jueves, 23 de diciembre de 2010

There is no way back

Today, I have finished my internship at Eden Development. After this month, I think I know what Eden is (for me, at least). Eden is a group of good people who care about what they do. It has been really awesome to work with you, guys! Thanks for everything :)

I came here with a lot of questions and I am leaving with the certainty that other companies are possible. Much more fun, more responsible, better companies :)

I have been tracking my feelings about my internship with MercuryApp and here is the result:

As you can see, it has been a great month :D The neutral days were the snowy saturdays or sundays.
The best ones are more interesting. They were the days I did pair programming with Aimee and Enrique. Think about it, the best days were the ones I did pair programming and, you know what, every day is like that for the edenites :D
I also enjoyed a lot the plage-presentation days, even though I do not like to speak in public. They were my opportunity to offer something to Eden (besides translations :P).
The rest of the days were "just funny days" :D

I also appreciate that Enrique has forced me to write an article every day. I am looking forward to read them :D

Thank you, Eden, for given me this opportunity :D It has been a life changing experience.

PS: I have liked Eden so much that I have stuck their sticker on my mac :D

miércoles, 22 de diciembre de 2010

Principios detrás de "Continuous Delivery"

Mañana tengo que hacer la presentación sobre "Continuous Delivery" y todavía no se muy bien que contar, así que voy a ensayar un poco con esta entrada :P Os voy a contar los principios que guían a los autores en esto de la entrega continua.

Create repeatable, reliable process for releasing software
Para los autores, liberar software debe ser fácil. ¿Alguna vez os habéis tenido que quedar una tarde o un fin de semana preparando una puesta en producción? ¿Os ponéis nerviosos con cada entrega al cliente? Si eso pasa es porque no confiais en vuestro proceso de entrega de software, os crea incertidumbre porque no es repetible. Depende demasiado de las personas que realizan esa tarea.
Según los autores, habremos triunfado si conseguimos que entregar software sea aburrido (común).

Automate almost everything
¿Cómo conseguimos que entregar software sea aburrido? Según los autores, automatizando todo lo que podamos el proceso. Eso sí, nos avisan de que no es necesario que automaticemos todo de golpe. Podemos ser un poco más conservadores e ir resolviendo solo nuestro mayor problema.

Yo estoy de acuerdo con ellos, aunque a mi me gusta hacerlo de golpe :D Cualquier proceso manual puede ser propenso a errores, por lo que prefiero minimizarlos :P

Keep everything in version control
Se refieren a todo, desde el código fuente, por supuesto, hasta las máquinas virtuales que utilizas para montar los entornos de test, pasando por los compiladores que necesitan para crear los entregables...

En realidad, no se refieren a que lo tengas todo dentro del sistema de control de versiones, se refieren a que cada entregable y el entorno en el que se construyó debe poder ser reconstruido a partir de un número de versión. Por ejemplo, si usas maven, tener todas las librerías externas que usas anotadas con la versión, de forma que cuando reconstruyas el artefacto no uses nuevas versiones. O, si tu aplicación la van a desplegar en un Tomcat 6, tener un entorno de test asociado a la versión a reconstruir que tenga ese Tomcat 6.

Todo esto me parece un autentico pasote y no se muy bien que pensar de todo ello. Veo que, algunas cosas sí que son sencillas (código fuente, librerías externas, documentación, etc) pero no tengo ni idea de como asociar hardware a versiones de artefactos. Creo que muchas del movimiento devops está relacionado con esa parte (mencionan puppet en algún lado), pero hablo desde la ignorancia :D

If it hurts, do it more frequently, and bring the pain forward
La integración continua se basa en este principio. ¿Integrar el código de los desarrolladores cada semana duele? Pues hazlo cada minuto. Es curioso, porque es muy poco intuitivo, pero funciona: D ¿Por qué no aplicarlo al resto? Cada vez que tenemos que desplegar la aplicación en el entorno de pruebas las pasamos canutas. Despliégala con cada commit, verás como al final no duele.
Es una forma de obligarnos a mejorar nuestro proceso de desarrollo.

Build quality in
Este lo toman prestado de lean (pero lo dicen, ¡eh!) :D Cuando suene una alarma, actua en consecuencia. ¿Se rompe el build? La prioridad es arreglarlo. ¿La aplicación falla en producción? Volvemos a la versión anterior y arreglamos el error (Eso sí, para volver a la versión anterior de una forma fácil y rápida más nos vale haber cumplido el primer y segundo principio).

Done means released
Algo terminado es algo que tiene el cliente. El resto está sin terminar. Puede parecer un poco radical, pero es cierto. La solución que plantean los autores es minimizar el tiempo que pasa entre el inicio del desarrollo y la entrega al cliente.

Everybody is responsible for the delivery process
Al igual que en el Agile Testing nos dicen que las pruebas son responsabilidad de todo el equipo, aquí nos dicen que la entrega de software debe ser responsabilidad de todo el equipo también.

Continuous improvement
Este también lo toman prestado de lean y, basicamente, significa que hay que reflexionar sobre lo que hacemos y mejorar :)


Y eso es todo. Como veis, es un libro bastante ambicioso. Estoy deseando ver como se las apañan para acercarse a estos ideales :D Un saludo

martes, 21 de diciembre de 2010

Tipografía

Hace unos días, Spencer me pasó un par de enlaces sobre tipografía en la red. Aún no me los he leido enteros pero, de momento, me parecen muy interesantes :D

El primero de los enlaces es "web typography". En esta página nos cuentan todo lo referente a tipografía en la red, desde el principio (¿qué son las em?). Todo viene muy bien explicado (yo, que no tengo ni idea de css, me estoy enterando bastante bien de todo :D ) pero, lo realmente molón, es que está viva. Cada poco sacan nuevos artículos o actualizaciones sobre los ya escritos (añadiendo algo de css3, por ejemplo). Os recomiendo que, aunque no tengáis que tocar un css en la vida, le echéis un ojo (La introducción es bastante chula).

El segundo enlace es un articulo de Smashing Magazine en el que hablan sobre "Qué fuente usar". No os asustéis, es bastante introductorio (explican que es eso de "serif"...).

Mi única experiencia en lo referente a tipografía en la red es este blog, con eso os digo todo :P Era uno de esas cosas que no sabía que no sabía.
Leyendo esos dos enlaces, me he dado cuenta de lo bonito e importante que es seleccionar una fuente adecuada, un espacio entre lineas cómodo, etc. Se que nunca llegue a ser un buen diseñador, tampoco es mi objetivo (me parece que no tengo demasiado buen gusto :P) pero, al menos, empiezo a entender la dificultad y esfuerzo que requiere dicho trabajo.

Un saludo.

PS: Parece que el tiempo mejora y que, al final, sí que voy a poder volver a casa para la cena de nochebuena :D

lunes, 20 de diciembre de 2010

Continuous Delivery

Aunque parezca mentira, ya casi ha pasado un mes desde que llegué a Eden. Hoy comienza mi última semana como interno y, como todos los lunes, ya tengo mi tarea semanal. Tengo que leerme el "Continuous Delivery" y hacer un resumen durante mi presentación :) Tenía ganas de leerlo, ahora ya tengo excusa :P

Continuous delivery está escrito por Jez Humble y David Farley, ambos thoughtworkers, y el libro entra dentro de la serie firmada por Martin Fowler. Tal y como ellos cuentan al principio, el titulo lo han sacado directamente del Manifiesto Ágil, concretamente del primero de sus principios:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Lo primero que me ha venido a la cabeza cuando he empezado a leer el libro ha sido ¿por qué necesito leer este libro? Jez y David me han dado la respuesta:
Only when you have control over the progression of every change from introduction to release can you begin to optimize and improve the quality and speed of software delivery.
Solo cuando tengas el control sobre la progresión de cada cambio desde que lo introduces hasta que lo liberas, podrás empezar a optimizar y mejorar la calidad y velocidad de tus entregas de software

Aunque acabo de empezarlo y aún no he podido leer mucho, la idea central del libro es lo que ellos llaman el patrón "deployment pipeline" que, tal y como lo definen, es una implementación automatizada de las fases de build, deploy, test y release de la aplicación sobre la que se trabaja, es decir, automatizar al máximo todo el proceso a partir del commit.

El libro promete bastante, ya os iré contando. Un saludo.

PS: Hoy es el cumpleaños de Todd, felicitadle por twitter :D

String calculator kata

On Friday, Aimee suggested me that, in order to improve my English, I should write some of my blog entries in that language so, every now and then, I am going to write short entries in English :D

As I have told you before, I need to practice, practice and practice. The problem I have chosen to start with is the string calculator kata. For those of you who do not know this kata, it is a very simple problem. Someone gives you a string with numbers separated by a defined separator and you have to calculate the sum of that numbers. You can find the actual code-kata specification here.

This is not the first time I confront this problem, I already did it some months ago in Java. Now, I am doing it in Ruby and the code I am writing is much more precise than the one in Java. Ruby classes are more friendly than the Java ones (Manipulate Strings in java is a nightmare compared with Ruby), and everything seems simpler. I am not an expert in Ruby nor in Java, but I think Ruby is a much more friendly language to work with.

I will practice this kata every day until I feel ready to record a screencast so, Stay tuned!

Meanwhile, here is the kata done in scheme by Enrique :D

String Calculator Kata from Enrique Comba Riepenhausen on Vimeo.

viernes, 17 de diciembre de 2010

Practicar, practicar, practicar

Imagino que todos lo tendréis claro ya, pero tengo que decirlo. Tenemos que practicar mucho.

Hoy me ha tocado presentar la refactorizacion del código para internacionalizar la web. Pensaba que no estaba demasiado mal. Había partes que me gustaban más que otras pero, en general, me parecía bastante buen código... Pues, ¡sorpresa! no lo es :D Mientras explicaba lo que habíamos modificado, he ido planteando las dudas que tenía en la cabeza. Mis compañeros me han contestado, pero no de forma teórica, con las manos en la masa. Cada mejora, consejo o discusión me parecían bastante obvias, pero yo no había sido capaz de verlas antes. ¿No os ha pasado nunca? Te dicen algo y piensas, "claro, ¿cómo no se me había ocurrido nunca?

Creo que, esa dificultad en descubrir el siguiente paso se debe a que no he practicado lo suficiente hasta ahora.

Estoy utilizando Ruby, un lenguaje que no domino. Acabo de empezar con él y le he cogido el gusto a los yield, lo que provoca que mi código a veces sea demasiado listo y difícil de entender. Si quiero entender bien como usar Ruby, está claro lo que tengo que hacer, practicar :)

No tengo claro los niveles de abstracción ni los conceptos que representan, lo que me lleva a mezclarlos. Tengo que practicar con problemas simples y pensar muy bien lo que hago. Necesito aclararme la cabeza y, espero, poco a poco todo irá saliendo más natural.

Dado que no manejo bien el lenguaje y no termino de definir las abstracciones, es imposible que un diseño decente emerja... Igual que antes, tengo que practicar mucho para que todo fluya.

Siento que esta entrada sea tan cortita y ligera, pero tengo que irme a practicar :D

Un saludo

jueves, 16 de diciembre de 2010

¿Por qué?

Tenía pensado contar algo sobre como hemos puesto en producción la página internacionalizada de Eden Development, pero he cambiado de idea después de la reunión del grupo de MadriAgil :D El tema de la reunión ha sido BDD, pero lo que yo me he llevado de ella es la importancia que tiene preguntar por qué.

Si os acordais, cuando escribí sobre los valores de Eden mencionaba este:

We ask "why?"
Preguntamos "¿por qué?"

Hoy, Enrique nos ha demostrado a todos los del grupo de Madrid la importancia que tiene para ellos preguntar por qué. Creo que nos a convencido a todos :P

Es muy importante cuestionar las motivaciones de los clientes. Obligarles a pensar en su problema, no solo en la solución. De hecho, esto es tan importante para Eden que se tiran 2 días enteros buscando respuestas a los por qué que plantean.

Sin embargo, lo que más me interesa a mi en este momento (intentando convertirme en aprendiz :P) es la parte en la que te cuestionas a ti mismo. Ahí van algunos ejemplos en distintos ámbitos:

¿Por qué he creado esta clase?
¿Por qué le he puesto ese nombre a esta variable?
¿Por qué mi código se entiende?
¿Por qué no entiendo SOLID?

¿Por qué me pongo tan nervioso cuando hablo en público?

¿Por qué no quiero ir a trabajar?

¿Por qué no soy feliz?
¿Por qué soy feliz?


Como veis, no todos los por qué tienen que llevarnos a malas conclusiones :D
Os dejo con esas preguntas (las que apliquen), pero sobre todo, con la idea de cuestionarnos tanto a nosotros mismos como a los demás, se aprende mucho :)

Un saludo.

miércoles, 15 de diciembre de 2010

Diseño Simple

Hoy no he podido hacer pair programming con ningún "edenite" :( Los que no estaban en proyectos, estaban liándola parda organizando cosillas para Madrid :) Preparaos para la que se nos viene encima :D Ya se están empezando a mover cosas y nos vamos a divertir mucho :D Si queréis estar informados de todo lo que se organice para Eden Madrid debéis seguir esta cuenta de twitter.

Pero a lo que iba, que me desvío :P Hoy me ha tocado enfrentarme a mi código solo (aunque Chris me ha ayudado con una cosilla que se me resistía :D ) y me ha surgido una duda que, creo :P, las 4 reglas del diseño simple han conseguido aclarar.

Las 4 reglas del diseño simple

  1. Runs all the tests.
  2. Expresses every idea that we need to express.
  3. Says everything OnceAndOnlyOnce.
  4. Has no superfluous parts.

  1. Pasan todos los tests.
  2. Expresa cada idea que necesitamos expresar.
  3. Dice lo que dice una única vez.
  4. No tiene partes superfluas.

El orden de las reglas define su importancia, por lo que, si dos reglas entran en conflicto, debemos quedarnos con la primera de las dos.

El problema
Tengo una clase que debe dar de alta en el entorno un par de variables. Ambas variables dependen de si existe una cookie con el idioma en dicho entorno, por lo que el mismo if puede valernos para dar de alta las dos variables, tal que así:



Sin embargo, el set_variables(env) del primer método no me parece lo suficientemente expresivo, así que lo he cambiado por esto:



Está claro que, en este último caso, tenemos duplicación (Nos cargamos la tercera regla), pero aumenta la legibilidad (la segunda regla). He estado dudando si dejar la duplicación o eliminarla y, al final, he decidido que me gustaba más la legibilidad del segundo caso. No estoy seguro de si es lo correcto, veremos mañana cuando programe con un "edenite" al lado :D A vosotros, ¿qué os parece?

Un saludo.

PD: Spencer me ha pasado hoy este enlace sobre tipografía en la web. No lo he podido leer todavía, pero parece muy molón :D

martes, 14 de diciembre de 2010

Código expresivo

Como os conté ayer, he comenzado un nuevo show que me gusta llamar "limpiemos el código que he creado". El invitado especial de hoy ha sido Enrique Comba, y tengo que decir que Aimee es una gran profesora :D Bueeeno, Enrique también es buen profe :P Ahora en serio, he estado programando todo le día con Enrique y me lo he pasado muy bien :D ¡Muchas gracias, Enrique!

Código expresivo
Lo que más me ha gustado de programar con Enrique es la importancia que le da a que el código sea expresivo. Hemos pasado mucho tiempo buscando buenos nombres y preguntándonos como conseguir que el código hablara por si mismo. Todo ese pensar, que muchas veces yo no hago :P, nos ha llevado a un código mucho más simple y entendible que el que había. No hemos conseguido terminar de limpiar, pero hemos avanzado bastante :D

Aunque siempre intento buscar nombres correctos cuando programo, hoy me he dado cuenta que soy muy vago. De hecho, comparado con Enrique, prácticamente no uso mi cerebro para pensar en el naming o para darle vueltas al código, de forma que sea más expresivo. Ojo, yo pensaba que sí que tenía cuidado, pero me he dado cuenta de que necesito ser mucho más responsable y tener mucha más autodisciplina. Para mi, no es fácil "perder" tanto tiempo intentando hacer que mi código sea lo más expresivo posible. Hoy creo que he aprendido a calmarme y a pensar bien lo que hago, aunque está claro que necesito practicar mucho.

Pequeños éxitos
Si aún no habéis programado con Enrique, os tengo que decir que es muy divertido (es un poco ganso :P ). A parte de lo mucho que sabe (he aprendido mucho sobre como refactorizar y un poco más de vi), siempre que limpiábamos algo un poco más complejo y conseguíamos que todos los tests estuvieran en verde, lo celebrábamos con un "high five" :) Parece una tontería, pero esas celebraciones son un reconocimiento al trabajo bien hecho y motivan para afrontar el siguiente cambio.

Pair programming
No es fácil hacer código que entienda mucha gente si solo trabajas tú en él. Hoy me he dado cuenta de lo importante que es tener a alguien al lado que lea lo que escribes y opine sobre ello. No he hecho mucho pair programming, por lo que no puedo comparar, pero el de hoy me ha parecido muy comunicativo. Ambas partes opinábamos sobre el código (aunque yo aveces no sabía como mejorarlo o como expresar lo que quería hacer :P) y lo íbamos "enriqueciendo", haciendolo más simple y más comunicativo. Creo que esa comunicación (feedback instantáneo sobre el código que escribes) es una de las mayores ventajas del pair programming.
Además, mientras haces pair programming es más complicado que vaguees a la hora de limpiar el código. La otra persona te puede dar un capón y ponerte en tu sitio :P

Cucumber
Respecto a los escenarios de cucumber, hemos dejado de hablar de locales y, como decía calavera en los comentarios de la anterior entrada, lo hemos cambiado por idiomas. Creo que la especificación de la funcionalidad ha quedado algo más clara, aunque puede que cuando la vuelva a leer se me ocurra otro cambio :P

Otras cosas
A parte de pasar el día programando con Enrique, que ya mola un montón, Aimee no ha dado una charla sobre como ha integrado MongoDB en su Merlin's castle :D ¿Cuanto mola eso? No se, creo que casi infinito. Tener unos compañeros así creo que no tiene precio :D

Oops, dinner's ready! Un saludo.

Actualizado: La charla sobre MongoDB la podéis ver aquí. ¡Muchas gracias por compartirla, Aimee!

lunes, 13 de diciembre de 2010

Limpiando la casa

Como ya os dije, el viernes pasado hice la exposición de la web de Eden en español :) Durante la presentación del código, los edenites me apuntaron unas cuantas cosas a mejorar. Debía estudiar algunas tecnologías más en profundidad y tenía que intentar conseguir que mi código se explicara solo. Durante este fin de semana he estado estudiando un poco y hoy, con la ayuda de Aimee, hemos empezado a limpiar el código. Me lo he pasado muy bien con ella y he aprendido mucho. Se nota que es muy buena profesora :) Me ha hecho comprender mejor cucumber y la importancia de expresarse correctamente en el código. Cada paso que dábamos parecía obvio, pero ya os digo yo que no lo era (de hecho, la semana pasada no veía el problema tan claro :P ) y los buenos nombres aparecían prácticamente solos.

Cucumber
Hemos empezado creando los escenarios que me faltaban para completar la descripción de la funcionalidad. Realmente, viéndolo ahora mismo, creo que fui muy vago. Con deciros que yo tenía 4 escenarios y ahora estamos en 10... Hemos ido creando cada escenario (y haciéndolo funcionar) de forma que, al final, tuviéramos una buena descripción de como funciona la selección de idioma en la página.

Además, los escenarios han ganado en expresividad y robustez. Los que yo hice tenían elementos de la vista "a la vista", lo que los hacía muy frágiles, y no hablaban de la abstracción correcta. Os pongo un ejemplo del antes y el ahora:



Hemos abandonado los detalles de la vista ("software que amarás") y hablamos de localizaciones en lugar de idiomas.

Mientras escribía el gist para el ejemplo se me ha ocurrido que aún no está del todo claro. He añadido un posible escenario algo más coherente con el naming ¿Qué os parece?



Hemos dejado de hablar de cookies porque no es interesante para el usuario. Lo que aún no tengo claro es si prefiero locale o idioma... Desde el punto de vista del cliente, lo que quiere es la página en varios idiomas. Mañana lo hablaré con los edenites ¿Vosotros que opinais?

Lo que sí que he sacado en claro hoy sobre cucumber, es que hay que intentar explicar la funcionalidad desde el punto de vista del cliente (de ahí que los escenarios los escriban los clientes :P ). No nos interesa mostrar detalles de implementación. Esto es fácil decirlo, pero, al menos para mi, no es fácil de hacer. Siempre se me cuela algún detalle de implementación...

Rack middleware
Además de añadir escenarios de cucumber, aunque la experiencia de usuario sigue siendo idéntica, hemos modificado todo el código responsable de la selección del idioma.

Lo que yo hice la semana pasada era seleccionar el idioma en el mismo método que me devolvía la página, provocando que el servicio web tuviera más de una responsabilidad. Steve me lo apuntó en la demo y me dijo que mirara los middleware de rack porque podían ser una solución al problema.

Basicamente, un middleware de rack filtra las llamadas a nuestra aplicación. En nuestro caso, lo vamos a utilizar para obtener el lenguaje preferido por el usuario y para establecer una cookie que recuerde dicho lenguaje. Esto permitirá que nuestro servicio web se desentienda de la selección del lenguaje, delegando dicha responsabilidad en el middleware.

No nos ha dado tiempo a dejarlo limpio del todo, pero ha mejorado bastante :D Estoy deseando que llegue mañana para dejarlo mejor :) ¡A ver si podemos ponerlo en producción pronto!

Un saludo.

domingo, 12 de diciembre de 2010

Dos semanas en Eden

Llevo un par de semanas en Winchester y me lo estoy pasando muy bien :D Es muy divertido ver como funciona Eden, todos los días estoy aprendiendo cosas nuevas y, por si fuera poco, estoy conociendo a mucha gente que merece la pena :D

Aunque el viernes me pudisteis preguntar todo lo que quisisteis en la #plagentrevista, tengo ganas de hacer una reflexión propia :P

Aspecto personal
Cuando surgió la oportunidad de venirme, no lo dudé. Tenía claro que no podía desaprovechar la ocasión. Aún así, no podía evitar ponerme nervioso. Otro país, otro idioma, un entorno desconocido, etc. Todas esas dudas desaparecieron el primer lunes :) Está siendo una experiencia espectacular :)

Una de las cosas que más me gusta de Eden es que se respira respeto por los demás y positivismo (palabro que no se si existe). Es algo que ayuda mucho a generar un entorno muy agradable y muy acogedor. Personalmente, quiero tratar así con la gente en mi vida normal, y estoy intentando forzar ese cambio. No es fácil, ya os lo digo. Evitar, por ejemplo, los típicos chascarrillos o bromas en plan "mira que eres paquete" (que es un desprecio hacia la otra persona), o intentar no buscar culpables (en la entrevista por ejemplo se me escapa un "no es culpa mía"...), es complicado porque es algo que tengo bastante interiorizado :P Aún así, se que tengo que cambiarlo y lo estoy intentando (el primer paso está dado).

Algo que, en ocasiones, es más difícil de manejar, es lo mucho que me queda por aprender. Raquel me lo preguntaba en la entrevista. ¿Cómo llevas lo de que te falte tanto por aprender sin agobiarte? La única respuesta que tengo es otra pregunta ¿Tengo alguna otra opción? Tenemos que hacernos a la idea de que vamos a estar toda la vida aprendiendo. ¿Nos queda mucho? Sí. Siempre nos va a quedar mucho. ¿Nos agobiamos? No. Eso no arregla nada. En lugar de agobiarte, practica :P Es parte del pensamiento positivo que, a partir de ahora, quiero tener :D

Aspecto técnico
De todo lo que estoy aprendiendo, sobresale sin ninguna duda la importancia que tiene que el código sea expresivo. Me gustó mucho algo que me dijo Enrique en la exposición del código de internacionalización de la página web. Chris me preguntó qué sería necesario modificar si quisieran añadir un tercer idioma. Yo conteste que, además de cambiar la experiencia de usuario, habría que tocar el código aqui y allá (resaltando el pobre diseño de mi código). Entonces, Enrique me dijo que era importante escribir el código lo más expresivo posible, de forma que no se tardara mucho en modificarlo para añadir un tercer idioma, permitiendo dedicar mucho más tiempo al problema importante, que en este caso es diseñar una buena experiencia de usuario.

Respecto a Ruby, nunca lo había utilizado "en serio" y tengo que decir que me está gustando mucho. Me parece un lenguaje muy expresivo y divertido. Aún me queda mucho por aprender, pero se que necesito dominar las colecciones. Muchas veces me lío por no conocer bien como funciona el Hash o el Array... Tendré que escribir alguna entrada sobre las cositas que voy aprendiendo. De momento, a parte de aprender el lenguaje, he utilizado Cucumber, RSpec, Sinatra, Rack, Bundler y rvm. Echadle un vistazo a todo eso porque realmente es impresionante. Sinatra es un alucine, Rack es la leche, bundler es super simple y RSpec y Cucumber molan mogollón. Si os apetece que escriba sobre algo en especial no tenéis más que decirmelo :)

Fuera del lenguaje en si, estoy aprendiendo a utilizar git de un modo más serio, aunque todavía en modo novato. Me está gustando bastante, la verdad, aunque ya os digo que todavía estoy empezando. Casi todo lo que hago lo subo a github (que me parece un flipe), por si os interesa cotillear :P

El viernes, Chris me enseñó lo fácil que es usar heroku y lo bien que se han montado el negocio :) Este fin de semana he estado trasteando un poco y he conseguido desplegar mi primera aplicación "Hola mundo" (que no hace nada, así que ni la enlazo :P ).
También me contó algo del servicio de Amazon EEC2, pero eso lo tengo muy verde. Espero que tenga tiempo para contarme algo más porque el proyecto que está haciendo me parece super interesante :D

Y no me podía olvidar de el vi (vim, macvim, etc). Está siendo todo un descubrimiento. No digo que sea intuitivo ni fácil, pero si consigues dominarlo, no creo que haya nada más productivo (y ligero). Como ya os dije, la curva de aprendizaje no es una curva, es una pared, pero eso solo implica practicar más. Se que no os voy a convencer de lo bueno que es (tampoco es mi objetivo), pero un día lo dominaré y entonces podré demostrároslo :P

Libros...
Ahora mismo tengo una pila de libros importante para leer. Por si os interesa, estoy con el "DDD", que me lo traje de España, con el "The timeless way of building" y con el "Structure and Interpretation of Computer Programs".

La guinda
Hoy, domingo, Enrique y yo nos hemos ido a Heathrow a comer con Sarah y J.B. Rainsberger. ¡Son muy simpáticos y divertidos! :D
La excusa de la comida era fijar la fecha para unos cursos en España pero, en realidad, ha sido más una comida entre amigos. Se ha hablado de todo menos de software :) Respecto a los cursos, deciros que parece ser que algo se hará, aunque todavía no tengo muy claro el qué (No por culpa del inglés, que conste :P Es que Enrique y J.B. parece ser que tienen un código secreto o algo así :P).

Resumiendo, me lo estoy pasando pipa y soy un programador feliz :D
Eso es todo, un saludo.

viernes, 10 de diciembre de 2010

Plagentrevista

Para los que no lo sepáis, Enrique y yo hemos hecho una "entrevista" a través de justin.tv en la que la gente que se conectaba nos ha hecho preguntas sobre Eden. Ha quedado un poco larga pero creo que tiene partes muy molonas :) Os voy a destacar un poco algunos momentos por si no os apetece verla entera :P

- Minuto 5 - Empezamos :) Antes de eso podéis verme haciendo un poco el ganso, pero no aporta mucho más :P

- Minuto 12:30 - ¿Por qué Eden en UK y no en España?

- Minuto 16 - Germán pregunta cómo hacen en Eden cuando detectan algo que va mal.

- Minuto 25 - Kini me pregunta cómo hacen programación por parejas en Eden.

- Minuto 29 - Raquel pregunta si los clientes de Eden están ya educados cuando llegan a Eden o si, por el contrario, hay que educarles.

- Minuto 35:40 - Raquel vuelve a la carga preguntando sobre la documentación que les exigen los clientes.

- Minuto 37 - De nuevo, Raquel nos pregunta sobre la asignación de personas a proyectos ¿Fijas? ¿rotan? ¿cada cuanto?

- Minuto 44 - Si queréis saber que tal va la página en español de Eden este es vuestro minuto :)

- Minuto 55:30 - Kini pregunta por los radiadores de información en Eden.

- Minuto 1:08:30 - ¿Eden desarrolla producto o solo proyecto?

- Minuto 1:17:45 - Jesús no se fía del vi como editor :P

- Minuto 1:18:45 - ¿Por qué Ruby?

- Minuto 1:20:30 - Steve aparece como invitado sorpresa :)

- Minuto 1:39:00 - Tour por Eden :) ¡No os lo podéis perder!


Watch live video from edendevelopment on Justin.tv

Y eso es todo :D Siento no haber escrito mucho hoy, pero creo que con la entrevista tenéis un rato para entreteneros :P Este fin de semana escribiré un mini resumen semanal o algo así :D

Un saludo

jueves, 9 de diciembre de 2010

Productividad

Aunque alguna vez ya os lo he contado, es alucinante lo que son capaces de producir en Eden. Una de las razones principales de su alta productividad es que son muy buenos, pero también es importante como funcionan como empresa en las tareas que no tienen nada que ver con tirar código (y derivados).
Dentro de ese grupo de tareas, me gusta como manejan el tema de las reuniones, así que os voy a hablar un poco sobre como las hacen y como no las hacen :P

En Eden les gusta más hacer cosas que hablar de si quieren hacer cosas, por lo que las reuniones, cuantas menos, mejor y, cuanto más cortas, mejor.
Como todas las cosas que ocurren en Eden, parece de sentido común, pero ¿cuantas veces os ha pasado eso de ir a una reunión a la que falta un asistente y habéis tenido que esperar a que llegue? o ¿cuantas veces os habéis ido por las ramas durante una planificación? Eso, en Eden no pasa. Si alguien no está para una reunión, se aplaza o se hace sin él. Si alguien se va por las ramas con algún tema, se le pide que lo discuta en otro momento. Tienen muy claro que una reunión es una perdida de tiempo y dinero y actúan en consecuencia.

Siempre que tiene que haber una reunión (una retrospectiva, una reunión de empresa como en la que se discutió sobre Eden Madrid, un grupo de estudio, la reunión diaria, etc) aparece la figura del facilitador, que enfoca la reunión y cuida de que ésta sea lo más productiva posible. Pero cuidado, no es que alguien diga: "Tú, facilita la reunión". Es algo más espontaneo. Simplemente, alguien toma la iniciativa.
Una cosa que me llama mucho la atención es que se pide turno de palabra levantando la mano. Aunque alguna vez se pisan (no son perfectos :P), intentan respetarlo al máximo, y siempre se piden disculpas si se saltan la norma. Ese ambiente de respeto suele hacer que sean reuniones bastante constructivas.

Otro punto importante es que las reuniones con los clientes no existen. El cliente siempre está ahí para conversar con él cuando es necesario (que es bastante a menudo). Es como si se hiciera una planificación continua, que no notas, pero que es muy eficaz.

Me parece que es una empresa muy madura y muy consciente del valor de su tiempo.

Un saludo.

PD: Mañana por la mañana es la presentación de la web :) No se si nos dará tiempo a ponerla en el servidor porque tenemos la comida de navidad (y porque quizás surja alguna idea interesante durante la exposición que involucre cambios), pero haremos lo posible :P

PD-2: Cada vez que escribo en el blog intento borrar lineas escritas pulsando "dd" :P Creo que estoy infectado :)

miércoles, 8 de diciembre de 2010

User Experience

Como ya sabéis, mi tarea semanal es traducir la web de Eden Development al Español. Aunque no esta siendo una tarea muy complicada, me está causando muchas más dificultades que el PlageServer.

Dificultades técnicas
A nivel técnico es una tarea muy sencilla. Los problemas que surgen en esta fase son , principalmente, culpa mía.
Para empezar, mi desconocimiento de Ruby hace que haga las cosas de una manera algo rebuscada, dejando un código no muy legible. Tengo que investigar más antes de lanzarme a tirar código. Soy demasiado impaciente.
Por si eso fuera poco, se me ha ido la cabeza y me he complicado la vida mucho más de lo que era necesario :S Menos mal que Enrique me ha encauzado y he vuelto a enfocarme en la tarea principal.
Aunque estoy aprendiendo mucho, aún caigo en los mismos errores del pasado. Como ya os he comentado en alguna ocasión, a veces se me va el desarrollo de las manos por no pensar bien en lo que estoy haciendo :(

Problemas en la experiencia de usuario
Pero sin duda, las dificultades más grandes están surgiendo a la hora de diseñar una buena experiencia de usuario.
He estado con Spencer un rato viéndole diseñar la modificación de la página mientras pensábamos en el problema :) Ha sido brutal. De hecho, todos los de Eden son brutales. Es espectacular verlos manejar el código con el Vim, casi no me da tiempo a ver las modificaciones que hacen en el código. Nunca había visto programar tan rápido y, a la vez, de forma tan precisa. Están a años luz. De momento, a mi ya me han convencido. Hay que dejar de usar IDEs y pasarse a Vim o similares. Cuesta entrar, pero merece la pena (aunque yo soy un paquete aún).

La duda más importante que nos ha surgido es si queremos que un usuario con el Español como idioma de preferencia sea redirigido directamente a la página en Español o, si por el contrario, es mejor presentarle la página en Inglés y darle la opción de cambiar la página a Español.
Si elegimos la opción en la que el usuario debe seleccionar en que idioma quiere la página, la siguiente duda es si debemos recordar su selección (con una cookie) y no volver a preguntarle. Si hacemos esto, solo se podrá cambiar el idioma una vez la cookie sea eliminada. ¿Deberíamos tener una opción para cambiar el idioma cuando quiera el usuario? Entonces, ¿para qué darle la posibilidad de elegir al principio?
Espero vuestras sugerencias :P

Nunca antes me había tenido que enfrentar a este tipo de cuestiones (al menos no tan "a fondo") y por eso me cuesta pensar en una buena solución. Me gusta como lo hace github (te presenta la página en inglés y te dice que la página está disponible en español en un mini-banner. Luego tiene también una opción para cambiar el idioma que seleccionaste en su momento), pero parece que a Spencer no le ha convencido para este caso :)

Mañana tocará definir bien lo que vamos a hacer y terminar la tarea (mejorar un poco la traducción y añadir algún test de cucumber, que lo he dejado para el final porque soy un paquete...). Enrique quería que hiciera la presentación mañana, pero no se si me va a dar tiempo :S Ya os contaré.

Un saludo

martes, 7 de diciembre de 2010

Hammock Driven Development

Ya os conté que una de las cosas que más me han gustado de Eden (y que más sencillas me parecen) es la parte de la reunión diaria en la que se habla de las cosas interesantes que ha descubierto la gente. Hoy, Steve nos ha contado lo interesante que le había parecido esta charla. Nos ha convencido de que merecía la pena verla y hemos quedado en proyectarla a la hora de la comida.

No es una charla técnica, es más bien "filosófica", así que no tenéis excusa para no verla :P

De todas formas, como tengo que escribir algo :P, voy a explicar algunos de los puntos que he sacado en claro tras la discusión que hemos tenido en Eden después de verla.

Hammock driven development
Básicamente, la idea central de la charla es como mejorar nuestra habilidad para resolver problemas. Hay una transparencia muy aclarativa en la que Rich Hickey, el creador de Clojure, nos recuerda que, si no estamos resolviendo un problema, para que demonios estamos trabajando (dentro del contexto del software). Además, se centra mucho en la importancia de entender el problema de forma global, no solo en el ámbito técnico.

Pensar y reflexionar sobre el problema
Nada más empezar, Rich nos hace una pregunta

¿Cuanto hace que no piensas en un problema durante toda una hora? ¿Durante todo un día? ¿y durante un año?

No se vosotros, pero yo no me paro a pensar "demasiado" en el problema ni en su por qué. Intento buscar una solución lo antes posible. Esta charla me ha recordado que lo importante no es la solución, es entender el por qué (a lo mejor no hace que busques una solución porque realmente no existe un problema). Me lo apunto como "a mejorar" :)

Además, ese pensar en el problema va a hacer posible que tu cerebro asimile que es importante y trabajará en "background" en ello.

¿El cerebro trabajando en background?
A lo que se refiere el autor con esto es al trabajo que realiza tu subconsciente mientras, por ejemplo, duermes (De ahí lo de hammock driven development, que es algo así como desarrollo dirigido por hamaca :D )
Rich deja claro que la charla no es un estudio científico ni nada de eso, así que no os lancéis como leones :P pero, ¿Nunca os ha pasado eso de encontrar la solución mientras dormías?

Enfocarse en profundidad en el problema
Esto implica pensar en el problema sin distracciones (nada de twitter, mail, teléfono, etc), es decir, hay que separarse del ordenador (suena duro, ¿no?). Para nosotros, los ordenadores son nuestra herramienta preferida para la procrastinación y el desenfoque, así que, en los momentos en los que se está enfocado en el problema, hay que intentar dejarlos a un lado.

Anotarlo todo
Personalmente, una de las cosas que más me ha chocado de la charla es que hace mucho hincapié en anotar todo lo que vamos descubriendo del problema. La razón principal es para no olvidar los detalles que ya se han descubierto. No se mete en como tienes que escribirlo, simplemente te aconseja que lo anotes.

No dejéis de ver la charla, es mucho mejor que mis notas :D

Un saludo

lunes, 6 de diciembre de 2010

¿Lunes? Menudo lunes

Es increible la cantidad de cosas que han pasado hoy en Eden :D
Tengo tarea nueva, hemos hablado de Eden Madrid, he asistido a una planificación de release, nos ha visitado un desarrollador de la zona y, por si fuera poco, el Agile South Coast User Group se ha reunido en nuestras oficinas (sí, nuestras, que yo también soy de Eden :P)

Nueva tarea semanal
Tengo que traducir al español la página de Eden :D En realidad lo que tengo que hacer es internacionalizar la página, porque en un futuro quieren poder traducirla también al alemán o al frances.
La web de Eden está hecha con sinatra y utiliza haml para las vistas. No tenía ni idea de lo que eran ninguna de esas dos palabras, así que la mañana la he pasado entendiendo la tecnología y buscando como internacionalizar aplicaciones que usan sinatra. La solución que he encontrado es utilizar r18n.
Tras una horita haciendo un spike para entender el funcionamiento tanto de sinatra como de r18n tengo que decir que ruby te hace la vida muy fácil :D No se que demonios hacía programando en java :P
Una vez descubierto cómo internacionalizar Eden, Spencer me ha hablado de la usabilidad de la web y de como puede afectarle el que esté disponible en varios idiomas.
¿Queremos que si vienes de España te aparezca la página en español? ¿Vamos a dar la poibilidad de elegir el idioma en el que mostrar el texto? En fin, una serie de preguntas de las que hemos sacado en claro que, aunque de primeras te aparezca en el lenguaje indicado por tu browser, debemos permitir seleccionar el idioma (aunque aún no sabemos como lo vamos a hacer).
De momento lo único que he conseguido es obtener la preferencia de idioma del navegador que consulta la página, mañana ya me meteré a fondo con la internacionalización de la página.
Otro problema que aún no he pensado como resolver es el de las pruebas. No estoy seguro de como montar las pruebas para probar la i18n.

Por si os interesa, he tenido que pelearme con unas expresiones regulares y Spencer me ha recomendado esta web. Me ha parecido super útil :D

Eden Madrid
Mas tarde, a las 13:00 nos hemos reunido para hablar de Eden Madrid. La idea era que los edenites decidieran si querían o no embarcarse en el proyecto Eden Madrid. Como siempre, ha sido una discusión abierta (incluso a los que venían de visita, a los clientes, etc) y honesta, en la que cada persona a expresado sus dudas.
Sin duda alguna, me quedo con lo que se preocupan por su empresa :) Está claro que les gusta.

Aunque la reunión ha sido muy reveladora, el resultado de la reunión no ha sido el esperado porque no se ha podido responder a las dudas planteadas. Dentro de una o dos semanas habrá otra reunión con algo mas de información y de la que quizás se salga con una decisión. Os mantendremos al tanto :)

Una de las dudas que han aparecido es si hay mercado en España para Eden (training, coaching y proyectos)y, si lo hay, cuanto tardarían en encontrar un cliente. ¿Vosotros que pensáis?

Release planning
Después de la comida (sí, la reunión de Eden Madrid la hemos hecho mientras omíamos) he participado en una release planning con uno de los clientes.
Ha sido una conversación muy interesante en la que el cliente ha demostrado un grado de madurez muy alto, eliminando de la release las features que menos valor le iban a aportar y contestanto muy tranquilamente a todas las preguntas y observaciones del equipo (era una colaboración con el cliente de las de verdad) e incluso de fuera del equipo (nuestro visitante).
Me ha parecido un product owner al que le importaba de verdad su producto.

Visita de uno de los desarrolladores de la comunidad
Russel, uno de los fundadores de la Winchester Web Scene, ha estado hoy de visita y ha sido algo un poco espectacular. Ha trabajado con Aimee durante casi todo el día pero, lo mejor de todo, es que ha intervenido tanto en la reunión sobre Eden Madrid como en la release planning. Nadie se ha soprendido, salvo yo, y todo el mundo le ha tratado como a uno más. Se nota que están acostumbrados a este tipo de visitas.

Reunión del grupo Agile South Coast
Ha sido una reunión un poco extraña. Parece ser que el grupo está en horas bajas y esta debía ser una reunión "refundacional". De los regulares solo ha aparecido uno, el resto eramos un CSM que acudía a su primera reunión y la gente que estábamos en Eden.
No hemos hablado de nada ágil, pero tengo que decir que me ha impresionado mucho como han llevado el tema los edenites. En todo momento han sido constructivos, pero nunca condescendientes. Ha sido una demostración de como intentar revitalizar una reunión y, sobre todo, como revitalizar un grupo. Todos han intentado buscar soluciones, dejando a un lado toda la parte de buscar culpables y no aceptando justificaciones que no eran pedidas.


Esto es todo por hoy. Como veis, en Eden no tienes tiempo de aburrirte :) Animaos a venir de visita, esto tenéis que verlo por vosotros mismos :)

domingo, 5 de diciembre de 2010

Los valores de Eden

En una de las paredes de Eden hay pegada una tarjeta con una frase que resume qué es Eden:

Eden exists to enable people to achieve better, greater, more worthwhile things
Eden existe para permitir a las personas conseguir cosas mejores, más grandes, que valgan más la pena

No se a vosotros, pero a mi me gusta mucho :D

Como os he contado en las anteriores entradas, Eden se guía por una serie de valores que todos los "edenites" entienden, comparten y cumplen. De hecho, dichos valores los han decidido entre todos, como hacen con todo lo demás :D Todos los valores de Eden están relacionados con esa frase.

We build relationships (Construímos relaciones)
Eden no solo se preocupa de construir software. Además, se preocupa de construir relaciones de total confianza con sus clientes. Tienen claro están dejando en sus manos su reputación y su medio de subsistencia.

Por supuesto, también se preocupa de las propias relaciones entre "edenitas". De hecho, lo que más vas a ver en Eden son sonrisas :D

We have a mindset of mutual respect (Tenemos una mentalidad de respeto mutuo)
Esto es muy importante en Eden. Puede que existan diferencias de opinión, pero nunca se pierde el respeto hacia la otra persona.

De verdad, es alucinante. En estos 5 días no ha habido ni una sola falta de respeto entre "edenites", y por falta de respeto me refiero incluso al típico chascarrillo español en plan "será cabrón :)". Sí que lo he visto por ejemplo por parte del cliente, y también he podido comprobar como los "edenites" lo han cortado de raíz con un toque de atención.

We ask "why?" (Preguntamos "¿por qué?")
Eden quiere añadir valor al negocio de los clientes, por lo que necesitan tener claras sus motivaciones.
Lógicamente, si es bueno para un cliente, también es bueno para Eden. El nivel de exigencia que tienen les hace cuestionarse sus motivaciones con el objetivo de mejorar.

We craft excellence (lo hacemos de forma excelente)
Eden es un equipazo. Son gente muy buena en su trabajo y muy responsable. Dicha responsabilidad les lleva a entregar sólo código excelente. Si la funcionalidad no está al nivel que ellos mismos se exigen, no se entrega.

We are disciplined (Somos disciplinados)
No son disciplinados en el sentido de cumplir órdenes, son disciplinados en el sentido de ser responsables. Prefieren arreglar la raiz de los problemas antes que parchear los sintomas.

We learn aggressively (Aprendemos de forma agresiva)
Todos los miembros de Eden sienten pasión por su profesión y están continuamente aprendiendo (nuevos lenguajes, nuevas técnicas, etc.) y compartiendo lo aprendido con el resto.

We give generously (Damos generosamente)
Eden es realmente generosa. Se involucran con las comunidades (no solo con las relacionadas con el software), aceptan visitas, promueven actividades, etc.

Si se monta Eden en Madrid entenderéis mejor a que me refiero. Nos lo vamos a pasar piruleta :D

We value people (Valoramos a las personas)
Eden no permite que los proyectos y sus fechas de entrega entren en conflicto con la vida personal de los "edenites". Además, fomentan actividades que refuercen las relaciones personales entre los "edenites" (como por ejemplo la proyección de Avatar del otro día)

Tengo que decir que todo esto sale de forma natural. En ningún momento se "fuerza la amistad". Simplemente son buenas personas juntas en una oficina :)

We are honest and open, even when it's hard (Somos honestos y abiertos, incluso cuando es duro)
La confianza entre todo Eden permite una honestidad brutal. Si algo no gusta, se dice, aunque cueste.

Realmente, en la semana que he pasado con ellos la única vez que se dio un toque de atención fue para intentar mejorar la dinámica de trabajo de un equipo cliente. No fue gratuito, fue necesario, y el equipo cliente lo aceptó y reconoció el problema.

We are humble (Somos humildes)
Eden es humilde y los "edenites" son humildes. Saben que son muy buenos y que hacen las cosas muy bien, pero también tienen claro que aún pueden mejorar (Aunque yo ahora mismo no veo como :D ).


Eso es todo, ¿Qué os parece? Espero que esto os de una idea del tipo de compañía que es Eden (o lo que yo entiendo que es Eden), aunque realmente es mucho mejor :) En serio, tenéis que comprobarlo por vosotros mismos. Este tweet de Luismi Cavallé resume bastante bien como me siento después de esta semana :D

viernes, 3 de diciembre de 2010

Mi primera presentación en Eden

Como parte de mi internship en Eden cada semana tengo que dar una charla al resto de la compañía. La primera ha consistido en explicar como he desarrollado el PlageServer.

Qué es PlageServer
Ya os lo he contado en varias entradas. PlageServer es mi primera tarea en Eden. La idea era implementar un servidor web capaz de aceptar peticiones y devolver respuestas que cumplan la rfc2616.
Aunque no he conseguido terminarlo, si que me ha dado tiempo a completar la operación GET. Si queréis ver el código lo tenéis en github.

La presentación
Teníamos fijada la presentación para las 15:00 y, aunque no os lo creais, a las 14:50 estaba tan tranquilo en uno de los sofás de Eden. Normalmente me pongo muy nervioso cuando me toca hablar, pero hoy no ha sido así. Mis compañeros me han dado mucha confianza durante toda la semana y me siento bastante integrado, lo que me ha permitido relajarme y disfrutar :D Tampoco os penséis que gracias a eso la presentación ha sido perfecta. Me he liado tanto con el idioma como con el código en sí :D No ha sido un desastre, pero he ido demasiado rápido y creo que ha sido un poco confuso.

Una vez terminada la exposición, mis compañeros han comentado el código. Ha habido de todo, desde que era un código más o menos limpio hasta que era una mezcla entre OO y programación estructurada :D
Realmente, creo que podría haberlo hecho mucho mejor (sobre todo ahora que ya se hacerlo mal :P).
No se si os pasa a vosotros, pero hay un momento en el que el código se me va de las manos (y eso que hago TDD). Creo que tiene que ver con los test que defino. Puede que esté dando pasos demasiado grandes.

A pesar de todo, mis compañeros me han felicitado con un "well done" :D ¡Muchas gracias!

Feedback semanal
Una vez terminada la presentación y la ronda de preguntas/observaciones, le ha llegado el turno al feedback semanal.
Por un lado, mis compañeros me han contado como se sienten conmigo por allí. Valoran el que haya venido desde España, dejando mi trabajo y a mi pobre novia (a la que, por cierto, le dedico este post :D ) y se sienten cómodos conmigo :) Eso sí, tengo que intentar dejar la timidez en casa.
Por el otro lado, yo les he dicho como me siento con ellos. ¿Os imagináis mis palabras? Las podéis leer aquí :) También les he comentado que quiero programar más con ellos. Esta semana no hemos podido por varios motivos (gente enferma, nieve bloqueando las carreteras, etc) y quiero aprender de ellos :D

Resumiendo, todo va bastante bien. Estoy disfrutando como un enano de la experiencia y espero que se note en estas entradas :)

¡Un saludo a todos!

jueves, 2 de diciembre de 2010

Nevando a tope

Os pido disculpas de antemano porque la entrada de hoy va a ser muy cortita :( Intentaré redimirme el fin de semana.

Que bonita es la nieve
Hoy ha sido un día extraño en Winchester. Anoche nevó mucho y nos hemos levantado con unos 20 centímetros de nieve. Eso ha provocado un mini caos en la ciudad debido al cual solo hemos podido ir al taller tres personas de Eden (Enrique, Aimee y yo) y los cuatro compañeros que están por parte del cliente :S Cuando nos hemos querido poner a trabajar nos hemos dado cuenta de que no funcionaba internet, no sabemos por qué. El proyecto del cliente lo necesita (skype para pair remoto, consultas de documentación, etc), así que nos hemos bajado a trabajar a un café cercano que tiene WiFi :D Este tweet sirve como prueba. A la hora del almuerzo, el equipo del cliente ha decidido irse a Londres para evitar problemas con los trenes, lo que ha dejado a Aimee y Enrique compuestos y sin novio :P Esto nos ha llevado a adelantar la proyección de Avatar (edición de coleccionista), por lo que, aunque la película mola, no hemos trabajado demasiado :P
¿Os lo había contado? El otro día planeamos ver Avatar en Eden :) Otra de esas cosas que crean relaciones personales y que tanto se dan en Eden :)

Avances en el PlageServer
Mañana tengo la presentación del PlageServer y no va del todo mal, aunque quiero darle un repasillo esta noche. Tengo algún problema con los require que provoca que cucumber no funcione, pero he conseguido terminar el GET :D Además, es posible que mañana antes de la presentación pueda tener el post también terminado. No está mal para no tener ni idea de Ruby y Vi (que por cierto, le estoy cogiendo el gustillo :P A ver si me animo y os escribo algo) Personalmente creo que el código no ha quedado del todo mal, aunque seguro que mañana me darán caña a tope (eso espero) :D Si tenéis ganas, también podéis criticarlo vosotros en los comentarios o por twitter :)

Lo dicho, siento que sea una entrada tan corta, pero ha sido un día extraño y tranquilo.

¡Nos vemos!

miércoles, 1 de diciembre de 2010

Esas pequeñas cosas

Desde que he llegado a Eden no han parado de sorprenderme las cosas que suceden sin que nadie les de importancia y que a mi me dejan con una sonrisa en la boca :)

Una de las primeras sorpresas que me llevé fue como funciona el stand up diario que se celebra a las 9:30. La típica reunión corta en la que cada uno dice que hizo ayer y que va a hacer hoy. ¿Típica? Bueno, típica no es, porque Eden es diferente. La mayor diferencia es que no hay una reunión por equipo. Hay una única reunión en la que participa todo Eden (por skype si no has podido ir a la oficina) y todos los clientes que estén con ellos en las oficinas. Mola porque todo el mundo sabe lo que está haciendo todo el mundo y mola porque no hay diferencias entre técnicos, no técnicos, clientes, internos :P Todos somos iguales y todos somos importantes :)
Pero sin duda, lo mejor de la reunión sucede cuando termina la ronda. Entonces llega el momento en el que el que quiera puede contar cosas interesantes que ha descubierto en casa (Por ejemplo, Enrique hoy ha hablado de los koans para clojure). ¿No os ha pasado alguna vez eso de haber leído algo super molón sobre programación y no tener nadie con quien compartirlo en el trabajo? Pues aquí es casi obligatorio que lo compartas :D

El momento de antes de la reunión también es divertido y suelen surgir conversaciones curiosas en torno a la programación. Hoy, por ejemplo, ha surgido el tema "frameworks sí, frameworks no" que tanto gustó en el AOS2010 :D
Espera, que no me lo creo del todo. ¡Mis compañeros hablan de programación en el trabajo! Moooola. Y además nadie les mira como si fueran frikis :P (Lo digo porque a Alfredo y a mi alguna vez sí que nos han mirado raro...)

Otro de los momentos en los que surge la magia es la hora de la comida. Todos los días ha pasado algo divertido e inspirador.
Mi primer almuerzo, como ya os conté, sirvió para que me contaran como ven la empresa, por qué es como es, etc.(Tengo ese tema pendiente, no me olvido) Todo de una forma muy natural y abierto a todo el que quisiera escucharlo.
El segundo día Chris nos contó como estaba enseñando a programar a su hijo de 6 años. Está utilizando un programa que simula un enfrentamiento entre robots y tu tienes que programarte el tuyo. Aquello dio paso a una discusión en torno a la mejor manera de acercar a niños tan pequeños a la programación bastante didáctica :)
Después, Enrique nos hizo la kata de los números romanos a unos cuantos curiosos en menos de 5 minutos (y creo que en mucho menos), dejándonos ojipláticos.
Hoy nos hemos juntado como grupo de estudio de patrones de diseño y hemos hablado sobre el Singleton. No nos ha tocado el más divertido pero aún así ha sido una charla interesante. Además, me he enterado de que twitter usa el 3% de sus servidores para Justin Bieber :O

De todo lo que os he contado, lo que me parece más importante es lo fácil y espontáneo que es, y el hecho de que sea abierto a todos los que quieran acudir (por supuesto, no es obligatorio), ya sean clientes o personal de Eden porque, mientras estás en Eden eres Eden :D

PD: El servidor va mejor :D Hoy he conseguido resolver un GET de un navegador :P Lo malo es que después me lo he cargado en la fase de refactor... El código no está del todo mal, aunque imagino que el viernes me meteran caña a tope :D

martes, 30 de noviembre de 2010

Una retrospectiva en Eden

Ya se que os tengo que hablar de los valores de Eden, pero hoy he podido asistir a una retrospectiva con un cliente y prefiero contaros como se lo montan :D Sobre los valores os prometo una entrada el fin de semana.

Antes de entrar en harina, hoy he conocido a Frances y bueno, super amable y encantadora. Además, nos ha traido una tarta de chocolate hecha por su hermana que estaba muy rica. Parece ser que mañana nos va a traer unos mince pies caseros que, por lo que dicen, son de chuparse los dedos :)

Hablemos de la retro
La retro de hoy la ha facilitado Aimee y han participado, por parte del cliente, las 4 personas que hay ahora mismo en Eden, y por parte de Eden, Enrique, Steve (via Skype porque sigue enfermo), Aimee y yo (Yo por parte de Eden, ¿qué os parece? Alucino :P ), aunque básicamente he ido a curiosear.

La retro ha empezado de una forma muy chula. Los implicados hemos entrado en la sala y nos hemos sentado alrededor de una mesa redonda. Delante nuestra teníamos una nota que decía:


Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Independientemente de lo que descubrimos, entendemos y creemos firmemente que todo el mundo hizo el mejor trabajo que pudo, teniendo en cuenta lo que sabían en ese momento, sus destrezas y habilidades, los recursos disponibles, y la situación actual.

Actualizado: Aimee me ha pasado el enlace a la cita original :D

Todo el mundo ha leido la nota y se ha mostrado de acuerdo :) (uno por uno hemos dicho "estoy de acuerdo")

Después, se han fijado unas reglas básicas (no se como traducir ground rules) para la retro entre todos los asistentes. Por ejemplo, hay que pedir la palabra levantando la mano, o queda prohibido faltar al respeto a la gente, o hacemos media hora, paramos y luego otra media hora.

Una vez fijadas las reglas, Aimee nos ha pedido que escribieramos en postits eventos importantes que han ocurrido en las dos semanas de proyecto que se iban a retrospectivar (un evento por postit). Algunos ejemplos, Enrique ha escrito que el 14 de noviembre estaba en Madrid en un curso de TDD (que es igual que escribir que no estaba en Inglaterra pero mola más :D), que el 23 fueron a las oficinas del cliente, etc. Supongo que os hacéis una idea. Una vez escritos los postits, los hemos que colocarlos en un calendario en su correspondiente día. Ha quedado algo parecido a esto:


Luego hemos puesto en común los eventos que ha escrito cada uno y hemos dibujado nuestra línea de "sentimiento" del proyecto. Os lo enseño y después os lo explico:


La línea punteada representa el estado "neutral", ni frio ni calor. Cada línea continua representa el sentimiento de un miembro del equipo durante las dos semanas de proyecto.
Una vez que todos los miembros del equipo han dibujado su línea (la mía es la roja :P) cada uno explica por qué la línea es como es, lo que da lugar a que todo el mundo sepa como se siente cada uno de los implicados.
No se ha vosotros, pero a mi me ha parecido una forma muy chula de expresar el bien y el mal del proyecto y, lo que es más importante, de compartirlo :)

Esto nos ha consumido la primera media hora, así que hemos parado para beber un poco, ir al baño, lo típico. Cinco minutos después hemos vuelto al ataque.

La segunda parte de la retrospectiva la hemos dedicado a tratar los problemas que más han afectado al proyecto. Para decidir que temas eran los que más importaban hemos juntado los postit-evento por temas y hemos votado los temas (7 puntos y puedes asignar tantos puntos como quieras a cualquier tema). Se han seleccionado los tres más votados y se ha charlado un rato de cada uno. En el momento en el que la discusión dejaba de tratar sobre como trabajar mejor para centrarse en detalles muy específicos del proyecto, alguien pedía tiempo muerto y cortaba la conversación. Esto mantenía enfocada la reunión.

Como punto y final de la retro, Aimee ha apuntado las conclusiones y las posibles mejoras en tarjetas y las ha dejado pegadas a la pared para que todo el mundo las pueda ver.

Y eso es todo, la verdad es que me ha parecido una forma muy amena de llevar una retrospectiva.

Nos vemos :)

PD: El servidor va igual que ayer porque hoy he borrado todo lo que hice y lo he vuelto a hacer desde otro enfoque :S Esperemos que mañana avance algo más.

lunes, 29 de noviembre de 2010

Eden por dentro

Hoy he empezado mi internship en Eden y tengo que deciros que esto es la caña. He conocido a Chris, Todd, Spencer, Juliet y Aimee y son todos muy simpáticos y muy amables. Entre Chris y Aimee me han explicado lo que es Eden y me han pasado su "código de valores" (A ver si mañana os blogueo algo). Sinceramente, es una empresa espectacular. No se muy bien como explicarlo, pero escucharles contar como sienten la empresa y verlos en acción con sus clientes deja bien claro que su máximo interes es hacer que las personas se superen. Es muy inspirador.

Aimee y Steve iban a ser los encargados de darme caña estos primeros días, pero Steve (al que conocí en la Software Craftsmanship y al que todavía debo una cerveza) está enfermo y le ha tocado a Aimee lidiar conmigo :) Lo primero que hemos hecho Aimee y yo ha sido modificar la web de Eden. Supongo que la mayoría ya os habréis dado cuenta del cambio :P El proceso entero ha sido muy sencillo. El código está en github y el deploy se hace con un comando. A prueba de plagelaos :)
Más tarde, Aimee me ha encargado (ha petición de enrique vía email) una tarea algo más compleja. Me ha pedido que realice una implementación de un servidor web que cumpla la rfc2616 :) Además, tendré que hacer una exposición sobre el tema el próximo viernes... Por supuesto, hay que desarrollarlo usando TDD (Con Cucumber y RSpec). Para añadir algo de dificultad al ejercicio, me he propuesto hacerlo en Ruby y utilizando el Vim (bueno, el MacVim, que es algo más amigable) ¿Qué puede salir mal? Pues nada, porque hemos venido a aprender y a mejorar, y eso no se consigue dentro de tu zona de confort. Hay que tirarse a la piscina.
Por si os interesa el código lo estoy dejando en github, aunque estos próximos días os iré contando mis dudas y las soluciones. De momento, hoy he aprendido a lanzar todos los specs de mi proyecto a la vez :P Os cuento como lo he hecho. Me he creado un fichero spec_helper.rb en el que he metido todos los ficheros con specs como require. Después lo único que hago es ruby spec_helper.rb y automagicamente se ejecutan todos los tests. Supongo que habrá alguna forma más sencilla de hacerlo ¿Me la contáis? Tampoco me importaría mirar un poco como funciona autotest...

No quería terminar sin agradeceros a todos los ánimos que me estáis dando :D ¡Muchas gracias!

Por cierto, creo que en Madrid ha nevado hoy ¿no? Aquí ha salido el sol por la mañana :) La vida puede ser maravillosa, que decía aquel.

Saludos del "Lucky Bastard" :P

PD: Me dejo muchas cosas en el tintero (Todd explicándome que si tengo algún problema no dude en hablar con él, Spencer recogiéndome en el B&B para llevarme a Eden, el bollo que me ha comprado Juliet, las cañas que nos hemos tomado al salir con los chicos de la empresa cliente a la que están ayudando de la que no recuerdo el nombre ahora, etc). Todo genial.

domingo, 28 de noviembre de 2010

Un plagelao en Winchester

¡Sí, ya estoy en Winchester! De momento (no podía ser de otra forma) todo está siendo espectacular.

Para empezar, Enrique Comba me ha ido a recoger a la estación y me ha acompañado a lo que va a ser mi casa durante este mes, Flowerdrews. Es el B&B que me buscó Juliet Arnott y es increíble (además de calentito). Siento no tener cámara de fotos (sí, soy lamentable), pero os lo recomiendo 100% a todos los que vengáis a Winchester. Es un sitio bastante tranquilo, las habitaciones son enormes y la pareja que lo lleva es super amable :)

Después de dejar la maleta y la mochila en la habitación, Enrique me ha llevado a las oficinas de Eden Development. "Yo... He visto cosas que vosotros no creeriais" :P Las oficinas reflejan todo lo que Enrique nos ha contado tanto en el aos2010 como en la lista de agile-spain. Hay restos de inceptions, story boards, libros, teclados Dvorak, sillas con nombres de bólidos, un globo-clon y muchos Macs ("ordenadores de verdad" los llama Enrique). Un pasote :) Sin embargo, lo que más me ha llamado la antención es la cantidad de espacio "libre" que tienen. De hecho, Enrique me ha contado que ellos no tienen un sitio fijo en el que trabajar. Cada uno trabaja donde le da la gana (o donde haya elegido su pareja, claro). Estoy deseando ir mañana para ver el taller a pleno rendimiento :) Va a ser una pasada.

Tras la visita a las oficinas de Eden, nos hemos ido de ruta turística por Winchester. Hemos visto al Rey Arturo, el mercado de Navidad, el centro de la ciudad, la catedral (testimonio gráfico incluido), etc, aunque lo mejor ha sido la charla durante el recorrido, saltando del software a la fotografía, pasando por la comida y, como no, por Eden Madrid :)

Siento que la entrada sea tan cortita, pero estoy baldado y mañana va a ser un día duro. De hecho, una de las cosas que me ha dicho Enrique es que esta primera semana las voy a pasar canutas, así que me voy a dormir :) ¡Mañana más!

miércoles, 24 de noviembre de 2010

Más sobre S.O.L.I.D.

En el último post os intenté convencer de que habíamos conseguido no violar el principio de inversión de dependencias con nuestra clase Banco. Si no lo recordáis, nos quedó algo como esto:



José Luis Barrera me sugirió en los comentarios que utilizáramos una clase Credenciales que agrupara tanto el nombre del usuario como el Pin. Con esa nueva abstracción, el código de Banco queda aún más claro:



Guay :D

Ahora bien, ¿qué ocurre cuando la validación de las Credenciales falla? Tal y como tenemos ahora mismo nuestra implementación, OperacionesBancarias lanzaría una excepción por cada tipo de error que se produzca al validar el usuario. Por ejemplo, si lo que falla es que las Credenciales son incorrectas se produce una excepción CredencialesIncorrectas. Si lo que sucede es que la validación de las Credenciales ha sido fallida más de tres veces, la excepción que se lanza es una AccesoInvalidadoPorMultiplesReintentosFallidos. Si lo que se produce es un error en el acceso al banco real, se lanzará un BancoInaccesible.
Veamos como implementaríamos un cliente de Banco (un Cajero) que se preocupe del resultado de la validación:



Pues no parece que sea muy legible... No se vosotros, pero yo estoy bastante acostumbrado a este tipo de código y tengo que decir ¡basta ya!
Las excepciones que captura Cajero no son parte de la abstracción de Banco, son detalles de bajo nivel que se encuentran en OperacionesBancariasBancoManolito, con lo que estamos volviendo a violar el principio de inversión de dependencias. Además, estamos controlando el flujo del programa mediante excepciones. ¡Que desastre!

Las excepciones deberían ser para casos excepcionales
Como bien nos contó (recordó) Enrique Comba en el curso de T.D.D., las excepciones deben ser excepcionales. No tiene sentido usarlas para controlar el flujo porque, en ese caso, dejan de ser excepcionales. Esto que parece tan trivial es una de las cosas que más nos cuesta cuando nos ponemos a programar.
Con esto en mente, volvamos a nuestro ejemplo, ¿Es excepcional que unas Credenciales sean incorrectas? ¿Es excepcional que un Banco tenga que anular una tarjeta porque el usuario se ha equivocado n veces al intentar usarla? De nuestro ejemplo, el único caso "excepcional" puede ser que el banco real no esté accesible pero ¿de verdad es tan raro que haya un corte de comunicaciones? Para mi, ninguno de estos casos es merecedor de una excepción, así que vamos a intentar arreglarlo. Lo primero que vamos a hacer es que Cajero no dependa de los detalles de OperacionesBancariasBancoManolito (y si de paso evitamos controlar el flujo con excepciones, mejor que mejor). Para ello, vamos a pasarle al Banco la responsabilidad de avisar al Cajero cuando suceda un evento de validación (correcta, incorrecta, invalida, sin conexión). Refatorizamos nuestro Banco para que quede como sigue:



y nuestro Cajero ahora queda mucho más limpio:



Aunque nuestra clase Cajero ha quedado mucho más clara, hemos pasado el problema de las excepciones a la clase Banco. Además, estamos violando el principio de segregación de interfaces (I). Vayamos paso a paso.

Segregación de interfaces

Clients should not be forced to depend upon interfaces that they do not use.

Los clientes no deben verse forzados a depender de interfaces que no usan.

Para cumplir este principio, nuestra clase Cajero debe implementar un interfaz para manejar los eventos de validación, que es lo único que la clase Banco necesita conocer de Cajero:



Y nuestra clase Banco dejaría de depender de Cajero para depender de dicho interfaz:



Ahora que nuestra clase Cajero ya cumple el principio de segregación de interfaces, arreglemos Banco.
La solución que se me ha ocurrido es que sea la abstracción Token la que nos de la información que actualmente nos dan las excepciones:



Ahora el flujo ya no es guiado por excepciones pero, lo que me parece más importante aún, es que nuestro código ahora es más sencillo de extender. Antes necesitábamos ir a un javadoc (o similar) para leer que tipo de excepciones eran necesarias para que Banco funcionara, ahora basta con implementar Token.

Por último, tengo que decir que no me gustan las estructuras if-elseif-elseif-else, pero para este caso en particular no me parece tan horrible. Si los motivos por los que Token puede no ser válido fueran más o pudieran cambiar más a menudo me pensaría una solución con suscriptores similar a la que hemos utilizado con el Cajero. Si os apetece hacerlo os lo dejo como ejercicio :P

Perdonad que me haya quedado una entrada tan larga y atolondrada. Espero que al menos se entienda lo que he intentado expresar :D ¡Nos vemos en la siguiente!

Nota: No haría estas refactorizaciones que he hecho aquí si no tuviera una buena base de pruebas contra las que probar cada pasito.

jueves, 18 de noviembre de 2010

Violando la D de S.O.L.I.D

A principios de semana tuve la suerte de asistir al curso de TDD que impartió Enrique Comba en Madrid. Me lo pasé genial pero me fui aún más convencido de que programar es muy difícil.
Aunque el temario del curso fue bastante amplio, yo sólo voy a centrarme en los principios S.O.L.I.D. Si queréis saber más sobre lo que hicimos allí, Jesús Jiménez ha escrito este post explicándolo.

El primer día del curso, Enrique nos dividió en 5 grupos y nos asignó la exposición de un principio S.O.L.I.D. a cada equipo. A nosotros (Amalia Hernandez, Jesús Jiménez, Leo Antolí y yo) nos tocó explicar la D.

Inversión de Dependencias (D)

High level modules should not depend upon low level modules. Both should depend upon abstractions
Abstractions should not depend upon details. Details should depend upon abstractions

Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones
Las abstraccciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones

Cuéntamelo con código
El segundo día lo dedicamos a crear el software que controla un cajero automático (haciendo T.D.D., claro). El código que creó nuestro equipo (los mismos cuatro que el día anterior) lo tenéis completo aquí, pero yo me voy a centrar sólo en nuestra implementación de la clase Banco:



Lo que hace la clase Banco es realizar una petición de validación mediante el Conector a una url. Dicha validación nos devuelve un json a partir del cual se puede crear el token de seguridad con el que se realizarán las siguientes operaciones del usuario validado.

¿Habremos sido capaces de respetar el principio que nos tocó explicar el día anterior?

Los módulos de alto nivel (Banco) no deben depender de módulos de bajo nivel(Implementaciones de Conector y GeneradorToken), ambos deben depender de abstracciones. Nuestro Banco depende de la abstracción Conector y de la abstracción GeneradorToken, pero no "conoce" que implementación de cada abstracción está usando (Ambas se le inyectan en el constructor). Parece que esta parte es correcta.

Las abstracciones (Banco) no deben depender de detalles. Los detalles deben depender de abstracciones. En esta parte es donde hemos metido la pata. Si Banco no debe depender de detalles ¿Qué pinta la construcción de la url contra la que debe operar el Conector? ¿Por qué el Banco conoce que el Conector devuelve json?

Pensando en esto se me ocurre el siguiente refactor de Banco:



Nuestro módulo de alto nivel depende ahora de una abstracción más general, dejándole a los módulos de bajo nivel (Las implementaciones de OperacionesBancarias) todo lo que tiene que ver con la infraestructura (tipo de comunicación, transformación de la respuesta, etc). Pero, ¿no es el token un detalle de bajo nivel? Si la respuesta es afirmativa deberíamos eliminarlo de Banco y OperacionesBancarias devolvería directamente la Cuenta, haciendo que nuestra clase Banco fuera redundante. Sin embargo, yo (que soy el que está programando :P ) creo que cualquier autenticación bancaria me va a devolver un token (hablo desde la ignorancia, pero suena bien) con lo que deja de ser un detalle para formar parte de la abstracción. Eso sí, no estaría mal que fuera una clase Token en lugar de un String, que no todos los tokens tienen porque ser iguales. La clase Banco que no viola el principio de inversión de dependencias quedaría así:



Conclusiones
Yo ya conocía los principios S.O.L.I.D. y se que mis compañeros también (aunque de este código tenemos la culpa Leo y yo :D ). Nos habíamos preocupado de leerlos y de intentar entenderlos mucho antes de dar este curso. Entonces, ¿por qué no fuimos capaces de recordar la dichosa D. incluso habiendo tenido que explicarla el día anterior? Yo pienso que es porque no lo tenemos interiorizado. Hace falta mucha práctica y mucha experiencia trabajando con los principios S.O.L.I.D. en la cabeza para que no se te olviden mientras programas. Por eso considero importante practicar T.D.D. con ejemplos sencillos, porque lo importante no es resolver el problema, lo importante es el proceso mental con el que resuelves el problema.


Criticadme, por favor
Lo que os he contado en este artículo es como entiendo yo el principio de inversión de dependencias. ¿Coincide con lo que entendéis vosotros? Si no es así, ¿en que me he equivocado?

lunes, 25 de octubre de 2010

Pair Programming Cara a Cara

Hace poco he empezado a tomarme más en serio mi relación con la Software Craftsmanship.
He decidido andar "El Largo Camino" (The Long Road).

Mi largo camino
En el Coderetreat que organizó Agilismo.es (patrocinado por Autentia y Eden Development ¡Gracias!) tuve la suerte de desvirtualizar a Enrique Comba el cual me regaló una copia del "Apprenticeship Patterns, Guidance for the Aspiring Software Craftsman". Si os interesa la Software Craftsmanship tenéis que leer este libro. Entre otras muchas cosas, algo que deja claro es lo importante que es relacionarse con otros, aprender de otros y enseñar a otros.

A su vez, hace poco que un grupo de españoles (vale, también había un argentino) fuimos a la conferencia SC 2010 en Bletchley Park. El mensaje que Jason Gorman quiso transmitirnos allí fue:

Enseñad vuestro código, enseñad lo que hacéis, difundid la palabra

Así pues, he decidido que, en esta parte del camino, voy a intentar relacionarme con la gente para enseñarles lo que hago y aprender lo que ellos hacen. Voy a compartir con otros mis experiencias.

Compartir con otros
Tras volver de Londres escribí un twitt ofreciendome a programar con gente con una sola condición, tenía que ser cara a cara. A aquel twitt contestarón varios apasionados del software. Aún tengo pendiente quedar con varios de ellos (no os he olvidado :P), pero ya he tenido mis dos primeras experiencias.

Apasionados
Mi primera vez (sé como suena) fue con @jjballano. Nos reunimos para hacer la kata "StringCalculator" en Java. No llegamos a acabarla (¿es una kata muy larga o solo me lo parece a mi?) pero sí que avanzamos bastante en la solución. Creo que, aunque empezamos haciendo ping-pong programming, no dejé participar demasiado a Jesús (no se como lo vio él, pero hice un refactor demasiado largo). Habrá que repetir y "arreglar" eso.

La segunda vez hice un trío (sé como sigue sonando) con @GermanDZ y @reemplazable :P Nos decantamos por esta kata en Ruby. Tras intentar instalar RSpec (sin éxito), acabamos usando Test::Unit y terminando la kata. Aprendimos un poquito de Ruby, @GermanDZ nos enseñó como afronta él las refactorizaciones y @reemplazable hizo una linea de código que nos dejó locos :). Creo que fuimos un poco rápido y 13'' no es lo mejor para tres personas, pero estuvo muy bien. Después nos tomamos las debidas cañas, que molaron igual o más :P

Futuro
Lo próximo que quiero hacer es grabar una de estas sesiones y subirla al internet para que la podáis ver todos.

Si os apetece programar una tarde conmigo no tenéis más que avisarme. Eso sí, daos prisa porque el próximo 30 de noviembre me marcho a Eden Development. Me han ofrecido hacer un internship y, si todo va bien, convertirlo en un apprenticeship :D Ya os iré contando.

Estoy muy contento y féliz :)

lunes, 10 de mayo de 2010

Principios ágiles #6

Hace muuuucho tiempo comencé una serie de post sobre los principios ágiles que hay detrás del manifiesto ágil. No se por qué, dejé de escribir en el blog y la serie se interrumpió. Hoy, a lo Fronkonstoin, voy a devolver la serie a la vida hablando del sexto de ellos (esperemos que dure):

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
El método más eficiente y efectivo de comunicar la información a un equipo de desarrollo y entre los miembros del mismo es la conversación cara a cara.

Comunicar información
¿Por qué hay gente que oculta información, que no comparte? Quizás para hacerse indispensables (como bien dice David Bonilla en su entrada sobre cajas negras). Que no os engañen, no lo son y no lo serán. Lo único que van a conseguir es aislarse de sus colegas de profesión y perderse todas las cosas buenas que hay fuera de su cubículo. Van a quedarse obsoletos.

Como decía Newton (aunque la wikipedia dice que fue Chartres):

Si he visto más lejos es porque estoy sentado sobre los hombros de gigantes

Si es bueno para Newton (vale, Chartres. Creo que se nota que soy físico) es bueno para ti.

Hay que salir, enriquecerse. Hay que aprender a ser humilde, a compartir tus conocimientos. Hay que enseñar lo que sabes y aprender lo que no sabes. Para todo esto es necesario comunicarse. No te conviertas en una caja negra.

A un equipo de desarrollo
Como he dicho ya muchas veces en anteriores posts, es importante que el cliente esté en contacto continuo con el equipo. Que sea capaz de comunicar sus objetivos y preferencias es una parte imprescindible de dicho contacto. Esto implica un nivel de compromiso por parte del cliente en el proyecto muy alto, siendo éste uno de los problemas más comunes en los equipos ágiles (al menos en los que yo conozco). Veamos un dialogo tipo:

- Hola, ¿vosotros sois ágiles?
- ¡Sí!
- ¿Cómo habéis conseguido involucrar al cliente en el ciclo de desarrollo?
- Respuesta 1: A no, eso no lo hemos conseguido.
- Respuesta 2: Nuestro cliente es interno.

Mi experiencia personal es del segundo tipo, así que tengo suerte :P Sinceramente, no se cómo resolver el primer caso :( Lo que sí que tengo claro es que, si no consigues que tu cliente se comprometa en el proyecto vas a pasarlas canutas...

Entre un equipo de desarrollo
Está claro que un equipo de desarrollo, si es sano ,debe estar en continua comunicación. Cuando se trabaja en intervalos de tiempo cortos es necesario que todo el equipo esté sincronizado de forma que se evite el trabajo duplicado. Igualmente, es muy importante que los miembros del equipo se encuentren comodos entre si, de forma que no resulte extraño que alguien pregunte cuando no sabe algo (No hay preguntas tontas ni respuestas estupidas, ya sabéis). Básicamente, es necesario que los miembros del equipo creen relaciones de confianza que ayuden el desarrollo de su trabajo (Todos trabajamos mejor con amigos alrededor ¿no? Huy, me ha salido muy piruleta esto último...).

Conversación cara a cara
Lo más eficiente no es ni usar el teléfono, ni el e-mail, ni el wave, ni el twitter, ni el skype... lo más eficiente (y por tanto lo deseable) es la comunicación cara a cara.

Pensad en la cantidad de herramientas que propone el agilismo a los equipos para que mejoren su comunicación. Desde el ¡Sienta al equipo junto! de Henrik kniberg a las reuniones diarias de Scrum sin olvidarme de algunas de las prácticas XP como la programación en parejas. Todas ellas se basan en la comunicación cara a cara, lo que debe dar una idea de su importancia.

Conclusiones
El sexto principio ágil:

  • Implica un alto nivel de compromiso en el proyecto por parte del cliente
  • Necesita que se den relaciones de confianza entre los miembros del equipo (incluido el cliente)
  • Señala la importancia de la relación directa entre las personas


Foto de "portada": Galería de Fernando en Picasa, bajo licencia Creative Commons.