Diario de Programación

Dos herramientas que se vuelven a integrar para trabajar conjuntamente: XPlanner y Eclipse

XPlanner, como ya mencioné alguna vez, es una pequeña aplicación desarrollada en JSP, por lo que necesitamos tener instalado Tomcat o algo parecido. Se accede a ella desde navegador y nos permite tener un listado de tareas a hacer por proyectos. Esta muy pensada para metodologías ágiles, como Scrum o Programación extrema. Para cada proyecto permite definir una serie de "historias de usuario" y para cada historia de usuario una serie de tareas para hacer. Las historias de usuario podemos agruparlas en iteraciones a realizar en un plazo determinado, al estilo de un Sprint de Scrum o iteración de programación extrema. Luego, día a día, podemos ir marcando cuánto hemos hecho para obtener gráficos al estilo Scrum.

Por otro lado, eclipse europa, según qué opción nos descarguemos, viene con un plugin llamado Mylyn que nos permite también gestionar nuestras tareas. Nos da en eclipse una perspectiva de "planning" en la que podemos crear nuestras carpetas de tareas pendientes y dentro de cada carpeta poner las tareas que queramos. Podemos activar las tareas cuando trabajamos en ellas y desactivarlas, de forma que Mylyn nos lleva una especie de cronómetro con el que podremos saber cuánto tiempo dedicamos a cada tarea. Desgraciadamente, es demasiado listo y si no estamos trabajando, no cuenta el tiempo. Otra característica interesante de Mylyn es que lleva un "filtro" de fuentes y ficheros que vamos tocando, de forma que al activar una tarea, sólo se ven aquellos fuentes con los que solemos trabajar en esa tarea. Interesante en proyectos grandes con miles de fuentes.

Y ahora lo más curioso de todo, Mylyn permite importar tareas de ciertas herramientas web como bugzilla y ahora, también de XPlanner. En Mylyn creamos un nuevo repositorio de tareas y seleccionamos XPlanner. Damos los datos necesarios, como la URL en la que está XPlanner, el nombre de usuario, el password y listo. Las tareas que tenemos de XPlanner se vienen a eclipse como lista de tareas a hacer. Desde el mismo eclipse podemos más o menos actualizar XPlanner.

Ya lo tengo instalado, con alguna tarea en XPlanner. Ahora solo queda lo más duro… ¡trabajar!

Llevo casi toda la semana entretenido, cambiando un poco los módulos ya hechos de una aplicación de escritorio para poder instanciarlos usando Springframework e instanciándolos con Springframework.

El primer módulo lo abordé con la ilusión de probar algo nuevo. Sin embargo, a la hora de escribir el fichero xml de configuración de Springframework empecé a intuir que ese fichero puede ser un verdadero infierno. Tenía abiertos dos editores, en uno la clase java principal del módulo/bean y en el otro el fichero XML. Iba mirando el nombre exacto de los métodos set() para poner el property con el mismo nombre en el fichero XML. Me reordaba a los viejos tiempos en que programaba en C++ con el vi, sin ningún tipo de IDE. Tenías que ir abriendo los ficheros .h para ver cómo se llamaba exáctamente el método y su parámetros para poder hacer la llamada en tu fichero .cpp

Indagando por google, descubrí que efectivamente, ese es uno de las pequeñas pegas de Springframework: XML grandes y pesados de construir.

Pero me dije, como todo está inventado, seguro que hay un plugin de eclipse para Springframework. Efectivamente, en Springide tienen un estupendo plugin de Springframework para eclipse. Se puede instalar desde eclipse, con "help" -> "software updates" -> "find and install" y poniendo la dirección http://springide.org/updatesite_dev/

La instalación me dio un pequeño problema. No se deja instalar completo, posiblemente porque la versión de eclipse que tengo es la más última y el plugin debe andar un poco por detrás. No obstante, la parte básica del plugin sí se instaló.

Una vez instalado Springide, la construcción del fichero XML es muy agradable. Eclipse ya ofrece ayuda contextual para los ficheros XML, de forma que en cualquier sitio del fichero, pulsando Ctrl-espacio, podemos ver los posibles tags o atributos XML que se pueden añadir siguiendo el DTD que se indique en la cabecera. Con Springide, la ayuda contextual incluye además las clases accesibles para el proyecto o las referencias a los beans ya declarados en el fichero XML.

Me explico, si empezamos a escribir

<bean id="nombre" class="MiC

y justo depués de la C de MiC pulsamos Ctrl-espacio, aparecerá el típico menú con todas las clases accesibles que empiecen por MiC. Seleccionamos una en el menú y se añade automáticamente, incluyendo el paquete.

De la misma forma, si escribimos

<property name="

y pulsamos Ctrl-espacio, aparece un menú con todos las propiedades de la clase en la que estemos poniendo este tag property. Elegimos una y seguimos escribiendo

<property name="propiedadElegida" ref="

y ahora, pulsando Ctrl-espacio sale un menú con todos los beans que ya tenemos declarados, para elegir uno.

Me queda comprobar si se pone en rojo si escribimos una clase, propiedad o bean que no exista.

Otro ejemplo de Orientación a Objetos y patrones en la API de java es la forma de construir las ventanas, la interface gráfica de usuario.

Todos los componentes visuales -JButton, JCheckBox, JList, etc- heredan de Component y todos tienen el método paint(Graphics). Este método, en cada componente, dibuja el componente sobre el Graphics que se le pasa.

Pasarle el Graphics es nuevamente una buena idea y una aplicación del patrón Estrategia. Un JButton sabe qué tiene que dibujar -líneas, sombras, icono, etc-, pero es Graphics el que realmente hace el dibujo. Esto da mucha versatilidad, puesto que si al JButton le pasamos un Graphics que pinte en pantalla, el botón se dibujará en pantalla. Si le pasamos un Graphics que dibuje en impresora, el botón se dibujará en una impresora y si le pasamos un Graphics que dibuje en un BufferedImage -una imagen en memoria-, el JButton se dibujará en una imagen. El mismo botón con exactamente el mismo código puede dibujarse en cualquier lado.

Es más, si le pasamos un Graphics2D -que como hereda de Graphics se puede pasar- al que hayamos aplicado alguna transformación con setTransform(), podemos obtener fácilmente botones "deformados": girados, a escala, cizallados, etc.

Sin embargo todo esto va más allá. Hay componentes java como los JPanel que está destinados a "contener" otros componentes java. De esta forma, podemos tener un panel que tenga dentro dos botones, una lista y un checkbox. Estos componentes se llaman Container. Pues bien, los Container también heredan de Component y también tienen un método paint(). ¿Qué hace este método paint() del Container?. Sencillo, simplemente dibuja lo que es el panel y luego, con un bucle, llama al método paint() de cada uno de los componentes que tiene dentro.

Esto es una aplicación del patrón compuesto -Composite-. Tenemos un componente compuesto -el Container- que implementa la misma interface que un componente simple, por lo que se puede tratar perfectamene como cualquier otro componente. Pero en realidad está "compuesto" de otros componentes simples y en el método del componente simple -paint() en este caso-, simplemente va llamando a todos los paint() de los componentes simples.

Este mecanismo permite fácilmente crearse unas piezas simples de un puzzle, crearse nuevas piezas componiendo piezas simples que a su vez podríamos usar para componer piezas más complejas.

Esta idea puede servir de base para una librería gráfica. Una clase Lienzo recibe ObjetosGraficos que tengan un método dibujate(Graphics). Así, por ejemplo, podemos tener un ObjetoGrafico Rectangulo, Circulo, etc. Podemos componer ObjetosGraficos, haciendo un ObjetoGrafico Tablero que esté compuesto de varios Rectangulo, o un coche a base de un par de Circulo-Rueda y alguna cosa más.

La idea importante que pretendo transmitir con estos tres artículos es símplemente que fijándose en como se hacen las cosas en la API de java, podemos aprender mucho sobre cómo hacer nuestros programas orientados a objetos, cómo se deberian organizar las clases para obtener cosas flexibles, modulares, ampliables y sobre todo muy reutilizables.

Si nos ponemos a mirar la API, encontraremos miles de ejemplos de casi todos los patrones de diseño y sería de tontos no dedicar un mínimo de atención a estos ejemplos.

Igual que tenemos integración continua, que básicamente consiste en compilar con frecuencia todo el proyecto desde cero y que hay herramientas que lo hacen automáticmente todos los días, como Cruise Control, también -acabo de descubrir- existe el concepto de test continuo.

Si tenemos unas mínimas buenas costumbres de programación, haremos test unitarios para nuestras clases. Herramientas como Cruise Control y maven se encargan de pasar esos test cada vez que compilamos y nos dicen si hemos o no metido la pata. Pero … ¿por qué no ir más allá?

Acabo de descubrir un plug-in para eclipse -que todavía no he probado, pero lo haré pronto- llamado Continuous Testing Plugin. Tiene pinta de que tú lo instalas en Eclipse, le dices cuales son las clases de test y él, según vas tocando código, va pasando los test de la que eclipse recompila automáticamente. Esto hace que si estropeas un test tocando código, te enteres inmediatamente.

Este mismo Lunes lo pruebo en el trabajo, aunque me da un poco de miedo que ralentice mucho eclipse.

Omondo es un plugin de eclipse para poder dibujar UML. PMD es un plugin de eclipse para ver las métricas de nuestro código.

Ambos tienen muy buena pinta y parecen plugins en serio y bastante pontentes. Los he probado ambos y he tenido que desinstalar ambos.

Como ya comenté en otras ocasiones, trabajo en proyectos muy grandes, de cerca de cinco o seis mil clases. Por supuesto, están repartidas en varios subproyectos de eclipse, interdependientes entre sí. Habitualmente tengo eclipse abierto con entre diez y quince proyectos, de varios centeneres de clase cada uno de ellos.

Omondo hace que eclipse tarde en arrancarse lo indecible. Según abres eclipse, se debe poner a revisar todas las clases para sus diagramas. Para cada proyecto te saca un aviso que debes cerrar. Resulta que al final, una vez abierto, eclipse se queda pillado unos minutos revisando diagramas y además debes estar pendiente para ir cerrando esos avisos. Si te vas a tomar un café mientras abre, se queda parado en el aviso y no continúa.

En cuanto a PMD le pasa algo parecido pero de otra manera. Mientras no lo usas, va todo bien como siempre. Pero si le pones que se ponga a medir las métricas de los ficheros, hace que eclipse se vuelva lento e inmanejable.

Así que para UML tendré que buscar otra herramienta y PMD lo paso actualmente con maven, de forma que en cada compilado me genera el informe de métricas.

Sabía desde hace tiempo que eclipse tiene diversas opciones de "refactoring", opciones que nos permiten modificar fácilmente el código para hacelo más legible, diseño más claro, etc.

La primera opción tonta es la de renombrar o mover una clase entera de sitio. Sobre la clase le damos al botón derecho del ratón para sacar el menú, "refactor" y "move" o "rename". La ventaja de hacerlo así es que eclipse nos revisa el resto de las clases del proyecto y nos cambia automáticamente los import y el nombre de la clase donde aparezca.

Otra que uso mucho es la de extraer un método. Seleccionas varias líneas de código, botón derecho del ratón, "refactor" y "extract method". Si se puede hacer fácilmente, eclipse nos crea el método y nos cambia el código para que haga una llamda a ese método. Si el asunto no es trivial, tenemos que ayudarle un poco.

Otras muy útiles también es el de "convert local variable to attribute" o "extract constant". En el primero selecionando una variable y en el segundo un valor fijo (numérico o cadena de texto), eclipse nos crea un nuevo atributo o constante en la clase y reemplaza todas las apariciones en el código de esa clase.

Otro muy maravilloso es el cambiar la "signatura" de un método. Seleccionamos el nombre del método, botón derecho, "refactor", "change signature" y podemos ponerle o quitarle parámetros. Eclipse revisa todo el código para arreglar las llamadas. Este es muy útil cuando vemos un método que ha dejado de usar uno de los parámetros que en principio se le pasaban. Lo podemos hacer desaparecer de un plumazo.

Y otro que he descubierto hace poco. Podemos mover un método de una clase a otra clase. Para que eclipse sepa hacerlo, la clase destino debe ser atributo de la clase origen, de forma que pueda reemplazar las llamadas a ese método por una llamada al método del atributo. Me explico, si la clase A tiene el metodo() y en algún sitio lo llama, debemos hacer una clase B que sea atributo de A. Al mover el método de A a B, eclipse nos cambiará las llamadas de metodo() por b.metodo().

Estas son las que recuerdo así por encima y que suelo usar. Es posible que me haya equivocado en los nombres de los menús (los puñeteros están en inglés), pero de todas formas es algo que merece la pena conocer, investigar y sacarle provecho. Puede ahorrar mucho trabajo y ayudarnos a dejar el código más limpio.

Cuando depuramos nuestro programa java con eclipse, situándonos encima de una variable y pulsando Ctrl-Shift-D (o bien botón derecho del ratón sobre la variable y opción “Display”) podemos ver un una especie de ventana amarilla emergente el resultado de llamar a toString() de dicha variable.

A veces la clase no tiene toString() definido salvo el de defecto, o el toString() que tiene está pensado para mostrar una información al usuario del programa y no nos sirve para depuración.

Con eclipse podemos cambiar el contenido del método toString() sólo para depuración, sin alterar el código, de forma que nos devuelva un texto más útil para depurar.

Para ello, elegimos “Window”->”Preferences”->”Java”->”Debug”->”Detail Formatter”. En la pestaña que nos sale elegimos “Add..”. Se abre una ventana en la que en la parte superior debemos poner el nombre de la clase en la que tenemos interés, con paquete incluido (podemos elegir dicha clase pulsando el botón “Select Type”). En la parte inferior escribimos el código que nos gustaría que devolviese nuestro toString().

Por ejemplo, a modo de prueba, he hecho esta clase

class Dato
{
public Dato(int a, int b)
{
this.a = a;
this.b = b;
}
int a;
int b;
}

En el código que quiero que se ejecute, dentro de la ventana mencionada antes, he puesto

“a=”+a+”,b=”+b

Y con eso está listo. Cuando depuro el programa y pulso Ctrl-Shift-D sobre una variable de tipo Dato, veo

a=3,b=5

que me ayuda más a depurar que lo que veía antes de hacer esto

chuidiang.ejemplos.Dato@1960f05

Visto en EclipseZone.