Apilar cacharros.
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.