jferrer's blog

Pruebas unitarias y de persistencia en Ruby on Rails

Wed, 26 Apr 2006 20:05:52 +0000

Uno de los aspectos que me ha sorprendido más gratamente de Ruby on Rails es la facilidad para hacer pruebas de una aplicación web a todos los niveles.

En el entorno J2EE no he acabado de encontrar herramientas de pruebas que cubrieran todas las necesidades del desarrollo de aplicaciones web. Para pruebas unitarias JUnit o sus competidores están muy bien, pero cuando te sales de ese terreno las cosas no están tan claras. En particular los entornos para llevar a cabo pruebas funcionales provocan que estas supongan un coste considerable.

En Rails tenemos el equivalente a JUnit+dbUnit+HttpUnit+Cactus+Jameleon y todo ello perfectamente integrado. Así da gusto :) El único pero que le pongo son los nombres que han dado a los distintos tipos de pruebas y que resultan bastante engañosos.

En esta entrada del blog comienzo explicando las pruebas que Rails denomina unitarias y que incluyen tanto a las realmente unitarias como a las pruebas de las clases de modelo Active Record. Estas últimas no son puramente unitarias, dado que dependen de que esté disponible una base de datos con determinada información en ella.

Pruebas de presistencia con Fixtures

Las primeras no tienen ningún misterio para las que hayan usado JUnit así que centrémonos en las segundas. Para ellas, Rails proporciona el sistema de Fixtures que permite definir los datos que deben estar presentes en la base de datos antes de la ejecución de la prueba. La forma de definir estos datos es mediante un fichero con formato YAML por cada clase del modelo. Todos estos ficheros se almacenan en el directorio tests/fixtures. Por ejemplo en SprintTracker los ficheros tests/fixtures/sprints.yml contiene:

La hora de la verdad con Ruby on Rails

Mon, 10 Apr 2006 21:51:05 +0000

La versión 0.1 de SprintTracker contenía únicamente funcionalidades típicas de los artículos de Rails. La hora de la verdad ha llegado al proponerme implementar las funcionalidades que había sugerido para la versión 0.2 y 0.3. Las más importantes son:

Gráficas Burndown de los sprints
Reordenación jerárquica de las páginas de administración de proyectos, sprints y tareas. Esto ha permitido mejorar mucho la usabilidad de SprintTracker
Páginas de edición rápida para añadir todas las reestimaciones de un día concreto o para una tarea concreta. Esto es fundamental si, como estoy haciendo yo últimamente, usas una hoja excel para llevar el seguimiento del proyecto
Otras mejoras menores: borrado en cascada de proyectos, sprints y tareas, validación a medida de reestimaciones (no puede haber dos para la misma tarea y día), etc.

En la captura de pantalla se muestra la vista de un sprint en la que se aprecian varias de estas funcionalidades.

Tras implementar estas funconalidades he liberado SprintTracker v0.3 y creo que ya empieza a ser una aplicación lista para ser usada. Para ellas no había ningún artículo que me guiara y ello me ha obligado a aprender mucho más sobre Rails y sobre todo a manejarme con las referencias online imprescindibles para todo desarrollador de Rails:

Peculiaridades de Ruby para desarrolladores Java (parte 2)

Tue, 04 Apr 2006 12:09:27 +0000

Continuando con la entrada anterior sigo explorando los aspectos de Ruby mas peculiares para un programador que viene del mundo Java.

Closures

En los artículos de autores relacionados con el mundo de los métodos ágiles es habitual oir hablar de lenguajes que soportan closures. Pues bien, tengo que reconocer que aunque creía haber entendido bien el concepto lo cierto es que al menos no lo había asimilado. Usandolo con Rails por fin lo he conseguido, así que ahí va mi intento de explicar lo que son:

Un closure puede verse como un bloque de código que se sitúa en paralelo al del método y al que éste puede pasarle el control cuando crea conveniente usando el método yield()

Un ejemplo típico de uso podría ser un método que itera por un árbol y realiza una acción con cada nodo. En Ruby es posible pasar al método (al que llamaremos iterateTree) un fragmento de código que será el que realice la operación sobre el nodo. Por ejemplo, la invocación del método para imprimir cada nodo podría ser:

  tree.iterateTree do |node|
     puts "Iterating node: " + node
  end

El fragmento de código entre do y end recibe el nombre de closure. El método iterateTree invocará el closure usando el método especial yield:

Peculiaridades de Ruby para desarrolladores Java

Sun, 02 Apr 2006 16:22:31 +0000

Durante estos días en que he estado aprendiendo Ruby y Rails para desarrollar SprintTracker 0.1 me he ido encontrando diferentes elementos de sintaxis que me han sorprendido, confundido o incluso disgustado (al menos inicialmente). He pensado que podía ser buen idea revisarlos porque creo que conociéndolos resulta mucho más fácil entender los fragmentos de código presentados en la mayoría de artículos sobre el tema. Como son bastantes cosas lo voy a dividir en dos entradas del blog.

Llaves y paréntesis opcionales

En Ruby los paréntesis y las llaves (() y {}) pueden omitirse cuando son obvios. Por ello en Rails es habitual encontrar invocaciones a métodos de la forma:

  nombre_método parametro

Que es equivalente a :

  nombre_metodo(parametro)

Cuando un mapa (hash) es el último parámetro de un método las llaves pueden ignorarse, así que uniendo esto a lo anterior es habitual encontrarse llamadas a métodos de la forma:

  nombre_metodo primer_parametro, :clave1 => "valor1", :clave2 => "valor2"

Que es equivalente a:

  nombre_metodo(primer_parametro, {:clave1 => "valor1", :clave2 => "valor2"})

Y que un programador Java escribiría como:

  Map segundoParametro = new HashMap();
  segundoParametro("clave1", "valor1");
  segundoParametro("clave2", "valor2");
  nombreMetodo(primerMarametro, segundoParametro);

Publicado SprintTracker v0.1

Thu, 23 Mar 2006 22:52:54 +0000

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:

Layout: es el fichero que contiene la estructura de un conjunto de páginas. Se encuentran en la carpeta views/layouts
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.
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

Relaciones entre entidades y validación en Rails

Thu, 23 Mar 2006 11:46:26 +0000

Lo prometido es deuda y tal y como comenté en el post anterior hoy toca explicar el resto de pasos que me han llevado a implementar la funcionalidad de la primera versión de SprintTracker funcional.

Estos han consistido en la creación de las herramientas de gestión de Proyectos, Sprints, Tareas y (re)Estimaciones con las oportunas relaciones entre estas entidades. Después he añadido un poco de validación (muy fácil, ya lo verás).

Proyectos, Sprints, Tareas y estimaciones

En el último post concluía que parece preferible usar la generación de código por script cuando vas a tener que modificar el resultado así que en esta ocasión lo uso directamente. Eso sí, lo primero es crear el modelo de datos. Lo hice en dos pasos en los ficheros 003_add_projects_and_sprints.rb y 004_add_tasks_and_estimates.rb, creados ejecutando:

$ ruby script/generate migration add_projects_and_sprints
$ ruby script/generate migration add_tasks_and_estimates

Muestro la parte más interesante de su contenido (el código de self.up)en ese orden:

    create_table "projects" do |table|
      table.column "name",:string,:limit=>128
      table.column "description",:string
    end
    create_table "sprints" do |table|
      table.column "target",:string
      table.column "start_date",:date
      table.column "duration", :int
      table.column "project_id", :int
    end

    create_table "tasks" do |table|
      table.column "name",:string,:limit=>256
      table.column "description",:string
      table.column "user_id",:int
      table.column "sprint_id",:int
      table.column "initial_estimate", :int
      table.column "real_effort", :int
    end
    create_table "estimates" do |table|
      table.column "reestimation_date",:date
      table.column "reestimation", :int
      table.column "task_id", :int
      table.column "is_going_well", :int
      table.column "explanation",:string
    end

Es importante fijarse que las claves extranjeras deben seguir un convenio de nombres. Por ejemplo en estimates la columna task_id apunta a tasks y por ello debe llamarse como la tabla a la que apunta en singular seguido de _id.
Para cada uno de ellos apliqué los cambios a la base de datos con:

$ rake migrate

Y ya estamos listos para generar el código:

$ ruby script/generate scaffold Project
$ ruby script/generate scaffold Sprint
$ ruby script/generate scaffold Task
$ ruby script/generate scaffold Estimate

Tras ejecutar estos comandos ya tengo el 80% de las herramientas de gestión. Lo primero que queda es establecer las relaciones.

Relaciones entre entidades persistidas

Tomemos como ejemplo la relación entre Proyectos y Sprints (un proyecto contiene varios sprints, un sprint pertenece a un proyecto). Para declarar esto en Rails basta con escribir lo siguiente:

[project.rb]
class Project < ActiveRecord::Base
  has_many :sprints
end

[sprint.rb]
class Sprint < ActiveRecord::Base
  belongs_to :project
end

Esto permite navegar de uno a otro usando la notación habitual: project.sprints o sprint.project y Rails se encarga del acceso a base de datos. También proporciona facilidades adicionales opcionales como la obtención de datos a priori (eager).

En el formulario de los sprints debemos poder elegir uno de los proyectos existentes. Para eso uso el siguiente código:

<p><label for="sprint_project_id">Project</label><br>
  <%= select("sprint", "project_id", Project.find_all.collect {|p| [ p.name, p.id ] }) %>

Gestión de usuarios en Rails: hacia SprintTracker v0.1

Tue, 21 Mar 2006 23:29:40 +0000

Ya me hago a la idea de lo que es una aplicación con Rails con suficiente claridad como para embarcarme en la tarea de crear la primera versión de SprintTracker. El objetivo de esta versión es que permita gestionar usuarios y proyectos, crear sprints asociados a proyectos, crear tareas dentro de un sprint y asignárselas a un desarrollador y por último ir añadiendo (re)estimaciones de la tarea durante los días que dura un sprint. La interfaz de usuario no me preocupa por ahora y dejaré la que genere Rails.

Primeros pasos

En primer lugar me decido probar un IDE específico de Ruby y encuentro RadRails así que digo adios a kate. También me pongo a buscar más artículos de Rails y me encuentro con una recopilación de los 12 mejores artículos de Ruby on Rails. A leer se ha dicho.

Una de las primeras cosas que se aprende de Rails es obliga a desarrollar de abajo a arriba: es decir empezando por el modelo de datos y llegando hasta la interfaz. Por ello es interesante comenzar la aplicación pensando bien el modelo de datos. El de SprintTracker es este:

Generación de código de persistencia en Rails

Rails ofrece dos modelos de generación de código (scaffolding) que podríamos denominar generación dinámica y generación por script

Aprendiendo más sobre Rails y Ruby

Tue, 21 Mar 2006 22:44:05 +0000

Tras conseguir instalar Ruby on Rails en la última sesión ha llegado la hora de entrar en materia. Como ya comenté mi idea era partir de los artículos del último número de la revista on-line ObjectiveView. Gracias a ellos he conseguido crear mi primera aplicación Ruby on Rails y por el camino también he aprendido mucho más tanto sobre este framework como sobre Ruby. Os cuento como ha sido la experiencia.

El primer artículo de la revista es sobre Ruby. Lo he leído rápidamente por encima y no me ha entusiasmado aunque si me he quedado con algunas de las peculiaridades de Ruby. En realidad tenía ganas de llegar al artículo "Ruby on Rails" de Obie Fernandez. Todo lo que escribo a continuación te resultará mucho más útil si has seguido, estás siguiendo o piensas seguir próximamente dicho artículo.

Siguiendo el artículo sobre Ruby on Rails

Siguiendo las instrucciones de los primeros párrafos he creado la aplicación ejecutando:

$ rails sprinttracker

Me ha gustado mucho la idea de que tras ejecutar el comando ya tengo una aplicación ejecutable y a la que puede accederse desde el navegador. Es más fácil y gratificante ir construyendo poco a poco sobre algo que funciona que escribir líneas y líneas que probablemente no funcionarán a la primera ni a la segunda.

Instalando Ruby y Ruby on Rails en Ubuntu

Mon, 27 Mar 2006 12:08:57 +0000

Ya no me he podido aguantar más. Después de meses escuchando las bondades de Ruby on Rails y en particular para conseguir un ritmo de desarrollo muy ágil me he decidido a probarlo. Llevaba varios días coméntandolo con amigos y compañeros, pero lo que me ha decidido ha sido el encontrar una idea para una aplicación: he pensado en desarrollar un entorno via web para llevar el seguimiento de una iteración con gráfica Burndown incluida. Últimamente estoy usando una hoja de cálculo, con la que estoy muy contento, pero echo de menos varias funcionalidades y el que varias personas puedan acceder a ella simultáneamente.

En definitiva que esta mañana me he puesto manos a la obra comenzando por instalar Ruby on Rails en mi Ubuntu 5.10. Lamentablemente la cosa no ha sido tan fácil como yo esperaba. Al final lo he instalado de la forma manual. Si no te interesan los problemas que me llevaron a esa decisión sáltate la sección que sigue ya pasa a la siguiente para una explicación rápida de cómo recomiendo proceder después de mi experiencia.

Primeros intentos con apt-get

Naturalmente lo primero que he hecho es mirar a ver si había paquetes disponibles para instalar con apt-get. Una de cal y una de arena. Ruby está y rails también (aunque una versión algo vieja) pero rubygems no. Primero instalé ruby:



Dónde aprender más sobre SCRUM
Tue, 15 Nov 2005 20:35:40 +0000
Últimamente estamos hablando mucho sobre SCRUM en Agile Spain, pero la verdad es que es bastante más difícil encontrar información sobre esta metodología que sobre otras más conocidas como Extreme Programming. Por ello voy a intentar dar algunas referencias a artículos, páginas web y libros que a mi me ayudaron a aprender sobre SCRUM. En general toda la información está en inglés. Pero primero mi propio resumen: 
  
 SCRUM es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo. Reduce al máximo la burocracia y actividades no orientadas a producir software que funcione y produce resultados en periodos muy breves de tiempo (cada 30 días). Sólo abarca prácticas de gestión sin entrar en las prácticas de desarrollo como puede hacer XP. Más bien delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo más productivos posibles. Sus raices teóricas están en las teorías de la auto-organización.
   
 Entrando en las referencias externas, en primer lugar, para los que tengan un buen nivel de entendimiento oral de inglés Ken Shwaber, uno de los padres de la metodología, ofrece unos vídeos introductorios de SCRUM.  
 Recientemente fue publicado el artículo Conventional Software Testing on a Scrum Team que hace una buena y didáctica introducción a SCRUM y profundiza en la forma de hacer pruebas en este tipo de proyectos.   


Como transmitir la sensación de avance del equipo
Wed, 14 Dec 2005 18:51:17 +0000
Era la primera vez que visitaba el blog de James Shore y me he encontrado con una entrada que me ha llamado mucho la atención.  
Los antecedentes son esos: todos los métodos ágiles coinciden combatir las jornadas de trabajo excesivamente largas, reuniones interminables y el exceso de presión en el trabajo. El resultado es que cuando se compara un equipo de trabajo que emplea XP o SCRUM con otros equipos que sufran los efectos anteriores puede parecer que hay una menor implicación de los integrantes del primero. Como consecuencia de esto comentaba Ron Jeffries en la lista de correo de XP que algunos clientes le pedían percibir una mayor sensación de urgencia en los equipos de desarrollo. Al leer esto he recordado diversas charlas con escépticos de los métodos ágiles que hablando sobre sus resultados me hacían comentarios como la gente está demasiado relajada o a las ocho ya no queda nadie en la oficina. 
A pesar de mi absoluto convencimiento sobre lo negativo de la presión externa y las ventajas de la motivación y la auto-organización siempre me ha quedado una espina clavada: ciertos clientes que no están lo suficientemente cerca del equipo para conocer su avance de primera mano siguen quedándose en ocasiones con una impresión peor que si la gente trabajara muchas horas extra. Algo parecido puede ocurrir con ciertos directivos o gerentes de alto nivel. Y claro está, aunque tu sepas que se está avanzando muy rápido puede ser un problema que la percepción externa sea distinta ¿puede evitarse esto? 


Presentación del Blog de Jorge Ferrer
Mon, 24 Oct 2005 12:27:57 +0000
Como primera entrada del Blog, que menos que presentarme. Mi nombre es Jorge y actualmente trabajo en Germinus XXI, en concreto en el departamento de desarrollo de software.
Los últimos 4 años he tenido la oportunidad de aplicar un gran número de prácticas ágiles en diferentes proyectos. En general con bastante éxito, pero también con algún traspies. En esta bitácora pretendo compartir estas experiencias pasadas y las que seguro vendrán en el futuro. 
Entre los temas que podreis encontrar estarán la gestión de requisitos ágil, la planificación colaborativa y constante, la relación entre métodos ágiles y los métodos de desarrollo de software libre y la aplicación de Desarrollo Dirigido por Pruebas (TDD). Estaré encantado de que me leais y aporteis vuestros comentarios.