«Лучше перебздеть, чем недобздеть» — часто слышу от людей эту фразу в смысле «лучше перестраховаться». Но есть нюанс :)

Бздеть — это пердеть. А глагол, означающий «проявить бдительность» — «бдеть».

Так что когда пошли в туалет — лучше перебздеть, а когда перестраховываетесь — лучше перебдеть.

Так что бдите!

Вы знали что подменять ответы API (и тело, и заголовки) можно прямо из Chrome Dev Tools? https://developer.chrome.com/blog/devtools-tips-34 Очень удобно для тестирования!

Рассказал, как мы мокаем запросы к REST API в тестах и в Storybook для react-приложений. Как организовать большой набор моков и сделать это type safety:

https://isqua.ru/en/blog/2025/05/17/scalable-mocking-architecture/

Вместо того, чтобы писать посты в блог, перевёл его на Astro

Мой блог четыре года жил на Hugo — генераторе статических сайтов на Go. Он идеально подходит для однотипного контента: удобно задавать категории, шаблоны, Hugo сам генерирует страницы постов, тегов и прочее. Писать просто — markdown. Для добавления кастомных «блочков» есть механизм шорткодов, я даже собрал свои: https://github.com/isqua/hugo-shortcodes

Полгода назад я решил писать посты на английском. У Hugo есть i18n, но она рассчитана на переводы, а не на самостоятельный контент. Пришлось делать две независимые ленты: /blog/ и /en/blog/. Остальные страницы тоже пришлось дублировать. Всё работало, но UX такой себе.

Затем я захотел сделать страницу с проектами. Написал шорткод для карточки проекта, собрал markdown-страницу с ними, отдельно написал шаблон и стили. Работает, но ощущается как «гвозди микроскопом». После 10 лет во фронтенде мозг уже думает в терминах данные+компоненты, а не контент+шаблоны.

После очередного обновления opengraph-превью: картинки с названием cover больше не подхватывались сами для англоязычных постов, у которых не было «оригинала» на русском. Это стало последней каплей.

Я полистал jamstack и снова выбрал Astro — уже использовал его раньше. Он поддерживает markdown, но даёт больше гибкости, компонентный подход, активно развивается и с кучей звёзд.

Но как обычно, больше гибкость — меньше работает из коробки. Например, сущности «блог» там нет — пришлось написать конфиг папок и валидатор для frontmatter.

Работа с картинками не нравится. Когда они вставлены в markdown, всё изи:

![](./team-calendar.png)

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

<img class="wide-image" src="./team-calendar.png" />

Astro перекладывает картинки при сборке, но src у тега img он не находит и не обрабатывает, и при сборке урлы получаются битые.

Долго возился со статьёй про деплой, там есть теги <mark> внутри <pre><code> и astro на таком файле просто падал, пришлось поприседать. В общем, минусы тоже есть.

Чтобы быстрее переехать, я просто перенёс контент, шаблоны и стили. Некоторые фичи пока отложил: нет страниц тегов, rss-лента только с заголовками постов. И превью для соцсетей тоже нет...

Но зато:

— Убрал разделение страниц на ru/en
— Объединил все статьи в одну ленту
— Вывел эту ленту прям на главной
— Получил больше гибкости и контроля

Дальше буду допиливать и причёсывать. Надеюсь, этого решения лет на 5 хватит.

Мои рекомендации теперь такие

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

📖 Вам подойдёт Hugo
— если ваши посты можно написать на (почти) чистом markdown и будет хорошо
— вы терпеть не можете фронтенд
— не планируете кастомизировать визуал и создавать разные виджеты

Напиши в жука

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

Это повышает качество сервисов: когда сталкиваешься с проблемой (или хочешь фичу), очень легко её зарепортить, потому что это под рукой. Не нужно искать ответственных и разбираться куда им писать

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

Вот такое простое решение для связи с пользователями!

Ждите мой код в ваших репозиториях

Для поиска информации я часто использую perplexity.ai (кстати они нанимают). Он даёт ссылки на источники, плюс довольно агрессивно парсит интернет, поэтому выборка очень свежая.

Все же знают как работает AI? Если грубо, ему скармливают огромные массивы текста / кода / картинок и других данных, а при взаимодействии с вами он компилирует все свои знания в какой-то наиболее статистически подходящий ответ на ваш промпт.

То есть чем мы его кормим, то он и выдаёт. Получается, мы теперь генерим информацию не только для людей напрямую, но и для AI, чтобы он потом её как-то переварил и выдал по-новому.

Ну и вот моя статья попала в ai-нтернет: пруф. Пока что выдаётся под довольно профильный запрос, если допустим про typenoscript не упомянуть, то подход из моей статьи перплексити уже не советует.

Так что, может быть, это мой маленький вклад в качество будущего генеренного кода в чьем-нибудь проекте. Вы же пишете тесты?

Как управлять карьерой: Continuous Self Review

В бигтехе раз в полгода-год проходит performance review: оценивают результаты каждого сотрудника, раздают бонусы и повышения. У каждого есть грейд (L5 в Google, E4 в Meta и т.п.), от него зависит зарплата. Вот видео с объяснением процесса, спасибо Антону Сапронову за наводку.

Ревью начинается с того, что вы готовите self assessment — отчёт о своих достижениях за полгода. Важно какую пользу нанёс, а не объём работы типа «закрыл 200 задачек».

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

Ошибка — писать self-assessment в последний момент. Пытаешься вспомнить, чем занимался это время, перечитываешь закрытые таски. Так можно обнаружить, что полгода занимался фигнёй.

Совет: пишите self-assessment всё время. По окончании каждого спринта или хотя бы раз в месяц фиксируйте результаты. Конечно, крупные проекты вы за спринт не закроете. Просто запишите прогресс по ним.

Это помогает фокусироваться на результате и не тратить время на текучку. Если пару спринтов и писать-то нечего — вы копаете не туда. Как в сёрфинге: куда смотришь, туда и едешь.

Чтобы знать, что куда копать, определите цели к следующему ревью вместе с руководителем. Аналогично с повышением: выясните, что делают специалисты следующего грейда и чего вам не хватает, чтобы апнуться.

Также и с резюме: пишите его по ходу работы, а не в момент поиска. При выходе на новую работу планируйте следующий карьерный шаг: это будет повышение здесь, или переход в крутую компанию, или смена трека? Что нужно сделать в ближайший год-два-три, чтобы ваши результаты за это время привели вас в следующую точку?

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

Чё там по state managers

Пошёл глянуть насколько ещё актуально в статьях про управление состоянием использовать примеры на redux (у меня он на текущем проекте). Пока что актуально. Несколько инсайтов с графика:

1. Судя по тренду, скоро Zustand обгонит Redux по загрузкам.

2. Jotai всё никак не обгонит mobx (если считать сумму mobx-react и mobx-react-lite)

3. Recoil, effector и reatom — какие-то нишевые и угасающие тренды. За год число их загрузок не выросло. А на фоне роста лидеров получается, что их доля значительно упала.

Скелетор вернется позже с еще одним неприятным фактом

Так, узнал, короче, что у телеграм каналов должна быть визитка. Ща будет визитка!

Привет! Я Алекс, Senior Software Engineer. В 2014-м пришёл в Яндекс джуном, дорос до тимлида и откатился в разработчики. В 2024-м переехал в Европу, сейчас работаю в стартапах. Стек: React, TypeScript, Node.js.

Официально я фронтендер, но что я только ни делал: крутил nodejs в проде под нагрузкой, мигрировал сервисы из одного облака в другое, отвечал за CI/CD в монорепе на 100+ проектов, писал тулзы и парсеры, оптимизировал перфоманс и переписывал легаси.

Много менторил — и младших коллег на работе, и студентов в HTML Academy. Этот канал когда-то сделал для них, чтобы делиться опытом и полезными материалами. Вот некоторые из них:

🚀 Карьера и работа в команде
— Как управлять карьерой: Continuous Self Review
— Как внедрять изменения: уровни сопротивления
— Работа это не писать код, а решать задачи
— Роли в команде: тесты пишет фронтендер или тестер?
— Как сделать работу интересной
— Как работать с информацией
— Как не продалбываться
— Синдром ученика: не тормозите на старте
— Встречи в одно и то же время


⚛️ Фронтенд
— Убираем лишние эффекты из компонента
— Алиасы для импортов: какие выбрать
— Как задеплоить react-приложения на Github Pages (en)
— Организуем моки бекенда для тестов и сторибука
— Рефакторим вложенные ифаки
— Фундамент CSS — для собеседований и не только
— Pixel Perfect
— БЭМ с точки зрения процессов
— Контрольные точки для media-выражений


📱 Дизайн и UX
— Типографика и вёрстка: как собирать крепкие страницы
— Автофокус: экономим клики
— Повышаем доступность дёшево
— Напиши в жука: как получать фидбек от пользователей


🛠 Инструменты
— Правим код быстрее — базовые фичи IDE
— Подмена ответов API в Chrome DevTools
— Два инструмента для работы с API
— Генератор шума и мурчания


🧠 Задачки
— Почувствуй себя хакером: взрывные головоломки
— Пишем свой reduce
— Упаковка массивов
— Парсинг выражений и длинная арифметика
— Кроссворды с regexp

Подскаст с Алёной делаем 👉 https://news.1rj.ru/str/code_cleanup
Лонгриды публикую в блоге 👉 https://isqua.ru

Приходит ко мне однажды Алёна Батицкая, та самая, из Доки, и говорит «а что, слабо нам видео про рефакторинг выпускать?» и я такой «ну нинаю, ну надо пробовать»

И вот мы что-то пыхтели, снимали 2-часовой рефакторинг приложения, очень занудно вышло.

А потом всё сожгли и выпустили пилотный выпуск на 7 минут про то, как оторвать useState в формах на React 19.

Поддержите нас пожалуйста лайками и репостами в твиттере и linkedin. И конечно смотрите наш выпуск!

https://youtu.be/JdMGSgh9uHA

В моей команде есть несколько ex-google инженеров. От них я узнал, что у Гугла есть публичные (!) гайдлайны по дизайну API. Называется «Google AIPs: API Improvement Proposals»

👉 https://google.aip.dev/

Вот несколько примеров документов:

AIP-193: Errors — формат ошибок, куда писать код ошибки, куда сообщение, локализацию, и как передать доп. информацию.

AIP-234: Batch methods: Update — батчевые ручки. Что должны отвечать синхронные и асинхронные апдейты и как сигнализировать, что только часть данных обновилась успешно. Отдельный поинт что батчевые ручки (и вообще кастомные операции) называются через двоеточие, типа
/users:batchUpdate

AIP-164: Soft delete — удаление и восстановление, в каких API-методах удалённые сущности могут и не могут появляться, и как же их всё-таки получить. И что делать, если восстановление долгое.

Там есть пропозалы и по клиентам для этих API. Короче, интересный справочник!

Толщина рамок в уголках

10+ лет в индустрии, и вот снова неделю крашу кнопки. Файн-тюним дизайн-систему на проекте.

Знаете же эти модные кнопки и плашки с градиентными рамками? Обычно это два элемента: «задний» с градиентным фоном выглядывает из-за «ближнего» элемента с белым фоном (ну или какой там фончик).

Если делать одинаковый border-radius у внутреннего и внешнего элемента, то уголки как бы утолщаются, выглядит не аккуратно. Верхний блочок на скрине, видите?

То ли дело, если уменьшить радиус внутреннего элемента на толщину рамки! Второй блочок на скрине выглядит прилично.

Поясняю в числах:

1. У блока с градиентом радиус 20px, толщина рамки 5px. Тогда у «белого» элемента радиус должен быть 15px.

2. У блока с градиентом радиус 10px, толщина рамки 2px. Тогда у «белого» радиус должен быть 8px.

Код и пример: https://codepen.io/isqua/pen/vEGomyr?editors=1100

Узнали? Согласны? 😁

Мифы про отличия Zustand и Redux

Работаю сейчас с zustand, который уже обогнал redux по загрузкам. Вот что говорят адепты zustand, сравнивая его с redux:

Миф 1: В Zustand можно создавать множество сторов вместо одного!

По факту и правда можно, но в доке Zustand советуют «single store». А если мол ваше приложение большое, можете разделить стор на слайсы.

В redux тоже single store, который можно разделить на слайсы. И в отличие от zustand, есть встроенное решение для динамической подгрузки слайсов, что позволяет делать код-сплиттинг и загружать только нужные слайсы.

Миф 2: В Zustand меньше бойлерплейта!

По факту и правда меньше, пока у тебя стор размером с "counter, increment, decrement". Как только тебе надо обновить поле где-то глубоко в дереве:

updateNestedParam: (value: string) => {
  set((state) => ({
    deep: {
      ...state.deep,
      nested: {
        ...state.deep.nested,
        obj: { ...state.deep.nested.obj, param: value }
      }
    }
  }))
}

В то время как в redux уже давно можно просто:

updateNestedParam: (state: MyState, value: string) => {
  state.deep.nested.obj.param = value
}

Чтобы решить эту проблему документация zustand советует нам immer. На этой библиотеке как раз работает redux, просто она уже встроена. А с zustand нужно писать всё вручную. Есть ещё опция прикрутить immer middleware, чтобы получилось ну-вот-уже-почти-как-в-redux, только вместо одной функции надо две писать:

updateNestedParam: (value: string) => {
  set(state => {
    state.deep.nested.obj.param = value
  })
}

Миф 3: Ура, не нужно использовать Provider!

И правда не нужно. А это точно преимущество? Чтобы написать тесты на компонент, использующий redux, нужен враппер с preloadedState. В Zustand советуют мокать (!) методы самого zustand, чтобы добавить в каждый стор метод очистки, и вызывать это в afterEach — а что если мне в тесте нужен не initialState, а какой-то уже наполненный. Опять всё руками? ЛИБО, внимание, использовать Context API, чтобы предоставить компонентам конкретный инстанс стора. В чём разница с Redux Provider?

Миф 4: Zustand лучше перфоманс!

И показывают бенчмарки на батчевую запись в стор, где в redux используется immer, а в zustand его не добавляют, и пишут тот самый бойлерплейт из мифа №2. Мы точно сравниваем полноценные решения на реальном юз-кейсе? Или подгоняем задачу под ответ?

Я повидал разные проекты. Вопрос производительности библиотек встаёт на масштабах главной страницы Яндекса, где сам код приложения уже оптимизирован донельзя. Проекты поменьше, даже если там сложные графики с 5-летними данными с дневной гранулярностью (зачем), или формы с 200 селектами (зачем), тормозят не из-за стейт-менеджера, а из-за того, как написано само приложение.

Миф 4.1: В Zustand селекторы более гранулярные, именно это влияет на перфоманс!

В zustand можно так:

useMyStore(state => state.very.deep.object.prop)

Но в redux можно точно также:

useSelector(state => state.very.deep.object.prop)

В чём разница? Получили ли мы что-то новое в Zustand, или авторы просто строят очередной Redux?