Hace un mes algo cambio en el trabajo. Mi grupo, en vez de seguir adaptando nuestro software de siempre a los distintos proyectos en curso (y corrigiendo las incidencias que siempre salen), hemos pasado a realizar software nuevo. Eso me ha llevado a decidir usar TDD, y para la parte de interface de usuario probar fest-swing, y a meterme con izpack para generar los instaladores … y cogida la inercia de probar las nuevas cosas que siempre he querido aprender/aplicar y no he podido, me he lanzado a probar más cosas, en casa y sin tener nada que ver con el trabajo. Openmap primero, tText después, lo de la google app engine con python, etc.
Al final me he decidido a hacer un pequeño tablero Kanban usando Grails. ¿Por qué Grails?. Pues simplemente porque no lo conozco. ¿Por qué subirlo a github? Pues porque nunca he usado git. Y la verdad es que me ha enganchado bastante todo esto. Llevo varios días en casa programando hasta la una o las dos de la madrugada. Para alguien como yo, acostumbrado a irse a la cama sobre las once, eso son horas realmente intempestivas. Y desde los viejos tiempos de la universidad que no me quedaba programando hasta esas horas.
¿Qué tal con Grails?
La verdad es que me ha decepcionado un poco. La primera impresión con las primeras pruebas fue muy buena, con poco tiempo y pocas líneas de código se pueden hacer muchas cosas. Pero resulta que uso Google Chrome como navegador y tengo de pantalla de inicio una en la que salen las páginas más visitadas. Pues bien, rápidamente la página que muestra las excepciones de mi aplicación se ha convertido en una de las más visitadas y es un poco deprimente.
Por un lado, groovy, el lenguaje de grails, no es fuertemente tipado, por lo que los IDE no dan un auto-completar demasiado completo, cosa imposible si en ningún sitio aparece el tipo de la variable. Esto hace que los errores de sintaxis al escribir nombres de métodos o atributos estén a la orden del día y no los descubres hasta que compilas, aparte de tener que navegar por el código para ver cómo era el nombre exacto.
Además, grails entiende/busca ciertos atributos en las clases para hacer cosas, como hasMany, allowedMethods, belongsTo, etc. Pues bien, nuevamente un error de sintaxis al escribir alguno de estos puede darte quebraderos de cabeza un rato. Compilar, compila, pero luego un tablero kanban no "hasmany" pegatinas dentro y te sale vacío.
La documentación de grails es bastante escasa. Si un tablero hasMany pegatinas, grails añade automáticamente de alguna forma el método tablero.removeFromPegatinas(). Pues bien, navegando por la documentación de grails no he encontrado ningún ejemplo de ese método, pero curiosamente, buscando en google, he llegado a un sitio de la documentación de grails donde sí pone el ejemplo (me hace la impresión de que es una documentación antigua que google encuentra, pero no está enlazada desde la documentación principal). Pues usas el ejemplo tal cual y no funciona, da errores de "deleted object would be re-saved by cascade". Buscando en los foros, veo que es un error que sale con frecuencia y no he visto en ningún foro que alguien dé una solución definitiva. Y lo peor no es que me dé ese error, porque si hago algo mal es normal que me de error, lo peor es que lo da de forma aleatoria en una misma ejecución. En una misma ejecución creo pegatinas, las borro, y unas las borra y otras falla, pero después de fallar, las vuelves a borrar y esta vez sí las borra … o no. Si grails tiene éxito y se usa, estoy seguro que algo estoy haciendo mal, pero desde luego, la documentación no ayuda a descubrirlo.
No todo es malo. Tiene muchísimas cosas que hacen el trabajo más rápido y más fácil. Por ejemplo, si una clase persistente en base de datos tiene los atributos nombre, apellidos y telefono, grails permite hacer consultas con métodos findAllByNombre(‘nombre’), o findAllByNombreAndApellido(‘nombre’, ‘apellido’) o findAllByNombreBetween(‘nombre1′,’nombre2’) y cualquier combinación larga y extraña que se te ocurra con los atributos de la clase, siguiendo ciertas reglas.
Seguiré jugando unos días con grails y la aplicacioncilla que estoy haciendo,
El tipado estatico tira mucho y es dificil dejarlo de lado y tirarse al vacio de las variables sin tipos explicitos. Eso hace la tdd mas necesaria al no tener los «test automaticos» en tiempo de compilacion que te da el tipado estatico. Sin embargo da otras ventajas que igual no has podido apreciar todavia del todo, pero groovy te permite hacer cosas que java no hara ni en la version 9..te recomiendo la serie de miniposts groovy goodness en este blog: http://mrhaki.blogspot.com/search/label/Groovy%3AGoodness
(aunque mi lenguaje favorito es clojure of course)
Hola Javier, te animo a seguir con Grails. Normalmente, los metodos adicionales si estan documentados en la guia de usuario. Si no encuentras algo, puedes ver al lado derecho de esta pagina ( http://grails.org/doc/latest/ ) y podras ver que para cada metodo y cada tag hay un ejemplo completo. En el caso de los taglibs, tambien esta el source escrito en groovy.
Tambien te recomiendo familiarizarte con el grails console, pues te permite experimentar con grails y groovy sin tener que escribir controllers o views.
Ademas de el blog de Mr. Haki, Scott Davis ha escrito una serie bastante buena ( en inglés ) en el IBM developerWorks – http://www.ibm.com/developerworks/java/library/j-grails02128/index.html .
Para mi, Grails se aprende mas rapido por ejemplo. El projecto blogito es bastante pequeño y es bastante buena para aprender. http://blogito.org/. Para tests, te recomiendo los projectos que tiene Robert Fletcher ->
http://github.com/robfletcher/grails-selenium-rc/tree/master/test
suerte
@jneira @tomas Gracias por los enlaces, seguro que me son de utilidad estos días mientras sigo jugando con ello. Soy consciente que cuando comienzas con algo todo son pegas y avanzar un pequeño pasito cuesta unas horas de sueño.
En cuanto a la documentación del método removeFrom si lo ví http://grails.org/doc/latest/ref/Domain%20Classes/removeFrom.html pero es bastante escueto. No indica si después hay que hacer un author.save() o un book.delete(). Si no haces el book.delete(), el book no se borra de base de datos, pongas o no el belongTo. Sin embargo, buscando en google, se llega a esto http://www.grails.org/Many-to-Many+Mapping+without+Hibernate+XML también de la página de grails y con un ejemplo algo más completo de removeFrom(). A esta página no se llega desde la documentación y aquí sí borra el equivalente al book.delete(). En cualquier caso, a mí, hacer eso, me da el error que he comentado.
Sin embargo no todo el monte de grails es oregano y, aunque groovy me atrae, grails no tanto ya que es tiene mucho de «magia» y soy reacio a las soluciones magicas. La «magia» en la programacion es al principio muy seductora pero tiene un precio que tarde o temprano hay que pagar. Por debajo bien escondido tiene hibernate y spring con el nucleo propio de grails que tampoco es transparente. No me convence esa integracion tan ferrea con hibernate y que no se pueda usar GORM de otra forma sin muchas dificultades. Por cierto tambien se puede usar groovy en aplicaciones de escritorio con swing al estilo de grails: http://groovy.codehaus.org/Griffon
que es obra de @aalmiray (twitter)
joe Tomas es @tomaslin, un crack en esto de grails, que ha superado el nivel de grails install-plugin hazme-lo-que-quiero-sin-saber-lo-que-pasa-por-dentro para que la magia no se vuelva en tu contra
¿Y qué opinión te ha merecido el lo del google app engine con python? Veo que no es lo que finalmente has elegido…
Interesante post, y aún más interesantes comentarios 🙂
Respecto a la decepción inicial, es lógico cuando uno se adentra en un framework nuevo «a las bravas», donde además el lenguaje también es nuevo. A mí me ha pasado con cada pieza de J2EE (JDBC, EJB 2.1, …), luego con Struts 1, después con JPA, con Spring… La diferencia es que en todos esos casos, el aprendizaje fue INFINITAMENTE más traumático.
Respecto a Groovy, autocompletado y demás. No te das cuenta de la dependencia que tienes con el IDE hasta que sales de Java. Yo me he pasado mucho tiempo utilizando escribiendo atributos y luego «Source > Generate Getters and Setters». En aquél momento parecía una buena idea. Te acabas aprendiendo hasta el atajo de teclado. Al final te das cuenta de que son soluciones a problemas que ahora simplemente no tienes.
La gente de Ruby on Rails al principio no tenía un IDE. Ahora tienen algo como Netbeans y algún plugin en Eclipse, pero si hablas con ellos te darás cuenta que la mayoría de ellos utiliza TextMate. No necesitan un IDE. Yo personalmente, tampoco.
Respecto a la escasez de documentación. Discrepo :). Aparte de haber bastantes libros (incluyendo el de mi colega Nacho Brito, Manual de Grails), la guía de referencia que te menciona Tomas cubre el 90 ó 95% de posibilidades. Aparte de que se lee en pocas horas.
Hace 2 años tuve que tragarme un montón de bugs de Struts 2, especialmente en un soporte de Ajax que de la noche a la mañana decidieron tirar y volver a escribir sin consultar, con una lista de correo en la que hay mucha más gente preguntando que respondiendo. Pero de eso nadie dice nada, porque se llama «Struts» y porque es de Apache.
Sobre la magia. Lo siento, amigo @jneira, pero también discrepo. No hay nada de magia ni en Groovy ni en Grails, sino desconocimiento de cómo funcionan. A mí me ha pasado, y me pasa con muchas cosas (eg: JSF). Pero con ese argumento podría decirte que nunca usaría un grifo porque me parece magia que lo abras y salga agua.
Graeme Rocher usa una frase muy acertada en sus presentaciones, acerca de los «facts» sobre Grails: «Built on the Shoulders of Giants». Esta filosofía de Grails es parte responsable de su grandeza; pero también de sus miserias: los «peores» bugs de Grails no son de Grails, son de Spring o de Hibernate o de… otros.
En fin. En cualquier caso, por encima de cualquier framework o tecnología están las personas que lo usan. Quiero decir que si el equipo es bueno, la tecnología es lo de menos, el proyecto seguro que sale. La cuestión ponérselo más fácil o más difícil.
Te animo a que sigas aventurándote en Groovy y Grails, y que compartas tus experiencias, sean buenas o malas. Seguro que en las malas podemos ayudarte 🙂
@Ivan Lo del app-engine-python lo he probado muy poquito y aunque no sé ni python ni groovy, mi objetivo principal es aprender cosas nuevas y de python sé un poquito más que de groovy. Ese ha sido el principal motivo para elegir groovy/grails, y es el mismo motivo por el que elegí git/github como repositorio en vez de svn/google-code, que ya conozco.
Entre google-app-engine y grails veo una ventaja y una pega. La ventaja de google-app-engine es que te dan hosting gratis para subir tu aplicación. Un hosting gratis para grails (o para subir wars) creo que es más complejo de encontrar. La pega de google-app-engine es que dependes totalmente de google. No podrías, por ejemplo, desplegar una de esas aplicación en tu intranet del curro.
@Alvaro Estoy de acuerdo en que hay cosas más traumáticas que grails. En su día intenté un «hola mundo» con jee y jboss y acabé dejándolo por imposible, mientras que con grails tenía el «hola mundo» y lo modificaba a placer (salvando mi desconocimiento) en cuestión de minutos. La documentación está bien en el sentido de que trae más o menos todo lo que hay y es la que consulto principalmente, pero la veo o bien poco didáctica, o bien que presupone que sabes cosas (groovy quizás) que no es mi caso. El ejemplo es el que he comentado sobre los removeFrom() que no consigo hacer funcionar. Tampoco consigo configurar el logging (sí, lo he visto en la documentación y no lo he intentado demasiado, pero no me ha funcionado ni a la primera ni a la segunda, seguiré con ello y seguro que es una tontería).
Por cierto, he mirado los fuentes de bloguito y sí, tienen hasMany y belongsTo, pero no usan para nada removeFrom(), sino que directamente borran el hijo. ¿Es posible que la forma correcta de usar removeFrom() sea no usarlo?
Y en cuanto al IDE y autocompletar, yo vengo de antiguo y he programado varios años con C/C++ y el editor vi, pero creo que frena la velocidad de desarrollo el tener que buscar el nombre exacto del método en el código o descubrir que te has equivocado en tiempo de compilado, sobre todo en proyectos grandes con muchos ficheros fuente implicados. Soy consciente de que no puedes ser dependiente del IDE y debes saber trabajar sin IDE, pero la velocidad de desarrollo se incrementa considerablemente con un autocompletar o que te diga, según escribes, si compila o no.
Hola Javier,
Acabas de descubrir la razón por la que el backend de Jobsket está en Java: IDEs+Documentación+Curva_de_Aprendizaje+Hacks era demasiado para lo que queríamos.
Por eso acabamos utilizando Grails sólo para lo que más nos es útil, como pegamento de Spring, buen framework de vista/controlador y fuente inagotable de plugins. El resto Java. A riesgo de tirón de orejas por Álvaro 😀
El desconocimiento de como funciona algo es la razon de verlo como algo magico esta claro y depende del conocimiento de uno mismo o del equipo con que trabaja. Sin embargo hay herramientas mas transparentes que otras. El sustrato de grails es spring e hibernate que son ya librerias muy grandes, complejas y poco transparentes con montones de opciones y funcionalidades (de las cuales no se usa la mitad) y … bugs, sobre todo hibernate. Librerias que consiguen meter debajo de la alfombra de capas y mas capas la complejidad inherente a los ambiciosos objetivos que cumplen Y la complejidad circunstancial que ellas mismas añaden. Y grails es una capa mas encima para ocultar la complejidad al usuario final. Las herramientas geniales son las que abordan o cabalgan la complejidad inherente al desarrollo del software haciendolo mas simple (casi nunca de puede conseguir) o al menos no añadiendo mas complejidad. Grails no lo es, es una capa mas, una alfombra mas donde barrer la complejidad. Es una buena herramienta, mejor que la mayoria que habia hasta ahora pero no mucho mejor.
Creo que la razon de su exito y su pecado original es su estrecha relacion con el entorno del software de empresa tradicional (en este post se habla del tema http://metasieve.wordpress.com/2010/03/05/does-grails-have-a-problem/). Demasiado estrecha diria yo con spring detras vendiendo la moto a todas las grandes empresas que trabajan con j2ee. Ahi esta una de las razones de fundir grails con hibernate y spring. Por supuesto tambien aprovechar todo el trabajo de esas frameworks, pero no olvidemos que hay mas opciones y que las habra y que se podria haber hecho tambien plugable tanto el orm como el di.
Y luego la generacion automatica de codigo y la convencion sobre configuracion son un arma de doble filo en la medida del esfuerzo que haya que hacer para comprender y dominar todos las interioridades. Y es que mientras todo va bien el monte es oregano pero el dia que la cosa se cae puedes perder todo el tiempo que te has dejado mecer en el grails install-plugin y grails agita-varita saca-conejo-chistera, mirando stacktraces kilometricas mientras te preguntas en que piso del rascacielos la cosa esta fallando.
Pero bueno mientras esperamos tiempos mejores en que la complejidad sea efectivamente reducida y no ocultada y se extiendan a la empresa formas de programar que revisen las bases mismas de la programacion y el software (arquitectura restful, programacion funcional, metaprogramacion sencilla e inmediata, librerias y frameworks livianos, transparentes y con un objetivo claro y delimitado) pues Grails es un buen arbol donde cobijarse (mejor que el que tengo yo ahora desde luego)
Joe vaya tocho os he metido.
uf el link con el parentesis no va muy bien http://metasieve.wordpress.com/2010/03/05/does-grails-have-a-problem/
Tocayo! edicion de comentarios y codigos html ya! 😛
@Chuidiang, el addTo y removeFrom lo único que hacen es asegurarse de poner/quitar los enlaces en ambos sentidos, en el caso de relaciones bidireccionales. Por supuesto que puedes hacerlo a mano. Total, son 2 líneas :). Respecto al logging, aquí está explicado, y te aseguro que haciendo lo que pone ahí debe funcionar.
@Martín, de tirón de orejas, nada. A mi charla en el Spring2GX Day me remito 😉
@jneira, estoy de acuerdo en que Grails es mejorable, como todo por cierto, pero según está ahora, ha revolucionado por completo mi relación con el desarrollo de aplicaciones. Llevamos ya más de 10 proyectos en Grails, algunos en desarrollo, otros en producción desde hace 2 años, uno de ellos de más de 1 año de desarrollo… y te aseguro que para nosotros hoy por hoy es lo mejor que hay con mucha diferencia. Period (como dicen los guiris :P).
Respecto al uso de Spring e Hibernate, fue una decisión que se tomó hace 5 años, muchísimo antes de SpringSource. Si usan esos frameworks es simplemente, porque todo el mundo (vale, la mayoría) los usa. Podrían haberlo implementado de cero; podrían haber elegido otros. Pero elegir esos me parece la mejor decisión posible. Gracias a eso, Grails no es muy diferente tecnológicamente de la mayoría de proyectos que la gente realiza.
La generación automática de código… yo no la utilizo. Si acaso en los controllers, pero nunca en las vistas. Tardo menos haciéndolo de cero. Y la convención sobre configuración… es precisamente lo que hace que seas más productivo. Nadie en Rails dice que eso sea un problema del framework.
Comparte tú también si quieres tus problemas, a ver si podemos ayudarte 🙂
Un saludo.
@Alvaro. Lo del log, como comento, no lo he mirado mucho, supongo que si me pongo a ello no tenga mucho truco. Me precupa más el addTo y removeFrom. Supón que llamo a padre.removeFromHijos(hijo). Las dudas concretas son:
– ¿debo llamar también a padre.save()?
– ¿debo llamar a hijo.delete()?
– ¿Por qué, haciendo todas las combinaciones posibles de llamar y no llamar a esos métodos o bien no se borra el hijo de base de datos o bien sale el error de «deleted object would be re-saved by cascade»
– ¿Por qué el error sale aleatoriamente?. Me da la impresión que el por algún tipo de caché o buffer que le da le da o no tiempo a actualizarse, pero los save(flush:true) o delete(flush:true) tampoco me lo resulven.
– ¿No es este un uso habitual y trivial que no debería dar ningún problemas?
Y efectivamente, al final acabe pasando del hashMany y el belongsTo y puse directamente la clave del padre en el hijo y los manejo independientemente, pero no creo que sea la solución elegante.
Bueno mi comentario es mas en el ambito del diseño y de las tendencias en el mundo de la programacion que de problemas concretos con el framework. No puedo evitar levantar la alfombra para ver lo que hay debajo en lugar de pisarla sin mas. Grails es una muy buena opcion para empresas que tengan un bagaje en j2ee, productiva, sin mucha curva de aprendizaje y taltal pero no le veo mucho futuro a largo plazo precisamente por ser groovy tan parecido a java y por estar grails subido a un vetusto gigante con los pies de barro. El continuismo que le da su exito ahora le quita opciones de futuro, en mi opinion. Y esta claro que comparado con la j2ee tradicional es una bocanada de aire fresco pero se mueven mas cosas en el mundo de la programacion en general y en la de programacion en java que groovy y grails, cosas que suponen un cambio mas radical, mas arriesgadas de adoptar en determinados ambitos empresariales conservadores. Por ejemplo erlang, scala (el backend de twitter esta en este lenguaje), clojure, etc,etc.
Pero la clave del futuro exito de grails es si las grandes (y pequeñas) empresas de subcontratacion en el mundo de la it pueden formas equipos de programacion con poca experiencia y bajo nivel tecnico, o sea baratos, que saquen adelante proyectos con un minimo de calidad (o sea que funcionen). Java es perfecto para eso. Si grails vale tambien su exito esta asegurado para mucho tiempo.