¡Échense a temblar! ¿Alguien se acuerda de aquel famoso efecto 2000? Ya casi nadie. Ni siquiera yo, que en los últimos meses de 1999 me dedicaba a esto de la informática, he vuelto a recordar aquel timo que sirvió para que algunas empresas se forraran. En aquella ocasión no llegué a conocer ni un solo caso de fallo por culpa de esa anomalía. Y tampoco se cayeron los aviones, ni se colapsaron las redes informáticas, ni se fue la luz ni explotaron las centrales nucleares. Nada de nada. El tránsito entre el 31 de diciembre y el 1 de enero se produjo sin ningún incidente.

Pero los agoreros de la tecnología ya tienen pensado otro «efecto». Esta vez la fecha será el 2038 (queda mucho todavía), y no el último día del año, sino el 19 de enero a las 3 horas 14 minutos y 7 segundos. ¿Y por qué esa fecha y hora concretas? Antes que nada hay que explicar algunos asuntos técnicos. Los lenguajes de programación con los que están construidas las aplicaciones y sistemas operativos que utilizamos tienen tipos de datos. Estos tipos sirven para almacenar información de uso interno para el programa (por ejemplo un contador que cuente el tiempo transcurrido, textos introducidos por el usuario o datos de control para el flujo interno de la aplicación entre otros). Pues bien, existe un tipo de datos donde se almacenan los segundos transcurridos desde el 1 de enero de 1970 a las 00:00. Es una forma de calcular la fecha actual en POSIX. Este sistema se da exclusivamente en UNIX y sus derivados.

La cuestión es que ese tipo de datos donde se almacenan los segundos tiene 32 bits (2³¹ combinaciones, porque el bit 32 es el de signo -/+). Es decir, admite un rango de valores entre -2.147.483.648 y 2.147.483.647. El 19 de enero de 2038, el contador de los segundos llegará precisamente a 2.147.483.647. El siguiente segundo nadie puede prever lo que ocurrirá, pero es seguro que el tipo de datos se desbordará y dará un error. En el mejor de los casos, y si la aplicación está bien programada, la cuenta de segundos volverá a -2.147.483.648, lo que en cristiano sería el 1 de enero de 1970. Eso al menos son los resultados que se han obtenido en las pruebas que se han realizado. Y en el peor pues… mejor que no pensemos, pero puede producirse una hecatombe a niveles planetarios.

Aunque esto hoy puede alarmarnos, es posible que para entonces todos los sistemas informáticos hayan sido ya renovados y el sistema operativo y las aplicaciones estén preparadas contra el «efecto 2038».

Este titular es lo que mejor define este fantástico entorno integrado de programación de la compañía REALSoftware. Primero, es multiplataforma. Esto implica que no importa el sistema operativo sobre el que estemos programando, ya que podremos compilar nuestra aplicación tanto en Mac OS X (Intel, PowerPC o binario universal), MacOS 9, Windows 98 y posteriores o Linux con GTK+ 2.x (librería gráfica) a partir de un sólo código fuente y sin tener que modificarlo. Esto supone una característica muy potente. Aunque por las pruebas que he hecho el interfaz no se ve exactamente igual, con un poco de práctica es fácil conseguir un look & feel similar en todas las plataformas.

Y segundo, es sencillo y rápido. REALBasic, como su propio nombre indica, está basado en Basic, más concretamente en Visual Basic, aunque mantiene importantes diferencias respecto a la herramienta de Microsoft. Reconozco que estoy muy acostumbrado a programar en Visual Basic y echo en falta muchas funciones que facilitaban bastante las cosas. Todo se soluciona teniendo el manual de referencia a mano. Cuestión de adaptarse. Una de las cosas que echo de menos es el autocompletar, que me ayudaba mucho a elegir la propiedad o el método adecuado de cada objeto.

Otra de las cosas relacionadas con la sencillez es que los ejecutables que genera para Windows no necesitan de ninguna librería externa. Todo va «empaquetado» en un archivo .exe. Esto implica un aumento de peso en el archivo, pero merece la pena sacrificar espacio en aras de una menor complicación.

En conclusión, REALBasic es una herramienta que ya es una seria alternativa a otro tipo de programación, sobre todo para Mac, donde no hay muchas alternativas para crear aplicaciones de escritorio más allá Cocoa, pero necesita todavía algunas iteraciones para ser una entorno «maduro».

Las alternativas a Windows están cobrando cada vez más importancia, bien sea por decantarse hacia el software libre con Linux o bien hacia el mundo Mac. Lo cierto es que a la hora de diseñar un nuevo sitio web, estos usuarios no mayoritarios han de ser tenidos en cuenta. Pero claro, cada plataforma tiene su idiosincrasia y su forma de interpretar las instrucciones que han de aparecer en pantalla (renderizar). De todos es conocida la rebeldía de Internet Explorer a la hora de seguir los estándares establecidos por la W3C y que siguen el resto de navegadores sea cual sea el sistema operativo sobre el que se ejecutan. A menudo me he llevado sorpresas desagradables después de haber terminado un diseño web y probarlo en otras plataformas diferentes a Windows o ahora a Mac.

Pero desgraciadamente no todo se soluciona con seguir los estándares. Mi último quebradero de cabeza es con las fuentes estándar o fuentes «seguras» que se utilizar para maquetar las páginas web. Para quien no lo sepa, existe un reducido conjunto de tipos de letra que pueden ser utilizados con seguridad y que son aceptados por todos los sistemas operativos. Suelen agruparse en «familias» y se definen en los archivos de estilos CSS. Para definirlos, cada «familia» se compone de una lista de nombres de fuentes separadas por comas, de forma que el navegador al interpretar la página escrita con esa fuente coge la primera, si el sistema no la tiene pasa a la segunda y así sucesivamente. La última de la lista siempre es la opción «de emergencia», el estilo de fuente genérico (es decir, serif o sans serif). Las «familias» más clásicas y «seguras» son las siguientes:

• font-family: arial, helvetica, sans-serif;
• font-family: georgia, "Times New Roman", times, serif;
• font-family: "Times New Roman", times, serif;

Existen muchas otras combinaciones posibles, pero hay que tener mucho cuidado. De hecho, estas «familias» que consideraba como seguras me han dado más de un dolor de cabeza a la hora de diseñar. He hecho la prueba a utilizar las mismas fuentes en los tres grandes sistemas operativos: Windows XP, Mac OS X y Linux Ubuntu. Los resultados han sido tan diferentes que me he tenido que replantear la forma o las fuentes que son seguras y las que no. El caso de Ubuntu es muy llamativo. La versión que he probado lleva las fuentes de la suite ofimática Open Office 2.3. Curiosamente ninguna se llama Arial, Helvetica, Times New Roman, Times, Verdana, Georgia o nada que se le parezca, con lo que las listas de antes de poco sirven en el sistema del pingüino. La fuente sans serif por defecto en este caso es la Free Sans, una especie de Helvetica «libre» que más o menos da el pego, la serif más parecida a la Georgia es Bitstream Vera Serif, y para sustituir a la Times/Times New Roman tenemos la Nimbus Roman No9 L.

He aquí los ejemplos de las tres familias de antes en Windows XP SP2, Mac OS X Tiger y Linux Ubuntu 7.10. Primero la renderización de fuentes en Windows:

En Mac:

Y en Linux Ubuntu con las fuentes sucedáneas «libres»:

Las diferencias son apreciables en cuanto al interletrado, a la forma de la propia fuente y sobre todo a la longitud del párrafo dependiendo del sistema operativo usado. Estas variaciones en bloques grandes de texto puede suponer el descuadre de las columnas, eso sin contar la sensación antiestética que provoca y que a mí me molesta bastante.

Desde que tengo el Mac he tenido ganas de hincarle el diente al tema de la programación bajo esta plataforma. Así que me puse a recopilar documentación sobre las posibles alternativas que existen para los desarrolladores. La principal de ellas y la digamos «oficial» es Cocoa. Bajo este nombre se esconde la API del sistema operativo Mac OS X, es decir, un conjunto de funciones que manejan todo los aspectos del sistema. Los lenguajes para poder utilizarlas son C++, Java u Objective-C. La mayoría de tutoriales que he encontrado por la red hacen referencia a este último.

Así que hace unos días instalé XCode, que es un conjunto de herramientas incluidas en los discos de instalación para desarrollar bajo la plataforma de la manzana. A parte de la propia XCode, me puse a juguetear un poco con Interface Builder que, como su nombre indica, sirve para construir todo el interfaz gráfico al más puro estilo Mac. Hasta ahí todo fue bien y muy intuitivo.

El problema surgió cuando vi que la mecánica para establecer las relaciones entre código y controles de ventana no tenía nada que ver con otros entornos integrados para Windows. No digo que fuera difícil, pero sí muy diferente. Nada de poner nombres a los controles para luego referenciarlos en el código, aquí todo funciona a través de flujos de entrada (inlets), flujos de salida (outlets) y acciones. Las asociaciones entre estos flujos y los controles se hacen gráficamente. Las acciones se asocian generalmente a los botones. Y, como no tengo más que ligeras nociones de Objective-C, me perdí un poco a la hora de captar el flujo de entrada, darle contenido a las acciones y devolver el resultado en el flujo de salida.

Me parece que para un uso profesional para aplicaciones de cierta entidad, el uso de XCode está bien, pero a los que venimos de la «vieja escuela» de Windows y sólo queremos programar ocasionalmente por puro placer quizás nos resulte demasiado aparatoso. Habrá que hacer un nuevo intento, esta vez con el RealBasic 2007.

Ahora que la W3C trabaja en una nueva versión de HTML, la 5ª ya, y ha arriconado el XHTML, es posible que nos encontremos en un nuevo punto de inflexión, o más bien una vuelta atrás diría yo. Y es que hubo un tiempo (no muy lejano) en el que el HTML no tenía una «X» delante. Se usaba con profusión el javaScript y estaba de moda poner en una esquinita «Made for Internet Explorer». El CSS sólo se utilizaba para cambiar los colores de las fuentes y se maquetaba con tablas.

Luego las cosas cambiaron y nos dimos cuenta (con razón) que para crear una web bien hecha había que separar el contenido del aspecto y que debíamos escribir el HTML (ahora XHTML) por un lado y el CSS (aspecto visual) por otro. El javaScript sólo se debería utilizar en caso de no tener otra opción y el target="_blank" era poco menos que una herejía. Nos sometíamos (sometemos en mi caso) al estricto cumplimiento de las normas mediante los temidos validadores.

Pero he aquí que las cosas cambian otra vez. La moda de la web 2.0 implica tener webs mucho más dinámicas, que muestren la información sin recargas, que permitan interactuar con formularios y otros elementos sobre la marcha y controlar nosotros mismos a través de código la navegación y el comportamiento de la web. Así que rescatemos nuestras chuletas sobre el modelo de objetos DOM, volvamos al javascript a mansalva y odiemos otra vez los botones del navegador. ¡El DHTML ha vuelto!

El pasado 10 de agosto, el W3C, la organización encargada de velar por los estándares que rigen la implementación de internet, presentó el último borrador de trabajo sobre HTML 5. En los últimos tiempos estamos viendo grandes avances en desarrollo web «no estándar». Estos estándares se estaban empezando a quedar obsoletos. No en vano, la última versión de HTML, la 4, fue publicada en 1999 y no fue implementada por todos los navegadores web hasta algún tiempo después. Desde entonces las cosas han cambiado mucho. La capacidad y las funcionalidades de internet ha aumentado muchísimo. Ya no sólo mostramos textos o imágenes. Ahora también hay vídeos o interacción con otros dispositivos. Es necesaria una mayor sencillez y potencia.

HTML 5 llegará para solucionar en parte estos aspectos. Aunque desgraciadamente siempre irá por detrás de las tecnologías propietarias. Me he molestado en echar un vistazo al borrador y me han llamado la atención la gran cantidad de cambios que se producirán con respecto a versiones precedentes. Algunos de ellos afectarán directamente a cómo estructuramos los documentos HTML. Por ejemplo etiquetas como <header> para definir la cabecera de la web, <footer> para definir la información de la web en el pie del documento o <section> para establecer las diferentes secciones de una web, independientemente de los bloques o <div>.

Otros elementos que cambian el concepto de escribir documentos HTML son <article> para definir recortes de otros artículos (vendrá a sustituir en cierta medida a <blockquote>, <dialog> para escribir diálogos con una estructura similar a las listas de definiciones, o <figure> que será un contenedor para referenciar cualquier elemento de imagen o vídeo.

Los controles de formulario tampoco se salvan de esta reforma. Las listas de opciones, listas desplegables o como queramos llamarlo pasan de ser <input list=...> a <datalist id=...>.

Existen otros muchos cambios que no son menores, ya que afectan al concepto mismo de la web. Por ejemplo <progress> nos permitirá a través de un parámetro actualizado dinámicamente mostrar una barra o un porcentaje de progreso de carga de algún elemento del documento. Mi intención no es hacer un repaso exhaustivo de HTML 5. Para quien esté interesado, en este artículo se comenta más pormenorizadamente todos los cambios y novedades de la nueva versión y aquí está el borrador completo en inglés de la nueva definición de HTML.

Que el mundo de la programación web está cambiando es algo que ya nadie duda. Ahora XHTML ya no es la moda y ha perdido prestigio frente al HTML de toda la vida. La aparición de nuevas tecnologías y lenguajes (léase Ruby, Flex, AJAX y otras) hace que a la hora de comenzar un nuevo proyecto uno se plantee qué herramientas utilizar. Este es el dilema que me ha surgido a mí al comenzar la nueva web de Zamora en Imágenes. Durante los últimos días me he leído varios manuales y tutoriales de Flex Builder 2. Uno de los problemas, que era la conexión con bases de datos, está ya resuelto a través de la utilización de servicios web y XML. Voy a hacer una reflexión en voz alta sobre las ventajas e inconvenientes de utilizar bien Flex+XML+PHP+MySQL por un lado o XHTML+CSS+PHP+MySQL.

Adobe Flex

Ventajas:

• Mucha libertad y facilidad para diseñar la distribución de los elementos.
• Independencia de la plataforma. Al estar basado en Flash, todas las webs realizadas con Flex se ven igual sin importar navegador o sistema operativo.
• Tecnología pensada para diseñadores. Pueden añadirse efectos visuales espectaculares que ofrecen más dinamismo y versatilidad a la web.
• Poca programación. Aunque en mi caso de todos modos no tendría que programar demasiado, con Flex esta tarea quedaría reducida a unas pocas líneas de MXML.

Inconvenientes:

• Problemas de usabilidad. Adobe Flex es todo lo contrario a los estándares de diseño web. A Jakob Nielsen no le gustaría nada. Esto también supone un problema a la hora de ser indexado por los motores de búsqueda de internet.
• Es necesario un ordenador medianamente potente. Las últimas versiones de Flash Player pueden funcionar lento en ordenadores antiguos.
• Empezar el proyecto de cero. La actual web de Zamora en Imágenes está escrita en PHP. Un nuevo proyecto en Flex supondría no poder reutilizar ese código.
• Tecnología propietaria. Flex no es de código abierto. Aunque el framework es gratuito, su propietario es Adobe.
• Aún no estoy demasiado familiarizado con, por ejemplo, la personalización de los controles en Flex. El desarrollo podría ser mucho más lento que con XHTML+CSS.

PHP+MySQL

Ventajas:

• XHTML+CSS cumple todos los estándares de la W3C y es accesible desde cualquier navegador.
• Páginas web más ligeras. Menor tiempo de carga.
• Ya he desarrollado varias páginas web con PHP+MySQL y la experiencia es un grado.
• Poder reutilizar el código de versiones antiguas de Zamora en Imágenes.

Inconvenientes:

• Diseño más laborioso. Para construir un buen CSS con todas las etiquetas necesarias redefinidas es necesario invertir mucho tiempo.
• Diseños menos vistosos.
• Necesidad de recargar la página para ofrecer los datos. Es posible utilizar capas dinámicas con AJAX, pero eso sí sería meterse en camisa de once varas.
• Es difícil conseguir que la web se vea igual en todos los navegadores y plataformas. Más de una vez, los detalles pueden llevar a la ruina un proyecto por culpa de la diferencia abismal en la renderización de las páginas.

Aún tengo que profundizar un poco con Adobe Flex. Sin duda es una tecnología muy prometedora. Sin ir más lejos, en 20 minutos y sin tener casi ni idea he conseguido a la primera escribir un servicio web en PHP que me sirva datos en XML a partir de una base de datos MySQL y los muestre en una rejilla de una página Flash. Es un buen comienzo, pero todavía queda mucho camino por recorrer.