Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?

Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным.

GitHub Actions давно стал одной из самых опасных точек в supply chain. Ошибка в workflow может открыть доступ к секретам, токенам и инфраструктуре — именно так развивались атаки на tj-actions, Ultralytics и Trivy.

В статье разберем, как работают уязвимости вокруг pull_request_target, expression injection и сторонних actions, и почему «просто CI» сегодня требует полноценной threat model.

В статье разберём, как именно раннер решает, что тест прошёл, почему .then без return выполняется уже после теста, почему try/catch в async‑тесте — частый источник ложного зелёного, что не так с forEach и setTimeout внутри тестов и какие инструменты не дают тесту соврать. Примеры на Jest, но контракт у Mocha, vitest и прочих тот же.

Привет, Хабр!

SUM() OVER (ORDER BY ...) часто выглядит как очевидный способ посчитать нарастающий итог, пока в данных не появляются одинаковые значения ключа сортировки. В этот момент результат начинает «прыгать», LAST_VALUE возвращает текущую строку, а запрос формально остаётся корректным.

В статье разбираем скрытую причину таких сюрпризов — кадр оконной функции: как база подставляет его по умолчанию, чем ROWS отличается от RANGE и какие детали стоит проверять, чтобы аналитические SQL‑запросы считали именно то, что вы ожидали.

Dataclasses появились в Python 3.7 и быстро стали стандартом: меньше бойлерплейта, чем у обычных классов, проще, чем attrs, и не требуют зависимостей. Выглядят настолько просто, что кажется, что ломаться там нечему. Но у них есть три ловушки, которые не видны при написании.

Когда продакшен падает в три часа ночи, строка ERROR Something went wrong не помогает никому. В статье разбираем, почему привычные текстовые логи быстро превращаются в шум при реальной нагрузке, как перейти на structured logging, зачем каждому запросу нужен request_id и как настроить нормальные JSON‑логи в Python и Go без лишней инфраструктуры.

Когда модель промышленной аналитики начинает показывать отрицательный расход электроэнергии или теряет 15% сырья на ровном месте, проблема часто лежит глубже качества данных и выбора алгоритма. SCADA, MES и ERP могут хранить корректные числа, но вкладывать в них разный смысл: по времени, единицам измерения, границам операции и правилам учета.

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

Kubernetes, Go, LLM, нагрузочное тестирование, observability, AI‑агенты, CTE, API Gateway и безопасность — в мае у OTUS много открытых уроков для тех, кто хочет быстро погрузиться в актуальные IT‑темы без долгого выбора курса.

Собрали расписание на 18–28 мая: можно выбрать направление под свои задачи, посмотреть формат обучения и понять, какую тему стоит разобрать глубже.

Модель может показывать 95–99% accuracy и при этом не решать задачу: особенно если редкий класс важнее всего для бизнеса. В статье разбираем, почему accuracy ломается на несбалансированных данных, как читать precision, recall и F1, зачем смотреть PR‑кривую и confusion matrix, а также как подбирать порог классификации с учетом стоимости ошибок.

Почему добавление второго consumer«а в очередь может привести к двойным списаниям? Разбираем на реальном кейсе: как один Topic стоил компании 312 дублей за час. »

Сравниваем поведение JMS, Kafka и RabbitMQ, показываем, почему ни одна очередь не даёт exactly‑once из коробки, и как идемпотентность, Dead Letter Queue и правильный выбор канала (команды vs события) делают интеграции надёжными.“

Готовые схемы, продакшен‑код на Java и чек‑лист, который стоит применить прямо сейчас!

Flaky‑тесты сложно ловить даже привычными инженерными методами: они ломают CI, подрывают доверие к автотестам и часто воспроизводятся только тогда, когда уже никто не понимает почему. Кажется логичным поручить такую задачу LLM: показать модели код теста и попросить определить, насколько он подозрительный.

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

Первая статья из цикла о каналах обмена сообщениями. Разбираем архитектурные дилеммы, конкурирующих потребителей, message storm, гарантированную доставку и лучшие практики команд, работающих с JMS и Kafka.

Представьте: вы запускаете генеративную AI‑фичу в проде. Всё работает как часы. А через месяц получаете иск, потому что ваша модель насоветовала клиентам того, чего не существует в реальных политиках компании.

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

Запутались в многоэтажных SQL‑запросах? Обобщённые табличные выражения (CTE) — тот инструмент, который превращает лапшу из JOIN и подзапросов в читаемый, модульный код.

Разберем на реальных примерах из FinTech и e‑commerce, как разбивать сложную логику на цепочку простых шагов, использовать CTE в UPDATE/DELETE, строить рекурсии для иерархий и избегать ловушек оптимизатора в PostgreSQL.

Пятница, до релиза осталось два часа, а на финальной проверке всплывают баги: зависание после оплаты, профиль без обязательного телефона, расхождение в отчёте на несколько рублей. Для QA в такой момент важна не паника и не формальное «блокер/не блокер», а быстрая оценка последствий: кто пострадает, что сломается, есть ли обходной путь, видит ли команда проблему в логах и можно ли безопасно откатиться.

В статье разбираем три типичных предрелизных дефекта и показываем, как принимать решение о выпуске без гадания на severity.

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

В этой статье — практический маршрут, как за один рабочий день собрать локальный прототип ИИ‑агента на Ollama и n8n: развернуть модель, связать её с автоматизацией, написать рабочие промпты и при необходимости подключить RAG по внутренней базе знаний.

Когда организация растет, процессы быстро превращаются в набор разрозненных схем: где‑то BPMN, где‑то регламенты, где‑то таблицы со статусами и ответственными. Но в какой момент становится понятно, что эти схемы плохо отвечают на главный вопрос: какую ценность мы создаем, для кого и какие способности бизнеса реально поддерживают этот поток?

В статье разбираем, как построить Value Stream Map с точки зрения корпоративной архитектуры: определить заинтересованные стороны, задать границы потока, выделить этапы создания ценности, связать их с бизнес‑способностями и использовать карту как основу для проектирования целевого состояния организации.

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

В статье разбираем, где ИИ действительно помогает продажам в 2026 году: ускоряет подготовку к звонкам, адаптирует follow‑up, анализирует разговоры, помогает с квалификацией лидов, КП и отработкой возражений — и где его лучше не подпускать к клиентскому общению без контроля человека.

Вайб‑кодинг выглядит безобидно, пока речь идет о скриптах, лендингах и небольших сервисах. Но что будет, если попробовать с его помощью собрать проект для ПЛИС: с I2S, FIFO‑буфером, DSD, S/PDIF, UART, PSRAM и отладкой на реальном железе?

Я проверил это на практике и почти без знания Verilog прошел путь от мигающего светодиода до рабочего FIFO‑реклокера для цифрового аудио. Получилась история о том, где ИИ действительно помогает инженеру, где уверенно ведет в тупик и почему в какой‑то момент все равно приходится доставать логический анализатор.

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

В статье разбираем, как шестерёнки, сельсины и физическая модель небесной сферы заменяли цифровые вычисления.