Por comodidad intento que tengan todas la estructura más similar posible, que usen todas las mismas tecnologías, que estén alojadas en el mismo sitio y que tengan un flujo de desarrollo lo más similar posible.

Hacer esto te evita un montón de problemas, y agiliza tu desarrollo bastante.

Todos estos proyectos están corriendo en instancias de Google Cloud Platform.
Son SPAs en Vue, proyectos Nuxt o custom JS.

Todos tienen un nginx delante para gestionar las URLS, un certbot para el SSL. (así por seguridad se pueden visitar las webs bajo https), algunas tienen sistema de login privado o tracking de visitas... Nada exótico.

La mayoría incluso usa el mismo framework que he montado para construir la UI CSS Bedrock\ o bloques más elaborados construidos a partir de Bedrock y que alojo en el proyecto que llamo Plantillas

Te animo a que le eches un vistazo a Bedrock y abraces las convenciones de tener una sola manera de hacer las cosas.

Tener este flujo de desarrollo tan similar tiene innumerables ventajas, cierto que es que acotas tu margen de posibilidades al reducir tu stack de tecnología pero ganas muchísimo al mantener solo un tipo de código y un flujo de trabajo, depuras los errores más facilmente, sabes siempre qué esta pasando, puedes saltar de un proyecto a otro sin cambiar de mapa mental y sobre todo puedes automatizar algunas partes de la gestión del proyecto con un poco de cuidado.

La dolorosa vuelta a Windows.

Hace un año que volví a Windows por temas de presupuesto para mi trabajo del día a día, ahora que no trabajo profesionalmente en estos proyectos, la inversión en máquinas mac se me hacía un poco cuesta arriba y por cuestiones de ahorro y versatilidad me pasé a windows de nuevo.

He desarrollado siempre mi trabajo en mac y linux y no voy a negar que la vuelta al entorno Windows ha sido un poco difícil, para mí acostumbrado a la maravilla de un terminal que funcionaba de verdad, volver a windows ha sido un camino lleno de altibajos.

El problema por ejemplo de desplegar cualquier cosa desde Windows, aprender todos los comandos y la nueva sintaxis ha sido duro (no me escondo...)

Incluso los proyectos pequeños necesitan de un montón de pasos: construir el proyecto, copiar los ficheros al servidor, recargar nginx, gestionar los certificados... en un primer momento todo de manera manual, luego usando scripts para agilizar que vas guardando entre proyectos y tienes que perder un rato editando cada vez que cambias de proyecto y al final acumulas un montón de scripts que no sabes luego ni donde los guardaste.

El camino de los golpes.

La primera vez que montas un proyecto con subida al servidor, tardas una tarde.

La segunda vez un poquito menos pero no recuerdas bien el orden de montaje y tropiezas, buscas y copias código del otro proyecto, falla y te desesperas.

La tercera vez te escribes un script para evitar tropiezos y automatizas alguna parte del flujo del proyecto, sabes que esos scripts se van a perder en alguna carpeta.

Here we go, again.

Hasta que empiezas a entender que lo que necesitas es una herramienta que te ayude a gestionar todo esto.

Si las cosas están en un solo lugar, solo se pueden romper una vez.

Sueñas con que tenga un botón bien gordo que accione toda la magia y lo haga todo de una vez. Y te emocionas al pensar que vas a hacer con todo ese tiempo que has ganado... (spoiler: hacer más herramientas y más proyectos).

Y así es más o menos como acabas montando algo como Lanzadera: un módulo PowerShell que convierte todos tus problemas a la hora de montar y desplegar un proyecto en dos o tres comandos reproducibles.

Aviso para caminantes.

En primer lugar tengo que advertir que es una herramienta hecha como un traje a medida para mi flujo de trabajo, he decidido ir con un stack de desarrollo, tener unas convenciones, usar un sistema operativo concreto y alojar los proyectos de manera similar en el mismo lugar.

Esto hace que la solución esté muy pensada en lo que YO necesito así que probablemente no puedas usar Lanzadera para tu propio entorno pero sí espero que este proyecto te aporte ideas sobre como poner tus proyectos sobre raíles y hacer más sencillo todos esos flujos y tareas que hacen posible que un proyecto se pueda publicar y actualizar correctamente.

¿Qué es Lanzadera?.

Lanzadera es una herramienta de deploy para proyectos web en GCP. Gestiona la configuración de nginx, los certificados SSL con certbot, la autenticación PHP, un contador de visitas, la subida de archivos por SSH/SCP... todo desde Windows con PowerShell 5.1.

No es un sistema de CI/CD. No tiene servidor, no tiene interfaz web, no requiere una cuenta en ningún servicio externo.

Es un módulo PowerShell que se instala una vez en la máquina y luego está disponible en cualquier proyecto.

El flujo completo para poner en marcha un proyecto nuevo es:

  install.ps1          → configura el proyecto (una vez)
  deploy.ps1 setup     → prepara el servidor (una vez por dominio)
  deploy.ps1 web       → sube el código (cada vez que quieras deployar)

Es decir: Inicializa un proyecto en local y configura todo, se conecta con el servidor y organiza todo en el servidor, luego te provee de comandos para que puedas ir haciendo releases, subiendo datos de la web o actualizaciones de código.

¿Cómo funciona?.

La config de máquina.

Lanzadera separa la configuración en dos niveles. Por seguridad (y para que no puedas subir datos comprometidos por error a un repo o en el despliegue) La config de máquina vive fuera de todos los repositorios, en ~\.lanzadera\config.json, y contiene las credenciales comunes a todos los proyectos: el usuario SSH, la ruta a la clave privada, el email para certbot, y la lista de instancias GCP a las que tienes acceso.

Ejemplo del config

  {
    "user": "oscar",
    "key": "C:/Users/oscar/.ssh/google_compute_engine",
    "email": "tu@email.com",
    "targets": {
      "principal": {
        "instance": "nombre-instancia-gcp",
        "zone": "us-central1-a",
        "project": "id-proyecto-gcp",
        "path": "/var/www"
      }
    }
  }

Esto se configura una sola vez. A partir de ahí, cualquier proyecto que use ese target hereda automáticamente las credenciales.

La config del proyecto.

La config del proyecto vive en deploy.config.json en la raíz de cada repo (en .gitignore, para que las rutas locales no se compartan). Define el dominio, la carpeta de build, si tiene auth, si tiene tracker de visitas...

  {
    "target": "principal",
    "domain": "miproyecto.omata.es",
    "buildCommand": "npm run build",
    "distPath": "dist",
    "auth": { "enabled": false },
    "tracker": { "enabled": false }
  }

Generarla a mano es innecesario porque install.ps1 hace todo esto con un asistente interactivo.

En el momento de la instalación inicial a través de un asistente por linea de comandos se te preguntarán las cosas más habituales para configurar correctamente el proyecto. Posteriormente siempre puedes editar este archivo si las necesidades de tu proyecto cambian.

El setup del servidor.

El primer deploy de un dominio nuevo requiere configurar el servidor desde cero. deploy.ps1 setup hace eso en orden:

1. Crea el webroot en el servidor
2. Sube una config nginx HTTP-only y recarga nginx
3. Ejecuta certbot para obtener el certificado SSL
4. Sube la config nginx completa con HTTPS y recarga nginx
5. Si el proyecto tiene auth, instala php_mini_auth
6. Si el proyecto tiene tracker instala migas

El orden importa: certbot necesita que nginx esté corriendo en HTTP para completar el challenge, así que no puedes saltarte los pasos intermedios. Lanzadera los gestiona en el orden correcto y no continúa si algo falla.

Tras el setup, para deployar solo necesitas:

  .\scripts\deploy.ps1 web

Esto subirá todo tu proyecto al servidor recién configurado.

La separación código / datos.

En varios de mis proyectos hay una carpeta data/ dentro de dist/ con cientos de archivos: JSON de contenido, imágenes, audio.

Esos archivos no cambian con cada deploy de código y subirlos enteros cada vez es improductivo, lento y no tiene mucho sentido, así que para evitar eso:

Lanzadera tiene dos modos de subida:

• deploy.ps1 web — sube todo dist/ excepto la carpeta de datos
• deploy.ps1 data — sincroniza solo los archivos de datos que no existen en remoto

La sincronización de datos compara los nombres de fichero antes de subir. Si un archivo ya está en el servidor, no se toca. Si es nuevo, se sube.

Eso hace que añadir contenido a un proyecto sea rápido aunque el volumen acumulado sea grande.

Para los casos en los que sí quieres forzar la subida completa:

  .\scripts\deploy.ps1 data -Force

Imagina que necesitas asegurarte de que reseteaste bien todo el contenido de datos.

Hooks.

Algunos proyectos necesitan lógica personalizada al final de una fase. Para eso he creado los hooks: scripts PowerShell del proyecto que Lanzadera ejecuta cuando completa setup o data. Están inspirados en los hooks de un montón de tecnologías como por ejemplo git.

La idea detrás de esto que puedas tener cierto control de personalización entre las fases de ejecución de Lanzadera, imagina que necesitas instalar algo solo para ese proyecto al final de la fase de setup.

Entiende esto último como una personalización de ese proyecto y no algo que debería ir por sistema en todas las configs de un proyecto.

Se declaran en deploy.config.json:

  {
    "postSetup": "scripts/post-setup.ps1",
    "postData": "scripts/sync-db.ps1"
  }

El script recibe un objeto $ctx con la IP del servidor, el usuario SSH, la clave y el webroot, y las funciones de Lanzadera (Invoke-SSH, Invoke-SCP...) están disponibles directamente. Esto hace que un hook sea solo la lógica específica del proyecto, sin tener que reimplementar la conexión SSH.

Un ejemplo real: instalar PocketBase tras el setup.

  # scripts/post-setup.ps1
  param($ctx, $projectConfig)
  
  Invoke-SSH $ctx "mkdir -p /opt/pocketbase && wget -q -O /tmp/pb.zip https://..."
  Invoke-SSH $ctx "unzip -o /tmp/pb.zip -d /opt/pocketbase && chmod +x /opt/pocketbase/pocketbase"
  Invoke-SCPFile $ctx ".\config\pocketbase.service" "/tmp/pocketbase.service"
  Invoke-SSH $ctx "sudo mv /tmp/pocketbase.service /etc/systemd/system/ && sudo systemctl enable --now pocketbase"

Lo bueno de los hooks es que la lógica específica de cada proyecto queda documentada en el propio repo, versionada con git, y se ejecuta automáticamente sin que tengas que recordarla.

Releases semánticas.

Para proyectos que usan versionado semántico, he creado el comando release hace todo el flujo de una vez:

Ejemplo

  .\scripts\deploy.ps1 release          # patch: 1.0.0 → 1.0.1
  .\scripts\deploy.ps1 release minor    # minor: 1.0.1 → 1.1.0
  .\scripts\deploy.ps1 release major    # major: 1.1.0 → 2.0.0

Verifica que el working tree esté limpio, hace el build, deploya, crea un tag anotado y hace push a GitHub con los tags. Si el working tree tiene cambios sin commitear, se detiene antes de hacer nada (No queremos subir nada que no esté en la rama buena)

Equivalentes npm.

Si el proyecto tiene package.json, install.ps1 añade los scripts de deploy automáticamente:

  {
    "scripts": {
      "deploy": "powershell -File scripts/deploy.ps1 web",
      "deploy:data": "powershell -File scripts/deploy.ps1 data",
      "deploy:release": "powershell -File scripts/deploy.ps1 release"
    }
  }

Esto último es por comodidad, cuanto menos tengas que pensar mejor, así puedes hacer npm run deploy sin recordar la sintaxis de PowerShell, a mí me resulta muy útil cuando cambio entre proyectos con frecuencia.

Por qué no GitHub Actions / otro CI.

La respuesta corta es que no necesito un sistema tan complejo para proyectos personales.

GitHub Actions requiere configurar secretos en el repositorio (la clave SSH, el proyecto GCP...), mantener un fichero .yml de workflow, y esperar a que el runner arranque cada vez que pusheas. Para un proyecto personal donde deploya una sola persona, desde una sola máquina, eso es más fricción que ayuda.

Lanzadera corre en la máquina local, con las credenciales ya configuradas, y la retroalimentación es inmediata: ves el output en el terminal y sabes exactamente qué pasó. Si algo falla, puedes reintentarlo al momento.

Conclusiones.

He creado una herramienta muy personalizada para poder montar, desplegar y actualizar proyectos sin fricción.

Estoy metido en varios proyectos a la vez y hago subidas y actualizaciones frecuentes de los mismos, quito y pongo login, subo nuevos datos o releases.

Unificar todos estos pasos en una herramienta ha supuesto una mejora enorme en mis tiempos de entrega, puedo estar saltando de un proyecto a otro haciendo cambios en proyectos que dependen unos de otros sin perder el tiempo.

Es cierto que estoy muy atado ahora a un tipo de flujo pero al haber hecho esto modular siento que podría reescribir parte de la lógica modular del proyecto y adaptarme a hacer por ejemplo despliegues en Amazon o en otro hosting propio, volver a mac solo implicaría reescribir los scripts de deploy...

En definitiva, estoy muy contento con el resultado.

Roadmap.

Qué hacer a partir de ahora, todavía me queda trabajo por pulir, es posible que surjan nuevos addons como el que ya tiene de login o el de tracking de visitas, así que me gustaría trabajar en el sistema de plugins para que fuera un poco más modular y robusto.

Por lo demás espero hacer pocas adaptaciones y centrarme en usarlo para sacarle partido con el resto del proyectos.

En definitiva las mejores herramientas son aquellas que no necesitan mantenimiento y son casi invisibles. Funcionan y te olvidas de que existen.

¿Dónde encuentro Lanzadera?

El código está en github.com/Katamo/lanzadera. Los requisitos son Windows con PowerShell 5.1, gcloud CLI configurado, OpenSSH instalado y una clave SSH con acceso a las instancias GCP.

Si te animas a usarla o te sirve de inspiración para hacer la tuya propia, me haría un poquito feliz saberlo.

Creo que expresa como pocas el sentimiento que me empuja a mantenerme activo y a disfrutar de las cosas que hago.

Hoy ha sido la última vez que la he leído y ha sido para enviársela a mi hermano que acababa de terminar el libro Matadero 5, de Vonnegut.

Mi hermano nunca ha sido de leer mucho, siempre ha tenido un montón de virtudes, pero la lectura no ha sido nunca una de ellas.

Hace poco me sorprendió pidiéndome consejo para retomar el hábito de la lectura, quería que le fuera pasando libros de los que tenía yo en casa porque consideraba importante apartarse un rato de la pantalla, recuperar la capacidad de atención y por qué no, hacer de ejemplo para que mi sobrino tuviese un buen modelo sobre el que fijarse.

Me pareció una idea muy buena y una oportunidad de empezar a compartir historias sobre lecturas que a mí me han hecho pensar mucho.

Pocas cosas molan más en la vida que encontrar un compinche de lecturas para poder comentar los hallazgos en los libros que lees.

La cosa estaba difícil porque además me pidió que fueran libros medianamente fáciles pero distintos y especiales.

Sin ser yo un gran lector ni un lector voraz, sí que siempre he tenido la suerte de tener amigos con muy buen gusto para los libros de esos que siempre recomiendan la lectura justa para el momento vital en el que estás.

Así que tenía un montón de listas con recomendaciones y libros excelentes (al menos eso creo yo...); pero era todo un desafío encontrar libros que hablaran de temas distintos, que contaran las cosas de una manera especial y además no fueran librazos de los de desanimar. Encontrar un libro "beginner" pero que sembrara afición.

¿Vosotros qué libro habríais elegido?

No podía por ejemplo recomendarle un Conde de Montecristo y cosas así, pese a ser ligero en el relato, trepidante y entretenidísimo, es un libro demasiado largo y puede volverse duro de acabar, tampoco podía irme a virguerías literarias, cosas muy densas, ni lugares demasiado comunes.

Quería huir de best sellers y novelas de gran público, tampoco podía ser nada que tuviera un "sabor" demasiado "freak" o de nicho.

El caso es que se me ocurrió empezar con Matadero 5 de Vonnegut, porque el autor es una de mis personas favoritas y casualmente además escribe grandes libros.

La novela es sencilla, divertida y diferente, no es muy larga y deja poso. Sobre todo cuando conoces la intención real que movió al autor a escribir el libro.

Vamos, es una novela que da para comentar, que es lo importante.

El resultado es que le ha gustado muchísimo, y ya tiene preparados otros libros que le he prestado para leer; libros totalmente diferentes, (ya me contará cuál de ellos escoge).

Hemos hablado del argumento, de los personajes, de cómo la guerra es una mierda y no hay nada bonito que contar de ella, de cómo aparecen en otras novelas suyas los mismos personajes bajo otras apariencias y de cómo eso ayuda a cogerle cariño a los personajes y descubrir ese estilo literario propio que tiene.

También hemos hablado sobre el escritor y de por qué pienso que es una gran persona.

Me alegra mucho poder compartir con mi hermano una cosa como la lectura de un libro y todo lo que hay detrás y espero que sea el comienzo de una sana afición.

Al final, y volviendo al tema que abría el post, le he pasado, para que la leyera, esta carta que escribió Vonnegut a unos estudiantes de colegio y que no puedo resistirme a compartir aquí de nuevo porque me identifico mucho con lo que dice; explica con sencillas palabras por qué sigo haciendo las cosas que me gustan y por qué deberíais seguir también haciéndolas todos vosotros.

Sinceramente creo que es una enseñanza vital de las buenas, distinta a lo que solemos oír, bonita y optimista.

La carta dice así y todo según aparece la historia en múltiples sitios de internet que he consultado:

5 de noviembre de 2006

Queridos Xavier High School, Ms. Lockwood, y los señores Perin, McFeely, Batten, Maurer y Congiusta:

Os agradezco vuestras amables cartas. Sabéis muy bien cómo alegrarle el día a un vejete de ochenta y cuatro años en el ocaso de su vida. Ya no hago apariciones públicas porque ahora mismo me parezco a una iguana más que a ninguna otra cosa.

Lo que tenía que deciros, además, no llevaría mucho tiempo, a saber: practicad cualquier arte —música, canto, danza, interpretación, dibujo, pintura, escultura, poesía, ficción, ensayo, periodismo—, bien o mal, no para conseguir dinero y fama, sino para experimentar el devenir, para descubrir lo que lleváis dentro, para hacer crecer vuestra alma.

Practicad cualquier arte, bien o mal, no para conseguir dinero y fama, sino para descubrir lo que lleváis dentro.

¡En serio! Me refiero a empezar ahora mismo, a hacer arte el resto de vuestras vidas. Dibujad un retrato gracioso o bonito de la señorita Lockwood y dádselo. Volved a casa bailando después del colegio, cantad en la ducha, y así sin parar. Haced una cara en el puré de patatas. Fingid que sois el Conde Drácula.

Ahí va una tarea para esta noche, y espero que la señorita Lockwood os suspenda si no la hacéis: escribid un poema de seis versos sobre cualquier cosa, pero que rime. No vale jugar al tenis sin red. Hacedlo tan bien como podáis. Pero no le digáis a nadie lo que estáis haciendo. No lo mostréis ni lo recitéis a nadie, ni a vuestra novia, ni a vuestros padres, ni a la señorita Lockwood. ¿De acuerdo?

Rompedlo en pedacitos minúsculos y tiradlos en papeleras bien separadas entre sí. Descubriréis que ya habéis sido gloriosamente recompensados por vuestro poema. Habéis experimentado el devenir, aprendido mucho más sobre lo que lleváis dentro, y habéis hecho crecer vuestra alma.

¡Dios os bendiga a todos!

Kurt Vonnegut

Carta original en inglés:

November 5, 2006

Dear Xavier High School, and Ms. Lockwood, and Messrs. Perin, McFeely, Batten, Maurer, and Congiusta:

I thank you for your friendly letters. You sure know how to cheer up a really old geezer (84) in his sunset years. I don't make public appearances anymore because I now resemble nothing so much as an iguana.

What I had to say to you, moreover, would not take long, to wit: Practice any art—music, singing, dancing, acting, drawing, painting, sculpting, poetry, fiction, essays, reportage—no matter how well or badly, not to get money and fame, but to experience becoming, to find out what's inside you, to make your soul grow.

Practice any art, however well or badly, not to get money and fame, but to find out what's inside you. Seriously! I mean starting right now, do art and do it for the rest of your lives. Draw a funny or nice picture of Ms. Lockwood and give it to her. Dance home after school, and sing in the shower, and on and on. Make a face in your mashed potatoes. Pretend you're Count Dracula.

Here's an assignment for tonight, and I hope Ms. Lockwood will flunk you if you don't do it: Write a six-line poem about anything, but rhymed. No fair tennis without a net. Make it as good as you possibly can. But don't tell anybody what you're doing. Don't show it or recite it to anybody, not even your girlfriend or parents or whatever, or Ms. Lockwood. OK?

Tear it up into teeny-weeny pieces and discard them into widely separated trash receptacles. You will find that you have already been gloriously rewarded for your poem. You have experienced becoming, learned a lot more about what's inside you, and you have made your soul grow.

God bless you all!

Kurt Vonnegut

Así fue.

Pero a veces, tengo que reconocer que, en proyectos largos, compartidos o en aquellos que dependen de acciones de otro, usar un gestor puede ser la diferencia entre sacar el proyecto bien y no sacarlo jamás.

Los deberes son aburridos.

Aún así, gestionar tareas siempre me ha parecido un rollo.
En mi vida profesional he probado la mayoría de los sistemas de tareas con más o menos éxito, Desde una simple nota, a enviarme correos; changelogs y todolists, software y aplicaciones, Notion, Trello, Jira...
En todos llevar el tracking de las tareas es bastante aburrido y gestionarlas un doloroso trabajo en sí mismo.

El problema del foco.

Todas las aplicaciones o sistemas que he probado sufren en mayor o menor medida el mismo problema gordo cuando los usas para desarrollo y es lo que yo llamo: la fricción con el código.

Lees una tarea, en un entorno y luego te tienes que ir a tu entorno otra vez a entender qué te está pidiendo, a veces cuenta cosas sobre un bloque de código y ese código viene sin formato. Tienes que ir a la aplicación, volver al código mirar, volver a la aplicación de tareas, explicar algo...

Todo esto te desconcentra, tienes que estar con dos contextos a la vez y hace que inevitablemente pierdas tiempo y concentración, transportando ideas de una aplicación a otra.

Es cierto que hay sistemas que producen menos fricción y están más integrados con tu zona de trabajo, tener a veces un sencillo archivo de texto sobre el que vas añadiendo y quitando cosas es bastante útil, no tienes que salir del area de concentración, tenerlo siempre disponible y si lo haces un poco profesional, puedes ir convirtiéndolo en un TODO-List/Changelog del proyecto directamente según resuelves o levantas tareas.

Lamentablemente eso también tiene el problema de que es poco potente y no te permite enlazar tareas de distintos proyectos.

El paraíso del procrastinador.

El otro gran problema que tienen los sistemas de gestión de tareas es que acaban siendo muy complejos y sirven para que ciertos perfiles de trabajo aprendan a vivir casi exclusivamente en esas aplicaciones de tareas, convirtiendo su labor en un ejercicio constante de levantar tareas y complejidad alrededor del trabajo pendiente.

Así las aplicaciones de tareas se vuelven complejas, se llenan de etiquetas y convenciones, niveles de urgencia o importancia.

Se crean tarjetas para todo y cada vez te consume más tiempo llevar el orden de lo que está pasando.

Para un procrastinador avezado una aplicación de tareas así se convierte en el paraíso porque puede dedicarse todo el día a explicar qué tiene que hacer sin llegar realmente nunca a hacerlo.

Hacer la cosa de la procrastinación.

Yo, reconozco que tengo cierta tendencia a la procrastinación, me descubro a menudo merodeando alrededor de un problema sin llegar a pegarle un mordisco definitivo para resolverlo.
Pensando a veces que son demasiado bocado para atacarlo de una vez, creo tareas y defino y preparo un montón de cosas que deberían estar listas para poder hacer de ese problema un bocado asequible. En realidad, pura procrastinación.

He aprendido con el tiempo a detectar cuando estoy siendo productivo y cuando estoy revoloteando alrededor de un problema sin atreverme a hincarle el diente.

Darme cuenta de eso me hace algo más resistente a la pereza y la procrastinación pero no inmune.

Así que cuando trabajo, busco procesos y herramientas que no me permitan detenerme mucho a contar los detalles, sobre todo ahora que ya no desarrollo en equipo, casi prefiero acometer una tarea que sé que tengo que realizar antes de pararme a documentarla y dejarla de hacer, perdiendo el tiempo en explicar cómo hacerla en lugar de hacerla.

La contrapartida de esa manera de funcionar es que a veces paras tareas importantes para realizar otras y pierdes un poco el control sobre lo que estás desarrollando, corriendo el riesgo de no cerrar tampoco tareas importantes, por una indefinición clara de qué debería estar hecho.

Buscando el santo grial.

Analizando todas estas cosas, me he puesto a buscar durante unos días una solución que cubriese ciertos puntos para gestionar el tipo de proyectos que estoy ahora mismo desarrollando.

Como trabajar en equipo ya no es un punto a tener en cuenta, la búsqueda de la aplicación se puede centrar en lo que me gusta a mí en concreto. Y a ello me he puesto.

Primeramente, los puntos importantes que debía cumplir esta herramienta han sido:

• Que estuviera en mi entorno de desarrollo, es decir que viviera al mismo nivel que el código en el que estoy trabajando.
• Que fuera minimalista, con las mínimas funcionalidades, para no perder el tiempo añadiendo etiquetas.
• Que fuera muy extensible, si necesito una funcionalidad que no tenía, por ejemplo enlazar tareas de dos proyectos, tiene que ser fácil cambiarlo.
• Que permitiera enlazar proyectos y tareas que dependen de otras. Desarrollo varias cosas a la vez y unas dependen de otras, si necesitas una funcionalidad debes saber de qué depende, o conocer cuando una funcionalidad desbloquea cambios en otros proyectos.
• Que fuera muy rápida, y pueda acceder a las tareas pendientes sin perder mucho tiempo buscándolas.
• Que fuera muy sencilla de usar, sin menús sin niveles de profundidad.
• Y sobre todo, transparente que no tenga la sensación de estar usando una aplicación más sino que se convierte en parte de mi flujo de trabajo escribiendo en el mismo lugar en el que lo hago todo.

La solución.

La respuesta y después de buscar soluciones y propuestas de otros desarrolladores, como todo buen programador ya debería haber anticipado, es: construir mi propia aplicación de tareas y eso es lo que he hecho aprovechando las dos cosas que tengo ahora siempre abiertas al trabajar: un editor de texto y Claude Code.

Ya tiene hasta nombre.

Se llama Los Deberes porque me sigue produciendo el mismo sentimiento llevarme los deberes del colegio a casa que resolver estas tareas de un proyecto.

Dicho todo esto, paso a explicar por encima lo que he hecho y cómo funciona.

Cómo funciona

La idea es simple: cada tarea es una carpeta con un archivo Markdown dentro. Nada de bases de datos, nada de servicios externos. En esas carpetas guardo todo lo necesario para esa tarea, otros trozos de código, texto por elaborar, referencias...

Todo vive en local, en mi disco, versionado con git y subida de vez en cuando a remoto para poder hacer backup por si rompo algo.

Utilizo Claude (aunque puedes montarlo con cualquier otra IA) para interpretar y manejar todas esas tareas.

Ejemplo

  datos/tareas/
  ├── bedrock/
  │   └── BDR-001-importacion-tipografias/
  │       └── tarea.md
  ├── mixes.0057/
  │   └── MIX-001-mejoras-ui-movil/
  │       └── tarea.md
  └── rutina/
      └── RUT-001-configurar-prettier/
          └── tarea.md

Formato de la tarea

Cada tarea.md tiene un frontmatter mínimo: id, título, proyecto, fecha, importancia y estado. El resto es texto libre.

Este es un ejemplo real de una tarea que tenía abierta.

  ---
  id: MIX-003
  titulo: Sindicar el RSS
  proyecto: mixes.0057
  fecha: 2026-05-26
  importancia: media
  estado: pendiente
  ---
  
  ## Descripción
  
  Generar y publicar un feed RSS para el proyecto mixes.0057, de forma que los usuarios puedan suscribirse y recibir notificaciones cuando se publique un nuevo mix.
  
  ## Criterios / pasos
  
  - [ ] Decidir formato del feed (RSS 2.0 o Atom)
  - [ ] Definir los campos a incluir (título, fecha, descripción, portada, enlace al mix)
  - [ ] Generar el feed a partir del `index.json` existente (estático o con script de build)
  - [ ] Publicar el feed en una URL fija (ej. `/feed.xml` o `/rss.xml`)
  - [ ] Añadir `` en el `` del HTML para autodescubrimiento
  - [ ] Verificar el feed con un validador (W3C Feed Validator o similar)

Lo interesante aquí es que Claude Code lee esa estructura y la entiende. El proyecto incluye un CLAUDE.md con las convenciones del sistema, así que Claude sabe cómo crear tareas, calcular IDs, mover carpetas al completar, y listar pendientes por proyecto o importancia.

Yo puedo también editar directamente cosas que ya no aplican o necesidades nuevas. La aplicación es tan sencilla que hacer un cambio en una tarea consiste simplemente editar un texto o pedírle a Claude que lo haga.

Los comandos

Lo importante ocurre a través de dos slash commands que he instalado globalmente en Claude Code:

Comando /deberes

/deberes gestiona la lista. Funciona desde cualquier proyecto, sin necesidad de abrir la carpeta de mi gestor de tareas.

El modo de uso es sencillo, con lenguaje natural describes las cosas importantes de la tarea, ejemplo: añade esto a éste proyecto, es importante.

  /deberes añade una tarea a bedrock: revisar sistema de importación de tipografías, importancia alta
  /deberes lista las tareas pendientes
  /deberes tareas críticas
  /deberes marca como completada BDR-001

Comando /tarea

/tarea carga una tarea concreta y analiza cómo abordarla en el proyecto que tengas abierto en ese momento. Útil cuando sabes lo que tienes que hacer pero quieres que Claude te ayude a arrancar:

Este comando sirve para arrancar con el desarrollo de una tarea o analizarla en detalle, Su uso es sencillo, después de listar, por ejemplo, los ids de varias tareas, usas ese Id para comenzar a trabajar en ella.

  /tarea MIX-001

Claude lee la descripción y los criterios, revisa el código del proyecto actual y te explica por dónde empezar, además es capaz de avisarte de las dependencias por si necesitas acabar antes con otra tarea.

Tareas de rutina

Algunos cambios hay que aplicarlos en varios proyectos a la vez: actualizar una dependencia, añadir un archivo de configuración, aplicar un nuevo estándar de código. Para eso he extendido las funcionalidades añadiendo un tipo nuevo de tarea transversal, las tareas de rutina.

Una rutina tiene una lista de proyectos donde debe aplicarse.
Cuando la completas en uno, lo eliminas de la lista.
Cuando la lista queda vacía, la tarea se archiva automáticamente.
Pueden ser tareas que tienen que ser completadas todos los días o que van a repetirse a lo largo de varios proyectos.

Lo bueno es que todo esto lo detallas en lenguaje natural y si en algún momento descubres que una funcionalidad como esta no es útil la eliminas del flujo con un par de frases y ya tienes gestor más ajustado a tus necesidades.

A mí me funciona trabajar con rutinas así:

  /deberes añade una rutina: configurar prettier en bedrock, mixes.0057 y plantillas
  /deberes he aplicado RUT-001 en bedrock
  → RUT-001 actualizada. Pendiente en: mixes.0057, plantillas.

Tareas vinculadas

A veces terminar una tarea en un proyecto abre trabajo en otro. Por ejemplo: implemento un componente en mi librería de UI y ese componente debería integrarse después en tres proyectos distintos.

El campo desbloquea captura esa relación:

  ---
  id: PLT-003
  titulo: Componente tabla ordenable
  proyecto: plantillas
  desbloquea: MIG-007
  ---

Al completar PLT-003, Claude me avisará de que MIG-007 está lista para empezar y me pregunta si quiero arrancar con ella ahora.

Changelog automático

Otro punto que puede beneficiarse de esta automatización es el changelog. El changelog es una cosa difícil de mantener que exige disciplina y cuyo beneficio solo puedes ver si eres persistente añadiendo tareas completadas, cosas qeu en los proyectos en solitario supone una carga de trabajo innecesario y que a menudo abandonas a la tercera release.

En Los Deberes mantener el changelog te sale gratis porque se encarga automáticamente la aplicación de hacerlo por ti cuando se lo indicas, sin perder tiempo ni aplicar esfuerzo.

Como en Los Deberes tengo las tareas completadas guardadas con fecha, título e importancia, es muy sencillo automatizar todo. El camino para hacerlo que encontré es añadir un tercer comando que convierte ese historial en una entrada de changelog.

Comando /changelog

  /changelog bedrock

El comando lee las tareas completadas del proyecto, detecta cuáles son nuevas desde la última entrada del CHANGELOG.md, sugiere una versión semver según la importancia más alta de las tareas (crítica → major, alta → minor, media/baja → patch) y te muestra un borrador para que lo apruebes o ajustes la versión antes de escribir nada.

  ## [0.2.0] - 2026-05-30
  
  ### Added
  - BDR-003 Sistema de tokens de color con soporte dark mode
  
  ### Fixed
  - BDR-001 Corregir sistema de importación de tipografías

El CHANGELOG.md vive en cada proyecto, no en el gestor. Es exactamente donde debe estar: versionado junto al código, accesible para cualquiera que clone el repo.

El flujo real.

Cómo es trabajar con en un proyecto entonces con este gestor?

Cuando quiero trabajar en un proyecto arranco Claude Code en ese directorio, al arrancar Claude ya tiene los comandos guardados y sabe qué hacer si le solicito algo a través de ellos.

Puedo escribir en la linea de comandos: /tarea BLG-001.
Entonces un skill lee el archivo, me muestra el resumen y me pregunta por dónde quiero empezar.

Cuando termino una tarea, la muevo a datos/completadas/ y listo. Con Git guardo el historial de todo.

Si quiero actualizar el changelog, con un comando está hecho.

Lo que me resulta especialmente útil es que puedo añadir contexto a las tareas. Si hay una decisión que tomé, una referencia que encontré o una restricción que descubrí mientras trabajaba, la apunto directamente en el tarea.md. La próxima vez que retome esa tarea, Claude tiene todo el contexto sin que yo tenga que recordar nada.

Es, básicamente, una memoria externa que vive junto al código.

Por qué funciona (para mí).

Para alguien que trabaja solo, en varios proyectos pequeños, con un asistente de IA siempre abierto en el terminal, tener las tareas en texto plano con git es lo más cómodo y transparente que he podido diseñar.

Las tareas están versionadas. Puedo ver cuándo creé algo, cuándo lo modifiqué, cuándo lo completé. No dependo de que una plataforma cambie sus condiciones ni de que el servicio esté disponible. Y si en algún momento quiero cambiar algo del sistema, lo cambio yo directamente porque son solo archivos.

El sistema tiene sus limitaciones, claro. No hay notificaciones, no hay fechas límite que me avisen, no hay integración con calendarios. Pero tampoco las necesito. Si algo es urgente, ya lo sé sin que me lo diga una app, y si necesito extenderla y tener más control puedo añadir nuevas reglas.

La aplicación entonces es un repositorio de archivos de texto plano, se interactúa con ella a través de Claude en el propio IDE, y solicitando cosas en lenguaje natural, puedes ver las dependencias con otras tareas, abrir nuevas incidencias sobre otro proyecto directamente en el proyecto en el que estás trabajando y sin salir de la pantalla de trabajo, puedes guardar trozos de código o textos dentro de cada tarea, pues cada tarea reside en su propia carpeta, es prácticamente transparente y muy sencilla de usar.

Y eso es todo amigos.

En mi condiciones y para el tipo de proyectos que estoy montando ahora mismo, se ha convertido en el flujo de trabajo ideal, cero fricción y mínimo tiempo perdido en gestionar incidencias.

No digo que sea para todo el mundo pero si crees que encaja con tu modo de trabajar, aquí te dejo el repositorio donde la he subido github.com/Katamo/losdeberes.

Un detalle a tener en cuenta es que la herramienta es pública, las tareas son privadas(*). El repo que instalas no contiene ninguna tarea: la carpeta datos/ está en el .gitignore. Puedes gestionarla como un repo git privado independiente, o simplemente dejarla en local.

(*) Suponiendo claro que todo lo que subes a claude es compartido para entrenar su modelo. Aunque nada te impide adaptar este proyecto para usarlo con un modelo local ya que no necesita ser muy potente.

En definitiva, Deberes es un sistema de trabajo más que un producto. No tiene interfaz, no tiene servidor, no tiene cuenta que crear y es totalmente personalizable.

Funciona porque Claude Code ya sabe leer texto y seguir instrucciones y porque los archivos Markdown son lo suficientemente flexibles como para modelar casi cualquier flujo de trabajo, puedes modificarla a tu gusto simplemente añadiéndole o quitándole funcionalidades.

No tengo planes de hacerle interfaz gráfica ni de complicarla, sencillez máxima e ir adaptando el flujo de trabajo según lo necesite, creo que he encontrado una gran solución para gestionar proyectos de desarrollo y la iré puliendo según avance en su uso.

Cuando lleve un tiempo con ella espero escribir otro post sobre cómo ha ido.

Si la pruebas cuéntame qué te parece y qué cambios le hiciste.

Ahora que tengo varios proyectos publicados me vendría bien saber de dónde vienen las visitas, qué visitan más y en qué cantidad lo hacen, así que he pensado en añadir un sistema de tracking a alguno de los proyectos que tengo ya online. Antes de ponerme a montar nada he estado analizando lo que necesitaba.

Estos eran los requisitos de salida:

• Necesitaba una herramienta muy sencilla.
• Que fuera fácil de instalar en los distintos proyectos que tengo.
• No hacía falta que estuviera en ningún hosting podía residir perfectamente en local.
• Tenía que permitirme ver todas las visitas de todos los proyectos a la vez.
• Acoplarse bien en el stack de tecnologías que uso para los proyectos.
• Que los datos fuesen solo míos y saber qué datos realmente estoy recopilando para no ser intrusivo con el visitante.

Por qué no X

Estuve mirando opciones ya existentes y fui descartándolas todas.

¿Por qué no Google Analytics? Usar Google Analytics supone una opción sobredimensionada y además implica compartir mis datos con terceros. Con Migas, los datos los tengo solo yo.

¿Por qué no Plausible / Fathom? Son buenas opciones pero tienen coste mensual. Migas es gratuito porque corre en infraestructura que ya tengo.

¿Por qué no Matomo? Matomo es potente pero pesado para lo que necesito. Un servidor PHP y un fichero de texto son suficientes.

¿Por qué JSONL y no una base de datos? Un fichero de log append-only no tiene dependencias, no requiere backups adicionales, y para el volumen de un proyecto personal es perfectamente manejable. Si algún día las visitas escalan, la migración a SQLite o similar es directa.

Así que acabé tomando la decisión de montar Migas: un sistema de analytics minimalista, autoalojado, que cabe en tres ficheros PHP y un par de componentes Vue.

Qué es Migas

Voy a ponerme un poco técnico el resto de la entrada, que es un post para gafotas y amigos de las teclas pero creo que merece la pena contarlo. Espero que este tipo de contenidos os animen a montar vuestras propias herramientas.

Migas tiene tres piezas independientes:

1 El tracker

Es un módulo PHP portable que se copia en cualquier proyecto web. Expone varios endpoints:

• POST /tracker/log.php — recibe un evento de visita desde la SPA y lo guarda en un fichero de log JSONL.
• GET /tracker/read.php — devuelve el log completo, protegido con un Bearer token.
• POST /tracker/flush.php — descarga los datos a local y vacía el log.

Este tracker no guarda IPs. No usa cookies. No instala nada en el navegador del visitante. El registro de cada visita tiene este aspecto:

  {
    "ts": "2026-05-28T18:32:01Z",
    "path": "/mix/01",
    "referrer": "",
    "screen": "1920x1080",
    "lang": "es",
    "ua": "Mozilla/5.0..."
  }

2 El viewer

Es una SPA en Vue 3 que actúa como panel de control central. Se conecta a los trackers de todos tus proyectos a través de un proxy PHP que mantiene los tokens fuera del bundle JavaScript. Desde ahí puedes ver las visitas de cada proyecto, filtrar por ruta o fecha, y paginar la tabla.

3 La app

Es opcional y sirve para tener el viewer por comodidad en una app de escritorio; ejecutas un .exe y tienes la consola de visitas abierta.

Cómo funciona

El flujo completo es:

  SPA del proyecto  →  POST /tracker/log.php  →  visits.log
                                                      ↑ Bearer token
  viewer (local)   →  /api/fetch.php (proxy)  →  GET /tracker/read.php

La SPA llama a log.php en el mismo servidor donde está desplegada. log.php valida que el origen esté en la lista de dominios permitidos, añade el timestamp y el user agent, y hace un append al fichero de log.

El viewer corre en local. Cuando seleccionas un proyecto, su proxy PHP llama a read.php con el token secreto y devuelve el JSONL. Los tokens nunca llegan al navegador.

Por decirlo brevemente:

• Instalas en el servidor de tu proyecto el bloque del tracker.
• Añades en tu proyecto las llamadas al tracker.
• Configuras un JSON con los datos de tu proyecto a trackear en el viewer.
• Accedes a los resultados ejecutando el viewer en local en modo desarrollo u opcionalmente usando el viewer en formato app .exe de Electron que es más cómodo.

📌 Tienes unas instrucciones completas de instalación en el README.md del proyecto en GitHub.

Llamar al tracker desde la SPA

Lo más fácil para trackear visitas desde cualquier Vue SPA es usar un composable o una llamada directa al montar la app:

  // src/composables/use-tracker.js
  export function useTracker() {
    function track(path) {
      navigator.sendBeacon(
        "/tracker/log.php",
        JSON.stringify({
          path,
          referrer: document.referrer,
          screen: `${screen.width}x${screen.height}`,
          lang: navigator.language,
        }),
      );
    }
    return { track };
  }

Cada llamada del router envía al log el dato de navegación

  // En App.vue o router/index.js
  router.afterEach((to) => {
    navigator.sendBeacon(
      "/tracker/log.php",
      JSON.stringify({
        path: to.path,
        referrer: document.referrer,
        screen: `${screen.width}x${screen.height}`,
        lang: navigator.language,
      }),
    );
  });

sendBeacon es no bloqueante: el navegador envía la petición aunque el usuario esté navegando a otra página, sin añadir latencia a la experiencia.

Qué se ve en el viewer

El dashboard es sencillo, tiene dos vistas, una con un resumen de todos los proyectos trackeados y una lista de las últimas visitas sin filtrar de todos los proyectos.

Pulsando en una de las cards de resumen de un proyecto, accedes a una vista en detalle con algunas estadísticas de páginas más visitadas y una tabla con los logs cargados.

La tabla muestra: ruta, timestamp, referrer, resolución, idioma y user agent. Hay filtros por ruta y por rango de fechas, y paginación para logs con muchas entradas.

Conclusión

Y eso es justo lo que quería: un tracker sencillo para ver qué páginas funcionan, detectar de dónde viene el tráfico, confirmar que los deploys llegan a los usuarios. Sin dashboards de cinco niveles y sin ceder datos a terceros.

El código está en github.com/Katamo/migas si te animas a usarlo o adaptarlo, adelante.

La informática y en concreto el trabajo de programador básicamente consiste en montar cacharros complicados usando otros cacharros complicados y con el resultado montar cacharros más grandes y más complicados que necesitan de esos otros que montaste antes. Cada capa le añade al asunto un poquito de complejidad con la contrapartida de ganar también en potencia y posibilidades.

Esto es particularmente cierto en el caso de las herramientas que construimos para poder montar cosas más grandes.

Tener una herramienta que automatice algún proceso que actualmente tiene que hacer un informático a mano es el sueño dorado de cualquier desarrollador.

Apretar un botón y que todo automágicamente funcione solo, es la fantasía a la que aspiramos todos los programadores (después de la fantasía de cobrar por el poquito de magia).

En este sentido considero que la pereza es el pilar básico que sustenta toda la programación, con permiso de la codicia.

No te repitas.

Súmale a estas ganas de hacer que todo funcione con el mínimo esfuerzo la alegría que se siente cuando descubres que una solución que hiciste funciona y que no solo funciona sino que puedes usarla y repetir el truco (...y cobrar por ello) en otro proyecto.
Si consigues meterlo en una caja y ponerle un nombre, ¡Enhorabuena! porque has creado una herramienta.

A partir de ahora puedes usar esa herramienta para generar parte de tu trabajo. Podríamos pensar que esto se traducirá en menos trabajo para ti o tu equipo pero eso es llevar las cosas demasiado lejos.

Lo que sucede con ese tiempo y esfuerzo que ahorras es que puedes tener más tiempo para trabajar más y hacer cosas más grandes y más complicadas.
¡Enhorabuena de nuevo! has apilado otra capa en la montaña de la complejidad computacional de tu profesión.

La buena noticia es que ahora con una herramienta que se encuentra varias capas más abajo puedes arreglar un problema que se produce en un montón de aplicaciones más arriba de esa montaña de cacharros.

La mala noticia es que si se rompe algo montaña abajo, todas las cosas de arriba se rompen a la vez.

Pero no pasa nada porque los informáticos somos especialistas en arreglar cosas o en su defecto montar cacharros que arreglen esos errores.

Volvemos a la fantasía.

Después de explicar cómo funciona básicamente el mundo de la informática para gente que no es de la profesión, o al menos intentar explicar cómo es una de sus facetas.
Viene ahora lo que todo programador o equipo hace en cuanto tiene la posibilidad.

Que es utilizar herramientas para ahorrarse trabajo en el día a día y esta oportunidad surge muy habitualmente pues los programadores somos gente muy entrenada en detectar patrones que se repiten.

En cuanto descubres algo que ya hiciste en su momento dices: ¡Ah! ¿Dónde hice yo algo parecido antes? y te lanzas a buscar el trozo de código que hacía más o menos lo que ahora mismo necesitas para adaptarlo.

En ocasiones incluso ante una tarea que se presenta compleja o repetitiva el demonio de la pereza que habita en el interior de todo informático que se precie, avisa al programador para que busque una herramienta en internet de alguien que ya haya hecho eso antes y haya compartido con la comunidad.

(Algún día habrá que hablar de la sacrificada fraternidad universal de la pereza que tanto ha hecho avanzar a la humanidad en estos últimos 50 años. La diferencia en este caso de la autoría y los derechos de autor con otros campos de la creación da para una buena discusión).

Y en algunas contadas ocasiones surge la oportunidad de crear para ti o junto a tu equipo una nueva herramienta, tu propuesta de cómo te han funcionado a ti las cosas, de esas ideas que encontraste y guardaste y que si consigues juntarlas y ponerles un nombre, te darán prestigio y ahorrarán mucho trabajo (En teoría).

Y ahí comienza la tarea, (en la que nadie se pone de acuerdo por cierto) de darle forma a un cacharro que te haga trabajar un poquito menos, repito (En teoría).

El Génesis.

Y más o menos así es cómo nace la idea de programar cualquier herramienta, Ilusión, pereza algo de codicia y si hablamos de un proyecto en grupo una buena cantidad de discusiones, (discusiones que por cierto suelen dar lugar a las mejores escisiones de grupos que generan nuevas herramientas).

Ahora mi cacharro.

Pero centrándonos en el proyecto del que quiero hablar, y como he vuelto a montar webs enseguida me ha surgido la opotunidad de crear una herramienta que me permita hacer más cosas en menos tiempo.

He juntado algunas de las ideas que usé con éxito en anteriores trabajos y les he puesto nombre, el framework está todavía en desarrollo, es decir, voy añadiendo funcionalidades a medida que las voy necesitando en varios sitios, guardando cosas que ya he usado y puedo volver a usar más adelante en esta herramienta.

Os dejo por aquí un enlace a CSS Bedrock , un framework con un montón de reglas, buenas prácticas, herramientas y algunos bloques y componentes para ayudaros a montar aplicaciones web.

Está orientado a no repetir cosas, a que se pueda aplicar en un equipo de varios desarrolladores y para proyectos medianamente grandes en código y duración.

El conjunto de reglas y recomendaciones que recojo tienen su eficacia probada por mí y por compañeros con los que trabajé en proyectos larguísimos de varios años de duración en los que mantener el código antiguo limpio y revisable era de suma importancia.

El desarrollador tiene que ser transparente.

Una de las ventajas que ofrece un conjunto de reglas así, es conseguir que en un equipo de varias personas trabajando a la vez, el programador pase a ser invisible, que no se pueda saber quién ha hecho qué parte porque las reglas solo te permiten hacer las cosas de una manera.

Esto que podría parecer un problema en proyectos de muy larga duración se convierte en una ventaja, al hacer código sencillo y mantenible.

Las cosas claras

Este proyecto quiere mantener una filosofía presente desde el inicio del desarrollo web y que es la idea principal que motivó la forma que tienen hoy ciertos lenguajes y es, separar contenido de presentación, algo que parece haberse olvidado en ciertas herramientas similares a ésta y que hoy en día gozan de una gran popularidad. En este sentido es claro, en el HTML (contenido) no se añade presentación (estilos).

Por otro lado también invita a que las piezas que desarrolles no dependan de otras piezas que pueden cambiar. (Una de las pesadillas recurrentes de un programador es tener que arreglar algo que depende de otra cosa que cambió)

Plantillas, el compañero de Bedrock.

Una de las cosas que me ha permitido montar Bedrock, además de este blog, es generar otra herramienta llamada Plantillas (sí, he apilado otra capa en esta montaña infernal de la complejidad). Y sirve para reutilizar trozos de código generados con Bedrock.

Porque Bedrock propone buenas prácticas y un puñado de funciones, pero nada me impide con ese tratado de buenas maneras crear bloques que pueda reutilizar en un montón de proyectos.

Pongo un ejemplo para que quede más claro, si en algún momento monto un layout de una cabecera un contenido principal y un footer para una web. ¿Por qué iba a tener que volver a programarlo si ya lo hice en algún lugar del espacio-tiempo? mi demonio de la pereza se revolvería dentro de mí si no lo hiciera.

Así que esa es la idea fundacional de mi proyecto Plantillas del que podéis ver algunas piezas ya funcionando en este enlace.

Un último mensaje.

Si estás pensando usarlo porque crees que podría serte de utilidad, avísame, estoy disponible en github, copia el proyecto y destrípalo, añade modificaciones o coméntamelas.

Advertencia El proyecto está en una fase inicial pero ya es usable, aún así puede que te encuentres con que no tiene alguna funcionalidad crítica que necesitas, valora qué te aporta la dependencia antes de añadirla a tu stack del proyecto.

Nadie quiere hacer el trabajo dos veces si puede evitarlo, así que si este código te es de alguna utilidad, tuyo es.

Pongo en funcionamiento esto con el primer post de mi nuevo proyecto blog.
Hace 3 años abandoné el mundo de la programación por razones personales y me prometí no volver a encender un ordenador en la vida, pero como si fuera un propósito de año nuevo no me ha durado mucho el juramento.
Llevo unos meses probando tecnologías y haciendo pruebas, desarrollando prototipos de ideas que tenía guardadas en un cajón y montando un montón de cosas nuevas que se me han ocurrido en este tiempo. He pasado varios meses desoxidándome y recordando cómo era mi profesión, a decir verdad, he estado casi 3 años sin tocar un teclado y muy feliz.
La cabeza se acostumbra muy rápido a esa nueva realidad y va olvidando y haciendo pequeñas todas esas ideas y recursos mentales, haciendo hueco para esas nuevas cosas que vienen en la vida.

¿Lo echaba de menos?

No. Bueno lo que se echa de menos es tener la cabeza ocupada resolviendo desafíos, afortunadamente me he mantenido despierto estudiando otras cosas que me apasionan, así que el cerebro se ha mantenido con músculo y es una cosa que agradezco mucho, ahora que retomo la actividad sesuda.
No os voy a engañar tampoco y en estos tres años he olvidado un montón de trucos y conocimientos básicos, vuelve a ser muy frustrante no recordar como centrar un