Блог

Решил сегодня посмотреть статистику этого блога — веб-аналитику я регулярно вижу, но после умирания FeedBurner данные по читателям этого блога через RSS собрать совсем непросто. Благо на Cloudflare можно включить ведение логов и потом заняться их анализом, например, озадачив этой задачей агента.

Оказывается, подписчиков у RSS этого блога примерно 3500. Конечно, большой вопрос, сколько из них реально читают — если сервис типа Feedly или Inoreader и показывает их количество, то возраст технологии и самих сервисов скорее предполагает, что многие аккаунты давно неактивны. Именно поэтому меня растрогала статистика десктопных клиентов — нет, Netnewswire и Reeder вполне ожидаемы, а наличие гиков можно подозревать и без наличия Emacs Elfeed. Но кто эти два человека, которые до сих пор читают блог через FeedDemon — прекрасный windows-клиент, закрытый в 2013 году? И, наконец, кто этот настоящий гик, который до сих пор пользуется Omea Pro — суперклиент для почты, мессенджеров и RSS, выпущенный в 2004 году компанией JetBrains? Отзовитесь, гики, вспомним былое!

И да, подписка через RSS — неплохой и быстрый способ читать этот блог.

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

Собственно, рассказать стоит только то, что весь процесс — от макетирования до полной имплементации и исправления багов, — занял у меня часа полтора. Конечно, благодаря AI — я взял привычный Claude Code, применил уже проверенный на паре мелких задач скилл frontend-design и так всё и сделал. Claude расспросил, какие стили я предпочитаю, какой шрифт для чего лучше использовать, что лучше сохранить из существующей темы (а тут стояла Mainroad, довольно старая тема) и нарисовал три макета в разном стиле.

Мне оставалось выбрать один из трех и через минут 15 можно было тыкать его на локальном сервере. Возможно, Claude Code и сам бы справился с вылизыванием верстки, но я предпочитаю держать минимальное количество MCP серверов, лучше уж я ему скриншотов накидаю.

Не обошлось без казусов — например, исправляя ширину поста, он вдруг заявил “А еще я убрал красную линию в заголовке” и на самом деле её убрал. Пришлось сказать, чтобы вернул.

Но результат мне нравится. Надеюсь, аудитории тоже будет лучше.

P.S. На самом деле надо честно сказать, что еще полтора часа заняли попытки заставить комментарии отображаться корректно — то есть, используя те же цвета, что и на остальном блоге. Ну, потому что в мире Умпутуна владельцы сайтов не должны хотеть других цветов кнопок и ссылок. Но и это победили.

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

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

На самом деле я немного пропустил точную дату юбилея — она пришлась на 13 декабря, что легко проверить, отлистав архив этого блога до первой записи. Но вот дальше лучше не читать — тогда, поскольку я вдохновлялся современными американскими блогами, он представлял из себя скорее Twitter. Но об этом никто не догадывался, ибо Twitter-а еще не было. Да и соцсетей еще не было. А блог был и точно будет дальше — не полагаться же на ненадежные платформы.

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

Я ничего не нашел приличного для управления контентом, скажу честно, поэтому пост пишу в VS Code, но в целом привыкнуть можно, тем более, что есть какое-то количество плагинов с макросами, которые делают написание более комфортным. Ну, а внешне, я надеюсь, блог не стал неудобным — текст есть, комментировать можно, поиск работает.

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

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

Неприятнее оказалось другое — система, красиво описывая, как она интегрирована с Wordpress, на самом деле просто быстро перелила себе все комментарии, но новые комментарии отдавать Wordpress-у не собиралась. В связи с чем мне очень неудобно перед теми, кто комментировал предыдущую запись — их комментарии никак не перенести обратно. Я могу только придумать их перепостить здесь и ответить так же, что и сделано ниже.

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

В общем, в итоге я занялся пристальным изучением творения того же Umputun — то есть системы комментариев remark42. Легко догадаться, что именно она и живет теперь здесь. Все приведенные недостатки у неё отсутствуют, а стоимость держания дополнительного контейнера равна минимальному тарифу у Replybox, к тому же я вполне могу и эту сумму сэкономить.

А ниже — те комментарии, которые остались в Replybox.

googhalava: Да, скорость загрузки впечатляет.
А вы не встречали способа писать посты в Hugo с телефона в процессе поиска? Вообще, нет способа писать посты в hugo. Посты писать надо во что-то, откуда hugo возьмет базу. В принципе, написать пост в гитхабе можно и с телефона. Можно попробовать прикрутить что-то типа netlify cms, которая умеет делать маркдаун-посты в выбранный репозиторий. С другой стороны, поскольку я давно перестал писать по 10-20 постов в день в блоге, то с телефона я скорее напишу в твиттер, а сюда можно и более основательно подготовиться.

googhalava: Я понимаю, как Hugo работает. Вопрос в том, как лучше организовать процесс написания, если ты пишешь не один и другие люди не готовы писать посты в Markdown. Я честно не знаю, как организовать процесс для нескольких человек, поскольку отправка постов несколькими человеками почти одновременно выглядит в данном случае странно. Живым людям можно вручить текстовый редактор типа ulysses или iAwriter, чтобы писать в маркдауне.

Alexey Shevchenko:
действительно быстро! Но есть вопросы:

1. Для СЕО, есть возможность генерировать читабельные URL, вместо: https://new1.blognot.co/60602/ ? Типа https://new1.blognot.co/60602/hugo-blog-kak-sdelat
2. Ответить на комментарий удалось только после отключение блокировки third-party cookies (Brave browser). Не круто, но понятно что удобно и быстро. Подозреваю в firefox и safari может быть такая же проблема.

1. Да, тут можно хоть руками задать, хоть из шаблона генерировать, я специально прописываю так, чтобы сохранить совместимость с вордпрессом.
2. В Safari да, есть такая проблема. Но вообще любая внешняя система комментариев столкнется с этим, разве что кроме того же ремарка, который можно поставить на поддомен и тогда его куки будут first-party.

zabey_ded :_ В кэш нужно уметь, он подходит где вы контролите всё. Темы лишены этого знания. Если тема без параметров, реализовать кэш просто, но никто не хочет их юзать, ибо нет ничего. Сложные темы настраиваются гибче, их скорость меньше, прирост от кеша большой, но и добавить его сложнее. А добавив, автоматически сильно усложняется допилка+понимание работы для окружающих. Если это просто (заменить всё на partialCached), почему никто этого не делает массово? Это чем-то похоже на дебаг неиспользуемого CSS в тулзах хрома. Полезно, но многие не понимают как оно работает и лезут. Если начать удалять всё неиспользуемое, можно поломать стили и не заметить. Тот же принцип: если кэш работал для вашего сайта, где все параметры одинаковы для всех страниц, это не значит, что оно заработает для других людей, которые используют более специфичные конфиги. О cache potential: 100 присваивается частям, которые не менялись при конкретной генерации для всех страниц. Эта система может ошибаться как детектор неиспользуемого CSS. Если сайдбар всегда справа, с одинаковым контентом, то вам покажет 100. Это не значит, что его можно закэшировать в 100 процентах случаев. Вот кто-то добавил новый виджет для конкретной секции сайта и всё, кэш ломается, потому что некоторые страницы теперь используют другой набор входных параметров. Это значение не константа, один раз проверил работает только если вы вообще больше к теме не притрагиваетесь и не используете её параметры во front matter. Кажется, четырехкратное ускорение вы получили в том числе, что сломали фичи, которые не используете. Поэтому «люди, осилившие язык шаблонов очень гиковского движка, знают что делают» и таки отличаются от людей, научившихся делать темы для WordPress. По крайней мере, не трогают то, в чём не разбираются на 100 процентов. Я надеюсь. А ваш вредный совет может кому-то подарить несколько незабываемых часов и сообщений на форумах в духе ПАМАГИТЕ!11. Начать с Hugo легко, оптимизировать его под готовый сайт со множеством страниц — нужно время и знания. Я настоятельно советую потратить несколько дней на изучение того, как оно работает на уровне чтения важных страниц документации (в особенности, если являетесь представителем WordPress или древнего PHP сообщества, без обид). И ридми темы тоже почитать, если вы решили готовую использовать, а не свой шаблон накодить. Иначе вас ждёт множественное наступание на грабли в самых неожиданных местах. P.S. Чёрная иконка YouTube это так было задумано?

За причисление меня к представителям PHP сообщества, наверное, надо сказать спасибо, но я вообще не программист. Я не собираюсь разрабатывать темы для этого движка и, правя шаблоны для этого блога, преследую цель только исправить шаблоны для этого блога и добиться его публикации за время, немного меньшее 10-20 минут. Почему это так разгневало комментатора — не понимаю. Я же не бегаю по форумам с заявлениями «Криворукие гошники, вы вообще в состоянии представить себе, что в блоге может быть больше сотни записей?». Видимо, потому что знаю, что нет, не могут они себе такое представить. Впрочем, не в Go дело, конечно.

Ну вот, теперь примерно можно жить — я имею в виду комментарии и прочие украшения. Есть, конечно, что еще доделать. Так что не переключайтесь.

Прошлый текст на тему ухода с Wordpress я закончил выводом, что пока не готов переносить свой блог на Hugo — слишком долго собирается, нет удобного редактора и вообще много движений руками. Но возиться с этой темой не перестал, выкладывая все новые записи теперь в двух вариантах — в Wordpress и в репозиторий на Github, откуда и собирался вариант на Hugo. Чтобы как-то ускорить сборку сайта, я перепробовал довольно много вариантов хостинга — тем более, что таких сервисов становится всё больше, а процесс тестирования предельно прост — завести аккаунт с каким-то бесплатным лимитом, указать репозиторий и подождать, пока соберется. Оказалось, что в сборке есть две основные части — собственно сгенерировать сайт из исходных данных и выложить его на CDN или другое публичное место.

Генерация сайта во всех случаях занимала большое время, вне зависимости от сервиса. Какой-то сервис выполнял эту работу быстрее, какой-то медленнее, но в целом эта часть занимала от 180 до 240 секунд, то есть 3-4 минуты, что особой разницы не составляло.

Выкладка уже готового сайта была тоже почему-то не быстрой. На разных сервисах она занимала от 10 до 20 минут и, например, на Cloudflare Pages ломалась по таймауту. В какой-то момент мудрый Umputun посоветовал использовать Github Actions для управления процессом и это оказалось чуть быстрее — то есть сборка сайта стала занимать 150 секунд, видимо, за счет того, что всё делается внутри сервиса, ведь исходный репозиторий тоже на Github. Правда, от идеи использования Github Pages я отказался — это самый неудобный вариант из имеющихся, — а вместо этого поднял самый простой дроплет на Digital Ocean, водрузил там самый простой веб-сервер Caddy, и наладил выгрузку готового сайта туда. Этап выгрузки стал занимать секунд 20, а, поскольку использовался rsync, то обновления стали выкладываться практически за секунду-две.

Я почти было смирился с 5 минутами на публикацию сайта, хотя и подумывал, что они обусловлены ограничениями бесплатных хостингов, и не попробовать ли самостоятельно генерировать сайт, — но тут не менее мудрый bobuk попросил ему показать статистику сборки, которая вызывается командой

hugo --templateMetrics --templateMetricsHints

Результат показал страшную вещь — оказывается, при генерации сайта из 8 с лишним тысяч одиночных записей и 500 страниц ленты (плюс страницы тегов и категорий), Hugo каждый раз (то есть 9 тысяч раз) генерировал каждый блок бокового меню (включая облако тегов, например) и собственно сам сайдбар целиком, хотя там ничего не менялось в принципе.

Bobuk хмыкнул и сказал гуглить partialCache. Я до этого и не смотрел в исходники темы особо, полагая, что люди, осилившие язык шаблонов очень гиковского движка, знают что делают, но, как я потом сообщил коллегам, принципиально не отличаются от людей, научившихся делать темы для Wordpress.

Если соберетесь сами повторить этот путь, то рецепт несложный — идете в файлы шаблонов, ищете все вхождения partial, внимательно смотрите на каждое и убеждаетесь, что оно даёт уникальный результат. Впрочем, если вы запросите статистику командой, которая приведена выше, то первой колонкой будет выведен процент идентичности результатов и, если там стоит 100, то вызов этого шаблона обязательно надо менять на partialCached.

И будет примерно такое счастье.

Как видите, время генерации снизилось почти в 4 раза. Это результаты на моем ноутбуке, actions на Github стали отрабатывать этап генерации за 30 секунд, а общее время выкладки стало занимать меньше двух минут, причем почти половину из него стало приходиться на разворачивание собственно среды для генерации и выкладки. Наверное, впрочем, тут тоже можно как-то оптимизировать, опять же унеся генерацию на собственный сервер и не таская каждый раз весь репозиторий, но и так жить можно.

Интересно, что в результате такой оптимизации перестали возникать проблемы и с другими системами — выкладка на Cloudflare Pages стала занимать 4 минуты и больше не ломалась.

Еще одной темой для изучения стали комментарии. В принципе, никаких изменений тут не произошло — либо вы отказываетесь от них, либо используете внешние комментарии. Причем есть даже решения, которые отправляют комментарии в отдельный репозиторий и из него строят отдельный блок для встраивания на страницу, но это уж слишком. Я в итоге остановился на решении от Replybox — симпатичные минимальные внешние комментарии, которые грузят буквально 10-15 кБ кода, что является абсолютным рекордом среди таких систем. Даже с включенными комментариями Google PageSpeed оценивает страницу в 100 из 100, чего не делает практически никогда при наличии других систем. Правда, система платная, но любая другая система, имеющая опцию self-hosted, тоже потребует денег на минимальный хостинг. Собственно, это заодно и ответ на вопрос, почему я не выбрал remark42 авторства того же Umputun.

Если к этому моменту вы задумались, а зачем я всё это ковыряю для личного блога, то ответов у меня два. Во-первых, это интересно. А во-вторых, меня буквально завораживает скорость загрузки страниц, которая укладывается в пару сотен миллисекунд без всякого кэширования.

Правда, как я уже тоже отмечал, все новое — это хорошо обруганное старое. Самый первый движок этого блога — Movable Type, — еще в далеком 2002-м году умел через свой интерфейс принять текст, загрузить изображения, гибко настроить шаблон и сгенерировать все страницы контента статически. А потом пришел Wordpress.

Заинтересовавшимся темой использования Wordpress как основы для быстрого фронтенда на модных фреймворках могу посоветовать симпатичную штучку под названием Frontity. Это полноценный движок, который цепляется к Wordpress через существующий REST-API и строит из полученного контента react-приложение — очень быстрое, легкое и приятное.

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

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