Llevo unos días jugando un poco con Grails y es un framework que estoy viendo bastante interesante, como también ir aprendiendo groovy.
La cuestión es que después de ir probando diferentes cosas del framework, y ver la facilidad que dan los constraints para las validaciones en las clases del dominio, pensé la situación de registro de un usuario. En esta situación, se suele utilizar un segundo campo para confirmar la contraseña, por lo que no podía validar esta situación en los constraints de la clase de dominio del usuario ya que password2 no forma parte de él.
La solución es utilizar los Command Objects, que tal y como dice la documentación sería algo como los form bean en struts. Estas clases se suelen declarar en el mismo fichero que el Controller que lo va a utilizar, y se definen los constraints de la misma forma que en las clases del dominio.
En mi caso, necesitaba comparar dos parámetros del formulario, para esto debía usar un constraint propio:
password1( validator: {
val, obj ->
obj.password2 == val
})
La validación se hace sobre password1, val es password1, obj -> es MiCommandObject y con obj.password2==val vemos si son iguales. Esto es porque si el clousure recibe dos parámetros, el primero toma el valor y el segundo el objeto de referencia(en este caso el Command Object).
Mi conclusión en cuanto a la documentación oficial de Grails, es que ya hay bastante cantidad de información pero en algunos momentos demasiado dispersa.
Al cortar la creatividad, no sólo se le esta prohibiendo a los desarrolladores hacer lo que más les gusta, si no que además éstos perderán todo "enlace sentimental" con el código que han creado. No esperes que estos desarrolladores vuelvan atrás, o se queden un par de horas, o piensen en casa como mejorar un código que les han obligado a escribir.
Esto es un pequeño extracto del post de Martín code reviews, ¿buena o mala idea? y, como no puede ser de otra forma ;), estoy muy de acuerdo con lo que dice en el post.
Centrándome en el extracto creo que esa situación, sino todos, la mayoría de desarrolladores la habremos sufrido, ya sea por revisiones de código o por imposición de una forma de trabajar.
Existen ocasiones en las que tal y como vamos escribiendo el código, no nos gusta y vamos pensando la forma en la que lo haríamos o que herramienta/librería/framework podríamos tratar de utilizar para ayudarnos. Esto nos lleva a sentirnos menos responsables de nuestro código ya que lo hubieramos hecho de otra forma y, por qué no, a ser algo menos productivos por no estar del todo centrados.
Con esto no quiero decir que crea que cada desarrollador debiera trabajar a su manera, porque al final lo más normal es trabajar en un equipo y se deben acordar unas bases de cómo se van a hacer las cosas, pero sí dar cierta flexibilidad para experimentar y "jugar".
Igor Minar ha publicado en su blog que han reescrito por completo mediacast, una aplicación web para que los empleados de Sun puedan publicar archivos.
Al parecer, la versión anterior estaba desarrollada con Servlets+JSP+Filtros y resultaba dura de mantener, por lo que decidieron reescribirla desde cero. Él sugirió que en el nuevo desarrollo se utilizara Rails con JRuby para desplegarlo en un servidor java. El equipo lo formaban él, que ya tenía alguna experiencia con Ruby on Rails, y otros dos compañeros más, éstos sin experiencia con Ruby o JRuby.
Algunas de sus razones para usar JRoR:
- Al comenzar desde cero, no tenían código heredado
- Utilizar el proyecto como prueba de concepto para otros usos
- Comprobar que se cumple la promesa Rails para el desarrollo rápido
- Algo nuevo y divertido para el equipo, para equilibrar las cosas no tan divertidas (La que más me ha convencido:P)
Por lo que comenta, la arquitectura de la aplicación no es demasiado compleja, aunque para mejorar el rendimiento utilizaron cacheos.
En el entorno de producción cuentan con un par de servidores balanceados T2000 con una unidad NAS compartida para el almacenamiento de ficheros, con Solaris 10, el JDK6, Sun Application Server 9.1 como servidor de aplicaciones y un servidor MySQL. Lo único que se echa de menos es que no de números de la carga que suele soportar el entorno de producción.
En cuanto al desarrollo, el core de la aplicación lo tuvieron listo en poco tiempo y parece que gracias a la poca cantidad de código necesario, el código lo revisaban rápidamente y los bugs los solían solucionar con pocas líneas de código. Encontraron problemas por no poder utilizar la mayoría de las gemas basadas en C y con las peticiones largas, que les supusieron la mayoría del tiempo de trabajo, ambos problemas los acabaron solucionando usando Java.
Que yo conozca, es la segunda aplicación que desarrolla una gran empresa con JRuby on Rails, tras Oracle Mix. Habrá que estar pendiente de los lenguajes dinámicos como JRuby y Groovy, pudiendo reaprovechar el conocimiento ya existente en Java y si va mejorando el rendimiento de estos lenguajes, quizás se empiecen a tener en cuenta como otra opción más dentro de la plataforma.
