Хвост инженера

Автор: Сергей Андржеевский · ScrumTrek

Сергей Андржеевский выступал на Ag;)eDays 2011 — одной из ранних российских Agile-конференций. Доклад старый, но вопрос, который он разбирает, не устарел: как работают XP-практики в условиях, когда команда разделена географически и работает на внешнего заказчика.

Офшорный проект — это специфический контекст. Разные часовые пояса, заказчик, который не сидит рядом, контрактная модель, которая создаёт стимулы скрывать проблемы, а не решать их. XP создавался для команды в одной комнате с заказчиком рядом. Андржеевский рассказывает, что из XP работает в офшорном контексте, что требует адаптации, а что — предположение, которое офшор разрушает принципиально. Центральный тезис: парное программирование и TDD в офшорном контексте — это не способ быстро работать, это способ поддерживать качество без прямого контроля. Заказчик не видит код — он видит результат. Дисциплина XP-практик создаёт доверие через предсказуемость результата.

Кому смотреть: тимлидам и менеджерам в распределённых…

Автор: Владимир Протасов · Habr

Владимир Протасов — разработчик с опытом highload-систем, выступал на HighLoad++ 2016 с докладом об OpenResty. Доклад из тех, что не устаревают: OpenResty существует с 2009 года, но основная масса разработчиков по-прежнему думает о нём как о «Nginx с Lua» и недооценивает, что именно это означает.

OpenResty встраивает LuaJIT прямо в worker-процессы Nginx и даёт хуки на каждую фазу обработки запроса: до получения заголовков, после, перед отправкой ответа, при ошибке. Это не «скрипт, вызываемый Nginx» — это Lua, исполняемый с той же производительностью, что и сам Nginx, без форков, без HTTP-запросов к отдельному backend, без копирования тела запроса туда-обратно. Авторизация, rate limiting, трансформация ответов, маршрутизация на основе тела запроса — всё это можно делать без выхода из nginx-контекста.

Протасов разбирает конкретные паттерны: как подключить Redis через cosocket API (без блокировки event loop), как кешировать сессии, как писать обработчики для нестандартных…

Автор: Дмитрий Евдокимов · VK Cloud

Дмитрий Евдокимов — CTO Luntry, платформы безопасности для Kubernetes. Luntry строится поверх Kubernetes API, поэтому понимание KRM у него не теоретическое — это основа продукта. Доклад с VK Kubernetes Conference.

Kubernetes Resource Model — это абстракция, которую легко пропустить за привычными деплойментами и сервисами. Суть в том, что Kubernetes — это не оркестратор контейнеров, а universal control plane для управления любыми ресурсами. Всё, что можно описать как «желаемое состояние + текущее состояние + reconciler», может стать Kubernetes-ресурсом. Это означает, что KRM применима не только к подам, но и к облачным ресурсам, сетевым политикам, конфигурациям безопасности и вообще к любому объекту с жизненным циклом. Everything-as-Code здесь не лозунг, а архитектурное следствие: если ресурс существует в Kubernetes API, он автоматически версионируем, аудируем, управляем через GitOps.

Евдокимов объясняет, как устроены CRD (Custom Resource Definitions), как писать операторы, и…

Автор: Олег Казаков · Spectr

Олег Казаков — CTO в Spectr, выступал на митапе Spectr в сентябре 2025 года. Spectr — продуктовая IT-компания, и Казаков рассказывает о внедрении observability изнутри: не как консультант, а как человек, который жил с проблемой и решал её в работающем продукте.

«Тушение пожаров» — это диагноз: команда реагирует на инциденты после того, как они случились, вместо того чтобы видеть деградацию заранее. Observability меняет режим работы с реактивного на проактивный. Казаков разбирает, как это сделать без enterprise-бюджета: стек Prometheus + Loki, который покрывает 90% потребностей продуктовой команды, и подход к внедрению в существующий продукт без остановки разработки. Центральный тезис: не нужен Datadog за сотни тысяч долларов в год. Нужны правильные метрики, алерты, которые срабатывают до того как пользователи пишут в поддержку, и процесс, который команда реально использует.

Кому смотреть: CTO и техлидам продуктовых компаний, у которых observability — это «когда-нибудь потом» или…

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях, объясняет практики разработки коротко и без академической перегруженности. Этот выпуск — девятиминутный обзор Extreme Programming (XP).

Большинство разработчиков знают отдельные XP-практики: TDD, парное программирование, непрерывная интеграция. Многие применяют их в изоляции. Суть XP в том, что эти практики спроектированы как система: TDD даёт быструю обратную связь, парное программирование распределяет знание о коде, CI гарантирует, что интеграция не накапливает долг. Убери одно — другие становятся менее ценными. XP существовал до Agile Manifesto (Кент Бек опубликовал книгу в 1999-м), и многие принципы манифеста 2001 года прямо из него вышли. При этом XP как целостная система встречается в командах гораздо реже, чем Scrum, — хотя технические практики у него сильнее.

Кому смотреть: разработчикам, которые применяют TDD или CI по отдельности и хотят понять, зачем Кент Бек сложил всё это в одну методологию.

Из этого можно взять в…

Автор: Антон Солдатов · Podlodka Podcast

Антон Солдатов работал в IPONWEB — высоконагруженном ad-tech — и участвовал в разработке внутреннего форка LuaJIT. Это человек, который использовал Lua не в хобби-проектах, а в production-системах под серьёзной нагрузкой.

Lua занимает странное место в списке языков: его редко выбирают для нового проекта «с нуля», но он встроен буквально везде — в Nginx (OpenResty), Redis, Neovim, World of Warcraft, Roblox. Причина одна: Lua проектировался как язык для встраивания в хост-приложение, а не как самостоятельный рантайм. Он крошечный (библиотека меньше 300 KB), быстрый в встраивании, и позволяет дать пользователю возможность расширять систему без доступа к её исходникам. Антон объясняет, почему именно Lua, а не Python или JS, стал де-факто стандартом для этой задачи — и почему альтернативы проигрывают в этой конкретной нише.

Кому смотреть: разработчикам, которые строят платформы или приложения с пользовательской расширяемостью — плагины, скрипты, пользовательские правила…

Автор: Дмитрий Польшаков · DSR Corporation RU

Дмитрий Польшаков — Lead Software Engineer в DSR Corporation и преподаватель курса Embedded Systems Lab. Он объясняет профессию изнутри, без рекламной шелухи.

Embedded-разработчик пишет код, который живёт в микроконтроллере без операционной системы — или с RTOS, где каждый байт памяти и каждый такт процессора на счету. Главное отличие от прикладной разработки не в языке (C и C++ встречаются в обоих мирах), а в ментальной модели: здесь нельзя «добавить памяти» или «перезапустить сервер». Код должен работать предсказуемо в реальном времени, часто на железе за два доллара. Это меняет всё — как пишешь, как отлаживаешь, как думаешь об ошибках.

Кому смотреть: разработчикам из веба и бэкенда, которые задаются вопросом, что находится «ниже» операционной системы — и стоит ли туда спускаться.

Из этого можно взять в работу: спроси себя — ты понимаешь, что происходит между нажатием кнопки и изменением пикселя на экране? Embedded — это о том, чтобы владеть этим стеком снизу…

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях и процессах, объясняет сложные концепции коротко и структурированно. Это видео — обзор Agile: не реклама и не критика, а попытка разобраться, чем Agile является на самом деле.

Большинство команд, которые «работают по Agile», работают по Scrum или Kanban — и это не одно и то же. Agile — это набор ценностей и принципов, сформулированных в Манифесте 2001 года. Он не описывает церемоний, ролей и спринтов. Scrum — это уже конкретный фреймворк, одна из возможных реализаций. Путаница между ними ведёт к тому, что команды «внедряют Agile» через ретроспективы и стендапы, не меняя при этом отношения к изменениям и клиенту — и потом удивляются, почему не работает.

Кому смотреть: разработчикам и тимлидам, которые участвуют в agile-церемониях, но не понимают, зачем они существуют. А также тем, кто слышит «мы agile-команда» и хочет проверить это утверждение на прочность.

Из этого можно взять в работу: спроси на следующей ретроспективе: «Какую…

Автор: Александр Алексеев · Папочка Разработки

Александр Алексеев ведёт канал о .NET-разработке, где объясняет архитектурные концепции без академической перегруженности. Это видео — один из лучших русскоязычных входных точек в DDD: без Эванса на 500 страниц, но с сохранением сути.

Domain-Driven Design принято считать сложным — и чаще всего путают причину сложности. Дело не в паттернах: агрегаты, репозитории, value objects можно выучить за вечер. Настоящая сложность DDD в другом: он требует, чтобы разработчики говорили на одном языке с теми, кто понимает предметную область. Без этого единого языка — Ubiquitous Language в терминах Эванса — код отражает не бизнес-логику, а то, как разработчик её понял. В больших системах этот разрыв со временем становится главным источником багов и рефакторингов.

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

Ко…

Автор: Артём Шумейко · YouTube

Артём Шумейко — Python-разработчик и преподаватель, специализируется на backend. В коротком видео показывает на живом примере и с реальными цифрами, как FastAPI обрабатывает больше тысячи запросов в секунду.

Асинхронность часто объясняют через «это быстро» — и это неточная формулировка, которая потом мешает. FastAPI не делает CPU-код быстрее. Он устраняет простой: пока один запрос ждёт ответа от базы данных или внешнего сервиса, event loop берёт следующий. При I/O-bound нагрузке это даёт кратный прирост пропускной способности без дополнительных потоков и без накладных расходов на переключение контекста. Видео полезно тем, что показывает разницу измеримо, а не концептуально.

Кому смотреть: Python-разработчикам, которые пишут async/await по инерции или «потому что так принято в FastAPI», но не могут объяснить, почему это работает и когда это не поможет.

Из этого можно взять в работу: найди в своём коде async-функцию, которая делает блокирующий вызов — requests.get() вместо httpx, time…

Автор: Алексей Смирнов · Podlodka Podcast #448

Уводим «Хвост инженера» в сторону безопасности. Этот выпуск Podlodka — о том, как уязвимости приходят в проект через обычные зависимости и наши привычки.

Алексей Смирнов основал CodeScoring — платформу для анализа open source зависимостей. Разбирает то, что обычно выпадает из разговоров о безопасном коде: угрозы, которые приходят не из вашего репозитория.

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

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

Из этого можно взять в работу: посмотри, что происходит с зависимостями, когда меняется мейнтейнер. XZ Utils показал, что именно здесь и нужно смотреть в первую очередь.

Автор: Сергей Константинов · SDCast

Сергей Константинов написал книгу «The API» — бесплатную, в открытом доступе, на русском и английском. До этого разрабатывал API в Яндекс.Картах. В подкасте разбирает то, что в этой теме обычно остаётся за кадром обычных туториалов.

Центральная идея, которую Константинов проводит через всю книгу: закон больших чисел работает против автора API. Если концепцию или сигнатуру вызова можно понять неправильно — её неизбежно будут понимать неправильно всё больше людей по мере роста популярности API. Поэтому нейминг в публичном API — это не вопрос стиля и не задача code review. Это архитектурное решение: каждое имя, вышедшее наружу, становится обязательством.

Отсюда — его подход к проектированию через пирамиду контекстов. Сначала — зачем вообще нужен этот API, какую задачу он решает. Потом — абстракции и ответственность сущностей. И только в конце — конкретная номенклатура. Потому что цена ошибки на разных уровнях сильно отличается: «если исправить плохое именование сравнительно…

Автор: Пётр Зайцев · Организованное программирование | Кирилл Мокевнин

Пётр Зайцев — сооснователь Percona. Это компания, которая появилась потому, что многим командам оказалось недостаточно корпоративной траектории MySQL — и кто-то должен был «сделать лучше». Зайцев видел MySQL изнутри и снаружи, в момент сделки с Oracle — и потом наблюдал, как это повлияло на весь рынок.

Разговор — о том, как технический выбор переплетается с бизнес-моделью. Почему MySQL оказался в ситуации конфликта интересов. Как из него выросла MariaDB. И почему на этом фоне Postgres — с его чистой open source-историей и отсутствием единого корпоративного владельца — стал выглядеть не только сильнее технически, но и надёжнее как стратегический выбор.

Зайцев не читает слайды. Он рассказывает историю — как человек, который жил внутри неё.

Кому смотреть: всем, кто выбирает хранилище данных и думает только в категориях «что быстрее» или «что популярнее». Особенно тем, кто строит продукт на 5+ лет и ни разу не задавался вопросом: а кто…

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

«Хвост инженера» — это кураторский канал редакции Territory о разработке без кликбейта и нейрослопа. Мы будем собирать хорошие видео и доклады: такие, где есть авторская мысль, практика, опыт и уважение ко времени зрителя.

Видео остаются у своих авторов и смотрятся через официальный YouTube-плеер. Territory добавляет редакционный контекст и помогает хорошим материалам быть найденными.

Не всё, что попало в рекомендации YouTube, заслуживает внимания. Но многое ценное туда как раз не попадает.

Будем вытаскивать.