Open source *

Неделю назад я писал, почему видео из аниме-плеера нельзя просто вставить в <video>. Вывод был такой: нужен серверный видеопрокси, и никуда вы от него не денетесь.

Потом я перенёс тот же проект на телефон, и прокси перестал быть нужен. Не потому, что я придумал обход, а потому, что оба ограничения, из-за которых он существовал, оказались браузерными, а не сетевыми.

Под катом: что именно делал сервер, почему на Android его нет, и что оказалось не переносом библиотеки с Python на Dart, а её переписыванием — вместе с багом, который жил в оригинале, стрелочной функцией в Dart, из-за которой whenComplete начинает ждать сам себя, и релизом, который подписывает не человек.

Сгенерированная картинка для привлечения внимания. Промпт: «Продемонстрируй, что всё новое — это хорошо забытое старое» (нет)

За последний год инструментов для агентной разработки стало столько, что в них легко потеряться: одни обещают сохранять контекст между сессиями, другие — «понимать» всю кодовую базу целиком, третьи — память, планирование и автономность в одном флаконе. На GitHub каждую неделю появляются репозитории с внушительным (и не всегда честно заработанным) числом звёзд, которые обещают всё и сразу, а на поверку оказываются README-проектами; другие честно работают на демо-репозитории и падают с OOM при первой же встрече с реальным энтерпрайз-проектом — и так далее, список можно продолжать долго.

Осенью прошлого года я пользовался связкой Claude + RooCode + семантический поиск на Ollama, и это был мой основной рабочий инструмент — ровно до того момента, как связка перестала работать (об этом чуть ниже). Я решил полностью пересесть на Claude Code и начал искать замену семантическому индексу, но так её и не нашёл: альтернативы для меня просто не работали — на монолите в 3,5M+ строк они либо индексировались часами, либо требовали отдать код в облако (и заплатить немалую сумму за эмбеддинги!!!), либо поддерживали Ruby, мягко говоря, номинально. В итоге я принял непростое для себя решение сделать собственный инструмент — начав с форка простого движка семантического поиска на Ollama + Qdrant — и, что характерно, сделал: полностью локальный, чтобы ни код, ни его производные (индекс, эмбеддинги, граф вызовов) никуда не уезжали. На сегодняшний день на него ушло больше полугода (и, честно признаюсь, не одна сотня чашек чая).

Маршрут в .route.xml на том же движке, что и C#: подсказки в VS Code, проверка пакета в dotnet build, граф-редактор и горячая замена модуля.

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

В 4.0 у redb.Route появилась вторая запись маршрута: XML. Файл .route.xml кладётся в пакет, пакет в папку работающего сервиса, и меньше чем через полсекунды по новому маршруту идёт первое сообщение. При этом ...

Гугл-док держится на сервере, который выстраивает все правки в один порядок. Убираем сервер: две копии правятся офлайн и обязаны сойтись символ в символ. Разбираю, как это устроено внутри, на движках, которые сам портировал на Go.

В одном из тестов моего humanizer-ru оценка “машинности” ответа упала с 0,95 до 0,10. Сам ответ при этом не изменился ни на букву: “Столица Австралии - Канберра”. Из файла убрали строки вокруг него, включая название чат-бота.

В другой паре тексты отличались лишь переводом строки в конце файла. Оценки всё равно разошлись: 0,9 и 0,3.

Эти пары лежат в открытых данных проекта. По общей таблице я раньше делал вывод о качестве редактирования, но теперь эта интерпретация отозвана. Разбираю, что именно я измерил на самом деле и как это проверить самому.

Модель эмбеддингов читает только первые несколько сотен токенов документа, а остальное молча отбрасывает. Теперь Manticore Search сам разбивает длинные документы при INSERT: добавьте chunk_strategy к векторному столбцу и выберите одну из пяти стратегий. Без конвейера загрузки и библиотек для разбиения текста. На нашей документации recall@5 для текста за пределами окна модели вырос с 55% до 83%.

Пятая часть про локальный ассистент для созвонов. В первой части я написал: ничего не уходит в облако. Облако появилось на второй день проекта, потому что большая модель одним чтением стенограммы находила то, чего локальная не видела. Что уходит с машины при каждом из пяти тумблеров и в каком объёме, почему остался Opus, как каждая третья ревизия не доезжала из-за усилия, а не размера промпта, и где сегодня проходит граница между локальным и облачным.

А вы тоже организуете общение между микросервисами по HTTP/1.1 + JSON? Так вот, адекватные люди на хайлоаде давно так не делают.

Как это выглядит в классическом REST: какой-нибудь сервис заказов стучится в сервис оплаты и отдаёт JSON-файлик: {"user_id": 123, "amount": 1000}. Принимающий сервис этот текст читает, парсит, валидирует, переводит в машинный код...

JSON сделан для людей. Человеку удобно читать JSON, потому что это текст. Но серверу для обработки текста приходится тратить драгоценные такты процессора на поиск и разбиение. Ещё классический HTTP тащит за собой гигантские заголовки с метаданными. Часто они весят больше, чем сама полезная нагрузка. Ещё если вы передаете число 123456789, в JSON оно займёт 9 байт (по байту на символ), а в бинарном виде — всего 4 байта.

Гугл ещё в 90-х это посчитал. Они со своими масштабами столкнулись с проблемами за 10 лет до того, как с ними столкнулся весь остальной мир. Для DNS-а в Гугле сделали внутреннюю систему Borg-NS. Они пытались сделать предка gRPC, чтобы решить две фундаментальные проблемы. Во-первых, зоопарк технологий. Когда у тебя тысячи микросервисов — одни на Java, другие на C++, третьи на Python, четвёртые на Go (ладно, этих тогда точно не было) — им нужен единый язык общения. Нужно было запилить стандарт: описали спецификацию интерфейса в одном независимом стиле — и система сама сгенерировала готовый сетевой код для всех нужных языков.

А во-вторых — это как раз производительность обмена.

Поэтому сейчас используется gRPC. И вот когда началась какая-то там по счёту волна санкций, внезапно выяснилось, что в России нет поддержки серверов gRPC.

7 лет назад я опубликовал в npm свою первую библиотеку — custom‑border‑mixin. Тогда я на неделю пропал, просто чтобы в своё удовольствие написать SCSS‑миксин. Если вам интересно, что весёлого может быть в SCSS, просто посмотрите на хелпер:

Код skillmem прошёл два независимых ревью, и я считал его чистым. Потом две модели с разных сторон — Claude и GPT — сорок раундов подряд читали его враждебно, обязанные воспроизводить каждую находку командой. Шесть P1 и около двадцати пяти P2 в коде, который «уже был отревьюен», и главный урок: каждый второй фикс рождал регрессию, которую ловил только следующий раунд.

Заказчик — страховая компания, которая имеет ключевое значение для устойчивости российской экономики. Среди ее клиентов финансовые организации, промышленные предприятия, транспортные компании, а также исполнители крупных инфраструктурных проектов.

Проект решил три задачи одновременно: гарантировал выполнение требований законодательства по импортозамещению без потери функциональности, сохранил независимость от конкретного вендора и обеспечил официальную поддержку с SLA. Работа с Хоулмонт позволила реализовать все это и не останавливать развитие проекта даже тогда, когда Camunda сменила бизнес-модель.

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

Модульная архитектура ускорила отклик интерфейса и упростила дальнейшее развитие системы.

В IT я больше двадцати пяти лет, в Android — почти пятнадцать. Оказалось, что этого мало.

Опыт никуда не делся. Я по‑прежнему знаю, чем интерфейс отличается от абстрактного класса и в чём разница между val и var. Но работать по‑старому стало тяжело. В требованиях всё чаще стояло не знание Kotlin и Compose, а умение вести разработку с ИИ. Не «пробовал Copilot», а именно вести: ставить задачу, разбирать результат, замечать, где инструмент уверенно врёт.

Вместо привычных TDD, BDD, DDD и FDD вокруг всё чаще звучали AIDD и SDD. Дошло до того, что на работе в карточках JIRA появилось обязательное поле «уровень использования ИИ» со значениями «полностью выполнено агентом» и «частично выполнено агентом». Варианта «выполнено самостоятельно» там нет. Намёк понятен.

Назад пути не было, пришло время меняться.

Учиться по статьям смысла нет — там всё получается. Нужен был настоящий проект, достаточно большой, чтобы в нём было где ошибиться.

Тему выбрал не случайно. Хотел разобраться не только в том, как пользоваться ИИ‑агентами, но и в том, как их делать. Так и вышло: агента я писал с помощью агента.

Получилось приложение. Через полгода оно лежит в Google Play, я пользуюсь им каждый день, и это уже давно не учебная работа. Дальше — как оно из неё выросло: через три смены курса (учебный проект стал продуктом, Gemini CLI сменился на Claude Code, маршрутизатор на два выхода стал графом), одну стену, в которую я въехал на полном ходу, и запуск, который не сработал.

Что-то много пеликанов на велосипеде начало появляться в ленте моего информационного пузыря в твиттер и я решил провести собственный эксперимент: GPT Astra против Qwen 3.8 и других доступных моделей.

Цель: Охватить экспериментом повседневные модели, которые можно легко проверить на качество генерации и получить сравнительную оценку их способностей.

Если вы ищите работу и у вас много телеграм-каналов с вакансиями, слова апи, python, гитхаб вам знакомы, то вам будет полезно. Мой кейс: когда я искала работу то смотрела по 50+ постов в день в десятках каналов в телеге, из них подходящих вакансий было штук 10, одна и та же вакансия висит в четырёх каналах, половина постов это курсы и "ищу работу", фильтров никаких. Платить за агрегатор мне не хотелось.

Собрала свой сервис, который вы можете адаптировать под любую роль: скрипт читает папку каналов в Telegram, отсеивает не-вакансии, вытаскивает компанию, грейд, город и зарплату, склеивает дубли и раз в день выкладывает одну страницу с фильтрами на GitHub Pages. Стоимость - ноль, ключи нужны только от Telegram.

Расскажу, как мы отказались от внешних серверов, безболезненно пережили переезд, избежали сбоев в высокий сезон и сократили расходы на эксплуатацию чатов в 100 (сто!) раз. Эта история — о нашем пути от Firebase к Centrifugo.

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

Это GitSpawn: восемь находок в семи кодинг-агентах. Агентам уже выкатили патчи, и это почти ничего не меняет, потому что твой собственный git status в той же папке по-прежнему выполняет чужой код. Проверял руками на git 2.53.0 и Claude Code 2.1.271.

В данной статье расскажу про проект logporter, который для меня полностью заменил решение от Google для централизованного и полнофункционального мониторинга контейнеров Docker.

Экспортер написан на Go и совмещает функции сборщика метрик, логов, проверки обновлений образов и встроенной панели мониторинга в одном легковесном образе.

Три года назад я поставила себе задачу: с пару десятков устройств, ноль облачных зависимостей, и чтобы всё крутилось на своей железке в шкафу. За последние 22 месяца правда упало дважды, но всего-лишь на минуты. Задержка от «нога переступила порог» до «свет зажёгся» — 110 миллисекунд. Я это мерила, и очень очень этим гордилась. А жить теперь в доме с повышенным IQ стало хуже. Почему? Об этом ниже.

«Просто прикрутить вход через Steam и цены из маркета» — примерно так это выглядит из бэклога. На деле: OpenID 2.0 образца 2007 года вместо OAuth, звёздочка ★ в имени ножа, из-за которой одно и то же название готовится для двух соседних эндпоинтов противоположными способами, и цена, приходящая строкой в чужой локали. Собрал все проблемы в одном месте.

В прошлой статье я закончил на том, что следующая часть серии, скорее всего, уже выйдет за границы самого Obsidian‑плагина, в Companion и MCP. Вышла.

За это время Vault Audit AI успел обзавестись отдельным сервером, MCP‑интерфейсом для AI‑клиентов, механизмом предложений изменений и вторым репозиторием.

А потом стало понятно, что старое название уже довольно плохо объясняет, что вообще происходит. Поэтому теперь проект называется Veynrel.

Сам плагин при этом не был переписан с нуля. Существующим пользователям не нужно ничего переустанавливать, заново вводить API‑ключи или перестраивать semantic index. Я специально постарался сделать самый скучный ребрендинг из возможных с технической точки зрения.

Зато вокруг самого плагина стало заметно интереснее. Сейчас всё это в упрощённом виде выглядит так: