Java *

Главная ценность релиза — разработчик начинает с рабочей задачи, а не с выбора режима.

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

Для этого в Veai 5.12 появился General Agent. Он принимает задачу в том виде, в каком разработчик обычно ее формулирует: неидеально, с сомнениями и неполным пониманием пути. Агент сам подбирает нужные действия и отдает результат, который уже можно проверить.

Попробовать Veai 5.12 · Что входит в релиз

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

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Продолжаю цикл статей о клиенте для облачного сервиса Ollama. В первой части я рассказал, как родился этот клиент, с какими трудностями пришлось столкнуться при организации стриминга, и даже оставил пасхалку.

Большинство статей о миграции с SharePoint описывают её как проект с двумя чёткими состояниями: «до» и «после». Вот вы работаете в SharePoint — вот уже в новой системе. На практике это не так. Между «до» и «после» существует третье состояние, которое может длиться месяцами: обе системы работают в проде одновременно, пользователи работают в обеих, а данные могут меняться в любой из них.

Именно это третье состояние и создаёт самый неприятный класс проблем. И именно о нём — эта статья.

В статье я делюсь практиками работы с Claude Code и Codex, которые помогли мне реализовать сложную техническую задачу в условиях ограниченного времени, бюджета и железа.

Первичное наполнение контекста — крайне важная задача, результаты которой влияют на качество решения/сгенерированного кода, возможно, даже больше, чем выбранная модель. В Claude Code за это отвечает Explore sub-agent, который, к слову, справляется неплохо, ровно до тех пор, пока вы не начинаете "по настоящему" использовать Spring: добавляя собственные starters, используя OpenAPI (Spec-first), определяя Bean/Components в стиле Josh Long (описывая их в конфигурациях), а также внедряя множество других инструментов фреймворка. В этом случае качественный анализ можно провести, только зная особенности работы Spring Framework и экосистемы.

В этом выпуске еженедельного дайджеста Skill of the week разберёмся, как, используя Spring Explore Skill, научить агента понимать специфику Spring-приложения и выполнять качественный первичный анализ.

К маю 2026 года средний сбор аудитории в нашей системе занимал 2 часа 50 минут. Проблема состояла из двух частей. Первая: 96.5% этого времени процесс стоял в очереди. Вторая: даже добравшись до исполнения, расчёт занимал 6 минут — десятки задач внутри DAG выполнялись над множествами в миллионы строк, и основным инструментом были JOIN.

Мы последовательно устранили обе проблемы — 20 изменений, разбитых на шесть этапов. Ниже описан каждый шаг и итоговый результат.

Все числа «до» и «после» получены одним и тем же SQL‑запросом по Postgres — это воспроизводимый замер.

Домен обобщён: конкретная компания не имеет значения. Это платформа, которая по булевым условиям («траты > 5000 ₽ за последние 3 месяца» И «покупки в категории Рестораны») собирает множество клиентских идентификаторов из 10-миллионной базы и доставляет его во внешние системы.

Я наткнулся на подход к функциональным тестам, который меня по-настоящему удивил. Тесты в нём вообще не знают, что внутри Spring: стучатся в реально поднятый сервис по HTTP, как обычный клиент, гоняются параллельно и проходят за секунды. Я разбирал это на код-ревью и сначала прифигел, а потом не стал переходить на него сам, но кое-что забрал себе. В статье сравниваю оба подхода, разбираюсь где какой уместен, и показываю три вещи, которые подсмотрел и притащил в свой Spring

За две недели мне прислали несколько десятков расшифровок реальных собеседований — и в девяти подряд попалась одна и та же задача: ASTON, ТБанк, Альфа, Совкомбанк, Иннотех. Везде одно: «найдите минимум восемь багов в этом куске Spring-кода, у вас двадцать минут». Разные домены, но скелет один — контроллер на полсотни строк с ловушками от Junior до Senior.

Я собрал эти восемь типовых багов в один контроллер обработки платежей и публикую как тест. Засеките 15 минут и попробуйте сами, до разбора: 4 бага — Junior, 7 — Middle, 8 и выше — Senior с опытом code review. Девятый я зашил отдельно — его обычно не находят вообще, и он не про код, а про архитектуру.

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

В Axelix мы в последнее время начали получать contribution-ы извне. И как по приватным обсуждениям, так и по GitHub я могу сделать вывод, что у очень многих людей есть довольно серьёзное непонимание того, что означает та или иная лицензия, что вообще такое “Open Source” и даже что такое Copyright.

Мне кажется, что я пару вещей в этой теме немного понимаю, и я чувствую некоторую ответственность этим знанием поделиться. Поэтому я решил написать небольшую статью, которая объясняет базовые концепции в Software, начиная с Copyright и Licensing.

Позже я, возможно, ещё напишу про CLA, Open Core и про то, как AI Agents и AI в целом вписываются в эту картину. Так что, если вам интересно, дайте знать :)

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

Давайте я попробую объяснить, как вообще вся юридическая часть вокруг софта устроена, шаг за шагом.

Как на собеседовании отличить системного аналитика, который учил REST по учебнику, от того, кто реально проектировал API?

В статье — три живых кейса из практики в FinTech и e‑commerce. Вы сможете проверить себя, увидите разбор популярных ошибок и узнаете, почему даже опытные инженеры спорят про PATCH и 409.

Если ориентироваться только на публичные обсуждения, может сложиться впечатление, что большинство проектов уже давно перешло на Spring Boot 3.x. В крайнем случае команда прямо сейчас выполняет миграцию, закрывает несовместимости и движется к актуальному стеку.

Но когда разговариваешь с инженерами не в формате доклада и не в режиме «расскажите, как у вас всё идеально устроено», картина оказывается менее однозначной.

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

Просто публично такие детали обычно не выносят. Или говорят о них очень осторожно.

Отсюда появляется важный вопрос: если это распространённая практика, почему её так неудобно обсуждать? Почему факт использования старой версии фреймворка воспринимается почти как признание в инженерной неаккуратности?

Попробуем разобрать это без морализаторства.

Привет! Меня зовут Дмитрий Михеев, я ведущий разработчик в MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.

В своих сервисах для межсервисных коммуникаций помимо gRPC-запросов мы используем брокер сообщений Kafka. Если описывать его в двух словах, Kafka — это распределённый журнал событий (event log), через который сервисы обмениваются данными в реальном времени.

Не буду подробно останавливаться на устройстве Kafka — это хорошо описано в документации. В этой статье хочу подсветить один неочевидный момент, который может привести к проблемам при работе с consumer’ами — повторную обработку сообщений (retry).

pip install, requirements.txt, virtualenv, black, isort, flake8, mypy, setup.py... Если вы настраиваете Python-проект так же, как в 2020 году, эта статья для вас. Показываю современный стек, который заменяет всё вышеперечисленное.

В 2026 году экосистема Python-инструментов наконец собралась в нечто цельное. Два инструмента (uv и ruff) + один файл (pyproject.toml) заменяют 7+ отдельных утилит. Вот как это работает.

JPA не предоставляет first-class модель для частичных вложенных графов как концепта. Для этого нужны JDBC (ручная сборка), jOOQ (MULTISET) или Blaze Persistence (Entity Views).

Большинство обсуждений вокруг persistence начинается не с той проблемы. Мы сравниваем фреймворки, SQL-инструменты, ORM… Но реальная проблема проще и фундаментальнее:

Реляционный JOIN результат имеет плоскую форму по умолчанию.

Приложениям нужны вложенные объектные графы или специализированные формы данных.

Читатели хабра, категорически вас приветствую! Я прошел путь от стажера до разработчика Java с опытом в 5+ лет. За это время было принято не мало хороших решений, но плохие тоже не отставали, о последних и возможном способе их решения я хочу рассказать, и возможно кому то это поможет не наступить на те же грабли что и я, или же менее болезненно “отодрать” их от своих ног, если вы уже попали на них.

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

Контракт use case должен описывать потребность приложения, а не API выбранного persistence фреймворка.

Spring Data пагинация хорошо работает в CRUD приложениях. Для многих проектов Pageable в application service — это разумный компромисс. Проблема возникает, когда Pageable становится частью публичного контракта use case.

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

Всем привет! 👋👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

В этом выпуске разбираем, почему G1 в JDK 27 окончательно прописывается дефолтным сборщиком мусора, и смотрим, что там с очередным, двенадцатым по счету инкубатором Vector API (спойлер: все по-прежнему ждем Valhalla). Заглянем в Netflix, посмотрим, как раскатили AOT из Project Leyden в прод и срезали время старта сервисов на 15—20%. Поговорим про то, как снимать heap-дампы с прода и не получить по шапке от безопасников, а заодно разберемся, зачем вообще были нужны гибкие конструкторы из Java 25. Посмотрим обзор фич Java 26 от Николая Парлога. Из любопытного — статья, где автор 18 месяцев гонял на проде два одинаковых сервиса на Spring Boot и Node.js и в итоге насчитал разницу в 24 тысячи долларов. Ну и пробежимся по свежим релизам: Micronaut 5.0, Quarkus 3.35 и 3.36, Spring AI и не только. Поехали!

Когда вокруг десяток микросервисов, документация устарела, а на согласование архитектурного решения есть два дня, обсуждение быстро погружается в детали и теряет общую картину.

На примере внедрения кэширования в API‑шлюз разберём, как системному аналитику применять C4-модель: пройти от границ системы до зон ответственности внутри сервиса, зафиксировать сценарии сбоев и сохранить архитектуру в виде кода.

У AI-агентов есть неприятное свойство: они часто выглядят умнее, чем их обратная связь.

Модель может хорошо писать текст, аккуратно рассуждать о коде и уверенно предлагать правки. Но если все, что она видит, это grep, несколько похожих файлов, команда в терминале и длинный лог, то ее выводы строятся на шумном сигнале. Иногда этого хватает. На небольшом проекте, с сильной моделью и простой задачей, агент действительно может быстро помочь. Но! В enterprise-коде ситуация другая. Важны конкретная версия зависимости, выбранная run configuration, classpath, SDK, профиль, состояние объекта в рантайме, IDE warnings, usages, inspections, trace уязвимости, важны факты, без которых агент начинает угадывать.

Разберем на последних релизах Veai 5.8-5.11 рабочий цикл разработчика в любимой IDE.