Все руки не доходили рассказать об MDC (Mapping Diagnostic Context) в Java и Spring.

Немного о проблеме, которую можно решить, используя этот инструмент.

Представим, что у нас есть большой (или не очень) RESTful сервис, запросы которого проходят через множество слоев приложения и каждый запрос выполняется асинхронно. 

Как в любом приложении у нас есть множество мест, где происходит логирование различной информации.
И вот представим, что нам частенько нужно будет смотреть логи, которые связанны с одним конкретным запросом (грубо говоря, проследить trace запроса по всему нашему приложению и его слоям). Причем запросов у сервиса огромное количество - фильтрация по времени не подходит.

Как решить эту проблему? Очевидно, что нужно для каждого запроса завести свой request-id.

Можно пойти очень простым путем и прямо в самом контроллере генерировать id и в каждый метод, где происходит какое-либо логирование, прокидывать дополнительным параметром этот request-id.
В таком случае лог везде будет выглядеть как-то так:

log.info("Some log message. Request-ID: {}", requestId);

Везде пропихивать и прописывать этот request-id - очень неудобно.

Для этого существует MDC - контекст (Thread Local-ный), содержащий различные диагностические метки, которыми можно обогащать свой лог.
Достаточно просто настроить logback-appender, который будет из MDC доставать информацию и выводить в консоль.
Тогда добавление request-id будет выглядеть так:

MDC.put("request-id", requestId);
try {
 invokeSomeMethod();
} finally {
 MDC.clear();
}

В таком случае, при правильно настроенном appender'е, каждый лог будет обогащаться уникальным идентификатором запроса.

Можно пойти дальше и написать свой WebFilter, который будет автоматически генерировать и добавлять в MDC любую полезную информацию, а так же добавить возможность с помощью header'ов самому переопределять id запроса (для отладки, например).

Возможно кто-то не знал, но у Telegram есть полностью изолированное тестовое окружение, в котором можно совершенно спокойно тестировать своих ботов без аффекта на реальных пользователей.

Чтобы получить туда доступ, нужно создать отдельный Telegram-аккаунт в этом окружении (можно использовать тот же номер, что и на основном аккаунте) -> инструкция

После чего, как обычно, написать BotFather'у и получить токен.

Тестовое окружение позволяет эмулировать покупки, проводить end-to-end тестирование и многое другое, что очень хочется проверить, но без костылей.

Референс на полную документацию по тестированию Telegram-ботов -> тык

Референс на крутую статью про это от ребят из beeline -> тык

Не могу не поделиться этим шедевром:

Метал-группа Nanowar of Steel выпустила трек под названием HelloWorld․java

Текст песни полностью состоит из рабочего кода Hello World на Java, и звучит прекрасно

r/#videos

Круто когда open-source фреймворки/библиотеки/инструменты развиваются.

Но не круто когда разработчики выпиливают какое-то API и при этом не пишут как/чем его можно заменить.

Так поступили крутые дяди разрабы Flyway (популярный инструмент миграции баз данных) -> тык
Они просто обозначили метод устаревшим, к удалению в 9 версии, но без какой-либо информации о том, чем же можно будет его заменить.

В итоге вместо того, чтобы быстренько заменить метод на что-то другое, приходится идти раскапывать документацию, читать форумы и issues на GitHub, дабы починить проблему (выпиленный метод нельзя просто удалить и радоваться жизни)

PS: не надо мне в комментах писать, что там просят использовать setIgnoreMigrationPatterns - он принимает на вход строку => хуй пойми что туда передавать

Все-таки новости про массовые сокращения IT-шников оказались правдой.

В Т1 (бывший Иннотех, дочка ВТБ) массово сокращают айтишников.

В Positive Technologies аналогично сокращают рабочие места.

Без внимания не остались дочки Сбера (СберМегамаркет, ЕАптека и тд).

VK тоже засветился, но, кажется, там не все так серьезно, как у ребят выше.

Не прикольно как-то, честно говоря, учитывая высказывания западных компаний про ИИ 🤖

Предостережение недели:

Не используйте никакие ORM'ки (особенно ебучий Hibernate) для сложных и долгоживущих проектов/сервисов.

Уж поверьте, лучше писать руками запросы, чем потом тратить кучу дней, копаясь в кишках ORM'ки и пытаясь разобраться в возникших проблемах.

Особенно больно, когда по какой-то причине нужно обновиться на новую мажорную версию - прямой путь в многодневный увлекательный (нет) дебаг кишков фреймворка.
Как правило, всегда есть 2-3 места (повезет, если не больше) в коде, где все внезапно развалится.

Поэтому лучше заранее откажитесь от соблазна не писать сикуэльки руками.
Хотя для маленьких проектов можно в целом пренебречь этим советом.

PS: что-то я зачастил с постами, теперь ухожу в закат (но это не точно)

Отмигрировал 29 микросервисов и их зависимотей с Spring Boot 2.7 на Spring Boot 3.2.

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

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

Топ самых хардовых проблем, с которыми я столкнулся:
1) Не адекватное поведение ObjectMapper - внезапно половина полей поменяла свое название из-за особенностей новой версии
2) Проблемы с неблокирующим построением индексов в PostgreSQL и транзакционными блокировками в миграциях Flyway 9
3) Измененное/Поломанное поведение каскадного удаления сущностей при использовании @ElementCollection и @CollectionTable в Hibernate 6
4) Поддержка двух версий Apache HttpClient для legacy-библиотек, которые так и не научились дружить с HttpClient5 - пришлось костылять и одновременно держать обе версии (client4 и client5) и дружить их между собой

Оставлю тут еще несколько основных приседаний, которые придется выполнить при миграции на Spring Boot 3.x (вдруг кто-то планирует обновляться):
1) Apache HttpClient4 -> Apache HttpClient5
2) Hibernate 5 -> Hibernate 6
3) Spring Security 5 -> Spring Security 6
4) javax -> jakarta
5) Spring Framework 5 -> Spring Framework 6

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