Всем привет! Один подписчик подсказал идею написать про Backpressure, я решила и правда, тема классная)

Не знаю как вы, а я долгое время не могла уложить у себя в голове это понятие. Сейчас попробую объяснить так, чтобы мы все поняли, особенно я, когда опять забуду 🤣

Этим термином называют
1) само явление, когда источник информации генерит её быстрее, чем получатель может её принять и обработать
2) механизмы сглаживания и уменьшения этого явления
2.1) в доке реактора написано, что это возможность консюмера сообщить продюсеру, что ему плохо)

Пример: если у меня есть два сервиса и один из них отправляет 20 rps, а второй может принимать и обрабатывать только 10, то будет создаваться дефицит обработки 10 остальных запросов в секунду.
В таком случае рано или поздно второй сервис накопит очередь на обработку и упадёт с OOM, либо не будет обрабатывать эти запросы вообще.

Есть несколько стратегий решения этой проблемы:
• решить на стороне продюсера 😅 (изян)
• копить буфер из сообщений на обработку
• отбрасывать сообщения

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

У нас на практике возникала проблема с backpressure дважды.
Один раз, когда на реактивном стеке мы использовали Scheduler.elastic() и смотрели как сервис падает с OOM 🤪 Сейчас elastic уже задепрекейтили))
Второй раз, когда мы читали из кафки гигантское количество сообщений и делали update в постгрес. Там быстренько разрастался WAL, и на репликах тоже 😨
Решить это до конца мы так и не смогли, крутили и постгрес и консюмера, чтобы медленнее читал. Коллеги поправят, если я что-то ещё забыла)

А у вас была проблема с backpressure? Как решали?

Ребята, я состою в сообществе @ityoutubers_com, хоть и не ютубер 😅
и у нас появилась шаренная папка с нашими IT-каналами 😏🔥
https://t.me/addlist/OSGJfcXF_chhOWIy

Всем привет)
Канал быстро вырос и я очень хочу знать кто вы 🤩

непростительно мало мемов у меня в канале, буду исправлять)

Кто блин эти 10 человек, которые проголосовали на первом опросе и не проголосовали на втором? 🤣🤣🤣

Про собеседования

Всем привет)
Я и мои коллеги достаточно часто проводим собеседования на java разраба, поэтому сегодня, так скозать, о наболевшем))))
Собеседование у нас проходит в несколько этапов, расскажу про техническую часть. Для неё мы придумали список вопросов и разбили их по категориям, чтобы тщательно и побыстрее 😅 оценить кандидата.

Ищем middle+/ senior, поэтому нам важно, чтобы человек мог пояснить за микросервисы и монолиты, всякие паттерны и солиды. Что когда использовать, зачем камунда 🤣
Если в резюме CQRS и Event Sourcing, спросим)
Очень интересно слушать про текущий проект, понимает ли кандидат, как там всё устроено и почему, бывает что нет. 🫠

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

По тестированию обычно спрашиваем про юниты, интегры, тестконтейнеры, etc. Если кандидат делал нагрузочное и тем более на гатлинге, то это ваще мой любимый кандидат сразу 🤩 (пока таких не было 😭)

Фреймворки - про Spring и вокруг него, про хибу и jdbc.
Если в резюме есть реактивщина, то спросим и не дай бог кандидат неверно ответит 🤣

Обязательно показываем код и тут начинается самое интересное, топ кандидаты по предыдущим вопросам могут полностью завалить код и наоборот)

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

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

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

Расскажите, как проводите собесы) Что спрашиваете?
Алгоритмы спрашиваете? 🤪

Что вас спрашивали на лучшем собесе в вашей жизни? 🤩

ну и по мотивам поста 🤪

Сегодня весь день ковырялась с Hibernate 😅
На прошлом месте работы у меня его не было, пользовалась Jdbc, а потом и R2dbc и бед не знала))
А сейчас у нас везде Hibernate, приходится изучать, а он мне не нравится)
Я всегда думала хиба, да и JPA в целом, это как из пушки по воробьям, слишком громоздкая штука и эти кэши сомнительные, какие-то контексты. Персистится чёт там всё само, непредсказуемо, неочевидно.

Многие хвалят Hibernate за сокращение количества кода. Блин, ребята, спрингдатовский CrudRepository + Jdbc то же самое)))) (ну почти 😅)
Тем более если у вас, как у меня, в куче микросервисов 1-3 таблицы без связей.

На собесе нам кто-то говорил что если мало таблиц, нет связей, простая схема БД — надо взять Hibernate, объясните плиз зачем???)) Мы тогда так и не поняли.

Кучу аннотаций сегодня пришлось изучать и я нашла классную статью, которая очень понятно объясняет про orphanRemoval, балдёжь)

Короче я решила изучить кэширование в Hibernate, чтобы не только хейтить его, но ещё и умничать про кэши 😂
Расскажу вам скоро про них 😌

Всем привет!
Мы тут с коллегами решили начать использовать layered jar. Может и вам пригодится)
Эта штука появилась в Spring Boot 2.3.0 (май 2020), то есть достаточно давно, но я лично узнала о ней только сейчас 😂
Суть в том, что создаётся jar, содержимое которого разделено на слои, в зависимости от того, как часто это содержимое будет меняться.
Это аналогия докер образов, собственно для большей эффективности в докере и предназначено) Ускоряет создание образа и всё такое))

Можно оставить слоистость по-умолчанию (snapshot и не snapshot зависимости + приложение), а можно настроить более сложные слои. Мы у себя дополнительно создали слой с нашими внутренними зависимостями, которые меняются часто. Ну вы это увидите в любых туториалах в инете 🤣
Ускорения запуска приложения замечено не было)))))

После сборки мы теперь извлекаем слои:
java -Djarmode=layertools -jar app.jar extract

И в Dockerfile у нас они все копируются:
COPY ./build/layers/dependencies/ /app
COPY ./build/layers/spring-boot-loader/ /app
COPY ./build/layers/snapshot-dependencies/ /app
COPY ./build/layers/application/ /app
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

Всем привет!
Вот что я вам сегодня скажу (то что вы и так знаете) — нужно ставить свои сервисы на мониторинг как можно раньше, это очень важно! 🤓

Предыстория (любимый начальник, прошу не читай 😅)
Я на той неделе выкатила свою доработку в прод и только вчера узнала, что у определенной части пользователей при определённых кривых данных перестала работать одна фича.
Давайте опустим вопросы про тестирование, речь не об этом)

Как бы я могла узнать об этом раньше? Если бы мониторила эту фичу)

Очевидно, что мониторинг, это не новость, но почему-то часто на него забивают. Например, когда я пришла на текущий проект, тут было очень мало чего на мониторинге, хотя проект делали не джуны.
Даже на собеседованиях иногда разработчики не знают про графану, либо «у нас маленькая нагрузка», «просто посмотрим логи», «у нас MVP», «руки не дошли» 😒
Блин, это как с тестами, может лучше сначала мониторинг сделать, а потом уже писать функционал 🤣

В общем - настраивайте мониторинг с алертами в тележку и спите спокойно 😌

А еще надо приделывать к логам ошибок какие то мотивационные цитатки, или гороскоп, или анегдот...о, предсказание как из печенек
"Расслабся и пусть весь мир подождет"
"Это не самая лучшая работа в мире"
....

ой не могу 🤣🤣🤣

Кстати про гороскоп
Не благодарите 🤪

https://deployhoroscope.ru

Builder: паттерн или антипаттерн?

На днях поспорила с коллегой за паттерн Builder 🤓 Он его часто использует, а я стараюсь избегать, дальше расскажу почему)

Когда его используют?
• нужен иммутабельный объект, который содержит множество необязательных параметров ( = множество конструкторов)
• объект содержит поля с одинаковым типом и есть вероятность перепутать эти параметры при инициализации
• иногда его пихают везде))))

Почему я стараюсь его избегать:
• даже если мы ожидаем, что все параметры объекта обязательные, ничего не мешает вызвать build() раньше чем надо и объект получается недоинициализированным
• мы смещаем проверку валидности объекта на рантайм, вместо compile time (как например в случае со статическим методом создания объекта)
• необходимы дополнительные тесты, что объект правильно создаётся в рантайме и тот ли объект вообще создаётся
• куча бойлерплейта, если не хочется использовать lombok (котлин-ребята поймут)

А ваще я люблю писать на котлине, я использую дата классы и конструкторы с именованными аргументами, и никакие билдеры мне не нужны)))
В джаве использую статический метод создания объекта и делаю конструктор приватным

Пользуетесь этим паттерном? Если да, то как проверяете, что объект валиден после создания?

Я уже писала, что ступила на скользкую дорожку Hibernate и недавно столкнулась с прикольной ошибкой, которую не ожидала вообще) (по незнанию)

У меня bidirectional one-to-many relationship между двумя объектами и они ссылаются друг на друга с соответствующими анноташками.

Пример в основной сущности (код не настоящий если что):
@OneToMany(mappedBy = "user", cascade = [CascadeType.ALL], fetch = FetchType.EAGER)
lateinit var emails: Set<Email>

В дочерней
@ManyToOne
lateinit var user: User

И тут мне понадобилось сложить эту сущность в json и записать в БД)))
Закономерно я получила циклическую зависимость и StackOwerflowException при сериализации в JSON.
Подробнее про ошибку и способы устранения можно почитать тут

Я у себя добавила @JsonIgnore в дочерней сущности и теперь довольная))
@ManyToOne
@JsonIgnore
lateinit var user: User