Primero lo primero – Instalando el JBoss AS 7

Cuando vayamos a www.jboss.org veremos que por primera vez existen dos versiones del servidor para bajarnos.

• Web Profile Only (Java EE6 Certfied)
• Everthing (NOT Java EE6 Certfied)

La primera como su nombre lo indica está orientada al la ejecución de aplicaciones Web y como se puede apreciar es una configuración certificada en cumplir con todos los requerimientos de un servidor Java EE6 con web profile. La otra configuración es lo que se conoce por Full profile pero que todavía no ha sido certificada y no soporta todos lo que necesita un servidor Full Profile, por lo cual es llamada “Full preview profile”.
Yendo a lo concreto, la diferencia entre el Web y el Full es básicamente es la siguiente

• JSR 914 – Soporte de JMS
• JSR 224- Java API 2.2 para WebServices basados en XML (JAX-WS)

Cualquiera de las configuraciones la podemos bajar desde la página de download de JBoss.
Para los ejemplos acá planteados cualquiera de las dos es indistinta. Si no piensan usar JMS y WebServices entonces con la Web van a estar más que bien. Tengan en cuenta que ambas vienen con la variación Lite del contenedor de EJB especificado en la JSR-381. Este contenedor es una versión limitada la cual NO soporta:

• Remote interfaces
• RMI-IIOP Interoperability
• JAX-WS Web Service Endpoints
• EJB Timer Service (@Schedule, @Timeout)
• Asynchronous session bean invocations (@Asynchronous)
• Message-driven beans

Los que quieran ver un poco más sobre que soporta y que no cada una de las versiones pueden consultar la tabla que hay en la guía de JBoss

Ahora a los bifes – Ejecutando el JBoss AS 7.0
Para ejecutar el servidor debemos tener descomprimido el archivo bajado (el zip o el tar.gz) en una carpeta donde mejor nos quede. Por ejemplo en mi caso yo lo instale en Users/ale/opt/Applications/jboss-as-web-7.0.0.Final.
El único requerimiento que tenemos es que debemos tener instalada una versión de la JDK que sea la 6 o superior.

Luego debemos abrir una terminal o consola, dependiendo del sistema en que estamos, y posicionarnos en la carpeta raíz donde instalamos el servidor.
Ahí ponemos nuestro asiento en posición vertical, nos abrochamos los cinturones y ejecutaremos:

• bin\stanadalone.bat si es que estamos en windows
• bin/stanadalone.sh si estamos en cualquier variante de Unix

Paren las rotativas!!! ¿Que es esto de standalone? Por ahora para la comprensión de este artículo solo diremos que standalone es uno de los dos modos de ejecución que trae la versión 7. De las dos opciones esta es la más similar en su funcionamiento a las versiones anteriores de JBoss.

Ahora sí, levantemos el JBoss AS 7!!!. tecleamos bin/stanadalone.sh [ENTER]
Podemos ver como en muy pocos segundos ya está el JBoss AS 7 levantado!!! . Ahora sabemos de primera mano que esta nueva versión levanta con una velocidad mucho mayor que cualquiera de sus versiones anteriores. Eso no es por casualidad y se debe a su nuevo diseño el cual nos provee de un nuevo proceso de carga de componentes. Este proceso tiene dos grandes cambios:

1. Carga concurrente de los servicios, aprovechando los múltiples procreadores que tengamos
2. Solo levanta los servicios críticos para el correcto funcionamiento del servidor. Cualquier otro servicio no crítico queda levantado en forma pasiva hasta que sea utilizado por primera vez.

Según RedHat esta versión ofrece una reducción de 10 veces en el tiempo de arranque con respecto a las versiones anteriores.
Esto podemos confirmar si miramos la última linea impresa por el JBoss, la cual debe decir algo así:

...
...
...
17:30:11,370 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-4) Starting remote JMX connector
17:30:11,405 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
17:30:11,878 INFO  [org.jboss.as.remoting] (MSC service thread 1-3) Listening on /127.0.0.1:9999
17:30:12,049 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-8) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
17:30:12,742 INFO  [org.jboss.as.connector] (MSC service thread 1-7) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
17:30:13,360 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) Bound data source [java:jboss/datasources/ExampleDS]
17:30:14,120 INFO  [org.jboss.as.deployment] (MSC service thread 1-4) Started FileSystemDeploymentService for directory /Users/ale/opt/Applications/jboss-as-web-7.0.0.Final/standalone/deployments
17:30:14,132 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.Final "Lightning" started in 7885ms - Started 92 of 147 services (55 services are passive or on-demand)

En este caso podemos ver como en JBoss levanto en casi 8 segundos.

Para bajar el JBoss no hay misterios, hacemos como siempre hasta ahora Ctrl+C.

Me parece que vi un lindo gatito – Nueva consola Web
Una vez que tenemos el servidor levantado pasemos a ver otra de las mejoras que trae que es su consola web de administración. Esta consola si la comparamos con la anterior es un avance importante en cuanto a la estética. La consola es una aplicación GWT lo cual la hacen mucho más rica en su funcionamiento. Dentro de esta podemos hacer varias actividades de administración, como ser:

• Configuración de los datasource
• Configuración de los logs
• Configuración de los conectores web y virtual host
• Realizar deployments con al posibilidad de, habilitar, deshabilitar, subir y eliminar aplicaciones
• Configuración de los puertos

Para conectarnos a esta nueva consola tenemos que abrir un browser e ingresar: http://localhost:9990/console

Una funcionalidad que se ha eliminado es la consola JMX. Este cambio se debe a que con JMX no se podía dar soporte a la nueva administración de dominios (hablaremos de ella en otro artículo). Ahora la forma de administrar es usando el modo nativo de administración. Desde este modo podemos configurar y accederá a todas las propiedades de los servidores. JBoss viene con una extensión que hace de puente entre JMX y la API nativa y nos permite conectarnos con un cliente JMX como el jconsole. En mis pruebas lo que si pude detectar es que no estaban todas las funcionalidades presentes en la consola JMX.

La consola web no es la única forma de acceder a la interfaz nativa de administración. Tenemos estás cuatro opciones:

• La consola web que como vimos es limitada
• Con un cliente de linea de comando, muy completo por cierto.
• Una API java que se puede acceder directamente con java remoting
• Una API REST-like para enviar comando por http

De estas vale la pena mencionar que la CLI que trae está muy completa, por ejemplo soporta auto completado. Para describir esta consola necesitaríamos una artículo entero. Los interesados pueden leer más sobre esta en JBoss CLI

A la carga – Haciendo nuestro primer deploy
Como ya mencionamos una forma de hacer deploy es por medio del uso de la consola web. Esta forma es muy simple por lo cual no nos vamos a detener en explicar. Lo que si vamos a ver es como hacer un deploy a la vieja usanza copiando el archivo en el directorio de deployment. Para variar esto también ha cambiado, yo estoy convencido de que luego de tantos años de manejar la misma estructura del servidor la gente de JBoss se aburrió y para hacer su trabajo más divertido nos cambio todo!!! Por suerte los cambios son para mejor.

Entonces, ¿Donde debemos copiar nuestra aplicación? Como tenemos levantado el JBoss en modo standalone debemos copiar el artefacto (jar, war o ear) al directorio standalone/deployments. Y listo nuestra aplicación queda levantada y funcionando.

Resumiendo

Los más importante que vimos en el artículo es:
Que versiones están disponibles para bajar
Como levantar el servidor en modo standalone: bin/standalone.sh
Conectarnos a la consola Web: http://localhost:9990/console
Hacer un deployment: Copiar nuestra aplicación a standalone/deployments

Por último espero que hayan visto que esta nueva versión incluye una cantidad de cambios aparte del soporte a Java EE 6.

Para la próxima

En el próximo artículo veremos más sobre los deploy y revelaremos el misterioso “Sandalone”. Antes de despedirme les dejo un deber, ¿luego de hacer el deploy, no ven nada extraño en el directorio deployments?

Saludos y hasta la próxima.

• El testing no sirve para nada
• Esto es bien simple, no necesita testing
• Que testén los usuarios
• El testing es una pérdida de tiempo
• Testear es improductivo
• Testear es aburrido

Bueno, déjenme decirles algo: todas estas afirmaciones están equivocadas. Sí, incluso la última. Testear tiene muchos beneficios, incluso tiene beneficios no directamente relacionados con el testing. Pero no nos adelantemos.

Tal vez la primera -El testing no sirve para nada- sea una de las más dichas y escuchadas. Esta frase la dice la gente que nunca testeó. No conozco a nadie con disciplina de testing que piense esto.

Otra frase nefasta es la tercera -Que testén los usuarios-. No hay peor cosa que entregarle al usuario que un software plagado de errores. La confianza del usuario es una de las cosas más importantes en un proyecto. Al usuario hay que tenerlo de nuestro lado ya que él/ella es la razón por la cual estamos haciendo ese sistema. La confianza se puede perder en un abrir y cerrar de ojos por un error que lleva 5 minutos eliminarlo. Y cuando sucede esto, volver a ganar la confianza cuesta mucho.

Pero ¿por qué se le tiene tanta idea al testing? y sobre todo por la gente que no tiene disciplina testeadora. Yo creo que es porque el testing nos expone a nuestros errores e inconscientemente tratamos de evitar esto. Y mientras haya errores, obviamente, la tarea no está terminada.

Cómo sería la implementación de una funcionalidad para un programador que no testea disciplinadamente:

1. Programación de la funcionalidad
2. Probar un par de veces (en el mejor de los casos)
3. Deploy

Para cualquier funcionalidad más o menos compleja, esto lleva a que haya un caso que no se consideró en el punto 2 y por lo tanto a un error en el sistema. Entonces:

1. Corregir el error
2. Probar un par de veces (ahora un poco mejor por el sentimiento de culpa
3. Deploy

Seis pasos, suponiendo que el error queda arreglado.

Como sería el mismo ciclo, pero con disciplina de test:

1. Programación de la funcionalidad
2. Programación del test de la funcionalidad
3. Probar la funcionalidad
4. Deploy

Cuatro pasos.

Les aseguro que la calidad del producto es mucho más alta y no quedamos pegados con el usuario. El “simple” hecho de programar el test, no hace pensar más. Y ¿tardamos más? Generalmente no, porque no hay que corregir errores ni volver a pasar a producción. Igualmente, sería preferible tardar más que por tratar de sacar el sistema antes, se escape un error se dañe la confianza del usuario.

Herramientas

Bueno, basta de psicología barata. Ahora voy a nombrar algunas herramientas que asisten al testing.

Simplemente voy a nombrarlas, hay mucha literatura en Internet sobre estas herramientas.

Unitarios

Para hacer tests unitarios hay básicamente dos frameworks JUnit y TestNG. El segundo es más abarcativo que el primero.

Integración

Para hacer tests de integración, también hay frameworks que nos facilitan la vida, jMock o Mockito por nombrar dos.

Cobertura

La cobertura de código es sin duda una de las herramientas más interesantes para tener una idea de la calidad de nuestro test. Con esta herramienta es muy fácil saber si se nos escaparon casos en nuestros tests, ya que van a aparecer lineas de código son cubrir. La idea es aproximarse lo más posible a 100%.

El hecho de testar, produce efectos secundario (positivos) en nuestro código:

1. Con el tiempo produce métodos más simples: Es más fácil testear métodos cortos y simples, que largos y complejos. Cuando programamos pensando en el testing esto surge naturalmente. El código simple es más fácil de mantener.
2. Los tests tienden a mejorar la modularización del sistema, ya que pueden exponer problemas de dependencias entre los módulos. Ej: dependencias circulares.
3. Los tests tiene un efecto psicológico en el desarrollador, dándole confianza en su producto y fomentando la motivación. Esto hace que testear sea “divertido”.

Notas finales

El test debe ser tomado con profesionalismo: la tarea no está terminada si no tiene el test correspondiente. Está de más decir que el test tiene que ser de alta calidad.

El test sirve para verificar y descubrir errores cuando estamos programando la funcionalidad, pero más importante aún, es que nos da la tranquilidad de que dentro de 6 meses cuando se realizaron un montón de cambios, nuestra funcionalidad se sigue comportando como esperamos.

Implantar el testing en un equipo no es tarea fácil. Requiere tiempo, esfuerzo y no bajar los brazos. Siempre hay rechazo a algo nuevo. Incluso la gente que reconoce el valor del testing, le cuesta arrancar a testear profesionalmente.

El testing (cómo cualquier otra cosa) no puede ser algo impuesto al equipo; por el contrario, tiene que ser aceptado por el equipo, haciéndole ver los beneficios del testing profesional en el día a día. Bien vale la pena el esfuerzo.

¿Qué, cómo, dónde?
Primero, vamos a definir “qué” queremos hacer. Una vez más, voy a utilizar el clásico ejemplo de obtener PI desde el servidor. Luego veremos el “cómo”.

El “qué” refiere a la interfaz del servicio y el “cómo” a la implementación. Entonces tenemos que crear:

package  ejemplo.client.services

// El “qué”
public interface MathService extends com.aquait.rpc.client.service.Service {
    double getPi();
}

// El “cómo”
package ejemplo.server.services

public class MathServiceImpl extends com.aquait.rpc.server.service.Service implements ejemplo.client.services.MathService {
    public double getPi() {
        return Math.PI;
    }
}

¿Y ahora? Ahora hay que decir el “dónde”. Para esto configuramos el servidor. En el archivo services.config agregamos:

service[math_service].interface = ejemplo.client.services.MathService
service[math_service].implementation =  ejemplo.server.services.MathServiceImpl

Recordar “math_service” que será utilizado más adelante.
El siguiente paso sería crear un jar con las clases e interfaces y copiar ese jar en el subdirectorio application.
Con el comando start levantamos el servidor y deberíamos ver en el log, en el reporte de servicios, al querido MathService.

Mozo! Un PI por favor!
Si todo está bien (y esperemos que así sea) estamos en condiciones de hacerle pedidos al servidor. Para esto, desde el cliente tenemos que conectarnos e invocar al servicio:

// 1 – Nos conectamos al servidor
AppServerClient appServerClient = new AppServerClient("localhost", 6666);

// 2 - Obtenemos un proxy del servicio desado: “math_service”
MathService mathService = (MathService)appServerClient.getService("math_service");

// 3 - Invocamos al método deseado como si lo tuvieramos local
double pi = mathService.getPi();
System.out.println(pi);

Todo esto y mucho más
Esta es la versión simple. Pero en realidad, el servidor soporta seguridad, parámetros de inicialización de los servicios, pool de conexión a la base de datos, mensajería, módulos, etc. Esto se puede ver en el código fuente publicado en el artículo AppServer-03 en un módulo que se llama test.

Good luck!

Primero, antes de comenzar para los que no saben que es Scala (en este caso no se como han llegado acá?) les cuento que es un lenguaje que mezcla la programación funcional y la orientada a objetos tratando de brindar lo mejor de ambos paradigmas. Este lenguaje cuenta con su propio compilador “scalac” el cual genera clases Java que pueden ser interpretada por una JVM. Esta particularidad hace que se puedan utilizar todas las librerías existentes en Java así como también utilizar nuestro código dentro de otras aplicaciones Java.

Actualmente mucho se ha escrito y discutido mucho de si Scala es un lenguaje fácil o difícil, simple o complicado. El problema con lo que he leído no es la opinión que se da, sino desde el punto desde el cual se enfoca la pregunta. ¿A que me refiero con esto? A mi entender necesitamos re-formular la pregunta ¿Es fácil para un programador Java aprender Scala? Para poder obtener una respuesta útil. La pregunta que deberíamos hacernos es: ¿Es fácil para un programador Java comenzar a utilizar Scala?

La diferencia entre ambas preguntas es que para comenzar a utilizar un lenguaje no es necesario SABERLO!!! A medida que uno utiliza un lenguaje va aprendiendo sus virtudes y sus trucos y así va mejorando su conocimiento con la practica. Yo pregunto ¿Ustedes estudiaron toda la teoría de Java antes de comenzar o arrancaron utilizándolo poco a poco? ¿Quien no agarra un código propio de sus años de inicio y no se sonroja por las barbaridades que programo? Como docente he visto que a los alumnos se les hace cuesta arriba cuando comienza a utilizar Java y tratan de entender el lenguaje y al mismo tiempo quieren utilizar toda su potencia. Cuando uno habla de todas las funcionalidades que Java tiene puede ver como los ojos se les quedan en blanco tratando de ver como van hacen para dominar “el monstruo”, y ni que hablar si nos encontramos con un grupo que viene de trabajar en C# con Visual Studio. En este caso agarrate catalina que les van a llover las quejas sobre “lo complejo que es Java”.

La mayoría de los artículos opinan sobre si Scala es difícil o fácil?, o si es complejo o simple? pero para poder responder estas preguntas es necesario saber y entender el lenguaje y si tenemos este conocimiento seguramente no nos vamos a estar haciéndonos esta pregunta . Lo que le interesa saber a un programador que quiere comenzar a utilizar Scala es:  ¿Es difícil llegar a tener un conocimiento profundo del lenguaje? . La respuesta es OBVIA, claro que SI!!!. Pero esto no es un problema de Scala sino de cualquier lenguaje. No creo que exista un lenguaje de programación que permita que en poco tiempo seamos unos expertos ( y VB no califica como lenguaje ). Todos tienen sus vueltas y nos lleva su tiempo lograr comprender como realmente funcionan y cual es la mejor forma de usarlos, y para rematarla por lo general no hay una única forma de hacer las cosas. Hoy cuando nos hacemos esta pregunta nos encontramos que ya dominamos un lenguaje, un paradigma y nuestra ansiedad hace que queramos comenzar a utilizar ya!!! Scala en todas su potencia. Pero nos olvidamos que para llegar al mismo nivel en este nuevo lenguaje no solo tenemos que aprender una nueva sintaxis y una nueva API sino que también tenemos que dominar un nuevo paradigma… ¿Como alguien puede pretender que esto sea una tarea fácil? No duden que va a ser un camino largo al igual que fue el camino de dominar Java y la programación orientada a objetos.

Ahora si cambiamos la pregunta a ¿Es fácil para un programador Java comenzar a utilizar Scala? La respuesta es un rotundo SI.

¿En que me baso para dar ésta respuesta?

• Primero en mi experiencia personal

• Segundo Scala tiene la dualidad de ser orientado a Objeto y Funcional, con lo cual se puede comenzar a utilizar orientado a objetos y una vez dominada la sintaxis y las principales API podemos comenzar a aprender los aspectos funcionales del lenguaje.

• Tercero si bien la sintaxis es diferente a Java en el diseño del lenguaje se ha puesto mucho hincapié en lograr el equilibrio entre eliminar sintaxis innecesaria y crear un código legible. Obviamente como todo lenguaje con un poquito de empeño cualquier programador puede crear código ilegible , pero no vamos a tener problema si nos mantenemos en las recomendaciones y no intentamos escribir métodos complicados en una sola linea .

• Cuarto hay mucha información en Internet y fácilmente se puede acceder a libros sobre el lenguaje y la mayoría orientados a programadores Java que quieran utilizar Scala.

• Por último el tener soporte de las principales IDE como ser Eclipse, NetBeans y IntelliJ con soporte de auto-completado de código hace que el arranque no sea tan tedioso.

Para finalizar los invito leer algunos articulos en la red teniendo presente la pregunta ¿Es fácil para un programador Java comenzar a utilizar Scala?. Yo no voy a escribir código habiendo tan buenos ejemplos, les dejo unos link que hacen un buen trabajo por mi.

http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/

http://warpedjavaguy.wordpress.com/2010/08/02/the-scala-is-too-complex-conspiracy-1/

http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html

Saquen sus propias conclusiones y posten su comentario.

El “celular” de hoy en día es como una computadora con un montón de periféricos integrados: cámara, teclado, pantalla, teléfono celular, lector de memoria externa, wifi, gps, gsm, etc. Y todo esto en la palma de la mano.

Algunos de estos dispositivos móviles traen sistemas operativos propietarios, otros utilizan alguna versión de Windows, Linux o Symbian OS. Pero hay una características que la gran mayoría tienen en común: Java. Obviamente no es la versión de Java full power que se instala en nuestro desktop, laptop o servidor. Se trata de una versión adaptada a dispositivos móviles en los cuales no se cuenta con Gigas de RAM, o múltiples CPUs con frecuencias de reloj del orden de los Giga Hetrz.

Sorprendentemente, Java Micro Edition (JME, A.K.A. J2ME) tiene las características que la hacen una plataforma bien interesante para desarrollar aplicaciones y particularmente juegos. Y estos últimos son los que vamos a explorar.

Primero un poco de teoría

Dada la cantidad de dispositivos móviles -todos con características diferentes- se inventaron los “perfiles de capacidades”: MIDP por Mobile Information Device Profile. Dependiendo de la versión de MIDP, el dispositivo va a tener más o menos capacidades de: comunicación, presentación, audio, etc.

Además de MIDP, existe otra especificación llamada CLDC por Connected Limited Device Configuration, que define capacidades de bajo nivel del dispositivo, por ejemplo, si tiene la capacidad de manejar número con punto flotante.

MIDP se apoya en CLDC para formar la plataforma Java ME. La idea es desarrollar en la plataforma más compatible que se pueda. Hoy por hoy, la mayoría de los celulares soportan MIDP 2.0 y CLDC 1.1, pero si podemos restringirnos a CLDC 1.0 mejor. El Motorola V360 es un ejemplo de teléfono móvil con MIDP 2.0 y CLDC 1.0.

Entonces cuando empecemos a desarrollar, tenemos que elegir que versión de MIDP y CLDC vamos a utilizar. En la página de Oracle (http://java.sun.com/javame/technology/index.jsp), se puede encontrar más información y el SDK (http://java.sun.com/javame/downloads/index.jsp).

Bien, tenemos el SDK instalado, tenemos nuestra IDE de confianza configurada. ¿Y ahora qué? ¡A programar! Bueno, no tan rápido. ¿Cómo se programa un juego? Esto es algo que los que venimos haciendo IT desde ya hace años, no tenemos muy claro. En Internet hay mucha documentación, pero la realmente buena es escasa.

Primero que nada, veremos como es el esqueleto de un juego -en pseudocódigo-:

proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
goto 1

Santo patrono de la informática, perdón por el goto.

No hay nada revelador en estas 4 lineas, pero lo que si se pueden empezar a ver algunos problemas. Por ejemplo: este juego va a ejecutar a distinta velocidad según de la potencia del celular. Algo claramente no deseable. Obviamente queremos que nuestro juego funcione a la misma velocidad en cualquier celular, sin importar la potencia del mismo.

Para esto, hacemos un pequeño cambio:

proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
esperar X milisegundos
goto 1

Ahora variando X, podemos variar la velocidad del juego. Fácil… ¿no? Queda en manos del usuario elegir X mediante, por ejemplo, el menú el juego. Pero, ¿no se podría determinar X automáticamente? Mejor aún, ¿no se podría determinar X dinámicamente en cada vuelta del ciclo? Claro que sí. Ahora vemos como:

ciclos_por_segundo = 30
milisegundos_por_ciclo = 1000 / ciclos_por_segundo
t_inicial = ahora()
proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
t_ciclo = ahora() - t_inicial
si (t_ciclo < milisegundos_por_ciclo) entonces
    esperar (milisegundos_por_ciclo - t_ciclo) milisegundos
goto 3

Nota: La función ahora() devuelve la hora actual en milisegundos, algo como lo que hace System.currentTimeMillis() en Java.

Lo que se hace es, tomar el tiempo que toma un ciclo completo (4, 5 y 6). Si ese tiempo es menor que la cantidad de tiempo que establecimos para cada ciclo en 1 y 2, entonces esperamos esa diferencia de tiempo. Así, todos los ciclos demoran lo mismo y el tiempo de espera se ajusta dinámicamente.

De esta forma logramos un rendimiento igual entre celulares de distinta potencia. Este método se puede mejorar implementando saltos de ciclos (frame skipping) cuando el celular es de muy baja potencia, pero corremos el riesgo de que el juego se vuelva injugable. Así, el juego ejecutará más lento en celulares de poca potencia, ya que todo el tiempo se consumirá en los puntos 4, 5 y 6 y nunca entrará en espera.

Es sorprendente la cantidad de cosas interesantes que se pueden hacer utilizando esta sencilla técnica.

A la práctica

Vamos a implementar, con esta técnica, el “hola mundo” de los juegos: el PONG de a uno.

Pong

Es como si fuera un Arkanoid, pero sin los ladrillos. Es verdad, no es muy divertido.

La implementación en Java del bucle principal sería algo así:

final int CICLOS_POR_SEGUNDO = 30;
final int MILISEGUNDOS_POR_CICLO = 1000 / CICLOS_POR_SEGUNDO;
while (true) {
    long tInicial = System.currentTimeMillis();
    procesarEntradaDelUsuario();
    actualizarEstadoDelJuego();
    dibujarLaPantalla();
    long tCiclo = System.currentTimeMillis() - tInicial;
    if (tCiclo < MILISEGUNDOS_POR_CICLO) {
        Thread.sleep(MILISEGUNDOS_POR_CICLO - tCiclo);
    }
}

Notar que hasta ahora no hay nada hecho particularmente para el PONG. Lo particular estará en las funciones procesarEntradaDelUsuario(), actualizarEstadoDelJuego() y dibujarLaPantalla().

La primera tiene la responsabilidad de tomar la entrada del usuario y modificar algo en el juego, en este caso sería la posición de la paleta. Sí, la paleta es ese rectángulo verde.. hay que tener imaginación

La segunda debe actualizar el estado interno del juego. En este juego, esta función tiene dos objetivos: a) mover la pelota y b) si la pelota se va hacia abajo, entonces el juego termina con el fatídico “Game Over”.

La tercer y última función, debe tomar el estado del juego y dibujarlo en la pantalla.

El código fuente se puede bajar desde acá: pong-scr.tar. En esta implementación, nunca se pierde. Cuando la pelota se va para abajo, aparece nuevamente en el medio de la pantalla. Un buen ejercicio, sería agregarle vidas, que aumente la velocidad de la pelota, darle aceleración a la paleta, mejorar los gráficos, agregarle ladrillitos, sonidos, powerups y ponerle un nombre marketinero (que no sea Arkanoid, claro ) y de ahí, a la fama!

Enjoy!

Una de la cualidades de Grails que personalmente más me gusta es su integración con JEE. Desde Grails podemos utilizar tags JSP, Session Beans y EntityBeans como si fueran parte integral del framework.
En este post nos centraremos en como podemos invocar SessionBeans ya sean remotos o locales desde nuestro código Grails. Esta posibilidad junto con el manejo de los EntityBeans le aportan a Grails adaptabilidad y escalabilidad. A que me refiero con esto, a que siendo prolijos podemos desarrollar una aplicación entera en Grails y luego más adelante pasar los modelos y los servicios a Entities y SessionBeans respectivamente. De esta forma podemos comenzar rápidamente a desarrollar nuestra aplicación haciendo uso de las ventajas de estar en un ambiente dinámico y luego cuando la aplicación está más definida y los cambios no son lo común entonces podemos pasar la capa de negocios a JEE. Este cambio no afecta a ningún otro componente de Grails como ser controladores o vistas.
Para lograr esto último todo lo que debemos hacer es sustituir el código de las operaciones de los servicios por delegación a la misma operación en los SessionBeans creados.

A continuación veremos como se configura Grails para utilizar SessionBeans tanto para EJB3.0 como EJB2.1

Inyectando los SessionBeans
Grails permite inyectar tanto en los servicios como en los controladores cualquier SB al igual que lo hace con sus servicios. Al Grails utilizar Spring en el manejo de sus componentes es posible utilizar todas las ventajas de este dentro de Grails. La forma más sencilla de configurar los objetos a ser inyectados dentro de los controladores o servicios, y en especial los SB, es utilizando el archivo resources.groovy. Este archivo es equivalente a el archivo applicationContext.xml de Spring solo que en vez de ser un archivo XML es una clase groovy que utiliza el SpringBuilder como DSL para la configuración. Por defecto el archivo resources que se encuentra en grails-app/conf/spring y tiene el siguiente contenido:

// Place your Spring DSL code here
beans = {

}

Dentro del closure es donde se deben agregar las definiciones de los beans.

Configuración de servidor JNDI
Para poder acceder a cualquier componente que se encuentra en un servidor de aplicaciones debemos hacerlo utilizando JNDI. Para esto Spring provee una clase utilitaria la cual facilita las operaciones sobre un servidor de nombres JNDI como ser lookup y a su vez actúa como un proveedor de contexto JNDI. Para esto hay que agregar la siguiente definición en el resources.groovy

	ejbJndi(org.springframework.jndi.JndiTemplate){
		environment = [
			"java.naming.factory.initial" : "org.jnp.interfaces.NamingContextFactory",
			"java.naming.provider.url" : "jnp://http://localhost:1099

Donde:

• ejbJndi

Es el nombre del bean el cual es de tipo org.springframework.jndi.JndiTemplate. Este nombre puede ser cualquiera. Es a este nombre que se hará referencia para determinar el servidor de nombres que provee el acceso a un objeto.

• environment

Es la propiedad de JndiTempalte la cual se configura con un Mapa que tiene las propiedades JNDI

En un archivo podrían existir tantas definiciones de JndiTemplate como proveedores JNDI se necesiten acceder.

Configuración de servidor JNDI por ENVIRONMENT
Es muy probable y necesario, que el servidor JNDI requiera diferente configuración de IP y puerto según sea el ambiente desarrollo, producción o testing. Para lograr esto se debe anexar a la configuración anterior lo siguiente:

• Colocar el valor de la IP y puerto del JBoss en cada environment del Config.groovy.
• Importar la clase ConfigurationHolder en el archivo resources.groovy
• Sustituir la ip y puerto de la variable "java.naming.provider.url" por las cargadas en la configuración.

Ejemplo
Config.groovy

  ...
  environments {
    development {
        ...
        jboss.ip = "10.200.8.173"
        jboss.port = "1099"
        ...
    }
    production {
        ...
        jboss.ip = "172.16.2.105"
        jboss.port = "1099"
        ...
    }

Resources.groovy

     import org.codehaus.groovy.grails.commons.*
     ...
	ejbJndi(org.springframework.jndi.JndiTemplate){
		environment = [
			"java.naming.factory.initial" : "org.jnp.interfaces.NamingContextFactory",
			"java.naming.provider.url" : "jnp://"+ConfigurationHolder.config.jboss.ip+":"+ConfigurationHolder.config.jboss.port]
	}

Configuración de componentes EJB 3.0
Para poder inyectar componentes EJB 3.0 tenemos que agregar la siguiente configuración:

	xXXServices(org.springframework.jndi.JndiObjectFactoryBean){
		jndiName = "XXXServices/remote"
		jndiTemplate = ref("ejbJndi")
	}

Donde:

• xXXServices

Es el nombre que se le dará a la referencia remota al SB y que será utilizado para inyectar esta en los controladores y servicios. Cualquier controlador o servicio que tenga una propiedad con nombre xXXServices se le inyectara la referencia al SB remoto definido por ese nombre en el archivo resources.groovy. La primer x es en minúscula para indicar que por convención el nombre debe comenzar en minúscula.

• jndiName

Nombre por el cual se va a buscar la referencia al SB en el servidor JNDI

• jndiTemplate

Nombre del bean que se va a utilizar como provider para acceder al objeto JNDI. Es el definido en el punto anterior.

Para utilizar el SB en un servicio sería:

public class EjemploServices {
	def xXXServices

	void unMetodo(param1, param2) {
		xXXServices.invocoMetodoEnEJB(param1, param 2)
	}
}

Configuración de componentes EJB 2.1
Para poder inyectar componentes EJB 2.1 tenemos que agregar la siguiente configuración que es similar a la vista para EJB 3.0.

 xXXServices(org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean) {
		jndiName = "EJBXXXServices"
		businessInterface = "biz.aquait.yyy.ejb.EJBXXXServices"
		jndiTemplate = ref("ejbJndi")
		refreshHomeOnConnectFailure = true
                lookupHomeOnStartup=false

	}

Donde:

• xXXServices

Es el nombre que se le dará a la referencia remota al SB y que será utilizado para inyectar esta en los controladores y servicios. Cualquier controlador o servicio que tenga una propiedad con nombre xXXServices a esta se le inyectara la referencia al SB remoto definido por ese nombre en el archivo resources.groovy. La primer x es en minúscula para indicar que por convención el nombre debe comenzar en minúscula.

• jndiName

Nombre por el cual se va a buscar la referencia al SB en el servidor JNDI

• refreshHomeOnConnectFailure

Refresca la home cuando detecta un fallo en la conexión, por ejemplo cuando se reinicia el servidor

• lookupHomeOnStartup

Hace que la aplicación no haga el lookup a levantar sino al utilizar servicios del SB.

• jndiTemplate

Nombre del bean que se va a utilizar como provider para acceder al objeto JNDI. Es el definido en el primer punto.

• businessInterface

La interfaz remota del SB, es decir la que extiende EJBObject.

La forma de utilizar el SB dentro de un servicio u otro componente es la misma forma que las referencias a SB implementados  con EJB 3.0.

Conclusión

Siguiendo los pasos presentados arriba podemos decir que configurar Grails para utilizar  SB no es engorroso y que el uso de estos dentro del framework es transparente ya que se usan de la misma forma que un servicio de Grails.

En la medida que adquiría experiencia me daba cuenta que faltaba algo. Tenía la sensación que lograba las metas con un esfuerzo personal muy importante, pero mi equipo lo hacía de forma irregular.

Luego de decenas de proyectos comencé a buscar la verdadera razón del éxito. Comprendí que éste radica en la naturaleza de las personas que trabajan en él, sumado al conocimiento técnico adecuado. Por esta razón, siempre considere a mi equipo de trabajo como el “gran actor” de un proyecto y siempre intente generar el contexto más adecuado para obtener el mayor rendimiento de ellos, incluyendo la motivación personal.

También aprendí que si quieres hacer un proyecto exitoso debes estar dispuesto a darle paso a quienes te acompañan en el trabajo cotidiano. Sin importar el nivel jerárquico, todos quieren ser reconocidos, todos quieren proponer, todos quieren aportar al objetivo. He aquí lo difícil, intentar satisfacer estas necesidades. Siempre intente hacerlo, convencido que era fundamental para lograr el objetivo.

Hace un par de años atrás, descubrí que muchas de esas premisas, en las cuales yo me basaba intuitivamente, estaban plasmadas en algo llamado SCRUM. Comencé a leer con ahínco, y poco a poco me daba cuenta que había encontrando lo que desde hace tiempo buscaba. Un marco de trabajo que pone por escrito el sentido común, basándose en el valor que aportan las personas, el vínculo, la creatividad, la crítica constructiva, la auto-enseñanza y la auto-organización.

¿Acaso alguien cree que es un buen project manager por hacer cronogramas, calcular presupuestos, hacer cumplir órdenes? Si estás o has estado desempeñando este rol, seguramente pienses que nada de lo anterior fue fundamental en el éxito de un proyecto. En mi opinión, un buen project manager es quién logra llevar a cabo un proyecto sintiendo que realmente tuvo el control del proyecto, fue el gestor, pero sabe perfectamente que sin el equipo de trabajo, solamente con su aporte individual no lograba el objetivo.

Del análisis anterior surge el tipo de líder que propone SCRUM, el líder que articula, orquesta, comanda, pero prácticamente no aparece en escena. Logrando el compromiso profesional de su equipo de trabajo plasmado en productos tangibles, que agreguen valor al cliente. Todo esto, conjugado con ciclos de desarrollo cortos, permiten corregir en base al empirismo y siempre con riesgo de bajo costo.

Muchas veces, al hablar de metodologías ágiles, tales como SCRUM, los project manager pensamos en anarquía y poca intensidad, cuando en realidad es exactamente lo contrario. Para practicar correctamente SCRUM se exige disciplina e intensidad, sostenidas en el tiempo.

Podría haber escrito un artículo que explicara aburridamente SCRUM, pero iría contra la esencia de éste método, por tal razón, los invito a aprender SCRUM. Luego habrá tiempo para decidir si lo practican o no, pero no lo quiten de sus escenarios por desconocimiento. Piensen, por algo está siendo utilizado por las grandes empresas del mundo de tecnología; Google, Yahoo, Microsoft, HP, Novell, SAP, Nokia, Xerox, etc.

Intro

Siguiendo en la linea de la introspección, hoy vamos a ver una simple reflexión que nos va a permitir invocar sobre una instancia de una clase a métodos por su nombre.

What for?

La reflexión es una característica interesante, que se hace fundamental a la hora de diseñar componentes genéricos. Nos permite crear instancias de determinada clase con el nombre de la clase o también invocar métodos sobre una instancia de una clase teniendo el nombre del método. Esto, por ejemplo, nos simplifica enormemente la implementación del patrón command.

How? What?!

En GWT (al menos hasta la 1.7) no hay reflexión. Lo que vamos a hacer en esta implementación de reflexión, es proveer un mecanismo para invocar métodos por nombre. Suponiendo que tenemos una clase llamada MiClase que tiene un método llamado miMetodo buscamos poder hacer algo así:

MiClase instancia = new MiClase();

String nombreMetodo = “miMetodo”;

Object[] parametros = new Object[]{...};

invocar(instancia, nombreMetodo, parametros);

Enter generators!

Lo que vamos a hacer es que GWT genere la clase MiClaseReflection. ¿Cómo? Usando generators. Esta es una característica bien interesante de GWT. El foco de este artículo no está en explicar generators, hay mucha literatura en Internet. Acá va un link: http://code.google.com/intl/es/webtoolkit/doc/1.6/DevGuideCodingBasics.html#DevGuideDeferredBinding. Igual no hay que ser un experto para entender lo que vamos a hacer.

Básicamente vamos a escribir una clase que genere el código de MiClaseReflection, que tiene un único método -invocar- que es una cadena if..elseif..else que pregunta por cada método de MiClase y si alguna coincide, se lo invoca. Sería algo como esto:

if (nombreMetodo.equals(“miMetodo1”)) {

    target.miMetodo1(params);  // void

} else if (nombreMetodo.equals(“miMetodo2”)) {

    return target.miMetodo2(params); // no void

} else {

    throw new Exception(“método no encontrador: ” + nombreMetodo);

}

Obviamente falta chequeos de parámetros.

Para no tener que realizar ningún paso previo a la compilación generando la clase con alguna utilidad externa vamos a usar la API que tiene GWT que permite extender el compilador (com.google.gwt.core.ext). NOTA: Los que hayan utilizado APT de Java van ver unas cuantas similitudes (http://java.sun.com/javase/6/docs/technotes/guides/apt/index.html).

Cuando el compilador de GWT encuentra con la instrucción GWT.create(class) –que devuelve una implementación de la interfaz class– invoca al generador asociado a la interfaz class (esta asociación se declara en el gwt.xml del módulo). En este generador se “escribe” el código que implementa la interfaz class. Para escribir este código tenemos la asistencia de la API com.google.gwt.core.ext.typeinfo que recuerda mucho a la API Mirror Reflection de Java.

Generate

La instrucción GWT.create() toma una interfaz y devuelve una implementación de la misma. Entonces vamos definir una interfaz de marca y la vamos a llamar Reflectable. Toda clase que queramos tener soporte de reflexión va a tener que implementar esta interfaz:

public interface Reflectable {

}

Entonces la clase MiClase:

public class MiClase implements Reflectable {

    void miMetodo1();

    int miMetodo2();

}

Además, tenemos que tener la interfaz de idioma de la reflexión:

public interface Reflection<I extends Reflectable> {

    Object invoke(I target, String methodName, Object... params)

    throws InvocationException;

}

Para obtener una reflexión y usarla suponiendo que miMetodo no tiene parámetros:

MiClase objeto = new MiClase();

Reflection<MiClase> reflection = GWT.create(MiClase.class);

reflection.invoke(objeto, “miMetodo”);

Para asociar el generador con la interfaz Reflectable, agregamos el siguiente fragmento al :

    <generate-with class="com.aquait.utils.gwt.rebind.ReflectionGenerator">

        <when-type-assignable class="com.aquait.utils.gwt.reflection.Reflectable"/>

    </generate-with>

Así, cuando el compilador de GWT encuentra GWT.create(MiClase.class), llama al generador pues la clase MiClase implementa Reflectable. Luego, tenemos una implementación de la interfaz Reflectable para la clase MiClase.

Para usarlo en un proyecto, hay que agregar esto en el <modulo>.gwt.xml:

<inherits name="com.aquait.utils.gwt.Reflection"/>

El JAR se puede descargar de acá: introspection-reflection4gwt.jar

Nota: Este JAR tiene una versión actualizada de la introspección que elimina los métodos getIntrospectable() y setIntrospectable() de la interfaz Introspection. Por lo tanto, los métodos getProperty() y setProperty() toman como primer parámetro al Introspectable.

Este es el último artículo de esta serie. En este voy a presentar como se configura el servidor y además voy a subir el código fuente.

Estructura de directorios:

aquait-appserver/

• application/
  • db_connection_pool.config Configuración del módulo pool de conexiones a la base
  • modules.config Configuración de los módulos
  • services.config Configuración de los servicios
  • messaging.config Configuración del módulo de mensajería
  • security.config Configuración de seguridad
• lib/
  • aquaitrt-bin_2009r1.jar Runtime
  • mail.jar Servicio de mail
• log/
• logging.config Configuración de logging
• server.config Configuración del servidor
• start.sh
• stop.sh
• start.cmd      Scripts para iniciar y detener al servidor
• start.sh
• stop.cmd
• stop.sh

logging.config

handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler

java.util.logging.FileHandler.level = ALL

java.util.logging.FileHandler.pattern = ./log/server.%u.txt

java.util.logging.FileHandler.limit = 50000

java.util.logging.FileHandler.count = 1

java.util.logging.FileHandler.formatter = com.aquait.utils.logging.ServerFormatter

java.util.logging.ConsoleHandler.level = INFO

java.util.logging.ConsoleHandler.formatter = com.aquait.utils.logging.ServerFormatter

Archivo que configura el logging. El servidor usa la API estándar de Java SE para logear. El archivo por defecto define dos handlers. El primero que genera archivos y el segundo logea a la consola. Por más detalles, ver http://java.sun.com/javase/6/docs/api/java/util/logging/package-summary.html.

server.config

# Server config

# Server listening port

#

port = 6666

# Worker pool size

#

workers.poolsize = 10

# Shutdown password

#

shutdown.password = _shut_down_now_server_

Este archivo define tres parámetros del servidor. Primero el puerto TCP/IP en el cual el servidor escucha conexiones. Los clientes se deberán conectar a este puerto. El segundo parámetro define la cantidad de workers (hilos) que atienden los pedidos de los clientes. Y el tercero es la contraseña para bajar el servidor. Se baja mediante el script stop que se comunica al puerto definido y manda un mensaje especial. El servidor solamente se puede bajar desde el mismo host en donde está ejecutando.

db_connection_pool.config

# DBConnectionPoolModule configuration

#

# Examples:

# url = jdbc:oracle:thin:@<host>:<port>:<database>

# driverclass = oracle.jdbc.driver.OracleDriver

#

enable = false

url = <url>

username = <user>

password = <pass>

driverclass = <driver_class>

autocommit = false

poolsize = 5

maxpoolsize = 10

Este archivo controla los parámetros del pool de conexiones a la base de datos.

modules.config

# Modules to load

# Format:

# module.name = <module_name>

# module[<module_name>].class = <module_class>

#

En este archivo se delcaran los módulos que van a desplegarse en el servidor. Cada módulo puede tener una cantidad varible de parámetros.

messaging.config

# MessagingModule configuration

#

enable = false

poolsize = 10

# Security realms

# Format (<n> starts at 0):

# security_realm[<n>] = <security_realm_class>

#

Este archivo configura la seguridad del servidor. Se pueden definir varios realms que se ejecutan en orden para cada pedido de los clientes.

services.config

# Services

# Format:

# service[<service_name>].interface = <service_interface>

# service[<service_name>].implementation = <service_implementation>

# service[<service_name>].parameter[<param_name>] = <param_value>

#

Este archivo configura los servicios que se publican en el servidor. Para cada servicio hay que configurar la interfaz y la implementación de esta. Además, opcionalmente, se pueden agregar parámetros de inicialización.

Con esto finalizamos esta serie. Siempre estoy a las orden ante cualquier consulta que tengan al respecto de este servidor.

Bajar código fuente: aquaitrt_2009-10-14.tar.gz

Siguiendo la exploración de los principales componentes de servidor, en este artículo vamos a ver el el componente de conexiones a la base de datos y el de mensajería. Los dos componentes se diseñaron e implementaron separadamente del servidor de aplicaciones, por lo que no están acoplados de ninguna forma. Para “agregarlos” al servidor, se implementaron módulos del servidor que los adaptan.

Pool de conexiones a la base de datos

El pool implementado es muy sencillo. Tiene una colección de conexiones con un tamaño inicial (configurable) y en caso de que el cliente (en este caso el servidor de aplicaciones) necesite más, crea hasta un máximo (también configurable).

Diseño del pool de conexiónes a la BD

Los métodos startup() y shutdown() del módulo manejan el ciclo de vida del pool. El primero carga de un archivo de configuración -que veremos más adelante- los datos para crear el pool y el segundo mata a las conexiones activas.

Mensajería

El servicio de mensajería también es sencillo, pero potente. Poseé un pool de hilos que procesan los mensajes en form asíncrona. La clase Messaging tiene un conjunto de MessageHandlers que son los responsables de procesar los mensajes. Cuando llega un mensaje, este se le pasa a todos los handlers y cada uno es responsable de si lo procesa o no.

Diseño del servicio de mensajería

En el próximo artículo voy presentar la configuración del servidor y también voy a subir el código fuente. Hasta el próximo!