Publicado SprintTracker v0.1

Efectivamente SprintTracker ya está aquí empaquetada y descargable. No esperes que te resulte muy útil aún, claro, es más bien una prueba de concepto. Tras completar la funcionalidad tal y como expliqué en mi post anterior sólo queda un lavado de cara visual a la aplicación y empaquetarla para que sea fácil de probar. En la siguiente captura de pantalla puede verse el resultado final, en concreto la pantalla con el listado de proyectos dados de alta:

Os explico cuales han sido los últimos pasos para crear la versión 0.1:

Mejorando el aspecto visual y la navegación

Según iba avanzando con el desarrollo de la aplicación me había preocupado bastante poco del aspecto visual de la misma y la navegación entre sus apartados. Simplemente había dejado la apariencia que se crea por defecto al ejecutar el script scaffold. El principal inconveniente de esta es que no hay ningún mecanismo para acceder de unas herramientas a otras (y SprintTracker tiene ya 5).

Así que lo primero que pensé fue en crear un primer menú. La cuestión es ¿dónde lo pongo? Leyendo uno de los artículos que tenía a mano vi que en Rails las páginas se construyen a partir de tres componentes visuales:

1. Layout: es el fichero que contiene la estructura de un conjunto de páginas. Se encuentran en la carpeta views/layouts
2. View: es el fichero que contiene el contenido principal de cada página concreta. Se encuentran en subcarpetas de views con el nombre del controlador asociado a la vista.
3. Parts: son ficheros incluidos, generalmente desde views usando el método <% render :partial => 'nombre_del_part' %>. Por convenio el primer caracter del nombre del fichero es un subrayado y la extensión es (por ejemplo _nombre_del_part.rhtml). Las parts se encuentran junto a las Views que las incluyen.

Aquí me encontré con el primer problema, para cada una de las herramientas se había generado en la carpeta view/layouts un layout diferente. Eso es un problema, porque si el menú es igual a todos ¿tengo que copiarlo a cada uno de los layouts? Eso viola el principio DRY (Don't Repeat Yourself) y por tanto no me hacía mucha gracia. Pero rápidamente leí la solución: basta con borrar todos esos layouts y crear una nuevo (copiando el contenido de cualquiera de los otros) llamado application.rhtml. Rails primero mira si hay un layout con el nombre del controlador que se ha invocado y si no lo encuentra busca siempre uno llamado application.rhtml. De esta forma creando este fichero es muy sencillo hacer que todas las páginas del portal tengan la misma apariencia, pero si hay alguna excepción se puede crear un layout para un controlador concreto.

Una vez determinado el fichero ya podía escribir el código HTML de la cabecera, el menú etc. Lo que quería era:

• Crear una apariencia más o menos decente (no soy diseñador, no le puedo pedir peras al olmo) pero muy poco sobrecargada
• Tener el código HTML lo más sencillo posible
• Poder cambiar la apariencia lo más posible usando CSS (para permitir a futuros usuarios de la herramienta adaptarla)

Con estos requisitos en mente me encajaba a la perfección usar el framework CSS de Mike Stenhouse que ha sido propuesto recientemente. La idea de este framework es proponer una estructura HTML concreta con unos nombres de identificadores y estilos CSS definidos que permitan representar cualquier página web normal. Gracias a las técnicas CSS soportadas a la gran mayoría de los navegadores es posible aplicar toda la apariencia a la página desde fuera del HTML. Este framework ha tenido repercusión en el mundo Java gracias al concurso propuesto por Matt Raible para crear apariencias para él.

En resumen, decidí seguir las guías de dicho framework CSS para SprintTracker y viendo los resultados me alegro de ello. Por un lado he perdido mucho menos tiempo de lo habitual maquetando el código HTML y por otro futuros cambios en la apariencia afectarán en la mayoría de los casos sólo al código CSS. En concreto siguiendo las guías de CSS modular del propio Stenhouse he dividido los CSS en componentes. En particular uno de ellos, _color.css contiene todas las definiciones de colores con lo que modificando sólo ese es posible cambiar todos los colores usados por SprintTracker.

Empaquetamiento

Uno de los aspectos que más me preocupaba cuando pensaba en implementar SprintTracker en Ruby on Rails era la dificultad de distribuirlo para que la gente lo probara. Yo pensaba "Si lo hiciera en Java, cualquiera puede instalar un tomcat y desplegar en él un WAR, o incluso puedo distribuir un tomcat con el WAR desplegado". Sin embargo mis temores se han convertido en nuevo reconocimiento hacia la comunidad de Ruby dado que me ha sido posible incluso crear un ejecutable autocontenido con toda la aplicación. ¡Más facilidad imposible!

Las herramientas que llevan a cabo la magia necesaria son tar2rubyscript y rubyscript2exe. Para instalarlas basta con ejecutar:

$ gem install tar2rubyscript
$ gem install rubyscript2exe

Una vez instalados aprendo a usarlas tal y como se explica en el artículo Distributing Rails Applications. El artículo es bastante nuevo (de hace 10 días) pero tiene bastantes imprecisiones, quizá porque habla de una versión antigua de Rails. En definitiva los que he tenido que hacer es ir al en el que hay un subdirectorio denominado SprintTracker que contiene toda la aplicación y ejecutar:

$ tar2rubyscript SprintTracker

Con este comando genero un fichero SprintTracker.rb que contiene toda la aplicación. Basta con tener Ruby instalado para poder ejecutarlo como ruby SprintTracker.rb. Me ha recordado a empaquetar una aplicación java en un jar y ejecutarla como java -jar app.jar sin embargo con aplicaciones J2EE no es tan fácil.

Pero ruby permite ir un paso más: puede incluirse el propio ruby en el paquete y crear un ejecutable. Basta con ejecutar:

$ rubyscript2exe SprintTracker.rb

Como inconveniente valga decir que esta herramienta genera un ejecutable que sólo funciona en la plataforma en la que se empleó. En mi caso para Linux (SprintTracker_linux).

En la generación de estos ficheros me he encontrado con dos problemas:

• No se incluía la dependencia con sqlite3 y por tanto fallaba al ejecutarlo en un ordenador que no lo tuviera instalado aparte. Creo que esto ya lo he corregido, pero agradecería al que pudiera probarlo que me lo confirmara.
• No me ha funcionado el sistema para sacar la base de datos fuera del ejecutable. Por ello esta versión 0.1 pierde los datos una vez se cierra. No me preocupa para esta primera versión, pero tenlo en cuenta: ¡no introduzcas datos reales que se van a perder

Debido a estos problemas de empaquetamiento he decidido marcar a los ficheros que he subido a RubyForge con la versión 0.1beta1. Os invito a todos los que estais siguiendo esta serie a descargarlos y probarlos:

SprintTracker v0.1

Toda realimentación será bienvenida y si alguien me sabe decir el porqué de los problemas estaré muy agradecido. También sería muy útil si algún Windowsero quiere generar el ejecutable para Windows y me lo envía para colgarlo también.

Conclusiones

La principal conclusión positiva de esta experiencia con Rails ha sido que a pesar de ser un lenguaje y un entorno totalmente nuevos en ningún momento me he atascado. Puede parecer poco importante, pero en realidad esto es clave para coger un ritmo de desarrollo muy rápido. Pensando en cómo consigue Rails esto se me ocurren las siguientes razones:

• Los mensajes de error son muy claros y proporcionan mucha información de contexto. Incluso sabiendo poco de Ruby y Rails encontré siempre el error en muy pocos minutos.
• Mucha consistencia: es fácil suponer cómo va a funcionar algo o el nombre de un método
• Se favorecen las buenas prácticas y al final redunda en tu beneficio
• Buena documentación: hay muchos tutoriales y http://api.rubyonrails.com es muy completo.
• Gracias a su simplicidad a la consistencia es posible tener en la cabeza cómo funciona la aplicación entera y esto permite avanzar con mucha mayor rapidez. Aunque claro, la aplicación es de momento muy sencilla.

En resumen mi impresión es que Rails está MUY pero que MUY especializado en desarrollo web y se nota en cada detalle el esfuerzo en facilitar la vida al desarrollador. Comparado con los frameworks más conocidos en J2EE me atrevo a decir que en el lado web es más completo que Struts y en el lado de persistencia es significativamente más fácil de aprender que Hibernate.

La versión 0.1 de SprintTracker me ha llevado unas 6 horas y media (más unas 12 horas de lectura de artículos y pruebas iniciales con Rails). Es muy poco tiempo para una aplicación web. Seguiré midiendo estos tiempos en las siguientes versiones a ver cómo evolucionan según la aplicación se complica. Los siguientes pasos son:

• v0.2: Pintar gráfica Burndown
• v0.3: Mejora significativa de usabilidad. Pantalla de inserción de todas las reestimaciones de un sprint tras la reunión diaria.
• v0.4: Cambios sugeridos por los usuarios: envíamelos como comentarios a este post, estoy deseando leerlos.
• v1.0: Ajustes, documentación y sitio web para el anuncio a la comunidad de SCRUM

Deseadme suerte ;)