A software developer cookbook

Porque no se cancelan las operaciones en Eclipse

2012-01-24T18:55:00.001Z

Ya llevamos muchos días del nuevo año y no he escrito nada en el blog, pero hoy el amigo @kinisoftware ha escrito un tweet que me ha dado la clave para escribir un artículo breve, pero curioso. Muchas gracias amigo, has venido al rescate en el momento justo :-D

¿Por qué tendrá Eclipse un botón "Cancelar" en las ventajas de acciones en ejecución que si lo pulsas te ignora? Quítalo directamente xD by @kinisoftware

Cuando leí este tweet no tuve más remedio que reírme por la razón que tiene Kini, pero también me vino a la cabeza aquellos tiempos en los que estuve trabajando en un plugin para Eclipse, que tampoco fue en la era del Jurásico, debió ser allá por la versión 3.5 de Eclipse. Mientras leía el libro que teníamos de referencia y me peleaba con el código, llegué a una interfaz llamada IProgressMonitor, ahora verás para que sirve esta interfaz tan curiosa.

La biblia del desarrollo de plugins para Eclipse

IProgressMonitor es la interfaz que deben implementar las actividades para poder aparecer en la pestaña esa tan molona que tiene el Eclipse, sí esa en la que aparece el progreso de cada actividad que esta en ejecución. Esa en la que Kini y todos nosotros apretamos el cuadradito rojo y no pasa nada de nada. Si vamos a la página de la API de Eclipse que contiene la información de IProgressMonitor, podemos leer lo siguiente.

"A request to cancel an operation can be signaled using the setCanceled method. Operations taking a progress monitor are expected to poll the monitor (using isCanceled) periodically and abort at their earliest convenience. Operation can however choose to ignore cancelation requests."

Lo que viene a decir eso es que Eclipse provee una forma para cancelar las tareas, pero se deja a elección de los desarrolladores del plugin de turno como hacerlo, intuyo que se decantan por esa parte de "Operation can however choose to ignore cancellation requests". Esta claro que la cancelación no siempre es posible o la lógica es tremendamente complicada, pero seamos serios, un gran porcentaje de plugins hacen lo siguiente.

class MiActividad ... implements IProcessMonitor {
...

public boolean isCanceled() {}

public void setCanceled(boolean value) {}

...
}

Y a grandes rasgos esta es la razón por la que no funciona el botón de cancelar en Eclipse ... porque no está implementada :-)

Retrospectiva del año 2011

2011-12-27T09:02:00.000Z

Otro año más David Bonilla hace su retrospectiva del año y de rebote nos mete a los demás en el embolado, y como a los amigos hay que responderles, aqui va mi entrada. Aprovecho para hacer la retrospectiva hoy, porque es mi 31 cumpleaños y nada mejor para celebrarlo que recapacitar sobre lo sucedido los 365 días anteriores.

El año pasado había planteado unos objetivos que para ser sinceros no he tenido muy en cuenta a lo largo del año, pero por suerte gran parte de ellos se han cumplido muy bien, y por "desgracia" otros no tanto.

En el trabajo diario en AvanTIC hemos descuidado un poco el proceso Scrum, sobretodo en la parte final del año donde más presión había, pero por otro lado hemos mejorado mucho la calidad de nuestros productos, en gran medida por la adopción un poco más generalizada de TDD y la revisión "oficiosa" de código. Digamos que este objetivo no se ha cumplido, pero tampoco ha caído en saco roto.
Lo que sí se ha cumplido con creces es la asistencia a los dos eventos de Agile Spain, la Conferencias Agile Spain 2011 y el Agile Open Spain 2011. No solo eso, sino que asistí a la SpringIO 2011 y a la fantástica Apache Barcamp Spain 2011, un año surtido de eventos, sobretodo para mi que vivo en Canarias. Y para rematarlo pude hacer algo que tenía en la cabeza desde hacía bastante tiempo, pasé una semana con la gente de BeCode y Enrique Amodeo, una experiencia que me pareció increíble.
Otro objetivo cumplido con creces ha sido el de aumentar el número de entradas en el blog, aunque creo que todavía queda mucho camino por recorrer hasta que sea un hábito más cotidiano.
Y los dos grandes fracasos del año, han sido ... no he ido a Nueva York :-( y he terminado desistiendo de intentar organizar la AOS en Tenerife, todavía falta que la comunidad local crezca un poco y madure, pero Zaragoza será una anfitriona genial seguro :-)

Como toda buena retrospectiva también habrá que pensar en los objetivos para el próximo año.

Como comenté antes he desistido de la idea de una AOS en Canarias, pero eso no quiere decir que no intentemos organizar un evento, así que preparaos para la Código Picón 2012 :-D
Después de las lecciones aprendidas del maestro Roberto Canales en la Apache Barcamp, este año intentaré aprender y desarrollar otras cosas que aporten valor a mi trabajo diario, pero sin descuidar mis conocimientos técnicos.
Espero poder participar activamente en la zona profesional de la Tenerife Lan Party 2012 que tan bien salió este año.
Al final del año creo que he mejorado mucho como profesional y espero poder mantener esa evolución el próximo año, sobretodo asistiendo a eventos (que aún no he decidido) y compartiendo mi tiempo con los magnificos amigos y profesionales que suelen asistir a este tipo de reuniones.
Para acabar espero poder hacer el maldito viaje a Nueva York de una vez, aunque parece que este no es el año más indicado :-S

Espero poder leer las retrospectivas de toda la gente a la que David Bonilla citó en su blog y algunos más.

P.D: ni que decir tiene que el objetivo de hacer más deporte en 2011 tampoco se cumplió, por eso ni lo mencionaré para 2012 :-)

The Clean Coder

2011-12-08T16:04:00.001Z

Hace unos días he terminado de leer el último libro de Robert C. Martin, más conocido como Uncle Bob, The Clean Coder. Lo empecé a leer porque bastante gente de la comunidad de desarrolladores española lo tenían muy bien valorado, pero no os mentiré, me ha decepcionado bastante.

¿Qué es lo que no me ha gustado?, pues dos cosas principalmente. Por un lado, es un libro increíblemente largo para la idea que intenta transmitir, y sinceramente no es que tenga tantas páginas. Pero en gran medida me pareció que eran más relleno para satisfacer a la editorial que una necesidad real para transmitir la idea. No te equivoques, la idea en si misma es muy importante y la comparto casi al 100%, pero puede resultar un poco "machacona" si ya has oído hablar sobre software craftmanship, la importancia de las personas u otros aspectos tan importantes como asumir tu propia responsabilidad en el proceso del desarrollo de software y en los errores que cometes.

Por otro lado no me gustó el tono en algunos párrafos o capítulos del libro. Bob Martin da una definición de lo que para él es un profesional, y cualquier persona que no cumpla sus condiciones no alcanza esa definición. No le quito su parte de razón, pero quizás habría sido más convincente en un tono menos autoritario o incluso menos prepotente me atrevería a decir. Lo que sí puedes hacer, y es algo recomendable, es extraer las lecciones que el propio autor aprendió a lo largo de su carrera en base a los errores que él mismo cometió, son estas anécdotas las que considero que merecen el precio del libro.

Algunas veces solemos poner notas a los libros que leemos, en este caso prefiero no hacerlo, quizás a partir de su anterior libro Clean Code y de las opiniones que ya había leído me hice una idea equivocada, y por tanto esa nota podría estar sesgada. Pero me da la impresión que para aquellas personas que están metidas en comunidad ágiles, que practican todos los días fuera de su horario de trabajo y que intentan mejorar día a día, no aprenderán nada especialmente nuevo en este libro.

*Disclaimer*

Por supuesto mi opinión del libro no tiene nada que ver con la opinión que tengo de su autor, cuyo anterior libro me parece un imprescindible, y cuya calidad profesional no cuestiono en ningún momento :-)

Windows Phone Roadshow en Tenerife

2011-11-28T12:44:00.001Z

Este sábado he tenido el placer de estar en el Windows Phone Roadshow, que pasó por la facultad de física de la Universidad de La Laguna, entre otros muchos lugares de la geografía española. @josueyeray, @rafasermed y @adiazcan estuvieron desde las 9 de la mañana hasta las 6 de la tarde hablando sobre las novedades que aportaba el nuevo dispositivo de Microsoft, sus herramientas de desarrollo o el "market" de aplicaciones, entre otras cosas.

Muchos os preguntareis que hacía yo en ese evento, un desarrollador que utiliza habitualmente un MacBook como herramienta de trabajo, que tiene un móvil con Android y defensor a ultranza de las metodologías ágiles. Quitando el aspecto de las metodologías ágiles, que Microsoft también utiliza, es importante conocer las diferentes opciones existentes. Cuando desarrollas aplicaciones para smartphones es importante saber cuál es la cuota de mercado de cada plataforma, si se pueden utilizar herramientas como PhoneGap para desarrollar aplicaciones multiplataforma o si simplemente no es una opción a tener en cuenta.

Presentación de la conferencia a cargo de José Fortes

Sería muy largo detallar el contenido de cada una de las presentaciones y además sería muy complicado dar una idea adecuada sin material audiovisual. Basta decir que el evento estuvo bastante bien, pero sí que quiero tocar algunos puntos o conclusiones que yo mismo obtuve.

Los terminales y el funcionamiento de los mismos me gustó bastante, aunque en contra de lo que se intentaba mostrar, no llegué a ver nada que no hubiese visto anteriormente en otros modelos del mercado con otros sistemas operativos. Pero me gusto que hubiesen diversas marcas fabricando terminales y que Microsoft tuviese cuidado de fijar algunos parámetros como la resolución de los mismos, un fallo que Android no pudo controlar y que hace que las pruebas sean más complejas.
En una sala casi repleta de terminales con Android y manzanas iluminadas se abrió un debate que en mi opinión no debía haber ocurrido. Los fanboys (tanto de Apple como de Google) obviamente atacaron a la gente de Microsoft, y estos que no eran menos fanáticos continuaron un debate interminable. Sinceramente un error por parte de los ponentes, debes capear el temporal y atender a toda la gente que independientemente de su postura quería conocer la plataforma (como yo :-)
Las herramientas de desarrollo ... lo puedo resumir en pocas palabras, muy buenas. Me gustaron mucho las herramientas que enseñaron, en el caso de Visual Studio estoy más acostumbrado a Eclipse y me gusta más este último, pero el simulador del móvil y el Microsoft Expression Blend eran sencillamente geniales, mucho mejor que las de Apple y Google (por el momento claro).
El market. Nada nuevo bajo el Sol. Un sistema muy similar al de Apple, más cerrado que el de Android, más barato que el de Apple, no hay mucho más que decir, es una opción más que coherente. Aunque creo que si hay un gran crecimiento en el número de desarrolladores y de aplicaciones para estos terminales, el proceso de aprobación de las aplicaciones se ralentizará mucho, actualmente está sobre los 3 días.
Lo que más me preocupaba ahora era saber si PhoneGap tenía soporte para esta nueva plataforma, y me agradó escuchar que @josueyeray ya había realizado dos aplicaciones en Plain Concepts utilizando PhoneGap. Todos sabemos que no es lo mismo que la página web de PhonegGap diga que soporta Windows Phone a que ya hayan ejemplos reales.

Actualmente la cuota de mercado de los teléfonos de Microsoft es muy baja, si subirá o no es algo de lo que no tengo ni idea. Desde luego el producto es lo bastante bueno, y el crecimiento del market prometedor, pero ha llegado muy tarde respecto a Apple y Google, y sin ofrecer nada realmente nuevo que no tuviesen ellos. Veremos como evoluciona.

Para acabar quiero felicitar a los tres ponentes, a los patrocinadores y a la gente de TenerifeDev por realizar el evento que, todo sea dicho, salió muy bien y tuvo una asistencia más que digna. ¿Sería porque regalaban 5 "Windows Phones"? :-D

@adiazcan entregando uno de los móviles que sorteaban

The BeCode Chronicles (día 5)

2011-10-28T22:22:00.001+01:00

Hoy ha sido mi último día en @beCodeMyFriend, y como ya dije ayer, es una sensación agridulce. Por un lado me da pena irme, pero por otro ahora tengo la oportunidad de aplicar todas las cosas que he aprendido en esta experiencia.

Como mola, ya tengo mi camiseta de BeCode

Hoy no hemos trabajado mucho en Cuore.js, por lo que me gustaría hablar de las razones por las que creo que todo el mundo debería tener una experiencia como esta de vez en cuando, en base a mi experiencia personal.

Te fuerza a salir de tu zona de comfort. Trabajar en otro ambiente, con otras personas, en otras tecnologías y proyectos, te fuerza a plantearte cosas que no te planteas en tu día a día, lo cual genera nuevo conocimiento.
Expone tu ignorancia. Probablemente no serás muy eficiente en la tecnología que utilice la empresa a la que vayas, por lo que no te quedará más remedio que exponer tu ignorancia, lo cual se premia con nuevo conocimiento que pasa a formar parte de tu "caja de herramientas".
Fomenta el pensamiento lateral. Por lo menos en el caso de @beCodeMyFriend, se trabaja en muchos frentes y esto implica que generas conocimiento de áreas que generalmente no aprendes. Además conoces a muchas personas distintas y se pueden generan muchas oportunidades de negocio.
Probablemente disfrutarás de un ambiente creativo. Las empresas que se apuntan a una experiencia de desk-surfing por lo general tienen un ambiente bastante creativo alejado de las consultoras clásicas. Esto es genial porque te llena la cabeza de ideas que en el futuro pueden ser buenos proyectos.
Aunque para muchos esto no significará nada, en un desk-surfing se hacen amigos, lo cual fomenta el trato con las personas y además hace que te lo pases bien. Desengañaos, los informáticos no somos antisociales ni trabajamos en el sótano de la empresa.

Que quieras hacer un desk-surfing o no, tan solo está en tu mano, pero luego no digas que no te lo han dicho :-) Para finalizar me gustaría agradecer a toda la gente con la que he compartido esta semana, no los voy a citar porque siempre me olvido a alguien y no es mi intención, todos han sido parte de la experiencia y me alegro de que haya sido de esa manera.

The BeCode Chronicles (day 4)

2011-10-27T21:34:00.002+01:00

Today I will write a short post ... hey wait wait wait, what's happening here? this is in english!!! ... yeah of course, because today was english day at BeCode!!!

Dessert of the day, I work really hard to deserve it :-)

This is the thing I would like to talk today, I know I'm really bad with english, but in BeCode they expose their ignorance and they go out of their comfort zone all the time (look for these patterns on Apprenticeship patterns, a really good book). I can't be less and I'll work as hard as them to improve my skills.

Today was a rainy day, but I went out to take a breakfast and buy some croissants like the other days, I don't like too much change some habits. While I was walking I thought "I will do really bad". In the end I think it was really nice and I learned a lot, it's easy with supportive people like them. The hard thing with this is you are twice as tired, because you need to think on the programming problems and the english thing. Believe me!, it deserve the effort.

Some people could think this is a really poor post, yeah it is. So, yes today I was working on software development like other days. I was busy all day with Cuore.js. The morning was nice but not really a lot of work done, more discussions and thinking on the architecture than other thing, but it is absolutely necessary. In the afternoon came all the work on the Handlers Set, to clean the component excess of responsibility. You can see the result here.

After a large day like this, the "Dr. Amodeo", a friend of him called Dani, @elmendalerenda and me went to take a nice dinner on Bocconcino, a small and nice Italian in the Barrio del Carmen. Good pizza and a nice Tiramisu for a nice end of the day.

Now I have a bittersweet feeling because my desk-surfing is ending and tomorrow will be my last day on BeCode :-( But I have a lot of illusion to return to AvanTIC where I will put in practice a lot of the things I learned here.

Special thanks to Google Translate :-D

The BeCode Chronicles (día 3)

2011-10-26T22:05:00.000+01:00

Hoy tengo una sensación un poco extraña, ya es mitad de semana y me da la impresión de que lleve aquí un mes, pero por otro lado los días se me pasan volando. Atribuyo esto a que me lo estoy pasando muy bien y estar continuamente aprendiendo cosas hace que no pueda plantearme nada más.

Me encanta la decoración de mi habitación en BeCode!!! :-)

Esta vez me gustaría entrar un poco menos en las tareas técnicas que he hecho y contaré como es para mi un día en BeCode. Para empezar siempre me levanto a las siete de la mañana, lo cual no está mal porque en Tenerife me levanto sobre las seis, me doy una ducha y me preparo. Luego salgo a dar una vuelta por el barrio del Carmen y tras un desayuno con zumo de naranja valenciana y tostadas con aceite y tomate, paso por una panadería a comprar algo para el desayuno de media mañana (parece que esté hablando de hobbits). Esta rutina para mi es importante porque la gente de BeCode me está dejando quedarme en su apartamento sin coste alguno, y es un mínimo e insignificante detalle que puedo tener con ellos.

Hoy el primero en llegar ha sido @markitosco y los demás han tardado un buen rato en llegar, por lo que he aprovechado para seguir trabajando en Cuore.js. Si quieres ver lo que he hecho durante ese tiempo puedes pinchar en el siguiente enlace. Antes de subir al repositorio obviamente he revisado un poco el código con @eamodeorubio que le ha dado el visto bueno y hemos refactorizado algún detalle, ya sabeis que yo no tengo casi experiencia con Javascript de producción y no es adecuado subir al repositorio cosas que no funcionan :-P

Como todos los días he estado un rato con @elmendalerenda trabajando en DaChop, y es interesante porque te hace sentir parte de BeCode poder trabajar en aplicaciones reales que ellos están desarrollando, además de Cuore.js claro. Me gusta trabajar con @elmendalerenda porque es muy aficionado a utilizar la técnica pomodoro al igual que yo, y me hace mucha gracia como contrasta un poco dentro de la diversidad del ambiente ya que creo que es la persona más seria del equipo, cuidado he dicho serio que no aburrido. Sinceramente a veces la oficina parece una guardería, un poco chocante para mi, porque en AvanTIC normalmente está todo bastante silencioso. Pero no os engañéis, esto no quiere decir que no trabajen porque lo hacen y muy bien. Ese ambiente se produce porque BeCode tiene sus puertas abiertas, de forma literal, a cualquier persona que quiera entrar, hoy por ejemplo pasaron la cartera y la revisora de la empresa de agua por la oficina para entrar al edificio. Bromas a parte, explicado por @XaV1uzz, la idea de BeCode es diluir las fronteras entre los componentes de la empresa incluyendo los que aportan el capital, cualquier persona se siente parte del equipo, y yo lo puedo confirmar como invitado que soy.

Por la tarde, cuando @eamodeorubio y yo volvimos del almuerzo, nos pusimos junto a @elmendalerenda a seguir trabajando en Cuore.js, creemos que @elmendalerenda tiene miedo de que lo rompamos :-P Si quieres ver los cambios que hicimos, la gran mayoría aportación de @eamodeorubio, puedes ver este enlace.

Otra cosa que he visto hoy que en otro tipo de empresas es más complicado de ver, es que todo el mundo hace lo que haya que hacer para que las cosas salgan, si hay que limpiar el armario del servidor se limpia y si hace falta pasar cable se pasa, seas quien seas, no hay diferencia de estatus. Aquí prima una práctica que también usan en Autentia y que me contó una vez @alejandropgarci, "No hay trabajo indigno".

Para finalizar el día fuimos a tomar una cerveza y a acompañar a @eamodeorubio a la estación de metro. Por el camino pude seguir hablando con @XaV1uzz, el cual día tras día me demuestra que tiene la cabeza muy bien amueblada, otra cosa es que a primera vista parezca más bruto que un arado :-)

Y fin ya!!!, mañana vendrá más y muy interesante porque toca día de inglés en BeCode, ¿será la entrada de mañana en inglés?

The BeCode Chronicles (día 2)

2011-10-25T21:48:00.000+01:00

Ya ha llegado el segundo día en mi aventura con @beCodeMyFriend y parece que sigo vivo. El primer día ha servido para tomar el pulso a la situación, ahora parece que ya he calentado (un poco) y puedo empezar a participar más.

La famosa pizarra de tareas de BeCode, quizás la explique otro día :-D

He empezado el día con @elmendalerenda haciendo un poco de pair-programming en DaChop para completar la funcionalidad con la que estaba trabajando. Como DaChop aún utiliza una versión anterior de Cuore.js me ha permitido comprobar algunos problemas que se producían, y que el equipo de BeCode había corregido para la versión que se presentó en la CAS2011. Además pude seguir viendo como se utiliza Cuore.js en una aplicación real, lo que me permite tener una visión más global de su funcionamiento, cuestión fundamental para poder empezar a cambiar cosas en el framework.

Tras tomar un café con @elmendalerenda esperando a que llegaran @eamodeorubio y @XaV1uzz, empezamos a trabajar en Cuore.js en el punto que lo habíamos dejado el día anterior. Ya habíamos creado el Directorio de Servicios y hoy completamos el Registro de Componentes, es muy interesante porque es una refactorización "muy sencilla" pero que añade mucha expresividad y desacopla la solución. Para resumirlo en pocas línea, lo que hemos hecho es hacer explícitos dos objetos que estaban modelados como arrays o mapas de Javascript, ¿y qué logramos con esto?, muy simple, que la responsabilidad de cada elemento esté encapsulada en el mismo y no en otro componente que crece para albergarlo todo. Por si te orientas mejor, aquí te dejo un dibujito ... pero te recomiendo que veas los cambios en el repositorio de GitHub por si no lo has hecho ya, que deberías.

No tengo ningún programa de modelado UML, yo solo uso lápiz y papel para estas cosas :-P

Dado que la gente de BeCode estaba ocupada haciendo incubaciones y hablando con sus inversores, es increíble la cantidad de gente que pasa por sus oficinas al día, @eamodeorubio y yo continuamos por introducir el Registro y el Directorio que ya teníamos hecho, en el componente Página de Cuore.js. Fue una tarea un poco larga pero relativamente sencilla porque contábamos con los tests que ya estaban hechos, como las relaciones ahora son ligeramente distintas algunos tests fallaron y lo que hicimos fue revisarlos y verificar los nuevos comportamientos que debían tener. Quizás te interese echarle un vistazo a los siguientes ficheros en el repositorio de código, para ver como han evolucionado, con sus respectivos tests.

Cuore.Page.js (Cuore.Page.Spec.js)
Cuore.Directory.js (si el de arriba se llama Cuore.Page.js y su test Cuore.Page.Spec.js, ¿cómo crees que será en este caso?, aplica la misma lógica la resto de ficheros)
Cuore.Registry.js
Cuore.Component.js
Cuore.Renderer.js

Si no encuentras algún fichero, recuerda que estamos trabajando en una rama llamada pagesurgery, ¿no has leído mi entrada anterior?

El resto del día ha transcurrido con normalidad, pero hay una cosa que me ha sorprendido de este lugar y que demuestra su madurez. Aquí nadie revisa el trabajo de los demás, todo el mundo sabe lo que tiene que hacer y como para alcanzar el bien común. Si quieres te levantas y te vas un rato a la calle, si tienes cosas que hacer las haces sin necesidad de responder ante nadie, porque todo el mundo entrega su trabajo y colabora con los demás para que el equipo avance.

Por supuesto, a lo largo de un día en este lugar aprendes muchas más cosas y mi libreta siempre acaba con un montón de anotaciones, pero no se puede expresar todo en una sola entrada. Quizás de mi temporada salgan nuevos posts en el futuro, ¿quién sabe?.

The BeCode Chronicles (día 1)

2011-10-24T22:33:00.000+01:00

Como ya sabéis por la entrada anterior, hoy ha sido mi primer día de desk-surfing con la gente de @beCodeMyFriend, todavía me tengo que adaptar un poco más a la forma de trabajar de ellos, pero ha sido toda una experiencia. Me he sentido casi como si estuviera en AvanTIC porque la gente es muy amable y acogedora, aunque no me voy a soltar en halagos, eso lo haré en el último de los posts, sino que voy a hablar del turrón, de como se trabaja aquí.

No lo he dicho, pero la gente de BeCode me ha prestado su apartamento para pasar la estancia, como molan!!!

Para empezar, en BeCode no tienen un horario fijo sino que la gente va llegando poco a poco, por lo que a primera hora pude pasar un rato con @elmendalerenda haciendo pair programming de una funcionalidad de DaChop. Esto me ha servido para conocer un poco mejor cual es la utilidad de Cuore.js, que ha sido esencial para no andar tan perdido en mis tareas posteriores.

Cuando todo el equipo estaba en la oficina, se ha realizado una reunión de planificación semanal, es como un stand-up meeting, pero sin estar de pie y con una previsión de una semana. Básicamente se habla de lo que se abordará esta semana y de las cosas que se pretenden dejar cerradas a final de semana. Es una práctica que me ha gustado mucho, porque permite tener unos objetivos a corto plazo un poco más generales que los que se suelen establecer en un stand-up meeting. Aunque mantendría la costumbre de estar de pie para que la reunión no se dilate más de lo necesario, cuestión de gustos.

@eamodeorubio y yo hemos decidido pasar la mañana investigando un poco en el código de Cuore.js antes de poder empezar a hacer "cirugía" en el mismo, todo sea dicho @eamodeorubio ha hecho de cirujano y yo de asistente, no voy a mentir. La tarea se ha simplificado mucho porque todo el código tiene tests, esto simplifica mucho el estudio del código porque se puede hacer abordando los diferentes tests de los que se dispone. Ya puedes añadir esto como otra excusa para hacer TDD, por si no lo sabías ya. Al final hemos sacado tres o cuatro páginas de posibles mejoras que posteriormente discutiríamos con @XaV1uzz.

Cuando ya estábamos empezando a notarnos cansados, hemos ido a tomar unas ricas tapas con @eamodeorubio por el barrio del Carmen y hemos estado hablando sobre los proyectos personales que tiene, y un poco sobre como se presenta el futuro del desarrollo de software en este país.

A la vuelta a las oficinas de BeCode nos hemos sentado con @XaV1uzz y ha tocado sacar el bisturí, es el momento de empezar a hacer el trabajo fino. Lo mejor que puedes hacer es conectarte al repositorio de GitHub donde se aloja Cuore.js e ir viendo los avances, pero yo te comentaré cual ha sido el cambio que hemos hecho hoy. Lo que he dicho sobre el bisturí es completamente literal, mira el nombre de la rama que hemos creado, pagesurgery :-) Esto se debe a que la página tiene una serie de servicios y los mismos pueden ser añadidos y ejecutados desde la página, lo cual hace que la misma tenga demasiadas responsabilidades. ¿Cuál es la solución?, pues se ha optado por crear un Directorio de Servicios de forma que se depuren un poco las responsabilidades.

A continuación puedes ver como hemos definido primero el comportamiento que queremos que tenga el Directorio y como luego hemos realizado la implementación. Con la ayuda de @eamodeorubio he podido empezar a meter un poco de mano y reconozco que aunque ha sido muy poco me siento bastante contento, es increíble la cantidad de cosas que se pueden aprender de un lenguaje en un solo día cuando estas rodeado de gente tan profesional.

Después de quedarnos satisfechos con los cambios y enfocar las tareas que tendremos que abordar mañana, hemos cerrado las puertas de BeCode para ir a tomarnos unas cañas y hablar un rato, pero eso ya no es una cuestión de este blog :-)

The BeCode Chronicles (día 0)

2011-10-23T18:29:00.000+01:00

Ayer por la noche llegué a la ciudad de Valencia, directo desde la estación de Nord al centro de operaciones de @beCodeMyFriend. Durante una semana entera estaré por aquí compartiendo y aprendiendo con la gente de BeCode y con @eamodeorubio, unas personas muy peculiares que sorprenden a todos por su apariencia irreverente pero con un fondo increíble, al fin y al cabo son "la incubadora punk".

Conocí brevemente a Xavi Gost en la Agile Open Spain 2010 en Barcelona, y desde luego a primera vista me pareció un radical, no sabía si estaba de broma todo el rato o es que realmente es así, pero cuando te paras a hablar con él y escuchas, comprendes rápidamente que se trata de una persona con una experiencia inmensa y de la que se puede aprender mucho. Pues después de la primera invitación que me hizo en esa edición de la AOS, tener que asistir a otra edición más y conocer a parte del equipo, aquí estoy en "El Apartamento". Antes de continuar también hay que agradecer a la gente que hay detrás de desk-surfing.org y que promueven este tipo de movimiento.

Muchas de las personas que echan un ojo a este blog ya sabían de esta experiencia, pero los que no, es posible que se pregunten si estoy cambiando de trabajo o algo similar. La respuesta es simple, NO. Lo mejor es que leais en la página de desk-surfing de que trata este movimiento, pero os aclararé que después de esta semana volveré a AvanTIC en donde me encuentro muy a gusto :-)

¿Entonces, por qué voy a trabajar una semana a otra empresa (y sin remuneración, aparente)?

La respuesta rápida es, para aprender y mejorar. ¿Es qué no hacemos las cosas bien en AvanTIC?, sí o al menos lo intentamos, pero lo podemos hacer mucho mejor, y la única forma de mejorar más es ver que hacen otras personas, salir de tu zona de comfort y probar otras tecnologías y formas de trabajar. Al final de la semana espero haber ayudado a la gente de BeCode y llevarme muchas nuevas ideas, de las cuales algunas se puedan llevar a cabo en mi empresa, de forma que nosotros también podamos mejorar.

La principal sensación que tengo ahora mismo es de inseguridad, ¿podré aportar algo a BeCode?, ¿estaré a la altura de la situación?, se podría incluso llamar miedo :-) Pero estoy seguro que el lunes a primera hora esa sensación desaparecerá por completo para ser sustituida por una sensación de ¿vertigo?, donde estaré todo el rato aprendiendo cosas nuevas, y seguro que algo podré aportar a esta gente.

Por si alguien no lo ha captado, la palabra más importante aquí es MEJORAR y hacer las cosas BIEN :-D

P.D: Justo al terminar de escribir este post he ido a dar un paseo por el barrio del Carmen con Xavi y tan solo ese tiempo ya ha sido muy interesante y he aprendido muchas cosas, me espera una semana muy intensa.

Conferencia Agile Spain 2011

2011-10-22T22:04:00.001+01:00

Esta última semana se ha celebrado en Castellón la Conferencia Agile Spain 2011 (CAS2011). Esta será una entrada más en la larga lista de opiniones y experiencias redactadas en los blogs, pero ni la mía ni ninguna otra podrá hacer justicia a lo que es vivir en persona uno de estos eventos.

Han habido charlas para todos los gustos, o casi todos, desde charlas técnicas hasta charlas un poco más de gestión, se ha hablado de casi todos los aspectos que implica el desarrollo de software, desde el primer contacto con el cliente hasta la entrega del producto final. Y yo no voy a hacer un resumen de las charlas en las que he estado, esta vez voy a optar por intentar transmitir que es lo que siento en uno de estos eventos, para que los indecisos se animen a venir en las próximas ediciones.

Una de las cosas de las que me he dado cuenta es que existen diferentes formas o niveles de aprendizaje.

Las cosas que ya sabías, pero que necesitas comprobar que otras personas hacen de la misma manera. Esto es una cosa que ya me pasó en la QCon London 2009, entras en una conferencia y te cuentan cosas que ya tú haces de esa manera. Esto no es malo porque confirmas que vas por el buen camino y que no estas loco, hay más gente haciendo lo mismo que tú. En esta ocasión me he sentido así en charlas como la de @AlfredoCasado sobre TDD o la que hicieron @ArturoHerrero y @mgryszko sobre su experiencia y los problemas que tuvieron en el proyecto de Bkool. Destaco que en ambos casos no fueron a hablar de lo fantástico y maravilloso que es "el mundo de la abeja Maya", en ambas charlas hablaron de los fallos que ellos mismos habían cometido y de lo que hicieron para corregirlos, y esto es lo que realmente debe importar a los asistentes.
Las cosas que creías saber, pero no haces bien y es posible que necesites reconducir. Durante la CAS no he estado en ninguna sesión concreta que me haya hecho sentir de esta manera, pero a la vez me he sentido así todo el tiempo. Pese a que yo mismo me crea bastante ágil y enfocado a la satisfacción del cliente, aún me queda muchísimo camino por recorrer, y es en estos eventos donde te bajan de nuevo a la tierra, lo cual es siempre necesario.
Las cosas que no sabías. Este fue el nivel en el que me encontré la mayor parte del tiempo, obtienes un montón de información, páginas en mi Moleskine llenas de ideas que a lo mejor sí, a lo mejor no, pasan a formar parte de mis proyectos en el futuro. En este ámbito destaco la charla de @csanchez sobre DevOps, o la de @david_bonilla sobre Gamification.

Aunque todo parece muy bonito, hay una cosa negativa en todo esto, y es que a mi personalmente toda esta cantidad de aprendizaje me hace estar en un relativo estado de ansiedad. Que mal estoy haciendo tal o cual cosa, ¿cómo voy a introducir esto o aquello en mis proyectos? ... sinceramente lo mejor es que te relajes y hables con el resto de asistentes, verás que nadie es perfecto y todos tenemos algún problema y muchos aspectos que mejorar. La solución, empezar poco a poco, cuando lleves un tiempo andando el camino, descubrirás lo mucho que has mejorado.

Para acabar de convencer hablaré de la agilidad nocturna, no de ir de copas y tapas, esa es solo la excusa para estar todos juntos y hacer amigos, sino de la oportunidad de relacionarte con la gente que compone este ecosistema del desarrollo de software en España. Conoces a los CEOs de algunas buenas empresas, conoces a emprendedores con ideas geniales, conoces a jefes de proyecto que se enfrentan a los mismos problemas que tú y te dan sus soluciones, básicamente creas toda una red de contactos que en más de una ocasión pueden ser muy interesantes.

Pero lo más importante de todo, a parte de los buenos amigos que he hecho en estos eventos de Agile Spain, es que siempre vuelvo con las pilas cargadas y con muchas ganas de hacer las cosas realmente bien.

Por lo tanto, si no has venido y por mucho que leas este u otros blogs, lo único que puedes hacer para saber como es una CAS, es asistir a una CAS :-)

Retrospectivas: "An elegant solution for keeping track of reality"

2011-10-18T11:00:00.001+01:00

El otro día estaba viendo Origen por enésima vez (sí me gusta mucho mucho, ¿y qué? :-), y una de las frases del personaje de Ellen Page me hizo recapacitar.

Muchas personas habrán visto ya la película de Christopher Nolan y sabrán a lo que llaman totem en la misma. Para aquellos que no la hayan visto y resumiendo lo suficiente para no estropear la trama, un totem es un objeto trucado en el que solo su dueño conoce su "comportamiento", de esta manera utilizando dicho objeto puede comprobar fácilmente si está soñando o despierto. Por ejemplo, el protagonista tiene una peonza que es capaz de girar indefinidamente cuando está dentro de un sueño, de forma que si se para es la realidad y si sigue girando es un sueño.

Cuando a Ariadne le enseñan la utilidad de los totem, y ella misma se fabrica uno, utiliza una frase muy interesante, "an elegant solution for keeping track of reality". Pues en el desarrollo de software también tenemos un totem con esta funcionalidad, en forma de retrospectivas.

Pero en la vida real, en un proyecto, estamos trabajando no es una película, no estamos soñando, ¿o sí?. Desde luego no es un sueño, pero en un proyecto sí tenemos que disponer de "un totem" que nos permita saber si estamos haciendo las cosas bien o no, esto nos permitirá corregir el rumbo a tiempo, por seguir el símil con la película, despertarnos.

Personalmente creo que una retrospectiva tiene una serie de características comunes con un totem.

Cada persona tiene su propio totem del que conoce su comportamiento, pues cada equipo debe tener su propia forma de llevar una retrospectiva. Hay múltiples formas de hacerlo y es normal al principio copiar las prácticas de otros, pero con el tiempo se deben ir adaptando a las características específicas de cada equipo.
De nada sirve tener un totem si nunca lo utilizas, pues lo mismo aplica a las retrospectivas. Hay que utilizar retrospectivas con cierta "frecuencia" para detectar las posibles mejoras y tomar medidas adecuadas, sino será como si estuviéramos en un sueño y no siempre tiene porque acabar bien :-)
Utilizar el totem no implica que te despiertes, debes tomar tus propias medidas al respecto, igualmente el resultado de una retrospectiva debe tener una serie de acciones a tomar o simplemente será otra reunión más.

Quizás si no tienes mucha experiencia con retrospectivas te interesen los siguientes enlaces, para saber por donde empezar.

Definición de Scrum de una retrospectiva.
Retrospective starfish una forma diferente de representar la información.
Descripción de Alberto Peña de como realizaban las retrospectivas en Eden.
Web en inglés con recursos para realizar retrospectivas.

Por lo tanto, da igual la metodología, el tamaño del equipo o el tipo de proyecto, siempre puedes hacer uso de retrospectivas para saber si estás soñando o estás despierto.

No es necesario aplicar tus nuevos conocimientos al instante

2011-10-15T00:33:00.000+01:00

Tenía pensada una entrada un poco más larga sobre el ciclo de vida de Hibernate, pero al finalizar la reunión de AgileCanarias de este viernes entre caña y caña, surgió un tema muy interesante que me gustaría comentar en el blog.

Hay un comportamiento típico en la mayoría de desarrolladores (de software) que conozco, incluyéndome a mi mismo, que es la tendencia a utilizar todo lo que aprenden a la mínima oportunidad. Y esto está bien cuando no se trata de proyectos reales que están en producción. Por ahí se suele decir que si "tu única herramienta es un martillo, todos tus problemas se parecerán sospechosamente a un clavo", pues este es un caso bastante similar pero en la otra cara de la moneda. Si te compras un taladro, estarás como loco buscando donde hacer un agujero, cuando lo que necesitas es apretar un tornillo.

Voy a dar una pequeña lista de razones por las que se debe andar con mucho ojo antes de aplicar una nueva técnica, herramienta, metodología o similar.

Cuando utilizas nuevas aproximaciones que acabas de aprender, generalmente no conoces todas sus implicaciones. Siempre es mejor probar en un pequeño toy project (ver Apprenticeship Patterns) o hacer un spike, antes de usar dichas aproximaciones en "la vida real".
Como continuación del punto anterior. Las nuevas "herramientas" siempre vienen con su "manual de instrucciones", que deberíamos al menos ojear aunque hayamos visto como la utilizan otras personas, porque puede que la estemos utilizando incorrectamente.
Lo normal es buscar entre todas nuestras herramientas cual es la adecuada para hacer un trabajo, no buscar cuál es el problema adecuado para utilizar una determinada herramienta. Si lo hacemos de la segunda manera por norma general llegaremos a lo que se suele denominar sobre-ingeniería y tendremos código que al final nunca se utiliza. En el peor de los casos tendremos una solución que no es la adecuada, no escala bien o no cumple su objetivo con eficacia.

Yo creo que esto sucede porque asoma el pequeño ingeniero/científico, o como lo quieras llamar, que llevamos dentro. A veces necesitamos algo nuevo que nos llame la atención, que nos entretenga, que despierte de nuevo nuestro interés innovador. Pero por el bien de nuestro yo futuro, será mejor hacer algunas pruebas iniciales en un toy project, y pensar con la cabeza fría cuales son las mejores herramientas de las que disponemos para nuestros problemas actuales.

Si es algo que te ha pasado alguna vez, te sientes identificado, piensas que es una tontería o que simplemente este artículo es una chorrada, no dudes en dejar tus comentarios :-D

El diseño sí importa

2011-10-12T17:39:00.000+01:00

La semana pasada me fui de viaje, pero antes tenía que comprar algunos detalles que me faltaban. Decidí ir al Corte Inglés, y como siempre en la planta de perfumería habían unas cuantas dependientas entregando las clásicas muestras de perfume. Pero esta vez me sorprendió, porque en vez del típico trozo de cartulina blanca, se trataba de algo más parecido a una tarjeta de visita. Cuando termine de comprar lo que necesitaba y bajaba de nuevo a la primera planta para salir a la calle, me plantee si comprar el perfume del que me habían dado una muestra o no, al final decidí no hacerlo porque ya casi no me quedaba tiempo y no me quería arriesgar a acabar en un cola de personas en la caja. Lo raro es que llevo usando la misma colonia desde hace mucho años y nunca se me había pasado por la cabeza comprar otra, eso me hizo pensar. La chica era guapa, pero las que están otras veces también, no, eso no era. El perfume olía muy bien, pero ... no casi que tampoco es eso. Desde luego lo que me hizo plantearme comprar el perfume fue la tarjeta que usaron para pulverizarlo, un toque de clase frente a la competencia.

Frontal de la tarjeta indicando la marca y su lema

Trasera de la tarjeta indicando las características del perfume

*Nota mental*
Es muy posible que si la chica no hubiese sido atractiva ni el perfume hubiese olido bien, ni me hubiese planteado comprarlo, pero es que eso es algo que ya tienen el resto de perfumes de la competencia.

*Disclaimer*
En ningún momento este artículo pretende resultar sexista ni mucho menos, pero está totalmente demostrado empíricamente que es más rentable utilizar una chica atractiva como dependienta, tanto si el comprador es varón como si es mujer.

Y muchos os preguntareis ahora, ¿qué tiene esto que ver con el desarrollo de software?. Pues muchísimo, me acuerdo que cuando estaba en la universidad me tocó hacer unas prácticas para una empresa en una de las asignaturas, y nosotros, claro está, nos preocupábamos más de la técnica, del backend y poco o nada le dedicamos a la presentación de la web, todo sea dicho, nada sabía yo de eso en ese instante. Cuando presentamos al cliente la solución, hacía más o menos lo que quería, pero no le sorprendió ni lo más mínimo, incluso le parecía difícil de utilizar y nos lo hizo saber, mi enfado era monumental, ¿cómo no veía lo complicada que era la aplicación, y el tiempo que nos había llevado?. Sencillo, con el tiempo lo he aprendido, porque nadie sabe lo que cuestan las cosas fuera de su ámbito de competencia, pero lo que sí es totalmente cierto, es que a igualdad de condiciones la gente prefiere las soluciones que les hace la vida más fácil y que sean más agradables a la vista. Por esta razón te tienes que separar de la competencia de alguna manera y un diseño agradable e intuitivo es una de esas ventajas, pero sin descuidar la calidad de lo que no se ve claro esta. Un ejemplo, supongamos que tenemos una web en la que tenemos que mostrar tablas, muy típico en nuestro día a día. Imaginando que mostramos la misma información, ¿quién prefiere los diseños sin estilo del primer enlace y quién los diseños del segundo enlace?.

Pues la diferencia entre ambos no llega a los 15 minutos que cuesta integrar jQuery, el plugin DataTables y un poco de CSS en tu web, pero la impresión del cliente será totalmente distinta. Además en el caso del segundo enlace, no solo es una cuestión de diseño, sino que estamos dando funcionalidades añadidas, como búsqueda u ordenación casi sin esfuerzo.

¿No te viene a la cabeza ninguna empresa que haga esto en sus productos?, ¿quizás Apple, tal vez Audi o Mercedes?, ¿crees qué quien compra un Audi es por su calidad técnica y el acabo del motor, o tal vez la línea elegante y moderna tiene mucho que ver?.

Enlace a la entrada de David Bonilla sobre marketing emocional, quizás te interese leer algo si te ha gustado esta entrada.

Apache Barcamp Spain 2011

2011-10-10T12:11:00.001+01:00

Una vez que he recuperado vagamente mi ya de por si reducida capacidad de redacción, creo que puedo empezar a relatar como he vivido la Apache Barcamp Spain o más conocida entre los asistentes como #barcampes.

Viernes 7 de Octubre, Aeropuerto Tenerife Norte, España

Para mi, todo comienza el viernes por la mañana en el aeropuerto Tenerife Norte, pero ... en realidad eso no es interesante para los lectores de este blog, así que avancemos unas 10 horas en el tiempo y situémonos en la recepción del hotel Sevilla Palmeras. Allí estoy yo más solo que la una, como si de una peli de zombis se tratase, ¿habrán cambiado de punto de reunión?, pero de pronto el ascensor abre sus puertas y aparecen David Bonilla y Jero, y ese es el inicio para uno de los fines de semana más interesantes y entretenidos que un desarrollador de software de la escena española pueda tener.

Poco a poco va llegando la gente y comienzan las presentaciones, los reencuentros, se forman grupos, se empieza a hablar de los intereses de cada uno. Como siempre me pareció algo muy interesante aunque no voy a dar listas de personas, porque como me ocurre muy frecuentemente me dejaré a alguien en el tintero. Así estuvimos un buen rato, mientras Martín Pérez corria la media maraton para llegar al hotel :-)

Del hotel, un taxi directo a Plaza Nueva donde el resto de la organización y los asistentes que tenían ganas de hacer networking nocturno, así es como se llama hoy en día en este ambiente a salir de copas, esperaban. Dimos un paseo por los lugares más típicos de la noche sevillana, tomamos unas cañas, un poco de tapeo y sobretodo seguimos charlando. Esa noche tuve la oportunidad de conocer a Javier Alonso y su mujer Yolanda Sánchez, estuvimos hablando sobre como es organizar TheEvnt o los parecidos que tiene logísticamente vivir en Canarias o la exótica Extremadura :-) Más avanzada la noche, aparecieron los chicos de Extrema Sistemas, ya los conocía de otros eventos y también tuve un hueco para hablar con ellos y saber un poco de Ernesto que se nos ha ido de Tenerife a Madrid, espero que todo le vaya muy bien en este cambio.

Después de bebernos toda la cerveza y comernos todas las aceitunas del local, no tuvieron más remedio que cerrar. Bueno a lo mejor estoy exagerando y solo cerraron porque ya era un poco tarde para ellos, ¿quién sabe?. Así que tuvimos que buscar otro local abierto por la Plaza de la Alfalfa, que todo sea dicho, me sorprendió como se pone de gente, incluso de niños pequeños, aunque sea la 1 de la madrugada. De esta manera la noche continuó con un pequeño reducto de personas que si preguntas a Bonilla reducirá a Martín, su mujer Candela y él mismo porque son gallegos, pero yo estoy aquí para desmentir semejante infamia y decir que éramos algunos más :-D

Sábado 8 de Octubre, Sevilla, España

A las 9:30 estaba llegando a la ETSII de la Universidad de Sevilla, y por allí ya se notaba bastante ambiente, había mucha gente en la zona de registro. Unos cuantos saludos y más reencuentros, esta vez con Roberto y Alejandro de Autentia, y Álvaro y Fátima de Escuela de Groovy, que además eran patrocinadores del evento. El registro fue bastante rápido, y me sorprendieron dos cosas, primero que no entregaban el típico lanyard con tu nombre sino que te daban una camiseta con un hueco especial para que lo pudieses escribir tú mismo, y segundo, te entregaban ¿una carta de Pokemon?.

Como todo el mundo sabe, #barcampes eligió un sistema tipo Open Space en el que son los propios asistentes los que proponen y votan los temas que van a desarrollarse. Tras 30 segundos de exposición de cada ponente, la cosa pintaba muy difícil pero algo había que decidir, así que cogimos los post-its que no pegaban y los colocamos en el tablero-mesa señalando las 6 charlas que más nos interesaban (genial como la organización solucionó todos los problemas que iban surgiendo de la manera más ágil posible, un 10). Mientras desayunábamos cortesía de Deiser (también hubo una merienda cortesía de Escuela de Groovy), la organización reorganizó el panel y distribuyo las 18 charlas elegidas entre las 3 aulas que estaban habilitadas (dos de ellas con streaming HD - Amazing)

Como me ocurre siempre, entre las charlas que selecciono y las que al final voy, hay todo un mundo de diferencia, pero es lo normal en estos eventos porque siempre vas cambiando de opinión o simplemente la logística te impide estar en todos lados. Finalmente asistí a la siguiente lista de charlas.

Apache Droids, de Javier Puerto, en la que pudimos ver toda una serie de herramientas de Apache que nos pueden ayudar en la automatización de tareas.
Tropo de Martín Pérez, una plataforma muy interesante para añadir comunicaciones mediante teléfono, sms, twitter o mensajería instantánea a nuestras aplicaciones web.
TDD con Objective-C de Alejandro Pérez, mostró a los asistentes como configurar XCode para ir un paso más allá y poder hacer TDD con dobles de pruebas.
Prohibido monos y lagartos de Alejandro Pérez y con la aparición estelar de Roberto Canales, una vuelta de tuerca más a la necesidad de usar la cabeza y ser consecuentes con nuestro propio trabajo. Una de las pocas charlas relativamente metodológicas del evento.
Apache James de Manolo Carrasco, presento las ventajas de James como servidor de correo, y también comentó como es trabajar en un proyecto de la fundación Apache.
Play! Framework de Jerónimo López, resumió las razones por las que aparece Play! y que cosas nos aporta, en que nos puede ayudar y como usarlo.

Desde luego las charlas fueron geniales y me perdí temas muy interesantes a los que también me habría gustado asistir, como por ejemplo las charlas de Nacho Coloma sobre CSS o una charla que habían propuesto sobre desarrollo de aplicaciones móviles multiplataforma con software libre. Pero por otro lado saqué momentos muy interesantes en los descansos, me quedo con la charla sobre Scala con Roberto Canales y una lección magistral que me dio sobre pensamiento lateral.

Para "acabar" el día volvimos al salón principal para una pequeña serie de lightning talks (charlas de no más de 5 minutos). David Gómez explicó como detectar interbloqueos en Java, Germán habló sobre la importancia de valorar que nos llevamos y nos aportan estos eventos, Thorsten Scherler habló de como Apache crea comunidad y Manuel Recena habló de Clinker. Finalmente usamos la carta de Pokemon para votar la charla que más nos había gustado, y a lo tres primeros les dieron premios!!!

La noche continúa

Para algunos todo acabó cuando salieron de las instalaciones de la Universidad de Sevilla, pero otros muchos volvimos al hotel para afrontar la fiesta ofrecida por Atlassian.

En La Carbonería, un carismático local de la capital andaluza toda una tropa de pitufos, eso es lo que la gente decía que parecíamos con las camisetas del evento, se adueño de una parte del local. Comimos, bebimos y sobretodo compartimos ideas, en mi cabeza están empezando a organizarse muchas ideas, sobretodo de mis charlas con Alex y Roberto durante esa noche. Me gustó mucho compartir mesa por un rato además de Roberto, con Javier, Yolanda y Jero ... tuvimos la oportunidad de ver a la hermana mayor de Hanna Montana :-P, bebí Jagermeister con Alex, Bonilla me intentó convencer exitosamente de que usase los productos que ya usaba de Atlassian y pude seguir haciendo lobby de la idoneidad de Tenerife como localización para hacer más eventos como este.

Los asistentes aceptan hacer publicidad de AgileCanarias :-)

Tras horas y horas e intentar aguantar hasta el final, parece que Álvaro y Fátima han ganado la partida por esta vez :-), gracias al rescate de Bonilla, Candela y Jero al final me pude ir al hotel y descansar al menos tres horas, antes de volver a Tenerife.

Conclusiones

Esto solo se puede resumir en que ha sido un eventazo muy Amazing, como diría Bonilla, un 10 para toda la organización. Si yo quisiera cambiar algo para el siguiente año, sería el realizar la presentación y selección de charlas la tarde del día anterior como se hace en los Agile Open Spain, para poder disponer de más tiempo durante las charlas.

Como punto negativo destaco la gente que confirmo y al final no fue, esa es la razón por la que no se pueden realizar eventos gratis en España, la organización trabajó muy duro para que fuese gratis y esos huecos vacíos no hacen bien a nadie.

Y para acabar, el otro punto negativo es para mi mismo, por no haber presentado ningún tema. En esta parte del año me estoy acomodando un poco y he venido a la #barcampes y asistiré a las #cas_2011 sin presentar temas ... FAIL!!!

Y este fin de semana, Apache Barcamp

2011-10-05T08:08:00.000+01:00

Este fin de semana tengo un plan un poco diferente al acostumbrado, viajaré a Sevilla para asistir a la Apache Barcamp Spain 2011 (lo pone en la barra lateral del blog :-). Muchos os podeis preguntar qué demonios es este evento. La respuesta no es nada fácil, pero por resumirlo en pocas palabras, es un evento "organizado por desarrolladores para desarrolladores". Las sesiones no están programadas previamente sino que se trata de un evento tipo Open Space, utilizando la Apache Software Foundation como excusa para reunirse, enseñar, aprender, pasarlo bien, ese tipo de cosas que ocurren en los Open Spaces.

La razón principal para asistir, es sin lugar a dudas, que David Bonilla ha estado "taladrando" todo el rato con este evento y como ha prometido, y cito textualmente, "una sesión de configuración de Tomcat que hará que te crezca pelo en el pecho", no me he resistido :-D

Por otro lado hay otras muchas razones, por ejemplo algunos de los patrocinadores del evento.

Atlassian: Es interesante, porque no solo Bonilla es su embajador aquí en España, sino que suelo utilizar algunos de sus productos a diario. ¿Se hablará de algo relacionado con sus productos? no lo sé, pero allí estaré para enterarme.
Escuela de Groovy: Aunque yo no soy usuario de Groovy o Grails, es una tecnología que utilizamos en mi empresa y siempre estará bien saber que nuevas noticias nos tiene que contar Álvaro junto con el resto de su equipo.
Autentia: Increíble, estos chicos no se pierden una y dado que tienen la misma filosofía y suelen utilizar la misma pila tecnológica que nosotros, seguro que algo interesante se puede aprender. En cualquier caso siempre son un buen fichaje para la fiesta nocturna :-)

Y como siempre, es una buena oportunidad para desvirtualizar a gente que solo conoces por Twitter. Si no vas pero quieres saber que ocurre, espera a mi siguiente entrada resumen de este fin de semana ;-)

Análisis de frameworks para desarrollo en móviles

2011-09-25T13:37:00.001+01:00

A principios de semana una amiga me envió un mail con un enlace a la documentación "Getting started with Appcelerator", esto me hizo plantearme la opción de escribir una entrada en el blog comparando Phonegap con Appcelerator Titanium y con Sencha Touch.

Pero seamos realistas, ¿para qué hacer algo que ya han hecho otros y mejor de lo que lo haría yo?, por lo que reseñaré los artículos que ha escrito Alberto Vilches al respecto:

Desde luego esta no pasará a la historia por ser mi mejor entrada, ¿pero quién no quiere uns cuantos enlaces de calidad de vez en cuando? :-D

En mi experiencia personal, y después de algunas pruebas, yo me quedo con la mezcla entre Sencha Touch y Phonegap. Sencha Touch permite el desarrollo de aplicaciones multiplataforma de manera muy sencilla y elegante, resolviendo problemas que antes resolvía con JQuery Mobile, como por ejemplo las diferentes resoluciones que pueden tener los terminales Android, pero por desgracia no puede acceder a los dispositivos del terminal. Para resolver este problema podemos utilizar Phonegap en conjunto con Sencha, permitiendo el uso de los dispositivos por Javascript.

Aunque Appcelerator es una buena plataforma y tiene sus ventajas, creo que el código generado por Sencha + Phonegap es más legible y mantenible, y como la documentación es bastante buena, no veo razón para cambiar. Ahora, si tu mercado está muy enfocado a los dispositivos de la manzana, quizás te convenga echar un buen vistazo a Appcelerator Titanium.

Screencast de la kata FizzBuzz en Javascript

2011-09-24T20:52:00.002+01:00

Esta no es la entrada que tenía pensada, pero algunas personas me han pedido que haga las entradas relativas a katas mediante screencasts, por lo que dicho y hecho. He repetido la kata FizzBuzz en Javascript como prueba, ya que no domino mucho el arte de los screencasts.

En esta kata he seleccionado Javascript como lenguaje de programación y Jasmine como framework de tests. Hay que recordar que soy principiante con Javascript por lo que pueden existir detalles que se pueden implementar mejor de alguna otra manera, así que cualquier comentario será bienvenido.

En este enlace se puede descargar el código de la kata.

Aunque he intentado que todo se vea lo más claro posible, te recomiendo que veas el vídeo en HD en la propia página de Vimeo, haciendo click sobre el enlace que aparece cuando te posiciones sobre el vídeo, o incluso que descargues el fichero.

Después de este pequeño aporte al blog seguiré trabajando en una entrada sobre frameworks para desarrollo de aplicaciones ... stay tuned! como diría David Bonilla :-)

Aprendiendo Javascript: Javascript Koans

2011-09-14T12:56:00.000+01:00

En el último año (incluso últimos años) está ganando mucha importancia un lenguaje de programación que nunca ha tenido muy buena fama, me refiero a Javascript. En mi caso personal me interesa aprender Javascript porque se presenta como una solución muy interesante en el desarrollo de aplicaciones móviles multiplataforma, además de tener todo un ecosistema de frameworks, como JQuery, que permiten crear una interfaz más amigable para nuestros clientes.

La cuestión más importante es, ¿por dónde empiezo?. Está la aproximación clásica de leer libros, blogs y hacer todos los ejercicios que puedas, pero he optado por seguir previamente el camino de las koans. ¿No sabes lo que son las koans?, pues a grandes rasgos se trata de un proyecto en el que tienes que completar una serie de problemas propuestos, con pasos muy sencillos. A medida que vas avanzando, cada ejercicio te "ilumina" sobre algún aspecto importante del lenguaje. Existen koans para casi todos los lenguajes, desde Ruby hasta Scala, pasando por Clojure, Java, Groovy y muchos más.

Buscando en Google yo he encontrado los siguientes repositorios de koans para Javascript:

Me he quedado con la primera opción porque utiliza Jasmine para hacer los tests, y me gusta mucho este framework, algo más "avanzado" que QUnit y con un estilo BDD (Behaviour-Driven Development).

Estas koans son bastante cortas y en algo más de una hora puedes completarlas todas sin problemas. Si conoces otros lenguajes de programación será sencillo y te permitirá conocer las comparaciones o la herencia un poco particulares de Javascript entre otras cosas, pero ni mucho menos serás un experto cuando acabes. Me pareció curioso el uso de la librería Underscore.js, que permite añadir un tratamiento más funcional en el uso de listas y arrays.

Tras haber realizado las koans decidí utilizar la librería Underscore.js para refactorizar la kata de StringCalculator que había hecho hacía un tiempo, y aquí está el resultado.

Código final de la kata sin Underscore.js

Código tras utilizar Underscore.js y eliminar alguna función que sobraba :-P

Quien quiera ver el código más en detalle puede utilizar este enlace.

Pair Programming Illuminated

2011-09-08T19:44:00.000+01:00

Después de este "largo" mes de vacaciones blogeras, una buena forma de retomarlo es con mi opinión del último libro que he leido, Pair Programming Illuminated, de Laurie Williams y Robert Kessler.

No creo que nadie tenga dudas sobre la temática del libro, pero otra cosa muy distinta es hacerse una idea sobre la utilidad del mismo.

El libro se divide en cinco grandes bloques y cuatro apéndices:

Part 1: Gaining understanding - Se trata de una serie de capítulos introductorios que explican en que consiste el pair programming, pero no se limitan a una visión superficial. Se profundiza en todos los aspectos necesarios para entender muy bien la complejidad del pair programming, se desmitifican algunas ideas preconcebidas, y aporta algunos consejos para lograr la transición a su utilización diaria.
Part 2: Getting started with pair programming - Este bloque habla sobre la configuración del lugar de trabajo, la importancia de la comunicación y algunas cuestiones importantes a tener en cuenta antes de empezar.
Part 3: Pair programming partner picking principles - Probablemente este es el bloque que más me ha gustado, habla principalmente de los distintos tipos de parejas que nos podemos encontrar y sobre algunos problemas que pueden surgir en función del caracter de cada persona. Lo mejor de todo es que siempre aporta algunos consejos interesantes para solventar dichos problemas.
Part 4: Case studies of pair programming in software process - Personalmente este bloque no me aportó nada respecto al resto del libro, aunque por suerte es el más corto de todos. Habla sobre el uso de pair programming en XP y diferentes ambientes del desarrollo de software.
Part 5: In closing - El capítulo 27 (Seven habits of effective pair programmer) es un buen resumen a tener en cuenta en todo momento y que nos ayudará enormemente en nuestro día a día.
Apéndices: No estoy seguro que estos apéndices sean de mucha utilidad para el desarrollador de software profesional que está convencido del pair programming, pero son un buen complemento.

En conclusión, no se trata de uno de esos grandes libros que todo desarrollador tiene que leer, pero no es una mala lectura. Es un libro entretenido que se deja leer rapidamente y que aportará algo nuevo y de valor a toda persona que le dé una oportunidad.

Kata FizzBuzz: Javascript, BDD y APIs fluidas

2011-07-29T00:28:00.001+01:00

Durante el día de hoy he tenido algo de tiempo libre y he decidido hacer la Kata FizzBuzz. Algunos os preguntareis, ¿y qué es es eso de la Kata FizzBuzz?, es más ¿qué es una Kata?. ¿Eso no es algo de Karate?. Pues sí, en muchas artes marciales se practican Katas para interiorizar una serie de movimientos preestablecidos, es decir que los aprendamos de manera tan automática que salgan solos. En el desarrollo de software se puede hacer lo mismo practicando con algunos problemas sencillos, lo importante no es resolver el problema en si mismo sino interiorizar una serie de buenas prácticas mientras lo resolvemos (TDD, refactorización, etc).

La Kata FizzBuzz en concreto es un problema MUY sencillo, que se puede ver en este enlace. A grandes rasgos lo único que hay que hacer es crear una programa que dado un número se comporte de la siguiente manera.

Devuelve fizz si el número es divisible por 3.
Devuelve buzz si el número es divisible por 5.
Devuelve fizzbuzz si el número es divisible por 3 y por 5.

Hay otras variantes en las que se pide escribir un programa que te devuelva el resultado para los primeros 100 número enteros, pero nos quedaremos con lo que he explicado anteriormente, porque esa variante no añade mucho valor a lo que queremos aprender.

Para resolver el problema yo he seleccionado Javascript como lenguaje de programación, ¿por qué?, pues porque es una herramienta que cada vez tengo que utilizar más y no domino ni lo más mínimo, incluso se puede decir que no tengo ni idea de Javascript, por eso en mi caso es un lenguaje interesante para hacer una Kata. Como framework de test en Javascript he elegido Jasmine porque ya he usado Qunit anteriormente y quería utilizar una aproximación más BDD (no explicaré como funciona ni como instalarlo porque en la web ya lo hacen maravillosamente, si alguien tiene dudas por supuesto puede preguntar).

Para los que no lo sepan, BDD son las siglas de Behaviour Driven Development. Yo soy de esos desarrolladores que piensan que TDD y BDD son el mismo perro con distinto collar, solo cambia la forma en la que enuncias los test, pero en la práctica no cambia mucho los pasos que realizas (siempre depende de cada desarrollador), por no decir que no cambian nada. Jasmine es un framework BDD porque enuncia los tests como Specs, es decir que en vez de llamarse test utiliza la construcción describe-it al estilo de RSpec. Puedes comprobarlo en mi solución, que llegó a las siguientes especificaciones.


describe("FizzBuzzCalculator", function() {

 it("should return 0 with input 0", function() {
  expect(FizzBuzzCalculator.calculate(0)).toEqual(0);
 });
 
 it("should return fizz with input 3", function() {
  expect(FizzBuzzCalculator.calculate(3)).toEqual('fizz');
 });
 
 it("should return buzz with input 5", function() {
  expect(FizzBuzzCalculator.calculate(5)).toEqual('buzz');
 });
 
 it("should return fizz with input 6", function() {
  expect(FizzBuzzCalculator.calculate(6)).toEqual('fizz');
 });
 
 it("should return input when input is not divisible by 3 or 5 (2 == 2)", function() {
  expect(FizzBuzzCalculator.calculate(2)).toEqual(2);
 });
 
 it("should return buzz with input 10", function() {
  expect(FizzBuzzCalculator.calculate(10)).toEqual('buzz');
 });
 
 it("should return fizzbuzz with input 15", function() {
  expect(FizzBuzzCalculator.calculate(15)).toEqual('fizzbuzz');
 });
 
 it("should return fizzbuzz with input 30", function() {
  expect(FizzBuzzCalculator.calculate(30)).toEqual('fizzbuzz');
 });
 
});

Una de las cosas que se pueden observar con estos tests es que he intentado ir muy poco a poco, triangulando en todos los casos. ¿Qué es eso de triangular?, muy sencillo, cuando me encontraba por ejemplo con el caso "should return fizz with input 3", en la implementación hacía que devolviese 3 de forma directa, y luego creaba otro test "should return fizz with input 6" que me llevaba a "descubrir" la función isDivisibleByThree.

Si te fijas, el primer test que realicé fue la comprobación que devuelve cero ante la entrada cero, pero luego seguí por la entrada tres que debe devolver fizz. No fue hasta el cuarto test cuando me di cuenta que si el número no era divisible por 3 ni por 5 debía devolver el propio número. Hasta ese momento solo devolvía cero para todos los casos. He ahí la importancia de tener una libreta con los tests que se deben pasar y anotar todos los nuevos tests que vayan apareciendo. Yo anote dicho test y continué hasta llegar a una solución que me convencía.


FizzBuzzCalculator =  {
 
 calculate : function(input) {
  if (input == 0) return 0;
  if (isDivisibleByTrhee(input) && isDivisibleByFive(input)) return 'fizzbuzz';
  if (isDivisibleByThree(input)) return 'fizz';
  if (isDivisibleByFive(input)) return 'buzz';
  
  return input;
 }
 
 function isDivisibleByTrhee(input) {
  return input % 3 == 0;
 }
 
 function isDivisibleByFive(input) {
  return input % 5 == 0;
 }
 
}

Buscando lo que había hecho otra gente encontré un enlace al blog de Javier Acero, recomiendo la lectura porque comenta la importancia del diseño orientado a objetos y se ve como extrae las comprobaciones de la divisibilidad a otra clase. Pues claro!!! se me tenía que haber pasado a mi por la cabeza. Esos son el tipo de detalles que hay que tener en cuenta en una Kata. Se me ocurrió que era buen momento para aprender a hacer APIs fluidas en Javascript y llegue a esta nueva solución, comprobando que pasaba todos los tests que ya pasaban antes.


var number = function(val) {
 
 var operations = {
  _val: val,
  
  isDivisibleBy: function(divisor) {
   return this._val % divisor == 0;
  }
 }
 
 return operations;
}

FizzBuzzCalculator =  {
 
 calculate : function(input) {
  if (input == 0) return 0;
  if (number(input).isDivisibleBy(3) && number(input).isDivisibleBy(5)) return 'fizzbuzz';
  if (number(input).isDivisibleBy(3)) return 'fizz';
  if (number(input).isDivisibleBy(5)) return 'buzz';
  
  return input;
 }
 
}

Quizás la "clase" number no es tan clara como se espera (puede que sea por mi ignorancia en Javascript), pero desde luego de cara a los usuarios de nuestra API tener líneas como


if (number(input).isDivisibleBy(5)) return 'buzz'

es más claro que el agua :-)

Bueno no he explicado lo que es una API fluida, ¿no lo has averiguado tú solo?, pues se trata de una API en la que se componen las llamadas a los métodos de manera consecutiva, es decir llamamos a number(input) y seguidamente podemos llamar a isDivisibleBy(5) de forma que se puede leer todo junto y se entiende que se quiere comprobar que es input el que tiene que ser divisible por 5 :-D ¿Está más claro ahora? Por ejemplo en Java, JodaTime es un buen ejemplo de API fluida.


public boolean isRentalOverdue(DateTime datetimeRented) {
  Period rentalPeriod = new Period().withDays(2).withHours(12);
  return datetimeRented.plus(rentalPeriod).isBeforeNow();
}

Espero que os haya gustado y que hagáis todas las críticas (constructivas) buenas o malas que merezca :-D el debate es lo interesante.

Una TLP2K11 muy profesional

2011-07-23T19:36:00.001+01:00

Durante esta semana se ha celebrado en Tenerife la Tenerife Lan Party 2011 (TLP2K11) con su correspondiente zona profesional, pero en realidad eso ya lo sabes si has leído mi entrada anterior. Este año, todo hay que decirlo, ha sido un éxito absoluto, y me ha sorprendido enormemente la gran acogida que han tenido en especial los talleres de desarrollo. Desde Arduino hasta Android, pasando por Ruby on Rails, Grails, HTML5 y CSS3 o jQuery entre otros.

El año pasado terminaba la TLP con un sabor agridulce, por un lado la organización hizo un buen trabajo, pero por el otro no hubo respuesta por parte de los asistentes, teniendo gran cantidad de cursos con muy baja asistencia e incluso con cancelaciones por falta de asistentes. Pero este año Innova 7 no desistió y lo volvió a intentar, con un gran trabajo de publicidad y difusión en redes sociales, esta vez sí que se logró el objetivo.

No solo se recibió gran cantidad de asistentes interesados y motivados, sino que había una lista de ponentes de muy buena calidad y que todo salió a pedir de boca. La organización me ha sorprendido con un gran trabajo y no se han producido problemas notables. Algunas personas se han quejado por ejemplo porque durante 20 minutos no hubo conexión a Internet en la zona profesional por fallo de un switch. En serio tíos, no es algo reprochable porque les pasa incluso a las mejores conferencias del mundo y además esta ha sido totalmente gratuita!!!

Como colaborador (pero también ponente), mi mayor miedo era que no pudiese atender a algunas conferencias y talleres que me parecían interesantes. Por suerte el staff en la zona profesional, sobretodo Pablo e Ithaisa, lo tenían todo controlado y pude asistir sin ningún problema.

Ruby on Rails

Alberto Perdomo nos presentó un taller de Ruby on Rails de 4 horas!!! Sinceramente yo creía que la gente no iba a aguantar tanto y que era muy largo para el tipo de conferencia. Que iluso soy, fue una maravilla y este "Canarión" de pura cepa, logró entretener a su enfervorecido público. Presentó dos webs que me parecieron muy interesantes, por un lado tryruby y por otro rails for zombies. Esta última es la que utilizó para seguir el taller, pero no se limitó a seguir el tutorial y punto, explicó cada punto de forma sencilla y directa y estuvo ayudando a todo el mundo con cualquier problema que les surgía.

Alberto Perdomo preparándose para empezar

En la cena del día anterior junto con Carlos Blé, Oscar Moreno y Alberto Vilches tuve la oportunidad de conocer a este crack. Y puedo decir que me agradó y que me gusta como habla de forma directa y sin rodeos. Vamos todo un profesional de la escena Ruby y encima es canario :-)

Desarrollo de aplicaciones web con Grails

Vamos, ¿qué voy a contar de este curso? Si el ponente es Alberto Vilches (aka Mr. Grails) nada puede salir mal. En dos horas Alberto tuvo al público totalmente cautivado y les enseño desde el más básico hola mundo en Groovy, hasta los detalles más usuales del desarrollo de aplicaciones con Grails.

Desde mi experiencia, creo que se nota el rodaje que tiene Alberto con este curso, y sin lugar a dudas se está convirtiendo en un referente nacional en el mundo de Grails. Pero el chico sabe más de lo que parece, solo hablar con él un rato de temas técnicos te confirmará que tiene una gran experiencia en plataformas Java y sobre desarrollo web, y ya te digo que sabe de lo que habla.

HTML5 y CSS3 en proyectos reales

Ezequiel González de Extrema Sistemas, presentó un curso de HTML5 y CSS3. Obviamente en dos horas no puedes cubrir todas las características de esta plataforma, pero hizo un buen resumen con sus correspondientes ejercicios.

Sinceramente no pude prestar la atención que el taller merecía, pero lo que vi y por lo que pude hablar con algunos asistentes me gustó. La respuesta general fue genial y la gente me habló maravillas de Ezequiel.

JQuery

Al final del día, Pablo Betancor y yo tuvimos que coger el toro por los cuernos y hacer el taller que preparamos sobre jQuery :-) Durante 15 minutos hablamos un poco de como y porque aparece jQuery en escena, algunos de los usos más habituales y ese tipo de detalles introductorios. Pero durante los restantes 105 minutos, nos pusimos todos manos a la obra.

Pablo y yo flipando porque nuestro nombre aparecía en algo que no eran facturas :-D

Pensabamos que la mejor manera para que la gente aprendiese, era arremangándose y escribiendo código, y eso hicieron todos sin excepción :-P Ahora aprovecho para meter algunos enlaces interesantes que prometí a los asistentes y las transparencias en Slideshare.

Introducción a jQuery

View more presentations from Yeray Darias

Artículo de Alberto Vilches de introducción a Javascript.

Artículo de Carlos Benítez sobre la herencia prototípica en Javascript. El resto del blog trata muchos aspectos de Javascript y jQuery y es muy recomendable su lectura si te interesa el tema.

Página principal del plugin DataTables de jQuery.

Página de Smashing Magazine. Esta es una web sobre diseño web en general, pero hay algunos artículos sobre Javascript, jQuery o plugins jQuery indispensables.

Otros eventos

Estos no fueron los únicos eventos de la zona profesional. Al mismo tiempo que estaba en mi curso de jQuery, Agustín Hernández presentaba junto a Román Hernández un curso de Android, que por la cara de las personas que salían de la sala fue muy bien.

El día anterior Carlos Blé habló sobre el coaching y el sábado Tanausú Cerdeña, Yurena García Hevía, Yeray Callero y Jennifer Vela presentaron FeudalSquare, un juego social basado en Foursquare. No hablaré mucho al respecto porque espero que sean ellos los que lo hagan en breve.

También escuché hablar muy bien del curso de Play Framework por Axel Hernández, aunque estaba en competencia directa con el de Grails :-P

Pero aún hubieron muchísimas conferencias y talleres más, para comprobarlo no tienes más que revisar la web de la TLP2K11, pero si no fuiste, tendrás que esperar hasta el próximo año para que se repita.

Posibles mejoras para otros años

Como detalles para el próximo año, propongo solo tres cosas:

Más enchufes libres y de acceso sencillo para los asistentes que vayan con su propio portatil. Aunque me han dicho que lo intentaron este año, pero por la falta de material a veces se quitaban las regletas libres porque se necesitaban en otro lugar.
Se podría intentar grabar las charlas (quizás también los talleres) para que estén disponibles en el futuro o para asistentes que no hayan podido venir.
Una cosa que me pareció interesante en la AOS en Pamplona es tener zonas de relax con puffs o sillones más cómodos para facilitar el networking entre charlas. Quizás en el futuro se puedan crear estas zonas de esparcimiento en el área profesional.

Agradecimientos

Antes de terminar quiero agradecer a Innova 7 que me invitase como ponente, y me encantará seguir participando en ediciones futuras si ellos quieren :-) Y un saludo especial para la gente que se encargaba de la zona VIP porque hacían sentir a los ponentes como en casa, por lo menos esa fue mi sensación.

La TLP es algo más que "gamers" y manga

2011-07-12T20:22:00.002+01:00

La próxima semana se celebra en Tenerife, la Tenerife Lan Party 2011 (TLP 2K11), y me gustaría dedicar una breve entrada a la misma. Hay una idea generalizada sobre la TLP de que es un evento únicamente para "frikis" y jugadores. Yo quiero desmentir esto, porque desde hace 3 años Innova 7 está dedicando bastantes recursos a la zona profesional, lo cual no quiere decir que no se llene de "frikis" como nosotros :-P Y este año desde Agile Canarias colaboramos con ellos para intentar mejorar un poco más el espacio profesional de esta Lan Party.

Pero lo mejor que puedo hacer para que se entienda, es hacer un breve resumen de las charlas y talleres a los que me gustaría asistir, que considero especialmente interesantes para mi mercado laboral, pero que no quiere decir que no hayan otros igual de interesantes.

Diseño de aplicaciones web con Grails: El curso de Alberto Vilches es mi principal prioridad, no siempre se puede contar con una persona de esta experiencia en la isla. Tengo el placer de conocer personalmente a Alberto y te aseguro que no te decepcionará.
Introducción al desarrollo web con Ruby on Rails: El curso de Alberto Perdomo es otra de mis prioridades, desde luego en el mercado que me muevo es muy importante conocer las distintas herramientas que existen y Ruby on Rails cada vez está escuchándose más. La única pega es que coincide en horas con el de Play Framework, pero algo hay que elegir :-)
HTML5 y CSS3 en proyectos reales: Ezequiel González de Extrema Sistemas contará un poco cual es la realidad de HTML5 y CSS3 actualmente. Me parece un tema bastante interesante porque son las tecnologías más en auge para el desarrollo en plataformas móviles.
Coach XP y la influencia del agente externo para impulsar el cambio en el equipo: Esta charla de la mano de Carlos Blé promete ilustrarnos sobre como un agente externo puede acelerar el cambio en la adopción de metodologías dentro de un equipo. Muy recomendable ya que muchas empresas están cada vez más convencidas de los beneficios de contratar un coach.

Además habrán cursos y charlas sobre desarrollo en Android, el IDE de Grafcan para el uso de mapas en aplicaciones web, tecnología Microsoft y otros muchos temas más. ¿Te parece poco?, pues además Pablo Betancor y yo daremos un curso de iniciación a JQuery. Y también tendrás la oportunidad de hablar con toda la gente de Agile Canarias en la zona dedicada al grupo en la que haremos actividades y fomentaremos el networking :-)

Dicho esto, solo queda decir que ... no te lo puedes perder!!! Esperamos verte por allí.

Rework

2011-06-28T23:18:00.001+01:00

Hace poco tuve el placer de asistir a la AOS2011 en Pamplona, lo que también implica que tuve que pasar algunas horas entre aviones y aeropuertos. Aprovechando que este año me han regalado un Kindle, antes de iniciar el viaje rebusqué en mi "lista de deseos" de Amazon, y acabé comprando Rework. Todo el mundo habla muy bien de este libro y tenía muy buena crítica, así que pensé, ¿por qué no?. Además sería más suave de leer que otros muchos libros que tengo pendientes :-)

Desde luego fue una apuesta arriesgada (para mí) porque no es el libro típico que suelo leer. Este libro está un poco más enfocado a la "gestión de la empresa" de lo que suele ser habitual en mí, ese tipo de cosas más acordes a personas como David Bonilla :-P Pero en realidad fue una grata sorpresa porque desde el principio del libro se opone a una gran cantidad de estereotipos clásicos.

Nada más empezar, uno de los capítulos hace hincapié en que no es necesario crecer para formar una gran empresa. Todos tenemos la idea preconcebida de que para que una empresa gane dinero tiene que crecer, pues bien los autores de este libro te contarán como eso es falso (siempre en función de lo que tú mismo consideres qué es ganar dinero). Ohhh sí, los autores, ya se me estaba pasando ... son Jason Fried y David Heinemeier Hansson. ¿No te suenan de nada?, pues son los fundadores de 37signals, entre otras cosas que dejaré que descubras tu mismo. ¿Te siguen sin sonar de nada? pues ve a Google, navega un poco y después vuelves, no te lo voy a dar todo hecho :-) Vaya, resulta que los autores sí son empresarios de éxito por lo que sus experiencias tendrán alguna base sostenible.

Cuando crees que ya no te pueden sorprender más, aparecen capítulos en los que te enseñan como tienes que decirle "no" al cliente, no de vez en cuando sino siempre, desde el principio la primera respuesta es "no", luego se puede transformar en un "ya veremos". Parece muy radical, pero no te dejes llevar por mi breve resumen, la explicación de este tipo de pensamientos es totalmente brillante y simple. Pura lógica aplastante :-)

Al final me ha terminado gustando bastante, porque me ha enseñado que muchos de los puntos de vista que yo mismo aplico, están basados más en mi entorno socio-cultural que en prácticas o reglas que realmente funcionen. A partir de ahora tendré que ser algo más crítico y aplicar muchas de las prácticas que se comentan en el libro.

Para acabar, algunas de las partes que subrayé y que me parecieron interesantes durante la lectura.

"The real world isn't a place, it's an excuse, It's a justification for not trying. It has nothing to do with you."

"Working wihtout a plan may seem scary. But blindly following a plan that has no relationship with reality is even scarier."

"Maybe the right size for your company is five people. Maybe it's forty. Maybe it's two hundred. Or maybe it's just you and a laptop."

"Sometimes abandoning what you're working on is the right move, even if you've alredy put in a lot of effort."

"Never hire anyone to do a job until you've tried to do it yourself first. That way, you'll understand the nature of the work."

"You can't install a culture. Like a fine scotch, you've got to give it time to develop."

Esa última es una de mis favoritas, y creo que lo dejaré aquí porque sino me van a terminar acusando de plagio :-) Si no te he logrado convencer ... pues tampoco era mi intención, pero sí te diré que es un libro muy interesante y recomendable para afrontar el mundo empresarial actual.

P.D: Quiero dedicar esta entrada al gran David Bonilla y que tenga mucha suerte en su nueva aventura empresarial :-D

Toma el control de tus ficheros CSS

2011-06-25T16:07:00.000+01:00

Hace un tiempo leí un artículo de Alberto Peña acerca de Sass, una herramienta para añadir características programáticas al código CSS. Posteriormente yo mismo realicé una entrada explicando como incluir Sass en un proyecto Java haciendo uso de Ant. En el último proyecto en el que estoy trabajando he optado por una aproximación diferente y quiero contártela :-)

Less es una herramienta que te aporta características similares a Sass, solo que no es necesario compilar los ficheros en el lado del servidor, sino que se compilan mediante JavaScript en el lado del cliente (aunque haciendo uso de Node.js puede hacerlo en el lado del servidor también). Esto tiene la desventaja clara que el cliente tiene más carga de proceso, pero la ventaja para el desarrollador de poder configurarlo mucho más rápidamente y reducir el tamaño de las dependencias del proyecto (además es una solución totalmente agnóstica del lenguaje y plataforma seleccionados).

Configurar Less

Toda la información se puede encontrar en la web de Less, pero es tan sencillo como incluir las siguiente líneas en la página web que estemos construyendo.

 <link href="styles.less" rel="stylesheet/less" type="text/css"></link>  <script src="less.js" type="text/javascript"></script>

Características de Less

Uso de variables

Esta característica es muy simple pero tremendamente útil. ¿Cuántas veces has querido guardar un color o un tamaño para poder usarlo en diferentes lugares?, pues ahora puedes.


@color: #4D926F;

#header {
  color: @color;
}
h2 {
  color: @color;
}

Mixins

De manera similar al uso de variables, se pueden construir también Mixins es decir, bloques de "código" más grandes que representan una serie de propiedades CSS a utilizar dentro de otras reglas. Esta en concreto es una de mis favoritas porque estamos haciendo uso de bordes redondeados y simplifica "muy mucho" el código a leer.


.rounded-corners (@radius: 5px) {
    border-radius: @radius;
    -webkit-border-radius: @radius;
    -moz-border-radius: @radius;
}

form fieldset {
    border: 1px solid black;
    padding: 10px;
    
    .rounded-corners;
}

Realmente por no tener que escribir esas tres líneas para añadir un simple borde redondeado, merece la pena el uso de Less :-) Además, como sé que eres un lector observador, te habrás dado cuenta que los mixins están parametrizados. En este caso si no se indica nada, el valor del radio para los bordes redondeados es 5px, pero se podría instanciar con .rounded-corners(10px) y su valor sería 10px.

Reglas anidadas

No es realmente una característica que utilice muy a menudo, pero tiene su utilidad y puede simplificar un poco el código añadiendo algo de estructura al mismo.


#app-header {
    height: 70px;
    width: 1080px;
    margin: 0 auto;
    padding: 0 20px ;
    background: none repeat scroll 0 0 white;
    
    .bottom-rounded-corners(15px);
    .box-shadow(3px, 3px, 3px);
    
    div {
        float: left;
    }
    
    img.right {
        margin-top: 14px;
    }
}

Funciones y operaciones

Esta es otra característica que en mi caso no es muy utilizada, pero puedes hacer uso de operaciones matemáticas en la definición de reglas, o incluso algunas funciones propias de Less como desaturate().


@the-border: 1px;
@base-color: #111;
@red:        #842210;

#header {
  color: @base-color * 3;
  border-left: @the-border;
  border-right: @the-border * 2;
}
#footer { 
  color: @base-color + #003300;
  border-color: desaturate(@red, 10%);
}

Less.app For Max OS X

Para todos aquellos orgullosos poseedores de un ordenador de la marca de la manzana, hay una aplicación llamada adecuadamente Less :-), que permite compilar ficheros .less en .css de forma directa y mediante una interfaz agradable. Yo personalmente no la uso casi nada, pero ahí lo dejo para quien le interese.

Interfaz de usuario de Less.app for Mac

Mi experiencia en la AOS2011 (parte 2)

2011-06-22T20:13:00.002+01:00

Después de una más que merecida noche de descanso toca volver a la carga, y nada mejor para retomar fuerzas como ver el ambiente tan "a la AOS" que hay en el hotel.

Con esa pegatina, este ascensor ha de tener talento :-P

Al llegar al CEIN pasamos por la cafetería para aprovechar ese desayuno tan completo que tenían y recuperar las fuerzas, porque en breve iba a empezar el evento "de verdad". Pero antes, algo de conversación con la gente, en especial con @david_bonilla, su mujer @candelamd y el gran @jerolba, nuevas noticias que no voy a contar yo aquí porque lo hará el propio protagonista en breve (ya sabes, #lodebonilla). Tras este breve tiempo de relax cada cual va a la sala que más le interesa para empezar con la primera tanda de sesiones.

Intership

La primera sesión que he elegido es la de Intership, propuesta por @hell03610, en donde comienza comentando cual ha sido su experiencia en el intercambio que ella misma realizó con @beCodeMyFriend y con Frogtek.

Emma comenta que la primera vez que lo hizo no se lo dijo a sus jefes y compañeros, sino que se cogió una semana de vacaciones y se fue a @beCodeMyFriend por su propia cuenta. A la vuelta le contó a todos su experiencia y lo que aprendió, aunque la gente se quedó un poco extrañada. ¡Has cogido vacaciones y te has ido a currar a otra empresa! es la frase más típica (existen otras como, tú estas mal de la cabeza, es la que me dicen a mi mis amigos cuando hablo de este tema).

La segunda vez que lo hizo, habló con su jefe y ya era un poco más receptivo, por lo que yo deduzco que si haces como Emma y explicas las cosas abiertamente, "cualquier" otro jefe también lo puede llegar a entender. Ten en cuenta que si le hablas de lo que ellos mismos van a ganar con este tipo de experiencias serán aún más receptivos.

Posteriormente salieron, durante un breve periodo de tiempo, algunas cuestiones del marco legal, aunque @jorgeuriarte indicaba que no era un problema y se podía solucionar de forma muy sencilla, por lo que se continuó hablando sobre la experiencia en sí misma y algunas soluciones que se podrían adoptar para fomentar este tipo de actividad en la comunidad (si te interesa, sigue el hilo en el Google Group de AgileSpain).

Otros temas tratados:

No es realmente necesario llevar acordado el proyecto o la tecnología, puede provocar un poco de ansiedad, pero cuando comienza la experiencia y te das cuenta que con tus propias preguntas aportas valor a la otra parte, todo se lleva mejor.
@XaV1uzz indicó algo interesante. Si colocas a la gente en los lugares donde más dudas tienes, no solo te pueden dar nuevos puntos de vista, sino que sus propias preguntas pueden hacerte replantear el problema a ti mismo (como se puede observar, está relacionado con el punto anterior).
Para que el movimiento funcione debe ser totalmente transparente, en ese caso se reducen los problemas de confianza de algunas empresas.
¿Se podría crear una "marca de calidad" entorno a la red de intership? Es innegable que este tipo de actividades fomentan el compartir conocimiento, siendo esto así, también es posible que haya empresas que lo vean como un "factor de calidad".

Emma explicando su experiencia

@XaV1uzz dando su opinión

Contratos ágiles

Esta sesión facilitada por @elmendalerenda de @beCodeMyFriend fue bastante interesante, aunque es complicado sacar unas conclusiones claras. Por un lado sí quedo claro que @beCodeMyFriend no factura horas como es lo habitual en el negocio, sino que factura valor entregado al cliente, de manera similar a como lo hacía Eden en su momento (cobraba por pareja de programadores por semana). ¿Pero cómo podemos llegar a esto? fácil ... o no, con trabajo duro y ganándose la confianza del cliente.

Para empezar, algunas de las empresas presentes que facturaban de forma "ágil" a sus clientes, lo hacían dentro un contrato marco previo. Es decir que el cliente y la empresa de desarrollo firman un contrato marco en el que alcanzan ciertos compromisos, pero en dicho contrato no se especifica de forma cerrada el precio ni el tiempo del proyecto (o como máximo uno de los dos). Cada entrega (semanal, mensual, bimensual, ...) se factura por separado. Me recuerda a una idea propuesta por @chozero en una reunión de @AgileCanarias, entregar una bolsa de horas al cliente y que las vaya utilizando de acuerdo a sus necesidades. Por supuesto esto requiere de nuestra participación y dedicación porque el cliente necesitará asistencia y consejo, no podemos quedarnos sentados esperando a que las cosas ocurran por si solas.

Lo que intuyo que hace @beCodeMyFriend (y recalco lo de intuyo porque estas son mis palabras no las de ellos) es reducir los bloques de trabajo a un tamaño más fácilmente estimable, y trabajar dentro de este tamaño, cobrando por dichos bloques completados. Cuándo un bloque está completado es algo que se acuerda entre los desarrolladores y el cliente, pero como apuntaban @elmendalerenda y @XaV1uzz es necesaria la transparencia y la confianza mutua. Esto no es sencillo porque tienes que trabajar muy bien para que el cliente no pierda la confianza en ti, además @XaV1uzz apuntó algo que me gustó mucho y es que tienes que adelantarte a tu propio cliente, proponerle soluciones antes de que sepa que las necesita, que note tu preocupación por el trabajo bien hecho y por querer hacer las cosas mejor.

Por otro lado, la gran duda que me surgió a mi durante la sesión, era si alguien conocía algún caso en la administración pública de este tipo de contratos. Bueno, la respuesta general fue un poco vaga (muchas de las personas presentes no trabajaban para la administración), pero alguno empieza a existir. En estos casos es la propia administración la que ha dado dicho paso y no a partir de la propuesta de la empresa contratada.

@elmendalerenda exponiendo lo que hacen en @beCodeMyFriend

Talento

Tan solo la mención de la palabra talento sugiere muy diversas cosas para cada persona que la escucha, por lo que voy a adoptar un punto de vista distinto para el resumen de esta sesión. Iré comentando las distintas partes del contenido que quedó escrito en la pizarra al final de la misma.

@ialcazar y @rlaina orgullosos ante su propia creación :-P

Al principio de la sesión @ialcazar y @rlaina preguntaron que características se consideraban indispensables en una persona con talento, de lo que resultó:

Responsabilidad
Resolutivo
Cultura corporativa
Valor
Aptitud
Confiable
Exigencia
Ganas de aprender
Eficaz
Inconformista
Creatividad
Marcar la diferencia
Altruista

Como se puede apreciar son una serie de características muy amplias y muy centradas en la opinión de cada persona, pero dan una buena visión general de lo que se entiende por talento en un profesional. Cabe destacar que no salió en ningún momento por ejemplo la palabra inteligente ... creo que se debe a que se da por hecho, no una persona con un coeficiente intelectual de 140 sino una persona que sabe aprovechar sus propios recursos para sacar el máximo beneficio. No será la primera vez que veo a una persona con un alto coeficiente rendir menos que otra más "normal". En general se "dibujó" el perfil de una persona en la que puedes confiar, que sabe trabajar en equipo, capaz de hacerse cargo de su trabajo sin vigilancia externa, capaz de tomar decisiones equilibradas.

Esto llevo a la pregunta más obvia posible, ¿cómo se detecta el talento?. Pues hay dos opciones, mediante el método empírico usado por @ialcazar y @rlaina en la sesión de señalar con el dedo, o si llevas una camiseta de @beCodeMyFriend :-) Básicamente esto es lo mismo que decir que no existe una manera infalible, pero demostrado con tanto arte como solo estos dos chicos saben hacer :-D

Posteriormente aparecieron los métodos de "entrevistas" utilizados por algunas empresas, en concreto se habló de Tuenti y Autentia. Básicamente se trata de métodos en los que no se limitan a realizar una entrevista tipo RRHH, sino que se hacen pruebas "reales" de desarrollo. @XaV1uzz hizo un apunte sobre estos métodos en los que él no cree que detecten el talento sino los skills, esto por supuesto no tiene nada de malo, sobretodo porque muchas empresas lo que necesitan son skills y no tanto el talento (aunque es deseable).

Para detectar el talento requieres de más tiempo y diferentes pruebas, por lo que salió a la palestra el método GitHub, esta empresa realiza una "noche de cervezas" una vez al mes y un gran porcentaje de sus trabajadores han asistido al menos una vez a estas reuniones. Es comprensible, en estas reuniones sin ningún tipo de presión la gente suele comportarse con naturalidad dando lo mejor de si mismos. Es entonces cuando puedes hacerle a los candidatos el "test de tripas", es decir que te basas en ese cosquilleo interno que se produce cuando conoces a una persona que tiene talento, más comúnmente llamado intuición.

La cuestión que surge después es, ¿está el talento ya presente en tu empresa?, muchas veces esto es lo que ocurre y no hay que buscar, sino cambiar la propia empresa para fomentar el talento y mantenerlo. No hay que equivocarse, no hablamos de dinero, sino de retos, un entorno agradable, ese tipo de cosas que pueden marcar la diferencia. No puedes esperar que esa persona con talento sea fiel o le guste tu empresa porque sí, tienes que tratarlo bien y fomentar su espíritu de mejora continua. Es importante que si tienes a gente con talento la rodees de otra gente que tenga ganas de mejorar, que lo ponga en situaciones "comprometidas", que fomente el ambiente positivo, porque en otro caso se largará. Por otro lado cuando he dicho que no se trata de dinero, no me refiero a que con 1000 € brutos al mes sea suficiente sino que hay muchos casos en los que aumentar 3000 € la oferta de otra empresa no hace que dicha persona se vaya a quedar en la tuya, hay muchos factores que influyen, pero los más importantes tienen que ver con los retos, la motivación y permitir hacer bien las cosas a los trabajadores.

Lean Code

Por fin había llegado la sesión a la que tanto deseaba asistir, por su naturaleza más técnica. @plagelao utilizó el guión de Chris Parsons para enseñarnos a todos la importancia de un proceso lean y de evitar recargar nuestros procesos de desarrollo con artefactos innecesarios.

Lo que más me gustó es que nos hizo cuestionarnos a todos porque hacemos lo que hacemos al desarrollar código, y porque a veces tendemos a hacer las cosas mal cuando estamos bajo presión. Las iteraciones eran tremendamente cortas y a veces los requisitos cambiaban en medio de una iteración, pero nunca se nos ocurrió hablar con el cliente y explicarle la situación. Siempre estábamos centrados en resolver el problema, esta fue la lección que más me gustó porque en la vida real a mi me pasa muy a menudo.

Me agradó que junto a mi compañero, un chico muy simpático y eficiente llamado Pablo (@pvcarrera) completamos los requisitos solicitados, aunque algunas veces tuvimos que usar parte de la siguiente iteración para completar cosas de la anterior. Pero en ningún momento dejamos de hacer TDD!!! esto es indudablemente WIN!!! Además me reí mucho con @amaliahern, @jacegu, @chozero y @yurenaghm :-D

Dandole a la tecla tan rápido como podíamos

Aprendizaje continuo

Tras una comida que solo puedo catalogar de simple, eficiente, abundante, sabrosa y bien pensada volvimos a la carga. Si digo que me enamoré del CEIN me quedo corto :-) Esta sesión era curiosa, @plagelao simplemente estaba preocupado por la mejora y aprendizaje continuo, por lo que hizo una serie de preguntas que le preocupaban, y cuando tuvo las respuestas ... se acabo la sesión.

Conclusiones obtenidas:

Involucrar a más gente para fomentar la motivación y la auto-motivación.
Marcarse metas medibles para saber el desempeño realizado (por ejemplo número de páginas leídas por semana), pero ojo sin que eso suponga estrés o ansiedad porque sino no tiene sentido ninguno. @programania indicaba aquí que él se marcaba unas horas estrictas para aprovechar mejor el tiempo, muy en la línea de la técnica pomodoro.
Tomando como partida el punto anterior, debe ser una actividad sostenible, es decir que no nos quememos y terminemos por odiar el proceso de aprendizaje continuo.
Hay que gestionar el problema de lo que no sabes que no sabes, es decir todos esos nuevos temas que desconoces leyendo de un tema que ya de por si desconoces :-P Simplemente aceptarlo y no estresarse, es un camino largo y que no tiene fin (recomiendo leer Apprenticeship Patterns).
Enseñar y coger aprendices te obliga a aprender a ti también, puede ser una buena manera de forzarte a mejorar.

Para acabar me quedo con la frase de @mgryszko con una copa de vino en la sesión, "lo que no esta prohibido está permitido", este "polaco loco" me cae muy bien :-)

Comunidades locales

Con diferencia el tema más abstracto y que más de lleno me toca, como ya he escrito mucho y este ladrillo podría volverse infumable lo que haré es dejar la foto con las conclusiones que obtuvimos en forma de Starfish Retrospective, igualmente hay un hilo en el Google Group de AgileSpain.

Lo que si cabe destacar es que los problemas de las comunidades locales independientemente de su situación geográfica o su tamaño son compartidos, por lo que cualquier idea venga de donde venga puede ser buena.

No termino de ver la forma de Canarias :-P

Retrospectiva

Para acabar el evento se realizó una retrospectiva, de la que igualmente solo voy a colgar la foto, porque cualquier cosa que diga solo será repetir lo que indica la imagen.

Tras la retrospectiva se resolvió cuales pueden ser las sedes del AOS2012 ... y serán ... Zaragoza o Canarias :-D

Pues bien, todos los que crean que esto es así, nueva sorpresa, aquí y ahora en nombre de @AgileCanarias y después de haber hablado con mi archienemiga @tolivern :-) hemos decidido crear una alianza y apoyar totalmente a Zaragoza en la AOS2012!!! pero no os preocupéis, es solo porque ellos nos apoyarán a nosotros en la AOS2013, ¿es posible que estén "decididas" las sedes para los próximos dos AOS? espero que sí. Y además así colaboramos con otra comunidad local más, al igual que ya hemos tenido relaciones con @AgileCyL :-D

Foto de familia

Pintxos ágiles

Aunque estaba algo cansado, tras la AOS fuimos a tomar unos pintxos y no me arrepiento, aquí se crearon algunas nuevas ideas y tras la lucha encarnizada con @tolivern por el futuro AOS surgió la idea de asociarnos. En realidad es que yo ya tenía algunos planes para 2012 y organizar AOS2012 también, podía ser un poco casi que imposible.

¿Cuáles son esos planes para el futuro? ... el tiempo lo dirá ... ¿verdad @jmbeas? :-D

Conclusiones

Este AOS ha sido distinto, pero tan fantástico como el anterior en Barcelona, una inyección de energía y moral para volver a seguir trabajando lo mejor posible y mejorando día a día. He echado de menos a mucha gente que no ha venido esta vez, pero me ha alegrado desvirtualizar a otra mucha, conocer gente nueva y tener nuevos propósitos ... por ejemplo aprovechar la CAS2011 para pasar unos días con la gente de @beCodeMyFriend, me hace mucha ilusión :-) aunque me llevaré el casco listo por si @XaV1uzz intenta tirarme algo a la cabeza.

Espero que todos lo hayáis pasado y vivido tan bien como yo.

Mi experiencia en la AOS2011 (Parte 1)

2011-06-21T19:07:00.001+01:00

Muchos ya sabréis que este fin de semana, gran parte (bueno está bien, una parte de tamaño indeterminado) de la "escena agile" española ha estado desplazada en Pamplona para disfrutar del Agile Open Spain 2011. ¿No sabes lo que es un Agile Open?, puedes enterarte un poco mejor en algunos artículos que escribí sobre la AOS2010 de Barcelona :-)

Este año nos hemos desplazado desde Canarias 7 componentes del #ComandoMuyayo, ni más ni menos, aunque el primero en llegar a tierras de la Comunidad Foral de Navarra he sido yo, lo cual me ha dado mucho tiempo para hacer turismo y disfrutar de una ciudad tan agradable como es Pamplona. Aquí dejo algunas imágenes para quien las disfrute.

Actividades Pre-AOS 2011

Como novedad este año, Biko (el patrocinador oro) ha organizado dos actividades previas al AOS. Un coding dojo facilitado por @sharpbites y un evento sobre la organización ágil facilitado por @jonsetuain y @tolivern.

Aunque solo iba a asistir al coding dojo por la tarde, como pude realizar el cambio de hotel bastante temprano, decidí ir a comer con la gente al CEIN. Sorpresa, sorpresa, al llegar antes de que hubiesen acabado, me pude sentar con @epatxi para hacer la última iteración de la mañana. No creo que sorprenda a nadie que la primera iteración que realicé me pilló totalmente por sorpresa porque casi no sabía ni cual era el problema que se había propuesto. Trabajé con @epatxi haciendo algo de TDD en la implementación de un 3 en raya, aunque no creo que el pobre pudiese sacar nada interesante del tiempo que compartió conmigo, debido a que yo estaba un poco "espeso".

Tras esta iteración fuimos a comer y pude hablar con los asistentes, en especial @rubenbpv, largo y tendido sobre desarrollo de software y calidad. Me quedo con la explicación que me dio @rubenbpv sobre "la curva de los valientes".

En azul se puede apreciar la curva de los valientes, lo siento por el dibujo tan malo pero mi habilidad con la tableta es nefasta :-P

Básicamente se trata de la necesaria bajada de rendimiento al adoptar nuevas metodologías para posteriormente mejorar respecto al modelo anterior. El problema reside en que muchas empresas vuelven al modelo anterior antes de que se produzca la subida de productividad, y terminan abandonando el cambio.

Al regresar realizamos dos iteraciones más. En la primera realizamos lo que "comúnmente" se denomina "hacer TDD como si te importase". ¿De qué se trata esto? pues básicamente tienes que implementar el mismo problema, pero tienes que escribir el código que hace pasar el test en el propio método de test. Para poder escribir métodos suplementarios tiene que existir duplicación y hacerse extrayendo el código de los métodos de test ya escritos. Y para escribir clases tiene que ser en base a esos métodos suplementarios que se han escrito previamente, por lo que no se crean clases ni métodos antes de tener el código que los forma. A algunas personas les puede parecer fácil, pero no lo es, mi compañero y yo (del cual no recuerdo el nombre :-S) las pasamos p**** digo canutas, y nos sentimos un poco frustrados, pero era la sensación dominante en la sala :-) No te diré como se hace pero, en general en este caso, pensar en booleanos al principio te puede hacer las cosas más sencillas (quizás algún día haga una entrada resolviendo una kata de esta manera).

Para la última iteración del día me senté con @rubenbpv. En esta iteración no existía ningún tipo de restricción tan solo tenías que hacer "el código de tu vida", sentirte orgulloso del mismo. No llegamos realmente lejos, pero puedo decir que mimamos mucho el trabajo y pensamos de manera muy simple, por lo que estábamos orgullosos de nuestra creación. Me gustaría acabar agradeciendo a @sharpbites su trabajo y decir que fue un gran facilitador, espero que tenga mucha suerte con la creación del grupo AgileNavarra :-D

Registro y presentaciones

Tras salir de la sala en la que nos encontrábamos haciendo el coding dojo y estirar un poco las piernas, comenzaba a llegar la gente, por lo que no había ni un minuto de relax. Me encanta volver a reencontrarme con todos estos pedazo de profesionales y, en gran cantidad de casos, amigos. Tras realizar el registro fuimos entrando a la sala principal y ... en fin no hay palabras, lo mejor ver las imágenes. Que pedazo de instalaciones que tiene el CEIN, así sí da gusto organizar eventos :-D En concreto NavarraFactori es una gozada.

Salas de relax o charla

Sala naranja, ¿es qué no se nota? :-)

Para romper un poco el hielo nos agrupamos haciendo que la persona que tuviesemos a izquierda y derecha no la conocieses, para posteriormente hablar un rato con cada uno de ellos. No hubo mucho tiempo y creo que todo el mundo habló sobre cuales eran sus razones para estar allí. En mi caso hice algo de trampa, al igual que otras personas que ví ;-), porque tenía a mi derecha a @rubenbpv, pero como en realidad este era el primer día que hablábamos cara a cara le pude contar un poco que es lo que hago en mi empresa y a que me dedico "realmente".

Planificación de las charlas

Tras romper un poco el hielo y que la gente se mezclase, empezó la fase de presentar las ideas, cada persona que quisiera se colocaba en el centro y exponía el tema del que quería hablar u oír hablar. Tras la fase de presentaciones yo decidí que las charlas que más me interesaron eran las siguientes:

Lean Code (propuesta por @plagelao): Ya venía con la idea de asistir a esta charla y tenía muchas ganas de tocar algo de código también, por lo que para mi era la esencial a la que no podía faltar y que no quería que se solapase con la mia.
Rompe la rutina (propuesta por @kinisoftware)
Contratos ágiles (propuesta por @elmendalerenda)
Red de Intership (propuesta por @hell03610)
Dobles de pruebas (propuesta por @rubenbpv)
Talento (propuesta por @rlaina e @ialcazar)
Taller de retrospectivas (propuesta por @joserra_biko): Esta charla ya la habíamos realizado en el grupo local aunque me pareció interesante, finalmente preferí no asistir aunque tengo constancia que otros componentes del #ComandoMuyayo sí fueron.
No entiendo a mi programador (propuesta por @jmbeas)
Delegation Poker (propuesta por @jorgeuriarte): @yurenaghm habló maravillas de esta charla a la que al final tampoco asistí, pero le ha tocado repetirla en el grupo local en un futuro próximo :-)
Dejamos hacer las cosas bien? - Deuda técnica (propuesta por @r_corral): Es curioso porque al final no asistí a esta pero tenía muchas ganas, ya que era uno de los temas que venía pensando en el avión. Es lo que tiene un open que no puedes estar en todos lados :-P Entiendo que el nombre puede confundirse un poco pero creo que habló sobre el equilibrio necesario entre el perfeccionismo y tener entregables a tiempo.
Aprendizaje continuo (propuesta por @plagelao)
AgileUX (propuesta por @ArtziS)
Seduce a las empresas (propuesta por @rlaina y @amaliahern)

Al final no salió pero @yurenaghm quería proponer algo sobre documentación ágil, aunque el miedo escénico la paralizó un poco :-P Espero que en futuros AOS salte a la palestra, porque la gente no se imagina que pedazo de facilitadora se han perdido.

Además cabe destacar la gran idea de @kinisoftware de montar un club de lectura que se mantuvo durante la realización del evento en la sala naranja.

Como puedes ver, los temas son muy diversos y es tan solo una pequeña parte de lo que se propuso, para muestra la siguiente foto.

Panel de sesiones

Mi idea original con la libreta en la mano era asistir a lean code, contratos ágiles, red de intership, talento, taller de retrospectivas y seduce a las empresas. Para empezar iba a tener que descartar ya uno de estos porque propuse junto a @sharpbites, "Expandiendo tu comunidad local".

Es curioso como evoluciona un Agile Open porque al final acabé asistiendo a red de intership, contratos ágiles, talento, lean code, aprendizaje continuo y a la de comunidades locales, bastante aproximado a lo que quería pero con cambios ... y siendo sincero, estoy muy contento de lo sucedido aunque me hubiese gustado estar en otras sesiones también.

Mientras se organizaban las sesiones en el panel pudimos asistir a un "festival" de sabor con la muestra que nos trajo @amaliahern de @nixi_es, absolutamente recomendable, para muestra un botón. Espero que a estas chicas les vaya estupendamente porque se merecen lo mejor.

Si piensas que la originalidad de su empaquetado es lo mejor, es porque no has probado su sabor :-P

Networking nocturno

Tras un largo día lo mejor era volver al hotel, darse una ducha y salir a tomar algo con el resto de gente que "curiosamente" estaba hospedada en el mismo hotel ... debía haberse llamado AC AgileSpain y no AC Ciudad de Pamplona :-P

Estuvimos un rato en el pub irlandés en frente del hotel, pero tras un rato fuimos al centro a tomar pintxos ... en fin estando en Pamplona ¿qué vamos a hacer? Y al final esto fue lo sucedido en el primer día, tendréis que esperar a la siguiente entrada para saber que ocurrió en el segundo día durante las sesiones y en la "agilidad nocturna".

Apprenticeship Patterns

2011-05-24T19:22:00.000+01:00

En la Agile Open Spain 2010, Enrique Comba recomendó un libro titulado Apprenticeship Patterns, que está escrito por Dave H. Hoover y Adewale Oshineye. El libro habla sobre distintos aspectos con los que se encontrará una persona que empiece a recorrer el camino del Software Craftmanship, eso sí, en forma de patrones y dando muchos y muy buenos consejos para afrontar cada una de estas situaciones.

¿A quién va dirigido este libro?

El libro resultará de mucha utilidad a todas aquellas personas a las que en definitiva les gusta el desarrollo de software y quieren mejorar y aprender todos los días hasta el momento de su retiro. Aunque presta especial atención a aquellas personas que entran por primera vez en este mundo, no es un libro a descartar por personas más experimentadas o incluso aquellas que se puedan considerar expertas (te puedes llevar muchas sorpresas).

¿A quién no va dirigido este libro?

Desde luego el camino del Software Craftmanship no es el elegido por todos los profesionales del sector y no es precisamente sencillo. Si eres una persona meramente interesada en temas técnicos y crees que con eso es suficiente este libro no es para ti. Si eres de los que cree que ya lo sabe todo y que aprendiste todo lo necesario en la Universidad, es muy posible que no le prestes mucha atención a este libro y tan solo estes perdiendo el tiempo con su lectura. En definitiva no es apto para aquellas personas que no sepan afrontarlo de manera un poco humilde.

Conclusiones

A mi personalmente es un libro que me ha gustado mucho y aunque no lo pongo en mi top 5 (probablemente más habitado por libros un poco más técnicos) si que me parece muy importante. Una de las cosas que más me ha gustado es que me siento identificado en algunas de las situaciones que cuenta y los consejos son bastante útiles. Además en el futuro es muy posible que me sienta identificado en otras muchas de las situaciones que cuenta, entonces podré volver al libro para recibir consejos :-)

A medida que lo leas es posible que vayas alternando entre momentos en los que te sientes un poco más agobiado y otros en los que te relajas, para simplemente llegar al final y darte cuenta que tan solo debes afrontar tu situación y recorrer el camino que decidas. Pero eso sí, debes tener en cuenta que este camino no tiene fin, no llegarás a ningún lado, así que disfruta su recorrido porque ese es el fin en si mismo :-D

P.D: También puedes leer otra opinión del libro en el blog de Javier Acero.

Curso de TDD con Carlos Blé (día 1)

2011-05-20T22:46:00.000+01:00

Hoy ha sido el primer día del curso de TDD que estamos celebrando en AvanTIC de la mano de Carlos Blé, y escribo esta entrada para reflexionar sobre lo que hemos aprendido hoy, espero que te guste. Debo aclarar antes de que continues que no es una entrada introductoria y doy por supuesto que sabes lo que es TDD y otros conceptos de desarrollo ágil.

Introducción

Allá por el año 2009 (como si fuese una fecha muy lejana) tuve la oportunidad de hacer por primera un curso de TDD con Carlos Blé, ya había leído algo sobre el tema y había conocido a Carlos en la facultad, pero no había tenido relación con él. ¿Por qué hacer este curso por segunda vez?, pues usando las palabras de Dalton Rusell, personaje de Clive Owen en Plan Oculto, porque puedo. También puedo decir que Carlos ha mejorado mucho y aprendido muchas cosas a lo largo de estos años dando cursos, por lo que es una buena oportunidad para reforzar conceptos y revisar mi TDD :-) y no solo al lado de Carlos, sino junto a mis compañeros de AvanTIC y otra gente estupenda del grupo Agile Canarias.

Primera aproximación: Tests unitarios

Hemos empezado descargando un proyecto que tiene lo que podríamos denominar ... "un código con una calidad muy mejorable" :-) en el que Carlos nos ha pedido que hagamos una serie de tests para asegurar que no rompemos nada cuando empecemos a realizar refactorizaciones sobre el mismo. Aquellas personas que estén más interesadas en este tema pueden leer el libro de Michael Feathers, Working effectively with Legacy Code, porque lo que hemos hecho es básicamente eso, trabajar con código legado y siguiendo muchas de las recomendaciones aportadas por el señor Feathers en su libro.

Para este ejercicio compartí teclado con uno de mis compañeros de AvanTIC, Fran Olmedilla. A medida que avanzábamos Carlos hacía alguna pausa y explicaba aspectos importantes, no solo de TDD en particular, sino de programación en general. Por ejemplo nos podemos quedar con las características deseables de un test unitario y los principios SOLID.

Características de un test unitario

Deben probar una unica funcionalidad.
Deben ejecutarse muy rápido.
Deben ser inocuos, no importa cuantas veces o en que orden los ejecutes, que el resultado ha de ser siempre el mismo.

Principios SOLID

Debatiendo sobre los principios SOLID llegó la hora de la comida y un merecido descanso para todos. Pero a la vuelta Carlos se puso a los mandos y mostró que cambios se podrían aplicar al código sobre el que habíamos trabajado para que tuviese una calidad más aceptable, tras lo cual nosotros continuamos haciendo nuestros propios cambios. Esta vez a mi me tocó con Guillermo Fuentes, otro de mis compañeros en AvanTIC, y con @davioth.

Carlos dandole al teclado :-)

En esta primera parte del día no me terminé de encontrar muy cómodo, es muy posible que me cueste un poco más trabajar con código legado y sobretodo haciendo pair programming (que se me dá mucho mejor cuando es un problema nuevo o generando código que no existe), porque me es más complicado encontrar un consenso debido a los distintos puntos de vista de cada persona. Desde luego es un punto que tengo que trabajar mucho más.

Segunda aproximación: TDD

Ahora sí, va la buena, por ahora solo habíamos calentado motores. Ahora toca empezar a resolver un problema nuevo, de la nada, por supuesto usando TDD. Para la primera iteración me ha tocado compartir teclado con @titeroygatra y al poco rato ya estábamos haciendo ping-pong (yo creaba un test, y él creaba el código para pasar el test y el siguiente test que tenía que resolver yo), ahora sí me encontraba en mi salsa y todo el código surgía bastante bien. Como "problema" en esta etapa yo señalaría que elaborábamos directamente métodos privados al intentar pasar el test en vez de en la etapa de refactorización, lo cual llevó a que algunos detalles no saliesen tan limpios como esperábamos (hay que dar pasos más pequeños), pero la calidad final era buena.

El secreto fue ir poco a poco, despacito y con buena letra, cuidando los detalles. Pero todo termina y ahora me tocaba continuar con la implementación que había empezado previamente, pero esta vez con @chozero de pareja. En esta etapa quizás cabe destacar que intentamos resolver una parte del problema con expresiones regulares y finalmente la descartamos para usar una simple concatenación de .replaceAll, pues sorpresa!!! esta solución que parece tan poco elegante se entendía perfectamente y funcionaba muy bien. El resto de la implementación no causo ningún problema y pudimos terminar todos los puntos que teníamos anotados en nuestra libreta de tests.

Para acabar el día me tocó cambiar de compañero y de ordenador, por lo que continuaría una implementación que no había visto previamente. Esta vez me tocó compartir asiento con otro de mis compañeros de AvanTIC, @diyipol. Esta vez ya había un test en rojo cuando he llegado y a vueltas con un problema con expresiones regulares, Carlos nos recomendó que empezáramos de nuevo esa parte haciendo tests muy sencillos, esto nos llevo toda la iteración, pero al final teníamos una implementación que funcionaba bien y también se entendía perfectamente, para redondear además tenía en cuenta una serie de casos que en iteraciones previas yo no había tenido en cuenta.

Y hasta aquí llegó el primer día y mis pequeñas reflexiones, sé que algunas personas estaban esperando código pero tendrán que esperar un poco a que termine de ordenar mis ideas, pero que sepan que en posteriores entradas pondré soluciones que han surgido en este curso o soluciones a problemas propuestos como por ejemplo la refactorización del código del primer ejercicio, pero hecha por mi y no por Carlos.

Recomendaciones literarias: The Agile Samurai

2011-04-17T09:45:00.000+01:00

El año pasado estuve en la Agile Open Spain 2010 y tuve el placer de asistir a una charla impartida por Enrique Comba que se titulaba "Agile Inception", y trataba sobre algunas buenas prácticas que debemos llevar a cabo al empezar un nuevo proyecto. En conversaciones y blogs posteriores se empezó a hablar del tema y apareció el título de un libro, "The Agile Samurai" de Jonathan Rasmusson, que contenía algunos capítulos dedicados a este tema. Pues bien, después de 6 meses me he podido leer este libro y me gustaría dejar mi opinión aquí por si a alguien le interesa.

Contenido del libro

El libro se divide en 5 grandes bloques:

Introducing Agile: Aunque este bloque es introductorio y muchas personas ya lo conocerán, recomiendo la lectura del capítulo "Meet Your Agile Team", que trata no solo de las personas que componen el equipo sino de las características que ha de tener el mismo para que un proyecto finalice de forma satisfactoria.
Agile Project Inception: Este es el bloque que más me ha interesado y la razón principal de que comprase el libro, básicamente se centra en como realizar un "Agile Inception Deck" y aunque no me iluminó más que la charla de @ecomba me pareció una lectura muy interesante. Creo que es una lectura interesante incluso para personas que no estén totalmente convencidas de las metodologías de desarrollo ágiles.
Agile Project Planning: En este bloque se habla de historias de usuarios, estimación y planificación. Si deseas conocer algo más sobre este tema es mejor leer el libro de Mike Cohn, "Users stories applied", pero me ha parecido un resumen bastante bueno y entretenido. Muy recomendable si no tienes conocimientos previos de historias de usuarios.
Agile Project Execution: Como es lógico en la evolución lineal del libro a lo largo del proceso de desarrollo, ahora nos encontramos con la ejecución del proyecto, en general se habla sobre el proceso iterativo, las correcciones de predicciones temporales, la variabilidad del alcance del proyecto y de como o porque tomar unas decisiones u otras, durante la ejecución del mismo. Creo que no te arrepentirás de leerlo.
Creating Agile Software: Probablemente para mi esta ha sido la parte más aburrida porque como técnico es la que "más domino" (que es más bien poco :-), pero para aquellas personas más acostumbradas a un desarrollo clásico, este bloque les resumirá de forma bastante amena algunas de las principales prácticas de Extreme Programming, como por ejemplo TDD o Integración Continua.

Conclusión

Aunque no destacaría el libro como uno de esos imprescindibles al nivel de Clean Code u otros de similar fama, me ha parecido un libro muy ameno, interesante y que merece la pena leerse, sobretodo para aquellas personas que como yo están más centradas en la parte técnica del negocio y desean aprender algo más sobre el trato con el cliente o la gestión del proyecto, pero de una forma más ágil.

Reunión AgileCanarias: Historias de usuarios

2011-03-26T12:09:00.001Z

Antes de ponerme a hacer el resumen de la última reunión del grupo, me gustaría volver a hacer una aclaración que es extensible al blog, y que por mi forma de hablar, comportarme o expresarme puede no ser aparente, y creo que quedó un poco borrosa en la reunión. Cuando digo o propongo algo, es siempre una opinión personal basada en mi experiencia o en mis lecturas previas, no es ningún tipo de ley universal ni nada que se le parezca. Mi única intención tanto con las reuniones como con el blog es expresar mis experiencias para que quien quiera las pueda compartir u opinar al respecto, y no deben ni tienen porque se compartidas por todo el mundo. Venga, creo que ha quedado claro ¿no? :-D

De vuelta al tema que nos trae aquí, en la última reunión de AgileCanarias celebrada ayer viernes se habló sobre las historias de usuarios. @yurenaghm hizo de facilitadora e introdujo el tema fantásticamente, proponiendo que le resolviésemos entre todos sus dudas e inquietudes al respecto.

Introducción a las historias de usuarios

Basándonos en la experiencia previa de otros grupos ágiles del panorama español, empezamos por aclarar que son las tres C y las cualidades INVEST de una historia de usuario.

Las tres C hace referencia a las partes básicas de una historia de usuario.

Card: Indica que vamos a utilizar una tarjeta para escribir la historia de usuario. Esto no quiere decir que no se puedan utilizar sistemas electrónicos, aunque se prefiere el lápiz y el papel.
Conversation: Es una parte fundamental e indica que antes de implementar la historia habrá que mantener una conversación con el cliente para obtener los detalles.
Confirmation: Crearemos una serie de tests de aceptación que nos permitirán determinar si el cliente estará de acuerdo o no con la funcionalidad aportada. Además se requiere de la confirmación por parte del cliente para dar dicha historia por concluida.

Por otro lado el acrónimo INVEST hace referencia a las cualidades deseables en toda historia de usuario:

Independent: Las historias deben ser descritas de forma independiente unas a otras, o en otras palabras, cualquier historia debe poder ser la siguiente a implementar. Veremos que en el mundo real esto puede no ser siempre tan fácil de decir como de hacer.
Negotiable: Una historia es la promesa de que se mantendrá una conversación, pero no es un contrato vinculante.
Valuable (to the customer): Toda historia debe tener valor para el cliente evitando las historias técnicas, como bien indicó @carlosble en la reunión. Esto es importante porque yo tiendo a mezclar un poco tareas con historias de usuarios, aunque modifique el texto para que no lo parezca sigue siendo una tarea técnica y eso no es deseable.
Estimable: Es simple, una historia debe poder ser estimada con cierta facilidad, pero es un concepto abstracto, por eso se recomienda que las historias sean pequeñas facilitando la característica de que sea estimable.
Small: En este punto yo me voy a quedar con la opción de que la historia debe ser lo suficientemente pequeña para entrar en una iteración, de esta forma se evita un poco la discusión de ¿cuánto es pequeña?.
Testable: Es obvio, debe existir una regla, parámetro, test ... como quieras llamarlo, que permita saber cuando una historia está completa.

Historias de usuarios VS Casos de uso

Una vez finalizada la introducción, @chozero realizó una pregunta que genero un buen debate acerca de las historias de usuario y los casos de uso, a grandes rasgos aparecen las siguientes conclusiones:

Un caso de uso puede almacenar información acerca de un cliente que la historia de usuario no, tampoco es para lo que se quiere una historia de usuario.
Una historia de usuario fuerza una conversación con el cliente, mientras que el caso de uso es una análisis que una vez finalizado rara vez se modifica.
Un caso de uso no puede ser testeado como una historia de usuario.

¿Significa que uno es mejor que otro?, no. Son herramientas distintas y útiles en función de como las utilices. Yo personalmente defiendo los casos de uso solo cuando pertenecen a una documentación viva que evoluciona con el proyecto hasta su finalización, y no cuando se usan al estilo waterfall para definir lo que hay que construir sin posibilidad de cambio.

Creo que otra conclusión pudo ser que waterfall le ha hecho mucho daño a los casos de uso :-)

NOTA: En este punto @pgonyan recomendó "Writting effective use cases" de Alistair Cockburn como una lectura interesante.

Caso práctico

Para entrar en materia yo empecé haciendo de cliente, pero surgió una cuestión interesante, mi sistema que era un sustituto de Jira se prestaba mucho a cosas como, "Jira ya te resuelve ese problema". Eso es correcto, si ya existe algo que hace dicha tarea, ¿para qué reinventar la rueda?. Esto ocurre porque probablemente, antes de entrar a saco con historias de usuario debíamos haber realizado un Agile Inception Deck, de manera que debates como este no tendrían lugar en este punto, porque ya habría quedado claro si el cliente necesita de verdad el producto o no.

Después de intentar reorientar el tema, @chozero hizo de cliente y la cosa empezó a marchar un poco mejor. Después de estar debatiendo largo y tendido y que saliesen algunas historias de usuario ... lamento decirlo pero se acabó el tiempo :-S

Salieron algunas historias y se habló un poco de como priorizarlas y estimarlas, pero muy por encima. Creo que es un tema que requiere mucho tiempo y como ya propuso José Manuel Beas, en el post que referencio anteriormente, sería una idea estupenda hacer un User Stories Retreat :-) te apoyo totalmente en esta idea tío!!! (nota mental: ¿sería interesante una sesión de User Stories Dojo en la AOS2011?)

Y con esto y un bizcocho hasta la próxima reunión que tratará sobre: ¿Cómo medir la calidad del código? .. pedazo de ladrillaco les voy a soltar a los que acudan a esa :-D

Recomendaciones literarias: User Stories Applied

2011-03-19T17:29:00.002Z

En la última reunión de Agile Canarias se acordó que en la próxima cita el tema a tratar serían "Historias de usuario", por lo que ninguna excusa mejor para leerme por fin "User Stories Applied" de Mike Cohn. Ya lo había visto en la librería de la oficina y había leído los primeros capítulos, pero esta vez he decidido leerlo de cabo a rabo :-)

Se trata de un libro bastante corto en relación a otros muchos (poco más de 250 páginas), lo cual lo hace un poco caro en su relación páginas/precio, pero no os dejéis engañar, vale cada uno de los dólares que cuesta.

El libro se divide en 4 bloques fundamentales que paso a detallar a continuación.

Part 1: Getting started

Como su propio nombre indica es una especie de introducción al mundo de las historias de usuarios y esta formada por 7 capítulos en donde se habla principalmente de qué es una historia de usuario y como se escriben buenas historias de usuario. Se habla de forma bastante clara sobre las personas implicadas en el proceso y se dan muy buenos consejos sobre como obtener las historias.

Los dos primeros capítulos nos ponen en situación, pero para mi los más interesantes han sido los tres siguientes.

User role modeling: Este capítulo resalta la importancia de conocer los usuarios implicados en el sistema a construir y da algunos buenos consejos sobre como organizar las historias de usuarios entorno a ellos.
Gathering stories: Aquí el autor cuenta algunas técnicas y actividades para obtener historias de usuarios junto con el cliente, lo cual no es siempre tan sencillo como parece.
Working with user proxies: Como todos sabemos, no siempre es posible contar con acceso directo a los usuario o clientes, por lo que se hace indispensable utilizar "proxies" de los mismos. En este capítulo se señalan bastantes detalles que debemos tener en cuenta cuando trabajemos con personas que hacen de enlace del usuario final.

Part 2: Estimating and planning

Ninguna sorpresa, este bloque habla sobre la estimación de historias y del proyecto en general. Es muy entretenida y aunque en parte es algo que ya hacíamos de manera similar en la oficina, he podido anotar muchas ideas para intentar poner en práctica. Me ha gustado que el autor se moja e indica como obtener planificaciones a largo plazo que en el mundo real son indispensables y que otros autores no comentan o incluso evitan.

Part 3: Frenquently discussed topics

Nada nuevo bajo el Sol, se profundiza un poco más en el tema de las historias de usuario, pero destaco el capítulo 14 (A catalog of story smells) en donde se comentan una serie de consejos a tener en cuenta para intentar saber si algo va mal con nuestras historias.

Part 4: An example

A lo largo de 5 capítulos el señor Cohn pone en práctica lo explicado en los tres bloques anteriores. No me dio la impresión de necesitar un ejemplo práctico porque la verdad es que el libro es bastante claro. Pero como se lee bastante rápido y es ameno, conviene leer este bloque también en donde se puede sacar alguna idea más o corregir algún detalle que se puede haber interpretado erróneamente.

Conclusión

Básicamente, para mi, es un 5/5, uno más entre esos libros indispensables para el desarrollador preocupado por hacer las cosas bien.

¿Cómo hacer uso de SASS en proyectos Java?

2011-03-12T22:40:00.000Z

El otro día leí un artículo de Alberto Peña en su blog, hablaba sobre las bondades de SASS cuando se trabaja con CSS, y me gustó mucho. Si quieres saber lo que es SASS lo mejor es que leas el artículo de Alberto o accedas a la página oficial, pero para saber lo que me ha llevado a escribir esta entrada, baste decir que es una herramienta hecha en Ruby. Vaya hombre, resulta que todos los proyectos que tenemos en mi empresa son en Java y SASS está hecho en Ruby.

¿Cómo hago si quiero hacer uso de SASS y no puedo dejar de usar Java?

La solución más sencilla que he encontrado es la utilización de JRuby en un script Ant para compilar los ficheros de SASS en CSS. Muchos pensaréis que también es posible crear un script Ruby directamente en el Ant, pero he preferido la opción de incluir la librería de JRuby en mi proyecto, porque es algo que puedo controlar, pero no puedo controlar que mi cliente o el servidor de integración dispongan de Ruby instalado.

Por lo tanto los pasos a seguir son:

Descargar la última versión completa de JRuby y copiar el jar correspondiente en la carpeta de librerías de tú proyecto, en mi caso concreto libs.
Descargar la última versión del módulo HAML para Ruby y copiarlo en una carpeta del proyecto, como en el caso del ejemplo yo he preferido la carpeta de librerías (libs) como destino de este módulo.
En esta captura se puede visualizar la estructura de ficheros utilizada para el script Ant

Crear el script Ant. Suponiendo que ya estas usando Ant para la construcción de tu proyecto, puedes introducir el target compileSASS en tu script de construcción, si no es el caso y no tienes ninguna herramienta de construcción puedes empezar a usar Ant (quiero decir empieza a usar una herramienta de construcción automática YA). Incluso en el caso de que tu proyecto no sea Java podrías hacer uso del script que se muestra debajo para poder utilizar SASS aunque no uses Ruby.


<project>    
    <property name="dir.sass" value="web/styles/sass" />
    <property name="dir.css" value="web/styles/css" />
    
    <path id="JRuby">
        <fileset file="libs/jruby-complete-1.5.6.jar"/> 
    </path>  

    <target name="compileSASS">
        <echo message="Compiling SASS files..." />
    
        <property name="sass" value="${dir.sass}/**/[^_]*.sass" />
        <property name="sass.build" value="${dir.css}" />
    
        <script language="ruby" classpathref="JRuby">
            <![CDATA[
                require 'libs/haml/lib/haml'
                require 'haml/exec'

                files = Dir.glob($project.getProperty('sass'))
                Dir.mkdir($project.getProperty('sass.build')) unless File.exists?($project.getProperty('sass.build'))
                files.each do 
                    | file |
                    opts = Haml::Exec::Sass.new([file, File.join($project.getProperty('sass.build'), File.basename(file, ".*") + ".css")])
                    opts.parse
                end
            ]]>
        </script>
    
        <echo message="Done compiling SASS files!" />
    </target>
    
    <target name="compile" depends="compileSASS">
    </target>
</project>

Pero si yo no uso Ant, yo prefiero Maven!!!

Para las personas que se encuentren en esta situación y no lo sepan, se puede ejecutar Ant desde Maven, por lo que no habría ningún problema, sino que basta con lanzar el script deseado de Ant en el punto del ciclo de vida de Maven adecuado. Por ejemplo en este caso queremos que se conviertan los ficheros de SASS en CSS cuando se está compilando los fuentes de la aplicación.

Reunión AgileCanarias: ¿Cómo hacer retrospectivas?

2011-03-02T20:18:00.000Z

El viernes pasado nos reunimos en el grupo #AgileCanarias para hablar sobre retrospectivas, y aquí viene el resumen de lo que en ella ocurrió.

La noticia más importante de la reunión es que tuvimos el placer de contar con la inestimable visita de @amaliahern y @semurat, que se encontraban en la isla para participar en el Carlos Blé Tour 2011, y le dieron un toque especial a la misma.

Empezamos por una breve introducción de lo que entendemos por retrospectiva, y luego nos pusimos manos a la obra haciendo la retrospectiva de lo que ha ocurrido en la escena ágil española durante el año pasado. ¿Quién ha dicho que solo se pueden hacer retrospectivas de proyectos de software?. Como guía para los pasos a seguir en la retrospectiva utilizamos el siguiente artículo de @plagelao, en él se cuenta como es una retrospectiva en Eden Development y además es muy ameno de leer.

Poniéndonos en situación

Nos sentamos todos alrededor de una mesa y empezamos a sugerir eventos que considerábamos importantes para el movimiento ágil en nuestro país, o que han afectado al mismo, o simplemente que nos han afectado a nosotros mismos en nuestra propia visión de "ágil", por ejemplo "Realización de la AOS 2010", o cuestiones más personales como "Empezamos a aplicar Scrum en nuestra empresa". No pusimos ninguna clase de limitación, sino que la gente iba haciendo memoria y seleccionaba lo primero que le venía a la cabeza, para hacernos una imagen global de todo lo que ha ocurrido. Cada persona comentaba el evento y como se sentía al respecto, luego lo escribía en un post-it y se pegaba en una línea temporal. A veces la gente hacía un comentario o recordaba algo relativo a la última idea comentada, pero en ningún caso se hacían críticas o similares.

Esta es la línea temporal que nos quedó a nosotros

Con este "juego" se logra que todos recordemos lo que ha sucedido, para luego hacer una línea de sentimiento. Esta cuestión de la línea de sentimiento lo he leído en algún post o libro tras ver el artículo de @plagelao, y nunca se me había ocurrido, pero es una buena idea. Desde mi punto de vista esto puede servir para hacerse una idea del estado general del proyecto. Si todo el mundo se siente bien la cosa va bien, si todos se sienten mal es que hay algo que cambiar :-)

A este respecto @semurat comentó algo muy interesante, como es utilizar tarjetas de distintos colores según si es un evento "bueno" o "malo", de alguna manera es algo quizás más visual que la línea de sentimiento o en todo caso algo complementario a la misma.

Idea de @semurat

En este caso solo participamos en la línea de sentimiento @chozero, @fran_reyes, @ehdez73, @semurat y yo mismo, pero se pudo extraer una lectura muy interesante, la participación en los eventos como AOS 2010 o SpringIO 2011 nos hacía sentir bien. ¿Se puede sacar una conclusión de esto?, lo veremos más adelante.

Relajandonos un rato

Tras 35 minutos cortamos durante 10 minutos para probar algunas tostadas con almogrote :-) y que la gente se relajase. Esto es esencial para que el ambiente continúe de forma distendida y los participantes no se agobien. Pero 10 o tal vez fueron 15 minutos más tarde nos pusimos de nuevo manos a la obra durante otros 35 minutos.

Extrayendo conclusiones

Como en toda buena retrospectiva había que salir con algunas conclusiones y un plan de actuación para mejorar en el futuro. Para hacer esto decidimos introducir una nueva herramienta que se puede leer en el siguiente artículo, denominada retrospective starfish. Es una hoja de papel (o más bien varias) que se divide en 5 espacios en los que aparecerán las siguientes zonas:

Keeping doing: Son las cosas que creemos que deberíamos seguir haciendo.
More of: Son aquellas cosas que aunque se hacen creemos que se deberían hacer un poco más.
Start doing: Son las cosas que aún no se hacen pero se deben empezar a hacer.
Stop doing: Son cosas que debemos dejar de hacer.
Less of: Son cosas que hacemos pero que deberíamos hacer un poco menos.

No estoy seguro de si es necesario tener una posición especial para cada zona pero decidimos mantener el diagrama tal cual aparece en el artículo reseñado. Pero bueno más vale una imagen que mil palabras.

Conclusiones de la retrospectiva en la Retrospective Starfish

Mientras creábamos las conclusiones a diferencia del paso anterior sí había algo de discusión, pero no debe nunca sobrepasar cierto nivel. Nosotros empezamos a desorganizarnos un poco y @amaliahern enseguida decidió introducir la idea de levantar la mano creando un efecto dominó como en la AOS 2010. La idea funcionó a la perfección y al final tuvimos un montón de conclusiones que podemos aplicar en el futuro. Como respuesta a la pregunta que quedó antes en el aire sobre que nos sintiésemos bien en los mismos momentos que se celebran grandes eventos de AgileSpain, debemos hacer más eventos de este tipo a niveles más locales :-)

Para concluir un pequeño grupo de los asistentes nos fuimos a cenar con @amaliahern y @semurat para agradecerles su colaboración y que también tuviesen un momento de relax en su viaje. De parte de todos os deseamos lo mejor chicos :-D

Y por ahora esto es todo amigos.

SpringIO Día 2

2011-02-27T09:15:00.000Z

Tras un primer día de conferencias que fue bastante largo pero muy entretenido, nos levantamos llenos de energía para el segundo y último día. Mientras Tino y yo desayunamos en una cafetería cercana al hotel recibimos un SMS de @chozero y @yurenaghm, se iban a retrasar un poco :-), por lo que dimos un paseo por los aledaños del hotel haciendo tiempo. Una vez en el coche, esta vez el trayecto fue directo, pero nos pasamos la entrada!!! y bueno se nos hizo un pelín tarde.

Sin ningún contratiempo más, llegamos a la CEU San Pablo y nos dio tiempo de entrar a la mitad de la charla de Graeme Rocher sobre Grails. Sinceramente no me termine de enterar bien de que iba, pero tuve la oportunidad de ver Spring Insight en funcionamiento y puedo decir que es una herramienta fantástica para la monitorización de tu aplicación web, cuando haga una prueba crearé una entrada en el blog (vaya, se me van acumulando las entradas). Tome notas de lo que pude entender y me quedé impresionado por el Spanglish de Graeme, todo un esfuerzo por parte de este ponente.

Aplicaciones Web ultraescalables con Redis de Alberto Gimeno

La siguiente elección en mi día de charlas fue la de @gimenete que trataba sobre Redis. Nada más entrar en la sala nos quedamos impresionados porque casi no había sitio, la sensación general de la gente en Twitter era "@gimenete lo ha petado en la charla de Redis" :-)

No tenía ni idea de la existencia de esta base de datos NoSQL, pero como en la empresa ya habíamos probado con CouchDB, tenía ganas de ver la experiencia de otras personas con otras soluciones distintas.

Redis es un producto de VMWare y propone como novedades o ventajas respecto a otras bases de datos NoSQL un promedio de 100000 operaciones por segundo!!!, sí sí habéis escuchado bien 100000, y también transaccionalidad que es una característica que no se encuentra en las demás soluciones NoSQL. Pues vaya sí que se está poniendo interesante el tema, pero no solo porque el producto merece la pena y será otra entrada en el blog :-), sino porque @gimenete es un presentador fantástico y muy ameno.

Otros temas interesantes que se tocaron en esta charla, fueron las herramientas para trabajar con Redis y hacer los mapeos de forma más sencilla (como por ejemplo Spring Data) o cual es la razón de ser de las BBDD NoSQL, principalmente la escalabilidad aunque yo también destaco que son una buena solución cuando hay cierta incertidumbre alrededor de la aplicación y no se sabe muy bien lo que se desea.

A raíz de una pregunta del público apareció el tema del rendimiento de lectura o escritura, y pudimos ver una prueba en directo en el ordenador de @gimenete que indicaba que Redis era incluso más rápido en escritura que en lectura.

Un fortísimo aplauso para @gimenete y buscamos nuestro camino a la siguiente sesión en mi caso probe con el taller de @fatimacasau

Testing en Grails y pruebas funcionales con Geb (Webdriver) de Fatima Casaú

Aunque no tenía mucha idea de Grails, y tampoco es que la tenga ahora, me interesaba ver como se realizaban las pruebas funcionales con Webdriver y como trabajaba otra gente en este aspecto, porque seguro que algo podría sacar para mi provecho :-)

Al principio todo fueron problemas, me había fiado de la instalación que tenía de STS en mi máquina, pero no tenía los plugins de Grails, y la versión de Grails en mi ordenador era mucho más que vieja. Nota mental: acuérdate de preguntar los requisitos y llevarlo todo instalado. Tiramos de la red del centro pero parece que no iba muy bien, bueno lo deje descargando y me puse con el compañero que tenía al lado que para mi suerte era ni más ni menos que @dani_latorre, así aprendería por partida doble.

@fatimacasau tenía un proyecto preparado con una serie de ejemplos, lo cual ayudo mucho a entender mejor como se hacen las pruebas con Webdriver, y demostró el buen hacer de esta chica.

Para muestra un botón. En el siguiente código se puede ver como se hace un test con Webdriver haciendo uso de Geb. Más sencillo imposible.

class AddCommentSpec extends GebSpec {
        
        def browser = new Browser(new FirefoxDriver(), "http://localhost:8080",ShowPublishPostPage)
        
        def "se muestra el ultimo post insertado"() {
            browser.to(ShowPublishPostPage)
            assert browser.page instanceof ShowPublishPostPage
            assert browser.page.$("p", id: "subtitle" ,text: startsWith("Creado por")).size() == 1
            assert browser.page.$("p", id: "subtitle" ,text: contains(Post.lastPostPublished().authorFullName())).size() == 1
            
        }
        
        ...
        
}

Como vemos, haciendo uso del framework Geb podemos hacer pruebas funcionales con mucha facilidad, tan solo hay que darle la URL de acceso y luego hacer los asserts que consideremos necesarios. Como comenté en la entrada anterior tras la charla de Webdriver, yo no lo veo útil para hacer pruebas muy intensivas probando todos los detalles de la vista, pero me gusta para comprobar que existen los elementos indispensables.

Por lo que pude hablar con @dani_latorre, parece que se puede usar Geb perfectamente en proyectos Java por lo que puedo decir que este taller fue muy interesante porque no aprendí solo cosas de Grails sino cosas que voy a poder usar todos los días. Salí muy contento de la charla y he de decir que @fatimacasau es la demostración empírica de que la belleza no está reñida con la inteligencia :-)

Ahora tocaba irse a comer un rato, unos sandwiches y algo de fruta claro, para lo que me reuní con el resto del #comandomuyayo y fuimos a buscar la comida. Mientras buscamos un sitio en el que comer tranquilamente nos encontramos con @mgryszko y tuvimos la oportunidad de pensar en un montón de ideas para la próxima edición del concurso AbreDatos, una comida muy interesante.

Taller de creación de DSLs con Groovy de Alberto Vilches

En este taller aprendí bastante aunque para ello tendría que mostrar todo el código que hicimos y eso me llevaría toda una nueva entrada y no de las pequeñas precisamente :-)

@albertovilches introdujo a la audiencia a las características principalmente de Groovy para crear DSLs, como por ejemplo los closures, es un tema complicado pero @albertovilches supo salir muy bien adelante y continuamos con los ejercicios, eran muchos y no dio tiempo a hacerlos todos pero creo que la idea principal quedo bien reflejada.

Mi más sincera felicitación para este chico que según @DavidBonilla es el mejor programador del mundo :-)

¿Configurar con Spring un API no basado en Spring?

Tras el taller de @albertovilches tocaba un descanso y fui a hablar con mis amigos de Autentia con quienes pude conocer a algunas personas más del equipo de desarrollo de esta empresa. Y puedo decir que la charla fue tan interesante que hablando con @alejandropgarci y José se me paso la charla sobre Spring a la que iba a asistir :-)

Tras más de una hora el #comandomuyayo se personó en la cafetería con cara de dónde te habías metido??? a lo cual solo puedo disculparme y presentarles a la gente de Autentia, pero no me arrepiento porque pude compartir un buen momento con @alejandropgarci y José y aprender cosas pese a que la gente no lo crea.

Networking nocturno :-D

Tras despedirnos de @alejandropgarci y José nos volvemos a la ciudad para dejar las cosas en el hotel y ... sí reunirnos con la gente para algo de networking nocturno. Íbamos un poco tarde por lo que recibí la llamada de @dani_latorre pero ya estábamos a punto de llegar, así que nos esperaron en la parada de metro y luego fuimos a comer. En la mesa había un selecto grupo con el que compartimos la experiencia como @dani_latorre, @gimenete, @ialcazar, @eamodeorubio, @jmbeas, @jerolba, @antoniofdr y algunas personas de las que no me acuerdo del nombre o no tengo su twitter. En definitiva una cena fantástica y luego un buen rato en una cervecería en donde tuve el placer de compartir algunas ideas y planes para el futuro con @jmbeas y @jerolba, esto parece que marcha!!!

Y esta vez sí ... eché de menos a @DavidBonilla (ver comentarios de la entrada anterior :-)

El grupo de networking nocturno, faltan @eamodeorubio y @yurenaghm en la foto

El #comandomuyayo destronando a @dani_latorre de su puesto de agilista nocturno :-)

Conclusiones

Tras estos dos días de Spring, Grails, talleres y compartir experiencias con otros desarrolladores de España me quedo con varias conclusiones.

Un 10 para la organización, todo ha salido fantásticamente bien aunque ya esté un poco harto de sandwiches de paquete :-)
Los ponentes españoles no tienen nada que envidiar a los grandes gurús del panorama.
El sector va cambiando poco a poco y cada vez son más las personas que asisten a estos eventos.

Un saludo y nos vemos en la próxima.

SpringIO Día 1

2011-02-26T10:44:00.001Z

Hace ya tiempo que no escribo nada en el blog y estoy incumpliendo uno de mis propósitos para este año, escribir un mayor número de entradas. Pues nada mejor que contar mi experiencia en el pasado SpringIO para recuperar la costumbre.

He tenido la suerte de que mi empresa (AvanTIC Estudio de Ingenieros, toma cuña publicitaria :-) me haya invitado a asistir a esta conferencia celebrada en Madrid durante los días 17 y 18 de Febrero, y por supuesto la suerte de compartir esa estancia con muy buenos amigos, entre otros la nueva alineación del #comandomuyayo. En esta expedición repite Fran y se suman como nuevas incorporaciones Tana, Yuyu y Tino (mi compañero de empresa).

El jueves por la mañana nos pasan a recoger Tana y Yuyu en coche, y con tres GPS y tres copilotos distintos, iniciamos nuestro viaje hacia la CEU San Pablo en Boadilla del Monte. Ante tal despliegue de tecnología y diversidad de opiniones no podía suceder otra cosa que llegar más tarde de la hora prevista, pero llegamos a tiempo que es lo que cuenta y nos unimos a la MUY larga cola de registro al evento. Nos hemos enterado que se han inscrito 350 personas!!! Una cifra record para un evento de este tipo en España y que espero que siente precedentes.

Mientras esperamos nuestro turno tranquilamente van apareciendo personas conocidas a las que vamos saludando y que no detallaré aquí porque seguro que se me olvida alguien, pero ya hablaré de ellos más adelante. Por fin llegamos a la mesa de registro y conseguimos nuestra acreditación, ya estamos listos para asistir a la primera charla del día.

Spring in 2011 and beyond de Jürgen Höller

Tras una breve presentación por parte de Sergi Almar, Jügen Höller pasa a contarnos el futuro de Spring, y he de decir que pinta bastante bien. ¿Cuáles fueron los puntos que me parecieron más interesantes?, os lo contaré.

Perfiles de entorno: Para los equipos que desarrollen principalmente en plataformas Tomcat como es mi caso, pueden estar tranquilos porque se seguirá dando total soporte a la misma en la versión 7. Pero mediante el uso de un indicador de perfil, Spring intentará que la misma aplicación se pueda desplegar tanto en un Tomcat de lo más normalito como en la nube o cualquier otro tipo de plataforma. Para ello lo único que se requerirá es la creación de los applicationContext correspondientes.
Tendencia a aplicaciones request-response: Según este gurú de SpringSource, las aplicación tipo JSF están llegando a su desaparición y la tendencia actual son aplicaciones tipo REST, para lo que Spring intentará dar el máximo soporte posible. Aunque desde mi punto de vista y mi experiencia hasta ahora la capacidad de crear servicios REST en Spring ya es muy buena.
Integración con la capacidad de programación concurrente de Java 7: Una de las mayores novedades en Java 7 será una mejor utilización de los recursos multicore y Spring prevé dar soporte a los desarrolladores para que puedan usar esta característica de la forma más sencilla posible.

Ya cuando todos estábamos que se nos caía la baba vino el jarro de agua fría, por lo menos para mi, tendremos que esperar hasta Junio de 2011 a la versión de producción, pero para aquellos osados que están dispuestos a probarlo todo, ya está disponible la versión de pruebas.

TBD, Escuela de Groovy Álvaro Sánchez-Mariscal

Tras la presentación de Spring, Álvaro Sánchez nos informo de los planes de Escuela de Groovy para el futuro. Esta gente se está posicionando muy bien, y actualmente es muy posible que sean unos de los equipos de profesionales más preparados para ayudar a cualquier empresa de desarrollo a adquirir los conocimientos necesarios en tecnologías Groovy/Grails, y alcanzar el éxito.

Groovy Koans de Daniel Latorre

Tras las charlas generales tocaba el momento de tomar decisiones y yo opte por acudir al taller de Dani Latorre sobre Groovy Koans, más que nada porque nunca he trabajado con Groovy y es un lenguaje que me parece muy interesante. No hay mucho que contar acerca de este taller, nos pusimos a hacer las koans, pero con la ayuda del gran gurú de Groovy Dani Latorre :-D

A estas horas ya el hambre empezaba a apretar y menudo susto nos llevamos Tino y yo, cuando miramos el reloj de nuestros portatiles indicaba que faltaba aún una hora y media!!! pues no, es que no habíamos cambiado la hora y teníamos una hora menos :-)

Tras este interesante taller que compartimos con gente como Amalia Hernández o Jesús Ballano, nos fuimos a comer con el resto del #comandomuyayo y tuvimos el placer de compartir almuerzo con la siempre interesante directiva de Funius, David Bonilla y Jero. Por mi podría haber durado mucho más pero es el momento de volver a las charlas que para algo hemos venido a Madrid, por el camino nos encontramos con Ernesto al cual ya conocíamos de Tenerife y a su compañero en Extrema Sistemas, David Gomez, una gente muy interesante también.

Effective out-of-container integration testing de Sam Brannen

Llega el momento de escuchar a otro de los gurús internacionales, esta vez Sam Brannen nos cuenta como realizar testing de integración con las herramientas que provee Spring. Es un tema que solo conocía a medias y no está mal, vale la pena echarle un vistazo a SpringTest ya que facilita las pruebas con sistemas externos como servidores de correos, contenedores de servlets y demás. En su momento, cuando haya realizado algunas pruebas, crearé un entrada sobre el tema.

Pruebas de soluciones web con Selenium 2 y Webdriver de David Gomez

David Gomez nos deleitó durante algo menos de una hora con algunas herramientas para hacer tests funcionales. Yo ya conocía Selenium 2 porque es la herramienta que utilizamos en la empresa para hacer pruebas de este tipo. Pero Webdriver me sorprendió muy gratamente sobretodo ahora que estamos pasando toda la aplicación a REST, tecnología con la cual Webdriver parece ser un muy buen framework de pruebas funcionales.

Me gustó mucho también la capacidad de Webdriver para hacer pruebas de este tipo sin levantar una instancia del navegador, porque nosotros no hacemos pruebas muy intensivas, ni de estilos en los tests funcionales, y nos vale con saber que existe un determinado componente y su contenido sin necesidad de conocer como se visualiza. Esto logra que las pruebas sean más estables porque una prueba muy en detalle con esta herramienta puede ser tremendamente frágil y hacerte perder mucho tiempo cada vez que cambies algo en la visualización.

Me voy con muy buen sabor de boca de esta charla y ganas de probar un poco Webdriver por mi cuenta. De aquí saldrá otra entrada en el blog :-)

Spring Social de Federico Caro

Aunque Federico Caro demostró su calidad como ponente y dominaba el tema, me dejó en un estado un poco indiferente, principalmente porque no es un tema que me interese mucho en este momento. Pero hay que admitir que lo que nos enseñó Federico puede ser muy interesante para aplicaciones que necesiten integración con Facebook o LinkedIn por ejemplo, porque simplifican el desarrollo hasta un nivel muy básico. Cuidado con estas cosas, aunque la herramienta haga todo el trabajo es conveniente que conozcas como funciona (por ejemplo OAuth) antes de usarla, y en eso Federico si tuvo mucho cuidado porque explico el tema con más o menos claridad.

Spring Puzzles de Sergi Almar y Eric Camacho

Para finalizar el día de charlas, asistimos a Spring Puzzles que me sorprendió muy gratamente, me mantuvo despierto y me hizo pensar todo el rato. Sergi y Eric (a los cuales tuve la oportunidad de conocer en la comida) presentaron una serie de casos utilizando Spring en los que las cosas no eran lo que parecían.

Este "ejercicio" me trajo a la mente la discusión de "Los Frameworks son evil" de la AOS 2010, volvemos a lo mismo, usar frameworks está bien y es incluso indispensable actualmente, pero por favor intenta saber como funcionan y que hacen por debajo.

Spring & Beers

Para finalizar el largo día, la organización del evento había planificado una noche de networking en el pub Platinum (Boadilla del Monte), algo de cerveza, más sandwiches y muchas risas entre amigos. Tuve la oportunidad de reencontrarme con gente que conocí en la AOS2010 además de conocer a otras, aunque eché bastante de menos a David Bonilla, o Alejando Pérez y José Manual Sánchez (y por supuesto a Roberto Canales que no estaba en el SpringIO). Y también a Jordi de Jobsket, aunque esta vez no necesitamos un guía para encontrar un lugar :-)

Primero los chic@s y yo repusimos energías con algo de bebida y más sandwiches de paquete :-S y posteriormente algo de networking. Para empezar, nos encontramos con José Manuel Beas, luego estuvimos con nuestro canario adoptado Dani Latorre :-) y nos reímos un rato, siempre lo pasamos bien con este hombre. Luego continuamos por la gente de AT Sistemas, Enrique Amodeo e Israel Alcazar con los que también estuvimos al día siguiente siempre son una buena compañía y me volvieron a presentar a Antonio (siento no acordarme del AOS2010, pero mi cabeza ya no es lo que era :-).

Finalizamos la noche hablando con la gente de CyLicon Valley :-D Amalia y Jorge entre otros muchos, y también Jesús Ballano que estaba por allí, gente amable e interesante. Y para acabar Laura Morillo y Alfredo Casado, aunque mejor me hubiese escondido, me toco reprimenda por parte de Laura por no haber hablado a Yuyu de las AgileGirls.

PUBLICIDAD

A ver, a todas las chicas que lean este blog (si es que hay alguna :-) y sean desarrolladoras (menos probable que lo anterior), Laura Morillo ha creado un grupo llamado las AgileGirls en el que están las más selectas desarrolladoras de este país, y es de libre acceso!!! Unete al grupo y demuestra que en España también hay chicas desarrollando y que además saben hacerlo bien.

FIN DE LA PUBLICIDAD

Para finalizar la noche y hablando de las AgileGirls tuve la oportunidad de saludar a Raquel Laina aunque no pude hablar mucho con ella, estad atentos porque me han informado que este es el año de esta chica.

Y con esto y el sueño acumulado que ya llevábamos nos fuimos a descansar hasta el día siguiente. Unos kilómetros de nada, dos vueltas a cada rotonda que encontramos, ir y volver por el mismo camino alguna vez y muchas risas con nuestra inestimable conductora @yurenaghm nos sirvieron para acabar muy bien el día.

En la próxima entrada el día 2 del SpringIO ... stay tuned como diría @DavidBonilla

Retrospectiva 2010

2011-01-02T11:35:00.001Z

Gracias a la petición que David Bonilla ha realizado en su blog, para que diversas personas hagamos una retrospectiva de este año que ha pasado y de objetivos para este nuevo 2011, me veo en la obligación de completar esta tarea :-P (que después el amigo Bonilla llama a Xavi Gost para que me de un capón como a Kini)

Vaya, aquí estoy, 1 de Enero de 2011, unos agradables 25 grados y el sol calentando (esto solo es para dar envidia a los lectores de la Península :-). Que rápido ha pasado el 2010, ahora que hago memoria sobre lo que ha ocurrido, me doy cuenta de las muchas cosas que se pueden hacer en un año, para muestra:

Agile Canarias - Este año hemos logrado consolidar el grupo que hace unos años había intentado formar Carlos Blé, y aunque no ha sido solo por mi mismo, me voy a apuntar mi parte del mérito :-D

CAS2010 - Fran Reyes y yo intentamos asistir a la CAS2010 como ponentes presentando un tema de integración continua, al final no pudo ser ya que habían otras presentaciones sobre el mismo tema de ponentes más experimentados, pero gracias a ello aprendimos mucho más de lo que ya sabíamos y al final pudimos exponer el mismo tema en la Tenerife Lan Party 2010.

AOS2010 - Después de no haber podido asistir a la CAS2010, me desquite un poco asistiendo a la AOS2010, un evento que me encanto y en el que conocí en persona a muchos profesionales y amigos a los que respeto muchísimo.

AvanTIC - Por último pero no por ello menos importante, en mi empresa he podido realizar cosas muy interesantes, como por ejemplo nuestra primera implementación de Scrum que poco a poco va consolidándose y evolucionando para adaptarse a nuestras necesidades. También hemos realizado un proyecto de investigación sobre web semántica en el que hemos utilizado algunas tecnologías que desconocíamos como bases de datos no SQL o lenguajes nuevos para nosotros como Scala.

Objetivos para el 2011

Profesionalmente en mi empresa (en la que trabajo, no es que sea mía :-) quiero aportar lo máximo posible por mi parte para que mejore nuestra productividad y nuestra calidad (sobretodo esto último), después de volver de la AOS2010 tenía un ligero sabor agridulce, no lo estábamos haciendo mal ni mucho menos, pero podemos mejorar mucho … y lo haremos :-D Pero de esto no quiero dar muchos detalles, porque creo que es mejor que vaya haciendo entradas más detalladas sobre esta evolución.

Este nuevo año también quiero asistir a las dos reuniones de Agile-Spain, la CAS2011 y la AOS2011 sean donde sean, aunque voy a seguir luchando porque la Universidad de La Laguna colabore para que la AOS2011 se pueda celebrar aquí (que no están muy entusiasmados con la idea hasta ahora). Y también quiero asistir a la SpringIO este Febrero en Madrid. Ay mi madre, cuanto viaje.

Otra cosa que me gustaría hacer este año es aumentar el número de entradas en el blog con respecto a las del año pasado, que a veces lo tengo muy descuidado, y por ahora va bien que ya estoy haciendo esta :-)

Por último y la más importante a nivel profesional, quiero mejorar, simplemente eso!!! Ya veremos como, tendré que leer muchos libros, practicar muchas horas, aprender de otras personas (e incluso de algunos artesanos a ser posible) tanto como pueda. Quizás incluso proponga en AvanTIC ese modelo de artesanía del software que tanto revuelo ha montado en la AOS2010.

En fin, hasta ahora solo he hablado de temas profesionales, en lo personal 2010 no trajo ninguna nueva noticia, muchos detalles pequeños pero nada relevante, lo cual es bueno porque todo sigue estupendamente. Para este 2011 lo que sí me he propuesto es irme de vacaciones a Nueva York de una maldita vez y por supuesto hacer muchas más fotos, que este año he tenido la cámara un poco olvidada :-P … y sí Gregorio!!! quitarle el polvo a la bici de una maldita vez :-D

De resto, prefiero la perspectiva de Jordi de ir viendo que ocurre día a día, pero sin perder el hilo del "plan maestro" … Por cierto, ya se me olvidaba, Feliz Año Nuevo a todos!!!

La técnica del patito de goma

2010-11-30T08:22:00.004Z

El viernes pasado hicimos lo que podríamos denominar un mini code retreat en casa de Gregorio, aunque más bien era una forma como otra cualquiera de quedar con los amigos para tomarse algo. Tuvimos la suerte de contar con Alejandro, de Autentia, en el cuartel general del #comandomuyayo :-), y resulta que no conocía la Técnica del Patito de Goma, así que me veo en la obligación de explicar en que consiste.

Yo todavía no he encontrado un patito como este :-)

Cuando entré en mi actual empresa, mi jefe me comentaba que una buena técnica cuando estas bloqueado con algún problema, es contarle a alguien lo que ocurre, normalmente en medio del proceso tú solo te das cuenta de que es lo que está fallando. Pero esto tiene un problema obvio ... que tienes que molestar a otra persona para que te atienda, por lo que aparece el Sr. Patito de Goma para resolver el problema. Cuando estés bloqueado coge el patito de goma, cuéntale lo que te ocurre y verás como en gran cantidad de ocasiones te solventará el problema ... y ahora todos estaréis pensando algo como, "este tío está mal de la cabeza", pero no, es totalmente cierto, funciona. Bueno a veces no, en ese caso no hay otro remedio que pedir ayuda a tus compañeros, pero será solo en los casos en los que no te quede más remedio.

Como yo no he encontrado un patito de goma que me guste, tengo a "Fernando" que cumple perfectamente el cometido :-)

En realidad no tiene porque ser un patito de goma, yo por ejemplo uso a "Fernando" (en la foto de arriba), o incluso puedes hablar con la pared, simplemente a tu gusto. Todo se debe a como funciona nuestro cerebro, cuando estamos bloqueados con algo obviamos muchos detalles en los que puede estar la solución del problema, cuando intentamos explicar el problema estos detalles salen a la luz y nosotros mismos nos hemos resuelto el problema :-)

Así que ya sabes, ahora antes de molestar a alguno de tus compañeros ... cuéntale antes tus problemas al Sr. Patito de Goma :-P

P.D: También Gregorio habló de este tema hace un tiempo.

Recomendaciones literarias: The Pragmatic Programmer

2010-11-28T19:00:00.000Z

Buenas a todos, hoy quiero cambiar un poco el tipo de entrada y voy a hablar del último libro que me he leído (que ya era hora), The Pragmatic Programmer. Se trata de uno de los libros más famosos dentro del desarrollo de software y todos aquellos desarrolladores preocupados por su trabajo (los llamados artesanos del software) lo tienen en su estantería (o deberían).

El libro se divide en ocho temas en los que sin llegar a entrar en detalles complejos propone las herramientas y actitudes adecuadas que todo artesano del software debe conocer, desde la visión que inspira a los autores, hasta el momento de entregar el producto al cliente. Aquí podemos ver un resumen del temario.

A Pragmatic Philosophy
A Pragmatic Approach
The Basic Tools
Pragmatic Paranoia
Bend, or Break
While You Are Coding
Before the Project
Pragmatic Projects

En mi opinión personal, se trata de uno de esos libros que se catalogan como un "indispensable". Yo he tenido la suerte de tropezar en mi carrera profesional con personas muy preparadas y que ya utilizaban en mayor o menor medida esta filosofía de trabajo, por lo que habían muchos temas que ya sabía o había leído en otros libros, como por ejemplo Clean Code.

Indistintamente me ha parecido un libro muy completo y entretenido de leer y simplemente se lo recomendaría a todas aquellas personas que no lo hayan leído :-) Pero creo que es un libro especialmente interesante para aquellas personas que acaban de terminar sus estudios y no han empezado a trabajar.

Desde luego, yo después de leerlo estoy aún más comprometido con mi trabajo y con las ganas de hacerlo aún mejor cada día.

Agile Open Spain 2010 (Capítulo 3)

2010-11-16T23:24:00.002Z

En el último capítulo de Agile Open Spain 2010 ... Software que funciona ... Software Craftmanship ... Los Frameworks son "evil" ... Agentes del cambio ... e Incepciones y otros juegos creativos.

Entrevista de guerrilla

Ahí estaba yo hablando con el resto del "comando muyayo" sobre porque había surgido la idea de querer tratar el tema de cómo contratar a los mejores candidatos ... mientras tanto en mi cabeza he de decir que me estaba maldiciendo a mi mismo porque no podía asistir a la charla que se celebraba en el aula de al lado (contratos ágiles con @ecomba).

Poco a poco el aula se empezaba a llenar y parecía que la cosa iba a ir bien, incluso se contó con gente como @xav1uzz, @angel_m o Rodrigo Corral para aportar su experiencia. Nos sentamos y presenté mis razones para proponer esta sesión. Cuando leí por primera vez la visión de Joel Spolsky acerca de como ha de ser una entrevista, me había parecido la forma natural de conocer a los candidatos, mediante pruebas y ejercicios. Hace no mucho, leí que Autentia hacía algo similar en su servicio de head hunting, pero se armo un revuelo en un hilo de Java Hispano en el que menos bonitos los llamaban de todo. @rcanalesmora, @alejandropgarci y José (la gente de Autentia en el AOS2010) me habían contado a lo largo del día en que consistía la prueba que realizan y sigo pensando que es una buena idea, no entiendo la reacción de la "gente" en Java Hispano.

Después de que en 5 minutos yo presentase el asunto, empieza el debate entre los asistentes, que trajo ideas tan interesantes y variadas como las siguientes.

Como contrató @xav1uzz a su último empleado, a ver ¿qué te parece? ... Llega un chico a la oficina de BeCode para dejar el curriculum, pero @xav1uzz lo rompe allí mismo en su cara y le dice que se siente en el ordenador. ¿Sabes TDD ... y JUnit? ¿no? bueno no pasa nada. @xav1uzz escribe un test y le pide a este chico que lo pase ... y lo pasa. Luego otro, y otro ... algunos más. Finalmente el chico ha pasado la prueba y queda contratado. Desde mi punto de vista esta es una de las mejores formas de evaluar a un candidato, y si como candidato te parece duro ... en fin no te contaré lo que hace @ecomba. No te puedes creer un fuera de serie y después no querer demostrarlo, porque sinceramente quedas en entredicho.
Por otro lado @angel_m comentó que en su caso no solo hace una prueba sino que además el candidato debe ser evaluado por múltiples personas de la empresa y del equipo, porque también es importante que encaje en la filosofía del mismo.
Se comentó que también se puede hacer uso de los periodos de prueba, pero la sensación general es que no es muy adecuado, primero es caro debido a los requisitos del sistema laboral actual y segundo y más importante no puedes despedir a gente así como así porque afecta al resto del equipo. En palabras de @xav1uzz, el que una persona no esté capacitada para el puesto no significa que no cree enlaces emocionales con el resto del equipo que puedan romper su armonía si andas probando y despidiendo sin control.
Emma comentó que la aproximación que ellos tenían es acercarse a gente nueva recién salida de la Universidad o contratada en prácticas, de esta forma los pueden ir formando a su gusto. En mi opinión esta es una opción interesante porque no es tan cara como otras y tienes tiempo de ir conociendo a los candidatos, contratándolos si son buenos y dejándolos marchar cuando acaba el tiempo de prácticas si no te convencen.
@xav1uzz propone de nuevo una idea que usan en BeCode y que consiste en hacer jornadas de puertas abiertas y Coding Dojo's cada cierto tiempo, de esta forma puedes ir conociendo gente y verla trabajar, tomas nota y los tienes en cuenta en el futuro :-)
Otra perla de @angel_m. No dejes nunca de entrevistar, si no lo necesitas en ese momento te quedas con los datos para el futuro, porque cuando realmente necesites a alguien no vas a tener tiempo de maniobra.
Para finalizar creo que es necesario recordar un comentario de @xav1uzz sobre su actitud cuando buscaba empleo. Es él quien hace casting de empresas y no las empresas quien lo entrevistaban a él :-) Por ejemplo también comentó que solicitaba ver la biblioteca de la empresa y comprobaba el uso de los libros. Cuando el entrevistador ve esta actitud en general le agrada, porque denota seguridad y conocer lo que realmente se quiere.

Estas son mis conclusiones más importantes, aunque no es lo único que se dijo. Finalmente me quedo con un buen sabor de boca y creo que cuando llegue el momento aplicaré todo lo que he aprendido. Joao me señala el reloj y debo dar por concluida la sesión, aunque la gente tenía muchas ganas de seguir hablando.

Jugando a las retrospectivas

Esto está llegando a su fin y bajamos a la sala de reuniones para hacer la retrospectiva. Con un montón de post-its y jugando como siempre se sacan las ideas principales de la AOS2010 y cosas que se pueden mejorar para sucesivas ediciones.

La idea principal podría ser en mi opinión a la vista de lo que se habló ... somos una comunidad unida y fuerte que en los últimos años ha empezado a andar sola y a su ritmo está cambiando el modo de construir software. Esto lo demuestra la cantidad de nuevos cursos, blogs, comunidades locales, que no paran de crecer y cada vez son más reconocidas.

Las ideas de la gente para mejorar en las próximas ediciones fueron principalmente:

Aumentar la cantidad de asistentes e incluso eliminar el límite de asistentes.
Crear más eventos a nivel local para apoyar al evento general.
Crear una plataforma de discusión previa al evento para que se genere más debate.
Aumentar el número de chicas inscritas (@laura_morillo no cede en su idea :-)

Y finalmente esto se acaba, nos vamos a casa y la sensación de toda la comunidad es que ha sido un AOS2010 RICONUDO!!! :-)

El "comando muyayo" despidiéndose de la AOS2010 ... hasta el próximo año

Promoviendo la agilidad ... nocturna

¿Creían que aquí se iba a acabar todo? Pues no, para empezar cuando bajaba con mis colegas canarios a dejar las cosas en el hotel nos tropezamos con @david_bonilla y @jerolba que se hospedan en el mismo hotel que yo, y quedamos con ellos para más tarde que ya habían quedado con @dani_latorre ... esto promete.

Los canarios hacemos tiempo en una cafetería cercana al hotel para no esperar en el punto de encuentro mucho rato y cuando vamos hacia la estación de metro nos tropezamos de nuevo con @david_bonilla, @jerolba y esta vez iban acompañados de la señora de Bonilla, la simpática Candela. Mientras vamos hacia la Plaza Cataluña hablamos sobre ... abróchense los cinturones ... la posibilidad de una candidatura canaria para la celebración de la AOS2011, ya los "muyayos" nos hemos puesto a ello a ver si llegamos a tiempo.

En la Plaza Cataluña nos reunimos junto a @dani_latorre, @fatimacasau, @alvaro_sanchez, @jordim y nos vamos a cenar para preparar el estomago para una vueltita nocturna (es vuelta porque llegamos antes de las 4, ¿verdad @kinisoftware?).

Después de la cena nos vamos todos a La Oveja Negra en donde empezamos a recuperar gente a un ritmo muy bueno ... aparecen entre otros los chicos Autentia (menos mal porque no me habría perdonado irme de Barcelona sin despedirme de ellos, ya bastante tengo con toda la gente que conocí y de la que no me pude despedir), @laura_morillo y @alfredo_casado. Un momento genial bebiendo y riéndonos, descansando tras una jornada que lo creáis o no ha sido muy dura.

Ahora sí, esto empieza a llegar a su fin ... @david_bonilla, Candela y @jerolba se marchan y yo decido acompañarlos porque también estoy muy cansado, algunas despedidas y promesas de vernos en el próximo evento, creo que he ganado algunos buenos amigos en esta AOS2010 a parte de muchas nuevas ideas. En el taxi estoy casi dormido si no es porque el taxista se esta saltando todos los semáforos y me tiene nervioso. Ya en el hotel toca despedir a @david_bonilla, @jerolba y Candela ... me he alegrado mucho conocerlos en persona porque me agradan aún más que en su versión digital :-P pero hay que hacerlo porque en poco tiempo tenía que estar cogiendo un vuelo de vuelta a Canarias.

RING, RING, RING ... hummm que sueño más raro ... abro los ojos y miro a mi alrededor ... no, no ha sido un sueño, ha sido una experiencia fantástica que repetiré de muy buena gana :-) Y ahora si que me tengo que marchar de tierras barcelonesas ... no os aburriré con más detalles innecesarios.

FIN, espero que os haya gustado mi crónica.

Agile Open Spain 2010 (Capítulo 2)

2010-11-15T22:11:00.000Z

RING, RING, RING ... está sonando el despertador, Dios mio, solo he dormido 3 horas, y el paseo de anoche en taxi hasta el hotel con el hermano gemelo de Lewis Hamilton al volante tampoco es para recordar, pero la noche con la gente de la AOS2010 ha valido la pena. Me doy una ducha y bajo a desayunar, y en el buffet del hotel me encuentro de nuevo con alguien del AOS2010 que no conocía. En este caso 'tropiezo' con Teresa Oliver (@tolivern). No tiene mucho tiempo porque pertenece a la organización del AOS2010 (de nuevo gracias a toda esta gente), pero conozco un poco más de ella y aparece el nombre de Carlos Blé (@carlosble), todo el mundo echa mucho de menos a este gran hombre, incluidos nosotros mismos, el 'Comando Muyayo' (nuevo apodo de @david_bonilla que he decidido hacer oficial) no es el mismo sin él. Me ha parecido muy simpática y agradable, debe ser requisito para estar en la organización porque mi impresión de @amaliahern es la misma. Bueno ha sido un desayuno agradable, pero ahora toca ir a la habitación a coger las cosas y dar un tranquilo paseo hasta la Universidad de La Salle nuevamente. Como anécdota comentar que la localización del hotel (Catalonia Mikado) y de la Universidad es genial, un barrio muy tranquilo y bonito.

El 'huracán' Xavi Gost

Espero al resto del 'comando' en compañía de @tolivern, @amaliahern y @semurat, una compañía agradable, hasta el momento de comenzar las reuniones. Yo he decidido comenzar el día con la de @xav1uzz (Software que funcione, es nuestra responsabilidad) y no podía haber decidido mejor, me ha despertado por completo (en el sentido literal), y os voy a explicar cuales han sido las principales ideas que he obtenido de esta interesante charla.

Xavi me ha tocado la fibra sensible porque ha enfocado el factor humano que hay tras el software mal construido, normalmente no es nuestro cliente el que paga los errores sino las personas de a pie a las que afectan los errores del mismo. Por lo tanto @xav1uzz ha llamado a los desarrolladores a que acepten su responsabilidad y parte de culpa. Simplemente con que cada uno acepte su responsabilidad y ponga límite a hacer software basura las cosas cambiarían radicalmente.

"Estamos en un modelo de negocio que es la estafa ... y no tiene otro nombre" Xavi Gost

Este tipo afirmaciones de @xav1uzz apoyadas firmemente por @ecomba empezaron a levantar revuelo porque gran cantidad de gente creía que si se plantaban ante la actitud de algunas empresas de hacer software de baja calidad, podrían perder su puesto de trabajo. Nada mejor que dos frases de @xav1uzz y @ecomba respectivamente.

"Hay que generar crisis para que las cosas cambien" Xavi Gost

"Yo solo tengo una vida y lo peor que me puede pasar es morir, y eso va a ocurrir sí o sí, a partir de ahí prefiero hacer las cosas bien y divertirme" Enrique Comba

Brutal y directo al grano, mi interpretación no es necesariamente que a ellos les da igual que les despidan, ellos saben que están haciendo bien su trabajo y que la empresa puede presionar pero no es tan sencillo despedir a nadie, sobretodo cuando se debe a que luchan por hacer las cosas bien. Cada cual que saque sus propias conclusiones.

Para acabar me gustaría ahondar en un idea de @xav1uzz que reside en que un artesano de software enseña a un aprendiz de forma altruista con la condición de que este hará lo propio en el futuro, es como en la película "cadena de favores", es una visión muy interesante y creo que voy a participar en ella porque es la mejor forma de mejorar el mundo.

Creo que esta charla va simple y llanamente de que el software no es de mala calidad debido (únicamente) a que hay una serie de empresas que solo quieren enriquecerse a base de estafas, sino porque nosotros mismos lo permitimos, para ello tomo una cita famosa.

"Lo único necesario para que el mal triunfe, es que los hombres de buena voluntad no hagan nada" Edmund Burke

Yo voy a hacer todo lo posible para que el bien triunfe :-) y con cada granito de arena de cada persona que acepte esta idea, el mundo será un lugar un poco mejor.

Enrique Comba "el artesano"

Ahora mismo mi cerebro iba a 1000 Km/h, pero tenía que reponerme porque después de oír hablar a @ecomba es obvio que tengo que asistir a su sesión (Software Craftmanship), si tenía alguna duda previa al respecto, verlo en acción las volatilizo instantáneamente.

@ecomba empezó hablando de los principios del manifiesto de Software Craftmanship, yo no los voy a repetir, aquí tienes el enlace a la web en la que puedes incluso firmar el manifiesto, pero sí que voy a sacar más ideas que me parecieron relevantes.

La primera idea que me llamó la atención y de la que @xav1uzz me habló la noche anterior, es el intercambio de artesanos entre empresas para favorecer el flujo de conocimiento y la mejora constante. Quizás desde que tenga la oportunidad deba aceptar el ofrecimiento de @xav1uzz para pasar una semanita aprendiendo en BeCode.

"Yo con mis clientes me voy de copas ... son nuestros amigos y trabajamos con ellos no para ellos" Enrique Comba

A medida que avanzaba la sesión aparecían temas similares a la charla anterior, pero lo que más me sorprendió es la cantidad de veces que aparecía la palabra mierda para referirse al software o lo complicado que es adquirir los conocimientos necesarios para trabajar bien ... es un poco egoísta pero aquí estaba viendo que mi sesión no parecía tan simple como creía, encontrar a la gente adecuada es muy importante. ¿Habré encontrado la respuesta a como buscar los mejores candidatos?, tendrás que seguir leyendo :-)

"Cuando alcances el nivel en el que podrías crear tu propia empresa pasas de ser un aprendiz a ser un artesano del software" Enrique Comba

"Yo cuando hablo de artesanía no estoy hablando de cosas fabricadas con aspecto rústico, hablo de fabricar Huevos de Fabergé" Xavi Gost

Creo que es increíble, es como si esta sesión fuese la segunda parte ideal de la charla anterior de @xav1uzz, y que esto no estuviese planeado sino que saliese de las decisiones de todo el grupo al organizar el panel el día anterior es riconudo (preguntar a @alejandropgarci por la palabra). Para finalizar esta sesión me gustaría citar un punto de vista de Alan Cyment que comentaba que también hay que saber educar al cliente y enseñarle en qué se debe fijar cuando compra software, para que aprenda a diferenciar la calidad de los malos desarrollos. Igual que un buen vendedor te comenta cuales son los aspectos en los que se diferencian dos teles o dos coches, etc. Cierto Alan es una buena idea para que las cosas comiencen a cambiar.

Combate en la cumbre, Roberto Canales vs. Xavi Gost

Llegó uno de los momentos más esperados, @xav1uzz proponía que los frameworks son "evil" y @rcanalesmora proponía que son totalmente necesarios ... la sangre está servida :-)

No te equivoques no se está hablando de que @xav1uzz no use frameworks de desarrollo, todos los usamos sería impensable actualmente no hacerlo, pero surge una cuestión, ¿están estos frameworks haciendo "mas tontos" a los desarrolladores?

Cuando hablo con algunos de mis colegas yo mismo me he dado cuenta que hay mucha gente que sabe usar frameworks ... digamos Hibernate o Spring ... pero no saben como trabajan y eso según la propuesta de @xav1uzz es totalmente negativo porque los desarrolladores se empiezan a convertir en "monos". Atentos a lo que he escrito, "monos", @xav1uzz que es aún más "manipulador" que Raquel Laina (@rlaina) logra con esta magnifica jugada que @rcanalesmora y @alejandropgarci defiendan que es necesario contratar monos en las empresas porque el ritmo de desarrollo lo requiere, lo que virtualmente les hace parecer los malos de la película.

Nota: La mención a Raquel Laina aquí hay que focalizarla en el contexto, yo no he escrito que ella sea una persona manipuladora, simplemente me he referido a su sesión de la que hablaré posteriormente.

Esta sesión no fue mi favorita pero estuvo muy bien, me quedo con el momento final en el que @xav1uzz pasa a defender los frameworks y @alejandropgarci a tacharlos de "evil" :-S

"Los frameworks son evil, porque la potencia sin control no sirve de nada" Alejandro Pérez

Magnifico resumen de @alejandropgarci, no es malo usar los frameworks, pero por favor antes de hacerlo estudia como funcionan y que es lo que hacen porque te ahorrará muchos problemas.

El arte de la manipulación

Había leído la idea de @rlaina en el google doc, que tenía la organización sobre las sesiones que querían proponer los asistentes, y me había resultado muy interesante, pero ver como la presentó en aquella sala llena de gente, con esa forma de decir "manipula!" hace que cualquiera desee asistir a su sesión :-P

@rlaina expuso fantásticamente el problema que nos planteamos, queremos ser ágiles, queremos que la empresa se dinamice, que las cosas se intenten hacer mejor, y deseamos ser el agente de dicho cambio. ¿Cómo lo hacemos?. Voy a comentar algunas de las ideas que propuso para hacer este camino un poco más sencillo o algunos de sus mejores consejos.

Siempre hay que hacer ver a la otra parte implicada que ellos van a ganar con el cambio y qué es lo que van a ganar.
Si esperas recibir algo a cambio te vas a estrellar, intenta lograr el cambio para mejorar tu vida pero no esperes que nadie te venga a dar las gracias.
La resistencia al cambio es una medida que confirma que las cosas van saliendo bien :-)
A veces tienes que montarles las herramientas tú a los demás porque si esperas que lo hagan ellos te puedes quedar sentado.
Busca ayuda no puedes hacerlo tú solo.

En definitiva la sesión fue muy bien, pero antes de acabar me gustaría contar una anécdota que da una idea de la capacidad de esta chica (aquí @laura_morillo tiene una compañera para su club :) para llevar la sesión. Durante un rato todos estuvimos proponiendo temas de los que nos gustaría hablar o que nos diese alguna idea de como afrontarlos, yo propuse "¿cómo hacer ver a nuestro equipo que se cree super ágil que no lo son?". Pero a la hora de priorizarlos resultaba que tan solo me interesaba a mi (sí lo sé, es un gran golpe para mi ego :-), aún así mientras respondía a alguna cuestión que al grupo le parecía más interesante se las ingenió para colar la respuesta a mi pregunta, increíble. Durante el resto de la AOS2010 no volví a coincidir con @rlaina y me habría gustado hacerle algunas preguntas sobre su experiencia, pero es lo que tiene esto del AOS vas de un lado a otro compartiendo conocimiento con un montón de personas y no siempre hay tiempo para todo lo que te gustaría.

Origen

@ecomba propone una charla titulada "Incepciones y otros juegos creativos", me enteré un poco mejor de la temática cuando se la explicaba a @alejandropgarci y no pensaba faltar a la misma. Esta charla me ha desmontado por completo, ver como @ecomba "juega" junto a sus clientes para enfocar el proyecto ha sido sublime, tanto que no estoy preparado para hacer un resumen en condiciones.

Este hombre ha tratado el tema de la focalización del proyecto, los requisitos, las necesidadades ... el origen ... como no lo había visto en la vida, parecía que estuviese hablando de manualidades, para acabar obteniendo la planificación del proyecto del cliente, todavía no salgo de mi asombro, en serio esto merece un post completo bien estudiado (no se si tendré lo que hay que tener para ser su "aprendiz"). Recomiendo la entrada de @laura_morillo para entender un poco mejor a que me refiero.

En el próximo capítulo de AOS2010

Entrevista de guerrilla ... jugando a las retrospectivas ... de paseo con los amigos ... fin de fiesta

Agile Open Spain 2010 (Capítulo 1)

2010-11-14T22:23:00.004Z

Cuando se abrió la inscripción de la Agile Open Spain 2010 (AOS2010) no participé, porque en Tenerife teníamos programado un curso de ScrumManager, pero al final no se ha podido celebrar dicho curso. Yo pensaba que me había quedado sin la posibilidad de asistir a Barcelona a la AOS2010, pero una amiga me convenció para inscribirme a la lista de espera, la cual yo creía que tendría a tantas personas que sería imposible conseguir plaza. Pero de perdidos al río, tampoco había nada que perder, y efectivamente al final hubo plaza y asistí a la AOS2010. Aquí os contaré cual fue mi experiencia personal.

De Tenerife a Barcelona

El hecho de asistir a la AOS2010 implicaba que tenía que faltar a mi puesto de trabajo el viernes casi sin previo aviso, y estábamos en medio de la entrega de un producto, al final todo fue bien pero casi no tuve tiempo de informarme sobre el formato de la AOS2010 ni de preparar nada.

Mientras iba en el avión leyendo "The Pragmatic Programmer" (lo sé lo sé, es un #fail que aún no me lo haya leido) se me encendió la bombilla y me vino a la cabeza el artículo de Joel Spolsky sobre entrevista de guerrilla y el revuelo formado en la comunidad Java Hispano acerca del anuncio de Head Hunting de Autentia (más adelante hablaremos de ello). Lo tenía claro, ese tema era uno de los que quería tratar en AOS2010, con la cabeza más despejada seguí leyendo hasta llegar a mi destino, la cosmopolita ciudad de Barcelona.

Ya estaba camino del edificio de Ingeniería y Arquitectura de la Universidad La Salle y pensaba en la cantidad de gente que conocía de leer sus blogs o de Twitter pero a los que ni tan siquiera había visto en mi vida. Conocer a toda esa gente era uno de mis objetivos principales y que sorpresa cuando la persona que se encarga de darme mi acreditación es ni más ni menos que Amalia Hernández (@amaliahern), super simpática y amable. Aquí y antes de que se me olvide, agradecer a ella y al resto de personas de la organización su GRAN labor porque sin ese trabajo, este evento no habría sido posible.

Una vez acreditado aproveché para conectarme y ver que ocurría con mis amigos Fran Reyes (@fran_reyes), Juanma Barroso (@jmbarroso) y Juanjo Coello (@jjcoellov), se retrasaban como siempre y esto empezaba a llenarse, pero al final llegaron justo a tiempo, tomamos asientos y comienza el show :-)

El juego de las tribus

Tras presentar el evento, y para romper el hielo, se propone el juego de las tribus. Este juego consiste en que el organizador propone una temática y la gente se agrupa en función a dicha temática. La primera es sencilla, lugar de origen, y allí estábamos Fran, Juanma, Juanjo y yo, cuando de pronto aparece Roberto Canales (@rcanalesmora) y nos comenta que él es nacido en Gran Canaria, toma ya, otro Canario al menos de nacimiento. ¿Pero crees que la cosa acaba ahí?, del grupo de al lado se gira un joven alto y un poco delgado llamado Joaquin Engelmo (@kinisoftware) y dice que él también nació en Canarias, creo que la sorpresa se la llevo él esta vez cuando leyo mi identificación :-) Efusivo saludo de reconocimiento mutuo y continuamos ambos el juego.

En la segunda parte del juego, Joao comenta que esta vez nos debemos asociar por hobbies, parece una buena idea y decido levantar la mano y decir que el mio es la fotografía, luego me separo para que el resto de personas interesadas en mi hobby se acerquen. Discusión entre Nikon y Canon que nada tiene que ver con agilismo y quien se pone del lado de Canon conmigo, ni más ni menos que el gran Enrique Comba Riepenhausen (@ecomba), increíble. Pero se acaba el juego y tendré que esperar para seguir conociendo a gente.

Ahora toca saber donde creemos que estamos y conocer a la gente que nos rodea, para ello a lo largo de la sala la gente se coloca desde una pared que representa "yo no tengo ni idea de que va esto" hasta la pared opuesta que representa "yo soy Mike Cohn" (o Xavi Gost) :-) Un ejercicio interesante de introspección. Después de dar vueltas a este ejercicio y de vuelta a casa reflexiono en que no tengo ni idea de donde estoy realmente, solo sé que cada día que me levante quiero estar un paso por delante de ayer y no ceder ni uno hacia atrás.

Panel de sesiones

Para los que no sepan como funciona este tipo de eventos, como yo antes de este fin de semana, lo más extraño es que no hay preparada ninguna sesión antes de que comience el evento. La gente me preguntaba, ¿vas a ir a un evento en el que no sabes de qué se va a hablar? y yo contestaba, sí se va a hablar de como desarrollar (buen) software y con eso me basta.

Pues listo, hemos roto el hielo y ahora cada persona interesada, debe escribir en un papel con pocas palabras de que quiere hablar y luego exponerlo en 30 segundos al resto de la sala. Todas las propuestas se colocan en una pared y entre todos las puntuamos indicando cuales son las 6 a las que deseamos asistir. Yo ya no estaba muy seguro de mi idea sobre "Entrevistas de guerrilla", pero cuando acabó el proceso de puntuación y organización en el panel de salas, parecía que había gente que le interesaba el mismo tema que a mi, incluso gente como Alejandro Pérez (@alejandropgarci) o José Manuel Beas (@jmbeas) lo cual me lleva a una de mis primeras "conclusiones". Hay gente con los mismos problemas y preocupaciones que yo.

Debo destacar que durante el proceso de puntuación y mientras voy viendo gente por aquí y por allá, me tropiezo con Jorge Jiménez (@semurat), que ganas tenía de conocerlo de una vez por todas, otro gran tipo allá donde los haya.

Panel resultante de las sesiones presentadas

Una vez que se ha completado el panel, está todo listo para el día siguiente, aunque os adelanto que tendréis que esperar hasta los siguientes capítulos para ver como se desarrollan las mismas, ya sabéis, el efecto "y en el siguiente capítulo de AOS2010" :-)

Agilidad nocturna

Una vez organizado todo para el día siguiente toca networking, socializar, divertirse, porque toda esta gente son también grandes personas que rompen por completo el mito del informático encerrado en el sótano. Por fin tengo el placer y a la vez honor de conocer a "mi ídolo" David Bonilla (@david_bonilla) y al imperturbable Jerónimo (Jeroclo el Espartano, @jerolba), unos tíos fenomenales de los que iremos conociendo más cosas en los próximos capítulos :-)

Primero empezamos con una cena en la que coincido en la mesa con más gente nueva como Jordi de Jobsket, Fatima Casau (@fatimacasau), Álvaro Sánchez (@alvaro_sanchez), José el compañero de Alejandro en Autentia o el mismo Alejandro, que grande este tipo que tuve la suerte de conocer en Tenerife, los demás no lo entenderéis, pero "si quieres ser un pro tienes que conocer Jägermeister".

Para finalizar la noche fuimos a un local a tomar algo, en el que tuve la suerte de seguir conociendo mejor a @semurat, la gente de Autentia, @ialcazar y otros muchos que se me olvidan y que ya conocía al menos de oídas. Lamenté junto a @kinisoftware y @jmbeas no haber propuesto la sesión de patrones, pero yo tenía que haber tenido los cojo... de presentarla. Y he de admitir que ha sido fantástico poder hablar un poco más con @jmbeas y conocer ya personalmente a @xav1uzz. He apoyado a @dani_latorre en su teoría sobre la definición de dar un vuelta y salir de marcha, que @kinisoftware parecía desconocer :-) Y finalmente he tenido el placer de charlar un rato con Alfredo Casado (@AlfredoCasado) o con Laura Morillo (@laura_morillo) entre otras muchas cosas de su blog http://noessolocosadehombres.wordpress.com/

Si te ha gustado este entrante ... abróchate el cinturón y agárrate porque en los siguientes capítulos vienen las curvas.

Reunión de Noviembre de AgileCanarias

2010-11-06T09:52:00.001Z

Ayer volvió a reunirse el grupo de AgileCanarias, evento que merece una entrada en este blog :-) Dicha reunión se dividió en dos partes claramente diferenciadas, por un lado hicimos un juego ágil que demostraba la importancia de los equipos multi-disciplinares y auto-organizados, por otro lado, Gregorio Mena realizó una fantástica charla sobre GTD que generó un debate bastante interesante.

You are not in control

"You are not in control" es el nombre de un "juego ágil" que muestra la importancia de tener equipos multi-disciplinares y auto-organizados. El juego consta de dos rondas en las que los equipos deben construir la mayor cantidad de aviones de papel atendiendo a los requisitos del organizador del juego. En la primera ronda el equipo puede organizarse el trabajo como quiera de forma autónoma, en la segunda ronda cada componente del equipo tiene un puesto diferente, una persona es el jefe de proyecto, otra es el piloto que se encarga de ajustar cosas como el timón o los flaps, una tercera se encargará de hacer y asegurar los pliegues en la hoja de papel y por último una cuarta es la que mantiene los pliegues de las hojas en contacto ya que el que hace los pliegues no puede hacer esto :-) Suena divertido ¿verdad?, pues lo es.

A medida que avanza el juego a los equipos les van sucediendo cosas como las que ocurren en la vida real, los componentes de los equipos cambian de equipos, el organizador introduce nuevos requisitos, ese tipo de cosas que probablemente todos hemos vivido más de una vez.

Los resultados del juego demostraron perfectamente como en la primera ronda, los tiempos que tardaban los equipos en poner a producir los nuevos componentes que entraban al grupo o los tiempos que tardaban en adaptarse a los nuevos requisitos eran menores que cuando el equipo estaba organizado por puestos de trabajo perfectamente definidos. Incluso la cantidad de aviones construidos y más importante, la cantidad de aviones aceptados por el organizador (en este caso yo mismo) también era superior.

Por lo tanto concluimos con que los equipos multi-disciplinares y auto-organizados son más productivos que los equipos clásicos altamente jerarquizados. Además quiero incluir una frase que leí ayer en un artículo de Joel Spolsky citado por David Bonilla en Twitter.

"Basically, if you’re going to hire smart people, you’re going to have to let them apply their skills to their work"

En mi opinión esta frase tiene mucho que ver con los equipos auto-organizados, no puedes intentar contratar a los mejores desarrolladores del mundo y después empezar a imponerles límites porque limitarás su creatividad y los harás menos productivos.

Getting things done

Para continuar, mi colega Gregorio Mena realizó una perfecta introducción a GTD (de David Allen). Yo haré un resumen, pero antes de nada quiero aclarar que cualquier error es posiblemente culpa mía al transcribir y no de Gregorio en su exposición :-)

Para resumir, en mi opinión la parte más importante fue la definición de los 5 pasos básicos de GTD.

1. Recopilar las tareas pendientes para vaciar nuestra cabeza de estas preocupaciones.

2. Procesar las tareas pendientes para hacernos una idea de su magnitud.

3. Organizar las tareas en grupos y prioridad, por ejemplo tareas a realizar en el próximo mes, "proyecto" (grupos de tareas para conseguir un único objetivo), "en espera" (tareas que no dependen de nosotros mismos) y "quizás" (tareas que nos gustaría hacer pero que no son seguras). Obviamente esta es una clasificación pero no es la única que existe y siempre dependerá de cada persona tener más o menos categorías.

4. Revisar de vez en cuando las tareas pendientes, esto dependerá de la prioridad y el grupo de tareas, es muy posible que hayan grupos que revisemos cada semana y otros que revisemos varias veces al día.

5. Hacer las tareas, es obvio la parte fundamental es hacer las tareas poco a poco, porque en otro caso este sistema no sirve para nada :-D

Estos pasos no son más que una guía pero no tienen porque hacerse en este orden, simplemente son las cosas que tienes que hacer para usar GTD.

Otras frases interesantes mencionadas por Gregorio y que a mi me parecen fundamentales para una correcta implementación de GTD son las siguientes.

"Hay que tener una visión clara de que es lo que se quiere obtener, cual es el objetivo a lograr, es decir visualizar los resultados, para poder llegar a ellos más fácilmente"

"Si una tarea tardo menos en hacerla que en procesarla y organizarla, mejor la hago porque en otro caso estoy perdiendo tiempo"

Despedida y cierre hasta la próxima reunión

Al final algunos de los que fuimos a la reunión acabamos en un bar cercano tomándonos algo, ¿qué sería de una de estas reuniones sin la correspondiente socialización?, se habló de bastantes cosas pero me quedo con la siguiente frase de Carlos Blé, que me gustó mucho.

"Si comienzas un proyecto con un lenguaje y una tecnología nueva, multiplica tus estimaciones por cuatro y acertarás casi siempre"

Creo que lo voy a aplicar porque se acerca bastante a mi experiencia personal :-) Y con esto y un bizcocho ... bueno es lo que hay hasta la próxima reunión.

P.D: Atentos a las próximas noticias porque esta semana he tenido una idea que le he comentado a Carlos y a él también le ha parecido bien, desde que me ponga en contacto con el resto de interesados estad seguros que os vais a enterar.

Algo de UML básico

2010-10-23T20:33:00.002+01:00

Este viernes en la oficina uno de mis compañeros y yo estábamos comentando uno de los tweets de una amiga, en el que decía que no entendía cual es la diferencia entre agregación y composición en UML. Después de algunos minutos hablando comprobamos que aunque supiésemos diferenciar entre los dos, nosotros tampoco podíamos dar una definición técnica correcta de ambos términos. Por esta razón voy a crear una entrada en la que tras documentarme trataré de dejar claro que es composición y que es agregación. Demostrando por otro lado que siempre es interesante volver a las bases de vez en cuando, tanto para refrescarlas como para verlas desde otro nuevo punto de vista.

Definición de libro.

Para empezar utilizaré las definiciones del libro de Tim Weilkiens y Bernd Oestereich, "UML 2 Certification Guide".

"An aggregation is an association expanded by the semantically noncommittal comment that the participating classes have no equal-ranking relationship; instead they represent a whole-parts hierarchy. An aggregation is used to describe how something whole is logically composed of its parts."

"A composition is a strict form of aggregation, where the existence of its parts depends on the whole. The whole is the owner of its parts. It describes how something whole is composed of individual parts."

Vamos, aunque se entiende lo que dicen, después de leer esto me quedo un poco confuso (más que nada porque todavía estoy pescando con lo de noncommital comment; nota mental, tengo que mejorar mi inglés), vamos a ver que dice Martin Fowler en su libro, "UML Distilled Third Edition".

Bueno pues, decir decir no dice mucho, pero los diagramas utilizados por el señor Fowler clarifican bastante.

Agregación

Composición

A ver, tras leer las definiciones y ver los diagramas de ambos libros tenemos una idea bastante concreta de que es cada termino. Utilizamos agregación cuando queremos hablar de una asociación entre clases en la que ambas tienen "vida propia", es decir que ambas forman parte del modelo de negocio por si mismas independientemente de la existencia de la otra. En cambio, utilizamos composición cuando queremos hablar de una clase que hace uso de otras más "pequeñas" para formar un solo concepto del modelo de negocio, es decir una serie de clases que no tienen sentido fuera de ese concepto más general y que no existirían en otro caso dentro del modelo de negocio.

Nota sobre UML.

Para acabar y aunque no está totalmente relacionado con la entrada, me gustaría citar una frase que leí en un "retweet" y que lamentablemente no me acuerdo de su autor, aunque estaría encantado que alguien me lo dijese.

"UML no es malo, lo malo es creer que es la magia para que luego un mono te haga el código"

Cito esta frase porque yo soy de esas personas que creen que UML es una buena herramienta de comunicación (directa, cara a cara a ser posible) pero ni remotamente permite definir de forma completa un sistema en un diseño real (al fin y al cabo en realidad el código fuente es el diseño, ¿o no?).

Bibliografía :-)

La maldita codificación de caracteres

2010-10-09T20:19:00.002+01:00

Esta semana he estado trabajando en un proyecto y me vino a la cabeza este artículo de Joel Spolsky sobre codificación de caracteres, porque nuestra aplicación (que por suerte está en fase de desarrollo) mostraba serios problemas de codificación en los diferentes navegadores con los que probábamos.

Vamos a ver, todos nuestros ficheros estaban en UTF-8 y los ficheros JSP tenían su correspondiente encabezado con la etiqueta meta indicando que la codificación es efectivamente UTF-8, ¿por qué razón el navegador detecta que están en ISO-8859-1?

Después de estar un rato buscando y leyendo información al respecto, he encontrado este interesante filtro creado por la gente de Spring que permite forzar la codificación de caracteres en el descriptor de la aplicación (web.xml).


   <filter>
      <filter-name>encodingFilter</filter-name>
      <filter-class>

         org.springframework.web.filter.CharacterEncodingFilter

      </filter-class>
      <init-param>
         <param-name>encoding</param-name>

         <param-value>UTF-8</param-value>

      </init-param>
      <init-param>
         <param-name>forceEncoding</param-name>

         <param-value>true</param-value>

      </init-param>
   </filter>

   <filter-mapping>
      <filter-name>encodingFilter</filter-name>
      <url-pattern>*</url-pattern>
   </filter-mapping>

Al introducir esta modificación en la aplicación, el navegador ya detecta que las páginas están en codificación UTF-8 ... !problema resuelto! ... pues no, en realidad ahora estamos peor que antes, no se ve bien en UTF-8 y se ve aún peor en ISO-8859-1. ¿Qué está ocurriendo aquí? A mi compañero Pablo se le ocurre abrir los fichero en un editor diferente al IDE que estamos utilizando, IntelliJ IDEA, y nos sorprende ver que la codificación es ... ANSI as UTF-8?!?!?! por lo que cambiamos a UTF-8 y volvemos a cargar la página, ahora todo se ve correctamente. Si a ti también te ha pasado esto seguro que te has quedado con la misma cara de incógnita que Pablo y yo, pero bueno ya tenemos la solución, y decidimos dejar el filtro encodingFilter porque nos asegura que aunque se nos olvide utilizar el tag meta con la información de codificación de las páginas, la aplicación funcionará bien.

Un rato más tarde estamos realizando la tarea de internacionalización de la aplicación, cambiando los literales por las etiquetas de los messages.properties correspondientes (los ficheros son cargados por el message source de Spring, ya que estamos usando Spring MVC) y cuando probamos la aplicación, resulta que la codificación es errónea de nuevo. Hoy no es nuestro día, pero el error debe estar en los ficheros .properties para la internacionalización, pues no, están perfectamente codificados y el resto no se ha cambiado. Aquí hay algo que no hemos visto o alguien no nos ha contado, de nuevo a googlear para ver cual es el problema y encontramos este fantástico artículo, sencillo y directo al grano. Pues claro ... si Java carga los .properties como ISO-8859-1 aunque el resto sea UTF-8 tenemos un problema, pero aquí llega de nuevo Spring a nuestro rescate y basta con cambiar ResourceBundleMessageSource por ReloadableResourceBundleMessageSource en nuestro applicationContext.xml o el fichero que se haya utilizado en cada caso concreto, y todo funciona de nuevo.


   <bean class="org.springframework.context.support.ReloadableResourceBundleMessageSource" id="messageSource">
      <property name="basename" value="classpath:messages">
      <property name="defaultEncoding" value="UTF-8">
   </bean>

Cual es la moraleja de hoy, pues primero desquitarme con IntelliJ IDEA porque nos ha tenido un rato más perdidos que un pulpo en un garaje, y segundo recordar a todo aquel que no haya leído el artículo del señor Spolsky que lo haga :-) Querido Joel ... nosotros ya hemos resuelto nuestros problemas de codificación, no nos ponga en su lista negra :-P

Lo que aprendimos con The Marshmallow Challenge

2010-09-07T21:48:00.002+01:00

Buenas a todos tras estas largas vacaciones, para quien las haya tenido, que no es mi caso :-) pero ya llegarán, aunque el blog si que ha estado de vacaciones, no lo puedo negar. He estado retirado en la montaña (dígase la zona de relax de la oficina) buscando la inspiración y ... bueno no ha llegado tampoco, pero se hará lo que se pueda ;-)

En la reunión realizada en Julio por el grupo Agile Canarias, mi compañero Gregorio Mena y yo quisimos darle un nuevo enfoque y propusimos la realización de algún juego que demostrase algún fundamento relacionado con el agilismo. La verdad es que no hubo ninguna duda, y desde el primer momento que vimos la página de Tom Wujec acerca de The Marshmallow Challenge sabíamos que esta era la opción adecuada, un juego divertido y con unas lecciones asombrosas.

La verdad es que no hay nada mejor que revisar la documentación propuesta por Tom Wujec para entenderlo todo, pero haré un breve resumen antes de pasar a las conclusiones que obtuvimos en el grupo. Bien, el juego es muy sencillo, a cada equipo compuesto como mínimo por dos personas (aunque lo ideal es que sean grupos de 4 como mínimo), se le entrega el siguiente material.

20 spaghettis
1 yarda de cinta aislante (optamos al final por 1 metro)
1 yarda de cordel (también usamos 1 metro)
1 marshmallow (aquí en España es mejor optar por una nube de azucar)

Con el citado material, cada equipo debe construir una estructura lo más alta posible en 18 minutos de tiempo, teniendo en cuenta que se mide desde la base de la estructura hasta la parte superior de la nube (que en ningún caso se puede romper). Visto de esta manera parece muy sencillo ¿verdad? pues permitid que os diga que no lo es, y que además os reiréis mucho si optáis por hacer el juego.

Vaya, ¿y qué tiene que ver esto con el agilismo o con construir software? Pues nada de nada y todo a la vez, tanto en las transparencias de Tom Wujec como en nuestra propia experiencia pudimos observar muchos aspectos interesantes.

La importancia del prototipado y reducción de la incertidumbre.

Gregorio y yo ya habíamos leído el material del Sr. Wujec y creíamos que mucha gente pasaría gran parte del tiempo diseñando y luego empezaría a construir, pero nos equivocábamos. Todos los asistentes eran en realidad de aspecto técnico por lo que prefirieron empezar a construir y hacer pruebas, lo cual está muy bien, ¿por qué? Pues porque ninguno de ellos era arquitecto, ingeniero de estructuras o similar, no tenían conocimientos previos sobre diseño de estructuras o reparto de cargas, por lo que haciendo estas pruebas reducían la incertidumbre del problema y tenían más posibilidades de llegar a una solución, aunque en el siguiente punto veremos otro aspecto importante que había que tener en cuenta.

Los chicos AvanTIC pensando en el problema

En el desarrollo de software la reducción de la incertidumbre es fundamental, mucha gente se dedica a estar un año haciendo documentos de word y diagramas UML, pero a la hora de la verdad la incertidumbre de cara a la construcción no se ha reducido, lo que en el futuro generalmente hace que el proyecto se retrase porque empiezan a aparecer los problemas que no se vieron al principio. Es mejor que el análisis y el desarrollo vayan de la mano y sean fases que se solapen y no en el estilo clásico en cascada, por lo menos es mi opinión.


Carlos Blé y Dani Latorre manos a la obra

Estos chicos tienen futuro, paso a paso

Hay que conocer el objetivo real del proyecto.

Vaya, ¿pero el objetivo no era construir la estructura más alta posible? Si y no, en realidad si analizamos el enunciado correctamente, el objetivo es situar la nube lo más lejos de la base posible y esto lo cambia todo. Los participantes de Agile Canarias hicieron un gran trabajo pero tan solo al final empezaron a hacer pruebas colocando la nube en lo alto de la estructura ¿sabéis que pasó? pues si, muchas estructuras no resistieron el peso.

Ubay y Yurena empiezan a dar nivel :-)

Esto tiene mucho que ver con el desarrollo iterativo, es mejor ir construyendo una solución completa desde el principio e ir añadiendo mejoras que construir las piezas por separado y después unirlas. Volvemos al mismo problema del punto anterior, si no sabemos como trabajan las piezas juntas seguimos teniendo una incertidumbre del 100% y eso se debe evitar.

IM-PRESIONANTE

Los equipos multidisciplinares funcionan mejor.

Por desgracia nosotros no pudimos comprobar este punto porque todos los asistentes eran técnicos, pero para todo el que este leyendo este blog seguro que sabe que hay que encontrar el equilibrio entre la gestión y la parte técnica. Construir software de calidad es mucho más complicado que esta torre de spaghettis y sin las personas apropiadas con los conocimientos apropiados de cada una de ellas, se hace más complicado.

Existen otras conclusiones por parte de Tom Wujec, pero esas os las dejo a vosotros porque es mejor oírlas expuestas por él en su vídeo :-) el tío es un crack presentando las ideas.

Mis propias conclusiones.

Ya se que lo que voy a decir a continuación es trivial y todo el mundo lo sabe, pero por si acaso lo voy a decir igualmente. Con el paso del tiempo los equipos empezaban a tener levantadas sus estructuras (o no, depende del caso :-) y como es obvio unos se fijaban en los otros. Cuando empezaron a quedar pocos minutos algunos grupos añadían más spaghettis para que su torre fuese más alta que la de los contrarios, pero en muchos casos resultó en una caída de la estructura. Cual es la moraleja, pues que habían equipos que podían haber tenido por ejemplo la segunda o tercera estructura más alta pero la competitividad y la presión del tiempo hicieron que no tuvieran una solución. Volvamos, ¿y qué quiero decir con esto?, pues que para el cliente, incluso en momentos de presión, siempre será mejor tener una solución que un montón de líneas de código y documentos que no hacen nada o que hacen cosas que no solucionan su problema.

Antes de terminar, dar las gracias a todas las personas que hacen posible Agile Canarias y que pasemos estos momentos tan divertidos, espero que os haya gustado el artículo y sino pues podéis insultarme y esas cosas en los comentarios :-P

Retrospectiva de la TLP 2K10

2010-07-26T21:57:00.003+01:00

La semana pasada se celebró la Tenerife Lan Party 2010 y como participante en la zona profesional voy a intentar hacer una retrospectiva que merezca la pena (cosa un poco complicada si la hago yo :-P) Aunque antes de entrar en materia hay que felicitar al equipo de organizadores y colaboradores por el gran trabajo realizado y el esfuerzo monumental que han llevado a cabo. Felicidades a la gente de Innova7, seguid así chicos/as!!!

Mi propia participación

Me gustaría empezar con las sensaciones que me ha dejado el taller que realicé junto a Fran Reyes sobre Integración Continua, pero para ello debo empezar dando las gracias a una serie de personas sin las que no hubiese sido posible. Gracias a Juanma, Juanjo y Fran Olmedilla por su ayuda con la instalación de las máquina virtuales, es lo que tienen los colegas, que te dan la mano y les coges hasta el hombro. Por otro lado pero no menos importante gracias a Tana (aquí en la foto) por habernos ayudado también con la instalación de las máquinas y por soportar una prueba del taller que nos sirvió para corregir muchos detalles, gracias Tana!!! Para acabar, gracias a la gente de Innova7 por el trabajo realizado y en especial a Cesar, Eduardo y también a Juan del Sol.

El taller no salió mal aunque contó con bastante poca participación, una pena para nosotros porque habíamos trabajado duro, pero comprendemos que no somos conocidos ni famosos, nos esforzaremos aún más en el futuro porque somos de esas personas que no conocen la palabra derrota :-P. Al menos la gente que fue lo valoró positivamente, gracias chicos, y contamos con Carlos Blé y Dani Latorre ni más ni menos, todo un honor para nosotros (ya os ingresamos la cantidad acordada chicos :-).

Por otro lado dos horas de taller se nos quedaron cortas y los asistentes no pudieron trastear todo lo que querían, pero debido al gran número de charlas y talleres que habían no podíamos disponer de más tiempo :-(

Otras charlas a las que asistí

Requisitos legales de una PYME para estar en Internet Debo ser sincero y decir que me senté en esta especie de reunión informal (que poca gente había, como en mi propio taller :-S) organizada por Paloma Llaneza, un poco obligado, pero Dios mio!! que sorpresa, nunca había imaginado que hablar de temas legales, LSSI y LOPD pudiese ser tan interesante, felicidades Paloma porque has hecho un gran trabajo. A fastidiarse todos los que se la perdieron :-D y os aseguro que este tema tiene más contenido de lo que parece incluso para los que hacemos un simple blog como este (o mejor este a ser posible).

Jobsket: Grails en una aplicación real Mi favorita y no porque la hubiese presentado Dani Latorre, sino porque era una de las pocas relacionadas con el desarrollo de software de verdad (que pena que no hubiesen más, me quedé con las ganas de ir a la de minube.com), y además ejecutada de forma magistral por este maño. Nuevamente con una muy baja participación, me preocupa la gente porque se queja de que nunca se hacen este tipo de eventos, pero cuando se hacen nunca aparecen (gente hay que cambiar el chip, ESTE TIPO DE EVENTOS SON IMPORTANTES). Gran trabajo Dani, te echaremos de menos aquí en Tenerife.

SEO y HTML5 Esta charla impartida por Javier Casares no estuvo mal, aunque se me hizo un poco larga, he de admitir que este hombre es un showman y me pareció un gran profesional, con el que tuvimos el honor de almorzar, muy simpático el chaval :-D He sacado algunos trucos pero me quedo con su frase más original "Un proyecto se hace en una semana, 5 días para pensar y 2 para programar" :-)

Descon2 Solo pude estar en las dos primeras desconferencias y he de admitir que aunque no tenían nada que ver con mi campo de conocimiento es una experiencia única, lo mejor que podéis hacer para entenderlo es acudir a su página web.

Otros eventos

No tuve la posibilidad de asistir a más charlas ni eventos de la TLP 2K10 pero cabe resaltar que hubieron talleres de Android, Windows Mobile 7, Cloud computing con Microsoft, Seguridad Informática, y muchos más. Vamos para todos los gustos.

Con respecto a la zona de Lan Party las cifras para una isla del tamaño de Tenerife son impresionantes, 1024 participantes, más de 16 Km de cableado, un total de 2 Gbps de salida, ¿alguien da más?

No todo ha sido bueno

La organización ha realizado un trabajo genial pero desde mi punto de vista se pueden mejorar algunas cosas y antes de que me llamen quejica o que me acusen de nada ... decir "públicamente" que me ofrezco como colaborador para la zona profesional en sucesivas ediciones, para que vean que también me muevo y no solo me quejo.

* Organización de las aulas: Estaría genial que en futuras ediciones se mantuviese cierta separación de las aulas porque debido a que son abiertas el audio de unas y otras se mezclaba.

* Calendario anticipado: Tener el calendario de las charlas con un tiempo de antelación de al menos un mes sería genial para los asistentes ya que se pueden organizar mejor, además estaría muy bien que las charlas estuviesen organizadas por temáticas como hacen en las grandes conferencias, de forma que te pierdas solo charlas de interés secundario para tí (aunque siempre puedes tener mala suerte).

* Acceso WiFi para todos los asistentes: Es común en esta clase de eventos que exista una WiFi abierta para todos los asistentes sin necesidad de estar haciendo gestiones. Además se intenta promover este evento entre las empresas y muchas personas de una empresa pueden requerir estar en contacto con la empresa en todo momento desde sus propios dispositivos.

Seguro que hay muchos más puntos en los que mejorar, si alguien que haya ido quiere hacer un comentario bienvenido sea, y si alguien que haya asistido al taller de Integración Continua nos da feedback seguro que haremos buen uso de él (podéis ponernos a parir ya sabemos que no somos los sucesores de Martin Fowler). Creo que esto es todo y nos podemos despedir de la TLP hasta el próximo año.

Presentación de la TLP2K10

2010-07-23T21:44:00.001+01:00

En la mañana del día de hoy, mi colega Fran Reyes y yo hemos realizado un taller sobre Integración Continua en la zona profesional de la Tenerife Lan Party 2K10 y habíamos prometido a los asistentes colgar la presentación en algún lado, y ese lado es ... este enlace a SlideShare :-)

Integración Continua - TLP+i 2K10

View more presentations from Yeray Darias.

En el fin de semana y cuando haya finalizado la TLP 2K10 haré un resumen de mis experiencias en la zona profesional y algunas reflexiones (o chorradas, según se mire) que tengo en mente.

Integración continua en entornos Java (1ª parte)

2010-06-12T11:38:00.001+01:00

Requisitos iniciales

Hace unos días, mi colega Fran Reyes y yo, hicimos una charla/taller sobre integración continua en la 3ª reunión del grupo Agile-Canarias y como allí prometimos que íbamos a mostrar en el blog los pasos a seguir para montar tu propio servidor de integración continua, y como lo prometido es deuda, aquí va la primera entrega, los requisitos iniciales para comenzar :-)

Damos por hecho que todo el mundo tiene instalado en su máquina el entorno de desarrollo de Java (JDK 1.5 o superior) y un servidor Apache Tomcat, por lo que daremos esos pasos por supuestos. Por lo tanto continuaremos con las herramientas necesarias para poder avanzar en los siguientes capítulos.

Cliente SVN

Aunque no utilizaremos SVN como repositorio de código, es necesario tener instalado un cliente SVN para poder descargar el proyecto de prueba con el que trabajaremos. En casi todos los sistemas existe un cliente SVN de fácil instalación, por lo que continuaré explicando como descargar el código que vamos a utilizar en los ejemplos.

Crearemos una carpeta que utilizaremos como espacio de trabajo para montar el servidor de integración y en dicha carpeta haremos lo siguiente para obtener los fuentes de la aplicación Petclinic de Spring Source.



svn export https://src.springframework.org/svn/spring-samples/petclinic/trunk petclinic

Ahora deberíamos tener una carpeta en el directorio que hemos creado anteriormente cuyo nombre es petclinic y que contiene el proyecto que he comentado.

Apache Maven 2

Para todos aquellos que no conozcáis Maven basta resumir sus ventajas en unos pocos puntos.

Ayuda a gestionar el ciclo de vida de la aplicación, de forma que nunca se nos olvidará algún paso en la construcción de la aplicación a partir de los fuentes, como por ejemplo ejecutar los tests.

Gestiona las dependencias por sí solo, de forma que no es necesario que nos estemos ocupando de mantener una carpeta llena de .jars, el solo se los descargará cuando los necesite, en base a un fichero de configuración especificado por los desarrolladores.

Permite automatizar muchos pasos que hasta ahora generalmente se hacían de forma manual, como por ejemplo el despliegue de la aplicación en el servidor.

Permite tener distintos perfiles en función de si estamos en desarrollo o queremos generar una release para el cliente, entre otros.

Pero lo mejor será que busquéis información en la página oficial o en Google si estáis interesados.

El siguiente paso será proceder a la instalación de la última versión (estable claro) de Maven en nuestro sistema. En general basta con descargar el fichero de la página oficial y descomprimirlo en algún lugar de nuestra máquina (así de sencilla es la instalación de Maven). Si queremos disponer de Maven en la consola, que es lo normal, basta con incluir en el path del sistema la ruta hasta la carpeta bin de la instalación de Maven y listo.

Antes de continuar y para asegurarnos que Maven está instalado, se puede teclear en consola el siguiente comando.



mvn --version

Lo normal es que se obtenga una salida en consola similar a la siguiente. En caso contrario volved a leer el manual de instalación de Maven antes de seguir con el resto.



Apache Maven 2.2.0 (r788681; 2009-06-26 14:04:01+0100)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: es_ES, platform encoding: UTF-8
OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac"

Ahora que tenemos Maven instalado, podemos comprobar que la aplicación que nos hemos descargado de Spring Source funciona correctamente, para ello basta con teclear en la consola (posicionados en la raíz del proyecto) mvn clean package. Si todo va correctamente la consola se irá llenando con un montón de texto que ahora mismo no nos interesa (puede tardar un rato porque tiene que descargar las dependencias, a menos que ya las haya descargado anteriormente), hasta concluir con el mensaje BUILD SUCCESFUL :-) Como doy por sentado que ha ido todo bien, en la carpeta petclinic/target debe existir el fichero petclinic.war que es la aplicación compilada y lista para el despliegue. Por lo tanto ya hemos finalizado este punto y podemos continuar al montaje del repositorio de código. Antes de continuar es conveniente ejecutar mvn clean para no llevar basura hasta el repositorio de código.

Mercurial

Ya estamos en el penúltimo punto de los requisitos previos, el repositorio de código, que en este caso será Mercurial. En principio Mercurial nos permitirá tener un repositorio de código configurando unos pocos pasos, pero para todos aquellos que quieran aprender un poco más y conocer sus ventajas (que las tiene), les recomiendo los siguientes enlaces.

Mercurial: The Definitive Guide by Bryan O'Sullivan

Hg Init: a Mercurial tutorial by Joel Spolsky

La instalación de Mercurial es dependiente de cada sistema, pero en general es muy sencilla y la página oficial tiene toda la información. Una vez instalado podemos hacer una prueba como en el caso de Maven.



hg --version

Con lo que deberíamos obtener la información de Mercurial que debe ser algo parecido a lo siguiente.



Mercurial Distributed SCM (version 1.5.2+20100502)

Copyright (C) 2005-2010 Matt Mackall  and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

No es muy complicado ¿verdad?, pues ahora vamos a convertir la carpeta petclinic que hemos creado al inicio, en un repositorio de código Mercurial, para ello basta seguir los siguiente pasos. Aunque antes es necesario configurar en nuestra carpeta home el fichero .hgrc con el siguiente contenido (para los usuarios de Windows CREO que el fichero es mercurial.ini, lo podéis comprobar en el manual).



[ui]
username = yeray

Ahora Mercurial sabe quien es el usuario que está haciendo estas operaciones sin necesidad de especificarlo, por lo que ahora si que podemos iniciar el repositorio de código :-)



hg init

hg add

hg commit

Cuando hayamos completado la operación de commit (que requiere necesariamente un comentario) nuestro repositorio de código estará listo y podemos publicarlo mediante hg serve -n petclinic. Para comprobar que está publicado podemos abrir en nuestro navegador favorito la siguiente URL http://localhost:8000/ y debería aparecer la información del repositorio.

Por si hay algo que no se haya entendido hasta este punto, en el siguiente enlace podéis ver un video de los pasos que he explicado hasta el momento.

Vaya, ya está casi todo listo, ahora tan solo tenemos que instalar Hudson en nuestro servidor Tomcat y ya habremos terminado el capítulo de los requisitos previos.

Hudson

Es posible que esta sea la parte más sencilla de todas, porque Hudson viene directamente empaquetado en un fichero .war que podemos desplegar en nuestro servidor Tomcat sin necesidad de hacer nada más :-)

Cuando tengamos el Tomcat iniciado con Hudson corriendo podemos acceder a http://localhost:8080/hudson y configurar los siguientes puntos de Hudson.

Ruta del JDK en el sistema.
Ruta de Maven en el sistema.

Para acceder a ellos, basta con hacer click en la opción Adminstrar Hudson en el panel de opciones de la izquierda y luego en Configurar el sistema, con lo que deberíamos tener una pantalla similar a la siguiente, en donde configuraremos la información de nuestro sistema, de forma similar a como aparece en la imagen (otra opción aunque no es la que yo he seguido, es dejar que sea Hudson quien instale estas dependencias por sí solo como se puede ver en el menú cuando seleccionamos añadir).

Con configurar las opciones de Maven y el JDK nos vale, aunque para finalizar y dejar nuestro sistema listo, tendremos que acceder a la opción de Administrar Plugins en la pantalla de administración de Hudson e instalar el plugin de Mercurial. Es muy sencillo tan solo tenemos que seleccionar el plugin que deseamos y hacer click en instalar. Este plugin no requiere configuración especial por lo que hemos terminado por ahora :-P

En el siguiente post (que espero publicar en breve) hablaré de como configurar el proyecto en Hudson para construirlo de forma automática, y de los pasos para tenerlo enlazado con Mercurial y que se construya el proyecto en cada nueva revisión del código.

Implementación del patrón Singleton en Scala

2010-06-10T21:39:00.000+01:00

Saludos a todo el mundo (o todo el mundo que lea este blog). Como estoy un poco liado con otras entradas referentes a la charla de integración continua en Agile-Canarias, hoy hablaré de un tema sencillo que me ha surgido esta semana. Como implementar el patrón Singleton en Scala.

Para empezar y para todos aquellos que no sepan lo que es el patrón Singleton, se puede resumir en que es un patrón de diseño que permite mantener una única instancia de un determinado objeto. Esto es muy útil cuando se trata de un objeto cuya instanciación es muy costosa o simplemente porque modela un elemento que es único en la realidad.

A partir del diagrama de clase anterior nos podemos hacer una idea de su implementación en un lenguaje como por ejemplo Java, pero para que quede más claro, aquí va el código de un Singleton en Java :-) Esta sacado de la Wikipedia y es tan solo un ejemplo ilustrativo así que no le intentéis buscar un sentido más allá de ser un simple ejemplo (aunque como ejemplo funciona bien).


public class Singleton {

   private static final Singleton instance = new Singleton();

   ...
 
   // El constructor privado impide la instanciación
   private Singleton() {}
 
   public static Singleton getInstance() {
      return instance;
   }

   ...

}

Ahora bien, si en Scala no disponemos del modificador static, cómo vamos a hacer esto?!?!?!?! Pues es muy sencillo, igual que hacemos para simular los métodos estáticos, con la declaración object en vez de class, es decir.


object SingletonContainer {

   val singleton = ... ; // instanciación desde una Factoría

   def getInstance: Singleton = {
      return singleton;
   }

}

Como imagino que ya os habréis fijado, esta clase Java que yo he llamado Singleton, en la vida real tendrá más líneas de código referentes a su utilidad en el sistema que estemos implementando, pero para nosotros estarán contenidas en los puntos suspensivos (...) En Scala no es posible hacer un new Singleton, porque se trata de un object, pero podemos tener una factoría para crear una instancia del objeto deseado "de la clase Singleton", mientras que SingletonContainer sirve para mantener la referencia única.

Además como a todos nos gustar escribir poco, voy a dar una aproximación aún más corta a la implementación con Scala.


object SingletonContainer {

   val getInstance = ... ; // instanciación desde una Factoría

}

Más corto imposible :-) Pero seguro que muchos esto les suena raro porque el patrón Singleton suele ser autocontenido, es decir que no hay contenedor que instancia a otra clase mediante una factoría. Pues claro!!! Bien, por defecto en Scala un object es un Singleton en sí mismo, así que realmente no teníamos que hacer nada de nada, ¿por qué he hecho yo esto? Porque en algunos casos es simplemente necesario tener una instancia única que en realidad es de otra clase distinta, y este es el método más sencillo que he encontrado, de forma que mi código real es algo como lo siguiente.


object BaseSemanticModel {

  val getInstance = SemanticUtils.loadModelFromResourceFile(...);
  
}

De esta forma ahora tengo una instancia de Model (que es una clase de Jena, lo cual no viene a cuento ahora :-) que funciona como un Singleton en tan solo unas pocas líneas. Pero si BaseSemanticModel fuese la clase de la que quiero el Singleton, no tengo que hacer nada más que la implementación de la misma, porque luego la referencia a BaseSemanticModel es única y funciona como un Singleton en Scala.

Espero que me hayáis entendido, porque creo que ni yo mismo lo hago y que le sirva de algo a alguien.

Fé de erratas

2010-04-01T10:23:00.000+01:00

Buenos días. Desde que Carlos Blé colgó el podcast sobre Scala y tuve tiempo de escucharlo, he querido hacer una entrada en el blog para corregir alguna cosa que dije y que me he dado cuenta que no es verdad. Lamento que no haya podido ser antes, pero he estado algo liado con temas laborales, la organización de Agile-Canarias y la asistencia al curso de Flexibilidad con Scrum impartido por Juan Palacio y Claudia Ruata aquí en Tenerife.

Bien, entremos en materia. En la parte final de dicho podcast se está comparando brevemente y de manera superficial Scala con Groovy, y hay un momento en el que afirmo que Scala no tiene frameworks web como Grails en el caso de Groovy. Pues bien, ESO ES MENTIRA, lo siento mucho y acepto toda la culpa de haber hecho una afirmación tan categórica sin tener toda la información, pero como se suele decir, "rectificar es de sabios" (para ver si me quito algo de culpa :-)

He estado revisando la documentación y Scala tiene un framework similar denominado Lift, siento no poder hablar mucho de él porque todavía no he podido hacer una prueba del mismo por falta de tiempo. Pero, sin prometerlo :-), para redimirme de mi fallo, intentaré hacer una entrada sobre el mismo cuando sepa como funciona.

También recordar que, como en las películas, las opiniones expresadas por los asistentes al podcast son propias y Carlos no se hace responsable ni tiene porque compartir dichas ideas, al menos cuando es un fallo como el que yo he cometido :-) Por lo que os recomiendo que sigais escuchandolo porque está haciendo un trabajo fantástico.

Cambiando de tema y sin saber si es el lugar adecuado, tengo que decir que estoy muy contento de haber asistido al curso de "Flexibilidad con Scrum" de Juan y Claudia. Creo que ha sido todo un éxito y además de a los profesores, hay que felicitar a Gregorio Mena que lo ha organizado todo sin pedir absolutamente nada a cambio, muchas gracias Gregorio! Para finalizar agradecer a Juan una idea que nos a dado para organizar una pizarra de tareas en la empresa, cuando él haya creado la correspondiente entrada en su blog (para no pisarle la idea), haré una entrada para indicar como nos va a nosotros :-)

Podcast Scala + Groovy

2010-03-18T14:43:00.004Z

En la tarde de ayer me reuní con algunos colegas (Carlos Blé, Fran Reyes, Juanma Barroso y Fran Olmedilla) para hablar sobre la preparación de una reunión del grupo Agile-Canarias. Carlos aprovechando el impulso con el que venía de dar unas charlas en el Pais Vasco sacó su grabadora e hicimos un podcast sobre Scala y Groovy, aquí puedes encontrar el resultado.

Por favor no seais muy malos con las críticas aunque todas serán bien recibidas para intentar mejorar en el futuro :-P

Trucos al aplicar TDD

2010-03-01T18:47:00.003Z

La semana pasada estuve leyendo una entrada del blog "the urban canuk, eh" que trataba sobre Test-Driven Development y he de admitir que me parecio una entrada bastante interesante con una serie de consejos que considero recomendables. Me gustaría hacer un resumen de los puntos que me parecieron más interesantes.

Utilizar nombres consistentes en las clases de tests.

Es conveniente que todas la clases de tests tengan un sistema de nombres consistente y homogéneo, por ejemplo que todas ellas tengan nombres como <TargetClass>TestCase (es decir el nombre de la clase que deseamos probar seguido de TestCase), y no que una se llame LoginTest, otra RepositoryTestCase, o lo que es peor aún que incluso ni siquiera se haga referencia a que es una clase de tests. Esto logrará que cualquier persona que trabaje en el proyecto pueda localizar los tests de forma sencilla y rápida.

Usar los mismos espacios de nombre para tests y código a probar.

He visto más de una vez que hay mucha gente que coloca las clases a probar en un paquete y las clases de tests en otro paquete con nombre diferente, con esto no quiero decir que no sea posible o no se pueda hacer, pero creo que si se ha de evitar en la medida de lo posible. En mi experiencia personal he llegado a la conclusión de que la mejor práctica es dividir entre el código de tests y el código que se desea testear en dos localizaciones diferentes, por ejemplo /src para el código fuente y /test para el código de tests (por ejemplo separado en distintas carpetas de código). Pero la estructura de paquetes ha de ser la misma para facilitar la busqueda en caso necesario.

Usar siempre los mismos nombres para los métodos de setup y teardown.

Con JUnit hay una serie de métodos especiales anotados con anotaciones como @Before o @After y aunque el método puede tener un nombre seleccionado por el programador, es recomendable que los nombres seleccionados para estos métodos sean siempre los mismos para que el código sea lo más homogéneo posible.

Nombrar los métodos de test según la funcionalidad a probar.

Dado que en TDD el primer paso es crear los tests para luego crear el código fuente, lo más normal es crear los métodos de test con un nombre que indique la funcionalidad que se desea probar. En general, es común que un mismo SUT (subject under test) tenga más de un test asociado, por lo que usar el nombre de la funcionalidad a probar documenta mejor el sistema y da una idea más concreta de lo que hace.

Documentar brevemente los métodos de test más complejos.

Hay veces que el dominio en el que trabajamos es muy complejo y el test no queda absolutamente claro, en estos casos es necesario hacer un breve comentario de lo que se desea probar en el código, para que la persona que venga detras sepa lo que estamos haciendo.

Si necesitas utilizar más de un par o tres de línea para documentar un método de test o necesitas documentar absolutamente todo porque nada queda claro, planteate que a lo mejor estas haciendo algo mal y es mejor darle un par de vueltas antes de continuar.

No crees implementaciones antes de los tests.

Si creas una implementación y luego creas los tests para esa implementación, estas haciendo pruebas unitarias, pero eso no es TDD. Intenta crear los tests antes porque en caso contrario pierdes todas las ventajas que aporta usar TDD.

Para acabar me gustaría hacer algo de publicidad sobre el libro escrito por Carlos Blé y sus colaboradores, para todas aquellas personas interesadas en el tema de TDD :)

Mientras funcione ...

2010-02-01T12:50:00.001Z

Hace poco escuché a un desconocido decir algo como - Lo importante es que el código funcione correctamente no si se lee mejor o peor - no dudo ni por un minuto, que es mejor un código mal hecho que funcione, a un código perfectamente legible que no funciona. Dándole un par de vueltas y teniendo en cuenta que yo no había escuchado el resto de la conversación, imagino que lo que quería decir esa persona es que si el código mal hecho pero que funciona se puede hacer en 30 minutos en vez de en 60 es mejor, pero ahí si que discrepo totalmente.

Cuando estaba en la universidad, esa máxima era cierta, lo importante era tener la práctica terminada y funcionando (total, una vez corregida nadie la volvía a mirar). Pero cuando empecé a trabajar me dí cuenta de algo muy duro - algo me había comentado algún profesor pero de manera un poco abstracta y sin mucho detalle - ¡el software hay que mantenerlo!, ¿cómo?, a mi nadie me había enseñado eso, en que clase dieron esa parte?!?!?!

Pues sí, esa es la dura realidad, el software tiene un mantenimiento, y puede ser realmente caro si no se hacen las cosas correctamente desde el principio. Ese programador que tarda 30 minutos en hacer una funcionalidad X, dentro de 3 meses puede que tarde 5 horas en descubrir cual es el error de la aplicación simplemente porque no entendía su propio código (cuando es el suyo, porque si es de otra persona puede tardar 15 horas). Pero el programador que tardó 60 minutos, porque quería tener un código legible y usar patrones para que el código fuese más limpio, puede que tan solo tarde 1 hora en resolver el problema.

Aunque estas cifras no son científicas, creo que están muy próximas a lo que puede ocurrir en el mundo real, o simplemente a mi propia experiencia :) Con lo cual tenemos, que el programador tardó el doble en programar el método (lo que hace un total de 30 minutos de perdida), pero realizó la corrección del error 5 veces más rápido (lo que hace que gane 4 horas). Es pura lógica, yo prefiero ganar esas 4 horas!!!

Nota: Para todos aquellos que no realizan el mantenimiento de su propio código (y para que quede constancia, en general yo me encuentro en ese caso actualmente), estos consejos son igual de válidos. Si el código se mantiene facilmente, el cliente estará más contento y más contratos tendremos, además le haremos la vida más feliz a nuestros compañeros si son ellos los que mantienen el código, haciendo que nuestra empresa sea un sitio mejor. Y si lo mantiene otra empresa simplemente le harás la vida más feliz a otra persona que hará dicho trabajo, lo cual te hará mejor persona o mejorará tu karma, o cualquier otra explicación que te guste :)

Programación orientada a objetos más legible

2010-01-21T12:11:00.000Z

El año pasado llegó a mis manos casi por casualidad un libro titulado "The Thoughtwors Antology". Mirandolo por encima, uno de sus capítulos, escrito por Jeff Bay, me llamó la atención porque daba una serie de reglas para mejorar la calidad de nuestro código orientado a objetos en muy pocas páginas. A mi me gustaría comentar algunas de estas reglas en mi blog porque considero que son bastante útiles.

Esto no quiere decir que podamos evitar la lectura de libros (de gran calidad) dedicados al tema como puede ser "Clean code", pero nos permite tener una visión general para todos aquellos que no seamos expertos en la programación orientada a objetos.

Un nivel de indentación por método.

Dicho así de rápido y fuera de contexto puede resultar una regla un poco dura, pero en realidad hace referencia a la necesidad de tener métodos cohesivos y que realicen una única tarea. Una de las mejores métricas que he conocido en mi breve vida de desarrollador de software es esta, porque cuando un mismo método tiene más de dos niveles de anidamiento es que está haciendo algo más de lo que debería (esto no quiere decir que se cumpla en el 100% de las veces).

No hacer uso de la palabra reservada "else".

En mi experiencia de estudiante lo más importante de las prácticas es que funcionen, siempre tiene algo de importancia la calidad del código pero no se mira con mucho detalle (dependerá de la asignatura y el profesor). Pero cuando empiezas a trabajar, muchas empresas también buscan que el código sea sencillo y se entienda en una sola pasada, principalmente porque en el código trabaja más gente a parte de tí. Los bloques condicionales son una de las estructuras que más oscurecen el código fuente, por lo que es necesario simplificarlos lo mejor posible.

Pongamos el ejemplo siguiente.


public void deleteDocument(String docId) {
   Document document = getDocument(docId);
   if (document != null)
      database.delete(document);
   else
      throw new BlackboardException(...);
}

Utilizando esta regla podemos refactorizar al siguiente bloque, que en general resultará más sencillo de leer y por lo tanto de saber cual es su función (aunque el propio nombre del método debería aclararlo).


public void deleteDocument(String docId) {
   Document document = getDocument(docId);
   if (document == null)
      throw new BlackboardException(...);

   database.delete(document);
}

Hay algunos autores que incluso recomiendan evitar el uso de los bloques condicionales, haciendo uso de las propiedades de los objetos. Intenta hacer algunos ejercicios verás como la calidad de tú código mejora drásticamente.

Envolver todas las primitivas y strings.

Esta, en mi opinión, es una regla un poco controvertida, pero es igual de cierto que es una práctica común en Domain-Driven Design (DDD) porque hace los conceptos explícitos. Hay casos en los que el uso de primitivas se entiende perfectamente bien, pero hay casos en los que el uso de objetos valor (objetos que envuelven a la primitiva, en general extendiendola) puede aclarar el modelo de dominio y además hacer que el modelo se pueda evolucionar más facilmente en el futuro.

Utilizar un solo punto (.) por línea.

Aunque lo intento evitar en la medida de lo posible, es muy normal encontrar en muchos lugares de mi código cosas como ...


...
comprobarCodigoPostal(persona.getDireccion().getCodigoPostal());
...

Para mucha gente será obvio que no se está haciendo uso de forma correcta de la abstracción de los objetos. Sería más lógico y mucho más claro tener algo como ...


...
comprobarDireccion(persona.getDireccion());
...
comprobarCodigoPostal(direccion.getCodigoPostal());
...

Quizás el ejemplo no es el más claro del mundo, pero espero que se aprecie que evitando la utilización de más de una referencia por línea, el código es mucho más sencillo y manejable, además de representar su funcionalidad a primera vista.

No usar abreviaciones.

Robert C. Martin escribe en su libro que hay que llamar a las cosas por su nombre, y esto es básicamente lo que quiere decir esta regla.

Revisando mis prácticas de Universidad he observado la tendencia a abreviar todos los nombres de instancias o de métodos, en parte adoptado de un modelo de programación más funcional. Lo que ocurre es que cuando miro dichas prácticas unos años más tarde, ya no se lo que siginifican algunas variables llamadas t o x porque ya no tengo en la cabeza el modelo que estaba tratando en ese momento, pero aún puede resultar peor para una persona que jamas haya trabajado en el dominio del problema que estaba resolviendo.

Mantener las clases lo más pequeñas posible.

En esta regla Jeff Bay indica que las clases no deben tener más de 50 líneas de código y los paquetes no deben tener más de 10 ficheros. No creo que sea un regla que haya que seguir al pie de la letra, supongo que una clase puede tener 60 líneas sin que signifique que no es cohesiva. Pero es bueno que la usemos para preguntarnos si estamos siguiendo el camino correcto, porque una clase cohesiva se limita a una sola cosa y por lo tanto no debería necesitar una gran cantidad de líneas de código para realizar dicha cosa.

Nota: Todas estas reglas pueden ser aplicadas en gran cantidad de ocasiones, pero hay que tener claro que habrá momentos en los que no nos conviene o simplemente no podemos hacerlo porque el problema es demasiado complejo, por ejemplo.

Diseño ágil con TDD

2010-01-14T07:53:00.003Z

Hace unos días Carlos Blé ha publicado su libro, "Diseño ágil con TDD", posiblemente el primer libro en castellano de esta temática. Se puede descargar de forma gratuita desde la web del libro.

He tenido el placer de colaborar con él como revisor, por lo que he leido las versiones previas del libro unas cuantas veces, aunque sea por encima, y he aprendido muchísimo. Creo que habrá mucha gente a la que este libro le puede servir de ayuda y le puede ayudar a entrar en el mundo del desarrollo ágil de software.

Solo me queda felicitar a Carlos y al resto de coautores (he trabajado con dos de ellos personalmente, Gregorio Mena y Fran Reyes, y puedo asegurar sin lugar a equivocación que son dos grandes profesionales) por el trabajo realizado, esperando que en el futuro se produzcan más iniciativas como esta.

Log4j - JMS Appender con ActiveMQ

2009-10-27T16:00:00.000Z

Como todos sabemos (y si no es así lo sabemos ahora), log4j permite usar topics JMS como destino de la información de log, en mi caso estoy acostumbrado a usar ActiveMQ como implementación de JMS por lo que será la que utilice para explicar el proceso, aunque se puede inferir el proceso para otras implementaciones de JMS como JBoss o WebLogic que son de las más utilizadas en la documentación que he visto.

Para utilizar ActiveMQ como destino de tus mensajes de log, necesitas configurar el appender JMS adecuadamente. El código de ejemplo (obtenido de la página oficial de ActiveMQ) para lograr esto es el siguiente:


log4j.rootLogger=INFO, stdout, jms

## Be sure that ActiveMQ messages are not logged to 'jms' appender
log4j.logger.org.apache.activemq=INFO, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %-5p %c - %m%n

## Configure 'jms' appender. You'll also need
## jndi.properties file in order to make it work
log4j.appender.jms=org.apache.log4j.net.JMSAppender
log4j.appender.jms.InitialContextFactoryName=
    org.apache.activemq.jndi.ActiveMQInitialContextFactory
log4j.appender.jms.ProviderURL=tcp://localhost:61616
log4j.appender.jms.TopicBindingName=logTopic
log4j.appender.jms.TopicConnectionFactoryBindingName=ConnectionFactory

Es importante tener en cuenta que no se esté logeando información de ActimeMQ con el JMSAppender, porque en otro caso nos arriesgamos a que se envíen mensajes sin que el sistema de colas esté arrancado. Para ello pasamos el log de ActiveMQ a otro appender diferente (en el ejemplo se puede observar como está asociado a la salida stdout).

Para que los recursos de ActiveMQ estén disponibles para Log4j tenemos que configurarlo mediante JNDI en un fichero jndi.properties de nuestra aplicación. Se puede partir del siguiente ejemplo (observar que en la página de ActiveMQ refieren un fichero de propiedades distinto, a mi no me funcionó, por lo que copio el que me funcionó a mi).


java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory

# use the following property to configure the default connector
java.naming.provider.url = vm://localhost

# register some queues in JNDI using the form
# queue.[jndiName] = [physicalName]
topic.logTopic = logTopic

Con estos pocos pasos hemos terminado, y ya tenemos configurado Log4j para que redireccione los mensajes de logging a colas JMS usando ActiveMQ como implementación de JMS.

Configurar un DataSource mediante JNDI en Spring

2009-10-24T01:36:00.000+01:00

Hoy he decido recuperar mi cuenta de Blogger he intentar colocar información útil (todo lo útil que una persona como yo pueda aportar :), y para empezar hablaré de como se configura mediante Spring un recurso JNDI en una aplicación.

Como es lógico el primer paso consiste en tener un recurso configurado mediante JNDI, en mi caso particular he configurado un "data source" de Oracle en Tomcat 6 (que basicamente es lo mismo que Tomcat 5 ó 5.5 por lo que he leído en el manual). Para ello en el fichero context.xml de la configuración de Tomcat hay que incluir un bloque de configuración similar al siguiente.


<Resource name="jdbc/myDB" auth="Container"
    type="javax.sql.DataSource"
    driverClassName="oracle.jdbc.OracleDriver"
    url="jdbc:oracle:thin:@localhost:1521:XE"
    username="scott" password="tiger"
    maxActive="20" maxIdle="10"
    maxWait="-1" />

Como la mayoría habrá visto, este bloque es simplemente la configuración de Oracle , y para que Tomcat pueda acceder a la base de datos debes tener en la carpeta de librerías de Tomcat el driver adecuado. Los ficheros que hayas de añadir a la carpeta de librerías van en función del recurso que estés configurando.

Llegados a este punto ya tenemos un recurso JNDI que tendrémos que configurar en nuestra aplicación para poder hacer uso del mismo. Como dice el título, esto lo haremos mediante Spring Framework (en mi caso la version 2.5.x, pero en versiones anteriores se hacía de manera similar). Para ello hay que añadir al fichero de configuración del contexto de aplicación (algo que por norma se llamará applicationContext-*.xml o similar) el siguiente bloque de código.


<bean id="dataSource"
     class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiName" 
       value="java:comp/env/jdbc/myDB" />
</bean>

Y con esto hemos terminado, reconozco que para empezar he elegido una tarea bastante sencilla, aunque con esto te ahorras tener que leerte los capítulos pertinentes de los manuales de Spring y Tomcat ;)