Oferta de trabajo: Desarrollador web con JS/Grails/Clojure (inglés)

Al Observatorio nos llega una nueva oferta de trabajo para Grails, esta vez en Greenville, South Carolina, USA.

Más información sobre M33 Integrated Solutions: Web Developer – JavaScript/Grails/Clojure.

Y otro artículo general sobre Grails (inglés)

Aunque se trata de un simple resumen de la tecnología, siempre es interesante conocer la visión que cada desarrollador tiene acerca de Grails.

Más información sobre Grails (traducido al español).

Curso: Groovy & Grails desarrollo rápido de aplicaciones

Nuevo curso sobre Groovy & Grails impartido en la Universidad de Alicante en Septiembre. Ya está abierto el plazo para inscribiros. Aquí os dejamos el enlace al evento con toda la información.

Llega el Mundial a Grails: IRO Foot

La fiebre del mundial también ha llegado a Grails. Aquí os dejamos una web desarrollada con Grails con los resultados y noticias del mundial.

Más información sobre IRO Foot.

La eterna discusión: ¿qué IDE es el más completo para Grails?

Desde el blog del Ayto. de Vitoria-Gasteiz nos llega un nuevo blog dentro de su experiencia con el uso de la tecnología Grails y herramientas asociadas, esta vez referente al uso de IDEs para su desarrollo.

Más información sobre IDE - Grails.

¿Qué hay de nuevo en Spock 0.4? (inglés)

Aunque Grails de forma nativa proporciona una API muy completa para nuestras pruebas unitarias, así como la posibilidad de 'mockear' nuestros objetos de las clases del dominio, en ciertas ocasiones no es suficiente y tenemos que recurrir a otras herramientas que extienden todavía más estas posibilidades. Un ejemplo podría ser la falta de soporte de 'named queries' en las pruebas unitarias.

Una de estas herramientas para Groovy es Spock, un magnífico framework para 'simular' objetos cuando realizamos nuestras pruebas unitarias. Con la nueva liberación 0.4, las posibilidades son aún mayores, y en este artículo se nos dan algunos trucos y consejos.

Más información sobre What's New In Spock 0.4? Episode 2: Better Mocking (traducido al español).

Retornar parte de la clase del dominio en JSON (inglés)

Con el auge de REST, muchos desarrolladores utilizan Grails para servir peticiones JSON. En estos casos, podemos convertir cualquier instancia de cualquier clase del dominio de nuestra aplicación a formato JSON de forma nativa en Grails; sin embargo, por defecto, todos los campos de la clase se incluyen en la respuesta, y puede que esta funcionalidad no sea siempre la deseada. Pero como siempre, Grails nos permite indicar sólo aquellos campos que queremos incluir en la respuesta JSON utilizando un mapa con las claves: 'include', para los que queremos incluir, y 'exclude', para los que no, exactamente igual que podemos hacer con el 'data binding' en un controlador.

Más información sobre Return partial Domain class (traducido al español).

Interfaz REST liberado para la aplicación de contabilidad de TLC (inglés)

Hace algunas semanas os anunciábamos en el Observatorio la disponibilidad de una aplicación de contabilidad desarrollada íntegramente en Grails: Wholly Grails. Ahora volvemos a dicha aplicación para anunciar la disponibilidad de un interfaz REST para poder interactuar con la aplicación.

Más información sobre REST interface released for TLC accounting system (traducido al español).

Injectando un 'bean' en un controlador Grails sin 'auto-wiring' (inglés)

Grails está basado en Spring, y por ello, por defecto, utiliza el mecanismo de 'auto-wiring' para inyectar las dependencias tanto en controladores, como servicios, como trabajos Quartz, etc. Sin embargo, en ocasiones este comportamiento por defecto puede que encaje con el resultado que pretendemos obtener, y aquí es cuando podemos 'bajar' a Spring e indicarle mediante configuración cómo queremos que se resuelvan las dependencias. Imaginad, por ejemplo, el caso en que un controlador Grails utiliza dos implementaciones distintas del mismo servicio.

Más información sobre Injecting a bean into a Grails controller without using auto-wiring (traducido al español).

Configurando InetlliJ para depurar con Grails/Spring/Acegi (inglés)

Cuando los 'logs' no son suficientes para comprender por qué un determinado trozo de código no está funcionando como esperábamos, la posibilidad de poder depurar directamente contra el código fuente de cualquiera de las APIs que estamos utilizando en nuestra aplicación es una gran ventaja. Sin embargo, dependiendo del entorno de trabajo, no siempre es fácil configurar nuestro editor para que sepa localizar los códigos fuente. Aquí os dejamos un pequeño artículo de cómo configurar el IDE IntelliJ para que podamos depurar nuestras aplicaciones.

Más información sobre Setting up IntelliJ to Debug Into Grails / Spring / Acegi 3rd Party Source (traducido al español).