Cierre y resumen del 2009

Finalmente este año 2009 llega a su fin. Ha sido un año que ha dado mucho de sí. Marcado, profesionalmente hablando, por La Crisis, Oracle compra Sun y el rugir de lo Ágil. Es tiempo de hablar con uno mismo, celebrar los éxitos, reconocer los errores, aprender de las experiencias y plantearse nuevas metas. Descansar el cuerpo y la mente, para volver ya el año que viene con renovadas fuerzas.

En lo relativo a este blog, me quedo con la espinita clavada de no haber superado el número de posts del año pasado. 35 el año pasado, por 34 éste. Por poco. Y eso que iba por muy buen camino, pero en Agosto me mudé y con el ordenador en el suelo, aún a falta de elegir mi despacho, se hace muy duro escribir.

Lo que sí han aumentado considerablemente han sido el número de visitas y el número de suscriptores. El primero se ha doblado (cerca de 35.000), aunque mucha culpa la tienen las visitas desde Google, y el segundo se ha quintuplicado (190). Pero lo que más me ha gustado han sido los debates que se han generado en algunos posts. Muchas gracias a todos.

El top 5 de los posts más visitados de este año ha sido (1) Buenas prácticas para desarrollar Servicios web SOAP, (2) Esquema de un Sistema de Gestión de Desarrollo Software, (3) Chuleta Maven, (4) 10 formas de mejorar tu código y (5) Programación basada en Google.

Una de mis nuevas experiencias de este año ha sido gracias a Jorge Rubira, que me invitó a participar en los podcasts Servicios web y Testing de aplicaciones de javaHispano. Fue un auténtico placer contribuir en ellos junto al susodicho, a Alfredo Casado, Leonardo de Seta y Jorge Luis Bugarín.

También me ha dado tiempo a hacer un experimento con AdSense. No es que quisiera monetizar el blog, simplemente tuve un ataque de emprendedor y quería ver, de primera mano, cómo funcionaba el tema de la publicidad en páginas web. De hecho, no ha llegado a generar ni 5 euros y no se cobra nada hasta que no se ganan al menos 70. En el próximo diseño del blog lo eliminaré.

Otra opción que estoy meditando es si pasarme a contractor o freelance y anunciar mis servicios por el blog. Ya veremos...

Llegados a este punto, sólo me queda desearos un Feliz 2010 y dedicaros un brindis por el talento.

Participación en el podcast Testing de aplicaciones de javaHispano

En javaHispano han publicado las dos partes del podcast Testing de aplicaciones en el que tuve el enorme placer de participar durante una noche del ya lejano mes de Noviembre.

El podcast fue en realidad una intensa tertulia, junto a Alfredo Casado, José Luis Bugarín y Jorge Rubira, donde mezclamos la importancia y ventajas del testing automático de aplicaciones con experiencias, buenas prácticas, técnicas, frameworks y herramientas.

La primera parte se centra más en introducir el testing automático, los tipos de tests, buenas prácticas y la metodología TDD.
Mientras que en la segunda parte se tratan herramientas y frameworks concretos, principalmente del mundo Java, para terminar comentando cómo explotar el testing al máximo desde un entorno de integración continua.

Poco más que añadir a lo contado en el podcast y comentado en javaHispano. Sólo volver a animaros a dar el salto a hacer testing a los que aún no lo habéis hecho. Merece la pena.

Espero que os haya gustado.

Un test para todos tus mapeos Hibernate v2.0

El otro día uno de mis chicos me dió un tirón de orejas. Resulta que el test para probar todos los mapeos de las entidades Hibernate de un proyecto que publiqué en el pasado, no es correcto para la versión 3 de Hibernate. La culpa es del método iterate de Query, que si bien en la versión 2 de Hibernate hacía un select de todas las columnas, en la versión 3 sólo lo hace de aquellas que forman el identificador de la entidad.

Así que nueva versión del test, compatible con Hibernate 3 y un poco más sofisticada. Allá va.

public void testHibernateMappingsOk() {
boolean allOk = true;
Map metadata = sessionFactory.getAllClassMetadata();
for (Iterator i = metadata.values().iterator(); i.hasNext();) {
   EntityPersister persister = (EntityPersister) i.next();
   String entityName = persister.getEntityName(); 
   try {
      Query q = session.createQuery("from " + entityName);
      q.setMaxResults(1);
      q.uniqueResult();
   } catch (HibernateException e) {
      logger.warn("ERROR probando el mapeo de la entidad " + entityName, e);
      allOk = false;
   } 
}
assertTrue(allOk);
}

¿Agil o Agilista?

2009 es el año Agile. Se ha convertido en la nueva moda, en el nuevo hype y para algunos en la nueva gallina de los huevos de oro. Ha llevado un tiempo desde que se escribió el Manifiesto en 2001, pero finalmente Agile se ha convertido en una auténtica revolución que está llegando -mejor o peor- a todas partes.

Hasta en España -más vale tarde que nunca- se suceden los podcasts, encuentros, conferencias, cursos, seminarios y charlas. Por llegar, ha llegado hasta a las LanParties! Lo próximo será un Open Space en Madrid. Todo ello bien apoyado desde agile-spain, la Comunidad Agile en castellano.

Es una gran noticia. Está haciendo mucho ruido. Y eso es bueno. Es muy bueno. Porque ante todo, lo que Agile transmite es un mensaje. Un mensaje que informa de que existen mejores formas de desarrollar software y que por primera vez viene de abajo a arriba, desde la gente que sabe desarrollar software a la gerencia y a los clientes.

Mi experiencia

Éste es un mensaje con el que estoy totalmente de acuerdo y que intento llevar a cabo en todos los equipos y proyectos por los que he pasado en los últimos años. No ha sido fácil. Sin apoyos, autoformándome en mi tiempo libre e introduciendo los cambios poco a poco, sacando horas de donde se podía.

Primero adopé la visión y objetivo del Manifiesto y los Principios Ágiles.
Luego fuí aplicando muchas de las llamadas Prácticas Ágiles en el desarrollo de los proyectos, como el diseño y desarrollo dirigido a pruebas (TDD), automatización, integración continua, iteraciones, concepto de hecho, diseño simple y evolutivo, revisiones de código, retrospectivas y documentación inteligente o útil.
Finalmente he utilizado algunas de las técnicas de las Metodologías Ágiles para transformar la forma de organizar el trabajo del día a día y alcanzar un nivel de agilidad más completo.
Consiguiendo así evolucionar la forma de desarrollar software, haciéndo proyectos más estables, eficaces y adaptables a los inevitables cambios, para satisfacción del cliente y propia.

Hoy puedo decir que mis esfuerzos por ser Ágil me han ayudado a ser mejor profesional y, también, a formar equipos que desarrollan mejor software y con los que da gusto trabajar. Aunque aún me queda mucho por aprender y mejorar, hoy soy consciente de que estoy en el camino correcto. Hace unos años no podía decir lo mismo.

Peligro

Sin embargo, últimamente noto el mensaje excesivamente -casi exclusivamente- dirigido a la implantación de las Metodologías Ágiles y principalmente Scrum.

Conviene recordar que las Metodologías Ágiles no son metodologías de desarrollo software en sí, sino simplemente de trabajo. Scrum (pej) no define qué entregables debe tener un proyecto, no define ni siquiera tipos de proyecto, si se debe usar UML, Diagramas Gantt, ni nada. Scrum es tan aplicable al desarrollo de software como a cualquier tipo de proceso divisible en tareas, pej. una mudanza! De hecho nuestro tan aclamado Scrum no es una metodología originalmente creada para el desarrollo de software.

En mi opinión, para poder usar una Metodología Ágil, primero es necesario que el proyecto tenga un nivel técnico alto, basado principalmente en automatización, pruebas e integración continua. Cómo podemos adoptar un desarrollo en iteraciones, si no tenemos modo de garantizar (al menos en parte) que el código que funcionaba en la iteración N sigue funcionando en la iteración N+1. ¿Mediante la repetición de fases de pruebas manuales? ¿Y eso es desarrollar mejor software?
Citando a mi colega Alfredo Casado: sin excelencia técnica no hay agilismo, sólo post-it pegados por las paredes. Y sinceramente el nivel técnico medio de los proyectos software a día de hoy deja bastante que desear.

Por otro lado, no puedo dejar de preocuparme cuando leo mucha de la publicidad que se le está haciendo a las Metodologías Ágiles y a Scrum. Cosas del tipo sólo existen 2 tipos de metodologías: en cascada y ágiles, o sólo hay 2 formas de desarrollar buen software: trabajar en la NASA o usar Scrum, o si no obtienes beneficio de aplicar una Metodología Agile es porque no lo estás aplicando en su totalidad, por tanto debes contratar un experto en Agile o Scrum es el remedio contra la crisis mundial. Por supuesto todo rodeado de los nuevos buzzwords de turno, que así como que engaña impacta más.

Todas estas falacias -y otras más- no hacen sino distorsionar el mensaje original (mejores formas de desarrollar software) y dejar una imagen de vendedor de teletienda que no hace ningún bien, y sólo puede generar desconfianza. Supongo que va asociado al hype, pero ¿qué tal si intentamos todos ser un poco más responsables?

También me preocupa -y mucho- el tema de las certificaciones en Scrum y el ansia de algunos por llegar a ser Agile Coach. Donde algunos ven la luz que iluminará el futuro, yo sólo veo una gallina; de huevos de oro, eso sí. Tiene toda la pinta de convertirse en el MBA de nuestro sector. Y si no, al tiempo.

En realidad Scrum no es aplicable a más de la mitad de los proyectos. Entre otras cosas, requiere una enorme disponibilidad por parte del cliente (el Product Owner es parte del equipo), equipos con dedicación absoluta y de alto nivel técnico y una sala de reuniones por equipo disponible a primera hora. Al final tienes que adaptar Scrum a tus circunstancias, pero entonces yo pregunto: ¿y no será más fácil adaptar la metodología que se esté usando para agilizarla? Ah no, que eso no sería cool.

Conclusión

¿Quiere ésto decir que las Metodologías Ágiles no aportan valor? En absoluto. Claro que aportan. Pero cada cosa en su sitio, sobre todo porque no siempre es posible y viable implantar una Metodología Agile oficial. Una Metodología Agile es la punta del iceberg, la guinda del pastel, debajo necesitamos una sólida base construida a partir del Manifiesto, Principios y Prácticas Ágiles.

No podemos dejarnos llevar por el hype de las Metodologías Ágiles, un hype que cada día tiene más parecidos con la religión que con desarrollar software, tanto por el fanatismo como por el negocio generado. De hecho hasta el nombre de Agilismo ha calado. Pero yo no quiero ser Agilista, yo no necesito creer en ninguna Metodología concreta ni en guías espirituales.

Yo quiero ser Ágil. Y se puede ser Ágil sin seguir fielmente una de las Metodologías Ágiles oficiales. Porque el valor de ser ágil es evidente: automatización, pruebas, integración continua, entregas periódicas de un software que funciona, equipos orgullosos y comprometidos con su trabajo, código de mejor calidad, documentación útil, respuesta frente a cambios en los requisitos, compresión y colaboración del cliente,... entre otros. Ésto sí son mejores formas de desarrollar software!

Tip Eclipse: Renombrar atributo junto a sus métodos get/set

Uno de los refactorings que más me gustan de Eclipse es el de Renombrar sobre el propio editor de código, sin necesidad de usar un diálogo o nueva pantalla. El genial Alt+May+R.

Pero como soy muy maniático con los nombres, muchas veces me da por cambiar el nombre de los atributos, por lo que tengo que ir a sus correspondientes métodos get/set y renombrarlos a mano. En el colmo de la perrería, a veces lo que hago es borrarlos y volver a generarlos automáticamente.

Ahora, con Eclipse 3.5 Galileo es mucho más sencillo. Basta con pulsar 2 veces el mismo atajo Alt+May+R sobre el nombre del atributo y aparecerá un diálogo con las opciones de renombrar también sus métodos get y set.


Encima tiene memoria y te guarda tus preferencias. Esta gente piensa en todo!

Cómo configurar el uso de memoria de un servidor en Eclipse

Antes de irme de fin de semana -qué ganas- dejo una chuletilla sobre cómo modificar la configuración de arranque y el uso de memoria de un servidor en Eclipse y en general.

Recuerda que la JVM usa 2 tipos de memoria. La memoria Heap donde se crean los objetos y que es gestionada por el GargabeCollector que se encarga de liberar memoria en caso necesario. Y la memoria PermGen que se utiliza principalmente para cargar las definiciones de las clases de forma permanente, pero también para trabajar con código nativo.

1) En Eclipse, ir a: Run -> Run configurations -> TuServidor -> Arguments -> VM Arguments

2) Para evitar el clásico java.lang.OutOfMemoryError: Java Heap space, usar las opciones de la VM:

-Xms64m
-Xmx256m

Es un ejemplo que asigna 64mb a la memoria heap de inicio y le permite crecer hasta un máximo de 256mb. Esta configuración debería ser más que suficiente si estás en desarrollo y sólo tienes una aplicación configurada para arrancar en el servidor. Antes de incrementarla, tómate unos segundos para meditar si el fallo pudiera ser causa de un memory leak.

3) Para evitar el igualmente clásico java.lang.OutOfMemoryError: PermGen space, usar las opciones de la VM:

-XX:PermSize=64m
-XX:MaxPermSize=128m

Es un ejemplo que asigna 64mb a la memoria perm de inicio y le permite crecer hasta un máximo de 128mb. De nuevo, este ejemplo debería ser más que suficiente si sólo tienes un par de aplicaciones configuradas en el servidor. Aunque todo dependerá del número de despliegues en caliente que realices habitualmente sin reiniciar el servidor.

Otra opción es intentar que el garbage collector recicle la memoria permgen. Para ello prueba a activar el recolector concurrente con los siguientes parámetros:

-XX:+UseConcMarkSweepGC
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled


Finalmente un par de enlaces a las páginas oficiales de opciones de la VM y la guía de tuning del gc de la jvm 5.