Понимание джойнов сломано

Если в гугле ввести "join sql" и перейти в раздел картинок, можно увидеть повсеместные диаграммы Венна, цель которых – визуально пояснить суть разных видов join-ов.

В своей статье автор делает сенсационное заявление и идёт против системы. Он пытается объяснить, почему использование таких понятных всем кружочков неправильно объясняет работу join-ов.

Считаем эту статья важной, так как, одной стороны, да, действительно, привычные кружочки дают наглядное представление о join-ах, но на практике важны детали, которые в кружочках опускаются.

Как говорится, критикуешь — предлагай, поэтому в следующей статье автор предлагает свой вариант визуализации join-ов. Не сказал бы, что предложенный вариант прям сильно наглядный, однако более точный.
#skills #database

Backup: декабрь. Топ постов за месяц

1. Читаем документацию на примере FastAPI
2. Подборка базовых материалов для python-разработчиков на 2022 год
3. Kubernetes в небольших проектах
4. Регулярные выражения в Python от простого к сложному
5. Ищем свой пароль в файле размером 37 Гб на Python. В комментариях разгорелась дискуссия, заменит ли ChatGPT джунов
6. Хватит пересылать пароли в открытом виде
7. FastAPI best practices
8. Идемпо… что? Улучшаем API
9. Зелёные потоки в Python
10. Давай-давай, пиши документацию

#backup

Топ постов за год 🔝

1. Делаем код мягким и шелковистым

2. Преодолеваем постоянное откладывание дел

3. Стрим по созданию небольшого проекта на gitlab с тестами

4. Зачем вам нужен докер?

5. Завышать ли опыт в резюме?

6. Как я научился воспринимать английский на слух

7. Что я увидел в своих собеседованиях

8. Корчеватель ломает науку

9. Какие знания нужны разработчику?

10. Вопросы для junior python developer

11. Зачем WSGI в Python?

12. Проектируем сервис: поиск организаций по картам

#backup

Вспоминая git

В статье Top 30 Git Commands You Should Know To Master Git CLI собран набор часто используемых команд для работы с гитом. Некоторые из них достаточно очевидные, но со списком точно стоит ознакомиться.

Мы на практике часто используем команды:
7. посмотреть лог коммитов с изменениями
9. просмотреть изменения перед коммитом
11. переименовать файлы
13. внести изменения в последний коммит
15. откатить произвольный коммит
20. просмотреть лог коммитов в виде графа
24. просмотреть подробности об удаленном репозитории: push url, fetch url, какие ветки есть, какая ветка head
29. удалить ветку в удалённом репозитории

Хочется обратить внимание на вредность второго пункта. Автор рассказывает о способе сохранения своих учетных данных. Но это неправильный путь. Правильный путь — работать с удаленным репозиторием, применяя ssh-ключи. Не парольный способ. И если вдруг не настроена двухфакторка — её тоже стоит прикрутить.

От себя хочется добавить ещё одну полезную команду git stash. А если столкнулись со сложным случаем, то мы рекомендуем использовать sublime merge.

В копилку часто используемых команд добавим создание локальной ветки из удалённой
git checkout -t origin/some-branch
#skills

Кажется, ваше приложение сейчас пятисотит

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

Работает ли само приложение?
Не упала ли база?
А все ли странички в веб-приложении доступны?
Не просрочился ли сертификат?

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

Простая, как дверь и достаточно многофункциональная штука для проверки статуса ваших приложений, то есть классический health check.

Можно реализовать специальные health check-ручки, а можно проверять любые доступные endpoints на возвращаемый статус, время ответа или конкретное содержимое body. Есть возможность следить в онлайне в дашбоарде, как на картинке. Можно складывать в базу и потом анализировать. Обо всех происшествиях можно настроить нотификации в телеграм и много куда ещё.

Функционал, конечно, намного шире, чем в нашем коротком описании. Поэтому стоит ознакомиться с документацией в ридми проекта. Читается легко и сразу становится понятно, как работать с этой махарайкой.
#skills

Принципы, которыми стоит руководствоваться

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

Эти принципы даются с высоты Solution Architect. Мы выделили принципы, применимые для любого специалиста и которые сами постоянно применяем на практике.

Идти нужно от проблемы
Если для проблемы есть типовое решение — применяйте его. Не нужно пытаться что-то изобретать и применять какую-то новомодную штуку.

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

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

Мы добавим, что не нужно пытаться продумать на 100 шагов вперед. Это внесёт излишнюю и ненужную сложность в систему, а когда требования кардинально поменяются (а они точно поменяются) окажется, что сложность накручена не там.

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

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

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

Многое, о чём говорит автор — знакомо и понятно. В статье есть еще несколько советов, а приятное изложение благоволит к прочтению :)
#sudo #edu

Авторизация через OAuth и OIDC

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

Иногда возникает необходимость самому реализовать авторизацию через сторонние сервисы (single sign-on). В каких-то случаях подобную функциональность из коробки предоставляет фреймворк, а вам нужно только правильно всё настроить. Но в задачах, связанных с безопасностью, важно знать, что происходит под капотом, и ничего не должно делаться на ощупь.

В замечательной статье An Illustrated Guide to OAuth and OpenID Connect по полочкам раскладывается эта тема. OAuth, OpenID Connect, кто на ком стоял, из каких шагов состоит и для чего каждый используется.

Также есть видео на понятном, неспешном английском.

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

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

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

Один день в неделю у нас "культурный код". Мы делимся интересным вне технических постов. Сегодня у нас "Жизнь" Конвея.

Это игра без игроков, созданная в 1970 году. Задаёшь начальное состояние и наблюдаешь. Правила просты:
— в каждой клетке либо есть жизнь, либо нет
— в пустой (мёртвой) клетке, с которой соседствуют три живые клетки, зарождается жизнь
— клетка живёт в компании 2-3 живых соседок. Если соседей меньше 2, то клетка умирает от одиночества. Если соседей больше 3, то клетка умирает от перенаселённости

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

Эрик Реймонд (автор Собор и базар) предложил сделать планер эмблемой хакеров.

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

#fun

Кино на выходные

Посмотрел тут Не беспокойся, дорогая (2022) с Оливией Уайлд в качестве актёра и режиссёра. Что же, рейтинг в 6.6 на кинопоиске и 5.9 на imdb — это ещё завышенная оценка. Абсолютно бездарный фильм с кучей ружей Бондарчука, когда показывают деталь типа зомби-танцовщиц, которая никак дальше не используется и не развивается. После просмотра совершенно не о чем подумать и нечего обсудить. Смотреть не рекомендую.

С теплом вспоминал Тринадцатый этаж (1999), о котором мы давненько писали в подборке интересных фильмов. Фильм не очень динамичный по современным меркам, но в нём схожие вопросы поднимаются куда глубже, чем в поделке 2022 года. Блин, по ощущениям, треть хронометража в "Не беспокойся" показывают процесс уборки дома. Увлекательнее смотреть, как растёт трава.

Посмотрите Тринадцатый этаж, он того стоит. Или те фильмы подборки, что ещё не видели.

#fun #films

ООП на простых примерах

В 40-минутном видео аккуратно объясняют три кита объектно-ориентированного программирования. Примеры даны на TypeScript, но понятны любому разработчику. Автор аккуратно иллюстрирует необходимость ООП, рассказывает про инкапсуляцию, наследование и полиморфизм. Покрыты даже относительно сложные вещи вроде параметрического и ad-hoc полиморфизма.

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

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

Про нюансы getattr и setattr в питоне мы делали отдельные посты.

#sudo #youtube #procode

Индексы в PostgreSQL

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

У нас уже был заход про EXPLAIN. Теперь перейдем к более серьезным вещам, которые нужны при работе с реляционными базами, в частности, PostgreSQL — индексы.

Первая статья из цикла знакомит с особенностями применения индексов в PostgreSQL. Эти знания помогут лучше понимать и обосновывать, для чего и когда использовать индексы.

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

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

На этой статье можно не останавливаться. Далее в цикле нас знакомят с нюансами использования конкретных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN и Bloom.

Многие практически значимые детали, приведенные в статьях часто спрашиваются на собеседовании разработчиков уровня middle.
#skills #database

БезТЗатый программист

В 24-минутном видео Михаил Флёнов (автор книги Linux глазами хакера и других) рассуждает о важности технического задания (ТЗ) в разработке. В видео полно занятных примеров из его карьеры. Особый интерес представляют истории о выкидывании ненужных фич — лучше кода может быть только его отсутствие. Самым дорогим в разработке оказывается функционал, которым никто не пользуется. Время и ресурсы потрачены, а проблемы бизнеса не решены.

По нашему опыту, техническое задание позволяет прийти к однозначному пониманию того, что нужно сделать разработчику и что получит в результате заказчик. Фрилансеру ТЗ позволяет оценить трудозатраты и соориентировать по срокам и стоимости. Кстати, сам процесс декомпозиции задач положительно влияет на точность оценки сроков разработки. Мы писали о нашем опыте отслеживания рабочего времени.

Не требуется делать ТЗ по ГОСТ или фиксировать его на годы вперёд. Можно прописывать user story и фиксировать их. Можно итеративно дополнять или корректировать ТЗ. Но важно, чтобы у всех сторон процесса создания продукта было общее понимание планов на разработку. С увеличением размера системы важность ТЗ возрастает.
#youtube #edu

Практика распила монолита

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

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

— контейнеризация и хранение контейнеров

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

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

— tracing, прослеживание пути запроса среди множества сервисов. Предлагаемое решение jaeger мы уже упоминали в отдельном посте про разухабистое логгирование

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

В статье приводятся не только теоретические выкладки, но и конкретные инструменты. Отдельно можно порекомендовать сервис, которым пользуется автор для выбора инструментов — Cloud Native Computing Foundation. Очень классная интерактивная и наглядная карта, где для различных задач собраны сервисы, решающие эти задачи.

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

Покоряем большие CSV

Классная практическая статья Working with large CSV files in Python from Scratch рассказывает о хитростях работы с большими CSV-файлами.

В статье рассматриваются примеры:
— подсчёт строк в большом файле. Для этого применяется mmap, который использует низкоуровневое API операционной системы. Это позволяет ускорить чтение большого файла. Сам mmap заслуживает отдельной статьи. В ней с примерами на питоне объясняется, откуда берётся ускорение, плюс другие интересности, в том числе уровня системных вызовов ядра

— разбиение большого файла на части, с которыми дальше удобнее работать

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

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

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

Например, вы знаете, что линуксовый sort --unique читает файл целиком в оперативную память? А для работы ему надо примерно в 2,5 раза больше памяти, чем весит исходный файл. То есть для сортировки файла в 10 гигов нужно около 25 гигов оперативной памяти. Решение этой проблемы заслуживает отдельного поста.
#python

Составляем документацию разработчика пошагово без диет и тренировок

Мы уже писали о своём опыте документирования проектов.

Теперь заход от больших ребят, в несколько другой плоскости.

Начинается статья с интересной блок-схемы, где отображены типичные вопросы по документации:
— Есть ли у вас документация?
— Актуальна ли она?
— Легко ли её найти?
— Читает ли её кто-то?
— В одном ли месте всё собрано?

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

Часто полезная информация разбросана по разным источникам. Как подключиться к инфре писали в общем чате, нюансы работы с сервисом написали в личку, R&D таки зафиксировали в конфлюенс. Поэтому на первом шаге рекомендуется собрать всё вместе.

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

Чтобы понять, о чём реально стоит писать, соберите обратную связь. Прошерстите чатики, комменты под инструкциями. Если часто спрашивают, как поменять конфиги там-то — отлично, именно об этом и стоит писать.

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

Стоит позаботиться также о читабельности. Тут все банально — на текст должно быть приятно смотреть. В статье на этот счёт есть конкретный набор советов.

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

И в заключение: с документацией, как с тестами. Не стоит думать, что, если проект не покрыт тестами, то и смысла писать их нет. Нужно просто начать покрывать тестами новый код и это уже будет хорошо. Если документация устаревшая или её вообще нет, начните с малого — начните писать её к новым разработкам.
#sudo #skills

Кино на выходные

Думаю, вы слышали о Стивене Хокинге. В 21 год ему поставили диагноз "боковой амиотрофический склероз" и предположили, что жить ему осталось 2.5 года. Болезнь прогрессировала, он перестал ходить, потом утратил возможность двигать руками. После воспаления лёгких он утратил способность говорить.

...В 2018 году он умер в возрасте 76 лет. Практически не имея возможности контактировать с окружающим миром, он вёл исследования, писал книги, выступал и даже летал в невесомости.

К просмотру рекомендуется фильм Вселенная Стивена Хокинга (2014) и одна из его книг, Краткая история времени.

#fun #films #books

Проектируем систему — System Design

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

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

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

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

Этапы выполнения запросов в PostgreSQL

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

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

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

Как итог: чтиво направлено больше на понимание кишочков, но менее захватывающим от этого не становится.

Статья является первой из цикла. Далее автор освещает использование статистики, индексное и последовательное сканирования, соединение вложенным циклом или хешированием. Всё это приблизит к глубокому пониманию того, как выполняются запросы в PostgreSQL.
#skills #database

Python import: Advanced Techniques and Tips

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

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

— import path и порядок поиска модулей

— создании своего пакета для PyPI. Классический setup.py, плюс установка изменяемого пакета для удобной разработки без необходимости переустановки. Интересным дополнением является включение ресурсов или данных в пакет на примере иконок для GUI-приложения

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

— перезагрузку модулей. Проблема в том, что повторный импорт не приводит к перечитыванию модуля, по факту используется старая версия. Для перезагрузки модуля надо использовать importlib.reload. Этот и предыдущий пункты позволяют вместе организовать динамические плагины в проекте

— работу с разными модулями в зависимости от доступности библиотек или версии интерпретатора. Это позволяет применять разные библиотеки. Нет bokeh для визуализации? Используем matplotlib. Не все фичи будут доступны, но будет работать

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

Заход на правильную организацию импортов был в посте об анализаторах кода.
#python

Жизненная история

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

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

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

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

Пока происходили все эти события, бизнес вырос в пять раз. Монолит переехал на микросервисы. Инфраструктуру перенесли в kubernetes, что позволило создать распределённое отказоустойчивое решение в трёх дата-центрах.

Автор выделяет следующие преимущества kubernetes:
— канареечные выкаты, позволяющие производить A/B-тестирование
— деплой без даунтайма
— балансировка нагрузки
— горизонтальное автомасштабирование
— интеграция запуска тестов в CI с различными хитрыми конфигурациями
#skills

Частичное клонирование репозитория

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

В git есть возможность частично клонировать репозиторий (partial clone). В статье рассматриваются разные способы частичного клонирования. Каждый раз мы выбираем, какие объекты клонировать не нужно.
— blobless clone не клонирует blob объекты
— treeless clone не клонирует директории
— shallow clone — самый минималистичный вариант. С помощью параметра depth можно выбирать глубину клонирования истории, например, только последний коммит.

По каждому из пунктов автор приводит наглядные картинки и рассматривает особенности применения других команд при partial clone.

Для работы с ограниченной рабочей копией есть интересная команда sparse-checkout. На github более подробная статья с примерами применения этой команды.
#skills