Когда у каждого репозитория есть свой Tx, код может выглядеть чисто, но атомарность всё равно сломается: один Store откатится, другой уже успеет закоммитить изменения.

В статье показан более надёжный вариант для Go-кода: репозитории остаются небольшими интерфейсами, транзакционная логика уезжает в Unit of Work, а сервис работает с готовым набором хранилищ, построенных поверх одного sql.Tx.

Большинство ошибок с памятью в C++ не выглядят как ошибки. Код компилируется, тесты проходят, приложение работает неделями. А потом внезапно появляется Segmentation fault, повреждённая куча или утечка памяти, которую приходится искать часами.

Разберём пять типичных ловушек, в которые регулярно попадают начинающие разработчики.

Ещё несколько лет назад рефлексия считалась нормой для.NET‑приложений. Сегодня Microsoft последовательно выносит всё больше работы из runtime в этап компиляции: JSON‑сериализация, логирование, регулярные выражения, конфигурация и даже тестовые фреймворки всё чаще опираются на source generators.

Разбираемся, почему рефлексия начала сдавать позиции, где кодогенерация уже стала стандартом и что это меняет для разработчиков.NET.

Инфраструктура обычно ломается не в одном месте. За «просто поправить деплой» быстро подтягиваются лимиты Linux, настройки контейнеров, CI/CD, безопасность, маршрутизация, Kubernetes, базы данных и сети ЦОД. Чем больше сервисов и команд, тем важнее видеть не только отдельные инструменты, но и связи между ними.

В этом дайджесте собрали открытые уроки, статьи и курсы по Linux, Docker, Kubernetes, CI, PostgreSQL, сетям и безопасности. Подборка будет полезна тем, кто отвечает за стабильность сервисов и хочет системно закрывать инфраструктурные пробелы.

Если после релиза Android‑приложения вы внезапно получаете краши, утечки памяти и жалобы на пропадающие данные, проблема может скрываться в нескольких строках кода вокруг Activity и Fragment.

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

В C++ часть ошибок выглядит слишком безобидно, чтобы сразу насторожиться: std::move в return, emplace_back «для скорости», перемещение из const, move‑конструктор без noexcept. Код компилируется, тесты могут проходить, а потом внезапно появляются лишние копирования, просадки производительности и странное поведение объектов.

Разберём пять типичных ловушек move‑семантики на небольших задачах и посмотрим, где именно ожидания разработчика расходятся с тем, что реально делает язык.

Лямбды в C++ выглядят безобидно, пока не начинают жить дольше переменных, которые захватили. Висячие ссылки, мёртвый this, копии состояния в потоках и ограничения std::function часто проходят компиляцию без шума, зато потом превращаются в undefined behavior.

Разбираем пять задач на захваты и время жизни, где ошибка прячется не в синтаксисе, а в неверном предположении о том, кому и сколько живёт объект.

Привет, Хабр! Jetpack Compose в 2026 году стал стандартом разработки UI на Android, но в проектах регулярно повторяется одна и та же история: на экране со списком в пару сотен элементов прокрутка идёт рывками, профайлер показывает скачки кадров до 200 миллисекунд, а команда чешет голову и предлагает откатиться обратно на RecyclerView.

Проблема почти всегда не в Compose, а в том, как написан UI: recomposition спроектирован как дешёвая операция, но эта дешевизна работает только при соблюдении ряда правил, которые в документации описаны рассыпанно и часто игнорируются.

Разберём пять ошибок, из-за которых производительность Compose-экранов проседает заметно для глаза, и покажем, как их находить и чинить.

AI‑агенту не нужен прямой доступ к базе, чтобы отвечать на вопросы оператора или вызывать действия в системе. Достаточно дать ему набор управляемых инструментов через MCP.

В статье разбираем, как это выглядит в Spring Boot, где заканчивается простая демка и почему перед продакшеном придётся думать не о магии LLM, а о правах, логах, таймаутах и человеке в контуре.

В SOC реальная атака редко приходит с табличкой «срочно расследовать»: чаще она маскируется под очередное ложное срабатывание, которое уже сотни раз закрывали на автопилоте.

В статье разбираем пять типичных ошибок триажа алертов — от mute шумных правил до закрытий одной строкой «FP» — и показываем, как зрелые команды выстраивают процесс так, чтобы слабый сигнал не терялся в потоке шума.

IBM System/360 выглядит как музейная машина с лампами, тумблерами и памятью на магнитных сердечниках, но внутри это сложная инженерная система с микрокодом, каналами ввода-вывода и десятками скрытых регистров. Симулятор Model 50 позволяет пройти ниже уровня ассемблера и увидеть, как одна машинная команда раскладывается на микрокоманды, управляющие реальным аппаратным устройством.

Иногда сетевой инцидент выглядит как проблема маршрутизации, коммутатора или IPTV‑сервиса, но на деле трафик умирает раньше — внутри сетевой карты. В этой истории разберём, как Intel X710 научилась отбрасывать корректный multicast, почему IGMP‑запросы не спасали ситуацию и как одна правка в драйвере превратила редкий баг в массовую головную боль для инженеров.

Мажорное обновление редко ломает сервис сразу и красиво. Чаще оно оставляет тихую регрессию в сериализации, безопасности, тестах или рантайме — и всплывает уже после релиза.

В этой статье разбираем, как перейти со Spring Boot 3.x на 4.0 и с Java 21 на Java 25 не одним рискованным прыжком, а как управляемой инженерной процедурой: с промежуточной остановкой, проверками, канарейкой и понятным планом отката.

eBPF часто подают как кнопку «ускорить Kubernetes», но на практике всё сложнее. Он действительно помогает уйти от тяжёлых цепочек iptables, снизить задержки и получить наблюдаемость ближе к ядру Linux. Но стоит перейти от L4 к L7, включить глубокую инспекцию трафика или mTLS — и бесплатная магия заканчивается. Разбираем, где eBPF меняет правила игры, а где всё ещё приходится считать оверхед.

Разобираем восемь антипаттернов, которые ловят даже сеньоров: от галлюцинированных зависимостей и slopsquatting до context rot и архитектуры, которая по кускам деградирует в God Service. На каждый — симптом, причина, последствия и конкретное исправление. Плюс готовый чек‑лист ревьюера AI‑кода, который можно забрать и повесить рядом с шаблоном PR.

Снаружи всё выглядит технологично: пайплайн анализирует изменения, линтер находит ошибки, а ИИ оставляет замечания к коду. В реальном процессе разработчики продолжают вручную обновлять файлы, применять исправления и заполнять метаданные.

В этой статье разберём четыре сценария псевдоавтоматизации и рассмотрим, где система должна переходить от комментариев к действиям.

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

В статье разберём, какие сенсоры действительно помогают находить регрессии, а какие создают ложное чувство уверенности.

В 1960-х орбиту «Союза» рассчитывал прибор, внутри которого вместо процессора работали шестерни, кулачки и дифференциалы. Разбираем устройство навигационного компьютера «Глобус»: как он показывал положение корабля, прогнозировал точку посадки и почему впечатляющая механическая вычислительная система всё же оставалась привязана к одной орбите.

Типовая ситуация: Terraform-конфигурация выглядит привычно, а ИИ-агент экономит время на рутинных операциях. Но потерянный state-файл и один terraform destroy способны за минуты снести прод вместе с базой данных и снапшотами.

В этой статье разберем реальный инцидент, восстановление через AWS Support и защитные механизмы, которые появились в инфраструктуре после аварии.

ROC‑AUC вырос с 0,871 до 0,874 — модель стала лучше или вам просто повезло с разбиением?

Разберём, почему прирост на третьем знаке часто оказывается шумом, как измерить разброс метрики и сравнивать модели так, чтобы «улучшение» не исчезло на свежих данных.