Java 8 goodie: Dividiendo elementos en lotes de forma facil (batch jobs)

Después de una hibernación larga, un truco que he podido utilizar recientemente. A ver si me animo y la cosa continúa de vez en cuando.

A veces tenemos una lista de elementos que queremos procesar pero en vez de hacerlo de uno en uno, queremos hacerlo en bloques. Se puede hacer con el típico bucle anidado que va añadiendo a una lista hasta llegar al tamaño del batch..., pero con Java 8 podemos hacerlo de una forma muy muy sencilla usando streams, y usando generics además podemos dejarla reutilizable.

Con algo tal que así (sí, se puede escribir todo en una linea, pero no es una competición de escribir menos)

public static <T> List<List<T>> splitInBatches(List<T> completeList, int batchSize) {
 int blocks = (int) Math.ceil(completeList.size() / (float) batchSize);
 return IntStream.range(0, blocks).mapToObj(count -> {
  int initList = count * batchSize;
  int endList = Math.min(completeList.size(), initList + batchSize);
  return completeList.subList(initList, endList);
 }).collect(Collectors.toList());
}

podemos dividir una lista de elementos y que nos devuelva una lista de listas de elementos, cada una con un tamaño máximo batchSize.
Dado un código

List<String> listaDeCodigos = Arrays.asList("ES","EN","FR"...);
for(List<String> batch : splitInBatches(listaDeCodigos,20))
{
// Hacer algo con el batch de como máximo 20 códigos
}

Podemos procesar la lista de elementos inicial de 20 en 20.

¿Para que nos puede servir? Pues por ejemplo, yo lo he utilizado para procesar una lista de notificaciones pendientes y dividir el trabajo actual de enviar los mails en lotes de X y distribuir los lotes entre los nodos de un cluster. En otro caso lo he utilizado para dividir una consulta SQL muy pesada (de esas que hacen que el servidor de BDD te corte la conexión) en consultas más pequeñas y poder hacerlas de forma concurrente...

No es algo que se use todos los días, pero si alguna vez os pasa, espero que esta solución tan sencilla os sirva.

Happy coding! EJ

Sesiones, Tomcat y consumo de memoria

Dado que en nuestro caso, además de desarrollar las aplicaciones, gestionamos los servidores de aplicaciones (la parte software), de vez en cuando hago revisiones periódicas del consumo de memoria, versiones de librerías… y en la última revisión encontré algunas cosas interesantes, pero una me llamó bastante la atención:
El consumidor #1 de memoria de los servidores de aplicaciones era… ¡El gestor de sesiones del Tomcat! Aunque parezca una perogrullada, el motivo de mi sorpresa es que nosotros no guardamos apenas datos en sesión, y en muchos casos ni siquiera usamos la sesión para nada puesto que muchas de nuestras aplicaciones son simplemente de consulta.
Así que revisando, revisando, encontré que el problema venía dado por varios factores:

• Aunque nosotros no usáramos la sesión para nada, algunas llamadas nuestras para comprobar si existía un atributo en la sesión o no, causaban que se crease la sesión sí o sí. Así que un par de if(request.getSession().getAttribute(…)) que se había colado se cambiaron por if(request.getSession(false)!=null && …) para evitar crear sesiones innecesarias.
• Debido a que ahora tenemos un cluster con “session failover” aunque a la sesión no le metas nada, ocupa un cierto tamaño que al multiplicarse en número empieza a ser significativo. Debido al mismo factor, las sesiones ocupan espacio en ambos nodos del cluster y no se con “fácilmente recoletables”.
• Dado que las sesiones son creadas “sin querer”, nadie las cierra y por tanto caducan solas agotando el tiempo máximo de vida sin actividad (session-timeout). Así que durante ese tiempo ocupan espacio en ambos servidores del cluster, inútilmente y encima no se pueden recolectar (GC). 
• Dado que nuestras aplicaciones son públicas, los buscadores las recorren a menudo y en algunos casos sin reutilizar las cookies entre peticiones, así que nos crean una sesión por petición. 

Afortunadamente, para lo bueno y lo malo usamos nuestro propio framework así que introducir cambios para evitar al máximo la creación de sesiones no fue nada complicado. Así mismo, configurar por web.xml que el time-out de las sesiones es de 1 minuto, por si alguna se escapa, y poner un filtro para las aplicaciones solo públicas que si se crea alguna sesión la cierre al acabar cada petición tampoco fue muy complicado (esto último es por qué algunas librerías usadas en algunas aplicaciones pueden crearte sesiones sin que puedas hacer mucho por evitarlo, o si usas JSP o alguna otra tecnología que las cree alegremente).
El resultado final, probado en un nodo antes que en otro, fue que para el mismo tráfico y uso, todo funcionaba igual pero con 1/3 menos de consumo de memoria. Además, ahora un pico de tráfico público, más difícil de controlar, no nos daría tantos problemas mientras las sesiones están esperando a expirar, como pasaba antes, ya que si se crean, el GC las puede liquidar sin problemas.

La moraleja es que aunque creas que no estas usando sesiones, puede que en realidad sí lo estés haciendo y te estén afectando más de lo que creas.

¡Un saludo y happy coding!
E.J.

Comparadores, igualdad y error difícil de detectar

Hola,

Después de leer por los internetes la enésima entrada sobre comparar objetos en Java y encontrar de nuevo el error que tienen el 90% de ellas, voy a aportar mi granito de arena para que quede constancia y alguno no se pille los dedos.

Para los que se aburren de leer pronto: Mucho ojo al devolver 0 en el método compare(Object o1, Object o2), tanto al implementar la interfaz Comparable como al crear un objeto Comparator.

La documentación dice que devolver 0 significa que los objetos son iguales, pero eso no es lo mismo que decir que nos da igual como estén ordenados, que eso es lo que entiende mucha gente instintivamente. Así que la pregunta es... ¿que ocurre cuando tenemos una Collection que no permite objetos repetidos ordenada por ese criterio?
La demostración, aquí:

import java.util.Arrays;
import java.util.Comparator;
import java.util.Set;
import java.util.TreeSet;

import lombok.Data;

public class App
{
  @Data
  static class ObjetoOrdenado{
    private final String nombre;
    private final Integer edad;    
  }
  
  static Comparator<objetoordenado> COMPARADOR_POR_EDAD =
     new Comparator<objetoordenado>()
  {
    @Override
    public int compare(ObjetoOrdenado o1, ObjetoOrdenado o2)
    {
      // Haciendo esto tendremos un problema, ya que
      // si devolvemos 0, uno de los elementos desaparecerá
      return o1.getEdad().compareTo(o2.getEdad());
    }
  };
  
  public static void main(String[] args)
  {
    ObjetoOrdenado[] aOrdenar = new ObjetoOrdenado[]{
        new ObjetoOrdenado("John",24)
        ,new ObjetoOrdenado("Jane",29)
        ,new ObjetoOrdenado("Bob",30)
        ,new ObjetoOrdenado("Susan",27)
        ,new ObjetoOrdenado("Kenny",24)
    };
    Set<objetoordenado> ordenados = new TreeSet(COMPARADOR_POR_EDAD);    
    ordenados.addAll(Arrays.asList(aOrdenar));
    for (ObjetoOrdenado o : ordenados)
    {
      System.err.println(o.getEdad() + " - " + o.getNombre());
    }
    System.err.println("They killed Kenny!");
  }
}

->

24 - John
27 - Susan
29 - Jane
30 - Bob


El resultado es que el pobre Kenny desaparece, eliminado por ser considerado "igual" que John al ordenar. La solución es no devolver 0 excepto cuando estemos seguros de que efectivamente son iguales, y si no pues devolvemos un 1 o un -1, lo que sea, pero distinto de 0.

Ésta implementación de compare sería una solución

import java.util.Arrays;
...
    @Override
    public int compare(ObjetoOrdenado o1, ObjetoOrdenado o2)
    {
      // Primero ordenamos por edad
      int temp = o1.getEdad().compareTo(o2.getEdad());
      if(temp==0)
      {
        // Si la edad es la misma, ordenamos por nombre
        temp = o1.getNombre().compareTo(o2.getNombre());
        // Si la edad y el nombre son iguales, ordenamos al azar.
        // Si realmente nombre y edad iguales significa que solo
        // queremos UN objeto, entonces podríamos saltar este paso y devolver 0
        if(temp==0)
        {
         temp = -1;  
        }
      }
      return temp;
    }
  };
...

Es un error difícil de detectar por que podemos tener una colección con todos los objetos, todo va bien, los ordenamos y ¡zas! mágicamente tenemos menos, sin excepciones, sin avisos.

Así que espero que a alguien le sirva para no caer en ello, siguiendo los típicos ejemplos de Internet que suelen explicarlo mal. Por dejarlo claro, yo caí en ello y por eso lo tengo bien aprendido :D.

Happy coding! EJ

El problema de N+1 consultas: explicación, caso real y solución propuesta

La entrada de hoy trata sobre un problema recurrente al acceder a bases de datos y especialmente al usar abstracciones por encima, como JPA o Hibernate, sin leer en detalle el funcionamiento interno de estas herramientas.

El problema se da al querer acceder a un objeto y sus N objetos relacionados, normalmente a través de claves foráneas, ya que la estrategia simple implica hacer una consulta para obtener el objeto principal y las claves de los objetos relacionados, y luego hacer N consultas, cada una para obtener un objeto relacionado, usando las claves obtenidas en la primera consulta. De ahí el nombre “N+1 consultas”. La trampa de este problema está en que con pocos datos o en ejemplos simples, el deterioro del rendimiento puede no ser significativo, pero cuando el número de objetos relacionados crece y los objetos relacionados están relacionados a su vez con otros objetos, que a su vez... En fin, la cosa crece exponencialmente y es la causa principal de que la gente se queje de que los ORM son lentos, ya que por defecto éste es su comportamiento y la gente no suele ir más allá.

Para ilustrar el problema usaremos un caso real con el que tuve que lidiar hace relativamente poco: mostrar en detalle los exámenes de un plan de estudios (sí, ya sé que suena a problema de examen de la carrera :) ). La cuestión es que eso que a principio suena tan simple se transforma en:

• Los planes de estudios se ofrecen en varios campus (es lo que tiene una universidad con varios campus).
• Para cada plan/campus, hay unas asignaturas que se ofrecen.
• Cada asignatura, se divide a su vez en grupos-asignatura (por turnos, por letras, por plan ya que una asignatura puede ofrecerse en varios planes).
• Para cada grupo-asignatura, se definen una serie de exámenes con sus datos.
• Además, cada examen puede tener lugar en varias localizaciones (normalmente aulas de un mismo edificio).
• Para componer más la cosa, los grupos-asignatura se juntan en entidades llamadas grupo-horario para poder distribuir los alumnos sin problemas de forma ordenada sin que haya solapamientos de horarios/exámenes etc.
• Todo esto, filtrado por año académico.

Si queremos obtener estos datos para poder mostrarlos y lo hacemos “al tun-tun”, lo que ocurre es que, partiendo del código de plan de estudios, campus y año académico:

• Obtenemos los datos del plan de estudios a partir de su código.
• Obtenemos los datos del campus a partir su código.
• Obtenemos la lista de códigos de los grupos-horario que se ofrecen para ese año académico filtrando por plan, campus y año.
• Obtenemos los datos del grupo-horario a partir de su código.
• Obtenemos los códigos de los grupos-asignatura de cada grupo-horario según el código de grupo-horario y el año académico.
• Obtenemos los datos del grupo-asignatura por código
• Obtenemos los datos de la asignatura por la clave foránea que tiene grupo-asignatura.
• Obtenemos los códigos de los exámenes de cada grupo-asignatura.
• Obtenemos los datos de cada examen por código
• Obtenemos los códigos de las localizaciones de cada examen.
• Obtenemos los datos de cada localización por código.

Cada una de esas lineas implica una consulta de 1 o N elementos, con el retardo extra que ello implica. Y eso si solo nos traemos los elementos necesarios, si usamos un  ORM y no tenemos cuidado con las relaciones que tenemos marcadas como “eager fetching”, podemos hacer muchas más consultas y traernos además multitud de objetos que, encima, no vamos a usar. La solución eficiente en cuanto a minimizar las consultas es, en este caso, sencilla: podemos usar una sola consulta para obtener todos esos datos. Una señora consulta, sí, y con datos repetidos, también, pero en un único viaje por la red, que en muchas veces será lo que más nos importe. La consulta, sin entrar en detalle, sería algo así

• Plan de estudios
• ∟ Datos del plan de estudios
• ∟ Datos del campus
• ∟ Lista de grupos-horario
• ∟ Datos de grupo-horario
• ∟ Lista de grupos-asignatura
• ∟ Datos de grupo-asignatura
• ∟ Datos de asignatura
• ∟ Lista de exámenes
• ∟ Datos de examen
• ∟ Lista de localizaciones
• ∟ Datos de localización

Ahora bien, si tenemos los datos de plan de estudio y campus repetidos en cada fila del resultado, los de cada grupo-horario para n filas etc. ¿Cómo hacemos para reconstruir el árbol de objetos sin que sea una pesadilla? Ahí es donde entra en marcha algo como Ibatis/MyBatis, que no sólo nos permite definir libremente las consultas si no que se encarga de “separar” los datos adecuadamente una vez se lo indiquemos en el fichero de “mapeo”. En este caso, al definir la consulta le diríamos que el resultado es un objeto de la clase PlanEstudios que contiene los datos del plan, y una referencia a un objeto de la clase Campus, que contendrá los datos del campus. Además, la clase PlanEstudios contiene una lista de objetos GrupoHorario, que se puede discriminar con la columna correspondiente al código de grupo-horario, el cual contiene los datos del mismo y una lista de objetos GrupoAsignatura el cual...

Una vez hecho así, podemos ejecutar la consulta y ésta, suponiendo que los datos estén bien, devolverá un único objeto de la clase PlanEstudios, con la listade GrupoHorario rellenada, y para cada GrupoHorario sus datos rellenados y sus listas de GruposAsignatura rellenadas etc. Todo el árbol de objetos rellenado y con los datos en su lugar con una sola consulta, no sólo a nivel SQL si no también a nivel de lógica, lo cual es una ventaja importante.

Obviamente, todo tiene su precio y en este caso el precio es introducir el framework Ibatis/MyBatis, y definir el mapeo de las columnas a los campos de los objetos, pero el beneficio es claro en cuanto a claridad en el código y rendimiento. Por otro lado, mencionar que no siempre es posible convertir todas las consultas en una (por ejemplo cuando un objeto está relacionado con dos listas de objetos independientes), pero en este caso lo que se puede hacer es definir la consulta de forma que obtenga los mayores datos posibles de la forma más eficiente minimizando las, en este caso inevitables, “consultas N”.

Cabe también mencionar que las herramientas ORM decentes incluyen opciones (véase la especificación del tipo de fetch y la utilización de “inner join” en  JPA) para poder controlar este tipo de cosas y, si bien de forma más limitada, permiten evitar en algunos casos el problema de las N+1 consultas y/o de la carga de objetos innecesaria. Así que antes de culpar a la herramienta, hay que asegurarse de que una la está usando correctamente.

No incluyo en esta entrada detalles de implementación, para no hacerla aun más extensa, pero espero que sirva para ilustrar un problema que existe y os encontrareis en el mundo real, y una forma de solucionarlo. Si el tema interesa, se podría hacer otra entrada con detalles de ese tipo, pero esa es otra historia ;).

Happy coding! EJ

Cluster de Tomcats con balanceo y "session failover"

Al hilo del artículo de David González Múltiples Tomcats con Apache y conector HTTP o AJP y el problema mencionado de tener que reiniciar un Tomcat al actualizar aplicaciones y perder servicio, vamos a añadir este articulillo rápido para explicar como montar un cluster de Tomcats con varias aplicaciones intentando no perder servicio al reiniciar. En principio la idea es tener todas las aplicaciones en 1 Tomcat y hacer cluster para que podamos pararlo y re-arrancarlo sin perder servicio. También serviría, con ligeras modificaciones, para tener varios Tomcat, dividiendo las aplicaciones entre ellos, y luego "clusterizárlos". Con eso conseguiríamos las ventajas que menciona David, más las de este artículo.

El primer paso es tener tus aplicaciones montadas en un Tomcat normal y corriente. Si no sabes hacerlo, empieza por ahí ya que éste artículo te será muy complejo sin una buena base.

Vamos a suponer que las maquinas donde quieres desplegar las aplicaciones se llaman app_host1.com y app_host2.com (nombres no publicos pero accesibles desde el servidor donde se encuentra el Apache) y que en ambas escucha el Tomcat con el protocolo AJP por el puerto 8009 o con el protocolo HTTP por el puerto 8080. Podemos usar el protocolo que más nos convenga (a AJP se le supone mejor rendimiento pero cada uno...)

Una vez tenemos claro esto, para dividir la carga entre las dos máquinas y enviarla a los Tomcats, y con "sticky sessions", usaremos el mod_proxy_balancer de Apache, añadiendo este bloque a la configuración en el lugar adecuado (depende de lo que queramos hacer y la versión de Apache, por defecto httpd.conf):

 # Definición del cluster con 2 nodos, usando el protocolo AJP
 <Proxy balancer://app_ajp_cluster>
  BalancerMember ajp://app_hos1.com:8009 route=Tomcat-All.1  
  BalancerMember ajp://app_hos2.com:8009 route=Tomcat-All.2  
  ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On
 </Proxy> 
 # Definición del cluster con 2 nodos, usando el protocolo HTTP
 <Proxy balancer://app_http_cluster>
  BalancerMember http://app_hos1.com:8080 route=Tomcat-All.1  
  BalancerMember http://app_hos2.com:8080 route=Tomcat-All.2  
  ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On
 </Proxy> 
 # Descomenta la siguiente parte para administrar el cluster, si sabes lo que haces.
 # Esta parte sirve para poder consultar/gestionar el estado del cluster
 # ¡¡No debe dejarse abierto al público!!
 #<Location /balancer-manager>
 # SetHandler balancer-manager
 # Order Deny,Allow
 # Deny from all
 # Allow from W.X.Y.Z   #Host del administrator
 # #... otras medidas de proteccion
 #</Location>
 #...
 # Para enviar un contexto al cluster de Tomcats, podemos hacerlo así
 ProxyPass ^/my1app/ balancer://app_ajp_cluster/myapp/ [P,QSA,L]
 # o si queremos afinar más...
 RewriteRule ^/my2app/ balancer://app_ajp_cluster%{REQUEST_URI} [P,QSA,L]
 # Podemos hacer virguerías como deshabilitar acceso a aplicaciones si no es por SSL
 RewriteCond %{SERVER_PORT} =443
 RewriteRule ^/mysslapp/ balancer://app_ajp_cluster%{REQUEST_URI} [P,QSA,L]
 # Y otras magias que permite RewriteCond

* Conviene asegurarse que en el Apache que estemos utilizando están cargados los modulos proxy_module, proxy_ajp_module, proxy_balancer_module, proxy_http_module, rewrite_module, headers_module y status_module.

** NO hay que olvidarse de proteger el balancer-manager si lo abrimos. YOU HAVE BEEN WARNED!!!

Ahora necesitamos definir en la configuración del Tomcat los nombres de las rutas, para lo cual modificaremos el fichero server.xml (o equivalente) y en el nodo  Engine añadiremos el atributo jvmRoute con el valor adecuado en cada nodo. Así pues, en el host app_host1.com el nodo quedará como:

    <Engine
      name="..."
      defaultHost="localhost"
      jvmRoute="Tomcat-All.1"
    >

en el host app_host2.com el nodo quedará como:

    <Engine
      name="..."
      defaultHost="localhost"
      jvmRoute="Tomcat-All.2"
    >

Una vez hecho esto, tenemos un cluster con "sticky sessions", lo cual nos permite tener aplicaciones con sesión y donde todas las peticiones de la misma sesión van al mismo Tomcat. Sin embargo, ¿Qué ocurre si uno de los Tomcat se cae? Pues que las sesiones se perderán y aunque los usuarios podrán seguir accediendo de forma transparente, perderán lo que estaban haciendo. En ciertos casos, como aplicaciones públicas sin identificación, eso no nos importará y el servicio se mantendrá sin incidencias, pero en los casos donde, como mínimo, se guarda el usuario identificado como atributo de la sesión como prueba de login, el servicio se interrumpirá y "echará" a todos los usuarios obligándoles a identificarse de nuevo, perdiendo lo que tuvieran en la sesión.

Como ese resultado no es muy agradable para los usuarios, ¿cómo añadimos "session failover" a nuestra configuración para que eso no pase? Pues existen multitud de opciones (Terracota, Hazelcast...) para hacerlo, pero la más sencilla y barata (aunque no tan fiable) es usar el clustering que viene con el Tomcat.

Para usarlo, dentro del nodo Engine de la configuración del Tomcat (server.xml o equivalente) añadiremos el elemento Cluster, configurado adecuadamente. Antes de mostrar la configuración en sí, analicemos los datos que vamos a necesitar definir:

• Necesitamos una dirección y un puerto de multicast, para que los nodos se encuentren (en el ejemplo definidas como ${tomcat.mcast.addr} y ${tomcat.mcast.port}). Deben ser los mismos valores para todos los nodos del cluster.
• Necesitamos el nombre público del host particular para que los otros miembros del cluster se puedan comunicar (en el ejemplo ${tomcat.host}). Esto que parece una obviedad no lo es si añadimos DNS internos, firewalls, etc. Hay que definirlo por que si no, lo más normal es que la JVM asuma por defecto que nuestro host se llama... "localhost" y cuando otro miembro del cluster quiera comunicarse con "localhost"... podeis suponer lo que pasa. Así que hay que asegurarse que ese nombre es correcto y se le pasa correctamente al Tomcat, ya que es la fuente #1 de problemas de configuración del cluster. Avisados quedais.
• * Hace falta además un puerto para las comunicaciones entre Tomcats, en el ejemplo definido como ${tomcat.nio.port}.
• Si estos últimos campos son iguales o diferentes para todos los nodos, depende de si los nodos están en la misma máquina o no.
• En el ejemplo los valores esán definidos como ${xxx} por que el script de arranque ha sido modificado para pasar los valores adecuados en cada nodo del cluster, pero el Tomcat por defecto no rellena estos valores, así que modifica los valores, o el script, o no te te funcionará.

Con todos estos datos, así es como queda el trozo de configuración:

<Engine
 ...
    >
      <Cluster
        className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
      >
        <Manager
          className="org.apache.catalina.ha.session.DeltaManager" />
        <Channel
          className="org.apache.catalina.tribes.group.GroupChannel"
        >
          <Membership
            className="org.apache.catalina.tribes.membership.McastService"
            address="${tomcat.mcast.addr}"
            port="${tomcat.mcast.port}" />
          <Sender
            className="org.apache.catalina.tribes.transport.ReplicationTransmitter"
          >
            <Transport
              className="org.apache.catalina.tribes.transport.nio.PooledParallelSender" />
          </Sender>
          <Receiver
            className="org.apache.catalina.tribes.transport.nio.NioReceiver"
            address="${tomcat.host}"
            port="${tomcat.nio.port}" />
          <Interceptor
            className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector" />
          <Interceptor
            className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor" />
          <Interceptor
            className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor" />
        </Channel>
        <ClusterListener
          className="org.apache.catalina.ha.session.ClusterSessionListener" />
      </Cluster>
      <Host
   ...
    </Engine>

* Nota: Esta es la configuración mínima que he conseguido que me funcione. Algunos atributos tienen los valores por defecto, según la documentación, y algunos nodos deberían estar incluidos por defecto, de nuevo según la documentación, pero o la documentación miente o el Tomcat se pasa por el forro de la boina los valores por defecto en algunos casos, escoge la que más te guste. De todas formas, esta no es la única configuración posible y lo único que puedo decir de ella es que se ajusta a los que nos interesa y nos funciona ;).

En caso de querer hacer pruebas para ver si funciona en una sola maquina, lo que habría que hacer es usar dos Tomcat cambiando los puertos y ajustando la configuración adecuadamente.

Se podrían contar más cosas, como el script que arranca los Tomcat pasando los valores adecuados, usar un solo binario para multiples Tomcats detrás de un único Apache... pero como dice un gurú... eso es otra historia.

Happy coding!

EJ.

Disclaimer: Este no es un tema sencillo y no es recomendable para los no-iniciados, así que tratarlo con prudencia ;).

Lucene: sin regla ni Compass

Saludos después de una larga pausa donde, básicamente, me he dedicado a la familia y al ocio, para que negarlo. La verdad es que no estaba seguro de si volvería a escribir o no en el blog, ya que mi visión de eso llamado comunidad se va degradando con el tiempo, pero los ánimos me han dado para algunas entradas más, y aquí estamos de nuevo.

Esta entrada debería haber sido algo diferente, ya que mi intención era principalmente comentar la librería Compass, que es una especie de envoltorio de Lucene para facilitar su uso cuando tratamos con objetos Java, pero después de usarla en unos cuantos proyectos y estar relativamente satisfecho con su uso, un ligero problemilla me hizo consultar sus listas de distribución donde buceando entre el spam me encontré con la sorpresa de que su autor declaraba oficialmente que pasaba a hacer otra cosa y que ya no le interesaba trabajar en la librería. Al ser un one-man project, la cosa queda en que Compass es, en estos momentos, “abandonware”, por lo que hacer entradas explicando su uso, ventajas… me parece hacerle un flaco favor al pobre programador que debido a ellas acabe usándola y encontrándose la misma desagradable sorpresa que yo.

Sin embargo, aparte de advertir del estado del Compass, he decido modificar el contenido de la entrada y limitarme a hablar de los conceptos que he aprendido últimamente del Lucene y que son aplicables fuera de Compass.

Así que si alguna vez te toca trabajar con Lucene, espero que estos consejillos te sirvan:

• Lo más normal, si estas realizando búsquedas en castellano o algún lenguaje con caracteres "raros" para los anglos, es que quieras usar un analizador personalizado (custom analyzer) que utilice, al menos, los filtros ISOLatin1AccentFilter, LowerCaseFilter y StandardFilter. De esta forma tus documentos (así es como llama Lucene a lo que sea que indexes) se indexarán sin tener en cuenta mayúsculas, ni acentos u otros caracteres no-ascii.
• Eso sí, una vez indexados los documentos de esa forma, ojo con una característica del Lucene muy desagradable: Las búsquedas se deben pasar, habitualmente, por el mismo analizador que al indexar, pero el Lucene ignora al analizador sin decir nada si en las búsquedas se usan comodines (‘*’ o ‘?’). Así que si realizamos una búsqueda sin comodines, los resultados no serán independientes de las mayúsculas o los acentos y nos llevaremos desagradables sorpresas. La excusa oficial, con su pequeña parte lógica, es que el analizador puede cambiar los términos de búsqueda, por ejemplo para buscar  en singular y plural indistintamente, y entonces al hacer esos cambios junto a comodines, el termino final de búsqueda podría no parecerse a lo que quería el usuario. Bueno, vale. ¡Pero déjame elegir! En nuestro caso no puede ocurrir nada de eso, simplemente cambiamos letras mayúsculas por minúsculas y cambiamos á por a … pero Lucene considera que dejar escoger al programador, pobre tonto, es un peligro y no da la opción de desactivar esa “ayudita”. Sin comentarios. La única solución que he encontrado es pasar por esos mismo filtros los términos de búsqueda “manualmente” y antes de pasárselos al Lucene, lo cual me parece una chapuza. Pero avisados quedáis.
• Otro truco útil es para cuando la gente quiere hacer una búsqueda de palabras que “acaben en”, o sea *algo . Lucene está pensado para búsquedas que “empiecen por”, o sea algo*, y en cambio empezar por un comodín es muy ineficiente. ¿Como solventarlo? Muy sencillo, a la hora de indexar, indexamos ese campo al revés y a la hora de buscar le damos la vuelta al termino de búsqueda, o sea ogla*. Por el módico precio de tener indexado el campo dos veces, volvemos a tener búsquedas eficientes: voilà.
• Este último caso es un claro ejemplo de una técnica general muy útil cuando trabajamos con búsquedas indexadas, lo que hacemos con Lucene, vaya: En caso de tener problemas al montar el criterio de búsqueda, se puede probar a modificar la forma en que se indexa el contenido para facilitar las cosas. Por ejemplo, tenemos una lista de productos que pueden venderse en distintas tiendas y de esas tiendas hay sucursales en distintas provincias. Si a la hora de indexar, usamos un campo para indexar la lista de tiendas en las que se vende un producto y en otro campo la lista de provincias donde se vende… ¿Cómo podemos saber en qué provincias se vende el producto X en una tienda determinada? La respuesta es que así indexado no lo podemos saber, ya que hemos perdido la relación tienda-provincia. En este caso lo que tenemos que hacer es crear un nuevo campo donde indexemos el par tienda-provincia, que es por el que buscaremos para este tipo de consultas.
• De igual forma, podemos indexar en varios campos los apellidos junto con el nombre o los apellidos por separado, según como queramos poder buscarlos. A no ser que tengamos un índice de modificaciones muy alto, o un volumen de datos inmenso, no hay que tener miedo en invertir en la indexación a cambio de obtener un rendimiento mucho más alto en la parte presumiblemente más usada: las búsquedas.

Happy coding! EJ

Generando números de versión automáticamente con Maven

En esta entrada de hoy mostraré como implementar un sistema para que los usuarios de nuestras librerías puedan averiguar fácilmente cual es la versión que están utilizando y que se mantenga automáticamente al generar nuestros .jar con Maven.

Introducción
Uno de los “problemas/features” cuando uno usa Maven/Ivy/Grape o sistemas similares para gestionar sus dependencias es que independientemente de la versión, las librerías acaban teniendo un nombre común. Es decir, que la librería org.hibernate:hibernate:3.2.6.ga acaba llamandose hibernate.jar, igual que si fuera la 3.3.0.SP1 o cualquier otra versión. Esta característica ayuda a la hora de reemplazar una versión con otra, pero dificulta averiguar de un vistazo que versiones de librería estamos utilizando.

En caso de que nosotros hagamos una librería y se use a través de uno de estos sistemas, nuestros usuarios tendrán el mismo problema para averiguar en el sistema final qué versión está desplegada. Como somos unos “grandes” programadores, queremos facilitar a nuestros usuarios el averiguar está información, pero como somos unos programadores vagos eficientes no queremos tener que hacerlo a mano cada vez que generamos un .jar, y menos si usamos algo como Maven para gestionar nuestro proyecto. Así pues, ¿como lo podemos hacer?

Implementación
Paso 1:
Lo primero que tenemos que hacer es almacenar el número de versión de forma automática en algún sitio. Un buen sitio para hacerlo es en el fichero Manifest de nuestro .jar, y para hacerlo de forma automática podemos utilizar el plugin de Maven org.codehaus.mojo.buildnumber-maven-plugin. La documentación que tiene no es demasiado extensa, pero investigando un poco podemos averiguar cómo usarlo. En mi caso, dado que utilizo Mercurial como sistema de versiones y el numero de versión que utiliza no es muy significativo (no es un número correlativo) así que lo he sustituido por una marca de tiempo que me da una indicación más fiable. Si usas algo como Subversion, entonces quizá la configuración estándar del plugin ya te sirva Dado que el plugin no se encuentra en el repositorio central de Maven, tenemos que añadir un repositorio de plugins para encontrarlo, de la siguiente forma:

    
        codehaus-snapshot
        Cohehaus snapshot repository
        https://nexus.codehaus.org/content/groups/snapshots-group
        
          true
        
    

Una vez hecho esto, configuramos el plugin para que nos defina unas variables con la información que queremos, así:

    
      org.codehaus.mojo
      buildnumber-maven-plugin
      1.0-beta-5-SNAPSHOT
      
        
          validate        
          
            create
          
        
      
      
        true
        true
        {0,date,dd/MM/yyyy HH:mm:ss}
        
          timestamp
        
      
    

Con esto le decimos que nos añada el timestamp a la variable buildNumber, que es donde el plugin pone su información.
Por último, configuramos el plugin org.apache.maven.plugins.maven-jar-plugin para que use esa información para añadir una nueva entrada en el Manifest de nuestro jar. De la siguiente forma:

 org.apache.maven.plugins
 maven-jar-plugin
 2.3.1      
 
  
   false
   
    ${version}-${buildNumber}
    my.package.MainApp
   
  
 

Una vez hecho esto, si ejecutamos mvn package, por ejemplo, para generar nuestro fichero ,jar y miramos el fichero MANIFEST.MF dentro del directorio META-INF, deberíamos ver algo tal que así:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: usuario
Build-Jdk: 1.6.0_21
Main-Class:  my.package.MainApp
MyLibrary-version: 0.1-SNAPSHOT-25/06/2011 13:33:01

Paso 2:
Bien, ya tenemos almacenada la versión en el .jar. ¿Ahora que hacemos para facilitar que el usuario pueda ver esa información sin tener que abrir el .jar y mirar el manifest? Muy sencillo: la clase my.package.MainApp que es la principal de nuestra aplicación tiene que mostrar esa versión. En mi caso, la librería es una utilidad que no se lanza en linea de comandos, se usa añadiéndola al classpath, así que mi clase MainApp simplemente muestra la versión de la librería.

¿Y como hacemos para leer el manifest del mismo fichero del cual nos estamos ejecutando? Pues averiguando donde se encuentra el .jar en tiempo de ejecución y accediendo a él para leer el fichero manifest. Podemos hacerlo así (código simplificado sin gestión de errores):

String jarFileURL = 
  MainApp.class.getProtectionDomain().getCodeSource().getLocation().toString();
int pos = jarFileURL.indexOf("!");
if(pos!=-1)
{
  jarFileURL = jarFileURL.substring(0,pos);
}
if(!jarFileURL.startsWith("jar:"))
{
  jarFileURL = "jar:" + jarFileURL;
}
URL manifestUrl = new URL(jarFileURL + "!/META-INF/MANIFEST.MF");
Manifest manifest = new Manifest(manifestUrl.openStream());      
return manifest.getMainAttributes().getValue(“MyLibrary-version”);

Y así podemos hacer que al ejecutar java -jar milibreria.jar nos devuelva la versión de la librería, o si lo ponemos en un método público, podemos usar este número para mostrarlo en las aplicaciones que usen la librería y así puedan saber que versión están utilizando, comprobar si existen nuevas versiones etc.

Espero que os sirva, al menos a mi me ha servido, y que vuestros usuarios estén más contentos :).

Happy coding! EJ

¿En qué se parece un informático a un limón?

En vez de hacer un chiste fácil, y seguramente malísimo, con la frase, voy a tratar de aportar mi grano de arena a la eterna discusión de "¿Por qué el mercado de informáticos está tan mal/desprestigiado y generalmente se cobra tan mal en relación a la valía?"

Para explicarme debo mencionar la teoría económica de un economista de 1970, George Akerlof, expuesta en un artículo bajo el título "The Market for Lemons: Quality Uncertainty and the Market Mechanism". En realidad en este caso "lemon" no se traduciría por limón, de ahí el chiste malo, si no por su acepción menos conocida de "cacharro" o "cosa decepcionante".
Por simplificar, la teoría viene a decir que cuando en un mercado de un artículo, el comprador no tiene información fiable a priori para saber si lo que compra es bueno o es malo, y el vendedor sí, al final en ese mercado se acaban vendiendo solamente los "cacharros", es decir, los artículos de peor calidad y a precios bajos.
Una explicación basada en un ejemplo la podéis encontrar en esta entrada del blog Fermat Margin.

Y eso es en parte lo que nos ocurre en el mercado de los informáticos, especialmente cuando tienen menos experiencia, ya que muchas veces quien contrata no sabe de que va el tema y no tienen experiencia previa, así que no pueden evaluar de forma fiable la valía de los candidatos.  Y la cosa va tal que así

• El comprador (el que contrata) no tiene forma medianamente fiable de saber como le va a salir el artículo (el posible empleado). Para no pasarse, obviamente tira por un sueldo medianero.
• Los buenos programadores que merecerían más sueldo, rechazan trabajar por ese sueldo y buscan otras cosas.
• Por tanto entre los que aceptan esos trabajos, sólo quedan los que merecen ese sueldo y los que no.
• Por tanto el comprador cuando mira lo que obtiene por lo que paga, se da cuenta de que la media le sale por debajo, así que la próxima vez ofrece sueldos más bajos.
• Y así recursivamente, hasta que los sueldos son una mierda y en ese mercado sólo trabajan los malos empleados que no podrían aspirar a nada más. Por lo tanto los empleadores ven confirmada su idea de que realmente no ha de pagar más por que todos los que contrata son malísimos, y los buenos empleados no tienen ningún incentivo por hacerlo bien, puesto que les van a pagar como si fueran malos, así que al final se convierten en malos.

Y ahí tenemos un bonito circulo vicioso :). No lo explica todo, y por supuesto los buenos empleados pueden encontrar buenos empleos, si salen de ese mercado, y los empleadores pueden encontrar personal adecuado si no entran en este juego. Pero es una pieza más del puzzle, aparte de la avaricia, la cultura del pelotazo y todos esos tópicos que ya se mencionan suficiente. Simplemente me apetecía añadir este enfoque diferente y curioso que explica algunos de los comportamientos humanos que llevan a situaciones desastrosas.

Ni soy economista ni gurú, así que no tengo ni creo tener receta mágica para solucionar este tipo de problemas, pero si crees ser un buen empleado, no te conviertas en un limón y si eres un empleador, no vayas al mercado a por limones. Hay que recordar que la clave de este problema concreto es la información, o falta de ella, de una de las partes. Decir que con más información se soluciona es fácil, aplicarlo en la vida real es lo complicado ;).

Happy coding! EJ

Estándar de nomenclatura en BDD

Hoy una entrada sobre el sistema personal de nomenclatura de BDD que me gusta utilizar en mis aplicaciones cuando tengo la capacidad de decidir. No siempre es así, a veces se trabaja con BDD heredadas o uno no es el responsable de esa área, pero cuando es posible, personalmente prefiero utilizar este sistema que me proporciona la sensación de tener más "ordenada" la BDD.

La idea, al fin y al cabo, es tener un sistema que sea fácil de seguir y que permita identificar fácilmente los elementos que se estan utiizando en consultas, los que se referencia en mensajes de error, en relaciones entre elementos etc.

Resaltar especialmente que este es el sistema que YO utilizo, pero hay muchos otros cada uno con sus pros y sus contras y no es mi intención decir que es el mejor ni nada remotamente parecido. En este caso, se cumple el dicho de que para gustos, colores y la organización o el DBA son los responsables de escoger entre la cantidad de opciones disponibles.

.- El primer punto es sencillo, escoger tres letras como alias de "la aplicación" o módulo a desarrollar. Por ejemplo, si vamos a trabajar la parte de almacén y no se ha usado ya ese "álias", podríamos escoger ALM como álias de aplicación.
.- Una vez escogido el primer punto, las tablas empezarían con T + dicho álias, las vistas con V + álias, las restricciones de integridad con K + álias, los índices con I + álias... etc. Así pues, la tabla para representar los productos en la aplicación sería TALM_PRODUCTO, la de clientes TALM_CLIENTE y así sucesivamente. Los nombres siempre en singular y sin abreviar a no ser que la longitud sea muy muy larga. Hoy en día restringir los nombres a 8 caracteres o menos como se hacía antes tiene muy poco sentido.
.- Dentro de las tablas, yo prefiero utilizar siempre un identificador único e inventado sin significado de negocio, siempre con el mismo nombre y el mismo tipo. Además, cada tabla tiene su propio álias y se añade delante de todos los nombres de los campos. Por ejemplo, la tabla TALM_CLIENTE, con alias CLI, tendria los campos CLI_ID, CLI_NOMBRE, CLI_NIF..., la de productos tendria PRD_ID, PRD_NOMBRE, PRD_CODIGO... Darse cuenta de que PROD_ID sería un identificador inventado y que el número que viene en el producto sería por ejemplo PRD_CODIGO. Existen múltiples discusiones a favor y en contra de usar o no identificadores inventados y no voy a intentar convencer a nadie. Sólo decir que tener que detener la operación del sistema periódicamente para poder anular las restricciones de integridad para solucionar los problemas de errores en los identificadores no inventados da una perspectiva diferente :). No voy a decir que no tenga inconvenientes o que el sistema esté mal hecho si no se sigue. Sólo puedo decir que cuando puedo elegir, YO lo hago así. Siguiendo con lo ya mencionado, la restriccion de clave primaría tiene el alias de la aplicacion y de la tabla seguido del sufijo _PK, para indicar que es "primary key". Por ejemplo, para la tabla TALM_CLIENTE sería KALM_CLI_PK, para TALM_PRODUCTO sería KALM_PRD_PK etc.
.- Las claves extranjeras simplemente referencian el campo en la tabla "remota" añadiendo el prefijo correspondiente y sólo en caso de existir más de una clave extranjera contra la misma tabla se añade un sufijo para diferenciarlas. Por ejemplo, en la tabla TALM_STOCK, tendríamos una clave extranjera a TALM_PRODUCTO bajo el nombre STK_PRD_ID, en TALM_FACTURA tendríamos FAC_CLI_ID para referenciar el cliente... etc. Como se puede ver esto facilita enormente la identificación de los elementos de cada relacion, incluso permite automatizar algunas tareas. Por otro lado, las restricciones de integridad de las claves extranjeras indican en este caso ambas tablas y el sufijo _FK, de "foreign ey". Las restricciones para los ejemplos mencionados serían KALM_STK_PRD_FK y KALM_FAC_CLI_FK. De este modo, al violar una de estas claves, el mensaje de error ya nos indicará claramente cuales con las tablas implicadas.
.- Las restricciones sobre campos indican el nombre del campo y el tipo de restriccion, por ejemplo PRD_CODIGO sería un campo seguramente único y como tal tendría la restriccion KALM_PRD_CODIGO_UK (de "unique key"), las restricciones de integridad serían igual pero con _CHK al final etc.

Ese es básicamente el estilo de nomenclatura que sigo y con el que me siento comodo, aunque no soy muy talibán al respecto.

A la hora de trasladar el modelo de datos a clases Java los prefijos desaparecen y uso un estilo de nomenclatura más "javero" y así de esta forma cada mundo es coherente y sigue sus propias reglas. Eso implica que siempre tengo que especificar los nombres de los elementos que corresponden en cada caso, pero es una "molestia" que tengo automatizada y no me importa pagar ese precio. La razoón para no tener que usar tanto sufijo en Java es que con la estructuración en paquetes y el estilo de los errores ya da suficiente información como para poder situarte rápidamente sin necesitar esas ayudas.

No intento convencer a nadie de que use nada pero por si a alguien le da alguna idea y/o le sirve, ahí queda dicho. Y una vez dicho esto...¿Usais vosotros, estimados lectores, algún tipo de estilo/estándar de nomenclatura?

Happy coding! EJ

PD: Ah, feliz año nuevo ;). A ver si este 2011 nos trata un poco mejor a "la plebe" y un poco peor a los chupasangres del mundo.

Paths relativos, especificaciones, Java y un bug en "Internetes"

Hoy en el trabajo me he encontrado con “un bug en Java e Internetes”. Bueno, más que un bug es un comportamiento extraño por especificaciones obsoletas, implementaciones independientes de contexto etc. etc. Pero es algo que te puedes encontrar en la vida real, así que he pensado que sería interesante contarlo.

El problema se da al leer un documento HTML con Java y tener que interpretar las direcciones relativas que contiene dicho documento. Si una de las direcciones únicamente contiene un “query string”... ¿Cómo la interpretarías vosotros?

Es decir, si en la página www.host.com/dir/loquesea.do encontramos un enlace tal que así href=”?param=value”... ¿Dónde ha de ir la página?

La respuesta correcta es “depende” :).

• Si estamos hablando de HTML 4.1, la respuesta es www.host.com/dir/loquesea.do?param=value y si hacéis una prueba con el navegador, lo debería resolver así.
• En cambio... ¿qué ocurre si procesáis ese documento con Java y usáis java.net.Uri.resolve(relativePath) para obtener la nueva URL? El resultado es www.host.com/dir/?param=value

¿Y cual de las dos respuestas es incorrecta? En realidad “ninguna”. La clase java.net.Uri implementa correctamente la resolución de caminos relativos según la RFC2396, de agosto de 1998, y por ello elimina el “loquesea.do” antes de añadir el camino relativo. En cambio HTML 4.1 está basado en la especificación RFC1808, de junio de 1995, la cual dice que si hay “query string” se mantiene la dirección completa como base. Lo curioso es que HTML 4.1 es de diciembre de 1999, más de un año después de que la RFC1808 fuera “sobre-escrita” por la RFC2396 pero sin embargo, parece al escribir la especificación de HTML no se fijaron en que la RFC1808 ya no estaba en vigor. De todas formas, el comportamiento de los navegadores es correcto ya que HTML 4.1 se basa en la RFC1808 y ésta es la que hay que seguir. Y la clase java.net.Uri tampoco hace nada “incorrecto” ya que en realidad sigue una especificación más reciente. En realidad podría hacerlo “mejor” si permitiera especificar si el método resolve() ha de funcionar según HTML 4.1 o el futuro HTML 5, y puestos a tener un comportamiento por defecto... HTML 4.1 es muy común.... en fin, que la cosa es bastante ambigua así que la mejor solución es no escribir nunca enlaces de esa forma y escribirlos al menos un poco más explícitos, o si hay que tratar en Java las páginas HTML que escribe un tercero... si esas páginas son HTML 4.1 hay que tener en cuenta que java.net.Uri no resuelve las direcciones relativas como lo hacen los navegadores, así que hay que tratar la dirección antes de pasársela para obtener el resultado esperado.

Y ahí queda escrito ese aviso para navegantes, por si a alguien le ahorra un buen rato de investigación leyendo especificaciones y el código del OpenJDK como he tenido que hacer yo.

Happy coding! EJ

Dime tu lista de prioridades y te diré lo profesional que me pareces

Un tema interesante y que da para muchas discusiones es “¿qué convierte/define a un buen informático?” Sin ánimo de sentar cátedra ni de que los demás piensen igual, voy a dar mi opinión personal e intrasferible de lo que define a un profesional del desarrollo de software (no a cualquier tipo de informático) pero siendo un pelín original. En vez de decir la típica lista de atributos, simplemente me fijaré en un aspecto que es: El orden de prioridades a la hora de afrontar un trabajo.

Así que sin más dilaciones, la pregunta crítica: “¿A que le das más importancia a la hora de desarrollar un software?

• A aplicar los patrones X, Y y Z. Si esa es tu prioridad más alta o está entre las más altas, lo siento pero entras dentro de la categoría empezar-la-casa-por-el-tejado. Los patrones son soluciones comunes y conocidas para ciertos tipos de problemas, y si tu interés se centra en usarlos sin saber si son aplicables a tu problema, ciertamente tienes el orden de las prioridades un poco confundidas. El desarrollo no es un concurso para aplicar el mayor número de patrones posibles, ni aplicar patrones significa garantía de nada (de ahí el invento de los anti-patrones) así que la hora de pensar en aplicar patrones está bastante más abajo, una vez sepamos a qué problemas no estamos enfrentando y en caso de reconocer algún problema habitual que se solucionar con un patrón, nada mejor que aplicarlo. Pero no antes.
• A aplicar las más modernas y “más mejores” técnicas de desarrollo. Si este objetivo lo tienes muy alto significa que te dejas llevar por las modas y que eres una “fashion-victim”, de las que se tragan eso de que todo lo nuevo es mejor y que lo viejo huele a rancio. Como pez en el agua en el mercado consumista, pero en versión tecnológica. Si es solo producto de la juventud y no de la falta de neuronas, no te preocupes que se cura con la experiencia :). Cuando veas a la misma gente contando cada X tiempo mentiras nuevas, por que con las viejas no se hace negocio, aprenderás a ver detrás del humo y distinguir lo aprovechable de las novedades y lo que hay que conservar de lo que ya existe, siempre en función del tipo de trabajo que tengas.
• A que el diseño sea orientado a objetos (sustituible por cualquier concepto purista). Este tipo de objetivos están muy bien para el mundo teórico, pero tienen ese ligero problemilla de que a la tozuda realidad a veces no le gusta jugar con reglas perfectas. Seguro que eres de los que creen que la tierra es perfectamente redonda y el mar es azul, al fin y al cabo los pintan así en todos los libros ¿verdad? Pues no, la perfección teórica está muy bien pero sirve a un fin, no es la finalidad en sí misma. Es decir, que el diseño sea lo más orientado a objetos posible persigue un fin, que es obtener los beneficios de la OO etc. pero si no vamos a conseguir esos beneficios, por diversas razones, entonces ya no tiene utilidad.
• A usar el lenguaje/framework X.Seamos sinceros, la mayoría de los proyectos sabemos en que lenguaje/arquitectura los vamos a realizar por que es en el que realizamos casi todos, si no todos, nuestros proyectos y no vamos a re-evaluar nuestra cartera de soluciones en cada proyecto (en la mayoría de casos, en algunas empresas lo hacen pero por necesidad). Aun así, a la hora de cambiar de lenguaje/arquitectura en un proyecto hay que recordar qué es lo realmente importante, y no, no es usar una solución específica a no ser que el proyecto tenga ese objetivo concreto.
• A cumplir lo que se me mande hacer, que para eso me pagan. Esta actitud conformista y muy habitual no es que sea terriblemente mala, pero no le convierte a uno en un gran profesional. Especialmente en nuestro campo donde muchos mandos intermedios no saben lo que significan la mitad de las siglas que usan y se limitan a distribuir la mierda que cae desde arriba entre los de abajo. Repito, es algo comprensible pero por hacer un examen justito a uno no le ponen un 10.
• A disfrutar trabajando. Sí, numerosos estudios demuestran que la gente trabaja mejor cuando está más contenta y en trabajos creativos como el nuestro es muy importante la mentalidad y la actitud, pero hombre, “un hombre ha de hacer lo que tiene que hacer” y la vida no es una fiesta constante. Si toca hacer un mantenimiento, se hace, aunque hayamos hecho mil. Es importante que el trabajo sea gratificante, pero tambien hay que tratar de disfrutar con nuestro trabajo. Como dicen los sabios “no es más feliz quien más tiene, si no quien menos desea”. O dicho de otro modo: “Señor, dame fuerza para aceptar las cosas que no puedo cambiar, valor para cambiar las cosas que puedo y sabiduría para poder diferenciar entre unas y otras.”
• A hacer lo que el cliente pide. Esta es otra actitud comprensible, decente... pero estamos hablando de informática, no de una tienda de ropa, y aquí el cliente no tiene siempre la razón, simplemente por que el experto en manejo de la información se supone que eres tú, y no él. Hacer lo que el cliente dice sirve para cubrir el expediente y salvaguardar el culo, pero no se lleva el máximo galardón en mi lista.
• A solucionar “El Problema”. Obviamente, como último en la lista, esta es la que yo considero que es la más profesional de las prioridades. Hay que entender cual es “El Problema” que queremos solucionar, ayudados por el cliente, usando el lenguaje y framework adecuados, que normalmente será los que conocemos ya que que los conozca el equipo de desarrollo da muchos puntos, utilizado las técnicas y patrones adecuados y si encima podemos disfrutar haciéndolo, mejor que mejor. Con esto lo que quiero decir es que la prioridad es dar respuesta al problema. Los programas, de momento, no son obras de arte para ser admiradas sin más, tienen una finalidad y cumplirla debería ser la máxima prioridad, la cual muchas veces se combina con el resto ya que ayudan a cumplirla, pero siempre hay que tener el orden claro.

Y esa es mi lista. Como se puede ver soy del modelo pragmático, pero es lo que hay. La lista no será del agrado de todos pero lo que está claro es que es la mía y sobre eso no hay discusión. ¿Y la tuya?

Happy coding!
EJ

Arquitectura ligera y uso de cachés

Después de explicar un poco la arquitectura ligera que estoy empleando en un proyecto y dado que estoy usando una caché, tema sobre el cual ya desvarié un poco, he pensado que también podría ser interesante explicar cómo estoy usando la caché en este proyecto, basándome en las reflexiones del mensaje sobre uso de cachés.

Como ya expliqué, el proyecto consiste en mostrar los resultados de las partidas de un juego online, quien participó, cómo lo hizo cada piloto y estadísticas recopilatorias sobre el historial de cada piloto. Respondamos entonces a las preguntas clave:

¿Merecía la pena introducir una caché? La respuesta en este caso es que claramente sí, dado que vamos a mostrar resultados acumulados de varias tablas, especialmente en el caso de las estadísticas históricas. Incluso la “simple” lista de partidas jugadas es una consulta que cruza 4 tablas ( no por que esté mal el esquema de BDD si no por que ya muestra datos acumulados) y las primeras pruebas ya indican un incremento en el rendimiento de x30 en las consultas más simples.

¿En que capa he introducido la caché? Dejar que la BDD se encargue de ello implicaría que todavía tendríamos que viajar por la red hasta la BDD. La cache de MyBatis no es algo con lo que he experimentado y no se que control me da (creo que no suficiente por lo que he leído en las listas de distribución), así que seguimos subiendo. El control de caché del framework ligero lo conozco bien y se que control me da: más que suficiente. Podría intentar subir aun más y usar la caché a nivel de filtro de servlets en la salida final (HTML o JSON), pero dado que más tarde introduciremos personalizaciones para que los usuarios vean sus propias páginas y eso implica que puede que la salida final de cada usuario sea ligeramente diferente, me quedo justo en el nivel de abajo. De todas formas, el salto gordo en el rendimiento se produce en este caso, como en muchos, en la consulta a la BDD y la creación de los objetos correspondientes en el servidor, así que haciendo caché de eso ya obtengo un gran beneficio.

¿Como vamos a mantener actualizada la caché? En la aplicación hay 3 tipos de páginas, clasificándolas en relación de dependencia con datos actualizables:

• 
  
  Grupo 1: Las que dependen de todas las partidas jugadas: Lista de partidas, estadísticas globales, clasificaciones de todos los jugadores, etc.
• 
  
  Grupo 2: Las que dependen de un piloto en particular: Estadísticas generales de cada piloto, detalles sobre los elementos utilizados por el piloto en sus partidas...
• 
  
  Grupo 3: Las que no dependen de nada: Datos de una partida y detalles de participación de cada piloto en esa partida.

Una vez sabemos esto, podemos ver que cada vez que haya una o más partidas nuevas, tenemos que invalidar todos los elementos de la caché del grupo 1 e invalidar los elementos del grupo 2 de los pilotos que hayan participado en las partidas nuevas. Los elementos del grupo 3 pueden estar en caché “indefinidamente”. Para llevar a cabo esta tarea lo que hemos hecho es implementar una tarea periódica con Quartz que a intervalos regulares comprueba si ha habido partidas nuevas y en caso afirmativo, procede a marcar como caducados los elementos de la caché según las reglas definidas.

¿Cual es el perfil de nuestra aplicación? Se presupone una aplicación donde habrá muchas más lecturas que actualizaciones, y donde las actualizaciones de datos no son críticas en absoluto. Por tanto el tipo de funcionamiento definido cuadra perfectamente.

Puntos extra: Para controlar mejor el uso que se hace de la caché y verificar que todo funciona correctamente, tenemos varias ayudas:

• 
  
  Por un lado, el framework que utilizamos de caché nos puede decir en cada momento el grado de utilización que le estamos dando (Hit/miss ratio) por lo que podemos saber si realmente se está leyendo mucho más de lo que se está actualizando la cache.
• 
  
  Por otro lado, podemos controlar la periodicidad de la tarea de control de la cache y si vemos que la el grado de utilización es bajo y la caché no se usa lo suficiente, podemos aumentar el período y así aumentar el grado de utilización, protegiendo a la vez la BDD de una carga excesiva.
• 
  
  Ambos elementos se pueden retocar en tiempo de ejecución sin necesidad de reiniciar la aplicación, lo cual nos permite una gestión muy cómoda sin miedo a molestar a los usuarios.

Espero que este ejemplo sirva para ilustrar lo que quería decir en el mensaje de reflexiones sobre el uso de cachés, y si os da algunas ideas para vuestras aplicaciones, mejor que mejor.

Happy coding! EJ

Ejemplo de arquitectura ligera

Una entrada corta sobre una arquitectura que estoy usando ahora mismo para una aplicación web de tamaño pequeño/mediano. La historia es que un grupo de "modders" estamos haciendo unas modificaciones a un juego multi-jugador online y una de las partes modificadas incluye recoger estadísticas de las partidas que se juegan: información del servidor y mapa que se jugó, qué equipo ganó, cuantas veces mataron y mató cada jugador, cuantos puntos... Y esta información la queremos publicar por web, que es la parte que me toca a mí (mi vena artística no da más que hacer cuatro palotes y mi C está demasiado oxidado como para meter mano al juego).

Así que aquí está lo que uso, por si a alguien le da alguna idea:

• Como framework-pegamento, uso uno "custom" que es simple y ligero, no necesito más, y por ahí no pienso recomendar nada: es mal negocio :).
• La interfaz la estoy haciendo principalmente con tablas y elementos de YUI, usando AJAX y JSON para paginar las tablas sin recargar toda la página.
• Para formatear el JSON y las páginas que hacen de contenedores de los elementos YUI, JSP me basta. Suelo usar otras tecnologías para esto, pero como otros miembros del equipo puede que me ayuden y JSP es lo más común y sencillo...
• Para hacer más "agradables" las URL y más intuitivas, fácil de recordar y de escribir, pero sin que me condicionen la implementación por debajo: Url Rewrite Filter.
• Para "decorar" las páginas y hacer que los estilos y menús sean comunes: SiteMesh.
• Para evitar machacar la BDD con consultas cuando los datos no han cambiado, se usa una cache implementada con OSCache.
• Para las tareas que comprobarán periódicamente cuando hay que marcar como caducados algunos elementos de la caché (al acabar una partida, por ejemplo, hay que "caducar" todas las estadísticas globales de los jugadores que participaron y la lista general de partidas jugadas) uso Quartz.
• Para consultar la BDD, como los datos que se muestran son principalmente recopilatorios, las consultas suelen implicar media docena de "joins" y la navegación por entidades mataría el rendimiento, uso MyBatis en lugar de JPA, que es lo que seguramente use para atacar la parte de autenticación, definición de equipos etc. que sigue otra estructura más orientada a objetos.
• Para no tener que escribir tropecientos getter y setter y dejar el código limpio, uso Lombok para que lo haga por mí sin siquiera tener que verlos en el código. Muy útil en este caso.
• La BDD es MySQL. No la escogí yo ni hice el esquema así que poco puedo decir excepto que funciona.
• Para crear, probar y depurar las consultas contra la BDD: Aqua Data Studio.
• Para no tener que reiniciar el contexto cada vez que hago un cambio en las clases Java: JRebel, aunque tiene algunos conflictos con Lombok. Por otro lado, el framework detecta los cambios en la configuración de MyBatis en ejecución y recarga los "Mapper", así que tengo que re-iniciar el contexto muy muy poco. Y para rizar el rizo, el tiempo de reinicio con este framework ligero y MyBatis no llega a los 4 segundos así que el famoso tiempo perdido esperando a que se (re)inicien las aplicaciones Java en este caso es irrisorio.
• Como IDE: Eclipse, aunque el proyecto se puede montar solito en base a Ant + Ivy e incluso ejecutarlo, ya que incluye contenedor de servlets embebido para pruebas. No tengo manías y casi cualquier IDE debería valer en este caso, pero uso el que me es más cómodo.
• Para depurar YUI: El Firefox con Firebug, como no, aunque a veces interfiere con otros plugin y últimamente me tiene algo mosqueado.
• Para comprobar que el JSON que envío es correcto cuando me da un problema y no se si es por la estructura de JSON o un fallo en JavaScript: JSONLint
• Como contenedor de servlets para pruebas: Jetty 6, Tomcat 5.5 y Resin 4, en sus formatos "embedido" respectivos y lanzados desde el Ant o a mano. El de producción, que tampoco escojo yo, será Tomcat 5.5, así que estoy cubierto.

De momento las pruebas iniciales son bastante satisfactorias y gracias al uso de paginación a través de AJAX y de cachés en el servidor, parece que aguantaremos la carga. Para este sistema en particular es más importante que la aplicación sea ligera y ágil, que usar grandes frameworks que nos den muchas cosas hechas que no vamos a usar o que nos permitan hacer virguerías que no haremos.

Cada aplicación tiene sus propias cosas e intentar aplicar siempre la misma receta es como intentar cocinar el pollo, el cordero y el cerdo de la misma forma. Algunas veces puede funcionar pero otras es un desastre incomestible. Así que como en las recetas de cocina, si alguien puede aprovechar partes y le sirven para sus circunstancias particulares, me alegro. Si no, pues mala suerte y a buscar sus propias soluciones :).

Bon Appétit & Happy coding!
EJ

Sobre Gurús y otros falsos mitos

Hoy un tema que seguramente levante algo de polvo, pero para eso estamos al fin y al cabo :).
Lo primero de todo: debo admitir que el "fenómeno gurú" es algo que no va conmigo y que personalmente me produce vergüenza ajena. Lo de elevar a los altares a una persona para considerarla un "gurú" se comprende en quinceañer@s con más hormonas que cerebro, pero que una persona adulta tenga tan poco consideración por si mismo como para sublimar sus opiniones a otra, por el mero hecho de la fama que tiene... en fin, que allá cada cual pero a mí que no me busquen para eso.

Volviendo al tema, una de anécdotas:
Eranse cuatro desarrolladores sentados a una mesa disfrutando de una cena y unas bebidas, dos de los cuales eran gurús de los gordos, de los que su nombre está semana sí, semana no en java.net, Dzone etc. Los otros dos éramos dos "soldados de trinchera", de los que el pan se lo ganan dándole a la tecla, coordinando nuestros proyectos, con nuestras ponencias en congresos de vez en cuando, nuestras colaboraciones en proyectos OS, pero fama: ni de lejos, ni ganas.
Una cena agradable en la que que apareció uno de los temas recurrentes: "para desarrollar me basta con el vi". Los dos gurús argumentando que los hombres de pelo en pecho de verdad sólo necesitan el vi, nosotros argumentando que saber hacerlo a pelo es imprescindible pero que los editores modernos con sus capacidades de refactoring, búsquedas de referencias etc. son una gran ayuda. Ellos que un buen desarrollador tiene todo el proyecto en su cabeza y que igualmente, hackeando el vi y con unas extensiones de no-se-donde hacía lo mismito, y total, ¿Quién necesita refactorizar si basta con escribir todo el código bien de un tirón y a la primera? Mi compañero de trinchera decía que en sus proyectos, donde a veces trabajan hasta seiscientos (sí, tantos) programadores en un sólo proyecto, pues tener formateadores estandarizados, el FindBug, y las capacidades de "refactoring", repositorios de versiones y dependencias integradas etc. sirven para que todo el mundo esté a un nivel parecido y no sólo sirvan los mega-cracks, aparte de hacer que los mega-cracks sean aun más eficientes.
Al final, como en todos estos temas que no tienen demostración matemática, "ni pa' ti, ni pa' mí" si no cada uno con su opinión. Se notó algo que estaban más acostumbrados a que la gente dijera "amén" a sus opiniones por ser quienes eran, pero tampoco tuvieron mucho problema al toparse con dos agnósticos de la fe gurú.
Ahí hubiera quedado la cosa, si no fuera por que al día siguiente en el congreso en el que estábamos le tocaba dar una charla a uno de los dos gurús, el cual ciertamente de su tema sabe un huevo y la yema del otro y mucho más que un servidor. En su charla le tocaba una demostración en vivo de ciertas técnicas y cómo el código podía afectarles, así que tenía su ejemplo preparado que consistía en unas clases Java muy simples para compilar y ejecutar.
La demo empieza bien, ejecuta el código, muestra los resultados que esperaba y todo perfecto.
Entonces toca modificar ligeramente la clase Java para comprobar una de las técnicas. Abre el vi, realiza unas modificaciones, borrando líneas enteras de texto con la x, repitiendo el mismo comando varias veces re-haciéndolo entero, y a la hora de salir guarda con :w y luego sale con :q. Para los que no uséis vi y no lo hayáis pillado, así es como trabaja alguien que sólo conoce los comandos básicos.
Pero bueno, guarda los cambios y compila con javac especificando todo a mano (¿Ant? Eso es para mariquitas). Resultado: No compila. En realidad hace falta modificar también otra clase donde se llama a la primera y como ha cambiado unos parámetros en un método... Eso lo puedo decir yo a 20m leyendo la linea que escupe javac, pero él parece no pillarlo (entiendo que los nervios en escena afectan). Al final alguien se lo chiva y abre el otro fichero, realiza otras modificaciones con la misma "habilidad" con el vi, guarda y sale. A compilar otra vez. Resultado: No compila. Esta vez es por que una de las letras llamando al procedimiento está mal, es mayúscula y ha de ser minúscula, y por eso no funciona. Etc. etc.

Resumiendo: Tuvo que saltarse la demo por que cuando no le fallaba la compilación con el javac, poniendo todos los parámetros a mano, tenía un error tonto en el código y tenía que arreglarlo, lo cual le costaba tiempo por que hasta interpretar los mensajes del javac le costaba en la tensión del momento. Y una cosa que quedó clara como el agua es que no se dedica a ganarse la vida picando código, cosa que yo ya sabía.
Conclusión: Cuando habla de su tema y está en su salsa, le escucho con los ojos abiertos. Cuando habla de otras cosas, como por ejemplo formas de picar código, valoro mucho más mi opinión o la del otro compinche de trincheras que la suya, con todo el respeto y sin desmerecer, que lo cortés no quita lo valiente.

Otra anécdota aun más cortita: Estaba yo en un congreso importante y gracias a un contacto que tengo, importante en el mundillo que no famoso, acabo cenando con un grupo donde hay "un famoso" que ha escrito un libro sobre un tema nuevo de Java, el cual todo el mundo recomienda como la Biblia del saber. Al llegar a la cena el famoso resulta ser un chico joven de veinti-pocos con cara de niño (nada en contra de la juventud, pero uno se imagina a un gurú con una larga barba blanca y profundas arrugas de meditar a la intemperie :) ). Hasta aquí nada reseñable excepto la sorpresa de descubrir una cara tan joven asociada a una tan famosa "fuente de conocimiento". Lo mejor viene durante la cena cuando movido por la curiosidad le preguntó cómo acabó escribiendo el libro ese que le hizo tan famoso. La respuesta es lo que me deja tieso: Acababa de aprender Java y nunca había trabajado con el tema del libro, así que cuando un contacto le propuso escribir un libro sobre el tema, pensó: "así aprenderé de que va esto". O sea, sin quitar méritos al libro que fue una gran guiá de iniciación para muchos, cuando el tío lo empezó a escribir no tenía ni la más remota idea del tema, y no demasiada de Java. Y ésta es la persona cuyas opiniones sobre el tema la gente pone por encima de las demás... en fin serafín.

Por mi parte, todos somos humanos y tenemos cosas de las que sabemos, cosas de las que no. Saber escribir un buen libro para iniciados no significa conocer un tema en profundidad, ser un experto en un tema concreto no nos convierte en expertos en todos los temas y dejarse llevar por la fama de la gente para poner sus opiniones de cualquier cosa por encima de otras, por el mero hecho de ser famosos, es una soplapollez que debería sonrojarnos.

Así que si te encuentras con un experto en un tema y te da su opinión sobre ese tema, escúchale, si te la da sobre cualquier otra cosa, recuerda que a igualdad de "conocimientos" la suya es tan válida como la de cualquiera.

Happy coding!
EJ

Uso avanzado de Enumeration

No parece que el tema de las cachés interese demasiado, así que mientras decido si continúo o no con el tema, otro consejo breve, en este caso sobre el uso de las enumeraciones en Java.
El uso básico que todo el mundo aprende rápidamente es el de simplemente hacer una lista de elementos para luego, por ejemplo, poderlos pasar como parámetros con verificación de tipos. Algunos desarrolladores, si embargo, se quedan ahí y piensan que su utilidad es limitada puesto que se puede sacar el valor con name(), se puede obtener el índice con ordinal() pero si necesitamos más, tenemos que complicar mucho la cosa... y total para pasar una cadena...
Nada más lejos de la realidad, puesto que extender una enumeración para que nos sea más útil es tremendamente sencillo.
Pongamos un caso parecido a uno con el que trabajé hace poco: Queremos mostrar una lista de empleados de forma ordenada, pudiendo pasar el criterio de ordenación como parámetro, o sea una cadena. Para ordenar una lista de elementos necesitamos un Comparator y no queremos ni que el parámetro a pasar sea un nombre muy largo ni que el nombre de la enumeración sea demasiado corto ni se aparte de las convenciones de código que usamos, así que... ¿como lo podemos hacer?
Muy sencillo:

• Añadimos dos campos a la enumeración: acrónimo y comparador y los inicializamos al crear cada elemento.
• Dado que querremos obtener el elemento correcto a partir del acrónimo, no del nombre completo, creamos una tabla de búsquedas inversa, indexada por acrónimos. La creamos estática e inicializada al cargar la clase y siempre la tendremos disponible y preparada, para no tener que buscar en un bucle.

Y el código es igualmente sencillo:

  static Comparator ComparadorPorNombre = new Comparator()
  {
   //...
  };
  static Comparator ComparadorPorSueldo = new Comparator()
  {
   //...
  };
  static Comparator ComparadorPorCargo = new Comparator()
  {
   //...
  };

  public enum Ordenacion
  {
    ORDENAR_POR_NOMBRE(ComparadorPorNombre, "nombre")
    ,ORDENAR_POR_SUELDO(ComparadorPorSueldo, "sueldo")
    ,ORDENAR_POR_CARGO(ComparadorPorCargo, "cargo");
    
    private static Map<String, Ordenacion> mapaAcronimoOrdenacion;

    private final String acronimo;
    private final Comparator comparador;

    private Ordenacion(Comparator comparador, String acronimo)
    {
      this.comparador = comparador;
      this.acronimo = acronimo;
    }

    public Comparator getComparador()
    {
      return comparador;
    }

    public String getAcronimo()
    {
      return acronimo;
    }

    // Método para obtener una ordenación según el acrónimo que nos hayan pasado.
    // Devuelve null si la ordenación no existe.
    public static Ordenacion getPorAcronimo(String acronimo)
    {
      return mapaAcronimoOrdenacion.get(acronimo);
    }

    // Inicializamos el mapa inverso por acronimo al cargar la clase, también
    // podríamos hacerlo de forma "lazy" en el primer acceso, si quisiéramos.
    static
    {
      mapaAcronimoOrdenacion = new HashMap();
      for (Ordenacion rt : Ordenacion.values())
      {
        mapaAcronimoOrdenacion.put(rt.getAcronimo(), rt);
      }
    }
  }

  // Un breve ejemplo de como sería el uso.
  public static void main(String[] arg) throws Exception
  {
    //...
    String param_acronimo = ""; // lo obtenemos de alguna forma
    Ordenacion ord = Ordenacion.getPorAcronimo(param_acronimo);
    Set listaOrdenada = new TreeSet(ord.getComparador());
    //...
  }

De esta forma, podemos añadir nuevas ordenaciones "tranquilamente" añadiendo elementos a la enumeración y podemos saber que en todos los métodos a los que le pasemos una Ordenacion como parámetro seguirán funcionando, y que el control de si existe o no una Ordenacion con ese acrónimo se produce en un punto único, lo cual facilita el mantenimiento.

Lo que he mostrado con un acrónimo y un comparador se puede aplicar a cualquier cosa que se os ocurra: Enumeración con tipos de datos admitidos y expresiones regulares para comprobar si el parámetro es correcto traducciones de acrónimos/códigos numéricos a nombres completos para mostrar al usuario en listas cortas que no estén en BDD...

La cuestión es que si tenéis una lista de elementos y estáis pasando int o String y luego haciendo if/else o switch en varias partes de vuestro código, re-pensadlo a ver si podéis usar una enumeración y hacer el código "type safe" con la traducción de input -> valor correcto en un sólo punto.

Espero que os sirva y...
Happy coding! EJ

Reflexiones sobre el uso de cachés I

Hoy un par de reflexiones sobre un tema interesante y complejo, aunque menos de lo que parece a primera vista: el uso de cachés* (me disculpo por adelantado del uso incorrecto de memoria caché y sus derivados, pero todos nos entenderemos y no encuentro sinónimo breve y adecuado).
La utilización de cachés es una técnica muy útil para mejorar el rendimiento de nuestras aplicaciones, aunque sufre del mismo tipo de problemas que otras técnicas avanzadas para mejorar el rendimiento, como la programación multi-hilo: Es tremendamente útil pero a la vez peligrosa si no se usa adecuadamente, por lo que mucha gente no se encuentra cómoda usándola y prefiere optar por la prudencia y abstenerse. Sin embargo, en el fondo no es tan complicada de utilizar si sabemos lo que estamos haciendo, así que intentaremos explicar aquí algunos conceptos para ver si ayudan a entenderla mejor.

Qué es y por qué

Lo primero es dejar claro qué es lo que hacemos y por qué lo hacemos: La idea básica es que para obtener el resultado que necesitamos, nuestros programas siguen una serie de pasos que hay que repetir cada vez que pedimos ese resultado. Usar una cache no es más que almacenar alguno de los resultados intermedios para no tener que volver a calcularlo, evitando tener que repetir los pasos que llevan a calcular el resultado intermedio. Así de simple. La razón de hacerlo es aun más sencilla: realizar los pasos cuesta recursos (principalmente tiempo) y si podemos evitar tener que hacerlos, evitamos consumir esos recursos. Esta perogrullada de explicación cobra sentido cuando debamos tomar decisiones sobre si vale la pena usar cachés, dónde, cómo...

Como atacar el problema

Uno de los errores comunes a la hora de implementar técnicas de cachés es empezar pensando cómo vamos a implementar nuestra caché, que librerías utilizar etc. Error. La implementación es importante, pero hay otros factores tanto o más importantes sobre los que merece la pena decidir antes:

• ¿Merece la pena introducir una caché? Ésta es la primera pregunta que deberíamos hacernos y no es trivial. Volviendo al primer punto, queremos introducir el uso de cachés para obtener unos resultados (ahorrar tiempo, consumo de CPU etc.) y si no lo vamos a conseguir, no merece la pena hacerlo. Aunque no lo parezca, hay muchos tipos de aplicaciones donde el uso de cachés no produce suficientes beneficios para el coste invertido. Para contestar a esta pregunta, es importante estudiar las respuestas a las preguntas que la siguen, ya que nos darán muchas pistas.
• ¿A que nivel vamos a introducir la caché? En el diseño típico de una aplicación hay varias capas que tendremos que recorrer hasta llegar el resultado que deseamos, y muchas veces el resultado va sufriendo transformaciones por el camino, así que decidir cuál es el resultado intermedio que vamos a cachear es también una de las decisiones importantes.
  Por ejemplo, en una típica aplicación web multi-capa, no es lo mismo guardar el resultado de la consulta a la BDD, que los objetos Java que hayamos construido a partir del resultado de la consulta, que el trozo de JSP (p.e.) donde los hayamos pintado, que toda la página HTML resultado de la petición.
  Hay que pensar que cuanto más cerca estemos del origen del resultado, más fácil será de reutilizar, ya que habrá sufrido menos transformaciones, pero menos estaremos ganando ya que nos ahorraremos menos pasos. Al mismo tiempo, cuanto más complejo sea el resultado que guardemos en caché, más nos ahorraremos pero mayor será la probabilidad de que no nos sirva la próxima vez que lo queramos usar.
  Por ejemplo, pintar la fecha/hora actual en la página resultado, o el nombre del usuario, o tener filtros sobre las búsquedas puede hacer que la página HML entera no la podamos reutilizar para otras peticiones de otros usuarios, pero si bajamos un nivel y guardamos la información antes de añadir esa información personalizada y aplicar el filtro, ahorraremos menos pasos pero podremos reutilizar mucho más ese resultado intermedio.
  
• ¿Cómo vamos a mantener actualizada la caché? Esta es la tercera pregunta importante y también nos da una pista muy importante sobre si merece la pena o no introducir una caché. Si hay algo mucho peor que un programa con bajo rendimiento por que no usa cachés, es un programa que devuelve resultados obsoletos por que no actualiza su caché cuando toca. Para poder mantener actualizada adecuadamente nuestra caché necesitamos tener claras dos cosas:
  • Identificar claramente cada elemento que guardamos en la cache para saber cuando lo podemos usar en vez de calcular de nuevo el resultado y cuando no.
  • Cuales son las circunstancias en las cuales el resultado intermedio que tenemos en cachés es inválido y cómo invalidarlo. Por ejemplo, si se actualizan datos en una de nuestras tablas... ¿que objetos de la caché se ven afectados y cómo podemos invalidarlos? ¿Lo haremos por tiempo, usaremos eventos, lo hará el usuario de forma manual?
  No poder responder claramente a estas preguntas o tener una respuesta muy compleja son signos de que quizá usar una caché no sea tan buena idea. Por ejemplo, si actualizar los datos de la tabla X nos invalida toda la caché y esa tabla se actualiza muy a menudo... quizá no nos sirva de nada tener una caché.


• ¿Cual es el perfil de nuestra aplicación? Una vez visto lo anterior, hay que añadir que no es lo mismo una aplicación donde los datos cambian solamente una vez al año pero el cambio ha de ser visible inmediatamente, que una aplicación donde los datos se actualizan continuamente pero únicamente mostramos resultados consolidados que no cambian. No es lo mismo una aplicación donde el 90% de accesos son a un par de páginas que han de estar siempre actualizadas, que otra donde los accesos están repartidos semi-aleatoriamente entre miles de páginas, aunque cambien poco.
  Siguiendo con los ejemplos, una aplicación como la última mencionada donde se accede aleatoriamente a miles de páginas... o tenemos una caché donde poder tener las miles de páginas pre-calculadas o al no poder guardarlas todas y ser el acceso aleatorio, el uso de la caché puede ser muy bajo así que o nos caben todas en caché o quizá no merezca la pena. En cambio, en la anterior donde un 90% de acceso se producen a un par de páginas que han de estar siempre actualizadas, si montamos un sistema de eventos para tener la caché siempre actualizada podemos sacarle un gran partido a la caché, pero si el sistema para mantenerla actualizada es demasiado complejo e inestable quizá debamos descartar el uso de una caché a ese nivel.

Así pues, el primer paso es responder a estas preguntas y decidir si merece la pena o no implementar una caché. Obviamente habrá muchos casos donde la respuesta no se decantara claramente en un sentido y podemos pasar a hacer pruebas y decidir con datos en la mano, pero como mínimo nos habrá servidor para tener claro cómo queremos hacerlo y qué cosas queremos comprobar en nuestra fase de evaluación.

Hay mucho más que hablar sobre el tema, aunque espero que con esto os de alguna idea de como empezar a estudiar el tema. No quiero hacer este tocho más extenso de lo que es y lo dejaré aquí de momento. Si hay interés, continuaré con el tema explicando algunos perfiles típicos de aplicaciones y las soluciones técnicas más habituales.

Happy coding! EJ

TreeSet y java.io.NotSerializableException

Después de un periodo sabático, un truco para solucionar un problemilla habitual por culpa de como está montado el JDK, sin ser realmente culpa de nadie... El problema en sí aparece al tratar de serializar un TreeSet, o cualquier otra colección ordenada, en el cual hemos especificado un Comparator creado como instancia anónima. En código:

static Comparator miComparador =
    new Comparator()
    {
      @Override
      public int compare(Object arg0, Object arg1)
      {
        //...
        return valorAdecuado;
      }
    };

  public static void main(String[] arg)
    throws Exception
    {
      Set miSetOrdenado = new TreeSet(miComparador);
      // ... rellenamos el Set
      ByteArrayOutputStream theBOS = new ByteArrayOutputStream();
      ObjectOutputStream theOOS = new ObjectOutputStream(theBOS);
      theOOS.writeObject(miSetOrdenado);
      theOOS.close();
    }

Si intentamos ejecutar este código, nos saltará una excepción:
java.io.NotSerializableException: test.App$1

Después de volverse tonto mirando por que el los elementos que uno pone en el TreeSet no son serializables, para normalmente descubrir que sí lo son, al final resulta que el problema es el Comparator. Entonces buscamos por Internet y las recomendaciones más habituales son hacer el campo static o transient, implementar Serializable... pero resulta que el Comparator lo tenemos declarado como static, por lo tanto no debería afectar puesto que la clase App sería Serializable... ¿o no? La cuestión sin embargo es... ¿cual es realmente la instancia que no es Serializable?

Para hacer la historia breve, el problema es que la instancia no Serializable es el TreeSet y que el campo que habría que marcar como transient es donde se guarda el Comparator de la clase TreeSet, cosa imposible, así que sólo nos queda declarar que el Comparator implementa Serializable, pero... ¿Cómo lo hacemos si es una instancia anónima? La solución pasa por no usar una instancia de clase anónima y hacer una clase interna, la cual sí podemos declarar que es Serializable y luego crear una instancia. Modificando ligeramente el código:

static class MiClaseComparadora
    implements Comparator, Serializable
  {
    @Override
    public int compare(Object arg0, Object arg1)
    {
      //...
      return valorAdecuado;
    }
  }
  static Comparator miComparador = new MiClaseComparadora();

  public static void main(String[] arg)
    throws Exception
    {
      Set miSetOrdenado = new TreeSet(miComparador);
      // ... rellenamos el Set
      ByteArrayOutputStream theBOS = new ByteArrayOutputStream();
      ObjectOutputStream theOOS = new ObjectOutputStream(theBOS);
      theOOS.writeObject(miSetOrdenado);
      theOOS.close();
    }

Y listo. Un detalle tonto que puede impedir que podamos serializar algunos objetos necesarios para nuestra aplicación y cuyo diagnóstico no es sencillo.

En mi caso, necesitaba almacenar en OSCache una lista ordenada de elementos para no tener que re-ordenarlos cada vez y al pasar la cache de memoria a disco... zas!

Espero que esto le evite a alguien tener que dar tantas vueltas por Internet como a mí, para acabar sin encontrar una solucón clara y concisa.

Happy coding!
EJ

Maven: como hacer fácil lo difícil y difícil lo fácil

//RANT ON

Debo confesar que mi primera idea para el titulo, llevado por la frustración, era "Mierda de Maven", y eso era lo más fino que se me ocurría, pero teniendo en cuenta que por mi parte odio los titulares amarillistas en los posts de los blogs, he decidido ser coherente y poner algo más neutro, o casi :).

La cuestión es que llevo unos días intentando transformar un proyecto de infraestructura desde Ant a Maven. Lo reconozco, nunca he sido fan de Maven pero resulta que quiero poder distribuir este proyecto en repositorios Maven y los buenos chicos de SonaType ofrecen hospedaje gratutito de repositorio a los proyectos open source. Eso sí, usando Maven para crear y subir las "releases" etc.

Así que después de mucho resistirme, me dije "¡amos a probar, hombre!" y como dicen los anglos decidí "morder la bala" (bite the bullet) o agarrarme los machos, como más os guste. Por el camino tuve que abandonar algunas cosas, como los productos del proyecto que no son .jar (tengo/tenía un .zip y un .xpi), y plegarme a las convenciones que los creadores de Maven consideran que son las buenas. Todo sea por la causa.

Pero bueno, después de unas cuantas peleas, unos cuantos insultos al aire y mucho Google + prueba y error, consigo tener el proyecto montado más o menos como quiero. Los otros artefactos los hago con Ant y al final dejo un proyecto padre y un subproyecto. Sigo las instrucciones para desplegar los artefactos en el repositorio de Sonatype (ver Sonatype OSS Maven Repository Usage Guide) y después de unas cuantas maldiciones más consigo desplegar unos SNAPSHOT e incluso una release. Y aquí llega el detalle: Como repositorio de versiones uso Mercurial, para poder tener siempre el histórico conmigo, cosa muy útil hoy en día donde los repositoros públicos te pueden hacer alguna jugada, y para colmo de males desarrollo en Windows (ya, ya, nadie es perfecto) así que cuanto intento perfeccionar mi pom.xml para que no tenga ningún path absoluto, me encuentro con que la propiedad ${basedir}devuelve siempre el path en Windows con barras invertidas (backslahes) y que el modulo SCM no entiende la URL tal como se la pasa esa propiedad. Bueno,un detallito, nada que Google no pueda arreglar, ¿verdad? Pues no, Google nos responde que ese problema es muy, pero que muy, común y que realmente "no hay solución" que no sea dar trescientas vueltas al mundo, constuir un plugin hacer unas cosas extrañísimas. Madre mía.

Entonces decido que si no lo puedo sacar automáticamente, quizá si se lo paso en un fichero de propiedades y que cada usuario se apañe configurando.... ¡MEEEC! ¡Error! ¿A quien se le ocurriría poder leer algo que no esté en el pom.xml? Debe ser únicamente a los extraterrestres por que Maven lo vuelve a poner complicadísimo simplemente para leer un p|@#@# fichero de propiedades y usarlas en el pom.xml. Lo más aproximado a lo que quiero requiere un plugin que he encontrado, el cual está en estado alpha y ni siquiera en los repositorios oficiales...

Así que sí, Maven permite hacer cosas "complicadísimas" de forma fácil por que te vienen hechas, pero algo tan "simple" como producir un artefacto que no sea .jar/.rar/.war/.ear, obtener un path normalizado o leer un fichero de propiedades es como para sacarse un master.

¿Por qué es el mundo tan cruel?... ¿por qué?... ¿por qué? :(

//RANT OFF

Happy coding! EJ