composición de sistemas con mashups. el caso physicaltrello · ejemplo diferentes sistemas...
TRANSCRIPT
Composición de sistemas con Mashups.
El caso PhysicalTrello
Tesis Que para obtener el grado de
Maestro en Ingeniería de Software
Presenta
Iván Eliseo Tinajero Díaz
Director de la Tesis
Alejandro García Fernández
Zacatecas, Zacatecas., 03 de febrero de 2016
AGRADECIMIENTOS
Al Consejo Zacatecano de Ciencia y Tecnología (COZCyT) y al Centro de Investigación
en Matemáticas A. C., Unidad Zacatecas (CIMAT), por haber financiado la realización
de mis estudios a lo largo de la maestría en Ingeniería de Software.
A mis asesores Alejandro García Fernández y José Guadalupe Hernández Reveles,
por su ayuda, tiempo y dedicación proporcionados para la realización de este proyecto.
A la Secretaría de Administración, en especial a Fernando de la Cruz Albino, Gilberto
Sánchez Esparza y Uriel Pérez Armas, por darme la oportunidad de asistir a mis clases
y asesorías durante estos dos años que duró la maestría.
A mi familia, en especial a mi padre J. Isabel Tinajero Márquez y mi madre Victoria
Díaz Acosta por todo el apoyo que me han ofrecido para mi formación personal y
profesional, además de que siempre han sido para mí un ejemplo a seguir.
Resumen
El desarrollo de aplicaciones basado en componentes web, por ejemplo interfaces de
programación de aplicaciones Web (Web APIs) ha tomado una gran relevancia en los
últimos años debido a que se pueden mejorar aplicaciones ya existentes o crear
nuevas aplicaciones con la reutilización e integración de dichos componentes. Estas
aplicaciones son conocidas como Mashups.
Como ejemplo, se presenta el caso del Mashup PhysicalTrello, el cual integra dos
componentes web (API de Trello y API de Mailgun). PhysicalTrello es una aplicación
web basada en Trello, la cual permite sincronizar tableros Kanban virtuales con su
respetivo tablero Kanban físico utilizando códigos QR.
Por lo tanto, en esta tesis se presentan los distintos tipos de mashup que existen,
haciendo énfasis en los retos encontrados al desarrollar un tipo de mashup híbrido
(PhysicalTrello), que combinando componentes de datos y lógica, dio pié a uno de los
principales resultados de investigación de este trabajo, la propuesta de un nuevo tipo
de mashup que ha sido denominado como “Inyección de Interfaz de Usuario” (User
Interface Injection, en inglés).
PALABRAS CLAVE
Mashup, API, Json, REST, DOM, Web Scraping, Trello, Componentes de un Mashup,
MailGun, JimFlowKlopfer, Códigos QR, Kanban, Scrum, Mashups Híbridos, Mashups
de Datos, Mashups de Lógica, Mashups de Interfaz de Usuario.
INDICE GENERAL
1. Introducción ............................................................................................................ 1
1.1 Motivación ......................................................................................................... 2
1.2 Objetivos ........................................................................................................... 2
2. Antecedentes ......................................................................................................... 3
2.1 Sistemas Distribuidos ....................................................................................... 3
2.2 Web Data Extraction (Web Scraping) ............................................................... 5
2.3 Definición de Mashup........................................................................................ 6
2.4 Tipos de Mashups ............................................................................................. 8
2.5 Características de los Componentes de un Mashup ....................................... 12
2.6 La importancia de Kanban en este proyecto ................................................... 18
3. PhysicalTrello ....................................................................................................... 21
3.1 Arquitectura de PhysicalTrello ........................................................................ 22
3.2 Componentes de PhysicalTrello. .................................................................... 26
3.2.1 Trello ......................................................................................................... 26
3.2.2 JimFlowKlopfer ......................................................................................... 28
3.2.3 PhysicalTrello ........................................................................................... 28
3.2.4 Extensión PhysicalTrello ........................................................................... 29
3.2.5 Tarea Programada (Cron) ......................................................................... 30
3.2.6 Aplicación Android .................................................................................... 30
3.2.7 Base de Datos PhysicalTrello ................................................................... 30
3.2.8 Navegador ................................................................................................ 31
3.2.9 Otras herramientas ................................................................................... 31
3.3 Componentes de Mashup de PhysicalTrello. .................................................. 33
3.3.1 APITrello ................................................................................................... 33
3.3.2 MailGun .................................................................................................... 34
4. Resultados ........................................................................................................... 35
4.1 Caracterización de componentes del Mashup de PhysicalTrello. ................... 37
4.2 Caracterización del Mashup. ........................................................................... 41
5. Discusión y opiniones ........................................................................................... 43
5.1 Hallazgos ........................................................................................................ 44
5.2 Recomendaciones .......................................................................................... 50
6. Conclusiones y trabajo futuro ............................................................................... 52
7. Referencias .......................................................................................................... 56
Alonso, G., Casati, F., Kuno, H., & Machiraju, V. (2003). Web Services Concepts,
Architectures and Applications.Berlin: Springer. ...................................................... 56
8. Anexos ................................................................................................................. 59
8.1 Anexo A .......................................................................................................... 59
8.1.1 Instalación y configuración........................................................................ 59
8.1.2 Problemas encontrados ............................................................................ 65
INDICE DE FIGURAS
Figura 1: Arquitectura básica de una aplicación y sistema distribuido ....................... 3
Figura 2: Ejemplo de Web Scraping ........................................................................... 6
Figura 3: Mashup Housingmaps ................................................................................ 7
Figura 4: Categorías más populares de Mashups - Junio de 2015,
programmableweb.com .............................................................................................. 9
Figura 5: Lista de APIs más populares - Junio de 2015, programmableweb.com ...... 9
Figura 6: Cubo de Mashups ..................................................................................... 10
Figura 7: Características de un componente de Mashup(Daniel & Maristella, 2014)18
Figura 8: Ejemplo de un Tablero Kanban (http://blog.consultec.es) ......................... 19
Figura 9: Diagrama de componentes de PhysicalTrello ........................................... 23
Figura 10: Diagrama de secuencia - obtención de Token ........................................ 24
Figura 11: Diagrama de secuencia - impresión de tarjetas con código QR .............. 25
Figura 12: Diagrama de secuencia - actualización de tablero digital ....................... 26
Figura 13: Tablero de bienvenida en Trello .............................................................. 27
Figura 14: Tablero de Trello mostrado en la aplicación web PhysicalTrello. ............ 29
Figura 15: Funcionalidad de PhysicalTrello como extensión para el navegador. ..... 30
Figura 16: Ejemplo de tarea de Trello con código QR - generado por PhysicalTrello
................................................................................................................................. 32
Figura 17: Mailgun.................................................................................................... 34
Figura 18: Ejemplo de rutas en Mailgun - http://www.mailgun.com .......................... 35
Figura 19: Características de un componente de Mashup (Daniel & Maristella, 2014)
................................................................................................................................. 36
Figura 20: Clasificación del Mashup PhysicalTrello ................................................. 42
Figura 21: Aplicación Web de PhysicalTrello ........................................................... 45
Figura 22: PhysicalTrello incrustado en la interfaz de Trello .................................... 46
Figura 23: Arquitectura de la extensión de PhysicalTrello ........................................ 47
Figura 24: Integración de aplicación de terceros en Google Drive ........................... 49
Figura 25: Cubo de Mashups con el tipo de composición “Inyección de Interfaz de
Usuario” .................................................................................................................... 50
Figura 26: Cubo de Mashups - Florian Daniel .......................................................... 53
Figura 27: Clasificación del Mashup PhysicalTrello ................................................. 53
INDICE DE TABLAS
Tabla 1: Aplicaciones que sincronizan tableros físicos y virtuales ........................... 20
Tabla 2: Tipos de componentes de PhysicalTrello ................................................... 24
Tabla 3: Caracterización del componente de Mashup - API de Trello ..................... 39
Tabla 4: Caracterización del componente de Mashup - API de Mailgun .................. 41
1
1. Introducción
Actualmente la Web ha dejado de ser un medio de comunicación en un solo sentido
como en sus comienzos. Hoy existe un enorme ecosistema de aplicaciones en
ejecución en diversos dispositivos y muchas de ellas permiten la interacción con
nuestras propias aplicaciones, todo esto a través de sus Web APIs, Web Services,
librerías de javascript u otros medios(Daniel & Maristella, 2014). Con esto se ha
marcado una nueva tendencia en la Web, la cual consiste en reutilizar componentes
de diversas aplicaciones para formar nuevas aplicaciones que ofrezcan un valor
agregado.
Estos componentes o bloques, han hecho posible que aparezcan las aplicaciones
denominadas Mashups (Daniel & Maristella, 2014), que se caracterizan por la
integración de componentes de datos, lógica o interfaz de usuario (UI). Si bien no
todas las aplicaciones nos facilitan una forma de interactuar con ellas ya sea a
través de una Web API (Richardson & Amundsen, 2013), Web Service u otro
medio, los desarrolladores se las han ingeniado para extraer determinados datos
que les permiten crear nuevas aplicaciones con un valor agregado. Técnicamente
un Mashup es una aplicación compuesta que integra dos o más tipos de
componentes disponibles en la Web.
El ejemplo clásico de Mashup es housingmaps.com el cual tomaba ofertas de casas
y departamentos en renta de Craigslist.com y los colocaba como puntos en un mapa
de Google Maps.
Los Mashups son cada vez más relevantes en el esquema de desarrollo de
software, tanto así que de 2005 a la fecha existen 7851 Mashups registradas en el
sitio programmableweb.com (Berlind, 2015), sitio líder de noticias, información y
evolución acerca de aplicaciones basadas en internet, como lo son las APIs y las
Mashups.
En los siguientes capítulos se presentan los antecedentes históricos de los Mashups
(cap. 2), la arquitectura y desarrollo de un Mashup propio de este trabajo de
investigación (cap. 3 y anexo A). Los retos y hallazgos encontrados en el desarrollo
del mashup mencionado (cap. 4 y 5) y las lecciones aprendidas a considerar en el
desarrollo de Mashups en el futuro (cap. 6).
2
1.1 Motivación
Trello (https://trello.com) con más de 8 millones de usuarios (Spolsky, 2015), es una
aplicación web que permite administrar proyectos y tareas de cualquier tipo,
básicamente usando tableros tipo Kanban. Trello permite gestionar tableros tipo
Kanban digitales, sin embargo para los seguidores de Kanban es importante
mantener también tableros físicos, ya que promueven el principio de Kanban de
máxima visualización y facilitan su administración, por ello la preferencia de los
tableros físicos. Sin embargo hay quienes desean tener ambos sincronizados, pero
son pocas las herramientas que permiten combinarlos. Es por ello que se presenta
PhysicalTrello, herramienta basada en Trello que aprovechando la nueva forma de
composición de aplicaciones basada en la reutilización de componentes web,
permite al usuario tener tanto un tablero físico como uno virtual, manteniendo el
tablero virtual sincronizado con el físico en base a la inclusión y posterior
identificación de códigos QR (Denso Wave Incorporated, 2015) en las tarjetas.
1.2 Objetivos
Esta tesis tiene como objetivos principales los siguientes:
1. Explicar en qué consiste el nuevo tipo de aplicaciones denominadas
Mashups, sus principales características y cómo se componen.
2. Crear una herramienta que permita y facilite combinar los tableros tipo
Kanban físicos y digitales basada en Trello.
3
2. Antecedentes
2.1 Sistemas Distribuidos
Históricamente, los sistemas integrados que se ejecutan en múltiples plataformas
tanto de hardware como de software son conocidos como Sistemas Distribuidos. En
(Tanenbaum, 1994) se define de forma más precisa un Sistema distribuido como
una colección de computadoras independientes que aparecen ante los usuarios
como un sistema coherente y simple. La Figura 1 muestra la arquitectura básica de
un sistema distribuido el cual abarca tres computadoras independientes conectadas
a una red que puede ser una red de área local (LAN) o una red de área amplia
(WAN).
Figura 1: Arquitectura básica de una aplicación y sistema distribuido
Se puede observar como el sistema distribuido que representa la figura encaja en
nuestra definición de sistema distribuido, es decir, es muy común que los sistemas
distribuidos estén formados no solo de computadoras con diferentes configuraciones
de hardware, sino también diferentes configuraciones en software, como por
ejemplo diferentes sistemas operativos. También se puede observar como la
aplicación distribuida es mostrada al usuario como si se tratase de una sola
aplicación, es decir, es completamente transparente al usuario.
4
Para que exista la integración tanto a nivel hardware como software en una
aplicación distribuida es necesaria una capa intermedia que ayude a esta tarea con
cierto nivel de abstracción, esta capa es conocida como Middleware(Alonso, Casati,
Kuno, & Machiraju, 2003).
Middleware es una capa de software la cual sirve como intermediaria entre todas las
piezas de una aplicación distribuida; el middleware proporciona una capa del
sistema distribuido que enmascara la heterogeneidad entre el hardware y el sistema
operativo y además proporciona una vista abstracta de las capacidades del sistema
distribuido. Como tal los servicios de Middleware son por lo general usados por los
desarrolladores que programan aplicaciones distribuidas, y no tanto por usuarios
que no son programadores de aplicaciones distribuidas. Middleware por lo tanto
representa por un lado, una infraestructura de cómputo sobre la cual pueden ser
desarrolladas aplicaciones distribuidas, y por otro lado, una abstracción de
programación que facilita el desarrollo.
Dependiendo del tipo de abstracción y soporte de desarrollo se pueden distinguir
cuatro tipos de Middleware:
● Middleware basado en RPC: El uso de RPCs (Remote Procedure Call)
representa la técnica más básica para implementar un sistema distribuido y
en la actualidad son la base para muchas soluciones de Middleware.
Básicamente este tipo de Middleware consiste en invocar procedimientos
ejecutándose en diferentes máquinas como si estuvieran ejecutándose
localmente. Ejemplos típicos son XML-RPC y SOAP.
● Middleware orientado a objetos: El middleware basado en RPC se basa en
lenguajes de programación imperativos y procedurales. Con la llegada de la
programación orientada a objetos, surge RPC pero orientando a este tipo de
programación, es decir, el soporte de pedidos de objetos distribuidos. Los
ejemplos más conocidos de este tipo son CORBA (Common Object Request
Broker Architecture) y RMI (Java Remote Method Invocation).
● Middleware orientado a mensajes (MOM): Permite a las aplicaciones
distribuidas comunicarse mediante el envío de mensajes. El MOM se encarga
de que todos los mensajes lleguen siempre a su destino. La comunicación
entre emisor y receptor es asíncrona, y en ningún momento están
directamente conectados. El emisor envía el mensaje y no se queda a la
espera de recibir confirmación de recepción de su mensaje, sino que sigue
5
trabajando normalmente. IBM WebSphere MQ (IBM, 2015) es un claro
ejemplo de ese tipo de Middleware.
● Monitores de procesamiento de transacciones y objetos: Estos son
similares a RPC con capacidad transaccional entre dos o más nodos. Los
ejemplos más representativos de estos son IBM CICS (IBM, 2015), Microsoft
MTS (Microsoft, 2015) y Oracle Tuxedo (Oracle, 2015).
2.2 Web Data Extraction (Web Scraping) Cuando fue desarrollado el primer Mashup de housingmaps.com, Google Maps no
tenía pensado publicar una API, tal como lo reconoció Lars
Rasmussen(Rasmussen, 2005), líder de ingenieros del equipo fundador de Google
Maps. Sin embargo esa no fue una limitante para housingmaps, que de alguna
manera se las ingenió para obtener datos de craigslists.org y publicarlos en Google
Maps, permitiendo al usuario realizar búsquedas por regiones, precio y otros filtros,
y ubicarlos geográficamente en Google Maps, ofreciéndole el valor agregado, todo
esto a partir de dos aplicaciones totalmente independientes y distintas tanto en
lenguaje como en arquitectura.
Una de las prácticas usadas para obtener datos de sitios web cuando éstos no
facilitan una API (Rasmussen, 2005), Web Service (Box, y otros, 2007) u otro medio
es conocida como Web Data Extraction o Web Scraping (Ferrara, Fiumara, &
Baumgartner, 2012). Web Scraping es esencial en los Mashups y buscadores.
Scraping es un término que, traducido al español, literalmente significa “rascar”.
En nuestro contexto se refiere a la extracción, limpieza, filtro y reutilización de datos
que son de nuestro interés, tomados de determinadas páginas, a través de
distintas técnicas y siguiendo algunas reglas. El scraping puede hacerse de distintas
formas, ya sea manual, semiautomático teniendo conocimientos de programación o
bien utilizando herramientas disponibles en la Web para este fin como lo es
Mozenda (http://www.mozenda.com) o import.io (https://import.io/ ).
Otra forma muy común de hacer scraping es por medio de analizadores DOM
(Document Object Models), con lo cual estos analizadores hacen un recorrido a toda
la estructura del árbol DOM1 de una página web con el fin extraer datos (Daniel &
Maristella, 2014). En la Figura 2 podemos ver cómo es usada la técnica de Web
1 DOM o Document Object Model es un conjunto de utilidades específicamente diseñadas para manipular
documentos XML. Por extensión, DOM también se puede utilizar para manipular documentos XHTML y HTML. Técnicamente, DOM es una API de funciones que se pueden utilizar para manipular las páginas XHTML de forma rápida y eficiente.
6
Scraping para extraer información de productos de la web de mercadolibre.com.mx,
posteriormente la información extraída puede ser almacenada en diferentes bases
de datos.
Figura 2: Ejemplo de Web Scraping
Anteriormente se mencionaron las características de los sistemas distribuidos, y
vimos además que con este crecimiento de los sistemas distribuidos, aunado con
las necesidades de integrar varios de estos sistemas utilizando en un inicio
técnicas como Web Scraping para generar nuevas aplicaciones, surgieron un nuevo
tipo de aplicaciones llamadas Mashups. En la siguiente sección veremos con más
detalle que es un Mashup.
2.3 Definición de Mashup Técnicamente un Mashup es una aplicación compuesta que integra dos tipos de
componentes disponibles en la Web. En la aplicación housingmaps.com un
componente (por ejemplo Craigslist) es la fuente de datos; el otro (por ejemplo
Google Maps) principalmente juega el rol de un interface de usuario reutilizable (UI),
aunque también proporciona algo de funcionalidad de lógica de negocio, por
ejemplo, la identificación de la posición del marcador en el mapa en una dirección
dada. El término de integración significa establecer un orden de ejecución, a esto se
le conoce como Flujo de Control. Con el ejemplo anterior y la explicación de lo que
es una integración de componentes podemos dar la definición de una Mashup
(Daniel & Maristella, 2014).
7
Un Mashup (o Web Mashup) es una aplicación que integra dos o más componentes
Mashup en cualquier capa de la aplicación, por ejemplo, en la capa de datos, lógica
de aplicación, y presentación, además pueden o no estar en comunicación cada
entre ellos.
Ejemplo de un Mashup
Vamos a retomar con más detalle el primer Mashup housingmaps.com. Surgido en
abril del 2005, combinó dos componentes totalmente independientes, dichos
componentes fueron craigslist.org y Google Maps.
Housingmaps lista ofertas de casas obtenidas de craigslist.org que es una
aplicación libre especialmente usada en los Estados Unidos que publica ofertas de
trabajo y diversos anuncios clasificados. Posteriormente estas ofertas son
georeferenciadas por housingmaps usando Google Maps, permitiendo a los
usuarios de una manera muy fácil buscar viviendas por una zona geográfica
determinada, buscar por rangos de precios, etc. Todo esto se realiza con una
interfaz de usuario por medio de listas desplegables en la parte superior de la
página web. La Figura 3 muestra la página principal del Mashup de housingmaps.
Figura 3: Mashup Housingmaps
8
El ejemplo con el que se ha trabajado hasta ahora (Housingmaps) puede ser
considerado un Mashup de acuerdo a la definición anterior, particularmente porque
es una aplicación web compuesta y su desarrollo requiere dos recursos externos así
como una lógica de integración. Esto nos lleva a otros dos importantes conceptos de
los Mashups; componentes de Mashups y lógica del Mashup.
Un componente de Mashup es cualquier segmento de datos, lógica de aplicación
y/o interfaz de usuario que puede ser reutilizada y que es accesible ya sea local o
remotamente (Daniel & Maristella, 2014).
En este contexto existen otras piezas de software que pueden ser consideradas
también como componentes por ejemplo RSS feeds, RESTful, SOAP, Web
services, interfaces de usuario (Widgets), APIs etc.
La lógica del Mashup es la lógica interna de operación del Mashup; específica la
selección de componentes, el control de flujo, el flujo de datos, la transformación de
los datos, y la interfaz externa del Mashup(Daniel & Maristella, 2014).
2.4 Tipos de Mashups
Los Mashups forman parte de un ecosistema muy grande que está creciendo a un
ritmo acelerado y prueba de esto es que existe un sitio web llamado
“programmableweb.com”. Este sitio es un directorio web de API’s y de Mashups que
pueden ser inspeccionados, además podemos ver las ultimas noticias referentes a
los nuevos Mashups que están surgiendo.
El sitio programmableweb.com tiene clasificadas las APIs y Mashups en categorías
de tal forma que sea más fácil para los usuarios poder buscar una determinada API
o Mashup dependiendo del dominio de la aplicación. Las figuras 4 y 5
respectivamente muestran algunas de las categorías usadas por
programmableweb.com para clasificar tanto las APIs como los Mashups.
9
Figura 4: Categorías más populares de Mashups - Junio de 2015, programmableweb.com
Figura 5: Lista de APIs más populares - Junio de 2015, programmableweb.com
Los nombres de categorías son un buen instrumento para los desarrolladores a la
hora de buscar Mashups en un dominio dado y se puede deducir que existen tanto
Mashups que pueden ser usados en aplicaciones web convencionales, así como en
entornos empresariales; a esto nos referiremos como Entorno. Podemos ver
además que existen diferentes dominios en donde pueden ser usados los Mashups,
por ejemplo aplicaciones móviles, telecomunicaciones, procesos, y algunas más
genéricas; a esto nos referiremos con Dominio. También se mencionó
anteriormente que en la composición de un Mashup podían existir componentes de
datos, lógica y de interfaz de usuario; a esto nos referiremos como
Composición(Daniel & Maristella, 2014).
10
Con lo anterior, se puede decir que los tipos de Mashups encontrados en esas
categorías pueden estar en estas tres perspectivas: entorno, dominio y composición.
A esto se le conoce como el cubo de Mashups(Daniel & Maristella, 2014) como lo
muestra la siguiente figura:
Figura 6: Cubo de Mashups
Las perspectivas son (Daniel & Maristella, 2014):
● Composición: Esta perspectiva hace énfasis en la parte interna del Mashup,
es decir sus componentes y cómo son compuestos en una nueva aplicación.
Esta perspectiva se deriva de la separación en capas el desarrollo de un
software, es decir una aplicación en tres capas: la capa de datos, lógica y
presentación. De esta forma la perspectiva de composición agrupa los
Mashups de la siguiente forma:
○ Mashups de datos.
○ Mashups de lógica.
○ Mashups de interfaz de usuario.
● Dominio: Esta perspectiva hace énfasis en el propósito del Mashup, es decir
la funcionalidad que tiene como objetivo proporcionar. Los dominios en este
contexto son los siguientes:
○ Mashups genéricos
○ Mashups de procesos
11
○ Mashups móviles
○ Mashups de telecomunicaciones (telco)
● Entorno: Esta perspectiva hace énfasis en el contexto de despliegue de un
Mashup, es decir el contexto en el cual el Mashup es usado. Básicamente
pueden ser de dos tipos:
○ Mashups Web.
○ Mashups Empresariales.
Anteriormente se había mencionado del uso de componentes de datos, lógica o
interfaz de usuario UI de diversas aplicaciones para reutilizarlos en nuestros
Mashups, generando un nuevo valor agregado. Tal es el caso de housingmaps.com
que toma datos de Craigslist y los despliega en mapas de Google Maps, este tipo
de aplicaciones denominadas Mashups se clasifican en cuatro tipos, los cuales se
describen a continuación(Daniel & Maristella, 2014).
Mashups de Datos
Este tipo de Mashups operan en la capa de datos, estos extraen datos de diferentes
servicios o recursos, los datos pueden ser extraídos de un solo recurso o varios,
realizando un filtro, selección y limpieza de datos que finalmente serán los de interés
para el objetivo del Mashup. Los datos finales generalmente son publicados como
RSS feeds o RESTful Web services.
Mashups de Lógica
Este tipo de Mashup es el que utiliza componentes en la capa de lógica, como
pueden ser objetos Javascript, de cierta forma se está reutilizando la lógica del
componente, la cual puede ser usada tanto en la capa de lógica como en la de
datos, siendo importante conocer las especificaciones del componente a efecto de
controlar los datos de entrada y los de salida.
Mashups de Interfaz de Usuario (UI)
Localizados en la capa de presentación, este tipo de Mashups manipulan
componentes de interfaz de usuario, como ejemplo podemos hablar de Google
Maps, generalmente cuando decidimos usar google maps en nuestras aplicaciones,
12
nos traemos toda su interfaz y la ubicamos en un lugar específico de nuestra
página, es decir hacemos una integración de Interfaces de usuario, y debe de
haber una sincronización entre cada componente, la interacción del usuario con este
tipo de Mashups se da a través de eventos, los cuales podemos usar para
sincronizar los componentes o piezas del Mashup.
Mashups Híbridos
Un Mashup híbrido integra componentes de distintas capas, como pueden ser
datos, lógica o interfaz de usuario, a diferencia de los anteriores los cuales solo
estaban formados por componentes del mismo tipo, los Mashups Híbridos como es
el caso de PhysicalTrello, motivo de este trabajo, integra un componente de lógica y
otro de datos, y los integra en un componente de interfaz, es por ello que se
denominan Híbridos, detrás de esta integración existe una serie de operaciones que
hacen posible su sincronización.
Si bien hemos clasificado los distintos tipos de Mashups y hemos ubicado a
PhysicalTrello como un Mashup híbrido, es necesario mencionar que los Mashups
se conforman de Componentes, dichos componentes tienen siete características,
motivo de la siguiente sección.
2.5 Características de los Componentes de un Mashup
Las características de un componente nos ayudan a responder las preguntas: ¿
Qué ?, ¿ Dónde ?, ¿ Cómo ? y ¿ Para quién ?, ya que cada componente tiene su
propia tecnología y esto determina el tipo de invocación, integración y presentación
requerida para poder hacer uso del mismo.
Tipo de Componente
El tipo de componente nos indica qué es lo que puede ser reutilizado, y también en
la mayoría de los casos determina el tipo de Mashup creado, aunque también
existen Mashups híbridos, como es el caso de Physical Trello, los tipos de
componentes se clasifican en (Daniel & Maristella, 2014):
13
● Datos, como su nombre lo indica, este tipo de componente es el que nos
permite acceder a datos, los cuales pueden ser estáticos como RSS o Atom,
o bien dinámicos a través de consultas dinámicas, Web Services o APIs, o
bien valiéndose de técnicas de extracción cuando no existe algún recurso
facilitado por el propietario de la página, afortunadamente al día, el
crecimiento de recursos como APIs va en crecimiento.
● Lógica, nos permite acceder a su lógica de negocio, por ejemplo reutilizar
sus algoritmos, un caso muy práctico es PayPal, el cual nos permite realizar
transacciones de pagos, aquí es importante controlar la entrada de datos al
componente de lógica, y de esta forma obtener una salida.
● Interfaz de Usuario, este tipo de componente nos permite hacer uso de una
aplicación completa dentro de nuestra aplicación, el mejor ejemplo es Google
Maps, existen infinidad de aplicaciones que hacen uso de google maps,
como podemos observar al hacer uso de google maps en nuestras
aplicaciones, básicamente estamos trayéndonos su interfaz, la cual podemos
colocar dentro de un frame en nuestra página.
Ubicación en tiempo de ejecución
Es necesario que identifiquemos cómo puede ser accedido el componente, esta
característica nos indica en dónde se encuentra el componente, es decir su
ubicación, la cual puede ser de tres tipos (Daniel & Maristella, 2014):
● Local, este tipo de componentes se ejecutan localmente en el mashup, por
ejemplo están las librerías de JavaScript, o Interfaces de Usuario que son
ejecutadas en el cliente, en el caso de JavaScript, estas generalmente son
descargadas dentro de la aplicación, también puede haber librerías de
determinado lenguaje que requieren que sean descargadas para su ejecución
en el Mashup.
● Remota, este es el caso de Web Services, APIs u otros servicios remotos,
la integración al Mashup se da a base de mensajes o invocación de
procedimientos remotos, comúnmente es necesario algún tipo de registro y
permisos de uso para autentificarnos y hacer uso de este tipo de
componentes, por ejemplo para hacer uso de la API de Trello, es necesario
14
autenticarse a través del protocolo OAuth2, lo que permite a Trello tener un
mejor control de quién y cómo se está usando su API.
Modelo de Invocación
Aunque la característica anterior nos dice si el componente requiere o no una
instalación local, o se ejecuta remotamente, el modelo de invocación nos dice cómo
es invocado el procedimiento para intercambiar información con este, básicamente
se distinguen cuatro tipos de modelos de invocación (Daniel & Maristella, 2014):
● Llamadas a procedimientos locales (LPCs): Es la técnica más tradicional
de interacción entre módulos de software, soportada por la mayoría de los
lenguajes modernos, comúnmente la interacción se da entre módulos escritos
en el mismo lenguaje, sin embargo pueden existir facades2 entre los módulos
que desean interactuar.
● Llamadas a procedimientos remotos (RPCs): Son una extensión de los
LPCs, las llamadas se dan entre procedimientos remotos como si estuvieran
siendo llamados localmente, los RPCs son soportados en muchos de los
lenguajes modernos, por ejemplo en Java existe RMI (Oracle, 2015),
regularmente los métodos están en el mismo lenguaje, pero no
necesariamente debe ser así.
● Invocación basada en mensajes: El modelo de invocación basado en
mensajes para aplicaciones distribuidas es más centrada en datos y menos
centrada en procedimientos como lo son los RPC. La interacción de los
componentes son identificados por sus puntos finales (endpoints) y sus
operaciones (procedimientos). La invocación basada en mensajes oculta los
detalles de la implementación interna (por ejemplo el lenguaje de
programación). Los estándares más usados de este tipo son SOAP (Box, y
otros, 2007), así como los web services tipo RESTful (Richardson &
Amundsen, 2013). Gracias a estos protocolos, las invocaciones basadas en
mensajes permiten un bajo acoplamiento entre los componentes.
2 Patrón de diseño de Software comúnmente usado en programación orientada a objetos, es
frecuentemente usado cuando un sistema es muy complejo o difícil de entender debido a que tiene un largo número de clases independientes o bien subsistemas, su propósito es ocultar la complejidad, ofreciendo una interfaz simple al cliente, un claro ejemplo es un sistema operativo.
15
● Invocación basada en eventos : En los métodos de invocación anteriores,
el método remitente o emisor conocía a su receptor y los métodos a invocar,
sin embargo en este tipo de invocación basada en eventos no es así, como
su nombre lo indica la invocación se da en base a eventos (Muhl, Fiege, &
Pietzuch, 2006), lo que permite la implementación de patrones de
comunicación uno a uno, uno a muchos y muchos a muchos, los eventos
pueden ser locales o remotos, como ejemplo podemos hablar de un museo
en el cual existen diferentes sensores de fuego, apertura de puertas, etc.,
cada sensor al ser activado puede generar un evento que es consumido por
algún tipo de componente.
Estilo de transmisión
Independientemente de si el método de invocación es local o remoto, la interacción
entre componentes ocurre en dos estilos diferentes (Daniel & Maristella, 2014):
Transmisión Síncrona, o bloqueo de transmisiones, en este tipo de transmisión el
emisor y receptor deben de estar ejecutándose al mismo tiempo, al momento de que
el emisor genera una petición, el componente que ejecuta la llamada queda
bloqueado hasta que recibe la respuesta, un ejemplo es la invocación de librerías de
JavaScript.
Transmisión Asíncrona, en este tipo de transmisiones los componentes no se
bloquean, tampoco es necesario que ambos estén ejecutándose al mismo tiempo,
un ejemplo de este estilo de transmisión es el correo electrónico.
Formato
El formato de datos es muy importante en la interacción entre componentes,
existen múltiples formatos (http://www.iana.org/assignments/media-types/index.html)
también llamados MIME types, que nos indican el formato, por ejemplo RSS, XML,
JSON, MP3, JPG, MP4, etc., los cuales básicamente se agrupan en dos familias:
● Tipos de medios discretos: los que requieren una transmisión completa,
como es el caso de las imágenes o páginas HTML.
16
● Tipos de medios de streaming: Este tipo de datos permiten una
transmisión incremental en partes, como es el caso de estaciones de radio,
películas, siendo más complejos.
Modelo de Instanciación
El modelo de instanciación en parte determina el tipo de transmisión (síncrona,
asíncrona), pero lo más importante de esta característica de unos componentes, es
que el modelo de instanciación determina el tiempo que debe estar disponible una
instancia de un determinado componente, la instanciación puede darse como
sigue(Daniel & Maristella, 2014):
● Stateless : Cuando el componente es instanciado solamente durante el
tiempo necesario para procesar la respuesta a una operación de invocación y
después es destruido, entonces se denomina stateless, siendo este modelo
de instanciación muy eficaz en el uso de memoria, ya que permanece
disponible únicamente por el tiempo necesario, este modelo de
instanciación es uno de los aspectos exitosos de los servicios web basados
en REST, ya que se implementan como tipo stateless, al contrario de los
SOAP Web services que se implementan como stateful, siendo más
eficientes los primeros, pues son implementados con un tipo de transmisión
síncrona.
● StateFul: En este tipo de instanciación, el componente está disponible
durante múltiples invocaciones de operación, es decir que permanece
ocupando memoria durante el tiempo que así permanezca, un ejemplo
práctico de un componente con modelo de instanciación stateful puede ser
un widget de interfaz de usuario que al ser instanciado dentro de una página
web, la cual al ser accedida por múltiples usuarios necesita interactuar y
sincronizarse con otros widgets. Al contrario del estilo de invocación síncrona,
el estilo de transmisión para los componentes tipo stateful puede ser
síncrona o asíncrona.
Orden de Invocación
Un aspecto importante a considerar es el orden de invocación de los componentes,
ya que dependiendo de la lógica interna del componente, algunas operaciones
17
podrían requerir de ciertas precondiciones para poder ser invocadas. Pongamos
como ejemplo una compra en línea, en la cual no podríamos primero enviar el pago
sin antes enviar la lista de artículos que se van a adquirir. El orden de invocación se
clasifica en dos tipos (Daniel & Maristella, 2014):
● Sin restricción de orden: Las invocaciones a las operaciones del
componente pueden ser realizadas en cualquier orden, no existiendo
prerrequisitos para la ejecución de operaciones.
● Con restricción de orden: La invocación a operaciones del componente
necesitan cumplir ciertos prerrequisitos, es decir, deben de llevar un orden,
ya que hay dependencia entre cada operación.
Descripción del Componente
Sin duda, un aspecto importante que puede acelerar la implementación y uso de un
componente es la documentación que el proveedor del componente nos facilite, al
día de hoy se le ha dado mucha importancia a este aspecto, por ejemplo el
crecimiento de APIs generalmente es acompañado con buena documentación, la
calidad de documentación de una API la podemos verificar aplicando un CheckList
de usabilidad, un CheckList recomendable es el de codeproject
(http://www.codeproject.com/Articles/8707/API-Usability-Guidelines-to-improve-your-
code-ease ). Podemos clasificar este aspecto en las tres siguientes
situaciones(Daniel & Maristella, 2014):
● Sin descripción: El componente solo está disponible como una pieza de
software sin ninguna documentación o ayuda disponible, el desarrollador
tiene que buscar ejemplos o bien si es posible leer el código. En esta
situación, se tiende a cometer errores al reutilizar el componente.
● Con descripción legible por humanos: En esta situación, el componente
viene acompañado de documentación que puede ser leída por humanos,
como es el caso de las APIs (aunque estas también pueden venir con
documentación en formato XML o JSON), o de componentes con
documentación generada por alguna utilería como Javadoc o simplemente en
formato HTML.
18
● Con descripción legible por máquinas o de manera automática: También
existen componentes con documentación que puede ser leída tanto por los
desarrolladores, como por una máquina, por ejemplo el formato XML o JSON.
En este capítulo se explicó los diferentes componentes que pueden formar parte de
un Mashup, además se explicaron un conjunto de características que capturan los
aspectos más importantes acerca de los Mashups. A manera de resumen,
mostramos una figura que representa las principales características que debe de
tener un componente de un Mashup.
Figura 7: Características de un componente de Mashup(Daniel & Maristella, 2014)
En este punto, ya se conocen en qué consisten las aplicaciones denominadas
Mashups, los diferentes tipos, arquitectura, integración, etc. Por lo tanto, con esto se
logra el primer objetivo de esta tesis, el cual es explicar en qué consisten dichas
aplicaciones.
2.6 La importancia de Kanban en este proyecto Antes de continuar con el siguiente capítulo, el cual describe el trabajo presentado
en este documento, es importante mencionar que PhysicalTrello, nombre de la
aplicación desarrollada, está basada principalmente en la aplicación web Trello
(https://trello.com/). Trello es una aplicación web de propósito general para
organizar y administrar proyectos, así como tareas de cualquier tipo, promoviendo la
productividad y el trabajo colaborativo. Su uso más común es enfocado a la
administración de tableros tipo Kanban, es por ello que a continuación se describe
brevemente este método.
19
El término Japonés Kanban, fue empleado por el Ingeniero Mecánico Japonés
Taiichi Ohno (29 de Febrero de 1912 - 28 de Mayo de 1990) de Toyota, para
referirse al sistema de visualización empleado en los procesos de producción que
coordinan en una cadena de montaje la entrega a tiempo de cada parte en el
momento que se necesita, evitando sobre producción y almacenamiento innecesario
de producto. Se puede traducir como tablero o tarjeta de señalización, y su origen
se remonta a finales de 1940 o principio de 1950.
Si bien Kanban surge para procesos de producción en Toyota, al día de hoy es
ampliamente usado para gestión de proyectos y tareas de cualquier tipo, ya que su
uso es muy intuitivo. Básicamente se trata de un tablero en el cual tenemos
columnas con el nombre de las fases o etapas y en cada una de ellas colocamos
tareas. Estos tableros pueden ser físicos usando post-it u otro tipo de notas para
anotar las tareas, o bien digitales, como es el caso de Trello (https://trello.com ) u
otras herramientas disponibles en la web. Una vez colocadas las tareas en
determinada etapa indicada por la columna, las tareas se van moviendo entre
columnas, lo cual indica la etapa en la que se encuentran. Aunque los tableros
físicos promueven el principio de máxima visualización de las tareas, al estar
siempre a la vista de las personas y equipos, cuando se trata de equipos
distribuidos geográficamente, los tableros digitales son de mucha utilidad. La
siguiente imagen ilustra un tablero físico.
Figura 8: Ejemplo de un Tablero Kanban (http://blog.consultec.es)
Existen personas que además de tener un tablero Kanban virtual, también prefieren
los tableros Kanban físicos ya que promueven el principio de Kanban de máxima
visualización y facilitan su administración. El problema es que hay pocas
20
herramientas que sincronizan un tablero físico con uno virtual. De hecho, antes del
desarrollo de esta tesis, se realizo una búsqueda de herramientas que permitieran
trabajar con tableros físicos y virtuales, y solo fueron encontradas 2 aplicaciones;
JimFlow (Jimdo, 2015) y Agile Cards for Jira (Atlassian, 2015). La siguiente tabla
muestra las principales características de estas.
Nombre Características
JimFlow • Se integra con Trac y Jira para los tableros digitales • Toma fotos automáticamente cada cierto intervalo de
tiempo. • Las fotos son tomadas con una cámara Canon. • La cámara Canon envía la foto vía FTP para hacer la
sincronización de los tableros. • Utiliza códigos QR para la identificación de los
elementos del tablero. • Open Source.
Agile Cards for
Jira
• Se integra con Jira. • Utiliza códigos KR y QR para su identificación. • Tiene múltiples plantillas. • Las fotografías pueden ser tomadas con un celular. • Las fotos se suben vía web a la aplicación Jira para
hacer la sincronización de los tableros. • Se necesita licencia para su uso.
Tabla 1: Aplicaciones que sincronizan tableros físicos y virtuales
Específicamente no se encontró una aplicación para los usuarios de Trello. Derivado
de ello y dado que el segundo objetivo de esta tesis es crear una herramienta que
permita trabajar con tableros tipo Kanban físicos y digitales basados en Trello, en el
siguiente capítulo se presenta los detalles de dicha aplicación.
21
3. PhysicalTrello Muchos equipos de desarrollo se apoyan de Tableros Kanban como una
herramienta que les permite tener una visualización muy completa del estatus actual
de sus proyectos, así como otros beneficios que tiene el uso de los tableros. Existen
equipos que prefieren los tableros virtuales y otros que los prefieren físicos, cada
uno tiene sus ventajas y desventajas, aunque si bien entendemos que el uso de
tableros físicos en equipos distribuidos remotamente es poco práctico, sin embargo
para equipos locales lo ideal sería que tuvieran la facilidad de usar en conjunto
tableros virtuales y físicos, manteniendo el principio de máxima visualización de
Kanban en el tablero físico y teniendo todas las ventajas que pueden ofrecer
herramientas de tableros virtuales. Es aquí donde radica el problema; existen pocas
herramientas que sincronicen un tablero físico con uno virtual, y específicamente no
se ha encontrado una para los usuarios de Trello (Trello, Inc, 2015) que es una
herramienta de propósito general ampliamente usada para manejar tableros tipo
Kanban de forma virtual y la cual cuenta con ocho millones de usuarios de acuerdo
a la publicación de Venture Beat (Spolsky, 2015) y publicada también en el canal
oficial de Trello en Twitter, es por ello la importancia de una herramienta como
PhysicalTrello. Derivado de esto es que fue creada la aplicación de PhysicalTrello,
por lo cual iniciaremos con una breve explicación de esta aplicación y
posteriormente ilustraremos su arquitectura utilizando diagramas en Lenguaje
Unificado de Modelado (Fowler, UML Distilled: A Brief Guide to the Standard Object
Modeling Language, 2004) de componentes y secuencia.
PhysicalTrello
PhysicalTrello es una aplicación web basada en Trello, la cual permite sincronizar
tableros virtuales con su respectivo tablero físico utilizando códigos QR para
identificar las tarjetas. La sincronización de un tablero virtual en Trello por medio de
una imagen del tablero físico se puede resumir en seis pasos los cuales son:
1. Crear tablero en Trello.
2. Imprimir el tablero virtual para formar el tablero físico en un pizarrón o pared.
La impresión del tablero básicamente es imprimir las cabeceras (nombres de
las columnas. Por ejemplo pendientes, haciendo, terminado.) y todas las
tareas (Tickets).
22
a. Nota: La impresión de las cabeceras y las tareas van acompañadas de
un código QR, el cual permite su identificación.
3. Organizar el tablero físico en una pared o pizarrón.
4. Tomar y enviar a PhysicalTrello una fotografía del tablero físico.
5. Por medio de PhysicalTrello analizar la fotografía que fue tomada al tablero
físico e identificar las posiciones de las tarjetas a través de los códigos QR
encontrados en la fotografía, identificando también las columnas (pendientes,
haciendo, terminado) en la que se encuentra cada tarea, así como el
identificador del tablero y el usuario propietario del mismo.
6. En base a los datos obtenidos de la identificación de los códigos QR,
actualizar la posición de las tarjetas en el tablero virtual en Trello.
Ahora que ya sabemos qué es PhysicalTrello y cómo trabaja vamos a ver la
arquitectura de la aplicación apoyándonos de diagramas UML.
3.1 Arquitectura de PhysicalTrello
Diagrama de componentes
El siguiente diagrama de componentes nos muestra los elementos de diseño de
PhysicalTrello, permitiéndonos visualizar con más facilidad la estructura general del
sistema.
23
Figura 9: Diagrama de componentes de PhysicalTrello
Como se puede observar en el diagrama de componentes, PhysicalTrello está
organizado principalmente en tres tipos de componentes de acuerdo a su función o
tarea, los cuales son:
Tipo de Componente Responsabilidad
Componentes para imprimir los
tableros
La función de estos componentes es
permitir al usuario conectarse con su cuenta
de Trello para imprimir sus tableros físicos
usando la interfaz proporcionada por Trello.
Componentes para actualizar el
tablero virtual
Estos componentes interactúan entre ellos
para que un usuario pueda actualizar el
tablero virtual tomando en cuenta el estado
actual del tablero físico.
24
Componentes usados para imprimir
y actualizar el tablero virtual.
Son componentes usados tanto para
imprimir el tablero físico, como para
actualizar el tablero virtual.
Tabla 2: Tipos de componentes de PhysicalTrello
Más adelante, se describirá con más detalle cada uno de los componentes.
Diagrama de Secuencia
Si bien el diagrama de componentes nos permite ver la estructura general del
sistema a un nivel más alto de abstracción, el diagrama de secuencia nos permite
analizar la forma en que los componentes u objetos se comunican e interactúan
entre sí en el transcurso del tiempo, por lo cual se incluyen también estos
diagramas, los cuales son más ilustrativos, en general el proceso de PhysicalTrello
se puede separar en las siguientes tres partes:
1. Obtención del Token de autenticación en Trello, con el cual el usuario otorga
permisos a PhysicalTrello para que tenga acceso a sus tableros en Trello, y
posteriormente realice la actualización de su tablero digital en base a las posiciones
de las tarjetas en el tablero físico, lo cual se ilustra con el siguiente diagrama de
secuencia:
Figura 10: Diagrama de secuencia - obtención de Token
2. Impresión de las tarjetas de un determinado tablero del usuario en Trello,
añadiendo un código QR que permitirá la identificación del tablero, identificación del
25
usuario del tablero, e identificación de listas y posiciones de las tarjetas. El siguiente
diagrama de secuencia ilustra este proceso:
Figura 11: Diagrama de secuencia - impresión de tarjetas con código QR
3. Actualización del Tablero digital (Trello) mediante la toma y envío a través de
MailGun(Rackspace, 2015) de una fotografía del tablero físico, MailGun al recibir la
fotografía, la envía a un script de PhysicalTrello, el cual descarga la fotografía en el
servidor PhysicalTrello, para que a su vez el cron de PhysicalTrello ejecute el
proceso de identificación de tarjetas así como sus posiciones. Usando el
componente de JimFlowKlopfer(Jimdo, 2015), se genera el archivo JSON y se
ejecuta la actualización del Tablero digital a través de la API de Trello. Este proceso
se ilustra con el siguiente diagrama de secuencia:
26
Figura 12: Diagrama de secuencia - actualización de tablero digital
Para lograr la sincronización de un tablero virtual por medio de una imagen de un
tablero físico (PhysicalTrello) se tuvieron que utilizar para su desarrollo varios
componentes, cada uno de ellos tiene una función específica.
3.2 Componentes de PhysicalTrello.
Como vimos anteriormente en el diagrama de componentes (Figura 9), para el
desarrollo de PhysicalTrello se utilizaron varios componentes. Un punto a destacar
aquí, es que la mayoría de esos componentes no son componentes web (ej. APIs,
Web Service). Por ejemplo la base de datos, las tareas programadas, la extensión
del navegador de internet, la aplicación móvil, JimFlowKlopfer, etc., y por lo tanto,
estos no son considerados componentes de Mashup. A continuación vamos a
describir los componentes antes mencionados.
3.2.1 Trello
27
Figura 13: Tablero de bienvenida en Trello
Trello es una aplicación de propósito general para crear tarjetas (tickets) dentro de
listas (describiéndolas de un modo muy básico e intuitivo). Lo que la hace único a
Trello es su versatilidad: A cada elemento de una lista se le pueden agregar varios
elementos: otras listas, imágenes, vídeos, documentos, etc. Además, es
extremadamente potente para uso colaborativo y remoto. Pueden agregarse
cualquier número de usuarios, asignar tareas, fechas, checklists, etc. Se basa en el
método Kanban para gestión de proyectos con tarjetas que viajan por diferentes
listas en función de su estado: así, podemos tener una lista de cosas por hacer (to
do, o pendientes), cosas que se están haciendo (doing, o en proceso) o hechas
(done, o terminadas).
La lista de usos que se le pueden dar a esta herramienta es interminable, el más
obvio, es para gestión de proyectos en equipos que trabajan con Tableros Kanban.
Sin embargo, Trello puede ser usado por cualquier persona u organización que
desee organizar sus actividades o proyectos. Trello permite el control del proyecto
de forma detallada de tal forma que todos los participantes siempre saben cuál es el
estatus actual del proyecto, así como las tareas que tiene asignadas cada miembro
del equipo.
En resumen, Trello nos facilita la administración de Tableros virtuales, y entre sus
ventajas tenemos que:
28
● Es ideal para equipos que trabajan remotamente.
● Se gana espacio (puedes tener decenas de tableros digitales en un mismo
lugar).
● Cuida la deforestación, ya que todo es digital.
● Permite combinarlo con otras herramientas como la extensión Burndown For
Trello, que nos permite asignar puntos a cada tarea y calcular
automáticamente métricas, así como obtener gráficas BurnDown.
● Un cambio realizado por un integrante inmediatamente es reflejado para
todos los miembros del equipo del Tablero.
● Se puede usar de forma gratuita.
● Cuenta con una API para los desarrolladores.
Por todas estas ventajas fue que se decidió usar esta herramienta como la base
para desarrollar PhysicalTrello.
3.2.2 JimFlowKlopfer
JimFlowKlopfer es un componente de JimFlow (Jimdo, 2015),
siendo este último un conjunto de componentes que integran una
herramienta híbrida que combina las características de los dos
mundos ágiles, un tablero Kanban físico el cual está enlazando
todas las tarjetas a un tablero Kanban digital, dando como
resultado la sincronización del tablero virtual cuando el tablero físico se actualiza, la
actualización se hace mediante la toma y envío por FTP de una fotografía,
posteriormente el componente JimFlowKlopfer es el que hace la identificación de
las posiciones entre listas de los códigos QR impresos en cada tarjeta,
JimFlowKlopfer está escrito en el lenguaje Phyton y al ser JimFlow de código
abierto, es lo que permitió reutilizar y modificar el componente JimFlowKlopfer para
adaptarlo a las necesidades de PhysicalTrello.
3.2.3 PhysicalTrello
PhysicalTrello es una aplicación web creada con PHP y Mysql con la cual un usuario
puede hacer Login con las mismas credenciales que utiliza para conectarse a Trello.
Al conectarse a la aplicación aparecerá la lista de tableros que tiene el usuario en
Trello, así como las tarjetas asociadas a cada uno de ellos.
29
La Figura 14 muestra un ejemplo de PhysicalTrello con los detalles de un tablero
llamado “comprasDirectas2015”.
Figura 14: Tablero de Trello mostrado en la aplicación web PhysicalTrello.
El objetivo principal de esta aplicación es obtener los datos de los tableros
directamente de Trello utilizando el API de Trello para poder imprimir las tarjetas y
los nombres de las listas, con el fin de que los usuarios puedan formar su
equivalente tablero físico, que más adelante será sincronizado con dicho tablero
virtual. Como se puede observar en la figura anterior, esta un botón para imprimir
las cabeceras (listas. ej. backlog, selected, doing, etc.) y otro botón para imprimir las
tareas.
3.2.4 Extensión PhysicalTrello
Otra forma de imprimir las tarjetas y cabeceras del tablero es
mediante una extensión para el navegador de Internet Firefox, la
cual nos permite añadir funcionalidad a Trello, agregando enlaces
dentro de la propia página de Trello, los cuales permiten al usuario
realizar dichas tareas. La figura 15 muestra los diferentes controles que son
insertados a la propia interfaz de Trello por medio de la extensión del navegador.
30
Figura 15: Funcionalidad de PhysicalTrello como extensión para el navegador.
3.2.5 Tarea Programada (Cron) También fue necesario programar dos trabajos cron dentro del
servidor de PhysicalTrello, estos tienen la tarea de monitorear la
recepción de imágenes de los tableros físicos, así como de
lanzar el script que realiza la identificación de las tarjetas a través
de los códigos QR (Denso Wave Incorporated, 2015) dentro de
cada fotografía, y generación del archivo JSON que es
monitoreado por un segundo cron para ejecutar el proceso de actualización del
tablero digital en Trello.
3.2.6 Aplicación Android
La aplicación Android es una aplicación para móviles muy sencilla. Básicamente
esta aplicación lo que tiene es un botón, cuando dicho botón es pulsado se toma
una fotografía al tablero físico. Posteriormente la fotografía es enviada vía correo
electrónico a una dirección predeterminada. Esta fotografía será la utilizada para
actualizar el equivalente tablero virtual en Trello de forma automática.
3.2.7 Base de Datos PhysicalTrello
Este componente es una base de datos Mysql la cual es usada para guardar
información de seguridad de los usuarios que utilizan Trello. Básicamente lo que se
guarda en esta base de datos es una relación de los usuarios, con el Token de
seguridad de cada uno de los usuarios. En el Anexo A se explican los detalles de
esta base de datos.
31
3.2.8 Navegador
El navegador de Internet es importante, debido a que es el medio por el cual la
aplicación de Trello y PhysicalTrello interactúan, ya sea por medio de la aplicación
web, o la extensión para el navegador.
3.2.9 Otras herramientas
Además de los componentes anteriores, es importante mencionar dos aspectos
importantes de PhysicalTrello que no son como tales componentes, sin embargo
fueron piezas fundamentales para el desarrollo de la aplicación; códigos QR y
protocolo de autenticación oAuth.
Códigos QR con TCPDF
Un código QR (Denso Wave Incorporated, 2015) (quick response code, «código de
respuesta rápida») es un módulo útil para almacenar información en una matriz
bidimensional, creado en 1994 por la compañía Japonesa Denso Wave, subsidiaria
de Toyota. Un código QR se caracteriza por los tres cuadrados que se encuentran
en las esquinas y que permiten detectar la posición del código al lector. La sigla
«QR» viene de la frase inglesa «Quick Response» («Respuesta Rápida» en
español), pues el equipo creador a cargo de Masahiro Hara (Denso Wave
Incorporated, 2015) tenía como objetivo que el código permitiera que su contenido
se leyera a alta velocidad. Un código QR es capaz de almacenar hasta 7,089
caracteres (numéricos, alfabéticos, símbolos, binarios, códigos de control, y alfabeto
Japonés como Hiragana3). Actualmente existen 40 versiones (Denso Wave
Incorporated, 2015).
Los códigos QR son muy comunes en Japón y de hecho son el código
bidimensional más popular en ese país, y tienen también un uso cada vez mayor en
el mundo. La siguiente imagen muestra un ejemplo de un código QR contenido en
una tarjeta de Trello, impresa por PhysicalTrello para permitir la colocación e
identificación de un tablero Físico.
3 El Hiragana es uno de los dos silabarios empleados en la escritura japonesa, el otro se denomina
katakana.
32
Figura 16: Ejemplo de tarea de Trello con código QR - generado por PhysicalTrello
Existen en Internet diferentes sitios que ofrecen la posibilidad de generar códigos
QR. Por ejemplo, el sitio “http://goqr.me/” permite generar códigos QR online,
incluso tiene una API para poder integrarla en aplicaciones de terceros. Otra forma
de generar códigos QR es utilizar librerías especiales las cuales existen para la
mayoría de los lenguajes de programación, en el caso de PhysicalTrello se usó una
librería para PHP proporcionada por TCPDF (Tecnick.com LTD, 2015).
TCPDF es un proyecto Open Source, en sí una clase PHP para generar
documentos PDF que no requiere extensiones externas. Es relativamente sencillo
de implementar en una aplicación PHP, y cuenta con muchas características que
nos permiten crear documentos personalizados. La razón por la cual se eligió
TCPDF fue por su facilidad para generar códigos QR en un PDF, lo cual es una
parte importante al momento de generar las etiquetas y cabeceras de los proyectos
de Trello en PDF para que el usuario pueda imprimirlas.
OAuth
Como bien resume Google (Google Inc, 2015), el protocolo OAuth
proporciona una manera estándar de acceder a los datos protegidos
de diferentes sitios web. Dicho de otro modo OAuth es un protocolo abierto y
estándar que permite a un sitio web A acceder de un modo seguro, previa
autorización del usuario, a datos de acceso restringido de dicho usuario
almacenados en otro sitio web B mediante una API que soporta OAuth y que B
pone a disposición de A.
El aspecto más importante en cuanto a la seguridad que ofrece OAuth es que el sitio
web A (OAuth Consumer) no almacena los credenciales de acceso (usuario y
contraseña) que el usuario utiliza en su cuenta en el sitio web B (Service Provider).
33
API Key y Callback URL
Cada OAuth Service Provider nos proporciona un API Key (un string de letras y
números) para identificar que las peticiones que recibe mediante su API vienen de
un OAuth Consumer autorizado, es decir, nuestra aplicación.
A su vez, cada OAuth Service Provider nos pedirá que se indique un Callback URL,
es decir, una dirección URL que apunte a un archivo de nuestra aplicación el cual se
encargará de procesar la respuesta de autorización (o desautorización) de acceso a
los datos de la cuenta del Usuario en el OAuth Service Provider.
3.3 Componentes de Mashup de PhysicalTrello.
En la sección anterior se describieron los componentes de PhysicalTrello que no
son componentes web como tal y otras herramientas utilizadas (códigos QR y
oAuth). Ahora toca el turno de describir de forma general los componentes web de
que dieron lugar al Mashup PhysicalTrello, es decir APITrello y Mailgun.
3.3.1 APITrello
Los usuarios de Trello por lo general usan la aplicación web para poder crear,
administrar, modificar, etc., sus tableros de sus diferentes proyectos. Dicha
aplicación puede ser usada desde un navegador de Internet en la PC o puede ser
usada desde diferentes dispositivos móviles como celulares, tablets, etc.,
descargando la aplicación para dichos dispositivos desde la página oficial de Trello.
Sin embargo cuando los usuarios tratan de acceder a sus tableros desde
aplicaciones externas o incluso desde sus propias aplicaciones, tienen que hacer
uso de una API. Trello proporciona una web API de tipo RESTful en donde cada
recurso (tableros, tarjetas, listas) pueden ser accedidos por medio de una URI
(Uniform Resource Identifier - Identificador de Recursos Uniforme) con la que
pueden interactuar. Por ejemplo si quisiéramos usar el API para obtener información
acerca del tablero de desarrollo de Trello, se podría hacer una llamada a la siguiente
URI:
https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c
La URI mostrada anteriormente está formada por los siguientes elementos:
34
1. https://api.trello.com: Todas las peticiones del API son dirigidas a esta
URL.
2. La parte /1 de la URI es la versión del API
3. La parte /boards significa que deseamos dirigirnos a la colección de tableros.
4. La parte de /4d5ea62fd76aa1136000000c es el id del tablero con el que
vamos a interactuar.
3.3.2 MailGun
Figura 17: Mailgun
Mailgun de Rackspace (Rackspace, 2015) es un conjunto de APIs utilizadas para
enviar, recibir y rastrear emails, permitiendo a los desarrolladores despreocuparse
por la implementación del servicio de correo electrónico en nuestras aplicaciones.
Mailgun nos proporciona APIs para varios lenguajes, entre ellos PHP, Ruby, Python,
Java, C#, Go. También nos permite el uso de curl para interacción por consola, sin
embargo para el caso de nuestra aplicación, no fue necesario descargar ni hacer
uso de ninguna API, ya que la forma de implementarlo fue simplemente registrarnos
en Mailgun para obtener una cuenta gratuita, y con ello tener derecho a 10000
correos mensuales, lo cual resulta más que suficiente para PhysicalTrello.
35
Uno de los servicios interesantes de Mailgun es que nos permite crear rutas de
envío. Es decir una vez registrados como usuarios de MailGun y obteniendo una
dirección de correo de su dominio, podemos enviar correos a esta dirección y en
MailGun filtrar correos electrónicos y configurar una determinada acción para estos
correos filtrados. En el caso de PhysicalTrello, el filtro se realiza en base a la
descripción del campo asunto o subject. Los correos enviados a MailGun con el
asunto “trellocimat”, son filtrados y se aplica una acción, la cual consiste en enviar
vía POST la imagen recibida en el correo. En este caso, la imagen de un tablero
físico, a un script de PhysicalTrello, quien a su vez al recibir la imagen, la descarga
automáticamente en el servidor, la siguiente imagen ilustra la creación de una ruta
en MailGun:
Figura 18: Ejemplo de rutas en Mailgun - http://www.mailgun.com
4. Resultados
Después de explicar lo que es un Mashup y conocer la arquitectura de
PhysicalTrello, se tienen los elementos necesarios para poder caracterizar
PhysicalTrello como un Mashup de acuerdo al cubo de Mashups. Por lo tanto el
objetivo de este capítulo es explicar primeramente por qué PhysicalTrello es un
Mashup, cuáles son sus componentes de Mashup que lo clasifican como Mashup, y
terminaremos explicando en qué dimensiones del cubo de Mashups encajan y por
qué.
36
En el corazón de cualquier técnica de composición, como por ejemplo los Mashups,
existen elementos atómicos, en este caso los componentes de Mashup. A la
composición en sí la llamamos Mashup. Además como vimos en nuestra definición
de una Mashup para que una aplicación pueda ser considerada como tal, es
necesario que utilice al menos dos componentes disponibles en la Web que a su
vez pueden ser de datos, lógica o de interfaz de usuario. Pues bien, en el diagrama
UML de componentes que vimos en el capítulo anterior pudimos observar que
PhysicalTrello está formado por varios componentes y dos de estos componentes
son APIs, estos componentes son el API de Trello y el API de Mailgun, a
continuación explicamos qué tipo de componentes de Mashup son estas dos APIs:
Componentes de Mashup
En el capítulo dos “Antecedentes” se explicó las características de los Mashups.
Para entrar en contexto, vale la pena recordar la definición de qué es un
componente de Mashup.
“Un componente de Mashup es cualquier segmento de datos, lógica de aplicación
y/o interfaz de usuario que puede ser reutilizada y que es accesible ya sea local o
remotamente” (Daniel & Maristella, 2014).
La siguiente figura muestra las características que tiene un componente de Mashup
sin importar de qué tipo sea:
Figura 19: Características de un componente de Mashup (Daniel & Maristella, 2014)
Basado en estas características vamos a explicar a continuación los componentes
de Mashup que integran PhysicalTrello.
37
4.1 Caracterización de componentes del Mashup de PhysicalTrello.
A pesar de que PhysicalTrello fue desarrollado usando varios componentes, es
importante mencionar que no todos son componentes de Mashup, de hecho solo
dos de esos componentes son considerados componentes de Mashup, dichos
componentes son el API de Trello, y el API de Mailgun. A continuación vamos a ver
con más detalle estos componentes.
API de Trello
El API de Trello es un servicio web tipo RESTful que ofrece la aplicación Trello y es
parte fundamental de PhysicalTrello ya que es el medio por el cual se extrae
información acerca de los tableros virtuales para poder imprimirlos y formar el
tablero físico (archivos PDFs) y posteriormente, por medio de la misma API
actualizar el tablero virtual en Trello.
Por ello, podemos concluir que el API de Trello en nuestro Mashup es un tipo de
componente de Mashup de datos. Los componentes de datos proporcionan acceso
a los datos vía interfaces y por lo general las fuentes de datos pueden ser de
cualquier tipo, por ejemplo estáticas (RSS, XML, JSON) o pueden ser dinámicas
como una consulta a una base de datos; los tipos más comunes son los llamados
Web Services que son usados como fuentes de datos. Al usar un componente de
datos, es obligación del desarrollador administrar la integración de dicha fuente de
datos del componente con la aplicación que se está desarrollando.
Vamos a hacer énfasis en la frase “datos vía interfaces”. El uso de interfaces en
este contexto significa que el componente puede estar usando como
almacenamiento primario bases de datos relacionales, NoSQL, archivos planos,
etc., y puede estar programado en cualquier lenguaje de programación. Sin
embargo esto es transparente para los desarrolladores ya que por lo general este
tipo de componentes de datos siempre nos regresa la información solicitada en
formatos de archivos que son de uso estándar para el intercambio de información y
por lo general estos formatos de archivos son compatibles con la mayoría de los
lenguajes de programación. Los ejemplos más comunes de estos formatos son
38
archivos XML, JSON, CSV o incluso archivos de texto plano con ciertos formatos.
En el caso del API de Trello la información siempre es enviada en formato JSON.
Ya sabemos cuáles son las características de un componente de Mashup. A manera
de resumen del API de Trello, la Tabla 3 muestra un resumen de todas las
características de este componente, así como una breve descripción de cada una
de ellas.
Característica ¿Tipo? ¿Por qué?
1. Tipo de componente Componente de
datos
Es un componente el cual es la
fuente de datos principal para
PhysicalTrello, ya que es de ahí
de donde se extrae la
información del tablero para
generar los archivos PDF.
2. Ubicación de
runtime(tiempo de
ejecución)
Remota La integración se hace en base
a intercambio de mensajes para
hacer solicitudes de datos de los
tableros y actualización de las
posiciones de las tarjetas, la
ejecución es entonces en los
servidores de Trello.
3. Modelo de
invocación
Invocación basada
en mensajes
Es una característica esencial
de las APIs, la interacción se
realiza a través de mensajes
siguiendo ciertos protocolos y
formato de mensajes.
4.Estilo de transmisión Síncrono Es necesario esperar a que
termine una solicitud de un
recurso al API para poder
realizar otra.
5.Formato (Media type) Tipo de medio
discreto (JSON)
La respuesta es entregada de
forma completa por medio del
API, es decir, no es
proporcionada en partes. Lo que
39
es entregado es una respuesta
en formato JSON.
6. Modelo de
Instanciación
Stateless El componente es instanciado
únicamente por el tiempo
necesario para obtener la
respuesta o datos, característica
esencial que distingue a los
RESTful Web Services de
SOAP.
7. Orden de invocación Con orden de
restricción
Las operaciones en la API
deben llevar un cierto orden, por
ejemplo autentificarse antes de
hacer una solicitud de datos.
Tabla 3: Caracterización del componente de Mashup - API de Trello
Por lo tanto, el API de Trello es un componente de datos y es nuestro primer
componente de nuestra Mashup PhysicalTrello.
Mailgun
Otro componente de nuestra Mashup es el API de Mailgun y la función principal de
este componente en PhysicalTrello es extraer las fotografías de los tableros físicos
que son enviadas vía correo electrónico a una cuenta predeterminada
proporcionada por MailGun. Esta cuenta de correo está configurada de tal forma
que Mailgun hace filtros de correo, en caso de que llegue un correo electrónico con
el asunto “trellocimat” el API de MailGun enviará vía POST esta imagen a
PhysicalTrello, y PhysicalTrello recibirá y descargará la imagen a un directorio en
el servidor para que posteriormente sea procesada por otros componentes de la
aplicación para sincronizar las posiciones de las tarjetas del tablero físico con el
virtual en Trello.
De la misma forma como se caracterizó el API de Trello lo haremos con el API de
Mailgun destacando las principales características de dicho componente. La
siguiente tabla muestra cada una de estas características.
Característica ¿Tipo? ¿Por qué?
40
1. Tipo de componente Componente de
lógica
Es un componente de lógica,
puesto que el API de Mailgun
hace todo el trabajo de forma
interna, es decir, recibe los
correos, aplica los filtros de
correos, extrae las imágenes
adjuntas y las manda vía POST
al script de PHP de
PhysicalTrello que hace la
descarga de la imagen al
servidor. El usuario lo único que
hace es enviar un correo.
2. Ubicación de
runtime(tiempo de
ejecución)
Remota El procesamiento de correos se
da en la parte del servidor de
MailGun.
3. Modelo de
invocación
Invocación basada
en eventos.
El API siempre está en espera
de llegada de correos
electrónicos para ser
procesados. En este caso el
evento es cuando llega un
correo electrónico con un filtro
configurado, para PhysicalTrello,
el filtro es el contenido del
campo asunto.
4.Estilo de transmisión Asíncrona Al enviar el correo a MailGun no
es necesario esperar una
respuesta.
5.Formato (Media type) Tipo de medio
discreto (Image)
La información en formato JSON
es entregada de transmisión
completa por medio del API, es
decir, no es proporcionada en
partes. Lo que es entregado es
una imagen que puede ser jpg,
png, etc.
6. Modelo de
Instanciación
Stateless El componente es instanciado
únicamente por el tiempo
41
necesario para enviar el correo.
7. Orden de invocación Con restricciones La ejecución o solicitud de
operaciones de la API debe
llevar un orden, por ejemplo no
se puede consultar un buzón sin
antes identificarse.
Tabla 4: Caracterización del componente de Mashup - API de Mailgun
Por lo tanto deducimos que Mailgun es un componente de lógica.
Hasta este punto ya explicamos los dos componentes principales de nuestra
Mashup. Se explicaron las características de cada componente, por lo tanto si
recordamos en nuestra definición de lo que es un Mashup, podemos deducir que
PhysicalTrello es un Mashup ya que hace uso de dos componentes usuales vía
WEB, además nuestra aplicación está entregando al usuario un valor agregado el
cual consiste en poder tener una aplicación híbrida que permite tener sincronizado
un tablero virtual Kanban (Trello) con su respectivo tablero físico.
Bien, ya caracterizamos los dos componentes de Mashup de PhysicalTrello, ahora
toca el turno de caracterizar el Mashup en sí.
4.2 Caracterización del Mashup.
Retomando el cubo de Mashups (Daniel & Maristella, 2014) y la caracterización de
los componentes API de Trello y MailGun, ya podemos identificar en cuáles
dimensiones se encuentra PhysicalTrello, estos están en color rojo, y se ilustran
con la siguiente imagen:
42
Figura 20: Clasificación del Mashup PhysicalTrello
Como podemos observar en el cubo de Mashups, PhysicalTrello usa componentes
de lógica y datos, y es por ello que lo clasificamos con un Mashup Híbrido, dado que
una característica de un Mashup Híbrido, es precisamente la combinación de
componentes de distinta composición. Aquí está la definición de una Mashup
Híbrido:
Una Mashup híbrido es aquel que integra componentes de Mashup en las diferentes
capas de una aplicación, es decir, capa de datos, lógica y presentación. Dentro de
los Mashups híbridos existen 4 tipos, los cuales son combinaciones de las diferentes
capas:
● Mashups (datos/lógica)
● Mashups (datos/UI)
● Mashups (lógica/UI)
● Mashups universales: Este tipo de Mashups distribuyen la lógica de
integración en las 3 capas. Datos, lógica, UI.
En resumen, podemos concluir que PhysicalTrello es un Mashup híbrido debido a
que usa dos componentes (APIs) de distinta composición:
● API de Trello: un componente del cual estamos usando sus datos.
● MailGun: componente que PhysicalTrello usa para envío y recepción de las
imágenes de los tableros, estamos usando su lógica, siendo este un
43
componente en el dominio de Telecomunicaciones, pero clasificado como de
lógica respecto a la dimensión de composición.
5. Discusión y opiniones
Ventajas de haber implementado PhysicalTrello como Mashup
Sin duda el haber utilizado el componente de Mashup de datos “API de Trello”, y el
componente de Mashup de lógica “API de MailGun”, además de otras utilerías que
no son como tal componentes de Mashup, por ejemplo, TCPDF (Tecnick.com LTD,
2015) y JimFlowKlopfer de JimFlow (Jimdo, 2015), entre otros, dieron vida al
Mashup PhysicalTrello. Esta aplicación que se distingue de un desarrollo tradicional
por la reutilización de componentes en lugar de codificar cada uno de ellos, nos ha
dado las siguientes ventajas:
● Una disminución considerable del tiempo de implementación debido a la
reutilización de componentes ya probados y en operación.
● Uso de componentes exitosos, que son usados por millones de personas, lo
cual nos da una garantía de estabilidad, confiabilidad y desempeño en
PhysicalTrello.
● El uso de la API de Trello y Trello en sí, nos evitó el tener que desarrollar una
aplicación de gestión de proyectos similar a Trello, es decir un clon de Trello.
● Al usar el API de MailGun, evitamos el tener que configurar nuestro propio
servicio de correo.
Desventajas en el desarrollo de Mashups
Sin embargo, aunque son grandes las ventajas de reutilizar componentes para crear
nuevas aplicaciones que ofrecen un nuevo valor al usuario final, existen ciertas
desventajas y riesgos implícitos en ello, ya que de cierta manera estamos usando
cajas negras. Esto es, no tenemos el control total de dichos componentes y
dependemos de software fabricado por terceros. Entre las posibles desventajas que
en general para todo Mashup existen, podemos listar las siguientes:
● Poca o nula información del componente. En el caso del uso de la API de
Trello, se encontró que existe escasa información para implementar la
autenticación con el protocolo OAuth 2.0, por lo cual debió recurrirse a otras
44
fuentes como lo es la documentación de la API de LinkedIn (LinkedIn Corp,
2015).
● No siempre los datos que necesitamos son facilitados por el propietario de la
aplicación en forma de servicios como son APIs, Servicios Web, RSS u otros,
por lo cual se debe recurrir a técnicas de web scraping (Extracción de datos
de páginas Web mediante herramientas automatizadas o de forma semi
automática) sobre la aplicación de la cual deseamos sus datos y se corre el
riesgo de que la estructura de estos datos cambie.
● Continuando con el tema de Web Scraping, es importante mencionar que
pueden existir riesgos legales al estar extrayendo datos sin el consentimiento
del propietario de la página o aplicación Web (Distil, Inc, 2015).
● Al reutilizar componentes de terceros, resulta complicado garantizar al cliente
o usuario final la disponibilidad, confiabilidad y desempeño de la aplicación
creada, ya que al no tener el control total de los componentes, dependemos
de los proveedores de estos servicios.
● Una forma de hacer Web Scraping para recuperar información de páginas
web es utilizar un parser de XML, que sea compatible con el modelo de
objeto de documento (DOM) de XML. Sin embargo, trabajar con el DOM de
una página web requiere conocimientos avanzados de tecnologías como
HTML, Javascript, y CSS, jQuery, etc., con lo cual esto puede significar un
obstáculo para algunos usuarios. En el caso de Trello el DOM de los tableros
digitales no es muy intuitivo, ya que está formado por varios archivos CSS
con lo cual es difícil localizar dónde se encuentra cada elemento de la página,
sin embargo se tuvo que analizar a detalle usando principalmente CSS y
jQuery para modificar el DOM para así lograr insertar los botones que
permiten al usuario imprimir los tableros digitales.
5.1 Hallazgos
Al implementar PhysicalTrello reutilizando los componentes API de Trello y API de
MailGun, inicialmente se desarrolló una aplicación propia como lo ilustra la siguiente
imagen. Mediante la autenticación con el protocolo OAuth 2.0 al API de Trello, se
obtenían los tableros del usuario y se tenía acceso a ellos para generar la impresión
de las tarjetas QR (Denso Wave Incorporated, 2015) para formar el tablero físico.
45
Figura 21: Aplicación Web de PhysicalTrello
Nota: PhysicalTrello actualmente se encuentra en un servidor de desarrollo la cual
se localiza en la siguiente dirección IP: http://104.131.125.114/
Sin embargo se observó que sería más amigable para el usuario que las opciones
de impresión de códigos QR (Denso Wave Incorporated, 2015) estuvieran dentro de
la misma página de Trello.
Por ello se decidió crear una extensión actualmente para Firefox, la cual una vez
concedidos los permisos del usuario para instalar dicha extensión, se insertan los
iconos con las opciones de impresión de PhysicalTrello directamente en la interfaz
de Trello, como lo muestra la Figura 22, enriqueciendo aún más la amplia
funcionalidad de Trello.
46
Figura 22: PhysicalTrello incrustado en la interfaz de Trello
Las extensiones (también conocidas como complementos o plug-in) son pequeños
programas que añaden nuevas características o funcionalidades a los navegadores
de internet (aspecto visual del navegador). Además de eso, las extensiones pueden
ser creadas específicamente para agregar funcionalidades a un sitio en especial,
como en nuestro caso la interfaz de Trello. Hay extensiones por ejemplo que
permiten modificar el aspecto de impresión, filtrar contenido, administrar cookies,
borras historiales, etc. La funcionalidad de estas extensiones por lo general es solo
código del lado del cliente. Sin embargo, existen otras extensiones que desde su
lógica interna, hace uso de componentes web como por ejemplo APIs o Web
Services.
Un claro ejemplo de este tipo de extensiones es PhysicalTrello ya que modifica la
interfaz de Trello para agregar los controles como se vio en la Figura 22. Para que
quede más claro el concepto, la Figura 23 muestra la arquitectura de la extensión.
47
Figura 23: Arquitectura de la extensión de PhysicalTrello
Esta inclusión de opciones propias dentro de una aplicación de terceros (en este
caso una extensión para el navegador) y que además hace uso de otro componente
de Mashup de forma interna la denominamos “Mashups con inyección de
interfaz de usuario”. Esto se logró gracias a las herramientas actuales que nos
facilitan el acceso al DOM de las páginas, más en concreto del framework de
JQuery (The jQuery Foundation, 2015). Aunque si bien esta técnica de inyección de
interfaz de usuario o inyección de controles propios dentro de páginas web de
terceros no es nueva, pues ya existen aplicaciones que lo hacen como los que
veremos a continuación, no se encontró en las fuentes literarias consultadas una
forma de nombrarlos, es por ello que nos tomamos la libertad de darles el nombre
de “Mashups con inyección de interfaz de usuario”. A continuación se hace una
breve descripción de este nuevo tipo de aplicaciones similares que realizan
inyección de interfaz de usuario:
● Burndown for Trello (Colombo, 2015) es una aplicación que integra Trello con
Scrum y nos permite generar una gráfica BurnDown del tablero seleccionado
siendo esta gráfica especialmente útil para quienes implementan Scrum en la
administración ágil de sus proyectos. BurnDown for Trello, al igual que
PhysicalTrello, se instala como extensión en el navegador y una vez
instalado, al abrir Trello aparece el icono de Burndown For Trello. Existe
versión gratuita y de paga.
● Scrum For Trello (Q42, 2015), al igual que PhysicalTrello y BurnDown For
Trello, se instala como extensión en el navegador y nos permite agregar
estimaciones de tiempo en cada tarjeta del tablero de Trello al hacer clic en la
48
descripción de las tarjetas. Aparecerá una lista de botones con números de
Fibonacci que nos permitirá asignar la estimación en puntos de historia, los
cuales aparecen en cada tarjeta y a la vez aparece la sumatoria por
columna. Scrum For Trello está disponible para Chrome, Firefox y Safari, y
también se puede integrar con BurnDown For Trello.
Además de los ejemplos mencionados anteriormente los cuales son similares a
PhysicalTrello (extensiones para navegadores), existe otra forma de enriquecer
aplicaciones por medio de la inyección de interfaz de usuario y de hecho estas
tecnologías ya están establecidas como plataformas. Algunos ejemplos de estas
plataformas son las siguientes:
● Sales Force: La plataforma Sales Force (Salesforce.com Inc, 2015) permite
a las empresas convertir sus ideas en aplicaciones de una forma rápida
permitiendo interconectar a sus empleados, clientes, socios, y los productos
de una forma totalmente innovadora todo desde la nube. Entra dentro de la
categoría de programas CRM, Customer Relationship Management. El
punto fuerte de la plataforma está en que existen miles de aplicaciones
creadas por proveedores de software independientes disponibles en
appexchange.salesforce.com (Salesforce.com Inc, 2015) y que pueden ser
integradas directamente en sus aplicaciones. Otra forma de enriquecer sus
aplicaciones es que los desarrolladores disponen de acceso instantáneo a
marcos avanzados de desarrollo, APIs, datos de clientes, recursos de
geolocalización, etc., todo esto de forma inmediata, de este modo pueden
dedicarse a crear extraordinarias interfaces de usuario en cualquier idioma en
lugar de perder tiempo con los servicios de infraestructura y gestión interna.
Los analistas empresariales también pueden crear aplicaciones específicas
para sus departamentos desde cualquier lugar con pocos clics. De esta forma
Sales Force ofrece todo un ecosistema en la nube la cual permite convertir
sus ideas en aplicaciones.
● Google Drive: La plataforma Drive (Google, 2015) de Google ofrece a los
desarrolladores un grupo de APIs junto con librerías cliente, ejemplos
específicos para lenguajes de programación y documentación para ayudarles
a desarrollar aplicaciones que puedan ser integradas con Drive. La
funcionalidad principal de las aplicaciones Drive es para descargar y subir
archivos en Google Drive. Sin embargo la plataforma Drive proporciona
mucho más que solo almacenamiento. Con respecto al contexto que nos
49
interesa, es decir inyección de interfaz de usuario, la plataforma Drive permite
a los usuarios habilitar aplicaciones externas para que puedan ser integradas
directamente en Google, de esta forma, los usuarios usarán un modelo
basado en IDs de archivos en vez de la tradicional jerarquía por medio de
carpetas para conectar con dichas aplicaciones y enlazar sus archivos
asociados. La siguiente imagen muestra algunos ejemplos de aplicaciones
que podemos integrar dentro de nuestra plataforma Drive. Ejemplo: Visores
de archivos de Autocad, aplicaciones para edición de fotos, herramientas
para diseñar prototipos, etc.
Figura 24: Integración de aplicación de terceros en Google Drive
● SharePoint: SharePoint (Microsoft , 2015) es usado por las organizaciones
para crear sitios web. Se puede usar como un lugar seguro donde almacenar,
organizar y compartir información desde prácticamente cualquier dispositivo,
así como acceder a ella. Lo único que se necesita es un explorador web.
SharePoint cuenta con un componente llamado Microsoft SharePoint
Designer (SPD) el cual se centra en el diseño y la personalización de los
sitios web, e incluye plantillas SharePoint de sitio específicas, además
conserva características de FrontPage como componentes web, bases de
datos, marquesinas, contadores de visitas, barras de navegación, mapas de
inserción, etc. El SPD es quien permite la inyección de interfaz de usuario.
A manera de resumen de los hallazgos encontrados (Mashups con inyección de
interfaz de usuario) durante el desarrollo de PhysicalTrello y previamente
ejemplificado con las extensiones para navegadores y plataformas como Sales
Force, Google Drive y SharePoint, se propone agregar un nuevo tipo de
50
componente en la categoría de Composición del cubo de Mashups, llamado
Mashup con inyección de interfaz de usuario, dichos Mashups no son
contemplados en la bibliografía citada para el desarrollo de PhysicalTrello. Por lo
tanto, el cubo de Mashups quedaría de la siguiente forma.
Figura 25: Cubo de Mashups con el tipo de composición “Inyección de Interfaz de Usuario”
5.2 Recomendaciones
Como describimos anteriormente existen numerosas ventajas orientadas al
desarrollo de Mashups. La principal ventaja y más significativa es la rapidez de
desarrollo mediante la reutilización de componentes (APIs por ejemplo) que ya
están probados en cuanto a funcionalidad se refiere.
Para terminar este capítulo, se recomienda a todos los desarrolladores, en especial
a aquellos que desarrollan aplicaciones web a que hagan uso de componentes web
como APIs, Web Services, etc., para agilizar el proceso de desarrollo, así como la
calidad de sus aplicaciones, y de esta forma crear Mashups fáciles de usar para los
usuarios finales.
A todos aquellos interesados en sumergirse en el mundo del desarrollo de Mashups
se recomienda lo siguiente:
51
● Como primer paso echar un vistazo al sitio programmableweb.com (Berlind,
2015) para ver toda la variedad de componentes que están listos para ser
usados. Este sitio es un directorio líder en el área de APIs y Mashups,
alimentado por los propios usuarios, en el cual podremos encontrar una gran
variedad de APIs así como Mashups e importantes estadísticas que nos
ayudarán a seleccionar alguna.
● Continuando con la selección de APIs a utilizar, es recomendable hacer una
evaluación de su arquitectura, ya que esto nos garantiza el usar una API de
buena calidad, para ello se recomienda evaluar el API a usar basándonos en
el Modelo de Madurez de Richardson RMM (desarrollado por Leonard
Richardson) (Fowler, Richardson Maturity Model, 2010), el cual califica en
cuatro niveles de madurez a las APIs (0 - 3), por lo cual se recomienda que
se seleccionen aquellas APIs que al menos se ubiquen en el nivel 2.
● Es recomendable también hacer una evaluación de usabilidad de la API, lo
cual es importante para todo desarrollador, ya que facilitará su trabajo al
integrarla al Mashup, para ello podemos seguir la guía de evaluación de
usabilidad de M. Jacques (Jacques, 2004), en la cual se evalúan aspectos
importantes como lo es la retroalimentación en caso de errores.
● Otro aspecto importante a considerar es la calidad de la documentación de la
API, ya que esto nos será de mucha ayuda al momento de usarla en el
Mashup.
● Estabilidad y Performance, como se había mencionado el usar componentes
de terceros implica algunos riesgos ya que no tenemos el control total y para
poder ofrecer el servicio ya sea interno o externo del Mashup. Es importante
conocer qué tan estable es la API, así como su rendimiento, para ello como
primer paso es investigar si el API tiene una página de estatus, es decir que
sepamos si el API está o no activa, y qué tan frecuente falla, en caso de no
tener una página de estatus, podemos usar herramientas online como
IsItDownRightNow (isitdownrightnow.com, 2015), StatusPage.io (Dogwood
Labs, 2015), ApiMetrics (APImetrics Inc, 2015) para monitorearla y así
conocer su estabilidad y rendimiento, aspectos importantes para determinar
que garantía de servicio podemos obtener con nuestra Mashup o bien que
garantía de servicio podemos ofrecer al cliente o usuario final.
52
6. Conclusiones y trabajo futuro
La Web 2.0 y las Web APIs han dado cabida a una nueva forma de composición de
aplicaciones llamada Mashup. La importancia de las Mashups se puede constatar
en programmableweb.com (Berlind, 2015) donde hasta el momento (Junio de
2015) se tienen registradas 13, 519 APIs y 7,851 Mashups. Lo más importante a
considerar es que la cantidad de Mashups está en constante crecimiento, aunque si
bien se ha reducido el registro de Mashups en el sitio programmableweb en los años
2014 y 2015, esto podemos atribuirlo a que los usuarios ya no están registrándolos
como lo hacían cuando inicio este fenómeno, ya que esta práctica se ha convertido
en algo natural.
El Mashup tiene varias características distintivas, dentro de ellas destacamos dos:
● El Componente de Mashup reside en servidores fuera del control de
los que hacen el Mashup.
● La composición también puede incluir elementos de la interfaz de
usuario.
PhysicalTrello nos llevo a crear una Mashup donde se mezcla Trello.com para la
interface de usuario, Mailgun.com para la comunicación y el valor agregado de los
propios componentes, lo cual reveló muchas de las ventajas y desventajas del
desarrollo de Mashups.
Las ventajas encontradas fueron principalmente:
● Velocidad de desarrollo: Al no tener que desarrollar desde cero muchos de
los componentes.
● Componentes de alta calidad: porque las empresas que los desarrollan son
serias y los componentes están usados y validados por miles de otros
usuarios.
● Disminuye el acoplamiento: Ya que con las Web APIs solo se puede
programar a la interfaz, no se puede romper el encapsulamiento.
Las desventajas encontradas fueron principalmente:
● APIs no documentadas lo suficiente.
53
● Falta de control en los cambios del API.
Florian Daniel (Daniel & Maristella, 2014) y su equipo han trabajado muchos años
en el ámbito de las APIs y las clasifican en tres dimensiones: Entorno, Dominio y
Composición.
Figura 26: Cubo de Mashups - Florian Daniel
De acuerdo a esas dimensiones PhysicalTrello es un Mashup Híbrido con
componentes en las siguientes áreas:
Figura 27: Clasificación del Mashup PhysicalTrello
54
Sin embargo también se encontró otro tipo de Mashup que con la información que
se tiene disponible en este momento no se ha reconocido en la literatura. A este tipo
de Mashup se le ha llamado Inyección de Interfaz de Usuario.
Este tipo de Mashups se caracterizan porque cambian la Interfaz de usuario de un
componente o página web, de una manera que los autores originales no habían
considerado, y se hace utilizando Plugins del navegador web que modifican la
aplicación que ya existía.
Se encontró evidencia de este tipo de composición en varios plugins exitosos, como
son los siguientes:
● BurnDown For Trello
● Scrum For Trello
Respecto a los objetivos establecidos al inicio de esta tesis, se concluye lo
siguiente:
• El primer objetivo establecido consistió en “Explicar en qué consiste el
nuevo tipo de aplicaciones denominadas Mashups, sus principales
características y cómo se componen”. Dado que en capítulo 2
Antecedentes se explica los lo que son las a aplicaciones denominadas
Mashups y sus principales características, este objetivo fue logrado.
• El segundo objetivo establecido consistió en “Crear una herramienta que
permita y facilite combinar los tableros tipo Kanban físicos y digitales
basada en Trello”. En el capítulo 3 se explica cómo se desarrollo la
aplicación a la cual se le dio el nombre de PhysicalTrello. Por lo tanto este
objetivo también se logró.
Finalmente se concluye que las ventajas de desarrollo de los Mashups son
demasiado grandes para ser ignoradas, sin embargo las desventajas también son
importantes y se necesitan más estudios de administración de riesgos en el área
antes de que una empresa decida utilizar un Mashup.
55
Trabajo Futuro
En cuanto a PhysicalTrello creo que se necesita seguir trabajando en los siguientes
aspectos:
● Creación del plugin de PhysicalTrello para Chrome, Safari e Internet Explorer.
aumentando con ello la base de usuarios potenciales.
● Publicación del plugin de Firefox en la sección de complementos de Mozilla.
● Creación de aplicaciones móviles para PhysicalTrello y así automatizar su
envío de información.
En lo referente a las Mashups creo que se requieren más estudios en los siguientes
aspectos:
● Estudiar a mucha mayor profundidad los Mashups de Inyección de Interface
de Usuario para caracterizarlas y catalogar mejor su importancia.
● Administración de riesgos de desarrollo y obsolescencia de APIs. ¿Qué hacer
cuando un API cambia o es retirada?
● Cómo predecir la confiabilidad de la composición del Mashup.
56
7. Referencias
Alonso, G., Casati, F., Kuno, H., & Machiraju, V. (2003). Web Services Concepts,
Architectures and Applications.Berlin: Springer.
Atlassian. (20 de 05 de 2015). Agile Cards for JIRA. Obtenido de
https://marketplace.atlassian.com/plugins/com.spartez.scrumprint.scrumplugin
APImetrics Inc. (2015). APImetrics - Intelligent API Monitoring. Recuperado el 05 de
03 de 2015, de http://apimetrics.io/
Berlind, D. (2015). Programmableweb.com. Recuperado el 06 de 02 de 2015, de
http://programmableweb.com
Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., y
otros. (2007). SOAP Version 1.2. Recuperado el 04 de 07 de 2015, de
http://www.w3.org/TR/soap/
Colombo, S. (2015). Burndown for Trello. Recuperado el 10 de 02 de 2015, de
https://www.burndownfortrello.com
Daniel, F., & Maristella, M. (2014). Mashups Concepts, Models and
Architectures.Milano, Italy: Springer.
Denso Wave Incorporated. (2015). QR code. Recuperado el 02 de 06 de 2015, de
http://www.qrcode.com/en/about/#featurePage1
Distil, Inc. (2015). Is Web Scraping Illegal? Depends on what the meaning of the
wordl Is. Recuperado el 20 de 04 de 2015, de
http://resources.distilnetworks.com/h/i/53822104-is-web-scraping-illegal-depends-on-
what-the-meaning-of-the-word-is-is
Dogwood Labs. (2015). StatusPage.io. Recuperado el 17 de 04 de 2015, de
https://www.statuspage.io
Ferrara, E., Fiumara, G., & Baumgartner, R. (2012). Web Data Extraction,
Applications and Techniques: A Survey.Obtenido de
http://www.emilio.ferrara.name/wp-content/uploads/2011/07/survey-csur.pdf
Fowler, M. (18 de 03 de 2010). Richardson Maturity Model. Recuperado el 21 de 02
de 2015, de http://martinfowler.com/articles/richardsonMaturityModel.html
Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling
Language. Addison-Wesley Professional.
Google. (2015). Drive REST API. Recuperado el 15 de 06 de 2015, de
https://developers.google.com/drive/web/about-sdk
Google Inc. (2015). Tutorial OAut. Recuperado el 15 de 02 de 2015, de
https://developer.chrome.com/extensions/tut_oauth#requirements
57
IBM. (2015). CICs Family. Recuperado el 07 de 07 de 2015, de http://www-
01.ibm.com/software/htp/cics/
IBM. (2015). WebSphere MQ. Recuperado el 07 de 07 de 2015, de http://www-
03.ibm.com/software/products/es/ibm-mq
isitdownrightnow.com. (2015). Is it down right now? Recuperado el 14 de 03 de
2015, de http://www.isitdownrightnow.com/
Jacques, M. (21 de 11 de 2004). API Usability: Guidelines to improve your code
ease of use. Recuperado el 18 de 02 de 2015, de
http://www.codeproject.com/Articles/8707/API-Usability-Guidelines-to-improve-your-
code-ease
Jimdo. (02 de 02 de 2015). JimFlow. Digitalize your Boards. Recuperado el 2015, de
http://jimflow.jimdo.com
LinkedIn Corp. (2015). LinkedIn. Recuperado el 20 de 01 de 2015, de
http://www.linkedin.com
Microsoft . (2015). ¿Que es SharePoint? Recuperado el 14 de 06 de 2015, de
https://support.office.com/es-es/article/%C2%BFQu%C3%A9-es-SharePoint-
97b915e6-651b-43b2-827d-fb25777f446f?ui=es-ES&rs=es-ES&ad=ES
Microsoft. (2015). Microsoft Transaction Server. Recuperado el 07 de 07 de 2015,
de https://msdn.microsoft.com/en-us/library/aa480405.aspx
Muhl, G., Fiege, L., & Pietzuch, P. (2006). Distributed Event-based Systems. Berlin,
Heidelberg: Springer-Verlag.
Oracle. (2015). Java Remote Method Invocation. Recuperado el 05 de 06 de 2015,
de http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138781.html
Oracle. (2015). Oracle Tuxedo. Recuperado el 07 de 07 de 2015, de
http://www.oracle.com/technetwork/middleware/tuxedo/overview/index.html
Q42. (2015). Scrum for Trello. Recuperado el 08 de 01 de 2015, de
http://scrumfortrello.com/
Rackspace. (2015). The Email Service For Developers. Recuperado el 02 de 02 de
2015, de http://www.mailgun.com
Rasmussen, L. (27 de 07 de 2005). Keynote: Google Maps and Browser Support for
rich Web Applications. Sysdney, Australia.
Richardson, L., & Amundsen, M. (2013). RESTful Web APIs. O'Really Media.
Salesforce.com Inc. (2015). Salesforce. Recuperado el 25 de 05 de 2015, de
http://www.salesforce.com/mx/
Spolsky, J. (2015). Venture beat. Recuperado el 21 de 04 de 2015, de
http://venturebeat.com/2015/04/21/task-management-app-trello-now-boasts-8m-
users
58
Tanenbaum, A. S. (1994). Distributed Operating Systems. Prentice Hall.
Tecnick.com LTD. (15 de 01 de 2015). TCPDF - PHP Class for generating PDF
Documents. Recuperado el 2015, de http://www.tcpdf.com
The jQuery Foundation. (2015). Category: DOM Element Methods. Recuperado el
14 de 03 de 2015, de https://api.jquery.com/category/miscellaneous/dom-element-
methods/
Trello, Inc. (2015). Trello. Recuperado el 11 de 03 de 2015, de https://trello.com
59
8. Anexos
8.1 Anexo A
8.1.1 Instalación y configuración
En este anexo se explica de manera detallada la instalación y configuración de cada
una de las herramientas necesarias para hacer el despliegue de la aplicación
PhysicalTrello. Se asume que ya se cuenta con una distribución Linux Ubuntu
instalada.
Instalación del servidor LAMP (Linux Apache Mysql PHP)
Ejecute los siguientes comandos desde la una consola:
● Instalar Apache
$ sudo apt-get update
$ sudo apt-get install apache2
● Instalar PHP
$ sudo apt-get install php5
● Instalar Mysql
$ sudo apt-get install mysql-server php5-mysql
$ sudo apt-get install libapache2-mod-php5 php5-mcrypt
$ sudo apt-get install php5-curl
Instalar Phyton
La distribución Linux Ubuntu incluye por default la instalación de Python, sin
embargo es necesario que se verifique que exista, lo cual se puede hacer con el
siguiente comando:
$ python
$ python3
En caso de existir, le mostrará el prompt de python similar a lo siguiente:
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GC 4.8.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information
60
>>
Si no existe, instálelo con el siguiente comando:
$ sudo apt-get install python3.1
o bien si lo prefiere
$ sudo apt-get install python2.7
Para este proyecto necesitamos la versión 2.6 o superior, así como los siguientes
módulos:
phython-pip (http://packages.debian.org/squeeze/python-pip)
python-zbar (http://packages.debian.org/squeeze/python-zbar)
python-imaging (http://packages.debian.org/squeeze/python-imaging)
Dichos paquetes pueden instalar con los siguientes comandos desde consola de
Linux:
$ sudo apt-get install python-pip
$ sudo apt-get install python-zbar
$ sudo apt-get install python-imaging
Habilitar puerto 80
Es necesario que en su sistema tenga abierto el puerto 80, para ello puede
verificarlo con el comandoufw (uncomplicated firewall) el cual viene siendo la
herramienta de configuración de firewall por defecto de Ubuntu o bien con la utilería
de su preferencia, para este caso describiremos el uso del comando Linux ufw.
En caso de no tener instalado ufw, instalarlo de la siguiente forma:
$ sudo apt-get install update
$ sudo apt-get install ufw
Para saber el estatus actual del firewall
$ sudo ufw status
Arrancar firewall
$ sudo ufw enable
Abrir Puerto 80
$ sudo ufw allow 80
61
Para verificar apertura del puerto 80, puede hacerlo con
$ sudo ufw status
Instalación del proyecto PhysicalTrello
Ahora que ya tenemos nuestro ambiente preparado, puede descargar el proyecto
PhysicalTrello, para ello solo es necesario que descargue la carpeta PhysicalTrello
de la siguiente ruta, y copiarlo dentro del directorio raíz de apache.
http://rutadeproyectofuentephysicaltrello
Compilación de JimFlowKlopfer
Una vez descargada la aplicación PhysicalTrello, es necesario que se compile la
carpeta jimflow/JimFlowKlopfer, para ello dentro de una consola de Linux, situarse
dentro de la carpeta jimflow del proyecto y ejecutar el siguiente comando, el cual
compilara el contenido de JimFlowKlopfer.
$ pip install JimFlowKlopfer/
Directorio FTP_IMPORT_DIR y permisos
Necesitamos una carpeta para poder recibir las imágenes de los tableros, esta
carpeta ya existe dentro del proyecto PhysicalTrello, su nombre es
FTP_IMPORT_DIR , su propietario debe ser el usuario www-data, para ello sitúese
vía consola dentro del proyecto PhysicalTrello y teclee el siguiente comando:
$ chown www-data:www-data FTP_IMPORT_DIR
También es necesario darle permisos de escritura y lectura con el siguiente
comando:
$ chmod 755 FTP_IMPORT_DIR
Directorio JSON_EXPORT_DIR
Adicionalmente necesitamos otro directorio, el cual contendrá el archivo json el cual
se genera una vez que JimFlowKlopfer digitaliza las imágenes recibidas, este
directorio también existe ya en el proyecto PhysicalTrello con el nombre
FTP_IMPORT_DIR, y al igual que FTP_IMPORT_DIR, es necesario que el usuario
62
www-data sea su propietario y debe de tener permisos de lectura y escritura Vía
consola de Linux, sitúese dentro de la carpeta PhysicalTrello y teclee el siguiente
comando:
$ chown www-data:www-data FTP_EXPORT_DIR
Y para darle permisos de escritura y lectura, utilice el siguiente comando:
$ chmod 755 FTP_EXPORT_DIR
Cron para leer las imágenes recibidas
La recepción de imágenes de los tableros a digitalizar se estarán recibiendo en la
carpeta FTP_IMPORT_DIR, y son procesadas conforme se van recibiendo de
MailGun, para ello decidimos utilizar un cron el cual estará revisando continuamente
dicha carpeta y al detectar una imagen ejecutará el módulo JimFlowKlopfer, que a
su vez digitalizará la imagen recibida e identificará al usuario propietario del tablero,
el tablero, el número de listas y la posición de las tarjetas dentro de cada lista, todo
ello digitalizando los códigos QR existentes en la imagen, finalmente nos generará
un archivo json que será colocado en la carpeta FTP_EXPORT_DIR, para registrar
este cron es necesario usar el comandocrontab de Linux.
Abra una consola de Linux y ejecute el comando:
$ crontab –e
Se abrirá un editor de texto de Linux con el contenido actual de crontab, ahora hay
que registrar el cron que procesará las imágenes recibidas, esto lo podemos hacer
agregando la siguiente línea en el archivo que se abrió:
# JimFlowKlopfer se ejecutará cada minuto
*/1 * * * * python -m jimflowklopfer.__main__
/var/www/kanbanboard/FTP_IMPORT_DIR/
/var/www/kanbanboard/JSON_EXPORT_DIR/ >>
/var/www/physicaltrello/FTP_IMPORT_DIR/jimflow.log
Nota: Las últimas tres líneas deben de ir en una sola.
De manera general, el formato para registrar un cron es el siguiente:
# m h dom mon dow user command.
Donde:
● m corresponde al minute en que se ejecutara el script que va de 0 a 59
63
● h corresponde a la hora exacta, manejando el formato de 24 horas, 0
corresponde a las 12:00 y puede tener valores de 0 a 23.
● dom hace referencia al día del mes, por ejemplo se puede especificar 10
si quiere ejecutarlo cada día 10.
● dow significa el día de la semana, y puede ser numérico 0 a y donde 0 y
7 son domingo, o bien puede especificar las tres primeras letras del
día en inglés: mon,tue,wed,thu,fri,sat, su.
● user define el usuario que va a ejecutar el comando, puede ser root u
otro usuario que tenga permisos de ejecución del script.
● command se refiere al comando que será ejecutado o bien la ruta absoluta
de algún script a ejecutar.
Cron para actualizar el tablero digital
Adicionalmente necesitamos registrar otro cron para que una vez que
JimFlowKlopfer digitalice las imágenes recibidas y genere el archivo json en
FTP_EXPORT_DIR, se ejecute el script JSON_EXPORT_DIR/trelloCron.sh el cual
ejecutará el script de php de nombre moveCard.php que tomara el archivo json
generado, identificará al usuario propietario del tablero, consultara su token de
permisos de conexión a Trello en nuestra base de datos , se conectara a Trello vía
OAuth y de acuerdo a la posición de las tarjetas identificadas en la imagen
digitalizada por JimFlowKlopfer, actualizará el tablero digital.
Abrimos una consola Linux y tecleamos el comando crontab –e para abrir el archivo
que contiene los crones, y agregamos el siguiente:
# Update Trello boards every 1 minutes
*/1 * * * * /var/www/kanbanboard/JSON_EXPORT_DIR/trelloCron.sh
Una vez guardado el archivo, puede usar el comando crontab –l para verificar su
contenido.
Descripción del Script trelloCron.sh
Como pudimos observar en el registro del Cron que leerá el archivo json generado y
actualizar el tablero digital, existe un script de nombre trelloCron.sh el cual se
encuentra dentro de la carpeta JSON_EXPORT_DIR, el contenido de este script es
el siguiente:
#!/bin/bash
cd /var/www/kanbanboard/JSON_EXPORT_DIR
64
php moveCard.php "`ls -At *.json | tail -n 1`" >> trello.log
De manera general esta línea lo que hace es lo siguiente:
● php moveCard.php ejecuta el script moveCard.php
● "`ls -At *.json | tail -n 1`" lista todos los archivos json
● tail –n 1 los ordena por fecha, tomando el primer archivo que llegó.
● Posteriormente >> trello.log añade al archivo trello.log el registro de la
ejecución de php moveCard.php para poder tener una bitácora de su
ejecución y detectar posibles problemas.
Configuración del módulo OAuth para php
Antes de instalar OAuth hay que asegurarse de que apt-get esté actualizado, para
ello usamos el comando:
$ sudo apt-get update
Posteriormente ejecutar el siguiente comando para instalar php-pear y php5-dev :
$ sudo apt-get install php-pear php5-dev
Instalamos OAuth con el comando pecl
$ sudo pecl install oauth
En caso de surgir el siguiente error, favor de ir a la sección de problemas
encontrados donde se describe su solución:
downloading oauth-1.2.3.tgz ...
Starting to download oauth-1.2.3.tgz (45,531 bytes)
.............done: 45,531 bytes
could not extract the package.xml file from "/build/buildd/php5-5.5.9+dfsg/pear-build-
download/oauth-1.2.3.tgz"
Download of "pecl/oauth" succeeded, but it is not a valid package archive
Error: cannot download "pecl/oauth"
Download failed
install failed
Agregamos la extensión oauth.so al archivo /etc/php5/apache2/php.ini, la línea que
hay que agregar es la siguiente:
extension=oauth.so
65
Reiniciamos apache
$ sudo /etc/init.d/apache2 restart
En caso de que se muestre el siguiente error:
Missing pcre.h when installing pecl_oauthsudo hay que instalar libpcre-dev con el
siguiente comando:
$ sudo apt-get install libpcre3-dev
Ahora es necesario registrar la extensión oauth.so en CLI, para ello abrimos el
archivo /etc/php5/cli/php.ini y agregamos la línea:
extensión=oauth.so
Nuevamente reiniciamos apache
$ sudo /etc/init.d/apache2 restart
Instalación de Mogrify
Para instalar mogrify es necesario instalar imagemagick con el siguiente comando,
en este caso para una distribución Ubuntu se hace con el siguiente comando:
$ sudo apt-get install imagemagick
8.1.2 Problemas encontrados
Identificador de las tarjetas del tablero
Inicialmente incluimos la url corta en el código QR, sin embargo el módulo
JimFlowKlopfer viene codificado para leer enteros, así que cuando digitalizaba el
código QR, este no podía ser comparado con el json descargado de Trello, pues el
json lo que traía era un id por cada tarjeta, por lo cual la forma de resolverlo fue
codificar el identificador de la tarjeta proporcionado por Trello , el cual se puede
obtener del json que genera Trello, de esta manera al momento de comparar el json
generado por JimFlowKlopfer contra el json de Trello, se resolvió el problema.
Calidad de imagen de los códigos QR
Al momento de que se generaban las tarjetas del tablero seleccionado, se genera
un pdf, el cual incluye las tarjetas, cada tarjeta contiene un código QR, el cual debe
66
ser digitalizado por JimFlowKlopfer, sin embargo tuvimos el problema de que no se
lograba identificar el 100% de las tarjetas, tras varias pruebas deducimos que era
por la calidad de la imagen del código QR, para ello optamos por usar el software
mogrify de imagemagick, así, al recibir una nueva imagen, pasamos la imagen por
imagemagick con el parámetro -quality 100, y de esta forma se resolvió el problema
de calidad de imágenes, logrando que JimFlowKlopfer pueda digitalizar todos los
códigos QR contenidos en la imagen.
Problemas al instalar OAuth
Al momento de instalar el OAuth, específicamente en una distribución Ubuntu 14.04,
se descargaba el paquete, pero una vez descargado era necesario que se
desempaquetar con el comando gzip, todo esto se realiza manera automática, sin
embargo sucedió que no se lograba ejecutar el comando gzip, para ello se hizo de
forma manual, resolviendo el problema, específicamente el error que generaba es
este:
$sudo pecl install oauth
[sudo] password for user:
downloading oauth-1.2.3.tgz ...
Starting to download oauth-1.2.3.tgz (45,531 bytes)
.............done: 45,531 bytes
could not extract the package.xml file from "/build/buildd/php5-
5.5.9+dfsg/pear-build-download/oauth-1.2.3.tgz"
Download of "pecl/oauth" succeeded, but it is not a valid package archive
Error: cannot download "pecl/oauth"
Download failed
install failed
Consultando en internet encontramos que el problema se da al momento de que el
instalador ejecuta el gzip, este falla y no se logra completar el proceso para ello se
debe ejecutar el comando:
$ pear upgrade
Al ejecutar el upgrade con pear se descargan los paquetes en la ruta:
/build/buildd/php5-5.5.9+dfsg/pear-build-download/
67
Ahora de forma manual hay que desempacar los archivos .tar o .gz
$ gunzip /build/buildd/php5-5.5.9+dfsg/pear-build-download/*.tar o bin tgz
Nuevamente ejecutamos sudo pear upgrade y de esta forma se logra el proceso de
instalación.
$ sudo pear upgrade /build/buildd/php5-5.5.9+dfsg/pear-build-download/*.ta
Permitir acceso a PhysicalTrello a múltiples usuarios
Para que los usuarios permitan acceso a Trello, es necesario que se genere un
token, sin embargo al contrario de la aplicación Burndown for Trello, la cual cada
que se quiere acceder a esa aplicación es necesario que el usuario autorice a Trello
dicho acceso, en PhysicalTrello se implementó que el usuario sólo autorizará el
acceso una vez, y se genera de esta forma un token sin vencimiento, para ello se
usó una base de datos, en la cual al momento de que el usuario genere su token de
autorización a Trello, este token junto con el nombre de usuario son guardados en
nuestra base de datos y para posteriores accesos ya no se le pedirá que genere
nuevamente el token, para resolver este problema se genero un código QR más, el
cual contiene el username del usuario, este código QR se coloca a un costado del
QR que contiene el nombre del tablero, se modificó el código python de
JimFlowKlopfer para que se incluyera la lectura de este nuevo código y de esta
forma al digitalizar la imagen, se lee ese código que contiene el username del
usuario, con el username se busca en la base de datos, se obtiene su token y se
realiza la conexión a Trello para poder leer y actualizar el tablero.
Escasa documentación en Trello para implementar OAuth
Existe escasa documentación en Trello para autenticación con el protocolo OAuth, y
en general la documentación de su API es escasa, la forma de resolver esta falta de
documentación fue consultando en otras fuentes, se consultó la API de LinkEdin ,
específicamente en la siguiente url, la cual trae código en php para realizar una
conexión con OAuth:
https://developer.linkedin.com/documents/getting-oauth-token-php