Cómo y por qué hice notas.mnsosa.com
Mi antiguo blog
Es viernes 20 de marzo en Córdoba y la Raspberry Pi 5 no bootea. Seguro murió la memoria SD. Nada dramático, pero me obliga a repasar mentalmente qué cosas estaban ahí, qué vale la pena re-deployar en otro lado y qué no. Entre esas cosas había varias páginas estáticas, incluido mi antiguo blog.
La verdad es que no voy a extrañar a mi antiguo blog. Qué suerte que su destino lo haya decidido una memoria de mala calidad.
Por si no se dieron cuenta, el blog era una bosta. Intentaba ser técnico, pero no era especialmente útil ni especialmente lindo. Se sentía rígido. Como si todo lo que publicara tuviera que caer en formato tutorial, como si esto fuera Medium, o como si solo valiera la pena escribir cuando había algo totalmente armado.
Y yo no quería eso. Quería tener la libertad de escribir sobre cualquier cosa, tal cual hago en mis doscientas libretitas que uso día a día. Esto son ideas sueltas, notas cortas, cosas que pienso durante el día, pequeños textos que me ayudan a ordenar la cabeza. No necesariamente tutoriales. No necesariamente contenido “útil”. Solo notas.
Eso además encaja bastante conmigo, porque a mí me encanta hacer notas. To-do lists diarias, textos breves, borradores, pensamientos medio crudos que muchas veces terminan perdidos en Notion o en archivos .txt locales (sí, bien rústico).
Ahora que tengo una PC nueva, también tengo txts nuevos. Pero esta vez quiero ordenarlos mejor.
En esta PC dejé de usar la app de Notas default de GNOME y empecé a usar Obsidian. No soy fan, pero me sirve. Al final no deja de ser un visualizador fancy de archivos markdown simples, y para este flujo alcanza. Me resulta más cómodo para escribir, ordenar y previsualizar sin tener que abrir VSCode para tocar un .md.
Ya casi ni vale la pena abrir VSCode para programar.
Qué tenía que cumplir el sistema
Si iba a armar un lugar para publicar notas, no quería repetir el mismo problema con otra estética. No se trataba solo de tener un sitio más lindo, sino de que el sistema acompañara mejor mi forma real de escribir.
Había algunas cosas que para mí eran importantes desde el principio.
Primero, seguir escribiendo en local. No quería depender de una plataforma externa ni de un editor web. Mis notas ya viven en archivos markdown dentro de mi máquina, y quería que eso siguiera siendo así. La web tenía que salir de ahí, no al revés.
Segundo, separar con claridad qué es privado y qué es público. Mi vault tiene de todo: notas sueltas, borradores, textos personales, listas, cosas incompletas. No quería ni por casualidad exponer todo eso. El sistema tenía que obligarme a hacer explícito qué cosas se publican y cuáles no.
También quería mantener el contenido como texto simple, sin formatos raros ni herramientas que me encierren demasiado. Markdown, archivos comunes, carpetas normales. Si algún día quiero mover todo a otro lado, debería poder hacerlo sin tener que pelearme con una exportación extraña.
Otra condición era poder previsualizar el resultado antes de publicar. Me gusta escribir y después revisar cómo queda. Ver los links, las imágenes, la estructura general. No quería hacer push a ciegas y enterarme después de que algo salió mal.
Además, buscaba un flujo de publicación lo bastante simple como para no frenarme. Si subir una nota implica demasiados pasos, demasiado miedo o demasiada ceremonia, al final termino no publicando nada. Necesitaba algo liviano: sincronizar, mirar, push y listo.
Y por último, quería que todo esto fuera más o menos seguro por defecto. No seguridad en un sentido épico, sino algo bastante más terrenal: reducir la chance de publicar por error una nota privada, dejar contenido viejo colgado, o romper el sitio por un descuido tonto.
Con esas ideas en mente, el sistema terminó tomando una forma bastante simple: escribir en el vault local, definir una carpeta pública explícita, sincronizarla al sitio y dejar que Quartz haga el resto.
¿Por qué Quartz? ¿No podías vibe-codear una web para levantar el blog?
La verdad es que sí, y de hecho ya lo hice antes, pero esta vez quería menos fricciones. Elijo Quartz como herramienta que me sirve mis archivos markdown, y listo. Es editable fácilmente si algo estético no me gusta, y me proporciona otros detalles que no se me hubieran ocurrido como requisitos del sistema. Lo importante es que haya poca fricción en todo el flujo.
Quiero tan poca fricción que hasta necesitaba que sea serverless y automático tan solo pusheando a Github. No quiero depender de ninguna COSA local, ni de mi Mac Mini, ni de mi PC secundaria que tengo ahí que consume como drogadicto de Los Ángeles, ni de la Raspi que para que ande de una forma más confiable tengo que comprarle un adaptador SSD M.2 y un disco SSD M.2, y tengo CERO ganas de gastar en eso para hostear este tipo de cosas. Esto es FRICCIÓN que quiero EVITAR.
Cómo fue el proceso de implementación
Antes de tocar código, hice algo que me viene resultando bastante bien: bajar primero el problema a especificaciones razonables.
En este caso conversé un rato con ChatGPT para ordenar qué tenía que cumplir el sistema y convertir eso en un spec más o menos claro. La idea no era pedirle “haceme un blog”, sino usarlo para refinar restricciones, detectar decisiones medio obvias que igual conviene explicitar, y llegar a una prompt que sirviera de base para implementar.
Con eso armado se lo pasé a OpenCode, que tengo bastante boosteado con MCPs y otras herramientas, incluyendo Chrome para revisar más fácil el resultado en navegador y iterar sobre la parte visual o de interacción cuando hace falta.
OpenCode me ayudó sobre todo a acelerar la parte más mecánica de bajar ese spec a una primera versión funcional. Yo, en cambio, me quedé con la parte que igual quería tener bastante controlada: el repo en GitHub, la organización general del proyecto y el deploy automático en Cloudflare Pages.
Ahí también ayudó que hoy Cloudflare Pages tenga la experiencia bastante más amigable que antes. Incluso agregaron features con IA en su web, así que conectar el repo, validar la configuración base del build y dejar andando el deploy automático fue bastante directo.
Cómo se usa en la práctica
En el día a día, el flujo me quedó más o menos así: escribo en Obsidian, muevo a Publish/ lo que quiero hacer público (con un comando nomás), sincronizo esa carpeta con el sitio, reviso el resultado localmente y recién ahí publico.
Eso era importante para mí porque mantiene dos cosas a la vez: la comodidad de escribir como siempre escribí, y una separación bastante explícita entre nota privada y nota pública.
También me gusta que el deploy no dependa de tener nada prendido en mi máquina. No hay servidor casero, no hay inventos raros corriendo en la Raspberry de turno. Hay archivos markdown, un generador estático, GitHub y Cloudflare Pages. Bastante más aburrido, y justamente por eso bastante mejor.