Новости опенсорсных проектов

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

— Стартер для джанго: обновились до следующей LTS джанги, добавили django-storages, чтобы удобно хранить файлы в s3, перевели API на camelCase, и перенесли кучу кода из коммерческих проектов.
— Бекенд для школы: добавили p2p-проверку домашек, сделали сервис выдачи дипломов (раньше скидывали всю пачку на яндекс-диск, теперь каждый ученик получает уникальную ссылку, которой можно делиться), перевели бекенд на heroku, а фронтенд на netlify.
— postgres-backup-s3: Форкнул заброшенный сервис для бекапа постгреса в s3, реорганизовал проект, добавив поддержку DigitalOcean spaces и healthchecks.io.

Если хотите работать со мной — напишите пару строк о себе на fedor@borshev.com: мы с Саматом с радостью набираем самостоятельных питонистов и фронтендеров (vue.js) в полностью распределённую команду без слака и другой хуйни.

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

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

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

Если вы до этого ещё не доросли, то используйте докер по-минимуму — чтобы быстро разворачивать куски инфраструктуры на машине разработчика. Для небольших команд, которые не любят сложностей, есть всего две причины добавлять докер в прод.
— У вас появился ручной тестировщик. Тестировщикам нужно окружение для каждой новой задачи. Если задача падает тестировщику — рядом с ней должна лежать ссылка на песочницу, в которой ее можно потыкать.
— У вас нет PaaS и вы раскладываете код больше, чем на одну машину. Большинство провайдеров позволяют строить на своей базе достаточно мощные виртуалки, и по началу действует модель масштабирования, при которой вы просто разносите сервисы по разным хостам. Когда единственного сервера с приложениями становится мало, вот тогда пора добавлять докер.

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

Последствия действия и последствия бездействия

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

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

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

В комментах больше нельзя постить ссылки

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

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

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

Исходники бота-модератора — тут.

Простое правило про технический долг

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

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

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

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

См. так же — технический долг как финансовый.

Похвастаюсь: мы с Федей наняли аккаунта! Наш первый не-программист, Дари Лебедкина отвечает за:

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

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

А вот в проектах, где общения больше, чем технарства, ведущая роль у меня и мне приходилось себя насиловать: вести четкие записи, списки, контролировать себя и других. Теперь мои слабые стороны в этих вопросах закрывает Дари. Прямо чувствую, как за спиной выросла ещё одна стена, которая надежно прикрывает тыл. Ура!