Управление разработкой *

Откровения евангелистов БЯМ (LLM) для целей софтостроения генерируются публикуются с высокой скоростью. Не только на хабре, LinkedIn заполнен ими "под завязку". Прочитывать всё невозможно, да и не нужно, но некоторый тренд в изложении присутствует.

К сожалению, авторы много пишут о процессе, забывая собственно цели. Упоминание о функциональной сложности программы, как правило, отсутствует. Длина описаний процесса может создать ложное впечатление о развесистой функциональности, хотя большинство примеров находятся на уровне "записная книжка". В этом нет ничего плохого, просто не забываем, что 30 лет назад RAD типа Delphi умели создавать такие же "книжки" без написания кода вообще: достаточно было "накидать" компонентов на форму, настроить, связать их, и нажать "Run".

Накидали, и что дальше?

За словами "писать на близком к естественному языку", скрывается постепенное создание быстро растущего "промпта" - детальной спецификации, местами - псевдокода. Как следствие, необходимо иметь версии таких "исходников", как и раньше для кода (об этом практически не пишут). Для сторонних пакетов, API служб и прочих зависимостей не забываем указывать версии. По сравнению с таким "псевдокодом" техзадание может показаться увлекательной беллетристикой. Речь идет по сути о конечных спецификациях, ведь программирование - не столько кодирование (от силы 20% времени), сколько детальное проектирование и стабилизация.

Размер спецификаций псевдокода вкупе с описаниями контекста среды могут превзойти собственно размеры генерируемого кода, написанного программистом на формальном ЯВУ. Спецификации придется так же хранить в Git, и нервно просматривать, что же изменилось в сценариях, почему, ***, вместо слова "опять" кто-то написал "снова".

Для детерминированности процесса желательно, чтобы моделька была в том же состоянии, что и на предыдущем этапе генерации, но для внешних БЯМ-сервисов это недостижимо. Напомню, что компиляторы и классические генераторы кода (CASE, MDD) - детерминированные.

На первый план выходят тесты, их нужно писать "больше и лучше", потому что под капотом теперь только "черный ящик", "белого" больше нет. Тесты нужно постоянно обновлять в зависимости от объема изменений. Если ваши новые спецификации меняют 20% существующей кодовой базы, то тестов придется менять вдвое больше, принимая 2:1 за стандартное соотношение тестов к коду. Для языков без статической типизации тестирование еще более усложняется.

В реальных проектах написание сотен строк в день - это режим стартапа, причем на "нулевом цикле". Достаточно быстро программист приходит к естественной норме десятков строк в день, остальное время занимает понимание текущего потока проблем, поиск ошибок, интеграция и стабилизация. Хороший программист минимизирует объем порождаемого кода. Нужно ли включать БЯМ для написания 50 строк в день - вопрос.

В процессе не предусмотрена роль юниоров. Перспектива - "уйти со сцены", не воспитав смены, достаточно сомнительная для бизнеса и весьма печальная в личном плане.

Напоследок накину немного философского. Евангелисты любят упоминать, что человеческий мозг и БЯМы работают на одних и тех же принципах. Часто выясняется, что курса "Аналоговые ЭВМ" на их потоке уже не было, что несколько удручает. Еще более простой вопрос на примере несуществующей (пока?) телепортации: "Человек на входе телепортера и на выходе - это одна и та же личность?"

Чек-лист: твой проект скоро развалится, если…

Небольшой технический чек, который стоит пройти каждому, кто ведёт продукт или отвечает за разработку.
Если узнаете себя — возможно, пора не спешить с новой фичей, а разложить фундамент.

• Весь проект держится на одном человеке
  И он — не документация. Ушёл в отпуск — проект замер.

• Задачи ставятся в личке, на встрече или в голове
  "Я же в телеге писал задачу". Без трекинга всё разваливается.

• Никто не может объяснить, что по приоритету
  Всё срочно, всё горит, всё одновременно. Ну вы поняли.

• Прод выкатывается вручную, или в пятницу вечером
  Даже не баг, а фича. Проблемы по подписке.

• Тестов нет, баги ловим по фидбеку
  Багрепорт от клиента — это не QA.

• Архитектура — это слово из чужого лексикона
  Потому что “нам и так норм”. До первой перегрузки.

• Вопросы “а как это работает?” решаются методом тыка
  Потому что комментировать код — западло.

• Бэкапы где-то есть… но никто не проверял
  Олег говорил, что сохранял себе дамп локально

• Ушёл один человек — и половина знаний ушла с ним
  Значит, их не было в проекте — только в его голове.

Если вы загнули 3–4 пальца — значит пора встать и осмотреться.
Пока “всё работает” — это ещё не стабильность, это просто везение.

Некоторые проблемы уже рассмотрел подробнее в своих статьях

Фича ради фичи

Как легко потерять смысл разработки, добавляя “полезности”

• Сделаем ещё кнопку, она “точно нужна”

• Добавим фильтр, и сортировку, и модалку, ну мало ли

• Вот бы выгрузку в Excel, и график, и пуши!

…Проект набирает скорость. Только куда?

В чём проблема?
Когда цель — просто сделать больше фичей, а не решить конкретную задачу, продукт начинает разваливаться: интерфейс пухнет, команда тонет в «хотелках», релизы идут в спешке, а люди - даже не замечают большинство этих «удобств»

Парадокс: чем больше фич, тем хуже продукт

Потому что он уже не про ценность, а про “галочки” и “давайте сделаем ещё”.

У фичи должен быть KPI, надо ставить вопрос «а что изменится от нее?». Также их надо подчищать, если старые не используются: «больше ≠ лучше»

Хороший пример: есть множество платных плагинов для Notion, в которых тонна функций. Но пользователям часто нужна была именно интеграция с Гугл таблицами, они не хотели переплачивать за другие возможности плагина.

Один парень заметил это, и сделал элементарный плагин для интеграции Notion с Google Sheets, на чем начал зарабатывать хорошие деньги.
Людям не нужно «все и сразу», им нужна качественная точечная фича

Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.

Человек-комбайн

Почему зависимость от одного специалиста может утопить всю команду. Выглядит как супергерой. На деле — одиночка, от которого зависит всё.

Это «человек-комбайн». Его любят, на него надеются, он незаменим. До тех пор, пока всё не рухнет.

Первый этап

Команда обращается за всем именно к нему: помощь, проверка, советы. Он — живая документация и мозг проекта.

Для бизнеса всё выглядит отлично: «три в одном, да ещё и без лишних затрат».

Второй этап

Постепенно «комбайн» устаёт: таски неинтересные, общения слишком много, помощи просят постоянно.

Он начинает раздражаться, отказывать, “зависимые” замыкаются. Процессы начинают проседать — но пока это незаметно сверху.

Третий этап

Бизнес не замечает проблему, а специалист уже морально ушёл. Проходит немного времени, и вот он увольняется. И…

Судный день

Без него — никто не знает, как деплоить, где что лежит, как починить баг.

Документации нет, у разработчиков паника.

Прод падает. Клиенты жалуются. Команда — в ступоре.

Восстановление занимает недели. А иногда — проект просто не поднимается.

Как не угодить в ловушку?

Раздавайте ответственность. Не сливайте всё на одного “самого умного”. Растите дублирующих специалистов. Пишите документацию. Один супермен — это риск, а не преимущество.

Коромысло с одним ведром — всегда перевесит в одну сторону.

Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.

🛠 День 10: Разработка полным ходом.

Хочу поделиться прогрессом по нашему новому продукту, постарался тезисно собрать все что есть на данный момент:

📱 Мобильная версия

• Полнофункциональный интерфейс на телефоне- Можно создавать формы и просматривать ответы прямо с телефона

🔧 Конструктор форм

• Drag & Drop

• Автосохранение

• Заголовки (title, description)

• Брендинг: обложка, логотип (картинка, текст или эмодзи)

• 20+ типов полей: текст, email, телефон, рейтинги, файлы, дата, время

• Бизнес-поля: ИНН, ОГРН, КПП, БИК, СНИЛС, паспорт - с валидацией и проверкой хеша

• Рейтинги: 1-5 звёзд, 1-10

🌐 Переводы

• Уже есть RU / EN- Скоро сделаем ещё 48 языков

🗂 Папки и доступы

Папки с правами доступа - удобно делиться с командой

Уровни доступа:

• Владелец - полный контроль

• Администратор - всё, кроме удаления папки

• Редактор - формы и ответы

• Редактор форм - только формы

• Оператор - только просмотр/обновление ответов

• Платежи - доступ только к платежам

📋 Управление формами

• Поиск, фильтрация, сортировка

• Дублирование и удаление

• Шаблоны

🔗 Публикация

• Короткие ссылки (/f/abc1234)

• QR-коды

• Виджет для встраивания в сайт (iframe)

• SEO-метатеги

• Превью формы в соцсетях (OG, Twitter) с картинкой

• SSR-рендеринг форм

📊 Ответы и аналитика

• Фильтрация по дате, форме, IP

• Экспорт ответов в CSV

📎 Файлы

• Поддержка 20+ форматов

• Превью: изображения, PDF, CSV, текст и др.

Карма vs Инженерная честность: Почему рейтинги убивают экспертизу

Есть в инженерной культуре наивная вера: если система имеет метрики и правила - она безусловно и по умолчанию объективна. Карма на Хабре тому идеальный контрпример. Формально всё честно: пост → оценка → рейтинг. На практике же это цифровой аналог пассивно-агрессивного "не зашло". Без объяснений. Без контекста.

Социальная инженерия вместо экспертной оценки

Главный парадокс: чтобы выжить, ты должен угадывать не истину, а ожидания аудитории. Тон, формат, табу. Это краш-тест на конформизм:

Написал, что 80% мониторинга в проде — это фейковый SLO? → Минус ("негатив").
Сказал, что ChatGPT пишет ТЗ лучше джуна? → Минус ("ересь").
Осмелился быть лаконичным без смайликов? → Минус ("агрессия").

Почему так? Потому что карма измеряет не глубину мысли, а комфорт восприятия. Инженерная точность = высокомерие. Прямолинейность = токсичность. Даже если за этим — годы практики и статистика.

Карма как инструмент подавления инакомыслия

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

Итог:
Действительно качественные и экспертные умы, готовые спорить и рушить догмы, — уходят.
Остаются те, кто мастерски жонглирует банальностями в дружелюбной обёртке. Звучит довольно резко, соглашусь. Но иначе не донести усть мысли.
Платформа медленно превращается в клуб взаимного одобрения.

Что делать?

1. Игнорировать карму как погрешность системы (но тогда зачем она?).

2. Требовать мандат для минусов ("Укажи причину: факт ошибка/оффтоп/токсичность"). Хотя у кого тут истребуешь - не нравится, двери на кнопке "выйти".

3. Ввести верифицированную карму - например, чисто теоретически, только от пользователей с 100+ постами в профильных хабах.

Пока же мы имеем соцсеть, где алгоритмическая справедливость проигрывает человеческой... нетерпимости.

P.S. Этот текст - эксперимент. Проверим, сколько стоит сказать: "Император голый". За инженерную честность - не жалко.
P.P.S. Карма — временна. Культура дискуссии — вечна.

Как QA и DEV могут эффективно работать вместе, а не играть в бесконечный пинг-понг с передачей фичи на тестирование и багов туда-обратно?

Об этом Лена Федорова, QA Garage Eight, рассказала на своей лекции «Мир, дружба, тестирование» на QA митапе в офисе Garage Eight. Она поделилась кейсом своей команды по внедрению совместного тестирования и тем, какие результаты оно дало.

Смотри лекцию и узнаешь:
> что такое «совместное тестирование»?
> какие у него преимущества и недостатки;
> каким командам подойдет этот подход;
> как измерить успех.

YouTube | VK Видео

Как развернуть среду разработки и сервис управления проектами в облаке?

Группа IT-компаний Lad сократила время запуска клиентских проектов, автоматизировала сборку клиентских приложений для iOS и развернула производительную инфраструктуру для публичных сервисов. И все это — на инфраструктуре Selectel.

• В основе инфраструктуры — облачные серверы с быстрым запуском, автомасштабированием и возможностью использовать подход GitOps.

• Чтобы автоматизировать сборку клиентских приложений для iOS, компания арендовала в Selectel серверы Mac mini^®.

• За производительность инфраструктуры для публичных сервисов отвечает связка из Managed Kubernetes, Container Registry и S3. Она позволяет поддерживать микросервисную архитектуру с отказоустойчивыми кластерами, автоскейлингом и надежным хранением файлов.

Как группа IT-компаний Lad развернула окружения для разработки и тестирования, а также запустила сервис для управления проектами и ИИ-ассистента для бизнеса, читайте в Академии Selectel.

Что ждет участников Ural Digital Weekend 2025?

1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций.

В 2025 году на конференции выступят спикеры из Альфа-Банк, Т-Банк, Яндекс, Avito.Tech, Ozon.tech, Битрикс24, SM Lab, Cloud.ru, Островок!, Столото, Scrum.ru, +7 pay, «Девелоника» (ГК Softline), Kokoc.tech, .redev, arcsinus, ARTW, ITECH, Terabit, Лидеры Изменений, Викенд в IT, CreativePeople, Luntry, Юникорн (Ujin), Деврел-бюро, MediaSoft, Product Vision, Partner’s Club, Тэглайн / agency2agency, Spectr и множества других известных компаний.

Программа конференции будет разделена на 3 секции: «Разработка», «Управление разработкой» и «Управление бизнесом». 

Полная программа и детали в нашем материале на Habr: https://habr.com/ru/articles/919802/

АГЕНТЫ И АГЕНТНАЯ ЭКОНОМИКА. 23.06.25

Микро-дайджест недели. Интересные мысли и инсайты.

Дайджест по материалам зарубежных медиа. Минимум булшита, максимум инсайтов.

=>  До появления ИИ вас отличали знания. Знать больше, означало зарабатывать больше. Накопление навыков, развитие экспертных знаний и освоение фреймворков вывели вас вперед.

А когда знания перестают быть дефицитными, что остается ценным? Мудрость. Вы можете получить ответы от ИИ, но то, как вы используете эти ответы, требует мудрости.

Мудрость это то как жить. Это остаток ошибок, усвоенный временем и размышлениями. Его нельзя торопить, и его нельзя копипастить. Это воплощение опыта, руководство изнутри.

Независимо от того, насколько умным становится ИИ, он не может прожить вашу жизнь за вас. Вот почему экономика будущего будет ценить мудрых работников. Давайте углубимся в их три основных навыка: эмоциональная ясность, проницательность и связь.

Работа, основанная на знаниях, умирает. Добро пожаловать в эпоху работы, основанной на мудрости Knowledge Work Is Dying. Here’s What Comes Next

=> Выход отчета The OpenAI Files отражает высокий уровень беспокойства среди лидеров мнений, в том числе со стороны бывших сотрудников OpenAI, и напрямую связан с убежденностью в том, что OpenAI действительно стремительно приближается к созданию AGI.

Сэм Альтман в своих недавних выступлениях говорит о том, что на пути к AGI мир уже прошел требуемый горизонт событий, и предсказывает, что в ближайшие несколько лет мир изменится сильнее, чем за последние столетия.

Илья Суцкевер, Ян Лейке и Стивен Адлер, бьют тревогу не из-за медленного прогресса, а из-за «опасной гонки» и «безрассудного» стремления к AGI, без наличия надежных методов контроля и согласования с человеческими ценностями.

Периодически появляются заявления инсайдеров, что фактически AGI «уже достигнут» внутри OpenAI на экспериментальных моделях.

=> Интервью с Сэмом Альтманом на AI Startup School в Сан-Франциско как и всегда приоткрывает некоторые важные нюансы стратегии компании. Несколько ключевых инсайтов ниже, но я всегда рекомендую смотреть такие выступления в оригинале, чем читать их саммари, в которых часто упускаются детали, имеющие именно для вас большое значение.

Альтман в очередной раз недвусмысленно намекнул на то, что новое устройство, которое они разрабатывают, сделает очередную революцию в интерфейсах (о чем я подробно писал в начале мае).

Поскольку цель OpenAI сделать из ChatGPT универсального ассистента и в чем-то ИИ-агента для каждого человека на земле, то по мере того как он будет узнавать каждого из нас лучше, он сможет и помогать нам все лучше.

Они готовят к релизу опенсорную и очень компактную модель, которая, по его словам, превзойдет все наши ожидания. Насколько я помню, вскоре за этим продуктом и должна появиться GPT-5.

И в очередной раз прозвучала очень важная мысль про Айвенторов:

...и я думаю, одна из вещей, которая будет ощущаться наиболее выдающейся в ближайшие 10 лет, по сравнению с тем же прошлым десятилетием, это то, как много может сделать один человек или небольшая группа людей с той свободой действий, которая у них будет (ну т.е. большим количеством ИИ-агентов)

Также Альтман употребил термин just in time software в новом контексте, о смысле которого я писал дней 10 назад, что если каждый сможет прямо на лету создавать под свою задачу требуемые алгоритмы. По сути, высокий уровень персонализации в функционале софта, да еще и создаваемого на лету, будет сильно конкурировать с текущей моделью SaaS продуктов, о чем и упомянул Альтман.

=> Создание надежных мультиагентных систем в 2025 году все еще нерешаемая задача, особенно если параллелить процессы, пишет исследователь и разработчик ИИ-агента Devin, Вальден Ян. Но по факту все зависит от решаемой задачи, и как вы строите когнитивные пайплайны. Он просто не читал мою книгу 😉

Предыдущие материалы и выпуски июньских дайджестов, в которых нет банальных ИИ-новостей, там до сих пор много интересных инсайтов для вас.

Альфред Лао. Новые Инсайты.

Паттерны проектирования: как всё начиналось?

Это заключительный эпизод курса «Паттерны и практики написания кода». В нём бэкенд-инженер Юра Афанасьев расскажет про истоки возникновения паттернов, а также объяснит, как урбанизм и проектирование городов помогли в создании книги «Паттерны проектирования». Напоследок Юра также разберёт два фундаментальных правила, описанных в книге «Design Patterns». 

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Вы знаете этих людей. Вроде умные, вроде опытные. Говорят правильные слова про 'стратегию', 'масштабируемость', 'долгосрочную перспективу'.
Но почему-то через полгода таких разговоров оказывается, что:

баг, который 'уже почти пофиксили' никуда из прода не девался
фича, которую 'вот-вот запустим' — всё ещё в черновиках
команда уже тихо ненавидит слово 'архитектура'

А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода

вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').

Бесконечный 'анализ'

'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'

Ответственность - это не про нас
Любимый приём - щедро размазать вину:

'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').

Реальный кейс (чтобы было не абстрактно)

В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.

А потом... уволился.

Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может

Как понять, что ваш техлид центральная часть системы самообмана?

главный результат его работы - не код, а презентации
коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует)
после разговора с ним хочется или закодить, или закопать

Что прикажете с этим делать?

тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.

ввести 'день испанского стыда'
раз в месяц техлид показывает руками, что сделал. Не слайды - код.

Задавать всего один вопрос

'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.

Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.

Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.

P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение

Часть 2: итоги недели разработки вайбкодинга с агентами

Прошлый пост тут

1️⃣ Текущий прогресс по xsoulspace.dev привел к тому, что обнаружил что есть закономерность какие именно модели хороши для использования в проектировании layout страницы (спойлер - не записал какие 🤦‍♂️ кажется использовал Claude 4.0 thinking + Gemini 2.5 Pro).

Что попробовал сделать : нарисовал простой wireframe image -> сконвертировал в ACSII art, и затем скормил LLM для более корректного восприятия layout.

Оказалось что так проще, но относительно (за счет убирания лишних элементов проще понять что где расположено), но с другой стороны LLM все так же тяжело воспринимать layout (если он чересчур кастомный).

2️⃣обновил все flutter библиотеки, last answer, word by word, budget app до flutter 3.8 - пользовался агентами в окошках. В некоторых случаях правил руками, но в большей части работал по принципу PDSA (Plan Do Study Act), где я разрабатывал план, а агент по нему шел, потому изучал результаты и т.д.
Вывод - нужно сильнее нарабатывать промпты.

3️⃣внезапно получил спам-рассылку-письмо с возможностью потестить on device API для того чтобы запускать модели. Чтобы потетстить решил запилить новое приложение для работы с промптами - действовал по принципу:

1. Идея и этические принципы

2. Палитра и дизайн система на основе идеи и принципов

3. План работы

4. Имплементация через агентов + доп ресерчи чтобы агенты понимали какую информацию брать.

Удалось собрать прототип за 12 часов (рабочую, включая все экраны и дизайн систему). Следующий этап - буду модифицировать чтобы можно было тестировать на реальных промптах в проектах.

Опыт: понял как создавать и работать с ролями (опишу в следующем посте про MVP), разобрался как запускать LLM на устройстве.
Недостатки: нужно более точно прописывать тех стак, особенно ключевые места, такие как - синхронизация данных, тип хранилища и т.д. И хорошо если изначально можно давать wireframes, или подгенеривать на основании дизайн системы.

Хотелось сделать нечто среднее между игрой и обычным интерфейсом, но пока не получилось.

4️⃣Создал детальный план и начал прорабатывать новую систему сохранения данных. Для меня это оказалось большой проблемой - потому что Hive, Isar на flutter перестали поддерживаться, а другие библиотеки неудобно использовать (где-то перешел на Sembast).

В результате на мой взгляд завязка на том, что данные хранятся непонятно где для конечного пользователя опасна тем, что в случае прекращения работы с приложением теряются все данные. Это оч больно.

Поэтому решил объединить все идеи и написать одну библиотеку которая будет из коробки давать синхронизацию с гитом, github и папками. Так надеюсь удастся побороть проблему долговечности и надежности хранения данных.
Пока агенты имплементировали 4 этапа из 5 (основную логику провайдеров данных), и как итог - собрал отдельное тестовое приложение (todo), чтобы протестировать работу (отдельный скриншот), понять недостатки и как можно быстрее завершить библиотеку чтобы начать интеграцию во все проекты. Это важно, потому что при одновременной интеграции сразу будет понятно что работает, а что нет, и таким образом будет проще получать feedback и развивать библиотеку качественно.

Спасибо за ваше время и хорошего дня!

p.s.:

Бумаги которые claude нашел по теме и одновременно не по теме)

• Towards Aligned Layout Generation via Diffusion Model with Aesthetic Constraints https://arxiv.org/abs/2402.04754

• CreatiLayout: Siamese Multimodal Diffusion Transformer for Creative Layout-to-Image Generation https://arxiv.org/abs/2412.03859

• Future of edge and on-device AI in gaming https://inworld.ai/blog/ml-advancements-that-will-make-on-device-ai-possible

• MobileExperts: A Dynamic Tool-Enabled Agent Team in Mobile Devices https://arxiv.org/abs/2407.03913

• From Cloud to Edge: Rethinking Generative AI for Low-Resource Design Challenges https://arxiv.org/html/2402.12702v1

• Generative Artificial Intelligence-Enabled Facility Layout Design Paradigm https://www.mdpi.com/2076-3417/15/10/5697

Последние из группы Поведенческих паттернов: Хранитель и Шаблонный метод

В одиннадцатой серии курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Юрой Афанасьевым завершаем тему Поведенческих паттернов. Последние два подхода, которые разберем в эпизоде: Хранитель и Шаблонный метод. Подробнее про их реализацию в коде, преимущества и недостатки — в эпизоде.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Эксперты по компьютерным наукам скажите свое мнение:

разработчики через 2 года будут не нужны?

80% разработчиков убьет ИИ ?

🚀 День 5: Тестирую управление общими папками в своем конструкторе форм. Релиз все ближе.

Так же запускаем череду юридических проволочек, чтобы стать Оператором Персональных Данных

Всё о назначении и применимости Наблюдателя и Цепочки Обязанностей

Это десятая серия курса «Паттерны и практики написания кода»: вместе с бэкенд-инженером Юрой Афанасьевым продолжаем изучать тему Поведенческих паттернов. В новом эпизоде разбираем два подхода, связанных с отправкой и обработкой событий: Наблюдатель и Цепочка Обязанностей.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Почему все сообщества инди-хакеров в России платные?

Давайте создадим свое бесплатное комьюнити для всех 👇👇👇

🖼 🚀 Я почти всегда выбираю ISR в Next.js для контентных сайтов.

Вот почему:

SSR:
- Каждый запрос = генерация страницы

SSG:
- Обновить контент = пересобрать весь проект
- При 1000+ страниц билдится часами

ISR - лучший вариант:
- Не генерит страницы сразу. Только по запросу.
- Ключевой параметр: revalidate - определяет, как часто Next.js должен перегенерировать страницы.

Например revalidate: 60 - страница обновляется раз в 60 сек, а между этим - юзер видит кэш из памяти.
Для некоторых контентных сайтов норма обновления данных 8-24 часа. Данные будут в оперативной памяти все это время.

💡 Фишка для SEO:
После деплоя (CI/CD) - страницы прогреваются скриптом, чтобы не ждать первого захода.
Это нужно чтобы поисковые боты видели всегда лучшую версию сайта, а не ждали прогрузки кеша.

📌 Вывод:
Если тебе не нужен real-time обновления сайта - ISR закрывает почти все потребности.

А чем пользуешся ты? Пиши 👇

Команда и Посредник: задачи и функции

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

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.