Шаблонизатор HTML — Jinja

На прошлом видео про WSGI рассматривался веб-запрос с момента пользовательского перехода на сайт до демонстрации ему строчки текста. Но современная веб-страница — это не просто текст, а фарш из HTML, CSS и javascript. Обычно сейчас frontend является отдельным проектом на angular/vue/react, а python код отдаёт лишь json для дальнейшей отрисовки на фронте.

Если нет сложных требований к фронтовой части приложения, можно воспользоваться html-шаблонизатором. Собственно, это HTML плюс небольшой язык управляющих конструкций типа for и if. Разработчик формирует шаблон — классическую HTML-страницу, в которой будущие данные оформлены в виде управляющих конструкций с внешними переменными. Из кода на python мы выбираем шаблон и подаём входные данные. Шаблонизатор подставляет входные данные в управляющие конструкции и формирует итоговую HTML-страницу для пользователя.

Наиболее популярным HTML-шаблонизатором для python является Jinja. Он применяется в Flask и FastAPI, его можно подключить в Django вместо Django template language.

Небольшой гайд по Jinja в рамках работы с Flask.

Полная документация по Jinja.
#python #devfm

Задача на собеседовании — проектируем динамическую фильтрацию

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

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

После уточнения задачи получаем следующие вводные:
— имеется клиент-серверное приложение интернет-магазина с возможностью поиска товаров

— количество записей в результате поиска может доходить до 1кк

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

— у разных категорий товаров разный набор фильтров

— после применения конкретного фильтра появляется новая выборка и для нее также должны отображаться только актуальные фильтры
Рассмотрим пример. Для телефонов должны быть фильтры "производитель" и "операционная система". После применения фильтра "производитель: Apple" в фильтрах ОС уже не может быть значения Android.

— для каждого значения фильтра необходимо отображать количество подходящих товаров. После выбора одного фильтра все счетчики должны пересчитываться.
Было "производитель": "Apple: 10", "Xiaomi: 20", "Встроенная память": "128 Гб: 10", “256 Гб: 20". Выбрали "128 Гб", после применения станет, например, "производитель": "Apple: 7", "Xiaomi: 19". То есть 3 модели Apple и 1 модель Xiaomi не попали под выбранный фильтр.

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

Как на настоящем собеседовании, уточняющие вопросы можно задать в комментариях. Наше решение задачи в 20:00 понедельника.
#devfm #skills #резюме

Нас круглое число 2^10=1024. Все помнят, что в 1024 году родился Магнус I Добрый, король Норвегии и Дании.

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

Залипнуть во фрактальные картинки можно на сайте медузы и жопы.

#ToTheMoon

В задачах на проектирование чего-либо интервьюера интересует не столько сам ответ, сколько ход ваших мыслей. Вы можете не дойти до правильного ответа, или дойти с подсказкой. Рассмотрим потенциальные решения задачи и покритикуем их:
💡 Давайте присылать все данные на фронт и фильтровать там.
🚫 1кк записей передавать нецелесообразно. Более того, даже хранить фильтры на фронте не выйдет, так как они динамические и определяются конкретной выборкой. В любом случае, фильтровать должен бекенд.

💡В postgres можно спроектировать схему для хранения фильтров в связке со списком товаров, к которым эти фильтры можно применять.
🚫 Здесь не стали приводить конкретики, но отметим, что при таком подходе будут проблемы с динамическим обновлением счетчиков. А ещё такое решение несёт сложную ментальную нагрузку на разработчика.

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

Пример реализации такого решения с использованием полнотекстового поиска в postgres приведен в статье Faceted search using PostgreSQL full text search.

Тестирование миграций alembic

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

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

Оказывается, можно избежать этих раздражающих проблем. Недавно наткнулись на плагин для pytest, который тестирует миграции. В комплекте идет 4 теста:
1. test_single_head_revision — проверяется, что существует единственная head ревизия
2. test_upgrade — проверяется согласованность всех миграций, то есть что миграции от первой до последней накатываются
3. test_model_definitions_match_ddl — проверяется, что состояние моделей должно полностью соответствовать миграциям
4. test_up_down_consistency — проверяется, что можно сделать даунгрейд от текущего состояния до пустой схемы
#python #database

Сервис проверки регулярок — regex101

У вас была одна проблема, потом вы решили применить регулярные выражения, теперь у вас две проблемы. Регулярки выглядят универсальным молотком, и после их изучения весь мир становится похожим на гвоздь. Но будьте осторожны! Применяйте регулярные выражения вдумчиво, когда другие способы действительно плохо применимы. Один из способов применения регулярок в pattern matching мы предлагали ранее.

Если всё-таки решили использовать регулярки, то для понимания их работы существует удобный сервис regex101.
Из удобного:
— наглядно видно, какая часть текста попала под регулярное выражение
— объясняется, как именно работает ваша регулярка
— есть подсказки, где можно быстренько что-то подглядеть
— можно выбрать язык, в рамках которого пишется регулярка, чтобы учитывать особенности ЯП

В дополнение есть менее применимый на практике сервис по визуализации и объяснению регулярок — regex-vis.
#skills

Почему трава зеленая, а программисты крутые

В одноимённой статье поднимается занятный вопрос умения удачно абстрагировать сущности. Представьте детский вопрос «Почему трава зеленая». У вас есть 4 варианта ответа:
1. «Потому что. У тебя мороженка уже капает»
2. На скорую руку придуманное объяснение
3. Хорошее понятное объяснение с точки зрения науки в понятных ребенку терминах
4. Вывалить на ребенка кучу научной чепухи, чтобы он сам выбрал нужное и погуглил недостающее

Наверное, лучший все-таки вариант 3. Но есть проблема. Вы не знаете вариант 3. В статье интересно рассказывается почему и как всё это связано с программированием.
#edu

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

Игра "кто хочет стать миллионером" является калькой с одноимённого британского шоу. И в США есть аналогичное шоу. Первый раз приз в один миллион долларов выиграл John Carpenter 19.11.1999, не израсходовав ни одной подсказки до финального вопроса. И на вопросе на миллион долларов он позвонил своему отцу. Отправляем вас посмотреть трёхминутное видео с заданным вопросом и неожиданной развязкой. 6 миллионов просмотров.

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

С тех пор у Джона даже есть своя статья на вики.

#fun

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

Кто такие лоббисты? Это люди, продвигающие в обществе определённые идеи. Например, трио друзей, которые лоббируют сигареты, алкоголь и оружие.

Это трио представлено в фильме Здесь курят (2005), в котором, несмотря на название, ни разу не показана сигарета. В центре кадра — переговоры и умение находить контакт с людьми. Всё приправлено юмором и сатирой на современность.

#fun #films

Собеседование Junior Python Backend Developer

В двухчасовом видеоролике luchanos с коллегой собеседуют девушку на позицию джуна. Обсуждались:
— коллекции и операции с ними
— как свой класс положить к множество
— ООП, наследование, полиморфизм, инкапсуляция
— итераторы и генераторы
— декораторы на практике
— небольшой код (тут девушка резко посыпалась), его time-complexity в терминах О-нотации
— немного вопросов по SQL
— GIL и IO-bound задачи

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

У luchanos есть проект с вопросами к собеседованиям. Неплохой check-list.
#skills #резюме #youtube

Разухабистое логирование

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

Статья от Яндекса Удобное логирование на бэкенде даёт понятное введение в логирование приложений в стиле:
1. Описали проблему, с которой столкнулись
2. Решили топорно имеющимися средствами
3. Отрефакторили к правильному решению

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

1. Логи нужно где-то хранить. Автор рассказывает о классическом решении — связке elastic и kibana. Особенно это актуально, если у вас распределенная система.

2. Поиск узких мест. Тормозит сеть? Или бд? Или, прости господи, сам питон? Смотря просто на логи, это невозможно понять. Проблему предлагается решать с помошью jaeger.

3. Ошибки нужно систематизировать, понимать важность и частоту возникновения. Ещё хорошо бы иметь контекст. Для этих целей в статье рекомендуют использовать sentry.

Подведём итог. Не стоит забывать об обширных возможностях логирования. При этом не тяните все решения себе, они могут оказаться overengineering для вашего проекта.
#skills

Прививка от азартных игр

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

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

Брат за три попытки не получил ничего, кроме ярких впечатлений от чудесного игрового автомата. Я же на второй монете получил три одинаковые картинки и баснословный выигрыш, монет эдак 30. В детской голове мгновенно созрел идеальный план. Если я со второй монеты получил 30, то сколько я получу с 30 монет!?

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

С тех пор к азартным играм у меня иммунитет.
#devfm #edu

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

Встретили тут в бизнесе мысль: "мы недостаточно большие, чтобы использовать Docker". Не можем согласиться с таким тезисом. В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:

1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.

2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.

3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково.

4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.

5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с django 3 и django 4, они никак друг другу не помешают.

6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend,frontend, базы данных, nginx и Let's Encrypt.

7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.

8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.

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

Для вас мы снимали ролик про изучение атаки forkbomb в Docker. В ролике можно увидеть, как просто применять докер. Для углублённого изучения недавно был пост с практическими советами по Docker.
#devfm #skills

Теория подталкивания или метод наджей

Двадцать лет назад журнал The Economist предлагал три варианта подписки:
1. 59$ в год на онлайн-версию
2. 125$ за печатную и онлайн-версию
3. 125$ только за печатную версию

В таких условиях мало кто купил первый вариант, большинство предпочло второй вариант и никто — третий. На следующий год третий вариант убрали. К чему это привело? Большинство выбрало первый вариант, так как он существенно дешевле.

Человеком можно манипулировать в достаточно широких пределах. В статье Как приучить соседей правильно закрывать дверь с помощью книжки про маркетинг⁠⁠ рассказывается интересный опыт, как можно подтолкнуть соседей закрывать плохой замок "как надо".

Почему бы не заменить замок на нормальный? Это не путь джедая.

Подробнее про наджи посмотреть в книге Nudge. Архитектура выбора. Один из авторов, Ричард Талер, спустя 10 лет получил Нобелевскую премию по экономике за теорию подталкивания.
#fun #edu #books

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

Мы уже говорили про фильмы о хакерах и реальность окружающего мира. Объединим эти темы. Может ли программист создать искуственный интеллект? Этично ли уничтожать созданный искуственный интеллект? Эти и другие вопросы в красочном фильме Из машины (2014).

Для любителей более динамичный картин рекомендуем посмотреть Суррогаты (2009) с Брюсом Уиллисом. Представлен мир будущего, где люди целиком перешли на удалёнку в достаточно странном виде. Даже в 2057 году метавселенные не взлетели, а люди управляют андроидами и не выходят из дома.

#fun #films

Паттерн Сага

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

Представим, что пользователь делает заказ в интернет-магазине. Заказ затрагивает сразу три сервиса:
1. складской сервис, где товар списывается
2. сервис организации курьерской доставки, куда товар передаётся
3. сервис платежей, в котором списываются деньги за заказ

Заказ не вызывает проблем, пока всё идёт штатно. А что делать, если оплата не прошла? Ведь со склада уже списалась единица товара и назначена доставка.

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

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

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

Wine для доступа к Windows-приложениям на Linux

Периодически раздражает необходимость иметь Windows-машину для доступа к специфическому софту, в том числе играм. Решением может быть multi-boot, но каждый раз перезагружаться? Виртуальная машина — неплохое решение. Но ВМ съест почти гигабайт оперативной памяти и 20%-30% процессора на накладные расходы.

Более интересным решением может быть Wine или его форк Proton от Valve. Никаких расходов на виртуализацию, потому что wine — не эмулятор. Windows-приложение запускается как нативное прямо в Ubuntu. Ну, если запускается.

Для любого софта в разделе Test Results на сайте winehq можно посмотреть совместимость. Для примера StarCraft. Если совместимость Gold или Platinum — поздравляю, для этого софта ВМ не понадобится, вы через Wine сможете запустить софт прямо на своём Linux.

В статье Как работает Wine (оригинал) вы можете познакомиться с интересными деталями реализации Wine, которые позволяют запустить Windows-приложение на Linux.
#skills

Трекайте рабочее время

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

Расскажу про свой опыт. На протяжении 5 лет я отслеживаю время, затрачиваемое на работу. Как и всегда в разработке, стоит начать с вопроса: зачем я это делаю и что это мне даёт?

Считаю, что мастхев трекать время в двух случаях:
1. когда сдельно работаешь на разных проектах
2. когда работаешь на удалёнке, чтобы соблюдать work-life balance

При проектной разработке со сдельной оплатой для меня важна выгодность проекта. И измерение времени связано непосредственно с зарабатываемыми деньгами.

Приведу пример: за проект мне заплатят Х денег. Но вот вопрос: а на сколько он выгоден? А если невыгоден, то из-за чего? Что мне сделать для увеличения выгоды? Есть количество денег в час, которое меня удовлетворяет. Поделив полученный Х на количество затраченных часов, я могу понять уровень своей удовлетворенности.

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

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

У меня в таск-менеджере есть ежемесячная задача на анализ выгодности своих проектов. Это позволяет держать руку на пульсе.

Когда я работаю на обычной работе, я работаю удалённо. И тут вот какая проблема. Ты вроде дома, а вроде и на работе. Я заметил два момента:

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

— Грустно для меня. Просыпаюсь и сразу за работу, весь день ударно работаю. Вечером вроде уже закончил, но вот возник вопросик, и компьютер соблазнительно близко — почему бы быстро не глянуть, что там за проблема. В итоге день в работе, вечер в работе, а и вечный день сурка.
В этом случае измерение времени позволяет мне соблюдать тот самый work-life balance.

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

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

Что касается приложений для этих целей — я пользуюсь atracker, коллега atimelogger, но вариантов много на любой вкус.
#devfm #edu

Снижаем нагрузку на БД с помощью аналитической базы

Не новая, но концептуально верная статья ReportingDatabase от дядьки Боба.

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

Для обработки сложных аналитических запросов предлагается создать отдельную базу данных — reporting database. Причем это может быть совершенно любая другая база данных, отличная от основной.
К плюсам такого подхода относятся:
— возможность выбрать базу, заточенную под аналитические запросы
— нет необходимости заботиться нормализации данных
— сложные запросы к reporting db не нагружают основную базу


Возможно, для вашей задачи отдельная БД не требуется. Вот и дядька Боб в конце рассказывает, что хороший базовый вариант — использовать классические views с вынесением их на отдельную ноду кластера. Представления позволяют создавать логические таблицы с данными, а их вынесение на отдельные вычислительные ресурсы позволяет разгрузить базу при построении сложной аналитики.
#skills #database

refurb — ещё один анализатор кода

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

Нашли на просторах гитхаба интересный проект — refurb. Ещё один анализатор кода, ставящий своей целью сделать код более питонячим и правильным. Никакого rocket science, просто набор формализованных правил, на которые проверяется код.

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

Из приятного, командой refurb --explain можно посмотреть подробное объяснение любого замечания. Этого не хватает во многих анализаторах, где за объяснением диагностик приходится лезть на stackoverlow.

Я попробовал погонять его на своих проектах. После автоматического запуска всех наших анализаторов в pre-commit оказалось, что рефёрбу ничего не осталось и никаких замечаний он не выдал.

Судя по свежим коммитам, проект активно развивается. Планируем посмотреть на него ещё через полгодика. Если он войдёт в список наших must have анализаторов, обязательно расскажем об этом. Попробуйте запустить его на своем проекте. Нашёл ли он что-то интересное? Добро пожаловать в комментарии.
#python