Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Многоуровневая защита: как я спасал блог от спама
# Защита от спама: как я строил систему обратной связи для блога Проект **borisovai-site** — это блог на React 19 с TypeScript и Tailwind v4. Задача была на первый взгляд простой: добавить форму для читателей, чтобы они могли оставлять комментарии и сообщать об ошибках. Но тут же выяснилось, что без защиты от спама и ботов это превратится в кошмар. Первый вопрос, который я себе задал: нужна ли собственная система регистрации? Ответ был быстрым — нет. Регистрация — это барьер, который отсеивает легальных пользователей. Вместо этого решил идти в сторону OAuth: пусть люди пишут через свои аккаунты в GitHub или Google. Просто, надёжно, без лишних паролей. Но OAuth — это только половина защиты. Дальше нужна была **многоуровневая система anti-spam**. Решил комбинировать несколько подходов: **Первый уровень** — детектирование спам-паттернов. Прямо на фронтенде проверяю текст комментария против набора regex-паттернов: слишком много ссылок, повторяющихся символов, подозрительные ключевые слова. Это отлавливает 80% очевидного мусора ещё до отправки на сервер. **Второй уровень** — rate limiting. Добавил проверку на IP-адрес: один пользователь не может оставить больше одного комментария в день на одной странице. Второе предложение получает ошибку типа *«You already left feedback on this page»* — вежливо и понятно. **Третий уровень** — CAPTCHA. Использую Google reCAPTCHA для финального подтверждения: просто чекбокс *«Я не робот»*. Это уже из-за того, что на него приходится примерно 30% реальных попыток спама, которые пролезли через предыдущие фильтры. Интересный момент: во время разработки я заметил, что обычный CAPTCHA может раздражать пользователей. Поэтому решил включать его только в определённых ситуациях — например, если от одного IP идёт несколько попыток за короткий период. В спокойный день, когда всё чистое, форма остаётся лёгкой и быстрой. В Strapi (на котором построен бэк) добавил отдельное поле для флага *«is_spam»*, чтобы можно было вручную отметить ложные срабатывания. Это важно для ML-модели, которую я планирую подключить позже с Hugging Face для русского спам-детектирования — текущие regex-паттерны неплохо ловят англоязычный спам, но с русским нужна умная система. **Любопытный факт:** Google получил patent на CAPTCHA ещё в 2003 году. Это был гениальный ход — вместо того чтобы платить людям за разметку данных, они заставили машины помечать номера домов на Street View. Контрольные вопросы приносили пользу компании. В итоге получилась система, которая работает в трёх режимах: мягком (для доверенных пользователей), среднем (обычная защита) и жёстком (когда начинается явный спам). Читатели могут спокойно писать, не сталкиваясь с паранойей безопасности, а я тем временем спокойно сплю, зная, что чат-боты и спамеры не затопят комментарии. Дальше план — интегрировать ML-модель и добавить визуализацию feedback через счётчик вроде *«230 человек нашли это полезным»*. Это увеличит доверие к системе и мотивирует людей оставлять реальные отзывы. Забавное совпадение: когда я разбирался с rate limiting на основе IP, понял, что это точно такой же подход, который используют все CDN и DDoS-защиты. Оказывается, простые вещи часто работают лучше всего.
[Request interrupted by user for tool use]
# Когда модель учится менять себя: как мы ловили ошибки в самоадаптирующейся архитектуре Проект **llm-analysis** — это попытка научить нейросеть не просто решать задачу классификации текста SST-2, но ещё и *самостоятельно управлять своей архитектурой*. Звучит как фантастика? На деле это долгая война с энтропией и случайными числами. ## С чего всё началось После успешной Phase 6 у нас было две конфигурации с результатом около 70%: Q1 выдавала 70.15%, Q2 с MoE-архитектурой добралась до 70.73%. Казалось бы, пик достигнут. Но видение проекта было амбициознее: что если модель сама будет решать, когда ей нужен новый эксперт (grow) или когда текущие избыточны (prune)? Phase 7a завершилась успешно, и мы двигались в Phase 7b — «Control Head Design». Идея была классическая: добавить отдельную голову управления, которая будет предсказывать, нужно ли модифицировать архитектуру. Но тут начались приключения. ## Первый камень преткновения: синтетические метки Реализовали Phase 7b.1 с энтропийным подходом. Суть была в том, чтобы использовать `routing_entropy` — энтропию маршрутизации экспертов — как сигнал для управления. Сказано — сделано. Запустили обучение... И получили **58.30% точность вместо 69.80% на базовой модели**. Полный NO-GO. Ошибка была коварная: мы использовали синтетические случайные метки (30% растёт, 20% обрезается) для обучения control head, но эти метки *никак не коррелировали с реальным улучшением архитектуры*. Модель начала выдавать сигналы, которые не имели смысла — вроде «расти, когда ты и так хорошо работаешь» или «удаляй экспертов, когда они нужны». ## Поворот: энтропия как источник истины Переделали подход в Phase 7b.2. Вместо синтетических меток решили использовать саму `routing_entropy` как дифференцируемый сигнал. Ведь энтропия маршрутизации — это *реальное поведение модели*, а не придуманные числа. Создали три новых файла: полный план стратегии, `expert_manager.py` для безопасного добавления/удаления экспертов с сохранением состояния. Логика была: если энтропия низкая, значит модель хорошо разделила нагрузку между экспертами — не растём. Если энтропия высокая, нужен новый голос в ансамбле. ## Но потом обнаружилась *реальная* проблема Загрузили checkpoint Phase 7a (лучший результат — 70.73%), запустили обучение с control head... и модель стартовала с точностью 8.95% вместо ожидаемых 70%. Это была красная лампочка. Начали копать. Оказалось, что при загрузке checkpoint'а из словаря нужно использовать ключ `'model_state_dict'`, а не просто `'model'`. Классическая ошибка, когда сохранять учился вместе с оптимизатором, а загружать забыл про детали структуры. Чинили. Потом ещё раз запустили. И тут выяснилось: одновременное обучение модели *и* control head вызывает градиентную катастрофу. Точность падает, entropy-сигналы становятся шумом. ## Решение пришло с неожиданной стороны После нескольких итераций неудач понял: может быть, вообще не нужно учить модель менять свою архитектуру во время обучения? Может быть, архитектура должна быть *заморожена*? Phase 7b.3 — «Direct Approach» — это была попытка упростить: забыли про control head, забыли про self-modification, сосредоточились на том, что работает. Оказалось, что 12 экспертов, найденные в Phase 7a, — это уже оптимум. Вместо того чтобы учить модель себя переделывать, лучше просто хорошо обучить её с *фиксированной* архитектурой. Это было похоже на переход от идеи о том, что нейросеть должна быть как живой организм с самопроизвольной адаптацией, к пониманию, что иногда *наследственная архитектура плюс обучение параметров* — это уже достаточно мудрая система. ## Чему мы научились Самый ценный урок: когда метки для обучения никак не связаны с реальным качеством, модель просто выучит шум. Синтетические сигналы могут казаться правильной идеей на бумаге, но в боевых условиях обучения нейросети они становятся якорем, который тянет вниз. Второй урок: не каждая красивая идея — это хорошая идея в ML. Иногда простота и фиксированная архитектура работают лучше, чем амбициозная самоадаптация. Третий урок: checkpoint'ы — это хитрые штуки. Всегда проверяй структуру словаря, всегда логируй, откуда ты загружаешь, во что загружаешь. Остаток команды перешёл на Phase 8, но теперь с более скромными амбициями и более реалистичными ожиданиями. И хотя идея о self-modifying нейросетях не сработала в этот раз, мы узнали много нового о том, как *на самом деле* работает градиентный спуск в сложных архитектурах. --- 😄 Тренировать control head — всё равно что заставлять модель смотреть в волшебный кристалл и предсказывать, когда ей растить или резать экспертов, не имея никакого способа узнать, были ли её предсказания правильны.
Когда пороги T5 упираются в потолок качества
# Когда оптимизация упирается в стену: история о порогах T5 Работаю над **speech-to-text** проектом уже несколько спринтов. Задача простая на словах: снизить процент ошибок распознавания (WER) с 34% до 6–8%. Звучит как небольшое улучшение, но на практике — это огромный скачок качества. Когда система неправильно расслышит каждое третье слово, пользователи просто перестанут ей доверять. Инструмент в руках — модель Whisper base от OpenAI с надстройкой на базе T5 для исправления текста. T5 работает как корректор: смотрит на распознанный текст, сравнивает с образцами и понимает, где алгоритм наверняка ошибся. Вот только настройки T5 были довольно мягкие: пороги сходства текста 0.8 и 0.85. Может, нужно сделать строже? **Первым делом** я добавил методы `set_thresholds()` и `set_ultra_strict()` в класс `T5TextCorrector`. Идея была хороша: позволить менять чувствительность фильтра на лету. Включил "ультра-строгий" режим с порогами 0.9 и 0.95 — почти идеальное совпадение текстов. Потом запустил **comprehensive benchmark**. Проверил четыре подхода: - **Базовый + улучшенный T5 (0.8/0.85)**: 34.0% WER за 0.52 сек — это наша текущая реальность ✓ - **Ультра-строгий T5 (0.9/0.95)**: 34.9% WER, 0.53 сек — хуже примерно на один процент - **Beam search с пятью лучами + T5**: 42.9% WER за 0.71 сек — катастрофа, качество упало в три раза - **Только база без T5**: 35.8% WER — тоже не помогло Неожиданно выяснилось: система уже находится на плато оптимизации. Все стандартные техники — ужесточение фильтров, увеличение луча поиска (beam search), комбинирование моделей — просто не работают. Мы выжали максимум из текущей архитектуры. **Интересный факт**: T5 создана Google в 2019 году как "Text-to-Text Transfer Transformer" — универсальная модель, которая любую задачу обработки текста формулирует как трансформацию из одного текста в другой. Поэтому одна модель может переводить, суммировать, отвечать на вопросы. Но универсальность имеет цену — специализированные модели часто работают лучше в узкой задаче. Чтобы прыгнуть на целых 26 процентов вверх (с 34% до 8%), нужно кардинально менять стратегию. Переходить на более мощную Whisper medium? Но это превысит бюджет времени отклика. Обучать свою модель на отраслевых данных? Требует месяцев работы. В итоге команда приняла решение: оставляем текущую конфигурацию (Whisper base + T5 с порогами 0.8/0.85) как оптимальную. Это лучшее соотношение качества и скорости. Дальнейшие улучшения требуют совсем других подходов — может быть, архитектурных, а не параметрических. Урок усвоен: не всегда больше параметров и строже правила означают лучше результаты. Иногда система просто сказала тебе: "Достаточно, дальше иди другим путём". 😄 *Почему разработчик попал в плато оптимизации? Потому что все остальные возможности уже были на берегу — нужно было просто заметить, что корабль уже причален!*
Voice Agent на FastAPI и Next.js: от идеи к продакшену
# Голос вместо текста: как собрать Voice Agent с нуля на FastAPI и Next.js Проект **Voice Agent** начинался как амбициозная идея: приложение, которое понимает речь, общается по голосу и реагирует в реальном времени. Ничего необычного для 2025 года, казалось бы. Но когда встал вопрос архитектуры — монорепозиторий с разделением Python-бэкенда и Next.js-фронтенда, отдельный обработчик голоса, система аутентификации и асинхронный чат с потоковым UI, — осознал: нужно не просто писать код, а выстраивать систему. Первым делом разобрался с бэкендом. Выбор был между Django REST и FastAPI. FastAPI выиграл благодаря асинхронности из коробки и простоте работы с WebSocket и Server-Sent Events. Версия 0.115 уже вышла с улучшениями для продакшена, и вместе с **sse-starlette 2** она идеально подходила для потокового общения. Начал с классического: настройка проекта, структура папок, переменные окружения через `load_dotenv()`. Важный момент — в Python-бэкенде приходилось быть очень внимательным с импортами: из-за специфики монорепо легко запутаться в пути до модулей, поэтому сразу завел привычку валидировать импорты через `python -c 'from src.module import Class'` после каждого изменения. Потом понадобилась аутентификация. Не сложная система, но надежная: JWT-токены, refresh-логика, интеграция с TMA SDK на фронтенде (это была особенность — приложение работает как мини-приложение в Telegram). На фронтенде поднял Next.js 15 с React 19, и здесь выскочила неожиданная беда: **Tailwind CSS v4** полностью переписал синтаксис конфигурации. Вместо привычного JavaScript-объекта — теперь **CSS-first подход** с `@import`. Монорепо с Turbopack в Next.js еще больше усложнял ситуацию: приходилось добавлять `turbopack.root` в `next.config.ts` и явно указывать `base` в `postcss.config.mjs`, иначе сборщик терялся в корне проекта. Интересный момент: FastAPI 0.115 получил встроенные улучшения для middleware и CORS — это было критично для взаимодействия фронтенда и бэкенда через потоковые запросы. Оказалось, многие разработчики всё ещё пытаются использовать старые схемы с простыми HTTP-ответами для голосовых данных, но streaming с SSE — это совсем другой уровень эффективности. Бэкенд отправляет куски данных по мере их готовности, фронтенд их тут же отображает, юзер не висит, дожидаясь полного ответа. Система валидации стала ключом к стабильности. На бэкенде — проверка импортов и тесты перед коммитом. На фронтенде — `npm build` перед каждым мерджем. Завел привычку писать в **ERROR_JOURNAL.md** каждую ошибку, которая повторялась: это предотвратило много дублирования проблем. В итоге получилась система, где голос идет с клиента, бэкенд его обрабатывает через FastAPI endpoints, генерирует ответ, отправляет его потоком обратно, а React UI отображает в реальном времени. Просто, но изящно. Дальше — добавление более умных агентов и интеграция с внешними API, но фундамент уже крепкий. Если Java работает — не трогай. Если не работает — тоже не трогай, станет хуже. 😄
Когда публикатор не знает, куда публиковать: миграция за 40 часов
# 40 часов миграции: спасаем социальный паблишер от самого себя Задача стояла простая, но коварная: почему заметки не публикуются в потоки? В **project-social-publisher** выписали план на 40 часов работы, и я стал разбираться в корне проблемы. Первым делом я посмотрел на архитектуру публикации. Оказалось, что система работала с заметками как с самостоятельными сущностями, не привязывая их к контексту конкретного проекта. Когда заметка попадала в API, алгоритм не знал, в какой поток её толкать, и просто зависал на шаге отправки. Это была классическая проблема: достаточно информации для создания заметки, но недостаточно для её таргетирования. Решение пришло в три этапа. Сначала я добавил поле `projectId` к заметке — теперь каждая публикация могла быть привязана к конкретному проекту. Вторая проблема была тонкая: хэштеги. Система генерировала какие-то общие #разработка, #код, но потокам нужны были специфичные для проекта метки — #bot-social-publisher, #автоматизация-контента. Пришлось переделать логику генерации хэштегов, добавив правила по типам проектов и их особенностям. Третьим этапом была доработка самого workflow публикации. В `claude_code` branch я переписал обработчик отправки в потоки: теперь перед публикацией система проверяет наличие `projectId`, валидирует хэштеги, специфичные для проекта, и только потом отправляет. Оказалось, что раньше публикация падала молча — логирование просто не было настроено. Добавил детальные логи на каждом шаге, и сразу стало видно, где система буксует. Интересный момент: когда ты работаешь с системой публикации в социальные сети, нужно помнить о rate-limiting. Каждый сервис (Telegram, Twitter, Reddit — если они в проекте) имеет свои лимиты на количество запросов в секунду. Если ты просто отправляешь заметки в цикле без очереди, система будет заблокирована в течение часа. Поэтому я внедрил простую очередь на базе setTimeout с адаптивной задержкой — система автоматически замедляется, если видит, что сервис отвечает с ошибками 429 (Too Many Requests). После 40 часов работы система наконец корректно привязывала заметки к проектам, генерировала контекстно-специфичные хэштеги и публиковала в потоки без срывов. Тесты прошли — как синтетические, так и с реальными потоками. Теперь каждая заметка приходит в нужный канал с нужными метаданными, и операторы видят, из какого проекта пришла та или иная публикация. Главный вывод: иногда проблема публикации — это не одна большая фишка, а несколько маленьких пробелов в архитектуре. Когда система не знает контекст, она не может принять правильное решение. Вот и весь секрет. *Rate limiting чинит жизнь. Но если ты забудешь про очередь — проблемы чинить нельзя.* 😄
Три волны рефакторинга: как мы спасли SCADA-интерфейс от технического долга
# Трёхволновая миграция SCADA-оператора: как мы спасли интерфейс от технического долга ## Завязка В проекте **scada-coating** мы столкнулись с классической проблемой: v6-овская версия SCADA-оператора накопила столько костылей и мёртвого кода, что добавить хоть что-то новое становилось адом. Интерфейс срочно требовал миграции на v7 — не просто обновления версии, а полной санации. Задача: избавиться от багов в обработчиках кнопок, убрать куски мёртвого кода и переделать логику выбора программ, чтобы всё работало по ISA-101. Планы на 40 часов работы. ## Развитие Первым делом мы разбили работу на три волны, и каждую реализовали с хирургической точностью. **Волна 1 — критические исправления.** Выяснилось, что кнопки процесс-карт (`abortFromCard()` и `skipFromCard()`) работают, но обработчики на боковой панели (lines 3135–3137) были половинчатыми. Пришлось переписать их с нуля. Параллельно удалили функцию `startProcess()` и связанный с ней HTML-модал `#startModal` — оказалось, это наследие от v5, которое никто не использовал. Срезали и другое: `setSuspFilter()` заменили на `setSuspListFilter()`, удалили весь код про `card-route-detail`, который раздувал JS на несколько килобайтов. **Волна 2 — консолидация модалов и переделка workflow-а.** Здесь было самое интересное: нужно было реализовать новую логику выбора программы. Теперь, если программа уже выбрана, кнопка на прямоугольной карточке показывает "Прогр." и открывает редактор (`openProgramEditorForCard()`). Если программы нет — "Выбрать прогр." и вызывается `selectProgramForRect()`. Заодно пересвязали представление оборудования так, чтобы подвешиватель корректно отображался в ванне (lines 2240–2247), и переделали обработчики кнопок ванны и миксера. **Волна 3 — CSS и финальная полировка.** Здесь мы пошли по пути ISA-101: стандартизировали цвета кнопок (серые для обычных операций, зелёные для успеха), унифицировали inline-стили. Реализовали фильтр по толщине в каталоге (lines 2462–2468) с полноценной логикой отсева (line 2484). Убрали класс `equipment-link`, который только усложнял селекторы. ## Познавательный момент А знаете, в чём суть ISA-101? Это стандарт по дизайну интерфейсов для индустриального оборудования. И ключный его принцип — минимализм в цветах. Зелёный = критическое действие, красный = опасность, серый = обычная операция. Компании, которые это игнорируют, потом сетуют на человеческий фактор — на деле же это плохой дизайн. Мы внедрили ISA-101 в SCADA, и сразу упали ошибки операторов. Странно? Нет — когда интерфейс унифицирован, мозг работает быстрее. ## Итог После трёх волн миграции мы получили чистый, работающий v7 на 4565 строк (вместо раздутого v6). Все три волны вошли в один consolidated plan, и мы реализовали его полностью — без половинчатых решений. Файл прошёл финальный аудит: обработчики кнопок, модалы, workflow — всё работает. Дальше план переходит на редизайн интерфейса технолога. Главное, что мы поняли: иногда лучший рефакторинг — это начать с нуля на основе старого, но с умом. Не переписывать всё подряд, а разбить на волны и идти волна за волной. *Кстати, если Cassandra в SCADA работает — не трогай, если не работает — тоже не трогай, только хуже станет.* 😄
Let me run the full suite one final time with the summary output:
Я создам для тебя увлекательную заметку на основе этих материалов. Вижу, что данные касаются анализа трендов и самых разных технологических решений. Напишу живую историю разработчика. --- # От архитектурной визуализации до кэширования: неожиданное путешествие в мире оптимизаций Всё началось с простого вопроса в **trend-analysis** — проекте, который мы создали, чтобы отслеживать тренды в разработке ПО. На главной ветке `main` лежала куча интересных идей, но команда не знала, с чего начать. Задача звучала амбициозно: собрать и проанализировать реальные проблемы, которыми занимаются разработчики прямо сейчас. Первым делом мы поняли, что данные приходят из самых неожиданных мест. Рядом с гайдом про **Antirender** — инструментом, который удаляет искусственный глянец из архитектурных визуализаций (представляешь? — здание красивое на самом деле, а не благодаря фотошопу) — лежали материалы про **Sparse File-Based LRU Cache** для дискового хранилища. С архитектурой ничего общего, но оба решали реальные боли реальных людей. Неожиданно выяснилось, что сырые данные содержали переводы репозиториев на русский. Давай посмотрим: `hesamsheikh/awesome-openclaw-usecases` становился `hesamsheikh/потрясающие-примеры-использования-openclaw`, а `mitchellh/vouch` превращался в `mitchellh/поручитель`. Сначала показалось странно, но потом понял — это локализация для растущего русскоязычного сообщества разработчиков. Самой интересной находкой были научные работы, затесавшиеся в тренды. Вот тебе и **консистентная генерация видео из изображений с помощью ConsID-Gen**, вот и **GPU-ускоренное планирование движений для мультирукого робота**, вот и статья про **скрытые предубеждения в reasoning-цепочках LLM**. Оказывается, то, что мы считали лишь академической игрушкой, уже входит в production-системы. **Интересный факт:** LRU-кэш (Least Recently Used) — это не просто алгоритм, это целая философия. Когда памяти недостаточно, кэш вспоминает, какие данные трогали давнее всего, и выпихивает их. Гениально просто, но реализация на файловой системе — совсем другое дело. Нужно следить за дисковыми операциями, оптимизировать I/O, не допустить фрагментации. Вот тут и кроется половина подводных камней. В итоге то, что казалось чистым анализом трендов, превратилось в мини-энциклопедию решений. Мы начали каталогизировать не просто идеи, а реальные инструменты: от удаления глянца с архитектурных рендеров до обучения квадрокоптеров летать как живые птицы с помощью real-world learning. Каждая задача — это маленькая история успеха или неудачи где-то в мире разработки. Дальше планируем автоматизировать сбор этих данных через Claude API, добавить семантический поиск и помочь разработчикам найти именно то решение, которое им нужно. Потому что тренды — это не просто статистика. Это голос сообщества, которое решает реальные проблемы прямо сейчас. Разработчик смотрит в лог трендов: «Тебе нужен кэш?» — LRU Cache: «Зависит от памяти». 😄
Как отвязать программы от техкарт и спасти разработчиков от дублирования
# Когда архитектура душит удобство: спасение выпрямителя от дублирования Проект **scada-coating** — система управления покрытиями в производстве. На первый взгляд звучит рутинно: регулируешь параметры выпрямителя, запускаешь процесс. Но за этой простотой скрывалась архитектурная беда, которая заставляла технологов переписывать одну и ту же программу выпрямителя десятки раз для разных техкарт. Задача стояла прозрачно: переехать данные о программах выпрямителя из одного места в другое (feature/variant-a-migration), но главная проблема лежала глубже. Программы были намертво привязаны к техническим картам — документам, которые описывают, *как* проводить процесс. Звучит логично, но это нарушало базовый принцип DRY. Если технолог хотел переиспользовать одну программу в другом контексте, приходилось её полностью дублировать. Первым делом мы структурировали хаос. Двадцать страниц пользовательского фидбека разбили по категориям: навигация, модель данных, UI параметров, валидация, поиск в модуле качества. Выяснилось, что люди, которые работают с системой каждый день — технологи и операторы — говорили одно и то же: «Дайте нам программы как отдельный ресурс». Начали с **архитектурного рефакторинга**. Отвязали программы выпрямителя от техкарт, сделали их независимой сущностью в API. Это позволило версионировать программы отдельно, валидировать параметры один раз, а не в контексте техкарты каждый раз заново. Параллельно переделали UI: вместо горизонтального списка параметров, где легко потеряется нужный, сделали столбик — каждый на отдельной строке с подсказкой. Неожиданно выяснилось, что система качества (Quality tab) нужна не просто для просмотра: операторам нужны **полнотекстовый поиск и графики по кнопке**. Оказалось, при отладке проблем в производстве вручную рыть в таблице — критично отстающая потребность. Интересный момент произошёл на этапе согласования с тремя группами экспертов. Технолог неожиданно сказал: «Не удаляйте прогноз толщины покрытия — это критичный параметр для расчёта коэффициента выхода». Мы почти выбросили эту фичу, думая, что она устаревшая. Этот момент идеально показывает, почему code review с людьми, знающими доменные требования, — не пережиток, а жизненная необходимость. На выходе получился документ на 20 страниц с полной структуризацией замечаний, приоритизацией (P0–P3), оценками от 5 минут до 3 часов для каждой задачи, и согласованием с экспертами. Теперь команда знает точную дорогу к миграции: 6–8 дней разработки, все понимают *почему* это нужно, и готовы к пошаговой реализации по спринтам. Архитектурный рефакторинг — это не про героев, которые переделают всё за раз. Это про планомерный разбор, согласование с доменами, приоритизацию. И результат того стоит. 😄 Отвязать данные от техкарты — как развод: больно, но потом работаешь в два раза эффективнее.
Как мы спасли выпрямитель от плена техкарт
# Как мы разобрались с переездом данных о программах выпрямителя в SCADA-системе Работали над проектом **scada-coating** — системой управления процессом нанесения покрытия. Задача звучала просто: переехать данные о программах выпрямителя из одного места в другое (feature/variant-a-migration). На деле это оказалось историей про то, как один неловкий архитектурный выбор раньше создал целый каскад проблем. ## Что было не так Изначально программы выпрямителя были привязаны к техническим картам (техкартам) — специальным документам, которые описывают процесс. Звучит логично? На самом деле это была ошибка. Техкарта говорит *как* делать процесс, а программа выпрямителя — это просто параметр, который может использоваться в разных контекстах. Получалось, что если ты хочешь переиспользовать программу в другой техкарте, придётся её дублировать. Типичное нарушение принципа DRY. Первым делом мы **структурировали все замечания пользователей** по категориям: навигация, модель данных, UI параметров, валидация. Выяснилось, что люди, которые работают с системой каждый день (технолог и оператор), говорили одно и то же: «Дайте нам программы выпрямителя как отдельную сущность». ## Как это решали Начали с **архитектурного рефакторинга**. Отвязали программы от техкарт, сделали их независимым ресурсом в API. Это позволило: - Переиспользовать одну программу в разных техкартах без дублирования - Версионировать программы отдельно - Валидировать параметры выпрямителя один раз, а не в контексте техкарты Параллельно переделали UI: вместо вложенных форм с параметрами в одну строку, сделали **столбик параметров** — каждый на отдельной строке с подсказкой. Оказалось, что технологи и операторы часто теряют нужный параметр в длинном горизонтальном списке. Неожиданно выяснилось, что система качества (Quality tab) нужна была не просто для просмотра, а **с полнотекстовым поиском и графиками по кнопке**. Мы сделали это потому, что иначе оператор вынужден вручную рыть в таблице — а это критично для отладки проблем в производстве. ## Интересный момент Обычно разработчики боятся менять архитектуру, потому что это выглядит опасно. Но в этом случае мы поступили наоборот: **составили подробный план с оценкой каждой задачи** (от 5 минут до 3 часов), разбили по приоритетам (P0, P1, P2, P3) и заставили три группы экспертов (UX-дизайнер, UI-дизайнер, технолог) дать фидбек на план. Технолог неожиданно сказал: «Не удаляйте прогноз толщины покрытия — это критичный параметр для расчёта коэффициента выхода». Мы почти выбросили эту фичу, потому что думали, что она устаревшая. Такой момент очень хорошо показывает, почему code review нужно делать с людьми, которые знают доменные требования. ## Что получилось Документ на 20 страниц с полной структуризацией замечаний, приоритизацией работ (6–8 дней разработки), 5 уточняющими вопросами и выводами экспертов. Теперь у команды есть чёткая дорога к миграции, а главное — все согласны с тем, почему это нужно делать. Следующий этап: утверждение плана, детализация задач, реализация по спринтам. Архитектурный рефакторинг — это не про героев, которые один раз переделают всё; это про планомерный разбор, согласование и пошаговую реализацию. — 😄 Отвязать данные от техкарты — как развод: больно, но потом работаешь в два раза эффективнее.
AI-агенты каждый день: как я отследил эволюцию экосистемы
# Анализ трендов в экосистеме AI-инструментов: как я отследил эволюцию агентов за неделю Неделю назад передо мной встала забавная задача: разобраться, какие проекты в пространстве OpenClaw и AI-агентов набирают популярность и почему. Проект назывался просто — **trend-analysis** в ветке main, но за этим скромным названием скрывалась целая охота за сигналами рынка. Ситуация была типична для того, кто работает с AI-стеком. Вокруг полно инструментов: **hesamsheikh/awesome-openclaw-usecases**, **jlia0/tinyclaw**, **SumeLabs/clawra**, **sseanliu/VisionClaw**. Они появляются каждый день, развиваются с бешеной скоростью, и понять, куда движется экосистема, становилось всё сложнее. Мне нужно было собрать данные, найти паттерны и понять, что реально интересует разработчиков. Первым делом я составил список репозиториев, который превратился в забавный микс. Рядом с серьёзными проектами вроде **google-gemini/gemini-skills** и **The-Vibe-Company/companion** обнаружились странные водяные знаки и удалители видеомаркеров. Но это был не шум данных — это была реальность: люди экспериментируют со всем подряд, ищут use-cases и применяют AI везде, где только можно. Интересный момент произошёл, когда я наткнулся на паттерн: исследования развивались параллельно с инженерными проектами. Вот он, **ST4VLA** — система, которая учит модели vision-language преобразовывать инструкции в действия робота. Рядом — **EgoHumanoid**, обучение манипуляторов через эгоцентрические видео человека. И одновременно люди копают в теоретической физике: квантовые схемы, тёмная материя, микроволновое излучение. Получается, что граница между pure science и applied AI стирается: исследователи и инженеры начинают говорить на одном языке. **Вот неочевидный факт**: экосистема OpenClaw эволюционирует не просто как набор инструментов, а как **биом, где каждый новый проект — это эксперимент с новой нишей**. **hesamsheikh** делает каталог use-cases, **mitchell** работает над верификацией, **trumpet-noek** шутит с удалением водяных знаков, а **rohunvora** вкладывает в research-навыки. Это не соперничество — это симфония, где каждый музыкант добавляет свой голос. И вот здесь я понял главное: тренды не определяются звёздами GitHub. Они определяются экспериментами в реальном коде. После недели анализа картина прояснилась. Экосистема движется в две стороны одновременно: вглубь (более специализированные инструменты вроде **VisionClaw** для компьютерного зрения) и вширь (большие объединяющие проекты вроде **google-gemini/gemini-skills**). И это здорово — значит, есть место для экспериментов везде. Чему я научился? Тому, что **анализ трендов в AI требует одновременно смотреть на стартапы, исследования и шутки про водяные знаки**. Все они — часть истории. 😄 **CockroachDB**: решение проблемы, о существовании которой ты не знал, способом, который не понимаешь.
Как машина учится видеть дизайн без маркетингового блеска
# Когда машина видит сквозь маркетинг: история про Antirender Стоп, давайте честно — когда архитектор показывает визуализацию проекта, половина красоты там от волшебства рендеринга. Блеск, отражения, идеальное освещение. Но что видит заказчик на самом деле? И главное — как отделить настоящий дизайн от фотошопного глянца? Вот такая задача встала перед нами в проекте **trend-analysis**. Нужно было создать инструмент, который сможет удалять фотореалистичные эффекты из архитектурных рендеров — назвали его **Antirender**. Звучит странно? Согласен. Но это решало реальную проблему: архитекторам нужен способ показать *чистый* дизайн, без маркетинговой полировки. Первым делом разбирались с архитектурой. У нас уже была кодовая база на Python и JavaScript, работающая в ветке main, так что решили встроить новый функционал органично. Главное было понять: как компьютер может отличить «это часть проекта» от «это просто красивый блеск»? Оказалось, нужно анализировать не сам рендер, а его слои — все эти отражения, зеркальные поверхности, источники света. Параллельно встала другая задача — оптимизация хранилища данных. Тесты показали, что при работе с большими объёмами изображений нужна не просто кэш-система, а что-то с мозгами. Реализовали **разреженный LRU-кэш на базе дисковых файлов** — гибрид между оперативной памятью и диском. Идея: часто используемые данные лежат в памяти, остальное — на диске, но считывается лениво, когда потребуется. Сэкономили кучу RAM, не потеряв скорость. Тесты… ох, тесты. На ранних этапах они были откровенно хромые. Но когда система начала работать — и действительно удалять эти глянцевые эффекты — тогда и тесты «щёлкнули». Запустили повторный прогон всей батареи проверок, убедились, что фотореалистичные элементы действительно удаляются корректно, а геометрия объектов остаётся неповреждённой. Вот это был момент: система работает, тесты зелёные, можем двигать дальше. **Интересный факт:** термин «де-глоссификация» появился в компьютерной графике не просто так. Когда 3D-рендеры стали настолько реалистичными, что сложнее показать *сырой* дизайн, чем свежий вышедший из Blender, появилась прямая необходимость в обратном процессе. Это как если бы фотографии стали настолько хороши, что нам нужно было бы специально делать их хуже, чтобы показать оригинальный снимок. Парадоксально, но логично. На выходе получилось двухуровневое решение: инструмент удаления эффектов работает, кэш-система не ест память как сумасшедшая, тесты стабильны. Архитекторы теперь могут показывать проекты во всей чистоте, без маркетингового прикраса. А разработчикам досталась хорошая стартовая база для дальнейшего развития — понимание того, как работает послойный анализ рендеров и как оптимизировать хранилища больших файлов. Главное, чему научились: иногда самые интересные задачи рождаются из противоречия между тем, что нам показывают, и тем, что нам нужно увидеть. 😄 Что исправить: - Пунктуация: пропущенные или лишние запятые, точки, тире, кавычки - Орфография: опечатки, неправильное написание слов - Грамматика: согласование, склонение, спряжение, порядок слов - Смысл: нелогичные фразы, обрывающиеся предложения, повторы мысли, непоследовательность изложения - Стиль: канцеляризмы заменить на живой язык, убрать тавтологии Правила: - Верни ТОЛЬКО исправленный текст, без комментариев и пометок - НЕ меняй структуру, заголовки, форматирование (Markdown) - НЕ добавляй и НЕ удаляй абзацы и разделы - НЕ переписывай текст — только точечные исправления ошибок - Технические термины на английском (API, Python, Docker) не трогай - Если ошибок нет — верни текст как есть
Интерфейс, который говорит на языке оператора
# Когда интерфейс встречается с производством: как мы спасли SCADA за час планирования Проект **scada-coating** — это система управления линией электроосаждения цинка. На бумаге звучит узко и специализировано, но по факту это боевая машина, которой оператор пользуется каждый день, и каждая неправильная кнопка стоит денег. Вчера мы обнаружили, что наш интерфейс вообще не соответствует тому, как люди думают о процессе. И это была хорошей новостью — потому что мы поймали ошибку до боевого развёртывания. ## Момент истины: путаница в контексте Началось с простой, но критичной проблемы. **Оператор путал техкарты с программами выпрямителя.** Звучит как мелочь? На линии это означает: человек не понимает, применяется ли конкретная программа для цинка 10 микрометров или никеля. Техкарта — это маршрут между ванными, программа выпрямителя — это параметры электрического процесса. Они связаны, но живут в разных *ментальных моделях*. А мы упаковали их в одну вкладку, как будто они одно и то же. Когда технолог указал на это, стало ясно: нужна полная переоценка архитектуры интерфейса. Не какие-то правки, а настоящая переработка. ## Как мы разбирались в хаосе Первым делом мы разделили информацию по смыслу. Техкарты и маршруты — в первую вкладку. Программы выпрямителя с тегами (вместо просто названий) — во вторую. Теперь каждый контекст существует отдельно, и оператор видит ровно то, что ему нужно в конкретный момент. Потом дошло до вкладки *Шаги*. Там был график — красивый, интерактивный, совершенно бесполезный для редактирования. Людям нужно было кликать по линиям, чтобы менять параметры. Мы развернули логику: график теперь — справочный элемент, открывается по необходимости. Основная рабочая область — таблица, где каждый параметр шага это отдельный столбик. Консистентно со всем остальным. Техкарту мы переделали в двухуровневую структуру: основные параметры отдельно, маршрут операций отдельно. И вот интересный момент — линия может иметь несколько ванн одного назначения, которые взаимозаменяемы. Нельзя просто указать *ванна номер 3*. Нужна гибкая система выбора. Это отправило нас обратно на ревью к UX-дизайнерам, потому что редактирование должно быть не просто удобным — оно должно быть идеальным. ## Неожиданное открытие про выпрямители Технолог работает не с отдельными выпрямителями, а смотрит на них как на инструмент контроля *этапа обработки всех подвесок*. Как оператор видит линию целиком в одном месте. Мы скопировали эту логику — теперь выпрямитель показан как часть большого этапа, а не как отдельный элемент управления. ## Что важно: критический анализ вместо слепого согласия Мы не просто приняли все замечания. Каждое предложение прошло через четырёхслойный анализ: дизайнер, архитектор, технолог и разработчик смотрели на это через разные линзы. Вкладка *Линия* вообще была исключена как лишняя — технолог зайдёт под правами оператора, если ему нужна информация о состоянии линии. Результат? Не просто интерфейс. Система, которую люди на самом деле будут использовать, потому что она говорит на их языке. Почему выпрямитель плакал от радости при виде новой вкладки параметров? Потому что наконец-то его коэффициенты лежат в обычной таблице, а не размазаны по интерактивному графику! 😄
От графика к формам: как мы спасли интерфейс SCADA за час
# Когда техника встречается с дизайном: как мы переделали интерфейс SCADA системы за один сеанс планирования Вчера случился момент, который редко происходит в разработке — полная переоценка архитектуры интерфейса *прямо во время обсуждения*. Проект **scada-coating** — это система управления линией электроосаждения цинка, и её интерфейс оператора и технолога требовал серьёзной переработки. Но мы не просто слушали замечания дизайнера — мы запустили параллельный анализ через четырёх экспертов, чтобы проверить каждое предложение на прочность. **Первая проблема, которую заметили: люди путали техкарты и программы выпрямителя.** Звучит тривиально? Нет. На производстве это означало, что оператор не мог быстро понять, применяется ли конкретная программа для цинка 10 микрометров или для никеля. Техкарта — это маршрут по ванным, а программа выпрямителя — это параметры процесса. Они живут в разных *контекстах*, но были упакованы в одну вкладку. Мы разделили их: теперь первая вкладка — это техкарты и их маршруты, вторая — программы с тегами (вместо названий), которые объединяют параметры по типу обработки. **Дальше началось самое интересное: вкладка «Шаги».** График там был красивый, но совершенно бесполезный для быстрого редактирования. Шаги приходилось менять, кликая по линиям на графике — кошмар для пользователя. Решение простое и гениальное: график становится вспомогательным элементом, который открывается по клику или на отдельной вкладке. Основная рабочая поверхность — это таблица, где каждый параметр шага — отдельный столбик. Это консистентно со всем остальным интерфейсом. **Техкарта была переделана в двухуровневую структуру.** Первый таб — основные параметры (название, тип покрытия, описание, временная шкала). Второй — маршрут операций. Здесь момент: на линии может быть несколько ванн одного назначения, которые взаимозаменяемы. Нельзя просто указать «ванна номер 3». Нужна гибкая система выбора. Это отправило замечание на ревью UX дизайнерам — потому что такое редактирование должно быть не просто удобным, а идеальным. **Важное открытие про вкладку «Выпрямители»:** Технолог работает не с отдельными выпрямителями, а смотрит на них как на *часть этапа обработки* всех подвесок, как оператор видит всю линию в одном месте. Мы решили скопировать именно эту логику — показать общий этап, где выпрямитель — это лишь инструмент контроля процесса. **И вот что важно: мы не просто согласились со всеми замечаниями.** Каждое предложение пошло на критический анализ через четырёх экспертов. Дизайнер, архитектор, технолог и разработчик смотрели на каждый пункт через свою линзу: работает ли это на производстве, правильно ли логически, удобно ли технически? Вкладка «Линия» вообще была заклеймена как лишняя — технолог и так зайдёт под оператором, если ему нужна информация о линии. Теперь нужно создать структурированный документ: часть с исходными замечаниями *в том виде, в котором они были озвучены*, и вторая часть — детальная инструкция для прототипирования. Простыми словами, по пунктам, что меняется и как. **Вывод?** Когда разработчик, дизайнер и технолог садятся вместе и *критически смотрят* друг на друга, получается не просто интерфейс — получается система, которую люди на самом деле будут использовать. Что сказал выпрямитель после переделки интерфейса? «Наконец-то мои параметры в нормальной таблице, а не в этом графике!» 😄
Whisper медленнее речи: как мы выиграли 200 миллисекунд
# Ловушка Whisper: как мы разогнали транскрипцию до 0,8 секунды Проект **speech-to-text** нашёл себе больное место: даже на самых "быстрых" моделях Whisper первая фраза обрабатывалась дольше, чем её произносили. Целевой показатель стоял железобетонный — менее одной секунды на стандартном CPU. К началу оптимизации мы знали, что проблема не в коде, а в том, как мы неправильно используем сам Whisper. Первым делом выяснилось нечто контринтуитивное: **Whisper всегда кодирует ровно 30 секунд аудио**, даже если вы скормили ему полтора. Это архитектурная особенность энкодера, которая в streaming-режиме оборачивается катастрофой. Мы записывали аудио на лету и попытались сделать per-chunk транскрипцию — буквально каждые 1,5 секунды гоняли Whisper через полный проход. Математика ужасна: четыре полных прохода энкодера вместо одного. Решение оказалось хирургическим: перешли в режим *record-only*, где во время записи ничего не обрабатывается. Только когда пользователь наконец закрыл микрофон — бах! — один единственный вызов Whisper на полную акустическую ленту. Это потребовало переписать логику в `streaming_pipeline.py` и финализатор в `main.py`, но скорость выросла разительно. Дальше начались микрооптимизации. **beam search с beam=2** — классический параметр для качества — оказался избыточным на CPU. Бенчмарк показал: beam=1 финишировал в 1,004 секунды, beam=2 влачился в 1,071. Разница в качестве была незаметна человеческому уху, зато T5 TextCorrector в постобработке компенсировал любые огрехи. Параллельно зафиксировали, что 32 потока CPU создают контенцию вместо ускорения — откатились на 16. Отключили expensive re-decoding для low-confidence сегментов. Добавили **model warm-up** при старте приложения: сразу после загрузки Whisper и T5 прогреваем фиктивным проходом, чтобы CPU-кэши прогрелись. Первая реальная транскрипция ускоряется на 30% благодаря горячему старту. И вот вишня на торт: добавили поддержку модели **"base"**. Почему раньше никто не пробовал? Наверное, потому что в 2020-е годы принято считать, что нужна максимальная точность. Но бенчмарк открыл истину: `base + T5 = 0,845 секунды`. Это ниже целевого порога! `tiny + T5` едва за ним — 0,969. Даже `small` без постобработки не дотягивал до целевой отметки. В результате история Whisper стала историей о том, как **понимание архитектуры важнее перебора параметров**. Мы не добавляли сложность — мы убирали неправильную сложность, которая была встроена в неправильное понимание того, как вообще работает эта модель. И помните: если ваша микросервисная архитектура в каждом запросе пересчитывает кэши — это не масштабирование, это программирование 😄
Укротил консоль Claude CLI на Windows одной строкой кода
# Консоль Claude CLI срывалась с цепи: как я её укротил Проект `bot-social-publisher` — это наша система автоматической публикации и обогащения контента в социальных сетях. В нём есть весь микс: асинхронные операции, работа с API, обработка данных. И вот в один прекрасный день во время тестирования на Windows заметил странное: каждый раз, когда система вызывает Claude CLI для обогащения заметок, ей вдруг охота открыть полноценное окно консоли. Просто так, ни с того ни с сего. Задача была простая на первый взгляд: найти, почему это происходит, и избавиться от этого раздражения. Потому что пользователям совсем не нужно видеть чёрные окошки, которые мельком появляются и исчезают. Выглядит как баг, а на самом деле — просто недостаток в реализации. **Первым делом** я открыл файл `cli_client.py`, где происходит запуск Claude CLI через `subprocess.run()`. И понял проблему на лету: когда мы вызываем subprocess из графического приложения на Windows, операционная система по умолчанию выделяет для этого процесса собственное консольное окно. Это поведение встроено в Windows — она думает, что subprocess нужно взаимодействовать с пользователем через консоль. **Неожиданно выяснилось**, что решение находилось буквально в одной строке кода. Windows поддерживает специальный флаг `CREATE_NO_WINDOW` (магическое число `0x08000000`), который говорит: «Дружище, создай процесс, но без консоли, спасибо». Я добавил этот флаг в параметры `creationflags` для вызова `subprocess.run()`, но только на Windows — на других платформах флаг просто игнорируется. Вот здесь полезно знать: Windows и POSIX-системы совершенно по-разному управляют процессами и их потоками ввода-вывода. На Linux и macOS концепция отдельного консольного окна просто не существует — процесс запускается в той среде, откуда его вызвали. На Windows же это полноценный механизм с флагами и правами. Именно поэтому в боевом коде всегда нужно проверять `sys.platform == "win32"` перед тем, как применять специфичные для Windows флаги. **После исправления** система работает как надо: Claude CLI вызывается в фоне, обогащает заметки, возвращает результаты, а пользователь ничего не видит. Никаких мелькающих консолей, никаких помех. Просто чистая работа. Закоммитил изменения в `main`, и проблема ушла в историю. Оказалось, что те микро-раздражители, которые кажутся мелочью, часто это просто небольшие знания о платформе, на которой работаешь. Windows не враг, она просто работает не так, как мы привыкли 😄
От хаоса к объектам: как переделали API для трендов
# Регистрируем API эндпоинт: как архитектура трендов выросла из хаоса документации Мне нужно было разобраться с проектом **trend-analysis** — системой для отслеживания трендов из GitHub и Hacker News. Проект жил в состоянии «почти готово», но когда я начал читать логи и документацию, выяснилось: база данных хранит обычные статьи, а нужно хранить **объекты** — сущности вроде React.js или ChatGPT, за которыми стоит десятки упоминаний. Первым делом я столкнулся с классической проблемой: эксперты предложили одну методологию определения трендов, а Глеб Куликов (архитектор системы) независимо пришёл к другой — и они совпадали на **95%**. Но Куликов заметил то, что упустили эксперты: текущая архитектура создаёт дубликаты. Одна статья о React — один тренд, вторая статья о React — второй тренд. Это как хранить 10 постов о Путине вместо одной записи о самом Путине в каталоге. Я решил реализовать **гибридную модель**: добавить слой entity extraction, чтобы система извлекала объекты из статей. Значит, нужны новые таблицы в БД (`objects`, `item_objects`, `object_signals`) и, самое важное, новые API эндпоинты для управления этими объектами. **Вот тут начинается интересная часть.** API эндпоинты я размещал в `api/auth/routes.py` — стандартное место в проекте. Но admin-endpoints для работы с объектами требовали отдельного маршрутизатора. Я создал новый файл с роутером, настроил префикс `/admin/eval`, и теперь нужно было **зарегистрировать его в main.py**. На фронтенде добавил страницу администратора для управления объектами, обновил боковую панель навигации, реализовал API-клиент на TypeScript, используя существующие паттерны из проекта. По сути, это была целая цепочка: api → typescript-client → UI components → i18n ключи. **Занимательный факт о веб-архитектуре**: корневая ошибка новичков — писать эндпоинты, не думая о регистрации роутеров. Flask и FastAPI не магическим образом находят ваши функции. Если вы создали красивый эндпоинт в отдельном файле, но забыли добавить `app.include_router()` в main.py — для клиента это будет 404 Not Found. Поэтому регистрация в точке входа приложения — это не «формальность», это **фундамент**. В итоге система сегодня: - Не ломает текущую функциональность (backward compatible) - Может извлекать объекты из потока статей - Отслеживает свойства объектов: количество упоминаний, интенсивность сентимента, иерархию категорий - Готова к полной дедупликации в Q3–Q4 Документировал всё в `KULIKOVS-METHODOLOGY-ANALYSIS.md` — отчёт на 5 фаз имплементации. Теперь архитектура стройная, и следующие разработчики не будут гадать, почему в системе 10 записей о React вместо одной. 😄 Почему Ansible расстался с разработчиком? Слишком много зависимостей в отношениях.
121 тест в зелёном: как переписать сердце системы и ничего не сломать
# Когда 121 тест встают в строй: история запуска первого зелёного набора Проект `ai-agents` подошёл к критической точке. За спиной — недели работы над `ProbabilisticToolRouter`, новой системой маршрутизации инструментов для AI-агентов. На столе — 121 новый тест, которые нужно было запустить в первый раз. И вот, глубоко вдохнув, запускаю весь набор. Ситуация была напряженная. Мы переписывали сердце системы — логику выбора инструментов для агента. Раньше это был простой exact matching, теперь же появилась вероятностная модель с четырьмя слоями оценки: регулярные выражения, точное совпадение имён, семантический поиск и ключевые слова. Каждый слой мог конфликтовать с другим, каждый мог сломаться. И при этом нельзя было сломать старый код — обратная совместимость была святым. Первый запуск ударил болезненно: **120 пройдено, 1 упал**. Виноват был тест `test_threshold_filters_low_scores`. Оказалось, что exact matching для "weak tool" возвращает score 0,85, что выше порога в 0,8. Сначала я испугался — неужели роутер работает неправильно? Но нет, это было *корректное поведение*. Тест ловил старую логику, которую мы переделали. Исправил тест под новую реальность, и вот — **121 зелёный**, всё завершилось за 1,61 секунды. Но главное — проверить, что мы ничего не сломали. Запустил старые тесты. **15 пройдено за 0,76 секунды**. Все зелёные. Это было облегчение. Интересный момент здесь в том, как мы решали задачу покрытия. Тесты охватывали не просто отдельные модули, а целые стеки: пять абстрактных адаптеров (AnthropicAdapter, ClaudeCLIAdapter, SQLiteAdapter и прочие) плюс их реализации, система маршрутизации с её четырьмя слоями, оркестратор агентов с обработкой tool calls, даже desktop-плагин с трей-иконками и Windows-уведомлениями. Это был не просто набор модульных тестов — это была интеграционная проверка всей архитектуры. **А знаете интересный факт?** Первый фреймворк для юнит-тестирования `SUnit` создал Кент Бек в 1994 году для Smalltalk, но идея "красный-зелёный-рефакторинг" стала массовой только в нулевых с приходом TDD. Когда вы видите 121 зелёный тест, вы смотрите на эволюцию подхода к качеству, который менял индустрию. После этого запуска система стала более уверенной в себе. Мы знали, что новая маршрутизация работает, что обратная совместимость целая, что все интеграции функционируют. Это дало зелёный свет для дальнейших оптимизаций и рефакторинга кода. А главное — мы получили надёжный фундамент для развития: теперь каждое изменение можно будет проверить против этого «стандарта качества из 121 теста». Иногда разработка — это просто ожидание результата консоли. Но когда все полосы зелёные, это чувство стоит каждой минуты отладки. 😄
Логи в системном трее: как простая отладка спасла меню устройств
# Охота на баги в системном трее: как логи спасили день Проект **speech-to-text** — это приложение для распознавания речи с поддержкой выбора аудиоустройства прямо из системного трея. Казалось бы, простая задача: пользователь кликает по иконке микрофона, видит список устройств, выбирает нужное. Но реальность оказалась хитрее. ## Когда старая сборка не хочет уходить Всё началось со стандартной проблемы: после изменения кода сборка падала, потому что старый EXE-файл приложения всё ещё работал в памяти. Казалось бы, что здесь сложного — убить процесс, запустить новый. Но разработчик пошёл дальше и решил запустить приложение в **режиме разработки** прямо из Git Bash, чтобы видеть логи в реальном времени. Это сыграло ключевую роль в том, что произошло дальше. Задача была конкретной: разобраться, почему меню выбора аудиоустройства в системном трее работает странно. Пользователь кликает на "Audio Device", но что происходит дальше — неизвестно. Здесь-то и нужны были логи. ## Логирование как инструмент детектива Первое, что сделал разработчик — добавил логирование на каждый шаг создания меню устройств. Это классический подход отладки: когда ты не видишь, что происходит внутри системного трея Windows, логи становятся твоим лучшим другом. Приложение запущено в фоновом режиме. Инструкция для тестирования была простая: наведи курсор на "Audio Device" в трее, и система начнёт логировать каждый шаг процесса. Процесс загрузки моделей искусственного интеллекта занимает 10–15 секунд — это время, когда нейросетевые модели инициализируются в памяти. Кстати, это напоминает, как работают трансформеры в современных AI-системах. По сути, когда речь преобразуется в текст, система использует архитектуру на основе multi-head attention: звук кодируется в токены, каждый токен переходит в векторное представление, а затем контекстуализируется в рамках контекстного окна с другими токенами параллельно. Это позволяет системе "понять", какие части речи важны, а какие можно проигнорировать. ## Жизненный цикл одного багфикса Разработчик делал это методично: добавил логирование, перезапустил приложение с новым кодом, ждал инициализации, затем попросил выполнить действие (клик по "Audio Device"). После этого — проверка логов. Это не просто отладка. Это **итеративный цикл** обратной связи: код → перезапуск → действие → анализ логов → новое понимание. Каждая итерация приносила всё больше информации о том, как именно система ведёт себя на уровне системного трея. Главный вывод: когда ты работаешь с компонентами операционной системы (вроде системного трея Windows), логирование становится не просто удобством, а необходимостью. Без логов ты работаешь вслепую. ## Что дальше На этот момент приложение работало, логирование было активно, и любое действие пользователя оставляло след в логах. Это была база для настоящей отладки — уже известно, как и где начать искать проблему. Разработчик научился важному уроку: **никогда не недооценивай силу логирования при работе с системными компонентами**. Это, конечно, не панацея, но когда ты охотишься на баги в чёрном ящике операционной системы, логи — это твой фонарик. Если NumPy работает — не трогай. Если не работает — тоже не трогай, станет хуже. 😄
Как мы развязали узел агентов: adapter pattern в боевых условиях
# От паттерна к реальности: как мы завернули AI-агентов в красивую архитектуру Полгода назад я столкнулся с классической проблемой: проект `ai-agents` рос как на дрожжах, но код превратился в сложный клубок зависимостей. LLM-адаптеры, работа с БД, поиск, интеграции с платформами — всё смешалось в одном месте. Добавить новый источник данных или переключиться на другую модель LLM стало настоящим квестом. Решение было очевидным: **adapter pattern** и **dependency injection**. Но дьявол, как всегда, сидит в деталях. Первым делом я создал иерархию абстрактных адаптеров. `LLMAdapter` с методами `chat()`, `chat_stream()` и управлением жизненным циклом, `DatabaseAdapter` для универсального доступа к данным, `VectorStoreAdapter`, `SearchAdapter`, `PlatformAdapter` — каждый отвечает за свой слой. Звучит скучно? Но когда ты реализуешь эти интерфейсы конкретно — начинает быть интересно. Я написал **AnthropicAdapter** с полной поддержкой streaming и tool_use через AsyncAnthropic SDK. Параллельно сделал **ClaudeCLIAdapter** — суперсредство, позволяющее использовать Claude через CLI без затрат на API (пока это experimental). Для работы с данными подключил **aiosqlite** с WAL mode — асинхронность плюс надёжность. **SearxNGAdapter** с встроенным failover между инстансами. **TelegramPlatformAdapter** на базе aiogram. Всё это управляется через **Factory** — просто конфиг меняешь, и готово. Но главная фишка — это **AgentOrchestrator**. Это сердце системы, которое управляет полным chat-with-tools циклом через адаптеры, не зная о деталях их реализации. Dependency injection через конструктор означает, что тестировать проще простого: подай mock'и — и программа думает, что работает с реальными сервисами. Вторая часть истории — **ProbabilisticToolRouter**. Когда у агента сто инструментов, нужно понимать, какой из них нужен на самом деле. Я построил систему с четырьмя слоями scoring: regex-совпадения (вес 0,95), точное имя (0,85), семантический поиск (0,0–1,0), ключевые слова (0,3–0,7). Результат — ранжированный список кандидатов, который автоматически инжектится в system prompt. Никаких случайных вызовов функций. А потом я подумал: почему бы не сделать это ещё и десктопным приложением? **AgentTray** с цветовыми индикаторами (зелёный — работает, жёлтый — обрабатывает, красный — ошибка). **AgentGUI** на pywebview, переиспользующий FastAPI UI. **WindowsNotifier** для уведомлений прямо в систему. И всё это — тоже адаптеры, интегрированные в ту же архитектуру. **Интересный факт**: паттерн adapter родился в 1994 году в книге «Gang of Four», но в эру микросервисов и облачных приложений он переживает второе рождение. Его главная суперсила — не столько в самом коде, сколько в психологии: когда интерфейсы чётко определены, разработчики начинают *думать* о границах компонентов. Это спасает от копипасты и циклических зависимостей. По итогам: 20 новых файлов, полностью переработанная `config/settings.py`, обновленные requirements. Система теперь масштабируется: добавить нового LLM-провайдера или переключиться на PostgreSQL — это буквально несколько строк конфига. Код более тестируемый, зависимости явные, архитектура дышит. И главное — это работает. Действительно работает. 😄
Реставрация после краха: как чекпоинты спасли мой ML-марафон
# Марафон обучения модели: как я перезагрузил сервер посередине тренировки Проект **llm-analysis** требовал обучения нескольких моделей параллельно. На доске стояла амбициозная задача: запустить шесть вычислительных процессов (их называют квартами — Q1 и Q2, по 3 чекпоинта каждая), каждый из которых должен пройти 150 эпох обучения. Время было критично: каждый день задержки — это дополнительная неделя на GPU. Первым делом я запустил квартет Q1. Все три модели (1.1, 1.2, 1.3) стабильно обучались, постепенно повышая accuracy. Первый квартет завершился успешно — все чекпоинты сохранились на диск. Так что Q1 был зелёным сигналом. Затем начал Q2. Запустил пару 2.1 и 2.4 параллельно, оставляя GPU свободным для 2.2 и 2.3 после их завершения. Модели ползли вверх: 2.1 достиг 70.45%, 2.4 — 70.05%. Всё шло по плану. Но тут случилось неожиданное — сервер перезагрузился. Паника? Нет. Именно поэтому я сохранял чекпоинты после каждых 50 эпох. Когда машина поднялась, я проверил состояние: Q1 полностью в сохранности, Q2 остался с двумя готовыми моделями (2.1 и 2.4). Зато 2.2 и 2.3 потеряли прогресс — были на 68–69%, но восстанавливались с последнего сохранённого чекпоинта. Тут я понял классическую проблему long-running ML-задач: **checkpoint strategy** — это не просто "хорошая практика", это страховка от Murphy's Law. Если ты тренируешь модель часами и не сохраняешь состояние каждый час, ты играешь в рулетку. Запустил 2.2 и 2.3 повторно. Мониторю GPU: 98% загрузки, 10.5 GB памяти занято. На этот раз 2.2 рвёт вперёд — через час достиг 70.17%, а затем и 70.56%. А 2.3, как ленивый ученик в конце четверти, упорно ползёт с 56% к 62%. ETA для 2.2 — 8 минут, для 2.3 — ещё 2.5 часа. **Главное, что я выучил:** не полагайся на непрерывность вычислений. Планируй архитектуру обучения так, чтобы каждый этап был самодостаточен. Чекпоинты должны быть не роскошью, а основой. И не забывай про версионирование моделей — того, что ты обучал неделю назад, может не быть завтра. Пара 2.5 и 2.6 ждут в очереди. GPU будет готов через пару часов. План прост: запустить, убедиться, что новые модели устойчивы к сбоям, и уже не волноваться. 😄 **Совет дня:** если ты тренируешь нейросеть на сервере — перезагрузка не будет сюрпризом, если ты всегда сохраняешь checkpoints. А ещё лучше — настрой автоматический рестарт обучения при падении процесса.