Markdown on kenji.blog

Introducción al generador de sitios estáticos Hugo (Guía de migración desde WordPress)

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

En el desarrollo web moderno y la gestión de blogs, la velocidad de carga de un sitio, su seguridad y su mantenibilidad son factores extremadamente importantes. Durante mucho tiempo, “WordPress”, que ha tenido una cuota de mercado abrumadora como base para blogs y sitios web corporativos, ha sido utilizado por muchos usuarios debido a su flexible ecosistema de plugins y su panel de administración intuitivo. Sin embargo, debido a que implica la comunicación con bases de datos y la generación dinámica de páginas en el lado del servidor (procesamiento con PHP), también enfrenta desafíos como la vulnerabilidad ante aumentos repentinos de tráfico y retrasos en la visualización (latencia).

Por lo tanto, en los últimos años, los “Generadores de Sitios Estáticos” (SSG: Static Site Generator) se han popularizado rápidamente. En este artículo, profundizaremos en “Hugo”, desarrollado en el lenguaje Go y conocido por su abrumadora velocidad de construcción entre los muchos SSG disponibles. Explicaremos exhaustivamente desde la comparación técnica de arquitectura con CMS (Sistemas de Gestión de Contenidos) dinámicos como WordPress, hasta los pasos concretos de migración, evaluación de rendimiento mediante modelos matemáticos, la estructura de directorios propia de Hugo y el orden de búsqueda de plantillas.

1. Diferencias técnicas entre un CMS dinámico (WordPress) y un generador de sitios estáticos (Hugo)

En el mecanismo de entrega de sitios web, WordPress y Hugo adoptan enfoques fundamentalmente diferentes.

1.1 Arquitectura de WordPress (Generación dinámica)

WordPress es un claro ejemplo de CMS dinámico que ensambla páginas en el lado del servidor con cada solicitud. Cuando hay un acceso a una página por parte de un usuario (navegador), el servidor web (Apache, Nginx, etc.) ejecuta un script PHP y realiza consultas a una base de datos relacional como MySQL (o MariaDB). Combina el contenido obtenido de la base de datos (datos de artículos, categorías, etiquetas, configuración del sitio, etc.) con archivos de plantillas para generar el HTML final y devolverlo al cliente.

Este mecanismo tiene la ventaja de poder generar contenido diferente para cada visitante en tiempo real (por ejemplo: carrito de compras de comercio electrónico, página exclusiva para usuarios que han iniciado sesión), pero consume intensamente los recursos del servidor a menos que se diseñe adecuadamente un mecanismo de caché (como proxy inverso o plugins).

1.2 Arquitectura de Hugo (Generación previa en tiempo de construcción)

Por otro lado, como su nombre indica, Hugo, un “generador de sitios estáticos”, genera contenido en el “tiempo de construcción” y no en el “tiempo de solicitud”. El contenido no se mantiene en una base de datos, sino como archivos locales “Markdown” controlados por versiones con herramientas como Git. Cuando un desarrollador ejecuta el comando (hugo), Hugo lee los archivos Markdown, inyecta los datos en plantillas HTML especificadas (archivos de diseño) y genera un conjunto completo de archivos HTML/CSS/JS puros.

Los archivos generados (activos estáticos) se pueden entregar simplemente colocándolos en “entornos de alojamiento estático” como Amazon S3, Cloudflare Pages, Netlify, Vercel o un simple servidor Nginx. Como no se requiere una base de datos ni un lenguaje de lado del servidor (como PHP), los riesgos de seguridad (inyección SQL, vulnerabilidades de PHP, etc.) disminuyen drásticamente, y la velocidad de entrega se acelera al máximo al ser almacenada en caché en nodos de borde de una CDN (Content Delivery Network).

A continuación, ilustramos la diferencia entre las dos arquitecturas con un diagrama Mermaid.

flowchart TD
subgraph WordPress["CMS Dinámico (WordPress)"]
direction TB
Req1["Solicitud del usuario"] --> WebServer1["Servidor web (Nginx/Apache)"]
WebServer1 --> PHP["Entorno PHP"]
PHP <--> DB["Base de datos (MySQL)"]
PHP --> HTML1["Generación de HTML"]
HTML1 --> Res1["Devolución de respuesta"]
end
subgraph Hugo["Generador de Sitios Estáticos (Hugo)"]
direction TB
Dev["Desarrollador / CI・CD"] --> HugoBuild["Proceso de construcción de Hugo"]
Markdown["Archivos Markdown"] --> HugoBuild
Templates["Plantillas (HTML)"] --> HugoBuild
HugoBuild --> StaticFiles["Archivos estáticos (HTML/CSS/JS)"]
StaticFiles --> CDN["CDN / Alojamiento estático"]
Req2["Solicitud del usuario"] --> CDN
CDN --> Res2["Devolución de respuesta instantánea"]
end

2. Evaluación del rendimiento mediante modelos matemáticos

Uno de los mayores beneficios de migrar de WordPress a Hugo es la mejora en el rendimiento (velocidad de carga). Para entender esto cuantitativamente, expresémoslo con un modelo matemático simple.

El tiempo hasta que se completa la carga de una página (Load Time: $T_{load}$) se divide principalmente en el tiempo de respuesta del servidor (TTFB: Time To First Byte) y el tiempo de renderizado y obtención de recursos por parte del navegador ($T_{render}$).

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

En el caso de un CMS dinámico (WordPress), $T_{ttfb}$ es la suma de los siguientes elementos: latencia de la red ($T_{network}$), tiempo de ejecución del script del lado del servidor ($T_{php}$) y tiempo de procesamiento de consultas a la base de datos ($T_{db}$).

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

En un estado de accesos concentrados (alta carga), $T_{php}$ y $T_{db}$ aumentan de manera no lineal, y el sistema en su conjunto puede convertirse en un cuello de botella. Expresado en una fórmula, con respecto al número de solicitudes ($N$), se observa el siguiente deterioro en el tiempo de respuesta ($k$ es el coeficiente de sobrecarga de procesamiento).

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

Por otro lado, en una arquitectura que combina un generador de sitios estáticos (Hugo) y una CDN, no existe un procesamiento dinámico del lado del servidor (PHP o consultas DB). Dado que el contenido se almacena en caché en servidores de borde distribuidos por todo el mundo, $T_{ttfb}$ depende puramente de la latencia de la red desde el cliente hasta el servidor de borde más cercano ($T_{edge}$).

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

Con esto, se cumple $T_{edge} \ll (T_{network} + T_{php} + T_{db})$, y el TTFB se reduce drásticamente desde varios cientos de milisegundos a unas pocas decenas de milisegundos. Además, incluso si aumenta el número de solicitudes $N$, el tiempo de respuesta se mantiene casi constante ($O(1)$) debido a la función de equilibrio de carga de los servidores de borde.

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

Esta es la base matemática por la cual Hugo (un sitio estático) es extremadamente robusto contra picos de tráfico (como cuando el contenido se vuelve viral).

3. Estructura básica y principios de funcionamiento de Hugo

Para dominar Hugo, es esencial comprender su estructura de directorios única y los conceptos de “Front Matter” y “Template Lookup Order” (Orden de búsqueda de plantillas).

3.1 Explicación detallada de la estructura de directorios

Cuando creas un nuevo proyecto de Hugo (hugo new site mysite), se genera la siguiente estructura de directorios.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


mysite/
├── archetypes/ # Plantillas al crear nuevo contenido (esqueleto de Front Matter)
├── assets/ # Archivos procesados por Hugo Pipes (SCSS/Sass, JavaScript, etc.)
├── content/ # Contenido real del sitio (archivos Markdown). Esto reemplaza a la DB.
├── data/ # Datos externos y configuración usados en todo el sitio (JSON, TOML, YAML, CSV, etc.)
├── layouts/ # Plantillas HTML que determinan la apariencia del sitio (utiliza Go html/template)
├── public/ # Lugar donde se generan los archivos estáticos después de ejecutar el comando build
├── static/ # Archivos estáticos publicados tal cual (imágenes, favicon, txt para robots, etc.)
├── themes/ # Directorio de temas de terceros o creados por uno mismo
└── hugo.toml # Archivo de configuración global del sitio (anteriormente config.toml era la norma)

En WordPress, el contenido se almacena en la tabla wp_posts de MySQL, pero en Hugo todo se gestiona como archivos de texto (principalmente Markdown) dentro del directorio content/. Esto facilita el control de versiones (Git) del contenido.

3.2 Gestión de contenido: Markdown y Front Matter

Cada archivo de artículo de Hugo tiene un bloque de metadatos llamado “Front Matter” en la parte superior, seguido del texto principal (Markdown). Front Matter se puede escribir en TOML, YAML o JSON, pero YAML es ampliamente utilizado.

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


---
title: "Comprendiendo la taxonomía de Hugo"
date: 2026-09-13T10:00:00+09:00
draft: false
categories:
 - "Explicación técnica"
tags:
 - "Hugo"
 - "Go"
aliases:
 - "/old-category/hugo-taxonomy/"
---
A partir de aquí comienza el texto. Se escribe en **Markdown**.
Explicaremos las potentes funciones de Hugo...

Aquí, un punto a destacar es la clave aliases. Al migrar desde WordPress, si cambian los enlaces permanentes (URL), será una gran desventaja para el SEO. Si usas la función de alias de Hugo, con solo especificar la URL antigua, Hugo generará automáticamente el HTML de redireccionamiento (redirección mediante meta refresh). Es extremadamente útil, ya que no se requiere configuración de redirección en el lado del servidor (como .htaccess).

3.3 Orden de búsqueda de plantillas (Template Lookup Order)

Una de las potentes características de Hugo es su mecanismo flexible de búsqueda de plantillas (Template Lookup Order). Cuando Hugo renderiza una página específica, busca directorios y nombres de archivos en un orden particular para encontrar la mejor plantilla.

Por ejemplo, al renderizar un artículo individual (Single Page) como content/post/hello-world.md, Hugo busca el archivo de diseño aproximadamente en el siguiente orden:

layouts/post/single.html
layouts/post/list.html (no es un error, pero normalmente es para listas)
layouts/_default/single.html
themes/<THEME_NAME>/layouts/post/single.html
themes/<THEME_NAME>/layouts/_default/single.html

Los desarrolladores pueden sobrescribir (override) las plantillas de un tema simplemente creando un archivo con el mismo nombre en el directorio layouts/ de su propio proyecto, sin tener que reescribir directamente el código fuente del tema. Esto permite aplicar personalizaciones propias sin obstaculizar la actualización del tema base.

3.4 Taxonomía (Taxonomy)

En Hugo, el sistema de clasificación equivalente a “Categorías” y “Etiquetas” de WordPress se llama “Taxonomía” (Taxonomy). Hugo admite de forma predeterminada las taxonomías categories y tags, pero editando hugo.toml, puedes agregar libremente taxonomías personalizadas (por ejemplo: series, authors, etc.).

1
2
3
4
5
6


# Ejemplo de hugo.toml
[taxonomies]
 category = "categories"
 tag = "tags"
 series = "series"
 author = "authors"

Esto permite organizar y listar el contenido bajo diversas perspectivas.

4. Proceso de migración de WordPress a Hugo

La clave del éxito al migrar de WordPress a Hugo es cómo convertir el contenido dinámico de la base de datos en archivos estáticos limpios (Markdown + Front Matter) y mantener la estructura de URL existente.

A continuación se muestra el flujo general de la canalización de migración.

flowchart LR
WPDB["Base de datos WP"] -->|Plugin| Exporter["Herramienta de exportación"]
Exporter -->| Extrae texto, \nMetadatos, Imágenes | ZipFile["Archivo Zip / Carpeta"]
ZipFile -->|Unpack| MarkdownFiles["Archivos Markdown \n(content/)"]
ZipFile -->|Unpack| ImageFiles["Imágenes \n(static/wp-content/)"]
MarkdownFiles --> Formatting["Revisión y formato \n(Corregir Shortcodes)"]
Formatting --> Git["Commit a Git"]

4.1 Extracción de datos y conversión a Markdown

Para exportar datos de WordPress a Hugo, usar un plugin dedicado es el método más sencillo y seguro. Presentamos algunos enfoques representativos:

Uso del plugin Jekyll Exporter Como Hugo tiene una estructura de datos muy similar a Jekyll, otro SSG, utilizar el plugin “Jekyll Exporter” para WordPress es una práctica común. Al instalar y ejecutar este plugin, todas las entradas y páginas estáticas se convierten a archivos Markdown con Front Matter y se pueden descargar como un archivo ZIP junto con los archivos de imagen.
Script propio usando la API de WordPress Este método consiste en usar Python, Node.js, etc., para hacer llamadas a la API REST de WordPress (/wp-json/wp/v2/posts), analizar los datos JSON y crear un script para generar archivos Markdown. Es eficaz para sitios que utilizan en gran medida campos personalizados complejos (como ACF) que los plugins no pueden manejar completamente.
Aprovechamiento de la herramienta wp2hugo También hay un enfoque para usar herramientas CLI escritas en lenguajes como Go para convertir directamente desde el archivo XML de exportación de WordPress (WXR) al formato de Hugo.

4.2 Mantenimiento de la estructura de enlaces permanentes (URL)

Para heredar la evaluación de SEO, es extremadamente importante mantener la estructura de URL de la era de WordPress tal como está. Si habías configurado enlaces permanentes en WordPress como https://example.com/2026/09/13/my-post/, debes especificar la estructura de enlaces permanentes en el archivo hugo.toml de Hugo.

1
2


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

Alternativamente, es posible fijar la URL de forma forzada especificando directamente el parámetro url en el Front Matter de cada artículo. Además, para las páginas cuyas URL cambiarán, configuras redirecciones usando los aliases mencionados anteriormente.

4.3 Conversión de Shortcodes (códigos cortos)

Los shortcodes específicos de WordPress (por ejemplo: [gallery], [caption], códigos únicos de varios plugins) a menudo permanecen como cadenas de texto tras la exportación, por lo que es necesario abordarlos. Estos se pueden eliminar por completo mediante scripts de reemplazo (sed o Python) o se pueden migrar utilizando la poderosa función de shortcodes personalizados de Hugo (creando diseños propios en layouts/shortcodes/) para que se rendericen adecuadamente en el lado de Hugo.

5. Herramienta CLI de Hugo y construcción / despliegue

Una vez que se completan las tareas de migración, es hora de usar Hugo para construir el sitio y publicarlo para el mundo. Hugo, que se proporciona como un binario de Go, presume de una velocidad asombrosa, completando la construcción en unos pocos segundos incluso para sitios de miles a decenas de miles de páginas.

5.1 Inicio del servidor de desarrollo local

Cuando escribas artículos o ajustes el diseño, inicia el servidor local.

1
2


# Comando de inicio del servidor de desarrollo (usa -D para incluir borradores)
hugo server -D

Al ejecutar este comando, podrás previsualizar el sitio en http://localhost:1313/. Hugo tiene una poderosa función integrada llamada “LiveReload”; en el momento en que edites y guardes un archivo Markdown, plantilla o CSS, la pantalla del navegador se actualizará automáticamente a alta velocidad. Como resultado, la experiencia de escritura y desarrollo se vuelve mucho más cómoda que el panel de administración de WordPress.

5.2 Construcción para producción y optimización de rendimiento

Para generar archivos estáticos que se desplegarán en un entorno de producción, simplemente escribe hugo.

1
2


# Ejecución de la compilación para producción. Minimiza HTML/CSS/JS con la opción --minify
hugo --minify

Con este comando, los archivos de todo el sitio se generarán en el directorio public/. Al agregar la opción --minify, se eliminan los saltos de línea y espacios innecesarios, lo que reduce aún más el tamaño de los archivos. Esto contribuye directamente a reducir la latencia de la red ($T_{network}$) en el modelo matemático mencionado anteriormente.

5.3 Automatización del despliegue (CI/CD)

Generar archivos estáticos localmente cada vez y subirlos por FTP, etc., es ineficiente. En las operaciones modernas de SSG, la mejor práctica es construir un entorno de CI/CD que realice automáticamente la construcción y el despliegue cuando se desencadena por un push a un repositorio Git (como GitHub).

Por ejemplo, la forma básica de una configuración (archivo YAML) para implementar en Cloudflare Pages o GitHub Pages usando GitHub Actions es la siguiente:

 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


# Ejemplo de .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 # Si los temas se administran como submódulos
 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

Configurándolo de esta manera, se completará un canal de automatización en el que solo con “escribir un artículo en Markdown y hacer Push a GitHub”, el sitio más reciente se publicará en el entorno de producción en unos pocos minutos.

6. Beneficios de SEO y operativos tras la migración

Los administradores de sitios que han completado la migración de WordPress a Hugo a menudo notan los tres siguientes beneficios significativos.

6.1 Mejora drástica de la velocidad del sitio y los Core Web Vitals

Como resultado de eliminar las consultas a la base de datos y la renderización en el servidor, el tiempo de carga de la página se reduce a milisegundos. Esto se traduce directamente en una mejora masiva de las puntuaciones de “Core Web Vitals” (LCP, FID/INP, CLS), que son factores de clasificación de Google. Se puede esperar una reducción en la tasa de rebote de los usuarios y una mejora en la evaluación del SEO.

6.2 Liberación de amenazas de seguridad

Dado que WordPress se usa ampliamente en todo el mundo, siempre es objeto de ataques. Siempre existe el riesgo de manipulación de vulnerabilidades de plugins e intentos de inicio de sesión por ataques de fuerza bruta. Sin embargo, un sitio estático generado por Hugo no tiene base de datos, entorno PHP ni pantalla de administración (formulario de inicio de sesión). No hay espacio para que un hacker ingrese al servidor y reescriba la base de datos, con lo que los riesgos de seguridad se acercan a cero al máximo.

6.3 Operación libre de mantenimiento

La operación de WordPress requiere tareas de mantenimiento continuas, como la actualización del propio núcleo, la actualización de plugins y el seguimiento de las versiones de PHP. Siempre hay que temer el riesgo de que el sitio se rompa debido a problemas de compatibilidad. En el caso de Hugo, solo necesitas actualizar la herramienta en sí cuando sea necesario, y dado que el código del sitio está compuesto de archivos de texto independientes, ofrece la abrumadora tranquilidad de saber que “no se romperá aunque lo dejes desatendido”.

7. Resumen

En este artículo, hemos explicado en detalle la migración de un CMS dinámico como WordPress al poderoso generador de sitios estáticos basado en Go, “Hugo”, abordando desde las diferencias de arquitectura técnica y la demostración matemática del rendimiento hasta los pasos de migración específicos.

Migrar a un generador de sitios estáticos conlleva un costo inicial de aprendizaje (manejo de Git, sintaxis de Markdown, ejecución de comandos CLI en terminales, comprensión del funcionamiento del motor de plantillas), pero los beneficios compensan con creces mediante su “abrumadora velocidad de visualización”, “seguridad sólida” y la característica de ser “libre de mantenimiento”.

Si tu sitio web no requiere cambios de diseño frecuentes ni procesos dinámicos complejos (como funciones exclusivas para miembros o características avanzadas de comercio electrónico) y su propósito es principalmente transmitir información (blogs, medios, sitios corporativos), migrar a Hugo será una de las inversiones técnicas más efectivas. Te animamos a usar este artículo como guía para dar tu primer paso en la operación de un sitio web de próxima generación con Hugo.

Blog técnico escrito en Markdown: Configuración del editor para duplicar la velocidad de escritura

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

Para escribir continuamente un blog técnico, es indispensable optimizar el entorno de escritura. En este artículo, profundizaremos en configuraciones avanzadas del editor para mejorar drásticamente la velocidad de escritura de un blog técnico utilizando Markdown. Explicaremos exhaustivamente desde la personalización extrema de Visual Studio Code (VS Code) y Neovim, el uso de fragmentos (snippets), la introducción de textlint como herramienta de revisión gramatical, la automatización en canalizaciones CI/CD, hasta las técnicas de escritura más vanguardistas utilizando LLM como GitHub Copilot.

1. Modelo matemático para mejorar la velocidad de escritura

Veamos primero con un modelo matemático simple cuánto impacta la optimización de la configuración del editor en el tiempo de escritura. Supongamos que el tiempo total de entrada al escribir un artículo de blog es $T_{total}$.

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

Aquí, $T_{think}$ es el tiempo de pensamiento, $T_{type}$ es el tiempo de escritura (tipeo), $T_{format}$ es el tiempo de ajuste de formato como Markdown, y $T_{review}$ es el tiempo de revisión y corrección.

El tiempo ahorrado $T_{saved}$ mediante la personalización del editor (como la introducción de fragmentos y configuración de Linter) se puede expresar de la siguiente manera, utilizando el número de apariciones $N$ de un patrón específico (por ejemplo, shortcodes de Hugo o tablas de Markdown), el tiempo necesario para la entrada manual $t_{manual}$, y el tiempo necesario para la automatización mediante fragmentos, etc., $t_{snippet}$.

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

Además, al introducir herramientas de formateo automático o de Lint, el tiempo de confirmación visual humano $T_{review}$ se reduce considerablemente. Maximizar este $T_{saved}$ es precisamente el objetivo de este artículo.

2. La configuración definitiva para Visual Studio Code (VS Code)

VS Code es uno de los editores más populares actualmente y cuenta con un ecosistema de extensiones muy potente incluso para la escritura en Markdown.

Extensiones recomendadas

Para acelerar la escritura, se recomienda encarecidamente instalar las siguientes extensiones.

Markdown All in One: Cuenta con todas las funciones básicas necesarias para escribir en Markdown, como poner en negrita o cursiva mediante atajos de teclado, continuación automática de listas y generación automática de la tabla de contenido (TOC).
markdownlint: Advierte en tiempo real sobre errores de sintaxis y violaciones de estilo en Markdown.
vscode-textlint: Aplica un conjunto de reglas orientado a documentos técnicos, previniendo inconsistencias y errores gramaticales.

Configuración de fragmentos personalizados para Hugo (`markdown.json`)

Si estás utilizando generadores de sitios estáticos como Hugo o Docusaurus para tu blog técnico, es probable que ingreses Frontmatter o tus propios shortcodes con frecuencia. Usando la función de fragmentos (snippets) de VS Code, puedes desplegarlos en un instante.

Selecciona Preferences: Configure User Snippets desde la paleta de comandos y agrega la siguiente configuración en 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:Título}\"",
 "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:Categoría}\"]",
 "tags: [\"${4:Etiqueta1}\", \"${5:Etiqueta2}\"]",
 "---",
 "",
 "${0}"
 ],
 "description": "Despliega el YAML Frontmatter para Hugo"
 },
 "Hugo Figure Shortcode": {
 "prefix": "hfig",
 "body": [
 "{{< figure src=\"${1:image.jpg}\" title=\"${2:Título de la imagen}\" >}}"
 ],
 "description": "Shortcode de Figure de 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": "Genera una tabla Markdown de 3 columnas"
 }
}

Con esta configuración, con solo escribir frontmatter y presionar la tecla Tabulador, el YAML Frontmatter que incluye la hora actual se desplegará instantáneamente, aumentando drásticamente la velocidad inicial de escritura.

Asistencia de escritura con GitHub Copilot

Cuando habilitas GitHub Copilot en VS Code, la autocompletación de IA sensible al contexto también funciona en Markdown. Especialmente en el caso de blogs técnicos, la IA predice y propone “la siguiente estructura a explicar” o “bloques de código relacionados”, lo que permite reducir significativamente el tiempo de escritura $T_{type}$.

3. Personalización extrema en Neovim

Aunque la interfaz gráfica (GUI) de VS Code es excelente, para los entusiastas de la terminal y los usuarios de Vim, Neovim es la opción más poderosa, ya que permite hacer todo sin soltar las manos del teclado.

Arquitectura LSP de Neovim

La arquitectura de LSP (Language Server Protocol) y Linter de Neovim en un entorno Markdown es la siguiente.

classDiagram
class Neovim {
+"Búfer de texto"
+"Mapas de teclado"
}
class nvim_lspconfig {
+"marksman (LSP para Markdown)"
}
class null_ls_or_none_ls {
+"markdownlint"
+"textlint"
}
class LuaSnip {
+"Fragmentos dinámicos"
}
class CMP {
+"Motor de autocompletado"
}
Neovim --> nvim_lspconfig : "Proporciona funciones semánticas"
Neovim --> null_ls_or_none_ls : "Diagnósticos y formato"
Neovim --> CMP : "Solicitud de autocompletado"
CMP --> nvim_lspconfig : "Fuente LSP"
CMP --> LuaSnip : "Fuente de fragmentos"

Despliegue avanzado de fragmentos usando LuaSnip

Más potente que los fragmentos JSON de VS Code es el plugin para Neovim LuaSnip. Utilizando la lógica de Lua, permite calcular y desplegar dinámicamente el contenido de los fragmentos.

A continuación se muestra un ejemplo de configuración de LuaSnip que obtiene la fecha y hora actuales dinámicamente y despliega el Frontmatter de 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

-- Función para obtener la hora actual 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, "Título"), 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, "Categoría"), t({"\"]", "tags: [\""}), i(4, "Etiqueta"), t({"\"]", "---", "", ""}),
 i(0)
 }),
 s("mtable", {
 t({"| "}), i(1, "Encabezado 1"), t({" | "}), i(2, "Encabezado 2"), t({" |", "|---|---|", "| "}), i(3, "Celda 1"), t({" | "}), i(4, "Celda 2"), t({" |"}),
 })
})

De esta manera, aprovechando el poder del lenguaje de programación (Lua), es posible crear fragmentos asombrosos que no solo contienen cadenas fijas, sino que también incrustan los valores de retorno de funciones, o aumentan y disminuyen dinámicamente el número de columnas de una tabla según la cantidad de caracteres ingresados.

4. Análisis estático para equilibrar calidad y velocidad de escritura (textlint y expresiones regulares)

Para asegurar la calidad del blog, es necesario prevenir errores tipográficos e inconsistencias. Si esto se hace manualmente, $T_{review}$ aumentaría de manera explosiva, por lo que introduciremos el análisis estático usando textlint.

Introducción a textlint y el conjunto de reglas para japonés

Instalaremos textlint en un entorno de Node.js.

1

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

Crea un archivo .textlintrc.json en la raíz del proyecto y configúralo de la siguiente manera.

 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"]
 }
 }
}

Crea prh.yml y define la inconsistencia de los términos técnicos. Por ejemplo, unifica “サーバー” (servidor) y “サーバ”, o “Javascript” y “JavaScript”.

1
2
3
4
5
6
7
8


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

Gracias a esto, cada vez que escribas en el editor, se te advertirá en tiempo real sobre las inconsistencias en la escritura, reduciendo el tiempo de corrección a casi cero.

Patrones estructurados y reemplazo masivo utilizando expresiones regulares

Cuando migras artículos existentes a Markdown o traes texto de fuentes externas, el reemplazo masivo usando expresiones regulares resulta muy útil.

Por ejemplo, la expresión regular para convertir la etiqueta HTML énfasis a **énfasis** en Markdown:

Patrón de búsqueda: (.*?)
Patrón de reemplazo: **$1**

Para combinar saltos de línea consecutivos innecesarios en uno solo:

Patrón de búsqueda: \n{3,}
Patrón de reemplazo: \n\n

Al ejecutar esto con la función de búsqueda y reemplazo de VS Code (modo de expresiones regulares) o el comando %s de Neovim (:%s/$.*?$<\/b>/**\1**/g), puedes unificar el formato al instante.

Comprobación automática mediante el canal (pipeline) CI/CD

Además, usando GitHub Actions, puedes construir una canalización CI que ejecute automáticamente textlint cuando subas (push) artículos al blog. Esto evita proactivamente el despliegue de artículos que infrinjan las reglas.

flowchart TD
A["Autor"] -->|Empujar cambios| B["Repositorio de GitHub"]
B --> C{"GitHub Actions Activado"}
C --> D["Checkout del repositorio"]
D --> E["Configurar Node.js"]
E --> F["npm install"]
F --> G["Ejecutar textlint"]
G -->|Éxito| H["Construir sitio Hugo"]
G -->|Fallo| I["Informar error al PR/Commit"]
H --> J["Desplegar en Hosting (Vercel/Netlify)"]

5. Técnicas de escritura en Markdown en la era de los LLM

En la redacción moderna de blogs técnicos, el uso de LLM (Grandes Modelos de Lenguaje) es inevitable. Al aprovechar las herramientas de IA integradas en el editor, la velocidad de escritura se duplica aún más.

Ingeniería de prompts dentro del editor

Usando GitHub Copilot Chat en VS Code, o plugins como ChatGPT.nvim o Copilot.vim en Neovim, puedes lanzar prompts como los siguientes sin salir del editor.

“Crea un esquema en estructura jerárquica de Markdown para principiantes sobre los siguientes elementos técnicos: Docker, Kubernetes, CI/CD”

De este modo, se generarán instantáneamente los encabezados y listas en Markdown. Solo tenemos que desarrollar y añadir contenido a esa estructura.

Además, al darle instrucciones a la IA, también puede generar una sintaxis precisa para diagramas complejos de Mermaid y fórmulas matemáticas (LaTeX). Por ejemplo, la base de las fórmulas matemáticas y los diseños de diagramas de este artículo también se aceleró gracias a la escritura colaborativa (pair writing) con un LLM.

6. Conclusión

En este artículo explicamos configuraciones del editor que duplicarán tu velocidad de escritura al crear un blog técnico en Markdown.

Conciencia del modelo matemático: Erradicar el trabajo repetitivo para maximizar $T_{saved}$.
Aprovechar VS Code: Omitir la entrada manual utilizando extensiones y fragmentos en markdown.json.
Personalización extrema de Neovim: Fragmentos dinámicos a través de LuaSnip y control total mediante el teclado.
textlint y análisis estático: Integración de CI/CD y Linters locales para acercar el tiempo de revisión a cero.
Integración de LLM: Hacer que la IA genere directamente la estructura del Markdown y el código de diagramas o tablas dentro del editor.

Al incorporar estas configuraciones a tu propio entorno, desaparecerá lo “tedioso” de la escritura y, con seguridad, la cantidad y calidad de tus publicaciones técnicas mejorarán drásticamente. ¿Por qué no empezar hoy mismo registrando al menos un pequeño fragmento (snippet)?