Visibilizando injusticias laborales publicadas en Twitter a travéss de una plataforma descentralizada basada en blockchain

Visibilizando injusticias laborales publicadas en Twitter a trav´es de una plataforma descentralizada basada en blockchain Giving visibility to workplace injustices published on Twitter via a decentralized blockchain-based platform TRABAJO DE FIN DE GRADO UNIVERSIDAD COMPLUTENSE DE MADRID FACULTAD DE INFORM´ ATICA Grado en Ingenier´ıa Inform´atica Roberto Asunci´on L´opez Pablo Imbert Fern´andez Juli´an Moreno Bellaneda Raquel P´erez Gonz´alez de Ossuna Doble Grado en Ingenier´ıa Inform´atica y Matem´aticas Javier Mulero Mart´ın ´ Angela Ruiz Ribera Departamento de Ingenier´ıa del Software e Inteligencia Artificial Directores: Samer Hassan Collado y Jorge Sald´ıvar Curso acad´emico 2021-2022 Convocatoria de Junio Distribuci´on de la memoria e im´agenes del proyecto Atribuci´on-CompartirIgual 4.0 Internacional (CC BY-SA 4.0) Usted es libre de: Compartir: copiar y redistribuir el material en cualquier medio o formato Adaptar: remezclar, transformar y construir a partir del material para cualquier prop´osito, incluso comercialmente. Bajo los siguientes t´erminos: Atribuci´on: Usted debe dar cr´edito de manera adecuada, brindar un enlace a la licencia, e indicar si se han realizado cambios. Puede hacerlo en cualquier forma razonable, pero no de forma tal que sugiera que usted o su uso tienen el apoyo de la licenciante. CompartirIgual: Si remezcla, transforma o crea a partir del material, debe distribuir su contribuci´on bajo la la misma licencia del original. This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. Distribuci´on del c´odigo del proyecto GNU General Public License v3.0 Todo el c´odigo desarrollado en este proyecto se distribuye bajo la licencia GPL-3.0. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses. Resumen En nuestro d´ıa a d´ıa, se producen numerosas situaciones de injusticia en el entorno laboral. Sin embargo, muchas veces, los medios tradicionales de denuncia no son suficiente para visibilizarlas. En los ´ultimos a˜nos, con la aparici´on y expansi´on de las redes sociales, muchas personas han recurrido a ellas para hacerse o´ır. En particular, Twitter ha jugado un papel muy importante a la hora de visibilizar iniciativas y unir a gente con intereses comunes. En este contexto, percibimos que, a´un significando un avance importante, pueden existir problemas si se usan exclusivamente las redes sociales como medio de denuncia. Por ejemplo, la denuncia puede ser censurada por medio de su eliminaci´on, denuncias muy medi´aticas pueden eclipsar a otras, o las denuncias pueden quedar ocultas entre la gran cantidad de contenido que hay en la red social. Es por ello que proponemos crear una herramienta de an´alisis yvisualizaci´on dedicada, exclusivamente, a este tema. La aplicaci´on Injustweet, haciendo uso de estad´ısticas y gr´aficas, muestra datos relacionados con denuncias laborales en Twitter. De forma que pueda servir como un punto de conocimiento,apoyo ydenuncia para personas que est´en interesadas, tanto a nivel personal como profesional, en el tema. El desarrollo de la aplicaci´on aprovecha los ´ultimos avances metodol´ogicos ytecnol´ogicos para llevarla a cabo. Por un lado, el desarrollo del frontend se lleva a cabo cuidando el dise˜no gracias a React. Por otro lado, con el objetivo de evitar la censura, el backend hace uso de tecnolog´ıas distribuidas, como la blockchain. Finalmente, destacamos que con el fin de detectar, entre la gran cantidad de datos, aquellas que sean denuncias, se aplican t´ecnicas de an´alisis de lenguaje natural. Palabras clave: blockchain, dashboard, an´alisis de lenguaje natural, denuncias laborales, Twitter, MERN, Python. iv Abstract There has always been different kinds of injustice in the workplace. However, many times, it is hard to be heard when using the traditional ways of launching complaints. During the past years, due to the rapid growth of social media, many have started using them as a way of communicating those injustices. In particular, Twitter has played a very important role. It has become a platform that gives visibility to many initiatives and where people can get together and share common interests. Even though social networks have partially solved the problem, they alone do not seam to be the best solution. For instance, a report made in Twitter can be censored by deleting the tweet. The denunciations can be eclipsed by the gigantic amount of data or by others which get more spotlight. That is way we propose to develop an application dedicated, exclusively, to this topic. Injustweet will show data related to workplace injustices by using graphs and statistics. Therefore, everyone who is interested personally or professionally in those situations could use it as a way of consulting and sharing information. During the development of this project, we have used the latest technologies and methodologies available. On one hand, we were able of creating an attractive design and developing the frontend thanks to React. On the other hand, we used blockchain as a way of avoiding censorship. Finally, it should be noted that we have used language processing techniques to obtain data related to workplace injustices. Key words: blockchain, dashboard, language processing, workplace complaints, Twitter, MERN, Python. v Agradecimientos Queremos dedicar unas palabras para agradecer a todos aquellos que nos han acompa˜nado y apoyado, no s´olo durante el desarrollo de este TFG, sino a lo largo de toda la carrera. En primer lugar, nos gustar´ıa agradecer a Samer Hassan yJorge Sald´ıvar, codirectores del TFG, por su motivaci´on y ayuda. Nos ha permitido sacar adelante un proyecto del que sentirnos orgullosos, as´ı como aprender sobre nuevas tecnolog´ıas y su aplicaci´on a problemas sociales reales. Por otro lado, agradecer a todas aquellas personas que de forma voluntaria participaron en la evaluaci´on del proyecto, lo que nos permiti´o entender mejor la calidad de los resultados obtenidos. Finalmente, a nivel personal, agradecer a los compa˜neros de carrera que nos han acompa˜nado durante estos a˜nos y con los que hemos compartido vivencias acad´emicas. As´ı como a los familiares y amigos, que nos han apoyado y animado durante las ´epocas de ex´amenes y las largas horas de estudio. vi ´ INDICE GENERAL ´ Indice general 1. Introducci´on 1 2. Introduction 4 3. Marco te´orico y estado del arte 7 3.1. Marco te´orico .................................. 7 3.1.1. Redes sociales y organizaci´on social ................... 7 3.1.2. An´alisis de lenguaje natural y web scraping ............... 9 3.1.2.1. An´alisis de lenguaje natural .................. 9 3.1.2.2. Web scraping ......................... 14 3.1.3. Blockchain como tecnolog´ıa descentralizada .............. 15 3.2. Estado del arte .................................. 19 3.2.1. Redes sociales como fuente de investigaci´on .............. 19 3.2.2. Blockchain para el beneficio social .................... 20 4. Metodolog´ıa y tecnolog´ıas 22 4.1. Metodolog´ıa ................................... 22 4.1.1. Metodolog´ıa de dise˜no y software .................... 22 4.1.2. Metodolog´ıa de software libre ...................... 23 4.1.3. Plan de trabajo ............................. 24 4.1.4. Contribuciones al proyecto ........................ 25 4.2. Tecnolog´ıas .................................... 42 4.2.1. Edici´on y control de versiones ...................... 42 4.2.1.1. Diagramas de Gantt ...................... 42 4.2.1.2. Overleaf ............................ 43 4.2.1.3. GitHub ............................. 43 4.2.1.4. PyCharm ............................ 43 4.2.1.5. Visual Studio Code ...................... 43 4.2.2. Dise˜no de la aplicaci´on .......................... 43 4.2.2.1. Balsamiq Wireframes ..................... 43 4.2.2.2. GIMP ............................. 43 4.2.2.3. diagrams.net .......................... 43 4.2.3. Desarrollo de la aplicaci´on ........................ 43 4.2.3.1. Twitter API .......................... 43 viii CAP´ ITULO 2. INTRODUCTION related to workplace denunciations. Moreover, with the final purpose of avoiding censorship, we bring forward the idea of using the blockchain. Goals In view of the situation exposed, we develop our application with the following goals in mind: To give visibility to workplace related denunciations in places where Spanish is their main language. We would like to show, not only the reports, but also the context in which they take place. To provide a place where people can share, see and report situations of injustice, as well as support one another. To develop an interface that can be used and understood by everyone. To learn and use natural language processing techniques in order to acquire data. To learn and use the blockchain as a way of avoiding censorship. To develop a project using and encouraging the use of free software. Structure of this document This paper contains the information required to properly understand the project. We now show the contents of each chapter. Chapter 1: It presents the reasons why we started this project and the motivations behind it. Chapter 2: Chapter 1 in English. Chapter 3: It gives a theoretical point of view of the technologies used and the lines of work that have inspired us. Chapter 4: It explains the work methodologies and technologies used, as well as the planning made and how each person contributed to the project. Chapter 5: Before starting the project, we took some time to learn and develop smaller projects which are shown in this section. Chapter 6: It explains the investigation phase that took place, as well as all the requirements we had to meet are shown in this section. Chapter 7: It presents the process followed during the design and implementation phase. It made us better understand the market we were entering to and the users we had to target. 5 CAP´ ITULO 2. INTRODUCTION Chapter 8: The full software architecture of our project can be found here. Chapter 9: After finishing the project, a phase of evaluation took place. It had two points of view; user experience and NLP. Chapter 10: It presents the results and conclusions of our project. It also proposes the future lines of work that could be followed. Chapter 11: Chapter 10 in English. Resources The project can be found in GitHub using the following link: https://github.com/injustweet-tfg Access Injustweet using the fillowing link: https://dashboard-twitter.herokuapp.com/dashboard 6 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE Cap´ıtulo 3 Marco te´orico y estado del arte 3.1. Marco te´orico Dedicamos esta secci´on a presentar los principales temas que vamos a tratar, introduciendo el contexto tecnol´ogico y social en el que se desarrolla nuestro proyecto. Vamos a contarlo en tres partes. En primer lugar, nos centraremos en ver c´omo las redes sociales se han utilizado como forma de organizaci´on social para denunciar injusticias laborales y sociales, as´ı como a entender c´omo de importante es la colectivizaci´on de personas para obtener resultados. A continuaci´on, dedicamos una secci´on a ver c´omo se pueden aprovechar t´ecnicas de an´alisis de lenguaje natural para detectar y recoger las situaciones que sean de inter´es. Finalmente, nos acercaremos a conocer qu´e es la tecnolog´ıa blockchain, un t´ermino muy utilizado durante los ´ultimos a˜nos y que se est´a introduciendo cada vez m´as en nuestra sociedad. Entenderemos los conceptos b´asicos, un poco de su historia, y en qu´e momento nos encontramos actualmente. 3.1.1. Redes sociales y organizaci´on social Hoy en d´ıa, gran parte de la comunicaci´on que realizamos a trav´es de internet es gracias a las redes sociales. Entendemos por redes sociales aquellos servicios web o aplicaciones que nos permiten conectarnos con otras personas, para compartir e intercambiar informaci´on, creando as´ı redes de contactos y comunidades. Las redes que se forman pueden ser privadas o p´ublicas. Pero son ´estas ´ultimas las que han promovido, durante los ´ultimos a˜nos, que las redes sociales no s´olo sean un lugar donde compartir experiencias con tus contactos, sino tambi´en un medio de difusi´on masiva de informaci´on. Todo esto ha conducido a que las redes sociales se utilicen, en particular, como medio de organizaci´on y movilizaci´on ciudadana. Esto se debe a que ayudan a aumentar la parti7 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE cipaci´on y el sentimiento de pertenencia a colectivos. Adem´as, dan voz a iniciativas que, por los medios tradicionales, podr´ıan no ser escuchadas. Un ejemplo de uso de redes sociales con este fin, es la movilizaci´on de los trabajadores de Walmart de 2010. Walmart es una cadena multinacional de supermercados estadounidenses, con una plantilla global de 2.2 millones de trabajadores, de los cuales 1.4 eran trabajadores por horas[121]. La organizaci´on “OUR Walmart” (Organisation United for Respect at Walmart), fundada por la UFCW (United Food and Commercial Workers), fue creada para combatir la amenaza que supon´ıa la compa˜n´ıa para la organizaci´on de los trabajadores [115]. A los trabajadores se les imped´ıa organizarse, incluso eran sancionados si se les ve´ıa hablar de esos temas durante las jornadas laborales, por lo que las redes sociales supusieron un canal de comunicaci´on seguro y directo, donde expon´ıan sus situaciones y se apoyaban mutuamente. OUR Walmart se convirti´o, de esta manera, en un movimiento con bastante repercusi´on en los medios. Gracias a ´el, consiguieron aumentar el salario inicial 10 d´olares la hora, cambio que afect´o a 500,000 trabajadores [115]. Otro ejemplo, fue el movimiento #FightFor15 surgido en Twitter en 2012, con el fin de aumentar el salario m´ınimo a 15 d´olares la hora a los trabajadores de un restaurante de comida r´apida. Gracias a las redes sociales, obtuvieron un nivel de exposici´on mucho mayor al esperado, debido a la gran cantidad de usuarios que compart´ıan el contenido. Esto evit´o que tuviesen que depender de los medios tradicionales para hacerse o´ır. La iniciativa tuvo tanta repercusi´on que, gracias a ella, se consigui´o la aprobaci´on de leyes, en numerosos estados estadounidenses, que aumentaban el salario m´ınimo, acerc´andose o superando los 15 d´olares la hora. Por lo tanto, se ha visto que las redes sociales son muy ´utiles a la hora de unir a personas en distintas situaciones de injusticia y visibilizar, a gran escala, problemas que son dif´ıciles de difundir haciendo uso de medios tradicionales. En particular, una de las redes m´as utilizadas para denunciar este tipo de situaciones es Twitter, gracias a la gran actividad que llevan a cabo sus usuarios, y al uso de hashtags. Twitter nace en 2006, fundada por Jack Dorsey y sus socios en San Francisco [85]. Propone un servicio en el cual sus usuarios pueden compartir mensajes de texto, llamados tweets, de hasta 280 caracteres (previamente 140). Los usuarios tambi´en pueden reaccionar a otros tweets, comparti´endolos mediante retweets, o marc´andolos como favoritos con likes. Adem´as, el uso de hashtags1, permite agrupar tweets relacionados entre s´ı. Adem´as de los movimientos mencionados anteriormente, hay muchas otras iniciativas que han utilizado Twitter como medio de difusi´on. Por ejemplo, #MeToo [54], nacido en 2017, para denunciar los abusos y agresiones sexuales por parte de productores de Hollywood, o #BlackLivesMatter [9], que denuncia la opresi´on de la comunidad negra ejercida por el estado y las autoridades. Twitter ha permitido y contribuido a la creaci´on de espacios seguros donde 1Palabras sin espacios precedidas del s´ımbolo # 8 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE las personas se unen para denuncias, crear colectivo y apoyarse mutuamente. 3.1.2. An´alisis de lenguaje natural y web scraping Hemos hablado de la gran cantidad de datos e informaci´on ´util que pueden encontrarse en redes sociales, debido a la participaci´on activa de una gran cantidad de gente. Nos planteamos c´omo extraer y analizar esos datos, la mayor parte de los cu´ales se encuentran en formato texto. 3.1.2.1. An´alisis de lenguaje natural El procesamiento del lenguaje natural, o NLP por sus siglas en ingl´es, es un campo en la intersecci´on entre la inteligencia artificial y las ciencias del lenguaje que permite a la inform´atica analizar, interpretar y comprender el lenguaje humano. Entre las distintas aplicaciones de esta tecnolog´ıa podemos encontrar las siguientes. Clasificaci´on de textos La clasificaci´on de textos [59, 49, 21] consiste en, a partir de una muestra, extraer informaci´on relevante que permita clasificarla en una clase de entre un conjunto de ellas. Dependiendo de c´omo se lleve a cabo esta clasificaci´on, existen 3 principales sistemas. Rule-based systems La clasificaci´on de textos se realiza utilizando un conjunto de reglas ling¨u´ısticas hechas a mano. Estas reglas tienen en cuenta una serie de elementos del texto que les permiten identificar a qu´e clase pertenecen. Sin embargo presentan grandes desventajas: •Por una parte requieren un amplio conocimiento sobre los temas que se est´an clasificando, para saber qu´e palabras se usan en cada contexto. •Requieren de muchas pruebas y cambios para que funcionen correctamente, lo que se traduce en mucho tiempo de desarrollo. •Son dif´ıcilmente escalables, puesto que las nuevas reglas pueden llegar a afectar a las ya existentes. Machine learning-based systems A partir de textos de ejemplo preseleccionados, tambi´en conocidos como corpus, los algoritmos de machine learning aprenden a clasificar textos gracias a m´etodos estad´ısticos que les permiten crear su propias reglas. La principal ventaja de este tipo de sistemas es precisamente su escalabilidad, no requieren de a˜nadir reglas manualmente porque basta con ampliar el corpus. Adem´as, son generalmente m´as precisos que los sistemas basados en reglas, ya que no requieren un profundo conocimiento del tema. Lamentablemente, son menos explicables que estos ´ultimos, un peque˜no cambio en el corpus de entrenamiento puede alterar completamente el funcionamiento del sistema sin conocer 9 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE su causa. Finalmente, observamos que se debe tener en cuenta que requieren de corpus preseleccionados que cumplan con las caracter´ısticas necesarias para entrenar al modelo, dependiendo de los textos necesarios puede hacerse dif´ıcil encontrar uno adecuado y crear uno a mano requiere de mucho tiempo y esfuerzo. Hybrid systems Los sistemas h´ıbridos son una complementaci´on de los anteriores sistemas. Machine Translation La Machine Translation (MT) [87, 31, 47] es la traducci´on autom´atica entre textos de habla humana. Destacamos las siguientes variantes. Rule-based MT Se basa en el empleo de un conjunto de reglas dise˜nadas por expertos ling¨uistas. El proceso de an´alisis parte de extraer informaci´on de morfemas, categor´ıa gramatical de las palabras que forman el texto (part of speech), named entity (es decir reconocer y clasificar nombres propios de personas, organizaciones, fechas ) y word sense disambiguation (reconocer cu´al de las posibles acepciones que una palabra tiene es la que se est´a usando). Tras este proceso, se lleva a cabo una traducci´on de las palabras ra´ız del idioma original a las palabras ra´ız del idioma a traducir, y luego se traducen los sufijos. Finalmente, se lleva a cabo una correcci´on del g´enero y n´umero de las palabras. Statistical MT Emplea modelos estad´ısticos que asumen que la traducci´on de todas las palabras del lenguaje al que se traduce est´an correctamente traducidas con una cierta probabilidad. Cuanta mayor sea la probabilidad mejor es la traducci´on de esa palabra. Para ello se usan textos anteriormente traducidos y combinan las palabras en todas las posibles posiciones, lo que resulta en una base de datos de traducciones. Neural MT Utiliza redes neuronales combinadas, normalmente, con Statistical MT para obtener mejores resultados. Son las m´as complejas pero tambi´en las m´as efectivas. Syntax-Based MT Son una subcategor´ıa de las Statistical MT pero llevan a cabo traducciones de unidades sint´acticas en lugar de palabras. Natural Language Generation Es un proceso que permite transformar datos en textos comprensibles por los seres humanos. Distinguimos las siguientes etapas. Content Determination: Se prioriza qu´e parte del contenido es el que se va utilizar. 10 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE Data interpretation: Se lleva a cabo una interpretaci´on, con el fin de reconocer los datos que se quieren mostrar. Document planning: Los datos se organizan para poder crear una estructura narrativa acorde al ´ambito en el que se va a utilizar el algoritmo. Sentence Aggregation: Se agregan aquellas frases que tengan cierta cohesi´on contextual entre ellas. Grammaticalization: Se revisa la gram´atica, ortograf´ıa y los signos de puntuaci´on. Language Implementation: Finalmente, se muestra el texto en los formatos adecuados dependiendo de los usuarios a los que va destinado. Tokenization, Lematizaci´on y Stemming Debido a la riqueza usual en los lenguajes como las distintas partes de una oraci´on (verbos, sustantivos, adverbios, adjetivos), la existencia de g´eneros o incluso los distintos tiempo verbales, es necesario el procesamiento de las palabras para poder reducirlas a un formato com´un m´as sencillo [45, 88]. La Tokenizaci´on es un proceso mediante el cual las palabras de una sentencia se dividen en espacios individuales, de esta forma se pueden obtener las palabras que conforman una frase o porci´on de texto. La Lematizaci´on reduce una palabra a su lema, que es la forma en que esa palabra est´a representada en el diccionario. Para poder llevar a cabo este proceso se emplean diccionarios en diferentes lenguas y an´alisis morfol´ogicos sobre estas palabras, con el fin de encontrar su similitud con las palabras del diccionario. El Stemming elimina los sufijos de las palabras, pero no se debe confundir con la Lematizaci´on, puesto que este proceso extrae el sufijo de las palabras atendiendo a una lista con sufijos y prefijos com´unmente usados y aplicando sobre las palabras an´alisis morfol´ogico. Observamos que no siempre funciona correctamente en todas las ocasiones, ya que puede detectar como sufijo o prefijo un conjunto de letras que pueden formar parte de la ra´ız de la palabra. Junto con estos procesos existen otros que permiten eliminar palabras de los textos que puedan entorpecer la clasificaci´on de los mismos. Uno de los m´as famosos es el Stopword removal. El Stopword Removal [118] es un proceso en el que se eliminan un serie de palabras sin significado alguno dentro de una oraci´on, las palabras vac´ıas o stopwords. Son palabras ampliamente usadas que no contienen un significado mayor a darle un sentido de construcci´on de las frases, son eliminadas a fin de reducir el tama˜no del texto a analizar (lo que implica menor procesamiento). Una gran cantidad de bibliotecas NLP emplean estos procedimientos casi de manera invisible para el usuario. 11 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE En la figura 3.1 ilustramos un ejemplo de aplicaci´on de algunos de estos procesos. Figura 3.1: Comparaci´on entre Lemmatization y Stemming Evaluaci´on de clasificaci´on de textos Para poder evaluar el desempe˜no de un sistema de clasificaci´on de textos se emplean matrices de confusi´on [45]. La matriz de confusi´on es una tabla que representa los valores obtenidos frente a los valores reales. Enfrenta lo que el sistema ha clasificado frente a lo que realmente es. Como se puede ver en la figura 3.2, es un matriz 2×2en la que las filas representan los valores predichos por el algoritmo y las columnas los valores reales de la clasificaci´on (es decir, los valores que deber´ıa predecir). Los valores num´ericos que se situaran en la matriz representar´ıan el n´umero de muestras que han sido predichas de una manera frente a lo que realmente son dependiendo de la posici´on en la que se situase. Poniendo como ejemplo de sistema de clasificaci´on de textos el nuestro, en el que se busca reconocer si un texto es una denuncia o no, los valores representados ser´ıan los siguientes: Esquina superior izquierda: N´umero de verdaderos positivos (VP), es decir, n´umero de muestras que han sido predichas como denuncias y realmente lo eran. Esquina superior derecha: N´umero de falsos positivos (FP), es decir, n´umero de muestras que han sido predichas como denuncias err´oneamente. 12 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE Figura 3.2: Matriz de Confusi´on Esquina inferior izquierda: N´umero de falsos negativos (FN), es decir, n´umero de muestras que han sido predichas como no denuncias err´oneamente. Esquina inferior derecha: N´umero de verdaderos negativos (VN), es decir, n´umero de muestras que han sido predichas como no denuncias y han acertado. Cuanto mayores sean los valores de los verdaderos positivos y negativos y menores los de los falsos positivos y negativos mejores estad´ısticas poseer´a nuestro algoritmo. A continuaci´on detallaremos cu´ales son las principales m´etricas, que se obtienen a partir de la matriz de confusi´on, para determinar el desempe˜no de los sistemas de clasificaci´on de texto. Exactitud (accuracy) Accuracy mide el porcentaje de muestras que fueron identificadas correctamente, es decir verdaderos positivos y negativos, entre todas las clasificaciones. Accuracy =V P +V N V P +V N +F P +F N (3.1) Esta m´etrica puede parecer fundamental pero no se usa en clasificaci´on de textos. La raz´on es que no es adecuada si el n´umero de clases predichas es muy distinto entre si. Por ejemplo, si nuestro algoritmo predijera un n´umero de denuncias mucho menor que 13 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE los que predice como no denuncias el accuracy ser´ıa muy alto, pero eso no significar´ıa que nuestro algoritmo fuera capaz de reconocer cu´ales son denuncias. Precisi´on (precision) Precision mide el porcentaje de muestras que el sistema predijo como positivo y fueron realmente positivo, lo que ser´ıa el porcentaje de verdaderos positivos entre todos los positivos. Precision =V P V P +FP (3.2) Exhaustividad (recall) Recall mide el porcentaje de muestras que fueron correctamente identificadas por el sistema, es decir verdaderos positivos y negativos. Recall =V P V P +FN (3.3) Se obtiene dividiendo los verdaderos positivos entre la suma de verdaderos positivos y falsos negativos. De esta manera cuantos m´as falsos negativos haya menor ser´a la m´etrica, lo que indicar´a que no es capaz de reconocer qu´e no es una denuncia. Medida F (F-measure) Ambos Precision yRecall representan la capacidad que tiene el algoritmo para reconocer qu´e es una denuncia y qu´e no, al contrario que Accuracy. Sin embargo mantener ambos valores altos no es algo sencillo, puesto que cambiar el algoritmo para aumentar la Precision implica que el Recall se resienta. Su f´ormula viene dada por la siguiente expresi´on: Fβ=(β2+ 1)P·R β2P+R(3.4) Donde el par´ametro βrepresenta cu´al de ambas m´etricas pesa m´as en la valoraci´on. Valores mayores a 1 favorecen al Recall, mientras que los menores a la Precision. Por ello F1es la m´as equilibrada y la m´as usada. Esta formula se obtiene a partir de una media arm´onica entre el Recall y la Precision. La raz´on de usar la arm´onica en vez de la aritm´etica se debe a que la media arm´onica halla valores m´as cercanos al m´ınimo de los valores sobre los que se halla que la aritm´etica. 3.1.2.2. Web scraping Para utilizar las t´ecnicas de procesamiento de lenguaje natural comentadas previamente, es necesario disponer de gran cantidad de datos. En muchas investigaciones, estos datos se obtienen de distintas redes sociales, ya que muchas de ellas proporcionan una API para facilitar la interacci´on con la informaci´on de estas redes. Sin embargo, cuando los datos no se 14 CAP´ ITULO 3. MARCO TE´ ORICO Y ESTADO DEL ARTE El uso de esta t´ecnica favorece que muchas denuncias puedan hacerse sin miedo a que puedan ser censuradas, eliminadas o reportadas posteriormente. Las aplicaciones y proyectos desarrollados para el bien social, buscan un cambio sist´emico hacia hacia una distribuci´on m´as equitativa de la toma de decisiones y beneficios fuera de la cadena de bloques. Adem´as, la mayor´ıa de las tecnolog´ıas blockchain son de c´odigo libre, de esta manera muchos m´as usuarios pueden comprobar, auditar y comprender todo el contenido del c´odigo y de los protocolos. Esto es crucial para explotar esta tecnolog´ıa, ya que es fundamental para el beneficio social, comprobar la calidad de lo que est´a codificado, las arquitecturas que se adoptan y por ´ultimo la seguridad que tienen. Otro de los beneficios que tiene por ser open source es que muchos usuarios pueden construir y desarrollar a partir de trabajos existentes, y as´ı permitir avances en la democratizaci´on de proyectos blockchain. Adem´as, hay otro inconveniente muy com´un hoy en d´ıa, es el tema de la privacidad de los datos. Cada vez m´as, diferentes empresas centralizadas almacenan nuestros datos, para su uso o venta. Por lo tanto, otro de los objetivos de la blockchain, es recuperar los controles democr´aticos en la producci´on y uso de datos dentro de las redes sociales. Esto se consigue gracias a las t´ecnicas de criptograf´ıa, que ofrecen ´unicamente la informaci´on necesaria para una determinada interacci´on digital. La finalidad de todo esto es democratizar cada vez m´as todo con el paso de los a˜nos aprovechando esta tecnolog´ıa. 21 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS Cap´ıtulo 4 Metodolog´ıa y tecnolog´ıas 4.1. Metodolog´ıa Antes de comenzar el proyecto, se cre´o el plan de trabajo que se iba a seguir durante su desarrollo. De esta forma, pudimos determinar c´omo se iba a realizar la gesti´on de los recursos, a nivel de tiempo, humanos y tecnol´ogicos. Para ello result´o esencial establecer la metodolog´ıas que se iban a utilizar. Dedicamos esta secci´on, por lo tanto, a mostrar las metodolog´ıas de dise˜no y software empleadas, haciendo especial hincapi´e en el uso de software libre. Adem´as, mostramos el plan de trabajo seguido y las contribuciones al proyecto de cada miembro del equipo. 4.1.1. Metodolog´ıa de dise˜no y software El objetivo de definir una metodolog´ıa era el de poder establecer un marco de trabajo que nos permitiese estructurar, planificar y controlar todo el proceso de dise˜no y desarrollo de nuestro proyecto. Elegimos seguir un modelo de dise˜no inspirado tanto en el dise˜no centrado en actividad (DCA) como en el dise˜no centrado en usuarios (DCU) [119]. Ambos forman parte del dise˜no centrado en humanos [17], que tiene como objetivo hacer que los sistemas interactivos sean usables y ´utiles para las personas. Su diferencia reside en que el primero se centra en la actividad que los usuarios podr´an desarrollar con la tecnolog´ıa, mientras que la segunda se centra en el usuario y sus necesidades. El dise˜no DCA basa sus fundamentos te´oricos en la Teor´ıa de la Actividad [8], cuya estructura consiste en detectar un motivo, realizar una investigaci´on, ejecutar un plan de trabajo controlado y finalizar con una correcci´on del mismo. Actualmente, aunque es un campo muy estudiado a nivel te´orico, no se ha desarrollado un proceso que permita su implementaci´on, por lo que suele utilizarse a nivel de modelo y no tanto de desarrollo. A diferencia del anterior, DCU s´ı que est´a muy extendido en dise˜no de aplicaciones. Es por ello que existe un proceso claramente definido que permite su implementaci´on; investigaci´on, recogida de requisitos, dise˜no y evaluaci´on. 22 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS Nuestro proyecto, partiendo de una motivaci´on inicial (cap´ıtulo 1), buscaba implementar una serie de tareas llevadas a cabo por un usuario general. Decidimos seguir la estructura del dise˜no DCU, pero focalizando la participaci´on del usuario al final del desarrollo. De esta manera, las fases iniciales pudieron centrarse en estudiar el contexto y las actividades que quer´ıamos implementar para cumplir con nuestros objetivos. El proceso, por lo tanto, consiste en cuatro fases que se van iterando hasta obtener el resultado final. Observamos que no necesariamente tienen que hacerse todas las fases en cada iteraci´on, depender´a del momento del proyecto en el que se est´e y los resultados obtenidos hasta entonces. Investigaci´on: Entender el contexto y las caracter´ısticas del usuario. Requisitos: Establecer requisitos que debe cumplir la aplicaci´on y modelizarla. Dise˜no eimplementaci´on: Dise˜nar e implementar las soluciones. Evaluaci´on: Evaluar las soluciones desarrolladas. Por otro lado, la metodolog´ıa software utilizada ha sido iterativa eincremental de forma que, partiendo de un m´ınimo producto viable, pudi´esemos ir a˜nadiendo funcionalidades. De entre todas las metodolog´ıas ´agiles, nosotros optamos por seguir un modelo simplificado de scrum [104]. ´ Este se caracteriza por tener iteraciones que duran 2-4 semanas (sprints) y reuniones tanto al principio como al final de la misma. Cada iteraci´on, comienza con una definici´on de requisitos y objetivos, y termina con una evaluaci´on de resultados. De esta forma, se controla, de forma colaborativa, la cantidad y calidad de trabajo que se va realizando. Como se ver´a m´as adelante en el plan de trabajo 4.1.3, comenzamos realizando un sprint inicial que permiti´o preparar el proyecto. El resto de sprints contaron con reuniones de seguimiento en las que se comenzaba repasando y evaluando los objetivos del sprint anterior, y posteriormente se establec´ıan los del siguiente. 4.1.2. Metodolog´ıa de software libre El proyecto se ha desarrollado intentando fomentar el uso y creaci´on de software libre. Es por ello que no s´olo hemos intentado utilizar tecnolog´ıas libres, sino que tambi´en hemos escogido licencias para el proyecto que lo fuesen. De esta manera, nuestro c´odigo est´a disponible para toda la comunidad open source, permitiendo que tanto durante el progreso del proyecto como al final del mismo, cualquier persona sea libre de usar, modificar, distribuir y publicar versiones modificadas y mejoradas. El objetivo es conseguir un c´odigo m´as seguro y mantenible a lo largo del tiempo [69]. En nuestro caso, hemos utilizado GitHub para publicar el c´odigo fuente y para poder trabajar de forma colaborativa. El c´odigo est´a bajo la licencia GNU General Public License v3.0 [51]. Tomamos esta decisi´on por el car´acter v´ırico que posee, el cu´al fuerza a que cualquier modificaci´on del c´odigo tenga que ser distribuida con la misma licencia, fomentando y expandiendo el uso de software libre. 23 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS El c´odigo fuente del proyecto se puede encontrar en el siguiente repositorio de Github: https://github.com/injustweet-tfg De la misma manera, para la distribuci´on de la memoria y del contenido creado en la aplicaci´on web, hemos escogido una licencia Creative Commons Attribution 4.0 International [50], que permite copiar y distribuir la obra utilizando la misma licencia (incluido el uso comercial). La aplicaci´on web del proyecto se puede encontrar en el siguiente enlace: https://dashboard-twitter.herokuapp.com/dashboard 4.1.3. Plan de trabajo La planificaci´on y organizaci´on del proyecto se llev´o a cabo utilizando un diagrama de Gantt. Debido a la magnitud del proyecto, esto nos permiti´o llevar un seguimiento de las tareas que se iban realizando y las dependencias existentes entre ellas. Se puede observar en la Figura 4.1. Figura 4.1: Diagrama de Gantt de la planificaci´on En primer lugar, se estableci´o un periodo de trabajo conjunto entre los 6 miembros del grupo. Este periodo sirvi´o para aprender algunas de las principales tecnolog´ıas que se iban a utilizar; React, Solidity y la API de Twitter. Realizamos peque˜nos proyectos que pusimos en com´un y sirvieron para afianzar conceptos. Esto garantiz´o que todo el equipo tuviese los conocimientos necesarios para entender partes del proyecto en las que no fuese a trabajar 24 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS directamente. A continuaci´on, se llev´o a cabo una fase de investigaci´on y recogida de requisitos, que permiti´o definir mejor el problema que quer´ıamos abordar con nuestro TFG (visibilizar situaciones de precariedad laboral en lugares hispanohablantes) y c´omo´ıbamos a llevarlo a cabo. Posteriormente, dividimos el proyecto en tres bloques que trabajaron en paralelo en el dise˜no y la implementaci´on de la aplicaci´on. A partir de este momento, tuvimos reuniones peri´odicas en las cu´ales mostr´abamos nuestro progreso y garantiz´abamos que los tres bloques fuesen coherentes. Gracias a ellas pudimos realizar un seguimiento cercano y colaborativo de los objetivos que se iban cumpliendo. Inicialmente, tuvieron lugar cada 2-4 semanas laborables, y al final del proyecto, cada 1-2. Explicamos, a grandes rasgos, en qu´e consisti´o cada uno: Bloque 1 (Recoger datos): Pablo I.F y Raquel P.G Se encarg´o de la recogida de datos, obtenidos a trav´es de la API de Twitter, y del categorizaci´on de los mismos, para garantizar que fuesen denuncias laborales. Bloque 2 (Guardar datos): Roberto A.L y Juli´an M.B Se encarg´o de recoger los datos proporcionados por el bloque anterior y almacenarlos en la blockchain. Tambi´en se encarg´o de hac´erselos llegar al siguiente bloque. Bloque 3 (Mostrar datos): Javier M.M y ´ Angela R.R Se encarg´o de mostrar los datos obtenidos en un dashboard. Adem´as, gestion´o los accesos a la blockchain y c´omo alimentar a la p´agina web. Finalmente, se estableci´o un periodo que sirvi´o para unificar el proyecto y alcanzar un m´ınimo producto viable. A partir de este momento, se realizaron mejoras sobre el mismo. El proyecto termin´o con una evaluaci´on de resultados que sirvi´o para plantear los posibles trabajos futuros. Adem´as, durante los ´ultimos meses, se document´o el proyecto. 4.1.4. Contribuciones al proyecto Finalmente, utilizamos esta secci´on para mostrar el trabajo realizado por cada miembro del grupo. Comenzamos viendo c´omo se ha organizado y redactado la memoria. Estructura de la memoria, descripciones de las secciones y revisi´on final: ´ Angela y Javier 0.Resumen y abstract: ´ Angela y Roberto 1. Introducci´on: ´ Angela 2. Introduction: ´ Angela 3. Marco te´orico y estado del arte 3.1 Marco te´orico 25 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS 3.1.1 Redes sociales y organizaci´on social: Javier 3.1.2 An´alisis de lenguaje natural: Pablo 3.1.3 Web Scraping: Raquel 3.1.4 Blockchain como tecnolog´ıa descentralizada: Roberto 3.2 Estado del arte: Javier yRoberto 4. Metodolog´ıa y tecnolog´ıas 4.1 Metodolog´ıa 4.1.1 Metodolog´ıa de dise˜no y software: ´ Angela 4.1.2 Software libre: Javier 4.1.3 Plan trabajo: ´ Angela 4.1.4 Contribuciones: Todos 4.2 Tecnolog´ıas: Todos 5. Trabajo previo: ´ Angela y Javier 6. Investigaci´on y recogida de requisitos: ´ Angela y Javier 7. Dise˜no e implementaci´on 8.1 Bloque 1: Pablo y Raquel 8.2 Bloque 2: Juli´an y Roberto 8.3 Bloque 3: ´ Angela y Javier 8. Arquitectura 9.1 Bloque 1: Pablo y Raquel 9.2 Bloque 2: Roberto y Juli´an 9.3 Bloque 3: ´ Angela y Javier 9. Evaluaci´on 10.1 Evaluaci´on usuarios: ´ Angela y Javier 10.2 Evaluaci´on an´alisis lenguaje natural: Pablo y Raquel 10. Conclusiones y trabajo a futuro: 11.1 Conclusiones: ´ Angela y Roberto 11.2 Trabajo a futuro: Todos 11. Conclusions and future work: ´ Angela A continuaci´on, cada miembro del equipo desarrolla en profundidad su aportaci´on al proyecto y el trabajo que ha realizado. 26 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS Roberto Asunci´on L´opez Al inicio del proyecto, comenc´e a indagar sobre la tecnolog´ıa blockchain, ya que desde el momento en que eleg´ı realizar este trabajo me pareci´o un campo muy innovador y con mucha proyecci´on de cara al futuro. Posteriormente, ech´e un vistazo a algunas redes sociales como Twitter e Instagram, para ver c´omo estaba la situaci´on sobre injusticias en el entorno laboral. De esta manera me hice una ligera idea de como pod´ıamos darle visibilidad a este problema. Despu´es de la primera reuni´on pactamos realizar tres peque˜nas pr´acticas, una para aprender React, otra para Solidity y por ´ultimo, una para la API de Twitter. Acordamos esto para que cada miembro pudiera ver que parte le gustaba m´as o con cu´al ten´ıa un mejor desempe˜no. La primera pr´actica que realic´e fue la de Solidity, la cual consist´ıa en hacer un peque˜no sorteo de loter´ıa. Adem´as hice un peque˜no curso en la p´agina web ”Udemy”, para aprender este lenguaje. Posteriormente hice la parte de React, cuyo objetivo era hacer una lista de tareas. ´ Esta tarea me cost´o mucho ya que no me adaptaba a React y lo notaba muy confuso, adem´as me llev´o bastante tiempo y no pude realizar la ´ultima pr´actica. La parte que m´as me gust´o y la que mejor se me daba fue sin duda la de Solidity. A continuaci´on de que todos termin´asemos las pr´acticas nos dividimos el proyecto en tres grupos de dos personas cada uno. Los dos primeros grupos, se centraban en el back-end de la aplicaci´on y el ´ultimo, se ocupaba del front-end. El primer grupo integrado por mis compa˜neros Pablo y Raquel, se someti´o a trabajar con la API de Twitter y as´ı obtener denuncias. El segundo grupo, el cual particip´e junto con mi compa˜nero Juli´an, se encargaba de recoger los datos que la parte de Twitter recog´ıa, y los almacenaba en la blockchain interactuando mediante un contrato inteligente. Por ´ultimo, la parte de React, integrada por ´ Angela y Javier, se ocup´o de obtener las denuncias de la blockchain y mostrarlas a trav´es de una p´agina web mediante estad´ısticas, gr´aficas, wordclouds, etc. Una vez tuvimos la reuni´on donde nos dividimos las partes. Juli´an y yo comenzamos a desarrollar un smart contract muy simple, que almacenaba (get) y devolv´ıa una variable (set) y as´ı poder probar las funciones del contrato desde fuera de este. Una vez ten´ıamos el contrato nos surgi´o la duda de c´omo pod´ıamos desplegarlo en redes de prueba, ya que cre´ıamos que desde Remix no se pod´ıa. Empezamos a usar la herramienta Truffle para desplegar el contrato e interactuar con ´el. Debido a la cantidad de problemas que nos daba utilizar esta herramienta, pensamos en otras alternativas. Finalmente opt´e por utilizar el mismo Remix, ya que descubr´ı que daba la posibilidad de desplegarlo en varias redes de prueba. Me encargu´e de crear una cuenta de Metamask asociada al proyecto y de introducir ethers de prueba para operar en la red de Ropsten. Adem´as de esto utilic´e Infura como infraestructura para las llamadas al contrato. Mediante Remix utilizaba el ABI generado al compilar el smart contract, para crear un archivo JSON y a˜nadirlo al proyecto. A continuaci´on de esto me ocup´e de documentarme bien sobre la biblioteca ”web3” para interactuar con el contrato e instanciarlo. Tuve bastantes problemas a la hora de llamar a las funciones del contrato ya que dependiendo de c´omo estuviera programado, se llamaban de una manera o de otra. Para las funciones que fueran ”view”ten´ıa que a˜nadir ‘call‘ y para las que no lo fueran, ten´ıa que a˜nadir ‘send‘ junto con un par´ametro ‘from‘ con la direcci´on de la billetera de metamask que utiliz´abamos para el 27 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS traspaso de ethers. Finalmente logr´e realizar la conexi´on con el contrato y llamar as´ı a sus funciones de forma correcta. A continuaci´on despu´es de otra reuni´on con nuestros tutores, nos dimos cuenta de que necesit´abamos una plataforma para almacenar las denuncias. Guardar tantas denuncias en un smart contract era inviable. Despu´es de investigar diferentes opciones optamos por utilizar IPFS para guardar la informaci´on de los tweets. El siguiente paso a realizar fue el desarrollo de una API para que nuestros compa˜neros pudieran interactuar con nosotros m´as f´acilmente. Optamos por usar “Express“ y realic´e dos peque˜nos m´etodos GET y POST. El m´etodo GET devolv´ıa un array simple con tres tweets de prueba que cog´ı de ejemplo. El m´etodo POST simplemente a˜nad´ıa un ‘hola mundo‘ a la API. Despu´es enlac´e el c´odigo de la API con la parte que interactuaba con el contrato (“Web3“) y funcionaba de forma correcta sin problemas de dependencias. El problema surgi´o cuando enlac´e la API con la parte de IPFS que mi compa˜nero Juli´an realiz´o. Aparecieron numerosos errores muy confusos que nos imped´ıan progresar en el proyecto. Me llev´o mucho tiempo investigar de donde ven´ıan estos problemas y finalmente descubr´ı que eran por temas de dependencias y versiones de las librer´ıas. Despu´es de una reuni´on con uno de nuestros tutores, arregl´e el problema actualizando todas las librer´ıas y borrando la cach´e de npm (NodePackageManage) y del proyecto. Resolver este problema fue crucial ya que estuvimos muchos d´ıas intentando solucionarlo y nos ralentiz´o mucho las tareas. Una vez ten´ıamos la API enlazada con “Web3“ y con IPFS empec´e a mejorar el smart contract por mi cuenta para que tuviera las funciones que realmente necesit´abamos. A˜nad´ı estructuras para almacenar los hashes devueltos por IPFS y para almacenar los identificadores de los tweets. Adem´as agregu´e funciones adicionales para insertar hashes e identificadores, y otra para devolverlos. Aunque finalmente utilizamos el contrato que mi compa˜nero Juli´an implement´o. Probamos para comprobar su correcto funcionamiento. Despu´es de que tuvi´eramos el contrato modificamos los m´etodos POST y GET de la API para que tuvieran el comportamiento real. El m´etodo GET fue modificado para que devolviese los hashes de los ficheros almacenados en el contrato y con cada uno de ellos obtener la informaci´on de las denuncias de IPFS. M´as tarde mi compa˜nero se encarg´o de comprobar que estuvieran actualizados. Si no estaban actualizados se encargaba de hacerlo. Por otro lado el m´etodo POST lo modificamos para que subiera el contenido de las denuncias a la API y a IPFS, adem´as almacenaba el hash devuelto por este ´ultimo en el contrato. Posteriormente nos surgi´o otro problema. La API que desarrollamos estaba gestionada de forma local en nuestro ordenador. Nuestros tutores nos aconsejaron que utiliz´asemos una plataforma para mantenerlo, ya que en local no era viable. Nos pusimos manos a la obra. Pens´e en numerosas opciones tales como “Amazon Web Services (AWS)“, “Google Cloud“, “Heroku“, etc. Finalmente, nos recomendaron “heroku“ y me pus´e a implementarlo con nuestro proyecto. Me cre´e una cuenta de heroku y despu´es de varias gu´ıas de instalaci´on logr´e enlazarlo con 28 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS nuestra aplicaci´on. Asimismo surgieron errores a la hora de subir nuestro c´odigo a “Heroku“, ya que no funciona de la misma manera que tener la aplicaci´on en local. Instal´e algunas dependencias m´as que la aplicaci´on requer´ıa y pude solucionar estos errores. Una vez hecho esto, Juli´an y yo pod´ıamos subir nuestra aplicaci´on al servidor de “Heroku“ e ´ıbamos actualiz´andolo seg´un correg´ıamos y a˜nad´ıamos funcionalidades. Los ´ultimos d´ıas, considerando que ya ten´ıamos el proyecto casi terminado nos preocupamos de observar y solucionar errores que surg´ıan cuando enlaz´abamos todas las partes de la aplicaci´on. Tuvimos algunos problemas debido a que algunos tweets no se sub´ıan a la API de la forma correcta. Pero, buscamos soluciones y Julian los solvent´o. Tambi´en tuvimos el inconveniente de que nos est´abamos quedando sin ethers de prueba, debido a que la red de Ropsten increment´o el coste en gas. Tuve que averiguar qu´e p´aginas suministraban estos tokens, ya que muchas de las p´aginas que usamos al principio ya no estaban operativas. Por ´ultimo me centr´e bastante en redactar mis partes de la memoria, partes generales y la gran mayor´ıa de las partes de blockchain, as´ı como de mantener muchas reuniones con el resto de compa˜neros para asegurarnos de que todo iba por buen camino. Tuvimos un problema de ´ultima hora, ya que la red de Ropsten empez´o a tener cantidades desorbitadas de gas para ejecutar las transacciones. Me ocup´e de cambiar la red a Rinkeby y desplegar el contrato en ´esta junto con mi compa˜nero Juli´an. Pablo Imbert Fern´andez Una vez confirmamos nuestra participaci´on en este proyecto decid´ı investigar de los lenguajes que ´ıbamos a utilizar, ya que me interesaba programar en un lenguaje nuevo que fuera ampliamente utilizado. Habi´endonos asignado una serie de pr´acticas para poder tener una visi´on m´as global del proyecto, realic´e la pr´actica de Blockchain y de React, la pr´actica de Twitter no pude realizarla por falta de tiempo. Inicialmente estaba m´as interesado en la parte de React, a pesar de haber encontrado dificultades sab´ıa que era un framework bastante usado, o la parte de Blockchain, que fue la que primeramente me atrajo al proyecto. Sin embargo, al haber utilizado anteriormente Python conjuntamente con la API de Twitter en una asignatura del grado, Raquel y yo decidimos encargarnos de la parte de recolecci´on de datos, ya que pensamos que as´ı ahorrar´ıamos tiempo y podr´ıamos ayudar al resto de bloques. Tiempo despu´es descubrimos que no podr´ıamos ayudar en otras partes del proyecto, dada la longitud de nuestro bloque. Inicialmente desarrollamos un peque˜no prototipo con el que poder utilizar las funcionalidades de la API de Twitter, empleamos distintas tecnolog´ıas recurrentes en el campo de NLP (tokenization, lemmatization, sentiment analysis). La creaci´on del diccionario a partir de publicaciones de Instagram usando la API de Instagram, as´ı como la obtenci´on de sus estad´ısticas fueron realizadas en su mayor´ıa por mi compa˜nera Raquel, debido a que por problemas de librer´ıas no fui capaz de ejecutar el c´odigo, por lo que mi participaci´on estuvo sujeta a que Raquel pudiera compartir pantalla y ayudarla en lo posible. Sin embargo las decisiones tomadas sobre las palabras que conformaron el diccionario final fueron realizadas conjuntamente. 29 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS Tras tener ciertos problemas con la revelaci´on de tokens de Twitter y cuentas y contrase˜nas de Instagram en Github incorpor´e una serie de modificaciones al c´odigo, con el objetivo de mantenerlos a salvo. Para ello agreg´e un sistema de manejo de tokens basado en archivos .env, los cuales no son subidos a Github gracias a la creaci´on de un archivo .gitignore (que permite ignorar ciertos archivos). En el caso de la cuenta de Instagram agreg´e un manejo de claves que empleaba el keyring del sistema Linux (llavero). Una vez el diccionario fue terminado, retomamos el desarrollo de la interacci´on con el API de Twitter. Tras detectar ciertos problemas para recoger el hist´orico de datos, decidimos emplear la librer´ıa de tweepy para recoger los tweets a tiempo real. En mi caso dediqu´e una gran cantidad de tiempo a la puesta en marcha del Listener, as´ı como conseguir que obtuviera los campos necesarios de cada tweet. Para poder hacer que funcionara correctamente toda la l´ogica del programa, fue necesaria la incorporaci´on de una Base de datos de Mongo, as´ı como su conexi´on desde el c´odigo. Esta parte fue desarrollada por mi, primeramente en local y m´as tarde con un servidor en la nube. Tras descartar utilizar la API de Twitter para la recolecci´on de datos con cierta antig¨uedad, nuestro codirector nos sugiri´o emplear un Scraper Web,snscrape. El c´odigo de esta nueva modalidad fue desarrollado a partir del existente por mi compa˜nera. Paralelamente trat´e de subir nuestros c´odigos a los servidores de Heroku. Sin embargo, y tras muchos intentos, no conseguimos incorporar el c´odigo al servidor. Se nos ocurri´o la idea de utilizar los famosos servidores de Amazon Web Services, por lo que cre´e una cuenta student para poder utilizar las instancias EC2, desde la que poder ejecutar nuestro c´odigo. La puesta en funcionamiento supuso una gran cantidad de tiempo, debido a las dificultades que presentaban la instalaci´on de la versi´on de Python con la que hab´ıamos desarrollado todo el proyecto y la cantidad de errores de lo m´as variopintos por la instalaci´on de librer´ıas y sus dependencias. Tambi´en fue necesario modificar las reglas de conexiones HTTP, HTTPS ySSH para obtener los datos del API de Twitter y , posteriormente, la BDD. Debido a los recursos limitados de las instancias que utilizamos, pensamos en dejar de usar una base de datos local, por lo que llev´e a cabo la migraci´on de MongoDB aMongoDB Atlas, cuyo servidor tambi´en es proporcionado por AWS. Todo esto supuso cambiar la direcci´on de la BDD a la que se conectaba el c´odigo, junto a la creaci´on de usuarios, habilitaci´on de IP´s y dem´as. Es necesario mencionar que cont´e con la ayuda de mi compa˜nera durante todo este proceso. El m´etodo de ejecuci´on de la API, proporcionada por el equipo de Blockchain, desde Python fue desarrollada conjuntamente con mis compa˜neros Raquel y Juli´an. La puesta en funcionamiento en los servidores fue realizada principalmente entre Juli´an y yo. Tambi´en ha habido varias modificaciones y soluciones de errores en el c´odigo que han sido realizadas tanto por Raquel, como por m´ı, pero su poca importancia en el funcionamiento general del programa implica su no menci´on en esta secci´on de la memoria. 30 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS puestas similares con peque˜nas modificaciones que decid´ı realizar para poner a prueba mis conocimientos. La siguiente tecnolog´ıa que abarqu´e fue la aplicaci´on para crear y eliminar listas de React. Ya que esta tecnolog´ıa est´a en auge, decid´ı dedicarle el mayor tiempo, investigando distintas formas de realizarla, leyendo una extensa bibliograf´ıa y visualizando varios tutoriales. Finalmente, como preparaci´on para la parte de la API de Twitter, consider´e lo m´as importante entender qu´e tipo de denuncias se podr´ıan encontrar en esta red social. Para ello, realic´e una b´usqueda exhaustiva sobre hashtags con denuncias, como por ejemplo sobre denuncias en el sector art´ıstico d´onde les hab´ıan robado sus dise˜nos. De esta parte saqu´e en claro que tipo de vocabulario ver´ıamos m´as adelante durante el desarrollo. Una vez adquiridos unos conocimientos que consideramos base, realizamos la divisi´on del trabajo. Pablo y yo nos encargar´ıamos de la parte de recolecci´on de datos, pues ya hab´ıamos trabajado con anterioridad con la API de Twitter y cre´ıamos que est´a familiaridad nos ayudar´ıa a realizarlo de manera m´as efectiva y nos permitir´ıa ayudar al resto de compa˜neros con otras partes del proyecto. M´as adelante nos dimos cuenta que al tratarse est´a parte del motor del trabajo, requerir´ıa una cantidad de trabajo que no pudimos prever. Esto se debe a que, si el algoritmo para recoger denuncias no era eficiente o si tanto el contenido como la forma en la que lo que almacen´abamos creaba cualquier discordancia, afectar´ıa directamente a la viabilidad del producto final. Por eso, lo primero que hice fue investigar sobre dashboards ywordclouds. Esto tiene importancia porque al ser una tecnolog´ıa que sab´ıa que mis compa˜neros del front-end iban a usar, quer´ıa conocer que tipo de informaci´on podr´ıan necesitar y en que formato para que Pablo y yo pudi´eramos programar de forma eficiente. De este modo, pretend´ıamos evitar cambios mayores una vez tuvi´eramos el algoritmo ya avanzado. Tanto Pablo como yo hemos realizado el trabajo pr´acticamente de forma conjunta, pues siempre que era posible qued´abamos para ayudarnos ya fuera con la resoluci´on de bugs o para compartir nuestros avances. Sin embargo, s´ı hay algunas distinciones sobre qu´e hizo cada uno. Nuestro primer trabajo fue la b´usqueda de un corpus de denuncias en Twitter. Como hab´ıamos aclarado con nuestro codirector ´ıbamos a usar una cuenta de Twitter llamada mierdaJobs para extraer los tweets, realizar el an´alisis de sentimientos y crear el diccionario. El primer problema con el que nos encontramos fue ver que la mayor´ıa de usuarios utilizaban im´agenes para compartir conversaciones u otro tipo de contenido multimedia que ve´ıan relevantes. Nuestra primera idea para solucionarlo fue, mediante el uso de librer´ıas de reconocimiento de texto en im´agenes, leer las conversaciones de las fotos para despu´es realizar el sentiment analysis del texto entero. Esta parte la realic´e principalmente yo con el apoyo 37 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS continuo de mi compa˜nero, pues por problemas t´ecnicos de dependencias entre librer´ıas que eran necesarias, a ´el le resultaba imposible ejecutar el c´odigo en su port´atil. Nuestra forma de trabajar consist´ıa en compartir mi pantalla mientras ´el me iba comentando posibles mejoras o errores en el c´odigo. Nos dimos cuenta pronto de la inviabilidad de hacer esto, pues el texto del tweet sol´ıa ser ir´onico y porque las conversaciones conten´ıan caracteres que no terminaban de reconocer bien. Por esto, hablando con nuestro codirector, llegamos a la conclusi´on de pasar a la API de Instagram pues encontramos una cuenta con denuncias reales de m´ultiples usuarios sobre distintas empresas. De esta parte tambi´en me encargu´e yo principalmente por los motivos citados anteriormente. Aqu´ı hubo una curva de aprendizaje para entender como funcionaba la API de Instagram, pero una vez hecho este trabajo, extrajimos un gran n´umero de publicaciones y creamos el diccionario a partir de la frecuencia con la que se usaba cada palabra en cada texto. Como quer´ıamos que el diccionario fuera lo m´as fiel a la realidad, limpiamos los textos de caracteres especiales, hicimos stemming ylemmatization adem´as de limpiar nombres propios de empresas. Despu´es ambos limpiamos bien el diccionario, realizando de forma conjunta las tres iteraciones para ver cual ser´ıa nuestro diccionario final. Una vez nuestro codirector nos dio el visto bueno, comenzamos a calcular si ´este era o no eficaz. Por eso, busqu´e varios corpus de tama˜nos similares a las publicaciones que no hab´ıamos llegado a extraer y saqu´e la matriz de confusi´on adem´as de varias m´etricas que nos hicieron ver que el algoritmo funcionaba. Una vez realizado este trabajo, volvimos a Twitter. Lo primero que intent´e llevar a cabo fueron consultas a la API, pero estas devolv´ıan un peque˜no n´umero de denuncias y de una antig¨uedad m´axima de una semana. Por eso, mi compa˜nero Pablo decidi´o centrarse en investigar como funcionaban los Listeners para poder recoger tweets en Streaming. En esta parte se centro principalmente ´el, pues yo estaba teniendo problemas con mi acceso a la API de Twitter tras realizar demasiadas peticiones con el primer m´etodo. Tambi´en se encarg´o ´el de conectar el algoritmo a MongoDB, primero de forma local, que me ense˜no adem´as a m´ı a utilizar, para que pudi´eramos ejecutar los dos el c´odigo con distintas fechas y recoger as´ı m´as denuncias. Esto mismo lo realiz´o luego en MongoDB Atlas, que gestion´o ´el con sus claves. Yo en est´a parte serv´ı principalmente de apoyo para la resoluci´on de errores que iban apareciendo a cada paso. Una vez montamos esto, vimos que recog´ıamos muy pocas denuncias, por lo que hablando con el codirector decidimos hacer uso de scrapers para recoger el hist´orico de tweets, ya que mediante la API de Twitter no ten´ıamos acceso al mismo. De esta parte me encargu´e principalmente yo, pues mi compa˜nero estaba empezando a estudiar c´omo podr´ıamos subirlo a un servidor de forma gratuita. El mayor problema que se nos presentaba era que muchas de las versiones de prueba solo permiten el uso de un hilo y, por el dise˜no del streaming, ya se usaban dos. De todas formas, mi compa˜nero estuvo ayud´andome siempre que le necesit´e para resolver dudas, ya fueran de concepto o de c´odigo. 38 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS Finalmente utilizamos AWS. Para subirlo aqu´ı, mi compa˜nero dedic´o una gran cantidad de tiempo, pues al utilizar una instancia con una versi´on antigua de Debian hubo muchos problemas de incompatibilidades ya fuera con Python o con distintas conexiones. ´ El tuvo que realizar un gran trabajo de investigaci´on para que funcionar´a. Ya que ten´ıamos que utilizar una misma cuenta y para AWS se utilizan los datos bancarios, cre´ımos que era mejor si solo uno usaba la cuenta. Por eso, yo en esta parte me dediqu´e a observar y ayudar a mi compa˜nero cada vez que encontraba alg´un fallo que llevaba mucho tiempo. Adem´as, hubo muchos problemas con el servidor para la habilitaci´on de puertos y de IPs. En estos fallos pude ayudar m´as a mi compa˜nero, pues por temas de trabajo estaba familiarizada con este tipo de errores. Lo ´ultimo que hemos tenido que realizar fue la API para conectarnos con el grupo de Blockchain. Juli´an nos paso el c´odigo a Pablo y a m´ı y hemos tenido que investigar como implementarlo. Hemos pasado mucho tiempo los tres intentando solucionar cada error que iba surgiendo y viendo como pod´ıamos conectarla con Python. Adem´as, ha llevado mucho tiempo entender porque funcionaba en local y no en el servidor, o porque funcionaba al realizar la llamada a la API desde la terminal pero no desde el c´odigo. Esta ultima parte nos ha llevado incontables horas a cada uno, yo intentado averiguar como hacer que funcionara en local, Pablo intent´andolo en el servidor, y Juli´an estudiando los logs que devolv´ıa para ver que pod´ıa estar fallando y debuggear as´ı el c´odigo. Cabe mencionar tambi´en el gran trabajo de investigaci´on para cada una de las tecnolog´ıas que usamos adem´as del tiempo dedicado a la resoluci´on de errores o de incompatibilidades entre las distintas librer´ıas y m´odulos. Esto fue realizado por los dos por igual. ´ Angela Ruiz Ribera Comenc´e definiendo, junto con el resto de mis compa˜neros, el objetivo que iba a perseguir nuestro TFG, y c´omo ´ıbamos a llevarlo a cabo. Para ello, busqu´e informaci´on sobre iniciativas que tratasen temas de injusticia laboral (Smart,#FightFor15...), y particip´e activamente en la planificaci´on realizada. En particular, durante el desarrollo del proyecto, me encargu´e de llevar acta de las reuniones que ten´ıan lugar y organizar las sesiones para que se tratasen todos los temas y se fijasen objetivos. A continuaci´on, dediqu´e un periodo de tiempo a aprender sobre los tres campos en los que´ıbamos a trabajar; desarrollo web, blockchain y an´alisis de lenguaje natural. Desarroll´e una aplicaci´on en React que permit´ıa crear y eliminar listas de tareas. Esto me permiti´o familiarizarme con javascript,CSS yHTML. Adem´as, aprend´ı los dos paradigmas de programaci´on en React; los componentes clase usados antiguamente y los funcionales, introducidos en la versi´on 16.8. Por otro lado, implement´e un Smart Contract usando Solidity yRemix que imitaba una loter´ıa. Nunca antes hab´ıa usado dicha tecnolog´ıa, por lo que dediqu´e la mayor 39 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS parte del tiempo a documentarme. Finalmente, le´ı e hice un repaso de conceptos relacionados con an´alisis de lenguaje natural. Todo ello lo puse en com´un con mis compa˜neros con el fin de afianzar conceptos. Gracias a este trabajo, creamos una base de conocimiento que nos permiti´o entender partes del proyecto en las que no ´ıbamos a trabajar de forma directa. Llegados a este punto, decidimos distribuirnos el trabajo en funci´on de los tres campos que he mencionado con anterioridad. Un grupo se encarg´o de la recogida de datos con an´alisis de lenguaje natural, otro del almacenaje de los mismos usando tecnolog´ıas distribuidas y, finalmente, un ´ultimo en dise˜nar y construir el frontend de la aplicaci´on. Por lo tanto, a partir de este momento, trabaj´e junto con Javier Mulero Mart´ın en el desarrollo del frontend de la aplicaci´on. Dediqu´e una fase de trabajo a investigar y definir requisitos, ya con el objetivo del TFG determinado (implementar una p´agina web que mostrase datos sobre situaciones de precariedad laboral, sin censura y en forma de dashboard). Esto me permiti´o entender mejor al usuario objetivo, as´ı como el tipo de datos que quer´ıamos mostrar y las caracter´ısticas que deb´ıa tener nuestra aplicaci´on. Posteriormente, comenzamos con las fases de dise˜no e implementaci´on, que ocuparon la mayor parte del proyecto. Dise˜namos bocetos que fueron incrementando su grado de fidelidad (en papel y Balsamiq), a la vez que aprend´ıamos sobre desarrollo web. Cree un proyecto en React en el que fu´ı probando distintas librer´ıas de visualizaci´on gr´afica (recharts,visx onivo) y dise˜no web (Bootstrap,Material UI...). Adem´as, haciendo uso de plantillas y bibliograf´ıa, profundic´e mis conocimientos sobre enrutamiento dentro de una p´agina, componentes funcionales y uso de Hooks. Todo ello lo puse en com´un con Javier, qui´en comparti´o conmigo las pruebas que hab´ıa realizado ´el. Una vez establecido el dise˜no inicial, y tomando como referencia una plantilla, realizamos la primera implementaci´on del dashboard. Cabe destacar que la mayor parte del desarrollo que hicimos a partir de este momento fue conjunto, haciendo uso de la herramienta LiveShare de Visual Studio Code, que nos permit´ıa trabajar en el mismo proyecto en tiempo real. El primer producto que creamos contaba con los siguientes componentes; 4 tarjetas para mostrar totales, 1 wordcloud, 2 tarjetas para mostrar rankings, 1 visualizador de tweets, 1 gr´afica temporal y 1 l´ınea de tiempo de doble eje. La estructura del proyecto, y los 4 componentes de totales, los implementamos juntos. El resto, los repartimos equitativamente. Yo me encargu´e del wordcloud, un ranking y la l´ınea de tiempo. Para comprobar su funcionamiento, utilizamos un fichero de datos de prueba. Posteriormente, dichos componentes sufrieron modificaciones en las que participamos tanto Javier como yo. El siguiente paso, fue ver c´omo obtener los datos que estaba almacenando otro grupo en IPFS. En ese momento, nos dimos cuenta de que dichos accesos pod´ıan resultar muy costosos, por lo que decidimos construir una base de datos que funcionase como una ”memoria cach´e”. Es decir, esta BBDD se actualizar´ıa cada dos d´ıas con datos de IPFS y ser´ıa la encargada de 40 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS proporcionar informaci´on a la p´agina web. Por lo tanto, a partir de este momento, comenzamos a desarrollar tres proyectos en paralelo; la p´agina web (dashboard-twitter), uno encargado de hacer consultas a la BBDD (cache-twitter) y un ´ultimo encargado de actualizarla con datos de IPFS (update-cache-twitter). La BBDD decidimos tenerla en MongoDB Atlas. Implementamos el proyecto (cachetwitter) para que, haciendo uso de express.js, pudiese conectarse con ella y realizar consultas. Dediqu´e un periodo de tiempo a aprender y familiarizarme con dichas tecnolog´ıas, para lo cu´al fueron de especial utilidad los manuales de MongoDB. En este momento, dimos funcionalidad a un nuevo componente en el dashboard; los filtros por fecha. Aprend´ı c´omo realizar e implement´e consultas filtradas a la BBDD, as´ı como peticiones HTTP que permitiesen conectar los proyectos. Adem´as, profundic´e mi conocimiento en el Hook UseContext, lo cu´al me permiti´o utilizarlo para dar funcionalidad a los filtros que afectaban a todos los componentes de la p´agina web. Por otro lado, implementamos el script (update-cache-twitter) para que llamase a la funci´on get de la API creada por el otro grupo, y obtener as´ı los datos de IPFS. Este script se encarga de vaciar la ”memoria cach´e” y meter los datos actualizados. Por lo tanto, en ese momento, implement´e las llamadas HTTP al proyecto cache-twitter y a˜nad´ı las consultas necesarias en ´el para modificar la BBDD. Desplegamos los tres proyectos en Heroku, de forma que estuviesen en servidores y no en local. En este momento, todos funcionaban perfectamente y ya est´abamos mostrando datos de IPFS. A partir de este momento, decidimos aumentar funcionalidades en el dashboard y realizar cambios de estilo. Me encargu´e de incluir un componente que permitiese visualizar correlaciones a lo largo del tiempo de las palabras m´as utilizadas en denuncias. Adem´as, a˜nadimos un buscador al componente encargado de visualizar los tweets. ´ Este ´ultimo permit´ıa b´usquedas por usuario y por palabras dentro de los tweets, y requer´ıa que los datos le llegasen ordenados. Por lo tanto, implement´e las consultas necesarias sobre la BBDD, haciendo uso de expresiones regulares para el tratamiento del texto. Otras tareas que se llevaron a cabo fueron; realizar la p´agina de informaci´on de la iniciativa, arreglar implementaciones realizadas que pod´ıan mejorarse con los nuevos conocimientos adquiridos, incorporar funcionalidades en las gr´aficas (zoom, enlaces a Twitter, personalizaci´on del contenido...), realizar un estilo amigable de la p´agina web etc. Una vez obtuvimos el producto final, llevamos a cabo un periodo de evaluaci´on con usuarios objetivo. Creamos un plan de evaluaci´on y realizamos entrevistas. Los resultados obtenidos, sirvieron para plantear posibles trabajos futuros. Adem´as, durante esta ´ultima parte del proyecto, se llev´o a cabo la redacci´on de la memoria. Form´e parte, no s´olo de su redacci´on, sino tambi´en de su organizaci´on y revisi´on. 41 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS 4.2. Tecnolog´ıas Dedicamos esta secci´on a exponer en detalle los recursos utilizados durante el desarrollo del proyecto, y cu´al ha sido su finalidad. En la tabla 4.1 encontramos un resumen de las mismas, organizadas por la funcionalidad que les dimos, junto con su bibliograf´ıa. Objetivo Tecnolog´ıa Acceso documento Averigua m´as Diagramas de Gantt 4.2.1.1 [98] Edici´on Overleaf 4.2.1.2 [70] y control GitHub 4.2.1.3 [30] de versiones PyCharm 4.2.1.4 [73] Visual Studio Code 4.2.1.5 [14] Balsamiq Wireframes 4.2.2.1 [120] Dise˜no GIMP 4.2.2.2 [29] diagrams.net 4.2.2.3 [20] API de Twitter 4.2.3.1 [106] Twitter for Websites 4.2.3.2 [107] API de Instagram 4.2.3.3 [41] Python y paquetes 4.2.3.4 [76] Desarrollo Metamask 4.2.3.6 [55] Infura y Etherscan 4.2.3.7 [39] Remix (Solidity) 4.2.3.5 [83, 92] Javascript y paquetes 4.2.3.8 [19] React 4.2.3.9 [79] Node.js y npm 4.2.3.10 [66, 68] Almacenaje IPFS 4.2.4.1 [42] de datos MongoDB Atlas 4.2.4.2 [57] Heroku 4.2.5.1 [36] Despliegue AWS 4.2.5.2 [3] Ropsten y Rinkeby 4.2.5.3 [86, 84] Comunicaci´on HTTP 4.2.6.1 [37] Cuadro 4.1: Tecnolog´ıas 4.2.1. Edici´on y control de versiones 4.2.1.1. Diagramas de Gantt Es una herramienta gr´afica que nos ha permitido organizar el tiempo de dedicaci´on previsto para cada una de las tareas que ten´ıamos que realizar. Adem´as, tambi´en nos ha servido para visualizar la relaci´on existente entre ellas y poder mejorar la planificaci´on. 42 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS 4.2.1.2. Overleaf El desarrollo de la memoria se ha realizado utilizando el lenguaje L A T EX[48]. La edici´on y control de versiones se ha gestionado, colaborativamente, usando Overleaf. 4.2.1.3. GitHub GitHub es un servicio basado en la nube que hemos utilizado para trabajar de forma conjunta en el proyecto. Nos ha permitido, no solo guardar el c´odigo y los cambios que se produc´ıan en ´el, sino tambi´en poder realizar un seguimiento y control de versiones. 4.2.1.4. PyCharm PyCharm es un IDE de Python que nos ha permitido integrar el servicio de GitHub para subir y actualizar de forma eficiente los cambios. Cabe destacar la facilidad con la que se pueden descargar los paquetes de Python sin necesidad de comandos. 4.2.1.5. Visual Studio Code Como editor de c´odigo, hemos utilizado tambi´en Visual Studio Code. En particular, ha resultado ser muy c´omoda la funcionalidad Live Share, que nos ha permitido editar c´odigo colaborativamente, y en tiempo real, desde varios dispositivos. 4.2.2. Dise˜no de la aplicaci´on 4.2.2.1. Balsamiq Wireframes Balsamiq Wireframes es una herramienta desplegada en la web que hemos utilizado para dise˜nar los wireframes que componen la interfaz de nuestra p´agina web. Nos ha permitido crear prototipos de baja fidelidad. 4.2.2.2. GIMP GIMP es un editor de im´agenes que nos ha permitido aumentar la fidelidad de los bocetos de nuestra aplicaci´on. 4.2.2.3. diagrams.net Para el dise˜no de la arquitectura, su estructura y funcionamiento hemos hecho uso de diagramas.net, una aplicaci´on web. 4.2.3. Desarrollo de la aplicaci´on 4.2.3.1. Twitter API La API de Twitter consiste en una serie endpoints de programaci´on que pueden ser usados para entender o crear conversaciones en Twitter. Esta se utiliza para recoger, interactuar y 43 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS analizar datos de Twitter. Algunos de estos son los tweets, usuarios, mensajes directos, listas ytrends. Para poder acceder a ella, es necesario tener una cuenta de Twitter developer, posteriormente hay que registrar una aplicaci´on y solicitar los tokens ykeys correspondientes. Para hacer uso de la API en Python hemos usado Tweepy, una librer´ıa que cuenta con numerosas formas de interactuar con la API (stream,API,Client...). Nosotros hemos utilizado la primera, para poder obtener tweets en tiempo real filtrados por nuestras necesidades. Observamos que, al no poseer una cuenta Research, no se ha podido utilizar esta librer´ıa para acceder al hist´orico de tweets. Otra forma que hemos utilizado para acceder a esta API, ha sido haciendo uso del m´odulo twitter-api-v2 [108] de JavaScript, para poder actualizar los metadatos de los tweets (retweets, likes y respuestas). 4.2.3.2. Twitter for Websites Twitter for Websites proporciona una serie de herramientas para incluir contenido de Twitter en p´aginas web. Por ejemplo, Web Intents proporciona un direccionamiento para interactuar con tweets y usuarios concretos desde nuestra p´agina web. 4.2.3.3. Instagram API Al igual que la API de Twitter, nos permite recoger y analizar datos, aunque esta vez de Instagram. Para acceder a ella, hemos hecho uso de Instagrapi [41], una librer´ıa de Python que, adem´as de facilitarnos el acceso, nos permite navegar tanto con API web p´ublica, an´onimamente, como m´ovil privada. Gracias a ella, hemos podido obtener la secci´on “descripci´on” de las publicaciones. 4.2.3.4. Python Python es un lenguaje de alto nivel de programaci´on interpretado. Debido a su popularidad, cuenta con gran cantidad de librer´ıas. En este proyecto, hemos hecho uso de las siguientes: Snscrape [91] Permite scrapear de redes sociales distintos datos. En el caso de Twitter, es posible obtener usuarios, perfiles, hashtags, b´usquedas, tweets o tendencias. Esta es la alternativa para acceder al hist´orico de tweets, al no tener acceso a la cuenta de Research de Twitter, y es usada en el programa scrape.py junto con una query formada por algunas palabras del diccionario que permite buscar palabras clave. Pymongo [74] Gracias a ella podemos trabajar con la base de datos MongoDB desde Python. Nos ha permitido, por ejemplo, solucionar problemas de concurrencia sobre archivos. 44 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS Stanza [94] Es un paquete de Python de procesamiento del lenguaje natural (NLP) en numerosos idiomas. En este trabajo se utiliza para tokenizar y lemmatizar el texto. Pandas [71] Es una famosa librer´ıa de Python, muy utilizada en el campo de an´alisis de datos, que permite el f´acil manejo de datos a trav´es de estructuras de datos, como pueden ser los dataframes o las series. Nos permite cargar datos de distintos formatos y poder manipularlos. En nuestro caso ha sido empleado tanto para crear el diccionario a partir de un dataframe de 2 columnas sobre cada palabra extra´ıda del diccionario mediante la funci´on to csv, como para poder cargar los datos del diccionario, con la funci´on read csv, cada vez que son requeridos por los programas. Dotenv [77] Facilita el manejo de variables de entorno, usadas para tratar con tokens de acceso de manera segura. Carga las variables de entorno de archivos .env al propio proceso, separando dichas variables del c´odigo. Esto lo consigue haciendo uso de las funciones find dotenv yload dotenv. En este proyecto es usado combinado con un .gitignore para no revelar los Tokens de acceso de la cuenta de Twitter Developer, que nos permite utilizar la API de Twitter. Keyring [46] Permite acceder al anillo de claves del sistema desde aquellas aplicaciones que requieren un almacenamiento seguro de contrase˜nas. Es necesario crear un usuario y una contrase˜na a trav´es de la funci´on set password para, posteriormente, usarlos con la funci´on get password. Fue usado para el manejo seguro de la contrase˜na de la cuenta de Instagram utilizada para la API de Instagram. Emoji [23] Permite utilizar emoticonos en textos a partir de los c´odigos CLDR que los representan. Nosotros lo hemos utilizado, por ejemplo, para limpiar el texto de los tweets para su clasificaci´on. Statistics [95] Permite hallar estad´ısticas matem´aticas de datos numerables. Fue empleado cuando busc´abamos un corpus para poder hallar las m´etricas del diccionario, ya que necesit´abamos calcular el tama˜no medio de los textos dado un corpus, pues era esencial que tuviera el tama˜no y longitud m´as parecido al que ´ıbamos a usar de denuncias. Certifi [12] Proporciona la colecci´on de certificados ra´ız de Mozilla para poder validar la confianza en el certificado SSL mientras se verifica la identidad de los hosts TLS. 45 CAP´ ITULO 4. METODOLOG´ IA Y TECNOLOG´ IAS Spacy [93] Permite el procesamiento de lenguaje natural. Lo hemos utilizado para tokenizar. Codecs [15] Define las clases base de codificaci´on en Python y da acceso a su registro interno de codificaciones, lo que facilita el manejo de errores. Para este trabajo se usa para manejar el fichero donde se escriben las denuncias. Subprocess [97] Permite crear nuevos procesos, conectar a sus correspondientes tuber´ıas de entrada/- salida/error y obtener sus valores de retorno. Este m´odulo se usa normalmente para reemplazar m´ultiples m´odulos y funciones antiguas. Threading [100] M´odulo que permite el manejo de distintos hilos de ejecuci´on. Es utilizado en el c´odigo scrape para obtener los tweets en un hilo distinto al que los clasifica, con el objetivo de incrementar la velocidad del programa. Time [102] M´odulo con funciones de manejo de tiempos. Es utilizado para poder crear un retardo en la velocidad de recolecci´on de tweets del c´odigo scrape, debido a la acumulaci´on de tweets en la base de datos al ser insertados a mayor velocidad de lo que son borrados. 4.2.3.5. Remix y Solidity Remix es un entorno de desarrollo de Ethereum que nos ofrece la posibilidad de compilar y desplegar contratos inteligentes, conocidos en ingl´es como smart contracts. Adem´as tambi´en se puede usar para probar las funciones de los contratos, gracias a su maquina virtual de prueba. La programaci´on de los contratos inteligentes se ha llevado a cabo usando un lenguaje orientado a objetos conocido como Solidity. 4.2.3.6. Metamask Metamask es una extensi´on para navegadores, o m´ovil, que act´ua como una billetera (wallet) de criptomonedas. Utilizamos esta extensi´on para tener un medio de pago con el que efectuar las transacciones. 4.2.3.7. Infura y Etherscan Infura es una plataforma que proporciona un conjunto de herramientas e infraestructuras que permiten a los desarrolladores llevar, f´acilmente, su aplicaci´on blockchain de la prueba, a la implementaci´on a escala, con un acceso simple y confiable a Ethereum. La utilizamos como 46 CAP´ ITULO 5. TRABAJO PREVIO 5.2. Loter´ıa - Blockchain y Solidity El objetivo de este proyecto era aprender a usar el lenguaje de programaci´on Solidity, gestionar el env´ıo y la recepci´on de criptomonedas (ether) y entender el funcionamiento de la blockchain. Para desplegarlo, utilizamos Remix. Este proyecto consisti´o en construir un contrato inteligente (smart contract) que permitiese realizar un sorteo de loter´ıa. El contrato funciona de forma que, qui´en quiera participar, paga una cantidad de dinero al contrato. Una vez elegido un ganador al azar, el contrato le enviar´a a ´el todo el dinero acumulado. Ejemplo de un proyecto: https://github.com/angrui02/lotery.git. 5.3. API de Twitter y an´alisis de lenguaje natural Este ejercicio ten´ıa como objetivo recolectar publicaciones de Twitter relacionadas con el tema de la precariedad laboral en Espa˜na, y haciendo uso de la API de Twitter. Adem´as de recordar algunos conceptos relacionados con el procesamiento y an´alisis del lenguaje natural. Comenzamos d´andonos de alta en su plataforma de desarrolladores. Intentamos conseguir una cuenta nivel Academic Research, que nos proporcionaba el acceso al archivo completo de Twitter. Sin embargo, s´olo conseguimos Elevated, que permite obtener menos tweets al mes y no permite el acceso al archivo completo. A continuaci´on, elaboramos un vocabulario con algunas palabras claves relacionadas con el tema de la precariedad laboral. Esto nos permiti´o extraer un conjunto de tweets en espa˜nol, sobre los cu´ales obtuvimos su polaridad (la mayor´ıa ten´ıan negativa o neutra). Visualizamos las palabras que m´as se repet´ıan, tras una limpieza del texto en la que se eliminaron s´ımbolos, enlaces, palabras vac´ıas etc. Figura 5.2: Wordcloud con las palabras m´as frecuentes de los tweets obtenidos 53 CAP´ ITULO 6. INVESTIGACI´ ON Y RECOGIDA DE REQUISITOS Cap´ıtulo 6 Investigaci´on y recogida de requisitos En este momento, comienza el desarrollo de nuestro proyecto propiamente dicho. Comenz´o con una fase de investigaci´on, seguida del establecimiento de los requisitos que deb´ıa cumplir la p´agina web. Mostramos ambos en esta secci´on. 6.1. Investigaci´on Estuvo orientada al objetivo que pretend´ıamos alcanzar con nuestra aplicaci´on; construir una p´agina web que muestre datos sobre situaciones de precariedad laboral, sin censura y en forma de dashboard. La investigaci´on consisti´o en determinar las caracter´ısticas y objetivos del usuario, as´ı como la situaci´on del mercado al que pretend´ıamos entrar. Es por ello que realizamos un an´alisis de la competencia, tanto total como parcial, que nos permiti´o entender mejor c´omo dise˜nar nuestro producto. Caracter´ısticas del usuario En primer lugar, determinamos que el usuario que va a hacer uso de nuestra aplicaci´on puede presentar caracter´ısticas muy diversas. Las m´as relevantes: Persona que trabaja en un sector/empresa, o va a empezar a trabajar en ´el, y quiere conocer qu´e situaciones de injusticia se dan, le est´en pasando o no a ella. Persona que presenta una predisposici´on a situaciones de injusticia, sea por su campo profesional, o por sus caracter´ısticas f´ısicas/psicol´ogicas. Persona de autoridad que quiere conocer las situaciones que se dan en un sector/empresa. Puede ser con el objetivo de solucionar la injusticia o intentar silenciarla. An´alisis de la competencia Por otro lado, el an´alisis de la competencia se centr´o en estudiar qu´e productos exist´ıan en el mercado. Estudiamos dashboards existentes, estuviesen o no relacionados con Twitter, 54 CAP´ ITULO 6. INVESTIGACI´ ON Y RECOGIDA DE REQUISITOS y buscamos organizaciones que llevasen a cabo proyectos con un objetivo similar al nuestro. A continuaci´on, indicamos las principales herramientas que encontramos y que consideramos m´as resaltables para nuestro desarrollo. TweetViz [96] Herramienta web donde se muestran datos de tweets relacionados con una palabra (o palabras). Busca tweets que contengan dichas palabras y realiza un an´alisis del sentimiento de los tweets. Adem´as, muestra distintas gr´aficas, temas relacionados, wordclouds... Los diferentes datos aparecen en diferentes pesta˜nas, y todas ellas se ven afectadas por ese an´alisis del sentimiento. En la zona inferior de los gr´aficos, muestra informaci´on general acerca del uso de la web. Twitter Analytics Dashboard [4] Es una funcionalidad proporcionada por Twitter para ver la informaci´on acerca de la cuenta personal de cada usuario. El objetivo es hacer un seguimiento de los tweets y la interacci´on del usuario, con el fin de ver c´omo repercute en la audiencia. Muestra informaci´on como las impresiones de los tweets, visitas al perfil y res´umenes mensuales del uso de la cuenta, entre otros. Portwiture [72] Proporciona una rejilla con im´agenes obtenidas de Flickr que coinciden con palabras m´as usadas del contenido m´as reciente de un usuario dado. TrackMyHashtag [103] El uso de hashtags en Twitter ayuda a encontrar tweets relacionados con una tem´atica. La herramienta TrackMyHashtag hace un seguimiento de un hashtag proporcionado y muestra estad´ısticas acerca de ´el, como las contribuciones al hashtag, impresiones o informaci´on acerca del lenguaje de los tweets. Cuentas en redes sociales En las propias redes sociales existen cuentas dedicadas a visibilizar denuncias. Por ejemplo, en Twitter est´a la cuenta @Jobsmierda [111], que se dedicaba a dar visibilidad a situaciones laborales precarias con un tono de humor. En Instagram encontramos @Trabajosruineros [40], que publica las denuncias que le env´ıan sus seguidores junto con el nombre de la empresa d´onde ha tenido lugar el incidente. Aplicaci´on jobstice [43] Es una aplicaci´on, desarrollada para tel´efonos m´oviles, que permite denunciar de forma an´onima abusos laborales. 6.2. Requisitos En esta fase, haciendo uso de la informaci´on recogida durante la investigaci´on, determinamos los requisitos que deb´ıamos cumplir con nuestro dashboard. Fue un paso esencial para 55 CAP´ ITULO 6. INVESTIGACI´ ON Y RECOGIDA DE REQUISITOS poder establecer las funcionalidades que deb´ıa proporcionar la aplicaci´on y realizar un dise˜no que se ajustase a ellas. Comenzamos llevando a cabo un brainstorming, o lluvia de ideas, entre todos los integrantes del grupo. El objetivo era compartir las ideas preconcebidas que ten´ıamos y, utilizando los resultados obtenidos en la fase de investigaci´on, establecer unos requisitos comunes en los que pudi´esemos basarnos. Requisitos funcionales En primer lugar, se establecieron los siguientes requisitos funcionales que determinan las interacciones que el usuario podr´a realizar con nuestra aplicaci´on: 1. Visualizar informaci´on sobre situaciones de precariedad laboral. a) Contenido de las denuncias. b) Cantidad de denuncias. c) Caracter´ısticas de las denuncias; tipo (horas trabajadas, impago...), localizaci´on... d) Personas que realizan las denuncias. e) Cantidad de personas que realizan denuncias. f) Caracter´ısticas de las personas que realizan denuncias (edad, g´enero, profesi´on...) g) Reacci´on que reciben las denuncias por parte de la gente. h) Tendencias en las denuncias; a lo largo de los a˜nos, en funci´on de la ´epoca del a˜no, del tema... 2. Acceder a la fuente original de la informaci´on para poder interaccionar con ella. 3. Ordenar la informaci´on en funci´on de varias m´etricas (tiempo, cantidad de denuncias, denuncias que mayor reacci´on generan...). 4. Filtrar la informaci´on que se muestra (tipo de informaci´on, tiempo, edad, g´enero, localizaci´on...). 5. Descargar la informaci´on que se muestra. 6. Realizar b´usquedas sobre la informaci´on (usuarios, temas...). 7. Poder poner denuncias. Requisitos no funcionales Por otro lado, se establecieron los siguientes requisitos no funcionales: 1. Garantizar que no haya censura. Es decir, aunque el contenido original sea eliminado, la p´agina web debe seguir mostr´andolo. 56 CAP´ ITULO 6. INVESTIGACI´ ON Y RECOGIDA DE REQUISITOS 2. Mostrar contenido significativo. 3. Realizar un dise˜no visual, simple y f´acil de usar por un usuario general. 4. Crear un sentimiento de comunidad y apoyo. Para referirnos a estos requisitos, de aqu´ı en adelante, utilizamos las abreviaciones RF (requisito funcional) y RNF (requisito no funcional). Los c´odigos que acompa˜nan a dichas nomenclaturas se corresponden con la enumeraci´on presentada. Por ejemplo, RF7 indica “Poder poner denuncias”. 57 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON Cap´ıtulo 7 Dise˜no e implementaci´on El siguiente paso, consisti´o en utilizar los requisitos de la fase anterior para realizar el dise˜no y la implementaci´on de la aplicaci´on. En esta secci´on, recogemos los resultados obtenidos tras las sucesivas iteraciones que realizamos en esta fase de trabajo. Adem´as, explicamos el desarrollo que nos condujo a la arquitectura y resultados finales de la aplicaci´on. Comenzamos viendo qu´e requisitos conseguimos cumplir y cu´ales no en el siguiente cuadro 7.1. En el primer caso, mostramos c´omo se implementaron y una breve explicaci´on del mismo. En el cuadro 7.2, profundizamos en los requisitos que no pudieron ser cumplidos y el motivo de que esto ocurriese. Adem´as, comentamos aquellos cumplidos pero que podr´ıan ser ampliados. A continuaci´on, exponemos c´omo se llev´o a cabo el desarrollo de esta fase y qu´e proceso se sigui´o. Debido a la magnitud del proyecto, y la complejidad de cada una de sus partes, lo explicamos siguiendo la divisi´on en tres bloques mencionada en el cap´ıtulo 4. Cada uno de ellos, expone el proceso en orden cronol´ogico. La arquitectura final obtenida tras este proceso, se puede encontrar en el cap´ıtulo 8. 7.1. Bloque 1: Recoger datos 7.1.1. Fase inicial La idea part´ıa de utilizar la API de Twitter para la obtenci´on de tweets y llevar a cabo un proceso de an´alisis del sentimiento (sentiment analysis) para determinar si eran denuncias laborales. Comenzamos utilizando textblob [99] y googletrans [32] para traducir las publicaciones y calcular el sentimiento del texto traducido. Sin embargo, realizar tantas consultas a la API de Google Traductor resultaba ineficiente, adem´as de que al no traducir el texto de forma literal, se perd´ıan matices que afectaban al tono del tweet. Por ello, optamos por usar afinn [1], una librer´ıa de Python que nos permit´ıa calcular el sentimiento en espa˜nol. El primer proyecto obten´ıa denuncias de cuentas y miraba si su sentimiento era negativo. Desarrollamos un prototipo inicial que recog´ıa tweets de la cuenta @JobsMierda [111], que denunciaba en base a capturas de pantalla de conversaciones de Whatsapp,e-mails u ofertas 58 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON Requisitos funcionales Implementaci´on Explicaci´on RF1a AppTweets Tweets que muestran el contenido de las denuncias RF1b AppTotalTweets Total de denuncias realizas RF1c No cumplido - RF1d AppTweets Tweets que muestran qui´en los redact´o RF1e AppTotalUsers Total de usuarios que realizaron denuncias RF1f No cumplido - RF1g AppTweets Tweets que muestran la reacci´on (comentarios, likes y retweets) que recibieron AppTotalFAV Total de likes que recibieron las denuncias AppTotalRT Total de retweets que recibieron las denuncias RF1h AppWordsTime Progresi´on y correlaci´on de temas denunciados en el tiempo AppWordcloud Temas m´as denunciados AppHeatmap Cantidad de denuncias en funci´on de la ´epoca del a˜no AppTimeline Cantidad de denuncias y reacci´on en el tiempo AppTopHashtags Temas m´as utilizados AppTopUsers Usuarios m´as activos RF2 AppTweets Enlace para escribir un tweet usando el hashtag #Injustweet AppTopHashtags Enlace para escribir un tweet usando el hashtag AppTopUsers Enlace al usuario RF3 AppTweets Ordena denuncias (fecha ascendente/descendente o en funci´on de la cantidad de likes/retweets) RF4 FilterSidebar Filtro temporal RF5 AppWordcloud Permite descargar informaci´on RF6 AppTweets B´usqueda de temas denunciados o usuarios RF7 AppTweets Acceso directo a Twitter para denunciar AppTopHashtags Acceso directo a Twitter para denunciar AppTopUsers Contacto directo al Twitter del usuario Requisitos no funcionales RNF1 Uso de la blockchain Guarda datos descentralizados RNF2 Uso de Twitter Plataforma con mucha actividad y datos RNF3 Estilos y dise˜no Usando la plantilla y Material UI, basado en Material Design AppInfo Informaci´on sobre el proyecto Texto explicativo Descripci´on del principal uso del dashboard RNF4 Iniciativa y uso de un hashtag com´un: #Injustweet Incentivar la denuncia de situaciones precarias motivadas por el dashboard Cuadro 7.1: Requisitos cumplidos y c´omo se han implementado de trabajo con condiciones extremadamente precarias. De esos tweets, mucha de la informaci´on relevante de la denuncia estaba en la imagen. Utilizamos los paquetes pytesseract [75] y easyocr [22] para capturar el texto de conten´ıan las 59 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON Requisitos Motivo RF1c Al no disponer de un corpus de documentos clasificados, no pudimos crear un modelo para entrenarlo, por lo que el tipo de las denuncias no aparece recogido. La localizaci´on no est´a disponible en todos los tweets. Adem´as, los tweets se pueden publicar desde cualquier lugar, sin tener garant´ıas de que ese sea el lugar origen de la denuncia. RF1f Se defini´o como requisito no prioritario para futuras implementaciones. RF1h Se podr´ıa ampliar la informaci´on sobre tendencias usando t´ecnicas de machine learning RF3 Se podr´ıa ampliar usando m´etricas como las caracter´ısticas de la denuncia o del usuario RF4 Se podr´ıa ampliar usando m´etricas como las caracter´ısticas de la denuncia o del usuario RF5 Se podr´ıa ampliar con una opci´on de descarga para cada gr´afica Cuadro 7.2: Requisitos no cumplidos o que se pueden ampliar y motivo del por qu´e im´agenes. Ambos nos plantearon los mismos problemas; iconos como el doble tick o la hora del mensaje formaban parte del texto. Esto no s´olo hac´ıa ilegible el mensaje, sino que adem´as hac´ıa que el texto no fuera v´alido para hallar su sentimiento. Adem´as, las conversaciones les daba estructuradas como si se tratase de una sola l´ınea. Esto romp´ıa el sentido de la misma al no saber cu´al de las dos partes dijo qu´e. Encontramos tambi´en otros problemas. Numerosas publicaciones de esta cuenta no eran ni siquiera denuncias laborales y buscar en hilos tampoco augurar´ıa un mejor resultado. Adem´as, aunque el texto de la imagen fuera una denuncia, muchas veces el comentario que la acompa˜naba ten´ıa un tono ir´onico o sarc´astico, lo que resultaba en un sentiment positivo. Esto tambi´en ocurr´ıa al analizar conversaciones, puesto que muchos mensajes no ten´ıan connotaciones negativas, como los saludos porque las condiciones laborales precarias redactadas como una oferta de empleo tend´ıan a tener un sentimiento neutro. Decidimos, por lo tanto, que un proceso de an´alisis del sentimiento no era lo adecuado para encontrar denuncias. Fue entonces cuando surgi´o la idea de crear un diccionario de palabras recogidas de denuncias preseleccionadas. De forma que pudi´esemos usarlas para ponderar y determinar si un texto es una denuncia laboral. 7.1.2. Diccionario Instagram La cuenta de Instagram @trabajosruineros [40] contiene contenido que es, casi exclusivamente, denuncias laborales. ´ Este es redactado por usuarios y va acompa˜nado de una imagen con el nombre de la empresa denunciada. Decidimos utilizarlo para crear el corpus y formar el diccionario ya que, al estar escritas por distintas personas, proporcionaban diversidad tanto en la redacci´on como en el contenido. 60 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON Utilizamos la librer´ıa Instagrapi de Python para poder interactuar con el API de Instagram, con el fin de extraer todas las palabras de las publicaciones que s´ı fueran denuncias laborales, siendo casi 800. De ´estas, utilizamos cerca de 650 publicaciones, reserv´andonos 150 para poder formar un corpus con el que, m´as adelante, probar´ıamos el rendimiento de nuestro algoritmo. Creaci´on del diccionario Una vez recogidas publicaciones de la cuenta, utilizamos t´ecnicas de NLP para quedarnos con la informaci´on de la palabra que nos interesaba. Inicialmente, aplicamos procesos de lemmatization, stemming y tokenization a las publicaciones. Sin embargo, decidimos prescindir de la t´ecnica stemming por la poca explicabilidad del diccionario. Esto se deb´ıa a que en ciertas ocasiones las ra´ıces de las palabras no permit´ıan deducir de qu´e palabra derivada hab´ıa surgido. Una vez recogidas todas las palabras, llevamos a cabo un proceso de limpieza. Inicialmente tomamos las palabras con mayor frecuencia, ya que deb´ıan ser las m´as usadas para realizar denuncias. Sin embargo, esto llev´o a un diccionario de cerca de 8000 palabras, en d´onde las que m´as se repet´ıan eran verbos y palabras de uso com´un, que pod´ıan usarse en cualquier contexto. Es por esto que, la primera iteraci´on, consisti´o en deshacernos de ellas, quedando un diccionario de 200 palabras. En la siguiente iteraci´on vimos que hab´ıa palabras que estaban directamente relacionadas con temas laborales, pero que pod´ıan usarse en muchos m´as contextos. Decidimos quedarnos con las palabras m´as espec´ıficas, por lo que el diccionario se redujo a 75 palabras. Observamos el mismo en las figuras 7.1a y7.1b. Finalmente, realizamos una ´ultima iteraci´on, d´onde nos quedamos con las palabras que consider´abamos necesarias en una denuncia laboral. El diccionario obtenido de 25 palabras se observa en la figura 7.1c.´ Este tan s´olo lo usamos para realizar consultas a la API de Twitter y al Scraper Web, con los tweets que nos devuelve, evaluamos con el diccionario de la segunda iteraci´on si son denuncias o no. Estas consultas son necesarias para disminuir los tiempos de obtenci´on de posibles denuncias laborales, puesto que estrechan el abanico de resultados. M´etodo de evaluaci´on del diccionario Tras terminar el diccionario buscamos un m´etodo de evaluaci´on para el algoritmo. Partimos con la idea de ponderar las palabras usando un ranking inverso; las palabras en una posici´on mayor ser´ıan las que m´as ponderaran. Decidimos operar sobre el porcentaje de texto que estaba recogido en el diccionario para que no penalizar a los textos m´as cortos. Sin embargo, el m´etodo planteaba un problema. Si el texto era lo suficientemente corto se podr´ıan dar muchos falsos positivos. 61 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON (a) 2ªiteraci´on, parte 1 (b) 2ªiteraci´on, parte 2) (c) 3ªIteraci´on Figura 7.1: Algunos de los diccionarios obtenidos Decidimos, por lo tanto, no tener en cuenta el porcentaje del texto que est´a en el diccionario, sino el porcentaje del diccionario que estaba contenido en el texto, lo que nos llev´o a trabajar con un n´umero de palabras absoluto. Ciertamente esta soluci´on s´ı que penalizar´ıa el tama˜no de los textos, pero s´olo hasta un punto l´ogico siempre que el n´umero de palabras fuera alcanzable (los textos muy cortos se ver´ıan m´as penalizados, pero en parte ser´ıa de manera 62 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON de llamadas que se hacen junto con el n´umero de tweets que hay almacenados y sabiendo el n´umero de tweets que se actualizan por llamada. Una vez todos los tweets est´an actualizados se para, y deja pasar un tiempo establecido antes de volver a funcionar. Observamos que un inconveniente que plantea esta decisi´on; la informaci´on se va a subir a IPFS varias veces para tenerlo todo bien actualizado, porque dicho contenido no puede ser eliminado y reemplazado. ´ Ultimos contratiempos El proyecto ya estaba funcionando, pero surgieron algunos contratiempos a los que tuvimos que hacer frente: Tuvimos que corregir el formato y tipo de los datos que se enviaban a la API. Hubo un agotamiento en la cantidad de ethers de prueba que ten´ıamos para desplegar contratos o ejecutar sus funciones. Tuvimos que buscar nuevas p´aginas web que nos enviasen tokens. Las cuentas que conseguimos para utilizar la API de Twitter est´an muy limitadas,lo que dificult´o la actualizaci´on de los datos 7.3. Bloque 3: Mostrar datos 7.3.1. Dise˜no Las distintas iteraciones de la fase de dise˜no, produjeron una serie de bocetos que fueron aumentando en su grado de fidelidad progresivamente. Comenzamos elaborando una gran cantidad de bocetos de baja fidelidad a papel, teniendo en cuenta los requisitos que hab´ıamos obtenido en la fase anterior. A continuaci´on, realizamos una fusi´on de las caracter´ısticas que m´as nos gustaban de cada uno, obteniendo as´ı el boceto inicial. En la Figura 7.4a podemos verlo. Posteriormente, gracias a los avances realizados en la fase de implementaci´on, y a una reuni´on de evaluaci´on que tuvimos con el resto del equipo, decidimos realizar cambios y mejoras. Para ello, dise˜namos un boceto de mayor fidelidad con Balsamiq. Esta herramienta, a trav´es de la creaci´on de wireframes, nos permiti´o entender mejor c´omo trasladar nuestra idea a la aplicaci´on. Se puede ver en las Figuras 7.4b y7.4c. A partir de este punto, el resto de fases de dise˜no consistieron en ir realizando cambios progresivos sobre la aplicaci´on. En las iteraciones que involucraron mayor nivel de cambios, como introducci´on de nuevos componentes, utilizamos GIMP para probar distintas reorganizaciones y caracter´ısticas. En la Figura 7.5 podemos ver algunos de los cambios que fue sufriendo la aplicaci´on. 69 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON (a) Boceto inicial en papel (b) Boceto del dashboard en Balsamiq (c) Boceto de la p´agina de informaci´on en Balsamiq Figura 7.4: Evoluci´on de los bocetos (a) Prototipo sobre la aplicaci´on (b) Redistribuci´on de elementos en GIMP Figura 7.5: Evoluci´on del dashboard El dise˜no final obtenido para nuestra p´agina web se encuentra en las figuras 7.6 y7.7. Observamos que durante todas las iteraciones, que finalmente nos han conducido a ´el, se han tenido en cuenta los 10 principios de dise˜no de Jakob Nielsen [62]. Comentamos algunos de ellos a continuaci´on: Visibilidad del estado del sistema: La aplicaci´on intenta mostrar al usuario en todo momento qu´e est´a pasando y en qu´e punto de la navegaci´on se encuentra. Por ejemplo, se ha incluido un esqueleto de p´agina web para que el usuario sepa que est´a cargando. Adecuaci´on entre el sistema y el mundo real: El sistema intenta hablar con el mismo lenguaje que los usuarios. Por ejemplo, se utiliza el s´ımbolo de calendario para indicar el 70 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON filtro por fechas. Libertad y control por el usuario: Se permite que los usuarios puedan volver f´acilmente a un estado anterior. Por ejemplo, al realizar una b´usqueda se pueden eliminar f´acilmente los filtros introducidos. Consistencia y est´andares: Repetimos patrones para no confundir a los usuarios. Por ejemplo, al ser datos de Twitter, utilizamos una tem´atica similar, asi como su lenguaje (likes, hashtags...). Est´etica y dise˜no minimalista: Se ha intentado simplificar y eliminar contenido irrelevante para que el usuario s´olo se fije en lo realmente importante. 7.3.2. Implementaci´on Tras el desarrollo de los primeros bocetos iniciales, nos planteamos c´omo implementar dichas ideas. La primera decisi´on que se tom´o fue hacer uso de React. Las principales referencias que hemos utilizado para utilizar React fueron la documentaci´on oficial de su web [79] y el libro Learning React [7]. 7.3.2.1. Fase inicial En primer lugar, dedicamos un periodo de tiempo a familiarizarnos y buscar tecnolog´ıas que nos permitiesen incorporar en nuestra p´agina web las ideas determinadas en la fase de dise˜no. Recordamos que nuestro objetivo era mostrar datos en forma de dashboard. Por un lado, investigamos qu´e librer´ıas exist´ıan compatibles con React que nos permitiesen implementar gr´aficas y diagramas para visualizar datos. Encontramos una gran cantidad de ellas (como recharts [82], charts.js [13], visx [2] o nivo [63]) con las que realizamos un proyecto de prueba. En paralelo, buscamos c´omo realizar un dashboard con dichas gr´aficas en React. Tuvimos un primer acercamiento a React-Bootstrap [11], una biblioteca de c´odigo libre con herramientas HTML,CSS yjavascript para crear p´aginas y aplicaciones web. Esta librer´ıa nos aportaba bastante facilidad a la hora de dise˜nar la web, porque nos permit´ıa no tener que crear los componentes b´asicos desde cero. Creamos otro proyecto bas´andonos en una plantilla [101] para entender su funcionamiento y que nos permiti´o aprender sobre enrutamiento en React, y sobre el lenguaje de estilos sass. Sin embargo, investigando y haciendo pruebas con Bootstrap, nos encontramos con Material UI, un framework para React basado en Material Design. Nos decantamos por este ´ultimo por ser mucho m´as personalizable y poseer una documentaci´on muy extensa. 71 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON Figura 7.6: Dashboard final 72 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON Figura 7.7: P´agina de informaci´on final 73 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON 7.3.2.2. Desarrollo Creaci´on del dashboard El resultado de la fase anterior fue un peque˜no proyecto que recog´ıa algunos de los requisitos expuestos. Sin embargo, con el fin de cumplir todos los objetivos propuestos, decidimos aumentar la velocidad de aprendizaje e implementaci´on. Es por ello que tomamos como referencia una plantilla que limpiamos y modificamos para que se ajustase a nuestros requisitos. Escogimos una basada en Material UI, la plantilla de Minimal Free [56], con licencia de uso MIT. Observamos que, gracias a ella, descubrimos una nueva librer´ıa para visualizar datos en forma de gr´aficas, ApexCharts, que result´o ser la que terminamos utilizando. Creamos un m´ınimo producto viable que consist´ıa en una p´agina web single page con dos ventanas enrutadas din´amicamente. Una encargada de mostrar el dashboard y otra de mostrar informaci´on sobre la aplicaci´on. Se implementaron los siguientes componentes para mostrar datos; −4 tarjetas para mostrar totales (cantidad de usuarios, tweets, likes y retweets). −1 wordcloud con las palabras m´as utilizadas. −2 tarjetas para mostrar rankings (por usuarios y hashtags). −1 visualizador de tweets para mostrar las denuncias. −1 gr´afica temporal para representar las tendencias anuales en la cantidad de tweets. −1 l´ınea de tiempo de doble eje para representar la progresi´on en la cantidad de tweets, likes y retweets a lo largo del tiempo. Base de datos La idea inicial era alimentar a la p´agina web con los datos de IPFS. Sin embargo, los accesos para recoger datos de la blockchain pueden llegar a ser muy costosos. Adem´as, en IPFS no pueden crearse ´ındices para mejorar la eficiencia y tampoco cuenta con gran variedad de consultas. Es por todo ello que se tom´o la decisi´on de crear una “memoria cach´e” que sirviese para alimentar a la p´agina web. La idea es que esta BBDD fuese actualizada cada dos d´ıas con los datos de la blockchain. Decidimos utilizar MongoDB Atlas, para lo cu´al resultaron de especial utilidad sus art´ıculos y manuales [58, 57]. A partir de este punto, comenzamos a desarrollar tres proyectos en paralelo; uno encargado de crear la p´agina web (dashboard-twitter), otro de gestionar las consultas con la BBDD (cache-twitter) y un tercero que se encargase de actualizarla cada dos d´ıas (update-cachetwitter). 74 CAP´ ITULO 7. DISE˜ NO E IMPLEMENTACI´ ON Desarrollo en paralelo Durante las sucesivas iteraciones de la fase de implementaci´on, se fueron a˜nadiendo cambios en los tres proyectos. Los mencionamos de forma superficial, porque se explicar´an en detalle en la soluci´on final (cap´ıtulo 8). dashboard-twitter: Se a˜nadieron funcionalidades y cambios de estilo con el objetivo de cumplir todos los requisitos que se hab´ıan establecido. Los componentes b´asicos que ten´ıa el producto m´ınimo viable se hicieron m´as complejos, aumentando las opciones que ofrec´ıan (permitir descargas, hacer zoom en las gr´aficas, elegir qu´e datos ver...). Adem´as, se a˜nadieron nuevos componentes y funcionalidades (b´usquedas, filtros, gr´afica de correlaci´on entre palabras...). Finalmente, tuvo lugar una fase en la que se hicieron los estilos m´as amigables y se a˜nadieron detalles de dise˜no que mejoraban la experiencia de usuario (esqueleto de p´agina web, pie de p´agina...). cache-twitter yBBDD: Se aument´o la variedad de las consultas que se pueden realizar y se mejor´o la eficiencia de la BBDD a la hora de resolverlas. Inicialmente, las consultas s´olo pod´ıan filtrarse por fecha. A medida que aument´o la complejidad de los componentes, tambi´en lo hicieron las consultas. Permitimos filtrar por usuario, realizar b´usquedas en el texto de las denuncias o devolver las consultas ordenadas. Para poder realizar estas operaciones de manera eficiente, recurrimos al uso de ´ındices en la BBDD. A continuaci´on, mostramos los que se crearon: date,user, retweets ylikes. update-cache-twitter: Se cre´o un script que actualizase la BBDD de la forma m´as eficiente posible y creando un nivel de protecci´on que evitase corromper la BBDD. En un primer lugar, tambi´en iba a encargarse de mantener actualizados los metadatos de los tweets (informaci´on sobre retweets, likes y respuestas) en esta parte de la aplicaci´on. Sin embargo, decidimos en equipo que la actualizaci´on se hiciera desde la parte del backend de la aplicaci´on, actualizando y guardando esta informaci´on tambi´en en IPFS. Despliegue Para que los tres proyectos pudiesen interactuar entre s´ı, y no estuviesen en local, se desplegaron en un servidor cloud. Decidimos utilizar Heroku, lo que facilit´o el intercambio de informaci´on a trav´es de llamadas HTTP. 75 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Cap´ıtulo 8 Arquitectura de la soluci´on Utilizamos esta secci´on para explicar, en detalle, la arquitectura final de Injustweet, la aplicaci´on que hemos creado. Podemos ver en la figura 8.1 el esquema general de la misma, dividido en los tres grandes bloques; recogida de datos, almacenaje de datos y visibilizaci´on de datos. A continuaci´on, explicamos cada uno de ellos en detalle. 8.1. Bloque 1: Recoger datos Comenzamos estudiando la parte de la arquitectura destinada a la recolecci´on de datos (tweets). Es decir, el primer bloque que se observa en la figura 8.1. Lo primero que observamos es que se obtienen de dos fuentes distintas. API Twitter Developer: A trav´es de su servicio streaming, los obtiene en tiempo real. Scraper de redes sociales: Permite acceder al hist´orico de tweets de Twitter. 8.1.1. Stream.py Comenzamos viendo la arquitectura del programa stream.py, en la figura 8.2, que obtiene tweets en tiempo real. Como se puede ver en la figura 8.3, el c´odigo parte de un hilo principal desde el que se crea un hilo demonio (gracias al par´ametro threaded) que ejecuta un listener. Para ello es necesario proporcionar los tokens de la cuenta de Twitter Developer. Este listener emplea el m´etodo stream proporcionado por la librer´ıa tweepy, que a su vez utiliza el protocolo Streaming HTTP para dar datos a trav´es de una conexi´on abierto en streaming con la API de Twitter. Sobre este listener, se usa una funci´on filter, permitiendo filtrar tanto el lenguaje del tweet, como las palabras clave que debe contener el texto (siendo ´estas las que conforman la tercera iteraci´on del diccionario). 76 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.1: Arquitectura de la aplicaci´on 77 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.2: Obtenci´on de tweets en tiempo real 1query =pd.read_csv(" ../../../ dict / query_dic .csv ") 2freq_dict =pd.read_csv(" ../../../ dict / FREQUENCIES_DIC . csv ") 3load_dotenv(find_dotenv(" env/ TwitterTokens .env ")) 5tweepy_stream =SimpleListener( 6os.getenv('API_KEY'), 7os.getenv('API_KEY_SECRET'), 8os.getenv('ACCESS_TOKEN'), 9os.getenv('ACCESS_TOKEN_SECRET'),daemon=True) 11 tweepy_stream .filter(languages =['es '], threaded=True, 12 track =[ 13 query ["WORD"][0], query [" WORD"][1], query [" WORD"][2], 14 query ["WORD"][3], query [" WORD"][4], query [" WORD"][5], 15 query ["WORD"][6], query [" WORD"][7], query [" WORD"][8], 16 query ["WORD"][9], query [" WORD"][10], query [" WORD"][11], 17 query ["WORD"][12], query [" WORD"][13], query [" WORD"][14], 18 query ["WORD"][15], query [" WORD"][16], query [" WORD"][17], 19 query ["WORD"][18], query [" WORD"][19], query [" WORD"][20], 20 query ["WORD"][21], query [" WORD"][22], query [" WORD"][23], 21 query ["WORD"][24]]) Figura 8.3: Creaci´on del listener Cuando el listener reciba un tweet la funci´on on status ser´a invocada. En esta funci´on recogemos los datos previamente mencionados en el formato del JSON para subirlos a la base de datos, tal y como se ve en la figura 8.4. 78 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON el anterior c´odigo, figura 8.2, con la salvedad de utilizar un scraper web en vez de un listener y el API de Twitter. La estructura del programa emplea igualmente 2 hilos, uno con el que obtiene los datos mediante snscrape y pr´acticamente igual al del stream que realiza el an´alisis y los sube a la blockchain. Tal y como se ve en la figura 8.16, se crea desde el hilo principal un nuevo hilo que ejecuta la funci´on que se encargar´a de recoger los tweets con snscrape. El hilo principal es exactamente igual al descrito anteriormente, recoge textos de la base de datos, llama a las funciones para clasificar el texto y, a partir de un cierto n´umero de denuncias, sube el archivo a la blockchain. Tambi´en cuenta con las mismas medidas de seguridad del formato del archivo. 1def main(): 2new_thread 1=Thread(target=thread_function) 3new_thread 1.start () Figura 8.16: Creaci´on del hilo secundario en Scrape Centr´andonos en la funci´on que obtiene los tweets, representada en la figura 8.17, el scraper no necesita utilizar los tokens de la cuenta developer de Twitter, ya que es independiente al API de Twitter. En nuestro caso empleamos la versi´on de librer´ıa de Python, pero podr´ıamos usar la versi´on CLI utilizando el m´odulo os de Python para llamar al comando desde Python como si fuera una terminal. La consulta es muy parecida a la usada en el c´odigo anterior, con la salvedad de poder especificar el rango de fechas de los tweets con los campos since yuntil. M´as all´a de estos sutiles pero importantes cambios, no se diferencia del anterior c´odigo. 1def thread_function(): 2for i,tweet in enumerate (sntwitter .TwitterSearchScraper( 3query ["WORD"][0]+" OR " +query [" WORD "][0]+" OR " +query ["WORD"][0]+" OR " +query ["WORD "][3]+" OR " +query [" WORD"][4]+" OR " +query ["WORD "][5]+" OR " +query [" WORD"][6]+" OR " +query ["WORD "][7]+" OR " +query [" WORD"][8]+" OR " +query ["WORD "][9]+" OR " +query [" WORD"][10]+" OR " +query ["WORD "][11]+" OR " +query [" WORD"][12]+" OR " +query ["WORD "][13]+" OR " +query [" WORD"][14]+" OR " +query ["WORD "][15]+" OR " +query [" WORD"][16]+" OR " +query ["WORD "][17]+" OR " +query [" WORD"][18]+" OR " +query ["WORD "][19]+" OR " +query [" WORD"][20]+" OR " +query ["WORD "][21]+" OR " +query [" WORD"][22]+" OR " +query ["WORD "][23]+" OR " +query [" WORD"][24]+" lang :es -is: retweet since :2022 -05 -01 until :2022 -05 -09 " ). get_items ()): Figura 8.17: Obtenci´on de datos con snscrape 85 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON 8.2. Bloque 2: Guardar datos Nos centramos ahora en la parte de la arquitectura destinada al almacenaje de datos. Es decir, el segundo bloque que se observa en la figura 8.1. El objetivo de este bloque es almacenar los datos obtenidos en un sistema descentralizado, para evitar que sean censurados. En particular, vamos a hacer uso de IPFS, al cu´al accederemos gracias a un contrato en la blockchain. La API, al desplegarse, configura con Web3 la conexi´on con Ethereum y con la cuenta de criptomonedas, utilizando el m´odulo truffle-hdwallet-provider. Para ello se utilizan dos claves; la de la cuenta de la que se sacan los fondos para ejecutar los m´etodos del contrato y la del proveedor de Infura que nos conecta con la red de prueba de Rinkeby, en la que est´a desplegado el contrato. El manejo de estas claves se hace con dotenv.config() y el archivo de configuraci´on .env. Tras configurar estas conexiones con la blockchain, se configura el c´odigo de la API usando express. A continuaci´on, se crea la conexi´on con IPFS usando como puerta de enlace la API de Infura. Finalmente, para terminar la configuraci´on, se le proporciona a Web3 tanto la direcci´on del contrato como el ABI, lo que devuelve una variable que permite interactuar con los m´etodos de ´este. Observamos que para modificar el estado de la blockchain se necesita dinero (ether). Por lo tanto, llamar a los m´etodos de un contrato inteligente puede ser caro. Aunque en nuestro caso trabajamos con la red de prueba de Rinkeby, el contrato est´a desarrollado y pensado de forma que tenga un consumo de gas reducido para que sea eficiente. A continuaci´on, mostramos los m´etodos que proporciona la API, desarrollada en express, y su funcionamiento. Recogida de datos: Recibe los tweets obtenidos mediante los procesos de scrape y stream del Bloque 1. Hace uso del m´etodo POST de la API que se puede observar en la figura 8.18. El m´etodo recibe un archivo JSON con un array que contiene la informaci´on del tweet que se desea almacenar. Tras parsear la petici´on, por cada objeto se obtiene el identificador del tweet, que se almacena en un array. Se guarda el cuerpo del post en IPFS y obtenemos el hash asociado al fichero subido, para poder acceder a ´el m´as adelante. Este hash, junto con el array de identificadores, se manda al contrato usando la funci´on setFile(). Se puede observar en la figura 8.19. La funci´on crea una estructura con estos datos y la amacena en el array principal del contrato. Tambi´en se recorre los tweets guardando los IDs en un mapa como clave y asign´andoles como valor la posici´on en la que se encuentra el hash del fichero que contiene esos tweets del array principal. Por ´ultimo, se cierra la conexi´on con el cliente. En la figura 8.20 podemos comprobar el funcionamiento de esta parte mediante un diagrama de secuencia. Para recibir en la API la informaci´on con los tweets, se hace uso de un c´odigo en Javascript que se encarga de almacenar en la variable postBody un JSONArray con los 86 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON 1app.post('/ set ',async (req,res)=> { 2let idArray =[]; 3req.body.forEach(obj => {// Collects the tweet ID 's 4idArray.push(obj["id"].toString ()); 5}); 6// Store the tweets in IPFS and gets the IPFS hash 7const added =await client.add (JSON.stringify(req.body)); 8// Sends the file IPFS hash with the tweet ID 's it contains to de smart contract 9await contract.methods.setFile(added.path ,idArray).send ({ 10 from:'0 x0fe2273f4754f494d3fe0C6D8cB5aE83f2b64bF9 '}); 11 res.json({});// Close the connection 12 }); Figura 8.18: C´odigo del m´etodo POST de la API 1function setFile(string memory hash,string[] memory tweetsID) external { 2TweetsFile memory tf =TweetsFile (hash,tweetsID); 3tweetsFiles.push(tf); 4for(uint i=0;i<tweetsID.length;i++){ 5storedTweets[tweetsID [i]] =tweetsFiles.length -1; 6} 7} Figura 8.19: Funci´on setFile() del smart contract datos de los tweets, y con la funci´on fetch se conecta a la API enviando el archivo en el campo “body”de la petici´on. Este c´odigo viene m´as detallado en la figura 8.13 en el apartado anterior, junto con su explicaci´on. Env´ıo de datos: Proporciona los tweets almacenados en IPFS al frontend de la aplicaci´on. Hace uso de un m´etodo GET de la API. En este caso, primero se accede desde el c´odigo en Javascript a la funci´on del contrato en Solidity getFiles que devuelve el array principal del contrato en la blockchain. Ver la figura 8.21. Esta funci´on es de tipo view dado que no modifica el estado de la blockchain, por lo que no consume nada al ser llamada. 1function getFiles()external view returns (TweetsFile [] memory){ 2return tweetsFiles; 3} Figura 8.21: Funci´on getFiles() del smart contract 87 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.20: Diagrama de secuencia del m´etodo POST de la API Usando el array con los hashes y los IDs asociados a cada hash, se recorren todos los elementos, descargando el contenido de IPFS con los hashes. La descarga se realiza por trozos o chunks, y una vez descargados se les da un formato JSON, el que ten´ıan antes de ser subidos, y se recorren los tweets comprobando que su ID se encuentra en la lista de IDs asociados al fichero. En caso de no encontrarse, significa que ese tweet ha sido actualizado y que su informaci´on m´as reciente est´a en otro fichero, por lo que se elimina de la respuesta. Cuando un fichero no contenga ning´un tweet v´alido, se elimina su “hueco vac´ıo”que deja en la respuesta y se pasa a comprobar el siguiente hash. A continuaci´on, se limpia la respuesta de corchetes, y se a˜naden comas entre los distintos JSONArray para almacenarlos de forma conjunta y continua y que la respuesta sea un ´unico JSONArray con la informaci´on de cada tweet. Por ´ultimo, se env´ıa la respuesta como tipo string. En la figura 8.22 podemos comprobar el funcionamiento de esta parte mediante un diagrama de secuencia. Actualizaci´on de datos: Actualiza los metadatos de los tweets almacenados en IPFS. Hace uso de un m´etodo GET de la API. Para realizar la actualizaci´on autom´atica de los datos, se llama a este m´etodo para indicar que ha de comenzar sin tener que enviar ning´un otro dato. Al igual que en el env´ıo de datos, primero se accede desde el c´odigo en Javascript a la funci´on del contrato en Solidity getFiles. Tambi´en se recorren todos los elementos descargando el contenido de IPFS y se le da formato al contenido descargado, pero en este caso, si se alcanza la cantidad de tweets que se pueden mirar, para de hacer comprobaciones. Una vez se ha recompuesto la informaci´on de IPFS, y se ha comprobado que el ID del tweet est´a en la lista de IDs asociados, se llama a la API de Twitter para Javascript a la que se le pasa el ID del tweet. Este m´etodo nos devuelve la informaci´on que tiene Twitter sobre ese tweet en concreto y comprobamos que las m´etricas que 88 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.22: Diagrama de secuencia del m´etodo GET de la API pueden haber variado con el tiempo y nos interesa mostrar en la web, es decir, los retweets, los likes y las respuestas, no sean diferentes a las que tenemos almacenadas. En caso de ser diferentes, ´estas se modifican y se almacena la informaci´on del tweet en un array con todos los que se van a actualizar y el ID en otro array. Una vez se han probado todos los tweets, se sube a IPFS un nuevo fichero con todos los actualizados y el hash de este archivo se le pasa al contrato junto con la lista de IDs que hemos subido a IPFS llamando a la funci´on updateTweets. Esta funci´on se encarga de a˜nadir el nuevo fichero al array principal como si de un archivo con tweets nuevos se tratase y modificar el mapa de clave ID, valor posici´on del array del hash del fichero en el que se almacena sustituyendo la posici´on por la del nuevo fichero, tambi´en elimina el ID de la lista de asociados a su hash anterior. Para ello recorre la lista de IDs asociados al fichero y comprobando que dos identificadores son iguales, al ser tipo string no se puede hacer la comparaci´on con “==”, sino que se debe usar keccack para calcular el hash y comprobar que los bytes sean iguales, una vez encontrado se quita del array usando la funci´on pop(). En caso de que el array quede vac´ıo se elimina, pero no el hash del fichero por motivos de inmutabilidad e integridad. La actualizaci´on se realiza gracias a un c´odigo que se encarga de llamar peri´odicamente a este m´etodo. Este c´odigo que est´a aparte es un cron que utiliza los m´odulos nodefetch para enviar peticiones a la API y node-schedule para actuar de cron. Tambi´en almacena el n´umero de tweets que lleva actualizados y una variable booleana que se encarga de limitar la llamada a la actualizaci´on de los datos para que no actualizar m´as veces de las que se pillan los datos y evitar consumo de memoria del contrato innecesaria. Este c´odigo primero obtiene el n´umero de tweets actualmente v´alidos que hay con una llamada al m´etodo get de la API. Con la longitud de la respuesta, sabe el n´umero de tweets que tiene y lo almacena. Despu´es hay dos funciones que se llaman de forma peri´odica. La primera, como se puede ver en la figura 8.24 es un trabajo que se llama cada 2 minutos, tiempo suficiente para que la API haya podido actualizar una tanda de 89 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON 1function updateTweets(string memory hash,string[] memory tweetsID) external { 2for(uint j=0;j<tweetsID.length;j++){ 3uint pos =storedTweets[tweetsID [j]]; 4for(uint i=0;i<tweetsFiles[pos].tweetID.length;i++){ 5if(keccak256(abi.encodePacked(tweetsFiles[pos ]. tweetID[i])) == keccak256(abi.encodePacked( tweetsID[j]))){ 6tweetsFiles[pos].tweetID[i]=tweetsFiles[pos ]. tweetID[tweetsFiles[pos ].tweetID.length-1]; 7tweetsFiles[pos]. tweetID . pop(); 8} 9} 10 if(tweetsFiles[pos ].tweetID.length == 0){ 11 delete tweetsFiles[pos ].tweetID; 12 } 13 } 14 TweetsFile memory tf =TweetsFile (hash,tweetsID); 15 tweetsFiles.push(tf); 16 for(uint i=0;i<tweetsID.length;i++){ 17 storedTweets[tweetsID [i]] =tweetsFiles.length -1; 18 } 19 } Figura 8.23: Funci´on updateTweets del smart contract tweets. Esta funci´on, si el booleano de control es verdadero, llama al m´etodo update de la API e incrementa la variable que almacena el n´umero de tweets actualizados, si se han terminado de actualizar todos, pone el booleano a falso para que no se puedan seguir haciendo llamadas. La segunda funci´on se ejecuta cada m´as tiempo, en este caso d´ıas. Se encarga de que una vez ha pasado suficiente tiempo, ponga la variable de control a verdadero para que se pueda volver a ejecutar la actualizaci´on de los datos y obtiene el n´umero de tweets con otra llamada al get de la API, porque la cantidad de tweets a actualizar puede haber cambiado. 8.3. Bloque 3: Mostrar datos Finalmente, estudiamos la parte de la arquitectura destinada a mostrar y representar datos. Es decir, el tercer bloque que se observa en la figura 8.1. Como hemos mencionado con anterioridad, est´a constituido por tres proyectos que se ejecutan de forma independiente. Proyecto cache-twitter: desarrollado en node.js, y haciendo uso de express, es el servidor que se encarga de recibir y gestionar peticiones sobre la base de datos de MongoDB. Esta base de datos act´ua como una “memoria cach´e”. Como mencionamos en desarrollo, se tom´o esta decisi´on porque los accesos a IPFS son costosos en tiempo. Por lo tanto, 90 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON 1schedule.scheduleJob('*/2 * * * *',async function(){ 2if(ok){ 3await fetch ('https :// precariedappv2.herokuapp.com / update ',{ method:"GET"}); 4numUpdated+=20; 5if(numUpdated>=numTweets ){ 6ok=false ; 7numUpdated =0; 8} 9} 10 }); Figura 8.24: C´odigo de ayuda para actualizar la API reducimos la cantidad de ellos a cada dos d´ıas. Esos accesos sirven para actualizar la BBDD que se encarga de proporcionar datos a la aplicaci´on web. Proyecto dashboard-twitter: desarrollado en React, representa el frontend de la aplicaci´on. Muestra los datos recogidos en la BBDD que hemos construido. Observamos que los datos mostrados no est´an actualizados en tiempo real. Proyecto update-cache-twitter: desarrollado en node.js, recoge datos de IPFS cada dos d´ıas para actualizar la “memoria cach´e”. Observamos que se ha seguido la arquitectura full-stack conocida como MERN (MongoDB, express.js,React.js yNode.js). Estudiemos en detalle el funcionamiento de cada uno por separado. 8.3.1. cache-twitter Creamos un servidor que se queda a la escucha de peticiones realizadas tanto por la p´agina web (dashboard-twitter), como por el script encargado de actualizar la “memoria cach´e” (update-cache-twitter). Una vez aceptada la petici´on HTTP, el servidor utiliza un cliente de la base de datos que hemos creado para conectarse con ella y realizar la acci´on que se haya solicitado. Contamos con un fichero .env que hace de capa de seguridad al acceder a la BBDD de MongoDB Atlas. Podemos ver en el diagrama de secuencia 8.25 las interacciones que se llevan a cabo. Observamos el tipo de peticiones que realizan la p´agina web y el script a la BBDD: P´agina web:´ Unicamente hace las consultas necesarias para mostrar datos en el dashboard, no puede modificar el contenido de la BBDD. Estas consultas se filtran y ordenan seg´un los criterios que estipule la p´agina web, para lo cu´al se ha heho uso de las funciones db.collection.find() ydb.collection.sort(). Observamos que, con el fin de aumentar la eficiencia de la BBDD para gestionar estas peticiones, se han implementado ´ındices 91 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.25: Diagrama de secuencia de cache-twitter en los campos date,user,retweets ylikes. Por un lado, existe una consulta que obtiene todos los datos filtrados por una fecha de inicio y final (figura 8.26). Por otro lado, existe otra consulta que adem´as de lo anterior, devuelve los tweets ordenados de 4 posibles maneras (fecha ascendente/descendente, cantidad de likes y cantidad de retweets) y tiene la opci´on de filtrar o no los tweets de acuerdo al nombre de usuario o por palabras en el texto del tweet (figura 8.27). 1router.route("/").get(function (req ,res){ 2let db_connect =dbo.getDb ("twitter"); 3let date_start =parseInt(req.query.dateStart); 4let date_end =parseInt(req.query.dateEnd); 5db_connect 6.collection("tweets_ipfs") 7.find ({date:{$gt:date_start ,$lt :date_end } }) 8.toArray(function (err,result){ 9if (err)throw err; 10 res.json(result); 11 }); 12 }); Figura 8.26: Llamada realizada por la p´agina web: datos filtrados por fecha 92 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON 1router.route("/ words ").get(function (req ,res ){ 2let db_connect =dbo.getDb ("twitter"); 4let word =req.query.word; 5let date_start =parseInt(req.query.dateStart); 6let date_end =parseInt(req.query.dateEnd); 7let order =parseInt(req.query.order); 9let textuser =word[0]== "@" ?" user " :"text" 10 let nameVariable =(order == 0|| order == 1)?" date" :(( order == 2)?" retweets " :" likes "); 11 let ascdesc =(order == 1)?1: -1; 12 value =word[0]== "@" ?word.slice (1):{$regex:word }; 14 var query ={} 15 query ['date']={$gt:date_start ,$lt :date_end }; 16 query [textuser]=value ; 18 var query_sort ={}; 19 query_sort [nameVariable]=ascdesc; 21 db_connect 22 .collection("tweets_ipfs") 23 .find (query ) 24 .sort (query_sort ) 25 .toArray(function (err,result){ 26 if (err)throw err; 27 res.json(result); 28 }); 29 }); Figura 8.27: Llamada realizada por la p´agina web: datos filtrados por fecha y/o nombre de usuario y/o palabra en el texto, y ordenados (fecha ascendente/descendente o cantidad de likes/retweets) Script: Encargado de gestionar la BBDD, realiza operaciones para eliminar todos los elementos de la BBDD y a˜nadir elementos dado un array (figura 8.28). Para ello, se ha hecho uso de las funciones db.collection.deleteMany() ydb.collection.insertMany(). 93 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON 1// To add a list of tweets to the data base 2router.route("/add").post (function (req ,response){ 3let db_connect =dbo.getDb ("twitter"); 4db_connect.collection("tweets_ipfs").insertMany(req.body ,function (err,res){ 5if (err)throw err; 6console.log(" Tweets added successfully "); 7response.json (res); 8}); 9}); 11 // To delete all tweets from the data base 12 router.route("/delete").delete((req,response)=> { 13 let db_connect =dbo.getDb ("twitter"); 14 db_connect.collection("tweets_ipfs").deleteMany({},function (err, obj){ 15 if (err)throw err; 16 console.log(" All document deleted "); 17 response.json (obj); 18 }); 19 }); Figura 8.28: Llamadas realizadas por el script 8.3.2. update-cache-twitter Est´a constituido por un script que, de forma autom´atica, accede cada dos d´ıas a los datos almacenados en IPFS. Para ello, utiliza el m´etodo get proporcionado por la API del Bloque 2. Posteriormente, elimina el contenido de la BBDD y vuelca los nuevos datos actualizados sobre ella, utilizando las funciones delete yadd explicadas en el proyecto anterior. Mostramos en la figura 8.29 dichas llamadas. Observamos que se ha hecho uso del paquete node-schedule de npm para implementar la periodicidad del script (una vez cada dos d´ıas) y de node-fetch para gestionar las llamadas HTTP. Adem´as, destacamos que se ha implementado una estructura de control de errores de forma que si no se obtienen bien los datos de IPFS, la BBDD permanece inalterada. De la misma manera, no se a˜nadir´an tweets si la eliminaci´on previa ha fallado. 94 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.36: Componente AppTweets 101 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.37: Componente AppWordcloud Figura 8.38: Componente AppWordsTime alfanum´ericos. El componente obtiene los datos invocando la funci´on getDataWordcloud, que devuelve las palabras junto a su cantidad de apariciones. AppWordsTime: Figura 8.38. Muy relacionado con el componente anterior, AppWordsTime toma las tres palabras m´as utilizadas en denuncias a d´ıa de hoy y muestra cu´al ha sido su progresi´on y correlaci´on a lo largo del tiempo. Para ello, calcula, utilizando expresiones regulares, el n´umero de apariciones de dicha palabra, o derivadas de ella, en los tweets que se publicaron cada d´ıa. La gr´afica permite elegir qu´e palabras visualizar, as´ı como hacer zoom sobre un periodo de tiempo en particular. El componente obtiene los datos invocando la funci´on getDataWordsTime, que proporciona las palabras m´as utilizadas y sus apariciones a lo largo del tiempo. 102 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.39: Componente AppHeatmap AppHeatmap: Figura 8.39. AppHeatmap desglosa la cantidad de tweets por d´ıa de la semana y mes del a˜no, para dar una visi´on de cu´ales son los momentos del a˜no en los que m´as denuncias se han publicado. De esta forma, se pueden analizar tendencias anuales en los problemas laborales existentes. El componente obtiene los datos invocando la funci´on getDataHeatmap, que proporciona la cantidad de tweets por d´ıa y mes. AppTimeline: Figura 8.40. Este componente contiene una gr´afica en la que podemos visualizar la variaci´on, a lo largo del tiempo, en la cantidad de tweets, likes y retweets. Se tom´o la decisi´on de usar un doble eje vertical porque estas variables utilizaban escalas muy distintas. Incluimos la posibilidad de elegir cu´ales de estas variables queremos visualizar y poder hacer zoom sobre un periodo de tiempo en particular. El componente obtiene los datos invocando la funci´on getDataTimeline, que devuelve la cantidad de tweets, likes y retweets a lo largo del tiempo. 103 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Figura 8.40: Componente AppTimeline 8.3.3.3. Estilos A la hora de estilizar nuestra aplicaci´on, hacer uso de la plantilla de Minimal nos aport´o algunas facilidades para personalizar el proyecto a nuestro gusto. ´ Esta nos proporcionaba una estructura sobre la que trabajar y escoger los temas que quer´ıamos usar, basada en la customizaci´on que proporciona Material UI. La configuraci´on de estilos que proporciona Material UI hace uso del componente ThemeProvider. Se basa en el uso del hook useContext para pasar la informaci´on relacionada con estilos a trav´es del ´arbol de componentes, sin tener que enviar las propiedades manualmente en cada nivel. En nuestro caso, dentro de la carpeta themes, encontramos el fichero index.js que define el contexto mediante el componente ThemeConfig. Adem´as, hace el uso del hook useMemo para solo calcular el valor memorizado que contiene los estilos cuando se renderiza, evitando as´ı c´alculos de m´as en cada renderizaci´on y optimizando la eficiencia de la aplicaci´on. La principal forma en la que hemos llevado a cabo la modificaci´on de temas ha sido utilizando las variables que define Material UI, como palette,typography ocomponents. Permiten, respectivamente, definir una paleta de colores, la tipograf´ıa utilizada y sobreescribir los componentes por defecto. Comentamos, a continuaci´on, algunas de las modificaciones llevadas a cabo. En referencia a la paleta de colores usada, seguimos con la l´ınea de Material UI que propone escoger tonalidades distintas para diferentes situaciones: Color primario (primary): es el color m´as frecuente en la aplicaci´on y se encuentra en los elementos principales de la misma. 104 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON Color secundario (secondary): sirve para acentuar y diferenciar algunos elementos de la aplicaci´on. Color de error (error): presente en los elementos que el usuario debe conocer. Color de aviso (warning): usado para representar avisos importantes. Color de informaci´on (info): se utiliza para mostrar informaci´on neutral. Color de ´exito (success): indica acciones completadas de forma correcta. Observamos que estos colores tambi´en se emplean en el uso de visualizaci´on de datos a la hora de dibujar las gr´aficas, manteniendo as´ı la concordancia de colores en toda la aplicaci´on. Como nuestro proyecto est´a relacionado con Twitter, decidimos emplear una paleta de colores relacionada con la red social. Esta paleta se muestra en la Figura 8.41. Vemos que utiliza como color primario y de informaci´on el azul de “Larry”, el ic´onico p´ajaro del logo de Twitter. Como color secundario y de error utiliza el rojo asociado al like de un tweet. El verde del retweet se utiliza como color de ´exito. Y por ´ultimo, el amarillo del antiguo bot´on de fav (sustituido por el like) se utiliza como color de aviso. Figura 8.41: Paleta de colores. Gradientes obtenidos de la herramienta online Coolors. La paleta se encuentra en el archivo palette.js, donde se declara la variable que va a ser exportada para establecerse como la paleta empleada por Material UI en nuestro proyecto. Observamos que en ella tambi´en se definen distintas tonalidades para las gr´aficas, una amplia variedad de tonos grises o los colores del texto y de los fondos, entre otros. Por otro lado, las distintas opciones para la configuraci´on de la tipograf´ıa se encuentran en el fichero typography.js, donde se puede configurar el tama˜no de cada tipo de letra y la fuente empleada. En nuestro caso, hemos seleccionado Helv´etica Neue, ya que es muy utilizada en 105 CAP´ ITULO 8. ARQUITECTURA DE LA SOLUCI´ ON dise˜no web, y en particular es la fuente que utiliza Twitter Web[105]. Otra funci´on que permite Material UI, como hemos comentado, es sobreescribir componentes. En nuestro caso, utilizamos los componentes sobreescritos Button,IconButton,Card, Input,List, y Typography. Se pueden encontrar dentro de la carpeta overrides. Por ´ultimo, destacamos el uso de la utilidad de styled(), que utilizan todos los componentes de Material UI, y que nos ha permitido modificar algunos que est´an incluidos en el contexto de los temas para aplicarlo de manera distinta en cada uno de ellos. 106 CAP´ ITULO 9. EVALUACIONES Cap´ıtulo 9 Evaluaciones Una vez llevada a cabo la implementaci´on, es necesario realizar una evaluaci´on de resultados para comprobar qu´e objetivos se han cumplido, cu´ales no, y qu´e modificaciones llevar a cabo. Observamos que evaluamos el funcionamiento de la aplicaci´on tomando dos puntos de vista; interfaz de usuario y an´alisis de lenguaje natural. 9.1. Evaluaci´on: Interfaz de usuario Durante el transcurso del proyecto, se realizaron varias sesiones de seguimiento y evaluaci´on con los tutores del TFG que resultaron en m´ultiples mejoras del proyecto. Sin embargo, una vez finalizado, decidimos llevar a cabo una evaluaci´on con usuarios finales con el objetivo de obtener informaci´on detallada y fiel a las necesidades del p´ublico final de la interfaz. Observamos que los 10 principios de dise˜no de Jakob Nielsen se han tenido en cuenta en el dise˜no de la inferfaz. Sin embargo, al ser una interfaz simple y haber contado con el apoyo de expertos durante su desarrollo, hemos optado por no realizar una evaluaci´on heur´ıstica y centrarnos en los usuarios finales. 9.1.1. Plan de evaluaci´on Identificaci´on del prop´osito y los objetivos de la evaluaci´on El primer paso de la evaluaci´on con usuarios es establecer el prop´osito y los objetivos de ´esta. Buscamos identificar qu´e aspectos de la interfaz funcionan bien, cu´ales no, y por qu´e motivo. Esto nos servir´ıa para establecer el posible trabajo a futuro y las mejoras que se pueden implementar. Extraemos los siguientes objetivos de alto nivel: Determinar si la interfaz resulta f´acil de entender y utilizar por los usuarios finales. Identificar aquellos elementos de la interfaz que dificultan al usuario la realizaci´on de sus tareas por resultar poco intuitivos o por propiciar que el usuario cometa errores. Identificar aquellos elementos que, por el contrario, el usuario echa en falta. 107 CAP´ ITULO 9. EVALUACIONES Encontrar la mejor forma de solucionar cada uno de los problemas del punto anterior, sin degradar la usabilidad de otras partes de la interfaz. Detectar qu´e elementos gustan y resultan intuitivos al usuario. Identificar los requisitos que deben cumplir los participantes Buscamos participantes que posean las caracter´ısticas detectadas en la fase de investigaci´on (cap´ıtulo 6). Al tratarse de un perfil muy variado, vamos a intentar reunir a un grupo de usuarios finales que representen suficiente diversidad en cuanto a rango de edad, profesi´on, organismo en el cu´al se desempe˜na dicha profesi´on, si han sufrido situaciones de injusticia laboral o si tienen alg´un inter´es en eliminarlas activamente. Descripci´on del dise˜no experimental A cada participante, se le va a explicar en qu´e consiste la evaluaci´on y se le va a pedir realizar un cuestionario inicial. El objetivo de este ´ultimo es conocer sus caracter´ısticas, as´ı como el nivel de conocimiento que poseen relacionado con nuestra aplicaci´on. De esta manera, podemos entender y analizar mejor los resultados obtenidos, y ver si las caracter´ısticas del usuario pueden estar afectando a su interacci´on con la interfaz. Posteriormente, un moderador le pedir´a al participante que interact´ue con la p´agina web, resolviendo una serie de tareas. Adem´as, se le enviar´a un cuestionario an´onimo para que pueda dar su opini´on sin estar condicionado, lo que nos permitir´a conocer su punto de vista. El objetivo es recoger datos cualitativos (elementos que gustan/disgustan, que son f´aciles/dif´ıciles de usar, nivel de satisfacci´on/frustraci´on del usuario...). No obstante, tambi´en se tendr´an en cuenta algunos cuantitativos (nºde tareas bien realizadas, nºde tareas para las que se necesita ayuda, tiempo de respuesta...). Concluimos indicando las m´etricas utilizadas para evaluar las tareas: Tiempo de respuesta: R´apido (menor a 5sec), Medio (entre 5y15sec) o Lento (m´as de 15sec). Necesidad de ayuda: (ninguna ayuda), (ha necesitado gu´ıa) o 7(no ha sabido). 9.1.2. Materiales necesarios para la evaluaci´on Antes de realizar la prueba de evaluaci´on, hicimos las siguientes preparaciones: Gui´on para la orientaci´on previa: Anexo A.1. Cuestionario previo: Anexo A.2. Tareas y escenarios 108 CAP´ ITULO 9. EVALUACIONES 1. Dime el total de denuncias 2. Dime la cantidad de personas que han puesto denuncias 3. ¿Puedes leerme una denuncia? 4. ¿Qu´e denuncias ha puesto el usuario X? 5. Busca una denuncia relacionada con “vacaciones” 6. ¿Qu´e denuncia ha recibido la mayor cantidad de likes? 7. Si quisieses poner una denuncia desde el dashboard, ¿c´omo lo har´ıas? 8. Filtra por fechas para ver datos correspondientes ´unicamente al ´ultimo mes 9. Ind´ıcame el perfil del usuario que m´as denuncias ha puesto 10. Visita su perfil 11. ¿Cu´al es el hashtag m´as utilizado? 12. ¿Cu´al es la palabra m´as utilizada en denuncias? 13. ¿C´omo evoluciona dicha palabra a lo largo del tiempo? 14. ¿C´omo var´ıa la cantidad de denuncias con el tiempo? 15. Haz que en el gr´afico solo aparezca la cantidad de retweets en el tiempo 16. ¿En qu´e momento del a˜no hay mayor n´umero de denuncias? 17. Si quiero saber m´as sobre la iniciativa, ¿d´onde me meto para averiguarlo? Cuestionario final: Anexo A.3. 9.1.3. Resultados de la evaluaci´on Dedicamos esta secci´on a mostrar los resultados obtenidos durante el proceso de evaluaci´on. En primer lugar, el cuadro 9.1 muestra las m´etricas resultantes y la acumulaci´on de las observaciones realizadas durante las evaluaciones. Para calcular las m´etricas, hemos seguido las siguientes reglas: −Resoluci´on: Si m´as de un tercio de los usuarios necesitan ayuda, entonces consideramos que se necesita ayuda. Si m´as de un cuarto no saben realizar una tarea, entonces no se sabe realizar la tarea. El motivo de estas decisiones es que, para que la aplicaci´on sea intuitiva, las personas que necesiten ayuda o no sepan realizar tareas deben ser una minor´ıa. −Tiempo de respuesta: Al tratarse de un dato cuantitativo, hemos optado por realizar la media de los tiempos. Si se quiere ver en detalle, de forma individualizada, la informaci´on, acceder a: Sesi´on 1: 109 CAP´ ITULO 9. EVALUACIONES −Cuestionario previo: Anexo A.4. −Tareas y observaciones: Anexo A.1. Sesi´on 2: −Cuestionario previo: Anexo A.4. −Tareas y observaciones: Anexo A.2. Sesi´on 3: −Cuestionario previo: Anexo A.4. −Tareas y observaciones: Anexo A.3. Sesi´on 4: −Cuestionario previo: Anexo A.4. −Tareas y observaciones: Anexo A.4. Sesi´on 5: −Cuestionario previo: Anexo A.4. −Tareas y observaciones: Anexo A.5. Por otro lado, la informaci´on recogida durante los cuestionarios finales an´onimos fue tanto cuantitativa como cualitativa. En el cuadro 9.2 se observa la primera y, a continuaci´on, la segunda: La iniciativa ha tenido muy buena acogida y ha parecido original. Los entrevistados han expresado su inter´es en tener un lugar donde se pueda dar visibilidad a situaciones de injusticia laboral, especialmente con la importancia que est´a cobrando a nivel social. Adem´as, hacen hincapi´e en que se alimente desde un lugar de libre acceso por los trabajadores, como es la red social Twitter. La preocupaci´on m´as repetida ha sido la relacionada con la fiabilidad de los datos. Consideran que al ser extra´ıdos de Twitter, deber´ıa existir alg´un medio por el cu´al se verifiquen. Muestran su inter´es en que la iniciativa pueda generalizarse a otro tipo de denuncias. Lo que m´as ha llamado la atenci´on del dashboard ha sido su claridad y atractivo visual. Consideran que es intuitivo. Consideran que ellos mismos le dar´ıan uso a la aplicaci´on en caso de estar buscando trabajo o vivir una situaci´on de injusticia. Tambi´en destacan el uso que pueden darle organismos sociales y laborales. Algunas funcionalidades que proponen a˜nadir son: diferenciar sectores laborales, g´enero, edad o localizaci´on. 110 CAP´ ITULO 10. CONCLUSIONES Y TRABAJO A FUTURO Emplear consultas m´as complejas a la hora de obtener tweets, esto acelerar´ıa enormemente el n´umero de denuncias obtenidas. Se podr´ıan emplear mejores servidores para ejecutar el c´odigo, ya que debido a los recursos de los que disponen la recolecci´on de datos es m´as lenta que en un equipo de uso convencional. Un sistema de detecci´on de denuncias falsas podr´ıa ser una buena incorporaci´on al proyecto, aunque podr´ıa presentar muchos fallos, dejando fuera denuncias que pudieran ser ciertas. 10.2.2. Sobre el uso de la blockchain Mostramos tres v´ıas que podr´ıan seguirse para mejorar la integraci´on de este proyecto con un uso m´as eficiente de tecnolog´ıas basadas en blockchain. Redise˜nar el sistema de acceso a la memoria del contrato que realiza el c´odigo en javascript evitando usar APIs de otros sistemas. Los contratos inteligentes son p´ublicos y la informaci´on que estos manejan tambi´en. Planteamos que sea el propio c´odigo de la API que hemos creado el que acceda de forma directa a la memoria del contrato. De esta forma, obtiene los datos minimizando las funciones en la blockchain que incrementan el gasto y reduce el c´odigo usado en Solidity. Utilizar c´odigo de bajo nivel EVM para reducir el n´umero de instrucciones m´aquina que genera el compilador, de forma que se optimice el consumo de gas del contrato. Quiz´a hay otras formas de obtener la informaci´on necesaria para realizar la actualizaci´on de informaci´on que est´en menos limitadas en cuanto a flujo de ejecuci´on, lo que mejorar´ıa significativamente el tiempo empleado en estas funciones y har´ıa esta parte m´as escalable. 10.2.3. Sobre la interfaz de usuario Por un lado, tras las evaluaciones realizadas con usuarios finales, proponemos realizar cambios en el dise˜no de la aplicaci´on que mejoren la experiencia de usuario. Destacar elementos importantes como el bot´on para filtrar por fecha, ordenar o publicar la denuncia en Twitter. Mejorar la b´usqueda dentro de las denuncias (marcar la palabra buscada en el texto o no exigir el uso de la @). Valorar la integraci´on de la interacci´on con Twitter dentro de la aplicaci´on, y permitir que el usuario realice las acciones s´olo desde nuestra web. Por otro lado, planteamos aumentar las funcionalidades actuales del dashboard haciendo uso de los requisitos no implementados y proponiendo nuevas ideas. 117 CAP´ ITULO 10. CONCLUSIONES Y TRABAJO A FUTURO Aumentar las opciones de filtro y personalizaci´on en funci´on de distintos par´ametros: g´enero, edad, tipo de denuncia, sector laboral al que pertenece etc. Este cambio es altamente dependiente de la recolecci´on de datos. A pesar de que no todos los tweets incluyen la localizaci´on, se podr´ıa valorar utilizarla para mostrar un mapa con los tweets disponibles o para realizar un filtrado sobre ellos. Permitir comparativas en base a los par´ametros anteriores, incluyendo alg´un tipo de sistema de reputaci´on. Incluir un sistema de recogida de denuncias por parte de aquellos usuarios que no tengan cuenta de Twitter. Podr´ıa ser an´onima o incluyendo un nombre. Valorar la opci´on de publicarlos desde una cuenta oficial de Injustweet. 118 CAP´ ITULO 11. CONCLUSIONS AND FUTURE WORK Cap´ıtulo 11 Conclusions and future work 11.1. Conclusions It can be concluded at this stage that we have been able to develop an application that satisfies the main goals established at the beginning of the project. They can be found at chapter 2. First of all, Injustweet is a platform that gives visibility to workplace denouncements thanks to the use of graphs and statistics. According to the results obtained in the evaluation stage with users, we have been able to implement an interface wich is not only intuitive and atractive, but also functional. It satisfies most of the requirements proposed. Besides that, even though there is a gigantic amount of data in Twitter, we have been able to obtain only those related to workplace denouncements from Spanish-speaking users. That has been possible thanks to the use of natural language processing techniques (NLP). As shown in the stage of evaluation, the results obtained from the analysis are very accurate. Finally, on another note, we have also been able to mitigate the problem of censorship in Twitter. It has been possible thanks to the use of distributed storage, which guarantees that even if data is deleted from Twitter, we will still have a copy of it. However, in spite of obtaining such good results and a final product that makes us feel proud, we have to take into account that it has its limitations. The project was very ambitious, that is why we had to drop some requirements at early stages. Moreover, we faced technological impediments. Below you can view some examples. As shown in chapter 6.2, some requirements were considered non-priority and dropped. The most important one is that we had to limit the number of characteristics obtained from the data (type of complaint, localization, laboral sector...). To be able to implement it, we would have needed more data and analytical capability. As we mentioned before, the use of distributed storage has enable us to guarantee that even if data is deleted from Twitter, there will always be a copy of it. However, that could raise an issue. If fake data is added to the blockchain, it will be kept forever. It is at this point that we would like to highlight that we are not only proud of the results just shown, but also of the process that led as to achieve them. The development of this 119 CAP´ ITULO 11. CONCLUSIONS AND FUTURE WORK project has turned out to be very enriching and has helped us learn in different ways. On one hand, we have used technologies we had never worked with before. For example, we built the frontend with React and the backend with blockchain. That is way, in spite of having a period of time dedicated to learning, we spent most of the project researching. On the other hand, we have put into practice methodologies that we only knew from a theoretical approach. Therefore, we have better understood how projects are managed and carried out. Especially taking into account that we were a team of six, and that we had to plan and coordinate the project from start to finish. To give an example, one of the biggest challenges we faced was the time where we had to put all the project together. From that point on, communication was a key part of it. Every change made had to be discussed and planned beforehand. Finally, we want to emphasize that due to the nature of the initiative we have learned how to solve a real-world problem and empathize with the people who are involed in it. We were able to use our technological knowledge to develop an application by bearing in mind that users do not usually have it. To conclude, we have created a product that even with it’s limitations, it is able to satisfy the main goals established. Moreover, thanks to the process followed, we have acquired skills that will be very useful in future projects. 11.2. Future work While developing our project, and thanks to the results obtained in the stage of evaluation, we have been able to detect some problems and changes that could be made. We propose them as future work and encourage anyone interested to develop them by using free software. 11.2.1. Data recollection We propose the following ways of improving the way in which data is recollected and the kind of data obtained. To obtain more quantity and diversity of data (gender, age, localization, type of complaint...). To improve the algorithm used. For example, by incrementing the size of the dictionary or using other methods of classification such as neural networks. To increase the complexity of the queries made so that tweets could be obtained at a higher speed. To consider using faster servers. Right know we face some limitations. To include a system which could help detect fake complaints. 120 CAP´ ITULO 11. CONCLUSIONS AND FUTURE WORK 11.2.2. Blockchain The efficiency of this project could be improved by making some changes in the backend. We propose the following ideas related to the use of the blockchain. To change the system in which we access the data of the smart contract so that we avoid using APIs from other systems. We propose to implement those functions in our javascript code to decrease the costs of the transactions. To use code EVM to reduce the number of machine instructions. This could further decrease the costs of the transactions. To consider obtaining the information required to update the data from other sources. Right now the API from Twitter is very limited, so this change would make the proyect more scalable. 11.2.3. User interface On one hand, after having interviewed many users, we have found some changes that could be made in order to improve the user experience. To give more visibility to important features such as the button used to filter, sort and publish a complaint in Twitter. To improve the way in which tweets are searched for (to highlight the word or to not require the use of @). To consider the possibility of including all the interaction with Twitter inside the dashboard, so that users can make every possible action without leaving the web page. On the other hand, we propose other functionalities that could be added. To increase the filter options and the capacity for giving a personalized experience by including more information (gender, age, type of complaint, laboral sector...). To include maps and information related to localization. To include diagrams that compare tweets according to the topics mentioned before. It could be a good idea to also include a reputation system. To implement a way of making complaints. It could be anonymous. Consider the possibility of publishing them from an official Injustweet account. 121 Anexos 122 AP´ ENDICE A. ENTREVISTAS Ap´endice A Entrevistas A.1. Gui´on inicial “La sesi´on de hoy va a consistir en una evaluaci´on de nuestra aplicaci´on, que es un dashboard en el que se muestran gr´aficos e informaci´on sobre denuncias laborales. Yo voy a moderar la sesi´on, y t´u ser´as el usuario de la aplicaci´on. Vamos a plantearte una serie de tareas que tendr´as que intentar resolver en la p´agina web. Durante estas tareas, me gustar´ıa que dijeras en voz alta todo lo que se te pase por la cabeza. Por ejemplo, los problemas que encuentras, las cosas que te confunden o lo que m´as te guste. Yo no voy a intervenir mientras t´u respondes. Es probable que haya momentos de silencio o que te anime a que sigas resolvi´endolo sin mi ayuda. Esto es porque queremos saber c´omo un usuario cualquiera utilizar´ıa la aplicaci´on sin ayuda externa. Cuando hayamos terminado, te haremos una peque˜na entrevista para recoger conclusiones. Si tienes alguna duda sobre el proceso o sobre lo que tienes que hacer, puedes hacerla ahora.” A.2. Cuestionario previo −¿Cu´antos a˜nos tienes? (Respuesta corta) −¿Has sufrido alguna situaci´on de injusticia laboral? (S´ı/No) −¿Has presenciado alguna situaci´on de injusticia laboral que no te haya pasado a ti? (S´ı/No) −¿Alguna vez has denunciado situaciones de injusticia laboral? (S´ı/No) −Indica tu situaci´on profesional (estudiante, tipo de trabajo, paro...) (Respuesta corta) −¿Trabajas en el sector p´ublico o privado? (P´ublico/Privado/Otro) −¿Has utilizado alguna vez un dashboard? (Utilizo a diario/He usado varias veces/Me suena haber visto alguno/Nunca) 123 AP´ ENDICE A. ENTREVISTAS −¿Tienes experiencia analizando gr´aficas? (S´ı, todo tipo de gr´aficas/S´ı, salvo que sean muy complejas/S´ı, s´olo gr´aficas simples/Ninguna experiencia) −¿C´omo de c´omodo te sientes entendiendo el lenguaje de Twitter (hashtags, likes, retweets, usuarios...)? (Soy experto/a/Algunos conceptos me fallan/No s´e nada) A.3. Cuestionario final −¿Qu´e te ha parecido la aplicaci´on y la iniciativa? (Respuesta larga) −¿Qu´e es lo que m´as te ha llamado la atenci´on? ¿Por qu´e? (Respuesta larga) −¿Crees que dar´ıas uso a la aplicaci´on? ¿Por qu´e s´ı/no? (Respuesta larga) −¿Hay funciones que te hayan gustado especialmente? ¿Alguna que no? (Respuesta larga) −¿Hay algo que no te haya quedado claro con ella? (Respuesta larga) −La aplicaci´on web me ha resultado f´acil de usar. En caso contrario, ¿por qu´e? (1 total desacuerdo - 5 total acuerdo) −La interfaz me resulta agradable a la vista. En caso contrario, ¿por qu´e? (1-5) −Me resulta ´util la informaci´on que muestran las gr´aficas. Indica si hay algo que no. (1-5) −La informaci´on que muestra la aplicaci´on me parece fiable. Indica posibles preocupaciones. (1-5) −Es sencillo acceder a Twitter. (1-5) −Es ´util acceder a Twitter. (1-5) −(Comentarios sobre la interacci´on con Twitter) −Es sencillo filtrar los datos. (1-5) −Es ´util filtrar los datos. (1-5) −(Comentarios sobre los filtros) −Es sencillo realizar b´usquedas. (1-5) −Es ´util realizar b´usquedas. (1-5) −(Comentarios sobre las b´usquedas) 124 AP´ ENDICE A. ENTREVISTAS −Es sencillo ver denuncias. (1-5) −Es ´util ver denuncias. (1-5) −(Comentarios sobre las denuncias) −Es sencillo entender las gr´aficas. (1-5) −Son ´utiles las gr´aficas. (1-5) −(Comentarios sobre las gr´aficas) −¿Has echado en falta algo que consideras importante a la hora de obtener informaci´on sobre precariedad laboral? En caso afirmativo, ¿el qu´e? (S´ı/No) −¿Recomendar´ıas la aplicaci´on a ...? (Respuesta larga) −Si quieres a˜nadir recomendaciones, opiniones, cr´ıticas o cualquier cosa que no haya quedado reflejada antes, puedes hacerlo. (Respuesta larga) A.4. Desarrollo entrevistas Cuestionarios previos Usuario 1 ¿Cu´antos a˜nos tienes?: 51 ¿Has sufrido alguna situaci´on de injusticia laboral?: S´ı ¿Has presenciado alguna situaci´on de injusticia laboral que no te haya pasado a ti?: S´ı ¿Alguna vez has denunciado situaciones de injusticia laboral?: S´ı Si quieres desarrollar dichas situaciones de injusticia laboral, puedes hacerlo aqu´ı: CONTRATACI´ ON EN CATEGOR´ IA INFERIOR, “CONTRATACI´ ON” SIN FORMALIZACI´ ON DE CONTRATO, CONTRATACI´ ON MEDIA JORNADA TRABAJANDO M´ AS TIEMPO, BECARIO SIN COBRAR/FORMALIZACI´ ON DE BECA/REALIZANDO TRABAJO SIN FORMACI´ ON, ACOSO LABORAL, DESPIDO IMPROCEDENTE... Indica tu situaci´on profesional (estudiante, tipo de trabajo, paro...): FUNCIONARIO ¿Trabajas en el sector p´ublico o privado?: P´ublico ¿Has utilizado alguna vez un dashboard?: He usado varias veces ¿Tienes experiencia analizando gr´aficas?: S´ı, salvo que sean muy complejas 125 AP´ ENDICE A. ENTREVISTAS ¿C´omo de c´omodo/a te sientes entendiendo el lenguaje de Twitter? (Hashtags, likes, retweets, usuarios...): Algunos conceptos me fallan Usuario 2 ¿Cu´antos a˜nos tienes?: 22 ¿Has sufrido alguna situaci´on de injusticia laboral?: S´ı ¿Has presenciado alguna situaci´on de injusticia laboral que no te haya pasado a ti?: S´ı ¿Alguna vez has denunciado situaciones de injusticia laboral?: No Si quieres desarrollar dichas situaciones de injusticia laboral, puedes hacerlo aqu´ı: pr´acticas sin remunerar, explotaci´on laboral Indica tu situaci´on profesional (estudiante, tipo de trabajo, paro...): estudiante de m´aster de la rama biosanitaria ¿Trabajas en el sector p´ublico o privado?: P´ublico ¿Has utilizado alguna vez un dashboard?: He usado varias veces ¿Tienes experiencia analizando gr´aficas?: S´ı, todo tipo de gr´aficas ¿C´omo de c´omodo/a te sientes entendiendo el lenguaje de Twitter? (Hashtags, likes, retweets, usuarios...): Soy experto/a Usuario 3 ¿Cu´antos a˜nos tienes? : 58 ¿Has sufrido alguna situaci´on de injusticia laboral?: S´ı ¿Has presenciado alguna situaci´on de injusticia laboral que no te haya pasado a ti?: S´ı ¿Alguna vez has denunciado situaciones de injusticia laboral?: No Si quieres desarrollar dichas situaciones de injusticia laboral, puedes hacerlo aqu´ı: En mi caso fueron hace a˜nos con una situaci´on personal dif´ıcil y los tuve que asumir, hoy no se dan y si se dieran no lo aceptar´ıa. He presenciado situaciones injustas relacionadas con el maltrato verbal y menosprecio de las personas que no denunci´e en su momento al presenciarlas y me arrepiento de no haberlo hecho. Indica tu situaci´on profesional (estudiante, tipo de trabajo, paro...): Soy profesional en una organizaci´on de IT y me dedico a la Gesti´on y seguimiento de los servicios que prestamos a terceros. ¿Trabajas en el sector p´ublico o privado?: Privado 126 BIBLIOGRAF´ IA Bibliograf´ıa [1] Afinn,Afinn. URL: https://github.com/darenr/afinn. [2] Airbnb,Visx. URL: https://airbnb.io/visx/. [3] Amazon,Amazon Web Services. URL: https://aws.amazon.com/es/. [4] T. Analytics,Twitter analytics. URL: https://analytics.twitter.com/about. [5] D. G. W. Andreas M. Antonopoulos,Mastering Ethereum: Building Smart Contracts and DApps, O’Reilly Media, Inc., 1st ed., 2018. [6] ApexCharts,Apexcharts. URL: https://apexcharts.com/. [7] A. Banks and E. Porcello,Learning React: Functional Web Development with React and Redux, O’Reilly Media, Inc., 1st ed., 2017. [8] O. W. Bertelsen and S. Bødker,Activity theory, HCI models, theories, and frameworks: Toward a multidisciplinary science, (2003), pp. 291–324. [9] Black Lives Matter,Black Lives Matter. URL: https://blacklivesmatter.c om/. [10] body parser,body parser. URL: https://github.com/expressjs/body-parser. [11] Bootstrap,Bootstrap. URL: https://getbootstrap.com/. [12] Certifi,Certifi. URL: https://certifiio.readthedocs.io/en/latest/. [13] Charts.js,Charts.js. URL: https://www.chartjs.org/docs/latest/. [14] V. S. Code,Visual studio code. URL: https://code.visualstudio.com/. [15] codecs,codecs. URL: https://docs.python.org/3/library/codecs.html. [16] E. Commission, J. R. Centre, P. De Filippi, J. Brekke, E. Mart´ ınez Vicente, G. Lop´ ez Morales, C. Orgaz Alonso, B. Bod´ o, S. Meiklejohn, S. Hassan, K. Beecroft, A. Figueras Aguilar, D. Rozas, and M. Atzori,Scanning the European ecosystem of distributed ledger technologies for social and public good : what, why, where, how, and ways to move forward, Publications Office, 2020. 133 BIBLIOGRAF´ IA [17] M. Cooley,Human-centered design, Information design, (2000), pp. 59–81. [18] M. Dalili and M. Dastani,The role of twitter during the covid-19 crisis: A systematic literature review, Acta Informatica Pragensia, 9 (2020). [19] M. Developer,Javascript. URL: https://developer.mozilla.org/es/docs/We b/JavaScript. [20] diagrams.net,diagrams.net. URL: https://www.diagrams.net/. [21] M. Dorash,Machine learning vs. rule based systems in nlp. URL: https://medi um.com/friendly-data/machine-learning-vs-rule-based-systems-in-nlp5476de53c3b8. [22] EasyOCR,Easyocr. URL: https://github.com/JaidedAI/EasyOCR. [23] emoji,emoji. URL: https://github.com/carpedm20/emoji/. [24] Ethereum,Solidity github. URL: https://github.com/ethereum/solidity. [25] Ethereum.org,Ethereum. URL: https://ethereum.org/en/developers/docs/ apis/javascript/. [26] , Ethereum Whitepaper. URL: https://ethereum.org/en/whitepaper/. [27] Etherscan,Etherscan. URL: https://etherscan.io/. [28] express,express. URL: https://expressjs.com/es/. [29] GIMP,GIMP - image manipulation. URL: https://www.gimp.org/. [30] Github,Github. URL: https://github.com/. [31] D. Glezos,Everything you need to know about machine translation. URL: https: //es.transifex.com/blog/2015/machine-translation-101/. [32] Googletrans,Google. URL: https://py-googletrans.readthedocs.io/en/la test/. [33] A. Gruzd and P. . Mai,Covid-19 misinformation portal – a rapid response project from the ryerson university social media lab. [34] J. Hao, Y. Sun, and H. Luo,A safe and efficient storage scheme based on blockchain and ipfs for agricultural products tracking, Journal of Computers, 29 (2018), pp. 158–167. [35] T. hdwallet provider,Truffle hdwallet-provider. URL: https://github.com/t rufflesuite/truffle/tree/master/packages/hdwallet-provider. [36] Heroku,Heroku. URL: https://id.heroku.com/. 134 BIBLIOGRAF´ IA [37] HTTP,HTTP docs. URL: https://httpwg.org/specs/rfc7231.html. [38] INE,INE gr´aficos. URL: https://www.ine.es/ss/Satellite?L=es ES&c=INESe ccion C&cid=1259925463134&p=1254735110672&pagename=ProductosYServicio s%2FPYSLayout. [39] Infura,Infura. URL: https://docs.infura.io/infura. [40] Instagram @trabajosruineros,Instagram @trabajosruineros. URL: https://ww w.instagram.com/trabajosruineros/?hl=es. [41] instagrapi,instagrapi. URL: https://adw0rd.github.io/instagrapi/. [42] IPFS,IPFS. URL: https://ipfs.io/. [43] Jobstice,Jobstice. URL: https://twitter.com/jobsticeoficial. [44] Js2Py,Js2Py. URL: https://github.com/PiotrDabkowski/Js2Py. [45] D. Jurafsky and J. H. Martin,Speech and Language Processing. [46] Keyring,Keyring. URL: https://github.com/jaraco/keyring. [47] R. Kumari,4 types of machine translation in nlp. URL: https://www.analyticss teps.com/blogs/4-types-machine-translation-nlp. [48] LaTeX project team ,The Latex Project. URL: https://www.latex-project. org/. [49] M. Learn,Text classification: What it is and why it matters. URL: https://monkey learn.com/text-classification/. [50] Licencia creative commons,Creative commons. URL: https://creativecomm ons.org/licenses/by/4.0/. [51] Licencia GNU,GNU. URL: https://www.gnu.org/licenses/gpl-3.0.html. [52] D. K. Mahto and L. Singh,A dive into web scraper world, in 2016 3rd International Conference on Computing for Sustainable Global Development (INDIACom), IEEE, 2016, pp. 689–693. [53] A. Matamoros-Fern´ andez and J. Farkas,Racism, hate speech, and social media: A systematic review and critique, Television & New Media, 22 (2021), pp. 205– 224. [54] Me Too Movement,Me Too Movement. URL: https://metoomvmt.org/. [55] Metamask. URL: https://metamask.io/. [56] Minimal Free,Minimal Free Dashboard. URL: https://github.com/minimalui-kit/material-kit-react. 135 BIBLIOGRAF´ IA [57] MongoDB,MongoDB Atlas. URL: https://www.mongodb.com/atlas/database. [58] , MongoDB Manual. URL: https://www.mongodb.com/docs/manual/. [59] A. Z. Mustafeez,Text classification in nlp. URL: https://www.educative.io/e dpresso/text-classification-in-nlp. [60] S. Nakamoto,Bitcoin: A peer-to-peer electronic cash system, 2009. [61] R. T. Nandita Krishnan, Jiayan Gu and L. C. Abroms,Research note: Examining how various social media platforms have responded to covid-19 misinformation, Harvard Kennedy School (HKS) Misinformation Review, (2021). [62] J. Nielsen,Ten usability heuristics, 2005. [63] Nivo,Nivo. URL: https://nivo.rocks/. [64] node fetch,node-fetch. URL: https://github.com/node-fetch/node-fetch. [65] node schedule,node-schedule. URL: https://github.com/node-schedule/nod e-schedule. [66] Node.js,Node.js. URL: https://nodejs.org/es/. [67] npm,About npm. URL: https://docs.npmjs.com/about-npm. [68] , Paquetes npm. URL: https://www.npmjs.com/. [69] C. C. (Organization),Copyleft: manual de uso, Traficantes de Sue˜nos, 2006. [70] Overleaf,Overleaf. URL: https://es.overleaf.com/. [71] pandas,pandas. URL: https://github.com/pandas-dev/pandas/. [72] Portwiture,Portwiture. URL: http://portwiture.com/. [73] PyCharm,PyCharm. URL: https://www.jetbrains.com/es-es/pycharm/. [74] PyMongo,PyMongo. URL: https://github.com/mongodb/mongo-pythondriver. [75] Pytesseract,Pytesseract. URL: https://github.com/madmaze/pytesseract. [76] Python,Python. URL: https://www.python.org/. [77] python dotenv,python-dotenv. URL: https://github.com/theskumar/pythondotenv. [78] D. Qiu and R. Srikant,Modeling and performance analysis of bittorrent-like peerto-peer networks, SIGCOMM Comput. Commun. Rev., 34 (2004), p. 367–378. [79] React,React. URL: https://es.reactjs.org/. 136 BIBLIOGRAF´ IA [80] , React Developer Tools. URL: https://es.reactjs.org/blog/2019/08/15/n ew-react-devtools.html. [81] react wordcloud,react-wordcloud. URL: https://react-wordcloud.netlif y.app/. [82] Recharts.js,Recharts.js. URL: https://recharts.org/en-US/api. [83] remix,remix. URL: https://remix-ide.readthedocs.io/en/latest/. [84] Rinkeby,Rinkeby. URL: https://rinkeby.etherscan.io/. [85] R. Rogers,Debanalizing twitter: The transformation of an object of study, in Proceedings of the 5th Annual ACM Web Science Conference, WebSci ’13, New York, NY, USA, 2013, Association for Computing Machinery, p. 356–365. [86] Ropsten,Ropsten. URL: https://ropsten.etherscan.io/. [87] S. S,Statistical vs rule based machine translation; a case study on indian language perspective, 2017. [88] E. Saravia,Fundamentals of nlp - chapter 1 - tokenization, lemmatization, stemming, and sentence segmentation. URL: https://dair.ai/notebooks/nlp/2020/03/19 /nlp basics tokenization segmentation.html. [89] K. Sharma, S. Seo, C. Meng, S. Rambhatla, and Y. Liu,Covid-19 on social media: Analyzing misinformation in twitter conversations, (2020). [90] Smart,Iniciativa Smart. URL: https://smart-ib.coop/. [91] snscrape,snscrape. URL: https://github.com/JustAnotherArchivist/snscra pe. [92] Solidity,Solidity. URL: https://docs.soliditylang.org/. [93] spaCy,spaCy. URL: https://github.com/explosion/spaCy. [94] Stanza,Stanza. URL: https://github.com/stanfordnlp/stanza. [95] Statistics,Statistics. URL: https://github.com/stanfordnlp/stanza. [96] D. Stojanovski, I. Dimitrovski, and G. Madjarov,Tweetviz: Twitter data visualization, (2014). URL: https://www.csc2.ncsu.edu/faculty/healey/tweet viz/tweet app/. [97] Subprocess,Subprocess. URL: https://docs.python.org/3/library/subproce ss.html. [98] teamgantt,teamgantt. URL: https://app.teamgantt.com/. [99] Textblob,Textblob. URL: https://textblob.readthedocs.io/en/dev/. 137 BIBLIOGRAF´ IA [100] Threading,Threading. URL: https://docs.python.org/3/library/threadin g.html. [101] C. Tim,Plantilla paper dashboard react. URL: https://www.creative-tim.com/ product/paper-dashboard-react. [102] Time,Time. URL: https://docs.python.org/3/library/time.html. [103] TrackMyHashtag,Trackmyhashtag. URL:https://www.trackmyhashtag.com/. [104] M. Trig´ as Gallego,Metodologia scrum, (2012). [105] Twitter,Brand Twitter guidelines. URL: https://about.twitter.com/en/whowe-are/brand-toolkit. [106] , Twitter API (docs). URL: https://developer.twitter.com/en/docs. [107] , Twitter for websites (docs). URL: https://developer.twitter.com/en/doc s/twitter-for-websites. [108] twitter-api v2,twitter-api-v2. URL: https://github.com/plhery/node-twit ter-api-v2. [109] Twitter hashtag #FightFor15,Twitter hashtag #FightFor15. URL: https: //twitter.com/search?q=%23FightFor15&src=typed query. [110] Twitter hashtag #Malpasopagaya,Twitter hashtag #Malpasopagaya. URL: https://twitter.com/hashtag/Malpasopagaya?src=hashtag click. [111] Twitter @jobsmierda,Twitter @jobsmierda. URL: https://twitter.com/jobs mierda?lang=es. [112] M. UI,Material UI. URL: https://mui.com/. [113] H. Ullah, Z. Ullah, S. Maqsood, and A. Hafeez,Web scraper revealing trends of target products and new insights in online shopping websites, International Journal of Advanced Computer Science and Applications, 9 (2018), pp. 427–432. [114] S. Vieweg,Microblogged contributions to the emergency arena: Discovery, interpretation and implications, (2010). [115] Vincent Pasquier, Alex J. Wood,The power of social media as a labour campaigning tool: lessons from our walmart and the fight for 15 — ETUI, the european trade union institute, 2020. [116] Y. Wang, M. McKee, A. Torbica, and D. Stuckler,Systematic literature review on the spread of health-related misinformation on social media, Social Science Medicine, 240 (2019), p. 112552. [117] Web3,Web3. URL: https://web3js.readthedocs.io/en/v1.7.0/. 138 BIBLIOGRAF´ IA [118] Z. West,Stop words: Removing words without meaning. URL: https://www.alph arithms.com/stop-words-lists-removal-195521/. [119] A. Williams,User-centered design, activity-centered design, and goal-directed design: a review of three methods for designing web applications, in Proceedings of the 27th ACM international conference on Design of communication, 2009, pp. 1–8. [120] B. Wireframes,Balsamiq wireframes. URL: https://balsamiq.com/wireframe s/. [121] A. Wood,Networks of injustice and worker mobilisation at walmart, Industrial Relations Journal, 46 (2015). [122] B. Zhao,Web scraping, Encyclopedia of big data, (2017), pp. 1–3. 139