Cursos Online JoeDayz

on octubre 27, 2011 with No hay comentarios.

Estamos muy contentos de que nuestros cursos ya sean tomados en cuenta fuera del Páis.

En Panama ya nos siguen. Gracias Erwin por tu mail, esto nos compremete a seguir dando lo mejor de nosotros.

Joe

Hamcrest

on octubre 19, 2011 with No hay comentarios.

Un post técnico que me ha resultado genial probar y me gustaría compartir.

Hamcrest

Cuando trabajas haciendo test, se te pide tener en cuenta lo siguiente:

Los tests deben ser clarisimos para el lector y transmitir lo que estamos tratando de testear de la forma mas simple posible
Nuestros tests que fallan deben ser claros acerca del problema presente, no tenemos porque gastar mucho tiempo averiguando cual es la causa del problema
Nosotros debemos en lo posible seguir la regla TDD "Un Assert por Test" - o lo mas cercano a ese punto.
Implementar el metodo equals() solamente para que podamos hacer comparaciones en esting es demasiado engorroso para la practica.

El último punto porque puede ser engorroso porque basicamente puedes tener un id y considerar que dado ese id los dos objetos a comparar son iguales.
Ademas hay que ser sinceros, a veces usamos librerías de terceros y la realidad que encontramos es que no implementan equals(), hashCode() o toString(). Entonces, no podemos usar assertEquals directamente y si lo hicieramos la salida obtenida sería completamente inutil.

Bueno, vamos a probar el ejemplo del tutorial (http://code.google.com/p/hamcrest):

http://pastie.org/2725256

(código fuente)

Nota: Si van a probarlo primero añadan la librería de hamcrest luego la de junit. Me salio un error cuando hice un proyecto java simple y añadir primero junit y luego hamcrest. En fin, segui este tip y lo solucione con http://danmalec.blogspot.com/2010/08/solving-javalangsecurityexception-when.html

Como bien dice la documentación este assertThat es un método estilizado para hacer un test assertion. El sujeto de el assertion es el objeto biscuit que el primer argumento del metodo. El segundo argumento del metodo es un matcher para objetos Biscuit, aqui el matcher chequea que un objeto es igual a otro usando el metodo equals. El test pasa puesto que la clase Biscuit define un metodo equals.

Pero que pasa si no se implementa equals

Fuente: http://blogs.atlassian.com/developer/2009/06/how_hamcrest_can_save_your_sou.html

¿Que pasa si queremos comparar dos objetos que no implementan ni equals, ni hashCode?

assertEquals(thisLightsaber.isSingleBladed(), thatLightsaber.isSingleBladed());
assertEquals(thisLightsaber.getColor(), thatLightsaber.getColor());
assertEquals(thisLightsaber.getHilt(), thatLightsaber.getHilt());

Usando el simple assertEquals de JUnit sería de la forma mostrada.

El tema es que si se cae en una linea, nos resultaría dificil saber donde.

Si aplicamos hamcrest podemos ubicar el error de una manera mas especifica.

http://pastie.org/964394 (código fuente)

Si ejecutamos esto nos saldría un error como este:

java.lang.AssertionError:
Expected: is {singleBladed is , color is , hilt is }
     but: {color was }
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
    at pe.joedayz.samples.LightsaberTest.assertThatAnakinsLightsaberIsLukesFirstLightsaber(LightsaberTest.java:21)

El ejemplo también nos muestra como crear nuestro Matcher personalizado.
Otra cosa interesante que nos muestra tambien hamcrest desde su versión 1.2 es que tenemos un:

static void reportMismatch(String name, Matcher matcher, Object item, Description mismatchDescription, boolean firstMismatch)
{
    if (!firstMismatch)
    {
        mismatchDescription.appendText(", ");
    }
    mismatchDescription.appendText(name).appendText(" ");
    matcher.describeMismatch(item, mismatchDescription);
}

Donde podemos personalizar mas la salida y ver en donde tenemos la falla.

Trabajandolo con otros Test frameworks

Lo bueno de Hamcrest es que ha sido diseñado para integrarse con Junit, TestNG.
También se puede usar con mock objects frameworks usando adaptadores. Hay para JMock y EasyMock.

Sugar

assertThat(theBiscuit, equalTo(myBiscuit));
assertThat(theBiscuit, is(equalTo(myBiscuit)));
assertThat(theBiscuit, is(myBiscuit));

Todos estos son equivalentes.

Creando Matchers personalizados

Código fuente: http://pastie.org/2725591

¿Porque crear un matcher personalizado? pues para eliminar duplicación de código y hacer nuestros tests mas leíbles.

Al copiar el código y ejecutar el test verás que assertThat recibe un argumento de tipo Matcher. Y en este caso se necesita un Matcher. En la documentación explican que se utiliza TypeSafeMatcher porque este ya castea a Double por nosotros. La unica responsabilidad de nosotros es implementar el método matchesSafely que chequea si el Double es NaN y el metodo describe() que se usa para productir un mensaje de falla cuando el test falla.

fails with the message

java.lang.AssertionError: Expected: is not a number
    got : <1.0>

Conclusiones

Nos podemos expresar mejor con Hamcrest. En lugar de usar:

    @Test
    public void deberiaObtenerIgv(){
        double total = 119;
        CalculadoraFinanciera calculadoraFinanciera = new CalculadoraFinanciera();
        double impuesto = calculadoraFinanciera.obtenerIgv(total);
        assertEquals(impuesto, 19, 0);
    }

Podemos usar:

     @Test
   public void deberiaObtenerIgvConHamcrest(){
       double total = 119.0;
       CalculadoraFinanciera calculadoraFinanciera = new CalculadoraFinanciera();
       double impuesto = calculadoraFinanciera.obtenerIgv(total);
       assertThat(impuesto, is(19.0));
   }

En caso falle nos muestra un error mas entendible:

java.lang.AssertionError:
Expected: is <19.0>
     but: was <44.705882352941174>

Si trabajas con colecciones:

    @Test
    public void deberiaTrabajarConArreglos(){
        String[] colors = new String[]{"red", "green", "blue"};
        String color = "yellow";
        assertThat(color, not(isIn(colors)));
    }

Continuará.

Frameworks Ágiles para la Plataforma JEE

on octubre 12, 2011 with 2 comentarios

Frameworks Ágiles en la Plataforma JEE

Por: Ing. José Amadeo Martin Díaz Díaz

E-mail: jose.diaz@joedayz.pe

Twitter: @jamdiazdiaz

Web: www.joedayz.pe

Facebook: http://www.facebook.com/JoeDayzUniversity

No soy mucho de escribir artículos, así que espero realmente que pueda transmitir adecuadamente el mensaje sobre los Frameworks Ágiles para la plataforma JEE.

En mis 12 años de experiencia profesional he sido analista programador, arquitecto, coordinador y Gerente en diversos proyectos para la plataforma JEE. Utilizo el lenguaje Java desde que salí de la universidad la PUCP (1).

Si bien Java no se caracteriza por ser un lenguaje dinámico, sino más bien verboso y lleno de clases e interfaces que aprender, es hoy por hoy el lenguaje escogido por muchas organizaciones gubernamentales y privadas. “Al cesar lo que es del cesar”.

Sumado a esto tenemos diversos IDEs o entornos de desarrollo (NetBeans (2), Eclipse (3), Intellij Idea (4)), Contenedores de Servlets (Ahí tenemos al popular Tomcat (5)), Servidores de Aplicaciones para escoger (JBoss (6), WebSphere (7), GlassFish (8), WebLogic (9), tc-server (10), etc), APIs, Middlewares, Enterprise Server Bus (Mule (11), Apache Service Mix (12)), Messaging como Rabbit MQ (13), Frameworks de persistencia (Hibernate (14), Mybatis (15), JPA (16)), Frameworks Web (Spring MVC (17), Tapestry (18), wickets (19), struts 2 (20), JSF 2.0 (21)), y podemos seguir nombrando más categorías ubicadas en el segmento open source y/o comercial.

En definitiva hay muchos caminos que seguir, y supuestamente las empresas que deberían apoyarnos Oracle (22), IBM (23), RedHat (24) y ahora VMWare (25) en su mayor parte no se destacan por innovar, casi la mayoría de estándares que tenemos hoy vienen de iniciativas open source. Gracias a Hibernate y Spring podemos para “muestra un botón” dar como resultado el estándar compuesto por EJB 3 (26) y JPA.

El camino que esperamos no es difícil de pensar o desear. Ellos deberían seguir las actividades más productivas y eso volverlo estándar. No sacar un estándar que finalmente solo una muestra de la comunidad Java utiliza. “Otro botón” el muy conocido Java Server Faces. Que hoy por hoy aún no es adoptado en todas las organizaciones y se utiliza más en ambiente intranet y por evitar la complejidad del modelo request – response.

Los años pasan y no solo las metodologías están pidiendo cambios. Por muchos años hemos llevado proyectos siguiendo los lineamientos de RUP (27), PMI (28) y hemos seguido el esquema Análisis, Diseño, Construcción, Implantación, Soporte Post Implantación. Este modelo que suena a “Cascada” (29) funciona muy bien para proyectos predecibles, similares, pero, para crear nuevos productos o para proyectos de mucho tiempo puede convertirse en una relación en el que ni el cliente ni el proveedor al final se quieren ver. Creo que esto es entendible. ¿Quiénes fueron nuestros primeros profesores de software?, pues Ingenieros Civiles e Industriales. Ellos pues siguen dicho proceso. Nosotros necesitamos algo diferente.

Las metodologías ágiles entonces como Scrum (30), Kanban (31), XP (32) ya están causando muchos cambios e impacto en las organizaciones de a pocos. Lamentablemente y como pasa siempre en nuestro País, nos enteramos o adoptamos algo cuando ya en nuestros vecinos Argentina, Chile, Colombia, Brasil, por mencionar algunos ya vienen tras cuatro años practicando y aplicando.

Hoy por hoy también invito al lector a revisar sobre Lean Software (33) pues esto les permitirá ver que no siempre hay que estar pegado al estándar si es que este no nos permite marcar la diferencia. "Piensa en grande, actúa en pequeño, equivócate rápido; aprende con rapidez".

Estas metodologías tienen un común denominador y que es parte del manifiesto ágil (34) que dio lugar a todo: Dar importancia al equipo, las personas, sus interacciones; al software como nuestro objetivo final, el cual debe funcionar y no depositar nuestra confianza en sólo herramientas, o documentación exhaustiva, a dar valor en resumen a lo que es estrictamente necesario; trabajar en un esquema basado en iteraciones o ciclos cortos para obtener un mejor feedback del cliente, lo cual implica no tener un contrato en el cual el cliente y el proveedor no tengan una relación win-to-win. El punto es tener a las dos partes como ganadoras. Entonces tenemos que poder responder al cambio, por lo cual los cronogramas Gantt se van a la basura. Cronogramas que nunca han reflejado la verdad y solo dan aproximaciones. Entiéndase bien: No se puede predecir el futuro.

Ante todo esta parte metodológica mencionada anteriormente. Las exigencias de hoy entonces te piden desarrollar cosas “para ayer”. Durante los últimos años muchas empresas sobre la base de estándares java desarrollaban su Framework de Trabajo, lo que originaba tener un Arquitecto que daba mantenimiento a ese framework y llenarlo de todo lo que se necesitaba por proyecto creándose unos “Transformers” de arquitecturas para dar soporte a todas las necesidades.

Por suerte estos últimos años, toda esta onda ágil ha traído innovación e iniciativas open source para crear aplicaciones más rápidamente sin sacrificar buenas prácticas y performance. Iniciativas como Spring Roo (35), Grails (36), Play (37), Vaadin (38), Lift (39) han salido al mercado. Todas ellas open source, y dando soporte a nuevos lenguajes para la plataforma java como Groovy (40).

En particular he probado Spring Roo, que para entenderlo bien hay que conocer muchos de los proyectos de SpringSource.com, JPA. Grails me pareció una muy buena idea como respuesta a Ruby (41) & Rails (42) que es otro mundo y no solo optar por JRuby (43), sino convertirse en un framework MVC para desarrollar con java y Groovy.

Play es como dice su traducción para desarrollar como jugando. Es muy sencillo de usar y basado en Scala (44) un lenguaje del cual también debes enterarte y que merece un artículo aparte. Está basado en Scala en su parte interna, pero puedes desarrollar con java. Permite recargar tus clases java sin bajar el contenedor.

Los otros no los he probado pero, puedes visitar los links que adjunto para enterarte por ti mismo estimado lector. Aunque se puede criticar que solo sirve para hacer mantenimientos simples, para alguien que los ha usado y personalizado, les puedo asegurar que es una buena iniciativa y que no deberíamos desestimar. Hay buenos casos de éxito en países vecinos y en el extranjero. ¿Que esperamos? ¿Queremos sorprender al jefe? ¿Queremos destacarnos frente a la competencia con nuestra capacidad de delivery? Entonces te invito a leer más sobre ellos.

Espero les sea de utilidad y si se ha compartido mis datos personales, gustosamente podré colaborar con ustedes. Su colaborador José Díaz.

(1) Pontificia Universidad Católica del Perú http://www.pucp.edu.pe

(2) NetBeans.org http://netbeans.org/

(3) Eclipse.org http://eclipse.org/

(4) http://www.jetbrains.com/idea/

(5) http://tomcat.apache.org/

(6) http://www.jboss.org/

(7) http://www-01.ibm.com/software/pe/websphere/

(8) http://glassfish.java.net/es/

(9) http://www.oracle.com/technetwork/middleware/weblogic/overview/index.html

(10) http://www.vmware.com/products/vfabric-tcserver/

(11) http://www.mulesoft.org/