Случайно наткнулся на открытый код с rails, dry-monads и сервис объектами. Решил написать детальный разбор того, как сам бы написал подобную логику и рассказать на что обращаю внимание в своем коде.

Хотелось бы сделать это в виде стрима или видео, но это довольно затратно. Поэтому если вам такой формат понравился - дайте знать.

https://gist.github.com/davydovanton/a8f3cab112e43cfafbcbbfae2472f6c7

Пятничное чтиво

Пару недель начал делать Inventarium, с помощью которого хочу решить проблему человеческого observability в сервисных/микросервисных системах. Если каждый раз приходится спрашивать где ссылка на роллбар или логи, нет визуализации связей между сервисами, нет процессов для выкатки нового сервиса в продакшен, информация в конфлюенсе устаревает и хочется видеть систему целиком, то inventarium поможет решить эти проблемы. MVP уже готов и хочется найти людей для закрытого бета теста. Если интересно - напишите пожалуйста в личку.

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

В среду будет стрим, будем разбираться с hanami 2.0, попробуем запустить тестовый проект, попутно расскажу как теперь будет выглядеть и работать фреймворк.  Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.

—————————————

Programming stuff: DI Паттерны. Service Locator

Если вы были на rubyrussia 2019 и смотрели мой доклад или доклад Никиты (об алгебраических эффектах), то возможно вспомните, что упоминался Service Locator в качестве антипаттерна и почему dry имплементация DI антипаттерн. По ссылке выше автор описывает Service Locator и дает примеры на C#, описывающие как паттерн работает. Также, поднимается тема Service Locator как антипаттерна. Если в двух словах:

# bad
def action(params)
  service = Container['http://amp.gs/3HFd']
  http://amp.gs/3HFO(params)
end

# also bad
def action(container = Container)
  service = container['http://amp.gs/3HFd']
  http://amp.gs/3HFO(params)
end

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

—————————————

Опыт внедрения Service Mesh на Nomad и Consul

Ребята из учи ру делятся опытом внедрения service mesh в системе. Описывается причины появления service mesh, а также конечная реализация. Из интересного - хочется выделить бонусы, которые появились (визуализация трафика и рейсинг).

—————————————

API versioning and evolution with proxies

История эволюции проекта с помощью использования API версий в разных сервисах. Основная идея которую взял из статьи - разные  API версии не обязательно должны быть в одном сервисе. Так же, заинтересовало описание сервиса Sentinel, напомнило реализацию Backends For Frontends паттерна. Так же, затрагивается идея dynamic configuration updates to APIs.

В своей практике я уже выносил логику из монолита используя разные API версии, запись доклада, где делюсь опытом.

——— одной строкой ———

- Ruby core: Thread scheduler for lightweight concurrency

амплифер не справился с кусками кода, там должно быть вот так:

# bad
def action(params)
  service = Container['services.show']
  service.call(params)
end

# also bad
def action(container = Container)
  service = container['services.show']
  service.call(params)
end

Напомню, что завтра стрим, будем разбираться с ханами 2.0. Начало в 20:00 по москве.

Так же, перевел на английский текст с рефакторингом. Структурировал информацию + добавил выводы и советы что делать
https://www.davydovanton.com/2020/05/19/five-common-issues-with-services-and-dry-monads/

Начинаем стрим через 5 минут

https://www.twitch.tv/davydovanton

Пятничное чтиво

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

В среду разбирали темплейт hanami 2.0 приложения, запись стрима уже доступна на ютубе. Мне так же важно собрать фидбэк по темплейту, поэтому буду рад любому мнению и эмоциям, касаемо темплейта из стримов. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.

Сегодня выпуск посвящен DDD, поэтому ссылки будут только о связанных темах. А также, на примере, покажу почему DDD сложная для понимания тема. Так же, ссылки будут разбиты на 2 части ибо текст не поместился в лимит.

—————————————

Domain Events in DDD

Лонгрид на тему событий в DDD. Статья - сборник цитат и рассуждением о назначении событий, Eventual Consistency, открытости/закрытости событий в системах, кто события может публиковать. Также затрагиваются темы отмены событий, CQRS и очередности. Понравилось, что статья строится на первоисточниках, а не только рассуждениях автора. Т.е. данный лонгрид стоит воспринимать как сборник оригинальных мыслей и последующее развитие этих идей. Если хочется разобраться с событиями в системах (большинство идей можно использовать отдельно от DDD) - однозначный мастрид.

—————————————

Understanding Domain Entities with Examples - DDD w/ TypeScript
How to Handle Updates on Aggregates - Domain-Driven Design w/ TypeScript

Первая статья - попытка разобраться в термине entity из DDD. Как оказалось -  проблема в том, что value object и entity имеют  пересекающееся значение, которое может путаться в имплементациях. В статье найдете определение энтити, а на примере класса Job, автор покажет как создавать и работать с энтити и в чем отличие от value object. Во второй статье уделяется внимание агрегатам и рассказывается о связях, апдейтах, работу с моделями и событиями из агрегата. Мне не нравятся некоторые примеры реализации (например UserService из статьи об агрегатах, там еще походу опечатка ибо код не работает как должен), но статьи будут полезны для общего развития, а также, что бы понять что проблема DDD в том, что нет конкретики и стандартизации в терминах. Так же хотелось бы видеть отдельную статью по сервисам, потому что хочется видеть какую логику автор хочет держать в энтити, а какую в сервисе.

—————————————

What Are Aggregates In Domain-Driven Design?
How Do I Persist Aggregates?
Consistency Boundary
Optimistic Concurrency

В качестве примера, как рассказать об агрегатах понятнее и как авторы используя одни и те же определения пишут разные вещи привожу пример - серия статей от James Hickey об aggregates. Статьи расставлены в порядке прочтения (от первой к последней). Важно понимать, что мнение каждого из авторов субъективно и стоит проверять описанные идеи лично (в пет или учебных проектах, в продакшене проверять не стоит без полной уверенности, что это там надо).

Автор начинает разбор темы с системы состоящей из 3 моделей (Team -> Member, Team -> Project), где дает определение агрегатам и объясняет в чем абстракция может помочь. Дальше происходит разбор системы с агрегатами, описывается, почему дупликации данных между агрегатами не проблема и как можно сохранять агрегаты  (CQRS, relation model, event sourced). О ES дается подробное объяснение принципа работы сохранения агрегатов. Дальше описывается самая сложная часть - как найти "хороший" размер и границы для каждого из агрегатов. А в конце объясняется Optimistic Concurrency и зачем это надо.

——— одной строкой ———

- @Freika взял и перевел майндмап с вопросами написанный много лет назад в отдельный сайт;
- Я стримил вариант реализации game of life, но Виктор шокировал вариантом Game of Life in one Ruby statement… inspired by APL;

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

Поэтому буду рад, если заполните форму из 4 вопросов, это поможет улучшить качество контента

https://forms.gle/1EXm3mBa8CKvnRwf6

Привет!

Понравился формат ревью кода (https://gist.github.com/davydovanton/a8f3cab112e43cfafbcbbfae2472f6c7) и поэтому хочется продолжить. А так же помочь людям разобраться как сделать код лучше и показать как можно решить похожую проблему с другой стороны. К сожалению поиск проектов или примеров кода затратен по времени и силам. Поэтому сделал отдельное место для коммуникации.

Если хотите получить текстовый разбор кода (пет проекта, тестового задания, чего угодно) или получить ответ на интересующий вопрос связанный с паттерном/технологией/подходом - заполните форму по ссылке. К сожалению, сделать разбор каждого примера физически не возможно, поэтому может получиться так, что разбор не появится. В этом случае вы получите подробное объяснение почему так вышло.

Ссылка на гугл форму - https://forms.gle/TaVRA7Zn8u5xe7Sy9

Пятничное чтиво

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

—————————————

Vertical Slice Architecture
Out with the Onion, in with Vertical Slices

На последнем стриме показывал концепцию слайсов в hanami 2.0. Идея в том, что горизонтальные части приложения (ui, application, domain, db) разбить не только горизонтально, но и вертикально. Это значит, что в самом приложении появляются “слайсы”, в которых находятся логика изолированно друг от друга. В комментариях к статье дается группа сервисов как пример для понимания. Кажется, что аналогия rails engines подходит для быстрого объяснения подхода, тем более об этом уже начинают говорить (за подробностями - к автору доклада, @greygreengreen).

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

Если хотите понять подготовиться к hanami 2.0 или же хотите взять идей для rails engines - мастхев.

—————————————

[Clean Architecture: The Bad Parts](http://amp.gs/Hhg4)

На прошлой неделе в рассылке присутствовали статьи автора касаемые aggregates из DDD. Сегодня статья о проблемах “clean architecture”. В начале описывается что это такое (спойлер: порты и адаптеры). Потом описываются принципы, которые должны в такой системе соблюдаться. Но к сожалению, реальность иначе. Поэтому автор описывает проблемы, с которыми встретился лично (Context Switching). Так же ставится риторический вопрос о действительной необходимости изменения базы данных в приложениях. В качестве “серебрянкой пули” предлагается использование слайсов, о которых рассказывала первая статья.

Кажется, что тема слайсов будет развиваться дальше по трем причинам (время для #2pe\http://amp.gs/Hhg4)

На прошлой неделе в рассылке присутствовали статьи автора касаемые aggregates из DDD. Сегодня статья о проблемах “clean architecture”. В начале описывается что это такое (спойлер: порты и адаптеры). Потом описываются принципы, которые должны в такой системе соблюдаться. Но к сожалению, реальность иначе. Поэтому автор описывает проблемы, с которыми встретился лично (Context Switching). Так же ставится риторический вопрос о действительной необходимости изменения базы данных в приложениях. В качестве “серебрянкой пули” предлагается использование слайсов, о которых рассказывала первая статья.

Кажется, что тема слайсов будет развиваться дальше по трем причинам (время для #2pe\analytics):

1. кажется, что микросервисы дошли до Trough of Disillusionment и  разговоров о возврате к монолитам становится больше в моем пузыре;
2. ограничивать части монолита нужно, DDD добавляет абстракций, использовать сервисы, декораторы и другие объекты в больших проектах сложно (куча хлама в одном месте). По идее, слайсы как раз и могут решить проблему поддерживаемости, при этом не добавляя проблем распределенных систем;
3. об этом начинают говорить не только в .net но и в js, ruby и других экосистемах.

При этом, я думаю, что подход вряд-ли окажется популярным как микросервисы, но он доступен для любой
экосистемы, даже для rails.

—————————————

Practice of GraphQL in microservice architecture

Статья для тех, у кого больше одного сервиса в системе и есть graphql. Автор описывает проблемы с которыми столкнетесь и дает направление куда копать дальше. В самом тексте затронуто так много тем, что не понятно как написать нормальное превью к статье. Начинается текст с определения graphql, описывает relay стандарт (включая node интерфейс), описывает N+1 проблему в GQL и дает определение микросервисной архитектуре. После автор детально описывает как можно спроектировать GQL schema для микросервисов, покрывая такие проблемы как stitching схем (по собственному опыту знаю какая это боль, а автор готового решения не даст). С картинками описывается как сделать авторизацию и certification. А после, последняя треть статьи затрагивает такие темы как: эволюция схем, роутинг на уровне системы, Centralized Schema and RPC, Decentralized Schema, Service Grid and RPC.

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

——— одной строкой ———

- How big is Ruby in Japan? What is the Japanese community around Ruby up to these days?
- Kir Shatrov написал твиттер тред о дружбе о Shopify и Sorbet (ruby type checker)

там должен был быть #2pe_analytics хештег, но амплифер его порезал зачем-то 😔

Так же побилась ссылка на Вову (автор доклада про энджины) - @grey_green

На этой неделе вышел новый выпуск журнала increment. В этом месяце тема связанна с форнтендом. Я уже делал разбор самых интересных статей прошлого выпуска, поэтому интересно, стоит делать такой же разбор свежего выпуска?

Завтра стрим, начало в 20:00 по москве.

С raft алгоритмом погорячился, прикинул сколько это может занять времени и сколько готовиться надо - решил, что это слишком затратно для меня.

Поэтому завтра будем делать имплементацию стейт машины с нуля, но по готовым требованиям + расскажу зачем нужна еще одна стейт машина. Покажу как использую подход с контейнерами для библиотек и напишем собственную реализацию контейнеров. А так же расскажу о RDD и почему люблю этот подход и, если успеем, пройдем цикл создания гемов с нуля до первого релиза на rubygems.

Начинаем стрим

https://www.twitch.tv/davydovanton

донаты - https://www.donationalerts.com/r/davydovanton

Наконец-то сделал нормальный сайт, там найдете ссылки и необходимую информацию связанную с каналом.
https://pepegramming.site

А так же, написал новый пост с ретроспективой опыта работы с ecommerce.
https://pepegramming.site/retrospection-ecommerce/

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

Пятничное чтиво

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

—————————————

Listen to Yourself: A Design Pattern for Event-Driven Microservices
В статье рассматривается три способа коммуникации в системах. Для уменьшения абстракций, автор указывает изначальный пример: order service, который сохраняет данные в базе данных и необходимость надо сохранять данные в легаси системе. Способы которые рассматривает автор: прямой вызов, мессадж брокер, метод, при котором сервис сначала шлет сообщение в брокер, а потом сохраняет данные в консьюмере, как и остальные сервисы. Последний способ напомнил CQRS, где брокер - модель на запись, а noSQL - модель на чтение. Также, в статье подробно расписываются плюсы и минусы последнего паттерна. А также указываются похожие подходы.

—————————————

A chatbot expedition
На прошлой неделе спрашивал о свежем выпуске Increment, посвященный фронтенду. После беглого прочтения выпуска, понял, что на отдельный выпуск статей не наберется, но статьей о чат ботах поделиться хочется. Предполагается, что скоро начнется новый бум чат ботов, а благодаря опыту прошлых лет можно выделить четыре направления в разработке чат ботов:
- Dialogue logic
- AI modules
- Relationship management
- Kernel

В статье поверхностно проливается свет на каждый из компонентов. Никаких технических откровений не найдете. Понравилась идея relationship management, это когда бот заранее предлагает вариант пользователю (например, как бариста, который заранее предлагает кофе, который человек обычно берет).

—————————————

Against Railway-Oriented Programming
Канал является пропагандой railway подхода. Как и у любого другого подхода, railway ограничен и не решает каждую проблему в проекте, так как есть места, где подход только навредит. По ссылке найдете статью человека, который первый заговорил об этом подходе публично и написал Domain Modeling Made Functional книгу. В статье приводятся 8 причин, почему использования ROP плохая идея. Хочу выделить эти три пункта, так как часто вижу (и сам делаю) подобные примеры:
- Don’t use Result to reinvent exceptions
- Don’t use Result if you need to fail fast
- Don’t use Result if no one will see it

Появился вопрос по поводу первого пункта (Don’t use Result if you need diagnostics) так как в dry-monads сделали tracing failures. Но сам вопрос больше о уместности реализации tracing информации в монаде.

В конце статьи автор указывает 3 места для использования Result монады (ошибки домена, ошибки логики и вычислений (не знаю как перевести лучше), ошибки инфраструктуры).

——— одной строкой ———

- What computer and software is used by the Falcon 9?;
- PyTrace — Time Travel Debugger для Python - хочу верить, что в руби тоже сделают что-то подобное;

Привет!

18 июня будет онлайн митап от ребят из RubyRussia (ex rails club). 4 спикера (включая меня) будут говорить об оптимизации, наследовании, постгресе и CQRS.

https://cutt.ly/hyBysYA

Пятничное чтиво

На следующей неделе выступаю на митапе, расскажу о CQRS и почему паттерн на самом деле популярен, а разработчики не знают этого. А в среду будет стрим, доделаем библиотеку со стейт машиной и добавим ее в rubyjobs. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.

—————————————

How Netflix works: the (hugely simplified) complex stuff that happens every time you hit Play
Why You Can’t Talk About Microservices Without Mentioning Netflix
A Design Analysis of Cloud-based Microservices Architecture at Netflix

Сборник статей об архитектуре нетфликса.

В первой подробно описывается как и где компания разворачивает 700+ сервисов, а так же объясняет что подразумевает под сервисной архитектурой. Также, раскрываются интересные моменты из внутренней кухни, например - каждое устройство проигрывает специфичный формат видео, который сделан специально для этого устройства.

Вторая статья описывает причины, по которым нетфликс перешел на микросервисную архитектуру.

А третья статья больше рассказывает о самой архитектуре сервиса, объясняет playback и backend архитектуры. Так же, рассматривается каждый компонент отдельно, т.е. найдете информацию по работе клиента, API gateway, application API (это прослойка между gateway и сервисами), самих сервисов и баз данных, которые используются в компании. Также указываются трейдоффы такой архитектуры и цели (High Availability, Low Latency, scalability)

—————————————

Microservice Architecture at Medium

Статья описывает как медиум перешел на микросервисную архитектуру. Из причин - ботлнек в монолите в виде медленной разработки, перфоманса и скейла приложения. Также, указываются принципы, которым следовали инженеры медиума (7 штук). На что советую обратить внимание:

- Decouple “building a service” and “running services”;
- Not every new service needs to be built from scratch;
- Avoid “microservice syndromes” from day one;

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

—————————————

Evolution of SoundCloud’s Architecture

Статья, без деталей, описывает эволюцию SoundCloud. Из не узнаете, как проект с apache + rails + mysql развивался и превратился в систему с кешированием, search engine, брокером на RabbitMQ и большим количеством асинхронных фичей. Авторы описывают каждый переход и объясняют почему появился каждый новый переход. Нравится, что статья не перегружена деталями и расписывает каждый переход поверхностно, но при этом, объясняет почему и зачем это надо было.

——— одной строкой ———

- Коллекция предложений переименовать термины в репозиториях;