Пятничное чтиво Ссылки уходят в ежегодный летний отпуск на месяц с 1го июля. Увидимся в начале августа. Спасибо что читаете и пишете комментарии ❤️ Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно . А ответы на вопросы можно прочитать на сайте . ————————————— How Spotify Recommends Your Next Favorite Song Помню, удивился, что в шазаме используются преобразования фурье для поиска песен. Сегодня статья тоже о музыке, точнее о том, как спотифай рекомендует треки. Начинается текст с объяснения collaborative filtering. Идея в том, чтобы создать матрицу с коэффициентами, основанных на том, как пользователь реагирует на треки (пропуски, повторения и так далее). После автор рассказывает о том, что к поведению пользователя добавляется «культурный» пласт. Тут парсятся блоги, тексты песен, журналистика и строятся векторы для маппинга песен на жанры или «эмоции». А для песен, загруженных несколько минут назад, файл прогоняется через «deep acoustic feature extraction pipeline». Далее описывается, как отдельные алгоритмы работают вместе, где тут используется кафка и что лежит в кассандре. В конце текст переходит в техническую плоскость. Дается таблица технических решений. А также описываются трейдофы решения: точный/приблизительный поиск, выбор между eventual и immediate consistency и так далее. Текст выглядит как сгенерированный нейронкой, но о процессе обработке информации почитать было интересно. #how_it_works ————————————— Жизненный цикл API «Жизненный цикл» чаще используют для обсуждения SDLC (жизненный цикл разработки), хотя жизненный цикл относится и к коду, сервисам, схемам асинхронных событий и так далее. Статья выше о том, что происходит с API от планирования до выведения из эксплуатации. Текст начинается с описания основных этапов ЖЦ: планирование, проектирование, реализация, тестирование, развертывание, сопровождение и вывод из эксплуатации. Каждый этап подробно описывается. Так в планировании, стоит задуматься о solution requirements и ответить на вопросы о том, кто пользователи, какие сроки и так далее. В этапе проектирования описываем схемы, в реализаци — пишем кодпро. В тестировании автор упоминает о видах тестов (интеграционное, контрактное, сквозное и т.д.). Отдельно порадовало упоминание «квадрантов agile-тестирования». В конце описываются идеи вокруг управления API и «фантазии» о будущем API. #api ————————————— How I’d Design a Global Payment System В канале редко упоминаются статьи в духе «я спроектировал аналог Х», так как 99% таких текстов о том, как проходить system design interview. Но сегодня решил сделать исключение, так как автор решил заморочиться и выйти за пределы интервью. Текст начинается не с постановки проблемы, а с терминологии. Даются определения payment gateway и payment processor (первое о передачи данных между устройством и банком, второе — о проведении платежа). Далее автор описывает то, что будет проектирование: проведение платежей, регулярные платежи, рефанды и разрешение споров. Плюсом задаются характеристики (миллионы запросов, 4 «девятки», масштабируемость и так далее). Далее описывается три слоя из которых будет система: фронтенд, бек (конечно же на сервисах с кафкой) и как хранить данные данные. Понравилось, что показывается схема данных для каждого из сервисов. Ближе к концу описывается flow транзакций в 8 шагов, включая антифрод. А в конце описываются quality тактики, которые автор выбрал вокруг reliability, scalability и security. К границам сервисов и названию топиков кафки есть вопросы, но это дискуссионная тема статьи. #system_design
PePepegramming
Грустно о программировании. Все проблемы сюда: @davydovanton
pepegramming.site
Medium: https://medium.com/pepegramming
Ссылки на конкретные посты: http://telegra.ph/Pepegramming-Contents-03-11
Обратная связь: https://goo.gl/forms/iUd1Gufq6WnTsaO62
CategoryTechnologyLanguageRUFirst seenJul 06, 2026QualityVerified
Subscribers947
Avg views34.4K
ERR240.2%
Price-- RUB
Price / subscriber--
Price / view--
Metrics updated: Jul 07, 2026
Recent posts
Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно . А ответы на вопросы можно прочитать на сайте . ————————————— How Netflix Maps Thousands of Microservices in Real-Time Очередная статья о нетфликсе, в которой рассказано, как в компании решали технические проблемы. Сегодня текст о том, как в компании улучшали наблюдаемость системы, а именно строили граф связи сервисов. Для этого создали Service Topology, о которой и рассказывается в тексте. Текст начинается с описания мотивации компании: повторяющиеся вопросы о структуре распределенной системы от инженеров, которые систему чинили или меняли. Плюсом, полезно было бы сразу понимать, что заденет изменения в сервисах. Для этого решили собирать информацию с трех мест: eBPF network flow logs, IPC metrics (для эндпоинтов) и распределенные трассировки. Далее положили собранную информацию в графовую бд, подключили grpc, настроили фильтрацию (включая фильтрацию по времени работы) и получили «карту» системы. Причем, данные хранятся не как снапшот, а с привязкой ко времени, что позволяет собирать временные проджекшены. #how_it_works #observability #distributed_systems ————————————— Fundamental concepts of plugin infrastructures Чем дольше живу, тем больше думаю о недооцененности системы плагинов для создания софта. В частности, недооцененность microkernel архитектурного стиля. Хоть плагины распространены в редакторах, браузерах, играх и других приложениях, но считаю собственным долгом двигать эту тему в массы. Поэтому сегодня статья о четырех концепциях для реализации плагинов. Начинается текст с примера на python, где автор решает сделать blog engine для генерации html. Далее объясняется, при чем тут плагины и показывается подход, который нравится автору: через plugin registry, хуки и discovery через загрузку модулей. Во второй части текста описываются четыре концепции, о которых стоит помнить: discovery, registration, mount points и extension API. В конце рассматривается как в mercurial и wordpress реализованы эти четыре концепции. #microkernel #plugin_system ————————————— Как найти медленный запрос в PostgreSQL: три инструмента мониторинга Продолжение статьей о том, как оптимизировать запросы в постгрес. В тексте найдете описание трех инструментов: - pg_stat_statements . Отслеживает статистику выполнения запросов к бд, попутно группируя одинаковые по структуре запросы. Как примеры использования, приводится поиск частых и медленных запросов, а также запросов с низким уровнем кеширования; - auto_explain . Автоматически выполняет EXPLAIN ANALYZE для медленных запросов с записью плана в лог. Тут важно следить за количеством записанных логов; - log_min_duration_statement . Записывает в лог запросы, которые выполняются медленнее, чем заданный порог. Тоже важно следить за размером лога. Так как каждое из трех инструментов расширения — ставить каждое придется через изменение postgresql.conf (в статье описаны шаги для включения и настройки). В конце найдете «эвристику» для выбора, какое из расширений включать в зависимости от нагрузки и окружения (дев/стейдж/прод). #psql
Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно . А ответы на вопросы можно прочитать на сайте . ————————————— Сколько стоит ваш техдолг: методики, цифры, российская специфика В канале раз 5 упоминались статьи связанны с тех долгом, например «вводная» статья упоминалась год назад (остальные статьи по тегу). Сегодня еще один текст о долге, только авторы решили посчитать «долг» в рублях. Текст начинается с объяснения, почему тех долг не видит бизнес и наоборот. Авторы связывают отчетность и фокус внимания бизнеса, куда не попадает техническая составляющая, не говоря уже о долге. Далее предлагается три способа подсветить долг бизнесу: прямые опросы людей, добавление тега «tech dept» в «джиру» и git churn (показывает процент перезаписанного кода за время). В конце предлагается три способа «оценки» долга в деньга: - Считаем время, потраченное на затупы из-за тех долга и умножаем на часовую ставку. Берем цифру и показываем, сколько денег можно сохранить; - Берем SonarQube и SQALE, полученное значение умножаем на часовую ставку, идем к бизнесу и повторяем первый вариант; - Считаем cost of delay. Тут нужно посчитать задержку выхода фичи, в итоге получаем два числа: сколько времени фича реально делалась и сколько делалась бы без задержек. P.S.: Учтите, что статья в блоге компании, которая «продает» собственное приложение. На базовую информацию не влияет, но мало ли. #tech_debt ————————————— PostgreSQL 19: Native Graph Queries Are Here Случайно узнал, что осенью поменяю планы и буду ковыряться с постгресом. Связанно это с тем, что в сентябре выходит 19 версия, где главная, для меня, фича — нативная поддержка графов (хотя возможно гта победит графы). Почему-то уверен, что графы появились благодаря RAG и LLM. Синтаксис запросов уже описан в ISO SQL:2023 Part 16 , а язык запросов назвали SQL/PGQ (Property Graph Queries). Статья выше объясняет как будет выглядеть работа с графами в пг. Пересказывать статью не буду, кратно расскажу как работает. Для начала работы с графами определяем property graph. Делается это через CREATE PROPERTY GRAPH , где явно указываются vertex (ноды, вершины) и edges (связи) таблицы (причем таблиц может быть больше одной). А что бы сделать запрос, используется SELECT * FROM GRAPH_TABLE (property_graph MATCH ...) . Плюс стандарта в том, что язык запроса похож на cypher. В статье найдете примеры и, что радует, автор описал ограничения: fixed-depth pattern matching. Ну и другие фичи 19 версии тоже описываются. #psql #graph ————————————— What Is the 3-2-1 Backup Rule and Why It's Evolved to 3-2-1-1-0? Я не DBA, поэтому о правиле 3-2-1 слышал, но использую только для 3 наборов данных и это не о коде. Если что, 3-2-1 о том, что нужны 3 копии, на 2 видах носителей и 1 копия должна быть в другом гео месте. Поэтому удивился, когда увидел 3-2-1-1-0 схему, думая что 3-2-1 уже заморочена для 80% проектов, но киберпреступления повлияли на бекапы. Начинается текст с объяснения 3-2-1 подхода, быстро переходя в ответ на вопрос — почему такого подхода уже не хватает (спойлер: с шифровальщиками не помогает). Поэтому, как эволюция подхода, предлагается добавить 1 иммутабельную копию, отключенную от интернета и 0 ошибок от проверки восстановления (поэтому 3-2-1-1-0). Далее рассказывается, как реализовать новое правило: локальный бекап на диске, второй бекап на другом носителе, cloud copy, копия на ленте/в облаке с object lock и автоматизация накатки бекапов. В конце описываются best practices и FAQ (вопросы — пересказ статьи). Русский перевод #db #backups
Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно . А ответы на вопросы можно прочитать на сайте . ————————————— Scaling ArchUnit with Nebula ArchRules Статья от нетфликса, в которой инженеры делятся опытом решения проблем с обратной совместимостью совместимостью библиотек. А так как нетфликс использует джаву, то для решения взяли ArchUnit («тесты» для структуры проекта на джаве). Текст начинается с проблемы: библиотека обновилась с breaking changes, из-за чего развалились сервисы на джаве. Как решение управления жизненным циклом библиотек выбрали archnunit, потому что работает поверх байткода (т.е. работает в jvm стеке), позволяет добавлять правила и содержит низкоуровневый API для сложных правил. В самом начале работы, инженеры, решили настроить работу с централизованным стором правил для проектов (чтобы не копировать правила из проекта в проект). Далее описывается как запускаются правила и как работать с артефактами библиотеки. В конце описываются некоторые примеры правил (безопасность, применение nullable аннотаций и так далее) Отдельно отмечу, что в русском переводе встречаются комментарии от джава разработчика, который раскрывает части статьи для людей вне джава экосистемы. Отдельно упомяну первый комментарий (в тексте), где дается ссылка на реддит с обсуждением использования модулей, вместо archunit. Русский перевод #archUnit #fitness_functions ————————————— A Field Guide to Alternative Storage Engines for PostgreSQL Статья из серии «а что, так можно было?» (я не настоящий DBA). В 2019 году в 12 постгресе сделали table access method API. Предполагалось, что будут добавляться новые способы для хранения данных (колонки для аналитики, undo-log для OLTP и так далее). Автор текста выше решил написать, что из себя представляет экосистема. Текст начинается с объяснения принципов работы API. Тут важно, что TAM API не является «настоящим» pluggable storage layer, только tuple-shaped abstraction. При этом, индексы тоже не работают. Ну и механизмы разбиваются на 4 группы: - Heap replacements; - Columnar; - Lakehouse-backed (тут постгрес — интерфейс запросов поверх внешнего колоночного механизма); - Специализированные TAM модели (тут автор упоминает три решения, одно связана с TimescaleDB и уже умерло). Для каждой группы автор приводит примеры реальных проектов, кратко объясняя как TAM работает. А в конце делится советами по выбору подходящего TAM (если конечно решитесь). #psql ————————————— Building a mental model for Stripe payments Мне нравятся статьи в которых описывается реализация домена (8 лет жду аналога книги Фаулера). Статья выше — почти такая статья, потому что текст, в краткой форме, описывает принципы работы и объясняет работу стейт машины для PaymentIntent . Начинается пост с примера: делаете магазин, доходите до страницы оформления заказа — начинаются проблемы. Как минимум, придется думать о взаимодействии с платежными системами, банком клиента, anti fraud процессах, соблюдении нормативов и так далее. Далее рассказывается о PaymentIntent объекте: намерение получить платеж от клиента. Сам объект отслеживает жизненный цикл платежа от старта и до конца (картинка с sequence diagram прилагается). Далее описываются пять этапов, через которые проходит платеж (оформление заказа, токенизация, аунтификация, capture и расчет со сверкой). В конце описывается, как работать с вебкухами страйпа, что бы знать что с платежом происходит. Если устанете читать — на сайте сделали «терминал», где запускается змейка (вызывается на <c>). #payments #domain_implementation
Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно . А ответы на вопросы можно прочитать на сайте . ————————————— A Promising New Metric To Track Maintainability Стараюсь пропагандировать ADD , где ключевая идея — принятие решений на основе характеристик. В случае с исчисляемыми метриками — вопросов нет. Сложности начинаются с «субъективными» и не исчисляемыми метриками, например с maintainability или modifiability. Поэтому сегодня статья, где предлагается математическую модель для расчета maintainability. Начинается текст с предположения, что coupling и cyclic dependencies помогут с расчетом, но, из-за вертикального и горизонтального разбиения, значения считать сложно. Как решение вводится понятие verticalization, благодаря которому, получается Maintainability Level через работу с циклами графа. Во следующей версии метрики, вводится штраф за «длину» цикла. После чего автор занимается fine tuning метрики. Для систем с малым количеством компонентов, метрика работала плохо. Вторая ситуация возникла, когда метрика показала «хорошее» значение, но разработчики были не удовлетворены поддерживаемостью. Проблема оказалась в структуре модулей, которую решили дополнительным условием. #maintainability ————————————— Why senior developers fail to communicate their expertise Проблемы в коммуникации между техническим отделом и «бизнесом» — база. Причин много: отличия в «важности» (у одних — сложность реализации фичи, у вторых — как инвестора на деньги разорить), разные цели от системы и так далее. Причин много, но автор статьи решил пойти по пути разбивки «бизнеса» на два цикла: вывод продукта на рынок и работа с платящими клиентами. Начинается текст с ситуации, когда бизнес приходит с гениальной идеей: «меняем разработчиков на LLM». От подобной идеи у разработчиков дергается глаз из-за сложности (complexity). Через конфликт, автор вводит первый цикл (в котором находятся продажники, продакт-менеджеры, CEO): компания выводит продукт на рынок и получает фидбек. В таком цикле главная проблема — неопределенность, которая решается скоростью получения фидбека. Во втором цикле, где компания предоставляет услугу пользователю и получает деньги, главное — стабильность, а со сложностью проблема. Далее автор связывает два цикла через «компанию» из-за чего получается несогласованность между людьми в разных циклах. В конце предлагаются решения, о чем уже прочтете в статье. Русский перевод #ppl_communications ————————————— On mashing up modelling techniques for fun and profit Статья заинтересовала идеей смешивания context map из ddd и c4 в одну модель. Если что, идея context map в отображении bounded context из DDD и связей между контекстами. А главная ценность — отображение паттернов коммуникаций из DDD. Добавив информацию о «типах» коммуникаций контекстов в с4, получаем больше информации о взаимодействии частей системы не только на техническом, но и на социо уровне (а software system — socio-tech system). Начинается текст с показа автором модели совмещенного context map и c4, которую сделали для воркшопа. А после объяснения плюсов подхода показывается как подобные модели делать. Сначала делается c4 level 1 с интеграциями, после чего добавляется level 2. Далее добавляются паттерны коммуникации на level 2 (open host, anti-corruption и так далее). После чего добавляются контексты и объясняется в чем плюсы и минусы подхода. В конце дается название подходу (Model Storming). Единственное что огорчило — нет конкретных инструментов, а статья сугубо идейная. #c4 #ddd