A software developer cookbook

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...

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

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...

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...

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 es...

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.

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....