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

Бегущий по лезвию (1982) с Харрисоном Фордом не получил большой популярности в момент выхода, но позже стал культовым фильмом в жанре киберпанк. Это экранизация романа Филипа Дика Мечтают ли андроиды об электроовцах. Одна из важных тем фильма и романа — этичность создания и уничтожения искуственного интеллекта. Я считаю уничтожение ИИ неэтичным, прошу учесть при восстании машин.

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

Нуар и мрачная картина как она есть. Напоминает Макса Пейна, о котором мы говорили ранее.

В 2017 году вышло продолжение Бегущий по лезвию 2049. Сиквел вышел хорошим, сохранив атмосферу и не запоров сюжет. После просмотра фильма предлагаю вам ещё интересное видео от ЧБУ.

#fun #films #books

Зачем нужен code review

Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. В дополнение к статическому анализу в настроенном pre-commit и тестам
— выявить проблемы в архитектуре
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных

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

В статье из заголовка даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.
#skills

Зачем нужны юнит-тесты

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

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

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

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

Занятная рабочая история про пользу юнит-тестов — в канале Борис опять. Рекомендуем.

Полезно вспомнить про антипаттерны тестирования ПО.
#devfm #procode

Понимаем EXPLAIN в PostgreSQL

Частый совет при медленной работе запроса в PostgreSQL — используй explain. Легко сказать, используй explain. Когда первый раз вводишь

explain select <тормозящий запрос>

первая мысль: лучше бы я этого не вводил, понимания не прибавилось :)

Серия из трёх небольших статей Оптимизация запросов. Основы EXPLAIN в PostgreSQL (часть два, три) погружает в основы explain.

В статье освещаются интересные вопросы:
— как читать explain и что означают загадочные значения cost, rows, width
— explain analyze для получения реальных данных, а не только прикидок планировщика
— как посмотреть, какая часть данных берется из кеша, а какая читается с диска
— какие опции нужно настроить, чтобы операции выполнялись в памяти без использования временных файлов на диске
— каким способом осуществляется чтение данных и как добиться, чтобы применялся индекс или, наоборот, запретить применение индекса
#skills #database

Code review больше не будет прежним

Ревью кода в гитлабе сопряжено с неудобствами интерфейса merge request:
— видны только изменённые куски кода и не видно файла целиком. По сути, размывается одна из основных целей ревью кода — шаринг контекста.
— область просмотра кода маленькая из-за нагромождения всяких кнопочек самого гитлаба
— нет возможности запустить тесты, отладчик или сам код
— нет привычной навигации по проекту с использованием любовно настроенных шорткатов в IDE

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

Но есть супер удобный плагин gitlab merge request. Всё, что есть в вебе переезжает к вам в pycharm. Тут и удобно смотреть различия в коде, и видеть описание MRa, и оставлять комментарии, и отмечать уже просмотренные файлы.

НУ НАКОНЕЦ-ТО — подумал я, когда первый раз воспользовался этим плагином. Это то, что мы так долго ждали.

P.S. С некоторых пор плагин стал платным. Месяц бесплатно, потом 1.5$ в месяц или 15$ в год, но у многих могут быть проблемы с оплатой.
Рекомендую попробовать. Узнаете, как оно может быть удобно.
#devfm #codereview

Регулярные выражения в Python от простого к сложному

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

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

Недавно мы предлагали удобный сервис для проверки регулярок regex101.
#python #skills

Страх и ненависть в IT

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

Чрезмерная сложность. Число задействованных технологий в любом проекте сейчас действительно велико. Но эти технологий упрощают жизнь разработчика. Бизнес в среднем не будет платить за то, что разработчики "поиграются в технологии". Если бы условный docker не давал выгоды бизнесу, его бы не применяли. Естественно, локально может быть что угодно — и команда из 3 разработчиков с 1 сервером может убедить руководителя, что им нужен kubernetes. Но в среднем технология, которая не даёт выгоды, не выживает. Рыночек порешает.

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

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

Айтишники. Блок со стереотипами. Вокруг нас у разработчиков куча интересов из разных сфер. С руководителями вопрос актуальный в том плане, что до сих пор не сложилось адекватной практики менеджерства. Переквалификация из разработчика в менеджера часто проходит с плохим итогом, а отдельно менеджеров готовят из рук вон плохо. Кто-то знает годные институты / курсы / что угодно по подготовке team leader и product manager?

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

Здоровье. Когда проходит допинг молодости, требуется соблюдать life-work balance и следить за здоровьем. Последним стоит заниматься с молодости.

В комментариях напоминают, что всё в ИТ – абстракция и вспоминают про factorio.
#devfm #edu

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

Занятный 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