Yahoo! Browser Plus: la apuesta RIA de Yahoo!

Yahoo! ha publicado la primera versión llamada "Sneak Peek" de su plugin para navegadores BrowserPlus. Dejando de lado la falta de creatividad del nombre, este plugin es la apuesta de la empresa para entrar al mundo de aplicaciones RIA para el escritorio, mercado hasta ahora ocupado por Google Gears, Mozilla Prism y Adobe Air. HHace ya unos meses que corría el rumor de que Yahoo preparaba un navegador para competir en el mercado, al final no es eso, sino un plugin para los navegadores existentes.

Browser Plus se instala en los ordenadores y pemite, de acuerdo a los ingenieros de Yahoo!, "una experiencia más rica" en tu navegación. Los sitios que soporten este plugin, pueden usar el API javascript para comunicarse con él y hacer uso de sus servicios que incluyen un FileUpload, un Upload para Flickr, soporte para Drag & Drop, un chat IRC e incluso un intérprete de Ruby que permitirá a los desarrolladores crear sus propios servicios usando el popular lenguaje.

Otra de las características interesantes de BrowserPlus es su soporte para guardar datos en local, lo que permite que un usuario trabaje con un sitio web en modo offline y al estar online, pueda sincronizar los datos de la aplicación de forma automática.

Los ingenieros de Yahoo! han estado trabajando durante 1 año en este plugin y se comprometen a seguir desarrollando servicios no sólo útiles, sino divertidos, para que aquellos que quieran incluir BrowserPlus en su sitio puedan hacer uso de ellos fácilmente. De esta forma, el mercado de los RIA de escritorio se puede dividir en dos: Adobe Air, Mozilla Prism y JavaFX que apuestan por una experiencia afuera del navegador y Google Gears y Yahoo! Browser plus que apuestan por ser extensiones del navegador. Nuevas tecnologías que se suman a la taxonomía RIA de Simon Morris: Browserism vs Neo-Desktopism.

Desde mi punto de vista, la ventaja competitiva que ofrece esta solución de Yahoo! está en los servicios listos para usarse, un sitio web puede añadir características RIA e integración al escritorio con sólo unas líneas de javascript. El punto débil está en que requiere un plugin externo instalado en el ordenador cliente, en vez de usar algún plugin existente como el de Flash o el JRE que están instalados en más del 90% de los ordenadores conectados a internet.

Por ahora, solo los sitios de Yahoo! y sus partners pueden usar este servicio, cuando se considere que el plugin es estable y seguro, se permitirá a cualquier sitio usarlo.  El plugin funciona en Windows XP y Vista con Firefox 2 o superior o IE 7 o superior y en Mac OSX con Safari 3 o superior y Firefox 2 o superior

¿Java 5, Java 1.4 o Java 5 y Java 1.4?

Este es uno de los debates que actualmente está sucediendo dentro del seno de Eclipse. Eclipse Foundation ha comenzado definir la arquitectura de lo que será Eclipse 4. Y uno de los grandes debates es si mueven o no los componentes internos de la plataforma a Java 5, si siguen usando Java 1.4, o si soportan ambas versiones.

Las ventajas de pasarse a Java 5 son las mejoras en el lenguaje y en las librerías. Los principales detractores de este cambio son los miembros de la comunidad empotrada de Eclipse, que temen que al moverse a Java 5 el entorno consumirá más recursos sin realmente ofrecerles nueva funcionalidad.

El debate va más allá de Java 5 y Java 1.4. También se plantea en sí debería soportar APIs para otros lenguajes como Groovy, Ruby, JavaScript, C... Aunque esto se lo plantean a más largo plazo. El punto más candente ahora mismo está entre Java 5 y Java 1.4. Y no es viable que cada grupo de desarrolladores responsables de una parte de la plataforma tome una decisión diferente, ya que la decisión que tome se verá reflejada en su API y arrastrará a otros proyectos que dependan del suyo.

Esta discusión no es realmente relevante para los usuarios finales de el entorno de desarrollo Eclipse. Si es relevante para los desarrolladores que usen la plataforma de Eclipse en sus desarrollos. Por otro lado, resulta interesante ver los problemas y tensiones que surgen al intentar evolucionar un proyecto software de tanta envergadura como Eclipse. Este tipo de cosas son las que hacen que la velocidad de evolución de las aplicaciones decrezca rápidamente con su tamaño

¿Sigue teniendo sentido almacenar un modelo de objetos en tablas relacionales? (opinión publicada en Sólo Programadores)

¿Sigue teniendo sentido almacenar un modelo de objetos en tablas relacionales?

Cristian González Losada
Analista-programador en Nevian Sistemas 

La solución a la persistencia de datos ha estado tradicionalmente ligada a las BBDD relacionales. La transición a la POO, que bien podríamos dar por finalizada, no ha cambiado en absoluto este hecho.

 Las diferencias entre el modelo de objetos y el relacional nos causa más de un problema a los desarrolladores. Estamos obligados a crear y mantener dos modelos (el de objetos y el relacional), así como a desarrollar clases que transformen nuestros datos de un modelo a otro.

Con el tiempo muchos desarrolladores han renegado de incrustar sentencias SQL en su código Java, pasando a emplear mapeadores O-R como Hibernate, TopLink, etc. Estos frameworks han permitido delegar el problema de la falta de concordancia objeto-relacional en una librería externa que nos hace casi transparente la traducción de un modelo a otro.

 

Algunos críticos de este tipo de frameworks consideran que no es el enfoque correcto para solucionar el problema. Debería considerarse la posibilidad de almacenar nuestros objetos en BBDD orientada a objetos, librándonos del problema que pretenden resolver los frameworks de mapeo O-R.

 Considero que el que estemos dejando de incrustar SQL en nuestro código en favor de distantas APIs de persistencia, facilitará una futura transición a este tipo de BBDD, cuando estos sistemas maduren y nos hayamos puesto de acuerdo en un lenguaje estándar de consulta para el modelo de objetos (que podría ser algo similar a LINQ o HQL, por ejemplo).

GWT 1.5 RC1 soporta Java 5

Hoy ha sido publicada la versión Release Candidate 1 de Google Web Toolkit 1.5. La principal novedad de esta versión, es que ya soporta las características de Java 5: Generics, auto-boxing, anotaciones y enumerations. Cabe aclarar que el soporte a Java 5 era la característica más demandada por los usuarios de esta librería, así que al final el equipo de GWT han logrado completar la tarea.

Otras mejoras han sido enfocadas al desempeño del código Javascript generado, en el anuncio oficial dicen "..estamos felices de que el compilador produce código más rápido del que podrías escribir a mano". Además incluyen una nueva API para manipulación directa del DOM.

Como ya he dicho, esta versión es solo una RC1, puedes descargarla y dar feedback a los desarrolladores en el foro que tienen para ello,

Versión 2.0 de barcode4j

El proyecto barcode4j ha anunciado recientemente la versión 2.0 de su generador de código de barras, 100% implementado en Java y distribuido bajo licencia Apache. El generador tiene soporte para generar códigos de barras en una y dos dimensiones, permite exportar los códigos a SVG, EPS, Bitmaps y Java2D y proporciona un Servlet con soporte para generar códigos de barras en formatos SVG, EPS y bitmap.

También posee una interfaz de línea de comandos y puede integrarse con Apache Xalan y Apache FOP y con SAXON XSLT. Podéis encontrar más información sobre el proyecto aquí.