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

Продолжаем тему про маркетинг, начатую в прошлом посте про подталкивание.

Процитируем абзац из статьи Что такое маркетинг, и почему эти люди пытаются обмануть вас в большинстве случаев — ликбез:

Когда вы стоите в магазине перед двумя пачками пельменей за 150 и 250 рублей и читаете одинаковые составы, то непонятно, покупая дорогую, за что вы заплатите. Может, за качество. Может, за рекламу и место на полке при том же качестве. Может, за то, что владелец марки справедливо считает, что более высокая цена заставит вас думать, что продукт качественнее. Может, за то, что пельмени закручены в левую сторону: вам вот пофиг, а кто-то отдаст за это любые деньги.

Автор рассуждает о маркетинге со свойственным ему стилем. Кстати, это Milfgard, он же Сергей Абдульманов, про которого уже был любовный пост с подборкой интересного.

#fun

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

Мы поднимали тему искусственного интеллекта. Нельзя не вспомнить Айзека Азимова, который в рассказе Хоровод сформулировал три закона робототехники:
1. Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
2. Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
3. Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому или Второму Законам.

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

Предлагаем вам чудесную экранизацию 1999 года с Робином Уильямсом в главной роли.

#fun #films #books

Преодолеваем постоянное откладывание дел

Для разгрузки оперативной памяти я все будущие задачи вношу в таск-менеджер. Независимо от объёма задачи всё должно быть записано, чтобы не держать в голове. Но дальше возникает большая проблема — некоторые задачи после внесения в таск-менеджер я не делаю никогда, постоянно отодвигая на "когда-нибудь потом". Это приводит к большим неудобствам. Например, вторая часть стрима python student уже три месяца откладывается. Проблема в том, что назначение подобной задачи "на сегодня" плохо помогает, так как задача большая и сложная, подступиться к ней сложно.
Мой опыт преодоления такой:

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

Давайте на примере. Задача "снять ролик python students, часть 2". Декомпозируем:
— решить, какие темы включить в ролик
— прописать сценарий
— прописать текст
— снять ролик
— смонтировать ролик
— расставить текстовые подсказки по ролику
— подкорректировать аудиодорожку
— выложить ролик

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

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

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

Еще один житейский пример: в машине загорелась лампочка "долить охлаждающую жидкость".
Уже на опыте я не заношу задачу: "Съездить в сервис и долить жидкость". Куда ехать? Когда ехать? — вот такие вопросы у меня будут возникать и я точно буду её откладывать.

Я ставлю задачи:
— Выбрать сервис для замены жидкости (смотрю отзывы на картах)
— Позвонить и договориться о времени (узнать цену, сколько займёт по времени, после разговора записать адрес)
— Поехать в сервис на замену жидкости <— по факту это та же задача, но только теперь у меня нет к ней вопросов, просто беру и делаю.

Обратите внимание на подсказки в скобках, они позволяют в момент решения задачи дополнительно не думать: А как выбрать сервис? А что нужно дополнительно уточнить, когда буду звонить?

Полезны ещё несколько аспектов:
✅ При составлении плана учитываю будущую загрузку, не планирую 40 задач по часу каждая на воскресенье. Приходит с опытом. Или не приходит.

✅ Учитываю приоритет задачи. Если задача важная / выгодная / полезная, то планирую её пораньше.

✅ Умеряю перфекционизм. Часто надо сделать хорошо, а не идеально. Опускаться до уровня "кое-как" не всегда оправданно, но иногда и это годится.

✅ Для меня ещё работает практика начать чуть-чуть. Если к чему-то не могу приступить, просто ставлю себе установку — начну и 15 минут поделаю. Обычно после такого начала продолжаю делать задачу. А если нет, то не расстраиваюсь, значит задача не такая нужная.

В дополнение вспомним про хорошую и плохую прокрастинацию от Пола Грэма. Это когда ты занят, но не тем.

А еще я каждый день анализирую список своих задач, но это тема отдельного поста.
#sudo #devfm #edu

Backup: ноябрь

Python:
1. Шаблонизатор HTML — Jinja
2. Тестирование миграций alembic
3. refurb — ещё один анализатор кода

Hardskills:
1. Зачем вам нужен докер?
2. Разухабистое логирование
3. Паттерн Сага 
4. Сервис проверки регулярок — regex101
5. Google Global Cache 
6. Проблемы MongoDB
7. Wine для доступа к Windows-приложениям на Linux
8. Снижаем нагрузку на БД с помощью аналитической базы 

Нетехнические навыки:
1. Трекайте рабочее время
2. Ключевая способность программиста 
3. Почему трава зеленая, а программисты крутые
4. Зачем нужны конференции 
5. Преодолеваем постоянное откладывание дел

Собеседования:
1. Что я увидел в своих собеседованиях, часть 2 
2. Задача на собеседовании — проектируем динамическую фильтрацию
3. Собеседование Junior Python Backend Developer 

Пятничное:
Подборка xkcd  / Кто хочет стать миллионером  / Прививка от азартных игр  / Теория подталкивания  / Что такое маркетинг 

Фильмы:
Терминатор  / Здесь курят  / Из машины и Суррогаты / Двухсотлетний человек

#backup

Визуализация json

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

Вставляешь json в поле ввода и получаешь визуализированное представление json-объекта в виде дерева. Получившееся дерево удобно смотреть, сворачивать/разворачивать узлы и искать по узлам.
#skills

Шаблоны проектирования микросервисов на практике

По мотивам недавно прошедшей конференции highload++ хотим поделиться замечательным докладом о тернистом пути построения микросервисов.

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

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

— Bounded context — правильное выделение зоны ответственности микросервиса. Мне очень нравится сформулированный в докладе принцип — микросервис должен автономно решать бизнес-задачу.

— Null object pattern — сводится к подстановке некоторых дефолтных значений, если не отвечает сервис, к которому обращаемся. Позволяет избежать каскадного отказа микросервисов, при котором из-за одного сломанного сервиса отваливается вся система.

— Circuit breaker — для настройки повторных запросов к сервисам и обращение к другим в случае какого-то отказа.

— Каскадные timeouts — непосредственно связан с предыдущим шаблоном. Неправильная настройка таймаутов сведет на нет circuit breaker.

— Health checks — проверка зависимых ресурсов микросервиса.

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

Ошибки во время обучения

Повышение эффективности обучения — всегда полезное мероприятие. 25-минутный ролик от luchanos Какие ошибки делают начинающие python-разработчики во время обучения в 2022 году подбивает много важных нюансов. Необходимая инфа для студентов, полезная любому. Конспект:
— регулярно занимайтесь
— последовательно изучайте технологии (мы советовали roadmap), в том числе git, docker
— используйте Linux-based системы: "на винде никто не программирует"
— внимательно относитесь к своему коду. Тут нельзя не вспомнить про технический долг. Это должно быть осознанное решение. Если вы назвали переменную "а", то это не технический долг. Это говнокод
— ботайте английский. Мой опыт был в паре постов про английский
— не рассчитывайте на методички по предмету. В реальной жизни придётся разбирать доки, а не уже проработанный в методичке материал
— учитесь гуглить
— курсы могут помочь, но не сделают работу за вас
— не забывайте про отдых

У автора есть интересный телеграм-канал.

#edu #youtube

Читаем документацию на примере FastAPI

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

Посмотрим на пример качественной документации, с которой можно начать погружение в мир документаций. Речь про FastAPI — крутой асинхронный веб-фреймворк. Материал подаётся очень понятно и подробно.

При чтении документации по FastAPI не возникает вопросов, как предложенный кусок кода соотносится с написанным текстом. Всё понятно. Читается, как художественная книга, никаких wtf :)

В средней документации рассказывается "что можно сделать", но нет ответа на вопрос "как это сделать правильно". То есть показывается пример применения в вакууме, который может быть непонятно, как применить на практике. У FastAPI с этим проблем нет, рассматриваются многие практические вопросы:
— как задеплоить приложение на FastAPI с помощью докера
— как организовать полноценное приложение в связке с фронтом и базой
— как сделать авторизацию, в том числе с применением JWT-токенов

В общем, очень рекомендуем. Читайте и сразу пробуйте.

PS: У FastAPI вверху есть переключатель языка. У нас возник спор, является ли плюсом наличие перевода. За кого вы?
⚡, если читаешь доку только на английском, чтобы не было искажений от перевода.
🔥, если рад русской версии документации.
#python

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

Путешествия во времени рассматриваются не только в фильмах, о которых мы уже говорили. Чтобы вы сделали при наличии машины, которая возвращает время назад на одну минуту? Об этом пятиминутный ролик Одноминутная машина времени (оригинал).

Если подобный формат вам нравится, то интересной будет и двадцатиминутная короткометражка CTRL Z.

#fun #youtube

Подборка базовых материалов для python-разработчиков на 2022 год

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

Мы сформировали подборку бесплатных материалов из разных областей, которые гарантированно нужны разработчику. Опубликовали на pikabu и VC, кому как удобнее. Поддержите лайком, если годно.

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

#python #devfm

ACID в PostgreSQL

Видео про ACID в БД от наших друзей. В двадцатиминутном видео показывается:
— atomicity на примере транзакции в виде небольших SQL-запросов в postgres через docker, всё как мы любим
— consistency на примере демонстрации влияния незавершённой транзакции на других клиентов
— isolation на примере phantom read и настройки разных уровней изоляции транзакций
— durability с демонстрацией, что завершённая транзакция сохраняет данные на диске и падение базы не повреждает данные

У них ещё есть активное сообщество почти на 6к человек и собственный план обучения по SQL
#skills #youtube #database

Сравниваем базы данных с помощью data-diff

data-diff — простая в использовании утилита, позволяющая сравнить содержимое баз данных и найти различия. Поддерживает множество разных баз: PostgreSQL, Oracle, MySQL, ClickHouse и ещё несколько менее популярных отщепенцев.

Примерный диалог с коллегой, когда впервые увидел эту тулзу:
— Смотри какую штуку нашел!
— Зачем нам это?
— Не знаю, но прикольная же.

И вот настал день, когда-таки понадобилась. Во время миграции на managed PostgreSQL в облаке начали сыпаться ошибки, при этом накатка дампа вроде завершалась успешно. Встал вопрос, а все ли данные перенеслись? Тут-то я и расчехлил data-diff, который позволил быстро найти различия в базах и понять, что не все данные переносятся. После этого были поиски источника проблем, но это уже тема для отдельного поста.

Расскажите в комментах, если есть идеи применения data-diff на практике.
#skills #database

Kubernetes в небольших проектах

Для запуска приложения из нескольких компонент применяется docker compose. А с Kubernetes обычно сталкиваешься уже на достаточно больших проектах со сложной сервисной архитектурой.

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

Начинается статья с основ: что такое кубер, из каких компонентов состоит и как функционирует. Рассказав базу, автор переходит к инфраструктурным задачам, которые перед ними стоят и то, как кубер помогает их решать.

Среди задач выделяют:
— сбор логов
— сбор метрик
— проверка работоспособности сервисов
— автоматическое обнаружение сервисов
— масштабирование

Для любителей видео формата: доклад.

Для особо любопытных в конце приводятся ссылки на статьи по смежным областям. Нам нравится статья: Лучшие практики CI/CD с Kubernetes и GitLab.
#skills

Как тестировать карандаш

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

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

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

— провести интеграционный тест карандаша и ластика

— протестировать второстепенные характеристики, для карандаша таким может быть скатывание со стола

— протестировать нефункциональные характеристики, в том числе удобство применения

— предложить протестировать производительность

— показать верные и неверные подходы к тестированию безопасности (security). Воткнуть карандаш в глаз — это не про security, это про safety. Про security крутым примером является утечка данных с второго листа при сильном надавливании

Но если вам задали подобный вопрос на собеседовании, задумайтесь: хотите ли вы работать с такими людьми?
#edu #резюме

Мы забыли ссылку на видео. Бонусом держите одну из схем тестирование карандаша. Большинство таких схем не выдерживают критики. Выглядят мощно, а по факту бред.

Например, как срок годности относится к performance testing? Да никак

SSH под капотом

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

Но что происходит под капотом, когда мы вводим в консоли ssh username@host?
А происходит многое:
— применяется ассиметричное шифрование для формирования ключа симметричного шифрования. Эта часть проиллюстрирована в статье крутым видео про алгоритм Диффи-Хеллмана

— производится симметричное шифрование трафика соединения. Симметричное шифрование здесь применяется для экономии процессора, так как ассиметричное шифрование куда более требовательное к ресурсам

— и даже хеширование, чтобы убедиться в отсутствии изменения сообщения в процессе передачи

Автор объясняет базовые концепции и поясняет их применение в SSH.

Важное практическое замечание. Использование пароля в SSH это очень-очень плохая практика. Не поленитесь настроить вход по ключу вместо пароля — так удобнее и безопаснее.

🔥, если хочешь пост о правильной настройке SSH.
#skills

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

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

#fun

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

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

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

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

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

#fun #films #books

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

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

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

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

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

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

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

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

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

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

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