twitterbot: robot de twitter per a la generacio de not´ ´ıcies · twitterbot: robot de twitter...

TFG EN ENGINYERIA INFORMATICA, ESCOLA D’ENGINYERIA (EE), UNIVERSITAT AUTONOMA DE BARCELONA (UAB)

Twitterbot: robot de Twitter per a lageneracio de notıcies

Pau Lopez de Recalde i Sanfeliu

Resum– Des de sempre l’esser huma ha tingut la necessitat de coneixer i comprendre el que suc-ceeix al seu voltant. Primariament es pot veure clarament com un metode de supervivencia al sabercom interactua el nostre entorn i com podem nosaltres anticipar-nos a aquest. Avui en dia es valorano nomes els coneixements adquirits a traves dels estudis, sino el que s’anomena com ‘culturageneral’. Cada cop mes les tecnologies guanyen terreny en els nostres mons. El que abans s’obteniallegint premsa escrita avui ha estat substituıt per premsa digital. Aquest projecte preten crear unportal de notıcies que s’actualitzi automaticament a traves de notıcies obtingudes de la xarxa socialTwitter, evitant un manteniment de notıcies manual. D’aquesta manera no seria imprescindible que hihagues algu treballant com a redactor ni periodista. Aquest portal sera apte per a qualsevol dispositiumodern adaptant el contingut a aquest i permetent a l’usuari registrar-se i interactuar amb el sistema.

Paraules clau– Notıcies, informacio, diari, Twitter, automatitzacio, portal web, responsive,Bootstrap, HTML, PHP, MySQL, intel·ligencia artificial, llenguatge natural, MVC, Internet.

Abstract– Humans have always had the need to know and understand what is happening aroundthem. That point can clearly be seen primarily as a method of survival in how it interacts with ourenvironment and how we can anticipate this. Today is not only valued the knowledge acquiredthrough education, but what is termed as ‘general knowledge’. Increasingly, technologies are gainingground in our worlds. What we previously obtained by reading newspapers today has been replacedby digital media. This project aims to create a news portal that is automatically updated via reliablesources of news (Twitter groups), avoiding manual maintenance. Thus there will be no one workingas an editor or journalist. This site will be suitable for any modern device being responsive to thiscontent and allowing the user to register and interact with the system.

Keywords– News, information, newspaper, Twitter, automatitzation, website, responsive, Bo-otstrap, HTML, PHP, MySQL, artificial intelligence, natural language, MVC, Internet.

F

1 INTRODUCCIO

ACTUALMENT la necessitat d’estar informat del quepassa al nostre voltant s’ha vist incrementada acausa de la crisi. Son moltes les empreses que de-

manen coneixements de cultura general com a filtre de pro-cessos de seleccio. Per a estar informat cal una font fiabled’informacio que estigui actualitzada constantment. Avuien dia el consum de premsa escrita ha baixat molt donadala despesa de diners i de temps per part del lector i de ma-

• E-mail de contacte: [email protected]• Mencio realitzada: Tecnologies de la Informacio• Treball tutoritzat per: Jordi Casas-Roma (Departament d’Enginyeria

de la Informacio i de les Comunicacions)• Curs 2015/16

terial per part de l’empresa. Es per aixo que han sorgit elsportals de notıcies online. Aquests necessiten un manteni-ment i redaccio constant de les notıcies.L’objectiu d’aquest article es de proposar un sistema queens permeti agafar la informacio automaticament de lesnotıcies, facilitant aixı la tasca del periodista o redactor, laclassificacio d’aquesta informacio en les categories gene-rals que te qualsevol diari i de mostrar aquesta informacioen forma de notıcies a l’usuari mitjancant tecnologies queens permetin arribar a qualsevol dispositiu d’avui en dia.

2 OBJECTIUS

L’objectiu del projecte es tenir un sistema independent ifuncional que integri els moduls necessaris per resoldre l’e-nunciat del projecte: tenir un portal web de notıcies actua-litzat automaticament mitjancant la creacio d’un robot que

“Gener” de 2016, Escola d’Enginyeria (UAB)

2 EE/UAB TFG INFORMATICA: TWITTERBOT, ROBOT DE TWITTER PER A LA GENERACIO DE NOTICIES

agafi les notıcies de Twitter i que classifiqui aquestes engrups estandarditzats. Podem dividir aquest enunciat en 4grans subobjectius:

1. Desenvolupament d’un robot o recol·lector que iteripels grups de Twitter establerts extraient la informa-cio en forma de tweets i la emmagatzemi en una basede dades.

2. Elaboracio d’un classificador que s’encarregui de clas-sificar els tweets emmagatzemats a la base de dades.

3. Construccio d’un portal web complert que permeti vi-sionar les notıcies recol·lectades i permeti una custo-mitzacio per part de l’usuari dels grups de notıcies alsquals esta subscrit. Aquest portal haura d’adaptar-se atots els dispositius i pantalles (disseny responsive).

4. Desenvolupament d’una base de dades que contin-gui tota la informacio necessaria, tant dels tweets re-col·lectats historics com dels usuaris i les relacionsusuari-grup subscrites.

L’acompliment d’aquests objectius es fara asseguranten cada etapa un acabat de qualitat que respongui alsestandards de TI actuals. A l’acabar el projecte ha d’estarfuncionant el portal de notıcies (front-end) aixı com el mo-tor de seleccio i classificacio d’informacio (back-end). D’a-questa manera es complira la resolucio del problema inicialamb la qualitat necessaria.

Fig. 1: Esquema dels objectius

3 ESTAT DE L’ART

Avui en dia i arrel de l’expansio de les TI han sorgit unmunt de pagines web de notıcies i de premsa digital. Mol-tes d’aquestes pagines son versions electroniques de premsaescrita ja existent. La majoria de consumidors s’ha passata aquest nou paradigma d’emissio d’informacio principal-ment pel cost reduıt que els suposa, aixı com no haver dedesplacar-se per estar informat. Es profitos tambe per per-sones amb mobilitat reduıda o que no poden sortir de casaper edat avancada, etc. El problema que tenen tots aquestsserveis web es que necessiten de personal que gestioni laseleccio i redaccio de les notıcies. Aixo encareix els costosde ma d’obra doncs es necessita personal qualificat en elmon del periodisme i una cerca constant d’informacio. Esrequereixen sistemes autonoms capacos de facilitar, o fins

i tot substituir, aquest dispendi de temps/diners. Un altreproblema que presenten aquests portals es que l’usuari note poder de personalitzacio de notıcies, aixı com la crea-cio de portades customitzades al gust de cada usuari. Ditd’una altra manera, hi ha una necessitat de tenir un sistemaautomatitzat de recol·leccio de notıcies que respongui a lesnecessitats de cada usuari.Actualment existeixen alguns serveis que permeten simularun sistema de RSS o feed com Twitter Feed[2]. Aquestspero no tenen com a objectiu principal informar mitjancantnotıcies periodıstiques als usuaris.

4 METODOLOGIA

Per tal de dur a terme el desenvolupament del projecte s’haseguit un model iteratiu i incremental on a cada etapa s’handesenvolupat funcions del sistema. D’aquesta manera s’haconstruıt i refinat els diferents moduls a cada iteracio queens han permes provar l’aplicacio com a conjunt.

La planificacio iterativa que s’ha seguit al llarg del pro-jecte es la seguent:

• Fita 1: 15/11/2015. Tenir connexio amb Twitter imetodes de consulta de tweets i de trending-topics(model). Tambe disposar d’una interfıcie elementalweb que ens permeti veure els tweets que hem agafatamb el recol·lector i que hi hagi unes classificacionselementals (esports, polıtica...). En aquesta fita ha dequedar la base de dades construıda (amb camps basics,no caldra disseny complert) i enllacada amb els dife-rents moduls. No cal estil en les pagines, nomes visu-alitzacio de contingut.

• Fita 2: 20/12/2015. Classificador de tweets funcionantamb un nivell de qualitat acceptable. Pagines web ambun estil atractiu i amb les notıcies ben classificades.Base de dades refinada amb els camps necessaris i op-timitzada. Models entitat-relacio elaborats. Sistematreballant correctament com a conjunt i formant unaagrupacio funcional operativa.

• Fita 3: 24/01/2015. Refinament de l’estil de la paginaweb. AJAX aplicat i funcionant. Us de tecnologia Ja-vascript i jQuery. Codi web de qualitat passat per vali-dador HTML5[3] funcionant igual que el CSS3. Clas-sificador de tweets amb el mınim error possible. Basede dades i aplicacio de recol·lector de tweets i classifi-cador muntada externament a un servidor amb dominipublic, a l’igual que el servei web operatiu (AmazonEC).

Per al desenvolupament del projecte hem dividit la nostraaplicacio en 4 moduls principals: el recol·lector de tweets orobot, el classificador de tweets, el portal web i la base dedades. Aquesta darrera es el nexe comu de les altres 3. Elsmoduls no es comuniquen entre sı sino que la informacioesta centralitzada a la base de dades, a excepcio de la gestiodel recol·lector i el classificador, que s’operen fent us d’undashboard des del portal web (comunicacio via sockets en-tre Python i PHP). Aquest punt s’explicara a l’apartat delsistema web.

Tot el desenvolupament utilitzara el paradigma model-vista-controlador per tal d’evitar dependencies i per a tenir

PAU LOPEZ DE RECALDE I SANFELIU: TWITTERBOT, ROBOT DE TWITTER PER A LA GENERACIO DE NOTICIES 3

un projecte de qualitat amb un baix acoblament. El codiseguira un estil de codificacio acurat (altament documentat,maxim 80 caracters per lınia, etc.) i es dedicara una part pera fer test dels diferents moduls.

4.1 Base de dades

Comencem fent la explicacio de la base de dades doncs laseva especificacio ens serveix com a protocol de comuni-cacio. Recordem que la gran majoria d’informacio que espassen els moduls del projecte es emmagatzemada a la basede dades.

La nostra base de dades consta de 4 taules:

• Category. Conte l’identificador i el nom de cada unade les categories que poden tenir els tweets.

• Tweet. Conte tota la informacio de cada tweet. Aques-ta es: identificador propi del tweet de Twitter (clauprimaria de la taula i es un long int), l’idioma en queesta escrit (ens ho dona Twitter), el text del tweet onotıcia, els cops que ha estat retweeteijat, els cops queha estat marcat com a preferit, el dia i la hora de cre-acio i les coordenades (per en lınies futures classificarper zones geografiques). Tots aquests atributs venendirectament dels atributs d’un tweet de Twitter, no s’-ha de calcular res sino fer la peticio REST des de l’APIque hem escollit.

• User. Conte la informacio dels usuaris del nostre por-tal. D’aquests guardem un id (clau primaria i ındex au-toincremental per motor de la base de dades), el nomd’usuari o username, la contrasenya o password, l’e-mail i un camp boolea que indica si es administrador ono. Aquest camp es vital per a multiples comprovaci-ons en apartats d’administracio i es constantment com-provat des del sistema web. Per l’emmagatzematge decontrasenyes s’utilitza un metode segur que s’explicaa l’apartat de seguretat del sistema web mes endavant.

• Twitter user. Tambe anomenat grups de notıcies deTwitter, fa referencia als grups dels quals agafem in-formacio. En guardem el nom i un camp boolea validque ens indica si ha estat moderat per part d’un admi-nistrador.

A l’annex A.1 es pot veure el diagrama entitat-relacio com-plert de la base de dades del projecte. Aquesta base de da-des esta funcionant per un sistema gestor de bases de dadesde MySQL. Les consultes doncs estan desenvolupades en elllenguatge SQL adaptat al gestor.

4.2 Recol·lector de tweets

4.2.1 API REST o Streaming

El primer punt a tenir en compte a l’hora de comencar ambel recol·lector es saber com farem aquesta obtencio delstweets. Twitter ens proporciona dos metodes diferents d’es-tar connectats amb la seva xarxa social[4]: el metode RESTi el metode Streaming. Cadascun d’ells te les seves particu-laritats i sera mes apte en uns casos que en uns altres.

TAULA 1: COMPARATIVA API REST I STREMING

API REST API StreamingRecursos Baix Alt (memoria, CPU i xarxa)Complexitat Baixa Alta (estructures de dades)Comunicacio Discrecional Simultania i permanent

• REST. Es una API que, en essencia, utilitza per acomunicar-se missatges discrecionals. Es a dir, s’en-via una peticio unica i aquesta es resposta per part de laxarxa de Twitter. Un cop s’ha donat resposta a la pre-gunta es tanca la connexio i ambdos nodes extrems s’o-bliden de la comunicacio que passa a ser historica. Elsmissatges son en formats ja establerts en estandards decomunicacions a nivell d’aplicacio, tals com XML omes utilitzat el JSON[5], que agafa el format de mis-satges Javascript per a treballar amb objectes. L’avan-tatge d’aquest metode es el poc consum de memoria ide connexions simultanies que ha de gestionar el siste-ma operatiu del servidor on allotgem la nostra aplica-cio.

• Streaming. Es una API que es mante amb una con-nexio establerta amb Twitter a llarg termini de for-ma que va rebent actualitzacions constants (semblanta un navegador web que rep notificacions i missat-ges). D’aquesta manera te un sistema mes complexde connexions a nivell d’aplicacio i treballa amb con-junts molt grans de connexions HTTP establertes si-multaniament. Es deduıble que consumira mes re-cursos del nostre servidor d’aplicacio final tant enmemoria i CPU com en entrada/sortida de xarxa.

Pel tipus de projecte que ens ocupa la millor opcio pernosaltres es la d’utilitzar la API REST[6], doncs les con-sultes que farem seran discrecionals on emmagatzemaremla informacio al moment de rebre-la. Tambe la complexitates molt inferior i ens permetra dedicar mes temps als altresapartats sense ocupar-nos de funcionalitats innecessaries.Per accedir a la API de REST utilitzarem la llibreria jaexistent de Python anomenada Tweepy[7]. Es una llibreriasenzilla i molt potent que ens permet estalviar molt detemps desenvolupant les funcionalitats necessaries. El seulema es “Una llibreria de Python facil d’utilitzar per aaccedir a la API de Twitter”.

Per la realitzacio del recol·lector o robot de tweets hemcreat les classes Controller, Model, DBConnector i Server.Cadascuna d’elles es un modul independent i necessari pera l’obtencio de tweets. El Controller es la classe principalque s’encarrega de l’obtencio i la pujada de tweets a la basede dades. Per fer-ho utilitza funcions implementades a laclasse Model, DBConnector i Server. A continuacio hi hauna explicacio de les classes:

4.2.2 Classe Controller

Classe principal del recol·lector de tweets. Els seus atri-buts permeten l’emmagatzematge d’una llista de tweets pera esser pujada a la base de dades, una instancia per a laconnexio a la base de dades de la classe BDConnector, unainstancia concurrent de la classe Server i un atribut objec-te de la classe Classifier per a classificar. Tenim tambe els


seguents metodes que ens serveixen per a realitzar les fun-cions principals del classificador:

Fig. 2: Diagrama de classe del Controller

• Constructor init() : inicialitza els atributs del mo-del i classificador amb instancies de les classes Modeli Classifier, aixı com l’atribut “db” amb una instanciade la classe DBConnector. Llanca el thread que s’exe-cutara de manera paral·lela com a servidor del classi-ficador i configura el sistema de logs de l’aplicacio derecol·leccio i classificacio.

• mainLoop(): thread principal d’execucio on cada certtemps (demanat a l’iniciar el recol·lector) es crida arecol·lectar i a classificar.

• serverLoop(): thread que conte el metode principald’escolta del servidor de la classe Server.

• updatetweets(): afegeix a la base de dades els tweetsque hem anat agafant.

• classifytweets(): crida al classificador per a realitzar laclassificacio.

Aquesta classe fa us tambe del Threading de Python, elqual ens permet executar un servidor (classe Server explica-da mes endavant) que ens permet rebre peticions del serveiweb per dur a terme operacions des del portal.

4.2.3 Classe Model

Classe que conte els metodes per a la connexio i obtenciode tweets.

Autenticacio amb OAuth Aquesta classe Model te elsatributs necessaris per a fer l’autenticacio amb OAuth[8](4 cadenes de text: consumer key, consumer secret, accesstoken, acces token secret; un objecte auth i un objecte api).Aquest darrer atribut ‘api’ es el que ens permet la obtenciodels tweets i l’iterador sobre Twitter dins del nostre usua-ri creat. A continuacio es pot veure l’esquema (figura 3)de missatges que comparteix la nostra aplicacio amb Twit-ter mitjancant OAuth. En primer lloc, nosaltres demanema Twitter, com a administradors d’una aplicacio, les claus iels tokens necessaris per a desenvolupar una aplicacio queestara connectada a la xarxa social de Twitter mitjancantla plataforma per a desenvolupadors . Twitter ens demanadoncs que tinguem un usuari creat per a vincular-lo ambla nostra aplicacio. D’aquesta manera, la nostra aplicacio

Fig. 3: Diagrama de sequencia OAuth

tindra els mateixos permisos de consulta i escriptura de twe-ets que un usuari normal de Twitter. Un cop creat l’usuarii vinculat a la nostra aplicacio Twitter ens retorna 4 clausnecessaries per a poder utilitzar una aplicacio estant con-nectats a la xarxa social:

• Consumer key. Identificador del client. Es la clau dela API associada a la aplicacio de Twitter.

• Consumer secret. La contrasenya del client que enspermet autenticar-nos davant del servidor de Twitter.

• Access token. Es sol·licitat al client un cop s’ha auten-ticat. Aquest defineix els privilegis del client.

• Access token secret. Es enviat junt a l’Access tokeni el protegeix d’usos indeguts en cas de coneixerunicament aquest.

Resumidament les dues primeres claus ens serveixen per aautenticar-nos a Twitter i les dues ultimes per a autoritzar-nos a fer us de la API que ens permet operar (es separaautenticacio de autoritzacio).

Estructura Per al tractament senzill des de fora de laclasse hem creat els seguents metodes:

Fig. 4: Diagrama de classe del Model


• Constructor init (): Inicialitza les variables per alOAuth treballant amb la classe OAuthHAndler i lidona a l’atribut ‘api’ el valor resultant de demanar-loamb les dades d’autenticacio.

• getTweetsByName(int name, int number): Ens retornauna llista de Python els “number” tweets de l’usuari‘name’. Exemple getTweetsByName(‘324cat’, 10).

• getTrendingTopics(): Ens retorna una llista de Pythonamb els 10 trending topics.

• flush(): crida al metode flushTweets() de DBConnec-tor. Purga la taula ‘tweet’ de la base de dades. Aquestmetode nomes es pot invocar des del portal web estantlogat com a administrador des del dashboard del re-col·lector. Esta pensat unicament per a buidar base dedades en cas de tests i proves.

• classify(): Crida a classificar a la instancia Classifier.

Com podem veure des de la classe Controller podem invo-car des de molt alt nivell operacions que utilitzen d’altresclasses (disseny per moduls).

4.2.4 DBConnector

Aquesta es la classe encarregada de treballar amb la basede dades externa que uneix els diferents moduls. Ofereixconnexio a aquesta i resolucio d’operacions utilitzades pelsmoduls del classificador (Controller i Model). Per al ma-neig de bases de dades de MySQL des de Python s’ha fetservir la classe nativa que ens ofereix el llenguatge de Pyt-hon: la MySQLdb[9]. La estructura de la nostra classe DB-Connector es la seguent:

Fig. 5: Diagrama de sequencia OAuth

• Constructor init (): inicialitza els atributs als valorspassats per parametre (des de Controller).

• flushTweetTable(): buida la taula de tweets. Metodeutilitzable des de l’interfıcie web.

• Connect(): estableix connexio amb la base de dades.

• addTweets(tweetList): afegeix a la base de dades elstweets de la llista tweetList.

• getUnclassified(): retorna una llista de ids i text ambels tweets no classificats (category = 0).

• changeClassification(classificationList): rep una llistade ‘id, valor’ i actualitza la classificacio del tweet ambaquella id.

• getTwitterUsers(): ens retorna els grups dels quals lle-gim notıcies.

4.2.5 Server

Finalment, per a tenir enllestit el modul del recol·lector ensfa falta que aquest sigui operat, no des d’una lınia de co-mandes, sino des del portal web, que sera la unica entradai sortida dels usuaris (i dels administradors del lloc web).Perque el sistema funcioni aquest ha de poder ser activat idesactivat, aixı com consultar l’estat en el que es troba i elslogs, des de la interfıcie web. Es per aixo que es necessa-ri que en el recol·lector hi hagi corrent constantment unaclasse Server que estigui a la escolta de peticions que arri-bin des del servidor web. Evidentment aquestes peticionsi consultes nomes podran ser executades per usuaris admi-nistradors.L’arquitectura del servidor es forca senzilla. Primerament, isense entrar en la classe en si, tenim el flux principal d’exe-cucio del programa en la classe Controller. Sera necessaridefinir un metode que s’executi concurrentment amb el filprincipal d’execucio del programa.

Threading Hem utilitzat les classes natives de Pythonque ens permeten fer us del threading, concretament la clas-se “Threading”[10].

t = threading.Thread(target = self.serverLoop)t.start()

Codi 1: Creacio d’un thread en Python

La funcio serverLoop() crida al metode loop() del Serverque analitzarem a continuacio:

Fig. 6: Diagrama de classe del Server

Com podem veure aquesta classe te la informacio de laconnexio (tupla de IP/Port on estara escoltant peticions), delsocket de Python[11] que te la connexio oberta i un loggerper a gestionar missatges d’aplicacio. El metode principalde la classe es el loop(), que es veu a continuacio:

while True:data, addr = self.__socket.recvfrom(2)if data:if data == "01":

self.__model.getTweets()


elif data == "02":self.__model.classifyTweets()

elif data == "03":self.__model.flushTweets()

[...]

Codi 2: Bucle del servidor a la escolta

Com es pot comprovar hem creat un protocol propi decomunicacions a nivell d’aplicacio que tracta tots els casospossibles d’enviament (al final hi ha un default que s’exe-cuta en qualsevol altre cas de recepcio de dades). Enviempel socket 2 bytes corresponents al codi d’operacio.D’aquesta manera el Controller principal te aquesta porciode codi sent sempre executada i escoltant les peticions quevinguin del servidor web. Al sistema web tenim un fitxerdoncs que tambe corre un socket de PHP[12] que es el queenvia la informacio. Com a mesura de seguretat a la paginaPHP que gestiona l’enviament de missatges es valida en totmoment que la sessio d’usuari PHP sigui amb un usuari elqual tingui el camp d’administrador a la base de dades coma ‘1’. De totes maneres, de la seguretat i estructura del ser-vidor web se’n parlara mes endavant.

4.3 Classificador de tweetsEl classificador de tweets es el segon modul del Twitterbot.El funcionament d’aquest, a grans trets, es el d’agafar totsels tweets de la base de dades que no estan classificats i unper un comprovar a quina categoria s’adapta mes. Segui-dament agafa aquests tweets i els puja de nou a la base dedades alterant el valor del camp ‘category’. A continua-cio s’expliquen detalladament els passos de l’algorisme declassificacio:

4.3.1 Obtencio de tweets no classificats

Per tal d’obtenir els tweets que no estan classificats simple-ment necessitem agafar el camp ‘id’ i ‘text’ dels tweets queno han estat classificats, es a dir, que el camp ‘category’ es0. No necessitem cap altre camp que no sigui el del text aanalitzar i l’apuntador ID per a poder fer l’update a la basede dades un cop classificat. La consulta SQL es la seguent:

SELECT id, text FROM tweet WHEREcategory = ‘0’;

Codi 3: Consulta de tweets no classificats

D’aquesta manera el metode que s’encarrega d’obtenir elstweets no classificats retorna una llista de Python on els seusvalors son tuples (id, text). Aquesta llista passa al seguentpas de l’algorisme.

4.3.2 Classificacio dels tweets

Un cop tenim la llista de tuples, anem agafant tupla per tu-pla i ens quedem amb la cadena de text del tweet. Per acada categoria en el classificador tenim un conjunt de tagso paraules clau que formen un diccionari. Per exemple depolıtica tenim:

self.__tagsPolitica = ["politica","congres", "president", "cup","pais", "parti", "artur", "sonde","debat"[...]]

Codi 4: Visio de tags del recol·lector

Per a cada tweet mirem de cada llista de tags el nombred’aquests que apareixen. D’aquesta manera fem una classi-ficacio basada en diccionari. El resultat d’aquesta operacioes un numero que ens indica a quina categoria va (1 perpolıtica, 2 per internacional...). En aquest punt creem unanova llista de Python que contindra tuples amb (id, valor),on valor es el numero que identifica la classificacio del twe-et, que seran els camps unicament necessaris per a fer elsupdates a la base de dades.

4.3.3 Actualitzacio de categoria

Finalment l’unic que ens queda fer en l’algorisme de clas-sificacio es actualitzar la base de dades. Igual que a l’inicino fa falta actualitzar tots els camps, unicament necessiteml’apuntador que es l’ID del tweet i el nou valor del regis-tre ‘category’. A continuacio tenim la consulta SQL queexecutem per cada un dels camps de la llista anteriormentanomenada.

UPDATE tweet SET category = \%sWHERE id = \%s;""" \%(classification[1],classification[0]));

Codi 5: Actualitzacio de categoria

4.4 Portal web

4.4.1 Requisits del sistema web

Per a entendre el que sistema web avarca s’ha de complir elseguent enunciat: es necessita un portal web que mostri lainformacio en forma de tweets als usuaris. Haura de teniruna pagina home on es mostrin les ultimes notıcies dels di-ferents apartats o categories (polıtica, tecnologia...). Tambesera possible consultar cada un dels apartats diferents, de talmanera que puguem veure unicament els tweets d’una cate-goria concreta, com per exemple els de polıtica. El portalweb ha de tenir, a mes, una seccio anomenada “Els mes”quecontindra un ranquing per a les notıcies o tweets mes retwe-eteijats o que mes han donat de parlar i un ranquing per alspreferits o que mes han agradat. Aquests es podran veuretant per ranquing diari, com per mensual i com per vitali-ci (des de l’inici del portal). Per tal de mostrar o no certsgrups de notıcies a l’usuari, aquest tindra un sistema de re-gistre i login que permetra als usuaris estar registrats al sis-tema i coneixer les seves preferencies, aixı com introduirnous grups de notıcies al recol·lector. De cada usuari se’nguardara username, el correu electronic, l’identificador unicque sera autoincremental i la contrasenya que triı. Aquestahaura d’estar emmagatzemada de manera segura a la ba-se de dades. Els grups de notıcies hauran de ser validatsper un usuari administrador a posteriori per tal de passara formar part de manera permanent. Tal com s’ha comen-tat hi haura distincio entre dos tipus d’usuari: usuari lectoro estandard i usuari administrador. L’usuari administradorpot fer el mateix que l’usuari estandard pero a mes a meste acces a un menu d’administrador que li permet executartasques avancades. Aquestes son:


• Gestio de les fonts d’informacio. Permet afegir i treuregrups d’informacio aixı com moderar grups afegits perusuaris estandards que encara no han estat validats.

• Gestio dels usuaris. Permet editar la informacio em-magatzemada de cada usuari (contrassenya en cas deperdua i email) aixı com eliminar l’usuari o fer-lo ad-ministrador.

• Gestio del recol·lector. Aquest es podra iniciar i parar,aixı com el classificador. Es podran llencar individual-ment les ordres de recol·lectar, de classificar pendents,de reclassificar tots ele tweets (util per si canviem dic-cionaris) i de purgar o eliminar per complet la taula detweets. Es el dashboard del sistema web.

Finalment hi haura una area privada per a cada usuari,tant si es administrador o usuari estandard que li permetraaccedir a la seva portada personalitzada i a la configuraciod’aquesta.

Fig. 7: Visio de menu estandard

Fig. 8: Visio de menu d’administrador

Per tal de mostrar la informacio als usuaris finals, aixıcom per controlar el recol·lector i el classificador s’hadesenvolupat el portal web amb la seva interfıcie propia.Aquest portal es totalment responsive i s’adapta a tots elsdispositius i pantalles. Per a fer-ho hem utilitzat el fra-mework de desenvolupament de Bootstrap en la versio mesrecent, la 3.0[13].

4.4.2 Bootstrap 3.0

Ha estat el nostre ‘dissenyador grafic’ del portal web. Toti que inicialment es va fer un disseny grafic desenvolupattotalment de manera propia, aquest va ser rapidament subs-tituıt al veure que no era responsive i no s’adaptava ni a unamateixa pantalla canviant l’ample d’aquesta. Aquest can-vi va suposar un fort contratemps tot i que al donar-se a laultima iteracio no s’ha anat arrossegant al llarg del desenvo-lupament del projecte. La part positiva era que el back-enden PHP s’ha pogut reaprofitar completament i que Boots-trap ens permet fer el disseny dels components, tals combotons i menus en un temps molt menor i amb uns resultatsmolt mes professionals. A continuacio es pot veure la di-ferencia entre el disseny inicial sense Bootstrap i el dissenyfinal.

Fig. 9: Portal sense us de Bootstrap

Fig. 10: Portal amb us de Bootstrap 3.0

4.4.3 Estructura de fitxers

Per tal d’entendre les seccions que te el nostre portal webhem de coneixer l’estructura de fitxers que soste el nostreservidor, que ens serveix per entendre com esta estructura-da la informacio. A l’annex 3 hi ha un esquema grafic del’estructura de fitxers. L’arrel del servidor conte els fitxersamb les pagines que es mostren a l’usuari i 3 directoris, quees detallen a continuacio:

• bootstrap-3.3.6-dist. El directori bootstrap-3.3.6-distes on hi ha allotjat el framework de disseny grafic d’a-plicacions web responsive. Conte documents CSS, JS(Javascript) i fonts tant de lletres com de sımbols. Totsels icones i imatges grafiques que es mostres a la in-terfıcie actual del projecte son sımbols del framework.Aixo ens aporta una qualitat superior al ser adaptablesa qualsevol dispositiu mantenint una interfıcie profes-sional al ser unicament amb estil del Bootstrap i nodissenys externs.

• Include. Conte els fitxers que son inclosos com a partsen les pagines principals del portal mitjancant el codiPHP:

<?phpinclude ’include/xxx.php’;

?>

Codi 6: Inclusio de codis en PHP

Aquestes pagines son les de la capcalera del portal, lesquals inclou el menu fixe principal superior del por-tal, el peu de pagina amb la informacio resumida del


portal, un script de connexio a la base de dades ques’utilitza constantment i un parell de taules usades endos apartats del lloc web (taula de resultats dels tweetsmes votats i taula d’usuaris per a fer la cerca des delmenu d’administrador).

• Operations. Conte les pagines que en sı no mostrencontingut, sino que operen amb la base de dades i/ofan comprovacions. Inclou afegir i eliminar grups denotıcies, fer el logout del sistema, moderar grups denotıcies no validats, modificar relacions entre usuarisdel portal i grups de notıcies, modificar usuaris i operaramb el recol·lector des de la interfıcie web.

4.4.4 Qualitat de pagines

Per tal d’assegurar una qualitat superior al nostre projecteweb, aquest ha estat desenvolupat seguint les regles de sin-taxi estrictes que estableix la W3C. Totes les pagines inter-pretables per navegadors web del projecte han estat desen-volupades i posteriorment refinades perque hi hagi 0 errorssegons el validador oficial de HTML5, pel que ens assegu-ren un optim rendiment en tots els dispositius que suportinaquest llenguatge.Tot el codi ha estat identat correctament i amb espais encomptes de tabuladors perque el codi es vegi de la matei-xa manera independentment de l’editor de text o navegadoramb la funcio d’inspeccionar elements que utilitzem.

4.4.5 Seguretat web

Com a mesures de seguretat hem implementat diversosmoduls que ens ajuden contra atacs d’impersonacio i pera millorar l’autenticacio de l’usuari aixı com evitar atacs deman-in-the-middle.

Proteccio de contrasenyes Un dels problemes que es vaobservar rapidament era que quan administravem la base dedades, si ens situavem a sobre de la taula ‘user’ que contetota la informacio dels usuaris podıem veure en clar la sevacontrasenya. A part d’una dubtosa legalitat, el fet de te-nir aquestes contrasenyes te una responsabilitat molt gran,doncs els usuaris poden estar utilitzant les mateixes que end’altres comptes de xarxes socials i en cas que un dia fossimvıctimes d’un atac de forca major i sortissin aquestes con-trasenyes seriem nosaltres els responsables legals. De to-tes maneres hem desenvolupat la solucio per simples raonsetiques. Aquesta passa per a guardar les contrasenyes xifra-des de tal manera que no estiguin en clar. Seguint l’esque-ma de seguretat que usa Linux en el fitxer ‘shadow’, s’haaplicat la millor solucio que consisteix en fer un resum deles passwords. D’aquesta manera ni amb un atac de forcabruta podrıem trobar una clau que desxifres totes les contra-senyes. L’algorisme que hem utilitzat es el de SHA-1[14],que tot i comencar a ser substituıt per les variants de SHA-2,segueix sent un estandard en quan a metodologia de resumo hash.S’apliquen les funcions hash en dos casos, en quan ens re-gistrem a l’aplicacio web i en quan fem el login. Un exem-ple de quan fem el login com treballa amb aquesta informa-cio el back-end de PHP es el seguent:

\$sql = SELECT username [...]

WHERE [...] and password =hash(’sha1’, \$_POST[’password’]);

Codi 7: Us d’algorime de hash

Com podem veure a l’ultima lınia mirem que el passwordque ens passa l’usuari coincideixi amb el valor del hash enSHA-1 d’aquest amb el valor de la base de dades. D’igualmanera ho fem amb el registre d’usuaris, on inserim un re-gistre on el password es el SHA-1 del que rebem de l’usuari.

Fig. 11: Vista de les contrasenyes des de BD

Proteccio de connexio La proteccio anterior ens propor-ciona seguretat en l’emmagatzematge, pero de res ens ser-veix si la nostra comunicacio no esta xifrada, doncs el calculdel SHA-1 es fa al servidor i no a l’origen, de tal maneraque esta viatjant per la xarxa en clar d’un extrem a l’altre.Per protegir la comunicacio nomes cal fer us del protocolSSL[15] sobre HTTP, el HTTPS. Hem creat doncs un pa-rell de certificats, un que ens serveixi com a autoritat arrelde confianca propi i un per al lloc web en concret. D’a-questa manera si canviem el nom de domini o volem fer uncertificat nou no haurem de confiar en cada un d’ells sinoque ja seran de confianca pels navegadors.

Fig. 12: Visio del certificat de confianca

Com es pot veure s’ha creat un domini gratuıt anomenat”notwicies.tk”[16], necessari per a que els usuaris no ha-gin de coneixer l’adreca IP i per a que el certificat tinguesun Common Name, camp necessari per a funcionar ambpagines web i que requereix un nom de domini. El servidoron s’allotja es una instancia de Amazon Elastic Cloud que


cubreix perfectament les necessitats del nostre portal. Po-dem apreciar que utilitzem un algorisme de xifrat moderni la connexio es segura perque acceptem el certificat arrelpropi autosignat de Pau NET CA.

Control d’acces a pagines d’administracio Un atacclassic es el d’esbrinar quins fitxers del servidor porten apagines d’administracio per tal d’accedir i modificar elsparametres que es desitgi. Aixo pot ser altament destruc-tiu si es duu a terme per usuaris que no tenen ni han de tenirel rang d’administrador.Per a solucionar-ho s’ha afegit, a cada una de les paginesque es requereixen privilegis d’administracio un codi quemira si l’usuari que hi ha logat en aquell moment, si n’hiha, sigui administrador. El pseudocodi que ho implementaseria el seguent:

si(existeix sessio d’usuari) {si(sessio.usuari.admin == 1) {// si usuari logat a web es admin

err = fals;} sino {

err = cert;}

}si(!(err))

mostrar_contingut_pagina();sino

mostrat_error();}

Codi 8: Pseudocodi de seguretat

5 RESULTATS

Com a resultats del projecte tenim un sistema autonom go-vernat unicament des d’una interfıcie web que ens permetdur a terme els tres objectius principals: recol·lectar tweets,classificar-los i mostrar-los mitjancant una interfıcie web. Acontinuacio s’exposen les diferents vistes de l’aplicacio.

Fig. 13: Visio en dispositiu mobil responsive

Podem veure a la figura 13 l’adaptacio responsive que esfa al visualitzar-ho en un dispositiu mobil o de baixa resolu-cio horitzontal. Com es pot observar les notıcies es mostrend’una en una i el menu principal superior es veu recollitamb un boto que genera un desplegable on es pot veure lesopcions verticalment.

Podem veure tambe l’estil que ens aporta l’us de Boots-trap en quan a creacio de pop-ups desplegables dins d’unamateixa pagina, el que ens permeten fer operacions comun login de manera senzilla i sense haver de desenvoluparAJAX[1] per nosaltres mateixos (figura 14).

Fig. 14: Visio de desplegable login

Per tal d’evitar que l’usuari administrador hagi de tocarde codi s’ha implementat tal com s’ha comentat a l’apartatde metodologia un menu d’administrador. A la figura 15hi ha el dashboard on podem seleccionar les operacions arealitzar amb el recol·lector des de la interfıcie.

Fig. 15: Visio del dashboard d’administrador

6 CONCLUSIONS

Podem concloure dient que els resultats del projecte son elsque s’esperaven inicialment. S’ha complet la planificacio ien cada un dels terminis s’ha superat el llindar. El fet que enla primera entrega s’hagues avancat mes del que estava pre-vist ens ha permet a l’ultima iteracio migrar tot el dissenyweb creat a Bootstrap 3.0.

• S’han complert els requeriments funcionals tals comrecol·lectar tweets (100% completat), classificacio detweets (70-80% doncs es podria haver utilitzat un al-tre metode d’intel·ligencia artificial mes avancat enca-ra que no fos de la mencio) i el portal web esta com-pletament funcional i desenvolupat (100% completati ampliat) amb un paradigma de desenvolpament que


ens permet adaptar-se a tot tipus de dispositius. Tenimdoncs seguint amb els objectius del treball un sistemaautonom funcional que s’encarrega de mostrar notıciesclassificades a un portal web.

• En quan a la qualitat del programari que estava com arequeriment no funcional tambe s’ha complert les ex-pectatives: el codi esta altament comentat, l’estil decodificacio es correcte (maxim 80 lınies), alta cohesioi baix acoblament en el desenvolupament de les clas-ses. Utilitzem un sistema de logs que ens ofereixen elsllenguatges Python com PHP per a tenir un historic deles operacions dels usuaris i del sistema de recol·leccioper a millorar la seguretat del sistema i controlar qual-sevol excepcio.

A continuacio s’exposen les lınies futures de desenvolupa-ment que complementen la feina feta i que no s’han pogutdesenvolupar donat l’estret marge de temps del que es dis-posava. El compliment d’aquestes donaria un acabat ambmolta professionalitat que podria donar lloc a un portal d’in-formacio amb exit en el mon de la informacio.

7 L INIES FUTURES DE DESENVOLUPAMENT

Per tal d’ampliar el projecte i donar-li una qualitat superi-or hi ha un conjunt de moduls que caldria implementar orefinar. A continuacio exposo els que ampliaria per ordre:

• Personalitzacio del disseny web. Tot i que la interfıcieweb esta dotada d’una qualitat correcta al haver estatdesenvolupada al 100% amb el framework de Boots-trap, aquesta manca de personalitzacio per part del pro-jecte Twitterbot. Seria bo afegir-li elements decoratiustal com imatges o colors que el distingissin dels demesportals i donant-li personalitat a la vegada que seguıssent responsive.

• Millora de l’algorisme de classificacio. Tal com s’-ha comentat a l’apartat del classificador, hi ha d’altresmetodes que estan mes a dins del que seria el camp dela intel·ligencia artificial. El metode que hem utilitzatnosaltres del diccionari esta be, pero el sistema no escapac de dur a terme un autoaprenentatge i d’acabarsent autonom en quan a la classificacio.

• Gestio dels idiomes dels tweets i de traduccio imme-diata. A l’area geografica on ens trobem tenim un casclar de bilinguisme. Els tweets es podrien guardar a labase de dades en l’idioma que s’han extret i el campsde la base de dades de ‘idioma’ de la taula ‘tweet’guardar quin es l’idioma. Es podria fer us d’un delsmultiples serveis web que se’ns ofereixen gratuıts pera la traduccio de tweets, de tal manera que un usuari es-tablıs l’idioma en que vol visualitzar tota la interfıcieen cas que volgues un de concret i que la informacioes mostres unicament en aquest idioma. Aixo seria utiltant en comunitats autonomes on no es parli en catalacom en paısos anglosaxons on no es parli ni el catala niel castella. Aquest atribut li donaria un caracter d’in-ternacionalitzacio elevat al nostre projecte.

• Sistema de valoracio de classificacio per part d’usu-aris. Per tal d’alimentar un sistema de Machine Le-arning seria bo crear un sistema de puntuacio per tal

que els usuaris registrats al portal poguessin informarrapidament si un tweet no ha estat ben classificat. D’a-questa manera el modul de classificacio s’alimentariade les valoracions dels usuaris i seria capac d’aprendrei millorar la classificacio. Mica en mica el sistema acu-mularia un nombre d’errors inferior fins al punt de quequasi no tingues errors. Per tal de motivar als usuarispodria haver una puntuacio personal que anes augmen-tant cada cop que es corregeix una classificacio i queels usuaris competissin per tal d’escalar el ranquing iobtenir beneficis i descomptes en diferents serveis.

• Definir mes granularitat entre usuaris del portal web.Actualment nomes hi ha usuaris lectors i administra-dors. Seria convenient tenir usuaris que puguin edi-tar notıcies i grups d’informacio sense arribar a tenirprivilegis d’administracio del sistema web complert.D’aquesta manera tindrıem col·laboradors que li trau-rien feina a l’administrador del sistema doncs podrienvalidar grups de notıcies i gestionar errors en aquests.

AGRAIMENTS

M’agradaria agrair al meu tutor del projecte, Jordi Casas-Roma, pels consells i guiatge al llarg del proces, a la mevafamılia per donar-me suport durant el desenvolupament i alsmeus companys de sortides per entendre que no he pogutestar amb ells tant com voldria.

REFERENCIES

[1] http://www.w3schools.com/ajax/default.asp

[2] http://twitterfeed.com

[3] https://validator.w3.org

[4] https://www.quora.com/What-is-the-difference-between-Rest-API-vs-Streaming-API

[5] http://www.w3schools.com/json/json syntax.asp

[6] https://dev.twitter.com/rest/reference/get/search/tweets

[7] http://docs.tweepy.org/en/latest/api.html

[8] https://dev.twitter.com/oauth

[9] http://mysql-python.sourceforge.net/MySQLdb.html

[10] https://docs.python.org/2/library/threading.html

[11] https://docs.python.org/2/library/socket.html

[12] http://php.net/manual/es/book.sockets.php

[13] http://www.w3schools.com/bootstrap/

[14] http://php.net/manual/es/function.sha1.php

[15] https://www.nanotutoriales.com/como-crear-un-certificado-ssl-de-firma-propia-con-openssl-y-apache-http-server

[16] http://www.dot.tk/es/index.html

[17] https://docs.python.org/2/tutorial/errors.html

[18] http://getbootstrap.com/components/


APENDIX

A.1 Base de dades ERA continuacio podem veure el diagrama entitat-relacio dela base de dades que integra els 3 moduls i la comunicacioentre ells.

Fig. 16: Diagrama ER de la base de dades


A.2 Visio del ındex del portal webAquı podem observar la vista en gran de la pagina principaldel nostre portal web.

Fig. 17: Diagrama ER de la base de dades


A.3 Directori de fitxers del servidorAquesta es la estructura de fitxers que composa el sistemaweb del projecte i que esta pujada al servidor.

Fig. 18: Directori del servidor del portal web

twitterbot: robot de twitter per a la generacio de not´ ´ıcies · twitterbot: robot de twitter...

Documents