Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarowého inženýrství

Diplomová práce

Nástroj pro monitoring na sociálních sítích Bc. Vojtěch Svoboda

Vedoucí práce: Ing. Jaroslav Kuchař

9. května 2012

Poděkování Zde bych chtěl poděkovat mému vedoucímu práce Ing. Jaroslavu Kuchařovi za cenné rady, které pomohli k lepší kvalitě této práce. Dále pak rodině a kamarádům za zpětnou vazbu při psaní této práce.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 9. května 2012

..................... vii

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Vojtěch Svoboda. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Vojtěch Svoboda. Nástroj pro monitoring na sociálních sítích: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract The aims of this thesis are design and implement a tool for monitoring of social networks. The main function is monitoring selected sources of the Internet and then display searched entries. This entries are filtered according to specified keywords and phrases that can be grouped into arranged themes. Thesis also includes initial analysis, which aims to clearly define requirements, because we must know, what problem is need to solve. Keywords monitoring, social networks, api, mashup

Abstrakt Cílem této diplomové práce je navrhnout a implementovat nástroj pro monitoring sociálních sítí. Hlavní funkcí aplikace je sledování vybraných zdrojů v rámci sítě Internet a následné zobrazení nalezených výsledků. Výsledky se filtrují dle zadaných klíčových slov a slovních spojení, která lze sdružovat do přehledných témat. Součástí práce je i vstupní analýza, která má za cíl jasně definovat požadavky na vlastní aplikaci, co musí umět a jaký problém to bude řešit. Klíčová slova monitoring, sociální sítě, api, mashup ix

Obsah 1 Úvod 1.1 Vývoj internetu . . . . . . . 1.2 Internet dnes . . . . . . . . 1.3 Monitorování sítí a sběr dat 1.4 Cílová skupina aplikace . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 3 5 8

2 Analýza 2.1 Požadavky na aplikaci . . . . . . . . . . . 2.2 Dnešní možnosti monitoringu a sběru dat 2.3 Seznam sledovaných zdrojů . . . . . . . . 2.4 Rešerše existujících řešení . . . . . . . . . 2.5 Uživatelské role . . . . . . . . . . . . . . . 2.6 Případy užití (Usecases) . . . . . . . . . . 2.7 Rozdělení aplikace na části . . . . . . . . 2.8 Závislosti stránek aplikace (Task graph) . 2.9 Konceptuální modely . . . . . . . . . . . . 2.10 Konceptuální datový model (ER model) .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

9 9 13 14 18 24 26 41 43 44 46

3 Návrh 3.1 Základní výběr platformy . . . . . . . . . 3.2 Návrh uživatelského rozhraní (Wireframy) 3.3 Prototyp grafického rozhraní . . . . . . . 3.4 Výběr platformy . . . . . . . . . . . . . . 3.5 Základní architektura aplikace . . . . . . 3.6 Návrh sběru dat . . . . . . . . . . . . . . 3.7 Návrh filtrování a indexace . . . . . . . . 3.8 Návrh výpisu a vizualizace dat . . . . . . 3.9 Model aplikace (PSM) . . . . . . . . . . . 3.10 Diagram nasazení . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

47 47 49 55 56 59 62 76 80 81 82

xi

4 Implementace 4.1 Grafický vzhled aplikace . . . . . . . . . 4.2 Tvorba základní struktury aplikace . . . 4.3 Správa uživatelů, přihlašování . . . . . . 4.4 Konfigurace monitoringu . . . . . . . . . 4.5 Implementace sběru dat . . . . . . . . . 4.6 Implementace indexace a filtrování . . . 4.7 Implementace vizualizace nalezených dat 4.8 Práce se záznamy . . . . . . . . . . . . . 4.9 Doplňkové funkce . . . . . . . . . . . . . 5 Testování 5.1 Testovací data . . . . . . . . . 5.2 Zhodnocení testovacích dat . . 5.3 Splnění nefunkčních požadavků 5.4 Nalezené nedostatky . . . . . . 5.5 Možnosti rozšíření . . . . . . . 5.6 Přehled nasbíraných dat . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

83 . 83 . 84 . 87 . 87 . 89 . 96 . 97 . 99 . 100

. . . . . .

101 101 102 105 106 107 108

. . . . . .

6 Závěr

109

Literatura

111

A Diagramy aplikace

113

B Obsah přiloženého CD

115

C Přístupové údaje

117

D Instalační manuál 119 D.1 Nastavení importérů . . . . . . . . . . . . . . . . . . . . . . . . 119 D.2 Sběr dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 E Uživatelská příručka E.1 Přihlášení do aplikace . . . . . E.2 Nastavení aplikace . . . . . . . E.3 Zobrazení nalezených záznamů E.4 Ruční vyhledávání dat . . . . . E.5 Export dat . . . . . . . . . . . E.6 Změna hesla a údajů . . . . . . F Seznam použitých zkratek

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

121 121 121 122 122 122 122 123

xii

Seznam obrázků 1.1 1.2

World Wide Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loga sociálních sítí, zleva Facebook, Twitter, Google, YouTube, Foursquare, LinkedIn, Picasa, atd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

4

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23

Uživatelské role . . . . . . . . . . . . . . . . . . . . . . . Diagram případů užití pro přihlášení . . . . . . . . . . . Diagram aktivit pro vybrané Základní případy užití . . Diagram případů užití Správa uživatelů . . . . . . . . . Diagram aktivit pro případy užití Správa uživatelů . . . Diagram případů užití Správa zdrojů . . . . . . . . . . . Diagram aktivit pro případy užití Správa zdrojů . . . . Diagram případů užití Správa témat . . . . . . . . . . . Diagram aktivit pro případy užití Správa témat . . . . . Diagram případů užití Správa klíčových slov . . . . . . . Diagram aktivit pro případy užití Správa klíčových slov Diagram případů užití Zobrazení . . . . . . . . . . . . . Diagram případů užití Zobrazení detailu záznamu . . . Diagram případů užití Sběr dat . . . . . . . . . . . . . . Diagram případů užití Filtrování . . . . . . . . . . . . . Diagram aktivit pro případy užití Filtrování . . . . . . . Diagram případů užití Export dat . . . . . . . . . . . . Diagram aktivit pro případy užití Export dat . . . . . . Diagram případů užití Administrace aplikace . . . . . . Hierarchie stránek . . . . . . . . . . . . . . . . . . . . . Task Graph . . . . . . . . . . . . . . . . . . . . . . . . . Class diagram . . . . . . . . . . . . . . . . . . . . . . . . Data model . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

25 27 27 29 29 31 31 32 33 34 35 36 37 38 39 39 40 40 41 43 44 45 46

3.1 3.2

Wireframe přihlašovací stránky . . . . . . . . . . . . . . . . . . . . Wireframe obrazovky dashboard . . . . . . . . . . . . . . . . . . .

51 52

xiii

. . . . . . . . . . . . . . . . . . . . . . .

2

3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17

Wireframe obrazovky analýza obsahu . . . . Wireframe obrazovky nastavení aplikace . . . Wireframe obrazovky export dat . . . . . . . Wireframe obrazovky export dat . . . . . . . Prototyp aplikace . . . . . . . . . . . . . . . . Návrhový vzor MVC - Model View Controller Ukládání témat a klíčových slov . . . . . . . Ukládání RSS záznamů . . . . . . . . . . . . Ukládání Facebook záznamů . . . . . . . . . Ukládání Twitter záznamů . . . . . . . . . . . Diagram návrhu importérů . . . . . . . . . . Diagram návrhu úložišť . . . . . . . . . . . . Sloučení zdrojů do skupin . . . . . . . . . . . Redundantní ukládání nalezených záznamů . Diagram nasazení . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

53 53 54 55 56 60 63 64 67 69 74 75 76 80 82

4.1 4.2 4.3

Adresářová struktura aplikace . . . . . . . . . . . . . . . . . . . . . Ukázka řádkového grafu . . . . . . . . . . . . . . . . . . . . . . . . Ukázka koláčového grafu . . . . . . . . . . . . . . . . . . . . . . . .

84 98 98

5.1 5.2 5.3

Graf nalezených záznamů pro téma T-mobile . . . . . . . . . . . . 104 Graf nalezených záznamů pro téma Bárta . . . . . . . . . . . . . . 105 Graf nalezených záznamů pro téma Titanic . . . . . . . . . . . . . 105

A.1 Diagram tříd aplikace . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.2 Datový model aplikace . . . . . . . . . . . . . . . . . . . . . . . . . 114

xiv

Seznam tabulek 4.1

Tabulka nastavení CRON . . . . . . . . . . . . . . . . . . . . . . .

95

5.1 5.2

Testovací témata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Nalezené záznamy . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C.1 Přístupové údaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 D.1 Sběr dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

xv

Kapitola

Úvod Internet (14) se v posledních dvou desetiletích stal prakticky fenoménem. Z původně akademické sítě skládající se ze čtyř uzlů, se stala síť, která v roce 2010 překročila hranici dvou miliard připojených uživatelů. Nejznámější a nejpoužívanější službou v rámci Internetu je World Wide Web (zkratka Www), proto se pro Internet někdy používá označení i „web“ (obrázek 1.1). Internet bude hlavním těžištěm naší práce a je tak nutné se alespoň stručně seznámit s historickým pozadím.

1.1

Vývoj internetu

Tak jako každý úspěšný produkt, i web si prošel několika fázemi vývoje. Popis těchto fází je důležitý hlavně z pohledu vzniku vlastního obsahu, zdali ho tvoří pouze správci stránek, nebo i samotní uživatelé a jak se obsah dále šíří a sdílí mezi uživateli.

1.1.1

Web 1.0

První z fází vývoje se zpětně označuje jako Web 1.0 a definuje web jako množinu počítačů, které jsou navzájem propojeny. Některé z těchto počítačů poskytují data ve formě webových stránek. Uživatel, který je se svou koncovou stanicí rovněž připojen k síti Internet, má k těmto stránkám přístup – může je zobrazovat, ukládat, nebo i měnit. Tento přístup může být buď volný, nebo omezený, například určitým přihlášením. Webové stránky jsou mezi sebou spojeny odkazy, které umožňují uživateli mezi těmito stránky plynule přecházet. Jedná se převážně o jednosměrné poskytování informací, kdy tvůrce webových stránek informace poskytuje a uživatel tyto informace konzumuje, ale žádný obsah nevytváří. Vlastní vytváření obsahu je relativně pomalé a vytvořený obsah většinou zůstává neměnný, statický a šíří se pouze pomocí odkazů, které si uživatelé posílají elektronickou poštou (e-mailem), popřípadě pomocí odkazů uveřejněných ve vlastním textu stránek. 1

1

1. Úvod

Obrázek 1.1: World Wide Web

1.1.2

Web 2.0

Fází Web 2.0 1 označujeme posun od jednosměrné komunikace typu „one-tomany“ ke komunikaci „many-to-many“. Pojem „one-to-many“ značí klasický typ komunikace, kde je jeden autor a více posluchačů. Mimo Web 1.0 se rovněž jedná například o rádiové vysílání, časopisy, filmy, seriály, televizní zpravodajství a další klasická média. Pojmem „many-to-many“ rozumíme situací, kdy se obsah nejenom konzumuje, ale i vytváří a sdílí s ostatními. Každý má možnost psát každému a navzájem se konfrontovat. Obsah je personalizovaný, takže si uživatel sám vybírá, s kým bude komunikovat a jaký obsah bude konzumovat, na rozdíl od novin, nebo televize, kde každý vidí to samé. Do této kategorie lze zařadit jak klasickou komunikaci v reálném světě, tak i sociální sítě na internetu.

1.1.3

Web 3.0

Pojem Web 3.0 2 není ještě přesně definovaný, ale většina lidí chápe Web 3.0 jako sémantický web(15), který se snaží dnešní neuspořádanou množinu webových stránek, proměnit do systému zdrojů, který je určitým způsobem propojen. Každá webová stránka by nejenom poskytovala data pro člověka čitelné, ale také data ve strojově snadno zpracovatelném formátu. Aktuálně je nejpoužívanějším sémantickým formátem RSS, ale jeho použití se omezuje pouze na 1 2

2

Web 2.0 - http://cs.wikipedia.org/wiki/Web_2.0 Web 3.0 - http://cs.wikipedia.org/wiki/Web_3.0

1.2. Internet dnes články, nebo novinky. Většina komunikace mezi více systémy se běžně řeší pomocí aplikačních rozhraní (API), jejichž nevýhodou je, že každé API je jinak definované, takže ke zdrojům nelze přistupovat stejně. Ideu sémantického webu jako první vyslovil(1) (2) autor stávajícího webu sir Tim Barners-Lee3 . Z pohledu dat a obsahu na internetu by byl sémantický web zajímavý možností propojení jednotlivých stránek. A to i stránek, které neposkytují aplikační rozhraní. Uživatel by si například zadal požadavek na vypsání všech lékařů, kteří mají nyní ordinační hodiny a jsou v okolí deseti kilometrů. Webový prohlížeč by načetl seznam lékařů a jejich webové stránky, kde by z každé stránky získal ordinační hodiny a pomocí toho vyfiltroval výsledky. Zbylé lékaře by vykreslil pomocí mapových podkladů včetně nejbližší trasy. Tímto by si uživatel vytvořil takzvaný „End User Mashup“ - tzn. uživatelské propojení zdrojů za účelem získání nějaké informace přímo ve webovém prohlížeči.

1.2

Internet dnes

Dnešní Internet neboli web se nachází ve fázi Web 2.0. Za posledních pár desetiletí došlo k několika změnám, která způsobila, že se z Internetu stal jeden z nejdůležitějších komunikačních a datových kanálů.

1.2.1

Nárůst uživatelů a obsahu

V prvé řadě došlo k rapidnímu nárůstu počtu uživatelů. Je to dané jak cenovou dostupností internetového připojení a cen počítačů, tak i postupným vzděláváním uživatelů. Nyní jsou i starší lidé schopní na internetu vyhledávat informace, nebo je i tvořit. Internet dává lidem možnost, jak mohou mezi sebou komunikovat. Online svět se stal naší přirozenou součástí, každý den hledáme nejnovější zpravodajství, organizujeme události, koukáme na televizní pořady a nakupujeme. Webový prohlížeč se stal nejpoužívanějším programem v počítači. Jako další změnou by šlo označit nárůst prostředků, které umožňují uživatelům obsah vytvářet. Ať už se jedná o sociální sítě, diskusní fóra, nebo i vysokou dostupností publikáčních nástrojů, které jsou zdarma. Uživatel má možnost si nainstalovat kompletní blogovací aplikaci, jako například WordPress, díky které může velice jednoduše vytvářet a publikovat články, fotografie, nebo audiovizuální materiál a sdílet ho s ostatními. Neposlední změnou, která je aktuální jen několik let zpět, je rozšíření mobilního připojení a mobilních zařízení. Díky tomu je část uživatelů připojena k Internetu prakticky pořád. Sdílejí fotky z výletů, společně s jejich přesnou polohou. V restauraci komentují právě dojedený oběd na oblíbené geolokační sociální sítí a každý má možnost si ho před další návštěvou přečíst. 3

Sir Tim Barners-Lee - http://cs.wikipedia.org/wiki/Tim_Berners-Lee

3

1. Úvod

1.2.2

Obsah vytváří hlavně uživatelé

Uživatelé tak nejsou pouze konzumenti obsahu, ale i producenti obsahu – tzv. prosumers. Podílí se nejenom na tvorbě obsahu, ale i na jeho šíření a připojují k nim svoje názory a postoje. Společně s růstem uživatelů roste i počet těchto dat, která uživatelé vytvoří. Z Internetu se pomalu stává neomezený zdroj informací. Existují miliony blogů, rozsáhlá oborové fóra, nebo celé encyklopedie, kde se agregují informace k miliardám slov a témat. Hodně lidí si sílu těchto dat uvědomuje, takže je v posledních letech zaznamenán nárůst webových služeb, vytváření mashupů (aplikace, která spojují výstupy více aplikačních rozhraní služeb dohromady), agregátorů dat a dalších možností, jak z webových stránek udělat zdroje dat, které může jednotlivec, nebo jiná aplikace využít pro svoje potřeby. S rostoucím počtem dat ale také roste potřeba dokázat eliminovat pouze relevantní data, což není jednoduchý úkol.

1.2.3

Sociální sítě

Součástí dnešního webu je i speciální kategorie, které se v posledních letech rozrostla do neuvěřitelných rozměrů, jak z hlediska počtu uživatelů, tak i co se týče generovaného obsahu. Jedná se o sociální sítě (16), což je souhrnné označení pro webové stránky, kde mohou lidé vytvářet určité skupiny a komunikovat spolu. Může se jednat jak o různá diskusní fóra, ale i konkrétní služby, jako je Facebook, Twitter, LinkedIn a další.

Obrázek 1.2: Loga sociálních sítí, zleva Facebook, Twitter, Google, YouTube, Foursquare, LinkedIn, Picasa, atd.

Například Facebook má celosvětově skoro miliardu uživatelů, v České republice pak přes 3 miliony (4). Celosvětový podíl návštěv sítě Facebook v březnu roku 2010 překonal dokonce návštěvnost stránky Google.com, který měl lehce přes 7% (měřeno ve Spojených státech). Twitter má celosvětově přes 100 miliónů uživatelů(7) a z toho 70 tisíc v České republice. Každý z uživatelů této sítě má nějaký názor a má možnost ho velice jednoduše sdílet s ostatními přáteli, nebo lidmi, kteří jej sledují. Sdílet lze nejenom text, ale i video nahrávky, odkazy na jiné stránky, fotografie z dovolené. Také dochází ke spojení uživatelů, kteří by se nemohli fyzicky setkat. Vznikají virtuální komunity, které například spolupracují na open-source projektech. Na těchto sociálních sítích vzniká největší množství uživatelsky generovaných dat. 4

1.3. Monitorování sítí a sběr dat

1.3

Monitorování sítí a sběr dat

Když spojíme všechny aspekty uvedené výše, je nadmíru jasné, že Internet se stal komunikačním kanálem, který nelze ignorovat, a to hlavně sociální sítě, z pohledu vytvářeného obsahu. Některá z těchto dat jsou ale velice důležitá, protože se vztahují k určité události, produktu, nebo osobě. Mohou se také vztahovat k oboru, o který se konkrétní uživatel zajímá a chce se o něm dozvědět co nejvíce informací z jakéhokoli dostupného zdroje. Jsou to vědomosti, názory, ale i problémy pro které někdo hledá řešení. Sociální média jsou ale daleko rychlejší než klasická, takže již není možné je sledovat ručně, jako se to provádí například u novin a časopisů - buď ručně, nebo pomocí služby označována jako „výstřižková služba“. Rovněž vzniká ohromné množství dat, které není možné ručně zpracovávat už vůbec. Vzniká tak požadavek, aby data, která jsou na Internetu, byla monitorována automaticky. Samotná potřeba pro monitoring se pak dá popsat z více pohledů. Vždy záleží, pro jaký účel ho chceme využívat a jaká data chceme sledovat.

1.3.1

Obecné použití

Obecně se dá říci, že monitoring slouží hlavně k účelu sledování určité množiny zájmu. Může se jednat o produkt, politickou situaci, studijní obor fakulty kam se chceme přihlásit, nebo pouze denní zpravodajství. Aby monitoring uživateli poskytl co nejvíce dat, musí sledovat co největší množství zdrojů dat, ale zároveň uživateli zobrazovat pouze data relevantní, která se opravdu vztahují k tématu, který si sám určil. Právě relevance je tím nejtěžším úkolem, což zjistíme několikrát během celé této práce.

1.3.2

Firemní použití

Z pohledu firmy, může určitý názor zákazníka znamenat rozdíl v tom, zda si produkt firmy zakoupí, nebo nikoli. Ale nejenom konkrétní zákazník, ale i přátelé a ostatní lidé, kteří mohou číst názory ostatních na sociálních sítích. Je velice jednoduché zjistit si informace o produktech, značkách, ať již je to lednička, nebo programátorské školení. Lidé ale věří přátelům daleko více než reklamě (10). Pokud si neví rady s nákupem určitého produktu, první místo, kde hledají informaci nebo radu jsou kamarádi, nebo skupiny, v sociálních sítích. Obsah tvořený uživateli je tak velice cenná komodita, a proto je potřeba s ním umět správně pracovat a využít jeho možností. Je nezbytné, aby se firmy přesunuli na sociální sítě, blíže ke svým uživatelům a začali sledovat dění kolem jejich značky a zákazníků, ať už ručně, nebo automatizovaně. 5

1. Úvod 1.3.2.1

Navázání dialogu se zákazníkem

Z pohledu velkých firem mají sociální sítě tu výhodu, že je zde možno daleko lépe navázat dialog se zákazníky. Výhodou například malého pekaře je, že může vytvářet se zákazníky dialog přímo v pekárně a zjišťovat tak zpětnou vazbu, nebo dle jejich přání měnit nabídku produktů. U velkých firem je navázání dialogu v reálném světě prakticky nemožné, protože je zákazníků několikanásobně více a názor je potřeba získat zprostředkovaně (pomocí anket, nebo výzkumů) což ubírá na věrohodnosti. Ale i u velkých firem je potřeba vědět, jaké mají zákazníci přání a názory na současné produkty, takže zde se naskýtá možnost právě sledování komunikace v rámci sociálních sítí. 1.3.2.2

O firmě se již dávno mluví

To, že firma není na sociální síti, nemá nikde vytvořený profil, ještě neznamená, že se o ní nemluví. Pravdou je většinou to, že se o firmě už dávno mluví, aniž by o tom firma věděla. V případě Facebooku nemusí být řešením ani dodatečné založení profilové stránky, protože pokud nebudou mít uživatelé dobré mínění o značce, mohou založit stránku, která bude začínat „Nesnáším firmu ...“. Tato stránka pak může mít třeba 10x více fanoušků, než oficiální stránka firmy o kterou se bude starat dvacetičlenný tým odborníků. Vlastní firemní profil tak ani nezaručuje, že veškerá komunikace o značce bude probíhat automaticky zde. 1.3.2.3

Údaje o zákaznících

Poslední věc z hlediska firmy, která je třeba zmínit je fakt, že na sociálních sítích je mnohonásobně více informací než mají firmy ve svých interních databázích, které budují třeba i desítky let. (9) Uživatelé sociálních sítí dávají volně k dispozici nejenom svoje osobní údaje, ale také místo bydliště a zveřejňují mnoho událostí z běžného života. Tyto data mohou být pro firmy důležitá, pokud se snaží zacílit na přesně definovanou skupinu lidí, například dle věku, místa bydliště, nebo zájmů. Jde tak o nevyčerpatelný zdroj informací o potencionálních, nebo stávajících zákaznících, ale také i o jejich chování v návaznosti na určitou reklamní kampaň, nebo uvedení produktu. 1.3.2.4

Konkrétní případy využití monitoringu pro firmu

Když vezmeme v potaz množství a relevanci dat na sociálních sítích, lze pro firmy monitoring využít z těchto hlavních hledisek: • navázání konverzací a vztahů se zákazníky – být tam, kde jsou zákazníci. • sledování jak se o značce mluví - zda je to převážně kladný ohlas, nebo spíše záporný. A také je nutné vědět, na jakých zdrojích tyto názory vznikají, kde se diskutuje nejvíce, jak hodně se data dále sdílí. 6

1.3. Monitorování sítí a sběr dat • zpětná vazba zákazníků - uživatelé produktů mají většinou spoustu nápadů jak produkt vylepšit, nebo něco udělat jinak. • znalostní báze - pokud firma provozuje například diskusní fórum, uživatelé jí tak pomáhají tvořit znalostní bázi, protože vytvářejí seznam existujících chyb a možných vylepšení. V některých případech na tyto zprávy i uživatelé sami odpovídají. • hlášení chyb (systém včasného varování) - pomocí sociálních sítí dokážou firmy vysledovat, jaký problém mají uživatelé s jejich produktem, a dozví se to řádově dříve, než z jakéhokoli jiného zdroje. Nepřímo tak mají k dispozici miliony testovacích uživatelů. Nemusí ale sledovat pouze svoje produkty, ale i produkty konkurence. Pokud má někdo problém s produktem konkurence, tak mu firma může nabídnout pomoc produktem vlastním. Pokud konkurence sociální sítě nesleduje automaticky, dozví se o tomto problému až o několik hodin (dní) později, kdy už může být pozdě, nebo se to nedozví vůbec. • zrcadlo aktivity na sociálních sítích - pokud firmy řeší problémy pomocí sociálních sítí, monitoring jim pomůže sledovat, jak na tuto pomoc reagují ostatní uživatelé, jestli jí hodnotí kladně, nebo záporně. Může se jednat i o řešení problémů v reálném světě. • sledování reakcí při uvedení produktu na trh – lze tak monitorovat počty nových zákazníků, nebo fanoušku na sociálních sítích v závislosti na uvedení produktu, nebo konání nějaké akce. • nové tržní příležitosti – pomocí monitoringu lze vysledovat nové tržní příležitosti v rámci problémů, které uživatelé mají a který by nový produkt pomohl vyřešit.

1.3.3

Akademické prostředí

Akademické prostředí je hodně podobné firemnímu. Z pohledu školy lze sledovat názory studentů, kteří se na školu teprve chystají, studentů, kteří právě studují, ale i absolventů a veřejné mínění. Sledovat lze jak studijní obory jako celky, nebo třeba samostatné předměty a jejich učitele. Lze porovnávat jednotlivé školy, nebo fakulty mezi sebou. Zjišťovat, co studentům chybí a které předměty jim přijdou již zbytečné.

1.3.4

Osobní použití

I když monitoring sítí vypadá jako ryze firemní nástroj, který slouží k marketingovým účelům, lze použít i pro osobní účely. Z tohoto pohledu lze opět vybrat několik případů, kdy by měl monitoring smysl: 7

1. Úvod • osobní business inteligence - pomocí monitoringu, nebo propojení se sociálními sítěmi, mohu dohledávat informací o lidech, s kterými chci spolupracovat, nebo o budoucím zaměstnavateli. Lze zjišťovat názory bývalých zaměstnanců, nebo lidí, kteří s daným subjektem již spolupracovali. • osobní zpravodajství - každý den se mnoho lidí potýká s problémem, jak z obrovského množství informací, které na Internetu každý den vzniká, vybrat pouze ta data, která uživatele opravdu zajímají. I v případě, že bude uživatel číst pouze oborově zaměřený zpravodajský zdroj, nebude seznam článku tak personalizovaný, aby vyhovoval všem. V tomto případě by šel monitoring využít tak, že by poskytoval uživateli pouze informace, co ho zajímají, bez duplicit, bez nerelevantních dat. Každé téma ideálně obohacené o názory uživatelů a diskuze.

1.3.5

Predikce budoucích událostí

Speciálním využitím může být například predikce budoucnosti. Na Internetu se dá najít několik článků, například o policii NewYork (12), která díky monitorování sociálních sítí dokázala určit pravděpodobné místo budoucího zločinu a opravdu ten den na daném místě odhalila páchání trestného činu. Dále třeba CIA monitoruje(3) denně 5 milionů zpráv ze sociální sítě Twitter a prezidentovi USA tak předává nejdiskutovanější témata dne a předpověď na další dny.

1.4

Cílová skupina aplikace

Nesmíme ale zapomínat, že monitoring sociálních sítí je pořád pouze nástroj a bez potřebně zaškolené obsluhy není možné využít jeho plný potenciál. S nástrojem je potřeba správně pracovat, upravovat ho dle průběžných požadavků a umět interpretovat získaná data pro daný kontext. Cílovou skupinou požadované aplikace tak budou jak jednotlivci, tak různé instituce, které potřebují sledovat například svojí značku, nebo chtějí mít přehled, o čem se diskutuje. Správu aplikace mohou mít na starosti jednotlivci přímo z firem, nebo institucí, které budou tento nástroj využívat, ale také mediální a reklamní agentury, které budou tento nástroj pro daného klienta spravovat a budou mu poskytovat buď surové výsledky, nebo přímo zpracované reporty v určených intervalech. Protože se jedná pouze o nástroj, a vzhledem k tomu, že aplikace bude implementována spíše pro potřeby firmy, nebo akademické organizace, bude moct aplikaci obsluhovat pouze člověk, který bude dostatečně obeznámen s fungováním, správou aplikace a vůbec s fungováním sociálních sítí a chováním jejich uživatelů. Tento uživatel musí rovněž umět pracovat s výstupy, které mu aplikace poskytne a umět je tak srozumitelně zpracovat.

8

Kapitola

Analýza V předchozí části jsme si popsali aplikaci, kterou chceme realizovat. Máme tak definované pouze hrubé požadavky, co by měla aplikace zvládat a cílovou skupinu, která bude s aplikací pracovat. Toto vše poslouží jako vstup pro následující část, kde bude podrobně provedena analýza požadavků a to jak funkčních, tak i nefunkčních. Dále budou sestaveny případy užití, definována cílová skupina a sestaven seznam zdrojů, které by bylo dobré sledovat. Navrženy uživatelské role a vytvořena základní kostra grafického návrhu (drátěné modely). Jedna z nejdůležitějších částí analýzy bude rozdělení systému na menší celky. To nám pomůže celý složitý systém dekomponovat a řešit tak každou část zvlášť, což je daleko jednodušší, než zkoumat systém jako celek najednou. Výstupem této analytické části budou uživatelské role, návrh uživatelského rozhraní a případy užití, které budou sloužit pro implementaci jednotlivých funkcí aplikace v dalších částích.

2.1

Požadavky na aplikaci

Navrhovaná aplikace bude tedy určena pro monitoring sociální sítí jako je např. Facebook, Twitter, ale i různé články a diskusní fóra. Hlavní funkcí systému bude sledování vybraných zdrojů v rámci sítě Internet a následné zobrazení nalezených výsledků dle zadaných klíčových slov a slovních spojení, která lze sdružovat do přehledných témat. Aplikace bude zaměřena primárně na české prostředí. Požadavky lze rozdělit na hlavní funkce, které budou jádrem aplikace, dále doplňkové funkce a nakonec volitelné rozšíření, které se mohou implementovat v budoucnosti. Taková aplikace lze využít k velice široké škále použití, zůstává tak na nás, která data budeme sledovat a následně analyzovat. Proto je důležité si ujasnit, jaké požadavky na nástroj budeme mít a dle toho si zvolit vhodný produkt, nebo si nástroj upravit tak, aby poskytoval výstupy, které budou opravdu v našem zájmu. Vedle vlastností je potřeba definovat i zdroje, odkud budeme 9

2

2. Analýza data sbírat. Pro určitý segment bude potřeba sledovat přednostně sociální síť Twitter, ale pro jinou oblast by to třeba již smysl nemělo a budeme se chtít zaměřit spíše na jiný zdroj. Požadavky nejdříve rozdělíme na funkční a nefunkční. Funkční požadavky dále rozdělíme na základní, rozšiřující a volitelné, spíš jako výčet možných rozšíření, nebo nadstavbových funkcí.

2.1.1 2.1.1.1

Obecné požadavky – nefunkční Dostupnost

Aplikace musí být dostupná kdykoli a nejlépe i kdekoli (na jakémkoli zařízení, které je připojené k Internetu). Pro toto použití by nejlépe posloužilo psát aplikaci jakou webovou, kde rovněž odpadají problémy s aktualizací produktu a při správné volbě platformy odpadají také problémy se škálovatelností. 2.1.1.2

Rychlost

Aplikace musí data poskytovat relativně rychle, tak aby měla obsluha dostatek času reagovat. Z tohoto pohledu bude kladen důraz na krátké intervaly mezi načítáním dat a jejich vlastním vyhledávání. Rovněž by bylo vhodné implementovat upozornění pomocí e-mailových zpráv, aby se varování dostalo k uživateli co nejdříve. 2.1.1.3

Přehlednost

Aplikace musí být přehledná, aby byla data poskytována v jednoduché formě a pro člověka, který s aplikací pracuje, bylo co nejsnazší získat požadované výstupy. Z tohoto důvodu budu na začátku analytické sekce provádět analýzu uživatelského rozhraní (UI – User Interface) a návrh prototypu aplikace, který pomůže odhalit určité problémy, nebo nedostatky co se obsluhy aplikace týče. Výsledkem by mělo být přehledné, intuitivní a rychle ovladatelné rozhraní. 2.1.1.4

Rozšiřitelnost

Aplikace musí být snadno rozšířitelná a musí počítat s tím, že témat a klíčových slov může být veliké množství a časem budou přibývat. Stejně tak se mohou přidávat sledované zdroje. Navigace v rámci aplikace by tedy neměla být omezená na počet možných položek. 2.1.1.5

Relevance

Systém musí poskytovat co nejvíce relevantní data, aby se uživatel, který s aplikací pracuje, mohl na výsledky spolehnout a nemusel je ručně kontrolovat. 10

2.1. Požadavky na aplikaci 2.1.1.6

Automatické zpracování

Aplikace musí v co největší míře automatizovat rutinní operace, aby uživatel měl co nejméně práce s její obsluhou. Jedná se jak o sběr dat, tak i upozorňování na nastavené situace, například zvýšený výskyt určitého klíčového slova. Bylo by vhodné, aby aplikace vytvářela i základní grafy, které budou ukazovat, z jakého zdroje pochází nejvíce záznamů. Pro složitější analýzu by měl být k dispozici export dat do standardních datových formátů. 2.1.1.7

Lokálnost, globálnost

Pokud bereme v potaz například Českou Republiku, je nutné být lokální – monitorovat většinu nejsledovanějších místních zdrojů, nebo zdroje sousedních zemí, pokud by data mohla být relevantní (například Slovensko). Zároveň je nutné být globální, nesledovat pouze lokální zdroje, tak i celosvětové zdroje dat, například Facebook, Twitter, YouTube, protože i zde se mohou pohybovat uživatelé, kteří jsou pro nás důležití.

2.1.2

Specifické požadavky – funkční

Nyní si definujeme funkční požadavky, které vyplývají z popisu toho, co by měla aplikace umět. Požadavky rozdělíme na základní, které budou tvořit jádro aplikace. Dále na požadavky rozšiřující, které jsou nadstavbou na základní řešení a poskytují určité rozšířené možnosti. Nakonec to budou požadavky volitelné, spíše jako výhled pro budoucí rozšíření aplikace a zmínění různých možností využití. 2.1.2.1

Základní požadavky

Základním požadavkem na aplikaci je tedy monitorování sociálních sítí. Uživatel musí mít možnost zvolit zdroje, které chce sledovat. Dále musí mít možnost vytvořit obory zájmu (témata) a navolit klíčová slova, která budou tyto obory definovat. Nalezené výsledky musí mít možnost filtrovat. Pro tuto základní funkcionalitu nadefinujeme první klíčové požadavky: 1. Víceuživatelské prostředí. • Aplikace musí být víceuživatelská, aby si každý uživatel mohl nadefinovat své sledované zdroje a klíčová slova. Zároveň bude mít aplikace centrální administraci, pro správu všech uživatelů, všech témat a klíčových slov všech uživatelů. 2. Zadání sledovaných zdrojů. • Aplikace musí umožňovat zadat, nebo vybrat sledované zdroje, které pak bude aplikace procházet a následně zobrazovat nalezené výsledky. 11

2. Analýza 3. Aplikace umožní zadání klíčových slov a témat, kam se budou klíčová slova slučovat. • Zadání témat – systém musí umožnit zadání témat, které budou definovat určitý obor zájmu. Pro každé téma bude možnost vybrat zdroje, které se mají sledovat. • Zadání klíčových slov – každé téma musí mít možnost přidání klíčových slov a spojení, které dané téma vystihuje. Podle těchto slov bude systém vyhledávat záznamy. 4. Aplikace umožní nasbíraná data filtrovat. • Dělení dle tématu – možnost vypsat pouze záznamy, které přísluší danému tématu. • Dělení dle zdroje – výpis pouze záznamů z daného zdroje. • Kombinace bodů výše – možnost filtrovat záznamy jak podle zdroje, tak i dle tématu. 5. Aplikace musí mít možnost data vizualizovat. • Nalezená data musí být prezentována ve srozumitelné formě a to přehlednými tabulkami, nebo grafy. 2.1.2.2

Rozšiřující požadavky

Rozšiřující požadavky budou vystavěny na základní systém a nemají tak přímý vliv na fungování základní aplikace. • Detail záznamu – pro každý záznam bude možno vypsat všechna data, která aplikace o zvoleném záznamu uchovává. • Provázanost aplikace – možnost zobrazení záznamů stejného autora, nebo ze stejného zdroje. • Export dat – nakonec musí mít aplikace možnost export syrových dat do snadno zpracovatelných formátů jako je CSV, XML. 2.1.2.3

Volitelné požadavky

Níže zmíníme souhrn volitelných požadavků, z nichž některé budou možná zpracovány do této práce, nicméně pokud by byl nástroj úspěšný, určitě by se tyto požadavky měli postupně do systému v budoucnosti zapracovat. Některé z požadavků by šlo prozatím řešit tak, že se data vyexportují a následná analýza bude probíhat ve specializovaném nástroji. 12

2.2. Dnešní možnosti monitoringu a sběru dat 1. Analýza konkurence – možnost stanovení poměru diskusí o klientovi vůči diskusím o jeho konkurentech, tzn. na jakých serverech je která konkurenční firma/služba v jakých souvislostech diskutována. 2. Sentiment (emociální vyznění) - možnost manuálního určení sentimentu zpráv a následná vizualizace míry jednotlivých sentimentů v rámci sledovaných zdrojů a témat. 3. Relevance dat – schopnost filtrování výskytů, které nejsou obsažné, zajímavé nebo přínosné. Možnost odstraňovat určité výskyty, označit je jako nerelevantní. Aplikace by toto označení zohlednila při dalším hledání. 4. Dohledávání kontextu zpráv – zobrazení zpráv, které sice již neobsahují navolená klíčová slova, ale mají návaznosti. Např. odpovědi, které se vztahují na zobrazený diskusní příspěvek. 5. Podrobnosti o nejaktivnějších diskutérech (opinion makers/leaders), vazby mezi diskutéry, jejich oblíbená témata, míra vlivu podle počtu příspěvků, podle počtu Přátel na Facebooku a Followers na Twitteru, podle doby uplynulé od registrace autora na určitém serveru apod., ideálně i včetně socio-demografických údajů (pohlaví, věk, bydliště) a kontaktů, které o sobě lidé zveřejňují v internetových profilech (cílem je mj. identifikace povolání/zaměstnavatele jednotlivých diskutérů s cílem odhadnout jejich autoritu v oboru dané diskuse). 6. Sledování návštěvnosti – propojení monitoringu s nástrojem sledování návštěvnosti (Google Analytics), pro vyhodnocení míry prokliku odkazů z publikovaných záznamů, například odkazu na firemní produkt. 7. Filtrování dle lokace - úzce zaměřené offline reklamní kampaně, slevy v různých městech. 8. Webová služba – aplikace by měla poskytovat webovou službu pro export nasbíraných dat pro možnost integrace s dalšími produkty.

2.2

Dnešní možnosti monitoringu a sběru dat

V době dnešního Webu 2.0 lze automatizovaný monitoring realizovat několika způsoby. Rozdíl je vždy v tom, jakým způsobem služba, kterou chci sledovat, data poskytuje. Možnosti hrubě rozdělíme na: • Web crawling – procházení přímo vygenerovaného HTML kódu, kde se míchají jak čistá data, tak HTML značky a stylování stránky. • Webová služby – získávání dat pomocí aplikačních rozhraní (API), nebo speciální XML exporty dat. 13

2. Analýza • RSS/Atom kanály – dnes nejpoužívanější formát pro strojovou spolupráci mezi jednotlivými stránkami. Nevýhoda je na první pohled patrná, s každým zdrojem je nutno nakládat individuálně, buď využít jeho aplikační rozhraní (API), nebo čerpat z dat, které dává stránka volně k využití, například RSS kanál článků. Když stránka neposkytuje ani jednu z těchto možností, je pak možno data získávat stahováním přímo HTML stránky, ale i zde jsou velice omezené možnosti, jak data strojově zpracovat.

2.2.1

Budoucnost monitorování

Východiskem z těchto problémů by mohl být až Web 3.0, který byl zmíněn v úvodní části. Ke každé stránce by se přistupovalo unikátně a s daty by se tak mohlo pracovat mnohem snadněji. Každý uživatel by si tak přímo ve svém prohlížeči mohl propojit jakékoli webové zdroje za účelem získání dat. Stejně tak snadno, by šlo zdroje monitorovat a přistupovat ke každému stejným způsobem, za účelem získání dat.

2.3

Seznam sledovaných zdrojů

Vzhledem k tomu, že nelze sledovat celý Internet, musíme definovat, které sítě a stránky budeme sledovat. Zkusíme tedy vybrat sítě, kde se nachází naše cílová skupina a aktivně zde komunikuje, diskutuje a sdílí data. Pomůže nám to rovněž získat relevantní a kvalitní data pro naši aplikaci. U každé sítě musíme definovat, jakým způsobem budeme se sítí komunikovat a získávat potřebná data. Důležité je také vědět, zda je potřebný nějaký druh autorizace, nebo jsou data volně přístupná. Pro monitoring je nutné načítat data z více zdrojů, aby nebyla celá aplikace závislá na jednom zdroji dat, který když přestane fungovat, nebo neumožní načítání dat, znamenalo by to pro monitoring celkové přerušení sběru dat a postupný konec, protože by se vyhledávalo pouze v uloženém archivu záznamů. Uvedeny budou i zdroje, které sledovat nebudeme, ale jsou vhodnými kandidáty na budoucí rozšíření aplikace. Zdroje seřadíme alespoň přibližně podle počtu uživatelů od největší.

2.3.1

Facebook.com

Sociální síť Facebook je z pohledu počtu uživatelů největší sítí na celém Internetu. Svůj profil zde má skoro 1 miliarda lidí. Síť je uzavřená, takže je nutné se zaregistrovat a přihlašovat, ale pro čtení některých veřejných dat není registrace nutná. Facebook mimo uživatelských profilů nabízí také tvorbu skupin (Groups) a stránek (Pages). 14

2.3. Seznam sledovaných zdrojů 2.3.1.1

Stránky

Stránky jsou volně přístupné a poskytují většinou informace o nějakém produktu, instituci, nebo jednotlivci (např. umělci). Slouží jako vyjádření sympatie, takže pro „spojení“ svého profilu se stránkou se používá speciální tlačítko „Líbí se mi“. Tento vztah je jednostranný, není potřeba potvrzovat od administrátora stránky. Výhodou stránek je, že mohou být i volně přístupné bez přihlášení do sociální sítě. Vzhledem k tomu, že by monitoring měl být částečně zaměřený na akademické prostředí, budou pro naše využití zajímavé stránky, které se nějakým způsobem týkají Fakulty informačních technologií4 , nebo celého ČVUT5 a budeme je chtít sledovat. 2.3.1.2

Skupiny

Skupiny jsou speciální druh Facebook stránek, které mají omezené členství, takže pro vstup do této skupiny je potřeba schválení administrátora skupiny. Hodí se pro tvorbu uzavřených skupin, například pracovní skupina, studijní skupina určitých žáků a slouží převážně pro výměnu interních informací. Data ze skupin nejsou bohužel přístupná bez přihlášení a schválení, takže nejspíš nebude možno je vůbec sledovat.

2.3.2

Twitter.com

Sociální síť Twitter je podstatně menší síť jak Facebook, má „pouze“ 100 miliónů uživatelů. Často se o ní mluví jako o mikroblogovací službě, umožňuje totiž posílat pouze zprávy o délce maximálně 140 znaků. Všechny vztahy na Twitteru jsou jednostranné, takže každý může sledovat kohokoli (pokud nemá nastavený profil jako privátní) a tento vztah není potřeba potvrzovat. V České republice moc aktivních uživatelů není, odhad je kolem 70 tisíc, ale na druhou stranu jsou to většinou uživatelé technického typu, kteří se aktivně zajímají o dění na internetu a dále také novináři, kteří využívají flexibility a rychlosti této sítě. Na Twitteru najdeme jak osobní účty, tak i firemní účty. Vzhledem k tomu, že u každé zprávy lze zmínit i přímo profil jiného uživatele nebo firmy, pomocí znaku zavináče (např. @Vodafone_cz) je pro firmy velice důležité sledovat Twitter, pokud se třeba stane, že má někdo problém s firemním produktem a chce na to pomocí Twitteru upozornit přímo pomocí zavináče a názvu firmy. Na Twitteru lze hledat buď pomocí klíčových slov, nebo sledováním tzv. hashtagů, což je akorát klíčové slovo doplněné na začátku o znak # a označující tak určité téma (jistý druh manuální anotace). Fakulta informačních technologií vlastní Twitter účet nemá, ale i tak můžeme hledat zprávy pomocí 4

https://www.facebook.com/pages/Fakulta-informa%C4%8Dn%C3%ADchtechnologi%C3%AD/167431340661 5 Facebook stránka Sedm Statečných - https://www.facebook.com/sedm.statecnych

15

2. Analýza hashtagů #cvut #fit. Dále můžeme sledovat příbuzné účty, např. účet Sedm statečných6 .

2.3.3

Pinterest.com

Pinterest je nejmladší z uvedených sociálních sítí, ale již nyní je 3. největší sociální sít ve spojených státech amerických(6). Jedná se o virtuální nástěnku, kde lze umisťovat převážně obrázky a fotky, ať už nahráním, nebo pomocí odkazu. Každý uživatel si může vytvořit několik svých nástěnek a zároveň vidí nástěnky všech ostatních. Ke každému obrázku lze pak přidávat komentáře, označit je jako oblíbené, nebo je umístit (přišpendlit) na své nástěnky. Přišpendlené obrázky lze pak dále sdílet a to jak pomocí odkazu, tak i pomocí dalších sociálních sítí. Služba je oblíbená u módních návrhářů, architektů, nebo lidí, kteří rekonstruují svůj byt, protože zde mohou agregovat obrázky oblečení, nebo bytových doplňků a vytvářet si tak své soukromé kolekce. Pro naše použití bude Pinterest zajímavý hlavně z hlediska textového obsahu, tzn. popisku fotografií a komentářů. Nehodí se však jako hlavní informační zdroj, ale pouze doplňkový, který najde využití pouze u některých sledovaných témat. Můžeme sledovat šíření fotografií nějakého produktu, nebo osobnosti. V současné době má Pinterest problémy s autorským právem, protože dochází ke sdílení i těch obrázků, které podléhají licenci a sdílení neumožňují.

2.3.4

Foursquare.com

Sociální síť Foursquare je geolokační služba, která umožňuje vkládat komentáře k místům, které existují v reálném světě. Jedná se především o restaurace, památky, významné instituce, školy, nebo sportovní stadiony. Lidé mohou označit, že se na daném místě právě nacházejí a mohou dále vložit komentář, nebo fotografii. Komentovat lze například právě dojedený oběd, nebo hodnotit vystoupení umělce. Vzhledem k tomu, že je služba sociální, každý uživatel má své virtuální kamarády, kteří vidí polohu místa, kde se uživatel naposledy přihlásil. Komentáře k objektům, ale vidí všichni uživatelé služby, kteří si dané místo zobrazí. Stejně jako Pinterest, tak i k Foursquare budeme přistupovat jako k doplňkovému zdroji a bude pro nás zajímavý v případě, pokud budeme chtít například sledovat restauraci a komentáře lidí, kteří restauraci již navštívili. Nebo se může jednat o restaurace konkurenční firmy. Získaná data jsou pak vysoce relevantní, protože se vztahují přímo ke konkrétnímu místu a uživatelé místo navštěvují s jasně definovaným záměrem. 6

16

https://twitter.com/#!/sedm_statecnych

2.3. Seznam sledovaných zdrojů

2.3.5

Flickr.com

Flickr je stejně jako Pinterest založený na sdílení obrázků. Na rozdíl od Pinterestu je ale výrazně starší (od roku 2004) a uchovává více jak 5 miliard obrázků. Funguje částečně také jako fotobanka, protože hodně fotek je zde umístěno s licencí, která umožňuje další využití. Zajímává je možnost tagování fotografií (každé fotografii lze přiřadit jeden nebo více tagů, což jsou jednoslovné popisky, které vystihují fotografii) a jedná se tak o určitou formu manuální anotace, která následné zjednodušuje vyhledávání na základě klíčových slov. Nám to pomůže při hledání, abychom našli co nejvíce relevantní záznamy.

2.3.6

YouTube

YouTube (nyní již ve vlastnictví společnosti Google) spíše než sociální sítí je stránka, kde má každý možnost nahrávat a sdílet videa. YouTube ale také umožňuje vytvářet určité profily a tímto si tak každý může udělat svůj kanál, kde publikuje nahraná videa a ostatní uživatelé mohou tento kanál sledovat. Pro monitoring je tato síť zajímavá hlavně z důvodu, že vložená videa lze komentovat a můžeme tak sledovat vložené komentáře, nebo případně tagy, stejně tak jako u sítě Flickr.

2.3.7

Google+

Google+ je relativně nová sociální sít, která je hodně podobná síti Facebook. Zaměřuje se na sdílení prakticky jakéhokoli obsahu, počínaje textem, přes obrázky, videa, zvuk a polohu uživatele. Aktuálně (duben 2012) má síť přes 100 miliónů uživatelů (5). Stejně jako na síti Facebook lze i zde vytvořit buď osobní profil, nebo firemní stránku. Síť je zajímavá hlavně z hlediska integrace ostatních služeb z portfolia společnosti Google, ale v České republice se zatím moc neujala. Pro naše využití by bylo dobré ze sítě zaznamenávat všechny komentáře a textový obsah, který uživatelé vytvoří, anebo vyhledávat podle klíčových slov, která budou navolena v nastavení monitoringu.

2.3.8

RSS kanály

Informace dostupné přes RSS/Atom kanály budou pro nás asi největším zdrojem dat. Nejedná se sice o sociální sítě, ale můžeme tak sledovat všechny dostupné blogy, zpravodajství, komentáře a diskuze. Velkou výhodou RSS kanálů je to, že si explicitně určíme, jaké zdroje budeme sledovat a tím i vyfiltrujeme velké množství nezajímavých zdrojů. Což je zároveň nevýhoda, protože stejně tak můžeme nějaký důležitý zdroj přehlédnout. Diskusní fórum FIT7 by pro naše účely mohlo být největším zdrojem in7

https://forum.fit.cvut.cz/index.php

17

2. Analýza formací, protože právě zde mají zprávy největší informační hodnotu pro akademické využití nástroje. Diskusní fórum vyžaduje registraci a přihlášení, ale pouze pro psaní nových příspěvků. Čtení je veřejně dostupné všem. Dále budeme sledovat co nejvíce ostatních diskusních fór přes co nejširší spektrum oborů, počínaje financemi (Peníze.cz, Mesec.cz) přes denní zpravodajství (iHNed.cz, iDnes.cz) až po různě zaměřené blogy a to jak firemní, tak osobní.

2.4

Rešerše existujících řešení

Komplexních systémů pro monitorování sociálních sítí a Internetu vůbec existuje několik desítek a to převážně zahraničních. V českém prostředí by se takové systémy daly spočítat na prstech jedné ruky a jsou převážně určeny pro velké firmy, které mají na propagaci značky a správu sociálních sítí většinou vyhrazeno celé separátní oddělení. Zmiňované systémy tedy rozdělím na ty české a pak zahraniční, protože české nástroje jsou specializované na lokální trh a dokážou tak zpracovat i specifika českého jazyka.

2.4.1

Nespecializované nástroje

Nejdříve ale uvedu nástroje, které se mohou hodit pro základní monitoring, a které jsou zdarma dostupné pro každého. 2.4.1.1

Google vyhledávání

Nejjednodušší nástroj pro monitoring je vyhledávač Google. Není nic jednoduššího, než si zadat název naší firmy do vyhledávače a podívat se, kde se o firmě píše. Výhodou tohoto řešení je, že je zdarma a není potřeba nikam se registrovat, nic instalovat. Zvládne to prostě každý. Google umí indexovat jak webové stránky, tak i textové dokumenty v různých formátech, třeba Doc, nebo PDF. Nevýhodou je, že se nejedná o automatizované řešení a nelze specifikovat zdroj dat, ani s daty nijak dále pracovat. Nelze určit, z jakého zdroje pochází nejvíce výsledků, jaká je míra jednotlivých klíčových slov. Google vyhledávání neposkytuje ani žádné grafy a reporty. 2.4.1.2

Konkrétní vyhledávání pro každou síť

Stejně jako Google vyhledávání, tak pro vyhledávání na konkrétních sítích lze využít přímo vyhledávací rozhraní každé služby, například pro Twitter je to Twitter Advanced Search8 , pro blogy je to Google Blog Search9 . Opět se nejedná o automatizované řešení a je nutné procházet každou síť samostatně. 8 9

18

https://twitter.com/#!/search-advanced http://www.google.com/blogsearch

2.4. Rešerše existujících řešení 2.4.1.3

Google Correlate

Další volně dostupný nástroj se jmenuje Google Correlate10 a umožňuje vyhledávat zadaná klíčová slova, ke kterým zobrazí další související klíčová slova, která se zadaným korelují. Zároveň zobrazuje míru vyhledávání v časovém úseku. Pokud například vyhledáme slovní spojení „losing weight“11 (volně přeloženo „jak zhubnout“), vidíme, že nejvíce koreluje s vyhledáváním spojení „burn calories“ (spalování kalorií) a také to, že nejvíce je toto spojení vyhledávané na začátku roku, kdy si lidé dávají nejvíc předsevzetí. Kromě nutnosti manuálního vyhledávání je další velkou nevýhodou to, že produkt funguje pouze na anglický jazyk. 2.4.1.4

Google Trends

Nástroj Google Trends zobrazuje vývoj četnosti hledání vybraných dotazů – klíčových slov, kterých může být více najednou a lze je porovnávat mezi sebou. Lze například pozorovat, jak se zvýší zmínky o nějakém produktu při jeho uvedení, nebo nárůst výsledků u nějakých významných událostí. Aplikace umožňuje export do CSV formátu a funguje i na české výrazy, protože sleduje daná klíčová slova jako řetězce, nezávisle na jazyku. Nefunguje tak skloňování, ani žádná forma automatizace (upozorňování na e-mail) ani porovnávání na úrovni jednotlivých zdrojů dat. 2.4.1.5

Google Insights for Search

Google Insights for Search je pro nás daleko zajímavější. Umí totiž navolit skupiny klíčových slov, které se dají porovnávat mezi sebou. Výskyty se dají filtrovat dle zdroje výskytu (vyhledávání, novinka, obrázek), času publikace ale také dle země a dokonce dle regionu v rámci zvolené země. Pokud si do aplikace navolíme například nějaké produktové značky, můžeme sledovat, o jaké značce se mluví nejvíce a jaká klíčová slova nejvíce převažují. Nevýhodou je, že vše se musí provádět manuálně. Velikou výhodou, stejně jako u všech produktů Google, je hlavně obrovské množství dostupných dat. 2.4.1.6

Rapportive

Produkt s názvem Rapportive je tak trochu speciální, nejedná se o žádnou webovou stránku, ale o plugin do prohlížečů Firefox, nebo Chrome. Využití najde hlavně pro osobní business inteligence. Umožňuje totiž v e-mailovém klientu Gmail, u každého kontaktu zobrazit další informace ze sociálních sítí. Spíš než monitoring se tak jedná o agregátor sociálních sítí, ale v určitých případech nám dokáže pokrýt požadavky, které budeme mít i na monitoring, např. dohledávání informací o konkurenci, o budoucím zaměstnavateli apod. 10 11

http://www.google.com/trends/correlate http://www.google.com/trends/correlate/search?e=losing+weight&t=weekly#

19

2. Analýza

2.4.2

České specializované nástroje

Následuje seznam českých nástrojů, které se specializují přímo na monitoring sociálních sítí, nebo je to jejich majoritní funkcí. 2.4.2.1

Ataxo Social Insider (www.ataxosocialinsider.cz)

Placené řešení české firmy umožňující monitorování sociálních sítí a vybraných blogů v českém prostředí. Nasbíraná data firma částečně poskytuje veřejně, konkrétně data ze sociální sítě Twitter a to na webové stránce klaboseni.cz, viz odstavec níže. Služba v základu poskytuje možnosti monitorování určitých skupin klíčových slov, neboli témat, jejich filtrování, vizualizaci a následnou analýzu. Tyto základní služby jsou doplněny možností exportování zobrazených údajů, upozornění na email, anebo na telefon, pokud aplikace objeví při procházení určité klíčové slovo v častějším výskytu. Dále využití logických operátorů u vyhledávání a označování zpráv sentimentem. Základní verze aplikace stojí 9.950,- Kč měsíčně a je omezená na 30 klíčových slov s aktualizací každé čtyři hodiny. Rozšířená verze stojí 19.500,- Kč měsíčně, je omezená na 100 klíčových slov a data se aktualizují každou hodinu. Technologicky je produkt postavený na ElasticSearch, což je fulltextový vyhledávací nástroj a zmíníme ho v návrhové části práce. Tato aplikace bude z pohledu funkcí nejpodobnější mnou realizované aplikaci. Nevýhodou je hlavně vyšší cena. 2.4.2.2

Klaboseni.cz

Webová stránka Klábosení je produktem společnosti Ataxo, stejně jako výše zmiňovaný Ataxo Social Insider, ale poskytuje výstup nasbíraných dat pouze ze sociální sítě Twitter. Klábosení disponuje daty z českého a slovenského Twitteru a umožňuje vyhledat zprávy na základě zadaných klíčových slov, nebo hashtagů. Nyní archivují více jak 20 miliónů záznamů od necelých 100 tisíc uživatelů. Lze využít hlavně pro vyhledávání určitých klíčových slov a dále lze také dohledávat pokročilé informace o konkrétním uživateli. Výhodou je, že je zdarma dostupný každému. Nevýhodou je zaměření pouze na sociální síť Twitter a nemožnost nastavit si určitou formu email upozornění, nebo RSS kanálů pro sledování vybraných klíčových slov. 2.4.2.3

Wunderman Listening Platform – Wlip (wlip.cz)

Produkt Wunderman Listening Platform nabízí stejně jako Ataxo Social Insider možnost monitorování sociálních sítí a dle specifikací vypadá produkt velice podobně. Bohužel se mi nepodařilo zajistit testovací přístup do aplikace, a firma Wunderman neposkytuje žádný testovací náhled aplikace, nebo 20

2.4. Rešerše existujících řešení podrobnou specifikaci. Z globálního pohledu působí celý ekosystém kolem produktu Wlip nedodělaným dojmem a dle blogu produktu je zatím v testovací fázi. 2.4.2.4

Newton Media (www.newtonmedia.cz)

Firma Newton Media se v oboru sledování médií pohybuje již od roku 1993 a to již s výstřižkovou službou, která byla takovou „off-line“ verzí monitoringu médií. V oblasti sledování sociálních sítí a internetu vůbec, tak dnes Newton IT pokrývá zhruba polovinu českého trhu (8). Newton nabízí dva produkty a to Monitoring Sociálních Sítí (MSS), který monitoruje sociální sítě Facebook, Twitter a vybrané blogy. Dále nabízí produkt Internet Media Monitoring (IMM), který sleduje internetové zdroje klasických médií jako je denik.cz, zena.cz, idnes.cz. Co se týče funkcí dle specifikace, tak ve srovnání s Ataxo Social Insider, nabízí pouze základní zobrazení nalezených článků, nebo statusů. Aktualizace probíhá pouze jednou denně. Na druhou stranu je produkt zaměřený nejenom na Českou republiku, ale i na Slovensko a Polsko. Monitoring Sociálních Sítí stojí měsíčně 1.700,- Kč a za každé další sledované slovo zaplatíme 1.500,- Kč. Internet Media Monitoring stojí měsíčně kolem 3.000,- Kč měsíčně a za každý nalezený článek zaplatíme 6,- Kč, ale výhodou je, že počet klíčových slov není limitovaný. 2.4.2.5

eMerite VOBID (http://www.emerite.cz/vobid)

Tento produkt využívá Ataxo Social Insider a rozšiřuje ho, resp. přizpůsobuje svým klientům. Poskytují rozsáhlejší statistické údaje, vazby mezi nalezenými údaji a posouzení různých vlivů, např. nejaktivnějších diskutérů. Využívají také statistiky návštěvnosti z nástrojů jako třeba Google Analytics pro výpočet konverzního poměru návštěvníků přicházející ze sledovaných diskuzí.

2.4.3

Shrnutí českého prostředí

V českém prostředí nabízejí nástroje pro monitoring sociálních sítí pouze pár firem z čehož je nejstarší řešení je od firmy Newton a hned po něm Ataxo Social Insider. Všechny uvedené produkty jsou placené a v základním režimu neumožňují omezit seznam prohledávaných zdrojů na ty, které samostatně vybereme. Nelze tak v jednom tématu sledovat pouze fórum fakulty informačních technologií. Všechny nástroje jsou webové aplikace. Ani jedna ze služeb neposkytuje veřejný výstup v podobě aplikačního rozhraní, ani export v XML (RDF), takže data nelze využívat pro účely vlastní aplikace a bude nutné je sesbírat samostatně. Všechny zmiňované placené produkty zastřešují mediální firmy, které službu monitoring sociálních sítí poskytují v komplexním balíku služeb, zahrnující i komplexní mediální analýzy s využitím právě dat z monitoringu. 21

2. Analýza

2.4.4

Zahraniční specializované nástroje

V zahraničí jsou nástroje pro monitorování sociálních sítí daleko více používány, což se také projevuje na jejich množství. Zkusím zde uvést alespoň ty největší, nebo nejvíce zajímavé služby. Mezi zahraniční řadím globální produkty, tzn. i české produkty, které nejsou pouze na lokálním trhu. V seznamu nejsou uvedeny služby, které umožňují pouze zobrazit výsledky na zadané klíčové slovo. Od aplikace vyžaduji alespoň základní možnosti filtrování a agregace. Většina z nástrojů není pouhý monitoring, ale jedná se i o integraci více nástrojů, například CRM. 2.4.4.1

Radian6 (http://www.radian6.com/)

O tomto produktu se píše na zahraničních zdrojích prakticky nejvíce. Vzniknul již v roce 2006 a začátkem roku 2011 byl koupen společností Salesforce.com za 326 miliónů dolarů (11). Produkt Radian6 nabízí stejně jako český Ataxo Social Insider sledování sociálních sítí, blogů a diskuzních fór. Spojením se stávajícím produktem Salesforce by měl vzniknout produkt pro správu vztahů se zákazníky, který bude poskytovat daleko přesnější a propracovanější analýzu pro práci s potenciálními zákazníky. Umožní jim lépe naslouchat a reportovat případné problémy. Řešení Radian6 je systém pro monitorování sociálních sítí. Nenabízí ovšem jen data-miningové funkce, ale umožňuje i přímou interakci na vybrané příspěvky v reálném čase. Také podporuje bussiness intelligence ve formě zpracovaných statistik z dat vzešlých ze sledování sociálních sítí. 2.4.4.2

Lithium (http://www.lithium.com/)

Lithium je zaměřené zejména na oblasti sociálního marketingu a komerce. Řešení jsou rozdělená do několika oblastí. Community platform - služba péče o stávající zákazníky, umožňuje interakci zákazníků se zaměstnanci firmy přes sociální sítě, jak je to pro zákazníky přirozené. Cílem jsou spokojení zákazníci, ale také rozšíření povědomí o firmě skrze ně a jejich aktivitu na sítích, která je viditelná jejich přátelům. Social media monitoring – pro nás asi nejzajímavější řešení, které hledá zmínky o firmách a produktech na sociálních sítích. Umožní zaměstnancům efektivně zareagovat a v ideálním případě přímo do daného diskusního vlákna. Customer Intelligence Center - vyhodnocuje efektivitu a úspěšnost kampaní podle toho, jak zákazníci reagují na sociálních sítích. 2.4.4.3

Jive (http://www.jivesoftware.com/)

Tento produkt nabízí nejkomplexnější služby v oblasti Social CRM a má tak nejlepší pozici v Gartner magickém kvadrantu. Social CRM je více než sa22

2.4. Rešerše existujících řešení motný monitoring, jedná se o kompletní propojení sociálních sítí a firemních nástrojů. Vlastní monitoring je tak pouze jednou částí. 2.4.4.4

Social Bakers (http://www.socialbakers.com/)

Tato česká firma je aktuálně evropským lídrem pro analýzu sociálních sítí a má tak globální působnost. SocialBakers měří jak Facebook, tak i Twitter, Google+ a LinkedIn. 2.4.4.5

Social Mention (http://www.socialmention.com)

Apliakce Social Mention umožňuje rovněž prohledávat sociální sítě. Navíc má tento produkt možnost přidat si widget na vlastní stránky, který lze využít například pro sekci „Napsali o nás“. 2.4.4.6

Hootsuite (http://hootsuite.com/)

Spíše než analytický nástroj, je Hootsuite aplikace, která agreguje správu všech firemních sociálních sítí. V jedné aplikaci tak máme přístup k sítím Facebook, Twitter, LinkedIn, Myspace a další. Zprávy lze tedy publikovat na více sítích najednou a to i přes více různých účtů s možností určení přesného času publikace. Umožňuje ale také vyhledávat, filtrovat, takže lze využít i pro monitoring, ale poskytuje pouze informace o návštěvnosti a míře prokliku na publikované odkazy. 2.4.4.7

Crowdbooster (http://crowdbooster.com/)

Produkt Crowdbooster je zaměřený přímo jenom na sociální síť Twitter a umožňuje publikovat anebo vyhledávat publikované zprávy. Poskytuje také informace o úspěšnosti publikovaných zpráv a to podle toho, jak byla zpráva dále sdílena. 2.4.4.8

Zoomsphere.com (http://www.zoomsphere.com/)

Webová aplikace firmy MicroMedia, zaměřená na indexování, analýzu a vizualizaci veřejně dostupných dat ze sociálních sítí. Původní název byl Fejsbucek.cz a byl zaměřen pouze na sociální sít Facebook. Nyní ale monitoruje i Twitter, Google+, YouTube, LinkedIn a síť Pinterest. Produkt je nyní dostupný globálně a výchozí lokalizace je anglická.

2.4.5

Shrnutí zahraničních

Zahraniční nástroje nejsou pro nás moc vhodné, protože nejsou cílené na lokální trh. Nezvládají český jazyk (skloňování), mají problémy s diakritikou, mohou mít problémy s kódováním, ale hlavně neobsahují databázi českých 23

2. Analýza zdrojů (lide.cz, zena.cz). Rovněž by bylo výpočetně a časově náročné sbírat i zahraniční zdroje, proto se v naší aplikaci zaměříme pouze na lokální zdroje.

2.5

Uživatelské role

Nyní je potřeba určit uživatelské role, protože dle uživatelských rolí budeme následovně rozdělovat případy užití. Musíme tedy specifikovat, jaké typy uživatelů budou s aplikací pracovat. Dle typu se rozlišuje množina funkcí, kterou budou moci uživatelé vykonávat a jejich celková oprávnění. Aplikace bude již od začátku psána jako více uživatelská, takže musí být počítáno s existencí více uživatelů a každý z nich musí mít své nastavení, které se bude vztahovat pouze k jeho účtu.

2.5.1

Nepřihlášený uživatel

První typ uživatele je nepřihlášený uživatel a je to každý, kdo poprvé vstoupí na rozhraní aplikace. Není ještě přihlášený, takže vidí pouze přihlašovací dialog. Jeho možnosti jsou následující: • Přihlášení se do aplikace. • Obnova zapomenutého hesla. • Zobrazení nápovědy, nebo kontaktu na administrátora. Jedná se tak pouze o akce, které souvisí pouze s autorizací uživatele, nebo pomocí v případě nějakých problémů.

2.5.2

Běžný uživatel

Další uživatelská role je běžný uživatel, což je uživatel, který má všechny možnosti, jako role Nepřihlášený uživatel, ale ještě navíc má možnost přihlásit se do aplikace tím, že vlastní správné přihlašovací údaje. Jeho možnosti se tak rozšíří o následující funkcionalitu: • Filtrování výsledků dle zdroje a tématu, jak textově, tak vizuálně. • Zobrazení detailu o každém ze zobrazených výsledků. • Definice témat (oborů sledování) a klíčových slov, které témata definují. • Možnost přiřazení zdrojů z předem daného seznamu. • Export dat, která odpovídají nastaveným tématům. • Změna hesla, osobních údajů. • Možnost odhlášení. 24

2.5. Uživatelské role Jedná se tak o běžného uživatele, který bude s aplikací denně pracovat. Není nijak omezený, ale vidí pouze ta data, která se vztahují k jeho účtu. Nemůže tak vidět data ostatních uživatelů.

2.5.3

Administrátor systému

Poslední rolí je Administrátor, který bude správce celého systému a bude mít tedy stejné možnosti jako běžný uživatel, ale navíc ještě: • Správa uživatelů. • Správa zdrojů, které lze sledovat, jejich vkládání. • Sledování vytížení systému, statistiky používání a chybové notifikace. • Práce s daty bez omezení na určité téma, nebo klíčové slovo. • Zobrazení témat a klíčových slov, které mají vloženi ostatní uživatelé. • Vytváření textových podstránek systému, například aktuality, nebo informační texty. Administrátor musí mít všechna oprávnění, aby mohl ovládat systém jako celek a zároveň mohl fungovat na úrovni jednotlivých uživatelů, například při řešení určitých problémů, které by mohl určitý uživatel mít s ovládáním systému. Administrace uživatelských účtů, podstránek a zdrojů bude pravděpodobně oddělena do separátní aplikace, do které bude mít přístup pouze administrátor a pro vstup do vlastní aplikace si bude vytvářet přístup nový.

Obrázek 2.1: Uživatelské role 25

2. Analýza Obrázek 2.1 popisuje uživatelské role jako UML graf. Speciálním typem uživatele bude čas, neboli CRON, což je technologie na straně serveru, která umí v nastavený čas spouštět přednastavené akce, jako například načítání nových dat.

2.6

Případy užití (Usecases)

Případy užití rozdělíme do tematických celků, dle toho jak si jsou logicky příbuzné. Tímto přímo rozdělíme aplikaci do různých menších částí, což bude výhodné, protože tak budeme moci řešit každou část samostatně i když ve výsledku musí všechny části spolupracovat. Z úvodní části zpracujeme pouze základní a rozšiřující požadavky, které budeme implementovat. Základní funkce aplikace je tedy monitoring vybraných zdrojů. Data, která budeme chtít uložit k pozdějšímu zpracování, definujeme pomocí oborů zájmu a klíčových slov, která tyto obory vystihují. Doplňkovou funkcí je následná vizualizace a filtrování nasbíraných dat, která lze i exportovat. Jako každá aplikace, tak i tato bude mít určité režijní funkce, jako je třeba přihlašování, takže seznam případů užití musí začínat právě základními případy.

2.6.1

Základní případy užití

Nejzákladnější funkčností je možnost autentizace a základní práce se systémem: • Přihlášení se do aplikace. – Vstupní podmínka: uživatel zadá správnou kombinaci uživatelského jména a hesla. Uživatel je aktivován (není zablokován). – Výstupní podmínka: uživatel je přihlášen a toto přihlášení trvá po celou dobu práce s aplikací. • Odhlášení se. – Výstupní podmínka: musí být provedeno odhlášení, takže uživatel nemůže s aplikací dále pracovat. • Obnovení zapomenutého hesla. – Vstupní podmínka: uživatel zadá email, který je v aplikaci uložený. – Výstupní podmínka: na tento email budou zaslány instrukce k obnově hesla. • Zobrazení nápovědy, nebo kontaktního formuláře. – Vstupní podmínka: pro tento případ užití není vyžadováno přihlášení. 26

2.6. Případy užití (Usecases)

Obrázek 2.2: Diagram případů užití pro přihlášení

Obrázek 2.3: Diagram aktivit pro vybrané Základní případy užití 27

2. Analýza Při odeslání e-mailu uživateli s instrukcemi k obnově hesla dochází zároveň k ověření, že daný uživatel má přístup do dané e-mailové schránky.

2.6.2

Správa uživatelů

Protože je aplikace víceuživatelská, musí být implementována správa uživatelů. Tyto případy užití vlastní pouze administrátor systému a ve všech případech musí být řádně přihlášen.

• Zobrazení seznamu uživatelů (jméno, email, aktivní/neaktivní). • Přidání uživatele.

– Vstupní podmínka: e-mail uživatele zatím v systému neexistuje. E-mail musí být unikátní. • Editace uživatele.

– Vstupní podmínka: uživatel v systému existuje. Nelze editovat email, který je unikátní. • Smazání uživatele.

– Vstupní podmínka: uživatel v systému existuje. – Výstupní podmínka: dojde ke smazání uživatele, všech jeho témat a klíčových slov. • Deaktivace/aktivace uživatele – krátkodobé zablokování přístupu do aplikace.

– Výstupní podmínka: pokud je uživatel zablokován, není mu povoleno se přihlásit.

Případy užití správy uživatelů jsou znázorněny diagramem 2.4. 28

2.6. Případy užití (Usecases)

Obrázek 2.4: Diagram případů užití Správa uživatelů Jednotlivé kroky složitějších případů užití popíšeme diagramem aktivit 2.5.

Obrázek 2.5: Diagram aktivit pro případy užití Správa uživatelů 29

2. Analýza

2.6.3

Zadání sledovaných zdrojů

Dříve, než bude aplikace nějaká data sbírat, je potřeba definovat, na jaká data se má aplikace zaměřit a podle čeho je filtrovat. Uživatel musí mít tedy možnost nastavit aplikaci pro sběr dat a měl by proto mít možnost práce se zdroji, tématy a klíčovými slovy. Aby uživatel věděl, s jakými zdroji může pracovat, je nutné realizovat tyto funkce:

• Výpis všech skupin zdrojů, které lze přiřadit k uživatelskému tématu.

– Výstupní podmínka: každý vypsaný zdroj musí být označen jako aktivní.

• Vypsat všechny dostupné zdroje, které jsou ve vybrané skupině zdrojů (například všechny RSS kanály).

– Výstupní podmínka: každý vypsaný zdroj musí být označen jako aktivní.

• Vizuálně rozdělit skupiny zdrojů na sledované a nesledované.

• Přiřazení skupiny zdrojů k určitému tématu, nebo eventuelně odebrání.

– Vstupní podmínka: téma, ke kterému se zdroj připojuje, musí vlastnit přihlášený uživatel.

• Výpis všech přiřazených skupin zdrojů k jednotlivým tématům.

• Vypsání podrobností o každém sledovaném zdroji (URL adresa, URL pro zdroj sbíraných dat, např. RSS kanál).

Případy užití správy zdrojů jsou znázorněny diagramem 2.6. 30

2.6. Případy užití (Usecases)

Obrázek 2.6: Diagram případů užití Správa zdrojů Tyto případy užití patří běžnému uživateli, který je přihlášen, tudíž i administrátorovi systému.

Obrázek 2.7: Diagram aktivit pro případy užití Správa zdrojů Diagram aktivit 2.7 popisuje jednotlivé případy užití Správy zdrojů. Pokud uživatel vybere zdroj, který je již přiřazen, ačkoli by tento zdroj již neměl být 31

2. Analýza nabízen, nezobrazí se chyba, ale pouze hláška o přidání zdroje a mělo by se odeslat varování na administrátora systému.

2.6.4

Správa témat

Aby mohl uživatel spojovat klíčová slova do přehledných témat, musí mít tyto možnosti: • Zobrazit seznam témat, které si již vložil a datum jejich poslední aktualizace. • Vytvořit nové téma, editovat téma, smazat téma. – Vstupní podmínka: editovat a mazat téma lze jen takové, které uživatel vlastní. • Zobrazit přiřazené zdroje k tématu. • Zobrazit přiřazená klíčová slova k tématu. – Vstupní podmínka: zobrazení pouze slov, která jsou připojena k tématu, které vlastní uživatel. • Nastavit téma jako aktivní, nebo neaktivní. Případy užití správy témat jsou znázorněny diagramem 2.8.

Obrázek 2.8: Diagram případů užití Správa témat 32

2.6. Případy užití (Usecases) Vybrané případy užití správy témat upřesňují diagramy aktivit 2.9.

Obrázek 2.9: Diagram aktivit pro případy užití Správa témat

2.6.5

Správa klíčových slov

Každé téma je definováno sadou klíčových slov, takže je nutné, aby aplikace umožnila: • Zobrazení všech klíčových slov, které má uživatel v jakémkoli téma. – Vstupní podmínka: klíčové slovo musí být přiřazeno k nějakému tématu, které uživatel vlastní • Zobrazení klíčových slov daného tématu. – Vstupní podmínka: Téma musí uživatel vlastnit. • Vytvoření nového klíčového slova, editace, smazání. • Zařazení klíčového slova k tématu, nebo odebrání. 33

2. Analýza • Zobrazení počtu nalezených článků, nebo příspěvků k danému slovu v závislosti na tématu.

• Nastavit slovo jako aktivní, nebo neaktivní.

Případy užití správy klíčových slov jsou znázorněny diagramem 2.10.

Obrázek 2.10: Diagram případů užití Správa klíčových slov

Aktivity diagramem 2.11 popíšeme operace s klíčovým slovem. Důraz je kladen na fakt, že jedno klíčové slovo může patřit do více témat. 34

2.6. Případy užití (Usecases)

Obrázek 2.11: Diagram aktivit pro případy užití Správa klíčových slov

2.6.6

Vizualizace nalezených dat

Nejdůležitější funkcí, s kterou bude uživatel denně pracovat, je vlastní vizualizace již nalezených výsledků, které se budou filtrovat dle nastavených témat a klíčových slov. Seznam případů užití lze tak definovat jako: • Zobrazení nalezených dat v textové formě. – Vstupní podmínka: zobrazené výsledky se vážou k nastaveným tématům a klíčovým slovům. • Zobrazení nalezených dat v grafické formě. 35

2. Analýza • Zobrazení počtu nalezených záznamů v rámci vybraného zdroje a tématu. • Zobrazení zdroje, odkud se záznam podařilo zachytit. • Zobrazení data uložení, autora záznamu, vlastní text záznamu a titulek. • Možnost sdílení dat (odeslat emailem). • Zobrazení permanentní odkazu, aby šel nalezený záznam zobrazit přímo na zdroji dat. • Možnost zobrazit detail záznamu. – Vstupní podmínka: záznam se musí vázat k určitému tématu daného uživatele. Případy užití zobrazení dat jsou znázorněny diagramem 2.12.

Obrázek 2.12: Diagram případů užití Zobrazení Žádný z případů užití zobrazení není tak složitý, aby se musel popisovat diagramem aktivit.

2.6.7

Zobrazení detailu záznamu

Pro každý uložený záznam musí jít zobrazit všechny podrobnosti, nejenom o vlastním záznamu, ale i podrobnosti o zdroji, odkud záznam pochází a dále možnost na zobrazení dalších záznamů, které můžou s aktuálním záznamem určitých způsobem souviset (stejné diskusní vlákno, odpověď na daný záznam, stejný zdroj, stejný uživatel dané sociální sítě apod.) 36

2.6. Případy užití (Usecases) • Možnost zobrazit všechna data, která jsou v systému, pro daný záznam uložena. – Vstupní podmínka: záznam se vztahuje k tématu, který uživatel vlastní. • Možnost zobrazit kompletní data o zdroji, odkud záznam pochází. • Možnost zobrazení ostatních záznamů původního autora záznamu. – Vstupní podmínka: pouze u sítí, kde to bude možné (Twitter, Facebook). • Možnost zobrazení ostatních záznamů daného zdroje odkud byl záznam uložen. Případy užití zobrazení detailu jsou znázorněny diagramem 2.13.

Obrázek 2.13: Diagram případů užití Zobrazení detailu záznamu Diagram aktivit stejně jako u vizualizace dat nemá smysl, jedná se pouze o zobrazení dat z databáze.

2.6.8

Sběr dat

Jednou z nejdůležitějších částí aplikace bude vlastní sběr dat, která se budou následně filtrovat. Data budou sbírána na základě nastavených zdrojů a klíčových slov. 37

2. Analýza • Aplikace bude umožňovat sběr dat ze zdrojů, které budou zadány přes administraci systému. – Vstupní podmínka: pro daný zdroj musí v aplikaci existovat příslušný importér a zdroj záznamů musí být validní (např. RSS kanál). • Aplikace bude zaznamenávat každý sběr pro případné vyhodnocování a optimalizace. – Výstupní podmínka: záznamy o sběru budou ukládány do databáze a dále podrobně do souboru. Pro každý den jeden soubor. Případy užití sběru dat jsou znázorněny diagramem 2.14.

Obrázek 2.14: Diagram případů užití Sběr dat

2.6.9

Filtrování sesbíraných dat

Aplikace musí umožňovat filtrování nasbíraných dat, aby si uživatel mohl vyfiltrovat pouze zdroj, nebo téma, které ho zajímá. Implementovat se tak musí tyto funkce: • Filtrování nalezených dat dle zdroje. • Filtrování dle témat – aplikace vypíše pouze záznamy, které se váží k vybranému tématu. – Vstupní podmínka: Vybrané téma patří danému uživateli, který je přihlášen a pracuje s aplikací. • Kombinace filtrování, jak podle zdroje, tak i podle tématu dohromady. Případy užití filtrování jsou znázorněny diagramem 2.15. 38

2.6. Případy užití (Usecases)

Obrázek 2.15: Diagram případů užití Filtrování Diagram aktivit 2.16 popisující průběh filtrování dle téma.

Obrázek 2.16: Diagram aktivit pro případy užití Filtrování

2.6.10

Exportování dat

Vzhledem k tomu, že aplikace nebude umožňovat pokročilou analýzu dat, je potřeba, aby šla nasbíraná data exportovat ve standardním formátu pro zpracování jinou aplikací, např. Microsoft Excel, nebo Gephi. Aby šla data exportovat, musíme implementovat tyto případy užití: • Zvolení dat, které chceme exportovat dle oboru zájmu a dle zdroje. • Možnost zvolení výstupního formátu dat – např. XLS, TXT, Gephi XML. 39

2. Analýza • Možnost data exportovat dle zadaných parametrů. Případy užití exportování dat jsou znázorněny diagramem 2.17.

Obrázek 2.17: Diagram případů užití Export dat Diagram aktivit 2.18 popisující vlastní proces exportu.

Obrázek 2.18: Diagram aktivit pro případy užití Export dat

2.6.11

Administrace aplikace

Poslední částí bude vlastní administrace aplikace, od správy sledovaných témat, přes správu statických stránek až po správu vlastních administrátorů. Bude se tak jednat o případy užití, které budou realizovány mimo hlavní aplikaci, v administrační části. Administrátor bude mít možnost: 40

2.7. Rozdělení aplikace na části • Správa statických stránek, vytvoření, editace, smazání stránky. Např. nápověda, kontaktní formulář. – Vstupní podmínka: každá stránka musí mít unikátní identifikátor (URL). • Správa načítaných zdrojů: vložení, editace, smazání. – Vstupní podmínka: každý zdroj musí mít validní výstup dat. • Správa administrátorů: vložení, editace, smazání, zablokování. – Vstupní podmínka: každý administrátor bude mít unikátní přístupové údaje, své jméno a heslo. Případy užití exportování dat jsou znázorněny diagramem 2.19.

Obrázek 2.19: Diagram případů užití Administrace aplikace Tímto je výčet případů užití kompletní a můžeme začít skládáním jednotlivých funkcí do sebe.

2.7

Rozdělení aplikace na části

Nyní máme definované všechny požadavky, které máme přehledně rozdělené do jednotlivých logických celků. Zároveň víme hlavní funkce aplikace. Můžeme 41

2. Analýza tak sestavit základní hierarchii stránek, neboli strukturu aplikace tak, aby nejdůležitější funkce byli ihned dostupné a ty méně používané byly dostupné až přes určitou volbu v menu. Již nyní víme, že aplikace má tři základní části:

• Sběr dat – nejdříve je potřeba data sesbírat, aby bylo s čím pracovat.

• Filtrování dat – poté je potřeba sesbíraná data filtrovat, dle zadaných témat a klíčových slov.

• Vizualizace – když jsou data vyfiltrována je nutné je přehledně zobrazit uživateli.

Vlastní sběr dat bude probíhat na pozadí, uživatel bude mít akorát informaci o tom, kdy proběhl sběr dat pro daný zdroj naposledy. Není proto potřeba, aby vlastní sběr dat byl součástí uživatelského rozhraní, i když se jedná o podstatnou část aplikace. Zajímavější je filtrování a vizualizace, což se dá považovat za hlavní funkci aplikace. Pracovat budeme pouze s případy užití, které se váží k nepřihlášenému a běžnému uživateli. Ostatní funkce budou řešeny v rámci administrace, která bude jako samostatný systém a nebude u ní kladen důraz na použitelnosti a přehlednost tak, jako u běžného rozhraní aplikace.

2.7.1

Priority jednotlivých funkcí

Rozdělení aplikace na hierarchii nám pomůže udělat aplikaci jednoduší, protože nejdůležitější funkce budou hned „po ruce“ a zároveň aplikace nebude nabízet možnosti, které většina uživatelů tak často nevyužije. I zde platí Paretovo pravidlo, že 80% uživatelů používá 20% procent funkcí. Důležité nastavení zůstane přístupné, ale až hlouběji ve struktuře stránek, protože se očekává, že bude nutno nastavovat aplikaci velmi zřídka. Funkce tedy seřadíme dle jejich důležitosti a míry využití. Nejpoužívanější funkce musí být co nejvýše. Hierarchii stránek 2.20 znázorníme myšlenkovou mapou, takže nám částečně vyplynou i návaznosti stránek, jak je možno se z jedné stránky dostat na další a upřesnit tak svůj záměr. 42

2.8. Závislosti stránek aplikace (Task graph)

Obrázek 2.20: Hierarchie stránek Uprostřed diagramu 2.20 je znázorněna naše aplikace, která se dále větví na položky, které budou dostupné z hlavního menu. Položky jsou číselně označeny tak, jakou budou mít prioritu a pořadí v menu. Položka č. 1 – Dashboard (hlavní panel) bude zobrazen ihned po přihlášení a bude mít na starosti zobrazení a filtrování nalezených dat, které budou zobrazeny pod sebou. Filtrování bude možné dle zvolených témat, kategorií anebo dle zdroje nalezené zprávy. Nakonec také podle času, abychom si mohli vyfiltrovat pouze dnešní zprávy, nebo zprávy staré maximálně týden. Druhá položka – Vizualizace dat bude mít na starosti vizualizaci dat v podobě grafů, nebo tabulek, aby šlo přehledně zjistit, z jakého zdroje pochází nejvíce nalezených zpráv, kde se nejvíce diskutuje apod. Postupem času by zde měli přibývat další možnosti vizuální analýzy dat. Třetí položka – Nastavení bude zastřešovat celkové nastavení aplikace od nastavení klíčových slov, témat až po navolení uživatelů, kteří budou moct s aplikací pracovat. Poslední položka – Exporty kde bude možnost provést export dat do formátu CSV, nebo PDF. Chybí zde položka Sběr dat, který se bude provádět na pozadí a informace o sběru, budou dostupné pouze v administraci systému.

2.8

Závislosti stránek aplikace (Task graph)

Graf hierarchie 2.20 byl určen pro zjištění priority a seskupení menu. Nyní je rovněž potřeba navrhnout, jak budou na sebe jednotlivé obrazovky navazovat, 43

2. Analýza což nám pak pomůže při implementaci grafického návrhů a dále odkazů na každé stránce. Můžeme tak zajistit, aby z každé stránky byla možnost dostat se jak na další krok, tak i krok zpět. Zároveň by z každého kroku měl vést odkaz na základní obrazovku aplikace (Dashboard), což se většinou realizuje kliknutím na logo, nebo na první položku v menu. Toto popíšeme tzv. Task grafem 2.21

Obrázek 2.21: Task Graph Tímto máme definováno, co musí grafické rozhraní určitě obsahovat a která položka má jakou prioritu. Z tohoto rozdělení budeme vycházet v návrhové části práce, kde si podle toho navrhneme uživatelské rozhraní aplikace, na kterém pak budeme stavět vlastní aplikaci.

2.9

Konceptuální modely

Nyní když máme definované požadavky na aplikaci a jednotlivé případy užití, lze určit jednotlivé entity, nebo třídy, které budou v aplikaci obsaženy na lo44

2.9. Konceptuální modely gické úrovni. Prozatím se bude jednat o modely, které nejsou závislé na platformě (PIM - Platform Independent Model). Až teprve v části práce s názvem „Návrh“ provedeme převod těchto nezávislých diagramů na PSM (Platform Specific Model) – na diagramy, které se budou vztahovat přímo k platformě, kterou si vybereme jako cílovou.

2.9.1

Konceptuální diagram tříd (Class diagram)

Z případů užití můžeme nyní eliminovat jednotlivé entity, které by mohli tvořit základ celé aplikace. Jednotlivé entity a jejich vazby namodelujeme pomocí diagramu tříd 2.22. Tento diagram pak bude v další části převeden na finální diagram tříd, dle zvolené platformy. U každé entity uvádím její parametry a dále operace, které bude možno s entitou provádět.

Obrázek 2.22: Class diagram Z důvodu přehlednosti chybí v diagramu 2.22 entity pro práci s adminis45

2. Analýza trátory systému a uložení statických stránek. Ani jedno není pro nás nyní důležité.

2.10

Konceptuální datový model (ER model)

Z diagramu tříd 2.23 můžeme sestavit rovněž datový model, jako návrh toho, jak by jednotlivé entity mohli být uloženy v relační databázi. Oproti diagramu tříd chybí tabulka Importer, protože ten nebude nikde uložen, ukládat budeme přímo až nalezené záznamy (Items).

Obrázek 2.23: Data model Opět chybí nedůležité tabulky pro uložení administrátorů a statických stránek, jako u diagramu výše. Oba dva diagramy použijeme v následující návrhové části a dle vybrané platformy je přetransformujeme na finální model aplikace. 46

Kapitola

Návrh V předchozí analytické části jsme si dle požadavků na aplikaci, vytvořili rozdělení aplikace na jednotlivé části a ke každé části jsme sepsali jednotlivé případy užití, které definují funkce, které bude aplikace v jednotlivých částech umět. Tyto případy užití a hierarchii aplikace použijeme v této části, abychom mohli navrhnout uživatelské prostředí aplikace. Rovněž vybereme platformu, na které budeme celou aplikaci implementovat, takže i prototyp uživatelského rozhraní můžeme přímo vytvářet na cílové platformě. Nakonec pak rozšíříme konceptuální modely aplikace (PIM) z analytické části a vytvoříme model aplikace, který se přímo váže na vybranou platformu (PSM). Navrhovat budeme pouze vlastní aplikaci bez administrační části.

3.1

Základní výběr platformy

Když budeme zkoumat, jak můžeme realizovat výslednou aplikaci, máme na výběr tři hlavní platformy: • Samostatná aplikace pro PC na platformě Windows, Linux, nebo Mac OS. • Webová aplikace dostupná pomocí webového prohlížeče. • Aplikace pro mobilní zařízení Android, OS X, Windows Phone, Symbian.

3.1.1

Samostatná aplikace

Možnost samostatné aplikace nabízí ještě další dvě rozdělení: • Kompletní logika na straně klienta – v tomto případě by serverová i klientská část byla nainstalována na straně klienta. Výhodou by tak byl vysoký výpočetní výkon a úložiště pro každého uživatele aplikace. Nevýhodou je pak to, že každý klient by data musel sbírat samostatně. 47

3

3. Návrh • Klientská aplikace pouze jako klient – sběr dat a uložení by probíhalo na serveru a klientská část, která by byla umístněna na straně klienta, by pouze načítala data. Výhodou by bylo, že data by se sbírala pro všechny klienty zároveň na jednom místě. Klientská aplikace by také mohla se sběrem dat vypomoct, takže by se načítání dat rozložilo přes více koncových uzlů. Obě možnosti mají stejné výhody a nevýhody. Nevýhodou je nutnost řešit aktualizace softwaru na straně klienta, dále instalace vlastního softwaru a rovněž programování aplikace, nebo minimálně ladění pro více operačních systémů, nebo i jejich verzí. Výhodou obou řešení by byla možnost lokální práce s daty a to i v případě nedostupného internetového připojení.

3.1.2

Webová aplikace

Hlavní výhodou webové aplikace je absolutní nezávislost na platformě. Není tak nutno řešit žádnou instalaci klientského software, ani aktualizace. Vyžadován je pouze webový prohlížeč, kde předpokládáme, že prakticky každé připojené zařízení je prohlížečem vybaveno. Šlo by možná namítnout, že je u webových aplikací nutnost řešit vzhled aplikace pro jednotlivé prohlížeče, nebo alespoň ty nejvíce používané. U naší aplikace nás to trápit nebude, protože nebude stavět na pěkném vzhledu, ale na funkčnosti. Webový prohlížeč je tak pouze tenký klient, který veškerá data načítá ze vzdáleného serveru. Sběr a uložení dat probíhají rovněž na serveru, takže se data sbírají pouze jednou. Další výhodou je možnost využít ostatních webových služeb, jako třeba generování grafů, statistiky návštěvnosti, napojení na sociální sítě, nebo mapové podklady. Nevýhodou je závislost na internetovém připojení, což se z části dá řešit lokálním úložištěm, ale z dlouhodobého hlediska tam závislost je. Další nevýhodou by mohla být pomalejší práce, kdy vzniká prodleva při přenosu dat po síti.

3.1.3

Mobilní aplikace

Výhodou mobilní aplikace je přítomnost na mobilním zařízení, takže by byla data z monitoringu vždy po ruce. Nabízí se zde využití funkcí mobilního telefonu, jako je určení polohy, notifikace, widgety (mini aplikace na plochu telefonu), fotoaparát, akcelerometr a další. Stejně jako u webové aplikace by mobilní aplikace byla pouze klientem, který by načítal data ze vzdáleného serveru. Nepočítá se s tím, že by sběr dat probíhal na vlastním zařízení. Kromě těchto pár výhod má mobilní aplikace mnoho nevýhod, jako třeba nutnost programovat aplikaci pro každou majoritní platformu zvlášť (Android, iPhone, Windows Phone). I tak je stejně nutná přítomnost serverové strany, kde budou vlastní data uložena. 48

3.2. Návrh uživatelského rozhraní (Wireframy) Rovněž lze naprogramovat aplikaci tak, aby šla správně zobrazit pomocí webového prohlížeče a odpadla by tak nutnost programovat mobilní aplikaci.

3.1.4

Vybraná platforma

Z důvodů uvedených výše jsem si vybral, implementovat aplikaci jako webovou aplikaci. Sběr, indexování, filtrování bude probíhat na webovém serveru a jako klientská aplikace poslouží webový prohlížeč. Konkrétní výběr platformy, včetně programovacího jazyka a databáze bude provedeno až v dalších krocích. Prozatím nám stačí vědět, že výstup aplikace bude v prostředí prohlížeče, abychom mohli dle toho navrhnout uživatelské rozhraní. I když bude aplikace implementována jako webová, v budoucnu se nabízí udělat i její mobilní variantu, nebo klientskou aplikaci pro jednotlivé operační systémy. Využilo by se tak výhod všech platforem.

3.2

Návrh uživatelského rozhraní (Wireframy)

V následující části vytvoříme wireframy, což jsou tzv. „drátěné“ modely uživatelského rozhraní aplikace, které se používají k prototypování uživatelského rozhraní. Z wireframů je vidět, jak bude aplikace rozvržena, kde bude menu a kde ovládací prvky. Výhodou wireframů je především rychlejší a levnější tvorba, než aplikace změn do finálního grafického návrhu. Za relativně krátký čas tak hned vidíme, jak bude aplikace přibližně vypadat a můžeme si rychle ověřit, zda nechybí nějaké tlačítko, nebo odkaz, který je pro správnou funkci nezbytný. Nemusí se ani tvořit wireframe pro každou stránku samostatně, postačí pro každý typ stránky – např. stránka s formulářem, stránka s textem, stránka s výpisem záznamů. Wireframy budeme tvořit na základě případů užití a hlavně dle hierarchie aplikace, kterou jsme si vytvořili v analytické části. Z této hierarchie je krásně vidět, které stránky bude nutné vytvořit, co bude obsahem menu a jaké skupiny případů užití musí dané obrazovka pokrýt. Z grafu závislosti jednotlivých částí zase vidíme, jak na sebe obrazovky navazují, takže budeme moct dle toho navrhnout odkazy a dodržet jednotlivé posloupnosti obrazovek.

3.2.1

Nielsonova heuristická analýza

Po vytvoření návrhu rozhraní je potřeba ověřit, že uživatelé budou schopni systém používat. Práce v systému musí být intuitivní a co nejjednodušší. Splnění těchto předpokladů je možno ověřit uživatelským testováním, které lze provádět buď za pomocí uživatelů, nebo i bez nich pomocí analýz. Výstupy analýzy je pak potřeba zpracovat a návrh rozhraní dle toho přizpůsobit. Poté již následuje tvorba grafického návrhu. 49

3. Návrh Jednou z možnosti jak testovat aplikaci bez využití uživatelů je heuristická analýza, která vychází z poznatků, které byly získány dlouhodobým pozorováním. Jedná se o soubor zkušeností, jak jsou uživatelé zvyklý se systémem pracovat a co od něho očekávají. Jednou z heuristických analýz je Nielsenova heuristická analýza, která se skládá z deseti základních pravidel, které je nutno zkontrolovat, aby byla zajištěna odpovídající použitelnost a intuitivní ovládání aplikace. Tyto pravidla je dobré mít na paměti již při vytváření návrhu uživatelského rozhraní: 1. Stav systému musí být vždy viditelný. 2. Systém „mluví uživatelským jazykem“ a je co nejvíce přizpůsoben tak, aby práce s ním připomínala práci v reálném světě. 3. Systém musí poskytovat uživateli možnost vrátit ze z určitého stavu zpět, nebo zrušit zvolenou akci. 4. Systém by měl být konzistentní jak vzhledově, tak i co se týče ovládání. 5. Systém by měl předcházet chybovým stavům, např. pomocí potvrzovacích dialogů a varování. 6. Uživatel by měl být při používání systému co nejméně kognitivně zatížen. To zajistíme tím, že bude systém nabízet pouze volby, které lze vybrat a ostatní skryje, nebo vizuálně zneplatní. 7. Systém musí být efektivní a jednoduchý pro použití. Zároveň však musí poskytovat i dostatečný počet voleb, které využijí hlavně pokročilí uživatelé. 8. Systém by měl uživateli poskytovat srozumitelné chybové zprávy tak, aby měl uživatel možnost chyby obratem opravit a věděl, co po něm systém vyžaduje. 9. Systém by měl zobrazovat co nejméně informací a voleb, tak aby práce v něm byla co nejrychlejší, přehledná, a uživatel musel co nejméně přemýšlet. 10. Systém musí poskytovat nápovědu přesně tam, kde jí uživatel očekává a v situacích, kdy je nejvíce potřeba. Dodržováním těchto pravidel nám pomůže vytvořit systém, který bude jednoduchý a efektivní na práci. Zároveň je dobré systém otestovat na reálných uživatelích, ať už pomocí nějakého prototypu, nebo třeba pomocí wireframů, které budou vytisknuté na papíře. Uživatel by neměl mít problémy s orientací v aplikaci a měl by alespoň tušit, co musí udělat, aby provedl nějakou činnost. 50

3.2. Návrh uživatelského rozhraní (Wireframy) Nyní když víme, jaké obrazovky budeme navrhovat a na co musíme dávat pozor, můžeme se pustit do návrhu jednotlivých wireframů. Stejně jako v analýze, navrhujeme pouze stránky, které se týkají případů užití nepřihlášeného a běžného uživatele. Administraci systému navrhovat nebudeme.

3.2.2

Přihlašování

První obrazovkou 3.1, kterou uvidí každý uživatel, bude přihlašovací stránka, kde se akorát bude moct uživatel přihlásit. Neměl by také chybět odkaz pro obnovu zapomenutého hesla, nebo odkaz na nápovědu. Tato obrazovka bude rovněž zobrazena po odhlášení uživatele ze systému společně s informační hláškou.

Obrázek 3.1: Wireframe přihlašovací stránky

3.2.3

Dashboard

Dashboard 3.2 bude vstupní stránkou po přihlášení do aplikace. Bude zobrazovat nejnovější nalezené výsledky procházení a dále bude nabízet možnosti filtrování. Jedná se o stránku, kde bude uživatel trávit největší množství času a měl by mít k dispozici všechny ovládací prvky pro manipulaci s daty. 51

3. Návrh

Obrázek 3.2: Wireframe obrazovky dashboard

3.2.4

Analýza obsahu

Obrazovka analýza obsahu 3.3 bude poskytovat možnost vizualizace nasbíraných dat buď pomocí grafů, nebo tabulek. Tyto data bude uživatel filtrovat opět dle zdroje, nebo tématu v levém menu, jako u dashboardu. Jedná se vlastně o stejný výpis dat a sadu ovládacích prvků, jako je to u dashboardu. Rozdíl je ten, že zde se záznamy nevypisují textově, ale vizuálně v grafech. 52

3.2. Návrh uživatelského rozhraní (Wireframy)

Obrázek 3.3: Wireframe obrazovky analýza obsahu

3.2.5

Nastavení aplikace

Obrazovka nastavení aplikace 3.4 umožňuje nastavit všechny potřebné parametry, od klíčových slov, přes témata až po uživatele, kteří budou mít do aplikace přístup. Obsahuje také sekundární menu, které umožní další navigaci v rámci nastavení.

Obrázek 3.4: Wireframe obrazovky nastavení aplikace 53

3. Návrh

3.2.6

Vytváření a editace položek

Všechny položky Témat, Kategorií i Zdrojů bude možno přidávat, editovat a mazat. Toto se bude provádět za pomocí formulářů, které budou zakomponovány do stránky, dle obrazovky 3.5. Neměl by chybět odkaz pro vrácení se zpět na výpis všech položek, aby měl uživatel možnost úniku.

Obrázek 3.5: Wireframe obrazovky export dat

3.2.7

Export

Obrazovka export 3.6 bude nabízet pouze výběr požadovaných dat pomocí volby zdroje a tématu. Poté si uživatel vybere formát exportu a stiskem tlačítka Exportuj, mu vyskočí dialog pro stažení souboru. Uživatel by měl být přehledně informován, který zdroj a které téma je aktuálně vybrané, aby měl jistotu, že exportovaná data budou kompletní. 54

3.3. Prototyp grafického rozhraní

Obrázek 3.6: Wireframe obrazovky export dat Tím je výčet typických obrazovek kompletní, zbývající obrazovky jsou buď velmi podobné, nebo se dají vytvořit z částí, které byly navrženy ve wireframech výše.

3.3

Prototyp grafického rozhraní

Z navržených wireframů a případů užití můžeme následovně realizovat prototyp grafického vzhledu. Prototyp by měl umožňovat plynulý přechod mezi stránkami aplikace, výpis testovacích dat a celkově by se měl chovat jako finální aplikaci, i když vypisovaný obsah je pouze statický. Prototyp se hodí vždy, když je potřeba pomocí testovacích uživatelů ověřit, že je ovládání aplikace jasné a uživatel vždy ví, v jakém stavu systém je, jaké má možnosti a ví jak se vrátit zpět, nebo na domovskou stránku. Prototyp umožňuje lepší iterativní vývoj, protože každá změna je daleko jednoduší, než ve finálním grafickém návrhu. Na rozdíl od wireframů ale vidíme, jak na sebe stránky navazují a můžeme si interaktivně projít celou apli55

3. Návrh kaci. Prototyp realizujeme přímo na finální platformě, tak že pomocí jazyka HTML vytvořím základní rozdělení stránky a pomocí kaskádových stylů (CSS) vytvoříme alespoň mírné obarvení, pro větší přehlednost. Držíme se přitom rozvržení, které jsme si navrhli pomocí wireframů. Výsledný návrh rozložení stránky a obarvení je zobrazen obrázkem 3.7

Obrázek 3.7: Prototyp aplikace

Z tohoto prototypu grafického rozhraní budeme následovně vycházet při implementaci aplikace a budeme ho dále rozšiřovat o funkce, které bude potřeba navrhnout. Ostatní stránky jsou realizovány ve stejném duchu a rozložení.

3.4

Výběr platformy

Ačkoli jsme si na začátku návrhové části navrhli základní platformu a to webovou, je ještě potřeba specifikovat jednotlivé technologie, které nám pomůžou implementovat výslednou aplikaci. Držíme se přitom jednak vybrané platformy, tak i možnostmi, které máme. 56

3.4. Výběr platformy

3.4.1

Výběr programovacího jazyka

Programovací jazyk zvolíme PHP ve verzi 5.3, protože s ním mám největší zkušenosti a výsledná implementace tak bude nejrychlejší a nejoptimálnější. Rychlost implementace je rovněž podstatný parametr, protože se mohu dříve dozvědět silné a slabé stránky aplikace, různé překážky a nečekané situace. Pokud by se v budoucnu ukázalo, že je programovací jazyk nedostatečný, nebo klade nějaké překážky, až poté by se dalo uvažovat o změně jazyka, ale myslím, že je to nepravděpodobné. Sociální síť Facebook, která rovněž začala na jazyku PHP, musí denně zvládat několik miliónů přístupů a pořád běží na PHP, ačkoli některé části kódu již byly překompilovány do jazyka C. Jazyk PHP je velice rozšířený, má kvalitní dokumentaci a existuje pro něho nepřeberné množství nástrojů a knihoven. To je jednou z obrovských výhod. Další výhodou je, že PHP je dostupné na 99% hostingových služeb v České republice a díky vysoké konkurenci se dá pořídit provoz v desítkách korun měsíčně. S tím se pojí i fakt, že PHP zvládá nainstalovat a provozovat téměř každý serverový administrátor. Na výběr jazyka se rovněž váže výběr frameworku, aby se nemusela aplikace implementovat od začátku včetně rutinních kroků. Pro implementaci zvolím vlastní mikro-framework, který je navržen dle návrhového vzoru MVC. Tento framework mi usnadní práci s obsluhou běžných požadavků, správu jednotlivých stránek, přístupu do databáze a ukládání logů. Framework bude dále doplněn vybranými knihovami z frameworku Nette12 .

3.4.2

Výběr databáze pro uložení dat

Výběr databáze je klíčové rozhodnutí, protože bude aplikace náročnější na práci s daty a ty budou uložené právě v databázi. Na výběr je opět více možností, já se ale zaměřím na dvě nejpoužívanější technologie – relační a dokumentově orientované. Zcela tak vynechám objektově orientované, XML databáze a další. 3.4.2.1

Relační databáze

Pro relační typy databáze rovnou vyberu nejsilnějšího zástupce a to MySQL. Databáze MySQL13 je relační, multiplatformní a komunikace s ní probíhá pomocí dotazovacího jazyka SQL. Celý produkt je uvolněn jako open-source, takže lze volně používat. Databázový systém MySQL je jeden z nejrozšířenějších a stejně tak jako PHP je dostupný na 99% všech hostingových službách. Tento systém doprovází 30 let zkušeností, což se pozitivně odráží na množství dostupných nástrojů a dokumentací. Pro MySQL lze najít ovladač prakticky v každém programovacím jazyce. 12 13

Framework Nette - www.nette.org MySQL - http://cs.wikipedia.org/wiki/MySQL

57

3. Návrh 3.4.2.2

NoSQL databáze

NoSQL databáze jsou celkem nová technologie, ale v poslední době zažívají obrovský nárůst. Dělí se na dvě velké skupiny: • Key-value databáze – Memcached, Redis, Riak, Tokyo Cabinet, Cassandra • Dokumentové databáze – CouchDB, MongoDB Databáze nemají vůbec žádné schéma, ani relace, jsou denormalizované. Všechny záznamy, které jsou zde uloženy, mají svůj unikátní klíč a pomocí něho se k datům přistupuje. 3.4.2.3

Výhody NoSQL

Výhodou takového řešení je vysoká rychlost, kdy se nemusí systém starat vůbec o žádné schéma, pouze ukládá a poskytuje surová data. Odpadá nutnost řešení indexu, tabulek a sloupců. Tyto databáze jsou vysoce škálovatelné, replikovatelné a deduplikovatelné. Pro získávání dat používají sadu Map/Reduce funkcí. NoSQL databáze používají snad všechny přední IT firmy a některé z databází zde i vznikly (Facebook – Cassandra, Amazon – SimpleDB, Google – BigTable). V dnešní době se používají nejvíce pro uložení dat, kterých je velké množství a dá se na ně koukat jako na data jednoho typu. Například záznamy chyb, návštěvnost jednotlivých stránek, různá hlasování. Pro naše využití by se tento typ databáze celkem hodil, protože bude ukládat vysoké množství dat bez potřeby uchovávat nějaké relace. 3.4.2.4

Nevýhody NoSQL

Nevýhodou oproti MySql je řádově menší počet nástrojů, slabší dokumentace a vůbec celková podpora. Rovněž nemám s NoSQL vůbec žádné zkušenosti. Dále je nutné řešit validaci vstupních dat, generování klíčů a celkové skládání relací mimo vlastní databázi. Hodí se opravdu spíše pro ukládání velkého množství stejných dat.

3.4.3

Vybrané databázové řešení

Vzhledem k počtu nástrojů a zkušenostem jsem se rozhodl zvolit relační databázi MySql s tím, že pokud by v budoucnu jako technologie nestačila, ukládání samotných záznamů, které budu sbírat, by se odklonilo do dokumentově orientované databáze. Použití obou databází se označuje jako „polyglot persistence“ a jedná se o používanou praktiku, kdy se klasická data ukládají do relační databáze a 58

3.5. Základní architektura aplikace ostatní data, kterých může být obrovské množství, se ukládají do dokumentově orientované. Toto řešení lze najít u všech velkých projektů, počínaje sítí Facebook (Cassandra), Google (BigTable), Amazon (Dynamo), LinkedIn (Voldemort).

3.4.4

Výběr prostředí pro běh aplikace

Prostředí pro běh aplikace vychází z vybraného programovacího jazyka a databáze. Jako server použijeme Apache server, který je stejně jako PHP, nebo MySQL volně dostupný. Společně s operačním systémem Linux se tak ustálila zkratka LAMP, což označuje kombinaci Linux, Apache, MySql a PHP. Jedná se tak o nejčastěji nainstalované technologie na webových serverech. Apache server bude doplněn o nástroje Munin a Nagios, které dokážou sledovat vlastní běh serveru, generují grafy vytížení a při enormním zatížení umí zaslat varování na email, nebo mobilní telefon.

3.4.5

Verzování a zálohování

Abychom měli vývoj aplikace zálohovaný a rovněž dostupné starší verze, je vhodné použít nějaký verzovací nástroj. Starší verze je vhodné uchovávat, pokud by se vývoj ubral slepou větví, abychom se mohli vrátit a pokračovat jinou cestou. Na výběr máme centralizované (Subversion), nebo distribuované (Git) verzovací systémy. Pro naše účely si vybereme nástroj Git, který dokáže pracovat jak se lokálním, tak i vzdáleným repositářem a není tak nutné každou změnu odesílat na vzdálený server.

3.5

Základní architektura aplikace

Jak bylo již výše zmíněno, pro implementací naší aplikace použijeme vlastní mikro-framework, který je postavený dle návrhového vzoru MVC. To nám rozděluje celou aplikaci na tři, nebo více části. Jedná se o Model, View (šablony) a Controller (kontroléry), jak je znázorněno na obrázku 3.8. Stejně jako dekomponujeme celou aplikaci na dílčí celky, tak i rozdělení vlastního kódu dle MVC nám zajistí větší přehlednost, menší složitost a hlavně další rozšiřitelnost. 59

3. Návrh

Obrázek 3.8: Návrhový vzor MVC - Model View Controller Pod modelem aplikace si lze představit veškerou funkční logiku a uložení dat. View jsou šablony, do kterých data vykreslujeme. Controllery jsou prvky, které spojují vše dohromady – umí zpracovat uživatelský požadavek, dle toho získat potřebná data z modelu a vše vykreslit pomocí šablon.

3.5.1

Šablonovací systém

Výhodou MVC je jednak oddělení šablon jednotlivých stránek, ve kterých se řeší pouze vykreslení požadovaných dat, ale už se zde neřeší žádné zpracování a načítání dat. Vyhneme se tak „spaghetti code“, což je označení pro stránky, kde se míchá dohromady prezentační a aplikační logika a stránky jsou tak pro programátora velice složité. A to nejenom pro programátora, který kód aktuálně píše, ale i pro někoho, kdo bude za půl roku v kódu dělat nějaké změny. S šablonami může také pracovat i kódér HTML šablon, který má na starosti pouze nasazení připraveného grafického návrhu na vlastní stránky. Nemusí vůbec manipulovat s žádným aplikačním kódem. Šablonovací systém budeme realizovat pomocí Smarty, což je velice rozšířená knihovna právě pro práci se šablonami.

3.5.2

Model aplikace

Do modelu aplikace můžeme zahrnout jak celou aplikační logiku, tak i databázi. Oddělení modelu aplikace nám vzniká interní aplikační rozhraní (API), 60

3.5. Základní architektura aplikace které se pak využívá napříč celou aplikací. Výhodou oddělení je, že nad jedním modelem lze postavit jak výstup do HTML, tak třeba i textový výstup do konzole. Pro implementaci modelu aplikace budeme používat klasické PHP objektové třídy. Důraz bude kladen na dodržování principů objektového programování a to hlavně pravidla programování proti rozhraní. Dále se budeme snažit využívat návrhové vzory, tam kde to bude mít smysl.

3.5.3

Kontroléry

Kontroléry jsou poslední částí MVC a zajišťují nám komunikaci mezi modelem aplikace a šablonami. Kontrolér umí z modelu získat data a předat je do šablony, kde jsou data vykreslena. V neposlední řadě zajišťují zpracování uživatelských požadavků. Kontroléry budou implementovány jako klasické PHP skripty.

3.5.4

Připojení do databáze

Vzhledem k tomu, že budeme mít v databázi uložena všechna data, musíme k ní nějak přistupovat. K tomu bude sloužit třída Database.php, která zastřeší veškerou komunikaci s databází a případné ošetření chyb. Abychom nemuseli v každé třídě získávat připojení do databáze, vytvoříme si třídu PersistentObject.php, což bude abstraktní předek všech objektů, které budou přistupovat do databáze. Objekty, které budou dědit z této třídy, budou mít připojení do databáze již obstarané.

3.5.5

Přihlašování a správa uživatelů

Nyní musíme navrhnout všechny případy užití, počínaje základními případy. Jedná se o přihlášení, odhlášení a obnova hesla. Správa uživatelů bude řešena v jedné databázové tabulce „uzivatele“, kde bude uložen seznam všech uživatelů, jejich přihlašovací email a otisk hesla. Administrátoři systému budou uloženi v samostatné tabulce „admins“. Přihlašování do aplikace, nebo administrace tak bude probíhat tak, že se uživatel ověří právě proti těmto tabulkám. Obnova hesla bude realizována zasláním nového hesla na uživatelův email. V systému se pak s uživateli bude pracovat pomocí třídy Users.php. Každý uživatel v systému bude mít unikátní identifikátor, který bude potřeba rovněž pro uložení sledovaných témat, u kterého se musí tento identifikátor rovněž uložit, abychom věděli, že se vztahuje k danému uživateli.

3.5.6

Správa statických stránek

Statické stránky budou řešeny jednoduše pomocí jedné databázové tabulky. Všechny stránky budou uloženy v databázové tabulce „kategorie“ a pracovat 61

3. Návrh s ní budeme pomocí třídy Categories.php. Správu stránek bude mít na starosti pouze administrátor systému.

3.5.7

Rozdělení aplikace na celky

Již z analýzy víme, že celková aplikace na té nejvyšší úrovni bude rozdělena na tři významné celky. Bude to: • Sběr vlastních dat. • Filtrování nalezených záznamů. • Vizualizace sesbíraných dat. Tyto jednotlivé části musíme rovněž zohlednit ve vlastní implementaci a pro každou část navrhneme, jak jí budeme konkrétně řešit, s ohledem na definované případy užití.

3.6

Návrh sběru dat

První a nejdůležitější částí bude sběr dat. Důležitost je daná jednak tím, že data musíme začít sbírat co nejdříve, abychom pokryli alespoň jeden měsíc sběru článků, a dále jsou tyto data důležitá, protože na nich pak bude závislé vlastní filtrování a vizualizace. Tyto data tak budou to nejcennější, co budeme v aplikaci mít.

3.6.1

Ukládání témat a klíčových slov

Aby mohl uživatel definovat, která data chce sbírat, musíme nejdříve navrhnout ukládání témat a klíčových slov, což bude v souladu s případy užití týkající se správy témat a správy klíčových slov. Témata budou pouze určitou abstrakcí nad skupinou klíčových slov a každé téma se bude vázat k jednomu uživateli. U klíčových slov budeme ukládat slova tak, že budou sdílená pro jedno, nebo více témat. To je důležité, protože pokud by dva uživatelé vložili to stejné slovo, bylo by neefektivní pro každé slovo provádět ty samé operace. Nevýhodou tohoto řešení je, že přináší mírné komplikace při mazání klíčových slov, kdy musíme kontrolovat, zda slovo odstranit, nebo pouze odpojit vazbu od příslušného téma. Témata i klíčová slova budeme ukládat do samostatných tabulek, dle obrázku 3.9, která budou spojena třetí tabulkou, poskytující vazbu. 62

3.6. Návrh sběru dat

Obrázek 3.9: Ukládání témat a klíčových slov Práce s klíčovými slovy bude řešena v aplikační třídě Keywords.php, práce s tématy zase v Topics.php. Obě třídy budou potomky PersistentObject.php, protože budou pracovat s databází. V každé třídě pak budeme implementovat metody, které jsou důležité pro realizaci všech případů užití. Nyní je tedy potřeba určit, jakým způsobem budou data z jednotlivých zdrojů načítána a ukládána.

3.6.2

Rss

Syndikační formát Rss14 je založený na syntaxi XML a jedná se o nejpoužívanější formát pro strojový přenos dat a spolupráci jednotlivých stránek. Nejčastější použití je pro export veřejně dostupných článků, novinek, nebo diskusních příspěvků, čehož využijeme v naší aplikaci. U zdrojů, které Rss kanál poskytují, budeme data načítat právě tímto způsobem. Vzhledem k tomu, že se jedná o formát XML, není problém s jeho zpracováním, protože přímo v PHP existuje několik knihoven a funkcí pro práci s XML. Výhodou Rss je, že se zde exportují pouze nejaktuálnější záznamy a odpadá tak nutnost filtrovat nové záznamy. Zdroje, které budeme načítat pomocí Rss uložíme přímo do tabulky zdrojů, protože každý zdroj má svojí unikátní URL. Je potřeba uložit jak URL vlastního zdroje, tak i URL Rss kanálu, ze kterého bude načítání záznamů voláno. 14

RSS - http://cs.wikipedia.org/wiki/RSS

63

3. Návrh Výhodou ukládání přímo načítaných zdrojů je to, že si sami určíme kvalitní české zdroje dat a záznamy nemusíme nijak třídit. Každý záznam musí mít svůj unikátní identifikátor, pomocí kterého lze každý jednotlivý záznam vždy dohledat. Tato unikátní adresa se někdy označuje jako permalink. Díky tomu můžeme rovněž zahazovat záznamy, které jsou již v aplikaci uloženy. Pro každý zdroj dále uložíme datum poslední aktualizace, aby aktualizace začínala vždy od nejstarších zdrojů.

Obrázek 3.10: Ukládání RSS záznamů Nalezené záznamy budeme ukládat do samostatné tabulky dle obrázku 3.10 a ukládat budeme všechny načtené záznamy bez rozdílu. U každého záznamu uložíme rovněž identifikátor zdroje a datum uložení, pro případně řazení a filtrování v závislosti na čase. Všechny záznamy budeme také ukládat do společné tabulky „zaznamy“. Důvod si zmíníme záhy v sekci 3.6.10.

3.6.3

Facebook

Facebook poskytuje několik různých způsobů jak vytvořit propojení pro naši aplikaci. Od integrace tlačítka „Líbí se mi“, přes Facebook Connect, pro při64

3.6. Návrh sběru dat hlašování pomocí Facebook přihlašovacích údajů až po Graph API, které poskytuje aplikační rozhraní pro získávání uživatelů a vztahů mezi nimi. Pro nás nejdůležitější ale bude PHP SDK, což je přímo sada nástrojů pro PHP, které umožňují volání grafového aplikačního rozhraní (Graph API), pomocí kterého budeme načítat jednotlivé veřejné záznamy. Facebook jako zdroj dat, bude rovněž uložen v tabulce zdrojů, ale pouze jako jediný řádek. 3.6.3.1

Přístup k datům

Pro přístup k rozhraní sítě Facebook je potřeba naší aplikaci zaregistrovat a získat na dva klíče, které následně použijeme v použitém PHP SDK pro OAuth autorizaci. Formát vrácených dat je JSON ale díky knihovně s daty pracujeme jako s asociativním polem. Načítány jsou všechny typy dat, které Facebook poskytuje, počínaje statusy, sdílením odkazů, apod. Aplikační rozhraní poskytuje několik možností, jak načítat relevantní data. Získávat data budeme dle uživatelů, které máme uložené a dále podle klíčových slov ve spojení se zadanou polohou. Bude se jednat o data, která jsou veřejně přístupné, abychom nemuseli od jednotlivých uživatelů získávat povolení pro naši aplikaci. 3.6.3.2

Načítání dle klíčových slov a polohy

První způsob bude načítání dle klíčových slov a dle polohy, pro které slouží koncový bod: https://graph.facebook.com/search Poloha je zde důležitá, protože tím máme možnost vyfiltrovat záznamy, které jsou v českém jazyce. Aplikační rozhraní bohužel neumožňuje filtrování na základě jazyka uživatele a v některých případech to ani není možné, protože někteří uživatelé mají nastavený jazyk na angličtinu, ačkoli píší česky. Pro toto volání použijeme parametry: • center – zeměpisná šířka a délka, oddělené čárkou např. 50.0, 14.4 pro Prahu • distance – vzdálenost od zadaných souřadnic • q – klíčové slovo, podle kterého budeme hledat • limit – maximální počet záznamů pro jedno volání • until – časové razítko (Unix timestamp) udávající od kterého data chceme záznamy načítat Jako klíčová slova použijeme množinu slov, která máme uložena k jednotlivým tématům. Pro každé jednotlivé slovo vytvoříme jeden požadavek. Jako parametr Center použijeme prozatím souřadnice Prahy, ale určitě by 65

3. Návrh bylo vhodné u každého téma ukládat i relevantní polohu, podle které by bylo možno data načítat. Vzdálenost od souřadnic nastavíme 10km. Parametr Until pro nás bude celkem důležitý, protože nám dovolí specifikovat datum posledního načtení dat a tím si částečně zaručíme, že se budou přenášet pouze nové záznamy bez duplicit. Poslední parametr Limit nastavíme až za běhu, dle empirického pozorování, ale vzhledem k použití parametru Until můžeme nastavit Limit na nějakou krajní hodnotu, třeba 100. Pro každé slovo tak musíme ukládat datum poslední aktualizace, abychom při dalším volání mohli předat toto datum jako parametr.

3.6.3.3

Načítání dle uživatelů

Druhou možností, kterou pro načítání dat použijeme, je načítání veřejných profilů uživatelů, které si v aplikaci uložíme. Výhoda tohoto řešení je stejná jako u Rss – budeme mít zaručený zdroj kvalitních dat a budeme mít jistotu, že autoři píšou českým jazykem, na který se zaměřujeme. Nevýhoda je, že musíme tento seznam uživatelů sestavit, nicméně můžeme rovněž využít veřejných seznamů nejsledovanějších uživatelů(13). Dále pak přidáme vybrané akademické zdroje, protože primární použití naší aplikace bude akademické. Načítání probíhá pomocí adresy:

https://graph.facebook.com/{uzivatel}/feed

Kde uzivatel je přímo uživatelské jméno, nebo unikátní číselný identifikátor uživatele. Pomocí tohoto volání dojde k načtení všech veřejných příspěvků na zdi uživatele. Toto volání nemá žádné další parametry. Pro každého uživatele, kterého budeme mít uloženého v samostatné tabulce, učiníme jedno volání Facebook rozhraní.

3.6.3.4

Ukládání záznamů

Všechny nalezené záznamy budou opět ukládány do společné a samostatné tabulky dle obrázku 3.11. Pro každý záznam nesmíme zapomenout uložit permanentní odkaz, aby byl záznam zpětně dohádatelný a identifikátor uživatele, ke kterému se záznam váže. 66

3.6. Návrh sběru dat

Obrázek 3.11: Ukládání Facebook záznamů

U každého uživatele musíme uložit datum poslední změny, abychom mohli obnovovat uživatele od těch nejstarších. V jedné aktualizaci bude totiž voláno pouze omezené množství uživatelů, protože rozhraní má daný časový interval, který nelze překročit. V aplikaci budeme nad tabulkami pracovat pomocí tříd FacebookUsers.php a FacebookItems.php.

3.6.4

Twitter

Sociální sít Twitter, stejně jako Facebook poskytuje aplikační rozhraní, které není v tomto případě grafové, ale klasické typu REST15 . Abychom nemuseli zpracovávat každý požadavek a příslušnou odpověď, je vhodné použít knihovnu, která nám poskytne vhodnou abstraktní vrstvu mezi rozhraním Twitteru a naší aplikací. Rovněž se nemusíme starat o autorizaci naší aplikace. Pro naši aplikaci použijeme knihovnu Twitter-PHP16 , která splňuje všechny naše požadavky. 15 16

REST - http://cs.wikipedia.org/wiki/Representational_State_Transfer Knihovna Twitter-PHP - https://github.com/dg/twitter-php

67

3. Návrh 3.6.4.1

Přístup k datům

Pro přístup k rozhraní je potřeba opět registrace naší aplikace na stránkách Twitteru a oproti tomu dostaneme dokonce čtyři klíče pro OAuth autorizaci. Registrace má rovněž výhodu ve zvýšení limitu ze 150ti denních volání, na 350 dotazů za hodinu. Data získaná přes API jsou ve formátu JSON, ale díky použité knihovně dostáváme přímo asociativní pole, s kterým tak můžeme pohodlně pracovat dále v aplikaci. Získávat data budeme dle uživatelů, které máme uložené. Získávat data by šlo i pomocí klíčových slov ve spojení s polohou, stejně jako u sítě Twitter. Vzhledem k velkému množství uživatelů, které máme uloženo, si prozatím vystačíme pouze s touto jednou metodou. 3.6.4.2

Načítání dle uživatelů

Pro získávání záznamů použijeme prozatím pouze jednu metodu a tím bude načítání veřejných záznamů dle uložených uživatelů. Opět jako u Facebooku budeme mít zaručenou kvalitu dat a jistotu, že záznamy budou od českých autorů. Při získávání seznamu uživatelů můžeme využít přímo monitorovací službu klaboseni.cz, které rovněž poskytuje seznam nejaktivnějších a nejsledovanějších uživatelů v rámci České republiky. Seznam pak rozšíříme o další zdroje manuálně vybraných uživatelů 17 18 a dále o vybrané akademické účty. Pro načítání dle uživatelů voláme adresu: http://search.twitter.com/search.json?q=&rpp=&since_id= s použitím parametrů: • q – vyhledávací dotaz, v našem případě jméno uživatele doplněné o znak na začátku • since_id – číslo posledního záznamu pro daného uživatele • rpp – počet vrácených záznamů Důležitý je pro nás hlavně parametr since_id, protože tím můžeme rozhraní říct, který záznam máme uložený jako poslední a dostaneme tak pouze aktuální záznamy. Pro volání lze využít i parametr lang, kterým by mělo jít specifikovat jazyk, což by pro naše použití bylo velice žádoucí. Dle pozorování se ale na tento parametr nelze spoléhat a české záznamy mají tento parametr nastavený všelijak, nejspíše dle nastavení Twitter klienta, operačního systému, nebo webového prohlížeče. 17

http://www.reflex.cz/clanek/zpravy/45764/15-nejlepsich-ceskych-twitteru-podlemilose-cermaka-ubavi-nas-twitter-k-smrti.html 18 http://beta.topicleaders.com/cs/vyvojari

68

3.6. Návrh sběru dat 3.6.4.3

Ukládání dat

Načtené záznamy ukládáme opět do společné a samostatné tabulky, včetně identifikátoru uživatele a zdroje dle obrázku 3.12.

Obrázek 3.12: Ukládání Twitter záznamů Seznam uživatelů máme uložený rovněž v samostatné tabulce a pro každého uživatele budeme ukládát datum posledního obnovení a dále číslo posledního záznamu (last_tweet_id), které pak slouží pro další získávání záznamů, prostřednictvím parametru since_id.

3.6.5

Foursquare

Foursquare poskytuje rovněž dobře použitelné aplikační rozhraní a stejně jako v případě Twitteru použijeme knihovnu, která nám zajistí tvorbu a zpracování validních požadavků na rozhraní. Jako knihovnu použijeme PHP-Foursquare19 . 3.6.5.1

Přístup k datům

Foursquare jako geolokační síť umožňuje vyhledávat záznamy vždy jen dle určité polohy, která je určena buď pomocí souřadnic, nebo adresou určitého 19

Knihovna PHP-Foursquare - https://github.com/stephenyoung/php-foursquare

69

3. Návrh místa. Vzhledem k tomu, že nás zajímá hlavně uživatelsky vytvořený obsah, budeme načítat pouze veřejné komentáře (tips) k jednotlivým místům. Formát načítaných dat opět JSON a knihovna nám poskytne přímo asociativní pole. Načítání by šlo dělat i dle uživatelských účtů, nebo pouze podle polohy. Vzhledem k tomu, že je Foursquare pouze doplňkový zdroj dat a máme omezené výpočetní prostředky, vystačíme si zatím se stávajícím načítáním. 3.6.5.2

Načítání dle klíčových slov a polohy

K načítání komentářů dle klíčových slov je určen koncový bod: https://api.foursquare.com/v2/tips/search V dokumentaci se však dočteme, že je doporučeno používat spíše obecnější adresu: https://api.foursquare.com/v2/venues/explore Tohoto se budeme držet a data budeme načítat z tohoto zdroje. Parametry volání jsou následující: • query – klíčové slovo • ll – zeměpisná šířka a délka oddělená čárkou, např. „50.0, 14.4“ pro Prahu • radius – vzdálenost od udaných souřadnic • limit – maximální počet vrácených dat Stejně jako v případě Facebooku omezíme volání pouze na souřadnice Prahy, ale bylo by vhodné, kdyby mohlo jít načítat data v rámci celé republiky, nebo alespoň u každého téma definovat oblast, která nás zajímá. Pro každé klíčové slovo tak učiníme jedno volání a je to prakticky jediný způsob, jak můžeme omezit množství načítaných dat. 3.6.5.3

Ukládání dat

Nalezené záznamy opět ukládáme do společné a samostatné tabulky, včetně data uložení. U každého klíčového slova musíme dále evidovat datum poslední aktualizace, abychom načítali pouze nejstarší slova. 70

3.6. Návrh sběru dat

3.6.6

Pinterest

Pinterest je nejmladší z monitorovaných sítí a v době realizace diplomové práce nemá ještě oficiální API, pouze neoficiální20 . Rozhraní se však již připravuje, takže se ho pokusíme používat, ale musíme počítat s tím, že se ještě může měnit a museli bychom tak upravit část aplikace. Vzhledem k tomu, že ještě není API uveřejněné, neexistuje ani žádná knihovna, která by nám poskytla abstraktní vrstvu nad rozhraním. Nějaké náznaky knihoven jsou již uveřejněné, ale žádná ze zkoušených nefungovala, takže jsem nakonec využil knihovnu Pinterest.api.php21 která se mi po několika úpravách podařila zprovoznit pro naše účely.

3.6.7

Přístup k datům

Formát požadavků i návratových dat je klasicky JSON. Autentifikace je pomocí OAuth, ale prozatím není příslušné klíče kde vygenerovat, takže API autentifikaci nevyžaduje. Pro naše účely budeme načítat hlavně zveřejněné položky a jejich popisky, které odpovídají klíčovým slovům, které máme uloženy. Má to však velikou nevýhodu, protože nelze filtrovat pouze české uživatele, nebo objekty, které pochází z českého prostředí. Ideální by bylo načítat záznamy dle seznamu uživatelů, jako v případě Facebooku, nebo Twitteru, ale žádný tento seznam se mi nepodařilo najít. V případě sítě Pinterest by šlo načítání rozšířit pouze podle uložených uživatelů, protože API neposkytuje žádné vyhledávání na základě polohy.

3.6.8

Načítání dle klíčových slov

Pro načítání záznamů dle klíčových slov slouží koncový bod: https://api.pinterest.com/v2/search/pins/ který má následující parametry volání: • limit – maximální počet vrácených záznamů • page – možnost stránkování záznamů • query – klíčové slovo pomocí kterého se záznamy hledají S tím, že parametr query bude klíčové slovo, podle kterého chceme hledat. Pro každé klíčové slovo bude opět jeden požadavek. Každá získaná položka má naštěstí datum vytvoření, takže alespoň podle tohoto atributu lze zahazovat staré záznamy, které se pak nemusí dále zpracovávat. 20 21

Neoficiální Pinterest API - http://tijn.bo.lt/pinterest-api Knihovna Pinterest.api.php - https://github.com/kellan/pinterest.api.php

71

3. Návrh 3.6.8.1

Ukládání dat

U každého klíčového slova ukládáme datum poslední aktualizace, abychom načítali pouze nejstarší. Ukládání probíhá opět do společné a samostatné tabulky společně s datem vytvoření.

3.6.9

Flickr

Poslední z načítaných sítí bude Flickr, který je stejně jako Foursquare síť pro sdílení fotografií. Jedná se o nejstarší síť a má velice kvalitní REST API a vysoké množství dostupných knihoven, které můžeme použít. Pro práci s API je opět vyžadováno zaregistrovat naší aplikaci. Tím dostaneme dva klíče, které použijeme pro OAuth autentifikaci. Pro přístup k API použijeme knihovnu PhpFlicrk22 , která je již ve verzi 3.1 a jedná se o osvědčenou volbu. 3.6.9.1

Přístup k datům

Všechna získaná data jsou ve formátu XML. Načítat lze prakticky vše od jednotlivých fotografií, přes jednotlivé uživatele a skupiny až po celé galerie. Pouze však veřejné záznamy. Pro nás bude zajímavé hlavně načítání fotografií dle klíčových slov, protože každá fotografie má svůj popisek. Je zde však stejný problém jako u sítě Pinterest, kdy není možné vyfiltrovat pouze české záznamy. Vše tak závisí hlavně na vhodném výběru sledovaných klíčových slov. Vhodné rozšíření načítání záznamů by mohlo být dle tagů, což jsou jednoslovné popisky, které popisují danou fotografii. Jedná se o manuální možnost anotace. Opět není možnost filtrování jazyka, ale dalo by se tak dostat k dalším relevantním datům. 3.6.9.2

Načítání dle klíčových slov

Pro načítání fotografií dle klíčových slov slouží koncový bod: http://api.flickr.com/services/rest/?method=flickr.photos.search který má parametry: • text – hledané klíčové slovo • sort – řazení nalezených záznamů • per_page – počet záznamů na stránku • page – číslo načítané stránky (společně s per_page pro stránkování) • min_upload_date – datum zveřejnění fotky, od kterého se budou záznamy hledat 22

72

Knihovna PhpFlickr - http://phpflickr.com/

3.6. Návrh sběru dat Nejdůležitější je pro nás parametr min_upload_date, pomocí kterého můžeme omezit načítání pouze nových záznamů. Klíčové slovo vyplníme opět dle uložených slov, pro každé slovo zvlášť. Počet načtených záznamů můžeme omezit pomocí parametru per_page. 3.6.9.3

Ukládání dat

U každého slova ukládáme datum poslední aktualizace, které se pak použijí v parametru min_upload_date. Všechny záznamy ukládáme do samostatné tabulky a do společné.

3.6.10

Společné ukládání dat

Při přemýšlení, jak se s daty bude pracovat při filtrování a také při výpisu zjistíme, že vzhledem k tomu, že budeme chtít získávat data ze všech zdrojů, bude potřeba vytvořit databázový dotaz přes všechny tabulky, v aktuálním případě přes šest tabulek, pro šest zdrojů. Tento proces by mohl být dosti zdlouhavý a dále by docházelo k načítání atributů, které zrovna nepotřebujeme (např. poloha, fotografie uživatele, typ zprávy). Samý problém vznikne při hledání záznamů, které vyhovují zadaným klíčovým slovům. Jako řešení jsem zvolil vytvoření databázové tabulky, kam se bude každý záznam duplicitně ukládat. Protože z každého zdroje načítáme jiná data, je potřeba je určitým způsobem namapovat na společnou tabulku. Ve společné tabulce budeme ukládat pouze ty nejdůležitější data, která jsou potřeba pro vypsání záznamu v dashboardu. Tato tabulka je několikrát vidět na diagramech výše, u každého zdroje. Jedná se o: • Identifikátor zdroje • Titulek záznamu (nadpis článku, uživatel, název restaurace, apod.) • Text záznamu (hlavní obsahová část záznamu) • Datum vytvoření • Autor Výhodu tohoto řešení vidím v tom, že veškerá náročná činnost bude probíhat pouze nad jednou tabulkou, kde se dá rovněž vytvořit full-text index. Pokud bude uživatel potřebovat zobrazit detail záznamu, data se načtou z příslušné tabulky, ale bude se jednat pouze o jediný záznam. Vlastní hledání pak bude probíhat nad částí titulek a text. Nevýhodou je redundance, z čehož plyne, že při jakákoliv manipulaci musíme dbát na to, aby se změny projevili v obou tabulkách. Ale to je daň za rychlost. 73

3. Návrh

3.6.11

Návrh integrace jednotlivých importérů

Dle jednotlivých zdrojů je vidět, že každý zdroj bude mít svojí třídu, která se bude starat o import dat a další třídu, která se bude starat o uložení. Dále bude existovat třída, která obstará uložení do společné tabulky, ale mapování si musí řešit každý importér samostatně. Využijeme tak znalostí návrhových vzorů a navrhneme si třídy tak, aby byl celý systém rozšířitelný a veškerá integrace byla proti rozhraní. Použijeme jednak návrhový vzor Strategy pro výběr importovací strategie dle zvoleného zdroje a dále vzor Template method pro implementaci jednotlivých importérů a jednotlivých úložišť, protože pro každé úložiště bude stejné, že nejdříve uloží záznam do společné tabulky a pak do vlastní, dle obrázku 3.13.

Obrázek 3.13: Diagram návrhu importérů

Ve třídě Servers.php se určí, který importér se pro daný zdroj použije. Na diagramu jsou znázorněny pouze dva importéry, pro Facebook a Twitter. Ve výsledné aplikaci jich je ale mnohem více, pro každou službu jeden. Každý importér musí implementovat metodu updateItems(), která zajišťuje načtení nových záznamů ze zdroje. 74

3.6. Návrh sběru dat

Obrázek 3.14: Diagram návrhu úložišť

Opět jako u importérů jsou v diagramu 3.14 vyznačena pouze dvě úložiště, pro Facebook a Twitter. Úložiště, která chtějí ukládat do své tabulky a zároveň do společné, tak dědí po třídě BaseItems, která tuto funkcionalitu pomocí metody saveItem() implementuje. Pokud by úložiště chtělo dělat vše samostatně, akorát implementuje rozhraní IItems. Takto navržená struktura tříd nám zaručí, že nebude problém v budoucnu přidat importér pro další vybranou sociální síť, nebo zdroj dat. Vše tak, aniž bychom zasahovali do stávající implementace. Bude tak dodržen Open-Close princip, který říká, že jednotlivé třídy by měli být otevřené pro spolupráci a rozšíření, ale uzavřené pro modifikaci.

3.6.12

Sloučení zdrojů do skupin

Poslední větší úpravou bude sloučení zdrojů do skupin. Důvod je ten, že pro Rss kanály může být vloženo stovky zdrojů, ale uživatel nebude chtít procházet každý zdroj samostatně. Z tohoto důvodu jsem navrhnul skupiny, kam zdroje roztřídím. Navržené skupiny jsou: 75

3. Návrh • Články – seskupení všech Rss zdrojů, kde je vytvářen profesionální obsah, nebo články – všechny denní zpravodajství, aktuální zprávy, články z blogů ad. • Diskuze – seskupení všech diskuzí a obsahu, který vytváří běžný uživatel • Facebook – pouze síť Facebook • Twitter – pouze síť Twitter • Flickr – pouze síť Flickr • Pinterest – pouze síť Pinterest • Foursquare – pouze síť Foursquare • Vysoké školy – seskupení akademických zdrojů, jak článků, tak diskuzí Jako budoucí rozšíření by se dalo navrhnout, že by si uživatel mohl vytvářet vlastní skupiny, do kterých by řadil vybrané zdroje. Například „Blogy o jídle“, „Konkurenční firmy“ a další. Diagram 3.15 zobrazuje navržení uložení jednotlivých skupin zdrojů.

Obrázek 3.15: Sloučení zdrojů do skupin Uživatel tak bude pracovat s celými skupinami a ne s každým zdrojem samostatně. V aplikaci zajistíme funkce pomocí třídy Groups.php.

3.7

Návrh filtrování a indexace

Ve chvíli, kdy máme nasbírána nějaká data, je potřeba je začít filtrovat, aby se uživatelům zobrazovala pouze data, která odpovídají nastaveným klíčovým slovům a tématům. Vyhledávání bude tedy probíhat na základě full-textového vyhledávání v názvu a textu každého záznamu. Toto vyhledávání je závislé na 76

3.7. Návrh filtrování a indexace vybrané technologii, pokusím se tedy rozebrat všechny možnosti, které máme, při vyhledávání v MySQL. V dokumentově orientovaných databázích bychom se zajímali o technologie jako je Lucene, ElasticSearch a další.

3.7.1

Rešerše dostupných řešení

Pro vyhledávání v rámci MySQL můžeme využít buď možností, které nám poskytuje přímo MySQL databáze, nebo zvolit některé z externích vyhledávacích nástrojů, kde bude zpracováno pouze full-text vyhledávání, ale zbytek dat bude uložen pořád v MySQL. Začněme tedy možnostmi samotným MySQL a dále pak zmíním samostatné nástroje v kontextu MySQL, ale každý z vyhledávacích nástrojů lze použít i nad databází typu NoSQL. 3.7.1.1

Vyhledávání v MySQL pomocí operátoru LIKE

První a nejjednodušší možností vyhledávání v databázi MySQL je operátor LIKE, který funguje v následující syntaxi: SELECT id_zaznamu FROM zaznamy WHERE text LIKE ’%keyword%’ Tímto SQL dotazem získáme všechny záznamy, kde se ve sloupci text nachází slovo keyword. Tento způsob se hodí ale pouze pro jednoduché typy hledání, například hledání produktů v e-shopu, pro složitější dotazy využijeme možnost jinou.

3.7.2

Fulltext vyhledávání v MySQL pomocí operátorů MATCH a AGAINST

Pro složitější fulltextové dotazy lze použít dvojici operátorů MATCH a AGAINST, které jsou v MySQL dostupné od verze 3.2. Syntaxe zápisu je: SELECT * FROM zaznamy WHERE MATCH(text, nadpis) AGAINST (’keyword1’‚ ’keyword2’) Fulltextové vyhledávání má dvě varianty: • Vyhledávání v přirozeném jazyce23 - funkce MATCH společně s AGAINST vrací s každým nalezeným výsledkem rovněž relevanci, podle které jsou pak výsledky seřazeny. • Boolean vyhledávání24 – které dovoluje používat operátory zpřesňující výsledky – operátor „+“ pro zahrnutí slova, operátor „–“ pro vyjmutí slova. 23 24

http://dev.mysql.com/doc/refman/4.1/en/fulltext-search.html http://dev.mysql.com/doc/refman/4.1/en/fulltext-boolean.html

77

3. Návrh Použití operátoru u boolean vyhledávání pak vypadá následovně: SELECT * FROM zaznamy WHERE MATCH(text, nadpis) AGAINST(’+apple -macintosh’ IN BOOLEAN MODE) Najde výsledky, kde se objevuje slovo apple, ale ne společně se slovem macintosh. Pro obě varianty platí, že se ignorují běžná anglická slova, která jsou bezvýznamná, a minimální délka indexovaného slova je čtyři znaky. Oba tyto parametry lze nastavit pomocí proměnných ft_stopword_file (seznam slov, které se neindexují) a ft_min_word_len (celé číslo definující minimální délku slova). U vyhledávání v přirozeném jazyce se navíc ignorují slova, která jsou obsažena alespoň v polovině záznamů. Pro správné fungování vyhledávání v přirozeném jazyce je potřeba na sloupec, ve kterém vyhledáváme, nastavit index typu FULLTEXT. Tento index lze nastavit pouze na sloupce typu TEXT, VARCHAR a CHAR. Pro Boolean vyhledávání není index vyžadován, ale vyhledávání je tak pomalejší. 3.7.2.1

Sphinx

Jedná se o samostatné vyhledávací řešení, které běží na serveru jako aplikace (démon). Pro správný běh je tedy nutné spustit programy indexer (pro indexování dat) a program searchd (pro vyhledávání). S databází lze komunikovat přes TCP pomocí vlastního protokolu, nebo je klientská část dostupná i jako MySQL Storage Engline plugin, takže můžeme využít stávající MySQL konektor v rámci naší aplikaci. Pro většinu běžných jazyků existují knihovny, takže jsme od používání odstíněni. Dle některých článků je problematická prvotní instalace a nastavení. Dále se krkolomně používá a má i problémy se správným ohýbáním slov. Třeba na dotaz „java“ vrací slova „jaký“, „jako“, „já“. Na „aleš“ vrací „ale“. Obtížnější je také změna indexů, takže se nehodí v aplikacích, kde se data hodně mění. 3.7.2.2

Lucene

Jedná se o knihovnu, která je napsaná v jazyce Java, takže je to multiplatformní řešení uvolněné jako open-source. Jedná se o velice robustní a snadno škálovatelný vyhledávací nástroj, nad kterým lze stavět další technologie. Podporuje velice rozšířitelné dotazy nad daty. Používán je např. u sociální sítě Twitter. Kromě vyhledávání umožňuje i další práci se slovy, ohýbání, opravy překlepů, zvýrazňování nalezených slov a další. 3.7.2.3

Ostatní fulltext nástroje

Existuje další množství vyhledávacích nástrojů, které by šlo použít, namátkově Apache Solr, Cassandra, Xapian, Sherlock Holmes. Všechny nástroje se liší 78

3.7. Návrh filtrování a indexace pouze v detailech, nebudeme je proto rozepisovat. Jedná se však o vyhledávací technologie, které mohou pracovat jak s databází typu MySQL, tak i NoSQL.

3.7.2.4

Vybrané řešení

Jako vybrané řešení jsem zvolil interní vyhledávání pomocí operátoru LIKE a nebo pomocí MATCH a AGAINST operátorů. Pro obě řešení je výhodou je obrovské množství návodů, kvalitní dokumentace a využití technologií, které již mám k dispozici. Nemusím se starat o instalaci dalšího software a následné konfigurace. Pokud by se toto řešení pomocí operátoru LIKE ukázalo jako nevyhovující, budeme dále zkoušet experimentovat s operátory MATCH a AGAINST. Pokud by ani to nestačilo, přistoupil bych k instalaci nástroje Sphinx, které je pro MySQL doporučováno a lze se dočíst spoustu kladných referencí i přes prvotní obtížnou konfiguraci.

3.7.2.5

Vlastní návrh vyhledávání

Vyhledávání bude spouštěno nezávisle na akcích uživatele, aby byla data předem připravena. Nalezené záznamy pro každé klíčové slovo, budou ukládány redundantně do samostatné tabulky, abychom nemuseli data vyhledávat při každém načtení aplikace, nebo volbě filtrů. Operace nad touto tabulkou a vyhledávání záznamů zajistíme pomocí třídy ItemsCacher.php a záznamy budeme ukládat do tabulky „topics_zaznamy“, dle diagramu3.16. 79

3. Návrh

Obrázek 3.16: Redundantní ukládání nalezených záznamů U každého klíčového slova ale musíme ukládat poslední identifikátor záznamu, který se podařilo nalézt, abychom příští hledání nemuseli dělat přes celou množinu uložených záznamů, ale pouze od posledního nalezeného. Při každém spuštění vyhledávání budeme brát pouze omezenou množinu slov a rovněž budeme dotaz omezovat na desítky nalezených záznamů, aby celkové zpracování nezabíralo více jak minutu strojového času. Vzhledem k tomu, že se bude vyhledávání spouštět opakovaně každou hodinu, očekává se, že se postupem času povede projít všechny záznamy pro všechna klíčová slova.

3.8

Návrh výpisu a vizualizace dat

Nyní navrhneme výpis a vizualizaci, tak aby to zahrnulo tyto případy užití: vizualizace nalezených dat, zobrazení detailu záznamu, filtrování sesbíraných dat, exportování dat. Aplikace bude data znázorňovat třemi způsoby: • Textově – na obrazovce, která bude dostupná přes záložku Dashboard. • Graficky – v sekci Analýza dat, kde budou zobrazena data pomocí grafů. • Export syrových dat – poslední speciální možností bude export dat. 80

3.9. Model aplikace (PSM) Všechny formy budou zobrazovat ta samá data. V textové formě půjde o výpis jednotlivých záznamů pod sebou, kde každý záznam bude mít odkaz na detailní informace. Záznamy bude možnost filtrovat dle zdroje a tématu. V grafické formě budou data zobrazována pomocí grafů Google Graph25 a nebude se operovat na úrovni jednotlivých záznamů, pouze se zobrazí četnosti záznamů v závislosti na čase. Zobrazená data půjde opět filtrovat dle zdroje a tématu. V poslední formě budou data exportována do zvoleného formátu a rovněž půjde vybrat skupinu zdrojů a téma, které chceme exportovat (nebo všechna témata). Textový výpis bude užitečný pro zobrazení konkrétních záznamů a jejich detailů. Grafické zobrazení se tak bude hodit hlavně pro srovnávání různých zdrojů a témat v časovém rozměru. Export bude sloužit hlavně pro uložení surových dat do externího formátu pro další zpracování, nebo analýzu.

3.9

Model aplikace (PSM)

Protože již máme vybranou platformu a navržené jednotlivé části aplikace, můžeme PIM (Platform Independent Model) z analytické části přetransformovat na PSM (Platform Specific Model). Výhodou tohoto přístupu je, že pokud bychom chtěli změnit platformu, například za mobilní aplikaci, nemusíme dělat celou analýzu a návrh od začátku, ale můžeme využít stávající PIM a udělat nový návrh a transformaci na PSM pro novou platformu. Všechny diagramy jsou dostupné na přiloženém CD buď jako zdrojový soubor pro Enterprise Architect, nebo jako vyexportovaný obrázek PNG.

3.9.1

Diagram tříd (Class diagram)

Diagram tříd popisuje pouze vlastní model aplikace, nejsou v něm tak obsažené všechny pomocné (servisní) třídy a knihovny. Dále jsem s ohledem na přehlednost všechny třídy týkající se importérů a ukládání (storage) umístil jako balík tříd. Také v digramu není abstraktní předek všech persistentních objektů PersistentObject.php, který je vyznačen u každého potomka v hlavičce třídy. Výsledný class diagram je vzhledem k rozměrům umístěn jako příloha A.1.

3.9.2

Datový model (Databázový model)

Datový model nám bude sloužit jako předloha k vytvoření databáze. Tabulky, které jsou určené pro každý typ zdroje, jsem umístil do samostatného balíku, protože jinak by byl diagram opravdu rozsáhlý. Dále zde chybí tabulky pro uložení administrátorů (admins) a pro uložení statických stránek (kategorie). Výsledný datový model je vzhledem k rozměrům umístěn jako příloha A.2. 25

https://google-developers.appspot.com/chart/

81

3. Návrh

3.10

Diagram nasazení

Diagram nasazení znázorňuje, jak bude výsledná aplikace nasazena a kontext jednotlivých částí.

Obrázek 3.17: Diagram nasazení Znázorněny jsou i klientské stanice, aby bylo vidět, že vlastní produkt je nezávislý na platformě.

82

Kapitola

Implementace V návrhové části jsme si navrhli základní prototyp naší aplikace a vybrali platformu, na které budeme aplikaci implementovat. Dále jsme si vytvořili základní architekturu a navrhli, jak budeme sbírat data z jednotlivých zdrojů a jak budeme uložená data indexovat a vyhledávat v nich. Protože máme již vše připraveno, je na řadě samotná implementace všech navržených částí. Výstupem bude základní funkční aplikace, která by měla splňovat všechny požadavky, které jsme si stanovili, a rovněž bude dále rozšířitelná v rámci budoucích vylepšení. Popisovat budeme pouze implementaci uživatelské části mimo administrace, která bude sloužit pouze pro pohodlnější přístup k datům nad MySQL databází.

4.1

Grafický vzhled aplikace

Dle navrženého prototypu aplikace a navržených wireframů by v tomto kroku mohla začít tvorba grafického návrhu. Vzhledem k tomu, že hlavní cíl aplikace je práce s daty, vystačíme si se základním vzhledem prototypu a budeme ho považovat za finální grafický návrh. V průběhu tvorby jednotlivých částí systému grafický návrh obohatíme o různé grafické prvky, které umožní lepší orientaci v aplikaci, například ikonky, barevná podbarvení a podobně. Důraz bude kladen hlavně na rychlou a intuitivní práci. Finální grafický návrh bude stejně jako prototyp implementovaný pomocí značkovacího jazyka HTML5 a grafický vzhled bude doplněn pomocí kaskádových stylů (CSS). Případné efekty, nebo skripty budou implementovány pomocí JavaScriptu, konkrétně s využitím frameworku jQuery26 . 26

JavaScript framwwork jQuery - http://jquery.com/

83

4

4. Implementace

4.2

Tvorba základní struktury aplikace

Nejprve ze všeho si implementujeme základní strukturu aplikace, na které pak budeme stavět vlastní funkcionalitu dle sestavených případů užití. Tato základní struktura musí umět zpracovat URL adresu (resp. HTTP požadavek) a dle toho vykonat příslušné akce. Pokud vznikne určitá chyba, nebo neplatný požadavek, musí se zobrazit varování, nebo chybová stránka.

4.2.1

Základní adresářová struktura

Nejdříve si vytvoříme základní adresářovou strukturu, dle obrázku 4.1, abychom měli všechny soubory roztříděné a programování tak bylo přehledné.

Obrázek 4.1: Adresářová struktura aplikace

Ve složce admin se bude nacházet administrace webu, přístupná pouze pro administrátora. Složka cache bude sloužit pro dočasné soubory a nesmíme zapomenout nastavit její práva pro zápis. Složky css, img a js budou sloužit pro uložení stylů, obrázků a souborů JavaScript pro implementaci šablon aplikace. Ve složce lib budou všechny knihovny a části třetích stran. Do adresáře log budeme zaznamenávat průběhy importů, nebo chyby. Ve složce models bude uložen vlastní model aplikace a ve složce php jednotlivé kontroléry. Složka templates je určena pro šablony stránek a složka upload pro obsah nahraný přes administraci webu, který se vztahuje ke statickým stránkám, rovněž s právy zápisu do složky. 84

4.2. Tvorba základní struktury aplikace

4.2.2

FrontController

Začneme implementací dle návrhového vzoru FrontController, který funguje tak, že všechny příchozí požadavky na aplikaci se přesměrují na soubor index.php ve kterém se rozhodne, co se bude dělat dále. V tomto souboru se zajistí načtení všech potřebných knihoven, souborů a dále zde dojde ke zpracování URL, kontrole přihlášení a provedení všech činností, které je potřeba udělat pro každý požadavek. Nasměrování na tento jeden soubor se řeší v rámci speciálního souboru .htaccess, který je uložený v kořenovém adresáři a webový server Apache s ním umí pracovat a dle jeho obsahu konfigurovat své chování. Všechny požadavky se tak řeší pouze jednou na jednom místě a jejich zpracování nemusí být řešeno duplicitně v každé stránce aplikace.

4.2.3

MVC

Další částí je implementace MVC. Vzhledem k tomu, že model aplikace a kontroléry budou jako klasické PHP skripty a PHP třídy, musíme implementovat akorát šablonovací systém. Pro to jsme vybrali knihovnu Smarty, takže provedeme její načtení a nastavení složky pro dočasné soubory (/cache). Vytvoříme základní třídy modelu aplikace, dle class diagramu, který jsme vytvořili v návrhové části a dále PHP soubory a šablonu pro každou samostatnou stránku. Ve vytvořených modelech (třídách) budeme dále implementovat dílčí funkce aplikace pomocí jednotlivých metod. V PHP skriptech budeme tyto funkce volat a výstupy posílat do připravených šablon. V šablonách akorát provedeme vykreslení dat a ovládacích prvků (formulářů, tlačítek, odkazů). Uživatelské akce opět zpracujeme v kontrolérech.

4.2.4

Připojení k databázi, vytvoření databáze

Připojení k databázi bude klíčová funkce aplikace, protože v databázi budeme mít uložena všechna data. Pro připojení lze využít základní funkce PHP s prefixem mysql, ale my si napíšeme jednoduchou třídu Database.php, která bude dle návrhového vzoru Singleton, protože připojení do databáze bude existovat pouze jedno a bude využíváno z více míst aplikace. V této třídě budou implementovány základní operace s databází a rovněž ošetření případných chyb. private static $instance = null; public static function getInstance() { if(!(self::$instance instanceof Database)) { self::$instance = new Database(); self::$instance->connect(); } return self::$instance; } 85

4. Implementace Třída vrátí svojí instanci, která pokud neexistuje, tak se vytvoří. Když máme třídu implementovánu, vytvoříme si všechny databázové tabulky dle datového modelu aplikace, který jsme si vytvořili v návrhové části. Ze začátku budeme s daty pracovat přímo přes program phpMyAdmin, který umožňuje práci s databází na úrovni jednotlivých tabulek. Můžeme si tak ručně vytvořit např. uživatelský přístup do aplikace, nebo naplnit první sledované zdroje. V další části pak vytvoříme i administraci, abychom mohli s administrací pracovat pohodlněji.

4.2.5

Persistence tříd

Protože skoro všechny třídy v naší aplikaci budou komunikovat s databází. Implementujeme tedy abstraktní třídu PersistentObject.php, která bude jako společný předek všech těchto tříd. Výhodou tohoto řešení je, že každý objekt bude mít již dostupné připojení do databáze bez další inicializace. Vytvoříme si pomocné proměnné, které budou definovat název databázové tabulky a primární index. Tyto proměnné pak v každém potomkovi přepíšeme na konkrétní hodnoty. V PersistentObject rovnou implementujeme základní metody, které budou moct využívat všichni potomci: • getAll() – získání všech položek z dané tabulky • getItem($key, $value) – získání položky dle zadaného klíče a hodnoty • getItems($key, $value) – získání více položek, dle zadaného klíče a hodnoty • addItem($values) – vloží nový záznam s atributy dle proměnné $values • updateItem($key, $value, $values) – úprava existujícího záznamu • deleteItem($key, $value) – smazání záznamu Toto budou metody, které se hodí mít pro každý objekt a zastřešují základní práci s objektem, někdy označované jako CRUD (Create, Return, Update, Delete). Pro získání všech záznamů, nebo vytvoření nového záznamu již není potřeba v každé třídě definovat příslušné metody.

4.2.6

Knihovny z frameworku Nette

Pro pohodlnější práci nasadíme dvě třídy z frameworku Nette. Bude se jednat o: • Nette\Loaders\RobotLoader – třída, která se postará o automatické načtení všech tříd v zadané složce. Odpadá tak nutnost definovat každý soubor samostatně pomocí include_once. 86

4.3. Správa uživatelů, přihlašování • Nette\Diagnostic\Debugger – pokročilá správa chyb, včetně odesílání chyb na email správce aplikace a logování chyb do souboru. Nyní tak máme vytvořenou základní strukturu aplikace, umíme zpracovat každý příchozí požadavek a zobrazit dle toho příslušnou stránku. V případě chyby se zobrazí chybová stránka a odešle se email administrátorovi. Dále pak dochází k automatickému načítání tříd a souborů, které jsou potřeba pro správnou funkci aplikace.

4.3

Správa uživatelů, přihlašování

Tabulku uživatelů již máme vytvořenu, takže nyní akorát vytvoříme přihlašovací formulář a jeho odeslání zpracujeme v příslušném kontroléru, který ověří, že se uživatel nachází v databázi a heslo se shoduje. Pokud uživatel existuje a zadal správné heslo, jeho údaje se uloží do SESSION a aplikace dle toho pozná, že je přihlášený. Při ohlášení tak stačí akorát vymazat obsah SESSION. Veškerou práci s uživateli zajistíme třídou Users.php, která bude pracovat nad tabulkou „uzivatele“. Heslo je uloženo jako „osolený SHA1 hash“, což znamená, že se jedná o klasický SHA1 hash ke kterému je před zpracováním připojen email uživatele. Toto nám zajistí, že pokud mají dva stejní uživatelé stejné heslo, nebudou mít stejný SHA1 hash a nebude tak možnost podle toho určit, že mají stejné heslo. Důležité je, že hesla nejsou uložena jako čistý text. Zaslání zapomenutého hesla implementujeme opět pomocí formuláře, kam uživatel zadá jeho email a po odeslání dojde ke kontrole, zda se email nachází v databázi a pokud ano, pošle se uživateli odkaz, na který musí kliknout, aby ověřil, že se opravdu jedná o jeho emailovou schránku. Po kliknutí na odkaz dojde k zaslání nového hesla s upozorněním, že je vhodné, po přihlášení, heslo co nejdříve změnit.

4.4

Konfigurace monitoringu

Abychom mohli začít sbírat nějaká data, je potřeba, aby měl uživatel možnost specifikovat si témata a zdroje dat, které ho zajímají. Tyto témata si pak definuje sadou klíčových slov. Uvažujeme, že je uživatel již úspěšně přihlášen.

4.4.1

Správa zdrojů

Běžný uživatel nemůže seznam zdrojů upravovat, pouze si může vybrat, které zdroje jsou pro něho zajímavé a podle toho zdroje přiřazovat ke svým vytvořeným tématům. V příslušné stránce tak akorát vypíšeme seznam všech dostupných zdrojů s datem poslední aktualizace. U každého zdroj bude rovněž odkaz na detail, kde se uživatel dozví URL zdroje a další podrobnosti. 87

4. Implementace Stránka bude bez další možné akce. Vlastní přiřazení zdrojů se bude řešit až u správy jednotlivých témat, ke kterým budou zdroje přiřazovány. U správy témat komunikujeme s modelovou třídou Servers.php, která nám poskytuje seznam všech zdrojů a dále bude rovněž obstarávat volání jednotlivých importérů, pro každý zdroj.

4.4.2

Správa skupin

Správu skupin implementujeme pomocí třídy Groups.php. V rámci aplikace budeme potřebovat pouze výpis všech skupin a dále možnost připojení (odpojení) skupiny od tématu. Výpis všech skupin témat by měl zobrazit rovněž počet zahrnutých zdrojů s možností výpisu všech obsažených zdrojů.

4.4.3

Správa témat a skupin

Správa témat bude řešena v několika stránkách. Bude se jednat o výpis všech témat, přidání nového téma a nastavení téma. Vkládání a editaci implementujeme opět pomocí formulářů a výpis všech témat vypíšeme v přehledné tabulce. Komunikujeme již s modelem aplikace, konkrétně s třídou Topics.php, která nám zajišťuje veškerou logiku, jako je načtení všech témat pro daného uživatele, přidání tématu, úprava tématu. Na stránce s úpravou tématu vypíšeme rovněž seznam dostupných zdrojů a nabídneme uživateli jejich připojení. Vzhledem k tomu, že jsme si zdroje seskupili do skupin, komunikujeme tak s třídou Groups.php, která nám poskytne seznam všech zdrojů a dále možnost připojení skupiny k tématu. Důležité je, že při každém připojení se musí zkontrolovat, zda uživatel dané téma opravdu vlastní.

4.4.4

Správa klíčových slov

Veškerou logiku implementuji ve třídě Keywords.php. Každé klíčové slovo se váže k tématu, ale ukládání neprobíhá duplicitně. Pokud dva uživatelé vloží to samé klíčové slovo, uloží se pouze jednou. Identifikace uložených záznamů pak probíhá ne podle klíčových slov, ale dle témat, podle kterých se až dohledávají přiřazená klíčová slova. Dále implementujeme metody pro přidání, editaci klíčového slova a vypsání všech slov, které se vážou k tématu a přihlášenému uživateli. Při vkládání je nutné ověřit, zda slovo existuje, či nikoli a následně ho připojit k tématu pomocí klíče. Při mazání klíčového slova musíme rovněž kontrolovat, v kolika tématech se slovo objevuje, abychom věděli, zda slovo od tématu pouze odpojit, nebo zároveň i vymazat ze systému. 88

4.5. Implementace sběru dat

4.5

Implementace sběru dat

Pro každý zdroj máme již navržené určité metody, jak budeme data sbírat. Nyní je potřeba implementovat každou metodu sběru a vymyslet, jak sbírat data bez zbytečných duplicit a takovým způsobem, aby byl co nejlépe využitý komunikační kanál a jednotlivé limity monitorovaných služeb.

4.5.1

Implementace základní struktury

Data budeme ukládat jednak do společného úložiště, nad kterým budeme vyhledávat, a dále bude mít každý zdroj svoje vlastní úložiště. Implementujeme tak základní strukturu tříd, dle návrhových vzorů Strategy a Template Method, přesně dle návrhu, konkrétně dle diagramu tříd. Pro importéry tak vznikne základní struktura: • IImporter – rozhraní každého importéru (metoda updateItems) • BaseImporter – abstraktní předek importéru, dle Template Method, který implementuje základní funkce pro importéry. • ImportManager – kontext pro volbu importovací strategie. Lze zde nastavit strategii a zavolat metodu import(). Tuto metodu budeme volat ze třídy Servers.php, která má na starosti práci se zdroji. Jednotlivé importéry tak můžeme stavět na základě tohoto rozhraní a abstraktní třídy. Pro úložiště si vytvoříme tyto základní třídy: • IItems – rozhraní každého úložiště (metody saveItem, isItemExist, checkItemFeed) • BaseItems – abstraktní předek těch importérů, které ukládají jak do společné tabulky, tak do svojí vlastní. Jednotlivé úložiště se pak už nemusí starat o ukládání do společné tabulky, akorát si implementují ukládání do svého úložiště. • CommonItems – implementace společného úložiště. Pro importování si vytvoříme ještě pomocnou třídu ImportLogger, která bude zajišťovat ukládání záznamů o importu dat. Datum spuštění, ukončení importu, počet uložených záznamů a zda-li se import povedl, nebo ne.

4.5.2

Společný importér a úložiště

Společné úložiště bude implementováno pomocí třídy CommonItems a voláno bude v abstraktním importéru BaseImporter. Pro správnou funkci, je potřeba, aby každý dále implementovaný importér splnil dvě podmínky: 89

4. Implementace • Jako URL je potřeba vždy předávat permanentní odkaz (permalink) na nalezený záznam, tak aby každý záznam v databázi měl unikátní adresu a mohli jsme podle ní určit, zda je záznam již uložen, nebo nikoli. • Každé přidané úložiště, které bude chtít ukládat do společné tabulky, musí implementovat funkci mapItemToCommonItem, která je předepsaná abstraktní třídou BaseItems. V této funkci bude provedeno namapování zdrojových položek na položky společné. • Záznam, který je uložený ve své tabulce a zároveň ve společné tabulce musí být provázán přes číselný identifikátor (id_zaznamu). Tímto máme implementovánu základní strukturu ukládání dat, na které lze postavit neomezené množství importérů, pro každý jednotlivý zdroj, bez zásahu do stávající struktury. Pro každý typ zdroje je potřeba implementovat jeden importér a pro každý typ záznamu jedno úložiště.

4.5.3

Rss

První ze sledovaných zdrojů jsou Rss kanály, které jsou uloženy jednotlivě v tabulce zdrojů a můžeme je získat pomocí třídy Servers.php. Implementujeme importér RssImporter.php, který bude dědit od abstraktního BaseImporter.php. Nyní stačí akorát naprogramovat metody updateItems, která bude číst jednotlivé zdroje a volat úložiště. Důležité je záznamy ukládat v opačném pořadí, než jsou získány, protože jinak by došlo k prohození pořadí. Pro každý ukládaný záznam voláme metodu processFeed, která zajistí převod data na správný databázový tvar. Struktura Rss je taková, že jednotlivé záznamy jsou definovaný jako prvky . Pomocí Xpath rozšíření můžeme tyto prvky ze zdroje získat. Xpath dotaz a celkové uložení bude velice jednoduché: foreach( $xml->xpath(’//item’) as $key => $item ) { $item = $this->processFeed($item); $storage->saveItem($item); } V úložišti RssItems.php akorát provedeme namapování položek na společné a uložení, to je vše. Pro každý zdroj uložíme datum posledního čtení. Počet načítaných zdrojů v jednom importu omezíme na 50, aby import netrval dlouho.

4.5.4

Facebook

Jako první je potřeba zaregistrovat naší aplikaci do sítě Facebook a získat autorizační klíče, které použijeme jako parametr při volání PHP SDK knihovny, 90

4.5. Implementace sběru dat která zajistí příslušná volání aplikačního rozhraní. Volání budeme provádět dvě, jednak dle uložených uživatelů a dále dle uložených klíčových slov. Pro volání dle uživatelů je potřeba implementovat třídu FacebookUsers.php, která nám zajistí práci s uloženými uživateli. Pomocí této třídy pak získáme seznam uložených uživatelů. V jednom volání obnovíme pouze 30 uložených uživatelů a pro každého uživatele načteme posledních 10 položek. To je dohromady maximálně 300 záznamů za hodinu. Limit aplikačního rozhraní je jeden dotaz za sekundu, takže 3600 dotazů za hodinu. Oba parametry implementujeme jako konstanty, takže bude možné je v budoucnu nastavovat. Záznamy pro jednotlivé uživatele voláme jako: $facebook->api(’/’ . $q . ’/feed’, ’GET’, $params); Kde proměnná q je uživatelské jméno vybraného uživatele a v proměnné params je uložený akorát limit počtu načítaných položek. Pro volání dle klíčových slov máme již připravenou třídu Keywords.php, takže pro každé volání zjistíme 10 nejstarších klíčových slov a pro každé slovo načteme 50 nejnovějších záznamů, maximálně tak 500 záznamů v jednom volání. Pro volání dle klíčového slova voláme: $facebook->api(’/search’, ’GET’, $params); Kde v proměnné params předáváme klíčové slovo, polohu (dočasně nastavené souřadnice Prahy), časovou značku, která určuje datum posledního načtení a limit určující kolik záznamů chceme získat. Získané záznamy pomocí FacebookItems, kde i provedeme namapování na CommonItems. Pro každého uloženého Facebook uživatele uložíme datum posledního obnovení a pro každé klíčové slovo rovněž. Každý uložený záznam obsahuje kromě vlastní zprávy rovněž identifikátor uživatele, podle kterého můžeme vyhledávat související záznamy.

4.5.5

Twitter

Pro síť Twitter implementujeme TwitterImporter.php, pro který bude potřeba opět naší aplikaci zaregistrovat a získáme tak čtyři konstanty pro nastavení Twitter knihovny. Načítání záznamů provádíme pouze podle seznamu uložených uživatelů, takže si implementujeme třídu TwitterUsers.php, která nám zajistí práci s těmito uživateli. Pro načtení záznamů získáme z třídy TwitterUsers.php 30 nejstarších uživatelů a pro každého uživatele načteme 30 nejnovějších záznamů, což je maximálně 900 záznamů. Limit aplikačního rozhraní je 350 záznamů za hodinu, takže je možné, že se někdy nestáhnou úplně všechny možné záznamy. Výhodou je, že pro každého uživatele ukládáme identifikátor posledního načteného záznamu, který lze jako parametr uvést při volání, čímž se počet načítaných záznamů rapidně sníží: 91

4. Implementace $tweets = $twitter->search(array( ’q’ => "@" . $user["nick"], ’since_id’ => $user["last_tweet_id"], ’rpp’ => self::MAX_TWEETS_COUNT)); )); Takto získané záznamy musíme před uložením upravit – doplnit permanentní URL pro každý záznam a dále upravit odkazy, aby byly klikatelné. Záznamy ukládáme pomocí třídy TwitterItems, stejně jako u ostatních zdrojů. U Twitter záznamů je zajímavé, že se ukládání identifikátor uživatele, ale i identifikátor druhého uživatele, pokud byla zpráva myšlena jako odpověď. Dle toho lze pak v budoucnu dohledávat kontext zpráv a návaznosti.

4.5.6

Foursquare

Pro načítání se sítě Foursquare potřebujeme opět aplikaci zaregistrovat a nastavíme si tak dva klíče potřebné pro přístup přes API pro vytvořený FoursquareImporter.php. Načítání záznamů voláme pouze podle uložených klíčových slov prostřednictvím třídy Keywords.php. Pro každé volání bereme 60 klíčových slov a počet načítaných záznamů omezujeme na 100 záznamů na slovo, což dává maximum 600 záznamů, které se ale většinou nepovede naplnit. Limit je pak 200 volání na jednu metodu za hodinu. Volání API pak provedeme pomocí: $foursquare->GetPublic("venues/explore", $params); Čímž dojde k načtení všech komentářů, které vyhovují dle zadaného klíčového slova, které nastavíme v proměnné params. Dalšími parametry je poloha (napevno nastavené souřadnice Prahy) a maximální počet záznamů. Záznamy jsou posílány jako vícerozměrné pole, takže vytvoříme funkci flatten_array, která nám z vícerozměrného pole vytvoří jednorozměrné, za použití prefixů. Tato data zpracujeme, doplníme permanentní URL a uložíme pomocí FoursquareItems.php do databáze. U Foursquare záznamů je zajímavé ukládání souřadnic a přesné adresy pro každý komentář.

4.5.7

Pinterest

Pro Pinterest neexistuje oficiální API, takže není nutné se ani registrovat. Načítání záznamů provádíme pomocí PinterestImporter, který pracuje s tabulkou uložených klíčových slov, a záznamy načítáme pomocí knihovny takto: $results = $pinterest->get("/search/pins/", array( ’limit’ \=> self::MAX_ITEMS_COUNT, ’page’ => 1, ’query’ => trim($slovo) )); 92

4.5. Implementace sběru dat Načteme tak všechny komentáře, které se váží k danému slovu. Pro každý import voláme 50 klíčových slov a pro každé slovo nastavíme proměnnou limit na číslo 30. V každém volání tak získáme maximálně 150 záznamů. Aplikační rozhraní není zatím nijak omezeno. Každý záznam uložíme pomocí PinterestItems a načtené klíčové slovo označíme jako aktuální pomocí časového razítka. I zde je potřeba vícerozměrné pole převést na jednorozměrné. Každý Pinterest záznam má i identifikátor uživatele a zdroj, odkud byl záznam na Pinterest umístně.

4.5.8

Flickr

U sítě Flickr je opět nutné registrace. Implementujeme si tak náš poslední importér FlickrImporter.php, kterým budeme načítat záznamy z této sítě. Knihovna, kterou budeme pro načítání používat, podporuje ukládání mezivýsledků, takže toho využijeme a nastavíme ukládání do naší dočasné složky /cache. Načítání bude prozatím dle klíčových slov, kterých si načteme 30 a počet vrácených výsledků omezíme na 60. To je maximálně 1800 záznamů s tím, že limit je 3600 volání za hodinu. Načítáme pouze výsledky, které nejsou starší než jeden měsíc, ale vzhledem k denní aktualizaci by šlo limit posunout i na jeden až dva týdny. U každého slova rovněž ukládáme datum posledního načtení, ale v tomto případě datum posuneme o měsíc zpět, protože těch záznamů, které se vrací, není mnoho. Volání pak vypadá následovně: $results = $flickr->photos_search(array( ’text’ => trim($slovo), ’sort’ => ’date-posted-desc’, ’per_page’ => self::MAX_ITEMS_COUNT, ’page’ => ’1’, ’min_upload_date’ => $datum )); Čímž získáme záznamy, které uložíme pomocí FlickrItems.php do příslušné databázové tabulky. Nesmíme zapomenout na uložení permanentní URL, protože obrázky jsou po síti distribuované přes více serverů.

4.5.9

Volání jednotlivých importů dat

Volání importů je implementováno ve třídě Servers.php protože ta se stará o uložené zdroje. Každý zdroj má uložený typ importéru, takže lze podle toho zavolat příslušný importér. Funkci pro načítání záznamů pojmenujeme jako updateServers() a voláme jí s parametrem $groups, což jsou identifikátory skupin, které chceme obnovit. Pro obnovení například zdrojů Facebook a Twitter zavoláme: $servers->updateServers(array(’3’, ’5’)); 93

4. Implementace To je důležité, protože nám to umožní obnovovat každý zdroj v jiném čase a server tak bude optimálně vytížený. Zavoláním této metody dojde k získání všech příslušných zdrojů a pro každý zdroj spouštíme následující sadu příkazů: $id_logu = $this->logger->create(’Import $log_title’); $importer = new ImportManager(); $storage = new $importerStorage(); $concreteImporter = new $importerType($storage); $importer->setImportStrategy($concreteImporter); $pocet = $importer->import($feed); $this->logger->setSucceed($id_logu); Nejdříve uložíme záznam o spuštění importu dat. Poté vytvoříme ImporterManagera, kterému nastavíme zvolený importér. Tento importér dostává jako parametr typ úložiště. Nakonec je akorát spuštěn import, kde se proměnou $feed definuje URL zdroje, odkud se bude čerpat. Pokud se vše povede, uloží se záznam o dokončení importu. Tím je vše navržené proti rozhraní, není problém přidat další typ zdroje s příslušným importérem.

4.5.10

Automatické volání

Abychom nemuseli načítání nových dat provádět manuálně, využijeme možností operačního systému Linux, který je nainstalovaný na serveru. Máme zde dostupný nástroj CRON, pomocí kterého si můžeme nastavit akce, které chceme spouštět v definovaný čas. V našem případě se bude jednat o volání určité URL, která bude spouštět volání funkce updateServers, kterou jsme si popsali výše. Sestavíme si tak kalendář, který vypíšeme jako tabulku 4.1 a podle které CRON nastavíme. Vzhledem k tomu, že se veškeré načítání dat ukládá do databáze, můžeme sledovat, z kterého zdroje pochází nejvíce dat a na základě toho upravovat kalendář volání, nebo limity jednotlivých importérů. Průměrné počty nasbíraných dat za jeden měsíc provozu jsou rovněž vidět v tabulce. Rozdíl mezi maximálním počtem a skutečným počtem jsou záznamy, které jsou už uložené, nebo se přes API vůbec neposílají. Počet načítaných dat je silně závislý na změnách klíčových slov v aplikaci a na jejich skladbě, jestli jde o často sdílená slova, nebo nikoli.

4.5.11

Optimalizace sběru dat

Pro optimální sběr dat je nejdůležitějším údajem počet procházených a vložených položek (viz tabulka), který by měl být co nejtěsnější, aby došlo k co největší výtěžnosti kapacity zdroje. Zároveň nesmí být čísla rovna, protože by nešlo určit, zda již nedošlo k zahazování některých dat, které ještě nemáme uložené. 94

4.5. Implementace sběru dat

Služba

Čas načítání dat

Data

Max

Procházeno Vloženo

Twitter

každou hodinu v :00 každé 4 hodiny v :15 jednou denně

30 uživatelů (á 30 záznamů maximálně) 50 zdrojů (á maximálně 100 záznamů) 30 klíč.slov (á 60 záznamů maximálně) 50 klíč.slov (á 30 záznamů maximálně) 60 klíč.slov (á 100 záznamů maximálně) 10 klíč.slov (á 50 záznamů); 30 uživatelů (á 10 záznamů)

800/hod

85/hod

Rss kanály

Flickr

Pinterest

jednou denně

Foursquare

jednou denně

Facebook

společně s Twitter

80/hod

1250/hod 320/hod

60/hod

1800/den 350/den

200/den

1500/den 400/den

70/den

6000/den 80/den

5/den

800/hod

15/hod

200/hod

Tabulka 4.1: Tabulka nastavení CRON

Tento poměr lze regulovat nastavením limitů jednotlivých importérů a počtu uživatelů, nebo zdrojů, které budou v jednom volání zpracovány. Abychom tyto proměnné nemuseli nastavovat ručně, bylo by vhodné implementovat algoritmus, který by tyto proměnné nastavoval automaticky, dle toho, kolik se podařilo stáhnout položek při posledním volání. Stejná optimalizace by šla provést i na úrovni jednotlivých zdrojů, nebo uživatelů. Zdroj, který produkuje hodně záznamů, například diskusní fórum, by se tak volalo častěji, než blog, ze kterého ukládáme jeden záznam týdně. Obě optimalizace jsou tak horký kandidáti na seznamu možných rozšíření. Data necháme týden sbírat a sledujeme přitom, jestli nevznikají nějaké chyby a jestli se vše ukládá správně. Je potřeba dávat pozor na rozsahy sloupců v databázi, jestli nejsou překračovány. Například identifikátor záznamu z Twitteru je sice číslo, ale má 18 míst, takže se podle toho musí nastavit správný typ sloupce. 95

4. Implementace

4.6

Implementace indexace a filtrování

Data už máme nasbírána, nyní je potřeba je protřídit a vybrat pouze ta relevantní, podle nastavených klíčových slov. Navrhli jsme si, že budeme nalezené výsledky ukládat do redundantně do samostatné tabulky a záznamy budeme prozatím vyhledávat pomocí operátoru LIKE. Celý tento proces budeme řešit ve třídě ItemsCacher.php, která bude pracovat nad databázovou tabulkou topics_zaznamy. Hledání záznamů spustíme metodou updateCache, která najde deset nejstarších klíčových slov. Vlastní hledání zastřešuje třída CommonItems, protože se jedná o práci nad společnými záznamy. Ta má metodu fullTextSearch(), která provede vlastní vyhledání a vrátí zpět identifikátory nalezených záznamů. V metodě fullTextSearch() je již databázový dotaz s operátorem LIKE. Celé toto hledání záznamů budeme spouštět jednou za hodinu, společně s načítáním dat ze sítě Twitter. V tabulce, kam budeme nalezené záznamy ukládat, uchováváme tyto informace: • Identifikátor záznamu – pro vazbu na reálný záznam. • Identifikátor tématu – pro rychlejší filtrování dle příslušného téma. • Identifikátor skupiny – pro rychlejší filtrování dle skupiny zdrojů. • Identifikátor klíčového slova – vazba na klíčové slovo, podle kterého by záznam nalezen. • Časové razítko, kdy byl záznam nalezen, což se bude hodit pro zobrazení v grafu. Při získávání nalezených záznamů pro vlastní aplikaci je nutné nejdříve najít seznam identifikátorů a až podle toho příslušné záznamy. Je to ale pořád méně náročné, než záznamy fulltextově dohledávat na vyžádání přes několik tabulek.

4.6.1

Implementace pomocí MATCH

To samé vyhledávání implementujeme pomocí operátorů MATCH, AGAINST a můžeme tak toto řešení porovnat s operátorem LIKE výše. Pro jednoslovné výrazy se oba operátory chovají prakticky stejně, ale pro víceslovné operátory je MATCH daleko lepší, protože dokáže pracovat s upřesňujícími operátory a navíc ještě vrací relevanci nalezených výsledků. Upřesnění probíhá následovně: • apple banana - Obsahující alespoň jedno ze slov. • +apple +juice - Obsahující obě slova. 96

4.7. Implementace vizualizace nalezených dat • +apple macintosh - Obsahující apple, ale pokud obsahovat i macintosh, tím lépe. • +apple -macintosh - Obsahující apple, ale ne macintosh. • +apple macintosh - Obsahující apple, ale neměl by obsahovat macintosh. • apple* - Vše co začíná apple: apple, apples, applesauce, or applet. • „some words“ - Přesná shoda, tak jak je napsáno. Vyhledáváme jak v textu, tak i v titulku záznamu, přičemž výsledná relevance je součet relevance textu a dvojnásobek relevance titulku. Pokud se dané klíčové slovo nachází přímo v titulku záznamu, přiřadí se záznamu větší váha, než když má výskyt pouze v textu. Operátor LIKE bere všechny výrazy jako přesnou shodu. Z tohoto důvodu finální vyhledávání implementuji pomocí operátoru MATCH, oproti původnímu vyhledávání se změní akorát metoda fullTextSearch() a do databáze budeme navíc ukládat ještě relevanci výsledků.

4.7

Implementace vizualizace nalezených dat

Nyní, když máme data sesbírána a vyfiltrována, je potřeba je vypsat uživateli. Na to máme již připravený grafický návrh, takže stačí data získat z databáze a vypsat.

4.7.1

Textová vizualizace

Pro textový výpis budeme potřebovat implementovat stránkování, protože záznamů může být značné množství. Nebudeme zobrazovat plnohodnotné stránkování v podobě číslic a šipek, zobrazíme akorát odkazy „Novější“ a „Starší“, což bude pro procházení záznamů stačit. Počet záznamů na stránku omezíme na deset prvků. Pro každý záznam zobrazíme nadpis, text, datum publikace a zdroj. Podle data publikace budeme záznamy i třídit, tak aby ty nejnovější byly jako první. Každý záznam pak doplníme odkazem pro sdílení, který bude otevírat emailového klienta a vyplní text e-mailu, kde bude odkaz na související záznam. Dále pak doplníme odkaz na detail, pomocí kterého si bude moct uživatel zobrazit detail každého záznamu. Celý výpis doplníme zobrazením aktuálně vybrané skupiny zdrojů a vybraného tématu. Dále vypíšeme celkový počet nalezených záznamů a pořadí záznamů, které jsou zrovna zobrazeny. 97

4. Implementace

4.7.2

Grafická vizualizace

Grafické zobrazení bude zobrazovat ty samá data jako Dashboard, ale budou v závislosti na čase. Uživatel tak bude mít možnost sledovat vývoj záznamů v čase, kde se o daném tématu mluvilo nejvíce a z jaké skupiny zdrojů. Pro vykreslení grafů jsme si vybrali JavaScriptovou knihovnu Google Chart, které předáme tabulková data a ona provede vykreslení pomocí HTML Canvas. Výslednému grafu nastavíme barvy, které příslušejí jednotlivým sociálním sítím a popisky sloupců. Předání dat probíhá pomocí připravené struktury DataTable, do které se data plní jako do tabulky. Plnění dat probíhá přímo v šabloně. Grafy budeme používat řádkové, které dokážou zachytit počty nalezených záznamů v čase, pro každý zdroj samostatně, jako je ukázáno na obrázku 4.2.

Obrázek 4.2: Ukázka řádkového grafu

A dále pak koláčový graf, který se více hodí pro zobrazení podílu jednotlivých zdrojů, viz obrázek 4.3.

Obrázek 4.3: Ukázka koláčového grafu 98

4.8. Práce se záznamy

4.8

Práce se záznamy

Zobrazení nalezených záznamů bude primární funkcí. V některých situacích by se ale mohlo hodit, zobrazení všech informací, které máme o záznamu uloženo, nebo záznam přeposlat.

4.8.1

Sdílení záznamu

Pro sdílení každého záznamu implementujeme jednoduchý odkaz, který umožní uživateli tento záznam odeslat jako přílohu e-mailu. Formát odkazu pak vypadá následovně: sdílet Kde se za {text} dosadí ještě odkaz na záznam a uživatel tak může email prakticky ihned odeslat. Funkce se může hodit například pro informování firemního kolegy, který má na starosti obor, který s vybraným záznamem souvisí.

4.8.2

Detail záznamu

Dále implementujeme funkci zobrazení záznamu, která pro každý nalezený záznam zobrazí veškeré uložené informace a to jak ze společného úložiště (CommonItems), tak i z databázové tabulky, která přísluší danému typu zdroje, kde je podstatně více informací. Pro každý záznam tak můžeme zobrazit: • Všechna data ze společné tabulky – nadpis, text, datum, autor záznamu • Všechna data z tabulky dle typu zdroje – závisí na zdroji, může to být třeba adresa komentáře, nebo odkaz na jiné uživatele • Kompletní informace o zdroji – datum poslední aktualizace, název, adresa odkud data čerpáme (např. Rss kanál) • Odkaz pro zobrazení dalších záznamů z daného zdroje. • Jméno uživatele s odkazem pro zobrazení dalších záznamů daného uživatele. • Jméno souvisejícího uživatele, např. pokud je záznam odpověď na jiný záznam. Rovněž s odkazem na další jeho záznamy. Detail záznamu je dostupný přes odkaz u každého ze záznamů. U některých zdrojů si můžeme dovolit zobrazit ještě více informací, například u záznamů ze sítě Foursquare můžeme zobrazit mapu, kde bude zobrazeno místo vzniku komentáře. 99

4. Implementace

4.8.3

Ostatní záznamy uživatele

Z detailu si také můžeme zobrazit posledních 20 záznamů daného uživatele. Navíc pokud se jedná o uživatele sítě Facebook, nebo Twitter, kterého máme uloženého v naší databázi (slouží pro načítání záznamů), zobrazí se nám i tyto informace, které evidujeme, jako je datum posledního načtení apod. Z jednotlivých záznamů se pak můžeme opět dostat na detaily jednotlivých záznamů.

4.9

Doplňkové funkce

Základní sadu funkcí doplňují funkce doplňkové, pro rozšířenou práci s vlastní aplikací.

4.9.1

Export dat

První z funkcí je export dat, který dokáže vybraná data exportovat do některých z nabízených formátů. Tato funkce se může hodit, pokud chceme uložená data zpracovat některou z externích aplikací, například pro vizualizaci, datamining, nebo pro analýzu sociálních sítí. Pro export dat lze vybrat určitou podmnožinu pomocí volby skupiny zdrojů a témat. Export bude mít dvě možnosti, buď do souboru ve formátu Excel, nebo přímo na obrazovku ve formátu HTML pro snadný tisk. Vlastní export pro formát Excel probíhá vypsáním dat do souboru, který je následovně nabídnut uživateli ke stažení. Oba exporty jsou omezeny na 200 položek.

4.9.2

Vyhledávání

Další z funkcí, která nebyla původně navržená, je vyhledávání. Ukázalo se, že při vkládání slov může být uživatel zmatený, protože neví, jak fungují upřesňující dotazy. Poskytneme mu tak vyhledávání, pomocí kterého si může ověřit, jaké výsledky mu daná klíčová slova vrací. Takto ověřené slovní spojení si pak může vložit ke svému tématu. Vyhledávání implementujeme přímo nad nalezenými záznamy a dále umožníme filtrovat dle zdroje dat. Rovněž zobrazíme nápovědu, vysvětlující zadávání upřesňujících operátorů.

4.9.3

Můj účet

Poslední funkcí je Můj účet, což je stránka v aplikaci, kde se může přihlášený uživatel dozvědět více informací o své registraci, změnit si heslo, nebo osobní údaje. Vlastní logika je realizována pomocí třídy Users.php a pracuje se nad databázovou tabulkou „uzivatele“.

100

Kapitola

Testování V předchozích částech se nám povedlo dle zadání navrhnout a implementovat funkční aplikaci pro monitoring sociálních sítí. Abychom ověřili, že aplikace funguje správně a mohli odhalit případné nedostatky a slabé stránky, je potřeba produkt otestovat. Pro otestování použijeme vybraná testovací data, pro která zhodnotíme uložené záznamy. Dále sestavíme seznam nalezených nedostatků, které by měli sloužit jako podklad pro budoucí rozvoj aplikace. Přístupové údaje k aplikaci jsou přiloženy jako příloha C.

5.1

Testovací data

V zadání a úvodu práce jsme uváděli, že práce bude zaměřena na akademické prostředí. Vzhledem k tomu, že sbíráme data ze širokého spektra služeb, provedeme testování i na obecných a firemních datech. I tak budou akademické zdroje tvořit velkou skupinu témat. Pro testování jsme vytvořili následující sledovaná témata, která definujeme sadou klíčových slov: 101

5

5. Testování Téma Vysokoškoláci Absolventi Středoškoláci Nová budova Majáles Progtest Synergy Pharm

Wedos T-mobile Vodafone mBank Kočí, Bárta RepRap Titanic

Klíčová slova +čvut +fit, čvut „volná místa“ přijímačky thakurova, „budova čvut“, „nová budova čvut“ majáles progtest, #progtest synergypharm, synergypharm, „synergy pharm“, „mladý ječmen“, chlorella wedos t-mobile, tmobile vodafone, vodafone_cz mbank, mbank_cz, mbanka kočí, bárta, šott, škárka RepRap titanic, titanicpo100letech

Poznámka

Oblíbený studentský nástroj. Firma zabývající se prodejem potravinových doplňků. Nejrychleji rostoucí hosting v Čr.

3D tiskárna na plasty. 100 let od potopení.

Tabulka 5.1: Testovací témata Některé z témat byly sledované měsíc, některé kratší dobu, minimálně však jeden týden.

5.2

Zhodnocení testovacích dat

Pro každé téma nyní provedeme zhodnocení, jaké záznamy se podařilo zachytit, jejich relevanci a komplexnost zdrojů. Nejdříve však tabulkově uvedeme počet záznamů, které se podařilo zachytit, aby bylo vidět, na jakém zdroji je které téma nejaktivnější. U jednotlivých zdrojů je dobré si připomenout, jakým způsobem jsou data sbírána. Společně s výběrem klíčových slov to má rovněž velký vliv na počtu a kvalitě záznamů: • Články, diskuze, vysoké školy – RSS kanály, cca 130 ručně vložených českých zdrojů • Facebook – načítání dle klíčových slov z Prahy a okolí a načítání ze seznamu 70 nejaktivnějších uživatelů • Twitter – načítání všech záznamů dle uložených 210 uživatelů 102

5.2. Zhodnocení testovacích dat • Flickr, Pinterest – načítání dle klíčových slov • Foursquare – načítání dle klíčových slov v Praze a okolí Téma Čvut Absolventi Středoškoláci Nová budova Majáles Progtest Synergy Pharm Wedos T-mobile Vodafone mBank Kočí, Bárta RepRap Titanic

P

Člá 20 6 5 0

Disk 4 2 6 0

Faceb 161 0 0 6

Twit 19 1 0 0

Flic 41 0 2 4

Pint 0 0 0 0

Fours 10 1 0 5

Vys.školy 85 340 0 10 1 14 1 16

7 0 0

1 0 0

10 2 13

4 3 0

55 0 39

0 0 108

1 0 0

1 2 0

79 7 160

1 52 29 23 544 0 97

31 22 21 18 17 0 0

7 2086 251 7 75 3 367

43 244 1352 9 58 42 71

1 162 128 27 50 23 150

0 926 223 2 3 25 42

0 5 7 1 0 1 1

0 0 4 0 0 0 0

83 3497 2015 87 747 94 728

Tabulka 5.2: Nalezené záznamy Čvut – klíčové slovo čvut funguje velice dobře a podařilo se najít 340 záznamů, z čehož nejvíce jich bylo na Facebooku a relativně hodně ve skupině vysokoškolských zdrojů, což by se dalo očekávat. Rekordní počet záznamů se podařilo najít i na geolokační síti Foursquare, z čehož plyne, že studenti tuto síť často používají. Z grafů nelze vysledovat žádný významný bod. Absolventi, středoškoláci, nová budova – u těchto témat se projevil ne moc dobrý výběr klíčových slov, kde byla slova dost obecná. Šikovně zvolené bylo slovo „Thakurova“ u tématu nové budovy, které umožnilo najít celkem dost záznamů i když většinou se jednalo o fotografie NTK (Národní technická knihovna). Nejvíce záznamů bylo v článcích a diskuzích. Majáles – jedná se o akci, která probíhá na přelomu dubna a května ve více městech. Mluví se o ní celkem dost, ale naše aplikace zachytila pouze 79 zpráv. Nejvíce na síti Flickr, kde převažovali fotografie z minulých ročníků. Toto lze přisuzovat nejspíš malou množinou sledovaných zdrojů. V případě Majálesu se podařilo objevit závažnou chybu, kdy se nevyhledávalo v názvu lokace, takže jsme přišli zhruba o 20 relevantních záznamů k Majálesu, protože uživatelé již v samotném textu slovo Majáles nepoužili. Progtest – zde se podařilo najít několik velice relevantních dat, vzhledem k výbornému klíčovému slovu, které přesně definuje pouze tuto jednu službu. Při použití vyhledávání v rámci sítě Twitter se však podařilo najít daleko více 103

5. Testování záznamů a to i od uživatelů, které přímo sleduji. Zde se projevila nejspíš shoda náhod, že uživatel, který zprávu napsal, byl zrovna na konci naší fronty a při jeho obnovení již nebyla zpráva aktuální a nenačetla se. Synergy-pharm – toto téma je zajímavé v tom, že se jedná o nový produkt na českém trhu a dříve než se o něm začne diskutovat na klasických médiích, už si o něm lidé povídají na Facebooku. Relativně hodně záznamů bylo nalezeno jako obrázky na sítích Flickr a Pinterest, protože produkty se prodávají rovněž v zahraničí a jedná se právě o zahraniční fotografie. Wedos – nejrychleji rostoucí hostingová služba v české republice, fungující teprve 18 měsíců. Nejvíce se diskutuje na oborových diskuzních fórech a Twitteru. Většina příspěvků jsou dotazy na fungování, výpadky, úroveň podpory. Lidé hledají zkušenosti ostatních, protože nemají v tento mladý produkt ještě důvěru. Pro tuto firmu je monitoring prakticky nutností, protože se zde nachází spousty dotazů a nejasností ze strany (budoucích) klientů. Přes vyhledávání Twitter lze dohledat skoro stejná množina zpráv, jako nám ukazuje naše aplikace. T-mobile, Vodafone – telefonní operátoři jsou klasicky nejdiskutovanějším tématem. U T-mobile převládá síť Facebook díky jejich reklamní kampani Motorkáři, který se virálně sdílí po českém Facebooku. Dokonce je krásně na grafu 5.1 vidět začátek a průběh šíření této kampaně (Facebook je modrý průběh grafu, počínaje 10.4.). Vodafone je zase diskutovaný na síti Twitter, daleko více než T-mobile. To je pro Vodafone důležitý údaj, protože vědí, že se musí zaměřit hlavně na sledování sítě Twitter.

Obrázek 5.1: Graf nalezených záznamů pro téma T-mobile

Kočí, Bárta – jeden zástupce obecných témat. Vedou hlavně zmínky z odborných zdrojů, jako je denní zpravodajství a články. 104

5.3. Splnění nefunkčních požadavků

Obrázek 5.2: Graf nalezených záznamů pro téma Bárta Na grafu 5.2 je krásně vidět, jak se o tomto tématu začalo mluvit a jaký to mělo další průběh. Hlavní nárůst je 13. 4., což je datum, kdy začal soudní proces, ve kterém figuroval Bárta, Kočí a soudce Šott. Všechna jména jsou zahrnuta jako klíčová slova. Titanic – nejvíce zmínek se váže k výročí sta let od potopení a jsou obsaženy celkem vyrovnaně ve všech zdrojích. Zcela však chybí Foursquare a vysokoškolské zdroje, což se dá čekat, ale úplná absence diskuzí je zajímavá.

Obrázek 5.3: Graf nalezených záznamů pro téma Titanic Výročí je datované na 14. 4. a na grafu 5.3 je krásně vidět, že nejdříve se diskutuje v rámci sítě Twitter a pak postupně začíná virální šíření na Facebooku (převážně videa a fotografie).

5.3

Splnění nefunkčních požadavků

V úvodní části jsme si definovali sady funkčních a nefunkčních požadavků, které vyplynuly ze zadání a je potřeba zjistit, zda došlo k jejich naplnění. • Dostupnost – aplikace je dostupná online a za celý běh nebyl zaznamenán jediný výpadek. Aplikace je dostupná jak na běžném počítači, tak i 105

5. Testování na tabletu a chytrém telefonu, ačkoli zde již klesá použitelnost. • Rychlost – díky tomu, že hledáme výskyty předem, filtrování výsledků v aplikaci je velice rychlé. Nejpomalejší částí je vyhledávání dostupné přímo v aplikaci, při kterém se záznamy vyhledávají přímo v celé databázi. • Přehlednost – dle posouzení několika testovacích uživatelů je aplikace, po předchozím mírném zaškolení, přehledná a dokážou jí ovládat. • Rozšiřitelnost – vzhledem k rozumnému návrhu importéru, jejich úložišť a metod importu je aplikace lehce rozšířitelná o další sociální sítě, další uživatele anebo další možnosti vizualizace (tabulkově, grafově). • Relevance – závisí především na volbě klíčových slov - jak jsou tato slova dostatečně unikátní. • Automatické zpracování – načítání i vyhledávání záznamů funguje automaticky. Jediné co chybí je zasílání e-mailových reportů uživateli, aby byl celý proces automatizovaný. • Lokálnost, globálnost – zde se podařilo nalézt určité nedostatky, protože aplikace nenačítá úplně všechny možné zdroje. Našli jsme několik záznamů, které se nepodařilo zachytit. Řešením tohoto problému je zvýšení počtu sledovaných zdrojů, počtu uživatelů a s tím související zvýšení výpočetní náročnosti celé aplikace.

5.4

Nalezené nedostatky

Dále je nutné uvést nalezené nedostatky, které poslouží jako podklady pro budoucí úpravy a vylepšení.

5.4.1

Relevance dat

Relevance dat je hodně závislá na volbě klíčových spojení a na datech, které do aplikace načítáme. Mělo by se tedy zapracovat na optimalizaci načítání dat (více zdrojů, více uživatelů), tak aby se daly výsledky přísněji filtrovat. V aplikaci rovněž ukládáme relevanci, která zatím není nijak započítána. Dalším rozšířením by mohlo být umožnění uživateli zvolit špatný záznam, který by se již příště nezobrazoval a aplikace by se tak dokázala učit.

5.4.2

Výpočetní náročnost

Jednotlivá načítání zdrojů by se měla optimalizovat tak, aby se nejaktivnější zdroje načítali častěji než ty neaktivní. To samé platí i pro konkrétní uložené 106

5.5. Možnosti rozšíření uživatele jednotlivých sítí. Cílem je využít komunikační kanál co nejvíce a přenášet pouze data, která ještě nemáme uložená a která jsou pro nás zajímavá, bez duplicit. Nutnost procházet aplikaci každý den i při nedostatku záznamů Aplikace by rovněž měla umět generovat e-mailové reporty, aby se uživatel nemusel každý den hlásit do aplikace a sledovat nalezené záznamy. Tyto reporty by měli být doplněné o grafy a různé zajímavé pohledy na data.

5.4.3

Nedostatek dat

Aplikace nenačítá dostatečné množství dat. Do budoucna by chtělo rozšířit počet načítaných zdrojů, jak RSS kanálů, tak i dalších sociálních sítí (Google+, LinkedIn). Dále by se mělo načítání stávajících sítí rozšířit o další metody načítání. Například u Twitteru hledat i dle klíčových slov, u Foursquare umožnit ukládat u témat jejich polohu (pokud to má smysl). Špatné filtrování českých zdrojů U sítí Flickr a Pinterest se nepodařilo načítat pouze české zdroje. Na globální klíčová, jako je Vodafone, nebo T-mobile se podařilo najít i zahraniční záznamy. Pro filtrování českého jazyka se nedá spolehnout na konkrétní sít a bylo by dobré implementovat pokročilé lingvistické zpracování, aby se dala klíčová slova skloňovat, pracovat s diakritikou, určit jazyk ad.

5.5

Možnosti rozšíření

Některé z možností rozšíření jsme zmínili přímo v textu. Další rozšíření jsou ta, která by se dali chápat, spíš jako oprava chyb, které jsme uvedli výše. Nyní bych rád stručně sepsal bodový seznam hlavních rozšíření, který by mohl sloužit pro budoucí vývoj aplikace. Veškeré rozšíření byla podrobně rozebrána v předchozích kapitolách. Sběr dat – rozšíření načítání více sítí (YouTube, Google+, LinkedIn). Optimalizace využití přenosového kanálu (prioritní načítání aktivních zdrojů). Rozšířit metody načítání jednotlivých sítí, např. Twitter načítat podle uložených klíčových slov. Načítat záznamy dle uložené polohy pro každé téma. Filtrování českých záznamů dle analýzy textu. Filtrování dat – započítat relevanci výsledků pro řazení v hlavním panelu aplikace, například umožnit řazení dle data, nebo relevance. Možnost určit záznam jako nevhodný a tuto volbu zohlednit pro další hledání. Grafická vizualizace – zobrazení dat i tabulkově. Možnost v rámci grafů vyfiltrovat konkrétní výsledky, které se váží k danému datu, nebo intervalu. Každé datum by mohlo být jako odkaz pro zobrazení konkrétních záznamů. Obecné – možnost určit sentiment záznamu. Generování e-mail reportů včetně grafů. Nastavení doby reportu v „Můj účet“. Pokročilá analytika, míra vlivu jednotlivých uživatelů. Mobilní aplikace pro náhled nasbíraných dat. Centrální úložiště pro uživatele, kde budou ukládány všechny účty v sociálních sítích. 107

5. Testování

5.6

Přehled nasbíraných dat

V době vytváření této kapitoly bylo uloženo přes 170 tisíc záznamů a databázová tabulka zabírala 220 MB, včetně všech redundancí, indexů a pomocných záznamů. Bylo provedeno přibližně 2900 načtení dat v rozmezí dvou měsíců. Množství nasbíraných dat, dle množství: • Twitter – 81000 záznamů, převážně od českých autorů. Tato síť byla implementována jako první. Uložených uživatelů je 214. • RSS kanály – 59000 záznamů z ručně vybraných českých zdrojů. Kanálů je 138. • Flickr – 11000 záznamů dle uložených klíčových slov, bohužel ne jenom českých. • Pinterest – 6600 záznamů, rovněž dle klíčových slov a globálních jako u Flickru. • Facebook – pouze 6000 záznamů. Tuto síť jsem implementoval až nakonec, sběr trval pouze měsíc. Uložených uživatelů je 74. • Foursquare – pouze 203 záznamů, které jsou ovšem vysoce relevantní. Načtené dle uložených slov v Praze a okolí.

108

Kapitola

Závěr Cílem této práce bylo navrhnout a implementovat aplikaci, která monitoruje vybrané sociální sítě, diskuze a zpravodajské kanály v rámci České Republiky. Uživatel má možnost si v aplikaci nastavit, které informace ho zajímají a popíše je pomocí klíčových spojení. Na základě tohoto nastavení jsou mu zobrazovány nalezené záznamy a to jak v textové podobě, tak i v grafické. Podařilo se vytvořit funkční aplikaci, která může sloužit jako dobrý základ pro další rozšíření. Během implementace a testování se podařilo odhalit některé slabé stránky a nedostatky, které byly v kapitole 5 sepsány a mohou tak sloužit jako podklady pro budoucí úpravy. Tvorba aplikace přinesla mnoho zkušeností se zpracováním obrovského množství dat, včetně návrhu nejoptimálnějšího využití výpočetních prostředků a přenosových kanálů. To je důležité proto, aby bylo možné využít bezplatné přístupy k sociálním sítím, které jsou limitovány určitým počtem dotazů denně. Aplikace je napsaná univerzálně a díky použitým návrhovým vzorům také modulárně, takže nic nebrání dalšímu rozšíření.

109

6

Literatura (1) Berners-Lee, T.: Tim Berners Lee - On The Next Web [online]. Březen 2009 [citováno 6. 5. 2012]. Dostupné z WWW: (2) Berners-Lee, T.: Tim Berners Lee - The Year Open Data Went Worldwide [online]. Březen 2010 [citováno 6. 5. 2012]. Dostupné z WWW: (3) Couts, A.: CIA actively monitors 5 million tweets every day [online]. Poslední aktualizace 4. 11. 2011 [citováno 10. 3. 2012]. Dostupné z WWW: (4) Dočekal, D.: Tři miliony českých aktivních uživatelů na Facebooku, hranice prolomena [online]. Poslední aktualizace 31. 1. 2011 [citováno 1. 3. 2012]. Dostupné z WWW: (5) Čičák, M.: Google+ už používá 100 milionů uživatelů [online]. Poslední aktualizace 10. 4. 2012 [citováno 20. 3. 2012]. Dostupné z WWW: (6) Čičák, M.: Pinterest roste, v USA již je třetí největší sociální sítí [online]. Poslední aktualizace 10. 4. 2012 [citováno 20. 3. 2012]. Dostupné z WWW: (7) Kočí, P.: Twitter má 100 milionů uživatelů, v Česku přes 70 tisíc [online]. Poslední aktualizace 9. 9. 2011 [citováno 1. 111

Literatura 3. 2012]. Dostupné z WWW: (8) Martinová, A.: Hon na informace [online]. Poslední aktualizace 8. 11. 2007 [citováno 10. 4. 2012]. Dostupné z WWW: (9) Metz, A.: The Social Customer: How Brands Can Use Social CRM to Acquire, Monetize, and Retain Fans, Friends, and Followers. McGrawHill; 1 edition, 2011, ISBN 978-0071759182, 304 s. (10) Podnikatel.cz, R.: Pomlouvají váš byznys na Facebooku? Na příliv nových zákazníků zapomeňte [online]. Poslední aktualizace 10. 4. 2012 [citováno 10. 3. 2012]. Dostupné z WWW: (11) Schroeder, S.: Salesforce Acquires Radian6 For $326 Million [online]. Poslední aktualizace 30. 3. 2011 [citováno 20. 4. 2012]. Dostupné z WWW: (12) Times, T. N. Y.: Twitter Tapping [online]. Poslední aktualizace 12. 12. 2009 [citováno 10. 3. 2012]. Dostupné z WWW: (13) Uhlíř, M.: Tipy na 50+ inspirativních osobností na Facebooku [online]. Poslední aktualizace 26. 9. 2011 [citováno 23. 4. 2012]. Dostupné z WWW: (14) Wikipedie: Internet [online]. Poslední aktualizace 30. 4. 2012 [citováno 6. 5. 2012]. Dostupné z WWW: (15) Wikipedie: Sémantický web [online]. Poslední aktualizace 10. 2. 2012 [citováno 6. 5. 2012]. Dostupné z WWW: (16) Wikipedie: Sociální sítě [online]. Poslední aktualizace 26. 4. 2012 [citováno 6. 5. 2012]. Dostupné z WWW:

112

Příloha

Diagramy aplikace

Obrázek A.1: Diagram tříd aplikace 113

A

A. Diagramy aplikace

Obrázek A.2: Datový model aplikace

114

Příloha

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD src diag......................finální diagramy aplikace ve formátu PNG ea ......... zdrojové soubory analýzy ve formátu Enterprise Architect impl...................................zdrojové kódy implementace thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce thesis.pdf ............................. text práce ve formátu PDF 115

B

Příloha

Přístupové údaje Aplikace je aktuálně on-line na adrese: http://sm.vojtasvoboda.cz/ Pro přístup do aplikace lze využít tyto přístupové údaje: E-mail [email protected]

Heslo test

Tabulka C.1: Přístupové údaje

117

C

Příloha

Instalační manuál Pro instalaci aplikace je potřeba provést několik níže uvedench kroků: 1. Zkopírování všech souborů, které jsou ve složce src na přiloženém CD. Soubory se zkopírují na webový server, kde má aplikace běžet, do příslušné složky. 2. Nasměrovná nějaké domény na výše zmíněnou složku, která je na webovém serveru. 3. Vytvoření databáze dle SQL souboru schema.sql, který je přiložen ve složce /sql/. 4. Nastavení přístupových údajů k databázi do souboru /lib/settings.php 5. Nastavení souboru .htaccess, dle webového serveru, kam je aplikace nakopírována. 6. Nastavení složek cache, log a upload pro zápis. 7. Nastavení importérů, viz D.1. 8. Spuštění importérů, viz D.2. Pomocí těchto kroků lze docílit zprovoznění aplikace. Pro vstup do aplikace lze použít přístupové údaje, které jsou přiložené v příloze C. Rovněž lze přístupy vytvořit přímo v databázi, v tabulce „uzivatele“ a „admins“. Je důležité dbát na správné vytvoření hesla, jak je popsáno v sekci 4.3.

D.1

Nastavení importérů

Pro sběr dat je potřeba rovněž zaregistrovat novou aplikaci v každé sociální síti jednotlivě. Vyjímkou jsou RSS kanály, kde je přístup i bez registrace. 119

D

D. Instalační manuál Registrací se získají dva, nebo čtyři přístupové klíče. Konkrétní konstanty se nastavují pro jednotlivé importéry zvlášť v jejich souborech, které jsou ve složce /models/importers/. Konstanty jsou uvedeny hned na začátku souboru.

D.2

Sběr dat

Pro sběr dat je nutno buď manuálně, nebo automaticky volat skript php/updatefeeds.php, který je zvnějšku dostupný na adrese /update-feeds/. A dále pak sript php/update-cache.php, který provádí hledání nových záznamů, dle předvolených témat. Parametry volání jsou uvedeny v následující tabulce D.2. Adresa /update-feeds/ /update-feeds/1/ /update-feeds/2/ /update-feeds/3/ /update-feeds/4/ /update-feeds/5/ /update-cache/

Služba Načtení RSS kanálů, Twitter, Facebook, obnova vyrovnávací paměti Načtení Twitter Načtení Flickr Načtení Pinterest Načtení Foursquare Načtení Facebook Obnova vyrovnávací paměti Tabulka D.1: Sběr dat

Aktuální nastavení rozsahu načítaných dat je zmíněné v tabulce 4.1.

120

Příloha

Uživatelská příručka E.1

Přihlášení do aplikace

Pro přihlášení je nutné zadat e-mail a heslo, které obdržíte od administrátora aplikace, nebo v příloze této práce C.

E.2

Nastavení aplikace

První co je potřeba, je nastavit si aplikaci, aby mohla sbírat data. Nastavení probíhá v záložce „Nastavení monitoringu“, kde je ihned nabídnuto vložení nového téma.

E.2.1

Nastavení témat

Pro vytvoření nového téma lze použít viditelný formulář, nebo odkaz v levém sloupci s názvem „Vložit téma“. Po vytvoření téma je potřeba zadat sledovaná klíčová slov.

E.2.2

Nastavení klíčových slov

Pro vložení klíčových slov je nutno kliknout na vložené téma, kde bude nabídnuto vložení klíčových slov. Nápovědu pro klíčových slov zobrazíte kliknutím na „Nápověda“. Pokud si nejste jistí vkládáním klíčových slovních spojení, lze také využít vyhledávání dostupné v hlavním menu. Dále je potřeba nastavit sledované zdroje.

E.2.3

Nastavení sledovaných zdrojů

Pro nastavení sledovaných zdrojů využijte formulář pod tabulkou vložených slov. Musí být vloženo alespoň jedno slovo. 121

E

E. Uživatelská příručka

E.3

Zobrazení nalezených záznamů

Pro zobrazení záznamů musí být správně nastaveno vyhledávání. Nalezení prvních výsledků může trvat i několik hodin v závislosti na nastavení aplikace. Nalezené výsledky jsou zobrazeny v textově v záložce „Dashboard“ a dále pak graficky v záložce „Vizualizace dat“. V textové podobě lze využít i stránkování pomocí odkazů „Starší“ a „Novější“. Pro zobrazení záznamu na jeho zdrojovém serveru klikněte na titulek záznamu.

E.3.1

Filtrování záznamů

Pro filtrování dat v záložkách „Dashboard“ a „Vizualizace dat“ použijte volby v levém menu, konkrétně volbu Zdroje a volbu Tématu. Počet nalezených dat pomocí filtrování lze vidět nad prvním nalezeným záznamem, nebo nad první grafem.

E.3.2

Zobrazení detailu záznamu

Pro zobrazení detailu najeďte myší na zvolený záznam. Dojde k zobrazení odkazu „Detail“, který vede na detail záznamu. Pomocí detailu lze zobrazit všechna uložená data, která se k záznamu vztahují a rovněž je zde odkazováno na další záznamy uživatele, nebo zdroje, pokud jsou tato data dostupná.

E.3.3

Sdílení záznamu

Sdílení je dostupné opět po najetí myši na vybraný záznam a kliknutím na odkaz „Sdílet“.

E.4

Ruční vyhledávání dat

Pro vyhledávání dat lze využít záložku „Vyhledávání“, která poskytuje fulltext vyhledávání nad uloženými záznamy. Rovněž je zobrazen návod pro správné zadávání slovních výrazů.

E.5

Export dat

Export dat, který je dostupný pod záložkou „Export“ je vhodný pro další zpracování uložených záznamů. Na výběr je buď HTML varianta, která je vhodná pro následný tisk, nebo uložení do souboru typu Excel.

E.6

Změna hesla a údajů

Změna hesla a údajů je dostupná v poslední záložce „Můj účet“. 122

Příloha

Seznam použitých zkratek API Application Programming Interface - aplikační rozhraní CSS Cascading Style Sheets - kaskádové styly pro tvorbu vzhledu webových stránek CSV Comma-separated values - formát dat, kde jsou hodnoty oddělené čárkou HTML HyperText Markup Language - značkovací jazyk pro tvorbu webových stránek LAMP Linux, Apache, MySQL, PHP - zkratka označující běžně instalovaný software na webový server MVC Model-view-controller - architektonický vzor PHP PHP: Hypertext Preprocessor – PHP programovací jazyk PIM Platform Independent Model - diagram nezávislý na platformě PNG Portable Network Graphics - formát obrazových dat PSM Platform Specific Model - diagram závislý na platformě REST Representational State Transfer - rozhraní distribuovaného přenosu dat RSS Really Simple Syndication - formát pro syndikaci obsahu web. stránek SHA1 Secure Hash Algorithm – Algoritmus pro vytvoření otisku dat SQL Standart Query Language – Dotazovací jazyk pro databáze typu SQL UI User Interface - uživatelské rozhraní 123

F

F. Seznam použitých zkratek UML Unified Modeling Language – Jazyk pro modelování systémů WWW World Wide Web – celosvětová síť XML eXtensible Markup Language - Formát pro uložení a přenos dat

124