Hay dos cosas que me pierden: el merchandising de los eventos de Microsoft, y casi todo lo nuevo que voy probando. Sí, si, lo se… soy un poco «pattern happy», un poco amante de los gadgets y muy, muy «friki» (en el sentido más puramente hispano de la palabra). Actualmente me está atrayendo poderosamente la idea de las Software Factories y los Domain Specific Languajes (DSL). Me atrae tan poderosamente que, como me conozco, empiezo a dudar sobre si lo que me atrae es real, o son cantos de sirena.
¿Software factoqué?
Cuando el famoso cocinero de la tele nos prepara un delicioso Marmitako, o nos deleita con una chuletitas de cordero ricas, ricas, ricas… nos está enseñando una receta. Nos da un conjunto de pasos, técnicas y conocimientos, que nos ayudan a triunfar en un determinado dominio: la cocina. Digamos que la distancia para sorprender a nuestra churri, es más corta si seguimos una receta que si tratamos de improvisar en los fogones.
Una Software Factory sigue el mismo principio: es un conjunto de patrones, documentación (recetas), plantillas y mucha, mucha, mucha… ¡generación automática de código! Personalmente estoy usando la Smart Client Software Factory, que te ayuda a desarrollar Smart Clients que se sustentan sobre Composite UI Application Block (CAB).
Vale, eso tiene sentido… ¿y los DSL?
Las Software Factory casi siempre van de la mano de los DSL, o «Domain Specific Languajes». ¿Te imaginas que el programa de Arguiñano se hiciese en el plató de Bricomanía? ¿Sería raro, verdad? Cada situación requiere un conjunto distinto de herramientas, y cada dominio, un lenguaje adaptado a su contexto. El problema de los lenguajes de propósito general, es que son como el plató de Bricomanía… por el simple hecho de que tengamos una sierra de calar, podemos sentir la tentación de usarla para trinchar el pavo. La solución para evitar el error, es deshacerse de la sierra de calar.
Hace poco, alguien, tratando de hacerme bajar de mi nube, me decía que hace 20 años que tratan de vendernos los lenguajes de 4ª generación, y me insinuaba que esto es el mismo perro con distinto collar. Bueno, en cierto modo los DSL se parecen a los 4GL en que buscan ser declarativos (yo digo lo que quiero, y no cómo lo quiero) pero no pretenden ser tan ambiciosos. Ciñéndose a un dominio, es más fácil tener éxito con un lenguaje declarativo.
Lo cierto es que cada vez que abrimos el diseñador de interfaces de Visual Studio, ya estamos usando un DSL. Nosotros añadimos controles a un formulario y enlazamos eventos con código usando un lenguaje visual, basado en el paradigma de arrastrar y soltar. Lo mismo ocurre cuando desarrollamos un ETL con Integration Services… los DSL llevan años acompañándonos.
En algunos casos, el DSL ni siquiera requiere que se abandone el lenguaje de propósito general… simplemente, se limita a ocultar la complejidad del mismo, y nos guía para que sólo utilicemos aquella parte del lenguaje adecuada a nuestros fines. Llevamos años encapsulando para tratar de ocultar la complejidad… ¿por qué somos tan reacios a que una herramienta nos abstraiga del propio lenguaje procedural?
Lo pasamos por la batidora, y directo al horno (220ºC)
Microsoft nos está preparando un buen plato a base de DSLs, patrones, Software Factories y demás ingredientes. Los muchachos se llaman GAX, GAT (Guided Automation Extensions y Guided Application Toolkit, respectivamente) y DSLTools y están a punto de llegar a este lado del Mississippi.
Esta pretende ser una revolución en la forma en la que desarrollamos software. Paremonos a pensar en la mayoría de ISVs y sus catálogos de software… es habitual que los ISV se especialicen en un dominio, ¿verdad? Los hay quienes hacen herramientas de desarrollo, software de tratamiento de imágenes, productos de seguridad… pero generalmente, igual que cada cabra tira a su monte, cada ISV va a su terreno. Luego hay consultoras capaces de hacer de todo (hasta botijos, si estuviesen bien pagados), pero bueno, estamos hablando de desarrollo de software, y no de tratantes de carne humana (huy lo que he dichoooooo…), y estoy seguro que hasta éstas pueden beneficiarse de las Software Factories.
Imaginaos este mundo idílico, en el que nuestro arquitecto desarrolla la Software Factory adecuada a nuestro dominio, y nuestros desarrolladores la utilizan para programar aplicaciones específicas para el dominio. ¿Acaso no es una forma estupenda de transferir el conocimiento?
¡Camarero una manzanilla!
Para acabar sin indigestión, os voy a recetar un poco de descanso (a poder ser en vuestro sofá más cómodo) y cuando vuestro cerebro pida guerra, unos cuantos links:
- Tom Hollander’s blog: Habla mucho sobre GAT y GAX, y también da noticias sobre nuevos «application blocks»
- Matias Woloski: Sobre todo habla de la Smart Client Software Factory
- Patterns & Practices: Software Factories: Noticias sobre las software factories de Microsoft.
Y ahora, ya puedes opinar… ¿Estamos hablando de la Piedra Rossetta del desarrollo de software, o son cantos de sirena?
Madre mia, estás usando CAB, es algo que sigo sin comprender, y perdona el atrevimiento, pero el esfuerzo que conlleva no merece la pena ya que realmente si uno lo piensa friamente no aporta nada que no podamos hacer de una manera más sencilla prescindiendo del el. Aún estoy esperando que alguien me demuestre que se puede hacer algo con este Application Block con menos esfuerzo que sin el ?¿?¿¿?¿?¿
Por cierto, yo también me emocioné mucho con GAT y DSLTools y aún sigo creyendo pero en unos casos muy especificos…..
Hola Gorka,
En un mundo donde nos dejamos llevar, cada vez más, por lo nuevas tecnologías que surgen de manera vertiginosa por el mero hecho de su novedad quizás sea el momento de plantearse un poco de tranquilidad. Intentar mejorar y ser mucho mas productivos con las tecnologías que usamos y tenemos en nuestro trabajo diario debería ser un objetivo igual de importante que innovar ser original. Pero ya sebe que es mucho más aburrido… o no?
Saludos.
Hola Unai,
Efectivamente, CAB supone una complejidad adicional que para una aplicación «normal» no compensa. En nuestro caso, estamos desarrollando un smartclient con smartparts independientes que además tienen que ser personalizables y actualizables en caliente. Este es el escenario ideal para el binomio CAB-SCSF, y la verdad que a pesar de que cuesta un poco montar la infraestructura, y hay que soportar algunos casques del GAT, desde mi punto de vista, merece la pena el esfuerzo (en ese escenario concreto, claro).
Evelardiez:
El lado novedoso de la fuerza seductor es… Lo que comentas acerca de ser más productivos con la tecnología actual es cierto. Desde mi punto de vista, se es más productivo cuanto mejores prácticas se adoptan. Las buenas prácticas se pueden aplicar a lo bueno y a lo viejo, es un valor en el que siempre conviene invertir. Lo cortés no quita lo valiente… así que niños, antes de realizar flipadas como las que leeis en los blogs recordad que antes hay que supervitaminarse y supermineralizarse con buena lectura de los clásicos del desarrollo de software 😉
Saludos a los dos, y ¡gracias por mandarme vuestros comentarios!