Behavior Driven Development

BDD — методология разработки "через поведение". Серия статей по BDD позволит достаточно глубоко разобраться в теме.

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

У автора есть также более прикладная статья — применение BDD на питоне, где можно посмотреть практические аспекты.

А закончить стоит примером настоящего проекта, где применяется BDD. Ребята уже давно разрабатывают консольный task manager (пример BDD тестов). Код несложный, можно достаточно быстро разобраться что к чему.
#python

Хватит пересылать пароли в открытом виде

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

Поэтому хочу посоветовать классный сервис SafeSecret.
Работает следующим образом:
1) Вводите чувствительную информацию, например пароль.
2) Задаете время, в течении которого можно получить доступ к информации.
3) Придумываете пин-код.
4) Получаете ссылку, которой можно поделиться.

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

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

А для изучающих язык программирования go — это замечательный пример хорошего проекта, код которого стоит изучить.
#skills #security

15 тривиальных фактов о правильной работе с протоколом HTTP

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

Из интересного, о чём рассказывает автор:
— основы работы с http методами
— кешируемые/не кешируемые методы
— идемпотентные/не идемпотентные методы
— коды возвратов и некоторые нюансы при их формировании
— capability URL ("секретные" ссылки) и как их готовить

И ещё момент: нюансы из статьи часто спрашивают на собеседовании.

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

FastAPI best practices

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

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

Из не совсем очевидного и полезного можно отметить:
— 8 п. глобальная Base Model с нужным конфигом
— 9 п. правильная генерация документации для сваггера и отключение ее на проде
— 12 п. настройка шаблонных и человекочитаемых имен для миграций
— 21 п. использование ValueError в своих кастомных пидантик валидаторах

Что стоит принять к сведению:
— 18 п. при использовании union в пидантике нужно быть уверенным, что валидатор знает разницу между типами
— 22 п. не забывать, как именно и в каком порядке Fast API работает с объектами пидантика и контроллера
— 13 п. соблюдать единые правила для именования сущностей базы данных
#python

Программа vs процесс vs поток

В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством. Пара слов сказана и о корутинах / зелёных потоках. Про зелёные потоки будет отдельный пост.

Для более вдумчивого чтения про процессы и потоки можем порекомендовать 2 главу Современные операционные системы Таненбаума (4 издание, 2015 год).
#skills

Идемпо… что? Улучшаем API

Когда писал пост про работу с HTTP, обнаружил непростительную оплошность. Мы ни разу не рассказывали о такой супер важной штуке, как идемпотентность API.

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

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

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

Из-за затупа с базой пользователь дважды нажал кнопку Заказать и приехало две машины.
Что ж, на фронте начали блокировать кнопку Заказать, пока не придет ответ с сервера.

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

Проблема решена, можно заканчивать статью. А потом тарам-пам-пам... классика. Менеджер изменил бизнес требования и старое решение уже не подходит.

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

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

Зелёные потоки в Python

Переключение между потоками — процесс очень затратный по времени, как мы уже разбирали. Для решения этой проблемы были придуманы зелёные потоки (green threads, они же coroutines или корутины), у которых вместо честного переключения потоков операционной системой реализуется виртуальное переключение потоков в пользовательском пространстве. Для IO-bound задач, где бутылочным горлышком являются медленные операции ввода-вывода, в том числе сетевого, зелёные потоки являются спасением. Для CPU-bound задач, где надо много физически вычислять на процессоре и нет простоев зелёные потоки не нужны.

Предлагаем прочитать статью Асинхронный python без головной боли (часть вторая). Начинается статья с наглядного примера асинхронности из жизни. Часто у начинающих разработчиков можно наблюдать ошибку, когда вместо подписки на событие, например, изменения файла, реализуется "жужжалка", которая в бесконечном цикле дёргает метаданные файла, загружая CPU на 100%.

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

Во второй части речь про event loop, про пример с API gateway, дополнение сервиса погоды переводчиком, асинхронным логгированием и базой.
#python

Практичный SSH (с картинками)

Статья A visual guide to SSH tunnels (перевод) рассказывает о практическом применении SSH-туннелей в различных интересных конфигурациях. О базовом устройстве SSH под капотом мы писали ранее.

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

Если вам нужно:
– получить доступ к удалённому ресурсу, размещенному в частной сети

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

– получить доступ к Git-репозиторию в частной сети, к которой нет доступа из интернета, но есть выделенный сервер из этой сети, который смотрит наружу

Эти и некоторые другие сценарии подробно раскрываются в статье.

Завершается статья набором настроек, которые позволят сделать SSH-туннели более надежным в случае разрыва соединения по таймауту или в случае сетевого сбоя.
#skills

Доработать нельзя переписать

Где поставить запятую в заголовке?

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

Более опытные разработчики скажут "Доработать, нельзя переписать". Они знают цену кода, который уже кто-то написал и отладил. Предыдущий автор уже через боль и страдания создал работающее решение. Костыли в этом коде появились не просто так.

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

В классической статье Грабли, на которые не стоит наступать (оригинал) Джоел Спольски рассуждает о вопросе выше. Он вспоминает о браузере Netscape, который умер в результате переписывания. Одной из причин желания всё переписать Джоел видит сложность чтения кода. С этим тяжело не согласиться. Остальные детали в статье.

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

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

Давай-давай, пиши документацию

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

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

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

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

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

И, конечно, мы всё запускаем в докере. О важности докера у нас есть отдельный пост.

В этом же разделе также важно описать, как запускать тесты. Очень важно.

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

— В разделе "другое" пишем о каких-то специфичных для проекта моментах. К таким особенностям может относится, например, накатывание миграций.

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

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

И ещё мысль по поводу документации:
Считаем вредным советом или требованием писать документацию в каких-то сторонних системах, таких как конфлюенс (да, порой и такое требуют). Практика показала, что поддержание документации в актуальном виде в стороннем сервисе, мягко говоря, не работает. Очень сложно убедить и даже заставить разработчика поддерживать доку где-то в сторонней приблуде. С ридми проще — можно писать, не отходя от кассы. И контролировать легче, проверяя изменение доки в merge request.
#devfm #procode

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

Если в гугле ввести "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