- Продукт5 мин
Feature flags и A/B-эксперименты: выкатывать безопасно и измерять
Feature flags (флаги возможностей) — простая идея с большими последствиями: вы отделяете момент, когда код попадает на прод (деплой), от момента, когда он начинает работать для пользователей (включение фичи). Это меняет модель релизов. Что это даёт. (1) Kill switch — мгновенно выключить проблемную фичу без отката деплоя; в отличие от redeploy, занимает секунды. (2) Канареечный релиз — включить на 1% трафика, посмотреть на метрики, расширить до 100%. (3) A/B-эксперименты — случайно разделить пользователей на группы, измерить эффект от изменения. (4) Бета для части пользователей. (5) Релиз по подписке (early access). Категории флагов: release-флаги (короткоживущие, пока фича раскатывается), experiment-флаги (привязаны к A/B-тесту, живут пока идёт эксперимент), ops-флаги (kill switch, долгоживущие), permission-флаги (роль/подписка пользователя). Что выбрать. SaaS-решения (LaunchDarkly, ConfigCat) — быстро стартуют, но платят за объём и вводят внешнюю зависимость в критический путь. Open-source (Unleash, Flagsmith) — разворачиваются у себя, без vendor lock-in. Своя реализация — соблазн, но легко недооценить: кеширование на стороне клиента, консистентность между сервисами, аудит, rollout-проценты. Главный риск — технический долг флагов: забытые флаги от давно выпущенных фич превращают кодовую базу в лабиринт `if (flag)`. Дисциплина: expiration-дата на release-флагах, регулярный аудит и удаление «мёртвых» веток кода.
- #feature-flags
- #ab-testing
- #release
- #experimentation
- UI/UX5 мин
Дизайн-системы: когда они окупаются, а когда это оверинжиниринг
«Дизайн-система» — ещё одно слово, которое стало означать слишком многое: от набора Figma-стиков до полноценного продукта с командой и релизами. Разберём, что это такое и когда окупается. Дизайн-система — это не UI-кит. UI-кит (набор кнопок и инпутов) — её часть, но система шире: это набор принципов, токенов дизайна (colors, spacing, typography как переменные), переиспользуемых паттернов, документации, гайдлайнов по применению, и процесса поддержки. Цель — единый визуальный и UX-язык между командами и продуктами, чтобы кнопка выглядела и вела себя одинаково везде. Когда окупается. (1) Несколько продуктов или платформ (web+mobile+desktop) в одной компании — без системы они расходятся в деталях. (2) Много команд — единая система убирает дублирование и споры «как сделать карточку». (3) Долгий жизненный цикл — дизайн-система окупается через 1–2 года, на коротких проектах не успеет. Когда это оверинжиниринг. Маленький продукт с одной командой — хватит общего файла стилей и набора компонентов. Стартап в поиске продуктовой ниши — UI ещё не устоялся, инвестиции в систему уйдут в мусор после следующего пивота. Главный риск: дизайн-система — это отдельный продукт со своим бэклогом, версионированием, депрекациями. Если нет людей, готовых её поддерживать (дизайн + разраб), она превратится в «заброшенную библиотеку», которой никто не пользуется. Признак здоровой системы — её используют добровольно, потому что это быстрее, чем делать своё.
- #design-system
- #ui-kit
- #design-tokens
- #product
- UI/UX5 мин
Accessibility для разработчика: WCAG, ARIA, контраст
Доступность (accessibility, a11y) часто воспринимают как «заботу о малом меньшинстве», но это не точно. По данным ВОЗ, около 16% населения мира имеют ту или иную форму инвалидности — это сотни миллионов потенциальных пользователей; кроме того, доступность помогает и всем остальным: людей с временными травмами, на ярком солнце, в шумной среде. А в юрисдикциях вроде ЕС и США для ряда продуктов она обязательна по закону (European Accessibility Act 2025, ADA). Что реально делать разработчику. WCAG (Web Content Accessibility Guidelines) — стандарт с тремя уровнями соответствия (A, AA, AAA); для большинства коммерческих сайтов ориентир — AA. Семантический HTML решает 70% проблем: `<button>` вместо `<div onclick>`, `<label>` для инпутов, правильные заголовки (`<h1>` → `<h2>` иерархией), `<nav>`, `<main>`, `<section>`. Screen reader читают DOM-дерево, и семантика — их основной канал. ARIA — там, где семантики не хватает (кастомные виджеты, динамические регионы): `aria-label`, `aria-expanded`, `aria-live`. Правило №1 ARIA: «первое правило ARIA — не использовать ARIA», если есть нативный HTML-элемент. Клавиатурная навигация: всё доступно через Tab, виден focus-ring (не убирайте `outline` без замены). Контраст: минимум 4.5:1 для обычного текста по WCAG AA — проверяйте через WebAIM Contrast Checker. Конкретные грабли: `display:none` (скринридер не читает), `tabindex` больше 0, картинки без `alt`, только цвет для различения статусов.
- #accessibility
- #a11y
- #wcag
- #aria
- #frontend
- Менеджмент6 мин
Технический долг: как его считать, обсуждать с бизнесом и гасить
Термин «технический долг» Уорд Каннингем ввёл именно как метафору с деньгами: вы берёте в долг (быстрое решение), чтобы быстрее выпустить фичу, и платите проценты (замедление следующих релизов) до тех пор, пока не вернете долг (рефакторинг). Как любая метафора, она ломается, если её понять буквально. Разбираем по слоям. (1) Революционный (осознанный) долг — «мы знаем, что это костыль, выпускаем к сроку, занесём в бэклог». Это нормальный инструмент, если долг осознан и запланирован к возврату. (2) Эволюционный (неосознанный) долг — код писался нормально, но требования изменились, и архитектура перестала им соответствовать. Не вина автора, а свойство развивающейся системы. (3) Гнилостный долг — код низкого качества, который копируется и плодится. Самый дорогой. «Проценты» технического долга измеряются не в строчках, а в скорости: сколько времени занимает новая фича в этой части кода, и насколько это дольше, чем могло бы быть. Как обсуждать с бизнесом: не «нам надо отрефакторить» (бизнесу всё равно), а «эта фича сейчас занимает 5 дней из-за запутанного модуля; рефакторинг снизит до 1 дня, и каждая следующая фича в этой области будет дешевле». Перевод в деньги и срок окупаемости — единственный язык, который понимает стейкхолдер. Главное правило погашения: никогда «не переписать всё с нуля» (классическая ловушка — переписывание идёт годами, продукт отстаёт от рынка). Гасить постепенно, оплачивая долг в каждой затронутой фиче (boy scout rule).
- #technical-debt
- #refactoring
- #product-management
- #engineering
- Менеджмент5 мин
Agile, Scrum, Kanban: перестаём путать философию, фреймворк и доску
«Мы работаем по Agile» — фраза, за которой может скрываться что угодно: Scrum, Kanban, просто отсутствие процесса или хаос под благовидным названием. Разберём, где у каждого своё место. Agile — это не методология, а зонтичный термин из Agile Manifesto (2001), четыре ценности и двенадцать принципов. Суть: люди и взаимодействия важнее процессов, работающий софт важнее документации, сотрудничество с заказчиком важнее контракта, готовность к изменениям важнее следования плану. Это философия, а не инструкция. Скрам — конкретный фреймворк поверх этой философии: фиксированные роли (Product Owner, Scrum Master, команда), артефакты (бэклог продукта, бэклог спринта, инкремент), события (спринт 2–4 недели, дейли, планирование, обзор, ретроспектива). Жёсткая структура, предсказуемые ритмы, хорошо подходит для продуктов с устойчивой командой и предсказуемой каденцией релизов. Канбан — система потоков, а не итераций: визуализация работы на доске, лимиты work-in-progress (WIP), управление потоком, непрерывное улучшение. Нет обязательных ролей и спринтов — задачи берутся в работу по мере освобождения слотов. Хорош для support-команд, операций, там, где работа приходит неравномерно. Scrumban — гибрид. Главное отличие: Scrum планирует партиями (спринт), Kanban — по потоку (как только есть место). Что часто ломается: превращение Scrum в театр (стендапы без смысла, ретро для галочки), copying Scrum-церемоний без ценностей, смешивание Kanban-«потока» со спринт-«партиями». Выбор зависит от характера работы, а не от моды.
- #agile
- #scrum
- #kanban
- #project-management
- #methodology
- Инфраструктура5 мин
Логи, метрики, трейсы: что такое observability и почему трёх хватает
Observability — модное слово, за которым стоит простой принцип: вы должны уметь ответить на любой вопрос о системе, не отправляя программиста дебажить на проде. Три источника данных покрывают 95% задач, и важно понимать, какой когда. Метрики (metrics) — числа во времени: CPU, память, RPS, latency-перцентили, счётчики ошибок. Дёшевы хранить, агрегируются, основа алертов и дашбордов. Стек: Prometheus (сбор), Grafana (визуализация). Отвечают «что не так и когда». Логи (logs) — дискретные события с контекстом: «пользователь X получил 403 в 12:03». Дорогие в хранении, ищутся по тексту, нужны для расследования конкретного инцидента. Стек: Loki, ELK. Отвечают «что именно произошло». Трейсы (traces) — путь одного запроса через все сервисы со временем на каждом шаге. Незаменимы в микросервисах: видно, что 80% времени запрос потратил в сервисе `billing`, из них 70% — в SQL-запросе. Стек: OpenTelemetry, Jaeger, Tempo. Отвечают «где тормозит и почему в этом конкретном вызове». Правило трёх: метрики говорят, что есть проблема → трейсы показывают, где в системе она возникла → логи раскрывают детали конкретного события. OpenTelemetry — индустриальный стандарт, объединяющий сбор всех трёх сигналов через единый API; снимает vendor lock-in. Антипаттерн: логировать всё подряд «на всякий случай» — превращает логи в шум и стоит дорого.
- #observability
- #metrics
- #logs
- #traces
- #opentelemetry
- Инфраструктура4 мин
Kubernetes для разработчика: Pod, Deployment, Service, Ingress без страха
Kubernetes пугает объёмом, но для разработчика (не девопса) нужен небольшой набор понятий, на котором держится 90% работы. Разбираем по линии «как ваше приложение живёт в кластере». Pod — минимальная единица, один или несколько контейнеров с общим network namespace и volumes. Обычно один контейнер на Pod (sidecar-паттерн — исключение). Не создавайте Pod напрямую — он не перезапустится при падении. Deployment — контроллер, который держит N реплик Pod и следит, чтобы всегда было ровно N живых. Падение контейнера — Deployment поднимет новый. Обновление образа — rolling update без простоя. Это рабочая лошадка. Service — стабильная сеть поверх Pod, у которых IP-адреса меняются. Service даёт постоянный DNS-имя и балансирует трафик между Pod с подходящими лейблами. Без Service клиенты не нашли бы ваше приложение. Ingress — вход HTTP-трафика в кластер: один Ingress-контроллер (nginx, traefik) терминирует TLS и маршрутизирует по доменам/путям на разные Service. ConfigMap и Secret — конфигурация и секреты, монтируются как переменные окружения или файлы. Что читать каждый день: `kubectl get pods` (статус), `kubectl describe pod <name>` (почему упал), `kubectl logs <pod>` (логи), `kubectl get events` (последовательность событий). Mental model: вы пишете Deployment+Service, остальное (оркестрация, перезапуск, масштабирование) делает K8s.
- #kubernetes
- #k8s
- #pod
- #deployment
- #ingress
- Инфраструктура4 мин
Docker-слои и кеш: почему образ весит 1.5 ГБ и как ужать до 150 МБ
Docker-образ размером в гигабайт для микросервиса на 500 строк кода — обычное дело, и почти всегда это следствие непонимания слоёв и кеша. Разбираем механику. Каждая инструкция в Dockerfile (RUN, COPY, ADD) создаёт слой — копию файловой системы поверх предыдущего. Образ — это стек слоёв. Свойство, на котором держится всё: слой кешируется и переиспользуется, только если изменились его входы (команда + копируемые файлы). Отсюда главное правило порядка инструкций — сначала то, что меняется редко (установка зависимостей), потом то, что часто (исходники). Классическая ошибка: COPY . /app перед npm install — любой чих в любом файле инвалидирует кеш, и зависимости переустанавливаются заново на каждой сборке. Правильно: сначала COPY package.json + lock-файл, RUN install, потом COPY остального кода. Дальше — multi-stage build, главный инструмент сжатия. В одном образе компилируем (с JDK, Maven, исходниками), во второй стадии копируем только готовый артефакт в runtime-образ с одной JRE. Результат: образ с компилятором весил 1.2 ГБ, runtime — 200 МБ. Ещё ужать: distroless-образы (без shell, без пакетного менеджера — только runtime) или alpine (musl вместо glibc, ~5 МБ база, но бывают проблемы с совместимостью). Практический разбор Dockerfile «было/стало» с цифрами на каждом шаге, и почему `docker image history` — первый инструмент для поиска жира.
- #docker
- #dockerfile
- #multi-stage
- #distroless
- #caching
- Базы данных5 мин
SQL vs NoSQL в 2026: когда реляционная база всё ещё лучший выбор
«NoSQL убил реляционные базы» — слоган 2012 года, который не подтвердился. В 2026 SQL по-прежнему доминирует, а NoSQL занял конкретные ниши. Разбираем по типам хранилищ и их реальным кейсам. Реляционные SQL-базы (PostgreSQL, MySQL) — транзакции, ACID-гарантии, схема, JOIN-ы, сложная доменная модель. По-прежнему дефолт для большинства приложений. Ключ-значение (Redis, DynamoDB) — кеш, сессии, счётчики, очереди — там, где важна скорость, а не сложные запросы. Документные (MongoDB, Couchbase) — документы с переменной структурой, CMS, каталоги; но на сложных JOIN-ах и транзакциях по нескольким документам начинают буксовать, и многие в итоге возвращаются к SQL. Колоночные (ClickHouse, Cassandra) — аналитика на терабайтах, времянные ряды, логи; OLAP-нагрузки. Графовые (Neo4j) — связи, рекомендации, фрод-детекшн. Два развития последнего времени сняли часть холиваров. (1) JSONB в PostgreSQL — реляционная база научилась хранить и индексировать JSON, и многие «нам нужен MongoDB»-кейсы закрываются одним PostgreSQL. (2) NewSQL (CockroachDB, Google Spanner, YugabyteDB) — горизонтально масштабируемые базы с ACID и SQL-диалектом, убирают главную боль классических реляционных (вертикальное масштабирование). Правило выбора: не выбирайте базу под «моду», выбирайте под характер данных и запросов. Стартуйте с PostgreSQL — закроет 90% задач.
- #sql
- #nosql
- #postgresql
- #mongodb
- #newsql
- Базы данных5 мин
Уровни изоляции транзакций: грязное чтение, фантомы, snapshot
«Грязное чтение», «неповторяющееся чтение», «фантом» — термины из стандарта SQL, которые на собеседовании повторяют, но редко понимают, как они выглядят в коде. Разбираем все четыре уровня изоляции с конкретными сценариями из двух параллельных транзакций. READ UNCOMMITTED — можно прочитать чужие незакоммиченные изменения (dirty read), на практике почти не используется; в PostgreSQL фактически недоступен и ведёт себя как READ COMMITTED. READ COMMITTED (дефолт в PostgreSQL и Oracle) — видит только закоммиченные данные, но неповторяющееся чтение разрешено: один и тот же SELECT внутри транзакции может вернуть разные строки, если другая транзакция успела закоммитить UPDATE. REPEATABLE READ — один SELECT стабилен на протяжении транзакции, но допускает фантомы (новые строки, добавленные другой транзакцией); в PostgreSQL/MySQL InnoDB этот уровень дополнительно защищает и от фантомов через MVCC, что идёт дальше стандарта. SERIALIZABLE — транзакции ведут себя так, будто выполняются строго последовательно; самая безопасная, но самая медленная, при конфликте одна транзакция упадёт с serialization failure и её придётся повторить. Под капотом — MVCC (multi-version concurrency control): каждая транзакция видит снапшот данных, читатели не блокируют писателей, и наоборот. Цена — старые версии строк хранятся, пока есть активные транзакции, что раздувает таблицу (нужен VACUUM в PostgreSQL). Практический выбор: большинство систем работает на READ COMMITTED, банковские операции — REPEATABLE READ/SERIALIZABLE.
- #sql
- #transactions
- #isolation
- #mvcc
- #acid
- Базы данных5 мин
Индексы PostgreSQL: B-tree, GIN, BRIN, частичные — и почему EXPLAIN врёт
«Добавил индекс, а запрос не ускорился» — классика. Разбираем, какие индексы бывают в PostgreSQL и почему не всегда помогают. B-tree — дефолт, работает для =, <>, BETWEEN, ORDER BY, уникальных ограничений. Hash — только точное равенство, в PostgreSQL не переживает crash до 10 версии (сейчас WAL-logged), применяется редко. GIN — для полнотекстового поиска, JSONB, массивов; тяжёлый на запись, быстрый на поиск. GiST — геометрия, диапазоны, тоже полнотекстовый. BRIN — для огромных таблиц с физически упорядоченными данными (логи по времени), крошечный по размеру, но приблизительный. Дальше — продвинутые паттерны. Частичный индекс (`WHERE active = true`) индексирует только нужные строки, экономит место и ускоряет частые запросы. Покрывающий индекс (`INCLUDE` колонки) позволяет полностью обслужить запрос из индекса, не ходя в таблицу (index-only scan). И главное — как читать EXPLAIN. Простой `EXPLAIN` показывает план по оценкам планировщика, которые могут быть ошибочны из-за устаревшей статистики. `EXPLAIN ANALYZE` реально выполняет запрос и показывает время каждого узла — только так видно, где индекс не используется или сканирование медленнее, чем ожидал planner. Почему индекс не сработает: функция на колонке (`WHERE LOWER(name) = ...` — нужен функциональный индекс), OR с разными колонками, несовместимый тип (`’123’` против числового столбца).
- #postgresql
- #indexes
- #b-tree
- #gin
- #explain
- Фронтенд3 мин
Utility-типы TypeScript, которые экономят часы: Record, Omit, ReturnType
Большинство разработчиков на TypeScript знают `interface` и `type`, но не используют встроенные utility-типы — а они убирают горы дублирования и багов синхронизации. Разбираем рабочий набор. `Partial<T>` — все поля опциональны (для форм редактирования, PATCH-запросов). `Pick<T, Keys>` и `Omit<T, Keys>` — выделить или убрать поля, вместо ручного копирования интерфейса, которое рассинхронизируется при изменении оригинала. `Record<K, V>` — словарь вместо `Record<string, User>` или, что хуже, `any`. `ReturnType<F>` и `Parameters<F>` — вывести тип из функции, чтобы не дублировать сигнатуру. Дальше — mapped types (`{ [K in keyof T]: ... }`) и условные типы (`T extends U ? X : Y`), из которых и собраны все встроенные utility-типы. С их помощью `Partial` буквально это `[K in keyof T]?: T[K]`. Практические кейсы: типизация API-клиента по ответам бэкенда без ручного написания интерфейсов, иммутабельные версии через `Readonly`, react-пропсы, выведенные из компонентов. Антипаттерн: навешивать utility-типы слоями, пока тип становится нечитаемым — иногда проще выписать обычный интерфейс.
- #typescript
- #utility-types
- #generics
- #mapped-types
- Фронтенд4 мин
Выбор стейт-менеджера без религии: useState, Zustand, Redux
«Какой стейт-менеджер выбрать?» — вечный вопрос, на который обычно отвечают любимым инструментом. Разберём по типам состояния, а не по фреймворкам. (1) Локальный UI-стейт (открыто ли меню, значение инпута) — useState/useReducer, точка. Не нужно тянуть Redux ради одного поля. (2) Серверный стейт (данные с API, кеш, инвалидация) — это отдельная категория, и для неё React Query / SWR / RTK Query решают то, что Redux/Zustand не решают хорошо (рефетч, кеш, состояние загрузки, дедупликация запросов). Не храните серверные данные в глобальном сторе вручную. (3) Глобальный клиентский стейт (тема, авторизация, настройки UI) — тут Zustand или Jotai покрывают 90% случаев за минимумом бойлерплейта, без экшенов/редьюсеров. Redux с Redux Toolkit по-прежнему оправдан: большие команды с жёсткими соглашениями, сложная логика обновления, потребность в middleware (саги, devtools с time-travel). Антипаттерны: дублирование серверных данных в клиентском сторе, прокидывание всего через Context (ре-рендер всех потребителей), один гигантский стор на приложение. Фреймворк выбора: что это за данные → кто их источник → как часто меняется.
- #react
- #state-management
- #zustand
- #redux
- #react-query
- Фронтенд4 мин
React Server Components: что реально меняют и когда выбирать
React Server Components — самая непонятная фича React с 2023 года, и вокруг неё много тумана. Разбираем чётко. Главное отличие: RSC — это не SSR. SSR рендерит HTML на сервере один раз при запросе и отдаёт статичную страницу; RSC рендерят часть дерева компонентов на сервере постоянно, передают клиенту особый формат (не HTML), и эти компоненты никогда не попадают в JS-бандл. Отсюда свойства: серверный компонент не может использовать useState/useEffect/handlers (он неhydrate’ится), зато может напрямую ходить в БД и читать файлы без отдельного API — никакой сериализации туда-сюда. Клиентский компонент (с "use client") — это привычный React. Граница между ними задаётся в коде, и её легко нарушить (попытка передать функцию из серверного в клиентский упадёт). Где боль: экосистема библиотек ещё не вся адаптирована, отладка сложнее, ментальная модель «что где исполняется» требует привыкания. Когда выбирать: проекты с тяжёлой статикой и админками поверх БД — да; SPA-приложения с богатым клиентским состоянием (редакторы, дашборды) — RSC мало что дают, классический CSR по-прежнему норма.
- #react
- #rsc
- #server-components
- #nextjs
- #ssr
- Фронтенд5 мин
Reconciliation в React: как reconciler решает, что перерисовать, и зачем key
React быстро рендерит за счёт виртуального DOM — фраза, за которой стоит конкретный алгоритм reconciliation. Разбираем, что на самом деле происходит между изменением состояния и обновлением экрана. Зачем нужно второе дерево в памяти и как diff-алгоритм за O(n) сравнивает старое и новое (а не O(n³), как в общем случае — благодаря трём допущениям про типы элементов, ключи и порядок). Отдельно — ключевые правила reconciler-а: смена типа элемента разрушает поддерево (поэтому нельзя менять div на p в одном месте ради стиля); списки без key получают индекс и ребиндятся при любой перестановке; key должен быть стабилен и уникален, а не индекс массива. Где люди теряют перфоманс: создание новых функций-обработчиков в render, нестабильные объекты как props, отсутствие memo — и почему это не всегда нужно лечить. Честный разговор про то, что reconciliation не бесплатен и когда стоит помогать ему memo/useMemo/useCallback.
- #react
- #reconciliation
- #virtual-dom
- #render
- #performance
- Языки5 мин
Под капотом ArrayList и HashMap: capacity, load factor и O(n)→O(1)
Коллекции Java многие используют на автомате, но «HashMap даёт O(1)» — это упрощение, за которым стоят условия и граничные случаи. Разбираем внутренности двух главных коллекций. ArrayList: единственный `Object[]` под капотом, capacity против size, рост в 1.5 раза, почему добавление в конец — амортизированное O(1), а вставка в середину — O(n), и при чём тут `System.arraycopy`. HashMap: бакеты по хешу, load factor 0.75 и порог расширения, обработка коллизий цепочками, и важное — переход в красно-чёрное дерево при длинной цепочке (с Java 8), что спасает от вырождения в O(n) при плохом хеше или атаке. Отдельно — что ломает «O(1)»: собственный ключ с плохим hashCode, высокая доля коллизий,.ConcurrentHashMap и сегменты. Практические следствия — когда задавать initial capacity осмысленно, почему дефолтный load factor не всегда оптимален, и как не наступить на `ConcurrentModificationException`.
- #java
- #collections
- #hashmap
- #arraylist
- #internals
- Языки5 мин
Почему Spring Boot стартует 8 секунд и как это лечить
«Spring Boot тяжёлый и долго стартует» — слышал каждый. Но за общим местом стоит конкретный набор причин, и каждая лечится по-своему. Разбираем, на что уходят секунды при старте: classpath-сканирование в поисках `@Component`, автоconfiguration сотен `@ConditionalOnClass`, разогрев Hibernate (построение метамодели, валидация сущностей), проксирование бинов через CGLIB. Дальше — три уровня оптимизации, от простого к радикальному. (1) Ленивая инициализация и `@Lazy` — бесплатно убирает старт того, что не нужно сразу, но падает первый запрос. (2) CDS (Class Data Sharing) и AOT-обработка Spring 6 — сокращает время загрузки классов, работает с JIT. (3) GraalVM native-image — старт за десятки миллисекунд, но ценой ограничений (reflection, build-time), и это меняет модель деплоя. Где это критично (serverless, FaaS, масштабирование по нулю) и где лишнее (долгоживущий сервис на сервере). Честные цифры старта из замеров сообщества, а не из маркетинга.
- #spring-boot
- #java
- #startup
- #graalvm
- #native-image
- Языки3 мин
Records, sealed и pattern matching: современная Java без бойлерплейта
Java последних релизов реально изменилась: то, что раньше занимало 60 строк (класс с полями, конструктором, геттерами, equals/hashCode/toString), теперь пишется одной строкой через `record`. Разбираем по порядку. Records — что генерирует компилятор, как работают компоненты, компактные и канонические конструкторы, когда record уместен, а когда лучше обычный класс. Sealed-классы (`permits`) — как закрыть иерархию и зачем это нужно компилятору и pattern matching. Pattern matching: `instanceof` без приведения, switch по типам с `case Foo f ->`, guard-условия, и как всё вместе даёт алгебраические типы данных в стиле Scala/Kotlin. Сравнение «было/стало» на скучном примере с формой заявки, где visitor-паттерн схлопывается в один switch. Что ещё не дотянуло (деструктуризация в произвольных местах) и куда движется язык.
- #java
- #records
- #sealed
- #pattern-matching
- #modern-java
- Языки3 мин
Stream API глубже: collect, reduce, flatMap и ловушки parallel-потоков
После `filter/map/collect` у многих складывается впечатление, что они освоили Stream API — но это верхушка. Разбираем то, на чом спотыкаются: `collect` и готовые `Collectors` (groupingBy, partitioningBy, joining, teeing) против ручной свёртки через `reduce` — когда какой; `flatMap` для разворачивания вложенных структур и почему его часто путают с `map`; short-circuiting (`findFirst`, `anyMatch`) и как он экономит проход. Отдельно — `parallelStream`: почему «просто добавь parallel» почти никогда не ускоряет код, какой ForkJoinPool под капотом, когда общая очередь бьёт по latency, и в каких случаях параллельный поток реально оправдан (CPU-bound над большими данными, без I/O). С примерами кода и типичными ошибками — автоупаковка примитивов, side effects в лямбдах, нарушение ассоциативности в reduce.
- #java
- #stream-api
- #functional
- #parallel
- #collectors
- Языки4 мин
Виртуальные потоки Java: чем отличаются от обычных и когда профит
Виртуальные потоки Java (virtual threads, JEP 444) обещают «миллионы потоков на одну JVM» — но за цифрой стоит конкретный механизм. Разбираем, чем virtual thread отличается от платформенного: кто реально крутит код (carrier-поток из ForkJoinPool), как JVM паркует виртуальный поток на блокирующем I/O и возвращает carrier другому, и почему «миллионы» — это про память, а не про CPU. Где прирост честный: I/O-bound нагрузки (HTTP-серверы, обращения к БД) — да; CPU-bound вычисления — нет, тут выиграют обычные потоки. Ловушки: `synchronized` на мониторе (pinning, до Java 24), `ThreadLocal`, пулы соединений. Сравнение с реактивным стеком (WebFlux) — когда Loom снимает сложность, а когда реактивщина всё ещё оправдана.
- #java
- #virtual-threads
- #loom
- #concurrency
- #jvm
- Карьера8 мин
Как выбрать направление и язык с учётом AI
AI меняет не то, *какой* язык учить, а то, *что* в нём ценить. Разбираем честно, что умеют Copilot и агентные среды, а где их потолок: шаблонный код — да, доменная логика и архитектура — нет. Новые критерии выбора — строгая типизация (читать код стало важнее, чем писать), богатая экосистема (LLM обучались на GitHub, популярные стеки знает лучше). Короткий разбор Python, TypeScript, Java/Kotlin, Go, Rust в эпоху AI; направления, которые AI усиливает, а не заменяет (ML, архитектура, DevOps, embedded, security); практический фреймворк из трёх кругов и антипаттерны («выучи промпт-инжиниринг вместо программирования» — нет). Выбирайте не язык, а область — язык подберётся под неё.
- #карьера
- #ai
- #языки программирования
- #выбор стека
- #copilot
- Эволюция1 мин
Эволюция JVM: от Java 1.0 до наших дней
Java Virtual Machine пережила за 30 лет несколько революций — и большинство из них остались за кадром, потому что «просто работает». Разбираем эволюцию по эпохам: ранний HotSpot и его последовательные GC; появление G1 и почему он стал дефолтом; эксперименты с модульностью (Project Jigsaw, Java 9) и как это изменило библиотеки; записи (records), switch expressions, pattern matching — как язык догонял современные тренды; low-latency GC — Shenandoah и ZGC с паузами меньше миллисекунды; и главное современное направление — GraalVM и нативные образы (native-image), которые переворачивают представление о том, что «Java тяжёлая». Что было маркетингом, а что реально изменило разработку.
- #java
- #jvm
- #history
- #gc
- #graalvm
- Карьера1 мин
Как расти в карьере разработчика
Что отличает middle от senior, а senior от staff — и почему дело не в количестве выученных фреймворков. Разбираем реальный рост: переход от «решил задачу» к «спроектировал систему»; как ответственность за решения и их последствия меняется с грейдом; soft skills, которые важнее новых технологий (коммуникация, код-ревью, менторство, умение спорить с аргументами); как выбирать проекты, которые растят, а не те, где ты просто закрываешь таски; синдромы самозванца и выгорание; когда стоит менять команду, а когда — учиться там, где есть. Без иллюзий про «выучил X — стал сеньором».
- #карьера
- #soft-skills
- #mentorship
- #senior
- Пайплайны1 мин
Как устроен CI/CD: от коммита до продакшена
Что на самом деле стоит за аббревиатурой CI/CD и почему это не про конкретный инструмент (GitHub Actions, GitLab CI, Jenkins), а про конвейер. Разбираем по шагам: что запускается на каждый коммит (lint, unit-тесты, сборка артефакта); стадии и когда что выполняется; изоляция через контейнеры и раннеры; тестовые окружения (staging, QA) и как код попадает из одного в другое; стратегии деплоя (rolling, blue-green, canary) и зачем они нужны; что такое артефакт и immutable deploy; как откатываться, когда что-то сломалось на проде. Практический разбор анатомии пайплайна.
- #ci-cd
- #devops
- #deploy
- #github-actions
- Системный дизайн1 мин
Подготовка к собеседованию по базам данных
Что реально спрашивают на собеседовании по базам данных — не теорию множеств, а прикладное: как работают транзакции и что такое ACID; B-tree и hash-индексы, когда индекс замедляет, а не ускоряет; уровни изоляции и блокировки (shared/exclusive, pessimistic/optimistic); мёртвые блокировки и как их находить; нормализация до 3НФ и когда осознанно денормализовать; виды JOIN и разница nested loop / hash / merge; чтение `EXPLAIN` и оптимизация медленных запросов. Шпаргалка по темам, которые стоит повторить перед собеседованием — структурированно, без воды.
- #sql
- #базы данных
- #индексы
- #транзакции
- #собеседование
- Языки5 мин
Java vs Node.js: кто сколько ест памяти
Запускаем одинаковый HTTP-сервис на Spring Boot и на Express — и видим разницу в RSS не на 10–20%, а в разы. Java спокойно держит 250–400 МБ сразу после старта, Node.js укладывается в 40–70 МБ. Разбираем, откуда берутся эти сотни мегабайт: метаспейс и JIT-кеш JVM, поколения объектов и `-Xmx`, поколенческий GC V8 и его лимиты. И главное — почему на холодном старте Node выигрывает, а под высоким RPS «дорогая» Java часто оказывается дешевле в пересчёте на запрос. Практические лимиты (`-Xmx`, `--max-old-space-size`), когда выбирать serverless, а когда — жирный долгоживущий инстанс.
- #java
- #nodejs
- #jvm
- #v8
- #memory
- #gc