style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Resumen de la tercera emisión de OpenTalks de JavaMéxico

Bastantes minutos después de la cita, con fila en espera de la llegada del encargado al que aparentemente no recibió el memo sobre este evento en el cada vez más socorrido Telmexhub, inició con comentarios distintos y mucha expectativa la primera charla a cargo de Andrés Almiray (aalmiray en Twitter), titulada "Introducción a Groovy", seguido de Juan Carlos Castrejón (jccastrejon en Twitter) y "Model-Driven Software Development". Era tiempo de iniciar la tercera emisión de las OpenTalks.

Introducción a Groovy

Groovy es un lenguaje para la Java Virtual Machine. Hay más de 250 lenguajes, muchos de ellos experimentales. El Ing. Almiray comenzó dando una visión panorámica, incluyendo los proyectos alrededor del lenguaje, por ejemplo, los varios niveles de ecosistemas como Grails, para desarrollo Web, o Griffon, para aplicaciones de escritorio.

Como características principales del lenguaje, es un lenguaje de tipado opcional, no estático, soporta closures, sobrecarga de operadores y metaprogramación, invocación dinámica de métodos (el método puede invocar buscando el método en las distintas rutas): Groovy realiza esta búsqueda en tiempo de ejecución; por eso se dice que es lento, pues este mecanismo repercute en el rendimiento. En realidad, Groovy es ligeramente más lento, pero el lenguaje no es el problema, sino el acceso a la base de datos o el disco. Cuando se compila Java, el método debe existir, en Groovy se puede compilar sin que esté el método. Sobrecarga de operadores, extender la biblioteca estándar de Java, por ejemplo, ofrece la posibilidad que una clase final tenga una extensión.

La sintaxis de Groovy es igual a la de Java. El 99% del código es compatible con Java. Sólo es preciso tener cuidado al inicializar arreglos.

Entre los recursos que ofrece Groovy está la Groovy Console, una aplicación visual. El expositor la abrió y escribió un POJO.

private String nombre;
public string getNombre {
    return nombre;
}
public void setNombre(String nombre) {
    this.nombre = nombre;
}
public static void main(String[] args) {
    Bean bean = new Bean ("Java");
    System.out.println(bean.getNombre());
}

Ensguida enumeró características que hacen de Groovy muy flexible y poderoso:

  1. En Groovy los modificadores de acceso son privados. Quitó "public" y sigue siendo código válido.
  2. El «;» es opcional (los quitó).
  3. Para declarar una propiedad el compilador hace setters, getters y acceso a propiedades. Podría ser más ligero:
    bean.nombre = "Java"
    

    mientras que:

    System.out.println(bean.nombre)
    

    se puede escribir:

    println bean.nombre
    
  4. Definir propiedades en el propio constructor. Usado mediante llaves. Por omisión, Groovy no soporta el alcance "protegido de paquete", pero puede habilitarse con una extensión.
  5. Agregar un método de negocio (antes del main):
    public string hola (String s) {
        return "Hola " + s
    }
    

    y en main, hasta abajo:

    println bean.hola ('mundo!')
    

    Se pueden omitir palabras clave como return. Se pone explícito return en este caso porque hasta Groovy 1.6 y 1.7 era necesario poner return en bloques if-else.

    def hola (s) {
       "Hola ${s}"
    }
    

    Groovy soporta código fuera de la clase. Puede ponerse un script, no sólo clases.

Haciendo gala de un juego de palabras en inglés: «Groovy can see your privates», es decir, por sus características, puede ver "más de la cuenta".

Más características de Groovy son los operadores:

  • « ?. » Navegación segura, brinca en navegación de objetos y si uno de los elementos es Null, devuelve "The Groovy Truth".
  • « ?: » (llamado operador "Elvis" por semejanza a un emoticon) es un simplificador del operador ternario: sólo se escribe la condición y el falso; se omite el verdadero.
  • « * » (spread) Explosión, si se puede construir.
  • « <=> » (llamado nave espacial) comparación.

Tras esto, se fue al código:

class Foo { String n }
class Bar { Foo foo }
foo = new Foo(n:'foo')
bar = new Bar(foo:foo)
println foo
println bar
println bar.foo.n
bar.foo = null
println bar.foo?.n.length() //también se puede asignar
println bar.foo?.n?.length() //y ya quedó

A continuación mostró "la verdad Groovy", pero antes, el operador =

foo2 = new Foo (n:'foo')
assert foo = foo2

Groovy hace uso de power asserts.

boolean equals(o) {n == o?.n }

Con ello se usa el operador. En cuando se tenga el operador, puede usarse.

Mapas en Groovy

map = [:] //vacío
map = ['llave':'valor']

println map.llave //notación de propiedad
println map[llave] //notación de arreglos
println map.getClass()
list = []
list = [1,2,3,'ab','cd']
list = ['ab','cd','123']
list*.size //obtener el tamaño de la lista y meternlo en otra, en Groovy

Podemos usar la sintaxis de lista y con la palabra «as», cambiarlo de tipo. Además, concatenar listas con « + », restar listas con « - », multiplicar la lista con « * ». Para sobrecargar el operador:

[1,2,3]*.multiply(2)

Regresa [2,4,6]

list = [1,2,3]
list.add(4)
list << 5
println list

En Groovy no es necesario preocuparse por excepciones de más:

f = new File ('foo.txt')
f.text = "Hola Mundo!"
g = new File ('foo.txt')
println f.text

Cambiando de tema, se dirigió a la metaprogramación y closures

String e Integer son finales, pero con Groovy se puede hacer este truco:

class Foo {
    static pounce(Integetr i) {
        (1..i).collect(){'boom'}.join(' ')
    }
}

use(Foo) {
    3.boom()
}

Sin declarar argumento en un closure. Descubrió el proceso: se utilizó «.collect» para hacer 3 listas, «.join» para unir esas listas en un String.

Integer.metaClass.boom2 = {
    (1..delegate).collect() {'boom'}.join(' - ')
4.boom2()
}

Si la clase no tiene un método dado, comienza a recorrer la jerarquía. El siguiente ejemplo se muestra pasado por parámetros:

    (1..delegate).collect() {s}.join(' - ')
4.boom2('java')

Regresa la cadena «java – java – java – java». Enseguida, el patrón "Singleton":

@Singleton
class Foo {
    String n
}
Foo.instance.n = 'foo!'
Foo.methods.name.each {println it}

En arreglo de métodos, o bien:

Foo.methods.name.sort().each {println it} //Transformación de AST
    new Foo(n:'otro')

En clases inmutables:

@Immutable
class Foo {
    String n
}
Foo.metaClass.methods.name.sort().each {println it}

Así de sencillo. Con immutable es válido, sin él, no.

f1 = new Foo(n: '1')
f2 = new Foo(n: '1')
assert f1==f2
f1.2 '2' //Groovy no lo permite

Groovy compila Groovy y Java al mismo tiempo. Esa habilidad sólo Scala puede hacerla también.

Groovy no es el lenguaje solo. Alrededor de él hay Frameworks completos, como Grails. En un emulador de terminal:

$ grails create-app

Cuando el comando terminó, mostró la estructura básica de directorios.

$ grails create-domain-class libro
$ grails create-controller libro

Le agregó 2 restricciones. La ventaja es no tener que preocuparse sino en la lógica de la propia aplicación. Groovy utiliza «gsp» en lugar de «jsp».

$ grails war

Griffon es un Framework similar a Grails, dirigido a aplicaciones para escritorio. Mostró un diccionario pequeño, similar al del capítulo 9 del libro "Griffon in Action". Aunado, enseñó características esenciales de Google AppEngine, Gaelyk (llamado por muchos el PHP de Groovy) disponible en gaelyk.appspot.com, a Gant y, al hablar de Gradle. Mostró una tarea de Gant que utiliza en la construcción de Griffon. Gracias a Groovy y su asignación mútiple y a AntBuilder, tiene una flexibilidad y un poder que les hace merecedores de evaluarlos detenidamente.

Debido a tanta configuración en Ant, Gant o Maven nace Gradle. Describió un archivo que tenía consigo, comparando la rápida forma para construir proyectos. En desarrollo dirigido por comportamiento, enlistó 2 herramientas de pruebas: easyB, con reportes HTML, y Spock, describiendo sus reportes. Además, codenarc para análisis estático de código, un tanto difícil de entender al principio, pero no imposible, gPars, con mejor soporte de "actores" a la manera Scala, inspeccionando código.

En la parte de preguntas y respuestas se cuestionó la manera Groovy de hacer XML:

builder = new groovy.xml.markupBuilder()
xml = builder.root {
    compania(nombre: 'Acme') {
        empleados {
            empleado(nombre: 'Foo')
            empleado(nombre: 'Bar')
        }
    }
}

root = new groovy.xml.XmlSlurper().parseText(xml)
root.compania.empleados*.nombre

Regresa una lista XML con Foo y Bar.

Se habló de AST, por cada token una clase para encapsular el elemento. Mostró una transformación de AST en Griffon, y con ello, terminando su muy brillante intervención. Allí se comunicó que recientemente el Ing. Almiray había sido nombrado "Java Champion". Su cuenta de Twitter es aalmiray y la de su proyecto Griffon, theaviary. La página principal del proyecto Griffon se ubica en http://griffon.codehaus.org/ y la del proyecto Groovy en http://groovy.codehaus.org/.


Antes de la segunda charla, Erick Camacho (ecamacho ecamacho en Twitter) llegó a hablar de la JavaCup y los mecanismos del concurso.

La segunda charla, Model-driven Software Development, por Juan Carlos Castrejón, inició prácticamente enseguida del anuncio.

¿Cómo se logra llevar a cabo este modelo? Tradicionalmente, mediante 3 fases: 1) qué se va a hacer, 2) cómo implementarlo y 3) probarlo. La idea general, la propuesta en los años ochenta por los CASE para la parte estática del sistema.

¿Cómo tomar las características principales de lago para representarlo? Por la abstracción. En cuanto la calidad de software: ¿cómo decir que un sistema tiene calidad? No se hace lo que no se sabe.

Interoperatibilidad: solución sin pensar ni en el lenguaje ni en portabilidad. La idea es que el modelo no sea sólo documentación, sino dirija el desarrollo. Para modelar, UML, EMF (Eclipse Modelling Framework) en los años 2000, o EMOF, lo más básico del modelado. Así desarrollan los modelos como un diagrama de clases.

En una aplicación básica, con EMOF se modela, transformándolo a Eclipse, posteriormente pudiendo modificar el modelo, creando, borrando en el editor. Con el estándar XMI para que compartan datos entre sí. En la práctica, XMI no es perfecto. No funciona para Web como tal.

Entre los proyectos para dar ese soporte, Acceleo genera aplicaciones Spring, Hibernate y Strouts, haciendo que la herramienta haga lo necesario "tras bambalinas", por ejemplo, en Grails. Otro, AndroMDA, que genera código desde plantillas. Si la aplicación cambia, el código deberá cambiar acorde.

Por otro lado, herramientas como Spring Roo generan una aplicación desde la línea de comandos, sin programar código fuente a partir de una abstracción hacia una aplicación Web. En Roo, se hace un metamodelo, de allí se modela y se hacen instancias. ¿Cómo se crean aplicaciones y se extienden? Mediante perfiles en UML o enotaciones Ecore. Esas transformaciones suceden gracias, por ejemplo, a ATL Query, a partir de ello, los perfiles y las anotaciones que lleven a los agregados de Model2Roo. El reto es general la aplicación utilizando nada más comandos de Roo.

Tras este panorama en Eclipse, abrió Elipse Modelling. El modelo es importante para que Ecore trabaje, por ello, abrió un Wizard y creó una aplicación sencilla. El Ing. Castrejón eligió entre las opciones crear un diagrama de Ecore.

Jaló un elemento Objeto y fue dándole atributos, hizo más objetos y les puso relaciones. A partir del diagrama, mostró con un plugin, la transformación de un diagrama de Ecore a uno de Roo. En el diagrama resultado no se aprovechan todas las características de root, pero es un buen comienzo.

Con otro plugin jaló características para Roo que sólo Roo entiende, es decir, si se ocupara para .NET ignoraría lo específico que estuvo agregando para Roo. Tiene la facilidad que se pone el modelo y el agregado elige qué app se hará cargo de ello. El plugin de Eclipse puede importar también de Roo y hará los modelos.

Para crear pruebas, basta con jalar componentes que crearán a su vez XML. Con el modelo se buvo una aplicación local con Eclipse y una Web con comandos Roo. Si mañana se utilizara con Grails, se pondría un implementador. La ventaja es código que considera "mejores prácticas" para conocer nuevas tecnologías y con código mejor al que se hiciera si no se conociera dicha tecnología. En Model2Roo, mostró cómo cambiar los predeterminados para cada comando.

Recomendó un interesante libro de Eclipse. Lo que hacían era modelar, MOF, de él viene EMOF y del segundo, Ecore. El "meta-metamodelo" se consideraría como abuelo, el metamodelo como padre. Para no tener que descargar todos los paquetes, Eclipse Modelling Tools tiene todo lo necesario. Ese paquete también está disponible con la distribución de Roo y ATR.

Del modelo se generan comandos de Roo y de allí la aplicación. Se hace por anotaciones y el ainado para no saber los específicos, ni utilizar comandos. En el área de convertir UML2 a Roo existen distintas propuestas, una de ellas encabezada por el ponente. Para diagramas de secuencia, proyectos varios medianamente lo abordan. Model2Roo se basa en el fundamento de Elipse Modelling. El chiste es utilizar el nivel más alto de abstracción del modelo, sin necesariamente saber el lenguaje o Framwork (Grails, Roo, etc.). Este modelo de desarrollo de software tiene más de 10 años de utilización, sobretodo en el ámbito académico. Con años de investigación y bastantes casos de éxito, utilizando transformaciones y alcances se puede modularizar.

Una vez terminada esta charla, se regalaron 2 licencias de IntelliJ Idea y 5 cupones de descuento para libros de Apress. La gente permaneció bastante tiempo platicando e intercambiando puntos de vista. Hubo mucha asistencia y se unieron asistentes regulares al Telmexhub en distintos puntos de las charlas, producto de la exposición de la sala asignada. A lo largo de las dos pláticas hubo mucha atención y entre ellas, bastante networking humano. Una muy agradable experiencia este cambio de sede, abriendo las posibilidades para llevar estas charlas a otros lares, para que sigamos conociéndonos y reconociéndonos en vivo.

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

codehaus

Es codehaus, no codehause...

Imagen de Shadonwk

No manches, creo que despues

No manches, creo que despues del choro que practicamente describio a detalle toda la charla un error de dedo se le perdona je.

Imagen de bferro

Abogado de Enrique

Enrique no lo hace por criticar. De eso estoy seguro. Las correcciones siempre son bienvenidas y contribuyen a la calidad del sitio.

Imagen de ezamudio

Es por la liga

No es crítica, pero creo que sí es importante corregir la dirección del sitio, sobre todo porque pone las ligas al final para que los interesados puedan bajar Groovy y Griffon o al menos leer al respecto.

No es por molestarte Enrique

No es por molestarte Enrique pero le debes una lanisima a bferro por eso de la defenciada....

Ya en serio: creo que es bueno hacer las correcciones porque este es un sitio de consulta, donde algo erroneo puede hacer que los que lo lean se queden con ese mal concepto... me ha tocado que los EJB los escriben como "Entreprise Java Bins"... Ademas enrique es como el conserje del sitio (lo digo de buen modo pues no creo que haya alguien que conozca mas acerca del contenido que aqui se ha publicado) y las correcciones que hace no son para molestar (como bien dice bferro) pero si son para notar algun error de cualquier tipo que se haya hecho pues yo he visto que (como en este caso) hace correcciones simples asi como correcciones mas elaboradas en las que se requiere verdadero conocimiento profundo de un tema... Si sus correcciones se toman como critica, alegrate que lo hizo alguien que SI SABE lo que dice y no alguien que nadamas anda faroleando copiando y pegando lo que encuentra en Google/Wikipedia/(hasta rincon del vago) (a mi tambien me ha tocado que me corrija en algunos comentarios)

he dicho!

Mejor hubiera sido

Mejor hubiera sido simplemente corregir la liga en el post original y tan tan.

Ya está corregido.

Chau!

Imagen de Miguel-1.mx

Todavía mejor hubiera sido...

¡Gracias Enrique, Javier y Oscar por corregir mi horror tipográfico! Tendré mayor cuidado en el de las próximas OpenTalks. Salvo su mejor opinión, estoy de acuerdo con Enrique: es mejor apuntarlo que sencillamente editarlo, pues primero, quien haya leído la entrada antes que Enrique se diera cuenta podría haber tomado un dato incorrecto; segundo, porque como apunta el doctor Ferro, así aprendemos todos y tercero, me di cuenta cuando ya lo había enviado, pero no tenía privilegios de edición. La ventaja que no todos puedan editar es que reduce prácticas de spam.

Alegrémonos que haya la posibilidad de intercambiar opiniones, de apuntar fallas y de hacer comunidad. ¡Reitero mi agradecimiento a todos por sus comentarios!

Imagen de Jose_Gastelum

yo quiero un paquete telmex jaja

parece que los estan capacitando para cambaceo
suerte

eehh cuando vendran a dejar el nuevo directorio

jaja

es cura

chido post

Imagen de bferro

23:28 horas

Ya es hora de poner el esqueleto en posición horizontal. Mañana de seguro sale el sol. Todavía no es 2012

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">