Primera prueba pública

Aunque no haya publicado nada aquí durante los últimos meses, no quiere decir que el proyecto esté parado:

• Ya está automatizada la actualización de precios.
• Está creado el servicio web - JSON (¡gracias Juan!) y XML.
• Existe una pequeña demo para Android - la liberaré, palabrita de niño Jesús.
• Un formulario de consulta WEB, utilizando PHP y Ajax. Una vez más, ¡gracias Juan!

El objetivo de esta corta entrada es invitarte a usarlo. Si permites a tu navegador que te geolocalice, devolverá las gasolineras en un radio determinado - no pruebes más de 25km. que quien mucho abarca... -. Si no se lo permites, te mostrará los de la capital del reino... O si te sabes las coordenadas de tu casa de memoria... pues puedes introducirlas. Por último, en ningún momento se almacenan ni se almacenarán los datos que introduzcas en el formulario.

Cualquier comentario, irregularidad, reflexión, ... será bienvenido.

Aquí tienes el enlace http://gas.x10.bz/preciosGas.php

Un día cualquiera

    Unas pequeñas zapatillas se movían en la penumbra de la casa. Se dirigían con soltura al lugar donde su padre - cada vez con más frecuencia - tecleaba sin parar. Allí estaba, una vez más, hablando con el ordenador grande. A sus tres años asumía con toda naturalidad que se pudiera hablar con el ordenador grande, y con el pequeño, y con el mediano... y hasta con Josefa, que además sabía llevarte a todos los lados. Aunque el ordenador grande tenía algo especial.
- Aita, ¿puedo jugar al come-cocos?
- En un rato, mi niño. Ahora estoy trabajando. - El pequeño miró con los ojos muy abiertos a la pantalla. Aquello estaba lleno de letras de distintos colores. Sentía curiosidad. Le gustaban los colores.
 - ¿Estás pintando?
- No cariño, le estoy enseñando a Josefa a hacer una cosa. - El niño observó con detenimiento el móvil que estaba sobre la mesa conectado con un cable al ordenador. A continuación contempló el monitor.

- ¿A dibujar?
- No, mi amor. ¿te acuerdas que el otro día el coche tenía sed y tuvimos que parar a echar gasolina?
- Sí - dijo asintiendo con la cabeza.
- Pues estoy enseñando a Josefa dónde están todas las gasolineras. ¿Quieres saber cómo se hace? - El hijo nuevamente accedió con la cabeza. Confiaba en que, con un poco de suerte, le dejara jugar.
- Hay unos señores que todos los días ponen papeles en una caja en Internet.
- ¿De qué color es la caja?
- Verde.
- ¡Qué bien! ¡Tu preferido!
- Sí, lo es. Y ¿sabes lo que escriben en esos papeles?
- No.
- Escriben los nombres de todas las gasolineras. Y también los precios de la gasolina. Lo que he hecho ha sido abrir una cajita azul para guardar esos papeles.
- ¿Por qué has abierto una caja nueva?
- Porque a veces hay mucha gente a la vez leyendo los papeles de la caja verde, y nosotros no queremos molestarles. Además, dejaremos nuestra caja abierta, para que todo el mundo pueda leer lo que hay dentro.
- ¿Y esas letras? - dijo señalando al monitor.
- Éstas le explican a nuestra cajita azul cómo copiar todos los papeles de la caja verde a la nuestra. - El niño observaba de soslayo el teléfono. Intentaba adivinar qué tenía que ver todo aquel galimatías de cajas con el móvil. Su padre continuó.
- Más tarde, cuando le digamos a Josefa que queremos gasolina, abrirá nuestra cajita azul, cogerá los papeles de las gasolineras que están más cerca de nosotros, y nos dirá cómo llegar a cada una. ¿Lo has entendido?
- Sí, aita... ¿ya puedo jugar al come-cocos?
- Claro, mi niño. Ven aquí. - Dijo el padre mientras le sentaba en su regazo.

Concretando: diseño general

    Después de un largo parón estival, llega el momento de ponerse manos a la obra otra vez. Respecto al programa, cabe decir que no he hecho tanto como planeé, aunque como contrapartida he vuelto con las pilas cargadas. Y también con las ideas mucho más claras respecto a cómo va a funcionar todo de manera global.

    Hasta ahora he ido desarrollando pequeños snippets de código a medida que iba aprendiendo la tecnología. La idea fundamental era seguir una especie de aprendizaje "reutilizable", y no el típico HolaMundo(). Pero todo está siendo muy intangible hasta ahora. Centremos el asunto y busquemos un punto de apoyo para mover el mundo. Y quizá la mejor manera sea enfocar al origen:

 

¿De qué datos se va a nutrir?

    Es una decisión fundamental, que va a condicionar todo el desarrollo de la aplicación. Lo voy a hacer desde la web el Ministerio de Industria, Energía y Turismo, que es donde están publicados los datos actualizados de los precios de los carburantes. Esta decisión tiene una serie de ventajas:

• Están los precios actualizados porque "todos los operadores al por mayor y todas las personas que lleven la gestión efectiva de un punto de venta de carburantes para suministro a vehículos están obligados por la orden ITC/2308/2007 a enviar los precios practicados en ese punto de venta todos los lunes y cada vez que cambien dichos precios." 
• La información es pública.

Asimismo existen una serie de inconvenientes:

• Si bien existe una herramienta para consultar todas las gasolineras (por ejemplo: Gasolina 95), ésta devuelve un listado sesgado en cuanto a número de resultados. Además no incluye los campos de posicionamiento GPS de cada una. Es una información que necesito, ya que pretendo mostrar sólo puntos de suministro cercanos a una posición dada.
• Para mantener actualizados los precios, lo haré mediante los enlaces publicados en la propia web. En este caso sí que vienen especificadas las coordenadas GPS de cada punto. El problema es que la descripción en cuanto a cada uno es demasiado críptica y difícil de cruzar con el fruto de la consulta anterior. Sería difícil hacer una búsqueda por dirección, si así lo deseara.

     Lo ideal sería poder unificar y consultar el resultado de ambos informes en paralelo, para disponer - potencialmente - de consultas más potentes que las de la web oficial.

¿Cómo reunir, tratar y mostrar la información?
    En otras palabras, ¿cuál va a ser funcionamiento general interno? Sinceramente, creo que es mala idea dejar todo el tratamiento de información proveniente de los datos oficiales únicamente en manos de terminales móviles:

• El uso de almacenamiento interno va a ser alto con toda seguridad. Y más si habilitaramos consultas de precios históricos.
• El consumo de tráfico de red para mantener la base de datos actualizada sería intolerable en los casos de uso continuado del sistema. Los usuarios se quejarían - y con razón - de que su tarifa de datos mengua excesivamente.
• El rendimiento general del programa estaría penalizado por la descarga, tratamiento y clasificación de la información.
• La percepción general de sería de falta de fluidez, con lo que la experiencia de los potenciales usuarios no sería agradable.

     Siguiendo la máxima "divide y vencerás", la respuesta pasa por dejar ese trabajo "a otros". Es decir, crear un servicio web que se encargue de:

• Mantener actualizada una base de datos.
• Que ofrezca información "bajo demanda".

    Consecuentemente, esto conlleva una complicación extra - relativa - en cuanto a infraestructura, pero simplifica mucho el desarrollo del programa, ya que los móviles pasarían a ser meros clientes.

    Respecto a la  tecnología a usar:

• PHP+MySQL para crear el servicio web
• Python para el proceso de actualización automática de la base de datos.
• Para lanzar el script en Python de forma periódica, me serviré de cron.

    La razón principal para usar estas herramientas es que puedo publicar un servicio web casero de forma trivial. Además, si en un momento determinado necesitara externalizarlo, no tendría muchos problemas en encontrar un proveedor en internet que me ofreciese dicha logística.

La idea

    "Mira nena, aquí hay una cuestión: el concepto es el concepto". Y éste es sencillo: un comparador de precios de combustible. Decía un buen amigo que "todo lo que sube, baja. O se encaja". Bueno, pues el precio del petroleo ni baja, ni se encaja. El asunto es cuán rápido va a subir: cuando no es tensión en una zona de tránsito de crudo, es guerra en otra, o conflicto diplomático con productores, o alguna subida de impuestos más o menos encubierta, o que el perro de un jefazo tiene moquillo...

¿Cuáles son objetivos?
    Soy perfectamente consciente de que existen otros programas en el mercado que ya hacen lo que voy a desarrollar. No me preocupa. Como ya dije en El primer post, el objetivo no es la aplicación en sí, ni buscarme un hueco en el mercado con esto. Aclarado este punto, empecemos a tomar decisiones.

¿Qué tipo de aplicación quiero desarrollar?
    He valorado tres grandes grupos: de escritorio, web o móvil. Partiendo de las premisas planteadas en la entrada precedente, la respuesta es casi trivial:

• no quiero aprender a programar web - de momento - con lo que una página web queda descartada.

• quiero que sea útil: el escenario que me he imaginado es buscar gasolineras en zonas que no se conocen muy bien. Todos sabemos más o menos cuáles son las gasolineras más caras cerca de casa. Para este caso me parece que puede ser mucho más apropiado una aplicación móvil que una de escritorio. Después de todo, es más común tener a mano un teléfono cuando estás en el coche, que un portátil con conexión a internet.

¿Qué plataforma usar?
    Opciones: Symbian, Android, iOs, Windows Phone y Meego. Todas estas plantaformas cumplen la premisa de utilizar lenguajes y herramientas desconocidas para mi. Aunque viendo los ojitos que me está poniendo Josefa (mi Nexus One), no me puedo resistir: Android. Ya decidiré de qué versión partir.

¿Lenguajes y herramientas?
    Poco hay que decir sobre este punto: Java y Eclipse con el plugin de Android. El punto a favor es que las herramientas de desarrollo son multiplataforma:

• en casa yo uso linux. Me hubiera supuesto un conflicto decantarme por otro sistema móvil.
• si en un futuro se sumara más gente al proyecto no habría dificultades al respecto.

¿Primeros pasos?
    Comenzaré por el principio: documentarme. Pero eso es carne para otro post.