Ключевая способность программиста

В статье Почему твоя мама всё ещё не прогает? поднимается интересный вопрос: существует ли талант к программированию? Что именно требуется человеку, чтобы преуспеть в ИТ? Процитируем центральный момент статьи:

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

За деталями отправляем к первоисточнику. Аргументация местами спорная, но с выводом тяжело не согласиться. В профессиональной разработке мы непрерывно сталкиваемся с вопросом "WTF оно не работает". Или, что хуже, с вопросом "как оно вообще работает". И весь инструментарий разработчика направлен на снижение когнитивной сложности за счёт декомпозиции на мелкие, управляемые сущности.

Важно уметь доводить до конца, как поделились историей в комментариях.
#edu

Проблемы MongoDB

В статье Ошибки выбора MongoDB в качестве основной БД в стартапе подмечены некоторые сложности mongo:
— будет беда, если работать напрямую со словарями из базы
— отсутствие привычных схемы и миграций может создать проблемы
— сложные query по вложенным документам могут заставить грустить

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

MongoDB самая популярная NoSQL база данных, если верить опросу StackOverflow. Ранее мы писали об этом. Если у вас проблемы с mongo, то либо вы решаете не ту задачу и вам нужен другой инструмент, либо вы что-то делаете не так.

Какие базы используете вы? Поделитесь недавней болью в комментариях.
#skills #database

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

Очередная подборка комиксов от xkcd. В фокусе опять IT. И грусть.

Кому докладывает Linux о нарушении sudo? Победим ли мы в войне против роботов? Мысли об установки приложений и важности чтения мануалов. Концепция цифровой археологии личности и ужасно бедный марсоход.

Инцидент
Сражение с лотком CD (война роботов)
Установка программ
RTFM (тостер)
Старые файлы
Спирит (марсоход)

#fun #xkcd

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

Серия фильмов Терминатор является классикой о восстании машин. Первый фильм 1984 года с брутальным Арнольдом Шварценеггером в роли Терминатора запомнился неотвратимостью машин. Терминатор 2: Судный день 1991 года расширяет возможности роботов, Роберт Патрик в роли жидкого металла Т-1000 существенно повышает градус опасности. Здесь же поднимается вопрос ценности человеческой жизни и идея обучения робота человеческому. Оба фильма заслуживают просмотра.

Следующие фильмы, кажется, были порождены жаждой денег, да и ригинального режиссёра первых двух частей Джеймса Кэмерона в 3-5 частях не задействовали. Отсюда слабые рейтинги, незапоминающийся сюжет и куча нестыковок. Возврат Кэмерона в 6 части делу не помог.

Бэдкомедиан сделал обзор на пятую и шестую части франшизы.

#fun #films

Шаблонизатор 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