- Новые изменения в 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