Feliz año nuevo y ya son cinco años bloggeando

Bueno, quizás alguno haya notado que no he escrito nada esta última semana. Esto se debe a que ahora mismo estoy en España, de vacaciones, y escribiendo esta entrada con una conexión de prestado.

Hemos aprovechado estos días para visitar a la familia y aunque esto ya se está acabando y pronto, pero que muy pronto (sniff), estaré ya de vuelta por Dublin, pues quería aprovechar la ocasión para felicitaros a todos los que os pasáis de vez en cuando por aquí un feliz año 2008.

Y otra cosa, es que parece que debo estar de cumpleaños. Allá por finales del 2002 empezaba a bloggear. Es una pena porque aunque cuando el año pasado comentaba que era el cuarto aniversario todavía estaba disponible mi viejo blog en blog-city.com pero ahora lo han borrado ya. Lo más viejo que he encontrado es lo que se puede ver en el historico de archivo.org que es de Abril del 2003.

Que tiempos eran aquellos. El concepto de blog apenas existía y creo que eramos unos cuantos "frikis" los que teníamos la desvergüenza de escribir a pecho descubierto en la red de redes. Claro, ahora lees las entradas y te partes de risa: que si patentes en .NET, que si nos recomiendan escribir tests unitarios, que si las nuevas características de C# y si Java las debe adoptar, en fin. Cuantas cositas que al final, realmente, aunque en el momento nos puedan parecer importantes, pues mirando hacia tras te das cuenta de que son un poco tonterías, que todo se ha pasado ya y que realmente lo importante es pasar un año más con tu familia, amigos y las personas que quieres. Siempre hablamos de que la tecnología avanza rapidísimo, pero la verdad es que los años pasan todavía más rápido :-)

Pues eso, que ¡feliz año!

Reporting en Java, como hemos cambiado...

Comentaba hace unos días que andaba a la busca que de motores de generación de informes en Java porque los clientes empiezan a preguntar por algo así. La verdad es que desde que había dejado España no había tenido que mirar más este tipo de herramientas. Hoy, acabando ya la revisión me han venido a mente una serie de recuerdos de esos que te hacen pensar lo viejo que vas ya, porque vaya que no han cambiado las cosas.

Mi primer contacto con la generación de informes en Java debió ser allá por el 1999. Casi nada, oiga. Necesitábamos un framework para generar informes de manera sencilla y ... no había nada. Pero nada de nada. Recuerdo que el imprimir un informe utilizando AWT era un infierno. Una miserable página te ocupaba unos 50Mb de memoria (que en aquella época ya era algo), la CPU se disparaba, pantallas en blanco (que Swing no era lo que es), etc. Al final, como nuestras impresoras soportaban PCL5 lo que hice fue crear una especie de printer spool en Java contra el que se programaba mediante una API de alto nivel pero que en realidad creaba informes que se generaban en PCL5 y se enviaban a la impresora. Vaya, eso sí que volaba. Los informes eran ligerísimos y se imprimían como balas, las páginas que fuesen.

Durante los años siguientes, ya en otro lugar, siempre tuve que andar dando vueltas con los informes. Los primeros años, allá por el 2001 y 2002, la verdad es que seguía sin haber nada de nada. O al menos nada utilizable. No quedaba otra que utilizar alguna herramienta propietaria que siempre iba un poco más adelante, pero como nunca había mucho dinero te las tenías que ahorrar con versiones viejas que no tenían todo lo que querías.

Ya hace tres o cuatro años empezaron a aparecer cosas interesantes. Teníamos Jasper Reports o JFreeReport, y alguno más por ahí que ya se ha muerto. En fin, que estaban muy bien, pero que diseñar, lo que se dice diseñar, pues que no había mucha herramienta. Estaba el iReport, que no se parecía en nada a lo que encontráis hoy en la web. Era cutre y un infierno, pero después de mucho pelear pues hasta conseguías que funcionaba.

Y ahora, hoy en día, que maravilla. Han pasado ocho años y por fin se puede ser medianamente productivo a la hora de hablar de informes. Ya era hora, por cierto. Ayer estuve jugando un poco con el Report Designer y con su reporting engine (otrora JFreeReport) y es que eso ya no es lo que era. Con su wizard, conectándote a tu base de datos y escogiendo diferentes plantillas, definiendo todas las agrupaciones, el formato, etc. y al final que te genera el informe el sólito y que lo puedes publicar a tu portal web de inmediato. Buf.

Y hoy le tocó a BIRT y como ha cambiado también. Me acuerdo hace un par de años que BIRT estaba cogiendo muchísima fama y en la EclipseCon tuve la oportunidad de hablar con gente que lo estaba utilizando, y bueno, estaba bien, pero no servía para la web y era bastante complicado de utilizar. Pero hoy, en 10 minutos tenía una aplicación web y varios informes contra mi base de datos funcionando. El editor es espectacular, de lo mejorcito que he visto, super sencillo de utilizar. La integración con WTP es perfecta, vas creando el informe y lo puedes desplegar y probar al momento. Una maravilla vamos.

En fin, que como han cambiado las cosas. Parece que fue ayer. Ahí sentado en nuestra oficinita con Jesús y Miguel peleando con los comandos de PCL5 y alucinando con lo rápido que podíamos imprimir. Sólo han pasado ocho años. No estoy seguro de si eso es bueno o malo :-)

Lo nuevo de Amazon: SimpleDB

Parece que Amazon acaba de lanzar una limited beta de su nuevo servicio web SimpleDB. A estas alturas (el lanzamiento fue el Viernes) ya hay un montón de información sobre sus características técnicas. Una de las más llamativas es que el servicio web se ejecuta sobre erlang.

El nuevo servicio web propone un modelo muy simple basado en tener un dominio de datos que almacenará items los cuáles tendrán diferentes atributos en forma de clave valor. Sobre ese dominio se pueden ejecutar diferentes operaciones:

• CREATE: para cear una nueva base de datos.
• GET, PUT, DELETE: para obtener, crear o actualizar y eliminar items y propiedades en una base de datos.
• QUERY: para hacer consulta de datos. Las consultas están limitadas a cinco segundos.

El precio depende de diferentes factores como la cantidad de CPU utilizada al realizar las operaciones, el ancho de banda consumido tanto in como out, y el espacio en disco ocupado por la base de datos. Pero vamos anda en torno al 0.14$ por hora, 0.11$/0.18$ al mes por Gb. in/out y 1.50$ al mes por Gb. de almacenamiento.

Sobre todo esto y más detalles podéis consultar la web de SimpleDB desde la que tienen también una guía para iniciarse y y la guía de desarrolladores. De todas las opiniones que hay ya ahora mismo en la blogosfera sobre el servicio, me he quedado con las que me resultan particularmente interesantes y que resumo a continuación.

Charles H. Ying apunta varias consideraciones importantes en su blog como que la latencia en la sincronización de datos entre diferentes nodos puede ser grande (+1 sec.), que las queries sobre los objetos son lexicográficas (ej. 4 > 35 pero 04 < 35), o que el API no soporta búsquedas de texto. En High-Scalability no han tardado en hacerse eco de la noticia y ya publican una amplia lista de pros y contras. Parece que la mayor parte de los contras se centran en que el servicio es caro para lo que ofrece, en los posibles problemas de consistencia y latencia, la falta de soporte para algunos lenguajes, y resumiendo en que no te ofrece mucho lo que una base de datos te puede ofrecer ahora mismo; los pros se centran sobre todo en el aspecto "hosted", es decir en que no se necesita un administrador de base de datos, en que no necesitas comprar la base de datos ni hardware, en su soporte de replicación y en que puede ser algo muy interesante para startups.

Sriran Krishnan hace una revisión técnica bastante completa donde muestra un ejemplo de petición/respuesta utilizando el API REST que ofrece SimpleDB y se centra también en el problema de la latencia de las actualizaciones y que los datos no se repliquen instantáneamente en todos los nodos. Este punto es interesante, pero en mi opinión no refleja otra cosa sino que este servicio está enfocado hacia cierto tipo de aplicaciones y no debe utilizarse como una silver bullet. Por poner un ejemplo, realmente en un portal de opiniones sobre viajes, restaurantes, hoteles, lo que quieras, la consistencia de los datos en un márgen de unos segundos no es precisamente algo muy importante.

Don MacAskill apunta también algo bastante importante y es que este servicio puede que sea apto sólo para aquellos que ya estén utilizando Amazon EC2. La razón fundamental es la latencia. A no ser que nuestros servidores estén cerca de los de Amazon, sí decidimos utilizar SimpleDB tendremos que sumar a cada consulta el tiempo de latencia en obtener dichos datos, lo que dependiendo del número de consultas puede ser un problema importante.

Antipatrones de gestión de proyectos

Pero que bueno el post de Michael Nygard sobre Budgetecture y
todos sus primos. ¿Quién no se ha encontrado alguna vez con ellos?

Budgetecture es un juego de palabras con budget (presupuesto) y architecture (arqhitectura). La arquitectura, o si queréis la gestión del proyecto, es una continua negociación. Requiere realmente autoridad y habilidad para negociar una solución correcta, no sólo con tus desarrolladores sino también con las personas que manejan el presupuesto. Lo malo es que los ingenieros tendemos a ceder fácilmente. Yo creo que es algo que nos ha pasado, o nos pasa a todos. Al fin y al cabo, somos ingenieros, ¿no? Nos gusta todo esto, la programación, los sistemas, el cacharrear y todas estas cosas. Nos gustan los retos. Así que cuando viene el dueño y nos dice si no podríamos utilizar la tecnología Y en lugar de la X, que resulta que es muy cara, tendemos a decir cosas como "buenoooo siiii, si poneemos esto por aquí y esto por allá... igual funciona". Y lo peor es que es cierto, igual funciona, pero lo más probable es que no y en caso de que funcione seguramente lo hará peor y nos dará muchos más dolores de cabeza.

Otro patrón que comenta y que es muy habitual es el de los favores en las agendas. Y este si que le tiene que sonar a todos. Estás desarrollando contra requisitos imposibles, sabes que no llegas y se lo dices a tu jefe. Y tu jefe como es tan bueno te hace caso y te deja terminar dos meses después.... a cambio de añadir tres funcionalidades nuevas que otro cliente ha pedido. Simplemente genial. Ya sabes, si no te gusta una taza de caldo, pues te damos dos ;) ¿A alguien le suena?

Y el último, también genial y probablemente hiperconocido es la falacia del capital. Básicamente se simplifica a que hemos conseguido convencer al jefe para que nos compre nuestro nuevo y caro juguete: WebSphere, Oracle, WebLogic, SQLServer, lo que sea. Y ahora lo tendremos que usar, y vaya si lo tendremos que usar. Lo tendremos que usar para todo proyecto que salga de la compañía, porque como se nos ocurra hacer un diseño después de haber comprado ese producto en el que no aparezca su nombre, ya nos podemos preparar. "¿Qué no estás usando WebSphere para ese programa de mantenimiento de clientes? Ya lo puedes poner ahora mismo que hemos pagado mucho dinero por él." Y ya podemos ir pensando en como alojar todas las aplicaciones de la empresa en ese producto, porque con lo caro que es nadie se va a creer que una licencia sólo se puede utilizar para una o dos cosillas a la vez que si no la cosa ya no da para más :-)

No sé si os han pasado cosillas como estas en vuestras empresas, ¿alguién se anima a comentar sus experiencias?

Información sobre reporting engines en castellano

Argh... los clientes empiezan a pedir herramientas de reporting para construir sus informes. Menos mal que el fenomenal blog de Stratebi siempre está ahí para contarme todo lo que me pierdo en el mundo del Business Intelligence.

Hace una semana han publicado un tutorial de JasperIntelligence de 40 páginas que me ha venido de perlas para al menos conocer esta herramienta.

Y eso por no hablar de la comparativa que publicaron en Octubre de los reporting engines de Jasper Reports, BIRT y Pentaho. Indispensable.

Rendimiento en colleciones de datos en Java

Hubo una época en el rendimiento de las colecciones de datos, es decir java.util.Collections, era realmente penoso. Blogs, forums y portales de programación predicaban sobre la necesidad de optimizar su funcionamiento y muchos se veían obligados a migrar a terceras librerías para obtener clases que a la hora de iterar no fuesen pasando por todos los objetos null de una lista, o que no doblasen el tamaño cada vez que te pasabas del tamaño de la colección y todas estas cosas.

He estado haciendo una pequeña evaluación de estas librerías para confirmar lo que ya me suponia. Esa época de optimización necesaria ya ha pasado a la historia. Hay que reconocer que el rendimiento de las colecciones de datos tanto en el JDK 5 como en el JDK 6 es ahora muchísimo mejor, y las librerías que en otrora tenían algo que decir han pasado un poco desuso. La verdad, no creo que cuente ningún secreto, pero bueno es uno de estos tipos de test que tienes que hacer, al menos para asegurarte de que no te estas perdiendo algo bueno. Lo cierto es que desde hace varios años ya no se oye a ven los post de los creadores de estas librerías en los foros técnicos, lo que te sugiere que ellos mismos sabes que su trabajo ya ha finalizado.

Una de las librerías que he mirado es GNU Trove pero la verdad es que es no pasé ni siquiera de las primeras pruebas. El problema de esta librería es que no implementa las interfaces estándar como java.util.Map o java.util.Set y te fuerza a atarte a sus propias estructuras de datos. Así que nada, descartada (además cuando evalué oval, que te permite utilizar diferentes implementaciones de colecciones de datos ya vi que el rendimiento no era mejor que el de las clases del JDK).

La siguiente en evaluar fue Javolution que tiene una serie de colecciones de datos. Esa librería es interesante. En algunos tests, como por ejemplo al utilizar listas, el rendimiento puede llegar a ser unas 10 veces mayor que con las clases del JDK, mientras que en otros tests el rendimiento es claramente peor, como por ejemplo usando mapas. El problema de esta librería es que está orientada a pequeños dispositivos en el que operaciones como crear y liberar memoria son caras, y por lo tanto sigue un modelo de programación un poco peculiar. Por ejemplo, hace cosas como crear un pool de entradas que reutiliza para las diferentes colecciones de datos, así si tenemos un mapa en el que estamos continuamente colocando y eliminando objetos en lugar de crear nuevas entradas, se reutilizan las que hay en el pool. Sin duda inteligente, pero este tipo de cosas pueden ser bastante perjudiciales dependiendo de como funcione la aplicación, y en mi opinión sería un error el meterse a utilizar librerías que tienen ese funcionamiento tan peculiar.

Por último está Commons Collections. El rendimiento de esta librería es peor que el del JDK, y además no soporta genéricos lo que es un problema adicional. Aún así, la verdad es que el punto fuerte de esta librería ya no es el rendimiento si no más bien la cantidad de diferentes algoritmos y colecciones que tiene implementados, así que puede ser realmente útil para aprovechar cosas que no haya en el JDK.

En fin, mi conclusión es que ahora mismo no tiene ningún sentido ya el mirar como reemplazar colecciones de datos que vienen en el JDK. Eso era una tarea útil hace
quizás hace cinco años, pero ya no lo es. Sin embargo, hay que agradecerle a toda esta gente que allá por el 2000 ya se preocuparon de comenzar a ponerle las pilas a
los desarrolladores del JDK para que mejoraran el rendimiento. Si no hubiese gente quejándose y desarrollando implementaciones mejores probablemente no tendríamos
ahora unas colecciones de datos decentes.

Cuidado con los nombres de clases graciosos

¿Qué opinaríais si estuviéseis depurando una librería de un proveedor de terceros que estáis evaluando comprar y de pronto descubriéseis que algunas de las clases de su servidor comienzan con el prefijo de .... ACME !!? (ojo, hay empresas que se llaman así, pero este no es el caso)

Jejeje, parece una tontería, pero imaginaros mi cara cuando, estando ya muy escamado por la calidad de su implementación, me encuentro con que el depurador entra en clases como AcmeHashTable. A alguno que estaba a mi lado le iba mal. Claro, vete a saber, en cualquier momento va y te explota el servidor de aplicaciones ;)


En fin, que supongo que no está mal el limpiar un poco las librerías, sobre todo cuando se las vas a pasar a un cliente potencial. Lección que aprendo para el futuro, por si estoy del lado proveedor.

El algoritmo de Nagle

Uno de los temas recurrentes y sobre los que siempre hay que pensar en el entorno en el que me encuentro es el algoritmo de Nagle. Este algoritmo es una optimización de TCP/IP para evitar su la gestión de las redes. La idea es que si un sistema envía muchos paquetes pequeños (e.g. 1 byte) continuamente se está desperdiciando mucho espacio en el paquete TCP/IP y por lo tanto se puede congestionar mucho una red.

Para ello, Nagle, ideó un algoritmo mediante el cual sólo un paquete pequeño puede viajar por la red sin que se haya recibido un ACK. Esto significa que hasta que no se reciba un ACK se estarán acumulando paquetes dentro de un buffer. Cuando el ACK se recibe se envía de nuevo un paquete TCP/IP pero esta vez con muchos más datos ya que contendrá esos pequeños mensajes que se habían estado acumulando.

La idea es muy buena, pero a parte de los problemas que tiene este algoritmo con otra optimización llamada delayed ACKs y que se desarrolló en la misma época (es lo que tienen los diferentes grupos de trabajo sin comunicación entre ellos) resulta que este algoritmo te obliga irremediablemente a esperar por los ACKs.

Ahora supongamos que estamos haciendo streaming de datos en tiempo real. Imaginémonos que no es vital el tener la seguridad de que estos datos lleguen a su destino (es decir, no necesitamos ACK), pero sí que es vital el enviar estos datos lo más rápido que sea posible. Ejemplos de este tipo de escenarios pueden ser streaming de datos médicos o trading en mercados financieros en el que diferencias en milisegundos pueden suponer el ganar o perder mucho dinero.

Volviendo al ejemplo, imaginémonos que por cosas de la vida nuestro data center está en Madrid y nuestro cliente en Chicago. Esto, si le hacemos caso al visualizador de latencia de Akamai son unos 330 milisegundos (asumo que en round-trip). Eso son 165 milisegundos ir y otros tantos volver. Una cuenta fácil es que con el algoritmo de Nagle seremos capaces de enviar tres mensajes mientras que si en el nos vamos a los 6 mensajes por segundo. Si dentro de cada mensaje TCP/IP puedo enviar cotizaciones digamos 8 cotizaciones pues pasaría de poder mostrar unas 24 cotizaciones por segundo a unas 48. Una aumento considerable.

¿Cómo puedo deshabilitar el algoritmo de Nagle? Fácil, utilizando el atributo TCP_NODELAY presente en la mayoría de lenguajes. Los que utilizamos Java tenemos buenas y malas noticias. La mala es que por defecto no hay manera de deshabilitarlo a no ser que vayamos a gestionar nosotros mismos la comunicación de sockets (es decir, que utilizando URL.openConnection() nada de nada). La buena es que excelentes librerías Open Source como Apache Commons HTTPClient o Apache Mina nos permiten hacer esto y muchísimas más cosas y son siempre una mucho mejor elección que utilizar las librerías de Sun.

Vaya post me ha salido para un Domingo :) Pero bueno, es una de estas cosas que te interesa apuntar así que la he dejado por aquí para futura referencia y por si a alguien le es útil. Espero no haber aburrido, al menos mucho, a nadie :)

Algo de humor: MashUp Camp, Dublin

Un poquillo de humor nunca viene mal. Hace un mes se celebró en Dublin un MashUp Camp. Además creo que era el primero de Europa, y bueno hubo gente de Yahoo, de SalesForce, IBM, Reuters y todas estas cosas.

El caso es que se les ocurrió hacer un video saliendo a la calle y preguntándole a la gente si sabía lo que era un "MashUp". Me ha hecho mucha gracia porque representa Dublin por la noche en estado puro.





Tenéis el video en la Yahoo Developers Network.

10 formas de reducir la contención por bloqueos

En Thinking Paralell, Michael Suess publica un excelente artículo en el que comenta 10 formas para reducir la contención por bloqueos en programas concurrentes.

Me permito castellanizarlos aquí:

1. Proteger sólo los datos y no todo el código.


2. Evitar cálculos complejos y largos dentro de locks.


3. Evitar el utilizar un único lock para todos los elementos.


4. Utilizar las operaciones atómicas disponibles en numerosos lenguajes.


5. Utilizar estructuras de datos ya sincronizadas (y si es posible lock-free).


6. Utilizar read-write locks cuando sea posible. Muchos lenguajes disponen de este tipo de bloqueos.


7. Utilizar datos de sólo lectura siempre que sea posible.


8. Evitar pools de objetos.


9. Utilizar variables locales o aprovechar el almacenamiento local en hilos.


10. Evitar puntos calientes (e.g. variables compartidas que se llaman mucho).


11. Bonus: Utilizar un sistema de memoria transaccional.

La programación concurrente es compleja, de eso no hay duda. Algunos dirían que hasta da miedo :-) Pero bueno, todavía daba mucho más miedo hace años cuando en lenguajes como Java variables como volatile funcionaban como querían. Lo peor de la concurrencia en Java es que simplemente empezó a ser decente demasiado tarde, con el paquete java.util.concurrent de Java 5. ¿Por qué es tarde? Pues porque ahora mismo coges a muchos programadores y les preguntas el significado de las palabras synchronized, volatile o qué es un ThreadLocal y muchos no lo van a saber, pues cual puede ser el resultado de preguntar que es un ReadWriteLock o un AtomicInteger.

¿Culpa de los desarrolladores? No creo. Si el 90% de los libros sobre programación básica en Java no hablan de estas cosas y se quedan en Thread.start() y Thread.run() difícilmente vas a concienciar de la dificultad de la programación concurrente. (Hago aquí un inciso porque yo fuí de los de programación concurrente en C, pero supongo que ahora mismo se estará dando en Java así que quizás la situación no esté tan mal en este lenguaje).

De todos modos, yo me quedo con lo que comenta Brian Goetz, autor del excelente libro Java Concurrenty in Practice en los comentarios a la entrada, y es que estas medidas deberían aplicarse con mucho cuidado y únicamente cuando se compruebe que realmente existe un cuello de botella debido al uso indebido de bloqueos. El intentar aplicar estas reglas de buenas a primeras sería adentrarse dentro del mundo de la optimización prematura (que es siempre algo malo, pero que hay que diferenciar del diseño en busca de rendimiento como comentaba hace unos días).

Me iba a enrollar ahora comentando algunas de las entradas, pero es que tampoco creo que valga mucho la pena. El que se lea el libro de Brian Goetz, es que ya va a saber todo lo que necesita saber. Y aunque el libro está basado en Java, creo que es una buena lectura en general independientemente del lenguaje. Eso sí, mejor os dejo con una captura de pantalla que hice hace unos meses y de la que iba a hablar en un post a ver que os parece:



¿Qué representa? Pues es nada menos que un servidor WebLogic que de repente se va a un 100% de uso de la CPU como quien no quiere la cosa. ¿Qué malvado código puede crear ese efecto? ¿Quizás un EJB que está procesando todos nuestros proveedores? ¿Un malvado timer que ha saltado y está lanzando un proceso batch de esos qeu todos tememos? mmm Pues no. Un simple put() en un HashMap puede hacer eso, especialmente si tienes la mala suerte de que el HashMap esté compartido (ejem, malo malo) y dos threads se les ocurra hacer el put() al mismo tiempo (efecto conocido en HashMap), ya que en ese caso es muy probable que entren en un bucle infinito intentando insertar el elemento, que es justo lo que podéis ver en la imagen y que era exactamente lo que se estaba comiendo toda la CPU de un pedazo servidor.

Imaginaros que esto pase en producción. En fin, en este caso la solución es utilizar en su lugar un ConcurrentHashMap que garantiza un cierto grado de concurrencia (o también no compartir el HashMap :-) ), pero supongo que os dará una idea de lo peligrosas que pueden ser cosas que en un principio pueden parecer realmente inocentes.

Bueno, mientras tanto, yo todavía estoy con ganas de leer algo que leí en en el blog de Ferrán hace unos meses y que me dio mucha envidia.

Multi-tenancy: diseñando con la escalabilidad en mente

Me ha gustado mucho un artículo que un compañero me ha pasado sobre el concepto de multi-tenancy. Se podría definir como la habilidad para ubicar varios clientes dentro de la infrastructura de una aplicación. Por otra parte, también me ha gustado una entrada de Jose Manuel Suarez en su blog en la que habla de optimización vs. hardware. Pensándolo esta tarde, me he dado cuenta de que, aunque no lo parezca a simple vista, existe bastante relación entre ambas entradas.

Como Fred Chong comenta en su blog, conseguir multi-tenancy es un trabajo duro. Por ejemplo, supongamos que tenemos una aplicación empresarial relativamente típica con un par de servidores web, un par de servidores de aplicaciones y un par de bases de datos, y que decidimos hacer nosotros el hosting de la aplicación. Realizar el hosting de la aplicación es mucho más práctico para la empresa proveedora de software ya que evita muchos problemas como el despliegue o la gestión de parches de cliente, al tiempo que hace más fácil la automatización; sin embargo, al mismo tiempo añade mucho coste en cuanto a infraestructura.

Por ejemplo el caso anterior está bien para un único cliente, ¿pero qué pasa cuando tenemos 5 clientes? En ese caso ya empezamos a hablar de 10 servidores web, 10 servidores de aplicaciones y 10 bases de datos a gestionar, y eso siempre que algún cliente no exija sistemas de demostración en cuyo caso las cifras pueden crecer todavía más. Excluyendo la administración, esto plantea dos problemas principales: el coste del hardware y el coste de las licencias de todo el software que estemos utilizando (servidores de aplicaciones, sistemas de monitorización, motores especiales como por ej. sistemas de comunicación para entornos financieros, sistemas de mensajería, etc.). ¿Qué pasa si estos 5 clientes son pequeños y no compensa el mantener esta infraestructura para ellos?

Esta es una de las razones por las que en aplicaciones complejas la aproximación "slashdot" o "youtube" de añadir servidores no funciona demasiado bien, ya que el escenario es más complejo.



El diagrama de aquí arriba muestra las diferentes técnicas que pueden aliviar el problema de multi-tenancy. Las técnicas están ordenadas por densidad, siendo las de más arriba las que permiten compartir más clientes dentro de nuestra infrastructura, y las de más abajo las que menos clientes permiten compartir.

No voy a entrar demasiado en detalle en las diferentes técnicas, porque eso es otra historia, pero básicamente cada una de esas técnicas tiene un coste asociado. Ya sea en cuanto a necesitar soluciones propietarias, o ser complejo de mantener, o ser funcionalidades específicas de un sistema operativo. Por ejemplo, la virtualización es una solución excelente para solucionar el problema de multi-tenancy pero tiene el problema de que el número de máquinas virtuales que podremos alojar en un servidor físico es limitado y a mayores tenemos el coste de las licencias (o del mantenimiento) del sistema de virtualización que utilicemos.

Y bueno, entonces, ¿cómo se puede arreglar todo este embrollo?

La solución ideal es crear aplicaciones que puedan utilizar varios clientes a la vez. Si la aplicación es muy grande, entonces se debería dividir en diferentes módulos independientes entre sí y que pudiesen ser compartidos por diferentes clientes. Por ejemplo, un sistema de trading financiero podría tener por una parte en un servidor la gestión de las carteras de los diferentes traders, en otro servidor la gestión de las órdenes de compra y venta de todos estos traders, y en otro servidor la gestión de informes para los clientes y los bancos.

Esto es lo que Fred Chong llama "Shared Application Instance", el compartir porciones de una aplicación con diferentes clientes. Esta es la aproximación que permite la mayor densidad de tenancy en un sistema, y la que ofrece la mejor escalabilidad. En estos sistemas, denominados comúnmente no-homogéneos, es mucho más sencillo gestionar los recursos del sistema. Por ejemplo, si sabemos que la gestión de órdenes necesita más recursos que la generación de informes, podemos dedicar servidores más potentes a alojar el cluster del sistema de órdenes mientras que reservaremos servidores más modestos para el reporting.

El problema, y ahora es cuando vuelvo a enlazar con el post de Jose Manuel, es que migrar una aplicación existente para que pueda dividirse y servir a diferentes clientes es algo muy complejo y muy costoso si la aplicación no se ha diseñado desde un principio para ello. En muchos casos estaríamos ante un reto casi tan complejo como el tener que reimplementar la aplicación. Ahí está la importancia de diseñar y crear una arquitectura desde un principio pensando en la escalabilidad. La optimización prematura siempre es algo malo, pero no lo es sin embargo el diseño en busca de la escalabilidad y el rendimiento. El diseño en busca de escalabilidad puede que no de frutos en los primeros meses, puede que añada complejidad lógica en el sistema (por ejemplo con desacoplamiento de APIs y módulos, uso de sistemas de mensajería, etc.), pero a largo plazo, cuando el sistema crece, y cuando hay más clientes a los que servir, es cuando se ven realmente los beneficios.

Vaya ladrillo que me ha quedado. Felicidades si has sido capaz de llegar hasta aquí :-)

ApacheCon 07 y web frameworks

Haciendo mis lecturas diarias he descubierto que ya están disponibles las transparencias de la ApacheCon 07 que se celebró hace unos días. Se pueden descargar desde este enlace.

En InfoQ destacan la charla de Matt Raible en la que hace una comparativa de los diferentes frameworks web disponibles en estos momentos para el desarrollo de aplicaciones. Esta comparativa es la continuación de una mítica comparativa que el mismo autor realizó en 1994. Como pasa el tiempo.

Una de las curiosidades de la nueva charla de Matt es que consta de dos versiones. La primera fue la que envió para la conferencia (que creo que ya la había visto en alguna parte). La segunda versión es la que realmente presentó. El motivo para presentar una charla diferente es que en un inicio él pensaba hablar de frameworks que ha utilizado pero después se dio cuenta de que creaía que muchos de esos frameworks ya no tendrían mucho éxito en el futuro así que los eliminó y los sustituyó por otros más prometedores.

En particular se cayeron de la lista Stripes, Spring MVC y Tapestry (parece que los autores lo acosan en su blog :D). En fin, curiosidades aparte, los frameworks que compara son: Flex, Grails, GWT, Seam, Struts 2 y Wicket. ¿Será ese el futuro?

La lista de la verguenza: Top 100 Software vendors

Hoy no iba a postear más. Es sábado y con uno ya era suficiente. Sin embargo tras encontrar en Navegapolis un enlace al informe Truffle 2007 sobre el que informaba el blog de Sin Seguridad IT, pues no he podido evitar el abrir esta entrada.

Os invito a leer el informe. Se trata de las 100 empresas vendedoras de software en Europa con mayor facturación en el año 2006. ¿Cuántas empresas españolas creéis que hay? .... mmm .... Sí, seguro que algunos ya lo habéis adivinado: NINGUNA.

Hace meses hacía una pregunta abierta: ¿Dónde están las empresas de software en España?. Era una pregunta resultado a la locura "blogosférica" general por la que todo el mundo preguntaba por dónde estaban los programadores, sin darse cuenta que el problema real es muy diferente y mucho más grave.



Hector Montenegro Director de Tecnología de Microsoft Ibérica se hace un montón de preguntas interesantes en su blog acerca de este tema. Vale la pena leerlo.

En mi humilde opinión, y me voy a repetir porque es algo que ya comentaba en susodicho post sobre la falta de empresas, el problema está en la raiz, es decir, en como funciona el sector de software en España. El sector de IT en España está basado en la consultoría y los servicios mientras que otros países apuestan realmente por la innovación y el desarrollo. Sí. Las famosas siglas I+D que tanto se utilizan en España para vender proyectos pero que a la hora de la verdad nadie ve ni íes ni des por ninguna parte.

En nuestro país lamentablemente gustan mucho los proyectos llave en mano, la personalización para el cliente, el hacer dinero fácil sin pensar en generar productos reales. Muchas personas se están preguntando el por qué no se matricula la gente en las carreras de informática hoy en día. Sinceramente, hoy por hoy no sé si yo mismo me re-matricularía sabiendo que mi futuro va a estar en una empresa de servicios sub-contratado o tri-contratado y sabiendo que mi software no llegará a ver la luz nunca porque el proyecto ha fracasado, o que en el mejor de los casos lo se quedará ahí dándole utilidad a unas cuantas personas de un departamento.

Lanzo una pregunta a todos los que trabajan en consultoras y empresas de servicios. Investiguen un poco y escriban en un papel el nombre de los productos que se encuentran en el catálogo de software que sus empresas ofrecen al público. ¿Cuántos productos han salido? 0,1, ... 5, que más da. En fin, por algo son empresas de servicios, ¿no? Lo malo es que en España parece que es lo único que hay.

Yo sé que ahora me voy a meter en un terreno muy fangoso, pero un tema que me hace gracia es el del intrusismo. Cuando comento por aquí lo que pasa en España con este tema me miran como si les estuviese tomando el pelo. "Mmm... they want to have professional bodies. That's pretty weird.". Vamos, que no se lo pueden creer. Y es que yo no veo que en Europa haya semejante debate como el que hay en nuestro país. Pero claro, en estos paises se hace software, se fomenta a la economía exportando productos, se crean puestos de trabajos permanentes desarrollando software, y se puede estar haciendo software con 40 años porque es un trabajo muy reconocido y que da dinero.

Nosotros, mientras tanto, seguiremos peleándonos en lugar de buscar soluciones al problema real. Seguiremos vendiendo el pan de hoy sin preocuparnos en como fabricar un pan que dure más días. Y bueno, quizás algún día hasta puede que sólo los informáticos podamos firmar los proyectos llave en mano, así colaboraremos un poquito más para seguir en el top 999.

Reemplazando Flash con Applets y comparación de rendimiento con otras tecnologías

En las últimas jornadas Javaa las que asistí, uno de los temas recurrentes en las charlas que tenían que ver algo con el interfaz de usuario es el interés de Sun por resucitar a los Applets.

A pesar de que con las mejoras de rendimiento en los últimos JDKs cada vez es más común ver Applets en las páginas web, lo cierto es que ésta es una tecnología que tendría que haber tenido mucho más éxito del que ha tenido. Sun tuvo en su momento la llave para triunfar en la Web, pero me temo que no la aprovechó, mientras que otras compañías como Macromedia (y ahora Adobe) sí que supieron encontrar su hueco en el mercado. Sí, los Applets ahora van relativamente bien, pero todavía te puedes encontrar con muchos problemas molestos, incompatibilidades, y un sinfín de pequeñas cosillas que te hacen perder mucho el tiempo.

Por eso David Brackeen creó PulpCore, cuyo lema lo dice todo: "Java applets that don’t suck". Se trata de un motor de renderizado y animación 2D con licencia BSD y orientado a la creación de juegos para la Web y centrado en algo que Sun olvidó en su momento: el obtener una buena experiencia de usuario.



Lo mejor para comprender qué es Pulpcore es echarle un vistazo a las demos, en especial a Milpa, aunque hay varias interesantes. PulpCore está basado en un motor de escenas que permite crear animaciones muy al estilo Flash, pero aprovechando las ventajas de Java.

En bubblemark.com tienen un análisis de rendimiento de diversas tecnologías RIA. En mi PC Pulpcore realmente arrasa con unos 200 fps, mientras que los diferentes sabores de Flash y Java se quedan muy por detrás con menos de 50fps.

¿Qué os parece? A mi se me ocurren bastantes utilidades para esta librería, especialmente para aplicaciones Web 2.0

Historia sobre una aplicación en JRuby on Rails de Oracle

Hace poco Oracle anunció el lanzamiento de Oracle Mix, la que según afirman es la aplicación más grande desplegada con JRuby on Rails.

Ayer, Rich Manalang, escribía una entrada en el blog de desarrolladores de Oracle en la que relataba lo que ha sido el camino hasta tener esta aplicación en producción.

Rich explica como después del éxito de Connect, la red social de Oracle se pusieron a trabajar en una aplicación para la Oracle OpenWorld. Tenía que hacerse en seis semanas, la aprobaron y contrataron los servicios de ThoughtWorks que puso cuatro desarrolladores con experiencia.

La lectura es interesante, aunque probablemente la parte más jugosa es la del rendimiento. Me permito traducir.

Después de tener las máquinas preparadas comenzamos a hacer los primeros despliegues de JRuby. El rendimiento era terrible. Entre 20-40 req/sec. en un único servidor de aplicaciones. Parece que no había activado algunos de los parámetros de producción (parámetros estándar para despliegues ruby). Conseguí 80 req/sec. en un único servidor... mejor, pero no suficiente. Al mismo tiempo, Ola y el equipo de JRuby encontraron algunos cuellos de botella interesantes dentro del código de JRuby. En un día o dos, Ola y el equipo habían parcheado el código y estabamos ya funcionando sobre las 150-200 req/sec. Después de que el servidor se calentase un poco las cosas se pusieron realmente interesantes... los números subieron un montón (400-600 req/sec).

Para mi una de las conclusiones que saco es que a pesar del desarrollo rápido, estas tecnologías están un poco inmaduras para determinadas cosas. A fin de cuentas, el hardware no era malo del todo: 4 máquinas doble núcleo, con 12 Gb de RAM, la base de datos era Oracle 10g y es de esperar que estuviera bien configurada :-) y aún así parece que hubo que tunear bastante. Y no todo el mundo se puede permitir el tener 4 consultores de ThoughtWorks on-site durante seis semanas. ¡Que estos ingleses trabajan más que por el bocadillo!

Este proceso que relatan es el que se está viendo en la mayor parte de lenguajes dinámicos surgidos durante los últimos años. Al final, todo tiene su tiempo. Esta gente con recursos y posibilidades va haciendo despliegues importantes y con sus recursos encontrando cuellos de botella y aportando parches. Poco a poco los lenguajes se van haciendo maduros, las máquinas virtuales funcionarán cada vez mejor, y pasarán a ser de consumo público.

Ahora bien, supongo que después todo el mundo los empezará a utilizar, dejará de ser especial el trabajar en ellos, y habrá que buscarse otra cosa mejor ;-)

Notas sobre la arquitectura de Linkedin

Una de las sesiones más jugosas de la pasada QCon 2007 fue la que presentaba la arquitectura de Linkedin. He hecho un pequeño resumen de la información que se puede encontrar en la presentación de Jean-Luc Vaillant, CTO y cofundador de la web.

Pongo aquí algunas notas que se pueden extraer de las transparencias muy al estilo High Scalability.

• 16 millones de miembros. Más de 1 millón de nuevos miembros por mes. Teniendo en cuenta que la web salió al público en 2003 habrá que asumir que esa tendencia se produce en los últimos meses.


• 50% de miembros son de fuera de los Estados Unidos.


• 30% de los miembros acceden a su cuenta cada mes. Sería interesante saber un dato sobre miembros activos cada día.


• 180 empleados.


• Da beneficios desde el 2006. Este dato también es bastante interesante.



• Principalmente es código Java, y también algo de C++ y Ruby.


• El sistema de producción es Unix (Solaris), y el de desarrollo es Mac OS X


• Oracle 10g para bases de datos críticas. MySQL para el resto.


• Utilizan Spring, ActiveMQ, Tomcat, Jetty y Lucene.



• Los diferentes algoritmos sociales ejecutados no funcionan demasiado bien BD. La única forma de obtener un buen rendimiento es ejecutándolos en memoria.


• Las aplicaciones y los diferentes grafos en memoria se sincronizan con la base de datos utilizando un algoritmo propio (databus) implementado sobre funcionalidades propias de Oracle. Tuvieron problemas con otras aproximaciones tradicionales como JMS o multicast que derivaban en el problema de commit en dos fases.


• Ese databus lo han implementado sobre HTTP con balanceo de carga. Hay un pool de trabajadores que acceden a base de datos para no sobrecargarla con demasiadas peticiones. Ningún cliente accede directamente a la base de datos.


• El sistema de caché es aparentemente propio. No nombran ningún producto en concreto.


• Índices especializados para consultas concretas


• Los diferentes motores de grafos son entidades en si mismas. Tienen un servidor RPC por el que reciben peticiones, varios sistemas para ejecutar algoritmos, un motor de persistencia para almacenar datos en disco y una librería de acceso al databus.


• Problemas al implementar el patrón de bloqueo read/write. 100% CPU. Problema: si una lectura lleva demasiado tiempo, la escritura tiene que esperar y bloquea al resto de lecturas. La solución fue migrar a un algoritmo copy-on-write.


• Determinadas redes crecen demasiado. Solución: comprimirlas para poder seguir manteniéndolas en memoria.

Nota: Justo después de escribir esto, he visto que alguien ha escrito también sobre ello.

Transparencias de QCon San Francisco 2007

QCon celebró hace unos días un evento muy interesante en San Francisco y han sido tan amables de subir todas las charlas y ponerlas a disposición del público. Bueno, realmente las charlas aparecen con un candado al lado así que no sé si se supone que iban a tener contraseña. Las de la QCon 2007 de Londres estaban protegidas, pero el caso es que en esta ocasión se pueden descargar libremente, al menos por ahora.

Así que aprovechad si queréis porque hay algunas interesantes.

Transparencia ante ataques de seguridad

Ayer se me ocurrió entrar en el blog de la compañía con la que recientemente he contratado un servidor virtual. Esto de los blogs está ya tan extendido que en muchas compañías ya es práctica habitual. Nada más entrar me topo con esto:

A very important update for everyone! It appears that earlier today a third party gained access to our mywebpayment.com billing system. Upon determining that there might be a security breach we immediately terminated the access to everyone by disabling the billing website. At this time we’re still uncertain as to the total scope of the data they accessed. We are going to be as transparent as possible about what happened, what our plans are to correct it, and also how we plan to make sure that this never happens again.

Ups. Nudo en la garganta. La nota sigue:

To start with it appears that the breach was made through some malware/spyware installed on an employee’s office computer. His username and password for the billing system were stored in a document unencrypted on his computer. This information was used to access parts of our billing system that, in retrospect, should have been protected better.

Esos programas que nos descargamos por ahí...

We are certain that credit card numbers were not exposed, however we do know that a limited number of email addresses and plain text passwords were exposed. We highly recommend that if your PayPal password was the same as your Spry password that you immediately change it. While no paypal passwords are ever provided to us, it is likely that many users have chosen the same password for their paypal account and their account at Spry...

Vale. Yo he pagado con Paypal y mi password es diferente, así que aparentemente estoy a salvo, o eso espero.

El caso es que me ha llamado la atención que el ataque haya sido expuesto de forma tan abierta. Por mi parte un diez para ellos por hacer públicos este tipo de ataques, ya que a fin de cuentas seguro que nos ibamos a enterar por otros medios. Siempre es mejor ir con la verdad por delante. De este modo futuros clientes saben que en caso de haber algún problema se sabrá por el blog de la empresa. Ahora bien, tirón de orejas porque el blog no ha sustituido al email, al menos que yo sepa, y no me ha llegado ningún tipo de notificación al correo electrónico.

Quizás es que quieren aumentar las visitas de su blog :)

Caso friendster: ¿Fueron los programadores o los directivos?

En High Scalability siempre ponen noticias interesantes sobre rendimiento, escalabilidad, fiabilidad, etc. Pero hace unos días, publicaron la noticia de el fracaso de Friendster a la hora de escalar e indirectamente ha derivado en una discusión sobre quién tuvo la culpa del fracaso. ¿Quién no supo escalar, programadores o directivos?

El enlace de High Scalability nos lleva a una entrevista en Venture Beat en la que Jim Scheinman (ex-Friendster y ex-Bebo) comenta que Friendster falló a la hora de escalar. Más concretamente, que al ser una compañía pionera, afrontó muchos retos que no pudieron resolver debido a la inexperiencia y a la inhabilidad para escalar tecnológicamente.

For me, it basically came down to failed execution on the technology side — we had millions of Friendster members begging us to get the site working faster so they could log in and spend hours social networking with their friends. I remember coming in to the office for months reading thousands of customer service emails telling us that if we didn’t get our site working better soon, they’d be ‘forced to join’ a new social networking site that had just launched called MySpace…the rest is history.

Ahora bien, John Allspaw que trabajaba en el equipo técnico de Friendster en la época está en desacuerdo con Jim. John afirma que actores como que la gente tuviense que registrarse para simplemente ver páginas, o empeñarse en crear un cliente de mensajería instantánea en esa época y que nunca vio la luz, o calcular en tiempo real los 3 o 4 grados de confianza de tus amigos, fueron decisivos para estrangular tecnológicamente a una compañía y le permitiron escalar en lo que quería realmente la gente: utilizar su web.

- Once your social network was built on Friendster, there was little left to do, and there was a lot of floundering around guessing as to what could be added to the site to keep users engaged. An integrated IM platform was worked on in-house for months until finally scrapped as a lost cause. Then a couple months later, restarted the project as an outsourced/managed application. Features that were intended on harnessing the reputation/suggestions that were built-in to the social graph were only talked about, never materialized. (i.e., like Yelp!)

Mientras tanto, Jonathan Abrams, fundador de Friendster comentaba hace poco sus nuevas aventuras en Wired y también hablaba sobre la escalabilidad y Friendster. Jonathan hablaba en este caso sobre como en sus proyectos actuales están evitando hacer un uso excesivo de AJAX para no caer en errores del pasado:

There are some things on Socializr that look like Ajax, but actually are not. They're using JavaScript, they're providing a dynamic-feeling user interface, but they're actually not asynchronously requesting data from the server. Most of the data is sent in the initial page request, and then there's a more dynamic user experience, but we're not making a lot of asynchronous calls. And that's deliberate, to address scalability concerns, because of having gone through the Friendster experience.

Another thing is that I think some of the ways people are using Ajax now actually makes the user experience worse, rather than better. There are so many sites where you click on something and they use that thing where the background fades and then this window pops up in a sort of modal dialog, and it's completely intrusive. It poses an unnecessary delay, because you have to wait for this animation to happen that really adds no real value. It's just a trendy Ajax effect that everybody seems to be copying from each other. And, you know, that's not what our style is.

La verdad es que se pueden aprender muchas cosas tanto del éxito como del fracaso. Ahora bien, probablemetne andarse echándose las culpas unos a otros no sea lo más oportuno. Por los comentarios de las diferentes historias, me inclino a pensar que el problema en la época fue más bien de dirección que tecnológico, a fin de cuentas ya había empresas en esos momentos afrontando problemas similares de carga. ¿Vosotros qué creéis? Sea como sea está claro que debieron aceptar la oferta de 30 millones de dólares que en su momento hizo Google.

Patrones de acceso y las 10 mejores maneras de estropear la escalabilidad y fiabilidad de Java

Ayer estuve viendo el video que han publicado en Parleys de Cameron Purdy en la JavaOne 2007: "Top 10 Ways to Botch Enterprise Java Applications", y lo cierto es que es una charla muy recomendable. En la línea de la presentación que ya hiciera en la JavaOne del 2006 "Top ten ways to create a real J2EE disaster" y de la que ya hablara en mi abandonado blog en inglés (lagrimilla, sí, ... pero que verguenza de inglés).

Aquí hay un buen resumen de la charla así que me puedo ahorrar casi todos los comentarios. El caso es que el patrón número 10 me ha recordado mucho lo que hacemos, ya que es exactamente uno de los problemas que tenemos, y es de eso de lo que quería hablar. Se trata de la importancia de tener en cuenta los patrones de trabajo de una aplicación, es decir, que si uno simplemente asume que todos los datos son iguales y los trata por igual se puede llevar una sorpresa.

Como comenta en la transparencia 11, el negocio de Foreign Exchange se basa en la compra y venta de divisas. Sin embargo, la realidad es que la mayor parte de las operaciones se realizan sobre euros y dólares ya que es donde hay más volumen comercial. ¿Cómo afecta esto? Os pongo un ejemplo.Un sistema de Foreign Exchange normalmente tendrá un montón de órdenes en el sistema puestas por los traders para comprar y vender, ganar posiciones o retirarse. Esas órdenes se procesan en tiempo real con cada latido del sistema con lo que se genera tal enorme carga de CPU que se ha de distribuir la evaluación entre diferentes nodos de un cluster.

Ahora bien, si alguien que no conoce el negocio se pone a diseñar el sistema puede decidir que la evaluación de cada par de divisas se haga en un nodo del cluster. La consecuencia es que el 40% de la CPU la consumirá una única máquina que será la que evalue el par EUR/USD, mientras que a lo mejor otras 20 máquinas están consumiendo el otro 60% del volumen del mercado evaluando órdenes para divisas que no son tan utilizadas.

No me enrollo más. La charla son 50 minutillos y la verdad es que vale la pena.

Dryad, la alternativa a MapReduce de Microsoft

En un comentario a la entrada anterior sobre GigaSpaces, Diego apunta que las arquitecturas existentes para trabajo en grid son todavía insuficientes por ser demasiado explícitas obligando a las compañías a invertir mucho tiempo en gestionar algoritmos de computación distribuida.

Parece que lo mismo pensaron en Microsoft cuando estaban diseñando Dryad, una abstracción creada sobre los fundamentos del álgebra relacional y el algoritmo Map and Reduce de Google y que permite la ejecución distribuida de grafos de trabajos en clusters. Ellos explican mejor lo que hace:


Dryad is quite expressive. It completely subsumes other computation frameworks, such as Google's map-reduce, or the relational algebra. Moreover, Dryad handles job creation and management, resource management, job monitoring and visualization, fault tolerance, re-execution, scheduling, and accounting.

La idea del framework es que el programador se dedique simplemente a preparar el grafo de trabajos y que el cluster Dryad haga el resto. Lo interesantes de Dryad son las abstracciones que ofrece. Parece que es capaz por ejemplo de ejecutar el mismo trabajo en varios nodos y quedarse con la salida del que acaba más rápido, o reejecutar un trabajo si se produce algún error, etc. Uno de los ejemplos que ponen es como integraron Dryad con SQLServer para ejecutar los planes de las queries de manera distribuida en un cluster Dryad.

Michael Isard de Microsoft Research dio una charla en Google bastante interesante y en la que explica como funciona el framework. Por cierto, no deja de ser curioso esto de que los ingenieros de Microsoft den charlas en Google :)

Si os interesa entrar en más detalle también tienen esta publicación: Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks

GigaSpaces ofrece gratis su plataforma a Startups

Hoy me he sorprendido leyendo que GigaSpaces ha decidido ofrecer su plataforma XAP (Xtreme Application Platform) a Startups por el módico precio de ... 0€!!! tal como se puede leer en el FAQ del recientemente lanzado GigaSpaces Start-up Program. Nati Shalom, fundador de la compañía y Geva Perry también hablan de este programa.

Wow! La verdad es que este anuncio sí que es sorprendente. Pocas veces una empresa decide regalar sus productos sin ningún tipo de restricción ni de funcionalidades ni temporal, para uso en producción, en cualquier número de CPUs y en cualquier número de servidores, etc. Parece que no hay trampa ni cartón. Bueno, sí, hay una, la empresa para optar a esta oferta no puede haber ganado más de 5 millones de euros en los 12 meses antes de aplicar a esta oferta. ¿Y que pasa en cuanto la empresa llega a los 5 millones de euros? Pues nada. Santa Rita Rita, lo que se da no se quita. Una vez entregada la licencia ésta dura de por vida y tanto da los beneficios que tenga la Startup en un futuro.

Lo único problemático es que GigaSpaces se reserva el derecho a aceptar o no a una empresa dentro de este programa. Pero de todos modos esta tiene que ser una opción muy, pero que muy atractiva para muchísimas compañías que estén empezando. Yo, desde luego si tuviese una Startup no perdería esta oportunidad. GigaSpaces es un producto que se está utilizando hoy por hoy en muchísimos sistemas que requieren enormes cargas de computación y prácticamente es ubicuo en los grandes bancos de inversión y compañías dedicadas al software financiero.

Ahora bien, una vez que uno se recupera del "shock" de ver como una compañía como GigaSpaces decide regalar su producto, uno se pregunta ¿por qué? Se me ocurren varias ideas. Por una parte, GigaSpaces propone un modelo de computación radicalmente diferente a J2EE, que aunque no es algo que sea completamente incompatible, lo cierto es que siempre añade un grado de complejidad especialmente a la hora de integrarse con todos los sistemas J2EE existentes. Quizás la adoptación del producto no sea la esperada y con este sistema esperan adquirir más adeptos. La otra idea que se me ocurre es que Oracle esté regalando Tangosol y que los clientes no compren GigaSpaces porque Oracle ya les da gratis algo similar. Esto no sé si será muy probable porque la adquisión de Tangosol ha sido demasiado reciente y ya se sabe que estas cosas requieren un cierto tiempo de adaptación.

Pero vaya, sea la razón que sea, pues que es una ganga señores. ¿Alguien que vaya pedir una licencia?

IJTC 2007, día 3

Bueno, este es el último post de esta serie sobre la Irish Java Technology Conference, un poco con retraso por eso del fin de semana.

La primera ponencia a la que fuí el pasado Viernes fue la de Richard Bair sobre "Filthy Rich Clients". La ponencia fue muy interesante. Es la misma que presentaron Chet Haase y Romain Guy en la JavaOne 2007 en la que presentaban montones de trucos para incrementar el rendimiento de Swing y que se pueden encontrar también en el libro que lleva el mismo nombre. Hubo montones de demos y efectos especiales, y también mucho código fuente explicando todos los trucos. La principal conclusión que saqué es que está claro que una empresa necesita una o dos personas que se dediquen exclusivamente a estas cosas ya que la diferencia entre aplicaciones que tengan estos pluses de efectos y rendimiento y las que no lo tienen es simplemente abismal.

A continuación pude disfrutar de la charla de James Strachan, "Enterprise Messaging with ActiveMQ". Me encanta este hombre. Sus ponencias son realmente amenas. ActiveMQ realmente es un producto muy interesante y ofrece montones de características que suman valor añadido a una solución JMS. Muy buena.

El siguiente ponente fue Dejan Bosanac, el autor del libro Scripting in Java y que habló de "Scripting with Balance in Design and Performance". Bueno, o al menos lo intentó, porque realmente hubo poco scripting y menos balance, design y performance. Una pena porque el tema era interesante.

Finalmente, acabé las sesiones con Ronan Gerarthy de Microsoft Ireland que presentaba una ponencia titulada "Application lifecycle management in a Java/.NET environment" y que también resultó bastante interesante. No era sobre Microsoft en sí misma sino como era el proceso que venían siguiendo y las herramientas que utilizaban.

Nos explicó como usaban el Team Foundation Server de Microsoft para gestionar el ciclo de vida de los proyectos y como se podían utilizar diferentes herramientas como Microsoft Project, o Microsof Excel para actualizar la información de los proyectos almacenada en TFS. Finalmente mostró como los desarrolladores, incluso desde Java podían utilizar Teamprise para mantener al día toda la información de su trabajo accediendo al TFS desde Eclipse con esta herramienta.

La ventaja fundamental era que se podían utilizar las herramientas que la gente estaba más acostumbrada a utilizar (PMs, BAs, desarrolladores, etc.) y que después con el SQL Server instalado en TFS y sus funcionalidades de Data WareHouse se obtenían informes mucho más indicativos de la salud de los proyectos y que permitían diagnosticar rápidamente el estado de los mismos.

Y todo esto fue lo del último día. En general creo que ha sido un evento bueno y aunque se podían mejorar algunas cosas pues ha valido mucho la pena. Habrá que ver el año que viene que tal.

IJTC 2007, día 2

Hoy estoy un poco de malas porque tenía un montón de notas cogidas y perdí el bloc de notas. Y claro, como es un cine cuando fuí a recogerlo ya habían pasado las de la limpieza y no había rastro de él. En fin, que mejor excusa para hacer este resumen.

El día de hoy ha estado realmente bien. Un poco de falta de organización, pero que demonios, las charlas fueron muy interesantes y además había descanso después de cada charla con comida y bebida a cuenta de la organización, así que nada de lo que quejarse. La verdad es que todas las charlas a las que he ido me han gustado, y aún así me quedaron un par de charlas a las que me habría gustado ir. Pero es que había tres tracks diferentes con cinco charlas cada una y no se podía ir a todo :(

Comencé el día escuchando a Simon Cook con su "Java Update". Era la primera de la mañana y no había mucha gente, pero estuvo interesante de todos modos. Trató las novedades de Java 6 y Java 7, y lo más interesante para mi fue los últimos 10 minutos que los dedicó a petición de la sala a hablar de Java Realtime. No hay mucho que destacar. Más o menos la charla se centró en lo mismo que comentaba ayer, es decir la presencia cada vez más destacada de los lenguajes de scripting, y el convencimiento de que la máquina virtual ejecutará diferentes lenguajes en el futuro.

También habló bastante sobre el consumer JRE y explicó con detalle como funcionará. Como muchos ya sabréis el nuevo plugin carga las clases bajo demanda; se carga un núcleo principal y después el plugin va cargando las clases que no encuentra con lo que se consigue un tiempo de lanzamiento mucho mejor. Eso sí, un "Hola mundo" ocupa 1Mb. Al final de la charla le comenté los problemas que habíamos tenido con los applets y parece que esta carga bajo demanda no debería afectar. Otra cosa interesante es la nueva API de despliegue. Es una librería de javascript que permite especificar exactamente las versiones del JRE que queremos utilizar para cada aplicación en concreto.

La siguiente charla a la que fuí fue la de Richard Bair. Realmente una persona muy simpática que hizo la charla muy amena. Estuvo hablando sobre el consumer JRE, nuevamente protagonista, pero también sobre Java 2D y JavaFX. Mostró un montón de demos y también algo de código JavaFX que realmente promete. Parte de su charla se centró en resaltar que los applets pueden tener una nueva oportunidad con JavaFX. Ya que a pesar que se supone que con Java 6 la experiencia es mucho mejor pues con Java FX se intentará disponer de APIs que realmente se echan de menos para competir con flash como son un buen soporte de SVG, facilidad de uso de Java 2D y sobre todo librerías para tratamientos de media, en especial videos. Una de las notas interesantes es que el API de video se está diseñando ya especialmente pensada sobre JavaFX como un requisito fundamental, y que sólo en una versión posterior se verá como integrarla mejor con aplicaciones normales.

La tercera charla fue la de Guillaume Laforge sobre Groovy. Guillaume explicó los fundamentos de este lenguaje y las ventajas de que funciona directamente sobre la máquina virtual como el poder utilizarlo como motor de scripting para reglas, o el mezclar objetos Java y Groovy sin ningún límite, o el utilizar en Java features que todavía no están ni planeadas para el futuro, y este tipo de cosas. También se paró un poco en las desventajas como la pérdida de rendimiento.

Fue interesante uno de los casos de éxito que comentó, Mutual of Omaha, una empresa del Fortune 500 y en la que implantaron un motor basado en Groovy y en el que se desplegaron más de 50.000 líneas de código Groovy. Lo más interesante es que en el despliegue de código participaron tanto desarrolladores principiantes, como expertos, como, y he aquí lo interesante, personas que no tenían ni idea de programar. Casos como éste parecen demostrar, al menos en teoría, la utilidad de este lenguaje para la creación de DSLs y su capacidad de ser utilizados por no-programadores. En Internet buscando el nombre de la empresa, que no me acordaba, he encontrado otro listado con casos de éxito de Groovy.

La cuarta charla fue la de Stephen Farrell que se llamaba "Delivering Scalable, Lighweight Mobile Java technology to Millions of Users". Esta fue interesantísima. Stephen nos contó como trabajan en NewBay y nos habló del reto que era proporcionar contenido a millones de móviles y sobrevivir en el intento. Básicamente, esta compañía se dedica a almacenar, gestionar y proporcionar acceso, a modo de aplicaciones sencillas como blogs, a imágenes, videos, SMSs, llamadas, etc., y cualquier tipo de contenido que los usuarios pueden enviar a sus proveedores.

Lo que hace especial a estos escenarios es que conforme las redes mejoran, y los fabricantes de móviles añaden megapixels y megapixels, los retos aumentan. Hasta nos comentó que internamente manejan la medida de "sh1tabyte" que viene a significar "a shit a load of bytes" :-) Su stack se basa en Open Source y Java: Lucene, Hibernate, Spring Web Flow, Struts, SwiftMQ, JMagick, etc. y nos explicó algunos de los trucos que utilizan como evitar el almacenar estado, el desplegar diferentes funcionalidades de trabajo de imágenes en diferentes servidores, etc. Realmente muy interesante.

Y por último vi a James Strachan hablando sobre Apache Camel. Espectacular ponente. Realmente lo hizo muy bien, y su charla fue muy amena. Puedo decir que entré sin saber realmente lo que era Apache Camel y que ¡salí convencido de querer utilizarlo! ¿Alguien lo ha utilizado? Porque en serio, parece un API espectacular. En teoría es una implementación de los patrones del libro Enterprise Integration Patterns construida sobre Spring, y compatible con un montón de sistemas diferentes.

Creo que Apache Camel se merece uno, dos, o tres post en si mismo. La idea de definir tener todos esos endpoints y definir un bean en Spring (o una línea de código Java) para copiar objetos de una cola a un fichero; leer datos de un tópico, transformarlos con JAXB y pasar volcar esos objetos a base de datos; o leer datos de IBM MQSeries, transformarlos a javabeans, convertir eso en texto con freemarker y enviarlo por email, y todo ello definirlo en una única línea de código o en un par de líneas de configuración XML es simplemente demasiado tentador como para no echarle un vistazo. Realmente me dejó impactado.

En fin, que me parece que ha sido un día muy productivo. Salgo con varias ideas interesantes que me gustaría probar. A ver si el día de mañana es también productivo en cuanto a ideas.

IJTC 2007, día 1

Ayer fue el primer día de la Irish Java Technology Conference, y aunque no puedo decir que haya estado muy bien, tampoco ha estado muy mal (sabéis que soy gallego, ¿no?).

Uno de los aspectos negativos (o no, según como se mire) es que se notaba que es un evento organizado por aficionados. El sitio no acompaña mucho para un evento de este sitio, un cine, aunque hay que decir que las salas son enormes y con muy buen sonido. Sin embargo, claro, los stans están en unos sofás, la gente que va al cine está por el medio, y todas estas cosas. Kudos de todos modos para la organización por ofrecer consumiciones gratis ;-)

Respecto a las charlas, pues me esperaba un poco más. Primero fue Joel Spolsky que era al que yo quería ver, pero resulta que al final volvió a dar la charla que ya había visto en el 2006. Eso sí, estaba actualizada. En lugar de poner de ejemplos a Angelina Jolie y Brad Pitt ponía a David y Victoria Beckham; en lugar de comparar un iPod con un Creative Zen, comparaba su teléfono (no recuerdo la marca) con un iPhone y volvía a poner el ejemplo de tener menos funcionalidad y de que el iPhone no tiene batería. Mismas fotos, misma música, mismos videos, ... Una pena, para mi claro, porque otra gente sí la disfrutó.

Finalmente hubo un panel bastante interesante pero que se hizo un poco largo. Se sacaron a la mesa varios puntos como la ausencia de soporte de Java en los últimos lanzamientos de Apple, los lenguajes de scripts, la facilidad de uso de la plataforma, vamos más o menos lo típico. El tono de fondo fue un poco crítico, que más o menos es lo que estamos ya acostumbrados en los últimos años.

Yo me quedaría especialmente con un punto que sacó Shaun Smith de Oracle y es que la gente ahora sale del colegio o de la Universidad y prefiere hacer cosas en otros lenguajes como Ruby, PHP, Python que en Java; que hay ciclos en los lenguajes y que poco a poco éstos se hacen más y más complejos dificultando mucho la entrada de las nuevas generaciones que como consecuencia migran hacia lenguajes más sencillos (e.g. Ruby), y que es algo que ya pasó en el pasado y que parece que está pasando ahora mismo. Todo esto derivó un poco en recalcar que en un futuro la plataforma evolucionará hasta permitir la ejecución de lenguajes más sencillos de manera nativa en la JVM de forma que se pueda aprovechar los billones de líneas de código existentes pero utilizando lenguajes más sencillos y productivos.

A ver como va el día de hoy.

Amazon S3 en Europa, 10 millones de objetos y algunas notas

Leyendo el blog de Diego Parrilla me entero de que Werner Vogels, CTO de amazon, ha anunciado que ya es posible contratar los servicios de S3 usando servidores que estén en Europa. Buenas noticias para todos los negocios que estaban ya utilizando S3 y que tendrán un buen empujón a sus estadísticas de rendimiento y latencia (suponiendo que se pueda migrar fácilmente de USA a Europa si ya eres cliente, algo que es de esperar), y también para todo el que planease utilizar los servicios de S3 para aplicaciones orientadas al mercado europeo.

No hay duda que los servicios de Amazon están siendo un éxito. Ayer leía que ya hay más de 10 billones de objetos almacenados en su servicio S3, cifra realmente impresionante y que ya citó Mike Culver en la charla que dio en Dublin hace una semana.

John O'Shea tiene un muy buen conjunto de notas sobre esta charla y en las que se pueden leer algunas curiosidades como que las imágenes de sus servicios están basadas en Fedora 4, que el servicio de Flexible Payment Service sólo disponible en USA lo estará también en Europa en un futuro y que Amazon S3 no coloca automáticamente las cabeceras de caché (ETag, Last-Modified), algo un poco "dodgy" como dirían por aquí.

OpenSocial, ¿lanzamiento prematuro?

Tras el anuncio de OpenSocial y los primeros alagos no han tardado en aparecer las críticas debido a la falta de seguridad de la API. Techcrunch ya anunciaba que habían hackeado la primera aplicación en 45 minutos, y hoy vuelven a anunciar otro hack más.

En un artículo en RegDeveloper critican también la falta de seguridad de la plataforma y citan para ello varias referencias, además de citar a la plataforma OpenQabal que pretende hacer lo mismo que OpenSocial y que ya había sido anunciada con anterioridad aunque evidentemente sin el mismo impacto publicitario.

A veces los lanzamientos dirigidos por acciones de la competencia (se rumorea que el lanzamiento de OpenSocial se ha acelerado debido al golpe de efecto de Microsoft con Facebook) pueden salir mal. ¿Será el caso de Google? Yo no lo sé, pero me da a mi que Google está por encima del bien y del mal en cuanto a todo esto.

Sobre feeds y la protección de contenidos

Hoy, no recuerdo bien como he llegado a un producto que me ha llamado la atención. Se trata de Attributor un producto que rastrea Internet buscando violaciones de contenido, es decir, sitios que agregan directamente tus feeds buscando sacar un beneficio monetario, personas que copian tus artículos y los publican como si los hubieran hecho ellos, videos o imágenes utilizados sin permiso, y todo este tipo de cosas.

Evidentemente todos queremos proteger nuestros contenidos, especialmente si nos ha costado bastante trabajo el generarlos. Por cierto, que esto me recuerda una anécdota en la que un amigo me alertó de que alguien había publicado un artículo en la revista de una empresa bastante importante muy parecido a un artículo que publicamos yo y Alberto hace ya demasiado tiempo (por cierto, fenomenal cambio de look en jh, pero es una pena que mucho del contenido antiguo se haya perdido). Investigando un poco me encontré que esta persona había copiado y pegado literalmente partes del artículo montando un collage al que le había puesto su nombre.

Pereo en fin, eso es otra historia. El caso es que al leer en este producto que Reuters parece que lo va a utilizar me ha recordado lo sensibles que son estas compañías con sus servicios y las oportunidades de negocio que pueden surgir en torno a ello.

Más concretamente, en las últimas semanas he comprobado en mi propia piel las pocas facilidades que te ofrecen estas compañías a la hora de proporcionarte acceso al contenido que generan. Uno que es inocente al principio piensa, "nada, acceso por RSS y listo". Pues no. Cualquier cosa menos soluciones sencillas: autenticación, bloqueo de IPs que puedan acceder al contenido, construcción de proxies para desplegar el contenido utilizando un API propietaria que prevenga el convertirse en hub de la información de estas compañías.

Más o menos eso ha sido con lo que me he encontrado estas últimas semanas, y la verdad es que parece que hay por ahí un hueco en el mercado, o al menos dentro de los feeds para mercados financieros en los que es realmente importante el ser el primero en obtener la información para obtener una ventaja competitiva. La mayor parte de servidores de feeds disponibles del mercado parten de un supuesto "optimista" que es que "todo el contenido es público", así que podría haber por ahí un hueco para un servidor seguro, con encriptación, certificados, firmas, autenticación, APIs, bloqueos, etc. Me da la impresiónás de alguna compañía estaría seguramente interesada, tanto proveedores de noticias como clientes de estos proveedores.

Ahí queda la idea por si alguien se anima :-) , aunque quizás ya conozcáis algún producto similar....

Una razón algo más técnica para no escribir métodos largos

Hoy en día creo que más o menos todo el mundo tiene claro que escribir métodos muy largos es una mala práctica. Nos lo dicen en la universidad, nos lo dicen en los libros de programación, de ingeniería del software, de patrones o de refactorización. Los paquetes de métricas y de detección estática de errores nos avisan de que nuestros métodos son demasiado largos y el jefe nos echará una buena bronca si ve que hacemos un método de 5.000 líneas.

Aún así, cuando uno está programando siempre hay esos momentos en que se siente un poco vago con algún método al que va añadiendo cosas y cosas, porque total, estamos haciendo sólo un boceto, ¿no? El problema es que esos bocetos se convierten en la versión definitiva (doy fe, que tengo un par de métodos grandes por ahí que verguenza me dan) y ahí ha quedado. Pero bueno, funciona, ¿no?. Y no lo va a tocar nadie nunca jamás de los jamases, ¿no?, ¿qué hay de malo entonces?. Pues sí, incluso creyéndonos que nadie verá ese código nunca, hay algo que puede ser malo:

Hoy en día los lenguajes populares se ejecutan en máquinas virtuales. Estas máquinas virtuales disponen de optimizadores que traducen el bytecode de nuestros programas en código máquina, pero que además realizan numerosas optimizaciones sobre el mismo para obtener mucho más rendimiento. Estas optimizaciones no sólo se limitan a reordenaciones, inlining y todas estas cosas sino que en algunos lenguajes como Java (no sé si en otros, supongo que sí) se almacenan mapas de objetos en los que se especifican donde se encuentran los objetos a los que apuntan las referencias: la referencia A está en un registro, la referencia B está en la pila, etc.

Dicha información se utiliza durante la recolección de basura para acelerar la ejecución. Si no se dipone de esos mapas de objetos en el momento de la recolección, el recolector los tendrá que crear por si mismo. Para crear estos mapas, el recolector trata de simular la ejecución del método en relación a la posición de la referencia que se pretende recolectar. A métodos más grandes, simulaciones más complejas. Por cierto, que además la simulación depende de en que línea salte la GC así que aunque los mapas se guardan, ésto no sirve de mucho si el método es grande.

¿Y qué tiene que ver esto con el tamaño de los métodos? Pues resulta que Java tiene un límite para el tamaño de los métodos a los que el JIT aplicará optimizaciones. Si los métodos sobrepasan ese límite no pasarán por el JIT, y por lo tanto estos mapas de objetos no se generarán, y por lo tanto la recolección de basura será mucho más larga de lo que debería ser. Más concretamente el límite son 8000 bytes de bytecode. Para deshabilitar este límite en la máquina virtual de Sun, se puede usar la opción "-XX:-DontCompileHugeMethods". Pero ojo, esto no es una buena idea ya que lo más probable es que el JIT también sufra a la hora de optimizar, a fin de cuentas si el límite lo han puesto así será por algo. Así que mejor refactorizar y hacer más métodos y más pequeños.

Bueno, ahora igual he engañado a alguno que estará pensando. ¡Qué listo es Martín, cuanto sabe! Pues no. Todo esto no me lo he encontrado, ni lo he vivido, ni nada de nada. No es más que un resumen, bueno más bien una traducción porque me ha quedado bastante largo, de lo que cuenta el genial Jon Masamitsu en su blog, en el que ha publicado una entrada en la que explica algunas experiencias que le han pasado con clientes, relacionadas con parámetros raros de la máquina virtual. Entre estas experiencias está la de un cliente que veía que los tiempos de GC eran enormes y que no sabía por que, pero que de pronto descubren que comentando el código los tiempos de GC son mucho menores.

Pues ya sabéis, ahroa si alguna vez habláis con alguien sobre esto de los métodos largos, y os dice que eso de la refactorización no son más que chorradas, os podéis sacar de la manga esta explicación que es de las de dejar con la boca abierta.

Los sin sentidos de VMWare respecto al Open Source

O quizás debiera haber titulado este post "Los sin sentidos de Diane Greene...". Dian Greene es la CEO de VMWare y que durante estos dos últimos días ha recibido feroces críticas de The Register a raiz de una entrevista que mantuvieron con ella recientemente.

En la entrevista la dejan fina. Pero, en una entrada de hoy mismo, tampoco se quedan cortos. VMWare es ya la quinta empresa de software más valiosa del mundo, (se excluye IBM y Google) al menos siguiendo las valoraciones de la bolsa de Nueva York, y tras dos meses en la bolsa ha roto toda las expectativas y su capitalización en mercado ya es de 38 mil millones de dólares.

Pero parece ser que el éxito lleva a la extravagancia (tener una cascada en la sala de reuniones parece suficientemente extravagante) y que los medios dudan de la capacidad de Diane para dirigir la compañía por su falta de diplomacia y de saber estar ante los medios.

Y es que la CEO de VMWare no se corta a la hora de atacar a sus competidores y en especial de despreciar al Open Source con sus últimas declaraciones:

"What we want to do is fund ourselves to be able to build new stuff. If you're purely open source, there is no way you can do new stuff."

Parece que a pesar de ser la niña bonita de Wall Street, VMWare tiene miedo de Xen, compañía que arrasa en el mundo de los servidores virtuales y que poco a poco, y sin hacer tanto ruido se está haciendo con parte del mercado. Como resaltan en la columna de opinión que destacaba anteriormente, lo cierto es que VMWare está actualmente en una posición en la que no tiene que hacerle guiños a nadie, pero ¿es realmente necesario embarcarse en este tipo de luchas?

IJTC 2007 en Dublin

Por fin hay un evento importante sobre IT en Dublin, porque han sido dos años bastante escasillos.

Se trata el IJTC 2007. Un evento Java organizado por el grupo de usuarios de Java de Dublin y al que aunque muchos de los participantes son locales sí que vienen algunas personas conocidsa como Joel Spolsky (Fog Creek), James Strachan (Apache), Emmanuel Bernard (Hibernate), Guillaume Laforge (Groovy) o Mark Proctor (Drools).

Se trata de un evento de pago, aunque no demasiado caro. Unos 190 euros online. No está mal para tres días de conferencias y una agenda movida. Una de las cosas más curiosas es que el evento se va a celebrar en un cine. El formato de las salas es muy bueno para este tipo de eventos, pero tengo curiosidad por saber si han dejado sin cine a toda la zona (bastante céntrica y unos cines muy populares) o si los asistentes estarán mezclados con adolescentes cargados de palomitas y gominolas.

Bueno, esperemos que haya más iniciativas como esta.

La típica discusión sobre escalabilidad en la web: Java vs. php, perl, ruby, etc...

La verdad es que el título de esta entrada no es demasiado original y simplemente viene a recoger lo que en mi opinión ha sido uno de los debates del mes en algunos de los sitios web que visito. El que empezó todo el lio fue Nati Shalom, CEO de GigaSpaces (de la que ya hablaba el otro día), que publicó un incendiario post con el título Why most large-scale Web sites are not written in Java.

Bueno, está claro que se trataba del típico post que iba a desencadenar una ida y venida de opiniones y en su momento no quise hablar de ello, pero creo que ahora es un buen momento. Y es que me parece que a raiz de este post pues ha surgido mucha información que hoy han recopilado en InfoQ. Concretamente, el post que se puede leer en Artima es bastante interesante y saca diferentes puntos clave dentro de toda esta historia como son:

• Muchos sitios web "high-scale" corren sobre Java. Ejemplos son ebay o amazon.


• Lenguajes como php, perl, ruby permiten crear rápido aplicaciones, y en la web el ser el primero es muy importante.


• Hay una gran diferencia entre las aplicaciones orientadas a la web y otro tipo de aplicaciones orientadas más al mundo de la empresa. Los requisitos son diferentes y como es de esperar los lenguajes escogidos serán diferentes. eBay no tiene los mismos requisitos que Facebook ni éste los de la Wikipedia. Un martillo no quita tornillos y un desatornillador no clava clavos (y si lo hace, lo hará peor).


• Cuando se lee algo hay que tener en cuenta los intereses del que lo escribe. Pongo esto por las contestaciones de Cameron Purdy que parecen sacar a la luz algo que no se ha hablado y es el interes de GigaSpaces por promocionar sus soluciones.

No sé si vosotros opináis lo mismo, pero personalmente con este tipo de discusiones a mi me resulta más interesante el resumen de los comentarios que la discusión en si misma, que ya se sabe de antemano que no tiene mucho sentido.