17 июня в Москве будет «день Фронтенда» от Яндекса. Отличная возможность для студентов-выпускников попробовать влиться в коллектив.

#frontend #ai

- Злые марсиане о том, как получать удовольствие от работы программисту в эпоху ИИ
- Опять злые марсиане о том, почему не всегда нужно выбирать React для веб-приложения
- Антон Непша о том, как забыть об использовании useMemo, useCallback и React.memo
- Почему, возможно, не надо использовать скилл от Гугла для веб-разработки
- Как продвинуть свой сайт в поисковой выдаче ИИ

Помогает ли айти-образование в айти?

Недавно на работе общались с коллегами со смежной команды по поводу роли образования в карьере программиста.
Сам я, по крайней мере раньше, считал, что нужно учиться много и упорно для того, чтобы чего-то добиться в карьере. Образование поможет сформировать «образ» человека, добавит логики в мышление, с помощью чего человек сможет принимать более правильные решения для достижения своей цели. Будь то карьерный рост, становление кем-либо at all: семьянином, строителем дома, просто хорошим человеком.
Но часто начал замечать, что образование обесценивается в глазах людей. Не только программистов, но сейчас нам интересны только они. Люди не хотят идти в магистратуру, аспирантуру, да и получать знания на бакалавриате, потому что это не поможет им вырасти в карьере.
При этом я могу сказать, что некоторые дисциплины, которым меня обучали в бакалавриате и магистратуре, помогают мне как минимум готовиться к собеседованиям: ООП, Assembler, объектно-ориентированное проектирование, базы данных, front-end программирование на React, да даже философия мне помогает более структурировано смотреть на некоторые события в своей жизни. Того же Ницше взять с идеей развития человека. Или популярный ныне стоицизм. Но все эти знания человек мог получить и без образования и учителей, которые помогали бы ему решать трудности, благодаря чему он бы намного дальше зашёл в изучении материала. Не помню, как называется такая стратегия обучения, пусть будет — on-demand. Типа изучаем то, что нужно лишь в текущий момент, так как знаний в мире слишком много и изучить всё и подготовиться ко всему трудно. Что ж, может, эта стратегия, действительно, работает.
В основном, исходя из своего опыта, а мой опыт строится на двух компаниях: Ispring, Travelline — айти-образование может помочь человеку устроиться на первую работу, или, в целом, на работу, так как знания, как я уже упоминал, могут пересекаться + компании очень охотно нанимают стажёров и джунов с локальных вузов. Есть очень много примеров, да и не только из Йошкар-Олы, из Владимира, из Москвы, как люди попадают на стажировки, работы через ВУЗы.

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

У нас на работе настроены автобилды проектов в МРах, и я недавно заметил, что время пайплайна уж слишком увеличилось: кол-во тестов всё увеличивается и увеличивается, добавляются новые stages в пайплайн. Возникла идея как-то уменьшить время сборки, поразмыслив вместе с ИИ, пришёл к новой для меня технологии — BuildKit cache mounts.

Суть технологии

Обычный docker build кэширует слои. Проблема в том, что слой со сборкой (RUN npm run build) инвалидируется при любом изменении исходников — то есть в каждом реальном МРе. Мб, прикрутить кешью?

BuildKit решает это через cache mount:

RUN --mount=type=cache,target=/app/node_modules/.cache npm run build

Такой mount подключает папку кэша только на время шага. Она живёт НЕ внутри слоя образа, а в отдельном кэш-сторе демона. Отсюда два свойства:

1. Кэш переживает инвалидацию слоя. Шаг пересобирается, а накопленный кэш остаётся на месте.
2. Стор общий на агенте. Это не «кэш одного МРа» — любая сборка на том же раннере читает и пишет в один стор, и разные МРы переиспользуют кэш друг друга.

Куда прикрутил

Кэш сам по себе ничего не ускоряет — нужен инструмент, который делает инкрементальную работу через папку-кэш. У меня таких оказалось два.

webpack. Включил cache: { type: 'filesystem' } и примонтировал папку кэша. webpack перестал гонять babel и минификацию по неизменённым модулям. Замер на агенте: около -2 минут на тёплой сборке.

jest. Он не запускает .ts/.tsx напрямую — сначала транспилирует каждый файл через ts-jest в JS, а это фактически прогон компилятора TypeScript. Кэш этого jest по умолчанию пишет в системный tmpdir, который в контейнере одноразовый. Перенёс cacheDirectory в node_modules/.cache и примонтировал тем же mount. Теперь на тёплой сборке транспилируются только изменённые тест-файлы.

Корректность: почему это не врёт на CI

Наш раннер делает свежий git clone на каждую сборку — у всех файлов новые mtime. Я думал, что это обнулит кэш. Но и webpack (в production) и ts-jest хешируют кэш по КОНТЕНТУ файла, а не по времени. Контент тот же — хэш тот же — кэш попадает.

Что кэшируется, а что нет

- Кэшируется дорогое: транспиляция и минификация. Тесты при этом выполняются каждый раз — экономия на компиляции, не на прогоне.
- SCSS-модули webpack в кэш не сериализует, так что стили пересобираются всегда.

Результат

Значимое сокращение времени сборки, у нас получился результат от 2 до 5 минут. Результат зависит от проекта, поэтому у вас уменьшение может быть ещё бОльшим.

Грабли

- Нужен DOCKER_BUILDKIT=1 и директива # syntax=docker/dockerfile:1.4, иначе RUN --mount падает.
- Стор надо чистить, иначе растёт бесконечно: docker builder prune --filter type=exec.cachemount --filter until=72h (удаляет только простаивающее 3+ дня).
- Кэш локален для агента. Новая виртуалка — потеря пользы от кэша.

Полезные материалы

- Cache mounts: https://docs.docker.com/build/cache/optimize/#use-cache-mounts
- RUN --mount reference: https://docs.docker.com/reference/dockerfile/#run---mounttypecache
- webpack persistent cache: https://webpack.js.org/configuration/cache/
- jest cacheDirectory: https://jestjs.io/docs/configuration#cachedirectory-string

#fullstack

- Новые изменения в npm v12, и как к ним подготовиться
- Всё-таки с React Compiler не забываем про мемоизацию
- Сжатая история фронтенда в хронологическом порядке
- В целом интересный сайт про тестирование фронтенда. Есть полезная статья на тему тестирования React

Краткий экскурс в Helm и k8s

На работе сейчас решаю довольно-таки непростую фулстек-задачу, в рамках которой нужно спроектировать и закодировать highload-систему.
Многие архитектурные решения в компании обусловлены тем, как уже принято. А для просовывания данных приложению через кубернетес у нас принято использовать Helm.
Приходится разбираться с новыми для меня технологиями: и Kubernetes, и Helm.

Helm в двух словах:
Берёт YAML шаблоны + параметры из values.yaml → собирает готовые манифесты → отправляет в Kubernetes.
YAML stands for Yet Another Markup Language (Ещё Один Язык Разметки).
Без него приходится YAML файлы для каждого окружения писать вручную, что не удобно.

Основные понятия в Helm (с англ. «руль») и Kubernetes (с древнегреческого «рулевой»):
Chart — папка с шаблонами kubernetes-манифестов, файлом Chart.yaml (метаданные) и файлом параметров (values.yaml), который будет использоваться для наполнения как раз-таки этих шаблонов.
Release — chart, натянутый на кластер.
Кластер — набор узлов (машинок), на которых запущены поды, а также узел управления.
Узел управления занимается оркестрацией кластера.
Под — один или несколько запущенных контейнеров приложения.

👍 — уже давно знал, что такое Helm
❤️ — хочу продолжения темы деплоя в k8s
🤔 — впервые слышу про Helm

#fullstack

Подробнее о Helm

В продолжение последнего поста решил подробнее рассказать, что есть Helm, почему это пакетный менеджер.
Helm — помощник kubernetes.
Когда мы работаем с kubernetes, то нам приходится конфигурировать то, как у нас кластер будет развёрнут.
Кластер, ещё раз — это набор узлов. Рабочий узел — набор подов. Под — запущенный контейнер. Контейнер — запущенное приложение.
И вот таких конфигураций много, и каждую нужно вызывать отдельно через команду kubectl (kube-control).
Для того, чтобы это всё не делать, умные люди придумали Helm.
Есть некий чарт — пакет, который содержит шаблоны и значения, которые нужно подставить в эти шаблоны.
И далее, через команду helm install, этот пакет запускается и разворачивается в кубер с нужными конфигурациями.
Для обновления конфигураций, если изменились какие-то значения, нужно использовать команду helm upgrade.

Пример конфигурационных файлов Helm:

Структура:

my-app/
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
└── service.yaml

Chart.yaml — паспорт чарта:

apiVersion: v2
name: my-app
version: 1.0.0
appVersion: "2.4.1"

values.yaml — конфигурация:

replicas: 3
image:
  repository: nginx
  tag: "1.25"
port: 80

templates/deployment.yaml — шаблон:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }} — тянется из параметра команды helm install
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: app
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          ports:
            - containerPort: {{ .Values.port }}

templates/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
spec:
  selector:
    app: {{ .Release.Name }}
  ports:
    - port: {{ .Values.port }}
      targetPort: {{ .Values.port }}

Запуск:

helm install my-app ./my-app/

Обновление:

helm upgrade my-app ./my-app/

#fullstack

Мой сетап Claude Code

Иногда спрашивают, как я работаю с AI-ассистентом в коде. Вот мой набор:

📚 Context7 (MCP)
Подтягивает актуальную документацию библиотек прямо в контекст.

🧠 Serena (MCP)
Семантическая навигация по коду через LSP: найти символ, все ссылки на него, переименовать по всему проекту. Ассистент перестаёт грепать вслепую и начинает видеть структуру кода. Экономит токены.

🎭 Playwright (MCP)
Ассистент сам открывает браузер, кликает, заполняет формы, делает скриншоты. Использую для отладки фронтенда.

⚡️ Superpowers
Система «скиллов» — пошаговых методик для типовых задач: брейншторм, TDD, дебаг по научному методу. По-моему, самый простой плагин, реализующий подход SDD. Использую для реализации проработанных задач, по которым уже есть требования и чётко очерченные границы.

🪨 Caveman
Режим общения без воды, без «Конечно, я с радостью помогу!». Экономит токены. Использую для генерации описаний MRов и экономии токенов.

🚀 GSD (Get Shit Done) или BMAD (Breakthrough Method for Agile AI-Driven Development)
Набор агентов для больших фич: исследование → роадмап → план → исполнение → верификация. Каждый этап — это отдельный агент со своей зоной ответственности.
Использую для проектирования больших эпиков.

🦀 RTK (Rust Token Killer)
CLI-прокси, который сжимает вывод команд (git, тесты, линтеры) перед отправкой в контекст. Экономия 60–90% токенов на рутинных операциях.

На всё это я никакие бенчмарки не запускал, поверил создателям на слово, что плагин/mcp реально экономит токены. Сам я использую подписку за 100 долларов и ещё никогда не упирался в лимиты, чтобы иметь потребность в экономии.

Какие полезные плагины/mcp вы используете в работе?

#ai

Уже примерно как 3 недели выкладываю шортсы на ютуб-канал, в которых разбираю вопросы карьеры и программирования. Если интересно — можете туда подписаться и смотреть!
Когда-то делал тут опрос на тему для подкаста: я всё-таки нашёл человека из Ispring, с которым можно поговорить на тему ИИ. Скоро на этом же канале выйдет подкаст.

На работе мы генерируем описания ПРов через ИИ. Столкнулся с тем, что некоторые команды делают это неправильно, из-за чего описания не читаются.
Я создал проект по описанию ПРов в июле 2025 года в ТЛ и до сих пор его сопровождаю, так что есть некоторый опыт того, как это нужно делать правильно:

— Не больше 3 пунктов описания того, что сделано в ПРе
— Если изменения не могут уместиться в 3 пункта, то нужно генерировать диаграммы/картинки

Всё. Остальное никто не читает.

#ai

Каким образом надо внедрять ИИ в компании? Личный опыт и опыт компании.

— Если все заняты бизнес-задачами и бизнес не готов выделять разработчиков отдельно в ИИ-проекты, то ничего не получится. Таким образом проекты будут пилиться во вне рабочее время, с костылями, кустарно, без продолжения, замеров результата.
В нашей компании только 2 проекта смогли пройти сквозь весь этот отсев. 2-й проект вывели в свет совсем недавно.
— Если делается ИИ-проект, то делать его нужно предварительно планируя масштабировать на всех. Иначе получится опять же кустарный пет-проект, который умрёт.
— Если делаете ИИ-проект, то всё-таки заверните его в докер, даже если в вашей компании единый стек и будет казаться, что удобнее написать проект на таком же стеке, так как внедрение будет проще. Всё равно найдутся проекты, в которых будет другой стек, интеграцию с которыми придётся пилить через контейнеризацию.

#ai

Записали подкаст с Захаром, программистом из Ispring, на тему «ИИ в IT-компаниях».

PS: Новую камеру уже заказал

#ai

https://youtu.be/U7iYqgRaWm0?si=VpXmwVzq9yZhwKem

Навеяло написать мне про альтернативные издержки, которые терпит человек, придерживаясь какого-либо мнения.
Всплыл недавно интересный кейс для примера — мой друг захотел купить себе айфон дешевле его рыночной стоимости, при этом риск скама не рассматривался. Далее начались разборки с одним продавцом, и вторым. Были потеряны деньги. Друг усвоил урок, что есть скам и некоторые вещи лучше покупать напрямую в магазине, чтобы не терять кучу бабла.
Допустим, айфон стоил 60к рублей. Урок стоил 60к рублей. А что если бы продавец оказался честным? И в следующий раз друг захотел бы заказать не айфон, а мак? Урок бы стоил уже ~200к рублей.

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

Рассмотренный кейс:
издержки: 60к рублей. альтернативная прибыль: 200к рублей.
издержки: 0 — не наебали. альтернативные издержки: 200к рублей.
Альтернативная прибыль — потенциальная выгода от корректировки плана достижения целей.
Альтернативные издержки — упущенная выгода.

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

Какие у вас есть мифы, в которые вы верите? И как думаете, какие альтернативные издержки вы из-за них терпите?

Кто не в курсе — прямо сейчас проходит конференция Deep Tech Night
Приходите послушать её с моими комментариями: https://www.youtube.com/live/LjgFhWhjhNc?si=EAISAZjOpV33B1Ws

Итак, друзья!
Вашему вниманию — зарплатный опрос программистов и тех, кто вырастает из программистов. Просьба всем, кому интересно узнать качественные результаты, внести свой вклад в прохождение. Опрос упростил до 4 кликов — ничего вводить не надо + всё анонимно.

Результаты через 2 недели — 21 сентября.

https://forms.gle/E3LVz1nsfkQAybCj6