Open source *

При работе с Claude Code я столкнулся с проблемой: по мере роста числа агентов стало сложно синхронизировать их правила между машинами и окружениями. Параллельно возник риск — потерять все наработки (скилы, команды, конфигурации) при смене аккаунта или среды.

Я решил считать ~/.claude/ обычным кодом и хранить его в Git.

Так появился claude-config-template — репозиторий, из которого ~/.claude/ собирается через симлинки. В нём лежат скилы, агенты, команды, хуки и MCP-конфигурации.

Это даёт:
- переносимую конфигурацию между машинами
- единый источник правды для всех агентов
- версионирование и откат через Git

Привет, Хабр.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Задача была простая: протестировать два веб-приложения перед деплоем. Next.js-портфолио и SaaS-чат — accessibility, консольные ошибки, отзывчивость на мобильных. Рутина.

Открыл Claude Code, подключил Playwright MCP, написал «протестируй приложение». Агент начал работать, делать скриншоты, проверять элементы. На 51-м снапшоте /compact сработал. Текстовый контекст был заполнен на 18%. Я не понял что произошло.

Через час разбирательств я нашёл невидимый image-лимит. Через три часа — понял, что Playwright MCP сжигает в 50 раз больше токенов чем CLI на том же workflow. Через три дня — у меня был рабочий инструмент, который уже тестируют реальные пользователи.

Эта статья — про путь от «хочу просто протестировать» до open-source инструмента, и про архитектурные проблемы, которые заставили его собрать.

У меня на столе стоит небольшая золотистая коробочка размером чуть больше Mac mini. Внутри — приватный AI-сервер: чат с локальной 26B-моделью, поисковая индексация моих документов с GPU-парсингом, конструктор агентов в Dify, RAGFlow для тяжёлого парсинга PDF, мониторинг, бэкапы, опциональный кластер из двух машин по QSFP 200G. Тридцать контейнеров, пять минут на установку через sudo bash install.sh, ноль обращений к внешним API.

Я делал это не как pet-project, а под себя — мне нужна была машина для работы с корпоративными документами, договорами и регламентами, которые ни при каких условиях нельзя отдавать в облачные ассистенты. Сборка получилась самостоятельным дистрибутивом — назвал его AGmind, выложил на GitHub под Apache 2.0.

В статье разберу:

— из чего собран стек и зачем там каждый компонент; — почему RAGFlow пришлось пересобрать с нуля и что я туда добавил; — как устроен кластер из двух Spark'ов; — пять конкретных грабель GB10, которые я ловил вечерами; — почему Claude Code за месяц превратил один из этих компонентов в работающий продукт, но при этом не заменил собственно программиста.

TL;DR

Я сделал библиотеку для генерации PDF на Java, в которой:

Документ описывается семантически (модули, секции, параграфы, таблицы, слои), а не через moveTo/lineTo/showText.

Layout и рендер — это два разных прохода. Геометрия резолвится один раз, потом её рисуют. Поэтому документ можно тестировать до того, как написан хотя бы один байт PDF.

Под капотом — ECS-архитектура в стиле игровых движков: Entity / Component / System. Сущности документа лежат в EntityManager, компоненты прицепляются и снимаются, системы (LayoutSystem, PaginationSystem, RenderingSystem) работают над ними.

Тестирование трёхуровневое: unit → layout-снапшоты (как у Jest для React) → визуальная регрессия по PNG-диффу.

На простом инвойсе библиотека идёт 2.45 мс (iText 5 — 1.57 мс, JasperReports — 4.45 мс). На стресс-тесте: 50 потоков, 5000 документов, 0 ошибок, ~2000 doc/sec.

Это статья про задумку и инженерные решения, которые получились нетривиальными. Если вам интересно, как декларативный UI, ECS и снапшот-тесты влезают в одну библиотеку для PDF — заходите.

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

Всем привет. В этой статье расскажу о новостях касаемо Loki. О том что было представлено на GrafanaCON 2026 в Барселоне. Чего нам ждать от новой архитектуры Loki, как она будет работать, и что прячет под капотом.

«Дуров, верни стену» – мем старый, но точный. ВКонтакте начала 2010-х была, при всех своих недостатках, одним из последних мест в рунете с по-настоящему живой лентой. Не алгоритмической, не персонализированной до тошноты – просто всё подряд от всех, на кого подписан. Новости соседствовали с мемами, мемы – с чьей-то репостнутой статьёй про квантовую физику, которую ты никогда не дочитаешь, но пролистаешь с удовольствием. Была случайность, была живость, был сам факт того, что ты не знаешь, что увидишь следующим.

Потом ВК превратился в то, во что превращается каждая платформа – в алгоритмический прямоугольник, оптимизированный под время на сайте. Мы переехали в Telegram. Telegram честнее: хронологический порядок, никакого умного ранжирования, читаешь то, на что подписался. Но одна вещь так и не появилась – единая лента. В ВК у тебя была стена, куда всё стекалось само. В Telegram двадцать каналов – это двадцать отдельных мест, которые надо обходить руками каждый день.

Папки? Пробовал. Папки – это шкаф. Они раскладывают каналы по полочкам, но за каждой полкой всё равно надо открывать каждый ящик отдельно. Единого потока нет.

Ботов-агрегаторов в маркете штук пять – все сломаны по одной и той же причине: Bot API физически не видит каналы, в которых бот не является администратором. То есть публичный новостной канал с миллионом подписчиков – недоступен. Бот читает только то, куда его добавили руками, а никто не добавляет чужих ботов в админы своих каналов. Логично, но бесполезно.

В какой-то момент я окончательно устал и собрал своё.

Мы в Beeline Cloud продолжаем рассказывать про опенсорс-разработку в Китае. В первой статье вспомнили, как привезли в страну Linux, во второй обсудили, как менялась китайская экосистема до 2020 года. Сегодня говорим о том, как большие языковые модели с открытыми весами стали флагманом китайского опенсорса.

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

Цель - протестировать производительность трёх систем объединения физических устройств в одно логическое систем при использовании iSER и NVMe-oF. Так как статья получилась объёмная, она поделена на 2 части. В этой части - тесты с использованием HCIbench и iSER\NVMe-oF

Смысл данной статьи показать максимальную производительность, когда вопрос сохранности данных решается репликами или бэкапами.

Цель - протестировать производительность трёх систем объединения физических устройств в одно логическое систем при использовании iSER и NVMe-oF. Так как статья получилась объёмная, она поделена на 2 части, в первой идут тесты на уровне локального устройства + вступление. Во второй уже тесты с использованием HCIbench и iSER\NVMe-oF

Сперва — откуда взялась идея?

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

Сейчас это не проблема — нейросетей куча, особенно для генерации изображений. Но есть минусы: на платных сервисах можно хорошо так разориться, особенно для пет-проекта. Есть решение — Stable Diffusion, генерировать на своей видеокарте.

Первые шаги с Stable Diffusion

Для работы с локальным SD есть несколько инструментов. Взял первый и, наверное, самый популярный — Automatic1111. Сгенерировал — получил полную фигню. Начал читать, что пишут. Оказывается, уже создано огромное количество предобученных моделей и LoRA для добавления тех функций, что модель не умеет. Результат стал сильно лучше.

Дальше — промпты, то есть текстовое описание того, что мы должны получить на итоговом изображении. Там тоже есть свои рекомендации. Модель не читает мысли пользователя, ей нужно более точно и в понятном ей виде предоставить описание. Дополнительно разбираемся с настройками генерации — samplers, steps и т.д. Всё осуществимо, но получаем другую проблему: для генерации одной картинки мы очень долго подбираем все эти значения и тексты.

Первая автоматизация

Чтобы упростить процесс, я сделал следующее. Для наполнения контента в игре есть админка — обычный CRUD на Symfony. Дополнительно в отдельной папке лежат файлы со всем лором книги/игры.

В итоге я создал два провайдера. Первый — для общения с локальной LLM, которая по нужному запросу берёт необходимый контент из папки с лором и составляет корректный промпт для SD. Второй — для SD, где заданы предварительные настройки: используемая модель, LoRA и вместе с промптом всё это отправляется в SD, и мы получаем итоговую картинку. Несколько попыток, потому что с первого раза вряд ли получим нужное. Получаем более-менее адекватный результат и идём в Photoshop — убрать лишнее, сжать и т.п.

Скажите роботу «настрой манипулятор» — и он напишет драйвер сам. Звучит как фантастика из тех самых фильмов 80-х и 90-х, но мы уже реализовали это в OpenGrall. Рассказываю, как работает режим Инженера и почему последнее слово всегда остаётся за человеком

Итак, вы нашли своего идеального кандидата. Возможно, он даже очень силён, но спустя 2 месяца всё ещё не вышел на ожидаемую продуктивность. Более того, вы заметили, что производительность команды только снизилась, потому что другие инженеры тратят время на онбординг нового человека.

Наверное, я не открою Америку, если скажу, что это довольно тревожный сигнал.

Причём часто в проекте уже есть документация. Очень много документации. Есть обучающие вебинары по продукту, отдельный портал со всеми схемами, ссылки на внутренние страницы, доступы, инструкции, записи созвонов и ещё несколько документов “это обязательно прочитай”. Но почему-то это всё равно не помогает быстро войти в систему.

Почему?

Потому что слишком много информации, высыпавшейся на голову даже очень квалифицированному человеку, часто работает как отсутствие информации. Формально информация есть, ее даже много. Практически человек всё равно не понимает, с чего начать, что важно прямо сейчас, а что можно оставить на потом.

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

Моя гипотеза в том, что каждый кусочек информации, который мы даём новому инженеру, должен быть максимально выверен. Это должен быть минимум на каждом этапе, который даст максимум понимания. 

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

Привет! Меня зовут Даниил Ткаченко, я веб‑разработчик в ИТ‑компании «Активика». В статье я поделюсь опытом развёртывания Sentry self‑hosted для высоконагруженного проекта. Несмотря на обилие материалов по SaaS‑версии, актуальных гайдов по self‑hosted‑установке почти нет — особенно с учётом современных требований к производительности и отказоустойчивости.

Мы столкнулись с рядом проблем: нестабильностью на базовом хостинге, отсутствием перехвата HTTP‑ошибок и быстрым заполнением диска. Под катом разберу каждую проблему, покажу код решений и дам рекомендации для тех, кто планирует развернуть Sentry самостоятельно.

Статья будет полезна разработчикам и DevOps‑инженерам без опыта работы с self‑hosted Sentry.

Понадобилась мне семантика - не в смысле «один раз глянуть Wordstat в браузере», а программно, чтобы прогонять по 50-100 фраз в день и складывать результаты в свою базу. Контекст: веду контент-маркетинг для агентства разработки чат-ботов BotKraft, статьи под Яндекс Нейро. Веб-Wordstat для такого объёма не вариант - копировать вручную из таблички полдня. Direct API - слишком дорогой вход: нужен рекламный аккаунт, отдельный OAuth, у меня этого не было и заводить ради одного метода не хотелось.

Случайно полез в новые сервисы Yandex Cloud AI Studio (там сейчас живёт YandexGPT) и обнаружил, что Wordstat теперь есть в Search API v2 - отдельным сервисом без зависимости от Direct. Доступ - обычный API-ключ из AI Studio, тот же что и для YandexGPT. По сути в один клик получаешь ещё и доступ к семантике.

Подключал, по дороге собрал коллекцию граблей. Этим и поделюсь.

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

В одно время между парами по актерскому и сценречью у нас образовался перерыв в несколько часов, и зумерши притащили небезызвесную игру «Шпион». Реализована она была на минималках даже для web-а из 90-х: нужно было внести список играющих, а потом передавать смартфон по кругу для получения персональной инфы. Интерфейс текстовый.

Кто не знает правила, напомню: все, кроме одного игрока (шпиона) узнают некое слово, место, историческое событие. В процессе общения нужно задавать друг-другу вопросы, чтобы вычислить того, кто не имеет представление, о чем речь, поймать шпиона. А шпион должен вести себя так, чтобы его не заподозрили, и по этим всем разговорам постараться угадать, о чем все знают и говорят. В общем, выигрывает либо шпион, правильно угадавший общий секрет, либо добропорядочные граждане.

Вопросы могут быть самыми разными: Это на улице или в помещении? Это для детей или взрослых? Можно ли на этом ездить? Это едят? И т. д.

«Шпион», при всей кажущейся его простоте забавлял нас много дней. Но мне, как айтишнику со стажем большим, чем те, с кем я учусь, было дико видеть, как для игры, явно претендующей на сетевую, нужно передавать чей-то смартфон из рук в руки. Так получилось, что я в это время активно работал над своим LOTIS, о котором писал здесь уже. И вот в какой-то из вечером я сделал сетевого шпиона, чем несказанно удивил своих коллег, будущих актеров. Заодно и протестировал LOTIS в режиме чата.

"Я выложил библиотеку на GitHub в четверг. В пятницу её клонировал AI-агент, а в субботу конкурент запустил идентичный SaaS." Такое будущее если еще и не наступило, но уже возможно очень скоро. Мы вошли в эру «вайб-кодинга», где софт пишется по наитию промптами, а скорость копирования превысила скорость осмысления. Встаёт неудобный вопрос: если вас могут повторить за сутки, стоит ли вообще публиковать код и пытаться строить продукт?

Объектный построитель SQL-запросов без ORM и моделей. Позволяет писать сложные SQL-запросы в виде цепочек Python-методов (table[‘person’].filter(…).join(…).get()) и получать результат в виде списка словарей. Под капотом — параметризованные запросы для защиты от инъекций, продуманная система кеширования с инвалидацией по таблицам (in-memory и Redis), поддержка синхронного и асинхронного кода из коробки. Для тех случаев, когда ORM избыточна, а сырой SQL небезопасен.

Ох уж этот мир свободного ПО! Хотите создавать проекты, которые покорят мир? Пожалуйста. Хотите просто развеяться и проверить, где же предел гибкости Linux? Этим можно заниматься сколько угодно.

Хотите конкретный пример? Их есть у меня, причем один из них совсем свежий. Шринукс, или Shrek Linux, появился буквально пару дней назад. Это полноценная операционная система с нескучными обоями, где буквально каждая деталь отсылает к мультфильму про болотного огра. К слову, создатель не стал ограничиваться парой обоев — он погрузил в атмосферу Шрека все, что только можно было кастомизировать.