Tenía pendiente escribir un poco por aquí lo que dio de sí para mi la Tenerife Lan Party, que tampoco pudo ser mucho, pero me pude pasar por varias charlas y talleres; además de ver el ambientazo de jugones y otakus que había en la party.

Por la zona de gaming sólo me pasé un par de ratos por ver un poco el ambiente, y la verdad que se veía un ambiente "clásico" de party de esos que molan: 1024 puestos, ordenadores personalizados, una zona de consolas, gente jugando y bajándose todo internet, juguetes por encima de los escritorios, alguien durmiendo por ahí... y alguna muñeca hinchable, elemento que empieza a parecerme habitual en las lan parties :P

Lo que menos pude disfrutar fueron las actividades del salón manga, bien porque no me enteraba o porque coincidía con alguna charla que me interesaban en la zona profesional. Eso sí era divertido entrar al recinto y empezar a ver a muchísima gente disfrazada de sus personajes favoritos, vamos lo que llaman cosplay, cada vez que pasaba por la zona manga no podía evitar esbozar una sonrisa... la gente se lo curra muchísimo y las caracterizaciones eran espectaculares! :)

Y por supuesto donde me pegué la mayor parte del tiempo fue en la TLP+i, que viene a ser la zona profesional (vale, vale... y en la llamada sala VIP bebiendo cerveza :P). Hubo actividades que me gustaron más y otras menos:

• Minube, o cómo una idea pasa a ser una multinacional: Una charla de la historia y la trayectoria de esta empresa de internet, que estuvo bastante bien; pero al parecer hubieron algunos problemas y terminó retrasando la charla y cambiando de sala, quizás eso hizo que se resintiera el número de asistentes.
• Taller de integración continua: Yeray Darias y Fran Reyes hicieron una buena introducción de que es la integración continua y luego nos pusimos manos a la obra a trabajar con Hudson y Mercurial, una pena que hubiera poquita gente, la verdad que estuvo muy bien pensado.
• Introducción al mundo Android: En mi opinión fue demasiado introductorio, no me esperaba ver mucho código pero sí que se hablara al menos de la arquitectura de una aplicación Android.
• Taller de gráficos para Android: La verdad que aquí tuve el problema de no conocer el contenido de taller con anterioridad, porque no hubiera ido. Yo esperaba de nuevo ver código, pero resultó ser un taller de edición de gráficos con Adobe Fireworks, eso sí, pensado para ser utilizado en Android.
• Penalizaciones en Google: Sólo vi los últimos minutos porque mi charla se retrasó media hora y entonces coincidió gran parte. El rato que pude ver, a mi me resultó también un pelín introductorio, aunque bien pensado quizás el tema de penalizaciones tampoco de para mucho más.

Otras cosas que me perdí y que tenían buena pinta: un taller de Django, otro de Arduino, de Azure... Y hablando de mi charla, la asistencia fue muy baja y en mi caso no creo que fuera por el retraso :S. La verdad que no sé cuál es la razón, pero viendo que al parecer en el resto de talleres para desarrolladores tampoco tuvieron excesivo éxito seguramente será un problema del gremio. Aparte que creo que es difícil dar entidad a unas jornadas para profesionales enmarcadas dentro de una lan party, porque la imagen que se suele tener desde fuera es que "es un evento para frikis"(o sea jugones y otakus).

Y bueno, que os dejo las poquitas fotos que fui haciendo por ahí:

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.

• En el directorio de un proyecto ejecuta la versión del mismo proyecto.
• Desde otros directorios se ejecutará la versión de grails que tengamos por defecto en GRAILS_HOME.
• Y para utilizar una versión concreta, simplemente se lo debemos pasar como parámetro.

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 :P

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 :P.

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 :P

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