Java *

За две недели мне прислали несколько десятков расшифровок реальных собеседований — и в девяти подряд попалась одна и та же задача: 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.

Что может быть общего у разработчика из крупной московской ИТ-компании и пенсионерки из Вологодской области? Ну, например, они оба регулярно пользуются SSO — технологией единого входа. Разработчик входит под одной учеткой во все корпоративные рабочие системы, а пенсионерка авторизуется через «Госуслуги» — чтобы записаться к врачу, проверить пенсию или оплатить коммунальные услуги. Об этом и поговорим, в смысле, об SSO, а не о «Госуслугах».

Привет, Хабр! Я Денис Радостев, старший  backend-разработчик в IBS. В этой статье расскажу о Blitz Identity Provider, российской платформе управления цифровой идентичностью, которая обеспечивает единый вход — SSO, многофакторную аутентификацию и централизованное управление пользователями, и как ее можно интегрировать с приложениями Java по протоколу OAuth 2.0. Покажу ключевые настройки Blitz IDP и моменты, которые важно учитывать на стороне Java-приложения.

А вместо заключения расскажу про наш собственный кейс, связанный с синхронизацией пользователей между Blitz IDP и нашей старой БД для самописной авторизации.

Полгода назад мой друг провалил собес в Иннотехе на одной фразе: «Напиши State Machine без локальной переменной». Это был его четвёртый отказ за месяц. Тем вечером я завёл табличку — и за полгода собрал базу из 247 разобранных Java-интервью по 27 компаниям: от Сбера и ВТБ до ERP-вендора, о котором почти никто не слышал.

В статье — три вещи: 12 вопросов, которые повторяются в 80% собесов; почему совет «возьми топ-50 с Хабра» в 2026 уже не работает; и почему вопрос №7 стабильно валит 9 кандидатов из 10 — включая тех, кто читал Bloch и Goetz.

Одной из первых задач, когда я начинал разработку idea, была интеграция xdebug в свой инструмент разработки и реализация основных возможностей работы дебагера. Первым делом надо было изучить документация по протоколу xdebug. В нем используется общий протокол дебагера DBGP. В целом ничего сложного, есть сокет через который мы отправляем команды в сам xdebug он нам отвечает в формате xml, парсим xml и получаем результат. Все просто подумал Я, но как всегда не без приключений.

Первая проблема возникла от недопонимания в какой момент создается сокет, тот самый порт 9000. Читаем документацию пункт 5.3 и 5.4 первый говорит про стандартный порт второй пункт говорит о инициализации подключения и что xdebug отвечает при готовности объектом <init>

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

Чтобы отличать повтор от новой операции, используют idempotency key (ключ идемпотентности). Это обычная уникальная строка-идентификатор, которую клиент или апстрим отправляет вместе с запросом (часто в заголовке Idempotency-Key). Сервис сохраняет этот ключ у себя и связывает с результатом операции.

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

В новом переводе от команды Spring АйО рассмотрим не самые очевидные ошибки и то, о чём стоит подумать, при реализации идемпотентного API.

Если вы следите за текущими тенденциями в мире найма/вакансий, то определенно заметили, что куда-то подевались вакансии Middle и Junior-разработчиков, и у этого есть несколько причин.

Первая: рынок просел, и общее количество вакансий в IT-индустрии сократилось. В результате Middle-позиции теперь можно закрывать Senior-разработчиками. Это уже случалось в нашей истории, но за любым спадом следует подъем.

Вторая — AI-агенты. Senior-разработчики получили "рычаг". Теперь задачи, которые ранее поручали Junior и Middle-разработчикам, можно поручить AI Agent. При этом для Senior мало что меняется, поскольку подробное review делать нужно в обоих случаях.

Можно сказать, рынок оказался в "клинче". Сейчас нет времени думать, что будет дальше, поскольку нужно решать текущие вопросы, а когда начнется подъем, нужного количества разработчиков может и не оказаться, поскольку они ушли в "плотники".

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

UI‑тесты редко ломаются красиво: один редизайн формы — и локаторы приходится чинить по всему проекту.

В статье разберём, как собрать первый автотестовый проект на Java и Selenium с Page Object Pattern: куда класть страницы и компоненты, как писать базовый класс, почему лучше держаться за data-test и какие ошибки быстро превращают аккуратную архитектуру в набор хрупких обёрток.

На самом деле, JavaFX есть механизм кастомизации уже существующих компонентов (StackPane, Pane, HBox, VBox, ScrollPane и т.д.) с помощью css. css javafx поддерживает псевдоклассы (after, before, hover, focused, presed и так далее). В целом все гибко и можем довольно легко взять любой компонент и превратить его в свое родное.

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