Dentro del roadmap de Adobe Apollo

En los últimos días he estado investigando sobre Flex y sus Data Services, eso sí, contando siempre con la inestimable ayuda de Carlos Rovira.

Hoy, haciendo un repaso a las noticias del fin de semana he dado con el resumen de una interesante entrevista a Mike Downey, Product Manager de Adobe Apollo en la que cuenta lo que propone el proyecto más ambicioso de Adobe.

Soporte para lectura y visualización de ficheros PDF, soporte de aplicaciones para móviles en la versión 2.0 de la herramienta, habilidad para ejecutar funciones en el cliente, soporte de actualizaciones automáticas progresivas, detección automática de la plataforma, etc. Parece que habrá una versión para Linux, pero sólo el próximo año (y se deja muy en el aire el que no haya retrasos).

La herramienta es prometedora, especialmente si tenemos en cuenta que Flex ha tenido muy buena acogida, aunque quedan en el aire muchas cosas. Una es el soporte multiplataforma que intuyo que va a ser malo (por la nota sobre Linux), otra es el rendimiento en el que parece que no entran.

Por ahora habrá que esperar a la beta.

La reina de las transacciones

Curioseando por blogs relacionados con mi trabajo, he llegado a esta entrada de Chris Skinner, donde explica algunos detalles sobre lo que podríamos llamar la compañía reina de las transacciones.... Visa.

Algunos datos que quitan el hipo:

• 1.6 billones de tarjetas en circulación.
• 6.803 transacciones por segundo en hora punta.
• 56.3 billones de transacciones en el 2006.
• 4.5 trillones de dólares en volumen transaccional el pasado año.
• Su red se ha construido sobre 9 millones de millas de cable que se extienden a lo largo de todo el mundo.

Por último, siguiendo las cuentas de Mr. Skinner parece que Visa procesa... ¡más transacciones en un minuto en hora punta que todas las bolsas del mundo!

Bueno, esto habría que corroborarlo la verdad, porque la cifra de transacciones por segundo con la que se hace el cálculo es en la hora punta del año, es decir en Navidad. Pero vamos, que desde luego las cifras marean.

Sería muy interesante encontrar material donde explique las arquitecturas para manejar este monstruo transaccional. Si alguien lo tiene... ya sabe :)

Flex será Open Source

Lo leo en Made in Flex que Flex será Open Source. No se liberan todas las herramientas ni el IDE sino que tan sólo el SDK, por ahora. De todos modos, parece un movimiento muy inteligente por parte de Adobe y que sin duda le dará todavía más momento a la plataforma.

Este es el anuncio oficial y felicidades a todos los Flexadictos!

Oferta laboral para Galicia

Me han pedido varios desarrolladores (10) J2EE para trabajar en un proyecto para una importante multinacional en la zona de La Coruña. Se busca también alguien para liderar técnicamente el proyecto. Si alguno de los que lee este proyecto está interesado y puede demostrar varios años de experiencia pues que me envie un correo a mi cuenta de gmail (mpermar).

No puedo desvelar mucha información (más que nada porque tampoco la sé). Pero me comentan que es un proyecto muy importante, que está bien pagado, y que es un proyecto con vistas a muchos años.

Interesados, al correo que puse arriba.

¿Qué ha pasado con JBoss?

Esta va a ser sin duda alguna, y una vez más, la semana de JBoss. Los dos anuncios que han hecho oficialmente hoy en nota de prensa (aunque el del branch creo que ya lo pude leer la semana pasada) parece que han sacado a la luz algunos detalles que junto a todos los sucesos ocurridos durante los últimos meses dejan al servidor J2EE Open Source por excelencia colgado de un hilo.

El fundador abandona el proyecto, la mayor parte de los arquitectos lo han abandonado también, sea ahora o sea hace años, y lo mismo pasa con los ejecutivos e inversores, RedHat obtiene la marca comercial por lo que tiene todos los derechos sobre el código, y por si fuera poco parece que los expertos dicen que las cuentas de JBoss durante los últimos años estaban claramente infladas.

Para colmar el vaso, ahora RedHat anuncia que JBoss no le ha dado los beneficios que se esperaba (y este tipo de anuncios normalmente quiere decir que no se los ha dado con muuucha diferencia), y que es necesario cambiar todo el modelo de desarrollo. Y el nuevo modelo está bastante claro, y es el que le ha dado tanto éxito a RedHat, y es el que usan los detractores del Open Source con argumentos del estilo "RedHat es más caro que Microsoft" por ejemplo.

En el futuro, supongo que lo que nos espera es el "JBoss es más caro que WebSphere". Es cierto, siempre nos quedará la Fedora de J2EE, el jboss.org community edition, pero que a su vez siempre será peor con respecto a la versión empresarial, al menos hasta que salga alguna compañía/personas que se encarguen de clonar la versión empresarial de una manera rápida.

En fin, muchos dicen que se veía venir.

Webinars de Covalent

Covalent es una empresa dedicada al mundo del Open Source empresarial dando soporte y consultoría sobre muchos productos Open Source. Para ello cuentan entre sus miembros con varios expertos en diferentes productos de este mundillo. Bueno, el caso es que en su página web ofrecen una serie de webinars bastante técnicos y que probablemente (sólo leí el de terracotta y estaba bien) serán interesantes. El próximo será la introducción a Tomcat 6, este 9 de Mayo.

Los Webinars de Covalent.

Interesante entrada sobre Tomcat 6 y escalabilidad

Siempre con retraso pero he visto una entrada sobre Tomcat 6 en el blog de Filip Hanik, que aunque con un título provocador (Can Servlet Containers Scale? 16,000 Concurrent Connections using Tomcat 6!), lo cierto es que es realmente instructiva para comprender varios de los conceptos asociados con NIO, los retos que se afrontan al diseñar un contenedor web y una pequeña comparación de rendimiento.

De obligada lectura también los comentarios finales. Me quedo con el detalle de que Tomcat mantiene el throughput con muchas conexiones (¿quién dijo que no va bien?) pero también con el hecho de que se traga todo lo que le llega (que puede ser un problema como bien se dice en los comentarios).

En fin, interesante para leer.

Algunos enlaces interesantes sobre Flex Data Services

Durante las próximas semanas evaluaré algunos productos de streaming, para finalmente decidir si nos quedamos con nuestro producto interno mejorándolo o nos vamos a por algo desarrollado por terceros.

Aparte de los productos típicos desarrollados en Java, una de las cosas que estoy haciendo es explorar también productos en otras plataformas, para ver como hacen las cosas. Uno de ellos es Flex Data Services, de Adobe.

Se trata de una aplicación Java (WAR) que hace Streaming a aplicaciones creadas en Flex (o Apollo), siendo posible utilizar diferentes canales de comunicación (HTTP plano, HTTP binario, Web Services, JMS). Dejo aquí algunos enlaces que me han parecido interesantes (por orden de interés):

• Flex Data Services capacity planning
• Flex Test Drive Server for Java Developers (tomcat based)
• Building the back-end of the Tour of California “Tour Tracker” using Flex Data Services
• Real Time Market Data using Apollo and Flex Data Services
• Flex Data Management Services Tutorial

Aquí huele raro 2.0

Hace unos días, leyendo diferentes weblogs, me di cuenta que me estaba quedando totalmente obsoleto en esto de la Web 2.0, así que decidí suscribir mi lector de RSS a un par de páginas webs sobre startups. Como casi todas las startups ahora mismo son 2.0 , porque de otra forma no serían startups que se precien pues con KillerStartups.com y StartupSquad.com debería tener suficiente, pensé. Y vaya si tenía razón, mucho más que suficiente.

Está claro que estamos en un momento dulce. Las vacas flacas han pasado, y no hace falta navegar mucho para leer continuamente en las fuentes de noticias que el negocio de IT ha incrementado beneficios en los últimos años, que las empresas invierten cada vez más en IT y que ¡incluso los pogramadores estamos cobrando más!

Las empresas de capital de riesgo llevan asomando la cabeza durante el último par de años, y los business angels buscan desesperádamente encontrar el proximo youtube, flickr, digg o cualquier otro producto catalogable como 2.0 que los transforme de millonarios a billonarios del día a la noche.

Y todas estas empresas están invirtiendo su dinero en lo que podemos ver en killerstartups y startupsquad, que pronto desaparecerán de mi lector de RSS porque quiero que mi vida sea tranquila y eso no es compatible con leer sobre 20 empresas 2.0 al día. Que si 5min "la nueva wikipedia para videos", que si socialDragon el "nuevo adsense killer para videos", que si karmaex.com "haz algo bueno hoy", que si flip.com "una red social diferente", que si octopz.com "colaboración avanzada para mentes creativas", que si....

En fin que esto inevitablemente empieza a oler un poco (¿bastante?) a .com. Y ojo, porque basta que se la pegue uno de los grandes para que el castillo de naipes se caiga de golpe. Al final esto es una selección natural. Está claro; y sólo quedan los mejores. Pero la fiebre por crear la próxima venta billonaria está llevando a gastar millones y millones de una forma ridícula, y en muchos casos más de un gato saldrá escaldado.

En fin. Habrá que ser práctico, que yo no soy un inversor. Creo que la realidad es que es el momento de crear una empresa 2.0, aparecer en este listado, conseguir algo de capital y dedicarse a vivir :)

Amazon, sin SLAs pero barato

Werner Vogels, CTO de Amazon explica en RegDeveloper como Amazon ya no es una empresa que se dedica a vender libros sino que ahora vende tecnología.

Sin embargo, esta tecnología viene sin SLAs, ya que según Vogels es imposible ofrecer SLAs en un negocio que está naciendo. Como compensación, los precios de sus servicios son muy bajos, y parece que aunque no haya SLAs el CTO de Amazon se jacta de no haber perdido ningún dato y de haber sufrido problemas de rendimiento y que nadie se viese afectado. ¿El futuro? Parece que los tiros irán por seguridad, facturación y WebDAV.

En otra parte del artículo, Vogels explica como internamente trabajan en pequeños equipos, autosuficientes, que tienen autonomía para escoger sus herramientas. De este modo tienen su comunidad de Ruby, o sus grupos de Perl, C++ o Java. A la hora de escoger un contenedor, se quedan con Tomcat, JBoss o cualquier otra cosa hecha en casa.

Los problemas de interoperabilidad se solucionan con contratos. Esto es: "haz lo que quieras pero aquí tienes el SLA". Los SLAs dentro de los proyectos de desarrollo parecen ser rígidos, y seguramente sean la clave para obtener el rendimiento que están teniendo.

Para más sobre sus servicios web, pues aquí.

Evaluando la salud de proyectos Open Source con ohloh

En fin, que me he cortado porque iba a poner un título del estilo de "jLibrary vale 1 millón de dólares" mmmm. Creo que debería haberlo puesto porque igual alguien se animaba a invertir :)

El caso es que he estado jugando un poco con ohloh. Se trata de una aplicación web de análisis de proyectos Open Source. Básicamente lo que hace es analizar el código de proyectos que se encuentran en repositorios de Open Source como sourceforge.net y extraer una serie de hechos a partir de todos los datos. He estado probando el servicio con jLibrary y la verdad es que tengo que decir que los resultados son interesantes.

Por ejemplo, este es el análisis del coste del proyecto que hace ohloh:

Codebase 89,010 LOC
Effort (est.) 22 Person Years
Avg. Salary 55.000 $/year
Estimated cost: $1,193,250

En fin, mmmm, los sueldos son bastante altos para España, así que supongo que el coste realmente sería menor :D Tampoco sabía que tenía tan pocas líneas de código, la verdad. Lo cierto es que utilizaba tantos frameworks que alguno puede estar sorprendido que con tan pocas líneas se puedan hacer tantas cosas... la magina del Open Source :)

En cuanto al estado del proyecto, hay que decir que ohloh lo clava:

Mostly written in Java
Factoid: "Small development team"

Over the past twelve months, only 5 developers contributed new code to jLibrary, making this a relatively small project.

For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 8 developers have contributed.

Yo creo que el análisis es perfecto, ya que en el último año prácticamente yo he sido el único que ha trabajado (y poco) en el proyecto. Además, no me ha sacado ningún warning sobre las licencias, cosa que sí se lo saca a muchos proyectos a poco que os pongáis a investigar un poco. También se ve que está bien comentado, porque ohloh pone un warning a todos los proyectos que no tienen comentarios.

En fin, que tampoco te va a dar un análisis muy completo del repositorio y del proyecto, pero encuentro que ohloh es un servicio muy bueno para evaluar la salud de proyectos Open Source. Y vosotros, ¿qué tal van de salud vuestros proyectos libres?

Instrumentando clases Java con anotaciones y class weaving

Hace unos meses estuve experimentando un poco con anotaciones y he decidido a escribir aquí el resultado, como referencia para que no se me olvide, y por si de paso a alguien le interesa, así que esta entrada va a ser bastante técnica. Empiezo...

La monitorización de sistemas es algo realmente fundamental, al menos para aplicaciones de medio y gran tamaño. Hoy en día, sin un sistema que nos permita examinar en tiempo real el estado de nuestras aplicaciones, se hace realmente complicado el encontrar errores, especialmente en sistemas distribuidos. Por poner un ejemplo, si tenemos un sistema de caché que funciona en cluster puede ser muy importante el saber en cada momento cual es el contenido de la caché, el saber si unas cachés están más llenas que otras, el ser capaz de ejecutar operaciones sobre la caché, etc.

En Java, JMX (en .NET ¿WMI?) permite la instrumentación de sistemas y la obtención de datos en tiempo real a través de herramientas como jconsole. Un libro que ya he recomendado en algún otro post, Pro Java EE 5 Performance Management and Optimization tiene varios capítulos donde recalca la importancia de instrumentar nuestro código en sistemas distribuidos complejos y pone algunos ejemplos con JMX.

La primera opción que nos puede venir a la cabeza a la hora de instrumentar nuestro código es simplemente crear nuestros managed beans y añadir el código de instrumentación directamente a nuestros proyectos:

MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); 
ObjectName name = new ObjectName("com.example.mbeans:type=Hello"); 
Hello mbean = new Hello(); 
mbs.registerMBean(mbean, name); 

Esta opción es sostenible y perfectamente justificable para proyectos pequeños. En cuanto los proyectos son de mayor calibre e involucran una cantidad considerable de componentes y desarrolladores es mejor buscar una solución más mantenible.

La alternativa natural sería crear un framework de monitorización que centralize toda instrumentación del proyecto. Esta es una opción muy recomendable que puede perfectamente cubrir todas nuestras necesidades.

Una vez que tenemos creado nuestro framework de monitorización, lo único que tenemos que hacer es decirle a nuestros desarrolladores como utilizarlo, y listo. ¿En serio? Pues la verdad es que depende mucho de nuestros desarrolladores, del movimiento que haya en la empresa (¿están continuamente saliendo y entrando nuevos programadores?), y de nuestra capacidad de formar a los miembros más junior del equipo. Porque aunque el framework de monitorización nos ahorrará mucho trabajo, lo cierto es que si nuestros programadores no saben como utilizarlo, entonces a la larga puede ser una solución menos productiva. Por ejemplo nos podemos encontrar con que un desarrollador ha colocado objetos gigantescos en memoria, que otro ha utilizado el framework para exponer operaciones que exponen nuestro sistema, que otra persona ha ejecutado código muy costoso dentro de los managed beans, o en resumen que cada persona utiliza el framework de una manera diferente.

Una solución a este problema es hacer mucho más fácil y estándar el uso de nuestro framework de monitorización, y ahí es donde entra en juego el concepto de las anotaciones. Si añadimos anotaciones al framework, los desarrolladores sólo tendrán por ejemplo que etiquetar sus clases, métodos o atributos, y nuestro framework de monitorización realizará todo el trabajo sucio: crear los managed beans, gestionar su registro en la plataforma de monitorización, controlar el árbol de nombres, o incluso operaciones más avanzadas como filtrar los componentes que se monitorizan y los que no se monitorizan.

Una opción muy parecida es la que ofrece Spring JMX o incluso de algún modo lo que ofrece el JDK 6. El problema del segundo es que el soporte no es demasiado avanzado, simplemente es un conjunto de anotaciones para no tener que extender clases o implementar interfaces. El problema del primero es que te obliga a utilizar Spring, algo que quizás no sea posible o simplemente no se quiera añadir por cualquier otra razón.

En los siguientes pasos voy a mostrar una aproximación al uso de anotaciones para este escenario. Lo primero es crear las anotaciones. En este caso serán muy simples a modo de ejemplo.

Anotación para cualquier clase que sea un MBean:

@Retention(RetentionPolicy.RUNTIME)  
@Target(ElementType.TYPE)
public @interface MBean {
String name();
String root();
} 

Anotación para un atributo instrumentado:

@Retention(RetentionPolicy.RUNTIME)  
@Target(ElementType.FIELD)
public @interface MBeanAttribute { 
String name();
} 

Anotación para un método instrumentado:

@Retention(RetentionPolicy.RUNTIME)  
@Target(ElementType.METHOD)
public @interface MBeanMethod { 

}

Una vez definidas las anotaciones ya se podría marcar cualquier clase Java como un MBean. El siguiente código muestra un servicio instrumentado:

@MBean (root="org.test:",name="TestService")
public class TestService {

public static boolean testBoolean = true;
public static String testString = "Test service";

@MBeanAttribute(name="stringAttribute")
public String stringAttribute;
private long lastLong;

public String getStringAttribute() {
return testString;
} 

@MBeanMethod()
public boolean getTestState() {

return testBoolean;
}

@MBeanMethod()
public long customOperation() {

// do some monitoring calcs here
lastLong = Math.round(Math.random()*1000);
return lastLong;
}

public void nonMBeanMethod() {}

public long getLastLong() {
return lastLong;
}
}

Hasta aquí todo bien, pero el que todavía siga leyendo se preguntará... ¿y ahora qué? La idea original era ser capaz de monitorizar nuestro sistema, es decir, cualquier clase Java, sin tener que llenarla de código de monitorización ni obligar a nuestros programadores a utilizar un framework, pero es que hasta este momento el código de monitorización está en nuestro framework imaginario. Así que, ¿cómo se enlaza dicho framework y estas clases Java?

Para hacer eso inyectaremos directamente el código de instrumentación dentro de las clases Java. Esto es lo que normalmente se conoce como weaving, un término relacionado con la programación orientada a aspectos (de hecho todo lo que estoy mostrando aquí se podría realizar también con AOP). Para inyectar el código en este ejemplo utilizaré el framework javassist ya que es bastante descriptivo, pero otros frameworks podrían ser más útiles por ser de bajo nivel como BCEL o ASM. Migrar el ejemplo a estos entornos puede quedar como ejercicio :)

El proceso de weaving de nuestras clases es el más laborioso y la verdad es que resulta difícil poner el código fuente aquí. Voy a escribir a continuación el pseudocódigo del proceso de instrumentación, y podéis leer directamente el código fuente en el enlace de descarga que pongo al final.

1. Escanear una clase en busca de la anotación @MBean.
2. En caso de encontrar la anotación, buscar todos los métodos (anotación @MBeanMethod), y los atributos (anotacion @MBeanAttribute) expuestos por la clase que hemos encontrado.
3. Crear una interfaz utilizando javaassist. Esta interfaz contendrá todos los métodos instrumentados que hemos encontrado, más una serie de métodos get que se generarán para cada uno de los atributos instrumentados (otra opción sería olvidarse de la anotación de atributos y asumir que todo método get que encontremos expondrá un atributo).
4. A continuación, crear una nueva clase que actuará de proxy e implementará la interfaz que hemos generado en el paso anterior. Esta clase proxy extenderá a StandardMBean, MXBean, o cualquier otra clase que creemos que sea un MBean y que contenga métodos genéricos. Así, en todos los proxies que creemos, tendremos una serie de funcionalidad común.
5. Crear el constructor del proxy, de forma que se guarde una referencia local al objeto que realmente se quiere monitorizar (esa referencia podría ser una soft o weak reference). El constructor también deberá registrar el managed bean en nuestro framework una vez que ha sido creado.
6. Implementar todos los métodos de la interfaz en la clase proxy que hemos creado. Estos métodos simplemente delegarán las llamadas sobre el objeto original que se ha recibido en el constructor del proxy.
7. Por último, modificar el constructor (o los constructores) del objeto original a monitorizar, de forma que cuando se cree una instancia de dicho objeto se cree también un proxy MBean.
   

El siguiente diagrama muestra como funciona el proceso de weaving. Como lanzar este proceso queda a vuestra elección. Podéis crear un plug-in de maven que simplemente ejecute este algoritmo como parte del proceso de build, o incluso podéis ir más allá y crear un ClassLoader que realize el weaving en tiempo de ejecución cada vez que una clase se carga y registrar ese ClassLoader en vuestro servidor de aplicaciones favorito. La ventaja de este método que he expuesto es que se lo podéis aplicar a cualquier código existente sin tener que añadir ningún tipo de dependencia, tan sólo anotando las clases que ya existen. Pero ojo, también hay alguna desventaja. La principal es que el proceso de weaving modifica las clases originales, con lo que quizás no podréis depurarlas fácilmente. Esto no lo he confirmado aunque probablemente dependa de como funcione javassist. Teóricamente, las modificaciones en el bytecode no tienen porque alterar el proceso de depuración de un programa, aunque añadan nuevo código. Esto es exactamente lo que hacen productos como terracotta. Un JSR específica todo el proceso que garantiza la depuración aunque se modifiquen los bytecodes, pero no recuerdo ahora cual era. Como he comentado anteriormente el código fuente de la parte de weaving es demasiado extenso como para colocarlo aquí. He comprimido todo el código fuente y lo he añadido al final de la entrada. El proyecto ha sido creado con maven 2, así que lo necesitaréis para descargarse las dependencias. Hay un unit test que podéis ejecutar. El test ejecutará todo el weaving para el servicio que he puesto de ejemplo en este artículo y comprobará que los MBeans se registran, que los atributos son accesibles y que se pueden ejecutar los métodos. Podéis ver a continuación varias capturas de jconsole mostrando el servicio anterior. Si miráis detenidamente la tercera captura de pantalla veréis como el managed bean no es el objeto sino que es el proxy que está delegando todas las operaciones sobre el objeto real. Pues nada, espero que os haya parecido interesante esta idea, sobre anotaciones y weaving de clases. Probablemente el modelo se pueda llevar mucho más allá, como han hecho en terracotta, pero eso ya normalmente dependerá de nuestros recursos y del problema que queramos resolver. Cualquier comentario, ya sabéis. Descárgate el código fuente del ejemplo.

BEA lanza WebLogic 10

Hace un par de días se anunció la disponibilidad general de WebLogic 10. Ninguna sorpresa grande leyendo la la hoja de características. Entre lo más notable: Soporte de Java EE 5/EJB 3.0, soporte oficial de Spring, nueva JPA, Workshop 10 basado en Eclipse y que se puede instalar como plug-in sobre una instalación de Eclipse existente. Todo lo esperado.

Entre lo no esperado, es decir la funcionalidad menos conocida, filtering classloaders (viva!), auto-record en la consola de administración para crear comandos WLST (viva!, me entenderéis en unos días), mejoras en JMS (ojalá!), aplicación de escritorio para monitorizar los servidores (interesante), no hay soporte para plataformas Linux de 64 bits (mmmm??) y no hay soporte para plataformas Solaris (mmmm???).

Esperemos que los dos últimos puntos los arreglen pronto.

Migrado al nuevo blogger

Hoy he migrado mi template al nuevo sistema de blogger. Tiene algunas cosillas interesantes así que ahora aparece el historial a la derecha y también la lista de tags. Este cambio es uno más en mi caótico historial como blogger. Así que en una nueva muestra de falta de respeto los viejos comentarios que se encontraban en haloscan no están disponibles, porque mantendré el sistema de blogger (espero que por mucho tiempo). Muchísimas gracias a todos los que habéis comentado cosas. Que sepáis que estáis todos fichados :-)

Eclipse: 5 años lanzando software a tiempo.

Hoy he estado viendo la presentación que Eric Gamma realizó en la JavaPolis 2006. Me parece que es una referencia para cualquier persona que tenga que dedicarse a la gestión de procesos en una compañía de software, y desde luego de obligada visión para cualquiera que esté interesado en estos temas. En las siguientes líneas intentaré condensar los cuarenta minutoes a los que no llega la charla.

Y es que no muchas compañías pueden vanagloriarse de de haber estado liberando software en los plazos establecidos durante cinco años consecutivos. Como dice Eric, shipping matters, al menos si quieres hacer crecer una comunidad.

El proyecto Eclipse está actualmente distribuido a lo largo de todo el globo pero comenzó como un desarrollo cerrado en el que simplemente algo no existía si no había sido liberado previamente. Nadie podía hablar de proyectos que no habían sido liberados. Es fácil comprender que esto suponía una gran barrera entre los desarrolladores y los usuarios ya que era imposible recoger feedback hasta que el producto no se lanzaba.

Es muy interesante ver como Eclipse migró a una cultura orientada al lanzamiento de software. La regla es sencilla: "Si algo contribuye al lanzamiento de software, incluso indirectamente, entonces se considera bueno. Si algo no contribuye, entonces es malo". ¿Vamos a liberar enormes documentos de diseño? ¿No? Ok, entonces no los haremos. Dentro de la cultura se valora siempre la habilidad para liberar software. ¿Has liberado software? Bien, entonces puedes hablar.

En 2001 Eclipse realizó la transición a un proceso abierto de desarrollo. Pero un proceso abierto de desarrollo genera una comunidad, y una comunidad requiere atención. De repente los desarrolladores se encontraron con que los usuarios podían interactuar con su bugzilla, que en los newsgroups aparecían constantemente preguntas, etc. Para sobrevivir a este efecto, Eric señala como algo fundamental el invertir en interacción con la comunidad. Cada desarrollador de Eclipse puede invertir el 30% de su tiempo en interactuar con la comunidad. Se trata de romper las barreras entre los usuarios y los desarrolladores.

En un proceso de desarrollo abierto las dos partes se comprometen y las dos partes ganan. El proyecto le ofrece al usuario el compromiso de escuchar y reaccionar a su feedback, demostrar un progreso continuo y hacer transparente el proceso de desarrollo, es decir, mostrar los planes de desarrollo, permitir acceso a las diferentes milestones, etc. Por otra parte, como contrapartida los usuarios comenzarán a involucrarse y a resolver las preguntas fáciles (si la comunidad es saludable los desarrolladores sólo tendrán que gastar su tiempo en contestar las preguntas complejas), informarán sobre errores y defectos, validarán la tecnología escribiendo plug-ins, enviarán mejoras y parches, etc.

Para conseguir un proceso de desarrollo abierto se requieren live betas, es decir, se requiere que el software se pueda probar pronto, conforme se va creando. Esto requiere que el proyecto sea saludable ya que se debe obtener calidad en todo momento. En Eclipse esto son las milestones. Eclipse lanza una versión mayor de su software por año, de otro modo sería demasiado estrés para el equipo, el resto son milestones.

El proceso de desarrollo comienza con una fase de calentamiento que dura un mes. En esta fase cualquiera puede hacer lo que desee y nadie le va a pedir cuentas por ello. Es una fase también en la que se analiza lo que se ha hecho en la versión anterior y se buscan posibles mejoras. Al final de esta fase se crea el plan inicial de lanzamiento.

Posteriormente se entra en el proceso de milestones. Eclipse lanza de siete a ocho milestones por año. Inicialmente una milestone duraba tres semanas pero pronto encontraron que a medida que el proyecto se hizo complejo esta medida no era suficiente, así que en la actualidad cada iteración consume seis semanas. El objetivo inicial es conseguir software saludable, y las milestones les ayudan a mantener la forma, es decir mantener siempre un ritmo de trabajo saludable. De este modo, cuando llega el momento de lanzar la versión final, el espacio que hay entre la última milestone y una versión de producción no es tan grande y el esfuerzo a realizar es menor. Una vez terminada cada milestone es firmada por los diferentes equipos.

Un proceso de desarrollo transparente requiere también planificación transparente, es decir, mostrar el plan al público. Este plan ya no será nunca más estático, sino dinámico, y se actualizará continuamente según la evolución del proyecto y el feedback de la comunidad. Para eso los elementos que forman el plan tienen estados: commited, proposed o deferred.

Una milestone saludable significa consumible, es decir, que pueda ser probada (testable) y que pueda ser demostrada (demo-able), y al mismo tiempo debe ser honesta, es decir, con un tiempo fijo de lanzamiento y un incremento en las funcionalidades. Con cualquier milestone de Eclipse los usuarios deben ser productivos. El software debe siempre ser continuamente consumible, continuamente interesante y debe continuamente escuchar el feedback.

Para conseguir estos objetivos los equipos de desarrollo tienen que consumir sus propios productos. Eclipse trabaja con un sistema de integración continua multi-componente (es decir cada componente, cada equipo, tiene su sistema de CI que se coordinan para dar el resultado final). La milestone se divide a su vez en dias y semanas. Cada dia un equipo debe consumir lo que ha creado el día anterior y comenzará a trabajar sobre esa base. A su vez, cada semana, los diferentes equipos comenzarán a consumir todo lo que el resto de equipos realizaron la semana anterior. Finalmente, el último gran salto es la milestone, en la que serán los usuarios finales los que consumirán el producto en el que se ha trabajado durante las últimas semanas. Todo esto lleva a un feedback continuo, primero el equipo, después el resto de equipos, para llegar finalmente al usuario final.

Finalmente el proceso termina con el end game. Este se divide en fases de pruebas y corrección de errores: test-fix-test-fix-test ... Eclipse no tiene una sección de testers. Todo desarrollador es un tester. El ritmo de hacer tests puede ser cansino, por ello no pasan más de dos días realizando tests y a continuación pasan a corregir errores. Una vez corregidos, se vuelven a los tests, y el ciclo continua. El ciclo se vuelve más duro y estricto conforme avanza el tiempo y se acerca la fecha definitiva. El número de bugs es menor, hay más revisiones y se controla mucho más el número de regressions.

Posteriormente Eric Gamma habla sobre la transición en productos comerciales hacia un Open Commercial Software Development, que según él (yo estoy de acuerdo) es el futuro del software comercial. El objetivo es conseguir la misma transparencia que hay en Eclipse pero en proyectos comerciales. Todo ello requiere que el proyecto comercial:

• Ofrezca acceso directo al sitio web de los desarrolladores.


• Ofrezca acceso al código fuente (o parte), que exista una comunidad, que los propios clientes puedan crear mejoras y parches, ...


• Permita interactuar directamente con el equipo de desarrollo.


• Ofrezca acceso a todas las versiones previas, milestones, betas o versiones de integración.

Creo que esto resume más o menos lo que es la charla de Eric. Parecen un conjunto de ideas muy a tener en cuenta, y que pueden ayudar a muchas organizaciones que realmente sufren para ser capaces de lanzar lo que inicialmente parece como una simple versión de producción pero que sin un proceso de desarrollo adecuado se puede convertir en un infierno que se alarga durante meses o incluso años.