Hace unos días me enteré por una entrada en el blog de David Bonilla de una iniciativa que estaban empezando en SixServix. La idea es que ante la necesidad de formación, en lugar de buscar cursos que en la mayoría de los casos no se ajustan a sus necesidades, invitar a personas relacionadas con las materias de las que se quiera aprender para poder hacer unas charlas los viernes por la tarde intentando tener un formato más abierto que el de una simple conferencia y donde se analicen los problemas desde una perspectiva más práctica. Me parece una iniciativa muy buena y lo que más me gusta es que no lo limitan a sus empleados, sino que dejan abierta la puerta a invitar a algunas personas externas, aunque por motivos de espacio tienen que limitarse las invitaciones.
El encargado de inaugurar esa iniciativa fue Alberto Vilches, que tuvo la difícil labor de vender Groovy y Grails a unos desarrolladores Java algo reacios a cambiar (¡o que se hacían los reacios a cambiar para ponérselo difícil a Alberto!).
Hubo gente que siguió en directo la charla a través de una página que se habilitó a tal efecto, e incluso algunos hicieron preguntas a distancia para que David Bonilla las retransmitiera. Pero si te lo perdiste no te preocupes, puedes encontrar el vídeo aquí. Apenas le faltan cinco minutillos que se perdieron por los nervios del directo y de la primera vez.
Albertó empezó a contarnos cómo era su relación con Java y cómo su paso a Groovy.
Lo que nos contó fue que de Java les gusta su sintaxis de estilo C pero sin punteros y con recolector de basura, también que es multiplataforma y ser un lenguaje orientado a objetos. Para desarrollo de aplicaciones web en Java se tienen Servlets, JSP, JDBC… y muchas otras herramientas que hacen que sea un lenguaje bueno para la web. Además, más adelante empezaron a aparecer muchos patrones y muchas cosas en J2EE que hacían la vida más fácil, pero que a veces ofrecían soluciones a problemas que no tenían, introduciendo complejidad y se dependía demasiado del IDE que se utilizara para desarrollar. Para esos temas el OpenSource aportó muchas soluciones (Maven, Ant, Hibernate, Struts, Spring) pero el desarrollo seguía sin ser demasiado rápido.
Así que se necesitaba una solución que permitiera hacer desarrollos RAD, había que hacer aplicaciones y hacerlas ya, y Grails nació en este contexto para cubrir el hueco que Java dejaba sin cubrir, el desarrollo RAD en Java, desarrollando aplicaciones utilizando la máquina virtual.
Grails utiliza como lenguaje principal Groovy, aunque también puedes utilizar clases Java, utiliza herramientas para el patrón MVC como Spring MVC, sus vistas en lugar de estar en ficheros JSP están en ficheros GSP (aunque también podemos utilizar ficheros JSP), tiene herramientas de testing y es muy extensible con plugins. Además es más divertido que Java porque como tienes que escribir menos código le dedicas menos tiempo a escribir código y más tiempo a pensar en los problemas del negocio, y también al haber menos líneas de código las posibilidades de cometer un error y las líneas a revisar cuando se produce uno son menos.
Alberto nos contó la estructura de una aplicación Grails, puesto que se basa en convención sobre configuración: sus controladores, sus servicios, sus vistas y sus clases de dominio y nos hizo algunos ejemplos para que viéramos los distintos elementos en acción.
Y durante la charla se plantearon algunas preguntas bastante interesantes:
– ¿Qué otras opciones se pueden encontrar para el desarrollo de aplicaciones rápidas en Java? Según Alberto lo más parecido que existe es el framework Play que incluye muchas de las cosas que aporta Grails y lo siguiente más parecido Spring Roo, que te permite generar la estructura del proyecto, pero en su opinión ninguna es tan buena como Grails ni puede competir con él en velocidad de desarrollo.
– ¿No dificulta encontrar los errores que sea dinámico? Ciertamente puede dificultar encontrar algunos errores y por ello es realmente importante hacer muchas pruebas unitarias, ya que los lenguajes dinámicos te obligan a ser más disciplinado en ese tema. Y si tienes una aplicación muy mal hecha y sin tests, es mejor rehacerla ya que puedes tener serios problemas.
– ¿Se puede luchar contra el modelo anémico en Grails? Su respuesta fue que no hay ningún problema puesto que puedes añadirle a las clases del modelo cualquier método, aunque me hubiera gustado discutir más sobre ese tema porque creo que tiene bastante más miga, no sólo por los métodos que puedas crear, sino por poder delegar en colaboradores que le puedas inyectar. Espero tener la oportunidad de profundizar más en este tema ya que es algo a lo que me estoy enfrentando ahora y no tengo del todo claro cómo tratar.
– ¿Grails o Rails? La ventaja que tiene Grails frente a Rails es que corre sobre la máquina virtual de Java y te puedes aprovechar de la gran comunidad que tiene detrás, además de que la curva de aprendizaje viniendo de Java es menor.
A mí me pareció una charla estupenda y de la que pude sacar algunos puntos en claro que me vienen muy bien para el trabajo que tengo que hacer en Wiseri. El formato se irá refinando poco a poco para intentar hacerlo más colaborativo, pero dado el caracter introductorio que tenía esta charla creo que no había mucho margen de colaboración a parte de ir viendo de forma práctica las cosas y el ir introduciendo las preguntas tanto de los asistentes presenciales como de los asistentes virtuales ¡que en algunos momentos llegaron a ser 22!
Es de agradecer que se hagan cosas de este estilo y también el estupendo catering que tuvimos gracias a SixServix y que nos sirvió de comida y de merienda post-charla. Espero poder asistir a otras, ¡aunque intentaré no acaparar siempre una plaza para mí!
Muchas gracias por tu resumen Laura! Si necesitas ayuda para luchar con el modelo anémico, cuenta conmigo 🙂
No dudes que lo haremos!! :p, porque de momento es una batalla perdida ¡y eso no puede ser!
Lástima que ya quedara tan poquito tiempo porque si no creo que habría dado para mucho, ¡hasta para una charla entera! xD
Muchas gracias por la entrada y las referencias.
Fue un placer teneros como invitados y, desde luego, confirmamos que SIEMPRE es bueno tener gente de fuera del equipo. Gente que te aporte otro punto de vista.
Muchas gracias Laura, con invitados como tú da gusto 🙂
Hola Laura.
Me pareció ver en el blog de Bonilla que Jmarranz hizo alguna pregunta sobre refactorizar en Grails. ¿Sabes si Alberto contestó a esa pregunta o habló sobre el tema?
Gracias y un saludo,
Julio.
¡Hola!:
Contestó a la pregunta diciendo que dependiendo del entorno que utilices algunos ide’s te ofrecen también opciones de refactorización como el renombrado de métodos y eso, pero si cambias el número de parámetros que se pasan o algunos cambios más complejos si no recuerdo mal no te vas a dar cuenta y vuelve a entrar en juego la importancia de los tests para que al hacer cambios de este tipo puedas darte cuenta cuando antes si te quedan cosas con cambiar.
¿Te vale esa respuesta o intentamos que pase el propio Alberto Vilches a responderla? jeje
También en el vídeo está grabada la respuesta :D.
Un saludo,
Laura
Sobre refactorizar una aplicación en Groovy: dependerá de tu IDE y de como hayas programado tus clases. Se pueden renombrar métodos, clases, cambiar la firma (el orden de los parámetros), extraer métodos, variables y las mismas cosas que se pueden hacer en Java. La única diferencia es que para que el IDE reconozca una variable debe estar tipada. Con IntelliJ acabo de probar ahora mismo a renombrar el método de una clase: si las variables están tipadas, IntelliJ te renombra las llamadas al método directamente sin decirte nada (como sucedería en Java). Si hay alguna variable que no esta tipada, entonces detecta la llamada al método como una llamada dinámica y te lo muestra para que tú decidas si lo debes cambiar o no. Como si dijera “hey, he encontrado un sitio donde se llama a un método con el mismo nombre del método que tu quieres cambiar, pero no se de qué tipo es, así que no estoy seguro, ¿lo renombro?”
Creo que no hay serios problemas en refactorizar una aplicación con Groovy si usamos las herramientas que nos proporciona el IDE y tenemos cuidado (yo lo he hecho). Lo que no podemos hacer es refactorizar “a mano” cambiando el nombre del método, y luego cambiar su uso simplemente mirando en donde ha fallado el compilador por todo nuestro proyecto, como podríamos hacer en Java.
¡Qué lujo contar con el ponente entre mis lectores! 😀
¡Muchas gracias!
De lujo nada chata! el lujo es que alguien haga una crónica de una charla tuya y lo publique en su blog! eso si que tiene mérito! 🙂
Te tengo en el rss así que no te escaparás… :-b
Muchísimas gracias a los 2 por las respuestas. No he probado nada de Groovy, aún, pero era una de las dudas que más me corroían. Desgraciadamente me he acostumbrado demasiado al compilador incremental, refactorings y sobre todo autocompletes del Eclipse jeje.
Supongo que lo normal en Groovy será no declarar el tipo de las variables. Al menos siempre nos quedarán las herramientas de buscar y reemplazar en todo el proyecto jeje.
Laura, yo también voy a añadir tu blog. Está muy bien para los de Provincias esto de contar con una reportera para los eventos de la capital 😉
Un placer ayudar y… ¡seguiremos retransmitiendo! :p
¡Muchas gracias!
Julio, en Groovy tipar es opcional, pero no tiene porque ser lo normal. Personalmente tipo todas mis clases y las del sistema, con generics si es necesario. Donde no suelo usarlo es en colecciones y Strings si son variables locales. Y no lo hago porque no suelo necesitar el autocompletar del IDE en estos casos.
def map = [:].withDefault { 0 } def list = ["a","a","b","c"] list.each { map[it] ++ }Como ves, no se usan metodos de los que el autocompletar del IDE realmente te ayude.