Lycka Bonita

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.

Mientras escribo estas líneas mi boca aún está enviando señales a mi cerebro indicando la sensación de total deleite que resuena en estéreo a lo largo de toda mi cavidad bucal. Supongo que será debido a la ensalada que he degustado hace unos escasos minutos, nada especial, sólo lechuga, cebolla, zanahoria, manaza y queso condimentado con vinagre de módena y aceite bueno de Jaén.

Anoche mismo me tomé una ensalada igual, y no me produjo la misma sensación. Será casualidad, pero la diferencia acaso radique en que la lechuga era de mi huerto, al igual que la zanahoria, procedentes de la primera recolección de mi huerto, el 28/11/2011.

Voy a regodearme un poco más en esta sensación cacofónica de placer bucal, vuelvo dentro de unos minutos.

Ya estoy. Sigo igual, pero voy a seguir escribiendo.

Aún no había helado en este magnífico otoño. Las temperaturas han sido suaves pero se mantuvieron constantemente por encima de los 10 grados incluso por las noches hasta finales de noviembre. La siguiente quincena la temperatura se mantenía entre los 5 y los 10 grados por la noche, y la última entre los 0 y los 5 grados. A medio día los días de sol la temperatura casi llegaba a la treintena de grados, pero según progresaba el otoño iban disminuyendo tanto el pico de temperatura como la duración de esta banda.

Ha habido varios días sueltos totalmente nublados y una racha de una semana con niebla a finales de Noviembre, un par de días hasta las 14:00h, pero en general las horas de sol han sido abundantes para la época.

Además el agua ha sido generosa y constante los dos primeros meses, sólo una gran lluvia pero el suelo se ha mantenido siempre húmedo. El último mes ha sido más bien seco.

La primera helada de la temporada ha llegado el 29/11/2011, dejando una vista de Salamanca preciosa con los campos bellamente blancos para presentar una Salamanca apenas perceptible al otro lado del río por la niebla y nubes bajas en la que destacaba la poderosa silueta de la Catedral mientras un tenue Sol luchaba por levantarse. Fría vista, pero cálida sensación de belleza de una manaña de Noviembre digna de inmortalizar. Únicamente ha habido otras dos más durante los dos últimos días del Otoño.

Han prosperado aproximadamente un 60% de lo esperado por lo sembrado, lo que atribuyo a novatada, hormigas, aves, gatos… Nada preocupante, en especial si siembro en semillero.

Las plantas han crecido sustancialmente menos de lo esperado, lo que atribuyo por un lado a la mala calidad del suelo, a que han crecido demasiado juntas, a la orientación norte pero sobre todo al verse entre dos edificios que disminuye significativamente las horas de sol. La razón por la que el huerto está situado ahí es para buscar la protección que ofrecen los edificios, menos viento, menos sol abrasador en verano y más fácil de cubrir con un plástico, pero habrá que replantearlo. Respecto a la proximidad entre semillas, habrá que hacer una segunda plantación con un bancal profundo.

Y de la calidad de lo cosechado, como comento al principio, no me puedo quejar en absoluto.

El Momento de la Verdad es un libro (que puedes previsualizar en la sección de libros de Google, aquí) escrito en 1987 por Jan Carlzon. Relata el cambio de paradigma que aplicó en 3 compañías mientras él estuvo al frente como presidente de las mismas dentro de un mercado estancado e hipercompetitivo en costes como el aeronáutico de los años 80.

Aunque es un libro sobre calidad y atención al cliente, sus lecciones se pueden extraer y extrapolar a cualquier ámbito.

3 compañías, 3 problemas diferentes, 3 enfoques diferentes.

Estudiar las necesidades en cada caso. No hay soluciones universales, no hay balas de plata, no hay buenas o malas decisiones, sino las decisiones adecuadas a cada necesidad.

Los empleados son un activo fundamental de la compañía. Por tanto tener a los empleados motivados y mantenerlos así resulta vital para que marquen la diferencia.

Para conseguir motivarlos Carlzon recomienda comunicar internamente el nuevo paradigma (visión) de la organización y delegar responsabilidades para que cada empleado opere ajustándose al nuevo paradigma

“Queríamos que todo el mundo en la compañía entendiera el objetivo”.

En este caso el paradigma es satisfacer al cliente, así que la plantilla tenía autoridad para decir “sí” para satisfacer las necesidades del cliente, pero debía pedir permiso para decir que “no”. ¿Funcionaría este enfoque en España?

Para mantener a los empleados motivados resulta vital el desempeño de los responsables.

Para mantener a los empleados comprometidos con la visión de la organización resulta vital el desempeño de los líderes.

El principal objetivo es consguir clientes satisfechos, comunicando efectivamente al mercado la nueva visión y cumpliendo sus expectativas.

Objetivo claro

Todas las acciones de Carlzon se guiaban bajo un único objetivo: que su compañía consiguiese marcar la diferencia con respecto a su compentencia.

You practically need to mentally turn the organization upside down to become a customer-driven service company. When I was at SAS, we said: “We used to fly airplanes – now we fly people.” [1]

Tienes que cambiar la mentalidad de la organización prácticamente de arriba a abajo para convertirte en una compañía de servicios orientada al cliente. Cuando yo estaba en SAS decíamos que “nosotros solíamos hacer volar aeroplanos; ahora hacemos volar a personas”.

1 nuevo enfoque : Momentos de la Verdad

El cambio de paradigma fue considerar a sus clientes satisfechos como los verdaderos y más importantes activos de su compañía, y por tanto cada contacto entre un cliente y cualquier parte de la compañía era un Momento de la Verdad. Estos momentos son los que determinan si una organización tendrá éxito o fracasará.

Anytime a customer comes into contact with any aspect of your business – whether with staff at the front line or however remote – is an opportunity to form an impression. [1]

Cualquier ocasión en que un cliente entra en contacto con cualquier aspecto de tu negocio [...] es una oportunidad para formar una impresión.

De ahí la importancia de los empleados, especialmente los que tienen trato directo con el cliente. Esta “primera línea” de contacto con el cliente disponía de libertad de acción y decisión sobre los burocráticos procedimientos para conseguir satisfacer al cliente en los escasos 15 segundos de media que duran estos momentos. Sí se producían errores, pero :

Los errores pueden ser corregidos generalmente más adelante; el tiempo que se pierde no tomando una decisión nunca puede recuperarse.

(y yo que creía que la agilidad la “descubrieron” ayer dos “gurús” del software, españoles)

Jefe / Responsable / Líder

Es un concepto que tengo claro antes de mi primera lectura de este libro, hará casi una década. Un jefe no tiene que tomar todas las decisiones o producir o saber hacer el trabajo de sus subordinados mejor que sus subordinados.

Un responsable tiene que crear la atmósfera para que el equipo funcione mejor.

Un líder comunica su visión y guía a su equipo.

Algo que ya hacía Sócrates hacía miles de años.

Referencias

[1] Extraído de esta entrevista a Jan Carlzon.

Decía Wiston Churchill que la democracia es el peor sistema de gobierno a excepción de todos los inventados hasta la fecha.

Algo así pasaba con las metodologías tradicionales en cascada hace unos años, algo así pasa ahora con las metodologías ágiles aceptadas en la actualidad, y algo así pasará con las nuevas metodologías que nos sorprenderán este año.

Y con cada cambio de metodología, nos toca aprender. En España suele ser “aprender”, pero por lo que Dilbert nos cuenta pasa es algo universal:

Vamos a probar algo llamado Programación Ágil.

Significa que no vamos a planificar más, y no más documentación. Simplmente empezad a escribir código y a quejaros.

Me alegra que eso tenga un nombre.

Eso ha sido vuestra formación.

No tengo ninguna duda que las metodologías ágiles sí representan una sustancial mejora respecto a sus predecesoras, no en vano estos últimos años han desaparecido de la primera línea los últimos dinosaurios del software (Sun, IBM, ASF) y ha aparecido un gran nuevo actor (Oracle). Está siendo sin duda una década de cambios, todo fluye y nada permanece que diría Heráclito.

Hoy no me imagino enfrentarme a ningún proyecto sin un enfoque ágil y en la importancia de la integración continua sino como objetivo sí como guía, pero en mi modesta opinión le añado una vuelta de tuerca antes de comenzar a enfrentarse a un problema: el poder de las katas, para iniciarse / dominar en las tecnologías y arquitecturas a emplear.

Pero guardaros de los jefes-pelos-punta (o clientes / comerciales / compañeros) que se leen un libro y repiten como en una misa los nuevos nombres molones sin entender lo que dicen, guardaros de esos falsos mesías e ídolos.

Y recordad la lección de Wally, en realidad no es nada nuevo, sólo distinto perro con el mismo collar: únicamente se ha cambiado el énfasis, pero el que hacía buen software ayer es casi seguro que lo seguirá haciendo hoy y mañana.

Pincha en la imagen para verla ampliada. Oringinal en la tira de xkcd, GOTO.

Podría reestructurar el flujo del programa, o podría usar un pequeño “GOTO”…

Bah, que le den a las buenas prácticas. Qué mal puede hacer? goto main_sub2; *COMPILE*

Yo empecé a programar a los 10 años, así que he sufrido el BASIC, sus líneas de código numeradas… pero sobre todo los GOTOs en programas monolíticos de miles de líneas… así que la modularización, reutilización y control de flujo los tengo muy interiorizados.

Hoy en día espero que ningún lenguaje de alto nivel mantenga algo que únicamente debería existir en lenguajes de bajo nivel (recordáis el ensamblador del Motorola 8Mhz?), así que resulta complicado explicar brevemente a todos los que os habéis iniciado en lenguajes más modernos por qué hay que modularizar, reutilizar y mantener un flujo lineal.

Pero todos los lenguajes de alto nivel modernos tienen lógicamente estructuras de control de flujo, algunas TAN odiosas para mí como break o continue de Java que afortunadamente sólo utilizan una ínfima minoría de “profesionales”, para mí leerlas es como recibir sendas bofetadas y mi opinión de tu profesionalidad me la ahorro.

Cuesta concienciar de por qué no utilizar más de un return por cada método, o por qué evitar salidas inesperadas lanzando excepciones o invocando returns en métodos void… Parece inocuo, al fin y al cabo es algo que puedes ver en los códigos fuentes de casi todos los frameworks, pero qué curioso, los bugs tiene predilección por estos métodos en tu código.

Ójala pudiera invocar al monstruo del GOTO cada vez que tengo que arreglar uno de esos…

MORALEJA

Las buenas prácticas son buenas por algo, porque antes de ti ha habido miles de profesionales que durante décadas se han pelado con tu mismo problema: mantén un flujo lineal, una entrada y una salida en cada método.

No son obligatorias de seguir, pero no seguirlas supone un coste… No te quejes cuando tengas que pagarlo, aunque desgraciadamente suele ser otro el que se encuentra tus muertos bajo la alfombra.