Бэкенд

Код, контейнеры и немного ИИ. GoCloud 2026: трек «Приложения и разработка»

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

Вот что разберут в докладах:

• AI Assisted Cloud Workflow: автоматизация облачных сценариев в эпоху ИИ — поделимся инструментом, который убирает ручную склейку сервисов: просто берете готовый шаблон, а ИИ-ассистент помогает собрать все от архитектуры до бизнес-логики. Полезно тем, у кого нет выделенного архитектора на каждый проект.

• Артефакты в масштабе: история роста и эволюции Evolution Artifact Registry — как устроено централизованное хранилище артефактов, как оно дружит с Kubernetes и что анонсируют из новых функций в этом году. Полезно командам, у которых артефакты разбросаны по разным местам.

• Evolution Container Apps: платформа для платформ — как на базе одного сервиса поднять изолированные среды для разработки, тестирования и обучения. Разберут на примерах: от личного ноутбука до учебной платформы в стиле «Школы 21».

• Снижаем рутину в облаке: новые сценарии Гига-помощника — как ИИ-помощник теперь умеет разворачивать сразу несколько продуктов и настраивать мониторинг. Покажут живьем, без слайдов с обещаниями.

• Защита cloud native приложения: от GUI до ИИ — как атакуют контейнеры и где типичные дыры в Kubernetes. На практике покажут, как закрыть угрозы через Evolution Container Security за несколько кликов.

• От сервиса до экосистемы: как Маркетплейс Cloud.ru ускоряет путь продукта к клиенту — как устроен путь от первого релиза до выплат, сколько это стоит и сколько экономит. Будут реальные цифры и разбор типичных ошибок.

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

Регистрируйтесь и до встречи на GoCloud 2026! 

Вайб-кодинг в энтерпрайзе?

Как приземлить вайб-кодинг в энтерпрайз поговорим об этом на AlfaGen Meetup #3 со спикерами из Альфа-Банка, Яндекса, Сбера и red_mad_robot. Обсудим: 

🔴 Почему код от ИИ подходит не только для пет-проектов?

🔴 Почему вайб-кодинг может вызывать сопротивление?

🔴 Что поменять в процессах, чтобы вайб-кодинг стал их частью?

🔴 Какой минимум обучения нужен, чтобы вайб-кодить?

🔴 С какими инструментами новый подход принесёт пользу продукту?

Обсудим все вопросы 31 марта в 18:00 — подключайтесь к трансляции по ссылке.

Всё, что нужно знать для начала работы в PVS-Studio

Статический анализатор PVS-Studio — это инструмент для поиска ошибок в коде на протяжении всего жизненного цикла проекта.
В новой статье разберём основные особенности анализатора PVS-Studio, сценарии и варианты анализа, а также узнаем всё, что нужно знать для начала работы с инструментом.

Три доклада с Backend-митапа Garage Eight

> AI в travel tech — но не ради хайпа
Спикер: Глазунов Илья, backend lead в сервисе бронирования «ЖилиБыли»
YouTube | VK Видео

> Собрать LLM-стек для PHP за один вечер и не выстрелить себе в ногу
Спикер: Якимов Андрей, backend-разработчик Garage Eight
YouTube | VK Видео

> Модульная архитектура против хаоса: как ограничить контексты в большом монолите
Спикер: Русин Иван, старший разработчик группы модернизации платформы Flowwow
YouTube | VK Видео

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

Всем привет. Начал писать открытую книгу про архитектуру безопасных AI-агентов.

Делаю не обзор фреймворков и не коллекцию «магических демо», а практический инженерный reference: control plane, policy boundaries, tool gateway, memory, observability, evals, approval flows, governance и production-подход к агентным системам.

Уже выложил первые главы и каркас книги - https://agent-axiom.github.io/agent-arch

Репозиторий - https://github.com/agent-axiom/agent-arch

Буду очень рад критике по существу:

• где архитектура спорная,

• где не хватает важных разделов,

• где формулировки слишком сырые,

• что стоит добавить из практики эксплуатации и безопасности.

Если тема близка - вливайся: issues, comments, corrections, PRs, ссылки на сильные источники и контрпримеры из реальных production-систем.

Хочется сделать не просто набор заметок, а полезный community-driven reference для тех, кто строит надежных и безопасных AI-агентов.

Делаем мир чуть чуть лучше

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

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

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

Новый режим для ваших приложений ⚡️

Раньше можно было запускать только статику (SSG) и одностраничные приложения (SPA). К ним добавился и серверный рендеринг (SSR).

SSR — это когда страница собирается на сервере и сразу приходит пользователю готовой. Например, в интернет-магазине вы сразу увидите товары и цены без пустого экрана и долгой загрузки.

Что дает этот режим:

• +1 к гибкости разработки. В приложении можно использовать серверную логику, авторизацию и собственные API-обработчики.

• +1 к SEO. Страницы рендерятся на сервере → лучше индексируются и быстрее попадают в выдачу.

• +1 к простоте архитектуры. Не нужно создавать отдельный бэкенд, ведь часть логики можно держать в SSR.

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

Минимальный конфиг: от 510 ₽/мес с 1 CPU и 1 ГБ RAM

☝🏻 После деплоя режим изменить нельзя. Для других настроек создайте новое приложение.

Запустить SSR на своем проекте →

Как стать инженером данных?

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

Мы обо всем позаботились и собрали на Хабр Карьере курсы по ключевым инструментам, которые нужны, чтобы стать крутым специалистом.

Вот, например, минимальный набор инженера данных:

• Metabase. Инструмент для визуализации данных и построения дашбордов.

• Airflow. Платформа для автоматизации и оркестрации процессов.

• Redis. Быстрое кэш‑хранилище.

• Kafka. Система потоковой передачи данных.

• Hadoop. Фреймворк для распределённого хранения и обработки больших данных.

• Apache Spark. Инструмент для быстрой обработки больших объёмов данных.

→ Сменить профессию или вырасти на текущей должности

Запустили Yandex Cloud Stackland — инфраструктурную платформу для развёртывания приложений в закрытом контуре

С помощью Stackland можно как настроить среду для разработки собственных сервисов, так и быстро внедрять облачные решения. Это готовая инфраструктура со встроенными управляемыми базами данных, контейнерным оркестратором, объектным хранилищем, а также инструментами для управления доступом к графическим ускорителям, которые помогут решать задачи инференса при разработке ИИ‑решений. Выдавать доступы к разработке можно гранулярно, используя встроенные средства безопасности.

Платформу можно развернуть на любых виртуальных, арендованных или собственных серверах, а также интегрировать с уже существующими корпоративными системами. Также она позволяет без дополнительной интеграции внедрять готовые сервисы Yandex Cloud, доступные по модели on‑premises. Сейчас в Stackland доступны инструмент для речевой аналитики Yandex SpeechSense и BI‑система Yandex DataLens, в ближайшее время появится ещё несколько решений, в том числе Yandex AI Studio для разработки ИИ‑приложений и агентов.

Подробнее о разработке опенсорс‑решения для бэкапов CloudNativePG в Stackland и предыстории платформы мы уже рассказывали в отдельной статье.

Для получения доступа к Yandex Cloud Stackland оставьте заявку.

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

Так родился lazy-tmux, написанный на Go. Ключевые фичи:

• Сохраняет текущую сессию, конкретную сессию или все сессии целиком. Снимки сохраняют окна, панели, layout, команды (например, npm, docker-compose, редакторы) и опционально scrollback историю шела.

• Ленивое восстановление: поднимается только выбранная сессия. RAM не расходуется на всё сразу.

• Интерактивный TUI браузер с деревом сессий, окон и панелей, таблицей с активными командами, временем последнего снимка, количеством окон/панелей и статусом сессии. Поддержка fuzzy search для быстрого поиска.

• Навигация и полное управление сессиями и окнами с клавиатуры в TUI браузере сессий.

• Гибкая сортировка сессий и окон через флаги --session-sort и --window-sort

• Можно заменить встроенный TUI на fzf, использую облегчённый бинарник.

• Автосейв через фоновый демон, периодически снимающий все сессии на диск.

• Восстановление при старте tmux для автоматизации workflow.

Проект ещё молодой, но буду рад любой помощи и идеям по улучшению: GitHub issues

За моими новостями можно следить в Telegram-канале

29 демо-уроков для тех, кто не стоит на месте

Привет, Хабр. Эти уроки проводят преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Это бесплатно. Приходите!

• 25 марта 20:00
  РазвИИтие на основе ClickHouse: базы данных для искусственного интеллекта

• 25 марта 20:00
  Кракозябры vs Java: как победить кодировки и стать гуру Unicode?

• 25 марта 20:00
  Типы данных, переменные и функции в Rust

• 25 марта 20:00
  Инструменты профилирования и оптимизации в Go

• 25 марта 20:00
  Механизмы блокировок в PostgreSQL

• 26 марта 20:00
  Путешествие запроса в PostgreSQL: от разбора до исполнения (от parser до executor)

• 26 марта 20:00
  NestJS и архитектура масштабируемых серверных приложений на Node.js

• 26 марта 20:00
  Проектирование RAG систем

• 30 марта 19:00
  Расширение возможностей автоматизации через REST API

• 30 марта 20:00
  Чтение CSV — вход в Spark

• 30 марта 20:00
  Spring Boot Actuator: основы мониторинга и управления приложением

• 30 марта 20:00
  Индексы в PostgreSQL

• 30 марта 20:00
  Стили взаимодействия микросервисов: 5 секретов, которые изменят ваш подход к backend-разработке

• 30 марта 20:00
  Основные шаблоны проектирования в системном дизайне

• 31 марта 20:00 SQL:
  Оконные функции — когда GROUP BY уже не хватает

• 1 апреля 20:00
  Scala + Cats: аккумулируем ошибки с Validated без боли

• 1 апреля 20:00
  Создание интерфейсов с помощью OpenAPI

• 2 апреля 20:00
  Анатомия памяти: типы данных, способы хранения, аллокации и работа GC

• 6 апреля 20:00
  Ошибки системного аналитика при описании REST API

• 9 апреля 20:00
  PostgreSQL как векторная база данных: ИИ-поиск без лишних сервисов

• 9 апреля 20:00
  Realtime на Node.js и TypeScript: создаём WebSocket-чат и разбираем архитектуру backend

• 9 апреля 20:00
  Модели восстановления в SQL Server: как не потерять данные и настроить бэкапы правильно

• 13 апреля 20:00
  Как работают структуры данных C# «под капотом»

• 13 апреля 20:00
  Telegram-бот с искусственным интеллектом на Python

• 14 апреля 20:00
  Case classes и pattern matching: суперсила Scala на практике

• 14 апреля 20:00
  Влияние нефункциональных требований на архитектуру

• 15 апреля 18:00
  Основы протокола HTTP

• 15 апреля 20:00
  OpenAPI + Spring

• 15 апреля 20:00
  Основы проектирования бизнес-логики в микросервисной архитектуре

Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.

Выпустили бесплатный курс для PHP-разработчиков

Всем привет! Год назад рассказывал в этой статье на Хабре о том, как мы подготовили и записали курс на 30+ часов для наших PHP-разработчиков. В итоге у нас вышло 43 урока, разбитые на 5 направлений.

Сначала думали упаковать все это в коммерческий формат, но решили оставить все как есть и просто поделиться с сообществом. Надеюсь, что он принесет вам пользу.

Курс охватывает PHP от базовых механизмов до архитектуры и тестирования. В программе — устройство языка, работа с памятью и производительностью, принципы ООП и проектирования, а также взаимодействие с базами данных.

Отдельные блоки посвящены внутренностям PHP (zval, сборщик мусора, OPcache, асинхронность), архитектурным подходам (SOLID, DDD, паттерны, организация бизнес-логики) и работе с БД — от проектирования схем до оптимизации запросов и масштабирования.

В части тестирования рассматриваются TDD, структура тестов и подходы к оценке их качества.

Материал основан на практических кейсах и разбирает задачи, которые встречаются в реальных проектах.

Худший бэкап — не тот, что не восстановился. А тот, что положил прод.

Что, если post-script не отработал? Моргнула сеть или случился таймаут. Внешний оркестратор просто пишет в лог failed и снимает задачу. А вот PostgreSQL об этом не знает. База остается в режиме бэкапа и начинает непрерывно копить WAL-файлы, ожидая команды на завершение.

Получается, что инструмент для защиты бизнеса от даунтайма, своими руками этот даунтайм и устроил.

Уметь дернуть pg_backup_start( ) — мало. Если СРК не имеет встроенного watchdog-механизма для сброса зависших сессий, резервное копирование превращается в угрозу доступности. Разделение ответственности — правильный архитектурный подход, но он означает, что защита базы от переполнения диска полностью ложится на ваши плечи.

О зависшем backup mode, разрывах PITR и других неудобных вопросах эксплуатации PostgreSQL совместно с Акурой поговорим в режиме live-демо на вебинаре 26 марта в 11:00 (МСК).

Регистрация по ссылке. Приносите в комментарии свои вопросы.

Расширение AI-Less Habr — Чистим Хабр от ИИ

Надоела лента, забитая ИИ? У меня есть готовое решение для вас. Shut up and take my money:

• Chrome Web Store

• GitHub

Есть следующие возможности:

• скрывать хаб «Искусственный интеллект»

• скрывать по словам в заголовке (настраиваемый список)

• скрывать по тегам (настраиваемый список)

• инвертированный режим (показать, попадающее под фильтры, и скрыть остальное)

По умолчанию включено только скрытие хаба «Искусственный интеллект». Фильтры по словам/тегам с большей вероятностью допускают ложноположительные срабатывания, поэтому выключены по умолчанию. По этой же причине в фильтрах по словам по умолчанию нет слов «ии»/«ai», так как есть достаточно много статей, содержащих что‑то вроде «без ИИ». Внимательно относитесь к добавлению слов в фильтры, чтобы минимизировать ложноположительные срабатывания.

Всем привет! На связи Иван, руководитель НИИ Крокодил 😀

Это продолжение истории про медицинское приложение для клиники.

Часть 2. Как устроена медицинская система изнутри

Когда начинаешь работать с медицинской системой, быстро понимаешь: это не продукт, который можно «собрать и доработать потом». Любое изменение проходит через внутреннюю ИТ-команду клиники, потому что за каждым экраном стоят реальные процессы — расписания врачей, лаборатория, регистратура, страховые компании.

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

🧪 Отдельная история — тестирование. Мы проверяли не только интерфейс, а связку «мобильное приложение + сервер клиники». Запись и отмена приёма, конкуренция за слот, обработка ошибок, загрузка PDF-документов, корректная работа вложенных структур в истории посещений — всё это нужно было прогонять реальными сценариями.

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

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

Всем привет! На связи Иван, руководитель НИИ Крокодил 😀

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

Часть 1. Как устроена медицинская система изнутри

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

📦 Данные в приложении не хранились

Каждое действие пользователя превращалось в запрос на сервер: авторизация, запись к врачу, список анализов. Сервер возвращал актуальное состояние системы в ответе. Если данные менялись на сервере, пользователь сразу видел это в приложении.

🕓 Запись к врачу была не одной формой, а сценарием

Выбор врача или направления, дата, свободное время, подтверждение или финальный статус. Сервер решал, какие данные запрашивать на каждом этапе, а приложение лишь следовало сценарию. Пользователь не мог перескочить шаги или отправить некорректные данные — интерфейс был привязан к логике backend’а.

⭐️ В следующих частях разберу технические сложности, с которыми мы столкнулись при разработке таких систем.

Заметил обнову на Хабре.

Появился новый счетчик "охвата" который судя по моим наблюдениям измеряется в степенях двойки (2,4,8,16,32 и тд). Но я так и не мог найти официальных данных как он работает. Смотрел официальный changelog Хабра — никаких недавних обновлений не вижу.

Как Хабр считает метрику "Охват", которая стала первым делом выводиться возле пользователя?

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

UPD
Наглая реклама, но после того как соберу инфу, сделаю еще один репост на Хабре и в своем-тг

Руководитель группы серверной разработки «Криптонита» Артём Корсаков ведёт проект Scalabook. Это уникальная русскоязычная база знаний по Scala.

И недавно он добавил туда новые страницы — делимся с вами. Отправляйте знакомым «скалистам»!

• Новый статус завершенной задачи

• Автоматическая генерация SQL-запросов

• Жизненный цикл задач

• Завершение задачи

• Авторизация

• Клиентское API

• Endpoint-ы авторизации

• Endpoint-ы настроек

• Endpoint-ы задач

Сравнивал разные методы сделать call-once (а точнее инициализацию синглтона) - далее небольшие заметки.

Итак, нам нужно создать какой-то объект, пусть даже что-то нетривиальное (для определённости можно представлять что мы хотим прочитать данные из файла/эмбеддет ресурсов и разложить эти данные в хеш-мапу для будущих чтений). Рассмотрим следующие варианты:

1. статичный глобальный объект, вычисление вызывается в конструкторе

2. статичный глобальный объект + std::call_once

3. статичный локальный объект в функции, вычисление вызывается в конструкторе

Чтобы в годболте видеть что и где вызывается - определяем тип имеющий только объявления методов (это заставит компилятор ставить явный call)

struct TSomeExternal {
    TSomeExternal(int);
    ~TSomeExternal();

    int DoCalc();
    char Data[60]; // просто чтобы было проще увидеть
};

Особенности первого варианта:

• вычисление "до main"

• неконтролируемый порядок инициализации глобальных ответов => нельзя иметь зависимости между такими объектами

• вычисление только в рамках 1 потока

• уникальный плюс: нет проверок "на горячем цикле" - при обращении к объекту вызывающая функция может считать что данные уже готовы (но именно этот плюс стоит нам второго пункта)

В годболте можно посмотреть на func1 - видно что она скомпилилась просто в забор поинтера, и call

TSomeExternal GlobalValue(7);
int func1() {
    int x = GlobalValue.DoCalc();
    return x + 14;
}

Также видно что были порождены - указание что нужно разместить объект

GlobalValue:
        .zero   60

А также _GLOBAL__sub_I_example.cpp - там видно, что вызывается конструктор, и регистрируется указатель на деструктор в пост-колбеках (__cxa_atexit)

Второй вариант (более правдоподобно было бы внести call_once внутрь глобального объекта, но для простоты сравнения сделал как ниже)

static std::once_flag flag;
static std::unique_ptr<TSomeExternal> ptr;
void init() {ptr = std::make_unique<TSomeExternal>(7);}

int func2() {
    std::call_once(flag, init);
    int x = ptr->DoCalc();
    return x + 14;
}

• настоящая инициализация случается только в момент первого использования (ленивая инициализация). Это может быть как плюс (позволяет не тратиться на инициализацию если данные не будут использоваться), так и минус (первые запросы/итерации будут медленными)

• разные инициализаторы данных вполне могут работать одновременно из разных потоков

• имхо - дорогой основной цикл (очень много инструкций до TSomeExternal::DoCalc) - это всё подготовка вызова call pthread_once, который будет выполнен каждый раз

Третий вариант годболт

int func3() {
    static TSomeExternal prepared = {7};
    int x = prepared.DoCalc();
    return x + 14;
}

• в рантайме есть проверка - но это проверка и так нужного нам указателя на null

push    rbx
movzx   eax, byte ptr [rip + guard variable for func3()::prepared]
test    al, al
je      .LBB0_1

• если указатель не нулевой, то переход не будет выполнен и мы сразу переходим к

        lea     rdi, [rip + func3()::prepared]
        call    TSomeExternal::DoCalc()@PLT

• в случае если указатель не готов, то подготовка случается под блокировкой (__cxa_guard_acquire)

• конкретно в годболте не видно, но создаются слоты для guard variable for func3()::prepared и func3()::prepared (в этом смысле разницы со вторым вариантом мало)

Итого: ленивое вычисление, также возможна многопоточная инициализация, а также дешёвый success-path

Я бы назвал относительным неудобством третьего варианта, что указатель оказывается скрыт внутри функции, и надо сделать ещё доп действие чтобы использовать объект из нескольких функций. Пример такой обёртки Singleton.

Друзья, Digital Q.DataBase позволяет Вам не только сохранить прикладную логику СУБД Microsoft и Oracle.

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

Что это означает на практике:

🔹 ABAP-приложения продолжают работать на новой платформе
🔹 Данные и обработка переносятся в Digital Q.DataBase
🔹 Вся бизнес-логика сохраняется без изменений
🔹 Формируется импортонезависимый стек из отечественного ПО

🔹 В этом видео: 

ABAP-код → сохранение → активация → преобразование в C++ → компиляция → установка на сервер → запуск

📎 Полезные ссылки
🔹 Отдельный лендинг по замене SAP: renovation.diasoft.ru
🔹 Бесплатное получение СУБД дистрибутива: database.diasoft.ru
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: t.me/dqdatabase