lunes, 9 de junio de 2008

Rendimiento en transformaciones XSLT

Esta vez voy a referenciar una serie de tres grandiosos posts hechos en el blog "Algo nuevo que hacer..." (http://www.cmaj.es/). Se trata de un blog muy interesante salpimentado con una pizca de tecnología y dos pizcas de liderazgo de equipos de trabajo y motivación.

XSLT en Java: uso de Translets

Si estás -como yo- preocupado por el rendimiento y escalabilidad de las transformaciones XSLT en Java, ya habrás llegado a la conclusión de que la única forma de que el rendimiento y escalabilidad del cruce de un XML con su plantilla XSL sea decente es el uso de "translets", esto es clases precompiladas:

No obstante, sigue este gran artículo dividido en tres entregas, muy interesante por la evolución cronológica que marca y por las sorpresas y tunnings realizados:

El "gato encerrado" descubierto en el tercer post hace que cada vez que reafirme más en esa sentencia que es recurrente en mis posts y conversaciones: si un framework deja dos opciones para hacer lo mismo, en el 50% de los casos se utilizará la incorrecta. Y lo que es peor, Murphy dice que el 100% de esas veces siempre pasa en proyectos más críticos y en sus peores fases. Venga pongámosle nombre a esta ley... ¿qué tal la Ley del Chikilicuatre?

¿Por qué entonces, joder, nos empeñamos todos los arquitectos software en dejar para la posteriidad múltiples opciones de implementación o parametrización cuando rara vez tiene sentido algo distinto de la opción "lógica"? ¿para que los desarrolladores tengan más emoción en sus vidas????

P.D: [OFFTOPIC - Reflexión personal sobre el uso de XSLT]:

La tecnología XSLT es muy interesante desde el punto de vista teórico para independizar la capa de presentación de la tecnología concreta en que se desarrolla el resto de la aplicación. Es decir, en un mundo ideal podemos tener un equipo especializado 100% en XSLT + HTML + Javascript + AJAX, y que ese equipo intervenga tanto en proyectos Java, .NET, Python, RoR, PHP, o lo que sea. Yo mismo he apostado por esa estrategia en el pasado.

Pero esa es la teoría, la realidad dice que muy pocas Compañías pueden permitirse ese grado de equipos/perfiles especializados, más bien generalmente el 95% de tus proyectos son mono-tecnología (Java en mi caso) y en la Organización no existen los perfiles especializados sino genéricos o todoterreno. En ese caso una constante suele ser que el 100% de tus desarrolladores se sienten "javeros" (o lo que toque) y sorprendentemente les da "alergia" cualquier cosa distinta (y en ese saco meto tanto SQL como XSLT, HTML o Javascript)... y ahí tenemos un problema de cojones!.

Conclusión: es mejor dejarse llevar por las fuertes corrientes e implementar la capa de presentación con Struts, JSF o lo que toque. Porque es lo que conocen los técnicos tanto de dentro como de fuera, y cuanto más distinto o especialito seas, más te cuesta sustituir a una persona o ampliar un equipo.

Corolario: el uso de XSLT puede llegar a ser equivalente o superior en cuanto a rendimiento en tiempo de ejecución, pero siempre va a ser muy inferior en cuanto a rendimiento del equipo de trabajo. Al menos en un par de años vista...

No hay comentarios: