• Existe un tiempo universal llamado UTC que se basa en relojes atómicos.
• Por razones astronómicas UTC agrega/quita segundos a años arbitrarios.
• El protocolo NTP permite sincronizar la hora UTC vía Internet con una gran precisión.
• UTC sirve de referencia a la zona horaria de cada país/región. Ej: la hora estándar de Chile es CLT ó UTC-04.
• Muchos países tienen un cambio de hora o horario de verano. Ej: la hora de verano de Chile es CLST ó UTC-03.
• Por razones políticas/económicas/etc cada país ha variado el tiempo de referencia UTC antojadizamente. Este año (2011), Chile movió el cambio de hora en 3 semanas.
• La base de datos Olson contiene la información de qué zona horaria es válida para distintos rangos de fechas. Esta base de datos es continuamente actualizada por un grupo de voluntarios en una lista de correo.
• NTP no contiene información de zonas horarias ni actualiza el cambio de hora. Los cambios deben hacerse manualmente.
• En el mundo globalizado de hoy, los informáticos deben entender cómo manejar el tiempo mundialmente. Por ejemplo, es recomendable usar el formato ISO-8601

En el presente artículo intentaré explicar los problemas implicados por el (mal) manejo del tiempo. También la forma en que se resuelven y cuales aún no están resueltos. La idea es generar discusión y (ojalá) generar soluciones (que son bastante obvias) para cada problema en particular.

El error de ignorar el problema

Mucha gente cree que el problema se reduce a eliminar las modificaciones al cambio de horario invierno/verano. Que siempre sea la segunda semana de Marzo/Octubre y ya está. Creen que el tema se soluciona pidiendo a los gobiernos que dejen de ser tan desordenados y que, por favor, paren con mover el cambio de hora apenas dos semanas antes de que ocurra.

Para recalcar que los cambios de horas son inevitables, aquí un resumen del número de cambios al archivo tzdata de la base de datos Olson:

Cada versión nueva del archivo tzdata incluye mayoritariamente una o más modificaciones a zonas horarias hechas por gobiernos de todo el mundo. Incluso, si los gobiernos dejaran de cambiar la hora antojadizamente, tenemos el problema latente de los segundos intercalares (“leap seconds“).

Pero pedir a los gobiernos de todo el mundo que dejen de modificar los cambios de hora es completamente irreal. Aún si nos escucharan, tenemos el caso latente de los segundos intercalares. Sería como pedir a la gente que deje de tener accidentes vehiculares, pues los autos no tienen cinturones de seguridad. O pedir al planeta que gire siempre con la misma velocidad. La informática debe adaptarse a la realidad, no al revés.

De la tabla, observamos que hay al menos 5 cambios por año, pero sin embargo los informáticos gritan, pelean y se preocupan con suerte una o dos veces al año. Lo que sucede es que este cambio es increíblemente complicado y costoso (veremos esto a continuación). Y cada sitio se preocupa exclusivamente de la hora local en el país en que está, por ejemplo en Chile a nadie le interesa actualizar un cambio de zona horaria en Afganistán. Es por esto que Google y muchos servicios “en la nube” están mostrando mal los calendarios que quedaron agendados estas semanas en Chile: es muy complicado/es muy caro/que lo resuelvan los usuarios. En resumen, a nadie le importa.

Por qué es tan costoso modificar el cambio de hora invierno/verano

Primero, por un tema de volumen. La cantidad de aparatos y sistemas informáticos no paran de crecer. Cada vez se hacen más invisibles, pero estamos rodeados de sistemas y aparatos: un scanner médico, tu celular, el cajero automático, el reloj del control horario, y un largo etc..

Segundo, por un tema de diversidad: la hora es entregada por el sistema operativo y no todos los aparatos usan el mismo sistema operativo. Luego, el procedimiento es distinto para cada tipo de aparato o sistema informático. Peor aún, la gran mayoría de los sistemas no tiene incorporado la funcionalidad para realizar una modificación al cambio de hora. Es un problema aún no resuelto en el mundo de la informática. Es decir, aparte de realizar la modificación, tendremos que analizar los datos del sistema para que ahora estén correctos con el nuevo horario.

Esto significa que cada modificación al cambio de hora se transforma en un mega proyecto informático que involucra a todos los computadores de cada instalación y a todos los sistemas informáticos. Y los gobiernos anuncian la hora con apenas un par de semanas antes de la fecha en que ocurre el cambio de hora automático. Un par de semanas antes de que ocurra el cambio es insuficiente para un cambio de esta envergadura. Ninguna empresa está preparada para tremendo proyecto en un par de semanas.

Lo que sucede en la práctica es que la gran mayoría de sistemas falla y presenta una hora incorrecta o información incorrecta.

Además, la precisión o calidad con que los sistemas manejan la hora local/mundial varía bastante. Por ejemplo, el soporte a UTC de los sistemas operativos Microsoft es bastante deficiente: modifican la hora del PC en vez de tener el reloj en UTC y cambiar la representación (esto es fatal para que NTP calcule correctamente la desviación respecto a los relojes atómicos) y no tienen soporte a segundos intercalares. Es probablemente por esto que nunca verás un sistema Windows manejando aparatos que requieren exactitud en este tema, como aparatos astronómicos, de navegación, etc.

Debido a que muchos sistemas operativos lo hacen de manera deficiente, hay mucho software que no usa lo que trae el sistema operativo e incluyen el código de Olson. La máquina virtual de java, servidores MySQL, PHP y un largo etcétera tienen su propio sistema con su propio archivo basado en tzdata. Es decir, para realizar el cambio debemos asegurarnos cada una de las siguientes capas:

1. En el sistema operativo
2. En cada uno de los subsistemas y plataformas: bases de datos, plataformas de desarrollo, API’s y middleware
3. En las aplicaciones
4. En los datos que tienen las aplicaciones

Actualmente, los sistemas UNIX resuelven sólo la primera capa, el sistema operativo: las actualizaciones al archivo tzdata se pueden automatizar sin mucha dificultad. Esta modificación sigue siendo bastante costosa (y muchas veces es simplemente imposible), pero la automatización facilita bastante. Pero las capas 2, 3 y 4 no están contempladas por nadie actualmente. La mayoría de las veces simplemente se ignoran.

Finamente, un par de semanas es insuficiente para que cada proveedor genere un parche a los sistemas. En UNIX usualmente este parche está disponible entre 1 o 2 semanas después de anunciado el cambio de manera oficial, lo que en la práctica implica que el mismo día del cambio se están parchando todos los servidores. Los parches de Microsoft se demoran 1 o 2 meses en salir, en la práctica no hay parche oficial y se debe realizar modificaciones al sistema de manera manual. Apple demora 3 a 4 meses en liberar un parche, tu iPhone se quedará con la hora incorrecta simplemente.

Las soluciones “obvias”

1. Exigir a los gobiernos que los cambios de hora deben ser anunciados con al menos 8 semanas de anticipación. Esto permite que los proveedores generen un parche a tiempo. Esto no quita el costo, sino que nos permite alcanzar los aparatos y sistemas que simplemente se ignoran cuando un cambio es repentino. Recuerden que esto toca a todos los aparatos y sistemas informáticos.

Nota de borrador

Este artículo está en borrador y he decidido lanzarla antes, debido a la urgencia que tenemos hoy en que el Gobierno de Chile intenta mover el cambio de hora a solo 5 días de que este ocurra.

Invito a las autoridades que me inviten a su despacho, yo personalmente les puedo explicar con detalles la gravedad del problema.

Me interesa hablar de los siguientes temas:

1. Muchos sistemas no están preparados para trabajar con distintas zonas horarias. En un mundo globalizado, creo que es inaceptable.
2. Peor aún, creo que ninguno contempla las (irremediables) modificaciones a los cambios de hora arbitrarios.
3. El tiempo de referencia oficial no es GMT, sino que UTC.
4. Existen minutos con más de 60 segundos (y eventualmente con 59 segundos).
5. NTP no tiene nada que ver con el cambio de hora, la zona horaria ni el horario de invierno/verano.
6. Los sistemas deben dejar de usar el formato DD/MM/YY.
7. Este es un problema aún no resuelto, pero se puede mejorar en varios aspectos.

Si le asombra una o más de las sentencias de arriba, lo invito a seguir leyendo.

El tiempo, unidad de medida continua y regular

El primer supuesto que toma la mayoría de sistemas informáticos es que el tiempo es completamente continuo y uniforme en todo el universo. Esto no es cierto (ya tendremos problemas cuando los viajes espaciales se hagan habituales), pero por ahora asumiremos esto.

Al tomar el tiempo de esta forma, podemos suponer que en cualquier parte del mundo es la misma hora. Podemos definir una “hora universal“. Cada país puede tener su hora oficial en referencia a la hora universal, y es lo que nos permite coordinar una reunión en Chile a las 09:00 hrs por la mañana con gente en Finlandia a las 14:00 hrs en la tarde. ¡Fácil y bonito! ¿No?

Bueno, no tanto, pues ahora comienzan las complicaciones…

Es UTC, no GMT… por favor

Variación día solar medio (fuente: Wikipedia)

Desde 1880+ la hora universal era calculada en base al tiempo solar medio. Esto es: se observa astronómicamente cuánto demora la tierra en dar una vuelta completa sobre si misma. Ese tiempo lo dividimos en 86400 segundos y ya está, tenemos hora oficial con la cual todos podemos sincronizarnos. Esto es lo que se conoce como GMT, pues es la hora en el meridiano de Greenwich.

El problema es que el tiempo solar medio es bastante irregular, no es para nada una medida estable. Si observan el gráfico, en general cada año la tierra gira mas lento y los días se van alargando, pero hay distintos fenómenos que modifican la velocidad en ambos sentidos (por ejemplo, los terremotos).

Esta variación en la medida de tiempo es inaceptable para muchas aplicaciones y sistemas. ¡Imaginen tener que parchar continuamente sus sistemas para redefinir el largo de un segundo!

Desde 1972, GMT es reemplazado por un nuevo estándar de tiempo universal: UTC que en inglés reza “Coordinated Universal Time” y en francés: “Temps Universel Coordonné”. O sea, no lograron ponerse de acuerdo en las siglas.

En UTC el largo de un segundo siempre es el mismo, pues está basado en relojes atómicos. Esto es muy ventajoso, nos permite tener muchos sistemas sincronizados con muy poco error, incluso a la milésima de segundo. Ya no es necesario ajustar los sistemas a los caprichos del tiempo solar medio. ¡Menos mal!

Lo relevante es que hoy en día UTC es el tiempo universal usado como referencia por todos los países. Esto es importante por las triquiñuelas que tiene, veamos.

Segundos intercalares o en sintonía con la tierra

En UTC tenemos segundos (y milisegundos, microsegundos, etc) estables. El problema de tener un segundo estable es que la tierra cada vez gira mas lento. A lo largo de los años, las 12:00pm de nuestro sistema informático será muy distinta a las 12:00pm astronómica. UTC resuelve esto haciendo que la duración de los minutos, horas y días sea variable.

Bueno, la mayoría de los días tiene 86400 segundos, pero hay días que tienen 1 segundo adicional. El último minuto, de la última hora del día en vez de 60 puede tener 61 segundos, y este segundo extra es llamado “segundo intercalar” (leap second en inglés). Es decir, el 31 de Diciembre de 2008 a las 23:59:60 UTC es una fecha válida.

No es tan raro si piensan que tenemos algo muy parecido con los días: Febrero 29 para los años bisiestos.

Puedes ver una lista de los segundos que han sido agregados en wikipedia, ya van 24 a la fecha. Como recordarán, la tierra cambia de velocidad irregularmente, no es algo que se pueda pre-calcular. Luego, se han agregado segundos intercalares arbitrariamente según observaciones astronómicas del movimiento de la tierra. También está contemplado que existan minutos con menos de 60 segundos, por si se diera el caso que la tierra gire más rápido, cosa que no ha ocurrido.

Ejemplo de segundo intercalar (Wikipedia)

Notar en la imagen que el segundo adicional es agregado a las 23:59:59 de la hora universal, pero localmente el segundo adicional será a medio día, a las 4 de la tarde, etc dependiendo de tu zona horaria.

Esto tiene enormes implicancias en los sistemas informáticos. Por ejemplo, si tu aplicación suma 60*60*24*30 segundos para decir “30 días a partir de hoy” lo estás haciendo mal, el resultado puede caer en el día 29 si te topas con el segundo adicional.

Es por esto que siempre debes utilizar un API que maneje segundos, días, meses y años “gregorianos“. Por favor, no lo hagas tú manualmente. Y espera, que el manejo del tiempo se complica más. Aún no terminamos.

Sincronizando el tiempo

El siguiente problema a resolver es cómo mantener nuestros sistemas sincronizados, esto es, con la misma hora y con la menor diferencia posible. Para esto existe el protocolo NTP (Network Time Protocol), el cual consiste en servidores que dan la hora y clientes que intentan sincronizarse con dichos servidores.

Si bien esto parece trivial, no lo es. De partida, la latencia variable en internet hace que los paquetes lleguen desordenados y varios milisegundos después (una vuelta completa desde Chile a EE.UU es al menos 150ms). El protocolo NTP debe compensar este hecho. Luego, es más complicado que copiar la hora de un servidor a otro (¡como muchos lo hacen!), pues el error se amplifica rápidamente.

Tal vez encuentres que un segundo no es tanto y para qué tanto escándalo. Pero hay muchas, demasiadas aplicaciones que no funcionan bien si no tienes relojes muy, muy bien sincronizados. Y en el resto, lo deseable es que la diferencia sea a lo más de unos 100 milisegundos. Si eres un administrador de sistemas, querrás por muchas razones tener los servidores y dispositivos con la misma fecha y hora.

El tema es tan importante, que el cliente NTP no llega y copia la hora del servidor. Sucede que el reloj de tu computador no es tan exacto comparado con un reloj atómico, por lo que tiene un error (supongamos -10 milisegundos cada 30 días). Entonces, el cliente NTP lo que hace es calcular ese error.

Puedes programar que tu computador inunde de consultas el servidor NTP y copie la hora (esto se llama SNTP), pero tendrás una precisión muy, muy mala y no es lo recomendado.

NTP stratum (fuente: Wikipedia)

Tal vez te estás preguntado cómo los servidores principales mantienen la hora tan bien. Los computadores que están conectados directamente a un reloj atómico están en Stratum 0. Luego están los servidores NTP conectados a ellos, y son Stratum 1. Y luego los servidores que consultan a los anteriores, que son Stratum 2 y etcétera.

Lo ideal es que tengas en tu datacenter un servidor NTP que hable directamente con ntp.shoa.cl (la hora oficial en Chile), y luego todos tus servidores/computadores/etc se conectan a este servidor. Tendrás diferencias muy pequeñas dentro de tu red y no saturarás al servidor oficial.

Por último, el protocolo NTP sólo da la hora universal (UTC, incluyendo segundos intercalares). Pero NTP no tiene nada que ver con la hora local de tu país ni si estamos en el horario de verano. Este problema lo veremos a continuación.

La hora en el mundo

Hasta ahora tenemos una hora oficial (UTC), correcciones arbitrarias (segundos intercalares) y un mecanismo de sincronización (NTP). Podemos definir distintas zonas horarias respecto a la hora universal UTC.

Zonas Horarias según base de datos TZ (fuente: Wikipedia)

Debemos considerar que las zonas horarias están definidas por límites políticos y no por el meridiano que nos corresponda. La diferencia horaria se escoge antojadizamente y no tiene relación con la “real”. En el caso de Chile, por longitud estamos dentro de la zona UTC-5, pero la hora estándar en Chile continental es UTC-4. Hay países que tienen más de una zona horaria: por ejemplo, Chile tiene además hora insular UTC-6, México tiene 3 zonas, etc.

Hoy en un mundo globalizado, una gran mayoría de sistemas informáticos almacenan y trabajan la hora en formato UTC. Esto garantiza que un evento se pueda mostrar en distintas zonas horarias del mundo. Por ejemplo, si tenemos una reunión el Lunes 9 de Mayo de 2011 a las 09:00 am CLT (UTC-4), el sistema almacena el evento con fecha Lunes 9 de Mayo de 2011 a las 13:00 pm UTC. Si el usuario está en Chile, se despliega la hora de la reunión restando 4 horas a la hora UTC; o en Ciudad de México la reunión se desplegará Lunes 9 de Mayo de 2011 a las 07:00 am CST (UTC-6).

Aparte de almacenar la hora UTC de un evento, otra opción válida es almacenar la hora local incluyendo la zona actual. Por ejemplo Lunes 9 de Mayo de 2011 a las 09:00 am CLT (notar CLT, que indica que la hora local está a UTC-4). Les debo la explicación de por qué esto es mejor que guardar UTC-4 o traducir a UTC.

Arbitrariedad y el Horario de verano

Esto no sería nada de grave si hubiéramos llegado hasta aquí. El problema es que la definición de zona horaria es, ha sido y será antojadiza. Chile ha tenido zonas horarias UTC-5, UTC-4 y UTC-3 (pueden leer historia de la hora oficial). Por distintas razones económicas, políticas o las que sean. Lo único seguro es que seguirán cambiando, así como habrán más segundos intercalares en el futuro y no sabemos cuándo.

Además, tenemos el concepto de horario de verano que es usado por muchos países. Cada año en Octubre se modifica la zona horaria a UTC-3 (CLST o Chile Summer Time) y se restaura en Marzo a UTC-4 (CLT o Chile Time). Esta modificación de zona también es antojadiza y es susceptible a cambios repentinos.

Todo esto es un gran dolor de cabeza para toda la gente que administra sistemas informáticos. Para comparar, cuenta en tu hogar los aparatos que manejan fecha y hora: celulares, computadores, microondas, televisores, cable satelital, etc. Y relojes, por supuesto. Imagina que debes tener todo sincronizado y lo engorroso que es, pues cada uno se configura de manera distinta. Ahora multiplica el número por 10, 100 e incluso 1000 y te darás cuenta de lo problemático que es.

Chile no es el único país que realiza estos cambios antojadizos. Son muchos los países y los cambios ocurren periódicamente. Es decir, si tienes una aplicación como un Calendario y tienes usuarios de todos los países, deberías estar pendiente de actualizar esta información periódicamente (¿Aló Google?).

Afortunadamente, hay gente que ha trabajado en una solución.

Olson y la base de datos TZ

La base de datos TZ o base de datos Olson es una iniciativa iniciada por Arthur David Olson, que consiste en código fuente y archivos con todas las modificaciones arbitrarias conocidas hasta el momento; es decir: segundos intercalares, zonas horarias, horario de verano/invierno y el historial de los cambios.

Un extracto del archivo que describe a Chile es el siguiente:

Code block

# From Glenn Eychaner (2011-03-02): [geychaner@mac.com]
# It appears that the Chilean government has decided to postpone the
# change from summer time to winter time again, by three weeks to April
# 2nd:
#
# http://www.emol.com/noticias/nacional/detalle/detallenoticias.asp?idnoticia=467651
#
#
# This is not yet reflected in the offical "cambio de hora" site, but
# probably will be soon:
#
# http://www.horaoficial.cl/cambio.htm
#

# From Arthur David Olson (2011-03-02):
# The emol.com article mentions a water shortage as the cause of the
# postponement, which may mean that it's not a permanent change.
# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S
Rule    Chile   1927    1932    -       Sep      1      0:00    1:00    S
Rule    Chile   1928    1932    -       Apr      1      0:00    0       -
Rule    Chile   1942    only    -       Jun      1      4:00u   0       -
Rule    Chile   1942    only    -       Aug      1      5:00u   1:00    S
Rule    Chile   1946    only    -       Jul     15      4:00u   1:00    S
Rule    Chile   1946    only    -       Sep      1      3:00u   0:00    -
Rule    Chile   1947    only    -       Apr      1      4:00u   0       -
Rule    Chile   1968    only    -       Nov      3      4:00u   1:00    S
Rule    Chile   1969    only    -       Mar     30      3:00u   0       -
Rule    Chile   1969    only    -       Nov     23      4:00u   1:00    S
Rule    Chile   1970    only    -       Mar     29      3:00u   0       -
Rule    Chile   1971    only    -       Mar     14      3:00u   0       -
Rule    Chile   1970    1972    -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   1972    1986    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   1973    only    -       Sep     30      4:00u   1:00    S
Rule    Chile   1974    1987    -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   1987    only    -       Apr     12      3:00u   0       -
Rule    Chile   1988    1989    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   1988    only    -       Oct     Sun>=1  4:00u   1:00    S
Rule    Chile   1989    only    -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   1990    only    -       Mar     18      3:00u   0       -
Rule    Chile   1990    only    -       Sep     16      4:00u   1:00    S
Rule    Chile   1991    1996    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   1991    1997    -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   1997    only    -       Mar     30      3:00u   0       -
Rule    Chile   1998    only    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   1998    only    -       Sep     27      4:00u   1:00    S
Rule    Chile   1999    only    -       Apr      4      3:00u   0       -
Rule    Chile   1999    max     -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   2000    2007    -       Mar     Sun>=9  3:00u   0       -
# N.B.: the end of March 29 in Chile is March 30 in Universal time,
# which is used below in specifying the transition.
Rule    Chile   2008    only    -       Mar     30      3:00u   0       -
Rule    Chile   2009    only    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   2010    2011    -       Apr     Sun>=1  3:00u   0       -
Rule    Chile   2012    max     -       Mar     Sun>=9  3:00u   0       -

# IATA SSIM anomalies: (1992-02) says 1992-03-14;
# (1996-09) says 1998-03-08.  Ignore these.
# Zone  NAME            GMTOFF  RULES   FORMAT  [UNTIL]
Zone America/Santiago   -4:42:46 -      LMT     1890
                        -4:42:46 -      SMT     1910        # Santiago Mean Time
                        -5:00   -       CLT     1916 Jul  1 # Chile Time
                        -4:42:46 -      SMT     1918 Sep  1 # Santiago Mean Time
                        -4:00   -       CLT     1919 Jul  1 # Chile Time
                        -4:42:46 -      SMT     1927 Sep  1 # Santiago Mean Time
                        -5:00   Chile   CL%sT   1947 May 22 # Chile Time
                        -4:00   Chile   CL%sT
Zone Pacific/Easter     -7:17:44 -      LMT     1890
                        -7:17:28 -      EMT     1932 Sep    # Easter Mean Time
                        -7:00   Chile   EAS%sT  1982 Mar 13 21:00 # Easter I Time
                        -6:00   Chile   EAS%sT

Una de las ventajas de la base de datos Olson es que declaró las regiones o zonas de manera “sencilla” para cualquier persona. Por ejemplo, la zona correspondiente a Chile continental es “America/Santiago” y su descripción es “Most locations” y para Chile insular “Pacific/Easter” con descripción “Easter Island & Sala y Gomez“. Si has visto estas descripciones al escoger tu zona horaria, tu sistema usa la base de datos Olson.

Cabe hacer notar que todas las modificaciones a esta base de datos no es información oficial. Es solo gente común que por el bien de todos mantiene dicha información lo más veraz y actualizada posible. Basta contactarse en la lista de correos de la iniciativa, cualquiera de nosotros puede hacerlo.

Hoy muchos sistemas UNIX, bases de datos y plataformas utilizan la base de datos Olson para manejar correctamente zonas horarias, segundos intercalares y horario de verano. Sí, también las modificaciones arbitrarias a última hora.

Pero este sistema está lejos de ser perfecto, pues esta base de datos no está disponible en línea como el servicio NTP. Debe ser actualizada manualmente por cada computador, plataforma o sistema que use los archivos y muchas veces el archivo no es único sino que está varias veces en un mismo sistema.

Es por esto que una modificación al cambio de hora es un dolor de cabeza para los administradores de sistemas: Debemos actualizar: Sistema Operativo, Bases de datos (ej: MySQL), Lenguajes y Frameworks (ej: PHP y Java) y un largo etcétera.

Representaciones de fecha

Debo reiterar que es imperativo en el mundo de hoy hacer sistemas informáticos globalizados.

Lo que quiero recalcar ahora es la representación de las fechas. Lamentablemente el formato de fecha de Chile es distinto que el de EE.UU., por ejemplo. Ya saben: DD/MM/YY versus MM/DD/YY. Es algo trivial, pero genera confusión tanto a las personas como al software para expresar y leer una fecha como 02/03/04.

La solución a esto es el estándar ISO 8601, el cual define un formato del estilo YYYY-MM-DD y por supuesto incluye cosas como la zona horaria. Les ruego que lean al menos el artículo de Wikipedia, completo. Notar que el estándar también define intervalos y períodos, por ejemplo 1 vez al mes es “P1M”, algo muy útil y que mucho software sabe generar y leer (parser) actualmente.

Sé que muchos de sus clientes encuentran que la fecha “2011-03-08 19:29:34″ es horrible, incorrecta y debe mostrarse como “19:29:34 08/03/11″. Enseñen, por favor,  que en el mundo de hoy debemos pensar globalizadamente.

§

Conclusiones y los problemas no resueltos

No he terminado de levantar todos los temas, pero espero haber logrado destacar que el tema del tiempo es un problema complicado de manejar en informática.

Como norma es obligatorio utilizar algún API para trabajar con fechas y hora. Hacerlo manualmente es muy difícil y probablemente tu sistema tenga errores inesperados.

Espero hablar de los problemas actuales en un próximo artículo, pues este ya quedó demasiado extenso… Por el mismo canal y, tal vez, a la misma hora.

§

Nota 1: Es muy posible que tenga más de un error en este artículo, por favor no dude en enviarme su corrección. ¡Gracias!

Nota 2: Usualmente escribo en inglés en este blog, por hacerme el cool y enfocarme en audiencia global en vez de local. Esta es una excepción, pues me interesa que localmente se genere una discusión y ojalá se gestionen mejoras.

§

Actualizaciones 2011-03-10

• correcciones sugeridas por Alejandro Weinstein; errores menores de redacción, gramática, etc.
• correcciones sugeridas por Álvaro Herrera.

Well, among other things, most people use Microsoft Windows out there. And they find extremely difficult unix-style installations. For me, it’s natural the solution of installing libssl-dev and rebuilding ruby when “gem install” fails because an error ocurrs in net/https. But normal people don’t.

So, if you are running Windows this howto is for you.

Installing rails 3

Because Windows doesn’t have a system wide ruby installation (like Mac OS or Linux), it doesn’t make sense to use something atop like RVM. We just need to install ruby 1.9.2 and then go up.

Go to http://rubyforge.org/projects/rubyinstaller/ and download latest ruby release, I’m using ruby 1.9.2-p0.

Just follow the wizard, but in the 3rd screen select “Add Ruby to PATH”.

Ruby will be installed inside C:\Ruby192. To check everything is ok, open a console and run “ruby -v”, you should see “ruby 1.9.2p0 (2010-08-18) [i386-mingw32]“.

Code block

C:\> ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

C:\> gem install rails
C:\> rails -v
Rails 3.0.3

Creating & running a test application

Now create a new application

Code block

C:\> rails new testapp && cd testapp

And start the server. It should fail (like in unix) because sqlite3-ruby is not installed:

Code block

C:\testapp> rails s
Could not find gem 'sqlite3-ruby (&>= 0, runtime)' in any of the gem sources.
Try running `bundle install`.

Instead of running “gem install foo bar”, rails 3 comes with bundle: when you get a new project, run bundle to check dependencies and install missing gems. You can specify your own dependencies in the “Gemfile”.

Code block

C:\testapp> bundle

If you try to run the server again, you’ll get an error:

Go to http://www.sqlite.org/download.html and below “Precompiled Binaries For Windows” download both sqlite-3*.zip and sqlitedll-3*.zip the “Precompiled Binaries For Windows” (I’m using sqlite-3_7_3.zip and sqlitedll-3_7_3.zip).

Extract all files (sqlite3.exe, sqlite3.dll and sqlite3.def) to the C:\Ruby192\bin folder. Now finally the server starts.

Code block
   
C:\testapp> rails s

[2010-11-19] 06:48:58] INFO  WEBrick::HTTPSERVER#start: pid=1836 port=3000

Check http://localhost:3000/.

Installing git

Download msysgit. I’m using Git-1.7.3.1-preview20101002.exe.

On the 4th screen, check everything:

On the 6th screen, select “Run Git from the Windows Command Prompt”:

On the 7th screen, select “Checkout as-is, commit Unix-style line endings”:

Once msysgit is installed, open a new cmd console and configure your name and email

Code block

C:\testapp> git config --global user.name "Juan Perez"
C:\testapp> git config --global user.email "juan.perez@example.com"

You can get help about any git command by typing the command and –help:

Code block

C:\testapp> git config --help

Git will be really important later, don’t skip this step. Do your first commit:

Code block

C:\testapp> git init
C:\testapp> git add .
C:\testapp> git commit -m "project started"

Create a new CRUD model, controller, view

Rails is based on MVC and “scaffolding” is what they call to create a simple controller, model and view for a very basic and useful CRUD template.

Code block

C:\testapp> rails g scaffold product title:string desc:string price:integer
C:\testapp> rake db:migrate

Now go to http://localhost:3000/products/ and try it. Don’t forget to commit:

Code block

C:\testapp> git add .
C:\testapp> git commit -m "created product mantainer"

Upload your app to heroku

This is really, really cool, you can upload and update your app for free in heroku using nothing but the command line!

First, upload your ssh keys to your home folder (something like C:\Users\Aldrin\.ssh\). If you don’t have a key, press the right button on the testapp folder and select “GIT Bash Here”.

Create your key with the following command:

Code block

C:\testapp> ssh-keygen.exe -t dsa -C "juan.perez@example.com"

Now, register in http://api.heroku.com/signup … After creating your account and uploading your ssh keys, install heroku and create a new app:

Code block

C:\testapp> gem install heroku
C:\testapp> heroku create
Uploading ssh public key C:\Users\test/.ssh/id_dsa.pub
Creating electric-sunset-57.... done
Created http://electric-sunset-57.heroku.com/ | git@heroku.com:electric-sunset-57.git
Git remote heroku added
C:\testapp> git push heroku master

The last line is all the magic: whenever you push to the heroku repository, your app is redeployed… deployment has never been so easy!

Go to your application url (like in http://electric-sunset-57.heroku.com/products/). It should fail because we need to setup a database in heroku servers… You can upload your current development sqlite3 database with:

Code block

C:\testapp> gem install taps
C:\testapp> heroku db:push

If still fails, you can check heroku logs:

Code block

C:\testapp> heroku logs

I’ve found out that heroku didn’t find sqlite3 (which is not be available in their production environment), so I’ve changed the Gemfile to this:

Code block

group :development, :test do
  gem 'sqlite3-ruby', :require => 'sqlite3'
end

Commit your changes and push them to heroku.

Code block

C:\testapp> git add .
C:\testapp> git commit -m 'bugfix: sqlite3 only in dev,test'
C:\testapp> git push heroku master

Now check http://deep-planet-58.heroku.com/products/. For removing the app in heroku:

Code block

C:\testapp> heroku destroy --app deep-planet-58

Bonus: TextMate like editor

Many tutorials you’ll see use TextMate for programming in rails, which is only available in Mac OS X. Try the following alternatives:

First, download java for windows. Now, install redcar (this will take a while…):

Code block

C:\testapp> gem install redcar
C:\testapp> redcar install
C:\testapp> redcar .

You may run redcar directly from C:\Ruby192\bin\redcar.bat .

That’s all for now.

I have also created a Projects page in this blog, so any other app or anything will appear in one central page.

Hope you find useful,

– Aldrin

Last week I started a REAL project using Ruby on Rails 3. The first two hours was quite exciting, but after a while I realized that all examples/docs/podcasts/guides were made with the 2.x versions in mind. Everything requires several adjustments for the new 3.0 rails version.

So, I’m beginning to document step-by-step instructions on how to start programming in the shiny new rails 3.

Prerequisites

Update: You’ll need to install the following:

Ubuntu 10.10 -

Code block

$ sudo apt-get install curl zlib1g-dev libsqlite3-dev libssl-dev

Installing Rails 3

Thanks to  RVM, this is quite easy: RVM will download, compile and install everything inside a sandbox directory ($HOME/.rvm/), no need to touch your system libraries or becoming root. You can install many versions of ruby, or go back to your system wide installation. Easy and reliable.

First, run the RVM install script and then include RVM in your .bashrc or .profile:

Code block

$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"' >> $HOME/.bashrc

Quit/restart your bash or terminal session. Now install ruby 1.9.2

Code block

$ rvm install 1.9.2
$ rvm --default 1.9.2

Note: If you are in Mac OS X, ruby is not compiled with iconv support (crucial for i18n!)… run this to install iconv inside the sandbox and reinstall ruby:

Code block

$ rvm package install iconv
$ rvm remove 1.9.2
$ rvm install 1.9.2 -C --with-iconv-dir=$HOME/.rvm/usr
$ rvm --default 1.9.2

You can switch between your system wide ruby or the new one inside the sandbox, just run both and keep with the 1.9.2 version:

Code block

$ rvm --default system && ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]
$ rvm --default 1.9.2 && ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]

Install rails 3 with gem (it may take a while) and check:

Code block

$ gem install rails
$ rails -v
Rails 3.0.0

Creating & running a test application

My recommendation is to setup a new directory for all your rails projects:

Code block

$ mkdir -p $HOME/proj/rails/
$ cd $HOME/proj/rails

Now create a new rails app called “testapp”:

Code block

$ rails new testapp && cd testapp

And start the server… it should fail because sqlite3-ruby is not installed:

Code block

$ rails s
Could not find gem 'sqlite3-ruby (&>= 0, runtime)' in any of the gem sources.
Try running `bundle install`.

Instead of running “gem install foo bar”, rails 3 comes with bundle: when you get a new project, run bundle to check dependencies and install missing gems. You can specify your own dependencies in the “Gemfile”.

Code block

$ bundle

And now we can start the server!

Code block

$ rails s
[2010-10-03 02:35:11] INFO  WEBrick::HTTPServer#start: pid=50672 port=3000

Check http://localhost:3000/.

Setup git

If you don’t know git, you should learn the basics right now

Git will be really important later, don’t skip this step. For starters, run inside your rail project:

Code block

$ git init
$ git add .
$ git commit -m "first import!"

Create a new CRUD model, controller, view

Rails is based on MVC and “scaffolding” is what they call to create a simple controller, model and view for a very basic and useful CRUD template.

Code block

$ rails g scaffold product title:string desc:string price:integer
$ rake db:migrate

Now go to http://localhost:3000/products/ and try it. Don’t forget to commit:

Code block

$ git add .
$ git commit -m "created product mantainer"

Upload your app to heroku

This is really, really cool, you can upload and update your app for free in heroku using nothing but the command line!

First, register in http://api.heroku.com/signup … After creating your account, install heroku and create a new app:

Code block

$ gem install heroku
$ heroku create
Uploading ssh public key $HOME/.ssh/id_dsa.pub
Creating deep-planet-58.... done
Created http://deep-planet-58.heroku.com/ | git@heroku.com:deep-planet-58.git
Git remote heroku added
$ git push heroku master

The last line is all the magic: whenever you push to the heroku repository, your app is redeployed… deployment has never been so easy!

Go to your application url (like in http://deep-planet-58.heroku.com/products/). It should fail because we need to setup a database in heroku servers… You can upload your current development sqlite3 database with:

Code block

$ gem install taps
$ heroku db:push

Now check http://deep-planet-58.heroku.com/products/. For removing the app in heroku:

Code block

$ heroku destroy --app deep-planet-58

Important things to remember

• Don’t run any command as root because everything is installed inside $HOME/.rvm/
• I repeat: never run sudo!
• Declare dependencies in the Gemfile and run “bundle” to install required gems. Heroku will do the same, so get used to it
• Setup git from the start and use it constantly
• You can deploy your app in heroku, don’t forget to push your database

That’s all for now.

In the mean time, I realized that finding the perfect web application technology could easily become a huge, really really huge project (Leo say something like ‘I was trying to fix the world’… that sounds huge!). And my fears of not finishing it all by myself in my spare/free/study/procastination time just appeared. So, I’m taking two strategies for this:

1. So many girls, so little time! I’ll start with something small, then grow as necessary: I mean, I will start with only one of the major functionalities I have in my mind for the test application, later I will cover the rest or improve the existing ones.
2. Ask for help: Please, you are already invited into this quest: talk to me, send me patches, re-create this application in the technology of your choice, fixs my bugs or find better ways of doing things, etc. Thanks!

So, functional requirements: here we go!

Functional requirements (version 2010-01-02)

The test application is a rich internet application for clients of a fictional bank. The clients of the bank can do the following tasks: see a balance report of their saving/deposit/whatever accounts, transfer money to other accounts, and chat directly with an executive, if they are available.

The six major functional requirements of the test applications are:

1. Layout of the web page that makes easy to compare a technology with others.
2. A very secure login and logout, user-password based.
3. Balance reports of different type of accounts, including excel and chart exporting.
4. Money transfer to other accounts of the same bank.
5. An embedded calculator, with bank-related functionality included.
6. A live chat with your executive, if she/he is available.

Remember the ‘so many girls, so little time’ phrase: I’m trying to meet as much sexy (and ugly!) girls/technology first rather than know them very well. So, in this version we are covering only the first two requirements. It will be long, however, take your notes!

Requirement 1: Layout of the webpage

This is easy, the layout of the page has to be something similar to this:

Let me explain each section of the layout:

1.1 Top-left section:

• first line is “the perfect web application technology” linking to this page
• second line is the number of the test (ex: “technology 05″) and the name of technologies used (ex: “gwt, java servlets”)
• third line is an about page, linking to a page with notes about this version of the application (who made it, where is the code, licensing, etc)

1.2 Top-right section:

• first line is the name of the connected user, only if she/he is already connected to the application
• second line is the roles available to the user, ONLY if the user has more roles other than “bank client”
• third line is a logout link

1.3 Evaluation accordion: The right column is a summary of evaluation points. The interface is an accordion widget, and the titles should indicate the number of issues found for a given requirement. For example: “Logon (4/10)” means that logon functionality has a total of 10 requirements, and 4 of them has issues in the current implementation”.

If the user clicks on a requirement, a new floating window should appear (inside the browser! example) with the page fragment of the evaluation page. Note that “the evaluation page” will be a post on this blog.

This will allows us to see the evaluation of a technology without leaving the same application. Bonus if the application reads the evaluation post and updates the accordion automatically (ie: no database or code to keep the count of issues!).

1.4 Link bar: just above the content pane, there should be a link bar with all the functionality for this application. Of course, if the user is not logged in, it must be forced to logon.

1.5 Content pane: It can’t based on frames, that sucks for many reasons. It should have vertical scrollbar and an horizontal scrollbar only if needed.

1.6 Expected web page behavior:

• The back, forward and reload browser buttons should work with your application. Not sure how to explain this, so I’ll do it later…
• Copy and paste should work, and also mouse scrolling (both horizontal and vertical)

Requirement 2: Login

2.1 User accounts: Because this is a bank, there is no account creation via web. We’ll may cover an administration interface later. All user accounts consist of an user and (strong) password.

2.2 Login interface: it should be something like this:

Note that the top-right section is empty.

2.3 Login failure: if the user fails, a message should appear below indicating the number of attempts left before the account will be locked (1). The failed attempts are by hour, and reseted if the login is successful. If the user has failed within the hour, a link to recover your password must appear (2).



2.4 Lost password: if the user click the ‘lost your password?’ link, a dialog should appear asking for the username or email of the account.

When the user press the ‘Sent me instructions’ button, an email will arrive with a link to reactivate the account (if it was locked) and to create a new password. The confirmation message should look like this:

The user has 1 hour to recover its password, after that the link sent is expired and must not work again. Besides that, the user cannot send new instructions until the recover links expires. Instead, it gets a message like this:

2.5 Account locking: if there are too many login attempts in the period of an hour, the account must be locked and the user must not be able to login after a pause of X minutes.

A clock should appear, with the minutes:seconds left until the user is able to try login again, once the counter reach zero, the account dialog must disappear and reveal the login. Account locking is an standard in the bank, so it must be implemented with functionality supported by remote services.

2.6 Services: The following remote services are available to build all the above functionality. These services can be made available in the protocol of your choice (from EJB/RMI to JSON). I will post the API + examples later, once I implement them.

• login_status remote_login_status(string username);
• user_info remote_login(string username, string password) throws login_error;
• remote_update_password(string username, string password) throws update_error;

Note there are things that must be implemented in the webserver (ie: not available as services), an example is the link to create a password.

Summary

To summarize, here is the list of all requirements (including those stated in the previous post). Bonus: If the evaluation accordion extracts the names from here.

List of requirements

1. Layout
1.1 Top left
1.2 Top right
1.3 Evaluation accordion
1.4 Link bar
1.5 Content Pane
1.6 Common behavior

2 Login
2.1 User accounts
2.2 Login interface
2.3 Login failure
2.4 Lost password
2.5 Account locking
2.6 Services

What’s next

All following post will talk about the experience of writing the test application implemented under a technology. I’m keeping a summary of versions and a changelog in the perfect web application technology page, check that regularly for changes and improvements.

But I couldn’t find any useful software in my ubuntu setup, neither on google. It seems the most useful and popular app is balsamiq, an AIR application that you can try on the web and run on your desktop. It seems really useful, but it costs US $80. I may buy it later, but I was looking for a free and open solution.

Then I looked some web utilities for doing mockups of web pages, but none of them seem up to the task… And then, it hit me: we are not building web pages anymore, we are building full desktop applications on the web; why I can’t use the same tools we use for desktop development? So, I tried Glade. Now, let me show you…

A web browser mockup

First, I needed a web browser mockup. That’s included in a tool like balsamiq, but I have to made one from start. In around 5-10 minutes, it was done!

A browser mockup made with glade, click to view

This was exciting! Now, let’s add some content… a typical web layout: header, side column and main content with scrolling. First, the layout and header:

Creating the web header, it took around 5-8 minutes including the site logo made in gimp

Well, it took more than I wanted, mostly because I had to recreate many elements like a breadcrum (in balsamiq, just search that element in the ‘Quick add’ text entry).

But there are advantages. The layout of elements is automatic, I don’t need to set positions or sizes of any element, neither link them together. For example, imagine I forgot to put the name of the logged user and a logout link.

Just add an ‘Horizontal Box’ as parent of the ‘web site title’ label:

Repacking a widget: add a parent horizontal box

The label will disappear, and glade will ask how many placeholders the horizontal box should have. Let’s add 3:

Repacking a widget: select the number of placeholders

Now, we have our original widget and got two new placeholders to put new content:

Repacking a widget: two placeholders ready!

After adding two widgets, we are done:

Repacking a widget: the final result

Summary

Well, glade is not really a mockup tool, so many things are hard and not easy: to change the title of  a label, you have to select the widget, search the text property and then change the text (three clicks and two scrolls movements!). It would be easier if you could change it directly from the preview, why it’s so hard? Also, the packing options (like expand) are hidden behind two more clicks.

Other things are actually hard and very difficult to do. I mean, anything that requires a ‘model’: tables, lists and even text entries required them. It’s just impossible to do it fast, which is sad because this kind of thing is also required in normal desktop applications.

However, I love the idea of automatic packing of widgets. This is far better than packing elements by myself.

My conclusion: if glade improves this problems, it would became a fantastic tool for making any kind of mockups (and also, it would be easier to modify our desktop apps interface). In the meantime, I’m not sure if I’ll continue with this app or will try something different…

As I said, I think most developers never consider all the gotchas of doing an application using web technologies. The following requirements may look like a little too much for “just a web application”, but I think this is the real minimum of any web application, no matter the ‘size’.

• Data processing and storage
  • Everything is UTF-8: all textual data (including source code) must be stored, processed and displayed in UTF-8 encoding. The reason is that Unicode is the only sane way of handling data in non-english languages. And from all Unicode standards, UTF-8 is the clear winner in terms of usage and acceptance. This simple innocent requirement immediately discards common used software, like Windows XP and PHP. Isn’t this amusing?
  • Validation: it should be natural or at least easy to assign validation rules of data to programming logic. Examples are: not null fields, only numbers/dates or creating a new validation rule like the Chilean “dígito verificador del rut“. It doesn’t need to be a framework: if the language provides a natural solution (ex: a closure/decorator in python) it’s sufficient. It should do data validation in both client and server sides, kudos if the rules are written only once.
• Development
  • A joy to develop: editing HTML files is so 90′s… Besides, we are not building pages anymore, but full desktop like applications. So, a modern web technology should encapsulate all the details and talks in terms of reusable components. Examples of this are Google Web Toolkit, some IDE’s with JSF support and some RIA frameworks.
  • Fast during development: I’m kind of tired the waiting in many JavaEE IDE’s like eclipse. Everything should be easy to test/run/change during development.
  • Debugging: it should be a joy to debug, and I mean, real debugging: pause the application, look around traces and variables, setting breakpoints… you know what I’m talking, right?
  • Multi-tier architecture: the web application should be a thin presentation layer for services that do the real work. Technically, the business logic is running on remotes servers via a remote procedure call protocol of your choice (RMI, CORBA, Hessian, JSON, XML-RPC, Web Services, whatever).
  • Data exporters: the technology must facilitate the export of data to other formats besides HTML within the same application. Examples are: PDF, Office Documents, Chart reports, and other common formats.
• User experience
  • Fast and reliable: the application should load in no time, it must not crash. The user must never see a 500 error page, neither get a trace of what went wrong… no excuses!
  • Browser independent: it should work and look almost the same  in different browser and operating systems. To put names: Internet Explorer, Firefox, Chrome and Safari; Windows, MacOS and Linux.
  • Desktop class: the application shouldn’t look like a page: it should look and behave like a real desktop application does. Bonus if the application can manipulate data offline!
• Security and integrity
  • Authentication and authorization: the technology must provide a sane and safe way of authentication.The authorization of certain functionality should be available too, and it should be role-based.
  • Auditing: it should be easy to generate audit logs, ideally through a declarative approach. The log should have: the action, logged user, and the data associated.
  • Transactional: the web application should not be transaction aware, neither transfer transactional state to the business layer. Every service invoked in the business remote servers is required to be transactional: if the remote operation succeed, transactions are committed; if the remote operation fails, transactions are rolled back. Moreover, this means there will be no long running transactions by one or more web page requests.
  • OWASP: the used technology should include countermeasures or help to minimize all common security flaws reported by 2007 OWASP top ten vulnerabilities report, which are:
    • CSS (or XSS) attacks.
    • Injection attacks, like SQL injection.
    • Malicious file execution attacks.
    • Insecure direct object reference.
    • CSRF (or XSRF) attacks.
    • Information leakage and improper error handling.
    • Strong authentication and session managment.
    • Insecure communications.
    • Failure to restrict url access.
  • Error handling: any error should be informed to the user, without revealing anything about the internal work of the application. Bonus: a ticket should be assigned, so the user problem may be associated to related traces and logs.
  • Logging: must not include secure or very private data, like passwords.
• Performance and operational
  • Scalable: the web layer should be prepared to scale. Given that all business logic is on remote servers, this should not be a real problem. However, there is data that only belongs to the web layer and is common that this data does not allow to scale, an example of this is session data.
  • Vertical/Horizontal: It should be relatively easy to scale vertically (adding CPU cores to the server) as horizontally (adding more servers).
  • Logging: given the multi-tier architecture, logging will be necessary, both in development and production. Ideally, all messages should be redirected to a central location like syslog.

Summary

Well, I have put some basic requirements that any application must/should follow. Your technology of choice may excel at some points, but it’s probably that some points are really bad and some of them it’s not even considered.

Next post, I will define the test application I’m going to create in each language and its requirements. Keep tuned!

I will post subsequent entries for each major technology that can be used to build a web application, including source code. You are invited to participate: tell me what technology I’m missing, send me patches or fixes, or… whatever you may like to do.

Motivation

For most of my programming life, I’ve never considered myself a web developer. You may got answered the “perfect web application technology” question many years ago, but that’s not my case. Well, actually I have done real web programming many times, among many many other things. By real web programming, I mean applications that were or are in use and I get paid for, not just something for myself or some toy experiment.

The problem that keep’s me avoiding web development is that current web is a big, big success… but the underlying technology is a big, big mess. Current “Web 2.0″ (and “normal web” too) have been used for something it was never designed, neither predicted.

It all started as a simple way to share information, mostly text and sporadicly an image over there. That’s where the term “web page” comes from: it was an electronic analogy of paper based documentation. There was a server and a client. The client requested a web page, and the browser served a file. You were able to interconnect one web page to another by putting links. HTTP and HTML were born under the “hypertext” name: just tag your text and your documents will be displayed as an “interactive” web page. And it scaled very well, because there was no central database or system; just a missing (404) link if something went wrong.

Then, the madness began. Browsers wars and incompatibilities (imagine your gnome program doesn’t work as expected or does not look the same in different Linux distributions), mixing presentation with code (argh! I hated every template I’ve seen), data conversion mega-problems (like &amp; when it should be &, and not to mention all the problems at all levels when your language is not english). Today, we have a mix of disparate usage and technologies, all of them running over the same “hypertext web page” system: wiki’s, blogs, search engines, JavaScript, tag clouds, DOM, XML, JSON, RSS, Web Services, REST…. including desktop class applications, like gmail.

So, all of this is running on requesting/response of a page. Does it make sense? Nope. Does it work? Sort of, and painfully. In my opinion, the web is far away of the “it just works” phrase.

And that’s the reason why it is so difficult to build a web application: it is not natural. And because it’s so difficult to do it, it’s harder to find projects that did it well. I think nearly all current web applications have at least one or more problems because it’s so difficult to do, that all developers just get to the point when “it works for me”, not considering all the implications of simulating a real desktop class application with a request/response webpage model.

So, that’s the story: it’s difficult because it wasn’t mean to be, it’s wrong because it so difficult that is nearly impossible to cover all the caveats.

And so, I never liked it. But now, I really want to solve this problem, at least for me. Partly, to make the web a little better. Partly, because I think developers are not aware of any of this. And well, it’s fun to compare and learn technology.

I will look for technologies that have managed or solver almost all of the common problems derived from this wrong model of making applications. Watch out, because my requirements will probably make your current web technology look like crap.

Just look at the /proc/<pid>/fdinfo/ files… Here is an example:
# cat /proc/1/fdinfo/1
pos: 0
flags: 02
That special file does exactly what I was doing: getting the struct task_struct for a PID, then getting its struct files_struct, and then the pos of the struct file. The code is in the linux kernel, in the function proc_fd_info inside fs/proc/base.c.

And here is a python script that helps a lot:
#!/usr/bin/env python
# Copyright(C) 2009 Aldrin Martoq
# Licensed under GPL v2 http://www.gnu.org/licenses/gpl-2.0.html
# version 20090206-01

for pid in sys.argv[1:]:
for fd in os.listdir(p1 % pid):
try:
d = dict(tuple(map(str.strip, l.split(':'))) \
for l in open(p2 % (pid, fd)))
d['path'] = os.readlink(p3 % (pid,fd))
# skip irrelevant fd's...
for p in skip:
if d['path'].startswith(p): break
else:
d['fd'] = fd
d['pid'] = pid
d['cmdline'] = open(p4 % pid).readline().strip()
try: d['size'] = str(os.stat(d['path'])[6])
except: d['size'] = '-'
try: d['%'] = '%5.1f' % (100.0 * int(d['pos']) / int(d['size']))
except: d['%'] = '-'
for i in range(len(fmts)):
print fmts[i] % d[cols[i]].replace('\0', ' '),
print
except Exception, e: print 'FIXME: ' + e

Sample usage:

amartoq@videopodcast:~$ sudo ./fdpos.py $(pgrep ^postgres)
pid cmdline fd pos size % path
13876 /usr/lib/postgr 1 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13876 /usr/lib/postgr 2 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13891 postgres: write 1 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13891 postgres: write 2 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13892 postgres: wal w 1 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13892 postgres: wal w 2 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13893 postgres: autov 1 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13893 postgres: autov 2 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13894 postgres: stats 1 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
13894 postgres: stats 2 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
15921 postgres: amart 1 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
15921 postgres: amart 2 51519 51519 100.0 /var/log/postgresql/postgresql-8.3-main.log
15921 postgres: amart 3 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2684
15921 postgres: amart 6 57344 57344 100.0 /var/lib/postgresql/8.3/main/base/16473/2663
15921 postgres: amart 7 303104 311296 97.4 /var/lib/postgresql/8.3/main/base/16473/1249
15921 postgres: amart 10 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2693
15921 postgres: amart 11 8192 65536 12.5 /var/lib/postgresql/8.3/main/base/16473/2618
15921 postgres: amart 12 65536 90112 72.7 /var/lib/postgresql/8.3/main/base/16473/2689
15921 postgres: amart 13 16384 106496 15.4 /var/lib/postgresql/8.3/main/base/16473/2617
15921 postgres: amart 14 16384 32768 50.0 /var/lib/postgresql/8.3/main/base/16473/2688
15921 postgres: amart 15 49152 57344 85.7 /var/lib/postgresql/8.3/main/base/16473/2690
15921 postgres: amart 16 65536 409600 16.0 /var/lib/postgresql/8.3/main/base/16473/1255
15921 postgres: amart 17 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2703
15921 postgres: amart 18 16384 57344 28.6 /var/lib/postgresql/8.3/main/base/16473/1247
15921 postgres: amart 19 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2661
15921 postgres: amart 20 8192 16384 50.0 /var/lib/postgresql/8.3/main/base/16473/2605
15921 postgres: amart 21 147456 327680 45.0 /var/lib/postgresql/8.3/main/base/16473/2691
15921 postgres: amart 22 16384 32768 50.0 /var/lib/postgresql/8.3/main/base/16473/2686
15921 postgres: amart 23 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2616
15921 postgres: amart 24 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2654
15921 postgres: amart 25 49152 49152 100.0 /var/lib/postgresql/8.3/main/base/16473/1259
15921 postgres: amart 26 8192 8192 100.0 /var/lib/postgresql/8.3/main/base/16473/2601
15921 postgres: amart 27 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2678
15921 postgres: amart 28 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2662
15921 postgres: amart 29 8192 8192 100.0 /var/lib/postgresql/8.3/main/global/1260
15921 postgres: amart 30 16384 16384 100.0 /var/lib/postgresql/8.3/main/global/2676
15921 postgres: amart 31 16384 16384 100.0 /var/lib/postgresql/8.3/main/global/2677
15921 postgres: amart 32 8192 8192 100.0 /var/lib/postgresql/8.3/main/base/16473/2615
15921 postgres: amart 33 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2685
15921 postgres: amart 34 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2696
15921 postgres: amart 35 8192 90112 9.1 /var/lib/postgresql/8.3/main/base/16473/2619
15921 postgres: amart 36 49152 57344 85.7 /var/lib/postgresql/8.3/main/base/16473/2704
15921 postgres: amart 37 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2650
15921 postgres: amart 38 8192 8192 100.0 /var/lib/postgresql/8.3/main/base/16473/2600
15921 postgres: amart 39 73728 73728 100.0 /var/lib/postgresql/8.3/main/base/16473/2659
15921 postgres: amart 40 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/2656
15921 postgres: amart 41 8192 8192 100.0 /var/lib/postgresql/8.3/main/base/16473/2604
15921 postgres: amart 42 8192 8192 100.0 /var/lib/postgresql/8.3/main/base/16473/16666
15921 postgres: amart 43 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/16675
15921 postgres: amart 44 16384 16384 100.0 /var/lib/postgresql/8.3/main/base/16473/16677


Updated 2009-02-06: Thanks to Daniel Serpell for fixing my bugs.