Memoria Proyecto Fin de Carrera

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


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


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


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


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


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


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


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


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


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


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


21

Figura 3.6.1.: Proceso de disposición de imágenes del algoritmo voraz


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


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


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


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


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

Memoria Proyecto Fin de Carrera

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (15)

Similar to Memoria Proyecto Fin de Carrera

Similar to Memoria Proyecto Fin de Carrera (20)

More from Jose Luis Lopez Pino

More from Jose Luis Lopez Pino (20)

Recently uploaded

Recently uploaded (17)

Memoria Proyecto Fin de Carrera