Java *

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

В статье вы найдёте:

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

Материал будет полезен архитекторам, ведущим разработчикам и всем, кто проектирует распределённые системы. Покажу, как не повторять ошибок, которые стоили компаниям миллионов.

Даже для опытных пользователей системы (продукт-оунеры, техлиды, CTO, руководители уровня B-1, сотрудники кост-менеджмента) это не всегда просто, тем более для новых. Значительная часть времени уходит не на работу в системе, а на поиск информации в разрозненных источниках: Excel-таблицы, письма, локальные заметки или уточнение деталей у коллег. Отсюда и появилась идея AI-ассистента как удобного способа получать ответы в одном месте, обычным человеческим языком.

Python почти стандарт для AI-проектов, но мы, как и большинство продуктовых команд в банке, используем JVM-стек: Kotlin, Java, Spring Boot. Поэтому осознанно выбрали развивать AI-ассистента в уже знакомом стеке. Это не просто техническое предпочтение. Мы хотели сохранить поддержку и масштабируемость внутри команды и  не привлекать новые компетенции, которых у нас пока нет.

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

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

В последнее время слово «инженер» мало употребляется в IT-индустрии. Есть программист, разработчик ПО, техлид, архитектор. Но одно только знание технологий не дает гарантии, что человек хорошо выполнит бизнес-задачу. Инженерное мышление — это особый дар, который позволяет решить сложную, возможно, даже ранее не решенную проблему с использованием существующих технологий.     

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

Наверно, все владельцы роутеров MikroTik знают, что они декодируют все SMS по стандарту 7-bit вне зависимости от того, как изначально было закодировано сообщение. Как оказалось, даже при декодировании 7-bit MikroTik использует не все 128 символов из стандартного алфавита (GSM 7-bit Default Alphabet).

А ещё вместо одного длинного SMS роутер покажет вам его части по отдельности, иногда с неполными дубликатами. Как же тогда нормально прочитать любое сообщение, отправленное на роутер? Надо стать протоссом и построить MotherSMS.

Привет всем!

Ко мне часто обращаются молодые инженеры с вопросом: «А зачем вообще идти в аспирантуру?» Я обычно рассказываю, какие плюсы и минусы есть у такого шага — как учёба прокачивает навыки, помогает упорядочить знания и освоить грамотную постановку экспериментов. Но выбор каждому нужно делать самому, стоит ли прокачивать такие навыки или нет.

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

Решили с товарищем поучаствовать. Правда, мы были вдвоём, а в команде могло быть до 9 человек. Спойлер: мы не взяли первое место и даже не попали в шорт‑лист из 9 команд — заняли 16‑е место из 35.

Да, это не история про успех, а про опыт — тот самый, который, как известно, «сын ошибок трудных». Главный урок прост: да, быть экспертом и действовать в одиночку — это неплохо. Но настоящая суперсила — в команде!

А теперь — обо всём по порядку…

Продолжаем серию статей для тех, кто начинает изучать Kotlin с нуля. Во втором уроке детально разбираем фундамент языка:
▪️Неизменяемые (val) и изменяемые (var) переменные
▪️Базовые типы: Int, Double, String, Boolean, Char
▪️Строковые шаблоны и многострочные строки
▪️Арифметические операции, целочисленное и вещественное деление
▪️Преобразование типов (явное и неявное)
▪️Ввод данных с консоли через readln()
▪️Символы и Unicode (коды символов)
▪️Особенности остатка от деления с отрицательными числами
▪️Инкремент и декремент (префиксная и постфиксная формы)

Все примеры кода — из реальной практики, доступны в открытом репозитории на GitHub (ссылка в статье). Материал подготовлен на основе опыта преподавания в OTUS и работы в FinTech. Статья поможет вам быстро войти в тему и избежать типичных ошибок новичков. Идеально для первого знакомства с языком или для систематизации знаний.

Иногда одна незаметная фича может сжигать гигантский объём ресурсов. В Netflix именно так и вышло: скоринг серендипности в Ranker оказался дорогой горячей точкой, а попытка слегка его ускорить в итоге привела к большой инженерной перестройке — от батчинга до SIMD через JDK Vector API.

В новом переводе от команды Spring АйО разберем, как SIMD AVX инструкции на практике позволили снизить потребление CPU.

В этой статье мы рассмотрим, как при помощи искусственного интеллекта отрефакторить множественные файлы на Java. Действуем по такому сценарию:

Есть компания, которая при работе с микросервисами на Java использует собственную библиотеку, управляющую флагами для переключения фич. Теперь решено мигрировать на  Unleash, где работа с флагами переключения фич организована удобнее, а также предусмотрено поэтапное включение фич.

Kafka часто воспринимается как система, гарантирующая доставку сообщений и Exactly Once Semantics. Однако в реальных распределённых системах эти гарантии заканчиваются на границе брокера.

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

В этой статье разберём:

Или: как спорили о реактивщине, а потом Java 21 всё запутала ещё сильнее

Реактивное программирование обещало нам масштабируемость и производительность. Оно их дало. Но вместе с этим подарило новый вид боли: stacktrace на 47 фреймов, половина из которых operator.onNext, а элементарные вещи написаны так, словно решаешь задачу на leetcode. Потом подвезли Virtual Threads, и половина интернета написала «реактивщина умерла», другая – «ничего не изменилось». Истина где-то посередине.

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

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

Подробнее в новом переводе от команды Spring АйО.

Привет, Хаброжители! Опытные хакеры постоянно охотятся за уязвимыми приложениями, поэтому никогда не переставайте беспокоиться о безопасности. Задача становится особенно сложной, если приходится работать с унаследованным кодом, новыми технологиями и сторонними фреймворками. Научитесь защищать Java-приложения с помощью Spring Security — проверенного и гибко настраиваемого фреймворка для аутентификации и управления доступом.

Для обычного пользователя разрешать уходить в минус по балансу - не может позволить себе ни одна организация, как говорилось в одном известном фильме - утром деньги, вечером стулья. Но для больших корпораций остановка платежей даже на секунду - это уже не проблема корпорации, а всего государства. Невозможно приостановить работу концерна (например Росатом) только потому, что в данный момент у него нет средств. На перезапуск может уйти куда как больше ресурсов.

Поэтому пора исправлять эту проблему в MireaPay и наконец-то добавить работу с крупными юр. лицами, которые будут называться корпоративными пользователями!

Как перевести продакшен-проект на рельсы agent-driven development - когда LLM-агенты становятся полноценными участниками разработки, а не просто подсказчиками в автокомплите ? Реальный опыт на реальном проекте !

Продолжаем улучшать Feedback Loop. В предыдущей статье я ускорил прогон тестов в 6 раз. Теперь — следующий шаг: LLM-агент генерирует тесты. Два подхода (sprint-driven и coverage-driven), шестиуровневый pipeline верификации, двух-агентная архитектура, оптимизация feedback loop — и 68 тестовых файлов на выходе с acceptance rate 86.8% при ревью живыми разработчиками.

В статье — конкретика: как анализировал покрытие и свежесть документации, как ускорял компиляцию для агента, на чём экономил токены, и что сказала команда на code review.

JDK 26 выходит уже совсем скоро. Тем временем в GC закрыли около 380 задач (почти в 2 раза больше, чем в прошлом релизе), но в этот раз акцент сместился с  больших фич в пользу практичных доработок.

Главное для всех сборщиков: нормальный учет CPU GC. Теперь считают не только stop-the-world паузы, но и конкурентную работу и дедупликацию строк. Можно посмотреть через лог cpu=info при завершении VM, обновили Hsperf-счетчики, есть доступ из кода. Плюс новый JFR-ивент с деталями по string dedup.

JEP 516: Aot Cache стал независим от выбранного GC и опций VM. Включение через опцию -XX:+AOTStreamableObjects.

G1 получил самые заметные улучшения: JEP 522 уменьшает синхронизацию между GC и приложением (цель - увеличить throughput). Еще: целевое использование CPU G1 по умолчанию снижено с 8% до 4%, добавили важнейший флаг UseGCOverheadLimit.

Это текстовая версия доклада с Java Rock Star Meetup, с которым выступал Дмитрий Фатов (@FatOFF ) — руководитель разработки Газпромбанка с опытом разработки приложений более 13 лет. Дмитрий работал как backend-, так и fullstack-разработчиком на языках Java, Kotlin, JS, TS, 1С и имеет большой опыт работы с SQL-базами данных.

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

1. Система ведения онтологии и моделирования бизнеса
2. Система верификации типов с правилами подстановки
3. Система среды исполнения динамического кода
4. Система модульной эволюции кодовой базы

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

Для доказательства возьму конкретную тему совместимостей библиотек. Этот вопрос с технической стороны хорошо изучен, и разделяют три вида совместимостей: исходную, бинарную и поведенческую. Но будет полезным привести примеры еще раз, разбив не просто по этим трём категориям, а по зонам ответственности, для того, чтобы понять, какие трения возникают между самими подсистемы Явы.

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

Как устроен процесс собеседования QA-инженера в 2026 году? Из каких этапов он состоит и чем интересуются интервьюеры на каждом из них? В этом гайде я разложил всё по полочкам: что спрашивает HR (и как он оценивает ваши ответы), какие блоки теории нужно повторить manual-инженерам, а какие — automation-инженерам на Java, и как проходит секция с задачами на логику и лайвкодингом.

Внутри — структурированные списки вопросов с разбивкой по темам, реальные примеры из практики и советы, как правильно "продать" себя на каждом этапе. Материал будет полезен как джунам, так и опытным специалистам для систематизации знаний.

Как тестировать несколько мобильных приложений в одном «Appium‑проекте». Показываю архитектуру фреймворка, запуск тестов через аннотации, потокобезопасный контекст и подключение новых приложений без дублирования кода.