Crónica del Coderetrat 2010 en Madrid

Qué es

El pasado sábado 2 de este mes de octubre asistí a mi primer Coderetreat. En el anuncio de agilismo.es no se decía claramente lo que se iba a hacer, tan solo una agenda con sesiones de trabajo y retrospectivas, pero nada más. Como no sabía lo que era un Coderetreat ni tenía claro si se iban a dar charlas o si se iba a programar decidí apuntarme y probar.

¿Y qué es un coderetreat? no lo tengo del todo claro, pero viene a ser un reunión de desarrolladores en los que se juntan para programar en parejas haciendo TDD, intentado resolver un problema concreto, compartir experiencias y aprender. Se hacen iteraciones (normalmente 6) de 40 minutos con 15 minutos de retrospectiva después de cada una.

La organización del Coderetreat de este sábado corría a cargo de agilismo.es y Autentia, que trajeron a Enrique Comba (@ecomba), uno de los autores intelectuales del Manifiesto por la Artesanía del Software y co-fundador de Agile-Spain como maestro de ceremonias.

Qué hicimos

Llegué a la sala de actos del hotel donde se celebraba la reunión a las 9:00 y me encontré, como en todos estos saraos, algunas caras conocidas y muchas nuevas. Un poco de networking-desayuno y empezamos, estaba incluso impaciente pues no sabía exactamente que íbamos a hacer.

En la presentación conocí a Enrique. Es un personaje carismático y un poco malvado (luego veréis porqué), así que nos dejamos llevar por su manera de hablar tranquila y relajada y nos explicó que teníamos que hacer. Programaríamos 40 minutos y cuando oyéramos la alarma de su móvil, borraríamos el código (sin excepción) y nos pondríamos de pie. Hizo, además, una breve encuesta a mano alzada con preguntas del tipo ¿cuántos de vosotros hacéis pair programming? ¿cuántos conocéis TDD? ¿cuántos practicáis TDD alguna vez? ¿cuántos prácticas TDD siempre?. Finalizada la presentación, nos sentamos en parejas, abrimos nuestros portátiles y, tras decidir quién de los dos empezaba a programar y qué lenguaje utilizábamos, tuvimos 40 minutos para desarrollar un reto. Este consistía en hacer el juego de la vida de Conway, un autómata celular basado en las siguientes reglas (que Germán tuvo la buena voluntad de escribirlas en la pizarra):

Las células nacen o mueren según el número de células vivas adyacentes.

  1. Una célula con menos de 2 vecinos muere.
  2. Una célula con más de 3 vecinos muere.
  3. Una célula con 2 o 3 vecinos, vive hasta la siguiente generación.
  4. Una célula muerta con 3 vecinos, revive.

Charlando, haciendo pruebas y programando se me pasaron los 40 minutos volando con Jon (el de la derecha en esta foto), un simpático phpero al que le apetecía probar con Groovy. Suena la alarma de Enrique y borramos todo el código hecho. No nos hace mucha gracia, al fin y al cabo es nuestro trabajo, pero no pasa nada, lo borramos, nos levantamos y hacemos una retrospectiva todos de pie de 15 minutos. Comentamos las diferentes aproximaciones que hemos hecho y Enrique nos pregunta el nombre de las clases que habíamos creado. Salen cosas tan dispares como tablero, matriz, universo, célula, estado, vecino, vecindario, muerte, vida, parrilla y otras muchas que no recuerdo ahora.

Cambiamos de pareja y volvemos a la carga. Esta vez me pongo con Alberto Peña (@plagelao) y repito con Groovy como lenguaje de programación. Con más decisión y, gracias a la experiencia de la iteración anterior, conseguimos avanzar lo suficiente para que pasaran casi todas las pruebas menos una ¡ya casi estábamos!, pero toca otra vez la campana y hay que borrar otra vez el código.

Viendo la luz

Tras la retrospectiva, es en ese momento es cuando me doy cuenta de que llevaba toda la mañana trabajando con una mentalidad totalmente equivocada: programando deprisa e intentado aportar soluciones que resolvieran el reto lo más rápido posible (¡solo 40 minutos!) al completo no es, para nada, el espíritu ni el objetivo de un coderetreat. Si quisíeramos hacer el juego de la vida, nos darían más tiempo y no borraríamos el código. Pero aquí no se persigue un fin, no se persigue una solución ideal ni tener el problema resuelto, sino todo lo contrario. Se persigue el medio, el enriquecimiento durante la programación, y se desecha el fin: el código se borra implacablemente tras cada iteración, dejándolo vivo solamente en nuestra memoria el tiempo suficiente para poder comentarlo en la retrospectiva y se vuelve a empezar. No importa si tu implementación fue brillante, el lenguaje que usaste, lo rápido que funcionase o si pasaban todas las pruebas. Se anda el camino por el placer de andar, no para llegar a ningún sitio: el verdadero fin es programar, usando cada vez un enfoque diferente, razonando en voz alta con un compañero distinto, en un reto diferente, cada vez.

Así que a partir de aquí cambié de mentalidad, me olvidé de resolver el problema y orienté el resto del día de otra manera: probaría otros lenguajes y otras maneras de resolver el reto. La siguiente iteración buscaría a alguien que programara en otro lenguaje que no fuera ni Groovy ni Java y lo haría todo de otra manera. Y me encontré a este chico, cuyo nombre no recuerdo, que usaba C#. Pero esta vez Enrique añadió unas cuentas reglas nuevas: ahora no se podía usar ninguna clase o entidad que representara una célula y teníamos que orientar la solución a las reglas del juego en sí mismas, y así lo hicimos (o lo intentamos). Por supuesto, al hacer un planteamiento tan diferente no nos dio tiempo a nada, y en la restrospectiva Enrique nos sorprendió con un engaño digno de un auténtico ilusionista: nadie nos dimos cuenta de que la iteración había durado ¡solo 20 minutos! todos pensábamos que había sido muy corta, pero por el hecho de habernos visto obligados a usar un enfoque distinto, pero nadie se dio cuenta que, simplemente, había durado la mitad. Buena jugada Enrique, si señor.

Confusión total

Cambiamos de pareja de nuevo y ahora si tenemos 40 minutos para la iteración, pero nos propone un gran desafío: no podemos usar clases, así que todo el código que necesitemos debe estar dentro de la prueba unitaria. Primero deberemos escribir el assert, después el código para pasarlo y cuando sea realmente necesario, podremos refactorizar y crear una clase. Nos advirtió que iba a ser muy difícil y para hacerlo más difícil todavía, nos invitó hacer cada test con un máximo de 4 líneas (sí podíamos). Confiados y motivados, me puse manos a la obra con Kini (@kinisoftware). Pero resultó no ser difícil, sino que directamente llegó un momento que no sabíamos ni qué hacer. Enrique se pasó por nuestro sitio para ayudarnos, nos dijo “¿me permitís?”, se puso al teclado, borró todo nuestro código (ante nuestra mirada atónita, claro) y tecleo algo parecido a:

void testVida() {
    boolean estaVivo = true;
    assertTrue(estaVivo);
}

Kini y yo, intentando comprender que es lo que quería Enrique que hiciéramos

Y nos miró satisfecho. Me recordó a la escena en la que Morpheo lucha contra Neo en Matrix y le dice “¿acaso crees que lo que respiras ahora es aire?”. Kini y yo nos miramos como sospechando el uno del otro y nos acabásemos de conocer ahí mismo y dijimos “venga vale, a ver si podemos seguir a partir de aquí”, pero nos duró poco. Intentamos baby-steps, haciendo tests muy básicos que siempre pasaban por el simple hecho de que, al tener que programar dentro de cada prueba el código necesario para pasarla, crear un test nuevo más no hacía que fallaran los anteriores, como suele suceder cuando compartes el código entre todos los tests. Así que no sabíamos en qué momento empezar a programar de verdad y refactorizar. Y así estuvimos, estrujándonos el coco durante 40 minutos de auténtica confusión, y se acabó, gracias a dios, la iteración y empezamos otra retrospectiva. Para colmo, creo recordar que en esta iteración estaba prohibido ¡usar ifs! Enrique parecía contento y sonreía sin parar al ver nuestras caras de desconcierto, un auténtico diablo malvado se esconde detrás de Enrique: creo que todos le odiamos en ese momento un poquito (es broma Enrique, sabes que te queremos ¡y nos encanta sufrir!)

Divirtiéndonos

La siguiente iteración fue algo más relajada, ya sin estar tan condicionados como en la anterior con las diabólicas reglas de Enrique, en esta solo se nos pidió que enfocáramos el desarrollo a modelar las reglas del juego de la vida. Me senté con Jorge Jimenez (@semurat), al que ya conocía de Twitter y tenía ganas de programar con él. Fue una iteración muy divertida ya que nos estuvimos riendo la mayor parte del tiempo (debió ser general, porque recuerdo a Kini gritar con los brazos en alto en un momento de euforia mientras programaba con José Manuel Beas …). Esta vez Jorge se dejó llevar por mi loca idea de plantear las reglas de una manera funcional, al estilo cálculo Lambda.

int fib(0) { return 1; }
int fib(1) { return 1; }
int fib(int n) { return fib(n-2) +
                 fib(n-1); }

La función de Fibonacci implementado en un pseudocódigo Java funcional. Algo así queríamos hacer Semurat y yo con el juego de la vida.

Y así estuvimos los 40 minutos, triturándonos un poco los sesos, creando reglas en un sistema que nos acabábamos de inventar y haciendo tests. Por supuesto, no acabamos ni de lejos, pero nos lo pasamos muy bien.

La última iteración, ya muy, pero que muy cansados, lo que hicimos fue repetir con el primer compañero que tuvimos cada uno ese día, de manera que pudiéramos comparar lo que habíamos aprendido cada uno por el camino durante el Coderetreat y lo contrastáramos. El enfoque en esta última iteración era pensar en el juego de la vida desde un punto de vista temporal, trabajando las generaciones y no las reglas. Así que busqué a Joan y decidimos empezar de nuevo, pero haciendo el juego de la vida con Javascript y las pruebas unitarias con QUnit, todo un reto para lo cansados que estábamos al final del día. Para acotar el problema, decidimos inventarnos una regla muy sencilla para el juego de la vida: una celula vive si tiene una célula viva a su derecha, e implementarla en un sistema que nos generase la matriz de células en función de una generación x dada en el tiempo. Y todo esto en Javascript, casi nada vamos.

La kata

Para rematar ante de irnos, una de las sorpresas del día fue que iban a regalar una licencia de IntelliJ IDEA ¿cómo? ¿una licencia de mi IDE favorito? ¡tenía que conseguirla! pensé, pero para ello teníamos que ganárnosla, y no nos lo iban a poner fácil. El reto consistiría en prepararnos la kata de String Calculator en 30 minutos (al final creo que fue casi una hora, no estoy seguro, perdí la noción del tiempo) y luego saldríamos en público a hacerla. Nos presentamos tres valientes: Jose Manuel Beas, Alfredo Casado y yo mismo. Xavi Gost estuvo a punto de hacerla directamente en vivo sin preparársela, pero al final nos dejó con las ganas. Hacer una kata no es ninguna tontería: tienes que salir con tu portátil y programar en directo, con un proyector, delante de mucha gente, y te puedes poner nervioso, sobre todo si… algo falla.

El primero que salió fue Jose Manuel Beas, que hizo su kata en Java, con un TDD muy bueno y narrando cada uno de los pasos que iba haciendo, mostrando como fallaban los tests, implementando y refactorizando después. Sin embargo, no tuvo el tiempo suficiente para preparársela entera y la dejó a la mitad. Y es que el cansancio a esas horas ya hacía mella en todos nosotros (¡las katas hay que hacerlas a primera hora, no a última!). Aplausos, votaciones y el siguiente a la palestra, yo mismo. Gracias a que usé Groovy, que permite programar mucho más con menos líneas, conseguí acabar mi kata completa durante la hora de entrenamiento anterior. Pero durante la realización de la misma en vivo, en uno de los primeros puntos, apareció un error que no me atreví a corregir con tanta gente mirando y directamente me planté. Mi falta de experiencia en las katas hizo que no supiera gestionar bien mis nervios, y me vine abajo en el primer error. Y es que una cosa es programar y otra muy distinta hacerlo en público, y para esto último hay que entrenar, y mucho. Votaciones, buen flow pero bajo TDD, tengo que entrenarlo más. La siguiente corrió a cuenta de Alfredo Casado, que hizo una kata muy, muy divertida: llegó un momento que todos nos estábamos riendo de su peculiar manera de narrar la kata. Pero al igual que los demás, cuando iba por la la mitad, le apareció un error y se plantó, así es que ninguno de los tres conseguimos acabar. Me imagino que, cuando todos los que salimos dejamos la kata por la mitad, es porque no debe ser nada fácil terminarla: está claro que hay que entrenar y practicar. Tras las votaciones, Alfredo salió victorioso y se fue a casa con una nueva licencia de IntelliJ IDEA ¡felicidades Alfredo! (que mejor momento para abandonar Netbeans :-D)

Y esta es mi versión personal de la kata String Calculator que hice el sábado. Es mejorable, sin duda: no usa expresiones regulares, falla en algunos casos (por ejemplo si se usan asteriscos como delimitadores) y el TDD usado es malísimo, pero es la que me salió en ese momento: http://groovyconsole.appspot.com/script/262001. Para ejecutarla solo hay que hacer click en “Edit in console” y después en “Execute script”

Fin

Seguramente la gente se quedó, hubo cañas o cena, pero personalmente estaba muy cansado, así que dejé a Israel Alcazar (me quedé con las ganas de programar con él, para la próxima) en el tren mientras charlamos en el coche y me fui a casa. Eso sí, con la sensación de que llevaba una semana trabajando sin parar y una sonrisa de oreja a oreja. Me metí en la cama, dormí 12 horas y soñé con células que nacían y morían…

Otras crónicas de asistentes:

Más información:

3 thoughts on “Crónica del Coderetrat 2010 en Madrid

  1. Ese es mi Alberto! Si señor! Pero, una cosa… resulta que la iteración que más sufriste y estabas más confuso cuál “célula” sin vecinos fue conmigo… no sé si alegrarme o no xD (para mi también fue la más confusa! :D) Y sobre el momento de euforia no pensaba que se notó tanto… que Beas y yo estábamos a tope con Groovy y los vecindarios xD

    Genial crónica, muy detallada y eso mola! Un placer programar (o intentarlo) contigo ;)

    PD: En los enlaces de abajo no me pongas como Joaquin Engemo, por desconocimiento de la gente :D pon mejor Kinisoftware ;) (estoy creando mi marca personal!)

  2. Un post bastante bueno que además de estar bien narrado, nos anima a los demás a participar en esta clase de eventos, una pena no estar más cerca de Madrid para poder haber asistido. Intentaremos hacer algo en Canarias en nuestra comunidad local. Me alegro mucho que lo hayas pasado bien y que te hayas tomada la molestia de escribir esta entrada.

    Un saludo.

Comments are closed.