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 ] }) %>

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

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.

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:

A todos los que hayais empezado a usar gráficas Burndown para llevar a cabo el seguimiento de los proyectos os resultará muy interesante el artículo Five Signs of Trouble in an iteration donde Mishkin Berteig evalúa varias formas que pueden tomar esas gráficas y cómo identificar problemas a partir de ellas.