⚙️ Генерация инфраструктуры для Contract Testing с Spring Cloud Contract и Testcontainers

Работаете с микросервисной архитектурой? Тогда знаете, как сложно обеспечить стабильные API-контракты между сервисами. Contract Testing решает эту проблему. А AI поможет быстро сгенерировать заготовку всей инфраструктуры для автоматизированной валидации контрактов.

📝 Промпт:

Generate a Java Spring Boot setup for contract testing using Spring Cloud Contract and Testcontainers.
— Configure a provider service and a consumer service.
— Use Spring Cloud Contract to define and verify contracts.
— Integrate with Testcontainers to run provider stubs in isolated environments.
— Add Gradle or Maven setup for running contract tests in CI.
— Provide examples for both producer and consumer side tests.

💡 Расширения:

— Добавьте integration with GitLab CI/CD or GitHub Actions для автоматической валидации контрактов при push'ах и pull request'ах.
— Добавьте generate stub JARs using Spring Cloud Contract Verifier для повторного использования контрактов на стороне потребителя.
— Добавьте handle contract mismatches gracefully with test reports and logs для быстрого выявления расхождений между сервисами и прозрачной отладки в CI.
— Добавьте include real-world example: REST endpoint for user profile with request validation and response structure как шаблон, который можно адаптировать под любую бизнес-логику.

🐸 Библиотека джависта #буст

❓ Когда стоит использовать DTO в Java-проектах?

Наш подписчик спрашивает:

В одном из проектов я заметил, что контроллеры возвращают модели сущностей напрямую, а в другом — используют DTO. Я всегда считал, что контроллеры должны возвращать только DTO. Почему в одном проекте возвращают модели, а в другом — DTO? Какой подход правильный?

🔹 Как вы подходите к использованию DTO и моделей

— В каких случаях вы предпочитаете возвращать модели сущностей, а когда — DTO?
— С какими трудностями вы столкнулись при выборе между DTO и моделями в своих проектах?
— Какие подходы к использованию DTO и моделей сработали для вас лучше всего?

💬 Делитесь в комментариях вашим мнением и опытом.

P.S. Если хотите задать вопрос, заполните нашу гугл-форму. Это займет 5 минут.

🐸 Библиотека джависта #междусобойчик

👑 Магия IntelliJ IDEA

Если вы часто просматриваете стек вызовов или трассируете поведение методов — попробуйте «Call Hierarchy» (Ctrl + Alt + H). Этот инструмент показывает, кто вызывает ваш метод — и кто вызывает вызывающего, до самого верхнего уровня.

🔹 Что делает

— Строит иерархию вызовов метода вверх или вниз.
— Помогает отследить влияние метода по всей кодовой базе.
— Работает даже с интерфейсами и абстрактными методами — покажет всех наследников.

🔹 Зачем это нужно

— Находит неочевидные связи между частями кода.
— Упрощает работу с легаси: видно, какие методы безопасно менять.
— Быстро определяет, как ошибка «долетела» до нужного места.

🔹 Как использовать

— Поставьте курсор на метод → нажмите Ctrl + Alt + H.
— IDEA откроет дерево вызовов (Call Hierarchy).
— Вы можете «разворачивать» цепочку вверх по стеку или вниз.

🐸 Библиотека джависта #буст

🐸 Библиотека джависта #развлекалово

❓ Java или Kotlin?

Оба языка активно развиваются на JVM, но какой логичнее изучать и использовать для новых проектов.

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

▪️ Сторонники Kotlin отвечают, что язык быстро набирает распространение — он уже обогнал по популярности все другие JVM‑языки вместе взятые, а его interop с Java и современные фичи делают его крайне привлекательным

💬 Стоит ли переключаться на Kotlin, или Java по‑прежнему "самая надёжная ставка" для новых проектов?

🐸 Библиотека джависта #междусобойчик

🆕 Java Digest: подборка материалов

🔹 Java Annotated Monthly – June 2025

Обзор редакции IntelliJ IDEA Blog: 17 активных JEP‑пропозиций для Java 25 и обзор предстоящих нововведений. Подчёркивается, что Java всё ещё активно развивается, несмотря на появление новых языков

🔹 How to Handle 1 Million Requests per Minute

Обсуждение реальных паттернов проектирования для высоконагруженных систем — балансировка на каждом уровне, эффективное кеширование, асинхронная обработка и др.

🔹 Clean and Modular Java

Автор показывает, как организовать модульную архитектуру (core, adapters, infrastructure) в Java-приложении с использованием Maven и четким разделением слоёв. Отлично подходит для архитекторов и тех, кто хочет улучшить читаемость и гибкость кода.

🐸 Библиотека джависта #свежак

😮 Топ-вакансий для джавистов за неделю

Разработчик Java — от 180 000 до 250 000 ₽ — гибрид (Москва)

Java разработчик (middle+/senior) — от 150 000 ₽ — гибрид (Москва)

Java-разработчик — от 150 000 ₽ — гибрид (Москва)

Java Middle разработчик — от 180 000 до 220 000 ₽ — гибрид (Москва)

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

🎮 Реализация асинхронной обработки сообщений с Apache Kafka

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

Решение: в книге «Java 17 Backend Development» автор предлагает интеграцию Apache Kafka для асинхронной обработки сообщений. Это позволяет разгрузить сервисы и обеспечить высокую производительность системы.

Пример кода:

public class KafkaMessageListener {
    private final KafkaConsumer<String, String> consumer;

    public KafkaMessageListener(String bootstrapServers, String groupId, String topic) {
        Properties properties = new Properties();
        properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, groupId);
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());

        this.consumer = new KafkaConsumer<>(properties);
        this.consumer.subscribe(List.of(topic));
    }

    public void startListening() {
        while (true) {
            var records = consumer.poll(Duration.ofMillis(100));
            records.forEach(record -> {
                System.out.println("Received message: " + record.value());
                // Обработка сообщения
            });
        }
    }
}

Преимущества:

— Лёгкая адаптация к увеличению объёмов данных.
— Гарантированная доставка сообщений.
— Возможность обработки сообщений в фоновом режиме.

Еще больше полезных книг — в нашем канале @progbook

🐸 Библиотека джависта #буст

⚙️ Генерация CI/CD пайплайна

Автоматизация сборки, тестирования и деплоя — must-have даже для pet-проекта. Но настраивать GitLab CI или GitHub Actions вручную? Спросите AI — и получите готовый пайплайн, адаптированный под ваш стек.

📝 Промпт:

Generate a CI/CD pipeline for a Java Spring Boot application using GitLab CI.
— Include stages: build, test, integration-test, package, deploy.
— Use Gradle (or Maven) as the build tool.
— Include support for Docker image build and push to container registry.
— Run integration tests using Testcontainers.
— Use caching to speed up pipeline runs.

💡 Расширения:

— Добавьте environment-specific deployments: отдельные джобы для dev/stage/prod с переменными окружения, secrets и условиями по веткам (only/except или rules).
— Интегрируйте notifications в Telegram или Slack на стадии failed/success для быстрой обратной связи.
— Добавьте security scan stage: используйте Snyk или OWASP Dependency Check для анализа уязвимостей зависимостей.
— Автоматизируйте Docker image tagging: используйте Git tag или commit hash, чтобы образы были отслеживаемыми.

🐸 Библиотека джависта #буст

🐸 Библиотека джависта #развлекалово

🔍 Правильное понимание Single Responsibility Principle (SRP)

О принципе единственной ответственности слышали все. Конечно правильный ответ согласно книги Роберта Мартина "Чистая архитектура": SRP - это принцип единой ответственности.

Но при попытке разобраться в более дательном понимании принципа его часто трактуют слишком буквально:

Метод должен реализовывать одну задачу

Класс должен отвечать за один функционал

Да, это отчасти верно и такой принцип тоже есть, но он применяется на низшем уровне системы. SRP же применяется на более высоком уровне.

В итоге получаются сервисы, в которых вроде как всё «по SRP», но изменения в одном бизнес-сценарии ведут к каскадным правкам в десятках файлов. Это сигнал: принцип нарушен, несмотря на формальное соблюдение.

🔹 О чём на самом деле говорит SRP

В классическом изложении (по Роберту Мартину):

Модуль должен иметь только одну причину для изменения.

И под модулем понимается не метод и не даже один класс, а группа классов и интерфейсов, объединённая общим потребителем — актором.

🔹 Что это означает на практике

1. Определите акторов
Актор — это не всегда пользователь. Это может быть внешний сервис, внутренний инструмент, регламент. Важно: требования акторов не должны пересекаться. Если они меняются независимо — значит, им нужны отдельные модули.

2. Постройте модули вокруг акторов
Частая ошибка — «модуль пользователей», в котором и логика регистрации, и рассылка писем, и обработка GDPR-запросов.
Лучше разделить:
▪️ один модуль обслуживает end-user’а,
▪️ другой — юридические требования,
▪️ третий — внутреннюю админку.

3. Не дробите код ради SRP, если это нарушает целостность модуля
SRP — это не о размере, а о мотивации изменений. Метод в 100 строк, обслуживающий один сценарий, допустим. А вот класс, который реагирует на десяток независимых событий — нет.

🔹 Пример

❌ Плохо:

public class OrderService {
    public void placeOrder() { ... }
    public void notifyCustomer() { ... }
    public void saveAuditLog() { ... }
}

Этот класс изменится при любом изменении в бизнес-логике, в уведомлениях или в логировании. Три причины изменения — три актора.

✔️ Хорошо:

▪️ OrderProcessor — отвечает за бизнес-сценарий
▪️ NotificationService — отправка сообщений
▪️ AuditService — логирование

Каждый компонент обслуживает одного актора, имеет свою причину для изменений и независимую эволюцию.

🔹 Вывод

SRP стоит понимать как инструмент для проектирования архитектуры. Его задача — отделить контексты, которые меняются по разным причинам, и тем самым минимизировать связность и ограничить зону изменений. Не методы, не классы, а контексты и акторы.

🔼 Если пост был интересен/полезен → поддержите бустом канал

🐸 Библиотека джависта #буст

❓ Виртуальные потоки — будущее или сырой эксперимент?

С выходом Java 21 виртуальные потоки (Virtual Threads) стали доступными для продакшна. Обещают удобный и масштабируемый способ работы с параллелизмом и без боли реактивщины.

▪️ Сторонники Virtual Threads уверены: это долгожданный прорыв. Теперь можно писать привычный синхронный код, не заморачиваясь с CompletableFuture и реактивными фреймворками. Масштабируемость? Да! Сотни тысяч потоков без overhead-а — вполне реально.

▪️ Напротив: tooling и экосистема пока не готовы. IDE лагают при отладке, JMX и трейсы работают криво, баги не редкость. Да и блокировки никуда не делись — просто теперь они маскируются, а не устраняются. По сути — "асинхронность для ленивых".

💬 Стоит ли сразу использовать их в новых проектах или подождать пару релизов?

🐸 Библиотека джависта #междусобойчик

👑 Магия IntelliJ IDEA

Когда нужно что-то быстро протестировать, написать фрагмент кода, проверить регулярку или сериализацию — не создавайте новый класс. Вместо этого используйте Scratch File (Ctrl + Alt + Shift + Insert).

🔹 Что делает

— Создаёт временный файл вне проекта
— Поддерживает Java (и другие языки), автодополнение, импорт, выполнение
— Сохраняется автоматически, можно переключаться между файлами

🔹 Зачем это нужно

— Быстрые пробы кода без засорения проекта
— Подходит для написания утилит, генерации данных, логов
— Удобно держать список SQL-запросов, curl-ов или шаблонов прямо в IDE

🔹 Как использовать

— Нажмите Ctrl + Alt + Shift + Insert → выберите язык (например, Java)
— Пишите как обычно: public static void main, System.out.println() — и запускайте
— Можно открыть менеджер Scratch-файлов через Project > Scratches and Consoles

🐸 Библиотека джависта #буст

🔼 От конкурентного программирования к промышленному производству

В разработке ПО ключевым фактором успеха является не только качество кода, но и способность команды эффективно решать сложные задачи. В статье рассматривается, как алгоритмическое мышление помогает разработчикам:

▪️ Оптимизировать производительность: использование алгоритмов для улучшения скорости и эффективности приложений.

▪️ Управлять сложностью: применение структур данных и алгоритмов для упрощения разработки и поддержки кода.

▪️ Повышать качество продукта: снижение количества ошибок и улучшение стабильности приложений.

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

🔗 Подробнее в статье

🐸 Библиотека джависта #буст

🐸 Библиотека джависта #развлекалово