Сегодня на конференции JPoint, покажу интересное 🤪

любимая атмосфера 💔💔💔

дискутируем про кафкин консьюмер на персидских коврах 🤪

Кто-нибудь знал про Spring Data REST ?
Штука для того, чтобы объединить 2 слоя в один - JPA и REST контроллер

Анноташка @RepositoryRestResource

ShedLock - java библиотека, которая гарантирует, что одновременно будет выполняться только одна job, несмотря на количество реплик сервиса, в котором эта джоба реализована.
Под капотом использует БД для хранения локов.

Анноташки:
@EnableSchedulerLock
@SchedulerLock

к стенду райфа фиг протолкнёшься 🤔

тоже очень загруженный стенд 😏😉

Blockhound - библиотека для поиска блокирующих вызовов в реактивном коде, инициализируем в тестах и готово)

BlockHound.install();

классный слайд, на котором описано когда лучше использовать блокирующий подход, а когда реактивщину 😌

Только что слушала доклад про Spring Cloud Gateway, где показывали код как будто из моего проекта в Сбере)
задумалась что могла бы сделать такой же доклад 🤔

зачем инженерно-зрелым командам развивать иннерсорс

влетаю в новый день конфы, ух как послушаю про TDD 😅

TDD (Test Driven Development) - это подход к разработке, при котором тесты пишутся перед кодом.

Что хорошего в TDD?
• разработка в режиме fail-fast
• не страшно дорабатывать и вносить правки, т.к. уже есть тесты
• лучше понимаешь как работает фреймворк
• можно учесть требованию к коду заранее, в тестах
• приносит удовольствие :)

Что плохого?
• когда делаем моки, мы пишем тест на то, чего в жизни быть не может, это цена за TDD
• если включаем spring.main.initialization=lazy то тесты поднимаются быстрее, но это отдаляет нас от prod like тестирования
• тратим время на написание множества тестов вместо разработки фичи 😅

Вывод 1: просто пишите тесты, не очень важно до или после кода
Вывод 2: используйте тест контейнеры, они приближают к prod like тестированию
Вывод 3: в докладе нет ничего про Spring Boot 3 🤣
Вывод 4: смотреть на лайвкодинг это отдельный вид кайфа 😍

Экскьюзьми, я что опять в универе? 😅

Плюсы и минусы использования паттерна Value Object

+
• часть ошибок можно выявить на этапе компиляции
• более безопасный и простой код
• правила валидации инкапсулированы в одном месте
• этот объект всегда валиден

-
• правила валидации могут измениться, а данные останутся и тогда могут возникнуть ошибки при чтении из БД
• если мы не владельцы данных, то внешний сервис может начать возвращать невалидные данные и будет парализована работа нашего сервиса из-за ошибок валидации
• не работает like при передаче объекта в репозиторий

В докладе Семён предлагает использовать этот паттерн только на этапе input и только в случае, если мы являемся владельцем данных.
Зачем:
• новые правила валидации не помешают чтению старых (возможно невалидных) данных
• like запрос работает как надо
• сохраняются все перечисленные выше плюсы

P.S. для Котлина неактуально, там из коробки всё :)
P.P.S. думойте сами, решайте сами 😅 я нашла у нас одно место, где можно попробовать применить