Circle CI: Ночные сборки
Workflows в Circle CI — это мощнейший инструмент для автоматизации девопса. В простом варианте (build → test → deploy) его использует все, а в этой заметке я расскажу про де полезные вещи, которые можно делать с помощью расписания workflows.
В mtrl.ai мы активно пользуемся ночными сборками. То есть просто каждую ночь собираем проект, тегаем текущей датой и раскладываем образы по песочницам для программистов и тестовым стендам. Получается, что в обмен всего на 10 строк в YAML-файле у нас появляются автоматически обновляемые песочницы!
Кроме ночных сборок, при помощи circle мы каждую ночь собираем докер-образы с нашей базой данных, доступные всей команде.
Такие образы гарантируют, что фронтендер всегда работает со свежими данными с прода — больше никаких рыбных текстов или таблиц, поехавших после публикации на проде.
У бекендеров тоже куча применений для таких образов — начиная от проверки миграций, и заканчивая поисками сложных багов.
Хитрости в процессе сборки образа с БД:
— Нужно делать его максимально тонким. Мы, к примеру, не берем в образ записи пользовательского журнала, телефонных звонков и других данных, которые нужны раз в год и не критичны для работы приложения.
— Образ с базой нужно тегать текущей датой. Так вы получите (почти) полный автоматический бекап своей базы прямо в докерхабе, если у вас не кастомный реестр контейнеров, конечно.
Workflows в Circle CI — это мощнейший инструмент для автоматизации девопса. В простом варианте (build → test → deploy) его использует все, а в этой заметке я расскажу про де полезные вещи, которые можно делать с помощью расписания workflows.
В mtrl.ai мы активно пользуемся ночными сборками. То есть просто каждую ночь собираем проект, тегаем текущей датой и раскладываем образы по песочницам для программистов и тестовым стендам. Получается, что в обмен всего на 10 строк в YAML-файле у нас появляются автоматически обновляемые песочницы!
Кроме ночных сборок, при помощи circle мы каждую ночь собираем докер-образы с нашей базой данных, доступные всей команде.
Такие образы гарантируют, что фронтендер всегда работает со свежими данными с прода — больше никаких рыбных текстов или таблиц, поехавших после публикации на проде.
У бекендеров тоже куча применений для таких образов — начиная от проверки миграций, и заканчивая поисками сложных багов.
Хитрости в процессе сборки образа с БД:
— Нужно делать его максимально тонким. Мы, к примеру, не берем в образ записи пользовательского журнала, телефонных звонков и других данных, которые нужны раз в год и не критичны для работы приложения.
— Образ с базой нужно тегать текущей датой. Так вы получите (почти) полный автоматический бекап своей базы прямо в докерхабе, если у вас не кастомный реестр контейнеров, конечно.
TCO, или полная стоимость фичи
Каждая фича, которую вы впиливаете в продукт, стоит денег. Причем бóльшую часть этих денег вы отдаете не за производство фичи, а за поддержку ее на плаву. И чем больше времени фича живет (пусть и заброшенная), тем больше она стóит.
Помните, ту выгрузку в эксель, которую вы сделали год назад за вечер, потому что конец квартала? За год она 5 раз сломалась в процессе разработки, один раз в релизе, не дала команде перейти на новый HTTP-фреймворк и повлияла на тимлида, склонив выбрать неудачный подход к функциональному тестированию (правда он этого не понял).
И неважно, что выгрузкой за год воспользовались два раза — ни один из инженеров, который ее касался, об этом не знал, а значит тратил на нее столько же времени, сколько и на любой другой код в приложении.
Для большинства программистов ваша выгрузка в эксель ничем не отличается от, скажем, авторизации по СМС, которой пользуются 1000 раз в день. Так уж устроен мозг программиста.
На своих проектах я даже поддерживаю процесс выпиливания фич — прям каждый спринт мы ищем и удаляем куски кода от фич, которые не заработали. Иначе бы нам пришлось тянуть в будущее код, который не выполняется, но требует поддержки и денег.
Каждая фича, которую вы впиливаете в продукт, стоит денег. Причем бóльшую часть этих денег вы отдаете не за производство фичи, а за поддержку ее на плаву. И чем больше времени фича живет (пусть и заброшенная), тем больше она стóит.
Помните, ту выгрузку в эксель, которую вы сделали год назад за вечер, потому что конец квартала? За год она 5 раз сломалась в процессе разработки, один раз в релизе, не дала команде перейти на новый HTTP-фреймворк и повлияла на тимлида, склонив выбрать неудачный подход к функциональному тестированию (правда он этого не понял).
И неважно, что выгрузкой за год воспользовались два раза — ни один из инженеров, который ее касался, об этом не знал, а значит тратил на нее столько же времени, сколько и на любой другой код в приложении.
Для большинства программистов ваша выгрузка в эксель ничем не отличается от, скажем, авторизации по СМС, которой пользуются 1000 раз в день. Так уж устроен мозг программиста.
На своих проектах я даже поддерживаю процесс выпиливания фич — прям каждый спринт мы ищем и удаляем куски кода от фич, которые не заработали. Иначе бы нам пришлось тянуть в будущее код, который не выполняется, но требует поддержки и денег.
Почему нужно записывать видео и делать скриншоты
Самый лучший способ разобраться в теме — попробовать ее объяснить кому-нибудь другому. Именно по этому мы в mtrl.ai требуем, чтобы в каждой задаче был минимум один скриншот\видео — в начале (что делаем), и в конце (что стало).
Скриншот в начале помогает сориентироваться в постановке задачи. Убедиться, что автор понимает в состоянии внятно проиллюстрировать задачу. Если вдруг это не так, значит задача — говно, и лучше на нее не тратить ничье время.
Скриншот (а лучше видео) в конце задачи помогает убедиться, что программист осознал юзкейс, воспроизвел его и проверил в понятном для пользователя виде (почему-то не все пользователи понимают вывод pytest).
Скриншоты и видео — это как юнит-тесты, только для задачи — четкое и ясное доказательство того, что задача поставлена и выполнена.
Самый лучший способ разобраться в теме — попробовать ее объяснить кому-нибудь другому. Именно по этому мы в mtrl.ai требуем, чтобы в каждой задаче был минимум один скриншот\видео — в начале (что делаем), и в конце (что стало).
Скриншот в начале помогает сориентироваться в постановке задачи. Убедиться, что автор понимает в состоянии внятно проиллюстрировать задачу. Если вдруг это не так, значит задача — говно, и лучше на нее не тратить ничье время.
Скриншот (а лучше видео) в конце задачи помогает убедиться, что программист осознал юзкейс, воспроизвел его и проверил в понятном для пользователя виде (почему-то не все пользователи понимают вывод pytest).
Скриншоты и видео — это как юнит-тесты, только для задачи — четкое и ясное доказательство того, что задача поставлена и выполнена.
Не терпеть говно вокруг себя
Важный навык, которого не хватает многим соотечественникам — говорить о проблемах. Это когда ты утыкаешься в какую-нибудь неудобную хуйню, типа CI который работает 15 минут вместо 2, и, вместо того, чтобы обсудить эту хуйню с руководителем или тем, кто может исправить, просто сидишь и молча страдаешь.
Частично это решает скрам с его ежедневными встречами, на которых в общем-то принято рассказывать о трудностях в работе. Но только частично — вещи, которые плохо работают давно, вроде длительности CI, которая росла до 15 минут по 1 минуте в неделю, это не выявляет.
Чтобы научиться не терпеть говно вокруг себя, надо немного подвинуть парадигму. В первую очередь нужно осознать, что руководителю твоя производительность более выгодна, чем тебе (ведь это же ты на него работаешь, а не он на тебя).
Во-вторых, нужно просто перестать терпеть говно. Если тебя беспокоит процесс CI — добейся того, чтобы он стал работать быстро: допинай руководителя, поговори с тем, кто умеет это чинить, почитай документацию сам, наконец.
Если получаешь отпор, типа «и так работает» — подумай, в той ли лодке ты сидишь? Чему, кроме терпимости, ты научишься у людей, которые терпят вокруг себя говно?
Важный навык, которого не хватает многим соотечественникам — говорить о проблемах. Это когда ты утыкаешься в какую-нибудь неудобную хуйню, типа CI который работает 15 минут вместо 2, и, вместо того, чтобы обсудить эту хуйню с руководителем или тем, кто может исправить, просто сидишь и молча страдаешь.
Частично это решает скрам с его ежедневными встречами, на которых в общем-то принято рассказывать о трудностях в работе. Но только частично — вещи, которые плохо работают давно, вроде длительности CI, которая росла до 15 минут по 1 минуте в неделю, это не выявляет.
Чтобы научиться не терпеть говно вокруг себя, надо немного подвинуть парадигму. В первую очередь нужно осознать, что руководителю твоя производительность более выгодна, чем тебе (ведь это же ты на него работаешь, а не он на тебя).
Во-вторых, нужно просто перестать терпеть говно. Если тебя беспокоит процесс CI — добейся того, чтобы он стал работать быстро: допинай руководителя, поговори с тем, кто умеет это чинить, почитай документацию сам, наконец.
Если получаешь отпор, типа «и так работает» — подумай, в той ли лодке ты сидишь? Чему, кроме терпимости, ты научишься у людей, которые терпят вокруг себя говно?
Код для космических кораблей
Недавно наткнулся на адски-сложный код в исходниках кубернейтс. Сложность заключается в огромном количестве ветвлений — сложно понять, что делает код, даже будучи глубоко в контексте.
В шапке прям большими буквами написано — «пожалуйста, не пытайтесь ничего упрощать». Автор рассказывает, что такой код пишут для космических кораблей в NASA — каждый if должен обязательно содержать свой else, чтобы убедиться, что программист предусмотрел вообще все возможные ситуации. Даже те, которые никогда не случатся.
По словам автора, такой «подробный» код легче поддерживать (не вообще, а конкретно в этом месте). Учитывая, что код отвечает за Persistent Volumes, в это хочется поверить.
Почему бы просто не покрыть все тестами на 100% и не переписать понятно и с нуля?
Потому, что код выполняется в средах, где ОЧЕНЬ много одновременных вычислений. Ситуация точно такая же, как с космическим кораблем: единственное место, в котором возможно провести полноценное интеграционное тестирование — это космос. В случае с Persistent Volumes в k8s — это супернагруженные системы, которые хранят наши с вами данные, к примеру вот эту заметку. Или код, который вы писали весь прошлый год.
Стоит ли писать такую лапшу на работе? Нет, не стоит. Нужно ли отступать от правил, когда это требуется для бизнес-задачи? Да, нужно.
Недавно наткнулся на адски-сложный код в исходниках кубернейтс. Сложность заключается в огромном количестве ветвлений — сложно понять, что делает код, даже будучи глубоко в контексте.
В шапке прям большими буквами написано — «пожалуйста, не пытайтесь ничего упрощать». Автор рассказывает, что такой код пишут для космических кораблей в NASA — каждый if должен обязательно содержать свой else, чтобы убедиться, что программист предусмотрел вообще все возможные ситуации. Даже те, которые никогда не случатся.
По словам автора, такой «подробный» код легче поддерживать (не вообще, а конкретно в этом месте). Учитывая, что код отвечает за Persistent Volumes, в это хочется поверить.
Почему бы просто не покрыть все тестами на 100% и не переписать понятно и с нуля?
Потому, что код выполняется в средах, где ОЧЕНЬ много одновременных вычислений. Ситуация точно такая же, как с космическим кораблем: единственное место, в котором возможно провести полноценное интеграционное тестирование — это космос. В случае с Persistent Volumes в k8s — это супернагруженные системы, которые хранят наши с вами данные, к примеру вот эту заметку. Или код, который вы писали весь прошлый год.
Стоит ли писать такую лапшу на работе? Нет, не стоит. Нужно ли отступать от правил, когда это требуется для бизнес-задачи? Да, нужно.
Devops и маленькие команды
Каждый раз, когда от небольших ребят я слышу понятие dev-сервера, я настораживаюсь.
Обычно под этим именем скрывается специально выделенная машина, на которую программисты заливают код. И наличие такой машины означает, что в команде серьезные проблемы с девопсом.
Когда с девопсом все хорошо, то любой кусок инфраструктуры в актуальном состоянии можно развернуть хоть на утюге — фронтендеры держат бекенд на локальной машине, обновляя код и данные хоть по 10 раз в день; на каждую ветку в гите разворачивается деплой-превью; QA может отдельно комбинировать любые ветки и запускать все у себя на машине.
Неважно, сколько у вас программистов — 2 или 50, все равно вам нужен нормальный девопс: вы же не хотите, чтобы вместо вашей фичи программисты занимались перекладыванием файлов или настройкой nginx?
Каждый раз, когда от небольших ребят я слышу понятие dev-сервера, я настораживаюсь.
Обычно под этим именем скрывается специально выделенная машина, на которую программисты заливают код. И наличие такой машины означает, что в команде серьезные проблемы с девопсом.
Когда с девопсом все хорошо, то любой кусок инфраструктуры в актуальном состоянии можно развернуть хоть на утюге — фронтендеры держат бекенд на локальной машине, обновляя код и данные хоть по 10 раз в день; на каждую ветку в гите разворачивается деплой-превью; QA может отдельно комбинировать любые ветки и запускать все у себя на машине.
Неважно, сколько у вас программистов — 2 или 50, все равно вам нужен нормальный девопс: вы же не хотите, чтобы вместо вашей фичи программисты занимались перекладыванием файлов или настройкой nginx?
Бесплатные репозитории на гитхабе, это случилось
Спустя 10 лет, гитхаб таки подарил всем разработчикам приватные репозитории на бесплатном тарифе.
Платная подписка теперь называется «Pro», и отличается от бесплатной только беджиком в профиле и тем, что в приватные репозитории можно добавлять больше трех участников. Еще в бесплатных репозиториях не работают всякие мелочи вроде вики, pages или защищенных веток, но без них вполне можно жить.
Это очень важная веха на пути гитхаба, потому что отсутствие приватных репозиториев — по большому счету единственное, что заставляло людей пользоваться гитлабом и битбакетом с их упоротыми UI.
Давайте порадуемся за команду гитхаба, которая продолжает принимать сильные решения под влиянием майкрософта. Ну и конечно за программистов, которые наконец-то могут выкладывать личные проекты на удобный хостинг не тратя ни копейки.
#гитхаб
Спустя 10 лет, гитхаб таки подарил всем разработчикам приватные репозитории на бесплатном тарифе.
Платная подписка теперь называется «Pro», и отличается от бесплатной только беджиком в профиле и тем, что в приватные репозитории можно добавлять больше трех участников. Еще в бесплатных репозиториях не работают всякие мелочи вроде вики, pages или защищенных веток, но без них вполне можно жить.
Это очень важная веха на пути гитхаба, потому что отсутствие приватных репозиториев — по большому счету единственное, что заставляло людей пользоваться гитлабом и битбакетом с их упоротыми UI.
Давайте порадуемся за команду гитхаба, которая продолжает принимать сильные решения под влиянием майкрософта. Ну и конечно за программистов, которые наконец-то могут выкладывать личные проекты на удобный хостинг не тратя ни копейки.
#гитхаб
Как мы используем Чатру для поддержки
Есть много сервисов для общения с пользователями, начиная от монстров вроде zendesk или jira service desk, и заканчивая моим любимым хипстерским Groove.
Однако для себя мы выбрали еще более простое решение — Чатру. Самое главное преимущество Чатры — в нее действительно легко написать. В отличие от традиционного сервисдескного софта, Чатру делали не для того, чтобы облегчить жизнь саппортерам, а чтобы общаться с пользователями на сайте — этот как всем надоевший «живой консультант» на плохих интернет-магазинах, только аккуратный и ненавязчивый.
Нам важно, чтобы любой сотрудник в компании легко мог написать о любой мысли или проблеме — это критично, когда у твоего продукта не 500 000 пользователей, а всего 100, но зато супер-важных.
С Чатрой мы избежали появления еще одного источника правды — обычный софт для хелпдеска обязательно содержит встроенный трекер, где все обращения пользователей превращаются в новые задачи. Такие задачи надо как-то закрывать, измерять, отслеживать появление нового.
От Чатры никто не ждет порядка — это же бесконечный чат. Если в чате появляется что-то, что нужно сделать или обдумать, то мы просто пишем письмо ответственному. Если баг — исправляем дежурным программистом.
Конечно, с такой системой мы никогда не разобьем сапорт на первую и вторую линию, не сможем измерять KPI каждого сотрудника поддержки (которых у нас нет). Но мы же маленькая команда, и добились главного — у нас каждый сотрудник может в один клик выразить свое мнение про продукт, и его точно услышат.
Есть много сервисов для общения с пользователями, начиная от монстров вроде zendesk или jira service desk, и заканчивая моим любимым хипстерским Groove.
Однако для себя мы выбрали еще более простое решение — Чатру. Самое главное преимущество Чатры — в нее действительно легко написать. В отличие от традиционного сервисдескного софта, Чатру делали не для того, чтобы облегчить жизнь саппортерам, а чтобы общаться с пользователями на сайте — этот как всем надоевший «живой консультант» на плохих интернет-магазинах, только аккуратный и ненавязчивый.
Нам важно, чтобы любой сотрудник в компании легко мог написать о любой мысли или проблеме — это критично, когда у твоего продукта не 500 000 пользователей, а всего 100, но зато супер-важных.
С Чатрой мы избежали появления еще одного источника правды — обычный софт для хелпдеска обязательно содержит встроенный трекер, где все обращения пользователей превращаются в новые задачи. Такие задачи надо как-то закрывать, измерять, отслеживать появление нового.
От Чатры никто не ждет порядка — это же бесконечный чат. Если в чате появляется что-то, что нужно сделать или обдумать, то мы просто пишем письмо ответственному. Если баг — исправляем дежурным программистом.
Конечно, с такой системой мы никогда не разобьем сапорт на первую и вторую линию, не сможем измерять KPI каждого сотрудника поддержки (которых у нас нет). Но мы же маленькая команда, и добились главного — у нас каждый сотрудник может в один клик выразить свое мнение про продукт, и его точно услышат.
Все коммиты привязывать к задаче
Во многих командах есть требование — каждый коммит в репозитории должен быть привязан к задаче в трекере. Однако есть ребята, которые не понимают, зачем это нужно, и считают это пустым формализмом. Попробую рассказать.
Во-первых, задача в трекере — это как тест до кода: прочитав\поставив задачу, ты уже определил конечный результат. Ты понимаешь, что и для чего ты делаешь, а не работаешь в режиме свободного художника.
Во-вторых, когда код не привязан к задаче, его сложнее смотреть — в глазах ревьюера он превращается из решения задачи в бессмысленные строчки на экране. В коде, который смотрели без привязки к задаче, никогда не найдут серьезных смысловых ошибок — только стилевые и другие очевидные вещи, которые вообще-то должен искать статический анализатор.
Ну и в-третьих, это блейм — тебе же самому через полгода захочется понять, зачем ты написал ту или иную строку. Ссылка на задачу в этом случае прибавит контекста. А что-нибудь вроде «changed layout» только добавит желания выкинуть весь старый код и написать новый.
Во многих командах есть требование — каждый коммит в репозитории должен быть привязан к задаче в трекере. Однако есть ребята, которые не понимают, зачем это нужно, и считают это пустым формализмом. Попробую рассказать.
Во-первых, задача в трекере — это как тест до кода: прочитав\поставив задачу, ты уже определил конечный результат. Ты понимаешь, что и для чего ты делаешь, а не работаешь в режиме свободного художника.
Во-вторых, когда код не привязан к задаче, его сложнее смотреть — в глазах ревьюера он превращается из решения задачи в бессмысленные строчки на экране. В коде, который смотрели без привязки к задаче, никогда не найдут серьезных смысловых ошибок — только стилевые и другие очевидные вещи, которые вообще-то должен искать статический анализатор.
Ну и в-третьих, это блейм — тебе же самому через полгода захочется понять, зачем ты написал ту или иную строку. Ссылка на задачу в этом случае прибавит контекста. А что-нибудь вроде «changed layout» только добавит желания выкинуть весь старый код и написать новый.
Релизы в sentry
Если вы еще не подключили функциональность релизов в сентри — обязательно это сделайте.
С помощью релизов сентри встраивается в ваш флоу — начиная с того, что показывает версию прода, в которой появилась ошибка, и заканчивая тем, что по хитрому алгоритму вычисляет подозрительные коммиты, которые с большой вероятностью могли привести к ошибкам.
Последнее очень актуально для случаев, когда вы выкатили говно и нужно срочно понять, что случилось — прямо на странице ошибки видно, кто участвовал в релизе, прямо со ссылками на подозрительные коммиты.
Если вы еще не подключили функциональность релизов в сентри — обязательно это сделайте.
С помощью релизов сентри встраивается в ваш флоу — начиная с того, что показывает версию прода, в которой появилась ошибка, и заканчивая тем, что по хитрому алгоритму вычисляет подозрительные коммиты, которые с большой вероятностью могли привести к ошибкам.
Последнее очень актуально для случаев, когда вы выкатили говно и нужно срочно понять, что случилось — прямо на странице ошибки видно, кто участвовал в релизе, прямо со ссылками на подозрительные коммиты.
Чем камин отличается от буржуйки?
Если бы авторы требований к программному обеспечению знали, сколько их требования стоят, то в мире стало бы гораздо меньше требований.
Вот делаете вы ремонт у себя в городской квартире. Почему вы не просите прораба построить какую-нибудь дорогую глупость, вроде камина или финской сауны в ванной? Это же в принципе осуществимо. Вас останавливает стоимость — это в банальном смысле нерационально.
Когда вы выступаете в роли источника требований в софтовом проекте, модель отношений точно такая же — вы что-то заказываете, а кто-то, кто умеет, этот заказ выполняет. Даже сроки в стройке проебываются так же, как в разработке.
Одно отличие — вы скорее всего даже примерно не понимаете, сколько стоят ваши требования. Запилить и поддерживать какую-нибудь дополнительную кнопку на третьем экране может по стоимости сравниться с разработкой целой фичи.
Для того, чтобы отличить камин от буржуйки, достаточно простого житейского опыта. А чтобы отличить фичу на час от фичи на день — нужен наметанный глаз. И дело вовсе не в том, что у прораба работа простая, а у программиста — сложная. Дело в банальной привычке: программисты, если не тренируются специально, точно так же ошибаются в оценке, как и вы.
Так что учите своих программистов самих работать с требованиями прямо во время выполнения задачи, либо переходите на вероятностную модель оценки, типа как в моей любимой книге про оценку Как измерить что угодно.
Если бы авторы требований к программному обеспечению знали, сколько их требования стоят, то в мире стало бы гораздо меньше требований.
Вот делаете вы ремонт у себя в городской квартире. Почему вы не просите прораба построить какую-нибудь дорогую глупость, вроде камина или финской сауны в ванной? Это же в принципе осуществимо. Вас останавливает стоимость — это в банальном смысле нерационально.
Когда вы выступаете в роли источника требований в софтовом проекте, модель отношений точно такая же — вы что-то заказываете, а кто-то, кто умеет, этот заказ выполняет. Даже сроки в стройке проебываются так же, как в разработке.
Одно отличие — вы скорее всего даже примерно не понимаете, сколько стоят ваши требования. Запилить и поддерживать какую-нибудь дополнительную кнопку на третьем экране может по стоимости сравниться с разработкой целой фичи.
Для того, чтобы отличить камин от буржуйки, достаточно простого житейского опыта. А чтобы отличить фичу на час от фичи на день — нужен наметанный глаз. И дело вовсе не в том, что у прораба работа простая, а у программиста — сложная. Дело в банальной привычке: программисты, если не тренируются специально, точно так же ошибаются в оценке, как и вы.
Так что учите своих программистов самих работать с требованиями прямо во время выполнения задачи, либо переходите на вероятностную модель оценки, типа как в моей любимой книге про оценку Как измерить что угодно.
Не бросайся решать задачи «в лоб»
Наверное, самая частая причина нарастания говнокода на проектах, после некомпетентности исполнителей — это привычка решать задачи «в лоб». Почему-то большинство ребят, которые получают сложные творческие задачи, первым делом не откладывают их в уголок мозга для обдумывания, а сразу бегут писать код.
Чтобы не плодить плохих решений, любая задача, которая подразумевает исследование, или просто кажется вам «необычной» должна обязательно проходить через три этапа.
Первый и самый долгий — ничегонеделание. Дайте задаче отлежаться, как минимум переночуйте с ней. Хорошие идеи приходят не во время лихорадочного стучания по клавишам, а в душе, на пробежке, по дороге в офис или из офиса. В общем-то в любом месте, отличном от того, где вы эту задачу потом будете делать.
Второй этап — эксперимент. Выделите части из придуманного решения, в которых вы сомневаетесь и придумайте эксперимент, который их проверит. Иногда можно обойтись и мысленным экспериментом, но лучше — написать код. Скажем, если вы делаете интеграцию с банком — просто научитесь отправлять хотя бы простые платежи с фейковыми данными.
Когда будете делать прототип — не допускайте даже и мысли потом его использовать в работающем проекте. Прототип — только на свалку.
И уже третья часть — реализация. Здесь вы должны соответствовать принятым на проекте правилам, думать о деталях решения, показывать код коллегам и т.д.
Как в стройке — архитектор не работает одновременно с прорабом, даже если они оба — это один человек, который строит сам себе загородный дом.
Наверное, самая частая причина нарастания говнокода на проектах, после некомпетентности исполнителей — это привычка решать задачи «в лоб». Почему-то большинство ребят, которые получают сложные творческие задачи, первым делом не откладывают их в уголок мозга для обдумывания, а сразу бегут писать код.
Чтобы не плодить плохих решений, любая задача, которая подразумевает исследование, или просто кажется вам «необычной» должна обязательно проходить через три этапа.
Первый и самый долгий — ничегонеделание. Дайте задаче отлежаться, как минимум переночуйте с ней. Хорошие идеи приходят не во время лихорадочного стучания по клавишам, а в душе, на пробежке, по дороге в офис или из офиса. В общем-то в любом месте, отличном от того, где вы эту задачу потом будете делать.
Второй этап — эксперимент. Выделите части из придуманного решения, в которых вы сомневаетесь и придумайте эксперимент, который их проверит. Иногда можно обойтись и мысленным экспериментом, но лучше — написать код. Скажем, если вы делаете интеграцию с банком — просто научитесь отправлять хотя бы простые платежи с фейковыми данными.
Когда будете делать прототип — не допускайте даже и мысли потом его использовать в работающем проекте. Прототип — только на свалку.
И уже третья часть — реализация. Здесь вы должны соответствовать принятым на проекте правилам, думать о деталях решения, показывать код коллегам и т.д.
Как в стройке — архитектор не работает одновременно с прорабом, даже если они оба — это один человек, который строит сам себе загородный дом.
#техническое
Circle CI: деплой
Конечная ступень любого процесса CI — доставка софта до продакшена. Circle позволяет автоматизировать доставку практически любой сложности. Здесь я приведу готовые рецепты, которые мы используем в своих проектах на Django.
Выложить на голое железо — самый простой способ. Читаем статью Deploying Django, берем какой-нибудь fabric и пишем скрипт, который выкладывает файлы и рестартует демона. Вот пример fabfile.py, который мы используем на простых проектах.
Выложить в кластер — у нас это swarm. Выстраиваем чуть более сложный воркфлоу, зато получаем масштабируемость. Делаем две задачи — собрать\отправить в реестр докер-образ, и обновить сервисы в кластере. Пример конфиги для двух этих задач — вот. В конфиге используется мой собственный велосипед под названием d, в современных сетапах для уменьшения бойлерплейта вместо него лучше использовать Orbs.
Выложить в облако — на самом деле, подвид предыдущего пункта, только подойдет любой облачный хостинг вроде zeit.co. Мы используем облака несколько нестандартно — для хранения статичных файлов django, чтобы не заморачиваться с маршрутзиацией статики. Если интересно как и зачем мы делаем — напишите в личку.
Circle CI: деплой
Конечная ступень любого процесса CI — доставка софта до продакшена. Circle позволяет автоматизировать доставку практически любой сложности. Здесь я приведу готовые рецепты, которые мы используем в своих проектах на Django.
Выложить на голое железо — самый простой способ. Читаем статью Deploying Django, берем какой-нибудь fabric и пишем скрипт, который выкладывает файлы и рестартует демона. Вот пример fabfile.py, который мы используем на простых проектах.
Выложить в кластер — у нас это swarm. Выстраиваем чуть более сложный воркфлоу, зато получаем масштабируемость. Делаем две задачи — собрать\отправить в реестр докер-образ, и обновить сервисы в кластере. Пример конфиги для двух этих задач — вот. В конфиге используется мой собственный велосипед под названием d, в современных сетапах для уменьшения бойлерплейта вместо него лучше использовать Orbs.
Выложить в облако — на самом деле, подвид предыдущего пункта, только подойдет любой облачный хостинг вроде zeit.co. Мы используем облака несколько нестандартно — для хранения статичных файлов django, чтобы не заморачиваться с маршрутзиацией статики. Если интересно как и зачем мы делаем — напишите в личку.
На vc.ru появился новый раздел «Разработка». Надеюсь, они смогут сказать новое слово в мире отечественных медиа для программистов и составят достойную конкуренцию надоевшим всем переводам статей с медиума.
Написал туда для эксперимента про Circle CI — https://vc.ru/dev/56022-opyt-ispolzovaniya-circle-ci.
Что думаете? Будете читать новый раздел?
Написал туда для эксперимента про Circle CI — https://vc.ru/dev/56022-opyt-ispolzovaniya-circle-ci.
Что думаете? Будете читать новый раздел?
Качество кода в аутсорсной разработке
Когда ребята сидят на аутсорсе и пишут код для чужих продуктов, они продают своё время маленькими порциями. Практически неважно, что программист напишет за час: 10 тестов или три костыля — этот час все равно будет оплачен одинаково и для бизнеса, и для программиста.
Конечно, качество кода у хорошего подрядчика не идёт ни в какое сравнение с качеством умельца с апворка. Однако сам формат отношений, в которых заказчик сегодня платит деньги тебе, а завтра — другому, заставляет подрядчиков ориентироваться на краткосрочные результаты, пусть и ценой жертв в таких непрозрачных местах, как исходный код.
Чтобы подтвердить мои слова, повспоминайте знакомые аутсорсные компании или агентства. Сколько из них пишут тесты?
Нет никакого смысла заботится о качестве кода, если это не увеличивает количество денег. Гораздо проще выкатывать быстрые решения, и получать за них деньги здесь и сейчас. А до момента, когда качество начинает играть критичную роль, заказчик может и не добежать. Или добежать, но с другим подрядчиком.
Когда ребята сидят на аутсорсе и пишут код для чужих продуктов, они продают своё время маленькими порциями. Практически неважно, что программист напишет за час: 10 тестов или три костыля — этот час все равно будет оплачен одинаково и для бизнеса, и для программиста.
Конечно, качество кода у хорошего подрядчика не идёт ни в какое сравнение с качеством умельца с апворка. Однако сам формат отношений, в которых заказчик сегодня платит деньги тебе, а завтра — другому, заставляет подрядчиков ориентироваться на краткосрочные результаты, пусть и ценой жертв в таких непрозрачных местах, как исходный код.
Чтобы подтвердить мои слова, повспоминайте знакомые аутсорсные компании или агентства. Сколько из них пишут тесты?
Нет никакого смысла заботится о качестве кода, если это не увеличивает количество денег. Гораздо проще выкатывать быстрые решения, и получать за них деньги здесь и сейчас. А до момента, когда качество начинает играть критичную роль, заказчик может и не добежать. Или добежать, но с другим подрядчиком.
Некоторые ребята восприняли мой прошлый пост про аутсорсную разработку резко негативно и привели противоположную точку зрения — типа аутсорсеры топят за результат (иначе им бы не платили деньги), а внутренние команды — за процесс.
Ребята в общем-то правы — когда нужны быстрые результаты за короткое время, в аутсорсе их часто выдают быстрее, чем ин-хаус.
Разница такая же, как между бегунами на короткие дистанции и марафонцами. Аутсорсеры хороши в коротких забегах, когда нужно быстро запустить MVP одного продукта или фичи. Когда гипотеза доказана, и MVP нужно хоть чуть-чуть развить, ребята, которые не заботятся о качестве, начинают тормозить, уставать и выдыхаться.
Свои же разработчики, наоборот, всегда работают с одной, стабильной скоростью.
Так что за быстрыми задачами можно смело ходить в аутсорс, а для больших продуктов — строить свою команду.
Ребята в общем-то правы — когда нужны быстрые результаты за короткое время, в аутсорсе их часто выдают быстрее, чем ин-хаус.
Разница такая же, как между бегунами на короткие дистанции и марафонцами. Аутсорсеры хороши в коротких забегах, когда нужно быстро запустить MVP одного продукта или фичи. Когда гипотеза доказана, и MVP нужно хоть чуть-чуть развить, ребята, которые не заботятся о качестве, начинают тормозить, уставать и выдыхаться.
Свои же разработчики, наоборот, всегда работают с одной, стабильной скоростью.
Так что за быстрыми задачами можно смело ходить в аутсорс, а для больших продуктов — строить свою команду.
Проблемы со сроками
Когда один человек получает от другого задачу, подразумевается, что он сам решит все возникающие по ходу проблемы.
Юристы не принимают договор, который тебе проучили? Согласовывай — твоя проблема. Код внезапно потребовал рефакторинга? Твоя проблема.
Клево, когда все проблемы решаются «внутри» задачи, не отвлекая постановщика.
Кроме одной — сроков. Проблемы со сроками, даже возможные, нужно всегда, и как можно раньше доносить до постановщика. Вдруг у него под твою задачу запланирована рекламная кампания? Или бизнес вот прямо сейчас нанимает людей, которые будут пользоваться вашей фичей?
Если проблему со сроками поднять честно и вовремя, то скорее всего ничего страшного не случится.
Когда один человек получает от другого задачу, подразумевается, что он сам решит все возникающие по ходу проблемы.
Юристы не принимают договор, который тебе проучили? Согласовывай — твоя проблема. Код внезапно потребовал рефакторинга? Твоя проблема.
Клево, когда все проблемы решаются «внутри» задачи, не отвлекая постановщика.
Кроме одной — сроков. Проблемы со сроками, даже возможные, нужно всегда, и как можно раньше доносить до постановщика. Вдруг у него под твою задачу запланирована рекламная кампания? Или бизнес вот прямо сейчас нанимает людей, которые будут пользоваться вашей фичей?
Если проблему со сроками поднять честно и вовремя, то скорее всего ничего страшного не случится.
Вопрос: что ты как CTO думаешь про монорепозитории?
Думаю то же самое, что и про serverless, vue.js или SCRUM.
Если у команды есть задачи, которые монорепозиторий решает лучше — значит это хорошо. К примеру у вас в компании живет злостная служба служба безопасности, которая проверяет каждый коммит каждого программиста. Конечно для всех будет быстрее, если комиты складывать в одно место — не нужно будет ходить к безопасникам за «регистрацией репозитория». Или к вам из начала двухтысячных приполз какой-нибудь самописный скрипт деплоя на перле, и он умеет только в один репозиторий.
А если у вас монорепозиторий потому что так в фейсбуке, или у вас сломалась кнопочка «add repo» в гитхабе — это конечно плохо.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Думаю то же самое, что и про serverless, vue.js или SCRUM.
Если у команды есть задачи, которые монорепозиторий решает лучше — значит это хорошо. К примеру у вас в компании живет злостная служба служба безопасности, которая проверяет каждый коммит каждого программиста. Конечно для всех будет быстрее, если комиты складывать в одно место — не нужно будет ходить к безопасникам за «регистрацией репозитория». Или к вам из начала двухтысячных приполз какой-нибудь самописный скрипт деплоя на перле, и он умеет только в один репозиторий.
А если у вас монорепозиторий потому что так в фейсбуке, или у вас сломалась кнопочка «add repo» в гитхабе — это конечно плохо.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Не работаю с мудаками
В отношениях с людьми я руководствуюсь простым правилом — не работать с мудаками.
Недавно я отменил заказ сантехника, который за три минуты до назначенного времени прислал СМС, что опаздывает на час, а потом опоздал ещё на два.
Без сомнений я расстаюсь с сотрудниками, которые молча нарушают обещания, ведут себя невежливо, неконструктивно спорят или проявляют любую иную токсичную форму поведения.
Расставаясь с такими людьми, я делаю лучше и им, и себе.
Мне от этого лучше потому, что если программист не в состоянии сдержать слово, он скорее всего и код плохой напишет. Мудакам тоже лучше — им легче работать с теми, кто терпимо относится к их поведению.
Даже тем руководителям, с которыми мудаки будут работать вместо меня, я делаю лучше — к ним придут люди привычного и понятного формата.
В отношениях с людьми я руководствуюсь простым правилом — не работать с мудаками.
Недавно я отменил заказ сантехника, который за три минуты до назначенного времени прислал СМС, что опаздывает на час, а потом опоздал ещё на два.
Без сомнений я расстаюсь с сотрудниками, которые молча нарушают обещания, ведут себя невежливо, неконструктивно спорят или проявляют любую иную токсичную форму поведения.
Расставаясь с такими людьми, я делаю лучше и им, и себе.
Мне от этого лучше потому, что если программист не в состоянии сдержать слово, он скорее всего и код плохой напишет. Мудакам тоже лучше — им легче работать с теми, кто терпимо относится к их поведению.
Даже тем руководителям, с которыми мудаки будут работать вместо меня, я делаю лучше — к ним придут люди привычного и понятного формата.
API гитхаба
За последний месяц я оценил, насколько удобно у гитхаба построена система интеграций. Такое ощущение, что API продумывали дизайнеры, а не программисты.
К примеру, сейчас мы вводим внутри стандарты оформления пулл-реквестов. Ничего особенного — просто называем их по-русски и требуем указывать ссылку на задачу.
Написать соответствующую проверялку при помощи probot заняло у меня около 4 часов, два из которых я потратил на чтение документации. У того же probot, кстати, есть целый каталог приложений, к примеру удобная удалялка смердженных веток.
Или еще пример — недавно мы осознали, что команда выросла настолько, что пора бы уже начать более оперативно рассказывать всем об изменениях в проекте — не в конце спринта, как раньше, а прямо как только закрыли задачу. Всего за два часа на питоне написали простой скрипт, который ходит в API гитхаба и рассылает всем письмо со списком закрытых вчера задач.
Так что если вы задумываетесь, что вам не хватает функциональности гитхаба — почитайте повнимательнее документацию. Возможно лучше потратить пару дней на написание кода, чем убивать производительность и мотивацию переходом на какую-нибудь толстую Jira.
За последний месяц я оценил, насколько удобно у гитхаба построена система интеграций. Такое ощущение, что API продумывали дизайнеры, а не программисты.
К примеру, сейчас мы вводим внутри стандарты оформления пулл-реквестов. Ничего особенного — просто называем их по-русски и требуем указывать ссылку на задачу.
Написать соответствующую проверялку при помощи probot заняло у меня около 4 часов, два из которых я потратил на чтение документации. У того же probot, кстати, есть целый каталог приложений, к примеру удобная удалялка смердженных веток.
Или еще пример — недавно мы осознали, что команда выросла настолько, что пора бы уже начать более оперативно рассказывать всем об изменениях в проекте — не в конце спринта, как раньше, а прямо как только закрыли задачу. Всего за два часа на питоне написали простой скрипт, который ходит в API гитхаба и рассылает всем письмо со списком закрытых вчера задач.
Так что если вы задумываетесь, что вам не хватает функциональности гитхаба — почитайте повнимательнее документацию. Возможно лучше потратить пару дней на написание кода, чем убивать производительность и мотивацию переходом на какую-нибудь толстую Jira.
Вопрос: работаю удаленно, помидорками по 25 минут. Если сложить помидорки за день, то получается всего 5 часов. Это нормально? Надо ли больше?
Если в вашей команде (как у нас в mtrl.ai) не трекают рабочее время, и вы за эти 5 часов успеваете выполнить все задачи — то да, это нормально.
Другой вопрос в том, куда вы деваете оставшееся время? Если оно уходит на то, чтобы превышать ожидания команды, на саморазвитие или свои проекты — вам повезло.
А вот если большинство оставшегося времени уходит на потребление — это проблема.
#вопрос
Если в вашей команде (как у нас в mtrl.ai) не трекают рабочее время, и вы за эти 5 часов успеваете выполнить все задачи — то да, это нормально.
Другой вопрос в том, куда вы деваете оставшееся время? Если оно уходит на то, чтобы превышать ожидания команды, на саморазвитие или свои проекты — вам повезло.
А вот если большинство оставшегося времени уходит на потребление — это проблема.
#вопрос