Не любить новые фичи
Если вы работали с опытными продуктовыми менеджерами, то знаете, насколько они не любят новые фичи. Прежде, чем поставить фичу в план, продуктолог испробует все возможные способы от нее отказаться. У Интеркома даже целый мануал на эту тему есть.
Ненавидеть фичи — задача не только продуктолога, но и всей команды: дизайнеров, программистов, менеджеров и тестировщиков. Особенно важно ненавидеть фичи в стартапах.
Между простым и сложным, влюбленный в фичу программист всегда выбирает сложное. Он будет рефакторить код, менять архитектуру и делать другие программистские штуки только ради того, чтобы новой фиче приятнее жилось в системе. Не важно, что фичу не внедрят или забудут — программист любит свою работу и сделает ее хорошо.
Когда программист не любит фичи, все наоборот — он пишет код, не касаясь участков приложения, которые можно не трогать. Если фича заработает — плохой код перепишут, не страшно. Если не заработает — ну и хрен с ней, сделаем реверт.
Менеджер, который любит фичи, не жалеет инвестиций, — выделяет время команды и стейкхолдеров, нанимает больше программистов, и вообще превращается в трудолюбивого идиота.
Трезвый менеджер, наоборот, думает про цифры — на какую метрику бизнеса эта фича влияет? А что считать показателем успеха внедрения? Если ответов нет — фича режется.
Давайте экономить деньги и не любить фичи.
Если вы работали с опытными продуктовыми менеджерами, то знаете, насколько они не любят новые фичи. Прежде, чем поставить фичу в план, продуктолог испробует все возможные способы от нее отказаться. У Интеркома даже целый мануал на эту тему есть.
Ненавидеть фичи — задача не только продуктолога, но и всей команды: дизайнеров, программистов, менеджеров и тестировщиков. Особенно важно ненавидеть фичи в стартапах.
Между простым и сложным, влюбленный в фичу программист всегда выбирает сложное. Он будет рефакторить код, менять архитектуру и делать другие программистские штуки только ради того, чтобы новой фиче приятнее жилось в системе. Не важно, что фичу не внедрят или забудут — программист любит свою работу и сделает ее хорошо.
Когда программист не любит фичи, все наоборот — он пишет код, не касаясь участков приложения, которые можно не трогать. Если фича заработает — плохой код перепишут, не страшно. Если не заработает — ну и хрен с ней, сделаем реверт.
Менеджер, который любит фичи, не жалеет инвестиций, — выделяет время команды и стейкхолдеров, нанимает больше программистов, и вообще превращается в трудолюбивого идиота.
Трезвый менеджер, наоборот, думает про цифры — на какую метрику бизнеса эта фича влияет? А что считать показателем успеха внедрения? Если ответов нет — фича режется.
Давайте экономить деньги и не любить фичи.
Я не знаю ни одного владельца нового макбука, который был бы доволен тачбаром. Написал статью, которая рассказывает, как не отвлекаться на ненужные кнопки и переключающиеся треки: https://telegra.ph/Kak-zhit-s-tachbarom-02-27-2
Стражники
Сколько ваших пользователей видят ошибки яваскрипта, когда заходят на главную? Какую долю корзин вы теряете из-за серверных ошибок? Как часто страницы отваливаются по таймауту?
Существует несколько сервисов для мониторинга таких вещей. Я рекомендую sentry.io или opbeat.com. Последний ещё и умеет мониторить производительность приложения. Оба сервиса бесплатны на небольших нагрузках.
Важнейший эффект от этих сервисов — моментальная обратная связь. Если программист выкатил код, который вызывает ошибку у 40% пользователей, он узнает об этом сразу, ещё находясь в контексте задачи. А не на следующий день, погрузившись в соседний проект. Меньше переключений —> меньше срочной работы —> больше производительность.
Сервисы очень легко устанавливаются на фронтенд любого сайта. На бекенд, если у вас не битрикс — тоже.
Сколько ваших пользователей видят ошибки яваскрипта, когда заходят на главную? Какую долю корзин вы теряете из-за серверных ошибок? Как часто страницы отваливаются по таймауту?
Существует несколько сервисов для мониторинга таких вещей. Я рекомендую sentry.io или opbeat.com. Последний ещё и умеет мониторить производительность приложения. Оба сервиса бесплатны на небольших нагрузках.
Важнейший эффект от этих сервисов — моментальная обратная связь. Если программист выкатил код, который вызывает ошибку у 40% пользователей, он узнает об этом сразу, ещё находясь в контексте задачи. А не на следующий день, погрузившись в соседний проект. Меньше переключений —> меньше срочной работы —> больше производительность.
Сервисы очень легко устанавливаются на фронтенд любого сайта. На бекенд, если у вас не битрикс — тоже.
Фундамент для автоматизации
Первая автоматизация, которая должна появиться в вашем проекте — непрерывная доставка.
CI/CD — это процесс, который после каждого коммита выполняет манипуляции над кодом: валидирует, тестирует и снимает метрики качества. В случае, если код ок, то CD автоматически раскатывает его по серверам.
CD спасает программистов от кучи рутины: не нужно хранить ключи от серверов, ждать выполнения проверок на локальной машине (любой SaaS умеет пускать тесты хоть в 10 потоков), настраивать окружение для деплоя.
Налаженный процесс CI/CD открывает дорогу к куче ускоряющих/удешевляющих практик: 10 релизов в день, gitflow, TDD/BDD. Даже Agile (простите) не работает без непрерывной доставки.
Вопреки заблуждению, которое я часто слышу от коллег, чтобы внедрить простейший CI/CD не нужно усложнять инфраструктуру. В начальном варианте не нужны даже docker и ansible — достаточно пары скриптов, которые может написать любой знакомый с bash программист.
Прямо сейчас начните отправлять через CD все — ваш лендинг, сайт и приложение, скрипты для воксимпланта.
Самый крутой CI — circleci.com. Полный каталог всех сервисов — на гитхабе.
Первая автоматизация, которая должна появиться в вашем проекте — непрерывная доставка.
CI/CD — это процесс, который после каждого коммита выполняет манипуляции над кодом: валидирует, тестирует и снимает метрики качества. В случае, если код ок, то CD автоматически раскатывает его по серверам.
CD спасает программистов от кучи рутины: не нужно хранить ключи от серверов, ждать выполнения проверок на локальной машине (любой SaaS умеет пускать тесты хоть в 10 потоков), настраивать окружение для деплоя.
Налаженный процесс CI/CD открывает дорогу к куче ускоряющих/удешевляющих практик: 10 релизов в день, gitflow, TDD/BDD. Даже Agile (простите) не работает без непрерывной доставки.
Вопреки заблуждению, которое я часто слышу от коллег, чтобы внедрить простейший CI/CD не нужно усложнять инфраструктуру. В начальном варианте не нужны даже docker и ansible — достаточно пары скриптов, которые может написать любой знакомый с bash программист.
Прямо сейчас начните отправлять через CD все — ваш лендинг, сайт и приложение, скрипты для воксимпланта.
Самый крутой CI — circleci.com. Полный каталог всех сервисов — на гитхабе.
Теория игр
Помните «Игры разума?». Главный герой, Джон Нэш, в реальной жизни известен не милым раздвоением личности, а тем, что получил Нобелевскеую премию как один из изобретателей Теории игр — науки, которая изучает стратегии с точки зрения математики.
Стратегии нужны не только в шахматах и Heroes III — теория игр отлично проецируется на все ситуации, где нужно принимать решения — ценовые войны, выборы, переговоры, и даже семейные отношения.
Единственная книга, которую я знаю на русском — одноименная «Теория игр». Книга — сложная. Авторы, видимо под влиянием преподавательского прошлого, наполнили книгу выдуманными примерами, сложными настолько, что не держатся в памяти — пока дочитаешь доказательство, забываешь, что оно доказывает, приходится возвращаться назад.
Однако, ради прокачки стратегического мышления, которую дает эта книга, не страшно и на пару недель почувствовать себя похмельным студентом. Покупайте на озоне. Если знаете аналоги попроще — пишите в личку.
Помните «Игры разума?». Главный герой, Джон Нэш, в реальной жизни известен не милым раздвоением личности, а тем, что получил Нобелевскеую премию как один из изобретателей Теории игр — науки, которая изучает стратегии с точки зрения математики.
Стратегии нужны не только в шахматах и Heroes III — теория игр отлично проецируется на все ситуации, где нужно принимать решения — ценовые войны, выборы, переговоры, и даже семейные отношения.
Единственная книга, которую я знаю на русском — одноименная «Теория игр». Книга — сложная. Авторы, видимо под влиянием преподавательского прошлого, наполнили книгу выдуманными примерами, сложными настолько, что не держатся в памяти — пока дочитаешь доказательство, забываешь, что оно доказывает, приходится возвращаться назад.
Однако, ради прокачки стратегического мышления, которую дает эта книга, не страшно и на пару недель почувствовать себя похмельным студентом. Покупайте на озоне. Если знаете аналоги попроще — пишите в личку.
Ни с кем не встречаюсь по понедельникам
Уже несколько лет я практикую классное правило продуктивности — ни с кем не встречаться по понедельникам.
Понедельник — это мой личный день: я планирую будущую неделю для себя и коллег, подвожу итоги прошлой недели, разбираю и причесываю беклог.
Голова после выходных загружена меньше, а значит качество планов — выше: задачи понятны и достаточно проработаны; везде заложены достаточные запасы времени; неважные задачи удалены или убраны в беклог.
Внедрить это правило очень просто — коллеги привыкают через две недели, а внешним ребятам достаточно говорить, что весь понедельник уже расписан.
В терминологии ГТД мой личный понедельник называется «еженедельный обзор».
Уже несколько лет я практикую классное правило продуктивности — ни с кем не встречаться по понедельникам.
Понедельник — это мой личный день: я планирую будущую неделю для себя и коллег, подвожу итоги прошлой недели, разбираю и причесываю беклог.
Голова после выходных загружена меньше, а значит качество планов — выше: задачи понятны и достаточно проработаны; везде заложены достаточные запасы времени; неважные задачи удалены или убраны в беклог.
Внедрить это правило очень просто — коллеги привыкают через две недели, а внешним ребятам достаточно говорить, что весь понедельник уже расписан.
В терминологии ГТД мой личный понедельник называется «еженедельный обзор».
По-моему это актуально не только для дизайна интерфейсов, но ещё для программирования, торговли помидорами и любой другой сферы, где можно измерить качество.
Forwarded from Без шелухи
😈 Потрясающий интерфейс и отвратительная морда
За последние недели несколько человек написали мне сообщения с общей темой «ты вот топишь за хорошие интерфейсы, а что толку — менеджмент всё равно всегда выбирает какаху, лишь бы подешевле».
Мне кажется, тут недопонимание.
На самом деле, нет выбора между «божественно прекрасный интерфейс задорого» и «самое убогое во вселенной отстоище задёшево». Обычно есть как минимум такие варианты:
1. Сделать плохо, потратив N ресурсов.
2. Сделать нормально, потратив те же N (или чуть больше) ресурсов.
3. Сделать отлично, потратив k*N ресурсов.
Понимать принципы создания хороших интерфейсов стоит хотя бы для того, чтобы видеть вариант 2. Иначе вы остаётесь только со «сделать плохо».
Действительно, далеко не всегда вы пойдёте по варианту 3 — потому что есть ограничения и есть приоритеты. Но почти никогда не останетесь с вариантом 1, потому что между «сделать плохо» и «сделать нормально за те же деньги» нормальный менеджер всегда выберет «сделать нормально».
За последние недели несколько человек написали мне сообщения с общей темой «ты вот топишь за хорошие интерфейсы, а что толку — менеджмент всё равно всегда выбирает какаху, лишь бы подешевле».
Мне кажется, тут недопонимание.
На самом деле, нет выбора между «божественно прекрасный интерфейс задорого» и «самое убогое во вселенной отстоище задёшево». Обычно есть как минимум такие варианты:
1. Сделать плохо, потратив N ресурсов.
2. Сделать нормально, потратив те же N (или чуть больше) ресурсов.
3. Сделать отлично, потратив k*N ресурсов.
Понимать принципы создания хороших интерфейсов стоит хотя бы для того, чтобы видеть вариант 2. Иначе вы остаётесь только со «сделать плохо».
Действительно, далеко не всегда вы пойдёте по варианту 3 — потому что есть ограничения и есть приоритеты. Но почти никогда не останетесь с вариантом 1, потому что между «сделать плохо» и «сделать нормально за те же деньги» нормальный менеджер всегда выберет «сделать нормально».
Два года назад я подобрал замену эверноуту — Simplenote в связке с nvALT. С тех пор эверноут стал еще жирнее, Apple в 10 раз улучшил Notes, но я все еще пользуюсь своей связкой.
Если вы, как и я, экономите время за компьютером и не боитесь клавиатурной навигации, прочитайте заметку о причинах перехода. Обе программы — бесплатные.
Если вы, как и я, экономите время за компьютером и не боитесь клавиатурной навигации, прочитайте заметку о причинах перехода. Обе программы — бесплатные.
Top-down и прогрессивный джипег для программистов
Правило Парето гласит, что 80% времени программиста тратится на 20% требований. К примеру, на любом современном фронтенд-фреймворке работающую корзину в интернет-магазине можно запилить за день — можно будет добавить/удалить товар и отправить заказ.
А потом еще неделю потратить на полировку — отмену удаления, возможность менять конфигурацию товара, промо-коды и расчет доставки. Обидно, если после запуска окажется, что пользователи склонны делать заказ по телефону и вообще не пользуются корзиной.
Хороший программист делает код, который с самого начала разработки умеет выполнять главную задачу. В случае с корзиной, главная задача — доставлять заказы до менеджеров в любом виде, хоть один номер телефона. А когда основные 20% функций готовы, программист, вместе с бизнесом, детализирует остальные требования. Если они еще актуальны, конечно.
Инженеры называют этот подход top-down, дизайнеры — прогрессивным джипегом.
Правило Парето гласит, что 80% времени программиста тратится на 20% требований. К примеру, на любом современном фронтенд-фреймворке работающую корзину в интернет-магазине можно запилить за день — можно будет добавить/удалить товар и отправить заказ.
А потом еще неделю потратить на полировку — отмену удаления, возможность менять конфигурацию товара, промо-коды и расчет доставки. Обидно, если после запуска окажется, что пользователи склонны делать заказ по телефону и вообще не пользуются корзиной.
Хороший программист делает код, который с самого начала разработки умеет выполнять главную задачу. В случае с корзиной, главная задача — доставлять заказы до менеджеров в любом виде, хоть один номер телефона. А когда основные 20% функций готовы, программист, вместе с бизнесом, детализирует остальные требования. Если они еще актуальны, конечно.
Инженеры называют этот подход top-down, дизайнеры — прогрессивным джипегом.
Почему я выбираю кандидатов с живым гитхабом
Недавно на хабре проскакивала статья о том, что не стоит смотреть на профиль в гитхабе при найме программистов. Автор утверждал, что программисту вовсе не обязательно все свободное время посвящать разработке, чтобы писать хороший код. Типа «Самый лучший программист, которого я знаю, вообще не имел ни одного коммита на гитхабе».
Такая аргументация работает только для больших компаний, которые сидят на горе кода из 2010 года и наладили процесс обучения и внедрения новых программистов.
В стартапах все по-другому. Программист в стартапе должен обладать нетипичными для больших компаний навыками:
— Быстро въехать. Легаси у меня нет, и я не хочу, чтобы кто-то за деньги инвесторов просто изучал новые технологии.
— Не бояться отрывать жопу от стула и выходить за рамки. Это стартап, тут CTO может подменить грузчика.
— Уметь доводить дела до конца. Менеджеров, которые с палкой следят за дедлайнами, у нас тоже нет.
Хороший профиль на гитхабе (с контрибьютами и запущенными проектами) косвенно подтверждает все эти умения. Отсутствие профиля вынуждает нанимателя проверять их наличие за деньги.
#работамечты
Недавно на хабре проскакивала статья о том, что не стоит смотреть на профиль в гитхабе при найме программистов. Автор утверждал, что программисту вовсе не обязательно все свободное время посвящать разработке, чтобы писать хороший код. Типа «Самый лучший программист, которого я знаю, вообще не имел ни одного коммита на гитхабе».
Такая аргументация работает только для больших компаний, которые сидят на горе кода из 2010 года и наладили процесс обучения и внедрения новых программистов.
В стартапах все по-другому. Программист в стартапе должен обладать нетипичными для больших компаний навыками:
— Быстро въехать. Легаси у меня нет, и я не хочу, чтобы кто-то за деньги инвесторов просто изучал новые технологии.
— Не бояться отрывать жопу от стула и выходить за рамки. Это стартап, тут CTO может подменить грузчика.
— Уметь доводить дела до конца. Менеджеров, которые с палкой следят за дедлайнами, у нас тоже нет.
Хороший профиль на гитхабе (с контрибьютами и запущенными проектами) косвенно подтверждает все эти умения. Отсутствие профиля вынуждает нанимателя проверять их наличие за деньги.
#работамечты
Нерешаемая задача
В общении с плохими программистами (и сантехниками) часто проскакивает тон «это нерешаемая задача»:
— Давай сделаем, чтобы по нажатию на кнопку уходило письмо клиенту? Не, не получится, мы в этот момент ещё не авторизованы на бекенде.
— Давай передавать данные о телефонных заказах в Гугль-аналитику? Не получится, мы для таких заказов не знаем ИД аналитики.
Это — плохие ответы. Для хороших ответов есть простое правило: в любом письме предлагай решение. Даже если оно будет безумным и нерациональным — не бойся: предложи и напиши об этом.
— Давай сделаем, чтобы по нажатию на кнопку уходило письмо клиенту? Давай, только придётся отключить авторизацию для этого эндпоинта и кто угодно сможет запустить такую отправку.
— Давай передавать данные о телефонных заказах в Гугль-аналитику? Давай, только можем либо забить на идентификаторы пользователей, либо интегрироваться с внешним коллтрекингом.
Будьте решателями проблем, а не создавателями.
В общении с плохими программистами (и сантехниками) часто проскакивает тон «это нерешаемая задача»:
— Давай сделаем, чтобы по нажатию на кнопку уходило письмо клиенту? Не, не получится, мы в этот момент ещё не авторизованы на бекенде.
— Давай передавать данные о телефонных заказах в Гугль-аналитику? Не получится, мы для таких заказов не знаем ИД аналитики.
Это — плохие ответы. Для хороших ответов есть простое правило: в любом письме предлагай решение. Даже если оно будет безумным и нерациональным — не бойся: предложи и напиши об этом.
— Давай сделаем, чтобы по нажатию на кнопку уходило письмо клиенту? Давай, только придётся отключить авторизацию для этого эндпоинта и кто угодно сможет запустить такую отправку.
— Давай передавать данные о телефонных заказах в Гугль-аналитику? Давай, только можем либо забить на идентификаторы пользователей, либо интегрироваться с внешним коллтрекингом.
Будьте решателями проблем, а не создавателями.
Рациональная фантастика
Редко читаю (а тем более советую) художку, но мимо этой серии пройти невозможно. Трилогия называется «Воспоминания о прошлом земли», написал ее китаец Лю Цысинь.
Читать стоит из-за наглядных, пронизывающих каждую страницу, научных отсылок — к политике, социологии и теории игр. Если хотите почитать что-нибудь не про работу, но полезное для саморазвития — самое оно.
Серия начинается в наше время и заканчивается в далеком будущем. По ходу повествования автор вводит все новые и более удивительные концепции, начиная с очевидных научных открытий вроде нановолокон, и заканчивая выглядящим реально глубоким космосом.
О художественной части я могу судить только на уровне «интересно-не интересно». «Воспоминания» — интересно.
Похоже всю серию на русском так и не выпустили, так что гуглите английскую The Remembrance of Earth's Past.
Редко читаю (а тем более советую) художку, но мимо этой серии пройти невозможно. Трилогия называется «Воспоминания о прошлом земли», написал ее китаец Лю Цысинь.
Читать стоит из-за наглядных, пронизывающих каждую страницу, научных отсылок — к политике, социологии и теории игр. Если хотите почитать что-нибудь не про работу, но полезное для саморазвития — самое оно.
Серия начинается в наше время и заканчивается в далеком будущем. По ходу повествования автор вводит все новые и более удивительные концепции, начиная с очевидных научных открытий вроде нановолокон, и заканчивая выглядящим реально глубоким космосом.
О художественной части я могу судить только на уровне «интересно-не интересно». «Воспоминания» — интересно.
Похоже всю серию на русском так и не выпустили, так что гуглите английскую The Remembrance of Earth's Past.
Процесс → результат
HR-ы делят людей на две группы — ориентированных на процесс и на результат. В их мире деление достаточно жесткое — люди, ориентированные на результат, подходят для бóльшей ответственности, а ориентированные на процесс — для меньшей. С программистами такое деление не работает — ориентированные строго на результат склонны писать говнокод, а ориентированные строго на процесс — решать задачу хорошо, но никогда.
Программист (как и HR, кстати) — профессия процессная, поэтому лучше нанимать процессных программистов, и учить их добиваться результата в вашей команде. По моему опыту это гораздо легче, чем научить результативников поддерживать правильный процесс.
Перефокусироваться с процесса на результат — тяжело: это связано с индивидуальными особенностями личности. Мне в свое время помогали простые вопросы про бизнес:
— Зачем я вообще делаю эту задачу? Кто ожидает от нее результат? Как этот результат выглядит?
— Как бизнес получал бы результат, если бы меня не было? Как бы я мог бы им в этом помочь?
— Если бы я мог потратить на эту задачу всего 30 минут, какими бы ее частями я пожертвовал, чтобы бизнесу было наименее больно?
— Какая самая сложная часть задачи? Что можно изменить в постановке, чтобы избавиться от нее?
Если вы — процессник, и будете задавать себе такие вопросы про каждую полученную задачу, то со временем научитесь ставить задачи лучше, чем бизнес, и вас начнут ценить как синьора. А говнокодить все равно не начнете.
HR-ы делят людей на две группы — ориентированных на процесс и на результат. В их мире деление достаточно жесткое — люди, ориентированные на результат, подходят для бóльшей ответственности, а ориентированные на процесс — для меньшей. С программистами такое деление не работает — ориентированные строго на результат склонны писать говнокод, а ориентированные строго на процесс — решать задачу хорошо, но никогда.
Программист (как и HR, кстати) — профессия процессная, поэтому лучше нанимать процессных программистов, и учить их добиваться результата в вашей команде. По моему опыту это гораздо легче, чем научить результативников поддерживать правильный процесс.
Перефокусироваться с процесса на результат — тяжело: это связано с индивидуальными особенностями личности. Мне в свое время помогали простые вопросы про бизнес:
— Зачем я вообще делаю эту задачу? Кто ожидает от нее результат? Как этот результат выглядит?
— Как бизнес получал бы результат, если бы меня не было? Как бы я мог бы им в этом помочь?
— Если бы я мог потратить на эту задачу всего 30 минут, какими бы ее частями я пожертвовал, чтобы бизнесу было наименее больно?
— Какая самая сложная часть задачи? Что можно изменить в постановке, чтобы избавиться от нее?
Если вы — процессник, и будете задавать себе такие вопросы про каждую полученную задачу, то со временем научитесь ставить задачи лучше, чем бизнес, и вас начнут ценить как синьора. А говнокодить все равно не начнете.
Сервис: netlify.com
Люблю инфраструктурные сервисы, которые не жалеют денег на дизайнеров. Сегодня хочу рассказать о netlify.com — сервисе для хостинга современных фронтенд-приложений, как они сами себя позиционируют.
Ребята выявили и идеально закрыли конкретную боль фронтендеров — до появления сервиса, чтобы опубликовать даже самое простое приложение, приходилось идти к девопсам — поднимать CI, разбираться в хостинге и DNS.
Нетлифай закрывает вопрос полностью — в нем есть CI (который не надо настраивать!), быстрый хостинг на амазоне, автоматический DNS и деплой-превью. Если остается желание, то в каждую часть процесса можно влезть и что-нибудь покрутить — сделать домен верхнего уровня, настроить редиректы или проксирование, докрутить CI.
Деплой-превью — самая большая ценность: к примеру мы в mtrl.ai делаем на нем превью веток с фичами. Достаточно развернуть где-нибудь бекенд, отключенный от интеграций, настроить проксирование, и бум — в каждом PR на гитхабе появляется волшебная ссылочка на превью.
И все это бесплатно.
Люблю инфраструктурные сервисы, которые не жалеют денег на дизайнеров. Сегодня хочу рассказать о netlify.com — сервисе для хостинга современных фронтенд-приложений, как они сами себя позиционируют.
Ребята выявили и идеально закрыли конкретную боль фронтендеров — до появления сервиса, чтобы опубликовать даже самое простое приложение, приходилось идти к девопсам — поднимать CI, разбираться в хостинге и DNS.
Нетлифай закрывает вопрос полностью — в нем есть CI (который не надо настраивать!), быстрый хостинг на амазоне, автоматический DNS и деплой-превью. Если остается желание, то в каждую часть процесса можно влезть и что-нибудь покрутить — сделать домен верхнего уровня, настроить редиректы или проксирование, докрутить CI.
Деплой-превью — самая большая ценность: к примеру мы в mtrl.ai делаем на нем превью веток с фичами. Достаточно развернуть где-нибудь бекенд, отключенный от интеграций, настроить проксирование, и бум — в каждом PR на гитхабе появляется волшебная ссылочка на превью.
И все это бесплатно.
Старая заметка о том, почему слэк (и другие чатики) не добавляют продуктивности, а наоборот, крадут. Со времени написания заметки слэк получил 600 миллионов долларов инвестиций, стал в два раза жирнее, но не прибавил ни капельке пользы.
Скиньте эту ссылку прямо сейчас в свой рабочий слек — https://borshev.com/slack-productivity/
Скиньте эту ссылку прямо сейчас в свой рабочий слек — https://borshev.com/slack-productivity/
t.iss.one
Как корпоративный чат убивает продуктивность
В разное время я пробовал разные корпоративные чаты — джабер, ирку (кто-нибудь еще помнит?), скайп, группы в популярных мессенджерах. В этой заметке я расскажу, почему все они вредят производительности, а лучшее средство для проектного общения — электронная…
Продолжение вчерашней темы. В слеке не работает важнейшее правило электронного общения: одно сообщение — один вопрос. Почитайте Тему вот:
Forwarded from Артемий Лебедев
Наиболее эффективная коммуникация
У всех людей разные привычки и возможности общения. Я для себя открыл наиболее эффективный способ общения: одно дело в одном сообщении.
Чтобы максимально быстро получить ответ от меня, нужно прислать ровно одно письмо ровно с одним вопросом или ровно с одной картинкой.
Если в письме два вопроса, у меня может быть ответ на первый, а на второй еще нет. Так что такое письмо надолго застрянет в моем инбоксе. То же и с картинкой - ответ будет максимально быстрый: да или нет. А две, пять, десять картинок могут потребовать обстоятельности, которая может отсутствовать на данный момент.
Люди, которые задают в одном письме четыре вопроса, обречены на неответ с моей стороны. (Люди, которые присылают четыре письма подряд, тоже обречены на неответ, если я их не приглашал писать мне.)
Таким образом я успеваю сделать больше, чем те, кто пытаются быть универсальными отвечателями на произвольный формат инфозагруза.
- Это поэтому ты так много успеваешь? А ты сам придумал этот лайфхак? А как мне научиться делать как ты?
- ...
У всех людей разные привычки и возможности общения. Я для себя открыл наиболее эффективный способ общения: одно дело в одном сообщении.
Чтобы максимально быстро получить ответ от меня, нужно прислать ровно одно письмо ровно с одним вопросом или ровно с одной картинкой.
Если в письме два вопроса, у меня может быть ответ на первый, а на второй еще нет. Так что такое письмо надолго застрянет в моем инбоксе. То же и с картинкой - ответ будет максимально быстрый: да или нет. А две, пять, десять картинок могут потребовать обстоятельности, которая может отсутствовать на данный момент.
Люди, которые задают в одном письме четыре вопроса, обречены на неответ с моей стороны. (Люди, которые присылают четыре письма подряд, тоже обречены на неответ, если я их не приглашал писать мне.)
Таким образом я успеваю сделать больше, чем те, кто пытаются быть универсальными отвечателями на произвольный формат инфозагруза.
- Это поэтому ты так много успеваешь? А ты сам придумал этот лайфхак? А как мне научиться делать как ты?
- ...
Стейджинг → деплой превью
Стейджинг — это такой сервер, на котором показывают промежуточный результат перед публикацией. Дело в общем-то хорошее, если забыть, что фичи нужно презентовать лично.
К сожалению, я пока не встречал ни одной хорошей реализации стейджинга в маленькой команде. Болезни у всех одинаковые —путаница в ветках гита или гвозди, забитые микроскопом вроде кубернейтса.
Расскажу про наш сетап. Про первую часть я уже писал в заметке про нетлифай — это автоматическая публикация веток фронтенда на поддоменах. На каждый ПР у нас появляется ссылка вида
С бекендом почти так же просто — если вы пилите сайт, то хватает ровно того же бекенда, что смотрит в мир. Если пилите что-то посложнее, что ходит в бекенд не только через GET, то обойтись без демонстрационного сервера не получится.
У нас это специальная машина на селектеле, на которой через docker-compose крутится минимальная инфраструктура, отключенная от внешних интеграций. Образы постоянно обновляются через ночные сборки в CI, включая полную копию рабочей базы.
Фичи, которые затрагивают бекенд, обычно выкатываем прямо в продакшн, еще до запуска фронта. Так можно делать, если вы не нарушаете обратную совместимость (вы же только добавляете поля в API, а не удаляете, правда?). Затем фича через ночные сборки попадает на демонстрационный бекенд, куда уже ходят фронтовые превью.
Конечно, деплой-превью никогда не заменит человеческого общения — скорее это просто удобное средство для презентаций. Но про это я расскажу как-нибудь отдельно.
Стейджинг — это такой сервер, на котором показывают промежуточный результат перед публикацией. Дело в общем-то хорошее, если забыть, что фичи нужно презентовать лично.
К сожалению, я пока не встречал ни одной хорошей реализации стейджинга в маленькой команде. Болезни у всех одинаковые —путаница в ветках гита или гвозди, забитые микроскопом вроде кубернейтса.
Расскажу про наш сетап. Про первую часть я уже писал в заметке про нетлифай — это автоматическая публикация веток фронтенда на поддоменах. На каждый ПР у нас появляется ссылка вида
deploy-preview--<feature>--<project>.netlify.com.С бекендом почти так же просто — если вы пилите сайт, то хватает ровно того же бекенда, что смотрит в мир. Если пилите что-то посложнее, что ходит в бекенд не только через GET, то обойтись без демонстрационного сервера не получится.
У нас это специальная машина на селектеле, на которой через docker-compose крутится минимальная инфраструктура, отключенная от внешних интеграций. Образы постоянно обновляются через ночные сборки в CI, включая полную копию рабочей базы.
Фичи, которые затрагивают бекенд, обычно выкатываем прямо в продакшн, еще до запуска фронта. Так можно делать, если вы не нарушаете обратную совместимость (вы же только добавляете поля в API, а не удаляете, правда?). Затем фича через ночные сборки попадает на демонстрационный бекенд, куда уже ходят фронтовые превью.
Конечно, деплой-превью никогда не заменит человеческого общения — скорее это просто удобное средство для презентаций. Но про это я расскажу как-нибудь отдельно.
Сервис: datadoghq.com
Сегодня расскажу о важной штуке — Application Performance Monitor, или APM. APM нужна программистам, чтобы анализировать скорость работы кода прямо в продакшене.
Когда приходит тикет «АА, у меня сайт тормозит», программист без APM вынужден поднимать инфраструктуру на локальной машине и долго созерцать код в попытках угадать узкое место. Программист с APM просто заходит в удобный интерфейс и смотрит трейсы — слепки из живых ответов системы, на которых видно распределение времени между частями программы. Думать вообще не надо — все узкие места как на ладони.
Датадог — один из трех доступных на рынке APM для питона (есть еще new relic и obeat). Кроме APM, содержит в себе еще развитую систему мониторинга серверов — снимает метрики с железа и контейнеров, шлет уведомления, и интегрируется с тоннами систем.
Цены у него не очень демократичные, но для коробочного решения, полностью закрывающего проблему мониторинга доступности и производительности — вполне ок.
Сегодня расскажу о важной штуке — Application Performance Monitor, или APM. APM нужна программистам, чтобы анализировать скорость работы кода прямо в продакшене.
Когда приходит тикет «АА, у меня сайт тормозит», программист без APM вынужден поднимать инфраструктуру на локальной машине и долго созерцать код в попытках угадать узкое место. Программист с APM просто заходит в удобный интерфейс и смотрит трейсы — слепки из живых ответов системы, на которых видно распределение времени между частями программы. Думать вообще не надо — все узкие места как на ладони.
Датадог — один из трех доступных на рынке APM для питона (есть еще new relic и obeat). Кроме APM, содержит в себе еще развитую систему мониторинга серверов — снимает метрики с железа и контейнеров, шлет уведомления, и интегрируется с тоннами систем.
Цены у него не очень демократичные, но для коробочного решения, полностью закрывающего проблему мониторинга доступности и производительности — вполне ок.
