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.
- 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.
