Artículos en Crónicas

Abierto el registro de Greach

PostedEn Crónicas, Groovy     Comentarios Comments Off
Sep
10

El 1 de septiembre se abrió el registro de Greach, un evento que estoy organizando, dedicado exclusivamente al lenguaje Groovy y a todos los frameworks y herramientas que se han creado a su alrededor. Se celebrará el próximo viernes 4 de Noviembre en la universidad San Pablo CEU de Madrid. De un solo día de duración, será corto pero intenso: dos tracks llenos de charlas y talleres sobre Groovy, Grails y Griffon, con primeras figuras nacionales e internacionales como Guillaume Laforge y Andrés Almiray (líderes del proyecto Groovy y Griffon, respectivamente).

Podéis visitar la web de Greach para conocer el programa y horario (todavía no definitivo) de las charlas, conocer un poco más a los sponsors y ver la localización del evento. Algunos speakers españoles ya han confirmado el tema de sus charlas y tenemos temas tan interesantes como programación funcional con Groovy, un taller de Koans de metaprogramación y MongoDB sobre Grails. Todavía quedan por confirmar nuevos speakers y nuevas ponencias.

Crónica de la Grails Exchange 2010 en Londres (parte 2)

PostedEn Crónicas, Groovy     Comentarios Comments Off
Dec
27

Ha pasado más de una semana desde que finalizó la Grails Exchange. Tenía el post a medio escribir desde el sábado que tenía que haber vuelto a Madrid, pero los aeropuertos de Londres no han funcionado con normalidad y hemos sido muchos los que nos hemos quedado casi hasta nochebuena allí atrapados. Yo al menos tuve suerte, el miércoles 22, y tras dos intentos fallidos, mi avión despegó y pude volver a tiempo, aunque me consta que ese mismo día hubo bastantes cancelaciones. Tras pasada nochebuena y navidad, por fin he tenido algo tiempo para terminar esta crónica de la Grails Exchange.

El segundo día de la Grails Exchange estuvo dedicado casi en exclusiva a Grails (ver la crónica del primer día aquí), fue un día muy productivo, con charlas muy interesantes y grandes figuras. A continuación un resumen de las ponencias más destacadas:

Keynote – In Search of the Grail of Developer Productivity

A Grails Roadmap Update

En esta keynote, Graeme Rocher comienza contando un poco la historia de Grails y cita algunos sitios interesantes desarrollados con esta herramienta como eHarmony, Northwestern Memorial Hospital y Hashable. Acto seguido pasa a hacer una demostración en vivo sobre el uso de Spring Insight con Grails desde SpringSource Tool. En este mismo blog ya hemos hablado antes sobre Spring Insight (posts y seminarios), así que es gratificante ver como Graeme apuesta por esta herramienta también para monitorizar aplicaciones Grails, ya que a nosotros también nos parece una herramienta muy buena de análisis y profilling.

Después pasa a comentar las novedades que lleva la versión 1.3 (la versión 1.3.6 fue liberada el miércoles, hacía tan solo 3 días) que son Groovy 1.7, JUnit 4, chaining named criteria y soporte para repositorios Maven. Nos cuenta que ha estado bastante ocupado trabajando en los plugins NoSQL para MondoDB, RedisRiak y Gemfire y una gran cantidad de nuevos módulos de autenticación para Spring Security. Y cita las novedades para Grails 1.4:

  • Actualización a Groovy 1.8, Hibernate 3.6 y Spring 3.1
  • Mejoras en el autocargado de clases al modificarlas en caliente (nos dice que no le gusta como está y que tiene que mejorarlo)
  • Nuevas funcionalidades para Gorm como migraciones, ingeniería inversa (que ya está disponible como plugin), herencia abstracta y un mejor soporte para tests.
  • Mejor manejo de los recursos estáticos (más adelante hay una ponencia de Marc Palmer sobre esto)
  • Cambio de Prototype por jQuery como framework Javascript por defecto.

Después continúa con la demo en vivo sobre el uso de criteria querys y named querys funcionando completamente con el plugin NoSQL inconsequential (usando un ConcurrentHashMap)

Finalmente comenta las nuevas mejoras que tendrá Grails 2.0, que saldrá en diciembre de 2011 como Gorm for REST (al salvar una clase de dominio con save(), invoca una llamada http PUT, y al leer hace un GET, etc. de manera transparente, al estilo como lo hace Ruby on Rails) y Scaffolding con Ajax con una nueva taglib para scaffolding.

Ver vídeo de la ponencia.

What’s hot in Grails land

En esta ponencia Peter Ledbrook hace un repaso a los plugins más interesantes y populares de Grails. Entre ellos cita:

  • Resources plugin, que se puede usar en combinación con zipped resources y cached resources (los tres del mismo autor, Marc Palmer, que después hará una ponencia específica sobre estos plugins) y cuyas características principales son:
    • Empaquetar recursos estaticos en modulos reutilizables entre GSPs.
    • Cachear y zipear los recursos para servir paginas más rápido.
    • Identificadores únicos de recursos a partir de su hash.
    • Añadir cache headers a los recursos estaticos. YSlow.
  • Spring Cache plugin que permite:
    • Cache de contenidos. Podemos usar en nuestros controladores las anotaciones @Cacheable(“x”) para activar la cache y @CacheFlush(“x”) para eliminarla (en un save por ejemplo)
    • Cache de metodos de servicios.
    • Cache de fragmentos de paginas, de taglibs, control de cabeceras.
  • Markdown plugin: un taglib que permite utilizar la sintaxis Wiki en tus gsps.
  • Bean Fields plugin: generación simplificada de formularios (obtiene automáticamente el tipo de input según el tipo del dato, visualiza los errores automáticamente):
    <bean:withBean beanName="form">
    <bean:field property="firstName"/>
    <bean:field property="lastName"/>
    <bean:field property="company"/>
    <bean:field property="email"/>
    </bean:withBean>
  • Reskin plugin que permite usar HTML5
  • Melody, un plugin de monitorización
  • Pretty time, un etiqueta  <prettytime:display date="${someDate}" /> que genera “right now”, “2 days ago”, or “3 months from now”
  • Itunes service, un plugin que se conecta a los servicios web de Apple de Itunes y permite hacer búsquedas.

Ver vídeo de la ponencia.

Design for simplicity

Glenn Saqui y Dave Scott, de sky.com, una compañía de entretenimiento y broadcasting de vídeo, nos cuentan la arquitectura de sus 7 portales que han realizado integramente con Grails y Groovy (98% de código es Groovy, 2% Java). Incluso los scripts de administración están escritos en Groovy. Tienen 6 millones de hits al día y más de 30 editores trabajando constantemente para añadir contenidos.
Solo usan un único war para todos sus portales, delegan los diferencias de configuración en archivos externos. Cachean todo lo posible, incluso cachean contenidos estáticos en los propios ordenadores clientes de los editores, mientras que para datos públicos, delegan los recursos en CDNs. Tienen pruebas funcionales de prácticamente todo y su primera regla es que todo sea lo más simple posible. Una ponencia que demuestra con un ejemplo real que el uso de Grails en servidor no penaliza (yo mismo defiendo esa idea en “¿se puede realizar una GRAN aplicación con Groovy y Grails?“)

Ver vídeo de la ponencia.

Introducing the new static resources framework for Grails

Aquí Marc Palmer, commiter de Grails, creador de Wecemm (un CMS  que se puede usar como aplicación independiente, o como plugin Grails para tu proyecto) y creador de los plugin static-resource, cached-resources y zipped-resources nos cuenta en que consisten estos tres plugins, que pasarán a formar parte del core de Grails en siguientes versiones.
Statis-resources es un plugin que permite definir los recursos (imagenes, css, javascript) de nuestras aplicaciones Grails en módulos, de manera que estos luego puedan ser usados desde nuestras páginas y layouts GSP. Soluciona el problema que supone que tanto la aplicación principal como cada uno de los plugins que esta usa posean cada uno sus propios css, javascript y recursos, dando lugar a lo que el llama “Optimizacion hell”: ¿quién (tu aplicación, el plugin A, el plugin B) es el que debe incluir los recursos y en que orden? Además, con este plugin podemos empaquetar nuestros estáticos fuera del archivo WAR para que puedan ser servidos desde un Apache o cualquier otro servidor HTTP, de esta manera podemos liberar a nuestro servidor de aplicaciones (o contenedor de Servlets) de la pesada tarea que es servir estáticos. Durante la ponencia, Marc muestra como utilizar y sacarle provecho, paso a paso, todos estos tres plugins.

Ver vídeo de la ponencia.

Grails Sans SQL

Graeme nos cuenta en esta ponencia que el futuro de las aplicaciones Web tiende a usar otros sistemas de almacenamiento distintos a las bases de datos relacionales. Grails incorpora de serie el acceso a un gran número de bases de datos diferentes con Gorm, gracias al uso que hace de Hibernate por detrás, así que es necesario llegar a otro tipos de manera de guardar nuestros datos que no sean tablas, relaciones, columnas y filas. El reto de Graeme es que los programadores de Grails puedan usar todas estas nuevas bases de datos NoSQL sin usar Apis específicas, solo con Gorm.
Primero hace un repaso sobre los diferentes tipos de bases de datos NoSQL:

  1. Document Stores (CouchDb y MongoDb)
  2. Column Family Stores (Cassandra, Bigtable)
  3. Grapth Tree (Neo4J, JCR)
  4. Map structures (Redis, Riak, Gemfire)

Y nos presenta Inconsequential: una abstracción sobre Gorm que soporta Redis, Gemfire, Riak, MongoDb y ConcurrentHashMap (actualmente está trabajando en Cassandra, CouchDb y JCR) y pasa a la práctica con una demo de Gorm con Redis: creando un proyecto desde cero y arrancando un servidor local de Redis (arranque instantáneo) y una consola para consultar el contenido de la “base de datos”. Es necesario indicar en el mapping de nuestras clases de dominio los campos por los que vamos a realizar consultas con index:true. Redis es un sistema de almacenamiento de pares clave/valor y permite almacenar tipos de datos ricos: strings, lists, sets y sorted set. Los datos se van guardando en memoria y posteriormente se van volcando a disco. Permite replicación master/slave replicación y tiene un rendimiento excelente (+100.000 lecturas/escrituras por segundo). La demo consiste en operaciones de creación, modificación, búsqueda y borrados sobre Redis usando solamente clases de domínio y Gorm.

La segunda demo consiste en realizar una aplicación en Grails con scaffolding usando Gemfire. Como nota adicional en este motor de base de datos NoSQL, es posible utilizar el espacio de nombres cq dentro de todas las clases de dominio con el que hacer búsquedas contínuas. Este tipo de búsquedas se realizan en background y ejecutan un Closure como evento cada vez que se encuentran valores definidos en la propia consulta (al guardar o sincronizar entre servidores). La tercera y última demo consiste en reutilizar la aplicación sin modificar el código simplemente desinstalando el plugin de Gemfire, instalando el de MongoDb y reiniciando. La conclusión final es que el soporte para base de datos NoSQL en Grails está bastante avanzado, al menos de manera básica, para un número considerable de sistemas y que poco a poco se irán añadiendo más.

Crónica de la Grails Exchange 2010 en Londres

PostedEn Crónicas, Groovy     Comentarios Comments Off
Dec
17

Durante hoy jueves 16 y mañana 17 se está celebrando en Londres la Grails Exchange 2010.

Dos días llenos de ponencias interesantes en el edificio de Skillmater, donde se puede ver en directo hablar a las primeras figuras del ecosistema Groovy y hacer contactos interesantes.

Gran ambiente, comida regular (lo siento, todos sabemos que el Reino Unido no es famoso por su gastronomía) y una conexión wi-fi estupenda es una buena definición de la Grails Exchange en pocas palabras. Para las ponencias me tendré que alargar un poco más, pues fueron muchas y todas bastante interesantes. Aquí va un resumen de las principales:

Keynote – Groovy, State of the Union

Como ceremonia de apertura, Guillaume Laforge hace una introducción a la historia de Groovy. Comentando un gráfico con la evolución del número de descargas de Groovy al mes, nos enseña como la adquisición de G2One y la liberación de la versión 1.6 de Groovy tuvieron los mayores picos de descargas. Pero el record sin duda han sido las 185000 descargas en un solo mes durante la salida de Groovy 1.7. Toda esta evolución da bastante confianza y presagia un gran futuro para Groovy y todo su ecosistema para las siguientes versiones.

Después repasa las mejoras que se han añadido a la versión 1.7 como:

  • Multiple asignements (a,b) = [b,a] para hacer swapping, por ejemplo.
  • Soporte para clases anónimas y anidadas. Aunque con algunas pequeñas mejoras, como que las clases anónimas no necesitan que las variables externas sean final y la creación automáticas de clases o interfaces con un solo método a partir de Closures.
  • Los power asserts, gracias al creador de Spock.
  • Anotaciones en imports, packages y la posibilidad de incluir Closures como parámetros en cualquier anotación.
  • Grab, que permite la descarga de clases desde repositorios de jars, como Maven, durante la compilación y ejecución de clases o scripts.
  • La personalización de la coerción a boolean con solo sobreescribir el método boolean asBoolean()

Después explica cual es el plan para las siguientes versiones:

  • Optimización en el rendimiento.
  • Soporte para JSON nativo.
  • GContracts: @Invariant, @Requires, @Ensures
  • Closure composition, crear closures con otros. Por ejemplo, closure1 << closure2 supone que una llamada a closure1(x), se ejecute realmente closure1(closure2(x))
  • Closure memoization o caché de resultados para Closures. Dado un mismo conjunto de parámetros de entrada, guarda la salida y la devuelve sin ejecutar otra vez el codigo.
  • Trampoline, idea sacada de los lenguajes funcionales (Clojure y Scala tambien la tienen), sirve para evitar los StackOverflowException en las llamadas recursivas a closures y métodos cuando se llaman demasiadas veces (más información sobre trampoline en el blog de Václav Pech)
  • Nuevas transformaciones AST: @Log, @Field, @PackageScope, @InheritConstructor, @IndexedProperties, @AutoClone, @AutoExternalize, @ThreadInterrupt
  • Modularizar groovy.
  • Mejorar soporte para DSLs con GEP-3, eliminando puntos y parentesis totalmente. Ver un ejemplo en el blog de Guillaume.

Sobre la optimización: Groovy es particularmente lento en manipulaciones aritméticas y manejo de primitivos debido a lo conversión automática de tipos (BigDecimal), boxing/unboxing y la sobrecarga de operadores matemáticos. El peor caso conocido es la función de fibonacci, que en Groovy 1.7.5 tarda 25131 ms, y su equivalente en Java 1110 ms, esto es hasta 22x mas lento. Debido a las optimizaciones con enteros que se han hecho en la versión 1.8-beta3, esta misma función tarda en calcularse 1871 ms, solo un 68% más lento (es decir, antes 22.64x y ahora 1.68x), lo cual supone un gran avance.
Lo siguiente será optimizar los doubles y mejorar el acceso a los arrays. La alineación de Groovy con JDK7 no será hasta la versión Groovy 1.9 (todavía queda bastante…), y los Closures hasta JDK8

Ver vídeo de la ponencia y presentación.

Rich Grails UIs with Canoo RIA Suite

Dierk Koenig, de Canoo, nos muestra en directo como funciona su suite para creación de aplicaciones RIA ligeras. Ultra Light Client es un framework para crear aplicaciones Swing en el que todo se programa y se ejecuta en el servidor. Y gracias a esto podemos usar Grails y Groovy para crear aplicaciones Swing, lo cual lo hace muy interesante. Las aplicaciones generadas se pueden ejecutar como un Applet o desde Java web start. Arrancan muy rápido, pues el cliente tiene siempre el mismo código: lo necesario para conectarse al servidor y que éste le diga que componentes Swing se deben crear y que eventos se deben propagar. El funcionamiento después es simple: una vez generados los componentes en cliente, cada evento generado invoca código en el servidor. Desde ahí, los posibles cambios se propagan de nuevo en la capa cliente.
El ejemplo empieza creando una aplicación muy básica en Grails con 4 clases de dominio. Despues instala el plugin para Grails ULC Plugin y genera un scaffolding de solo lectura para acceder a todas las entidades en un applet con Swing. Es interesante ver como la carga de datos se hace bajo demanda (se nota sobre todo cuando hay un listado con 2000 elementos: según se va desplazando se van cargando poco a poco los resultados)
ULC es una herramienta de pago en la que trabajan Hamlet D’arcy (committer de Groovy, autor del capítulo “AST Transformations” de la segunda edición de “Groovy in Action”), Andres Almiray (committer de Groovy y creador de Griffon) y el propio Dierk Koenig, autor principal del libro Groovy in Action. Menudo pedazo de equipo que tiene Canoo.

Ver vídeo de la ponencia

Enter the Gradle

El creador de Spock, Peter Niederwieser, da una charla práctica sobre Gradle. Gradle es un sistema para construir aplicaciones Java (además de Groovy, Scala, Web apps y OSGi). Proporciona un DSL y una librería Java que se pueden usar para crear scripts. Comenta que no es un framework de builds, es un lenguaje extensible para construir builds, que no es lo mismo (a diferencia de Ant, con Gradle puedes programar), y es declarativo (le dices qué hacer y el se encarga del cómo). Finalmente acaba la demo creando, a partir de varios scripts Ant, sus equivalentes en scripts Gradle, y su integración con Maven.

Ver vídeo de la ponencia.

Testing dynamic websites with GEB: a newbie’s perspective

Tomas Lin (@tomaslin), que se casa el próximo martes (felicidades!), nos explica en su charla su experiencia haciendo tests funcionales sobre sites con Geb. Este tipo de tests se encargan de navegar, hacer clicks en enlaces y submit de formularios para testear aplicaciones web, incluso con Ajax. Durante la charla nos explica como simular las acciones de un usuario con Webdriver, y después procesar el DOM resultante para ver si es válido. Para esto Geb proporciona un DSL una sintaxis igual que la de jQuery. Una ponencia bastante entretenida e interesante, sin duda GEB parece muy potente, incluso para hacer crawling y bots.

Ver vídeo de la ponencia.

High volume and scalable Ajax with Grails

David Dawson en su charla nos explica como hacer que nuestras aplicaciones con un refresco intensivo vía Ajax sean escalables usando long polling. Para esto nos enseña varios ejemplos con jQuery en la parte cliente y en la parte servidor Continuations (sólo para Jetty), Comet (Tomcat) y Atmosphere (para cualquier contenedor de Servlets). La idea es bastante simple: si un cliente tiene que refrescar su estado y hace una petición al servidor cada 10 segundos ¿porque no mantener solo una conexión abierta contra el servidor esperando ese resultado? de cara al cliente el resultado es el mismo o incluso más rápido, ya que la información llega inmediatamente. Y en el servidor solo tenemos que mantener las conexiones abiertas en un pool y enviar el resultado a todas en cuanto se reciba. El cliente, cuando reciba el resultado (al segundo o al cabo de una hora), lo mostrará y abrirá una nueva petición. Los ejemplos y el código mostrados en la charla son completamente prácticos, sencillos y, sobre todo, que funcionan (se ve la conexión Ajax que abre jQuery esperando indefinidamente en Firebug).

Ver vídeo de la ponencia.

Los chicos de skillmater son unas máquinas y los vídeos están listos apenas acaban las ponencias, por lo que ya podéis verlos todos aquí. Mañana el resto.

Crónica del Coderetrat 2010 en Madrid

PostedEn Crónicas, Groovy     Comentarios 3 comentarios
Oct
6

Qué es

El pasado sábado 2 de este mes de octubre asistí a mi primer Coderetreat. En el anuncio de agilismo.es no se decía claramente lo que se iba a hacer, tan solo una agenda con sesiones de trabajo y retrospectivas, pero nada más. Como no sabía lo que era un Coderetreat ni tenía claro si se iban a dar charlas o si se iba a programar decidí apuntarme y probar.

¿Y qué es un coderetreat? no lo tengo del todo claro, pero viene a ser un reunión de desarrolladores en los que se juntan para programar en parejas haciendo TDD, intentado resolver un problema concreto, compartir experiencias y aprender. Se hacen iteraciones (normalmente 6) de 40 minutos con 15 minutos de retrospectiva después de cada una.

La organización del Coderetreat de este sábado corría a cargo de agilismo.es y Autentia, que trajeron a Enrique Comba (@ecomba), uno de los autores intelectuales del Manifiesto por la Artesanía del Software y co-fundador de Agile-Spain como maestro de ceremonias.

Qué hicimos

Llegué a la sala de actos del hotel donde se celebraba la reunión a las 9:00 y me encontré, como en todos estos saraos, algunas caras conocidas y muchas nuevas. Un poco de networking-desayuno y empezamos, estaba incluso impaciente pues no sabía exactamente que íbamos a hacer.

En la presentación conocí a Enrique. Es un personaje carismático y un poco malvado (luego veréis porqué), así que nos dejamos llevar por su manera de hablar tranquila y relajada y nos explicó que teníamos que hacer. Programaríamos 40 minutos y cuando oyéramos la alarma de su móvil, borraríamos el código (sin excepción) y nos pondríamos de pie. Hizo, además, una breve encuesta a mano alzada con preguntas del tipo ¿cuántos de vosotros hacéis pair programming? ¿cuántos conocéis TDD? ¿cuántos practicáis TDD alguna vez? ¿cuántos prácticas TDD siempre?. Finalizada la presentación, nos sentamos en parejas, abrimos nuestros portátiles y, tras decidir quién de los dos empezaba a programar y qué lenguaje utilizábamos, tuvimos 40 minutos para desarrollar un reto. Este consistía en hacer el juego de la vida de Conway, un autómata celular basado en las siguientes reglas (que Germán tuvo la buena voluntad de escribirlas en la pizarra):

Las células nacen o mueren según el número de células vivas adyacentes.

  1. Una célula con menos de 2 vecinos muere.
  2. Una célula con más de 3 vecinos muere.
  3. Una célula con 2 o 3 vecinos, vive hasta la siguiente generación.
  4. Una célula muerta con 3 vecinos, revive.

Charlando, haciendo pruebas y programando se me pasaron los 40 minutos volando con Jon (el de la derecha en esta foto), un simpático phpero al que le apetecía probar con Groovy. Suena la alarma de Enrique y borramos todo el código hecho. No nos hace mucha gracia, al fin y al cabo es nuestro trabajo, pero no pasa nada, lo borramos, nos levantamos y hacemos una retrospectiva todos de pie de 15 minutos. Comentamos las diferentes aproximaciones que hemos hecho y Enrique nos pregunta el nombre de las clases que habíamos creado. Salen cosas tan dispares como tablero, matriz, universo, célula, estado, vecino, vecindario, muerte, vida, parrilla y otras muchas que no recuerdo ahora.

Cambiamos de pareja y volvemos a la carga. Esta vez me pongo con Alberto Peña (@plagelao) y repito con Groovy como lenguaje de programación. Con más decisión y, gracias a la experiencia de la iteración anterior, conseguimos avanzar lo suficiente para que pasaran casi todas las pruebas menos una ¡ya casi estábamos!, pero toca otra vez la campana y hay que borrar otra vez el código.

Viendo la luz

Tras la retrospectiva, es en ese momento es cuando me doy cuenta de que llevaba toda la mañana trabajando con una mentalidad totalmente equivocada: programando deprisa e intentado aportar soluciones que resolvieran el reto lo más rápido posible (¡solo 40 minutos!) al completo no es, para nada, el espíritu ni el objetivo de un coderetreat. Si quisíeramos hacer el juego de la vida, nos darían más tiempo y no borraríamos el código. Pero aquí no se persigue un fin, no se persigue una solución ideal ni tener el problema resuelto, sino todo lo contrario. Se persigue el medio, el enriquecimiento durante la programación, y se desecha el fin: el código se borra implacablemente tras cada iteración, dejándolo vivo solamente en nuestra memoria el tiempo suficiente para poder comentarlo en la retrospectiva y se vuelve a empezar. No importa si tu implementación fue brillante, el lenguaje que usaste, lo rápido que funcionase o si pasaban todas las pruebas. Se anda el camino por el placer de andar, no para llegar a ningún sitio: el verdadero fin es programar, usando cada vez un enfoque diferente, razonando en voz alta con un compañero distinto, en un reto diferente, cada vez.

Así que a partir de aquí cambié de mentalidad, me olvidé de resolver el problema y orienté el resto del día de otra manera: probaría otros lenguajes y otras maneras de resolver el reto. La siguiente iteración buscaría a alguien que programara en otro lenguaje que no fuera ni Groovy ni Java y lo haría todo de otra manera. Y me encontré a este chico, cuyo nombre no recuerdo, que usaba C#. Pero esta vez Enrique añadió unas cuentas reglas nuevas: ahora no se podía usar ninguna clase o entidad que representara una célula y teníamos que orientar la solución a las reglas del juego en sí mismas, y así lo hicimos (o lo intentamos). Por supuesto, al hacer un planteamiento tan diferente no nos dio tiempo a nada, y en la restrospectiva Enrique nos sorprendió con un engaño digno de un auténtico ilusionista: nadie nos dimos cuenta de que la iteración había durado ¡solo 20 minutos! todos pensábamos que había sido muy corta, pero por el hecho de habernos visto obligados a usar un enfoque distinto, pero nadie se dio cuenta que, simplemente, había durado la mitad. Buena jugada Enrique, si señor.

Confusión total

Cambiamos de pareja de nuevo y ahora si tenemos 40 minutos para la iteración, pero nos propone un gran desafío: no podemos usar clases, así que todo el código que necesitemos debe estar dentro de la prueba unitaria. Primero deberemos escribir el assert, después el código para pasarlo y cuando sea realmente necesario, podremos refactorizar y crear una clase. Nos advirtió que iba a ser muy difícil y para hacerlo más difícil todavía, nos invitó hacer cada test con un máximo de 4 líneas (sí podíamos). Confiados y motivados, me puse manos a la obra con Kini (@kinisoftware). Pero resultó no ser difícil, sino que directamente llegó un momento que no sabíamos ni qué hacer. Enrique se pasó por nuestro sitio para ayudarnos, nos dijo “¿me permitís?”, se puso al teclado, borró todo nuestro código (ante nuestra mirada atónita, claro) y tecleo algo parecido a:

void testVida() {
    boolean estaVivo = true;
    assertTrue(estaVivo);
}

Kini y yo, intentando comprender que es lo que quería Enrique que hiciéramos

Y nos miró satisfecho. Me recordó a la escena en la que Morpheo lucha contra Neo en Matrix y le dice “¿acaso crees que lo que respiras ahora es aire?”. Kini y yo nos miramos como sospechando el uno del otro y nos acabásemos de conocer ahí mismo y dijimos “venga vale, a ver si podemos seguir a partir de aquí”, pero nos duró poco. Intentamos baby-steps, haciendo tests muy básicos que siempre pasaban por el simple hecho de que, al tener que programar dentro de cada prueba el código necesario para pasarla, crear un test nuevo más no hacía que fallaran los anteriores, como suele suceder cuando compartes el código entre todos los tests. Así que no sabíamos en qué momento empezar a programar de verdad y refactorizar. Y así estuvimos, estrujándonos el coco durante 40 minutos de auténtica confusión, y se acabó, gracias a dios, la iteración y empezamos otra retrospectiva. Para colmo, creo recordar que en esta iteración estaba prohibido ¡usar ifs! Enrique parecía contento y sonreía sin parar al ver nuestras caras de desconcierto, un auténtico diablo malvado se esconde detrás de Enrique: creo que todos le odiamos en ese momento un poquito (es broma Enrique, sabes que te queremos ¡y nos encanta sufrir!)

Divirtiéndonos

La siguiente iteración fue algo más relajada, ya sin estar tan condicionados como en la anterior con las diabólicas reglas de Enrique, en esta solo se nos pidió que enfocáramos el desarrollo a modelar las reglas del juego de la vida. Me senté con Jorge Jimenez (@semurat), al que ya conocía de Twitter y tenía ganas de programar con él. Fue una iteración muy divertida ya que nos estuvimos riendo la mayor parte del tiempo (debió ser general, porque recuerdo a Kini gritar con los brazos en alto en un momento de euforia mientras programaba con José Manuel Beas …). Esta vez Jorge se dejó llevar por mi loca idea de plantear las reglas de una manera funcional, al estilo cálculo Lambda.

int fib(0) { return 1; }
int fib(1) { return 1; }
int fib(int n) { return fib(n-2) +
                 fib(n-1); }

La función de Fibonacci implementado en un pseudocódigo Java funcional. Algo así queríamos hacer Semurat y yo con el juego de la vida.

Y así estuvimos los 40 minutos, triturándonos un poco los sesos, creando reglas en un sistema que nos acabábamos de inventar y haciendo tests. Por supuesto, no acabamos ni de lejos, pero nos lo pasamos muy bien.

La última iteración, ya muy, pero que muy cansados, lo que hicimos fue repetir con el primer compañero que tuvimos cada uno ese día, de manera que pudiéramos comparar lo que habíamos aprendido cada uno por el camino durante el Coderetreat y lo contrastáramos. El enfoque en esta última iteración era pensar en el juego de la vida desde un punto de vista temporal, trabajando las generaciones y no las reglas. Así que busqué a Joan y decidimos empezar de nuevo, pero haciendo el juego de la vida con Javascript y las pruebas unitarias con QUnit, todo un reto para lo cansados que estábamos al final del día. Para acotar el problema, decidimos inventarnos una regla muy sencilla para el juego de la vida: una celula vive si tiene una célula viva a su derecha, e implementarla en un sistema que nos generase la matriz de células en función de una generación x dada en el tiempo. Y todo esto en Javascript, casi nada vamos.

La kata

Para rematar ante de irnos, una de las sorpresas del día fue que iban a regalar una licencia de IntelliJ IDEA ¿cómo? ¿una licencia de mi IDE favorito? ¡tenía que conseguirla! pensé, pero para ello teníamos que ganárnosla, y no nos lo iban a poner fácil. El reto consistiría en prepararnos la kata de String Calculator en 30 minutos (al final creo que fue casi una hora, no estoy seguro, perdí la noción del tiempo) y luego saldríamos en público a hacerla. Nos presentamos tres valientes: Jose Manuel Beas, Alfredo Casado y yo mismo. Xavi Gost estuvo a punto de hacerla directamente en vivo sin preparársela, pero al final nos dejó con las ganas. Hacer una kata no es ninguna tontería: tienes que salir con tu portátil y programar en directo, con un proyector, delante de mucha gente, y te puedes poner nervioso, sobre todo si… algo falla.

El primero que salió fue Jose Manuel Beas, que hizo su kata en Java, con un TDD muy bueno y narrando cada uno de los pasos que iba haciendo, mostrando como fallaban los tests, implementando y refactorizando después. Sin embargo, no tuvo el tiempo suficiente para preparársela entera y la dejó a la mitad. Y es que el cansancio a esas horas ya hacía mella en todos nosotros (¡las katas hay que hacerlas a primera hora, no a última!). Aplausos, votaciones y el siguiente a la palestra, yo mismo. Gracias a que usé Groovy, que permite programar mucho más con menos líneas, conseguí acabar mi kata completa durante la hora de entrenamiento anterior. Pero durante la realización de la misma en vivo, en uno de los primeros puntos, apareció un error que no me atreví a corregir con tanta gente mirando y directamente me planté. Mi falta de experiencia en las katas hizo que no supiera gestionar bien mis nervios, y me vine abajo en el primer error. Y es que una cosa es programar y otra muy distinta hacerlo en público, y para esto último hay que entrenar, y mucho. Votaciones, buen flow pero bajo TDD, tengo que entrenarlo más. La siguiente corrió a cuenta de Alfredo Casado, que hizo una kata muy, muy divertida: llegó un momento que todos nos estábamos riendo de su peculiar manera de narrar la kata. Pero al igual que los demás, cuando iba por la la mitad, le apareció un error y se plantó, así es que ninguno de los tres conseguimos acabar. Me imagino que, cuando todos los que salimos dejamos la kata por la mitad, es porque no debe ser nada fácil terminarla: está claro que hay que entrenar y practicar. Tras las votaciones, Alfredo salió victorioso y se fue a casa con una nueva licencia de IntelliJ IDEA ¡felicidades Alfredo! (que mejor momento para abandonar Netbeans :-D)

Y esta es mi versión personal de la kata String Calculator que hice el sábado. Es mejorable, sin duda: no usa expresiones regulares, falla en algunos casos (por ejemplo si se usan asteriscos como delimitadores) y el TDD usado es malísimo, pero es la que me salió en ese momento: http://groovyconsole.appspot.com/script/262001. Para ejecutarla solo hay que hacer click en “Edit in console” y después en “Execute script”

Fin

Seguramente la gente se quedó, hubo cañas o cena, pero personalmente estaba muy cansado, así que dejé a Israel Alcazar (me quedé con las ganas de programar con él, para la próxima) en el tren mientras charlamos en el coche y me fui a casa. Eso sí, con la sensación de que llevaba una semana trabajando sin parar y una sonrisa de oreja a oreja. Me metí en la cama, dormí 12 horas y soñé con células que nacían y morían…

Otras crónicas de asistentes:

Más información:

Crónica de la GR8conf 2010 en Copenhague

PostedEn Crónicas, Groovy     Comentarios 1 comentario
May
28

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á…

Spring 2GX day en Madrid

PostedEn Crónicas, Groovy     Comentarios 14 comentarios
Feb
20

Spring 2GX day es el primer evento gratuito organizado entre SpringSource y Javahispano que trata exclusivamente sobre Grails y Spring. La verdad es que fueron muchas cosas de las que se hablaron, y aunque el saber no ocupa lugar, la memoria siempre tiene un límite, así que intentaré contar mi propia versión del Spring 2GX day, es decir, de lo que me acuerdo.

Llego a las 8:15 y ya hay cola para registrarse, parece que este en evento va a haber mucha gente. Más tarde nos contarán que aunque inicialmente se esperaban unos 150 asistentes, a final serán más de 400. La organización, desbordada, tiene que planificar sobre la marcha, cambiar de sala de audiencias a una mayor y se quedan sin algunos items para todos que regalan durante el registro a todos los ponentes (como bolis, panfletos, etc.). Pese a todos los inconvenientes, todo sale perfectamente. ¡Felicidades Javahispano! :)
La presentación corre por parte parte de Abraham, de Javashipano, agradeciendo a todos los sponsors su ayuda y contándonos que no van a poder hacer streaming de las ponencias por problemas técnicos, una pena para los que no pudieron venir, aunque pueden estar tranquilos: todos los vídeos y transparencias van a ser publicados, pero tendrán que esperar un poquito. También comenta que en todas las ponencias se va a sortear un libro a uno de los asistentes (a mí no me tocó ninguno, una pena porque el libro The Definitive Guide to Grails, 2nd edition, venía firmado por el propio Graeme Rocher).

Empiezan las ponencias. Entra Graeme Rocher, creador de Grails, entre aplausos. Aunque comienza su introducción en castellano, prefiere continuar en inglés donde se encuentra más cómodo, sobre todo a la hora de utilizar palabras técnicas. Graeme empieza a hablar sobre Grails comentando que esta construido sobre hombros de gigantes: Java, Groovy, Spring, Hibernate, Sitemesh y Quartz (he encontrado la presentación aquí: http://europe.springone.com/europe-2009/file?path=/springone-amsterdam-2009/slides/GraemeRocher_HowToBuildTwitterIn40minsUsingGrails.pdf)

Finalizada la presentación y usando SpringSource Tool Suite en su portátil, nos muestra un caso practico para enseñarnos que Grails es realmente Spring y que la capa web de Grails es Spring MVC. Para ello, crea una aplicación de prueba desde cero, añade en un controller el applicationContext de Spring implementando la interfaz ApplicationContextAware y accede con este contexto a diferentes beans de Spring desde Grails, como un DataSource, el SessionFactory de Hibernate, etc. Después, para demostrar que Gorm es Hibernate, crea un clase de dominio y la guarda desde la sesión actual del sessionFactory de Spring y con el método dinámico save() de Gorm, con idénticos resultados.

La siguiente ponencia, de Sergi Almar, nos cuenta las ventajas de utilizar la capa web de Spring 3.0, explicando como es posible programar vistas completamente diferentes, como XML, JSON o HTML con el mismo controlador para soportar, por ejemplo, peticiones Rest y Ajax reutilizando código.

Paramos a tomar un cafe o zumo, cortesía de los sponsors, y seguimos las ponencias. Ahora entran Nacho Brito y Alvaro Sanchez-Mariscal, donde Alvaro nos explica las bondades de la plataforma Grails y anima a los dudosos y escépticos a dar el paso a probarla. Para ello utiliza una gran dosis de humor y auto-crítica, recordándonos lo “felices” que éramos con Struts 1, mapeando las acciones en interminables xml y que ahora es posible hacer exactamente lo mismo y más, sin tocar ni un xml. Después, Nacho Brito nos cuenta como novedad el nuevo campus virtual semi-presencial de escuela de groovy y ofrece una oferta de descuento del 50% para los matriculados ese día. Una interesante manera de hacer un curso de Groovy y Grails desde casa con material de estudio y tests de mano de los creadores de escuela de Groovy y de el libro manual de desarrollo web con Groovy. Finaliza la ponencia con Juanfer Blasco, responsable de Arquitectura y Plataformas del Dpto. De Tecnologías de la Información del Ayuntamiento de Vitoria-Gasteiz, contando un caso de éxito de formación e implantación de Groovy y Grails gracias a Escuela de Groovy.

La siguiente ponencia es de Joris Kuipers, donde nos explica OSGi, un nuevo sistema para desplegar modularmente nuestras aplicaciones y evitar problemas de dependencias o de reinicios durante los despliegues. Con un contenedor OSGi, ya no desplegamos ears o wars de manera monolítica en un sistema de classloaders jerárquico, sino que desplegamos jars que exponen beans en un sistema de classloaders en forma de grafo, donde se exportan e importan servicios. El tiempo apremia y dado que se arrastran algunos retrasos en todas las ponencias, Joris tiene que acabar deprisa su exposición con una demo donde despliega diferentes servicios en caliente. Personalmente no conocía OSGi, y la demo me deja impresionado y con ganas de utilizarlo en futuros proyectos.

La última ponencia es de los creadores de Jobsket a los que ya conocía, sin saberlo, de twitter: Martín Pérez, Jordi Monné y Dani Latorre. Nos explican un caso de éxito real de implantación de Grails en su proyecto Jobsket y nos cuentan, con sinceridad, las cosas buenas de Grails pero también las malas. Muchas de ellas reconocen que ahora han sido mejoradas o arregladas (como el soporte de plugins, que cuando empezaron no funcionaban muy bien), pero eso no quita para que también reconozcan que el uso de Grails, en el fondo, ha merecido la pena y ha mejorado su productividad. El código de su proyecto es 70% Java y 30% Grails: con unos 350 gsp, el principal uso de Grails es para la capa de presentación. Para el resto de código, como el acceso a diferentes bases de datos y los crawlers para recolectar información, utilizan Java, donde se sienten más cómodos y aprovechan código anterior que ya tenían realizado. Jobsket es un portal de empleo donde su principal punto fuerte es el análisis de curriculums para empresas, realizado con Lucene, y la recolección sistemática de ofertas de empleo en otros portales para calcular la valoración de sus curriculums a partir de los sueldos ofertados.

No conocía Jobsket, así que he entrado y me he registrado ayer mismo al volver a casa, y me ha sorprendido algunas cosas: que es capaz de decirte que empleos o provincias tienen los sueldos más altos (y bajos) y sus variaciones diarias. Como si de la bolsa se tratara, podemos entrar todos los días y ver la evolución del mercado. Y todo gracias a su sistema de crawlers que están constantemente recolectando información. Una imagen vale más que mil palabras: http://www.jobsket.es/trabajos-de-tecnologias-de-la-informacion

Hora de comer, dada la cantidad de gente que hay, me voy con Roberto Gil, Jose Vicente Carretero, Carlo Scarioni y Pablo Pazos haciendo una comida ligera en el centro de Boadilla (picadillo de chorizo, torreznos, carcamusa y presa de ibérico…, no te digo “ná”)

Continuamos con las ponencias, ahora le toca el turno a Federico Caro de Paradigma Tecnológico, donde nos habla sobre Spring Security 3.0 de una manera, primero teórica, y después práctica, bastante interesantes.

Después continúa Juan José Martín, que nos cuenta como Spring Roo nos ayuda a crear la estructura básica necesaria de archivos y configuración para empezar un proyecto con Spring. No conocía Roo, así que es una grata sorpresa para mí que existan este tipo de herramientas que te generan el código y el esqueleto básico para arrancar una aplicación. Roo es una shell inteligente: es decir, sabe en que estado se encuentra tu proyecto y te sugiere cual es el siguiente paso que debes dar, con autocompletado de parámetros obligatorios y mostrando después los opcionales.

Siguiente ponencia, espectacular, de la mano de Tomas Lin, donde nos muestra como integrar aplicaciones ricas de escritorio con Flex/Air con Grails. Para ello, primero nos enseña como crear scaffoldings de nuestras entidades (es decir, crud: altas, bajas, borrados y modificaciones) usando un cliente flash incrustado en html con flex. El resultado final es un crud mucho más vistoso y usable que el generado por Grails con html puro, gracias al plugin de Grails Flex Scaffolding. También nos muestra la clara integración que existe entre todas las herramientas de Adobe, como Photoshop y Catalyst, con Flex Builder, un entorno de desarrollo basado en Eclipse para crear aplicaciones ricas. Con Flex Builder, conecta varios combos que se actualizan con un servicio web creado con Grails y XFire. Tomas Lin está haciendo un libro sobre Grails y Flex que se puede leer aquí: http://flexongrails.com

Un cafe rápido, donde puedo conocer y hablar con los creadores de Jobsket, unos auténticos emprendedores y ejemplo a seguir de como es posible vivir con talento y creando una aplicación innovadora como la suya.

Finaliza el día con dos charlas, por un lado Groeme Rocher presenta en una sala una introducción a Groovy y Grails, y por otro, Joris Kruipers presenta cloud para simples mortales. No puedo hablar de la ponencia de Groeme porque no asistí, pero no dudo que escuchar una introducción sobre Grails de su propio creador, sea la mejor manera de empezar a con Groovy y Grails.

La ponencia de Joris Kruiper es muy esclarecedora. Empieza con una presentación donde explica los diferentes sistemas de cloud: Saas, Paas, IaaS, después muestra los diferentes y principales proveedores de cloudcomputing actuales, entre ellos Amazon Web Services (como IaaS), CloudFoundry (con un modelo mixto entre IaaS y PaaS), y Google App Engine (con un claro modelo de PaaS). Para acabar, nos hace dos demostraciones en vivo: la primera, sobre como crear una aplicación en Grails y desplegarla en CloudFoundry desde la línea de comandos con el plugin de Cloud Foundry para Grails. Y la última, la creación y despliegue de una aplicación Grails en Google App Engine. La conclusión final que nos ofrece es que el mejor sistema de cloud computing es el de Amazon, siempre que asumamos que debemos ser nosotros los encargardos de la instalación y despliegue de todos sus componentes. Y que Google App Engine es una buena manera de empezar, ya que es gratuito para las primeras 10 aplicaciones, pero a cambio debemos cambiar nuestro manera de programar las aplicaciones, ya que Google App Engine no soporta Gorm, solo JPA, y no permite hacer joins en base de datos o acceder al sistema de archivos, entre otras muchas cosas (más información en el blog de Tomas Lin). Para acabar, Joris Kruiper nos ofrece a todos los asistentes cuentas de prueba para CloudFoundry, donde las primeras 48 horas de “cloud” son gratuitas. También nos recuerda que, durante estas 48 horas de prueba, apaguemos el servidor cuando no lo utilicemos para que no se consuman a los dos días, y que nos duren mucho más.
Durante la ronda de preguntas, Tomas Lin nos explica que Google App Engine es un fantástico sistema para manipular y servir imágenes.

Mi conclusión final es que fue un gran evento con grandes ponentes, centrado en tecnologías punteras como Spring y Grails, y donde se puede conocer gente y aprender cosas nuevas de mano de primeras figuras del panorama tecnológico actual. Sinceramente, mi enhorabuena a Javahispano y Springsource: espero que se repita todos los años.

Más información:

Categorías

-moz-border-radius: 4px; -ms-border-radius: 4px; -webkit-border-radius: 4px; border-radius: 4px;