Generación de código, AjGenesis, y Dunga dunga a la tecnología

En un post mío


Sobre la generación de código


comentaba sobre AjGenesis y generación de código en general. En uno de los párrafos declaraba:


Dunga dunga un ratito

De alguna forma, un generador de código ideal no estará atado a una tecnología. Siempre habrá alguna “better mousetrap”, siempre alguien inventará alguna nueva forma de hacer algo, siempre habrá un ruso con insomnio, o un hindú sin novia, que no tiene otra cosa que hacer que crear algo nuevo, ya sea en forma de librería, framework, patrón, o estilo arquitectónico. Un generador de código debe ser agnóstico de la tecnología, de las modas, de las soluciones actuales y futuras.

El generador de código que adoptemos, debe poder adaptarse a lo que queramos hoy y mañana y pasado mañana. La estrategia es: no importa la tecnología, el patrón o el framework que aparezca, nuestro generador deberá aprovecharse de lo que surja. Es lo que llamo la estrategia “dunga dunga”: si aparece una nueva tecnología T1, le hacemos “dunga dunga” a T1, si aparece un nuevo framework PiruloStruts, adaptamos nuestras plantillas a aprovecharse de ese framework, “dunga dunga” a PiruloStruts. Es como un maestro de aikido: siempre habrá alguien más fuerte, sólo hay que utilizar la fuerza del otro, para vencerlo.


Un comentador Emmanuel escribía:


Un resumen y secciones mas especificas ayudarían (tienes que admitir que “Dunga dunga un ratito” es un titulo sobre el cual es difìcil sacar conclusiones :).


Bien, me refería a un viejo chiste, que no encontré ahora en la web, así que trataré de transcribirlo aquí, como pueda:


Resulta que un explorador se pierde en la selva, y ya exhausto, se encuentra con una tribu de indígenas, con caras de pocos amigos. Lo rodean, el que parece el jefe, se le acerca, y le despacha:

“Hombre blanco! Elige! Dunga dunga o muerte!!”

El explorador no entiende qué es eso de “dunga dunga”, así que acepta eso, antes que la muerte. Los miembros de la tribu sonríen, y le empiezan a dar al pobre explorador, de formas que éste no se lo imaginaba…

Lo dejan, y el explorador, maltrecho, sigue su camino, se encuentra con otra tribu, otro jefe, y la ya clásica frase:

“Hombre blanco! Elige! Dunga dunga o muerte!!”

El explorador, escarmentado, responde:

“No!! No dunga dunga de nuevo!! no!!! Prefiero la muerte!!””

El jefe asiente, pero se le acerca, le pasa brazo por el hombre, y con afecto y sonriendo, le dice:

“Bueno, muerte, pero antes… dunga dunga un ratito, eh?”


:-) :-)


A eso me refería cuando escribí ese post. AjGenesis, como generador de código, no está especializado en producir artefactos para una tecnología. No es como Xdoclet que sólo produce Java, o está muy orientado (por lo menos en sus comienzos) a EJB (Enterprise Java Beans).


No, lo que hace AjGenesis, es aprovecharse del conocimiento del programador o equipo de programación, de las tecnologías, frameworks existentes o futuros, y generar gran parte de una solución (o por lo menos la parte repetitiva).


Recordemos que AjGenesis puede partir de un modelo abstracto y generar artefactos de textos (que pueden ser una solución completa):


 


Notemos que puede haber más de un modelo inicial. En muchos de los ejemplos que publiqué, hay un modelo independiente de la plataforma (por ejemplo, que describe que nuestro sistemas tendrá departamentos, empleados, clientes, proveedores…) y un modelo de tecnología (que indica que vamos a usar tal base de datos, y tal lenguaje, y una interface web, etc..)


Pero también puede partir de la base de datos, y generar un modelo de base, que puede ser completado, ajustado, y usado más adelante la generación de código:



El modelo a usar es totalmente definible. Y las tareas y plantillas a usar, totalmente definibles. Si lo que Uds. necesitan, es generar aplicaciones con interfaz web, usando Struts 2, es cuestión de armarse las plantillas y tareas que generen ese tipo de solución. Si luego necesitan generar una aplicación en ASP.NET 3.5, con persistencia resuelta en NHibernate, de nuevo es cuestión de definir las tareas y plantillas adecuadas.


Pero si el día de mañana, aparece un nuevo ORM (Object Relational Mapper), o hay una nueva forma de implementar la persistencia, podemos “instruir” al AjGenesis para que genere los artefactos de textos que necesitemos.


Ya he publicado ejemplos, explicaciones de todo esto en


Posts sobre AjGenesis


desde una explicación de Hola Mundo:


Generando Código- Hello World con AjGenesis


hasta aplicaciones completas en distintas tecnologías:


Generando aplicaciones con AjGenesis


En esos ejemplos, el modelo se define en archivos XML, pero también pueden tomarlo desde texto:


Modelo textual para generación de código con AjGenesis


y desde otras fuentes menos convencionales:


AjGenesis- Modelo desde la Base de Datos


AjGenesis- Modelo generado desde los assemblies


Si hasta pueden implementar una solución web que genere código para cualquiera que lo necesite:


Code Generation as a Service


Así que no tienen excusas: no pueden quejarse de que no les avisé, o que me encanuté, oculté algo bajo la manga. Tienen todo eso disponible desde hace años. Sólo falta poner cabeza y cerebro, en descubrir los modelos de base que necesitamos, y escribir las tareas y plantillas. Recomiendo siempre partir de una aplicación de ejemplo, que resuelva lo que Uds. necesitan, usando la tecnología que hayan elegido, y desde ahí, ir construyendo las tareas y plantillas que necesiten.


Como siempre aclaro, no toda la aplicación puede crearse por generación de código. Pero se pueden aplicar técnicas, como generar desde el modelo que elijamos, sólo algunos artefactos de texto, y otros, los generamos manualmente.


Lo interesante, es que así, cuando pasen las tecnologías, cuando aparecen nuevas, podemos reaprovechar nuestro conocimiento anterior, al haber definido un modelo que describa nuestro problema, y luego, al conocer una nueva tecnología, y cómo resolver los mismos problemas de otra forma, podemos generar código para la nueva forma de hacer las cosas.


Yendo a un ejemplo concreto. Desde hace décadas, estamos haciendo ABM (Altas, Bajas y Modificaciones) de valores, como países, provincias y demás. Cuando resolvimos eso en Visual Fox, un cliente nos pidió hacerlo en ASP clásico. Cuando resolvimos eso en ASP clásico, otro cliente nos pidió eso en ASP.NET, o en JSP o en JSF (JavaServer Faces) o en lo que aparezca mañana. Pero el problema a resolver es el mismo: mantener una lista de valores. Si luego cambia la tecnología, cambia la solución a aplicar, pero el problema inicial se mantiene. En AjGenesis, podemos definir un modelo independiente  de la tecnología (por ejemplo, definiendo las entidades que tenemos que manejar, como Cliente, Factura, Remito, etc… y sus relaciones), y por otro, instruyendo sobre qué tecnología usar (aportando uno o varios modelos dependientes de la tecnología), como ASP.NET, ASP.NET MVC, WCF, JSP, JSF, Struts 1 o 2, etc…


Otro camino hubiera sido lo que muchos de nosotros encaramos: hacer nuestro propio framework. He visto muchas consultoras de software, “casarse” con una tecnología (ej. Visual Fox), estudiarla, armar un framework sobre ella (que resuelva los problemas clásicos, como ABMs, seguridad, autorización, validaciones, etc…) y luego ver cómo, ese trabajo de años, se diluye, porque la tecnología cambia.


Si nosotros elevamos el nivel de abstracción, identificamos los problemas a resolver (ABMs, listas, buscadores, seguridad, procesos, validaciones, reglas de negocio), y luego los resolvemos en una tecnología (ya sea viendo código de ejemplo, armando nuestros propios ejemplos, et…), podemos describir ese mapeo de problema a solución concreta, usando las tareas y plantillas de AjGenesis.


Como ejemplo: cuando comencé con el proyecto, no existía ASP.NET 2.x. Sin embargo, los modelos que construí como ejemplos de base, pudieron ser usados para luego generar aplicaciones de ASP.NET 2.x. Actualmente, en un proyecto, estamos adaptando conocimiento previo, para generar código sobre .NET y Mere Mortals Framework. Y el modelo que construimos, fácilmente podría ser reusado para otras aplicaciones, y otras tecnologías,como Clipper o COBOL, hasta ASP.NET MVC o Wicket. El construir el modelo, pone de manifiesto qué es lo que queremos resolver, los problemas básicos, que terminan expresándose de forma independiente de la tecnología de moda, o el framework popular del momento.


Y aunque usemos una sola tecnología, el ejercicio de definir el modelo, definir las tareas y plantillas, aporta una clara separación entre lo abstracto, y lo que llamo las “technicalities”, los detalles técnicos de implementación, que el día de mañana pueden cambiar.


Entonces, no importa la tecnología: AjGenesis le puede hacer dunga dunga a la tecnología que venga. Si Uds. creen que la tecnología que Uds. usan actualmente, va a durar para siempre, lamento desilusionarlos. Vean la historia de la programación, los últimos 30 o 50 años, y verán que lo único permanente es el cambio.


Nos leemos!


Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
http://www.facebook.com/ajlopez

This entry was posted in 1389, 1390, 2643, 3463, 6145. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>