Katayunos de febrero

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!!!

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

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

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

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

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

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.