Об этом блоге (подробности реализации)
Увидев впервые этот блог, вы наверняка подумали что-то вроде: “Боже, как же он хорош! Как он красиво и современно выглядит! А как молниеносно открывается!”
(Подумали же, правда?)
Ладно-ладно, и ежу понятно, что нет. Но с другой стороны, смею надеяться, что и кровь из глаз у вас не шла. Как бы там ни было, я обещал, что в этом блоге будут девелоперские заметки о моих проектах, а этот блог сам по себе тоже мой проект, поэтому первая заметка - именно о нём.
Сразу подчеркну: это не туториал и не полноценная техническая статья. Просто я расскажу, что и как делал, не претендуя даже на то, что делал всё правильно. Если в этой (или любой последующей) статье вы увидите код, и вам в голову придёт мысль: “Что за говно?”, то, скорее всего, вы правы, и код действительно говно. Я далеко не лучший программист на свете, и если я демонстрирую код или рассказываю о каких-то технических решениях - это не для того, чтобы похвастаться или показать “как надо” - это просто мой вариант решения задачи.
Итак. Для начала, пара слов о дизайне этого сайта. Над этим я вообще не парился.
Можно было, конечно, найти готовый дизайн и сверстать по нему что-то стильное, но:
- мне было лень;
- я уверен, что дизайн https://thebestmotherfucking.website/ - действительно лучший из возможных (кстати, если не видели раньше, зацените прогресс: https://motherfuckingwebsite.com/ => http://bettermotherfuckingwebsite.com/ => https://thebestmotherfucking.website/)
Поэтому я просто оформил всё так, чтобы выглядело не совсем уж ужасно, да и дело с концом.
Теперь о том, что же у этого красавца (я имею в виду блог) под капотом. А находится там Jekyll. Почему именно он? На то есть ряд причин:
- Jekyll достаточно лёгок в изучении (их туториал читается минут за 10, и тем не менее позволяет составить вполне цельное представление о возможностях движка);
- он изначально заточен под блоггинг (автоматическая генерация иерархии папок, встроенные инструменты для сортировки и фильтрации статей, а также пагинации списков, поддержка markdown и т.д.);
- на выходе получается простой статический сайт - кучка HTML-файлов плюс ассеты (CSS, JS и картинки) - идеально, чтобы захоститься на платформе типа Github Pages или даже из S3-бакета на AWS (этот вариант я, кстати, и выбрал, но об этом позже).
В общем, я уже и не помню, когда и откуда узнал об этом движке, но в одном из укромных уголков моего мозга жила мысль, что если я когда-нибудь я соберусь завести блог, то Jekyll - самый подходящий вариант. Так что, когда это время пришло - долго я не думал.
Я работаю на Windows (больной ублюдок, и не говорите). А пашет ли под ней Jekyll?
С одной стороны, официально Windows как платформа не поддерживается, а с другой - на вполне себе официальном сайте есть инструкция, как всё завести. Инструкция, на удивление, достаточно простая, а самое главное - рабочая: я последовал ей, и у меня всё получилось с первого раза. Ну, почти: установилось-то всё хорошо, но первая попытка выполнить jekyll serve обернулась ошибкой и падением. Впрочем, проблема тут не с Виндой - на Убунту у юзеров та же беда; добавление пакета webrick в Gemfile всё решило, но осадочек небольшой остался.
По исходному коду блога ничего рассказывать, пожалуй, не буду: там ничего интересного и нет особо - пара-тройка шаблонов и тексты статей. Но, если хотите, посмотреть это всё можно здесь.
Единственное, что хотел бы отметить: для работы с несколькими языками использовал вот этот плагин. В целом, он хорош, работу свою делает, но небольшие косяки есть. С чем пришлось столкнуться:
- в конфиге плагина есть опция
exclude_from_localizations, которая говорит: такие-то файлы / папки не нужно дублировать для каждой из локализаций, их достаточно один раз положить в корень; так вот, с scss эта фича не работает: если где-то в html у вас есть link на css-файл, который создаётся Джекиллом из scss, то этот css-файл будет скопирован в папки всех локализаций, даже если он есть в массивеexclude_from_localizations; в конечном счёте я отказался от scss из-за этого - благо, стилей у меня не так много, можно и обычным css обойтись; - в какой-то момент контент папки
_siteперестал обновляться:jekyll serveв консоли писал, что изменения он обработал, но файлы оставались прежними; приходилось после каждого изменения вручную удалять папку_site- тогда она создавалась заново, уже с актуальным контентом; потом это как-то само собой починилось; - чтобы добавить ссылки на “эту же страницу, но на других языках”, нужно городить огороды вида:
Вставить код текстом не получилось, потому что Liquid упорно отказывался интерпретировать его как строку и попросту выполнял
С исходниками блога разобрались; теперь об инфраструктуре: что где лежит, чем отдаётся. Тут я тоже хитрить особо не стал и воспользовался услугами AWS: собранный сайт лежит в бакете на S3, откуда посредством Route 53 раздаётся. Поверх этого прикручен CloudFront, чтобы файлы не лежали на одном каком-то сервере, а плавали в CDN. Как эта схема пришла мне в голову? О, это долгая история, но вы же всё равно сейчас ничем важным не заняты.
Итак, чуть больше года тому назад, по работе мне пришлось исследовать различные варианты хостинга статических сайтов. Мы собирались полностью следовать архитектуре JAMStack, и для нас была важна производительность сайта (в том числе первоначальная скорость загрузки). Мы рассматривали различные CDN, и наиболее подходящим вариантом для нас оказался Cloudfront (как достаточно широко распространённая и надёжная сеть). Отсюда и появилась эта схема: файлы собранного сайта лежат на S3, откуда они растекаются по нодам Cloudfront, а Route 53 обрабатывает привязку к домену. Тогда я воссоздал всю эту структуру, мы усиленно тестировали её с помощью Google Pagespeed Insights, но в итоге так и не утвердили (решили файлы складывать на EC2-инстансе, рядом с бэкендом, хотя Cloudfront оставили). Правильно всё настроить было непросто, поскольку в разнообразии сервисов AWS (и документации к ним) сам чёрт ногу сломит. Увы, я не сохранил конкретные туториалы, которыми я пользовался, но процесс был примерно таким. Ах да, мне же ещё пришлось купить свой собственный домен - им стал synthoel.com - чтобы условия хостинга были максимально близки к реальным. После проведения всех тестов я благополучно забыл об этом домене, и весь следующий год он жил себе своей жизнью, дублируя контент того сайта, ради которого мы изначально и проводили все эти исследования (что, кстати говоря, наверняка было вредно для SEO того сайта, если вдруг мой домен проиндексировался, но да ладно, кому это интересно).
И вот примерно две-три недели назад AWS прислал мне письмо, в котором сообщил, что собирается вскорости продлить срок действия домена synthoel.com. И тут я такой: “Блииин, у меня ж есть свой домен! Можно же с ним что-то сделать! Там ведь уже и настроено всё, надо только файлы в бакете заменить!” Вот это-то событие и послужило судьбоносным пинком под зад, который заставил меня вспомнить своё давнее желание купить слона завести блог и завести-таки блог!
Туда-сюда, неделя трудов (по часу-полтора в день после основной работы), и блог готов увидеть свет. Настраивать CI / CD я не стал: опять в основном потому, что влом, но вообще я не планирую постить что-то прям каждый день, а раз в неделю / месяц можно и руками команду для деплоя в терминал ввести. Что ж, на этом, пожалуй, и всё. Как я уже говорил, подробностей по исходному коду нет - потому что сам исходный код не слишком-то и интересен, но если хотите - ссылка на Гитхаб выше есть. Можете даже issue или pull-request-ы создавать!
Следующая статья будет нескоро, но она должна быть достаточно большой, и будет описывать проект, над которым я собираюсь работать ближайшие пару лет. Ещё увидимся!