WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.

Parece que he entrado en un momento del 0,1% no contemplado en el 99,9% de Uptime de Google Mail…

Casi me siento afortunado. Os prometo que no se la tengo jurada a Google…

(AYBABTU)

Acabo de dar el paso definitivo a Mac OS X con un MacBook Pro que me he comprado para reemplazar mi equipo Vista de escritorio. Dicho con otras palabras, es la primera vez en 20 años que tengo un Mac exclusivamente.

Y una vez dicho esto, releo algo que ya sabíamos: OS X Snow Leopard sólo es para máquinas Intel de 64 bits. No va en PowerPC’s.

Esta frase que pasará desapercibida para la gran mayoría de usuarios de Mac (Dirán “Vale, ya lo sabíamos”), en el mundo PC es como si Microsoft decidiera que el próximo Windows 7 sólo funcionara en Intel Core 2 Duo o Xeon. Es decir, que se cargaría el 80% del mercado. No se qué cuota tendrán los Mac con procesador Intel, pero Apple tiene tan férreo control sobre el mercado de máquinas que se permite hacer esto.

Tengo que releer la frase y volver a pensar en ello, míralo con otras palabras: “A partir de aquí, o te compras una nueva máquina Apple o no podrás usar ningún programa!”. Quizás con Paralels o algún tipo de virtualización se podrían ejecutar aplicaciones PowerPC, pero vamos, coincidiréis que “no es lo mismo”.

A ver, no quiero que este post tenga connotaciones negativas exclusivamente, puede parecer que es una crítica. Pero leyendo entre líneas también hay algo de admiración. Ojalá otros pudieran hacer lo mismo. Estoy seguro que Vista o Windows 7 serían mucho mejores si Microsoft decidiera suspender el soporte para tecnologías obsoletas que llevan arrastrándose miles de años (en el universo informático, quiero decir).

Está claro que soy un admirador de Apple, no en vano me acabo de “convertir” ($$$), pero eso no quita para que sea crítico con algunas cosas de las que hace. Fanaticos Maqueros del mundo, os voy a decir como Pablo Motos: “Relaaaajate”.

El microformato hCalendar incrusta fechas y eventos basados en iCalendar. La BBC usaba además el patrón de diseño sobre el tag ABBR, para incluir información relevante para parsear automáticamente alrededor de información para humanos. Por ejemplo:

<p>Mi cumpleaños es el <abbr class="dtstart" title="20090814">14 de Agosto</abbr></p>

Lo anterior es un ejemplo de microformato hCalendar incrustado en un ABBR tal como usaba la BBC.

¿Por qué es malo esto y por eso dejó de usarlo la BBC?

Pues básicamente, y sorprendentemente, por cuestiones de usabilidad.

Resulta que los microformatos, al usar el atributo “title” para almacenar los metadatos, expone visiblemente los mismos al usuario como efecto secundario. El atributo “title” en algunos elementos es visible al pasar el ratón por encima en forma de “tooltip”. Por ejemplo en los enlaces <a title="Título visible">, etc. Además, resulta que los programas que leen la pantalla para personas discapacitadas como ciegos, etc, LEEN el contenido del tag title, con lo cual una persona que use un lector de pantalla a voz y pase por el ejemplo anterior diría “Mi cumpleaños es el veinte millones noventa mil ochocientos catorce catorce de agosto”.

El artículo de A List Apart es especialmente interesante porque cuestiona en cierta forma a HTML 5. Usa el caso de la BBC para exponer sus argumentos, que son los siguientes:

Semántica estricta en HTML 5

HTML 5 marca un hito en los estandares de la red, entre otros por añadir una semántica más estricta en los elementos. Aparecen tags del tipo section, nav, etc, que se pueden usar en lugar de div para añadir semántica al contenido. El artículo cuestiona dos aspectos con gran convicción:

• La compatibilidad con navegadores antiguos.
• La futura expansión semántica del lenguaje.

Es decir, se cuestiona el antes y el después de HTML 5. El problema con los navegadores antiguos es grave, aunque se limita a los navegadores de Microsoft éstos representan un amplio porcentaje de los clientes existentes.

Por ejemplo, Internet Explorer (en cualquier versión) no soporta los estilos sobre los nuevos elementos. Por ejemplo:

<style type="text/css">
    section { color: red; }
</style>
<section>
    <h1>Esto es la sección principal.</h1>
</section>

La cabecera anterior no saldrá en rojo en Internet Explorer, ya que no aplica los estilos a los elementos que no conoce. Ya hay una solución en JavaScript para esto, como no, pero evidentemente es un gran problema ¿cómo puede un estandard moderno introducir nuevos “hacks”? ¿No tenemos bastante con los hacks existentes para CSS en Explorer?

El otro punto de interés es la futura ampliación de la semántica. El autor se basa en que los elementos existentes no son suficientes para dar intención semántica en general, y el lenguaje no permite ampliar dichos elementos. Por ejemplo, HTML 5 introduce elementos como <section>, <header>, <aside>, <figure>, que amplían las posibilidades semánticas, pero el artículo se cuestiona con razón que quizá son pocos elementos y la amplitud que abarca esta apertura semántica es insuficiente.

Como ejemplo, el mismo autor plantea una posibilidad que sería ampliar la semántica del lenguaje en lugar de mediante los tags, por los atributos de éstos. Por ejemplo, mediante <ul navigation="main"> o algo por el estilo.

Os recomiento otros posts del mismo autor para saber más.

Al principio sonaba un anuncio cada muchas canciones. Igual oías dos o tres discos seguidos hasta que aparecía una publicidad, pero poco a poco se fueron subiendo de tono. Primero empezaron con la publicidades visuales, los banners de toda la vida pero en versión Desktop. Vale, hasta ahí vale. Podemos minimizar, pero poco a poco empezaron a acelerar los anuncios audibles.

Hasta que ahora es prácticamente insoportable, no se a vosotros, pero me suena no uno, sino DOS anuncios seguidos cada 2 ó 3 canciones… En fin, no es que quiera ser demasiado quiquilloso, pero a estos niveles ni la radio, en M80 por ejemplo no ponen tantos anuncios. (Si, la comparación de Spotify con una radio está más que justificada).

Además, tampoco es mi intención ponerme quisquilloso, pero la voz que han puesto a los últimos anuncios da pena. Con todos mis respetos, pero parece una chiquita becaria de Cadiz.

“Con Snow Leopard, ahora el Mac ofrece compatibilidad con Exchange Server 2007 de Microsoft nada más sacarlo de la caja, algo que ni siquiera es posible en los PC con Windows.”

¡¡¡Ouch!!!

Lo que pretendo en este post es “guiar” o “introducir” TDD para aquellos que no comprenden del todo el concepto. Para entender TDD, debes saber que requiere escribir las pruebas PRIMERO, no DESPUES, y enfatiza la refactorización para conseguir todo esto. ¿Cómo se pueden escribir las pruebas primero? Si estás acostumbrado a hacer las pruebas (en caso de que las hagas) después de escribir el código, este concepto te será raro. Si las pruebas se hacen después del código, estás comprobando que el código funciona pero dicho código no está inducido por las pruebas, simplemente has hecho un “test” para comprobar que lo que has hecho es correcto.

Puede parecer una perogrullada, pero esto no es lo mismo. TDD hace posible que tu código esté guiado por las pruebas inciales, que al fin y al cabo es un conjunto de requerimientos. Es decir, en TDD empiezas primero por definir el comportamiento al que debes adherirte y asegurarte de cumplir estos comportamientos. Al hacer primero los tests, se evitan una serie de comportamientos y se aseguran una serie de ventajas: por ejemplo el sobredimensionamiento del código, sólo implementamos lo suficiente para pasar los test (cumplir los requerimientos) y también obliga al programador primero a entender bien el problema a resolver y a pensar como cliente al enfocarse en los interfaces.

Como se que todo esto está muy bien, pero es difícil entenderlo, voy a hacer un pequeño ejercicio de TDD para que lo comprendais mejor.

Números de Fibonacci

Los requerimientos son hacer una clase en C++ con un método que devuelve un número de la serie de Fibonacci. Bueno, tampoco vamos a controlar una central nuclear, así que el ejemplito clásico de la serie de Fibonacci para un ejemplo de TDD es perfecto. He utilizado gcc en OSX, los ejemplos deberían funcionar también en Linux.

Primero tenemos que usar alguna herramienta para hacer los tests. Para este ejemplo yo he creado la mía, que simplemente es una fución “test” que le paso una cadena y un “bool” como resultado de la comprobación de la prueba. En un entorno real se debería usar una librería de tests, aunque como podeis ver tampoco hace falta nada del otro mundo para hacer una batería de tests.

#include <stdio.h>
#include "fibb.h"
 
void test(char *str, bool pass)
{
    printf("%-11s %s\n", pass ? "OK" : "***ERROR***", str);
}
 
int main()
{
    Fibb f;
 
    test("Fibb debe existir.", true);
 
    return 0;
}

Vale, he incluido la cabecera de mi “futura” librería que crea un objeto “Fibb”. Como todabía no la he creado (recordad, los test se hacen ANTES del código) ya tengo mi primer requerimiento: “Fibb debe existir“.

Como era de esperar, esto falla:

Twoixter:pruebas josemiguel$ make
g++    -c -o test.o test.cpp
test.cpp:3:18: error: fibb.h: No such file or directory
test.cpp: In function ‘int main()’:
test.cpp:12: error: ‘Fibb’ was not declared in this scope
test.cpp:12: error: expected `;' before ‘f’
test.cpp:15: error: ‘f’ was not declared in this scope
make: *** [test.o] Error 1
Twoixter:pruebas josemiguel$ _

Se me olvidaba, este es el fichero Makefile:

.SUFFIXES:
.SUFFIXES: .cpp .o
.PHONY: clean
 
all: test
 
test: test.o fibb.o
        $(CXX) -o test $^
 
clean:
        -rm *.o

Y esta es la clase esqueleto para hacer pasar el primer test: Vamos a crear el objeto “Fibb”:

/* Fichero: fibb.h */
class Fibb {
public:
        int dame(int numero);
};

/* Fichero: fibb.cpp */
#include "fibb.h"
 
int Fibb::dame(int no)
{
    return 0;
}

Bueno, ya tenemos todo en su sitio y ahora vamos a ver qué pasa:

Twoixter:pruebas josemiguel$ make
g++    -c -o test.o test.cpp
g++    -c -o fibb.o fibb.cpp
g++ -o test test.o fibb.o
Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
Twoixter:pruebas josemiguel$ _

Bueno, como suponíamos, ahora pasa el test. Nuestro requerimiento se ha cumplido.

Fijaros que aún no hemos hecho nada para calcular la serie de Fibonacci, estamos haciendo requerimientos y los estamos cumpliendo programando nuestra clase para que pase los test. Esta es la clave del Test Driven Development no hacemos nada aparte de cumplir nuestros tests. Recordad, es Programación Dirigida por Pruebas, son los test los que nos indican qué tenemos que hacer.

Vamos a añadir unos cuantos tests más. Vamos a añadir unos cuantos requerimientos a nuestra “calculadora fibonacci“:

#include <stdio.h>
#include "fibb.h"
 
void test(char *str, bool pass)
{
    printf("%-11s %s\n", pass ? "OK" : "***ERROR***", str);
}
 
int main()
{
    Fibb f;
 
    test("Fibb debe existir.", true);
    test("Fibb.dame(0) debe ser 0.", f.dame(0) == 0);
    test("Fibb.dame(1) debe ser 1.", f.dame(1) == 1);
 
    return 0;
}

Es importante hacer notar aquí que, obviamente aparte de que cumplan con los detalles del problema, tenemos que procurar hacer los test para que fallen. En nuestro caso, la clase Fibb está vacía, sólo devuelve 0. Nuestro primer requerimiento (fibb de 0 == 0) por razones obvias va a cumplirse, pero a partir de aquí, los demás requerimientos SABEMOS que van a fallar, hacemos los test sabiendo que van a fallar y nuestro cometido es hacer que pasen.

Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
OK          Fibb.dame(0) debe ser 0.
***ERROR*** Fibb.dame(1) debe ser 1.

Como esperábamos, el número 0 de la serie es 0, pero al comprobar el número 1 de la serie no es 1, como debería.

Pues venga, vamos a cumplirlo:

/* fichero: fibb.cpp */
#include "fibb.h"
 
int Fibb::dame(int numero)
{
    if (numero == 1) return 1;
 
    return 0;
}

Ya está. Perfecto. Nuestro programa pasa los tests…

Twoixter:pruebas josemiguel$ make
g++    -c -o fibb.o fibb.cpp
g++ -o test test.o fibb.o
Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
OK          Fibb.dame(0) debe ser 0.
OK          Fibb.dame(1) debe ser 1.
Twoixter:pruebas josemiguel$

Bueno, aquí el lector avezado empezará a decir: “Espera, espera, no estás programando ninguna serie de Fibonacci, me estás mintiendo“. No, la respuesta es que estamos dando respuesta a nuestros requerimientos.

Si nuestros requerimientos fueran sólamente estos, ya habríamos terminado. No se, por ejemplo para un programa tonto que sólo saque los 2 primeros números de la serie de fibonacci esto bastaría. Las claves son las siguientes:

• Nuestra clase funciona según los requerimientos indicados.
• Nuestra clase no tiene ninguna funcionalidad extra, con lo cual no está sobrecargado con código sobrante.
• Si un futuro programador lee nuestro código, sabe perfectamente (por los requerimientos) lo que hace.

Vamos a seguir ampliando requerimientos porque “parece” que nos falta algo para que sea una serie real de Fibonacci. Vamos a incluir lo siguiente:

1. Para cualquier número negativo, devuelve -1 (Esto es un poco arbitrario, lo ponemos como requerimiento).
2. Para el número 2, debe devolver 1.
3. Para el número 3, debe devolver 2.
4. Para el número 4, debe devolver 3.
5. Para el número 5, debe devolver 5.

Venga, manos a la obra. Recordad PRIMERO hacemos los TEST para que FALLEN…

/* fichero: test.cpp */
#include <stdio.h>
#include "fibb.h"
 
void test(char *str, bool pass)
{
    printf("%-11s %s\n", pass ? "OK" : "***ERROR***", str);
}
 
int main()
{
    Fibb f;
 
    test("Fibb debe existir.", true);
    test("Para cualquier negativo, debe ser -1", f.dame(-1) == -1);
    test("Fibb.dame(0) debe ser 0.", f.dame(0) == 0);
    test("Fibb.dame(1) debe ser 1.", f.dame(1) == 1);
    test("Fibb.dame(2) debe ser 1.", f.dame(2) == 1);
    test("Fibb.dame(3) debe ser 2.", f.dame(3) == 2);
    test("Fibb.dame(4) debe ser 3.", f.dame(4) == 3);
    test("Fibb.dame(5) debe ser 5.", f.dame(5) == 5);
 
    return 0;
}

…como era de esperar:

Twoixter:pruebas josemiguel$ make
g++    -c -o test.o test.cpp
g++ -o test test.o fibb.o
Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
***ERROR*** Para cualquier negativo, debe ser -1
OK          Fibb.dame(0) debe ser 0.
OK          Fibb.dame(1) debe ser 1.
***ERROR*** Fibb.dame(2) debe ser 1.
***ERROR*** Fibb.dame(3) debe ser 2.
***ERROR*** Fibb.dame(4) debe ser 3.
***ERROR*** Fibb.dame(5) debe ser 5.
Twoixter:pruebas josemiguel$ _

Vale, tenemos que hacer cumplir estos tests… así que modificamos el programa principal de esta forma:

/* fichero: fibb.cpp */
#include "fibb.h"
 
int Fibb::dame(int numero)
{
    switch (numero) {
        case -1: return -1;
        case 1: return 1;
        case 2: return 1;
        case 3: return 2;
        case 4: return 3;
        case 5: return 5;
    }
 
    return 0;
}

¡Pero que estafa es esta! ¡Seguimos sin programar un generador de números de Fibonacci!. No, esperad, no funciona así… Estamos cumpliendo los requerimientos, y para los requerimientos que hemos puesto, este programa funciona perfectamente, como lo demuestran los tests:

Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
OK          Para cualquier negativo, debe ser -1
OK          Fibb.dame(0) debe ser 0.
OK          Fibb.dame(1) debe ser 1.
OK          Fibb.dame(2) debe ser 1.
OK          Fibb.dame(3) debe ser 2.
OK          Fibb.dame(4) debe ser 3.
OK          Fibb.dame(5) debe ser 5.
Twoixter:pruebas josemiguel$ _

Como veis, hemos pasado todos los tests. Nuestro programa es simple, fácil de entender, y pasa los tests.

Moraleja importante: TDD, o Desarrollo Asistido/Guiado por Pruebas, basa todo en los test al contrario que en la forma tradicional de programación. Si no usaramos TDD, empezaríamos por hacer un generador de números de Fibonacci seguramente de forma recursiva. Nos centraríamos en cosas que no tienen que ver con los requerimientos. En este ejemplo de la serie, insisto, es muy básico pero creo que cumple perfectamente con el objetivo de ver cuán diferente puede ser esta metodología de programación con respecto al método “clásico”.

Como veis, los detalles de implementación pasan a un plano secundario y lo importante son los requerimientos, el comportamiento que queremos que tenga nuestro programa. Con una batería de test correcta, con todos los requerimientos bien definidos, la implementación pasa a un segundo plano.

Hablando de requerimientos. Hay un fallo importante en los test, si os fijais, el test de los negativos pone “Para CUALQUIER negativo“, y sin embargo sólo comprobamos con menos uno. Vamos a cumplimentar mejor la batería de tests:

/* fichero: test.cpp */
#include <stdio.h>
#include <stdlib.h> 
#include "fibb.h"
 
void test(char *str, bool pass)
{
    printf("%-11s %s\n", pass ? "OK" : "***ERROR***", str);
}
 
int main()
{
    Fibb f;
 
    test("Fibb debe existir.", true);
    test("Para cualquier negativo, debe ser -1", f.dame(-rand()) == -1);
    test("Fibb.dame(0) debe ser 0.", f.dame(0) == 0);
    test("Fibb.dame(1) debe ser 1.", f.dame(1) == 1);
    test("Fibb.dame(2) debe ser 1.", f.dame(2) == 1);
    test("Fibb.dame(3) debe ser 2.", f.dame(3) == 2);
    test("Fibb.dame(4) debe ser 3.", f.dame(4) == 3);
    test("Fibb.dame(5) debe ser 5.", f.dame(5) == 5);
 
    return 0;
}

Hemos cambiado el test para cualquier negativo incluyendo un número aleatorio. No es estrictamente “científico”, porque en una pasada de test no podemos comprobar TODOS los números negativos. Para la mayoría de propósitos, un número aleatorio en un rango suficientemente grande nos asegurará que en cada ejecución de los test tengamos muchas posibilidades de que falle el test.

Moraleja: Como veis, seguimos enfocados en que los test fallen. Sería una perdida de tiempo en TDD hacer test para cosas que sabemos que funcionan, o cosas redundantes. Al enfocarnos en hacer test que fallen vamos “dirigiendo” nuestros esfuerzos a mejorar el desarrollo.

El test de los números negativos, como suponíamos, falla:

Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
***ERROR*** Para cualquier negativo, debe ser -1
OK          Fibb.dame(0) debe ser 0.
OK          Fibb.dame(1) debe ser 1.
OK          Fibb.dame(2) debe ser 1.
OK          Fibb.dame(3) debe ser 2.
OK          Fibb.dame(4) debe ser 3.
OK          Fibb.dame(5) debe ser 5.
Twoixter:pruebas josemiguel$ _

Ahora introducimos un concepto importante en TDD, la refactorización. Una vez que nuestro código pasa los test, debemos refactorizar. Refactorizar es cambiar la programación por cualquier motivo, por ejemplo para que sea más eficiente, más rápido, o hacer el código más simple, pero siempre teniendo la seguridad de pasar los tests.

En nuestro caso, hacer que valide el test de los negativos no sería una refactorización en sí, puesto que hay un test que falla y tenemos que enfocarnos en que valide. Sí que hacemos una refactorización para hacer que lo que antes era un “switch”, pase a ser una tabla.

/* fichero: fibb.cpp */
#include "fibb.h"
 
int Fibb::dame(int numero)
{
    int tabla_fibb[6] = { 0, 1, 1, 2, 3, 5 };
 
    if (numero < 0) return -1;
    if (numero > 5) return 0;
    return tabla_fibb[numero];
}

Vale, hemos cumplido el test de los negativos haciendo que cualquier número menor que 0 devuelva -1. Después también ha habido la refactorización importante de pasar de un switch a una tabla. Ahora todos los tests pasan, incluso el de los negativos:

Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
OK          Para cualquier negativo, debe ser -1
OK          Fibb.dame(0) debe ser 0.
OK          Fibb.dame(1) debe ser 1.
OK          Fibb.dame(2) debe ser 1.
OK          Fibb.dame(3) debe ser 2.
OK          Fibb.dame(4) debe ser 3.
OK          Fibb.dame(5) debe ser 5.
Twoixter:pruebas josemiguel$ _

Bien, como decíamos antes, si nuestros requerimientos fueran estos, ya habríamos terminado. ¡Y sin hacer el algoritmo de Fibonacci!. Merece la pena recapitular lo que hemos visto hasta ahora:

• Programar usando Test Driven Development significa “dar la vuelta” a la forma de pensar cuando programamos normalmente, ya que PRIMERO se hacen los test (pruebas) en forma de requerimientos.
• Los requerimientos por tanto deben ser sólidos, y estar bien fundados ya que nuestro programa va a ser una representación literal de esos requerimientos.
• Los pasos que debemos dar por tanto son: test > implementación > probar test > refactorización. Y así continuamente hasta que todos los requerimientos se cumplan.

Para terminar, y como tengo la sensación de que a esta serie de Fibonacci le falta algo, imaginemos que una vez hecho todo lo anterior y ya estamos contentos (nuestro programa cumple con los requerimientos), viene el “jefe” y nos dice:

• No, no, hasta 5 no, debe sacar los números de la serie hasta 40 como mínimo.
• A ver, a ver, entonces cómo se hace eso?
• Muy fácil, un número “n” de la serie es la suma del número “n-1″ más “n-2″…
• Ahhhh… Vale.

Entonces, hacemos el siguiente test:

/* fichero: test.cpp */
#include <stdio.h>
#include <stdlib.h>
#include "fibb.h"
 
void test(char *str, bool pass)
{
    printf("%-11s %s\n", pass ? "OK" : "***ERROR***", str);
}
 
int main()
{
    Fibb f;
 
    test("Fibb debe existir.", true);
    test("Para cualquier negativo, debe ser -1", f.dame(-rand()) == -1);
    test("Fibb.dame(0) debe ser 0.", f.dame(0) == 0);
    test("Fibb.dame(1) debe ser 1.", f.dame(1) == 1);
    test("Fibb.dame(2) debe ser 1.", f.dame(2) == 1);
    test("Fibb.dame(3) debe ser 2.", f.dame(3) == 2);
    test("Fibb.dame(4) debe ser 3.", f.dame(4) == 3);
    test("Fibb.dame(5) debe ser 5.", f.dame(5) == 5);
 
    int n = 20;
    test("Fibb de 'n' debe ser fibb(n-1) + fibb(n-2)", f.dame(n) == f.dame(n-1) + f.dame(n-2) );
 
    return 0;
}

Incluimos un último test donde decimos exactamente eso, que el número “n” de la serie es la suma del n-1 más n-2. Si corremos la batería de tests, ocurre esto:

Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
OK          Para cualquier negativo, debe ser -1
OK          Fibb.dame(0) debe ser 0.
OK          Fibb.dame(1) debe ser 1.
OK          Fibb.dame(2) debe ser 1.
OK          Fibb.dame(3) debe ser 2.
OK          Fibb.dame(4) debe ser 3.
OK          Fibb.dame(5) debe ser 5.
OK          Fibb de 'n' debe ser fibb(n-1) + fibb(n-2)
Twoixter:pruebas josemiguel$ _

¿Comorrrlll? ¿Ha pasado la prueba? Bieennn… Nuestro programa funciona para cualquier número natural positivo con sólo una tabla de 6 números. Bueno, evidentemente, esto está mal. Y está mal porque si recordais, hemos dicho antes que los tests tienen que hacerse PARA QUE FALLEN inicialmente. Si no, pasan estas cosas.

Nota: La explicación de por qué pasa el test debe ser evidente, pero si no, lo que ocurre es que nuestra función devuelve 0 para cualquier número mayor de 5. Entonces, 0 = 0 + 0.

Tenemos MAL el test.

Deberíamos replantear el test de esta forma: “Fibb de ‘n’ debe ser fibb(n-1) + fibb(n-2) y mayor que cero“.

Twoixter:pruebas josemiguel$ ./test
OK          Fibb debe existir.
OK          Para cualquier negativo, debe ser -1
OK          Fibb.dame(0) debe ser 0.
OK          Fibb.dame(1) debe ser 1.
OK          Fibb.dame(2) debe ser 1.
OK          Fibb.dame(3) debe ser 2.
OK          Fibb.dame(4) debe ser 3.
OK          Fibb.dame(5) debe ser 5.
***ERROR*** Fibb de 'n' debe ser igual a fibb(n-1) + fibb(n-2) y >0
Twoixter:pruebas josemiguel$ _

Vale, ahora podemos ponernos manos a la obra:

/* fichero: fibb.cpp */
#include "fibb.h"
 
int Fibb::dame(int numero)
{
    if (numero < 0) return -1;
    if (numero == 0) return 0;
    if (numero == 1) return 1;
 
    return dame(numero-1) + dame(numero-2);
}

Que es un algoritmo de Fibonacci más o menos estandard. (Bueno, no me critiqueis mucho, esto es un post sobre Test Driven Develpment, no sobre cómo hacer un algoritmo de Fibonacci)

De hecho, habiendo refactorizado lo anterior, pasan todos los test. Ahora podríamos hacer un test que comprobara uno a uno todos los números de la serie hasta el 40, que es nuestro tope.

Espero que hayais leido hasta aquí, este ha sido uno de mis posts más largos. La intención ha sido hacer entender de una forma práctica las bases de TDD. En futuros posts, pondré enlaces más interesantes sobre frameworks y librerías que podemos usar para hacer tests y usaré otros lenguajes aparte de C++, lo prometo.

Me incita a escribir esta entrada (y de ahí el título del post) una comparativa que me viene a la cabeza con la época hippie de los años 60. La revolución sexual de aquellos años contrastaba con el régimen conservador y se reveló contra él, de la misma forma casi que Ruby se revela contra otros lenguajes más “estrictos”. La comparativa viene al caso porque al igual que los abusos de aquellos años de droga, sexo y rock’n'roll con Ruby también se pueden cometer excesos.

Ruby introduce no sólo un lenguaje de programación, sino toda una forma de hacer las cosas, “The Ruby Way” que llaman los entendidos. Esto es cierto, sin llegar a ser un cambio de paradigma, se tiene que pensar de forma diferente en Ruby. Todos los manuales existentes insisten en que el propio lenguaje te fuerza a hacer las cosas de forma diferente, pero continuamente veo que no es así.

Por ejemplo, continuamente veo código Ruby que mantiene los mismos patrones de programación de… pongamos PHP. Por ejemplo:

def temp_dirname
  chars = %w{a b c d e f g h i j k l m n o p q r s t u v w x y z}
  rand_max = chars.size
  ret = "" 
  16.times { ret << chars[rand(rand_max)] }
  ret
end

El método anterior devuelve una cadena aleatoria para ser usada como nombre en un fichero temporal. Evidentemente, desde la primera línea se ve que se ha programado con la intención de seguir un patrón no-ruby, creando una variable temporal “ret” como cadena para ir concatenando caracteres aleatoriamente de la tabla abecedario creada anteriormente. Lo único “Ruby-Way” del código anterior es el uso de 16.times, pero seguro que si Ruby tuviera un for(x;x<y;x++) se usaría.

Esto no se tiene que hacer así. Ruby da para más. El problema de lo anterior es que no queda “claro” desde un primer momento lo que hace el método. Si, seguro que gastando 5 minutos de tiempo se llega a la conclusión de lo que hace, y tienes que ser un programador medio avezado para ver instantáneamente lo que hace la operación chars[rand(rand_max)].

Lo anterior podría haberse escrito de esta forma:

require 'digest/md5'
 
def temp_dirname
  (Digest::MD5.hexdigest rand.to_s)[0..15]
end

De acuerdo, aquí hemos introducido la librería “digest/md5″ para crear una cadena hash a partir de un número aleatorio, y luego extraemos los 16 primeros carácteres. Pero aún así, es más fácil de entender que las 5 líneas anteriores.

Podemos evolucionar más y hacerlo aún más “Rubyist” usando varios conceptos exclusivos de Ruby. Vamos a eliminar la dependencia de la librería de MD5 y volvemos al array abecedario, pero vamos a hacerlo DRY (Don’t Repeat Yourself) y KISS (Kept It Simple, Stupid):

class Array
  def any
    self.[] rand(length) if length
  end
end
 
class String
  @@temptemp = %w{a b c d e f g h i j k l m n o p q r s t u w x y z}
  def tempname!
    16.times { self << @@temptemp.any }
    self
  end
end

OK, nos aprovechamos de poder “extender” los objetos nativos de Ruby para añadir dos métodos a las clases “Array” y “String”. En “Array”, añadimos el método “any” que nos devuelve, aleatoriamente cualquier elemento de un array. por ejemplo:

>> [1, 2, 3, 4].any
=> 1
>> [1, 2, 3, 4].any
=> 2
>> [1, 2, 3, 4].any
=> 4

Esto es DRY, hemos ampliado la clase Array para devolver cualquier elemento aleatorio de cualquier array. Por ejemplo:

>> String.methods.any
=> "display"
>> String.methods.any
=> "untaint"
>> String.methods.any
=> "private_class_method"

Después, hemos ampliado la clase String para añadir un método llamado “tempname” que nos añade, a cualquier string, una cadena aleatoria (basada en el Array#any anterior). Por ejemplo:

>> "".tempname!
=> "tyhbijuqhhjednmr"
>> "/tmp/".tempname!
=> "/tmp/nykfurjyunojqykj"
>> "/var/lib/temp/".tempname!
=> "/var/lib/temp/rdysjeymslkqwfar"

Lo de incluir una exclamación al final de tempname! es un consenso que usa Ruby de incluir una exclamación al final de los métodos que modifican de alguna forma el objeto sobre el que actua (vamos, que no devuelve nada, sino que modifica el propio objeto). Por otra parte, es como otro carácter y forma parte del nombre del método.

La conclusión de este post es que si te propones aprender Ruby, intentes mirar más allá de la sintaxis. “Code is Poetry”, como dirían algunos, y esto es mucho más verdad en Ruby.

Definitivamente, alguien debería enseñar a Google qué es UTF-8.

Bueno, he visto un caso de canción borrada…

Como podeis ver en la captura, la canción “It’s Oh So Quiet” de Lisa Ekdahl ha sido “borrada” a petición del artista o la discográfica. La verdad, no me quita el sueño que esa canción en concreto sea borrada, pero no deja de ser curioso ver la aplicación del “borrado” por ti mismo.

¿Tendrá que ver Anaïs Anaïs (Cacharel) con algo de esto? Podeis apostar lo que sea…

Actualización: ¡Acabo de ver más canciones prohibidas! En este caso si que me afecta más, hay un disco concreto de Herbie Hancock que tiene al menos 6 canciones prohibidas, entre ellas “Watermelon Man” y “Maiden Voyage”, dos grandes éxitos que curiosamente SI que se pueden escuchar en otras recopilaciones.

Por ejemplo, en la captura que pongo a continuación marco con una flecha roja las canciones que están prohibidas, y en verde las mismas pero en otros discos recopilatorios. Algunas al parecer son versiones diferentes, por la duración (una en concreto es un directo). En este caso es más difícil que en el caso de “It’s Oh So Quiet” saber por qué están prohibidas. Al menos yo no encuentro la explicación para bloquear una canción de un recopilatorio cuando la canción original está disponible (”Watermelon Man” es del disco “Head Hunters“).

¿Estarán las mismas restricciones activas en la versión “Premium”?