​Ежедневный герой

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

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

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

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

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

Кстати, если вы — питонист, думаете сменить работу и хотите, чтобы код, написанный на работе, добавлялся в ваше опенсорс-портфолио — напишите мне на fb@gdml.ru.

Профессиональный сленг

Где-то читал, что для того, чтобы тебя приняли за своего в любом профессиональном сообществе, достаточно просто владеть сленгом — и никакие 10 000 часов практики не нужны.

Упомянул про юнит-экономику — и ты уже продакт-менеджер. Рассказал про отличия роторных машинок от индукционных — и ты уже тату-мастер.

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

Если я на собеседовании замечаю программиста, который не имея глубоких знаний употребляет профжаргон, скажем много говорит о тестировании фронтенда, но не знает, как работают ассерты в Jest, или что какое TestCafé, я прекращаю такое собеседование.

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

Мне сказали — я копаю

В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такой фичекатинг, ещё до продакт-менеджера.

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

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

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

Вопрос: какой программист более ценен — кто глубоко знает одну технологию, или тот, кто в целом имеет хороший кругозор и знает много?

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

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

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

А вообще — не учите технологии, учитесь решать задачи.

Другие ответы — #вопрос. Задать свой — @fedor_borshev.

Django и кластеры

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

Во-первых, они сделали модульную абстракцию от системы хранения — просто подключаем любой модуль из django-storages вместо FileSystemStorage и перестаём думать о хранении файлов.

Во-вторых, Django запускается через общепринятый протокол WSGI, что позволяет как угодно настраивать мультипоточность при помощи того же UWSGI. Я рекомендую классический master mode с двумя воркерами на контейнер, и ограничение по количеству запросов на каждый, чтобы не есть память.

В-третьих, почти вся функциональность, нужная для современного девопса, в Django сделана через удобные внешние зависимости.
— Мониторинг статистики через Datadog. Просто заводим его на каждой машине в кластере и получаем в дополнение ещё и мониторинг серверов.
— Сбор статистики через statsd. Можно использовать dogstatsd из того же Датадога, либо взять оригинальный, если хотите держать значения метрик у себя.
— Мониторинг ошибок — просто ставим sentry.
— Логирование — что угодно, мы в ГдеМатериале используем Papertrail, но можно тот же datadog
— Мониторинг здоровья контейнеров — django-healtchecks.

P.S. Кстати, Django работает и с модным serverless, так что если вы модный хипстер — обязательно посмотрите Zappa.

Поработал? Убери!

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

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

Если ваш ПР ничего не улучшает для других — это плохой ПР.

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

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

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

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

Каждый раз, когда я объясняю что-то новое, я обязательно после разговора записываю это в специальную доску в трелло. Одна карточка — одна мысль, 3–5 карточек в неделю.

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

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

Другие ответы — #вопрос. Задать свой — @fedor_borshev.

Почему я не люблю оценивать задачи

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

Почему я не даю оценок маленьких задач? Во-первых потому, что если в задаче указано сколько её нужно делать, это подрывает саму основу контракта с исполнителем: ведь я же, отдавая задачу, ожидаю получить фичу на проде, а не 5 часов работы по написанию кода.

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

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

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

Где провести границу MVP

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

Вопрос: что разработчик должен знать о дизайне? А тимлид?

Если разработчик занимается интерфейсами, то базовые вещи вот такие:
— Теория близости и Закон Фиттса
— Анимация в интерфейсах
— Как писать тексты в интерфейсах

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

Когда закончите с технологиями, почитайте о продукте и результате:
— Понятие «боли» и «мира клиента», Джим Кэмп
— jobs-to-be-done или любая другая методика проектирования
— Психбольница в руках пациентов
— Intercom on Product Magement

Это был традиционный вопрос по понедельникам. Задать свой — @fedor_borshev, посмотреть другие ответы — #вопрос

Одна задача — один ответственный

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

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

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

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

Идеальное решение проблемы — процесс, который описал Фредерик Лалу в своих «Организациях будущего» — внутреннее консультирование. Это когда мы интересуемся мнением коллег, но финальное решение принимает один человек. Коллеги при этом с самого начала понимают, что их голос — совещательный. То есть слушаем экспертов, но эксперты заранее знают, что решение принимают не они.

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

​Status Hero — замена дейли-митингам, если вам уж очень надо

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

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

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

Для таких случаев мы используем Status Hero — простой сервис ежедневных чекинов. Все что он делает — присылает в 11:00 каждого дня ссылку на форму со стандартными вопросами из скрама: что сделал вчера, что будешь делать сегодня, какие есть проблемы. В 16:00 результаты заполнения формы рассылаются всей команде.

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

Вопрос: Как программисту не решать выдуманных проблем?

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

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

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

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

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

Если ответ на оба вопроса «нет» — не делайте.

Другие вопросы — #вопрос. Задать свой — @fedor_borshev.

Не нравится? Разбирайся!

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

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

Или достал вас кривой линтер. Если подойти к тимлиду и позадавать вопросов на тему «почему так?», то с ненулевой вероятностью легаси начнет исправляться — говнокод перепишется или изолируется, линтер обновится, а питон, даже если не станет третьим, то хотя бы начнёт делать from __future import.

Может конечно и нет, но задать вопрос ничего не стоит, а в ответ на открытые вопросы люди всегда делятся полезными знаниями.

Задавайте вопросы.

​Django: бить модели по файлам, а файлы — по приложениям

Как не следуй гайдлайнам, а в любом проекте на Django рано или поздно окажется файл models.py длиной в 1500 строк. Запускать такую ситуацию нельзя — длинные файлы неудобно читать и править, и команда начинает сама того не осознавая тратить силы на неважное: вместо размышлений о бизнес-логике, программисты вынуждены запоминать, на какой строке находится та или иная модель.

Не стесняйтесь бить models.py на файлы. Даже если у вас всего две модели, скажем, Author и Book, пусть они лежат в models/author.py и models/book.py. К сожалению, без бойлерплейта сделать это не получится, поэтому вам придётся сделать ещё models/__init.py__. Ничего страшного, новые модели добавляются редко, и 5 минут на импортирование всех моделей окупятся уже за следующую неделю.

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

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

Раскрытие соседствует с кучей неприятных подробностей, самое страшное — от нахождения уязвимости до первого патча прошло аж 4 (!) месяца. Лично мне патч прилетел всего пару дней назад.

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

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

Пост с деталями — http://bit.ly/2YRRwhy

Обновляйтесь почаще.

​Вопрос: я дизайнер, и хочу не просто рисовать макеты, а делать работающие штуки, которые решают проблемы в реальном мире. Чтобы запустить проект, кроме языка программирования обычно нужно выучить ещё много всего, хотя бы тот же PyCharm и пару библиотек. Как делать работающие штуки не тратя время на борьбу с настройкой IDE?

Среда разработки — это всего лишь инструмент, как гвозди и молоток. Если вы, не умея забивать гвозди, возьмётесь строить дом — вы скорее всего просто отобьёте все пальцы. А дом, даже если вы его достроите — развалится.

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

Чтобы не осваивать базовые инструменты, но при этом делать работающие вещи, откажитесь от свободы. Уменьшив требования, можно собирать прекрасные веб-страницы на Тильде, писать ботов на pipe.bot, и botmother, а интерфейсы к базам данных — в Retool. Для мобильных приложений тоже существует десяток конструкторов — выбирайте любой.

Просто откажитесь от программирования совсем — снесите IDE, закройте мануалы по питону. Решайте проблему тем, что есть под рукой. Ну а если всё-таки решите усложнить себе решение и разобраться в программировании — начните с веба, это самый понятный путь. Обязательно перед началом прочтите совет Юрия Мазурского о том, как дизайнеру стать разработчиком.

Это был традиционный вопрос по понедельникам. Другие вопросы — #вопрос. Задать свой — @fedor_borshev.

Производство и потребление: продолжение

После прошлой заметки о производстве и потреблении, многие ребята спрашивали в личку, как производить больше 95% людей имея только блокнот и ручку?

На самом деле, задача очень простая — 95% людей, которых вы встречаете, не производят совсем ничего. К примеру почти всё, что большинство делает на работе — это всего лишь простые действия, которые улучшают потребление. У многих цепь настолько простая, что не отличается от мышки в лабиринте: совершил 100 звонков -> выполнил KPI -> получил бонус -> улучшил потребление.

Никто не задаётся вопросами. Кому стало лучше от 100 звонков? Мне? Близким? Человечеству?

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

Заведите блог (те самые блокнот и ручка). Кому-то будет полезно и интересно.

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

Запишитесь в волонтёрскую организацию.

Прочитайте 150 книг.

Возьмите кусочек рынка и переверните его с ног на голову.

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

Хороший план исходит от команды

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

В плане менеджеров обычно все завязано на цифры: берем беклог, оцениваем каждую задачу в часах, а затем всё как в бухгалтерии: в двухнедельном спринте у нас 80 часов, 20 оставляем про запас, а остальные 60 — забиваем задачами. От такого плана исполнители уже не отвертятся — раз оценил задачу в трекере на 4 часа, значит 4 часа над ней и работай.

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

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

См. также: почему я не люблю оценивать задачи

Вопрос: приведи примеры софт-скиллов в контексте программирования?

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


Другие вопросы — #вопрос. Задать свой — @fedor_borshev.