В одном и том же null часто прячут разные смыслы: “нет значения”, “неизвестно”, “неинициализировано”. Потом это всплывает в NPE и в кривой логике исполнения.
В Ceylon эту проблему решают через типовую систему, через Union типы. Подробнее, в переводе от Spring АйО.
В данной статье я хочу рассказать об подходе к организации параллельной обработки сообщений из Kafka, когда Kafka Topic используется как транспорт бизнес-событий, например транзакций или ордеров, которые необходимо отправить во внешнюю систему. При это важно обеспечить стабильную скорость обработки трафика и надёжность (отсутствие потерь) в условиях, когда downstream-система не на все запросы отвечает стабильно и быстро.
Покажу почему стандартные подходы, такие как обработка batch'ами, в определённых сценариях перестают работать и приводят к деградации производительности или рисками потери сообщений.
Для иллюстрации подходов далее будет использоваться код из демонстрационного проекта на Kotlin с использованием spring boot, webFlux, spring reactor и reactor-kafka. Код проекта не является production-ready: в нём, например, отсутствует обработка rebalance, а также ряд других моментов, обязательных для промышленной системы. Используется reactor-kafka, однако описываемые решения не зависят от конкретного фреймворка работы с Kafka и могут быть реализованы с использованием других.
В статье намеренно опущены детали реализации бизнес-протокола и механизма идемпотентности. В реальной системе они реализованы с использованием внутреннего хранилища и машины состояний обработки ордеров, но это за рамками данной статьи.
Соблюдение определённой структуры пакетов или архитектуры крайне важно. Особенно в Java, где для корректной работы некоторые элементы должны быть public или действительно доступны за пределами своего пакета.
В новом переводе от команды Spring АйО рассмотрим библиотеку с открытым исходным кодом ArchUnit, которая помогает в тех случаях, когда одного компилятора недостаточно.
Продолжаем прорабатывать методы шардирования. В прошлой статье было предложено простое, но крайне трудозатратное решение по реализации динамического шардирования (когда ассоциация ключа и шарда лежат в отдельном сервисе, а не вычисляется при помощи функции). В этой статье предлагается универсальное решение, которое позволяет гибко настраивать параметры шардирования и при этом не быть перегруженной возможностями, из-за которых производительность неуклонно снизится.
Records, pattern matching и sealed-типы сделали Java куда более «функциональной» — читать вложенные данные стало легко и красиво. Но как только вам нужно изменить что-то глубоко внутри неизменяемой структуры, начинается боль: каскад пересоздания records, копирование полей, десятки строк ради одного изменения.
В новом переводе от команды Spring АйО рассмотрим, почему у современной Java всё ещё есть пробел в истории неизменяемости — и как оптики закрывают его. Если pattern matching — это про элегантное чтение, то оптики дают то, чего так не хватает, — композиционную запись: определили путь один раз и дальше меняете вложенные поля одной строкой, без ручной реконструкции и без циклов.
В последнее время мне довелось много заниматься распараллеливанием однопоточного кода и показалось уместным свести воедино более-менее всё, что нам известно про разные типы многозадачности, с примерами и комментариями.
Примеры на Ruby, Go, Java.
Снова привет, Хабр!
разоблачение телеграм клиента Telega, что скрывается за оберткой обхода блокировок
Для кого статья: для техлидов и системных аналитиков (SA), архитекторов ПО.
О чём статья: об использовании некоторых удобных, современных подходов к проектированию ПО на стеке Java-Spring в enterprise в условиях большого количества команд и большой неопределенности.
Об авторе: лид стрима в облачном провайдере, в 2024-2025 гг. с коллегами разрабатывавший подходы к архитектуре микросервисов.
В условиях современной разработки, когда компании растут, а команды распределены по офисам и странам, классические подходы к проектированию часто становятся узким местом. Хаос в интеграциях, бесконечные согласования форматов данных и конфликты из-за изменений в API — это знакомые боли для многих архитекторов и тимлидов. Если вы тоже сталкивались с трудностями и конфликтами при разработке платформ с множеством микросервисов или хотите разрабатывать и не хотите сталкиваться – эта статья будет наверняка интересна.
Добрый день! Меня зовут Андрей Слекеничс, я PO GigaIDE, и сегодня мы продолжаем наш экскурс по функциональности GigaIDE.
Первая и предыдущая статьи цикла доступны здесь и здесь. Сегодняшний материал — последний, затрагивающий функциональность GigaIDE Community, и первый, в котором мы переходим к возможностям уже только GigaIDE PRO.
Если дедлайн плавающий или его нет, обучение и пет-проекты превращаются в вечный "черновик": сегодня читаешь доки, завтра переписываешь пример, послезавтра думаешь про идеальную архитектуру. Это нормальный творческий процесс - пока не заметишь, что за месяц у тебя так и нет ничего, что можно запустить и показать.
Когда я проходил AI Advent Challenge этот режим прокрастинации сломался: 28 дней подряд у тебя есть ровно сутки. В 10:00 приходит задание, а в 10:00 следующего дня - дедлайн. Поэтому каждый день заканчивается одной из двух вещей: либо у тебя есть работающий кусок, либо ты точно понимаешь, где решение не выдержало и почему.
Разбираем изменения в OWASP Top 10 версии 2025 года на примерах и рассматриваем, как SAST может помочь избежать уязвимостей.
Первое крупное контролируемое исследование влияния ИИ-ассистентов на поддерживаемость кода: код, написанный с GitHub Copilot и Cursor, не стал сложнее в эволюции для других разработчиков. В двухфазном эксперименте с 151 участником (95% — практикующие специалисты) одни разработчики создавали фичи с ИИ и без, а другие — развивали чужой код, не зная его происхождения.
Результат: нет значимых различий по времени, качеству кода (CodeHealth) или покрытию тестами. При этом в первой фазе ИИ дал типичное ускорение на 31–56%. Авторы предупреждают о двух невидимых рисках — раздувании кода и когнитивном долге — которые краткосрочные метрики не захватывают.
Привет, Хабр!
Вот мы уже полтора месяца в новом году, пора бы встретиться и обсудить насущные вопросы, что думаете?
Это мы приглашаем вас на наш первый в 2026 году Java Rock Stars Meetup. Надеемся, вы соскучились по нам и нашим митапам так же сильно, как и мы по вам!
Регистрация открыта, но количество мест ограничено.
Для кого статья: для собеседующих в первую очередь, и для кандидатов.
О чём статья: о задачах, разработанных мною для технических интервью бэкенд-разработчиков уровня middle и выше.
Об авторе: лид стрима в облачном провайдере, набирал большую часть команды в 2024-2025, пришлось скорректировать процесс проведения интервью.
В прошлой статье я рассказывал об этапах проводимых мною собеседований. Рассказывал об особенностях найма в IT в 2024-25. Были немного обрисованы задачи, мотивация их особенностей, специальные подходы. Теперь пора уделить внимание хардскиловой составляющей. В этой статье подробнее расскажу о задачах и разберу сходные вариации.
Разбираем на практике, как гарантировать доставку сообщений в Kafka/RabbitMQ без распределенных транзакций, используя паттерн Transactional Outbox.
В этой статье рассмотрим наиболее полную реализацию паттерна Transactional Outbox, которую можно будет легко расширять и применять в продакшне. Данная статья будет полезна как для разработчиков, которые еще не встречались с данным паттерном, так и тем, кто уже применял его в своей работе.
Record-классы удобны, пока класс = «состояние, всё состояние и ничего кроме». Любое отклонение (API канонического конутруктора не равно внутреннему представлению, нужно наследование) ломает «автогенерацию» и паттерн-деструктурирование (destructuring).
В новом переводе от команды Spring АйО статьи Brian`а Goetz`а, архитектора Java Language, предлагается следующий шаг в направлении data-oriented programming in Java: классы-носители и интерфейсы-носители (они же Carrier classes & interfaces). Концептуально, carrier классы родились из record-ов путем ослабления части их ограничений.
Комментарий от Михаила Поливаха: Друзья, помните, пожалуйста, что данная статья по сути является суммированием обсуждения Carrier классов из JDK Project Amber Mailing List. Я это к тому, что пока непонятно, в какой версии языка carrier классы появятся, и появятся ли они в том виде, в котором представлены в статье. Статью стоит рассматривать как пищу для размышления.
Я сделал сервис, который помогает проходить технические собеседования. Побочный эффект - у меня есть транскрипции 9 247 интервью. В первой части я показал общую аналитику: кто собеседуется, куда, на какие позиции, какие вопросы задают на теории. Эта часть про конкретные задачи на секции live-coding.
Энигма не сохраняет скриншоты экрана - приватность. Зато vision-модель описывает то, что видит кандидат: "код на Go, функция принимает слайс, цикл с горутинами...". По этим слепкам и транскрипциям я восстановил условия самых частых задач. Это было похоже на сборку пазла из 2 000 фрагментов, где половина кусочков одного цвета.
17 задач. 10 компаний. 5 стеков. Go, Java, Python, React, C#. С кодом, статистикой ошибок и выводами, на чём фокусироваться.
В новом переводе от команды Spring АйО рассмотрим, как можно ускорить Java-приложения без переписываний: в свежих JDK появились Ahead-of-Time оптимизации кэша, которые выносят «дорогие» этапы загрузки/линковки классов (и даже частично профилирование методов) из рантайма в заранее подготовленный артефакт.
Рассмотрим как устроен AOT-кэш в JDK 24–26, какие есть workflow (3 шага vs 2 шага/в один прогон), где прячутся подводные камни вроде удвоения требований по памяти при -XX:AOTCacheOutput, и какие практики обучения помогут реально сократить время старта и быстрее выйти на пик производительности.
Новая версия Veai 5.4 (плагин к IntelliJ IDEA со своим AI агентом для написания кода, тестирования и отладки) — это практичные улучшения для повседневной разработки.
Персональные пользователи теперь могут прикладывать изображения прямо в чат (удобно для фронтенда и UI-тестирования), запросы к моделям Anthropic стали до 70% дешевле за счёт улучшенного кэширования, а большие чаты автоматически сжимаются без дополнительных запросов к LLM.
Появились новые сценарии для автоматического разрешения merge-конфликтов и генерации UI-автотестов из мануальных кейсов, а также гибкие механизмы для целей кибербезопасности — глобальные запреты на чтение и редактирование файлов через .readignore и .writeignore.
Дополняют релиз улучшения интерфейса: единый diff нескольких изменений в чате, настраиваемый размер окна ввода, кнопки копирования и оценки ответов агента (👍 👎), а также более заметное оформление пользовательских сообщений.
Всем привет! Сегодня я расскажу, как мы переводили наши Java-команды на новые рельсы.
Проблема:
В прошлом год стало ясно, что покупать лицензии Intellij IDEA проблематично. Предложения с ресурсов вроде «Авито»выглядели сомнительно и небезопасно. И российский рынок разработки очень плотно занялся переездом на свои решения, заказчики требовали использовать сертифицированное по местным реалиям ПО и все такое прочее. О переезде на новую среду не говорил разве что кто-то совсем уж ленивый.
С чего мы начали:
Изучив заново рынок, мы (я и другие лиды, которым на плечи легла эта ноша) стали анализировать доступные решения. Пишем мы чаще всего, используя Spring Framework и технологии около него, хотя иногда и вынуждены адаптироваться к конкретным пожеланиям заказчика и рекомендуемым им технологиям. Но фокус-группа акцентировала внимание вокруг Spring.
