Hace unos días se ha publicado Sonar PDF Plugin 1.0, con una mejora fundamental: el documento PDF se almacena en la base de datos tras cada análisis y puede descargarse desde la GUI de Sonar.

PDF Download from Sonar GUI

También es posible configurar el tipo de reporte desde la interfaz de administración de Sonar:

PDF report type configuration

Se  puede encontrar información más detallada (instalación y uso) en la documentación del proyecto.

Cuando hablamos de calidad del software podemos hacerlo a muchos niveles: rendimiento, mantenibilidad, cumplimiento de requisitos funcionales, estabilidad, proceso de construcción,… y el que en mi opinión constituye la base, el código fuente.

Desde mi punto de vista la calidad del código fuente se extiende hasta otros niveles, por ejemplo, el rendimiento. De hecho, cuando nos disponemos a realizar una auditoría de rendimiento el punto de partida siempre debería ser el código fuente, éste nos puede dar pistas sobre los puntos débiles de la aplicación, los cuales orientarán las pruebas de rendimiento.

Supongamos un caso de uso simple (y muy común): una aplicación web escrita en Java que permite la subida de un fichero a través de un formulario, cuando este stream de datos llega al servidor se carga en memoria y posteriormente se almacena en base de datos. Si tenemos la mala suerte de que al programador se le “olvide” cerrar el stream después de usarlo y por algún motivo esta memoria no sea liberada por el recolector de basura de la JVM, entonces tenemos un problema: ese espacio de memoria no se liberará NUNCA.

La herramienta PMD detecta, entre otras muchas, una mala práctica de programación consistente en no cerrar correctamente los recursos (streams de ficheros, conexiones a bases de datos, etc) después de usarlos. Si la utilizásemos para analizar el código fuente de la aplicación descrita anteriormente nos indicaría que no se está cerrando un recurso. Si lo que buscamos son causas de un problema de memoria en tiempo de ejecución, vamos en el camino correcto. Definiremos una prueba que ejecute el caso de uso en cuestión y la ejecutaremos simulando N usuarios, al mismo tiempo podemos monitorizar el servidor de aplicaciones y verificar que realmente estamos ante un memory leak.

Desde ayer está disponible en el repositorio central de Maven Sonar PDF Plugin 0.3.

Como comentaba hace unos días, esta versión ofrece (además de un nuevo tipo de reporte) la posibilidad de usar Sonar PDF como un plugin propio de Sonar (hasta ahora sólo era posible usarlo como un plugin de Maven), configurable desde la propia GUI. La configuración se limita actualmente a la activación o desactivación del reporte.

Este plugin es el primero (en la forja de Sonar Plugins) que hace uso del concepto de “Sonar post-job”: acciones que se ejecutan como parte del ciclo definido por sonar:sonar una vez finalizado el análisis. Es decir, una vez instalado el plugin en Sonar, al ejecutar mvn sonar:sonar sobre uno de nuestros proyectos estaremos generando un reporte PDF al final del análisis (el reporte se almacena en el target de la copia de trabajo).

En la página del plugin hay disponible información más detallada en relación a la instalación, un enlace para la descarga directa de los binarios y características generales.

¿Qué hay previsto para la versión 0.4?

• Revisión del diseño de los reportes
• Inclusión de más opciones de configuración desde Sonar (por ejemplo, selección del tipo de reporte)
• Disponibilidad de descarga del reporte desde la interfaz gráfica de Sonar

Pero por ahora, disfrutemos de la versión 0.3 :)

A partir de la versión 0.3 de Sonar PDF Report (su publicación se realizará en los próximos días) se podrá configurar su uso desde la interfaz gráfica de Sonar.

Por ahora sólo podemos indicarle a Sonar que genere el reporte en PDF como parte del análisis, haciendo uso del concepto de “post-jobs” (a partir de la versión 1.10).

PDF Report en la GUI de Sonar

El siguiente paso será dotar a la interfaz de más posibilidades de configuración, como la selección del tipo de reporte, y por último la inserción del reporte en la base de datos para poder descargarlo desde el navegador, pero esto es el futuro… no muy lejano.

El proceso para instalar el plugin en Sonar es el estándar para todos los plugins, copiar el jar en el directorio de extensiones y reiniciar Sonar.

Me gustaría agradecer a Simon Brandhof la ayuda en la integración del plugin como “post-job”.

En estos días estamos renovando nuestro ecosistema, el primer habitante nuevo ha sido Nexus, posiblemente le sigan Hudson, nuevas versiones de Subversion, Trac y Sonar.

La migración de Archiva a Nexus ha sido realmente suave, del lado del “cliente” (Maven) el impacto ha sido simplemente el cambio de una URL en settings.xml, donde digo Archiva digo Nexus y listo.

Del lado del servidor la cosa no ha sido mucho más compleja. Nexus viene configurado perfectamente:

• Un repositorio interno de releases
• Un repositorio interno de snapshots
• Un grupo de repositorios de releases (incluye el interno, en central y el de codehaus)
• Un grupo de repositorios de snapshots (incluyendo el interno y el de codehaus)

Sólo había un pega, ¿qué pasa con los artefactos internos que tenemos desplegados en nuestro Archiva (lo que viene a ser nuestro proyecto Commons)? ¿y que pasa con los artefactos que hemos desplegado porque no se encuentran en ningún repositorio público (p.e. driver de Oracle)?

La solución ha sido mantener los dos repositorios (Archiva y Nexus) durante un tiempo y decirle a Nexus que haga mirror de Archiva.

Para ello hemos creado dos nuevos repositorios (releases y snapshots) de tipo “Proxy” en Nexus que apuntan a las URLs de nuestro Archiva.

New proxy repository

Hecho esto tenemos un proxy de Archiva en Nexus, pero la idea es poder eliminar (apagar) Archiva en unos días/semanas y deshabilitar los proxies que hemos creado en Nexus. Para poder borrar los proxies sin perder la “importación” de los artefactos debemos mapear el “local storage” de los proxies en los correspondientes repositorios internos (Archiva releases con Nexus Releases e idem para snapshots), en lugar de usar el valor por defecto.

Override local storage

Hoy ha sido uno de esos días en los que me doy cuenta lo mucho que me gusta mi trabajo.

Ha habido un momento en que me he visto a mi mismo, allí sentado, con dos portátiles delante, uno mostrándome 9 consolas recibiendo los datos de 9 load tests (cada uno modelando un caso de uso del sistema) ejecutandose simultáneamente. El otro mostrándome un conjunto de gráficas sobre el estado del servidor de aplicaciones, todo en tiempo real.

En la misma sala, 5 equipos controlados desde las consolas ejecutando las pruebas y reportando información.

Terminada la primera tanda, decidimos modificar algunas pruebas, lo hago en el equipo que tengo delante (en 3 de las consolas), automaticamente los 5 equipos controlados reciben los cambios, ya estamos preparados para la segunda tanda.

20 minutos, ese el tiempo que he dejado correr los test, ese el tiempo que he tenido para pensar (y disfrutar) del tinglado que teníamos allí montado.

El resultado, una prueba que ha sometido al sistema a una carga muy cercana a lo que sería la mitad de los usuarios potenciales accediendo simultáneamente, y que nos ha dado un conjunto de datos muy valiosos.

Y por si eso es poco, llego a la oficina y me encuentro una sala con las paredes empapeladas con prototipos de una aplicación y anotaciones a rotulador, tres de mis compañeros comentado algo sobre unos de los posters, les digo “¿qué ha pasado aquí?“,  y me contestan “nada, una sesión de trabajo con el cliente“… !impresionante!

Pues eso, me gusta mi trabajo ;-)

Cuando ejecutamos pruebas de carga sobre una aplicación web en un entorno de producción nos enfrentamos a una serie de restricciones:

• No podemos ejecutar ninguna herramienta en el entorno de producción. Debemos limitarnos a tocar parte de la configuración.
• No tenemos interfaz gráfica
• Las condiciones del entorno son “las que son”, no hay posibildad de cambio.

Para la ejecución de las pruebas no hay demasiados problemas, accedemos a modo de cliente, con herramientas como Tsung (comentada aquí hace poco tiempo) o The Grinder (con la que estoy teniendo una estrecha relación ultimamente, y escribiré algo pronto).

Los problemas vienen a la hora de tomar datos de rendimiento de la JVM mientras ejecutamos el load-test, que dadas las condiciones anteriores debemos hacerlo de forma remota. Hay varias herramientas que nos pueden ayudar, como son VisualVM o JConsole (ambas distribuidas con JDK 6). Yo me he quedado con JConsole por una sola razón: en modo remoto me proporciona más información sobre la JVM que VisualVM (para monitorizar en local, no hay duda, VisualVM es la elección).

Para configurar el acceso remoto de JConsole se debe lanzar la máquina virtual a monitorizar con las opciones:

-Djava.rmi.server.hostname=192.168.0.12
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9005
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

Comprobamos desde la máquina cliente (la que usaremos para lanzar JConsole) que el puerto está abierto en la máquina objetivo (en el ejemplo 192.168.0.12):

Antonio$> nmap 192.168.0.12 -p 9005
Starting Nmap 4.53 ( http://insecure.org ) at 2009-06-14 21:26 CEST
Interesting ports on 192.168.0.12:
PORT     STATE SERVICE
9005/tcp open  unknown

NMap done: 1 IP address (1 host up) scanned in 0.144 seconds

Sólo queda iniciar JConsole:

Antonio$> jconsole 192.168.0.12:9005

JConsole monitoriza memoria, CPU, Threads y clases instanciadas, además muestra un dashboard muy útil:

JConsole Dashboard

JConsole Memory

JConsole Classes

JConsole Summary

Hace unos días hemos publicado Sonar PDF Plugin 0.2. Los cambios principales son: compatibilidad con Sonar 1.9, uso de “-Dbranch” e inclusión de hotspots en el reporte.

La publicación de esta nueva versión ha coincidido con la inclusión de Sonar en el Marco de Desarrollo de la Junta de Andalucía (proyecto MADEJA) como herramienta de verificación de la calidad del código de las aplicaciones desarrolladas para la administración pública andaluza.

Buscando herramientas para realizar labores de profiling Java he encontrado JIP (Java Interactive Profiler). Esta herramienta permite monitorizar a nivel de máquina virtual parámetros tan útiles como métodos que más tardan en ejecutarse, número de veces que se llama al método o el tiempo que ocupó su ejecución durante la vida del Thread que lo contenía.

Además su configuración es muy sencilla, algo poco común en el mundo del profiling Java. Tan solo es necesario iniciar la máquina virtual con los siguientes parámetros:

-javaagent:/antonio/jip/profile.jar -Dprofile.properties=/antonio/jip/profile.properties

En función del contexto en el que nos movamos estas propiedades se configuran de un modo u otro. Por ejemplo, si estamos monitorizando una aplicación web que es lanzada a través de un wrapper incluiremos entradas en el wrapper.conf, pero si nuestra aplicación está en un Tomcat sólo tenemos que incluirlas en $CATALINA_OPTS. Eso si, las rutas a profile.jar y profile.properties (ambos incluidos en la distribución de JIP) deben ser absolutas.

Al inciar la JVM debemos ver en los logs lo siguiente:

Java Interactive Profiler: starting

Si no, algo hemos hecho mal.

Para iniciar la monitorización haremos uso del cliente de JIP:

./file.sh localhost 15599 /Users/Antonio/temp/jip/jip-1.1.1/client/dump.txt
./start.sh localhost 15599

Esto inciará la sesión de profiling. Cuando hayamos realizado las pruebas oportunas:

./finish.sh localhost 15599

Si todo ha ido bien debemos tener en el directorio seleccionado dos ficheros nuevos: dump.txt y dump.xml. Para visualizar los resultados de una forma más amigable podemos usar jipViewer:

./jipViewer.sh dump.xml

La aplicación Java nos mostrará todos los datos del análisis:

JIP Viewer

Para terminar comentar que hay algunos detalles mejorables: la documentación en cuanto a interpretación de los datos es escasa y la aplicación monitorizada va mucho más lenta cuando se está monitorizando. Esto último es un factor común a todas las herramientas de profiling debido al uso de agentes Java que inyectan código para poder realizar los cálculos de tiempo necesarios.

Ya hablaba de esto hace algún tiempo, y después de varios meses de trabajo hemos publicado la primera versión (0.1) de Sonar PDF Plugin.

En esta primera versión se ha optado por envolver la lógica de generación del reporte en un plugin para Maven, el cual está disponible en el repositorio central de Maven.

El reporte actual contiene:

• Información general del proyecto (nombre, descripción, version, módulos)
• Dashboard (indicadores proporcionados por Sonar, similar al dashboard que muestra Sonar en su interfaz web)
• Violaciones de reglas por categorías
• Reglas más violadas
• Ficheros que más violan las reglas
• Todo lo anterior para cada módulo que compone el proyecto (si existe alguno)

Ya hay algunas mejoras reflejadas en JIRA para la versión 0.2, seguiremos trabajando.

Seguro que todos nos hemos encontrado con ciertas peculiaridades de las herramientas que usamos día a día, pero encontrarse con dos (de las buenas) en un solo día, eso no tiene precio ;) sobre todo cuando el tema te quita medio día.

Son sólo detalles, pero si se dan las condiciones precisas… puede ser un quebradero de cabeza.

Cuando hay dos clases con el mismo FQN (Fully Qualified Name) en el classpath, ¿cuál de las dos se carga? Pues la respuesta es que depende, con Java 1.5 puede ser una, y con Java 1.6 puede ser otra. Resulta que tenía en mi classpath tres versiones de commons-collections (fruto de descontrol con las dependencias transitivas). Si ejecutaba los tests con Java 1.5 todo iba bien, se estaba usando commons-collections-3.1 (que era la versión que yo tanía en mi POM). Pero si usaba Java 1.6 resulta que se cargaba commons-collections-2.1.1 y uno de los métodos que se llamaba por reflexión no existía en esta versión pero sí en la 3.1. La solución, estudiar de donde viene esa dependencia transitiva y excluirla en el POM para que no haya diferentes versiones de un mismo artefacto.

¿Por qué no me aparecen los enlaces a los módulos hijos en el Maven Site? Mi proyecto tenía la estructura típica de un proyecto Maven multimódulo. Configuré los ficheros site.xml para que en el Maven site se pueda navegar mediante enlaces desde el proyecto padre a los hijos y viceversa. Resulta que los enlaces no aparecen. El problema resultó ser que en los POM de los módulos hijos tenía una etiqueta <url> y su contenido era el mismo que en el POM padre, quitando este nodo en los POM de los hijos… problema resuelto. Cuanto menos, curioso.

En fin, el primero de los problemas lo detecté rápido mirando las dependencias transitivas de mi proyecto con Q4E. El segundo fué más bien suerte y gracias alguna incidencia en Codehaus que hablaba de la influencia en el site de la etiqueta <url>.

Ayer GMV realizó una ponencia en IMAGINATICA 2009 y  tuve la oportunidad de poder participar en la misma.
En mi intervención intenté expresar a un colectivo de alumnos de la Universidad de Sevilla (estudiantes de Ingeniería Informática mayoritariamente) cómo entendemos el Software Libre en GMV. Comenté nuestra participación en proyectos Open Source que forman parte de nuestro ecosistema software como Continuum, proyecto en el que mi compañero José Morales está trabajando, o Sonar, para el que estamos desarrollando una nueva funcionalidad de la que yo mismo me estoy ocupando.

Sigo pensando que ese peldaño que hay entre la Universidad y la Empresa es demasiado alto, cuando se habla de herramientas como Trac o Subversion en un foro universitario… desgraciadamente pocos las conocen (desde luego yo tampoco las conocía cuando estudiaba). Quizás no estaría demás alguna asignatura orientada en este sentido.

La empresa en la que trabajo (GMV) está apostando con fuerza por el Software Libre, fruto de esta apuesta es la contribución a varios proyectos Open Source, entre ellos Sonar. Cuando se me dió esta oportunidad, no tuve dudas, quería aportar algo a este magnífico proyecto, del cual llevábamos sacando partido bastante tiempo.

Desde hace algún tiempo trabajo (entre otras cosas) para desarrollar un nuevo módulo en Sonar, Sonar PDF Reporter. El objetivo del módulo es añadir una nueva funcionalidad a Sonar que permita la explotación en forma de entregable de gran parte de la información que nos ofrece esta herramienta en su interfaz web.

El módulo genera un archivo PDF que contiene:

• Visión general de la calidad del código de todo el proyecto.
• Información concreta por módulos funcionales: métricas y medidas obtenidas a partir combinaciones de las métricas.
• Información general del proyecto: versionado, estructura de módulos, descripción, etc

Además de ser un módulo integrado en Sonar, durante el diseño siempre tuve en mente el posible uso del módulo de forma independiente, es decir, ofrecer la posibilidad de explotar la información que Sonar proporciona desde nuestra propia aplicación, por ello se ha hecho uso de Web Services API de Sonar.

Sonar PDF Reporter Design

Quedan bastantes retoques y mejoras por realizar, pero puedes descargar un PDF de ejemplo con los reportes del propio proyecto Sonar, y ver en primicia el resultado ;)

Ayer estuve en el encuentro tecnológico “Medidas y calidad del software”.

Las charlas fueron bastante interesantes. Destaco dos:

“Situación de la calidad del software en España: Estudios e Indicadores”

En esta charla Ignacio Caño (Inteco) Luna nos mostraba el último estudio realizado desde Inteco: un sondeo basado en encuestas a PYMES y grandes empresas. De él se desprendía el bajo conocimiento de las normas en cuanto a calidad, y proponía el conocimiento a través de certificaciones (en otras charlas se dijo exactamente lo contrario, en fin, son puntos de vista, veremos que depara el futuro), en cualquier caso el estudio realizado era bastante interesante.

“Métricas de la calidad del software”

Esmeralda Mancheño (Matchmind) nos presentó a uno de sus clientes, ISBAN. La responsable de calidad de ISBAN nos hizo partícipes del criticismo de la calidad en los productos orientados a la banca, donde los errores son tan caros que no pueden permitirse. Proponía la medición de todo tipo de parámetros como una forma de mejorar el producto tomando decisiones en función del resultado de estas mediciones. Me sorprendió una frase: “En ISBAN no tenemos presupuesto para la gestión de la calidad, el director dice que está todo pagado”. Supongo que un fallo en algún sistema informático del banco puede hacerles perder más dinero del que hayan invertido en 10 años en calidad…

¿Es posible aislar todo el código javascript de nuestra aplicación web en un proyecto a parte?

Si, lo es. Con javascript-maven-tools, en concreto con javascript-maven-plugin. Este plugin nos permite tratar con proyectos de tipo javascript, es decir, esto sería válido:

...
<dependencies>
    ...
    <dependency>
        <gruopId>example.javascript</groupId>
        <artifactId>my-javascript</artifactId>
        <version>1.0.0</version>
        <type>javascript</type>
    </dependency>
    ...
</dependencies>
...

Este plugin habilita el uso del tipo “javascript” en nuestras dependencias. Sólo debemos configurarlo:

<build>
    <plugin>
        <groupId>org.codehaus.mojo.javascript</groupId>
        <artifactId>javascript-maven-plugin</artifactId>
        <version>1.0-alpha-1-SNAPSHOT</version>
        <extensions>true</extensions>
        <executions>
            <execution>
                <id>js-copy-deps</id>
                <goals>
                    <goal>war-package</goal>
                </goals>
                <phase>package</phase>
            </execution>
        </executions>
    </plugin>
</build>

¿Y el artefacto javascript, cómo se crea?

Pues definiendo un proyecto maven de tipo “javascript”. Es decir, el “packaging” será de tipo “javascript” en el POM:

<packaging>javascript</packaging>

Y definiremos la siguiente extensión:

...
<build>
    <extensions>
        <extension>
            <groupId>org.codehaus.mojo.javascript</groupId>
            <artifactId>javascript-maven-plugin</artifactId>
            <version>1.0-alpha-1-SNAPSHOT</version>
         </extension>
    </extensions>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo.javascript</groupId>
            <artifactId>javascript-maven-plugin</artifactId>
            <version>1.0-alpha-1-SNAPSHOT</version>
            <extensions>true</extensions>
         </plugin>
     </plugins>
</build>
...

Maven tratará nuestro proyecto como un projecto más, y tenemos a nuestra disposición toda la potencia de la gestión de dependencias de Maven.

Para configurar el comportamiento del plugin debemos indicarle un proporcionar un par de parámetros, basta con incluir las propiedades en el POM:

<properties>
    <scripts>public/scripts</scripts>
    <lib></lib>
    <useArtifactId>true</useArtifactId>
</properties>

Eso es todo. Solo un detalle más, el plugin tiene algunos bugs, he reportado un parche a sus desarrolladores, aún no lo han incluido en la versión actual. Siempre podemos descargar el código y parchearlo nosotros mismos ;)