Всем привет! Недавно я слушала подкаст подлодки про продуктивность разработчика (#291), и так впечатлилась, что решила кое-что из рекомендаций применить.

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

Второе и главное, я решила учиться слепой печати)
Кто умеет, прошу, не ржите надо мной, ДА, я много лет работала смотря на клавиатуру 😅
И сейчас спустя пару недель после начала обучения я уже уверенно печатала в слепую, правда пока только на русском, для кода приходится подсматривать)
Мозг кстати очень быстро понял, что не смотреть на клавиатуру гораздо эффективнее и теперь, когда я опускаю глаза, мне некомфортно, интересный эффект)

Делюсь ресурсами, которые помогли мне быстро освоить слепую печать:

Гайд от Кирилла Мокевнина, гостя на этом подкасте

Подборка сервисов для практики

С помощью каких сервисов научилась я:
https://www.keybr.com/ru/index
https://klava.org/delta/#rus_basic

В завершении темы опишу выводы из подкаста и свои, почему слепая печать это важно, а в совокупности с хоткеями это чистый кайф)

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

Всем привет!
Покажу классную (мою любимую) статью про зрелость REST API: https://blog.restcase.com/4-maturity-levels-of-rest-api-design
Если вы такой же человек как я, который никогда не открывает полезные ссылки, которые присылают коллеги 🤣 то вот саммари:

Существует 4 уровня зрелости rest API

Нулевой уровень называется The Swamp of POX (Plain Old XML).
На этом уровне есть один URI, используется метод POST, и отправляется XML, в котором указан метод и параметры запроса.

Есть best practices, которые следует соблюдать уже на этом уровне:
• для лучшей читаемости использовать spinal-case
• использовать lowercase
• не использовать underscore (_)
• не включать в URI расширения файлов
• не использовать глаголы в URI

RPC это протокол как раз нулевого уровня

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

Best practices этого уровня:
• не включаем в URI завершающую косую черту:
http://example.com/hellew/ ❌
http://example.com/hellew ✅
• слэш используем для иерархичности
• используем в приложении либо единственное число, либо множественное везде

Второй уровень это методы, эквивалент CRUD операций в ресте
То есть мы можем использовать один и тот же URI, но разные методы, и будут совершаться разные действия над ресурсом
• GET
• POST
• HEAD
• PUT
• PATCH
• DELETE
• OPTIONS

Уровень 2.1 - HTTP Headers
Хидеры используются для получения метаданных по ресурсу, авторизации, хешей. Также могут содержать инфу о респонзе
Есть 4 вида хидеров:
1) General Header - хидеры, которые применяются для реквеста и респонза
2) Client Request Header - применяется только для реквеста
3) Server Response Header - применяются только для респонза
4) Entity Header - хидеры для боди или если нет боди, то инфа о ресурсе, указанном в запросе

Уровень 2.2 - Query Parameters
Обычно используются для:
• пагинации
• фильтрации
• сортировки
• поиска

Уровень 2.3 Status Code
Используется для того, чтобы узнать с каким результатом выполнился запрос
Самые распространённые статус коды это 200, 201, 204, 400, 404, 500 (ну вы знаете 😌)

Третий уровень. Hypermedia Controls
Делится на две категории:

1) Content Negotiation (согласование содержания) - это когда контент может отдаваться в некотором виде или в разных видах (json, xml) и клиент говорит в каком виде он хочет контент получать, а сервер решает, в каком виде он может его отдать.

Accept Negotiation - с помощью хидера Accept клиент говорит в каком виде он хочет получить ответ от сервера. Если сервер не может вернуть ответ в требуемом виде, он должен вернуть 406 Not Acceptable.
При возврате ответа сервер использует Content-Type header, чтобы рассказать, что он вернул.

Content-Type Negotiation - это когда клиент отправляет боди в каком-то виде и сервер с помощью хидера может понять, что это за боди и десериализовать его. Если сервер не может десериализовать пришедшее от клиента боди, он отправляет 415 Unsupported Media Type.
А если боди не может быть десериализовано, например, если написано что тип контента json, но на самом деле там не json, то сервер должен вернуть 400 Bad Request.

2) HATEOAS (Hypermedia As Transfer Engine Of Application State) (который никто не использует 🤣)
Суть заключается в том, что когда запрашиваешь ресурс, тебе возвращается не только его содержимое, но и линки на то, какие действия с этим ресурсом можно делать.

Уровень 3.1. Версионирование
Используется для разного представления ресурсов. Очень полезно для обратной совместимости сервисов при добавлении нового функционала или изменения существующего. Обычно все используют для версионирования два подхода:

1) Headers
• Custom Header
Например X-API-VERSION от клиента поможет сервису направить запрос на правильный эндпоинт
• Accept Header
Accept: application/vnd.example.v2+json

2) URL
POST /v2/client

Признавайтесь, дочитали?)

В офисе конечно хорошо, но дома монитор получше и джунгли 😌🌱🌿

Увлеченный отец

Однажды мы с вами поговорим про чистую архитектуру)

Всем привет! На днях проводили собес и с кандидатом разошлись во мнении по поводу паттерна Circuit Breaker (CB), поэтому я решила написать шпаргалку) 
Мы на собеседованиях спрашиваем его почти всегда 😏

Это один из паттернов микросервисной архитектуры входящий в категорию Resilience Patterns, т.е. помогающий предотвратить каскадные сбои и сохранить часть функциональности.

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

Когда используется паттерн Circuit Breaker, проксируются все запросы от одного сервиса к другому и устанавливается некий порог ошибок, при достижении которого прокси переходит в состояние Open. В этом режиме прокси сразу возвращает ошибку, не делая запрос на второй сервис.
Затем, по истечении заданного времени CB переходит в состояние Half-Open. В этом состоянии CB-прокси начинает потихоньку пропускать запросы на второй сервис, чтобы выяснить, была ли исправлена ошибка. Если сервис отвечает успешно, то CB переходит в состояние Closed, при котором восстанавливается взаимодействие между двумя сервисами.

Таким образом если сервис не отвечает, мы не генерим ненужный трафик, а после восстановления работы сервиса мы даём ему время на инициализацию стейтов и т.д. с помощью Half-Open состояния.

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

Мы у себя реализовали это с помощью библиотеки Resilience4j, классная 😍

Всем привет! Пока, так скозать, горячо (было в коментах) 😂 решила вкратце рассказать про второй известный паттерн из категории resiliency - Rate Limiter.
Кто уже знает этот паттерн - вы лучшие 🤩 кто не знает, щас узнаете)))

Цель паттерна ограничивать количество запросов в единицу времени.
Реализация состоит в том, что задаются определённые значения, сколько запросов и за какое время хочет/может обрабатывать сервис, все запросы сверх этих значений отбрасываются. То есть мы контролируем throughput. Клиент при этом может повторить эти запросы позже, либо взять из кэша предыдущее значение, up to you.
Полезен, как один из инструментов предотвратить DDoS, снять нагрузку если сервис не вывозит и для предотвращения каскадных сбоев.

Мы у себя реализовывали этот паттерн немного нестандартно, когда хотели защитить внешнюю систему от своей пиковой нагрузки.
У нас тогда был большой RPS, а внешняя система могла обрабатывать гораздо меньше.
Пренебречь результатом мы могли, а положить чужой сервис не хотели.
Для cloud native парней (и девчонок) 😏 скажу, что мы реализовали этот паттерн и на nginx’е и в коде с помощью Resilience4j, на всякий случай)
Почему внешняя система не реализовала на своей стороне? Ну потому, это легаси 🤪

В заключение напишу, что реализовывала я этот паттерн около 3х лет назад, но только в сегодня лет я узнала, что есть разные алгоритмы для вычисления лимита 🤣 Можно почитать об этом на хабре, если интересно 😌

Расскажите, знаете этот паттерн? Приходилось ли реализовывать на практике?

Оказывается уже есть даты Joker 2023!
В чатике JUG писали, что офлайн будет проходить в Питере
Планируете ехать?
Я да 🤩

Только что проходила мок-интервью с HR для обучающего курса IT- рекрутёров)

Удивительно, но за свою карьеру я не проходила ни одного собеседования с рекрутёрами, сразу техническое собеседование и погнали работать 😅
Было интересно, новый опыт и волнительно, такой мини-стендап имени меня.

Спрашивали что для меня важно в компании, в процессах, кейсы управления людьми и принятия архитектурных решений. Я рассказывала какую хочу видеть атмосферу и какую ответственность на себя брать.

Были и сложные вопросы, например почему ушла с прошлого места и что будет если моя компания начнёт перебивать новый оффер. Я об этом никогда даже не думала 🤣

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

Короче мне понравилось 😍

Всем привет! Один подписчик подсказал идею написать про 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.
Если в резюме есть реактивщина, то спросим и не дай бог кандидат неверно ответит 🤣

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

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

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

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

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

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

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