Бэкенд

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

Финал цикла про облачную LLM на 16 ГБ VRAM.

За две предыдущие статьи мы подняли собственную локальную модель на облачном сервере с GPU на 16 ГБ VRAM, разобрались с vLLM и tool calling, собрали агентный бэкенд на LangGraph с MCP-серверами, получили вокруг него полноценный REST API из коробки и обернули все это в FastAPI-сервис через LangGraph SDK.

В этой части закрываем полный стек: к готовому агентному бэкенду на LangGraph подключаем официальный ChatGPT-подобный фронтенд от LangChain — agent-chat-ui. Переводим на русский, добавляем переключатель между тремя агентами разной архитектуры и удаление чатов. Закрываем API Bearer-авторизацией с разбором нюансов, которых нет в документации. Деплоим всё на VPS с доменом и SSL — LangGraph внутри контура, наружу смотрит только фронт.

Если вы когда-либо преподавали SQL или проходили курс по базам данных, то почти наверняка встречали Sakila — маленькую базу данных видеопроката, которая вот уже почти двадцать лет служит эталонным примером в туториалах по MySQL и MariaDB. Схема чистая, нормализованная, данных достаточно для интересных запросов.

Проблема в другом: Sakila спроектирована в 2006 году под MySQL 5.0.

С тех пор многое изменилось.

На PreparedStatement обычно заканчивается вводный курс по JDBC / PostgreSQL. Все довольно просто, пока не задумываешься: а работает ли оно как надо в моем крутом инновационном приложении?

Дальше интереснее: как PostgreSQL выбирает custom или generic plan? кто именно кэширует statements? как с этим дружат ORM и внешние пулы?

По закону подлости все выясняется на собеседовании, в контексте “начальных банальных вопросов по БД”. Разберемся в подробностях и закроем эту тему

Если вы запускаете Manticore Search на Linux, в качестве основного инструмента управления стоит выбрать systemd.

На текущий момент это общепринятая практика, хотя ранее существовали определённые ограничения. Да, Manticore Search мог работать под systemd, но интеграция обладала рядом функциональных ограничений. Архитектура демона основана на традиционных подходах Unix; systemd появился позже и хотел от службы совсем другого. Так что настройка работала, но не соответствовала современным требованиям к управлению службами.

Теперь Manticore Search поддерживает нативные уведомления systemd — это и есть главное изменение.

Почему это важно? Потому что устраняется ряд операционных проблем:

TL;DR: я сделал sqlalchemy-query-manager — небольшой слой поверх SQLAlchemy для типовых backend-запросов. Он не заменяет SQLAlchemy, а добавляет более компактную запись для частых операций: фильтры в стиле number__gte=100, условия через Q, фильтрацию по связанным моделям, eager loading, CRUD helpers, агрегаты и просмотр итогового SQL. Идея в том, чтобы оставить SQLAlchemy в основе, но убрать повторяющийся код там, где запросы становятся слишком большими.

Если вы продаёте на двух и более маркетплейсах, вы почти наверняка с этим сталкивались: товар продан на Ozon, но на Wildberries он ещё висит в наличии. Приходит заказ на то, чего на складе уже нет. Дальше по сценарию: отмена, штраф, падение рейтинга карточки, в худшем случае - блокировка.

В этой статье я разберу проблему по слоям: откуда физически берётся расхождение, какие есть уровни решений (от коробки до event-driven на Go), и почему модный ответ «поставьте Kafka» для одного селлера почти всегда оверкилл. Будет код и будут цифры.

Spring Batch - проект в рамках экосистемы Spring Framework, который, как правило не получает должного внимания. Тем не менее, это хорошее решение для Enterprise Batch Processing.

Долгое время Spring Batch требовал SQL-базу для хранения общего состояния, шагов перехода, статусов выполнения и время запусков. Даже если проект жил на MongoDB, рядом часто приходилось держать Postgres или MySQL только ради метаданных.

В Spring Boot 4.1 стало проще: появился spring-boot-starter-batch-data-mongodb. Теперь Spring Batch научился работать с MongoDB.

В статье Josh Long рассказывает про новинки в рамках Spring Batch, в том числе и новую интеграцию с MongoDB, а также работу с GraalVM

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

В современной разработке компоненты с открытым исходным кодом (Open Source Software, OSS) стали абсолютным стандартом. От небольших библиотек до целых фреймворков вроде Spring или Hibernate — FOSS (Free and Open Source Software) значительно ускоряет разработку и снижает издержки.

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

Цель этой статьи — предоставить максимально подробное и практическое руководство для разработчиков и технических директоров. Мы разберем, как безопасно использовать FOSS‑лицензии в реалиях российского законодательства и международной практике, и как защитить свой проект от фатальных ошибок.

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

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

Какое отношение этот пример имеет к работе с потоками в программировании? Дело в том, что решить задачу синхронизации конкурентных операций можно также несколькими способами, близкими к ситуации выше. Меня зовут Александр, я разработчик на С++ в YADRO, и в этой статье я разберу несколько вариантов эффективной организации ожидания потоков. 

Разбираем мажорное обновление Greengage с версии 6 на 7: как работает pg_upgrade, какие шаги нужны для обновления кластера, чем помогает ggupgrade и какой выигрыш по времени дают копирование файлов и режим жестких ссылок.

Я Игорь Юрченко, backend-разработчик Сбера, в этой статье расскажу о нашем опыте автоматизации деплоя потоков Apache NiFi.

Apache NiFi — инструмент для управления потоками данных между автоматизированными системами (реализует подход ETL — extract, transform, load). Документация: https://nifi.apache.org/documentation/v1 (на момент написания статьи актуальна версия 2.x, но тут речь про 1.x). Физически это Java-приложение с графическим web-интерфейсом, в котором настраивается поток — в общем случае набор процессоров, которые получают на вход какие-то данные от предыдущего процессора или из внешней системы, обрабатывают их определённым образом и передают следующему процессору или во внешнюю систему. Процессор — готовый модуль с параметрами интеграции и/или обработки данных (например, строка подключения к БД, или схема трансформации данных). То есть ETL настраивается графически, без написания кода. NiFi обладает возможностями горизонтального масштабирования (ноды кластера имеют одинаковую копию настроек потока, обрабатывают данные параллельно), и расширения (пользователь может писать custom процессоры и использовать их в потоках наравне со штатными). Из коробки поддерживается множество внешних систем и протоколов передачи данных.

Apache NiFi Registry — инструмент версионирования потоков, Java-приложение с web-интерфейсом, интегрировано с NiFi. Что-то вроде системы контроля версий исходного кода, но проще. Пользователь может сохранять в Registry, просматривать и восстанавливать старые версии потока. Документация: https://nifi.apache.org/docs/nifi-registry-docs.

Привет, Хабр! Пишет эту статью Александра Лысенко — вчера я была студенткой, а сегодня как инженер-программист Nexign спешу поделиться приобретенным опытом.

Мой первый проект для реального бизнеса был связан с миграцией с Oracle на PostgreSQL. Сегодня расскажу, как внедрение диапазонного типа данных при переходе между СУБД позволило не просто сохранить производительность, но и превзойти исходные показатели. Если вы тоже только начинаете свой карьерный путь — надеюсь, этот материал вам поможет.

В облачных сетях принято разделять два уровня: физический Underlay и виртуальный Overlay. Если Underlay — это фундамент здания (кабели, коммутаторы, базовая IP-связность), то Overlay — инженерные коммуникации: невидимые глазу, но без которых жизнь в доме остановится. От того, насколько эффективно и надёжно спроектирован Overlay, напрямую зависят скорость пользовательских приложений и стабильность всей платформы.

Привет! Меня зовут Валерий Симаков, я разработчик команды Network DPL в MWS Cloud Platform. Сегодня мы подробно поговорим о сетевой составляющей нашего облака, а именно об устройстве Data Plane (DPL) в Overlay-слое — том самом слое, который и отвечает за передачу пользовательского трафика. Мы разберём, как из разрозненных компонентов рождается единый, слаженный механизм передачи данных. Благодарю коллег из команды Network DPL за помощь в подготовке статьи.

В 1994 году у меня появился первый компьютер: Intel i486 DX2-66 с 4 МБ ОЗУ и жёстким диском на 512 МБ. На нём были установлены IBM OS/2 и Microsoft Windows 3.11. Следующие четыре года я апгрейдил эту машину каждые несколько месяцев, добавляя больше ОЗУ (до 16 МБ), привод CD-ROM и карту SoundBlaster. Так я научился апгрейдить эту машину, устанавливать новое ПО, а потом и писать ПО на BASIC. Но я ни разу не касался процесса запуска и тонкостей MS-DOS.

В 2026 году, 32 года спустя, я узнал из скриншотов DDX3216, что в Behringer использовался настоящий процессор 386. В моём мозгу сразу же активировались какие-то нейроны и я начал размышлять о том, можно ли запускать на этом устройстве ПО или даже полнофункциональную операционную систему. Для этого мне нужно было разобраться, как запускается система x86, когда управление перехватывает DOS и что необходимо для попадания в оболочку.

Допустим, вы разработчик. Вам в Jira прилетает задача — сделать на странице пользователя кнопку «Дать денег». Вы делаете кнопку, она появляется на странице, нажимается, запрос уходит на бэк, бэк отвечает 200 OK. Технически все выполнено верно, но заказчик недоволен и вопрошает: «Я уже пять раз нажал на кнопку, почему деньги так и не пришли?».

И где-то между «в ТЗ было написано просто добавить кнопку» и «давайте срочно переделаем фичу до релиза, перепишем кнопку на тумблер и подрубим биллинг» возникает вопрос: кто виноват и почему именно аналитик?

Привет, Хабр. Я Арина, системный аналитик в Selectel. Я пишу требования к внутренним сервисам, ботам, интеграциям и прочим штукам, которые сначала кажутся маленькими, а потом обрастают ролями, статусами, ретраями, правами доступами и фразой «а это точно MVP?». 

В этой статье я спровоцирую холивар подниму давнюю проблему недопонимания между разработчиками и аналитиками в части ТЗ. Статья, в первую очередь, для разработчиков, чтобы можно было как можно раньше находить потенциальные проблемы, не ссориться с аналитиком и не реализовывать идеально то, что потом все равно придется переделывать. Хотя и аналитики, составляющие ТЗ для разработчиков, я уверена, смогут найти для себя что-то полезное в статье.

Аналитика, сканирование интернета стали сегодня сильно проще — даже китайских коллег можно читать совершенно прозрачным образом. Изучение исходников смежных OSS-проектов — это вообще песня: за пять минут, на малознакомом языке программирования и без предварительного знания структуры проекта можно получить ответы на важные вопросы, потырить полезные приёмы и изучить как удачные, так и неудачные архитектурные решения.

Тогда почему мы всё ещё тратим время, ходим на youtube и новостные сайты в поисках интересного контента? Зачем полагаемся на чей-то алгоритм - ведь тот же Claude хранит в том или ином виде историю переписки и таким образом может оценить наши реальные интересы. Может быть стоит взять в свои руки формирование 'информационного пузыря'?

2 июня мой мониторинг аптайма разом отрапортовал, что упало почти всё: 932 инцидента за 25 минут. Сайты были живы — все до единого. Виноваты дефолтный лимит файловых дескрипторов 1024 и «оптимизация», тихо размножившаяся в 60 раз. Разбираю по приборам: /proc, ss, EMFILE и почему docker compose restart не спасает.