11 de Octubre de 2009 · 6 min de lectura
Ayer por la noche abrimos al público nuestra prueba de concepto de lo que puede ser una página de reservas de hoteles: hotelestest. Al hablar de prueba de concepto me refiero a poder mostrar lo que se puede hacer con tecnología Python y Django en cuanto a aplicaciones orientadas al sector turístico. En nuestra comunidad (Balears) un tanto por ciento muy elevado de la informática gira en torno al negocio turístico (bueno, un tanto por ciento muy elevado de la economía para ser exactos). Cuando como empresa vas a hablar con alguien del sector y le dices que le harás su aplicación en Python y Django te encuentras normalmente con caras extrañas, salvo honrosas excepciones no conocen de qué les estás hablando. Han oido hablar de PHP, Java o punto-net y no ven claro lo que se puede hacer. Nuestra prueba de concepto tiene por objeto mostrar que desarrollar una aplicacion en Python y Django es sencillo, que la aplicación va tan rápida como la que más. Para hacer la demostración necesitábamos que la página se conectase a un motor XML/SOAP de un tercero, ya que de este modo se cubre el uso más habitual de este tipo de aplicaciones: una aplicación web donde el motor y la capa de presentación están separadas por un servicio XML. De los proveedores XML que contactamos recibimos una muy buena acogida por parte de Valadis/Versys. Nos dieron muchas facilidades para poder utilizar su entorno XML de pruebas. Su XML es muy sencillo de mapear y es bastante rápido, esto junto con su buena disposición nos decidió a utilizarlo como base de nuestra web, des de aquí muchas gracias por vuestra colaboración gente. La ideas que se presentan se pueden desarrollar con otros proveedores siempre que cumplan unos mínimos. La web estará siempre condicionada por las posibilidades del XML y por la velocidad del mismo. Así pues, tenemos una aplicación B2C que permite reservar hoteles y que conecta al motor XML de test de Valadis/Versys como proveedor externo. Como buen entorno de demo y pruebas he de decir que está en continua evolución y que los datos que se muestran son solo un subconjunto limitado de las que se tendrían en un entrono de producción. No nos fijemos pues en los datos, ni en si una foto o descripción sale o no sale, sinó en la parte importante de lo que se intenta mostrar: la tecnología subyacente. Por cierto, la web se puede probar sin problemas, no se realiza pago alguno ni control de la tarjeta de credito. Obviamente tampoco se envía la reserva al hotel. Una vez hecha la introducción vayamos a diseccionar a la bestia: El desarrollo Tal como he comentado la aplicación está desarrollada utilizando Python y Django, para el control de versiones se ha utilizado Subversion y Trac para el control del proyecto y la documentación. Para crear la aplicación hemos mapeado el XML a objetos Python con la librería lxml, una librería que envuelve la libreías C libxml2 y libxslt. La velocidad del C y la expresividad de Python en una combinación de alto rendimento. Para la depuración y programación hemos utilizado django-extensions, debug_toolbar, ipdb i ipython. La primer librería nos proporciona un conjunto de utilidades para la administración de la aplicaicón; debug_toolbar nos permite controlar en todo momento qué plantilla se utiliza, sus herencias, el sql que se genera, etc. La aplicación ipdb es un depurador de línea de ocmando, como el pdb pero con autocomepletado y resaltado de sintaxis; ipython es una consola Python que Django aprovecha si está instalada proporcioando autocompletado, resaltado de sintaxis y un gran número de comandos extra. Los editores más habituales en el desarrollo han sido Netbeans, Eclipse, Vim, Kate i Notepad++ (en Windows). El editor importa poco, todos están configurados para trabajar en UTF-8 y utilizar tabuladores de 4 espacios. Con esto tenemos suficientes para poder utilizar el editor más conveniente en cada momento. Para las páginas de contenido estático utilizamos django-page-cms. La idea es mostrar cómo un gestor de contenidos se puede integrar en la aplicación. Los css y javascript se comprimen antes de servirse gracias a django-compress. Esto quiere decir que podemos cachear los archivos meses, simplemente cuando cambia el css o el javascript generamos un nuevo archivo con un nombre distinto automáticamente. La configuración de sistemas. El entorno de ejecución de independiza de la máquina con un chroot y además hemos creado un entorno virtual separado para la aplicación utilizando virtualenv, esto os permite tener un control total sobre la librerías que instalamos y el Python Path. Siguiendo la mejores prácticas recomendadas hemos eparado los dominios que sirven el contenido estático del contenido dinámico. Esto es realmente sencillo en Django, sólo tienes que acordarte de escribir {{MEDIA_URL}} en los enlaces a imágenes, javascript y css. Dado que la aplicación se ejecuta en una máquina que comparte sus recursos con varias aplicaciones más, queríamos que el consumo de memoria y recursos fuese mínimo. Para ello optamos por utilizar el serviodr nginx en lugar de Apache y lo configuramos para que sirviera tanto el contenido estático como para actuar de proxy inverso hacia el motor WSGI que ejecuta la aplicación Django. Para el motor utilizamos el WSGI de CherrPy, una pila http de alto rendimiento escrita en Python (en breve probaremos también de utilizar Tornado). Con ello mantenemos una relación de consumo de recursos de máquina y rendimiento bastante óptima y una escalabilidad horizontal realmente fabulosa. Con un simple balanceador podemos ir añadiendo entornos chroot con un simple "copiar y pegar" y dentro de cada chroot podemos tener tantas instancias de la aplicación como soporte la máquina. Seguramente no sería necesario complicarse tanto la vida para una prueba de concepto, pero la idea es mostrar lo que se puede hacer técnicamente tanto en programación como en sistemas, y cómo el framework y los recursos se adaptan a las necesidades actuales de rendimiento. En pocas palabras, que podemos escalar hacia arriba y hacia abajo.
vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz stepping : 13 cpu MHz : 1994.999 cache size : 1024 KB top - 08:52:55 up 729 days, 13:56, 0 users, load average: 0.07, 0.02, 0.00 Tasks: 126 total, 1 running, 125 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1015232k total, 984036k used, 31196k free, 154472k buffers Swap: 2097144k total, 2948k used, 2094196k free, 90536k cached
La aplicación En la página principal nos encontramos con el buscador, el buscador típico añadiría. Utilizamos jquery-ui para el control de calendario y mostramos las funciones de autocompletado en los apartados destinos y nombre de hotel. Los errores se muestran en pantalla de manera poco intrusiva, sin mover la página. Para ello utilizamos plugins de jQuery y las capacidades de serialización de Python y Django complementándolo con la validación de formularios de Django. Es mucho más sencillo de lo que parece. Se puede ver también la utilización que se hace del CMS en las páginas de Aviso Legal por ejemplo y podemos ver cómo se muestran dos grandes grupos de ofertas. Dichas ofertas se crean en la parte de administración y no son para nada sofisticadas, pero sirven para postrar el dinamismo que se puede conseguir uniendo backoffice y presentación y el concepto de url semántica. Si hacemos clic sobre una oferta o directamente desde el buscador iremos a la página de resultados. Recordemos una vez más que es un entorno de pruebas y que los datos son los que son. La idea es mostrar cómo los datos del hotel se cargan dinámicamente mediante una llamada Ajax y cómo la aplicación mantiene los datos de selección. En esta página hemos puesto también un filtro javascript. Pulsando sobre el link de filtro por categoría desaparecen los hoteles de esa categoría. Se puede utilizar la misma idea para filtrar el resultado por otros campos (rango de precios, tipo de habitación, etc). A partir de aquí ya vamos a las pantallas que obtendrían al información del cliente y completarían la reserva, así como la pantalla de agradecimiento. Nada destacable técnicamente que no se hay visto ya en pantallas anteriores. Paso a producción Esta aplicación no va a pasar a producción. Recordemos que es una prueba de concepto, sirve para mostrar ideas de programación, conceptos tecnológicos, de optimización, diseño y maquetación. Lo que sí sería factible sería desarrollar una aplicación a medida utilizando estas tecnologías. La comercialización será siempre de un tercero, APSL se limita a la parte técnica. En todo caso sería necesario desarrollar una serie de módulos que en la prueba de concepto se han obviado:
La aplicacción tal como está y en sus posibles evoluciones tiene por objeto que gente como APSL que nos dedicamos al desarrollo de soluciones web con Python y Django puedan mostrar al mundo turístico lo que se puede hacer. Consideramos la aplicación como un proyecto mascota: dedicamos las horas que queremos y podemos. Si logramos acercar estos conceptos tecnológicos al sector turístico nuestro trabajo habrá valido la pena.
Volver al blog