• Like
  • Save
Memoria Proyecto Fin de Carrera
Upcoming SlideShare
Loading in...5
×
 

Memoria Proyecto Fin de Carrera

on

  • 2,780 views

Memoria presentada para el proyecto fin de carrera en la Universidad de Granada.

Memoria presentada para el proyecto fin de carrera en la Universidad de Granada.

Statistics

Views

Total Views
2,780
Views on SlideShare
1,990
Embed Views
790

Actions

Likes
1
Downloads
16
Comments
0

5 Embeds 790

http://visuse.wordpress.com 778
http://www.slideshare.net 6
url_unknown 3
http://www.365dailyjournal.com 2
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Memoria Proyecto Fin de Carrera Memoria Proyecto Fin de Carrera Document Transcript

    • Visuse: un meta-buscador visual José Luis López Pino 4 de julio de 2010 Tutor: Juan Julián Merelo Guervós
    • Índice general 1. Introducción 4 2. Denición de objetivos y especicaciones 5 2.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Proyectos similares . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Distribución de imágenes . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. ¾Buscador o meta-buscador? . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Especicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. Software y documentación libre . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Desarrollo del proyecto propiamente dicho 10 3.1. Descripción del funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Herramientas y tecnologías utilizadas . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Del lado del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Del lado del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Módulos para búsquedas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. Desarrollo de un módulo . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.2. Estructura de un módulo . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.3. Puntuación de resultados . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.4. Módulos desarrollados . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4. Visualización de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Carga de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.6. Determinar la posición de los resultados . . . . . . . . . . . . . . . . . . . 18 3.6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.2. Algoritmo voraz utilizado . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.3. Aplicación del enfriamiento simulado . . . . . . . . . . . . . . . . . 20 3.7. Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Evaluación y conclusiones 23 4.1. Evaluación de la disposición de imágenes . . . . . . . . . . . . . . . . . . . 23 4.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 A. Instrucciones de utilización 28 B. Dependencias de los módulos 29 2
    • Índice general Bibliografía 30 3
    • 1. Introducción Visuse es un acrónimo de VISUal Search Engine, ya que el proyecto consiste en un meta-buscador que clasica y muestra los resultados obtenidos de distintos buscadores y sitios web de forma visual, centrándose sobre todo en contenidos multimedia como imágenes, vídeo y audio. La forma de mostrar los resultados de muchos servicios de búsqueda no permiten buscar diversos contenidos al mismo tiempo y ofrecen una navegación incómoda para visualizarlos. Mostrar los resultados de una forma visual aprovechando la totalidad de la pantalla resulta más cómodo para los usuarios, además de resultar muy útil para niños, personas que tengan problemas para leer, personas con un bajo nivel de alfabetización o dispositivos en los que sea incómodo leer. El desarrollo del proyecto tiene dos partes principales: el desarrollo de la parte del servidor, que se comunica con los buscadores para trabajar con los resultados, y la parte del cliente, que se encarga de la visualización de dichos resultados. 4
    • 2. Denición de objetivos y especicaciones 2.1. Estado del arte 2.1.1. Proyectos similares Si consultamos cualquier lista de sitios más visitados de la red, encontramos que la clasicación está encabezada por buscadores, redes sociales y sitios de contenidos multi- media tal y como se puede apreciar en http://www.alexa.com/topsites. Los buscadores llevan indexando la red y ayudando a los usuarios a encontrar recursos desde 1993 y en la última década, ayudado por el aumento de la velocidad de acceso de los usuarios, los contenidos multimedia han inundado la red. Es lógico que en todo este tiempo hayan surgido distintos buscadores especializados en contenidos multimedia y los buscadores tradicionales también hayan desarrollados sus versiones centradas en dichos contenidos. Sin embargo, estos buscadores siguen mostrando los resultados de forma similar a los resultados de texto, organizándolos en páginas con muy pocos resultados y añadiéndoles pequeños thumbnails, haciendo la búsqueda del usuario lenta e incómoda. Recientemente ha habido algunos intentos para mejorar estas interfaces: El buscador Bing añadió un servicio llamado Visual Search (http://www.bing. com/visualsearch), cuyo objetivo es sustituir las tradicionales búsquedas de tex- to por búsquedas a través de imágenes clasicadas en categorías y subcategorías, para ello diseñaron una nueva interfaz utilizando Silverlight. Sin embargo, el obje- tivo de este servicio no es encontrar imágenes u otros contenidos multimedia, sino reemplazar las tradicionales búsquedas de texto por otras visuales. oSkope (http://www.oskope.com/) por su parte es otro buscador que permite, mediante Flash, visualizar de distintas maneras los resultados de otros buscadores como Google Images o Youtube. Sus principales desventajas son que no nos per- mite combinar los resultados de distintos buscadores, no ordena por puntuación los resultados en el mural y no permite visualizar los contenidos multimedia en el propio buscador. El servicio Spezify (http://spezify.com/) sí que permite combinar resultados de distintos buscadores multimedia y visualizarlos en el propio buscador, sin embargo, no realiza ninguna ordenación según la importancia de los resultados y su distri- bución en un gran mural por el que tenemos que ir desplazándonos y en el que hay grandes huecos; todo esto hace muy difícil encontrar los resultados que deseamos. 5
    • 2. Denición de objetivos y especicaciones Como se puede apreciar, ninguno de los buscadores existentes ha trabajado la disposición de las imágenes en función de su importancia ni la disposición óptima de los resultados para formar un muro que no desaproveche espacios. 2.1.2. Distribución de imágenes Ha habido múltiples intentos para conseguir una distribución óptima de elementos sobre una página, problema que se conoce como 'layout optimization' (optimización de la distribución). Sin embargo, como veremos, ninguno es igual al que en este proyecto he tratado. En 1979, Daniel Selator[13] ya se planteaba un problema similar, al que llamaba 'pac- kage in two dimensions' (empaquetamiento en dos dimensiones), utilizando un inteligente método que consistía en colocar primero las piezas más grandes. Existen diversos trabajos que plantean el mismo problema con la intención de aplicarlo a periódicos y anuncios. En todos estos casos se ciñen a la estructura de columnas y los tamaños de los anuncios no eran modicables, lo que no sucede en este proyecto: Ramesh Johari y otros (1997)[10] aplicaron enfriamiento simulado para resolver el problema de la colocación de anuncios en las guías telefónicas. J. González y J. J. Merelo[4] también aplican enfriamiento simulado para buscar la mejor distribución de artículos en un periódico web, intentando minimizar el tamaño medio de los huecos. Charles Jacobs y otros[9] utilizan diseños basados en rejilla para optimizar la dis- posición en periódicos y revistas. Más recientemente, en 2007, Gen Hattori y otros[6] aplican los mismos conceptos a la adaptación de sitios web para dispositivos móviles. En 2001 Joe Geigel y Alexander Loui[2] utilizan algoritmos genéticos para realizar la distribución automática de un álbum de imágenes. Sin embargo, ellos intentaba optimizar el diseño de la página y permitían transformaciones como rotaciones en las imágenes y debían estudiar la superposición de las imágenes. Analizando todos los trabajos anteriores, nuestro problema tiene dos características que lo hacen exclusivo: la posibilidad de redimensionar los contenidos pero respetando las proporciones de la imagen y la necesidad de que tengan tamaños distintos en función de su importancia. Además también hay que intentar que no haya superposición de imágenes o que sea mínima. 2.2. ¾Buscador o meta-buscador? Un meta-buscador es un buscador que, en vez de indexar contenidos, realiza consultas a otros buscadores y los clasica y muestra como una única lista (en el caso de Visuse, de forma visual), lo cual tiene distintas ventajas y desventajas. 6
    • 2. Denición de objetivos y especicaciones Un meta-buscador permite al usuario obtener los resultados de distintos buscadores de una forma homogénea, sin tener que acceder independientemente a cada uno de los buscadores y disponiendo de esa forma de un número mayor de resultados con una única búsqueda. Desde el punto de vista del administrador también es muy cómodo, ya que es muy difícil indexar la web, que se expande a un ritmo enorme, y que supone desarrollar y mantener una gran cantidad de software, desarrollar una araña web (o web crawler) que inspeccione la web repetitivamente, evitar técnicas poco éticas usadas por algunos desa- rrolladores como el cloaking, el espacio de almacenamiento para las páginas indexadas, etc. Por otra parte, desde el punto de vista del administrador del buscador supone otra serie de problemas, muchos de ellos debidos a las restricciones que ponen los buscadores que incorporemos: no podemos personalizar y elegir la información con la que trabajamos, podemos ser bloqueados indiscriminadamente por los buscadores, hemos de cumplir las limitaciones que ellos nos imponen, debemos cachear resultados para que no ocurra lo anterior, tenemos que lidiar con distintos sistemas de comunicación para cada uno de los buscadores, la homogeneizar la información recibida puede ser difícil, tenemos que ltrar o gestionar los operadores utilizados por los distintos buscadores (+, and, or, site: ), nos genera una gran cantidad de consultas salientes de las que debemos obtener respuesta de una forma rápida, etc. Sin embargo, un meta-buscador no supone ninguna desventaja para el usuario, excepto que en ocasiones puede resultar un poco más lento que un buscador normal. La decisión tomada tras evaluar las ventajas y desventajas de las dos opciones fue desarrollar un meta-buscador, esto es debido a que se pueden obtener resultados más rápidamente para poder desarrollar también el el front-end de la aplicación (las consultas al buscador, la organización de resultados, la visualización de resultados, etc.). Sin embargo, aunque el desarrollo del proyecto incluye un meta buscador con distintos sistemas de búsqueda, el front-end de la aplicación no depende de él en absoluto y puede ser fácilmente adaptado para trabajar con un buscador corriente. 2.3. Objetivos En primer lugar se debe lograr la intercomunicación con los distintos buscadores para obtener los resultados relacionados con la búsqueda, para lograr este objetivo se han desarrollado diversos módulos que se encargan de la comunicación de un buscador, debido a la heterogeneidad de formas a los resultados que nos imponen los distintos buscadores. En segundo lugar se encuentra la organización de la información proveniente de los buscadores. Cada buscador nos facilita ciertas informaciones básicas de los resultados comunes a todos como la dirección donde se encuentra el recurso o especícos del tipo de resultado como un thumbnail en el caso de imágenes, además de otra información heterogénea en función del buscador con que estemos trabajando que es importante obtener y almacenar para tener más criterios con los que organizar los resultados. También son objetivos del proyecto la puntuación de los distintos resultados que, como comentamos, dependerá de la información que nos facilite el buscador del que procede y 7
    • 2. Denición de objetivos y especicaciones deberán establecerse los criterios con cuidado para conseguir una visualización interesante para los usuarios, premiando los resultados más relevantes en función principalmente de su relación con la búsqueda y castigando aquellos que no estén relacionados. Una vez obtenidos los resultados y estando estos organizados y puntuados es el momen- to de realizar la mejor visualización para dichos resultados, siendo importante mostrar primero y en mayor tamaño los resultados mejor puntuados y al mismo tiempo intentando dejar el mínimo de huecos posibles. 2.4. Especicaciones Una vez establecidos unos objetivos claro para el proyecto, era necesario también es- tablecer una serie de especicaciones que se respetasen durante la consecución de estos. Una necesidad básica es intentar que funcione en la mayor cantidad de navegadores posible, aunque esto para el desarrollador web siempre supone un compromiso entre crear aplicaciones que funcionen en navegadores obsoletos tecnológicamente o utilizar nuevas propiedades y tecnologías que permiten crear mejores aplicaciones con impresionantes funcionalidades (como HTML5). En la parte de la visualización de resultados, también resulta indispensable que éstos sean mostrados adecuándose a las dimensiones de la ventana del navegador con la que el usuario está visitando el sitio web, ya que todos los navegadores nos facilitan esta información y debemos adaptarnos al máximo a la heterogeneidad de resoluciones que hoy en día utilizan los usuarios, cada vez más grandes en los equipos de escritorio y al mismo tiempo cada vez en pantallas más pequeñas con la proliferación de dispositivos móviles. Por contra, esto nos supone la imposibilidad de almacenar (cachear) la forma de disposición de los resultados, ya que será distinta para cada usuario. Por otra parte, la visualización de los resultados también tiene que ser rápida. La carga de muchos recursos es lenta, pero no podemos tener al usuario esperando a que carguen todos los recursos para que pueda navegar, debemos intentar que carguen y que sean usables por el visitante lo antes posible. Por último, los buscadores y las formas de comunicación que ponen a disposición de los desarrolladores cambian rápidamente, por lo que también es necesaria la fácil extensión mediante módulos que se encarguen de obtener y puntuar los resultados de un buscador. De esta forma, cualquier persona con bajos conocimientos sobre cómo funciona la aplicación puede ampliar la cantidad de resultados ofrecida de una forma sencilla incorporando nuevos buscadores o actualizando los existentes. 2.5. Software y documentación libre Todo el software desarrollado está liberado, bajo la licencia GPLv3[1], al igual que toda la documentación sobre este proyecto. Esto signica que cualquiera puede usarlo para cualquier propósito, compartirlo, estudiar su funcionamiento, modicarlo y com- partir esas modicaciones. Pero el software libre no signica únicamente una serie de 8
    • 2. Denición de objetivos y especicaciones libertades para el usuario, también es benecioso para el propio proyecto: recibe visibi- lidad (publicidad), logra mejoras gracias a la retroalimentación de los usuarios y recibe la colaboración de otros usuarios. La liberación del software y la documentación también permite la transferencia de conocimientos y la innovación tecnológica, haciendo que el proyecto no quede estancado una vez que nalice, sino que pueda servir para cubrir futuras necesidades continuan- do su desarrollo o integrándose en el de otro proyecto. Este proyecto, además, se basa completamente en estándares abiertos y herramientas libres, por lo que es también una obligación moral devolver a la comunidad lo recibido, además de que algunas licencias obligan a liberar los desarrollos derivados. El proyecto no ha sido únicamente liberado, sino que ha sido desarrollado en un proce- so completamente abierto, siendo accesibles todos los avances del desarrollo en una forja (https://forja.rediris.es/projects/cusl4-visuse/) y publicando información so- bre él en un blog. El desarrollo ha permitido también la colaboración de los usuarios mediante el envío de sugerencias de mejoras y errores. Por último, el proyecto ha participado Concurso Universitario de Software Libre (http: //www.concursosoftwarelibre.org) en el que ha recibido el 2º premio al Mejor Proyec- to Comunidad en el concurso nacional y Premio a la Difusión en el concurso granadino. 9
    • 3. Desarrollo del proyecto propiamente dicho 3.1. Descripción del funcionamiento El proyecto cuenta con dos partes claramente diferenciadas pero que deben estar per- fectamente comunicadas: un back-end que se encarga de obtener los resultados de los distintos buscadores, organizarlos, puntuarlos y servirlos y un front-end (con el que in- teractúa el usuario) encargado de obtener dichos resultados, determinar cual es la mejor disposición posible a realizar y mostrarlos al usuario. Cuando el usuario indica al front-end que desea realizar la búsqueda de unos determi- nados términos al usuario, éste realiza consultas asíncronas (tecnología conocida como AJAX) que consisten en peticiones HTTP corrientes, una por cada buscador, y que recibe el back-end. Esta parte se encarga de retransmitir esa petición a los distintos buscadores para obtener los resultados de clasicará y puntuará, devolviendo al front-end los resul- tados procesados de cada buscador en cada una de las peticiones. Se realiza el proceso de petición-respuesta utilizando JSON en distintas peticiones HTTP para que los buscado- res más lentos no provoquen que los resultados de los más rápidos se demoren en llegar y se puedan devolver códigos de error cuando se produzcan errores en la obtención o el procesamiento de los resultados de uno de los buscadores. Cuando el front-end recibe los resultados pasa a procesarlos, para lo cual los organiza por importancia y determina la mejor forma de mostrarlos en función de la importancia de ellos e intentando dejar la menor cantidad de huecos en la pantalla. La ejecución de esta parte es particularmente importante, ya que los usuarios necesitan que se les empiece a mostrar la información lo más rápido posible, aunque aún no estén disponibles todos los resultados o no sea óptima su disposición en la pantalla. 3.2. Herramientas y tecnologías utilizadas Las herramientas y tecnologías escogidas para el desarrollo de un proyecto deben ser escogidas cautelosamente, ya que pueden suponer el fracaso de éste o pueden aumentar su complejidad, para lo cual deberemos conocer cuales son las distintas alternativas y las necesidades de nuestro proyecto. Además todas las tecnologías son libres y compatibles con la licencia escogida para liberar el proyecto. 10
    • 3. Desarrollo del proyecto propiamente dicho Figura 3.1.1.: Ilustración del funcionamiento del proyecto 3.2.1. Del lado del cliente En cuanto a ejecución de código en el navegador del usuario para determinar la dispo- sición de los resultados, las alternativas son básicamente dos: utilizar código JavaScript o una aplicación utilizando la tecnología de Adobe Flash. La primera alternativa está hoy presente en la práctica totalidad de las navegadores y, aunque hay problemas por las diferencias entre los distintos intérpretes, existe cierto grado de estandarización. La segunda nos permitiría evitar esas diferencias de ejecución en los distintos navegadores si utilizamos la implementación ocial, sin embargo las aplicaciones Flash son pesadas de cargar, su tecnología es privativa (lo que va en contra de la naturaleza abierta de la web) y obligan al usuario a instalar un complemento a su navegador que muchas veces no está disponible en todos los navegadores (como pasa en los de los dispositivos móviles). Iguales problemas que Flash presenta la tecnología Silverlight de Microsoft y además la cuota de navegadores en la que está presente es muy baja. Debido a la falta de estándar de JavaScript/ECMAScript es aconsejable la utilización de una biblioteca que nos permita no tener que preocuparnos porque nuestros desarrollos se ejecuten de formas distintas en los diferentes navegadores. Además la utilización de grandes bibliotecas o framework simplican la manipulación del DOM (Documment Ob- ject Model), el tratamiento de eventos y la comunicación asíncrona. Dentro de la amplia variedad de bibliotecas para JavaScript disponibles me decanté por el uso de jQuery por su velocidad y simplicidad, porque tiene una baja curva de aprendizaje y cuenta con una excelente documentación y porque pone a nuestra disposición una gran cantidad de 11
    • 3. Desarrollo del proyecto propiamente dicho extensiones. A la hora de hacer la disposición de resultados en la pantalla, una vez descartada la tecnología Adobe Flash y Microsoft Silverlight por las razones comentadas, nos quedan básicamente dos alternativas: la utilización de XHTML/HTML o de HTML5[7]. Para disponer imágenes en un punto concreto de la página es suciente con la utilización de HTML en combinación con hojas de estilos indicando a las imágenes que se sitúen en posiciones absolutas, aunque sería más complicado lograr complejos efectos de animación (aunque no imposible, utilizándolo en combinación con JavaScript). En cambio, HTML5 es aún un borrador, no aportaría demasiadas funcionalidades (únicamente la inclusión de efectos bonitos con la utilización del elemento canvas) y está aún en proceso de implan- tación, sólo disponible en las últimas versiones de los distintos navegadores y en algunos casos parcialmente. 3.2.2. Del lado del servidor Del lado del servidor, se eligió como lenguaje de programación Python debido a que se trata lenguaje de alto nivel que sin embargo no se puede considerar lento y que tiene una importante presencia entre las aplicaciones web debido a su velocidad y la facilidad para desarrollar en él. Además genera un código fácil de leer y su biblioteca estándar muy completa, siéndome especialmente útil en la serialización de los objetos en JSON, mediante la biblioteca jsonpickle, para transmitirlos al lado del servidor. En comparación con otros framework, con Django es fácil desarrollar código más man- tenible, nos facilita el manejo de los datos y su migración, está muy bien documentado, goza de una gran popularidad y está apoyado por una importante comunidad .[12] Además, Django[8] nos permite: Rápida creación de sitios web complejos. Fácil empleo del patrón M.V.C. Desarrollo de sitios con estructuras modulares. Uso simple de plantillas. Fácil gestión de los accesos a bases de datos. Creación de direcciones amigables. Uso de cachés. Utilización simple de extensiones. 3.2.3. Comunicación En la comunicación, como se ha comentado, se hace uso de JSON (JavaScript Object Notation), un formato ligero para el intercambio de datos, frente a su principal alternativa XML[5], un lenguaje de marcado de propósito general. La elección de JSON se debe a la 12
    • 3. Desarrollo del proyecto propiamente dicho velocidad en que se procesa en JavaScript, a que resulta muy simple tanto para humanos como para máquinas, a que está orientado a las estructuras de datos de los lenguajes de programación modernos y a que no necesitamos la validación mediante esquemas de las respuestas. Realmente esta decisión no supone un gran compromiso, con unas simples modica- ciones la comunicación se podría realizar utilizando XML sin afectar a las dos partes involucradas en la comunicación. Figura 3.2.1.: Ilustración resumen de las tecnologías utilizadas 3.3. Módulos para búsquedas La estructura de módulos ha tenido que ser reestructurada en dos ocasiones, con el ob- jetivo de reorganizar cierta información, facilitar las pruebas sobre los módulos y facilitar la extensibilidad de la aplicación. El resultado nal utiliza las herramientas facilitadas por la programación orientada a objetos para crear un diseño de clases que se ajuste adecuadamente a las necesidades de organización de la información. La estructuración propuesta también mantiene la conguración de los módulos sepa- 13
    • 3. Desarrollo del proyecto propiamente dicho rada de la lógica de funcionamiento de ellos, para que el servidor pueda ser administrado por cualquier persona sin que conozca el funcionamiento interno de los módulos. La conguración de los módulos permite administrar aspectos como los módulos en funcio- namiento, las claves exigidas por algunos motores de búsqueda para realizar las consultas o el número de resultados obtenidos por cada buscador. Las pruebas desarrolladas se apoyan en el sistema de pruebas facilitado por Django para simular peticiones a todos los módulos y comprobar que todos devuelven un código de estado correcto. 3.3.1. Desarrollo de un módulo El funcionamiento de un módulo consiste en cuatro sencillo pasos: 1. Obtener los datos del buscador (usando XML, JSON o lo que corresponda). 2. Crear una instancia de la clase por cada resultado. 3. Creamos una lista de resultados. 4. Establecer la puntuación de cada uno de los resultados. Pero previamente al desarrollo del módulo, se debe encontrar la forma de comunicarse con el buscador deseados, lo cual suele ser una tarea ardua debido a que los buscadores imponen fuertes restricciones al uso de sus servicios y en algunas ocasiones ni ofrecen este servicio. Servicios de búsqueda como Bing no permiten que se mezclen sus resultados con los de otros buscadores y otros como Yahoo anuncian que la utilización de este tipo de servicios pronto pasará a ser de pago. También suelen requerir que nos registremos en sus sitios como desarrolladores para facilitarlos una clave que deberemos incluir en sus descargas, e incluso algunos como el buscador del servicio de vídeos Vimeo requiere la identicación de un usuario, aunque sea empleando el protocolo OAuth que evita que tengamos que facilitar nuestra contraseña. Una vez conseguida la forma de comunicarnos con el buscador, debemos considerar los datos que nos facilitan, como mínimo debemos tener la dirección al recursos y un thumbnail para poder mostrarlo. 3.3.2. Estructura de un módulo Cada módulo debe contener dos clases: una que almacena la la información relevante de los resultados obtenidos y otra que se encarga de realizar la búsqueda. La clase que almacena la información de los resultados obtenidos hereda de la super- clase Result y si se trata de un resultado visual, también de ImageResult. Esta clase contiene un constructor (__init__ en Python) que inicializa las variables y otra que realiza la estimación de a puntuación del resultado, para lo cual recibe como parámetro el término de búsqueda introducido. La clase que realiza la búsqueda hereda de SearchModule e implementa dos métodos básicos: uno que realiza la comunicación para obtener los resultados del buscador y otro 14
    • 3. Desarrollo del proyecto propiamente dicho que obtiene los atributos correspondientes de un resultado y crea con ellos una instancia de la clase anteriormente descrita. Si hay algún parámetro de la búsqueda que debe ser congurable, debe ser declarado en el chero cong.py. Para que los resultados del módulo desarrollado sean accesibles únicamente hay que añadir el nombre del módulo al diccionario de módulos de dicho chero. Figura 3.3.1.: Jerarquía de clases usando como ejemplo el módulo para Youtube 3.3.3. Puntuación de resultados También es interesante obtener datos adicionales que nos permitan puntuar los resulta- dos de los módulos., como el título del recurso, la descripción, las etiquetas, el número de usuarios que lo han guardado como favorito, el número de visualizaciones o la puntuación que le dan a los usuarios. Una vez obtenida toda la información posible para puntuar los módulos debemos rea- lizar una calicación entre 0 y 1 en la que 1 supondrá gran importancia y 0 muy baja importancia. Un sistema simple para evaluar la similitud entre dos textos es el método SequenceMatcher de la biblioteca de Python diib, que establece un valor también entre 0 y 1 en función de la coincidencia entre dos cadenas de texto. A pesar de basarnos en distintos criterios, debemos intentar que los resultados homo- géneos con el resto de módulos para que no sean castigados o premiados los resultados simplemente por ser facilitados por un buscador. Si no tenemos criterios o provisional- mente no hemos desarrollado la puntuación, el módulo automáticamente heredará el método de puntuación contenido por la superclase que dará una puntuación mínima al recurso. Un ejemplo de puntuación puede ser el utilizado para el módulo de búsquedas en 15
    • 3. Desarrollo del proyecto propiamente dicho Youtube: se le asigna un valor entre 0 y 1 en función de la coincidencia de los términos de búsqueda introducidos con el título del vídeo y además un 0.2 más en función de la puntuación de los usuarios y un 0.2 más según el número de visualizaciones del vídeo. 3.3.4. Módulos desarrollados El proyecto cuenta con seis módulos desarrollados: cuatro de ellos para servicios de imágenes (Flickr, Picasa, GoogleImages y Wikicommons), otro para vídeos (Youtube) y otro para resultados de texto tradicionales (Yahoo Search). El módulo de resultados de texto nalmente nunca fue incorporado a la interfaz porque la intención es que la aplicación se centre en contenidos multimedia. Algunas empresas como Google ofrecen distintas formas de acceder a sus servicios, en el caso de esta compañía podemos acceder a información de sus servicios mediante bibliotecas libres en Python desarrollados por ellos mismos (conocidas como GData) o mediante JSON. En los módulos desarrollados se ha utilizado el primer método para acceder a los resultados de Youtube y Picasa y el segundo para acceder a los de Google Images. En ocasiones, el acceso a determinada información no está disponible o es complejo de obtener. En el caso de Flickr, para poder a la imagen del tamaño mayor posible se debía hacer una consulta para cada uno de los resultados obtenidos, lo cual es inviable por el coste de tiempo que supone. Por otra parte, Wikicommons únicamente facilita el nombre del recurso, lo que hace muy difícil su puntuación. 3.4. Visualización de los resultados Para la visualización de los resultados, como se ha indicado en la sección sobre las tec- nologías utilizadas, se emplea simplemente HTML y CSS. Combinando ambos, podemos mostrar en la ventana del navegador una imagen en las coordenadas deseadas empleado para ello distancias absolutas. Cuando se realiza la visualización, se marcan todos los resultados mostrados como usados y cuando el usuario decide avanzar de página, lo que realiza el código que se ejecuta en el cliente es descartar todos estos resultados y realizar una nueva visualización. Si el usuario decide volver atrás en los resultados, el buscador vuelve a considerar todos los resultados descartados la última vez que se avanzó la página. De esta forma de consigue una navegación muy rápida para el usuario, en la que el único retardo que se produce es el de estimar la posición en la que se van a disponer los resultados. Durante la visualización, el usuario puede visualizar los resultados a un tamaño mayor simplemente pulsando sobre éste. Para ello se ha utilizado el plugin de jQuery Ceebox, que permite mostrar un diálogo dentro de la página ajustado al tamaño de la ventana y la imagen o vídeo visualizado y que permite también navegar pasando los contenidos uno a uno. Esto resulta muy cómodo para los usuarios y para el buscador, ya que estos no tienen que abandonar la página para consultar los resultados. La principal ventaja de Ceebox con respecto al resto de bibliotecas que hacen el mismo trabajo es que permite hacer 16
    • 3. Desarrollo del proyecto propiamente dicho sin modicar los enlaces originales y puede trabajar con cualquier tipo de contenidos: imágenes, vídeos, otras páginas, etc. Para la visualización de resultados también se desarrollaron dos plantillas utilizando el sistema de plantillas de Django para que el buscador contase con una página de inicio y una página de búsqueda. Las páginas de búsqueda también cuentan con una dirección permanente del tipo http://www.dominio.com/search/terminosdebúsqueda. 3.5. Carga de los resultados Una de las especicaciones del proyecto es la rápida carga de los resultados para me- jorar la experiencia del usuario que visite el buscador. El algoritmo voraz planteado, que describiré posteriormente, consigue una disposición muy rápida de los resultados; pero éste necesita que previamente hayan cargado todas las imágenes para ser ejecutado, ya que necesita conocer el ancho y alto de cada una de ellas. Del planteamiento inicial que se hizo del proyecto, se tuvieron que analizar importantes problemas que hacían la carga de imágenes muy lenta: 1. Se comprobaba cada cada vez que se cambiaba de página si las imágenes habían cargado. 2. No se empezaban a descargar las imágenes hasta que los resultados de todos los buscadores no habían llegado. 3. Los resultados sólo se visualizaban cuando terminaban de cargar todas las imágenes. Para solucionar el tercero de los problemas, se implementó una forma de que los resul- tados se visualizasen cada vez que terminaban de cargar todos los resultados de uno de los buscadores. Pero esta solución seguía siendo insuciente, por lo que se cambió el comportamiento para que la actualización de las imágenes mostradas se realizase cada cierto tiempo, utilizando para ello un temporizador que en las pruebas fue jado cada 2 segundos. También se reestructuró todo el código para que no se volviesen a comprobar que todas las imágenes hubiesen cargado cada vez que se cambiaba de página y para que las imágenes empezasen a descargarse de los servidor en cuanto llega el resultado al cliente. Para esto me serví de que los resultados de cada uno de los buscadores se devuelven en peticiones HTTP distintas. Para gestionar la carga de las imágenes se utilizan tres métodos: 1. El evento onload de la imagen, que ocurre cuando la imagen carga correctamente. 2. El evento onerror de la imagen, que ocurre cuando la imagen carga incorrectamente. 3. La propiedad complete, que indica si el navegador ha cargado ya la imagen. 17
    • 3. Desarrollo del proyecto propiamente dicho 3.6. Determinar la posición de los resultados 3.6.1. Introducción Conociendo ya la experiencia con problemas similares descrita en la introducción sobre el estado del arte, es necesario elegir una alternativa para la disposición de resultados. El principal factor a tener en cuenta es la velocidad, ya que un tiempo de carga bajo es fundamental para una aplicación web y, durante la carga de las imágenes, se desea llamar repetidas veces al algoritmo, al tiempo que van llegando los resultados. En un principio, el planteamiento era utilizar un algoritmo genético[3], aunque se des- cartó debido a que para obtener unos buenos resultados es necesaria una gran diversidad y un número elevado de iteraciones. La alternativa elegida entonces para solucionar el problema del tiempo fue utilizar un algoritmo 'greedy' (voraz o goloso) y, si la cantidad de huecos es muy elevada, realizar una búsqueda local para mejorar el resultado. Para la representación de la disposición de las imágenes existen dos alternativas: alma- cenar las coordenadas en las que está situada la imagen o representar el espacio dispo- nible como una rejilla y almacenar en una matriz si cada posición está disponible o no. La segunda alternativa supone almacenar más información, sin embargo, es preferible a la primera debido a que si únicamente almacenamos las coordenadas es muy difícil comprobar los huecos para asignar las siguientes imágenes. En diciembre de 2009, James Padolsey (http://james.padolsey.com/javascript/ gapless-wall-of-images/) utiliza un algoritmo voraz para resolver un problema muy similar al que yo estaba estudiando: él trata de crear un muro a partir de imágenes, redi- mensionándolas a partir de un tamaño mínimo y máximo. Para ello utiliza un algoritmo voraz cuyas principales desventajas son: Que no se encuentra en absoluto documentado. Los tamaños máximos y mínimos no son para cada imagen. Las soluciones obtenidas en algunos casos se encontraban muy lejos de ser la óptima. Debido a que todas estas desventajas eran fácilmente evitables y a que el trabajo esta publicado mediante una licencia libre, se parte del trabajo realizado para aplicarlo al problema del proyecto. Para mejorar las soluciones obtenidas se plantea también aplicar la técnica del enfria- miento simulado[11] (también conocido como 'simulated annealing' o 'recocido simulado') como posteriormente se explica. La ventaja que presenta el enfriamiento simulado frente a la búsqueda local es que evita nalizar la ejecución en óptimos locales. 3.6.2. Algoritmo voraz utilizado Como se ha comentado, se parte del trabajo de James Padolsey, que se adapta Para que los tamaños vayan en función de la importancia del resultado, se toma la puntuación del resultado para establecer un tamaño máximo y un tamaño mínimo de la imagen. 18
    • 3. Desarrollo del proyecto propiamente dicho Utilización de dichos tamaños máximos y mínimos para cada imagen. Organización de los resultados antes de empezar a utilizarlos. Uso de las estructuras de datos necesarias. Impedir la reutilización de imágenes, ya que no tiene mucho sentido mostrar resul- tados por duplicado. Optimización del rendimiento. El algoritmo consiste en los siguientes pasos: Se ordenan los resultados según su importancia, para que primero sean considerados los más importantes. Se inicia el punto más alto a 0,0. De forma iterativa, hasta que no queden candidatos a punto más alto: ˆ Se toma el punto más alto y se elimina de la lista de candidatos a punto más alto. 1 ˆ Se toma el siguiente resultado.2 ˆ Se intenta colocar en la posición más alta, al máximo tamaño posible sin que exceda las dimensiones máximas.3 ˆ Si no se alcanzan las dimensiones mínimas jadas para el resultado, se descarta y se pasa al siguiente. ˆ Si no se descarta, se insertan en la lista de candidatos a punto más alto las esquinas inferiores de la imagen y la esquina superior derecha. Los resultados obtenidos son muy satisfactorios ya que la carga de resultados es muy rápida. Analizando el tiempo de ejecución de todo el código JavaScript se puede apreciar que la mayor parte del tiempo se invierte trabajando con la matriz que determina las posiciones ocupadas, por lo que quizás estos tiempos sean aún mejorables. En la gura 3.6.1 se puede apreciar el proceso de disposición de imágenes que se va siguiendo. 1 La lista se ordena de candidatos a punto más alto se ordena considerando más alto como el punto cuya posición el eje Y sea más bajo y, en caso de igualdad, aquel cuya posición en el eje X sea menor. 2 El siguiente resultado se toma de manera recursiva, de forma que puede que hayamos descartado resultados en un primer recorrido de la lista pero, si se recorre toda la lista entera, se vuelven a considerar los descartados. 3 Para conocer qué posiciones se encuentran libres y cuales ocupadas se utiliza una matriz en la cual cada posición representa cada uno de los píxeles del espacio disponible y el valor 1 signica que se encuentra ocupado por una imagen y el 0 que está libre. 19
    • 3. Desarrollo del proyecto propiamente dicho 3.6.3. Aplicación del enfriamiento simulado El enfriamiento simulado consiste en una búsqueda por entornos que, a diferencia de la búsqueda local, permite aceptar soluciones peores en función de una probabilidad que va disminuyendo con el tiempo. De esta forma, al principio se realiza una búsqueda con mayor diversicación y al nal se intensica la búsqueda, al ser más difícil que se acepte una solución peor. Para aplicar el enfriamiento simulado se adapta el código desarrollado por Jesús Gonzá- lez Peñalver que optimiza la disposición de un periódico online[4] y que se encuentra dis- ponible en http://atc.ugr.es/~jesus/layout/. La temperatura inicial, que determina la probabilidad para aceptar soluciones peores, es iniciada según sugiere Kirkpatrick[11] y el algoritmo recibe como parámetros el número de iteraciones a realizar y cada cuántas iteraciones se modicará la temperatura. Como el resultado del algoritmo voraz depende de el orden en que se consideran las imágenes, lo que se hace es aplicar la técnica del enfriamiento simulado sobre el orden de dichas imágenes de entrada, siendo inicialmente el orden de este de mayor a menor importancia. Aplicar el enfriamiento simulado sobre la salida del algoritmo voraz sería más complicado y no merecería la pena, ya que no sería muy difícil aplicar una mutación sobre el resultado que minimice el número de huecos dejados. El operador de mutación empleado consiste en intercambiar dos miembros distintos y seleccionados al azar de la lista. La función de evaluación o tness es el número de huecos que quedan tras aplicar el algoritmo voraz. 3.7. Comunicación Como ya indicamos, el cliente y el servidor utilizan JSON para la comunicación de los resultados, aunque sería fácilmente extensible el código para que también se permita la comunicación entre cliente y servidor mediante XML o cualquier otro método. Se ha decidido que todos los atributos que sean almacenados en la clase del lado del cliente se transera al lado del servidor, esto debe a que, aunque en determinado momento no utilicemos todos los atributos, puede ser interesante utilizar otro cliente para comunicarse con la interfaz que sí utilice estos datos. Además, toda la información contenida es pública y no tiene sentido que esté oculta. Para que un objeto de Python se convierta a notación JavaScript se ha utilizado la biblioteca jsonpickle (http://github.com/jsonpickle/jsonpickle), a la que simple- mente se le pasa el objeto y se obtiene el texto con el resultado. Del lado del cliente, al ser estar ya la respuesta del servidor en la misma notación que el código que la procesa, simplemente hay que evaluar el código recibido. 20
    • 3. Desarrollo del proyecto propiamente dicho 21 Figura 3.6.1.: Proceso de disposición de imágenes del algoritmo voraz
    • 3. Desarrollo del proyecto propiamente dicho Figura 3.6.2.: Ejemplo de disposición de resultados empleando el algoritmo voraz 22
    • 4. Evaluación y conclusiones 4.1. Evaluación de la disposición de imágenes Los tiempos de ejecución obtenidos mediante esta técnica no son demasiados bue- nos, para 10 iteraciones (un número muy bajo para el enfriamiento simulado) en un computador moderno tarda más de 10 segundos, lo que claramente es un rendimiento inaceptable. Analizando con un el 'proler' de la extensión Firebug para Mozilla Firebug se detectan los principales cuellos de botella: más del 50 % del tiempo es invertido en calcular el tness de la solución, por lo que utilizando como función de evaluación el número de espacios que quedan en la matriz no es factible aplicar el enfriamiento simu- lado. Podríamos utilizar otros como función de tness el número de imágenes utilizado, pero puede utilizándose muchas imágenes el desaprovechamiento de la pantalla sea muy grande. Analizando también la calidad de la solución obtenida, llegamos a la conclusión de que apenas existe diferencia entre aplicar el enfriamiento simulado unas pocas iteracio- nes y quedarnos con la primera solución de la que partíamos, como se puede observar comparando las guras 4.1.3 y 4.1.4. Para estimar cuántas iteraciones serían necesarias para obtener resultados que fuesen apreciables se hace una ejecución de 50 iteraciones en la que se enfría la temperatura cada 5 y los resultados son los observados en la imagen 4.1.2, comparando el espacio que queda ahora libre con el total disponible (gura 4.1.5) ahora sí se aprecia una importante mejora. Sin embargo, debido al tiempo que tarda cada una de las ejecuciones no es viable. La razón por la que es difícil conseguir mejoras con respecto al algoritmo greedy inicial puede ser debida a la ordenación de mayor a menor realizada al inicio de éste. Como ya estudió Daniel Selator[13], una buena técnica es empezar colocando las imágenes mayores para después intentar rellenar los huecos dejados por ellas con las imágenes más pequeñas. Es obvio que si en último lugar consideramos las imágenes más grandes nos va a ser más difícil conseguir una óptima distribución. Observando los resultados de muchas de las ejecuciones puede parecer que en ningún momento se opta por tomar soluciones peores que la actual y por lo tanto los parámetros del enfriamiento simulado deberían ser reajustados o utilizar simplemente una búsqueda local. sin embargo, como podemos apreciar en la gura 4.1.6 sí que se adoptan peores soluciones para evitar caer en óptimos locales. El mayor inconveniente es que una pequeña mutación da lugar a grandes cambios en la disposición, lo que hace que no haya ni pequeñas mejoras ni pequeños empeoramientos, sino siempre cambios bruscos en el valor del tness. 23
    • 4. Evaluación y conclusiones Figura 4.1.1.: Evolución del tness de la solución en 10 iteraciones 4.2. Conclusiones El proyecto ha logrado cumplir todos los objetivos básicos que se habían propuesto y respetando las especicaciones planteadas. Se han desarrollado buscadores para diferentes módulos que obtienen la información, la organizan y la puntúan según distintos clientes. Todo esto se realiza utilizando una estructura modular que permite una fácil extensibilidad de la aplicación, lo que ha permi- tido que terceras personas colaboren con el proyecto e implementen sus propios módulos para distintos buscadores y utilizando distintos sistema de comunicación con ellos, con- tando nalmente el proyecto con media docena de módulos. Esta estructura modular también permite que los errores en unos módulos no afecten al resto. Por otra parte, del lado del cliente se ha creado una agradable a la par que simple interfaz que muestra los resultados de una forma paginada y que da la sensación de rapidez al ir mostrando los resultados conforme son recibidos del servidor. Esto permite que la experiencia del usuario sea satisfactoria, además de que se le permite que no tenga que abandonar el buscador para consultar los resultados. El resultado ha sido probado en distintos navegadores modernos con satisfactorio re- sultado, gracias a que ha sido desarrollado empleando estándares y tecnologías abiertas. Además, independientemente del navegador utilizado, los resultados se ajustan al espacio dejado libre por la ventaja del navegador. En cuanto a los métodos de disposición de los resultados en la pantalla se han es- tudiando distintas alternativas, consiguiendo grandes resultados con el algoritmo voraz implementado en un tiempo muy reducido, que además permite representar los resultados más interesantes (mejor puntuados) a un tamaño mayor y en las primeras páginas. La aplicación del enfriamiento simulado no ha sido satisfactoria, pero su estudio ha permiti- do sacar interesantes conclusiones sobre la conveniencia de aplicar este tipo de búsqueda 24
    • 4. Evaluación y conclusiones Figura 4.1.2.: Evolución del tness de la solución en 50 iteraciones y sobre cómo aplicarla. Por último, la madurez del software desarrollado ha permitido que sea publicado e instalado para el acceso público en http://visuse.com. El desarrollo del proyec- to también ha supuesto una interesante contribución a la comunidad de software li- bre, que puede reutilizar este trabajo para cualquier otro n relacionado y que ha re- conocido dicha contribución. Todo el código del proyecto se encuentra disponible en https://forja.rediris.es/projects/cusl4-visuse/. 25
    • 4. Evaluación y conclusiones Figura 4.1.3.: Espacio ocupado y libre en la ventaja sin aplicar el enfriamiento simulado Figura 4.1.4.: Espacio ocupado y libre en la ventaja tras aplicar el enfriamiento simulado durante 10 iteraciones 26
    • 4. Evaluación y conclusiones Figura 4.1.5.: Espacio ocupado y libre en la ventaja tras aplicar el enfriamiento simulado durante 50 iteraciones Figura 4.1.6.: Otro ejemplo de 50 iteraciones en el que se 'escapa' de un óptimo local 27
    • A. Instrucciones de utilización En todas las plataformas o sistemas operativos que dispongan de un intérprete Python se puede utilizar Visuse y en el repositorio del proyecto se incluyen unas instrucciones de instalación. Las instrucciones básicas de instalación (incluyendo comandos para instalar en distri- buciones Linux basadas en Debian) son: 1. Instalar paquete de Django: sudo apt-get install python-django 2. Instalar mysqldb : sudo apt-get install python-mysqldb 3. Ejecutar desde la carpeta visuse ./manage.py runserver 4. Acceder con el navegador a http://127.0.0.1:8000/ y comprobar que las bús- quedas funcionan. Es posible que también se requiera de distintas bibliotecas para la comunicación con algunos buscadores que se indicarán en la siguiente subsección. 28
    • B. Dependencias de los módulos Las particularidades de cada uno de los módulos hacen necesaria la utilización de distintas bibliotecas que no siempre están incluidas en las bibliotecas estándar o junto con el código del módulo facilitado. Las dependencias de los módulos facilitados con el software son: 1. urllib: en distribuciones basadas en debian se encuentra en el paquete python- m2crypto 2. Gdata: en algunas distribuciones basadas en debian se encuentra en el paquete python-gdata y se puede encontrar en http://code.google.com/p/gdata-python-client/ 3. Simple-JSON: es necesario si se tienen versiones de Python anteriores a la 2.6 29
    • Bibliografía [1] FS Foundation. The GNU General Public License (GPL), pp. 1989. [2] J. Geigel and A. Loui. Automatic page layout using genetic algorithms for electronic albuming. Internet Imaging II, volume SPIE-4311, pages 7990, 2000. [3] D.E. Goldberg et al. Genetic algorithms in search, optimization, and machine lear- ning. Addison-wesley Reading Menlo Park, 1989. [4] J. González, J. Merelo, P. Castillo, V. Rivas, and G. Romero. Optimizing web news- paper layout using simulated annealing. Engineering Applications of Bio-Inspired Articial Neural Networks, pages 759768, 1999. [5] E.R. Harold and W.S. Means. XML in a Nutshell. O'Reilly Media, Inc., 2004. [6] G. Hattori, K. Hoashi, K. Matsumoto, and F. Sugaya. Robust web page segmen- tation for mobile terminal using content-distances and page layout information. In Proceedings of the 16th international conference on World Wide Web, page 370. ACM, 2007. [7] I. Hickson and D. Hyatt. HTML 5. The World Wide Web Consortium.(W3C Working Draft). Online: http://www.w3.org/TR/html5/, 25:2008, 2008. [8] A. Holovaty and J. Kaplan-Moss. The Denitive Guide to Django: Web Development Done Right. Springer, 2009. [9] C. Jacobs, W. Li, E. Schrier, D. Bargeron, and D. Salesin. Adaptive grid-based document layout. ACM Transactions on Graphics, 22(3):838847, 2003. [10] R. Johari, J. Marks, A. Partovi, and S. Shieber. Automatic yellow-pages pagination and layout. Journal of Heuristics, 2(4):321342, 1997. [11] S. Kirkpatrick, C.D. Gelatt Jr, and M.P. Vecchi. Optimization by simulated annea- ling. Science, 220(4598):671, 1983. [12] J. Plekhanova. Evaluating web development frameworks: Django, Ruby on Rails and CakePHP. Institute for Business and Information Technology, 2009. [13] D.D. Sleator. A 2.5 times optimal algorithm for packing in two dimensions. Infor- mation Processing Letters, 10(1):3740, 1980. 30