2128
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
За что мы любим командную строку
В повседневной деятельности мы активно применяем командную строку. Иногда слышим вопросы о том, зачем это вообще нужно, вроде и без неё все хорошо? Этот вопрос вполне логичен, если не погружался в эту тему, не пытался решать реальные задачи.
На хабре мы написали лёгкую статью, где на примерах рассказали, за что мы любим командную строку. Профессиональный навык работы с командной строкой – один из шагов к 10х программисту.
Попробуйте ruff
Ранее мы рассказывали о целом наборе линтеров, которые постоянно применяем в своих проектах.
Недавно обратили внимание на достаточно молодой и интересный линтер для python – ruff. Он объединяет в себе правила многих других линтеров – по сути всех, которые используем.
Мы уже сделали для себя конфиг и испробовали его на одном из сервисов. Полёт нормальный, ощущения только положительные.
Из плюсов:
– ощутимая скорость. Линтеры у нас прогоняются с помощью pre-commit на каждом коммите, поэтому скорость имеет значение. Пару раз даже ловил себя на мысли, что не делаю лишний коммит, чтобы не ждать прогона линтеров. А ruff отрабатывает практически моментально
– в pre-commit не нужно держать целый зоопарк линтеров. Достаточно один раз сконфигурировать и подключить ruff
Так что категорически рекомендую попробовать. У них, кстати, есть playground для этих целей.
#python
Пятничное развлекательное
Мы уже говорили о Роберте Сапольски. Хочется порекомендовать ещё одну захватывающую лекцию. На этот раз о религии. Просто послушайте и делайте выводы сами.
А кто хочет лёгкого и интересного чтения обратите внимание на его книгу о жизни и работе в Африке – Записки примата. Необычайная жизнь ученого среди павианов. Путешествия по континенту, исследование влияния стресса на другие биологические показатели, быт местных племен.
#fun #books
Работа с памятью
На практике редко приходится работать с памятью напрямую, но под капотом компьютер шуршит шестерёнками — выделяет и освобождает память.
Познавательная статья с очень качественной визуализацией, посвящённая основам работы с памятью.
Автор рассказывает базовые концепции, как выделяется и как освобождается память, затрагивает проблему фрагментации, утечки памяти, и другие причины полнейших крахов, от которых мы не защищены.
#skills
Пятничное развлекательное
Наверно, почти все слышали о замечательной книге "Вы, конечно, шутите, мистер Фейнман!", но она точно заслуживает ещё одного упоминания.
Увлекательная автобиография известного физика, лауреата Нобелевской премии – Ричарда Фейнмана. Как думал, как работал этот выдающийся человек. Помимо этого в книге рассказывается множество интересных историй и смешных случаев из жизни.
Эта книга вдохновляет и мотивирует на новые свершения.
Если еще не читали – обязательно прочтите.
#fun #books
Нужен совет сообщества. У нас всё острее встаёт вопрос документирования сервисов. Конечно, у каждого сервиса есть свой сваггер, к методам написаны докстринги, в ридми есть описание работы сервиса и его архитектуры. Но всё это лежит в разных местах. Хочется красивенько и удобненько собрать всё вместе.
Из хотелок:
– для всего многообразия единый веб-интерфейс: архитектурные описания сервисов из readme, openapi спецификация, общее описание архитектуры из конфлюенса.
– было бы классно понимать пересечения http-ручек, когда в случае вызова одной по цепочке вызывается другая
Есть концептуальное понимание, что должно быть что-то, что периодически собирает всю информацию из разных источников, приводит к единому виду и строит статическую веб-страницу.
Расскажите, как решаете вопрос с документацией, что документируете? Какие технологии стоит использовать?
Пятничное развлекательное
Нашёл тут в своих давних заметках лёгкую, но полезную статью от Сергея Абдульманова. Статья небольшая, но даже сейчас помню своё ощущение после прочтения: ого, сколько интересностей!
Название статьи говорящее — Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло, но там не только об этом.
После прочтения вы наверняка не начнете проводить "офигенно длинные собрания", но точно почерпнёте набор того, что важно для полезной, качественной встречи. Мне очень понравилась мысль, что на встрече должно быть минимально достаточное количество людей для принятия решения. Чтобы не приходилось с ним бегать наверх для одобрения. Кстати, о том как этого добиться, есть отдельная статья.
В статье хорошо демонстрируется важность единой терминологии. По сути — один из аспектов DDD, о котором писали раньше. Простой термин, но как он может по-разному интерпретироваться. Например, "наличие". Для закупки «есть в наличии» — это хотя бы один товар в любом одном магазине в России. Для розницы — есть в большинстве магазинов хотя бы один товар. Для организации акций — есть хотя бы 5 штук в большинстве магазинов.
И ещё один вроде простой, но супер важный практический совет — никогда не нужно начинать сразу с решения. Всегда начинайте с проблемы. В статье этот тезис объясняется на двух запоминающихся примерах. Из опыта скажу, что легко скатиться сразу к обсуждению решения, не выяснив толком проблему. Поэтому с тех пор тщательно отслеживаю этот момент.
#edu
Как проектировать микросервисы
Нет универсального алгоритма, где сказано как проектировать микросервисы и правильно разделять зоны ответственности. Обычно этот навык нарабатывается с опытом и всё равно каждый раз думаешь, сомневаешься.
Когда только начинаешь смотреть в эту сторону хочется иметь хотя бы вектор. В статье автор даёт вполне адекватный алгоритм действия, который можно использовать при проектировании.
Важно, что в своих размышлениях автор старается учитывать изменчивость или неточность бизнес требований. Например, сразу неизвестно, какие способы авторизации будут нужны в будущем, или какой способ приёма платежей будет использоваться, кроме заявленного заказчиком на данный момент.
В целом, стоит критически смотреть на подобные статьи. Автор действительно даёт некий алгоритм, но опускает многие детали и вопросы, которые предстоит решать после такой декомпозиции. А именно в деталях обычно скрываются самые большие сложности и нежданчики.
И ещё небольшое примечание от нашей редакции. Когда что-то изучаете на тему микросервисной архитектуры, не цепляйтесь за "микро". Сервисы могут быть абсолютно разного размера в зависимости от конкретной задачи. Не нужно плодить сущности только потому, что в каноническом названии архитектуры есть приписка "микро".
#skills
Пятничное развлекательное
Не очень профильно, но очень полезно. Неоднократно бывало такое, что нужно выбрать лампочку, а какую конкретно непонятно. Вроде смотришь на всякие показатели, вроде даже что-то понятно, но что выбрать из сотни лампочек – хз.
Есть прекрасный проверенный ресурс для этих целей – lamptest. Ребята конкретно заморачиваются, проверяют множество показателей и даже ведут блог на хабре.
У них еще есть похожий проект batterytest, где они тестируют элементы питания.
UPD: оказывается и в тг есть канальчик.
#edu
Пагинируем по-всякому
Занимательная статья, посвящённая способам реализации пагинации.
Достаточно частая задача – отдавать что-то порционно. В зависимости от потребностей, нужно применять разные способы пагинации.
Помимо классического page-based pagination автор рассматривает KeySet-based pagination и Cursor-based pagination. Также рассматриваются плюсы и минусы каждого из способов.
В конце приводятся примеры, как реализована пагинация у больших ребят: Stripe, Shopify, Github.
#skills
Пятничное развлекательное
Настало время моего любимого фильма Город грехов (2005). Четыре новеллы с интересными переплетениями между собой. Каждый фрагмент захватывает своими персонажами, вызывая сопереживание.
Старик умирает... Девочка остается жить. Честный обмен
Фильм в жарне нуара, где во главе угла атмосфера пессимизма, недоверия, разочарования и цинизма. Мы говорили про игру Max Payne и фильм Бегущий по лезвию в этой стилистике.
Рекомендую к просмотру. Продолжение 2014 кода мне нравится куда меньше, но атмосферу фильм смог сохранить. Рад был видеть Кристофера Ллойда, хоть и в эпизоде. Кто не знает, это Док из трилогии Назад в будущее.
#films
Backup: апрель
Архитектура проекта
Межсервисное взаимодействие
Выбор брокера сообщений
DDD – Domain Driven Design
О программировании
Вариантность типов
Приоритизация технического долга
Асинхронность в браузере
Базы данных
Postgres – как хранить строки?
Работа с json в PostgreSQL
Инструменты
Рисуем схемы
VPN — не панацея
Софтскиллы
Биология поведения человека и лекция о депрессии
Курс Learning How to Learn
В этом месяце мы отметили три года. Если пропустили, то подборка за март.
#backup
Приоритизация технического долга
Технический долг штука хитрая, сначала незаметная. Но в какой-то момент начинает влиять на производительность системы и эффективность разработки.
И вроде всё просто — бери и исправляй. Но когда система разрастается, а бизнес требует новый функционал, появляются вопросики. За что хвататься? Всё явно не успеем, но забивать нельзя, потихоньку нужно закрывать долги.
В статье автор размышляет о приоритизации технического долга. На практике сводится к тому, что нужно ответить на два вопроса:
— Если мы ничего не будем предпринимать, усугубится ли проблема, или всё в целом останется на прежнем уровне, или вообще всё будет двигаться в сторону улучшения?
— Проблема относится к той части системы, которая активно развивается и используется или находится просто на обслуживании?
Ответив по каждой проблеме на эти вопросы, можно более осознанно приоритизировать свой технический долг.
#procode
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
Три года DevFM
Мы создали этот канал 25 апреля 2020 года. Начинался он как инициатива двух друзей, которые делились контентом "для своих". Когда в десятый раз с кем-то поделился одним и тем же интересным материалом, возникло желание такой материал систематизировать и опубликовать. Первые посты не теряют актуальности:
– Как правильно постоянно ботать
– Паттерны проектирования
– Первое пятничное развлекательное – история xkcd
– Качественные публичные выступления для студентов
– О важности предсказуемости
– Не строй велосипед, переиспользуй
– Как изучать предметную область перед стартом проекта
А год назад мы основательно взялись за канал и с тех пор не сбавляем темп. Также иногда пишем видео для ютуба, например, Идеальный скрипт на bash и статьи для Пикабу, которые выходят за формат поста тут. Недавно мы вышли на Хабр со статьёй по реверсу, и набрали почти 50 плюсов и две сотни закладок.
В закреплённом посте у нас есть навигация по каналу с продуманной системой тегов.
В этом году мы планируем ещё больше и ещё круче. А вам спасибо за интерес, спасибо, что читаете. Хотелось бы узнать подробнее о вас. Чем вы занимаетесь и как долго? Два небольших опроса в следующих постах
#ToTheMoon
Управление данными в микросервисах
В микросервисной архитектуре у каждого сервиса обычно своя база данных. Для организации доступа одного сервиса к данным другого сервиса нужно либо каждый раз делать запрос к сервису, ответственному за данные, либо иметь копию нужных данных. И тут важен баланс.
Например, у нас есть сервис, который хранит и обслуживает актуальный справочник городов. А навигационный сервис предоставляет информацию о маршрутах общественного транспорта в выбранном городе. Как правильно организовать доступ навигационного сервиса к справочнику городов?
В статье автор рассказывает о способах управления данными в микросервисной архитектуре:
– Дублирование мастер-систем. Каждый сервис хранит и поддерживает данные независимо друг от друга
– API. Сервис, ответственный за данные, предоставляет доступ к данным по API другим сервисам
– DWH. Сервис, ответственный за данные, сливает их в единое хранилище, а другие сервисы имеют доступ к хранилищу
– Очереди. Сервис, ответственный за данные, публикует информацию обо всех изменениях в очередь. А другие сервисы, считывая данные из очереди, хранят на своей стороне и актуализируют.
По каждому способу автор рассказывает о достоинствах и недостатках. Подробнее останавливается на последнем, как на наиболее интересном, и рассказывает о нюансах реализации.
Способ через очереди мне особенно нравится тем, что позволяет делать сервисы более независимыми, хотя он, конечно, более трудозатратный.
#systemdesign
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
Сам читаю недавно, но уже хочется посоветовать живой и приятный канал Николая Хитрова о разработке на python.
Автор пишет много практических постов о разработке, например, пост о логировании или какие нюансики стоит знать, внедряя loguru. Периодически поток информации разбавляется юмором. А ещё узнал из этого канала об интересной такой утилите deptry.
TOAST – проблемы откуда не ждали
Для хранения длинных записей в Postgres используется механизм TOAST.
Колонки с длинными значениями не хранятся в самой таблице. Если значение больше 2 Кб, то данные разбиваются на чанки и отправляются в связные тост-таблицы, скрытые от пользователя. А в исходной таблице хранится специальный указатель на чанки в тост-таблице.
И нам этом можно было бы и закончить. Просто интересный факт, связанный с особенностью хранения данных.
Но есть нюансы. Отметим практически значимые.
– В тост-таблице не может быть больше, чем 2^32 значений, то есть можно просто упереться в верхнее значение
– TOAST не поддерживает UPDATE. То есть каждая операция обновления вашего большого JSON приводит к INSERT в тост-таблицу и её распуханию.
– Независимо сколько в вашей таблице колонок, тост-таблица всегда одна.
Но дело не только в количестве значений в тост-таблице. Сам механизм накладывает определенные издержки.
JSON в Postgres уже давно не в новинку и активно используется. И, как правило, обсуждения проблем TOAST крутятся именно вокруг JSON полей.
В первой части статьи на конкретных примерах показывают, как резко и, на первый взгляд, беспричинно может упасть производительность и увеличиться WAL из-за TOAST.
Во второй же рассказывают, как оптимизировали JSON, чтобы повысить его производительность и уменьшить влияние TOAST. Также дают пару советов: всегда использовать JSONB и никогда не хранить в нём ID.
А для желающих по хардкору погрузиться в кишочки ещё одна статья. Автор закатывает рукава и лезет вглубь TOAST, рассказывает алгоритм его работы и предлагает конкретный подход с бенчмарками для улучшения самого TOAST.
#skills #database
Асинхронное взаимодействие сервисов с применением Kafka
Практическая статья, демонстрирующая, как организовать асинхронное взаимодействие сервисов на Python с использованием Kafka. Автор коротенько даёт вводные, описывает архитектуру и переходит к делу.
У нас были посты для более глубокого погружения в Kafka. Например, тут в одной статье рассказывают самые основы, в другой разбирают неочевидные проблемы, возникающие на практике.
#python #procode
Попробуйте HTMX
Если у вас несложный фронтенд и не хочется погружаться в дебри развесистых фронтенд фреймворков – посмотрите на htmx. Очень интересная штуковина. Никакого javascript и сложной логики на фронте. Берем в руки html и вперёд.
Обзорная статья, где автор делится позитивным опытом использования htmx.
А тут можно посмотреть примеры использования htmx с вашим любимым языком программирования. Питонистам будет интересен вот такой свежий проектик.
Всё думал, где об этом написать. Но раз уж пост почти про фронтенд, то вот интересный материал, в котором собраны базовые правила по дизайну интерфейсов. На понятных примерах автор показывает, как делать правильно и почему именно так.
#skills #frontend
Кеширование на бекенде
Вводная статья, посвященная кешированию на бекенде, затрагивающая много интересных моментов.
Автор проходится по основным концептам:
– Для чего нужно кеширование, что нужно кешировать, по каким метрикам оценивать работу кеша
– Стратегии работы с кешем. Сквозное кеширование, когда все запросы проходят через кеш. Кеширование на стороне, когда само приложение координирует запросы в кеш или бд. Опережающее кеширование (только для чтения), когда приложение работает только с кешом, и кеш периодически синхронизируется с бд
– Всегда актуальный вопрос – стратегии инвалидации кеша. Jitter, чтобы не протухало всё разом. Схлопывание запросов в один, когда протухла запись, которую очень интенсивно используют
– Кеширование ошибок – полезный прием. Если знаем, что в бд нет определенных данных, так зачем каждый раз продолжать долбиться в бд. Можно закеширвать ошибку. Есть даже специальная схема атаки – cache miss attack
О кешировании у нас уже был пост Design distributed cache.
#skills
Как работает ChatGPT
Несколько лёгких статей, посвященных языковым моделям.
В первой ребята рассказывают историю языковых моделей, и как мы дошли от T9 до чатЖПТ.
Вторая статья посвящена исключительно GPT4. В чём отличия от предшественников, где применять на практике, как добавили работу с картинками. И ещё много всего интересного.
На фоне всех переживаний: абы чего плохого не вышло — третья статья, где размышляют и пытаются разобраться, стоит ли напрягаться и ожидать восстания машин.
Все статьи читаются на одном дыхании. Для особо любопытствующих в тексте много ссылок на другие исследования.
Ещё хочется поделиться одной статьей What Is ChatGPT Doing … and Why Does It Work? от Стивена Вольфрама. Более вдумчивое чтиво, с примерами и объяснениями, как оно устроено изнутри. Из приятного — все примеры можно позапускать.
О доступе к ChatGPT и наших примерах применения мы писали.
#skills
О производительности Postgres
Кто о чём, а мы о postgres. Небольшая, но полезная заметка о некоторых базовых настройках, которые помогут, когда дело дойдёт до исследования производительности базы.
– использовать расширение pg_stat_statements – такая штука, которая собирает полезную информацию о запросах к БД. Например, можно узнать, какие запросы самые долгие, какие в сумме по времени дольше всего выполнялись, какие выполнялись чаще всего
– логировать медленные запросы – можно настроить логирование запросов, которые выполнялись дольше заданного времени. В ту же сторону – логировать EXPLAIN-планы медленных запросов
– автоматически убивать запросы, которые очень долго выполняются
#database
Zero-Downtime Deployments with Docker Compose
У нас был пост, посвященный стратегиям деплоя приложений. Но во всех практических примерах использовался кубер. Для многих задач это стрельба из пушки по воробьям, и в комментах спрашивали, есть ли что-то подобное, только без использования кубера.
Нашли свеженькую статью, где автор реализует blue-green деплоймент без даунтайма с применением docker compose.
Из приятного – автор пользуется полюбившимся многим traefik вместо nginx. Также в процессе знакомства можно кое-что новое узнать о композе. Из не очень приятного – bash всё ещё активно применяется.
Всё описанное можно потрогать, исходники выложены на github.
#skills
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
Пост о DDD зашёл хорошо. Но всё-таки с чего начать? Классические книги по этой теме могут не зайти с первого раза. Для погружения в тему и отслеживания, что происходит в мире DDD рекомендуем канал DDDevotion.
Читать полностью…
Пятничное развлекательное
Хочется порекомендовать очень классный бесплатный курс на Coursera – Learning How to Learn. Название говорит само за себя. Курс имеет почти 90 тысяч рецензий с общим рейтингом 4.8.
Пересматривал его дважды. Помогает структурировать в целом известные факты о постижении новой информации. Рассказывают о том, как работает мозг и различных техниках освоения нового. Также выступают ученые, занимающиеся исследованиями в этой области. Они рассказывают, почему оно работает именно так.
Курс лёгкий для освоения, поэтому можно смотреть, не напрягаясь.
#fun #edu
Ребята из SQL-чатика проводят онлайн-встречу 12 мая в 19.00. Темы:
– о работе
– как войти в айти
– софт скиллы
– технические вопросы
– о том, что спрашивают на собеседованиях
Вопросы, которые хочется обсудить можно оставить в гугл-форме.
Ссылка в зум на встречу. Любые вопросы можно уточнить в чате.
VPN — не панацея
Цикл удачных статей на горячую тему обхода блокировок в сети.
В первой статье автор рассказывает о том, как можно выявлять попытки обхода блокировок. Если у вас настроен VPN или прокси, не стоит расслабляться – их можно выявить и заблокировать. В статье автор приводит подобные примеры из реальной жизни.
Вторая статья рассказывает, что всё не так уж и плохо. Всё-таки есть технологии обхода блокировок, которые пока не детектируются (хотя наверняка в эту сторону идут активные исследования). Автор рассматривает такие технологии как: V2Ray, XRay, XTLS, Hysteria, Cloak. Статья больше теоретическая, но неплохо так расширяет кругозор.
А кому хочется потрогать, что было описано ранее и иметь запасной вариант выхода в мир, есть еще две чисто практические статьи: Обход блокировок: настройка сервера XRay для Shadowsocks-2022 и VLESS с XTLS, Websockets и фейковым веб-сайтом и Программы-клиенты для протоколов недетектируемого обхода блокировок сайтов: V2Ray/XRay, Clash, Sing-Box, и другие.
Порядок чтения не столь важен, можно начинать с любой заинтересовавшей.
#security