Documentación de proyecto subsistema Visualizacion - EGC-Decide/locaste GitHub Wiki

EGC

Decide-Locaste-Visualización

Grupo 2

Curso académico: 2018-2019

ID de opera: 111

Miembros del grupo

Enlaces de interés:

Resumen

Nuestro trabajo consistía básicamente en mejorar la visualización del proyecto decide. El problema principal del proyecto tal y como se nos entregó, referente a la visualización del mismo, residía en que a la hora de visualizar una votación no se mostraba de forma atractiva. Por ello añadimos gráficos para mostrar los resultados de las votaciones. Además incluimos una vista estándar de error 404 cuando se escribía una url que no existía. Por otro lado, consideramos que una buena manera de mostrar información asociada a una votación era manejarla a través de un bot de telegram con la ayuda de sencillos comandos.

Introducción y contexto

Nuestro equipo eligió trabajar sobre el subsistema de visualización para añadir ciertas mejoras que consideramos interesantes implementar. Entre las mejoras principales que quisimos incorporar pensamos centrarnos en aspectos como mostrar los resultados de las votaciones una vez finalizadas con gráficas. De esta manera se puede obtener una mejor idea de cuántos votos se obtiene para cada opción.

Por otra parte, detectamos que las vistas cuya url no existiese no contenía una vista estática de error 404, muy común en cualquier página actual. Por lo que también quisimos emplear tiempo en solucionar dicho problema.

Por último, una implementación que pensamos podría mejorar bastante la forma de interactuar el cliente con las votaciones existentes era con la creación de un bot de telegram. Dicho bot podría devolver información relativa a las votaciones, así como su nombre, descripción, opciones, resultados, etc. con la ayuda de simples comandos.

Descripción del sistema

Respecto al componente del bot: Como comentamos previamente, el bot que hemos implementado se maneja a través de comandos, y su uso es bastante sencillo. Para inicializar el bot basta con tener lanzada la aplicación de decide (python manage.py runserver) y lanzar el bot (python bot.py). Una vez hecho esto abriremos la aplicación de telegram y podremos conversar con el bot que acabamos de crear. Con /start nos da un mensaje de bienvenida en el que nos aclara que con el comando /help podemos obtener una lista de todos los comandos disponibles. El usuario puede decidir qué comandos quiere utilizar escribiendole al bot. A continuación incluimos una lista de los diferentes comandos que hemos añadido y la funcionalidad que tienen:

/start : devuelve un mensaje de bienvenida.
/id : devuelve una lista con los id’s de las votaciones que se han creado y los nombres de las mismas.
/info : devuelve toda la información referente a una votación.
/title X : devuelve el título de una votación dado su id. Por ejemplo ‘/title 1’.
/date X : devuelve la fecha de fin de una votación dado su id. Además, también comprueba si dicha votación se ha cerrado. Por ejemplo ‘/date 1’.
/options X : devuelve el conjunto de opciones de una votación dado su id. Por ejemplo ‘/options 1’.
/result X: devuelve el resultado de una votación dado su id. Por ejemplo ‘/result 1’.
/login : permite logearte a la aplicación de decide con credenciales.
/logout : permite deslogearte de la aplicación de decide.

El proceso de creación del bot comienza mediante el asistente automatizado BotFather, el cual permite generar y gestionar bots. BotFather ofrece múltiples funcionalidades para diferentes tipos de bots, tales como juegos interactivos, creación de claves y funciones, etc. Para nuestro caso, tan sólo fue necesario hacer uso de la función principal de crear un nuevo bot: usando el comando /newbot, proveyendo un nombre para el bot, y un alias corto para enlazarlo a otras personas. BotFather genera un bot vacío con dicho enlace, así como una clave para conectarlo mediante Python u otros servicios. Según nuestro plan original, realizamos el bot con Python como un subsistema, de modo que no se hizo otro uso de BotFather tras este punto.

Tuvimos que desplegar el bot para poder hacer uso de la generación de gráficos en telegram. Para la generación de imágenes estáticas desde el servidor ha sido necesario la utilización de plotly junto con una dependencia llamada orca cuya instalación debe hacerse con npm, tras investigar si era posible realizarlo con la aplicación global (https://locaste-decide.herokuapp.com) pero la aplicación no contaba con node.js para hacer uso de npm. Una posible opción es la de añadir un “buildpack” (heroku/nodejs) de Heroku a la aplicación actual para que contase con la información necesaria para contener a node y usar npm, pero esto hacía necesario que los archivos de lanzamiento como el Procfile fuesen modificados para lanzar al bot junto con la aplicación.

Se optó por una solución más simple que es desplegar el bot en una aplicación de Heroku independiente, con los buildpacks necesarios (heroku/python y heroku/nodejs).

Para ello se ha procedido a obtener la última versión del fichero bot.py del módulo de visualización realizándo un pull a la rama “visualizacion-bot”, se copió el archivo a una nueva carpeta-repositorio que serviría de aplicación de Heroku para nuestro bot, pasamos entonces a la creación de la aplicación con el uso de “heroku create ‘locaste-bot'” y “heroku git:remote –a ‘locaste-bot’”.

Lo siguiente necesario fue modificar la url base de nuestro bot para que no usase localhost sino que usase la de nuestra aplicación global, añadimos el TOKEN como variable de entorno en heroku con el uso del comando “heroku config:set TOKEN=xxx”, preparamos el Procfile y ficheros de configuración necesario tales como requirements.txt para Python y package.json para node.

El archivo Procfile contiene la siguiente información

release: sh -c 'pip3 install -r requirements.txt && npm install' worker: sh -c 'python3 bot.py'

El fichero requirements.txt contiene las dependencias de Python necesarias para hacer funcionar nuestra aplicación

python-telegram-bot python-dotenv pillow psutil plotly

Y por último el fichero package.json es un fichero necesario para poder lanzar la aplicación con el buildpack de node.js, el fichero package.json contiene la dependencia “orca”.

"dependencies": { "electron": "^1.8.4", "orca": "^1.1.1" }

Una vez tenemos todos los archivos bot.py, Procfile, package.json y requirements.txt, tenemos todo lo necesario para realizar “git add .”, “git commit” y “git push heroku master”, con esto ya podremos utilizar nuestro bot de forma ininterrumpida.

Una de las mejoras que queríamos incorporar en el bot de telegram es la generación de gráficas en base a los resultados de la votación. En un inicio se intentó usar matplotlib, una librería de python para la representación de gráficas, después de múltiples intentos resultó imposible utilizar dicha librería ya que causaba un error que causaba que el bot dejase de funcionar. Se optó una solución distinta la cual consiste en usar la librería plotly.

Esta librería permite generar gráficos además de almacenarlos en memoria gracias al uso de “electron” y “orca”.

Para poder enviar las imágenes haciendo uso del bot hicimos uso del ejemplo en su documentación, se nos insta a usar una imagen de tipo Image dentro de la librería PIL, y posteriormente usar un buffer para enviar los bytes de la imagen desde el bot.

Para generar las las imágenes de tipo PIL se generaron los gráficos, de barras y pastel, con los datos de la votación en el eje X las opciones y el eje Y el resultado del postprocesado y se convirtieron de formato JPEG a bytes con el uso de la función to_image, estos bytes son usados por la función open de la librería Pillow para convertirlos a objeto Image, finalmente como ha sido explicado en el párrafo anterior podemos proceder a enviar ambas imágenes desde el bot.

El resultado son imágenes que presentan el siguiente aspecto para una votación con dos opciones y resultado 2, 1.

grafico telegram 1

grafico telegram 2

Respecto al visualizer: Hemos mejorado la vista de visualización para los votos. Hemos añadido CSS a la información de las votaciones para que sea más atractiva para el usuario. Cuando una votación está cerrada y se ha hecho tally se muestra un botón llamado “Stats”. Cuando se pulsa ese botón se generan gráficas para representar la votación que se está visualizando. Dichas gráficas se realizan con la librería chart.js. Para la realización de esta vista básicamente hemos tenido que diferenciar tres situaciones: Que la votación no haya empezado, que haya empezado pero no haya finalizado y que haya finalizado.

visualizacion graficos escritorio

La implementación con la gráfica ha sido bastante sencilla. Está hecha para introducir los datasets a mostrar. Los demás parámetros son básicamente para personalizar otros parámetros como el color de la gráfica, tipo de gráfica, etc... Además, se añadió el botón de Logout ya que el anterior daba problemas y no tenía CSS. En cuanto a la organización del código se ha realizado todo en un mismo documento html, tanto los scripts como la configuración CSS. Esto se ha realizado así para facilitarle el trabajo a el módulo de cabina ya que está realizando una app móvil y nos hemos integrado con ellos para que su vista de visualización sea igual a la nuestra sin que se compliquen mucho en la integración. Nos hemos ayudado de Google Chrome para comprobar cómo se vería en la versión de móvil. Por ejemplo, para Iphone 6/7/8 quedaría así:

visualizacion graficos movil

Sobre la API: Hemos añadido una llamada a la API que devuelva solo la información que se muestra cuando se visualiza. De esta forma se podría integrar en otros sistemas, obtener la información de los votos, compartirla, etc… Para realizar esto tendremos que acceder a la URI “/visualizer/?id=” y poner la id del voto al que queremos acceder. La mayor dificultad para realizar esta funcionalidad ha sido aprender cómo funcionaba la herramienta de APIs de Django. Tras haberlo aprendido, las líneas de código ni la complejidad de estas son elevadas:

visualizer API

Frente a las mejoras basadas en funcionalidades generales, implementamos una pequeña mejora basada en la visualización de errores 404. Cuando un usuario intenta acceder a una votación no existente, o para la cual no tiene permiso, el sistema originalmente lanzaba una excepción 404 a modo de una pantalla de error en el navegador. Comúnmente, este tipo de casos en sistemas de información web se resuelve implementando una vista que enmascara el error de cara al usuario. Dada la relativa simplicidad de la mejora, un solo miembro del equipo se encargó de ella. El cambio principal fue sustituir el código que lanzaba una excepción con una serie de mensajes genéricos, pidiendo al usuario disculpas por no haber encontrado el recurso, y sugiriendo que verifique que la petición del visualizador que ha hecho es correcta. En total tan sólo fue necesario modificar dos ficheros: el fichero views.py donde se implementa la lógica que lanza las excepciones/mensajes, y la plantilla HTML donde se renderiza en pantalla la información de la vista. Al intentar visualizar una votación no existente, el usuario recibe el siguiente resultado (se trata de un ejemplo básico sin estilo aplicado):

sorry!

Planificación del proyecto

Respecto a la planificación del proyecto, comenzamos por diferenciar entre las distintas partes que componían el desarrollo de mejoras que queríamos implementar. Estas partes eran, como hemos comentado previamente, la visualización gráfica de los resultados; solucionar la vista de error 404; y crear un bot de telegram. Es por ello que en un principio empezamos a dividir a los miembros en función de la complejidad y tiempo necesario para poner solución a estas partes.

En un principio, la planificación inicial del trabajo fue designar 2 miembros a la parte de gráficos, 1 a la del error 404 y otros 2 a la del bot. Para cada una de estas partes incluimos una rama de desarrollo específica para que cada grupo fuese trabajando sobre ellas y posteriormente una vez finalizadas subirlas a las ramas de development y master.

Una vez solucionado el problema relacionado con el error 404, el miembro encargado se asignó a la rama del bot quedando 2 miembros para la parte de gráficos y 3 para la del bot. Atendimos a este criterio debido al peso de trabajo que podía suponer. De esta manera pudimos trabajar en paralelo ambos grupos.

Respecto al grupo de telegram bot, se creó un issue con un desglose de mini tareas con las que dentro de ese grupo se les asignaría a cada uno. Entre ellas se encontraba la creación del bot, configurar dicho bot para que se comunicarse con la aplicación y devolver los datos desde el cliente de telegram sobre las votaciones. Posteriormente uno de los miembros del grupo se encargó de devolver en forma de gráficos los resultados de las votaciones a través de telegram.

Respecto al grupo de gráficos, también se creó un issue con varias tareas a realizar. Por una parte un miembro se encargó de la parte de mostrar las gráficas con Chart.js (librería la cual se tuvo que encargar de buscar), y otro se encargaba del CSS y de la visualization API para que se mostrase el json y con el html en ayuda al subsistema de cabina.

Entorno de desarrollo

Todos compartimos un fichero de instalación de requisitos (requirements.txt) incluido en el repositorio de decide con el que tenemos instaladas las mismas versiones para poner en funcionamiento el proyecto. Dichos requisitos son:

Django==2.0
pycryptodome==3.6.6
djangorestframework==3.7.7
django-cors-headers==2.1.0
requests==2.18.4
django-filter==1.1.0
psycopg2==2.7.4
django-rest-swagger==2.2.0
django-rest-auth==0.9.3
django-allauth==0.38.0

Para poner en funcionamiento el proyecto ‘decide’ primero tuvimos que instalar y configurar postgres en cada uno de nuestros ordenadores. Creamos un rol llamado ‘decide’ y le garantizamos permisos para poder crear una base de datos ‘decide’. Instalaremos todo lo necesario recogido en requirements.txt dentro del repositorio de locaste. Para esto ejecutaremos el comando “pip install -r requeriments.txt” Además tendremos que modificar el archivo /decide/local_settings.py en el cual añadiremos la línea “PASSWORD: decide” Una vez realizado todo esto nos crearemos un superusuario. Para ello usando la consola de comandos nos iremos hasta locaste/decide y ejecutaremos el comando “python manage.py createsuperuser” e introducimos las credenciales. Tras esto ejecutamos “python manage.py migrate” Finalmente iniciamos el servidor ejecutando “python manage.py runserver”. Desde este punto cada miembro ha utilizado un IDE distinto, en función de sus preferencias. A continuación se muestra la de cada uno:

Álvaro Pérez Pérez: en mi caso he estado trabajando desde un ordenador con macOS. El programa de desarrollo que he usado para desarrollar el código que he aportado ha sido Visual Studio Code y he usado la versión 1.30.2
Joaquín Romero Moreno: Ha trabajo desde Windows 10 usando Eclipse Neon V.3
Gonzalo Delgado Chaves: he trabajado con dos entornos diferentes: para el desarrollo del proyecto, un sistema operativo Windows 10 Home con el IDE Visual Studio Code, versión 1.30.1. Debido a problemas con la instalación y posterior mantenimiento de Docker Toolbox, el entorno de pruebas en despliegue se ha hecho en un sistema operativo Windows 10 Education con Docker for Windows, versión 18.09.
Iván de los Santos García: He estado trabajando con macOS. El IDE usado ha sido Visual Studio Code, versión 1.30.2
Jesús Andrés Rico Catalán: He estado trabajando con Windows 10 usando como IDE Eclipse(PyDev) Neon V.3

ALTERNATIVA: DOCKER Un miembro intentó realizar el desarrollo en Docker, aunque consiguió desplegar su copia local de decide en Docker (En lugar de un clone de github) abandonó la idea dado la dificultad de trabajar con PostgreSQL a través de Docker. Para conseguir desplegar una copia local de decide en Docker se debe de hacer un clone de decide (En este caso locaste) dentro de la carpeta /Docker/ Una vez realizado esto se debe de modificar el archivo “Dockerfile” y sustituir la línea “RUN git clone https://github.com/wadobo/decide.git” por “ADD /decide ."

La instrucción ADD nos copia los archivos indicados dentro de la MV de Docker, de esta forma cuando desplegamos, lo haremos con los cambios que estamos realizando.

Gestión de incidencias

La gestión de incidencias, dentro del contexto de nuestro proyecto, consiste de dos procesos definidos para varios tipos de desarrollo del subsistema de visualización, tales como nuevas funcionalidades, depuración de errores o refactorización de código. El proceso de gestión a nivel general contiene los siguientes pasos:

Identificación de la incidencia.
Documentación de la incidencia.
Evolución de la incidencia.
Finalización de la incidencia. La identificación consiste en uno o más miembros del equipo descubriendo y verificando la necesidad o existencia de una incidencia, y por lo tanto de su documentación. Puede ser una nueva funcionalidad que se haya decidido implementar, un error que un miembro haya descubierto, o una necesidad para cambiar el código de manera no impactante (refactorizaciones, tareas “chore”, etc.). En cualquier caso, consenso entre los miembros del grupo debe alcanzarse antes de pasar al paso de documentación. Si se trata de un error, al menos otro miembro del equipo aparte del primero en descubrirlo debería ser capaz de reproducir el error, para evitar falsos negativos. Según si se trata de una incidencia interna al equipo de desarrollo, o externa (o bien debido a una incidencia por parte de otro subsistema hacia el nuestro, o bien una incidencia detectada por el equipo sobre un subsistema ajeno), la documentación, evolución y finalización de la incidencia sigue un proceso diferente. Para incidencias internas, el proceso queda definido por los miembros del grupo:
El dueño de la incidencia (se considera como dueño a aquella persona que descubriera o propusiera la propuesta inicialmente) debe generar un ticket de incidencia en el repositorio de GitHub del proyecto general, conteniendo una descripción, prioridad y una categoría (feature, bug, refactor, etc.).
El encargado de la incidencia la valorará, y podrá elegir denegar su ejecución, o bien añadirla a la columna To do del proyecto de GitHub. Asimismo, podrá asignar a una o más personas a la incidencia.
El encargado, o uno de los encargados si procede, moverá la incidencia a la columna WIP (Work in Progress) del proyecto GitHub cuando sea el momento de empezar.
En este momento, y según la prioridad de la incidencia, el miembro o miembros del equipo asignados deberán llevar a cabo la evolución de la incidencia, hasta que se resuelva el error o tarea, o se implemente la nueva funcionalidad. Durante cada paso de la evolución, se deberá comentar en el ticket sobre su progreso.
Una vez resuelta la incidencia, el encargado o uno de los encargados moverá el ticket a la columna In Review, y notificará al revisor de la incidencia para que verifique que se ha cumplido.
El revisor podrá denegar, tras su revisión, que la incidencia se haya cumplido correctamente, o aceptarla, cerrando el ticket y moviéndolo a la columna Done. Esto finaliza el proceso para esta incidencia en particular.

En caso de tratarse de una incidencia sobre otro subsistema, nuestro equipo se encargaría únicamente del primer paso de la incidencia, mediante el cual informaríamos al equipo correspondiente del problema encontrado, para que el miembro encargado pueda actualizar su estado. En estos casos, la incidencia debería llevar información que permita al equipo entender la incidencia. El formato generalizado sugerido desde la administración del proyecto contiene los siguientes campos:

Pasos necesarios para reproducir la incidencia: 1. x 2. y 3. z ... Salida esperada, junto con la salida real: Versiones de sistema y software, así como sistema operativo que se usa: Información adicional que sea pertinente a la incidencia:

Si más de una persona puede reproducir la incidencia fuera del grupo encargado del subsistema responsable, se recomienda que comenten en el ticket con los mismos campos de información. Esto permite solidificar el estado de la incidencia. Este proceso se aplica a nuestro propio grupo: en caso de llegar una incidencia de parte de otros desarrolladores ajenos a nuestro equipo, nos corresponde evaluar la incidencia y seguir los pasos anteriormente descritos para el proceso de evolución y finalización.

Gestión de depuración

La gestión de depuración se entiende como el proceso mediante el cual un desarrollador aborda un error en el código o funcionamiento del subsistema (a partir de ahora conocido como bug) y lleva a cabo los pasos necesarios para que dicho bug deje de existir en la versión pertinente del subsistema, y si es posible, en toda iteración posterior.

El proceso de depuración queda recogido dentro de este documento como un proceso interno al desarrollo, y específicamente como un proceso interno a la metodología de trabajo de cada miembro desarrollador individual del equipo. Dentro del modo de operación de cada individuo, se ha fijado un proceso común para la resolución de errores, que no aparece visiblemente recogido paso a paso en otros procesos, tales como el de gestión de incidencias.

El prerrequisito para garantizar la ejecución de este proceso es el siguiente:

Un miembro desarrollador del equipo ha encontrado el bug durante el desarrollo de actividades normales de evolución y gestión del subsistema, o bien otro miembro ajeno al grupo ha encontrado el bug durante el desarrollo o ejecución del sistema en su propio marco de actuación.

Una vez descubierto el bug, el proceso de gestión de la depuración comienza. Los pasos recomendados mínimos y necesarios dentro del marco de actuación del proyecto general:

Recolección de evidencia: se prepara de alguna manera la información a presentar sobre el bug al resto del equipo, a fin de preparar el siguiente paso.
Reproducción: los miembros del equipo, una vez recibida la información sobre el bug, deberán repetir los pasos realizados por el miembro encargado del bug, a fin de verificar que se trata de un problema probable, y no un caso aislado.
Confirmación de actuación: los miembros del grupo dan vía libre al encargado para ocuparse del bug. El encargado podría cambiar en este momento, debido a una reasignación de la tarea pertinente.
Documentación de descubrimiento: el bug se documenta mediante una incidencia, y se añade al cómputo del proyecto.
Evolución: el encargado trabaja con las herramientas habituales para eliminar el bug. Se producen los siguientes pasos iterativos: 5.1. Diagnosticar: se construyen hipótesis a fin de encontrar una explicación con causa plausible y demostrable del bug. 5.2. Reparar: mediante experimentación u otro medio de actuación, el encargado descubre la manera de eliminar el bug. 5.3. Probar: mediante pruebas que puedan ser repetidas por otros miembros del grupo, el encargado demuestra que el bug ya no existe.
Confirmación de evolución: los otros miembros del equipo llevan a cabo las pruebas del encargado y verifican que el bug ya no existe, y que es posible avanzar.
Documentación de finalización: se finaliza la incidencia correspondiente según su proceso pertinente.
Analizar: se realiza una introspección sobre el bug y cómo, si es posible, se podría mejorar el proyecto o los procesos asociados a su desarrollo para incrementar la funcionalidad y rendimiento de los mismos.

Cabe destacar que existen bugs que, por su naturaleza, se resuelven rápidamente y en un entorno controlado (por ejemplo, por un sólo miembro del equipo que descubre y resuelve el problema). En estos casos, seguir el proceso no es necesario, y como tal no se exige documentar estos bugs en otros procesos.

Gestión del código fuente

Nuestro sistema de gestión del código fuente ha sido el siguiente. Primero creamos 3 ramas con la que manejar el código fuente (visualizacion, visualizacion-bot y visualizacion-404). En estas ramas se han ido subiendo los cambios respecto a las gráficas, al bot de telegram y al error 404 respectivamente. A continuacion, una vez implementados los cambios en la rama visualizacion-404 estos pasaron a la rama visualizacion. El bot de telegram en un principio lo hicimos funcionar de manera local, pero al desplegarlo con heroku (debido a las restricciones ya explicadas en el desarrollo del sistema) no tuvimos que pasarlos a la rama visualizacion. Una vez completados todos los cambios estos pasarían a development para integrar esta rama con el resto de subsistemas y solucionar los posibles errores que puedan haber. Y una vez solucionados pasar a la rama master libre de errores. Respecto a los commits se ha definido una guía y un protocolo común de cómo y cuándo realizar un commit. En este link se puede encontrar dicho protocolo.

Gestión de la construcción e integración continua

En este caso también hemos compartido un mismo sistema de gestión con el que conseguimos automatizar el proceso de integración continua. Se puede consultar en este link dicho sistema de gestión..

Gestión de liberaciones, despliegues y entregas

Respecto a la licencia de software elegida se puede consultar en el siguiente link. Tanto la liberación como la entrega del proyecto se realizará el 13-01-19. Respecto al control de versiones seguiremos el mismo esquema común que aparece en este link.

Mapa de herramientas

mapa de herramientas

El epicentro del diagrama será Git. Desde el uso de git (Github en su defecto) podremos descargar el repositorio en el que estamos trabajando y con las ramas que veamos necesarias. A través de este, podremos trabajar con Travis para poder correr los Tests automatizados necesarios sobre nuestro proyecto. Tras realizar el trabajo con Travis, podremos realizar con Heroku el despliegue continuo. Desde nuestro puesto de developer, una vez obtenido el repositorio a través de git, podremos trabajar con nuestro proyecto desplegándolo en local haciendo uso de PostgreSQL y DJango. Cabe decir la bidireccionalidad entre el developer y Git dado que realizaremos pull-push a lo largo del proyecto.

Ejercicio de propuesta de cambio

El desarrollo de una propuesta de cambio está compuesto por las siguientes pautas:

Se realiza una issue en estado TODO en el que se describa el cambio en el sistema asignando a algún desarrollador si se requiere.Esta se etiqueta con la correspondiente categoría por defecto de github a la que pertenece y con una prioridad.
Un desarrollador verifica la issue y si la incidencia es adecuada pasa al estado de WIP.
Un desarrollador implementa el cambio propuesta .
Sube a Github el cambio mediante los siguientes comandos: git add . git commit -m “descripción del cambio y a que tipo pertenece ese cambio” git push origin nombreRama
Una vez subido pasa la incidencia al estado de REVIEW.
Un desarrollador diferente comprueba dicho cambio y cierra la issue colocándola al estado DONE.

Cabe destacar que tanto Travis como Heroku se encuentra desplegado automáticamente desde Github.

Conclusiones y trabajo futuro

Como conclusiones podemos sacar que trabajar en un trabajo de gran tamaño compartido por tantos participantes requieren un buena organización y un correcto sistema de comunicación, ya que de otra manera resultaría imposible trabajar con un equipo tan grande.

Respecto a futuras mejoras pensamos que se podría mejorar la interfaz de usuario en general para que fuese más atractivo. Además como funcionalidad sería interesante mostrar un cuadro con estadísticas sobre las votaciones.

Diario de equipo

Enlace a las actas de reuniones aquí. Enlace a la hoja de tiempos aquí.