Google Chrome Frame: esteroides para Internet Explorer

Una de las dificultades de desarrollar una aplicación Web moderna (HTML5, CSS3, JavaScript 5, SVG, etc.) es conseguir que funcione correctamente y tenga un rendimiento óptimo en los principales navegadores, como se puede apreciar en los resultados de compatibilidad ofrecidos por la web Caniuse para navegadores de escritorio:

Como se podía intuir los principales problemas suelen surgir con Internet Explorer por su falta de cumplimento de los estándares, agravándose la situación conforme bajamos en su número de versión, aunque parece que con la futura versión 10 se acerca a los niveles de compatibilidad y rendimiento ofrecidos por la competencia. En cualquier caso, el número de equipos que utilizan versiones de Internet Explorer (¡incluso IE 6!) es bastante alto por lo que obliga a "casi" tener que realizar un versión independiente de nuestra aplicación para cada una de las versiones de Internet Explorer, con el esfuerzo que esto conlleva.

¿Qué podemos hacemos en estos casos?

Da prioridad a tus librerías en WebLogic

Si vas a desplegar una aplicación con una versión de Spring en Oracle WebLogic Server 10.3.x puedes encontrarte con que el funcionamiento no es el esperado o que obtienes un error al intentar desplegar el WAR del tipo al comentado en https://jira.springsource.org/browse/SEC-1397

En el fichero de log del servidor se puede ver un mensaje de advertencia bastante esclarecedor indicando que se ha detectado una versión anterior de Spring incompatible con algún módulo determinado, en mi caso con Spring Security. Pero, ¿cómo puede ser si mi aplicación funciona correctamente en un entorno local con Tomcat?

Codemotion 2012: conociendo nuevos trucos de magia

Hace unos días tuve la oportunidad de asistir a la codemotion que se celebró en Madrid. Sin duda, una excelente idea juntar en un mismo evento diferentes tipos de tecnologías: Javascript, Microsoft, Agile, Devops, Mobile, Ruby, Cloud, Java, PHP, HTML, .NET, Grooby, Phyton, etc. En estos casos, la diversión está asegurada si eres entusiasta de la tecnologías y te interesa conocer cual es el estado del arte en el desarrollo software, con independencia del lenguaje de programación utilizado.

Hubo siete track simultáneos durante el día que duró el evento. En general me gustaron todos a los que asistí, aunque ya se sabe que elegir siempre es difícil y me quedé con las ganas de haber podido ir a alguno mas. A modo de resumen os pongo las presentaciones a las que fui y las impresiones que me causaron:

Social Coding: GitHub

Hace unos días, revisando el blog de springsource para ver sus últimas novedades me llamó la atención la entrada "Spring Framework moves to GitHub" porque llevaba tiempo escuchando del éxito de GitHub como sistema de alojamiento de proyectos de software y alternativa a otros "Project Hosting" como SourceForge o GoogleCode.

Hasta ese momento reconozco que no había tenido suficiente tiempo y/o curiosidad para probarlo, pero esta noticia me ha animó: algo bueno tiene que haber cuando una referencia como Spring Framework realiza una migración de su repositorio de código a GitHub.

Lo primero que encontramos al ir alojar un proyecto en GitHub es que, como su nombre indica, usa Git como sistema distribuido de control  de versiones, pieza clave en torno a la que gira la "magia" del sitio.

La modernidad en el desarrollo software

El jueves pasado pude asistir al evento Oracle Enterprise Java Developer Day. En general fue bastante interesante, sobre todo las exposiciones que se realizaron en la primera parte, luego las prácticas se hicieron un poco aburridas, quizás influyó que las herramientas presentadas me eran familiares.

Lo que más llamó mi atención fue el comentario de Alfredo Casado (javaHispano), en su exposición sobre "Desarrollo Moderno y Ligero con Java EE 6", sobre el significado de la modernidad en el desarrollo de software: no es sólo utilizar las últimas tecnologías, es hacerlo aprendiendo de los errores del pasado.

Me identifico bastante con esta definición de modernidad y creo que es una buena reflexión. Realizar desarrollos modernos no es sólo utilizar tecnologías vanguardistas, es mucho más, es usarlas con criterio para hacer el proceso mas sencillo, productivo y de calidad, con el objetivo de poder construir aplicaciones más robustas, mantenibles, eficientes e innovadoras.

Control de errores, ¿reinventando la rueda?

Cuando se define la interfaz de un servicio no suele haber demasiada confusión en qué incluir en el mensaje de entrada, parece claro que debe ser la información necesaria para poder realizar la operación, ni más ni menos. En cambio, en el mensaje de salida, se tiende a incluir en algunas ocasiones, además de la propia información de respuesta, estructuras de control de excepciones, con las siguientes consecuencias:

1. La definición del mensaje de respuesta tiene que incluir una estructura de datos adicional para cuando se producen excepciones.
2. Si se usa una estructura genérica para el control de errores, dificulta poder especificar información diferente para cada excepción. Esto no suele tener importancia si lo que se busca es que el sistema cliente se limite a registrar el problema, pero es fundamental si se devuelve información, que aun no siendo habitual, es parte del funcionamiento del servicio.
3. Obliga a documentar el mecanismo de control de excepciones del servicio para que los sistemas cliente lo puedan interpretar.
4. El sistema cliente para usar el servicio tiene que incluir en su código un procesado específico de la estructura de control de excepciones definida.

¿No estamos en estos casos reinventado la rueda? ¿No está definido en la especificación de servicios como realizar el control de excepciones?

Versionado de servicios

En una arquitectura SOA los servicios van evolucionando con el tiempo, lo que afecta a la definición de sus interfaces. Por eso, es de gran utilidad disponer de un procedimiento que permita minimizar el impacto de los cambios en los sistemas que usan los servicios. De esta forma, conseguiremos reducir las situaciones en las que es preciso regenerar los clientes de acceso, facilitando las tareas de mantenimiento y la adopción de los servicios.

Lo primero es comprender bien como se usa un servicio y que implicaciones tiene, porque, a veces, por la el propio lenguaje, se tiende a confundir o no diferenciar entre el propio servicio y las operaciones que lo componen. Es importante tener claro que un sistema sólo consume realmente un servicio si usa al menos una de las operaciones.

En adelante se asumen las siguientes condicionantes para encontrar el procedimiento de versionado más adecuado:

1. Los servicios pueden ser consumidos por sistemas de diversa índole: diferentes equipos de soporte, diferentes calendarios de subidas a producción, diferentes tiempos de desarrollo, diferentes prioridades, etc., lo que dificulta coordinar los cambios en los servicios.
2. Se busca minimizar el número de servicios publicados, de forma que se pueda reducir la complejidad de uso, las tareas de mantenimiento y los recursos de infraestructura.