Dejo por aquí mi presentación del sábado.
A ver si en estos días saco algo de tiempo y escribo sobre que tal estuvo la Lan Party
El sábado 24 a las 12:00 de la mañana, daré una charla en la Tenerife Lan Party 2010: Jobsket.com, Grails en un proyecto real.
La charla será una explicación de qué es Grails y cómo lo usamos en Jobsket, una startup pequeñita con unos recursos muuuucho menores que otras empresas, y como nos ayuda a ser una de las compañías más innovadoras tecnológicamente en el sector de empleo en internet.
También hay otras actividades muy interesantes para desarrolladores en el programa. Aunque yo voy a destacar las relacionadas con la gente de Agile-Canarias, el viernes por la mañana a las 10:00 Yeray Darias y Fran Reyes impartirán un taller de Integración continua, y seguidamente a las 12:00 Carlos Blé organiza un Code Retreat.
Leyendo la lista de correo de grails, me encuentro un pequeño script, que al menos a mi me parece muy útil para los que a veces andamos cambiando entre varias versiones de grails: grails.sh.
Sencillo y cumple su función. Al parecer funciona perfectamente en Mac, Linux y Windows con cygwin. Y para los despistados como yo, recordad darle permisos de ejecución al script 
Desde que trabajé hace algo más de un año con los cracks de Linking Paths y Rails que no tocaba Cucumber, hasta este fin de semana, que he estado haciendo algunas pruebas con el plugin grails-cucumber. Cucumber es una herramienta para hacer tests de aceptación(a la Behaviour Driven Development) escrita en Ruby que ayuda a bajar la barrera que separa a la gente de negocio o de testing(hay una leyenda urbana que dice que existen XD) con los programadores, utilizando un DSL de por medio.
Por un lado gracias a la JVM y JRuby podíamos aprovecharnos de esta interesante herramienta utilizando Ruby, y por otro, hace cosa de un año y algo que se han ido añadiendo soporte a otros lenguajes de la JVM con el proyecto cuke4duke. A día de hoy, también podemos escribir los tests con Java, Groovy, Scala, Clojure, Javascript y Ioke; cada uno que elija el lenguaje que más le guste 
. Y siguiendo con la recapitulación, a principios de primavera surgió el plugin para grails y desde entonces que tenía pendiente probarlo, pero por falta de tiempo unas veces o simplemente no acordarme otras, lo había ido retrasando .
En fin, pues después de encontrarme varios problemas para instalar y hacer funcionar el plugin, preferí hacer un fork para modificar el código bajo mis necesidades y luego hacer un pull request en github para que se pudieran aprovechar los cambios. Arreglé un problemilla con el script Gant de ejecución de cucumber con mi versión de grails(1.2.2), aproveché a actualizar las depenencias con jruby y cuke4duke a las últimas versiones y eliminé la dependencia con picocontainer.
Tras estos pasos me puse a escribir una feature como esta:
Feature: Search job offers
Scenario: Search job offers in zaragoza, we should have results
Given I'm at jobsket.es
And I write zaragoza into the seachbox
When I submit the form
Then the result should contains Promotora
And the result should contains zaragoza
Supongo que a los que conozcáis otras herramientas de BDD os resultará familiar o imaginaréis por donde van los tiros del significado de este DSL(pre-condiciones, proceso, post-condiciones). Pero como supongo que a algunos les resultará útil, ahí va una mini-explicación con mis palabras
Feature: Es la funcionalidad que vamos a testear, en este caso la búsqueda de ofertas de empleo en jobsket.
Scenario: El escenario vendría a ser una historia de usario de la funcionalidad, esto quiere decir que cada scenario sería probar una funcionalidad en un contexto distinto.
Given: El estado inicial del escenario, se pueden concatenar varios con And’s.
When: El proceso que queremos probar, también se pueden concatenar varios usando And’s… pero de inicio no tiene sentido, deberíamos probar sólo una cosa en cada escenario.
Then: Las comprobaciones para saber si el escenario se está ejecutando correctamente o no.
Bueno, una vez escritos los pasos de la feature, nos queda escribir los steps para que se ejecute el test del escenario. Como en nuestro caso queremos aplicar el test de aceptación a una interfaz web, utilizaremos el archi-conocido Selenium. El código en Groovy quedaría algo parecido a esto:
import org.openqa.selenium.By
import org.openqa.selenium.WebDriver
import org.openqa.selenium.WebElement
import org.openqa.selenium.htmlunit.HtmlUnitDriver
import static groovy.util.GroovyTestCase.*
this.metaClass.mixin(cuke4duke.GroovyDsl)
WebDriver driver
WebElement element
Before() {
driver = new HtmlUnitDriver()
}
Given(~"I'm at jobsket.es") {
driver.get("http://www.jobsket.es/home")
}
Given(~"I write (\\w+) into the seachbox") {keywords ->
element = driver.findElement(By.id("keywords"))
element.sendKeys(keywords)
}
When(~"I submit the form"){
element.submit()
}
Then(~"the result should contains (\\w+)") { someContent ->
assertFalse(-1 == driver.getPageSource().indexOf(someContent))
}
Si os fijáis, lo único raro es this.metaClass.mixin(cuke4duke.GroovyDsl), que hace la “magia” para que funcione el DSL. Los Given, When y Then se ejecutarán cuando coincida una cadena de las features, internamente funcina mediante expresiones regulares. El Before() se ejecuta antes de cada escenario, y para ser re-utilizable entre features distintas debería estar en el directorio support. El resto del código no deja de ser de selenium/webdriver normal y corriente, además de usar GroovyTest(basado en JUnit) para comprobar que se cumplen las post-condiciones.
Hasta aquí no hay diferencias con utilizar cuke4duke con Groovy sin Grails. Lo que aporta el plugin de grails es que ayuda a olvidarse de instalar jruby y la gema de cuke4duke, lo integra como herramienta de línea de comandos(ejecutando grails cucumber) y entonces tampoco es necesario configurar nada nuevo en el servidor de integracion contínua para ejecutar estos tests.
En mi opinión, todavía está lejos de la integración de Cucumber con Rails, al menos por lo que yo recuerdo. Con Rails tras cada escenario se devuelve la base de datos al mismo estado inicial, es posibl combinar comprobaciones a nivel de interfaz y a la vez acceder a los métodos de los modelos para preparar o comprobar el escenario… vamos, que ayuda a que puedan ser tests menos frágiles, que es lo negativo que se suele ver en los test de aceptación(también llamados funcionales o de sistema).
De todas formas, sigue siendo un plugin muy interesante por poder conocer en un lenguaje cercano al natural si un escenario está en un estado aceptable o no, y si hay gente no técnica de por medio puede ser una herramienta perfecta para acercar mundos.
Ala! Fin del tocho! XD
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
By @mraible
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:
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
Subscribe in a reader
