Страница телеграм канала Pepegramming

pepegramming logo

Pepegramming

587 подписчиков

Грустно о программировании. Все проблемы сюда: @davydovanton Ссылки на конкретные посты: http://telegra.ph/Pepegramming-Contents-03-11 Обратная связь: https://goo.gl/forms/iUd1Gufq6WnTsaO62


Входит в категории: Технологии
Pepegramming
30.04.2021 13:04
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Event-driven APIs — Understanding the Principles В тексте рассказывается о трёх способах создания event driven api: webhooks, websockets и SSE (Server-Sent Events). Подобное апи подойдет для пушинга информации на клиенты, например для нотификаций или обновлении асинхронного состояния. А состоит из двух концепций: возможности подписки консьюмером на определенные события и непосредственно отправкой событий. Для каждого из подходов дается краткое описание, как работает подписка и как работает отправка событий. Важно учесть, что в статье говорится не только о клиент-сервер коммуникациях, но и о сервер-сервер (webhook). А в качестве бонуса - в конце приводится еще один пример использования asyncAPI для документации асинхронных коммуникаций в системе. ————————————— An Event-Driven REST Coffee Machine API with Clojure Статья о том, как реализовать коммуникацию между частями системы используя event driven подход. Для этого автор использует собственную реализацию Embedded Event Processing библиотеки. В качестве реализации делается приложение по доступу к кофе машины используя HTTP API, которое состоит из трёх компонентов: сервера, event emitter и бизнес логики кофемашины. При этом сервер вызывает бизнес логику через event emitter. Работа с событиями состоит из handler и observer. А сервер диспатчит нужное событие во время вызова экшена, возвращая результат работы хендлера. Сложно сказать, насколько сложно будет использовать такой подход в больших системах. А также не хватило информации о том, где такой подход будет лучше или хуже. ————————————— Is Your Microservice a Distributed Monolith? Статьи о распределенных монолитах уже упоминались в канале, но сегодня маркетинговая статья от технического писателя Gremlin (платформа для Chaos Engineering). Хоть статья “продажная”, мне понравилась идея, что Chaos Engineering позволяет явно определить, является система распределенным монолитом или нет используя набор экспериментов. Такое чувство, что данную идею можно автоматизировать, автоматически “тестируя” релиз и определяя значение распределенности монолита. А потом встроить еще один шаг в CI Помимо определения распределенного монолита и описания почему он плох упоминаются три характеристики: - Services are tightly coupled - Services don’t scale easily - Services are overly chatty А для каждой характеристики дается подробное описание с примерами и вариациями. А также, предлагается набор тестов, которые могут показать насколько все плохо (с примерами использования Gremlin).
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
23.04.2021 13:04
Пятничное чтиво Один из моих клиентов хочет переписать текущее приложение и создать инхаус разработку в компании, поэтому ребята ищут рубистов. Придется с нуля переписать мелкий проект, а в будущем можно будет возглавить отдел разработки. Я помогаю с проектированием и планом работ, при этом, за разработчиками остаются решения по технологиям и деталям имплементации отдельных частей системы. Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Emergencies in Distributed Systems В рассылку редко попадают статьи о работе с критическими ситуациями в распределенных системах, но сегодня день исключение. Автор делится опытом работы с emergencies, который состоит из пяти пунктов: - Создание протокола, который должен отвечать на вопросы “кто”, “что” и "как”; - Таймфрейм в котором работает протокол; - Решения. В статье указываются три основных вида: блокирование доступа к stateless протоколам, блокирование доступа к message-based systems и роллбэк транзакций; - Различие централизованных и децентрализованных распределений. Тут работе emergency orchestrator/choreography и emergency message pipeline; - Как применять принятое решение; Статья будет хорошим стартом и, возможно, поможет начать работать над стандартизацией вокруг критических ситуаций в компании. ————————————— Simulating CloudEvents With AsyncAPI and Microcks AsyncAPI Initiative - горячий пирожок из мира архитектуры, о стандарте писали в свежем отчете по архитектурным трендам. По сути - это способ упрощения асинхронных коммуникаций посредством единого описания интерфейсов (читай сваггер для асинхронных коммуникаций). Поэтому решил добавить прикладную статью с реализацией системы используя AsyncAPI. Из статьи узнаете о существовании спецификации для event data - CloudEvents, а также о том, как комбинируя две спецификации получить полное описание асинхронного вызова в системе. ————————————— Chaos Engineering — Part 3. Tools and Methods Полтора года назад в канале публиковались первые две главы из цикла статей о хаос инженеригне. В них говорилось о том, что это такое, откуда появилось (спойлер - вдохновились пожарными) и как выбрать правильные гипотезы перед тем, как ломать систему. В третьей части разбираются 4 категории неисправностей (пятая связана с людьми): - resource level; - network and dependencies level; - application, process, and service level; - infrastructure level; Для каждой из категорий приводится описание что это, как и почему может возникнуть. А также, дается список “обычных” инструментов, которые делают тест каждой из частей системы. Все инструменты - дефолтные утилиты или вообще запросы в базу с измененным конфигом, например манипуляции с /etc/hosts и шатание серверлесс функций. Чтобы в будущем не делать тесты руками - дается список toolkit-ов, которые одной библиотекой реализуют набор неисправностей. Русский перевод
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
16.04.2021 13:04
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Как использовать ClickHouse не по его прямому назначению Давно смотрю на ClickHouse и жду случай, чтобы начать использовать технологию. Изначально казалось, что базу можно использовать для аналитики, но после прочтения статьи мозг взорвался. Из десяти способов запомнились три: - Использование clickhouse-local для локального выполнения файлов, что позволяет использовать SQL подобный диалект для работы с файлами; - Работа с полуструктурированными данными, т.е. использование материализованных столбцов для json в котором может быть поле, а может и не быть; - Реализация graph processing (осторожно, китайский); ————————————— Building Multi-Tenant SaaS App for an Unknown Scale В последний месяц часто сталкиваюсь с Multi-Tenant приложениями, при этом, я не фанат такого подхода. Так как избежать Multi-Tenant приложений не реально, то сегодня статья с примерами реализации таких приложений. В тексте найдете описание пяти подходов: - Multi-Tenancy using Virtualization - Multi-Tenancy using Containerization - Database-per-tenant - Single multi-tenant database - Sharded Multi-tenant databases Для каждого из подходов найдете краткое описание, как использовать и где подойдет. ————————————— My Mental Model on Choosing a Database for a Particular Problem Выбирать базу сложно, не только из-за количества технологий, но и из-за того, что сложно помнить все области по которым стоит рассматривать решения. В тексте, автор, описывает основные области, по которым выбирает базы данных. Всего вышло восемь пунктов: Access and Write Patterns, Consistency, Fault Tolerance, Scalability с разными вариантами, Maintenance and Observability, Self-healing, Regulations and Compliance и цена. Понравилось, что в конце еще упоминается поддержка экосистемы языка и лицензирование. Кажется что статья поможет в двух случаях: - хотите разобраться с базами данных и на что смотреть, когда данные и нагрузка достаточно большие; - хотите подготовиться к system design interview;
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
09.04.2021 13:04
Пятничное чтиво После перерыва выпустили очередную серию подкаста, в которой подкаст скатился. Говорим, как нас накрыл синдром самозванца во время подготовки курса об асинхронной архитектуре, по-детски материмся (как всегда) и рассказываем, куда пропал сосед. Слушайте везде (18+): SoundCloud , Apple , Яндекс.Музыка , Google Podcasts , Castbox , Spotify , RSS ————————————— Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 5 things I learned while developing a billing system Сделать биллинг - сложно, еще сложнее помнить о особенностях, которые могут вставить палки в колеса. В статье описывается пять идей, которые стоит помнить во время разработки. Кроме очевидного “float как тип денег выстрелит в ногу” (советую посмотреть доклад от Вани о деньгах в программировании), найдете еще размышления об обнулении инвойсов, требованиях, крайних случаях и как обрабатывать случаи, когда пользователь хочет поменять план в различных таймлайнах. ————————————— Тестирование требований: как я нахожу ошибки в бизнес-логике фичи прежде, чем их закодят По работе с клиентами, приходится часто работать с бизнес требованиями заказчиков. Во время работы над требованиями возникают ситуации, когда обсуждение приводит к ситуациями в духе: “а, мы не учли вот это и это, сейчас доработаем”. Если такие требования попадут разработчикам - придется потратить время на доработки, которые окажутся дороже, чем исправление требований. К сожалению, работать с требованиями приходится и разработчиками. Поэтому в статье найдете пример разбора требований для фичей, в которых пользователь взаимодействует с продуктом. Автор подробно объясняет как определить для кого фича, разобраться какие варианты использования и что для каждого из вариантов стоит определить. ————————————— Top 5 Things Every Apache Kafka Developer Should Know Статьи о “N вещей которые надо знать” и статьи от confluent в почете, поэтому было сложно пропустить данный текст. В тексте описываются следующие темы: - durability guarantees и отправка сообщений; - sticky partitioner в продюсерах; - ребалансировка групп консьюмеров; - CLI - хедеры записей (добавляет метаданные, например версию в сообщение); Я не знал о sticky partitioner и плавал в durability guarantees, поэтому статья оказалась отличным стартом в разборе тем. Русский перевод
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
07.04.2021 13:04
Осенью выступал в рамках курса о том, как быть тимлидом, где рассказал о архитектуре. В результате чего родился курс об асинхронных системах, который закончился на этой неделе и о котором хочется написать разбор. Изначально было неловко выступать на тимлидском курсе ибо к менеджменту мало отношения имею, но выяснилось, что информация из курса относится не только к тимлидам, но и даже к работе с архитектурой и разработкой кода в частности. Попросил у ребят контент и в результате подтянул знания связанные с проверкой гипотез, "считанием" денег клиента в работе над задачами и какие метрики и почему работают с тех долгом, а какие не работают. В результате чего, смог эффективнее разбираться в проблемах клиентов. Особым бонусом оказался урок об общении для интровертов, что похоже на краткую выжимку тем, которые поднимались в личной терапии. На личном опыте знаю как Марьяна и Федя трепетно относятся к контенту, поэтому, хоть и не даю рекламу, решил сделать исключение по большой любви. Для тех, кто захочет попробовать - PEPELEAD, 10%, а записаться можно по ссылке: http://education.borshev.com/teamlead #реклама
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
02.04.2021 13:04
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Keeping CALM: when distributed consistency is easy | the morning paper CALM (consistency as logical monotonicity) теорема представлена в 2010 году и системы основанные на этой теореме обходятся без координатора, так как координатор является боттлнеком в high performing scalable distributed systems. Статья - вводная в теорему (за подробностями - в пейпер), в которой описывается основные принципы. А также, в конце дается пример использования такой теоремы в виде языка bloom, который существует только как Bloom DSL поверх ruby. ————————————— От монолита к модулям: как отстроены бизнес-процессы склада Lamoda Кроме сервисной архитектуры можно остановиться на модульном монолите. Статья от ребят из ламоды как раз об этом. Описываются три складских бизнес процесса: входящий поток товаров, проблемы с товаром и исходящий поток товаров. Также дается три причины почему не перешли на сервисы: - Сильная связанность процессов и агрегатов между частями системы - Нужна транзакционность для бизнес процессов - Общие процессы между бизнес процессами В итоге ребята вынесли код в модули с общей базой и таким образом решили проблему транзакций. Но почему решение - модульный монолит и чем отличается от обычного монолита я так и не понял. Если есть предположения - давайте обсудим в комментариях. ————————————— The limits of the saga pattern Саша паттерн решает проблему распределённых транзакций с помощью событий и компенсаторный событий при ошибках. С бизнес ошибками такой подход работает без вопросов, проблемы начинаются с техническими ошибками. Автор статьи разбирается с тем что есть бизнес и технические ошибки, развивает идею «сага только для бизнес ошибок» и в конце даёт пару примеров “smells”, которые помогут сориентироваться, если используете сагу для технических ошибок.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
26.03.2021 13:03
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Comparision of all modern database models Название статьи говорит о контенте. Модели которые сравниваются: - key-value (redis) - Wide-column store (Cassandra) - Column-oriented (InfluxDB, ClickHouse) - Document-oriented (mongo) - Relational (sql) - Graph (neo4j, запись стрима с примером использования бд) - Inverted index (Elasticsearch) Для каждой модели дается краткое описание, плюсы/минусы, основные юзкейсы и примеры продуктов. ————————————— Reporting models and Event Sourcing Когда упоминают ES или CQRS, говорят, что много абстракций и из-за этого легче код не становится, особенно в репорах и read data. В статье автор пытается развенчать этот миф, показывая как используя ES и доменное моделирование спасти себе день работы. Статья строится на том, что можно не сливать атрибуты агрегата в одно место, а попробовать сделать разные проджекшены под каждую из задач. ————————————— Moving from Salesforce Commerce Cloud to Microservices-Based Commerce Статья с историей перехода с Salesforce Commerce (SaaS для магазинов) на собственную микросервисную архитектуру. У компании было три причины для переезда (типичные переезды с SaaS решения на самом деле): - гибкость - кастомные репорты или нормальный импорт продуктов. - скорость - говорят, что админка Salesforce Commerce безбожно тормозит. - security - в 2020 году нашли малварь в Salesforce Commerce, что позволило утащить информацию из магазинов. В оставшейся части статьи найдете описание переезда. Сначала компания определила место переезда (в статье дается 4 примера начальных сервисов в зависимости от контекста). Потом создала Middle Layer для подмены старого магазина на новые части системы и мигрировала данные из старой части системы в новую. А потом уже релиз, тесты и повтор цикла с новой частью системы. ——— одной строкой ——— - Crystal 1.0 - What to expect - The Crystal Programming Language
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
19.03.2021 16:03
Попутал ссылку к последнему посту. Вот правильная: https://medium.com/geekculture/architecting-a-scalable-permissions-service-for-saas-web-applications-a4bc7dcb1cb3
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
19.03.2021 13:03
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— How we found and fixed a rare race condition in our session handling Инженеры Github опубликовали детективную статью , в которой описывается случай, в котором пользователь случайно залогинился под чужим аккаунтом 2 марта. Дальше идет рассказ, как искали что случилось: начали с инфраструктурных изменений, потом кодовых, а потом нашли ошибку в месте, в котором она обязательно должна была случиться (не хочу спойлерить причину проблему). В статье найдете описание проблемы, что делать, чтобы не попасть в такую же проблему. Также, советую задуматься о надобности подобного подхода в рубишном и не только коде. ————————————— Communication Between Loosely Coupled Microservices — Webinar FAQ Транскрипция вебинары о коммуникациях в сервисах. Ценность ищите в описании коммуникаций (с пицца аналогиями), а также в вопросах. Личный топ вопросов: - Some people recommend not using synchronous communication at all, but use asynchronous communication instead. But for fast tasks, REST seems fine to me and a broker just adds overhead and a point of failure. Can you comment? - How to decide between commands and events? - How is microservice orchestration better than point to point connections between microservices? Can you explain this via a metaphor? Смущает, что много абстрактных вопросов, но вместе с прошлой статьей из DZone, можно разобраться в сервисных коммуникациях. ————————————— Architecting a Scalable Permissions Service for SaaS Web Applications Статья в духе: пишем шаг за шагом. В качестве авторизации будет использоваться RBAC. В начале автор знакомит с функциональными и нефункциональными требованиями, дизайном системы и моделью данных. Также используется лоад балансер, мастер/слейв репликации инстансов сервиса. А в качестве следующих шагов предлагается реализовать кеширование, инстансы на чтение и запись (непонятно что делать, когда после записи клиент сразу захочет прочитать данные). Если опустить вопрос: а зачем permissions делать в отдельном сервисе с синхронными коммуникациями - получается статья, из которой можно узнать способ реализации сервисов и вдохновиться тем, как сделать permissions в распределенной системе.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
12.03.2021 13:03
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— OAuth 2.0 flows explained in GIFs Мне сложно дается понимание и изучение видов аутентификации на “глубоком” уровне. Кажется, что проблема в большом количестве абстракций/терминов и коммуникаций между ними. И в ограниченном количестве визуальной информации (визуальная информация мной воспринимается проще, чем полотно текста). Сегодня статья - объяснение работы oAuth с помощью гифок с пошаговым выполнением каждого шага. Показывается работа пяти authorization flow и объясняются термины. Настоятельно рекомендую тем, кто сложно воспринимает текст и хочет разобраться в вариантах oAuth. ————————————— Microservices: monitoring and observability Еще одна статья об обсервабилити в микросервисной архитектуре. Рассматриваются метрики, логи и трассировка. Для метрик и логов автор указывает желательную информацию. Не хватило информации по трассировки: никакой конкретики и примеров. ————————————— Обзор книги “What Is Domain-Driven Design?” В 2019 Vladik Khononov написал книгу “What Is Domain-Driven Design?”. Книга состоит из двух частей, разбора инструментов и техник для стратегического и тактического дизайна + практическая информация по двум пунктам. Обзор кратко рассказывает о каждом из инструментов и судя по топикам, которые указанные в статье - книгу стоит прочитать. ——— одной строкой ——— - Пример аудита рельсового приложения. Круто, что проскакивают такие документы, потому что есть возможность посмотреть на то, как работают другие. Если знаете другие открытые аудиты - пожалуйста, пришлите в личку, интересно посмотреть.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
05.03.2021 13:03
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Code review checklist for distributed systems Люблю идею чек листов для рутинных действий. Ревью кода я воспринимаю одно из таких действий. А если говорить о сервисах, то количество тем, которые надо помнить возрастает по сравнению с монолитами. Поэтому статья со списком тем/вопросов/проблем, о которых стоит помнить во время написания или ревью кода. Из тем: отказы, медленность работы, идемпотентность API, обсервабилити и так далее. Статья не выглядит как полноценный чеклист, но можно использовать текст как основу для созданию персонального чеклиста в компании. Русский перевод ————————————— EventStorming Glossary & Cheat sheet Если вы захотите провести event storming сессию в первый раз - cheat sheet с терминами перед глазами поможет не тратить время на поиски определений или избежать ситуаций, когда что-то забылось. Ребята из Domain-Driven Design Crew (советую посмотреть репозитории) решили облегчить жизнь и сделали список терминов, описание процесса и советы, которые могут помочь во время event storming сессии. ————————————— Tackling Complexity in CQRS О CQRS в этом канале говорилось (была мастхев статья + стрим где делали блог платформу с CQRS на тему). Сегодня статья - описание ловушек, в которые можно попасть используя паттерн. Ловушки: - One-Way Commands, or Overzealous Segregation - Event sourcing - Too Much of a Good Thing Для каждой ловушки описывается возможное решение, а последняя - персональный фаворит. Понравилось, что в конце дается лаконичная диаграмма того, как автор видит CQRS.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
02.03.2021 14:03
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
02.03.2021 14:03
Сегодня начинается курс, которым занимаюсь фултайм последние 2 месяца, из них последние 2 недели без выходных. В конце прошлого года, когда обсуждали идею курса с Федей идея казалась отличной, так как я много выступал на конференциях и митапах до этого, а попробовать сделать курс хотел последние 2 года. К тому же, тема интересная и напрямую связана с текущей работой, так что мотивации оказалось достаточно. Мне повезло, потому что курсом занимаюсь не один, а с Федей, Марьяной и Ваней. Изначально, я думал, что сложнее всего будет сделать контент. Но больше боли принес обострившийся синдром самозванца (ну и вырезать все эканья из видео). Ребята забрали самое сложное: поддержку (и меня в том числе), маркетинг, вычитку и проверку контента на понятность человеку вне контекста. После курса, хочу написать пост с опытом и внутренней кухней (расскажу как монтировал, собирал контент, что сделал бы иначе и как уплотнил ран примерно в два раза). TLDR что произошло за последние месяцы: - попробовал себя в монтаже видео, оказалось это сложнее чем ожидалось (зато понял, что стоит переходить с iMovie на профессиональный софт); - факап с коммуникациями, который пока не понятно как решить, но гипотезы уже проверяем; - внезапные задачи, которых оказалось в разы больше, чем я мог представить; - цепочка каждого урока из "сделать скрипт записать добавить доп материалы" превратилась в цепочку из 9 пунктов. При этом, только моя работа, занимает от 15 часов на урок; Кроме проблем - получил фидбэк от ребят: - Контент — круче чем ожидали. Доп материалы, которые готовим можно продавать за отдельные деньги. Столько пользы мы не закладывали; - Видосы Федя проверяет на каждый чих чтобы каждому было понятно, Марьяна следит за тем чтобы легко усваивалось и было интересно; - Придумали как поделить большую домашку на кусочки. Подсказываем как не слететь на каждом шаге; Не знаю, как пройдет курс в итоге, так как подобного опыта еще не было. Но уверен, что будет круто, а опыта, который получил за это время хватит надолго. P.S.: бонусом - артефакт в виде нарезки, которую делал на память, видео идеально отражает состояние последних двух недель (осторожно, присутствует ненормативная лексика).
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
26.02.2021 13:02
Пятничное чтиво Анонсы: На следующей неделе стартует курс по асинхронным системам, жду и переживаю. Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Patterns for Microservices — Sync vs. Async Самое подробное описание синхронных и асинхронных коммуникаций в системах на моей памяти. В статье найдете: по три вариации на каждый из видов коммуникации, а также список трейд оффов, с которыми столкнетесь . Важно отметить, что в качестве sync оркестратора может выступать BFF или API Gateway, sync оркестратора с async вызовами - GQL gateway, а CQRS может работать с тем же сервисом, где реализована read model. ————————————— Real-time monitoring of Formula 1 telemetry data on Kubernetes with Grafana, Apache Kafka, and Strimzi Я не фанат формулы один, но фанат статей, в которых описывается, как инженеры реализуют сумасшедшие вещи. Сегодня статья с описанием того, как перегнать телеметрию гоночного болида из F1 2020 (игра такая) в InfluxDB и Grafana. Понравилось, что в статье описываются, как может использоваться Apache Camel для трансфера данных из телеметрии в кафку и из кафки в InfluxDB (давно смотрю на него). ————————————— Saga Orchestration for Microservices Using the Outbox Pattern Must read статья выпуска. Transactional outbox pattern позволяет автоматически продьюсить нужный агрегат через outbox таблицу в message broker. Sagas pattern - пример реализации распределенной транзакции. Авторы задаются вопросом: что произойдет, если совместить оба паттерна в одной системе используя kafka (на самом деле - любой message broker) и Debezium в качестве реализации outbox pattern из коробки. В статье найдете код реализации, описание failure случаев, а также, бонусом, мысли о трассировке. Особое внимание советую уделить Figure 4 (sequence diagram), в которой показывается как данные будут ходить между тремя сервисами в такой системе. ——— одной строкой ——— - Upgrow - попытка от Shopify сделать собственный hanami из рельсы;
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
19.02.2021 13:02
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Google Translate: Analyzing Clubhouse for fun and profit Clubhouse повсюду. Канал не стал исключением, поэтому ссылка на статью, в которой автор из Кореи зареверсинженерил приложение clubhouse и разобрался как соцсеть работает. Описание на корейском как работает мобильное приложение. В статье найдете диаграмму HTTP вызовов и подробное описание того, что происходит в каждом из сервисов, куда ходит мобильное приложение: - API - Agora.io как реалтайм войс и видео платформа (Китай и Калифорния) - PubNub как реалтайм чат Также, автор описывает три возможные секьюрити проблемы. API клиент на питоне Оригинал на корейском ————————————— Zero Downtime API Gateway cloud migration Дано: компания с 500+ микро сервисами, часть из сервисов вне клауда. Необходимо: перевести API на один домен, а сервисы в клауд без даунтаймов. С таким контекстом начинается статья, в которой инженеры из bukalapak описывают опыт использования API gateway для миграции системы в клауд. описываются две проблемы, с которыми столкнулись инженеры и решения, которые были выбраны. Опыт оказался успешным, а размышления можете прочитать в конце статьи. ————————————— Kafka for Engineers. Here are things about Kafka that you… Лонгрид о том, что такое кафка описанный инженерным языком, а не языком инфраструктуры. Понравилось, что в статье объясняется как появилась технология, в чем отличие message queues и кафки. Благодаря объяснению отличия между distributed queue и distributed log автор предполагает, почему инженеры используют кафку как очередь и для чего действительно использовать (спойлер - стримить данные между Bounded Contexts). Ну а дальше описываются концепции из которых состоит технология (топики, партишены, консьюмер группы и так далее). Однозначный мастрид недели.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме