Arragonán

Este viernes noche después de cenar me puse a programar(o a jugar) uno de esos mini-pet-projects, lo suficientemente pequeño para no comprometerme a dedicarle más tiempo fuera del fin de semana y lo suficientemente grande para que sea algo más que un hello world. Y salvo a que tenga algún momento de aburrimiento en el que me de por mejorar o añadir alguna cosilla, así se va a quedar.

El proyecto es un agregador de twitts que hablan del Real Zaragoza(o #realzaragoza ). Y como uno no quiere hacerse de oro, no lo hace ni del Madrid ni del Barça .

Hablando ya desde el punto de vista puramente técnico, es una aplicación muy sencillita que corre en la nube de Google, osea en App Engine (aquí voy a ahorrarme varios comentarios de lo que mola la nube, además de confundirlo con internet… No voy a dar nombres… )

He utilizado un framework web ligero, hecho expresamente para correr en App Engine y muy sencillo llamado gaelyk, donde el código que escribimos es Groovy.

Gaelyk permite separar las vistas(Groovy Tempaltes) de las acciones(Groovlets). Inyecta en las acciones los elementos del SDK de GAE(datastore, memcache, mail, images…), y algunas variables para facilitar la vida y tener un código más escueto.

En mi caso he dejado la lógica de negocio en los mismos scripts de los Groovlets. Tan sólo hay tres: la home, la vista de un usuario(ej: @dani_latorre) y otro que es llamado cada 10 min para hacer una búsqueda en twitter e insertar los twitts nuevos.

Para la búsqueda de twitts, se hacen tan sólo dos peticiones cada 10 min y se parsea la respuesta atom de la búsqueda con XmlSlurper, se comprueba si no está duplicado y se crea y guarda una nueva Entity de GAE (gaelyk facilita su uso, para que sea más a la groovy).

Para recuperar lo que hemos persistido, por el momento no aporta novedades, a partir del datastore lanzaremos las queries. En el futuro es posible que surjan novedades en este apartado.

Para quien le interese conocer más detalles de gaelyk, le recomendaría pegarle una ojeada al tutorial.

Ver una presentación de Guillaume Laforge y Patrick Chanezon.

O un screencast de Pratik Patel(ojo, que a los elementos de GAE inyectados ya no se les llama loqueseaService, sólo loquesea)

Gaelyk & Groovy & Google App Engine – ATL2G from Pratik Patel on Vimeo.

Y aunque este año nos toca sufrir, aupa Zaragoza! XD

El viernes tuvo lugar el Spring2GX Day en Madrid, evento organizado por Sergi Almar junto a javaHispano y SpringSource. La verdad es que me quedé muy sorprendido por el interés que generó el evento, con más de 400 inscritos, no sé cuál sería el número de asistentes finalmente, pero se vió bastante gente durante todo el día.

Una de las cosas que más me gustan de estos eventos es tener la oportunidad de reencontrarte con viejos conocidos como Sergi, Nacho Brito, Álvaro Sánchez-Mariscal, Aitor Alzola, los paisanos de MasterD… además de con Martín y Jordi, por supuesto XD. Poner cara a gente con la que has mantenido algún contacto por internet como Tomás Lin, Raúl Expósito, Alberto Vilches o el mismo Graeme Rocher. Y por supuesto entablar conversaciones y conocer gente nueva durante el evento.

Eso sí, me quedé con mal sabor de boca por no haberme podido quedar hasta el final del evento, ya que hubo gente con la que no pude hablar o ni si quiera saludar, pero el tren de vuelta no esperaba

Algunos de los ponentes, compartido por @sergialmar

Sobre las charlas no me voy a extender, Alberto Vilches y Tomás Lin han hecho unos resúmenes del evento estupendos, además, no creo que tarden mucho en publicarse los videos del evento .

Acerca de la presentación que hicimos nosotros sobre nuestra experiencia creando Jobsket con Grails y Java, Martín publicó ayer las transparencias que utilizamos. Parece que para bastante gente resultó interesante conocer de primera mano una experiencia concreta con estas tecnologías.

Martín hablando de nuestros números, foto de @jerolba

También me quedo con la sensación de que Groovy y Grails empiezan a calar en España. Tanto por interés a nivel particular de desarrolladores, como de algunas empresas y organizaciones que lo están empezando a adoptar o que están interesadas en conocer lo que les puede aportar.

Leo en el blog de Andrew Glover, que el equipo de easyb ha publicado un pequeño videotutorial de introducción a cómo utilizar este framework de testing para hacer Behaviour Driven Development en la JVM, tanto para escribir specifications como stories.

Aquí ya toqué el tema de easyb junto a grails, eso sí, no he llegado a utilizarlo de verdad.

Otras alternativas que pueden ser interesantes para practicar BDD, y que pueden correr en la JVM son Spock, RSpec, JBehave… y unos cuantos más cuyos nombres no recuerdo

Ya he subido a github el código que añadimos el viernes en el taller de Grails(con algunos arreglillos que tenía pendientes) que hicimos en la sede de hispalinux Zaragoza.

Aún siendo un día festivo, finalmente vinieron 10 personas, y eso que se despistaron un par de la hora(mea culpa por no mandar un email de recordatorio el día de antes :S). Creo que durante las casi 3 horas que duró, llegamos a ver bastante del framework y algunos detalles de lo que puede aportar groovy en casos prácticos.

Antes de ponernos a trabajar sobre el código, también hice una pequeña presentación de introducción, para situar a la gente que no conociera demasiado acerca de groovy y grails.

Al terminar el taller estuvimos charlando de varias cosas, lo más interesante:

• Montar más talleres/charlas de temática técnica para aprender unos de otros, vernos las caras… y seguro que todo el mundo puede aportar algo o hablar sobre un tema.
• Retomar las quedadas del ZaragozaJUG, aproximadamente una vez al mes. Y aunque tenga el nombre de Java User Group, jamás se ha hablado exclusivamente de Java o programación; es simplemente una reunión de gente del gremio(sin importancia del lenguaje) para charlar sobre lo que surja alrededor de unas cervezas, y obviamente alguna vez toca hablar de temas relacionados con el desarrollo de software

El viernes 29 de Enero(día de San Valero y festivo en Zaragoza) impartiré un taller de iniciación a Grails, en la sede de Hispalinux en Zaragoza (Calle San Blás 104). El taller lo organizamos desde Jobsket con la colaboración de Hispalinux y Escuela de Groovy.

Para el taller utilizaremos como base un pequeño proyecto que he subido a github, un simple directorio de desarrolladores, para empezar con algo más que un proyecto tipo hello world. Podéis descargaros el código y pegarle una ojeada, veréis que he utilizado el plugin de acegi para el registro y autentificación de usuarios, así como image tools para las fotos de perfil.

Hay un máximo de 12 plazas para asistir al taller, así que si quieres asistir inscríbete, aunque sea un día raro para un taller de programación, nunca se sabe…

Ah! Y al terminar el taller iremos a tomar unas cervezas

Con tanto festivo de por medio, ya casi se me pasaba avisar aquí de que el equipo de jobsket en pleno, vamos a participar en el evento Spring 2GX Day, el 19 de Febrero de 2010 en la Escuela Politécnica Superior de la Universidad CEU San Pablo de Madrid.

Este es el primer evento en España que gira exclusivamente a las tecnologías relacionadas con Spring, Groovy y Grails; la asistencia es gratuita y está organizado conjuntamente por javaHispano y SpringSource.

La agenda no está completamente cerrada, pero ya se han confirmado como ponentes internacionales a Graeme Rocher y Joris Kuipers. Además de, entre otros, a Nacho Brito y Álvaro Sánchez-Mariscal de Escuela de Groovy.

En nuestro caso hablaremos de productividad con Grails y Java

Una de las características más importantes de Grails es la gran productividad que ofrece en el desarrollo, a la vez que se aprovecha toda la potencia de la plataforma Java a través de su integración con el framework Spring. Aún así, mucha gente puede estar tentada a deshechar la plataforma por estar asociada con Groovy y pensar que se trata de un todo o nada. En esta charla se mostrará como construimos Jobsket sobre Grails explotando al máximo la productividad y rapidez de desarrollo que aporta y como aprovechamos sus capacidades de integración para interactuar con todos los servicios Java que teníamos desarrollados

También quiero aprovechar a agradecer a Sergi Almar que haya contado con nosotros para participar en el evento. ¿Nos vemos en el Spring 2GX Day?

Aunque en la documentación de Grails aparece un ejemplo de como escribir un test para una acción que recibe una petición en formato XML o JSON, no lo hace de como escribir un test de una acción que genera el JSON, que tampoco es que sea precisamente complicado.

Si lo único que quisieramos probar es que, en una cadena JSON, se está devolviendo algún valor que estuvieramos esperando, podríamos utilizar el contenido que devuelve la response como una cadena(con contentAsString) y hacer alguna comprobación sobre el texto:

def response = controller.response.contentAsString
assertTrue response.contains('"name":"Gustavo Poyet"')
assertTrue response.contains('"goals":63')


Pero claro, este test es un muy ligero y no prueba demasiado. Si quisieramos probar más a fondo la respuesta(estructura, un elemento concreto de un array, etc), podríamos usar contains sobre la cadena devuelta, convertir tipos… vamos, que sería más que posible que el código del test terminara siendo infumable. Pero está disponible out of the box el converter JSON de Grails, que permite testear más a fondo fácilmente y con un código mucho más claro.

Es muy posible que si alguien se ve en la necesidad de escribir un test para una acción que devuelve un JSON, ya conozca el converter, por que es una de las alternativas que hay para hacerlo:

render object as JSON

Pues esa misma clase, tiene el paso contrario, pasar una cadena a un objeto groovy/java(JSONElement). De esta forma ya nos ahorraremos trabajo sucio y el código quedará bastante claro:

def response = controller.response.contentAsString
def responseJSON = grails.converters.JSON.parse(response)
assertNotNull responseJSON.players
assertEquals 5, responseJSON.players.size()
assertEquals 63, responseJSON.players[0].goals
assertEquals "Gustavo Poyet", responseJSON.players[0].name


Me parece muy interesante la iniciativa que se presentó el Viernes en Madrid On Rails: Escuela de Groovy, una joint venture entre ImaginaWorks y Salenda, dos de las empresas de referencia en el mundillo Groovy/Grails/Griffon/… hispano.

Pienso que es interesante que unan el esfuerzo que ya estaban haciendo por separado impartiendo charlas, talleres y seminarios para “evangelizar” acerca de las bondades que pueden aportar Groovy o Grails; y que se quieran enfocar conjuntamente en hacer llegar estas tecnologías a las empresas para tratar de ayudarles a ser más productivas(principalmente a empresas Java, obviamente).

Os dejo los videos que grabaron durante la presentación, si os interesa conocer algunas cosas del lenguaje Groovy o del framework Grails, no dejéis de verlos:

Álvaro Sánchez-Mariscal, haciendo una introducción a Groovy

Nacho Brito, acerca de los beneficios de usar Groovy

Días antes del último despliegue de Jobsket, estuve dándole vueltas a un problemilla con Grails 1.0.5 y los taglibs estándar para usar Ajax, por defecto Grails utiliza la librería javascript prototype para abstraerse de los distintos navegadores. Para que funcionen los taglibs remoteFunction, remoteLink y formRemote debemos utilizar <g:javascript library=”prototype” /> para que cargue el .js de la librería, la cuestión es que estamos utilizando algunos componentes de YahooUI(y de GrailsUI) y para aligerar el peso de las peticiones, queríamos quitar todas nuestras dependencias con prototype.

Después de refactorizar nuestro código javascript dependiente de prototype, donde hemos encontrado que hay efectos muy sencillos de implementar gracias a script.aculo.us que no lo son tanto con YahooUI(la librería Effects Widget nos ha ayudado en esta transición), nos encontramos que teniendo en el layout la declaración de qué librería deben usar para renderizar esos taglibs de Ajax, en las vistas seguía haciéndolo con el código para prototype, por lo que daba errores javascript. Para que en cada vista renderizara usando el código de YUI, debemos poner la declaración <g:javascript library=”yui” /> en cada vista, yendo con cuidado en el orden de las dependencias, ya que si hay un <g:javascript library=”yui”/> en el layout y en la vista sólo se renderizará el segundo, por lo que habría que hacer algo así:

En el layout:
<g:javascript library="yui" />
<g:layoutHead />
<yui:javascript dir="..." file="..." />
<yui:javascript dir="..." file="..." />
<g:javascript library="application" />

En la vista:
<g:javascript library="yui" />
<yui:javascript dir="..." file="..." />

En este orden se renderizarán primero las dependencias básicas de la librería YUI, luego las que necesitemos para usar componentes, y por último nuestro propio código que puede depender de algún componente.

En fin, no es una solución DRY, pero funciona para los pocos casos en los que lo necesitamos.

Otra de las soluciones de las que nos hemos ayudado, como muchos seguro que imaginaréis , es implementar una función $(), que aunque no nos dé las bondades de las extensiones DOM de prototype, nos ha ayudado a tener que cambiar mucho menos código:

function $(id){ return YAHOO.util.Dom.get(id)}

Una de las cosas de Groovy que pueden resultarnos útiles en algunos momentos, es la posibilidad de escribir pequeños scripts para automatizar alguna tarea o para escribir pequeñas utilidades. Es algo muy habitual para lenguajes como Perl o Ruby, y que tienen la ventaja de que comienza antes su ejecución por no tener que arrancar la JVM, cosa que sí necesita Groovy(que esto sea más o menos crítico, que lo decida cada uno ).

A modo de ejemplo, y basándome en el post Descargando la música de GoEar.com en debugmodeon, se me ocurrió escribir un pequeño script que hiciera prácticamente lo mismo(Extractor.groovy):

Update: Parece que el código se verá mejor en gist

import groovy.util.XmlParser
args.each{ id ->
def songs = new XmlParser().parse("http://www.goear.com/files/xmlfiles/${id[0]}/secm${id}.xml")
def song = songs.song[0]
def mp3 = song.'@path'
def name = (song.'@artist'+"_"+song.'@title').replaceAll(" ","_")
def file = new File("/path-a-un-directorio/${id}-${name}.mp3").newOutputStream()
file << new URL(mp3).openStream()
file.close()
println "${name} has been downloaded"
}

Para utilizarlo, simplemente le pasamos los identificadores de las canciones que queramos descargar, por ejemplo:

groovy Extractor.groovy cd332f6 e96ff20 acee672