Diario de Programación

Normalmente en mis proyectos maven añado el log4j, siempre la versión 1.2.12. No por ningún motivo en particular. Símplemente era la versión disponible la primera vez que lo añadí a un proyecto maven y luego ha prevalecido el copy-paste de esa dependencia de un proyecto a otro.

El otro día cree un proyecto en casa y no tenía ningún sitio de donde copiar esta dependencia, así que me fuí a internet y busqué cómo ponerla. Puse la 1.2.15, que es la última que encontré disponible para maven.

Me pongo a compilar con maven, a generar el proyecto para eclipse y … ¡¡ Sorpresa !!. Da fallo. Busco el motivo y resulta que entre los jar que no puede bajarse, está el javamail, el activation.jar y algún otro más de los de SUN. Efectivamente, SUN no permite distribuir sus jar, por lo que oficialmente no se puede hacer. En los repositorios maven que hay por el mundo, no están estos jar de SUN, así que maven no se los puede bajar. Hay que bajárselos a mano y ponerlos en tu repositorio local de maven.

Y digo yo… ¿necesito javamail para log4j? Y aunque sea así, ¿voy a usarlo?. Pues más bien no. No tengo ningún interes en recibir por correo el log de mi aplicación y tampoco tengo ningún enemigo al que odie lo bastante como para mandárselo. Mejor dicho, sí lo tengo, pero lo que no tengo son ganas de quedarme de patitas en la calle.

Creo que esta vez se han pasado un poco. Entiendo que un momento dado, ante un error crítico, alguna aplicación crítica quiera enviar un correo a alguien. Pero, ¿es con un log.error(…) la mejor forma de hacerlo?. Desde luego puede ser cómoda en vez de usar javamail directamente, pero ¿tienen que cargar todas las aplicaciones que quieran un uso normal de log4j cargar con javamail?. A mi, desde luego, no me gusta.

Y aquí es donde llegamos a un punto donde siempre he tenido mis dudas. Por un lado la lógica y la elegancia me dicen que debería hacerse algo como log4j-core.jar con lo básico de log4j, es decir, sacar los log por pantalla o por fichero y poco más. Luego, deberían hacerse otros jar de amplicación, como log4j-mail.jar, log4j-bd.jar, etc, de forma que cada uno cargue sólo con lo que necesita. Sin embargo, la pereza me pediría que hubiera un único log4j-con-todo.jar y despreocuparme de andar buscando los que debo. Si me sobra el 90% del jar, da igual, no pasa nada.

Y esas dudas son las que siempre me corroen en el trabajo. Ante un proyecto gigante… ¿hacemos muchos jar pequeñitos por temas, de forma que en otros proyectos podamos llevarnos aquellos mini-jar que necesitamos? o por el contrario ¿hacemos un mega jar con todo y si un proyecto no necesita parte de él no pasa nada?

En la primera opción, al empezar un proyecto, debemos empezar a elegir jars que necesitamos y a coger también los jar de los que dependen esos jar. Afortunadamente maven nos ayuda en el proceso. Sin embargo, la segunda opción es menos elegante pero infinitamente más cómoda. Cuando empiezo el proyecto, me copio el mega-jar-que-lo-tiene-todo y a trabajar, sin más complicaciones.

¿Tú qué eliges?. ¿Elegancia o pereza?

Siguiendo el post anterior, ya me  he dado la pequeña paliza de ir externalizando String por todo el código eclipse para sacar los textos y que alguien los traduzca al inglés y al ruso. Yo domino varios idiomas: colombiano, cubano, chileno, argentino, mexicano, etc, pero inglés no y el ruso menos, así que todo el trabajo para el traductor, que para eso le pagan.

Me comentan que el traductor, cómo no, es ofimático, así que lo de darle los ficheros de propiedades que encima son textos técnicos pues no vale. Tenemos que pasar esos textos en una columna de una hoja excel. Debemos añadir otra columna en la hoja con explicaciones de los textos más complejos, palabras que no se traducen o significado de ciertas palabras técnicas o propias del proyecto. Y dos columnas más vacías, una para que lo ponga en inglés y otra en ruso.

Pues bien, es una oportunidad estupenda para aprender a usar POI y hacer un programa java que haga:

• Se le indica un directorio a partir del cual buscar, que será el directorio del proyecto. A partir de ahí, busca recursivamente todos los ficheros messages.properties generados por eclipse. Para la búsqueda de ficheros recursivamente, he usado un pequeño buscador de ficheros en java que me hice en su día.
• Lee cada uno de esos ficheros y genera varios EXCEL con el formato indicado anteriormente. De cosecha propia he añadido una columna con la "clave" de la etiqueta en el properties, de forma que luego pueda generar los messages_en.properties y messages_ru.properties también de forma automática. Me he inventado lo de _ru, de ruso.
• Salva el excel poniendo un nombre al fichero xls que corresponda más o menos con el paquete donde está el messages.properties. Algo como cambiar los puntos de los paquetes por _

Dicho y hecho. Me he cogido POI, un pequeño ejemplo de uso de otro compañero y me he hecho el programita java. Ahora ando con la tontería de poner en la hoja una cabecera bonita, unos bordes para las celdas y demás.

Aprovecho para dar unas pequeñas indicaciones de cómo se usa POI para crear un EXCEL.

Ante todo, bajarnos el jar de poi. Como lo he hecho con maven, lo he añadido como dependencia en el pom.xml copiando del pom.xml de poi, así que sin problemas, maven crea el proyecto eclipse y se baja el jar.

Y en el código java, lo primero, crear el cuaderno de excel y una hoja

HSSFWorkbook wb = new HSSFWorkbook();
HSSFSheet sheet1 = wb.createSheet("Hoja 1");

creamos ahora una fila, la fila cero, y le ponemos celdas de cabecera

HSSFRow row = sheet1.createRow((short) 0);
HSSFCell cell = row.createCell((short) 0);  // celda de columna 0
cell.setCellValue("ESPAÑOL");
cell = row.createCell((short) 1);  // celda de columna 1
cell.setCellValue("RUSO");
…

y así sucesivamente con el resto de filas y columnas y todos los datos. Finalmente, para guardar definitivamente el fichero

FileOutputStream fileOut = new FileOutputStream("fichero.xls");
wb.write(fileOut);
fileOut.close();

y listo. La verdad es que me ha asombrado lo sencillo que es. Ahora ando metiendo estilos en las celdas y tampoco parece complejo, aunque sí un poco más laborioso. Así que ya tengo dos entretenimientos que hacer. Un par de pequeños tutoriales en la Chuwiki: Un ejemplo sencillo y algo como "ExportTableModelToExcel" y el viceinverso.

Pues acabo de aprender una cosa nueva. Cómo no, una cosa que NO debo hacer, porque hoy me ha tocado sufrir las consecuencias.

Hace aproximadamente un año tuve que hacer un cambio importante en un proyecto. Un cambio en unos pocos ficheros fuente, pero que podían dejar "descojonado" el sistema durante una buena temporada hasta que se volviera a afinar. Así que me decidí a abrir una rama de CVS para hacer mis cambios, de forma que cuando en esa rama todo estuviera adecuadamente depurado, juntarlo con la rama principal con ciertas garantías.

Pues bien, comencé los cambios y lo dejé después de un par de semanas de trabajo casi todo a punto… pero me interrumpieron con otra de esas labores super importantes que no pueden esperar a otro día … y aquella rama se quedó sin juntar … hasta ahora.

Hoy me he puesto a intentar juntar aquella rama con la principal y es un verdadero lio. En parte por recordar qué es lo que había tocado, pero principalmente he tenido que sufrir una de mis pequñas manías. Tengo la manía de refactorizar el código que toco, comentar lo que está sin comentar, arreglar los sangrados, eliminar warnings, etc, etc. Pues bien, eso ha hecho que sea prácticamente imposible ver qué cambios reales de código se hicieron entre la rama principal y la rama secundaria. Un diff de ambas versiones daba por cambiadas casi todas las líneas, aunque sólo fuera por temas de sangrado.

Así que ya sé dos cosas que NO debo hacer:

1. Dedicarme a hacer refactoring en una rama. En las ramas hay que tocar lo mínimo imprescindible para facilitar la tarea de unirlas a la rama principal.
2. No dejar tanto tiempo hasta integrar la rama. Si dejas mucho tiempo, es posible incluso que se te ocurra hacer refactoring y comentar el código de la rama principal, aunque no lo hagas en la secundaria, con lo que el efecto es el mismo.

Y de paso, sé una cosa que no deben hacer NUNCA los jefes

1. Interrumpir a un currito cuando tiene algo a medias con otra cosa muy importante. Y menos interrumpirlo durante un año.

Llevo un par de semanas trabajando con XPlanner.  En él pones las tareas que vas a realizar y la estimación de tiempos de cada una de ellas. Día a día vas poniendo el tiempo que has trabajado en ellas y para ver cómo vas te saca unos gráficos. En el eje horizontal pone los días. En el eje vertical pone las horas estimadas de trabajo y las horas trabajadas.

En la situación ideal, las horas estimadas deberían ser una línea perfectamente horizontal, es decir, has sido capaz de estimar a priori todo lo que tienes que hacer y el tiempo que te va a llevar. El gráfico de horas trabajadas debería ser una línea que empiza en cero y día a día va subiendo hasta, al final del periodo estimado -una semana en mi caso- alcanza a la línea de horas estimadas. Justo en el momento de alcanzar a la de horas estimadas, el trabajo, si todo se ha planificado bien, debería estar terminado.

Pues bien, eso es la situación teórica. Ahí va mi gráfico de esta semana pasada

Ante todo, se puede ver que no tengo ni repajolera idea de planificación. El Lunes no hice absolutamente nada de lo planificado, salvo quizás hacer la planificación, pero que no está planificada la tarea de hacer la planificación. El Martes, Miércoles y Jueves sí hice algo, pero casi todo lo que hacía eran tareas nuevas necesarias que no había previsto. Por eso la curva roja de tiempo previsto, en vez de ser horizontal, va subiendo. El Viernes fue el día que capture el gráfico y por eso no hay todavía datos -por cierto, se me olvidó apuntar el tiempo trabajado al final de la jornada-. Al final, dos conclusiones:

• No he sido capaz de prever las tareas. Cada vez que me meto en ellas, me aparecen tareas previas que hay que hacer y no había previsto.
• El tiempo de trabajo a la semana en lo planificado es más bien escaso. Tengo muchas interrupciones que me ocupan tiempo en cosas que no son de esta guerra. Como excusa, es la semana previa a navidades y tenemos muchos jolgorios asociados.

En fin, lo más importante es no desanimarse y persistir. Como propósito de año nuevo -junto con los consabidos hacer algo de deporte, ponerse a dieta y dejar de fumar-, me pondré el de aprender a planificar.

Por cierto, este es el típico gráfico de Scrum para ver como va el Sprint.

Al final creo que me he decidido por iBATIS. No he hecho más que unas pruebas sencillas con varios -Hibernate, iBATIS, JPOX, etc-, pero al final iBATIS me ha parecido el más "controlable".

Hibernate me ha fallado con la ingeniería inversa, no es capaz de tragarse el mismo los ficheros de configuración que él ha generado, aparte que los plugins y herramientas adicionales parecen bastante descuidadas.

JPOX ni siquiera he conseguido hacerlo funcionar -el plugin para eclipse, ni siquiera lo he probado a mano-. De todas formas, parece que toca los bytecodes después de compilar el código y eso me da "mal rollo".

iBATIS no me ha dado ninguna pega. El plugin para eclipse ha funcionado a la primera y el código generado funciona a la primera. Además, me gusta el tener los SQL visibles en un fichero, ya que siempre da la sensación de tener más control sobre lo que se está haciendo.

Un compañero mio probó cayenne, y aunque la ingeniería inversa se hace estupendamente con una interface gráfica de usuario, en los java beans mete cosas propias de él y no me convenció.

Por supuesto, y siguiendo mi costumbre, he puesto mis pruebas sobre iBATIS en la Chuwiki. Estoy deseando que me toque codificar algo contra una BD…

Como el diablo, cuando no tiene nada que hacer, espanta moscas con el rabo y, aprovechando que soy un poco "nerd" y este puente, me estoy dedicando a generar un sitio web con maven, para mi pequeño proyecto de librería de gráficos en java.

Por supuesto, esta librería no es nada del otro mundo, simplemente un entretenimiento casero para las aburridas largas tardes de invierno. De todas formas, me he entretenido en ponerla disponible para que se pueda usar en proyectos maven, y en generar un sitio maven. Es sólo el comienzo y como hobby, pero ahí está.

• Documentación maven de la librería gráfica.
• Repositorio maven con el jar.

A ver en qué queda todo esto…

PD: Estoy totalmente de acuerdo con las conclusiones sobre maven site de ese enlace.

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.

Normalmente me gusta probar las herramientas antes de elegir una, pero a veces puede ser tarea difícil.

¡¡ Como para probar la cantidad de IDEs que hay por el mundo !!

Vía 4bits blog.

Sigo con mis pruebas de herramientas/librería de persistencia en base de datos.

Con Hibernate conseguí que funcionara. El ejemplo tonto con una única tabla funcionó casi a la primera. Las HibernateTools - Middlegen para sacar los .xml y los .java a partir de la base de datos me dieron más problemas, pero también funcionaron.

Luego hice pruebas con iBatis. La filosofía de trabajo es distinta, pero el plugin de eclipse me funcionó bien e iBatis genera código hasta un nivel más alto, genera una interface de DAO y una implementación iBatis.

Investigando, descubro que hay una especificación de Java, llamada JPA -Java Persistent API, parte V del tutorial de JEE-, que pretende indicar cómo trabajar con objetos java persistentes -que se guardan más o menos solos en base de datos, sin que el programador tenga que preocuparse de los SQL-.

También descubro que la gente de Apache ha hecho otra especificación similar, JDO, para lo mismo, pero que pretende ser más completa que JPA.

También descubro JPOX, una implementación que cubre las dos especificaciones anteriores: JPA y JDO. Sin embargo, no he conseguido que me funcione. Desde eclipse con el plugin correspondiente me falla al crear las tablas en base de datos y de momento me ha dado pereza crearlas a mano. En cuanto a maven, tienen una mezcolanza rara. Parece que se han quedado en maven 1 según la documentación, pero si te lo bajas con maven 2 está disponible, aunque no encuentro documentación para configurarlo.

Y descubro también que eclipse dali viene con una perpectiva y un "wizard" de proyecto para trabajar con objetos persistentes JPA. Por supuesto, tampoco me ha funcionado.

Y para marear más la perdiz, y todavía sin probar, Glassfish de java lleva una implementación de JPA, hay también otra implemantación de Apache OpenJPA,

En fin, todo un mundo y un abanico de posibilidades. Para probarlas todas no basta con que se paren dos meses la producción, harán falta varios años . De cualquier forma, Hibernate es uno de los que menos problemas me ha dado -descontando los de MiddleGen- y yo creo que sin duda es el más conocido. Aunque la filosofía de trabajo es distinta, iBatis también es conocido y da la impresión de que tienes más control sobre lo que estás haciendo. Ambos están "soportados" por SpringFramework -ver capítulo 12- que sí pienso empezar a usar, así que creo que me centraré un poco más en Hibernate e iBatis.