Hadoop gana competición de ordenación

El equipo de Yahoo! ha ganado la competencia anual de ordenación (sorting) de terabyte llamada Daytona. Lo relevante de este resultado es que lo han logrado usando Hadoop, la librería opensource java que implementa MapReduce.

Esta competición que se celebra desde 1998 (en la categoría Terabyte) nunca había sido ganada por un proyecto opensource ni por uno java. Vamos que con eso de que java es lento, seguro que hubo un error en el benchmark ;-) .

Este bechmark fue creado en 1998 por Jim Gray y especifica los datos de entrada (1 Terabyte) que deben ser correctamente ordenados y escritos a disco. Yahoo! ganó la competición completando la tarea en 209 segundos, para ponerlo en perspectiva el ganador del año pasado lo logró en 297 segundos,

El clúster usado por el equipo de Yahoo! constó de:

• 910 nodos
• 4 dual core Xeons @ 2.0ghz por nodo
• 4 discos SATA por nodo
• 8G RAM por nodo
• 1 gigabit ethernet en cada nodo
• 40 nodos por rack
• 8 gigabit ethernet uplinks desde cada rack al core
• Red Hat Enterprise Linux Server Release 5.1 (kernel 2.6.18)
• Sun Java JDK 1.6.0_05-b13

Se usó Hadoop pre-0.18 optimizado para evitar escrituras intermedias al disco y la ordenación tomó 1800 maps y 1800 reducciones. Hadoop es una librería opensource cuyo principal contribuidor es Yahoo (debido a que la adoptaron hace ya unos años y contrataron a sus creadores), pero también es usada internamente por otros grandes jugadores como Amazon y Facebook. Este tipo de resultados en competiciones, es una muestra de la madurez de la librería y a los desarrolladores nos da la confianza de tener una herramienta poderosa totalmente opensource para realizar tareas que manejen grandes volúmenes de datos y procesamiento.

Oracle Workshop 10.3: primer producto Oracle + Bea

Se ha publicado la suite de plugins Oracle Workshop para Weblogic 10.3. Entre las nuevas características, destaca que estos plugins ya no están atados a los productos BEA, ahora tienen soporte para otros servidores y para las librerías Oracle, en específico para ADF.

Entre las características de esta nueva versión de Workshop destaca el soporte a la especificación Servlet 2.5 y a lo que será la 3.0 que permite que los web.xml sean opcionales; soporte para JEE 5: JAX-WS con JAXB, JSF, JPA. y otras tecnologías de BEA como XMLBeans 2.0.

Oracle Workshop funciona sobre Eclipse 3.3 con WTP 2.0 y con los servidores de aplicación websphere, weblogic, tomcat, jboss, jetty y resin.

IBM Websphere Portal 6.1 con soporte a JSR-268

IBM ha publicado la nueva versión de su producto para Portlets Java. Esta versión 6.1 tiene como principal característica soportar las últimas especificaciones para Portlets:

JSR-286 (me parece que es el primer producto en soportar esta nueva especificación). Incluye el concepto de eventos (cualquier portlet puede enviar y recibirlos), cualquier portlet puede servir recursos desde el servidor (lo que de hecho permite el uso de Ajax) y Filtros para Portlets. La especificación fue publicada en su forma final el pasado 13 de junio, por lo que es interesante ver que IBM ya tiene lista una implementació.

WSRP 2.0 (Web Services for Remote Portlets). Un estándar de OASIS que por ende no solo cubre portales java sino también se usará en portales .net y similares. Básicamente cubre la forma de actualizar el html de un portlet a través de peticiones SOAP.

Además, Websphere Portal 6.1 tiene soporte para servicios REST, nuevos layouts y temas y una consola de administración basada en Ajax más usable. La lista de los cambios más relevantes la puedes consultar en la página de ibm.

IBM nunca se ha destacado por su rapidez a la hora de implementar estándares; sin embargo en el mundo de los portlets java ellos siempre han llevado la posición de liderazgo. Este nuevo producto es una gran mejora con la versión anterior.

Sobre los nombres de clases en Java

Recientemente, en reddit comentaban sobre esta clase del modulo de AspectJ para Eclipse desarrollada por Adrian Colyer:

HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor

No se si es la clase con el nombre más largo que exista pero es un buen ejemplo de las prácticas de Java, un nombre así tan descriptivo evita la necesidade documentar su uso, pero por otro lado venga algo como la clase del ejemplo es ridículo. Hace que el programar sin un IDE que te autocomplete imposible además que según que SO te pueden dar problemas nombres tan largos. 

Las code conventions de Sun, no mencionan nada acerca de la longitud de los nombres de clase pero dicen que se deben evitar usar abreviaciones y acrónimos, lo que obviamente lleva a usar nombres de clase largos.

Regresando al ejemplo de AspectJ, la clase la desarrolló Adrian Colyer, CTO de SpringSource y uno de los principales promotores de la AOP. Vamos, que no es ningún principiante en Java, pero que también es famoso por su sentido del humor inglés (ver la variable llamada ohYesItHas en la misma clase) basta recordar que en el SpringOne de 2007 para enseñar duck typing sacó una marioneta de un pato y se puso a teclear en su portátil. Es interesante ver que ese sentido del humor también se traslada a su código.

La pregunta es, si las convenciones no nos mencionan ninguna limitante para nombrar nuestras clases e internamente se manejan como Identifiers por lo que en teoría pueden tener cualquier longitud (aunque al parecer no en todos los SO te lo permiten) ¿Vosotros aplicáis alguna regla de dedo para determinar la máxima longitud en el nombre de las clases? Si no lo hacés, ¿cómo evitar casos ridículos como el del ejemplo aquí dado?

Listado de decompiladores Java

En LinkMingle.com han publicado un listado bastante completo de decompiladores y ofuscadores para Java. No sé en vuestro caso, pero aunque pueda parecer que un decompilador es una herramienta que raramente nos será útil, de vez en cuanto yo siempre acabo necesitando usar alguno y recurriendo a Google para encontrarlo. En cualquier caso, es un excelente enlace para añadir a nuestros bookmarks.