Artículos en Groovy

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.

¿Se puede hacer una GRAN aplicación con Groovy y Grails?

PostedEn Groovy, Programación     Comentarios 3 comentarios
Dec
8

El que sea necesario responder a esta pregunta significa que todavía existe una imagen bastante distorsionada de Grails. Así que antes de responderla, será necesario saber primero qué es Grails y cómo está hecho, y averiguar por qué es tan común está pregunta.

Grails es un framework de desarrollo para aplicaciones Web creado en Java y Groovy en 2005. Pero también es una herramienta de construcción de proyectos y testing a la vez, que permite, además, añadir plugins desarrollador por terceros. Tiene la peculiaridad de que abarca las tres capas del desarrollo web: acceso a base de datos, capa de negocio y vista. Y para conseguir todo esto en un solo producto, Grails se basa en otros (muchos) frameworks opensource conocidos: principalmente Spring e Hibernate.

La principal característica y que más llama la atención de Grails es que esta diseñado para que programemos las aplicación en Groovy, un lenguaje dinámico con la misma sintaxis que Java, pero que añade muchísimas nuevas funcionalidades, permitiendo programar más con menos código.

Los orígenes

Sin embargo, Grails tiene fama de ser ideal para desarrollar pequeñas aplicaciones, pero para abordar una gran aplicación es mejor usar el stack de Java común hoy en día: Spring + Struts2 + Hibernate. Entonces me pregunto ¿y cuál es la diferencia, si Grails usa Spring + SpringMVC + Hibernate? Y es ahí cuando encontramos la semilla que siembra el temor en todos los arquitectos que se dedican a evaluar herramientas, antes de que los equipos de sus empresas empiecen a usarlas.

Estos arquitectos son los que, hace 10 años, evaluaron los Ejbs, los adoptaron y después se arrepintieron. Los mismos que, con mucha mas cautela, probaron y aceptaron Struts1 hace 8 años, y mejoraron su productividad, tanto que muchos equipos lo siguen usando hoy en día en sus proyectos. Los mismos que aceptaron sabiamente que Spring y Hibernate eran grandes herramientas, y las han convertido en un standard de facto para cualquier desarrollo actual. Y los mismos que tuvieron que descubrir como Struts1 fue una buena idea en su momento, pero que ahora se ha quedado completamente obsoleta, y tienen cada vez mas frameworks a elegir entre Struts2, JSF, SpringMVC, Wicket, Tapestry, Stripes… O entre Hibernate, iBatis, JPA, JDO…

Todos estos arquitectos llevan mucho tiempo, muchos años, probando nuevas herramientas, adoptándolas y desechándolas. Siempre aparece algo mejor, que se define a si mismo como la solución definitiva a todos los problemas. Pero después de tanto tiempo, no hay tanta confianza en las nuevas herramientas. ¿Y por qué? porque siempre requieren tiempo, una curva de aprendizaje. Y son fuentes de nuevos problemas, los problemas propios de la nueva herramienta y de integración con otras. Hasta el punto de que algunas empresas incluso han creado sus propios framework MVC y de persistencia.

Entonces estos arquitectos evalúan Grails, empiezan a programar controladores, prueban la persistencia, usan las vistas y dicen “¡qué fácil!”. Pero descubren que esto es posible porque programan con Groovy, y que Groovy es dinámico. Un lenguaje que resuelve las llamadas a métodos y evalúa las expresiones en tiempo de ejecución, no de compilación. Que no tiene un verdadero control de tipos, que es difícil refactorizar y depurar. Y empiezan a sospechar, claro. Pero cuando descubren que, usando incorrectamente el lenguaje, Groovy puede llegar a ser hasta 60 veces más lento que Java, es cuando Grails se desecha como opción directamente: ¿pero cómo voy a instalar en producción una aplicación que funciona hasta 60 veces más lento que la misma aplicación en Java?

La verdad sobre la velocidad de Groovy

Mi primera respuesta sería “no me importa que la aplicación sea más lenta, si puedo desarrollarla en menos de la mitad de tiempo o con una persona menos en el equipo“. Y es que en el ciclo de vida de desarrollo de un proyecto, tiene mucho más coste una persona más desarrollando, que poner un nuevo nodo en el cluster, ampliar la memoria RAM del hosting, o contratar una segunda máquina para el servidor.

Pero es que esto es falso. Spring, Sitemesh, Hibernate… todas las librerías que usa Grails están creadas 100% con Java. Y casi todo el código propio de Grails también. Veámoslo con números. Quitando las clases de tests, y sin tener en cuenta en qué están desarrolladas las partes más importantes (qué podríamos, y me consta que están en Java), este es el recuento de clases en función del lenguaje en el que están programadas (datos reales obtenidos sobre Grails 1.3.4)

Bauer.avilches:~/Work/Apps/grails-1.3.4/src2$ find . -name *.java|wc -l
    562
Bauer.avilches:~/Work/Apps/grails-1.3.4/src2$ find . -name *.groovy|wc -l
    155

Es decir, solo el 22% del código fuente de Grails está desarrollado en Groovy, el resto es Java auténtico 100%.

Entonces es cuando pensamos “ya, pero ¿y nuestro propio código, acaso no programamos las vistas, los servicios y los controladores en Groovy?“. Si, pero es que esa parte del código es mínima, si lo comparamos con todo el código que se ejecuta y el tiempo que se invierte en resolver una petición. Existe una gran cantidad de agentes intermedios involucrados que consumen mucho más tiempo, como el envío de información a través de la red, tanto la petición http como su respuesta, o el acceso a base de datos u otros servicios externos, desde el acceso a ficheros en disco a servicios web/rest. Y es ahí donde debemos preocuparnos por el rendimiento, no por la velocidad del lenguaje. Si nos preocupa el rendimiento, hay tareas muy concretas que se ha demostrado que funcionan, además de una buena optimización en la base de datos, cachear elementos estáticos, reducir o comprimir los recursos, aumentar el número de hilos, dividir la carga, etc.

Velocidad de ejecución vs. velocidad de desarrollo

Lo único en lo que no debemos escatimar es en la claridad en el lenguaje utilizado. Una mayor claridad significa menor cantidad código, pero mejor escrito. Significa que un nuevo programador se puede incorporar al equipo con el proyecto empezado, entender el código y empezar a trabajar rápidamente. Cada hora que un programador dedica a ponerse al día para entender cómo funciona un proyecto es dinero. Esta claridad, esta reducción de código con mayor funcionalidad, no lo conseguimos solo con Groovy, sino que ya lo llevamos haciendo mucho tiempo con Java.

Porque programamos en Java, ¿verdad? no programamos en C o en ensamblador, cuya velocidad de ejecución es varios ordenes de magnitud superior. No, lo hacemos en Java porque nos ha permitido hacer buenos diseños, usar patrones, nos permite programar de una manera clara, nuestra productividad mejora y somos más rápidos y mejores programando. Un lenguaje de alto nivel es más cercano al humano que a la máquina,es una abstracción que encapsula funcionalidades que alejan a los programadores del hardware. Cada nivel que sube un lenguaje, cada nivel que se aleja de la máquina, se añade más y más código intermedio por detrás. Instrucciones, rutinas, procesos, funciones, librerías, intérpretes, máquinas virtuales, clases, objetos, apis, frameworks. Java es un gran lenguaje de alto nivel, y Groovy lo es más todavía.

Resumiendo, preguntas y respuestas

  • ¿es más lento Groovy que Java? sí, pero solo en cosas muy puntuales.
  • entonces, ¿son verdad todos esos tests que dicen que Groovy es 60 veces más lento que Java? No del todo. Existen muchos benchmark publicados en internet comparando la velocidad entre Groovy y Java, con conclusiones como que Groovy era hasta 60 veces más lento que Java en un código equivalente. En la siguiente presentación que hizo Jochen Theodorou, uno de los líderes de Groovy, en la GR8, nos explica la realidad sobre los microbenchmarks, y como el mismo test, bien y mal diseñado, puede dar resultados muy dispares. Siempre hay que comparar el código más óptimo equivalente entre dos lenguajes, una línea situada dentro o fuera de un bucle puede hacer que una prueba tarde un orden de magnitud más.
  • ¿penaliza la velocidad de respuesta de una petición http? técnicamente, si, pero es despreciable.
  • ¿es siempre Groovy más lento que Java? no, es posible hacer optimizaciones muy simples en nuestro código para incrementar la velocidad.
  • Groovy es un lenguaje dinámico, por lo que hay muchos errores que deberían aparecer en tiempo de compilación y que no salen. Estos errores aparecen después, en tiempo de ejecución, a veces en producción ¿cómo lo evito? esto en realidad es un problema de metodología, no del lenguaje. Pero que sale a la luz cuando usamos lenguajes dinámicos. El verdadero problema es que no existen pruebas unitarias suficientes y hay poca cobertura de código. La solución es hacer más tests, lo cual tiene muchos más beneficios de lo que a simple vista parece. Más información aquí, es un artículo del 2006, pero que sigue vigente hoy en día.
  • ¿Está haciendo algo el equipo de Groovy para incrementar la velocidad? Si, son muy conscientes de ello y están trabajándolo.
  • Si uso Grails ¿estoy obligado a programar todo en Groovy? no, puedes programar en Java si te apetece, o si hay una parte crítica en tu sistema (complejos cálculos matemático, por ejemplo) que necesita el máximo rendimiento, pero tendrás que prescindir de la riqueza del lenguaje que añade Groovy a Java.
  • ¿tiene una curva de aprendizaje Groovy? si, pero si ya conoces Java, es muy pequeña.
  • ¿tiene una curva de aprendizaje Grails? si, pero si ya conoces Spring e Hibernate, es muy pequeña.
  • ¿puedo tener problemas con Grails? si, principalmente los mismos que tendrías al usar Spring e Hibernate. Y algunos nuevos que añade el simple hecho de usar una nueva plataforma, pero nada está exento de errores.
  • Entonces ¿puedo hacer una gran aplicación con Grails? Claro. Si la puedes hacer con Java con las mismas herramientas (Spring + Hibernate), también la puedes hacer con Grails, y además en menos tiempo, gracias a Groovy.

DISCLAIMER: El siguiente artículo apareció el 13 de octubre en el blog corporativo de Paradigma Tecnológico. Como me parece interesante compartirlo y el artículo es mio, lo publico aquí también.

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

Accediendo a los datos internos de Grails

PostedEn Groovy, Programación     Comentarios 2 comentarios
May
17

A veces es inevitable tener la sensación de que Grails es demasiado sencillo y que esconde, a propósito, algo debajo. Debajo no tiene nada más que Spring, y gracias a ello, podemos entrar en sus “tripas”, verlo e incluso modificarlo.
Veamos algunas formas sencillas se obtener información útil para nuestros desarrollos.

Entorno

Primero es saber en que entorno estamos trabajando ahora mismo. Podemos hacer que nuestro BootStrap (o un controlador o servicio, lo que sea), ejecute una acción u otra en función del entorno actual en el que se ha arrancado. Para ello tenemos la clase grails.util.Environment y los métodos isDevelopmentMode() y getCurrent()

import grails.util.Environment

class BootStrap  {

     def init = { servletContext ->

         if (Environment.isDevelopmentMode()) {
             println "development"
         }

         switch (Environment.getCurrent().name) {
             case "development":
                 println "development"
                 break;
             case "otro" :
                 println "otro"
         }
     }
}

Para arrancar en un entorno u otro, hay que pasar el parámetro grails.env: grails -Dgrails.env=X war o grals -Dgrails.env=X run-app

application.properties

La configuración del application.properties se obtiene a través de ApplicationHolder.application.applicationMeta. Por ejemplo, el siguiente fragmento muestra todo el contenido de este fichero (es un GSP):

<%@ page import="org.codehaus.groovy.grails.commons.ApplicationHolder" %>

<h1>Meta:</h1>
<g:each in="${ApplicationHolder.application.applicationMeta}" var="name">

    <li>${name}</li>

</g:each>

Config.groovy

Todos nuestros datos de configuración que poquito a poco hemos ido metiendo en el Config.groovy están accesibles desde cualquier lugar de tu aplicación en el objeto ConfigurationHolder.config y ConfigurationHolder.flatConfig:

<%@ page import="org.codehaus.groovy.grails.commons.ConfigurationHolder" %> 

<h1>Config (flat)</h1>
<g:each in="${ConfigurationHolder.flatConfig}" var="name">

      <li>${name}</li>

</g:each>

<h1>Datasource</h1>
<g:each in="${ConfigurationHolder.config.dataSource}" var="name">

      <li>${name}</li>

</g:each>

Podemos crear en el fichero Config.groovy nuestra propia sección:

xmpp {
    priority = 20
    client {
          host = "192.168.3.1"
          port = 2832
          domain = "peterpan"
    }
}
ftp {
    user = "hoy"
    passwd = "gan"
}

Y luego acceder a estos valores desde un controlador así:

import org.codehaus.groovy.grails.commons.ConfigurationHolder as CH

class TestController {

    def index = {
        def prio = CH.config.xmpp.priority
        def host = CH.config.xmpp.client.host
        def port = CH.config.xmpp.client.port
        def doma = CH.config.xmpp.client.domain

        def ftpuser = CH.config.ftp.user
        def ftppasw = CH.config.ftp.password
    }
}

basePath

Si quieres saber donde están físicamente los archivos de tu aplicación:

import org.codehaus.groovy.grails.commons.ApplicationHolder;
...
println ApplicationHolder.application.mainContext.servletContext.context.basePath

La factoría de Spring

Ahora vamos con Spring. Para acceder al contexto de la aplicación, al factory, tenemos ApplicationHolder.application.mainContext. De ahí podemos sacar beans, o mostrar todos los que ya hay:

<%@ page import="org.codehaus.groovy.grails.commons.ApplicationHolder" %>

<h1>System beans</h1>

<g:each in="${ApplicationHolder.application.mainContext.getBeanDefinitionNames()}" var="name">

      <li>${name}/li>

</g:each>

Incluso podemos obtener un bean del sistema con ApplicationHolder.application.mainContext.getBean(beanName)

web.xml

Finalmente, podemos acceder a los atributos y parámetros de nuestro archivo /WEB-INF/web.xml con ServletContextHolder.servletContext.context

<%@ page import="org.codehaus.groovy.grails.web.context.ServletContextHolder" %>

<h1>Servlet context Attributes:</h1>

<g:each in="${ServletContextHolder.servletContext.context.attributes}" var="name">
    <li>${name}</li>
</g:each>

<h1>Servlet context parameterss:</h1>

<g:each in="${ServletContextHolder.servletContext.context.parameters}" var="name">
    <li>${name}</li>
</g:each>

Y a otros valores como el contextPath con ServletContextHolder.servletContext.context.contextPath y el resto de método de la interfaz javax.servlet.ServletContext

Conclusión

Como podemos observar, la aparente simplicidad de Grails no sirve para protegernos ni para esconder toda su información: existe toda una serie de clases con las que Grails nos facilita obtener beans de la factoría Spring, datos de sus archivos de configuración y parámetros y atributos de la aplicación Web. Resumen de clases y métodos usados:

  • grails.util.Environment.isDevelopmentMode()
  • grails.util.Environment.getCurrent().name
  • grails.util.GrailsUtil.grailsVersion
  • org.codehaus.groovy.grails.commons.ApplicationHolder.application.applicationMeta
  • org.codehaus.groovy.grails.commons.ApplicationHolder.application.mainContext.servletContext.context.basePath
  • org.codehaus.groovy.grails.commons.ConfigurationHolder.config
  • org.codehaus.groovy.grails.commons.ConfigurationHolder.config.dataSource
  • org.codehaus.groovy.grails.commons.ConfigurationHolder.flatConfig
  • org.codehaus.groovy.grails.commons.ApplicationHolder.application.mainContext.getBean(beanName)
  • org.codehaus.groovy.grails.web.context.ServletContextHolder.servletContext.context.attributes
  • org.codehaus.groovy.grails.web.context.ServletContextHolder.servletContext.context.parameters

Espero que os haya servido de utilidad.

Mini tutorial, log4j en Grails

PostedEn Groovy, Programación     Comentarios 5 comentarios
Apr
13

El siguiente mini tutorial intenta explicar como configurar Grails para que ciertas clases (las que nosotros queramos) escriban sus logs en un fichero distinto. Esto puede ser necesario si, por ejemplo, hemos programado un componente en concreto usando varias clases que generan muchas trazas, y el fichero de log general de nuestro servidor de aplicaciones nos las muestra todas juntas y mezcladas, haciendo difícil el seguimiento de errores. Lo que vamos a hacer es:

  • Configurar log4j para que cree un fichero de log independiente llamado pepito.log
  • Configurar una clase para que escriba sus trazas en este fichero de log.

Primero tenemos que editar el fichero grails-app/conf/Config.groovy y añadirle un nuevo appender y una categoría nueva en la sección log4j.

log4j = {
    appenders {
        console name: 'stdout', layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')

        rollingFile name:'pepitoAppender', file: "/tmp/pepito.log", append: true,
            layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
    }

    info pepitoAppender:'pepito', additivity:false
    ...
}

El atributo additivity:false indica que si se usa ese appender, no se utilice ninguno otro más. De esta manera se evita que los logs salgan, además, en la salida standard y, por lo tanto, en el fichero de log principal de nuestro servidor de aplicaciones.

Ahora tenemos que especificar en cada una de las clases (nuestro controladores, servicios, etc) que utilice nuestra categoría “pepito”. Para ello, utilizaremos el constructor LogFactory.getLog() indicando como parámetro un String que empiece siempre con "pepito.", por ejemplo "pepito.xxxx" o "pepito."+MiClase.class.getName()

package pepito
import org.apache.commons.logging.*

class PepitoController {

    private static Log log = LogFactory.getLog("pepito."+PepitoController.class.getName())

    def index = {
        log.info "Esto debería salir en pepito.log"
    }
}

Si utilizamos Tomcat, podemos hacer que nuestros logs se creen en la carpeta $CATALINA_HOME/logs con el siguiente código:

log4j = {

    def catalinaBase = System.properties.getProperty('catalina.base')
    def logDirectory = !catalinaBase? '/tmp': "${catalinaBase}/logs"

    appenders {
        rollingFile name:'pepitoAppender', file: "${logDirectory}/pepito.log", append: true,
            layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
    }

Así, si está definida la propiedad Java ‘catalina.base’ con el directorio de instalación de Tomcat (ya se encarga el propio Tomcat de definir esta propiedad cuando arranca), utilizará el directorio logs de Tomcat. Si no estuviera definida, utilizará “/tmp”.

Otra forma de hacerlo sería especificando un appender distinto para cada environment. De esta manera podemos cambiar o añadir parámetros de configuración en los appenders, como el tamaño del fichero, el número de backups:

log4j = {

    appenders {

        development {
            rollingFile name:'pepitoAppender', file: "/tmp/pepito.log", append: true,
                layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
        }
        production {
            rollingFile name:'pepitoAppender', file: "/usr/local/tomcat/logs/pepito.log", append: true,
                maxBackupIndex: 10, maxFileSize: "10MB",
                layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
        }
    }

Más información:

Probando Grails en Google App Engine

PostedEn Groovy, Programación     Comentarios 5 comentarios
Mar
1

Este es un pequeño tutorial para probar una aplicación desarrollada con Grails sobre Google App Engine. La aplicación es lo más sencilla posible: no tiene clases de dominio ni servicios ni nada, tan solo un controlador que pinta “Hola mundo”. Las versiones que he utilizado son Grails 1.2.1 (descárgatelo de aquí: http://grails.org/Download) y Google App Engine SDK para Java 1.3.1 (descárgatelo de aquí: http://code.google.com/p/googleappengine/downloads/list)

El primer paso de todos es crear una cuenta en http://code.google.com/appengine y crear una aplicación. Para este ejemplo, asumiremos que el nombre de la aplicación es tuapp, pero podría ser cualquier otro. El nombre de la aplicación en App Engine debe coincidir con el nombre de la aplicación Grails.

Descargar el Google App Engine SDK, descomprimirlo en un directorio y establecer la variable de entorno APPENGINE_HOME para que apunte a dicho directorio. Ejecutar los siguientes comandos (se supone que tenemos instalado Grails y que el comando grails está en el PATH)

grails create-app tuapp
cd tuapp
grails set-version 1

Google App Engine no acepta números de versión decimales (como 0.1), por eso es importante que la versión sea un número entero, como 1, 2, etc.

Hay que desinstalar el plugin de Tomcat (solo se desinstala para esta aplicación, no para todo el sistema) ya que el plugin de Google App Engine lleva su propio servidor.

grails uninstall-plugin tomcat
grails install-plugin app-engine

Elegir jpa cuando te pregunte.

Ahora vamos a crear un controlador de prueba:

grails create-controller test.Test

Editar grails-app/controllers/test/TestController.groovy y modificar el closure index para que quede así:

package test

class TestController {
    def index = { render "Hola mundo" }
}

Editar el fichero grails-app/conf/UrlMappings.groovy y cambiar el mapeo de “/” para que apunte al controller que acabamos de crear

"/"(controller:'test', action:'index')

Lanzar la aplicación con:

grails run-app

Probar que todo funciona visitando http://localhost:8080. Parar el servidor con CTRL+C.

Añadir las siguientes lineas al fichero grails-app/conf/Config.groovy con los datos de tu cuenta de Google.

google.appengine.email="tumail@gmail.com"
google.appengine.password="tupassword"

Despliega la aplicación con el siguiente comando:

grails app-engine deploy

Prueba que todo funciona correctamente visitando http://tuapp.appspot.com. He hecho más de una prueba, y no he conseguido hacerlo funcionar. Parece que la primera petición http que se hace a la aplicación, Google App Engine la inicializa y Grails tarda demasiado. Google App Engine tiene un límite de 30 segundos por petición, y si se supera ese tiempo, mata la petición. Y con ella, el proceso de arranque. Al parecer es un bug conocido: http://jira.codehaus.org/browse/GRAILSPLUGINS-1736. En fin, estaré al tanto para ver si se arregla este bug, ya que es bastante interesante poder disponer de un hosting gratuito para nuestras aplicaciones en Grails. Mientras tanto, probaremos otras opciones como Gaelyk, que es bastante más ligero.

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:

Un generador de passwords en grails

PostedEn Groovy, Programación     Comentarios 2 comentarios
Feb
17

A raíz del post en wwhatsnew donde se listan diferentes aplicaciones web para generar passwords seguras, he decidido crear un sencillo servicio de Grails que genera passwords. En DATA he quitado los números 1 y 0, y las letras L minúscula, I mayúscula y las dos oes, así se evitan confusiones del tipo “eso es una o mayúscula o un cero?”, aunque se pueden volver a añadir. La proporción de símbolos, números y letras es de 25%/25% y 50%, respectivamente. El código es autoexplicativo.

class PasswordGeneratorService {

    int DEFAULT_SIZE = 8
    Random rnd = new Random()
    String DATA =
        '!$%&().?=/*+!$%&().?=/*+'+
        '234567892345678923456789'+
        'abcdefghijkmnpqrstuvwxyz'+
        'ABCDEFGHJKLMNPQRSTUVWXYZ'

    String generateNew() {
        return generateNew(DEFAULT_SIZE)
    }

    String generateNew(int size) {
        StringBuffer result = new StringBuffer()

        size.times {
            result << DATA[rnd.nextInt(DATA.length())]
        }

        return result.toString()
    }
}

En alt1040 han creado un interesante post sobre como crear contraseñas seguras.

Groovy: un chat

PostedEn Groovy, Programación     Comentarios 2 comentarios
Apr
23

Tok es un programa de chat escrito en Groovyen dos horas por el autor de SH*TMORES, un blog sobre ingeniería de software. El autor (no he logrado encontrar cómo se llama) se quedó sin ADSL unos días, y decidió dedicar su tiempo libre a “aprender un poco más de Groovy”. Cogió su ejemplar de Groovy in Action, y en un par de horas tenía una sencilla aplicación de chat cliente-servidor.
El cliente tiene 63 líneas de código, el servidor solo 33, y la conectividad entre ambos se realiza mediante XML-RPC.

Vía Groovy.or.ges, el post original aquí

Cada día estoy más convencido de que tengo que aprender Groovy. Ya. Ahora. Solo de pensar la de cientos de líneas que me puedo ahorrar programando lo mismo que hago en Java pero en Groovy se me hace la boca agua.

Tok client

 1 import groovy.swing.SwingBuilder
 2 import groovy.net.xmlrpc.XMLRPCServerProxy as Proxy
 3 import groovy.net.xmlrpc.XMLRPCServer as Server
 4
 5 import java.net.ServerSocket
 6 import java.awt.BorderLayout as BL
 7 import javax.swing.WindowConstants as WC
 8
 9
10 def swing = new SwingBuilder()
11 def content = new StringBuffer()
12 def remote = new Proxy('http://localhost:8081/')
13
14 newMsg = swing.action( name:'newMessage', closure: {
15     msg = remote.chat( swing.inputMsg.text )
16     //content << " ${msg}"
17     //swing.msgPane.text = content
18     swing.inputMsg.text = ""
19 } )
20
21 def frame = swing.frame( title:'Tok' ) {
22     // Menu bar
23     menuBar {
24         menu('File') {
25             menuItem 'Quit'
26         }
27         menu('Edit') {
28         }
29         menu('Help') {
30             menuItem 'About'
31         }
32     }
33
34     // Panel
35     panel( layout: new BL() ) {
36         scrollPane( constraints: BL.CENTER ) {
37             editorPane( id:'msgPane', editable:false, preferredSize:[60, 100],
38                         editorKit: new javax.swing.text.html.HTMLEditorKit() )
39         }
40         panel(constraints: BL.SOUTH) {
41             textField(id:'inputMsg', columns:20)
42             button( action:newMsg, 'Go' )
43         }
44     }
45 }
46 content << "Tok session started on ${new Date().toString()}"
47 swing.msgPane.text = content
48
49 // Perform client registration to the chat network
50 int ticket = remote.register()
51 println "TICKET: ${ticket}"
52 def server = new Server()
53 server.startServer( new ServerSocket(ticket) )
54
55 server.update = { msg ->
56     print msg
57     content << "${msg}"
58     swing.msgPane.text = content
59 }
60
61 frame.pack()
62 frame.setDefaultCloseOperation( WC.EXIT_ON_CLOSE )
63 frame.show()

Tok Server

 1 import groovy.net.xmlrpc.XMLRPCServer as Server
 2 import groovy.net.xmlrpc.XMLRPCServerProxy as Proxy
 3 import java.net.ServerSocket
 4
 5
 6 def ticket = 9991
 7 def clients = []
 8
 9 def server = new Server()
10
11 server.chat = { msg ->
12     println msg
13         clients.each { client ->
14             //client.update( msg )
15             updateClient(client, msg)
16     }
17 }
18
19 def updateClient(client, msg) {
20     try {
21         client.update( msg )
22     } catch (Exception ex) {
23         println ex
24     }
25 }
26
27 server.register = {
28     clients << new Proxy("http://localhost:${ticket}")
29    return ticket++
30 }
31
32 def socket = new ServerSocket(8081)
33 server.startServer(socket)

Categorías

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