Resumen 24ta. Reunión de Grails.org.mx y SpringHispano.org

Comenzaba el mes de abril. Un día medio soleado despuntaba para revivir un tiempo que marcó época, el tiempo en que al menos cada mes nos reuníamos y compartíamos sobre la tecnología que nos apasionaba. Y ese sábado, como el primero de ellos, como algunos otros, como parecía que tenía uno o dos meses sin vernos, aquél sábado 5, Andrés Almiray (@aalmiray en Twitter), el padrino de las reuniones, nos habló de Gradle y Spock.

Así fue que caímos en cuenta cuánto tiempo había pasado, que nuestro espíritu quedó ligeramente aletargado, y las comunidades, inactivas. El expositor inició recordando la primera reunión que se dio, los orígenes de las charlas y la actividad que se tuvo durante todo el tiempo, y después, la pasividad. Si bien, hubo algunas reuniones entre semana el año pasado, dejaron también de suceder, y con esta charla, exhortó a seguir, a continuar con este espacio de colaboración, de la manera como sabemos: compartiendo tecnología.

En pocas palabras, los temas fueron Gradle, para construcción de proyectos, y Spock, para pruebas. Sometió a votación con cuál iniciar, y los asistentes decantamos en favor de Gradle. Inició con una breve historia de los programas para la construcción de proyectos en Java. Apache Maven se usa ampliamente, sin vérsele mucho problema. Si comparamos Maven contra Ant, tiene ciertas ventajas. Empero, en el día a día, sus problemas son tan cotidianos que los dejamos pasar. En la JVM ningún constructor de proyectos existía. Con la llegada de Apache Ant se pudo hacer mucho, pero su enorme flexibilidad era su problema, porque debía declararse extensivamente cada tarea que se habría de ejecutar.

Una mejora para Maven 1 fue la programación declarativa con XML mediante Jelly. Con Maven 2 llegaron los MOJO, versión de POJO «a la Maven» conduciendo plugins que hicieron más rígido el procedimientlo y agregaron otro problema sobre conflictos de versiones. Por el lado positivo, Maven dio un estándar para manejar relaciones en dependencias. Ivy, en estado zombie, descarga dependencias para Ant. Maven parece ser el estándar, pues se usa en muchos lados. El problema en que si se deja de declarar la versión exacta de dependencias, Maven actualiza los paquetes. Deben definirse versiones transitivas y contra qué versión de la JDK se trabaja.

Un ejemplo típico es al utilizar Jetty, Maven lo actualizaba automáticamente a la versión estable. Eso rompía la posibilidad de tener builds reproducibles. Por supuesto que Maven funciona, tan funciona que de cierta manera se ha vuelto «de facto», el repositorio central de Maven, nada más por mencionar algo, pero tiene muchos problemas que se repiten enormemente.

En las primeras versiones de Tomcat, se generó Ant con XML, a finales del milenio pasado, cada vez que se debía externalizar un concepto, se usaba XML, el autor del futuro. El autor de Ant pidió disculpas por haber usado XML. El segundo problema, se compilan fuentes, se procesan recursos, y se ejecutan pruebas en cada fase. El árbol de definición de metas es muy rígida, solo se pueden eliminar metas, dejando poco flexible para comportamiento pre o post para una meta. Y muy probablemente se le ocurrirán más ejemplos similares.

Gradle

Charla de Andres Almiray sobre Gradle en #sh24 from Grails.org.mx on Vimeo.

Gradle, con base en la experiencia de los sistemas anteriores, permite una flexibilidad para una meta. Gradle permite tips para brincar. Build helper permitía juntar proyectos de distintas naturalezas para construir, pero deja de ser agradable por plugins que requieren acceso a múltiples fuentes. Proyectos similares que conduzcan a distintas versiones de JDK todavía requerirán proyectos separados. La mayoría de Gradle está construido en Java, solo tiene una capa de Groovy encima, para tener una definición declarativa. Pueden escribirse sus plugins en Groovy o Java.

El expositor creó un directorio. Gradle puede seguir las convenciones de Maven u omitirlas.

src/main/java/sample y allí crea una nueva clase.

Foo.java – En un principio no había IDEs, para mucha gente el IDE estorba. Para muchos, ni siquiera el public void static main puede verse claro, o es más, cómo se ejecuta.

Package sample;
public class Foo {
public stati8c void main (String[] args)

Una clase simple.

En www.gradle.org tienen soporte profesional, pero generalmente se trata de desde descargar un zip y se agrega una variable de entorno. Recomienda usar GVM y lo puso con ejemplo:

> gvm u gradle 1.11

Using gradle version 1.11 in this shell

> gvm list candidate

Se describieron los conceptos de gaiden, gradle, grails, griffon, glide, groovy, groovyserv, lazybones, springboot, vertx.

Con Gradle instalado se puede dar mucha información. Gradle ha causado tanto furor que incluso Maven ha copiado ideas.

Si se ejecuta gradle sin argumentos, termina sin argumentos. Puede listar tareas.

Comencemos construyendo el build.gradle. Para construir un proyecto Java siguiendo las convenciones de Maven basta con aplicar un plugin.

apply plugin: 'java'

En Java las comillas dobles y el signo de pesos la vuelve variable mutable. Eso es lo único que debe hacerse por el momento.

Una vez guardado el archivo se disponen de muchas más tareas. Por ejemplo, check o test para verificaar.

> gradle build

Mustra el orden en que se ejecutan las tareas. Comprueba si las entradas o las salidas han cambiado y salta las que detecta sin cambios. Se guarda el caché en ~/.gradle por referencia, reduciendo tiempos. Ni siquiera Maven 4 lo tiene. En multiproyectos, Maven realiza las pruebas 2 veces.

La primera vez que se ejecuta gradle se levanta un daemon que se va al fondo.

> gradle wrapper

Build successful

Crea un directorio gradle para ejecutarse en entornos sin gradle. Con gradlew el build es 100% reproducible y si la otra persona no tiene tal herramienta. Maven y Tesla han dado de ellos.

> gradle clean

Limpia el asunto.

> gradle build

En build.gradle

apply plugin: 'java'

version = '1.0.0.SNAPSHOT'

-- El scope provided de Maven aún no está en Gradle

> gradle clean build

> tree

Se muestra el contenido

En build.gradle

apply plugin: 'java'

version = '1.0.0.SNAPSHOT'

jar {
   manifest {
      attributes(
         'LLAVE': 'VALOR'
      )
   }
}

En el manifest se puede agregar quién construyó el proyecto, variables y cualquier info que se quiera agregar.

En gradle-plugins (aalmiray.github.io/gradle-plugins/) se encuentra una lista extraoficial.

El repositorio utiliza las convenciones de Maven. Si no se conffigura nada, el repositorio predeterminado es inexistente.

En build.gradle

apply plugin: 'java'

version = '1.0.0.SNAPSHOT'

dependencies {
   testCompile 'junit:junit:4.11'
}

jar {
   manifest {
      attributes(
         'LLAVE': 'VALOR'
      )
   }
}

Cuando se hace un proyecto Maven, no debe especificarse que se trata de un proyecto. Gradle no asume de qué repositorio va a jalar las dependencias.

En build.gradle

apply plugin: 'java'

version = '1.0.0.SNAPSHOT'

repositories {
   //mavenCentral()
   //mavenLocal()
   //maven {url: 'http://github.com/aalmiray' }
   //flatDir { dirs '' }
   jcenter()
}

dependencies {
   testCompile 'junit:junit:4.11'
}

jar {
   manifest {
      attributes(
         'LLAVE': 'VALOR'
      )
   }
}

Con paquetes como bitrade, jcenter, administración de binarios de manera social. Resuelve más rápido que Maven Central y bitrate permite incluso que tu paquete se pueda compartir a Maven Central, si tienes cuenta en Sonatype. Algo que no les gusta a Sonatype es especificar dependencias a repos locales. Es más flexible. Grails 2.4 debe tenerlo.

Hay mucha sinergia en el ecosistema Groovy.

> mkdir -p src/test/java/sample

Snapshots son mucho mejor.

En FooTest.java
package sample;

import org,.junit.*;
import static.org.junit.Assert.*;

public class FooTest {
    @Test
   public void probarSaludar() {
       Foo foo = new Foo();
       String resultado = foo.saludar(“Java”);
       assertEquals(“Hola Java”, resultado);
}

En Foo.java:

public class Foo {
  public stati8c void main (String[] args)

> gradle test

La primera vez, 1.6 segundos, la segunda, 0.5. En gradle se pueden paralelizar las pruebas.

Reportes: Junit no tiene un estándar ni definición de reportes.

Haciendo que falle la prueba, En FooTest.java
package sample;

import org,.junit.*;
import static.org.junit.Assert.*;

public class FooTest {
    @Test
   public void probarSaludar() {
       Foo foo = new Foo();
       String resultado = foo.saludar(“Java”);
       assertEquals(“Hola Groovy”, resultado);
}

Ahora el reporte muestra la falla.

En múltiples proyectos. Un problema con Maven es que no se nota si un hermano ha cambiado. Todo lo que cambia, se ejecuta, y luego el segundo hermano.

Creamos un directorio multi y dos subproyectos

> mkdir multi
> cd multi
> mkdir core ext
> mkdir -p core/src/main/java/foo
> mkdir -p ext/src/main/java/foo

En el core generamos una clase Version.java

public class Version {
   public static int getVersion() {
      return 1;
   }
}

Luego en el de extensión:

Extension.java
package foo;

public class Extension {
   pulbic String getNombre() {
      return “Foo: “ + version”
   }
}

En build.gradle

apply plugin: 'base'

version = '0.0.0.SNAPSHOT'

allprojects {
   repositories {
      jcenter()
   }
}

subprojects {
   apply plugin: 'java'

   dependencies {
      testCompile 'junit:junit:4.11'
   }
}

Con esto se evita duplicar info para proyectos hijos.

El build.gradle del core debe estar vacío en los proyectos hijos.

En el build del proyecto hermano:

dependencies {
   compile project(':core')
}

Por último, un archivo adicional le dice cuáles son los subproyectos que dirán cuáles son los subproyectos que incluirá:

settings.gradle
include 'core'
include 'ext'

En el raíz se especifica, bajo settings.gradle, la ruta y nombre de dónde se encuentra cada proyecto.

“${fileBAseName}.gradle”, el caso de una variable.

Al ejecutar el gradle del proyecto core, primero compila el core, luego la extensión, similar a Maven Reactor.

En el directorio de extensión, al cambiar la entrada, verifica si los recursos de entrada cambia. Con esto se evita trabajar con binarios desactualizados.

Puede pedirse que se limpie y se recompile

> gradle :core:clean

> gradle :core:test

Esas son grandes ventajas. El  proyecto que siga, que supere esto, en sus palabras, «será la bomba».

Para agregar dependencias solo a ciertos hijos

subprojects {suproject ->
   if (subproject.name == 'persistencia' {
      compile 'org.hibernate:hibernate:123'

 O bien, con persistencias de Groovy:
   if (subproject.name =~ /-persistencia/ {
      compile 'org.hibernate:hibernate:123'

Para plugin management

ext.hibernateVersion = '123'

Se pueden agregar propiedades en gradle.properties

ext.hbiernateVersion = '123'

Para integración continua, dependiendo el servidor de integración, por ejemplo travis.ml. After success pide a Gradle un generado para toda la cobertura. El ambiente de integración continua debe proporcionar la facilidad.

Con maven-publish se puede publicar a MavenLocal.

El pom se puede agregar una configuración declarativa

Algo para mencionar: estos archivos se ejecutan dos veces. La primera vez, para configuración, qué cosas son posibles, qué tareas, qué configs o repos y la fase de ejecución, cuando el grafo de tareas se construyó, y pueden agregarse o modificarse tareas. La documentación de Gradle es muy buena, superior a la de Maven. No solo basta qué tareas adicionales debo tener, sino qué tareas se ejecutan antes y después. En Maven se ejecutan alfabéticamente si usan Junit, o todo revuelto.

Puede especificarse si la tarea tiene éxito o fallo, se genere un reporte y que se hagan todas las pruebas de calidad. Al tener el control del orden, se compilan las pruebas, incluso de integración, una sola vez.

Pueden obtenerse jars locales y agregarse con flatDir o mediante MavenLocal.

MOJOs desde Gradle, el problema es el orden de búsqueda. No puede usarse el binario, pero el fuente sí.

grade.org describe DCL y sus plugins. Al menos 3 libros de O’Reilly, mrhaki.glogspot.com con nuevas monerías de features de gradle, groovy.

Es posible desde Gradle ejecutar tareas de Ant. No necesariamente de Maven, por bootstrap, debe configurarse una instancia adecuada. Pero se puede traducir la fuente del MOJO.


El receso fue reencontrarse con viejos amigos, conocer a nuevos y constatar que la tecnología avanza, pero es el factor humano quien le da sentido y los lazos humanos, la barrera donde nunca llegarán las computadoras. Pero en lo que sí son buenas las computadoras es en automatizar procesos, clasificar información y hacer cosas repetitivas tantas veces como se requieran. Y de eso habló el segundo tema, prubas con Spock.


Spock

El autor, austriaco, es un Trekie. El DSL de pruebas es lógico, evidente para crear las cosas. Puede incluso hacer dependencias circulares.

Escribió una prueba de Junit a la Java. Deben generarse campos para la prueba, un constructor y la inicialización de los parámetros. JunitUtils permite la parametrización de pruebas mucho más sencilla. Básicamente se crean casos de pruebas, uno por cada renglón.

En Spock es mucho más sencillo.

FooSpeck.groovy
package foo

import spock.lang.*

class FooSpec extends Specification {
   def voyAProbarAlgoConEsteMetodo() {
      given:
         List names = [
            'spock', 'kirk', 'bones'
         ]
      when:
         names = names*.capitalize()
      then:
         names[0] == 'Spock'
         names[1] == 'Kirk'
         names[2] == 'Bones'
   }
}

La primera parte es probar sin demasiados asserts. Si falla uno, ignoraremos si los demás también fallaba.

FooSpeck.groovy

package foo

import spock.lang.*

class FooSpec extends Specification {
   def voyAProbarAlgoConEsteMetodo() {
      expect:
         name.capitalize() == expected
      where:
         name  | expected
        'spock' | 'Spock'
        'kirk'    | 'Kirk'
        'bones' | 'Bones'
   }
}

En el bloque de definición, se tienenn strings y un assert sin usar. La biblioteca de Spock “secuestra” el compilador y Spock mueve el código para hacerlo adecuado. Por cada renglón creará una iteración y la asignará a cada variable, mucho más sencillo.

> gradle clean test

Exitosa

Al abrirla se obtiene una lista unificada. Para tener la de todas, o de cada una, puede agregarse:

FooSpeck.groovy

package foo

import spock.lang.*

@Unroll
class FooSpec extends Specification {
   def voyAProbarAlgoConEsteMetodo() {
      expect:
         name.capitalize() == expected
      where:
         name  | expected
        'spock' | 'Spock'
        'kirk'    | 'Kirk'
        'bones' | 'Bones'
   }
}

Un problema de la computación es darle nombre a las cosas.

def “Aplicar capitalize() a #name resulta en #expected”() en Spock es válido y lo utiliza.

La JVM permite utilizar muchos más carácteres, por ejemplo, una clase cualquiera:

def “”” y un multistring, sigue funcionando.

Spock define en especificación para los reportes. Permite agregar texto de manera simlar a Cucumber, etc. y reportes amigables al cliente.

Esta capacidad de expresión y pruebas dirigidas por datos son suficientes. ScalaCheck Engwise Testing. Si quisiéramos generar datos dinámicos:

FooSpeck.groovy

package foo

import spock.lang.*

@Unroll
class FooSpec extends Specification {
   def voyAProbarAlgoConEsteMetodo() {
      expect:
         name.capitalize() == expected
      where:
         name << ['spock', 'kirk', 'bones']
         name << ['Spock', 'Kirk', 'Bones']

   }
}

El powerAssert está desde Groovy 1.6 (en scala, Spocky es la alternativa).

Cualquier cosa que extienda iterable se puede consumir en la prueba, incluso conectarse a la base de datos.

FooSpeck.groovy
package foo

import spock.lang.*

@Unroll
class FooSpec extends Specification {
   def voyAProbarAlgoConEsteMetodo() {
      expect:
         name.capitalize() == expected
      where:
         name << ['spock', 'kirk', 'bones']
         name << ['Spock', 'Kirk', 'Bones']

   }
}

Las reglas @Rule de Junit 1.4 permiten ejecutar cosas antes y después. Lo importante viene debajo.

Puede usarse PowerMock, Mockito u otros.

Describió detalles para cleanupSpec. Para cada adicional, MockSpeck.

Mostró ejemplos de Asciidoctor con Mocks. Un mock es estricto en argumentos y orden. Puedo separar bloques mediante «and:» y lo revisará en el orden que se desee, al extremo de _ *  _._(*_)

En Spock no se llaman Spocks, no interacciones.

En Spock se pueden concatenar pruebas. Con @Stepwise se ejecutan los estados, basándose en el estado final de la prueba anterior. Funciona también con @Unroll.

EasyBee escribe escenarios, con referencias a otros escenarios. Dependencias hacia arriba, no hacia abajo, puede ser una buena idea para una extensión.

GmavenPlus y la jar de Spock es todo lo que se necesita para integrarlo a un objeto Java.

Springboot – Ratpack – es otro proyecto a considerar.

Mensaje breve del fundador de grails.org.mx para pedir ayuda de la comunidad from Grails.org.mx on Vimeo.

Y así de repente se fueron las horas, se quedó con ganas de seguir, y precisamente es el sentimiento que estas breves líneas desean impregnar: es momento de hacer florecer nuestras comunidades. Es tiempo de recuperar y continuar nuestra dinámica… pero esa, es otra historia, historia que invitamos a colaborar juntos, hombro con hombro.

Revisión: Groovy 2 Cookbook (3a. Parte)

En esta última parte comento la parte en mi consideración “épica” del libro, pues llegados a este punto los lectores encontraran concentrado y totalmente explotado el conocimiento de Groovy que se pudo adquirir en los capítulos anteriores.

Capítulo 8

Actualmente, el trabajo con WebServices es arduo y está lleno de API’s que en Java pueden facilitarnos la labor, sin embargo, con Groovy podemos hacer uso de las mismas clases que vienen dentro del lenguaje, que son realmente las clases de Java con algunos elementos adicionales, o bien, utilizar algo como HttpBuilder o WSLite, las cuales son librerías Groovy que nos ahorran mucha codificación y que son altamente expresivas. En mi opinión, una receta muy interesante de probar sería el uso de OAuth con Twitter.

Capítulo 9

Metaprogramación con Groovy, un tema que me gusta mucho, y me llamó la atención que viniera un tema de este tipo para los desarrollados Java que pudieran leer este texto, si bien al principio el autor muestra las características de Groovy, sirve también para que los lectores puedan comprender la forma en como funciona internamente Groovy.

Si en su momento pudimos ver cosas muy interesantes con el AOP, veremos cosas aún más interesantes y poderosas con el MOP. La receta llamada “Adding a caching functionality around methods” es definitiva un explotador de cerebros, hay que leerla detenidamente.

La creación de dos DSL’s muestran como Groovy puede simplificar la forma en la que se puede desarrollar una API en Groovy para desarroladores Groovy, aunque recomiendo mucho conocimiento de Java para comprenderla a la perfección.

Capítulo 10

Programación concurrente en Groovy, es el último capítulo de este libro, llegando a tocar uno de los temas que pueden llegar a representar un reto para muchos desarrolladores. Sin embargo, el autor nos lleva de un ejemplo basado en fork/join, reforzando con un ejemplo de múltiples tareas y la forma de partir una gran tarea en otras más pequeñas que se pueden ejecutar de forma independiente.

Me gusto mucho que hicieran uso de Ratpack, para después tratar otro tema: ejecuciones asíncronas. Y sin dejar de lado el modelo de concurrencia más comentado, se describe el famoso esquema basado en Actores, para dar paso a una receta que usa Software Transactional Memory y DataFlows, de los cuales me hubiera gustado que profundizará un poco más pues hay muy poca difusión de estos últimos, sin embargo, los ejemplos que demuestran a cada uno hacen justicia al libro.

Conclusión

En definitiva es un libro muy intenso, requiere de un buen conocimiento del lenguaje Java para poder aprovecharlo, y refuerza muchos conceptos del mismo lenguaje. Es un libro para que el desarrollado Java use a Groovy como una opción a elementos muy particulares que llegue a necesitar y que pueda implementar, me imagino que existió algo de inspiración en la parte empresarial, y por eso se tocaron algunas recetas como se hizo.

Indudablemente, los autores tienen un conocimiento profundo del lenguaje, lo demuestran plasmándolo en cada receta, y la mejor parte parte es la explicación puntual de cada una, sin dejar escapar ningún detalle.

Si eres un programador Java que quiere mejorar su código de forma sustancial, entonces este libro es para ti.

Aprovechando que ando haciendo esta revisión y estoy terminando precisamente en estas fechas los chicos de PacktPub tienen una promo en donde compras un ebook y te dan otro gratis. Lo hacen por la publicación del libro número 2000, lo cual hace que PacktPub tenga una gran variedad de temas plasmados en textos.

2000th-Book-Home-Page-Banner

Revisión: Groovy 2 Cookbook (2a. Parte)

Nuevamente y continuando con la revisión de este libro, he de sostener la especialización que tiene acerca del lenguaje, el uso de Java dentro de cada una de las recetas simplifica de forma elegante, expresiva y muy bien explicada.

Capítulo 4

El uso de Reader, Stream y File requiere de un buen conocimiento de los mismos para comprender que es lo que está explicando el autor. Hace uso muy aventajado de las API’s disponibles en el GDK a través del manejo de archivos y flujos de datos. Durante el desarrollo de este capítulo podremos ver la solución a la automatización de algunas tareas comunes que se pueden presentar en proyectos de software. Una de las partes que podría llamar la atención a los lectores podría ser el manejo simplificado que hacen con ayuda de API’s de terceros para la manipulación de documentos Excel y PDF, e inclusive, el uso de recursividad para explorar archivos y directorios.

Para el conocedor de Groovy, tal vez le pueda interesar la forma en que profundizan la API de File.

Capítulo 5

El siempre difícil XML, tratado en este capítulo con ayuda de XmlSlurper y XmlParser, el manejo de namespaces, y muchos de los problemas que se puede enfrentar para su manejo, solucionados con la ayuda de varias recetas. Groovy hace trivial el manejo del XML, sin embargo, un tema de mi interés y que me agrado mucho fue la modificación de XML, así también, el ordenamiento. Adicionalmente, durante el transcurso de este episodio se muestran algunas bondades más del manejo de colecciones con Groovy.

Adicionalmente, es interesante ver como se usan los conocimientos adquiridos en capítulos anteriores.

Capítulo 6

Desde la versión de Groovy 1.8 se tiene un soporte para el manejo de JSON que viene incluido dentro de la estructura del lenguaje. Y aunque el manejo de JsonSlurper y JsonBuilder pueden resultar en extremo simple, los autores explican de una forma muy detallada la forma en que funcionan, lo cual, ayuda a sacarle más provecho a cada componente.

Un tema que el desarrollador Groovy podría encontrar interesante sería la modificación de documentos JSON, además de la validación.

Me causa curiosidad la necesidad que tuvo el autor de convertir JSON a XML, sin embargo, lo resuelve de forma muy elegante.

Y la propuesta de almacenar configuración externa en un archivo JSON sin lugar a duda es una excelente propuesta para cualquier proyecto que use Java o Groovy.

Capítulo 7

En esta ocasión, recomiendo que la lectura de este capítulo sea mayormente lineal, o por lo menos, leer las primeras recetas pues la mayor parte de ella se basa en estas o hace referencia a su código.

Me da la impresión de que los autores conocen muy bien la API de JDBC y la han sufrido, al mostrar como se puede simplificar la vida usando Groovy. Creo que una de las mejores partes de las recetas hasta este momento son el detallar las explicaciones de como funciona el código Groovy, lo que le daría confianza al conocedor del lenguaje Java. En mi opinión una de las cosas más atractivas del lenguaje Groovy es el GDK, y entre ellos la abstracción que hace al uso de la API de JDBC; me gusta que incluso se tratan temas como el uso de LOB’s, procedimientos almacenados, transacciones y operaciones en batch.

Y sin lugar a dudas, tocar los temas de NoSQL con Groovy pueden introducir a un nuevo paradigma de acceso a datos a los desarrolladores, y dulcificarlos con la sintaxis de Groovy es gentil para quienes no los conocen; y aunque los autores asumen conocimiento en dichos manejadores de acceso a datos, no dejan de lado tener una referencia y una breve introducción a ellos.

Conclusión parcial

Llegado a este punto, considero que el programador Java encontrará fascinante la forma en como Groovy simplifica el uso del lenguaje, y el programador Groovy encontrará útil la forma en que los autores describen el funcionamiento de las soluciones. También, considero que el profundizar en el funcionamiento del lenguaje le dará confianza en el uso del lenguaje a todos los desarrolladores pues resuelve el misterio de la magia de Groovy.

Revisión: Groovy 2 Cookbook (1a. Parte)

En esta ocasión y con mucho gusto traigo a ustedes la revisión de un libro de Packt Publishing: Groovy 2 Cookbook.

De antemano agradezco la oportunidad a los miembros de esta librería por dejarme hacer esta breve revisión, esperando que les pueda servir de buena referencia para conocer más acerca del lenguaje Groovy.

Si bien, he de mencionar que los libros de PacktPub son especializados, y tienen un nivel de expertise muy alto pues en los que he leído solicitan ya un nivel de conocimiento, lo cual es comprensible para los temas que se desean tratar. Y si lo que queremos es conocer en pocas palabras acerca de este libro, lo que puedo decir es que en mi opinión es una lectura recomendable para el desarrollador que domina el lenguaje Java y desea usar Groovy, pues considera y usa elementos que son por más esenciales en el lenguaje.

También he decir que como desarrollador Groovy te puedes llevar varias sorpresas pues ejemplifica el uso del lenguaje dinámico de formas que en lo personal no había considerado. Además que la profundidad y la estructura del código es lo necesaria para comprender la “magia” de Groovy; es importante mencionar, que es un libro de recetas y por lo tanto puede ser tomado como un texto de consulta, aunque recomiendo que el primer capítulo sea leído de forma líneal.

Capítulo 1

Es muy interesante ver la forma como algunos elementos que consideramos esenciales para el uso de Groovy son llevados a una forma o enfoque distinto, incluso mostrando como se puede usar Groovy como elemento de línea de comando tal como lo haría grep o awk. La forma en como se profundiza en el uso de las nuevas características de Java 7 con InvokeDynamic es muestra de que los autores conocen bien las ventajas del uso de Groovy 2, así también, nos muestran a construir Groovy desde el código fuente y configurar nuestros IDE’s.

Capítulo 2

Para el desarrollado que gusta de Java pero desea conocer que le puede ofrecer Groovy le puede servir mucho este capítulo. La integración con sistemas de construcciones existentes como Ant y Maven son cubiertos, aunque, muestra también la dulzura del uso de grape y grade. Y por si fuera poco, nos provee de una integración con una herramienta de análisis para que nuestro código sea más Groovy.

Capítulo 3

Para este punto ya tenemos la necesidad de saber que se puede hacer realmente con Groovy y como me puede ayudar en mi día a día. En este capítulo se comienza a tratar con elementos que en Java son muy verbosos y que con Groovy podemos simplificar como: Expresiones regulares, JavaBeans, clonación y herencia. Pero mejor aún, se muestra la forma en que Groovy puede implementar Mixins o Delegados, y la diferencia detallada de los elementos que se ejecutan en Runtime o los que están dentro de la fase de compilación. Así también, el uso de Groovy como un lenguaje de compilado estático, algo que sólo esta disponible en la versión 2 de Groovy y que ayuda mucho a que desarrolladores Java no se sientan sin el soporte del chequeo de tipos.

Algo que me llamo mucho la atención es algo que había visto desde el enfoque de lenguajes funcionales como Lisp, pero que en esta ocasión los autores evidencian con dos secciones llamadas:

Definiendo código como datos en Groovy
Definiendo estructuras de datos como código en Groovy

Y aunque de primera vista podría parecer muy extenso o complicado de entender, los autores hacen un gran trabajo para explicar todo lo que acontece sin dejar pasar ningún detalle.

Espera la segunda parte de mi revisión, yo creo que serán tres entradas, siendo esta una de ellas.

Quickstart: JMS en Grails

El uso de JMS dentro de las aplicaciones Java es una de las piedras angulares dentro del desarrollo JEE; permite que las aplicaciones se comuniquen de forma fiable por medio de mensajes asíncronos enviados a través de un broker e mensajería. JMS es bueno para sistemas distribuidos o procesamiento de tareas, lo cual puede ayudar a la escalabilidad.

Elementos esenciales para el uso de JMS

Existen dos elementos esenciales en JMS, un productor de mensajes y un consumidor de mensajes. Así también, existen dos estilos principales para el envió de mensajes y para su consumo: Queues(Colas) y Topics(Tópicos).

Un Queue es un mecanismo punto-a-punto que usa el estilo de de almacén y reenvío para entregar un mensaje de un productor a un consumidor.

Un tópico es un mecanismo del tipo pub-sub donde una aplicación envía un mensaje  y todos los puntos que se han suscrito al tópico reciben el mensaje para procesarlo mientras estén activas.

Spring y el JMSTemplate

“La clase JmsTemplate es central en el paquete básico de JMS. Simplifica el uso de JMS ya que se encarga de la creación y liberación de recursos al enviar o recibir mensajes de forma sincrónica.”

El JmsTemplate requiere una referencia a un ConnectionFactory, y este a su vez se referencia hacia el broker.

El envío de mensajes como lo resume Spring se puede ensamblar de la siguiente manera:

ConnectionFactory->Connection->Session->MessageProducer->send

La aplicación puede recibir mensajes si implementa un message listener. Y Spring a través del soporte de JMS permite implementarlo de forma muy sencilla con lo que denomina Message Driven POJO, por lo tanto no necesitamos codificar la interface MessageListener.

Sin embargo, aunque podríamos implementarlo de forma conveniente, Spring nos provee del MessageListenerAdapter que es una forma de registrar un listener para recibir un mensaje sin ser invasivo con elementos de Spring.

La referencia que se hace aquí considera un poco de profundidad en temas como:

  • Queue
  • Topic
  • Listener
  • Service Activator
  • Spring JMS
    • ConnectionFactory
    • Connection
    • Message Listener Containers

Que muy bien están detallados en la documentación de Spring JMS.

El plugin de JMS para Grails

Muchos de los componentes mencionados anteriormente están ensamblados con el plugin de JMS, sin embargo, tenemos que indicar algunos de ellos como el broker y el ConnectionFactory.

Los elementos que describo durante la redacción de este artículo se ejecutaron con la versión de Grails 2.3.4, la cual, al parecer no resuelve algunas dependencias esenciales para su uso con JMS, por lo tanto una serie de elementos en el BuildConfig es necesaria.

Para comenzar con el uso del plugin tenemos que declararlo en la sección de plugins BuildConfig.groovy:

[sourcecode language=”groovy”]
plugins {
//…
compile ":jms:1.2"
//…
}
[/sourcecode]

Una característica de ActiveMQ es que con sólo agregar la JAR a nuestro CLASSPATH, podemos contar con un broker de mensajería listo para usarse, el cual esta embebido en la JVM que nos ayuda a levantar la aplicación. Por lo tanto podemos agregarlo a nuestra sección de dependencias. Adicionalmente con la versión de Grails y la versión del plugin en cuestión surgen algunos problemas al no poder resolver algunas clases de SpringJMS por lo que agregarla también es necesario.

[sourcecode language=”groovy”]
dependencies {
compile(‘org.apache.activemq:activemq-core:5.3.0′,
‘org.apache.activemq:activeio-core:3.1.2′,
‘org.apache.xbean:xbean-spring:3.7′) {
excludes ‘activemq-openwire-generator’
excludes ‘commons-logging’
excludes ‘xalan’
excludes ‘xml-apis’
excludes ‘spring-context’
exported = false
}
compile ‘org.springframework:spring-context:3.2.5.RELEASE’
compile ‘org.springframework:spring-jms:3.2.5.RELEASE’
}
[/sourcecode]

Adicionalmente, tenemos que configurar  un par de beans adicionales con ayuda de resources.groovy, para definir nuestro ConnectionFactory.

[sourcecode language=”groovy”]
import org.apache.activemq.ActiveMQConnectionFactory
import org.springframework.jms.connection.SingleConnectionFactory

beans = {
jmsConnectionFactory(SingleConnectionFactory) {
targetConnectionFactory = { ActiveMQConnectionFactory cf ->
brokerURL = ‘vm://localhost’
}
}
}
[/sourcecode]

Para demostrar la funcionalidad del envío de mensajes, supongamos que tenemos una clase de dominio y su scaffold, haremos uso de ello para sobreescribir algunos métodos y mandar el procesamiento hacia el broker de mensajería.

El productor de mensajes en el controller

El plugin de JMS nos provee de un servicio que ayuda al envío de mensajes, tiene un método ‘send’ que provee varias implementaciones para su uso, te recomiendo que veas la documentación del servicio.

Nuestro controller quedaría:

[sourcecode language=”groovy”]
package com.makingdevs

class ProjectController {

static scaffold = Project
def jmsService

def save() {
jmsService.send(queue:"project.new",params,"standard",null)
flash.message = "Project creation queued"
redirect(action:"index")
}

def update(){
jmsService.send(topic:"project.update",params,"standard",null)
flash.message = "Project updating queued"
redirect(action:"index")
}
}
[/sourcecode]

El consumidor de mensajes

Una vez implementado el controller, procedemos con la creación del consumidor, el cual delegamos a una clase de Servicio de Grails, el Service Listener, como se denomina ahora esta clase debe de tener un atributo estático que defina la exposición de JMS para el plugin y contar con un método ‘onMessage’, como la interfaz MessageListener.

[sourcecode language=”groovy”]
class ProjectService {

static exposes = ["jms"]

def onMessage(msg) {
// handle message
}
}
[/sourcecode]

Sin embargo, el plugin provee de anotaciones para indicarle a un método que se expone como un listener de JMS que sea quien reciba el mensaje y actúe. Dicho método puede ser un Queue o un Topic, las anotaciones @Queue y @Subscriber nos ayudan a definir y direccionar el envío de mensajes, nuestro servicio quedaría:

[sourcecode language=”groovy”]
package com.makingdevs

import grails.plugin.jms.*

class ProjectService {

static exposes = ["jms"]

@Queue(name="project.new")
def createInQueue(msg) {
println msg
def p = new Project(msg)
p.save()
null
}

@Subscriber(topic = "project.update")
def updateInQueue(msg){
println "updateInQueue : ${msg}"
null
}

@Subscriber(topic = "project.update")
def updateBackupInQueue(msg){
println "updateBackupInQueue : ${msg}"
null
}
}
[/sourcecode]

Al correr nuestra aplicación y navegar el scaffold, podremos ver claramente en la consola los deplegados respectivos en pantalla, notando que la llamada al Queue se ve reflejada al persistir una entidad, y la llamada a dos métodos servicio que son el Topic se ejecutan de forma simultánea al ejecutar un update. Para más información de como consumir un mensaje te recomiendo eches un vistazo a la documentación del plugin.

Conclusión

La implementación de JMS ayuda mucho a crear aplicaciones que inician a demandar escalabilidad o delegar el procesamiento de un componente que requiere de tiempo para ejecutarse. Java nos provee una implementación robusta de JMS, y Grails nos facilita mucho incorporarlo a nuestra aplicación; embeber el broker con ActiveMQ y la abstracción del servicio que provee el plugin acelera la implementación pues con un servicio convencional de Grails se puede exponer un consumidor.

Nueva Imagen de GrailsMX

Hola a todos, esta vez les anuncio que hay una nueva imagen de GrailsMX fue renovado para ustedes con la finalidad de brindarles una nueva y renovada imagen.

[layerslider id=”9″]

“Nueva imagen, nueva estructura” para mayor fluidez y organización del sitio como el menú en el cual esta perfectamente estructurado nuestros blogs sobre los diferentes temas que tratamos además de un apartado exclusivo del Podcats de GrailsMX en cual podrán escucharnos o subscribirse al feed.

Gracias al nuevo apartado en la pagina principal y en el nuevo diseño los blogs es mucho mas claro y flexible al leer. Ademas de que lo podrás consultar desde cualquier parte en al que te encuentres gracias a que el sitio se puede visualizar en cualquier dispositivo móvil.

En la parte inferior del sitio podrán encontrar otros sitios de la comunidad de Software en los cuales también nos podrán encontrar, colaborando con otra interesantes tecnologías del desarrollo del software.

Podcast de GrailsMx, temporada 2 episodio 7

Hola a todos, les damos la bienvenida @neodevelop y @tomaslin les traemos nuevamente la emisión del podcast.

En esta ocasión platicamos de nuestra experiencia en el evento al que tuvimos la oportunidad de asistir como Grails Champions, este es el SpringOne2GX, el cual tuvo sede en Santa Clara y es uno de los eventos más importantes que tiene la comunidad de Spring, Groovy y Grails.

Es grato platicar nuestra versión de lo acontecido y compartirlo con ustedes, además de comentar los sucesos no oficiales que pudimos tener en compañía de la gente que está alrededor del ecosistema Grails. Adicionalmente, durante el networking diario tuvimos el honor de conocer a más desarrolladores que con gusto comparten su conocimiento con nosotros, entre ellos algunos ponentes y la gente de SpringSource ahora renombrada como SpringCentral. Continue reading Podcast de GrailsMx, temporada 2 episodio 7

Podcast de GrailsMx, temporada 2 episodio 6

Hola a todos les damos la bienvenida @neodevelop y @tomaslin les traemos nuevamente la emisión del podcast en donde estamos hablando de cloud.

Hablamos de como a crecido exponencialmente la “nube” hablando en el desarrollo de software y como esto a ayudado a que sea mas interesante el desarrollo web. Ademas hablamos en que benefician del uso de la nube para despliegue de aplicaciones y otras herramientas que facilitan poner una aplicación grails en producción o hacer pruebas de concepto.

Algunos Links sobre lo tratado:

   – Infrastructure as a service

   – Amazon EC2
   – Elastic Beanstalk / S3 /
   – Aasgard / Ice de Netflix
   – Digital Ocean
- Platform as a Service
   – Cloud Foundry
   – Openshift
   – Google App Engine
   – Heroku
   – Jelastic, Appfog, Anynines
   – DotCloud
Grails + Cloud Foundry / Heroku
- Software as a service
  – Cloud IDEs
     – Nitrous.io
     – Cloud9 IDE
  – Jenkins / Build / testing
    – Cloudbees
    – Drone.io
    – Sauce Labs
    – Travis CI
    – Cloudbees BuildHive

En fin, hablamos de varias cosas, esperamos que les sirva tanto como a nosotros.

Suscríbete al feed en http://grails.org.mx/feed.xml

O bien descargalo en directo desde:

Aqui

Muchas gracias por escucharnos !!!!

Podcast de GrailsMx, temporada 2 episodio 5

Hola a todos les damos la bienvenida @neodevelop y @tomaslin les traemos nuevamente la emisión del podcast en donde estamos hablando de Testing con Grails.

En esta ocasión hablamos con nuestro compañero Tomas Lin desde Londres, es una charla muy interesante sobre Testing con Groovy Grails cosas interesantes como estas herramientas nos ayuda a realizar un testing. tambienb de algunas otras herramientas o micro framework y la comparación de utilizar Grails.

Algunos Links sobre lo tratado:

http://grails.org/plugin/partition-tests

https://github.com/tomaslin

https://github.com/mjhugo/grails-auto-test

http://grails.org/plugin/improx

https://github.com/neodevelop/atdd_tdd_groovy_grails_gradle

En fin, hablamos de varias cosas, esperamos que les sirva tanto como a nosotros.

Suscríbete al feed en http://grails.org.mx/feed.xml

O bien descargalo en directo desde:

Aqui

Muchas gracias por escucharnos !!!!

¡como usar grails?

hola, estoy haciendo una pagina y estoy relacionando domains,   cuando corro grails,  donde me despliega la opcion para escoger que es lo q quiero mostrar  me muestra la ruta y la ip.

ejemplo

estoy relacionando  horario con materia , entonces en materia me despliega una ventanita para elegir que horario elegir en vez de mostrarme

lo que tengo en horario q es hora de inicio , hora de fin y dia me muestra la extencion (BASEDATOS.HORARIO.1) como le hago para

cambiar esa extencion por una palabra en especifico ya sea hora de inicio , hora de fin o dia.

saludos.

pd. no se si estoy en el lugar correcto para preguntar , si no es asi una disculpa.