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

pepegramming logo

Pepegramming

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

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


Входит в категории: Технологии
Pepegramming
03.07.2020 17:07
Пятничное чтиво Стрим не успел провести, поэтому закрываю сезон и выхожу на летние каникулы. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Scalability concepts: zero-downtime deployments Автор объясняет что и зачем нужен zero-downtime деплой. Описываются основные блоки, без которых не получится построить zero-downtime: Graceful shutdown, Load balancing, dynamic routing и health checks. После этого описывается два варианта создания подобного деплоя (Blue/green deployments и rolling deployments). Понравились вручную нарисованные картинки, по ним намного проще понять что хочет сказать автор, а так же, в конце найдете ссылку на гитхаб, в котором будет пример деплойментов. Статья entry point для того, чтобы разобраться в теме, но сложных проблем или примеров не найдете. ————————————— Microservices: Must-Have Communication Strategies - DZone Microservices Коммуникации в сервисной архитектуре заставляют помнить о проблемах, которых нет в монолитных системах. В статье, за авторством DZone, авторы попробовали собрать список проблем, с которыми потенциально столкнется разработчик. Сам текст делится на 3 части: сложности, рекомендации или возможные решения и виды сбоев. Из проблем выделяются три: Latency, Transaction и Reliability. Статья напомнила подход из DDIA, где описываются что может произойти, но конкретных решений нет. ————————————— Architecture Characteristics Defined Глава из книги “Fundamentals of Software Architecture”, в которой описываются основных характеристики, наблюдаемые в архитектуре. Из текста узнаете о трех критериях, которые входят в архитектурные характеристики (“Specifies a nondomain design consideration”, “Influences some structural aspect of the design” и “Is critical or important to application success”). А также список из характеристик, которые можно взять себе на вооружение. Если тема заинтересовала - советую первую (или вторую) главу из DDIA, там можно найти больше информации. ——— одной строкой ——— - A distributed database built on the same principles as Git; - IBM Shows Instances of COBOL Running Natively on Kubernetes;
Читать

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


Pepegramming
01.07.2020 16:07
Привет, к сожалению стрим не успею провести. Поэтому стримы уходят на летние каникулы. Вернусь в новом сезоне с новым микрофоном
Читать

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


Pepegramming
26.06.2020 14:06
md:true Пятничное чтиво Прихожу в себя после болезни, поэтому ссылки возвращаются. На следующей неделе стрим. Доделаем библиотеку со стейт машиной и используем полученную стейт машину в rubyjobs.dev. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 4 Types of NoSQL Databases Сборная статья в которой описываются четыре вида noSQL баз данных (key-value, document oriented, column-base, graph-base). Понравилось описание видов баз данных (не путать с названиями) с понятными картинками, для каждого вида баз приводятся конкретные примеры которые можно изучить. Не понравилось, что нет конкретных примеров использования, например, как использовать графовые базы в логистике. Хотелось бы видеть больше юзкейсов, почему лучше брать документо-ориентированную или графовую базу, а не использовать постгрес (об этом написано в DDIA книге). ————————————— Why JWTs Suck as Session Tokens Статья о jwt и почему подход не серебряная пуля. Понравилось описание jwt и как технология работает, а так же пример того как разработчики часто используют технологию не правильно. На примере указываются проблемы jwt. Из описанных проблем: размер токена по сравнению с id сессии, в любом случае придётся использовать базу данных, и сам формат строки. Кроме минусов автор указывает чем можно заменить jwt, а так же делится видением как использовать технологию “правильно”. ————————————— Build Streaming ETL Solutions with Apache Kafka & Rail Data Лонгрид из технического блога confluent (известны тем, что предоставляют kafka as a service и большим опытом). Робин описывает как из публичного фида UK’s Network Rail, в которой данные проходят через ActiveMQ, и REST API сделать ETL систему. Главная идея - взять источники данных, положить их в кафку, там же, посредством KSQL преобразовать данные в нужный формат и выгрузить куда надо + сделать сервис нотификаций, который будет слать телеграм сообщения, когда поезд задерживается. Решение из статьи сложно назвать серебряной пулей, скорее это пример того, как использовать кафку для стриминга данных из одного источника в другой. ——— одной строкой ——— - The Marketplace for Software Developers
Читать

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


Pepegramming
16.06.2020 18:06
Привет, я заболел, поэтому стрима завтра не будет. А так же не будет ссылок на этой неделе
Читать

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


Pepegramming
12.06.2020 15:06
Пятничное чтиво На следующей неделе выступаю на митапе, расскажу о 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 и большим количеством асинхронных фичей. Авторы описывают каждый переход и объясняют почему появился каждый новый переход. Нравится, что статья не перегружена деталями и расписывает каждый переход поверхностно, но при этом, объясняет почему и зачем это надо было. ——— одной строкой ——— - Коллекция предложений переименовать термины в репозиториях;
Читать

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


Pepegramming
08.06.2020 18:06
Привет! 18 июня будет онлайн митап от ребят из RubyRussia (ex rails club). 4 спикера (включая меня) будут говорить об оптимизации, наследовании, постгресе и CQRS. https://cutt.ly/hyBysYA
Читать

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


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

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


Pepegramming
04.06.2020 14:06
Наконец-то сделал нормальный сайт, там найдете ссылки и необходимую информацию связанную с каналом. https://pepegramming.site А так же, написал новый пост с ретроспективой опыта работы с ecommerce. https://pepegramming.site/retrospection-ecommerce/ В канале осталось куча старых постов, хочу их перевести на сайт и разбавить новыми. Так как статей накопилось много, то ближайшие пол года на сайте будет появляться новая (или старая запись) каждую неделю.
Читать

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


Pepegramming
03.06.2020 20:06
Начинаем стрим https://www.twitch.tv/davydovanton донаты - https://www.donationalerts.com/r/davydovanton
Читать

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


Pepegramming
02.06.2020 16:06
Завтра стрим, начало в 20:00 по москве. С raft алгоритмом погорячился, прикинул сколько это может занять времени и сколько готовиться надо - решил, что это слишком затратно для меня. Поэтому завтра будем делать имплементацию стейт машины с нуля, но по готовым требованиям + расскажу зачем нужна еще одна стейт машина. Покажу как использую подход с контейнерами для библиотек и напишем собственную реализацию контейнеров. А так же расскажу о RDD и почему люблю этот подход и, если успеем, пройдем цикл создания гемов с нуля до первого релиза на rubygems.
Читать

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


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

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


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

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


Pepegramming
29.05.2020 14:05
там должен был быть #2pe_analytics хештег, но амплифер его порезал зачем-то
Читать

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


Pepegramming
29.05.2020 14:05
————————————— 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)
Читать

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


Pepegramming
29.05.2020 14:05
Пятничное чтиво На следующей неделе стрим, попробуем сделать raft consensus алгоритм на руби. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Vertical Slice Architecture Out with the Onion, in with Vertical Slices На последнем стриме показывал концепцию слайсов в hanami 2.0. Идея в том, что горизонтальные части приложения (ui, application, domain, db) разбить не только горизонтально, но и вертикально. Это значит, что в самом приложении появляются “слайсы”, в которых находятся логика изолированно друг от друга. В комментариях к статье дается группа сервисов как пример для понимания. Кажется, что аналогия rails engines подходит для быстрого объяснения подхода, тем более об этом уже начинают говорить (за подробностями - к автору доклада, @greygreen). В первой статье с картинками объясняется как паттерн работает подробнее. Во второй больше уделяется вниманиям плюсам и минусам подхода, а также дается пример, показывающий, что слайсы могут быть использованы не только в бэкенде. Если хотите понять подготовиться к hanami 2.0 или же хотите взять идей для rails engines - мастхев. ————————————— [Clean Architecture: The Bad Parts](http://amp.gs/Hhg4) На прошлой неделе в рассылке присутствовали статьи автора касаемые aggregates из DDD. Сегодня статья о проблемах “clean architecture”. В начале описывается что это такое (спойлер: порты и адаптеры). Потом описываются принципы, которые должны в такой системе соблюдаться. Но к сожалению, реальность иначе. Поэтому автор описывает проблемы, с которыми встретился лично (Context Switching). Так же ставится риторический вопрос о действительной необходимости изменения базы данных в приложениях. В качестве “серебрянкой пули” предлагается использование слайсов, о которых рассказывала первая статья. Кажется, что тема слайсов будет развиваться дальше по трем причинам (время для #2peanalytics): 1. кажется, что микросервисы дошли до Trough of Disillusionment и разговоров о возврате к монолитам становится больше в моем пузыре; 2. ограничивать части монолита нужно, DDD добавляет абстракций, использовать сервисы, декораторы и другие объекты в больших проектах сложно (куча хлама в одном месте). По идее, слайсы как раз и могут решить проблему поддерживаемости, при этом не добавляя проблем распределенных систем; 3. об этом начинают говорить не только в .net но и в js, ruby и других экосистемах. При этом, я думаю, что подход вряд-ли окажется популярным как микросервисы, но он доступен для любой экосистемы, даже для rails.
Читать

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