Синдром «я так и знал»

Он же — знание задним числом, интересно описанный в статье Юдковского. Того самого, который автор Гарри Поттера и методов рационального мышления.

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

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

В шестиминутном ролике есть интересный пример про результаты соц опроса.

Для интересующихся темой когнитивных искажений человека мы уже рекомендовали фильм Я и другие.
#edu #devfm

Backup: октябрь

Hardskills:
1. Docker. Практические советы
2. Тернистый путь к ClickHouse
3. ИИ на службе мошенников 
4. Dependency Injection в python
5. Генеративно-состязательная сеть (GAN)

О программировании:
1. Pre-commit — must have утилита любого проекта
2. Делаем код мягким и шелковистым
3. Технический долг 
4. Git — исход 

Разбираем код:
1. Реализуем read-only атрибуты
2. Поверхностное копирование объектов и изменяемость типов
3. Чисто позиционные параметры

Нетехнические навыки:
1. Какие знания нужны разработчику?
2. Проблемы курсов по программированию
3. Теория разбитых окон
4. Синдром «я так и знал»

Собеседования:
1. Завышать ли опыт в резюме?
2. Пересмотри своё собеседование
3. Что я увидел в своих собеседованиях, часть 1

#backup

Google Global Cache

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

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

GGC сохраняет недавно просмотренные видео в масштабе района, вероятно, способен делать упреждающую загрузку для набирающих популярность видео и прочую чёрную магию. У самого гугла про это довольно лаконичная страница. Немного дополнительных сведений есть в старой статье Google Global Cache — для избранных.

Сама система запатентована в 2006 году.

#skills

Что я увидел в своих собеседованиях (часть 2)

Продолжаем начатое...

❌ Оказалось, что есть типовые вопросы, которые часто задают на собеседованиях, но к которым я специально не готовился. ООП, SOLID, микросервис vs монолит и подобное — без подготовки ответ выходит путанным.
✅ Подботал типовые вопросы.

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

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

❌ Когда интервьюер спрашивал "есть ли у меня вопросы по вакансии и компании", то возникала заминка. Я спрашивал не очень связно и не всё, что действительно хотел узнать о потенциальном работодателе.
✅ Для этого я также составил чеклист со списком интересующих меня вопросов.

Какие у вас были проблемы на собесе?

#devfm #edu #резюме

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

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

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

За деталями отправляем к первоисточнику. Аргументация местами спорная, но с выводом тяжело не согласиться. В профессиональной разработке мы непрерывно сталкиваемся с вопросом "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