Программирование *

Случалось мне работать с CV: запускаешь сорокаминутное видео, YOLO честно находит людей, машины, собак. На двадцатой минуте падает сеть или, что хуже, камера наблюдения выходит из строя. Перезапускаешь. Модель снова смотрит те же кадры, снова инференс, трекинг ID, пошла пахота GPU…

Так продолжаться не может — подключаю кеширование.

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

Привет! Меня зовут Сергей, я тимлид iOS-команды в Банки.ру. В разработке уже 11 лет — успел поработать и на аутсорсе, и в продуктовых финтех-компаниях.

Если вы iOS-разработчик и планируете внедрять Live Activities в своё приложение — эта статья для вас. Особенно если обновления LA у вас триггерятся на бэкенде, а не в коде приложения. Мы наступили на несколько граблей, нашли неочевидное решение и хотим сохранить вам пару недель отладки.

Каждые четыре недели Яндекс Браузер переезжает на новую версию Chromium. Обычный пользователь этого не замечает, но для команды разработки каждый такой переход — это более тысячи конфликтов кода и, как правило, несколько тысяч ошибок компиляции.

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

Мы хотели сократить объём этой рутинной работы и освободить время команды для развития браузера. Для этого автоматизировали две самые трудоёмкие части процесса: разрешение конфликтов и починку компиляции.

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

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

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

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

Главный тормоз корпоративных ИИ‑проектов в 2026 году это не выбор модели, не мощности GPU и не цена за токены. Это банальный обмен данными между корпоративными системами. В апрельском исследовании Integrate.io 95% ИТ‑директоров назвали проблемы интеграции главным барьером внедрения ИИ. Отчет Anthropic State of AI Agents 2026 фиксирует ту же картину с другого угла: среди инженеров, которые уже строят агентные системы на продакшене, 46% называют интеграцию с существующими корпоративными системами главным техническим вызовом — она обошла и вопросы безопасности, и надежность самих моделей.

Привет! Если ты, как и я, держишь инфраструктуру небольшой команды, наверняка знаком с ситуацией: разработчиков становится больше, а DevOps-отдел при этом не растёт. С приходом vibe-coding'а эта диспропорция стала особенно заметной — у нас в студии команда разработки выросла раза в полтора буквально за пару месяцев, потому что каждый продакт-менеджер захотел свой мини-аппликейшен. Параллельно подкинули головной боли участившиеся проблемы с доступностью приложения из ряда регионов.

В результате поток обращений в канал поддержки в Mattermost вырос настолько, что значительная часть рабочего дня инженера стала уходить на их разбор. И самое неприятное — далеко не каждое обращение по итогу оказывалось в зоне ответственности DevOps, но каждое требовало хотя бы поверхностной диагностики, чтобы это понять.

В этой статье расскажу, как мы строили свою линию тех поддержки на n8n.

Перевёл 16 курсов Anthropic Academy на русский за неделю. 448 уроков, субтитры, Telegram-авторизация, пейволл и т.п. на shared-хостинге за $2/мес. Рассказываю, как устроен пайплайн и что пошло не так.

Дядя Петя съедает 12% всего шашлыка. Backend-инженер видит классический hot key в multi-tenant.

Дачный шашлык на 20 гостей это producer-consumer система с общей тарелкой как bounded buffer. 8-часовой маринад работает как pre-warm cache с TTL. Шампуры это connection pool с риском утечки. Соседская собака утащила мясо, и это unhandled storage failure без backup’а. Шеф приостанавливается при полной тарелке, чистый backpressure.

Парные сравнения альтернатив, таблица failure modes, измерения с дачи, ссылки на DDIA и Release It!.

Принципы те же что в backend, инструменты другие.

Привет, Хабр. Есть устойчивое заблуждение насчет того, что убило рыцарский меч. Многие говорят - порох. И это самая логичная версия. Но Дон Алонсо де Кастро, который сражался при Павии в 1525-м, рассказал бы иначе.

Есть такая старая и немного протухшая дискуссия про 10x программистов. То ли они существуют, то ли это миф стартаперов, то ли это просто мечтания менеджеров про «давайте наймем одного волшебника вместо команды». В презентациях, постах и разговорах эта тема всплывала регулярно, обычно где-то рядом с «нам нужны сильные люди», «у нас маленькая команда» и «дедлайн вчера», а уж на фоне AI-агентов, так и вовсе расцвела опять буйным цветом.

Меня в этой теме всегда смущало, что под 10x часто пытаются запихнуть вообще всё: скорость написания кода, умение чинить баги, знание проекта, способность не делать больно проекту, опыт коммуникации с менеджментом, архитектурный вкус и опытный опыт, готовность сидеть ночью и баф на везение. А потом из этого делают красивую легенду про человека, который работает в десять раз быстрее остальных.

Мечты ПМа, это все же мечты, а в реальной жизни всё скучнее и интереснее одновременно. Я видел людей, которые действительно делали задачи сильно быстрее других. Видел в open-source, видел в игровых проектах, видел на старом коде, видел в маленьких библиотеках. Но почти всегда причина была не в том, что человек родился с коэффициентом x10 и бафом на скорость набирания буковок, а в том, что за его скоростью стоял какой-то накопленный капитал, вроде знания проекта, инструмента, узкой экспертизы или годов ковыряния в похожих задачах.

11 мая Anthropic выкатили в Claude Code новую фичу — agent view. Это менеджер сессий: один экран, в котором видны все запущенные параллельно сессии Claude Code, их статус и какие из них ждут ввода. Запускается командой claude agents. Звучит как мелкое улучшение, но на практике решает реальную боль — раньше для трёх параллельных задач нужны были tmux-сетка и mental ledger в голове. Обновил Claude Code, потестил неделю, рассказываю, что внутри и где границы.

В современном IT ландшафте широко используютя  форматы представления данных JSON и XML, используемые в качестве своеобразного "общего языка", lingua franca  для обмене информацией.

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

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

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

Знакомо?

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

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

Посмотрите на функцию загрузки инвойса:

13-й выпуск IT-новостей от OpenIDE!

Неделя получилась плотной: Grok потерял $175 тыс. без единой строки эксплойт-кода, европейские регуляторы выписали крупный GDPR-штраф «дочке» Яндекса, а Anthropic подписала сделку с куда более неожиданным партнёром.

А ещё обновления маркетплейса OpenIDE, новая архитектура SubQ и 423 закрытых бага в Mozilla благодаря Claude Mythos.

Привет, Хабр! Я SDET‑инженер в SimbirSoft Александр, в этой статье я предлагаю вам:

Рассмотреть основы Kafka, ее архитектуру и как она работает.

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

— Обсудить роль Kafka в интеграционном тестировании, покажу пример интеграционного теста.

— Материал будет полезен для новичков в области тестирования ПО, как ручного, так и автоматизированного.

При работе с современными CPU устранение ошибочного предсказания ветвления — ключевой способ повышения скорости программ. Один из самых эффективных способов снижения количества ошибочных предсказаний— полное устранение ветвлений.

Возьмём для примера простую задачу: итеративный обход массива и копирование всех чисел меньше 500 в новый массив. Если числа распределены случайно, то результат условия if становится непредсказуемым для блока предсказания ветвления CPU. Из-за этого показатель ошибочного предсказания будет высоким, существенно препятствуя производительности, потому что процессору многократно приходится сбрасывать конвейер и начинать исполнение повторно.

Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO: переписать нормально. Поздравляем, у вас уже работают проценты по техдолгу, которые вы пока не считали.

Микрофреймворк для параллельного обучения AI-агентов в средах Gymnasium с графическим интерфейсом на wxPython. Решает классическую проблему «зависшего GUI» при длительном обучении нейросетей: вычисления вынесены в отдельные процессы-сервисы, а интерфейс остаётся полностью отзывчивым. Поддерживает плагинную систему для добавления новых сред, визуализацию прогресса (графики Matplotlib), генетический алгоритм обучения (нейроэволюцию через DEAP) и сборку в один .exe через PyInstaller с автоматическим CI/CD.

Книга Андрея Литвинчука «Разработка программного обеспечения. Практическое руководство для новичков в ИТ-команде» (БХВ-Петербург, 2026) — структурированный и полезный разговор о том, с чем реально сталкивается новый сотрудник, выходя на первую работу в российскую ИТ-компанию. Автор показывает как устроен рынок, кто есть кто в команде, как вести себя на стендапе, как работать с требованиями, как использовать ИИ-инструменты и строить карьеру. Студентам, стажерам и начинающим ИТ-специалистам эта книга стопроцентно поможет не потеряться в первые месяцы работы на реальном проекте.

 Архитектура «оркестратор + сабагенты» на одном экране: ведущий агент держит план и раздаёт подзадачи изолированным сабагентам.

Один AI-агент в чате – это удобно, пока задача помещается в контекст. Как только она начинает разъезжаться по 30 файлам, четырём ролям и циклу «исследуй – реализуй – отревьюй – поправь», единый чат превращается в свалку: модель путает, какой шаг где, тащит решения из первой задачи в третью и стабильно проседает по качеству начиная с заполнения окна примерно наполовину. Схема «оркестратор + сабагенты» – это инженерный ответ на проблему: один ведущий агент держит план и раздаёт подзадачи изолированным сабагентам с пустым контекстом.

Мы у себя в Veai полгода живём с этой архитектурой в IDE-плагине под JetBrains. За это время накопилось достаточно граблей, чтобы написать честный текст: как это устроено, на каких задачах команда из агентов реально лучше одного, и где она проигрывает с разгромом.