С появлением виртуальных потоков в Java благодаря Project Loom, параллельное программирование стало проще, а производительность — выше. Однако за этой простотой кроются новые вызовы для инструментов отладки и анализа. Как читать тред-дампы, если их теперь тысячи — или миллионы? Какие средства реально помогают найти взаимные блокировки и аномалии в асинхронном коде? Рассмотрим в новом переводе от команды Spring АйО.
Привет, Хабр! Меня зовут Владислав, я занимаюсь разработкой расчётных систем в Мир Plat.Form. Два года назад мы перешли от взаимодействия через REST к использованию Kafka между системой Фронт-Офиса, в которой хранятся данные об авторизованных транзакциях, и системой Бэк-Офиса, ответственной за выполнение клиринга. При этом мы реализовали собственный сериализатор для работы с AVRO сообщениями. Более подробно о причинах выбора такого подхода я рассказал в статье.
Тогда нам не требовалась поддержка изменения схемы данных, так как контракт взаимодействия был стабильным на протяжении нескольких лет.
Но в прошлом году перед нами встала задача внедрения новой интеграции, что могло повести за собой частые изменения в модели данных, из-за чего нам пришлось пересмотреть подход к работе с AVRO сообщениями.
В этой статье я расскажу:
1. Что такое эволюция данных и почему она критична для Kafka при работе с AVRO сообщениями.
2. Какие варианты решения мы рассмотрели.
3. Как реализовали поддержку изменений схемы.
4. Подводные камни, с которыми столкнулись, и как их обошли.
В прошлой статье мы рассказали, какие группы плагинов есть на маркетплейсе GigaIDE. Их количество постоянно растёт — как за счёт open source-плагинов, ранее доступных у JetBrains, так и за счёт собственных разработок. Именно оригинальным плагинам мы и посвятим цикл статей.
Начнём с группы ИИ-помощников — плагинов, которые используют возможности GigaCode для автоматической работы с кодом. Все они бесплатны, но для работы требуют активированный GigaCode.
Команда Spring АйО подготовила перевод статьи в которой автор разбирает, где параллельные стримы действительно масштабируются, а где создают накладные расходы, конкуренцию за ресурсы и иллюзию производительности. Коротко: сначала аналитика и измерения, потом — параллелизм.
Привет, Хабр! Cегодня рассмотрим, как ускорить интеграционные тесты в Spring Boot с помощью специальных slice аннотаций.
Начнём с того, почему вообще тесты могут быть медленными. Используя @SpringBootTest, мы просим Spring Boot поднять весь контекст приложения для каждого тестового класса. У нас доступны все бины, но часто все это избыточно. Например, хочется протестировать контроллер, а Spring загружает ещё и базу данных, и сервисы, и шлёт запросы к Kafka. В результате простой тест метода контроллера может запускаться несколько секунд, пока поднимется веб‑сервер, инициализируется база, подтянутся все классы.
Эту проблему осознали и добавили так называемые test slice‑аннотации. Все простоб грузим не весь контекст, а только срез приложения, например, только веб‑слой или только слой доступа к данным. Spring Boot содержит готовые slice‑аннотации для основных слоёв: @WebMvcTest для веб, @DataJpaTest для JPA‑репозиториев, и ещё пачку для других случаев.
Рассмотрим на примерах двух интересных слайса: @DataJpaTest и @WebMvcTest.
Amplicode 2025.3 — релиз про новые фичи для Spring Data JDBC, улучшения для HTTP-клиента Connekt (между прочим, убийца Postman), поддержку MyBatis и новые возможности по работе с инфраструктурой вокруг Kubernetes и Terraform.
Ниже — ключевые изменения по блокам.
Привет, Хабр! Меня зовут Каненков Александр, я backend-разработчик в Домклик. Не так давно я резко и с головой погрузился в мир реактивного программирования и очень заинтересовался этой темой. Хочу поделиться кратким введением в Spring Data R2DBC, зачем это нужно, как начать использовать и какие преимущества даёт. Мы разработаем небольшое приложение, добавим flyway и напишем пару тестов.
Команда Spring АйО подготовила материал о том, почему «быстрый запрос в MongoDB» — это не магия, а дисциплина: индексы, форма запроса, проекции, explain(), профайлер и наблюдаемость в Java/Spring Boot. Разбираем, как отличать IXSCAN от COLLSCAN, где чаще всего прячутся антипаттерны (skip-пагинация, тяжёлые $regex/$nin, findAll), и как выстроить измеримый цикл оптимизаций от Atlas/Compass до Micrometer.
Данная статья посвящена практическому изучению механизмов Class Data Sharing и AppCDS. В ней рассматривается, какие именно компоненты ускоряются CDS в HotSpot JVM, почему для Spring‑приложений зачастую оказывается недостаточно использования «CDS по умолчанию», а также каким образом можно собрать .jsa‑архив для приложения — как в локальной среде, так и при работе с Docker.
Отдельное внимание уделено теоретическим аспектам JIT‑компиляции и tiered compilation, а также практической части с измерениями времени запуска. В качестве дополнения рассматривается влияние использования Spring AOT, а также переход на Java 25 и применение Spring AOT Cache.
Отказоустойчивый и масштабируемый энтерпрайз невозможно спроектировать по книжкам. Одно и то же решение может фигурировать и в best, и в bad practice — и, что забавно, иногда переходит из одного списка в другой. Ещё недавно монолиты считались злом, а теперь снова в моде.
Хотите посмотреть, как знакомые паттерны ведут себя в реальном контексте?
Чтобы показать это на практике, я собрала три инженерных кейса. Каждый оформлен в формате детективного квиза: роль, фабула, вопросы на размышление, разбор и выводы. Попробуйте разобраться в проблеме, пройти тест и определить: где костыль, где инженерный компромисс, а где — настоящая best practice.
Привет, Хабр! Я сегодня хочу разобрать одну из самых мощных, но часто неправильно понимаемых архитектурных концепций — CQRS. Если вы уже переросли уровень «просто писать CRUD» и задумываетесь о том, как строить системы, которые будут масштабироваться и оставаться производительными — эта статья для вас.
Забудьте о сторонних стартерах и костылях — Spring gRPC 1.0 GA уже здесь. Теперь можно строить высокопроизводительные RPC-сервисы с Protocol Buffers прямо из коробки, без плясок с бубном.
В новом переводе от команды Spring АйО рассмотрим пошаговую миграцию со старых решений, генерацию кода из .proto, и сравнение с тем, как это работает в Quarkus.
AI-помощники в IDE — уже не фантастика, а ежедневная реальность. Но как сделать так, чтобы они действительно помогали, не лезли не в тему, не сливали код в облако и не требовали подписку на каждого чиха? Ответ — Continue: open source AI-ассистент, который интегрируется с IntelliJ IDEA, GoLand, WebStorm, OpenIDE и другими IDE на базе IntelliJ Platform.
Он предоставляет автодополнение, чат, команды над выделенными фрагментами и даже агентный режим с патчами на несколько файлов. Главное — вы выбираете модель и правила игры.
В статье я сравниваю четыре реализации одного и того же сервиса поверх PostgreSQL:
1. Spring MVC + JDBC
2. Spring WebFlux + R2DBC
3. Ktor + JDBC
4. Go + pgx
Все сервисы крутятся в Docker с одинаковыми ресурсными лимитами и прогоняются через один и тот же JMeter-план. Для каждого стека я ищу максимальный RPS при соблюдении SLO по p99-латентности.
Я подробно разбираю:
- как устроен стенд (Docker-compose, Postgres, Prometheus, Grafana, JMeter);
- как реализованы сервисы и чем различаются модели конкурентности;
- методологию нагрузочного тестирования и расчёта RPS@p99≤SLA;
- как реально ведут себя блокирующий стек, реактивный стек и Go под честной нагрузкой.
После того как наш парк вырос до более 245 тысяч самокатов и велосипедов, а команда сервисных центров начала исчисляться сотнями человек, стало ясно: управлять статусами устройств, задач и процессов в нашем внутреннем сервисном приложении по старинке уже не получится. Представьте себе: нужно изменить статус самоката или работы, а механик, специалист по контролю качества и бригадир — роли с разными функциями — видят одни и те же кнопки, одни и те же статусы, в которые можно перевести самокат. Иногда нажимают не туда — и ремонт идет не по желаемому процессу, что-то может потеряться, сроки увеличиваются… Добавим в уравнение еще разные версии мобильного приложения с различным набором кнопок — в какой-то версии кнопку убрали, в какой-то добавили. В итоге вся надежда только на бэкенд, перед которым встала задача контролировать и валидировать действие каждого пользователя в приложении.
В WCMA (Whoosh Control Maintenance App, писали о нем в предыдущей статье), нашем внутреннем приложении для управления флотом, мы столкнулись с этой проблемой в полной мере. Напомню, в этом приложении работает наша сервисная команда, через него мы обслуживаем самокаты и велосипеды в городе, следим за их зарядом, переставляем на спросовые парковки, а также восстанавливаем и чиним.
Одна из первых версий WCMA была больше похожа на пульт-отмычку для самоката, приложение не было интуитивным: все переводы доступны, а значит люди нажимали куда попало, часто новички путались в процессах и кнопках, в целом было мало контроля над действиями пользователей. Это могло вызывать ошибки “в полях” или при ремонте флота. Чтобы это исправить, мы завели большее количество ролей в системе, и каждая роль получила свой особенный раздел в WCMA. А для надежности добавили много проверок на бэкенде, валидирующих действия команды.
Такой подход работал, статусная модель была простой: несколько базовых состояний и переходы между ними. Но с ростом бизнеса логика усложнилась. Появились региональные особенности работы в разных городах, ролевые ограничения, условные переходы, зависящие от контекста.
Меня зовут Игорь Волынский, я backend-разработчик в команде WCMA Whoosh. И сегодня я расскажу, как мы решили эту проблему: построили централизованную и гибкую систему управления статусами, добавили условные переводы с хендлерами для проверки бизнес-правил и реализовали динамические сценарии для гибкого формирования UI. Спойлер: теперь наши механики и менеджеры видят только те действия, которые им реально доступны, а бэкенд гарантирует целостность данных на уровне системы.
GitHub только что анонсировал изменения в ценообразовании Actions. Ранее GitHub Actions имел бесплатный control plane. Это означало, что если вы использовали GitHub Actions, но запускали задачи вне GitHub-hosted runners — будь то ваши собственные машины или в вашем собственном AWS аккаунте — вы ничего не платили GitHub за эти минуты; вы платили только за вычислительные ресурсы. Теперь подход изменился. Команда Spring АйО подготовила перевод анонса команды Github.
Каждая успешная рекламная кампания начинается с технологий, которые остаются за кадром. Но именно от них зависит, увидит ли целевой пользователь нужное объявление, сможет ли рекламодатель быстро настроить кампанию и получить точный отчет, и не сгорит ли его бюджет из-за мошенников или технических сбоев. Когда мы начинали проект AdWebs, нам нужно было создать платформу, которая справится с тремя ключевыми вызовами: высокая нагрузка, безопасность данных и безупречный пользовательский опыт. Вот как мы это сделали.
Кажется, что оборачивать BigDecimal и String в отдельные классы — это overengineering и преждевременный DDD. Но именно из-за этих «лишних» типов в прод не пролезают посылки в ПВЗ, проценты внезапно превращаются из 0.8 в 80, а деньги теряют валюту и смысл. В статье на реальном примере логистики разбираем, как один небольшой record Weight и несколько аккуратных Value Object’ов наводят порядок в бизнес-логике: инварианты перестают жить в комментариях, проверки перестают дублироваться, а код начинает читаться как текст предметной области. Без внедрения полного DDD, без религиозного фанатизма — только практические шаги.
Команда Spring АйО подготовила перевод про Fray — инструмент для обнаружения и воспроизведения ошибок многопоточности в Java-программах. Основанный на научных исследованиях и написанный на Kotlin, Fray использует технику теневой блокировки для выявления взаимоблокировок и других проблем синхронизации. Он уже доказал свою эффективность на таких проектах, как Kafka, Flink и Lucene.
Эта статья дополняет предыдущую. Там мы зафиксировали проблемы. Здесь разберем, что именно мы сделали со стороны Amplicode, чтобы агент начал работать как опытный software engineer: опираясь на структуру проекта, детерминированные генераторы и понятные высокоуровневые операции.
Если коротко, в первой статье было несколько основных болей:
– LLM часто обучены на слегка устаревшем мире, и это вылезает в мелочах (и не только).
– Галлюцинации и нехватка контекста идут рука об руку: «кажется, в этой библиотеке должен быть такой метод» и пошло-поехало.
– Переизбыток контекста тоже зло: агент прочитал половину репозитория, потратил деньги, запутался, а потом еще и забыл начало чата.
– Типичный агентный workflow: «сгенерил простыню кода, оно не компилится, давай чинить, ой теперь сломалось другое».
И на этом фоне появляется логичный вопрос: а можно сделать так, чтобы агент работал не с сырыми файлами, а с моделью проекта и сущностями фреймворка? Чтобы он не гадал, где DTO, как принято именовать контроллеры и какие миграции у вас используются?
Собственно, Spring MCP от Amplicode про это.
