2pegramming

2022-08-29 17:00:16 Запускаем четвертый поток курса по асинхронным коммуникациям, который прошло уже больше 1к человек. Старт 23 сентября, закончим 27 октября. Промокод на 10% скидку ASYNC_PEPE, действует до 9 сентября.

Курс позволит профессионально вырасти и улучшить знания вокруг проектирования систем и работы с событиями. Т.е. основная цель не только рассказать как отправлять события, а объяснить логику поиска событий из поведения системы и данных, необходимых для ее работы, определиться с границами доменов, разделить события на бизнесовые и "технические". А также объяснить процесс мышления "что делать важнее чем как что-то делать". Ну и до кучи - показать и рассказать что делать в случае проблем.

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

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

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

Промокод на 10% скидку ASYNC_PEPE, действует до 9 сентября.

P.S. Про курс об анализе систем и распиле монолитов никто не забыл, контент делается. Открыть/Комментировать

2022-08-26 13:31:00 Пятничное чтиво

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

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

How to Lead a Project - as a Software Engineer

Рано или поздно наступает момент, когда начинаешь менеджить проекты. К сожалению, этому учат тимлидов, но не учат инженеров, из-за чего могут возникать проблемы. Так, первый крупный проект, который менеджил - превратился в ад и хаос. И если бы не тимлид - хз как выкручивался бы. Поэтому сегодня статья с советами и "капитанским" гайдлайном о том, как менеджить проекты для инженеров и будущих менеджеров. Предупреждение: текст может показаться “очевидным”, если у вас уже присутствует минимальный опыт.

Автор описывает пять пунктов, которые считает обязательными: создание фреймворка для общения с заинтересованными лицами, менеджмент рисков, шаринг статуса с заинтересованными лицами, делегирование и мотивация. Понравились первые два пункта, из них можно сделать чеклист для того, чтобы не забывать, что сделать надо. Хоть автор старается подвести к “купи статью и получишь больше”, чеклист, в конце текста, может помочь если столкнулись с проблемой менеджмента проекта в первый раз.

#management

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

Документация в порядке

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

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

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

#documentation

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

Паттерн Outbox: как не растерять сообщения в микросервисной архитектуре

Outbox паттерн уже упоминался в канале не один раз. Сегодня статья, в которой инженеры Lamoda делятся опытом использования паттерна для реализации процессинга заказов.

На примере резервации доставки описывается проблема: что делать, если часть заказов отменилась и сервис с отменой лег, бизнес теряет деньги, так как остаются “пустые” доставки. Дальше описывается паттерн и базовую структуру outbox таблицы, а так же плюсы и минусы. Интересное начинается в момент объяснений видов гарантий при отправке сообщений и рассуждений, почему exactly once не может существовать. В конце автор останавливается на at-least-once гарантии из-за чего могут возникнуть дубликаты. Эту проблему автор описывает в последней части текста.

#events #transactional_outbox Открыть/Комментировать

2022-07-29 13:31:00 Пятничное чтиво

Важное объявление: пятничные ссылки уходят в ежегодный отпуск на 2 недели. Вернусь в середине августа, после 15го числа (если не будет никаких форс мажоров).

В виду моей перегруженностью информации, последней статьей сезона и отсутствию интересных статей, сегодня будет спецвыпуск: три статьи связанные с factorio и IT. Рассмотрим три абстракции: низкоуровневую, архитектурную и менеджерскую. Если еще не пробовали “игру” - возможно эти статьи дадут нужную мотивацию потратить отпуск на постройку цехов.

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

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

YouTube: Factorio Belt Computer, part 1

Я не фанат технических видео, но сегодня день исключение. Четыре 13-15 минутных видео, которые показывают как собрать программируемый CPU используя только ванильные конвейеры из факторио. Зачем смотреть: если вам понравилась “Код. Тайный язык информатики” - по ссылке найдете минимальный аналог + базовое объяснение работы процессоров.

В первой серии показывается, как на конвейерах и бесконечных сундуках реализовать базовые комбинаторные операции (OR, AND, XOR, etc). В конце показывается, как складывать два двоичных числа и как перевести двоичное число в 10ричное не используя лампочек.

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

Третья часть показывает как сделать 9х9 калькулятор используя различные ресурсы, а завершается серия созданием Arithmetic-Logic Unit, блока процессора, который выполняет арифметические и логические преобразования над данными.

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

#factorio

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

Проверяем Архитектурные стили на движке Factorio (часть 1)

Если больше нравятся абстрактные вещи, например архитектурные стили - автор с помощью факторио создает эмулятор разработки ПО для валидации пяти стилей: монолита, SOA, service-based, EDA, microservices. Для сравнения, автор проходит игру используя каждый стиль, а дальше начинается магия, автор делает анализ по ТТТ характеристикам: Evolvability, Perfomance, Deployability, Scalability, Agility, Fault Tolerance, Configurability, Domain Partitioning, Abstraction Level, Elacticity, Testability и Cost. Для каждой характеристики прописываются сценарии (прямо как в quality attribute scenarios). После этого делаются выводы по стилю.

Это наверно самый прекрасно странный текст, который я читал за последние года три. Сильно хочу видеть что-то подобное для сравнения стилей в реальной жизни с software системами. Единственный минус - автора хватило только на статью о монолитах.

P.S.: автор, если читаешь это, прошу, доделай цикл.

#factorio #architecture_style

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

Factorio Is The Best Technical Interview We Have

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

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

#factorio #собеседования Открыть/Комментировать

2022-07-29 13:30:01 Открыть/Комментировать

2022-07-29 13:30:01 Самат напомнил, что стоит писать о работе и успехах, хоть я и стараюсь избегать этого всеми силами (ну и отдельное спасибо Марьяне за пинок). Надеюсь, когда-нибудь допишу черновики по работе с разными компаниями, в которых помог переделать всю систему для улучшения time to market и maintainability, улучшить перфоманс части системы под хайлоад и так далее.

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

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

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

А если не хотите ждать и хотите сами все изучить - можно посмотреть краткое содержание с объяснением базовых концепций по ссылке. Открыть/Комментировать

2022-07-22 13:31:00 Пятничное чтиво

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

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

Soft Deletion Probably Isn’t Worth It

Soft delete подход помечает данные как удаленные, вместо реального удаления этих данных. Такое удаление преследует две цели - безопасно удалить данные и если что, восстановить “удаленные” данные. Судя по опыту - подход распространен и используется (или использовался) в каждой первой компании, где я работал.

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

- code leakage (утечка кода) - когда реализация логики уходит на уровень данных (пролил скупую слезу при упоминании actsasparanoid);
- losing foreign keys - тут о том, что при софт делите можно забыть “удалить” связанные данные;
- pruning data is hard - если данные придется удалить совсем, из-за ключей и маркировок будет сложно это сделать;

Дальше автор рассуждает когда нужно восстановление данных (спойлер - автору не пригодилось). Но самое интересное, ради чего статья оказалась в подборке - deleted records table подход. Создается отдельная таблица для данных которые удалились (одна таблица для всей бд). Таблица хранит данные в jsonb, а также оригинальный id записи, привязку к таблице, откуда удалились данные и deleted_at. Подход спорный, но, так как с таким не сталкивался - решил поделиться.

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

#data_modelling

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

ArchUnit: Test Software Architecture Easily | Better Programming

У меня сложные отношения с джавой. Каждый раз, когда надо было написать код - страдал, а вот примеры инструментов из джавы люблю и вдохновляюсь. Один из таких инструментов - ArchUnit. По сути, это набор фитнесс функций, которые тестируют архитектуру джава проекта. Умеет проверять нейминг, структуру программы, поддерживаемость проекта определенным паттернам (например кросс вызов слоев в layered architecture style), наличие циклических зависимостей, соблюдение правильной связи между поддоменами и доменами. Подробнее можно прочитать по ссылке выше (а также о фитнес функциях). Ну и добавлю, что сожалею об отсутствии подобных инструментов и слабом развитии в других экосистемах, кроме dotnet (ну или не замечаю развития). Надеюсь, что на пенсии я сделаю аналог для руби

#fitness_functions #archops

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

Делим неделимое или горизонтальная декомпозиция

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

Рассматривается три способа деления:

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

Дальше расписывается об организации работы, кто за что отвечает, как деплоится и тестируется.

#management Открыть/Комментировать

2022-07-15 13:31:00 Пятничное чтиво

Ребята из эврона попросили рассказать о двух вещах: 20го июля (среда), в 19 часов будет рубишный митап и о Ruby Quiz. Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.

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

Migrating Monoliths to Microservices with Decomposition and Incremental Changes

Статья - транскрипт выступления Sam Newman с QCon London, в которой рассказывается о способах декомпозиции монолита на сервисы.

В начале, автор описывает три варианта монолитов: обычный модульный монолит, вариация монолита с несколькими базами данных и распределенный монолит. После чего рассматриваются два паттерна декомпозиции: strangler fig и branch by abstraction. Понравился пункт, в котором рассказывается, как валидировать миграцию сервисов запустив одновременно старую и новую реализацию (если что, это главный навык без которого рефакторинг цехов в факторио превращается в хаос). Заканчивается лонгрид описанием миграции данных и как джойнить данные между сервисами.

#monolith_decomposition

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

Microservices Observability Design Patterns

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

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

#observability

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

Should you throw an exception when rebuilding the state from events?

Event sourcing позволяет получить состояние из событий, но что делать, если по какой-то причине не хватает нужных событий, без которых стейт не соберется? Например: отсутствует product из которого собирается item в order. На этот вопрос рассуждает автор сегодняшнего текста.

В начале, описывается краткий интродакшн в event sourcing: что такое события, что такое стрим событий, какие две минимальные операции должен поддерживать эвент стор, как собирать стейт из событий. После чего вводится абстрактная ситуация в которой не смогли записать какой-то набор необходимых событий (например, когда выкатывается не протестированный код).

Дальше возникает выбор между:

- Игнорировать поломанные данные (автор сразу выкидывает этот вариант)
- Добавить компенсаторные событий
- Выкидывать эксепшен

В самом тексте расписывается каждый из вариантов и, ожидаемо, конечный вариант можно сократить до “зависит от”.

#event_sourcing Открыть/Комментировать

2022-07-08 13:31:00 Пятничное чтиво

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

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

About Bounded Contexts and Microservices

Еще одна статья о размере микросервисов, на этот раз от автора Event Storming. Для начала дается определение Eric Evans для context (обстановка, в которой появляется значение слова или высказывания) и bounded context (ограниченность применимости определенной модели). После чего, автор, рассуждает о микросервисном подходе и даются краткие характеристики стиля. Благодаря этому автор доказывает матч между микросервисами и bounded context (концепцией).

Потом обсуждается размер сервиса, в котором поднимается тема использования монолита в стартапах, с последующем физическим разделением монолита на сервисы при росте компании. После чего, автор приходит к выводу, что bounded context возникает вокруг целей бизнеса и language boundaries. А размер микросервиса строится от частоты изменений и размера команд, в первую очередь. Понравилось, что указывается антипаттерн в виде разделения сервисов по данным (читай entity services).

#service_boundaries #ddd #bounded_context

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

Explain Redlock in Depth

В канале уже публиковалась ссылка о распределенных локах, с ссылкой на офф гайд редиса о работе redlock. Сегодня статья описывающая Redlock, реализацию распределенной блокировки поверх редиса, и объясняющая, почему redlock не практичен (тут важное замечание, автор говорит о кластере редисов, а не об одной ноде).

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

#distributed_lock #redis

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

6 Symptoms of a Distributed Monolith

Распределенным монолитом называют систему, состоящую из сильно связанных (coupled) сервисов. Автор собрал 6 “запахов” связанных сервисов в одной статье:

- Когда два сервиса должны деплоиться одновременно;
- Когда первый сервис использует определенную версию второго сервиса, при этом, при изменении версии второго сервиса придется менять конфигурацию первого сервиса;
- Bi-directional Dependencies. Когда сервис А вызывает Б, а Б вызывает А;
- Использование общей базы данных. Т.е. при изменении схемы для одного сервиса - придется менять второй сервис;
- Когда два сервиса продьюсят события в одну и ту же очередь/топик;
- The Enterprise Service Bus. Самый спорный пункт из статьи;

#distributed_monolith #coupling Открыть/Комментировать

2022-07-01 13:31:00 Пятничное чтиво

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

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

Размер микросервиса

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

- Изоляция по бизнес потребностям - границы проводятся по заветам DDD, т.е. по бизнес процессам, коммандам, bounded context, , etc. При этом, использование event storming может помочь найти границы;
- Изоляция состояния - система разделяется по данным, с которыми работает до тех пор, пока 2+ серивса не начнут в одну базу ходить или использовать распределенные транзакции;
- Изоляция в пространстве - не очень понял идею, если кто-то поймет, объясните пожалуйста в комментариях;
- Изоляция во времени - если нужна транзакционность для поддержания согласованности данных - лучше такие части объединять;
- Изоляция сбоев - падение одного сервиса не влияет на другие;

#service_boundaries

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

Top 10 Architecture Characteristics / Non-Functional Requirements with Cheatsheat

Архитектурные характеристики (non-func requirements, quality attributes) являются частью системы, благодаря которой можно принимать технические, дизайн и архитектурные решения. Например: в двух одинаковых по функционала блога за 15 минут, один блог должен обрабатывать 10k запросов в секунду, другой - 5 запросов. В таком примере, дизайн и архитектурные решения будут отличаться, при том, что функционал и форма блогов будет абсолютно одинаковой.

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

#architecture_characteristics

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

Tactical Forking

Если верить авторам Software Architecture: The Hard Parts, существует два варианта архитектурной декомпозиции монолитов:

- component-based
- tactical forking

Первая предполагает выявление компонентов и постепенный перенос компонентов из монолита в отдельный сервис (5 глава книги, там шесть шагов).

Но сегодня статья о втором варианте. Идея заключается в копировании системы 1 в 1 как новый сервис, после чего не нужный код удаляется до тех пор, пока не останется только необходимый функционал в каждом из сервисов. Это похоже на создание скульптур из мрамора, когда итеративно отсекается лишнее. Главный плюс подхода, по заверению автора, позволяет разбить big ball of mud на сервисы.

Вроде как, первым, подход описал Fausto De La Torre, статью которого можно найти по ссылке.

#monolith_decomposition

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

- В четверг прошло интервью с Мартином Клеппманном, это автор Designing Data-Intensive Applications (DDIA), запись еще не выложили, но она должна появиться на канале книжного клуба Открыть/Комментировать

2022-06-29 16:35:54 Привет!

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

Так как материала много и он сложный, мы решили пойти по пути lean-startup и протестировать сокращенную версию на небольшой группе, как мы делали до этого. Поэтому решили сделать двухдневный интенсив, где вкратце пробежимся по материалу и скорее всего попробуем сделать прототип домашки.

От желающих нужно будет время 23 и 24 июля. Скорее всего формат будет такой: утром/днем созваниваемся на пару часов для разбора материала. Потом отдых и работа над практикой. Вечером созвон на час—полтора для обсуждения, что получилось и ответов на вопросы. Итого где-то 4-5 часов в день чистого времени. Плюс сколько то на самостоятельную работу. Пока хз сколько, поэтому лучше ничего не планировать в эти дни. План такой, но может все измениться.

Сможем взять только 10 человек. Чтобы было больше мотивации вход делаем платным. 5К рублей за 2 дня. Если вы пойдете потом на курс — доплатите только разницу.

UPD: места закончились Открыть/Комментировать