En el hangar de Flowers se está terminado de ensamblar el nuevo proyecto.

La tripulación prepara los últimos retoques de la nave que se lanzará al espacio en breve.

Después de algunos meses de trabajo, muchos retoques, noches sin dormir soñando con código Ruby on Rails, y con otras cosas que no son líneas de código, el proyecto verá la luz en breve.

Según loa cálculos del Ingeniero jefe, y si las condiciones climáticas lo permiten, esta previsto colocar la nave en la rampa de lanzamiento en unas dos semanas.
Una vez colocada la nave en la lanzadera, será cuestión de horas activar el despegue.

En el próximo boletín informativo esperamos poder dar la fecha y hora exacta del lanzamiento.

El equipo sigue perfilando los últimos detalles para poder tener listo nuestro primer proyecto propio.

La ardua tarea de limar los últimos detalles no está llevando algo mas de tiempo de lo previsto. Pero gracias a que esta enteramente programada en Ruby on Rails, los últimos retoques se están ejecutando de forma muy ágil y sencilla.

Ayer, 4 de julio de 2007, a las 18:32 minutos se lanzó al espacio web nuestro primer proyecto:
El “Sputnik 2” (www.cineciudad.com).
El proyecto ha sido el primero realizado por encargo de una empresa y en él han colaborado otras compañías (Unocomunicación) para que todo estuviera perfecto.

Los nervios invadieron a los miembros del control de tierra, sobre todo por que dependían de los datos de APIs aportados por otras empresas ajenas al proyecto, y estás podían fallar en sus envíos de datos. Pero al final, la conexión de datos fue perfecta y el lanzamiento tuvo lugar sin problemas.
Este acontecimiento se celebró, por supuesto, con una cena un restaurante muy fecuentado por el equipo directivo.

Los técnicos desde la base central irán comprobando y chequeando que todo funcione correctamente, harán un mantenimiento periódico durante unas semanas hasta que el “Sputnik 2” (www.cineciudad.com) demuestre que está perfecto y puede navegar solo.

Estamos todos muy ilusionados, nuestro primer parto digital. Lo miembros de Flowers in Space ya son padres, esperemos que la familia siga aumentando aunque tengamos que comprar un autobús para llevarlos a todos al Colegio.

Se nos olvidaba comentar un tema. El Código Genético de nuestra criatura es 100% Ruby on rails.

El otro día le tuve que explicar a un cliente en qué consiste el TDD, en menos de un minuto.

Cuando le expliqué que los tests se escriben antes del código, se extrañó mucho y me preguntó cómo podía ser.

Le expliqué el típico caso de un modelo que tiene como atributos nombre y apellido y queremos tener una función nombre_completo, que concatena esos dos campos. Se puede escribir el test antes que esa función y comprobar que el nombre_completo proporciona el resultado correcto dado un nombre y un apellido conocido. Antes de escribir la función el test fallará, y luego funcionará. Es un ejemplo muy simple pero le bastó para enterarse al menos del concepto.

Ahora voy a contar una batalla del abuelo: durante mi paso por el proyecto del sistema de gestión de dominios, empezamos a hacer tests unitarios de alguna de la funcionalidad, no toda por desgracia. No era TDD, pero por lo menos había (algunos) tests.

Recuerdo un día que bajó una persona del Dpto. de Administración para decirnos que se había facturado incorrectamente un dominio de segundo nivel (.es, más caro) como uno de tercer nivel (.com.es, bastante más barato).

El dominio del error en cuestión tenía la forma xxxxcom.es e incorrectamente se había tratado como un dominio tipo .com.es, a pesar de que no era así.

Como había tests unitarios en el método que calculaba el nivel del dominio a partir de su nombre, inmediatamente añadí el test. Pongo el equivalente en Ruby, aunque el proyecto se programó con Java.

Sorprendentemente el test no falló. El método Dominio.obtener_nivel estaba bien escrito. Lo que pasaba es que en esa comprobación en concreto no se estaba utilizando.

Resulta que en el punto concreto donde se produjo el fallo, el código comprobaba “a mano” la terminación del dominio mirando si terminaba en “com.es”.

Aquello nos sirvió para corregir aquel bug, y además buscar por todo el código si había algún sitio más donde se estuviera haciendo mal. El programador de turno se llevó una pequeña reprimenda, pero la cosa no llegó a mayores.

En este caso, el hecho de tener tests unitarios permitió rápidamente encontrar la causa del problema.