El programador feliz

Me he mudado

2011-07-23T20:54:00.000+02:00

Hace tiempo que pensaba en cambiar de blog. Quería algo que no implicara acceder a la web para escribir y publicar, y quería ser yo el que alojara los posts (y no google).

Hace poco encontré lo que estaba buscando en Github, y ahora podéis seguirme en:

http://blog.plagelao.com

Un saludo y ¡Adios blogger!

Autotest: friend or foe

2011-05-15T21:50:00.001+02:00

For all of you who don't know what autotest is, it's just a ruby gem that lets you run your tests automatically in the background every time you make a change either in your code or in your tests. It is very clever, and a lot of people use it. You can see some examples in almost every screencast of a kata written in ruby.

Why I don't like autotest
Well, it's not that I don't like it. It is a very cool project and I've used it sometimes while performing a kata. My real problem with it is that it breaks the TDD cycle. Let me explain myself.

Running the test should be a blocking step
When we are doing TDD, we run the tests to get feedback. Then, we use that feedback to guide our code/design.
When we use autotest we are not waiting for the tests to fail, we just continue coding, ruining the TDD cycle.

Wait a second, I do not write any code till autotest tells me that there is a failing test.
Well done. Why are you using autotest then?

Update: Talking with Tom Brand the other day, he said that maybe it is ok to use autotest in the refactoring phase. I think he is right :)

XGN y Software Craftsmanship

2011-04-27T14:50:00.001+02:00

Hace una semana estuve pasándomelo pipa en la #XGN de Santiago de Compostela (Muchas gracias a la organización, que nos trató muy bien y muchas gracias a mis anfitriones de agil-az, que me llevaron a cenar cosas muy ricas). Alfredo Casado y yo dimos un par de charlas técnicas (refactorización y continuous delivery) y una charla sobre Software Craftsmanship.

Si quieres ver la presentación de la charla, aquí la tienes:

Software Craftsmanship: Convierte tu vida profesional en una Lan Party

View more presentations from plagelao

No tiene mucho sentido verla sin nosotros, porque casi todo son imágenes, pero podemos resumirla en esta cita de Pete McBreen:

Software development is meant to be fun, if it isn't, the process is wrong

El desarrollo de software se supone que es divertido, si no lo es, el proceso es incorrecto

Pete McBreen - Software Craftsmanship: The new imperative

5 Things I want to do today!

2011-04-25T09:30:00.000+02:00

Two weeks ago I was in Edinburgh. I attended the Scottish Ruby Conference and it was awesome! I met a lot of great people and I enjoyed a lot of great talks. But I want to talk today about one of the lightning talks that I had the pleasure to attend. It was not about code, technology or robots, it was about how to manage your time and how to set your priorities.

The idea
The idea is very simple. Before going to sleep, you have to write down the 5 most important things you want to do tomorrow. Once you've written them down, you have to prioritize them. Then, the next day you have to do the first task in your list. Once you finish the first task, you have to start with the second task. It goes on and on until you finish the 5 tasks or the day ends :P

The reality (My reality)
I've been doing this for two weeks, so I'm not an "expert" :P but I have some conclusions to share.

First of all, I feel much more productive :D "Planning" what to do the next day helps me to focus on the important things and shows me how difficult it is to achieve everything I want to do (pretty obvious. You can't do everything you want in a day :D )

Second, it is not easy to follow your plan :D I always start with my first task, and most of the times I continue with the second one, but, eventually, I get distracted. The thing is, there are a lot of things I want to do, and limiting myself to only five is not easy. Also, some of the tasks on the list are really bored (but still important), so sometimes I just ignore them...
Some other times, I just "forget" the priorities :)

And last, but not least, is not easy to write down the five most important things you have to do the next day.

Anyway, I think that this simple method is helping me a lot, and I recommend all of you to give it a try. Even if you are not able to follow "the rules", it is a great exercise.

BDD y Continuous Delivery en la XGN

2011-04-12T22:50:00.001+02:00

Este fin de semana estaré en la XGN de Santiago de Compostela y voy a intentar picaros un poco para que os animéis a venir. Como ya os conté, tengo tres sesiones junto con Alfredo Casado, pero hoy os voy a hablar de Teo crea su primera aplicación web (con Rails, Git y Heroku). La idea para esta sesión es hacer un taller en el que crearemos una aplicación web en Heroku utilizando Rails. Sin embargo, para hacerlo un poco más interesante, lo vamos a hacer al estilo Software Craftsmanship, lo vamos a hacer usando BDD y Continuous Delivery. ¿Os hace?

Continuous Delivery
Vamos a aprovechar lo fácil que nos pone las cosas Heroku para practicar (y entender) un poco eso de Continuous Delivery. Veremos lo que mola desplegar con cada commit y el nos daremos cuenta del cuidado que hay que tener cuando desarrollamos software (y no solo mientras escribimos el código).

BDD
Dado que vamos a desplegar la aplicación en el entorno de producción prácticamente con cada commit, necesitamos definir exactamente cada feature que vamos a desplegar. Para ello utilizaremos BDD (Utilizaremos Cucumber) de forma que cada vez que todas nuestras features ejecutables estén verdes podamos desplegar la aplicación sin ningún temor :D
Una pequeña cuña aquí. Nos vamos a dar cuenta de la importancia que tiene definir buenas historias de usuario de forma que nos sea sencillo crear features pequeñas y deployables. Por eso, os recomiendo el dojo de historias de usuario de los agilismo.es

Entorno
Si os apetece participar en el taller tenéis un par de opciones, podéis traer vuestro ordenador con git y ruby instalado o podéis traer vuestro ordenador con VirtualBox instalado y yo me encargo de daros una máquina virtual con todo instalado (Eso sí, esa máquina será un Linux con Vim como editor, ya os aviso :P).
Si os da tiempo, nos ahorraríamos algo de tiempo si os hacéis una cuenta en Heroku antes de asistir al taller.
Otra opción es que vengáis a cotillear, que también vale, pero es un poco más aburrido.

Ya sabéis, si quereis darle caña al continuous delivery no os podéis perder esta sesión. ¡Os espero!

PS: Por cierto, la aplicación que vamos a crear nos va a servir para sortear un par de Apprenticeship Patterns en la sesión sobre Software Craftsmanship, así que no podemos fallar :P

ACTUALIZACIÓN: Os cuento un poco las versiones de ruby y de las gemas que vamos a utilizar:

La versión de ruby será la 1.8.7
La versión de Rails será la 3.0.3.
Necesitamos también la gema de heroku, claro.
Después usaremos cucumber-rails y capybara. También le daremos al haml (haml-rails es la gema) y al Sass :D

My Vim configuration. Part 4 - Vim as an IDE

2011-04-01T22:00:00.000+02:00

Today I'm going to finish my Vim configuration explanation (Have a look at the previous articles). The final part of my configuration is related to the "IDE behaviour" in Vim.

Encoding
First of all, I have set my encoding to utf-8 with:

set encoding=utf-8

Indentation
I prefer spaces to tabs, so this is how I configure it in Vim.

filetype indent on
set tabstop=2
set softtabstop=2
set smarttab
set expandtab
set autoindent

Line numbers
If you want to see the line numbers in Vim you only need to do:

set number

Backspace
Default backspace behaves in a strange way :P I've changed it so it behaves in a more "normal" way:

set backspace=indent,eol,start

Search
One of the most important features in Vim is searching. I've configured mine so it is case insensitive (except if what I search has an uppercase character, then it is case sensitive)

set ignorecase
set smartcase

I also want Vim to highlight my search terms:

set incsearch
set hlsearch

And I have a shortcut to remove the highlighting:

nnoremap <leader><space> :noh<cr>

There are some more little things that can help you in making a more "personal" Vim, but I'm going to stop here :) Feel free to have a look to my vimrc file or, you know, google it :P

Thanks for reading :)

XGN en Santiago de Compostela

2011-03-22T10:00:00.002+01:00

Los próximos 15, 16 y 17 de Abril estaré en la XGN presentando algunas charlas junto a Alfredo Casado. La verdad es que tengo muchas ganas de estar por allí con todos los demás participantes (la gente de axilmente, las agile girls, los agilismo.es, los funius, los 1up talent, etc). Vamos a aprender mogollón y nos lo vamos a pasar piruleta :)

He podido cotillear algunas de las charlas propuestas por algunos de estos cracks y son realmente alucinantes :) Nosotros intentaremos mantener el nivel, que no va a ser fácil. Para ello, estamos preparando:

Convierte tu vida profesional en una lan party: software craftsmanship
Teo crea su primera aplicación web (con Rails, Git y Heroku)
¡Si funciona no lo toques!, ¿o sí?

Además, si todo lo que os he contado no os termina de convencer, se está organizando un openspace para el sábado en el que seguiremos hablando de desarrollo, agilismo, etc.

Si no tenéis reservada la fecha, reservadla ya. En serio, nos lo vamos a pasar piruleta.

PS: Iré publicando por aquí pequeños spoilers de las charlas para ir abriendo boca :P

Elige tu propia aventura

2011-03-11T20:00:00.006+01:00

Tras un par de semanas algo turbulentas, hoy ha sido mi último día como edenita.
El tiempo que he formado parte de Eden ha sido espectacular. Estoy muy agradecido a todos y cada uno de mis compañeros por creer en mi y por hacerme crecer tanto en lo personal como en lo profesional :) De verdad, muchas, muchas gracias por haberme brindado esta oportunidad.

Supongo que os preguntaréis qué ha pasado. Tranquilos, no he suspendido durante mi aprendizaje :P De hecho, voy a seguir siendo aprendiz de Aimee (¡yuju!). Simplemente, a veces las cosas no salen como uno espera y entonces es cuando tenemos que abrazar el cambio :D
Ahora empieza otra aventura :D Me voy a quedar en Inglaterra mejorando mi inglés y trabajando como autónomo. Después de mi internship pense en hacerlo en España, pero no terminé de atreverme. Ahora sí que me voy a lanzar :D Todavía no tengo muy claro los pasos a seguir (tengo bastante lectura acumulada para el fin de semana :D ), pero tengo compañeros que me van a ayudar en esta nueva etapa del largo camino (y también tengo un cliente :P ).

¡Nos vemos!

PS: Mañana tenemos code retreat en el taller :D Ya os contaré que tal.

My Vim configuration. Part 3 - Vim shortcuts

2011-03-11T09:00:00.001+01:00

Continuing with my explanation of my Vim configuration (you can have a look at my view settings and my plugin settings), today is the day of the shortcuts :)

Everyone of us love the shortcuts our favorite IDE has. Vim is no less and you can define whatever shortcut you need :)

How to define a shortcut in Vim
It is very easy to define a shortcut in Vim, you only need to map the key combination you one to use with the actual command you want to execute.
To map a combination you can use map or noremap (and all the variants for each mode, like imap, inoremap, nmap, nnoremap, etc...). The difference between map and noremap is that the second one is not recursive. You have a very good explanation here.
You can see an example of a shortcut definition:

This shortcut closes Vim without saving the file and can be executed by pressing the keys 'c', 'l', 'o', 's' and 'e'

Leader
The previous example is more or less a "hard code" shortcut :) A better way to map commands is using the leader variable, so you start your shortcut by pressing your leader combination.
To define your leader combination you only need to do something like this:

In this case, my leader combination is just the ',' key :)

It is important to define your leader combination because a lot of the existing plugins for Vim use it for their own shortcuts (mappings).

My shortcuts
Ok, now that we have defined the leader, let's have a look to my actual shortcuts.
The first one I want to show you is how to change between the actual buffer and the alternative buffer (If you don't know anything about Vim buffers, take a look at this video, it is great!)

What I'm doing here is mapping ',' and '6' to ':b#' (:b# is what you have to type to switch buffers when in normal mode. means that, after the command, I want to press 'return', executing the command). I'm using nnoremap for this shortcut because I want to use it only in normal mode (the first n of nnoremap) and because if some of my plugins map any ':', 'b' or '#' key to any command I don't want to execute that shortcut (not recursive), I just want to execute ':b#'.

The next shortcuts are related to some plugins I use:

I just map the NERD tree to ',d' and a little bit of help every time I want to use ack (only in normal mode) :P

Then, I have two shortcut for removing the extra spaces (at the end of the line) and to change tabs with 2 spaces :)

I also have a shortcut that changes the ruby hashes (with a symbol as key) from 1.8 syntax to 1.9 syntax:

And last, but not least, I map the tab as a match bracket finder:

I probably change all of this shortcuts in the future, when I get more experience with Vim, but I hope it shows you how powerful (and customizable) Vim is :)

PS: I know that the gist are not visible on google reader. Sorry about that! I want to move my blog and fix that :)

Sass is so cool!

2011-03-08T09:00:00.001+01:00

I have to admit that I didn´t know almost anything about CSS six months ago. I was an API developer and I never needed it. But now, everything has changed (I know, it should have changed before, but it didn´t). I need to improve my CSS skills and I need to do it quickly!

The thing is, I don't really like CSS. I find it a bit confusing and, every time I try to do something I end up doing a mess. What can I do? I need to learn SASS (Syntactically Awesome StyleSheets)!

SASS to the rescue
This is the first line you can read on the SASS page:

Sass makes CSS fun again.

And, do you know what? It is true!

What makes SASS funny
For me, SASS is funny because it brings programming concepts to CSS, and I love programming :D

Variables in SASS
Corey Haines said on Twitter that this year's color was #CB6586. If I start to use this color on my CSS I have two problems:

If I want to change it on january 1st of 2012 with the 2012 color I'm going to find all the places I'm using it (DRY violation).
I am not a color machine. #CB6586 does not mean anything to me (Not readable).

SASS solves those two problems with variables. We can define our color as:

And we can use that variable everywhere we want:

Mixins in SASS
Another DRY violation that I used to do with CSS is when I have to define effects (round borders, shadows, gradients, etc...) to the elements. I end up writing the same more than once (probably because I don't know almost anything about CSS, but probably because it is a very easy thing to do with CSS). SASS helps me to define mixins so I don't repeat my "code" every now and then.
An example of how to define a mixin to apply a gradient can be this one:

And we can use it like this:

Did you notice it? Mixins accepts arguments! How awesome is that?

More SASS awesomeness
You can find more cool SASS features on the official page. It is very simple and very useful!

Enjoy it!

My Vim configuration. Part 2 - Vim plugins

2011-03-06T10:00:00.001+01:00

I was supposed to talk about shortcuts in Vim, but I've changed my mind :P I'm going to talk about how to install plugins for Vim :)

Vim plugins
Vim has a lot of plugins, a lot :D So, how do I choose the plugins I need? Well, fist of all, you have to know what you need. This is very important, you shouldn't use a plugin if you're not sure about why you need it!

Once you've decided which plugins do you want you only need to install them!

How to install a vim plugin
Vim plugins are just scripts and to install them you only need to copy the script file in the right directory. Ok, this looks very similar to the way we add color schemes to our Vim, doesn't it? Yes, the only thing we need to change is the directory. When we install a plugin, we have to add the script file to the 'plugin' (or 'ftplugin' if it is a file-type-dependent script) directory in our .vim directory. Sooo easy :D

Yes, so easy. But, do I have to do that every time I get a new plugin or every time I update an old one? Cannot this process be automated? Yes, it can! There are a lot of tools to manage your plugin dependencies. I am using Vundle right now.

Vundle
Vundle is a plugin management tool for vim. It is very easy to set up and it is very easy to use. You only need to follow their instructions to "install" it. Once you have everything in its right place, you have to add those two lines to your .vimrc file:

This makes bundle available while you're using Vim :D

Vim plugins
Ok, so, how do I install plugins with Vundle? You only need to add the plugins you want to your .vimrc file (with the Vundler format). I have those:

As you can see, you can ask for the plugin by its "official" name or you can linked it to its github repository.

Once you've defined the plugins you want you only need to type:

on Vim to install or update your plugins :D

Ok, that's all for today. Soon on your screens "How to create shortcuts with Vim" (Although maybe I'll talk a little bit about why I choose those plugins)

My Vim configuration. Part 1 - View settings

2011-02-27T20:49:00.001+01:00

Lately, I've been trying to understand better how Vim works, so I've started looking at its configuration files. I forked Chris's configuration (that was the easy part :D ) and I removed everything I'm not using at the moment. You can see my actual configuration files here.

It was not easy for me to understand how everything works, that's why I'm going to write about it :D Let's start from the beginning, the vimrc file.

.vimrc file
You can find an explanation about the .vimrc file here. Basically, this file is loaded just before entering Vim and it contains our personal Vim configuration settings.
I'll try to explain every line of my vimrc file during the week but, today, I'm going to show you how to configure the "view" part (colors, syntax highlighting, status line, etc).

My Vim view settings

Now, we have a nice Vim window much more friendly than the initial one :D The only problem is that the color scheme is just the default one (which is not very good).

Adding color schemes to Vim
To add a color scheme to vim we first need to get one :D There are a lot of them. I'm actually using tir_black, but I have to try some more :D

Ok, you've selected one color scheme, how does Vim know about it? First of all, you need to create a .vim/colors directory in your home directory. Then, you have to copy the color scheme vim file to that directory.
That's all! Now, you can go to Vim and type

The only problem with this is that it is not a permanent change. Every time you close Vim, it will lose your color scheme preference.
What can we do about it? Easy, we just need to open our .vimrc file and add the following line:

Now, Vim knows our preferences :D

Ok, that's all for today. Soon on your screens "How to create shortcuts with Vim"

Vim macros

2011-02-24T21:28:00.000+01:00

I'm a total noob with vim, so I'm going to start a very basic series of blog posts writing down everything I learn :) Those are going to be very short posts explaining a vim feature. So, let's get started.

Today, I've been working with Tooky the whole day and he has taught me how macros work in Vim.
I can only imagine how powerful they are :D We've used one to rename a method (including everyplace it was called)

How to record a macro
First of all, we need to be on command mode. Then, we have to press 'q' and the key to store the macro ('qa' will store the macro in the key 'a'). We'll see the word 'recording' on the last line.

Everything we do then will be recorded (And I mean everything and on any mode).

To stop recording the macro, all we need to do is press 'q' on command mode.

How to execute a macro
All we have to do is to press 'q' and the key where we stored the macro (on command mode). To execute a macro stored in the key 'a' we have to press '@a'.

Recursive macros
We can make a recursive macro by recording a '@<key that stores the macro>'

Hope you find it useful :)

Estado de un plagelao

2011-02-22T09:00:00.001+01:00

Hoy voy a escribir un poco sobre como han sido mis tres primeras semanas en Eden a nivel personal. Os advierto desde ya que va a ser un post sobre como me siento yo, no sobre como funciona Eden. Si no os apetece leerlo, lo entiendo :D

Enrique continúa su largo camino
Estas tres semanas han dado para mucho pero, probablemente, lo más importante es la marcha de Enrique.
Como para muchos de vosotros, Enrique es una fuente de inspiración tanto en lo personal como en la profesional. Creo que soy muy afortunado por haberle conocido y por poder trabajar con él. ¡Gracias, Enrique! ¡Te deseo muchos éxitos y felicidad mientras cumples tus sueños!
Por suerte, Enrique se queda hasta abril (o no, depende de varias cosas :D ) en Winchester, así que aún podré disfrutar de su compañía algún tiempo más :)

Pero entonces ¿tú que haces?, ¿te quedas en Winchester o te vuelves a Madrid? ¿Qué pasa con Eden Madrid?
Estas preguntas me las habéis hecho varios y creo que a todos os he contestado lo mismo. De momento, yo me quedo en Winchester continuando con mi apprenticeship. Si todo va bien espero quedarme en Eden una vez termine, ya os iré contando. Respecto a Eden Madrid, aún no se nada.

Los edenitas
Como ya os conté durante mi internship, los edenitas molan todo y más :D Todos me están ayudando mucho a integrarme en Eden (tanto personalmente como profesionalmente), especialmente mi mentora, Aimee :)
Quiero hacer una mención especial para mi compañera de aprendizaje, Despo :D Compartir el apprenticeship con alguien que está pasando por la misma experiencia ayuda a no sucumbir a la presión que nos auto-imponemos. ¡Gracias, Despo!

Pair programming
Todo lo que programo en Eden lo programo haciendo pair programming. No estaba acostumbrado pero tengo que decir que es muy divertido, muy cansado y mucho más productivo (al menos para mi).
Es más divertido porque no estás solo :D Siempre tienes alguien con quien hablar :P
Es muy cansado porque te obliga a estar a tope de concentración. Echando cuentas, creo que el máximo de pomodoros que he conseguido terminar en un día han sido 10, que vienen a ser 4 horas y cuarto... Y sin embargo termino mucho más cansado que cuando trabajo solo en casa.
Es más productivo porque es mucho más difícil relajar las buenas prácticas. Siempre tienes a alguien al lado diciendo cosas como "Creo que ese nombre no es correcto" o "¿No deberíamos hacer un test antes?".

Futuro
No se lo que me deparará el futuro. Lo que tengo claro es que pienso disfrutar el presente :D

¡Abrazos!

Omniauth, Twitter and BDD

2011-02-20T23:15:00.000+01:00

Today I've (almost) integrated Twitter authentication for Let's walk the path together! I've used the omniauth gem to achieve this task. Thanks to this railscast, it is very easy to understand how to do it. But, we are doing BDD, aren't we? How do we do BDD against Twitter? That's what I'm going to tell you today :D

Omniauth
OmniAuth is a Rack-based authentication system for twitter (and many other services). Its rack middleware is the one that talks with twitter and puts the twitter user data in the env variable. You can watch the railcast to see an explanation of how it works (it's only 8 minutes).

BDD
Ok, I know how to integrate Twitter authentication in my application. How do I test it? How do I continue with my BDD cycle? When we are testing our application, we don't want to rely on the actual Twitter service. It will make our tests slower and brittle. We need to have control of our tests, so we need to fake the Twitter server. Fortunately, doing it with omniauth is very easy.
We only need to put omniauth in test mode and give it the information we want to receive from Twitter in our test:

In this case, we're telling omniauth to, when asked about Twitter, give us the provider, the user uid and the user name.

We can integrate this easy in a cucumber hook, or even in a cucumber step, to mock the Twitter server and continue with our BDD cycle :D

BDD y descargas de ficheros auto-generados

2011-02-17T09:00:00.000+01:00

La semana pasada, Tom y yo necesitábamos comprobar que un informe se descargaba correctamente desde la aplicación. Dicho informe era una hoja excel generada a partir de los datos contenidos en la base de datos. ¿Os interesa saber cómo lo hicimos? Os lo voy a contar con un ejemplo algo más simple :D

Escenario

Empecemos creando un escenario en cucumber. Queremos descargar un catálogo de productos generado por nuestra aplicación:

Steps
El given simplemente crea un producto en el sistema y el when descarga el catálogo:

Muy bien, hemos descargado el fichero al pulsar el enlace pero, ¿cómo accedemos a dicho fichero cuando estoy usando capybara y rack-test? Se me ocurren dos cosas. La primera es usar selenium en lugar de rack-test, haciendo que nuestros tests sean muuucho más lentos. La otra es obtener el bytestream del fichero descargado que, por si no lo sabíais, está en el body de la página obtenida tras hacer click en el enlace de descarga:

Esto tan simple funciona porque, en nuestro caso, estamos descargando un fichero de texto plano. Si en lugar de un texto plano tenemos, por ejemplo, un fichero Excel solo necesitamos parsear los bytes que nos llegan en el body con un objeto que entienda el formato Excel. Nosotros utilizamos la gema Spreadsheet (Cuidado con pronunciarlo spred-shit que queda muy feo :P )

¡Esto es todo, amigos! Un saludo

Specify exactly what you want to happen and no more

2011-02-09T10:29:00.000+01:00

There is a discussion in the spanish TDD group about whether it is good or bad, when you have a stub object, to return a different value depending on the input arguments of the method. I don't think it's the right thing to do because, normally, when a stub object cares about the input arguments in its method calls it's because it should not be a stub object, it should be a mock object. Let me explain it with an example:

The payment gateway is a stub that returns true when user_has_funds is called with an input argument of 50.
If we look carefully at the test, what we are really doing is testing more than one behavior. First, we're asserting that a user can buy stuff if she has sufficient funds. Second, we are expecting that the payment gateway is called with the right amount.
So, if it is an expectation, why don't we use a mock instead of a stub? We're mixing the concepts of mock and stub and, as a consequence, we're testing more than one thing.We're breaking the single responsibility principle.

Steve Freeman and Nat Pryce, authors of the great Growing objects oriented software, guided by tests, recommend to follow a simple rule of thumb, "specify exactly what you want to happen and no more". If we listen to them (and we should!), those are the resulting tests:

The first test specifies the relationship between the order and the payment gateway (The message protocol). It uses a mock object to replace the gateway payment object and it expects a call at user_has_funds method with the order amount as an input argument. We want to know that the payment gateway is going to be called with the right amount, so we are interested in its input argument (which is right when mocking). The second one specifies the behavior of the order when the user has funds, and I don't really care about how the order interacts with the payment gateway. I just want to know that the user has sufficient funds. That's why, in this case, we use a stub.

What I like about the new tests is that, if we change the order behavior by adding some taxes to the product price, the second test is not going to break (we still confirm the order if the payment gateway says that the user has funds, nothing has changed in that specification). Only the first one would be red (and for the right cause, we've changed exactly that specification).

What do you think?

PS: I know that, in RSpec:mocks, stub() is an alias for mock() and I don't like it very much :P

Resistencia

2011-02-07T09:30:00.001+01:00

Hace más o menos un mes, mi novia me regaló "Linchpin", un libro de Seth Godin. Si no lo habéis leido, leedlo.
Aunque prácticamente debería copiar el libro palabra por palabra, hoy solo voy a hablar de una de las partes que más me han llamado la atención, la resistencia

La resistencia
¿Alguna vez os habéis puesto una excusa para no hacer algo? Yo os pongo algunas de las mías:
"Me gusta esa chica pero no voy a decirle nada no vaya a ser que pase de mi"
"No voy a proponer nada para el open porque eso de hablar en público no me gusta nada"
"Podría solicitar ese puesto pero ¿que va a pasar con mi vida si me cogen? Mejor lo dejo pasar"

Lo que tienen en común todas esas frases es que yo soy el que pone los impedimentos, nadie más. Yo soy el que me impide alcanzar nuevas metas, yo soy el que no me deja evolucionar, yo soy el único responsable de mi propio futuro. Cualquier otra causa que sea capaz de pensar es una excusa creada por la resistencia.

Pasar a la acción
Últimamente estoy intentando vencer siempre que puedo a esa resistencia. Cada vez que me doy cuenta de que estoy pensando alguna excusa para no hacer una tarea, dejo de pensar y me pongo a hacerla. Así es como he decidido que mi primera charla en Eden trate sobre javascript (un lenguaje que desconozco), o que la tecnología que quiero enseñar al resto de edenitas (españolizando el término) sea node.js.

¿Qué puede ser lo peor que puede pasar? Por mucho que mi cerebro de reptil me diga lo contrario, lo peor que puede pasar es que aprenda algo nuevo.

Un saludo

Apprentice at Eden Development

2011-02-03T19:04:00.000+01:00

Here I am! I'm an apprentice at Eden Development :D I'm very happy to be here and I want to share this experience with you.

Apprenticeship and Eden
Even though Eden is all into the Software craftsmanship, Despo and I are their first full-time apprentices, so we'll improve the process as we walk the road :D We're going to do two month iterations with all Eden and one week iterations with Aimee (our mentor).

Apprentice expectations
Last monday, Chris and Aimee told us about the kind of things they're expecting from us.

Real world experience of client work
Ability to grasp complex logic
Confidence to change code (sometimes unattended)
Humility
Admitting to mistakes
A good grasp of TDD

Apprentice tasks
Apart from the expectations, they also told us some "mandatory" things, so I have a lot of homework :P

I must write one blog post every week. I don't really think that's going to be a problem given my previous internship ;) I'll try to write twice a week (once in English and once in Spanish)

I must give an Eden talk every month. Since all Eden talks are already booked until March, I'll do the first one on March 1st. The talk is titled "Javascript, I didn't know that!" and I'm going to do a javascript koans session.

I must do an apprenticeship ongoing project. I want to continue growing Let's walk the path together! I want it to be a useful resource for the spanish developer community so, if you want me to add some features just tell me about it. I also have to do a presentation about the project every two months (code review and retrospective included).

There is one more thing I have to do during my apprenticeship. I have to teach some technology to the edenites! I don't know yet what I'm going to do with that...

As you can see, I have a big challenge ahead!

There is no way back

2010-12-23T23:07:00.000+01:00

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

Principios detrás de "Continuous Delivery"

2010-12-22T21:59:00.000+01:00

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

Tipografía

2010-12-21T22:54:00.000+01:00

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

Continuous Delivery

2010-12-20T19:00:00.000+01:00

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

2010-12-20T01:30:00.000+01:00

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.

Practicar, practicar, practicar

2010-12-17T22:18:00.002+01:00

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

¿Por qué?

2010-12-16T23:51:00.000+01:00

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.

Diseño Simple

2010-12-15T20:10:00.000+01:00

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

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

Pasan todos los tests.
Expresa cada idea que necesitamos expresar.
Dice lo que dice una única vez.
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

Código expresivo

2010-12-14T20:32:00.002+01:00

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!

Limpiando la casa

2010-12-13T20:49:00.000+01:00

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.

Dos semanas en Eden

2010-12-12T22:03:00.000+01:00

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.

Plagentrevista

2010-12-10T22:07:00.001+01:00

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

Productividad

2010-12-09T22:41:00.000+01:00

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 :)

User Experience

2010-12-08T20:21:00.000+01:00

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

Hammock Driven Development

2010-12-07T19:35:00.000+01:00

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? Menudo lunes

2010-12-06T22:58:00.000+01:00

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 :)

Los valores de Eden

2010-12-05T02:25:00.000+01:00

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

Mi primera presentación en Eden

2010-12-03T19:49:00.000+01:00

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!

Nevando a tope

2010-12-02T21:26:00.002+01:00

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!

Esas pequeñas cosas

2010-12-01T21:05:00.000+01:00

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

Una retrospectiva en Eden

2010-11-30T20:25:00.002+01:00

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.

Eden por dentro

2010-11-29T22:53:00.000+01:00

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.

Un plagelao en Winchester

2010-11-28T19:32:00.000+01:00

¡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!

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

2010-11-24T08:00:00.004+01:00

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.

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

2010-11-18T09:00:00.006+01:00

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?

Pair Programming Cara a Cara

2010-10-25T09:45:00.001+02:00

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 :)

Libros: Implementation Patterns

2010-08-17T09:30:00.001+02:00

En una de mis anteriores entradas explicaba la necesidad de aprender de los que más saben, de apoyarse en los grandes. Como dicen que hay que predicar con el ejemplo, os voy a comentar lo que he aprendido de mis gigantes. Voy a empezar con Kent Beck.

Hace una semana que compré sus screencasts sobre tdd y hace algo más de un mes que leí su "Implementation Patterns" (Previa recomendación de Xavi Gost en las cañas de la primera code retreat española). De los screencasts ya os hablaré otro día, hoy le toca al libro.

No voy a haceros un resumen, simplemente os diré que es un libro espectacular. Debería ser de lectura obligatoria en la carrera de informática junto con el "Clean Code" de Robert Martin :) Os recomiendo leerlo (176 páginas que se leen en un plis plas) pero, como es muy probable que mi recomendación no os baste, voy a tiraros la caña para que piquéis escribiendo las frases que más me han impactado. Vamos a ello.

[Decidí]Dejar de fingir que programo por instinto

Mis primeros pasos en esto de la programación fueron así. Hacía lo que yo pensaba (intuía) que estaba bien, pero en realidad no tenía ni idea. No tenía visión global, no pensaba en el usuario, iba a impulsos, no hacía pruebas automáticas, etc. Era un patán, una inconsistencia con patas. Y sin embargo, ¡Me parecía que hacía las cosas bien! Que barbaridad... No tenía ningún tipo de criterio.
Cuando empece a tomar conciencia de mi profesión (y en esto le debo mucho a Alfredo Casado) descubrí lo malo que era. Avergonzado, decidí empezar a aprender mi oficio y, no es que ahora sea la hostia, pero estoy a años luz de aquel paquete :D Espero que dentro de unos años vuelva a pensar lo mismo del paquete que os escribe ahora mismo, querrá decir que no me he estancado.

Los programas se leen más a menudo de lo que se escriben.

Espero que esto lo tengamos todos más que asumido. Hay que hacer código legible porque vamos a pasar más tiempo leyéndolo que escribiendo código nuevo. Sin embargo, cuando empiezas en esta profesión no eres consciente. En mi caso, no pensaba en el mantenimiento de mi programa porque, obviamente, una vez que lo hiciera funcionar nadie iba a volver a tocarlo :D Ahora, cada vez que me toca "enseñar" a alguien intento explicarle ésta necesidad y casi siempre me encuentro con lo mismo: "caras de pescao y culos torcios" ¿Nadie explica esto en las empresas o en las universidades?

Encontrar el nombre correcto es uno de los momentos más satisfactorios cuando se programa

Cuando empiezas a pensar en leer código más que en escribirlo se te plantea el problema de cómo nombrar una clase, un método, una variable... ¿Qué nombre representa mejor a esta clase? ¿Es lo suficientemente comunicativo? Para mi, es una de las partes más complicadas de la programación por eso, cuando consigues dar en el clavo, es de las más gratificantes.

Los programadores deben pensar, comunicar y aprender. Es parte de ser un profesional

Ser un profesional. Si queremos que nos tomen en serio como sector debemos empezar a tomarnos en serio nosotros mismos. Debemos empezar a ser profesionales. Para Kent Beck, los tres pilares de un programador profesional son

Pensar: Programar es muy difícil. Si haces las cosas a la ligera lo acabaras pagando.
Comunicar: Como ya he dicho antes, debemos empezar a hacer código expresivo, sencillo de leer y entender.
Aprender: No anclarnos, no quedarnos obsoletos. Intentar mantenernos al día.

El mejor código para optimizar es el legible, modular y probado

Me gusta esta frase porque pone por delante de la optimización las pruebas y la legibilidad. Haz que funcione, ya harás que funcione rápido.
Espera a tener pruebas que demuestren que necesitas optimizar y optimiza entonces.

Haz que tu código funcione, decide después como debe estructurarse. Si gastas mucho tiempo estructurando tu código antes de escribirlo, tendrás que deshacer todo ese trabajo y rehacerlo de nuevo cuando aprendas algo durante la implementación

Código que funcione, código que funcione, código que funcione, código que funcione, código que funcione, código que funcione, código que funcione... ¡Hazlo! Deja el análisis y pasa a la acción. Pero recuerda, PIENSA.

[sobre los setters]Intenta entender que problema está resolviendo el cliente al asignar la variable.

Orienta tu código al dominio del cliente, no al contrario. En esta cita en concreto, Beck se refiere a los típicos métodos "set" que únicamente sirven para asignarle el valor a una variable. ¿Por qué necesita tu cliente hacer ese "set"? ¿Qué problema necesita resolver? Cuando empecé a programar nunca me hacía estas preguntas. Pasaba de mi cliente (Entendido como el programador que utilizaba mi código). El solo hecho de pensar en ellas te asegura un código mucho mejor.

Antes de añadir complejidad a un programa, asegurate de que dicha complejidad traerá beneficios

Manten tu código lo más simple posible. Muchas veces los programadores somos los que añadimos la complejidad a nuestro código sin venir a cuento. Si cuando estás programando te da la impresión de estar creando un código demasiado complejo párate a pensar en por qué está pasando eso. Puede que hayas perdido el foco y estés añadiendo funcionalidad innecesaria.
Algo que me ha ayudado mucho a mantenerme enfocado en el problema a resolver es TDD. ¡A tope con el TDD!

Con esto paro, que me veo comentando el libro entero y eso prefiero hacerlo delante de unas cañas. Yo pago la primera :P

Principios ágiles #6

2010-05-10T09:40:00.000+02:00

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.

Principios Ágiles #5

2010-02-02T11:26:00.000+01:00

Siguiendo con la temática de los principios ágiles, hoy voy a hablar del quinto de ellos:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Construye proyectos con profesionales motivados. Dales el entorno y soporte que necesitan, y confia en ellos para que realicen el trabajo.

Profesionales motivados
Cuando una persona encuentra un nuevo trabajo su motivación inicial es bastante alta. Si tiene experiencia previa probablemente haya conseguido un trabajo que le guste con un sueldo acorde a dicha experiencia. Estará contento y querrá demostrar que vale lo que le van a pagar. Si es un junior sin experiencia querrá aprender y prosperar en su carrera profesional. ¿Qué lleva a cualquiera de estas dos personas a desmotivarse? Pues multitud de causas. Falta de dirección (visión de empresa, visión de producto, abandono por parte de la gerencia...), mala cultura empresarial (mala relación entre compañeros, infraestructura deficiente, falta apoyo al aprendizaje), etc. Imagino que todos hemos pasado por algo así en algún momento, por desgracia.
Una vez que una persona pierde la motivación es muy complicado volver a motivarla, por lo que hay que esforzarse en evitar que ocurra.
¿Cómo se puede evitar la desmotivación?
Dan Pink lo explica muy bien en esta presentación (Si aún no la habéis visto ya estáis tardando :P)
Os escribo las conclusiones para los más vagos (aunque ya os digo que mola mogollón). Básicamente cuenta que, una vez resuelto el tema salarial (está claro que es un factor importante, pero no el único) los factores que ayudan a mantener la motivación son los siguientes:

Autonomía. Muy en sintonía con la auto-organización de los equipos ágiles ;) Hay que confiar en que el trabajador es capaz de hacer su trabajo por si mismo.
Maestría. Para los agilistas significa buscar la excelencia técnica (Sea lo que sea eso, que ya lo veremos en futuras entradas)
Propósito. Contribuir a algo importante. En el caso de la agilidad sería equivalente a contribuir en la mejora del negocio del cliente. Aportar valor y tal :)

Estos tres factores ayudan a mantener la motivación de un profesional (no solo los profesionales técnicos, cualquier tipo de profesional) ya que crea un entorno en el que las personas son importantes y valiosas (Ya sabéis, personas sobre procesos...).

Crear un entorno y dar el soporte necesario
Tal y como hemos visto arriba, la cultura empresarial es muy importante a la hora de mantener la motivación.
Es necesario que la empresa proporcione un ambiente que favorezca el aprendizaje, que ayude a crecer profesionalmente a sus trabajadores, que confíe en ellos para realizar su trabajo, que les proporcione una infraestructura adecuada a sus necesidades, etc. Es decir, que se dedique a eliminar impedimentos externos del día a día para que los únicos problemas que se encuentren sus trabajadores sean los propios de su trabajo (Eliminar burocracia inútil, métricas absurdas, controles exhaustivos, etc).

Confianza
Todo lo anterior se basa en la confianza. Está claro que un buen profesional sabe hacer su trabajo. No necesita un jefe todo el día detrás suya, interrumpiéndole cada 10 minutos para preguntarle qué tal lo lleva. Ese micro-control, además de desmotivar, reduce la productividad.
Sin embargo, hay que tener claro que no todo depende de área de gestión, el empleado debe responder. Como dijo el Tío Ben :

Un gran poder conlleva una gran responsabilidad

Si queremos que nuestro trabajo mejore, que se nos trate como a verdaderos profesionales y que se confíe en nosotros, debemos responder con autentica profesionalidad. Si nuestra empresa fomenta el aprendizaje debemos aprovecharlo y mejorar. Si nuestra empresa nos permite autonomía debemos comprometernos. No podemos desaprovechar las (¿pocas?) oportunidades que se nos ofrecen.

Conclusiones
El quinto principio ágil:

Busca fomentar la confianza
Advierte que lo importante son las personas
Pide que se eliminen los impedimentos externos
Implica responsabilidad y profesionalidad

NOTA: Si os interesa más el tema de la motivación de un equipo os recomiendo el libro Peopleware. Yo aún no lo he podido leer, pero José Manuel Beas lo recomendó en la reunión que tuvimos sobre principios ágiles al hablar sobre este principio. El libro se lo dejó a Alfredo Casado, que nos ha ido contando algunas de las cosillas que ha ido leyendo. La verdad es que tiene muy buena pinta :)

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

Sprint #2 - Aceptando el riesgo

2010-01-27T23:31:00.009+01:00

Os presento la segunda planificación del ScrumBlog. Si no leistéis la primera planificación podéis echarle un ojo ahora (Allí explico un poco los roles de Scrum y las fases de la planificación). Doy eso por sabido y me meto directamente a planificar.

Planificación de la iteración
Voy a intentar que todas las iteraciones duren lo mismo, por lo que esta también durará 15 días. Quedan las fechas del sprint como siguen:
Planificación - Miércoles 27 de Enero
Inicio de Sprint - Jueves 28 de Enero
Fin de Sprint - Jueves 11 de Febrero
Retrospectiva - Viernes 12 de Febrero

Disponibilidad del equipo
Tal y como señale en la retrospectiva, la velocidad del equipo es de 11 puntos de historia cada 15 días. Dado que la disponibilidad del equipo es la misma que en la iteración anterior, fijamos los puntos de historia en 11.

Estimación de las historias
Veamos el estado de la pila de producto:

El equipo ha estimado las historias pero, si os fijáis bien, la historia de FitNesse aparece con un símbolo de exclamación. Esto es debido a que dicha historia tiene un factor de riesgo alto debido al desconocimiento del equipo en la tecnología a utilizar. La idea es hacer un ScreenCast cuando nunca he hecho ninguno. Es muy probable que mi estimación sea mala pero, es la mejor que puedo hacer.
¿Qué hacemos con este tipo de historias? Existen varias alternativas. Las que yo considero más adecuadas son las siguientes:

Fijar un limite de tiempo a dedicar a dicha tarea (en este caso 4 horas) de forma que, si mientras estamos investigando como realizar dicha historia nos damos cuenta de que la complejidad es mucho mayor que la que estimamos, dejemos dicha historia para la siguiente iteración.
Dividir la historia en dos. Por un lado tendríamos una historia para la formación del equipo y otra historia para la ejecución.

En este caso, tras hablarlo con el dueño de producto optamos por la primera de las opciones (algo más arriesgada). Si al final se lía la cosa el cliente como el equipo tendrán claro el por qué.

Selección de las historias del sprint
Estas 4 historias suman 12 puntos y solo tenemos 11 disponibles. Volvemos a encontrarnos con que no entran todas en el sprint. Sin embargo, esta vez, después de acaloradas discusiones entre el equipo y el dueño de producto, se decide aumentar el nivel de compromiso del equipo para que entren las cuatro historias en la iteración, por lo que las proximas entradas del blog serán:

Principios ágiles #5. Importancia de la motivación de, la confianza hacia y el apoyo a las personas involucradas en el proyecto.
How To: Primeros pasos con FitNesse. Mi primer ScreenCast. Espero que no sea el último :D Además, este ScreenCast lo añadiré al resumen de la reunión de Madrid para completarlo un poco más.
Principios ágiles #6. Comunicación cara a cara como método más eficiente y efectivo para que fluya la información.
How To: Mockeando llamadas asíncronas con easymock. ¿Os habéis planteado como hacer TDD con llamadas asíncronas? Intentaremos explicarlo en esta entrada.

Burndown
Por último, falta el burndown de la iteración. Iré actualizándolo regularmente con los avances :D

Reunión Diaria (Scrum diario) del 28 de Enero: Al ser la primera, lo único que se hace es que cada miembro del equipo elija la tarea en la que quiere trabajar. Voy a intentar escribir la entrada sobre el quinto principio ágil. Al menos el primer borrador
Reunión Diaria (Scrum Diario) del 29 de Enero

¿Qué hiciste ayer? Comence con el quinto principio, pero avancé menos de lo que esperaba. Me quedan un par de horitas todavía
¿Qué vas a hacer hoy? Hoy espero terminar la entrada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 30 de Enero

¿Qué hiciste ayer? Nada :( Las cañas de los viernes pudieron al blog
¿Qué vas a hacer hoy? Hoy espero terminar la entrada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 31 de Enero

¿Qué hiciste ayer? Pues hice un poquito más de la entrada de los principios. pero aún le falta una horita
¿Qué vas a hacer hoy? Nada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 1 de Febrero

¿Qué hiciste ayer? Pues jugar al COD. Menudo vicio.
¿Qué vas a hacer hoy? Hoy acabo la entrada sí o sí
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 2 de Febrero

¿Qué hiciste ayer? ¡Terminé la entrada!
¿Qué vas a hacer hoy? Pues investigar un poco como va lo de los screencasts
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 3 de Febrero

¿Qué hiciste ayer? Pues al final no me dio tiempo a hacer nada.
¿Qué vas a hacer hoy? Creo que tampoco me va a dar tiempo a hacer nada, pero igual preparo el guión del screencast
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 4 de Febrero

¿Qué hiciste ayer? Terminé el guión del screencast.
¿Qué vas a hacer hoy? Hoy me voy de concierto, así que nada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 5 de Febrero

¿Qué hiciste ayer? Nada
¿Qué vas a hacer hoy? Hoy voy a ver a los Arctic Monkeys, así que nada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 8 de Febrero

¿Qué hiciste ayer (y antes de ayer y antes de antes de ayer)? Pues no pude ponerme con el screencast porque vinieron invitados a casa pero al menos saqué tiempo para avanzar con el sexto principio ágil. Le queda una horia más a esa entrada.
¿Qué vas a hacer hoy? Quiero intentar el screencast, a ver si tengo tiempo.
¿Algún impedimento? No

Foto de "portada": Galería de boo_licious en Flickr, bajo licencia Creative Commons.

Retrospectiva #2

2010-01-25T20:25:00.003+01:00

Bueno, pues parece que hemos terminado la primera iteración del ScrumBlog :D Vamos a "retrospectivar" un rato sobre dicha iteración.

¿Por donde empezamos?
Vamos a empezar calculando la velocidad del equipo y su eficacia. Para ello vamos a basarnos en el burndown de la iteración. Podemos ver que la velocidad del equipo se corresponde a 11 puntos de historia y su eficacia es de un 100%. Estos datos nos servirán como base para la próxima planificación.

Parece que ha sido una buena iteración ¿no? Veamos que opina el equipo (Como ya hicimos en la retrospectiva anterior, vamos a hacer a basarnos en 3 preguntas para llevar la retro).

¿Qué nos ha gustado de este sprint y queremos seguir haciendo?

El compromiso. Ha sido "duro", pero ha merecido la pena.
Por fin hemos metido una historia técnica. No se si os habrá gustado, a mi sí :D. Me parece una idéa muy interesante, la verdad. Además, el tener una historia técnica me ha servido para iniciarme en git.

¿Qué estamos haciendo mal?

La priorización de las historias. No puede ser que la segunda historia más prioritaria no pueda empezarse hasta un par de días antes del final de la iteración
Aunque hemos aumentado la tasa de entradas, sigue siendo un poco baja.
Los Scrum diarios no han sido tan diarios :D Ha sido un poco despendole...
La plantilla del blog no permite leer bien el código :(

Acciones

Las historias bloqueantes hay que priorizarlas teniendo en cuenta dicho bloqueo.
Fijar una hora para realizar el Scrum diario. Si es posible, por la mañana
Modificar la plantilla del blog para que el código se pueda leer decentemente.

¡Que poquitos problemas! :D Se nota que esta primera iteración ha salido bien. Veremos las siguientes...
Si queréis proponerme algún tema para la próxima iteración dejad un comentario en la entrada antes de la planificación de mañana :D De momento, en lo más alto de la pila están el quinto principio ágil y una introducción a FitNesse.

11º Encuentro Agile-Madrid. Definition of Done (Pruebas de aceptación automatizadas)

2010-01-21T17:06:00.000+01:00

Entre todos los asistentes a la reunión hemos creado un resumen en el sitio google del grupo. Leedlo antes de continuar :D

Dado que el resumen ya está hecho, voy a escribir un poco qué supuso para mi la reunión.

Preparativos
En un principio, mi labor para esta reunión era preparar un ejemplo de automatización de pruebas de aceptación en FitNesse y presentarlo (Tengo que decir que, aunque conocía FitNesse, nunca lo había usado y, esta reunión me ha servido para aprender un poco de que va ese rollo :D Me ha gustado bastante y puede que para la próxima iteración del blog escriba un "How To" sobre FitNesse).
Unos días antes de la reunión, José Manuel Beas me dijo que no iba a poder ir y me pidió que me encargarse yo de la charla. Me cedió tanto la presentación como el ejemplo de Concordion que iba a presentar.
No estoy acostumbrado a hablar en público y soy bastante tímido, así que me puse un poco nervioso. Aún así, el tema era muy chulo y me apetecía hablar de él, por lo que acepté :)

El encuentro
Acudimos unas 20 personas, entre las que había bastantes caras nuevas (lo que aumentó el miedo escénico :D). No se lo que piensan los demás, pero para mi la reunión fue bastante entretenida (Me sentí bastante cómodo mientras casi improvisaba la presentación) y la gente debatió bastante. Como ya he dicho, el resumen podéis leerlo en el sitio del grupo, pero os apunto las conclusiones a las que llegamos por si sois un poco vagos :P

Las pruebas de aceptación deben comprobar las reglas de negocio (Qué y no cómo).
Las pruebas de aceptación deben producirse mediante la colaboración de cliente y equipo (Negocio y desarrollo juntos).
Es deseable que las pruebas de aceptación se escriban antes que el desarrollo, ya que ayuda a focalizar dicho desarrollo.
Utilizar un framework que ayude a automatizar las pruebas de aceptación es deseable.
Entre Concordion y FitNesse no sabemos con cual quedarnos. Ambos tienen aspectos positivos y negativos. Probadlos y decidid :D

Futuro
El haber dado esta charla me ha enseñado que no es tan duro hablar delante de la gente. Te puede salir mejor o peor, pero lo importante es compartir. La verdad es que me he animado bastante y creo que voy a proponer alguna charla más e, incluso, algún taller (A ver si hablo con Alfredo Casado y organizamos algo de TDD, que ya me lo ha dicho un par de veces. José Manuel Beas quiere montar uno sobre Concordion y creo que estaría muy bien).
Además, después de haber entrado un poco más a fondo en las pruebas de aceptación, queremos empezar a utilizar algún framework para automatizar las pruebas de aceptación en mi trabajo. Yo me decanto por FitNesse, que me parece más sencillo de cara a un usuario no técnico, pero algún que otro compañero prefiere Concordion. ¿Que haremos? De momento creo que vamos a probar FitNesse porque me voy a encargar yo de hacer esas pruebas :D Ya os contaré nuestros avances y nuestros problemas.

Animaos y venir a las reuniones, a los coding-dojos, a los talleres, etc. Son gratis y de verdad que merecen la pena.

How To: Contract Tests (Pruebas de Contrato)

2010-01-17T01:50:00.096+01:00

El diseño de un API es un problema bastante complejo. Hay que tener multitud de cosas en mente (modularidad, escalabilidad, extensibilidad, usabilidad, simpleza, etc). Si os interesa el tema os recomiendo este libro de Jaroslav Tulach (uno de los arquitectos de NetBeans). Es un libro difícil, como el problema que aborda, pero muy bueno.
En dicho libro conocí el concepto de Contract Tests(Pruebas de Contrato). Sin embargo, aunque me pareció una buena idea, no le dí mucha importancia en aquel momento (hace un año, aproximadamente). Antes de fin de año, J.B. Rainsberger twitteaba el vídeo de Ben Rady escribiendo Contract Tests en Junit 4 y todo el tema volvió a mi cabeza.

¿Qué son las Pruebas de Contrato?
J.B. Rainsberger lo explica en este artículo (Que escribió en el 2005, menudo crack). Básicamente, las Pruebas de Contrato son una batería de pruebas que especifican el comportamiento de un determinado interfaz (o clase abstracta). Cualquier implementación de dicho interfaz (o cualquier clase derivada de la clase abstracta) debe superar dicha batería de pruebas para ser considerada correcta.

¿Qué problema resuelven las Pruebas de Contrato?
Normalmente, cuando se crea un interfaz (o una clase abstracta) es para que tenga varias implementaciones (o clases derivadas). Sucede lo mismo con un API, puede tener más de una implementación pero un único interfaz.
Si no se define un comportamiento general, es posible que las implementaciones no sean intercambiables entre sí, violando así el principio de sustitucion de Liskov y, lo que es más importante, dejando a los clientes de dicho interfaz con el culo al aire. Dicho comportamiento es lo que se define como contrato. Podemos escribir dicho contrato como un documento más, con los problemas que ello conlleva (Código y documentación desincronizada, interpretaciones subjetivas de lo escrito, etc) o podemos escribir dicho contrato mediante pruebas.

¿Por qué me interesan las Pruebas de Contrato?
Imagino que estaréis pensando:

Vaya chapa nos está metiendo el Peña.

Así que voy a contaros un poco mi motivación. Mi pensamiento tras ver el vídeo de Ben Rady fue:

¡Coño! Que bueno. Si lo hubiera aplicado antes a mi proyecto ahora sería mucho más feliz.

El proyecto actual de mi equipo consiste en diseñar (e implementar, testear, etc. Nada de waterfallismo :D )un API y crear varias implementaciones de dicho API (y diseñarlas, testearlas, etc. :D ).
Cuando comenzó el proyecto no le dimos importancia a esto de las Pruebas de Contrato (Sobre todo por desconocimiento). Tampoco pasaba nada, solo existía una implementación para la cual teníamos una batería de pruebas.
Más adelante añadimos una segunda implementación y, en lugar de convertir los test de la anterior implementación en Pruebas de Contrato, hicimos un corta-pega del demonio (Me da vergüenza escribir esto, pero de los errores se aprende).
No os recomiendo este enfoque :D Las pruebas huelen a DRY que tiran de espaldas.
Además, aceptamos pequeños cambios en el comportamiento de las implementaciones ya que, al definir el contrato en un wiki en lugar de hacerlo con pruebas, malinterpretamos ciertos detalles (algunas veces a propósito :S ).
Le he planteado al equipo que, las nuevas pruebas funcionales que creemos sean Pruebas de Contrato, a ver si conseguimos eliminar duplicaciones.
NOTA: Tengo que aclarar que estoy muy contento con la marcha del proyecto :D Lo que pasa es que mi nivel de exigencia aumenta cada mes. De hecho, nuestro equipo es famoso por lo mal que habla de su propio código, estando dicho código bastante por encima de la media. Somos un equipo muy autoexigente y muy autocrítico.

Un caso práctico: El interfaz Collection con JUnit 4
Después de todo este rollo, vamos a la chicha.

Vamos a hacer unas Pruebas de Contrato para el interfaz Collection (No vamos a hacer el contrato entero porque nos puede dar un chungo).
Normalmente, las Pruebas de Contrato se añaden al proyecto que contiene los intefaces a definir. Las clases que ejecutan las pruebas para cada implementación se añaden al proyecto que contiene dicha implementacion. Como yo no tengo acceso a dichos proyectos, me he creado uno propio. He metido todas las clases en ese proyecto, pero he hecho una separación en paquetes para que entendáis un poco la distribución de las clases. Podéis verlo aquí (Es de NetBeans. A mi me gusta mucho, pero Xavi Gost me diría que madurara... Aún así, es tan sencillito que no creo que de problemas :D ).

Lo primero es crear una clase abstractra que contenga todos los test de contrato y un método abstracto que devuelva un objeto Collection. Yo he hecho la siguiente:

Como podéis ver, el método nuevaColeccion se llama en el setUp para no tener que escribirlo en cada prueba. Además, dicho setUp es final para que no pueda ser sobreescrito por las clases hijas.

Si ahora lanzamos las pruebas obtenemos el siguiente resultado:

Si os fijáis, la clase abstracta que hemos creado no termina en Test, así que JUnit 4 no la tiene en cuenta a la hora de ejecutar las pruebas.

Ahora vamos a probar las implementaciones. Empezamos por ArrayList, para lo que añadimos la siguiente clase:

Lo mismo para HashSet:

Si ahora pasamos las pruebas obtenemos:

¡Bien! Pasan todas las pruebas :D Eso quiere decir que ambas implementaciones cumplen con el contrato y todos somos un poco más felices.
Hay que destacar que las pruebas se están contabilizando en cada clase de prueba de cada implementación (Todas las Pruebas de Contrato se ejecutan en ArrayListTest y en HashSetTest). A la hora de contabilizar pruebas la clase base no existe :D

Vamos a ponérselo un poco más difícil a las implementaciones. Añadimos la siguiente prueba a la clase que define el contrato:

Si ahora pasamos las pruebas de las implementaciones obtenemos:

¿Rojo? mmmmm Huele a violación de los principios S.O.L.I.D.
La implementación HashSet no supera la nueva prueba que hemos añadido. Hemos definido un contrato demasiado estricto y algunas implementaciones no lo soportan.
En este caso, no podemos suponer lo que hará una colección cuando se le añada el mismo objeto varias veces. Depende de la clase derivada. Claramente, las implementaciones de Collection violan el principio de Liskov :D

Podríamos seguir añadiendo pruebas y tal, pero imagino que ya ha quedado más o menos claro ¿No? Ya veis que no sería muy complicado organizar las pruebas que ya tenemos para obtener unas cuantas Pruebas por Contrato. Espero poder hacerlo en mi equipo :D (Me temo que esto es deuda técnica).

Conclusiones

Las Pruebas de Contrato son una especificación del API.
Las Pruebas de Contrato se pueden usar como documentación del interfaz. La documentación escrita en prosa "a la antigua usanza" es mucho más fácil de malinterpretar.
El contrato puede ser todo lo estricto que queramos. Hay que aplicar el sentido común para saber cuando parar.
Mediante Pruebas de Contrato eliminamos duplicidad de código de test. Las pruebas hay que seguir escribiéndolas tengamos o no Pruebas de Contrato y, escribir las mismas (o parecidas) en cada una de las implementaciones es una perdida de tiempo y un infierno a la hora de mantenerlas (lo digo por experiencia).
Definir unas Pruebas por Contrato puede ayudarnos a descubrir problemas de diseño en el API. Una violación del principio de Liskov es un problema en el API

Esto es todo amigos. Espero que os haya gustado mi primera entrada técnica :D

Foto de "portada": Galería de Mark, bajo licencia Creative Commons

Principios Ágiles #4

2010-01-13T21:50:00.014+01:00

Siguiendo con la temática de los principios ágiles, hoy voy a hablar del cuarto de ellos:

Business people and developers must work together daily throughout the project.

La gente de negocio y los desarrolladores deben trabajar de forma conjunta diariamente a lo largo del proyecto.

¿Gente de Negocio y gente de desarrollo?
Cuando se comienza un nuevo proyecto es lógico que el equipo de desarrollo (encargado de implementar una solución) no sea experto en el negocio del cliente. Por otro lado, un experto de negocio (encargado de explicar las reglas de negocio) casi nunca se interesará por el aspecto técnico (desde luego, ninguno que yo conozca). Ambos mundos están bastante separados, al menos sobre el papel, lo que provoca que sean incapaces de entenderse. No poseen un lenguaje común.

¿Por qué trabajar juntos de forma conjunta?
Obligar a que ambos mundos trabajen juntos de forma continua provoca que la separación entre ambos se reduzca. Obviamente, el objetivo no es que un desarrollador se convierta en un experto de negocio ni viceversa. Siempre existirá una cierta separación. El objetivo es construir un lenguaje común mediante el cual ambos grupos consigan entenderse y resolver sus dudas. Actualmente en el mundo ágil, dicho lenguaje común se plasma sobre todo en las pruebas de aceptación, definidas por la gente de negocio con ayuda del equipo técnico (Si queréis saber más sobre pruebas de aceptación pasaos por la próxima reunión de Agile-Spain Madrid).
Cuando ambos grupos empiezan a colaborar se empieza a reducir la brecha que los separa. Comienza a aparecer un sentimiento de equipo y una visión global del producto.

¿Por qué diariamente?
No vale con reuniones esporádicas, debe ser un esfuerzo continuo. No vale que los grupos se reunan una vez al mes para tratar ciertos temas y que después cada uno se marche a su cubículo. Si un desarrollador se encuentra con que tiene que tomar una decisión de negocio debe acudir a los expertos de negocio para que se la resuelvan. Si un experto de negocio quiere conocer que tal va el desarrollo de una funcionalidad X debe acudir al desarrollador para que le informe. Obviamente, esta colaboración no se puede llevar a cabo sin confianza y transparencia. No me sirve de nada que los desarrolladores estén siempre disponibles para el experto de negocio pero le mientan sobre el estado del proyecto.
Este trabajo diario no es sencillo de llevar a cabo. Muchas veces los desarrolladores no queremos levantar la cabeza del ordenador. Otras muchas los expertos de negocio no tienen tiempo (ni ganas) de reunirse con los "frikis". Por eso, es necesario un compromiso por ambas partes. Si alguno de los dos no se compromete se deja de ser ágil.

Conclusiones
El cuarto principo ágil:

Busca que la gente de negocio y la gente técnica hablen un lenguaje común que favorezca el entendimiento.
Refuerza el sentimiento de equipo aumentando la confianza entre sus componentes.
Implica compromiso.
Obliga a la transparencia.

Imagen de "portada": Galería de thinkpublic, bajo licencia Creative Commons.

Sprint #1 - Planificando enero

2010-01-06T21:32:00.021+01:00

Como ya escribí en la retrospectiva, voy a intentar aplicar una especie de Scrum al blog. Tanto José Manuel Beas como Juan Quijano apuntaron en los comentarios de la anterior entrada los problemas que veían al aplicar Scrum para un blog. Es cierto que Scrum está orientado a productos desarrollados por equipos de varias personas y que no cuadra muy bien con un blog personal. Aún así, se que me va a servir para mejorar el ritmo de entradas, que es lo que busco. Además, los post de planificación y retrospectivas pueden ayudar a entender la parte de gestión de Scrum (que no es que sea muy difícil) A ver que tal sale, probablemente sea un "fail", pero voy a probar.

Roles de Scrum
En Scrum hay basicamente tres roles:

Dueño de Producto - Gestiona la pila de producto
Scrum master - Elimina los obstáculos que impiden que el equipo cumpla sus compromisos.
Equipo - Desarrolla el producto.

Normalmente cada persona involucrada en el proyecto tiene asignado un único rol y existen varias restricciones.

Solo hay un dueño de producto (Se puede argumentar que puede ser un comité de expertos de negocio los que implementen dicho rol pero vamos, lo más adecuado es que sea una única persona de ese comité el dueño de producto. Personalizar ese rol en una persona ayuda al equipo, que tiene más claro a quien dirigirse).
Solo hay un Scrum Master.
El equipo está formado por una o más personas (En realidad, el equipo siempre es de más de una persona. He puesto una porque en este caso el equipo soy yo solo).

Yo haré de Dueño de producto, de Scrum master y de equipo :) Me voy a volver loco...

La Pila de Producto
Tenemos nuestro dueño de producto y nuestro equipo. Ahora necesitamos una pila de producto. Para no aburriros con muchos datos, solo voy a contaros los temas que he metido en la pila (si continúo con el blog-scrum la presentaré en futuros posts) mientras llevaba puesto mi gorro de dueño de producto.
Voy a seguir con la serie de principios ágiles y con el resumen del libro "Agile Testing". También he añadido unos cuantos temas técnicos (Orientados sobre todo a testing, aunque hay algo de TDD). Además, he incluido una historia para el resumen de la reunión del día 19 de Agile-Spain Madrid.

Planificación de la iteración
Creada la pila ¡podemos empezar a planificar la primera iteración!
Sigo con el gorro de dueño de producto. Lo primero que tengo que decidir es la duración de este sprint. Como quiero incluir la historia con el resumen de la reunión he pensado en una iteración de dos semanas. Quedan las fechas del sprint como siguen:

Planificación - Miércoles 6 de Enero
Inicio de Sprint - Jueves 7 de Enero
Fin de Sprint - Jueves 21 de Enero
Retrospectiva - Viernes 22 de Enero (Creo que esta se puede alargar al fin de semana del 22...)

Ahora toca ver que entra en la iteración. Para ello primero debo conocer la disponibilidad del equipo y las estimaciones de las historias. Me pongo mi gorro de Scrum master y os cuento que, para simplificar un poco, voy a igualar los puntos de historia a horas ideales (Se que no está muy bien, pero voy a empezar así).

Disponibilidad del equipo
Me pongo ahora el gorro de equipo. Como es el primer sprint aún no conozco mi velocidad así que voy a ponerme una a ojo. Una persona durante quince días dedicándole unas seis horas a la semana me dice que, más o menos, mi velocidad es de 12 puntos de historia.
Estimación de las historias
Todavía con mi gorro de equipo estimo las primeras historias de la pila:

Selección de las historias del sprint
Una vez estimadas las historias vuelvo a ponerme el gorro de dueño de producto para decidir que historias de las estimadas entran en el sprint.
Estas 4 historias suman 15 puntos y solo tengo 12 disponibles ¿Qué hago? Tengo varias opciones:

Puedo intentar convencer al equipo para que aumente su nivel de compromiso y acepte hacer los 15 puntos. He estado discutiendo conmigo mismo (cambiando de gorro mientras lo hacía, menudo cuadro) y he decidido que el equipo no puede aumentar su compromiso (Hay que hacer más cosas en la vida...)
Puedo reordenar las historias de forma que las tres historias con estimación 4 entren en la iteración. El problema de esta opción es que uno de los requisitos era tener al menos una historia técnica por sprint.
Puedo regalarle un punto al equipo y que hagan las 3 historias más prioritarias. Me quedo con esta opción.

Decidido entonces. Las proximas entradas del blog serán:

Principios ágiles #4. Continuamos con la serie sobre principios ágiles. Esta vez toca "Negocio y tecnología deben trabajar juntos" (traducción libre :) ).
Resumen reunión 19 Enero Agile-Spain. Podéis ver toda la información sobre la reunión en esta página. Animaos y venid.
Contract tests. Una idea muy buena que ya leí en "Practical API design: Confessions of a Java framework architect" y que he recordado gracias a este post de J.B. Rainsberger :) Qué son y como se hacen con JUnit.

Burndown
Por último, falta el burndown de la iteración. Iré actualizándolo regularmente con los avances :D

Reunión Diaria (Scrum diario) del 7 de Enero: Al ser la primera, lo único que se hace es que cada miembro del equipo elija la tarea en la que quiere trabajar. Yo elijo la tarea "No hacer nada porque no tengo tiempo".
Reunión Diaria (Scrum diario) del 8 de Enero

¿Qué hiciste ayer? Nada. Como no hice nada no reestimo la duración de las tareas quedando un burndown plano. Como siga así veras que risa.
¿Qué vas a hacer hoy? Hoy voy a intentar empezar el post sobre el cuarto principio ágil.
¿Algún impedimento? Nop.

Reunión Diaria (Scrum diario) del 9 de Enero

¿Qué hiciste ayer? Empecé la historia de los principios ágiles. Reestimo que me quedan unas 3 horitas. Esta reestimación hace que el burndown de reestimación baje un poquito, hacercandose al ideal. Sin embargo el de terminado sigue plano ya que aún no he acabado ninguna historia.
¿Qué vas a hacer hoy? Voy a continuar con dicho artículo, aunque no se si voy a poder hacer mucho.
¿Algún impedimento? Ninguno, de momento.

Reunión Diaria (Scrum diario) del 10 de Enero

¿Qué hiciste ayer? Pues al final no hice nada. Me pudieron las ganas de darle caña al modern warfare 2. ¡Que vicio!
¿Qué vas a hacer hoy? Hoy voy a avanzar sí o sí con la historia de los principios ágiles.
¿Algún impedimento? No.

Reunión Diaria (Scrum Diario) del 11 de Enero

¿Qué hiciste ayer?
He creado el esqueleto del post. Yo creo que con un par de horitas más lo acabo
¿Qué vas a hacer hoy? Nada, me parece que hoy toca ver una peli.
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 12 de Enero

¿Qué hiciste ayer?
Nada :(
¿Qué vas a hacer hoy? Hoy espero terminar una primera versión de la entrada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 13 de Enero

¿Qué hiciste ayer? He seguido avanzando en la entrada de los principios y casi la tengo lista :)
¿Qué vas a hacer hoy? Hoy espero terminar la entrada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 14 de Enero

¿Qué hiciste ayer? Terminé la historia de los principios ágiles :D y empecé con la de la reunión, pero no la puedo hacer porque ¡todavía no hemos hecho la reunión!
¿Qué vas a hacer hoy? Hoy puede que empiece con la de "Contract tests"
¿Algún impedimento? No puedo hacer la historia más prioritaria...

Reunión Diaria (Scrum Diario) del 15 de Enero

¿Qué hiciste ayer? He creado el borrador de Contract Test, pero no he podido escribir nada :D Por lo menos me he registrado en github, donde dejaré el código de los ejemplos
¿Qué vas a hacer hoy? Hoy voy a crear los ejemplos para "Contract tests" y, si me da tiempo, escribiré algo
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 16 de Enero

¿Qué hiciste ayer? Además de ver perder al Madrid he estado trabajando en la entrada de Contract Test. Con un poco más de esfuerzo la tengo lista para el lunes :D
¿Qué vas a hacer hoy? Seguir con la entrada. Tengo que hacer los ejemplos y poner el código en el post
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 17 de Enero

¿Qué hiciste ayer? ¡Acabé la historia de las Pruebas de Contrato!
¿Qué vas a hacer hoy? Hasta despues de la reunión no creo que haga nada :D
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 18 de Enero

¿Qué hiciste ayer? Nada. Bueno, preparar la reunión de Agile-Madrid
¿Qué vas a hacer hoy? Nada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 19 de Enero

¿Qué hiciste ayer? Nada. Bueno, preparar la reunión de Agile-Madrid
¿Qué vas a hacer hoy? Nada
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 20 de Enero

¿Qué hiciste ayer? Hice la presentación sobre Definition of Done al grupo de Madrid. También he escrito el resumen en el sitio de Agile-Madrid
¿Qué vas a hacer hoy? Hoy terminaré la entrada sobre la reunión en el blog :D
¿Algún impedimento? No

Reunión Diaria (Scrum Diario) del 21 de Enero

¿Qué hiciste ayer? Termina la historia de la reunión de agile Madrid :D
¿Algún impedimento? No

Foto de "portada": Galería de Wyscan en Flickr, bajo licencia Creative Commons.

Retrospectiva #1

2010-01-04T16:44:00.000+01:00

Desde que entré en esto del agilismo he aprendido muchísimas cosas. Una de las más importantes es kaizen, más conocido por mejora continua. En este caso, quiero mejorar mi forma de llevar el blog.
Una de las formas de mejorar es reflexionar sobre lo que has hecho. Para eso (y muchas más cosas) sirven las retrospectivas. Hay infinidad de formas de realizar una retrospectiva. Actualmente en los equipos en los que estoy lo hacemos como sigue:

¿Qué estamos haciendo bien y queremos seguir haciendo? Empezar por lo que se hace bien ayuda a crear un buen ambiente en la reunión y sirve para celebrar los pequeños éxitos (a nadie le amarga un dulce)
¿Qué estamos haciendo mal? Es necesario identificar en qué nos estamos equivocando para intentar evitarlo en un futuro.
Acciones para mejorar lo que hacemos mal. Si queremos mejorar debemos actuar. No vale con identificar los errores, hay que solucionarlos.

Siguiendo estos pasos voy a hacer una retrospectiva de lo que llevo de blog (un par de meses, creo). Animaos y contribuid a la retro, los comentarios están abiertos :)

¿Qué estamos haciendo bien y queremos seguir haciendo?

Sin duda, lo mejor ha sido empezar el blog :D Pensaba que no iba a darle continuidad y, aunque debería escribir más, no está del todo mal. Ocho publicaciones en dos meses :)
Otro puntazo fue que Lisa Crispin leyera el post sobre su libro y lo publicitara en twitter :) Que buena gente. Realmente, le pedí permiso y, tras dármelo, me pidió el enlace al post, pero aún así :D
Publicitar las entradas en twitter me parece dabuti. Muchos de vosotros retwitteais y ayudáis a difundirlo. Gracias a todos ;)

¿Qué estamos haciendo mal?

La periodicidad de las entradas. Hago una a la semana aproximadamente, pero es de milagro. De hecho, no me había dado cuenta hasta ahora... Menuda potra.
Ningún contenido técnico de momento. Soy el programador féliz y todavía no he enseñado ni una linea de código... Eso no está bien.
No aplico el agilismo a la hora de crear entradas. Voy a lo cowboy.
La interacción con los lectores (clientes) es casi nula. ¡No se qué os gusta y qué no! :P

Acciones

Aplicar Scrum con el blog. Ya tengo cliente (vosotros). Voy a tener una pila de producto, voy a hacer iteraciones y voy a hacer retrospectivas. Lo de hacer demo no creo :) Aquí tengo algunas dudas...

¿Cuanto debe durar la iteración? Voy a empezar probando con iteraciones de un mes, a ver que tal.
¿Publico el plan de cada iteración? Voy a crear un post con el resultado del plan para cada iteración.
¿Hago reuniones diarias? En el post con el plan iré actualizando un burndown. A ver que tal sale :)

En esa pila priorizaré algo de contenido técnico. Al menos una entrada técnica por iteración (menudo lío).
Dado que voy a aplicar Scrum, necesito un dueño de producto. De momento, el dueño de producto seré yo, pero actuaré como proxy de mis verdaderos clientes, vosotros. Por eso, si tenéis en mente algún tema del que queráis que escriba no dudéis en escribir en los comentarios.

Pues nada, me estoy metiendo en un lío pero merece la pena.
La primera planificación la haré a lo largo de esta semana (Probablemente comience la iteración el miércoles 6 de Enero). Animaos y proponed historias para la pila de producto :D

Objetivos para el 2010

2009-12-31T15:41:00.001+01:00

David Bonilla me ha "obligado" a postear el meme de los objetivos personales para el 2010. Nunca he sido de marcarme objetivos para el nuevo año (más que nada por lo vago que soy) pero esta vez haré una excepción. Hay van:

Continuar aprendiendo de (y compartiendo con) la comunidad ágil española. Estoy flipándola, de verdad. Creo que estamos creando entre todos una comunidad muy activa y divertida. Espero que este nuevo año sigamos mejorándola.
Leer muuucho. Tengo pendiente varios libros "profesionales" pero estoy empezando a echar de menos a Dostoyevski, Palahniuk, James, las Bronte, etc. Jo, que pedantón ha quedado eso. Os jodéis.
Ir a esquiar. Hace como un millón de años que no voy y tengo mazo de ganas. Ya no me acuerdo como se hace así que me romperé un brazo seguro (Eso por pedante, ahora me jodo yo).
Mejorar el blog. A principios de año publicaré una entrada con mi plan secreto... Es un experimentillo, a ver que tal sale.
Aprender un nuevo lenguaje de programación. Tengo ganas de meterme con los lenguajes dinámicos, aunque también me llama mucho Scala.
Mejorar mi ingles. Leer, escuchar y escribir va bien pero, cada vez que intento hablarlo se me seca la boca.
Mudarme de piso y, con un poco de suerte, hasta de continente :D De esto no hay nada definido, pero si salen un par de cosas bien a lo mejor me toca cruzar el charco :)
Quemar la Xbox360 dandole caña al modern warfare 2 y a todo lo que se ponga por delante.

No parece muy complicado conseguirlo ¿no? ¡Feliz año nuevo!

El coding dojo de agilismo.es

2009-12-29T01:47:00.011+01:00

Por fin tengo un ratito durante las fiestas para hablar del coding dojo que organizó agilismo.es. Fue en Okuri Spaces y fueron ayudados por Autentia (que, ademas de encargarse de la grabación del evento, nos pusieron unas cocacolas y unas pastas muy ricas).

Como he tardado unos días en escribir esto (lo siento, las comidas y cenas navideñas me han dejado KO) algunos de los asistentes ya han escrito sobre el tema. Podéis leer la opinión de Alfredo Casado y la de David Bonilla. Coincido con ellos en todo. Fue muy divertido y os recomiendo a todos que acudáis a los eventos de este estilo que se organicen cerca vuestra. No os vais a arrepentir.

De todas formas, como soy un pesado, voy a contar como fue el evento para mi.

Presentación del problema del pomodoro
agilismo.es preparó una kata nueva para este evento. Dicha kata consistía en crear una clase que representara un reloj pomodoro que sirviera para utilizarla en la técnica del pomodoro. Nos dieron unas especificaciones y nos pidieron que hicieramos dos equipos de voluntarios para codificar el pomodoro. Hay que señalar que había que hacerlo en Java sobre eclipse y haciendo TDD. Esto frenó a muchos de los asistentes pero 9 "valientes" nos animamos a mostrar nuestro Kung-Fu (Copyright de Xavi Gost). El primer equipo comenzaría el trabajo y el segundo continuaría por donde lo dejó el primero.

Aquí podéis ver al primero de los equipos planeando la estrategía:

Imagen Robada del blog de David Bonilla ;)

Los equipos dandole caña
Mi equipo fue el primero en entrar en acción. La idea era hacer programación por parejas de forma que uno de los dos componentes de la pareja hacía un test (Piloto) y el otro codificaba lo necesario para que el test pasara (Copiloto). Cada 5 minutos el piloto desalojaba, el copiloto se convertía en piloto y otro componente del equipo entraba como copiloto. Tengo que decir que contábamos con la ventaja de tener en nuestras filas a uno de los miembros de agilismo.es, José Manuel Beas, lo que nos ayudo a comenzar algo más rápido. Conseguimos crear pomodoros y asignarles una duración, aunque nos pusieron alguna pega por utilizar un operador ternario :D

Momento Ternario, con Xavi Gost metiendo el dedo en la yaga :D

No nos fue mal hasta que llegamos a la parte complicada del ejercicio, que era la parte en la que debíamos controlar que el tiempo del pomodoro se agotaba...

Momento marrón

Nos quedamos atrancadillos y les dejamos el marrón al segundo equipo que, al menos, fue capaz de volver a tener todos los test en verde.

Segundo equipo, enmarronado

La kata ejecutada por los maestros
Después de que los equipos hiciéramos lo que pudimos (no fue mucho, la verdad). José Manuel Beas se puso a los mandos del portátil para realizar el ejercicio en modo kata mientras Xavi Gost nos comentaba las discusiones de diseño que habían ido teniendo mientras preparaban el programa. Hay que decir que Beas tardo menos de 20 minutos en realizar el ejercicio y que lo enseñaron funcionando. Doy fe :P Se que van a subir el vídeo de la kata. Cuando esté actualizaré el post con el enlace. De momento os tendréis que fiar de mi :)

Agilismo.es en plena Kata

Además del vídeo de la kata creo que también iban a colgar el vídeo del evento. Cuando lo cuelguen actualizaré el post con el enlace y podréis ver a los equipos desplegar nuestro Kung-Fu, todo amenizado con los comentarios/puyas de Xavi (menudo crack). De momento podéis echarle un ojo a las fotos que han subido los chicos de Okuri Spaces aquí (Algunas os las he mostrado en el resumen) y al vídeo-montaje que han realizado los chicos de Autentia con todos los asistentes al evento.

En fin, fue un evento muy divertido. Espero que se organicen más. Mejoraré mi Kung-Fu para la próxima :D

Para mi fue todavía más molón porque Jose Manuel Beas me regalo esto:

Yo, féliz con mi pulsera

Toma pulsera de Clean Code :D Pedazo regalo de navidad.

En cuanto a la Pomodoro-Kata, prometo darle caña y mejorarla :P A ver si consigo picar a Alfredo y la hacemos en pareja.

Libros: Agile Testing (Parte 1)

2009-12-22T16:40:00.003+01:00

Desde que volví del Agile Open Spain he intentado practicar el agilismo de guerrilla de Xavi Gost y, de momento, he conseguido que nos compren todos estos libros ¡Yuju! Algunos ya los he leido, pero me pareció buena idea tenerlos en la oficina por si, algún día, alguien se interesa y lee alguno. De entre los que aún tengo pendientes de leer me decidí por Agile Testing de Lisa Crispin y Janet Gregory (Si no os dicen nada estos nombres os recomiendo ojear sus twitters y blogs. Además, por si hace falta vender un poco más el libro, sabed que contiene un prefacio escrito por Mike Cohn y otro escrito por Brian Marick ¡ahí es nada!). Les pedí permiso para hacer un pequeño resumen en castellano de su libro y me lo dieron, así que... ¡Allá vamos!

Para empezar, el libro está dividido en 6 partes, así que dedicaré un post (mínimo) a cada una de las partes. Este, como ya os imagináis, está dedicado a la primera :D

Parte I: Introducción
En esta primera parte se hace un resumen de las principales diferencias entre el enfoque ágil y el enfoque tradicional basado en fases (algo que deberíamos tener todos bien claro ya). También se explora la idea del equipo multidisciplinar ágil desde el punto de vista de la calidad y las pruebas. Además, se define lo que debe ser la "mentalidad ágil para testing" y que hace que un tester tenga éxito en un equipo ágil.

Capítulo 1: De todos modos, ¿Qué es testing ágil?

Para ser ágil es necesario ser un equipo, y es necesario que todo el equipo sea consciente de la importancia que tienen las pruebas para alcanzar una calidad alta. Pero, si todo el equipo está preocupado de probar el desarrollo ¿Cómo cuadra un tester en un equipo ágil? Debe ser consciente de su situación. Cuando un equipo es ágil, los programadores prueban los casos límite (mediante TDD). Dado que el tester queda libre del trabajo de grano fino, puede centrarse en otro tipo de problemas que aporten un mayor valor al cliente (Exploratory testing, usabilidad de la aplicación, etc).

En un equipo ágil los testers no se sientan a esperar el trabajo, dan un paso adelante y buscan formas de contribuir durante todo el ciclo de desarrollo. Estas contribuciones pueden ir desde la automatización de las pruebas (en la medida de lo posible) hasta opiniones en las charlas de diseño para que el código sea más sencillo de testear.

Al ser un equipo ágil la colaboración con el cliente es la norma. El tester debe beneficiarse de esa colaboración para definir los test de aceptación de cada funcionalidad. Cuando los test demuestran que un mínimo de funcionalidad está completo el equipo puede considerar la historia terminada.
El tester de un equipo ágil debe conocer tanto el negocio como la tecnología. Debe ser el "traductor" entre negocio y tecnología.

Conclusiones del capítulo 1

Un tester ágil debe seguir el manifiesto ágil (Individuos e interacciones, software funcionando, colaboración con el cliente y respuesta al cambio).
El testing ágil se centra en añadir valor al negocio y en entregar la calidad que el cliente solicita, diferenciándose así del testing tradicional, centrado en cumplir unos requisitos.
Todos los miembros del equipo es responsable de entregar software de alta calidad.
En caso de duda, volver a los valores y principios ágiles.

Capítulo 2: Diez principios para testers ágiles

¿Que es un tester ágil? Es un tester que acepta el cambio, sabe colaborar tanto con la gente de negocio como con la gente técnica y entiende como utilizar los test para documentar los requisitos y dirigir el diseño.

Un tester ágil no debe verse a si mismo como un policía de la calidad que protege al cliente de código inadecuado. Debe estar preparado para reunir y compartir información, para trabajar con el cliente y ayudarle a expresar sus requisitos de forma adecuada para que pueda conseguir las características que necesita y para proveer el feedback sobre el progreso del proyecto a todo el mundo.
Un tester ágil, al igual que sus compañeros de equipo, disfruta adquiriendo nuevas habilidades y no se limita a resolver únicamente problemas sobre testeo. Como cualquier otro miembro del equipo ayuda a la mejora continua tanto del proyecto como de dicho equipo.
Los 10 principios que debe seguir un tester ágil son:

Provee feedback de forma continua. Dado que las pruebas dirigen el diseño, es importante que el tester se centre en expresar los requisitos del cliente en forma de tests y que trabaje de la mano del cliente para que cualquier cambio en los requisitos llegue de forma rápida y clara al equipo de desarrollo.
Entrega valor al cliente. Un tester ágil permanece centrado en la visión global del proyecto. Si una característica se vuelve demasiado compleja debe analizar si conviene realizarla completa o simplemente hacer que funcione el camino normal (dejando los casos raros para otra iteración).
Posibilita la comunicación cara a cara. Si hay dudas sobre una cierta funcionalidad el tester debe reunir al experto de negocio y al programador para que lo discutan. Dado que el tester entiende el negocio pero también comprende la parte técnica, puede ayudar a crear un lenguaje común entre ambos mundos.
Ten coraje. Cualquier miembro de un equipo ágil debe tener coraje. Además, un tester ágil lo necesita porque, al ponerse en la situación del cliente, puede tener que decirle al equipo que algo no es correcto.
Mantenlo simple. Debe hacer las pruebas más simples posibles que verifiquen que una funcionalidad satisface las exigencias del cliente respecto a la calidad del producto. Esto no quiere decir que la funcionalidad esté implementada y que funcione, eso se presupone. Se refiere a temas como el rendimiento, la seguridad, etc.
Practica mejora continua. Debe buscar nuevas formas de ayudar al equipo (herramientas de automatización, unirse a listas de correo sobre testing, mejorar en el test exploratorio, leer artículos, libros y blogs para obtener nuevas ideas, etc).
Responde al cambio. Mediante la automatización de las pruebas es más sencillo responder al cambio. Si todas las pruebas que realiza son manuales será imposible adaptarse a los cambios a la velocidad que exige un equipo ágil.
Auto-organízate. Debe compartir con el equipo los problemas que encuentre de forma que el equipo se auto-organice para solucionar dicho problema.
Céntrate en las personas. En un equipo ágil todos sus miembros son igual de importantes y los tester no están infravalorados. Un tester ágil sabe que está ayudando al equipo de una forma única.
Disfruta. Trabajar en un equipo donde todos sus miembros colaboran, donde el tester está involucrado desde el principio del proyecto hasta el fin del mismo, donde los responsables de negocio trabajan junto al equipo de desarrollo y donde todo el equipo toma la responsabilidad tanto de las pruebas como de la calidad es un bonito lugar de trabajo para un tester.

¿Cómo añade valor un tester a un equipo ágil? Se está hablando de que, en un desarrollo ágil, las pruebas dirigen el desarrollo, pero se necesitan las pruebas correctas. El tester, con su capacidad para entender tanto el negocio como el lado técnico es capaz de aportar al equipo dichas pruebas.

Conclusiones del capítulo 2

La mentalidad de un tester ágil está centrada en el cliente, es orientada a resultados, es colaborativa y tiene muchas ganas de aprender.
La actitud es importante y difumina las fronteras entre los roles en un equipo ágil.
Los testers ágiles aplican los valores y principios ágiles (feedback, comunicación, simplicidad, entrega de valor, etc) para ayudar al equipo a identificar y entregar los requisitos del cliente.
Los testers ágiles añaden valor a sus equipos y organizaciones gracias a su punto de vista único.

Principios Ágiles #3

2009-12-15T22:53:00.003+01:00

Después del 10º encuentro del grupo de Madrid de Agile-Spain en el que charlamos sobre los principios ágiles voy a continuar con mi serie sobre dichos principios. Hoy toca el tercero de ellos:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Entregamos software frecuentemente, desde un par de semanas a un par de meses, con preferencia por los periodos más cortos posibles.

Este principio va de la mano del primero. El primer principio introduce la idea de entregas continuas de software y este tercer principio especifica un poco más como realizar dichas entregas. De forma frecuente, en iteraciones cortas, entre la semana y el mes.

¿Por qué frecuentemente?
Ya lo he hablado con anterioridad pero, en el desarrollo ágil, el feedback que aporta el cliente es muy importante tanto para llevar el proyecto a buen puerto como para mejorar el producto final. Queremos entregar software que funciona frecuentemente porque aumenta el feedback que nos aporta el cliente.

¿Por qué mejor si los periodos son lo más cortos posibles?
Porque, cuanto más pequeño sea el ciclo de desarrollo, antes le entregaremos al cliente algo que no quiere, con lo que antes nos avisará de qué es lo que realmente quiere. Ya sabéis, la movida del feedback otra vez.
Ahora bien, es fácil decirlo pero entregar software que funciona cada poco tiempo es muy difícil.

Como dice Robert C. Martin (Uncle Bob):

Takes a real man to do a one week iteration!

¡Hay que ser muy hombre para hacer iteraciones de una semana!

No es sencillo entregar software funcionando y con nuevas funcionalidades cada poco tiempo. Cuanto más corto sea el ciclo de entrega mejores deben ser nuestras prácticas de desarrollo software (¡Aupa XP!). Si, por ejemplo, tu equipo hace Scrum pero deja de lado XP es muy probable que acabe por no soportar las iteraciones cortas o, peor aún, termine entregando software que no funciona.

Conclusiones
El tercer principio ágil:

Obliga a que se entregue software que funciona cada poco (y por poco me refiero a un mes o menos).
Necesita acompañarse de una serie de prácticas de desarrollo (XP) para soportar las frecuentes entregas en ciclos cortos.
Apunta que ser ágil no es sencillo. Se debe entregar software funcionando cada poco y hay que pelear por conseguirlo. Es un objetivo ambicioso, pero es necesario.

10º Encuentro Agile-Madrid. Principios Ágiles

2009-12-08T22:46:00.001+01:00

El pasado día 1 de diciembre tuvo lugar el 10º encuentro del grupo madrileño de Agile-Spain en las instalaciones de IPSA (me tocó hacer de anfitrión/portero :D ).

El tema de la reunión era "Los Principios Ágiles detrás del Manifiesto Ágil". Parece ser que el tema interesaba porque acudimos 12 personas, entre las cuales había varias caras nuevas (Mola que siga entrando gente nueva). Personalmente me interesaba bastante conocer que pensaba el grupo sobre los principios ágiles y si sus opiniones coincidían con las mías (las cuales podéis leer en mi serie de post sobre Principios Ágiles).

Como ya os dije en el post sobre el 9º encuentro, hemos cambiado el formato de las charlas y ahora comenzamos con una pequeña presentación introductoria. Esta vez, el encargado de hacer dicha presentación era José Manuel Beas y su presentación podéis verla aquí (Esta vez no hay vídeo de la charla porque el ordenador encargado de realizar la grabación se quedó sin espacio en disco :D La próxima vez ya no nos pasa).

Tras la introducción comenzó un debate del que salieron algunas preguntas y respuestas interesantes:

¿Son los principios ágiles de obligado cumplimiento para ser ágil? Obviamente sí, pero siempre teniendo en cuenta que son principios, es decir, guías. Para ser ágil es necesario practicarlos, pero más importante es entenderlos.
¿Cómo introducir los principios en la empresa? Dado que los principios representan un cambio de mentalidad, es importante practicar con el ejemplo. Además, un enfoque "de abajo a arriba" (bottom-up) parece más sencillo que "de arriba a abajo" (top-down).
Los principios hacen hincapié en la autogestión (Principio #11). Esto puede provocar rechazo en la empresa porque saca a relucir puestos innecesarios y obliga a la gente a redefinir su trabajo.
¿Es necesaria una jerarquía en la empresa? Aquí hubo bastante discordia. Aparecieron dos bandos, "Sí hay autogestión mi jerarquía puede ser plana" y "Es necesaria una jerarquía que saque a la gente de la zona cómoda (comfort zone)". Yo, personalmente, soy partidario de la primera opinión. Los principios ágiles también piden autoexigencia y responsabilidad (Principio #9) por lo que de la "comfort zone" sales tú solito. Además, creemos en las jerarquías porque las empresas que conocemos funcionan (o no) así, pero ¿Que harías si montaras tu propia empresa? Quizás un modelo ágil más plano te funcione mejor. Aún así, en este punto no hubo acuerdo.

Una vez finalizado el debate sacamos unas pequeñas conclusiones:

Los principios ágiles marcan el camino, pero dicho camino es duro y difícil de recorrer.
Hay que creer (sin llegar al fanatismo). Es muy importante ser apasionado para conseguir convencer a otros.
La confianza hay que ganársela. Además, es muy fácil perderla por lo que hay que esforzarse en mantenerla.
Hay que invertir la polaridad en las relaciones de confianza, es decir, hay que empezar a confiar en la gente. Si no confías en la gente no esperes que la gente confíe en ti.
Hay que ser exigentes con el cliente. No se puede renunciar a los principios ágiles porque el cliente no los comparta.
Cuando hablamos de agilismo, a veces se nos olvida que negocio y tecnología deben ir de la mano, ser uno (Principio #4).
La confianza es fundamental en el mundo ágil. Para conseguirla es necesaria la transparencia.
Para ser ágil debes ser autoexigente y tener coraje y confianza(en ti mismo y en los demás).

Esto fue todo. Bueno, miento un poco. También hicimos una retrospectiva en la que nos comprometimos a:

Tener una agenda para las próximas reuniones.
Elegir los temas de forma que haya dos reuniones "teóricas" y un taller.
Grabar en vídeo las reuniones.
Crear un taller de ATDD. La propuesta la hizo Agustín Yagüe y, aunque quedamos en hacerlo fuera de las reuniones, nos pareció una muy buena idea.

Si os interesa, la próxima reunión será el día 19 de Enero de 2010 y el tema a tratar será "Definition of Done (Pruebas de Aceptación Automatizadas)". La charla la llevaremos a cabo Jose Manuel Beas (se encargará de hablar de pruebas en Concordion) y yo (hablaré de pruebas en Fitnesse), así que, os esperamos en la siguiente reunión del grupo.

Principios Ágiles #2

2009-11-24T20:22:00.009+01:00

Siguiendo con la temática de los principios ágiles, hoy voy a hablar de el segundo de ellos:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Aceptamos requisitos cambiantes, incluso en etapas avanzadas del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

¿Por qué se aceptan los requisitos cambiantes?
Porque es la forma más sencilla de adaptarse a la realidad. Aunque exista un contrato firmado por el cliente en el que se fija el "alcance" del proyecto, lo cierto es que los requisitos cambian. Normalmente un cliente no sabe exactamente lo que quiere. Su conocimiento va aumentando según avanza el proyecto y es así como consigue definir realmente su objetivo. Dado que es imposible que el proyecto no cambie hay que hacer algo para que ese cambio no sea doloroso. Ahí es donde entra este principio. Aceptar los requisitos cambiantes significa que, si el cliente cambia de opinión, hay que hacerle caso y se debe modificar el desarrollo (Recordad que "nuestra máxima prioridad es satisfacer al cliente"). No hay que utilizar el contrato como escudo contra el cliente. Hay que utilizar al cliente como compañero para conseguir que el contrato llegue a buen puerto. Es decir, se debe establecer una relación de confianza entre el cliente y el proveedor para aprovechar las ideas de ambos.

¿Por qué no importa que los cambios lleguen en etapas avanzadas de desarrollo?
Porque, al tener "entregas continuas y tempranas de software valioso", es sencillo introducir los cambios que pida el cliente en cualquier etapa. La obligación de entregar software funcionando en cualquier momento del desarrollo hace que la complejidad al introducir cambios sea constante a lo largo del tiempo. Para que este modelo sea mantenible es necesario que el equipo de desarrollo se preocupe de que la base de código sea de calidad (Prácticas XP). Si no se mejora la base de código de forma continua, aceptar los cambios será cada vez más complicado, faltando así a este principio.

¿Cómo aprovechar el cambio para proporcionar ventaja competitiva?
Al aceptar el cambio lo que en realidad se está haciendo es aumentar la velocidad de reacción del cliente, que puede reaccionar antes a los proyectos de la competencia. Es capaz de adaptar su producto para eliminar las ventajas del rival y crear las suyas propias (o, al menos, intentarlo).

Conclusiones

El segundo principio ágil:

se basa en abrazar el cambio. No hay que protegerse contra el cambio.
introduce la colaboración con el cliente. Un cliente implicado que quiere la mejor herramienta posible.
asume ciertas prácticas en el área de desarrollo (XP).
aumenta la velocidad de reacción del cliente ante el mercado.

Principios Ágiles #1

2009-11-18T23:27:00.003+01:00

Cuando uno entra en esto del agilismo lo primero que le cuentan es el Manifiesto Ágil. Conocer el manifiesto ágil es importante, pero no basta con quedarse ahí. Los autores originales del manifiesto se tomaron muchas molestias para redactar los 12 principios detrás del manifiesto y es necesario que nos los tomemos tan en serio como al propio manifiesto.
He decidido dedicar un post a cada principio. Empecemos por el primero:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Nuestra prioridad más alta es satisfacer al cliente mediante entregas continuas y tempranas de software valioso.

¿Por qué la prioridad más alta?
Es importante destacar que los firmantes del manifiesto ágil tienen un objetivo por encima del resto. Además, dicho objetivo no es negociable. Siempre debe estar presente y siempre debe cumplirse. Si no se cumple es un fracaso.Dicho objetivo es satisfacer al cliente.

¿Qué significa satisfacer al cliente?
A la hora de realizar un desarrollo es importante tener un cliente que lo demande (Cuando hablo de cliente me refiero a quien demanda dicho desarrollo. Por ejemplo, un cliente puede ser el propio desarrollador que necesita una nueva librería para un proyecto más grande. No tiene porque ser siempre un cliente que firma un contrato). Si no existe el cliente no existe el desarrollo. El cliente es el leitmotiv del desarrollo. Esto, que parece tan simple, se pierde muchas veces de vista a lo largo del desarrollo, provocando que se tomen decisiones sin contar con el cliente con lo que el desarrollo se va alejando de las necesidades de dicho cliente.

¿Por qué con entregas continuas y tempranas?
Por varios motivos. Deben realizarse entregas tempranas porque es una forma de involucrar al cliente en el desarrollo (Puede validar la usabilidad del desarrollo, puede opinar sobre el entregable, etc...). A su vez, deben realizarse entregas continuas porque de esa forma se es capaz de adaptarse a lo que el cliente quiere en cada momento. Los requisitos del cliente no son inmutables, por eso, cuanto antes se le enseñe software funcionando antes se podrá modificar de acuerdo a las nuevas necesidades del cliente.
Mediante este tipo de entregas se consigue un feedback del cliente que permite que el rumbo del desarrollo siempre apunte hacía donde el cliente desea.

¿Qué es software valioso?
Es software que funciona y que hace lo que el cliente necesita. Es fácil decirlo, pero no es nada sencillo conseguirlo.
Software que hace lo que el cliente necesita se puede conseguir mediante entregas continuas y tempranas, tal y como se ha explicado antes.
Conseguir software que funcione es mucho más complicado pero es condición necesaria para conseguir la satisfacción del cliente. Esto, que puede parecer algo obvio, se suele olvidar en la mayoría de los desarrollos. La "industria del software" (clientes y proveedores) está acostumbrada a rebajar las exigencias y a permitir errores en la mayoría de los proyectos que se realizan (ya sea por los tiempos de entrega, por la pobre formación de los desarrolladores, etc). A un desarrollo hay que exigirle que funcione y en eso es en lo que se centra el agilismo, en el software que funciona. Cualquier otra cosa dejará al cliente insatisfecho. Probablemente algún bug aparezca (ya sabéis, cualquier código contiene al menos un bug) pero se debe reducir la tasa de errores al mínimo (sobre todo en las funcionalidades principales). Es cierto que no todos los desarrollos tendrán la misma calidad (Siempre habrá desarrolladores mejores y desarrolladores peores, pero eso solo puede tener influencia en el tiempo que se tarde en realizar el proyecto, en lo fácil o difícil que sea mantener dicho proyecto, etc), pero es necesario exigirnos que funcionen (Un Seat y un Ferrari funcionan, la diferencia está en el proceso de montaje, en la calidad de los materiales, etc).

Conclusiones

El primer principio ágil:

se basa en el la satisfacción del cliente.
muestra como obtener un feedback periódico del cliente.
indica la necesidad de entregar lo que el cliente necesita.
avisa de la importancia que tiene el entregar software que funciona.

9º Encuentro Agile-Madrid. Kanban

2009-11-12T21:34:00.001+01:00

Ayer se celebró la 9ª reunión del grupo local de Madrid en las oficinas de 11870.com. El tema de la reunión era Kanban, un tema que, particularmente, me resultaba muy interesante (en mi empresa soy "Kanban-master" de un equipo). A la llamada acudimos 10 caras conocidas (todos eramos "habituales" de las reuniones, aunque yo falté a las dos últimas...) dispuestos a aprender y compartir experiencias.

La reunión comenzó con una charla de Agustín Yagüe sobre los fundamentos de Kanban (Aquí tenéis la página de la reunión. Están las transparencias de la presentación y las lecturas recomendadas. De estas, yo recomiendo ésta. Muy buen artículo. Además, José Manuel Beas ha colgado el vídeo de la presentación aquí). Normalmente no empezamos así las reuniones pero la verdad es que estuvo bien comenzar con una pequeña introducción sobre el tema porque nos hizo adoptar un vocabulario común (el expresado en la presentación). Además, la gente que no conocía Kanban pudo entender por lo menos de que se iba a discutir en la reunión.

Después de la presentación, Agustín preparó un pequeño ejercicio práctico en el que los asistentes simulábamos un proceso guiado mediante Kanban. La verdad es que fue muy divertido y bastante instructivo.

Lo que me llevo sobre Kanban de la reunión es lo siguiente:

Kanban es un sistema pull, es decir, no se hace nada hasta que te lo pida la siguiente fase (y la fase final es el cliente que demanda un producto).
Kanban está basado en señales. En el caso del desarrollo de software esas señales son los post-it con las tareas a realizar y los movimientos de dichos post-it que, al dejar un hueco indican la posibilidad de crear algo.
Los pilares de Kanban son limitar el trabajo en progreso (evitar la sobreproducción, es decir, no hacer más de lo que el cliente pida) y la mejora continua del proceso (cualquiera de los miembros del equipo es capaz de descubrir posibles mejoras en el proceso).
Kanban necesita un workflow para funcionar. Dicho workflow puede ser tan simple o tan complicado como se quiera (Desde el típico ToDo-Doing-Done hasta flujos complejos).
Kanban dice que los equipos deben ser multidisciplinares ya que, cuando una de las fases se convierte en un cuello de botella, las personas bloqueadas por dicha fase deben hacer todo lo posible por desbloquearla (Ayudando a la persona que está en dicha fase). Sin embargo, el basarse en un workflow implica cierto grado de especialidad (Tú vas a estar más tiempo en la fase a la que pertenezcas y menos en las otras, ya que en las otras solo estarás si las cosas van mal).
Que Kanban sea capaz de modelar flujos complejos puede llevarnos a pensar en desarrollo "waterfall" con equipos específicos para cada taréa. Si bien Kanban te permite modelar un proyecto a la "waterfall" no hay que olvidar que Kanban es simplemente una herramienta y que depende del que la usa.
Kanban, al limitar el trabajo en progreso de forma explícita evita el multi-tasking en los miembros del equipo, no como Scrum en el que es el propio equipo el que se autogestiona y decide si hace o no multi-tasking (aunque está claro que es una mala práctica hacerlo ;) ).

Lo que me llevo del nuevo formato de la reunión, ya que no pude quedarme a la retrospectiva es:

Empezar con una introducción/presentación me parece muy buena idea, aunque quizás debería haber sido algo más corta. Ayuda a que todos los asistentes sepan de que se está hablando.
Aunque nos vamos de hora (yo me fuí a las diez menos veinte y todavía quedaba la retro) me quedo con ganas de más :D
Me perdí las cañas :(

Agile Open Spain 2009

2009-10-27T17:27:00.007+01:00

El pasado 23 y 24 de octubre se celebró en la Universidad Politécnica de Madrid el primer (y esperemos que no último) Agile Open Spain. Os presento mis recuerdos de las sesiones a las que asistí.

Lean in Agile Adoption

En un principio esta charla la iba a introducir Robin Dymond, pero no pudo asistir (Creemos que se quedó sobado, pero no estamos seguros) y Xavier Quesada se encargó de reemplazarlo. Xavier Quesada es uno de los impulsores del agilismo hispanohablante y siempre es un placer poder escuchar sus opiniones.

Estuvimos hablando un poco sobre los principios Lean y su posible mapeo al desarrollo de software, aunque teníamos claro que no había que tomarlos como reglas (por algo son principios).

Lo más interesante de esta charla fue cuando Xavier nos introdujo el concepto de Value Stream Mapping y como aplicarlo en tu empresa para eliminar tiempos de espera. En próximas entradas intentaré hablar de ésto con algo más de conocimiento porque la verdad es que merece la pena.

Caminos de adopción ágil

Esta sesión la presentaban Jorge Uriarte y Angel Medinilla. Tenía muchas ganas de conocerles y la verdad es que no me defraudaron. Son dos monstruos del agilismo español.

La sesión comenzó con la identificación de problemas a la hora de implementar una metodología ágil en tu empresa. Aparecieron cuatro grandes grupos de impedimentos:

La gerencia no apoya el cambio. La causa principal de esta falta de apoyo se debe a que no sabemos venderle a la gerencia las virtudes del cambio ágil. Debemos aprender a hablar el idioma de la gerencia si queremos que nos hagan caso.
Los compañeros no quieren modificar su forma de trabajar. Una parte de la plantilla teme que la transparencia que aportan las metodologías ágiles muestre su poca productividad. Se planteo que, a la hora de realizar cualquier cambio, primero hay que aliarse con los emprendedores de la empresa y después convencer a la gran masa de indecisos, de forma que los intransigentes al cambio no tengan más remedio que tragar.
Los clientes no se implican. Se habló de que al cliente había que venderle las ventajas. Un cliente no va a decir que no a entregas mensuales, no va a decir que no a un informe diario del estado del proyecto, no va a decir que no a la posibilidad de modificar el proyecto si descubre que lo que pidió no le sirve, etc.
El proceso de implantación no funciona. La mayoría de los problemas encontrados en este grupo se referían a la fase en la que ya hemos conseguido implantar la metodología en algún equipo pero se hacía difícil escalar a toda la empresa.

Agilismo de guerrilla

Xavi Gost, para mi el crack del evento, introdujo el tema de como implantar en el agilismo (y sobre todo las prácticas de XP) en una empresa sin permiso. Fue una charla espectacular. Manipulación, engaño, sabotaje... todo tiene cabida a la hora de implantar ágil :D

Los puntos más importantes de la sesión:

Hay que ser valiente. Si nadie hace test, empieza tú. No han despedido a nadie por hacer test pero, si te echan, además de ser unos capullos, que lo pongan en la carta de despido. Es probable que te sirva como carta de recomendación en otra empresa :D
No hay que esperar agradecimiento. Haces XP porque te gusta y porque quieres cambiar la industria. Si tus compañeros no hacen pair programming pideles ayuda con algo, aunque sepas hacerlo. Estarán haciendo pair programming sin saberlo.
Haz integración continua. Aunque sea monta un Hudson en tu equipo. Cuando el equipo se acostumbre a él, quitaselo. Veras como empiezan a pedir un servidor de IC :D
Un guerrillero no debe ir de cara contra el ejercito. Es decir, se sutil. No te lances al vacío. Ve poco a poco. Conquista primero a los que están más cerca y expándete poco a poco.
A veces, un guerrillero tiene que sabotear por el bien común. Si un proyecto es un infierno en cuanto a mantenibilidad y consumo de recursos, haz que dicho infierno sea visible para la gerencia.
Si tus compañeros se resisten al cambio, utiliza la manipulación. Si no quieren hacer reuniones diarias invítales todos los días a un café y que te cuenten en que andan.

Fue una charla muy divertida en la que se dijeron verdades como puños.

The rise of the agile hacker (o la charla del queso)

Luismi Cavallé propuso una de las charlas más interesantes del Agile Open Spain. Nos introdujo el movimiento ARxTA. Si visitáis la página veréis que la primera frase dice algo así como:

Nosotros creemos que el manifiesto ágil está siendo simplificado, su idea se está comercializando y está perdiendo su espíritu.

Brian Marick, uno de los firmantes originales del manifiesto ágil, está impulsando este movimiento debido a la creciente comercialización de la marca "Agile". El nombre completo de este movimiento es Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism.

Artisanal: Se refiere a que el programador es más un artesano que un ingeniero. Este concepto ya apreció en varias de las sesiones del Agile Open Spain.
Retro-Futurism: Es cierto que las personas son más importantes que la tecnología, pero también es muy importante el uso que esas personas le dan a la tecnología a la hora de desarrollar software. Además, la tecnología es necesaria. Por ejemplo, Ron Jeffries dice "si no haces XP, olvidate de hacer SCRUM" ¿Como haces XP con FORTRAN?
Team-Scale Anarcho-Syndicalism: Es importante la autogestión a nivel de equipo, pero ¿por qué no pensamos más allá? ¿Son necesarios los jefes? ¿Por qué no es posible una comunidad de programadores artesanos capaces de autogestionarse a la hora de repartirse el trabajo existente?

A mi esta sesión me dejo trastocado. Salí emocionado y con ganas de trabajar e impulsar el movimiento ARxTA.

Mortal Kombat y Pair Programming
La sesión comenzó con un pequeño debate sobre si XP mola o no mola. La opinión generalizada es que es útil cuando los niveles de la pareja son aprendiz-maestro pero que realmente es poderosa cuando se realiza entre pares equilibrados.

Tras la pequeña discusión comenzó el combate entre José Manuel Beas y Xavi Gost. Hicieron una sesión de Ping-Pong Programming que dio mucho que hablar sobre estilo.

Conclusiones

Para mi ha sido una de las mejores "conferencias" en las que he estado. Espero que se repita y que, como dice Xavi Gost:

Mantengamos el Open Agile como un evento por y para la comunidad[...]
mantengamos el Open Agile lo mas "puro" posible y si se pudiera
financiar de los restos de otros eventos (conferencias , cursos,
jornadas) de pago , lo ideal es que no tuviera ni sponsors

Presentación: ¿Por qué un blog?

2009-10-27T00:01:00.004+01:00

Porque después de estar en el Agile Open Spain 2009 tengo la necesidad de seguir compartiendo.

Porque creo que es necesario aprovechar el impulso y generar contenido en español tanto sobre metodologías ágiles como sobre buenas prácticas en el desarrollo de software.

Porque quiero una comunidad activa, que comparta y aprenda.

Porque, aunque aún se que tengo mucho que aprender, creo que puedo enseñar algo de lo que ya he aprendido.

Porque me apetece.

Mi nombre es Alberto Peña y soy agilista :D