​​Гитхаб выкатил классную фичу для питонистов — Dependency Graph на основе анализа requirements.txt. Помимо красивого, но бесполезного вывода версий библиотек, гитхаб теперь умеет присылать алерты безопасности. До этого эта фича работала только с Руби (в гитхабе много рубистов) и JS.

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

#гитхаб

Вопрос по понедельникам: Начинаю изучать ПХП, стоит ли идти стажёром в агенство, которое работает на битриксе?

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

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

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

Последний пункт поясню. К примеру, если вы знаете условный Laravel, то вы понимаете, что такое MVC, зачем нужна ORM, как устроена маршрутизация в веб-приложениях. Вы уже наверняка несколько раз наступили на стандартные новичковые грабли, вроде толстых вьюх или N+1. Это означает, то вы достаточно легко можете пересесть на любой другой веб-фреймворк — хоть Yii, хоть Django, или вообще какой-нибудь Meteor. А если вы знаете Битрикс, то вы знаете только Битрикс. Вы, вероятно, даже документацию на английском читать не умеете.

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

Есть #вопрос? Присылай в @fedor_borshev.

Требования к питоньему коду

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

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

На питоне вы для этого используем кучу плагинов для flake8, кроме стандартных это commas, bugbear, isort, print. Еще ждем релиза pep8-naming с моим патчем.

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

А вот и сами требования (на английском, по историческим причинам).

Style
— Obey django's style guide.
— Configure your IDE to use flake8 for checking your python code. For running flake8 manualy, do cd src && flake8
— Prefer English over your native language in comments and commit messages.
— Commit messages should contain the unique id of issue they are linked to (refs #100500 -- changed smth)
— Every model and a model method should have a docstring.

Testing
— We use TDD, so all of your code (except admin declarations) should be covered by tests.
— Unit tests are split into 4 categories:
— Unit (check at least 90% of the flow graph for every method)
— Functional: business-logic, cross-app relations, testing views
— API
— Integration: integration with other services or complex business-cases, like creating an order with certain payment type and delivery.

Code organisation
— DRY and KISS.
— Obey django best practices.
— Make models fat. No logic is allowed within the views or templates. Only models.
— Use PEP-484 type hints when possible.
— Prefer composition over inheritance.
— Prefer Manager methods over static model methods.
— Obey Attribute\method order for your models.
— Do not use signals for business logic. Signals are good only for notification purposes.
— No l10n is allowed in python code, use django translation.

Презентация самому себе

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

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

Чтобы не запускать неработающее говно, проведите презентацию самому себе. А еще лучше — выберите коллегу поопытнее, и представьте, как проводите презентацию ему.

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

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

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

Вопрос: пытаюсь объяснить важность тестирования коллегам, но не получается — кто-то совсем против, а кто-то соглашается, но ничего не делает. Как быть?

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

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

А может и не заметят. Если от коллеги плохо пахнет (простите) то есть вероятность что никакой личный пример не заставит его соблюдать правила гигиены.

Есть #вопрос про ИТ? Задавай в @fedor_borshev

​​В mtrl.ai мы ищем ведущего питониста. Вы будете работать над нашим бекофисом — это сложное бизнес-приложение, которое позволяет нам взаимодействовать с неорганизованными строительными рынками, как с настоящими складами.

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

Кол пишем на Django2/DRF и python 3.6. БД — Postgres и Redis, планирование задач на Celery/RabbitMQ, поиск на elasticsearch. Переиcпользуемый код опенсорсим или выносим в микросервисы. Пишем юнит- и интеграционные тесты на pytest, на самом большом проекте сейчас ~4500 тестов.

Работаем удаленно, недельными спринтами, таски ставим в issues гитхаба. Сейчас в команде, включая меня, трое питонистов — вы будете четвертым.

Если порекомендуете друга, который пройдет испытательный срок — получите 30к.

По всем вопросам — @fedor_borshev.

#работамечты

​​Понятный код

Долго думал над тем, как можно было бы одним словом охарактеризовать хороший код. Недавно дошел: ПОНЯТНЫЙ.

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

Может ли хороший код быть непонятным? Нет. Может ли понятный код быть плохим? Вряд ли.

Вопрос: Я программист, хочу стать тимлидом и руководить людьми, что почитать?

Тимлиду нужно прокачивать то же, что и менеджеру — общение с людьми, ответственность, планирование проектов и управление командой.

Прокачку софтскиллов стоит начать с классики вроде Стивена Кови и Джима Кэмпа. Обе книги — сложный и качественный селф-хелп, почти без воды.

Для хардскиллов рекомендую Голдрадта — Цель (все три части) и Критическую цепь.

Если прочитали основы, поизучайте список книг в моем блоге.

#вопрос

​​Первый закон Паркинсона

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

Если внучка может писать бабушке письмо три дня, то она будет писать его три дня.

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

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

А если внучка торопится в кино с подружками, то бабушке хватит и открыточки.

​​Сервисы: Periscope

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

У нас в mtrl.ai уже давно внедрен Periscope — помимо привычной функциональности, вроде построения графиков и сборки красивых дешбордов, он сильно упрощает построение запросов — там есть упрощенные джоины (SELECT order.id, order.date, customer.name from [order+customer]), джоины из разных БД, кастомные вьюхи и еще много всего, упрощающего жизнь и аналитикам и программистам.

Periscope — дорогой инструмент (цены начинаются от 500$ в месяц), наверное есть и подешевле. Но простота настройки и фичи, которые позволяют аналитикам не ковыряться в дебрях SQL, кажется стоят еще дороже.

​​Процесс vs результат

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

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

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

Самый хороший способ — прямо сейчас найти у себя на работе проект с жестким дедлайном и взять на себя ответственность за его завершение. После второго проеба вы научитесь вести правильный внутренний диалог с собой: «Действительно ли то, что я делаю необходимо для результата?»; «Что из того, что я запланировал можно НЕ делать?».

Если проектов нет на работе — сделайте свой. Только поставьте жесткий дедлайн с осязаемым результатом. Хорошая личная задача — «завести блог». Напишете себе бекенд на гошечке? Возьмете модный генератор статичных сайтов? Или все-таки медиум?

Слово «Аджайл» заездили давно и наглухо. Даже Сбербанк уже работает по аджайлу. Тем не менее, я до сих пор встречаю ребят, которые не понимают, что такое «гибкость» в процессе разработки ПО.

Если вы тоже знаете таких ребят — прочитайте статью Натальи Бабаевой Как объяснить аджайл дедушке: сможете быть очень убедительными, да и свое понимание, наверняка, улучшите.

​​Ребята из Zeit.co (они же now.sh) выкатили классную фичу — деплой докер-образа в одну команду.

Поясню, как это круто — можно моментально, ничего не настраивая, выпустить в продакшн любой код на любом языке. Конечно есть ограничения — сложную инфраструктуру с БД, кешем и очередями таким образом не построить. Но для хипстерского serverless это не так уж и важно — ведь можно таким же образом задеплоить хоть десяток образов с чем угодно.

Плюшки вроде автоотката в случае фейла, скейлинга и полного отсутствия серверов, жестких дисков, дистрибутивов убунты и apt-get прилагаются.

​​Сервисы: retool

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

Ребята из retool пошли еще дальше — они позволяют прямо мышкой собирать кастомные интерфейсы, которые будут ходить в API или напрямую в БД.

Доступ на запись к БД — штука сомнительная: пользователь должен неплохо разбираться в кодовой базе, чтобы не обрушить все приложение парой инсертов, консистентных с точки зрения БД, но бессмысленных в контексте приложения (да, такое бывает у всех).

А вот доступ к API — это круто. В комплекте с работающей документацией (вроде apiary + dredd), это позволит не привлекая программистов на коленке собирать новые рабочие места.

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

Приходи с решением, а не с проблемой

Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».

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

Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти закон Паркинсона.

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

Post mortem

Большие ребята, которые работают с инженерами, после крупных аварий всегда пишут post mortem — начиная с гугля и амазона, и заканчивая более «консьюмерскими» сервисами вроде circle ci или гитхаба. Самый известный post mortem, который наверное читали все — эпичный проеб данных в гитлабе.

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

Существует даже целая коллекция post mortem, можно читать прям с пивом и попкорном.

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

Это прям наша национальная черта — еще со школы всех приучают, что ошибаться — плохо. Пофиг, что ты ошибся потому, что делаешь сложную работу, жизнеспособность которой зачастую лежит вне круга твоего влияния: в мозгу многих ребят застряла формула «ошибка = косяк, штраф, публичный ататат и профессиональная смерть». А что серьезного может сделать программист, который боится написать даже сложную дата-миграцию?

В mtrl.ai принято писать подробные письма о крупных ошибках. Вот к примеру про недавнюю проблему, которую спровоцировал я (ПДФ, чтобы картиночки сохранить).

​​В эту субботу закрывается старая версия CircleCI.com

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

Много времени вложили и в ускорение сборки — на самом медленном нашем проекте мы снизили время сборки в 8 раз, просто перейдя на вторую версию.

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

Цены у circle вполне демократичные — 50$ за контейнер. В комплекте — еще один бесплатный контейнер, который умеет собирать приватные проекты.

​​Сервисы: dependabot

Важная часть гигиены кодовой базы — актуализация зависимостей. Устаревшие зависимости приводят к мелким незаметным проблемам, которые вместе съедают кучу времени — на 5 минут дольше разворачивается проект; появляются свой код, который дублирует то, что давным-давно есть в апстриме; код не работает на новой убунте и т.д.

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

Dependabot решает эту проблему методом брутфорса: он постоянно мониторит зависимости и делает пулл-реквест с новой версией сразу после выхода. Первое внедрение становится тяжелым — вам упадет 20–30 ПР, с которыми как-то нужно будет разобраться. Зато потом вы получаете гарантию, что ваши зависимости не застрянут в каменном веке — просто нажимайте на зеленую кнопку: у вас же наверняка хорошее покрытие, и вы не боитесь обновляться, правда?

Самый первый дедлайн

Любая долгая работа — это отношения. Я знаю совсем немного компаний, которые довольны своей разработкой. И вторая причина недовольства, после банального отсутствие опыта у программистов — их неумение строить отношения.

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

В этот период вас оценивают. Ваши будущие отношения будут построены не по тому, как вы вели себя на встрече, а по тому, как вы поведете себя в эту неделю.

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

Как только вы нарушаете обещание — вы становитесь «обычными» программистом. И тут же получаете весь букет стандартной менеджерской хуйни: вас просят оценить задачи в часах, работать по скраму с ежедневными стендапами, быть онлайн с 9 до 18. С вами торгуются по срокам — все равно вы не выдержите, почему бы не отжать побольше?

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

Микроменеджмент ←———→ доверие

Для меня всегда слово «микроменеджмент» был антонимом слова «доверие».

Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном времени, не влезаете в рабочие процессы и детали реализации. У вас даже общего чатика нет (или чат состоит только из мемасиков, как у нас).

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

А если вы занимаетесь микроменедментом, значит вы не доверяете коллегам. Насколько вообще имеет смысл работать с людьми, которым нельзя доверять?