Как писать «скучные» API-автотесты на Go: выносим всю инфраструктуру в Axiom, оставляя в тестах только бизнес-сценарии, и запускаем всё в CI/CD с Allure.
Привет!
Сегодня расскажу о GoMCP — production-grade альтернативе официальному MCP SDK от Anthropic. Спойлер: получилось в 10 раз быстрее, с multi-tenancy и enterprise-фичами из коробки.
100K+ tool calls/sec (vs ~10K у Python SDK)
Security hardening: input validation, audit logging, rate limiting
Multi-tenancy: изоляция namespace + квоты
3 адаптера: stdio (MCP v1), gRPC, HTTP REST
213 тестов, 430+ Full Ralph итераций
Для начала хотелось бы сказать, что же такое массивы и слайсы.
Массив в Go — это структура данных, которая представляет собой упорядоченную последовательность элементов одного типа фиксированной длины.
Давайте рассмотрим на примере:
Привет, Хабр.
Хотим вам рассказать об одной из первых наших новинок 2026 года, которую с тем же успехом можно считать и вторым изданием, и переизданием отлично зарекомендовавшей себя книги о микросервисах. Речь под катом пойдёт о книге Юлии Поповой «Go: разработка приложений в микросервисной архитектуре с нуля».
И даже до выхода у этой книги уже есть история.
Переписать решение с Python на Go и получить ускорение в 35 раз — звучит приятно. Но можно ведь пойти дальше, вспомнить о возможностях современных процессоров и увеличить отрыв Go до 200 раз! Статья написана по мотивам доклада для Golang Conf.
Привет, Хабр! Я — Игорь Вагулин, работаю тимлидом департамента IaaS в Cloud.ru, крупнейшем в России облачном провайдере IaaS- и PaaS-сервисов. Прогресс в производительности процессоров и видеокарт привел к тому, что мы можем использовать полный перебор там, где мы раньше обходились приближениями. Сегодня на примере алгоритма DRS-платформы Cloud.ru Evolution рассмотрим, как он может быть решен на разных версиях операций с плавающей точкой процессоров x86 и Arm, в чем сложности задействования SIMD-операций, почему это сложнее на Go и как это обойти.
Неделю назад мы опубликовали статью «Почему финтеху нужен капитальный ремонт„, а до этого „От стартапа к протоколу: Почему мы решили написать свой „PostgreSQL для финансов“„. Мы получили много комментариев — от умеренных до резко критических. И я хочу начать с благодарности.“““»
Спасибо тем, кто нашел баги в нашем UI (мы всё поправили). Спасибо тем, кто писал «зачем это нужно, если есть PostgreSQL?». Спасибо даже тем, кто называл проект «велосипедом„.“»
Именно ваша критика заставила нас пересмотреть приоритеты и за неделю реализовать то, что мы откладывали месяцами: Atomic PvP (атомарный обмен валют) и ISO 20022 "в ядре".
Мы поняли, что не смогли донести главную мысль. Qazna - это не просто "еще один леджер". Это попытка ответить на вопрос, который IT-сообщество почему-то боится задавать.
Вчера я баловался с проектом API, которым занимаюсь уже долгое время. Подобные проекты мы обычно переписываем снова и снова на протяжении многих лет, чтобы поддерживать высокий уровень дофамина от рефакторинга. Вы понимаете, о чём я. На этот раз совершенно внезапно я кое-что осознал. Мне нужно отрефакторить одну вещь. Я достаточно активно пользуюсь UUID, поэтому URL моих ресурсов очень длинные и некрасивые.
В зависимости от версии и варианта в UUID есть множество разной информации, но по большей мере это куча случайных битов, которые и обеспечивают свойство «универсальной уникальности», которое нам так нравится. Но если по какой-то причине вам не нравится проверенный временем стандарт с огромной экосистемой нативной поддержки... то эта статья для вас!
В первой части было разобрано, как настроить RLS в Go, почему is_local=true спасает от утечек в PgBouncer, и как покрыть это интеграционными тестами. Если вы еще не настроили базовую изоляцию, начните оттуда.
Сегодня мы пойдем глубже. Мы не будем говорить о синтаксисе. Мы поговорим об архитектуре. О том, почему RLS - это не просто "удобный фильтр", а нативный механизм инкапсуляции, который решает проблемы распределенных систем и рисков безопасности прямо в слое данных, не раздувая Ops-сложность до сотен схем и баз.
Кому и зачем читать?
Junior/Middle: Поймете, почему RLS - это архитектурный выбор, а не просто WHERE tenant_id = ?. Узнаете про TOCTOU и как его избежать.
Senior/Architect: Увидите паттерны для highload (партиционирование + RLS) и production-грабли (матвьюхи, репликация).
В ноябре 2024 года язык программирования Go достиг своего исторического максимума — седьмого места в престижном индексе TIOBE, укрепив позиции в топ-10. Однако всего через 14 месяцев, в январе 2026 года, картина кардинально изменилась: Go обвалился на 16-е место, потеряв сразу 9 позиций. Это один из самых драматичных спадов года среди топовых языков. Парадокс в том, что в России Go переживает противоположную тенденцию — язык активно набирает популярность, его используют крупнейшие технологические компании и количество Go-разработчиков превысило 40 тысяч. Возникает критический вопрос для отечественной индустрии: не движемся ли мы против глобального технологического тренда, делая ставку на язык, который теряет позиции на мировой арене?
Я давно увлекаюсь и изучаю технологии WebRTC. Устанавливал для клиентов множество WebRTC медиа серверов и кастомизировал их. Но постоянно не хватало гибкости. В итоге обнаружил чистую реализацию WebRTC на Golang, которая умеет и MESH, и SFU. Сейчас буду рассказывать, что удалось разработать и в чем польза.
Команда AI for Devs подготовила перевод статьи о том, как выжать максимум из маленьких языковых моделей. Автор показывает, что даже очень компактные LLM могут быть полезны в реальных задачах — если правильно работать с контекстом, embeddings и RAG.
В мире разработки есть негласное правило: не пишите свою криптографию. В финтехе должно быть похожее правило: не пишите свой леджер (ledger) на SQL, если планируете масштабироваться.
Меня зовут [Имя], и я хочу рассказать, как мы прошли классический путь «изобретения велосипеда», набили шишки на race condition-ах и в итоге поняли, что индустрии нужен не очередной необанк, а открытый стандарт финансового учета. Так появился проект Qazna.
В этой статье я не буду продавать вам продукт. Я покажу код, архитектурные решения и то, как мы пытаемся сделать «Linux для финансов».
Устали от десятка открытых терминалов с kubectl port-forward? В этой статье я расскажу, как написал PortFwd — TUI-приложение на Go для управления множеством port-forward соединений в одном окне. Разберём архитектуру, работу с client-go, построение интерфейса на Bubble Tea и реальные грабли, на которые я наступил. Статья будет полезна DevOps/SRE инженерам и Go-разработчикам, интересующимся Kubernetes.
Go 1.22 заметно укрепил позиции стандартной библиотеки в роли «достаточно хорошего» веб‑стека: ServeMux научился матчить шаблоны, и зависимость от роутеров ради базовой маршрутизации уже не выглядит обязательной. Но как только в проекте появляется больше пары middleware, начинается знакомая боль — обёртки размножаются, порядок теряется, правки становятся хрупкими.
В этой статье разбираем, как собрать управляемые цепочки middleware без alice и как поверх http.ServeMux сделать группировку маршрутов с наследованием middleware в стиле chi — только на стандартной библиотеке и с минимальным количеством кода.
Команда Go for Devs подготовила перевод отчёта команды Go о результатах Go Developer Survey 2025 (опрос проходил в сентябре 2025, публикация — 21 января 2026). Главные сигналы: разработчикам не хватает понятных best practices и более «современных» возможностей в языке и встроенных инструментах; ИИ-инструменты уже стали повседневностью, но качество и предсказуемость всё ещё подводят; а справка go по базовым подкомандам вроде go build, go run и go mod слишком часто вынуждает лезть в документацию.
Мы продолжаем наше погружение в мир аутентификации и будем разбирать всё на простых примерах с практикой на Go.
В первой части статьи мы разобрали, как устроен JWT, зачем нам refresh и access токены и почему в распределенных системах нам необходимо использовать асимметричные алгоритмы подписи.
Теперь пришло время двигаться дальше и познакомиться с тем, что стоит поверх JWT: JWKS, OAuth 2.0, OIDC.
Как я построил систему мониторинга LLM-приложений и научил AI анализировать собственные ошибки
AI-ассистенты в IDE стали незаменимыми помощниками разработчиков, но остаются чёрными ящиками. Мы не видим что они делают "под капотом", сколько это стоит и где теряется время. В статье покажу как построить системуobservability для AI-агентов: от Cursor IDE до production, с AI-анализом трейсов и открытым исходным кодом.
AI агенты в 2026: гайд для тех, кто всё еще пишет код руками.
Как устроены агенты типа Claude Code, ChatGPT Codex и др. Как правильно с ними работать. Как управлять контекстом. Как прогать голосовухами из тг.
В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе.
Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут.
Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть.
Почему стандартные решения не подошли?
Перебрал классическую тройку вариантов, и у каждого нашлись фатальные минусы для задачи:
1. Логическая изоляция (WHERE в коде)?
Как это работает: Тысячи строк кода, и в каждом запросе ты обязан помнить про tenant_id.
Проблема: Человеческий фактор. Это бомба замедленного действия.
2. Схема на клиента (Schema-per-tenant)
Как это работает: У каждого клиента своя схема (schema_01, schema_02...).
Проблема: Это работает, пока клиентов 100. Когда их становится 10 000, база начинает задыхаться.
Детали: Проблема даже не в миграциях, а в файловой системе. 10 000 клиентов × 50 таблиц = 500 000 файлов. Postgres (и Linux) сходят с ума от такого количества открытых дескрипторов, а VACUUM превращается в ад.
3. Отдельная БД на клиента
Как это работает: Полная физическая изоляция.
Проблема: Ценник на инфраструктуру. Держать тысячи коннектов или инстансов RDS - экономическое самоубийство для стартапа.
Тогда посмотрел в сторону PostgreSQL Row Level Security (RLS). Честно говоря, поначалу было страшно. Отдавать логику безопасности "черному ящику" внутри БД казалось рискованным. Плюс, все вокруг пугали: "RLS убьет производительность".
Команда Go for Devs подготовила перевод статьи о том, действительно ли атомарные операции всегда быстрее и лучше мьютексов в конкурентном коде. Автор разбирает реальные сценарии, показывает бенчмарки и объясняет, почему рост производительности часто оборачивается ростом сложности и рисков для корректности.
