lunes, 21 de junio de 2010

La rueda loca en una servilleta



Esto que algunos llamamos #laruedaloca de Hacer Historia, es una herramienta para diseñar la coordinación de las conversaciones necesarias para producir valor en mis clientes (donde el valor es un juicio de los clientes).

Con esta "simple" herramienta podemos descubrir espacios de acción que no teníamos en claro, pensar en los posibles quiebres que pueden ocurrir, cosas que pueden salir mal, darnos cuenta de qué cosas necesitamos pedir y a quien, ya que no se puede hacer todo solo.

Sin entrar en detalles me gustaría contar lo que hay en el medio de la rueda. La rueda gira en torno a las preocupaciones de mis clientes, que tienen que ver con:
  • Ver el negocio en dimensiones que hasta entonces no podía ver.
  • Entender mejor su negocio para conseguir objetivos particulares (bajar costos, expandir el negocio, aprovechar mejor los recursos, etc).
  • Contar con información clave a tiempo para tomar decisiones.

La esencia de mi oferta se basa en:
  • Agilidad.
  • Soluciones simples pero de alto valor p/el cliente.

Algo anecdótico es porque elegí una servilleta para hacer este ejercicio. Algunas razones:

Este post va dedicados a todos mis amigos de Hacer Historia, que me ayudaron con esta rueda y me mostraron posibilidades ahí donde yo estaba ciego.

saludos!

martes, 15 de junio de 2010

Generación de código, seguimos sin ver la luz?

En el pasado agile open de programación, junto con @claudiomeschini, @mariodallago y otra persona más que no recuerdo quien era, participamos de una sesión que los muchachos llamaron "Generación de código, seguimos sin ver la luz?" en referencia al maestro @ajlopez, alguien que para mi hace aportes muy interesantes a la comunidad. El material del encuentro lo pueden encontrar acá: http://www.agiles.org/agile-open-tour/ba-2010-coding/resultados

Hablamos sobre experiencias personales en el uso de generación de código p/construir aplicaciones y sobre temas relacionados. Voy a tratar de hacer un resumen de los temas que tocamos. Visiten el blog de Claudio, que en cualquier momento escribe algo también:

Experiencias personales de uso

Claudio comentó sobre su proyecto Quetzal de generación de código. Yo comenté sobre una experiencia de hace unos años usando AjGénesis en un proyecto real y la de hace unas semanas, donde a partir de un modelo muy simple, generamos una solución web mvc con las características que venimos usando últimamente (service layer, domain model, repository, log4net, structure map, manejo de errores c/páginas amigables, etc). También generamos los scripts de nAnt p/integración continua con cruise control y deploy automatico al ambiente de QA.

Modelos abstractos

Dijimos que algo destacable de la generación de código es trabajar con modelos abstractos. A partir del modelo, es posible generar código con una herramienta (ej: AjGénesis) o en runtime (ej: mapeos de nhibernate). De hecho hicimos extensible el concepto a no solo generar código, sino cualquier artefacto de texto como pueden ser script de base de datos, archivos de mapeo nhibernate, archivos de configuración, etc.

Una distinción importante para hacer en el modelo es separar el modelo de la tecnología o aspectos de implementación (como podrían ser paths, lenguage de programación, etc).

Algo interesante de AjGénesis es que el modelo se puede cargar de cualquier lado. Por ejemplo se podría cargar una parte del modelo a partir de las clases de una dll. Y luego completar ese modelo con más información, cómo por ejemplo que campos son requeridos p/armar un ABM.

Otra cosa que puede servir a la hora de diseñar un modelo es la de favorecer convención sobre configuración, para que sea menor la cantidad de cosas a definir en el mismo. Por ejemplo, podría asumir que todos los campos de mis entidades son requeridos y especificar puntualmente cuales no.

Mantenimiento

Uno de los problemas que a veces se presenta, es que después de generar el código surgen necesidades que me obligan a cambiarlo. Si el cambio lo hacemos directamente en el código, este gap es costoso de mantener y me pierdo de volver a cambiar el modelo y regenerar nuevamente.

Una manera de lidiar con esto vimos que es importante crear buenas abstracciones que separen la parte del problema que puede ser resuelta con generación de código, de la que no. De esa forma, hacer un cambio se traduce a modificar el modelo y volver a generar el código.

Cuando conviene usar generación de código?

Pregunta de respuesta fácil, depende... De qué depende? eso es más difícil de responder. La generación de código es una manera de automatizar tareas repetitivas, por lo que si hay algo que se repite muchas veces, podría considerarla como una buena opción.

Criterios de evaluación

Conversamos también sobre algunos criterios para evaluar una herramienta de generación de código:
  • El código generado debería ser el mismo que escribiría a mano sin usar la herramienta.
  • Una prueba ácida sería que a partir del mismo modelo, debería ser posible generar código para otra tecnología.
  • El modelo a definir debe ser libre.
  • Posibilidad de cargar este modelo de cualquier lado: xml, excel, txt, dll, tablas, etc.

Pueden ver mucha más información sobre este tema en el blog de @ajlopez:

saludos!
pd: este post salió hablando x twitter con @jfroma y @ajlopez