⚙️ Генерация 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

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

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

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

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

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

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

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

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

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

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

❓ Lombok — спасение от boilerplate или технический долг?

Lombok давно стал популярным решением. Аннотации вроде @Getter, @Builder, @Slf4j избавляют от рутинного кода и ускоряют разработку.

▪️ За Lombok
— Устраняет шаблонный код и снижает количество ручных ошибок.
— Удобен при работе с immutable‑объектами и внедрении зависимостей через конструкторы.

▪️ Против Lombok
— Зависимость от нестабильных internal‑API.
— Требует обязательной поддержки на всех IDE/CI.
— За «синтаксический сахар» приходится платить техническим долгом.

💬 Подключать Lombok и ускорять разработку ценой стабильности, или отказаться и держать чистоту кода?

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

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

🔹 Towards a JSON API for the JDK

Разработчики OpenJDK анонсировали JSON API для Java, пока только на уровне рассылки, но обещают скоро подготовить JEP или обновить JEP 198. Добавление JSON API видится крайне полезным, по крайней мере для простых проектов и скриптов.

🔹 Redis is now available under the AGPLv3 open source license

Начиная с версии Redis 8 система снова доступна под открытой лицензией AGPLv3, одобренной OSI. Вместе с этим в Redis 8 интегрированы технологии Redis Stack, включая поддержку JSON и Time Series, а еще представлен новый тип данных — vector sets.

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

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

Senior + / Lead Java Developer — 4 500 - 6 500$ — удалёнка

Руководитель команды разработки (Java) — от 300 000 ₽ — офис (Омск)

Team Lead Full Stack разработчик (Java + React) — от 300 000 до 400 000 ₽ — удалёнка

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

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

🎮 Реализация аутентификации с использованием Spring Security

Проблема: обеспечение безопасности приложения требует надёжной системы аутентификации и авторизации пользователей.

Решение: в книге «Java 17 Backend Development» автор предлагает процесс настройки Spring Security для реализации аутентификации с использованием JWT-токенов.

Пример кода:

public class JwtAuthenticationFilter extends OncePerRequestFilter {
    private final JwtTokenProvider tokenProvider;

    public JwtAuthenticationFilter(JwtTokenProvider tokenProvider) {
        this.tokenProvider = tokenProvider;
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request, FilterChain chain) throws ServletException, IOException {
        String token = tokenProvider.resolveToken(request);
        if (token != null && tokenProvider.validateToken(token)) {
            String username = tokenProvider.getUsernameFromToken(token);
            UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(username, null, null);
            authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
            SecurityContextHolder.getContext().setAuthentication(authentication);
        }
        chain.doFilter(request, response);
    }
}

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

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

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

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