¿Por qué WordPress es un buen ejemplo de cómo el software libre y el open source nos ayudan a ser creativos y eficaces en los procesos de implementación tecnológica? 

De acuerdo con el propósito del proyecto Exhibitium se nos planteaba como necesaria la creación de un mecanismo que automatizara, en la medida de lo posible, la captura de información sobre exposiciones temporales de temática artística a partir de cualquier fuente de datos presente en Internet. El aplicativo debería cumplir, por supuesto, con las normas y principios fundamentales de ingeniería de software, ateniéndose a las regulaciones y estándares establecidos, implementando los adecuados protocolos de seguridad, utilidad, funcionalidad y usabilidad.

En realidad, el conjunto completo del proyecto Exhibitium incluye dos grandes bloques de trabajo, que determinan, en gran medida, el ritmo y el formato de su despliegue.

• Por una parte, la construcción de un «motor» que posibilita la extracción y el almacenamiento de la información sobre exposiciones artísticas temporales (EAT, en adelante).
• Por otra, un sistema que exporta los datos capturados y estructurados para su explotación por parte de plataformas diseñadas para el análisis de grandes volúmenes de datos mediante técnicas de descubrimiento de relaciones y patronaje de estructuras reticulares (cowording, trazado de redes, etc.).
• Además, hay que contar con el equipo humano (un grupo seleccionado de historiadores del arte involucrados en el paradigma digital) que realiza las labores de supervisión, filtrado, grabación, descripción, documentación y revisión.

Asimismo, había que distinguir, como parte del planteamiento, dos grandes bloques de tareas en el desarrollo.

1. El formado por un sistema de captura de información lo más automatizado posible, que garantizase razonablemente la fiabilidad de los datos recogidos.
2. Y el compuesto por todo el conjunto de elementos necesarios para almacenar los datos capturados tras la pertinente revisión de los editores, y exportar los resultados a la(s) plataforma(s) que se desplegarán en la segunda fase del proyecto.

El bloque A se denominó casi desde el comienzo Beagle, en honor al buque con el que Charles Darwin recorrió medio mundo y por su connotación cuasi humorística de «experto en búsquedas». Y, en un alarde de pragmatismo nominalista, el bloque B pasó a ser conocido como ExpoFinder. Ambos bloques trabajan de forma coordinada, de manera que lo que A extrae queda a disposición de B. El conjunto de ambos bloques se ejecuta formando parte de un sistema unificado, «sabiendo el uno lo que hace el otro», de manera que las funcionalidades de los dos son complementarias y la mencionada coordinación no es buscada, sino innata. El proceso completo se configura, como queda patente, mediante un algoritmo cíclico: Beagle captura, ExpoFinder analiza y da el visto bueno, Beagle vuelve a capturar[1].

 

Figura 1. Beagle + ExpoFinder. Plan de funcionamiento (simplificado)

Beagle captura -ya se ha dicho- de forma automatizada datos de la web relativos a exposiciones artísticas temporales procedente de cualquier fuente de información, e incluye un mecanismo de filtrado.

La idea primaria sobre el funcionamiento de Beagle es la de un procedimiento que se ejecuta de forma regular cada cierto tiempo y que selecciona las referencias de las URIs[2] que hayan sido dadas de alta como fuentes primarias de información en ExpoFinder, conecta con los enlaces correspondientes, extrae la información significativa tras un proceso de filtro preliminar (en el que se eliminan las partes no significativas del texto recuperado), valora mediante el uso de una tabla de lexemas que contienen raíces de palabras «positivas» y «negativas» (es decir, que, en caso de estar presentes, refuerzan la posibilidad de que un texto corresponda a una exposición temporal o no) la pertinencia de la información localizada y almacena un registro preliminar en formato «borrador» para que, a continuación, los operadores «humanos» del sistema validen o no los datos recogidos y complementen la metainformación necesaria.

 

Figura 2.

Preferiblemente, Beagle debería poder «aprender» de lo que fuese capturando, de manera que, en función de lo que los inspectores humanos de ExpoFinder decidieran sobre cada elemento recogido, Beagle pudiese acumular experiencia para, ante una información nueva, afinar más el proceso de selección.

Beagle utiliza dos artificios complementarios para «predecir» el grado de adaptación de cada noticia «capturada» a las precondiciones de ExpoFinder[3], ambos de carácter estadístico: un recurso basado en la intersección de un conjunto de palabras clave «positivas» y «negativas», con un peso proporcional asignado, basado a su vez en el algoritmo de ruta más corta de Bellman-Ford[4], y otro de carácter heurístico, que emplea un clasificador bayesiano ingenuo[5] para orientar al inspector durante su tarea de discriminar si una noticia es o no válida. Este último es capaz de mejorar su rendimiento mediante el aprendizaje continuo (cada rechazo o aceptación afinan la «percepción» del sistema).

En las primeras fases, tras unas versiones preliminares basadas en desarrollos propios, no estaba muy claro si se debía optar por el uso de un framework determinado de los muchos que hay disponibles actualmente que cumpliera, entre otros requisitos, el de ser software libre y open source (la filosofía openess es condición sine qua non de este proyecto) o bien probar «algo nuevo», al menos relativamente. Pero pronto una opción pareció la más interesante.

WordPress o WP es un conocidísimo gestor de contenidos (CMS, por sus siglas inglesas) que está excelentemente diseñado. Aunque, en realidad, y de acuerdo con lo expresado por Tom McFarlin en su conocida página “tuts+”, WP es más una foundation (cimiento) que un framework. Y tal vez no ande escaso de razón: un framework consiste en un conjunto de convenciones -como dónde deben guardarse los archivos- así como de bibliotecas y herramientas -pongamos por caso, una capa de abstracción de base de datos- que nos permiten fácilmente comenzar a trabajar en una aplicación. En resumen, proporciona los medios por los cuales una aplicación puede ser construida partiendo de cero, a partir del esquema de base de datos hasta su front-end. Sin embargo, una foundation permite «extender» una aplicación ya existente. WP tiene sus propios mecanismos internos bien definidos, y la foundation simplemente amplía su funcionamiento o lo aprovecha en su propio beneficio. Y eso es lo que terminamos haciendo con WP: aprovechamos la base de datos predefinida, las APIs disponibles y el sistema de plantillas para la visualización de datos con los que construir soluciones usando una aplicación que ya está plenamente funcional. De este modo, para la implementación de Beagle-Expofinder, aprovechamos la base de datos predefinida, las APIs disponibles y el sistema de plantillas para la visualización de datos para construir soluciones usando una aplicación que ya está plenamente funcional.

De hecho, jugando con esta estructura ya se han realizado al menos dos proyectos de envergadura para transformarlo en un modelo lo más universal posible que permita realizar desarrollos sobre él: WP MVC de Tom Benner[6], y Themosis[7], de la agencia creativa belga homónima. En nuestro caso, ambos proyectos, que basan su funcionamiento en implementar un mecanismo MVC (Model, View, Controller), hacían excesivamente complejo el desarrollo y obligaban a «forzar la máquina», teniendo que realizar adaptaciones y modificaciones en el núcleo principal (core) de WP, lo que suponía renunciar a algunas de sus ventajas, que a continuación enumeramos, primero a grandes rasgos y luego más en detalle.

• Una base de datos con un esquema organizativo flexible y muy sólido.
• Una capa de aplicación principal con numerosos hooks[8] que permiten aprovechar al máximo su funcionalidad.
• La facilidad para gestionar tareas en las caras de servidor y cliente, y asumiendo roles de administrador o usuario.

Diseccionando estas virtudes, podemos fijarnos de modo especial en las siguientes particularidades.

1. Gestión de usuarios. La seguridad no es, en el caso de aplicaciones abiertas a su uso en Internet, un problema menor. WP tiene un módulo de gestión de usuarios excelente, que se encarga de toda la funcionalidad, tal como el registro de usuarios y de inicio de sesión, gestión de roles, asignación de capacidades a diferentes roles y la creación de nuevas soluciones.
2. Pantallas de administración. ¿Quién no desea disponer de facilidades para poder gestionar la administración de un aplicativo? WP ofrece todo un interfaz, que permite crear páginas propias de configuración personalizada para poder hacer frente a una amplia serie de requisitos.
3. Funcionamiento CRUD (Create, Read, Update, Delete). Ni que decir tiene el enorme ahorro de «energía programadora» y de tiempo contar con un contratadísimo mecanismo que controla absolutamente todo el proceso de dar de alta, de baja, modificar o leer cualquier registro o conjunto de registros almacenados.
4. Completísimo juego de funciones internas perfectamente aprovechables. Incluyen desde la gestión de la internacionalización (mediante mecanismos gettex[9]t) a través de un avanzado control i18n hasta la «desinfección» preventiva de textos, bloqueando de esa forma posibles ataques de tipo SQL injection[10] y variantes.
5. Administración de medios. WP se ocupa de la carga de archivos y la gestión de los medios audiovisuales, incluyendo su securización.
6. Extensibilidad y escalabilidad. Desde el punto de vista de un desarrollador, extensibilidad y escalabilidad constituyen las dos piedras de toque esenciales para adoptar una decisión sobre la infraestructura o el paradigma a emplear. Todos sabemos que lo que empieza como un pequeño proyecto acaba ampliándose ad infinitum. Su mecanismo API interno, basado en hooks, filtros, preprocesadores y callbacks[11], permiten intervenir en prácticamente cualquier operación que WordPress tenga predefinida.
7. Enrutamiento de URIs y URLs «SEO friendly». Son características de gran importancia a la hora de optar por una modelización u otra. La trascendencia de enrutar adecuadamente las llamadas a las distintas estructuras de la aplicación es innegable. Por otra parte, la estructura de la URL mediante la cual se identifica un contenido juega un papel muy importante en el mecanismo SEO (Search Engine Optimization), decisivo a la hora de que un proyecto cumpla con las condiciones de la web semántica, y WordPress implementa magníficamente ambas facilidades.
8. Caching. Si se está buscando una aplicación de alto rendimiento que pueda servir muchas peticiones simultáneas y manejar decenas de miles de usuarios, es necesario disponer de un mecanismo de almacenamiento en caché eficiente pero que no sacrifique la precisión en aras de las prestaciones. WP y su API de transients[12] proporcionan funcionalidad de almacenamiento en caché a nivel de la base de datos que se utilizará en la aplicación.
9. Plantillas. La presentación o front-end no es un mero adorno. Mediante una peculiar arquitectura MVC, WP dispone de una potentísima mecánica de formateo final de páginas.

Los inconvenientes más destacados pasan por una cierta rigidez estructural si se desea aprovechar la magnífica configuración de los custom post, los metadatos y las taxonomías, jerárquicas o no, que en ocasiones dificulta bastante la posibilidad, por ejemplo, de establecer vocabularios controlados o tesauros. No obstante, tales obstáculos pueden ser considerados menores en comparación con las capacidades de que WP hace gala.

ExpoFinder incluye: a) un mecanismo de control de calidad, identificando las equivocaciones y fallos, y asociándolas con el usuario inspector que las haya producido, a quien le es suministrada una lista de los errores para que pueda realizar las oportunas tareas de corrección; b) una página de mantenimiento, con operaciones internas de «limpieza» y normalización de datos; c) y un sistema de seguimiento y trazabilidad del trabajo realizado por cada operador (que, entre otras cosas, facilita el control del horario de trabajo a los administradores y gestores).

Para concluir, en el momento de escribir este texto, y tras diez meses de funcionamiento en su «encarnación actual», ExpoFinder se encuentra en un grado de finalización del 48,1{d2c84eb7dce5b0a9234ba34539095d636f8dec509fc5ac025aa7d2109304a384}, un 5{d2c84eb7dce5b0a9234ba34539095d636f8dec509fc5ac025aa7d2109304a384} por encima de lo inicialmente planeado para la fecha, con alrededor de 27.600 elementos de información almacena-dos. Si todo continúa al ritmo mantenido hasta ahora, Exhibitium podría alcanzar los objetivos numéricos previstos con tres meses de antelación a la fecha inicialmente planificada.

[1] El inicial análisis de requisitos quedó encomendado a Nuria Rodríguez y María Luisa Bellido, que evaluaron las necesidades de elementos singulares de información. No citaremos ahora en este texto, dada su extensión, la estructura interna de datos y sus relaciones, las taxonomías o niveles de agrupamiento y los vocabularios controlados que se propusieron desde el primer momento utilizar en cada taxonomía –que serán objeto de posts subsiguientes-, si bien sirva como adelanto que todos van referidos a los tesauros desarrollados por el Getty Research Institute y ofrecidos en Internet con condiciones y formatos de tipo Linked Open Data.

[2] Acrónimo de la expresión inglesa Uniform Resource Identifier. Es una cadena de texto que identifica de forma unívoca a cualquier recurso disponible en una red determinada (incluyendo Internet).

[3] Aunque no es este documento lo suficientemente extenso como para exponer en detalle la lista de precondiciones de selec-ción de términos significativos que Beagle emplea para filtrar la información que localiza, sí aclararemos que se trata de una relación «valorada» de lexemas en los idiomas correspondientes a cada fuente localizada, en la que a cada raíz de término se le asigna un «peso» total en el conjunto (entre 1 y 3). Al final se pondera la cifra absoluta de la suma de valores correspondien-te a los términos encontrados con la cifra relativa (referente a la extensión del texto sobre el que se busca) para asignar una evaluación positiva o negativa al conjunto de la información.

[4] El algoritmo Bellman-Ford (o de Bellman-Ford-Moore) calcula las rutas más cortas a partir de un solo vértice fuente a todos los otros vértices en un dígrafo ponderado. Es más lento que el algoritmo de Dijkstra para el mismo problema, pero más versátil, ya que es capaz de trabajar con grafos en los que algunos de los pesos de las aristas son números negativos. De él en ExpoFinder aprovechamos su mecanismo de ponderación, útil para nosotros por cuanto trabajamos con listas de lexemas para palabras que se emplean como marcadores «positivos» o «negativos».

[5] En terminología de aprendizaje automático, los «bayesianos ingenuos» constituyen una familia de clasificadores probabilísticos simples que se fundamentan en la aplicación de teorema de Bayes basado en la hipótesis de independencia entre variables. Ampliamente estudiado desde la década de 1950, se comenzó a emplear como método taxonomizador capaz de autoop-timizarse desde comienzos de la década siguiente en la comunidad de recuperación de texto. Nosotros utilizamos la frecuen-cia de aparición de un determinado lexema como disparador, de forma que ExpoFinder puede contribuir a la selección semiau-tomatizada de información relevante a partir de la experiencia acumulada al respecto. No es un mecanismo discrimitativo puro, sino una herramienta auxiliar que ha demostrado ser de gran utilidad para los operadores de la aplicación.

[6] http://wpmvc.org/ y https://github.com/tombenner/wp-mvc.

[7] http://framework.themosis.com/.

[8] En la programación de computadoras, el término «hook» abarca una serie de técnicas que se utilizan para alterar o aumentar el comportamiento de un sistema operativo, de las aplicaciones, o de otros componentes de software mediante la interceptación de llamadas a funciones, mensajes o eventos intercambiados entre componentes de software. El código que se encarga de este tipo de función interceptado llamadas, eventos o mensajes se denomina «gancho» o «hook».

[9] En informática, gettext es un sistema de internacionalización y localización (i18n) comúnmente utilizado para escribir programas multilingües en sistemas operativos tipo Unix. La aplicación más común de gettext es gettext GNU, publicado por el Proyecto GNU en 1995.

[10] La «inyección SQL» es una técnica de inserción de código que se utiliza para atacar aplicaciones basadas en datos, en el que las sentencias SQL maliciosos se insertan en un campo de entrada durante la ejecución de la aplicación (por ejemplo, para volcar el contenido de bases de datos para el atacante).

[11] En programación de ordenadores, una «devolución de llamada» o callback es una pieza de código ejecutable que se pasa como argumento a otro código, que se espera para volver a llamar (ejecutar) el argumento en algún momento conveniente. La invocación puede ser inmediata como en una devolución de llamada síncrona, o puede ocurrir más tarde, como en el caso del mismo mecanismo pero asíncrono.

[12] El API de WordPress para transients (‘transitorios’) ofrece una manera simple y estandarizada de almacenamiento de datos en caché en la base de datos con carácter temporal, asignándole un nombre personalizado y un plazo de tiempo una vez transcurrido el cual caducará y será eliminado.