Go *

В первой части я показывал agent-memory-mcp v0.1.0: MCP-сервер на Go + SQLite, который даёт AI-агентам persistent memory, semantic search и RAG по документации проекта.

Во второй части разбираю, что изменилось после нескольких месяцев реального использования. Почему fallback между embedding-моделями оказался опаснее отказа, зачем понадобились local-only режим и reembed, почему одного semantic search мало для инженерной памяти, как появились session close, Claude Code hooks, canonical knowledge, stewardship, sedimentation и multi-hop recall.

Это не changelog, а разбор эволюции архитектуры: как простой memory tool вырос в memory backbone для инженерных агентов — слой, который не просто хранит заметки, а помогает поддерживать актуальное, проверенное и полезное знание проекта.

Загнивая от усталости, дописывая последнюю строчку последнего (или не очень) модуля системы, теша себя мыслями о скорой зарплате, каждый уважающий себя философ задаётся вопросом - а как контролировать в бою всё то, что мы написали¿¿

Глупец скажет - никак, мы же покрыли тестами.

Хитрец скажет - Grafana+Prometheus отдельными сервисами.

Психопат на крайней стадии выгорания скажет - поднимем отдельную админку и будем собирать метрики и инциденты без прометеуса, снимая снимки системы каждую минуту асинхронными воркерами под каждый компонент платформы, включая сервер, базу данных, объектное хранилище и кэш. На лету будем высчитывать дельты серверных метрик, а в завершение отрисуем всё это дело без графаны, силами Recharts и Святого Духа, упакуем в отдельную панель для технических администраторов и наконец - сделаем клиентский status-page платформы.

Yggdrasil - это экспериментальная оверлейная IPv6 mesh-сеть, уже неоднократно обсуждавшаяся на хабре. Под катом рассматриваем ее использование в качестве встраиваемой библиотеки в вашем go приложении.

Когда разработчик слышит слова “математический анализ”, в голове часто всплывает что-то из университета: пределы, производные, интегралы, бесконечные ряды, многостраничные доказательства и ощущение, что все это находится очень далеко от реальной работы. На практике все устроено иначе.

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

Проблема обычно не в том, что матан бесполезен. Проблема в другом: его часто преподают как отдельный мир формальных конструкций, а разработчику нужен другой взгляд, более инженерный. Не “докажите теорему по Коши”, а “объясните, как изменяется функция, почему вычисления могут быть нестабильны и как это связано с кодом”.

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

Я создал еще одну библиотеку SNMP на Go, но это не просто еще одна SNMP библиотека а библиотека созданная сетевым инженером, каждый день работающим с различным оборудованием.

Библиотека создавалась без оглядки на аналогичные а основной целью было написание различно ПО для мониторинга и управления оборудованием в реальных сетях.

Мне был необходим фундамент для создания:

Многоканальных сенсоров для PRTG

Утилит для сбора данных с сетевого оборудования, таких как MAC/ARP таблицы, режим работы портов, их состояние, информация о POE, информация о CDP/LLDP соседях и многое другое.

Приемника SNMP Trap/Inform сообщений версии 3 (с поддержкой смешанных трапов, как версии 2c так и 3 и с различными параметрами шифрования и аутентификации, то есть например часть оборудования шлет Trap и использует пользователя SNMPuser и использует шифрование DES, а часть использует пользователя useram и использует шифрование AES-256).

Утилит управления портами, POE и прочими функциями оборудования

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

Были изучены и учтены проблемы SNMP агентов на некотором оборудовании, с которыми мы столкнулись при использовании как gosnmp так и net-snmp и прочих библиотек.

Это вводная статья и надеюсь не последняя.

Что регулярно ломается в реальных сервисах, когда надо совместить YAML, .env, переменные окружения и вложенный Config.

Kubernetes давно стал повсеместной платформой, а написать к нему собственный оператор сегодня — задача нескольких часов. Стандартный путь — kubebuilder на основе controller-runtime: scaffold проекта, типы, реконсайлер. В типовых сценариях этого вполне достаточно. Но как только нагрузка растёт или поведение оператора начинает расходиться с ожиданиями, всплывает целый класс edge-кейсов, причина которых — непонимание того, как controller-runtime устроен внутри. Если вы пишете контроллеры для Kubernetes, этот материал поможет собрать целостную mental model и заранее избежать дорогих сюрпризов в проде.

В этой статье разберём внутреннее устройство controller-runtime и на его примере увидим, какие архитектурные решения лежат в основе самого Kubernetes. Начнём с того, как контроллеры читают объекты из Kubernetes API.

Есть распространённое заблуждение, что r.Get() в Reconcile ходит прямо в kube-apiserver, List() каждый раз смотрит «живую» картину мира, а после Update() можно сразу перечитать объект и увидеть свежее состояние. На практике всё наоборот: controller-runtime живёт на локальной копии данных через LIST+WATCH. Благодаря этому чтение в реконсайле обходится почти бесплатно и не нагружает control plane даже при сотнях вызовов в секунду — но ценой этой модели становится то, что оператор может внезапно съедать гигабайты памяти, делать скрытые O(n)-сканы и регулярно упираться в stale reads.

Статья рассчитана на тех, кто уже писал операторы на Go с использованием controller-runtime, но хочет собрать целостную mental model, а не жить с набором частных наблюдений. Фокус будет на практических последствиях для production-кластеров: память, трафик, консистентность чтения и поведение реконсайла.

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

Через пару дней я взяла LSM-дерево, мемтейбл на B-дереве(что временно) и компакшн. Дальше были и атомарные батчи, fsync, все хотелось оптимизировать, добавить отказоустойчивости, сделать все более быстро, серьёзно и чтоб хоть где-то полезно.

Я расскажу из каких частей состоит мой движок, почему принимала те или иные решения, где у меня все было не так гладко, компромиссы, что до сих пор не работает и отложено в долгий ящик. Если вы когда-нибудь писали свой storage — очередь, кэш, или свое NoSQL хранилище — мой опыт поможет вам в принятии некоторых решений.

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

Сегодня познакомим вас с самой долгожданной новинкой апреля — книгой «Алгоритмы на языке Go», которую мы успели выпустить в продажу 30 числа.

С типом float рано или поздно сталкивается почти любой разработчик. Сначала все выглядит просто. Есть float32, есть float64, можно хранить дробные числа, делить, умножать, считать проценты, средние значения, коэффициенты и что угодно еще. Кажется, что это просто «числа с точкой». Но именно здесь у многих начинаются странные баги.

Почему 0.1 + 0.2 != 0.3? Почему после серии вычислений число внезапно становится 9.99999999997 вместо 10? Почему сравнение двух значений с float64 иногда работает, а иногда ломает логику? Почему в деньгах float почти всегда плохая идея? И почему даже корректная формула может давать нестабильный результат? Проблема не в Go. Проблема в том, что float устроен не так, как его часто себе представляют. Это не «точное дробное число», а приближенное представление вещественных чисел в памяти компьютера.

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

В микросервисной архитектуре ошибка — это не просто баг в отдельном сервисе. Это сорванный релиз, нестабильные интеграции, потерянные заказы и часы дорогой ручной проверки. Когда сервисов десятки, а релизы идут постоянно, цена отсутствия системной автоматизации становится слишком высокой.

Уже больше полутора лет я пишу автотесты на Go. За это время мы прошли путь от «зачем вообще тестировать на Go?» до «почему мы не сделали это раньше?».

В этой статье я покажу, как внедрить автоматизацию тестирования на Go с нуля — так, чтобы она решала реальные бизнес‑проблемы, а не просто увеличивала количество тестов в репозитории.

В Go легко написать код, который компилируется, но раздражает при чтении: слишком длинные receiver’ы, странные имена пакетов, лишние повторы в вызовах, хаотичный регистр и utils, который постепенно превращается в свалку. Для начинающего Go-разработчика соглашения по именованию могут выглядеть как набор мелких вкусовых правил, хотя на практике они влияют на навигацию по проекту, читаемость API и стоимость будущего рефакторинга.

В статье разберем основные правила и идиомы именования в Go – от идентификаторов и пакетов до методов, интерфейсов и геттеров – с примерами удачных и неудачных решений.

Продолжение прошлой статьи про ошибки на Go-собесах. В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”.

Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26.

Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.

Знаете, кому 29 апреля стукнуло 30 лет? Спецификации FastCGI. Тридцать лет с 1996 года. Погодите. Эта заметка не про ностальгию по .fcgi-скриптам, которые на каждый запрос форкали отдельный процесс и которыми сегодня никто не пользуется. И не про CGI вообще.

Разговор о другом. У нас всех в проде между прокси и бэкендом обычно стоит HTTP. nginx перед Go-приложением, Caddy перед Python-сервисом, Apache перед PHP-FPM, неважно, поверх там HTTP/1.1 или HTTP/2. И вот Эндрю Айер на agwa.name к юбилею FastCGI собрал аргументы, что этот участок инфраструктуры всё это время сидит на не самом удачном протоколе. Айер основатель SSLMate, и в SSLMate всё крутится на FastCGI в проде уже больше десяти лет. Так что пишет не теоретически.

Заметка короткая и по делу. HN-тред собрал сотню комментариев, для 2026 года это не топ, но там пишут люди, которые знают, о чём говорят. Если попроще, аргумент такой: у HTTP как протокола между прокси и бэкендом есть два структурных бага, которых у FastCGI нет, и индустрия за тридцать лет так и не нашла повода переехать. А обсуждение в треде ушло дальше: почему вообще HTTP победил, если он хуже технически. И ответ оказался любопытнее самого аргумента.

Мой рабочий день - это код. Вечером я хочу разговаривать с кем-то по-английски, а не нажимать на пингвинчиков.

Duolingo учит меня заказывать яблоки, ChatGPT-чат отлично объясняет грамматику - но не помнит, что я разбирал Present Perfect в среду и опять путаю его с Past Simple в пятницу.

Я хотел простую штуку:

написать модели «давай сегодня про багтрекеры»;

получить чат на 15 минут;

а в конце - три новых слова, которые она же мне и подобрала по уровню B1.

Чтобы завтра эти слова всплыли в упражнениях.

Через месяц получился Lexis:

Go · Clean Architecture · 4 LLM-модели · SSE-стриминг · JWT rotation + reuse detection

MIT, открытый репозиторий.

В статье - три инженерных якоря, которыми я доволен:

Pluggable AI-провайдеры через интерфейс из трёх методов.

SSE вместо WebSocket для стриминга AI-ответов.

JWT rotation + reuse detection как production-ready стандарт, а не «потом перепишем».

Плюс честный список того, что ещё не готово.

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

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

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

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

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

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

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

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

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

Когда один зависимый сервис начинает отвечать медленнее, проблема быстро перестает быть локальной: горутины ждут, соединения заканчиваются, таймауты разъезжаются по всей цепочке. Circuit breaker помогает остановить этот каскад до того, как он положит соседние части системы. В статье разберем, как написать простой breaker на Go примерно за 100 строк, где у такой реализации границы применимости и почему production‑библиотека gobreaker устроена гибче.

Привет! Меня зовут Александр. Некоторые могут помнить мои статьи про финансовую аналитику на Python — анализ ETF, оптимизацию портфелей. Но последние 6 лет я Senior Go Backend Engineer, специализируюсь на финтехе и трейдинге.

Эта комбинация — domain expertise в финансах + техническая экспертиза в Go — оказалась очень ценной. Но путь был тернистым.

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

Привет, Хабр! Меня зовут Даниил Подольский, я программист и архитектор, разрабатываю программное обеспечение и спецификации для создания ПО в YADRO. Вот уже девять месяцев я использую методологию Spec-Driven Development (SDD) в работе и управляю AI-агентами, которые пишут код. При этом я не считаю себя вайбкодером, потому что мой подход к работе более комплексный, чем просто «общение с AI».  

Это первая статья из цикла об оборудовании рабочего места SDD-кодера. Я расскажу о базовой настройке AI-агента Claude Code: что делать, если вы хотите оперативно и без перезагрузки переключать используемые модели и делать это для каждого проекта отдельно.

Сегодня я хочу рассказать про то, как гетеросексуальный бэкендер (до этого момента коим я себя в той или иной степени считал) переживает болезненный опыт построения клиентской части платформы. Ради интереса недавно я посмотрел, сколько примерно строк на данный момент насчитывает репозиторий фронтенда Kroncl (название платформы), и приятно удивился числу 70.

Сделаю поправку на то, что очевидно: объём кода не свидетельствует о его чистоте и виртуозном ведении (опытные читатели скорее установят обратную зависимость).