23. noviembre 2011, 15:39
Tras el primer artículo que escribí sobre las nuevas características de Grails 2.0 en las que comentaba básicamente aquellas nuevas características que ayudaban al desarrollador a ser más productivo todavía si cabe, en este nuevo artículo comentaré otros aspectos novedosos en la nueva versión de Grails como son la introducción de HTML5 y otras mejoras relativas a la generación del contenido de nuestras aplicaciones así como de otras mejoras en lo relativo a GORM.
Quizás el aspecto que más llama la atención cuando generamos una aplicación en Grails 2.0 utilizando su scaffolding es el cambio de interfaz que ha habido en relación a versiones anteriores. Este cambio es debido principalmente a que en esta nueva versión se ha empezado a utilizar HTML5. Este scaffolding es mucho mejor que en versiones anteriores y representa lo que se conocen como buenas prácticas a la hora de diseñar aplicaciones web.
En la nueva versión de Grails también se facilita la creación de páginas para por ejemplo ser envíadas a través de emails (tipo newsletter) a través del API de la clase PageRenderer. Esta generación de emails se hacía complicada en versiones anteriores debido a la falta de una petición HTTP en la que basarse.
Del mismo, si en estos emails queremos generar enlaces dinámicos hacía partes de nuestras aplicaciones, podemos utilizar el API de la clase LinkGenerator.
Por otro lado, el plugin resources ha sido integrado en el nucleo de Grails 2.0. Este plugin permite declarar recursos estáticos en nuestras páginas de forma sencilla y además, optimizando incluso las llamadas a los mismos para no repetir peticiones a un mismo recurso.
Todo esto en lo relativo a la parte web de nuestras aplicaciones en Grails 2.0. Pasemos a ver ahora las nuevas características en lo relativo a la gestión de los datos de nuestras aplicaciones.
La características más importante es que GORM ya no se basa únicamente en Hibernate sino que puede ser utilizada con otros entornos como Mongo DB, Redis, Riak, Amazon SimpleDB, Neo4j o Cassandra.
Se ha creado para GORM lo que se conoce como las Where queries que no es más que un DSL para realizar consultas a nuestras clases de dominio.
def query = Person.where {
firstName == “Fran”
}
def fran = query.find()
Este tipo de consultas se comprueban en tiempo de compilación lo que nos adelanta posibles problemas de nuestras consultas. Además, te habrás dado cuenta de que incluso podemos utilizar caracteres como ==, >=, <=, <, >, != en estas consultas que posteriormente serán traducidas al lenguaje SQL correspondiente.
Además, también vamos a poder utilizar funciones agregadas como avg(), sum(), max(), min(), etc. En la siguiente consulta obtendremos aquellas personas cuya edad sea superior a la media.
def query = Person.where{
age > avg(age)
}
También podemos definir varias fuentes de datos de nuestra aplicación que como siempre definiremos en el archivo de configuración DataSource.groovy. Además, en Grails 2.0 también vamos a poder hacer ingeniería inversa a partir de un esquema de base de datos para ahorrarnos tener crear a mano todas las clases de dominio de la aplicación.
Por último, se han creado dos nuevas funciones de GORM que son findOrCreateWhere() y findOrSaveWhere() que como su propio nombre indica, en primer lugar buscar en las clases de dominio un registro que cumpla las condiciones pasadas en el método y en caso de que no exista lo crea o lo modifica en función del método utilizado.
10. noviembre 2011, 09:41
Ayer estuve viendo un screencast presentado por Peter Ledbrook en el que presentaba las nuevas características que vendrán con la nueva versión de Grails 2.0, así que me he decidido a escribir unos pequeños artículos en los que comentaré esas nuevas características.
En este artículo veremos algunas características introducidas en el entorno de desarrollo de Grails. En primer lugar hay que comentar que se ha mejorado la interfaz de la consola en el modo interactivo en la cual podremos ejecutar cualquier comando de Grails y ayudarnos al mismo tiempo de su autocompletado. Llama la atención que incluso vamos a poder ejecutar comandos externos a Grails como si estuviéramos en el shell de Linux.
Se han mejorado también las plantillas que muestran los resultados de los tests para que sea más intuitivo saber que ha sucedido en la última ejecución de dichos tests. Siguiendo con las plantillas utilizadas en el proyecto Grails, desde la versión 1.3 la documentación seguía una estructura muy sencilla de consultar (IMHO). Pues bien, desde la versión 2.0 vamos a poder utilizar estas plantillas para realizar la documentación de nuestras aplicaciones en Grails.
Algo que nos ayudará a ser incluso más productivos es la mejora que se ha introducido en Grails 2.0 en el mostrado de los errores por pantalla. En esta versión se mostrará no sólo la línea en la que se produce un error en el controler sino que también se mostrará el error producido en el servicio en caso de que el controlador invoque a un servicio con lo que encontrar el error será una tarea mucho más sencilla.
Por otro lado, en Grails 2.0 se cambia la base de datos que viene por defecto para desarrollo, que hasta ahora era HSQLDB por H2. Pues bien, desde la versión Grails 2.0 vamos a poder consultar el esquema de base de datos creado automáticamente a partir de las clases de dominio accediendo a la URL http://localhost:8080/app/dbconsole y así hacernos una idea de lo que está creando Grails por detrás de las cortinas. Lo bueno de esto es que no sólo está disponible para una base de H2, sino que podremos hacerlo con cualquier base de datos que se pueda conectar mediante JDBC.
Algo que también me gusta mucho y que ayudará a saber que plugins son los mejores en cada categoría es que a partir de ahora se hará un seguimiento del uso de los plugins en proyectos reales, por supuesto, siempre y cuando demos permiso para esto. Con lo que ahora además de la propia valoración de los plugins podremos ver el uso que se está haciendo del mismo en otros proyectos.
Por supuesto, Grails 2.0 viene con las librerías actualizadas de los paquetes utilizados como son Groovy 1.8, Spring 3.1 y Hibernate cuyas versiones irán desde la 3.3 hasta la 3.6. Además, el plugin de Tomcat funcionará con la versión 7.
Los desarrolladores de Grails ya sabéis que en la mayoría de los casos no hace falta reiniciar la aplicación cada vez que introducimos un caso, pero esto no sucede en ocasiones y toca parar la aplicación. Pues bien, en Grails 2.0 no es necesario para la aplicación cada vez que hagamos referencia a un servicio desde un controlador, modifiquemos una clase de dominio o cambiemos una clase de los directorios src/groovy o src/java, ya no será necesario reiniciar la aplicación en desarrollo con lo que también ahorraremos tiempo. Además, también tenemos la posibilidad de añadir el parámetro -reloading en cualquier comando Grails.
Por último, si queremos desarrollar un plugin, hasta el momento no había más remedio que publicarlo en formato zip e incluir los archivos fuente de dicho plugin. Lo bueno que tiene esto es que si un plugin no hace exactamente lo que queremos podemos modificarlo a nuestro gusto y lo malo, es que nadie que quiera proteger su desarrollo, iba a subirlo como un plugin, con lo que muchas empresas no se implicaban en el desarrollo de estos plugins. Esto puede hacer que estas empresas terminen desarrollando plugins, aunque también será muy probable que terminemos pagando por ellos. Aunque como dicen por ahí, Nada es gratis y si algo nos soluciona un problema o nos ahorra horas de trabajo, es normal que tengamos que pagar por ello, ¿no?
La próxima semana veremos algunas mejoras introducidas en la parte web y GORM de Grails 2.0.
22. junio 2011, 11:45
En muchas ocasiones, el éxito de una idea reside en la rapidez con la que sepas llevarla a cabo y si esta idea además requiere de una aplicación, debes saber elegir que tecnologías y metodologías utilizar. Si por si fuera poco, el presupuesto inicial con el que cuentas es prácticamente nulo, debes acudir a soluciones gratuitas no significando esto que sean malas.
En este artículo voy a explicar como podemos utilizar CloudBees para desplegar nuestras aplicaciones en Grails utilizando como repositorio BitBucket y desplegando automáticamente las nuevas versiones de la aplicación a partir de los cambios subidos a nuestro repositorio.
Comencemos por BitBucket. BitBucket es un repositorio gratuito y privado (esto es muy importante ya que la mayoría no nos ofrecen esta privacidad) basado en Mercurial. Sí, ya sé que Mercurial no es de los sistemas de control de versiones más extendidos, pero si queremos esta privacidad y este precio (gratis), tenemos que conformarnos con esto.
BitBucket ofrece incluso colaboración entre usuarios hasta cinco de forma gratuita. Repito, pocos servicios ofrecen esto gratis. También puedes utilizar un wiki para generar documentación del proyecto e incluso tienen sistema de tickets integrado.
Pasemos al siguiente elemento de nuestro stack de aplicaciones que es “CloudBees”. CloudBees no es más que un servicio que te permite desplegar aplicaciones Java (o Grails en nuestro caso) en un servidor en producción. Esto se conoce como el RUN@Cloud. En la cuenta gratuita te permiten hasta 5 aplicaciones diferentes. Además de las aplicaciones, CloudBees también te ofrece la posibilidad de utilizar sus servidores de base de datos MySQL, también hasta 5 como máximo. Aquí es donde viene un problema con CloudBees y es que el tamaño máximo de estas bases de datos es únicamente 5 MB en la versión gratuita y el paso a la versión de pago la verdad es que me parece un poco cara (25$/mes por 1 GB). Ahí, no hay término medio.
La primera aplicación que desplegué en CloudBees fue el ManagerT1, esa aplicación que te permite jugar a la Fórmula1 con tu cuenta de Twitter y que la verdad es que no ha tenido mucho éxito, aunque ahí seguimos jugando un grupo de amigos (hasta que no regale un coche al ganador, creo que no voy a conseguir repercusión ;=)) y en ese momento, todavía no había nada de Integración Continua.
Sin embargo, recientemente y a raiz del artículo de Marco Vermeulen en el que hablaba de Integración Continua en CloudBees con Grails, me decidí a utilizarlo en las dos últimas aplicaciones que estoy realizando en la Universidad de Alicante (que por privacidad, no voy a poner aquí).
La integración continua de CloudBees se basa principalmente en una instancia de Jenkins (nuevamente gratuita) a la que puede agregarle tantas tareas quieras. Es lo que se conoce en CloudBees como el DEV@Cloud. Nosotros vamos crear una tarea, de tal forma que cada vez que se detecte un cambio en nuestro repositorio, se genere un nuevo archivo WAR y automáticamente se despliegue en nuestro servidor en producción. Por el momento no nos vamos a meter pruebas de cobertura, para no complicar demasiado el tema.
Pero antes de continuar, necesitamos instalar el plugin de cloudbees en nuestra aplicación Grails para facilitar el despliegue de la misma en nuestro servidor en producción. Para ello, simplemente ejecutamos en nuestro proyecto Grails el comando grails install-plugin cloud-bees que nos permitirá una serie de nuevos comandos en nuestra aplicación. Posteriormente a instalar el plugin, debemos también añadir unas entradas a nuestro conf/Config.groovy con unos datos que nos ofrece cloudbees en la página privada https://grandcentral.cloudbees.com/user/keys
cloudbees.api.url='https://api.cloudbees.com/api'
cloudbees.api.key='CLOUD_BEES_API_KEY'
cloudbees.api.secret='CLOUD_BEES_API_SECRET'
Básicamente, vamos a crear una tarea en Jenkins y la configuraremos de la siguiente forma (sólo especificaré aquellos campos donde debemos introducir información, el resto quedarán en blanco por defecto):
Datos generales
- Nombre del proyecto: ManagerT1
- Marcaremos Crear un proyecto de estilo libre
Configuración del origen del código fuente
- Marcaremos sobre Mercurial
- Repository URL: https://frangarcia:contraseña@bitbucket.org/frangarcia/managert1
- Branch: default
- Navegador del repositorio: BitBucket
- URL : https://frangarcia:contraseña@bitbucket.org/frangarcia/managert1
Disparadores de ejecuciones
- Marcaremos Consultar repositorio (SCM)
- Programador: */5 * * * *
Ejecutar
- De la lista Añadir un nuevo paso seleccionamos Build with Grails
- Grails Installation: Grails 1.3.7
- Marcaremos Force upgrade
- Targets: clean test-app war “bees-app-deploy frangarcia/managert1 0.1.${env[‘BUILD_NUMBER’]} target/managert1-0.1.war”
Acciones para ejecutar después
- Activate Chuck Norris (sí, lo tengo instalado, que pasa)
- Marcar Notificación por correo
- Destinatarios: Vuestra dirección de correo electrónico
Con esta configuración le estamos diciendo a Jenkins que cada 5 minutos compruebe si se ha producido algún cambio en el repositorio y en caso afirmativo realizará todas las operaciones especificadas en el target que terminarán por desplegar la nueva versión de nuestra aplicación, siempre y cuando todos los tests se pasen correctamente, esperando por supuesto que un maravilloso sol se pose sobre vuestra tarea en Jenkins lo que indicará que el despliegue ha ido perfectamente y que podéis seguir con el desarrollo de vuestra aplicación.
9. mayo 2011, 11:33
[2]
Este fin de semana se ha disputado (y disfrutado también diría yo) el concurso AbreDatos, que pretende fomentar la apertura de datos por parte de las administraciones públicas para un mejor aprovechamiento de los mismos.
Junto con unos amigos (@alejandro_such, @crico_aven y @perex) hemos desarrollado para dicho concurso la aplicación Dónde aparco que informa de las plazas de aparcamiento en parkings públicos en la ciudad de Alicante.
Por el momento nos hemos centrado en la ciudad de Alicante aunque ya tenemos en el horno otras ciudades como Pamplona o Reus cuyos ayuntamientos también disponen de esas información pública.
18. enero 2011, 22:10
[4]
Finalmente, ya ha salido a la luz el curso Desarrollo rápido de aplicaciones con Groovy&Grails que impartiré para el CEFIRE específico de la familia de Informática y Comunicaciones.
El curso se impartira de forma online y en él recorreremos las benevolencias tanto del lenguaje de programación Groovy como del framework para el desarrollo rápido de aplicaciones Grails.
El inicio de la inscripción es el próximo 4 de marzo y finalizará el 22 del mismo mes y está abierto a todos los profesores de secundaria y FP de la familia de Informática y Comunicaciones.
Si tienes cualquier duda con respecto al curso, no dudes en ponerte conmigo dejando un comentario en este mismo post.
1. octubre 2010, 09:43
Yo creo que nunca en ningún entorno de desarrollo fue tan sencillo proteger las llamadas AJAX que realizas en tus aplicaciones web. Imaginemos el caso que tenemos una aplicación con la típica navegación por pestañas y que todo se carga en la parte inferior de esas pestañas.
Esta característica de nuestra aplicación la vamos a implementar con una etiqueta en Grails que se llama remoteLink y que permite especificarle, entre otros parámetros, un controlador, una acción y un elemento del DOM del HTML para que lo actualice con la información correspondiente que le venga de la llamada a la acción del controlador invocado.
Por ejemplo, imagina la típica pestaña de usuarios que nos permite listarlos. Podríamos tener algo así.
Es importante recordar que para poder utilizar la llamada a la etiqueta remoteLink debemos importar por ejemplo la librería de scriptaculous.
De esta forma, cada vez que el usuario haga click en cualquiera de las opciones, la información se cargará automáticamente en el div con identificador contenido y no tenemos que recargar la página por completo. Pero, ¿que pasa si alguien intenta acceder a la URL que carga ese contenido AJAX, por ejemplo, http://localhost:8080/miapp/ajax/listarusuarios? Pues que se vería el contenido de la llamada pero totalmente fuera del contexto que nosotros queremos, lo que podría provocar algún que otro problema en nuestra aplicación.
¿Cómo podríamos evitar esto? Pues muy sencillo. En Grails tenemos el concepto de filtros que nos permiten ejecutar antes y después de llamar acciones en los controladores e incluso después de que la vista de nuestra aplicación sea generada. Estos filtros son clases normales en Groovy que se deben alojar en el directorio de configuración de nuestra aplicación y cuyo nombre debe terminar por la palabra Filters. Nosotros crearíamos un filtro llamado SeguridadFilters.groovy en el directorio grails-app/conf con el siguiente contenido:
Aunque el código es bastante sencillo de entender, voy a tratar de explicarlo un poco. En primer lugar, le estamos indicando al filtro que cualquier llamada a una acción del controlador AjaxController me la capture y me permite realizar una serie de llamadas de comprobaciones. Esa comprobación consiste en saber si la cabecera X-Requested-With de nuestra petición coincide con la cabecera que se añade en las llamadas Ajax que es XMLHttpRequest y en caso de que no coincida, redirijo al usuario a una página de error.
Sencillo, ¿no crees? Creo que he tardado más en explicarlo que en hacerlo en la aplicación en la que estoy trabajando actualmente, que en cuanto la termine os podré contar más cosas interesantes sobre ella y sobre su forma de trabajo. Sólo adelanto que trabajamos con metodologías ágiles y con gente muy dispersa geográficamente hablando.
13. septiembre 2010, 19:39
El pasado 9 de Septiembre estuve en Cheste (Valencia) en unas jornadas impartidas a profesores de formación profesional de la familia de informática y comunicaciones#.
En la presentación presenté las benevolencias de la pareja formada por Groovy&Grails y como podría mejorar la productividad de las personas que se decidan a utilizarlo. La charla anterior a la mia la realizó Lorenzo Gascón y en ella estuvo hablando sobre las pruebas unitarias y la integración continua e intenté aprovechar esta presentación para indicar que Grails es el framework perfecto para poder centrarnos en este tipo de pruebas y que el programador pueda olvidarse de determinados aspectos de configuración.
Aquí os dejo la presentación que llevé a cabo.
30. julio 2010, 15:40
[1]
Si te propusieran empezar tus vacaciones con un curso en Londres, ¿lo harías? Pues yo sí y la verdad es que no me arrepiento para nada. Tras un tiempo buscando un curso para hacer este verano, mi novia encontró una serie de cursos muy interesantes en Londres en el Kensington and Chelsea College englobados dentro de una especie de escuela de verano.
Los cursos eran muy baratos (el mio costó 118 libras) así que no nos lo pensamos mucho y reservamos el curso al mismo tiempo que el vuelo. El curso por el que opté se llamaba Adobe Illustrator: Introduction y con este esperaba unas nociones básicas de diseño gráfico con este programa de Adobe que hasta el momento no conocía.
La verdad es que puedo decir que la experiencia ha sido muy enriquecidora y a todo el mundo al que le contaba la experiencia la encantaba esta forma de estar de vacaciones, pero al mismo aprovechar para aprender. Y si encima, tengo tiempo para hacer una especie de logo para mi blog, pues mejor que mejor. Eso sí, ¿dónde estaría yo cuando Dios repartió el arte del diseño gráfico? Ahí va mi logo… espero no herir la sensibilidad de los que leen esto.
Así que ya sabes, si el próximo verano quieres venir a Londres pero no para hacer el típico curso de inglés, échale un vistazo a la web del Kensington and Chelsea College porque quizás te puedan ofrecer algo interesante.
2. julio 2010, 09:15
Una de las cosas que más me gustan en Grails es que, a partir de un esquema de clases de dominios, con un simple comando sea capaz de generar una aplicación completa. Pero, ¿cómo hace esto Grails?
Si nos movemos un poco por el núcleo de Grails encontraremos el directorio $GRAILS_HOME/src/grails/templates/scaffolding, en el que veremos una serie de archivos que son:
- Controller.groovy
- create.gsp
- edit.gsp
- list.gsp
- renderEditor.template
- show.gsp
Si echamos un vistazo rápido a estos archivos, nos daremos cuenta de que esas son las plantillas que Grails utiliza cuando hacemos un grails generate-all. Pero, ¿qué pasa si estas plantillas no nos gustan y queremos modificarlas?
Podemos optar por dos opciones. La primera de ellas supone modificar directamente y con mucho cuidado los archivos del directorio $GRAILS_HOME/src/grails/templates/scaffolding para que queden a nuestro gusto y con las necesidad de la aplicación a desarrollar. Sin embargo, esta opción tiene dos inconvenientes. El primero de ellos es que todas las aplicaciones generadas automáticamente con el scaffolding de Grails tendrán la misma apariencia, lo cual es muy probable que no queramos. Y el segundo inconveniente es que si actualizamos la versión de Grails, esas plantillas modificadas se perderán y tendremos que copiarlas de nuevo al núcleo de Grails.
La segunda opción pasa por utilizar esas mismas plantillas del núcleo de Grails pero que pasen a formar parte de la propia aplicación desarrollada. En Grails tenemos el comando grails install-templates que lo que hace básicamente es copiar esas plantillas del núcleo de Grails a un directorio propio del proyecto, en este caso $GRAILS_PROJECT/src/templates/scaffolding. Una vez estén las plantillas en ese directorio, ya podremos modificarlas a nuestro gusto. De esta forma, cuando ejecutemos un grails generate-all y Grails detecte que en ese directorio hay unas plantillas, utilizará éstas en lugar de las existentes en el núcleo de Grails.
22. junio 2010, 11:53
Cuando empecé a desarrollar ManagerT1 una de las preguntas que me hacía era, ¿dónde lo voy a alojar? La idea era muy clara. Debía ser muy económico, cuando no gratuito, así que lancé una pregunta en twitter pidiendo ayuda sobre donde alojar mi aplicación desarrollada en Grails y gracias a Rafa Alemán, que al instante me recomendó una serie de sitios para alojar la aplicación, empecé a utilizar Stax.
Stax es un claro ejemplo de lo que ahora se llama Cloud Computing y que la verdad, aunque no sea muy modesto por mi parte, llevo más de 10 años haciendo desde que empecé a trabajar.
Stax es muy sencillo y rápido de utilizar. Simplemente debes bajar y configurar su SDK propio y a partir de ahí, empezar a desplegar los archivos war de tu aplicación desde la línea de comandos. Además, desde la propia consola de Stax podemos administrar tanto la base de datos asociada a la aplicación como la propia aplicación desplegada.
En definitiva, un buen servicio disponible para todos aquellos que empiezan con Grails y no quieren gastar mucho dinero en un hosting.
« Entradas antiguas
