Software artesanal, desde 1997

Ya casi estamos. Al final he pasado más tiempo haciendo testing de la aplicación y arreglando bugs que programando. Buena señal. Aquí un pantallazo de la fase de testing con el simulador de iOS, para ver que la home page era visible y usable desde dispositivos móviles:

La mayoría de los problemas han sido causados porque soy un novato en Ruby on Rails y he tenido que estudiarme a fondo el tema del routing en Rails 3 con subdominios. O lo que es lo mismo, que las peticiones a barcelona.bisicalc.com, valencia.bisicalc.com, etc… sean procesadas por la misma aplicación.

Y ahora, hacer check in en GIT y a subir la aplicación al servidor, es decir… a romperlo todo, porque estas cosas nunca funcionan bien a la primera.

Debería haber subido ya la versión que os he estado enseñando a bisicalc.com… pero algo se ha interpuesto en mi camino: El bug del infierno de último minuto™.

Para resumir dos horas en dos minutos: El API de Citybik.es me devuelve la fecha y hora de actualización de cada estación en formato:

2011-12-17 00:16:51.335480

Pero Javascript en Firefox/Safari no tragaba, y en lugar de formatear la última fecha de actualización, me decía: NaN/NaN/Nan a las NaN:NaN (NaN = Not a Number). Por algún oscuro motivo en Chrome si que funciona.

La especificación de Javascript dice que el formato que viene de citybik.es no es ninguno de los dos aceptados. Lo que más se aproxima a lo que me pasan es un subconjunto de la norma ISO 8601:

2011-12-17T00:16:51.335480+01:00

Expresiones regulares al rescate:

var last_update_date = new Date(last_update[0].timestamp.replace(/(\S*) (\S*)/,"$1T$2+01:00"));

Queda por hacer:

• Adaptar Bisicalc Valencia al nuevo formato, ahora no funciona
• Añadir una página de bienvenida
• Subir a servidores

Estoy en ello, ahora viene la parte peliaguda… actualizar servidores. De momento os dejo con una foto de Sevici:

Al final aquello de divide y vencerás ha funcionado. Sólo cambiando el javascript con las coordenadas de Zaragoza… ¡tachán!

El javascript:

// THE GRID
var theGrid = new Object();
theGrid.latN = 41.69445;
theGrid.latS = 41.623399;
theGrid.lonW = -0.944138;
theGrid.lonE = -0.834618;
theGrid.SW = new google.maps.LatLng(theGrid.latS,theGrid.lonW);
theGrid.NE = new google.maps.LatLng(theGrid.latN,theGrid.lonE);

theGrid.bounds = new google.maps.LatLngBounds(theGrid.SW, theGrid.NE);
theGrid.cellSize = 250; // meters
theGrid.distance = 1; // number of cells square we use to calculate occupations
// END THE GRID

var city = new google.maps.LatLng("41.655553","-0.887806");

var APIurl = "http://api.citybik.es/bizi.json?callback=?";

Me comentan que en el bicing de Barcelona tienen lo que se conoce como “el efecto Baixing”: todas las bicis acaban concentrándose cerca de la playa, en las zonas más bajas de la ciudad. Debe ser porque a la gente no le gusta pedalear hacia arriba.

No conozco mucho la geografía de Barcelona, pero se puede ver que efectivamente si que acaban cerca de la playa…

El API de Citybik.es en JSON usa UTF-8 para codificar los caracteres. En el primer intento de hacer los mapas térmicos de bicing, las etiquetas de las estaciones con nombres con acentos o cedillas salían con “un garabato”.

El parsing del JSON lo hago con jQuery y al inspeccionar las variables podía ver que el garabato venía directamente del API:

… ¿o no?, ¿qué me devuelve el API antes de llamar a $.getJSON ?

Es decir, jQuery se está haciendo la picha un lío con el encoding de los caracteres. El API me devuelve UTF-8, que es perfectamente válido para JSON, pero me da a mi que jQuery espera Unicode.

Por cierto, el Mínimo Minimorum Que Todo Desarrollador De Software Positiva Y Absolutamente Debe Saber Acerca De Unicode Y Conjuntos De Caracteres. (¡Sin Excusas!).

La solución tras una hora de búsqueda es, como casi siempre, una sola línea de código, antes de llamar a getJSON:

 $.ajaxSetup({ scriptCharset: "utf-8" , contentType: "application/json; charset=utf-8"});

Sigo con mi misión Rodriguez del sábado: Adaptar Bisicalc a todas las ciudades españolas que exponen los datos de su red de bicicletas de alquiler.

Después de reducir el ámbito del problema, hacerlo todo en local y sin base de datos, y separar los datos de las funciones de dibujo, para que luego el trabajo sea más fácil al portar otras ciudades, ya tengo el primer pantallazo:

Los principales problemas han sido:

• Diferencias entre el modelo de datos de Bisicalc, basado en “updates” y el de Citybikes, basado en “estaciones”
• Siempre se me olvida que los callbacks de Javascript son asíncronos y no necesariamente se sigue un orden de ejecución lineal (fuera del callback)

Una vez mirado el API de CityBikes veo que hay bastantes diferencias con el que uso yo, es decir, que voy a tener que adaptar la parte de proceso del modelo de datos.

En lugar de liarme con Ruby on Rails y todo a la vez, sigo la ‘estrategia del comedor de turrón duro (TM)’ y voy a partir el problema en trozos pequeñitos:

• Primero Barcelona bicing
• Páginas estáticas sin servidor (así elimino el Ruby on Rails y la base de datos de momento)
• Separar la parte de configuración de latitudes y longitudes a un fichero Javascript separado

Hace unos días vi las APIs de CityBikes, que dan acceso a las estadísticas de uso en vivo, no sólo de Valenbisi, sino de muchos otros sistemas.

Hoy me he levantado “faener” y, con eso de que soy mi propio jefe, y estoy de Rodriguez, voy a intentar añadir servicios de mapas de ocupación por colores para todas las ciudades de España que tienen los datos abiertos antes de que acabe el día.

Por aquí y por Twitter voy a ir retransmitiendo la jugada y como va progresando la cosa. De momento ya he preparado el entorno de programación: café y dulces de boniato a mano.