Tell, Don't Ask

Le verdad que me gustó mucho este post de uno de mis ídolos, Michael Feathers. Creo que este concepto es hasta casi más importante en Objetos que temas de Herencia y Polimorfismo (con esto me pueden llegar a enterrar) pero si, creo que esto es una de las cosas más importantes para diseñar en objetos (dependencias).
Creo que habría que tomarse el tiempo y probarlo de una manera bien extremista como para ver que sale y obviamente ver como encarar los mensajes entre los objetos y desglosar un poco (como dice Mark Miller) el concepto de "Tell".
No tengo más que decir por el momento sobre este tema, pero les aseguro que voy a ver que pasa yéndome a un extremo.

Ya es hora de mirar nuevos horizontes - Beyond Java

En dos semanas tengo planificado, junto con Gonzalo de Pedro y Andrés Calabrese, dar una charla con el objetivo de presentar técnicas y conceptos de programación que están cambiando a la industria del desarrollo de software y que Java, por ser la plataforma de desarrollo indiscutida, le cuesta adoptarlas aunque muchas veces se pueda.
Estaría dirigida a los profesionales que trabajan en java y quieren abrir sus mentes y ver como se están desarrollando el software en otras plataformas para luego traer esas técnicas al mundo java.
En principio los temas que se nos ocurren son los siguientes:

• Continuation
• Open classes
• AOP / Hooks
• Subject Oriented Porgramming
• Duck Typing
• Mix-in
• Clousures
• OOP con Prototipado (Javascript & Self)
• Domain Specific Languages
• Behavior Driven Development
• Conventions over Configuration
• Concurrencia con Earlang
• Behavioral completeness

Un poco la idea es abrirle la cabeza a los desarrolladores Java como para que vean que fuera de la burbuja java (empresarial) existen conceptos muy interesantes que le puede hacer la vida como desarrollador mucho más feliz y como dice DHH más productiva.

Si tienen alguna sugerencia, por favor no duden en comentar.

RadRails 0.9.1 - El Code Assist ya está funcionando

En el post anterior comenté que el Code Assitant del RadRails (Aptana) no estaba funcionando muy bien, bueno, antes de ayer bajé la nueva versión y ahora está funcionando bien, asi hagan el update, pero ojo que es una beta y para hacer el update hay que apuntar a otra URL, por favor lean aca como hacerlo.
Lo que si me dejó de funcionar, pero tenemos que investigarlo un poco más, es el tema de el output de los rSpec que venimos usando para diseño y test. El problema es que el output (a diferencia de xunit) antes lo tiraba a consola dentro del aptaba y ahora me lo tira a una consola de DOS que cuando termina de ejecutar se cierra sola... pero bue ya lo resolveremos.

Bill on Rails... segunda iteración cumplida

Hace un par de meses comencé junto a un grupo de gente de IBM un proyecto relativamente pequeño, que se encargará del manejo de ordenes de compra y seguimiento de facturas emitidas por los proveedores. Obviamente, este proyecto tiene otros dos objetivos:
- Implementar y aprender sobre Ruby on Rail y sobre todo el lenguaje Ruby
- Desarrollar el software de una manera iterativa incremental utilizando metodologías ágiles como Scrum y XP,
Luego de cuatro meses en donde estuvimos investigando, aprendiendo en conjunto y luego comenzando con el desarrollo de la aplicación tuvimos muy buenos resultados y me gustaría comentarle algunas cosas que venimos haciendo:

• Estamos usando Aptana como entorno de desarrollo que posee un plug-in muy copado para desarrollo de aplicaciones RoR llamado RadRails, este fue comprado (o algo por el estilo) por Aptana hace unos meses. Si bien todavía está un poco verde y no tiene mucho code assistance te da una mano bastante grande facilitándote la ejecución de los generators y las tareas rake. Aparte de permitir debug y syntax high-lighting.
• Como base del Aptana tambien estamos usando InstanRails que te instala de una todo el entorno Ruby, MySQL (con phpMyAdmin) y el Apache, en dos clicks tenes el entorno listo para comenzar a programar. No hay que olvidarse que al Aptana hay que apuntar al IntantRails para que tome el interprete Ruby.
• Como herramienta fundamental de comunicación estamos usando el Wiki, tenemos todo centralizado assets, tutoriales, backlog de requerimientos, direcciones de svn, estandares, arquitectura, release plan, build & deploy, etc, etc.
• Todo el manejo de Tareas e Issue tracking estamos usando la fantástica herramienta de Trac que nos permite mantener en un único lugar parte del SCM necesario para llevar a cabo el desarrollo, obviamente integrado con Mylyn y SVN. Realmente es una herramienta muy simple y que tiene todo lo necesario para asignación de tareas y defectos como así también su seguimiento.
  
• No hubo mucha discusión con la decisión de usar SVN para el versionado, es rápido, fácil de configurar, se pone atrás de un apache, lo que permite mantener la autenticación y autorización corporativa y se integra perfectamente con el eclipse y el Trac. En este ultimo punto, le pusimos un hook para no permitir commitear a menos que haya una tarea en estado "working" asociada.
• Uno de los Plug-ins que me está maravillando (gracias Andrés Calabrese) es Mylyn, la verdad que la gente que lo inventó realmente tuvo una idea genial debido a que no solo permite integrar las tareas del trac (o de cualquier issue tracking) en el IDE, sinó que también permite el uso de contextos lo cual aumenta la productividad minimizando la cantidad de información visualizada. Les recomiendo escuchar este podcast de 20 minutos en donde explica brevemente que es Mylyn y como utilizarlo.
• El Build & Deploy automático lo estamos encarando utilizando Capistrano y guiándonos con el nuevo libro de la serie de pragmatic programmers llamado "Deploying Rails Applications". Todavía no tenemos un entorno con Capistrano funcionando pero no falta mucho, cuando cierre voy a postear algo sobre el tema.
• La referencia obligatoria del lenguaje es este libro "Programming Ruby", la primera edición está abierta y es gratuita. No se que hablar mas de Ruby, realmente es un lenguaje que cada día me gusta más. En este post explico por que. Lo único que voy a agregar es que definitivamente antes de tirar líneas en Ruby, les pido por favor que lean, no se les ocurra programar como si estarían en Java.... no van a llegar a nada.
• El framework, Ruby on Rails, que les puedo decir... está muy bien enfocado y acotado a los que quisieron hacer, pequeñas aplicaciones web con bases de datos atrás. Lo único que me resulta un poco flojo es el tema de la concurrencia de migrations, si bien es una excelente idea, si no tenés cuidado se puede armar un con los mapeos a la base de datos, nosotros lo minimizamos tratando de poner un solo encargado para crear las migraciones, les pido que lean por que la idea es muy buena, todavía le falta madurar pero el approach está bueno. Todo lo que es ActiveRecord y AJAX, la verdad que me tengo que sacar el sombrero, Rails lo resuelve de una manera muy elegante, ya voy a hablar del tema.
• En cuanto al Diseño y Unit Test venimos usando técnicas de BDD (Behavior Driven Development) utilizando rSpec y el plug-in para rails de rSpec que realmente está bastante cerradito para lo que es la parte de Modelos (ActiveRecords). Resultó muy práctico e interesante empezar a escribir las especificaciones de los Modelos para empezar y luego a través de los generadores de rSpec para Rails creamos los modelos. Lo único un poco málo es que la documentación es bastante poca y siempre que te topas con un problema hay que arremangarse y tratar de solucionarlo y muchas veces se pierde mucho tiempo, pero bueh... es un costo que estamos asumiendo. Obviamente no solo estoy trabajando en esto, con lo cual cuando vuelvo a Java y a JUnit me quiero pegar un tiro :(
  

Me faltó hablar un poco de la metodología que usamos, pero prefiero terminar aca y escribir en otro post sobre esto ya que hace una semana también estuve involucrado en la definición de una metodología (ágil) para un proyecto un poco más grande y más importante que este :p