У systems.education тут стартовал новый воркшоп по очередям и кафкам: https://systems.education/kafka-workshop.

Будет интересно тем, кто хочет все потрогать руками, я вот записалась)

Что можно почитать и послушать, чтобы познакомиться с обменом сообщениями/брокерами сообщений/Kafka/Event Driven Architecture (EDA):

1. Базовая книга “Шаблоны интеграций корпоративных приложений” Г. Хоп и Б. Вульф - в плане практических примеров может быть где-то устарела, но основные паттерны и понятия интеграции через обмен сообщениями там есть и довольно хорошо описаны.
2. “Микросервисы. Паттерны разработки и рефакторинга” К. Ричардсон - хорошая книга, чтобы познакомиться со всеми современными способами интеграций. В главах 5 и 6 дается базовое разъяснение EDA, Event Streaming и Event Sourcing и зачем они вообще нужны.
3. Выпуск подскаста Podlodka про менеджеры очередей
4. Выпуск подскаста Podlodka про EDA (на самом деле больше про Kafka)
5. Отдельная статья про Event Streaming and Event Sourcing
6. И про outbox pattern - хороший способ реализации отправки сообщений из БД

Написала, почему так важно при разработке смотреть на реальные данные.

В одной из рассылок от ByteByteGo пришла прекрасная инфографика с 12 способами сделать API безопаснее. Буду по мере сил публиковать более подробное описание каждого из пунктов.

Итак, первый способ - это HTTPS

HTTPS  -  это HTTP с обеспечением безопасности (HTTP over TLS/SSL).

В рамках взаимодействия по HTTPS происходит шифрование данных и проверка сертификатов. 

При установке соединения сервер отправляет клиенту свой сертификат и открытый ключ (public key). На основе открытого ключа генерируются сессионные ключи (session key), которые живут только одну сессию.

Далее с помощью session key клиент сверяет данные из сертификата с данными сервера, от которого приходят запросы. Если данные (например, имя) сервера не совпадают с указанными в сертификате - клиент может прервать соединение, либо сообщить о проблеме пользователю.

Аналогичным образом сервер может проверять сертификат клиента. Так HTTPS-соединение помогает избежать перехвата данных. 

Но даже если данные будут перехвачены - их нельзя будет просто так прочитать. Так как HTTPS обеспечивает шифрование данных. Расшифровать сообщения можно только с помощью закрытого ключа (private key).

Часто, при взаимодействиях внутри контура компании, HTTPS-ресурс используют именно при аутентификации/получении токена. А дальнейшее взаимодействие идет по обычному HTTP.
То есть создается отдельный API для авторизации - туда по HTTPS передается логин и пароль. В ответ сервис авторизации присылает токены.
Далее клиент с этими токенами идет в API сервисов, содержащих нужные ему данные. Особенно это удобно при микросервисной архитектуре - клиенту не нужно проходить аутентификацию в каждом из сотни микросервисов.

Если взаимодействие между сервисами происходит под VPN, то часто в HTTPS нет необходимости.
Но все же так шанс перехватить токен становится выше, поэтому важно, чтобы время жизни токена было небольшое.

Источники:
- https://www.cloudflare.com/learning/ssl/what-is-a-session-key/
- https://ru.wikipedia.org/wiki/HTTPS
- https://en.wikipedia.org/wiki/HTTPS
- Вот тут можно почитать, зачем сайтам использовать HTTPS и как это влияет на SEO

А вот и сама инфографика

Пока я планирую следующие посты и вообще чаще писать в этот канал, поделюсь еще одной хорошей инфографикой от ByteByteGo.

UPD: @and_burakov правильно заметил, что протоколами это все называть не совсем корректно, API technologies - более точное словосочетание.

Написала про интересный интеграционный кейс: проблему зависимых сообщений. А также про такие способы ее решения, как Dead Letter и Inbox.

Cтатья на habr и на английском на medium (c VPN).

Если вы встречались с подобной проблемой - напишите в комментариях, как ее решили? Как в итоге проявило себя решение в процессе эксплуатации?

На моем проекте мы выбрали Inbox, причем сначала сохраняли туда только зависимые и проблемные сообщения. После начала эксплуатации пришли к выводу, что лучше все-таки сохранять в inbox все сообщения, чтобы использовать его возможности по полной.
Спустя какое-то время потребовалась оптимизация логики обработки. Но в итоге решением довольны - у нас есть гарантия обработки сообщения хотя бы 1 раз, сообщения не теряются и обрабатываются корректно.

За 5 лет, что я проектирую API, вывела для себя шесть базовых принципов, которых стараюсь придерживаться. Собрала эти принципы в чек-лист. (Версия на английском).

Открываю портал в дискуссию на тему “Надо ли читать “Проектирование требований к ПО” К. Вигерса и Дж. Битти в 2024 году?”

Напишу свое мнение по этому поводу.

Это фундаментальная книга с подробным описанием базовых паттернов проектирования ПО. Пять лет назад я была уверена, что эта книга должна быть обязательной для всех IT-специалистов, а не только для аналитиков. В ней описано, как подходить к разработке так, чтобы не переделывать или закрывать продукты сразу после релиза. Книга предлагает системный подход к проектированию и помогает оптимально выстроить процесс работы: сначала разобраться, что и зачем нужно сделать, и только потом приступать к работе. Об этом я даже писала статью.

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

Также сильно изменились требования к аналитикам. Сейчас от нас больше ожидают умение описать контракты API, структуры БД и интеграционные схемы. А разобрался ли аналитик, нужен этот функционал бизнесу или нет - беспокоит далеко не всех нанимающих менеджеров. Во время последних поисков работы в 2021 году про процесс разработки требований меня спросили где-то в 5 компаниях из 10.

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

При этом я считаю agile хорошим подходом, который помогает поставлять больше полезных и нужных фичей. Очень важно находиться в постоянном контакте с заказчиком и сверяться с реальностью. Но не всегда следует начинать кодить сразу после того, как заказчику пришла в голову какая-то идея. Иногда лучше остановиться, подумать, применить к задаче какие-то инструменты анализа.

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

А вы как считаете, нужна ли сегодня эта книга и описанные в ней приемы? И часто ли вы сталкиваетесь с неприятностями, которых можно было бы избежать, выдели команда больше времени на проработку требований?

Чем опасен PATCH?

На собеседованиях часто спрашивают, чем отличается PUT от PATCH.

Самый простой ответ - что PATCH предназначен для частичного изменения ресурса, в то время как PUT всегда меняет ресурс полностью.

Рассмотрим пример ресурса с пользователем:

{
"id": 1,
"name": "John Doe",
"email": "john@example.com",
"phone": "12345678"
}

Метод PATCH может позволять менять параметры ресурса по отдельности.

PATCH /users/1

{
"email": "newemail@example.com"
} 

PUT же требует отправки всех полей ресурса, даже если меняется только одно из них.

На этом уровне кажется, что PATCH - хороший способ оптимизировать размер запросов и увеличить гибкость API.

Но если копнуть немного глубже, то появляется идемпотентность. Операция считается идемпотентной, если её повторное выполнение не изменяет результат после первого применения.

PUT должен быть всегда идемпотентным. В то время как идемпотеность PATCH зависит от реализации. Эта вариативность тоже добавляет гибкости, но несет больше рисков и требует больше внимания команды к разработке и поддержке таких методов.

Также, даже если мы сделали PATCH идемпотентным, его применение может привести к нарушению целостности данных. Допустим, мы делаем вызов с удалением email:

PATCH /users/1

{
"email": null
} 

Примерно в это же время кто-то сделал другой вызов, с удалением номера телефона:

PATCH /users/1

{
"phone": null
} 

Однако, по бизнес-правилам у пользователя должен быть заполнен либо email, либо телефон.

Значит, надо это заранее продумать и добавить дополнительную проверку в момент транзакции в БД. В то время как в методе PUT мы бы могли ограничиться валидацией на поля запроса.

Более того, какой-то из клиентов получит в ответе ошибку, хотя с его точки зрения он делал все правильно и конфликта быть не должно. PUT же делает для клиента очевидным результат запроса в разрезе всего ресурса и минимизирует шанс получить противоречия в значениях параметров.

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

Как познакомиться с GraphQL:

1. Посмотреть вебинар.
2. Почитать официальную документацию(она короткая, но на английском).
3. Потренироваться на тестовых и открытых API:
▫️ Тестовый API выдуманной горнолыжной базы - https://snowtooth.moonhighway.com/,
▫️ SWAPI на GraphQL - https://graphql.org/swapi-graphql/,
▫️ API GitHub - https://docs.github.com/ru/graphql/overview/explorer,
▫️ Еще много открытых API: https://github.com/graphql-kit/graphql-apis (не все сейчас работают, но какие-то можно посмотреть).

Тестовые и открытые API взяты из книги “GraphQL” Алекс Бэнкс, Ева Порселло - ее можно почитать, если хочется углубить знания технологии.

Села обновлять своё резюме для международного рынка и выяснила, что первый в гугл-выдаче сайт для создания резюме Resume.io — это скам. Как пишут на Reddit, он предлагает за 2 доллара один(!) раз скачать резюме в pdf, а после еще списывает 20$ якобы за подписку. В общем, будьте осторожны.

В целом выяснилось, что генерировать резюме онлайн - не лучшая идея, так как такие документы не проходят ATS. Эти системы плохо считывают информацию из сложных и красивых файлов. Автоматические скрининги лучше всего проходят простые классические резюме.

Такие шаблоны можно найти, например, вот тут:

- Microsoft CV templates
- Google Docs Templates
- https://resumeworded.com/resume-templates

Еще в ЕС есть стандарт резюме, который называется Europass. Его можно бесплатно создать на официальном сайте https://europass.europa.eu/en.

Только начала разбираться в этой теме и много еще не понятно. Например, как толково описать 9 лет опыта в 4х компаниях в одностраничном формате. Или как не умереть, редактируя свое резюме под каждую компанию и ее ATS. Если у кого-то есть хорошие советы/ссылки/инструменты по этой теме - делитесь в комментариях🤗.

Мне сложно дается грамотное ведение LinkedIn, поэтому решила поучаствовать в прожарке профилей в прямом эфире AgileFluent. Мой и еще 10 профилей разберет эксперт по международному найму🫣.

Страшно, конечно, но обещают много полезного. Расскажут, как вести эту хитрую соцсеть так, чтобы рекрутеры всех стран хотели нас схантить.

Приходите посмотреть на мой позор 17 декабря в 19:00 Мск в канале ребят. Все подробности и канал тут.

UPD: Запись эфира https://youtu.be/ci_YU9hpCmI

О КАНАЛЕ И АВТОРЕ

Привет!

Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.

Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю рекламу, но иногда могу анонсировать мероприятия коллег.

Я пишу о том, что мне кажется интересным. И последние несколько лет меня увлекают вопросы интеграций систем. Но не исключено, что в какой-то момент тут станет больше контента про бизнес-анализ, менеджмент или программирование🙈.

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

Очень благодарна вам за то, что читаете этот канал, оставляете реакции и комментарии - это очень важно для меня❤️.

Предлагаю в комментариях нам познакомиться: напишите о себе, почему вы читаете этот блог, о каких темах вам было бы интересно узнать в следующих постах? Или что-то, что хочется тут написать. Буду рада знакомству и общению🤗.

LinkedIn
Хабр
Medium (eng)
Донаты: ЮMoney | PayPal

Тем временем, прожарка моего LinkedIn уже завтра😳