Пятничное развлекательное

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

Название статьи говорящее — Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло, но там не только об этом.

После прочтения вы наверняка не начнете проводить "офигенно длинные собрания", но точно почерпнёте набор того, что важно для полезной, качественной встречи. Мне очень понравилась мысль, что на встрече должно быть минимально достаточное количество людей для принятия решения. Чтобы не приходилось с ним бегать наверх для одобрения. Кстати, о том как этого добиться, есть отдельная статья.

В статье хорошо демонстрируется важность единой терминологии. По сути — один из аспектов DDD, о котором писали раньше. Простой термин, но как он может по-разному интерпретироваться. Например, "наличие". Для закупки «есть в наличии» — это хотя бы один товар в любом одном магазине в России. Для розницы — есть в большинстве магазинов хотя бы один товар. Для организации акций — есть хотя бы 5 штук в большинстве магазинов.

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

#edu

Попробуйте HTMX

Если у вас несложный фронтенд и не хочется погружаться в дебри развесистых фронтенд фреймворков – посмотрите на htmx. Очень интересная штуковина. Никакого javanoscript и сложной логики на фронте. Берем в руки html и вперёд.

Обзорная статья, где автор делится позитивным опытом использования htmx.

А тут можно посмотреть примеры использования htmx с вашим любимым языком программирования. Питонистам будет интересен вот такой свежий проектик.

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

#skills #frontend

Нужен совет сообщества. У нас всё острее встаёт вопрос документирования сервисов. Конечно, у каждого сервиса есть свой сваггер, к методам написаны докстринги, в ридми есть описание работы сервиса и его архитектуры. Но всё это лежит в разных местах. Хочется красивенько и удобненько собрать всё вместе.

Из хотелок:
– для всего многообразия единый веб-интерфейс: архитектурные описания сервисов из readme, openapi спецификация, общее описание архитектуры из конфлюенса.
– было бы классно понимать пересечения http-ручек, когда в случае вызова одной по цепочке вызывается другая

Есть концептуальное понимание, что должно быть что-то, что периодически собирает всю информацию из разных источников, приводит к единому виду и строит статическую веб-страницу.

Расскажите, как решаете вопрос с документацией, что документируете? Какие технологии стоит использовать?

Асинхронное взаимодействие сервисов с применением Kafka

Практическая статья, демонстрирующая, как организовать асинхронное взаимодействие сервисов на Python с использованием Kafka. Автор коротенько даёт вводные, описывает архитектуру и переходит к делу.

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

#python #procode

Пятничное развлекательное

Наверно, почти все слышали о замечательной книге "Вы, конечно, шутите, мистер Фейнман!", но она точно заслуживает ещё одного упоминания.

Увлекательная автобиография известного физика, лауреата Нобелевской премии – Ричарда Фейнмана. Как думал, как работал этот выдающийся человек. Помимо этого в книге рассказывается множество интересных историй и смешных случаев из жизни.

Эта книга вдохновляет и мотивирует на новые свершения.

Если еще не читали – обязательно прочтите.

#fun #books

TOAST – проблемы откуда не ждали

Для хранения длинных записей в Postgres используется механизм TOAST.

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

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

Но есть нюансы. Отметим практически значимые.
– В тост-таблице не может быть больше, чем 2^32 значений, то есть можно просто упереться в верхнее значение
– TOAST не поддерживает UPDATE. То есть каждая операция обновления вашего большого JSON приводит к INSERT в тост-таблицу и её распуханию.
– Независимо сколько в вашей таблице колонок, тост-таблица всегда одна.

Но дело не только в количестве значений в тост-таблице. Сам механизм накладывает определенные издержки.
JSON в Postgres уже давно не в новинку и активно используется. И, как правило, обсуждения проблем TOAST крутятся именно вокруг JSON полей.

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

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

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

#skills #database

Работа с памятью

На практике редко приходится работать с памятью напрямую, но под капотом компьютер шуршит шестерёнками — выделяет и освобождает память.

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

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

#skills

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

Автор пишет много практических постов о разработке, например, пост о логировании или какие нюансики стоит знать, внедряя loguru. Периодически поток информации разбавляется юмором. А ещё узнал из этого канала об интересной такой утилите deptry.

Пятничное развлекательное

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

А кто хочет лёгкого и интересного чтения обратите внимание на его книгу о жизни и работе в Африке – Записки примата. Необычайная жизнь ученого среди павианов. Путешествия по континенту, исследование влияния стресса на другие биологические показатели, быт местных племен.

#fun #books

Backup: май

Архитектура проекта
1. Load balancing
2. Zero-Downtime Deployments with Docker Compose
3. Как проектировать микросервисы
4. Кеширование на бекенде
5. Асинхронное взаимодействие сервисов с применением Kafka

Копаем вглубь
1. Пагинируем по-всякому
2. Как работает ChatGPT
3. Попробуйте HTMX
4. Работа с памятью

Базы данных
1. О производительности Postgres
2. TOAST – проблемы откуда не ждали

Разное
1. Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло
2. Роберт Сапольски — Биология религиозности
3. Вы, конечно, шутите, мистер Фейнман!
4. Сравниваем лампы и батарейки

Если пропустили, то подборка за апрель.

#backup

Попробуйте ruff

Ранее мы рассказывали о целом наборе линтеров, которые постоянно применяем в своих проектах.

Недавно обратили внимание на достаточно молодой и интересный линтер для python – ruff. Он объединяет в себе правила многих других линтеров – по сути всех, которые используем.

Мы уже сделали для себя конфиг и испробовали его на одном из сервисов. Полёт нормальный, ощущения только положительные.

Из плюсов:
– ощутимая скорость. Линтеры у нас прогоняются с помощью pre-commit на каждом коммите, поэтому скорость имеет значение. Пару раз даже ловил себя на мысли, что не делаю лишний коммит, чтобы не ждать прогона линтеров. А ruff отрабатывает практически моментально
– в pre-commit не нужно держать целый зоопарк линтеров. Достаточно один раз сконфигурировать и подключить ruff

Так что категорически рекомендую попробовать. У них, кстати, есть playground для этих целей.

#python

Управление данными в микросервисах

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

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

В статье автор рассказывает о способах управления данными в микросервисной архитектуре:
– Дублирование мастер-систем. Каждый сервис хранит и поддерживает данные независимо друг от друга
– API. Сервис, ответственный за данные, предоставляет доступ к данным по API другим сервисам
– DWH. Сервис, ответственный за данные, сливает их в единое хранилище, а другие сервисы имеют доступ к хранилищу
– Очереди. Сервис, ответственный за данные, публикует информацию обо всех изменениях в очередь. А другие сервисы, считывая данные из очереди, хранят на своей стороне и актуализируют.

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

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

#systemdesign

За что мы любим командную строку

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

На хабре мы написали лёгкую статью, где на примерах рассказали, за что мы любим командную строку. Профессиональный навык работы с командной строкой – один из шагов к 10х программисту.

Зачем разработчику нужен Linux вообще и терминал в частности

Эта статья существует! Вчерашний анонс из-за путешествий во времени вышел не вовремя. Так зачем вам терминал?
– легко поставить софт
– легко автоматизировать процессы
– легко вспомнить
– легко настроить под себя

легко…(злобный закадровый смешок)

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

#devfm #skills

Backup: подборка по базам

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

Практика
– Подробный гайд по работе с json в postgres
– Какой тип данных использовать для хранения строк в postgres
– Куда смотреть, если postgres начала тупить
– Базовые настройки Postgres
– Работа с NULL в Postgres
– Тестирование миграций alembic
– Сравниваем базы данных с помощью data-diff
– Временные интервалы в postgres
– Порядок имеет значение
– Утилита postgres_dba

Теория
– TOAST – проблемы откуда не ждали
– Индексы в PostgreSQL
– Буфферный кеш в PostgreSQL
– Этапы выполнения запросов в PostgreSQL
– ACID в PostgreSQL
–Понимаем EXPLAIN в PostgreSQL
– Миграции без даунтайма
– Храним данные по-разному, в зависимости от цели – создаем аналитическую базу
– Введение в Greenplum и пример реального использования
– Введение в Manticore и сравнение с Elastic
– Тернистый путь к ClickHouse
– Оптимизатор Join в Postgres
– Как мы боролись с Manticore
– Посмотрите на keydb
– TimescaleDB для хранения временных рядов

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

#backup

Типы кабелей

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

– силовые кабели
– витая пара и DAC-кабель. Какие категории кабелей бывают и как и что на это влияет: скорость передачи данных, экранирование
– оптика. Что за мода такая, что за сердцевина, какие бывают коннекторы

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

Путь от монолита к микросервисам

Лёгкая для понимания статья, проводящая грань между монолитом, микросервисным монолитом, микросервисами и так называемым оркестратором бизнес-сервисов (последнее – это какая-то ненаучная фантастика).

Каждый из вариантов имеет свои плюсы и свои недостатки, о которых говорит автор. Пожалуй, самое грустное – зависнуть на микросервисном монолите и словить все проблемы, какие только можно придумать.

Статья мне понравилось ещё тем, что по пути автор даёт ссылки на интересные материалы для погружения в тему. Например, о CirquitBreaker от Мартина Фаулера.

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

#systemdesign

Пятничное развлекательное

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

#fun

Retrying consumer in Kafka

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

Кафка не предоставляет возможность пропустить сообщение и вернуться к нему позже.

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

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

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

#skills

Мониторинг — боль

Интересное чтиво на тему мониторинга.

Казалось бы, логи и метрики облегчают жизнь, наблюдаемость системы растет, отладка становится проще. Или не совсем?

Автор проходится по основным моментам логирования и сбора метрик. Описывает боли, с которыми неоднократно сталкивался. Многое из написанного оказалось знакомо.

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

Отдельно автор останавливается на трассировке, как на недооценённом инструменте.

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

#skills #logging

Бесплатный курс "Командная строка для разработчиков"

Мы довольно давно готовим молодых python-разработчиков, и начинаем именно с базовых знаний в Linux, прививая желание и умение работать в терминале. Вдохновляясь курсом "Поколения Python" на степике, мы решили сделать свой бесплатный курс "Командная строка для разработчиков", посвящённый терминалу Ubuntu, языку bash и базовому администрированию. Начинающим разработчикам поможем преодолеть неловкость перед текстовым терминалом, опытным разработчикам покажем неочевидные и полезные в работе фишки для увеличения продуктивности.

Курс начинался с оффлайна, а переход в онлайн требует существенной переработки материала. Поэтому релизимся поэтапно, выпуская новые уроки по мере готовности.

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

#devfm