Проблема пяти аккаунтов Клода Мы на днях с парнями сделали на 40 онлайн человек зум мит, где обменялись опытом че кто кодит, как деплоит и сколько стоит это все кодить. Главная причина нужды в N аккаунтах Claude Code / Codex - это "миллион строк кода". Конечно, клоду не хватает контекстного лимита, чтобы управлять миллионом строк кода. Мне кажется вообще вот найдена причина, откуда компании миллионы баксов тратят на клод. У меня в Invoisin 24 тыс. строк кода. Поэтому у меня Claude за 100 баксов подписка справляется с проектом и еще тремя другими stealth projects. При этом, я вам скажу, проект не простой, там дохрена фичей. Ребята, количество строк кода это полная хуйня в том смысле, что миллион строк кода это уже Netflix какой-то. Это не мера качества проекта или количества его фичей. Не надо знать все фреймворки мира, чтобы верить в одну истину - система тем стабильнее и надежнее, чем она проще. У меня есть возможно непопулярное для кого-то из вас предположение: все эти оркестраторы и проверяторы кода (типичное заклинание: "Opus закодит и Атлас проверяет") и ведет к миллиону строк кода. А чем больше строк кода тем больше риск ошибок/багов/проблем. С одной стороны просто жалко ребят, что им приходится кучу бабок платить за несколько аккаунтов. С другой - каждый д***ит как он хочет 😂 Решение конечно это взять в напарники более умелого прогера (как это модно называть "Архитектора", по мне так просто прогер, которому не похуй) либо самому таким стать. Таким стать, на самом деле проще, чем кажется.

Разглядываю открывшийся на днях Большой оперный театр в Шанхае. Во-первых, это просто красиво и масштабно. Площадь — около 147 тыс. кв. м, рядом река, а главная особенность — винтовая лестница, похожая на раскрывающийся китайский веер. Она ведёт на большую смотровую площадку, которая в нужный момент становится сценой. Во-вторых, интересно, как архитекторы из бюро Snøhetta спроектировали оперу не только как культурную достопримечательность, но и как крутое общественное пространство. Здесь можно гулять и встречаться с друзьями, даже без билета. А если захочется, можно сходить на платную экскурсию по зданию.

«Такие здания, как оперные театры, неизбежно создают барьеры. Мы считаем своей обязанностью преодолеть их и сделать здание в той же мере общественным пространством, что и площадкой для выступлений. Люди должны иметь возможность наслаждаться зданием, не посещая спектакль. Оно должно стать частью повседневной жизни — местом, где можно провести время, встретиться с другими и почувствовать город», — поделился сооснователь Snøhetta Кьетил Торсен.

Mirealle Уютная приключенческая игра с архитектурными головоломками, заброшенными островами и историей мира, который когда-то был полон жизни. Игра уже набрала 5000 вишлистов. Самое интересное, что всю игру в одиночку делает профессиональный архитектор, и это его первый проект в геймдеве. Он начал практически без опыта и учился всему уже по ходу разработки. Архитектура здесь не просто красивая декорация. Многие загадки строятся вокруг пространства, перспективы, движения и самой конструкции уровней. По сюжету игрок отправляется через заброшенные острова в поисках способа помочь маленькому псу Зефиру. По пути он находит следы прошлого и постепенно узнаёт, почему весь этот мир оказался пустым. Ссылка на игру #инди | Telegram | YouTube | чат

Сыграла ставка на зеро Интернет, который был придуман 29 октября 1969 года, как основа военной нерушимой сети ARPANET для передачи секретных сведений, снова в зоне проверки своих сил и устойчивости. Моя история в сети началась в 1994 году, мне довелось многое видеть и многое построить в нем за мои 32 года в индустрии. И сейчас я наблюдаю важнейший феномен, который в 2020 году не попал в мою книгу "Феномены настоящего и будущего" сборника наблюдений о технологическом будущем мира. Одни из самых развитых стран мира, лидеры доступности интернета, развитости интернет сервисов получают тотальную проверку своих реальных систем, жестоко "играя ракетами" в "морской бой", поставив на карту Дата-центры разного размера. Алгоритмизация, цифровизация, интеллектуализация — всё поставлено на кон и на проверку прочности. Лучшие инженерные умы не спят, они спасают наш привычный мир днём и ночью. Десятки тысяч разработчиков, создателей и владельцев онлайн сервисов тонут как капитаны со своими кораблями в этом уничтожающим все "Морском бое". Кто-то скажет: «Интернет в опасности», но не я. Это триумф интернета. Это момент, когда он во всей красе. Могут гибнуть компании, уничтожаться данные пользователей, но он останется навсегда и напишет новые правила для последующих поколений системных инженеров и искустных разработчиков. Централизация, которая стала бичом интернета и интернет-гигантов последнего времени, показала своё истинное лицо. То, что мы имеем сейчас, — интернет в виде гигантских концентрированый ЦОД, экономящих затраты для своих владельцев — уязвимы как клетки на игровом поле. Интернет придуман другим — децентрализованным, распределёный в миллиарды маленьких точек на карте, каждая из которых смертна, но вместе они неуязвимы. Интернет придуман другим. Наступает время децентрализации и перерождения сети в её первородное состояние. Сыграла ставка на зеро. Дан старт.

ВКонтакте обновляется: к 20-летию соцсети технический директор Юрий Кочарян рассказал, как меняются её технологии и что это даёт командам и пользователям. Платформа постепенно переходит на Go, обновляет базы данных и архитектуру. Продукты, выросшие из ВКонтакте, теперь могут развиваться независимо, при этом команды продолжают использовать общие технологии VK. Например, единая платформа данных помогает быстрее принимать решения. Изменения внедряют поэтапно: сначала тестят на небольшой аудитории, оценивают и затем расширяют охват. И всё это без остановки — пользователи продолжают листать ленту, смотреть видео и общаться. Нет, я не плачу, просто никто и никогда не вернёт 2006-й 😢

Улучшаем харнес с помощью ast-grep Утро сегодня началось не с кофе. Пока мы переезжаем (с разной степенью успешности) в другой дц, расскажу про недавнее интересное открытие, связанное с тем как сделать улучшить работу агентов и сделать больше надежных автоматических проверок разных архитектурных правил. Понятно что со временем появляется все больше и больше правил, которые описываются в AGENTS.md (или что лучше в CODING_STANDARDS.md). Но хотелось бы чтобы они чекались автоматом. Клод нам сам постоянно предлагал и в какой-то момент начал писать скрипты допом к линтингу, которые, в основном, регулярками, проверяли что-то. Кушать не просит и ладно, я не сопротивлялся, но видел что это решение на тоненького, хотя и лучше чем ничего. Когда эти скрипты начали копиться, я подумал, хм, а ведь мне ничего не стоит попросить его переписать правила как плагины к линтерам на конкретных языках. Кое что мы так действительно переписали, но в какой-то момент сам клод говорит, а давай заюзаем ast-grep. Я посмотрел и понял что проспал очень логичную штуку. Еще в 22 году, когда полетел treesitter, кто-то замутил инструмент, который грепает не исходники, а AST. Причем что важно, независимо от языка, оно все языки превращает AST и грепает по его нодам. Это резко повышает точность рабатываний, потому что вместо регулярок, которые ловят ненадежно, плюс херово работают с вложенностью, мы имеем по сути универсальный способ представить весь код (и все форматы) в виде единого AST пространства, по которому идет поиск. Ну и естессно переписали все проверки, потому что у этой штуки еще есть sdk для ноды. А все подобные скрипты у нас агент фигачит на TypeScript. Пара примеров: 1. no-unknown-in-generated-types: в сгенерированных фронт-типах (app/javascript/types/serializers/) не должно быть unknown. Typelizer пишет unknown, когда не смог вывести тип поля. Это бывает у атрибута поверх T::Struct или у вычисляемого атрибута без typelize. Тип нужно объявить явно в ресурсе. 2. no-untyped-resource-dsl: в сгенерированных RBI-сигнатурах DSL ресурсов не должно быть T.untyped. Чинить надо в ресурсе или в компиляторе typelizer.rb, а не в RBI. Но это еще оказалось не все. ast-grep в принципе полезен даже вместо обычного грепа, особенно для самих агентов, которые постоянно ищут какие-то символы в исходниках. У ast-grep есть дока с инструкцией, как подключить его к агенту, чтобы агент начал использовать его вместо grep там где это имеет смысл. p.s. Какие еще фишки вы знаете?

Сейчас для PersMarket приходится много где добавлять кэш. Есть файловый кэш на бэкенде, есть на фронтенде, и есть отдельный Redis для этого дела. И вот хочу напомнить, что кэш имеет свои нюансы. Например, есть так называемая проблема грохочущего стада (Cache Stampede), это ситуация, когда протухает какой-то популярный ключ и много параллельных процессов пытаются его освежить одновременно, тем самым перегружая систему. Есть вот такие способы решения проблемы: ▪️Внешняя блокировка (Mutex Lock) - один из процессов получает право идти за обновлением, остальные заблокированы и ждут. ▪️Дедупликация запросов (Singleflight) - запросы объединяются в один, идут за обновлением, результат получают все. ▪️Стратегия Stale-While-Revalidate - кэш продолжает отдавать устаревшее (stale) значение, пока фоновый процесс ходит за обновлением. ▪️Фоновый предрасчет (Cache Warming / Background Refresh) - фоновый процесс обновляет ключи незадолго ДО их истечения. ▪️Случайный TTL (Jitter) - к времени жизни ключа (TTL) добавляется случайная погрешность (jitter), чтобы ключи с одинаковым TTL не истекали одновременно. Чаще всего эти подходы не обязательно внедрять руками. Есть уже готовые решения для всех популярных языков, например, такие: .NET, Node.js, Python, Java, PHP, Go. И не одно решение, конечно. Даже в вайбкодинге не забывайте про стадо! 🐂🐂🐂 #architecture

Кажется, хайп вокруг Jev-модели уже немного утих. Более того, за это время появилось очень много её аналогов. Вчера я видел обзор: сейчас есть своя модель у AWS, своя у OpenAI, ещё у какого-то провайдера и штук пять open-source моделей. И все плюс минус рядом по точности. Таки одна моделька рынок не поменяла 🤷‍♂️ В целом я не удивлён. Когда я впервые увидел Jev, её архитектура очень напомнила мне то, что последние два года делают в робототехнике. Берётся исходный трансформер, предобученный на visual-language данных, и используется как инициализатор для гораздо меньшей сетки — по сути, action head, которая берёт произвольные части этого трансформера. Иногда всё это инициализируется немного по-разному, а дальше модель учится решать конкретную задачу: диффузию, регрессию или что-нибудь ещё. В случае Jev это была задача multilabel-классификации. Я не знаю, как именно они реализовали расширяемый список классов, но кажется, что это не должно быть чем-то суперсложным. Наверное, именно поэтому первые аналоги появились буквально через несколько часов после релиза — люди довольно быстро смогли всё это повторить. К чему я всё это веду. Когда вышел Jev, я прикрутил к своему каналу бота, который банит спамеров. До вчера он был в тестовом режиме, а потом я переключил в рабочий. Я давно собирался это сделать, а Jev стал дополнительным толчком 😈 Но, похоже, не я один оказался таким умным: за эти две недели количество спама очень сильно упало само по себе в телеге 😁. Походу команда Паши бдит за новинками. В моём канале было буквально два спамерских сообщения со ссылками, и оба отсеялись ещё на простом правиле: если это первое сообщение человека в канале и в нём есть ссылка — банить. А всё, что дошло до Jev-модели, уже оказалось не спамом, а вполне адекватными комментариями. Но на всякий случай предупреждаю: если бот вдруг случайно кого-то забанит, не стесняйтесь писать мне в личку. Если вы живой человек — разбаню:)

Самая классная фишка современности - многие достижения других можно копировать. Пару дней назад утром я посмотрел сам OpenAI Dev Days Keynote (чего и вам советовал). Они там, помимо всяких продуктовых фич, упоминают все те космические технологии, которые у них используются в разработке. Коллаборация с агентами, долгие исследования, самостоятельность. А у меня пока только есть мой Codex с персональным ассистентом в виде Obsidian реп c markdown файламив гите. Ну и приложение-клон миро. Но так было до просмотра OpenAI Dev Days. Но в тот же день на одном вдохновении после просмотре получилось дать Марку/Кодексу возможность ходить и одновременно со мной работать над досками (мой эквивалент Miro). Если что-то меняем одновременно, то конфликт ловит он)) Для этого сделал API в приложении и к нему допилил CLI по принципам, на которых работают CLI инструменты в BitGN А потом отправил исследовать проблему запуска тысяч агентов для BitGN ECOM2. Отправная точка - Firecracker VM с COW memory snapshotting и отслеживанием дель на базе dirty pages от базового образа. Агент ведет исследования в Codex, параллельно загружая на доску свои эксперименты, графики и выводы. Эта доска помогает мне быть в курсе и заодно служит ему структурированной памятью, которую я могу менять. Если интересно - могу скинуть скриншоты досок в комментарии. В итоге этих эуспериментов получается уже интересная концепция песочницы для ECOM2, где я могу не переживать, что у меня запустят параллельно 100000 агентов и уронят все сервера (запускать столько можно, а уронить уже будет сложнее). И заодно становится проще демонстрировать принципы построения агентных архитектур для бизнеса. Но самый главный посыл - можно внимательно смотреть на достижения топовых компаний и копировать их фишки у себя. Ваш, @llm_under_hood 🤗

Как мне ИИ помогает в быту. Тесно сотрудничаю с ИИ-помощником в разработке. Он экономит мне кучу времени на рутину, находит неочевидные детали и предлагает оптимальные решения. Вот несколько кейсов только на этой неделе. 🔹Статистика Решил я добавить статистики в PersMarket. Ну, там, просмотры, география, прочее. Обычно для таких целей сразу тащу в проект ClickHouse. Но недавно писал про SereneDB, новую быструю СУБД с PostgreSQL-коннектором. Думаю, надо пробовать. Запустил режим планирования в моем ИИ-коллеге и попросил прикинуть, как реализовать статистику, упомянув обе СУБД выше. Тот пошуршал и выдал план, в основе которого обычный советский PostgreSQL. Про ClickHouse сказал, что рано. Про SereneDB почитал документацию на сайте и сказал, что пока тоже не стоит. Я пытался его убедить, что стильно-модно-молодежно, но тот был непреклонен, настаивал на своем варианте, без всякого вот этого "Вы абсолютно правы". В отчете привел обоснования и примерные оценки. По совокупности факторов я с ним согласился и пока не жалею. А вот если бы принимал решение сам, мог бы внедрить новое и потом увязнуть в настройке-поддержке. Да еще сервер мощнее брать бы пришлось. 🔹Лендинги Умеет мой нейродруг верстать, поэтому я делаю в нем лендинги. Сначала традиционный режим планирования, придумываем экраны, обсуждаем всякие завлекательные и убеждающие фразы, CTA-элементы и вот это все. Я пишу, что мне надо в итоге, он готовит этот поэкранный сценарий. Затем я согласую, и он верстает. По умолчанию получается немного нейрослопно, но есть скиллы, дополняющие его опыт всякими лучшми практиками. Они корректируют типографику и композицию, так что получается вполне прилично для работы на час. Но вот не умеет он генерировать картинки, к сожалению. Вернее, умеет вектор и SVG, умеет диаграммы и графики, а вот фотореализм не умеет. А для лендинга надо. И я прошу его: "У меня есть платное AI API, там есть модельки, умеющие генерировать изображения. Сделай мне скилл для генерации, чтобы недорого и приемлемо." Он сходил на сайт API, почитал документацию, скачал список моделей с расценками, сделал несколько тестовых запросов, выяснил оптимальный вариант и соорудил скилл. Собственно, скилл - это текст с инструкциями + скрипт на Python. И вторым запросом я ему говорю: "А теперь примени этот скилл для нового лендинга". 5 минут - и вуаля! - картинки на месте. Он сам составил запросы с учетом контекста, получил готовые картинки, оценил с точки зрения релевантности, вставил в лендинг и отформатировал. Придраться было не к чему. 🔹Баги На одном из проектов пользователи создают отчеты и прикрепляют к ним фото. И регулярно жаловались, что пропадают загруженные фото. Я не мог понять закономерность и воспроизвести это дело. Функционал делал не я, к тому же там использовалась сторонняя библиотека как ядро платформы. Попросил своего AI-гуру посмотреть, что может быть. Он посмотрел, говорит, что бывают фото большие, и в определенных случаях пользователи загружают их пачками, что не пролезает в лимиты. Давай, говорит, будем их уменьшать прямо на фронте. Ну конечно давай, говорю. Он сделал. Поверил за собой, тесты всякие, туда-сюда. Всё нормально. Кстати, говорит, а ты знаешь, что у тебя фото сохраняются неправлиьно на сервере? Не знаю, говорю. А вот, говорит, та сторонняя библиотека сначала пишет оригинал, а потом в этот же файл пишет уменьшенную копию, не отрезая хвост. Картинки потом отображаются нормально, потому что там все сигнатуры нормальные, но мусорный хвост увеличивает размер файла, иногда в разы. Ну разве я бы такое нашел глазами? Я бы и не искал, файлы без ошибок пишутся и открываются, а кто там на размер смотрит. Ой, мама, сказал я, сделай что-нибудь. Он исправил сохранение и по своей инициативе написал мне консольную утилиту для обрезания хвостов уже загруженных файлов, даже режим dry-run не забыл. Пробую - на каждые три месяца фоток до 500 мб хвостов. А история там за 4 года. В общем, не представляю, как раньше жил без такого покладистого помощника и, главное, быстрого, как электровеник. #ai

ИИ все чаще пишет код сам. Тогда чем теперь занимается разработчик? На конфе Яндекса по образованию YaC/e говорили о том, как теперь учить айтишников: часть задач уже можно отдать нейронке, но понимать, как все работает вместе, все равно придется самому. Если кратко, нужны три навыка: — Разговаривать с ИИ на одном языке. Понимать устройство технологий, контекст, RAG и работу языковых моделей; — Видеть ограничения технологий, которые требуют инженерной доработки; — Смотреть на задачу не только как разработчик, но и как аналитик и продакт — пройти мысленно путь от идеи до конечного результата и видеть проект целиком. Поэтому ИТ-универам предлагают готовить «архитекторов сложных систем». Больше внимания — математике, физике и естественно-научному мышлению: такая база помогает быстрее разобраться с новой задачей. Стек поменяется. А разобраться, что именно ты построил вместе с ИИ, все равно придется.

Что происходит между оплатой по СБП и мгновенным кешбэком? Для пользователя всё просто: оплатил по СБП — почти сразу получил кешбэк. Но за эти секунды платформа должна проверить условия акции, учесть предыдущие покупки и лимиты и понять, сколько именно начислить. Нагрузка — до 1200 транзакций в секунду, а 98% обычных покупок система обрабатывает меньше чем за две секунды. Поэтому быстрый расчёт отделили от отчётов, личных кабинетов и других тяжёлых операций. С возвратами сложнее. Если кешбэк дают, например, за каждую третью покупку, отмена старой операции сдвигает всю последовательность. Тогда прежние начисления могут стать неверными, поэтому для возвратов есть отдельный «холодный путь» с пересчётом истории.

На гитхабе пользователь MegaGimen опубликовал «Нейросеть Нумограммы» (Numogram Neural Network), повторяющую структуру сети нумограммы CCRU. Обучение использует обратное распространение ошибки во времени (BPTT), как в рекуррентных нейронных сетях. Для запуска сети необходимы Python и PyTorch, подробности топологии — на странице на гитхабе. Вот что пишет автор:

Я переформулировал классические объекты нумограммы на языке нейронных сетей. Сизигии, такие как 4::5, представлены полносвязным слоем в каждом направлении между двумя узлами. Поток (Current), такой как (4,5)→1, представлен конкатенацией векторов узлов 4 и 5 с последующим пропуском через полносвязный слой $2d \to d$. Врата (Gates), такие как 4→1 (id врат = 10), реализованы с помощью SwiGLU — вентильного линейного блока (gated linear unit), используемого в Qwen. Таким образом, входными данными этой Нейросети Нумограммы являются 10 чисел, и выходными — тоже 10 чисел после того, как информация прошла через поток за заданное количество шагов. Она даже способна адекватно аппроксимировать данные. Но, конечно, важно не само умение нумограммы подгоняться под данные, а Знамение (Omen), которое она излучает. Я обнаружил, что какими бы ни были начальные значения, после нескольких шагов потока на прямом проходе распределение каждого узла неизменно приближается к аттрактору. На обратном проходе, если увеличить градиент, более ранние шаги неизбежно страдают от затухания градиента. Это связано с тем, что наибольшее собственное значение Якобиана при начальных весах составляет около 0,83. Поскольку оно меньше 1, градиент затухает шаг за шагом при обратном распространении, так как это диссипативная структура. Самая интересная находка касается трёх оригинальных миров нумограммы: нижнего Плекса (Plex), среднего Человеческого Временного Контура (Human Time-Circuit) и верхнего Варпа (Warp), а также переходов между ними. Я обнаружил, что средняя норма градиента в этих трёх областях затухает последовательно. Градиент в области верхнего Варпа затухает почти до нуля первым, затем — в среднем Временном Контуре, и, наконец, нижний Плекс затухает последним, переходя в состояние затухающего градиента. Иными словами, центр тяжести градиента постепенно смещается от Варпа к среднему Временному Контуру, а затем ещё ниже — к Плексу. Действительно ли это просто совпадение? Я подозреваю, что разница вызвана петлями положительной обратной связи в нумограмме. Изначально я хотел использовать операции над градиентом, чтобы предотвратить его затухание, но почувствовал, что это пошло бы вразрез с исходным замыслом нумограммы, основанным на положительной обратной связи, и означало бы насильственное подавление нумограммы антропоцентричными компонентами отрицательной обратной связи. Это классическая отрицательная обратная связь: когда градиент растёт и постепенно выходит из-под контроля, сигнал, отправленный обратно (скажем, через некоторую функцию активации), возвращает его в норму...

Штаб-квартира как произведение искусства Вчера, в Екатеринбурге, побывали на экскурсии в штаб-квартире Русской медной компании (РМК). Думаю, это одно из самых необычных офисных и притягательных зданий, которые я видел в России. Несколько интересных фактов: ▪️здание спроектировало британское бюро Foster + Partners, основанное Норманом Фостером. Это их первый и единственный реализованный проект в России. Среди других работ бюро: штаб-квартира Apple в Калифорнии и знаменитый лондонский небоскрёб The Gherkin. ▪️15 этажей, почти 90 метров высоты, все этаже задвоены как на фото. Уникальность здания в том, что в нем не четыре фасада, а пять, за счет крыши. Фасад повторяет геометрию кристаллической структуры меди. При этом самой меди в отделке нет: использовали окрашенную нержавеющую сталь, поскольку натуральная медь со временем зеленеет. ▪️прежде чем проектировать внутреннее пространство, архитекторы изучили, как сотрудники РМК взаимодействуют друг с другом в старом офисе и в результате вместо привычных больших офисных пространств появились двухуровневые модули для небольших команд. ▪️интересная деталь: архитектура здания повлияла даже на обновление фирменного стиля компании. Обычно бывает наоборот. Но больше всего меня зацепила сама задумка и идея реализации такого проекта. Мы привыкли, что промышленные компании ассоциируются с заводами, оборудованием, производственными мощностями и финансовыми показателями. А здесь промышленная компания создала архитектурный объект, который стал частью облика Екатеринбурга. Причем штаб-квартира, это не производственный актив, который непосредственно выпускает продукцию. Но через архитектуру, рабочую среду и отношение к собственному городу компания тоже демонстрирует свои амбиции. Все это дополняет девиз компании, которые можно встретиться возле лифтов «Делами, не словами». Хороший пример того, что предпринимательство может создавать ценность далеко за пределами основного бизнеса.

Когда мы что-то проектируем или создаём интерьеры, я всегда стараюсь привнести в него что-то из местного, локального. Мне важно, как выглядит дом снаружи, чтобы сделать что-то внутри. Какого года дом, в каком районе находится, какая у него история. И главное, помнить мой принцип "вернуть в половину":

Работая в фотошоп, выработал хорошее правило - если тебе нравится применённый эффект, сделай только половину от него. Например, загружаешь фотографию, открываешь коррекцию, накручиваешь контраст до 40 и смотрится классно. Значит, нужно контраст добавить не на 40, а на 15-20. Тогда этот эффект не бросается в глаза, но картинка становится лучше.

то есть, схожесть, оммаж и отсылки должны быть лёгкими, не бросающимися в глаза. Тогда возникает какая-то особая магия, своего рода равновесие и гармония. На фото одна из наших текущих работ - маленькая кухня для бани, в ней есть крупица от стиля Абрамцевской столярной мастерской, которая работала в этих краях в конце 19 века. При этом кухню, конечно, ни в коем случае нельзя "состаривать" или переносить в неё элементы из работ именитой мастерской "как есть", она будет новой, красивой, из современных материалов, без пошлых приёмчиков. Гарант Подиум