Arragonán

Ayer, unas horas después de leer el post de @kinisoftware, Modelos de dominio anémicos, POJOs y demás seres del lugar, me encontré una discusión en twitter a varias bandas(sitio que no es ni mucho menos el mejor para debates así… sigo echando de menos las conversaciones/discusiones que teníamos entre una micro-comunidad en jaiku, pero ese es otro tema) sobre el anti-patrón del modelo anémico.

Hablando del tema vi tuits de @kinisoftware, @albertovilches, @jmbeas, @genezeta, @jneira, @jlhuertas… y fijo que me pierdo a algunos más de gente que no sigo. Como es habitual, yo no me mojé demasiado . Por un lado soy un chaquetero, y por otro esta gente sabe mucho y me pueden dejar a la altura del betún en cualquier momento

Por resumir un poco esto del modelo anémico, viene a ser que el modelo está implementado con DTOs, cuya única responsabilidad es encapsular datos para transferirlos a otra parte(ej: de una base de datos a la vista de una app). Cosa que creo aún es bastante habitual en muchas aplicaciones que utilizan ORMs o similares(llámense Hibernate, ActiveRecord, GORM, Doctrine, MyBatis… o soluciones home-made)… Pues resulta que eso es un anti-patrón, más que nada porque por hacer eso probablemente estemos rompiendo el paradigma de programación orientada a objetos.

Recuerdo cuando me enseñaban POO(con Java) que una clase Rectangulo tenía un atributo base y otro altura con sus getters y setters y un método calculaArea() que devolvía su área(vale, y probablemente extendería de Poligono ). Vamos, que se supone que un objeto combina estado y comportamiento, por eso veo por ejemplo hablando una clase de dominio Noticia que tiene un atributo propietario puede tener un método del estilo:

public boolean esPropiedadDe(Usuario usuario){
   return propietario.equals(usuario)
}

La cosa es que en los frameworks MVC ese tipo de lógica la he visto(y sí, también la he puesto! XD) en la capa del controlador, cuando se supone que es una capa que debe ser lo más tonta posible en cuanto a lógica de negocio (o ya puestos, tonta del todo , skinny controller-fat model), y con la moda de las capas de servicio con los Spring & co(Grails como una de esas víctimas colaterales) ha resultado que esa lógica se pone en la capa de servicio para evitar ponerla en el controlador y seguir dejando a las clases de dominio como DTOs(o modelos anémicos).

¿Eso quiere decir que siempre pongo la lógica en las clases de dominio?
No, pero procuro hacerlo siempre que puedo identificar responsabilidades en una clase del dominio. Aún así, en ocasiones me encuentro con lógica que pasa a alguna clase en la capa de servicio, principalmente porque no consigo identificar qué clase debería ser la responsable, afecte a varias clases de dominio o simplemente sean comportamientos que no tienen que ver con la lógica de negocio pura y dura. Por supuesto teniendo en cuenta que esas decisiones sean cosa mía

De todas formas, ya se sabe que en esto del desarrollo de software todo depende de muchos factores(principalmente de los gustos y costumbres de los desarrolladores) y nadie tiene LA respuesta. Eso es lo que hace más interesante el mundillo, ¿o no?

Viñeta de Geek And Poke, como no

PD: Disculpad que os tengáis que imaginar parte del código y el spanglish rarillo en los ejemplos, el código de verdad hace tiempo que procuro escribirlo siempre en inglés

En estos momentos me encuentro enfrentándome a un problema en el que tengo que persistir una cantidad de datos realmente grande, con diferentes fuentes de esos datos, en cada fuente los datos pueden ser “de su padre y de su madre”, el sistema debe escalar lo más fácilmente posible y se deben poder hacer búsquedas por diferentes criterios.

Una vez puestos en contexto a grandes rasgos, os diré que vi que posiblemente la mejor opción para resolver el problema era utilizar una base de datos orientada a documento, un tipo de base de datos de las llamadas NoSQL.

Tras andar estudiando CouchDB y MongoDB, me decanté por la segunda. ¿Por qué?: La principal razón porque MongoDB, además de MapReduce, permite lanzar consultas dinámicas al estilo relacional. En la misma web de MongoDB hay una comparativa muy interesante de diferencias y similitudes con CouchDB.

En fin, que he ido recopilando algunas lecturas que me han resultado interesantes para romper el hielo(eso sí, principalmente para trabajar con Java):

• Tutorial: MongoDB in Java
• Learning Mongodb y Still learning MongoDB
• Java Tutorial – MongoDB (del driver oficial)
• MongoDB: A NoSQL datastore with (all the right) RDBMS moves
• MongoDB made more Groovy

Tengo que decir también que hay un par de plugins para Grails, pero por ahora he pasado de ellos. No he visto que aporten mucho más que un mapeo objeto-documento para las clases de dominio, y eso haría que perdiese esa flexibilidad que necesito.

En fin, trataré ir contando algo de como van mis progresos

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

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