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.
Categorías: Software Quality
Etiquetado: Calidad del software, Software Quality
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 :)
Categorías: Maven Plugins · Open Source
Etiquetado: Sonar, Sonar PDF Plugin
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”.
Categorías: Herramientas · Open Source
Etiquetado: PDF, Sonar, Sonar PDF Plugin
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
Categorías: Herramientas
Etiquetado: Archiva, Maven repository, Nexus
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 ;-)
Categorías: Miscelánea
