Ребята из SQL-чатика проводят онлайн-встречу 12 мая в 19.00. Темы:
– о работе
– как войти в айти
– софт скиллы
– технические вопросы
– о том, что спрашивают на собеседованиях

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

Ссылка в зум на встречу. Любые вопросы можно уточнить в чате.

Domain Driven Design

Domain Driven Design (DDD) – на первый взгляд, что-то такое сложное. Да и на второй тоже сложное. Не очень понятно, с чего начинать.

Начать можно со статьи Domain-driven design: рецепт для прагматика.

Автор на примерах проходится по основным концептам DDD:
– ubiquitous language – всё обсуждение происходит в терминах единого языка
– domain model – некий набор сущностей и сценариев, связанных с предметной областью
– bounded context – некие рамочки, в которых существует доменная модель и единый язык

Основная идея DDD – борьба со сложностью бизнес-процессов, их автоматизации и реализации в коде. Domain – предметная область и от неё нужно отталкиваться при проектировании и разработке.
Бороться со сложностью – звучит многообещающе, но "прежде чем начать бороться со сложностью с помощью Domain-Driven Design, нужно научиться бороться со сложностью самого Domain-Driven Design".

Не факт, что будете применять, но знать что это за зверь – стоит. К тому же, можно перенять некоторые полезные практики, например, ubiquitous languge – единый язык общения. На эту тему написан занимательный комментарий, что пример, приведённый в статье из мира продаж всем понятен, тривиален и нет смысла для него составлять ubiquitous languge. На что ему приводят такие термины из мира продаж: ретроскидка, скидка по фактуре, ценовое соглашение, отличное от базового и др. Кажется, не всем понятно. Это я к тому, что использование ubiquitous languge в любой области облегчит взаимодействие.

Можете посоветовать что-то толковое на тему DDD?

#skills

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

Хочется порекомендовать очень классный бесплатный курс на Coursera – Learning How to Learn. Название говорит само за себя. Курс имеет почти 90 тысяч рецензий с общим рейтингом 4.8.

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

Курс лёгкий для освоения, поэтому можно смотреть, не напрягаясь.

#fun #edu

Приоритизация технического долга

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

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

— Если мы ничего не будем предпринимать, усугубится ли проблема, или всё в целом останется на прежнем уровне, или вообще всё будет двигаться в сторону улучшения?

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

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

#procode

Пост о DDD зашёл хорошо. Но всё-таки с чего начать? Классические книги по этой теме могут не зайти с первого раза. Для погружения в тему и отслеживания, что происходит в мире DDD рекомендуем канал DDDevotion.

Backup: апрель

Архитектура проекта
Межсервисное взаимодействие
Выбор брокера сообщений
DDD – Domain Driven Design

О программировании
Вариантность типов
Приоритизация технического долга
Асинхронность в браузере

Базы данных
Postgres – как хранить строки?
Работа с json в PostgreSQL

Инструменты
Рисуем схемы
VPN — не панацея

Софтскиллы
Биология поведения человека и лекция о депрессии
Курс Learning How to Learn

В этом месяце мы отметили три года. Если пропустили, то подборка за март.

#backup

Load balancing

Прочитал на одном дыхании замечательную статью о балансировке нагрузки (load balancing).

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

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

Автор рассматривает:
– алгоритм round robin, когда запросы отправляются на сервера по кругу. Этот алгоритм не учитывает, что сервера могут иметь разную мощность. Тогда более мощные сервера будут быстро обрабатывать запросы, а менее мощные могут загибаться и давать отлупы.

– алгоритм dynamic weighted round robin учитывает мощность серверов. На основе среднего времени ответа им динамически устанавливаются веса. И, в зависимости от весов, будет автоматически варьироваться количество запросов.

– алгоритм least connection учитывает количество подключений, поддерживаемых серверами в текущий момент времени. Запрос будет передан серверу с наименьшим количеством активных подключений.

– алгоритм peak exponentially weighted moving average (PEWMA) направлен на уменьшение задержек в запросах. По сути, сочетает в себе dynamic weighted round robin, least connection и немного магии сверху.

Каждый из описанных алгоритмов сопровождается красивой и понятной анимацией. А в конце статьи можно поиграться с наглядным симулятором каждого из методов.

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

#skills

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

Настало время моего любимого фильма Город грехов (2005). Четыре новеллы с интересными переплетениями между собой. Каждый фрагмент захватывает своими персонажами, вызывая сопереживание.

Старик умирает... Девочка остается жить. Честный обмен

Фильм в жарне нуара, где во главе угла атмосфера пессимизма, недоверия, разочарования и цинизма. Мы говорили про игру Max Payne и фильм Бегущий по лезвию в этой стилистике.

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

#films

Zero-Downtime Deployments with Docker Compose

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

Нашли свеженькую статью, где автор реализует blue-green деплоймент без даунтайма с применением docker compose.

Из приятного – автор пользуется полюбившимся многим traefik вместо nginx. Также в процессе знакомства можно кое-что новое узнать о композе. Из не очень приятного – bash всё ещё активно применяется.

Всё описанное можно потрогать, исходники выложены на github.

#skills

Пагинируем по-всякому

Занимательная статья, посвящённая способам реализации пагинации.

Достаточно частая задача – отдавать что-то порционно. В зависимости от потребностей, нужно применять разные способы пагинации.

Помимо классического page-based pagination автор рассматривает KeySet-based pagination и Cursor-based pagination. Также рассматриваются плюсы и минусы каждого из способов.

В конце приводятся примеры, как реализована пагинация у больших ребят: Stripe, Shopify, Github.

#skills

О производительности Postgres

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

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

– логировать медленные запросы – можно настроить логирование запросов, которые выполнялись дольше заданного времени. В ту же сторону – логировать EXPLAIN-планы медленных запросов

– автоматически убивать запросы, которые очень долго выполняются

#database

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

Не очень профильно, но очень полезно. Неоднократно бывало такое, что нужно выбрать лампочку, а какую конкретно непонятно. Вроде смотришь на всякие показатели, вроде даже что-то понятно, но что выбрать из сотни лампочек – хз.

Есть прекрасный проверенный ресурс для этих целей – lamptest. Ребята конкретно заморачиваются, проверяют множество показателей и даже ведут блог на хабре.

У них еще есть похожий проект batterytest, где они тестируют элементы питания.

UPD: оказывается и в тг есть канальчик.

#edu

Как работает ChatGPT

Несколько лёгких статей, посвященных языковым моделям.

В первой ребята рассказывают историю языковых моделей, и как мы дошли от T9 до чатЖПТ.

Вторая статья посвящена исключительно GPT4. В чём отличия от предшественников, где применять на практике, как добавили работу с картинками. И ещё много всего интересного.

На фоне всех переживаний: абы чего плохого не вышло — третья статья, где размышляют и пытаются разобраться, стоит ли напрягаться и ожидать восстания машин.

Все статьи читаются на одном дыхании. Для особо любопытствующих в тексте много ссылок на другие исследования.

Ещё хочется поделиться одной статьей What Is ChatGPT Doing … and Why Does It Work? от Стивена Вольфрама. Более вдумчивое чтиво, с примерами и объяснениями, как оно устроено изнутри. Из приятного — все примеры можно позапускать.

О доступе к ChatGPT и наших примерах применения мы писали.

#skills

Как проектировать микросервисы

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

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

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

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

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

#skills

Кеширование на бекенде

Вводная статья, посвященная кешированию на бекенде, затрагивающая много интересных моментов.

Автор проходится по основным концептам:
– Для чего нужно кеширование, что нужно кешировать, по каким метрикам оценивать работу кеша

– Стратегии работы с кешем. Сквозное кеширование, когда все запросы проходят через кеш. Кеширование на стороне, когда само приложение координирует запросы в кеш или бд. Опережающее кеширование (только для чтения), когда приложение работает только с кешом, и кеш периодически синхронизируется с бд

– Всегда актуальный вопрос – стратегии инвалидации кеша. Jitter, чтобы не протухало всё разом. Схлопывание запросов в один, когда протухла запись, которую очень интенсивно используют

– Кеширование ошибок – полезный прием. Если знаем, что в бд нет определенных данных, так зачем каждый раз продолжать долбиться в бд. Можно закеширвать ошибку. Есть даже специальная схема атаки – cache miss attack

О кешировании у нас уже был пост Design distributed cache.

#skills

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

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

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

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

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

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

#edu

Попробуйте HTMX

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

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

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

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

#skills #frontend

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

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

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

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

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

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

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

#python #procode

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

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

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

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

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

#fun #books