Java *

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 про это.

В этой статье я хотел бы обобщить всё, что мы знаем про Hot/Live Reloading на JVM, и далее показать, как я пришел к реализации универсального Live Reloading решения для любых веб-приложений на JVM.

Вкратце, в этой статье мы:

🔹 Попробуем сформулировать, какие виды релоадинга бывают.
🔹 Подробно рассмотрим, какие реализации существуют на JVM.
🔹 И немножко обсудим детали реализации универсального решения, и что вообще к нему привело.

Как работать с оффсетами в Kafka на практике, используя Spring Boot?
Разбираем проблемы и их решения на примере интернет-магазина.

Простым языком и с примерами кода о режимах коммитов, проблемах с транзакциями и надёжных паттернах.

Рассказываю про одну простую, но эффективную реализацию вебхуков, не требующую тотальной переделки вашей замечательной системы и/или сетевой инфраструктуры.

~300 строк кода.

Когда количество доступных LLM инструментов (tool-ов) разрастается, традиционные подходы к tool calling становятся непрактичными — утилизация токенов улетает ещё до начала общения. К тому же, модели становится сложнее выбрать нужный набор tool-ов для решения проблемы.

В новом переводе от команды Spring АйО читаем о паттерне Tool Search Tool, предложенном Anthropic и реализованном в Spring AI с помощью ToolSearchToolCallAdvisor. Он позволяет LLM динамически находить нужные инструменты по мере необходимости, экономя до 64% токенов и повышая точность.

В слое Domain 90% проектов с тактическим DDD забыли о самом главном. Сегодня мы вспомним то о чем забыли или узнаем то чего не знали.

Представьте ситуацию: пятница, вечер, до релиза осталось два дня. Заказчик внезапно вспоминает, что «было бы неплохо генерировать договоры в PDF». Знакомо?

Я оказался в похожей ситуации год назад. Задача казалась тривиальной: взять HTML-шаблон счёта, подставить данные и получить красивый PDF. «Часа на два работы», — подумал я. Как ошибался...

Привет! Я Фёдор, CEO OpenIDE. За год с момента анонса OpenIDE выросла в стабильную, привычную и активно используемую IDE, которую всё чаще выбирают разработчики и компании. Мы создали её быстрой, предсказуемой и полностью доступной — и теперь готовы к следующему шагу.

В этой статье — что мы сделали, зачем мы это делаем и куда дальше движется OpenIDE.

Теперь, после того как в предыдущей статье так красочно описаны преимущества Fluent API появилось опасение что все  эти “плюшки” просто не могут быть бесплатными. Наверняка это очень дорого, или нет?

Продолжаем разговор о Fluent API. И теперь, после того как мы из предыдущей статьи (или/и личного опыта) узнали о том что это чудо из себя представляет давайте разберемся зачем оно нужно?

В то время как аналитики жарко спорят на тему станет ли основным языком программирования 6-го (видимо) поколения английский или все-таки китайский предлагаю поговорить немного на другую тему, но в том же направлении: как сделать код программы ближе к человеку? 

Один из ответов на этот вопрос зародился еще в 70-х годах прошлого столетия как method chaining в рамках языка Smalltalk и, благодаря стараниям Эрика Эванса и Мартина Фаулера дошел до нас как Fluent API.

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

В статье я расскажу, какие проблемы он решает, как устроен внутри, как его использовать и почему он оказался намного удобнее обычных self-made конфигураций.

В мире разработки часто возникает соблазн использовать знакомый инструмент для всех задач. Зачем изучать что-то новое, если есть проверенная реляционная база данных (РСУБД), такая как PostgreSQL или MySQL? Однако, когда дело доходит до реализации мощного, быстрого и релевантного поиска, этот подход терпит неудачу.

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

Чтобы статья была максимально практико-ориентированной, мы рассмотрим, как с помощью Spring Boot быстро поднять приложение с интегрированным Elasticsearch и реализовать поиск, который «летает».