En busca del Grial

La búsqueda

Fue en el mes de febrero pasado cuando descubrí Grails en el Spring 2GX Day, desde entonces he estado trasteando con este framework para desarrollo rápido de aplicaciones web. Yo algo sabía ya de Groovy desde hace un par de años, pero en estos meses me he empapado casi todos los libros de Groovy/Grails que he encontrado (alguno me falta todavía) y además como el que no quiere la cosa, he vuelto a programar "por gusto", cosa que no me ocurria desde que aprendí Spring, y es que ya no programo largo y tendido sino tengo alumnos atendiendo, o como dicen "si no tengo el taxímetro puesto"...

Desarrollo Rápido de Aplicaciones significa que con un numero reducido (reducidísimo) de líneas de código tenemos una gran parte de la funcionalidad de nuestra aplicación desarrollada, puesto que Grails estereotipa la programación de un proyecto web, generalizando los diversos patrones y estrategias de uso común  (MVC, comandos, servicios, DI, plantillas, testing, etc) en una arquitectura en N capas (presentación, negocio, dominio y persistencia)

Los calvarios

Al principio, fui bastante reticente, por dos motivos fundamentalmente:

1. Que el paradigma "Convention over Configuration" me parece peligroso. Peligroso para la gente que aprenda directamente Grails y que no haya trabajado jamás con una aplicación hecha con Spring e Hibernate (los pilares que mueven este framework) y que puede no llegar a entender que pasa tras toda la tramoya generada. Ya que al final, uno termina teniendo que poner algo que no esta implementado por Grails o cambiar algo para cumplir con las especificaciones y si carece del conocimiento de los distintos patrones idiomaticos para trabajar con Spring, Hibernate, etc, pues termina haciendo "código churro".
   
2. Porque había leido varias cosas sobre la penalización del rendimiento que imponen los lenguajes dinamicos y en especial Groovy, pero es cierto, como el propio Graeme Rocher expresó en el SpringGX2Day, que siempre será más barato el hardware que el desarrollo de aplicaciones.

Los dones

he puesto las pegas, ahora vienen las bondades:

1. Como siempre digo a mis alumnos "Convention over Configuration", significa que una vez que has aprendido algo y lo has hecho una vez, el resto de las veces que vuelves a hacerlo, sólo puede pasar que te equivoques o se te olvide algo. Aparte del cierto regusto que da hacer las cosas manualmente una vez tras otra al principio (hasta que ya se vuelve en hastío), lo único que podemos aportar en un proceso que ya esta bien definido, es el factor humano o mejor dicho "el meter la pata". Por tanto, este paradigma es un arma de doble filo (bueno/malo), como los cuchillos de cocinero que no son aptos para pelar un diente de ajo, pero si para hacer un corte en juliana en segundos.
   
2. Existen una gran multitud de aplicaciones donde Grails refulge: como son las de Backoffice para administrar/configurar/monitorizar desde un Frontend web a un sistema en tiempo real escrito en C++ (donde no importe demasiado el rendimiento porque son utilizadas por un reducido número de usuarios concurrentes), o si nos orientamos más en el mundo PYME, como las que tiene la web de taller de coches o un restaurante (aunque nos pese no tienen cientos de miles de hits a la hora), o en el desarrollo de aplicaciones Intranet/Extranet para corporaciones y sus parners.

Las pertrechos

en este tiempo he evaluado SpringToolsSuite, Netbeans e Intellij como corazas para mi lucha. a riesgo se ser partidista, me quedo con él primero. Ciegamente por ser un Eclipse vitaminado (y Eclipse si que es el grial de los IDES) y porque la nueva perspectiva Grails me gusta mucho, espero que en los próximas meses mejore aún más...

Los templarios y las porfias

Tras estos meses, entiendo mucho mejor a la caballeros que han encontrado el Grial y que defienden su custodia. A escala internacional, el interés estratégico de Spring con Grails, con el fichaje de Graeme Rocher, la inversión en herramientas (el propio STS) y a nivel nacional, he de reconocer que me dejan pasmado la visión comercial y el esfuerzo por difundir esta tecnología de Nacho Brito y Álvaro Sánchez con  Escuela De Groovy , y que admiro todo el trabajo invertido por Dani Latorre, Martín Pérez y Jordi Monné con Jobsket, un desarrollo de los que no parecen hechos por gente de aquí...

¿La búsqueda ha terminado?

Grails. The search is over...¡Not yet for myself!

No. definitivamente no. Grails esta bien para unos escenarios, pero no para todos. No valorar el perfil tecnológico del equipo de desarrollo, el mantenimiento posterior de la aplicación, los requerimientos de rendimiento y carga puede ser temerario. No caigamos en el antipatron del martillo de oro: para un martillo todo son clavos. Otras herramientas como Spring Roo, Jboss Seam, Jruby on Rails y Scala-Lift parecen prometer el mismo nivel de rapidez y simplicidad que Groovy-Grails. Espero poder hacer caso a Jose Ramón Díaz  y a mi buen amigo Israel Álcazar, para darle vidilla al blog contando por lo menos mis impresiones sobre estos temas y otros que crea que os puedan interesar.