Markdown on kenji.blog

Введение в генератор статических сайтов с использованием Hugo (руководство по миграции с WordPress)

Sun, 13 Sep 2026 02:00:00 +0900

В современной веб-разработке и ведении блогов скорость загрузки сайта, его безопасность и простота обслуживания стали критически важными факторами. «WordPress», долгое время занимавший подавляющую долю рынка как основа для блогов и корпоративных сайтов, полюбился многим пользователям благодаря своей гибкой экосистеме плагинов и интуитивно понятной панели управления. Однако, поскольку он полагается на взаимодействие с базой данных и динамическую генерацию страниц на стороне сервера (обработка на PHP), он также подвержен уязвимостям при резком увеличении трафика и проблемам с задержками отображения (latency).

Поэтому в последние годы стремительную популярность набирают «генераторы статических сайтов» (SSG: Static Site Generator). В этой статье мы подробно рассмотрим «Hugo» — один из множества SSG, разработанный на языке Go и известный своей невероятной скоростью сборки. Мы досконально разберем всё: от сравнения технической архитектуры с динамическими CMS (Content Management System), такими как WordPress, до конкретных шагов по миграции, оценки производительности с использованием математических моделей, а также уникальной структуры каталогов Hugo и порядка поиска шаблонов.

1. Технические различия между динамическими CMS (WordPress) и генераторами статических сайтов (Hugo)

В механизмах доставки веб-сайтов WordPress и Hugo используют фундаментально разные подходы.

1.1 Архитектура WordPress (Динамическая генерация)

WordPress — это типичный пример динамической CMS, которая собирает страницу на стороне сервера при каждом запросе. Когда пользователь (браузер) обращается к странице, веб-сервер (Apache, Nginx и т.д.) выполняет скрипт PHP и отправляет запрос к реляционной базе данных, такой как MySQL (или MariaDB). Полученный из базы данных контент (данные статей, категории, теги, настройки сайта и т.д.) объединяется с файлами шаблонов для генерации итогового HTML, который затем возвращается клиенту.

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

1.2 Архитектура Hugo (Предварительная генерация во время сборки)

С другой стороны, Hugo, как следует из названия «генератор статических сайтов», генерирует контент не «во время запроса», а «во время сборки» (build time). Контент хранится не в базе данных, а в виде локальных файлов Markdown, которые версионируются с помощью Git или аналогичных систем. Когда разработчик выполняет команду (hugo), Hugo считывает файлы Markdown, подставляет данные в указанные HTML-шаблоны (файлы макетов) и генерирует набор готовых чистых файлов HTML/CSS/JS.

Сгенерированный набор файлов (статические ресурсы) можно доставлять, просто разместив их в «средах статического хостинга», таких как Amazon S3, Cloudflare Pages, Netlify, Vercel или на простом сервере Nginx. Поскольку база данных и серверные языки (например, PHP) не требуются, риски безопасности (такие как SQL-инъекции или уязвимости PHP) резко снижаются, а скорость доставки максимизируется за счет кэширования на граничных узлах CDN (Content Delivery Network).

Ниже на диаграмме Mermaid показаны различия в каждой из архитектур.

flowchart TD
subgraph WordPress["Динамическая CMS (WordPress)"]
direction TB
Req1["Запрос пользователя"] --> WebServer1["Веб-сервер (Nginx/Apache)"]
WebServer1 --> PHP["Среда выполнения PHP"]
PHP <--> DB["База данных (MySQL)"]
PHP --> HTML1["Генерация HTML"]
HTML1 --> Res1["Возврат ответа"]
end
subgraph Hugo["Генератор статических сайтов (Hugo)"]
direction TB
Dev["Разработчик / CI/CD"] --> HugoBuild["Процесс сборки Hugo"]
Markdown["Файлы Markdown"] --> HugoBuild
Templates["Шаблоны (HTML)"] --> HugoBuild
HugoBuild --> StaticFiles["Статические файлы (HTML/CSS/JS)"]
StaticFiles --> CDN["CDN / Статический хостинг"]
Req2["Запрос пользователя"] --> CDN
CDN --> Res2["Мгновенный возврат ответа"]
end

2. Оценка производительности с использованием математических моделей

Одним из самых больших преимуществ перехода с WordPress на Hugo является улучшение производительности (скорости отображения). Чтобы понять это количественно, давайте выразим это с помощью простой математической модели.

Время до завершения загрузки страницы (Load Time: $T_{load}$) можно в целом разделить на время ответа сервера (TTFB: Time To First Byte) и время, затрачиваемое браузером на рендеринг и получение ресурсов ($T_{render}$).

$$ T_{load} = T_{ttfb} + T_{render} $$

В случае динамической CMS (WordPress) $T_{ttfb}$ представляет собой сумму следующих компонентов: сетевой задержки ($T_{network}$), времени выполнения серверного скрипта ($T_{php}$) и времени обработки запросов к базе данных ($T_{db}$).

$$ T_{ttfb\_wp} = T_{network} + T_{php} + T_{db} $$

В условиях высокой концентрации доступа (при высокой нагрузке) $T_{php}$ и $T_{db}$ увеличиваются нелинейно, и вся система может стать узким местом. В математическом выражении мы можем наблюдать следующее ухудшение времени отклика по отношению к количеству запросов ($N$) (где $k$ — коэффициент накладных расходов на обработку):

$$ T_{php}(N) \approx O(N^k), \quad T_{db}(N) \approx O(N^k) \quad \text{where } k > 1 $$

С другой стороны, в архитектуре, объединяющей генератор статических сайтов (Hugo) и CDN, отсутствует динамическая обработка на стороне сервера (PHP и запросы к БД). Поскольку контент кэшируется на граничных серверах, распределенных по всему миру, $T_{ttfb}$ зависит исключительно от сетевой задержки от клиента до ближайшего граничного сервера ($T_{edge}$).

$$ T_{ttfb\_hugo} = T_{edge} $$

В результате выполняется условие $T_{edge} \ll (T_{network} + T_{php} + T_{db})$, и показатель TTFB кардинально сокращается до нескольких миллисекунд или десятков миллисекунд. Кроме того, даже при увеличении количества запросов $N$ время отклика остается практически постоянным ($O(1)$) благодаря функциям балансировки нагрузки граничных серверов.

$$ \lim_{N \to \infty} T_{ttfb\_hugo}(N) \approx \text{Constant} $$

В этом и заключается математическое обоснование того, почему Hugo (статические сайты) обладает чрезвычайной устойчивостью к всплескам трафика (например, при вирусном эффекте).

3. Базовая структура и принципы работы Hugo

Чтобы освоить Hugo, необходимо понять его уникальную структуру каталогов, а также концепции «Front Matter» и «Порядок поиска шаблонов» (Template Lookup Order).

3.1 Подробное объяснение структуры каталогов

При создании нового проекта Hugo (с помощью hugo new site mysite) генерируется следующая структура каталогов:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


mysite/
├── archetypes/ # Шаблоны для создания нового контента (заготовки Front Matter)
├── assets/ # Файлы, обрабатываемые Hugo Pipes (SCSS/Sass, JavaScript и т.д.)
├── content/ # Фактический контент сайта (файлы Markdown). Служит заменой БД.
├── data/ # Внешние данные и настройки, используемые на всем сайте (JSON, TOML, YAML, CSV и т.д.)
├── layouts/ # HTML-шаблоны, определяющие внешний вид сайта (используют Go html/template)
├── public/ # Место вывода сгенерированных статических файлов после выполнения команды сборки
├── static/ # Статические файлы, публикуемые "как есть" (изображения, favicon, robots.txt и т.д.)
├── themes/ # Каталог для сторонних или собственных тем
└── hugo.toml # Файл конфигурации всего сайта (ранее основным был config.toml)

В WordPress контент хранится в таблице wp_posts MySQL, в то время как в Hugo всё управляется в виде текстовых файлов (преимущественно Markdown) в каталоге content/. Это значительно упрощает версионирование контента с помощью Git.

3.2 Управление контентом: Markdown и Front Matter

Каждый файл статьи в Hugo имеет блок метаданных в самом верху, который называется «Front Matter», за которым следует основной текст (Markdown). Front Matter можно писать в форматах TOML, YAML или JSON, но чаще всего используется YAML.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


---
title: "Понимание таксономий в Hugo"
date: 2026-09-13T10:00:00+09:00
draft: false
categories:
 - "Технические руководства"
tags:
 - "Hugo"
 - "Go"
aliases:
 - "/old-category/hugo-taxonomy/"
---
Здесь начинается основной текст. Он пишется на **Markdown**.
Мы объясним мощные возможности Hugo...

Здесь стоит обратить внимание на ключ aliases. При переходе с WordPress изменение постоянных ссылок (URL) будет иметь серьезные негативные последствия для SEO. Используя функцию алиасов в Hugo, достаточно указать старый URL, и Hugo автоматически сгенерирует HTML для перенаправления (переадресация через meta refresh). Это чрезвычайно удобно, так как избавляет от необходимости настраивать редиректы на стороне сервера (например, в .htaccess).

3.3 Порядок поиска шаблонов (Template Lookup Order)

Одной из мощных возможностей Hugo является его гибкий механизм поиска шаблонов (Template Lookup Order). При рендеринге определенной страницы Hugo осуществляет поиск по каталогам и именам файлов в определенном порядке, чтобы найти наиболее подходящий шаблон.

Например, при рендеринге отдельной статьи (Single Page) content/post/hello-world.md Hugo ищет файлы макетов примерно в следующем порядке:

layouts/post/single.html
layouts/post/list.html (Не ошибка, но обычно используется для списков)
layouts/_default/single.html
themes/<THEME_NAME>/layouts/post/single.html
themes/<THEME_NAME>/layouts/_default/single.html

Разработчики могут переопределять (override) шаблоны темы, не изменяя исходный код темы напрямую, а просто создавая файл с тем же именем в каталоге layouts/ своего проекта. Это позволяет вносить собственные настройки, не мешая будущим обновлениям базовой темы.

3.4 Таксономии (Taxonomy)

Система классификации, эквивалентная «Категориям» и «Тегам» в WordPress, в Hugo называется «Таксономией» (Taxonomy). По умолчанию Hugo поддерживает таксономии categories и tags, но, отредактировав файл hugo.toml, вы можете свободно добавлять пользовательские таксономии (например, series, authors и т.д.).

1
2
3
4
5
6


# Пример hugo.toml
[taxonomies]
 category = "categories"
 tag = "tags"
 series = "series"
 author = "authors"

Это позволяет упорядочивать контент и составлять списки по различным осям.

4. Процесс миграции с WordPress на Hugo

Ключом к успешному переходу с WordPress на Hugo является то, насколько чисто вы сможете преобразовать динамический контент из базы данных в статические файлы (Markdown + Front Matter) с сохранением существующей структуры URL.

Ниже показана типичная схема пайплайна миграции:

flowchart LR
WPDB["База данных WP"] -->|Плагин| Exporter["Инструмент экспорта"]
Exporter -->| Извлечение текста, \nметаданных, изображений | ZipFile["Zip-архив / Папка"]
ZipFile -->|Распаковка| MarkdownFiles["Файлы Markdown \n(content/)"]
ZipFile -->|Распаковка| ImageFiles["Изображения \n(static/wp-content/)"]
MarkdownFiles --> Formatting["Проверка и форматирование \n(Исправление шорткодов)"]
Formatting --> Git["Коммит в Git"]

4.1 Извлечение данных и преобразование в Markdown

Для экспорта данных WordPress для использования в Hugo проще и надежнее всего использовать специальные плагины. Вот несколько типичных подходов:

Использование плагина Jekyll Exporter Поскольку Hugo имеет очень схожую структуру данных с Jekyll (еще одним SSG), использование плагина «Jekyll Exporter» для WordPress является распространенной практикой. После установки и запуска этого плагина все записи и статические страницы конвертируются в файлы Markdown с Front Matter, которые можно загрузить в виде ZIP-архива вместе с изображениями.
Собственные скрипты с использованием WordPress API Метод, при котором с помощью Python, Node.js и т.д. выполняются запросы к REST API WordPress (/wp-json/wp/v2/posts), анализируются данные JSON и самостоятельно генерируются файлы Markdown. Этот метод эффективен для сайтов, интенсивно использующих сложные произвольные поля (например, ACF), с которыми плагины не могут справиться в полной мере.
Использование инструмента wp2hugo Также существует подход с использованием инструментов командной строки (CLI), написанных на Go и т.д., для прямой конвертации из файла экспорта XML WordPress (WXR) в формат Hugo.

4.2 Сохранение структуры постоянных ссылок (URL)

Чтобы сохранить SEO-рейтинг, критически важно сохранить URL-адреса такими, какими они были во времена WordPress. Если в WordPress были настроены постоянные ссылки вида https://example.com/2026/09/13/my-post/, необходимо указать аналогичную структуру постоянных ссылок в hugo.toml для Hugo.

1
2


[permalinks]
 post = "/:year/:month/:day/:slug/"

В качестве альтернативы можно принудительно зафиксировать URL-адреса, явно указав параметр url во Front Matter для каждой статьи. Кроме того, для страниц, чьи URL-адреса изменятся, следует настроить редиректы с помощью ранее упомянутого параметра aliases.

4.3 Конвертация шорткодов

Специфичные для WordPress шорткоды (например, [gallery], [caption] или собственные коды различных плагинов) часто остаются в виде исходных строк при экспорте, поэтому требуется их обработка. Их можно либо удалить все сразу с помощью скриптов замены (sed или Python), либо использовать мощную функцию пользовательских шорткодов Hugo (путем создания собственных макетов в layouts/shortcodes/), чтобы они корректно рендерились на стороне Hugo после миграции.

5. Инструменты CLI, сборка и развертывание в Hugo

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

5.1 Запуск локального сервера разработки

При написании статей или настройке дизайна необходимо запускать локальный сервер.

1
2


# Команда запуска сервера разработки (используйте -D для включения черновиков)
hugo server -D

После выполнения этой команды сайт будет доступен для предварительного просмотра по адресу http://localhost:1313/. В Hugo встроена мощная функция «LiveReload»: как только вы отредактируете и сохраните файл Markdown, шаблон или CSS, экран браузера будет автоматически и мгновенно обновлен. Это делает процесс написания и разработки намного более комфортным, чем в панели администратора WordPress.

5.2 Сборка для продакшена и оптимизация производительности

Чтобы сгенерировать статические файлы для развертывания в рабочей (продакшен) среде, просто введите команду hugo.

1
2


# Выполнение сборки для продакшена. Опция --minify минимизирует HTML/CSS/JS
hugo --minify

Эта команда выведет файлы всего сайта в каталог public/. Добавление опции --minify удаляет ненужные переносы строк и пробелы, еще больше сокращая размер файлов. Это напрямую способствует уменьшению сетевой задержки ($T_{network}$), описанной в математической модели ранее.

5.3 Автоматизация развертывания (CI/CD)

Генерировать статические файлы каждый раз на локальном ПК и загружать их по FTP — неэффективно. В современной практике управления SSG лучшим подходом является создание среды CI/CD, в которой отправка (push) в репозиторий Git (например, на GitHub) служит триггером для автоматической сборки и развертывания.

Например, базовая конфигурация (файл YAML) для развертывания на Cloudflare Pages или GitHub Pages с использованием GitHub Actions выглядит следующим образом:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


# Пример .github/workflows/hugo.yml
name: Deploy Hugo site to GitHub Pages

on:
 push:
 branches: ["main"]
 workflow_dispatch:

permissions:
 contents: read
 pages: write
 id-token: write

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v3
 with:
 submodules: recursive # Если темы управляются как подмодули
 fetch-depth: 0

 - name: Setup Hugo
 uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: 'latest'
 extended: true

 - name: Build
 run: hugo --minify

 - name: Upload artifact
 uses: actions/upload-pages-artifact@v2
 with:
 path: ./public

 deploy:
 environment:
 name: github-pages
 url: ${{ steps.deployment.outputs.page_url }}
 runs-on: ubuntu-latest
 needs: build
 steps:
 - name: Deploy to GitHub Pages
 id: deployment
 uses: actions/deploy-pages@v2

С такими настройками мы получаем автоматизированный пайплайн, в котором достаточно выполнить действие «написать статью в Markdown и отправить (push) на GitHub», и через несколько минут обновленный сайт будет опубликован в рабочей среде.

6. Преимущества SEO и управления после миграции

Владельцы сайтов, завершившие переход с WordPress на Hugo, чаще всего отмечают три следующих существенных преимущества:

6.1 Кардинальное улучшение скорости сайта и показателей Core Web Vitals

За счет устранения запросов к базе данных и рендеринга на стороне сервера время загрузки страницы сокращается до миллисекунд. Это напрямую приводит к значительному улучшению показателей «Core Web Vitals» (LCP, FID/INP, CLS), которые являются факторами ранжирования Google. Можно ожидать снижения показателя отказов пользователей и улучшения позиций в SEO.

6.2 Освобождение от угроз безопасности

Поскольку WordPress широко используется по всему миру, он постоянно является мишенью для атак. Всегда существуют риски взлома через уязвимости плагинов или обхода формы входа в систему с помощью атак методом перебора (brute force). Однако статические сайты, сгенерированные с помощью Hugo, не имеют ни базы данных, ни среды PHP, ни даже панели управления (формы входа). У хакеров нет возможности проникнуть на сервер и изменить базу данных, поэтому риски безопасности сводятся практически к нулю.

6.3 Эксплуатация, не требующая обслуживания

Эксплуатация WordPress требует постоянного обслуживания: обновления ядра, обновления плагинов, перехода на новые версии PHP и т.д. Вам всегда приходится опасаться риска того, что сайт сломается из-за проблем с совместимостью. В случае с Hugo достаточно обновлять сам инструмент по мере необходимости, а код сайта представляет собой набор независимых текстовых файлов. Это дает подавляющее чувство уверенности в том, что «сайт не сломается, даже если его оставить в покое».

7. Заключение

В этой статье мы подробно рассмотрели переход с динамических CMS, таких как WordPress, на мощный генератор статических сайтов «Hugo» на базе языка Go: от различий в технической архитектуре и математического доказательства производительности до конкретных шагов по миграции.

Хотя переход на генераторы статических сайтов требует начальных затрат на обучение (работа с Git, синтаксис Markdown, выполнение команд CLI из терминала, понимание спецификаций шаблонизатора и т.д.), он приносит отдачу в виде «подавляющей скорости загрузки», «надежной безопасности» и «отсутствия необходимости в обслуживании», которая с лихвой окупает эти затраты.

Если вашему веб-сайту не требуются частые изменения дизайна или сложная динамическая обработка (например, функции только для зарегистрированных пользователей или продвинутые функции интернет-магазина), и он предназначен в первую очередь для распространения информации (блог, медиа, корпоративный сайт), то переход на Hugo станет одной из самых эффективных технических инвестиций. Обязательно воспользуйтесь этой статьей как руководством и сделайте первый шаг к управлению веб-сайтами нового поколения с использованием Hugo.

Технический блог на Markdown: Настройки редактора, удваивающие скорость написания

Sat, 12 Sep 2026 12:00:00 +0900

Для постоянного ведения технического блога оптимизация среды для написания является абсолютно необходимой. В этой статье мы подробно рассмотрим расширенные настройки редактора, которые радикально повысят скорость написания технических статей с использованием Markdown. Мы всесторонне обсудим максимальную кастомизацию Visual Studio Code (VS Code) и Neovim, использование сниппетов, внедрение инструмента проверки грамматики textlint, автоматизацию через CI/CD-пайплайны, а также передовые методы написания с применением LLM, таких как GitHub Copilot.

1. Математическая модель повышения скорости написания

Давайте сначала смоделируем с помощью простой математической формулы, насколько оптимизация настроек редактора влияет на время написания. Пусть общее время ввода для написания одной статьи в блоге будет $T_{total}$.

$$ T_{total} = T_{think} + T_{type} + T_{format} + T_{review} $$

Где $T_{think}$ — это время на обдумывание, $T_{type}$ — время на набор текста, $T_{format}$ — время на форматирование (например, Markdown), а $T_{review}$ — время на редактирование и вычитку.

Сэкономленное время $T_{saved}$ за счет кастомизации редактора (например, внедрения сниппетов или настроек Linter’а) можно выразить следующим образом, используя количество появлений определенного паттерна $N$ (например, шорткодов Hugo или таблиц Markdown), время ручного ввода $t_{manual}$ и время при автоматизации через сниппеты $t_{snippet}$:

$$ T_{saved} = \sum_{i=1}^{k} N_i \times (t_{manual, i} - t_{snippet, i}) + T_{review\_saved} $$

Кроме того, благодаря внедрению автоматических форматеров и инструментов Lint’инга, время, затрачиваемое на визуальную проверку человеком $T_{review}$, значительно сокращается. Максимизация этого значения $T_{saved}$ и является целью данной статьи.

2. Ультимативные настройки Visual Studio Code (VS Code)

VS Code — один из самых популярных редакторов на сегодняшний день, обладающий мощной экосистемой расширений для написания в Markdown.

Настройка пользовательских сниппетов для Hugo (`markdown.json`)

Если для технического блога вы используете генераторы статических сайтов, такие как Hugo или Docusaurus, вам придется часто вводить Frontmatter или собственные шорткоды. Функция сниппетов в VS Code позволяет развернуть их в одно мгновение.

Из палитры команд выберите Preferences: Configure User Snippets и добавьте следующие настройки в markdown.json.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


{
 "Hugo Frontmatter": {
 "prefix": "frontmatter",
 "body": [
 "---",
 "title: \"${1:Заголовок}\"",
 "slug: \"${2:slug-name}\"",
 "date: \"$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE T$CURRENT_HOUR:$CURRENT_MINUTE:$CURRENT_SECOND+09:00\"",
 "image: \"img/eyecatch.jpg\"",
 "math: true",
 "mermaid: true",
 "categories: [\"${3:Category}\"]",
 "tags: [\"${4:Tag1}\", \"${5:Tag2}\"]",
 "---",
 "",
 "${0}"
 ],
 "description": "Разворачивает YAML Frontmatter для Hugo"
 },
 "Hugo Figure Shortcode": {
 "prefix": "hfig",
 "body": [
 "{{< figure src=\"${1:image.jpg}\" title=\"${2:Заголовок изображения}\" >}}"
 ],
 "description": "Шорткод Figure для Hugo"
 },
 "Markdown Table": {
 "prefix": "mtable",
 "body": [
 "| ${1:Header 1} | ${2:Header 2} | ${3:Header 3} |",
 "| :--- | :---: | ---: |",
 "| ${4:Row 1} | ${5:Data} | ${6:Data} |",
 "| ${7:Row 2} | ${8:Data} | ${9:Data} |",
 "$0"
 ],
 "description": "Создает Markdown таблицу на 3 колонки"
 }
}

Благодаря этой настройке, достаточно ввести frontmatter и нажать клавишу Tab, чтобы мгновенно развернуть YAML Frontmatter с текущим временем, что значительно увеличит начальную скорость написания.

Поддержка написания с использованием GitHub Copilot

Если в VS Code включен GitHub Copilot, автодополнение AI с учетом контекста работает и в Markdown. В частности, для технического блога AI может предвидеть и предлагать «структуру, которую следует объяснить далее» или «связанные блоки кода», что позволяет существенно сократить время на набор текста $T_{type}$.

3. Экстремальная кастомизация в Neovim

Графический интерфейс VS Code отличный, но для любителей терминалов и виммеров (Vim-пользователей) Neovim, позволяющий делать всё без отрыва рук от клавиатуры, является наиболее мощным выбором.

Архитектура LSP в Neovim

Архитектура LSP (Language Server Protocol) и Linter в Neovim для среды Markdown выглядит следующим образом:

classDiagram
class Neovim {
+"Текстовый буфер"
+"Привязки клавиш"
}
class nvim_lspconfig {
+"marksman (LSP для Markdown)"
}
class null_ls_or_none_ls {
+"markdownlint"
+"textlint"
}
class LuaSnip {
+"Динамические сниппеты"
}
class CMP {
+"Движок автодополнения"
}
Neovim --> nvim_lspconfig : "Обеспечивает семантические функции"
Neovim --> null_ls_or_none_ls : "Диагностика и форматирование"
Neovim --> CMP : "Запрос автодополнения"
CMP --> nvim_lspconfig : "Источник LSP"
CMP --> LuaSnip : "Источник сниппетов"

Продвинутое развертывание сниппетов с помощью LuaSnip

Гораздо мощнее JSON-сниппетов VS Code является плагин для Neovim — LuaSnip. Используя логику языка Lua, можно динамически вычислять и разворачивать содержимое сниппетов.

Ниже приведен пример настройки LuaSnip, которая динамически получает текущую дату и время и разворачивает Frontmatter для Hugo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


local ls = require("luasnip")
local s = ls.snippet
local t = ls.text_node
local i = ls.insert_node
local f = ls.function_node

-- Функция для получения текущего времени JST
local function get_current_date_jst()
 return os.date("!%Y-%m-%dT%H:%M:%S") .. "+09:00"
end

ls.add_snippets("markdown", {
 s("frontmatter", {
 t({"---", "title: \""}), i(1, "Title"), t({"\"", "slug: \""}), i(2, "slug-name"), t({"\"", "date: \""}),
 f(function() return {get_current_date_jst()} end, {}),
 t({"\"", "image: \"img/eyecatch.jpg\"", "math: true", "mermaid: true", "categories: [\""}), i(3, "Category"), t({"\"]", "tags: [\""}), i(4, "Tag"), t({"\"]", "---", "", ""}),
 i(0)
 }),
 s("mtable", {
 t({"| "}), i(1, "Header 1"), t({" | "}), i(2, "Header 2"), t({" |", "|---|---|", "| "}), i(3, "Cell 1"), t({" | "}), i(4, "Cell 2"), t({" |"}),
 })
})

Таким образом, опираясь на мощь языка программирования (Lua), можно создавать невероятные сниппеты, которые вставляют не просто фиксированные строки, но и возвращаемые значения функций, или динамически увеличивают/уменьшают количество колонок в таблице в зависимости от количества введенных символов.

4. Статический анализ для совмещения качества и скорости написания (textlint и регулярные выражения)

Для обеспечения качества блога необходимо предотвращать опечатки и несоответствия в терминологии. Если делать это вручную, время $T_{review}$ катастрофически возрастает, поэтому мы внедряем статический анализ с помощью textlint.

Внедрение textlint и наборы правил для японского языка

Установите textlint в среде Node.js.

1

npm install -D textlint textlint-rule-preset-ja-technical-writing textlint-rule-prh textlint-filter-rule-comments

Создайте .textlintrc.json в корне проекта и настройте его следующим образом:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


{
 "filters": {
 "comments": true
 },
 "rules": {
 "preset-ja-technical-writing": {
 "ja-no-mixed-period": {
 "periodMark": "。"
 },
 "sentence-length": {
 "max": 100
 }
 },
 "prh": {
 "rulePaths": ["./prh.yml"]
 }
 }
}

Создайте prh.yml и определите несоответствия в технических терминах. Например, можно стандартизировать написание «サーバー» (сервер) и «サーバ», «Javascript» и «JavaScript».

1
2
3
4
5
6
7
8


version: 1
rules:
 - expected: "JavaScript"
 pattern: "Javascript"
 - expected: "サーバー"
 pattern: "サーバ"
 - expected: "インターフェース"
 pattern: "インターフェイス"

Благодаря этому при каждом наборе текста в редакторе будут выдаваться предупреждения о несоответствиях в реальном времени, что сведет время на вычитку почти к нулю.

Пакетная замена и структурные паттерны с использованием регулярных выражений

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

Например, регулярное выражение для преобразования HTML-тегов выделение в Markdown **выделение**:

Шаблон поиска: (.*?)
Шаблон замены: **$1**

Если нужно объединить лишние переносы строк в один:

Шаблон поиска: \n{3,}
Шаблон замены: \n\n

Выполнив их с помощью функции поиска и замены VS Code (в режиме регулярных выражений) или команды %s в Neovim (:%s/$.*?$<\/b>/**\1**/g), вы сможете мгновенно унифицировать формат.

Автоматическая проверка с помощью CI/CD пайплайна

Кроме того, используя GitHub Actions, мы построим CI пайплайн, в котором textlint будет автоматически запускаться при отправке (push) статей в блог. Это позволит предотвратить деплой статей, нарушающих правила.

flowchart TD
A["Автор"] -->|Пуш изменений| B["Репозиторий GitHub"]
B --> C{"Запуск GitHub Actions"}
C --> D["Клонирование репозитория"]
D --> E["Настройка Node.js"]
E --> F["npm install"]
F --> G["Запуск textlint"]
G -->|Успешно| H["Сборка сайта Hugo"]
G -->|Ошибка| I["Отчет об ошибке в PR/Коммит"]
H --> J["Деплой на хостинг (Vercel/Netlify)"]

5. Искусство написания Markdown в эпоху LLM

В современном написании технических блогов невозможно обойтись без использования LLM (Large Language Model). Использование встроенных в редактор инструментов ИИ еще больше удваивает скорость написания.

Инженерия промптов внутри редактора

Используя GitHub Copilot Chat в VS Code или ChatGPT.nvim и Copilot.vim в Neovim, не покидая редактор, можно отправлять следующие промпты:

«Создай структуру в виде иерархии Markdown для начинающих по следующим технологиям: Docker, Kubernetes, CI/CD»

После этого мгновенно генерируется разметка Markdown с заголовками и маркированными списками. Нам остается лишь добавить содержание на этот каркас.

Кроме того, написание сложных диаграмм Mermaid или математических формул (LaTeX) также можно доверить ИИ, который сгенерирует точный синтаксис по вашим указаниям. Например, основы верстки формул и диаграмм в этой статье также были ускорены за счет совместного написания с LLM.

6. Заключение

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

Осознание математической модели: Устранение повторяющихся задач для максимизации $T_{saved}$.
Использование VS Code: Сокращение ввода с помощью расширений и сниппетов в markdown.json.
Экстремальная кастомизация Neovim: Динамические сниппеты с помощью LuaSnip и полностью клавиатурное управление.
textlint и статический анализ: Интеграция CI/CD и локального Linter’а для сведения времени вычитки к нулю.
Интеграция LLM: Вывод структуры Markdown и кода для диаграмм непосредственно ИИ внутри редактора.

Внедрив эти настройки в свою рабочую среду, вы избавитесь от «рутины» при написании, а количество и качество ваших технических публикаций кардинально возрастут. Почему бы не начать с малого — например, с регистрации одного простого сниппета?