Introducción

Esta es mi primera contribución para Artesanos de Software.

Soy un desarrollador de software “de la vieja escuela”, por decirlo de alguna manera. Hace años, pensaba que tenía bastante dominado este asunto de la programación, hasta que me topé con Extreme Programming y todo el ecosistema de Métodos Ágiles que se ha desarrollado desde entonces. Para mi, todo cambió desde entonces y me dí cuenta de lo poco que sé en realidad. He estado practicando la disciplina del Desarrollo Dirigido por Pruebas o TDD ahora si y ahora no por los últimos ocho años. Quienes me conozcan, sabrán que no ha sido ni por mucho un proceso fácil ni mucho menos rápido. Sin embargo, si solo pudiera lograr que todos los desarrolladores de mi equipo adoptaran una sola práctica de XP, esa sería TDD.

Las excusas abundan, es simplemente demasiado fácil ceder y dejar de hacerlo. Desde los clásicos “en mi empresa no me lo permiten” y “mi jefe dice que me pagan por escribir funcionalidad, no pruebas” hasta los no tan infrecuentes “las pruebas son trabajo de QA, no mio” o “esta porquería es una mi3rd@, ¡es imposible de probar!”. Lo sé porque yo mismo he estado en esas situaciones, he dado las mismas excusas y ni una sola vez puedo decir que el resultado haya sido positivo para mi o para el proyecto.

El propósito de este blog es allanar un poco el camino para aquellos que estén considerando aprender TDD y posiblemente utilizarlo en su trabajo o en proyectos personales. Para mi no ha sido fácil y aún estoy aprendiendo. Si alguien puede sacar algo en claro de mis propias experiencias pasadas, creo que eso será más que suficiente para compensar el tiempo invertido en el mismo.

Este blog debe considerarse un trabajo en progreso. La idea del mismo comenzó hace probablemente tres o cuatro meses. Simplemente hay demasiados temas y ángulos para cubrir de una sola vez. El material disponible en la red, las anécdotas personales, las técnicas, los “pitfalls” (alguien, español por favor?), los “tips”, etc. son suficientes como para llenar uno o varios libros así que no puedo esperar cubrir todas las bases en un solo post. Debido a ello, en este post me concentraré exclusivamente en el tema de las pruebas unitarias. Solo el tiempo dirá si soy capaz de llevar este proyecto a buen término

>>> 2 + 3
5

>>> a = 2
>>> a + 3
5
>>> b = 3
>>> a + b
5
>>> def sum(a, b):
...   return a + b
...
>>> sum(2, 3)
5

public class UsuarioPOJO {
// código de la clase
}

Si se está aprendiendo algún patrón de diseño para que ciertos componentes se expongan como servcios o similares intenciones:

public class BusquedaUsuariosFacade{
// código de la clase
}

Si se tiene un estilo de diseño de responabilidades y roles, o aplicar un DDD, que indica que necesitamos ciertos colaboradores como:

public class UsuarioBuilder{
// código de la clase
}

Por el momento, es de esperar que basten estos ejemplos. El punto aquí es que los nombres que se asignan a las clases son algunas veces bastante atados al Framework que se utiliza, a algún patrón de diseño, o bien sólo a un rol o responsabilidad. Todo esto son detalles técnicos y en verdad hacen que el programador se olvide del dominio específico para el que realiza la aplicación. Uno podría aventurarse a decir que este mecanicismo es parte de que pocos sean críticos en cuanto a su diseño y que realmente se aprecie el problema en su escencia. Y en analogía con lo que indica Uncle Bob el código deberían gritar el dominio del problema y no una tecnología específica, es decir, Hibernate, Spring o ese nuevo patrón o tecnicismo que acabamos de aprender o que aplicamos como receta de cocina.


No está de más decir que algunos desarrolladores se olvidan del dominio o contexto del aplicativo que están resolviendo y simplemente le llaman a sus clases: FactoryEntitiyBean, CrudServiceBean, AuditLoggerBean, EventDispatcherBean, LoginStrategyBean, ThreadPoolImpl . Y el dominio del problema se desvanece.


Para efectos de aprendizaje está muy bien nombrar a las classes así, pero para la práctica no. Los ejemplos de diversas fuentes nombran sus clases haciendo clara referencia a las partes del tema que quieren aclarar pero al final pocos dicen que no se debe seguir al pie de la letra los nombres del ejemplo.


Con tales antecedentes presentemos a la propuesta de mejora. En UML muchos de estas palabras que agregamos como sufijo (o prefijo) a las clases son los llamados stereotypes que comunmente aparecen en los diagramas de clases o de secuencia. Y son bastante eficaces en mostrar la responsabilidad o rol que juegan en el diseño de la solución. A nivel de código estos stereotypes se pueden conservar y mantener el código documentado con el uso de una anotación. Que al final servirá como una marca (o tag) bastante útil.

@Stateless
@Remote(BusquedaUsuarios.class)
@Facade(responsability="Ejemplo de responsabilidad descrita",
documentationLink="http://wiki.artesanos.de/software")
public class BusquedaUsuariosAdscritos implements BusquedaUsuarios { ... } 

Tal y como se observa el nombre de nuestra clase ha quedado más limpio y sólo hace referencia al dominio/negocio. Admás se ha logrado mediante el uso de anotaciones a la medida documentar y plasmar ese rol o responsabilidad que anteriormente adjuntabamos a manera de sufijo (o prefijo).


Ahora bien, analicemos que ventajas nos reporta esta práctica. Hemos observado que se utilizan anotaciones y es necesario responder ¿por qué? Las anotaciones tienen algunas ventajas sobre el JavaDoc, ya que este metadata permanece en en el byte code y es accesible via reflection. Este tipo de documentación puede ser inclusive aprovechada durante el proceso de build o con heramientas de análisis estático de código.


La declaración de la anotación tipo marca para identificar un Facade como pieza de la solución, es el siguiente:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Facade {
/**
* Un link a documentación existente,
* o "user story" o "use case".
*/
String documentationLink() default "";
/**
* La intención escencial y responsabilidad(es)
* de la Facade que se implementa
*/
String responsibility();
}

En este ejemplo podemos observar que el atributo “documentationLink” es opcional, en el bien podría hacerse referencia a un sitio donde haya información de la decisión de diseño o proporcione la “user story” o el “use case” asociado a este componente. Para el caso de “responsability” por el contrario no es opcional. Algo interesante es que el uso de anotaciones puede forzar al desarrollador a proveer algún tipo de información escencial, lo cual sería el caso para este atributo. Adicionalmente podemos agregar cuantas anotaciones necesitemos para definir roles o responsabilidades de la clase, aunque lo mejor sería condensarlo en una sola anotación que exprese toda la idea.


Supongamos que nuestra clase ha dejado de ser un “Facade” protagonista al exterior y ahora simplemente es un “Provider” al interior de la implementación. Este cambio sin modificar el nombre de la clase se lograría facilmente colocando su nuevo Rol/Responsabilidad mediante la anotación correspondiente dentro de nuestra arquitectura propuesta. Es muy cierto que el cambio quizá involucre un cambio de paquete o algún otro refactor pero el punto es que la clase con su nombre dentro del dominio del problema sigue intacto, sólo ha rotado en su posición dentro de la estructura sin haberse preconcebido con un prefijo/sufijo a un Rol/Responsabilidad definitivo o por la tecnología en uso.

@Stateless
@Local(BusquedaUsuarios.class)
@Provider(responsability="Ejemplo de nueva responsabilidad descrita",
documentationLink="http://wiki.artesanos.de/software")
public class BusquedaUsuariosAdscritos implements BusquedaUsuarios { ... } 

Este tipo de anotaciones pueden inclusive ser más formalizadas y proveer más información que sea utilizada como meta-data para ser consumida por un Interceptor de los proporcionados por EJB3.x o alguna estrategia similar de AOP. Esta última sería la gran ventaja de adoptar esta propuesta ya que además de fomentar la claridad en los nombres de clases permitirá habilitar o deshabilitar comportamientos en las clases marcadas con anotaciones.

En resumen: Es mejor generar anotaciones propias (derivados de la arquitectura propuesta) que generen documentación útil y adicionen compotamiento en tiempo de ejecución (mediante interceptores, AOP); y con ello dejar los nombres de clases limpios y enfocados al dominio del problema.

Si sólo deseas escucharlo entonces:

El video del podcast:

La liga del artículo con los vínculos y demás información:

http://vivecodigo.org/2011/12/21/podcast-10-de-la-temporada-0/

Que lo disruten!!

“La situación fundamental de aprendizaje es una en la cual una persona aprende ayudando a quien realmente sabe que es lo que esta haciendo” Cristopher Alexander en ‘A Pattern Language’

Una de ellos fue el manejo de hilos. Los nuevos requerimeintos que debía satisfacer, requieren que se hagan cálculos con millones de datos, la velocidad es crucial, ya que se obtiene el siguiente dato en la orden de cien milésimas de segundo, y no es que el cálculo en sí tarde más que esa pequeña ventana de tiempo, sino que esperamos que se disparen varios eventos por cada dato, de tal modo que el hilo principal siga teniendo la oportunidad de manejar todos los eventos sin esperarse a que alguno de estos termine, incluyendo el pintado de la interfaz gráfica. Lo primero que me vino a la mente para esto fueron los hilos (gracias hilos por existir), pero comencé a toparme con detallles, uno de ellos es que todos los hilos se ejecutaban en algunos cores solamente, a pesar de que el server tiene 24 núcleos, trabajaban como locos los cores elegidos al azar, mientras se desperdiciaban los demás. Una búsqueda en la red me llevó al descubrimiento de las Tareas del .NET Framework 4.0 las cuales se encargan de generar los hilos, ¿cuántos y cómo? solo el CLR lo sabe, pero lo que también sabe es cuántos cores hay disponibles y la caga de trabajo que ya tienen, de tal modo que balancea los hilos generados y los ditribuye entre todos los núcleos. Problema resuelto para mi aplicación de escritorio.

Veamos la diferencia entre el uso de hilos y el uso de tareas con C# (a partir de la versión 4.0 del .NET Framework necesariamente). Primero el ejemplo con hilos:

class Program
{
   static void Main(string[] args)
   {
       DateTime inicio = DateTime.Now;
       for (int i = 0; i < 100000; i++)
       {
           int temp = i;
           Thread t = new Thread(() => method1(temp));
           t.Start();
       }
       DateTime fin = DateTime.Now;
       TimeSpan diff = fin - inicio;
       Console.WriteLine("Inicio= {0} - Fin= {1} - Diferencia= {2}:{3}:{4}.{5}",
                          inicio.ToString("yyyy/MM/dd HH:mm:ss.fffffff"),
                          fin.ToString("yyyy/MM/dd HH:mm:ss.fffffff"),
                          diff.Hours, diff.Minutes, diff.Seconds,
                          diff.Milliseconds;
       Console.ReadLine();
   }

   static void method1(int i)
   {
       for (int j = 0; j < 10000; j++)
       {
           double d = 45345 / 6546 * 7989 / 0.2254;  //cualquier procesamiento...
       }
   }
}

La ejecución de este código muestra en su salida:

Inicio= 2011/09/29 21:39:33.6400926 - Fin= 2011/09/29 21:53:23.1265365 -
Diferencia= 0:13:49.486

Como podemos ver, se tardó casi 14 minutos en lanzar los hilos, solamente en generarlos, cuando descubrí esto, vi que no me servía la utilización directa de muchos hilos, ya que hubiera tenido que idear una manera (sofisticada) de adminsitrar su generación para que fuese gradual.

Afortunadamente, los creadores del .NET Framework se preocuparon por proveer mecanismos eficientes para el manejo de concurrencia, apartír de la versión 4.0, entre esos mecanismos, existe la clase Task, la cual para fines prácticos, es como tener hilos ya que permite ejecutar procesos en paralelo. Veamos el mismo ejemplo con tareas:

class Program
{
   static void Main(string[] args)
   {
       DateTime inicio = DateTime.Now;
       for (int i = 0; i < 100000; i++)
       {
           int temp = i;
           Task t = Task.Factory.StartNew(() => method1(temp));
       }
       DateTime fin = DateTime.Now;
       TimeSpan diff = fin - inicio;
       Console.WriteLine("Inicio= {0} - Fin= {1} - Diferencia= {2}:{3}:{4}.{5}",
                          inicio.ToString("yyyy/MM/dd HH:mm:ss.fffffff"),
                          fin.ToString("yyyy/MM/dd HH:mm:ss.fffffff"),
                          diff.Hours, diff.Minutes, diff.Seconds,
                          diff.Milliseconds;
       Console.ReadLine();
   }

   static void method1(int i)
   {
       for (int j = 0; j < 10000; j++)
       {
           double d = 45345 / 6546 * 7989 / 0.2254;  //cualquier procesamiento...
       }
   }
}

Con la siguiente salida:

Inicio= 2011/09/29 21:39:07.0425713 - Fin= 2011/09/29 21:39:07.0975745 -
Diferencia= 0:0:0.133

Como podemos notar, la diferencia entre lanzar hilos y tareas es abismal, lanzar las tareas ha tomado solamente 133 milisegundos!.

¿Por qué es tan grande la diferencia? Resulta que las tareas, en algún momento se convierten el hilos, pero nosotros no somos los encargados de decidir cúantos ni cuándo serán lanzados, quien se encarga es el CLR (Common Language Runtime). Para mi sorpresa, el CLR se entera bien de cúantos núcleos existen y de cuánta carga de trabajo tienen, y en base a eso, es que decide cómo repartir las unidades de procesamiento (Tasks) en los hilos, los cuales son reutilizados una vez que terminan de hacer su trabajo. Al parecer esta pequeña, pero importante diferencia, le ahorra mucho tiempo al sistema operativo en cuestión de adminsitrar los hilos de ejecución.

Esto fue solo el inicio del desarrollo de aplicaciones paralelas que he comenzado a programar, existen muchas monerias que se pueden explotar en cuanto a paralelo en .NET 4.0 se refiere, como se puede apreciar en la siguiente imagen, las características que se incorporaron en esta versión están enfocadas principalmente al paralelo.

He escuchado que en la versión 7 de Java existen las Tareas y en algunos meses desarrollaré el mismo tipo de aplicaciones, pero en Java, espero sinceramente que la JVM también se destaque en la administración de unidades de procesamiento, de lo contrario me tocará sufrir con este tema. Si alguien ha tenido la oportunidad de explotar esta característica de Java, le agradeceré que comparta su experiencia.

Como recomendación, pueden referirse al libro llamado “Pro .NET 4 Parallel Programming in C#” del autor Adam Freeman, el cual me ha sido de mucha ayuda.

—–

Claudia (@clausia)

Para mí, pasar de una curiosidad por un nueva tecnología, a código que pueda usar para jugar un rato o usar en algún proyecto es complicado y requiere de mucho esfuerzo, aun así con el tiempo he pulido un poco este proceso. Quiero compartirles con un ejemplo como es que llego de una curiosidad por Comet a código.

Todo inicia con una simple pregunta, por ejemplo, ¿cómo podría pintar logs de mi aplicación en un div de HTML sin tener que recargar la página? Esta es la parte más difíciles, porque es en donde tengo que hacer preguntas con las palabras correctas, primero a Google y luego a uno que otro Chapulin Colorado de la programación para que me den la respuesta u orientación que deseo. Porque bien me pudo haber dicho cualquier fuente que Ajax me resolvía el problema, y en efecto me lo resuelve pero Reverse Ajax o Ajax Push. Las preguntas adecuadas son la solución.

Después de mucho investigar qué es lo que necesito aprender, logro saber la palabra clave, el inicio del la aventura, Comet. Es momento de empaparme en la filosofía de la tecnología, saber ¿para qué sirve?, si es lo que necesito en realidad, ¿por qué existe?, ¿que existía antes?, etc.

Esta parte abre muchas interrogantes, en este caso supe que no solo se llama Comet, también que existen otras formas de resolver el mismo problema, por ejemplo con WebSocket.

Bueno pues a escribir mas palabras en el buscador. Momento, que un error en el que cuido no caer, es en abarcar mucho y reducir mi visión en búsqueda de la de la solución. Este problema lo resuelvo viendo demos, leyendo más artículos, y si aun no puedo saber con certeza que tecnología es la adecuada, es momento de la resignación, no hay de otra más que empezar a ensuciarse los dedos y quemarse las pestañas, pero sin perder el enfoque y sin desesperarse. La paciencia es una aliada.

Me he dado cuenta que mucha de la información que circula es repetitiva, dice muchas veces lo mismo, solo diferentes autores, así que necesito distinguir de las fuentes que valen la pena el esfuerzo, pero esto es algo gradual. Después de leer varios artículos, veo la palabra Bayeux Protocol una y otra vez, también CometD Bayeux Ajax Push, bueno pues resulta que la mejor fuente para aprender una nueva tecnología es en …, pues en la fuente misa de la tecnología, en la página oficial y su documentación. Soy capaz de leer 5 hojas con contenido técnico en media hora, y también soy capaz de releerlas y entender algo diferente de la última vez en varias ocasiones seguidas. Nadie nos agradecerá ni dara premios por leer rápido y no entender nada de lo que dice la documentación, lamentablemente no siempre existen los ejemplos copy/paste, así que solo queda ponerse cómodo y disfrutar de la función, o del método, en fin.

Al final de de todo esto, leo completamente la página http://cometd.org/documentation y resulta que si existe un copy/paste sencillo primer, sigo las instrucciones a la Maven Way y guala, ya soy un experto en esta tecnología.

Pues no, resulta que no hice mi tarea y no tendré recreo, así que a revisar el código. Después de descargar el proyecto mvn, reviso y estudio el código, gano la confianza para hacer cambios al código y ver qué sucede. Este momento es muy importante porque es cuando adaptamos el código que nos dan de ejemplo a nuestras necesidades.

Modifico el archivo application.js para adaptarlo al estilo en el que yo escribo código y con esto estudio y entiendo más sobre comet, por ejemplo:

var cometd = $.cometd;

$(document).ready(function(){

    var _connected = false;
    function _metaConnect(message){
        if (cometd.isDisconnected()){
            _connected = false;
            _connectionClosed();
            return;
        }

        var wasConnected = _connected;
        _connected = message.successful === true;
        if (!wasConnected && _connected){
            _connectionEstablished();
        }
        else if (wasConnected && !_connected){
            _connectionBroken();
        }
    }
    // Function invoked when first contacting the server and
    // when the server has lost the state of this client
    function _metaHandshake(handshake){
        if (handshake.successful === true){
            cometd.batch(function(){
                cometd.subscribe('/hello', function(message){
                    $('#body').append('
Server Says: ' + message.data.greeting + '

');
                });
                // Publish on a service channel since the message is for the server only
                cometd.publish('/service/hello', { name: 'World' });
            });
        }
    }

    var cometURL = location.protocol + "//" + location.host + config.contextPath + "/cometd";
    cometd.configure({
        url: cometURL,
        logLevel: 'debug'
    });

    cometd.addListener('/meta/handshake', _metaHandshake);
    cometd.addListener('/meta/connect', _metaConnect);
    cometd.handshake();
});

// Disconnect when the page unloads
$(window).unload(function(){
    cometd.disconnect(true);
});

/*Funciones xyz*/
var  _connectionEstablished = function(){
    $('#body').append('
CometD Connection Established

');
}

var _connectionBroken = function(){
    $('#body').append('
CometD Connection Broken

');
}

var _connectionClosed = function (){
    $('#body').append('
CometD Connection Closed

');
}

Y para terminar modifico HelloService.java con una muy ligera modificación, quedando así:

public void processHello(ServerSession remote, Message message) throws InterruptedException{
        Map input = message.getDataAsMap();
        String name = (String)input.get("name");

        Map output = new HashMap();
        output.put("greeting", "Hello, " + name);
        remote.deliver(getServerSession(), "/hello", output, null);

        Thread.sleep(3000);

        output.put("greeting", "Hello, " + "artesanos.de/software");
        remote.deliver(getServerSession(), "/hello", output, null);
}

Salida:
Server Says: Hello, World
CometD Connection Established
CometD Connection Broken
CometD Connection Established
Server Says: Hello, artesanos.de/software

Gracias por tu tiempo y saludos. Atentamente: Rodrigo Salado Anaya

En los últimos meses hemos tenido la oportunidad de trabajar en proyectos internos, sin embargo, una de las cosas que nos motivan a continuar desarrollando es el hecho de compartir lo que aprendemos a través de eventos, ya sea organizados por nosotros y también a los que nos invitan; y precisamente, como comunidad hemos estado bastante activos presencialmente hablando, por lo tanto, me gustaría listar un par de eventos/lugares a los cuales hemos asistido…

• UPAEP(Universidad Popular Autónoma del Estado de Puebla)
  • En donde con ayuda de Jaime Castillo y María del Rocío Gpe. Morales, presentamos el tema de:
    • “Lenguajes dinámicos para la JVM” por @neodevelop
• FLISOL(Esime Culhuacán)
  • Enrique Díaz(@nRikeDiaz) fue organizador de este evento en esta universidad y junto con él pudimos participar en dos charlas:
    • “10 años en la industria, ¿Que esperar de la universidad?” por @domix
    • “Introducción a Groovy” por mí(@neodevelop)
    • “Introducción a Grails” por @domix y yo(@neodevelop)
• GULEV(Grupo de Usuarios Linux del Estado de Veracruz)
  • Con lugar en el WTC de Veracruz y organizada por Miguel Angel López (@GulevSL), presentamos las ponencias de:
    • “Estrategias ágiles para incrementar calidad al construir y probar software” por@domix
    • “Groovy: el lenguaje dinámico para la JVM” por @neodevelop
    • “Desarrollo políglota en la plataforma Java” por @domix

De cada uno de estos nos hemos llevado muy buenas experiencias, y precisamente esa es una de las tantas cosas que me da el pertenecer a una comunidad como springhispano.org y grails.org.mx: la posibilidad de conocer a más personas interesadas en el uso de tecnologías similares, de darle rostro al timeline, de tener charlas fluidas y amenas, de conocer los intereses e inquietudes de alumnos, maestros, empresarios, desarrolladores…

La comunidad me ha dado conocimiento, ya que cada vez que se realiza una reunión los ponentes despiertan la inquietud del uso de herramientas que no conocía o simplemente había escuchado de ellas…

La comunidad me permite expresarme, exponer mis dudas, tener otro punto de vista diferente, ampliar mi abanico de posibilidades para resolver un problema…

Inclusive, me dió la capacidad de darles a los miembros la posibilidad de asistir a un curso de certificación a través del proyecto #PCJ…

En realidad, hay demasiadas cosas que puedo mencionar que considero aportación mutua; la actividad dentro de las comunidades es algo que me da identidad y que le da un verdadero significado al concepto ‘social’

Espero que al igual que yo, los lectores y desarrolladores encuentren un interés en ser parte de comunidades, y por supuesto, en springhispano.org y grails.org.mx serán siempre bienvenidos…