Google + Intel = Android x86

Recientemente hay varias noticias que hablan de la alianza entre Google e Intel para desarrollar Android en los procesadores x86. Ya había un proyecto de la comunidad de desarrolladores para portarlo, que estaba dando sus frutos, y ahora se suma esta iniciativa conjunta de estos dos pesos pesados.

Estaba leyendo una nota al respecto, y pensaba que acá el problema es que Intel tiene que resolver el mayor consumo de los procesadores Atom, si se los compara con los efectivos y rendidores diseños de ARM. Intel necesita dejar de perder mercado en los sectores móviles, donde la arquitectura ARM es hoy por hoy el rey absoluto, y esta alianza con Google, puede llevar a Android a nuevos sectores.

Oracle/Sun: pensamientos y divagaciones

A continuación, algunos pensamientos y divagaciones sobre Sun, Oracle, MySQL, Java y temas relacionados a la post-compra de Sun. Escribí este texto durante una conversación con colegas, que todo inició como un debate sobre el artículo que publicó Oracle por la finalización de la adquisición de Sun. Mi preguntaron si podían compartirlo, y aquí está.
Advierto que si deciden seguir leyendo, lo hacen baja su propia responsabilidad. Y como siempre, la casa se reserva el derecho de moderar cualquier comentario desubicado ;)

...
Creo que el único fuerte que salva a MySQL es que es universalmente usada en los ISPs y se incluye hasta en los planes de hosting más baratos, lo que no es poco. Pero se queda corta comparada con cualquier base de datos relacional seria, y también en el entorno embebido cuando se quiere algo rápido y eficiente (donde SQLite es el líder lejos, y cada vez más usada). Para mi, MySQL es una base de datos de compromiso y nada más ;)

PostgreSQL es "LA" base de datos libre. Es muy parecida a Oracle en muchos sentidos. Y ahora que a MySQL le nació MariaDB... más vale que Oracle no descuide a la criatura... o se habrán gastado una pasta al dope xD y creo que con MySQL ya van camino a perder todo su control, apenas MariaDB reemplace a MySQL como la favorecida por las distros Linux, lo que ya se está discutiendo.

Lo que ahora controla Oracle de Java... lo puede perder en un instante si empieza a alienar a la comunidad y al resto de las empresas del sector. Y si pasa eso, se van a disparar en su propio pie, no creo que lo hagan, pero es posible. Me acuerdo lo que pasó con el consorcio que manejaba X11 y lo que pasó al hacer cambios en su licencia y decisiones que lo gustó nadie: rápidamente se conformo un nuevo consorcio (X.org) que lo reemplazó de hecho, y encima se ganó mucha apertura, innovación y velocidad de mejoras en el proceso. A veces, una revolución es positiva.

¡Hay laburo asegurado en Java hasta para nuestros nietos! Incluso si se volviera obsoleto o irrelevante, la inversión en software crítico que existe es impresionante, y habrá que convivir con él y darle mantenimiento y soporte por varias décadas, como sigue pasando con COBOL y FORTRAN hasta nuestros días.

Se puede perder interés en Java en algún momento: pasará eventualmente, y no depende solo de Oracle/Sun. Ya hay muchos lenguajes pidiendo cancha en la JVM: Groovy (c/Grails), Ruby (RoR), Scala, Clousure, Jython/Python, etc. que si Java (el lenguaje) no se mantiene al día, cualquiera de estas u otras opciones serán cada vez más interesantes, dentro o fuera de la JVM.

Y Apache con Harmony sigue ahí a la espera. Sun no les dejaba certificarse y llamarse "JAVA", y Apache en protesta votaba en negativo en cada votación de JCP. Android ya usa partes de Harmony y está claro que no es Java. Dicen que Harmony está programado tan pero tan bien, que es todo un ejemplo de cómo debe programarse algo, y que está limpio y programado desde cero, bien documentado, bien diseñado. Encima, al estar bajo licencia Apache (digamos burdamente "hacé lo quieras"), se hace muy tentador a empresas como este caso de Google con el Android.

En resumen: Oracle no puede hacerse mucho "el loco", o le quitarán el control. Y si no abren el JCP, si no lo transforman en un organización per-se, se les puede complicar. A favor, Oracle era una de las empresas que votaba para abrir el JCP, vamos a ver si ahora que está en sus manos se "acuerda" de sus propios reclamos ;)

Todo lo que ya es software libre, como en la Evolución, irá encontrando su camino, aunque a veces sea difícil verlo de antemano :)

Escoba de 15

En este comienzo de la primavera, les tengo un regalito. Hoy publico un juego en SourceForge.net, como código abierto, bajo una licencia libre. Se trata del clásico juego de naipes españoles de la "Escoba de 15".

Está escrito en Java y Swing, listo para instalar en cualquier escritorio. El único requerimiento es tener un JRE de Java 6. Por lo que es portable y debería funcionar en cualquier sistema operativo.

Por el momento solo permite jugar contra la computadora. Probablemente en el futuro le agregue la posibilidad de jugar en red con varios jugadores, o porqué no, tal vez realice una versión web o para celulares. El tiempo dirá.

Si lo descargan para probarlo, dejen sus comentarios aquí mismo. Y cualquier problema o sugerencia, por favor usen el sistema de soporte y seguimiento de SF.net. Que lo disfruten :)

Crear documentación en Java: JavaHelp, DocBook y Ant

Recientemente, para un mini proyecto personal realizado en Java y Swing, necesité integrar un sistema de ayuda.

Naturalmente pensé en el sistema estándar y predeterminado de Java para Swing: JavaHelp. Este nos permite crear un sistema de ayuda completo con tabla de contenidos, secciones, buscador y todas las funciones que esperamos encontrar. Incluye un SDK para el desarrollo, visualizadores, ejemplos y hasta puede extenderse para personalizarse si lo deseamos. Como está implementado 100% en Java, automáticamente está disponible para todas las plataformas.

Aunque lo conocía de antes, hasta el momento nunca había tenido oportunidad de usarlo, así que era una buena excusa para incursionar en el tema. Pero me encontré con un pequeño problema: no me parecía del todo útil aprender otro lenguaje de marcado, cuando encima solo podría generar como resultado archivos de ayuda en dicho formato. Estaba pensando en usar algo más universal, que pudiera generar salidas al menos en pdf y html, además del formato JavaHelp.

Una de las mejores alternativas, si no la mejor, es DocBook, que es el lenguaje XML específico para crear documentación en general y que cumple con todos los requisitos. Es un estándar muy usado para ello. Desde DocBook tenemos todas las opciones posibles para exportar a cualquier otro formato de salida, incluído JavaHelp, CHM, PDF, HTML (simple y multipágina), XML-FO y muchos más. Les enlazo una introducción en castellano a DocBook, en la cual pueden encontrar el siguiente diagrama:

DocBook es una especificación abierta, implementada y soportada por distintas herramientas. Hasta existen editores visuales para escribir documentos en este formato, por si no queremos aprender el lenguaje de marcado. Es muy conocido y utilizado en el entorno GNU/Linux.

Pero para completar el círculo, el desarrollador en mi pedía automatizar el proceso. Investigando un poco más, busqué información hasta lograr armar el conjunto de herramientas adecuado. No hay mucha información al respecto, no al menos de forma completa. Terminé usando un script de ANT desde Eclipse 3.5 Galileo, con un archivo fuente XML en DocBook, y con el soporte de varias librerías, ya me permite generar toda la documentación completa tanto en JavaHelp como en HTML, y eventualmente en cualquier otro formato. Probablemente agregue PDF y tal vez CHM.

El mejor y más completo tutorial que encontré es "Build DocBook XML in Eclipse". Hay que seguirlo al pie de la letra. Tiene un dato clave que es que la implementación Xalan/Xerces proporcionada por ANT en Eclipse no funciona debido a un bug, y debe ser reemplazarla por la última versión estable. Por supuesto, tuve ese problema :D. También fueron útiles en cierta medida los artículos "Creating an Online Help System with JavaHelp and DocBook" y "DocBook with Eclipse - Tutorial", que aportan algunos detalles más.

Aunque se supone que generar archivos de ayuda y documentación debería ser una tarea bastante habitual para todos los programadores, la ausencia de buenos tutoriales y algunas herramientas actualizadas que faciliten la tarea demuestran que no es tan así. Al final termino confirmando esa sensación de que es un ítem bastante olvidado. Ojalá sirvan estas lineas para facilitar la implementación de esta funcionalidad tan importante, tantas veces descuidada.

Chuck Norris y Java

Conocía los "hechos de Chuck Norris", pero no sabía que también programaba en Java.

LWUIT y los acentos

Me puse a investigar porqué no aparecían los acentos en los formularios de LWUIT. Buscando un poco, vi que recomendaban reconstruir la fuente incluída en los recursos. Haciendo un poco de prueba y error, encontré la solución al tema:

1. Asegurarse que el proyecto esté en UTF-8. Bien porque el entorno usa ese encoding por defecto (preferences, general, workspace, text file encoding), o bien porque así lo indicamos para nuestro proyecto (project properties, resource, text file encoding).
2. Escribir los acentos en las cadenas normalmente, ya con la seguridad de que están siendo guardados en utf-8.
3. Usando el Editor de Recursos de LWUIT, abrimos nuestro archivo de recursos, que contiene el/los tema/s, las imágenes, las fuentes y otros elementos localizables. Ir a la sección de fuentes, y revisar los caracteres incluídos en la sección charset. Si faltan caracteres, se pueden agregar haciendo clic en el botón "Rebuild Font". Habrá que seleccionar una fuente apropiada, revisar su tamaño y estilo, y agregar todos los caracteres que necesitemos en la lista disponible en la sección charset.
   

Recordemos que en el archivo de recursos, las fuentes son convertidas a una imagen bitmap. Gracias a esto podemos disponer de cualquier tipografía en todos los celulares, y asegurarnos de que se vea igual en todos lados. Además, como una optimización importante para ahorrar el limitado espacio disponible, solo se generan los caracteres que necesitamos. Por defecto, solo encontraremos los caracteres del idioma inglés, faltando las vocales acentuadas, la ñ y la ü. También nos sirve para agregar cualquier otro carácter utilizado.

Una sugerencia: me parece que el editor no recuerda la lista de caracteres al volver a editar una fuente previa. Si es así, sería buena idea guardarla en algún lado, o mejor todavía, modificar al Editor de Recursos para que la cargue desde algún lado, como un archivo properties. No estoy seguro de esto, y ya lo verificaré más adelante.

OSGi

Usando Eclipse, es normal encontrar alguna mención a OSGi, como cuando se hacen actualizaciones o se instalan plugins. ¿Pero qué es eso?

OSGi es una tecnología que permite agregar funcionalidades dentro de una aplicación. Estos agregados pueden ser desarrollados de forma independiente al entorno de la aplicación. Los componentes más importantes de la tecnología OSGi son el contenedor OSGi y los bundles
(paquetes) que pueden ser desplegados dentro de dicho contenedor.

Es parte fundamental del sistema de plugins de Eclipse, como de otras aplicaciones que usan la misma tecnología. También podemos utilizarlo en nuestras propias aplicaciones, como sistema de agregados y actualizaciones.

La Alianza OSGi es un consorcio sin fines de lucro, formado por muchas compañías líderes, como IBM, Motorola, Nokia, Telefónica o Red Hat, con el fin de definir sus estándares y promoverla.

En la Wikipedia en inglés podemos encontrar más detalles sobre el tema. What is OSGi? – The Dynamic Module System for Java es una introducción interesante, con enlaces a algunos ejemplos.

Portales y Portlets

Estaba leyendo un artículo que resume las diferencias entre Portal, Portlet y Contenedor de Portlet, y me gustó el siguiente resumen:

Los Portlets son componentes web, como los servlets, diseñados específicamente para ser agregados en el contexto de una página compuesta. Generalmente, son invocados muchos Portlets en un único pedido de una página al Portal. Cada Portlet produce un fragmento de la salida, que es combinado con la salida de otros Porlets, todo junto con la salida de una página del Portal.

Los Portlets son mini-aplicaciones, que proveen algún contenido que formará parte de las páginas del portal. Los Portlets son manejados por un Contenedor de Portlets.

Un Contenedor de Portlets:

• ejecuta (corre) portlets,
• maneja el ciclo de vida de los portlets,
• y les provee un entorno de ejecución.

Para correr y probar un Contenedor de Portlets necesitamos un conductor: un Portal.

Los pedidos de los usuarios son recibidos por el portal, y luego son direccionados a un contenedor de portlets, para ser ejecutados en los portlets. El portal, no el contenedor de portlets, es el responsable de unir todo el contenido producido por los portlets, y de presentarlo a los clientes. Entonces un portal es una aplicación web, que puede ser desplegada en un contenedor web como Apache Tomcat, el cual junta el contenido de los distintos portlets, mientras la comunicación entre el portal y los portlets es llevada a cabo por los contenedores de portlets.

No es un tema muy nuevo, así que hay muchos artículos y documentación, incluso se puede encontrar algunos analizaban sus ventajas y desventajas.

Web Beans

Ya hay una documentación preliminar sobre Web Beans, y formaría parte de Java EE 6. Todavía está en una etapa temprana, y habrán cambios y definiciones importantes. Pero lo llamativo, es que ya mismo se dispone de documentación en castellano y en otros idiomas, no solo en inglés.

Recientemente se anunció el cambio de nombre: se llamará "Java Contexts and Dependency Injection", lo cual representa mejor su alcance, y es la introducción formal de las mejores ideas y soluciones que nos trajo Spring, Guice, Seam y otros frameworks.

El trabajo se está realizando en la JCP bajo la JSR-299., con la participación de la mayoría de los proveedores de soluciones EE, como JBoss e IBM.

JBoss es el responsable de realizar la implementación de referencia, la cual ya está disponible como Alpha 2. Se espera que JBosss SEAM 3 esté basado en JSR-299.

REST: vuelta a lo simple

Leí una introducción a REST que me encantó por lo clara y sencilla. La encontré vía JavaHispano.

Me quedo con esta frase:

REST es la vuelta a la Web antes de la aparición de los grandes servidores de aplicaciones, ya que hace énfasis en los primeros estándares de Internet, URI y HTTP

Ironía

Me encontré un comentario muy divertido en la documentación del framework SEAM.

Para entender el contexto, estaba leyendo en el manual las recomendaciones sobre cómo configurar la JVM, y rematan con lo siguiente:

If you don't want to bother with this stuff now, you don't have to—come back to it later, when you get your first OutOfMemoryException.

Que viene a decir:

Si no quiere preocuparse por estas cosas ahora mismo, no tiene que hacerlo. Vuelva más tarde, cuando obtenga su primer OutOfMemoryException.

Muy sutil :D

javaME SDK 3.0 EA

El SDK para desarrollo de aplicaciones móviles javaME (Java MicroEdition), mejor conocido como WTK (Wireless Toolkit), está siendo renovado.

La versión anterior, es la llamada "Sun Java Wireless Toolkit 2.5.2 for CLDC". Con la nueva, cambia también el nombre que pasa a ser "Java Platform Micro Edition Software Development Kit 3.0". Para abreviar: JavaME SDK 3.0.

Por el momento hay una versión EA (Early Access), que viene a ser una versión de prueba o candidata, y que lamentablemente solo está disponible para windows por el momento :(

Para poder bajarla, hay que estar registrado en la SDN (Sun Developers Network).

La estoy probando, junto a otros emuladores (ya hablaré sobre esto en otro momento), y hoy me encontré con un problema. Cuando instalé el WTK 3.0, estaba usando el JDK 1.6_07. Ayer actualicé al JDK 1.6_10, y desinstalé la versión anterior. ¡Sorpresa, no funciona más el WTK 3.0!

Me imaginé que habría algún archivo de configuración apuntando al viejo JDK. Lo peor, es que ni siquiera hay un mensaje de error claro del problema. Empieza a arrancar, y queda a mitad de camino tratando de iniciar una y otra vez el device manager, que posee un icono en la traybar, quedando en un cliclo sin fin, hasta que no queda otra que matar al proceso.

Para hacerla fácil, traté de usar el (inútil) buscador de archivos de windows, seleccionando "todos los archivos", apuntándolo a la carpeta del WTK, y buscando por texto el viejo path. ¡Craso error!. Luego de bastante tiempo, responde que no existen archivos... ¡MENTIIIIIRA!. No puede haber herramienta tan mal programada como el maldito buscador de archivos que trae windows. Vuelvo a hacer la búsqueda con indispensable Total Commander, y en segundos obtengo la respuesta esperada: una lista de archivos que contienen dicho path. Bien, ya es otra cosa. Moraleja: no hay que pedirle peras al olmo.

Lo extraño, es que los archivos encontrados tienen una extensión hasta ahora desconocida para mi: .vm. ¡WTF!. Igualmente los abro con notepad++, para inspeccionar sus tripas, y resultan ser simples archivos batch. ¿Por qué ponerles dicha extensión? Supongo que la gente de Sun no querrá que los usuarios les hagan clic por error, para que en su lugar usen el .exe que los acompaña. Supongo que el .exe sería más inteligente (cof, cof) para detectar dónde se encuentra la JDK... pero bueno, están perdonados porque es una edición EA. Finalmente, corrijo los paths a mano dentro de esos archivos, y problema solucionado.

También hay un archivo en Java_ME_platform_SDK_3.0_EA\toolbar\bin\java, que contiene la ruta al jdk, y que hay que corregir también. Este lo había encontrado a mano, en un primer intento de ver dónde podría haber algún archivo de configuración.

Una curiosidad: este WTK 3.0 no es un SDK más. Es un IDE completo, con muchas herramientas y novedades. Todo el IDE parece estar basado en el framework de Netbeans. No lo he verificado, pero por la estructura de archivos y las cosas incluídas, podría asegurar que es así.

Presentando a LWUIT

LWUIT es un toolkit infaltable para el desarrollo de aplicaciones para móviles y celulares, usando JavaME.

Cualquiera que haya programado en JavaME sabe que hay dos opciones para la interfaz gráfica: usar los formularios o usar el canvas. El primero es mucho muy básico. Considerando las limitadas capacidades de los primeros celulares, no es de extrañar que sea tan limitante. Provee muy pocos elementos para hacer una UI, y de lo poco que tiene, son muy toscos y limitados. Lo peor es que las aplicaciones hechas así, son muy feas, desagradables, y no hay solución :D. La otra opción, es el canvas, que nos ofrece acceso a la pantalla como si tratara de una superficie de dibujo, muy similar a las provistas por java2D, donde hay que dibujar todo a mano, por coordenadas gráficas (x,y). Nos da poder y control absoluto del display, lo cual es muy útil para los juegos, pero para hacer una interfaz de usuario... es como construir un túnel hoy día con solo pico y pala. Otro inconveniente: como hay muchas diferencias entre un celular y otro, hay que manejar a mano las diferencias de resoluciones y profundidades de color, sortear bugs conocidos de ciertos modelos y marcas, adaptarse a las APIs disponibles en cada caso, en fin, una serie de complicaciones que puede transformar el desarrollo de una aplicación para javaME en un gran dolor de cabeza y en un terrible costo/esfuerzo.

Les presento LWUIT: la solución a (muchos de) nuestros problemas :). LWUIT significa Lightweight UI Toolkit for Java ME, el cual está gratamente inspirado por Swing. Esta librería permite crear aplicaciones modernas, agradables, con mayor usabilidad, al mismo tiempo que las hace fáciles de adaptarse a las particularidades de cada dispositivo móvil, casi "automágicamente".

Es una interfaz gráfica basada en componentes y MVC, muy similar a Swing. Los controles son dibujados aprovechando las posibilidades que ofrece cada móvil, incluyendo efectos 2D y 3D, con soporte propio de temas visuales. Estos son fáciles de intercambiar, y se incluye un editor de temas para personalizarlos y poder crear los propios.

Resulta muy fácil crear interfaces modernas y sorprendentes, y al mismo tiempo unificarlas entre distintos móviles. LWUIT se encarga de todos los detalles del dibujado por nosotros, y en el camino nos brinda muchas herramientas y soluciones a problemas comunes.

La documentación, aunque breve, es suficiente. Viene un ejemplo muy completo que muestra las posibilidades de la librería, que recomiendo probar y jugar. Pueden ver los videos donde se muestran demos sobre varios celulares típicos.



Como si esto fuera poco, estas son apenas algunas de las características de esta librería. Hay muchas más, y permanentemente están trabajando para mejorarla y agregarle más funciones y herramientas.

Si estás involucrado en el desarrollo de aplicaciones para móviles, no podés dejar de probarla.

Saludos