Tratando de entenderlo

Empezando con Node.js

2011-12-30T23:56:00.005+01:00

El pasado día 27 de diciembre estuve en la charla organizada por el grupo MadridJS sobre Node.js y Heroku. Acudí porque había leído algo sobre el tema y tenía curiosidad por saber de qué trataba realmente este proyecto. En la charla se dió una explicación inicial de lo que es y para qué sirve e incluso se vió algún ejemplo real, pero además se habló de algunos otros proyectos y tecnologías relacionadas con Node.js, como es el manejo de WebSockets con la librería Socket.IO.

A partir de lo visto en dicha charla me ha picado la curiosidad y en lo últimos días he estado buscando información sobre Node.js para poder conocer algo más sobre este proyecto. Node.js lleva la programación en Javascript al lado del servidor. Es una plataforma que permite el desarrollo de servidores de alta concurrencia y que se ejecuta sobre la máquina de Javascript de Google V8. Se basa en el paradigma de programación orientada a eventos de entrada y salida de forma asíncrona.

¿Y cuál es la principal ventaja de Node.js? Pues su rapidez y el menor número de recursos que consume. Un servidor de Node.js se ejecuta en un único hilo y no crea un nuevo proceso o un nuevo hilo por cada petición entrante, con el consumo de recursos que esto supone. Sin embargo, las operaciones en Node.js se ejecutan de forma no bloqueante en base a eventos, por lo que se pueden aprovechar los tiempos muertos de las operaciones de entrada/salida para servir otras peticiones y aumentar la rapidez.

¿Que significa que las operaciones se ejecutan de forma no bloqueante y en base a eventos? Pues que todas las operaciones de entrada/salida se realizan de forma asíncrona. Cuando se llama a una operación de entrada/salida se le pasa una función callback que será el manejador del evento de ejecución y pasa a ejecutarse en segundo plano, continuando con la ejecución del programa. Cuando la operación de entrada/salida haya finalizado saltará el evento correspondiente y se llamará a la función callback que lo maneja, que dispondrá de la información recuperada y podrá trabajar con ella.

Además de los módulos que Node.js incorpora en su instalación, existen multitud de módulos adicionales que puedes ser usados, los cuales se pueden instalar a través de la herramienta de gestión de paquetes de Node.js: NPM (Node Package Manager). Dichos módulos permiten el acceso al sistema de archivos, bases de datos, ofrecen una implementación del patrón MVC... Dichos módulos están organizados según el estándar CommonJS.

En vez de incluir aquí un ejemplo de cosecha propia, voy a remitir a quien quiera profundizar más a “The Node Beginner Book”, un tutorial estupendo para iniciarse en Node.js y empezar a entender su forma de trabajar.

Otras referencias sobre Node.js:
Página oficial de Node.js
Node.js en español
Introducción a Node.js de Rafa Muñoz
Introducción a Node.js en debugmodeon
Understanding Node.js
How to Node
Understanding the Node.js event loop
Colección de enlaces sobre Node.js

La evolución de JavaScript

2011-12-23T18:36:00.011+01:00

En los últimos meses, y viendo la popularidad de JavaScript debido a fenómenos como HTML5 o NodeJs, me he propuesto ponerme al día con JavaScript, ese lenguaje que normalmente utilizo para hacer validaciones en mis páginas HTML, pero que, en realidad, permite mucho más que eso.

Lo cierto es que, debido al boom que está sufriendo este lenguaje, lo que más me está costando es saber cuál es el estado en que se encuentra y hacia donde se encamina. Por ello, sirva este post para recopilar las ideas que sobre ello he ido encontrando y para, a partir de él, seguir profundizando en el lenguaje y sus capacidades, tanto nuevas como antiguas.

JavaScript surgió como un lenguaje de script en el navegador que apareció por primera vez dentro de Netscape Navigator 2 allá por 1995, y que se basaba en el lenguaje CEnvi desarrollado anteriormente por Nombas.

Fue tal el éxito de JavaScript que Microsoft decidió incorporar su propia implementación de este lenguaje, llamada JScript, en la versión 3 de su navegador Internet Explorer.

Debido a los problemas que entrañaban las diferencias entre implementaciones, se envió la versión JavaScript 1.1 como propuesta a ECMA para su estandarización, que culminó con el estándar ECMA-262. Este estándar dicta la base del lenguaje ECMAScript a través de su sintaxis, tipos, sentencias, palabras clave y reservadas, operadores y objetos, y sobre la cual se pueden construir distintas implementaciones. La versión JavaScript 1.3 fue la primera implementación completa del estándar ECMAScript.

Actualmente, las implementaciones de JavaScript de los navegadores implementan la versión 3 del estándar ECMAScript, que data de 1999, y cuyas últimas mejoras han sido:

Soporte de expresiones regulares.
Nuevas sentencias de control.
Manejo de excepciones (bloque try-catch).
Definición de errores más precisa.
Formateo de salidas numéricas de datos.
Manejo de strings más avanzado.

Cuando en 2004 se empezó a trabajar en la evolución de JavaScript, surge la revolucionaria propuesta ECMAScript 4, que pretende convertir JavaScript en un nuevo lenguaje con nuevas reglas, principalmente introduciendo el tipado de variables y el concepto tradicional de clases e interfaces al estilo de lenguajes como Java.
Debido a la revolución que estos cambios en JavaScript suponían, surge ECMAScript 3.1 como contrapropuesta, que evita introducir nuevos conceptos y añade en su lugar características adicionales al lenguaje.

Finalmente se llegó a la decisión de enfocarse en la propuesta ECMAScript 3.1, que se ha cambiado de nombre, pasando a ser ECMAScript 5. ECMASCript 4 ha quedado relegada al proyecto Harmony. Harmony, que a su vez parece que pasará a ser ECMAScript 6, pretende incorporar a posteriori en ECMAScript 5 algunas de las mejoras propuestas inicialmente por ECMAScript 4.

Las características que se incluyen en ECMAScript5 son las siguientes:

Getters y setters.
Array extras y reductions.
Cambios en Object:
- Rediseño de los atributos internos de las propiedades.
- Introducción de métodos estáticos de Object, que permiten:
  - Acceder a la información del prototipo.
  - Manipular las propiedades de un objeto.
  - Crear objetos de forma dinámica.
  - Obtener los nombres de las propiedades.
  - Impedir que un objeto sea modificado.
- Cambios a las funciones:
  - Soporte nativo del function currying a través del método bind.
- Cambios en el objeto Date.
Soporte nativo de JSON.
Modo de ejecución strict, que define reglas de codificación más estrictas que el modo de ejecución estándar.

Los cambios que podrían ser introducidos en ECMAScript 6 se mencionan en esta charla de Dave Herman, ingeniero de Mozilla Labs y representante del TC39:

Módulos.
Ámbito a nivel de bloque (sentencia let).
Generators.
Proxys.
Destructuring assignments.
Rest y default arguments.
Name objects.
Iterators.
Array comprehensions.
String templates.
Hash tables y weak maps.

También parece que se podría incluir:

Constantes.
Clases y herencia.
Tipos Map, Set y StructType.

Algunos navegadores ya han ido incluyendo estas y otras mejoras del lenguaje, como se indica en estos datos obtenidos de Wikipedia:

Javascript 1.5 (Firefox 1.0, IE 8-, Opera 6, Safari 5-, Chrome 10-):
- ECMAScript 3.
- Constantes.
- Getters y setters.
Javascript 1.6 (Firefox 1.5):
- Array extras.
- Array y String Generics.
Javascript 1.7 (Firefox 2.0):
- Ámbito a nivel de bloque.
- Generators.
- Iterators.
- Array Comprehensions.
- Destructuring assignments.
Javascript 1.8 (Firefox 3.0, Opera 11.50):
- Expression closures.
- Generator Expressions.
- Array Reductions.
Javascript 1.8.1 (Firefox 3.5):
- Soporte nativo de JSON.
Javascript 1.8.2 (Firefox 3.6):
- Actualizaciones menores.
JavaScript 1.8.5 (Firefox 4, IE 9):
- 1.8.2.
- ECMAScript 5.

Referencias:
- JavaScript en Wikipedia.
- ECMAScript en Wikipedia.
- Presentación sobre ECMAScript 5.
- ECMAScript 5: The Definitive Slides.
- Otra presentación sobre ECMAScript 5.
- Video: "Changes to JavaScript, Part 1".
- Video: "Dave Herman: The Future of JavaScript (ECMAScript 6)"

Compresión y comprobación de archivos javascript desde Maven

2011-10-08T19:33:00.013+02:00

Estos últimos días he estado probando YUI Compressor Maven Mojo para la gestión de los archivos javascript de mis proyectos.

YUI Compressor permite, en primer lugar, comprobar la corrección del código javascript mediante JSLint. En segundo lugar, permite comprimir y ofuscar los archivos javascript, de forma que se reduce su peso y se dificulta la introducción de ataques a través del código javascript.

Todo ello, a través de la siguiente configuración del pom.xml:

<pluginRepositories>
 <pluginRepository>
  <name>oss.sonatype.org</name>
  <id>oss.sonatype.org</id>
  <url>http://oss.sonatype.org/content/groups/public</url>
 </pluginRepository>
</pluginRepositories>

<build>
 <plugins>
  <plugin>
   <groupId>net.alchim31.maven</groupId>
   <artifactId>yuicompressor-maven-plugin</artifactId>
   <executions>
    <execution>
     <goals>
      <goal>compress</goal>
      <goal>jslint</goal>
     </goals>
    </execution>
   </executions>
   <configuration>
    <jswarn>true</jswarn>
    <failOnWarning>false</failOnWarning>
    <nomunge>false</nomunge>    
    <excludes>
     <exclude>**/jquery.js</exclude>
    </excludes>
    <aggregations>
     <aggregation>
      <includes>
       <include>**/*-min.js</include>
      </includes>
      <output>${project.build.directory}/${project.artifactId}-
      ${project.version}/js/revistero.js</output>
     </aggregation>
    <aggregation>
    <includes>
     <include>**/*-min.css</include>
    </includes>
    <output>${project.build.directory}/${project.artifactId}-
    ${project.version}/css/revistero.css</output>
    </aggregation>
   </aggregations>
  </configuration>
 </plugin>
…
<build>

La configuración de los atributos jswarn y failonwarning hace que se realice la comprobación de los archivos javascript pero sin parar la ejecución en caso de error. El atributo nomunge indica que se debe ofuscar el archivo ("munge": Modify Until Not Guessed Easily).

Tanto la verificación como la compresión de los archivos se ejecutarán cada vez que se construya el proyecto mediante:

mvn package

O se despliegue con:

mvn jetty:run-war

Pero se pueden ejecutar de forma independiente. Para lanzar la compresión de los archivos javascript y css se ejecutará:

mvn net.alchim31.maven:yuicompressor-maven-plugin:compress

Y para realizar la verificación de los archivos javascript:

mvn net.alchim31.maven:yuicompressor-maven-plugin:jslint

Referencias:
YUI Compressor Maven Mojo
Minimizando el tiempo de carga: Maven YUI Compressor

Apprenticeship Patterns

2011-08-31T12:20:00.011+02:00

La Artesanía del Software es un enfoque del desarrollo de software distinto de la Ingeniería de Software tradicional. Está más orientada hacia las relaciones entre desarrolladores y clientes en busca de valor para los proyectos, y también hacia las relaciones entre los propios desarrolladores, favoreciendo el traspaso del conocimiento.

Este libro trata sobre el enfoque de la Artesanía del Software sobre el aprendizaje que debe realizar un desarrollador. Este aprendizaje no se limita sólo a la etapa inicial de formaciónsino que debe ser continuo a lo largo de toda la carrera profesional.

Los autores (Dave H. Hoover y Adewale Osinheye) han recopilado una serie de patrones que pueden guiar este aprendizaje y que, a continuación, trataré de presentar. Dichos patrones se presentan por capítulos según su intencionalidad:

Vaciando La Taza

Cómo iniciarse en el aprendizaje desde una postura abierta y receptiva, eliminando los prejuicios.

Tu Primer Lenguaje: Conocer un primer lenguaje es lo que servirá como base para todo el aprendizaje posterior.
El Cinturón Blanco: Hay que ser humildes y receptivos, conscientes de que para aprender algo nuevo hay que desprenderse en parte de lo que sabíamos.
Desata Tu Entusiasmo: El entusiasmo da energía a un aprendiz y a su equipo, por lo que es un valor que hay que fomentar.
Habilidades concretas: Una persona que está aprendiendo puede tener poco que ofrecer a un equipo de programadores expertos. Sin embargo, es necesario que pueda ofrecer algo para que se le acepte como un miembro más.
Expón Tu Ignorancia: Se debe hablar abiertamente de las carencias, y no engañar a nadie atribuyéndonos cualidades que no tenemos.
Confronta Tu Ignorancia: Las carencias identificadas se deben combatir. Esto aumenta el conocimiento y permite identificar nuevas carencias.
El Profundo Abismo: En determinados momentos es necesario llevar a cabo tareas que están aparentemente más allá de nuestra capacidad para poder crecer.
Refúgiate En Tu Competencia: Para ganar confianza en caso de vernos superados se dedicar un rato a tareas que se dominan.

Caminando Por El Largo Camino

El aprendizaje del desarrollo de software es un camino largo abarca toda la carrera profesional.

El Largo Camino: A lo largo de la carrera profesional la prioridad debe ser aumentar las habilidades, no en el beneficio económico ni el ascenso en la escala empresarial en sí mismo.
Oficio Más Que Arte: Hay que ser consciente de que se están construyendo herramientas que deben aportar valor a los clientes.
Motivaciones Sostenibles: Para poder llegar al final del camino, se debe trabajar sin sacrificar de forma permanente ningún otro aspecto importante de la vida personal.
Alimenta Tu Pasión: Durante algunos periodos puede que el trabajo del día a día no sea suficientemente gratificante, y habrá que buscar algo que permita mantener la pasión por el aprendizaje, ya sea en el trabajo o fuera de él.
Dibuja Tu Propio Mapa: Somos los únicos responsables de nuestra trayectoria profesional. Si nuestra empresa o equipo actuales no son favorables al aprendizaje, tenemos en nuestra mano cambiar estas condiciones.
Usa Tu Título: El título profesional es reflejo de la organización en la que nos encontramos. Un título que no refleja nuestra realidad es un síntoma de que debemos actuar para cambiar nuestra situación.
Permanece En Las Trincheras: Para aprender a desarrollar del software hay que mantenerse desarrollando, y no dejarse seducir por ascensos profesionales que nos separen de él, llevándonos, por ejemplo hacia la gestión.
Un Camino Diferente: Se puede aprender a desarrollar siguiendo muchos caminos, por lo que no se debe menospreciar a quién ha elegido uno distinto.

Auto-Evaluación Precisa

Hay que saber reconocer nuestra situación respecto del entorno en que nos encontramos, para poder actuar si se da el peligro de estancamiento en el aprendizaje.

Sé El Peor: Ser el peor en un nuevo equipo permite aprender cosas a costa del esfuerzo que supone ponerse al día.
Encuentra Mentores: Conseguir que alguien con más conocimientos nos supervise es la mejor manera de acelerar el aprendizaje.
Espíritus Afines: Gente con los mismos intereses nos ayudará a aprender, ofreciendo visiones alternativas, apoyo o nuevas oportunidades.
Juntar Los Codos: Aprender junto a alguien incentiva la comprensión y facilita la comunicación de aquello que se da por supuesto pero que supone la diferencia.
Barrer El Suelo: Si se es el miembro de menor experiencia en un equipo se deben aceptar las tareas menos llamativas para poder aspirar a tareas más complejas.

Aprendizaje Perpetuo

No se puede dejar de aprender porque la tecnología avanza y ofrece nuevas soluciones que debemos conocer en la medida de lo posible.

Expande Tu Ancho De Banda: Hay que abrirse a todas las fuentes de conocimiento disponibles (blogs, Twitter, listas de correo, grupos de usuarios, conferencias, libros, cursos…) para recibir información sobre aspectos distintos a nuestra experiencia.
Practica, Practica, Practica: Para poder aprender es útil practicar con ello en un entorno tolerante con los errores. Se puede practicar con ejercicios (katas) sólo o junto con otros desarrolladores (dojo). Una realimentación inmediata sobre los errores que podamos cometer es importante para poder corregirlos y aprender.
Juguetes Que se Pueden Romper: Se puede poner a prueba y aplicar lo aprendido construyendo sistemas con exigencias reales pero no críticos, tal vez para uso propio.
Usa La Fuente: Para reconocer buen código hay que haberlo visto antes. Leer código de otros permite entender la forma de desarrollar de otras personas y adquirir los mejores hábitos de ellas.
Reflexiona Mientras Trabajas: Periódicamente se debe reflexionar sobre las prácticas usadas y analizar si se pueden mejorarlas o cambiars por otras mejores. Como equipo, esto puede traducirse en reuniones retrospectivas sobre la marcha del proyecto.
Guarda Lo Que Aprendes: Guardando constancia de cómo se ha resuelto un problema se ahorra tiempo en el futuro cuando se vuelva a presentar.
Comparte Lo Que Aprendes: Esto permite la comunicación con otros desarrolladores con los mismos problemas.
Crea Ciclos de Realimentación: Sólo alguien distinto de nosotros puede evaluar de forma objetiva lo que estamos haciendo bien o mal.
Aprende Cómo Fallas: Identificar nuestros fallos permite afrontarlos o, si el esfuerzo fuese desmedido, aceptarlos y reconocer las tareas para las que no somos aptos.

Construye Tu Currículo

La necesidad de seguir aprendiendo será continua. Estos nuevos conocimiento s irán definiendo nuestro propio currículo.

Lista de Lecturas: Existe una enorme cantidad de libros que pueden resultar interesantes. Mantener una lista de estos libros ayuda a priorizar y registrar lo que leemos y hacerla pública la deja abierta a sugerencias por parte de otras personas.
Lee Constantemente: Leer de forma periódica permite adquirir un conocimiento aceptable de la tecnología y diferenciarse de la mayoría de quienes nos rodean.
Estudia Los Clásicos: Las referencias a clásicos del desarrollo del software son constantes y es importante leer estos libros para entender las referencias de otras personas.
Excava Más Profundo: El conocimiento superficial de varias tareas no es suficiente. Habrá casos en que haya que profundizar en una herramienta o lenguaje concreto en busca de la solución a un problema.
Herramientas Familiares: Para que los proyectos puedan desarrollarse según lo estimado no se puede innovar siempre. Hay que mantener un conjunto de herramientas constantes en las que basarse.

Personalmente, este libro me parece muy inspirador y me ha dado un montón de ideas sobre cómo afrontar mi carrera como desarrollador de software, al verme reflejado en muchas de las situaciones que en él se describen.

Los patrones que presenta, en ciertas ocasiones parecen sencillas e incluso evidentes. La complejidad está en saber combinarlos y aplicarlos en nuestro día a día.

Apuntes de XP

2011-06-13T15:36:00.013+02:00

Recientemente he estado leyendo el libro de Kent Beck "Extreme Programming Explained" y, lo que presento es este post, es el resumen que he hecho sobre el mismo.

XP es una metodología ligera para el desarrollo proyectos de software con requisitos variables o poco definidos. Pone énfasis en el código e introduce prácticas que permiten entregar el software a tiempo, reducir el riesgo, mejorar la respuesta al cambio, aumentar la productividad y hacer más divertido el trabajo en grupo.

El problema del desarrollo de software

El principal problema del desarrollo de software es el riesgo. XP propone soluciones para luchar contra los distintos tipos de riesgo que pueden existir en un proyecto:

Las iteraciones cortas permiten planificar mejor y reaccionar a los cambios.
Desarrollar primero las tareas de mayor valor acelera el retorno de la inversión.
Asegurar la calidad introduciendo pruebas automáticas permite hacer modificaciones de forma segura.
Probar constantemente el sistema permite encontrar defectos más rápido.
Involucrar al cliente mejora la especificación del sistema y las expectativas sobre él.
Otorgar mayor responsabilidad y respeto al programador reduce su frustración. Promueve el espíritu de equipo y crea un mejor ambiente de trabajo.

La Economía del Software

Se debe obtener el mayor valor haciendo la mínima inversión para obtener beneficios de la forma más rápida e incrementar la vida del proyecto.

Para ello, se estudian las distintas opciones de cada funcionalidad del proyecto (implementarla ya, descartarla o posponerla) y se calcula su valor según el beneficio original, el precio de la opción, el beneficio si se ejecuta la opción, el periodo de tiempo durante el que se puede ejecutar la opción y la certeza en el valor final.

Las cuatro variables que permiten gestionar un proyecto son: coste, tiempo, calidad y alcance. El alcance es la variable más potente. XP reduce el riesgo de retrasar el desarrollo de una funcionalidad y juega con el alcance centrándose en realizar aquello que está definido. Se puede modificar el alcance a medida que el proyecto avanza y el conocimiento sobre el producto deseado aumenta.

Se asume que el coste que implica un cambio en el proyecto aumenta exponencialmente según avanza el proyecto. Sin embargo, combinando tecnología y buenas prácticas, se puede conseguir un aumento prácticamente lineal del coste del cambio. Esta es la premisa principal de XP, según la cual las decisiones se deben retrasar hasta obtener la mayor certeza.

Para reducir el coste del cambio se debe usar un diseño simple, pruebas automáticas que puedan ejecutarse en cualquier momento y refactorización para modificar el diseño cuando sea necesario. Se pueden así realizar ajustes durante el desarrollo, de la misma manera que se realizan correcciones al volante cuando se conduce.

Valores, principios, actividades y prácticas de XP

Los 4 valores que dirigen el proceso de XP son:

Comunicación: la información debe fluir entre el equipo.
Sencillez: hay que hacer las cosas de la forma más sencilla posible.
Realimentación: hay que conocer el estado del proyecto en todo momento.
Coraje: ser capaz de tomar decisiones difíciles cuando sea necesario.

Los valores anteriores inspiran los principios que guían a XP:

Realimentación rápida: acelerando es el aprendizaje.
Sencillez: resolver los problemas de forma sencilla.
Cambio incremental: los cambios son más sencillos si se realizan poco a poco.
Abrazar el cambio: abierto a lo que depare el futuro.
Trabajo de calidad: si el trabajo no se hace bien, se pierde la motivación.
Enseñar a aprender: demostrar todo aquello sobre lo que no haya certeza.
Pequeña inversión inicial: manejando el alcance, no hacen falte grandes presupuestos.
Jugar para ganar: la confianza en la propia capacidad ayuda al éxito del proyecto.
Experimentos concretos: probar cada decisión para asegurar que es correcta.
Comunicación abierta y honesta: hablar del proyecto de forma directa y sincera.
Trabajar con los instintos de las personas, no contra ellos: a la gente le gusta hacer un buen trabajo. Hay que ayudar a que esto ocurra.
Aceptar la responsabilidad: A nadie le gusta que le digan lo que tiene que hacer. Es preferible que cada persona lo elija, pero como miembro del equipo, también debe asumir la responsabilidad de hacer lo que el equipo estime necesario.
Adaptarse de forma local: decidir qué cosas funcionan mejor en cierto entorno.
Viajar ligero: mantener pocas cosas, que sean simples y de valor.
Medida honesta: usar medidas significativas que reflejen el estado del proyecto.

Las actividades principales del proceso de desarrollo en XP son codificar, probar, escuchar y diseñar:

El código sirve para plasmar ideas y aprender sobre ellas a través de la comunicación.
El código puede ser probado para ver si cumple con lo esperado. Las pruebas automáticas permiten realizar estas pruebas una y otra vez asegurando el funcionamiento del sistema.
Para implementar las pruebas, el desarrollador escucha al usuario, que dice cómo debe funcionar el sistema, y al propio sistema, que da realimentación sobre el sistema y sus problemas.
A medida que el conocimiento evoluciona y se amplían las funcionalidades se revisa el diseño del sistema para poder satisfacer las nuevas necesidades sin afectar a las anteriores. El diseño consiste en organizar el sistema de forma que los cambios lo afecten lo menos posible.

Las actividades anteriores se realizan mediante las siguientes prácticas:

El Juego de la Planificación: en cada iteración los desarrolladores estiman las tareas y el cliente decide las prioridades, para seleccionar el conjunto de tareas a realizar.
Entregas cortas: entregar el mayor valor en producción lo más rápidamente posible.
Metáfora: se utiliza una historia sobre el funcionamiento del sistema, que comparte todo el equipo, para describir el funcionamiento del sistema y guiar el desarrollo.
Diseño simple: el sistema debe ser lo más simple posible en cada momento.
Pruebas: se crean pruebas unitarias y funcionales.
Refactorización: el sistema se reestructura constantemente, sin cambiar su comportamiento, para mejorar el diseño o la comunicación.
Programación en pareja: el código se escribe en pareja, aumentando la comunicación entre los miembros del equipo y otorgando realimentación inmediata.
Propiedad colectiva: cualquier miembro del equipo puede modificar el código.
Integración continua: el código se integra cada vez que se completa una tarea para mantenerlo estable.
Jornada de trabajo estable: XP supone un esfuerzo y se debe permitir el descanso necesario.
Contacto directo con el cliente: el cliente debe estar disponible en todo momento para responder preguntas sobre el sistema.
Estándares de codificación: se programa en base a reglas de codificación que mejoran la comunicación.

No son prácticas novedosas, sin embargo, al llevarlas a cabo de manera conjunta, unas se refuerzan a otras aumentando su potencia.

Gestión de proyectos en XP

La gestión del proyecto no puede ser cosa de una sola persona, nadie tiene conocimiento total del sistema. XP permite una estrategia de gestión descentralizada en la que el gestor sólo debe intervenir en situaciones que no se puedan resolver de forma distribuida.

A la hora de gestionar un proyecto debe existir tanto un perfil administrativo como uno técnico. El perfil administrativo se encarga de que se realice el Juego de la Planificación, de recoger métricas sobre el seguimiento del proyecto y mostrárselas a los interesados. El perfil técnico hace de consejero (coach). No toma decisiones técnicas, sino que ayuda a los de demás a tomarlas y colabora con ellos en el desarrollo. También es el encargado de velar por la buena marcha del proceso de desarrollo.

A la hora de realizar la planificación hay que separar las responsabilidades. Negocio decide el ámbito del proyecto y de las iteraciones, y las prioridades de las tareas. Desarrollo informa sobre las estimaciones de las funcionalidades y las alternativas técnicas. Desarrollo decide el proceso que va a seguir para el desarrollo y las prácticas que llevará a cabo.

La planificación se basa en las estimaciones que los desarrolladores hacen sobre las tareas que el cliente ha priorizado. Sólo se debe planificar en detalle la iteración actual, pero se puede planificar a largo plazo con menor detalle el resto de las tareas.

El objetivo de la planificación es el de maximizar el valor entregado al cliente en cada iteración. Para ello, el equipo de desarrollo deberá invertir lo mínimo posible poniendo el mayor valor en producción lo más rápidamente posible.

La planificación se realiza en las siguientes fases:

Exploración: trata de descubrir lo que debe hacer el sistema. Se escriben historias que describen lo que debe realizar el sistema, se estiman y, si fuesen demasiado grandes, se dividen en historias más pequeñas.
Compromiso: las historias se priorizan. A partir de la velocidad de desarrollo del equipo se elije el alcance del proyecto según el tiempo que se disponga.
Dirección: se realizan iteraciones de alcance restringido durante las que se pueden detectar nuevas historias que pueden ser incorporadas a la planificación. Se vuelve a estimar teniendo en cuenta la velocidad obtenida durante las iteraciones anteriores.

Desarrollo en XP

Durante el desarrollo, las prácticas principales son la integración continua, la propiedad colectiva del código y la programación en parejas.

La integración continua consiste en que los desarrolladores integren sus cambios cada pocas horas, manteniendo la corriente principal del desarrollo en sincronía. Gracias a las pruebas automáticas se verifica en todo momento que el sistema sigue funcionando, y gracias a la refactorización se transforma el sistema en elementos cada vez más pequeños e independientes, de forma que los cambios a realizar están mucho más localizados.

La propiedad colectiva del código hace que cualquiera pueda modificar cualquier parte del código cuando lo necesite. Para ello es preciso atenerse a unas reglas de codificación comunes que faciliten la comprensión del código a todo el equipo.

La programación en pareja obliga a programar, analizar, diseñar y probar de forma conjunta. Esto favorece la comunicación y el aprendizaje. Uno de los miembros se centra en programar, mientras que el otro piensa de una manera más estratégica. Hace que la gente se mantenga fiel a las prácticas de XP, puesto que hay cierta supervisión.

La disposición del entorno de trabajo debe favorecer el trabajo en equipo. Es importante tener espacios comunes donde el equipo pueda reunirse a debatir o donde programar en pareja.

Diseño en XP

En XP se procura tener en todo momento un diseño lo más simple posible. Se realiza una inversión inicial pequeña para proporcionar valor rápidamente, haciendo cosas simples que permitan evolucionar el diseño fácilmente.

El diseño comienza por el desarrollo de pruebas que verifiquen lo que tiene que hacer el sistema. Se irán desarrollando nuevas pruebas que verifiquen más requisitos. Si en el proceso se ve la posibilidad de simplificar lo ya hecho, hay que hacerlo. Así, la primera vez que nos encontremos con un problema, lo solucionaremos de la manera más rápida posible. Las siguientes veces, se trata de flexibilizar la solución para acomodarla a nuevas necesidades.

Lo más simple posible es aquello que comunique su función, no contenga código duplicado y tenga el menor número de clases y métodos.

En el diseño se pueden usar gráficos, pero hay que ser conscientes de que entrañan el riesgo de que la funcionalidad del sistema que definen pueden ser comprobada a través de ellos. Se pueden usar gráficos en los primeros pasos de un diseño y luego convertir el diseño a código para eliminar este riesgo lo antes posible.

La arquitectura del sistema se expresa a través de una metáfora que permite hablar sobre el sistema. Para obtener esta arquitectura se recoge un conjunto básico de historias y se cambiará a medida que el conocimiento sobre el sistema aumente.

Pruebas en XP

XP propone realizar las pruebas a la vez que el desarrollo. Antes de codificar una funcionalidad se debe crear una prueba que valide su funcionamiento. Como las pruebas son automáticas se pueden ejecutar en cualquier momento y verificar que el sistema sigue funcionando.

Las pruebas permiten aprender sobre el sistema. Son realizadas por los desarrolladores, pero también por los clientes, que escriben pruebas que verifican si el sistema cumple con el funcionamiento descrito en sus historias de usuario.

Comenzar con XP

A introducir XP en un nuevo entorno se debe hacer paso a paso, comenzando por aquello que suponga el mayor problema. Normalmente se empieza por las pruebas y la planificación. Es importante reorganizar el espacio de trabajo para favorecer la comunicación desde el primer instante.

Hay que cambiar la estrategia en las siguientes áreas:

Pruebas: las pruebas otorgan confianza en el código. Hay que ir introduciendo pruebas en el código existente a medida que sea necesario modificarlo por cualquier razón.
Diseño: XP provocará un aumento en la refactorización. No se debe realizar al mismo tiempo que se añade una nueva funcionalidad. Los objetivos de la refactorización deben ser identificados cuanto antes y ser abordados antes de avanzar en funcionalidades nuevas.
Planificación: se debe educar al cliente en las nuevas reglas que guían la planificación y convencerle para que escriba historias de usuario.
Gestión: una de las partes más difíciles es el cambio de mentalidad sobre la gestión del equipo. El gestor debe de dejar de tomar las decisiones que son responsabilidad de los programadores. Los programadores deben asumir la responsabilidad de su trabajo.
Desarrollo: se debe aprender a desarrollar en pareja y el entorno debe facilitarlo.

Ciclo de vida del proyecto en XP

El ciclo de vida de XP trata de adelantar cuanto lo máximo posible la puesta en producción de valor para el cliente, aunque sólo sea una parte de la funcionalidad. A partir de ahí, se irá incrementando el valor en las siguientes iteraciones.

En una primera fase de exploración se debe analizar la viabilidad del proyecto y estudiar su utilidad y si tenemos las capacidades necesarias para llevarlo adelante. Esta fase termina en el momento en que existen suficientes historias de usuaria para una puesta en producción.

En esta fase se explora la arquitectura del sistema a través de varias alternativas. Se exploran las tecnologías a usar para conocer sus límites y rendimiento. El cliente también debe aprender en esta etapa a escribir historias de usuario. Para ello debe recibir realimentación por parte de los desarrolladores hasta llegar al nivel adecuado.

En la fase de planificación se recogen las historias más valiosas que puedan servir para una primera puesta en producción y se trata de estimar la fecha. A partir de este punto se realizan varias iteraciones. En la primera iteración se tratará de asentar la arquitectura del proyecto y en las subsecuentes iteraciones se irán incluyendo las historias de usuario seleccionadas.

Posteriormente se pasará producción, para lo cual puede ser necesario hacer pruebas de rendimiento del sistema y refinarlo en base a los resultados.

A partir de este momento el proyecto está en la fase de mantenimiento, que es el estado natural de un proyecto en XP. En esta fase se incorpora nueva funcionalidad manteniendo la existente, manejando las altas y bajas en el equipo.

Cada nueva versión necesitará de una fase de exploración que puede implicar la refactorización de parte del sistema. También hay que responder a los problemas que puedan surgir en el funcionamiento normal del sistema, lo que puede disminuir la velocidad del equipo para aportar nueva funcionalidad.

El día en que el cliente ni tiene nuevas historias es el momento en que se debe redactar el funcionamiento del sistema para la posteridad. Este es el fin del proyecto. También se puede llegar al fin del proyecto porque éste no reporte la rentabilidad esperada.

Roles en XP

En un equipo XP existen los siguientes roles:

Programador: programa y comunica sobre lo que hace. Debe buscar la sencillez del sistema. Es miembro de un equipo que le ayuda a mejorar.
Cliente: decide lo que debe hacer el sistema en función de la información de que dispone y la que le da el avance del proyecto. También se encarga de escribir las historias que debe cumplir el sistema y crea pruebas para comprobarlo.
Probador (tester): ayuda al cliente a escribir y ejecutar las pruebas funcionales. Puede ser un programador.
Rastreador (tracker): recoge las estimaciones, verifica su cumplimiento e informa al equipo.
Consejero (coach): vela por el cumplimiento del proceso. Su trabajo disminuye a medida que el equipo madura y se hace responsable del proceso.
Consultor: aporta conocimiento técnico al equipo en un determinado momento, pero no resuelve el problema por ellos.
Jefe: responde a las necesidades del equipo para la realización el proyecto. Debe pedir explicaciones al equipo sobre su forma de trabajar y, si algo no tiene sentido, hacerlo saber para que el equipo lo corrija.

Observaciones generales

En XP es necesario realizar moderadamente bien el conjunto de todas las prácticas para empezar a obtener resultados notables. Esto es porque las prácticas se apoyan unas en otras y es esta conjunción lo que asegura el buen funcionamiento de XP.

Las prácticas de XP son simples, pero es difícil realizarlas de forma conjunta. Cuando hay problemas, se tiende a relajar la aplicación de las prácticas más exigentes y el proceso se desequilibra si no se corrige rápidamente. También se requiere humildad y coraje para reconocer lo que uno no sabe y preguntar por ello. Hay que estar dispuesto a colaborar.

En ciertas condiciones hay que descartar XP, como cuando tratamos con equipos grandes, clientes desconfiados o tecnología que no soporta el cambio. Estos casos dificultan o imposibilitan la aplicación de algunas de las prácticas de XP, desestabilizando el proceso de desarrollo.

Esto último es muy importante, puesto que por más que nos gusten las ideas que XP propone, puede ser contraproducente adoptar XP a ciegas en determinados entornos en los que pueden llevar al caos. Sin embargo, aunque introducir el conjunto de prácticas de XP no sea una buena opción, algunas de ellas son recomendables en sí mismas en el desarrollo de software, como la integración continua (hasta cierto grado), el uso de estándares de codificación y las pruebas auto

Referencias:

Extreme Programming Explained (Kent Beck)

The Mythical Man-Month

2011-03-18T13:57:00.009+01:00

Este libro, un clásico de referencia sobre la ingeniería del software, es una colección de ensayos en los que el autor, Frederick P. Brooks, expone sus experiencias como gestor en un gran proyecto de desarrollo.

Aunque se trata de un libro de hace más de 30 años, que refleja experiencias de un proyecto realizado 20 años atrás, este libro sigue resultando valioso. En lugar de centrarse en los ya obsoletos problemas técnicos del proyecto, se centra en los problemas organizacionales de los mismos, y en cómo gestionar a las personas involucradas en ellos.

A continuación, haré un resumen de cada uno de los capítulos que forman parte de este libro:

1. El pozo de alquitrán

Los proyectos de software con como un pozo de alquitrán, en el cual uno se adentra sin darse cuenta y, cuando comienzan los problemas, luchar contra ellos sólo hace que uno se hunda más.

No hay razón aparente para la dificultad de los proyectos, sino un cúmulo factores. Para conocer la naturaleza de este problema es necesario identificar la finalidad de la programación y las satisfacciones y dificultades que entraña.

Existen distintos productos de software en función su usuario final que requiere más o menos diseño, integración o pruebas, e implican diferentes grados de esfuerzo. Un producto que vaya ser usado por otros supone el triple de esfuerzo que un programa de uso privado. Un programa que va a ser usado dentro un sistema supone el triple de esfuerzo que uno que va a ser usado de forma independiente. Estas implicaciones son independientes entre sí, por lo que un producto de software que va a ser usado por sistema cuesta nueve veces más esfuerzo que un programa independiente de uso privado.

La programación proporciona la satisfacción de crear cosas complicadas que sean de utilidad para los demás. Es algo tan maleable que permite hacer casi cualquier cosa. Sin embargo, se sufre la necesidad de perfección y el estar trabajando con objetivos impuestos por otros.

2. El mito del mes-persona

La principal causa de fracaso de los proyectos de software es la desviación respecto a la planificación estimada. Esto se debe al optimismo a la hora de estimar por parte de los programadores, que no tienen en cuenta que las ideas iniciales pueden ser incompletas e incluso erróneas. Además se carece de datos fiables sobre las estimaciones, lo que hace difícil justificar estimaciones que vayan en contra de los intereses del gestor o del propio cliente.

A la hora de estimar, se suele caer en el error de creer que personas y meses son intercambiables. Se olvida que al añadir más personas a una tarea se incrementa el esfuerzo total necesario debido a la necesidad de reorganizar las tareas, de formar a los nuevos miembros y al aumento de la intercomunicación.

La ley de Brooks dice que: “Añadir gente a un proyecto retrasado lo retrasa más”.

Como regla general, Brooks propone repartir el tiempo de un proyecto de la siguiente forma: 1/3 para diseño, 1/6 para la codificación, 1/4 para las pruebas de componentes y 1/4 para las pruebas de sistema.

3. El equipo de cirujía

Los buenos programadores son mucho más productivos que los malos. Además, los equipos, cuanto más pequeños sean menos los problemas de intercomunicación tendrán.

Hay que favorecer el trabajo de los buenos programadores simplificando la comunicación dentro del equipo.

Los equipos pequeños son demasiado lentos para realizar grandes sistemas y, por otra parte, un equipo de mucha gente es costoso, lento e ineficiente, y produce sistemas que no están conceptualmente integrados.

Una solución es tener un equipo organizado en torno a un programador jefe a quien da apoyo, de la misma manera que un equipo de cirugía. De esta forma se logra mantener la integridad de un producto de un número reducido de mentes con la ayuda de unos cuantos colaboradores, reduciendo la comunicación de forma radical.

4. Aristocracia, democracia, y diseño de sistemas

La consideración más importante en el diseño de un sistema es preservar la integridad conceptual. La integridad conceptual otorga mayor facilidad de uso, y permite construir y probar el sistema más rápidamente.
Para lograrla, el diseño debe ser fruto de una sola mente o de un grupo reducido de mentes que están de acuerdo. La separación entre arquitectura e implementación es la forma de conseguir esta integridad conceptual en sistemas grandes.

Alguien debe controlar los conceptos fijando la arquitectura, pero ello mejora la creatividad en la implementación, puesto que permite enfocar el esfuerzo.

De cualquier manera, arquitectura (requisitos), implementación (diseño) y realización (programación) pueden discurrir en paralelo.

5. El efecto del segundo sistema

Una buena comunicación puede dar al arquitecto una lectura adecuada de los costes y al constructor confianza en el diseño, sin difuminar la clara división de responsabilidades entre ellos.

Para que el arquitecto pueda influir con éxito en la implementación debe tener en cuenta que:

Es el constructor quien tiene la responsabilidad de la implementación. El arquitecto solo sugiere.
El arquitecto debe ser capaz de sugerir una forma de implementar lo que especifica, pero debe estar preparado para aceptar cualquier otra forma igualmente válida.
Debe escuchar las sugerencias del constructor para mejorar la propia arquitectura.

El segundo sistema es el más peligroso, porque se tiende a sobrediseñarlo. Asignar a priori valores de memoria y tiempo para cada función ayuda a detectar el sobrediseño durante la implementación.

6. Pasar la Palabra

A la hora de redactar el diseño de un sistema, por grande que sea, es mejor que lo hagan pocas personas (preferiblemente una) para que el resultado sea consistente.

Se necesita tanto una descripción formal que aporte precisión como una descripción en prosa que aporte claridad. Una de ellas debe ser la de referencia y la otra servir como apoyo. Utilizar una implementación como definición es una fuente de problemas.

Es importante registrar y publicar todas las consultas de los desarrolladores a los arquitectos.

7. ¿Por qué cayó la Torre de Babel?

Si no hay comunicación cada uno hace sus propias suposiciones, provocando retrasos, desajuste funcional y errores en el sistema. Los equipos de deben comunicar de todas las formas posibles, tanto informal como formalmente.

Se debe especificar cuanto antes el conjunto de documentos a través de los cuales se producirá la comunicación formal en el proyecto. Esta documentación debe estar al alcance de cualquier miembro del equipo. Se debe actualizar constantemente y resaltar los cambios realizados respecto a la última versión.

Sin embargo, Parnas propone que nadie debe ver las interioridades de ninguna otra parte que no sea aquella en la que se está trabajando. Sólo se deben publicar las interfaces.

La organización debe encargarse de reducir la cantidad de comunicación y coordinación necesaria, mediante la división de tareas y la especialización en las funciones.

En cada proyecto se deben establecer dos roles, el productor y el arquitecto o director técnico, que requieren de distintas habilidades.

8. Apuntando para disparar

No se puede estimar el esfuerzo total de un proyecto estimando el tiempo de codificación y extrapolándolo a las demás tareas.

Tampoco sirve extrapolar la construcción de pequeños sistemas a proyectos de sistemas. El incremento en el esfuerzo es una potencia del tamaño del proyecto.

Hay estudios que dicen que los programadores sólo dedican el 50% de su tiempo a la programación y el resto a otras tareas.

Otros estudios sobre la productividad indican que ésta se mantiene constante en términos de secuencias elementales. La productividad se incrementa por 5 cuando se pasa a usar un lenguaje de alto nivel.

9. 10 libras en una bolsa de 5

Además del tiempo de ejecución, el espacio de memoria que ocupa un programa es su coste principal. Se deben establecer límites de tamaño en cada función para que los costes no se disparen.

Durante la implementación, los arquitectos deben velar por la continuidad de la integridad del sistema.

Para poder hacer un buen balance entre tiempo y espacio, el equipo debe estar entrenado en las peculiaridades del lenguaje de programación y de la máquina que se están usando.

Todo proyecto de programación necesita una librería de componentes estándar.

Los programas sencillos y rápidos son resultado de la innovación estrategia más que de una buena táctica. Esto se puede lograr a través del uso de un nuevo algoritmo o de rehacer la representación de los datos.

10. La hipótesis documental

Sólo unos pocos de todos los documentos del proyecto son el eje sobre el que gira toda la gestión del proyecto: objetivos, manual, calendario, presupuesto, diagrama de organización y situación física de los miembros del equipo.

El gestor debe formalizar este conjunto de documentos. Mantener estos documentos proporciona un mecanismo de vigilancia y alarma.

El gestor debe encargarse de que todo el mundo vaya en la misma dirección a través de la comunicación, y no tomando todas las decisiones. Solo una pequeña parte de las tareas del gestor están relacionadas con información que está fuera de su mente.

11. Planea deshacerte de uno

Cuando se pasa de un entorno protegido a uno de producción es necesario un paso intermedio de prueba. Al probar el primer sistema construido se suele comprobar que éste es demasiado lento, grande o difícil de usar, y que debe ser rediseñado.

Este rediseño se puede hacer de golpe o pieza a pieza, pero habrá que hacerlo de todas formas. Si se entrega el primer sistema, esto será en detrimento del usuario y del desarrollador que lo debe mantener. Por tanto, debe incluirse en la planificación el rediseño de la primera solución.

Las necesidades del cliente y la percepción de las mismas cambiarán a medida que avanza el proyecto. La maleabilidad del software hace que los requerimientos no dejen de cambiar porque los cambios se presuponen fáciles. Algunos de estos cambios son válidos y hay que estar preparados para poder afrontarlos. Las técnicas que nos permiten hacer esto son conocidas pero no son usadas.

Los esfuerzos de los desarrolladores son tentativas de satisfacer los requisitos, sujetos a modificaciones y, por tanto, hace que sean reacios a documentarlos.

Para acomodar una organización al cambio los miembros de los equipos de ben ser intercambiables y reubicables, tanto en la parte de gestión como en la técnica. Una posible solución es la propuesta organizar el equipo en torno a un programador jefe.

El mantenimiento del software consiste principalmente en reparar defectos de diseño, añadir nuevas funcionalidades y adaptarse a los cambios en el entorno o la configuración. El coste de mantenimiento de un programa es aproximadamente el 40% del coste de su desarrollo.

El número de errores encontrados aumenta con el número de usuarios. El número de errores a lo largo de la vida de un proyecto primero aumenta y luego se estabiliza.
Al corregir un error existe una alta probabilidad de introducir otros, por los que se debe disponer de casos de prueba que aseguren que esto no se produce.

Durante la vida de un proyecto el número de módulos se incrementa de forma lineal, pero el número de módulos afectados por las modificaciones se incrementa de forma exponencial. Toda corrección tiende a romper la estructura e incrementa la entropía y el desorden del sistema. Inevitablemente, se llegará a un punto donde la mejor solución es el rediseño.

12. Herramientas precisas

Todo proyecto necesita herramientas personalizadas, por lo que el gestor debe establecer la filosofía para establecer los recursos necesarios para su construcción.

Es necesario instrumentalizar las máquinas sobre las que se va probar para poder extraer resultados de ellas. A la hora de probar en la máquina es mejor repartir periodos separados de tiempo para los distintos miembros.

La documentación voluminosa introduce mayor complejidad al proyecto.

Se debe construir de forma temprana un simulador de rendimiento que analice el programa desde fuera, y hay que prestar atención a lo que dice.

Las mejores herramientas que existen actualmente (1975) son los lenguajes de alto nivel (aumentan el rendimiento y facilitan la depuración) y la programación interactiva (reduce el tiempo de respuesta en la depuración).

13. El todo y las partes

Una buena arquitectura hace que un sistema sea más fácil de usar, más fácil de construir y que tenga menos errores. Antes de empezar la construcción se debe entregar las especificaciones al grupo de test, que debe comprobar si está completa y es clara.

Diseñar de lo general a lo específico refinando la especificación paso a paso reduce los errores y permite volver atrás cuando sea necesario. Hay que usar una notación de tan alto nivel como sea posible en cada paso.

La programación estructurada es el diseño de programas formados por un conjunto reducido de estructuras de control.

Se demuestra que en la primera interacción de depuración se un progreso hace tres veces mayor que en las subsecuentes. La depuración de un sistema siempre lleva más tiempo de lo planeado.

Se debe empezar la depuración sólo cuando las piezas parezcan funcionar, en vez de adelantarlo a cuando se hayan detectado errores pero sigan sin ser corregidos.

Merece la pena construir código de apoyo para la depuración, que puede llegar a ser el 50% del código a depurar.

Durante la depuración se deben añadir los componentes de uno en uno. Es mejor introducir grandes cambio de forma poco frecuente porque esto introduce menos inestabilidad.

14. Vislumbrando una catástrofe

Los proyectos se retrasan día a día. Esto es difícil de reconocer, de prevenir y de arreglar. Para poder controlar un proyecto es necesario tener un calendario con hitos concretos y bien definidos y fechas identificables.

Diversos estudios han demostrado que las estimaciones no suelen variar hasta el arranque del proyecto, posteriormente se van reduciendo las sobreestimaciones y, tres semanas antes del fin estimado del proyecto, lo que cambian son las infraestimaciones.

La planificación de ruta crítica permite identificar que desviaciones son las que realmente importan. Se debe identificar esta ruta crítica lo antes posible.

Todo jefe necesita ser alertado de las excepcionen que precisen de acciones correctoras y que se muestre el estado del proyecto para su conocimiento. Esto es difícil puesto que los subordinados temen la intromisión del jefe en sus responsabilidades. Se debe disponer de técnicas de revisión que ofrezcan el estado del proyecto a todo el mundo.

15. La otra cara

La documentación para el usuario es tan importante como el propio producto. Es importante también para el autor como memoria de lo que se ha hecho.

Por regla general no se entrega una buena documentación porque no se ha instruido a los desarrolladores en cómo hacerlo de forma efectiva y económica.

La documentación crítica para el usuario se debe establecer antes de la construcción ya que contiene decisiones de planificación básica.

A nivel de documentación interna, para mantener la documentación actualizada es necesario incorporarla junto con el código fuente. Se debe explicar por qué las cosas son como son, no solamente cómo están hechas. Los lenguajes de alto nivel permiten técnicas de auto-documentación dentro del propio código.

16. No hay balas de plata – Esencia y accidente

El autor compara el desarrollo de software con los hombres-lobo, gente normal que se convierte de repente en algo fuera de control que solo pueden ser eliminados con una bala de plata. Sin embargo, no existen balas de plata para el software que den una mejora de un orden de magnitud en su desarrollo, aunque existen innovaciones que de forma conjunta sí pueden ofrecer esta mejora.

La construcción de software implica tareas complejas, acomodar sus estructuras conceptuales, y tareas accidentales, representarlas en lenguajes de programación.

Las dificultades esenciales del desarrollo de software son la complejidad, conformidad, variabilidad e invisibilidad a la hora de acomodar las complejas estructuras conceptuales que implica.

El desarrollo de software también implica tareas accidentales, que son la representación en lenguajes de programación.

Las mejoras de los últimos tiempos han estado enfocadas en solucionar las dificultades accidentales a través de:

Lenguajes de alto nivel.
Tiempo de ejecución compartido.
Entornos de programación unificados.

Sin embargo, la mayor parte del tiempo se dedica a acomodar estructuras conceptuales abstractas de gran complejidad y, por tanto, es esta tarea esencial la que se debe atacar. Se han propuesto las siguientes formas:

Avances en lenguajes de alto nivel.
Programación orientada a objetos.
Inteligencia artificial.
Sistemas expertos.
Programación automática.
Programación gráfica.
Verificación de programas.
Entornos y herramientas de trabajo.
Estaciones de trabajo.

Estas alternativas, aunque introducen mejoras, no han alcanzado los niveles esperados. Es necesario atacar la esencia del software elevando el nivel de abstracción que implica su desarrollo. Los avances más prometedores en este sentido son:

Comprar en lugar de desarrollar.
Refinado de requisitos y prototipado rápido.
Desarrollo incremental.
Encontrar y educar a los mejores diseñadores.

17. “No hay balas de plata” revisado

En este capítulo el autor rebate las críticas recibidas al artículo presentado en el capítulo anterior “No hay balas de plata”. Sobre todo aquellas que van contra el principal argumento del mismo (que no hay ningún avance en el mundo del software que pueda dar por sí solo una mejora de n orden de magnitud), para presentar la propia bala de plata de cada investigador de turno.

El autor se reafirma en la idea de que la complejidad es la mayor dificultad inherente al software, aunque la mayor parte de esta complejidad se suele deber a problemas de organización de la propia realidad que se intenta modelar. Esta complejidad se puede atacar aumentando el nivel de abstracción de los elementos utilizados y manteniendo en todo momento sistemas que funcionen y que incorporen nuevas funcionalidades de forma incremental.

Se introduce el enfoque a la calidad, que aumentaría de la productividad reduciendo el tiempo dedicado a la corrección de errores.

La productividad también aumenta con mejores equipos y herramientas de trabajo y el uso de la programación orientada a objetos (que promueve la modularidad, la encapsulación, la herencia y el tipado de datos). Aunque se lamenta de la poca introducción de la orientación a objetos y la reutilización.

18. Proposiciones de “El mito del mes-persona”

Este capítulo muestra una recopilación de las afirmaciones expuestas en el libro a modo de resumen.

19. “El mito del mes-persona” 20 años después

Este capítulo es una revisión del libro hecha tras 20 años por el propio autor. En ella expone los argumentos que mantiene tras este tiempo y aquellos en los que ha cambiado de opinión.

El autor mantiene que la integridad conceptual es el factor más importante para la facilidad de uso de un sistema. Esta integridad conceptual suele lograrse cuando el producto ha sido diseñado por una única persona, pero este enfoque no es productivo para grandes sistemas que sufren presiones competitivas.

En estos entornos es necesario tener un arquitecto (o un grupo de ellos organizados de forma jerárquica) que se encargue de la integridad conceptual de todos los aspectos del producto percibibles por el usuario. Además sus tareas estarán separadas de la implementación.

Otro peligro que se recalca en el desarrollo de sistemas es el de cargarlos de funcionalidades de mínimo valor que compliquen el diseño y el uso de los mismos. Se debe ser consciente de quienes son los usuarios y ponderar las nuevas capacidades que se introducen en función del mayor valor ofrecido al mayor número de usuarios.

En lo que sí cambia de opinión es en el consejo de que el primer sistema implementado deba ser desechado. Esto era una consecuencia de la aplicación del desarrollo en cascada, que asume que los pasos del proyecto avanzan uno a continuación de otro, y supone que todos se realizan de forma correcta. El sistema se construye de una sola vez y se asume que todos los errores se introducen en la implementación.

Un modelo de desarrollo incremental permitiría el refinamiento progresivo del sistema. Se puede construir un sistema inicial de funcionalidad limitada y, a partir del cual hacer crecer el sistema introduciendo nuevas funcionalidades. De esta forma se pueden adelantar las pruebas del sistema y se puede entregar un sistema que funciona cuando sea necesario, aunque de funcionalidad reducida.

En cuanto al ocultamiento de información que Parnas proponía y del que el autor desconfiaba, éste se retracta y asume que los programadores son más efectivos si no están expuestos a las interioridades de módulos que no son de su propiedad.

El avance en el desarrollo del software se producirá al aumentar el nivel de abstracción de los elementos que se utilizan. En este sentido se han dado los siguientes pasos:

La definición del ocultamiento de información de los módulos hecha por Parnas.
La aparición de los tipos de dato abstractos de los que pueden derivar otros objetos.
La programación orientada a objetos.

El hecho de disponer de clases diseñadas y probadas para ser reutilizadas es lo que permitiría elevar dicho nivel de abstracción.

La Ley de Brooks (añadir más gente a un proyecto retrasado lo retrasa más) ha sido refinada gracias a varios estudios, aunque se mantiene como una buena aproximación a la realidad. En realidad, añadir más gente a un proyecto retrasado aumenta su coste, pero no siempre lo retrasa.

Otra idea que se ha reforzado durante este tiempo es la importancia de las personas que forman parte de los proyectos, y cómo los factores humanos deben ser tomados en consideración. Es importante dar responsabilidades a la gente y no centralizar todo en una única entidad, puesto que esto fomenta la creatividad.

Se hace eco del avance en el campo de la informática y de la explosión del número de ordenadores. Esto ha cambiado la forma de desarrollar el software y creado una nueva industria, los programas empaquetados.

Respecto al futuro de la ingeniería del software, presume que, a través del conocimiento, será capaz de lidiar en el futuro podrá con la complejidad del comportamiento humano y los aspectos no lineales que introduce.

Clean Code

2011-01-05T12:33:00.017+01:00

Durante los últimos meses he estado leyendo y releyendo el libro “Clean Code: A Handbook of Agile Software Craftmanship” de Robert Martin. En este libro, el autor trata por qué hemos de escribir código limpio y cómo hacerlo.

Código Limpio. Este tema es algo que me interesa particularmente en estos momentos. Cuando eres un desarrollador con responsabilidades puntuales dentro de un proyecto y sin relevancia ninguna en cuanto a las decisiones que toma el arquitecto de turno, lo único importante es quitarte el muerto de encima cuanto antes para evitar las típicas preguntas de: ¿Cómo vamos (¿Vamos? Pero si lo estoy haciendo sólo yo…)? ¿En qué estado está esta tarea? ¿Qué pongo en el Project, 80%, 90%...? ¿Podemos hacer la entrega ya?

Sin embargo, cuando tienes cierto grado de responsabilidad sobre un proyecto y te interesa que su evolución no se complique es importante hacer entender a los miembros del equipo que la responsabilidad de cada uno va más allá de quitarse el muerto de encima, sino que cada uno debe hacer lo mejor que pueda por tener un código lo más comprensible posible. Al código comprensible es a lo que Robert Martin llama código limpio.

Este libro está dividido en tres partes:

En una primera parte, se explica qué es el código limpio y cómo llegar a él.
La segunda parte son ejemplos más complejos de refactorización de código en busca de código más limpio.
La tercera parte es una recopilación de pistas que ayudan a encontrar código que no está todo lo bien que debería estar y que debería ser refactorizado.

En este resumen del libro me voy a centrar en la primera parte de él, puesto que la segunda y la tercera parte son bastante directas.

Capítulo 1 - NOMBRES

La lectura del código es la actividad a la que se dedica más tiempo, incluso para escribir nuevo código hay que leer lo que ya hay escrito. Un mal código puede llegar a arruinar un proyecto, dificultando las modificaciones y alargando los plazos de entrega. El único responsable de ello es el programador que no se toma en serio su trabajo y no es profesional.

Para evitar estas situaciones se debe hacer un código limpio, pero, ¿qué es código limpio?. Según varios autores conocidos, las características del código limpio son:

Fácil de leer, expresivo y sencillo.
Probado mediante tests automáticos.
Hace una única cosa.
No existe duplicidad en él.
Utiliza el menor número de elementos posibles.
Realiza abstracciones de elementos similares.

Para conseguir un código limpio se debe prestar atención a cada uno de los elementos que componen un sistema a nivel de código: variables, funciones, clases, comentarios, tests y el propio sistema. Además existen una serie de aspectos, como son la diferenciación entre objetos y estructuras de datos, el comportamiento en los límites del sistema, el manejo de errores y la concurrencia que afectan directamente al código y a su comprensión. Capítulo a capítulo se va analizando cómo mejorar en cada uno de estos elementos

Tembién habla de la regla del Boy Scout “Hay que dejar el código mejor de cómo lo encontraste”. Esto va en la línea de la mejora continua del código y de la imposibilidad de hacerlo perfecto a la primera.

Capítulo 2 - NOMBRES

Un buen nombre da mucha más información que cualquier otra cosa. Para conseguir buenos nombres hay que usar nombres descriptivos y claros. Deben ser legibles y evitar codificaciones complejas.

Capítulo 3 - FUNCIONES

Una buena función es aquella de la que se puede inferir su comportamiento de un solo vistazo. Para ello deben ser cortas, hacer una única cosa y mantenerse dentro del mismo nivel de abstracción.

Es importante usar buenos nombres y reducir al mínimo el número de argumentos. Pero lo principal es eliminar toda la duplicidad.

Capítulo 4 - COMENTARIOS

Los comentarios no pueden maquillar el mal código. La necesidad de comentarios para aclarar algo es síntoma de que hay código mal escrito que debería ser rediseñado. Es preferible expresarse mediante el propio código.

Hay situaciones en las que los comentarios son apropiados, como cuando tratan de:

Aspectos legales del código.
Advertir de consecuencias.
Comentarios TODO.
Remarcar la importancia de algo.
Javadocs en APIs públicas.

Sin embargo, en el resto de los casos pueden llevar a confusión y deberían ser evitados.

Capítulo 5 - FORMATEO

El formateo afecta directamente a la legibilidad del código. El código se lee de arriba abajo y de izquierda a derecha. Los espacios verticales y horizontales permiten separar ideas y conceptos distintos.

Se debe mantener un estilo uniforme, y para ello se debe consensuar con todo el equipo las reglas de formateo. Las reglas elegidas no son tan importantes como el hecho de que todo el mundo se atenga a ellas.

Capítulo 6 - OBJETOS Y ESTRUCTURAS DE DATOS.

No todo se puede solucionar usando sólo objetos o sólo estructuras de datos. Hay que aprender a diferenciar en qué situaciones son más convenientes unos u otros. Los objetos esconden sus datos y exponen funciones que permiten manipularlos, mientras que las estructuras de datos exponen datos pero no tiene funciones que operen sobre ellos.

Capítulo 7 - MANEJO DE ERRORES

El código de manejo de errores oculta la verdadera funcionalidad del código. Hay que mantenerlo lo más separado posible de la lógica de negocio para no dificultar la comprensión de ésta última.

Para no complicar el manejo de errores hay que escribir los bloques try-catch-finally en primer lugar permite identificar los puntos del programa en los cuáles se puede producir una excepción. Se deben usar excepciones en lugar de códigos de retorno. Las excepciones deben proporcionar suficiente información sobre el error y el momento en que se ha producido. Además, las excepciones no comprobadas son menos invasivas a nivel de código.

También se debe evitar pasar null como parámetro de una llamada a un método o devolverlo como valor de retorno. Esto introduce complejidad adicional debido a las comprobaciones necesarias.

Capítulo 8 - FRONTERAS

Los sistemas dependen de paquetes de terceros o de componentes desarrollados por otros equipos. Hay que definir de forma clara la frontera entre el código y el exterior para poder acomodar de forma sencilla los futuros cambios, minimizando las partes de nuestro código que dependan de elementos externos.

Los tests ayudan a experimentar con el código externo viendo cómo puede cubrir nuestras necesidades. También permiten comprobar que las nuevas versiones de la librería siguen cumpliendo con nuestras necesidades.

Encapsular el conocimiento adquerido a través de los tests en un interfaz entre nuestro sistema y el código de terceros permite localizar en ún único punto las modificaciones debidas a posibles cambios en código que está fuera de nuestro control.

Capítulo 9 - TESTS UNITARIOS

En TDD los tests de seben escribir en primer lugar. Las 3 reglas de TDD son:

No se debe escribir código de producción hast que no se tenga un test unitario que falle.
No se debe escribir más de un test unitario que lo necesario para que éste falle.
No se debe escribir más código de producción uqe el necesario para que pase un tests unitario que fallaba.

Se debe dar la misma importancia al código de test que al de producción. Los tests permiten que el código de producción se pueda modificar sin temor a introducir nuevos errores, asegurando su mantenibilidad.

El número de assert por cada test debe ser lo más bajo posible. Se debe testear un único concepto en cada test, lo que permite ir aclarando los distintos conceptos progresivamente, mejorando el conocimiento sobre el código.

Las reglas FIRST sobre el código de test son:

Fast: Se deben ejecutar rápido y muy a menudo.
Independent: Las condiciones de un test no deben depender de un test anterior.
Repeteable: Se deben poder ejecutar en cualquier entorno.
Self-Validating: El propio test debe decir si se cumple o no, no debe hacer falta realizar comprobaciones posteriores al test.
Timely: Los tests se deben escribir en el momento adecuado, que es justo ante de escribir el código de producción, lo que permite escribir código fácilmente testeable.

Capítulo 10 – CLASES

Las clases se deben organizar situando en primer lugar las constantes públicas, después las variables estáticas privadas, variables de instancia privadas y, a continuación, los métodos. Los métodos privados se encuentran junto a los métodos públicos que los usan.

Se debe mantener la encapsulación de las clases. Las clases deben ser pequeñas y con un número reducido de responsabilidades. Se consigue una alta cohesión si todos los métodos de una clase hacen uso de todas sus variables privadas.

Las nuevas funcionalidades se deben de introducir extendiendo el sistema, no modificando el código existente. Las clases concretas contienen detalles de implementación y las clases abstractas expresan conceptos. La dependencia en clases concretas es un riesgo en caso de cambio. Según el principio de inversión de dependencia las clases deben depender de abstracciones.

Capítulo 11 – SISTEMAS

Es importante reconocer y separar las distintas responsabilidades de un sistema.

En primer lugar, se deben separar el proceso de construcción de un sistema de su uso. El proceso de construcción se encarga de crear y conectar entre sí los objetos necesarios para la ejecución de la aplicación. Se debe modularizar y separar de la lógica de ejecución, permitiendo una estrategia independiente para resolver las dependencias de la aplicación.

La inyección de dependencias permite que los objetos sólo se encarguen únicamente de la lógica de negocio. Un elemento contenedor se encarga de inyectar las dependencias de cada objeto de forma externa.

No se puede construir sistemas de forma correcta a la primera hay que ir implementando las historias de que se dispone, y después refactorizar y expandir el sistema para seguir implementando nuevas historias. TDD, refactorización y código limpio permiten esto a nivel de código.

A nivel de sistema, es difícil crecer de sistemas simples a sistemas complejos debido a las dependencias en la arquitectura que se usa. Para evitar estos problemas, se deben separar las distintos responsabilidades de un sistema. Para lograr esta separación se pueden usar proxys, frameworks AOP Java puros o aspectos AspectJ.

Se debe construir la lógica de la aplicación en base a POJOs a través de tests, e ir evolucionando de lo simple a lo complicado, interconectando los distintos aspectos necesarios.

Capítulo 12 – EMERGENCIA

Las siguientes 4 reglas dadas por Kent Beck permiten crear buenos diseños según se trabaja en ellos, conocer nuestro sistema y aplicar buenos principios de diseño:

Ejecutar todos los tests: Los tests verifican que el sistema se comporta según lo esperado. Al construir un sistema testeable se intenta que las clases sean simples y tengan un único propósito, y se trata de reducir el acoplamiento.
Eliminar la duplicación: La duplicación implica trabajo adicional, más riesgo y mayor complejidad.
Expresar la intención del programador: Usar un código lo más expresivo posible facilita el mantenimiento. Se deben escoger buenos nombres, funciones y clases pequeñas y tests bien escritos.
Minimizar el número de clases y métodos: Siguiendo las recomendaciones anteriores uno se puede exceder creando demasiadas clases pequeñas. Hay que tener cuidado y mantener un número reducido de clases.

Durante la refactorización de puede aplicar todo nuestro conocimiento para mejorar el diseño: aumentar la cohesión, reducir el acoplamiento, separar responsabilidades, reducir funciones y clase, escoger nombres mejores, etc.

Se dedicar tiempo a estas tareas después hacer que el software funcione. No se debe pasar a la siguiente tarea sin repasar lo hecho. Es imposible conseguir un código limpio a la primera, hay que repasarlo una y otra vez para conseguir mejorarlo progresivamente.

Capítulo 13 – CONCURRENCIA

La concurrencia es otro de los aspectos que pueden estar presentes en el código. Permite desacoplar lo que que ocurre de cuándo ocurre, y mejorar tanto el rendimiento como la estructura de una aplicación.

Desde el punta de vista estructural se puede percibir la aplicación como un grupo de computadoras colaborando entre sí, haciendo el sistema más fácil de entender y permitiendo separar las responsabilidades. La concurrencia permite mejorar los tiempos de respuesta y la eficiencia de una aplicación.

Se deben tener en cuenta las siguientes ideas sobre la concurrencia:

Introduce cierta sobrecarga.
Es compleja de manejar.
Los errores causados por ella son difícilmente reproducibles
Normalmente requiere cambios en el diseño.

El problema de la concurrencia es que los distintos hilos de una aplicación pueden entrelazarse siguiendo múltiples flujos de ejecución, lo que puede provocar problemas inesperados en situaciones normales.

Para defendernos de los problemas de concurrencia es importante que cada clase tenga una única responsabilidad,seperando la gestión de hilos se del resto del código. Hay que conocer las librerías que manejas y entender los distintos modelos de ejecución. Las secciones sincronizadas lo más pequeñas posibles.

Ejecutar pruebas de forma frecuente es la mejor manera de encontrar los posibles errores en el código. Sin embargo, es difícil hacer tests cuando hay concurrencia. Se deben tratar los fallos espúreos como posibles problemas de concurrencia e instrumentar el código para forzar la aparición de errores.

CONCLUSIONES FINALES

Todas estas buenas prácticas sobre cómo escribir código limpio se deben ejecitar de forma constante para adquirir buenos hábitos y ser capaces de hacerlo de forma natural. Siguiendo estas prácticas el autor nos promete conseguir un código con el que será mas fácil trabajar y hará mucho menos frustrante nuestro día a día.

Una idea que se repite en varios puntos del libro es que debemos de ser capaces de exprimir las capacidades de nuestro entorno de trabajo. Conocer nuestro entorno de trabajo nos puede simplificar enormemente nuestro trabajo, puesto que puede realizar por nosotros un montón de actividades de forma automática y nos ofrece una serie de ayudas que nos pueden ayudar en el día a día haciendo innecesarias algunas convenciones que sólo sirven para complicar el código.

Otra cosa que me ha gustado de este libro es la bibliografía en que se basa. No es excesivamente grande, pero me ha servido para sacar unas buenas recomendaciones sobre otros libros a leer:

Agile Software Development: Principles, Patterns and Practices, Robert Martin.
Implementation Patterns, Kent Beck.
Test Driven Development, Kent Beck.
Extreme Programming Explained: Embrace Change, Kent Beck.
Refactoring: Improving the Design of Existing Code, Martin Fowler et al..
Design Patterns: Elements or Reusable Object Oriented Software, Gamma et al..
The Pragmatic Programmer, Andrew Hunt, Dave Thomas.

La Técnica Pomodoro

2010-11-17T16:46:00.007+01:00

En una profesión como es la informática, nuestro mayor aliado se convierte también en nuestro mayor enemigo. Nos pasamos horas programando delante del ordenador, y éste no es sólo nuestra herramienta de trabajo, sino también una tentación constante para la distracción.

Cuando uno trabaja en un tarea necesita estar centrado en ella para poder realizarla de la mejor manera posible. Esto no se consigue si interrumpimos la ejecución de dicha tarea cada dos por tres porque nos ha llegado un correo o se nos acaba de ocurrir qué mirar en Internet.

Tampoco es bueno realizar una tarea de forma ininterrumpida durante horas, puesto que la concentración del ser humano disminuye a medida que pasa el tiempo. Por ello, parece ser mejor intercalar periodos de esfuerzo relativamente cortos con pequeños descansos que sirvan a nuestra mente para asimilar el conocimiento que hemos adquirido, descansar y permitirnos afrontar el siguiente esfuerzo con energía.

La Técnica Pomodoro, desarrollada por Francesco Cirillo, trabaja en esta línea de forma que aprendamos a manejar los esfuerzos personales de una forma que nos permita centrarnos en lo que estamos haciendo, llegar a establecernos un ritmo de trabajo constante y sostenible, estructurar las actividades a realizar de forma incremental y hacernos capaces de realizar planificaciones razonables sobre ellas.

Implementar la Técnica Pomodoro es sencillo, puesto que las herramientas que se necesitan son muy básicas:

Un reloj.

Una hoja dónde registrar las actividades a realizar en el día. Existirá en ella una sección donde registrar actividades urgentes que no estaban planificadas y hayan ido apareciendo.

Una hoja de registro de las actividades pendientes.

Una hoja donde se muestre información de análisi de los datos registrados.

También se pueden usar herramientas más elaboradas como hojas de cálculo o aplicaciones con bases de datos. Sin embargo, se recomienda usar el método más simple posible para que las herramientas no supongan un impedimento a la técnica en sí.

La Técnica Pomodoro tiene los siguientes objetivos, que se pueden ir logrando de forma recursiva mediante su aplicación:

Primer objetivo: Descubrir cuánto esfuerzo requiere una actividad

Éste es el primer objetivo de la Técnica Pomodoro. El esfuerzo se mide en periodos de 30 minutos llamados pomodoros: 25 minutos de actividad y 5 de descanso.

Una vez priorizadas las tareas a realizar en el día de hoy, extraídas de la hoja de actividades pendientes, se comienzan a realizar respetando los tiempos del pomodoro. Cada vez que se cumple uno de estos periodos se registra en la hoja de actividades del día, junto a la actividad que se estaba ejecutando.

Se deben respetar los periodos de esfuerzo de 25 minutos, no pueden durar menos ni más. Si no se llegan a cumplir los 25 minutos realizando la tarea, este intervalo no se considera válido. Si se cumplen los 25 minutos se debe parar y descansar durante 5 minutos. Tras cada 4 pomodoros se debe parar durante un rato más largo de unos 30 minutos.

Al final del día podemos evaluar el número de pomodoros que nos ha llevado realizar cada actividad y, por tanto, el esfuerzo invertido.

Segundo objetivo: Reducir el número de interrupciones

El mayor problema para la ejecución efectiva de un pomodoro son las interrupciones. Por ello, se deben establecer estrategias para eliminar tanto las interrupciones externas cómo las internas.

Las interrupciones internas son las provocadas por nosotros mismos y por la falta de capacidad para concentrarnos. Debemos hacer visible el número de éste tipo de interrupciones y hacer lo posible por reducirlo.

Para ello, cada vez que tengamos la tentación de interrumpir la tarea que estamos realizando para hacer otra cosa, se marca la tarea con un apóstrofe (‘) y se añade una nueva en la lista de actividades urgentes o en la hoja de actividades pendientes, según su urgencia, para que sea realizada posteriormente. Tras esto, debemos volver a la tarea que estamos realizando.

Las interrupciones externas son las provocadas por otra gente. Debemos conseguir que ocurran cuando nosotros queramos, dentro de lo posible. Si alguien viene a pedirnos que hagamos algo, debemos tratar de posponerlo para después si es posible.

Para registrar estas interrupciones, se pone un guión en la actividad que estemos realizando (-) y se añade una nueva tarea en la lista de actividades urgentes o en la hoja de actividades pendientes, según su urgencia, para que sea realizada posteriormente. Tras esto, debemos volver a la tarea que estamos realizando.

Una vez que sabemos qué interrupciones sufrimos, se pueden buscar estrategias para reducirlas al mínimo.

Tercer objetivo: Estimar el esfuerzo necesario para realizar una actividad

Con la experiencia acumulada hasta el momento debemos tratar de estimar el esfuerzo que requiere una actividad, de forma que podamos usar estas estimaciones para planificar nuestro trabajo diario.

La estimación de una tarea no debe ser mayor de unos 7 pomodoros. Hay que mantener tareas no desmasiado grandes puesto que las tareas pequeñas facilitan su estimación. Tampoco debemos tener tareas con estimaciones inferiores a un pomodoro. Para lograr esto debemos agrupar o dividir tareas según sea necesario.

Una vez estimadas las tareas, si vemos que durante la ejecución llegamos al número de pomodoros estimados sin haberla terminado, debemos hacer una segunda estimación del esfuerzo restante y, si fuese necesario una tercera. Si hacen falta menos pomodoros de los estimados continuamos normalmente.

Al final del día, a la hora de registrar lo que ha pasado, debemos resaltar las diferencias entre las estimaciones y la realidad. El objetivo en posteriores pomodoros será tratar de reducir las terceras y las segundas estimaciones y, por último, tratar de acertar en la primera estimación.

Cuarto objetivo: Aumentar la efectividad del pomodoro

En este punto, y con la experiencia adquirida, podemos decidir organizar la estructura del pomodoro de la forma que más nos convenga. Puede ser interesante utilizar los primeros minutos de un pomodoro para repasar todo lo hecho hasta el momento, y los últimos 5 para repasar lo hecho en éste pomodoro.

También se pueden organizar los grupos de 4 pomodoros reservando alguno de los pomodoros para tareas específicas.

Quinto objetivo: Definir una agenda

El hecho de establecer uan agenda permite definir límites respecto a las tareas a realizar. Esto permite separar el tiempo de trabajo y el tiempo libre, entendiendo el tiempo libre como algo necesario y beneficioso para que la persona vuelva a reemprender las tareas productivas con energía y concentración.

Una agenda también permite comparar los resultados obtenidos y comprobar si se ajustan a lo esperado para, en caso de lo contrario, poder tomar medidas correctoras. El hecho de registrar el número de pomodoros que finalizamos cada día permite organizar nuestra agenda en función de ello, sin caer en planes demasiado optimistas que se alejen de la realidad del día a día.

Impresiones personales

No he hecho más que empezar a utilizar esta técnica y este post no es más que una forma de reforzar lo aprendido, puesto que he utilizado la Técnica Pomodoro para gestionar mi tiempo durante el estudio y redacción de dicho artículo.

Sin embargo, durante este poco tiempo he percibido las siguientes impresiones al respecto:

La motivación de usarla era tratar de reducir las interrupciones. El fijarme periodos de trabajo sin interrupciones no demasiado largos me ha permitido limitar las visitas a Twitter, Facebook, Gmail… a los tiempos entre pomodoros, cuando hasta hace poco era algo que hacía continuamente casi de forma compulsiva mientras realizaba otras tareas.

Por otra parte, en otras ocasiones me he autoexpuesto a periodos excesivamente largos de trabajo continuado, lo cual me ha llegado a producir agotamiento y dificultad para concentrarme en las horas finales de la jornada laboral. El hecho de parar sistemáticamente cada cierto tiempo para descansar o, por lo menos, separar lo ojos de la pantalla, me está resultando beneficioso y me permite mantenerme con energía hasta el final de la jornada.

La sensación de aburrimiento o monotonía ha disminuído, aunque esto no puedo decir con seguridad si es por el uso de la propia Técnica Pomodoro o por el hecho de estar inmerso en un nuevo tema de estudio interesante. Esto ya lo iré viendo durante los próximos días.

La Técnica Pomodoro me obliga a mantener un registro de las tareas que he realizado durante el día, lo cual me permite saber en qué he invertido realmente el tiempo y cuánto he malgastado. Esto me está permitiendo organizarme mejor para aprovechar el tiempo.

El conocer el esfuerzo de las tareas realizadas me permite hacer estimaciones más realistas sobre las tareas a desarrollar. Sé a qué me puedo comprometer y evito la frustración por no llegar a alcanzar los compromisos.

También debo decir que es la primera vez que estoy usando una de estas técnicas de gestión personal del tiempo, puesto que parece que la Técnica Pomodoro no es la única. No puedo decir si es mejor o peor que otras, pero sí parece que el uso de una ayuda a la eficiencia personal.

Para terminar, recomendo que si estáis interesados os leáis el libro de Francesco Cirillo donde explica la Técnica Pomodoro, disponible gratuitamente en PDF.

Recursos
The Pomodoro Technique
La Técnica Pomodoro en Wikipedia
Aumenta tu concentración con la Técnica Pomodoro
La técnica Pomodoro
No sabes nada de la Técnica Pomodoro
Técnica Pomodoro extrema

Patrones de diseño: Strategy

2010-11-03T11:46:00.005+01:00

Este patrón permite que el algoritmo a ejecutarse se seleccione en tiempo de ejecución. Este algoritmo proporciona una familia de algoritmos, encapsula cada uno dentro de un objeto y los hace intercambiables. Esto permite que el algoritmo a ejecutarse varíe en función del cliente que lo use.

¿Qué ventajas proporciona el uso de éste patrón?

En primer lugar, es mucho más fácil comprender cada uno de los distintos comportamientos si su implementación está encapsulada en distintas clases, y no entrelazada en un único método. Esto permite de forma simple añadir nuevos comportamientos, y elminar o modificar los existentes.

En los casos en que existan varios objetos cuyo comportamiento sea parcticamente el mismo, esto se puede reducir a una única clase que haga uso de distintas estrategias. Esto reduce el uso de subclases y, por tanto, el acoplamiento entre ellas

¿Cómo se implementa este patrón?

Las posibles estrategias se ejecutan dentro de un objeto de contexto que se encarga de recuperar la estrategia apropiada para el cliente. Cada una de las estrategias implementa una interfaz que define la firma del método de la estrategia.

Vamo a ver un ejemplo que permita aclarar esto. Por ejemplo, en un banco existen distintos tipos de cuentas, para las cuáles se siguen distintos algoritmos a la hora de calcular sus rendimientos anuales. Un objeto encargado de calcular los rendimientos de las cuentas (en este ejemplo, éste sería el objeto de contexto) podría utilizar distintas estrategias para calcular el rendimiento de cada tipo de cuenta.

El siguiente diagrama representa el ejemplo anterior:

Si ahora se quisiese incluir un nuevo tipo de cuenta, por ejemplo una Cuenta Vivienda, simplemente habría que crear una nueva estrategia que implemente el algoritmo de cálculo de rendimiento y hacer que el objeto CalculadoraRendimiento relacione este tipo de cuenta con la estrategia adecuada.

De esta manera, se ha desacoplado el cálculo del rendimiento específico de cada tipo de cuenta, separando cada uno en una clase haciéndolos más claros de entender y más fácilmente modificables.

Referencias:
Strategy Pattern en Wikipedia
The Strategy Design Pattern
Patrón Strategy
Otros patrones de diseño

Patrones de diseño: Template Method

2010-10-28T16:27:00.007+02:00

Estre patrón define el funcionamiento general de un algoritmo en una operación de una clase, delegando en otras clases, a través de herencia o dependencia entre clases, la implementación específica de cada uno de sus pasos. Permite que estas clases redefinan ciertos pasos del algoritmo sin cambiar su comportamiento general, adaptandose cada una de ellas a una necesidad específica.

Una implementación clásica de este patrón es la que aparece en el libro “Design Patterns” del GOF, que presenta una clase abstracta en la que se define el comportamiento general de una operación en un método concreto que llama a su vez a otros métodos abstractos en los que se definen comportamientos más específicos. Distintas subclases pueden heredar de esta clase y especificar comportamientos diferentes para los métodos abstractos, permitiendo varias implementaciones que se puedan ajustar a cada necesidad.

El siguiente diagrama UML presenta un ejemplo basado en esta forma de implementación del patrón Template Method:

En él, una clase Juego define en su método jugar() el comportamiento general de cualquier juego, el juego comienza y cada uno de los jugadores va haciendo su jugada hasta que se cumple una condición que da fin al juego y se muestra el resultado. Estas operaciones se indican mediante métodos abstractos que deben ser implementados por cada juego específico de forma apropiada, como pueden ser el Parchis o el Ajedrez.

Sin embargo, al ser la herencia la forma de acoplamiento más fuerte que existe entre clases, en busca de una mayor flexibilidad se propone una implementación alternativa basada en la dependencia entre clases en lugar de la herencia.

El siguiente diagrama muestra un ejemplo de implementación del patrón Template Method usando la dependencia entre clases:

En él se muestra una clase plantilla JuegoTemplate con un método jugar() que define el comportamiento general de cualquier juego. Igual que antes, el juego comienza y cada uno de los jugadores va haciendo su jugada hasta que se cumple una condición que da fin al juego y se muestra el resultado. Estas operaciones son llevadas a cabo por una instancia de una clase que implementa la interfaz Juego, interfaz que especifica los métodosque deben ser implementados por cada juego específico. Las clases Parchis y Ajedrez implementan la interfaz Juego y definen el comportamiento específico de estos juegos.

Esta forma de implementar el patrón Template Method es el usado en Spring para proporcionar, por ejemplo, soporte en el acceso a JDBC o Hibernate, a través de sus plantillas JDBCTemplate o HibernateTemplate, que usan una instancia de una clase que implementa la interfaz DataSource y que encapsula el comportamiento específico de acceso a una fuente de datos.

Referencias:
Design Patterns (Erich Gamma, Richard Helm, Ralph Johnson, Hohn Vlissides)
Patrón Template Method en Wikipedia
Implementacion de pattern Template utilizando composición e inyección
The Template Design Pattern
Patrón Template Method
Otros patrones de diseño

Error extraño en Sonar con JFreeChart y Novell SecureLogin

2010-09-28T15:00:00.010+02:00

Durante algún tiempo no he podido visualizar los gráficos de las estadísticas generados en Sonar a través de JFreeChart en mi equipo del trabajo.

Revisando los logs de Sonar encontré las siguientes trazas:


2010.09.23 11:57:21 ERROR org.mortbay.log  Error for /chart
java.lang.NoClassDefFoundError: 
 Could not initialize class org.jfree.chart.JFreeChart
...
2010.09.23 11:57:21 ERROR org.mortbay.log  Error for /chart
java.lang.UnsatisfiedLinkError: 
 no sljava in java.library.path
...

Al parecer, el error es debido a que no encontraba la librería sljava.dll en la ruta descrita por la propiedad java.library.path, definida en el archivo wrapper.conf de la configuración de Sonar.

Esta librería es una librería de Novell SecureLogin, que tengo configurado en mi equipo y parace que es la instalación de este producto lo que provoca el error.

La solución ha sido tan sencilla como llevar la librería sljava.dll a la ruta de java.library.path. Ahora bien, ni idea de qué está pasando...

Patrones de diseño: Proxy

2010-08-31T12:59:00.010+02:00

Según la Wikipedia, el patrón Proxy se utiliza como intermediario para acceder a un objeto, permitiendo controlar el acceso a él.

Este patrón es ampliamente utilizado en frameworks cómo Hibernate o Spring AOP, permitiendo capturar las llamadas a objetos POJO y permitiendo insertar en ellas capacidades de persistencia para el caso de Hibernate, u otro tipo de aspectos como gestión de seguridad o transacciones para Spring AOP.

A continuación mostramos el diagrama de clases del patrón Proxy:

En este patrón se identifica una interfaz Subject, un objeto RealSubject que es el objeto al que se accede a través del Proxy. El objeto Proxy mantiene una referencia al objeto RealSubject y controla el acceso a sus métodos, intruciendo las capacidades adicionales que fuesen necesarias. Tanto la clase RealSubject como la clase Proxy implementan la interfaz Subject.

En Java es fácil crear proxies dinámicos en tiempo de ejecución a partir de la clase java.lang.reflect.Proxy. Veámoslo a través de un ejemplo.

Creamos una interfaz:

package com.roldan.proxy;

public interface Lector {
 public void leer();
}

Ahora creamos una implementación para esta interfaz:

package com.roldan.proxy;

public class LectorImpl implements Lector {

 public void leer(){
  System.out.println("Estamos leyendo...");
 }
}

En este momento, creamos el proxy para la clase LectorImpl:

package com.roldan.proxy;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class LectorProxy 
 implements java.lang.reflect.InvocationHandler {

 private Object obj;
  
 public static Object newInstance(Object obj) {
  return java.lang.reflect.Proxy.newProxyInstance(
   obj.getClass().getClassLoader(),
   obj.getClass().getInterfaces(),
   new LectorProxy(obj));
 }

 private LectorProxy(Object obj) {
  this.obj = obj;
 }

 public Object invoke(
  Object proxy, 
  Method m, 
  Object[] args) throws Throwable {
  Object result;
  try {
   System.out.println(
    "Antes de llamar al metodo " + m.getName());
   result = m.invoke(obj, args);
  } catch (InvocationTargetException e) {
   throw e.getTargetException();
  } catch (Exception e) {
   throw new RuntimeException(e.getMessage());
  } finally {
   System.out.println(
    "Despues de llamar al metodo " + m.getName());
  }
  return result;
 }
}

Esta clase, que usa el patrón singleton, crea dinámicamente un proxy para la instancia de la clase que se pasa a su método newInstance() gracias a las capacidades de la clase java.lang.reflect.Proxy.

El método invoke() de esta clase captura las invocaciones a este proxy y las redirige al objeto LectorImpl en lugar del que actúa, añadiéndolo funcionalidad adicional, que en este caso consiste en mostrar mensajes antes y después del método invocado.

Ahora podemos crear una instancia de este proxy y acceder a los métodos de la interfaz Lector que implementa:

package com.roldan.proxy;

public class PruebaLector {
 public static void main(String[] args) {
  Lector lector = (Lector)LectorProxy.newInstance(
   new LectorImpl());
  lector.leer();
 }
}

Si ejecutamos la prueba, obtenemos la siguiente salida por la consola:

Antes de llamar al metodo leer
Estamos leyendo...
Despues de llamar al metodo leer

Vemos que la llamada al método leer() gestionada por el proxy ha sido adornada con los dos mensajes adicionales.

A pesar de la sencillez de este ejemplo, el uso de proxies dinámicos permite la ejecución de tareas avanzadas en frameworks de gran complejidad como Hibernate o Spring AOP.

Referencias:
Patrón de diseño Proxy en Wikipedia
¿Cuál es el problema que resuelve el patrón de diseño Proxy?
Patrón de diseño Proxy en Adictos al Trabajo
Dynamic Proxy Classes
Otros patrones de diseño

Kanban y Scrum – Obteniendo lo mejor de ambos

2010-07-28T13:55:00.004+02:00

Tras un mes de vacaciones, volvemos a la carga con el blog. Voy a empezar por un libro cortito cuya lectura ya tenía en mente antes de ir de vacaciones y que continúa el tema de las metodologías ágiles, haciendo una introducción a Kanban en este caso.

Este libro es la traducción al castellano, realizada por el equipo de contenidos de Agile Spain del libro de Henrik Kniberg y Mattias Skarin “Kanban vs Scrum – a practical guide”.

En el prólogo de este libro, David Anderson expone que la idea principal de Kanban consiste en limitar el trabajo en progreso (WIP – Work In Progress), utilizando tarjetas (kanban) como indicadores de que nuevos bloques pueden ser incorporados en un paso del flujo de trabajo. Está basado en las ideas extraídas del sistema de producción de Toyota (TPS – Toyota Production System) y se engloba dentro de las metodologías ligeras (Lean).

También comenta que Kanban introduce una aproximación a la gestión del cambio. Se comienza a hacer Kanban comprendiendo el flijo de trabajo actual y estableciendo límites para el trabajo en curso en cada una de sus fases. El trabajo es arrastrado (pull) a través del sistema a partir de señales Kanban. Mostrando este avance del trabajo en un panel se hacen visibles las deficiencias en el proceso y permite su mejora y adaptación continua.

El propósito de este libro es introducirnos a lo que es Kanban, comparándolo con Scrum, y a cómo pueden ser útiles en nuestro entorno. Para ello, el libro se divide en dos partes, en la primera parte Henrik Kniberg compara Kanban y Scrum y en la segunda parte Mattias Skarin presenta un ejemplo práctico de aplicación de Kanban.

Como he dicho, en la primera parte, más teórica, se comparan Scrum y Kanban a través de los siguientes capítulos:

Bueno, pero, al fin y al cabo, ¿qué son Scrum y Kanban?: En este capítulo se resume de forma breve lo que es cada una de estas dos metodologías. Ya conocemos Scrum, así que sólo me detendré en las ideas principales de Kanban: visualizar el flujo de trabajo, limitar el WIP y medir el tiempo de ciclo para hacer que sea lo más pequeño y predecible posible.

Entonces, ¿cómo se relacionan Scrum y Kanban entre sí?: Scrum y Kanban son herramientas de proceso que porporcionan ciertas restricciones y directrices. Ambos son métodos ligeros menos restrictivos que los métodos tradicionales y muy adaptables, siendo Scrum algo más restrictivo que Kanban. Estas herramientas no son excluyentes y se pueden mezclar entre sí y con otras herramientas como algunas de las ideas de XP.

Scrum prescribe roles: Mientras que Scrum prescribe los roles de dueño del producto, equipo y Scrum Master, Kanban no establece ningún rol. Pero existe libertad para añadir los roles que se consideren necesarios.

Scrum prescribe iteraciones de tiempo fijo: Scrum está basado en iteraciones de tiempo fijo que determinan la cadencia del proyecto. En una iteración se combinan las actividades de planificación, mejora del proceso y entrega. En Kanaban no existen iteraciones, por lo que estas actividades se pueden realizar siguiendo cualquier estrategia.

Kanban limita el WIP por estado en flujo de trabajo, Scrum limita el WIP por iteración: Kanban limita el número de elementos al mismo tiempo en un estado del flujo de trabajo. En Scrum, el límite es el número de elementos en la pila del producto.

Ambos son empíricos: En Scrum y Kanban el proceso se puede controlar de forma indirecta a través de parámatros como el número de componentes del equipo, el límite de trabajo en curso, la existencia de iteraciones… Son empíricos en el sentido de que se espera que experimentes con el proceso y lo adaptes a tu entorno. A este proceso de mejora se le denomina “kaizen” en terminología Lean, y se trata de buscar una realimentación sobre el proceso que de información sobre cómo mejorarlo.

Scrum se resiste a los cambios durante la iteración: Scrum no permite modificar la pila del sprint durante el mismo, permitiendo al equipo mantenerse enfocado durante un periodo de tiempo suficiente. Kanban, en cambio, permite cambiar los elementos en la entrada del flujo de trabajo siempre que se respete el límte del WIP establecido.

El tablero sprint se limpia entre iteraciones: En Scrum, cuando finaliza un sprint, el tablero se limpia y todos los elementos son eliminados. En Kanban, el tablero no se limpia, los elementos simplemente van avanzando a través de las columnas.

Scrum prescribe equipos multifuncionales: En Scrum, el tablero pertenece a un equipo, y un equipo tiene todo el conocimiento necesario para llevar a cabo una iteración. En Kanban el tablero está relacionado con un flujo de trabajo y puede pertenecer a varios equipos de distintas funcionalidades.

Los elementos de la pila de producto deben caber en un sprint: En Scrum, si un problema es demasiado grande para caber en un sprint, éste se descompone. En Kanban, aunque es interesante tener elementos pequeños que minimicen el tiempo de entrega, no es obligatorio que estos se ajusten a un intervalo de tiempo específico.

Scrum prescribe la estimación y la velocidad: En Scrum los equipos estiman el tamaño relativo de cada elemento al que se comprometen, y sumando el tamaño de cada elemento se obtiene la velocidad. En Kanban no es necesario estimar, pero algunos equipos lo hacen para poder garantizar el tiempo de entrega promedio.

Ambos permiten trabajar en múltiples productos simultáneamente: En Scrum, la pila de producto podría completarse con elementos de varios proyectos. Esto mismo, se puede hacer también en Kanban.

Ambos son Lean y Ágiles: Ambos son sistemas de optimización “pull”, basados en procesos de optimización continuos y que priorizan la respuesta al cambio frente al seguimiento de un plan, entre otras características.

Diferencias menores: diferencias menos relevantes entre Scrum y Kanban son que Scrum prescribe una pila de producto priorizada, establece reuniones diarias y utiliza gráficos burndown. En Kanban se utilizan diagramas de flujo acumulativo que representan como el WIP afecta al plazode entrega.

El tablero Scrum vs. El tablero Kanban – un ejemplo menos trivial: En este apartado se muestran casos de utilización de un tablero Kanban en distintas situaciones. También se dan directrices sobre cómo aplicar los límites Kanban.

Resumen de Scrum vs. Kanban: En este apartado se resumen los parecidos y las diferencias entre ambos vistos en los capítulos anteriores.

La segunda parte es un ejemplo de cómo poner Kanban en práctica. Con ello, el libro es una introducción estupenda a Kanban, sobre todo para aquellos que ya han visto algo de Scrum y que se preguntan cuál es la diferencia entre ambas herramientas.

Referencias:
Blog de Henrik Kniberg
Página web de Navegapolis

Conceptos principales de Scrum

2010-06-17T10:31:00.004+02:00

Basándome en lo explicado en el libro de Henrik Kniberg “Scrum y XP desde las trincheras”, en este post lo que pretendo es recopilar y explicar brevemente los conceptos principales en los que se basa Scrum.

Vamos a separar por un lado las personas implicadas en un proyecto que sigue esta metodología y, por otro lado, los productos y tareas que hay que completar durante el proceso que Scrum propone.

En primer lugar las personas:

El cliente: Es la persona que solicita un proyecto de cara a satisfacer una necesidad propia o de su negocio.

El propietario del producto (Product Owner): Es la persona que hace de intermediario entre el cliente (no técnico) y el equipo y tiene capacidad de decisión sobre los requisitos a implementar.

El equipo: Es el personal técnico que se encargará de la realización del proyecto.

El Scrum Master: Es la persona conocedora del proceso Scrum que se encarga de orientar al equipo y al propietario del producto para que sigan el proceso determinado por Scrum. Si las personas involucradas en el proyecto ya conocen Scrum su labor puede no ser necesaria.

Y, en segundo lugar, los productos y tareas necesarias:

La pila de producto: Es una lista priorizada de requisitos o “historias” del cliente escritos usando su propia terminología, de forma no técnica.

Reunión de planificación del sprint: En esta reunión el equipo y el propietario del producto negocian sobre el alcance de cada sprint en base a las estimaciones y a la importancia de cada una de las historias de la pila del producto.

La pila de sprint: El la lista de historias sacadas de la pila del producto que conforman el alcance del sprint actual.

Reunión diaria de scrum: En esta reunión el equipo discute los problemas que se va encontrando a medida que el producto avanza y revisa sus estimaciones para poder llevar el seguimiento del avance del proyecto.

Demostración: Como colofón a cada sprint se debe presentar una demostración de aquello que se ha implementado, de cara a obtener retroalimentación sobre el proyecto por parte de los interesados que permita encaminar futuros sprints.

Retrospectiva: Al final de cada sprint se lleva a cabo una reunión que permite revisar qué se ha hecho bien y mal durante el sprint con el objetivo de mejorar el proceso.

Para terminar, resumiré de forma breve el proceso que define Scrum:

En primer lugar, el propietario del producto construye la pila del producto con las historias de usuario o requisitos del proyecto. La pila del producto no es algo invariable, será modificada a medida que avanza el proyecto y se clarifican los requisitos.

Antes de cada sprint, iteración de aproximadamente 3 o 4 semanas, el equipo y el propietario del producto se reunen para decidir que historias de la pila del producto se van a implementar en él. Estas historias a implementar forman la pila del sprint.

Durante el sprint, el equipo tendrá una reunión diaria de sprint, en la que se actualiza la evolución del proyecto y se tratan de resolver posibles problemas.

Al final del sprint, se lleva a cabo la demostración, en la que se exponen las nuevas funcionalidades implementadas durante el sprint.

Antes de comenzar un nuevo sprint, se lleva a cabo una retrospectiva que permite identificar posibles mejoras en la forma de trabajar.

Referencias:
Aplicando Scrum y XP
Metodologías ágiles
Qué es Scrum

Scrum y XP desde las trincheras

2010-06-15T18:01:00.007+02:00

Aunque ya lo he leído hace algún tiempo, ahora mismo siento la necesidad de releer el libro de Henrik Kniberg “Scrum & XP from the trenches” (“Scrum y XP desde las trincheras” en su traducción al español ) en busca de ideas que aplicar para tratar de incorporarlas en las nuevos proyectos que voy a comenzar.

En este libro, disponible para su descarga gratuita, Henrik Kniberg cuenta sus propias experiencias durante la implantación de Scrum en la empresa en la que estaba trabajando. En él expone sus ideas acerca de cómo usar la metodología de desarrollo ágil Scrum.

El libro, con prólogos por parte de Jeff Sutherland y Mike Cohn, consta de los siguientes capítulos:

Introducción: Según el propio creador de Scrum, Ken Schwaber, Scrum no es una metodología, sino un marco de trabajo y, por tanto, no dice exactamente qué es lo que hay que hacer. Sin embargo, en este libro, Henrik Kniberg sí que dice qué es exactamente lo que él hace para aplicar Scrum. A pesar de ello, previene de que Scrum es una metodología que debe adaptarse a la situación específica de cada proyecto.

Cómo hacemos las pilas de producto: La pila de producto es una lista priorizada de requisitos o “historias” del cliente escritos usando su propia terminología, de forma no técnica.

Cómo nos preparamos para la planificación de sprint: El propietario de la pila de producto debe tener ésta ya preparada para cuando se va a planificar un sprint. El propietario debe comprender todas las historias de usuario y asignarlas una importancia.

Cómo hacemos la planificación de sprint: La reunión de planificación de sprint es la actividad más crítica de Scrum. La meta de esta reunión es definir un objetivo, la lista de miembros del equipo implicados, la lista de tareas que se desarrollarán, una fecha de demostración y un lugar y hora para la reunión de scrum diaria. En ellas, el propietario de producto y el equipo negocian sobre el alcance de cada sprint en base a las estimaciones y a la importancia de cada una de las historias.

Cómo comunicamos los sprints: Es necesario informar a todo el mundo de qué está ocurriendo en cada sprint. Para ello, después de la reunión de planificación del sprint se debe redactar una hoja de información del sprint que recoja los objetivos que se han definido. Esta hoja debe publicarse para todo el mundo.

Cómo hacemos las pilas de sprint: Después de la reunío de planificación de sprint y antes de la primera reunión de scrum diaria, el Scrum master debe crear la pila de sprint. La pila de sprint es la lista de tareas que se realizan durante el sprint, con gráficos de avance de estas tareas (burndown). La forma más efectiva de mostrar la pila de sprint es mediante un tablón en la pared.

Cómo distribuímos la sala del equipo: Las discusiones más interesantes tienen lugar de forma espontánea delante de una pizarra donse se puedan pintar diagramas o gráficos de diseño. Los miembros del equipo se pueden reunir en frente de esta pizarra y discutir sobre el diseño en cualquier momento. También es importante que los miembros del equipo se sienten junto para fomentar la comunicación entre ellos. El propietario del producto no debe estar sentado con el equipo para que no sienta la tentación de medrar en los detalles, pero debe sí estar accesible para el equipo por si surge alguna duda y hay que preguntarle. El resto de la gente no debe interferir para nada con el equipo.

Cómo hacemos los scrums diarios: El mejor sitio para el scrum diario es delante del tablón con la pila de scrum. Durante la reunión, que no debe durar mucho más de 15 minutos, se debe actualizar el tablón con los avances que el equipo ha realizado.

Cómo hacemos la demo de sprint: El hecho de tener que hacer demostraciones al final de cada sprint fuerza al equipo a tener algo hecho que mostrar y fomenta lo comunicación sobre lo que se está haciendo dentro del equipo y con otros equipos que asistan a la demostración. Las demostraciones además permiten obtener realimentación sobre el proyecto por parte del cliente.

Cómo hacemos las restrospectivas de sprint: La retrospectiva es la segunda tarea más importante, puesto que es la que premite mejorar. La restrospectiva es una reunión que tiene lugar al final de cada sprint donde el equipo expone sus ideas sobre qué cosas se pueden hacer mejor.

Descansos entre sprints: Después de cada sprint, que pueden ser muy intensos, es necesario un tiempo de descanso que permita además asimilar nuevas ideas o información.

Cómo hacemos la planificación de entregas y los contratos de precio fijo: En algunos casos, normalmente unidos a un contrato de precio fijo, es necesario planificar con antelación las entregas de varios sprints posteriores. Para ello el propietario del producto necesita estimaciones de las tareas incluidas en el contrato, que se deben haber realizado de forma conjunta con el equipo. En función de estas estimaciones y la velocidad del equipo se establece el plan de entregas a lo largo de los siguientes sprints. Este plan puede ser modificado a medida que surgen cambios según el proceso avanza.

Cómo combinamos Scrum con XP: Scrum y XP se complementan a la perfección, puesto que Scrm se centra en la gestión y la organización del proyecto y XP se centra en las prácticas de programación. Algunas de las prácticas de XP son también parte inherente de Scrum, como el concepto de equipo, sentarse juntos, las historias de usuario y el juego de la planificación. Además, hay otras prácticas de XP que se complementan con Scrum, como la programación en parejas, el desarrollo guiado por pruebas (TDD), el diseño incremental, la integración continua, la propiedad colectiva del código y su estandarización y el trabajo a un ritmo enérgico pero sostenible.

Cómo hacemos pruebas: Esta es la parte más difícil del desarrollo de software y la más variable entre distintas organizaciones. Es necsario realizar algún test de aceptación manual antes de dar un trabajo por realizado. Sin embargo, se puede reducir esta fase de test aumentando la calidad del código entregado y aumentando la eficiencia de las pruebas automáticas realizadas. O, incluso, incluir que algún miembro del equipo realice tareas de tester. El tester será la persona que certifique que una tarea está completamente terminada. Las pruebas de aceptación no encajan bien dentro del ciclo de un sprint, por lo que se definen ciclos de aceptación fuera del sprint.

Cómo manejar múltiples equipos Scrum: Los equipos demasiado grandes no se adaptan bien a las prácticas de Scrum porque la comunicación entre todos los miembros es mucho más difícil. Es preferible tener varios equipos pequeños que uno grande, si el proyecto lo permite. El número ideal de personas parece estar entre 5 y 9 personas.

Cómo gestionamos equipos distribuidos geográficamente: Aquí se discuten distintas formas de gesrionar equipos distribuídos, que pueden ser bien distintos equipos en localizaciones distintas o un mismo equipo con miembros distribuídos.

Lista de comprobación del Scrum Master: Aquí se listan las tareas administrativas del Scrum Master, tareas que debe realizar al comienzo, durante y al final de cada sprint.

Este libro es una introducción estupenda a Scrum y permite comenzar a usar esta metodología siguiendo las ideas que en él se exponen. Luego, a través de la práctica, se pueden ir perfeccionando las prácticas en base a aquello que resulte realmente valioso.

Referencias:
Scrum & XP from the trenches
Scrum y XP desde las trincheras

Patrones de diseño: Adapter

2010-06-10T16:43:00.011+02:00

Este patrón convierte la interfaz de una clase en otra distinta que es la que esperan los clientes y permite que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.

Se encarga de proporcionar a una clase cliente el interfaz que necesita para trabajar utilizando en su implementación una clase o clases que no cumplen con dicho interfaz.

La mejor forma de ver este patrón es a través de un ejemplo. Supongamos que tenemos una clase Cliente que realiza cálculos matemáticos complejos cuya realización se delegan en otra clase. Vamos a suponer a modo de ejemplo que estos cálculos complejos pueden ser una suma o una resta. La interfaz requerida por esta clase cliente para sus cálculos se define en la interfaz Calculadora:

package com.roldan.adapter;

public interface Calculadora {
 public int suma(int operador1, int operador2);
 public int resta(int operador1, int operador2);
}

Para la ejecución de estos complejos cálculos se dispone de la clase Procesador que los implementa:

package com.roldan.adapter;

public class Procesador {
 public static final int SUMA = 1;
 public static final int RESTA = 2;
 
 public static int realizarOperacion(
   int operador1,
   int operador2,
   int operacion) {
  int resultado = 0;
  
  switch(operacion) {
   case SUMA:
    resultado = operador1 + operador2;
    break;
   case RESTA:
    resultado = operador1 - operador2;
    break;
  }
  
  return resultado;
 }
}

En este caso, a pesar de que la clase Procesador realiza las operaciones que necesita la clase Cliente, no implementa la interfaz que ésta necesita para poder usarla. Sin embargo, se puede crear una clase Adaptador que adapte la clase Procesador a la interfaz Calculadora:

package com.roldan.adapter;

public class Adaptador implements Calculadora {
 public int suma(
   int operador1,
   int operador2) {
  return Procesador.realizarOperacion(
    operador1,
    operador2,
    Procesador.SUMA);
 }
 
 public int resta(
   int operador1,
   int operador2) {
  return Procesador.realizarOperacion(
    operador1,
    operador2,
    Procesador.RESTA);
 }
}

De esta forma, la clase Cliente puede usar los cálculos realizados en la clse Procesador a través de la clase Adaptador, que la adecúa a la interfaz Calculadora que necesita la clase Cliente.

El siguiente diagrama UML refleja las relaciones entre dichas clases:

Adapter pattern en Wikipedia
Patrón Adaptador en Wikipedia
Design Patterns Uncovered: The Adapter Pattern en DZone
Adapter Pattern en OODesign.com
Otros patrones de diseño

Consideraciones sobre el diseño

2010-06-04T13:24:00.007+02:00

Este artículo está basado en el artículo de Martin Fowler “Is Design Dead?” y en su traducción al castellano realizada por Alejandro Sierra.

La verdad es que he descubierto en Martin Fowler una verdadera fuente de inspiración y de ideas sobre la ingeniería del software. En los últimos tiempos, basándome en sus artículos, estoy encontrando respuestas y reflexiones valiosas sobre los problemas que me afectan como desarrollador de software.

En este caso, llevo algún tiempo en conflicto entre la idea de realizar el diseño al principio del proyecto, paralizando todo desarrollo hasta tener una visión clara, o comenzar a desarrollar tan pronto como sea posible para tener algo que ofrecer como propugnan las metodologías ágiles, aunque esto implique rehacer lo ya hecho cuando las ideas se aclaran o varían.

En este artículo, Martin Fowler expone sus ideas sobre el diseño dentro de una metodología ágil como es XP que, aparentemente, no le da importancia.

Hay dos maneras de plantear el diseño, el diseño evolutivo y el diseño planeado:

Durante el diseño evolutivo el diseño se realiza a medida que el sistema evoluciona, formando parte de la programación. Esta forma de diseño suele acabar en desastre porque termina siendo una agregación de decisiones puntuales que complican el código y deterioran el diseño.
El diseño planeado se corresponde con la visión del diseño de cualquier ingeniería clásica, en donde se trata de anticipar los problemas de forma abstracta sin entrar en la codificación hasta haber terminado esta fase de diseño. Sin embargo, es difícil anticipar todos los problemas antes de comenzar con la programación, lo que hace aparecer tensiones entre programadores y diseñadores. También se pueden producir cambios en los requisitos que pueden deberse a cambios en el negocio y que, por tanto, son muy difíciles de preveer y de controlar sus efectos.

XP aboga por el diseño evolutivo. Sin embargo, para ello propugna una serie de prácticas que permiten controlar los efectos negativos de este tipo de diseño. Según la curva del cambio del software, el coste del cambio en programación aumenta exponencialmente a medida que avanza un proyecto, dificultando el diseño evolutivo. Pero esta curva se puede aplanar mediante una serie de prácticas que reducen el efecto de los cambios. Estas prácticas son:

Pruebas: permiten controlar el efecto de los cambios eviatndo la introducción de nuevos errores.
Integración continua: permite mantener el equipo en sincronía evitando que los cambios afecten a más gente.
Refactorización: permite limpiar el código y hacerlo más mantenible y fácil de modificar.

En el diseño evolutivo XP dice que “hay que hacer la cosa más simple que pueda funcionar” y que no lleve a cabo todo aquello que no sea necesario (principio YAGNI – “You Ain’t Gonna Need It”). Se trata de mantener el diseño lo más simple posible haciendo sólo aquello estructamente necesario. Para ello existen dos razones:

Si se hace algo que no es necesario ahora mismo se está comprometiendo el esfuerzo para quello que sí lo es. Además, se puede estar haciendo de forma incorrecta por falta de información, es mejor posponer su implementación hasta que se conozca con más detalle.
Un diseño complicado es más difícil de comprender e implementar que uno sencillo. Haciendo lo estrictamente necasio se tiene un diseño más sencillo y fácil de implementar.

Sin embargo, esta forma de mantener el diseño simple añadiendo posteriormente lo que se vaya convirtiendo en necesario sólo es factible si se están usando las prácticas anteriormente descritas para reducir el costo del cambio.

Como pautas de le lo que es un diseño simple, Kent Beck expone los siguientes cuatro criterios:

Correr todas la pruebas.
Revelar toda la intención del código haciendo que sea fácil de leer.
Evitar duplicación.
El menor número de clases y métodos.

No es necesario perder demasiado tiempo buscando el diseño más simple. La refactorización permite irlo simplificando a medida que se va entendiendo. Tampoco es bueno usar patrones de diseño sin ton ni son, es mejor dejar que el diseño evolutivo te guíe hacia el uso de un patrón que introducirlo prematuramente.

Respecto al uso de diagramas y UML XP dice que se usen si son útiles, pero no es partidario de su uso. Los diagramas pueden ser útiles para la comunicación siempre y cuando se reduzcan a la mayor sencillez posible. Sin embargo, el uso de diagramas se complica cuando se producen cambios durante la evolución del proyecto, porque es difícil mantenerlos en sincronía con el código.

Algo importante en el diseño es evitar la irreversibilidad de las decisiones. De esta manera la toma de decisiones no es dramática porque las malas decisiones pueden ser deshechas. En este sentido es importante contar con sistemas de control del código que permitan garantizar la reversibilidad.

Es importante contar con gente involucrada en el diseño. Alguien debe ejecercer control sobre el proyecto vigilando el diseño del código y responsabilizándose de él. Estas personas deben actuar cuando se detecta que el diseño puede verse comprometido o hay alguna dificultad técnica durante el proyecto. Esta rol es el del líder técnico. No tiene sentido el rol de arquitecto, puesto que no puede existir el diseño por parte de alguien que luego se desentienda de la construcción del software.

El diseño de un proyecto se puede medir en función de la calidad del código base. Si la calidad del código base de un proyecto se deteriora y se vuelve más difícl trabajar, entonces el diseño es insuficiente. Éste es un criterio subjetivo, pero es la gente técnica la que primero sufre la dificultad de hacer cambios y a quienes se debe escuchar.

Según Martin Fowler, la naturaleza del sideño ha cambiado. Ahora se buscan las siguientes habilidades:

Mantener el código tan claro y simple como sea posible.
Ser capaz de refactorizar, haciendo mejoras en el diseño cuando sea necesario.
Conocer y reconocer patrones y cuándo evolucinar hacia ellos.
Saber comunicar el diseño mediante diagramas, código y comunicación directa con las demás personas.

Como resumen, Martin Fowler aboga por un diseño evolutivo que permita comenzar con el desarrollo de forma temprana. Pero esto no se puede hacer de cualquier manera, es necesario introducir prácticas que faciliten el cambio durante el desarrollo de forma que el diseño pueda mejorar y adaptarse a las nuevas necesidades que vayan apareciendo.

Esto va en contra de un diseño planeado que deja todo por sentado en un larga fase inicial y que es seguido por una fase de implemantación en que los cambios no se contemplan y que, cuando se incorporan porque terminan siendo absolutamente inevitables, son difíciles de incorporar, rompiendo el diseño previamente establecido e introduciendo una gran propensión a errores.

El diseño evolutivo delega gran cantidad de trabajo de diseño en los desarrolladores. No existe la figura de arquitecto como persona que realiza todo el trabajo de diseño, sino como alguien que supervisa el trabajo de estos. Se debe contar con un equipo capaz y comprometido para poder seguir esta forma de trabajo, de lo contrario, se hace inviable.

Referencias:
Is Desing Dead? - Por Martin Fowler
¿Ha muerto el diseño? - Traducción de Alejandro Sierra
Examining the Agile Cost of Change Curve

UML2

2010-04-12T23:15:00.007+02:00

Este libro de Anaya Multimedia es la traducción al castellano de “UML2 and the Unified Process”, escrito por Jim Arlow e Ila Neustadt. Este libro no sólo es una introducción al lenguaje de modelado UML en su versión 2, también presenta el flujo de trabajo el Proceso Unificado, que es el proceso de desarrollo de software creado por los autores de UML y utiliza UML como lenguaje de modelado.

El libro, nos sumerge en UML y UP a través de los siguientes capítulos:

¿Qué es UML?: Se presenta UML como un lenguaje de modelado visual. UML permite crear modelos de la arquitectura de los objetos de un sistema, capturando la estructura estática y el comportamiento dinámico del mismo a través de diagramas, compuestos de elementos y relaciones. Se presentan los mecanismos de especificación, adornos, divisiones comunes y extensibilidad que se utilizan en UML para construir el modelo.

¿Qué es el proceso unificado?: Es un proceso de ingeniería del software de los mismos autores que UML. Es un proceso dirigido por riesgo y requisitos, centrado en la arquitectura, iterativo e incremental. Cada iteración realiza los workflows de requisitos, análisis, diseño, implementación y prueba. Separa la vida del proyecto en las fases de comienzo, elaboración, construcción y transición.

El workflow de requisitos: El workflow de requisitos se desarrolla principalmente durante las fases de comienzo y elaboración y recoge y organiza los requisitos funcionales y no funcionales. Se presentan técnicas que ayudan a encontrar requisitos, como las entrevistas, cuestionarios y workshops.

Modelado del caso de uso: Los casos de uso son funciones que el sistema realiza en nombre de actores específicos. Se dan pautas sobre cómo encontrar estos casos de uso y define una especificación de caso de uso que los describe. Se indica la necesidad de crear una matriz de trazabilidad de requisitos que relacione los requisitos funcionales y los casos de uso.

Modelado avanzado de caso de uso: En este capítulo se explica la generalización de actores y la generalización, inclusión y extensión de casos de uso. Se dan sugerencias para escribir casos de uso.

El workflow de análisis: Se presenta el workflow de análisis, que trata de crear modelos que capturen los requisitos esenciales y las características del sistema deseado. Se presentan las características del modelo de análisis y los artefactos y actividades del workflow de análisis. Se dan reglas generales para el análisis.

Objetos y clases: Se presentan que son los objetos y las clases y su notación en UML.

Encontrar clases de análisis: Se presenta la actividad de análisis de un caso de uso, centrándose en la obtención de clases de análisis. Se definen las propiedades de estas clases de análisis y se dan reglas generales sobre sus propiedades. Se presentan las técnicas para encontrar estas clases, como el análisis nombre/verbo, el análisis CRC y los estereotipos RUP.

Relaciones: Se analizan las relaciones, conexiones semánticas entre los elementos de un modelo que son equivalentes a que una clase tenga un pseudoatributo que pueda albergar instancias de la otra clase. Las conexiones entre objetos son los vínculos, y las asociaciones son las conexiones entre clases. Las asociaciones pueden estar definidas por un nombre de asociación, nombres de roles, multiplicidad y navegabilidad. Se presentan las clases de asociación y las asociaciones cualificadas. Las dependencias son relaciones en que un cambio en el proveedor afecta al cliente. Las dependencias pueden ser de uso, de abstracción o de permiso.

Herencia y polimorfismo: La herencia de clase es una relación de generalización entre clases. La subclase puede añadir nuevas características o anular operaciones heredadas. Las clases abstractas tienen alguna operación abstracta y no se pueden heredar. El polimorfismo permite que una operación tenga distintas implementaciones según su clase. Se presentan los conjuntos de generalización y los powertypes.

Paquetes de análisis: El paquete es el mecanismo de agrupación de UML. Todo elemento del modelo está contenido en un paquete. Un paquete define un conjunto de nombres encapsulado. Existen varias relaciones de dependencia entre paquetes: use, import, access, trace, merge. El análisis de la arquitectura de un sistema trata de dividir conjuntos cohesivos de clases de análisis en paquetes de análisis. Es importante maximizar la cohesión dentro de los paquetes y minimizar las dependencias de otros paquetes.

Realización de casos de uso: Las realizaciones de casos de uso muestran cómo las instancias de clases de análisis interactúan para realizar los requisitos funcionales especificados por los casos de uso. Las interacciones están representadas por las líneas de vida de los participantes y los mensajes que se envían entre ellos para comunicarse. Las interacciones se expresan mediante diagramas de interacción, que pueden ser principalmente de secuencia o de comunicación.

Realización avanzada de casos de uso: Se muestran características avanzadas de los diagramas de interacción, como las ocurrencias de interacción, que pueden hacer uso de parámetros o puertas, y las continuaciones.

Diagramas de actividad: Son diagramas de flujo orientados a objeto que se utilizan para modelar todo tipo de procesos. Tienen semántica de Redes de Petri. Las actividades son redes de nodos conectadas por extremos. Se presenta la notación de los diagramas de actividad.

Diagramas avanzado de actividad: Se presentan características avanzadas de diagramas de actividad, como regiones de actividad interrumpibles, pins de excepción, nodos protegidos, nodos de expansión, envío y recepción de señales y conjuntos de parámetros.

Workflow de diseño: En esta actividad se trata de determinar como se implementará la funcionalidad especificada en el modelo de análisis. Es la principal actividad de la última parte de la fase de elaboración y de la primera parte de la fase de construcción. Se discute la conveniencia de mantener modelos aparte de análisis y diseño.

Diseñar clases: Las clases de diseño son clases cuyas especificaciones se han completado hasta un nivel que se puede implementar. Proceden tanto del ámbito del problema como del de la solución. Tienen especificaciones completas y presentan las características de ser completas, suficientes, sencillas, altamente cohesionadas y poco acopladas. Las clases de diseño hacen uso de la herencia y la realización de interfaz.

Mejorar relaciones de análisis: Convertir relaciones de análisis en relaciones de diseño implica convertir asociaciones en agregación o composición, implementar clases de asociación, implementar asociaciones uno a muchos, muchos a uno, muchos a muchos, bidireccionales, añadir navegabilidad, añadir multiplicidad, añadir nombres de rol a los extremos y utilizar clasificadores estructurados.

Interfaces y componentes: Las interacciones entre subsistemas están mediadas por interfaces, que especifican un conjunto de características públicas. Diseñar mediante interfaces permite hacer las cosas más flexibles a costa de mayor complejidad. Los componentes son partes modulares del sistema y que encapsulan contenidos, siendo éstos componentes reemplazables. Un subsistema es un componente que actúa como una unidad de descomposición para un sistema más amplio. Se utilizan interfaces para ocultar los detalles de implementación de los subsistemas.

Realización de un caso de uso: diseño: La realización de un caso de uso en diseño es una extensión de la realización de un caso de uso en análisis y se encarga de encontrar las clases de diseño, interfaces y componentes que interactúan para proporcionar el comportamiento de un caso de uso. La realización de un caso de uso se muestra en diagramas de interacción de diseño y diagramas de clase de diseño. Se utilizan clases activas para modelar concurrencia, diagramas de interacción de subsistema para mostrar interacciones entre sus partes y diagramas de tiempo para modelar restricciones de tiempo.

Máquinas de estado: Las máquinas de estado se basan en el trabajo de Harel y modelan comportamiento dinámico de un objeto reactivo. Las máquinas de estado pueden ser de comportamiento o de protocolo. Los diagramas de estado se componen de acciones, actividades, estados, transiciones y eventos.

Máquinas de estado avanzadas: Los estados compuestos pueden tener una o más submáquinas anidadas. Un estado compuesto secuencial tiene una submáquina anidada, un estado compuesto concurrente contiene dos o más submáquinas anidadas que se ejecutan concurrentemente. La historia (superficial o profunda) permite que un superestado recuerde el último subestado antes de una transición de salida.

El workflow de implementación: Es el foco principal de la fase de construcción y trata sobre la transformación de un modelo de diseño en código ejecutable.

Despliegue: Los diagramas de despliegue permiten modelar la distribución de un sistema de software sobre hardware físico. Un diagrama de despliegue está formado por nodos, relaciones y componentes.

El libro termina con material adicional, como una referencia al Lenguaje de Restricción de Objetos (OCL – Object Constraint Language).

Es un libro que me ha resultado fácil de leer y que creo que hace una buena introducción al modelado de sistemas en análisis y diseño, proporcionando técnicas útiles y buenos consejos.

JBoss Drools

2010-04-09T20:39:00.012+02:00

Según la Wikipedia: "Las reglas de negocio describen las políticas, normas, operaciones, definiciones y restricciones presentes en una organización y que son de vital importancia para alcanzar sus objetivos. Las reglas de negocio especifican en detalle lo que una organización puede hacer."

Ejemplos de reglas de negocio podrían ser:

"A una persona que ingresa más de 20.000 euros al año Hacienda le retiene el 15%"
"A los clientes que gasten más de 1.000 euros se les hace un descuento del 5%"

Como se ve en los ejemplos, las reglas de negocio tienen una semántica if/then, si se cumple una determinada condición se debe realizar una determinada acción.

Cuando un negocio dispone de muchas reglas que se deben aplicar, las aplicaciones que las gestionan se convierten en una maraña de código formado por estructuras if/else anidadas, que dificultan enormemente la comprensión y mantenibilidad del código.

Si las reglas de negocio se aíslan del resto del código, se está separando la verdadera inteligencia sobre el negocio (las reglas) del resto del programa. Los sistemas de gestión de reglas de negocio (BRMS – Bussiness Rule Management System) permiten gestionar de forma independiente las reglas de negocio. Facilitan la modificación o inclusión de nuevas reglas en tiempo de ejecución.

Dentro de los sistemas de gestión de reglas de negocio en Java más populares hoy en día encontramos Drools. Drools es un BRMS de JBoss que implementa la Java Rule Engine API (JSR 94) y utiliza una implementación mejorada del algoritmo de Rete para la ejecución de reglas.

A continuación voy a mostrar un ejemplo simple de cómo utilizar Drools y cómo permite parametrizar las reglas del negocio de forma externa a la aplicación que las utiliza. Antes de comenzar, recomiendo haber instalado JBoss Tools en Eclipse, puesto que nos ofrecerá herramientas que facilitan el desarrollo de apicaciones que usan Drools.

El caso de uso que vamos a implementar en el ejemplo será el de una tienda online. En esta tienda hay dos tipos de clientes, aquellos que se han registrado previamente y los que no. Para todos los clientes que gasten más de 1.000 euros se les hace un descuento del 5%. A los que se han registrado, se les ofrece un descuento adicional del 5% en todas su compras, independientemente del importe. Vamos a hacer una aplicación que calcule el descuento que corresponde a cada usuario.

En primer lugar creamos un proyecto Drools en Eclipse, lo que es posible gracias a las utilidades instaladas en JBoss Tools:

El nuevo proyecto se va a llamar CalculadorDescuento:

El asistente nos permite crear ejemplos de uso de Drools:

Es necesario especificar el runtime de Drools, es decir, la carpeta donde se encuentran las librerías de Drools:

Ahora, creamos una clase Cliente que refleje los datos del cliente, su nombre, si está registrado, el gasto que ha realizado y el descuento que se le aplica:

package com.roldan.drools;

public class Cliente {
 String nombre;
 boolean registrado;
 float gasto;
 float descuento;
 
 // Getters y setters...
}

En la clase CalculadorDescuento se crea el siguiente método, que lee las reglas que se han definido en el fichero Descuentos.drl:

private static KnowledgeBase readKnowledgeBase()
 throws Exception {
 KnowledgeBuilder kbuilder = 
  KnowledgeBuilderFactory.newKnowledgeBuilder();
 kbuilder.add(
 ResourceFactory.newClassPathResource("Descuentos.drl"),
 ResourceType.DRL);
 KnowledgeBuilderErrors errors = kbuilder.getErrors();
 if (errors.size() > 0) {
  for (KnowledgeBuilderError error: errors) {
   System.err.println(error);
  }
  throw new IllegalArgumentException("Could not parse knowledge.");
 }
 KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
 kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
 return kbase;
}

El método main de esta clase crea una sesión de Drools y crea también varios clientes que introduce en esta sesión a los que se aplican las reglas que se definen en el fichero Descuentos.drl:

public static void main(String[] args) {
 try {
  // Cargar las reglas
  KnowledgeBase kbase = readKnowledgeBase();
  StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
  KnowledgeRuntimeLogger logger =
   KnowledgeRuntimeLoggerFactory.newFileLogger(ksession, "test");
   
  // Cliente no registrado que gasta más de 1.000 euros
  Cliente cliente1 = new Cliente();
  cliente1.setNombre("Cliente 1");
  cliente1.setRegistrado(false);
  cliente1.setGasto(1200);   
  ksession.insert(cliente1);
   
  // Cliente registrado que gasta menos de 1.000 euros
  Cliente cliente2 = new Cliente();
  cliente2.setNombre("Cliente 2");
  cliente2.setRegistrado(true);
  cliente2.setGasto(800);   
  ksession.insert(cliente2);
   
  // Cliente registrado que gasta más de 1.000 euros
  Cliente cliente3 = new Cliente();
  cliente3.setNombre("Cliente 3");
  cliente3.setRegistrado(true);
  cliente3.setGasto(1600);   
  ksession.insert(cliente3);
   
  ksession.fireAllRules();
  logger.close();
   
  System.out.println("El cliente 1 tiene un descuento de " 
   + cliente1.getDescuento() + " euros.");
  System.out.println("El cliente 2 tiene un descuento de " 
   + cliente2.getDescuento() + " euros.");
  System.out.println("El cliente 3 tiene un descuento de " 
   + cliente3.getDescuento() + " euros.");
   
 } catch (Throwable t) {
  t.printStackTrace();
 }
}

Ahora vamos a ver cómo se definen las reglas anteriormente descritas en el fichero Descuentos.drl:

package com.roldan.drools

rule "Gastos superior a 1.000 euros"
 when
  cliente : Cliente( gasto > 1000 )
 then 
  System.out.println("El cliente " 
   + cliente.getNombre() + " ha gastado más de 1.000 euros.");
  cliente.setDescuento(
   cliente.getDescuento() + cliente.getGasto()*5/100);
end

rule "Cliente registrado"
 when
  cliente : Cliente( registrado == true )
 then 
  System.out.println("El cliente " 
   + cliente.getNombre() + " está registrado.");
  cliente.setDescuento(
   cliente.getDescuento() + cliente.getGasto()*5/100);
end

Al ejecutar la clase principal, obtenemos la siguiente salida que nos informa sobre lo que ha pasado:

El cliente Cliente 3 está registrado.
El cliente Cliente 3 ha gastado más de 1.000 euros.
El cliente Cliente 2 está registrado.
El cliente Cliente 1 ha gastado más de 1.000 euros.

El cliente 1 tiene un descuento de 60.0 euros.
El cliente 2 tiene un descuento de 40.0 euros.
El cliente 3 tiene un descuento de 160.0 euros.

En esta traza vemos qué condiciones ha cumplido cada uno de los clientes y el resultado final de aplicarles todos los descuentos a los que tienen derecho según su condición.

Aunque este es un ejemplo muy sencillo, se puede apreciar que ahora, si se quisiese variar el descuento aplicado para cada uno de estos casos o aplicar un nuevo descuento según otra condición distinta, no haría falta manipular el código de la aplicación. Bastaría con modificar las reglas definidas de forma separada en el fichero Descuentos.drl.

Esto no es más que una sencilla aplicación de lo que ofrece Drools, aunque este BRMS es mucho más potente que esto y ofrece mucha más funcionalidad que ya iremos viendo.

Referencias:
Does Your Project Need a Rule Engine
Primeros pasos con Drools
Drools en Wikipedia
Bussiness rule en Wikipedia
Implement business logic with the Drools rules engine
Open Source BRE/BRMS JSR-94 compliant
Getting Started With the Java Rule Engine API (JSR 94): Toward Rule-Based Applications

Los Métodos Ágiles

2010-03-29T15:12:00.007+02:00

Entre finales de la década pasada y principios de la actual surgieron una serie de métodos de desarrollo de software contrapuestos a la visión clásica de la ingeniería del software. Estos métodos se postulan en contra del control de los proyectos de software basado en la predictibilidad de las tareas a desarrollar, y proponen una orientación de estos que facilite su adaptabilidad de forma continua a las condiciones cambiantes de dichos proyectos.

En su artículo “The New Metodology”, Martin Fowler hace una exposición de estos métodos, llamados métodos ágiles. Voy a hacer un pequeño repaso a este artículo a través de la traducción al castellano realizada por Alejandro Sierra.

Según Martin Fowler, la forma más habitual de trabajar en un proyecto de desarrollo de software es a través de la prueba y error con un mínimo plan inicial, y completando el diseño con decisiones a corto plazo. Esto funciona bien para proyectos pequeños pero no para proyectos más grandes, que necesitan de largas fases de prueba a posteriores que desbordan toda planificación.

Para remediar esta situación se dispone de metodologías de desarrollo, que imponen un proceso disciplinado que trata de convertir el desarrollo de software en algo predecible y eficiente, similar a otras ingerierías. Sin embargo, estos métodos introducen mucha burocracia en los proyectos, retrasando su avance.

En opocición a estas metodologías, surgen los métodos ágiles, que se sitúan en medio de las metodologías tradicionales y la falta de metodología. Están más orientados a producir código que documentación debido a sus dos características principales:

Son adaptables en lugar de predictivos. En vez de planear todos los aspectos del proyecto tratan de adaptarse en los cambios que se producen durante la ejecución del proyecto.
Son orientados a la gente en lugar de al proceso. Tratan de apoyar el equipo de desarrollo en su trabajo, en vez de forzar al equipo a trabajar de una forma estricta.

Las ingenierías tradicionales enfatizan en que hay que planear antes de construir. En ellas, el plan define de forma exacta cómo se llevará a cabo la construcción. La realización del plan es una actividad mucho más exigente que la ejecución, y requiere de personal especializado. La ejecución es algo más mecánico que puede ser llevado a cabo por personal de nivel bajo.

Sin embargo, en desarrollo de software, no es fácil diseñar un plan que convierta el desarrollo en una actividad de construcción predecible. Un diseño en UML no suele ser todo lo completo que sería necesario y suele variar con respecto a la implementación. En estos casos el costo del esfuerzo del plan es mucho mas cercano a la implementación que en proyectos de ingenierías tradicionales.

Por tanto, se observa que en el desarrollo de software la construcción es barata ya que casi todo el esfuerzo está en el diseño, que es un proceso creativo. Como los procesos creativos no se planean fácilmente, la previsibilidad es una meta difícil de alcanzar.

Además, en los proyectos de desarrollo de software, los cambios en los requisitos son habituales, debido a las condiciones cambiantes en las que se dearrollan los proyectos. Además, ya que el desarrollo de software es una actividad de diseño, esta es difícil de planear y cuantificar, por lo que la estimación de los requisitos es difícil, y con ello la posibilidad de obtener un plan predecible.

Es por ello que en desarrollo de software es necesario un proceso que controle esta imprevisibilidad mediante adaptabilidad. Esto se logra mediante el desarrollo iterativo, que permite obtener retralimentación sobre la situación del proyecto en intervalos frecuentes.

De esta forma, se hace evidente tanto la situación actual del proyecto como posibles fallos de entendimiento del mismo o bugs.

Sin embargo, este tipo de desarrollo necesita un tipo de cliente distinto al tradicional. El cliente debe estar involucrado con el equipo, revisando el resultado de las iteraciones y proporcionando información sobre el proyecto de forma constante. Además, el contrato de precio fijo deja de tener sentido.

Ya que no se puede fijar tiempo, precio y alcance, lo normal es fijar precio y tiempo y permitir que el alcance varie de manera controlada. Gracias a las iteraciones, el cliente tiene control a escala fina sobre la evolución del proyecto, pudiendo fijar la dirección del proyecto de acuerdo a sus prioridades. Esta visibilidad sobre el proyecto que otorgan las iteraciones permite controlar también el riesgo.

En un proceso de este tipo se requiere de un equipo eficaz de desarrolladores. Las personas involucradas en un proyecto ya no son recursos reemplazables, debido a que el trabajo que se realiza es algo creativo y en este tipo de trabajo hay grandes diferencias entre las personas. Además, si las personas trabajan en equipo, se establecen sinergias que hacen que el equipo sea más que la suma de sus miembros.

También hay que reconocer a los profesionales de software como profesionales competentes capaces de dirigir su trabajo técnico. La labor de la gerencia será favorecer este trabajo con la menor interferencia posible.

Las metodologías ágiles tambien rechazan las métricas como herramienta de control del rendimiento de las personas, puesto que no se han encontrado métricas fiables en este sentido. Por ello favorecen la gestión delegatoria, donde los que finalmente hacen el trabajo deciden sobre cómo hacerlo.

Pero para llevar esto a cabo no se puede confiar sólo en la parte técnica. Es necesario que los expertos de negocio estén accesibles y pueden resolver las dudas que surjan a medida que el proyecto avanza. Se favorece la comunicación interdisciplinar.

Además, el propio proceso de desarrollo debe evaluarse y someterse a modificaciones que permitan mejorarlo.

Varias metodologías comparten estas bases. Entre ellas, podemos citar:

XP.
Scrum.
Crystal.
FDD (Feature Driven Development).
DSDM (Dynamic System Development Method).
Lean.
Etc.

A pesar de todo, es importante resaltar que el uso de estas metodologías no es apropiado para todos los casos. Hay que considerar la naturaleza de cada proyecto y evaluar si encajaría con estos principios o no.

Factores que sugieren un proceso adaptable:

Requisitos inciertos.
Desarrolladores responsables.
Clientes implicados.

Factores que sugieren un proceso predictivo:

Equipos grandes.
Contratos con alcance y precio fijo.

Sin embargo, no todo son parabienes para estos métodos y su aparición ha suscitado amplios debates entre sus defensores y los defensores de las metodologías tradicionales. Como ejemplo, este artículo de Miguel Ángel Abián y el debate que suscitó dentro de la comunidad JavaHispano.

Referencias:
The New Metodology por Martin Fowler
Traducción al castellano del artículo The New Metodology por Martin Fowler realizada por Alejandro Sierra
Artículo de Miguel Ángel Abián sobre las Metodologías Agiles
Discusión en JavaHispano en torno al artículo de Miguel Ángel Abián
La Falacia de la Ingeniería del Software por Samuel Zarza
Waterfall vs. Agile: Can they be Friends?

Lean

2010-02-24T11:17:00.004+01:00

Lean manufacturing o Lean production, conocido normalmente como Lean, es una es una filosofía de gestión cuyo origen principal es el TPS (Toyota Production System), y que considera como desperdicio cualquier gasto de recursos que no esté orientado a la creación de valor para el cliente. Lo que intenta es crear un mayor valor con el menor gasto.

Lean intenta optimizar el flujo del proceso de producción, tratando de incrementar la eficiencia, reducir el gasto, y usar métodos empíricos para decidir qué es lo verdaderamente importante.

La metodología de desarrollo de software Lean es una translación de los principios y prácticas de la manufacturación Lean hacia el dominio del desarrollo del software. El desarrollo de software Lean tiene origen en el un libro del mismo nombre, escrito por Mary y Tom Poppendieck.

El desarrollo Lean se resume en los siguientes siete principios:

Eliminar los residuos.
Fomentar el aprendizaje.
Retrasar las decisiones.
Reaccionar rápidamente.
Potenciar el equipo.
Fomentar la integridad.
Ver todo el conjunto.

A continuación, pasamos a explicar cada uno de estos principios.

Eliminar los residuos

En Lean, todo lo que no añade valor al cliente se considera un residuo. Hay que ser capaz de reconocer las actividades que son residuos. Si el resultado esperado se puede alcanzar sin realizar alguna actividad, esta actividad es un residuo:

La codificación parcial eventualmente abandonada durante el proceso de desarrollo es un residuo.
Los procesos extra y funcionalidades que no utilizan con frecuencia por los clientes son residuos.
Las esperas ocasionadas por otras actividades, equipos o procesos son residuo.
Defectos y menor calidad son los residuos.
Gastos generales de gestión que no producen valor real son residuos.

A continuación se deben señalar las fuentes de los residuos y eliminarlos. Y todo ello debe hacerse de forma iterativa.

Fomentar el aprendizaje

El desarrollo de software es un proceso de aprendizaje continuo. La forma más eficaz para mejorar un entorno de desarrollo de software es el aprendizaje:

La acumulación de defectos debe evitarse ejecutando las pruebas tan pronto como el código está escrito.
En lugar de añadir más documentación o planificación detallada, las distintas ideas podrían ser juzgados escribiendo código y construyendo.
El proceso de recopilación de requisitos de usuarios podría simplificarse mediante la presentación de las pantallas de los usuarios finales y para que estos puedan hacer sus aportes.

El proceso de aprendizaje es acelerado por el uso de ciclos de iteración cortos que incrementan el feedback de los clientes, ayuda a determinar la fase actual de desarrollo y ajusta los esfuerzos para introducir mejoras en el futuro.

Durante estos ciclos, tanto los clientes como el equipo de desarrollo aprenden sobre el dominio del problema y buscar posibles soluciones para un mejor desarrollo. De esta forma los clientes comprenden mejor sus necesidades y los desarrolladores aprenden a satisfacerlas mejor.

Retrasar las decisiones

El desarrollo de software está siempre asociado con cierto grado de incertidumbre. Los mejores resultados se alcanzan cuando se puede decidir entre varias opciones basándose en hechos y no en suposiciones y pronósticos inciertos.

Cuanto más complejo es un proyecto, más capacidad para el cambio debe incluirse en este, así que debe permitirse el retraso en las decisiones importantes. Este enfoque de desarrollo puede llevar a opciones antes a los clientes. Por lo tanto, es conveniente retrasar algunas decisiones cruciales hasta que los clientes se hayan reconocido mejor sus necesidades. También permite la adaptación tardía a los cambios y previene de las costosas decisiones delimitadas por la tecnología.

Esto no significa que no haya un planificación del proceso. Por el contrario, las actividades de planificación se centran en las diferentes opciones y se las adapta a la situación actual. Esto permite clarificar las situaciones confusas y establecer las pautas para una acción rápida.

Reaccionar rápidamente

En el mercado actual, cuanto antes se entrega el producto final sin defectos considerables, más pronto se pueden recibir comentarios, que pueden ser incorporados en la siguiente iteración. Cuanto más cortas sean las iteraciones, mejor es el aprendizaje y la comunicación dentro del equipo.

La velocidad asegura el cumplimiento de las necesidades actuales del cliente y les da la oportunidad de demorarse pensando lo que realmente necesitan, hasta que adquieran un mejor conocimiento.

La ideología de producción Just In Time se aplica a programas de desarrollo. El equipo se organiza y se divide las tareas para lograr el resultado necesario para una iteración específica. El cliente dispone los requisitos necesarios en pequeñas historias y los desarrolladores estimarán el tiempo necesario para el desarrollo de cada una de ellas. Cada mañana, cada miembro del equipo evalúa lo que se ha hecho ayer, y lo que hay que hacer hoy y mañana, y pregunta por cualquier nueva entrada necesaria de parte de sus colegas o del cliente.

Otra idea clave se establece a base de diseño. Si un nuevo sistema es necesario, tres equipos pueden diseñar soluciones al mismo problema. Cada equipo aprende sobre el problema y diseña una posible solución. Cuando una solución se considera irrazonable, se desecha. Al final de un periodo, los diseños sobrevivientes se comparan y se elige uno, quizá con algunas modificaciones basadas en el aprendizaje de los demás. Mediante esta práctica se minimiza el riesgo provocado por un solo gran diseño realizado por adelantado.

Potenciar el equipo

Hasta el momento los administradores dicen a los trabajadores cómo hacer su trabajo. Ahora, los roles cambian, los trabajadores son los que dicen qué acciones podrían tomarse y sugieren mejoras. Los directores de proyecto más experimentados dicen que la clave de éxito de los proyectos es: "Buscar la buena gente y dejarles hacer su propio trabajo".

Otra creencia errónea ha sido considerar a las personas como recursos. En el desarrollo de software, las personas necesitan motivación y un objetivo hacia el cual trabajar, con la garantía de que el equipo puede elegir sus propios compromisos. Los desarrolladores deberían tener acceso a los clientes, el jefe de equipo debe proporcionar apoyo y ayuda en situaciones difíciles, y asegurarse de mantener el espíritu de equipo.

Fomentar la integridad

La integridad consiste en que los componentes separados del sistema función bien tanto juntos como en un todo.

Una de las maneras más saludables hacia una arquitectura que mantinen la integridad es la refactorización, que consiste en mantener la sencillez, la claridad, la cantidad mínima de funcionalidades en el código. Las repeticiones en el código son signo un mal diseños de código y deben evitarse. El completo y automatizado proceso de construcción debe ir acompañada de una suite completa y automatizada de pruebas, tanto para desarrolladores y clientes, que tengan la misma versión, sincronización y semántica que el sistema actual.

Al final, la integridad debe ser verificada con una prueba global, garantizando que el sistema hace lo que el cliente espera haga.

Ver todo el conjunto

Los sistemas de software hoy en día no son simplemente la suma de sus partes, sino también el producto de sus interacciones. Cuanto mayor sea el sistema, más serán las organizaciones que participan en su desarrollo y más partes son las desarrolladas por diferentes equipos; mayor es la importancia de tener bien definidas las relaciones entre los diferentes proveedores, con el fin de producir una buena interacción entre los componentes del sistema.

Para terminar, simplemente quiero recalcar que Lean define los principios a aplicar en un desarrollo de software, pero no la forma concreta de aplicarlos.

Referencias:
Desarrollo software Lean
Lean Manufacturing
Lean software development

Patrones de diseño: Prototype

2010-02-23T15:49:00.006+01:00

El patrón Prototype es un patrón de diseño creacional en el que los objetos se crean a partir de una instancia prototípica, que es clonada para dar lugar a nuevos objetos.

Este patrón se usa en los siguientes casos:

Para evitar las subclases de un objeto creador como hace el patrón Abstract Factory.
Para evitar el costo inherente a la creación de un objeto nuevo mediante el operador new cuando esto demasiado costoso para la aplicación.

Para implementar este patrón, se declara una clase base abstracta que tiene un método clone(). Cualquier clase que necesite un constructor deriva de la clase abstracta e implementa el método clone().

El cliente, en vez de escribir codigo que hace uso del operador new sobre una clase específica, llama al método clone() de la clase prototipo, o llama a un método factoría con un parámetro que especifica la clase deseada, o invoca el método clone() de la clase de alguna otra forma.

El siguiente diagrama UML representa este patrón:

Un ejemplo en Java de este patrón es el siguiente, sacado de la Wikipedia:

/** Prototype Class */
abstract class PrototypeFactory implements Cloneable {
 public PrototypeFactory clone() throws CloneNotSupportedException {
 // call Object.clone()
 PrototypeFactory copy = (PrototypeFactory) super.clone();
 //In an actual implementation of this pattern you might 
 //now change references to
 //the expensive to produce parts from the copies 
 //that are held inside the prototype.
 return copy;
}
 
abstract void prototypeFactory(int x);
 abstract void printValue();
}
 
/** Concrete Prototypes to clone */
class PrototypeImpl extends PrototypeFactory {
 int x;
 
 public PrototypeImpl(int x) {
  this.x = x;
 }
 
 @Override
 void prototypeFactory(int x) {
  this.x = x;
 }
 
 public void printValue() {
  System.out.println("Value :" + x);
 }
}
 
/** Client Class */
public class PrototypeExample {
 private PrototypeFactory example; 
 // Could have been a private Cloneable example.
 
 public PrototypeExample(PrototypeFactory example) {
  this.example = example;
 }
 
 public PrototypeFactory makeCopy() throws CloneNotSupportedException {
  return this.example.clone();
 }
 
 public static void main(String args[]) {
  try {
   PrototypeFactory tempExample = null;
   int num = 1000;
   PrototypeFactory prot = new PrototypeImpl(1000);
   PrototypeExample cm = new PrototypeExample(prot);
   for (int i = 0; i < 10; i++) {
    tempExample = cm.makeCopy();
    tempExample.prototypeFactory(i * num);
    tempExample.printValue();
   }
  } catch (CloneNotSupportedException e) {
   e.printStackTrace();
  }
 }
}

También se puede combinar el uso del patrón Prototype con el de Factory Method, como en el siguiente ejemplo, también extraído de la Wikipedia:

// Los productos deben implementar esta interface
public interface Producto extends Cloneable {
 Object clone();
 // Aqui van todas las operaciones comunes a los productos que genera la factoria
}
 
// Un ejemplo basico de producto
public class UnProducto implements Producto {
 private int atributo;
 
 UnProducto(int atributo) {
  this.atributo = atributo;
 }
 
 public Object clone() {
  return new UnProducto(this.atributo);
 }
 
 public String toString() {
  return ((Integer)atributo).toString();
 }
}
 
// La clase encargada de generar objetos a partir de los prototipos
public class FactoriaPrototipo {
 private HashMap mapaObjetos;
 private String nombrePorDefecto;
 
 public FactoriaPrototipo() {
  mapaObjetos = new HashMap();
  // Se incluyen al mapa todos los productos prototipo
  mapaObjetos.put("producto 1", new UnProducto(1));
 }
 
 public Object create() {
  return create(nombrePorDefecto);
 }
 
 public Object create(String nombre) {
  nombrePorDefecto = nombre;
  UnProducto objeto = (UnProducto)mapaObjetos.get(nombre);
  return objeto != null ? objeto.clone() : null;
 }
}
 
public class PruebaFactoria {
 static public void main(String[] args) {
  FactoriaPrototipo factoria = new FactoriaPrototipo();
  Producto producto = (Producto) factoria.create("producto 1");
  System.out.println ("Este es el objeto creado: " + producto);
 }
}

Referencias:
Prototype (patrón de diseño)
Prototype pattern
Prototype Pattern – Patron Prototipo — Patrones de diseño
Un ejemplo del Patrón Prototype ( la versión Java )
Pattern Summaries: Prototype
Prototype Design Pattern, UML diagram, Java Example
Otros patrones de diseño

Sonar: Métricas de calidad del código

2010-02-11T21:06:00.009+01:00

Según su propia web, Sonar es una plataforma que permite gestionar la calidad del código controlando los 7 ejes principales de dicha calidad del código:

Arquitectura y diseño
Duplicaciones
Pruebas unitarias
Complejidad
Errores potenciales
Reglas de codificación
Comentarios

Sonar realiza varios análisis de nuestro código a través de otras herramientas (Checkstyle, PMD, Cobertura…) y presenta de manera unificada a través de su interfaz la información generada por ellas en forma de métricas.

A través de la interfaz de Sonar podemos ver de forma detallada los puntos débiles de nuestro proyecto como errores potenciales en el código, escasez de comentarios, clases demasiado complejas, escasez de cobertura de las pruebas unitarias, y más.

Lo mejor es ilustrar la potencia de esta herramienta con un ejemplo de su uso, para lo cual vamos instalarla en nuestro equipo en primer lugar desde la página web del proyecto Sonar.

Descargamos la versión actual, que en este momento es la 1.12. Una vez que hemos descargado Sonar, tenemos un archivo .zip que podemos descomprimir en cualquier lugar, yo lo haré en la carpeta D:\java.

Por sencillez, para las pruebas vamos a lanzar el servidor de Sonar en modo standalone, aunque lo ideal sería instalarlo en un servidor de aplicaciones. Desde la línea de comandos vamos a la carpeta D:\java\sonar-1.12\bin\windows-x86-32 (estoy haciendo la prueba en Windows) y ejecutamos StartSonar.bat:

Esto lanzará el servidor de Sonar, al que podremos acceder desde la URL http://localhost:9000/:

Como acabamos de instalar Sonar, la interfaz aparecerá prácticamente vacía hasta que empecemos a analizar nuestros proyectos. Para ello iremos a uno de nuestros proyectos, gestionados con Maven, y le pediremos a Sonar que lo analice mediante el target de Maven mvn sonar:sonar:

Si ahora refrescamos la interfaz de Sonar, veremos que aparece el nuevo proyecto analizado:

Además ya nos va mostrando información sobre el proyecto, como el porcentaje de cumplimiento de las reglas de análisis o el porcentaje de cobertura de las pruebas unitarias. Pero, si queremos más información, no tenemos más que pinchar sobre nuestro proyecto para ir a la siguiente pantalla:

Aquí se empieza a ver la potencia de Sonar. En una interfaz compacta nos muestra una cantidad importante de información sobre el código del proyecto como:

medida en líneas de código
complejidad de los componentes
cantidad de comentarios introducidos
duplicidad del código
cobertura del código
conformidad respecto a ciertas reglas de codificación
violaciones del código

Para ampliar la información, podemos, por ejemplo, acceder a las violaciones tipo major de las reglas de codificación:

Sonar nos muestra información sobre las reglas que se están incumpliendo, y los paquetes y clases en que esto ocurre. Y, si pinchamos sobre una de las clases Sonar muestra cuál es el código que está incumpliendo estas reglas y da indicaciones para corregirlo:

A mí Sonar me ha parecido una maravilla, y no he hecho más que empezar a ver sus posibilidades. Os invito a que utilicéis esta herramienta y exploréis su interfaz en busca de toda la información que ofrece sobre el código del proyecto.

Referencias:
Página web del proyecto Sonar
Métricas en Java: Sonar
Analizando la calidad del código Java con Sonar

Patrones de diseño: Builder

2010-02-09T18:13:00.005+01:00

El patrón Builder o Constructor es otro de los patrones creacionales. Este patrón permite separar la construcción de un objeto complejo de su representación, de modo que el mismo proceso de construcción pueda crear diferentes representaciones de este objeto.

La siguiente imagen muestra el diagrama de clases de este patrón:

Builder: interfaz abstracta para crear productos.
Concrete Builder: implementación del Builder, construye y reúne las partes necesarias para construir los productos.
Director: construye un objeto usando el patrón Builder.
Producto: El objeto complejo bajo construcción.

A continuación se muestra un ejemplo de este patrón, extraído de la Wikipedia. En este ejemplo tenemos un cocina (Director) que produce pizzas (Producto) de con diferentes características (Concrete Builder):

/** "Product" */
class Pizza {
 private String dough = "";
 private String sauce = "";
 private String topping = "";
 
 public void setDough(String dough) {
  this.dough = dough;
 }
 
 public void setSauce(String sauce) {
  this.sauce = sauce;
 }
 
 public void setTopping(String topping) {
  this.topping = topping;
 }
}
 
/** "Abstract Builder" */
abstract class PizzaBuilder {
 protected Pizza pizza;
 
 public Pizza getPizza() {
  return pizza;
 }
 
 public void createNewPizzaProduct() {
  pizza = new Pizza();
 }
 
 public abstract void buildDough();
 
 public abstract void buildSauce();
 
 public abstract void buildTopping();
}

/** "ConcreteBuilder" */
class HawaiianPizzaBuilder extends PizzaBuilder {
 public void buildDough() {
  pizza.setDough("cross");
 }
 
 public void buildSauce() {
  pizza.setSauce("mild");
 }
 
 public void buildTopping() {
  pizza.setTopping("ham+pineapple");
 }
}
 
/** "ConcreteBuilder" */
class SpicyPizzaBuilder extends PizzaBuilder {
 public void buildDough() {
  pizza.setDough("pan baked");
 }
 
 public void buildSauce() {
  pizza.setSauce("hot");
 }
 
 public void buildTopping() {
  pizza.setTopping("pepperoni+salami");
 }
}

/** "Director" */
class Cook {
 private PizzaBuilder pizzaBuilder;
  
 public void setPizzaBuilder(PizzaBuilder pb) {
  pizzaBuilder = pb;
 }
 
 public Pizza getPizza() {
  return pizzaBuilder.getPizza();
 }
 
 public void constructPizza() {
  pizzaBuilder.createNewPizzaProduct();
  pizzaBuilder.buildDough();
  pizzaBuilder.buildSauce();
  pizzaBuilder.buildTopping();
 }
}
 
/** A given type of pizza being constructed. */
public class BuilderExample {
 public static void main(String[] args) {
  Cook cook = new Cook();
  
  PizzaBuilder hawaiianPizzaBuilder = new HawaiianPizzaBuilder();
  PizzaBuilder spicyPizzaBuilder = new SpicyPizzaBuilder();
  
  cook.setPizzaBuilder(hawaiianPizzaBuilder);
  cook.constructPizza();
 
  Pizza pizza = cook.getPizza();
 }
}

Hay quién confunde el patrón Builder con Factory, pero la diferencia es que, mientras el patrón Factory difiere la elección de la clase concreta de un objeto, el patrón Builder simplemente oculta la lógica de creación de un objeto complejo.

Referencias:
Patrón Builder en Wikipedia
Builder
Builder Pattern, Interfaces Fluidas– Patrones de diseño
Intro to Design Patterns: Builder Pattern
Creational Patterns - Builder Pattern
Design Pattern - Builder Pattern
Otros patrones de diseño

Patrones de diseño: Factorías

2010-02-02T18:08:00.007+01:00

Una factoría es un objeto que maneja la creación de otros objetos. Las factorías se utilizan cuando la creación de un objeto implica algo más que una simple instanciación.
Los siguientes ejemplos son casos donde una factoría puede ayudar:

Es necesario acceder a algún recurso para la creación y configuración de un objeto.
No conocemos hasta el momento preciso de la instanciación qué tipo concreto de objeto se va a instanciar.

En estos casos, en lugar de que sea el propio objeto quien se encargue de todos los aspectos realativos a la creación, se crea otro objeto que lo haga. De esta manera, se libera al objeto que va a ser creado de aquellas responsabilidades que no le corresponden pero que son necesarias para su creación, manteniendo su independencia.

El siguiente es un ejemplo de la utilización de una factoría para la creación de objetos. Se pueden crear figuras geométricas y calcular su área. Las figuras estarían definidas por una interfaz. Las figuras posibles son círculos y cuadrados.

Se va a utilizar una factoría para crear las figuras, puesto que no conocemos de antemano a qué clase pertenece el objetoque tenemos que instanciar. El uso de una factoría permite separar la lógica de negocio, igual para todos los casos, de la lógica de instanciación de los objetos. De este forma el código queda más claro.

public interface Figura {
 public double getArea();
}

public class Circulo implements Figura {
 double radio;
 
 public Circulo(double radio) {
  this.radio = radio;
 }
 
 public double getArea() {
  return (3.14 * radio * radio);
 }
}

public class Cuadrado implements Figura {
 double lado;
 
 public Cuadrado(double lado) {
  this.lado = lado;
 }
 
 public double getArea() {
  return lado * lado;
 }
}

public class Principal {
 public static void main(String[] args) {
  int tipo = Integer.parseInt(args[0]);
  double lado = Double.parseDouble(args[0]);  
 
  Figura figura = 
   FiguraFactory.getFigura(tipo, lado);

  System.out.println("El area de la figura es: " + figura.getArea());
 }
}

public class FiguraFactory {
 public final static int CUADRADO = 0;
 public final static int CIRCULO = 1;
 
 public static Figura getFigura(int tipo, double lado) {
  switch (tipo) {
   case CUADRADO:
    return new Cuadrado(lado);
   case CIRCULO:
    return new Circulo(lado);
  }  
  return null;
 }
}

El ejemplo anterior se corresponde con el patrón de diseño Factory Method, que se refiere a la utiliación de un método cuyo propósito principal es la creación de objetos.

Existe otro patrón de diseño denominado Abstract Factory, que proporciona una interfaz para crear familias de objetos que dependen entre sí, sin especificar sus clases concretas.

El siguiente es un ejemplo de una factoría abstracta sacado de la Wikipedia, en el que se crea un botón que puede pertenecer a dos familias distintas de componentes gráficos y la aplicación no sabe hasta el momento de la ejecución a qué familia pertenecerá este botón:


interface GUIFactory {
 public Button createButton();
}
 
class WinFactory implements GUIFactory {
 public Button createButton() {
  return new WinButton();
 }
}
 
class OSXFactory implements GUIFactory {
 public Button createButton() {
  return new OSXButton();
 }
}
 
interface Button {
 public void paint();
}
 
class WinButton implements Button {
 public void paint() {
  System.out.println("I'm a WinButton");
 }
}
 
class OSXButton implements Button {
 public void paint() {
  System.out.println("I'm an OSXButton");
 }
}
 
class Application {
 public Application(GUIFactory factory){
  Button button = factory.createButton();
  button.paint();
 }
}
 
public class ApplicationRunner {
 public static void main(String[] args) {
  new Application(createOsSpecificFactory());
 }
 
 public static GUIFactory createOsSpecificFactory() {
  int sys = readFromConfigFile("OS_TYPE");
  if (sys == 0) {
   return new WinFactory();
  } else {
   return new OSXFactory();
  }
 }
}

Referencias:
Objeto Factoría en Wikipedia
Patrón Factoría en Wikipedia
Patrón Factory Method en Wikipedia
Factory Pattern - Patrones
Patrón Abstract Factory en Wikipedia
Abstract Factory Pattern - Patrones
Otros patrones de diseño

Patrones de diseño: Singleton

2010-01-26T18:27:00.011+01:00

En este artículo vamos a ver uno de los patrones creacionales más comunes, el Singleton. Este patrón garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.

Este patrón se suele utilizar cuando una clase controla el acceso a un recurso físico único o cuando hay datos que deben estar disponibles para todos los objetos de la aplicación.

El patrón Singleton se implementa mediante una clase con un constructor privado. Existirá un método que creará una instancia del objeto llamando al constructor sólo si todavía no existe ninguna.

Se pueden producir problemas en programas con múltiples hilos de ejecución, si dos hilos de ejecución intentan crear la instancia al mismo tiempo y ésta no existe todavía. Para que sólo uno de ellos pueda crear el objeto se puede utilizar exclusión mutua (synchronized) en el método de creación de la clase que implementa el patrón.

Habría que decir también que si existen varios cargadores de clases para la aplicación puede existir una instancia de la clase en cada uno de ellos, aunque la instancia sea única dentro de ese cargador.

Una implementación correcta del patrón Singleton en Java podría ser la siguiente, propuesta por el investigador Bill Pough:

public class Singleton {
 // Private constructor prevents instantiation from other classes
 private Singleton() {}
 
 /**
  * SingletonHolder is loaded on the first execution of 
  * Singleton.getInstance() or the first access to 
  * SingletonHolder.INSTANCE, not before.
  */
 private static class SingletonHolder { 
  private static final Singleton INSTANCE = new Singleton();
 }
 
 public static Singleton getInstance() {
  return SingletonHolder.INSTANCE;
 }
}

A pesar de que es ampliamente utilizado, existe una corriente contraria al uso de este patrón debido a los problemas que introduce. En esta página Scout Densmore expone los problemas que Brian Button achaca a los Singletons. A continuación, hago una adaptación de lo ahí se dice:

Los Singletons normalmente se usan para proporcionar un punto de acceso global para un servicio. De esta forma no hace falta pasar una referencia a este servicio, lo que viene a ser como usar una variable global. Al final lo que ocurre es que las dependencias de diseño permanecen ocultas dentro del código y no son visibles al examinar las interfaces. Hace falta inspeccionar el código para entender qué objetos están usando las clases.

Los Singletons permiten limitar la creación de los objetos. Esto es cierto, pero ahora se están mezclando dos responsabilidades diferentes en la misma clase. Una clase no debería preocuparse de si es o no un Singleton, sino que sólo debería preocuparse por sus responsabilidades de negocio. Para limitar la creación de clases se deberían crear factorías u otros objetos que limiten la creación. De esta forma, cada objeto mantendría una responsabilidad mejor definida.

Los Singletons promueven el acoplamiento fuerte entre clases. Un acoplamiento flojo entre clases permite sustituir implementaciones alternativas de las clases colaboradoras en las pruebas. Una mejor alternativa es modificar el diseño para pasar referencias a los objetos en las clases y métodos, de forma que se reduzca el acoplamiento.

Los Singletons mantienen el estado hasta la finalización del programa. Este estado persistente es perjudicial para las pruebas unitarias, puesto que cada prueba debe ser independiente de las demás. Si esto no se cumple, podría llevar a situaciones donde las pruebas fallen donde no deben y a que se estén ocultando errores. Esto se puede evitar pasando referencias a objetos a las clases y métodos.

Es por ello que parece un patrón de diseño a evitar dentro de lo posible.

Referencias:
Patrón Singleton en Wikipedia
Singleton Pattern — Patrones de diseño
Singletons en Java, el patrón instancia única por David Barral
Patrón Singleton en c2.com
Why Singletons are Evil por Scott Densmore
Otros patrones de diseño

Pruebas funcionales con Selenium

2010-01-24T10:06:00.007+01:00

Selenium HQ es un framework que permite automatizar las pruebas funcionales sobre aplicaciones web. Está formado por varias herramientas que permiten definir estas pruebas y automatizarlas. En concreto, vamos a ver:

Selenium IDE: Se trata de un plugin de Firefox que permite definir una prueba de una aplicación web guardando en un script las acciones que ejecuta el usuario sobre el navegador. Este script puede volver a ejecutarse después todas las veces que se quiera.
Selenium RC (Remote Control): Permite automatizar las pruebas sobre las aplicaciones web a partir de los scripts definidos mediante Selenium IDE.

Veremos a continuación un ejemplo de prueba funcional de una aplicación web.

En primer lugar debemos descarganos el plugin de Firefox para Selenium IDE. Podemos hacerlo desde esta página. Esto descargará el plugin de Selenium IDE y lo instalará en el navegador. A continuación lo reiniciaremos para completar la instalación.

Ahora vamos a hacer una prueba de una aplicación web. En este caso se trata de una aplicación que guarda todos los artículos de interés de las revistas que voy comprando, y la prueba consistirá en introducir un nuevo artículo.

En primer lugar, vamos a Herramientas->Selenium IDE. Esto abre una ventana que permite grabar el script con la prueba a realizar:

A partir de este momento todo lo que hagamos sobre el navegador se registrará en el script. En este momento se introducirá un nuevo artículo de nombre “Nuevo” y título “Nuevo”. Una vez introducido, se pulsa sobre el botón rojo de la ventana de Selenium IDE para que pare la grabación del script. Comprobamos que se ha introducido el artículo.

Ahora repetimos la prueba pulsando sobre el triángulo verde situado arriba a la derecha de la ventana de Selenium IDE. Esto repite la ejecución anterior y por tanto, en el listado de artículos vemos que ahora existen 2 artículos de nombre “Nuevo”.

Podemos grabar esta prueba desde Archivo->Save Test Case. Sin embargo para nosotros será más interesante la opción Archivo->Export Test Case As ->Java (JUnit) Selenium RC que exportará este script a un caso de prueba de JUnit que vamos a utilizar posteriormente para automatizar esta prueba:

package com.example.tests;

import com.thoughtworks.selenium.*;
import java.util.regex.Pattern;

public class Prueba extends SeleneseTestCase {
 public void setUp() throws Exception {
  setUp("http://change-this-to-the-site-you-are-testing/", "*chrome");
 }
 public void testPrueba() throws Exception {
  selenium.open("/RevisteroMyFacesWeb/");
  selenium.click("link=Nuevo Artículo");
  selenium.waitForPageToLoad("30000");
  selenium.type("j_id_jsp_815202587_1:nombreArticulo", "Nuevo");
  selenium.type("j_id_jsp_815202587_1:descripcionArticulo", "Nuevo");
  selenium.click("j_id_jsp_815202587_1:j_id_jsp_815202587_35");
  selenium.waitForPageToLoad("30000");
 }
}

Una vez definida la prueba vamos ahora a automatizarla. Para ello usaremos JUnit y la herramienta Selenium RC (Remote Control). También usaremos el plugin de Selenium para Maven, que permite arrancar el servidor de Selenium RC cuando se ejecutan las pruebas.

Creamos un proyecto de Maven con el siguiente pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.roldan</groupId>
 <artifactId>RevisteroPruebasSelenium</artifactId>
 <version>0.0.1-SNAPSHOT</version>  
 <dependencies>
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>3.8.2</version>
   <scope>test</scope>
  </dependency>       
  <dependency>
   <groupId>org.seleniumhq.selenium.client-drivers</groupId>
   <artifactId>selenium-java-client-driver</artifactId>
   <version>1.0.1</version>
   <scope>test</scope>
  </dependency>
 </dependencies>  
 <build>
  <plugins>
   <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>selenium-maven-plugin</artifactId>
    <executions>
     <execution>
      <phase>process-test-classes</phase>
      <goals>
       <goal>start-server</goal>
      </goals>
      <configuration>
       <background>true</background>
      </configuration>
     </execution>
    </executions>
   </plugin>
  </plugins>
 </build>
</project>

Vemos que además de configurar el plugin de Maven para Selenium para que arranque el servidor de Selenium en la fase anterior a la de test (process-test-classes), define dos dependencias, JUnit y el driver de cliente Java para Selenium, que permite ejecutar los tests creados desde Selenium IDE.

Vamos a adaptar la clase de test generada desde Selenium IDE para que haga uso del driver de Java para Selenium:

package com.roldan.selenium;

import com.thoughtworks.selenium.*;

public class CrearNuevoArticuloTest extends SeleneseTestCase {
 
 protected DefaultSelenium createSeleniumClient(String url) throws Exception {
  return new DefaultSelenium("localhost", 4444, "*firefox", url);
 }
 
 public void testCrearNuevoArticulo() throws Exception {
  DefaultSelenium selenium = createSeleniumClient("http://localhost:8080/");
   selenium.start(); 
  
  selenium.open("/RevisteroMyFacesWeb/");
  selenium.click("link=Nuevo Artículo");
  selenium.waitForPageToLoad("30000");
  selenium.type("j_id_jsp_815202587_1:nombreArticulo", "Nuevo");
  selenium.type("j_id_jsp_815202587_1:descripcionArticulo", "Nuevo");
  selenium.click("j_id_jsp_815202587_1:j_id_jsp_815202587_35");
  selenium.waitForPageToLoad("30000");
  
  selenium.stop();
 }
}

La diferencia está en que ahora al comienzo de la prueba se crea un cliente de Selenium y al final de la prueba se cierra este cliente.

Si ahora se lanzan los test para este proyecto con mvn test, se verá aparecer un navegador que repite la prueba definida, y se habrá grabado otro artículo más.

Referencias:
Web de Selenium HQ
Turorial de Adictos al trabajo sobre Selenium IDE
Turorial de Adictos al trabajo sobre Selenium RC
Tutorial de Dos Ideas sobre tests secuenciales con Selenium y JUnit
Web del plugin de Selenium para Maven

Patrones de diseño

2010-01-08T20:25:00.016+01:00

Cada vez que se comienza el desarrollo de una nueva aplicación, como ingenieros de software nos volvemos a enfrentar a los mismos o similares problemas que ya se han encarado en anteriores desarrollos. No sólo esto, nos estamos enfrentando en muchos casos a los mismo problemas que otros ya han tenido que resolver.

Aprovechar todo el conocimiento anterior es útil y permite ganar tiempo en el diseño y desarrollo de nuevas aplicaciones. Esto es algo de sobra conocido y por ello han surgido los patrones de diseño, como pautas a seguir en determinadas condiciones avaladas por el conocimiento previo.

En la construcción, el arquitecto Christopher Alexander propuso el aprendizaje y uso de una serie de patrones para la construcción de edificios de una mayor calidad. Según sus palabras, "cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez."

Los patrones que Christopher Alexander y sus colegas definieron son un intento de formalizar y plasmar de una forma práctica generaciones de conocimiento arquitectónico. Los patrones no son principios abstractos que requieran su redescubrimiento para obtener una aplicación satisfactoria, ni son específicos a una situación particular o cultural; son algo intermedio. Un patrón define una posible solución correcta para un problema de diseño dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones.

Llevando la idea de patrón al mundo de la informática, un patrón de diseño es una solución a un problema de diseño que debe poseer las siguientes características:

Debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores.
Debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Los patrones de diseño tuvieron un gran éxito a partir de la publicación del libro Design Patterns escrito por el grupo Gang of Four (GoF, en el que se recogían 23 patrones de diseño comunes. Estos patrones definidos por el GoF están divididos en 3 grupos, patrones creacionales, estructurales y de comportamiento.

Patrones creacionales: Tratan de solucionar los problemas que pueden surgir en la creación de objetos.

Abstract Factory: Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.
Factory Method: Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.
Builder: Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.
Prototype: Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
Singleton: Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.

Patrones estructurales: Tratan de facilitar el diseño identificando formas simples de establecer relaciones entre entidades.

Adapter: Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.
Bridge: Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.
Composite: Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
Decorator: Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
Facade: Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
Flyweight: Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
Proxy: Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.

Patrones de comportamiento: Identifican patrones comunes de comunicación entre objetos y tratan de incrementar la flexibilidad de esta comunicación.

Chain of Responsibility: Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.
Command: Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.
Interpreter: Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
Iterator: Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
Mediator: Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.
Memento: Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.
Observer: Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
State: Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.
Strategy: Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
Template Method: Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.
Visitor: Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.

Con el tiempo, han ido surgiendo nuevos patrones, sobre todo dentro del ámbito del desarrollo Java empresarial. Algunos de ellos son:

Controlador frontal
Modelo Vista Controlador (MVC)
Vista de composición
Fachada de sesión - Sesion Facade
Localizador de servicio - Service Locator
Objeto valor - Value object
Objeto de Transferencia de Datos - Data Transfer Object (DTO)
Delegado de empresa - Bussiness Delegate
Objeto de acceso a datos - Data Access Object (DAO)
Dependency Injection(DI) - Inversion of Control (IoC)
Open Session In View (OSIV)
ThreadLocal Session

En este artículo sólo he tratado de dar una introducción a los patrones de diseño. En posteriores artículos trataré de desarrollar algunos de los patrones aquí expuestos analizando su utilidad, virtudes y defectos.

Referencias:
Design Patterns (Erich Gamma, Richard Helm, Ralph Johnson, Hohn Vlissides)
Professional Java Server Programming J2EE, 1.3 Edition (Subrahmanyam Allamaraju, Cedric Beust, Marc Wilcox, Sameer Tyagi, Rod Johnson, Gary Watson, Alan Williamson, John Davies, Ramesh Nagappan, Andy Longshaw, P. G. Sarang, Tyler Jewell, Alex Toussaint)
Patrones de diseño en Wikipedia
Introducción al diseño con patrones por Manuel Lagos Torres
Patrones de diseño en ingenierosoftware.com

Spring in Action Second Edition

2009-12-25T16:46:00.006+01:00

Spring es un framework Java que trata de simplificar el desarrollo de aplicaciones Java basándose en la inyección de dependencias y la programación orientada a aspectos. En este libro, Craig Walls hace una explicación exhaustiva de Spring cubriendo todas las capas del desarrollo de una aplicación.

El libro consta de los siguientes capítulos:

Pasar a la acción: Se presenta Spring y los módulos que lo componen. Se introducen los conceptos principales de Spring, la inyección de dependencias y la programación orientada a aspectos.

Conexión básica de beans: Se presentan los distintos tipos de contenedores de beans, las fábricas de bean y los contextos de aplicación. A continuación se ve cómo crear beans en un contenedor y cómo inyectar valores y propiedades en ellos mediante inyección de dependencias. Después se muestra qué es la autoconexión de beans y, por último, se explica cómo controlar la creación de beans a través de métodos de inicio y destrucción del bean.

Conexión avanzada de beans: Se muestran conceptos avanzados del contenedor de beans de Spring. Primero se ve cómo declarar beans padre de los que otros beans hijos pueden heredar propiedades. Después se enseña la inyección de métodos. Luego se pasa a la inyección de beans que no han sido creados dentro del contenedor de Spring. También se ve cómo registrar editores de propiedades y cómo trabajar con beans especiales de Spring que se integran en el ciclo de vida de otros bean. Por último, se ve cómo crear beans con lenguajes dinámicos como Ruby, Groovy o Beanshell.

Notificaciones a beans: En primer lugar, se hace una introducción a la programación orientada a aspectos (AOP). Posteriormente se explica cómo crear aspectos clásicos de Spring y qué es el autoproxying. Después se ve la declaración de aspectos POJO y cómo se pueden inyectar aspectos creados con AspectJ.

Peticiones a la base de datos: Se examinan las capacidades de acceso a base de datos que ofrece Spring, y su fillosofía de acceso a datos a través de plantillas. Posteriormente se ve cómo se puede integrar Spring con JDBC puro o con ORMs como Hibernate, JPA o iBatis. Por último, se muestran las capacidades de cacheo en Spring.

Gestión de transacciones: Se revisa la gestión de transacciones en Spring, comenzando por una explicación de sus conceptos fundamentales. Después se enumeran los distintos gestores de transacciones disponibles y se explica cómo manejar las transacciones en Spring, tanto de forma programática como de forma declarativa

Seguridad en Spring: Se hace una introducción a la seguridad en Spring, que se implementa mediante la antigua librería Acegi Security. Posteriormente vamos viendo cómo se autentican los usuarios y se controla el acceso. Finalmente se ve cómo asegurar una aplicación web y cómo asegurar las invocaciones a métodos.

Servicios remotos basados en Spring y POJO: Se ve cómo implementar y consumir servicios remotos en Spring mediante RMI, Hessian, Burlap, Spring HttpInvoker y Web Services.

Construcción de servicios web contract-first en Spring: Comienza con una introducción a Spring-WS, un framework que permite construir servicios web a partir de un contrato definido en primer lugar. Después se ve cómo se manejan los mensajes de estos servicios mediante puntos finales de servicio y como juntar todo esto para la creación de un servicio. Para terminar, se ve cómo consumir servicios web usando Spring-WS.

Mensajería Spring: Se explica qué es JMS y cómo se puede usar desde Spring. Después se explica cómo construir POJOS dirigidos por mensajes y, por último, cómo utilizar RPC basado en mensajes, en contraposición a los servicios remotos vistos en el capítulo 8.

Spring y Enterprise Java Beans: Se muestra cómo conectarse a EJBs desde Spring. Después se ve cómo desarrollar EJBs que puedan aprovecharse de las capacidades de Spring. Por último, se ve cómo utilizar anotaciones EJB 3, a través del proyecto Pitchfork, para realizar inyección de dependencia y AOP en Spring.

Acceso a servicios empresariales: En este capítulo se estudia el uso en Spring de capacidades empresariales como JNDI, correo electrónico JMS, planificación de tareas y gestión de beans mediante JMX.

Manejo de peticiones Web: Se introduce el marco MVC de Spring para la capa web, en el que las peticiones son manejadas por controladores. Se ve cómo mapear las peticiones a los controladores de la aplicación y los distintos tipos de controladores que se pueden utilizar. También se ve cómo se manejan las excepciones que se pueden producir durante el procesamiento de estos controladores.

Mostrar vistas Web: Se ve cómo Spring MVC resuelve la vista que debe mostrar como respuesta a una petición. Se examinan las diferentes posibilidades, como JSP, con o sin Tiles, y otras alternativas a JSP, como Velocity y Freemarker. También se ve cómo es posible generar salida no-HTML, como documentos de Excel o PDFs.

Spring Web Flow: Se explica qué es Spring Web Flow, un marco de trabajo que permite definer el flujo de navegación de una aplicación. Se ve cómo se puede definir el flujo de la aplicación desde los conceptos básicos hasta técnicas más avanzadas. También se ve cómo se puede integrar Spring Web Flow con otros frameworks web como Struts o JSF.

Integración con otros marcos de trabajo Web: Se explica cómo se pueden utilizar las capacidades empresariales de Spring junto con otros conocidos frameworks web como Struts, WebWork/Struts2, Tapestry, JSF y aplicaciones Ajax con DWR.

Este libro es sencillo de leer y te va introduciendo paulatinamente dentro de Spring, explicando los conceptos principales y utilizando gran parte de sus funcionalidades. A mí me ha servido para aprender Spring desde cero, así como para entender la inyección de dependencias y la programación orientada a aspectos.

(ACTUALIZACION 26/10/2011: Ya está disponible la tercera versión de este libro, actualizada a Spring 3.)

Hibernate in Action Second Edition

2009-12-13T16:50:00.007+01:00

Este libro, escrito por Christian Bauer y Gavin King, es una revisión de otro libro anterior, Hibernate in Action. Está actualizado a la versión 3 de Hibernate y, además, presenta el estándar de persistencia de de EJB 3.0 (JPA).

Se trata de un libro de referencia no sólo para Hibernate, sino también para JPA. En él se puede encontrar información de introducción a estas dos tecnologías ORM, enseña a realizar con éxito los mapeos de objetos a entidades relacionales, explica el funcionamiento interno de Hibernate y cómo optimizar su comportamiento y da pautas sobre cómo construir aplicaciones que hagan uso Hibernate y/o JPA.

Consta de los siguientes capítulos:

Comprender la persistencia objeto/relacional: Se hace una introducción a los problemas de la persistencia en aplicaciones orientadas a objetos que usan bases de datos relacionales, explicando los desajustes que se producen entre estas dos tecnologías. Se presentan las distintas alternativas existentes para la capa de persistencia y se presentan los ORM como la solución que nos permite abstraernos de los desajustes anteriormente mencionados.

Comenzar un proyecto: Se presentan las posibles alternativas de desarrollo con Hibernate, dependiendo de si empezamos desde un modelo de clases o desde un modelo relacional. A continuación se muestra la configuración de Hibernate en un proyecto y se implementa el mismo proyecto de distintas formas: usando Hibernate y mapeo XML, anotaciones, JPA mediante el Hibernate EntityManager y componentes EJB. Posteriormente se hace una introducción a la ingeniería inversa con Hibernate dada una base de datos. Por último, se presenta cómo se integra Hibernate con otros servicios de la plataforma JEE como JTA, JNDI y JMX.

Modelos de dominio y metadatos: Se presenta el modelo de dominio de ejemplo que se utilizará en el libro, un sistema de subastas. Se presentan las pautas para la implementación de este modelo, como el desarrollo de POJOs. A continuación se muestran las distintas alternativas para los metadatos de mapeo, XML, anotaciones, XDoclet y de forma programática en la ejecución. Por último se presentan representaciones alternativas de las entidades mediante mapas y XML.

Mapear clases persistentes: Se explica la diferencia entre las entidades y los tipos de valor. También se ve el concepto de identidad en Hibernate. Después se ven algunas opciones para el mapeo de clases. Por último, se ve como mapear tipos de valor, tanto para tipos de datos Java como para clases.

Herencia y tipos personalizados: Se muestran las distintas formas de manejar la herencia en Hibernate. También se ve el conjunto de tipos de datos que ofrece Hibernate y explica como crear tipos de datos personalizados.

Mapear colecciones y asociaciones de entidades: Se presentan los distintos tipos de colecciones que maneja Hibernate y se muestra cómo mapear colecciones de tipos de valor tanto en el caso de tipos simples como de clases. Posteriormente se ve cómo mapear una relación padre/hijo entre entidades.

Mapeo avanzado de asociaciones de entidades: Se continúa viendo cómo mapear relaciones entre entidades, tanto relaciones simples como múltiples. También se ven las asociaciones polimórficas entre entidades.

Bases de datos heredadas y SQL personalizado: Se comentan los principales problemas en la integración con bases de datos heredadas. Después se estudia la personalización del SQL que genera Hibernate en las consultas, y se ve la integración de procedimientos almacenados y funciones. Por último, se muestra cómo mejorar el DDL generado por Hibernate para personalizar los nombres y los tipos de datos, añadir restricciones o crear índices.

Trabajar con objetos: En este capítulo se comienza exponiendo el ciclo de vida de los objetos persistentes y después se habla de los conceptos de identidad e igualdad de objetos, introduciendo las conversaciones y el ámbito de identidad de un objeto. A continuación se ven los interfaces de persistencia de Hibernate y de JPA, terminando con una explicación de cómo usar JPA en componentes EJB.

Transacciones y concurrencia: Se revisan los conceptos básicos de las transacciones en las bases de datos y cómo pueden ser manejadas en Hibernate y JPA. También se trata el control del acceso concurrente en las bases de datos, revisando el control optimista de la concurrencia y cómo se pueden obtener garantías adicionales en el aislamiento. Por último, se estudia el acceso no transaccional, viendo en qué casos se puede trabajar en modo autocommit tanto con Hibernate como con JPA.

Implementando conversaciones: Se comienza viendo cómo se propaga la sesión en Hibernate, que puede ser a través de una variable thread-local, a través de JTA o mediante EJBs. Después se ve cómo se pueden implementar convesaciones en Hibernate, JPA y EJB a través de objetos “separados” (detached) y extendiendo la sesión.

Modificar objetos eficientemente: En primer lugar se estudia la persistenca transitiva de objetos a través de las asociaciones en cascada, tanto con Hibernate como con JPA. Posteriormente se pasa a ver cómo manejar operaciones que implican grandes volúmenes de datos a través de HQL y JPA QL y cómo procesar lotes. Por último, se ve cómo filtrar los datos de las consultas y cómo interceptar eventos en Hibernate.

Optimizar la recuperación y el cacheo: Comenzamos viendo cómo definir el plan de obtención de datos en Hibernate y se dan pautas de qué estrategia elegir y cóm optimizarla. Posteriormente se exponen los principios de cacheo en Hibernate y se explica cómo establecer una cache de segundo nivel a través de proveedores de cache.

Hacer consultas con HQL y JPA QL: Veremos cómo crear y ejecutar consultas a base de datos. Se aprenderá a crear consultas básicas con HQL y JPA QL y cómo se usan las joins, las consultas de informes y las subselects.

Opciones de consulta avanzadas: En este capítulo se ve cómo usar las APIs Criteria y Example para construir consultas de forma programática. También se ve cómo hacer consultas nativas en SQL. Después se ve cómo filtrar colecciones, y, por último, se habla del cacheo de resultados de consultas y en qué casos es conveniente hacerlo.

Crear y probar aplicaciones en capas: En este capítulo se dan pautas para el diseño de aplicaciones web con Hibernate, a través de patrones como OSIV (Open Session In View), Command y DAO (Data Access Object). También se trata el diseño de aplicaciones con EJB 3.0. Por último, se trata el tema de cómo probar estas aplicaciones y se presentan herramientas como TestNG y DBUnit.

Introducción a JBoss Seam: En este capítulo se hace un introducción al marco de trabajo JBoss Seam, un marco de trabajo orientado a Java EE 5.0 que se base en JSF y EJB 3.0. Se ve cómo mejorar una aplicación usando este marco, cómo utilizar componentes contextuales, cómo validar los datos de entrada y cómo simplificar la persistencia.

Se trata de un libro difícil de leer de corrido por la complejidad de los temas que trata. Sin embargo, creo que es un libro de referencia excelente sobre Hibernate y JPA.

Control de versiones con ClearCase

2009-12-11T11:25:00.005+01:00

Rational ClearCase es el sistema de control de versiones de IBM. Aunque Subversion es más de mi agrado por su sencillez, esta herramienta es la que utilizo en el trabajo. Estamos teniendo un montón de problemas trabajando con ella, aunque estoy convencido que es más por desconocimiento que por la herramienta en sí. Así que voy a exponer a continuación que es ClearCase, cómo lo usamos y qué problemas estamos encontrando de cara a compartir experiencias con otros usuarios de ClearCase.

Cómo otros sistemas de control de versiones, ClearCase almacena distintas versiones de los elementos que forman parte de un proyecto, que pueden ser directorios o archivos. Estos elementos se almacenan en un repositorio que en ClearCase se llama base de objetos de versionado (VOB).

ClearCase proporciona un proceso de gestión de la configuración llamado gestión del cambio unificado (UCM). UCM se situa sobre la base de ClearCase simplificando el trabajo.

En UCM un proyecto es un producto de un desarrollo de software que contiene información de configuración sobre el mismo. Un proyecto está formado por componentes, que constituyen las partes de un proyecto, como módules web o módulos JAR en un proyecto Java.

Las modificaciones que se llevan a cabo durante las tareas de desarrollo dentro de la ejecución de un proyecto se registran en actividades, que consisten en varias versiones de distintos elementos de un componente.

Un proyecto consta de un área de trabajo compartido y muchas áreas de trabajo privadas. Cada área de trabajo está formada por una corriente y una o varias vistas. Una corriente es un objeto de ClearCase que mantiene una lista de actividades y líneas base que determinan que versiones de elementos aparecen en la vista. Una vista es un árbol de directorio que muestra una única versión de cada archivo del proyecto.

Todo proyecto tiene un área de trabajo compartido que se maneja mediante una corriente y una vista de integración. Su función es registrar las líneas base del proyecto y recibir las nuevas versiones de los elementos compartidos del proyecto para su integración conjunta.

Cada línea base representa una versión de los elementos de un componente en un determinado momento del desarrollo. A lo largo del proyecto, el administrador crea y recomienda líneas base para reflejar hitos del proyecto.

Según UCM, los desarrolladores tienen un área de trabajo privada donde realizan sus cambios. Esta área de trabajo consta una de corriente de desarrollo que mantiene la lista de actividades del desarrollador y determina qué versiones de los elementos del proyecto aparecen en su vista de desarrollo.

Cuando los desarrolladores se unen a un proyecto incluyen en sus áreas de trabajo las versiones de los elementos del proyecto marcados en la línea base recomendada del proyecto. Éstos harán sus cambios dentro de actividades en su área de trabajo privada y, una vez finalizados y probados, harán entrega (deliver) de estas actividades a la corriente de integración, lo que podría llevar a tener que combinar elementos si otro desarrollador ha hecho modificaciones en los mismos elementos.

Periódicamente, los desarrolladores deben hacer rebase para actualizarse a las últimas líneas base recomendadas. Si las líneas base incluyen nuevas versiones de los elementos que se están modificando en la vista de desarrollo, la operación de rebase fusiona las dos versiones en una nueva versión dentro de la corriente de desarrollo.

Lo explicado hasta ahora es el proceso de gestión de la configuración que define UCM, que implica que cada desarrollador tiene su propio área de trabajo privada. Esto permite que los desarrolladores trabajen de forma paralela e independiente sin colisionar entre ellos a la hora de modificar los mismo elementos. Estos serán fusionados posteriormente en las operaciones de deliver y rebase.

Sin embargo, esto añade carga de gestión al desarrollo, porque para ver las últimas modificaciones de otro desarrollador es necesario que haya entregado sus actividades, se haya hecho una nueva línea base y los otros desarrolladores hagan un rebase.

Para aligerar esta carga, nosotros usamos una única área de desarrollo para todos los desarrolladores, que tienen vistas a ella. Todos los cambios que un desarrollador registra pueden ser vistos por los demás desarrolladores sin más que hacer un update de su vista, permitiendo que los nuevos cambios se publiquen de manera más inmediata.

Sin embargo, si todos los desarrolladores están desarrollando en vistas de la misma corriente, se pueden producir situaciones no deseadas:

Modificaciones concurrentes de los mismos archivos

Un desarrollador desaA está modificando un archivo fich1, para lo cual lo ha reservado (check out).
Otro desarrollador desaB también quiere modificar este archivo, y, si no quiere quedarse bloqueado en su trabajo, lo reserva (check out) después de que aparece un aviso de que el desarrollador desaA lo ha reservado previamente.
El desarrollador desaA sube (check in) el archivo con sus modificaciones.
El desarrollador desaB sube (check in) el archivo con sus modificaciones, pero en ese momento ClearCase le avisa de que en el repositorio hay una versión de este archivo posterior a aquella que reservó, por lo que debe fusionar las dos versiones (merge). Este merge puede ser automático o manual, a través de la herramienta de ClearCase para esto.
Este problema, que con un solo archivo puede ser fácil de solucionar, se complica cuando se están modificando varios archivos que coinciden por parte de varios desarrolladores. Se puede llegar a situaciones de bloqueo, por ejemplo, si un desarrollador no puede actualizarse un archivo que ha modificado otro desarrollador y es necesario para que los cambios en otros archivos compilen sin error porque el archivo necesario está reservado y siendo modificado por el desarrollador. Se puede llegar a situaciones difíciles de salir.

Dependencia entre actividades no relacionadas

Un desarrollador desaA está realizando modificaciones dentro de una actividad activA que implican a los ficheros fich1, fich2 y fich3.
Comienza reservando (check out) fich1, haciendo los cambios pertinentes y subiéndolo (check in) al repositorio, y después pasa a reservar fich2 y modificarlo.
En ese momento, otro desarrollador desaB realiza otras modificaciones distintas dentro de otra actividad activB que implican modificar el fichero fich2, previamente modificado en la actividad activA de desaA.
Por necesidades del proyecto, hace falta crear una nueva versión (línea base) del proyecto sólo con la modificación realizada en la actividad activB y no las modificaciones de activA. Por ejemplo, porque activB es una corrección de un bug que queremos solucionar rapidamente en producción, pero activA es un nuevo desarrollo que no queremos subir hasta no haberlo probado concienzudamente.
Al tratar de subir la actividad activB, ClearCase nos dirá que esta actividad depende de la actividad activA y que también hay que subirla. Esto es debido a que la modificación del fichero fich2 se hizo sobre la versión modificada en la actividad activA.
Resultado, no se puede subir activB de forma independiente de activA. Y este problema se puede complicar exponencialmente a mayor número de desarrolladores.

Conclusión, hay que evitar que varios desarrolladores modifiquen los mismo archivos por el bien de la productividad del equipo y de la facilidad en la gestión del proyecto. Lo cual me hace pensar que lo mejor sería un área de desarrollo privada por cada desarrollador como dicta UCM, pero esta forma de trabajar, que también usamos en otro proyecto aumentaría el número de merges de forma considerable con el riego que conllevan.

Aquí os pido colaboración. ¿Alguien tiene experiencia con ClearCase? Me gustaría saber qué estrategias se están usando en otros proyectos y cómo solucionan todos estos problemas.

Referencias:
Introducción a Rational ClearCase LT (Rosa María Carretero López)
ClearCase en Wikipedia
Comparación de software de control de versiones

Manifiesto en defensa de los derecho fundamentales en Internet

2009-12-04T21:48:00.002+01:00

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Configuración de Log4j en una aplicación web

2009-11-27T19:20:00.003+01:00

Log4j es una librería que permite guardar registros informativos sobre el funcionamiento de una aplicación. En este artículo vamos a ver cómo configurar Log4j para su uso en una aplicación web.

En primer lugar vamos a crear en Eclipse un proyecto war Maven que se llame PruebaLog4jWeb. Crearemos también una página de inicio index.jsp y desplegaremos la aplicación en un servidor. La URL de la aplicación será http://localhost:8080/PruebaLog4jWeb/.

Añadimos la dependencia a la API de servlets para poder trabajar en nuestro proyecto con sus clases. Esta librería no hace falta desplegarla en el servidor, puesto que éste tendrá su propia implementación de esta API:

<dependency>
 <groupId>javax.servlet</groupId>
 <artifactId>servlet-api</artifactId>
 <version>2.5</version>
 <scope>provided</scope>
</dependency>

Añadimos la dependencia a Log4j en el pom.xml del proyecto:

<dependency>
 <groupId>log4j</groupId>
 <artifactId>log4j</artifactId>
 <version>1.2.15</version>
</dependency>

Ahora vamos a crear el siguiente servlet:

package com.roldan.log4j;

import java.io.IOException;

import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.log4j.Logger;

public class ServletPrueba extends HttpServlet {

 private static final long serialVersionUID = 1L;

 static Logger logger = Logger.getLogger(ServletPrueba.class);
 
 public ServletPrueba() { }

 protected void doGet(
  HttpServletRequest request, 
  HttpServletResponse response) 
  throws ServletException, IOException {
  
  logger.debug("Se ha llamado al servlet mediante un GET.");
  
  execute(request, response);
 }

 protected void doPost(
  HttpServletRequest request, 
  HttpServletResponse response) 
  throws ServletException, IOException {
  
  logger.debug("Se ha llamado al servlet mediante un POST.");
  
  execute(request, response);
 }
 
 protected void execute(
  HttpServletRequest request, 
  HttpServletResponse response) 
  throws ServletException, IOException {
  
  logger.info("Se redirige a la página de inicio.");
  
  RequestDispatcher rd = 
   request.getRequestDispatcher("index.jsp");
  rd.forward(request, response);
 }
}

En él hemos creado un logger estático de Log4j que usamos en los distintos métodos del servlet para mostrar logs con distinto grado de importancia.

Para configurar la salida de los logs tenemos que crear un archivo log4j.properties, donde definiremos cómo queremos que se muestren los logs. Vamos a mostrar los logs de nuestra aplicación tanto por consola como en un archivo:

log4j.logger.com.roldan.log4j=debug, stdout, file

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

# Pattern to output the caller's file name and line number.
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=example.log

log4j.appender.file.MaxFileSize=100KB
# Keep one backup file
log4j.appender.file.MaxBackupIndex=1

log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%p %t %c - %m%n

Por último, debemos inicializar Log4j dentro de cada aplicación web, para que cada aplicación pueda trabajar satisfactoriamente de modo independiente. Para ello, vamos a incluir en la aplicación el siguiente servlet de inicialización:

package com.roldan.log4j;

import org.apache.log4j.PropertyConfigurator;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class Log4jInit extends HttpServlet {

 public void init() {
  String prefix =  getServletContext().getRealPath("/");
  String file = getInitParameter("log4j-init-file");

  if(file != null) {
   PropertyConfigurator.configure(prefix+file);
  }
 }

 public void doGet(HttpServletRequest req, HttpServletResponse res) {}
}

E incluiremos la siguiente configuración en el archivo web.xml:

<servlet>
 <servlet-name>log4j-init</servlet-name>
 <servlet-class>com.roldan.log4j.Log4jInit</servlet-class>
 <init-param>
  <param-name>log4j-init-file</param-name>
  <param-value>WEB-INF/log4j.properties</param-value>
 </init-param>
 <load-on-startup>1</load-on-startup>
</servlet>

Cuando redesplegamos y ejecutamos la aplicación llamando al servlet mediante la URL http://localhost:8080/PruebaLog4jWeb/ServletPrueba se muestran los siguientes logs en la consola:

DEBUG [http-8080-2] (ServletPrueba.java:23) 
 - Se ha llamado al servlet mediante un GET.
INFO [http-8080-2] (ServletPrueba.java:39) 
 - Se redirige a la página de inicio.

Referencias:
http://logging.apache.org/log4j/1.2/index.html
http://logging.apache.org/log4j/1.2/manual.html

Configuración de EhCache en Spring

2009-11-18T15:51:00.012+01:00

En este artículo vamos a ver cómo se puede acceder a los datos almacenados en una base de datos a través de una plantilla JDBC de Spring. Para mejorar el rendimiento en este acceso a base de datos introduciremos también una caché usando EhCache que permita almacenar las consultas ya obtenidas evitando el acceso a la base de datos.

En primer lugar, creamos en Eclipse un proyecto Maven e incluimos las dependencias necesarias en el archivo pom.xml del proyecto:

<project
 xmlns="http://maven.apache.org/POM/4.0.0" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.roldan.spring</groupId>
 <artifactId>PruebaCache</artifactId>
 <version>0.0.1-SNAPSHOT</version>  
 <dependencies>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring</artifactId>
   <version>2.5.6</version>
  </dependency>
  <dependency>
   <groupId>log4j</groupId>
   <artifactId>log4j</artifactId>
   <version>1.2.15</version>
  </dependency>
  <dependency>
   <groupId>mysql</groupId>
   <artifactId>mysql-connector-java</artifactId>
   <version>5.1.10</version>
  </dependency>
  <dependency>
   <groupId>org.springmodules</groupId>
   <artifactId>spring-modules-cache</artifactId>
   <version>0.7</version>
  </dependency>
  <dependency>
   <groupId>net.sf.ehcache</groupId>
   <artifactId>ehcache</artifactId>
   <version>1.6.2</version>
  </dependency> 
 </dependencies>
</project>

Las dependencias necesarias para nuestro proyecto son:

El framework Spring.
Log4j para sacar logs informativos sobre la ejecución de la aplicación.
El conector a base de datos MySql.
El módulo de cache del proyecto spring-modules, que permite integrar la herramienta EhCache con Spring de forma sencilla.
La herramienta de cacheo EhCache.

Posteriormente hemos creado una base de datos (pruebacache) con una única tabla (elementos) cuyos elementos serán recogidos por las consultas que realiza la aplicación:

El objeto al que se mapean los registros de esta tabla está definido en la siguiente clase:

package com.roldan.spring.model;

public class Elemento {
 
 private int id;
 private String descripcion;
 private int grupo;
 
 public int getId() {
  return id;
 }
 public void setId(int id) {
  this.id = id;
 }
 public String getDescripcion() {
  return descripcion;
 }
 public void setDescripcion(String descripcion) {
  this.descripcion = descripcion;
 }
 public int getGrupo() {
  return grupo;
 }
 public void setGrupo(int grupo) {
  this.grupo = grupo;
 }
}

A continuación se muestra el archivo de configuración de Spring, spring-config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ehcache="http://www.springmodules.org/schema/ehcache"
 xmlns:jdbc="http://www.springmodules.org/schema/jdbc"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
  http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
  http://www.springframework.org/schema/jdbc 
  http://www.springframework.org/schema/jdbc/spring-jdbc-3.0.xsd
  http://www.springmodules.org/schema/ehcache
  http://www.springmodules.org/schema/cache/springmodules-ehcache.xsd">
 <bean id="datasource"
           class="org.springframework.jdbc.datasource.DriverManagerDataSource">
  <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
  <property name="url" value="jdbc:mysql://localhost/pruebacache"/>
  <property name="username" value="root"/>
  <property name="password" value="root"/>
 </bean>
 <bean id="jdbcTemplate"
            class="org.springframework.jdbc.core.JdbcTemplate">
  <property name="dataSource" ref="datasource"/>
 </bean>
 <bean id="elementoDao" class="com.roldan.spring.dao.ElementoDaoImpl">
  <property name="jdbcTemplate" ref="jdbcTemplate"/>
 </bean>
 <ehcache:config configLocation="classpath:ehcache.xml"/>
 <ehcache:proxy id="proxyElementos" refId="elementoDao">
  <ehcache:caching methodName="get*" cacheName="cacheElementos"/>
 </ehcache:proxy>
</beans>

En este archivo se configuran los siguientes beans:

Un datasource sencillo a nuestra base de datos.
Una plantilla de acceso a JDBC de Spring.
Un objeto de acceso a datos para recuperar elementos de la base de datos.
Un bean proxy que permite incorporar cacheo en las llamadas al bean DAO.

En cuanto al los beans datasource y jdbcTemplate, no hay que hacer más que seguir las instrucciones de configuración de Spring. El bean elementDao pertenece a la clase ElementDaoImpl que implementa la interfaz ElementDao. A continuación vemos la implementación de la clase ElementDaoImpl:

package com.roldan.spring.dao;

import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.List;

import org.apache.log4j.Logger;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.RowMapper;

import com.roldan.spring.Prueba;
import com.roldan.spring.model.Elemento;

public class ElementoDaoImpl implements ElementoDao {
 
 private static Logger logger = 
  Logger.getLogger(ElementoDaoImpl.class);
 
 public static final String RECUPERAR_ELEMENTOS = 
  "SELECT * FROM ELEMENTO WHERE GRUPO = ?";
 public static final String RECUPERAR_TODOS = 
  "SELECT * FROM ELEMENTO";
 
 public List getElements(int grupo) {
  List matches = jdbcTemplate.query(
    RECUPERAR_ELEMENTOS,
    new Object[] {Integer.valueOf(grupo)},
    new RowMapper() {
     public Object mapRow(ResultSet rs, int rowNum) 
      throws SQLException {      
      Elemento elemento = new Elemento();
      elemento.setId(rs.getInt(1));
      elemento.setDescripcion(rs.getString(2));
      elemento.setGrupo(rs.getInt(3));
      
      logger.info("Se mapea el elemento " + elemento.getId());
       
      return elemento;
     }
  });  
  return matches;
 }
 
 public List getAllElements() {
  List matches = jdbcTemplate.query(RECUPERAR_TODOS,
    new Object[] {},
    new RowMapper() {
     public Object mapRow(ResultSet rs, int rowNum) 
      throws SQLException {
      Elemento elemento = new Elemento();
      elemento.setId(rs.getInt(1));
      elemento.setDescripcion(rs.getString(2));
      elemento.setGrupo(rs.getInt(3));
      
      logger.info("Se mapea el elemento " + elemento.getId());
       
      return elemento;
     }
  });
  
  return matches;
 }

 JdbcTemplate jdbcTemplate;
 public void setJdbcTemplate(JdbcTemplate jdbcTemplate) {
  this.jdbcTemplate = jdbcTemplate;
 }
 public JdbcTemplate getJdbcTemplate() {
  return jdbcTemplate;
 }
}

Tras esto, sólo nos queda revisar la configuración de EhCache en Spring, realizada a través del módulo spring-modules-cache. En el archivo spring-config.xml vemos que se ha definido que el archivo de configuración de EhCache es ehcache.xml:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
 <defaultCache
  maxElementsInMemory="100"
  eternal="false"
  timeToIdleSeconds="120"
  timeToLiveSeconds="120"
  diskPersistent="false"
  diskExpiryThreadIntervalSeconds="120"
  memoryStoreEvictionPolicy="LFU"/>
 <cache name="cacheElementos"
  maxElementsInMemory="100"
  eternal="false"
  timeToIdleSeconds="300"
  timeToLiveSeconds="1"
  memoryStoreEvictionPolicy="LFU"/> 
</ehcache>

En este archivo se configura una cache por defecto, que es obligatoria, y una cache para las aplicación. En esta caché se pueden guardar hasta 300 elementos, y cada elemento se corresponde con una llamada a un método con unos determinados parámetros. Si se repiten llamadas al mismo método con los mismos valores de parámetros, el resultado de la llamada estará cacheado y no será necesario ir a la base de datos a recuperarlo.

Por ejemplo, si ejecutamos la siguiente clase de prueba:

package com.roldan.spring;

import java.util.List;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

import com.roldan.spring.dao.ElementoDao;
import com.roldan.spring.model.Elemento;

public class Principal {

 public static void main(String[] args) {
  ApplicationContext ctx = 
   new ClassPathXmlApplicationContext("spring-config.xml");

  ElementoDao elementoDao = (ElementoDao) ctx.getBean("proxyElementos");
  
  List elementos = elementoDao.getElements(1);
  for (Elemento elemento : elementos) {
   System.out.println(elemento.getDescripcion());
  }
  
  elementos = elementoDao.getAllElements();
  for (Elemento elemento : elementos) {
   System.out.println(elemento.getDescripcion());
  }
  
  elementos = elementoDao.getElements(1);
  for (Elemento elemento : elementos) {
   System.out.println(elemento.getDescripcion());
  }
 }
}

Se obtienen los siguientes logs:

…
DEBUG - Creating JDK dynamic proxy: target source is SingletonTargetSource for target object [com.roldan.spring.dao.ElementoDaoImpl@2a6f16]
DEBUG - Finished creating instance of bean 'proxyElementos'
DEBUG - Returning cached instance of singleton bean 'proxyElementos'
DEBUG - Attempt to retrieve a cache entry using key <1130820531|30562044> and cache model 
DEBUG - Retrieved cache element 
DEBUG - Executing prepared SQL query
DEBUG - Executing prepared SQL statement [SELECT * FROM ELEMENTO WHERE GRUPO = ?]
DEBUG - Fetching JDBC Connection from DataSource
DEBUG - Creating new JDBC DriverManager Connection to [jdbc:mysql://localhost/pruebacache]
INFO  - Se mapea el elemento 1
INFO  - Se mapea el elemento 3
DEBUG - Returning JDBC Connection to DataSource
DEBUG - Attempt to store the object <[com.roldan.spring.model.Elemento@7109c4, com.roldan.spring.model.Elemento@1385660]> in the cache using key <1130820531|30562044> and model 
DEBUG - Object was successfully stored in the cache
Primer elemento
Tercer elemento
DEBUG - Attempt to retrieve a cache entry using key <23191881|23191477> and cache model 
DEBUG - Retrieved cache element 
DEBUG - Executing prepared SQL query
DEBUG - Executing prepared SQL statement [SELECT * FROM ELEMENTO]
DEBUG - Fetching JDBC Connection from DataSource
DEBUG - Creating new JDBC DriverManager Connection to [jdbc:mysql://localhost/pruebacache]
INFO  - Se mapea el elemento 1
INFO  - Se mapea el elemento 2
INFO  - Se mapea el elemento 3
INFO  - Se mapea el elemento 4
DEBUG - Returning JDBC Connection to DataSource
DEBUG - Attempt to store the object <[com.roldan.spring.model.Elemento@4ecfdd, com.roldan.spring.model.Elemento@30d82d, com.roldan.spring.model.Elemento@c09554, com.roldan.spring.model.Elemento@18bf072]> in the cache using key <23191881|23191477> and model 
DEBUG - Object was successfully stored in the cache
Primer elemento
Segundo elemento
Tercer elemento
Cuarto elemento
DEBUG - Attempt to retrieve a cache entry using key <1130820531|30562044> and cache model 
DEBUG - Retrieved cache element <[com.roldan.spring.model.Elemento@7109c4, com.roldan.spring.model.Elemento@1385660]>
Primer elemento
Tercer elemento

Se pueden apreciar los siguientes pasos:

En la primera llamada se buscan todos los elementos que pertenecen al grupo 1. La llamada pasa por el proxy, que trata de buscar el resultado de esta llamada en la cache y, como no lo encuentra, acude a base de datos.
En la segunda llamada se buscan todos los elementos. Esta llamada también pasa por el proxy, que trata de buscar el resultado de esta llamada en la cache y, como no lo encuentra, acude a base de datos.
En la tercera llamada se buscan de nuevo todos los elementos que pertenecen al grupo 1. Al pasar por el proxy, éste reconoce que el resultado de la llamada está en la caché y que no hace falta acudir a la base de datos, ahorrándose la consulta.

Con esto, tenemos ya un ejemplo de cómo utilizar una cache en las consultas a base de datos en Spring.

Referencias:
http://www.dosideas.com/wiki/EhCache_Con_Spring

La Deuda Técnica

2009-11-12T22:11:00.009+01:00

¿Quién no se ha encontrado en el siguiente dilema? Tenemos que añadir una nueva funcionalidad al sistema y tenemos prisa. Podemos hacerlo rápido y de forma no óptima, más enrevesado o menos eficiente, satisfaciendo las exigencias de entrega. O podemos (si es que podemos…) saltarnos estas exigencias y sentarnos a pensar y hacerlo mejor, con diseño más claro y mantenible.

La Deuda Técnica es una metáfora ideada por Ward Cunningham que ayuda a pensar sobre este problema. Viene a decir que en caso de hacer las cosas rápido y de manera chapucera se incurre en una “deuda” que vamos a tener que pagar en el futuro, en forma de esfuerzo de desarrollo, como consecuencia de postergar el buen diseño en la implementación. Y a medida que se siga postergando este esfuerzo y el desarrollo deficiente se siga recubriendo con nuevos desarrollos que lo enmascaren o lo usen, esta deuda será cada vez más elevada y difícil de pagar.

No se quiere decir que no sea sensato incurrir en esta deuda. En ciertas ocasiones es una decisión acertada asumir esta deuda para resolver una situación determinada en un proyecto. Sin embargo, hay que tener en cuenta las repercusiones que puede tomar en el futuro y hay que tratar de satisfacer esta deuda cuanto antes para evitar que crezca desmesuradamente, es decir, que un mal planteamiento en una funcionalidad de la aplicación comprometa la buena marcha del proyecto en el futuro.

Sobre esta idea, Martin Fowler ha desarrollado el “Cuadrante de la Deuda Técnica”. Según él, una deuda técnica asumida en un proyecto puede clasificarse de dos formas:

Prudente o imprudente.

Advertida o inadvertida.

La combinación de estas clasificaciones produce cuatro situaciones distintas:

Deuda prudente y advertida: Se produce cuando somos conscientes de que estamos asumiendo un mal diseño para salir de una situación puntual, como una entrega. Posteriormente se debe evaluar la conveniencia de “pagar la deuda técnica” solucionando esta carencia en función del interés que acarree.

Deuda prudente e inadvertida: Se produce cuando, con el paso del tiempo, se descubren cómo se deberían haber hecho las cosas. Inevitable, ya que según avanza el proyecto, se aprende de él. Llegado el momento, también se debe evaluar si resulta interesante mejorar el diseño con lo que hemos aprendido o si esto implicaría un esfuerzo demasiado alto.

Deuda imprudente y advertida: Se deshecha el diseño porque se pretende acelerar el desarrollo. Según la “Hipótesis de Resistencia al Diseño”, esto se puede lograr hasta un punto determinado del proyecto en el que deja de ser posible conseguir un beneficio de obviar el diseño porque la calidad del código se degrada.

Deuda imprudente e inadvertida: No se conocen las técnicas de diseño ni se es consciente de que se están tomando decisiones incorrectas.

Conviene saber en qué situación nos encontramos. Si bien las tres primeras situaciones se pueden asumir en un momento determinado dentro de un proyecto, la última resulta mucho más peligrosa, porque implica no saber hacia dónde se dirige el proyecto.

Referencias:
La Deuda Técnica
El Cuadrante de la Deuda Técnica
La Hipótesis de Resistencia al Diseño

EclEmma: Visualizar la cobertura de los tests unitarios en Eclipse

2009-11-06T12:24:00.006+01:00

Hace algún tiempo publiqué un post sobre herramientas de calidad del código. A las que yo publiqué, Dirty Affairs añadió otra, EclEmma, a la cual he estado echando un vistazo.

EclEmma es una herramienta para Eclipse que permite visualizar la cobertura del código de los tests unitarios que hemos hecho. Existen otras herramientas como Cobertura, que generan informes, pero que no permiten visualizar esta informacuón de forma gráfica directamente en Eclipse.

EclEmma se instala en Eclipse de forma sencilla, desde Help -> Software Updates -> Available Software -> Add Site, se añade el sitio http://update.eclemma.org/ y pasamos a realizar la instalación del plugin.

Una vez instalado el plugin y reiniciado Eclipse, aparece una nueva opción en la barra de herramientas:

A través de este botón, podemos lanzar los tests de forma que EclEmma analizará qué parte del código se está cubriendo en ellos. Veamos un ejemplo práctico.

He creado una clase OperadorAritmético, que realiza las operaciones de suma y division:

package com.roldan.tests;
 
 public class OperadorAritmetico {
 
 public static int suma(int a, int b) {
  return a + b;
 }
 
 public static int division(int a, int b) throws Exception {
  if(b==0) {
   throw new Exception();
  }  
  return a / b;
 }
}

Para probar esta clase he creado una clase de test que, en principio, solo prueba la suma:

package com.roldan.tests;

import org.junit.Assert;
import org.junit.Test;

 public class OperadorAritmeticoTest {

 @Test
 public void suma() {
  
  int a = 5;
  int b = 3;
  
  int suma = OperadorAritmetico.suma(a, b);
  
  Assert.assertEquals(8, suma);
 } 
}

Ahora lanzamos las pruebas para el proyecto, sitándonos en la raíz del proyecto y yendo al botón de EclEmma antes mostrado, seleccionamos la opción Coverage as -> JUnit Test:

Vemos como las instrucciones de la clase OperadorAritmetico has sido coloreadas, con verde aquellas que han sido cubiertas en las pruebas y con rojo aquellas que no. La pestaña Coverage muestra el informe de cobertura del proyecto.

Ahora queremos arreglar un poco esta situación y hacer un prueba para la división:

@Test
public void division() {
  
 int a = 8;
 int b = 4;

 int division;
 try {
  division = OperadorAritmetico.division(a, b);
  Assert.assertEquals(2, division);
 } catch (Exception e) {
  Assert.fail();
 }
}

Si ahora volvemos a realizar las pruebas, vemos que la situación se ha mejorado, aunque todavía queda código sin cubrir:

De esta forma, podemos ir mejorando progresivamente la cobertura de las pruebas para asegurar el buen funcionamiento de nuestro código.

Referencias:
http://tratandodeentenderlo.blogspot.com/2009/10/herramientas-de-analisis-de-calidad-del.html
http://www.eclemma.org/
http://cobertura.sourceforge.net/

Lecturas anteriores

2009-11-05T15:06:00.018+01:00

En esta entrada simplemente se listan los libros que he leído y que vaya leyendo, por tanto, estará en constante actualización.

También espero que sirva para recibir recomendaciones sobre estos libros o sobre otros que puedan resultar interesantes.

The Agile Samurai (Jonathan Rasmusson)

The Pragmatic Programmer (Andrew Hunt, David Thomas)

Becoming agile in an imperfect world (Greg Smith, Ahmed Sidky)

Peopleware: Productive Projects and Teams (Second Edition) (Tom de Marco, Timothy Lister)

Extreme Programming Explained: Embrace Change (Kent Beck)

Design Patterns (Erich Gamma, Richard Helm, Ralph Johnson, Hohn Vlissides)

Implementation Patterns (Kent Beck)

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) (Frederick P. Brooks)

Clean Code: A Handbook of Agile Software Craftsmanship (Robet C. Martin)

Diseño Ágil con TDD (Carlos Blé Jurado, Juan Gutiérrez Plaza, Fran Reyes Perdomo y Gregorio Mena)

Ingeniería del software - Un enfoque práctico (Roger Pressman)

Kanban vs Scrum – a practical guide (Henrik Kniberg y Mattias Skarin)

Scrum and XP from the trenches (Henrik Kniberg)

UML 2 (Ila Neustadt, Jim Arlow)

Spring in Action (Craig Walls)

Java Persistence with Hibernate (Christian Bauer, Gavin King)

J2EE Development without EJB (Rod Johnson)

Version Control with Subversion (Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato)

Maven - The definitive guide (Sonatype)

J2EE Design & Development (Rod Johnson)

Jakarta Struts (Chuck Cavaness)

Java & XML (Brett McLaughlin)

Professional Java Server Programming J2EE, 1.3 Edition (Subrahmanyam Allamaraju, Cedric Beust, Marc Wilcox, Sameer Tyagi, Rod Johnson, Gary Watson, Alan Williamson, John Davies, Ramesh Nagappan, Andy Longshaw, P. G. Sarang, Tyler Jewell, Alex Toussaint)

Próximas lecturas

2009-11-03T10:33:00.021+01:00

Esta entrada no es más que una declaración de intenciones, una recopilación de los libros que tengo previsto leer proximamente. Por tanto, estará en constante actualización.

También espero que sirva para recibir recomendaciones sobre estos libros o sobre otros que puedan resultar interesantes.

Growing Object-Oriented Software Guided by Tests (Steve Freeman, Nat Pryce)

Patterns of Enterprise Application Architecture (David Fowler)

Head First Design Patterns (Eric T Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra)

Pruebas de base de datos con DbUnit

2009-10-30T12:45:00.003+01:00

Cuando se desarrollan aplicaciones que acceden a una base de datos, es conveniente verificar que los datos se están manipulando de forma correcta. Para ello, es necesario hacer pruebas sobre el código que realiza esta manipulaciones de datos.

JUnit es un framework que nos ayuda a la hora de hacer pruebas en nuestra aplicación. Además, también podemos usar DbUnit, que es una extensión de JUnit que permite llevar la base de datos a un estado definido antes de cada prueba y que proporciona clases que nos ayudan a realizar pruebas sobre el contenido de una base de datos.

DbUnit permite importar y exportar el contenido de la base de datos a ficheros xml. Por ejemplo, la tabla PROFESORES se define de la siguiente forma:

Un registro en la tabla PROFESORES, se expresaría en xml como:

<profesores PROFESOR_ID="3" NOMBRE="nombre_profesor"/>

Se puede apreciar que el nombre del elemento es el nombre de la tabla y los distintos atributos son los campos de la tabla y su valor para este registro.

Mediante registros de este tipo se pueden generar distintos conjuntos de datos (datasets) en ficheros xml, que pueden servir como semillas para probar el código que accede a la base de datos en situaciones adecuadas para cada prueba.

Vamos a ver como exportar un esquema completo de la base de datos utilizando DbUnit. En primer lugar, se debe obtener una conexión a la base de datos. Se puede hacer de la siguiente forma:

Class.forName("com.mysql.jdbc.Driver");
Connection jdbcConnection = 
 DriverManager.getConnection(
  "jdbc:mysql://localhost/bdprueba", 
  "user", 
  "pwd");
IDatabaseConnection connection = 
 new DatabaseConnection(jdbcConnection);

Posteriormente pasamos a exportar los datos que hay actualmente en la base de datos. Al exportar hay que tener en cuenta el orden de las tablas ya que se podría romper la integridad referencial que existe entre ellas. Para ello se crea un dataset al que se añaden las tablas de forma ordenada, que se pueden obtener a partir de un DatabaseSequenceFilter:

DatabaseSequenceFilter filter = 
 new DatabaseSequenceFilter(connection);
IDataSet datasetAll = 
 new FilteredDataSet(
  filter, 
  connection.createDataSet());
QueryDataSet partialDataSet = 
 new QueryDataSet(connection);

String[] listTableNames = 
 filter.getTableNames(datasetAll);
for (int i = 0; i < listTableNames.length; i++) {
 final String tableName = listTableNames[i];
 partialDataSet.addTable(tableName);
}

Ahora se exportaría este dataset a un archivo xml:

FlatXmlDataSet.write(partialDataSet,
 new FileOutputStream("dataset.xml"));

<?xml version='1.0' encoding='UTF-8'?<
<dataset>
  <academias/>
  <estilos ESTILO_ID="1" NOMBRE="nombre_estilo"
   DESCRIPCION="descripcion_estilo"/>
  <estilos ESTILO_ID="3" NOMBRE="nombre_estilo"
   DESCRIPCION="descripcion_estilo"/>
  <estilos ESTILO_ID="4" NOMBRE="nombre_estilo"
   DESCRIPCION="descripcion_estilo"/>
  <estilos ESTILO_ID="6" NOMBRE="nombre_estilo"
   DESCRIPCION="descripcion_estilo"/>
  <estilos ESTILO_ID="8" NOMBRE="nombre_estilo"
   DESCRIPCION="descripcion_estilo"/>
  <estilos ESTILO_ID="9" NOMBRE="nombre_estilo"
   DESCRIPCION="descripcion_estilo"/>
  <estilos ESTILO_ID="10" NOMBRE="nombre_estilo"
   DESCRIPCION="descripcion_estilo"/>
  <estilos ESTILO_ID="12" NOMBRE="nombre_estilo"
   DESCRIPCION="descripcion_estilo"/>
  <clases/>
  <academia_clase/>
  <profesores PROFESOR_ID="3" NOMBRE="nombre_profesor"/>
  <profesores PROFESOR_ID="6" NOMBRE="nombre_profesor"/>
  <profesores PROFESOR_ID="9" NOMBRE="nombre_profesor"/>
  <profesores PROFESOR_ID="12" NOMBRE="nombre_profesor"/>
  <clase_profesor/>
  <profesor_estilo PROFESOR_ID="3" ESTILO_ID="3"/>
  <profesor_estilo PROFESOR_ID="6" ESTILO_ID="6"/>
  <profesor_estilo PROFESOR_ID="9" ESTILO_ID="9"/>
  <profesor_estilo PROFESOR_ID="12" ESTILO_ID="12"/>
</dataset>

Tras esto se ha obtenido un dataset que puede ser usado como semilla para una prueba.

A la hora de hacer pruebas, DbUnit proporciona la clase DatabaseTestCase, que sirve como clase base para las pruebas. Esta clase tiene algunos métodos que debemos sobreescribir. El método getConnection() proporciona la conexión a la base de datos, de forma similar a como hemos visto antes:

protected IDatabaseConnection getConnection() 
 throws Exception {
  
 Class driverClass = 
  Class.forName("org.gjt.mm.mysql.Driver");

 Connection jdbcConnection = 
  DriverManager.getConnection(
   "jdbc:mysql://localhost/bdprueba", 
   "user", 
   "pwd");
        
 return new DatabaseConnection(jdbcConnection);
}

El método getDataSet() proporciona un dataset que sería la semilla para la prueba que vamos a ejecutar:


protected IDataSet getDataSet() throws Exception {
   return new FlatXmlDataSet(
      new FileInputStream("dataset.xml "));
}

Los métodos getSetUpOperation() y getTearDownOperation() indican lo que debe hacer cada método antes y después de cada prueba. Antes de cada prueba vamos a limpiar la base de datos y a volver a dejarla en el estado que proporciona el dataset que hemos exportado anteriormente, y después de cada prueba no haremos nada:

protected DatabaseOperation getSetUpOperation() 
 throws Exception {
 return DatabaseOperation.CLEAN_INSERT;
}

protected DatabaseOperation getTearDownOperation() 
 throws Exception {
 return DatabaseOperation.NONE;
}

Tras esto, podemos escribir nuestros casos de prueba en la clase que extiende de DatabaseTestCase, sabiendo que las pruebas partirán de un estado definido.

Referencias:
http://dbunit.sourceforge.net/index.html
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=DBUnitEI
http://onjava.com/pub/a/onjava/2004/01/21/dbunit.html
http://www.oreillynet.com/onjava/blog/2005/10/dbunit_made_easy.html

Agile Open Spain

2009-10-26T10:40:00.009+01:00

Los días 23 y 24 de Octubre se ha celebrado en la Escuela Universitaria de Informática del Campus Sur de la Universidad Politécnica de Madrid el Agile Open Spain, organizado por Agile Spain.

El Agile Open Spain tenía como objetivo la difusión de la metodologías ágiles en España, compartiendo experiencias entre todos los participantes. Se ha desarrollado basándose en el formato Open Space.

La tarde del viernes 23, tras la introducción al evento por parte de la organización, cualquier participante pudo presentar los temas que más interés tenían para él. Tras votación por parte de los asistentes, se seleccionaron los más votados para confeccionar el horario de charlas para el día siguiente, en el que se establecieron 5 turnos de charlas con 6 charlas distintas en cada uno para escoger.

Voy a comentar las charlas en las que yo estuve, que, desgraciadamente, no fueron todas las que me habría gustado estar.

Integración continua

La integración contínua fue el tema de la primera charla a la que asistí. Fue conducida por Juan Gutiérrez y en ella se habló de lo que es la integración continua, presentándola como un proceso continuo de integración del trabajo que se lleva a cabo dentro de un proyecto, que aglutina una serie de buenas prácticas y que está apoyado por una serie de herramientas que permiten automatizarlo.

Algunos asistentes hablaron de sus experiencias con la integración continua en sus proyectos y se llego a exponer el sistema de integración contínua con que uno de los asistentes trabajaba.

Se recalcó la idea de que el principio de la integración es el control de versiones (CVS, Subversion, Git, …) y las herramientas de construcción automática (Ant, Maven…) y que, a partir de ahí, existen un montón de herramientas que contribuyen a la automatización de las distintas pruebas (Junit, DBUnit, Selenium…). Y todo esto, orquestado por el servidor de integración continua (Hudson, Bamboo…).

Control de versiones

En la siguiente sesión se habló sobre el control de versiones en los proyectos, estableciendo la necesidad de establecer una política de ramas bien definida, para lo que se presentaron varias estrategias.

El conductor, Jose Luis Soria, presentó la serie de tareas necesarias para establecer una política de ramas:

Establecer el modelo de aislamiento: sobre qué rama se realiza un nuevo cambio.
Establecer listas de promoción: definir qué ramas pueden hacer merge a cuáles.
Criterios de calidad.
Establecer un responsable de cada rama, que se encargará de que se mantenga estable.
Establecer permisos.
Estrategia de testeo y construcción automatizada.

Hubo también algún firme impulsor de Git, presentándolo como una alternativa superior a CVS o Subversion, así que habrá que echarle un vistazo.

Agilismo de guerrilla

En esta charla, conducida por Xavi Gost, se habló sobre cómo intruducir el agilismo en una organización. La idea principal que se me quedó es no esperar que vengan de arriba a ofrecértelo, sino ir introduciendo técnicas ágiles en la medida de lo posible en los proyectos.

También se habló sobre la resistencia al cambio por parte de la gente. Resistencia, sobre todo, a los grandes cambios. Por el contrario, si se introducen los cambios de forma disimulada, la gente los adopta sin el miedo que supone presentar a un grupo una nueva metodología o conjunto de prácticas de golpe.

Kanban

Como dijo Xabier Quesada en la presentación, Scrum ha muerto y ahora lo que se lleva es Kanban. Como luego él mismo matizó, esto no es así, puesto que Kanban es algo que todavía se está definiendo.

Xabier, junto con Robin Diamond, nos presentaron Kanban, una nueva metodología basada en Lean. Los principios de Kanban son:

Limitar el trabajo en progreso, todo trabajo empzado y no terminado, puesto que está costando dinero.
Establecer un flujo continuo de trabajo, que entra por un lado y fluye hasta el final de la cadena de producción.

En la charla contruyeron un tablero Kanban que sirvió para hacernos una idea visual de su funcionamiento.

Historias de usuario

Sesión conducida por Jose Luis Soria, Rodrigo Corral y otro asistente más cuyo nombre no recuerdo :-(. En esta charla se habló de la documentación en los proyectos.

La idea principal sería la de hacer simplemente la documentación que aporte valor al proyecto, bien para el desarrollador o para el usuario, y resistirse a documentar por documentar creando tochos que nadie lee ni actualiza y se quedan obsoletos de forma inmediata.

Se habló mucho de las historias de usuario, representación de un requerimiento a través de una sencilla descripción de la conversación mantenida con un usuario y sus condiciones de aceptación. Una historia de usuario debe tener las siguientes características:

Independente
Que aporte valor
Estimable
Negociable
Testable
Pequeña

De todas las charlas me marché con la sensación de haber aprendido bastante. No siempre tienes la oportunidad de tener delante gente que puede hablar sobre su experiencia en temas en los que tú estás empezando a introducirte.

La pena, no haber podido asistir a otras charlas que también me interesaban. Pero el tener que elegir hace que a las que vayas, lo hagas con el mayor interés.

Un saludo a la organización del Agile Open Spain y a todos sus participantes.

Licencias de Software

2009-10-20T14:27:00.006+02:00

Según la Wikipedia, “una licencia de software es un contrato entre el licenciante (autor/titular de los derechos de explotación/distribuidor) y el licenciatario del programa informático (usuario consumidor /usuario profesional o empresa), para utilizar el software cumpliendo una serie de términos y condiciones establecidas dentro de sus cláusulas.”

Por tanto, la licencia establece las condiciones bajo las cuáles podemos usar un software determinado.

Puesto que existen una amplia variedad de licencias, voy a exponer a continuación algunas de las más comunes, junto con una breve explicación de lo que estas licencias implican desde el punto de vista del usuario.

GPL

La Licencia Pública General (General Public License) es una licencia de software libre que permite al usuario utilizar un programa licenciado bajo dicha licencia, modificarlo y distribuir las versiones modificadas de éste.

Todo software desarrollado, aunque sólo sea una parte, con material licenciado bajo GPL debe estar disponible para ser compartido de forma gratuita (copyleft), manteniendo los nombres de los autores originales.

El software con licencia GPL carece de garantía, el autor no se hace responsable por el malfuncionamiento del mismo.

Tampoco se puede establecer ningún cobro por las modificaciones realizadas sobre el software.

LGPL

La Licencia Pública General Menor (Lesser General Public License) es una modificación de la licencia GPL, que permite que los desarrolladores utilicen programas bajo la LGPL sin estar obligados a someter el programa final bajo dichas licencias.

LGPL no permite que se realicen versiones comerciales del producto licenciado bajo LGPL. Sin embargo, permite realizar versiones comerciales de un producto final que contenga como herramienta adicional un programa LGPL.

LGPL exige registrar todos los cambios realizados por terceros, a manera de no afectar la reputación del autor original del software.

BSD

La Licencia de Distribución de Software de Berkeley (Berkeley Software Distribution) permite a los programadores utilizar, modificar y distribuir a terceros el código fuente y el código binario del programa de software original con o sin modificaciones bajo licencias de código abierto o comercial.

Esta licencia permite el uso del código fuente en software no libre sin necesidad de mencionar a los autores ni proporcionar el código fuente. Esta licencia sí que establece la renuncia de garantía y la atribución de la autoría sobre trabajos derivados.

MPL

La Licencia Pública de Mozilla (Mozilla Public License) es una licencia de código abierto y sofware libre utilizada por el navegador de Internet Mozilla y sus productos derivados. La MPL deja abierto el camino a una posible reutilización comercial y no libre del software y permite la reutilización del código ni el cambio de licencia.

Apache License

La Licencia Apache es una licencia de software libre que permite al usuario usar el software para cualquier propósito, distribuirlo, modificarlo, y distribuir versiones modificadas de ese software.

La Licencia Apache no exige que las obras derivadas del software se distribuyan usando la misma licencia, ni siquiera que se tengan que distribuir como software libre. La Licencia Apache sólo exige que se mantenga una noticia que informe a los receptores que en la distribución se ha usado código con la Licencia Apache.

Actualmente, existen muchas herramientas que están siguiendo una estrategia de licenciamiento dual de software. Estas proporcionan dos tipos de licencias para el mismo software entre las que puede optar el usuario:

Una licencia gratuita de software libre (por ejemplo, GPL) que permite el uso del software a condición de que lo que el cliente desarrolle tambien sea puesto a disposición de otros usuarios libremente.

Una licencia de pago comercial que permite que no haya que publicar el código fuente de las aplicaciones desarrolladas.

Referencias:
http://es.wikipedia.org/wiki/Licencia_de_software
http://www.gnu.org/licenses/license-list.es.html
http://www.monografias.com/trabajos55/licencias-de-software/licencias-de-software.shtml
http://es.wikipedia.org/wiki/Apache_License

Scrum Manager

2009-10-19T13:07:00.005+02:00

En los últimos tiempos se viene oyendo hablar mucho sobre metodologías ágiles y, principalmente, sobre Scrum. El creciente interés por Scrum ha hecho florecer una serie de certificaciones al respecto, promovidas por la Scrum Alliance y, por supuesto, de pago. Contra esta tendencia a lucrarse de una metodología que ha florecido dentro de ambientes “Open Source” se han alzado voces que prefieren compartir el conocimiento a través de la comunidad.

Una iniciativa en este sentido es Scrum Manager, que se define como una “comunidad profesional para la gestión flexible de proyectos y organizaciones TIC”. Su objetivo es mejorar los procedimientos y métodos de trabajo de las organizaciones y proyectos de software manteniendo de forma abierta a la comunidad profesional la plataforma de conocimiento Open Knowledge.

Esta plataforma ofrece los siguientes cursos gratuitos sobre Scrum:

Introducción a Scrum Manager: Su objetivo es “conocer los principios de los modelos de procesos y las prácticas ágiles, enmarcados en el mapa o marco de situación que les da sentido, y revela las fortalezas y debilidades de cada estrategia: ingeniería, procesos, gestión predictiva y gestión ágil”.

Scrum: Su objetivo es “conocer el modelo Scrum: origen del modelo, principios y prácticas que emplea para la gestión y seguimiento ágil del proyecto, sus componentes; junto con las razones y consideraciones de fondo para la implementación del modelo”.

Métricas ágiles: Su objetivo es “conocer la razón y finalidad de las métricas en la gestión ágil de proyectos, y evitar errores habituales en el diseño y aplicación de métricas, normalmente por exceso en el número de métricas o en su complejidad, que suele desbordar las necesidades de estimación y seguimiento ágil”.

Estos son cursos ofrecen recursos de aprendizaje como material didáctico y foros. Además, a la conclusión de estos cursos existe una prueba de evaluzación final cuya superación satisfactoria otorga puntos de autoridad dentro de la escala de reconocimiento profesional de Scrum Manager.

Desde aquí quiero aprovechar para felicitar a los responsables de esta iniciativa y agradecerles su esfuerzo.

Referencias:
Scrum Manager

Gestionando un proyecto Hibernate desde Maven

2009-10-14T11:54:00.008+02:00

Vamos a ver cómo gestionar con Maven un proyecto que utiliza Hibernate.

En primer lugar, vamos a ver cómo configurar las dependencias de Hibernate en Maven. Aquí nos encontramos con un problema, Hibernate depende de la Sun JTA API, que no está disponible en el repositorio central de Maven porque, debido a problemas de licencias, no puede ser distribuida libremente.

Para solucionar este problema existen dos posibles soluciones. La primera es descargar la Sun JTA API de la página web de Sun y despues instalarla en el repositorio local de Maven.

Usaremos el siguiente pom.xml:

<project 
 xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
  http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.roldan.hibernate</groupId>
 <artifactId>HibernateMavenProject</artifactId>
 <version>0.0.1-SNAPSHOT</version>  
 <dependencies>
  <dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate</artifactId>
   <version>3.2.6.ga</version>
  </dependency>
  … 
 </dependencies>
</project>

Para instalar la Sun JTA API en el repositorio usaremos la siguiente instrucción desde la línea de comandos:

mvn install:install-file
 -DgroupId=javax.transaction
 -DartifactId=jta
 -Dversion=1.0.1B
 -Dpackaging=jar
 -Dfile=jta-1_0_1B-classes.zip

La segunda posible solución sería descartar la dependencia de la Sun JTA API que tiene Hibernate y, en su lugar, obtener una implementación alternativa de este API que pueda ser descargada libremente, como la de Geronimo:

<project 
 xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.roldan.hibernate</groupId>
 <artifactId>HibernateMavenProject</artifactId>
 <version>0.0.1-SNAPSHOT</version>  
 <dependencies>
  <dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate</artifactId>
   <version>3.2.6.ga</version>
   <exclusions>
    <exclusion>
     <groupId>javax.transaction</groupId>
     <artifactId>jta</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>geronimo-spec</groupId>
   <artifactId>geronimo-spec-jta</artifactId>
   <version>1.0-M1</version>
  </dependency>
  …
 </dependencies>
</project>

Una vez resueltas las dependencias de Hibernate en Maven, podemos usar Hibernate en nuestros proyectos. Una herramienta que nos ayudará a simplificar las tareas de administración de estos proyectos es el plugin de Hibernate 3 para Maven, que se puede obtener del repositorio de Codehaus.

Por ejemplo, vamos a usar este plugin para generar el DDL de la base de datos durante el desarrollo, permitiendo reconstruir la base de datos para irnos actualizando a los cambios que se vayan produciendo:

<project>
 …
 <repositories>
  <repository>
   <id>codehaus</id>
   <name>Maven Codehaus repository</name>
   <url>http://repository.codehaus.org/</url>
  </repository>
 </repositories>
 …
 <build>
  <extensions>
   <extension>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.6</version>
   </extension>
  </extensions>
  <plugins>
   <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>hibernate3-maven-plugin</artifactId>
    <version>2.2</version>
    <configuration>
     <componentProperties>
      <drop>true</drop>
      <outputfilename>schema.sql</outputfilename>
     </componentProperties>
    </configuration>
   </plugin>
  </plugins>
 </build>
</project>

Para lanzar la ejecución de esta tarea de actualización de la base de datos, usamos el comando:

mvn org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl

Hacer un release de un proyecto con Maven

2009-10-06T12:30:00.007+02:00

A la hora de hacer un release de un proyecto que estamos gestionando con Maven y Subversion podemos seguir los siguientes pasos:

Cambiar la versión en el pom.xml del proyecto y quitar la etiqueta SNAPSHOT.
Hacer commit del pom.xml.
Etiquetar la versión del código en el repositorio de Subversion.
Cambiar la version en el pom.xml para dejar la siguiente versión: 0.0.2-SNAPSHOT.
Hacer commit de los pom.xml.

Si además, en vez de sólo uno, tenemos varios proyectos, el trabajo se multiplica.

Para simplificar estas tareas, se puede hacer uso de un plugin de Maven, el Maven Release Plugin. Para ello, primero debemos configurar las propiedades del sistema de control de versiones que estamos usando. Esto se hace en el bloque scm del pom.xml:

<scm>
  <url>svn://localhost/trunk/SimpleProject</url>
  <developerConnection>
    scm:svn:svn://localhost/trunk/SimpleProject
  </developerConnection>
</scm>

Ahora, incluimos en el pom.xml del proyecto la configuración para el Maven Release Plugin. Vamos a indicar en que ruta se deben dejar los etiquetas de las releases que realicemos:

<project>
…
  <build>
    <plugins>
    …
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.0-beta-7</version>
        <configuration>
          <tagBase>svn://localhost/tags/releases</tagBase>
        </configuration>
      </plugin>
    …
    </plugins>
  </build>
…     
</project>

A la hora de hacer la release he experimentado fallos relacionados con el directorio target, puesto que este es un directorio que se elimina cada vez que se hace un clean, lo cual genera conflictos entre las versiones del proyecto en Subversion. Puesto que es un directorio cuyo contenido se genera automáticamente en la fase de construcción del proyecto, no es necesario que lo incluyamos en el sistema de control de versiones. Vamos a indicar en Eclipse que este directorio sea ignorado por Subversion, desde la ventana Preferences:

En este momento, ya se podría hacer una release del proyecto mediante el siguiente comando que se ejecutaría dentro del directorio del proyecto:

mvn -Djorge=jorgepassword release:clean release:prepare

La ejecución de este comando nos preguntará por la versión de la release que estamos realizando, por el nombre de la etiqueta para esta release y por la siguiente versión del proyecto después de esta release. En nuestro caso, dejaremos las opciones por defecto:

What is the release version for 
 "Unnamed - com.roldan:SimpleProject:jar:0.0.2-SNAPSHOT"?
 (com.roldan:SimpleProject) 0.0.2: :
What is SCM release tag or label for 
 "Unnamed - com.roldan:SimpleProject:jar:0.0.2-SNAPSHOT"?
 (com.roldan:SimpleProject) SimpleProject-0.0.2: :
What is the new development version for
 "Unnamed - com.roldan:SimpleProject:jar:0.0.2-SNAPSHOT"?
 (com.roldan:SimpleProject) 0.0.3-SNAPSHOT: :

Al finalizar, habremos creado la release del proyecto:

Referencias:
http://maven.apache.org/plugins/maven-release-plugin/index.html
http://weblogs.java.net/blog/2008/08/31/using-maven-release-plugin
http://jmbeas.blogspot.com/2009/03/versionado-automatico-con-maven.html

Herramientas de análisis de calidad del código

2009-10-01T11:38:00.004+02:00

Existen muchas herramientas que nos permiten analizar el código desarrollado y parecen ser ampliamente usadas. Me había propuesto escribir un artículo describiendo el uso de algunas de ellas, pero visto que esta información ya existe y es fácilmente localizable en Internet, me voy a limitar a enumerar estas herramientas y hacer una breve descripción de para qué sirve cada una.

Las herramientas sobre las que voy a hablar son:

Checkstyle
PMD
Findbugs
JDepend
JavaNCSS
Cobertura

Checkstyle (http://checkstyle.sourceforge.net/)

Checkstyle ayuda a escribir código que se adhiera a unas convenciones de codificación determinadas. Además, en las últimas versiones se le han añadido nuevas características que permiten también encontrar problemas en el diseño de las clases, encontrar código duplicado o buscar patrones de error conocidos.

Checkstyle tiene plugins que permiten que sea usado desde cualquier IDE, como Eclipse (http://eclipse-cs.sourceforge.net/), resaltando sobre el código los errores encontrados por el analizador. También poseee un plugin para Maven 2 (http://maven.apache.org/plugins/maven-checkstyle-plugin/) que permite generar informe sobre lor errores encontrados.

PMD (http://pmd.sourceforge.net/)

PMD busca en el código fuente ciertos patrones de error, código no usado, código no óptimo, expresiones demasiado complicadas y código duplicado.

Podemos usarlo tanto en Eclipse (http://pmd.sourceforge.net/integrations.html#eclipse) como en Maven (http://maven.apache.org/plugins/maven-pmd-plugin/project-info.html).

Findbugs (http://findbugs.sourceforge.net/)

Se trata de otra herramienta que realiza análisis estático de código en busca de errores.

También puede ser usado en Eclipse (http://findbugs.sourceforge.net/manual/eclipse.html) como en Maven (http://mojo.codehaus.org/findbugs-maven-plugin/2.0.1/).

JDepend (http://clarkware.com/software/JDepend.html)

Jdepend proporciona métricas de cálidad entre los paquetes de un proyecto en términos de su extensibilidad, reusabilidad, y mantenibilidad.

Como las herramientas anteriores, se puede usar en Eclipse (http://andrei.gmxhome.de/jdepend4eclipse/) y en Maven (http://mojo.codehaus.org/jdepend-maven-plugin/).

JavaNCSS (http://www.kclee.de/clemens/java/javancss/)

Esta herramienta permite recoger métricas sobre el código fuente, como el número de líneas, paquetes, clases o métodos.

Al igual que todas las herramientas anteriores, se puede susar en Eclipse (http://freshmeat.net/projects/jncss4eclipse/) y en Maven (http://mojo.codehaus.org/javancss-maven-plugin/dependencies.html).

Cobertura (http://cobertura.sourceforge.net/)

Esta herramienta permite calcular la cantidad de código al que acceden los tests.

En este caso, no se dispone de un plugin para Eclipse, pero si que podemos usar esta herramienta desde Maven (http://mojo.codehaus.org/cobertura-maven-plugin/).

Os animo a que probéis estas herramientas. ¿Conocéis alguna más que pueda resultar útil para el desarrollo de un proyecto Java?