ТОП - Тёма о программировани

Здарова, работяги!Прошлые два поста были про сдвиг в голове: React всё меньше про «сравни деревья», всё больше про «какую работу и когда делать». Три поста на одной философии — перебор, так что ныряем под капот.Начну с фундамента: с чем React вообще работает, когда рендерит. Звучит занудно, но пока тут чёрный ящик, советы про memo и colocation остаются заклинаниями: делай так, а почему — непонятно.JSX — это объект-описание<ChildVerySlow /> сам по себе ничего не рисует. Это сахар над вызовом функции, которая возвращает обычный объект:<ChildVerySlow color="red" />// превращается примерно в:{ type: ChildVerySlow, props: { color: "red" }, key: null }Чертёж: какой компонент и с какими пропсами показать. Эти объекты одноразовые — на каждом рендере создаются заново и выбрасываются. Хранить в них что-либо нельзя, да и негде.Файбер — рабочая память ReactА жить-то где-то надо. На каждый узел дерева — компонент, div, даже кусок текста — React заводит файбер: объект, который переживает рендеры.В нём лежит всё, что должно пережить вызов функции: пропсы прошлого рендера, ссылки на родителя, ребёнка и соседа, пометки «здесь запланирована работа».Деревьев из файберов два: текущее, по которому построен экран, и рабочее (work-in-progress из старой лекции), которое React собирает под обновление. В коммите React переключает указатель: достроенное рабочее дерево становится текущим. Старые файберы не выбрасываются — из них, переписав поля, React соберёт следующее рабочее дерево.Стейт — связный список хуковЛокальный стейт тоже живёт в файбере. Никакой магии: на каждый вызов хука React заводит обычный объект, где лежит значение и ссылка на следующий хук. Вместе они сцеплены в связный список:// fiber.memoizedState, упрощённо:hook1 = { memoizedState: 'Тёма', next: hook2 }hook2 = { memoizedState: 29, next: null }Имён у звеньев нет. На новом рендере React идёт по списку заново: первый вызов хука получает первое звено, второй — второе. Всё сопоставление держится на порядке вызовов. Поэтому

Здарова, работяги!Раньше я, как и все, искал одну лучшую модель. Выходит новая — в чатиках вопрос «что сейчас топ». Одна шкала: от «тупее» к «умнее».Потом я начал экспериментировать с промпт-левел харнесами: оркестрацией, сабагентами и ролями поверх обычного чата. Не «один чат на всё», а оркестратор, исполнитель, быстрый поиск по кодбазе, архитектурный советник. Под каждую роль — своя цепочка моделей с фолбэками.Вот тут одна шкала и рассыпалась. В оркестрации модель выбирается не «лучшая вообще», а подходящая под роль: где-то важнее скорость, где-то формат, где-то глубина, где-то цена.Две оси вместо рейтингаЯ развёл выбор на две вещи.Первая — характер задачи: аккуратно сделать по плану, самому достроить решение или поработать с визуалом.Вторая — масштаб и автономия: сколько шагов, сколько надо думать, насколько без присмотра.Рейтинг «кто умнее» пытается свести эти оси в одно число. Мне всё чаще не хватало ответа «бери вот эту модель»: без роли и масштаба он мало говорит.Характер задачи → семействоУ семейств часто заметен разный характер: какие промпты модель лучше держит и где она у меня чаще окупается.— Claude-like модели (Claude Sonnet, Opus, Haiku, Kimi, GLM) — аккуратные исполнители. Хорошо держат план, чеклист и явный формат вывода.— GPT-like модели (GPT-5 mini, GPT-5, GPT-5.5, DeepSeek) — про автономное рассуждение. Лучше держатся там, где план ещё надо достроить: выбрать подход и не развалиться без маршрута на каждый шаг.— Gemini-like модели (Gemini Flash, Gemini Pro, Qwen) — сильны в визуале. Я беру их туда, где есть UI, скриншоты, макеты и визуальные баги.Это рабочая эвристика, а не закон. Границы размываются с каждым релизом, но для первого выбора под роль мне такой карты хватает.Масштаб задачи → размер моделиВнутри почти каждого семейства есть уровни: флагман, средний, быстрая мелочь.— Утилиты: найти файл, суммаризировать, сделать простую правку. Тут важнее скорость, цена и стабильный минимум качества. Примеры: Haiku, GPT nano / mini-fast, Gemini Flash, M

Здарова, работяги!Продолжаем про React.Если бы я сейчас пересобирал старую лекцию про React, я бы начал не с FPS.Тогда я заходил через плавность интерфейса: пользователь нажал кнопку, ввёл текст, открыл попап — интерфейс должен ответить без подвисаний.Это всё ещё правда. Но сейчас я бы быстрее переходил к другому вопросу: какую работу пользователь должен увидеть сразу, а какая может подождать.Старый заходВ той лекции я шел через 60 FPS.Идея простая: между двумя кадрами у браузера очень мало времени. Если JS надолго занял поток, браузер не успел отрисовать следующий кадр — интерфейс дёрнулся.Это не устарело. Просто 60 FPS — слишком грубая рамка, если на ней остановиться.Fiber в этой истории был ответом на проблему: React перестал воспринимать рендер как один большой кусок работы. Новое дерево можно готовить частями, а не в режиме «начали — теперь все ждут».Эта база держится. Если вы заблокировали главный поток тяжёлым JS, пользователю всё равно будет плохо.Но как объяснение современного React этого уже мало.Чего здесь не хватаетПроблема не только в том, сколько работы делает интерфейс. Проблема ещё и в том, какая это работа.Пользователь печатает в инпуте — символ должен появиться сразу. Иначе это ощущается не как «рендер не успел», а как сломанная клавиатура.А пересчитать результаты поиска, перестроить таблицу или подготовить следующий экран можно чуть позже. Пользователь не ждёт каждый промежуточный результат. Он ждёт, чтобы интерфейс не вставал колом.Раньше мы почти всегда упирались в один совет: сделай работу быстрее. Профилируй, мемоизируй, выноси state ближе к месту использования.И это всё ещё правильный совет. Просто он не закрывает весь кейс. Иногда работа нужная, но пользователь не обязан ждать её прямо сейчас.Что изменилось в моделиСовременный React всё меньше похож на прослойку для обновления DOM и всё больше — на механизм управления работой интерфейса.Не только:— что изменилось;— какие компоненты надо пересчитать;— какие DOM-изменения потом применить.А ещё

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

Здарова, работяги!Около четырёх лет назад я прочитал лекцию React(продвинутый) в ШРИ. Там был большой разбор про то, как React работает под капотом.Лекция неожиданно для меня хорошо зашла: я-то её планировал на аудиторию студентов ШРИ, а получилось 92к просмотров. До сих пор люди иногда пишут, что именно после неё у них щёлкнуло понимание React, и это меня сильно мотивирует.Потом я надолго почти перестал писать про React.Причина простая: я несколько лет преподавал React, не только в ШРИ, и в какой-то момент накопилась усталость скорее от преподавания, чем от самой темы.А пока отдыхал, React взял и уехал вперёд.Что осталось прежнимГлавная база из той лекции не умерла.React всё ещё не “просто меняет DOM”. Он строит work-in-progress дерево, сравнивает его с текущим деревом, готовит изменения и потом коммитит результат.Ререндер всё ещё не равен “браузер перерисовал весь экран”.key всё ещё влияет на то, считает ли React компонент “тем же самым” между рендерами.Ремаунт всё ещё может внезапно стереть локальный state.Фаза коммита всё ещё не то место, где React может спокойно сказать: “ой, браузер занят, я продолжу позже”. Если дошли до применения изменений — надо применять.То есть если вы тогда поняли идею current tree и work-in-progress tree, это знание не превратилось в тыкву.Но сменился фокусРаньше React часто объясняли через Virtual DOM.Мол, React строит виртуальное дерево, сравнивает с прошлым, находит разницу и аккуратно обновляет настоящий DOM.Как первая ступенька — норм. Как полная модель — уже слабовато.Современный React всё меньше хочется объяснять через “сравнение деревьев” и всё больше через планирование работы.Не просто:— что изменилось;— какой компонент ререндерится;— сколько DOM-нод надо обновить.А ещё:— срочная это работа или нет;— можно ли её прервать;— можно ли показать старый UI, пока новый готовится;— можно ли часть работы сделать на сервере;— можно ли вообще не делать ручную мемоизацию, потому что её заберёт Compiler.Вот это, по моему ощущению, главный

Здарова, работяги!Сегодня разберёмся, в чём боль code-first, что меняет schema-first и как это выглядит в Fastify.Code-firstПравила формы данных живут в коде, рассыпанные по разным местам. Валидация — отдельная функция. Типы — отдельный интерфейс. Обе сущности — копии одной и той же правды в разных синтаксисах.Знакомая картина — ручная валидация формы:function validateUserForm(values) { const errors = {} if (!values.email) errors.email = 'required' if (!values.age || Number.isNaN(+values.age)) errors.age = 'must be number' return errors}// где-то рядомtype UserForm = { email: string; age: number }Два источника правды на одну сущность. Один обновил — другой забыл. Дальше прод, неприятный сюрприз, разбор полётов в Slack.Schema-firstПодход, при котором описание формы данных живёт отдельно от бизнес-логики и является источником правды. Описываем форму декларативно — например, объектом JSON Schema. Дальше из этого объекта получаются:— валидация входа (запрос проверяется по схеме до того, как попадёт в обработчик);— сериализация выхода (ответ режется по схеме, лишние поля не уйдут наружу);— TypeScript-типы (генерятся из схемы — например, через TypeBox или json-schema-to-ts).Одна декларация — три артефакта. Обновил схему — всё остальное само догнало.Как это в FastifyFastify построен вокруг schema-first из коробки. Минимальный пример:const schema = { body: { type: 'object', required: ['email', 'age'], properties: { email: { type: 'string', format: 'email' }, age: { type: 'integer' } }, additionalProperties: false }, response: { 201: { type: 'object', properties: { id: { type: 'integer' }, email: { type: 'string' } } } }}fastify.post('/users', { schema }, async (req, reply) => { const user = await db.users.insert(req.body) reply.code(201).send(user)})Что мы получили бесплатно:— request body валидируется до обработчика. Невалидный — 400 с понятным сообщением, обработчик даже не дёргается;— response сериализ

Понял, принял, делаем 👨‍💻

Здарова, работяги!В прошлый раз говорили про скилы. Сегодня — про линтеры и форматтеры: как я выбирал стек на новом проекте, почему сначала взял Biome и почему переехал на oxlint + oxfmt.Почему про линтерыКак уже писал, прежде чем тащить guidance в скилы и рулы, стоит посмотреть, нельзя ли закрыть это автоматикой. Линтер — бесплатный детерминированный гейт: не забывает, не интерпретирует, не жжёт токены. Особенно ценно при работе с агентом — каждое правило в линтере = минус один пункт в guidance и минус один способ облажаться.Что было на столе— ESLint + Prettier — максимум правил и плагинов, но два тула, медленно, конфигурить долго.— Biome — один тул на всё (lint + format + import sort), быстрый, конфиг простой.— oxlint + oxfmt — Rust-стек от oxc: быстрый линтер с большим покрытием ESLint-правил и отдельный форматтер.Сравнение коротко— Скорость: oxlint > Biome >> ESLint+Prettier.— Количество тулов: Biome — один. oxlint + oxfmt и ESLint + Prettier — два, но oxlint + oxfmt живут в одной экосистеме и конфигурятся проще.— Покрытие правилами: ESLint — максимум. oxlint — большая часть популярных ESLint-правил, пул растёт. Biome — свой набор, заметно уже.— Конфигурируемость: ESLint — максимум. oxlint — гибко, overrides, плагины. Biome — намеренно ограничено.— Экосистема: ESLint — всё. oxlint — догоняет, ключевые плагины (react, typescript, import) уже есть. Biome — самодостаточно, плагинов нет.Почему сначала взял BiomeПросто, быстро, один тул. На старте проекта это закрывает 90% потребностей с нулевой настройкой.Почему слезПожил пару недель и понял, что правил банально не хватает.— Нет аналога consistent-type-assertions. Запрет as SomeType — критичное правило, потому что агенты обожают кастить типы вместо того, чтобы написать type guard или поправить сигнатуру. Без линтера это ловится только на ревью, и то не всегда.— Слабый no-restricted-imports. Хотелось паттернами фиксировать границы модулей в монорепе — в Biome либо никак, либо очень куцо.— Нет react/no-multi-comp и по

Пост фана и чутка рекламы 🚶Я сам не из Москвы: приехал сюда учиться примерно 10 лет назад. Скажу как есть: изначально город мне не зашёл. Он был совсем не похож на уютную Рязань, где я вырос. Особенно усугубляли ситуацию осень(начало учебного года) и идущая за ней зима — с темнотой, серостью и вот этим всем.В какой-то момент я смирился: ну, видимо, город такой. Сконцентрировался на учёбе, потом на работе.Но со временем отношение менялось. Я люблю ходить пешком: иногда выхожу на пару станций раньше и иду остаток пути ногами, а иногда вообще обхожусь без транспорта — в разумных пределах, конечно. Так постепенно проникался городом и находил новые места.Сейчас я уже совсем не могу надолго уехать: быстро начинаю скучать. Обожаю осень, весну и лето в Москве. Зиму, правда, так и не полюбил 😄В моей истории большую роль сыграли пешие прогулки. Но ещё очень крутой формат — разные забеги по городу, квесты и похожие активности. Они позволяют иначе взглянуть на любимый город.Яндекс решил организовать один из таких форматов — «Рекурсия по городу»: командное офлайн-приключение в формате CTF. Будет 35+ заданий по маршруту через точки, связанные с историей российской IT-индустрии: в том числе через территорию МГУ, центр фундаментальных исследований РАН и другие места.Старт — в одной из моих любимых локаций: штаб-квартире Яндекса в «Красной Розе».Если вам тоже интересны такие активности, переходите по ссылке и регайте команду

Здарова, работяги!В прошлый раз разобрались, чем отличаются memory bank, rules, MCP и skills, и сошлись на том, что основной фокус сейчас — связка rules + skills. Сегодня — как я пишу скилы: что стоит оформлять, что нет, и на что обращать внимание.Коротко напомню разницуRules — правила, которые агент держит в контексте всегда и применяет на каждой задаче.Skills — переиспользуемые сценарии. Агент знает, что они есть и когда их доставать, но не держит целиком в контексте.Две главные мыслиПервая: если проблему можно решить не скилами и не рулами — решаем не скилами и не рулами.Линтеры, форматтеры, тайпчек, скрипты, кодгены — надёжнее и дешевле любого guidance. Не забывают, не жгут токены, не интерпретируют инструкцию творчески. Скилы и рулы — это то, к чему приходим, когда автоматикой уже не получается.Вторая: скилы не пишем впрок.Отношусь к ним как к коду — пишу по мере необходимости. Со временем набирается своя база, и появляется чувство:• какие скилы я всегда тащу в новый проект, потому что они проверены опытом;• какие подключаю ситуативно — например, для React-проекта имеет смысл взять скилы Vercel про React(но не все);• какие пишу с нуля под конкретные грабли, которые увидел в работе агента.Скилл «на будущее» обычно не попадает в реальные сценарии и просто висит балластом. А если их много, агент хуже выбирает нужный и описания начинают конфликтовать. Поэтому: увидел поведение, которое не устраивает → если ответ «скилл», только тогда написал.Алгоритм: что делать, когда хочется добавить guidance1. Это уже покрыто? Существующий skill, rules, системный промпт, линтер. Если да — обновляю существующее, а не плодю новое.2. Можно ли решить тулзами? Линтер, тайпчек, скрипт, кодген. Если правило детерминированное — заводим автоматику. Скилл тогда максимум объясняет, что делать поверх тулзы.3. Это всегда или ситуативно? Всегда и на каждой задаче — rule. Под конкретный тип задач (ревью, новый пакет и тд) — skill.Как писать сам скиллDescription — самое важное. Агент видит толь

Воскресенье, 3 мая — последний день подачи тестовых в Летние школы Здарова, работяги! Многие из вас знают, что я уже несколько лет преподаю в ШРИ(школа разработки интерфейсов Яндекса) React, кто-то возможно даже был на этих лекциях(ссылки на некоторые есть в закрепе). В этом году я решил отойти от привычной темы и сконцентрироваться на новом для меня формате - с деталями и материалами вернусь чуть позже, но буду очень рад видеть вас в числе очных слушателей)Главное о школах:1️⃣ Направления: бэк (C++ и Java), мобилка (iOS и Android), фронтенд и фулстек, аналитика 2️⃣ Занятия очно в июле и августе в московском офисе. Программа насыщенная, но не помешает учёбе, работе и просто отдыху3️⃣ Ограничений по возрасту, вузу, ступени обучения — нет. Ждём всех, кто справится с отбором и готов поучиться летом, а осенью выйти на стажировку4️⃣ Планируем Школы на 400 человек — тебя ждёт широкий нетворк и плотная работа с ментором5️⃣ В программе собрали всё самое прикладное: актуальные технологии и подходы, практические домашки, командную работу над проектами, хакатоны, публичные выступления и вечеринки!Важная инфа: до 3 мая ждём и заявки, и выполненное тестовое — оно приходит на почту сразу после регистрации.@Young_and_Yandex

Здарова, работяги!У меня сложилось впечатление, что в сообществе есть определённая путаница на тему мемори-банков, рулсов, MCP и скиллов. Поэтому сегодня хочу поговорить с вами именно на эту тему.Начнем с определений.Memory bank — это внешняя память агента о проекте или пользователе.Туда обычно кладут долгоживущий контекст: архитектурные решения, договорённости, особенности проекта, вкусы команды, важные факты, которые агент должен помнить между сессиями.По сути, это способ не объяснять одно и то же заново в каждом чате.Memory bank как “папка с простынями контекста, которую агент должен перечитывать перед работой” — почти устаревший паттерн.Rules / рулсы — это инструкции для агента, которые задают рамки его поведения.Например: “используй только pnpm”, “не трогай файлы миграций”, “компоненты называем через PascalCase”, “перед изменением API сначала предложи план”.MCP — это протокол, через который агент подключается к внешним инструментам и данным.Например, к GitHub, Jira, Figma, базе данных, Sentry, файловой системе, внутренним сервисам компании.MCP превращает агента из “чата, который умеет писать текст” в участника рабочего процесса, который может ходить в нужные системы и получать оттуда контекст.Skills / скиллы — это переиспользуемые сценарии работы агента под конкретные задачи.Например: “как делать code review”, “как заводить новый пакет в монорепе”, “как писать тесты в этом проекте”, “как оформлять PR”.Если совсем коротко:Memory bank хранит контекст.Rules задают правила поведения.MCP даёт доступ к инструментам.Skills описывают рабочие сценарии.Использовать агента без них сейчас нет совершенно никакого смысла, качество его работы драматически падает без них. Но нужны ли прям все эти инструменты?Сейчас всё больше фокус смещается в сторону связки rules и skills.Rules играет роль закона: они всегда в силе и задают рамки, которые агент не должен нарушать. Агент держит их в контексте всегда.Skills работают как инструменты: агент знает, что они есть и когда их применят

Композер 2 только вышел, и уже угодил в скандал. Пупупум....

Похоже Composer 2 — это украденная Kimi 2.5Сразу после выхода Composer 2 пользователи заметили что модель на эндпоинте называется kimi-k2p5-rl-0317-s515-fast, а чуть позже пошли (ныне удалённые) шокированные твиты от команды Kimi — по их словам они ничего не знали об использовании Cursor их весов. И раньше ходили слухи что оригинальный Composer был основан на китайской модели — GLM 4.6, так что прецедент такого "ребрендинга" есть, но там ситуация отличается.Дело в лицензии — если GLM лицензирована по MIT, то у Kimi 2.5 лицензия более сложная — подобные к лицензии MIT права она даёт только до 100 миллионов пользователей продукта или 20 миллионов выручки в месяц. То есть тюн GLM не нарушал лицензию оригинальных весов, а тюн Kimi — нарушает.Ситуацию обостряет конфликт Anthropic с авторами Kimi — компания обвиняет Moonshot в использовании более чем 3.4 миллионов запросов для дистилляции. Возможно руководство Cursor решило, что из-за собственных проблем с данными, Moonshot не отважится подать на них в суд и им за это ничего не будет.Достаём попкорн и наблюдаем за ситуацией@ai_newz

Здарова, работяги!Сегодня принес полезный материал для тимлидов и сочувствующих. Уже совсем скоро пройдет митап Dream Teamlead.Не на каждой конфе набирается такой бодрый набор спикеров, как тут. Особенно хочу отметить:• Евгений Антонов(Тимлид Очевидность) — читаю его канал(@general_it_talks), слушаю подкаст — всем рекомендую, очень крутые материалы.• Александр Поломодов — один из лучших каналов(@book_cube) на русском языке(по моему скромному мнению). Рекомендую не только лидам, но и инженерам. Огромное кол-во материалов про лидерство, систем-дизайн, AI и т. д.По традиции, если будете там и захотите пообщаться — пишите в лс