#37: vas3k: CEO OF HTMX

[00:00] Вастрик: Я ненавижу SPA. Прям терпеть не могу. Я не понимаю — нет ни единого плюса у SPA, их просто не существует вообще. Любую вещь, которую делают на SPA, обычный браузер делает лучше. Рендеринг HTML быстрее делает обычный браузер, чем твои React-компоненты. History уже встроено в браузер — зачем ты роутер тащишь на фронтенд? Кэширование — тоже у тебя есть все эти флажочки, If-Modified-Since, HTTP-заголовки и всё прочее. Блин, это всё засилие SPA и вот этих, как их называют, сайтов-спиннер-фестов. Открываешь сайт, а там у тебя фестиваль спиннеров: всё подгружается, каждый виджет свой лоадер отображает, и вот спиннер-фест, как будто в цирк какой-то приехал. Клоун у тебя тут вертится, а ты сидишь и ждёшь, как дебил, пока тебе реально твиты покажут. Зачем твиттеру SPA? Я вообще не понимаю.

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

[01:54] Александр: В 1997-м выпуске случилось то, чего год назад я и представить не мог. Как вы уже догадались из названия, сегодняшний гость — Вастрик. Если вдруг вам это слово ни о чём не говорит, переходите по ссылке в описании и знакомьтесь с талантливым блогером и основателем Вастрик-клуба. Я давний участник этого замечательного сообщества. Когда я в первый раз открыл страницу Вастрик-клуба, я сказал себе: вау, как всё просто и понятно. Интересно, а как это работает? Конечно, ответ на этот вопрос я мог найти на GitHub. Но, согласитесь, куда интереснее поговорить об этом с автором проекта. Это выпуск про то, как работает Вастрик-клуб и какие технологии стоит выбирать для собственных pet-проектов. Поехали!

[02:54] Александр: Никто почему-то до этого не хотел поговорить о том, как делать self-pet-проект и всё вот это вот. Дам слушателям немного контекста: я написал Вастрику в гостевуху, предложил поговорить про технологии, про технологическую часть его проектов и клуба в частности. Потому что я член Вастрик-клуба, и мне нравился минимализм, UX и в целом организация всего — как там всё устроено. Мне всегда было интересно, как это сделано, какие технологии за этим стоят, какой код. Видно, что всё сделано с душой, просто и без выебонов, что называется, — и это меня сильно подкупало. Я всегда думал: было бы классно с Вастриком про это поговорить или просто посмотреть на код. Слава богу, он есть в open source, но поговорить, конечно, поинтереснее, чем смотреть. К тому же я на Python не программирую. Ну, я посмотрел, когда готовился, как там всё устроено, — про это мы ещё поговорим. И что самое интересное — ты тоже это подметил, — в поисках, как оно всё работает, я, естественно, прослушивал подкасты с тобой, их есть несколько. И ни в одном даже близко не говорят про технологическую часть, разве что где-то тема чуть-чуть затрагивалась. И я предлагаю в подкасте «Тысяча фичей» закрыть эту дыру в публичном пространстве и конкретно так поболтать про технологии.

[04:33] Александр: Расскажи, пожалуйста, как выглядела самая первая версия Вастрик-блога. Ты ведь сначала блог писал, а потом уже оттуда вырос Вастрик-клуб. Давай сначала немного про блог, а потом про клуб. Первая версия блога — что это было?

[04:50] Вастрик: Технически самая первая версия блога — это был ЖЖ, когда он ещё был жив. Потом я решил делать stand-alone, почему-то так захотелось. Сначала это были CMS-ки, тогда популярные, а сейчас уже мёртвые. Естественно, они меня все чем-то не устраивали: WordPress был слишком жирный, а все остальные слишком тупенькие. Тогда я как раз учился в универе, учил Python и написал первую версию на Django. И с тех пор как-то так и повелось. Сейчас там уже не первая, а четвёртая или пятая версия — но всё на Django. Очень простые, чисто заточенные под себя. Одно время там даже админки не было. Да и сейчас, по-моему, нет — я все тексты тупо пишу через базу данных.

[05:39] Александр: Прикольно. Я, кстати, думал, что админка есть. То есть когда ты говоришь «версия», ты имеешь в виду, что переписывал с нуля новый код? Или какие-то major changes называешь новой версией?

[05:50] Вастрик: С нуля, да. В смысле, чаще всего это были большие изменения в структуре базы данных. Сначала у меня были только посты одного формата. Потом была одна очень смешная версия блога, где вместо главной страницы был таймлайн. В 2010–2012 годах была мода на таймлайны: из разных сервисов — из Facebook, из Instagram, чекины из… где все чекинились? Забыл. Мне 26 лет.

[06:22] Александр: Foursquare.

[06:23] Вастрик: Да, точно, Foursquare. И всё это попадало на одну страничку — такой таймлайн твоей жизни. Тогда ещё в Instagram выкладывали чисто фоточки: что поел, куда съездил. Складывалось в очень прикольный вид, но для этого, естественно, нужна была совсем другая структура. Я только уже потом, спустя лет десять, узнал, что это вообще один из главных подходов к такой редкой вещи, как инди-веб. Там есть два вида постинга: либо ты постишь в любые социалки и агрегируешь всё к себе на сайт, либо наоборот — постишь у себя на сайте, и всё распространяется автоматом по твоим социалкам. И тот и другой имеют место быть, у них даже название для этого есть. А я тогда просто думал, что сам это придумал.

[07:12] Александр: Прикольно. То есть это инди-веб? Условно, я, например, у себя на личном веб-сайте составляю такой таймлайн, или фид, — вся моя активность в интернете. Все мои твиты, публикации в телеграм-канале, истории в Instagram — они туда сливаются, и человек пришёл, посмотрел. И это называется инди-веб. Прикольно. Я такие штуки видел, но сейчас, по-моему, оно не то чтобы сильно распространено — по крайней мере среди тех, за кем я слежу. Но на то время это действительно было что-то такое.

[07:50] Вастрик: Ну, вообще да, я видел вначале какие-то такие фиды: о, вот тут он что-то делает, и здесь. Но, мне кажется, сейчас практической ценности в этом немного — разве что прикольно просто иметь такую штуку.

[08:05] Александр: Да и тогда не было особо?

[08:07] Вастрик: Да и тогда не было. Это просто было хобби — коллекционирование собственной жизни. Я бы сейчас с удовольствием такой таймлайн себе написал, но с закрытием API… Twitter закрыл API, Instagram закрыл тоже, все хотят за это денег. Всё стало какой-то погоней корпоратов за платформами. Неинтересно, короче. Раньше все API были открыты, очень просты, можно было легко парсить, у многих даже авторизации не было. Вот это было время.

[08:36] Александр: Все крупные платформы со временем превращаются в огороженные сады — те самые знаменитые walled gardens. И дальше происходит процесс эншитификации, который стал даже словом года, по-моему, в 2023-м. А можешь проговорить для тех, кто не знает, что это такое?

[08:59] Вастрик: Погуглите — на русском ещё нет термина, но можно взять «оговнякивание». Эншитификация — это когда платформа только появляется: она маленькая и классная, все туда идут. Instagram, Twitter, все эти — когда они только-только появились, были классными, всем хотелось там сидеть. Потом со временем они вырастают, становятся сильно крупными и прекращают развиваться. Их целью становится не развитие, а дойка юзеров на деньги. Из-за этого везде появляются эти алгоритмические ленты, которые вперемешку подсовывают тебе рекламу, думают за тебя, что ты хочешь смотреть, скрывают твоих друзей и подсовывают какие-то бренды. И это как раз тот самый процесс, когда платформа сговнякивается в попытке выдавить последние деньги из пользователей — и тихо-мирно умереть, как какой-нибудь Foursquare. Это сейчас у всех активно. Facebook проходит эту фазу — там уже почти не осталось контента. Twitter немного пошатал Маск, посмотрим. Но очень многие платформы также умерли. Кто вспомнит, кто где сидел ещё десять лет назад? Сейчас уже половины этого нет.

[10:17] Александр: Да, я, кстати, не задумывался про энщитификацию под таким срезом, но на уровне ощущений ты замечаешь: понятно, что здесь уже ловить нечего. Остались последние люди, которые просто не хотят уходить или у них есть какой-то социальный контекст в некоторой соцсети. Скажем, во «ВКонтакте» у меня есть страница, потому что там есть ряд людей, с которыми только там я могу разговаривать. Хотя Telegram и этих людей переманивает. То же самое и с WhatsApp: он у меня просто потому, что с некоторыми людьми по-другому невозможно общаться. Это, конечно, не соцсеть. А про Instagram я заметил это давно, и ты сейчас навёл меня на мысль: стандартной лентой Instagram же невозможно пользоваться. Не знаю, кто в обычной ленте сейчас сидит: сплошная реклама, сплошная какая-то фигня. Остались истории, и то я смотрю истории первых четырёх людей, остальных просто свайпаю и закрываю. Многие, наверное, вообще Instagram не пользуются, но я по инерции ещё захожу раз в день. А с Twitter у меня интересная история: бывают волны, когда я сижу там по два часа в день, а бывает, наоборот, не захожу по два месяца. У нас с ним какие-то абьюзивные отношения: либо очень много вместе времени проводим, либо вообще не общаемся. Вот сейчас как раз стадия, когда я туда не захожу.

[11:46] Вастрик: Прикольная тема, да. Интересная.

[11:54] Александр: Но давай немного вернёмся к блогу, к технической части. Ты говоришь, первая версия Вастрик-блога — замечательного, который сейчас есть, но уже пятого, как я понимаю, — работала следующим образом. Это просто приложение на Django, какой-то фреймворк, который возвращает HTML. То есть это multi-page application. Фронтенда и JavaScript там, я так думаю, по минимуму. А CMS, Content Management System, — это в целом штука, которая решает такую проблему: у тебя есть блог, и ты хочешь туда посты писать. Как тебе написать пост, как не программисту, обычному человеку? Нет там в блоге кнопочки «написать» — сейчас во многих есть, но в целом контент туда заливается с другого конца. И вот у тебя контент на блог попадает из базы данных. Ты туда напрямую условно INSERT делаешь или как?

[12:50] Вастрик: Сейчас уже там есть стандартная джанговская админка. Но было время, когда я реально её открывал… Ну, я всегда пользуюсь клиентами для баз данных — они красивые, классные, всё умеют, всё, что я хотел. Я потому и не пишу никакие админки: если можно, я хожу на свои проекты напрямую, через SSH на базу данных. Для Mac у меня клиент для Postgres, называется Postico — абсолютно классный. Есть ещё TablePlus и другие. Короче, они все решают дело. Но сейчас я уже иду через джанго-админку. Django изначально создавалась для CMS-ок и новостных сайтов, так что для блога это идеальное решение: всё из коробки подключаю и использую. Но тексты я никогда не пишу в браузере. Я опять же из тех олдскульщиков, которые знают: если что-то может проебать браузер, то он обязательно это сделает. Поэтому тексты я всегда пишу в Sublime, и только когда они готовы, открываю админку, вставляю туда текст с картинками — и всё. Текст на Markdown, если что. Чисто стандарт интернета сейчас, мне кажется, он ещё долго не уйдёт.

[14:12] Александр: Да, Markdown замечательный. Я буквально сегодня свичнул свой флоу последнего взаимодействия с браузером. Ты сказал, что ты из тех олдскульщиков, которые всё делают где-то в другом месте или в терминале. Я уж думал, ты скажешь, что программируешь в терминале. Так вот, сейчас среди молодых движовых программистов есть тренд как раз на то, чтобы использовать… Большинство сейчас, короче, дрочат на Neovim — такой новый Vim, точнее форкнутый и переписанный. Там куча плагинов на Lua, и ты можешь в терминале сделать себе IDE как тебе угодно. Причём это всё прикольно кастомизируемо, красиво и быстро. Я как раз из тех красноглазиков, которые вот этим непонятным занимаются. И последнее, что я свичнул из браузера, — это Google Docs. Я довольно много пишу в Google Docs, чтобы обсудить архитектуру и так далее, и вот писал в браузере. И думаю: ну, Google Docs — это же Cloud Sync, комментарии, вот это всё, ценность, которую несёт этот софт, как я могу не в браузере? А потом, так как у меня Vim-байндинги, я постоянно нажимаю Escape, чтобы переключаться между режимами Insert и Visual. И я начал тыкать Escape в браузере, а он у меня из fullscreen сворачивался в маленькое окно. Меня настолько это достало, что я сказал: блин, нафиг, пойду писать Google Docs в Vim. В итоге пишу в Markdown локально документ, ничего меня не отвлекает, а потом просто копирую и вставляю в Google Doc — он Markdown понимает.

[15:50] Вастрик: А, ты так делал. Я думал, ты прям открыл себе какой-то плагин, который автоматом через API пишет в Google Docs.

[15:58] Александр: Это было бы круто.

[15:59] Вастрик: Так браузер всё равно открывать приходится.

[16:01] Александр: Да, это правда. Но тут видишь в чём ценность? В том, что я погружаюсь в поток в своих стандартных байндингах. В стандартном для себя флоу работаю, выдаю текст, а потом уже комментарии, обсуждения, правки — это в браузере можно. Но вот это творческое флоу, состояние потока, в браузере почему-то не достигается. Ну как в браузере его достичь? А когда у тебя всё в терминале, ты условно четыре часа в день пишешь код в таком стиле, а потом начинаешь текст писать в таком же — это какое-то чувство, которое надо понять, его сложно описать.

[16:39] Александр: Но прикольно: то есть ты в первых версиях прям Markdown вставлял в базу данных через какой-то клиент. А как ты это дебажил? Мог же что-то не то вставить. Какие-то драфты у тебя были или сразу всё?

[16:55] Вастрик: Драфты, естественно, есть. Задаёшь пост — и пока ты не нажал кнопку, что он visible, он виден только тебе, если знаешь URL. У меня сейчас, кстати, многие олды научились за неделю до Нового года находить новый драфт моих итогов года и читать его, пока я его ещё пишу, потому что у меня даже никакой авторизации нет. Это просто скрытый пост. Драфт — это такая же абсолютно страница блога, как и другая, просто на неё нет ссылки с главной страницы. Но если знаешь, где искать, можешь просто увидеть.

[17:36] Александр: Ну, понятное дело, что на блоге никакой авторизации нет, если ты не хочешь оставлять комментарии. А как ты по-другому скроешь драфт?

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

[18:20] Александр: А какие у тебя были проблемы в процессе развития блога, помимо спама и странных людей, которые могли что-то писать? В техническом плане — например, из-за спама падала страничка, засиралась база данных, что-то такое было? Или просто оно работало, и всё?

[18:42] Вастрик: Просто оно работает. Для обычного блога вообще много ресурсов не надо. Оно до сих пор хостится на каком-то самом минимальном сервере на Hetzner, я никогда не увеличивал его размер — даже когда в золотые 2016–2017 годы, когда все тусили на TJournal или были всякие YouTube-шоу, пара статей залетала во внешний интернет. Про Дружко-шоу, кстати, тоже такое было.

[19:14] Александр: Подожди, а что у тебя на Дружко залетало?

[19:16] Вастрик: Там был разбор взаимосвязей на российском YouTube. И Дружко даже вставил мою картинку у себя и что-то иронично прокомментировал. Я так радовался, у меня даже скриншот лежит. Она была у него типа одной из новостей. То есть за сутки тебе сотни тысяч просмотров льются — а мы даже не падали. Cloudflare хорошо спасает, потому что чаще всего сервер забивается именно по I/O: условно, у него кончаются какие-нибудь сокеты. А так как Cloudflare всё кэширует, а у меня там что — картинки и текст, — то 90% трафика раздаётся из кэшей Cloudflare. А те 10%, которые доходят до сервера, — ну окей, серверу не жалко их обработать. Так что живём всё ещё на самом маленьком. Ну, это бложик. Сейчас вообще многие делают просто static page на GitHub — и тоже норм работает.

[20:24] Александр: Да, я вот один из таких. И, кстати, сейчас подумываю переписать этот static page на GitHub, потому что хочется.

[20:30] Вастрик: Я, наоборот, подумывал уходить обратно с этих всех самописных джанго-монстров на какой-нибудь нормальный static page. Но потом думаю: не, тогда я не смогу делать весёлые штуки.

[20:43] Александр: Да-да-да.

[20:44] Вастрик: А мне как раз хочется весёлые штуки поделать, только руки пока не доходят.

[20:49] Александр: Давай про Cloudflare немного подробнее расскажем для тех, кто, может быть, не знает, что это. Это когда мы ставим перед своим сервером некоторый прокси — или как это правильно называется?

[21:03] Вастрик: Да, получается, Cloudflare обрабатывает все твои DNS и знает, кто к чему обращается. Он умеет кэшировать статику, даже какую-то динамику, у него много настроек. По сути, это прокси на твой сайт — даже айпишник меняет. Все запросы, которые идут тебе на сервер, идут через их edge-серверы, и там они на какое-то время кэшируются, файлики лежат. То есть это ускоряет твой сайт, потому что люди, например, из Америки грузят его с американского CDN, а не с немецкого, где лежит сайт. Но, по-моему, они работают, только если ты делаешь DNS-запрос — то есть вводишь имя сайта. А если я знаю айпишник твоей тачки, никто мне не помешает сходить на него напрямую.

[21:55] Александр: Да-да-да, конечно.

[21:56] Вастрик: Ну, то есть у них есть защита от DDoS — это тоже одна из вещей, с которых они начинали. Там уже есть методы сильно прятать айпишники тачек.

[22:10] Александр: Я тоже пользовался Cloudflare для своего pet-проекта, и мне очень понравился набор фичей, которые они предоставляют. Тебе — ну, ты один человек, у меня нет инфраструктуры, нет крутых сетевых инженеров, которые могут эти проблемы решить, — а они решают. Это кэширование, защита от DDoS, история с сертификатами: они могут помочь с SSL, чтобы у тебя был HTTPS.

[22:38] Вастрик: Да, кстати, да. Без запары: даже не надо самому настраивать Let’s Encrypt на серверах — оно просто работает.

[22:45] Александр: Да. И вот куча всего вот этого: статистику можешь смотреть, некоторую мини-аналитику у них делать. Это всё довольно прикольно.

[22:54] Вастрик: Да, он заменил мне Google Analytics прям полностью, и я от неё отказался. Ну, есть, как бы, ложка дёгтя в эту бочку мёда Cloudflare. Ты знаешь последнюю историю про сокращение и увольнение сотрудников?

[23:12] Александр: Да сейчас все увольняют, сокращают — разве это новость? А что там было?

[23:16] Вастрик: Не-не, там просто есть видосик в TikTok…

[23:20] Александр: А, где девочка плачет.

[23:22] Вастрик: Да-да, где она плачет. Не знаю, насколько верить этому всему — это дело каждого, но если действительно так, то история не очень приятная. Кому интересно — погуглите, найдёте. Но как к продукту, как к решению у меня вообще никаких вопросов нет.

[23:39] Александр: Нет, тут скорее ты должен был вспомнить, что у Cloudflare некоторые ноды иногда попадают под блокировки Роскомнадзора. Это проблема: твой сайт может внезапно перестать открываться в случайный момент у жителей РФ. Эти проблемы посерьёзнее, чем плачущая девочка.

[23:56] Вастрик: Да, наверное, согласен.

[23:57] Александр: Ну, видишь, я-то на эти штуки обращаю внимание.

[24:06] Вастрик: Корпораты все бездушные.

[24:07] Александр: Это правда.

[24:08] Вастрик: Не надо испытывать каких-то чувств к корпорациям, это чисто деловые отношения. А по поводу того, что некоторые серверы Cloudflare могут быть недоступны из некоторых регионов, — это хороший тейк, об этом стоит думать.

[24:24] Александр: То есть ты где-то запостил, например, в Яндекс.Клауде, подключил Cloudflare — и твой захостенный на Яндекс.Клауде блогик из РФ не работает, что может удивить.

[24:37] Вастрик: Но, мне кажется, сейчас это уже вообще никого не удивит.

[24:40] Александр: Ну да.

[24:40] Вастрик: Там много чего не работает.

[24:47] Александр: Есть ли ещё какие-то сервисы, которыми ты пользуешься в блоге, в клубе, которые тоже доставляют тебе некоторую ценность, как Cloudflare?

[24:58] Вастрик: Ну, все ошибки у нас идут в Sentry — это, мне кажется, уже тоже классика. Мне пока хватает даже бесплатного аккаунта. Всё, что упало, где что отвалилось, сразу в Sentry показывается: я могу продебажить, посмотреть логи и пойти починить.

[25:17] Александр: А как там интеграция? Ты просто stdout своих имиджей направляешь сюда или как?

[25:23] Вастрик: Во-первых, она работает на уровне языка: для Python своя, для JavaScript своя. По сути, Sentry — это такой глобальный try-catch, который просто ловит на выходе вылетающий из твоего приложения exception. Это отдельный логер, который ловит его вместе со всем stack trace и что там ещё можно вытащить из объекта exception, забирает себе на сайт и красиво показывает: вот на этой линии упало с такой-то ошибкой, можешь посмотреть traceback. Всё удобно.

[25:58] Александр: Ты используешь его, чтобы просто посмотреть, всё ли там ок, чтобы самому не грепать логи?

[26:05] Вастрик: Ну, это не логер же, это скорее error tracker. То есть когда я что-то деплою, сделал новую фичу, и где-то какая-то ошибочка — она сразу заорёт тебе в Sentry: вот у такого-то юзера при попытке написать комментарий вылезла ошибка 500. И ты сразу такой: ага, почему? В комментарии спецсимвол какой-то был, поэтому упало. Так, ладно, давай починим. Вот для таких вещей. А логи я смотрю чисто в докер-контейнерах, когда надо. Они отдельно никуда не складываются.

[26:39] Александр: Ты вот сказал про Sentry, что типа все используют. Мне кажется, это как раз в мире Django, питоновских серверов распространено. А в Java-мире, из которого я, я прям ни разу в своей коммерческой деятельности его не использовал. И знаешь почему? Потому что в Java есть культ логеров. Логеры в Java — это вообще отдельная штука, на уровне логеров можно очень много сконфигурировать. Тебе не нужен вот этот условный глобальный try-catch — ты просто конфигурируешь логер и из него уже подсасываешь эту трубу куда хочешь. То есть там немного по-другому.

[27:14] Вастрик: Ну да. У Python абсолютно та же схема с логерами, что и в Java. Это глобальный try-catch — в кавычках, я имел в виду. Технически это отдельный логер, который настроен ловить исключения. Ты можешь даже указать, что если хочешь и warning’и слать, то тоже в Sentry. Но их нет смысла слать: зачем? Только считать что-то, сколько раз где-то упало.

[27:39] Александр: Окей, с Sentry для ошибок понятно. Тачка у тебя хостится, ты сказал где. Она одна и вообще не жирная.

[27:49] Вастрик: Ну, одна для блога, одна для клуба. На блоговой тачке ещё несколько проектов — как раз тех, которые мои и не мои. Там живут How to Berlin, InfoMate, что там ещё, всякие мелкие pet-проекты. Когда им перестаёт хватать места, они отъезжают на новую тачку. Легко. Docker — класс вообще.

[28:10] Александр: Да, давай про Docker поговорим. Когда я открыл GitHub Actions в коде Вастрик-клуба, я смотрю — deployment, какой-то файл, и он один в один как я делал во всех своих проектах. Даже с точностью до последней команды docker push. То есть я такой: да, ну потому что тачка засирается — очищать, что там было. То есть оно прям один в один, и я нигде это не вычитал. Просто это какой-то прагматичный, практический подход: если ты хочешь что-то сделать и тебе не надо параллельно изучать какую-то технологию или упражняться с YAML-ами, то, скорее всего, у тебя GitHub Actions с deployment будет выглядеть вот так, с точностью до переменных окружения. В общем, deployment в Вастрик-клубе выглядит так: после мерджа pull-реквеста, когда он попадает в ветку main, триггерится событие — action, который передеплоивает: делает сборку, docker push в registry, а потом на тачке делает pull из этого registry и заменяет один бегущий докер на другой. И всё. Причём это Docker Compose, то есть на тачке нужно ещё несколько сервисов поднять. А кстати, у тебя в docker-compose база данных поднимается, если ты docker compose up сделаешь?

[29:40] Вастрик: Да.

[29:40] Александр: И точно так же на prod у тебя база поднимается? То есть ты не используешь managed Postgres?

[29:46] Вастрик: Есть docker-compose.production.yaml — это чисто то, что происходит на production, всё открыто. Ну не open source, а open code. Главная проблема такого сетапа — то, что нужно быть очень аккуратным с persistence: чтобы Docker не убил твою базу данных и не пересоздал её заново. Поэтому volume примонтирован отдельно на диск и бэкапится ежедневно на всякий случай, если вдруг какой-то деплой его убьёт. Но в целом, так как деплой делается через GitHub Actions, руками туда практически никогда не лазают. Я лезу только один раз — когда что-то серьёзное сломалось.

[30:28] Александр: А, место на диске закончилось?

[30:31] Вастрик: Вот, только хотел сказать.

[30:32] Александр: Что случилось?

[30:33] Вастрик: Вот тогда мне пришлось лезть руками на сервер, смотреть, почему что-то засралось. Докеры же вроде все очищаются после каждого деплоя, этот system prune. Но нет — там оказалось, логи какие-то засрались.

[30:48] Александр: Классика, классика.

[30:49] Вастрик: Пришлось открыть для себя, что у Docker Compose есть свой log rotate — ротация логов, которую тоже нужно включить, она по умолчанию выключена.

[31:03] Александр: Я тут зачитаю выжимку из readme проекта Вастрик-клуба, которая как раз касается того, о чём мы говорим. Я буду на английском, потому что это оригинальный текст, не буду переводить. Первое: «No Kubernetes, no AWS, we ship Docker directly via SSH and it is beautiful». И второе — это моё любимое: «We are open for proposals on how to improve our deployments without overcomplicating it with modern DevOps tools».

[31:35] Вастрик: Ну, это, кстати, уже не «looking», это старое readme. Нам пришёл-таки чувак-девопс и написал нормальный деплой. У нас просто в первой версии имиджи даже билдились на самой тачке — не было registry. GitHub Actions делал тупо git pull на тачке, собирал прям там имидж и заменял его на лету. Но мне очень хотелось сделать registry, чтобы легче было откатывать. И вот чувак-девопс написал офигенный YAML. Единственный YAML в клубе, но вот такой.

[32:07] Александр: Бывает.

[32:07] Вастрик: И он как раз делает…

[32:08] Александр: Это GitHub Actions, да, который YAML ты имеешь в виду?

[32:11] Вастрик: Да-да. По-моему, actions он сделал, который собирает, кладёт в registry и подменяет. И даже ничего не сломалось: представляешь, когда мы переехали с одного деплоя на другой прям на проде — переключились, и всё продолжило работать. Магия.

[32:26] Александр: Круто, да. То есть это тот YAML, который я насмотрел, — уже модернизированный, с registry?

[32:36] Вастрик: Наверное. Я там что-то подправлял, но основная часть файла написана другим человеком из open-source-сообщества.

[32:47] Александр: Магия open source, ура. Респект. То есть давай я ещё раз проговорю. Первая версия была такая, что GitHub Actions тупо сшивался на сервер, делал там git pull и дальше просто docker build, docker compose down, up — всё.

[33:14] Вастрик: Да-да-да.

[33:15] Александр: Давай проговорим для тех, кто, может быть, не понимает, в чём проблема такого подхода. Получается, что у нас не существует артефакта кода. Сам код является конечным продуктом, конечным артефактом, который мы производим. А в современных реалиях, да и common sense подсказывает, что иметь сорцы как конечный продукт — не самая лучшая идея. Конечным продуктом в случае модернизированного Вастрик-клуба является докер-имидж, который лежит в registry. Это коробочка, которая готова, произведена: её можно заменить на другую, откатиться к старой, кому-то отдать. У нас в Java-мире таким чаще всего является джарник. Ну либо тоже докер-имиджи, если это микросервисы. Соответственно, что было сделано? Появилась третья сторона в виде registry — сервер для докер-имиджей, который их хранит. В GitHub Actions делается docker build и push туда, а потом раннер сшивается по SSH, и уже на виртуалке делается pull — то есть артефакт стягивается из registry.

[34:25] Вастрик: Так и есть. Главный плюс в том, что когда я задеплоил дерьмо и всё сломалось, я просто иду и делаю «откати на предыдущий», а сам пока посмотрю. Мне не нужно перебилживать, откатывать код, коммитить его заново. Я просто подменяю. Но вообще-то я так сладко об этом рассказывал, что люди, которые не шарят, думают: ничего себе, rocket science. А люди, которые шарят: да они там все ебанутые, вы чего.

[34:53] Александр: Да, и так нельзя. Сшиваться по SSH из GitHub Actions — куда, что?

[34:58] Вастрик: А ещё у них volume на той же тачке с данными.

[35:03] Александр: Да, volume на той же тачке с данными. Представляешь, вообще жесть. Никакого managed Postgres, AWS. Даже лоад-балансера нет.

[35:11] Вастрик: Ну, это прикольно.

[35:12] Александр: Но вот эта схема — она такая самая рабочая. И я хочу похвалиться, что мои проекты, которые я делал (мы с другом тоже небольшой стартап делали), сделаны именно по такой схеме. Они сразу работали, и это было написано мной — все эти экшены и придуманы схемы. Я к ней пришёл сам, хотя я не девопс. А ты говоришь, к вам даже человек, который шарит, пришёл и сделал так же. То есть я на полставки девопсом могу уже работать.

[35:40] Вастрик: Удивительно. Но это так. Минутка саморекламы.

[35:47] Александр: Давай здесь вставим тогда жирный дисклеймер. Даже когда ты потом будешь делать нарезку в начале выпуска, вот эту вставь туда. Что всё, что мы сейчас обсуждаем, не касается профессиональной разработки в крупных компаниях, на работе, за которую вам платят. Это всё исключительно работа над pet-проектами. И это две кардинально разные разработки, два абсолютно разных стиля, у них разные цели. Эти вещи делаются так, потому что так проще тебе же их потом будет поддерживать. На работе ты пишешь код для других, в pet-проектах — для себя.

[36:25] Вастрик: Да. Такой вот. А то ещё подумают, что мы тут пропагандируем вот это всё, порнографию — по SSH ходить, докеры носить. Нет. Придут к нам эти chief site reliability инженеры и накидают в защитку, что мы тут сидим и несём фигню.

[36:46] Александр: Естественно, спасибо за дисклеймер, я его обязательно вставлю в начале. Да, мы говорим про свои проекты. Ну или про начало каких-то стартапов, когда ты хочешь проверить идею: тебе нужна скорость и быстрота, ты там один — и CTO, и CEO, и девопс. Тоже такой подход, мне кажется, довольно рабочий. Не надо сразу сетапить. Я не знаю, сколько времени я потрачу, чтобы засетапить Kubernetes-кластер, написать туда какие-то Helm-скрипты и всё это менеджить. Устанавливать операционную систему поверх операционной системы я буду две недели — вместо того чтобы за эти же две недели понять, что идея никому не нужна, и пойти дальше. Вроде очевидная вещь, но не всегда народ об этом задумывается. И вот, например, когда ты приходишь в какой-то рабочий проект и там есть осколки этих начальных скриптов, ты думаешь: ну вот какие дураки это писали, надо было сразу вот это делать. А вы вернитесь на их место. У них были другие цели, другие ресурсы, другое время. Так развивается, так эволюционирует, мне кажется, абсолютно любой продукт, любое приложение. Не надо сразу делать кластера и ждать той самой чёрной пятницы, когда у тебя автоскейлинг сработает и ты такой: вот ради этого я живу.

[38:07] Вастрик: Вот ради этого я учу Kubernetes: чтобы оно заавтоскейлилось, потом задаунгрейдилось, и мы красавцы.

[38:14] Александр: Да-да-да, всё так. У нас даже в крупной компании, где я когда-то работал — 10 тысяч человек, — всё равно где-то внутри инфры был скрипт на Bash, который что-то делал. И он был как раз первым скриптом первого деплоя, когда этот проект только создавался. А сейчас там компания в 50 странах еду доставляет, но всё равно был скриптик на Bash. Я когда уходил, правда, его уже переписали, но это было иронично.

[38:39] Вастрик: Ну, это тяжело — скрипты на Bash, конечно. Я бы сейчас, наверное, писал на Python. Такой же скриптовый язык.

[38:46] Александр: Да, Python, Ruby — норм.

[38:49] Вастрик: Но понятное дело, что народ, который дружит с командной строкой, не знает, что это. Им, наверное, на Bash попроще будет.

[38:55] Александр: Смотри, последний, наверное, технический вопрос в тему бложика и клуба. А почему у тебя Postgres не managed? Как будто бы довольно рискованно самому всё на диске хранить. А вдруг диск отвалится?

[39:11] Вастрик: Согласен, согласен. Ну, если вдруг диск отвалится — на сервере снапшоты есть, за этим Hetzner, я думаю, последит. Плюс я бэкаплю базу во внешнее хранилище каждый день. На случай чего у меня вроде как всё есть. А почему не managed? Не знаю. Потому что дорого, наверное. Или лень. Нет ответа. Скорее всего, потому что не хочется идти в AWS, а у Hetzner, где я всё-всё-всё храню, до сих пор нет managed-баз данных. Хотя надо проверить, может, появились. Они только недавно сделали Load Balancer — ну, как недавно, год назад. И это уже такое: о, настоящее облако. Я их люблю, они маленькие, классные. Если у них появится managed Postgres, наверное, я туда перееду. Почему бы и нет?

[40:05] Александр: Ответ вполне себе исчерпывающий. И бэкап то, что ты делаешь, сразу прикрывает. Конечно, ты можешь потерять немножко данных, но это уже мелочи.

[40:14] Вастрик: Ну, там надо глянуть, сколько это стоит, какие у них pricing-полиси. Потому что если у меня, условно, за сервера в клубе я плачу физически, по-моему, 30 долларов в месяц — то есть копейки, — а база данных managed будет стоить плюс 100 к этому, то зачем мне туда переезжать, если и так всё нормально работает.

[40:41] Александр: Ну, вообще да. Вообще берите managed, они нормальные, классные — там и статистика сразу будет. Мне как раз это нравится: одна из идей облачных провайдеров в том, что они предоставляют managed-базы данных. Все эти кубернетесы и всякая шляпа вокруг, может, не сильно интересуют, но managed-базы данных — это реально ценность. Но они, как ты сказал, стоят. У меня во всех проектах managed-база — это прям больше половины стоимости всего, за что я платил. Поэтому косты — один из аргументов, чтобы это не использовать. Ну и нужно иметь довольно крепкие стальные яйца, чтобы этим заниматься. Ты из олдскульных ребят, которым это не в новинку: базу поднял, volume примонтировал, бэкап настроил. А для кого-то поднять базу данных — да вы что: я её только в веб-морде видел, веб-интерфейсы, сиквельные запросы, и то мне роли админы настраивали. В современном мире всё меньше значимость этого: люди, которые начинают входить в разработку, всё меньше взаимодействуют с базой данных на таком уровне, к которому привык ты.

[41:54] Вастрик: Да, я как раз из тех, кто и Oracle локально поднимал. А Oracle локально запустить — это вообще-то не очень просто, попробуйте. Там целый мануал и процесс инсталляции. Ну и, естественно, Postgres, MySQL. То есть мы в универе ещё таким развлекались. Мне кажется, сейчас уже большинство даже не знает, как это сделать — не в докере.

[42:19] Александр: У тебя пять копеек?

[42:21] Вастрик: Пять копеек про базы данных вставлю. Сейчас ещё можно глянуть на open-source-ные альтернативы Firebase. Например, есть такой проект — Supabase. Он даёт тебе Postgres с extra steps, и при этом ты можешь его self-hostить. Ты просто берёшь ещё одну машинку и делаешь из неё managed-базу данных с аутентификацией и всякими функциями. Они сейчас активно набирают обороты, потому что многим нужно хостить эти эмбеддинги, вектора для AI-моделек, для LLM-ок. Тебе нужно очень много места где-нибудь в Postgres, и желательно в своём. Поэтому многие ставят их себе на серверы и используют как managed.

[43:03] Александр: Прикольно. Это self-managed database.

[43:06] Вастрик: Self-managed, да, наверное. Ну вот, короче, Supabase.

[43:11] Александр: Прикольно. Все ссылочки будут в описании или в посте соответствующего Telegram-канала «Тысяча фичей». Заходите.

[43:17] Вастрик: Они ещё админку к этому дают. По сути, сервер базы данных превращается в такую глобальную админку: ты видишь таблички, прям на вебе можешь зайти, посоздавать базы данных. То есть тебе вообще не нужна никакая сторонняя админка — админка в смысле для базы, не для сайта.

[43:36] Александр: Блин, круто. Вот ты мне… Я не знал про такую штуку, обязательно пойду посмотрю после выпуска. Прям стоит. Слушай, а такой вопрос: аналитика. Понимание того, что происходит с твоим клубом, устроено только через Cloudflare, ты там смотришь? Или сам запросы в Postgres делаешь? Или у тебя есть какая-то тула для этого?

[43:58] Вастрик: Только Cloudflare — по визитам, по географии, по самым просматриваемым страничкам. Никаких Google Analytics, Яндекс.Аналитики нет. Одно время на блоге у меня была Яндекс.Аналитика, когда это ещё не было за шкваром. Потом я понял, что просто в неё не хожу. Ходил смотреть за единственным графиком — число просмотров, разбитое по разным страничкам. Ну, ещё рефералки смотрел, откуда пришло, было интересно. Но с появлением соцсетей все рефералки стали пустыми, потому что все приходят из каких-то приложений — Инстаграма, Твиттера. А если мне нужно выгрузить статистику за год, я это делаю в Postgres: делаю там GROUP BY — давай-ка мне, сколько там в среднем за неделю.

[45:00] Вастрик: …делал аналитические запросы на OLTP-базе.

[45:03] Александр: Как ты мог? Ты же повесишь базу.

[45:15] Вастрик: Ну, блин. Ну да, да. Если вы стесняетесь вешать базу, то делайте read-only реплику, считайте всё там. Какая вам OLTP, вы что, Oracle тут настраиваете?

[45:25] Александр: Мне даже, по-моему, на работе, на довольно больших проектах, когда нужно было считать метрики, мы делали просто отдельную read-only реплику и гоняли там свои статистики. Никаких OLAP, кубов не было. Это уже для аналитиков. Ну и даже у них уже BigQuery есть: всё выгрузил в BigQuery, всё там лежит, всё считается. Только чемоданы денег гуглу отвози — и всё красиво.

[45:56] Александр: Так, и ещё у тебя из стека, я видел, есть Redis. Я так понимаю, это просто кэшик, чтобы сессии хранить?

[46:05] Вастрик: Сессии, всякие временные ID — типа телеграмовских. Это всё Redis, моё любимое, моё всё. Я без него на улицу не выхожу, как говорится, — это мой everyday carry kit. В любом проекте всегда нужно что-нибудь быстренько закешировать в памяти, чтобы далеко не ходить, и это всегда Redis. Он меня никогда не подводил — вообще один из тех продуктов, которые тупо не подводят. Они простые, как сапог: даже код можно читать просто с листа, как на Python, настолько он простой. А через Redis чаще всего ещё делается pub/sub — чтобы гонять какую-нибудь асинхронщину, ну, имейлы рассылать, например. Ты же не будешь рассылать имейлы из главного треда — ты положишь куда-то тасочку, потом какой-нибудь воркер эту тасочку оттуда возьмёт и выполнит. Раньше для этого у всех был Celery, но он дерьмо. Так что все приехали на легковесные брокеры на pub/sub Redis, которые по сути не добавляют никакой комплексити, просто работают. У меня, по-моему, имейлы рассылаются, телеграмовские дайджесты — вся-вся асинхронщина. Это Redis всегда.

[47:30] Александр: А сколько у тебя под него оперативки выделено?

[47:32] Вастрик: Сейчас посмотрю. Восемь гигабайт.

[47:36] Александр: Ага. То есть, да, я говорю, там ничего нет вообще.

[47:40] Вастрик: Кайф-кайф. Восемь гигабайт — это total оперативка на всём сервере. Redis из них, наверное, до одного не доходит.

[47:48] Александр: Прикольно. Но в целом, слушай, звучит так, как будто оно и так должно быть. Потому что зачем больше, если оно работает нормально?

[48:03] Александр: Я в питончиках прям совсем slowpoke. И вроде как у него с многопоточностью некоторые проблемы есть. Ты вот упомянул main thread, асинхронную обработку. Как сейчас в современном Python с этим обстоят дела? Если мне нужно, чтобы много запросов одновременно на сервер приходило, они все в одном процессе обрабатываются — как это работает? Расскажи.

[48:25] Вастрик: Если на сервер приходит много запросов, и особенно они маленькие, и особенно тебе хочется делать это очень быстро, то лучший способ делать это в Python — взять Go. Написать мегасервис на Go. У нас так, например, картиночный мегасервис работает: его задача — ресайзить на лету миллиард картинок и отдавать их. Он там кусок на Go. Но в целом Python тоже: если твоя сложность не вычислительная, а именно I/O — то есть тебе нужно быстро-быстро-быстро кидать джейсоны обратно клиенту, — то asyncio, когда появился, и вся асинхронщина с event loop на Python вообще решила все проблемы. Да, он всё ещё в одном потоке — ну запусти просто рядом под load balancer пять инстансов этого приложения, вот тебе пять потоков. В Python мы решаем проблему просто: запускаем их пять штук. Это довольно быстро, если тебе не что-то считать надо, а именно взять из базы и отдать. asyncio вообще отлично справляется.

[49:34] Александр: Да-да, пользовался для написания Telegram-бота — точнее, другой библиотекой, которая поверх asyncio работает, — замечательный экспириенс. Я не понимаю, зачем писать бота на Java: если бы ты видел, как выглядит код Telegram-ботов на Java, ты бы ужаснулся. А на Python оно как будто бы язык создан для Telegram-ботов, я так скажу.

[49:58] Вастрик: У нас есть один бот в клубе на Kotlin, которого никто не может поддерживать. Никто не знает ни Kotlin, ни Telegram, мы все хотим его переписать. Так что, друзья, если кто-то хочет помочь Вастрику или просто законтрибьютить в отличный проект — вот, пожалуйста, перепишите наконец-таки с Kotlin на Python.

[50:19] Александр: Да-да-да.

[50:21] Вастрик: Никогда не думал, что так скажу, что такая фраза из моих уст будет произнесена: «Перепишите с Kotlin на Python, пожалуйста».

[50:28] Александр: Это реальность, да, такое бывает. Слушай, вопрос, наверное, подводящий к следующей теме, но про твой клуб. Я очень внимательно читал readme и contributing, смотрел, как это всё работает, запускал у себя локально, кстати. Кому интересно — можете сходить на GitHub, сделать git checkout и docker compose up. Буквально две команды, чтобы локально поднять клуб и писать там посты, ковыряться в админке. Отличный пример того, как в целом должен выглядеть developer experience для человека, который хочет потыкать, посмотреть продукт: максимум две команды. За это тоже респект. Вопрос следующий. Там было несколько упоминаний того, что если вы хотите использовать код клуба — пожалуйста, используйте, только укажите авторов, мол, powered by Vas3k Club. И был такой заход — типа мини-темплейта для закрытых комьюнити-сообществ: если хотите себе такое сделать, можете форкнуть Вастрик-клуб и сделать своё сообщество, указав, что автор — Вастрик. Расскажи, как ты видишь эту модель — Вастрик-клуба как платформы, как движка для других?

[51:46] Вастрик: Изначально планов делать из этого платформу не было вообще. Код был выложен на GitHub исключительно потому, что… почему бы и нет? Чего скрывать код. Я все свои pet-проекты всегда выкладывал на GitHub, люди даже видели, как я их разрабатываю в прямом эфире, могли подписаться. С клубом было абсолютно так же. Плюсом к GitHub у тебя идёт нормальный issue-трекер, бесплатный GitHub Actions, если репозиторий open source. В общем, много плюсов по сравнению с тем, чтобы хранить код где-нибудь на локальном гите. Локальный гит у меня тоже есть — Gitea, который живёт на домашнем облачке и просто сливает всё с моего же GitHub на случай, если там опять какая-то война, санкции и «извините, нам нужно закрыть ваш аккаунт». То есть идеи делать из этого именно open-source платформу не было. Это был скорее open code: когда ты просто выкладываешь код, но без обязательств. Плюс было удобно, что некоторые ребята находили какие-то баги и такие: блин, пойду пофикшу. Самое простое — опечатки на главной странице: чувак просто присылает pull-request, мол, закрою за тебя опечатку. Но со временем люди стали использовать это как платформу, у некоторых даже получилось: они просто грепали всё, где написано «Вастрик», и меняли на какой-нибудь «Олег», и дальше запускали у себя. Сейчас, по-моему, то ли два, то ли три живых форка осталось: у Дорофеева, у Максима — знаменитый такой чувак, у него как раз клуб на этом движке, — ещё Сорокин-клуб, не помню, чем они занимаются, какой-то рекламой или маркетингом. Все они сделали себе форки. Мы даже хотели как-то собраться, сделать всем удобно: я даже вынес фича-флаги, которые чаще всего просили. Например, они хотели открытый клуб — чтобы вся главная была открыта. Мы сделали фича-флаг специально, «открыть главную для всех». Но дальше особо не пошло. Я думал, придут ещё ребята, скажут: каждому нужна своя система оплаты, давайте собирать разных провайдеров оплат, апстримить в мастер, чтобы люди могли в настройках сказать «я хочу Яндекс.Кассу, а не Stripe, которым мы тут в Европе пользуемся». Но это не пошло. Open source — это процесс.

[54:44] Александр: Хорошо ты описал, что это процесс. Вообще, когда я это прочитал, меня довольно вдохновила идея, что можно использовать клуб как основу для собственного клуба. Это как раз плюс трушного open code, как ты говоришь: когда мне хочется запустить какую-то штуку, я не готов писать два месяца что-то подобное твоему клубу, я могу просто форкнуть его, грепнуть, внизу указать, что автор — ты, в футере, и запустить, проверить, что моя идея стартапа с клубом вообще нафиг никому не нужна, люди туда не идут, — и сохранить себе два месяца жизни. Что, безусловно, хорошо.

[55:27] Вастрик: Ну да. Сейчас уже появились платформы, на которых ты можешь делать своё комьюнити. Платные, естественно, но зато они экономят тебе время на тестинг MVP. Но когда я писал, этого ещё ничего не было, ни одной self-hosted именно платформы я не нашёл. Был Forem, самый близкий к этому, на котором работает Dev.to. Но хотелось что-то как Forem, но своё, с другими типами постов и всякими другими плюшками.

[56:01] Александр: Ну, я тебя прекрасно понимаю. Я всё время бью себя по рукам, когда хочу очередное что-то сделать своё, потому что понимаю: скорее всего, это будет мертворождённое, и я потрачу много сил. Но вероятность того, что что-то получится, тоже есть, и я постоянно что-то начинаю делать. Пока что нет у меня такого успешного проекта, как у тебя, — и тут как раз подводочка про инди-хакинг. Я такой термин не слышал, может быть, я довольно молодой, поэтому…

[56:34] Вастрик: Нет, там тоже все ребята примерно 20 лет. Я слишком старый для инди-хакинга, наверное.

[56:40] Александр: Ну давай раскроем. Мы говорим про философию инди-хакинга — это делание проектов для себя, а не для работы. В чём она состоит, расскажи.

[56:50] Вастрик: Инди-хакинг, или мейкинг, как ещё себя называют, — это такое движение, когда ребята делают компанию условно одного человека и запускают один продукт, который окупается, который они продают. У них нет ни инвесторов, ничего, и это даёт им огромные плюсы: не нужно содержать команду разработки, не нужно поднимать деньги инвесторов, а потом страстно пытаться их отбить. Это такие волки-одиночки, которые, поголодав годик-два, поделав десятки проектов в год, всё-таки выстреливают одним, начинают его развивать. Топовые инди-хакеры иногда выходят на месячную зарплату, какую ФАНГи платят за год, — то есть очень неплохой экзит. При этом их расходы минимальны: они чаще всего едут каким-нибудь диджитал-номадом куда-нибудь в Азию, живут на виллах, пишут код и ничего никому не должны. Мне эта штука началась лет десять назад — хотя она всегда была, просто её так назвали, она волнами приходит и уходит. Я тоже начал этим заниматься до того, как узнал, что это называется инди-хакинг: просто делал свои проекты, сначала даже не думал о монетизации, мне было интересно с кодом разобраться, с технологией. Потом начал думать: как тут написать что-то, что будет приносить людям ценность, за которую они захотят принести мне доллар. Поделал несколько проектиков, и клуб был тем, который таки завёлся: сошлись все звёзды, люди пришли, им понравилось, мы стали тусить, и у меня появился неплохой второй инком, доход, который платит мне ипотеку. Я пока не вышел на те звёздные уровни, но мне особо и не надо. Сейчас думаю, что бы ещё такого запустить.

[59:18] Александр: Да, так вот чем я занимался всё это время — я инди-хакал. А я-то думал, что фигнёй всякой.

[59:25] Вастрик: Ну, инди — это типа independent: ты не поднимаешь деньги, не зависишь ни от кого, кроме себя самого и своего макбука. А хакинг — там была идея, что это как growth hacking, когда люди искали хитрые варианты, как зайти в аудиторию, чтобы за ноль денег сразу получить 20 миллионов пользователей. Хакинг примерно такой же: у людей есть челленджи — типа каждый месяц ты запускаешь новый проект, и делаешь так целый год, или вообще каждую неделю новый проект. У тебя очень жёсткие рамки: за неделю найти проблему каких-то людей, придумать способ решения, решить и выкатить — и чтобы хотя бы один-два человека это купили. Абсолютно простые вещи: типа помодоро-таймер, который в окошке поверх всех других окошек просто тикает, и это удобно. И реально, когда у людей такие глупенькие проекты выстреливали и начинали приносить по 20 тысяч долларов в месяц, все, конечно, завидовали: как ты продал таймер на 20 тысяч? А мы тут думали платформу для блогеров запускать, подняли инвестиции, пригласили в совет директоров каких-то чуваков, у нас 15 разработчиков — и мы не заработали 20 тысяч долларов, а ты продал будильник и заработал.

[1:01:07] Александр: Да, так и было.

[1:01:09] Вастрик: Люди просто искали такие ниши, решали кучу реальных человеческих проблем, а не вот эту новую платформу для блогеров, — и за счёт этого становились успешными. Сейчас инди-хакинг выходит немного в мейнстрим, опять же по версии самих инди-хакеров: там уже много людей и организаций, даже свои инфоцыгане инди-хакерские начали появляться. Потому что везде, где есть деньги — особенно где это выглядит со стороны как лёгкие деньги, хотя это не так, — сразу начинается «купи мой курс, я расскажу тебе как».

[1:01:52] Александр: Ох, это больная тема, да, со всеми этими странными ребятами, которые что-то толкают. Я вообще свой подкаст запустил, и последней каплей была как раз невозможность послушать что-то техническое в русскоязычном айтишном сообществе. Я такой: да что ж, все тебе либо курсы продают, либо говорят, какие они крутые, либо обсуждают высокоуровневые архитектурные концепты, а вот такое прикладное — типа как база данных работает, как в странице байтики расположены, почему оно вот так работает, — никто об этом особо не говорил. И это была моя мотивация: я так этот стеклянный потолок пробил и начал делать подкаст именно поэтому. Но это уже другая история. Классно, что мы про инди-хакинг проговорили. У меня, знаешь, мысль появилась. Сейчас в этом странном инфополе эксперты объясняют тебе, разработчику, зачем тебе нужен pet-проект: мол, работодатель будет смотреть на твой pet-проект, и он тебя разовьёт. А я как раз с другой стороны: зачем мне нужен работодатель, если я могу делать pet-проект? Это даже вывернутая наизнанку штука, которая мне лично намного ближе. И она хотя бы вдохновляет: делать свой проект, вложить туда душу — это твоё. А когда ты делаешь что-то для работодателя, это не твоё, это его, ты за это просто деньги получаешь.

[1:03:23] Вастрик: Ну, это тоже довольно очевидное наблюдение. Но ещё странно, как человек, всю жизнь делавший pet-проекты и по сути пришедший в программирование, чтобы программировать себе, могу сказать: работодатели скорее напрягались, когда pet-проект есть. Они такие: а, вы там не сто процентов времени будете работе уделять? Это ещё когда я в России работал. Здесь-то всем похер, в Европе они наоборот: о, pet-проект, давай расскажу, тут у всех есть какой-нибудь pet-проект — хотя чаще всего их pet-проект это работать диджеем в местном клубе, но тоже проект. А вот лет пять-десять назад в России работодатели прям такие: ммм, а чем вы заняты, а это не будет отвлекать вас от работы? Короче, тупая идея — делать проект для работодателя. Если вы хотите что-то кодить под конкретного работодателя, так возьмите на работе какую-нибудь таску: в любой компании всегда есть нужда в каком-нибудь очередном боте или дашборде, чтобы порадовать своего менеджера или менеджера своего менеджера, — вот это и будет ваш pet-проект, вас, может, за это ещё и повысят.

[1:04:26] Александр: Да, всё так. И добавлю про то, что напрягает работодателей, — это хороший поинт. Например, у меня был проект с другом, мы это даже называли стартапом: хотели прям сделать продукт и продавать его. Я уже какое-то время над ним работал, всё у меня деплоилось, как я рассказывал в начале, всё по-инди-хакерски, но прагматично. И вот, устраиваясь на работу — у меня был перерыв между двумя работами, я весь был в этом, потом понял, что деньги-то как-то нужны, — я прямо в начале говорю: вот у меня есть это, мой проект, мой стартап, я на него трачу некоторое время, и, возможно, потом я буду там full-time или part-time уже юридически (мы же деньги хотели зарабатывать, значит, должно быть какое-то ИП). И мне работодатель говорит: ты вообще без проблем, наоборот, красавчик. И я такой: вот здесь я хочу работать.

[1:05:31] Вастрик: Да, это классно всегда.

[1:05:33] Александр: Но это было скорее исключение. Я очень сильно переживал, что мне скажут: нет, никаких твоих коммерческих проектов быть не может. Хорошо, что мы про это поговорили. Так, про инди-хакинг есть ещё что-то, что бы ты хотел добавить?

[1:05:49] Вастрик: В мире деньги тебе приносят тогда, когда ты решаешь чьи-то проблемы, — это аксиома. Чем больше проблем ты решаешь для других, тем больше они тебе рады нести деньги. Вот и всё, очень простой отбор. И сейчас в инди-хакинге очень популярны все те темы, которые мы обсуждали раньше — с абсолютно тупой инфраструктурой. Есть реально проекты, которые чуваки продавали за миллионы долларов крупным компаниям, — такой у них был экзит, — а проект был типа один PHP-файл, который он по FTP просто копировал на сервер. Это был весь проект, там вообще ничего не было, база данных была SQLite на том же диске рядом. И этот проект приносил ему десятки тысяч долларов в месяц, а в итоге у него был огромный экзит. Когда компания покупает такое, они же покупают не проект — они покупают юзербазу, чтобы толкать ей рекламу. И поэтому им на этот файл насрать: какой там Kubernetes? Он бы дольше ебался с Kubernetes, чем решал реальные проблемы. Так что вот такая интересная ниша, мне нравится.

[1:07:03] Александр: Да, мне тоже нравится. И знаешь, я не уверен, что это прям пример инди-хакинга, то, что я сейчас скажу, — наверное, какая-то параллельная штука: всякое разное спонсорство. Сейчас на GitHub есть кнопочка спонсорства, донаты в целом входят в мейнстрим. Люди, как я это вижу, — народу надоело, когда их блогеры продают всякую дебильную рекламу, и они уж лучше будут не смотреть рекламу, а платить какую-то копеечку в Patreon, спонсорить на YouTube, но поменьше видеть всего этого. Все понимают, что деятельность на YouTube, поддержка своего клуба или подкаста занимает очень много времени и усилий, и авторам иногда хочется за это какой-то инком получать. Поддержать любимого автора — по мне так это нормально.

[1:07:57] Вастрик: Это, наверное, уже не такой прям инди-хакинг, это больше про то, как тебе монетизировать себя, — influencer economy. Поддержка авторов — это ты платишь за контент. К сожалению, как только у этого автора хоть один проект таки выстрелит, на котором он сможет зарабатывать деньги, донаты ему резко прекратятся. Так устроена психология. У меня так же было: как только появился клуб, донатить мне стали так редко — типа да у него там платные чемоданы приносят, зачем я ему буду. Так что имейте это в виду. Наличие подписчиков хорошо конвертируется в первых юзеров, потому что они всегда довольны и рады попробовать то, что ты им показал. Но не рассчитывайте, что это будет вечно, — скорее всего, это до первого успеха.

[1:08:53] Александр: Ты сказал, что набор технологий, скиллов, того, что ты делаешь в философии инди-хакинга, и того, что ты делаешь на работе, — это вообще разные вещи. Давай попробуем как-то структуризировать и сгруппировать набор скиллов, которые нужны в инди-хакинге и которые могут быть совершенно не нужны, а иногда даже вредить на обычной работе.

[1:09:15] Вастрик: Да, смотри. Как я сказал в самом начале, в дисклеймере: когда ты пишешь проект для себя — свой инди-проект, pet-проект, любой код для себя, — ты пишешь его и организуешь всё (деплой, тестирование, бла-бла-бла) так, чтобы тебе же потом было удобно чинить, поддерживать, развивать. Из этого как раз получаются все упрощения: фронтенд и бэкенд у тебя в одном флаконе, всё на Django, база данных в докере — потому что нахера тебе какой-то автоскейлинг? Да какой автоскейлинг, Cloudflare поставим, он справится. Все эти упрощения идут из того, что тебе потом это всё поддерживать. А на работе ты пишешь код, чтобы другие после тебя могли его поддерживать и чинить. Это главная разница. Для этого на работе обязательно тестирование: чтобы новый чувак пришёл на проект, что-то поменял — хрясь, упали тесты, он понял, что сделал не так, и пошёл смотреть. В pet-проекте ты тесты никогда не ставишь. Никто, блять, из инди не пишет тесты. Ну, может, какие-то самые лютые опасные места: у нас авторизация покрыта тестами и оплата, всё. Остальные модули, по-моему, у нас тестами даже не покрыты. Плюс все эти кубернетесы-пубернетесы, ямлы-девопсы — это тоже чтобы другая команда, даже когда ты уйдёшь или у тебя не будет времени заниматься инфрой, смогла держать это под контролем, обмазывать мониторингами. Frontend-backend то же самое: всегда разделяют фронтендеров и бэкендеров, потому что в будущем проще найти чувака на React, чем чувака, который сразу всё умеет. Вот главная причина, почему написание кода на работе отличается от написания кода для себя. Это не плохо и не хорошо, просто у того кода две разные цели. Для себя единственный человек, который будет потом этот код поддерживать, — это ты сам. А на работе это ты, скорее всего, годочек-два, а потом другие люди, и их будет много.

[1:12:05] Александр: То, что ты оставляешь после себя, результат твоей работы — код, инфраструктура, — в одном случае заточено конкретно под то, что ты для себя одну дорожку делаешь, а в другом ты строишь магистраль для остальных. И она должна ещё как бы бить им по рукам, потому что они многого могут не знать. Тесты — почему? Потому что тот, кто пришёл и что-то сломал, не сможет свою поломку довести до продакшена: его остановят тесты.

[1:12:33] Вастрик: Ну конечно. В твоём случае ты всегда, например, тестируешь happy path: поднимаешь и протыкиваешься, ты так привык работать. И поэтому happy path можешь тестами не покрывать, потому что знаешь, что и так проверишь. Я иногда даже просто деплою на прод и смотрю в Sentry, пошли ошибки или нет.

[1:12:59] Александр: Такое…

[1:13:01] Вастрик: А почему бы и нет? Если это pet-проект, то можно тестировать на проде. Это фан. И главное, что это самый честный тест: никаких моков, ничего — реально данные в базе лежат. Дропнешь — значит дропнешь, никто же не умер.

[1:13:20] Александр: Ты правильно ещё сказал, что на работе ты пишешь код, чтобы он бил по рукам. Кстати, интересная аналогия. А для себя ты пишешь код, наоборот, чтобы он тебя в будущем любил. Ты знаешь, что через месяц уже забудешь, как там что работает. Даже если ты сам написал этот код для себя, ты абсолютно не вспомнишь, как деплоить конкретно вот этот сервер, какой там айпишник, здесь докер, здесь что-то ещё. Поэтому ты пишешь всё так, чтобы тебе будущему было максимально удобно и понятно. Ты выбираешь самые тупые вещи, которые можешь сделать, — типа деплоя по SSH, потому что знаешь, что ты их сделаешь без ошибок, а если что-то сложное — накосячишь. А на работе наоборот: ты пишешь сложно, чтобы всех других оно било по рукам, чтоб тесты падали, чтоб мастер не шёл в прод деплоить, если он красный.

[1:13:23] Вастрик: Точнее не опишешь.

[1:14:25] Александр: В этом плане важно, знаешь… Я вспоминаю себя молодого — ну, я и сейчас молодой, но тогда я прям хотел быть профессиональным, контрибьютить в open source. Мне казалось, что чем сложнее, тем ты круче. Такая ложная была уверенность: я тогда ещё на Scala писал — чем жёстче нафигатишь функциональщины, тем ты крутой профессионал. А сейчас у меня какое-то отпущение, другой уровень понимания, что наоборот: чем проще, тем ты профессиональней. Чем яснее, тем безопаснее — в инди-случае для себя самого, чтобы двигаться вперёд. Если ты что-то забыл — ты помнишь, что запушу в main, и оно само раскатится, и это всё, что тебе надо помнить в любом состоянии.

[1:15:17] Вастрик: Вот именно. Ты максимально тупо делаешь, и акцент на том, что делаешь максимально тупо, — это не делает тебя тупым, это наоборот показывает твою мудрость и опыт. Потому что если ты делаешь всё суперсложно, то, как ты говоришь, через месяц придёшь что-то поменять и забудешь, как оно отработает. Как следствие, ты это просто не поменяешь — и оно затухнет, заглохнет, не будет двигаться. Рельсы сломались, всё.

[1:15:43] Александр: Такая вот мысль прикольная. Давай гипотетически сделаем мысленный эксперимент. Допустим, сейчас ты со своим огромным багажом знаний и опыта — и в инди, и работы в компании — как бы строил свой новый инди-проект под себя? Поговорим про это, а потом то же самое сделаем в случае, когда к тебе пришли, дали миллион долларов, сказали: вот мы компания, делаем свой продукт, хотим в него инвестировать, нам нужна маленькая команда, сделай, пожалуйста. Как бы ты в этих двух случаях мыслил, какой стек выбирал, расскажи.

[1:16:25] Вастрик: Ну, в первом случае всё так же, как мы уже обсудили: максимально просто, как я всегда делаю. Фигачишь на GitHub, открытые репы, все дела. Скорее всего, стек, на котором я вообще, не приходя в сознание, могу писать код, — это Python, очевидно, какой-нибудь Postgres. Их я могу даже во сне рожать и не бороться с технологией, а наоборот использовать. И дальше погнал сам. Если приходят… ну, с чемоданом никто не приходит, но возьмём условно ситуацию, когда тебя на работе просят создать новую команду и стать её лидом, и у вас будет новый проект. Ты первый чувак на проекте, но он имеет все шансы стать огромным и важным. Тут, конечно, сначала архитектура, решение первичных вопросов выживания: кто стейкхолдеры, что система производит, куда отдаёт, откуда берёт. Скорее всего, свой MVP я бы написал сам — потому что чем быстрее ты забираешь MVP, тем проще компании сделать выводы, надо это вообще или нет. Ты не всегда знаешь внутри рабочего бизнеса, эта шестерёнка действительно нужна или это была влажная мечта какого-то топ-менеджера, которая, кроме него, никому не нужна, — а ему тоже, потому что он забыл про неё на следующую минуту. Дальше MVP живёт в проде, им все пользуются, плачут, страдают. MVP скорее всего написан так же, как я бы писал свой проект, — максимально просто. Но там уже, скорее всего, у тебя есть доступ к какому-нибудь Kubernetes, менеджеру баз данных, инфра-команда где-то сбоку сидит, — то есть уже посолиднее, там тепло, и пайплайны нормальные, и тестирование. Скорее всего, тесты здесь были бы уже нужны, потому что этот проект будут развивать дальше. И дальше ты нанимаешь на эти деньги команду под проект. Опять же, зависит от проекта. Если фронтенд-хэви, а на бэкенде джейсоны отдавать, — берёшь одного фронтендщика, одного фулстака, он там джейсоны как-нибудь на бэкенде настроит. А если наоборот, бэкенд-хэви, там AI-модель крутится, — нанимаешь на бэкенд, фронтенд по остаточному принципу. Дальше они, скорее всего, просто выкидывают нахер то, что я написал, и пишут своё с нуля, потому что они молодцы, умные, — ну, под моим руководством. Так чаще всего происходит, потому что эволюционировать из самого первого MVP в теории можно, но на практике проще, имея уже подтверждённую теорию, что эта маленькая шестерёночка работает, теперь сделать крутую шестерёнку, которая встанет в систему и которую сможет развивать вся команда. Там уже, естественно, процессы: Kanban, спринты, тесты, мониторинг — скорее всего это уже пришло тебе от инфра-команды на халяву. Дальше вы уже думаете о будущем, а не о том, как бы сейчас решить нашу проблему: проблема уже решена на фазе MVP.

[1:20:08] Александр: Чувствуется опыт, чувствуется, что ты через это так или иначе проходил. Я пока ещё нет, в силу возраста, но полностью согласен с твоим подходом. И знаешь, что я заметил? То, что ты делал и выбирал в проекте для себя, ты на начальных этапах выбрал и на работе. То есть ты сделал трансфер этих скиллов, знаний и умений на работу, чтобы сделать первое MVP, а дальше вокруг него нарастить или рядом создать совершенно новый продукт.

[1:20:39] Вастрик: Да, чаще всего хорошие, большие системы не создаются с нуля, а являются эволюцией из абсолютно одноклеточных тупых алгоритмов, которые потом много-много раз обновляются и превращаются в действительно красивую, стройную систему. Так что да: когда ты один на проекте, и он новый, и у тебя нет чёткого понимания, что это будет нужно, — это типичная IT-движуха, проверка гипотез. Если ты самолёт строишь, то ему, скорее всего, нужны крылья, тут вообще без вариантов: MVP не надо строить, их уже братья Райт построили. А если ты сервисы делаешь, то чаще всего ты не знаешь, правдива твоя теория или нет. Поэтому нужно сначала её проверить, а потом уже растить.

[1:21:33] Александр: Дальше. Ты сказал, что выбрал бы Django и Postgres, потому что ты в любом состоянии готов произвести не код, а написать логику на этом стеке. Самое важное для тебя — написать, чтобы работало, а не посидеть и поизучать новый язык. Мне кажется, как раз изучать новый язык программирования было бы неплохо на работе, чтобы за это деньги платили и ты реально задачи решал. А когда для себя проект делаешь — бери максимально то, с чем у тебя больше всего опыта. Я тоже абсолютно так же делаю: у меня всё на Java, Spring Boot, шекшмэк, погнали. И меня иногда спрашивают: а что не на Kotlin? Я говорю: потому что у меня есть Spring Boot и Java, зачем мне Kotlin? Быстрее и всё, в этом весь ответ. Цель не что-то поизучать, а сделать что-то.

[1:22:33] Вастрик: И это прикольное наблюдение: технология, которую ты взял, чтобы решить абсолютно любую проблему проекта, никакой роли не играет в дальнейшем успехе либо неуспехе. Ты, скорее всего, никогда даже не дорастёшь до ограничения этой технологии. Я никогда не дорасту до ограничений производительности языка Python — честно, никогда этого не произойдёт. А если произойдёт, то мы уже Facebook, я Марк Цукерберг, у меня уже 500 разработчиков, для которых эта проблема является проблемой.

[1:23:08] Александр: Да, ты никогда не упрёшься. Люди реально на PHP всё ещё пишут и поднимают достаточно нормальные денежки. Это вообще не проблема. Поэтому Spring Boot вы берёте или на Go пишете. Те, кто всё время обсуждают языки, фреймворки, технологии, чаще всего как раз ничего и не делают: работу свою работают, но успешных проектов у них нет. Потому что нужно пересилить себя, этот техно-дрочь, переключиться с дрочи на инструменты на дрочь на решение реальных проблем. И тогда всё становится хорошо.

[1:23:50] Александр: Хотя, вообще говоря, ты сказал, что первоначальный стек не определяет и никак не влияет на конечный результат. Я бы тут немного поспорил: если ты начинаешь писать Telegram-ботов на Rust, то, скорее всего, ты не будешь так хорошо его развивать, и он не выстрелит. Или если выстрелит, то жизнь у него будет короткая. А если ты выбрал Python…

[1:24:14] Вастрик: Ладно, хорошо. Стек может влиять, но только негативно.

[1:24:20] Александр: Окей, перефразируем так.

[1:24:24] Вастрик: Это действительно так. Я несколько проектов брал и думал: блин, возьму какой-нибудь модный язык программирования. Начинаешь писать — и зарываешься в проблемы новичка с новой технологией, ничего в итоге не пишешь, только три вечера поебался с указателями, и всё. Проблема не решена, проекта нет, а желание его делать уже пропало.

[1:24:49] Александр: Ну да. Это классическая история вообще.

[1:24:51] Вастрик: Всегда так. Поэтому всегда берите то, что вы реально знаете как свой родной язык.

[1:24:59] Александр: Да, полностью согласен. Прикольно. Спасибо. Смотри, давай напоследок поговорим про то, что бы ты использовал на фронтенде. Ты сказал Django, Postgres, Python — окей, принимается. А фронтенд бы на чём у тебя работал?

[1:25:21] Вастрик: Хороший вопрос, да. В клубе у нас очень странная организация фронтенда. Там я взял Vue вместо React — но по одной простой причине: потому что я ненавижу SPA. Прям терпеть не могу, не понимаю — нет ни единого плюса у SPA, их просто не существует. Любую вещь, которую делают на SPA, обычный браузер делает лучше. Рендеринг HTML быстрее делает обычный браузер, чем твои React-компоненты. History уже встроено в браузер — зачем ты роутер тащишь на фронтенд? Кэширование — тоже у тебя есть все эти флажочки, If-Modified-Since, HTTP-заголовки. Короче, всё это засилие SPA, вот эти сайты-спиннер-фесты: открываешь сайт, а там фестиваль спиннеров, каждый виджет свой лоадер отображает, как будто в цирк какой-то приехал, клоуны вертятся, а ты сидишь и ждёшь, как дебил, пока тебе реально твиты покажут. Зачем твиттеру SPA — я вообще не понимаю. Короче, я всегда был против SPA, и последние десять лет смотрю на фронтенд как на немного сошедший с ума цирк. Хотя опять же объясняю это тем, что ты просто старый становишься и гонишь на молодёжь — им там развлекаться. Для меня как в основном бэкенд-чувака всегда бэкенд драйвил то, что видит фронтенд: на сайте должна грузиться HTML-ка, и она честная HTML-ка, она индексируется поисковиками без каких-то server-side рендерингов. То есть SPA даже индексацию поисковиками сломали — всё сделали плохо. Ладно.

[1:27:19] Александр: Давай я тебе сейчас опровергну твой тезис, что это ты старый, поэтому бузишь, а молодёжь, в ней кровь бурлит, ей надо эти реакты. Я, скажем так, ровесник этим ребятам, я вокруг себя их вижу, и скажу, что я всю дорогу тоже не понимал, чем эти люди занимаются и почему так. Вот я как обычный студент — мы в университете писали лабы, и чтобы что-то отображалось, мы просто брали темплейты. На любом языке программирования есть template engine: берёшь HTML, рендеришь там, Bootstrap в стиле подсоединил — и оно везде работает, таблички, grid, всё. Что ещё надо-то? Конечно, оно выглядело немного отличающимся от тех сайтов, к которым ты привык, потому что большинство сайтов уже тогда были спашные. И ты такой: что-то я не то делаю, вроде сделал, вроде работает, а выглядит и ощущается не так. Я думал, это со мной что-то не так. Потом смотрю: а, то есть надо JavaScript писать, собирать это всё, и HTML с JavaScript должны рендериться в браузере, а не я HTML отправляю. Я такой: ух, йо, не, наверное, я всё-таки на бэкенд пойду. И определилась моя карьера. Я писал на React свои проекты, пытался какой-то rich UI делать, и вот этот цирк спиннеров — это то, что я у себя постоянно наблюдал: нафигачил компонентов и сидел, ждал, пока всё асинхронно загрузится, и не понимал, почему так. А сейчас я, как мне кажется, более зрелый с инженерной точки зрения, и абсолютно тебя поддерживаю. Более того, скажу: браузер — это программа, которая рендерит HTML. Она так задумана. А сейчас мы делаем то, что интерпретируем JavaScript в этой программе, прямо внутри браузера, и эта интерпретация генерирует HTML, а браузер потом этот HTML показывает. Это жесть. И я такой: в каком месте мы, как человечество, свернули вот сюда? Почему мы здесь оказались?

[1:29:39] Вастрик: Я знаю, в каком. На появлении Angular, когда Google выкатил это дерьмо, мы свернули в SPA-мир, и всё стало очень-очень плохо. Потом React всё пытался починить, но сделал ещё хуже.

[1:29:52] Александр: Блин, давай я сейчас дисклеймер скажу — как ты, что я бэкендер, ты, я так понимаю, тоже больше бэкенд-гай. Мы, может, чего-то не понимаем, но я с этим не боюсь.

[1:30:05] Вастрик: Ну, фронтендеры нас закэнселят после этого выпуска.

[1:30:08] Александр: Да-да-да. Ладно, давай дальше, к тому, что было дальше.

[1:30:11] Вастрик: Да. Дальше я решил, что клуб у меня не будет SPA ни в коем случае. Хотя понимаю, что SPA, может быть, хорошо подходит для банковских приложений и просто для программ. Но когда я вижу блог на SPA, это вызывает у меня прям полное отторжение. Поэтому я сказал, что буду всё рендерить хорошим старым HTML, но местами на сайте мне нужна интерактивность: клик на лайк, чтобы отправлял этот лайк и обновлял счётчик, или автоподсказка с поиском тегов на бэкенде. Много мелких вещей, где реально важна интерактивность и где уже есть много готовых JavaScript-библиотек — например, редактор Markdown на сайте, чтобы писать посты. Я же не буду свой писать — вставлю какой-то JavaScript. То есть я не отрицатель JavaScript, нет-нет. Я пришёл к идее: а что, если взять React, или Vue, или ещё что-то, и не оборачивать им всю страницу, а обернуть отдельные элементы? Хочу, чтобы каждая кнопка лайка была отдельным React-приложением, я имею право на это. Пошёл в интернет, спросил у людей — мне сказали, что за это на фронтенде дают лет 20 строгого режима и так вообще запрещено. Никто не смог объяснить почему, но все были абсолютно уверены, что так нельзя. Я пытался найти в интернете, кто-нибудь так делал, — нашёл одну статью на Medium, где чувак так делал, но сам сказал, что с React не смог подружиться: на каждый блок вешается новый React.createApp или что-то такое, их много, и React как-то плохо. А вот Vue.js вообще офигенно лёг, без заморочек. Я не знал тогда причин, но решил: возьму Vue, я его не знал, заодно выучу. И как-то всё хорошо пошло: каждая кнопка лайка интерактивна, а вся страница нет — HTML просто, и всё. То есть JavaScript накладывался поверх HTML, как раньше. Мне это так понравилось, что я решил: надо это как-то легализовать. Пошёл, показал другим людям: смотрите, у меня получилось. Они говорят: ну блин, не должно было. Я такой: ну получилось же. Они: ну в теории так нельзя. Я: ну ладно. Как это — в теории теория и практика не отличаются, а на практике теория и практика — две разные вещи. И у нас так получилось, до сих пор живём. Естественно, так как Vue и React — это все эти JavaScript-фреймворки, поражённые раком того, что каждый год новая версия, несовместимая со старой, у нас всё написано на Vue 2 — на том Vue, который был в 2021–2022 году, когда это писалось. Сейчас это всё устарело, и не осталось ни одного разработчика, который вообще может понять концепцию, что я на готовый HTML накладываю JavaScript-фреймворк, — а тем более на Vue 2 умеет писать, потому что они все уже куда-то уезжают. Мы остались одни, но в целом работает, я даже дописываю новые компоненты, они как-то дописываются, ничего не ломается, мне нравится. Но сейчас бы я, конечно, так делать не стал — сейчас бы я взял какой-нибудь HTMX. И на HTMX я бы всё то же самое сделал ещё куда красивее и лучше. HTMX — это JavaScript-фреймворк для бэкендеров, его все фронтендеры… если бы у них был профсоюз, они бы уже продвинули какой-нибудь законопроект о том, чтобы сажали за использование HTMX как нелегальной техники программирования — примерно как я использую Vue.

[1:32:33] Александр: HTMX собирает рабочие места у фронтендеров, нужно срочно остановить его распространение.

[1:32:37] Вастрик: Да не, они столько реакт-дерьма написали за десять лет, что рабочие места там secured до 2130 года, чтобы всё поддерживать.

[1:32:46] Александр: Весь твой спич — под ним есть очень интересные детали, которые я хотел бы подсветить. Но вначале я быстренько проговорю, потому что кто-то может быть не в курсе — у меня был целый сезон про базы данных, жёсткие чуваки по базам данных пришли и вообще не понимают, что мы тут несём. В чём твоя революция в подходе с Vue и этим миксом HTML? Она в том, что эти фреймворки — Angular, React, Vue — задизайнены под такой паттерн использования, когда JavaScript-фреймворк является движком рендеринга HTML, который потом рендерится браузером. Он отправляется на первом запросе в браузер, и дальше этот JavaScript-код определяет, как меняется страница. Делает он это так: берёт DOM, документную модель, про которую думает браузер, и куски этого DOM меняет — делает асинхронный запрос AJAX на сервер, берёт JSON, JSON представляет HTML, и подставляет кусок HTML. То есть JavaScript-фреймворк управляет всей страницей, вообще всем. И когда вы переходите в мой аккаунт или на главную, браузер вам не перезагружает страницу — этим занимается JavaScript-код внутри страницы. Грубо говоря, для совсем маленьких. А ты сделал следующее. Ты говоришь, что вообще-то браузер задуман для того, чтобы на каждый запрос сервера получать HTML и отображать его. HTTP-протокол — это HyperText Transfer Protocol, где hypertext — это, грубо говоря, HTML, потому что HTML является гипертекстом. Эти две штуки друг для друга созданы. А когда ты по HTTP гоняешь джейсоны, начинается что-то странное. И ты говоришь: давайте мы по HTTP будем гонять HTML. Но в некоторых кусках этого HTML, где мне нужна, например, кнопка like, будет встроен фреймворк Vue, который является JavaScript, но управляет не всей страницей, а только вот этим divчиком, внутри которого лежит button like. И вот он уже будет гонять джейсоны по HTTP.

[1:37:01] Вастрик: Да-да-да.

[1:37:04] Александр: И до этого, судя по всему, никто в целом такого не пытался сделать. Потому что а зачем? Есть фреймворк.

[1:37:12] Вастрик: Блин, ты назвал это революцией, но для меня это был просто единственный способ, который в мою глупую голову укладывался, — поэтому я так и сделал. Проблема даже не в том, что там HTTP, — ладно, я не привязываюсь к названиям. Проблема в том, что меня всегда смущала сама идея: чтобы отобразить не-SPA, браузер что делает? Идёт на сервер, получает HTML, рендерит его. Чтобы отобразить SPA, браузер что делает? Идёт на сервер, а тот отдаёт ему 13 мегабайт JavaScript, браузер охуевает, загружает это всё, начинает исполнять — ты всё это время ждёшь, — JavaScript ему говорит: ага, нам нужно ещё 15 раз сходить на сервер, чтобы получить разные виджеты, иди. Браузер опять идёт, опять получает 15, и только потом это начинает рендериться в HTML. Зачем? Собери это всё одним куском и отдай браузеру бедному, чтобы он не мучился. А всю интерактивность можешь навесить поверх. Короче, SPA дали вот этот дикий оверхед: сходи туда, получи 15 мегабайт JavaScript и пытайся его исполнить за те 0,05 миллисекунды, что пользователи ожидают от загрузки страницы. Не, это рак. Я решил идти нормально.

[1:38:37] Александр: Да, и вот как раз про HTMX. Здесь мы подходим к тому, что история дала виток — спираль, — и мы сейчас находимся на той позиции, где если прыгнуть прямо перед собой по спирали, то как раз вернёмся в этот мир гипертекста, когда возвращались только HTML, и так работало всё. Давай про HTMX я тоже простым языком за 30 секунд скажу, в чём его основная идея. По сути, HTMX делает то, что делает Вастрик у себя в клубе, но на уровне фреймворка — то есть он сделал нормально, как должно было быть. Он действительно принимает HTML с сервера, это не single-page application, это multi-page application. Но он решает родовые проблемы той модели, которой было противопоставлено SPA. А проблема следующая: вся страница всё время перезагружалась. Нажатие на кнопку, отправление формочки приводило к тому, что браузер перерендеривал всю страницу, у тебя терялся скролл — выглядело это как-то стрёмно. Зайдите на старые формы — вот оно так и работает. А что делает HTMX? Он говорит: а зачем нам перерендеривать весь HTML, если мы можем перерендерить только кусочки? Та же кнопка like у тебя выглядела бы как кусочек HTML — тег, типа div, у которого есть атрибут, относящийся к HTMX, и вот он делал бы этот экшен. По сути, это встроенный расширенный HTML, они говорят — extended HTML.

[1:40:16] Вастрик: Ну да-да. Там создатель прям так и заявляет, что в обычном HTML только два тега умеют делать GET и POST запросы — это тег a, линк, и тег form. А в HTMX любой тег может сделать любой запрос, причём не только POST и GET, а вообще любой. По сути, если тег a что делает — он говорит браузеру: сходи, получи HTML и замени на этой страничке, на этом табе всю страничку на новую. То HTMX умеет это сделать на любом конкретном виджете. Ты всё равно пишешь HTML, ты не оборачиваешь всё в SPA, просто добавляешь, скажем, виджет лайков со счётчиком: там тег с условным hx-on:click. И если юзер на него кликнет, ты сходишь на сервер, проставишь там лайк, и сервер вернёт тебе — причём не JSON — новую цифру лайка либо вообще новую кнопку этого лайка. То есть он вернёт тебе HTML, в который HTMX просто заместит этот виджет — заменит его на новый. И дальше ты сможешь, скажем, un-like-нуть обратно, и тебе опять сервер пришлёт кнопку в состоянии un-like-нута. Это ломает мозг, особенно тем, кто привык на фронтенде всё писать, но это так нативно для бэкендеров: ты всё отправляешь HTML-ом, все куски твоего приложения теперь могут являться просто темплейтами. А у тебя и так обычно на бэкенде всё приложение побито на темплейты. У меня есть отдельный HTML-файлик, где хранится кнопка лайка, потому что она используется на многих страницах, в каждом типе поста. Поэтому у неё уже есть отдельный темплейт, ты просто этот темплейт бросаешь через HTMX браузеру обратно, и он заменяет эту кнопку. Также ты можешь сказать target: условно, когда ты пишешь коммент, ты не хочешь, чтобы новый коммент заменил форму коммента, — ты хочешь, чтобы он добавил его в общий список, ты можешь сказать target вот туда. И у тебя продолжает работать history браузера, продолжает работать валидация форм — то, что на React делают просто боль, особенно валидацию. Там все формы переизобрели каждый тег. Зачем? Вам HTML был дан дедами, отцами. А тут ты пишешь тот самый чистый красивый HTML, если нужна интерактивность — дописываешь сверху красивый CSS. CSS сейчас вообще намного лучше, чем был в эру до SPA: там можно всё, и транзишены, и анимации. То есть у тебя может выглядеть как SPA. Многие говорят: ну Twitter же ощущается на кончиках пальцев, он интерактивный, каждая кнопочка подсвечивается. Так это, блять, не из SPA — это CSS красивый там написали. Напиши такой же для любой статической страницы — он будет такой же красивый. И при этом тебе не запрещают использовать JavaScript для действительно интерактивных элементов: нужно drag-and-drop сделать или видеоплеер вставить — иди, используй npm. Никто не отказывается от JavaScript, все отказываются от JavaScript, который рендерит за тебя всё. Этот подход мне показался таким классным, что я даже офигел, что так можно было и что кто-то решился сделать.

[1:42:53] Александр: А я удивился, почему так всегда нельзя было. Это выглядит как то, куда должен был развиваться веб в начале 2000-х. Вот так оно должно было идти.

[1:42:59] Вастрик: Ну, это смело — знаешь, как Олег Тиньков оценивает вещи: это было смело, это было пиздец как смело. Никто не набрался такой смелости тогда, в десятых, когда Google выкатил Angular, и все подумали: ну раз Google выкатил, будем все на нём делать. А Google дашборды свои внутренние на нём делал, а эти побежали блоги писать, come on. HTMX — там очень смешной фаундер тоже, чувак из Монтаны, Карсон Гросс, по-моему, зовут. По сути, это его инди-проект, он его написал один дома у себя. Он очень смешной, у них офигенно смешной твиттер, они там всё время себе меняют аватарки — единороги с лазерами из глаз, короче, очень панк-рокские вайбы. У них даже есть отдельная страничка, типа «CEO of HTMX», и любой человек может стать CEO HTMX. Сейчас там 270, что ли, CEO — можно прийти, зарегаться, и мой аккаунт станет в списке CEO HTMX. И они всё время носятся: типа в обычных компаниях и других фреймворках один CEO, а у нас их 257 — математика, чем больше, тем лучше. У них прям офигенное комьюнити, отличные вайбы, ребята реально живут этим всей душой.

[1:45:19] Александр: Слушай, ты мне сейчас, на самом деле, мем объяснил. Я буквально вчера смотрел интервью этого чувака на канале как раз у The Primeagen, которого я упоминал, и там тоже активное комьюнити, и в чате написали «So, this is a true CEO of HTMX», и все засмеялись. Я такой: хм, а в чём шутка? А сейчас ты мне её объяснил. Забавно.

[1:45:41] Вастрик: Да, у них ещё локал-мемы есть, вот CEO of HTMX. Я тоже думаю: как напишу постик, пойду запрошу, чтобы мне за пост тоже дали пост CEO.

[1:45:53] Александр: Да-да-да. Так что нам получается ждать поста от Вастрика про HTMX, правильно?

[1:45:57] Вастрик: Ну, ты меня заразил, я хочу сейчас собрать всё, что здесь сказал, в какой-то более структурированный текст — именно про HTMX. Написать про SPA, про HTMX, мне кажется, аудиторию так разъебёт.

[1:46:11] Александр: Да-да, вообще такая горячая тема, ты так с горячими глазами про это рассказывал, я думаю, должна залететь.

[1:46:16] Вастрик: Да-да-да.

[1:46:19] Александр: Ну и главное, что отклик, я думаю, будет с обеих сторон.

[1:46:23] Вастрик: И я прям захотел что-то написать своё сейчас на HTMX, руки зачесались. Надо себя как-то остановить.

[1:46:31] Александр: В общем, да, мне кажется, это отличное завершение нашего довольно технического обсуждения всего подряд. Мне очень сильно понравилось, и я бы хотел закинуть мотивашку в конце — я очень часто это делаю слушателям. Вастрик, вот скажи, как ты находишь для себя мотивацию заниматься собственными проектами? И, может быть, давай попробуем поселить мотивацию в наших слушателях для тех, кому она нужна.

[1:46:57] Вастрик: Как я нахожу? Так у меня ипотека. Берите ипотеку, берите ипотеку. У вас нет денег — у вас есть куча мотивации, чтобы что-то делать. Когда вы сидите в своих арендованных однушках и жрёте Яндекс.Еду на фанговскую зарплату — конечно, у вас там остаётся ещё и в ETF-ки инвестировать, и в отпуск ездить. А взял ипотеку в Берлине — всё, 40 лет выплачиваешь. Хочешь быстрее — иди делай проекты. Такая мотивация у вас будет.