Crónica de la GR8conf 2010 en Copenhague

Los pasados 19 y 20 de Mayo tuve la oportunidad de asistir en representación de Paradigma Tecnológico, la empresa donde trabajo, a la GR8 European Conf en Copenhague, la versión europea de la GR8, una conferencia que trata exclusivamente sobre Groovy y otras tecnologías creadas con este lenguaje como Grails, Griffon y Gradle.

El recinto de acogida fue la IT University, ahí pasamos todo el día, horas de la comida y cena incluidas. Pese a que la wifi no resistió todo el tráfico de los asistentes, en general diré que el sitio, la organización y la comida fueron bastante buenos. Además, al volcán islandés Eyjafjalla le debe gustar también Groovy, porque esa semana nos dio a todos los asistentes un respiro y se pudo volar con normalidad a la ciudad.

Fueron solo dos días y muchas ponencias, así que los organizadores tuvieron que ingeniárselas para que diera tiempo a todo, dando como resultado una agenda bastante apretada: incluso a la hora de comer había una pequeña charla de 20 minutos sobre algún tema. Además, el primer día hubo Hackergarten night coding, así que los que no tuvimos suficiente con las charlas (o sea, todos), nos pudimos quedar hasta la hora que quisimos dentro del recinto para programar algún plugin (o lo que sea) con alguno de los líderes de Groovy, Grails, Gradle o Griffon. Más adelante comentaré la experiencia en el Hackergarten, pero en resumen diré que fue de lo más interesante, aunque agotador (acabámos a las once la noche).

Pero lo mejor de la conferencia ha sido, sin duda, que el nivel técnico de todos los ponentes (y del público también, dadas las preguntas que se hacían durante las charlas) ha sido muy muy alto. Supongo que tener que viajar hasta Copenhague a una conferencia que trata sobre un tema tan especializado como el ecosistema Groovy, ha hecho que la proporción de expertos respecto a gente “normal” haya sido más acusada.

Más información:

Groovy on the way to success

En esta primera ponencia, Philippe Delebarre y Raffaele Cigni, de la Oficina Europea de Patentes (EPO) nos cuentan su problemática situación actual y como la han solucionado. Su oficina gestiona actualmente más de 140.000 patentes al año, y su sistema informático es una gran aplicación host basada en Cobol muy antigua que se está quedando obsoleta: cada vez hay más patentes que tramitar y sus procesos son cada vez más lentos. Por dos veces han intentado migrar sus sistemas, pero sin éxito alguno. Primero un ET y después un ESB: las dos soluciones o eran muy caras, o muy difíciles de mantener, con grandes ficheros XML de configuración, etc.
Su solución final ha consistido en la elaboración de un lenguaje propio de dominio (DSL) al que han bautizado como DFP (data flow process) con el que crean procesos. Es un lenguaje muy simple, intuitivo, fácil de usar y de mantener. A su alrededor, han creado todo una plataforma que es capaz de leer y procesar estos ficheros DFP, por lo que su trabajo de mantenimiento consiste en crear nuevos procesos o modificar los existentes, y desplegarlos en la plataforma que han diseñado, responsable de procesar todos sus DFP. Con esto han conseguido una forma barata de migrar su sistema aumentando la velocidad de procesamiento de las patentes: ahora están listas en varios días en vez de semanas (hay que tener en cuenta que una patente suelen requerir correcciones manuales, pero el sistema desarrollado contempla el rechazar alguna patente si le falta algún dato, etc).

Esquema de la plataforma de procesamiento de patentes

Mi conclusión tras ver la ponencia es que no solo de Grails viven las aplicaciones empresariales: Groovy es un excelente lenguaje de scripting que, junto con un DSL bien diseñado, puede agilizar la creación y mantenimiento de aplicaciones de procesamiento automatizado de datos.

Quickie: Grails update

En una breve exposición de apenas 20 minutos, Graeme Rocher nos cuenta el estado de Grails en la actualidad y nos cita algunos sitios importantes desarrollado con este framework como la tienda online Walmart, una aplicación 2.0 para la gestion de tareas llamada Manymoon, la página de la universidad Northwestern, y un buscador de ¡baños públicos! llamado Sitorsquat.com, entre otros. Como nota destacable, nos cuenta que se ha mejorado el soporte de Grails para Eclipse en el nuevo SpringSource Tool y nos adelanta su roadmap:

Grails 1.2 ha mejorado considerablemente su rendimiento

  • Mejoras sustanciales en el rendimiento
  • Pluggable test framework: poder insertar nuevos framework de test como pluggins
  • Global constraints/mappings: constraints globales que afectan a todos los objetos de dominio
  • Soporte Gorm para NoSQL
  • Soporte para despliegue de aplicaciones cloud
  • Integración con Gemfire RabbitMQ

Y para Grails 2 en septiembre con grandes cambios.

  • Mejorar la integración con aplicaciones ricas de escritorio (RIA)
  • Mejoras en el sistema de plugins (basado en Osgi), despliegue de plugins en caliente
  • Múltiples datasources (¡bien!)
  • Database migration e ingeniería inversa (creación de clases de dominio a partir del modelo de datos)
  • Arranque más rápido (supongo que por los problemas que tiene Grails al desplegarse sobre Google App Engine)

En resumen, Graeme nos cuenta que Grails 2 va a ser muy diferente y que el cambio mayor de versión esta justificado. Esperamos ansiosos su salida, que estima entre septiembre y final de año (la verdad es que no recuerdo bien la fecha).

Grails Internals – Demystifying the Magic

Grame continúa después con una presentación bastante extensa (y que me es imposible resumir) sobre como funciona el arranque de Grails, los class loaders implicados, el BootStrap, etc. Acaba con la creación de una aplicación de ejemplo básico y la depuración, línea a línea, del código de Grails al recibir una petición http: para ello inserta un par (bueno, unos cuantos al final) de puntos de ruptura en clases clave del código, como GrailsWebRequestFIlter y UrlMappingsFilter, intentando explicar todos los pasos y procesos que toman parte de la petición. Muy interesante e instructivo.

Graeme explicando la secuencia de una petición HTTP en Grails

Gaelyk, a lightweight Groovy toolkit for Google App Engine

Durante la comida, Guillaume Laforge, en unos breves 20 minutos, nos resume el funcionamiento de Gaelyk, un framework ligero para el desarrollo de aplicaciones Groovy para Google App Engine. Gaelyk no es más que un conjunto de clases que añaden dinámicamente a los Groovlets y Groovy Templates los atributos y métodos necesarios para acceder cómodamente a las APIs que nos ofrece Google para acceder a sus servicios de Xmpp, BigTable (memcache, blob y datastore), email, images, etc. La verdad es que esta presentación me pilló comiendo, así que no puedo contar más.

Flying with Griffon

La presentación de Andres Almiray, el creador de Griffon consiste primero en una introducción donde explica qué es y cómo funciona Griffon y después en el desarrollo, en directo, de una pequeña aplicación de ejemplo en Swing con Griffon.

Griffon es un framework de desarrollo, muy parecido en concepto y arquitectura a Grails (de hecho, comparten código), para la elaboración de aplicaciones MVC con Swing, Groovy y Java. Al igual que Grails, posee un comando para la creación de proyectos, generación de clases, empaquetado de la aplicación e instalación de plugins. De la misma manera que lo hace Grails, el tener por separado controladores, modelos y vistas hace que el desarrollo sea mucho más cómodo y mejor estructurado. Sobre todo para la elaboración de las vistas, donde existe un DSL propio con el que generar todo el código Swing, pero sin tener que sufrir escribiéndolo. Además, podemos utilizar la anotación @Bindable en nuestros beans para que cualquier modificación en los atributos del modelo se transmitan directamente a las vistas y viceversa, sin tener que programar manualmente toda la gestión de estos eventos del patrón Obverser de Swing, con sus event listeners y demás parafernalia. Por supuesto, esto solo es posible gracias a Groovy sus transformaciones AST.

Andres preparándose para dejar al público atónito...

Esta presentación fue, para mí, una de las mejores, y ahora voy a explicar por qué: hace más de un año que uso Flex y Adobe Air en mi trabajo diario para hacer aplicaciones de escritorio. Y estoy muy contento, tanto por el lenguaje de desarrollo como por los resultados finales obtenidos. Swing siempre me ha parecido la parte más aspera de Java: aunque use un IDE para la elaboración de ventanas y componentes, la cantidad de código necesaria para construir una aplicación es simplemente desproporcionada, lo que hace que programar Swing acabe siendo una tarea poco agradable. Y esta ha sido la principal razón por la que, hace ya más de un año, cuando tuvimos que decidir qué tecnología usar para crear una aplicación de escritorio para un proyecto, nos hayamos decantado por Flex y Adobe Air en vez de Java y Swing, pese a ser Java el lenguaje con el que más cómodo nos encontramos (simplemente porque es el que más usamos a diario) y haber sido Flex/Adobe Air, en su momento, nuevos para nosotros.

Este precedente me sirvió para apreciar más todo el trabajo que ahorra Griffon en el desarrollo de aplicaciones Swing en comparación con Java. La prueba de ello fue cuando Andres empezó a hacer su demo, la programación de una aplicación con Griffon. Esta aplicación consistía en un pequeño cliente que se conectaba a una cuenta de Twitter (usando login y password) para listar todos sus followers. Todo programado desde cero, paso a paso y en directo, editando el código, compilando, corrigiendo errores y probando. El resultado final no tenía más de 10 clases y el código era compacto y fácil de entender. Había creado una aplicación desde cero, con una estructura básica coherente, perfectamente funcional, y ejecutable desde un Java Web Start, un applet o aplicación de escritorio. Hacer lo mismo con Java habría llevado, sin duda, muchísimo más tiempo.

Por ejemplo, esto es una vista Swing hecha con Griffon:

application(title:'gr8', pack:true, locationByPlatform:true {
    busyComponent(busy: bind{ model.busy }) {
	panel {
	   borderLayout()
	   panel(constraints: NORTH) {
	      gridLayout(rows: 3, cols: 2)
	      label 'Username:'
	      textField columns: 20, text: bind('username', target: model)
	      label ' Password:'
	      passwordField columns: 20, text: bind('password', target: model)
	      label ''
	      button 'Login', actionPerformed: controller.login
	   }
	   scrollPane(constraints: CENTER) {
	        table {
	            tableFormat = defaultTableFormat(columnNames: ['Id', 'Name'])
	            eventTableModel(source: model.followers, format: tableFormat)
	            installTableComparatorChooser(source: model.followers)
	        }
	    }
	}
    }
}

Para acabar la presentación, Andres anunció en directo la liberación de la versión 0.3.1 de Griffon, donde incluye, principalmente, una guía completa y documentación de referencia para el programador: http://dist.codehaus.org/griffon/guide

Mi conclusión es, tras acabar la demo, que Griffon es al desarrollo de aplicaciones de escritorio, lo que Grails es al desarrollo web: una manera de hacer lo mismo, pero más fácil, muchísimo más rápido, con menos código (y errores) y, sin duda, mucho más divertido.

  • Presentación de la ponencia de Griffon en Slideshare.
  • Descarga el código fuente de Gritter (197kb), la aplicación desarrollada por Andrés durante la conferencia.

El post acaba aquí, pero hubo muchas más ponencias interesantes, así que… continuará…

One thought on “Crónica de la GR8conf 2010 en Copenhague

  1. Pintaza de conferencia !!!

    A ver si te curras un segundo post con los insights de la conferencia, las conversaciones de pasillo, los cotilleos y detalles organizativos.

    Estoy especialmente interesado en conocer si la comida era tan vomitiva como la de la javaOne (es difícil).

Comments are closed.