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

​​😈 Потрясающий интерфейс и отвратительная морда

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

Мне кажется, тут недопонимание.

На самом деле, нет выбора между «божественно прекрасный интерфейс задорого» и «самое убогое во вселенной отстоище задёшево». Обычно есть как минимум такие варианты:

1. Сделать плохо, потратив N ресурсов.
2. Сделать нормально, потратив те же N (или чуть больше) ресурсов.
3. Сделать отлично, потратив k*N ресурсов.

Понимать принципы создания хороших интерфейсов стоит хотя бы для того, чтобы видеть вариант 2. Иначе вы остаётесь только со «сделать плохо».

Действительно, далеко не всегда вы пойдёте по варианту 3 — потому что есть ограничения и есть приоритеты. Но почти никогда не останетесь с вариантом 1, потому что между «сделать плохо» и «сделать нормально за те же деньги» нормальный менеджер всегда выберет «сделать нормально».

Два года назад я подобрал замену эверноуту — Simplenote в связке с nvALT. С тех пор эверноут стал еще жирнее, Apple в 10 раз улучшил Notes, но я все еще пользуюсь своей связкой.

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

​​Top-down и прогрессивный джипег для программистов

Правило Парето гласит, что 80% времени программиста тратится на 20% требований. К примеру, на любом современном фронтенд-фреймворке работающую корзину в интернет-магазине можно запилить за день — можно будет добавить/удалить товар и отправить заказ.

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

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

Инженеры называют этот подход top-down, дизайнеры — прогрессивным джипегом.

Почему я выбираю кандидатов с живым гитхабом

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

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

В стартапах все по-другому. Программист в стартапе должен обладать нетипичными для больших компаний навыками:
— Быстро въехать. Легаси у меня нет, и я не хочу, чтобы кто-то за деньги инвесторов просто изучал новые технологии.
— Не бояться отрывать жопу от стула и выходить за рамки. Это стартап, тут CTO может подменить грузчика.
— Уметь доводить дела до конца. Менеджеров, которые с палкой следят за дедлайнами, у нас тоже нет.

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

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

​​2018 год и собственный огород

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

Теперь анализаторы логов заменила Гугль-аналитика, сисадминов заменил докер, и появилось отдельное слово для обозначения невиртуальных серверов  — bare metal. Однако я до сих пор встречаю компании, которые ставят себе «анализаторы логов» — корпоративный гитлаб вместо гитхаба, локальные версии дженкинса вместо серкла, свои хостинги, почтовые сервисы, трекеры задач и пр.

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

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

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

Неужели ваше время стоит дешевле?

Нерешаемая задача

В общении с плохими программистами (и сантехниками) часто проскакивает тон «это нерешаемая задача»:

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

— Давай передавать данные о телефонных заказах в Гугль-аналитику? Не получится, мы для таких заказов не знаем ИД аналитики.

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

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

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

Будьте решателями проблем, а не создавателями.

​​Рациональная фантастика

Редко читаю (а тем более советую) художку, но мимо этой серии пройти невозможно. Трилогия называется «Воспоминания о прошлом земли», написал ее китаец Лю Цысинь.

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

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

О художественной части я могу судить только на уровне «интересно-не интересно». «Воспоминания» — интересно.

Похоже всю серию на русском так и не выпустили, так что гуглите английскую The Remembrance of Earth's Past.

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

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

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

Перефокусироваться с процесса на результат — тяжело: это связано с индивидуальными особенностями личности. Мне в свое время помогали простые вопросы про бизнес:
— Зачем я вообще делаю эту задачу? Кто ожидает от нее результат?  Как этот результат выглядит?
— Как бизнес получал бы результат, если бы меня не было? Как бы я мог бы им в этом помочь?
— Если бы я мог потратить на эту задачу всего 30 минут, какими бы ее частями я пожертвовал, чтобы бизнесу было наименее больно?
— Какая самая сложная часть задачи? Что можно изменить в постановке, чтобы избавиться от нее?

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

​​Сервис: netlify.comnetlify.com

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

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

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

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

И все это бесплатно.

Старая заметка о том, почему слэк (и другие чатики) не добавляют продуктивности, а наоборот, крадут. Со времени написания заметки слэк получил 600 миллионов долларов инвестиций, стал в два раза жирнее, но не прибавил ни капельке пользы.

Скиньте эту ссылку прямо сейчас в свой рабочий слек — https://borshev.com/slack-productivity/

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

Наиболее эффективная коммуникация

У всех людей разные привычки и возможности общения. Я для себя открыл наиболее эффективный способ общения: одно дело в одном сообщении.

Чтобы максимально быстро получить ответ от меня, нужно прислать ровно одно письмо ровно с одним вопросом или ровно с одной картинкой.

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

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

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

- Это поэтому ты так много успеваешь? А ты сам придумал этот лайфхак? А как мне научиться делать как ты?
- ...

Стейджинг → деплой превью

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

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

Расскажу про наш сетап. Про первую часть я уже писал в заметке про нетлифай — это автоматическая публикация веток фронтенда на поддоменах. На каждый ПР у нас появляется ссылка вида deploy-preview--<feature>--<project>.netlify.com.

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

У нас это специальная машина на селектеле, на которой через docker-compose крутится минимальная инфраструктура, отключенная от внешних интеграций. Образы постоянно обновляются через ночные сборки в CI, включая полную копию рабочей базы.

Фичи, которые затрагивают бекенд, обычно выкатываем прямо в продакшн, еще до запуска фронта. Так можно делать, если вы не нарушаете обратную совместимость (вы же только добавляете поля в API, а не удаляете, правда?). Затем фича через ночные сборки попадает на демонстрационный бекенд, куда уже ходят фронтовые превью.

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

Для программистов: правила хорошего ревью

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

Если хотите научиться хорошему ревью, очень рекомендую почитать вот эту статью от Никиты Сивакова.

​​Сервис: datadoghq.comdatadoghq.com

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

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

Датадог — один из трех доступных на рынке APM для питона (есть еще new relic и obeat). Кроме APM, содержит в себе еще развитую систему мониторинга серверов — снимает метрики с железа и контейнеров, шлет уведомления, и интегрируется с тоннами систем.

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

Нужен ли вам докер в продакшене? Нет.

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

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

Если вы до этого еще не доросли, то используйте докер «как все» — чтобы быстро разворачивать куски инфраструктуры на машине разработчика. А сервера автоматизируйте на старом добром Ansible.

НЕ ЗАВИСАЙ

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

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

Мой метод борьбы с неконтролируемой работой — внешний арбитр. Если я замечаю, что потратил на задачу больше часа, и до сих пор не понимаю, как я получу результат, я призываю кого-то со стороны. Арбитром может быть руководитель, более опытный коллега или даже менеджер проекта. Задача арбитра — просто выслушать. Если решение не найдено во время вашего монолога (обычно находится) пусть арбитр позадает открытые вопросы: «зачем ты решаешь эту проблему?», «какими ещё способами можно ее решить?», «что будет с задачей, если этого не сделать?».

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

Сервис: VPN

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

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

За половину стоимости нормального ВПС можно купить аккаунт у любого крупного провайдера ВПН, вроде PureVPN или NordVPN. Мой любимый — NordVPN: в добавок к удобному способу соединения, вы получаете ещё набор расширений для браузеров и быстрые SOCKS-прокси. Прокси удобно прописывать в телеграмме, чтобы приложение на телефоне работало даже без ВПН.

Скорость на платных ВПН почти не падает — можно смело заворачивать весь канал туда. Разница будет видна только если начинаете качать что-нибудь крупное.