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

Занятный 30-минутный ролик Белый хакер разбирает сцены из фильмов. Местами хакер душнит, но было очень приятно вспомнить подборку этих фильмов и критически осмыслить ряд фрагментов:

Мистер Робот
Ограбление по-итальянски
Матрица: Перезагрузка
Кто я
Девушка с татуировкой дракона
Брат 2
Черное зеркало
Хакеры
Сноуден

#fun

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

Что будет с туристом в аэропорту, если во время полёта его страна юридически исчезнет? Чудесная и очень добрая картина Терминал (2004) с Томом Хэнксом отвечает на этот вопрос. Можно ли выстроить быт в зале ожидания аэропорта? Фрагмент со сдачей в Бургеркинге очень милый.

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

#fun #films

Ищем свой пароль в файле размером 37 Гб на Python

Статья Has your password been pwned? Or, how I almost failed to search a 37 GB text file in under 1 millisecond примечательна по нескольким причинам.

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

Далее начинается захватывающее чтиво. Автор проявляет невероятную смекалку для достижения своей цели — локально проверить свой пароль в файле размером 37 Гб за 1 миллисекунду.

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

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

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

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

И еще одна приятность статьи — в процессе повествования автор оставляет множество интересных ссылок для изучения.
#python

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