Запись моего (невыспавшегося) выступления с Barcamp Erevan:

​Недавно меня позвал в гости Иван Самолов. Поговорили буквально обо всём, что меня волнует — о бизнесе с Саматом, о том, как (не) нанимать программистов, как системно вести подход к личному бренду и о том, откуда в телеграме в последний год взялось столько мусорных ИТ-каналов.

Отдельная важная часть — о Школе Сильных Программистов: в этом интервью я впервые публично сформулировал наши цели и подходы.

Если вы только собираетесь войти в ИТ, и выбираете куда пойти учиться и какой курс купить, вот вам краткая инструкция:

1. Покупаете хорошую книгу по выбранному языку программирования. «Хорошая» означает, что её кто-нибудь кому-нибудь советовал в группах/форумах больше 5 раз. К примеру по питону это Марк Лутц — «Изучаем питон».
2. Изучаете её всю, от корки до корки, делая все домашние задания.
3. Выбираете самый популярный фреймворк. «Самый популярный» означает «чаще всего упоминается на тематических сайтах». В питоне под веб это Django.
4. Изучаете всю официальную документацию к фреймворку, от корки до корки. Проходите официальные обучалки. Гугите <framework> best practices, изучаете их.
5. Делаете свой пет-проект. Блог, сайт, исследование аномалий в парковке под окном, что угодно — зависит от выбранного языка.
6. Ищете команду с высокой инженерной культурой, которая возьмёт вас джуниором. Дальше учитесь у них.
7. На сэкономленные на курсе деньги езжайте на недельку или две в Питер (если живёте в Питере — в Калининград).

И не благодарите.

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

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

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

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

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

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

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

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

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

• 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.