Google Gears: Unplugged Web 2.0

Hace unos días escribía sobre aplicaciones web offline sin saber que Google sacaba ya su solución: Google Gears. Los estándares son buenos, pero ¿quién quiere esperar a un estándar cuando tus ingenieros son los mejores?

Lo acabo de instalar. Al entrar en Google Reader, la primera aplicación que lo soporta, aparece el siguiente mensaje:


Marco que lo recuerde y le permito acceso. Al entrar en la aplicación, en el menú de opciones aparece un nuevo icono. El tooltip reza lo siguiente: "Currently online. Click to go offline". Lo pulso, como no puede ser de otra forma, y aparece una barra de progreso con el estado de la descarga de noticias:
Lo quedo en modo offline y el monitor de red ni se inmuta a partir de entonces: puedo leer noticias "desenchufado".

¿Y si ahora me quedo sin conexión? /etc/init.d/net.eth0 stop... Ok. Puedo seguir viendo noticias, están en mi caché local. En la ayuda de Google Reader indican que debería poder cerrar la ventana y volver, sin conexión, y debería funcionar. Lo pruebo y efectivamente funciona (parece que hay un pequeño problema y el contenido no se carga hasta que pulso algún enlace en la página, pero bueno, es una beta sobre otra ;) ).

Nada que no pudiese hacer antes con alguno de los miles de lectores RSS que ya hay, pero no es lo mismo. Las aplicaciones de sincronización han muerto. En breve todas las aplicaciones serán Web y nuestros datos estarán en un único sitio, cacheados en varios.

Google lo ha vuelto a hacer, justo a tiempo para competir con Silverlight de Microsoft Apollo, de Adobe. Pero claro, sólo uno funciona en "el otro" sistema operativo y "el otro" navegador ;)

Corrección: Silverlight no incorpora nada para trabajo offline.

Posted by Juan Ignacio Sánchez Lara 15:58 Enlaces a esta entrada  



Entierra con el hacha las pantallas de edición

Cuando conocí Flickr, me gustó. Pero cuando me convertí en usuario me enamoró por lo terriblemente bien hecho que está el interfaz, muy especialmente un detalle: si algo en la pantalla es editable por mí, lo puedo editar directamente. Por ejemplo, si doy de alta una foto, cuando estoy en su pantalla de detalle, si pulso en el título, el texto se convierte -elegantemente- en un campo de entrada, y puedo editar el valor, que se almacena vía Ajax (como el componente inline de Dojo).

Esa comodidad viene de romper con un hábito habitual: separar las pantallas de ver y de editar. ¿Para qué? Yo, usuario de la aplicación, no quiero tener que pasar a "modo edición" cada vez que quiera cambiar un dato. Si estoy viendo algo que puedo editar, debo poderlo editar, sin indicarle a la aplicación "¡oye, que voy a editar!". El componente de edición inline a mí me encanta pero para muchos usuarios puede ser confuso, por lo que, en una aplicación web, este principio se traduce a que si un dato no es editable debe aparecer como texto (¡no en un campo deshabilitado!), y si es editable, en un campo.

Esto en muchos entornos se traduce en jsps llenas de ifs, o, con suerte, de c:ifs, lo cual ni es productivo, ni mantenible, ni legible. Sin embargo, si puedes utilizar JSF y Tomahawk, no debes dejar pasar el atributo displayValueOnly de (casi) todos los campos de entrada. Permite, mediante una expresión JSF, decidir si algo se muestra como texto o como campo. Mejor, imposible. Y, para gestionar también el permiso de visibilidad sobre una propiedad, tienes el rendered. Con estos dos atributos manejas los tres permisos elementales (visibilidad, lectura y escritura) de la forma mínima.

Se acabó tener que programar varias pantallas en función de permisos y modos. Con una única pantalla podemos mostrar sólo lo que un usuario pueda ver (¡a nivel de propiedad!) y editar sólo lo que pueda editar.

Posted by Juan Ignacio Sánchez Lara 20:27 Enlaces a esta entrada  



Java QuickTip #0: comparaciones de igualdad

Cuando hagas comparaciones de igualdad de objetos, en vez de hacer

miCadena != null && miCadena.equals("hola")
haz
"hola".equals(miCadena)
Funciona igual y nunca te olvidarás de hacer la comprobación de no nulidad.

Posted by Juan Ignacio Sánchez Lara 13:48 Enlaces a esta entrada  



Técnicas ágiles

Las metodologías ágiles fracasarán, como todas las demás metodologías, porque en informática lo importante no son los procesos, sino el talento. Además, porque aprovecharlas probablemente significa olvidarse de CMMIs, ISOs y demás siglas que les gusta a los tipos encorbatados que impiden que las cosas se hagan como se debe.

Sin embargo, sus técnicas están aquí para quedarse:

  • Testing: hacer pruebas es poco costoso y muy beneficioso. Permite desarrollar más ágilmente, sin intervención de pesados servidores de aplicaciones. Detecta errores en cambios (¿cuántas veces las cosas dejan de funcionar y es el usuario el que lo detecta?). En Navegápolis listan herramientas de pruebas, a las que yo añado las siguientes:
    • JMeter: pruebas de carga y funcionales.
    • BadBoy: un Internet Explorer que permite "grabar macros" para después lanzarlas. Permite probar Javascript, y su proxy funciona incluso usando https y certificados de cliente (ya que se ejecuta "por encima del navegador", en vez de "por debajo" como el JMeter).
    • Unitils: un recubrimiento de JUnit y otras cuantas que como mínimo te facilita la vida hasta que todos (JUnit, Spring...) se pongan de acuerdo para funcionar de verdad juntos.
  • Integración Contínua: mantenme informado de cómo va el código de nuestro proyecto (¿compila al menos? ¿pasa las pruebas? ¿cumple las métricas? ¡avísame al messenger si hay problemas!)
  • Olvidarse de tantos diagramas UML, documentos de viabilidad, planificación, requisitos, análisis, diseño, presentaciones powepoint y demás basura que no sirve para casi nada, y "símplemente hacerlo (6:00)".
PD: el artículo citado antes enlaza a su vez con otro sobre procesos de obligada lectura, y saca de él una cita que no puedo menos que plagiar también:

Las pautas que en los entornos industriales logran eficiencia, en el software producen mediocridad.
Gestionar empresas del conocimiento con teoría de management industrial genera productos mediocres y técnicos desmotivados.

Posted by Juan Ignacio Sánchez Lara 10:37 Enlaces a esta entrada  



La Web: la piedra filosofal de la informática

La web pretende convertirse en los próximos años en la plataforma (casi) perfecta. Si hiciésemos una lista de características de una aplicación ideal podríamos indicar, por ejemplo, que no tuviese instalación, que pudiese acceder a ella desde cualquier sitio, que no necesitase conexión a Internet para funcionar, pero que la aprovechase si la tuviese, que se actualizase automáticamente (¡y gratis!), que facilitase el trabajo compartido...

La teoría es que esto se podría conseguir casi con cualquier lenguaje, pero sólo la Web ha conseguido meterse (hasta el tuétano) en nuestra vida. Así que, lo que a priori es una basura de plataforma (estándares ineficaces, implementaciones deficientes, problemas de seguridad, frameworks complejos, pocas herramientas útiles...) va camino de convertirse en los próximos años en la piedra filosofal. Google Docs viene anticipando desde hace meses la muerte de los paquetes de ofimática gracias a Ajax, pero la siguiente generación de navegadores se pretende convertir en una plataforma de ejecución mediante aplicaciones offline. La idea es tan "simple" como que los recursos se almacenen en una caché local con el rel="offline-resource".

Hasta ahora, por ejemplo, teníamos el Word OpenOffice, programado en C++ y compilado a código máquina, ejecutándose con el procesador interpretando este código. Periódicamente pirateamos emergemos la versión nueva, cuando vamos a otro ordenador, lo instalamos también...
En breve tendremos una nueva versión de Google Docs, que se ejecutará sobre el intérprete JavaScript de Firefox, que si estamos conectados a Internet ejecutará la ultimísima versión, y si no, la de la última vez que entramos. Nada de instalaciones, nada de actualizaciones... Sí, es más lento interpretar JavaScript que ejecutar código máquina, pero ¿para qué queremos si no estos fantásticos procesadores de n núcleos que nos venden?

Por si alguien no le da importancia, tanto Microsoft con Apollo como Adobe con Flex ya se han posicionado para dominar un mercado difícil de dominar. Incluso Dojo tiene un paquete para aplicaciones offline.

Posted by Juan Ignacio Sánchez Lara 16:39 Enlaces a esta entrada  



Pestañas

En términos de usabilidad, las pestañas son seguramente mi componente favorito. Aunque a Jacob Nielsen no le guste el (supuesto) abuso que se hace de ellas, son un modo fantástico de organizar la información. Por ejemplo, ahora mismo mi pantalla tiene dos grupos de pestañas: las de Firefox, que organizan las páginas de consulta para escribir este artículo, y las que Blogger utiliza para organizar la edición del blog. A Jakob Nielsen posiblemente estas segundas no le gustarían, ya que son de navegación, no para mostrar diferentes vistas de una misma cosa...

En el libro Don't Make Me Think les dedican unas siete páginas, que os paso a resumir:

  • Es una de las pocas metáforas que funcionan plagiadas directamente de El Mundo Real™: de un plumazo muestran la estructura de un elemento, organizan su información y permiten acceder de forma rápida a apartados específicos.

  • Son obvias, fáciles de usar y fáciles de comprender (en el fondo esto es repetir tres veces lo mismo).

  • Amazon fue uno de los primeros sitios en usarlas. En mi opinión, la parte del libro en el que hace un estudio sobre la evolución de las pestañas de Amazon es de obligada lectura para todo diseñador Web. No vayáis ahora a Amazon a ver cómo son, porque prácticamente las han suprimido, ya que se toparon con su principal problema, que es que...

  • ... escalan mal: más de siete pestañas casi siempre son demasiadas. Tanto por espacio físico como por el modelo mental que el usuario hace de ellas al usarlas.
En términos (web) prácticos, mi implementación favorita es la que tiene el portal hispano de Ubuntu, basada en listas de elementos, enlaces y CSS. La técnica queda descrita en este ejemplo de pestañas. Permiten tener varias líneas de texto, si desaparece el estilo queda html comprensible (buena accesibilidad, por tanto), vistosas (al usar imágenes de fondo, en vez de tablas), etc.

Sin embargo, al pensar en nuestra ¿querida? generación de páginas en Java y ahora que estoy metido hasta el cuello en JSF y Ajax, me abordaba una duda: ¿navegación tradicional (cliente-servidor puro), navegación cliente (sólo Javascript), o Ajax? La primera es lenta para el usuario, pero de fácil implementación. La segunda es la más rápida una vez cargada, pero la más lenta de carga, al generar todas. La tercera, un buen término medio, pero de compleja implementación... hasta que conocí las pestañas de RichFaces. Una vez superas ciertos problemas técnicos, se convierten en un perfecto 3 en 1. Con cambiar un parámetro cambias entre los tres modelos anteriores. La única pega, que son tablas :\ En cuanto tenga tiempo espero hacer un componente semejante, basado en Ajax4JSF como RichFaces, que implemente las pestañas elegantes de Ubuntu.

PD: me gustan tanto que las he metido en el blog (en formato cliente puro). Están arriba, sobre la imagen de cabecera, e iré recopilando en ellas las referencias, estándares y blogs que hacen del mundo del desarrollo de software un mundo un poco más llevadero.

Posted by Juan Ignacio Sánchez Lara 16:01 Enlaces a esta entrada  



JSF (Una historia de amor y odio sin final todavía)

Conocí a JSF en medio de una relación. Llevaba un par de años con Struts. Al principio me había parecido (Struts) engorroso y pesado (venía de un largo affair con PHP), pero una vez conocí a sus parientes Validator y Tiles, me ganó. Me acabó convenciendo la potencia de utilizar ficheros de configuración para casi todo, y su orientación a las acciones me parecía una forma natural de programar en MVC.

En un viaje a la capital me presentaron a JSF, y mi impresión no pudo ser más tibia. Tenía la sensación de estar haciendo lo mismo, pero de otra manera, con ficheros de configuración que no me aportaban nada, y con etiquetas menos potentes que antes. Además, no vino solo, sino que iba acompañado de Spring e IBatis, haciendo que romper el hielo fuese todavía más difícil. ¿Qué me aportaba pensar en componentes en vez de en acciones?

De repente, un tercero se cruzó en mi camino y lo ví claro: Ajax. Todo cobraba sentido. Un campo de texto nunca más sería una caja vacía hasta que alguien pulsa el botón. Ahora, un campo de texto despliega sugerencias, se conecta al servidor para validarse de forma asíncrona, activa y desactiva partes de la página... Y si quieres programar esto de forma productiva, JSF es la elección.

Hasta aquí, la bonita historia de amor que se ve. Lo malo es cuando lees entre líneas. JSF es un estándar limitadísimo en términos de componentes (y no sólo lo digo yo). Es tan solo un framework sobre el que montar algo más interesante. Nació en el 2004 como la oferta de Sun ante el despropósito de J2EE al programar aplicaciones web, pero no ha sido hasta masificación de Ajax cuando se ha empezado a invertir en él.

Las implementaciones (MyFaces, Sun RI, Facelets...), frameworks (Ajax4JSF, ICEFaces, Tobago...) y librerías de componentes (RichFaces, Tomahawk, jMaki...) prometen mucho, pero en la práctica hacerlas funcionar es desesperante. Mala documentación, incompatibilidades, tener que recurrir a betas, sandboxes, nightshots...

Aún así, creo que ahora mismo la mejor opción para elegir un MVC si quieres Ajax es JSF. Concretamente, (MyFaces + Tomahawk (imprescindibles)) + (Ajax4JSF + RichFaces (potentes)). Los dos primeros proporcionan un conjunto base razonablemente estable y completo, y los dos segundos, toda la potencia de Ajax (aunque mezclar ciertos componentes con otras librerías es poco menos que imposible).

Se agradecerán sugerencias...

P.D.: MyFaces se mueve mucho. En el wiki hay un buen lote de artículos de JSF, MyFaces e incluso de integración con otras librerías

Actualización: leo en un blog un curioso gráfico del número de librerías Ajax existentes para diferentes tecnologías. La gráfica corrobora mi teoría de que, a pesar del caos de librerías, JSF es la opción para implementar aplicaciones Ajax.


Actualización 2: esa gráfica sale de una interesante comparativa de frameworks J2EE, muy actualizada

Posted by Juan Ignacio Sánchez Lara 15:30 Enlaces a esta entrada  



Nuevo borrador de WCAG 2.0

El Web Content Accessibility Guidelines Working Group (WCAG WG) es la máxima autoridad de Internet en términos de accesibilidad. Suyo es el único estándar de usabilidad reconocido internacionalmente (y legalmente), el WCAG 1.0. El problema es que ese estándar es de 1999, y está totalmente desfasado. Está orientado únicamente a accesibilidad en contenido web, pero, ¿qué ocurre con las aplicaciones web?

Las aplicaciones web no son comparables a las páginas a las que fue destinado aquél estándar hace ya 8 años. Las aplicaciones web no son (principalmente) un medio de distribución de contenido, sino que son un sustituto de las aplicaciones de escritorio, no se puede aplicar las mismas reglas. Especialmente ahora que todos nos volcamos en Ajax para hacerlas más usables, rápidas y cómodas.

Hoy se ha publicado un nuevo borrador del siguiente estándar, WCAG 2.0, llamado a sustituir al primero y permitir el uso de estas nuevas tecnologías. Sólo queda que tarde o temprano se convierta en estándar estable (lo llevan prometiendo desde el 2005), y al fin se podrá cumplir la ley, proporcionando aplicaciones accesibles, sin tener que renunciar a los últimos avances en desarrollo web.

Esto hará, además, que se sustituyan las aplicaciones de escritorio (las cuales nunca fueron objeto de legislación sobre accesibilidad) por otras, basadas en tecnologías web, que acercarán la informática a usuarios con discapacidades.

Posted by Juan Ignacio Sánchez Lara 19:20 Enlaces a esta entrada  



Metodologías ágiles

Algo va mal cuando nadie quiere utilizar metodologías pesadas como RUP o METRICA. Algo va muy mal cuando, siguiendo esas tecnologías, se hace lo que buenamente se puede en el tiempo disponible y después los diseños no se utilizan en la construcción, ya sea por incapacidad del autor o del programador (o de ambos).

Desde hace años existen las metodologías ágiles de desarrollo de software. Algún profesor de Ingeniería del Software nombraba XP (eXtreme Programming) con la boca pequeña, como aquella cosa que hacen los que no saben nada más que programar. Sin embargo, cuando lees ingenieros de Microsoft que a todas horas hablan de Scrum, o incluso de Cuales, algo notas que está cambiando.

Hoy, para echar más leña al fuego, aparece la noticia de que Oracle compra Agile Software Corp., una empresa que desarrolla herramientas de soporte para procesos ágiles.

Cuando el río suena...

Posted by Juan Ignacio Sánchez Lara 21:08 Enlaces a esta entrada  



DRY: Breve guía para mantenerse seco

Hace años un profesor de Bachiller nos contaba que hay unos pocos principios que explican la gran mayoría de los fenómenos de la naturaleza. La ósmosis, el principio de conservación de la energía y otros pocos son capaces de modelar una gran parte de lo que vemos.

Pienso que en informática pasa lo mismo. Pese a los cientos de lenguajes de programación, librerías y plataformas que existen, los fundamentos que hacen de ellos una buena herramienta son muy parecidos. Entre ellos el que más importante me parece es el "principio DRY": Don't Repeat Yourself. Repetirse supone trabajar más (un buen programador debe ser vago), duplicar los errores, reducir la mantenibilidad del código, hacer más costosos los cambios... De ahí la gran frase de "Cada vez que cortapegas, Dios mata un gatito".

Mi entorno de trabajo desde hace unos años es J2EE, y para mantenerme seco utilizo estas herramientas:

Hibernate: minimizar el código de acceso a datos.
Hibernate Validator: aprovechar la especificación de persistencia para comprobar la validez de los datos recogidos en formularios, y mostrar mensajes adecuados. Y si no usas Hibernate, al menos usar Commons Validator.

"Trocear las páginas", ya sea con Tiles (imprescindible si usas Struts) o componentes (la mejor forma de reutilización en JSF).

Uso intensivo de CSS para la presentación. Nada de aprovechar CSS para mejorar la apariencia, sino componer las páginas independientemente de la presentación, delegando al 99% en los estilos (el 1% restante es para apaños para el IE).

Posted by Juan Ignacio Sánchez Lara 19:02 Enlaces a esta entrada  



Ideas + Ingeniería del Software


/**
* Blog sobre desarrollo de software.
*
* @author Juan Ignacio Sánchez Lara
* @version v0.00
* @since 070509
* @see http://juanignaciosl.blogspot.com/
*/
public class I2S extends Blog implements DesarrolloDeSoftware, J2EE {

//TODO: comentario ocurrente para el primer post de un blog sobre desarrollo.

//FIXME: faltan las librerías de chistes graciosos.

}

Posted by Juan Ignacio Sánchez Lara 20:03 Enlaces a esta entrada