Archive for the ‘APSL’ Category

Creant bits amb Python i Django

By aaloy on December 7th, 2009

El pasado viernes 4 de diciembre, entre las 4 i más de las 9 de la noche tuvo lugar la reunió “fent bits”, dedicada a Python y Django. Nos reunimos más de 25 programadores interesados en Python y Django, en la tecnología y en lo que los lenguajes dinámicos nos pueden ofrecer.

El workshow surgió de un twitt, a partir de ahí generé un apunte en mi blog personal y en poco tiempo había más participantes que disponibilidad de sitio.

La experiencia ha sido fantástica, tanto que por poco que podamos vamos a repetir.

Algunos enlaces del evento:

Se pueden obtener el código de ejemplo a través del repositorio appfusedjango de Google Code y hemos creado un site para la documentación de los ejemplos realizada en Sphinx.

Como incubados en el Parc Bit, el Incubit permite a APSL utilizar (previa reserva) las salas de formación y conferencias. Gracias a esto este evento ha sido posible, ya que el Parc Bit nos ha cedido tanto la sala como el proyector y la valiosa colaboración de Guillem que nos ayudó a con las conexiones de la sala.

Posted in

Una prueba de concepto: APSLHOTELES

By aaloy on October 11th, 2009

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.

01
vendor_id   : GenuineIntel
02
cpu family  : 6
03
model       : 15
04
model name  : Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz
05
stepping    : 13
06
cpu MHz     : 1994.999
07
cache size  : 1024 KB
08
 
09
top - 08:52:55 up 729 days, 13:56,  0 users,  load average: 0.07, 0.02, 0.00
10
Tasks: 126 total,   1 running, 125 sleeping,   0 stopped,   0 zombie
11
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
12
Mem:   1015232k total,   984036k used,    31196k free,   154472k buffers
13
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:

  • Definir los texos de los contenidos estáticos.
  • Creación de filtros javascript
  • Paginación de resultados
  • Conexión a una pasarela de pago
  • Generación y envío del bono al cliente
  • Backoffice de gestión y control
  • Optimizaciones adiconales como proxy-cache de imágenes y balanceo de carga.
  • Política de backups.

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.

Posted in

ADSL: misión imposible?

By aaloy on October 10th, 2009

La historia con nuestra conexión ADSL en el Parc Bit es tan surrealista que creo que merece ser contada en el blog, no sé si convendría llamar ya mismo a la buabuambulancia, pero de todos modos ahí va:

Como incubados en el Parc Bit nos dijeron que tendríamos una conexión a Internet compartida de 10 Mb. La conexión funcionaba bastante bien, algún corte que otro sobre las 17:15 h que nunca llegué a aclarar, pero con tiempos de ping buenos y una subida más que decente. Ideal para trabajar.

En la tercera semana de agosto recibidos un e-mail de la dirección de parque diciéndonos que por razones legales, porqué alguien había hecho mal uso de la conexión, etc los incubados nos quedábamos sin conexión a principios de septiembre. Menos de una semana para contratar una nueva línea y con la mitad de los incubados de vacaciones. Olé!

Personalmente reclamé al Parc Bit. El coste de la ADSL era lo de menos, el problema era tener que conseguir que una teleco en agosto te pusiera una conexión en menos de una semana. Supongo que se apiadaron de nosotros y nos dieron un mes más de plazo. Una manera poco elegante de intentar minimizar un problema que ellos mismos habían creado. Personalmente creo que aguantar hasta finales de años hubiese sido lo más razonable y no escudarse en excusas de “mala utilización de la línea por parte de no sabemos quien…”.

Bueno, empezamos a contactar con proveedores. Para ellos pedimos al Parc Bit que nos recomendara los más habituales y nos derivan a un comercial de ONO y al 1004 de Telefónica.

La comercial de ONO nos ofrece 12Mb/600K y 10Mb/1Mb, la segunda algo más cara que la primera. Telefónica por su parte nos ofrece únicamente 6 Mb y tenemos que pagar además la cuota de línea.  Decidimos ir con ONO. A la comercial le explicamos que sólo tenemos un mes para que se realice la instalación, así que para ir adelantando cosas le envío la documentación firmada por e-mail. En ONO no hay manera de efectuar los trámites on-line, tuvimos que ir hasta dos veces a entregar la documentación en las oficinas del comercial.

Cuando ya estaba todo listo y a una semana de que Parc Bit nos cerrara el grifo la comercial de ONO nos dice que en el Parc Bit no pueden ser 12 Mb, que sólo 6 Mb y que a ver si todavía nos interesa. Le digo que eso se avisa antes y con el tiempo que tenemos no tenemos más remedio que pasar por el aro, pero que muy contentos no estamos, que para eso nos hubiésemos ido con Telefónica. Mientras a todos esto la conexión del Parc Bit que se suponía que se cerraba a primeros de octubre empieza a fallar miserablemente, conexiones y desconexiones cada 5 minutos, lo que hace imposible el trabajo en la oficina. Optamos por trabajar desde casa.

Pasan los días y aunque la comercial de ONO me dice que todo está en marcha no aparece nadie a realizar la instalación.   Ante esta situación no me queda más remedio que enviarle un e-mail a la comercial de ONO diciéndole que si no está este miércoles la on conexión ya no nos interesa. También la llamo por teléfono ya que no me ha contestado a los e-mails en los que le solicitaba información sobre el estado de la instalación. (Curiosamente esta comercial me dijo que la conexión para empresas era más cara que la particular porqué el servicio de atención a las empresas es mejor que a los particulares. Pobrecitos usuarios de ONO…!)

Finalmente logro ponerme en contacto con ella y me dice que el jueves (9/10) o el viernes tendré la conexión. Bueno, si es así nos conviene esperar, pensé y le digo que ok, que de acuerdo, que esperaremos hasta el viernes.

El viernes recibo una llamada en mitad de una reunión de un número desconocido. Son las 13:30, a las 14 h aproximadamente intento devolver la llamada. Pues sí, es un número de ONO, pero me remite a otro número de atención al cliente. Me temo lo peor, que ONO haya ido a instalar la línea y no haya encontrado a nadie, raro porqué les di el número de teléfono de contacto del Parc Bit. Llamo al responsable del Parc Bit y me dice que no le ha llamado nadie de ONO.

Llamo al  número de ONO y tras un rato de espera me atiende a una persona de atención al cliente que me pide el teléfono de ONO, le digo que no tengo, que es una alta nueva. Me dice que no puede atenderme hasta que no tenga teléfono.

Llamo a la comercial. Le explico el caso. No puede hacer nada y vuelvo a quejarme de que la línea hace semanas que debería estar instalada. La sensación de impotencia es total.

Camino a casa me paso por una tienda Vodafone Empresas a ver qué tienen en ADSL y de paso ver qué tienen en planes de empresa.  Le cuesta horrores encontrar el Parc Bit, cuando la encuentra de dice que sólo me puede ofrecer una línea indirecta de 3Mb, que el Parc Bit está muy mal comunicado (no puedo estar más de acuerdo con él). Solicito información sobre un plan de empresa. Me ofrece el que le parece que es más óptimo para nuestra situación, curiosamente es mucho más caro que los planes particulares.

Finalmente ONO me llama por la tarde. Una chica empieza verificar mis datos. Se los empiezo a dar y le digo a ver qué ha pasado, que no han llamado al responsable del parque . No sabe nada. Le explico que les estaba esperando hace días. Me corta, sólo quiere verificar mis datos para empezar a planificar la instalación. Aquí soy yo el que la corta, le digo que de eso nada, que si todavía tienen que planificar significa que no voy a tener la línea en mucho tiempo. Le digo que ya no me interesa.  A la chica le patina, como quien oye llover. Pues bueno, un cliente menos.

Llamo a telefónica. 1004. Se pone el contestador y digo que quiero contratar una ADSL de empresa. Al cabo de un par de preguntas más me ponen con una comercial. Me pide los datos y le digo que es para una empresa. Me dice que es otro número y que no puede pasarme.  Bueno, al menos es un 900. Eso sí, antes de colgar me intenta colocar el Imagenio y 30 Mb por 90 Eur/mes, que podré ver el futbol. Le explico que a mi el fútbol no me interesa, que lo que quiero es una conexión rápida a buen precio, que cuando la tengan que me llamen. Contesto a la encuesta de satisfacción y cuelgo.

Llamo el 900 y vuelvo a explicar el caso. Al cabo de un rato de contestar a las mismas preguntas que antes el comercial que me atiende me dice que he llamado al 1004 y me da el mismo número al que he llamado. Se lo digo. Me dice que seguramente su i.stema detecta mi línea y me envía a atención a clientes particulares, que llame desde un móvil. Antes de colgar intenta colocarme también el Imagenio. Esta vez no contesto a la encuesta.

Llamo desde el móvil. Esta vez no hay tantas preguntas y me pasan con una comercial directamente. Le explico que necesito una ADSL. Después de deletrear “Valldemossa” y “parc bit” me dice que en esa zona sólo me puede ofrecer una conexión ADSL rural. Le digo que no puede ser, que es un parque tecnológico, que deben tener conexión y que hace un mes y medio teníamos conexión ADSL en el parque. Aunque esté en el culo del mundo, le digo, es un parque tecnológico y se supone que debe tener conexión.

Parece que la frase le hace gracia y me pregunta si le puedo dar un número del Parc Bit. Le doy el de la centralita del parque. Esta vez sí, me dice que hay conexiones de 6 Mb. Le pido más caudal y me dice que no, que es el máximo que hay.

Contrato la conexión. Obtengo el número de caso y la promesa de que en unos 10 días tendré la conexión. Le doy el número del contacto en el Parc Bit y me despido.

Después de todo esto, todavía me quedan muchas preguntas sin respuesta:

  1. ¿Por qué las instituciones que deberían fomentar la innovación son tan poco conscientes que la conexión a Internet y el correo es un servicio fundamental hoy en día y lo corten de manera unilateral?
  2. ¿Cómo puede ser que en un parque tecnológico las ADSL que ofrezcan las telecos sean de menor calidad que las un usuario individual?
  3. ¿Cómo puede ser que un parque tecnológico no figure en los registros de las principales operadoras?
  4. ¿Por qué es tan difícil montar y mantener una empresa en este país? Parece que es mucho más fácil vivir de subvenciones.

Os dejo, ya oigo llegar la buabuabulancia!

Posted in
Tags

Motores de reservas: comprar o crear?

By aaloy on October 8th, 2009

Entendemos como motores de reservas aquella tecnología que nos permite poner a disposición de terceros (vías web, xml, etc) nuestra disponibilidad de habitaciones, permitiendo que se pueda hacer la reserva.

El términio es muy amplio y la solución técnica que le podemos dar no es única. En este artículo trataré de explicar un poco qué alternativas tenemos a la hora de elegir un motor de reservas y los condicionantes que nos pueden llevar a elegir una solución u otra.

A la hora de elegir una solución debemos plantearnos el porqué lo hacemos: si queremos una solución para salir del paso o queremos una solución que nos de flexibilidad. Si necesitamos vender sólo nuestro producto o bien necesitamos, como en el caso de las agencias, vender disponibilidad de camas de un gran número de proveedores.

Veamos las principales alternativas:

Página estática

Listamos las posibilidades en nuestra web y el cliente rellena un formulario. Todo el proceso se realiza manualmente y no hay control de cupo y sí un procesamiento totalmente manual de la reserva.

Pongo esta opción por completitud, pero es la menos aconsejable, pero obviamente es la más rápida de desarrollar y mantener.

El iframe

Un iframe es una página dentro de una página. Es la solución que cuesta menos de poner en producción ya que se limita a unas pocas líneas de código HTML dentro de nuestro portal web. Si no tenemos portal obviamente habrá que crearlo.

Es la solución que presenta más desventajas desde el punto de vista de la hipoteca tecnológica (el precio que pagamos a la larga por elegir una solución), de dependencia del proveedor y por posicionamiento.

Hay que tener en cuenta que es el proveedor del iframe el que tienen el motor de reservas y lo aloja en sus servidores. Nosotros no tenemos control alguno sobre ni sobre el iframe ni nuchas veces sobre los resultados que aparecen.

El grado de integración que podemos tener con el iframe es mínimo, ya que recordémoslo, se trata de una página que no es nuestra y que por tanto tendremos únicamente lo que el proveedor del iframe nos proporcione.

En tema de posiciamiento de nuestra web el iframe representa un gran problema, ya que recordémoslo nuevamente, el iframe no forma parte de nuestra página, y por tanto no vamos a poder posicionar nuestro portal de modo tant eficiente como si todo el contenido fuese nuestro.

En resumen:

  • tiempo de puesta en producción: bajo
  • control: poco
  • dependencia del proveedor: alta
  • personalización: baja
  • indexabilidad: nula
  • desarrollo y mantenimiento: sólo contenido

Servicios XML

El motor de reservas sigue estando controlado por un proveedor externo pero este nos proporciona un interfaz xml con el que comunicar con él. Algunos proveedores XML pueden servirnos todo su contenido o bien únicamente contenido con contrato o cupo propio, por lo que también pueden ser una solución para cadenas y pequeños TTOO que no deseen mantener un motor propio.

El desarrollo de la aplicación web es más costoso ya que se necesita hacer una transformación entre los datos que nos suministra el proveedor (texto en XML) y la web y normalmente añadirle reglas de negocio para la presentación de resultados y precios. Se deben aplicar optimizaciones adicionales para agilizar los tiempos de respuesta de nuestra web y añadir una capa adicional de código que nos independice el XML del proveedor de las funcionalidades de nuestra web, de este modo si cambiamos de proveedor XML sólo tendremos que cambiar una pequeña parte de la web.

El grado de integración que podemos tener en nuestro portal web es muy alto, ya que el proveedor se limita a ofrecernos información de disponibilidad y nosotros decidimos qué y como lo presentamos. El posicionamiento por tanto no está limitado por la tecnología XML que utilizamos.

El grado de depenencia con el proveedor es alto, pero tomando algunas precauciones (como la de añadir una capa de procesamiento intermedia) podríamos dado el caso, cambiar de proveedor sin tener que empezar totalmente de cero. También estamos limitados por la interfaz de acceso que nos proporcione el proveedor (la API XML) y por el flujo que tenga del proceso de compra.

En resumen:

  •  tiempo de puesta en producción: medio
  •  control: alto
  •  dependencia del proveedor: media
  •  personalización: alta
  •  indexabilidad: alta
  •  desarrollo y mantenimiento: mapeo del xml y contenidos

Motor propio a medida

Tener un motor propio nos da control total sobre nuestro producto. Podemos elegir qué y cómo vamos a vender y cómo vamos a poner nuestro producto en la web o si vamos a permitir conexiones de terceros.

El motor puede estar optimizado para nuestro tipo de negocio, de modo que se tendría un motor con optimizaciones diferentes para hoteles de costa que para hotels de nieve. Al estar desarrollado a medida podemos alcanzar cotas de rendimiento y adaptación mucho más altas que en cualquiera de los dos casos anteriores.

Mantener un motor propio nos permite desarrollar nuevos productos e ir construyendo nuestra plataforma de venta a medida.

Todo esto tiene un coste, y no es tan solo el precio, tener un motor a medida propio sólo tiene sentido si pensamos invertir en la web al 100% y junto con el área de marketing ir desarrollando nuevas vías de negocio y fidelización de clientes.

Es importante que mantengamos el control del código fuente del motor (del programa), en caso contrario no tendríamos la flexibilidad que estamos buscando y mantendríamos una dependencia alta con el proveedor. Por ejemplo, si nuestro departamento de programación no tiene tiempo para desarollarlo de manera interna, podemos externalizar el desarrollo y asegurarnos de que el proveedor transfiere el código fuente y el conocimiento de cómo está hecho a nuestros desarrolladores.

El motor será todo lo complicado o sencillo que nuestro negocio requiera. Puede ser una simple tabla con las camas o un completo sistema de disponibilidad y ofertas.

En resumen:

  • tiempo de puesta en producción: medio o alto
  • control: muy alto
  • dependencia del proveedor: baja (si hay transferencia de código y conocimiento)
  • personalización: alta
  • indexabilidad: alta
  • desarrollo y mantenimiento: desarrollo  y contenidos

Independientemente de la solución que elijamos, tenemos que verificar que podemos acceder a las estadísticas de reservas, que podemos exportar los datos que introducimos y ver si hay alguna posibilidad de que el sistema elegido se pueda comunicar con nuestro backoffice de gestión principal.

Éste es uno de los problemas principales: la venta web no se comunica con el backoffice de gestión y eso hace que haya un trabajo manual y rutinario que se podría evitar. A la hora de cambiar el backoffice convendría pedir siempre al vendedor sobre las posibilidades de importación de datos de venta y facturación del mismo. Un backoffice que permita la importación de datos en un formato estándard (texto plano, csv o xml por ejemplo) nos permitirá en un futuro integrar mejor las reservas que vengan de la web sin que tengamos que tener un programa que lo haga todo, pero eso es un tema que dejaré para otro día.

Cada una de estas opciones representa una apuesta mayor en la comercialización web y una implicación mayor de nuestros departamentos de IT (o de los partners que tengamos) y de los departamentos de marketing y ventas. Cuanto mayor es la apuesta mayor es el riesgo, pero también son mayores los beneficios.

Desde la blogosfera actualmente hay un movimiento importante contra el recorte ministerial en I+D, la frase que apunta Ricardo Galli también nos puede servir como conclusión en este apunte:

“Desde la revolución agraria las sociedades más desarrolladas no fueron las que podían comprar las herramientas, sino las que tenían los conocimientos y recursos para construirlas. Por ello en los países más desarrollados aproximadamente el 80% de la financiación de I+D proviene de fondos públicos. EEUU invierte en I+D  casi el triple del PIB que España, la media europea es el doble, y algunos paises europeos casi cuatro veces más. Las tijeras no generan atajos.”

Para comprar sólo necesitas dinero, pero te quedas sin el conocimiento.

Desde el punto de vista de control de negocio y mínima hipoteca tecnológica mis soluciones preferidas son el XML y el motor propio, pero obviamente cada uno conocerá mejor que nadie su situación. Espero que este apunte pueda servir para valorar las alternativas y encontrar la que mejor se adapte a las necesidades de cada negocio.

Nota: apunte publicado también en hosteltur

Posted in
Tags

Hello world!

By admin on August 9th, 2009 

from itertools import cycle
greeting = ['Hello', 'World!', '\n']
for word in cycle(greeting):
print word,

Posted in
Tags