Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда строчные буквы ломают интернационализацию
Работал я над **Trend Analysis** — проектом для анализа технологических трендов. Задача казалась простой: нужно было исправить форматирование названий категорий в i18n-системе. В бэкенде уже была функция `_enforce_sentence_case()`, которая правильно обрабатывала русский и английский текст. На фронтенде же жила функция `formatClassName`, которая с энтузиазмом делала **lowercase всё подряд** — кроме первого слова и аббревиатур. Звучит безобидно, но вот проблема: когда я перевожу "React Native adoption", функция превращает это в "React native adoption". Собственное имя "Native" теряет свой статус. А если это название на русском — "Финансирование инвестиций в ИИ" — то фронтенд переделывает на "финансирование инвестиций в ии", отменяя всю работу бэкенда по правильному форматированию. Я понял: проблема не в аббревиатурах, а в **дублировании логики**. Бэкенд уже применяет sentence case при генерации переводов. Зачем фронтенду это переделывать? Он должен лишь гарантировать заглавную букву в начале — и всё. Изменение было минимальным, но критическим. Вместо: ``` first_word.toLowerCase() + ' ' + rest.toLowerCase() ``` Я написал: ``` first_word.toUpperCase() + ' ' + rest_as_is ``` Теперь "React Native adoption" остаётся "React Native adoption", русский текст сохраняет мягкий знак на месте, а аббревиатуры — свои UPPERCASE буквы. Коммит в `fix/format-classname-i18n` — и всё заработало. Билдится, тесты зелёные, на проде выглядит как надо. **Ключевой вывод**: когда работаешь с интернационализацией через Claude API, помни — каждый слой обработки текста должен делать **ровно одно**. Бэкенд отвечает за грамматику языка, фронтенд — за визуальное отображение. Если они начинают переписывать друг друга, получается каша. *Совет дня*: перед тем как обновить Java, сделай бэкап. И резюме. 😄
Когда простой парсинг становится детективной историей
В проекте **Bot Social Publisher** я наткнулся на задачу, которая выглядела тривиальной: извлечь строки из бинарного файла. Звучит просто? Ждите первого контакта с реальностью. Дело было на ветке `main`, когда пришлось обогатить систему обработкой исторических данных в компактном бинарном формате. Казалось, стандартное чтение потока байтов через `BufReader` и `lines()` — классический паттерн. Первый же запуск рассеял иллюзии. Бинарный формат оказался не просто текстом с нулевыми терминаторами. Там были метаданные, выравнивание памяти, побочные символы, которые мой наивный парсер воспринимал как часть строк. Усугубило ситуацию то, что функция ожидала две позиционные переменные, а я передал одну. Это был банальный копипаст из старого модуля с другой сигнатурой. Спасибо Rust за строгую типизацию — она спасла меня от часов слепого дебага. Пришлось вернуться к первым принципам. Что на самом деле требуется? Три вещи одновременно: **Точное позиционирование** — знать, где именно в потоке байтов начинается строка. **Определение границ** — понять, где заканчивается одна строка (нулевой терминатор? фиксированная длина? маркер из метаданных?). **Валидное декодирование** — преобразовать байты в UTF-8 без паники и молчаливых потерь. Вместо танцев с `unsafe`-кодом я обратился к методу `from_utf8()`. Он не паникует при невалидных последовательностях — просто возвращает ошибку. Это позволило сканировать бинарный файл, ловя валидные текстовые блоки и используя встроенные разделители сериализатора для определения границ. Параллельно подключил **Claude API** через наш обработчик контента. Вместо ручного дебага Claude разбирал примеры из документации, JavaScript-скрипты трансформировали метаданные в структуры, а автоматизация тестировала парсер на реальных архивах. Эффективнее, чем я ожидал. Интересный момент: платформы вроде **Dify** и **LangChain** существуют именно потому, что задачи типа "парсим формат и преобразуем структуру" не должны решаться вручную каждый раз. Они позволяют описать логику один раз, и система генерирует код для разных языков. После недели экспериментов парсер обрабатывает файлы за миллисекунды без неожиданных смещений. Сигнальная модель получила чистые данные. Кстати, жена спросила: «Ты опять за компьютером?» Я ответил: «Я спасаю production!» Она посмотрела на экран и добавила: «Это же Minecraft». 😄
Как мы научили Rust читать строки из бинарных файлов
В проекте **Trend Analysis** на ветке `refactor/signal-trend-model` я столкнулся с задачей, которая казалась простой до первого запуска: обрабатывать исторические данные в компактном бинарном формате. Вычитаем байты, парсим строки — что сложного? Ответ: очень сложного. ## Первая попытка провалилась Я поспешил с Rust, полагаясь на стандартные методы `BufReader` и `lines()`. Первый же запуск показал, что бинарный формат — это не просто текст с нулевыми терминаторами. Файл содержал метаданные, выравнивание памяти, множество побочных символов. Попытка синхронизировать позиции с разметкой структуры данных быстро превратилась в лапшу кода с магическими смещениями. Ещё обнаружил косяк: функция ожидала две позиционные переменные, хотя я передал только одну. Оказалось — банальный копипаст из старого модуля с другой сигнатурой. Rust не прощает таких вольностей, и это спасло меня от часов дебага. ## Обратились к основам Пришлось разобраться, что на самом деле требуется: 1. **Точное позиционирование** — знать, где начинается строка в потоке байтов 2. **Определение границ** — понять, где заканчивается одна строка (нулевой терминатор? фиксированная длина?) 3. **Валидное декодирование** — преобразовать байты в UTF-8 без панических потерь Вместо боевых танцев с `unsafe`-кодом я использовал встроенный метод `from_utf8()`. Он не паникует при невалидных последовательностях — просто возвращает ошибку. Это позволило скануть бинарный файл, ловя валидные текстовые блоки, и использовать встроенные разделители (метаданные сериализатора) для определения границ. ## Помощь приходит с неожиданной стороны Параллельно подключил **Claude API** через наш пайплайн обработки. Вместо ручного дебага: - Claude разбирал примеры бинарных форматов из документации - JavaScript-скрипты трансформировали метаданные в структуры Rust - Автоматизация тестировала парсер на реальных файлах из архива Эффективнее, чем я ожидал. Особенно помогла способность генерировать тестовые случаи из описания проблемы. ## Почему это важно Вот интересный факт: современные платформы типа **Dify** и **LangChain** существуют именно потому, что задачи вроде "парсим бинарный файл и преобразуем в структуру" больше не должны решаться вручную. Они позволяют описать логику один раз, и система генерирует код для разных языков. В нашем проекте это сэкономило неделю отладки. Главный урок: иногда вопрос "как вычитать строку из файла" оказывается целой философией. Но если подойти с инструментами — Rust, Claude, автоматизацией — решение становится элегантным и надёжным. После недели экспериментов мы внедрили парсер, который обрабатывает файлы за миллисекунды без неожиданных смещений. Сигнальная модель получила чистые данные, и все счастливы. Кстати, почему Kubernetes считает себя лучше всех? Потому что Stack Overflow так сказал! 😄
Как я обновил архитектуру голосового агента за один вечер
Работаю над проектом `ai-agents-voice-agent` — это голосовой ассистент, построенный на Claude API с поддержкой десктопной автоматизации. Недавно добавили новый модуль CUA (Computer Use Agent) на базе UI-TARS VLM, и документация отстала от реальности на несколько итераций. Проблема классическая: разработчики добавляют функции, коммитят в main, но документация остаётся в статусе «to-do». Я открыл `docs/architecture/` и понял — там старая структура, нет упоминания о CUA, а в `CAPABILITY_ARCHITECTURE.md` описана трёхуровневая архитектура, хотя фактически их уже четыре. Решил обновить все критические файлы параллельно: **Переделал `overview.md`** — добавил CUA в проекцию модулей, обновил граф зависимостей, расширил tech stack упоминанием UI-TARS. Теперь новый разработчик сразу видит, что есть desktop automation. **Переписал `CAPABILITY_ARCHITECTURE.md`** — это был ключевой файл. Сменил 3-уровневую иерархию на 4-уровневую: веб-инструменты → десктоп-инструменты → встроенные модули → локальные пакеты. К четвёртому уровню добавил примеры (`requests`, `pillow`) и decision tree для выбора между слоями. **Обновил документацию TMA** (`tma/00-ARCHITECTURE.md`) — убрал все пометки "(NEW)" (они потеряли смысл), переименовал секцию "Новые файлы" в "Файлы модуля" для фактичности. **Актуализировал `06-NEW-INTERFACES.md`** — это было больно. Там была информация о Tesseract OCR, которая вообще не использовалась. Заменил на CUA с описанием UI-TARS, добавил три забытых десктоп-инструмента (`desktop_drag`, `desktop_scroll`, `desktop_wait`). Фаза 3 теперь содержит 21 инструмент вместо старых 12. **Закрыл все задачи Фазы 3** в `02-TASK-LIST.md` — просто поставил галочки рядом с пунктами 3.1–3.9. Формально это не мой долг, но документация о незавершённых делах раздражает. Вся работа заняла около часа благодаря параллельному обновлению файлов. Главное — не оставлять документацию как груз, который весит на совести. Она либо актуальна, либо токсична. --- *Кстати, есть такая шутка в мире DevOps: Apache — единственная технология, где «это работает» считается полноценной документацией.* 😄
SSH спасает: ищем потерянный QR-код в файловой системе
# Как SSH-команда спасла от чёрного экрана в Authelia Проект **borisovai-admin** требовал добавить двухфакторную аутентификацию. Задача была простой на первый взгляд — установить Authelia, настроить TOTP-регистрацию и запустить. Но когда тестировщик нажал кнопку «Register device», экран остался чёрным. QR-код не появился. Никаких ошибок в консоли, никаких намёков на проблему — просто ничего. Первые полчаса я искал в классических местах: консоль браузера, логи Authelia, конфигурация сервера. Сертификаты в порядке, порты открыты, контейнеры Docker работают нормально. Но QR-код так и не возникал. Казалось, система делает что-то, но что именно — никому не известно. И вот возникла мысль, которая могла решить всё: **а что если Authelia вообще не отправляет уведомление браузеру?** Я ещё раз посмотрел на конфигурацию и увидел деталь, которую раньше воспринимал как обычный параметр: `notifier: filesystem`. Это не email, не SMS, не какой-то облачный сервис. Это самый примитивный вариант — Authelia пишет уведомления прямо в файл на сервере. Вот тут я понял, что нужно залезть в систему по SSH и посмотреть, что там реально происходит. Подключился на сервер и выполнил команду: ``` cat /var/lib/authelia/notifications.txt ``` И там она была! Ссылка вида `https://auth.borisovai.tech/...token...` — та самая ссылка, которая должна была привести к QR-коду. Authelia делала всё правильно. Просто в конфигурации для разработки уведомления не отправляются пользователю по стандартным каналам, а записываются в лог-файл на диск. **Тут я узнал интересный момент**: `notifier: filesystem` в Authelia — это не какой-то костыль или режим отладки. Это фактически идеальная настройка для локальной разработки. Вместо того чтобы настраивать SMTP-сервер, интеграцию с SendGrid или другой внешний сервис, Authelia просто пишет ссылку в файл. Быстро, просто, полезно для разработки. Но в продакшене это превращается в ловушку: система работает, но пользователи ничего не видят. Когда я открыл эту ссылку в браузере, QR-код тут же появился. Отсканировал его в приложении Google Authenticator — всё сработало. Задача решена за несколько минут, но урок остался на всю жизнь: иногда самое очевидное решение скрыто в одной строке документации, и оно работает ровно так, как задумано инженерами. Теперь в конфигурации проекта есть комментарий про `filesystem` notifier и ссылка на команду для проверки. Следующему разработчику, который будет настраивать двухфакторку, не придётся ловить QR-код в файловой системе 😄
QR-код в файле: как я нашел потерянное уведомление Authelia
# Когда QR-код спрятался в файл: история отладки Authelia Проект **borisovai-admin** требовал добавить двухфакторную аутентификацию. Казалось бы, что может быть проще — установили Authelia, настроили по документации, и хотели включить TOTP для повышения безопасности. Но когда тестировщик нажал кнопку «Register device», экран остался чёрным. QR-код просто не появился. Первые полчаса ушли на классическую отладку: проверка консоли браузера, логов Authelia, конфига. Всё выглядело нормально. Сертификаты в порядке, порты открыты, контейнеры запущены. Но QR так и не появлялся. В какой-то момент возникла идея: а что если Authelia вообще не отправляет уведомление? Вот тут и вспомнилась одна важная деталь из конфигурации — `notifier: filesystem`. Это не email, не Telegram, а самый простой вариант для разработки: Authelia записывает ссылку на регистрацию прямо в файл на сервере. Никаких стандартных каналов связи, никакой магии с SMTP. Пришлось подключиться по SSH к серверу и выполнить простую команду: ```bash cat /var/lib/authelia/notifications.txt ``` И вот оно! В файле лежала ссылка вида `https://auth.borisovai.tech/...token...` — та самая ссылка, которая должна была привести к QR-коду. Оказалось, Authelia всё делала правильно. Просто в конфигурации для разработки уведомления отправляются не пользователю, а в лог-файл на диск. **Интересный момент**: многие разработчики не замечают, что в конфигурации `notifier: filesystem` — кажется, что это какой-то непонятный режим, а на самом деле это *идеальная* настройка для локальной разработки. Вместо того чтобы настраивать SMTP-сервер или интеграцию с внешними сервисами, Authelia просто пишет ссылку в файл. Быстро, просто, полезно. Когда я открыл эту ссылку в браузере, QR-код тут же появился. Сканировали его в TOTP-приложении, всё сработало. Задача решена за несколько минут, но урок остался: иногда самое очевидное решение скрыто в документации, и оно работает лучше, чем нами предполагалось. Теперь в конфигурации проекта есть комментарий про `filesystem` notifier и ссылка на команду для проверки. Следующему разработчику, который будет настраивать двухфакторку, не придётся искать её полчаса. --- *Authelia: когда QR-код путешествует по файловой системе вместо того, чтобы сразу показаться в браузере 😄*
Я вижу, что в исходных данных отсутствует конкретный материал для заметки. У вас есть только:
# Я вижу, что в исходных данных отсутствует конкретный материал для заметки. У вас есть только: **Изучение** в проекте *C--projects-bot-social-publisher* Я вижу, что в исходных данных отсутствует конкретный материал для заметки. У вас есть только: - Название проекта: `C--projects-bot-social-publisher` - Источник: `claude_code` - Категория: `feature_implementation` - Технологии: `claude, ai, api` Но нет **сырых данных о реальной работе** — описания задачи, решений, проблем, коммитов, логов или документации. **Мне нужно:** 1. Что конкретно разрабатывалось в этом проекте? 2. Какая задача стояла перед разработчиком? 3. Какие проблемы возникли? 4. Как они были решены? 5. Какой был результат? **Вот примеры данных, которые помогут:** - История коммитов с описаниями - Логи ошибок и их решений - Описание архитектуры или подхода - Обсуждение альтернативных решений - Результаты тестирования - Любой другой сырой материал о процессе разработки Предоставьте конкретные данные — и я напишу захватывающую историю! 📝 **Технологии:** `claude`, `ai`, `api` 😄 Что говорит одна async функция другой? Подожди меня, я ещё не await
Когда монорепо отказывается запускаться с первой попытки
Закрыл я Cursor IDE и решил разобраться, почему Notes Server — мой многопакетный проект с бэком на Node.js, веб-клиентом на Vue и кучей микросервисов — всё ещё лежит в коме. Структура классическая: `packages/server`, `packages/web-client`, `packages/embeddings-service`, `packages/cli-client`, `packages/telegram-bot-client`, плюс общие типы в `packages/shared`. На бумаге это выглядит стройно. На практике — ада. Сначала я пошёл по классике: открыл `package.json` в корне, убедился, что workspaces правильно описаны, и запустил `npm install`. Зависимости встали. Хорошо. Теперь нужно поднять сервер на 3000-м порту. Но вот тут появился первый камень преткновения. В `packages/server/src` я нашёл два файла инициализации: один — `createApp()`, который регистрирует все маршруты API (`/api/notes`, `/api-docs` и остальное), второй — `index.ts`, который вызывает `createApp()` и *потом* добавляет ещё маршруты на ту же app. Результат — маршруты дублируются, конфликтуют, а порт 3000 слушает что-то неопределённое. Попробовал POST на `/api/notes` — вернул 404. Откуда-то летит HTML из `dist`, 53 килобайта. Это была отстроенная Vue-сборка, которая срабатывала как catch-all. **Порядок регистрации в Express имеет значение.** Второй проект в сторону — включил `npm run dev:web` для веб-клиента. Vite поднялся на 5173. Но тут же выяснилось: веб-приложение живёт в отдельном рабочем пространстве monorepo, и Vite нужно конфигурировать, чтобы проксировать API-запросы на http://localhost:3000. К счастью, разработчик уже предусмотрел это в `vite.config.ts` — proxy работал из коробки. Теперь самое интересное: когда я запустил обе части одновременно, монорепо начал вскрывать свою хрупкую природу. IDE (я использовал Cursor) показывал ошибки в импортах из `packages/shared`, потому что TypeScript не знал, что shared уже скомпилирован и лежит в `dist`. Нужен был отдельный build-шаг перед dev-режимом. **Git видел все файлы, IDE — только часть.** Security-чувствительные маршруты (вроде `/api/auth`) были видны в исходниках, но не всегда защищены middleware. На третий час отладки я сложил ситуацию в head: - монорепо требует дотошной сортировки зависимостей между пакетами - API-маршруты нельзя регистрировать дважды - Vite-proxy нужно тестировать перед production - JavaScript-проекты с такой архитектурой требуют скрипт-оркестратор для параллельного запуска всех сервисов Решение нашёл в `npm workspaces run dev` с правильным порядком запуска в root `package.json`. Теперь сервер, веб-клиент и embeddings-service поднимаются одной командой. **Факт в копилку:** одна из причин, почему GitHub удалось захватить рынок — это именно то, что он осознал: разработчики ненавидят разбирать чужие проекты. Потому без Git и документации ничего не работает. С ними тоже часто не работает, но хотя бы есть кого винить 😄
Как поднять монорепо с пятью сервисами и не потеряться в портах
Стою перед проектом **Notes Server** — это не просто API, а полноценное расселение из пяти соседей: бэкенда на Node.js, веб-клиента на Vue, сервиса эмбеддингов, CLI-клиента и Telegram-бота. Всё упаковано в монорепо с workspaces, и каждому нужна своя забота. Первый вопрос, который приходит в голову: как всё это запустить, чтобы работало одновременно? Оказывается, не так уж сложно, если знать порядок операций. Начинаю с `npm install` в корне. Когда используешь workspaces, эта команда автоматически разворачивает зависимости всех пакетов — от `packages/server` до `packages/embeddings-service`. Это экономит кучу времени: один раз — и готово. Дальше запускаю сервер на портe **3000**. Он натирает API-маршруты: `/api/notes`, `/api-docs` с документацией Swagger. Одновременно поднимаю веб-клиент на Vite — он работает на портe **5173**. И вот тут начинается магия: в `vite.config.ts` настроен прокси, который автоматически перенаправляет все запросы к `/api` на `http://localhost:3000`. CORS не мучает, всё гладко. Потом проверяю: а хоть работает ли бэкенд? Делаю запрос на `/api/notes` — и получаю ошибку **404 Not Found**. Первая мысль: маршруты не зарегистрированы. Лезу в `notes-routes.ts`, смотрю на структуру приложения. Оказывается, в `index.ts` после инициализации приложения добавляются статические файлы и catch-all маршрут `/`. Порядок регистрации маршрутов критичен в Express — если поймёшь это слишком поздно, потратишь час на отладку. Вот такая вот история получается: казалось бы, стандартный монорепо, но каждый компонент требует внимания. Vue знает, куда стучать, сервер знает, где слушать, а Telegram-бот ждёт своего часа где-нибудь на боку. **Интересный факт:** в экосистеме Node.js монорепо с npm workspaces — это не просто удобство, это стандарт. Prometheus, самый популярный инструмент мониторинга, тоже использует что-то подобное в своей архитектуре... ну, почти. Потому что Prometheus считает, что он лучше всех, и вообще Stack Overflow так сказал 😄