влетаю в новый день конфы, ух как послушаю про 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. думойте сами, решайте сами 😅 я нашла у нас одно место, где можно попробовать применить

Всем привет! Недавно я слушала подкаст подлодки про продуктивность разработчика (#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- рекрутёров)

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

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

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

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

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