Una de las mejores incorporaciones que tuvo Spring Boot en la versión 1.3 fueron las Developer Tools. De entre toda la funcionalidad, lo que me parece mas útil es sin lugar a dudas el automatic restart, que relanza la aplicación en cuanto detecta cambios en un fichero que esta en el classpath y el LiveReload, que en conjunción con un plugin de Chrome detecta cuando ha habido cambios en la aplicación (como un reinicio) y refresca automáticamente la página.

Pues ahora que ya tengo el constructor y construyo un objeto siempre que, al menos es coherente, toca parsear el xml para extraer los datos. En Java, esencialmente hay tres formas de parsear xml, todas dentro de lo que se denomina Java XML Processing API, JAXP: SAX: La API originaria, orientada a eventos. Muy rápida, muy eficiente y muy farragosa. Técnicamente es una API de streaming mediante push, es decir, nosotros arrancamos el procesamiento del documento y la API empieza a funcionar mandándonos eventos conforme va encontrando elementos. DOM: La API orientada a objetos, representa el XML como un árbol en memoria. Muy fácil de acceder, muy tragón de recursos. Técnicamente, se representa el árbol del DOM en memoria y listo, se puede acceder libremente, por ejemplo usando XPath. StAX: A partir del JDK 1.5 se encuentra disponible esta API que es un modelo mixto, se basa en un modelo de streaming (parecido a SAX) pero más sencillo de utilizar y además permite escribir. Técnicamente se define como una API de streming mediante pull, es decir, que somos nosotros los que vamos indicanto los elementos que queremos acceder. Eso sí, al ser de streaming solo permite avanzar en el documento, es decir, no podemos ignorar el elemento 1, tratar el 2 y en función de este retroceder a tratar el 1. En mi caso en particular, y dado que el modelo de “ir hacia delante” se adapta perfectamente al caso de uso (ya que simplemente estoy emparejando), pero tampoco necesito tantísima eficiencia ni tengo ganas de fastidiarme la vida, voy a utilizar StAX.

En la migración del blog a GitHub Pages uno de los objetivos era no perder contenido, por lo que una vez puesta en pie toda la infraestructura, toca migrar los posts (mucho me temo que los comentarios si se van a perder…). Solución: Hacer un pequeño programa en Java (casi que diría script) que realice automáticamente esta conversión, además voy a seguir TDD para “mantenerme en forma”. En un principio lo voy a plantear como una mera conversión de formatos, como formato inicial tengo el que devuelve Wordpress para la exportación: Wordpress Extended RSS y como formato final quiero un archivo en el formato específico de JBake, que no deja de ser Markdown con unas cabeceras (metadata) particulares:

Desde hace ya bastantes años llevo pagando religiosamente todos los años un dominio (aguasnegras.es) y un alojamiento para tener el blog. El blog ha tenido mejores y peores momentos, pero en general me gusta tener un sitio donde poder escribir en un momento dado, y por supuesto compartir con la comunidad (sobre todo en español, es por lo que escribo en este idioma). El asunto es que si nos paramos a pensarlo, el blog tiene bastantes pocos comentarios y sobre todo entradas mías, es decir, es fundamentalmente un medio de solo lectura. Hace ya un tiempo que pienso que tener para ésto un Wordpress con su PHP y su MySQL es bastante asesino y hasta antieconómico (en sentido general, porque el hosting me cuesta cuatro duros al año, tampoco vamos a ser ruinas). Otra cosa que me molesta bastante es tener que andar actualizando Wordpress (cosa lógica y normal) y aunque ya las actualizaciones sean automáticas, pues me molesta.

En este artículo se hace una breve introducción a la generación de logs en Java usando SLF4J y Log4j2, así como un breve repaso de las mejores prácticas relativas. Introducción En Java se da una circunstancia muy extraña, siendo el logging tan importante como es, no hay una buena solución integrada en el framework como tal. Es cierto que existe la Java Logging API o Java Logging Framework, pero fue una adición bastante a posteriori (en concreto, se añadió en el 2002, en la versión 1.4 del JDK). Para cuando esta API salió como parte del JDK ya teníamos un “estándar” de facto, Log4j, que fue creado en el 1999. Mientras tanto, y haciendo honor a aquella vieja tira de XKCD, seguían saliendo frameworks de loggings: logback, commons-logging, slf4j y otros tipos de soluciones a cada cual más exótica. En este artículo se hace un repaso bastante completo de la historia del desaguisado. A verano de 2013, la situación no ha mejorado, tal y como recoge una reciente encuesta de ZeroTurnAround. Si acaso se clarifican dos tendencias: