Пятничное чтиво
Запись стрима, где начал делать стейт машину уже на ютубе. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
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 - хочу верить, что в руби тоже сделают что-то подобное;
Запись стрима, где начал делать стейт машину уже на ютубе. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
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 - хочу верить, что в руби тоже сделают что-то подобное;