Dominando el Dominio?

Katayunos de febrero

2011-03-01T08:54:00.005-03:00

El 17 y 25 de febrero pasado tuve la suerte de participar en la organización de dos "Katayunos". El primero lo realizamos junto con un grupo de amigos (Mario Dal Lago y Francisco Larramendi) en un bar de Buenos Aires, donde degustando unas ricas medialunas llevamos adelante una "kata" de "StringCalculator". El segundo lo realizamos en el laboratorio de Grupo de Usuarios Microsoft(MUG), (el próximo será el 29 de marzo) junto a Ariel Cen, Alejandro Nelis y Carlos Peix.

Para quien no conozca lo que son los "katayunos", les cuento que es una reunión, inspirada en los "coding dojo", donde un grupo de programadores nos juntamos a escribir código para resolver un problema (o sea la "kata"), y a la vez desayunamos. El acento no está puesto en resolver un problema complejo, en general son muy sencillos, sino en practicar pair-programming y TDD. La idea es ir adquiriendo una "gimnasia", que nos acostumbre a incorporar estas prácticas, como movimientos naturales, a nuestra programación diaria, al estilo de las "katas" en las artes marciales.

Las ventajas que le encuentro a los "katayunos" es que son reuniones que organizarlas cuesta muy poco, solamente se necesita combinar un lugar de encuentro como un bar y un par de notebooks, y que nos permite aprender e intercambiar experiencias con programadores que quieren innovar y mejorar la calidad del software que construyen diariamente. Por otro lado la escala no condiciona su realización, ya que con dos personas ya le da sentido a la reunión.

Acá les dejo un video de la comunidad ágil de Buenos Aires sobre la realización de un "randori coding dojo" con una explicación más detallada del sentido de estas prácticas.
Y una "traducción" de la kata de "String Calculator"

Are you ConfORM? Yes!!!

2010-03-23T18:56:00.006-03:00

Fabio volvió a hacerlo(cfr. NHValidator, SharpTestEx), y nos voló la cabeza con un espectacular código para olvidarnos de los .hbm, y mapear directamente nuestras entidades a la BD sólo escribiendo lo mínimo indispensable.
ConfORM, que así se llama el proyecto, es (entiendo) un framework para CONFigurar desde código el ORM NHibernate, sin necesidad de utilizar los archivos XML, y aprovechando las nuevas funcionalidades de NH 3.0. Pueden saber más de como usarlo visitando su blog o escuchando la VAN que dio en altnet.hispano.
Pero a que viene todo este cuento?
Es que estuve trabajando en mi framework Quetzal para implementar una "extensión" (no son extensiones de .net) que use ConfOrm en lugar de AutomationNH( o NHGenerator) , ya que el espiritú es el mismo, pero ConfOrm esta mucho mejor resuelto, y posee como ventaja el amplísimo conocimiento que tiene su autor sobre NH y el manejo de BD en general.
El cuento viene entonces debido a que, luego de "bucear" en el código de ConfOrm, y de preguntarle algunas cositas al "bueno" de Fabio, pude implementar la extensión, y parece que todo funciona.
Así que el código esta subido como para empezar a probarlo.

Documentación ágil y Open Source

2010-03-23T17:58:00.006-03:00

El pasado sábado 13 de marzo participé del Agile Open Space 2010 en Buenos Aires que organizó la gente de Agiles de Argentina. Demás esta decir, que fue una experiencia muy productiva y enriquecedora, no solo desde el punto de vista técnico sino humano también.
En una de las charlas en que se dividio el Open Space, se tocó el tema de la documentación de un proyecto "ágil". La motivación de quien había propuesto el tema provenía de que estaba trabajando, junto con su equipo, en un proyecto como consultor externo, y terminado este deberían transferirle las capacidades para que un equipo interno de la empresa lo siguiera desarrollando.
Esto disparó una serie de propuestas desde armar videos con entrevistas a los propios desarrolladores, como demos para mostrar el deployment, hasta distintos tipos de gráficas, o infografías que explicaran la "metafora" del sistema que estaban desarrollando. Todas propuestas que implicaban dejar mucho más que un "Manual del usuario", y que apuntaban a tratar de "explicar" en un nivel de mayor abstracción, lo que el código decía.
Pero una de ellas me quedo picando en la cabeza, y fue la idea de escribir un blog con las decisiones de arquitectura que vamos tomando en el día a día, porqué usamos esta opción y desacartamos otras, o porque el surgimiento de un nuevo requerimiento implico cambios, etc.
Y esto me pareció muy aplicable al escenario que presentan los proyectos "open source", donde también se necesita tranferir el saber de un proyecto a personas que no han trabajado en él. Y pongo el acento en esto, porque creo que una de las grandes dificultades para que no haya más personas en proyectos "open source" es lo difícil que resulta iniciarse en uno, es decir tener un nivel de conocimiento mínimo de lo codificado, entender la "metáfora" de quienes lo diseñaron, y como eso impacto en el código.
Ya sabemos que arduo es, escribir la documentación de cualquier proyecto, quizás este sea un mecanismo "ágil" para lograrlo, ya que no solo ayudará a los "newbie", sino a nosotros mismo cuando volvamos 2 años despues a modificarlo :(

Quetzal finalmente disponible

2009-01-12T23:54:00.001-02:00

Luego de un año ajetreado, finalmente he liberado el código de Quetzal bajo una licencia GPL. Lo pueden descargar de aquí.

Varias fueron las razones por las que tarde tanto en liberar este framework, pero la principal era que en la primeras versiones era arduo de configurar y de extender, cosa que lo hacía muy improductivo. Por suerte, Quetzal ha cambiado mucho internamente, desde esas primeras versiones principalmente para facilitar su extensibilidad.

Es así que Quetzal es un framework "orientado a la generación de código", ya que si bien fue pensado para resolver varios de los problemas que se presentan al trabajar con la generación de código, su capacidad de mantener el "modelo" en memoria permite que funcione como una "extensión" de las clases del dominio agregando propiedades y métodos de forma dinámica.

Quienes bajen el código tendrán entre sus manos lo siguiente:

El "core" de Quetzal que es "ModelDescriptor" y tres extensiones,
AutomationNH tambien conocida como NHGenerator que permite generar los .hbm a partir de las clases del dominio.
ModelToArtifact (M2A) que implementa un mecanismo para la manipulación y la administración de la generación de código
y Validator que como su nombre lo indica implementa validaciones usando como validadores específicos los de EntityLibrary 3.1

Pueden seguir como ejemplo los test, para el caso de M2A y Validator, y el sample para el funcionamiento de "NHGenerator". Se que los ejemplos son pobres pero mi idea es tener una demo y "alguna" documentación que integre todo próximamente.

Espero sus comentarios y que les sea útil.

ASP.NET MVC II : Recursos

2008-04-14T00:57:00.003-03:00

Como les conté estoy trabajando con Asp.Net MVC y como todo proyecto en ejecución carece de muchas funcionalidades y recursos que nos facilitan las cosas para construir aplicaciones del mundo real. Si aparte trabajan con Visual Web Developer 2008(VWD2008) como es mi caso, la cosa se complica un poco más, ya que el CTP 2 no soporta el tipo de proyectos que se manejan con esta IDE. Así que mi idea es compartir con Uds. algunos recursos que me resultaron de mucha ayuda y un pequeño aporte de mi parte.

Thinking in .NET blog con traducciones al castellano de importantes referentes de .net, sobre sus ultimas tecnologías. Entre las traducciones figuran el tutorial de MVC de Scott Gutthrie.
Un template de una aplicación de Asp.Net MVC CTP 2 para utilizar con VWD 2008. Esencial para nuevos proyectos. Si ya venias trabajando con el CTP 1 te simplifica la migración.
MVC Contrib - MvcContrib.org un importante proyecto de la comunidad para aumentar la funcionalidad del framework. Varias cosas muy interesantes (IOC, helpers, templates, NHaml para los que conocen RoR, etc). No lo use todavía.
ASP.Net MVC Membership Starter Kit esta implemetación para MVC solo funciona en proyectos bajo VS2008. Se puede usar tambien con OpenID. Podrán hallar aquí (svn) una adaptación del codigo fuente de mi autoría para Visual Web Developer 2008.
El blog de Fredrick Normén con ejemplos de programación avanzada.

Bueno, espero que a ustedes les sirva también .

ASP.NET MVC I : RenderComponents y bugs

2008-04-10T20:04:00.010-03:00

Estoy desarrollando desde el fin del año pasado un proyecto que usa Asp.Net MVC. Demás esta decir las bondades de la nueva arquitectura.
Recientemente se lanzó el CTP 2 que trae una serie de mejoras, muchas basadas en las recomendaciones de la comunidad, y tambien se puede ver el código fuente (sic) ;).
Para los conocedores de MVC, especialmente de MonoRail, entre las mejoras se encuentra la utilización de "ViewComponents", pero como toda tecnología que esta "verde" trae sus bugs.
Es así que me cruce con uno de estos "bichitos" que es comentado en este post
y cuyo autor plantea el "core" de la solución, y tambien propone una solución más general pero sin código. Mi humilde aporte va en este sentido, es decir aqui les dejo el código mas general que permita avanzar hasta el próximo CTP. La funcionalidad se implementa mediante "extensions" (.net 3.5) de la clase ViewPage:

Y lo utilizamos en las .aspx así:

....

...

Bueno la seguimos en el próximo post.

NHGenerator ve la luz

2008-03-08T03:19:00.004-02:00

Para aquellos que les aburre como a mí escribir los mappings de nHibernate, deje una demo tan temprana, que casi es una prueba de concepto, de NHGenerator, una herramienta que espero evolucione, guste y fundamentalmente acorte nuestros tiempos de desarrollo.
NHGenerator es una herramienta que esta inspirada por las mismas ideas que exprese cuando presente a Quetzal, y que las podrán leer en post anteriores aunque bajo el nombre de Automation.NH.
Utilice para la demostración los test del proyecto uNHAddins , indispensables para encarar cualquier proyecto con NHibernate.
Hasta ahora he implementado los test que implicaban los mapeos mas básicos "Master-Detail", "one-to-one", "many-to-one" y "component", quedando como paso importante los mapeos de herencia.
Cabe aclarar tambien que no he tenido tiempo todavía de probarlo en dominio "complejos".
Espero sus comentarios.

Prism y nuestro IDE

2007-11-17T21:04:00.000-03:00

Me entere que Mozilla había "relanzado" una especie de "Firefox-light", es decir un Firefox que permite correr un solo sitio , impidiendo la navegación por otras urls. La aplicación se denomina ahora "Prism", y antes era conocida como "WebRunner".

Leyendo sobre las ventajas (menor consumo de recursos, mayor seguridad, etc.) se me ocurrió que podía ser el compañero ideal de nuestro "IDE" para desarrollar sitios web y no esperar tanto cada vez que "recargabamos" el proyecto. Así que lo puse a prueba con VS2005 y anduvo bárbaro, cargando como esperaba "muchísimo" más rápido el proyecto para debuguear.

Para hacerlo procedan así

Generen un "Acceso directo" con Prism con el URL de su aplicación por ej: "http://localhost:4401/Website/Default.aspx".
luego tomando de la hoja de propiedades del Acceso Directo que genero Prism los valores del campo "Destino"

configuren en las opciones de Inicio en el menu WebSite de VS2005, poniendo en este caso en el campo de
"Start external program": C:\Archivos de programa\Prism\prism.exe
y en el campo "Command line argument": -webapp TestPrisma@prism.app
Aplicar, y listo.

Agradecimiento y deuda

2007-09-03T13:27:00.000-03:00

Hoy abro el correo de la lista de arquitectura del MUG y encuentro el post que escribío Angel sobre la charla que dio el viernes y que ya les comente . Y me llevé la grata sorpresa de ser citado en él, y en su blog, lo cual le agradezco.
Próximamente subire una version mejorada de "templates compilados" para aclarar un poco màs el asunto

Templates compilados?

2007-08-31T13:59:00.000-03:00

Hoy, luego de asistir a una charla en el "MUG" dictada por el "maestro" Angel sobre generación de código y su excelente "ajgenesis", me quede "tildado" en la relación entre templates, código "vivo" y su actualización de forma dinámica. Ya que uno de los grandes problemas de la "generación de código" es la actualización del código generado, sobre todo si estamos produciendo software de una forma incremental. O sea, si actualizamos el "template", como "brodcastiamos" o difundimos eso en el "código" ya generado, y por sobre todo no pisamos el "ajuste fino" que hicimos sobre él.

Por otro lado, habitualmente para generar un template en alguna herrmienta de generación de código lo que hago es reemplazar las partes "variables" de un codigo en el lenguaje original que estoy trabajando y lo reemplazo por los token que me da el generador. O sea algo así:

"EditPersona" se transforma en "Edit${NombreEntidad}".

Esto implica abrir el notepad buscar "Persona" y reemplazarlo por "Edit${NombreEntidad}". Esto sucede cada vez que cambio mi código "fuente", o sino debo agregar a "pelo" en el template lo que modifique sin garantía de que este código este compilado. Demás esta decir que si son muchas las variables a reemplazar y muchos los templates a actualizar el trabajo se torna largo, y tedioso.

Lo ideal sería entonces que:

El template "compilara".
Que en el proceso de re-generación no pisará nuestro "ajuste fino".

Lo que les dejó aquí es una especie de "prueba de concepto" que me gustaría profundizar con la opinión de ustedes. Solamente atacá el primer problema, ya que es un mero ejemplo que más que ofrecer una solución lo pongo para explorar una idea. Esta realizado simplemente con NAnt y algún "truquillo" en el código c#.

Para usarlo simplemente tenemos que respetar que las variables/string que queremos reemplazar empiezen con "_" y terminen con "0", (se pueden elegir otros que c# permita) , lanzar el build de NAnt (GeneraEntidad) y luego recargar el proyecto. El único problema es que deberán comentar el código de cada generación de entidad ya que NAnt NO "puede"!!! sobreescribir sus propiedades.

Los comentarios estan abiertos para opinar

Presentando a Quetzal

2007-08-16T18:13:00.000-03:00

Como dijimos en el blog introductorio Quetzal es un framework de librerías de mi autoría, realizado en c# que consta de dos capas:

La capa de descripción del modelo (Model Descriptor): que comprende las clases que describen el modelo inferido a partir de las clases del dominio. El cual puede ser "refinado" desde el evento Init.
y la capa de automatización que comprende las librerías que generan distintos artefactos de nuestra aplicación. De esta capa solo desarrollé dos librerías:

Automation.UI: para la generación de pantallas.
Automation.NH: para la generación de los .hbm para NHibernate.

Quizas una imagen describa mejor lo dicho:

Existe una tercera capa de servicios, que no aparece en el gráfico, y que por ahora sólo contiene unas tareas en NAnt que permite ejecutar unos templates de NVelocity inyectandole el modelo descripto.
Vale la pena decir que si bien esta es mi cuarta version de las librerías, (hace casi un año que empecé) estas continuan aún en un estado beta en el caso de Model Descriptor y Automation.UI y en un estado alfa Automation.NH.

Introducción a Quetzal

2007-08-15T18:31:00.000-03:00

El surgimiento...

Hace varios años que vengo girando alrededor del tema de ser "productivo" en mi trabajo, y a su vez me aburre mucho "copiar y pegar" código y luego reemplazar, para hacer aplicaciones nuevas, sin hablar de los riesgos que esto implica. Así es que siempre he tratado de construirme algún framework, o herramientas que me ayudaran a evitar esta tediosa tarea.
Unos de mis primeros intentos fue por Marzo del 2002 con un proyecto de "generación de código" que se llamo "GenClases" y que realice en VB6 + XML + XSLT. Demás esta decir que fracasé en tanto que debía escribir las XSLT(o sea los templates) para hacer las transformaciones. Un trabajo que luego de cierto grado de complejidad se torna "inhumano".
Luego vino .Net, c#, CodeSmith, MyGeneration, NHibernate, Patrones, DDD, ASP.NET 2.0, AJAX etc. por lo que pasó un tiempo hasta que logre reacomodar la cabeza para insistir con el tema y finalmente pude volver a la tarea de hacer algo que me ayudara en la generación de mis aplicaciones.

Pero... que es Quetzal?

Quetzal es un framework de librerías desarrollado en C#, que junto a otras herramientas como NAnt y NVelocity, permite la creación de aplicaciones y sus multiples artefactos, a partir del código escrito para las clases del dominio de la aplicación.

Algunos antecedentes

Es dificil entender el "punto nodal" de Quetzal sin ver un panorama de las herramientas de "automatización" para la generación de aplicaciones.
Una primera aproximación es la de los "generadores de código". Angel "Java" López ha escrito muy, mucho y bien sobre el tema (y en castellano para colmo) lo que me ahorra de escribir unos buenos párrafos sobre esto.
Pero tambien hay frameworks, como "MonoRail" que van más allá de la generación del código y parte de su "trabajo" lo realizan de forma dinámica o en "runtime" como en el caso de la generación de los .hbm de NHibernate con "Castle ActiveRecord".
Otra mirada del asunto la encontrmos en "Naked Objects" para el mundo Java, con su "futura" versión optimizada para .net, donde solamente debemos escribir "una" capa (la del dominio) para tener la aplicación hecha. Y no sigo más para no aburrir y porque con esto me alcanza para marcar algunas diferencias en la visión de Quetzal.
Queda sin embargo un tema importate en todo esto : LOP o "Lenguajes Orientados a la Programación", una especie de "esperanto" para programar, pero me referiré a esto más adelante .

Los problemas de estos enfoques

En la mayoría de las estrategias de los "generadores de código" el modelo esta separado de la aplicación, siempre hay una metadata que define al dominio de la aplicación que es distinta del codigo de las clases, siempre debe sucederse una transformación con el consiguiente problema de el "gap"(distancia) posible entre el modelo de la metadata y el modelo de la aplicación. A esto debemos sumarle que pasa con el código "nuevo" agregado, ante una nueva generación, "partial class" y herencia juegan aquí su rol para garantizar la "sincronía", que si no esta prevista implica "fuertes" dolores de cabeza.
En cambio los frameworks como Mono Rail, tienen el problema de que estan "atados" a una "arquitectura" y en este caso tambien a una tecnología (NHibernate con ActiveRecord), entiendo que su uso no es excluyentes, pero implican un costo y pierde algo de la gracia de su uso.
El enfoque en cambio de Naked Object, que es el que más me simpatiza en términos de "productividad", implica escribir el dominio de una forma "extraña", definiendo las clases del dominio con los tipos que propone el framework, pudiendo implicar que ciertas actualizaciones del lenguaje impliquen la actualización previa del framework para su utilización. Tambien tiene su costo en el entrenamiento, si trabajamos con personas no entrenadas en el framework

Que sería entonces lo deseable de un generador de aplicaciones?

Poder escribir el modelo en el mismo código de la aplicación.
Que no implicara acoplamiento alguno con una determinada tecnología.
Que no usara otro tipo de clases para definir el dominio que nos impidan reutiliazar lo ya codificado y que la curva de aprendizaje sea leve.
Que no usen bases de datos para inferir el modelo, evitando así la impedancia entre objetos y tablas.

En la próxima entrada les presento a Quetzal.

Extendiendo las propiedades de una clase dinámicamente

2007-08-15T17:57:00.000-03:00

El otro día estaba tratando de pasar parametros de una forma "muy" desacoplada, pero con cierto "rigor" y salio esto. No se que tan correcto sea, pero lo comparto por si a alguien le sirve.

/// <summary>
/// Parametros para extender dinámicamente las propiedades
/// </summary>
Dictionary<string, object> _parameters = new Dictionary<string, object>();
public void SetParameter<T>(string name, T value)
{
if (_parameters.ContainsKey(name))
_parameters[name] = value;

else
_parameters.Add(name, value);
}

public T GetParameter<T>(string name)
{
try
{
if (_parameters.ContainsKey(name))
return (T)_parameters[name];
else
throw new Exception("El parametro solicitado no existe");
}
catch
{

}
return default(T);
}