Blog dedicado a la distribución GNU/Linux que uso habitualmente, Arch Linux, a mis andanzas alrededor del software libre, la programación y a otros temas relacionados con la tecnología y la informática.
Disponer de información para tratar de averiguar la causa de un problema es vital para poder resolverlo rápidamente. Para ello existen los sistemas y librerías de trazas que permiten a la aplicación sacar mensajes a un archivo para su consulta posterior ya sea en Java, Javascript o seguro que otros lenguajes.
En el caso de Grails inyecta en varias entidades como controladores, servicios y clases de dominio el objeto log con el que se pueden emitir las trazas con el nivel que deseemos.
Sin embargo, a veces nos puede resultar interesante también sacar alguna traza en los gsp para conocer que es lo que se ha emitido, especialmente si se trantan de gsp que contienen lógica de negocio con etiquetas g:if especialmente complejas. Tener mucha lógica en las vistas es una práctica no recomendada para evitar el código espagueti en los gsp que en el mantenimiento puede causarnos problemas al posiblemente tener esa lógica duplicada en varias zonas diferentes de la aplicación. Los frameworks que usan un sistema de plantillas donde por un lado están los datos y por otro la plantilla sin una posibilidad propia («built-in») de extraer esa lógica a una entidad externa suele ser habitual. Esto nos puede obligar a precalcular todas esas condiciones y pasarlas a la visa como datos lo que nos exige conocer previamente en el controlador exactamente que datos necesita la vista y mantener el código de dos archivos sincronizados o crear métodos con esa lógica en los objetos que le pasamos a la vista como podrían ser en las entidades persistentes de dominio.
Una forma de emitir trazas desde un gsp es incluir un scriptlet que obtenga un logger y posteriormente hacer log.debug. Pero si hacemos esto en muchos gsp y de forma habitual es mejor hacerlo con un tag ya que el código de los gsp nos quedará más limpio y será un poco más sencillo además de tener centralizado en un único sitio el tratamiento de los logs de todos los gsp. Ese tag necesitará recibir el nivel de la traza y el mensaje de la traza al menos. Podría ser como lo siguiente:
Su uso en un gsp sería:
Y este sería el caso para el framework grails y su parte de visualización con gsp, para otros frameworks que probablemente tengan otro sistema para la parte de la vista nos puede ser útil una solución con similar funcionalidad.
En Java los archivos Properties que se cargan con la clase ResourceBundle utilizados comúnmente para realizar la internacionalización y la localización a varios idiomas en una aplicación Java por defecto usan la codificación de caracteres ISO-8859-1 (salvo que usemos un framework o una librería lo haga de otra forma). Los caracteres que no pertenezcan al ISO-8859-1 deben ser escapados, por ejemplo \u20AC para el símbolo del euro (€). Esto hace que si tenemos una aplicación que trabaja con caracteres en varios idiomas tengamos unos ficheros properties con un montón de caracteres de escape que impide su legibilidad al momento de escribirlos o nos obliga a usar el comando native2ascii lo que nos produce también archivos poco legibles.
La clase ResourceBundle permite cargar archivos properties según un Locale pero como digo los carga con la codificación ISO-8859-1 y esto es un problema para los locales como el chino donde casi todos los caracteres deben ser escapados. Si queremos tener archivos más legibles y sin necesidad de escapar los caracteres debemos extender la clase ResourceBundle.Control y redefinirla un poco para que cargue los properties en UTF-8. La implementación sería la siguiente:
El código anterior es parte de la clase EncodingControl donde está redefinido el método newBundle. La magia está en la siguiente linea, donde al InputStreamReader se le indica la codificación de caracteres:
Su uso para cargar los ResourceBundle sería:
Y el programa completo en el que puede verse una carga de un archivo properties con codificación ISO-8859-1 y otro con codificación UTF-8:
Como la RPi la uso por SSH y sin interfaz gráfica necesitaba buscar un reproductor de música basado en una interfaz de texto, que permaneciese ejecutandose a pesar de terminar la sesión ssh y usable desde la terminal para reproducir música además de que consuma pocos recursos (ridículos comparados con cualquier programa gráfico). Después de una búsqueda en google y en la wiki de Arch Linux encontré cmus (C* Music Player). Y me ha parecido tan sencillo y bueno que se ha convertido en mi reproductor de música incluso en el ordenador personal que uso con interfaz gráfica, no necesito más que lo que ofrece, antes usaba Banshee y anteriormente Rhythmbox.
La dificultad de los programas o comandos basados en la consola es que suelen ser menos intuitivos que los que tienen interfaz gráfica para los usuarios nuevos de esos programas. A continuación explicaré el funcionamiento básico de cmus para que un usuario que esté buscando en este programa una alternativa al que usa ahora le sea más sencillo iniciarse y no abandone cmus por otra opción porque le cueste descubrir como conseguir con él lo que uno quiere. Primeramente deberemos instalar su paquete, en Arch Linux con:
Nada más iniciar cmus nos encontraremos con una lista vacía de nuestra colección de música. Primeramente debemos conocer es que cmus se divide en varias pantallas (o tabuladores) que se acceden con las teclas:
1 para Colección de música
2 para Librería de música
3 para Lista de reproducción
4 para Cola de reproducción
5 para Navegador de archivos
6 para Librería de filtros
7 para Configuración y referencia de teclas
Para añadir nuestra colección en música mp3 u ogg iremos al navegador de archivos, una vez que estamos en el directorio que contiene la música que queremos añadir pulsamos al tecla «a» sobre el directorio, cmus buscará de forma recursiva los archivos de esa carpeta. En la pestaña de la Colección de música veremos que ya contiene los archivos organizados por artista y álbum. Con las flechas «arriba» o «k» y «abajo» o «j» podemos cambiar de artista y con la tecla «espacio» podemos expandir un artista para ver cada unos de sus álbumes, con la tecla «tabulador» cambiamos entre el panel artista/álbum y track. Con la tecla «retorno» podemos reproducir un artista, álbum o pista dependiendo de donde este la selección o foco.
Si queremos crear una lista de reproducción con música de varios artistas, álbumes o pistas estando en la Colección de música pulsaremos la tecla «y», con esta tecla la música se irá añadiendo a la Lista de reproducción. Estando en la Lista de reproducción podemos hacer que se reproduzca de forma aleatoria con la tecla «s» o de forma repetida «r», en la barra de estado en la parte inferior veremos las opciones que están activas (CRS). Con las tecla «z» podemos reproducir el elemento anterior de la lista, con la tecla «x» iniciamos la reproducción desde el inicio de la pista, con «c» pausamos/reiniciamos la reproducción, con «v» se detiene la reproducción y con «b» se reproduce el siguiente elemento de la lista. Todas estas teclas de reproducción están en la fila de abajo y todas seguidas en el teclado con lo que es cómodo usarlas y no muy complicado de recordarlas.
Si queremos limpiar la Lista de reproducción o nuestra Colección de música podemos hacerlo individualmente sobre cada elemento con la tecla «Supr» o «D» (la mayúscula es importante) o con el comando :clear, los comandos de cmus funcionan de forma similar a como se trabaja con vim, primeramente pulsando «:» y luego introduciendo el comando y pulsando la tecla retorno. Para buscar una pista en la Librería de música pulsamos «/» seguido del término de la búsqueda, según vayamos escribiendo la lista se irá posicionando el el primer elemento encontrado, si queremos encontrar la siguiente coincidencia podemos hacerlo con la tecla «n» (al igual que con vim). Con los comandos «:save ~/playlist.pls» podemos guardar la lista de reproducción y con «:load ~/playlist.pls» cargarla.
Aunque pueda parecer que no y en muchos casos no se tenga en cuenta la diferencia que puede haber entre una aplicación web no optimizada y optimizada puede ser significativa en varios aspectos.
¿Por que en algunos casos es importante optimizar la aplicación? Uno de los motivos es conseguir una mejor experiencia de usuario haciendo que la página le cargue más rápido. Una página que tarde en cargar demasiado puede significar pérdida de visitas y si se trata de una página de comercio electrónico de clientes y compras. Si un flujo importante de usuarios de una página procede de las búsquedas la velocidad de carga de la página es importante ya que es una de las variables que tiene muy en cuenta el algoritmo de Google para establecer el ranking de los resultados, reducir el tiempo de carga puede significar aparecer antes en los resultados de la búsqueda y esto significa más clics en nuestro resultado, más visitas y nuevamente más potenciales clientes y compras. Y en caso de que no estemos desarrollando una aplicación accesible desde internet sino una aplicación para una empresa o administración publica hacer que cargue más rápido puede suponer una mayor satisfacción de los usuarios y una aplicación más eficiente (con una menor carga para el servidor, con la posibilidad de soportar más usuarios o con menor necesidad de hardware).
La velocidad de carga de una página se ve afectada por varios elementos entre ellos el número de peticiones que hace la página para recuperar los recursos (imáges, css, fuentes, javascript) y el peso de esos archivos. Cuantas menos peticiones hagamos y menos peso de los archivos notaremos una significativa reducción de tiempo de carga de la aplicación. El tamaño de los archivos no afecta tanto a dispositivos que acceden por líneas de banda ancha de varios megas pero hay muchos dispositivos móviles como los teléfonos inteligentes que hace uso de conexiones de datos móviles, las velocidades son más modestas en estos y muchos usuarios tienen cuotas de megas descargados, es de agradecer tenerlos en cuenta también.
En esta entrada usaré el Ejemplo de la lista de tareas con Marionette, un ejemplo sencillo pero bastante completo que usa RequireJS, Backbone y Marionette, jQuery, Mustache, el plugin i18n de RequireJS para internacionalizar los textos de las plantillas, el plugin text para externalizar del html las plantillas de Mustache. Me centraré en como optimizar toda esa cantidad importante de código javascript que necesita el ejemplo cargar en el navegador del usuario. El estado inicial de la aplicación es de 28 peticiones, un peso de 737 KiB utilizando las versiones no minimizadas de las librerías javascript y un tiempo de carga de 261 ms funcionando en local, si tomásemos medidas de tiempo pero funcionando en internet la latencia haría que el tiempo de carga fuese aún mayor. En la imagen se puden apreciar estos datos en la parte inferior de las herramientas para desarrolladores de Chrome.
Para minimizar los archivos de javascript y reducir su peso y también para agregarlos en unos solo que evite muchas peticiones usaré el optimizador de RequireJS (r.js). Esta utilidad ya la que expliqué en la Optimización de módulos RequireJS y archivos javascript del ejemplo más sencillo de la Introducción a Backbone pero ahora lo aplicaré con este ejemplo de Marionette que es bastante más complejo.
Para usar r.js necesitaremos instalar previamente node.js (pacman -S nodejs en Arch Linux). Después deberemos crear el archivo de configuración para r.js, en el que básicamente indicamos la localización de los archivos a optimizar (baseUrl), el nombre del módulo de la aplicación (main), el archivo de resultado agregado y minimizado (out) y la misma configuración shim que utilizaríamos en la aplicación (shim).
Ejecutando este archivo build.js con r.js a través de node obtendremos el archivo agregado y minimizado main.min.js que será el único archivo de módulo que necesitará cargar nuestra aplicación:
Para usar este nuevo módulo deberemos cambiar el nombre del archivo de main.min.js a main.js o cambiar el nombre del módulo del archivo generado de main a main-min (al final del archivo generado, en el define) si hacemos esto último deberemos especificar este nuevo módulo en el atributo data-main de la etiqueta script que cargar el archivo require.js (en Index.tml). En el archivo parece que a pesar de optimizarse se siguen generando algunos comentarios si queremos optimizarlo completamente podemos eliminarlos. El resultado es que cargando este módulo optimizado ahora la aplicación hará tan solo 14 peticiones, la mitad de peticiones, necesitará descargar 403 KiB y se cargará en 245 ms. La diferencia de tiempo no es significativa por hacer las pruebas en local, como decía la latencia de internet o el ancho de banda de un móvil probablemente haría que el tiempo fuese bastante mayor.
Finalmente si queremos automatizar este comando con Gradle podemos hacerlo añadiendo lo siguiente en nuestro archivo de construcción:
Optimizar el javascript y los módulos de RequireJS solo es una de las cosas que podemos hacer para optimizar nuestra aplicación, hay otras muchas cosas que podemos hacer como se comentan en los siguientes enlaces, además si es el caso también deberíamos tener en cuenta el SEO:
