Actualizado mi Currículum web

El fin de semana pasado actualicé jonasurbano.es con mi experiencia y el proyecto POIWrapper, Excel en Java fácil. Empecé instalando Git en un servidor que me llevó un tiempo hasta que entendí que el directorio del repositorio (Ej. /home/git/repo) no es el mismo que el directorio del sitio web (Ej. /var/www/). En el directorio del repositorio se guarda la información que usa Git para construir los archivos y se puede utilizar un hook para que construya los archivos en el directorio del sitio web.

Hace un año empecé mi pequeño currículum web con Netbeans que es mi IDE preferido para desarrollo web. Pensé que sería difícil volver a montar el entorno pero no me supuso mucha dificultad.

El primer error que me dio el proyecto ocurrió cuando Netbeans no encontró el compilador para LESS así que me descargué less.js-windows y pude escribir código LESS sin problemas que se compiló automáticamente conforme guardaba.

El segundo error ocurrió al lanzar la página web porque no tenía instalado Netbeans Connector, un plugin para Chrome con el que sincronizar Netbeans con el navegador y poder depurar el proyecto.

Fin. Ahora a mantener jonasurbano.es actualizado. El código de la web está en Github para que le echéis un vistazo. Y por último, gracias a @ccastillos quién tomó la mayoría de las fotos.

Anuncios

www.jonasurbano.es, mi Currículum Vítae web

Más allá del formal cúrricúlum vítae para imprimir, quería expresar de una manera más vistosa los proyectos a los que me he dedicado durante algunos años. Además, llevaba tiempo queriendo crearme una presencia en Internet y reunir en una web mis referencias como este blog o el perfil de Twitter donde intento no retuitear sólo tonterías y compartir artículos que me han parecido interesantes. Por fin me puse manos a la obra en mi currículum web.

He vuelto a usar Netbeans, mi IDE preferido para desarrollar aplicaciones web. Comencé a utilizarlo cuando escribí el código para El comentario de oro, hace un par de años. En aquel tiempo Sublime Text estaba on fire y desde entonces es de las primeras herramientas que siempre instalo. Pero no termino de concebir el hecho de tener que instalar un montón de plugins para empezar a escribir código.

Netbeans ahora cuenta con integración para Sass y LESS. Me he decidido por LESS (utilizando less.js-windows) por no instalar Ruby on Rails. Si todavía no os animáis a usar un preprocesador, lo mismo es que no habéis visto el tercer episodio de Frontazo, cuando lo ví me pregunté cómo lo he pospuesto tanto tiempo. Te das cuenta de que un preprocesador nos permite escribir código CSS casi de la misma manera que escribimos código de un lenguaje de programación.

El HTML no lo escribí usando HAML pero me instalé este plugin para ahorrar en teclados con Zen coding. Otra cosa que me ayudó muchísimo fue el plugin Netbeans Connector para Chrome que actualiza automáticamente el navegador y tiene un menú con diferentes resoluciones para probar las media queries. Aunque esta característica se queda muy atrás si se compara con la extensión Ripple o incluso con la nueva característica de Chrome Dev tools Mobile Emulation.

No todo está yendo rodado, algo en lo que me he atrancado han sido las media queries y después de haber leído Responsive Web Design me he convencido completamente de que la estrategia para afrontar un diseño web y móvil es Mobile First desde el punto de vista de la aplicación de Progressive Enhancement. Completamente al revés de como diseñé mi currículum.

Ahora, una de las tantas cosas que me quedan por hacer es preocuparme por el posicionamiento del currículum en la web aprovechando las nuevas características de HTML5.

El destino me empujó a escribir tests de aceptación para código Javascript

El viernes mi colega Jorge comenzó a desarrollar una historia de usuario en la que tenía que reutilizar código Javascript que yo había desarrollado el día anterior para validar y enviar los datos obtenidos de un formulario. Así que dividí ese código en dos archivos JS para que reutilizase uno. Refactoricé y probé -sí, manualmente-.

Al día siguiente continué con otra historia de usuario que me hizo usar el formulario y para mi sorpresa en uno de los casos de uso no validaba el formulario cuando estaba bien relleno. La solución fue tan tonta como añadir un ! para negar una variable. Pero más tonto fue ocasionar el error. Y más tonto sería aún si no lo hubiese encontrado y hubiera acabado en producción.

Mi mosqueo fue tal que por fin me decidí a desarrollar pruebas para el código Javascript. En primer lugar me interesé por QUnit pero tras hacer una búsqueda de una librería Javascript que se pudiese integrar con Maven me decanté por Jasmine. Sé que estoy muy pesado con automatizar, mi justificación es que el otro día leí un tweet que aún resuena en mi cabeza: 

“We haven’t got time to automate this stuff, because we’re too busy dealing with the problems caused by our lack of automation.” —Everyone.

La introducción a Jasmine no me parece muy clara pero el ejemplo que acompaña la librería al descargarla no deja lugar a dudas.

Escribir un test de aceptación es muy sencillo pero sobre todo es muy reconfortante leer los tests descritos con esa nomenclatura tan entendible y llena de significado que indica que detrás hay código escrito, código importante y cuya razón de ser está justificada.

Para facilitar la escritura de las pruebas de aceptación sobre objetos jQuery se ha desarrollado una librería jasmine-jquery de matchers, que son las funciones que verifican el test. Por ejemplo: toBeVisible() determina si un objeto jQuery ocupa espacio en el documento.

Si se desea verificar cómo el código Javascript ha manipulado el DOM de un archivo HTML (o JSP como es mi caso) hay que cargarlo con la función loadFixture(). El archivo se busca en spec/javascripts/fixtures por defecto, pero se modifica fácilmente. La carga de esta página se hace con AJAX así que hay que tener cuidado con Chrome y su política de Cross Origin.

Todavía me queda mucho que aprender de Jasmine. Por ejemplo, aún no he conseguido saber si un elemento está oculto. La función toBeHidden() no se me comporta como debiera.

Para terminar, decir que el fin parece justificar los medios, porque mientras escribía las pruebas de aceptación acabé refactorizando -cosa que es normal- y corrigiendo el código que se suponía que estaba bien escrito pero no probado… Y la realidad era bien distinta.

 
No volváis a hacer commit sin la seguridad de que nada ha dejado de funcionar.