Blog de Víctor Corbacho

Hola, si soléis visitar mi blog supongo que ayer pudisteis comprobar cómo desde media mañana hasta por la noche estuvo offline. Desde hace algo más de un mes, este blog corre sobre una microinstancia de Amazón EC2, basada en un ami Amazon Linux (una especia de híbrido de CentOS). La cuestión es que a raíz de una actualización de paquetes, ente los que había una actualización del núcleo, perdí todo acceso posible a mi instancia desde ssh, web, ftp, etc.

Tras varios reinicios  conseguí acceder al log que se puede ver desde la consola de gestión de Amazon, y vi que había un fallo que decía lo siguiente: Page fault in pagetable walk (access to invalid memory?).

Tras buscar por varios sitios, encontré el problema y la solución. Por lo visto sólo afecta a las versiones de 32 bits de las microinstancias (¡qué suerte!), y ocurre dentro de PV-Grub, en la gestión que éste hace de la paginación de memoria en Xen. El bug está corregido en la versión 1.02 de PV-Grub, pero las imágenes de Amazon Linux AMI 2011.02.1 utilizan la versión 1.01. La solución consiste en actualizar el aki de PV-Grub que se utiliza en la instancia, o lanzar una instancia basada en Amazon Linux AMI 2011.02.01 con la última versión del AKI de PV-Grub.

Para poder continuar tenemos que tener instaladas las EC2 command line tools. En la página de Amazon está el enlace de descarga y hay información sobre cómo instalarlas.

Para poder actualizar el AKI de la instancia, primero tenemos que conocer la última versión disponible en nuestra región. Para ello tenemos que utilizar el siguiente comando:

ec2-describe-images -o amazon --filter "manifest-location=*pv-grub-hd0_1.02-i386*" --region REGION

En mi caso tengo la instancia en Virgina, por lo que en región tuve que poner us-east-1. El resultado de este comando me proporcionó la información necesaria para saber la versión que tenía que utilizar para la actualización: us-east-1    aki-805ea7e9    ec2-public-images/pv-grub-hd0_1.02-i386.gz.manifest.xml

Una vez conocida la versión (aki-805ea7e9), debemos detener nuestra instancia:

ec2-stop-instances --region us-east-1 i-#####

A continuación actualizamos el AKI:

ec2-modify-instance-attribute --kernel aki-805ea7e9 --region us-east-1 i-#####

Y finalmente volvemos a iniciar nuestra instancia:

ec2-start-instance --region us-east-1 i-#####

Y con esto nuestra instancia volverá a arrancar normalmente, recuperando la conectividad a través de la IP elástica o de la DNS pública.

Un saludo.

Hoy voy a explicar el funcionamiento básico de la aplicación ZGZagua. La aplicación cuenta con tres secciones a las que se accede mediante el menú superior:

• Home: es la página principal. En ella se muestran todos los cortes activos (del día actual y días posteriores, son todos los publicados actualmente por el Ayuntamiento).
• Estadísticas: proporciona acceso a todos los cortes de agua que han tenido lugar en los últimos 30 días o en los últimos 7 días.
• Cortes previstos: muestra un listado con los cortes previstos para el día actual.

Home (entrada a la aplicación)

Home corresponde a la pantalla principal de la aplicación. En el mapa se puede ver la situación de todos los cortes previstos para hoy y los próximos días, y pinchando sobre los marcadores se puede ver la información de los mismos (duración, situación, etc.).

Estadísticas

Esta sección consta de dos subapartados: incidencias del último mes e incidencias de la última semana. Desde aquí se pueden ver de forma visual todos los cortes de agua que han tenido lugar en Zaragoza en la última semana y en el último mes respectivamente. Además, pinchando sobre cada icono, se puede acceder a la información detallada de la incidencia (localización, duración, etc.). Gracias a esta información, se puede ver de un simple vistazo las zonas más propensas a sufrir cortes programados (aquellas donde hay mayor cantidad de iconos).

Cortes previstos

La sección de cortes previstos presenta la información visual detallada de todos los cortes de agua vigentes para el día actual. En ella se pueden ver estos cortes sobre un mapa y en una lista, en la que se detalla gráficamente su situación (mediante un pequeño mapa) y la descripción de la incidencia (localización, horario, etc.). Para facilitar la localización de los cortes, si se pincha sobre el mapa que cada uno tiene en la lista, se abre la ventana emergente en el mapa en el punto exacto donde se localiza.

Como se puede ver, en todo momento la aplicación está enfocada a presentar de forma rápida, sencilla e inequívoca, toda la información referente a las incidencias de cortes de agua al usuario, para que este la pueda consultar en cualquier momento de una manera fácil. En la próxima entrada explicaré el funcionamiento del registro de usuarios y gestión de incidencias para notificaciones.

Un saludo.

Este año he decidido participar en el desafío AbreDatos 2011. AbreDatos es un concurso de programación que consiste en desarrollar una aplicación en 48 horas, con la característica de que esta aplicación debe utilizar en su funcionamiento una o varias fuentes de datos de organismos públicos.

¿Qué es ZGZagua?

ZGZagua es una aplicación que notifica los cortes de agua previstos en la ciudad de Zaragoza a los usuarios que hayan dado de alta alertas. Esta información se obtiene a partir de los datos proporcionados por el Ayuntamiento de Zaragoza a través de geoRSS en http://www.zaragoza.es/georss/feed?id=0. Una vez obtenidos los datos de los cortes, se cotejan las direcciones con las alertas registradas por los usuarios, y si hay coincidencia, se notifica al usuario vía e-mail.

¿De dónde surge la idea?

La idea surge de una situación que nos ha pasado a la gran mayoría: una mañana te levantas, abres el grifo y no hay agua. Cuando me pasó acudí enseguida en busca de información, y encontré que el Ayuntamiento publicaba estas incidencias en su web. Si bien hay que facilitar al Ayuntamiento de Zaragoza por la publicación que hace de muchos de sus datos y la cantidad de formatos en los que se puede acceder a ellos, entrar cada día para ver si te van a cortar el agua puede ser una ardua tarea, por lo que pensé que sería mucho más sencillo que una aplicación leyese esta información por ti y, si coincidía con tu dirección, te mandase un correo de aviso. Es ahí donde surgió la idea de ZGZagua.

¿Qué funciones tiene?

Como he dicho, la principal función de la aplicación es notificar a los usuarios vía correo electrónico cuándo se producirá un corte de agua en una o varias de las alertas que previamente han configurado. Para ello, hay que registrarse en la aplicación con una dirección de correo electrónico, que será la que se utilice para las notificaciones, y configurar todas las alertas que queremos que se nos notifiquen.

Además, contacté con el ayuntamiento para ver si había alguna forma de obtener un histórico de cortes de agua. Hasta el momento no existía tal posibilidad, pero a raíz de esta petición habilitaron un servicio que proporciona un máximo de 50 incidencias entre dos fechas pasadas como parámetro. A este servicio se puede acceder a través de http://www.zaragoza.es/georref/rdf/hilo/verHistorico_Incidencias?id=0&fechainicio=10/10/2010&fechafin=10/12/2010&srsname=wgs84.

Las dificultades

Pese a tener los ingredientes para la receta, por desgracia no todo era tan fácil como leer, comparar y notificar. Las principales dificultades que encontré fueron las siguientes:

• Las librerías más comunes para leer xml desde php no reconocen las coordenadas de geoRSS, por lo que tuve que recurrir al uso de otras librerías y la identificación de otros namespaces en el propio documento para extraer estos datos.
• Las fechas de las incidencias no eran homogéneas, y las más antiguas tenían formatos distintos o errores que tuve que tratar prácticamente uno por uno.
• Con los nombres de las calles pasa lo mismo: la misma calle puede tener varios formatos de nombre. Esta falta de homogeneidad, así como la no coincidencia con un callejero oficial, es el mayor problema que he encontrado a la hora de desarrollar esta aplicación, y sin duda será el que más fallos cause a largo plazo, ya que puede provocar que se notifique a usuarios que han dado de alta una alerta con un nombre similar de vía o bien que no se les notifique por figurar un nombre distinto en la incidencia creada por el ayuntamiento.
• El tiempo: todos los informáticos sabemos que el tiempo siempre es una característica más del proyecto. En este caso el plazo de 48 horas me resultó muy corto para desarrollar toda la aplicación (era el único componente del equipo). Esto me impidió mejorar funciones como el login de usuarios (en principio debería poder hacerse desde Facebook, Twitter, etc, pero sólo me dio tiempo a implementar servicios compatibles con openID, en concreto Google y Yahoo). Además, con mayor plazo hubiese podido mejorar la función de análisis sintáctico para la identificación de coincidencias en los nombres de vías, así como crear más informes sobre datos históricos con mapas con clusters de marcadores y mejorar otros aspectos no tan importantes como las hojas de estilo, pero el plazo es el que es y ahí está el fundamento del desafío.

Como conclusión final, diré que no me arrepiento de haber participado, ha sido una experiencia interesante (a la par que un poco estresante) pero bonita. Ayer cuando apagué mi portátil apenas pasadas las 12 de la noche (hora  a la que terminaba el plazo) casi sentí hasta un poco de pena. De todas formas, hubiese preferido sin duda alguna contar con más integrantes en el equipo, a ver si el año que viene es posible.

Próximamente os contaré más sobre la aplicación.

Un saludo.