Google, Microsoft y Yahoo! se ponen de acuerdo en un lenguaje de marcado para la web

El lenguaje se llama Schema.org, y cuenta con el apoyo de los tres gigantes del mundo de los motores de búsqueda: Google, Microsoft y Yahoo!. El propósito de este lenguaje de marcado es acercarnos a la utopía inalcanzable hasta ahora de una web semántica.  

Schema.org está basado en the Microdata, y tiene un vocabulario muy rico que cubre todos los términos recogidos en Microdata, Microformats y RDF. Todos estos términos se definen empleando varios atributos HTML (itemscope, itemtype y itemprop). Por ejemplo: 

<div itemscope itemtype ="http://schema.org/Movie">
  <h1 itemprop="name">Avatar</h1>
  <span>Director: <span itemprop="director">James Cameron</span> (born August 16, 1954)</span>
  <span itemprop="genre">Science fiction</span>
  <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
</div>

Hasta ahora Google soportaba Microdata, Microformats y RDF. Pero afirma que tener un único formato va a mejorar la consistencia a través de múltiples motores de búsqueda y será beneficioso para todos. 

¿Cuántos de vosotros habéis empleado Microdata, Microformats, RDF o alguna solución similar en alguna web que habéis desarrollado? ¿Qué pensáis de Schema.org?

Clojure vs Scala ejemplos de una sola línea

Si bien que puedas programar una funcionalidad en una sola línea, no es demasiado importante para elegir un lenguaje de programación (incluso en lenguajes que tienden a necesitar más líneas, siempre puedes usar/hacer una librería para simplificarlos); me han gustado estos ejemplos usando Scala y Clojure como un acercamiento a ambos lenguajes.

Los ejemplos de Scala los publicó Marcus Kazmierczak en su blog, algunos no son los más eficientes, pero en los comentarios proponen mejores alternativas. Algunos son muy simples, como el ejemplo 7 que obtiene un xml de un servicio web y hace el parsing del mismo:

val results = XML.load("http://search.twitter.com/search.atom?&q=scala")

Donde se demuestra, entre otras cosas, que el XML es una estructura nativa en el lenguaje lo que reduce la complejidad de hacer parsing a mano. 

El ejemplo 9, por su parte, demuestra una nueva funcionalidad de Scala 2.9, las colecciones paralelas:

val result = dataList.par.map(line => processItem(line))

En este ejemplo dataList es una lista y a cada uno de sus elementos, le aplicamos la función "processItem". El resultado se va guardando en otra lista que es asignada a la variable inmutable result. Lo interesante es que por usar la palabra reservada "_par", Scala automáticamente paralelizará este procesamiento sacando provecho de los múltiples cores que suelen tener los ordenadores hoy en día.

Ahora veamos los mismos ejemplo en Clojure, hechos por Baishampayan Ghose  y publicados en su blog.

(clojure.xml/parse "http://search.twitter.com/search.atom?&q=clojure")

En Clojure también se tiene una estructura nativa para el XML y también se puede recibir directamente una URL representada como un String.

Para el caso del ejemplo 9:(pmap process-line lines) ;

En este caso, el procesamiento en paralelo se indica con la letra p antes de map. En teoría funcionaría igual que en Scala, pero los desarrolladores de Clojure han dejado claro que solamente está pensada para casos en que la función a llamar (en este caso process-line) sea computacionalmente intensiva (referencia).

¿Qué opináis de estos ejemplos? ¿Son complicados de leer, os invitan a conocer más el lenguaje? ¿Cómo se harían en otros lenguajes?

Jenkins no está interesado en reconciliarse con Hudson

Jenkins, el proyecto que surgió cuando hubo roces entre la comunidad y Oracle respecto al servidor de integración continua Hudson, parece no tener interés en volverse a fusionar con Hudson. Tras la separación de ambos proyectos, la respuesta de la comunidad fue bastante rotunda: cerrar filas en torno a Jenkins y abandonar Hudson. Al final, sólo Oracle y Sonartype continuaban apoyando el proyecto. Esta pérdida de momento (probablemente) ha llevado a Oracle a decidir donar Hudson a la fundación Eclipse.

Sin embargo, Jenkings no parece estar a favor de reconciliarse con Hudson. El mayor problema es que el proceso de desarrollo de Jenkings es muy ligero y muy abierto. Es muy fácil convertirse en un commiter del proyecto. Cosa que no ocurre con los proyectos de la fundación Eclipse. Para poder ser commiter de un proyecto de la fundación es necesario bastante papeleo de cesión de propiedad intelectual del trabajo, y además hay controles de calidad bastante rigurosos y (desde el punto de vista de algunos) burocráticos sobre el código fuente. 

Sin embargo, la filosofía de Jenkings es liberar productos rápido; su objetivo es hacer una release semanal de Jenkins core. Esto es simplemente imposible dentro de la fundación Eclipse, que somete a sus proyectos a meticulosas revisiones para asegurarse que la fundación es dueña de toda la propiedad intelectual del nuevo código y que éste cumple con los estándares de calidad de la fundación. 

En general, la fundación tiene muchas salvaguardas para garantizar que cuando una empresa construye un producto comercial sobre código de la fundación nunca va a tener ningún problema de propiedad intelectual o patentes relativo al código que toma del ecosistema de Eclipse. Y todos estos procesos parecen demasiado pesados a la gente de Jenkins.  

Por todo ello, aunque no se ha tomado ninguna decisión, parece que van a optar por no reconciliarse. O eso se desprende de la lista de condiciones que los integrantes de Jenkins están elaborando para aceptar una fusión con Hudson.

¿Creéis que ésta es la decisión más adecuada o creéis que deberían volver a fusionarse con Hudson?

Encuesta del mes: ¿Está JavaME muerto?

El 65% de la gente ha respondido que sí, o que no pero casi. Si a esto añadimos el otro 20% que dice que sólo está muerto para smartphones, nos queda sólo un 15% que piensa que todavía tiene un buen estado de salud, o que va a conseguir resurgir. Obviamente, la opinión de la comunidad no es muy positiva.

Si a esto añadimos el hecho de que parece que los planes de Oracle (al menos hasta el momento) para revitalizar Java ME son el Oracle Java ME Embedded Client (un entorno que tan siquiera tiene interfaz gráfica de usuario) parece claro que la batalla de Java ME al menos en lo que a smartphones se refiere (quizás incluso terminales móviles en general) está perdida.

¿Qué opinais vosotros al respecto?

GwtQuery 1.0.0

Hace un par de días se ha liberado la primera versión estable de GwtQuery. Su nombre describe bastante bien lo que es: un porte de jQuery a GWT. Esta librería nos permite escribir dentro del código Java de las aplicaciones GWT código al estilo de jQuery para manipular la página web.

Por ejemplo, para cambiar todo el texto de los encabezados h1 de una página simplemente tendríamos que hacer:

$("h1").text("Nuevo texto");

Y para manipular la hoja de estilos que configura la presentación de estos encabezados:

$("h1").css("vertical-align", "top");

GwtQuery permite realizar interacciones con los widgets de GWT, tienen completo soporte para el API de jQuey, sus motores de selección están altamente optimizados y, a diferencia de jQuery, es completamente "type-safe". Por ejemplo, la última sentencia también podría haberse escrito así en modo "type-safe":

$("h1").css(CSS.VERTICAL_ALIGN.with(VerticalAlign.TOP)); 

Aquí tenéis documentación sobre la librería. Los que estuvisteis en la primera charla de Madrid JUGpudisteis presenciar de una presentación sobre esta librería de mano de uno de los commiters del proyecto, Manolo Carrasco. En breve se publicará el video de la charla para que todos podáis disfrutar de él.