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

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

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

Health Check Rack Middleware

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

Подробно о хелсчеках говориться в книге по паттернам микросервисов и на http://amp.gs/0jyP.

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

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

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

How Netflix microservices tackle dataset pub-sub

Лонгрид от нетфликса, который откладывал 4 месяца. Одна из проблем, которая встала в компании - как шарить данные между сервисами так, что бы это было на уровне стандарта компании. В итоге появился Gutenberg, внутренняя dataset pub/sub system, которая позволяет шарить версионированные датасеты между частями системы. Статья обзорная, в которой описывается модель данных и юзкейсы использования, архитектура продюсинга и консюминга, Data resiliency, масштабирование и что осталось сделать (первый пункт - Polyglot support, потому что сейчас работает только с джавой). Статья будет интересна в разрезе сервисной архитектуры и шаринга данных между сервисами, потому что идеи лежащие в Gutenberg можно использовать и в других языках.

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

Sharding & IDs at Instagram - Instagram Engineering

Наткнулся на статью, в которой автор рассуждает о проблемах uuid в качестве pk.

Why I’m not fan of uuid datatype – select * from depesz;

Проблемы которые описывает автор:

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

В качестве решения проблем предлагается изначальная статья от инженеров instagram, которые описывают как инстаграм пришел к собственному способу генерации Sharding IDs для публичных ресурсов. Из требований к ID было: сортировка по времени создания, размер 64 бита и простота. В итоге было рассмотрено 3 решения проблемы, но ни одно из решений не подошло. В статье найдете решение инженеров инстаграма, а также имплементацию, которую можно повторить на любом языке.

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

- 30 Tips for Successful Communication as a Remote Worker

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

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

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

Protobuffers Are Wrong

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

Основная проблема - система типов, но также затрагиваются:
- No Compositionality;
- Questionable Choices;
- отсутствия совместимости схем данных;

Так же приводятся примеры, как исправить некоторые из проблем дизайна protobuffers. Но действительно полезная информация - в комментариях, где люди делятся различными серелизаторами. Например, я выписал себе 3 новых серелизатора, с которыми хотел бы поиграть в свободное время

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

История vim

В 2014 году пытался объяснить на пальцах как появился вим и зачем редактор нужен. Из статьи узнаете о ed, почему в виме нет стрелок и как абстракции помогают посмотреть иначе на редактирование кода и текста.

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

Hexagonal Architecture in Go

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

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

- An HTTP client library for ruby

Завтра, в 20:00 по москве, стрим. Будем делать распределенную блокировку. Возможно успеем поковырять zookeeper.

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

https://www.twitch.tv/davydovanton

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

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

Сегодня специальный выпуск. Я фанат журнала Increment, который каждый месяц выпускает статьи связанные одной темой. Уже выходили выпуски о тестировании, Open Source и языки программирования. Рекомендую ознакомиться, так как уже вышло 12 выпусков.. Февральский номер посвящен Software Architecture и я нашел время и прочитал выпуск спустя месяц.  Поэтому сегодня, три статьи которыми хочу поделиться.

Если понравился формат - пиши, сделаю регулярным и разберу прошлые выпуски.

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

A primer on functional architecture

В последние пару лет больше и больше думаю о том, как использовать идеи FP мира в архитектуре. Как пример, что будет, если рассматривать каждый из сервисов как отдельную функцию (stateless и stateful) и модуль и попробовать применить идеи из OOP и FP миров для организации логики. Поэтому статья стала однозначным мастридом для меня. В статье вы не найдете рабочих практик, но это будет отправной точкой для дальнейшего изучения материала, в чем помогут ссылки в конце. А также, в тексте,  найдете информацию о the entity-service antipattern, событиях, пайпах, DDD и boundaries/contexts.

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

In space, no one can hear you kernel panic

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

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

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

A monorepo renaissance
The rise of nanoservices

Две статьи которые дополняют друг друга.

В первой рассказывается о том, как монорепозитории были забыты с приходом облачных сервисов. Но теперь, из-за развития микросервисов, подход с “1 репозиторий на 1 сервис” становится сложнее и сложнее. Автор предлагает вернуться назад во времени и переосмыслить подход монорепозиториев для текущих реалиях.

А вторая уходит в другую крайность и предлагает идею наносервисов, как куска кода, который деплоится в продакшен без scaffolding или boilerplate code. Это сводится к еще меньшим сервисам развернутым поверх serverless архитектуры. В статье также рассказывается о плюсах такого подхода, но лично для меня автор не смог продать идею.

#increment

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

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

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

Everything you need to know about HTTP security headers

Я плохой специалист в вопросах безопасности веб приложений. Поэтому статья оказалась познавательной, а Public Key Pinning и Referrer-Policy стали открытием. В статье найдете список из восьми хедеров, каждый из которых разбирается: как выглядит, зачем нужен, нужно использовать и как использовать в рельсе, джанге, экспрессе, го, nginx и апаче.

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

Should I really use monads?

Статья от @morozzzko в которой Игорь рассуждает о том, когда и как использовать монады в руби. Если память не изменяет, статья родилась из обсуждения в @saintprug о dry проекте и что это вообще такое. В статье автор рассказывает о том, что такое монады, на примере dry-monads объясняет каждую из монад. Также на примере показывается как использовать монады и главное, автор отвечает на популярные вопросы в духе “Is Ruby really the right place for those things?” и “What about exceptions?”.

Так же, в канале можно найти:
- Пост о монадах
- Запись стрима, где показывалось использование монад

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

- Open Source Status Update – March 2020
- Open source status update, March 2020

Месяц назад в ссылках был постом с апдейтом по опенсорсу. Сегодня такой же статус от Piotr Solnica и Tim Riley. Из статей узнаете что происходит с ханами, dry-validation, dry/hanami view. А так же, анонс dry-rails и мотивация написания библиотеки. Нравится такой формат и надеюсь, что в будущем больше опенсорс разработчиков будут писать подобные статусы.

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

- Проползал новой архитектуры wiki;
- Советы для проведения 1to1 митингов;

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

https://my.mindnode.com/7MwUq5Cz3TpTnbynwTekzMrET6xvqyuy1o3FW81Q#-889.3,585.1,2

привет!

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

Начало в 20:00 по москве

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

https://www.twitch.tv/davydovanton

Привет

Не хочется скатываться в новости, но повод стоит того.

Пару месяцев назад гильдии из руби переименовались в Ractor, а вчера Коичи выложил заметки с обсуждения API для новой абстракции. В документе найдете много японского языка (перевода нет), но примеры уже говорят о том, что планируется сделать. Краткая выжимка такая:

- У Ractor планируется сделать incoming-port и outgoing-port, это единственный способ коммуникации с внешним миром;

- Послать сообщение в Ractor и прочитать из инстанса Ractor: Ractor#send + Ractor.recv;

- Послать сообщение из инстанса Ractor и получить сообщение из “message box” Ractor инстанса: Ractor.yield + Ractor#take;

- http://amp.gs/KnZf позволяет ожидать ответа от нескольких Ractor инстансов;

- Ractor может быть именованным, а так же принимать другой ractor в качестве значения, что поможет в создании пайплайнов;

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

От себя добавлю, что это не публичный релиз и API может поменяться в будущем. Но можно представить что пытаются сделать ruby-core и проследить идеи, которые разработчики хотят реализовать. Много вопросов к неймингу, примеры выглядят тяжело читаемыми, yield и recv выглядят не к месту.  Понятна идея outgoing port (это не эрланг, в руби вряд ли все будет ractor-ом), но реализация выглядит сложной. Так же интересно узнать, появится аналог OTP и(или) кто его сделает. А так же, что будет с rack, текущей экосистемой и как изменятся http фреймворки.

Амплифер наложал с разметкой, там должен быть Reactor.select в место ссылки

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

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

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

От монолита к микросервисам

Из статьи узнаете об определении монолита и получите список пунктов когда стоит  переходить на сервисы. А так же, автор описывает идею декомпозиции, которую можно применять в легаси проектах, показывая на примере выделения сервиса из связки FrontEnd, BackEnd и базы данных. Идея проста: выделить новый боундед контекст, взять гейтвей и вытащить контекст в отдельный сервис. Если совместить статью с идеями из прошлой статьи, то можно сделать подробный гайд об экстракции сервиса.


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

How to Break Apart a Rails Monolith

Статья продолжение, в которой автор описывает подход разделения монолита на изолированные части с примером на RoR. Мне понравилась диаграмма, благодаря которой можно понять каким путем можно разделить части приложения (separate gems, engines, separate applications). К этой диаграмме так же даются описания и примеры, которые позволят лучше понять идею автора.

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

How to make up-selling recommendations based on cart using Redis

Пример создания рекомендательной системы основанной на прошлых items в orders и популярности этих items. Автор статьи свел задачу к двум проблем:

- finding all previous orders matching the current cart’s product list
- getting other products from those carts aggregated, counted and ordered by frequency

Первая проблема решается с помощью set в редисе, добавлением айтема в ключи заказов (SADD) и последующим вызовом  SINTER для определения похожих ордеров. Вторая проблема решается с помощью sorted set.

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

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

- Endless method definition · Pull Request #2996 · ruby/ruby

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

На следующей неделе стрим, будем делать hanami API приложение с GraphQL. А старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.

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

Why Event Sourcing is a microservice communication anti-pattern

На канале уже упоминались статьи связанные с event sourcing (ES). А на ютуб плейлисте храняться две части стрима связанных с ES. Часто вижу проблему, что под ES подразумевают event driven architecture, что может быть ошибочно (подробнее в стримах). Сегодняшняя статья понравилась ровно из-за одной мысли: стоит различать публичные и приватные события для каждого сервиса. Это касается не только ES, но и даже банальных событий из web части в event consuming часть сервиса (в случае типичного rails приложения аналогом может быть web app и sidekiq как приватный транспорт обмена сообщениями). В практике видел как приватные события сервиса клали в публичную кафку и начался хаос, так как другие сервисы подписывались на эти приватные события. Поэтому идея на выходные - попробовать разделить события в системе на приватные и публичные, а так же посмотреть на связанность между сервисами основываясь на приватных сообщениях.

Также стоит посмотреть комментарии оригинальной статьи, там есть что почитать и засветился Scott Bellware, автор Eventide Project.

Русский перевод

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

3 Design Principles for Engineering Data

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

в статье найдете 3 принципа
- Gradual and Optional Validation
- Creating Data Lineage
- Immutable Data.

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

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

Ruby Concurrency Final Report

В рассылке уже публиковалась статья Samuel Williams связанная с прогрессом concurrency в руби. Сегодня последний отчет, требуемый для 2019 Ruby Association Grant. В статье найдете историческую справку и примеры использования non-blocking абстракций. Автор указывает ссылку на оригинальный тред в руби кор репозитории, который объясняет имплементацию и позволяет добиться результатов, описанных в конце статьи (спойлер - время не растет от количества запросов в не блокирующих вызовах). Отчет будет интересен, если следите за concurrency в руби.

Привет, сегодня стрим, будем делать hanami API приложение с GraphQL.

Начало как обычно в 20:00 по москве.

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

https://www.twitch.tv/davydovanton

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

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

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

Методы борьбы с legacy-кодом на примере GitLab

Расшифровка доклада с FrontendConf о том, как гитлаб борется с легаси кодом на стороне фронтона. Я не фанат фронтенда, но статья показалась интересной, так как рассказывает о темах, которые касаются не только гитлаба. Что понравилось:

- “40% времени публичных раннеров на http://amp.gs/KMS4 GitLab собирает сам GitLab, потому что pipeline проходит на каждый merge request”;
- Концепция “Pinning test”, что-то отдаленно похожее делает scientist гитхаба. Но интересно наблюдать, что подобная тема всплывает в каждой из компаний;
- Увидел очередное подтверждение, что Danger работает. У меня библиотека подключена в ossboard, надо добавить в rubyjobs тоже;
- Понравилась секция с метриками.

Отдельно отмечу, что читая о “Is this known” канале в слаке, полилась скупая слеза.

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

От микросервисного монолита к оркестратору бизнес-сервисов

Автор делиться идеей 4рех стадий  развития архитектуры:
- монолит;
- distributed monolith (в статье называется микросервисный монолит);
- микросервисы;
- оркестратор бизнес сервисов (в теории, следующий шаг - монолит и стадии зацикливается);

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

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

Making Your Rails Console Interesting

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

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

- Советы и идеи как улучшить опыт удаленной работы;

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

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

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

Feature Flags: The stupid simple way to de-stress production releases

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

Если тема заинтересовала, советую посмотреть запись доклада с railsclub2018 от @wi11son.

Фичетогглинг. От теории к практике. Иван Шаматов

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

40+ Ruby on Rails Application Monitoring Tools 2020

Статья в закладки. Автор собрал инструменты для мониторинга rails (и руби) приложений в одном месте. Инструменты поделены на  группы (APM, error monitoring, etc). А также даются общие сведения по мониторингу и что конкретно стоит мониторить в приложениях. Понравились таблицы со сравнением существующих решений, а так же ссылки на библиотеки (например, rails_performance, было бы круто иметь такю библиотеку для любого рубишного стека, а не только для rails). Статья поможет закрыть пробелы связанные с вопросом “а за чем следить” и может помочь сделать чеклист для выкатки сервиса в продакшен.

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

The art of writing great release notes

Статья не связанная с технологиями, но прочитать стоит каждому, кто пишет или поддерживает библиотеки (как открытые, так и приватные для компании). Статья рассказывает о release notes, а также затрагивает темы, о которых я бы не подумал. Например: “The risks of being too creative”,  где показываются примеры medium, Tumblr и других компаний, соревнующихся в оригинальности и бесполезности релиз ноутов. Понравился пример Todoist, который использует эмоджи (думаю, что пример сильно зависит от дизайна, о чем тоже говорится, так как в гите такой пример не работает). Если лень читать статью, в конце найдете выжимку + ссылки на ресурсы, которые рассказывают о том, как писать релиз ноуты.

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

- Библиотека timetrap ищет мейнтейнеров;
- 10 советов связанных с improve your writing;

Привет!

Сегодня стрим, я так и не придумал тему, поэтому займемся опенсорсом. Начало в 20:00 по Москве

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

https://www.twitch.tv/davydovanton

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

Запись стрима уже на ютубе. За 2.5 часов сделали отзывы по компаниям для RubyJobs стриме + вытащили AST из rom relation для последующего создания ERD (entity-relationship diagram). Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.

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

Scalability concepts: distributed ID generation

Генерация ID - тривиальная задача если база одна и отсутствует распределенная система. Проблемы начинаются, когда генерация происходит в распределенной системе с несколькими тредами инкрементирующие значение ID и больше одной базы данных, в которых надо делать генерацию ключа. Автор статьи описывает 6 решений этой проблемы которые включают:

- Централизованную запись;
- Централизованную генерацию значений ID;
- Рандомное значение из большого разброса (по сути UUID);
- Привязка партишена к значению ID;
- Семантический ID;
- Скейлинг ID по географическому признаку;

Так же, автор описывает недостатки каждого из решений, упомянутых выше.

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

UNIX pipes as IO monads

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

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

Retrying failed operations

Лонгрид, в котором автор описывает опыт повторного выполнения упавшего кода, связанного с данными в распределенных системах. Главная проблема, которую будет описывать автор - что делать, если надо синхронизировать данные с кучей сервисов и часть из этих сервисов будет работать как надо, а часть будет обрабатывать данные медленно или падать с ошибками. Для объяснения возможных решений автор сделает платформу, на которой будет показывать каждый из способов. А вариантов решения три:

- Real time retrying;
- Post event retrying;
- Tackling the problem;

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


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

- История совместимости rack и rails
- A collection of Ruby tools for enterprise and more, пока есть только реализация Stream API из джавы.
- Релиз Rails Event Store 1.0