This PFG was made by Cristian Álvarez Belaustegui and directed by Jose Emilio Labra Gayo inside the WESO Research Group.
The lecture happened the July 23rd at the School of Computer Science (University of Oviedo).
The project consists in the creation of the backend for the new LandPortal, property of the International Fund for Agricultural Development (IFAD - ONU).
Backend de un portal de datos e información sobre la Tierra
1. Backend de un portal de datos e
información sobre la Tierra
Cristian Álvarez Belaustegui
Dirigido por José Emilio Labra Gallo
2. landportal
Proyecto “RFQ/2013/016/SC:
Rebuilding IFAD’s Land Portal”
Participantes:
Fondo Internacional para el Desarrollo
Agrícola (IFAD, ONU)
Land Portal Partnership
SBC4D Consulting
Grupo de Investigación WESO
3. landportal
Creado en marzo de 2011
1000 usuarios registrados
70 organizaciones
70000 visitantes únicos
10000 visitas mensuales
4. ¿Qué queremos?
Crear un portal de datos abiertos
enlazados
Utilizando datos de diversas fuentes
independientes
Aportando visualizaciones de los datos
Fomentando la participación de los usuarios
Incluyendo un sistema sencillo de búsqueda
Soportando internacionalización de los
contenidos
5. ¿Qué queremos?
“Mejorar la gestión de la tierra para beneficiar a los
más vulnerables y con menos derechos, a través del
intercambio de información y conocimientos”
Land Portal Strategy - Tim Davies
14. landdebate
• Utiliza las capacidades del CMS
• Gestión de usuarios
• Gestión de contenidos
• Gestión de comentarios
• Tipos de contenido y roles de usuario personalizados
• Aspecto visual totalmente personalizado
• Internacionalización de la interfaz gráfica
• Integración con la búsqueda
15. landdebate (modelo de datos)
Usuario
registrado
Administrador
Usuario con
acceso al API
Noticia
Evento
Debate Comentario
Entrada del
blog
Organización
18. landbook
• Punto de entrada de datos
• API interna para visualizaciones
• Framework MVC personalizado integrado en Drupal
• Internacionalización
• Interfaces
• Datos
• Integración con la búsqueda
19. landbook (punto de entrada de datos)
CKAN
Controller
Router
Services
CKAN Service
RDF Service
SQL Service
Parser
ORM
(SQLAlchemy) MySQL
Virtuoso
20. Plantillas e internacionalización
hook_menu Model
Languages
en.json
es.json
fr.json
labels data
template controller
Templates Mustache Javascript
HTML
22. Pruebas
Pruebas de integración
Desarrollo Dirigido por Pruebas
Integración continua
Pruebas de rendimiento
Pruebas de aceptación
23. Ampliaciones
Página de inicio segura
Automatización de los debates
Sistema de solicitud de acceso al API
Futuros proyectos con el IFAD
Land Library
Hackatón
24. Conclusiones
Conocimiento de nuevos lenguajes, frameworks y CMS
Evitar caer en la optimización prematura
Beneficios de un buen diseño y arquitectura
Trabajo en equipo
Trabajo con un cliente real
27. ¿Qué opina el cliente?
• “This is looking really good visually: and looks like a great foundation
for the renewed site.” – Tim Davies
• “Dear all - it's looking good!” – Sabine Pallas
• “Looks good!” – Christophe Guéret
• “Overall, very nice look and feel and good organization of the debates
section.” – Valeria Pesce
• “I wish to say your work is really appreciable, a high degree of quality
for a Drupal website. Congratulations!” – Alessandro Bonelli
• “It's an incredibly detailed set of information and excellent package of
tools.” – Neil Sorensen
28. Pruebas de usabilidad
Medir la capacidad del software para cumplir con su cometido.
1. Crear un escenario realista para realizar las pruebas
2. Observar a los usuarios interactuar con la aplicación
3. Analizar resultados y obtener conclusions
4. Mejorar donde sea necesario
Requiere tiempo, esfuerzo y dinero.
Decisión: mockups + pruebas de aceptación
Dar las gracias al tribunal y a los asistentes
Presentar el título del proyecto
Presentarme a mi y a Labra
CONTEXTUALIZAR
El TFG forma parte de un proyecto mayor llamado “Rebuilding IFAD’s Land Portal” en el que se pretende renovar el portal landportal.info
Participaron:
IFAD (agencia perteneciente a la ONU) como cliente y propietario del actual landportal.info. Tras la renovación del portal pasará a ser propiedad del Land Portal Partnership
SBC4D como director del proyecto
Grupo WESO (del que formamos parte) como desarrollador del proyecto
MÁS CONTEXTO
Dijimos que el proyecto pretende renovar “landportal.info”, vamos a dar algunas cifras:
“landportal.info” fue creado en marzo de 2011
En el año 2013 contaba con unos 1000 usuarios registrados
En el año 2012 tuvo 70.000 visitantes únicos y unas 10.000 visitas mensuales
70 organizaciones
OBJETIVOS
Ya hemos hablado sobre el antiguo “landportal.info”, pero ¿qué queremos conseguir con su renovación?
Construir un portal de LOD:
Colaborando con múltiples fuentes de datos independientes (las veremos posteriormente)
Aportando visualizaciones (no sólo datos brutos) para facilitar su interpretación
Fomentando la participación y el intercambio de ideas entre los usuarios
Incluyendo una búsqueda unificada que facilite encontrar información
Soportando internacionalización para democratizar el acceso a la información
OBJETIVOS
Como dijo Tim Davies (coordinador del grupo de investigación de datos abiertos en la Web Foundation) en “Land Portal Strategy”…
ESTADO DEL ARTE
¿Es Land Portal único o existe algo similar?
Algunos portales sólo proporcionan datos en bruto, lo que requiere un tratamiento previo para poder interpretarlos. Tampoco permiten participar a los usuarios.
Enseñar “data.gov” y pasar a la siguiente
… seguimos de la anterior
Enseñar “data.gov.uk” y pasar a la siguiente
… seguimos de la anterior.
Otros proporcionan visualizaciones que facilitan la interpretación de datos, pero no permiten participar a los usuarios ni cuentan con un API para desarrolladores.
Enseñar “landmatrix.org” y pasar a la siguiente
… seguimos de la anterior
Una tercera variante son portales que permiten la participación de los usuarios pero no cuentan con las capacidades de un portal de datos.
Enseñar “antiguo landportal.info” y pasar a la siguiente
COMO FUNCIONA
Como hemos visto anteriormente, los objetivos del nuevo Land Portal son ambiciosos. ¿Cómo los consigue? DISEÑO MODULAR CON DIVISION DE RESPONSABILIDADES
En primer lugar los datos que se utilizan provienen de diferentes fuentes de datos independientes (OMS, BANCO MUNDIAL, FONDO INTERNACIONAL DESARROLLO AGRICOLA, etc). Para introducir los datos en el portal hemos creado un Punto de Entrada (receiver / Alfred) para poder controlar cómo se incluyen los nuevos datos (programado en PYTHON)
PROBLEMA: las diferentes fuentes de datos tienen formatos diferentes: json, xml, csv, Excel, apis, etc.
SOLUCIÓN: como decía David Wheeler (universidad de Cambridge) “Todos los problemas en computación pueden resolverse añadiendo un nivel de indirección”. Hemos creado los importadores que transforman los formatos de cada fuente de datos a un formato único antes de enviarlos al punto de entrada de datos
El receiver está diseñado para soportar distintos servicios de exportación de datos (RDF, SQL, CKAN con api)
Apache redirige a los usuarios hacia los diferentes componentes de forma transparente
Los datos enlazados se pueden visualizar con WESBY (además de con un SPARQL endpoint), un producto creado por WESO originalmente como parte del proyecto WebIndex 2013 en el que yo forme parte de sus últimas fases de desarrollo. Está escrito en SCALA
Las visualizaciones de datos se ofrecen con WESCOUNTRY
Una API para desarrolladores
Un gestor de contenidos (DRUPAL) que actúa como principal punto de acceso a los usuarios, está escrito en PHP.
El gestor de contenidos se comunica con APACHE SOLR para proporcionar un sistema de búsqueda unificado
COMO FUNCIONA
Como hemos visto anteriormente, los objetivos del nuevo Land Portal son ambiciosos. ¿Cómo los consigue? DISEÑO MODULAR CON DIVISION DE RESPONSABILIDADES
En primer lugar los datos que se utilizan provienen de diferentes fuentes de datos independientes (OMS, BANCO MUNDIAL, FONDO INTERNACIONAL DESARROLLO AGRICOLA, etc). Para introducir los datos en el portal hemos creado un Punto de Entrada (receiver / Alfred) para poder controlar cómo se incluyen los nuevos datos (programado en PYTHON)
PROBLEMA: las diferentes fuentes de datos tienen formatos diferentes: json, xml, csv, Excel, apis, etc.
SOLUCIÓN: como decía David Wheeler (universidad de Cambridge) “Todos los problemas en computación pueden resolverse añadiendo un nivel de indirección”. Hemos creado los importadores que transforman los formatos de cada fuente de datos a un formato único antes de enviarlos al punto de entrada de datos
El receiver está diseñado para soportar distintos servicios de exportación de datos (RDF, SQL, CKAN con api)
Apache redirige a los usuarios hacia los diferentes componentes de forma transparente
Los datos enlazados se pueden visualizar con WESBY (además de con un SPARQL endpoint), un producto creado por WESO originalmente como parte del proyecto WebIndex 2013 en el que yo forme parte de sus últimas fases de desarrollo. Está escrito en SCALA
Las visualizaciones de datos se ofrecen con WESCOUNTRY
Una API para desarrolladores
Un gestor de contenidos (DRUPAL) que actúa como principal punto de acceso a los usuarios, está escrito en PHP.
El gestor de contenidos se comunica con APACHE SOLR para proporcionar un sistema de búsqueda unificado
TECNOLOGÍAS
El número de componentes que forman parte del nuevo Land Portal es grande, también lo es el número de tecnologías utilizadas:
PHP -> módulos del CMS y API interna para las visualizaciones
Drupal -> Gestor de contenidos
Python -> lenguaje para le punto de entrada de datos
Flask -> microframework de desarrollo web para el punto de entrada de datos
MySQL -> como base de datos relacional desde la que se ofrecen los datos al usuario
HTML + CSS + BOOTSTRAP-> para la interfaz de usuario
ZONA SOCIAL
Como se ha mencionado anteriormente el nuevo Land Portal tendrá dos orientaciones principales: por un lado será un portal de LOD y por otro una plataforma social en la que los usuarios intercambien información y opiniones.
Hablaremos primero de ésta zona social, que recibe el nombre de “landdebate”
El “landdebate” utiliza las capacidades de Drupal la realizar la gestión de usuarios, contenidos y comentarios.
Los tipos de contenido, así como el aspecto visual de ésta sección han sido totalmente personalizados. Cabe destacar que la interfaz gráfica está internacionalizada en tres idiomas y puede ser extendida con tantos idiomas como se deseen.
Todos los contenidos de esta sección se integran con el sistema de búsqueda para facilitar su descubrimiento.
Aquí podemos ver el diagrama con el modelo de datos del “landdebate”:
Tenemos tres roles de usuario además de los usuarios anónimos:
Anónimos -> consumidores de información, sólo pueden ver los contenidos creados
Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates
Acceso al API -> además de consumidores y creadores también son difusores de información
Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog
Ahora haremos una demostración del “landdebate”. Entraré en la web del Land Portal real, si tienen sus tablets, smartphones o ordenadores portátiles les invito a acceder también a ustedes y navegar por el portal.
Podrán acceder en la dirección “landportal.weso.es”
Tras haber visto la zona social, hablaremos ahora de la zona de datos, que recibe el nombre de “landbook”
El “landbook” está formado por:
El punto de entrada de datos
Una API interna que proporciona los datos necesarios para la generación visualizaciones
Al igual que sucedió con el “landdebate” el “landbook” también está integrado en Drupal. Puesto que Drupal usa el patrón arquitectónico PAC, para integrar las vistas de ésta sección hemos creado un pequeño framework que nos permite trabajar de una forma similar al patrón MVC.
El “landbook” también soporta internacionalización. La internacionalización está soportada tanto a nivel de interfaces como a nivel de datos
Por último, el “landbook” también está integrado con la búsqueda unificada
Las peticiones llegan al controlador, quien va llamando a los diferentes servicios
Los servicios utilizan el modelo de datos común para exportarlo
El parser transforma los datos que llegan en la petición al modelo de datos común. Para ello utiliza un XML Schema definido
El servicio de SQL utiliza un ORM (“sqlalchemy”) para la persistencia
El servicio de RDF envía los datos a Virtuoso
El servicio de CKAN utilza el API de CKAN para enviar los conjuntos de datos junto con mentainformación sobre su contenido
¿CÓMO FUNCIONA EL MECANISMO DE SELECCIÓN DE PLANTILLAS E INTERNACIONALIZACIÓN?
El ‘hook_menú’ es automáticamente invocado por Drupal cuando un usuario accede a una de las rutas asociadas. Las rutas se especifican en un fichero JSON de configuración.
Selecciona el idioma escogido por el usuario y devuelve sus etiquetas traducidas.
Busca el modelo por convenio de nombres. La clase del modelo se instancia utilizando reflectividad y posteriormente se llama a su método ‘get’ para que nos devuelva los datos con los que se rellenará la vista. El modelo realiza consultas a la base de datos y las cachea para futuras peticiones.
Mustache localiza la plantilla adecuada y la renderiza con las etiquetas traducidas y los datos del modelo. En caso de que exista un fichero Javascript, se utilizará como controlador de la vista.
Todo este sistema utiliza un mecanismo de “convención sobre configuración” para buscar idiomas, plantillas, modelos y Javascript. Los idiomas se puden añadir directamente al directorio adecuado y están automáticamente disponibles en el portal. Al igual que los modelos, las vistas y los Javascript se buscan por convenio de nombres dependiendo de la ruta a la que acceda el usuario.
A continuación veremos una demostración del “landbook”, cabe recordar que las vistas de esta parte no han sido desarrolladas como parte del TFG, pero utilizan el framework MVC explicado anteriormente, las visualizaciones utilizan el API interno.
Al igual que antes, les invito a que entren con sus dispositivos.
Pruebas de integración durante todo el desarrollo y apoyadas por un servidor de integración continua (Travis CI)
Pruebas de rendimiento usando profiling cuando se acabó el punto de entrada de datos
Pruebas de aceptación con el sistema probado por el cliente durante una semana y media (originalmente una semana)
Las pruebas pueden verse detalladas en el capítulo 7 de la documentación.
Mencionar que el Hackatón iba a tener lugar en el Open Knowledge Festival 2014 (Berlín) pero se celebró entre el 15 y el 17 de julio y el proyecto aún no había terminado.
Opiniones extraídas de https://basecamp.com/2037036/projects/4324721/topics
Opiniones extraídas de https://basecamp.com/2037036/projects/4324721/topics
Opiniones extraídas de https://basecamp.com/2037036/projects/4324721/topics
Las peticiones llegan al controlador, quien va llamando a los diferentes servicios
Los servicios utilizan el modelo de datos común para exportarlo
El parser transforma los datos que llegan en la petición al modelo de datos común. Para ello utiliza un XML Schema definido
El servicio de SQL utiliza un ORM (“sqlalchemy”) para la persistencia
El servicio de RDF envía los datos a Virtuoso
El servicio de CKAN utilza el API de CKAN para enviar los conjuntos de datos junto con mentainformación sobre su contenido
Cuenta con un fichero en el que se declaran las rutas
El modelo de cada ruta devuelve los datos necesarios para rellenar la vista
Los datos se cachean en la primera petición
Los modelos se buscan por convenio de nombres y usando reflectividad
“mustache” nos permitió rellenar las plantillas con los datos devueltos por el modelo
Si el modelo no se encuentra se carga la vista de error 404
Aquí podemos ver el diagrama con el modelo de datos del “landdebate”:
Tenemos tres roles de usuario además de los usuarios anónimos:
Anónimos -> consumidores de información, sólo pueden ver los contenidos creados
Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates
Acceso al API -> además de consumidores y creadores también son difusores de información
Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog
Aquí podemos ver el diagrama con el modelo de datos del “landdebate”:
Tenemos tres roles de usuario además de los usuarios anónimos:
Anónimos -> consumidores de información, sólo pueden ver los contenidos creados
Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates
Acceso al API -> además de consumidores y creadores también son difusores de información
Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog
Aquí podemos ver el diagrama con el modelo de datos del “landdebate”:
Tenemos tres roles de usuario además de los usuarios anónimos:
Anónimos -> consumidores de información, sólo pueden ver los contenidos creados
Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates
Acceso al API -> además de consumidores y creadores también son difusores de información
Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog
Aquí podemos ver el diagrama con el modelo de datos del “landdebate”:
Tenemos tres roles de usuario además de los usuarios anónimos:
Anónimos -> consumidores de información, sólo pueden ver los contenidos creados
Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates
Acceso al API -> además de consumidores y creadores también son difusores de información
Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog