Relanzando un blog en 2022

Sé que he hecho otros blogs en el pasado. Prometo mantener este, palabrita. (Yo, 2020)

Sé que mucha gente no va a leer mi blog más allá de los pobres desgraciados que caigan en el engaño del buscador de Google, pero bueno... Aquí estamos 😃

Esta vez he abandonado Notion (que fue la última herramienta que utilicé antes de rehacer mi web personal) y me moví a... Zola. Fácil de montar algo rápido, con soporte de Markdown y básicamente listo para generar una build que puedo desplegar en mi entorno. ¿Para qué más? Total, ya no uso servicios de Google, no necesito JavaScript aquí y cuando tenga tiempo podré meterle estilos a esto.

"Pero Cristo, pesado, ¿por qué te sigues negando a usar herramientas existentes y reinventas la rueda?"

Resumo en plan rápido:

• Evito ceder mis datos en la mayor medida de lo posible
• La mayor parte de las "herramientas" que existen crean más problemas en lugar de solucionar necesidades reales
• Aprendo más montando mis cosas que simplemente usando lo que decida el mainstream
• Me siento más feliz desde que llevo esta vida (y eso que tengo menos tiempo que antes... si llego a tenerlo ya tendría un sistema de la hostia)

Así, para dejar un poco claro cómo es mi vida tecnológica ahora mismo, les dejo este pequeño resumen:

• No uso NINGÚN servicio de Google de manera directa en mis equipos (salvo las inevitables cosas del trabajo / smart TV / servicios de Google en Android que no puedo dejar de usar por factores externos)
• Uso mi propia Arch ISO, abandonando Windows para 1 o 2 juegos
• Uso herramientas hechas en Rust (LeftWM, TUI, Neovide, una buena parte de los core-utils de GNU las he reemplazado por reimplementaciones hechas en Rust)
• Tengo mis redes sociales, pero están en abandono permanente (solo las abro si tengo algún mensaje que leer, porque no puedo evitar que las 2 o 3 personas que siguen en contacto conmigo lo hagan por allí)
• Mis teléfonos están prácticamente libres (o sea, no GApps, no Play Services, no sustitutos de Amazon/MS)
• Uso Neovim (con Neovide cuando se puede) para programar. Simplemente se nota la diferencia en relación a VS Code y la cantidad de distracciones que genera (NOTA: en el curro uso CODE OSS ya que todavía no me sé de memoria todos los atajos de Nvim 🙃)
• Y básicamente todos estos cambios se han traducido en que puedo enfocarme mucho más en el trabajo que hago, las tareas que debo hacer en un día, las prioridades REALES cuando tengo notificaciones en el teléfono/ordenador, y que he aprendido muchísimas cosas nuevas (y mira que yo hace unos años era del team EMACS... quién me ha visto y quién me ve)

La razón del blog

Últimamente me doy cuenta de que si paro en alguna tarea, y la tengo que retomar dentro de un tiempo, cuando llega la hora he olvidado algún comando, un paso, alguna dependencia, etc., necesaria para continuar. Así que esta vez el blog será enfocado en tomar notas y apuntes para aquellas cosas que son más o menos complejillas (y ojo, seguiré escribiendo chorradas en algún momento que otro, prometo no dar tanto la turra con eso).

Dicho esto, espero que no tenga que meterle muchas horas más a configurar un nuevo sustituto de un servicio "X", que a día de hoy ya parece que todo mi entorno digital parece muy estable.

Por qué Zola y no otra cosa

Antes de decidirme por Zola, probé varias alternativas. Hugo es rapidísimo (también está escrito en Go), pero su sistema de templates me parece críptico. Jekyll necesita Ruby y un ecosistema de gems que siempre acababa dando problemas. 11ty es genial pero necesitas Node.js y un montón de configuración para algo que debería ser simple.

Zola, en cambio, es un solo binario. Lo descargas, lo ejecutas, y ya. Además, usa el motor de templates Tera (inspirado en Jinja2/Django), que me resultó familiar después de años usando Python.

# Instalar Zola en Arch
sudo pacman -S zola

# Crear un nuevo proyecto
zola init mi-blog
cd mi-blog

# Escribir contenido en content/blog/
# Configurar en config.toml

# Build y serve local
zola serve  # http://localhost:1111

# Build para producción
zola build  # -> public/

El timepo de build es ridículo. Mi site entero (unas 50 páginas en ese momento) se genera en 47ms. Para contexto, mi antiguo blog en Jekyll tardaba unos 12 segundos. La diferencia es abismal.

La pila técnica completa

Aquí está todo lo que uso para que este blog funcione:

Editor: Neovim + Neovide
Static generator: Zola (Rust)
Theme: Solanda (tema personalizado)
Hosting: Servidor propio (Nginx en Docker)
Despliegue: rsync + script bash
Comentarios: No existen (email/Mastodon)
Analytics: No existen (ngo log)
CDN: Cloudflare (solo DNS, no proxy)
SSL: Let's Encrypt via acme.sh

No hay JavaScript en el frontend. No hay trackers. No hay cookies. No hay GDPR banner (no hago Tracking, no necesito consentimiento). La página carga en menos de un segundo incluso en conexiones lentas.

Y lo mejor: si Zola desapareciera mañana, me llevo los archivos Markdown a cualquier otro generador y sigo exactamente donde lo dejé. Sin vendor lock-in, sin migraciones dolorosas, sin perder 15 años de contenido.

Lo que he aprendido gestionando mi propio blog

Sobre el contenido

Escribir para ti mismo es muy diferente a escribir para una audiencia. Cuando este blog era solo un repositorio de notas técnicas, escribía de forma más natural, sin preocuparme por si sonaba demasiado técnico o demasiado simple. Ahora que sé que hay gente leyendo (aunque sean 4 gatos), me cuesta más sentarme a escribir.

La solución ha sido tratar el blog como lo que es: mi cuaderno de notas público. Si alguien encuentra útil lo que escribo, genial. Si no, al menos yo tengo mis apuntes organizados.

Sobre el diseño

El tema minimalista no es solo una decisión estética, es funcional. Sin JavaScript, sin fuentes personalizadas (uso las del sistema), sin imágenes pesadas. El CSS completo del site pesa menos que un solo banner de cookies de cualquier site moderno.

/* Prácticamente todo el CSS que necesito */
body {
    max-width: 720px;
    margin: 0 auto;
    padding: 1rem;
    font-family: system-ui, sans-serif;
    line-height: 1.6;
}

Eso es más o menos el 80% del diseño. El resto son detalles menores. No necesito un framework CSS para mostrar texto en una pantalla.

La migración desde Notion: una odisea de 3 tardes

Salir de Notion no fue bonito. Tenía unas 40 páginas entre apuntes técnicos, borradores de posts, listas de tareas y documentación de proyectos. Exportar desde Notion te da Markdown, sí, pero el Markdown de Notion es... creativo. Los bloques de código llegan sin formato consistente, las imágenes son enlaces rotos a su CDN, y las tablas son una mezcla de HTML y Markdown que ningún parser entiende.

Tuve que escribir un script en Python para limpiarlo todo:

import re

def clean_notion_markdown(text):
    # Quitar spans vacíos que Notion deja
    text = re.sub(r'<span[^>]*></span>', '', text)
    # Convertir sus tablas a algo legible
    text = re.sub(r'<table>.*?</table>', '[tabla omitida, ver PDF original]', text, flags=re.DOTALL)
    # Normalizar bloques de código
    text = re.sub(r'```\s*\n', '```\n', text)
    return text

No es bonito, pero funcionó. Perdí las imágenes (las fui subiendo una a una a mi servidor), y las tablas las dejé como nota. El contenido importante, los apuntes técnicos y los tutoriales, quedaron perfectos en Markdown puro.

Por qué LeftWM y no i3/bspwm/Hyprland

He probado todos los window managers. Literalmente todos. i3 fue mi primer amor, bspwm me duró un par de años, y Hyprland lo tuve instalado unos meses. Pero LeftWM es el que se ha quedado.

LeftWM no tiene una barra integrada, no tiene un sistema de configuración con syntax específica, no tiene atajos por defecto. Es un gestor de ventanas que hace una cosa: gestionar ventanas. Punto. La barra, los atajos, los temas... todo eso va aparte.

Esto, que parece una desventaja, es exactamente lo que quiero. Puedo usar polybar, eww, o simplemente no tener barra. Puedo configurar atajos con sxhkd (el mismo que usa bspwm), y los temas se definen en Rust (se compilan como parte del binario).

# En LeftWM, los temas van en ~/.config/leftwm/themes/
# Y se compilan como parte del binario de LeftWM
leftwm check  # Verificar que el tema no tiene errores
leftwm theme next  # Cambiar de tema en caliente

¿El resultado? Un escritorio que responde en milisegundos, que no se interpone en mi flujo de trabajo, y que puedo configurar exactamente como quiero sin tener que aprender un lenguaje de configuración nuevo.

El meta-aprendizaje: programar un blog te enseña más que usar uno

Algo que no esperaba cuando empecé este blog era cuánto iba a aprender sobre tecnologías que no tocaba en mi trabajo diario. Al montar mi propio stack:

• Aprendí Zola y Tera templates (Rust) cuando en el curro usaba Django
• Aprendí los entresijos de Nginx para servir contenido estático correctamente
• Aprendí a optimizar builds de CI/CD para que fueran rápidos y fiables
• Aprendí sobre SEO técnico (sitemaps, meta tags, Open Graph) porque no tenía un plugin que lo hiciera por mí
• Aprendí a configurar Let's Encrypt con acme.sh y renovación automática

Cada vez que quería añadir una funcionalidad al blog, tenía que implementarla yo mismo. Eso me obligaba a entender cómo funciona realmente, no solo a instalar un plugin y olvidarme. Y ese conocimiento se queda contigo para siempre.

Por ejemplo, cuando quise añadir RSS, no instalé un generador de RSS. Zola ya lo genera automáticamente. Pero cuando quise personalizar el feed, tuve que entender cómo funcionan los templates Tera, cómo Zola estructura los datos de las páginas, y cómo se serializa el XML. Ahora sé exactamente qué información aparece en mi RSS y por qué.

El despliegue: de Git a producción en segundos

El flujo de publicación es sencillo pero efectivo:

1. Escribo en Neovim, en mi máquina local
2. git push al repositorio en GitLab
3. GitLab CI ejecuta Zola build
4. Un script rsync sube el contenido al servidor
5. Nginx sirve los archivos estáticos

# .gitlab-ci.yml
pages:
  stage: deploy
  script:
    - cd web && zola build
    - rsync -avz --delete web/public/ user@server:/var/www/blog/
  only:
    - main

Todo el proceso, desde que hago push hasta que el cambio está vivo, tarda unos 10 segundos. Sin deploy hooks complejos, sin contenedores intermediarios, sin servicios externos.

Sobre el mantenimiento

Un blog estático no se mantiene solo. De vez en cuando tengo que:

1. Actualizar Zola (suele ser pacman -Syu y ya)
2. Revisar que los enlaces sigan funcionando (uso zola check)
3. Actualizar el theme si he hecho cambios locales
4. Renovar SSL (automatizado con acme.sh)
5. Comprobar que el servidor sigue vivo

Pero comparado con mantener un WordPress (actualizar core, plugins, themes, base de datos...), esto es prácticamente cero mantenimiento.

Y entonces, ¿qué planes hay?

Este blog va a ser mi cuaderno de bitácora técnico. Voy a escribir sobre:

• Self-hosting y por qué merece la pena (y por qué a veces no)
• Linux, Arch, y cómo sobrevivir a una actualización que rompe todo
• Docker, contenedores, y cómo no volverte loco con las redes
• Rust, Go, Python, y mis opiniones no solicitadas sobre cada uno
• La vida como ingeniero español en Noruega (spoiler: hace frío)

Y probablemente también alguna chorrada sobre videojuegos, series, o lo que me dé la gana. Al fin y al cabo, es mi blog.

Una cosa más: he aprendido que un blog no tiene que ser perfecto para ser útil. Este post, por ejemplo, lo he ido escribiendo en ratos libres durante una semana. A veces un párrafo entre reuniones, a veces una sección entera un sábado por la mañana. No esperes publicación semanal ni contenido curado — esto es un cuaderno de notas público, no una revista digital. Y creo que esa honestidad es lo que hace que un blog personal merezca la pena frente a los feeds algorítmicos de las redes sociales.

Saludos!