Caso de estudio: Mi blog de marca personal
En general, un tutorial explica cómo hacer las cosas. A mí me gusta, además, contar por qué las hago, qué motiva mis decisiones. Este artículo es la introducción a una serie en la que explico cómo he creado y desplegado mi blog personal utilizando tecnologías modernas como Astro, TypeScript, y GitHub Pages. Aquí te cuento los objetivos que tengo para este blog y por qué he tomado cada decisión tecnológica.
¿Qué objetivo tengo con este blog?
Toda decisión tecnológica tiene que estar alineada. Por eso la primera pregunta que me hago es acerca del objetivo que busco.
En general, cuando creamos un blog personal, lo hacemos para compartir conocimientos, experiencias y reflexiones. Si el blog lo creamos para generar marca (como es el caso), entonces compartiremos conocimientos, experiencias y reflexiones sobre los temas que creemos que definen la marca.
En mi caso, estos temas son el desarrollo de software en general, el desarrollo de software seguro y la gestión de proyectos de desarrollo seguro. Además, también intento hablar de “egoísmo técnico”. Y justo este último punto es el que más peso tiene a la hora de elegir mi objetivo.
No he mantenido un blog en mis 20 años de carrera porque siempre he estado demasiado ocupado trabajando. Querer conseguir y hacer más con menos es lo que dio origen a esta filosofía (el “egoísmo técnico).
Por eso, mi objetivo es crear un blog que “no tenga que gestionar” y que pueda ampliar con funcionalidades con facilidad.
Para ello, tomo las siguientes decisiones:
1. Gestionar la creación de contenidos desde Obsidian
Obsidian es la base de mi “segundo cerebro”. Todo lo que escribo y documento acaba ahí, así que también es el lugar donde suelo generar los artículos que pueden acabar en este blog. Obsidian funciona en base a archivos MarkDown y esto influirá muchas de mis decisiones.
Por otro lado, admite el uso de enlaces simbólicos (o “accesos directos” si eres usuario de Microsoft) por lo que puedo gestionar contenido desde Obsidian que esté en una carpeta fuera de la estructura de carpetas del mismo.
2. Desarrollar usando Astro como base
Astro es un framework relativamente nuevo que se enfoca en generar sitios web estáticos, pero con la capacidad de incluir componentes interactivos solo donde realmente se necesitan. Además, tiene su foco en la optimización del rendimiento. Astro genera HTML estático por defecto y solo carga JavaScript en el navegador cuando es absolutamente necesario.
Existen otros frameworks que permiten generar HTML estático con JavaScript cargado según es necesario, pero en la medida en la que los voy probando, les encuentro pegas (y si hablo de ello, lo haré en otro post). No es que no los vaya a utilizar sino que, simplemente, Astro me ofrece una base agnóstica al resto de frameworks.
Por un lado, se orienta a la generación de HTML estático es ideal para un blog, puesto que la mayor parte del contenido es estático.
Por otro, Astro me permite trabajar con múltiples frameworks de componentes como React, Vue o Svelte, lo que me ofrece flexibilidad para futuras expansiones o experimentos.
Mi motivo estrella: Astro funciona de serie con archivos MarkDown (y con una pequeña configuración también admite MDX) por lo que es ideal para usarlo con Obsidian de manera integrada.
3. Desarrollar usando TypeScript
TypeScript es un superset de JavaScript que añade tipado estático al lenguaje. A estas alturas de la película, TypeScript tiene gente a favor y en contra. Y no hablo de gente como yo, sino de titanes del desarrollo que han utilizado TypeScript en entornos exigentes y competitivos. Esto da para otro post… o para toda una recopilación de posts de razonamientos en un sentido o en otro.
Para mí, el principal motivo para elegir TypeScript es que tiene tipado estático, con lo que puedo detectar errores antes de ejecutar el código, lo que reduce significativamente los bugs y de tests necesarios para detectarlos y aumenta la mantenibilidad del proyecto.
Además,la claridad que aporta (EMHO) a través de sus tipos y anotaciones hace que el código sea más legible y fácil de entender, tanto para mí como para cualquier otra persona que pueda contribuir en el futuro.
Por otro lado, la complejidad de tener que buscar el tipo adecuado o de crearlo en caso necesario, está más que compensado con el hecho de poder detectar muchos más fallos en tiempo de transpilación. Y esto me ayuda a dormir muy tranquilo con proyectos que puedan estar en manos de desarrolladores juniors.
En un proyecto como este blog, que es susceptible de convertirse en una plantilla de proyecto, considero que TypeScript es clave para facilitar los desarrollos futuros que no dependan de mí.
4. Guardar el código generador en un repo privado
Seguramente crearé una plantilla de blog para Astro a partir de este blog. Esa plantilla será pública (obviamente) para que cualquiera pueda utilizarla.
Sin embargo, este blog probablemente crezca más allá de lo que dicha plantilla llegue a ofrecer y, aunque puedan influirse (bien adaptando a este blog una funcionalidad futura de la plantilla o al revés), las diferencias de este blog con la plantilla serán de uso privativo.
Al trabajar con un repositorio privado, puedo controlar quién tiene acceso al código y evitar exponer detalles sensibles al público.
Además, mantener el código fuente en un repositorio privado me permite experimentar y probar nuevas funcionalidades sin preocuparme de que código inacabado o experimental se haga público. Esto me da la libertad de iterar rápidamente y asegurarme de que el código que finalmente despliego sea de la más alta calidad.
5. Publicar la web en GitHub Pages
GitHub Pages es una plataforma gratuita y altamente confiable para alojar sitios web estáticos directamente desde un repositorio GitHub. La elección de GitHub Pages para este proyecto es sencilla: es fácil de configurar (dominio personalizado con HTTPS incluido), se integra perfectamente con el flujo de trabajo de GitHub y ofrece un tiempo de actividad excelente y, lo más importante, no necesito mantenerla.
Otra razón clave es la simplicidad que ofrece en el despliegue. Con GitHub Actions, puedo automatizar completamente el proceso de construcción y despliegue de la web desde mi repo privado a un repo público con solo los archivos estáticos finales, lo que me permite concentrarme en el desarrollo y en el contenido, sin preocuparme por la infraestructura.
Está claro que podría haber usado otras plataformas pero, como decía al principio, busco más con menos, así que no quiero plataformas que requieran de un mantenimiento constante, o servidores que requieran de mi atención.
Con este stack puedo centrarme en experimentar, aprender y demostrar lo que ya sé. Puedo ser creativo de una manera que otros stacks no me lo permiten.
Además, la mayor parte de lo que escriba en este blog lo republicaré en plataformas (en español en LinkedIn y en inglés en Medium) por lo que no espero que haya demasiado tráfico más allá de allegados y curiosos.
Este artículo es el punto de partida no tanto para entender cómo construir un blog moderno, sino por qué he tomado determinadas decisiones tecnológicas por lo que te invito a contactarme tanto si tienes dudas como opiniones similares, complementarias o contrarias.