Lucrare de finalizare a studiilor a studentului: Coco ș Laurențiu Florin [610309]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT ZI

Proiect de diplomă

COORDONATOR ȘTIINȚIFIC :
PROF. DR. ING. ZMARANDA DOINA

ABSOLVENT: [anonimizat]
2017

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI
DEPARTAMENTUL DE CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI

TEMA _____________

Lucrare de finalizare a studiilor a student: [anonimizat]: Coco ș Laurențiu Florin
1). Tema lucrării de finalizare a studiilor: Aplicație software pentru automatizarea
procesului de marketing online
2). Ter menul pentru predarea lucrării: iulie 2017
3). Elemente inițiale pentru elaborarea lucrării de finalizare a studiilor: Symfony , PHP,
HTML și C SS, utilizare tehnologii Bootstrap, Font Awesome și MySQL.
4). Conținutul lucrării de finalizare a studiilor: Introducere; Arhitectura aplicației – Tipare
de programare, Teorie și implementare la nivel de Symfony, Arhitectura nucleului Symfony;
Principii ale automatizării – Ghid pentru automatizare, Resursele necesare pentru un robot
virtual realizat în Symfony; Aplicația Marketilio – Scopul aplicației, Arhitectura aplicației,
Elemente de design și interfață, Implementarea aplicației – Viziune de ansamblu, Structura
bazei de date, Implementarea robotului, Integrarea robotului, Administrarea aplicației,
Utilizarea aplicației; Concluzii; Bib liografie .
5). Material grafic: Imagini, capturi de ecran
6). Locul de documentare pentru elaborarea lucrării: Internet, biblioteca universității
7). Data emiterii temei : octombrie 2016

Coordonator științific
PROF. DR. ING. ZMARANDA DOINA

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT ZI

Aplicație software pentru
automatizarea procesului de
marketing online

COORDONATOR ȘTIINȚIFIC :
PROF. DR. ING. ZMARANDA DOINA

ABSOLVENT: [anonimizat]
2017

Cuprins
Capitolul I. Introducere ………………………….. ………………………….. ………………………….. ……….. 1
Capitolul II. Arhitectura aplicațiilor Symfony ………………………….. ………………………….. …… 3
II.1. Tipare de programare ………………………….. ………………………….. ………………………….. .. 3
II.2. Teorie și implementare la nivel de Symfony ………………………….. ………………………… 5
II.3. Arhitectura nucleului Symfony ………………………….. ………………………….. ………………. 9
Capitolul III. Principii ale automatizării ………………………….. ………………………….. ………….. 12
III.1. Ghid pentru automatizare ………………………….. ………………………….. …………………… 13
III.2. Resursele necesare pentru un robot virtual realizat în Symfony ……………………. 14
Capitolul IV. Aplicația Marketilio ………………………….. ………………………….. …………………… 17
IV.1. Scopul aplicației ………………………….. ………………………….. ………………………….. ……… 17
IV.2. Arhitectura aplicației ………………………….. ………………………….. ………………………….. 17
IV.3. Elemente de design și interfață ………………………….. ………………………….. ……………. 21
IV.4. Implementarea aplicației ………………………….. ………………………….. …………………….. 24
IV.4.1. Viziune de ansamblu ………………………….. ………………………….. …………………….. 24
IV.4.2. Structura bazei de date ………………………….. ………………………….. …………………. 29
IV.4.3. Implementarea robotului ………………………….. ………………………….. ……………… 31
IV.4.4. Integrarea robotului ………………………….. ………………………….. …………………….. 32
IV.4.5. Administrarea aplicației ………………………….. ………………………….. ……………….. 33
IV.4.6. Utilizarea aplicației ………………………….. ………………………….. ………………………. 36
Capitolul V. Concluzii ………………………….. ………………………….. ………………………….. ………… 41
Bibliografie ………………………….. ………………………….. ………………………….. ………………………… 43
Anexa 1. Cod sur să ………………………….. ………………………….. ………………………….. …………. 44
Anexa 2. Baza de date ………………………….. ………………………….. ………………………….. …….. 50

1
Capitolul I. Introducere
Marketilio este o aplicație web destinată automatizării sarcinilor de marketing online.
În cadrul acestei lucrări s -a abordat automatizarea unor acțiuni pe care le realizează un
marketer în cadrul platformei Google Plus, acțiuni realizate manual în absența acestei
aplicații.
Sunt patru componente importante ale acestei aplicații. Prima componentă este robotul
care realizează sarcini automate pe baza configurațiilor date de utiliz ator în interfață. A doua
componentă o reprezintă bazele de date unde se stochează configurații și date culese prin
intermediul robotului, dar și date despre utilizatori și alte concepte din aplicație. A treia
componentă este arhitectura Symfony care este un set de practici bune utile aplicațiilor web și
componente scrise în PHP de asemenea cu sprijin pentru dezvoltare rapidă. În cele din urmă,
a patra componentă este interfața, care are o zonă securizată pentru administrator, dar și una
pentru utilizatori obișnuiți, ambele zone având scopul configurării și vizualizării datelor din
aplicație.
Motivația alegerii temei
Analizând piața de unelte pentru rețeaua socială Google Plus am conștientizat că nu
există foarte multe unelte pentru această rețea socială. As ta deoarece Google Plus nu are un
serviciu API (Interfață de Programare a Aplicației) care să -ți permită foarte multe lucruri, în
plus sunt foarte multe restricții datorită modelului de afacere a companiei Google. Spre
exemplu, acest API nu permite nimic l egat de distribuire a informației, platforma oferind doar
câteva posibilități de culegere a informației legate de profilele utilizatorilor, comunități și
anumite colecții de date.
Astfel că principalul motiv pentru care am ales această temă a fost provocarea de a
lucra cu roboți virtuali și de realiza ceva la care nu s -a mai gândit cineva (cel puțin din câte
am investigat eu pe piață).
Un motiv secundar este acela că la un moment d at în cariera mea am avut de -a face cu
marketingul unor afaceri și era un proces foarte lent în ceea ce privește livrarea informației

2
(mai mult manual și destinat foarte mult erorii). Astfel că am dorit să realizez o unealtă menită
a ușura munca marketer -ilor în ceea ce privește livrarea mesajului.

3
Capitolul I I. Arhitectura aplicațiilor Symfony
II.1. Tipare de programare
Dezvoltarea de produse software este dificilă. Cu toate că introducerea programării
orientate pe obiect a însemnat un progres major în evoluția software, există încă foarte multe
dificultăți în a scrie programe de calitate ridicată. Un program care este de o calitate ridicată
trebuie să fie compus dintr -o logică bine structurată, organizat pe module și are nevoie de
principii solide care stau la baza scrierii programului. Un astfel de program este ușor de
actualizat și menținut pe termen lung. În sprijinul acestor deziderate sunt folosite tiparele de
programare.
Christopher Alexander, părintele tiparelor generale ce pot apărea în mai multe domenii,
spunea: „ Each pattern describes a problem which occurs over and over again in our
environment, and then describ es the core of the solution to that problem, in such a way that
you can use this solution a million times over, without ever doing it the same way twice ” [1].
Un tipar este deci un cuplu format din problema care se repetă și soluția la aceasta.
Un tipar de programare este un tipar care este folosit în furnizarea unor soluții solide la
cele mai întâlnite probleme din cadrul construcției programelor de calculator. Acesta este
compus din [2]:
1. Numele tiparului – este un identificator care descrie o problemă, s oluția dar și
consecințele acestora, în cât mai puține cuvinte.
2. Problema – descrie când să aplici tiparul. Explică problema și contextul acestuia.
3. Soluția – descrie elementele care compun tiparul, relațiile între acestea, dar și felul
în care acestea conlucrează. Soluția nu este una concretă. Se oferă mai degrabă un
mijloc prin care să se înțeleagă cum trebuie gândită aceasta de la caz la caz.
4. Consecințele – reprezintă avantajele și dezavantajele aplicării tiparului. Acestea
sunt critice deoarece pe ba za lor se poate decide dacă tiparul este unul benefic
pentru contextul dat.
Există foarte multe tipare de programare, dar în cadrul acestui subcapitol se vor trece în
revistă doar acelea care sunt folosite în cadrul arhitecturii Symfony.
Așadar iată tipare le de programare folosite în arthitectura Symfony:

4
Tiparul cerere – răspuns [3]
Acest tipar este similar protocolului HTTP (Protocol de Transfer Hipertext). O prezentare
succintă a acestui protocol arată ca în f igura II.1.

Figura II.1 – Readaptare după figura de la [4]
Tiparul consistă din două modelări (de obicei obiecte) asupra cărora se rețin toate detaliile
de comunicare, iar legătura între cerere și răspuns este realizată într -un strat superior acestor
două modelări (care vede detaliile de proiectar e a cererii și răspunsului cu maximă precizie).
Tiparul MVC (Model Vedere Controlor)
Tiparul MVC este folosit pentru a construi interfețe utilizator și are trei obiecte care
comunică între ele. Modelul este obiectul care permite comunicarea cu datele apl icației (baze
de date, fișiere). Vederea este obiectul care permite prezentarea datelor. Controlorul este cel
care asigură comunicarea între vedere și model, dar este responsabil și pentru felul în care
interfața reacționează la intervențiile utilizatorulu i [2].
Tiparul Mediator
Definește un obiect care încapsulează cum un set de alte obiecte interacționează. Acest
tipar promovează detașarea, nelăsând ca un obiect să fie referit de un alt obiect în mod explicit
[2].

5
Tiparul Injectare de Dependențe (Dependency Injection)
Acest tipar presupune un obiect care ține toate detaliile legate de dependențele altor
obiecte. Se folosește mult la decuplarea unei aplicații pe module, fapt ce sprijină
modularizarea unui proiect.
Tiparul Fabrică (Factory)
Oferă o modalitate de a crea familii de obiecte care sunt în relație sau sunt
interdependente, fără a specifica planul de construcție a acestor obiecte.
Tipul Controlor Frontal (Front Controller)
Este mai mult o metodă decât tipar, deși este clasificat ca tipar î n mai multe referințe
bibliografice. Presupune preluarea tututor cererilor unei aplicații web și delegarea către alte
mecanisme în vederea formulării răspunsului.
II.2. Teorie și implementare la nivel de Symfony
În cadrul acestei lucrări s -a folosit arhite ctura Symfony versiunea 3. Există mari diferențe
între această versiune și versiunea 1, dar în schimb foarte multe similarități cu versiunea 2 (cu
foarte puține diferențe). Voi detalia în continuare arhitectura versiunii 3.
Prin arhitectura Symfony se înțe lege baza de cod (organizată în module), care vine
împreună cu anumite standarde de a scrie cod și practici des întâlnite în cadrul comunității
dezvoltatorilor PHP.
Arhitectura Symfony 3 are următoarele caracteristici:
 Performanță ridicată. Toate modulele din Symfony sunt gândite pe cât posibil cu
multă atenție, iar factorul performanță este foarte important. Pentru a testa această
performanță Symfony prezintă o unealtă de depanare în care se poate vedea toată
evoluția cererii în milisecunde.
 Orice cod nou scris în Symfony este organizat într -un modul (bundle) și poate fi
decuplat de restul aplicației folosind implementări ale două tipare descrise în capitolul

6
II.1: Injectarea de dependențe și mediator. Decuplarea nu este tot timpul utilă,
pretându -se doar atunci când s -a scris un modul ce poate fi reutilizat.
 Configurarea este extrem de facilă și permite patru formate standard: PHP, XML,
YAML și anotații (adică direct în cod acolo unde este necesar). Există posibilitate de a
configura ceva pentru a fi folos it de toate modulele aplicației, dar și separat pentru
fiecare modul.
 Structura de directoare este ușor de amintit deoarece folosește un model care amintește
mult de sistemul de fișiere din sistemul de operare Linux. Iată așa arată structura de
directoare a arhitecturii Symfony:
app/ – aici rezidă toate materialele legate de configurarea aplicației, traduceri și
șabloane ale vederilor (V din tiparul MVC explicat în capitolul II.1)
bin/ – conține principalele componente legate de fișiere executabile (acest l ucru este
exact la fel și în Linux)
src/ – conține codul proiectului PHP
tests/ – aici sunt stocate toate lucrurile ce țin de teste automate (Teste pe unități sau
Unit Testing și alte modalități de testare automată)
var/ – exact ca și în Linux acest direct or conține fișiere variabile, care se schimbă de
la o stare la alta a aplicației.
vendor/ – dependențe ale unor terțe părți (third party). Este vorba despre toate
modulele care constituie baza de cod spre a construi o aplicație web deasupra acesteia.
web/ – acesta este directorul web public unde sunt stocate toate resursele statice ale
aplicației (imagini, foi de stiluri, scripturi de javascript) dar și locul în care rezidă
implementarea propriu zisă a controlorului frontal (tipar explicat în capitolul II.1).
 Există niște clase speciale numite servicii care sunt atașate containerului aplicației
(este un obiect central care se ocupă cu delegarea celor mai importante sarcini) și care
pot fi folosite din nou la decuplare și organizare.
 O modalitate extraordina ră de a interacționa cu arhitectura Symfony este prin abonarea
la evenimente. Toată arhitectura este construită în jurul acestui concept și se bazează
pe componenta EventDispatcher care implementează tiparul Mediator discutat în
capitolul II.1.
 La un punct anterior spuneam că directorul vendor/ conține modulele arhitecturii
Symfony. Pentru a ține evidența versiunilor acestor module și a dependențelor acestor
module, Symfony folosește Composer care este managerul standard de module PHP.

7
Ideea acestui manager este simplă: într -un fișier cu format JSON composer.json se
specifică un modul pe care dorești să -l folosești în arhitectura ta și pe urmă rulezi
comanda composer install din terminal. Desigur există o modalitate și mai simplă de a
adăuga acel modul și es te vorba de composer require nume_modul:versiune.
Exemplu: Symfony folosește implicit un ORM (Obiect de Mapare Relațional) numit
doctrine . În versiunea Symfony 3 modalitatea prin care se specifică acest ORM este
folosind modulele "doctrine/orm" : "^2.5", "doctrine/doctrine -bundle": "^1.6",
"doctrine/doctrine -cache-bundle": "^1.2". Dacă se dorește folosirea unui alt ORM
atunci se menționează în composer pachetele acestuia. Spre exemplu, un alt ORM
popular care poate fi utilizat în cadrul Symfony este Propel , iar pentru includerea lui ar
trebui folosit modulul "propel/propel ": "^2.0" . Acestea sunt singurele ORM -uri cu
suport din partea comunității care sprijină arhitectura Symfony. Orice alt ORM ar
necesita să fie adaptat pentru aplicația bazată pe arhitectura Symfony.
 Arhitectura Symfony implementează cu succes tiparul Controlor Frontal (prezentat în
capitolul II.1). Ca urmare a acestui fapt există conceptul de mediu (environment).
Acest mediu poate fi producție, sau dezvoltare implicit, dar se pot configura și alte
medii necesare unei aplicații (un alt mediu util ar fi staging sau punere pe scenă). Prin
mediul producție se înțelege desfășurarea aplicației daca ar fi publicată online, iar prin
mediul dezvoltare se înțelege desfășurarea aplicației în curs de dezvoltare. Cele doua
medii implicite au o diferență semnificativă de câteva zeci de milisecunde în ceea ce
privește execuția unei cereri web, deoarece mediul de dezvoltare are automat și o
unealtă de depanare menită a facilita înțelegerea dezvolta torului cu privire la parcursul
cererii web.
Exemplu de structurare a unei aplicații bazată pe arhitectura Symfony 3
În primul rând aplicația trebuie configurată. În acest scop se editează fișierele
app/config/parameters.yml și app/config/parameters_dev.ym l (aici se pun toate lucrurile care
diferă față de mediul producție). În figura II.2 se poate vedea un model de astfel de
configurare cu explicațiile aferente tot în imagine.

8

Figura II.2 – Exemplu de configurări Symfony și explicații la acestea
În al doilea rând trebuie construită logica aplicației. De obicei este un singur modul al
aplicației numit AppBundle în mod implicit. Dacă pe parcurs se observă că sunt anumite
trăsături ale aplicației ce pot fi extrase într -un modul separat atunci acestea vor f i mutate în
src/NumeBundle .
În interiorul unui modul (bundle) sunt anumite standarde ce trebuie urmate ca urmare a
practicilor din Symfony și anume:
 Resursele modului ce țin doar de acesta vor fi stocate în directorul src/
NumeBundle/Resources .
 Toată logica ce ține de interfața cu utilizatorul va fi organizată astfel:
o controlorii aplicației se află în src/NumeBundle/Controller , aceștia
având vederile stocate în src/NumeBundle/Resources/views , iar
modelurile asociate în src/ NumeBundle/Entity .
 Toate serv iciile aplicației trebuie stocate în src/NumeBundle/Service , iar
configurația pentru acestea în
src/NumeBundle/Resources/config/services.(yml|xml|php) .
 Toate procesele aplicației care trebuie rulate după anumite programări vor fi definite
în src/NumeBundle /Command .
 Toate formularele din aplicație vor fi stocate în src/NumeBundle/Form/Type ,
iar validările asociate acestora sau alte tipuri de validări în
src/NumeBundle/Validator .

9
 Orice structură aparte ce nu are legătură cu cele standard de mai sus trebuie să țină
cont de următoarele:
o Numele clasei din fișier va fi Robot pentru că trebuie să aibă același nume ca și
numele fișierului fără extensie.
o Dacă se scrie o clasă numită Robot.php în directorul
src/NumeBundle/Navigation atunci clasa Robot va avea numele d e
spațiu asociat clasei ca fiind NumeBundle \Navigation .
o Acest lucru permite obiectului de încărcare automată de clase ( Autoloader.php
și acesta este realizat de către creatorii managerului de pachete Composer )
numit autoloader să încarce clasa automat.
În cele din urmă trebuie decis pentru un modul dacă e important ca acesta să aibă toate
setările ce țin de el în interiorul modului sau să fie plasate în afara modului la nivel de
aplicație în directorul app/ . Acest lucru se decide pe bază de analiză. Trebuie luat în vedere
dacă acel modul va fi vreodată externalizat (adică publicat ca și pachet în comunitatea de
PHP); dacă nu există astfel de motive atunci sunt anumite lucruri care se pot pune în
directorul app/ :
 Setările ce în mod normal ar fi în src/NumeBun dle/Resources pot fi
transferate în src/Resources . Aici poate fi vorba de vederi, configurări de
servicii sau traduceri.
II.3. Arhitectura nucleului Symfony
Nucleul Symfony are un rol extrem de important în încărcarea modulelor pe care le
conține arhitectu ra Symfony, dar și a acelora care se adaugă la aplicația rezultată, module
externe arhitecturii Symfony. Tot nucleul realizează formularea răspunsului pe care aplicația
îl va da în urma unei cereri web.
Iată punctele principale în care nucleul intervine în mecanismul cerere -răspuns:
1. În urma unei cereri, URL -ul (Identificator de Resurse Uniform) asociat cererii este
mapat la un controlor frontal (de obicei va fi stocat în web/app.php sau
web/app_dev.php). Această mapare este realizată de reguli ale serverulu i Apache
care de regulă vor fi prez ente în fișierul web/.htaccess.

10
2. În interiorul controlerului frontal următoarele se întâmplă:
a. Obiectul nucleului este instanțiat  $kernel = new AppKernel ('dev', true);
b. Clasele se încarcă din memoria cache  $kernel ->loadClassCache ();
c. Obiectul cerere se încarcă din variabilele globale standard în limbajul PHP
($_GET, $_POST, $_SERVER, ș.a.m.d.)  $request =
Request ::createFromGlobals ();
d. Obiectul nucleu se ocupă de cerere și va intermedia formularea unui obiect
răspuns  $response = $kernel ->handle($request );
e. Obiectul răspuns va transforma informațiile care le are și le va trimite
navigatorului care a inițiat cererea  $response ->send();
f. Obiectul nucleu își termină activitatea curățând memoria cumulată în
obiectele cerere și răspuns  $kernel ->terminate ($request , $response );
Cele mai importante puncte în toți acești pași pe care le face nucleul sunt 2a și 2b.
Sumarul a rhitecturii de mapare a cererii și de formulare a răspunsului în Symfony este vizual
descrisă în figura II.3 [7].
Figura II.3. – Arhitectura de mapare a cererii și formulare a răspunsului din Symfony
În cadrul punctului 2a se petrece instanțierea lui, obiectul nucleu achiziț ionând toate
informațiile de bază despre el: mediul de execuție, calea către directorul rădăcină al aplicației,

11
dacă modul de execuție este în stil depanare sau nu și de asemenea se stochează timpul de
început (doar în modul depanare – cu scop de a măsura timpi de execuție).
În cadrul punctului 2b se execută formularea răspunsului. Acțiuni premergătoare
formulării răspunsului sunt încărcarea serviciilor aplicației, încărcarea modulelor și
determinarea controlorului care va fi folosit.

12
Capitolul III. Principii ale automatizării
Existǎ anumite principii care se repetă în ceea ce privește mecanismele de automatizare.
Aceste principii fac ca implementarea tehnicilor te automatizare să urmeze un curs stabil, fără
de care ar exista foarte multe erori în cadrul automatizării.
Iată câteva dintre cele mai sănătoase principii de automatizare [6]:
 Cercetarea problemei de automatizat și formularea de tipare  gradul de
performanță al automatizării crește dacă cunoaștem bine problema ce se dorește
automatizat ă. Formularea de tipare înseamnă să se găsească și să se împartă logica
rezolvării problemei în blocuri de sarcini repetitive.
Exemplu: se dorește achiziționarea de date de la o platformă socială. După
cercetare se constată că sunt patru pași pentru achizi ționare:
1. Accesarea datelor pe baza unui cuvânt de căutare.
2. Preluarea datelor vizibile care s -au încărcat deja în pagină.
3. Efectuarea derulării în jos a paginii cu date.
4. Sesizarea finalului setului de date. Dacă nu s -a ajuns la finalul datelor
atunci se revi ne la pasul 2.
 Dacă cercetarea problemei este prea anevoioasă se recomandă împărțirea
problemei în mai multe probleme mici.
Exemplu:
În cadrul acestei lucrări o problemă interesantă a fost soluționarea adăugării
automate în comunități Google Plus. Deși la prima vedere pare că este o problemă
simplă nu e. Tocmai de aceea această problemă a fost împărțită în următoarele
probleme mici:
1. Căutarea de comunități pe baza unui cuvânt cheie, număr de membrii
minim și maxim, nivel de vizibilitate (public sau privat).
2. Utilizatorul poate să aleagă acum pe baza căutării de la punctul 1 unde
anume e potrivit pentru el să se alăture.
3. Procesul de adăugare se realizează în spate, fără a forța utilizatorul să
aștepte.
4. Stocarea evoluției adăugării este o consecință imediată a f aptului că
utilizatorul va vrea la un moment dat să vadă dacă acțiunile comandate la 2
s-au desfășurat sau nu.

13
5. Alertarea utilizatorului printr -un sistem de notificări.
 Testarea modulelor automate ar trebui să se realizeze tot prin teste automate.
 Avansarea soluției la o problemă în detrimentul optimizării  datorită
complexității care însoțește orice problemă ce necesită automatizare, există un soi
de frică în a aborda soluția până când nu este una perfectă. Dar adevărul e că asta
va ține pe loc evoluția so luției și atunci când crezi că e soluția perfectă, în realitate
are multe lucrui care au scăpat capacității cognitive umane limitate. Așa că pentru
a preveni stagnarea, oferirea unor soluții imperfecte care se îmbunătățesc ulterior
este o alternativă mai v iabilă decât atingerea perfecțiunii din prima.
 Înregistrarea evoluției automatizării  în general automatizarea e constituită din
procese care rulează programe predefinite și uneori dotate cu inteligență artificială.
Cu toate acestea dacă un singur lucru p oate eșua într -un plan deservit automat
atunci asta poate să afecteze experiența utilizatorilor. Astfel că se recomandă
salvarea de la o stare la alta a procesului, informații despre cum a decurs, pentru
cine s -a efectuat procesul, data acestuia și orice a r putea să ajute la depistarea
viitoarelor probleme. Probleme vor fi, asta este indiscutabil, dar contează cât de
pregătit ești în a găsi cauza la acestea. Stocarea datelor legate de proces poate fi
făcută în fișiere de înre gistrări (log files) sau în baza de date.
III.1. Ghid pentru automatizare
Automatizarea aduce după sine trei întrebări [5]:
1. Când se desfășoară planul automat ?
2. Cine sunt oamenii implicați ?
3. Ce resurse necesită ?
Spre exemplu, compania Google pentru a soluționa problema indexării în motorul lor de
căutare, ar fi putut oferi următoarele răspunsuri la cele trei întrebări.
1. Zilnic. Asta deoarece zilnic apar website -uri noi în lume, iar scanarea internetului
trebuie să fie constantă.
2. Oamenii care caută paginile web și se așteaptă la rezult ate “inteligente”, pe baza
preferințelor lor. Pe urmă sunt implicați o grămadă de oameni la dezvoltarea
programelor ce constituie robotul de căutare și indexare al companiei Google.

14
3. Cu toate că nu știu cât de vast e imperiul de resurse al companiei Google, iată o
aproximare a lucrurilor pe care le -ar necesita doar robotul de căutare și indexare:
 Servere de ultimă generație și tehnologii diverse cu implementări în
multiple limbaje.
 Mai multe instanțe ale robotului de căutare și indexare (care rulează în
nodu rile serverelor companiei din toată lumea) care fac constant cereri
la paginile deja indexate și caută referințe noi. Referințele noi trebuiesc
indexate, clasificate și notate pe baza a numeroși factori (precum
performanță, lizibilitate, durata medie a viz itei pe aceste pagini,
ș.a.m.d.). Aceeași notare trebuie actualizată constant și pentru paginile
deja indexate.
În măsura răspunsurilor date se poate începe implementarea programelor care vor
constitui soluția la automatizarea sarcinilor.
III.2. Resursele necesare pentru un robot virtual realizat în Symfony
În cazul acestei lucrări au fost utilizate următoarele resurse:
 PHP 5.6.
 Componentă PHP numită Mink Extension versiunea 2.2.  este o adaptare a
componentei Mink versiunea 1.6. la arhitectura Symfony 3 .
 Componentă PHP Mink Selenium Driver 1.3.  este implementarea unui mod de
interacțiune cu serverul Selenium.
 Selenium server1  este intermediarul între aplicația Marketilio și clientul
(browser -ul). Driver -ul Selenium este cel folosește această comunica re între
Selenium server și client (browser) și care este controlat din PHP programatic.
 Un client (browser). În acest caz a fost folosit clientul Chrome.
 Un calculator cu procesor puternic și memorie RAM2 cel puțin 4 Gb3. Asta
deoarece în cadrul automatiz ărilor pot să ruleze mai multe instanțe ale clientului
fiecare instanță consumând cel puțin 100 Mb4 de memorie RAM.

1 http://www.seleniumhq.org/download/

15
Iată o schemă a felului în care interacționează aceste resurse între ele în figura II I.1.

Figura III.1. – Interacțiunea resurselor necesare robotului virtual
Arhitectura Symfony este fundamentul care a fost folosit pentru scrierea oricărui program
asociat cu robotul acestei lucrări. Se poate vedea că este o comunicare strânsă între aceste
programe și arhitectura Symfony. În cadrul log icii robotului au intrat alte două componente,
este vorba despre Mink Extension și Mink Driver, cea din urmă fiind responsabilă de
comunicarea cu intermediarul Selenium server.
Unde se realizează controlul automat al clientului ?
Se realizează de către in termediarul Selenium server, iar la capetele liniei de comunicare
se află Mink Driver și clientul Chrome. Astfel se poate simula o interacțiune cu aplicațiile
web, exact ca și cum ar face -o un utilizator uman. Se pot vizita pagini, interacționa cu
butoane, formulare și link -uri. De asemenea culegerea de date corespunzător unor tipare este

2 https://ro.wikipedia.org/wiki/Memorie_cu_acces_aleator
3 Gb – unitate de măsură a informației digitale egală cu 1024 Mb.
4 Mb – unitate de măsură a informației digitale egală cu 1024 * 1024 de octeți.

16
posibilă. În orice moment se poate accesa DOM -ul5 și executa scripturi în limbajul javascript
permițând o interacțiune și mai compl exă decât cea posibilă pentru un utilizator obișnuit.

5 DOM – Document Object Model – Modelul Obiectului de Document – este o
abstractizare documentului HTML deschis la un moment dat în fereastra clientului (browser –
ului), cu acces la proprietăți legate de pagină și metode cu care se poate manipula dinamic
conținutul sau starea curentă a documentului.

17
Capitolul IV. Aplicația Marketilio
IV.1. Scopul aplicației
Munca marketer -ilor este una în care trebuie să fie atenți la foarte multe detalii legate de
conținutul mesajului, la impresii și l a detalii de crearea unei interacțiuni pozitive cu potențialii
clienți. Pe lângă aceasta marketer -ii trebuie să cunoască modalități rapide de a livra mesajul
odată ce acesta e conceput.
Marketilio se ocupă cu partea de livrare a mesajului conceput de marke ter-i. Cu doar
câteva setări și realizarea unei programări utilizatorul poate să acceseze o lume întreagă de
clienți. Livrarea făcută manual este prea costisitoare pentru o afacere, astfel că Marketilio este
și o unealtă de economisit într -o lume atât de c oncentrată pe partea de marketing.
IV.2. Arhitectura aplicației
Organigrama arhitecturii aplicației
În figura IV.1 se poate vedea organigrama arhitecturii aplicației Marketilio, lucru ce va
ajuta mult la clarificarea modului de funcționare al acesteia.

18

Figura IV.1 – Arhitectura aplicației Marketilio

19
Detalierea organigramei
În cele ce urmează se va detalia fiecare componentă vizibilă în organigramă, spre a
înțelege mai bine rolul ei în aplicație:
 Modulul admin  este responsabil cu accesul utilizatorilor ce au rol de
administrator și permite crearea de interfețe ce pot fi supravegheate de aceștia.
 Zona de admin  este implementarea propriu -zisă a interfețelor pentru
administratori, bazată pe modulul admin.
 Arhitectura Symfony 3  este constituită dintr -un set de practici bune utilizate de
comunitatea programatorilor PHP și componente PHP. Se bazează pe multe tipare des
pomenite în dezvoltarea software [8].
 Module PHP (Doctrine, Mink)  sunt toate componentele care formează
fundamentul arhitecturii Symfony 3.
 PHP (>= 5.5.9)  limbajul PHP alături de varianta minimă compatibilă cu Symfony
3. Limbajul PHP ( PHP: Hypertext Preprocessor ) este un limbaj interpretat deschis la
contribuție publică, care în mod special este folosit pentru dezvoltare web și poate fi
încadrat în HTML [9].
 Composer (manager de module)  facilitează încărcarea modulelor PHP necesare
aplicației. Validează compatibilitatea între eventualele module pe baza informațiilor
disponibile în baza de date a pachetelor6 PHP. Conform documentației ofi ciale, este o
unealtă folosită pentru managementul dependențelor unui proiect scris în limbajul
PHP [10].
 Alte module (Securitate, Management utilizatori, etc)  sunt module externe
arhitecturii Symfony care au avut diverse roluri în aplicație. Spre exempl u modulul de

6 https://packagist.org/ → înscrierea pachetelor PHP și referințelor pentru acestea, dar
și a dependențelor asociate.

20
utilizatori permite crearea, logarea și înregistrarea utilizatorilor, cu mici ajustări la
necesitățile aplicației curente.
 Zona utilizator  este zona care cuprinde interfața utilizator.
 Configurație G+  o parte a zonei utilizator în care se salvează setări legate de
rețeaua socială Google Plus.
 Istoric acțiuni G+  reprezintă sistemul de notificări pe care le primește utilizatorul
în urma activității proceselor interne.
 Comenzi (procese PHP)  reprezintă programe ce pot fi executate din termi nal7.
 Crontab8 program ce rulează alte comenzi planificate la anumite intervale de timp.
 Informații despre rulajul comenzilor  date salvate în anumite tabele din baza de
date după ce anumite acțiuni s -au desfășurat în aplicație. De exemplu, dacă un proces
a executat cu succes alăturarea unui utilizator într -o comunitate Google Plus atunci
acest lucru va fi semnalat cu o intrare nouă într -un tabel.
 Modulul PHP Mink  rol deosebit de important în executarea acțiunilor robotului,
conectează driverul Mi nk de Selenium Server.
 Robot virtual9  un set de clase PHP ce compun funcționalități ce imită activități
umane online pe platforma socială Google Plus.

7 Terminal → cons olă, interacțiune cu utilizatorul în alb și negru
https://en.wikipedia.org/wiki/Terminal
8 Crontab → program Linux ce rulează în fundal, ce are rolul de a rula alte comenzi ce
sunt planificate într -un fișier de configurare al acestuia
https://help.ubuntu.com/community/CronHowto .
9 Prin robot virtual se înțelege o colecție de programe destinate efectuării de acțiuni
care în mod normal ar fi ef ectuate prin intervenție umană.

21
 Clientul Chrome  browser -ul Chrome, navigator de pagini web.
 Modulul PHP Mink Driver  acest modul face posibilă comunicarea cu Selenium
Server.
 Selenium server  este cel care permite comunicarea cu browser -ul și automat și
controlul acestuia.
IV.3. Elemente de design și interfață
Design -ul aplicației este bazat pe o temă disponibilă gratuit numită G entelella10. Această
temă folosește ca și fundament pentru dezvoltarea interfeței arhitectura bootstrap11.
Bootstrap este o tehnologie de dezvoltare a CSS -ului ( Cascading Style Sheets – Foi de
Stiluri în Cascadă), bazată pe împărțirea în module a stilurilor, utilizarea de variabile și
funcții. Are la bază ideea „ Mobile first ” (axare pe mobil prima dată) lucru care presupune
dezvoltarea design -ului pornind de la un ecran mic și pe urmă adaptat pentru ecrane mai mari
pornind de la modelul de mobil [11].
Sunt pa tru ecrane principale pe care le abordează Bootstrap și este vorba despre [12]:
1. Dispozitive foarte mici (telefoane inteligente) – cu lațimea ecranului mai mică decât
768 pixeli.
2. Dispozitive mici (tablete) – cu lățimea ecranului mai mare decât 768 pixeli și mai
mică decât 992 pixeli.
3. Dispozitive medii (calculatoare personale) – cu lățimea ecranului mai mare decât 992
pixeli și mai mică decât 1200px.

10 Gentelella → temă bazată pe arhitectura bootstrap
https://github.com/puikinsh/gentelella.
11 Bootstrap → arhitectură și filozofie de dezvoltare a CSS -ului asociat unei aplicații
web http://getbootstrap.com/

22
4. Dispozitive mari (calculatoare personale) – cu lățimea ecranului mai mare decât 1200
pixeli.
Bootstrap are și un sistem grilă pentru organizarea spațiului dintr -un document web care
este bazat pe cele patru tipuri de dispozitive. În figura IV.2 se poate vedea un exemplu de
organizare a spațiului dintr -un document utilizând împarțire în două coloan e pentru
dispozitive foarte mici și mici, în trei coloane pentru dispozitive medii și în patru coloane
pentru dispozitive mari.
<div class= "row" >
<div class= "col-xs-6 col -sm-6 col -md-4 col -lg-3">…</div>
<div class= "col-xs-6 col -sm-6 col -md-4 col -lg-3">…</div>
<div class= "col-xs-6 col -sm-6 col -md-4 col -lg-3">…</div>
<div class= "col-xs-6 col -sm-6 col -md-4 col -lg-3">…</div>
</div>
Figura IV.2 – Exemplu de utilizare a sistemului grilă din Bootstrap
Tehnologia care face arhitectura Bootstrap atât de importantă în lumea web -ului este
SASS12 (Syntactically Awesome Style Sheets – Foi de Stiluri cu Sintaxă Grozavă). SASS este
un limbaj care produce CSS în urma trecerii fișierelor SASS (cu extensia .scss) p rintr-un
compilator [13]. Acest compilator analizează corectitudinea sintactică a fișierelor și produce
cod CSS valid.
De ce este important SASS în lumea designerilor ?
Scrierea unui cod CSS organizat și extensibil este o problemă dificilă. Oricât de mult s-ar
dori păstrarea unor principii sănătoase și evitarea repetiției, limbajul CSS nu permite acest

12 SASS → ext ensie a limbajului CSS cu accent pe modularizare și evitarea repetiției
http://sass -lang.com/

23
lucru. Astfel că cei mai mulți designeri ajung să repete foarte multe stiluri în mai multe locuri,
iar de fiecare dată când trebuie să înceapă un proiect nou , trebuie să o ia de la zero.
SASS este soluția mult așteptat ă pentru designeri pentru că abordează problema CSS -ului
de la un nivel mai sus, în care există un control programatic asupra designului și mai mult
decât atât, datorită compilării se pot obține o varietate de design -uri care pot fi testate și
integrate pe măsura unui răspuns real de la client.
În cadrul acestui proiect spre exemplu, pentru a putea extinde tema de Gentelella, au fost
necesare doar două fișiere. Un fișier numit _variables.scss unde se definesc variabile din temă
și altul numit custom.scss unde se integrează variabilele și se extinde tema prin sintaxa din
figura IV.3 :
@import "../vendor/gentelella/src/scss/custom.scss"
@import "_variables.scss" ;
Figura IV.3 – Exemplu de utilizare tema Gentelella
Desigur că nu toate elementele de interfață au fost realizate utilizând doar CSS. Sunt
anumite funcționalități care nu pot fi atinse decât numai prin intervenția unui limbaj dinamic,
ce presupune accesarea documentului și modificarea stării sau modificarea proprietățile
acestuia.
De exemplu, funcția de ecran complet (full screen) prezentă în partea de jos a aplicației (în
meniul lateral stânga). Această funcție este îndeplinită utilizând javascript13, mai exact o
extensie javascript numită JQuery. JQuery este o librărie rapidă, cu linii de cod puține,
constituită din funcționalități ce oferă o experiență bogată utilizatorului și este bazată pe
Javascript [ 14].
Porțiunea de cod care realizează implementarea de ecran complet este o componentă
gratuită realizată de un programator javascript. Modul de folosire al componentei adaptat
situației din aplicația Marketilio este prezentată în figura IV.4:

13 Javascript – limbajul de programare al web -ului → https://www.w3schools.com/Js/

24
<script>
$(document ).ready (function () {
$('.glyphicon -fullscreen' ).parent ().click (function () {
$(document ).toggleFullScreen ();
});
});
</script>
Figura IV.4 – Exemplu de utilizare a unui script bazat pe JQuery
IV.4. Implementarea aplicației
În această parte a lucrării voi detalia aspecte ale implementării aplicației, făcând referire la
porțiuni din codul aplicației.
IV.4.1. Viziune de ansamblu
Sunt cinci module deasupra bazei formată de componentele PHP ale arhitecturii Symfony
3 (exceptând modulele externe arhitecturii Symfony).
În figura IV.5 se poate vedea structura de directoare a aplicației Marketilio.

25

Figura IV.5 – Structura de directoare a aplicației Marketilio
Voi enumera fiecare modul și voi descrie ce rol are, exemplificând cu cod sursă acolo
unde este cazul.
Modulul App (stoc at în directorul src/AppBundle ) este centrul aplicației. Aici se
reunesc toate funcționalitățile aplicației utilizând suport din celelalte module. Este locul unde
s-a definit logica pentru zona de administrator și zona utilizator. Structurarea aplicației î n
formula ce se poate observa în figura IV.5 a fost discutată în subcapitolul I I.2.
Iată câteva dintre cele mai importante părți ale acestui modul:
src/AppBundle/Controller/Uarea
Aici sunt definiți toți controlorii zonei de utilizator. Spre exemplu, contro lorul pentru
conturi Google Plus în figura IV.6.

26

Figura IV.6 – Exemplu de controlor din aplicația Marketilio
Între liniile 17 -24 se află logica pentru afișarea conturilor de Google Plus, disponibile în
browser la locația http://local.marketilio.com/app_dev.php/user/plus -accounts.html .
Între liniile 26 -63 se află logica prin care se adaugă un nou cont Google Plus la aplicație,
adăugare în urma căreia se obține și un set de permisiuni pentru culegere de date din
platformă. Modulul de culegere date nu a fost implementat în aplicație în cadrul acestei lucrări
și face obiectul dezvoltărilor viitoare.
Fișierul src/AppBundle/Controller/Uarea/PlusJoinC ommunityController .php conține
logica pentru căutare și setări de adăugare în comunități. Se poate vedea în figura IV.7
porțiuni de cod unde se execută logica de căutare de comunități din platforma Google Plus. În
browser această logică este disponibilă la link-ul
http://local.marketilio.com/app_dev.php/user/plus -join-community -new-requests.html .

27

Figura IV.7. – Porțiune de cod cu un formular care cere an umite detalii înainte să se facă
căutarea comunităților Google Plus
Logica de aducere a rezultatelor în urma căutării robotului este mult prea mare pentru a fi
inserată aici, dar se poate vizualiza în anexele acestei lucrări, la secția cod sursă, fișierul
src/AppBundle/Controller/Uarea/PlusJoinCommunityController .php (liniile 152 -280).
Modulul Crawler (stocat în directorul src/CrawlerBundle ) este destinat pentru
robot și toate activitățile ce -i aparțin. Detalierea acestui modul se va face la subcapitolul
III.4.3. Implementarea robotului.
Modulul Google (stocat în directorul src/GoogleBundle ) este modulul unde s -a
lucrat la logica de interacțiune cu platforma Google. Sunt două comenzi importante aici:
PlusJoinCommunitiesCommand și PlusMemberCommunitiesCrawl er stocate în
directorul command al acestui modul.

28
Prima comandă folosește robotul pentru executarea acțiunilor de alăturare în comunități
Google Plus. Codul cel mai important din această comandă se poate vedea în anexe la secția
cod sursă, fișierul src/Go ogleBundle/Command/PlusJoinCommunitiesCommand.php (liinile
46-64). Motivul pentru care comanda are puține linii de cod este că folosește o clasă externă
de tip serviciu, unde se execută partea grea de procesare. Delegarea externă este adesea utilă,
deoarec e în viitor este foarte posibil ca această logică de alăturare în comunități să fie
refolosită în alt loc.
A doua comandă este folosită la culegerea comunităților în care conturile Google Plus
asociate utilizatorilor sunt deja membre. În acest caz delegare a externă nu a fost necesară și
toată logica funcționării aparține în totalitate clasei acestei comenzi. Codul sursă se poate
vedea în anexe, secția cod sursă, fișierul
src/GoogleBundle/Command/PlusMemberCommunitiesCrawlerCommand.php (liniile 49 –
120).
Un u ltim serviciu important din acest modul este conținut de clasa GooglePlus (fișierul
src/GoogleBundle/Service/ GooglePlus .php). Acesta este responsabil de obținerea unui jeton
(token) de autorizare cu anumite permisiuni de la rețeaua Google Plus, permisiuni care permit
și preluarea de anumite date din platformă. Pe lângă obținere acest serviciu are și o metodă
destinată actualizării acestui jeton. Protocolul de autorizare folosit în tranzacțiile cu Google
Plus este Oauth 214.
Modulul Schedule (stocat în direct orul src/ScheduleBundle ) a fost folosit pentru
managementul evenimentelor în urma cărora survin acțiuni reale. Nu are în componență nici
un set de acțiuni ce se execută, este doar un modul în care s -a detaliat la nivel de tabel și
interfață un model de eve niment programabil, repetitiv, cu dată de început și sfârșit, având
posibilitatea de activare/dezactivare. Codul sursă pentru entitatea evenimentului se găsește la
anexe, secția cod sursă, fișierul src/ScheduleBundle/Entity/ScheduleEvent.php (liniile 13 -75).

14 Oauth 2 → permite obținerea accesului la datele utilizatorilor de diverse re țele
sociale, între care și Google Plus. Două jetoane stau la baza obținerii accesului, unul de acces
și altul de împrospătare a celui de acces →
https://www.digitalocean.com/community/tutorials/an -introduction -to-oauth -2

29
De asemenea tot în acest modul a fost programat un serviciu căruia furnizândui o entitate
eveniment definită după modelul din anexă, știe să determine dacă un eveniment trebuie
declanșat sau nu (fișier stocat în src/Service/ScheduleHelper.php).
În cele din urmă, modulul User (stocat în src/UserBundle ) este destinat
managementului utilizatorilor și presupune:
 logarea șau înregistrarea utilizatorilor.
 opțiunea de resetare a parolei cunoscând doar e -mailul asociat.
 opțiunea de activare a utilizatorilor prin accesarea căsuței de e -mail și confirmarea
adresei printr -un click pe un link cu destinație Marketilio.
Nu voi pune cod sursă de la acest modul în anexă deoarece conține lucruri de rutină. Se
constată utilizarea a mult cod html pentru diversele pagini ce au legătură cu utilizatorul,
pagini cu prea multe linii de cod și prea puțină relevanță.
IV.4.2. Structura bazei de date
Baza de date utilizatǎ în aplicația Marketilio este prezentatǎ în Anexa 2.
Limbajul și tehnologia folosite pentru reprezentarea bazelor de date este MySQL 5.7.
O scurtă descriere pentru fiecare tabel în parte este urmǎtoarea:
1. fos_user – tabel folosit pentru stocarea datelor utilizatorilor aplicației (atât utilizatori
normali cât și administratori).
2. join_plus_community_request – tabel folosit pentru stocarea setărilor de alăturare în
comunități din rețeatua socială Google Plus. Pentru un cont de Google Plus dat există
mai multe astfel de setări.
3. join_plus_community_request_log – tabel folosit pentru a înregistra comportamentul
robotului după ce încearcă să alăture contul de Google Plus la o comunitate. A fost
important să se sesizeze eventuale probleme și succesul unei astfel de acțiuni.

30
4. plus_account – tabel folosit pentru stocarea conturilor de Google Plus în urma
adăugării acesto ra și totodată a obținerii unor permisiuni de utilizare date în cadrul
aplicației Marketilio. Conturile fără cedare de permisiuni nu vor fi înregistrate în
aplicație. De asemenea un cont existent în aplicație nu va fi funcțional fără precizarea
parolei con tului (parolă care este salvată criptat în tabelă pe baza unui algoritm
personal).
5. plus_account_plus_community – tabel de legătură între conturi și comunități Google
Plus. O astfel de tabelă este necesară atunci când există o relație de „many to many”
sau „mulți la mulți” între două tabele. Pe scurt o astfel de relație spune că un cont
poate să aparțină la mai multe comunități, iar o comunitate poate să aibă mai multe
conturi.
6. plus_ community_share_setting – tabel folosit la stocarea setărilor de distribuire a unui
articol sau mesaj într -o comunitate Google Plus. Această tabelă este legată printr -o
relație „mulți la unu” cu tabela schedule_event; asta înseamnă că o setare poate să aibă
un eveniment asociat, iar un eveniment poate să aibă mai multe setări. În cadrul tabelei
se detaliază când să înceapă acțiunea de distribuire, cât de des să se repete și dacă
evenimentul e activ sau nu. De asemenea există și o dată limită până la care trebuie să
se desfășoare acea acțiune.
7. plus_member_com munity_confirmation_log – tabel cu rol în stocarea notificărilor
legate de alăturarea cu succes într -o comunitate Google Plus.
8. plus_sch edule_event – tabel folosit la stocarea unor evenimente din aplicație în urma
cărora trebuie să se desfășoare acțiuni reale, de către robot și p osibil că în viitor și de
culegerea de informație la date de timp prestabilite.
9. plus_share_post – este articolul distribuit pe platforma Google Plus. Poate fi într -o
comunitate momentan, dar în viitor vor fi și alte zone precum pagini sau profile
personale .
10. plus_share_setting_community – o setare de distribuire poate să aparțină mai multor
comunități, precum și unei comunități i se pot atașa mai multe setări. Acesta este

31
tabelul care reprezintă această relație de „mulți la mulți” între setările de distribui re
(plus_community_share_setting ) și comunitățile propriu -zise.
11. session – tabel folosit la stocarea unor date relevante despre sesiunile utilizatorilor
aplicației.
12. user_notification – tabel care conține notificări din mai multe surse. Până la acest
moment al dezvoltării aplicației aceste surse sunt preluate din tabele precum:
join_plus_community_request_log , plus_member_community_confirmation_log și
plus_member_community_confirmation_log .
IV.4.3. Implementarea robotului
Un modul întreg a fost dedicat în totalitate interfeței de programare a robotului virtual care
realizează acțiuni în cadrul platformei Google Plus. Acesta este stocat în directorul
src/CrawlerBundle . Fundația pentru robot este definită în clasa BaseBot din fișierul
Bot/BaseBot.php . Aici se setează managerul robotului și se inițializează sesiunea Mink prin
intermediul căreia se accesează funcțiile componentei Mink Driver (acesta din urmă va
interacționa cu Selenium Server și va permite controlul total al navigatorului).
Clasa principală în care s -au scris metodele de automatizare se numește GooglePlusBot și
codul asociat se poate găsi în Anexa 1, fișierul src/CrawlerBundle/Bot/GooglePlusBot.php
(liniile 12 -324).
Câteva explicații pentru fiecare astfel de metodă sunt următoarele :
 getMemberCommunities(username, password) – această metodă are rolul de a
achiziționa comunitățile în care utilizatorul cu identificatorul „username” este
membru. Modalitatea se bazează pe ajungerea utiliza torului logat la zona de
comunități și dintre acelea s -a constatat că cele membru sunt identificate de o clasă
CSS cu numele fNtDS. Astfel s -a folosit funcționalitatea componentei Mink de a căuta
și returna rezultatele pe bază de un identificator CSS ( $this->minkSessionPage –
>findAll(‘css’, ‘.fNtDS’) ). Odată aduse rezultatele, acestea sunt prelucrare într -o
colecție de tablouri de comunități și funcția returnează această colecție.

32
 getCommunitiesBySearchTerm(username, password, searchTerm, additionalOptions)
– această metodă returnează o colecție de comunități pe baza unui cuvând de căutare
dat ca și parametru și alte opțiuni (număr de membrii, tip de alăturare privat sau
public). Metoda folosește pagina de comunități returnate de platforma Google Plus. În
acea pagină robotul trebuie să determine dacă a ajuns să returneze numărul cerut de
comunități și să continue deplasarea barei de derulare în caz contrar. Totodată pentru a
preveni intrarea într -o buclă infinită există o verificare care verifică dacă un anume
nod din DOM a apărut (este vorba despre un element DIV dintr -un alt container CSS
cu clasa SrWDEb).
 visitUrlAndGetPage(url) – metodă care vizitează un url dat ca și parametru și salvează
pagina scanată într -o proprietate din obiectul asociat robotului (ob iect instanțiat de
clasa GooglePlusBot).
 checkIfLoggedInAndLoginIfNot(username, password) – este o metodă prin care se
returnează 0 în cazul în care utilizatorul e conectat cu succes, iar o valoare diferită de
zero (ce este codificarea unei erori) dacă a e xistat o eroare la verificare sau la
conectare în caz că utilizatorul nu a fost deja conectat.
 joinCommunity(id) – metodă care realizează conectarea la o comunitate identificată
prin parametrul id (este un id numeric preluat din platforma Google Plus). Met oda
returnează o valoare booleană „true” în caz de succes, iar în caz de eșec o variabilă
booleană „false”.
 isAccountMemberInCommunity(communityId) – metodă care verifică contul logat în
prezent este membru al comunității identificată prin parametrul communityId.
IV.4.4. Integrarea robotului
În cadrul modulului pentru robot a fost definită o clasă de tip serviciu, care este stocată în
src/CrawlerBundle/Service/GooglePlusBotWrapper.php și se numește
GooglePlusBotWrapper. Aceasta are rolul de a oferi ac ces oricăror module care includ acest
serviciu sau întregii aplicații dacă este inclusă în configurația de servicii globale.
Accesul este posibil la toate metodele descrise la subcapitolul Implementarea robotului.

33
Cum se utilizează robotul prin intermedi ul acestei clase ?
Exemplu: pentru aducerea comunităților pe baza cuvântului de căutare „food” utilizarea ar
fi așa:
$communities = $this->googlePlusBotWrapper ->bot->getCommunitiesBySearchTerm(‘ abclaur@gmail.com ’,
‘dskdak213njds’, ‘food’);
În variabila $communities ar fi rezultatul a maxim de o mie de comunități (limitare
internă) reprezentate prin tablouri de date. Dacă s -ar dori returnarea după doar două zeci de
comunități atunci uzul ar fi astfel:
$communities = $this ->googlePlusBotWrapper ->bot->getCommunitiesBySearchTerm(‘ abclaur@gmail.com ’,
‘dskdak213njds’, ‘food’, [‘limit’ => 20]);
În ultimă instanță să zicem că se dorește maxim două zeci de comunități cu număr de
membrii între o sută și o mie, iar aceste comunități trebuie să fie publice. Atunci sintaxa ar fi
următoarea:
$communities = $this ->googlePlusBotWrapper ->bot->getCommunitiesBySearchTerm(‘ abclaur@gmail.com ’,
‘dskdak213njds’, ‘food’, [‘limit’ => 20, ‘numberOfMembersMin’ => 100, ‘numberOfMemberMax’ => 1000,
‘joinStatus’ => ‘Join’]);
Se poate deci vedea că integrarea robotului în procesele sau metodele altor zone ale
aplicației este extrem de facilă prin intermediul s erviciului care încapsulează robotul.
Decuplarea robotului virtual este extrem de evidentă, dar uzul lui este ușor chiar și în ciuda
acestei decuplări. Acesta este și unul dintre dezideratele arhitecturii Symfony, decuplare
completă și integrare facilă din module externe, iar părerea mea e că dezvoltatorii au realizat
acest lucru foarte bine.
IV.4.5. Administrarea aplicației
În stadiul curent al aplicației am considerat că există două tabele pentru care un utilizator
cu rol de administrator (se va numi în continuare administrator) are drepturi totale: tabelul cu
utilizatori și cel cu comunități Plus.
În ceea ce privește crea rea de utilizatori noi, un administrator nu poate crea alți
administratori, doar deținătorul aplicației poate să creeze alți administratori dintr -un terminal
pe serverul asociat aplicației utilizând comanda:

34
app/console fos:user:create –super-admin
Această restricție este o măsură de prevenție, în caz că cineva cu intenții malefice ar reuși
vreodată să aibă acces la datele de acces ale unui administrator. Fiind limitat la o sesiune ar fi
mai ușor de descoperit și anihilat potențialul intrus. Totuși un admin istrator poate să creeze
alți utilizatori. Ultimul lucru la care un utilizator are acces sunt conturile de Google Plus, dar
doar în regim de vizualizare, asta deoarece crearea unui cont de Google Plus necesită și
permisiuni pe care doar contul real le -ar putea activa (aici este vorba de permisiuni de
preluare date din platforma Plus).
În figura IV.8 se poate vedea pagina de administrare a utilizatorilor.

Figura IV.8 – Administrarea utilizatorilor
Administratorul vede detaliile cele mai importante legate d e utilizator în tabelă, de poate
descărca în mai multe formate pentru prelucrări ulterioare. De asemenea mai multe filtre au
fost adăugate în partea superioară, utile atunci când volumul de utilizatori va crește.

35
Pentru a edita un utilizator existent, adm inistratorul trebuie să dea click pe identificatorul
utilizatorului, evidențiat diferit față de celelalte valori din tabel, cu un albastru deschis.
Crearea unui utilizator nou se face în urma acționării butonului „Add new” prezent în partea
superioară.
O remarcă importantă legată de limbajul utilizat în interfață: dacă administratorul schimbă
limba pentru un utilizator, această modificare se va resimți pentru acesta doar în urma
începerii unei noi sesiuni. Sesiunea oricum expiră din mai multe motive (brows er, server), dar
utilizatorul poate reintra într -o sesiune nouă și mai repede prin delogare din sesiunea curentă
și logare în cea nouă.
În figura IV.9 se poate vedea cum arată pagina de administrare a comunităților Google
Plus.

Figura IV.9 – Administrarea comunităților Google Plus
Sunt disponibile informații despre numele extern al comunității (exact cel din platforma
Plus), număr de membrii și ce conturi există în acea comunitate. De asemenea chiar lângă
identificatorul intern al unei comunită ți există un link extern care duce la pagina principală
din Google Plus.

36
IV.4.6. Utilizarea aplicației
În cele ce urmează se va detalia modul de utilizare al aplicației, pornind de la situația în
care un om dat nu are nici măcar un cont încă.
Primul lucru pentru a putea utiliza este înregistrarea care se poate face la adresa:
http://local.marketilio.com/app_dev.php/user/login . La pagina încărcată se apasă din nou
legătura „ Create Account ” și pe urmă se trec datele cerute: nume utilizator, e -mail, parolă și
confirmarea parolei din nou. Un e -mail va fi trimis la adresa precizată. În acesta se va da click
pe legătura precizată și acum contul este funcțional. În figura IV.10 se poate vedea for mularul
de înregistrare.

Figura IV.10 – Înregistrarea în aplicație
Al doilea lucru necesar este logarea în aplicație utilizând formularul principal încărcat la
adresa de mai sus.
Al treilea lucru este adăugarea unui cont nou de Google Plus. Din meniul de acțiuni rapide
din partea de sus a paginii se selectează „ Add a new Google Plus account ” (Adaugă un cont
nou Google Plus) . După cedarea de permisiuni a contului nou în favoarea accesului din partea

37
Marketilio, utilizatorul va fi redirecționat la pagina cu conturi Plus unde va trebui adăugată
parola reală a contului. Această valoare va fi criptată, deci nu sunt probleme de securitate la
acest pas. În figura IV.11 se poate vedea cum arată acțiunea rapidă de adăugare a contului și
pagina unde va fi redirecț ionat utilizatorul.

Figura IV.11 – Adăugare cont Plus nou și pagina de redirecționare după cedare permisiuni
După crearea cont ului, utilizatorul va putea utiliza facilitățile aplicației. În funcție de
domeniul de activitate al marketer -ului acesta își v a stabili cuvinte cheie și va începe să caute
comunități potrivite pentru profilul afacerii pe care o promovează.
Din acțiuni rapide poate selecta „ Join google plus communities ” (alăturare în comunități
Google Plus), iar în pagina care aterizează stabile ște parametrii de căutare. După ce a decis ce
comunități sunt bune pentru el, le bifează și se vor salva în baza de date, urmând ca un proces
în fundal să execute acțiunile de alăturare în comunități. Modalitatea de căutare a
comunităților și alăturare în acestea este prezentată în figura IV.12.

38

Figura IV.12 – Exemplu de căutare și alăturare în comunități Google Plus
Se remarcă în figura IV.12 că pentru ca un cont de Google Plus să se alăture unei
comunități găsite în urma procesului de căutare, trebuie să se bifeze permisiunea d e alăturare
„Join this community ?” (Te alături acestei comunități ?) și după ce a bifat toate comunitățile
dorite se apasă butonul „ Save join requests ” (Salvare cereri de alăturare) .
Într-un final, după ce contul este acceptat în câteva comunități, el poate să distribuie
informație tot printr -o facilitate a aplicației, accesând din meniul lateral funcționalitatea de
distribuire pe bază de p rogram are: „Manage community share settings ” (Managementul
setărilor de distribuire în comunități). În pagina care se deschide interfața va arăta precum în
figura IV.13.

39

Figura IV.13 – Interfața pentru setările de distribuire în comunităț
O setare de dis tribuire a informației deja existentă poate fi accesată utilizând butonul
„Edit” (Editare) din dreptul setării care se dorește a fi modificată (a se vedea figura IV.13).
Dacă se dorește adăugarea unei setări noi atunci se va accesa „ Add a new setting ” (Ada ugă
o setare nouă) utilizând meniul prezentat în figura IV.13, poziționat în partea dreapta sus. În
urma accesării acestei funcții se va ajunge la pagina de programare a unei noi distribuiri,
pagină care arată ca în figura IV.14.

40

Figura IV.14 – Setarea u nei distribuiri noi în comunitățile Google Plus

41
Capitolul V. Concluzii
Proiectul acesta a fost o provocare personală însoțită de la bun început de foarte multe
bariere în urma cercetării inițiale. Spre exemplu , când am început să lucrez la aplicație am
ales din start platforma Google Plus ca și țintă pentru automatizare deoarece știam cu
certitudine că nu sunt mulți concurenți pe piață și cei care sunt nu aveau decât culegere de
date, nimic care să acționeze sim ilar unui om. Am descoperit repede în urma cercetării inițiale
că API -ul Google Plus nu permite scrieri (însemnând orice acțiuni de distribuire automată a
informației, atribuire de aprecieri, ș.a.), doar citire de date într -un sens limitat și restrictiv.
Cu toate astea aveam o oarecare experiență în automatizări software și mi -am permis să –
mi dedic timpul construirii unui robot care să se comporte asemenea unui utilizator care
navighează browser -ul. Cu toate acestea munca implicată a fost de ordinul a sute de ore, iar
rezultatele abia răsăreau.
Un impas major în dezvoltarea de roboți virtuali este timpul destul de lung pe care trebuie
să-l acorzi testelor în diverse contexte, pentru a elimina orice posibilitate de a merge ceva rău.
O altă problemă o reprezi ntă platforma în sine și identificarea elementelor cu care se
interacționează. Google Plus este plin de cod sursă HTML cu identificatori CSS codificați, iar
uneori identificarea elementelor cu care trebuia să interacționez a fost extrem de dificilă.
Una p este alta, cred cu tărie că proiectul ales este o temă importantă pentru un
programator, dar de asemenea și pentru miile de marketer -i care așteaptă o soluție de
automatizare a platformei.
Sunt multe direcții de dezvoltare viitoare , iată doar câteva mențio nate aici:
 interacțiune cu alți utilizatori Google Plus folosind robotul; atribuire de aprecieri
pentru a atrage atenția sau reciprocitatea, mesaje private unor utilizatori care au fost
scanați de robot și se încadrează profilului ideal al clientului, pent ru produsul
comercializat.
 integrarea altor platforme sociale precum Facebook, Twitter, Instagram cu
funcționalități similare. Centralizarea tuturor acestor platforme într -un singur loc din
Marketilio, permițând controlul lor foarte repede și ușor.

42
 ar treb ui îmbunătățită și extinsă logica de funcționare a robotului, incluzând și tehnici
de inteligență artificială în dezvoltările viitoare. Cred că dacă robotul ar avea un soi de
recunoaștere a platformei Plus și un bagaj suficient de capabil de recunoaștere d e
tipare, același robot ar putea fi folosit la o interacțiune mult mai bună cu utilizatorii
platformei. Un lucru important de care se feresc toți e ideea de SPAM (mesaj
nesolicitat), pe care dacă robotul ar putea -o sesiza ar fi deja un plus enorm față de
stadiul curent.

43
Bibliografie
[1] http://www.informit.com/articles/article.aspx?p=30084&seqNum=4
[2] Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm: Design Patterns.
Elements of Reusable Object -Oriented Software , Addison -Wesley; Octombri e 21 1994, pagini
431.
[3] http://symfony.com/doc/current/introduction/http_fundam entals.html
[4] http://symfony.com/doc/current/_images/xkcd -full.png
[5] Jacob Ward: Instant PHP Web scraping, Packt Publishing Ltd.; Iulie 2013, pagini 60.
[6] Michael Schrenk: Webbots , Spiders and Screen Scrapers, 2nd Edition, No Starch Press;
Martie 2012, pagini 392.
[7] http://symfony.com/doc/current/_images/10 -kernel -view.png
[8] http://symfony.com/doc/current/best_practices/index.html
[9] http://php.net/manual/en/intro -whatis.php
[10] https://getcomposer.org/doc/00 -intro.md
[11] https://code.tutsplus.com/tutorials/mobile -first-with-bootstrap -3–net-34808
[12] https://www.tutorialspoint.com/bootstrap/bootstrap_grid_system.htm

[13] http://sass -lang.com/docum entation/file.SASS_REFERENCE.html

[14] http://jquery.com/

44
Anexa 1. Cod sursă
Pentru codul sursă anexat acestei lucrări se va preciza calea (relativă la directorul ce
conține tot codul), evidențiată prin înclinare și îngroșare și abia apoi liniile care constituie
codul propriu -zis. Din motive de brevitate codul expus în această anexă este incomplet, s -a
trecut aici ce a fost mai important (pe baza experienței c umulate în urma codului scris).
src/AppBundle/Controller/UA rea/PlusJoinCommunityController.php

45

46
src/ScheduleBundle /Entity/ScheduleEvent.php

src/GoogleBundle/Command/PlusJoinCommunitiesCommand.php

47
src/GoogleBundle/Command/PlusMemberCommunitiesCrawlerCommand.php

48
src/CrawlerBundle/Bot/GooglePlusBot.php

49

50
Anexa 2. Baza de date

DECLARAȚIE DE AUTENTICITATE A
LUCRĂRII DE FINALIZARE A STUDIILOR

Titlul lucrării: ____________________________________________________
________________________________________________________________
________________________________________________________________
Autorul lucrării: _____________________________________
Lucrarea de finalizare a studiilor este elaborată în vederea susținerii
examenului de finalizare a studiilor organizat de către Facultatea
______________________________________ din cadrul Universității din
Oradea, sesiunea ____________________ a anului universitar ____________ .
Prin prezenta, sub semnatul (nume, prenume, CNP) __________________
________________________________________________________________
_______________________________________________________________,
declar pe proprie răspundere că ac eastă lucrare a fost scrisă de către mine, fără
nici un ajutor neautorizat și că nici o parte a lucrării nu conține aplicații sau
studii de caz publicate de alți autori.
Declar, de asemenea, că în lucrare nu există idei, tabele, grafice, hărți sau
alte sur se folosite fără respectarea legii române și a convențiilor internaționale
privind drepturile de autor.
Oradea,
Data Semnătura