Фёдор Борщёв

Годовая подписка — обман

Почти всегда, когда производители софта предлагают купить месячную подписку на софт, нам предлагают сэкономить 20%, оплатив сразу на год. Почти всегда это — пустая трата денег.

Во-первых, ваши 20% экономии тут же превращаются в 10%, когда вы понимаете, что деньги можно было отдать не разработчику, а на год положить в любой доступный инвестиционный инструмент (историческая доходность по ETF Тинькова, один пай которого стоит 5 ₽, — 14% годовых).

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

Если бы вы платили помесячно, вы бы потратили 600 рублей. А за год вы заплатили 1000 — получается, либо вы потеряете 400 рублей, либо останетесь на Bear. Через 4 месяца вы наверняка забудете отказаться от подписки и оплатите ещё 1000 за будущий год.

Если цифры кажутся маленькими — представьте то же самое с каким-нибудь устаревшим Adobe Photoshop за сотни денег в месяц, который, как внезапно выясняется, можно заменить на прекрасный Pixelmator Pro с единоразовым платежом.

У меня есть только одна программа, за которую я плачу годами, — это дневник Day One. Для меня это программа больше про вечность, чем про фичи: мне приятно осознавать, что мои личные переживания и важные моменты из жизни уходят в облако, в котором пролежат, возможно, и после моей смерти. Наверное, если бы за Day One можно было платить десятилетиями, я бы и на этом сэкономил 20%. А вот за всё остальное я плачу помесячно, что и вам советую.

Как переименовать приложение в Django

Как-то на бекенде для инфобизнеса меня перестало устраивать название приложения в Django. Всё просто — когда я начинал проект, я продавал только курсы, и приложение с моделями курсов называлось courses. Потом появились записи этих курсов (record) и наборы (bundles). Конечно мне захотелось переименовать приложение courses в products, чтобы уменьшить когнитивную нагрузку при чтении кода.

К сожалению, я не нашёл ни одного решения, кроме стрёмного django-rename-app, который предлагал мне выполнять management-команды в консольке на проде. Кроме того, что это ломает любые пайплайны CI\CD, там ещё и код был не очень понятный. Так что в итоге я решил сделать это сам. Оказалось сложно, поэтому я написал эту инструкцию.

Исходные условия:

  • БД — SQLite. На PostgreSQL наверное тоже будет работать, но я не проверял.
  • CI\CD пайплайн, который запускает миграции при каждом деплое.
  • Данные терять нельзя.
  • Мы не стесняемся править старые миграции.

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

  • Подменяем имя приложения в истории миграций: ./manage.py makemigrations <some-other-app> -n RenameOldApp --empty. Коммит.
  • Деплоим миграцию на прод. После этого шага ничего нельзя деплоить до конца.
  • Делаем новый пулл-реквест.
  • Переименовываем папку с приложением: git mv courses products
  • Заменяем все упоминания старого приложения в миграциях. Коммит.
  • У всех моделей в новом приложения в Meta прописываем db_table с именем старого приложения. В моём случае, если модель называется bundle и лежала в приложении courses, нужно прописать db_table = 'courses_bundle'. Коммит.
  • В старых миграциях, которые используют операцию CreateTable, добавляем новую db_table в options. Коммит.
  • Меняем упоминания приложения в коде, можно автозаменой. Мой коммит, если важно.
  • Проверяем, ./manage.py makemigrations --check. Новых автоматических миграцией был не должно, ошибок тоже.
  • Деплоим на прод.

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

«Самому не проще»: новый почтовый курс про делегирование

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

Делегирование и постановка задач — больная тема. Ещё 10 лет назад всех уже тошнило от S.M.A.R.T. и условных «семи правил успешного делегирования». Мне, к примеру, хотелось, чтобы кто-нибудь рассказал, почему я так стесняюсь ставить коллегам задачи, и как сделать, чтобы команда делала порученную работу быстрее, чем я своими руками. Но везде были советы от копирайтеров, из серии «делегируйте полномочия вместе с ответственностью».

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

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

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

3 письма, 1 q&a-сессия, старт 12 января. Стоит 6500 рублей. До конца этого года скидка 15% по промо-коду FBLOG1.

Меньше тратить → больше зарабатывать

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

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

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

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