Первый Пост: Великий init

Итак, это первый полноценный пост на этом сайте.

И раз уж у него такой статус, то, вероятно, логично посвятить его самому сайту.

Вообще, идея чего-то более личного, чем страничка в соцсетях, висела у меня давно. Чего-то такого, что не могут в любой момент ограничить, заблокировать или удалить за даже небольшой выход из формата “постик про мой отпуск))”.

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

Грубо говоря, всё та же страничка в соцсети, только с чуть большей кастомизацией. Не прикольно.

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

Среди этих векторов были и ранние попытки поковыряться в программировании, и специальность, напрямую с этим не связанная, и политическая подоплёка, и война, и странная работа, призванная просто приносить хлеб на стол в военное время.

Изначально этот сайт мог быть написан на ASP.NET, затем на Ruby on Rails, а в итоге оказался на Django. Первый вариант вытекал из интереса к Unity (Си Шарп же), второй — из совета опытного человека, третий уже стал ответом на необходимость искать новый карьерный путь.

Процесс создания собственного сайта — штука двоякая.

С одной стороны, это очень увлекательно. Всё-таки ты буквально собираешь систему, а по пути узнаёшь много нового. С другой — это постоянное сравнение с уже готовыми, качественными решениями, и постоянный голос внутреннего критика, который говорит: “недостаточно хорошо”. И ты снова переделываешь. Потом ещё раз. И ещё.

Именно в процессе понимаешь, что проблема не в том, чтобы что-то “накодить”. Проблема в том, чтобы понять, что именно ты хочешь сделать.

Одним из открытий по пути стало то, насколько современные ИИ-системы столь же неоднозначны.

Иногда смотришь на результат и думаешь: “чёрт возьми, а нахрена я тут вообще нужен, если оно за минуту выдаёт полностью рабочий код, а иногда и сразу несколько готовых частей программы?” А сразу после этого замечаешь, насколько же “не то” тебе отдаёт даже самая крутая агентская система (на момент написания Claude Code Opus 4.6 и Codex GPT 5.3).

Один из самых ярких примеров здесь — дизайн.

Даже новомодные инструменты от Google, вроде Stitch, на первый взгляд выглядят шикарно. Там тебе и полностью готовый, современный, стильный дизайн, и палитра цветов, и какие-то концептуальные картинки, и правильные акценты, и примеры шрифтов — одним словом чуть ли не полноценный брендинг.

Но начинаешь вглядываться — не то. Более отполированный, более детализированный, но всё же усреднённый slop-продукт.

Тем не менее, когда у меня случался творческий тупик, вероятно во многом из-за нехватки опыта, я использовал ИИ-системы как брутфорс вдохновения.

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

Жаль, что только под конец, когда я уже работал над финальными штрихами, я узнал про Refactoring UI от создателей Tailwind. Это, по сути, одна из тех книг, из которых растёт значительная часть современного веб-визуала. Что уж там — даже ЛЛМки выдают очень похожий результат. Не знаю, кто тут был раньше — авторы книги или сам веб, — но после прочтения начинаешь особенно хорошо замечать эту общую визуальную “одинаковость”.

Отдельная история — сам Django.

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

Начать хотя бы с того, что Model-View-Controller здесь превратили в Model-View-Template, а затем ещё и по-своему переосмыслили роли последних двух частей. Формально разницу, конечно, можно описать, но, имея пусть и небольшой опыт и в Rails, и в Django, я всё же склонен считать это в значительной степени разными названиями очень похожих сущностей.

Кроме того, то ли из-за местами многословного ООП в Python, то ли из-за желания разработчиков Django добавить побольше “магии”, сама админка ощущается одной большой неявностью.

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

Особенно если у тебя подключён i18n.

Сам i18n в Django, по сравнению с тем же Rails, ощущается довольно зачаточным. Разница в философии двух фреймворков в этой области ощущается сполна.
Нормальных и внятных гайдов по этой теме в интернете почти нет. Думаю, во многом потому, что значительная часть разработчиков находится в англоговорящей среде, где потребность в многоязычности просто не настолько остра. Им проще в сотый раз рассказать про очередные фишки вьюшек, чем подробно разбирать интернационализацию. То же самое и с .po-файлами переводов — назвать их удобными или элегантными у меня язык не поворачивается.

При этом у Django есть и весомые плюсы.

Приложение не захламляется с самого начала сотнями файлов. Ты создаёшь то, что тебе реально нужно, и часто это не требует расползания логики по нескольким разным местам программы. Разделение на отдельные приложения тоже оказалось весьма удобной штукой: оно даёт простое и наглядное представление о структуре проекта в момент, когда просто смотришь на его структуру в ВС коде.

Ну и, конечно, весомый плюс нашего времени — благодаря обилию Python-кода и распространённости Django ЛЛМки в целом неплохо понимают, чего ты от них хочешь, и часто реально помогают разобраться в тех или иных аспектах функциональности.

К сожалению, я так и не нашёл для Django нормальной альтернативы HAML из Rails, поэтому шаблоны всё же пришлось писать с некоторым количеством лишних пальцедвижений.

Для написания стилей я использовал SASS. Не SCSS, а именно его более красивый и удобный вариант, построенный на отступах, а не на фигурных скобках. Сплошное удовольствие.

Можно заметить и то, что на сайте не так уж много JavaScript.

Из основного — Turbo Hotwire, который даёт SPA-подобное поведение для SSR: префетчи, переходы по ссылкам без полной перезагрузки страницы и всё это практически от одного тега script.

Плюс кастомный переключатель светлой и тёмной темы, а также небольшая логика для запоминания состояния поиска по тегам, чтобы панелька не закрывалась при переключении.

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

Во-первых, я не JS wizard и предпочитаю не использовать экстенсивно то, что сам пока не знаю на достаточно хорошем уровне.

Во-вторых, это вытекает из первого: я хотел и хочу, чтобы сайт был максимально шустрым, легковесным и быстро загружался. Чем меньше пакет загрузки и чем меньше блокирующих запросов, тем лучше. Если бы здесь было много библиотек, бандлеров и прочей тяжёлой обвязки, мне бы пришлось ковыряться в чужом JS-коде, чтобы всё это оптимизировать, а там почти гарантированно пришли бы баги, и сайт надолго застрял бы в состоянии “в процессе разработки” с FCP ~20 секунд.

Да и в целом — а зачем? Многое из того, что делают JS-библиотеки, вполне достигается обычным CSS. А ещё большее количество вещей просто не имеет особого смысла.

Хотя планы добавить в будущем разные прикольные фишки у меня уже есть.

Из ЛЛМ, помогавших в процессе создания, это были веб-версии ChatGPT, Claude и Gemini.

ChatGPT — классный универсал.
Claude — местами чуть лучше разбирается в технических тонкостях, но почти всегда внезапно оканчивается дневной лимит и ты сидишь в резко прерванном vibe-coding-flow.
Gemini... запасной, экстренный вариант после остальных. Что-то с ним всё же не так.

Поначалу у меня была подписка на ChatGPT Plus, а потом, после её окончания, пришлось пользоваться уже целым “оркестром” из ЛЛМок. Дневные лимиты — штука ограничительная, а бесплатные версии, как правило, ещё и ощутимо слабее.

Отдельно экспериментировал с агентским кодингом — Codex, Claude Code — ощущения очень странные.

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

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

Ну а сама философия сайта — и, вероятно, частично моя собственная — уже описана на странице “О проекте”.

На этом вводный текст про сам сайт, пожалуй, можно закончить.

Дальше — больше.

P.S.

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

И вот, когда в голову пришла идея с Synthropy, я подумал: “блин, а неплохо”.
И пошёл вбивать это слово в Google. Как я поначалу и ожидал, Google упорно исправлял syntHropy на syntropy — убирал ту самую h, которой в оригинальном слове нет.

Я подумал "да, вот и оно! уникальное название!".
Как же я удивился, когда уже после покупки доменного имени и запуска сайта решил снова вбить Synthropy и увидел сразу несколько других проектов — от YouTube-канала про синтезаторы до сайта про ML-библиотеки.

Всё же, наверное стоило ожидать, что добавление целой одной буквы в слово не сделает его резко уникальным.
Будем знать.