Minimizando el tiempo de carga: Maven YUI Compressor

Cuando se usan frameworks Javascript, como ExtJS o YUI, en la capa de presentación de una aplicación web nuestro navegador debe descargar todo el Javascript antes de poder mostrar nada. Esto se traduce en un tiempo de espera, por parte del usuario, en ocasiones demasiado largo. Una medida, como otras muchas, de calidad del software, es la satisfacción del usuario final en cuanto a rendimiento de la aplicación, y por tanto debe ser tenida en cuenta durante el proceso de SQA.

Una solución a este problema es la aplicación conjunta de dos métodos: compresión/ofuscado (minify) y uso de un solo fichero que contiene todo el Javascript. De esta forma el navegador sólo debe hacer una llamada para descargar un fichero comprimido, y no decenas de llamadas para descargar cada pequeño fichero Javascript (sin comprimir).

Este proceso puede hacerse a mano, usando herramientas como YUI Compressor, o automatizarlo durante el ciclo de vida de nuestro proyecto Maven. El plugin Maven YUI Compressor hace uso de la herramienta citada anteriormente para integrar este proceso durante el empaquetado de la aplicación web.

La configuración que requiere el plugin en el pom es la siguiente:

<plugins>
    <plugin>
        <groupId>net.sf.alchim</groupId>
        <artifactId>yuicompressor-maven-plugin</artifactId>
        <version>0.7.1</version>
        <executions>
            <execution>
                <goals>
                    <goal>compress</goal>
                </goals>
                <phase>generate-sources</phase>
            </execution>
        </executions>
        <configuration>
            <nosuffix>false</nosuffix>
            <jswarn>false</jswarn>
            <preserveStringLiterals>true</preserveStringLiterals>
            <preserveAllSemiColons>true</preserveAllSemiColons>
            <nomunge>true</nomunge>
            <failOnWarning>false</failOnWarning>
            <sourceDirectory>${basedir}/src/main/webapp/public</sourceDirectory>
            <outputDirectory>${project.build.directory}/compressed/public</outputDirectory>
            <aggregations>
                <aggregation>
                    <includes>
                        <include>**/*-min.js</include>
                    </includes>
                    <output>
${project.build.directory}/${project.artifactId}-${project.version}/public/scripts/todo-el-javascript.js
                    </output>
                </aggregation>
            </aggregations>
        </configuration>
    </plugin>
</plugins>

Esta configuración realizará las siguientes tareas:

1. Comprimir/ofuscar (minify) cada fichero Javascript generando un fichero [nombre_original]-min.js
2. Colocar el código comprimido en target/compressed/public
3. Unir todos los ficheros ofuscados (*-min.js) en uno: todo-el-javascript.js
4. Colocarlo en target/[artifact]-[version]/public/scripts

En el proyecto que he usado como ejemplo se ha conseguido reducir en un 40% el tamaño total en bytes del código Javascript que el navegador debe descargar, a esto hay que sumarle la ganacia en tiempo que se produce al descargar un solo fichero con una sola petición.

Este plugin además ofrece otra funcionalidad, el análisis estático del código usando Jslint, pero esto será tratado en otra entrada futura ;)

Recopilando la información (II): Maven Dashboard Report Plugin

Como comenté hace unos días (en el post anterior) he configurado Maven Dashboard Report Plugin para un proyecto Open Source que conozco de cerca, Opina: gestor de encuestas. La versión 2 de esta aplicación está compuesta por dos módulos (por ahora) y está en una fase temprana de su implementación.

La configuración no es compleja, basta seguir la documentación publicada en la propia página del plugin, la única peculiaridad es que, como he comentado, Opina está compuesto de varios módulos Maven, para ello también hay documentación en la página oficial.

El resultado ha sido el siguiente. Para el módulo opina-model:

Para el módulo opina-dao:

Y lo que más me gusta, un resumen que agrupa a todos módulos:

Maven Dashboard Report Plugin: recopilando la información

Hace unas semanas me encontré con este interesante plugin para Maven: Maven Dashboard Report Plugin.

Con el paso del tiempo se van incluyendo plugins de generación de reportes a nuestros proyectos, pero llega un momento en que la información es tanta y tan dispersa (PMD, Findbugs, Checkstyle, Surefire Report, etc) que empieza a dejar de ser útil. Es aquí donde surge la necesidad de aglutinar la información en un dashboard que nos proporcione de un vistazo la información que requerimos, pudiendo profundizar posteriormente en el aspecto que consideremos oportuno. Precisamente esto es lo que ofrece Maven Dashboard Report Plugin.

Mediante gráficos resumen y datos globales obtenemos una visión general de todos los reportes que se han citado anteriormente.

Otro aspecto muy interesante es la posibilidad de usar una base de datos para almacenar un histórico de los reportes, pudiendo generar gráficos que muestran la evolución a lo largo del tiempo de nuestros reportes.

Estoy configurándolo en un proyecto Open Source que conozco desde hace algún tiempo, en cuanto lo tenga dejaré caer por aquí los resultados.

Guía práctica para hacer fracasar un proyecto

Si tenemos por objetivo que un proyecto fracase estrepitosamente, no tenemos más que cumplir las siguientes directrices (o buenas prácticas) de forma escrupulosa:

1. No usar un sistema de control de versiones, lo mejor es que cada desarrollador trabaje en su propia máquina.
2. No documentar absolutamente nada, el propio código es la mejor documentación.
3. Cada desarrollador debe hacer lo que quiera, sin nadie que coordine su trabajo y sin ningún tipo de comunicación entre ellos.
4. Es fundamental que no se defina ningún tipo de prueba, y prohibir terminantemente el uso de sistemas de integración continua.
5. No compilar de forma frecuente, a lo sumo, una vez a la semana.
6. Si el proyecto comprende bloques funcionales independientes, es imprescindible no realizar ninguna prueba de integración, solamente se hará una, el día antes de poner la aplicación en producción.
7. Asegurar que nunca se sabrá quién hizo qué, de esta forma, a falta de documentación (véase punto 2), mantendremos los indices de inmantenibilidad en los valores deseados.
8. El proceso de despliegue de la aplicación debe ser lo más complejo posible, por supuesto indocumentado y ligado a la máquina en la que se desarrolló.
9. Y claro está, lo más importante, las palabras «Quality Assurance» jamás serán pronunciadas.