HTML 4 va a cumplir 10 años en unos meses, y su sustituto va cobrando forma. El desarrollo web es una parte fundamental para nosotros, tanto en forma de aplicaciones de gestión como en distribución de contenidos en sites públicos, por lo que dar un repaso a lo que es y va a ser es una tarea de obligado cumplimiento.

Hay decenas de blogs que ya han escrito acerca de las novedades de HTML 5, así que no es necesario que entremos en ellas en detalle:

• Nuevos elementos para estructurar el contenido de las páginas web: section, article, dialog, aside... Se nota la influencia de los blogs.
• Estandarización de las etiquetas para contenido multimedia interactivo: canvas, video y audio.
• Soporte para páginas web offline.

La importancia de esta nueva versión del estándar es tal que muchos navegadores se apresuran a implementar sus características, incluso antes de alcanzar la versión definitiva del mismo. Firefox, Chrome, Safari, Opera... incluso parece que Internet Explorer 8 va a tener un "fuerte" soporte (sic). En la Wikipedia tenemos una interesante referencia del grado de implementación de HTML 5 en los diferentes motores (no olvidemos que Chrome, Safari y Android comparten motor). La implantación comienza a ser tal que ya podemos disfrutar, por ejemplo, de soporte offline en GMail en Android e iPhone, algo fundamental al hablar de tecnologías de movilidad.

Para comenzar a familiarizarnos con el estándar hemos preparado un par de páginas que utilizan parte de los nuevos elementos de HTML 5, puedes probar cuánto de funciona en tu navegador. Las de entrada y prueba de componentes son páginas terriblemente sencillas, lo cual hace que se vean razonablemente bien en cualquier navegador, aunque no se aproveche la semántica de las etiquetas. Por ejemplo, es de esperar que los elementos marcados con mark sean destacados al usuario de alguna manera, pero por ahora ni Chrome ni Firefox lo hacen. De todas formas, no debemos olvidar que HTML 5 busca separar mejor estructura/significado de apariencia, aspecto que delega en CSS, por lo que si lo que queremos es investigar las líneas futuras del diseño web debemos ir viendo CSS 3. Mediante estos nuevos elementos vamos a poder estructurar semánticamente las páginas, lo cual facilitará, entre otras cosas, la búsqueda e indexación de contenido. Será más fácil distinguir, por ejemplo, el cuerpo de un artículo de las anotaciones al margen y de los comentarios, valorando cada apartado en su justa medida.

Una tercera página de prueba dibuja un tablero de ajedrez en un canvas. El potencial de poder realizar alteraciones gráficas dinámicamente es enorme: mapas más interactivos, gráficas animadas, editores... No voy a expresar lo que me parece que ni siquiera esté en el roadmap para Internet 8, cuando que el estándar ya menciona incluso una versión 3D.

Hemos dejado sin probar las etiquetas multimedia para video y audio, pero puedes probarlo en YouTube con HTML 5, una prueba/empujón al estándar por parte de Google. Es de agradecer que esto se estandarice, pero llega un poco tarde, con Flash erigido como estándar de facto. Personalmente tengo la esperanza de que Microsoft lo apoye y lo incorpore en su navegador, aunque sólo sea para quitar a Adobe algo de la ventaja que tiene con Flash respecto a la alternativa de los de Redmond, Silverlight.

Otra de las características fundamentales, especialmente para los que hacemos aplicaciones que se solapan con lo que tradicionalmente se venía haciendo en el escritorio, es el soporte offline. No hemos hecho una prueba de concepto para ello porque ya hemos trabajado anteriormente con Google Gears, y los resultados son prometedores. El potencial es infinito.

Combina las nuevas etiquetas semánticas y multimedia con interfaces más ricos con Ajax, CSS 3 y canvas, con soporte offline y motores Javascript cada vez más rápidos, y tendrás fantásticas aplicaciones multiplataforma publicadas y distribuidas en red de forma transparente: paquetes ofimáticos completos que no tienes que instalar y que potencian el trabajo remoto en grupo, juegos... El navegador visto como sistema operativo.

Todos los que estamos metidos en esto acabamos las conversaciones respecto a nuevos estándares web topándonos con el mismo muro: Microsoft y su Internet Explorer. Microsoft se dedica principalmente a vender sistemas operativos y aplicaciones de escritorio, y el nuevo paradigma de aplicaciones en la nube no encaja con su modelo de negocio actual. De ahí su nulo interés en hacer evolucionar el gran lastre de la web, su navegador. No es de extrañar que dos de los principales impulsores de este estándar sean Google y Apple. A pesar de ello, cabe la esperanza:

• Firefox continúa ganando cuota de mercado. Acaba de batir su propio record Guiness con la versión 3.5, sin necesidad de tanta publicidad como en la versión anterior.
• El éxito de los "móviles avanzados" (iPhone y Android, esencialmente) deja de hacer a los usuarios tan dependientes de las tecnologías de Microsoft.
• Parece que Microsoft no va a poder meter Internet Explorer en Windows 7, al menos en Europa.
• Internet Explorer, si la 8 no lo remedia, está cada vez más por detrás de los demás en términos de velocidad y funcionalidad.
• Disponemos de Google Gears también para Internet Explorer, así que no tenemos porqué renunciar a una de las piezas clave de HTML 5 ni siquiera en este navegador.
• Para aplicaciones a ejecutar en un entorno específico (usuarios concretos, intranet...) podemos desarrollar para otros navegadores.

Una de los aspectos que en mi opinión son más terriblemente equivocados en la ingeniería del software tradicional es la orientación hacia la calidad del proceso. Hasta la llegada de las metodologías ágiles, todas las metodologías, filosofías, técnicas y certificaciones se centraban, en mayor o menor medida, en la documentación. Todavía hoy veo cómo muchas empresas se dedican a imponer restricciones que conducen a entregar cientos (literalmente) de folios para especificar un trabajo que no lo requieren. Veo proyectos que se documentan durante más de un año para una construcción que un equipo pequeño es capaz de hacer en tres o cuatro meses. ¿Qué sentido tiene eso?

Esto es lo que se dice en el punto 1.2 del manifiesto ágil: "Valorar más el software que funciona que la documentación exhaustiva", y creo que es la tendencia adecuada. El software lo hacen las personas, no las máquinas, así que aplicar métodos industriales no es correcto. Por ejemplo, los muestreos aleatorios en las líneas de producción pueden detectar bastante bien problemas en la producción, pero no en el código: es frecuente encontrar errores aislados con consecuencias catastróficas; no todas las partes del código tienen el mismo peso; no todo el código es producido por la misma persona...

La técnica que aplicamos en CexC para mejorar la calidad del producto es la Integración Contínua. Obviaré la descripción y ventajas habituales, centrándome en nuestra experiencia con Hudson, nuestro motor de integración contínua, y otras herramientas relacionadas.

Valor añadido adicional: aprendizaje

El CexC está en un entorno universitario, formando parte de la UVa, y el aprendizaje es fundamental. Este aspecto, habitualmente obviado al hablar de herramientas de calidad, para nosotros es fundamental. Mediante herramientas de análisis estático de código como FindBugs o PMD, integradas en el entorno de desarrollo, el programador va dándose cuenta cada vez de más formas de mejorar el código. Aprende, por ejemplo, que debe declarar las referencias como final si no las va a modificar. Revisar los informes agregados en Hudson permite ver qué partes del código se deben revisar, qué está mejor, cómo estamos evolucionando...

El coste son los tests

Es innegable que el uso de una herramienta adicional tiene que dar algo más de trabajo. En el caso de la integración contínua el añadido es mínimo, ya que no deja de ser una agregación y automatización. A poco de soltura que tengas con Ant (lo siento, no me gusta Maven), en un par de días, tras ajustar el script de compilación y un poco los de configuración de algunas herramientas, tienes Hudson funcionando a pleno rendimiento, y crear nuevos proyectos a partir de otros existentes es cosa de, literalmente, un minuto.

Las herramientas de calidad de código imponen buenas costumbres, buenas prácticas, así que una vez se convierten en hábito no suponen un problema. Las gráficas de Checkstyle, CPD, FindBugs y PMD crecerán de un modo moderado a lo largo de la vida del proyecto, y ya está. En el gráfico anterior podemos ver cómo sí hubo que realizar un serio correctivo respecto a PMD, lo cual sí implicó un esfuerzo extra, pero no es una consecuencia de la herramienta, sino de una relajación en la calidad del trabajo (y esta es una de las ventajas de tener una web que integre todo: la visibilidad).

Sin embargo, en metodologías ágiles sí que cobra una mayor importancia algo que sí es costoso: las pruebas. Programar pruebas, mal que me pese, no es trivial. Incluso pruebas esencialmente elementales, para probar el correcto funcionamiento de páginas de CRUDs son costosas. No por el código en sí, sino por el estado de la base de datos.

Verificar que un algoritmo para un conjunto de entradas da los resultados correctos es muy potente y fácil. Sin embargo, probar consultas, por ejemplo no. ¿Cómo pruebas que una consulta a base de datos da los resultados esperados y sólo esos? Es muy difícil hacer -en un tiempo razonable- una prueba unitaria de esto.

Al final en general lo que acaba ocurriendo es que no se hacen demasiadas pruebas, pero, si hablamos de aplicaciones de gestión, tampoco es tan grave. Realmente no aporta demasiado esforzarse en hacer pruebas que anden insertando y borrando en base de datos, ya que eso no es nuestro código, es sólo la infraestructura.

¿Cuándo hacemos pruebas, entonces?

1. Cuando se nos reporta un fallo: desarrollamos el código que reproduce el fallo. De esta forma mejoramos el flujo de trabajo: prueba que reproduce el fallo (¡automatizadamente!) - corregir - lanzar prueba - no funciona, corregir - lanzar prueba - correcto - cerrar incidencia documentando la prueba desarrollada.
2. Cuando el código de gestión no es trivial: al realizar cálculos complejos, al aplicar algoritmos importantes para el negocio...
3. Verificaciones de seguridad: no son costosas de realizar, y el valor añadido que proporcionan es importante.

Cualquiera que haya trabajado desarrollando aplicaciones es consciente de que la Ingeniería del Software tiene un gran componente de artesanía y, como tal, las herramientas son fundamentales.

En el Centro Experimental del Conocimiento hemos diseñado el entorno de desarrollo teniendo esto en mente. Al escoger las herramientas y la forma de trabajar con ellas nos planteamos los siguientes objetivos:

• Estandarizar las herramientas lo máximo posible...
• ... pero siendo pragmáticos: la mejor herramienta para cada caso.
• Escoger un conjunto de herramientas lo más integrado posible.
• Maximizar la cobertura del trabajo a realizar: buscamos el conjunto mínimo de herramientas que cubría la mayor parte del trabajo a realizar, desde la planificación de los proyectos hasta la integración.
• Soporte para las técnicas ágiles de desarrollo de software en las que se basa nuestra metodología.
• Minimizar el trabajo de gestión a los desarrolladores, permitiéndoles centrarse en su trabajo.

Los dos primeros objetivos surgen temprano en las primeras reuniones. Tenemos muchas líneas de trabajo diferentes, con dispares tecnologías (J2EE para aplicaciones de gestión, .NET para Sistemas de Información Geográfica, PHP para publicación de contenido web, SOA...). ¿Debíamos estandarizar totalmente las herramientas? Claramente se determinó que no. El choque entre Java y .NET fue el determinante. Tanto uno como otro tienen entornos de desarrollo contrastados, estables, muy productivos. No tiene sentido imponerse una limitación tal como tener que usar herramientas de Microsoft para Java, o viceversa.

Esto conlleva un efecto colateral: las herramientas que se integran bien con Eclipse no tienen porqué integrarse con Visual Studio. Por tanto, renunciamos a estandarizar no sólo el entorno de desarrollo sino también otras cosas, como la gestión de proyectos. ¿Supone esto un problema? Para nada.

Determinado esto, mi trabajo fue seleccionar las herramientas para el desarrollo con J2EE, de las que paso a contar la experiencia hasta la fecha.

Eclipse

 Es un entorno de trabajo contrastado, potente y flexible gracias a los plugins. Lo usamos satisfactoriamente gracias a esto incluso para proyectos sobre PHP.

JBoss Tools

 Es un conjunto de plugins para facilitar el trabajo con las tecnologías de JBoss, compañía de la que somos partners. Facilita trabajar con Seam (en nuestra opinión, el mejor framework J2EE en el momento), con el servidor de aplicaciones, con el Enterprise Server Bus... Implementa la creación de CRUDs de entidades tanto de forma directa, generando desde cero la entidad y las páginas de alta, edición y consulta, como inversa, tomando una tabla existente y generando con ella el código Java de entidades y control y las páginas JSF. Una de las grandes ventajas de usar Seam es este conjunto de plugins. En SpringSource se han dado cuenta de ello y hace unos meses publicaron también su propia versión de Eclipse y servidores de aplicaciones, pero en mi opinión JBoss está ya mejor posicionado para ello.

No hemos tenido un solo problema serio con JBoss Tools, y el valor que nos proporciona no tiene precio.

Trac

 Utilizamos Scrum como metodología de desarrollo, y Trac con unos cuantos plugins (Timing and Estimation, notablemente) nos permite gestionar el sprint backlog. Lo que es más, mediante Mylyn, el sistema de trabajo orientado a tareas que tiene Eclipse integrado, se conecta con Trac, permitiendo que un desarrollador gestione su trabajo (asignaciones, tiempos, requisitos...) directamente desde el IDE, sin tener que recurrir ni siquiera a un navegador web. Además, le proporciona valor añadido con la gestión de contextos.

Si bien todavía no es una solución tan estable y completa como alguna otra alternativa como Jira, su sistema de extensión mediante plugins y su integración con Mylyn le hace ser una alternativa perfectamente viable (y más barata).

Hudson

 Es nuestro sistema de integración contínua. Preferimos centrarnos en la calidad del producto sobre la del proceso, así que ejecutar tareas automatizadas de compilación, análisis estático de código, pruebas, etc., nos es muy importante. Si bien exige algo de trabajo inicialmente (especialmente para configurar un buen script Ant), lo que aporta una vez lo has echado a andar es muy interesante. Además, hay plugins para integrar Eclipse con él, y él con el Subversion y el Trac.

 A grandes rasgos, éste es nuestro poquer para el desarrollo. Realmente conseguimos que el desarrollador se pueda centrar en el código, minimizando la carga adicional de comunicación (asignación y finalización de tareas o bugs, por ejemplo), y maximizando la productividad y la calidad, todo ello sin renunciar a la información necesaria para monitorizar el proyecto tanto por dentro (calidad de código) como por fuera (estimaciones, planificación...).