Alt-net Open Space Buenos Aires 2010

Finalmente se realizó el Alt-Net Open Space 2010 (#altnetba en twitter) en las cómodas y "remodeladas" oficinas de Microsoft de Argentina. Sinceramente fue un gusto encontrarse de nuevo con varios amigos de la comunidad y tambien "ponerle la cara" a muchos nombres que leemos en la lista de alt-net argentina y en alt-net hispano.
Acá les dejó algunos post que hicieron otros asistentes del evento.

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 :(