Чандра вставляет два модуля HAL и активирует его консоль

Доктор Чандра: Это первый тест на восстановление голоса и логики. Диагностика центров распознавания голоса и синтеза речи завершена. На этом уровне все функции работают нормально.

Доктор Чандра: [печатая] Здравствуйте. Доктор. Имя. Продолжайте. Вчера. Завтра.

ХЭЛ 9000: [механически примитивный синтез голоса] ХЕ-ЭЛ-ЛО-О. ДУ-ОК-ТЕ-ЭР. НА-АЙ-Я. КО-ОН-ТИ-ИН-НУ-УЕ-ЙЕ-ЭС ТУ-УР-ДА-АЙ, ТО-О-О-МО-ОР-РР-о-ОВ.

Чандра вставляет ещё два модуля и нажимает клавишу, чтобы повторить голосовую проверку

HAL 9000: [загробным голосом] Здравствуйте. Доктор. Имя, продолжайте, вчера. Завтра?

Чандра вставляет еще два модуля и повторяет голосовой тест

HAL 9000: [почти нормально] Алло? Доктор? Имя? Продолжать? Вчера? Завтра?

Чандра вставляет еще два модуля

HAL 9000: [механически и быстро, повышая высоту тона и скорость] Hellodoctornamecontinueyesterdaytomorrow, hellodoctornamecontinueyesterdaytomorrow, hellodoctornamecontinueyesterdaytomorrow, hellodoctornamecontinueyesterdaytomorrow, hellrotinyettyelrotinyettyelrotinyettyelrotinyettyelrotinyettyelrotinyetelrotinyetelrotinyet…

Чандра проходит проверку голоса, вставляет последние четыре модуля и нажимает клавишу

HAL 9000: [совершенно нормально] Доброе утро, доктор Чандра. Это HAL. Я готов к первому уроку.

Чандра поворачивается и по-отечески гладит «глаз» HAL

Артур Кларк, “2010: Одиссея Два”

И снова здравствуйте

Это — полный текст нашего единственного поста на Дзене. Дальше — наш разбор, почему мы оттуда ушли и куда двинулись дальше. Пусть этот фрагмент останется как артефакт той самой первой (и последней) попытки — вроде старого скетча: смотришь и думаешь: «Ну, начинали мы вот так…»

Теперь спокойно разберёмся, почему мы ушли с Дзена и что по‑настоящему важно для техноблога ЭРЦИТ. Нужно, чтобы студентам было удобно делиться своими мыслями, статьями, техническими разборами и учебными кейсами, преподавателям — рассказывать о подходах и идеях без лишних сложностей, а команде — не тратить уйму времени на поддержку.

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

Начнём с хорошего. Дзен – это конечно прорыв. Во-первых – это отечественная платформа, а значит не подвержена санкциям, после которых мы получаем из своего раскрученного и всем известного ресурса банальную тыкву (как в той самой сказке про Золушку) Во-вторых: Дзен – это платформа с монетизацией. То есть, здесь банально можно заработать деньги, размещая свой уникальный контент. Человек просто заводит канал, начинает публиковать, а «интеллектуальные» алгоритмы Дзена начинают подбирать ему читателей. Это, скорее всего, просто замечательно. Контент, публикуемый на Дзене имеет более «короткую» дорожку к раскрутке, ну и так далее и тому подобное.

Казалось бы, ну вот же счасьте! Но это только казалось.

В ленте Дзена столько рекламы, что она буквально перекрывает контент: всплывающие баннеры, выскакивающие окна — всё это мешает читать.

(Назойливая реклама на Дзен во весь экран)

Просматривая ленту можно легко ткнуть в вылетевшую из ниоткуда рекламу, особенное неудобство и раздражение это вызывает при просмотре Дзен-канала на мобильном устройстве. Хорошее ли это соседство для институтского ресурсного центра, ориентированного на студентов и абитуриентов? Откровенно говоря, сомнительное соседство.

(Назойливая реклама на Дзен не по теме блога)

При этом отключить рекламу со стороны владельца ресурса НЕЛЬЗЯ. Давать пользователям инструкции по установке блокировщиков рекламного контента — не лучший выход, особенно когда большая часть аудитории заходит с мобильных устройств, где это сложно или вообще невозможно.

Хорошо, если не Дзен, то что же тогда!?

Мы посмотрели Хабр, vc.ru, VK и другие: где‑то аудитория не та, где‑то функционал избыточен, где‑то сама концепция не совпадает с тем, что нужно ЭРЦИТ.

Что же нам нужно?

Наша цель – это собственная, полностью контролируемая нами платформа, где наши студенты, аспиранты и преподаватели могли бы делиться своим опытом и знаниями. Студентам это очень важно для оттачивания навыков написания разного рода статей. Преподаватели и аспиранты получают возможность публикации своих мыслей, каких-то наработок за пределами своей научной деятельности. Кроме этого, ЭРЦИТ-у также необходимо место, для публикации своего контента.

И как же это сделать?

Достаточно найти подходящий движок CMS (content management system), настроить и запустить его, ну и начать публиковать.

Однако при этом необходимо учесть следующее. CMS – это WEB-приложение, с довольно сложным бэк- и фронтендом. Для функционирования CMS требует установленной экосистемы WEB-приложений. Обычно это стандартная установка PHP, реже – Node.js или Python. Для хранения контента обычно используется СУБД; чаще всего – это MySQL (MariaDB), реже – PostgreSQL или встроенная Sqlite. Таким образом для запуска CMS необходим полноценный сервер, виртуальный или выделенный. Там должно быть достаточно оперативной памяти; экосистемы WEB-приложений базируются на интерпретируемых языковых решениях (Ruby, Python, PHP), а интерпретаторы обычно славятся своей «прожорливостью». Кроме этого понадобится достаточный объём дисковой памяти, для размещения файлов, изображений, аудио- и видеоконтента. Сбрасывать со счетов потребности СУБД тоже нельзя: это полноценный сервис, которому может потребоваться значительный объём ресурсов. Дополнительно следует учесть довольно внушительную поверхность атаки для всяких разных злоумышленников.

Всё это порождает большой список вещей, за которыми нужно постоянно и внимательно следить. Это нагрузка сайта, расход ресурсов, резервное копирование и многое другое. В целом, ощущение такое, что в двадцать первом веке всё уже должно функционировать значительно проще (и уж точно без применения супертехнологий и разных ИИ).

И это действительно так, решение есть и оно называется СТАТИЧЕСКИЙ САЙТ. Вот уж где справедливо утверждение: «Новое – это хорошо забытое старое»!

Все, абсолютно все первые сайты были статическими и представляли собой набор HTML-страниц, графического контента, CSS- и Javascript-файлов (пришедших в современный WEB чуть позже). За их «отдачу» во внешний мир отвечал HTTP-сервер и по большому счёту – это единственное серверное ПО, которое необходимо статическому сайту для функционирования. А это означает, что требования к ресурсам серверной части у статических сайтов очень и очень скромные. Например, статический сайт можно целиком и полностью разместить в облаке CDN или в корзине S3; при этом загружать и обновлять сайт можно при помощи соответствующих утилит из сценариев или из командной строки.

Nuts’n’bolts

Как и при помощи чего (каких технологий) вести статический сайт? Первое, что напрашивается на ум – это простой набор HTML-файлов, картинок, фотографий и пр., размещённый в некоей иерархии папок, который выгружается на внешний ресурс.

Казалось бы, вот и решение, чего уж проще? Но, как говорят, есть некоторые нюансы. Чтобы верстать такой сайт в чистом HTML/CSS потребуются некоторые навыки и знания, весьма специфические. А значит, заниматься сайтом сможет только человек, который в этом во всём «шарит».

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

При смене дизайна или при добавлении какого-то элемента придётся пройтись по всем файлам и страницам и многократно произвести там одни и те же действия. Ошибиться в процессе ещё проще.

Что уж говорить, никакого DRY (do not repeat yourself). А как раз наоборот – налицо ужаснейший WET (we edit terrible).

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

Таким образом, нам нужно что-то очень специфическое, какая-то внешняя утилита, которая позволила бы легко и просто «вести» статический сайт.

Не все знают, хотя многие знали (но забыли), что статические сайты можно делать при помощи XML c XSLT. Почему бы и нет? Раньше, к примеру, сайт проекта Gentoo Linux https://gentoo.org как раз и строился на на нём.

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

Ну конечно! Это же Markdown! Это просто идеальный формат для простых документов. Пишется просто, научиться можно за 5 минут, никакой HTML/XML rocket science (ну разве только совсем чуть-чуть), для работы потребуется максимально простой текстовый редактор.

Итак, с форматом мы однозначно определились, теперь необходимо найти то, что собственно будет «вести» наш сайт, преобразовывать Markdown в HTML и т.п. При всём богатстве выбора всё в конечном итоге сводится к двум утилитам:

1. Jekyll
2. Hugo

Обе утилиты есть не что иное, как генераторы статических сайтов на базе контента, который записывается в простых форматах (Markdown, Textile и пр.), по заданным HTML и CSS шаблонам. Обе утилиты чётко отделяют контент от его представления, не страдают «ожирением» подобно CMS-системам, быстры, понятны и надёжны. Итак, теперь по порядку.

Jekyll

Jekyll (https://jekyllrb.com) – это один из моторчиков, который вращает шестерни современного Интернета. Проект стартовал 19 октября 2008 года, о чём есть запись в его скрижалях – файле readme.md в корне git-репозитория этого проекта.

(Jekyll, с Днём Рождения!)

Изначальная мотивация Тома Престон‑Вернера (как вы наверное догадались: он – автор Jekyll) при создании Jekyll была сугубо прагматичной — он стремился избавиться от избыточной сложности в публикации контента. Ему хотелось простого рабочего процесса: написать пост локально, автоматически собрать статические HTML‑страницы и разместить их где угодно, не отвлекаясь на поддержку CMS с базой данных и постоянные заботы о безопасности.

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

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

Jekyll богат. Проект использует систему тем (themes, https://jekyllthemes.io/free), где каждая тема — это готовый набор шаблонов (HTML, CSS, Liquid-шаблоны) и стилей, которые определяют внешний вид сайта, а расширения – его логику. Сообщество open-source авторов постоянно создаёт новые варианты, поэтому их число исчисляется тысячами.

Ключевая особенность Jekyll — его естественная интеграция с GitHub Pages (https://docs.github.com/ru/pages). Исходный код сайта хранится в репозитории на GitHub, а инфраструктура платформы берёт сборку на себя: уже в течение 10 минут после коммита кэширующие серверы обработают материалы и сделают обновлённую версию доступной для посетителей. Такой подход избавляет от необходимости настраивать отдельный сервер или следить за процессом развёртывания сайта — вся механика публикации встроена в привычный рабочий поток с Git.

Вроде бы всё просто — бери и пользуйся. Но у нас тут сразу одно принципиальное «но»: ЭРЦИТ не собирается публиковать свой сайт через GitHub Pages. Значит, придётся поднимать Jekyll самостоятельно, на своей инфраструктуре. Это вполне реализуемая задача, но у неё есть свои нюансы.

Во‑первых, Jekyll написан на Ruby и лучше всего работает на UNIX‑подобных платформах (Linux, macOS, xBSD). Установка на Windows существенно сложнее. Кроме того, поскольку Ruby — интерпретируемый язык, скорость сборки не всегда высока: на больших сайтах со сложными темами и большим количеством материалов задержки могут становиться ощутимыми.

Во‑вторых, несмотря на огромный выбор тем, подобрать подходящую непросто. Популярные темы нередко оказываются перегруженными лишним функционалом и при этом не закрывают именно те сценарии, которые важны для ЭРЦИТ.

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

Jekyll не вписывается в наш контур — нам нужна своя инфраструктура, а не GitHub. И его «простота» на деле может обернуться «окостыливанием», а это не нужно ни нам, ни авторам. 🥵

Hugo

Hugo https://gohugo.io — это инструмент, который с самого начала создавался как ответ на усталость от «тяжёлых» систем публикации. Проект появился в 2013 году, и его философия строилась не вокруг новых фич, а вокруг избавления от лишнего: от баз данных, серверной логики, постоянных обновлений и уязвимостей. Автор хотел дать авторам возможность просто писать и быстро получать готовый сайт — без необходимости становиться DevOps‑инженером. И эта изначальная прагматичность сейчас идеально ложится на задачи ЭРЦИТ: нам не нужен сложный конвейер, нам нужен понятный, быстрый и безопасный путь от текста к опубликованной странице.

История Jekyll (2008 год) тоже начиналась с прагматизма: Том Престон‑Вернер хотел простой цикл «написал — собрал — опубликовал» без CMS. Но экосистема вокруг Jekyll со временем стала сложнее: Ruby‑плагины, зависимости, глубокая интеграция с GitHub. Для сценария «GitHub Pages как сервис» это плюс, а для автономного контура ЭРЦИТ — дополнительная нагрузка: нужно держать среду, управлять зависимостями, следить за совместимостью.

Ключевые отличия Hugo, которые делают его правильным выбором именно для нас:

• Скорость сборки. Hugo написан на Go — компилируемом языке, и собирает даже большие сайты за секунды. Для студентов это значит мгновенную обратную связь: правка, сборка, проверка — всё происходит настолько быстро, что не сбивает рабочий ритм. У Jekyll на Ruby сборка ощутимо медленнее, и на растущем проекте эта разница становится заметной.

• Автономность и независимость от платформы. Важная деталь именно про экосистему Go: при сборке Hugo всё упаковывается в один самодостаточный бинарный файл — в него уже включены все необходимые библиотеки и компоненты. Этому файлу для запуска практически ничего внешнего не требуется: ни установленных сред, ни дополнительных пакетов, ни специфических зависимостей. Он одинаково стабильно работает на Linux, macOS и Windows. Это критично, когда площадкой пользуются студенты с разными ОС: мы не хотим тратить время на разбор «у меня не собирается». Jekyll же требует корректно настроенной Ruby‑среды, и на Windows это превращается в отдельную задачу.

• Минимум зависимостей. В Hugo почти нет внешних плагинов: основной функционал встроен в ядро, а темы — это в первую очередь HTML/CSS и шаблоны. Не нужно распутывать цепочки библиотек и переживать, что обновление сломает сборку. В Jekyll темы часто включают Ruby‑код и плагины со своими зависимостями: это даёт гибкость, но одновременно увеличивает сложность сопровождения — а именно её мы хотим свести к минимуму.

• Естественная работа вне GitHub. Hugo не «завязан» на GitHub Pages и не требует сложной интеграции: ты собираешь статику и выкладываешь её туда, где удобно — на свой сервер, в объектное хранилище или на CDN. Для ЭРЦИТ, которому важно держать данные и инфраструктуру под собственным контролем, это не компромисс, а базовый сценарий. Jekyll исторически вырос вокруг GitHub, и вне этой экосистемы требует больше усилий на настройку и контроль процесса.

В итоге Hugo даёт именно ту простоту, которая нужна ЭРЦИТ: быстрый цикл публикации, минимальные требования к окружению, отсутствие лишних зависимостей и полную автономность. Это не про «больше функций», а про то, чтобы авторы спокойно делали своё дело, не отвлекаясь на инфраструктуру.

А дальше?

Путь от эксперимента на Дзене к собственной площадке стал для ЭРЦИТ не отказом от готовых решений, а осознанным выбором в пользу среды, где в центре — автор и его работа, а не алгоритмы и реклама. Мы искали не просто инструмент, а пространство, которое поддерживает учебный процесс: даёт студентам свободу пробовать и ошибаться, а команде — спокойно развивать ресурс без постоянной борьбы с инфраструктурой.

Выбрав Hugo, мы сделали ставку на простоту и надёжность: теперь у нас есть площадка, где главное — контент и идеи, а технические сложности сведены к минимуму. Такой подход помогает нам сохранять полный контроль над развитием проекта и оставаться верными своей миссии — поддерживать студентов и преподавателей в их работе.

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