Lycka Bonita

Esta kata es una continuación de la anterior kata sobre GWT. El objetivo es conseguir gestionar el proyecto con Maven para poder utilizar GWT simplemente como framework de vista en nuestros proyectos profesionales, y conseguir gestionar las dependencias entre beans utilizando Spring Framework.

El mayor problema que nos encontraremos con Maven es que la “filosofía” de GWT es muy antigua, Java de finales de los años 90 con notables deficiencias desde un punto de vista actual de desarrollo de software aún en las versiones más recientes (como mezclar código fuente con código generado), en las que los proyectos son GWT o no en lugar de utilizar GWT como un simple framework más que simplemente se utiliza en la vista y el control.

El mayor problema que nos encontraremos en Spring Framework es que GWT crea las instancias de las RPCs asíncronas, que a su vez utilizan componentes creados por Spring (los servicios) y gestionados en su contexto. Ojo, no confundir Spring Framework para gestionar dependencias con Spring MVC para gestionar la capa de control: utilizar Spring MVC para gestionar la capa de control no es el objetivo de esta kata aunque bien podría dar para otra kata diferente y luego compararla con la solución de esta kata.

Para esta kata se propone un orden concreto, primero convertir el proyecto GWT en proyecto Maven y luego introducir Spring, pero bien se podría realizar otra kata más al revés: primero introducir Spring en el proyecto GWT y luego convertirlo a un proyecto Maven. El resultado final debería ser el msimo.

Las versiones recomendadas para la realización de la kata son GWT v2.4, Maven v2.1 y Spring Framework v2.5. Las versiones antiguas de Maven y Spring Framework se deben a necesidades del proyecto para el que necesitaba aprender/enseñar, no creo que haya mayores diferencias con las respectivas versiones v03.xx.

Igual que en la anterior kata, no dudes en contactarme si tienes dudas, sugerencias o mejoras, publicaré mi solución pero te recomiendo encarecidamente que primero resuelvas la kata y luego la consultes, y agradeceré si decides compartir tu solución con nosotros.

Ejercicio 01 – Integración Maven con GWT

Objetivos

• Conseguir que cualquier ejercicio de la kata de GWT (preferiblemente el último) funcione bajo Maven.

Restricciones

• La configuración del proyecto debe ser gestionado por Maven.
  • Las dependencias del proyecto (librerías) se deben gestionar con Maven.
  • El ciclo de vida del proyecto se debe controlar con Maven: limpiar, compilar, ejecutar, depurar y empaquetar.

Ejercicio 02 – Integración Spring con Maven con GWT

Objetivos

• Partiendo del anterior proyecto, utilizar Spring para inyectar las dependencias.

Restricciones

• Las mismas que en el ejercicio anterior.

Kata sobre GWT con 4 ejercicios cortos cuyo objetivo es introducirse en la API de la vista, dominar la arquitectura de comunicación asíncrona y aprender a gestionar sus proyectos.

La versión de GWT recomendada es la v2.4, o al menos versiones v02.xx. Se recomienda utilizar Eclipse como IDE junto con el plugin de GWT para Eclipse que proporciona Google.

Si tienes dudas sobre el enunciado del ejercicio, sus objetivos o restricciones no dudes en contactarme, así como si tienes sugerencias o mejoras. La semana que viene espero publicar mi solución, pero antes de consultarla recomiendo fuertemente trates de hallar tu propia solución. También agradecería que compartieseis vuestras implementaciones.

La estructura del proyecto requerida se muestra en la siguiente imagen:

Se implementará un patrón MVC (Modelo Vista Controlador).

• El Modelo será utilizado por todas las capas del proyecto, no sólo la Vista y el Controlador.

• La Vista se encargará de la implementación de la  Interfaz de Usuario.

• El Controlador se encargará de atender las llamadas procedentes del cliente y despacharlas al método de negocio que le corresponda.

Ejercicio 01 – GWT – Hello World!

Objetivos

• Partiendo de un workspace vacío, debemos crear un proyecto web con GWT que al ser ejecutado nos muestre una página con un botón.

• Al pulsar el botón nos debe aparecer un mensaje con el literal “Hello World!”.

Restricciones

• Utilizaremos GWT para implementar la vista y el controlador
  • En la parte de la vista, crearemos un módulo GWT con un entry point que carga una página que contiene un botón que tiene asociado un manejador de eventos que dispara la ventana emergente con el mensaje recibido del servidor, todos ellos creados por nosotros como clases de nuestra aplicación.
  • En la parte del controlador, utilizar llamadas RPC para conseguir una comunicación asíncrona.

• El controlador invocará un servicio.

• El servicio invocará un DAO.

• El DAO no consultará ninguna estructura de persistencia, sino que devolverá siempre el mismo mensaje esperado, “Hello World!”.

• Utilizar APIs en servicio y persistencia.

• Aunque es suficiente utilizar un objeto java.lang.String para transportar el mensaje, utilizar otro objeto de modelo creado por nosotros (por ejemplo, Message) para encapsularlo.

Ejercicio 02 – GWT – Bye World!

Objetivos

• Partiendo del proyecto resultante de la kata anterior, Hello World!, ampliaremos el proyecto con otro nuevo módulo similar al anterior pero el mensaje que se nos devolverá será “Bye World!”.

Restricciones

• Para el nuevo código seguiremos las mismas restricciones válidas para el Ejercicio 01.

• Toda la nueva implementación debe ser completamente independiente del código anterior, y se empaquetará en paquetes diferentes, cero reutilización (“cero” quiere decir la mínima posible, obviamente sólo puede haber un fichero web.xml…).

• En este punto, el proyecto debería tener dos módulos diferentes y funcionando.

Observaciones

• Si utilizamos la palabra “Adiós”, comprobaremos que el carácter “ó” no lo muestra correctamente. Esto es un problema de internacionalización, pero a priori queda fuera del alcance y podría ser objeto de otra kata.

Ejercicio 03 – GWT – All World!

Objetivos

• Partiendo del proyecto resultante de la kata anterior, Bye World!, refactorizar para llegar a un proyecto con otro nuevo módulo que nos cargue una página con dos botones.

• Un botón devolverá el mensaje “Hello World!” y el otro devolverá el mensaje “Bye World!”.

Restricciones

• Para el nuevo código seguiremos las mismas restricciones válidas para el Ejercicio 01.

• Sólo implementar el código imprescindible, reutilizar cuando sea posible pero sin refactorizar el código existente.

• En este punto deberíamos tener 3 módulos GET diferentes funcionando correctamente con código completamente independiente entre módulos.

Ejercicio 04 – GWT – All World! Reloaded

Objetivos

• Partiendo del proyecto resultante de la kata anterior, All World!, refactorizar para llegar a un proyecto con las mismas tres funcionalidades pero con la máxima reutilización posible.

Restricciones

• Máxima reutilización posible.

Kata es un término japonés hace referencia a una serie de movimientos preestablecidos que pueden ser practicados por una sola persona o en parejas para perfeccionar el dominio de un arte marcial.

Code Kata es un término utilizado en la industria del software para referirse a ejercicios simples para ejercitar y perfeccionar el dominio de algún aspecto técnico. Al igual que las katas de artes marciales, pueden ser ejercicios individuales o en grupos.

A pesar de ser un término recientemente acuñado, estos ejercicios son buenas prácticas que se utilizan desde el principio de los tiempos! Por ejemplo el típico ejercicio de Hola Mundo! que acompaña a casi cualquier tecnología para explicar el uso de la misma.

El gran enemigo del conocimiento no es la ignorancia, sino la ilusión de conocimiento.
Stephen Hawking

Pueden ser utilizadas como ejercicios para aprender una nueva tecnología o mejorar nuestras habilidades de codificación / implementación, como katas sobre algoritmos. Una forma muy buena y muy extendida de aprender diferentes lenguajes de programación es codificar el mismo algoritmo con diferentes lenguajes.

Lo que no se sabe expresar, es que no se sabe.
Friedrich Engels

Cada maestrillo tiene su librillo, pero generalmente una kata son tareas simples que se pueden resolver en alrededor de una hora mediante una serie de pasos que puedas explicar después.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
Antoine de Saint-Expury

Dado que típicamente existe más de una forma de resolver un mismo problema, y que no todas las soluciones que funcionan son aceptables, resulta muy saludable ejercitar sin haber visto la solución de otras personas. Eso sí, después compara tu implementación con la de otras personas y discutid las razones que os han llevado a tomar vuestras decisiones. No se trata de hacerlo mejor que el resto, sino de aprender lo máximo posible en el menor tiempo posible!

Si tú tienes una manzana y yo tengo una manzana y las intercambiamos, entonces ambos aún tendremos una manzana. Pero si tú tienes una idea y yo tengo una idea y las intercambiamos, entonces ambos tendremos dos ideas.
George Bernard Shaw

En el mundo real seguramente no nos encontremos problemas tan sencillos, pero dominando (de verdad) estas tareas simples podemos abordar las más complejas con confianza y eficacia. Por ejemplo, si debes migrar una aplicación que actualmente está utilizando para inyectar dependencias de Spring Framework a Guice, sería una excelente idea hacer una pequeña kata previa para poder estimar el tiempo que llevará la migración, afrontarla con confianza justificada y elegir el enfoque óptimo.

Me lo contaron y lo olvidé; lo vi y lo entendí; lo hice y lo aprendí.
Confucio

En mi opinión, su punto más conflictivo de Kanban es su respuesta ante atascos en la cadena de producción. Kanban propone un límite en el trabajo (WIP, Work In Progress) que puede ser asignado a cada etapa de la cadena de producción. El WIP actúa como un cuello de botella artificial detectando tempranamente atascos en ambos lados de la etapa atascada: los trabajos se acumulan en su entrada, la alimentación de tareas a las etapas posteriores se detiene.

Kanban sugiere corregir esta ineficiente situación parando la producción de la cadena y que cada operario deja de trabajar en su puesto para ayudar a desatascar el problema. Una vez solucionado el problema se vuelve a la normalidad.

Kanban, en la práctica: nuestro problema

Hasta ahora no había tenido la oportunidad de enfrentarme a una situación similar en la vida real, además una situación similar al descrito en la imagen que acompaña esta entrada: no podemos desplegar una versión.

Nuestras circunstancias :

• Somos un equipo distribuido de 5 personas en 2 centros de trabajo a varios cientos de km de distancia.
• Se trata de un proyecto que nos ha sido entregado recientemente para que llevemos su mantenimiento correctivo y evolutivo.
• El proyecto está basado en versiones antiguas de tecnologías en cuya integración no tenemos conocimiento ni experiencia suficiente. Además presenta importantes puntos de mejora en más de un área.
• Una de las primeras cosas que hemos hecho al recibir el control del proyecto ha sido eliminar todo el código de pruebas… qué locura no? nuestras razones teníamos
• Partimos de un punto en el que el proyecto arranca, funciona y ha sido validado por los usuarios en un ambiente de preproducción.
• Nuestro primer objetivo, simplificar. Llevamos una reducción del 75% en el tamaño del WAR, en el tiempo de compilación y arranque, también una importante simplificación de la estructura del proyecto… pero no arranca correctamente.

En estas circunstancias, los desarrollos no pueden ser validados hasta conseguir arrancar el proyecto y comprobar si funcionan. Qué debemos hacer?

• Debemos parar todos los desarrollos y poner a todas las personas a reparar la línea base hasta conseguir desplegar esta versión?
• O debemos seguir cada uno con lo nuestro? Una persona o un equipo arreglando la línea base y el resto continuando con los desarrollos, que se validarán cuando la línea base se arregle?

Kanban, en la práctica: qué hicimos?

La primera semana después de romper la línea base seguimos al pie de la letra la recomendación de Kanban. Paramos la cadena de producción y nos pusimos todos a intentar que el proyecto arrancase nuevamente. 5 pollos sin cabeza, cero resultados, cero avance.

A la semana optamos por la segunda solución. Nos dividimos el trabajo.

Un centro se dedicaba a aprender e investigar sobre las versiones más modernas de las tecnologías y su integración, para después preparar la formación al otro centro y acometer la migración del proyecto a las nuevas versiones (arreglando la línea base en el camino).

El otro centro se dedicaba a sustituir partes de la arquitectura. Es decir queda fuera de la cadena de producción de código, pasando a trabajar en otra cadenas de montaje independiente (arquitectura). Cuando arreglemos el problema volverán a nuestra cadena para desarrollar pruebas desde cero.

Fallo de Kanban? Fallo en nuestra aplicación de Kanban? Nuestra respuesta es un atajo?

Creo que no, no y no. Creo que es un fallo en la gestión del proyecto, nunca debimos ir tan lejos sin conocimientos más avanzados en las tecnologías involucradas. Si hubiésemos abordado en primer lugar la (auto)formación no nos hubiésemos encontrado en esta situación que nos ha hecho perder al menos una semana de trabajo de 4 personas. Con la segunda solución retrasamos la salida de esta incómoda situación, pero al menos no desperdiciamos trabajo.

Siempre he odiado involucrarme en la capa de vista de una aplicación por las deficiencias de sus lenguajes y la falta de opciones. HTML, JSP, JavaScript, CSS son las monturas de los jinetes del apocalipsis. Desde mi más tierna edad profesional me preguntaba…

Por qué no utilizar Java para la capa de vista?

Bendita solución.

GWT nació en 2006 de la necesidad de Google en proporcionar a sus usuarios interfaces ricas, claras, ligeras, intuitivas y sobre todo dinámicas. Dado que ninguna herramienta externa o lenguaje cubría sus necesidades, decidieron desarrollar su propia solución, que posteriormente convirtieron en código abierto, generando JavaScript a partir de código Java y solucionando problemas comunes como la internacionalización, la comunicación asíncrona, el histórico de navegación y la compatibilidad entre navegadores.

Y lo consiguieron, los resultados desde el punto de vista de usuario son muy buenos y el desarrollador se abstrae completamente de AJAX y JavaScript.

Monstruo avernal.

Sin embargo GWT no se imponía en el mercado, no se convertía en estándar, el número de proyectos y profesionales GWT no despegaba e incluso recientemente ha empezado a decaer.

¿Por qué? Yo no entendía la razón… hasta que he tenido que involucrarme profesionalmente. Quizás las lagunas que le encuentro a estas versiones de GWT sean debidas a mi desconocimiento de la propia tecnología y a mi escasa experiencia de un par de meses, lo que en el mejor de los casos sitúa a GWT como una tecnología con una curva de aprendizaje poco suave debida a su buena pero escasa documentación oficial, su gran número de rígidas convenciones (no documentadas) y sobre todo al enfoque erróneo en sus orígenes de aspirar a gestionar el proyecto en lugar de ser una simple herramienta más que se utiliza únicamente en la vista y en el controlador para las llamadas asíncronas.

Colaboración, intercambio y estandarizar: se debió crear una fundación sin ánimo de lucro y dotarla de fondos o colaborar con las existentes, para encontrar una solución común para resolver un problema común ajeno a sus negocios. Sin embargo Google buscó una ventaja competitiva sobre su competencia haciendo algo que no pertenece a su core de negocio, pan para hoy…

Las versiones v01.xx son muy “noventeras” : rígidas (pensadas para las necesidades de Google), implementa supuestamente el patrón MVP (a mí me parece una arquitectura de dos capas cliente-servidor), mini-manuales, sota caballo y rey, tu proyecto pasa a ser un proyecto GWT, el desarrollo será rápido pero cogido con chinchetas (si funciona no toques, por qué tocas?), el mantenimiento será infernal y las migraciones eternas. Salvando las distancias, recuerdan a Alfresco.

Las versiones v02.xx han mejorado enormemente : existe un plugin de Google para Eclipse, un plugin para Maven con el que colaboran Codehaus, Sonatype y Google, se creó GIN (Gwt Injection) para inyectar dependencias, es más flexibilidad, existe más documentación.

Sin embargo aún debe avanzar hacia una hipotética versión v03.xx más simple, más documentada, con menos convenciones para reconvertirlas en configuraciones, una simple herramienta del proyecto en lugar de ser el centro del proyecto, lo que facilitaría su integración para gestionar la Vista con otras herramientas MVC como Struts, Spring MVC o las que aparezcan en un futuro.

Ángel o demonio?

Depende de cómo lo utilices.

Si te estás planteando utilizar GWT para tu nuevo desarrollo, o migrar tu actual proyecto a GWT, no creo que sea una mala idea, pero antes de hacer nada profundiza, aprende, practica con una pequeña kata y sé consciente del riesgo que estás introduciendo en tu proyecto y de que la curva de aprendizaje será mayor de lo esperado.