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

Отже, це перший повноцінний пост на цьому сайті.

І раз він має такий статус, то, мабуть, логічно присвятити його самому сайту.

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

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

Грубо кажучи, усе та ж сторінка в соцмережі, тільки з трохи більшою кастомізацією. Не прикольно.

При цьому бажання створити свій персональний сайт усе ж не було головним імпульсом, який привів до його появи. Швидше, кілька ймовірнісних векторів зійшлися в одній точці, і результатом цього перетину став сайт, на якому відтепер інсує цей пост.

Серед цих векторів були і ранні спроби покопирсатися в програмуванні, і спеціальність, напряму з цим не пов’язана, і політика (куди ж без неї), і війна, і дивна робота, покликана просто приносити хліб на стіл у воєнний час.

Спочатку цей сайт міг бути написаний на ASP.NET, потім на Ruby on Rails, а в підсумку створено на Django. Перший варіант витікав з інтересу до Unity (це ж C#), другий — із поради досвідченої людини, а третій уже став відповіддю на необхідність шукати новий кар’єрний шлях.

Процес створення власного сайту — штука двоїста.

З одного боку, це дуже захопливо. Усе ж таки ти буквально збираєш систему, а дорогою дізнаєшся багато нового. З іншого — це постійне порівняння з уже готовими, якісними рішеннями, і постійний голос внутрішнього критика, який каже: “недостатньо добре”. І ти знову переробляєш. Потім ще раз. І ще.

Саме в процесі розумієш, що проблема не в тому, щоб щось “накодити”. Проблема в тому, щоб зрозуміти, що саме ти хочеш зробити.

Одним із відкриттів на цьому шляху стало те, наскільки сучасні ШІ-системи настільки ж неоднозначні.

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

Один із найяскравіших прикладів тут — дизайн.

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

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

Тим не менш, коли в мене траплявся творчий тупик, імовірно значною мірою через нестачу досвіду, я використовував ШІ-системи як брутфорс натхнення.

Новий окремий git-branch, запит у дусі “ось опис мого сайту, зроби супер пупер красивий сучасний модний дизайн” — і йдеш подихати повітрям. Повертаєшся, а в тебе вже є щось неймовірно криве, місцями зламане, але водночас таке, що містить у собі окремі зерна цікавих ідей, на основі яких потім уже розвиваєш власне бачення.

Шкода, що лише під кінець, коли я вже працював над фінальними штрихами, я дізнався про Refactoring UI від творців Tailwind. Це, по суті, одна з тих книжок, з яких виростає значна частина сучасного веб-візуалу. Що вже казати — навіть ЛЛМки видають дуже схожий результат. Не знаю, хто тут був раніше — автори книжки чи сам веб, — але після прочитання починаєш особливо добре помічати цю загальну візуальну “однаковість”.

Окрема історія — сам Django.

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

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

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

Вона не те щоб захмарно складна, але це дивне поєднання підходів “ми все зробимо за тебе” і “тепер сам усе налаштовуй” досить швидко перетворюється на головний біль, коли намагаєшся підлаштувати щось під себе.

Особливо якщо в тебе підключений i18n.

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

При цьому в Django є і вагомі плюси.

Застосунок не захаращується від самого початку сотнями файлів. Ти створюєш те, що тобі реально потрібно, і часто це не вимагає розповзання логіки по кількох різних місцях програми. Поділ на окремі застосунки теж виявився досить зручною штукою: він дає просте й наочне уявлення про структуру проєкту в момент, коли просто дивишся на його структуру у VS Code.

Ну і, звісно, вагомий плюс нашого часу — завдяки великій кількості 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-бібліотеки.

Усе ж, мабуть, варто було очікувати, що додавання всього однієї літери до слова не зробить його раптом унікальним.
Будемо знати.