Spring Roo y su mala evolución.

Fue hace un año, cuando para un pequeño desarrollo que tenía que realizar en el trabajo decidí probar suerte con STS y Spring Roo.

En aquel momento necesitábamos desarrollar un pequeño aplicativo web para mantener datos de configuración del sistema, al que pudiésemos incorporar algún proceso de importación y exportación de datos.

De entrada la cosa me gustó, dado que permitía generar mantenimientos CRUD muy rápidamente, aunque luego entender el código generado y cómo poder modificarlo para adaptarlo a tus necesidades requería de un poco de tiempo.

Y aunque tuve algún problema y comportamiento extraño, la cosa salió y mi impresión fue la de estar ante un producto muy útil pero aún por evolucionar para resultar del todo útil.

Esta semana a petición de un amigo he querido volver a usarlo para desarrollar unos mantenimientos de datos muy sencillos, aunque debo admitir que la evolución de un año hacia aquí me está generando una tremenda desilusión y frutración.

El IDE, STS, ha mejorado y ahora monta por debajo Eclipse Juno, pero por desgracia se ha vuelto realmente torpe y lento, hasta el punto de que ponerlo en marcha a veces falla sin explicación, dejándote en la ventana de Splash (incluso antes de pedir la ubicación del Workspace) durante varios minutos sin saber qué sucede.

Dentro del workbench es habitual ir a hacer algo y ver cómo se queda congelado sin explicación, o tarda en reconocer cualquier tipo de orden.

La imagen más habitual en los últimos días.

Del ETERNO problema de Eclipse con los proxies poco se puede añadir, STS hereda los mismos problemas y a estas alturas intentar que coja la configuración y el usuario/password del  proxy es un dolor de pelotas enorme.
Parece mentira que un desarrollo como Eclipse, a estas alturas, siga haciendo gala de semejante error, lo que hace que intentar usarlo dentro de una red corporativa (detrás de un proxy) termine siendo un problema más que una solución a una necesidad.

Y Spring Roo, ahora en su versión 1.2.3, ha evolucionado a mucho peor.

No responder ante un comando y no hacer nada, solo quedarse colgado, la imposibilidad de cargar los drivers para MySQL por un bug y tener que buscarte la vida para solucionarlo por los foros de Spring, o terminar con un 'OutOfMemory Error' tras intentar generar el scaffolding de forma automática a un modelo de datos grande no son más que algunos ejemplos de su mal funcionamiento.

En el mundo del desarrollo, cualquier herramienta o framework de trabajo se supone que ha de aportar y ayudarnos a mejorar nuestra productividad a la hora de desarrollar Software.

Sin embargo, en el estado actual Spring Roo y STS son más un foco de problemas, retrasos y una inmensa frutración que los hace totalmente INVALIDOS para un desarrollo en JAVA.

Y me preocupa, porque es Spring (con VMWare) quien está detrás, y el framework de Spring es uno de los más extendidos en el mundo JAVA, así que no quisiera ver cómo lo que hasta ahora era una ayuda pasa a convertirse en un generador de problemas en los desarrollos porque se esté siguiendo una pésima politica de evolución de los productos.

The Art of Software

If there is something I have noticed for years in the programming world is that it is becoming harder and harder to find documentation of Quality.

A few years ago, when someone wanted to start with a new programming language, as soon as he had a bit of interest was more or less easy to find documentation, tutorials, examples and everything a developer could need to take their first steps and then move to create increasingly complex systems.

So I started with PowerBuilder client-server environments, with Pro-C or JAVA, manuals and tutorials based on trying to guide you in the process of software development.


The Evolution.

But as the years pass, the software evolves, it creates new and more powerful development Frameworks, which force you to take more time to master and integrate them into your projects.

You might think that the documentation is also becoming more complex and forces you to spend more time with those first steps, but with the subsequent reward of better applications and shorter development times.

But the truth is not always the case, since the effort spent to create these more complete and complex Development Frameworks have been ahead of the forces for something that is becoming more necessary: DOCUMENT.

Frameworks evolve from projects where documentation and worth you to start and develop your knowledge, to projects where it is customary to find the typical 'Hello World', which is as absurd as useless when what you need is to build large systems.


Objective: Productivity.

AJAX, JSON, HTML 5, MVC, JPA ... All this and even more come to be the day to day in the development of dynamic websites with complex and powerful RIAs, where everything is complicated to change to ensure high productivity.

Or at least it should be, because the sad reality is that finding quality documentation that teaches how to integrate the various technologies of today, how to solve the various problems you may encounter in integration, has become an exercise similar to fishing ... only we have changed our favorite river or lake by Google, and our bait for these keywords to help us discern the solutions of other thousands of developers who also drowned in the same problems as us.

You're lucky if you give your solution in the vast sea of Google results.

And all because the same people who are capable of twisting lines of code to create these frameworks tame and highly productive, suffer from interest, capacity or pedagogical skills necessary to sit in front of a word processor and write a guide explaining something more than the fucking 'Hello World'.

So what should be a high initial effort to become lower development times, ends up being a HUGE effort and frustrating days and weeks to not only think about how to create real applications, but to resolve the thousand and one problems that we we can find to begin to understand how to actually use these tools.


But hey, if we were talking about Open Source projects, carried out by newly graduated kids like writing lines and lines of code, but not to explain what they do, one could even understand it.

But when one has to face Frameworks supported by people who assume serious and resourceful, gifted to do things right, faces the enormous frustration is when I start to ask: But what the hell is going on?

And in this case I mean neither more nor less than Google and its GWT, Spring Roo of SpringSource, which are not small companies.

The Road to Frustration.

Two weeks ago, and in order to decide what technology to use for a small web development work, after being given options and looking eager to develop something with GWT, I came to this page:

Rapid Application Development for the Cloud

Getting started with GWT, Spring Roo, and SpringSource Tool Suite

I read the title, header and starts reading the 'tutorial' and beginning to think I found what I needed.
And to that end I download the development environment for Spring STS, PDF 'Getting Started with Roo', willing to trust these two large companies and devote my time to learn how to create a project with these tools.

For these two weeks can be summarized as: anger, frustration and a sense of wasted time.
The environment is good, Spring Roo is a great idea, great Framework GWT RIA ... but the documentation is pitiful.

Roo's book is outdated, written for version 1.5.5 has been published as version 1.2.0, which could be overlooked if not for the mistakes that you find by following the examples.

Why does it not work? What have I done wrong?

First to be behind a proxy, which somehow made the JDBC drivers are not installed even though the application say that everything had gone well.
Then because you're going to find errors occurred with no one knows exactly where, that force you to waste time on finding solutions to the forums.
No solutions, so we only get to 'solve' with the method 'Delete project' - 'Create New Project'.


And the latter because when you try to create your first application with GWT + Spring Roo, which is supposed to be only 4 lines on the Roo shell to have an application, it becomes a ...

'why the fuck FAILS NOW?'

And a lot of inexplicable errors, when compiling assumed that after all has gone well and should run without problems:

Results after following the steps outlined in the book "Getting Started with Roo '. Here I was about to throw me to mourn.

The Hangover.

And at that point I am, in deciding whether to give one more chance, spend a day or two to find out why the hell fails, or opt for other options easier.

If I were asked right now ...

Do you recommend for use by people in your office?

My answer is a resounding: NO.

They are good products are powerful, you can end up getting high productivity ... but when the dates are short, when the support is not going beyond a one-page tutorial sad or book incomplete and full of errors, or a forum where no one says you're going to get a response ... with the budget in hand should put aside these products until they either get better documentation, or work as expected.

For now I will give one or two days to spare, but if problems persist it is time to give them aside until someone at Google or Spring to realize that as important as making things work, is to that the documentation will be serious and complete.


Deliberation.

I think the conclusion is obvious, as large as Google and Spring fail in something as important as providing a good, complete and updated documentation ... What we are not doing wrong to others?

Maybe it's the rush, the lack of time or simple carelessness, but simply find various tutorials online to find articles where hardly bare delves into the subject.

But does anyone think that Java would become what it is today if it had not delivered SUN complete API with every release? Or if he had not filled his web of examples on how to develop desktop applications with Swing or how to build web applications?

Unfortunately those days seem to have gone forever, leaving time to a time where everything is rushed and more importantly delivering new versions before going to explain it to anyone who wants to use them how.

We're turning the Art of Software, the work of master craftsmen, working in a production line where what matters is not to understand what you do, if you do not learn what button to press at the time.

El Arte del Software.

Si hay algo que desde hace años vengo notando en el mundo de la programación, es que cada vez es más y más difícil encontrar documentación de Calidad.

Hace unos años, cuando uno quería empezar con algún nuevo lenguaje de programación, a poco que tuviese un mínimo de interés era más o menos sencillo encontrar documentación, tutoriales, ejemplos y todo lo que un desarrollador podía necesitar para dar sus primeros pasos para luego pasar a crear sistemas cada vez más complejos.

Así, en su día empecé con PowerBuilder en entornos Cliente-Servidor, con Pro-C o el JAVA con el que llevo desde hace más de 10 años, partiendo de manuales y tutoriales que intentaban guiarte en el proceso del desarrollo de software.


La Evolución.

Pero a medida que pasan los años, el Software evoluciona, se van creando nuevos y más potentes Frameworks de desarrollo, que a su vez te obligan a tomarte más tiempo para dominarlos e integrarlos en tus proyectos.

Uno podría pensar que la documentación también se va volviendo más compleja y te obliga a dedicar más tiempo a esos primeros pasos, pero con la posterior recompensa de obtener mejores aplicaciones o tiempos de desarrollo más cortos.

Pero lo cierto es que no siempre es así, puesto que el esfuerzo dedicado a crear esos más completos y complejos Frameworks de desarrollo se han llevado por delante las fuerzas para algo que cada vez se hace más necesario: DOCUMENTAR.

Pasando de proyectos y Frameworks donde la documentación te valía para empezar y perfeccionar tus conocimientos, a proyectos donde lo habitual es encontramos el típico 'Hola Mundo', que es tan absurdo como inútil cuando de lo que se trata es de construir grandes sistemas.


Objetivo: Productividad.

AJAX, JSON, HTML5, MVC, JPA... todo esto e incluso más vienen a ser el día a día en el desarrollo de Webs Dinámicas, con RIAs complejas y potentes, donde todo se ha complicado a cambio de asegurarnos una alta productividad.

O al menos así debería ser, porque la triste realidad es que encontrar documentación de calidad que enseñe cómo integrar las distintas tecnologías de hoy, cómo resolver los problemas diversos que uno puede encontrarse en esa integración, se ha convertido en un ejercicio similar a la pesca... solo que hemos cambiado nuestro río o lago favorito por Google, y nuestro cebo por esas palabras clave que nos han de ayudar a discenir las soluciones del resto de miles de desarrolladores que también se ahogan en los mismos problemas que nosotros.

Tienes suerte si das con tu solución en el vasto mar de los resultados de Google.

Y todo porque las mismas personas que son capaces de retorcer las líneas de código para domarlas y crear estos frameworks de alta productividad, adolecen de interés, capacidad o las dotes pedagógicas necesarias para sentarse delante de un procesador de textos y escribir una guía que explique algo más que el jodido 'Hola Mundo'.

Así que lo que debería ser un alto esfuerzo inicial para convertirse en bajos tiempos de desarrollo, termina siendo un ENORME Y FRUSTRANTE esfuerzo de días y semanas para no solo pensar en cómo crear aplicaciones de verdad, sino para resolver los mil y un problemas que nos podemos encontrar hasta empezar a entender cómo usar realmente las cosas.


Pero bueno, si estuviésemos hablando de Proyectos Open Source, realizados por chavales recién licenciados con ganas de escribir líneas y líneas de código, pero no de explicar lo que hacen, uno hasta podría entenderlo.

Pero cuando uno se tiene que enfrentar a Frameworks respaldados por gente que se presupone seria y con recursos, dotados para hacer bien las cosas,  se enfrenta a esa ENORME FRUSTRACIÓN, es cuando me empiezo a preguntar: ¿Pero qué coño está pasando?

Y en este caso me refiero a ni más ni menos que a Google y su GWT, y Spring Roo de SpringSource, que no son precisamente poca cosa.

El Camino a la Frustración.

Hace dos semanas y con el objetivo de decidir qué tecnología usar para un pequeño desarrollo web en el trabajo, tras estar buscando posibles opciones y teniendo muchas ganas de desarrollar algo con GWT, llegué hasta esta página:

Rapid Application Development for the Cloud

Getting started with GWT, Spring Roo, and SpringSource Tool Suite

Uno lee el título, el encabezado y comienza a leer el 'tutorial', y empieza a pensar que ha encontrado lo que necesitaba.
Y con ese objetivo me descargo el entorno de desarrollo de Spring STS, el pdf 'Getting Started with Roo', dispuesto a confiar en estas 2 grandes empresas y dedicar mi tiempo a saber cómo crear un proyecto con estas herramientas.

Pues estas dos semanas se pueden resumir en: rabia, una gran frustración y sensación de tiempo perdido.
El entorno es bueno, Spring Roo es una gran idea, GWT un gran Framework para RIA... pero, la documentación ES PENOSA.

El libro de Roo está desactualizado, escrito para la versión 1.5.5 cuando ya se ha publicado la versión 1.2.0, algo que se podría pasar por alto si no fuese por los errores que te encuentras al seguir los ejemplos.

¿Y por qué a mi no me funciona? ¿Qué he hecho mal?

Primero por estar detrás de un proxy, lo que por algún motivo hacía que los drivers para la conexión JDBC no se instalasen aunque la aplicación dijese que todo había ido bien.
Luego porque te vas encontrando con errores surgidos no se sabe muy bien de dónde, que te obligan a perder mucho tiempo en buscar soluciones por los foros.
Soluciones que muchas veces no encuentras y solo consigues 'resolver' por el método de 'borrar proyecto' - 'crear nuevo proyecto'.
 

Y el último porque cuando intentas generar tu primera aplicación con GWT + Spring Roo, lo que se supone que son apenas 4 líneas en la shell de Roo para tener una aplicación, se convierte en un...

'¿Y AHORA POR QUÉ COÑO FALLA?'

Mas un sinfín de errores inexplicables, cuando se supone que tras compilar todo ha ido bien y debería de ejecutarse sin problemas:

Resultado tras seguir los pasos indicados en el libro 'Getting Started with Roo'. Aquí estuve a punto de echarme a llorar.

La Resaca.

Y en ese punto estoy, en el de decidir si darle una oportunidad más, dedicar uno o dos días más a averiguar porqué demonios falla, o decantarme por otras opciones más sencillas.

Si ahora mismo me preguntasen...

¿Lo recomiendas para que lo use la gente a tu cargo?

Mi respuesta sería un rotundo: NO.

No porque no sean buenos productos, no porque no sean potentes, no porque no se pueda terminar obteniendo una alta productividad... si no porque cuando las fechas son cortas, cuando el soporte no va más allá de un triste tutorial de una página o un libro incompleto y lleno de errores, o un foro donde nadie te asegura que vayas a obtener una respuesta... con el presupuesto en la mano debería dejar de lado estos productos hasta que o bien se mejore su documentación, o bien funcionen como se espera de ellos.

De momento voy a darles uno o dos días más de margen, pero si los problemas persisten habrá llegado el momento de darlos de lado hasta que alguien en Google o en Spring se de cuenta de que tan importante como hacer que las cosas funcionen, es hacer que la documentación sera seria y completa.


Reflexión.

Creo que la conclusión es obvia, cuando grandes como Google y Spring fallan en algo tan importante como proporcionar una buena, completa y actualizada documentación... ¿qué no estaremos haciendo mal los demás?

Quizás sean las prisas, la falta de tiempo o simple dejadez, pero basta con buscar por internet distintos tutoriales para encontrar escuetos artículos donde apenas se profundiza en el tema.

Pero, ¿alguien cree que JAVA hubiese llegado a ser lo que es hoy si SUN no hubiese entregado un completo API con cada Release? ¿o si no hubiese llenado su web de ejemplos sobre cómo desarrollar aplicaciones de escritorio con Swing o cómo construir aplicaciones web?

Desafortunadamente esos tiempos parecen haberse ido para siempre, dejando tiempo a un momento en el que todo son prisas y es más importante ir entregando nuevas versiones antes que explicar bien a quien quiera usarlas cómo puede hacerlo.

Estamos convirtiendo el Arte del Software, el trabajo del Maestro Artesano, en el trabajo de una cadena de producción donde lo que importa no es entender qué haces, si no aprender qué botones hay que pulsar en cada momento.