Después de los desarrollos con Grails, hemos sacado conclusiones. Os las contamos en este video-presentación:
Esperamos vuestros comentarios…
-
Twitter VG_grailsteiz
Entradas recientes- La Web Municipal. GEO Vitoria-Gasteiz.
- La Web Municipal. La Sala de Prensa.
- La Web Municipal. El buscador.
- La Web Municipal. La publicación de contenidos.
- La Web Municipal. La gestión de la información.
- La Web municipal
- Greach 2011
- Identificación y Firma en *.vitoria-gasteiz.org (Ubuntu)
- Identificación y Firma en *.vitoria-gasteiz.org (Windows)
- Grails 2.0
- Tumblr
- Upgrading to Grails 2 Unit Testing - Ted Naleid
- InfoQ: Grails Best Practices
- "Grails 2.0.3"
- "Grails 2.0.2"
- Grails 2.0.1 available
- Grails 2.0 Released! | SpringSource Team Blog
- "our test execution time went down from 26 minutes to 12 minutes"
- Testing Domain Constraints Using Grails 2.0 & Spock « Christian Oestreich
- "TDD on Grails by @ggalmazor"
- "Six ways to become a better Grails programmer"
Pingback by Tweets that mention Conclusiones del proyecto piloto « Tecnologías de Información -- Topsy.com
13 mayo 2010 @ 07:26
[...] This post was mentioned on Twitter by Javier Moreno and Aitor Alzola, GRAILSTEIZ. GRAILSTEIZ said: Nuestras conclusiones del proyecto piloto: http://ti.vitoria-gasteiz.org/2010/05/07/conclusiones-del-proyecto-piloto/ [...]
Comentario by potele
13 mayo 2010 @ 08:03
No puedo ver el vídeo.
Comentario by Aitor Alzola
13 mayo 2010 @ 08:19
Revisa la configuración de tu acceso a internet, en principio el video se ve ¿¿??
Comentario by jneira
13 mayo 2010 @ 19:21
Buen resumen, felicitaros por haber puesto en marcha el blog para abrir mas canales de comunicación, interno y también cara al exterior (tanto que esta de moda la apertura de la información de las administraciones)
La verdad es que a veces es bastante fastidioso el tener que trabajar con herramientas algo anticuadas (jdk 1.4, struts 1.1, j2ee 1.3), para mi tener la jdk 5 ya seria un avance tremendo, mejor aun el tener de golpe java 6 (supongo), spring y groovy ((no tanto hibernate). Sin embargo le veo algunos peros:
* El dinamismo de groovy tiene un doble filo como bien se dice en el vídeo, mas peligroso cuanto mas grande es el proyecto. El dinamismo que es como el agua en la parte web puede no resultar tan útil en la capa de la lógica de negocio. Como también se comenta en el vídeo casi hace necesario el adoptar un estilo mas orientado a las pruebas. El adoptar ese estilo de forma estricta y disciplinada me parece mas difícil que adoptar el framework en si, aunque sería un gran avance en si mismo naturalmente.
* Otra cosa que no me acaba de convencer es que no solo sea “full stack”, sino que este tan ligado a unos frameworks j2ee que ahora pueden ser mas o menos estandar pero que no tienen por que serlo siempre, ni siquiera a medio plazo. Si en lugar de hibernate se quiere usar un orm mas liviano, que se ajuste mas a la bbdd (el uso de procedimientos almacenados p.ej.) o simplemente no usar orm dependiendo incluso de cada proyecto, no hay una alternativa. (Igual se puede desinstalar el plugin de hibernate e intalar otro con el que GORM funcione y que desconozco). Lo mismo con spring (hay otros frameworks de DI) o Sitemesh (que el que menos conozco). El tener todo preparado es muy comodo pero tambien podria ofrecerse un arquitectura mas flexible (groovy lo permite mucho mas que java) que te permitiera en un momento dado cambiar de frameworks fácilmente.
* También el abandono del sql que permite grails (puedes programar perfectamente la capa de persistencia si saber mucho de sql ni de la gestión de rdbms) parece que puede desaprovechar los conocimientos acumulados de los programadores. Por otro lado el uso del sql me parece todavía útil, para entender mejor como funciona por debajo la capa mas importante (los datos) y los recovecos de la lógica de negocio.
* En general me da la sensación que aunque se simplifica lo que es la programación (tal vez demasiado), no reduce la cada vez mayor complejidad accidental de la infraestructura de la aplicaciones j2ee en el ámbito empresarial sino que la oculta a los ojos del programador, añadiendo incluso alguna capa mas con sus propias complicaciones. Eso hace al programador mas dependiente de aquel que tenga los conocimientos suficientes de toda esa complejidad para cuando la cosa falle o se quede bloqueado el desarrollo. Esa menor autonomía podría suponer un trabajo excesivo a esas personas lo suficientemente expertas o puede suponer un coste si hay que recurrir a alguien externo.
Me he centrado en los cosas que no me acaban de convencer porque con las positivas que se resaltan en el vídeo estoy totalmente de acuerdo. Ademas tampoco hay ninguna alternativa extendida y estable que no tenga estos mismos problemas o todavía peores así que tampoco serian motivos para no usarlo y la verdad que me gustara trabajar con grails si se me presenta la ocasión.
Nos vemos!
Comentario by jneira
13 mayo 2010 @ 19:24
Funcionan los comentarios?
Comentario by Aitor Alzola
14 mayo 2010 @ 06:05
@jneira Como ves, los comentarios si funcionan
Como comentas, la solución no es perfecta, en eso estamos de acuerdo, la cuestión es encontrar algo más perfecto (¡¡sin tener que construirlo!!)
* “El dinamismo de groovy … mas peligroso cuanto mas grande es el proyecto” Cuanto más grande sea el proyecto, todo se vuelve más peligroso, independientemente del lenguaje que utilicemos. Existen ejemplos de proyectos grandes bien solucionados (seguro que mal solucionados también) en Grails. Y en Java. Y en ruby. Y en ${ponga aqui su lenguaje favorito} Utilizar las pruebas automáticas siempre será un paso adelante.
* “ligado a unos frameworks j2ee que ahora pueden ser mas o menos estandar pero que no tienen por que serlo siempre” La evolución de la tecnología es algo contra lo que es difícil luchar, quizá hay que concentrarse en intentar lidiar con ello, no contra ello. Una evolución deseable del framework sería hacia algo más modularizable, que permita intercambiar piezas, aunque no sé si está preparado para un cambio tan grande.
* En cuanto al sql, no creo que se nos olvide de un día para otro, y en algunos momentos lo agradeceremos. En un momento dado, lo podríamos hacer todo con martillo y cincel, pero creo que no lo haremos (:P).
* “no reduce la cada vez mayor complejidad accidental de la infraestructura de la aplicaciones j2ee en el ámbito empresarial” eso no hay quien lo arregle, la verdad. A mi si me parece un avance que lo fácil (y habitual) sea fácil y lo difícil posible, aunque sea con un poco de ayuda.
Total, creo que estamos más o menos de acuerdo. El framework tiene sus problemas, pero creo que supone un avance interesante.
Comentario by linsms
24 mayo 2010 @ 09:31
He tenido la suerte de trabajar en unos cuantos proyectos con symfony (php) y ahora comenzamos a trabajar con grails. Me gusta grails por sus similitudes con symfony (salvando las distancias) pero aún le queda un, espero, largo recorrido (como por ejemplo, independizarse del ORM o mejor integración con otros frameworks javascript).
Coincido en todas las respuestas de Aitor excepto en que si se reduce la complejidad de las aplicaciones. Al reducir el número de líneas de código para hacer lo mismo la aplicación se hace mucho más fácil de mantener. Puede ser cierto que se dependa del framework y de quien sepa utilizarlo al completo, pero lo mismo nos pasa con, por ejemplo, struts 1.
Como ventaja añadida del framework, por encima de por ejemplo symfony que puede estar más maduro, además del rendimiento (no he evaluado los aceleradores php, pero en operaciones básicas es 10 veces más rápido), está la integración total con java: podremos reutilizar lo que ya tenemos y aprovecharlo conjuntamente con lo que groovy y grails nos proporcionan.