Лекции по разработке

Полезные и интересные фотографии к предыдущему посту

Съездил в этот четверг на конференцию Yandex Scale.

Все доклады более или менее были нацелены на продажу продуктов Яндекса, которые помогают компаниям внедрять ИИ.
Я думаю, что многие уже слышали об аналоге GitHub — SourceCraft. Помимо этого есть Yandex AI Studio, AI Security Gateway — совместная работа компании SolidLab и Yandex,
YDB — реляционная СУБД от Яндекса.

Естественно, я не успел сходить на все доклады и воркшопы, но доклады, на которых я был, были построены по такому шаблону:
внедрение ии — проблема — решение (в виде продукта от Яндекса).

Некоторые идеи всё равно удалось подцепить и узнать что-то новое для себя, помимо полезного в нынешнее время нетворка с другими айтишниками. Хотя, по правде говоря, в этот раз не был слишком общительным, так как за несколько дней до конференции приболел и не до конца успел «окрепнуть».
Новое:
— Есть OWASP Top 10 специально под LLM; Топ 1 атака — Prompt Injection: примером этого может быть попытка достать секретные данные через запрос в LLM, по типу системного промпта.
— В системах защиты от трафика ботов на сайте используют JS Challenge, не только Captcha. Отправляется небольшой скрипт на клиент, результат выполнения которого затем отправляется на сервер для сверки результата. Если результат сошёлся и уложился в лимитное время, то считается, что это человек.
— Очень-очень большой упор во времена ИИ делается на Security, поэтому Яндекс создали продукт Yandex Security Deck, который с разных сторон решает эту проблему: предотвращает утечку секретов, обнаруживает уязвимости в репозиториях, выявляет лишние права пользователей в системе и т.п. Думаю, можно в своей компании если не подключить такой продукт, так использовать его идеи.

Презентации
Записи докладов

#ai

Достиг 500+ коннектов в LinkedIn.

Кто не знает — это соц. сеть для айти-специалистов. Там регаются, чтобы прокачать нетворк. Есть специальный SSI — Social Selling Index у каждого профиля, который показывает то, насколько часто он будет показан участникам сети. В общем, тут всё как и в жизни — делаешь много, но при этом никого не знаешь и никому об этом не рассказываешь — карьерных возможностей примерно 0. Поэтому всем, кто ещё не завёл свою страничку там, настоятельно рекомендую это сделать.
Ну и можете добавиться ко мне в коннекты.

Напоследок эмпирический лайфхак: добавлять нужно максимум 3-4 человек в коннекты за сессию. Минимальный гэп между сессиями: 4-5 часов. Иначе банят на время возможность делать коннекты.

Итоги зарплатного опроса

Ответов в форме: 19
Медианная вилка: 200-250 тыс. рублей
Наиболее часто встречающийся формат работы: Удалёнка

Вот такая вот статистика. Ответов не так много, чтобы получить какие-то результаты, на которые можно опираться, тем не менее...

Мой сетап Claude Code

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

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

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

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

⚡️ 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

Краткий экскурс в 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

У нас на работе настроены автобилды проектов в МРах, и я недавно заметил, что время пайплайна уж слишком увеличилось: кол-во тестов всё увеличивается и увеличивается, добавляются новые 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