Gabriel Belingueres

Gabriel Belingueres obtuvo recientemente el título de Licenciado en Informática (plan 90). Para finalizar su recorrido académico, desarrolló  una tesis que abordó el uso de conversaciones en el desarrollo de aplicaciones web, en particular las desarrolladas usando el lenguaje Java.

Me sentí atraído por el varias razones. Por un lado, como desarrollo en forma diaria aplicaciones web, siempre veo que hay un conjunto típico de problemas de navegación y bugs que son muy comunes. Por ej. Gestionar el estado de la aplicación cuando el usuario presiona el botón para retroceder en el historial de navegación (back button), o bien cuando se almacena el estado de la aplicación en la sesión de usuario para preservarlos a través de varias peticiones realizadas al servidor web, mantener estados independientes entre distintas pestañas de navegación, entre otros. Hay muchas formas de resolver estos problemas, pero resolverlos usando conversaciones realmente simplifica el código a programar a la vez que mejora la calidad final de la aplicación.

Por otro lado, veo que este concepto de conversaciones ya vienen implementados de forma nativa por varios frameworks de desarrollo de aplicaciones web en Java como JBoss Seam o Spring Web Flow (ambos soportados por empresas muy grandes y prestigiosas) con lo cual comencé a interiorizarme del tema y me di cuenta que estaba ante una abstracción muy poderosa, y por lo tanto valía la pena dedicar tiempo y esfuerzo a ese tema.

Por último, en mi ámbito laboral se utiliza principalmente el framework Struts 2 para desarrollar la mayoría de nuestras aplicaciones. Struts 2 es uno de los frameworks más utilizados del mundo, pero no tiene soporte nativo de conversaciones, de ahí mi interés en hacer mi aporte con una implementación de calidad, a fin de poder utilizarla yo mismo en el día a día!

¿Cuál es la importancia de implementar un soporte de conversaciones para Struts 2?

Struts 2 es un Framework de desarrollo de aplicaciones web muy utilizado, esto significa que hay una cantidad significativa de programadores alrededor del mundo con experiencia en su uso. Es una herramienta open source, con una comunidad de usuarios muy grande y activa.

Struts 2 no posee soporte nativo de conversaciones, pero es un framework muy flexible diseñado de manera que sea muy sencillo (o al menos posible) extender su funcionamiento con muchos tipos de funcionalidades, entre ellas por supuesto, agregar soporte de conversaciones en aplicaciones web.

Si tomamos la misma funcionalidad de una aplicación Web y la implementamos de dos formas distintas: una utilizando conversaciones y otra SIN utilizar conversaciones, lo que veremos en el primer caso es que el código fuente será más sencillo de escribir (y por lo tanto más fácil de leer), debido a que el framework con soporte de conversaciones realiza en forma automática ciertos controles y lógica que de otra manera tendría que pensar y escribir el programador.

Como el soporte de conversaciones está muy bien probado (por ej. utilizando pruebas unitarias), interceptando las peticiones web y realizando ciertas tareas en forma automática, centralizada y controlada en forma declarativa por el programador, entonces se está mejorando la calidad final de la aplicación a la vez que el código fuente de la misma es más sencillo y fácil de escribir (debido a que la complejidad de los controles a realizar fue transferida al Framework y conversaciones), entonces es de esperarse que la productividad del desarrollador tienda a mejorar.

Si además se logra que el código fuente de una aplicación desarrollada con  Struts 2 SIN utilizar conversaciones, sea reutilizable (o fácilmente modificable) para adaptarlo al uso de conversaciones, la curva de aprendizaje para aprovechar esta tecnología sería muy buena en costo-beneficio, entonces estamos ante una abstracción que es muy fácil de integrar a aplicaciones existentes, y, como hay una gran cantidad de programadores con experiencia utilizando Struts 2, potencialmente es posible mejorar la productividad de un número elevado de personas.

¿En qué aspectos creés que ayudaría a mejorar la experiencia  de navegación del usuario?

Creo que al usuario hay que entregarle una aplicación cuya experiencia de navegación sea placentera de usar. La experiencia de navegación no solo está dada por la usabilidad de la misma, en el sentido de que la aplicación sea “fácil” de usar, o “intuitiva” o “amigable”.

La aplicación debe comportarse de forma consistente, estable y robusta en todos los casos, especialmente ante la presencia de errores, tanto por algún recurso de la aplicación que ya no está disponible y genera una condición de error, como por errores que cometa el usuario (estos últimos son los más difíciles de detectar, ya que el usuario no se ha dado cuenta que lo ha cometido, y por lo tanto puede tratarse de una operación legítima, o bien puede ser un hacker). Por ej. Si quiero pagar el resumen de mi tarjeta de crédito utilizando el home banking de mi banco, y al terminar de hacer el pago, presiono el botón F5 del navegador para refrescar el cache? Me vuelve ha realizar el pago? O la aplicación detecta el inconveniente avisándole del mismo?

Qué pasa si presiono el botón de retroceso y vuelvo a realizar el pago? El usuario puede llenar un carrito de compras y realizar el checkout, luego de lo cual presiona el botón de retroceso del navegador para realizar la compra nuevamente: aquí la aplicación es responsable de detectar este caso y notificar al usuario de este nuevo intento.

Las conversaciones facilitan el desarrollo de aplicaciones web, ya que serán capaces de detectar el acceso a cierta funcionalidad que no debería ser ejecutada si la aplicación no se encuentra en cierto estado en particular. Ejemplos:

● Acceso desde una URL de la aplicación en particular (ej. El usuario accede a un link de la aplicación guardado entre los Favoritos del navegador, pero este link tiene sentido solamente en el contexto de que el usuario esté logueado al sistema y haya ejecutado previamente un paso anterior al correspondiente al link que se quiere acceder.)

● El usuario presiona el botón F5, solicitando a la aplicación que realice nuevamente la última operación ejecutada.

● El usuario presiona el botón de retroceso/avance del historial de navegación, solicitando un estado de la aplicación cuyo tiempo de vida ya expiró.

● El usuario hace múltiples envíos del mismo formulario.

● Permite que el usuario pueda ejecutar la misma funcionalidad en distintas ventanas/pestañas del navegador utilizando conjuntos de datos distintos, sin que estos interfieran unos con otros.

 ¿Con qué obstáculos te encontraste en el desarrollo de la tesis?

Obstáculos hubo, y muchos. Los más difíciles desde lo personal fueron hacer un balance entre el trabajo, mi esposa, hijas y la tesis: es difícil dedicarle el tiempo a una cosa sin restarle tiempo a otra.

También creo que influyó el hecho de tener que hacer el trabajo yo solo. Al terminar las cursadas y mudarme fuera de La Plata, se me hacía muy difícil realizar la tesis con algún compañero ya que al insertarse en la vida laboral (y si le añadimos matrimonio e hijos) se va perdiendo el contacto con los antiguos compañeros de facultad, y los tiempos de cada uno y las distancias hay que saber manejarlas para poder organizar el trabajo. Sin embargo, creo que si lo hubiese podido hacer en equipo hubiésemos terminado la tesis en menor tiempo, ya que es más llevadero y el compañero de alguna forma te “obliga” a ponerte las pilas para continuar.

Otro tema que me llevó mucho tiempo definir (probablemente por mi inexperiencia) fue el alcance del trabajo a realizar: qué era importante y que no, qué cosas implementar para que el aporte sea usable en un nivel profesional, pero a su vez que no requiera de 2 años de programación. La línea entre implementar un prototipo o algo de calidad comercial, o bien hacer un informe final más (o menos) extenso y detallado me llevó tiempo encontrarla. Al final salió bien creo jaja.

¿Qué diferencias tiene tu desarrollo en comparación con otros desarrollos predecesores?

Hay varios frameworks de desarrollo de aplicaciones web con soporte de conversaciones. Los más prominentes son JBoss Seam (de la empresa RedHat) y Spring Web Flow (de la empresa VMWare). Ambos son excelentes, y llevan ya varios años de vida, con lo cual demuestran que ha corrido mucho agua bajo el puente y han sobrevivido al test del paso del tiempo.

Más recientemente, Oracle empezó a estandarizar por primera vez el concepto de conversaciones, con el estándar CDI (Context and Dependency Injection), ahora parte de Java EE 6. Esto indica que el concepto está afianzado en la industria y llegó para quedarse.

Al margen que todos los frameworks anteriores gozan del mantenimiento de muchos programadores, con lo cual son de calidad muy superior a la implementación que realicé yo, entiendo que lo que aporté alcanza para un uso “normal” de conversaciones (“normal” en el sentido de que hay muchas funcionalidades o casos de uso que pueden resolverse utilizando el soporte de conversaciones implementado para Struts 2), y de los tres frameworks nombrados anteriormente, creo que estoy más cerca de lo implementado en CDI y JBoss Seam que de Spring Web Flow. Los otros frameworks soportan modelos “extendidos” de conversaciones, que son mucho más potentes pero que también son útiles en situaciones de navegación complejas más particulares.

¿Estás interesado en difundir tu desarrollo?

En principio sí, siempre y cuando el tiempo me lo permita. Se propuso desde un principio “intentar” abrir el código fuente de la implementación, a efectos de que pueda ser utilizado por otros, e incluso extendido y modificado. Estoy intentando hacerme un tiempo para “arreglar” el código fuente como para que tenga un poco más de calidad, o más amigable a cualquier programador (por ej. Modificando los nombres de las variables a inglés)…pero todo eso lleva su tiempo.

 ¿Cuál creés que es su potencialidad?

Utilizar conversaciones agregan una herramienta más al programador para resolver ciertos problemas comunes en las aplicaciones web. Como estos problemas los resuelve el Framework y el uso de las conversaciones, el tiempo del programador se invierte en saber cuándo y cómo usarlas. En general, en una situación donde es conveniente utilizar una conversación para realizar cierta funcionalidad de la aplicación, siempre va a ser más sencilla de implementar, y tendrá más calidad si se implementa usando conversaciones, en vez de utilizar solamente las herramientas que nos brinda el estándar de Servlets.

¿Qué influencia tuvo el desarrollo de la tesina para tu desempeño laboral?

La verdad que me ayudó bastante. Como en mi trabajo utilizamos extensivamente Struts 2, la tesis me ayudó a entender mejor el funcionamiento interno del Framework así como otros aspectos del desarrollo en general, como por ej. lo conveniente del uso de anotaciones en el código fuente para declarar cierto comportamiento deseado. Además, de a poco voy a ir incorporando en mi trabajo el plugin de Struts 2 implementado en esta tesina, ya que (si bien es un prototipo comparado con otros frameworks) es perfectamente usable en aplicaciones reales.