Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Diplomová práce
SaaS na technickou a obsahovou analýzu webu Bc. Ján Januška
Vedoucí práce: Ing. Jaroslav Vidím
29. května 2012
Poděkování Rád bych poděkoval Ing. Jaroslavovi Vidímovi za odborné konzultace během práce na diplomové práci a při jejím dalším rozvoji.
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 29. května 2012
..................... 7
České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Ján Januška. 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 Ján Januška. SaaS na technickou a obsahovou analýzu webu: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.
Abstract The graduation theses deal with a design of application for technical and content web analysis with primary direction to search engine optimization and web accessibility. There is performed detailed retrieval of competitive tools before particular design. Those are fundamental elements for elaboration of analysis and aims, which must be executed by application because of fairly big competition. The design consist of several different resolutions from which is chosen the most effective one. For final design is implemented prototype to confirm the design legitimacy. Keywords content analysis, technical analysis, search engine optimization, accessibility, web crawler, software as a service, Google App Engine
Abstrakt Diplomová práce se zabývá návrhem aplikace pro technickou a obsahovou analýzu webu, s primárním zaměřením na optimalizaci pro vyhledávače a přístupnost webových stránek. Před samotným návrhem je provedena detailní rešerše konkurenčních nástrojů. Ta byla stěžejním prvkem pro vypracování analýzy a cílů, které musí aplikace splnit, aby mohla uspět v nemalé konkurenci. 9
Návrh sestává z několika různých řešení, ze kterých bylo vybráno to nejefektivnější. Pro výsledný návrh byl implementován prototyp, aby se potvrdila správnost návrhu. Klíčová slova obsahová analýza webu, technická analýza webu, optimalizace pro vyhledávače, přístupnost, vyhledávací robot, software jako služba, Google App Engine
10
Obsah Úvod
17
1 Uvedení do problematiky a vymezení pojmů 19 1.1 Fulltextové vyhledávače . . . . . . . . . . . . . . . . . . . . . . 19 1.2 Optimalizace pro vyhledávače (SEO) . . . . . . . . . . . . . . . 22 1.3 Přístupnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2 Rešerše existujících nástrojů 27 2.1 Hodnotící kritéria . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2 Výběr konkurenčních nástrojů . . . . . . . . . . . . . . . . . . . 29 2.3 Analýza konkurenčních nástrojů . . . . . . . . . . . . . . . . . 30 3 Analýza a požadavky na 3.1 Cíle aplikace . . . . . 3.2 Funkční požadavky . . 3.3 Nefunkční požadavky . 3.4 Omezení . . . . . . . . 4 Návrh 4.1 High-level architektura 4.2 Prvotní návrh . . . . . 4.3 Zefektivnění návrhu . 4.4 Výsledný návrh . . . .
aplikaci . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
41 42 43 45 45
. . . .
47 47 49 53 55
5 Implementace prototypu 63 5.1 Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6 Zhodnocení a další vývoj
69 11
Závěr
71
A Seznam použitých zkratek
73
B Seznam funkcí pro technickou analýzu
75
C Obsah přiloženého CD
79
12
Seznam obrázků 1.1 1.2 1.3 1.4 1.5
Ukázka struktury fulltextového vyhledávače . . . . . . . . . . . . . Ukázka rozhraní vyhledávače Google . . . . . . . . . . . . . . . . . Ukázka vyhledávače Seznam, který na rozdíl od Google používá ve výsledcích vyhledávání i přímé náhledy nalezených stránek. . . . . Proces tvorby webu a související SEO praktiky . . . . . . . . . . . SEO metody využívané během provozu webu. . . . . . . . . . . . .
21 22 23
2.1 2.2 2.3 2.4 2.5 2.6 2.7
Screenshot z programu XENU . . . . . . . . . . . . . . . Vizualizace link grafu(? ), s využitím nástroje Gephi . . Screenshot z programu Screaming Frog SEO Spider Tool Screenshot z programu IIS SEO Toolkit . . . . . . . . . Screenshot aplikace Analytics SEO . . . . . . . . . . . . Screenshot aplikace Bing Webmaster Tools . . . . . . . Screenshot aplikace SEO Servis . . . . . . . . . . . . . .
. . . . . . .
31 32 33 35 36 38 39
4.1 4.2 4.3
48 49
4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13
High-level architektura aplikace . . . . . . . . . . . . . . . . . . . . Diagram analytických tříd . . . . . . . . . . . . . . . . . . . . . . . Ukázka link grafu: Uzly tvoří URL adresy, resp. entity třídy UrlData. Hrany jsou odkazy, resp. entity třídy Link. . . . . . . . . . . Activity diagram životního cyklu entity z Queue. . . . . . . . . . . Activity diagram pro nalezení nových odkazů pro Queue. . . . . . Diagram analytických tříd. . . . . . . . . . . . . . . . . . . . . . . Activity diagram jednoho Task procesu. . . . . . . . . . . . . . . . Activity diagram pro nalezení nových odkazů pro TaskQueue. . . . Ukázka metody Sharding Counters - uložení dat . . . . . . . . . . Ukázka metody Sharding Counters - načtení dat . . . . . . . . . . Výsledný diagram analytických tříd . . . . . . . . . . . . . . . . . Activity diagram úkolu, který zpracovává URL. . . . . . . . . . . . Activity diagram úkolu TaskControl. . . . . . . . . . . . . . . . . .
5.1
Průběh od HTTPServletRequest až po HTTPServletResponse (? ). 65 13
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
19 21
50 51 51 54 54 55 56 56 57 58 59
5.2 5.3
Ukázka úvodní stránky prototypu. Je na ní zobrazen přehled analýz. 67 Ukázka detailu analýzovaného webu. . . . . . . . . . . . . . . . . . 67
14
Seznam tabulek 1.1
(X)HTML tagy posuzované vyhledávači . . . . . . . . . . . . . . .
24
2.1 2.2 2.3 2.4 2.5
Souhrnné Souhrnné Souhrnné Souhrnné Souhrnné
. . . . .
33 34 36 37 38
3.1 3.2
Cílové hodnotící kritéria . . . . . . . . . . . . . . . . . . . . . . . . Příklady technických nedostatků. Kompletní přehled se nachází v příloze B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
hodnocení hodnocení hodnocení hodnocení hodnocení
XENU’s Link Sleuth . . . . . . . Screaming Frog SEO Spider Tool IIS SEO Toolkit . . . . . . . . . . Analytics SEO . . . . . . . . . . Bing Webmaster Tools . . . . . .
15
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
44
Úvod K běžným návštěvníkům webových stránek nepatří jenom lidi, ale taky vyhledávací roboti a další software. Stroj si zřejmě neobjedná zboží, služby a ani jiným způsobem nebude zdrojem přímých příjmů. Ale i tak může být jeho návštěva prospěšná, protože má často schopnost zprostředkovat web jiným, živým návštěvníkům. Například hendikepovaní uživatelé jsou v mnohých případech zcela odkázáni na pomoc asistivního softwaru, který přečte obsah webových stránek namísto nich. Velmi důležití jsou taky vyhledávací roboti, kteří navštěvují stránky napříč webem a shromažďují informace, které skrz vyhledávač najdou živí uživatelé. Proto je důležité, aby software dokázal najít, zpracovat a následně i správně interpretovat obsah na webu. Existují různé překážky, které mohou robotům zkomplikovat, nebo úplně zmařit zpracování obsahu. Tyto překážky dokáže odhalit software na technickou analýzu webu. Simuluje robota a informuje o všech problémech, které mu způsobují potíže. Ale i v případě, že si vyhledávací robot dokáže se stránkami na webu poradit, neznamená to, že bude přivádět mnoho návštěvníků z vyhledávání. Je totiž nutné, aby se na webu nacházel obsah, který uživatelé vyhledávají. Nejdůležitější obsahové prvky (titulky, nadpisy) je vhodné upravit takovým způsobem, aby obsahovaly klíčová slova, která uživatelé vyhledají. Během kontroly správnosti obsahových prvků, značně pomůže obsahová analýza webu. Původním cílem práce bylo navrhnout a implementovat webovou aplikaci na technickou a obsahovou analýzu webu, která dokáže uspět mezi nemalou konkurencí. Bohužel jsme zpočátku nedostatečně odhadli náročnost aplikace jak pro fázi návrhu, tak i implementace. V případě, že bychom pracovali na všech fázích projektu, výsledná služba by jako celek nemohla být dostatečně kvalitní. A s nekvalitní službou se jen velmi těžce uspěje. Z toho důvodu jsme se rozhodli zaměřit především na návrh náročnějších částí aplikace. S kvalitním návrhem úzce souvisí i důkladná analýza a rešerše konkurence. Výsledný návrh pak implementujeme do podoby prototypu, abychom mohli ověřit, jestli je návrh správný. 17
Kapitola
Uvedení do problematiky a vymezení pojmů 1.1
Fulltextové vyhledávače
Fulltextový vyhledávač (dále jen vyhledávač) je program, který na základě zadaného dotazu vygeneruje seznam webových dokumentů, které jsou pro vyhledávač (a v ideálním případě taky uživatele) nejvíce relevantní. Ve světě je nejrozšířenějším vyhledávačem Google1 . V české republice má kromě Google významný podíl na trhu i vyhledávač Seznam2 .
Obrázek 1.1: Ukázka struktury fulltextového vyhledávače 1 2
http://www.google.com http://www.seznam.cz
19
1
1. Uvedení do problematiky a vymezení pojmů Vyhledávač obvykle tvoří 4 hlavní komponenty, které zajišťují: • Sběr dat • Indexaci • Zpracování dotazu a vyhodnocení výsledků • Zobrazení výsledků
1.1.1
Sběr dat
Sběr dat neboli crawling zajišťuje vyhledávací robot (crawler, spider). Jeho primárním úkolem je prohledávání webových dokumentů. Strukturu webu prochází prostřednictvím hypertextových odkazů3 . V rámci sběru dat se robot zaměřuje především na: • Nalezení nových dokumentů • Aktualizace stávajících dokumentů V současnosti nemají vyhledávače dostatečnou výpočtovou kapacitu na to, aby crawleři neustále pokrývali veškerý obsah na webu. Z toho důvodu se musí vyhledávací roboti rozhodnout, které webové dokumenty budou prohlížet a v jakém intervalu budou kontrolovat, jestli nebyly aktualizované.
1.1.2
Indexace
Množství dat, které je indexováno, resp. ukládáno do databáze je velmi vysoké. Vyhledávače s celosvětovým zaměřením indexují webové dokumenty v řádu bilionů (1012 ). Velikost indexu vyhledávače Google tvoří podle odhadů(? ) více než 30 000 000 000 stránek. Kromě ukládání samotného obsahu je potřeba udržovat informace taky o tom, v jaké části stránky se jednotlivé složky obsahu nacházejí (např. jaký obsah se nachází v titulku, nadpisech apod.) Tyto informace patří k tzv. hodnotícím faktorům, které jsou důležité při výsledném seřazení výsledků vyhledávání. Pro každou stránku se zaznamenávají i další data, která při zpracování dotazu budou sloužit jako hodnotící faktory, které se nevztahují přímo k obsahu, ale ke kvalitě stránky. K nim patří různé ranky, v případě Google je to například PageRank4 . 3
Odkazy vedoucí na url adresy v rámci hypertextu, typicky World Wide Webu. Nacházejí se zejména v (X)HTML dokumentech, ale můžou se vyskytovat i v dalších typech souborů, jako například PDF, nebo DOC. 4 Algoritmus pro hodnocení hypertextových stránek, který vychází ze struktury odkazů. Přesná podoba PageRank algoritmu, který využívá Google není známá, ale vychází z výzkumné práce(? ) zakladatelů Google, Lawrence Page a Sergey Brina.
20
1.1. Fulltextové vyhledávače
1.1.3
Zpracování dotazu a vyhodnocení výsledků
Po zpracování dotazu se vyhledá odpovídající množina dat z indexu. Ta je následně zpracována a pomocí hodnotících faktorů se jednotlivé webové dokumenty seřadí podle vypočítané hodnoty relevance. Hodnotící algoritmy a vhodné nastavení vah jednotlivých faktorů jsou nejdůležitější součástí vyhledávačů.
1.1.4
Zobrazení výsledků
Zobrazování výsledků je ve většině fulltextových vyhledávačů velmi podobné. Mezi typicky zobrazované informace patří: • Titulek - Obsah (X)HTML tagu
• Popisek - Popis stránky generovaný z textového obsahu, nebo tagu <meta>, s atributem name="description" • URL adresa nalezené stránky<br />
<br />
Obrázek 1.2: Ukázka rozhraní vyhledávače Google<br />
<br />
Obrázek 1.3: Ukázka vyhledávače Seznam, který na rozdíl od Google používá ve výsledcích vyhledávání i přímé náhledy nalezených stránek.<br />
<br />
21<br />
<br />
1. Uvedení do problematiky a vymezení pojmů<br />
<br />
1.2<br />
<br />
Optimalizace pro vyhledávače (SEO)<br />
<br />
Optimalizace pro vyhledávače je proces, během kterého se zvyšuje popularita webových stránek takovým způsobem, aby se za pomoci neplacených výsledků vyhledávání zvýšil počet relevantních návštěvníků. Cílem je přivést na web návštěvníky, kteří hledají nabízený obsah, resp. informace, zboží nebo služby. Konkrétními cíli může být například: • Zvýšení relevantní návštěvnosti • Prodej produktů a služeb • Budování značky • Zlepšování v oblasti reputačního managementu Na rozdíl od většiny marketingových metod (např. televizní reklamy nebo display5 reklamy), je SEO nenucený způsob propagace. Uživateli je obsah na webu nabízen jenom ve chvíli, když má o něj přímý zájem. Optimalizace pro vyhledávače by měla doprovázet web od jeho počáteční fáze (plánování) až po realizaci a následně taky během provozu.<br />
<br />
Obrázek 1.4: Proces tvorby webu a související SEO praktiky<br />
<br />
5 Druh reklamy, který přiláká pozornost svým vzhledem. V prostředí internetu je to např. bannerová reklama.<br />
<br />
22<br />
<br />
1.2. Optimalizace pro vyhledávače (SEO)<br />
<br />
Obrázek 1.5: SEO metody využívané během provozu webu.<br />
<br />
Realizaci jednotlivých metod optimalizace pro vyhledávače můžeme zařadit do 2 hlavních kategorií: • On-page SEO • Off-page SEO<br />
<br />
1.2.1<br />
<br />
On-page SEO<br />
<br />
Jak naznačují obrázky 1.4 a 1.5, k on-page SEO patří veškeré faktory, které se nacházejí na optimalizovaném webu. Můžeme je tedy přímo ovlivňovat. Patří k nim obsah na stránce a jeho správná interpretace. On-page SEO se skládá z technických a obsahových aspektů. Tato problematika, resp. detekce technických nedostatků a výpomoc při optimalizaci obsahu, je hlavním předmětem diplomové práce. 1.2.1.1<br />
<br />
Technické aspekty<br />
<br />
Slouží k tomu, aby vyhledávač neměl problém s přecházením webu (1.1.1), indexací (1.1.2) a následně se správnou interpretací, resp. pochopením obsahu. Vyhledávací robot může mít mnoho problémů, které mu zcela zabrání, nebo zkomplikují sběr dat: Nepřístupnost navigace nebo obsahu, dlouhá odezva, duplicitní obsah a podobně. Crawler by měl rozpoznat strukturu a důležitost každé části textu. Měla by mu být podána informace o tom, která část obsahu je titulek, nadpis, jestli 23<br />
<br />
1. Uvedení do problematiky a vymezení pojmů se jedná o důležitý text a podobně. Obsah je interpretován prostřednictvím (X)HTML tagů. Na základě struktury tagů jednotlivých podstránek robot dokáže odhadnout i to, ve které části se nachází hlavička stránky, hlavní obsah a pod.. K nejdůležitějším (X)HTML tagům, které vyhledávače posuzují patří(? ): Název Titulek<br />
<br />
Tag <title><br />
<br />
Nadpisy Popis stránky<br />
<br />
Zvýrazněný text Popis obrázků<br />
<br />
Popis Nejdůležitější on-page faktor. Zobrazuje se i jako nadpis ve výsledcích vyhledávání a ovlivňuje míru prokliku z výsledků vyhledávání. <h1> až <h6> Největší vliv má pochopitelně nadpis 1. úrovně. <meta Nemá vliv na hodnocení. Ale name="description"> často se zobrazuje ve výsledcích vyhledávání jako popis stránky. Když není tag vyplněný, vyhledávače vygenerují popisek z obsahu stránky, což nemusí být vždy žádoucí. <strong>, <em>, Zvýšený přínos je nízký, případně resp. <b>, <i> žádný. <img>, atribut "alt" Alternativní popisek obrázků by měl být definován pro každý obrázek, který není jenom dekoračního charakteru.|<br />
<br />
Tabulka 1.1: (X)HTML tagy posuzované vyhledávači Bezproblémové zpracování dat a jejich správná interpretace je nutná podmínka, bez které nelze SEO realizovat vůbec, nebo jen se značným omezením. Je to tedy základ, který by měl splňovat každý web. 1.2.1.2<br />
<br />
Technická analýza webu<br />
<br />
Technická analýza webu se zaměřuje na kontrolu veškerých technických aspektů. Může být prováděná takřka ručně, což je časově velmi náročné a nespolehlivé, nebo pomocí specializovaných nástrojů. Simulací vyhledávacího robota lze automaticky najít většinu problémů. 1.2.1.3<br />
<br />
Obsahové faktory<br />
<br />
K tomu, aby webová stránka přiváděla návštěvnost z neplaceného vyhledávání, musí obsahovat text a klíčová slova, která jsou pro uživatele přínosná a 24<br />
<br />
1.3. Přístupnost vyhledávají je. Z toho důvodu je velmi důležitá analýza klíčových slov, tvorba obsahu a následná aplikace obsahu do titulku, nadpisů apod. 1.2.1.4<br />
<br />
Obsahová analýza webu<br />
<br />
Zabývá se kontrolou obsahu na webu. Automatická kontrola má velmi omezené možnosti, protože kvalitu obsahu nedokáže software spolehlivě rozpoznat. Hlavní přínos nástrojů určených pro obsahovou analýzu není v automatickém vyhodnocování, ale zejména ve vhodné agregaci dat (např. přehledné zobrazení titulků na webu apod.).<br />
<br />
1.2.2<br />
<br />
Off-page SEO<br />
<br />
Off-page činitele se nacházejí mimo stránky. Z toho důvodu je není možné přímo ovlivnit. Vyjadřují popularitu web stránky, resp. její hodnocení. Každá stránka na internetu má možnost "hlasovat"za jiné stránky. Když jedna stránka odkazuje na jinou, dává ji svůj "hlas", doporučuje jí a zvyšuje tak její popularitu. Čím vyšší počet externích odkazů stránka obsahuje, tím slabší hlas odevzdává odkazovaným stránkám. Hodnota hlasu nezávisí jenom na celkové popularitě stránky, ale taky například na zaměření stránek, resp. tematické podobnosti odkazující a odkazované stránky.<br />
<br />
1.3<br />
<br />
Přístupnost<br />
<br />
Ve všeobecnosti pojem přístupnost znamená přístup bez bariér, bez jakýchkoliv překážek. Přístupnost webových stránek charakterizuje bezproblémový přístup k obsahu na webu pro hendikepované uživatele. Mezi tyto uživatele internetu patří každý, kdo má specifické požadavky na prohlížení webových stránek. Do této skupiny patří například: • Nevidomí, nebo jinak zrakově postihnutí • Neslyšící • Uživatelé s pohybovým postižením • Návštěvníci s poruchami soustředění • Uživatelé s jiným fyzickým nebo psychickým postižením (epileptici apod.) • Uživatelé používající nestandardní software (např. textový prohlížeč), nebo zařízení (zastaralé CRT monitory apod.) Hendikepovaní uživatelé při prohlížení webu často využívají asistivní zařízení nebo software (Braillský řádek(? ), odečítač obrazovky(? ) apod.). Asistivní 25<br />
<br />
1. Uvedení do problematiky a vymezení pojmů software interpretuje obsah obdobně jako web crawler, resp. vyhledávacího robota můžeme taky považovat za "hendikepovaného uživatele". Technické prvky (1.2.1.1) SEO a přístupnosti jsou v mnohých ohledech totožné. Když je stránka přístupná pro uživatele, s velkou pravděpodobností jsou v pořádku i technické prvky SEO. Ale naopak to nemusí až tak často platit, protože člověk web nejenom prohlíží, ale je s ním v přímé interakci. Pro hendikepovaného uživatele je např. často důležité ovládání pomocí klávesnice, potřebuje se orientovat ve webových formulářích atd. Z toho důvodu je problematika uživatelské přístupnosti značně komplikovanější, než přístupnost pro vyhledávací roboty.<br />
<br />
26<br />
<br />
Kapitola<br />
<br />
Rešerše existujících nástrojů Cílem práce je navrhnout aplikaci, která co nejvíce usnadní práci s technickou a obsahovou analýzou webu. Měla by mít vlastnosti a funkce, které budou pro potenciální uživatele větším přínosem, než konkurenční software. Rešerším existujících nástrojů jsme věnovali značné úsilí. Snažili jsme se najít všechny přímé i nepřímé konkurenty, které jsme následně analyzovali z 2 hlavních důvodů: • V případě, že již kvalitní software existuje a není dostatečný prostor na zlepšení, nemá velmi smysl zabývat se návrhem nástroje, o který nebude dostatečný zájem. • Některé existující řešení můžou být velmi dobrou inspirací. A naopak, jiný konkurenční systém může být varovným signálem v tom, jakou cestou návrhu se nemáme vybrat a čemu se máme vyvarovat.<br />
<br />
2.1<br />
<br />
Hodnotící kritéria<br />
<br />
Ještě před samotnou analýzou konkurenčních projektů je potřebné stanovit základní hodnotící kritéria: • Přístupnost k systému Typ aplikace Dostupné operační systémy • Funkcionalita Kvalita obsahové analýzy Kvalita technické analýzy<br />
<br />
27<br />
<br />
2<br />
<br />
2. Rešerše existujících nástrojů • Další funkční kritéria Schopnost zpracování vysokého objemu dat Rychlost zpracování URL adres webu Chybovost aplikace • Uživatelská přívětivost (User eXperience) • Správa uživatelů • Cena<br />
<br />
Typ aplikace Jestli se jedná o desktopovou, webovou, případně mobilní aplikaci. Nejvhodnějším typem jsou webové aplikace, jelikož fungují na každém zařízení podporujícím používání internetu. U desktopových aplikací je často nevyhnutná i instalace a jsou s nimi spojeny i další nevýhody. Jednou z mála výhod oproti webovým aplikacím může být nezávislost na používání externích serverů, což snižuje náklady. Ale na druhou stranu výkon osobního počítače nemusí být vždy dostačující.<br />
<br />
Dostupné operační systémy Operační systémy seřazené podle důležitosti: MS Windows, Mac OS, Linux.<br />
<br />
Kvalita technické a obsahové analýzy Funkcionalita je nejdůležitější hodnotící kritérium. Škála ohodnocení je 1 - 5, přičemž 1 znamená výbornou kvalitu, 5 je nevyhovující kvalita.<br />
<br />
Schopnost zpracování vysokého objemu dat Důležité kritérium, které informuje o tom, jak velký web dokáže aplikace zpracovat. Škála hodnocení podle bezproblémového zpracování webu (na základě počtu stránek): • Velmi nízká - do 1000 stránek • Nízká - 1001 až 10000 stránek • Střední - 10001 až 50 000 stránek • Vysoká - 50 001 až 100 000 stránek • Velmi vysoká - více jako 100 000 stránek 28<br />
<br />
2.2. Výběr konkurenčních nástrojů<br />
<br />
Rychlost zpracování URL adres webu Rychlost zpracování je shora omezená, na základě možností a nastavení serverů, ze kterých jsou data získávána. Proto budeme hodnotit rychlost vzhledem k existujícím možnostem. V tomto případě zanedbáme možnost nastavení rychlosti sběru dat a předpokládáme, že nastavení bude provedeno správně. Tj. maximální rychlost nebude překročena a cílový server nezačne další žádosti o načítání stránek odmítat. Rychlost může být: nízká, střední a vysoká.<br />
<br />
Chybovost aplikace Na základě množství a důležitosti programových chyb, rozdělíme chybovost na: nízkou, střední, vysokou.<br />
<br />
User eXperience Bez hlubšího testování se UX špatně hodnotí. Budeme vycházet především z best practices6 a našich zkušeností. Škála hodnocení je 1 - 5, přičemž 1 znamená výborné UX, 5 je nevyhovující.<br />
<br />
Správa uživatelů Hodnotí, jestli lze projekty sdílet mezi více uživateli, s klientem apod. Možností přístupu může být mnoho, z toho důvodu bude správa uživatelů hodnocená slovně.<br />
<br />
Cena Uvedení ceny nástroje.<br />
<br />
2.2<br />
<br />
Výběr konkurenčních nástrojů<br />
<br />
Celkově jsme analyzovali více jako 20 různých nástrojů. V následujícím seznamu uvádíme výběr 15 softwarových aplikací, které jsme seřadili do několika skupin: • Desktopové aplikace XENU’s Link Sleuth Screaming Frog SEO Spider Tool IIS SEO Toolkit Integrity 6<br />
<br />
Známé postupy, které vycházejí z běžných, případně modelových problémů.<br />
<br />
29<br />
<br />
2. Rešerše existujících nástrojů Link Examiner WebSite Auditor Web Link Validator • Systémy na komplexní správu SEO Seomoz PRO Analytics SEO 80 Legs AnalyticsSEO Web SEO Analytics • Nastroje poskytované vyhledávači Google Webmaster Tools Bing Webmaster Tools • Miniaplikace SEO Servis<br />
<br />
2.3<br />
<br />
Analýza konkurenčních nástrojů<br />
<br />
Nebudeme vyhodnocovat všechny konkurenty. Zaměříme se na nejpopulárnější a nejlepší nástroje a na aplikace, které jsou nějakým způsobem zajímavé. Vybrali jsme nástroje: • XENU’s Link Sleuth • Screaming Frog SEO Spider Tool • IIS SEO Toolkit • Analytics SEO • Bing Webmaster Tools • SEO Servis<br />
<br />
2.3.1<br />
<br />
XENU’s Link Sleuth<br />
<br />
XENU7 patří k nejpopulárnějším (a zdarma dostupným) nástrojům na technickou analýzu. Není používán jenom pro účely SEO. Populárním se stal 7<br />
<br />
30<br />
<br />
http://home.snafu.de/tilman/xenulink.html<br />
<br />
2.3. Analýza konkurenčních nástrojů hlavně kvůli jednoduché kontrole nefunkčních odkazů8 . Pro tento účel je to velmi dobrý a lehce použitelný nástroj. XENU je potřeba brát hlavně jako nástroj na dolování dat z webových stránek. Jejich zpracování je již na uživateli. Velmi často se využívá např. export do tabulkového procesoru (Microsoft Excel apod.), kde se data agregují do požadované formy. Tento postup obvykle není problémem pro webmastery. Ale optimalizace pro vyhledávače je marketingový obor a nemalá část SEO konzultantů nemá s "technickými"postupy mnoho zkušeností. Nemusí být pro každého snadné, naučit se agregovat data podle různých pravidel. Z obsahových faktorů, XENU poskytuje u (X)HTML stránek tvar url, titulku a popisku stránky. Při obsahové analýze to velmi pomůže, ale ještě chybí informace o nadpisech. Taky nelze analyzovat texty interních odkazů, což značně komplikuje analýzu interního prolinkování. Kromě (X)HTML stránek je možné kontrolovat taky obrázky, u kterých se zobrazuje alternativní popisek.<br />
<br />
Obrázek 2.1: Screenshot z programu XENU Z pohledu technických faktorů nástroj neposkytuje některé důležité informace, jako například zamezení pro vyhledávací roboty - Zákaz indexace nebo zákaz následování odkazů. Odhalování technických chyb často závisí od schopnosti uživatele agregovat data. Na vhodnou agregaci existují různé návody9 , 8<br />
<br />
Za nefunkční odkaz je považován odkaz na URL, která vrací stavový kód 404, nebo jiný chybový stav (kódy 4xx, 5xx) 9 http://blog.h1.cz/odhalte-technicke-nedostatky-webu-pomoci-xenu<br />
<br />
31<br />
<br />
2. Rešerše existujících nástrojů ale i s jejich pomocí se technická analýza značně prodlužuje. Kromě výpisů dat o jednotlivých stránkách, XENU poskytuje i možnost exportu dat pro tzv. link graf, tj. graf který zobrazuje vztahy mezi odkazy celého webu. Soubor je možné zpracovat v některém ze specializovaných softwarů (např. Gephi10 ). Je tak možno vizualizovat odkazovou strukturu, ze které se dají často vyvozovat další důležité informace. Ale vzhledem k náročnosti není tento způsob práce s nástrojem XENU rozšířený.<br />
<br />
Obrázek 2.2: Vizualizace link grafu(? ), s využitím nástroje Gephi<br />
<br />
10<br />
<br />
32<br />
<br />
http://gephi.org<br />
<br />
2.3. Analýza konkurenčních nástrojů 2.3.1.1<br />
<br />
Souhrnné hodnocení XENU’s Link Sleuth<br />
<br />
Kritérium Typ aplikace Dostupné operační systémy Kvalita obsahové analýzy Kvalita technické analýzy Schopnost zpracování vysokého objemu dat Rychlost zpracování analýzy Chybovost aplikace User eXperience Správa uživatelů Cena<br />
<br />
Hodnota Desktopová MS Windows 3 3 Střední Vysoká Nízká 4 Žádná Zdarma<br />
<br />
Tabulka 2.1: Souhrnné hodnocení XENU’s Link Sleuth Největší problém XENU je v User eXperience a nemožnosti zpracovat vysoký počet URL. Kvalita analýz taky není oslnivá. Ale i vzhledem k tomu je XENU užitečným nástrojem a zdarma poskytuje širokou škálu funkcí.<br />
<br />
2.3.2<br />
<br />
Screaming Frog SEO Spider Tool<br />
<br />
Tento nástroj je označován jako "Software pro SEO konzultanty od SEO konzultantů"(? ). Je to komerční desktopová aplikace, která je podobná XENU(2.3.1), ale vyvaruje se jeho mnohým problémům.<br />
<br />
Obrázek 2.3: Screenshot z programu Screaming Frog SEO Spider Tool 33<br />
<br />
2. Rešerše existujících nástrojů Pro obsahovou analýzu poskytuje i kontrolu nadpisů 1. a 2. úrovně. Taky je možné analyzovat anchor texty11 příchozích interních odkazů. Během technické analýzy hodně pomůžou nejrůznější způsoby agregace dat, které jsou přímo součástí uživatelského rozhraní. I když vhodné zobrazení dat má ještě výrazné rezervy, např. oproti XENU je to mnohem lepší. Jak jsme uvedli na začátku, nástroj je určen pro SEO konzultanty, tj. osoby, které velmi dobře rozumí problematice optimalizace pro vyhledávače. Nástroj tedy není vhodný pro méně pokročilé uživatele. 2.3.2.1<br />
<br />
Souhrnné hodnocení Screaming Frog SEO Spider Tool<br />
<br />
Kritérium Typ aplikace Dostupné operační systémy Kvalita obsahové analýzy Kvalita technické analýzy Schopnost zpracování vysokého objemu dat Rychlost zpracování analýzy Chybovost aplikace User eXperience Správa uživatelů Cena<br />
<br />
Hodnota Desktopová MS Windows, Mac OS 2 2 Střední Vysoká Nízká 3 Žádná £99/ročně, 1 licence. (tj. cca 3 080 kč/ročně)<br />
<br />
Tabulka 2.2: Souhrnné hodnocení Screaming Frog SEO Spider Tool Software nabízí kvalitní technickou i obsahovou analýzu. Nicméně prostor pro vylepšování je stále nezanedbatelný. GUI se při analýzách větších webů stává nepřehledným. Jinak je používání nástroje bezproblémové a z veškerých komerčních řešení nabízí nejvíc funkcí. Pro SEO konzultanty, kteří pracují samostatně a nepotřebují často analyzovat rozsáhlé weby, je Screaming Frog velmi dobrá volba. Komplikace nastávají až při kooperaci většího počtu konzultantů, kdy je potřeba zakoupit licenci každému z nich. Vzhledem k chybějící správě uživatelů je i případná kooperace problémem.<br />
<br />
11 Anchor text je text odkazu. Např. v <a href="/url.html" rel="nofollow">SEO</a>, je anchor textem slovo "SEO".<br />
<br />
34<br />
<br />
2.3. Analýza konkurenčních nástrojů<br />
<br />
2.3.3<br />
<br />
IIS SEO Toolkit<br />
<br />
IIS SEO Toolkit12 je zdarma dostupný produkt od Microsoftu. Ke zpracování dat přistupuje odlišným způsobem jako XENU a Screaming Frog. Nezobrazuje jenom URL adresy (a jejich vlastnosti), ale vytváří tzv. reporty, které obsahují i popisy problémů a způsoby jak je odstranit. Takže nástroj už nemusí být určen jenom profesionálům z oboru SEO. Kromě toho nástroj nabízí rozhraní na filtrování a agregaci dat, které lze využít při pokročilých analýzách.<br />
<br />
Obrázek 2.4: Screenshot z programu IIS SEO Toolkit Nástroj neumožňuje práci jenom s URL adresami, ale dokáže agregovat i informace o odkazech, včetně anchor textů. To poskytuje nové možnosti v analýze interního prolinkování. Bohužel Microsoft hází sám sobě "klacky pod nohy". Nástroj má problémy se stabilitou a poradí si jenom se znakovou sadou UTF-8. Veškerou manipulaci s daty si ukládá do operační paměti a při analýze rozsáhlejšího webu je práce s aplikací pomalá.<br />
<br />
12<br />
<br />
http://www.microsoft.com/web/seo<br />
<br />
35<br />
<br />
2. Rešerše existujících nástrojů 2.3.3.1<br />
<br />
Souhrnné hodnocení IIS SEO Toolkit<br />
<br />
Kritérium Typ aplikace Dostupné operační systémy<br />
<br />
Kvalita obsahové analýzy Kvalita technické analýzy Schopnost zpracování vysokého objemu dat Rychlost zpracování analýzy Chybovost aplikace User eXperience Správa uživatelů Cena<br />
<br />
Hodnota Desktopová MS Windows Vista, MS Windows 7, MS Windows Server 2008. 1 2 Střední Vysoká Vysoká 2 Žádná Zdarma<br />
<br />
Tabulka 2.3: Souhrnné hodnocení IIS SEO Toolkit IIS SEO Toolkit nabízí nejlepší funkčnost jak technické, tak i obsahové analýzy. Z toho ohledu ho nepředčí ani zpoplatněné nástroje. Ale velké problémy s chybovostí a nízká dostupnost pro operační systémy, dělají nástroj často nepoužitelným.<br />
<br />
2.3.4<br />
<br />
Analytics SEO<br />
<br />
Analytics SEO13 je placená webová aplikace na komplexní správu SEO. Námi hodnocená kritéria jsou součástí balíčku nabízených nástrojů.<br />
<br />
Obrázek 2.5: Screenshot aplikace Analytics SEO 13<br />
<br />
36<br />
<br />
http://www.analyticsseo.com/<br />
<br />
2.3. Analýza konkurenčních nástrojů Ze všech hodnocených komerčních aplikací je Analytics SEO nejpřínosnější. GUI je velmi intuitivní a veškeré informace jsou podány formou, které porozumí i méně zkušený uživatel, např. majitel kontrolovaného webu, pracovníci marketingu apod. Z pohledu kvality obsahové a technické analýzy webu Analytics SEO nenabízí tolik možností jako např. IIS SEO Toolkit2.3.3. Tento komplexní nástroj je vhodný pro marketingové pracovníky, kteří nejsou úzce specializovaní jenom na optimalizaci pro vyhledávače, ale potřebují vývoj SEO nějakým způsobem monitorovat. 2.3.4.1<br />
<br />
Souhrnné hodnocení Analytics SEO<br />
<br />
Kritérium Typ aplikace Dostupné operační systémy Kvalita obsahové analýzy Kvalita technické analýzy Schopnost zpracování vysokého objemu dat Rychlost zpracování analýzy Chybovost aplikace User eXperience Správa uživatelů Cena<br />
<br />
Hodnota Webová Všechny (s dostupným prohlížečem) 3 2 Vysoká Střední Nízká 2 Žádná Začíná na £99/měsíčně (tj. cca 3 080 kč/měsíčně)<br />
<br />
Tabulka 2.4: Souhrnné hodnocení Analytics SEO Cena Analytics SEO je velmi vysoká, vzhledem k přínosům technické a obsahové analýzy webu. Za uvedených £99/měsíčně lze analyzovat max. 5 domén, s počtem stránek nižším jako 50 000. Ale je potřeba brát do úvahy, že tato webová aplikace nabízí mnohem více funkcí, které nejsou předmětem rešerše.<br />
<br />
2.3.5<br />
<br />
Bing Webmaster Tools<br />
<br />
Nástroj 14 poskytuje přímo vyhledávač Bing. Není to standardní typ nástroje jako ostatní analyzované aplikace. Uživatel se nemusí vůbec zabývat zahájením sběru dat, vše zajistí Bing. Jelikož informace pocházejí "přímo od zdroje", poskytované informace jsou zcela přesné. Můžeme tak přímo monitorovat, s čím má vyhledávač problémy. Taky poskytuje mnoho dalších informací, které lze externími nástroji zjistit 14<br />
<br />
http://www.bing.com/toolbox/webmaster/<br />
<br />
37<br />
<br />
2. Rešerše existujících nástrojů jen těžko (např. počet zaindexovaných stránek v Bingu). Webmaster Tools od Bingu si bez problémů poradí taky s obrovskými weby (což je pochopitelné).<br />
<br />
Obrázek 2.6: Screenshot aplikace Bing Webmaster Tools Nástroj poskytuje informace jenom o pár nejzásadnějších technických nedostatcích. Obsahová analýza není s Bing Webmaster Tools vůbec možná. 2.3.5.1<br />
<br />
Souhrnné hodnocení Bing Webmaster Tools<br />
<br />
Kritérium Typ aplikace Dostupné operační systémy Kvalita obsahové analýzy Kvalita technické analýzy Schopnost zpracování vysokého objemu dat Rychlost zpracování analýzy Chybovost aplikace User eXperience Správa uživatelů<br />
<br />
Cena<br />
<br />
Hodnota Webová Všechny (s dostupným prohlížečem) 5 3 Velmi vysoká Nízká Nízká 1 Možnost sdílet účet s více uživateli, přičemž je možné dát přístup jenom "ke čtení". Zdarma<br />
<br />
Tabulka 2.5: Souhrnné hodnocení Bing Webmaster Tools 38<br />
<br />
2.3. Analýza konkurenčních nástrojů Bing Webmaster Tools kontroluje každé 2 týdny nejzásadnější technické nedostatky. Ale momentálně neposkytuje plnohodnotné možnosti pro obsahovou a technickou analýzu webu. Nástroj zpracuje i velmi rozsáhlé weby. Používání nástroje je jednoduché a intuitivní. Vytvořit pro Bing komplexnější nástroj nemusí být problém. Obdobně jako IIS SEO Toolkit, společnost Microsoft vlastní taky Bing. V případě, že se k tomuto kroku Bing odhodlá, bude se mu jen těžce konkurovat.<br />
<br />
2.3.6<br />
<br />
SEO Servis<br />
<br />
Podobných mini aplikací existují desítky. Nástroj analyzuje jenom jednu URL a pro hlubší analýzu není vhodný. Při nesprávné interpretaci může být dokonce zavádějící(? ).<br />
<br />
Obrázek 2.7: Screenshot aplikace SEO Servis Do rešerší jsme tento nástroj zahrnuli z toho důvodu, že jednoduchým (i když diskutabilním) rozborem dokáže zaujmout laiky, kteří SEO nerozumí. Z programátorského hlediska je tedy nástroj nepodstatný, ale z byznys hlediska je inspirativní.<br />
<br />
39<br />
<br />
Kapitola<br />
<br />
Analýza a požadavky na aplikaci Před stanovením cílů si musíme položit otázku „V čem může být technická a obsahová analýza prospěšná, jaký má přínos“? Technická analýza by měla poskytnout rychlý přehled o tom, jestli web nemá nějaké technické potíže a jeho obsah dokáže zpracovat software . Tj., upozorní nás, když můžou mít s webem problém vyhledávací roboti, asistivní software apod. Uživatel se tedy ihned dozví, jestli web: • Zbytečně přichází o návštěvnost z vyhledávačů • Zabraňuje hendikepovaným, nebo jinak indisponovaným v přístupu k informacím • Má jiné nedostatky, které komplikují jeho používání Technická analýza by měla taky poskytnout rozhraní, které usnadní nalezení konkrétních chyb a v ideálním případě taky poskytne možnosti, jak chyby odstranit. Její přínos v odstraňování nedostatků je: • Minimalizuje riziko "přehlédnutí"problému (které je při manuální kontrole vysoké) • Výrazně šetří čas Obsahová analýza může automaticky vyhodnotit jen několik typických chyb v obsahu. Její hlavní přínos je ve vhodné agregaci dat takovým způsobem, aby uživatel mohl rychle analyzovat mnoho stránek najednou a následně tak detekoval nedostatky v obsahu. Vhodná úprava obsahu pomůže v optimalizaci pro vyhledávače. Přínosy obsahové analýzy: • Výrazně šetří čas • Minimalizuje riziko "přehlédnutí"problému 41<br />
<br />
3<br />
<br />
3. Analýza a požadavky na aplikaci<br />
<br />
3.1 3.1.1<br />
<br />
Cíle aplikace Požadavky z uživatelského hlediska<br />
<br />
• Bezproblémový a rychlý přístup k aplikaci s pomocí jakéhokoliv zařízení, které má přístup k internetu • Poskytnutí nejvyšší kvality analýz • Důraz na množství ušetřeného času • Jednoduché a intuitivní ovládání • Možnost sdílet přístup k analýzám i dalším lidem • Bezplatný systém, případně za přijatelnou cenu<br />
<br />
3.1.2<br />
<br />
Cíle na základě hodnotících kritérií<br />
<br />
Na základě rešerší můžeme lépe stanovit cíle, které by měla aplikace splňovat, aby se dokázala prosadit vůči existující konkurenci: Kritérium Typ aplikace Dostupné operační systémy Kvalita obsahové analýzy Kvalita technické analýzy Schopnost zpracování vysokého objemu dat Rychlost zpracování analýzy Chybovost aplikace User eXperience Správa uživatelů<br />
<br />
Cena<br />
<br />
Hodnota Webová Všechny (s dostupným prohlížečem) 1 1 Velmi vysoká Vysoká Nízká 1 Musí nabízet možnosti sdílení přístupu k analýzám, včetně nastavení uživatelských pravomocí Přijatelná, ideálně nižší než má konkurence<br />
<br />
Tabulka 3.1: Cílové hodnotící kritéria<br />
<br />
3.1.3<br />
<br />
Byznys požadavky<br />
<br />
• Platební systém bude vytvořený na základě měsíčních plateb, v kombinaci s „Pay Per Use15 “ systémem. 15<br />
<br />
42<br />
<br />
Výše platby se odvíjí od množství využívaných služeb, výkonu apod.<br />
<br />
3.2. Funkční požadavky • U neplatících uživatelů bude kladen důraz na maximalizaci konverzních schopností aplikace v podobě objednání placeného tarifu. • Další typy konverzí: Registrace uživatele, provedení bezplatné analýzy webu. • Důraz na spokojenost zákazníků (platících i neplatících).<br />
<br />
3.1.4<br />
<br />
Cílové skupiny<br />
<br />
• Amatérští tvůrci webů Cíl: Informování o službě dalším potenciálním zájemcům • Majitelé malých firemních webů Cíl: Informování o službě dalším potenciálním zájemcům • Malé firmy a živnostníci Cíl: Objednávka základního tarifu • Středně velké firmy: Agentury,... Cíl: Objednávka vyššího tarifu • Velké firmy: Rozsáhlé e-shopy, velké agentury, zpravodajské weby,.. Cíl: Objednávka nejvyššího tarifu<br />
<br />
3.2<br />
<br />
Funkční požadavky<br />
<br />
• Aplikace se bude skládat ze 3 hlavních funkčních celků Technická analýza (více v sekci 3.2.1) Obsahová analýza Analýza interního prolinkování • Aplikace umožní přístup k datům získaným z kontrolovaného webu i během analýzy • Budou existovat 3 typy uživatelských účtů Owner - majitel účtu může změnit objednaný tarif, má plný přístup k aplikaci a může spravovat uživatelské účty. Admin - má plný přístup k aplikaci, ale nemůže zrušit, nebo změnit tarif. Může spravovat uživatelské účty, kromě typu owner. User - má přístup k analýzám, ale nemůže je žádným způsobem upravovat. 43<br />
<br />
3. Analýza a požadavky na aplikaci<br />
<br />
3.2.1<br />
<br />
Požadavky pro technickou analýzu<br />
<br />
• Všechny technické nedostatky budou vyhodnoceny automaticky • Každý nedostatek bude obsahovat podrobnosti problému, včetně návrhů na jeho řešení • Každý nedostatek může patřit do kategorií: SEO - Nedostatek omezující optimalizaci pro vyhledávače Přístupnost - Problém v přístupnosti stránky Technická - Jiný technický nedostatek • Každý nedostatek bude patřit do jedné z 3 kategorií: Chyba Upozornění Informace Ukázka funkcí pro technické nedostatky Funkce Dlouhý titulek Duplicitní stránky Zacyklené přesměrování 2 a více stránek Neexistující (404) stránka Stránka obsahuje odkaz s nerelevantním anchor textem Na stránce se nacházejí obrázky s nedefinovaným atributem alt Stránky se zakázanou indexací v meta robots Na stránce se nachází prvky technologie FLASH Na stránku vedou odkazy s prázdným nebo nerelevantním anchor textem Na stránce se nachází tag <blink><br />
<br />
Kategorie SEO SEO SEO, Technická<br />
<br />
Status Upozornění Chyba Chyba<br />
<br />
SEO, Technická SEO, Přístupnost<br />
<br />
Chyba Upozornění<br />
<br />
SEO, Přístupnost<br />
<br />
Upozornění<br />
<br />
SEO<br />
<br />
Informace<br />
<br />
SEO, Přístupnost, Technická SEO, Přístupnost<br />
<br />
Informace<br />
<br />
Přístupnost<br />
<br />
Chyba<br />
<br />
Upozornění<br />
<br />
Tabulka 3.2: Příklady technických nedostatků. Kompletní přehled se nachází v příloze B.<br />
<br />
44<br />
<br />
3.3. Nefunkční požadavky<br />
<br />
3.2.2<br />
<br />
Požadavky pro obsahovou analýzu<br />
<br />
Výsledky bude možné agregovat dle následujících obsahových prvků: • U (X)HTML stránek: Tag title Tag meta, s atributem name="description" První Tag h1. • U obrázků: Atribut alt v tagu img<br />
<br />
3.2.3<br />
<br />
Požadavky pro analýzu interního prolinkování<br />
<br />
• Odkazy bude možné agregovat dle anchor textů • O každém odkazu budou dostupné informace: Anchor text 100 znaků před odkazem 100 znaků za odkazem Jestli vyhledávače nemají zákaz následování odkazu Jestli odkaz vede na interní nebo externí stránku Pořadí odkazu<br />
<br />
3.3<br />
<br />
Nefunkční požadavky<br />
<br />
• Aplikace bude vyvíjená na platformě Google App Engine16 • Uživatelé budou pro přístup k aplikaci využívat Google účet<br />
<br />
3.4<br />
<br />
Omezení<br />
<br />
Omezení aplikace: • Navrhovaný typ služeb není velmi známý • Aplikace konkuruje i bezplatným nástrojům • Úzká cílová skupina Vzhledem k rozsahu problematiky, se práce nezabývá: 16<br />
<br />
https://developers.google.com/appengine/<br />
<br />
45<br />
<br />
3. Analýza a požadavky na aplikaci • Návrhem a realizací uživatelského rozhraní • Implementací všech funkčních požadavků. Implementace bude zaměřená především na stěžejní problémy, jako je sběr dat a jejich vhodné zpracování. • Nezabýváme se byznys procesy, jako například stanovení cen pro tarifní pásma, marketingová strategie apod.<br />
<br />
46<br />
<br />
Kapitola<br />
<br />
4<br />
<br />
Návrh Jak jsme již uvedli v úvodu, návrhu programové části jsme původně neplánovali věnovat velkou pozornost. Aplikace se do značné míry skládá z obecně známých problémů. Problematice web crawlerů se již taky zabývalo mnoho výzkumních prací (např. (? ), (? )). Bohužel, v tomto ohledu jsme naše počínání podcenili. Navrhli jsme architekturu web crawlera, včetně modelu analytických tříd a bez hlubší analýzy návrhu jsme začali s implementací. Výsledkem testování implementace byla velmi vysoká zátěž na zápisy a čtení dat z databáze. Proto bylo potřeba změnit návrh crawlera, což mělo za následek kompletní přepracování implementační části aplikace. Ještě před návrhem samotného crawlera se na architekturu aplikace podíváme ze vzdálenější perspektivy. Následně se zaměříme na několik návrhů modelů analytických tříd a crawlera, od počátečního (neefektivního) až po výsledný návrh.<br />
<br />
4.1<br />
<br />
High-level architektura<br />
<br />
Aplikaci bude tvořit: • Prezentační vrstva - GUI • Aplikační vrstva - Vyhledávací robot a tzv. procesor • Datová vrstva - Databáze a konfigurační soubory<br />
<br />
47<br />
<br />
4. Návrh Jednotlivé vztahy mezi funkčními celky aplikace naznačuje obrázek 4.1:<br />
<br />
Obrázek 4.1: High-level architektura aplikace Funkční celek nazvaný „Procesor“ zajišťuje zejména součinnost GUI s datovou vrstvou. Má na starosti veškerou logiku, kromě dolování a následného ukládání dat z webových dokumentů. To zajistí vyhledávací robot, včetně syntaktické analýzy. Konfigurační soubory v datové vrstvě slouží k prvotní inicializaci databáze. Potom už do fungování aplikace nezasahují. Uživatelské rozhraní zajišťuje komunikaci uživatele s ostatními částmi aplikace.<br />
<br />
48<br />
<br />
4.2. Prvotní návrh<br />
<br />
4.2 4.2.1<br />
<br />
Prvotní návrh Návrh analytických tříd<br />
<br />
Obrázek 4.2: Diagram analytických tříd<br />
<br />
Slovní popis analytických tříd • User - Třída obsahující data o uživatelích • Project - Projektová data, včetně nastavení projektů • UrlData - Třída uchovávající data o jednotlivých URL adresách, entity tvoří uzly link grafu4.3. • Link - Třída uchovávající data o jednotlivých odkazech, entity tvoří hrany link grafu. • Recommend - Seznam možných doporučení 49<br />
<br />
4. Návrh • Queue - Třída uchovává data o aktuálním stavu fronty url adres určených pro robota<br />
<br />
Obrázek 4.3: Ukázka link grafu: Uzly tvoří URL adresy, resp. entity třídy UrlData. Hrany jsou odkazy, resp. entity třídy Link.<br />
<br />
4.2.2<br />
<br />
Návrh řešení sběru dat<br />
<br />
Fronta URL adres, které čekají na zpracování, je reprezentována v podobě entit, v analytické třídě Queue. V 1. kroku se do fronty uloží počáteční URL adresa, kterou definoval uživatel. Tento krok kvůli přehlednosti zanedbáme. Předpokládejme, že ve frontě se již alespoň jedna URL nachází. Zpracování entity z Queue je následovné:<br />
<br />
50<br />
<br />
4.2. Prvotní návrh<br />
<br />
Obrázek 4.4: Activity diagram životního cyklu entity z Queue. Aktivitu „Nalezení nových odkazů pro Queue“ pro přehlednost uvedeme do dalšího acitivty diagramu:<br />
<br />
Obrázek 4.5: Activity diagram pro nalezení nových odkazů pro Queue.<br />
<br />
51<br />
<br />
4. Návrh Modré znaky „R“, resp. „W“ na obrázcích 4.4 a 4.5 charakterizují Read, resp. Write17 databázové operace. Znak „S“ charakterizuje tzv. Small operaci. Výše poplatků za využívání Google App Engine závisí do znační míry od počtu databázových operací. Zejména od Write operací, které jsou nejdražší. Z toho důvodu je potřeba navrhnout aplikaci takovým způsobem, aby byl počet databázových operací co nejnižší. Zároveň je potřeba dbát na to, aby se značně nezvýšila náročnost na výpočetní výkon a přitom se zachovala taky požadovaná funkčnost.<br />
<br />
4.2.3<br />
<br />
Rozbor návrhu<br />
<br />
Počet databázových operací18 (Read, Write) bude pro jednotlivé složky návrhu: • Výběr 1. volné URL z Queue = 1*R • Nastavit aktuální entitu na "zpracovávám" = 1*W • Vložení entity do UrlData = 2*W + 2*<iv19 -UrlData> • Vložení entit do Link = (2*W+2*<iv-UrlData>)*<poc-odkazu> • Nachází se URL odkazu v Queue? = (R+R)*<poc-odkazu> • Nachází se URL odkazu v UrlData? = (R+R)*<poc-odkazu> • Vlož seznam do Queue = 2*W*<poc-prvku-seznamu> • Odstranění URL z Queue = 2*W Zanedbali jsme operace Small, protože je jich velmi nízký počet a jejich využívání je výrazně levnější, než Read a Write operace. Počty databázových operací jsme odvodili z definicí na požadavky jednotlivých operací20 . 17<br />
<br />
V Google App Engine terminologii, je i odstranění entity považováno za součet Write operací, jelikož si vyžadují úpravy v databázi. 18 V tomto případě o počtu databázových operací, uvádíme počty pro jednu URL. 19 Konstanta obsahující „iv“, charakterizuje počet indexovatelných položek. Podrobnosti o indexovatelných položkách: https://developers.google.com/ 20 https://developers.google.com/appengine/docs/billing<br />
<br />
52<br />
<br />
4.3. Zefektivnění návrhu Vkládání každého odkazu jako novou entitu, je extrémně drahá operace. Příklad: Potřebujeme analyzovat web, který má 10 000 stránek, přičemž na každé stránce se nachází v průměru 100 odkazů. Použijeme 3 indexovatelné položky pro odkazy (příchozí URL, odchozí URL, anchor text) a 5 indexovatelných položek pro URL adresy. Počet Write operací do analytické třídy Link bude tedy: (2*W+2*3) * 10000 * 100 = 12 000 000W. Udržování aktuálního stavu fronty v databázi je taky náročné na počet operací. Počet operací spravující Queue následovný: (1R+1W+2W) * 10 000 + 2R*(10 000*100) + 2W*10 000 = 2 010 000R+50 000W. Náročné je především neustálé čtení z databáze kvůli každému odkazu. Poslední databázové operace obsluhují vkládání URL do UrlData a kontrolu existence URL každého odkazu v UrlData: (2W+2*5) * 10 000 + 2R*(10 000*100) = 120 000W + 2 000 000R. Celkový počet operací: 12 000 000W + (2 010 000R+50 000W) + (120 000W + 2 000 000R) = 12 170 000W + 4 010 000R. Dle aktuálních finančních sazeb21 za databázové operace, je cena 12$ + (1,47$ + 0,05$) + (0,12$ + 1,4$) = 15,04$. To je velmi vysoká cena a nelze tak splnit cíl cenové přijatelnosti (3.1.2).<br />
<br />
4.2.4<br />
<br />
Shrnutí návrhu<br />
<br />
Současný návrh je extrémně náročný na počet databázových operací. Při optimalizaci se zaměřime především na: • Ukládání odkazových dat - nelze každý odkaz ukládat do nové entity • Zjednodušení správy fronty za pomoci databáze • Minimalizaci čtení odkazů, které vedou na stejné URL adresy.<br />
<br />
4.3<br />
<br />
Zefektivnění návrhu<br />
<br />
Každý odkaz nebudeme ukládat do nové entity a třídu Link odstraníme. Data o odkazech přidáme do UrlData, kde každá entita, resp. URL adresa bude obsahovat seznam odchozích odkazů, včetně doplňkových informací (anchor text apod.). Další úsporu počtu databázových operací získáme převedením správy fronty na UrlData a úkoly, resp. Tasks. Každý Task již nebude zpracovávat první volnou URL ve frontě. Task dostane informaci o URL, kterou má zpracovat při jeho vzniku. To umožňuje zrušit i třídu Queue.<br />
<br />
21<br />
<br />
https://developers.google.com/appengine/docs/billing<br />
<br />
53<br />
<br />
4. Návrh<br />
<br />
Obrázek 4.6: Diagram analytických tříd.<br />
<br />
Obrázek 4.7: Activity diagram jednoho Task procesu. Zpracovávaná URL nevytvoří v UrlData novou entitu, ale aktualizuje již existující. Entity se vytvářejí během zavádění nových úkolů ??. Je to z toho důvodu, aby se v databázi nenacházely jenom zpracované URL adresy, ale i ty nezpracované. Protože jinak by nebylo možné zjistit, které URL se nacházejí ve frontě úkolů.<br />
<br />
54<br />
<br />
4.4. Výsledný návrh<br />
<br />
Obrázek 4.8: Activity diagram pro nalezení nových odkazů pro TaskQueue. Tento návrh výrazně sníží počet databázových operací. Ale ještě stále je kontrolován každý odkaz, jestli se jeho cílová URL nachází v UrlData. Hodně odkazů má přitom duplicitní cílovou URL. V následující sekci 4.4 si představíme návrh, který je v náročnosti na počet databázových operací šetrnější.<br />
<br />
4.4<br />
<br />
Výsledný návrh<br />
<br />
Abychom nemuseli neustále kontrolovat duplicitní odkazy, které vedou na stejnou cílovou stránku, můžeme je ukládat do množiny (duplicitní URL budou odstraněny). Jakmile se skončí poslední Task z TaskQueue, zkontrolujeme které URL adresy z množiny se nenacházejí v UrlData. Ty následně přidáme do TaskQueue a inicializujeme je v UrlData. V případě zápisu všech odkazů do množiny ale vzniká problém: Jednu entitu (v tomto případě množinu), lze aktualizovat jenom několikrát za sekundu. 55<br />
<br />
4. Návrh Aplikace by měla umožňovat i zpracování několika desítek URL za sekundu. To nám umožní využití metody Sharding Counters(? ). Ta spočívá v tom, že nebudeme využívat jenom jednu entitu, ale zátěž rozložíme na větší počet entit (tzv. Shards). Před realizací zápisu do databáze, se náhodně vybere jeden z předem definovaných Shards, resp. množin, do které se nové odkazy přidají (viz. obrázek 4.9).<br />
<br />
Obrázek 4.9: Ukázka metody Sharding Counters - uložení dat Když budeme potřebovat data ze Sharding Counters načíst, Shards sjednotíme a vytvoříme tak výslednou množinu (viz obrázek 4.10).<br />
<br />
Obrázek 4.10: Ukázka metody Sharding Counters - načtení dat<br />
<br />
56<br />
<br />
4.4. Výsledný návrh<br />
<br />
4.4.1<br />
<br />
Návrh analytických tříd<br />
<br />
Diagram analytických tříd (viz. 4.11) se tedy vzhledem k předchozímu návrhu téměř nezměnil.<br />
<br />
Obrázek 4.11: Výsledný diagram analytických tříd<br />
<br />
Správu fronty úkolů, tzv. TaskQueue nemůže databáze vůbec ovlivnit. Jednotlivé úkoly o sobě navzájem nevědí. To znamená, že úkol zpracovávající nějakou URL adresu nemá žádnou informaci o tom, jestli se ve frontě nacházejí ještě další úkoly. Taky nezná, jakou URL bude zpracovávat další úkol. V navrženém diagramu analytických tříd se nacházejí jenom informace o celkovém počtu nalezených URL (zpracované URL + URL v TaskQueue). To klade vyšší nároky na složitost implementace TaskQueue. 57<br />
<br />
4. Návrh<br />
<br />
4.4.2<br />
<br />
Návrh sběru dat<br />
<br />
Na rozdíl od předchozích návrhů, využijeme pro sběr dat více typů úkolů, které se nacházejí v TaskQueue.<br />
<br />
Obrázek 4.12: Activity diagram úkolu, který zpracovává URL. Průběh úkolu na zpracování URL (4.12) neslouží na inicializaci dalších úkolů stejného typu. Na to využijeme jiný typ úkolu (4.13), který jsme nazvali TaskControl.<br />
<br />
58<br />
<br />
4.4. Výsledný návrh<br />
<br />
Obrázek 4.13: Activity diagram úkolu TaskControl. Aby mohl byl úkol TaskControl úspěšně ukončen, musí být předtím zpracovány všechny úkoly na zpracování URL. V případě, že během zpracování URL došlo k nějaké chybě, kterou lze očekávat, je úkol přesunutý až za TaskControl. To zapříčiní, že TaskControl nebude úspěšně ukončen a přesune se na konec fronty.<br />
<br />
59<br />
<br />
4. Návrh<br />
<br />
4.4.3<br />
<br />
Rozbor návrhu<br />
<br />
Během implementace uvedeného návrhu je potřeba myslet na dvě situace, které můžou nastat: • Zaseknutí, neboli tzv. stuck z důvodu neočekávané chyby • Překročení limitu na maximální čas pro zpracování úkolu Zaseknutí TaskControl je zcela závislé od bezchybného zaznamenávání zpracovaných URL. V případě, že se kvůli nějaké chybě neaktualizují data o počtu zpracovaných URL a daný úkol nebude opět zařazen do fronty, nebude počet nalezených a zpracovaných URL stejný. To bude mít za následek, že TaskControl nikdy neskončí úspěšně, ale bude se neustále opakovat, resp. zacyklí se. Úplnou bezchybnost implementace nelze garantovat na 100%. Proto je důležité očekávat, že daná situace může vzniknout a TaskControl na to připravit. Překročení limitu na maximální čas pro zpracování úkolu Návrh připouští přidání nových url do fronty až ve chvíli, když je prázdná. Je to z toho důvodu, že se v databázi neuchovávají data o tom, které URL čekají na zpracování. Pak by mohla nastat situace, že do fronty se dostanou dva úkoly, které budou zpracovávat stejnou URL. Množina, resp. množiny, ve kterých se uchovávají všechny (unikátní) URL adresy odchozích odkazů, můžou obsahovat velmi vysoké množství prvků. Operace sloučení množin za pomoci Sharding Counters 4.4 a následná kontrola existence URL v UrlData může trvat dlouhou dobu. Když je čas pro zpracování úkolu omezen, může nastat zlyhání TaskControl. S tím je během implementace potřeba počítat. Problém lze vyřešit například následovně: • Úkol rozdělíme na několik podúkolů, aby každý dokázal zpracovat přidělená data včas. • V databázi se bude udržovat dodateční seznam URL, které čekají na zpracování. Náročnost vzhledem k počtu databázových operací Počet databázových operací (Read, Write) bude pro jednotlivé složky návrhu: • Načtení zpracovaných URL ze Sharding Counter 60<br />
<br />
4.4. Výsledný návrh = R + S*<pocet-shards22 > • Načtení počtu nalezených URL = 2*R • Přidání nové entity do UrlData = 2*W + 2*<iv23 -UrlData> • Přidání odkazů do Sharding Counter =W Minimální náročnost na počet operací, pro analýzu všech URL vybraného webu je následovná: • Načtení zpracovaných URL ze Sharding Counter = (R + S*<pocet-shards>)*<pocet-levelu> • Načtení počtu nalezených URL = (2*R)*<pocet-levelu> • Přidání nové entity do UrlData = (2*W + 2*<iv-UrlData>)*<pocet-URL> • Přidání odkazů do Sharding Counter = W*<pocet-URL> Tj. celkově: (3*R + S*<pocet-shards>) * <pocet-levelu> + (3*W + 2*<iv-UrlData>)*<pocet-URL> Na rozdíl od prvotního návrhu se v UrlData nachází o dvě indexovatelné položky víc, protože se tam momentálně nachází i odchozí odkazy, včetně anchor textů. Ale i vzhledem k tomu, je výsledný návrh výrazně efektivnější. 22 <pocet-shard> je konstanta počtu Shards ve Shard Counter. Vhodný počet Shards závisí od implementace, resp. implementačního prostředí. Lze předpokládat, že hodnota konstanty bude přibližně 8 - 20. 23 Konstanta obsahující „iv“, charakterizuje počet indexovatelných položek. Podrobnosti o indexovatelných položkách: https://developers.google.com/<br />
<br />
61<br />
<br />
4. Návrh<br />
<br />
4.4.4<br />
<br />
Shrnutí návrhu<br />
<br />
Výsledný návrh minimalizoval problémy, které se nacházely v původním návrhu, tj.: • Každý odkaz se již neukládá do nové entity. Každá entita UrlData nyní obsahuje seznam odchozích odkazů, včetně doplňkových dat o odkazech. Díky tomu se extrémně snížila zátěž na počet databázových operací. Dotazy na čtení z databáze budou ale náročnější a komplikovanější. • Zjednodušení správy fronty za pomoci databáze Fronta úkolů, resp. TaskQueue je téměř úplně oproštěna od databáze. To přináší další úsporu v počtu databázových operací. Na druhou stranu, ztratili jsme úplnou kontrolu nad složením fronty. Během implementace je potřeba vhodně nastavit přidávání a prioritu jednotlivých úkolů. Taky vzniká větší prostor pro vznik chyb, které můžou zásadním způsobem ovlivnit chod aplikace. Proto je nutné implementaci provést velmi důkladně. • Minimalizaci čtení odkazů, které vedou na stejné URL adresy. Neustálou kontrolu duplicitních dotazů se podařilo odstranit. Konečný návrh je mnohem efektivnější, ale taky náročnější na implementaci.<br />
<br />
62<br />
<br />
Kapitola<br />
<br />
Implementace prototypu Hlavním důvodem implementace prototypu je ověření správnosti a použitelnosti návrhu. Zaměřili jsme se tedy hlavně na sběr a zpracování dat. Nejdříve představíme technologie a knihovny, které jsme v implementaci využili. Pak se zaměříme na samotný způsob provedení implementace.<br />
<br />
5.1<br />
<br />
Použité technologie<br />
<br />
Prototyp byl implementován v programovacím jazyce JAVA. Vzhledem k nefunkčním požadavkům (viz. sekci 3.3), jsme použili App Engine Datastore24 , konkrétně High Replication Datastore. Pro práci s databází jsme použili Java Data Objects25 . Na zpracování dat použijeme knihovnu JSOUP26 , což je knihovna určená pro syntaktickou analýzu (tzv. parsing) HTML. Pro zpracování XML používáme DOM Parser(? ). Uživatelské rozhraní, resp. prezentační vrstva je vytvořená za pomoci JavaServer Pages (JSP).<br />
<br />
5.1.1<br />
<br />
High Replication Datastore<br />
<br />
Platforma Google App Engine poskytovala kromě High Replication Datastore (HRD) i tzv. Master/Slave Datastore. Ale ta je již zastaralá, resp. nebude se dál vyvíjet a rozšiřovat její podpora. DHRD je typická replikací dat mezi různými datacentry (? ). High Replication Datastore používá systém založený na Paxos algoritmu (? ),což poskytuje vysokou dostupnost pro čtení a zapisování do databáze. 24<br />
<br />
https://developers.google.com/appengine/docs/java/datastore/overview http://www.oracle.com/technetwork/java/index-jsp-135919.html 26 http://jsoup.org 25<br />
<br />
63<br />
<br />
5<br />
<br />
5. Implementace prototypu<br />
<br />
5.1.2<br />
<br />
Java Data Objects (JDO)<br />
<br />
JDO je API pro persistenci objektů v programovacím jazyku JAVA(? ). JDO není závislé od konkrétní databáze. Pomocí JDO je možné pracovat jak např. s MySQL databází, tak i s non-relačními databázemi, mezi které patří již zmiňovaná High Replication Datastore.<br />
<br />
5.1.3<br />
<br />
JavaServer Pages<br />
<br />
Technologie JSP poskytuje jednoduché vytváření webového obsahu, který má statické i dynamické komponenty. JSP poskytuje veškeré možnosti Java Servlet technologie, ale přitom působí jako přirozený způsob pro tvorbu statického obsahu(? ).<br />
<br />
5.1.4<br />
<br />
JSOUP<br />
<br />
JSOUP je knihovna na zpracování dat z (X)HTML souborů. Poskytuje velmi intuitivní API, HTML data nedokáže jenom zpracovávat, ale taky s nimi manipulovat, resp. upravovat je. JSOUP jsme zvolili především kvůli jednoduchosti, velmi dobré podpoře a neustálému vývoji.<br />
<br />
5.1.5<br />
<br />
DOM Parser<br />
<br />
S daty v XML aplikace velmi nepracuje, proto jsme ani nekladli důraz na co nejefektivnější zpracování XML souborů. Uvedenou knihovnu jsme vybrali především kvůli jednoduchému používání.<br />
<br />
64<br />
<br />
5.2. Implementace<br />
<br />
5.2<br />
<br />
Implementace<br />
<br />
Abychom mohli komunikovat s webovým serverem, využíváme Java Servlet technologii. Požadavky tvoří HTTPServletRequest, odpovědi se vrací prostřednictvím HTTPServletResponse. Průběh požadavku a odpovědi dobře ilustruje obrázek z dokumentace(? ):<br />
<br />
Obrázek 5.1: Průběh od HTTPServletRequest až po HTTPServletResponse (? ). Každý servlet je namapovaný (pomocí konfigurace souboru web.xml) na nějakou URL adresu. Jakmile je Servlet zpracován, odešle data příslušné JSP, která vytvoří (X)HTML stránku v požadovaném tvaru.<br />
<br />
5.2.1<br />
<br />
Správa uživatelů<br />
<br />
Uživatelské účty jsou tvořeny na základě existujících Google účtů. Aplikace tedy neposkytuje možnost vytvoření nového účtu, ve smyslu, že uživatel zadá uživatelské jméno, heslo, e-mail a pod. Uživatelé se můžou k aplikaci přihlásit pomocí Google účtu. Software do databáze ukládá jenom nevyhnutná data, která jsou specifická pro aplikaci, jako například uživatelské oprávnění. Google App Engine pro manipulaci s Google účty poskytuje velmi jednoduché API27 .<br />
<br />
27<br />
<br />
https://developers.google.com/appengine/docs/java/users/overview<br />
<br />
65<br />
<br />
5. Implementace prototypu Ukázka User API: UserService userService = UserServiceFactory.getUserService(); User user = userService.getCurrentUser(); Uvedený kód kontroluje, jestli je uživatel přihlášený. V případě že ano, načítají se informace o uživateli.<br />
<br />
5.2.2<br />
<br />
Vytvoření nové analýzy<br />
<br />
Když uživatel vyplní jméno projektu a počáteční URL, může spustit analýzu. Po spuštění se počáteční URL vloží do fronty úkolů. Implementace vychází z výsledného návrhu (viz. sekce 4.4). Platforma Google App Engine přímo poskytuje API pro frontu úkolů, tzv. Task Queue28 . Fronta úkolů je tvořena seznamem GET, resp. POST požadavků, které směrují na zadanou URL. Tu opět obsluhuje jeden ze Servletů. Ukázka přidání prvku do Task Queue: Queue queue = QueueFactory.getQueue("queueName"); queue.add( withUrl("/process") .method(Method.POST) .param("url", item) .param("projectKey", String.valueOf(projectKey)) .param("level", String.valueOf(level+1)) ); Celá analýza tedy probíhá na pozadí. Uživatel si může během analýzy prohlížet již zpracované data. Data se zpracovávají za pomoci JSOUP.<br />
<br />
5.2.3<br />
<br />
Správa nedostatků<br />
<br />
Nedostatky pro technickou analýzu webu, se alokují taky během zpracovávaní URL v Task Queue. Podrobnosti, resp. textové informace o jednotlivých nedostatcích, jsou do databáze uloženy na základě inicializačního XML souboru. XML zpracovává knihovna DOM Parser.<br />
<br />
28<br />
<br />
66<br />
<br />
https://developers.google.com/appengine/docs/java/taskqueue/<br />
<br />
5.2. Implementace<br />
<br />
5.2.4<br />
<br />
Ukázky prototypu<br />
<br />
Obrázek 5.2: Ukázka úvodní stránky prototypu. Je na ní zobrazen přehled analýz.<br />
<br />
Obrázek 5.3: Ukázka detailu analýzovaného webu.<br />
<br />
5.2.5<br />
<br />
Výsledky ověření funkčnosti<br />
<br />
Výsledný návrh jsme implementovali do funkčního prototypu. Počet databázových operací byl přijatelný, jak sme předpokládali na základě návrhu. Nicméně implementace byla složitější, protože nemálo pomocných dat se již ve výsled67<br />
<br />
5. Implementace prototypu ném návrhu nenacházelo. Ale i vzhledem k tomu, že implementace byla zdlouhavější a složitější, jsou přínosy mnohem výraznější, než nevýhody.<br />
<br />
68<br />
<br />
Kapitola<br />
<br />
Zhodnocení a další vývoj Nejdůležitější komponentu aplikace na technickou a obsahovou analýzu webu se nám podařilo navrhnout dostatečně efektivně. To je ovšem jenom jedna část vývoje. Během dalšího vývoje můžeme vycházet z podrobné rešerše a budeme i nadále dbát na to, abychom plnili cíle, které jsme si stanovili. Momentálně by se mělo začít s návrhem uživatelského rozhraní a implementací vhodné agregace dat. I po splnění všech cílů a zprovoznění aplikace je ještě velmi velký prostor na další vývoj. Aplikace by mohla čerpat informace např. z analytických nástrojů a získávat tak další důležité informace o jednotlivých URL adresách. Obsahová analýza by mohla být doplněna o různé funkce, které souvisejí s klíčovými slovy. Prostor na další vývoj je obrovský, ale nejdřív se musíme zaměřit zejména na úspěšné dokončení aplikace.<br />
<br />
69<br />
<br />
6<br />
<br />
Závěr Na základě rešerší konkurenčních nástrojů jsme si vytyčili cíle, které je potřeba splnit, abychom mohli obstát mezi konkurencí. Z funkčního hlediska bylo potřeba dbát především na schopnost aplikace zpracovávat vysoký objem dat, poskytnout analýzy nejvyšší kvality a nabídnout veškerou funkcionalitu za přijatelnou cenu. Návrh aplikace byl proto zaměřený hlavně na optimalizaci nejnákladnějších operací, resp. databázových operací v prostředí Google App Engine. Optimalizace byla úspěšná, což potvrzuje taky funkčnost a efektivita implementovaného prototypu. Aplikaci čeká ještě dlouhý vývoj. Zatím jsme udělali jenom první, ale velmi důležitý krok. Jeho zdárný konec nás motivuje ve vývoji aplikace nadále pokračovat.<br />
<br />
71<br />
<br />
Literatura (1) Burget, R.: JDO - Java Data Objects. Dostupné z WWW: <http:// interval.cz/clanky/jdo-java-data-objects/> (2) Cho, J.: Crawling the web: Discovery and maintenance of large-scale web data. A dissertation. 2001. Dostupné z WWW: <http://oak.cs.ucla. edu/~cho/papers/cho-thesis.pdf> (3) Gautam Pant, F. M., Padmini Srinivasan: Crawling the Web. Dostupné z WWW: <http://dollar.biz.uiowa.edu/~pant/Papers/crawling. pdf> (4) Google: Introducing the Datastore. Dostupné z WWW: <https: //developers.google.com/appengine/docs/java/datastore/ overview> (5) Gregorio, J.: Sharding counters. 2008. Dostupné z WWW: <https:// developers.google.com/appengine/articles/sharding_counters> (6) Januška, J.: Ako na vizualizáciu web stránok. Dostupné z WWW: <http://jan.januska.info/?q=vizualizacia&utm_source=dp&utm_ medium=pdf&utm_campaign=dp> (7) Januška, J.: Kontrola prístupnosti web stránok, Bakalářská práce. Univerzita Komenského, 2010. (8) Jelínek, M.: Odečítač obrazovky. Blindfriendly. Dostupné z WWW: <http://blindfriendly.cz/download/doc/ odecitace-obrazovky-michal-jelinek.pdf> (9) de Kunder, M.: The size of the World Wide Web (The Internet). Dostupné z WWW: <http://www.worldwidewebsize.com> 73<br />
<br />
Literatura (10) Lawrence Page, R. M. T. W., Sergey Brin: The PageRank Citation Ranking: Bringing Order to the Web. Dostupné z WWW: <http: //ilpubs.stanford.edu:8090/422/1/1999-66.pdf> (11) Ltd, S. F.: Screaming Frog SEO Spider Tool. Dostupné z WWW: <http: //www.screamingfrog.co.uk/seo-spider/> (12) Mook, Y.: How to read XML file in Java – (DOM Parser). Dostupné z WWW: <http://docs.oracle.com/javaee/5/tutorial/doc/geysj. html> (13) Oracle: . Dostupné z WWW: <http://docs.oracle.com/javaee/5/ tutorial/doc/geysj.html> (14) Oracle: JavaServer Pages Technology. Dostupné z WWW: <http:// docs.oracle.com/javaee/5/tutorial/doc/bnagx.html> (15) Roman Kabelka, J. P. M. J., Jiří Fenz: Srovnání braillských řádků. Blindfriendly, 2009. Dostupné z WWW: <http://www.blindfriendly.cz/ at/srovnani-braillskych-radku> (16) Tichý, J.: SEOmaty jsou k ničemu. Dostupné z WWW: <http://blog. medio.cz/seomaty-jsou-k-nicemu> (17) Tushar Chandra, J. R., Robert Griesemer: Paxos Made Live An Engineering Perspective. 2007. Dostupné z WWW: <http: //static.googleusercontent.com/external_content/untrusted_ dlcp/research.google.com/en/us/archive/paxos_made_live.pdf><br />
<br />
74<br />
<br />
Příloha<br />
<br />
Seznam použitých zkratek SEO Search Engine Optimization GUI Graphical user interface (X)HTML (eXtensible) HyperText Markup Language CRT Cathode Ray Tube UX User eXperience UTF-8 Unicode Transformation Format, 8-Bit JDO Java Data Objects GAE Google App Engine HRD High Replication Datastore DOM Document Object Model API Application Programming Interface JSP JavaServer Pages<br />
<br />
75<br />
<br />
A<br />
<br />
Příloha<br />
<br />
Seznam funkcí pro technickou analýzu<br />
<br />
77<br />
<br />
B<br />
<br />
B. Seznam funkcí pro technickou analýzu<br />
<br />
78<br />
<br />
79<br />
<br />
B. Seznam funkcí pro technickou analýzu<br />
<br />
80<br />
<br />
Příloha<br />
<br />
Obsah přiloženého CD<br />
<br />
readme.txt...................................stručný popis obsahu CD src impl...................................zdrojové kódy implementace thesis ...................... zdrojová forma práce ve formátu LATEX install.txt.....................................návod na instalaci funkce.xls...................Seznam funkcí pro technickou analýzu text ....................................................... text práce thesis.pdf ............................. text práce ve formátu PDF 81<br />
<br />
C<br />
<br /> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<form role="form" method="post" action="https://adoc.pub/report/sem-vlote-zadani-vai-prace3b6a6e891ecdce89f4b031e42339fd5045738" style="border: none;">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button>
<h4 class="modal-title">Report "Sem vložte zadání Vaší práce"</h4>
</div>
<div class="modal-body">
<div class="form-group">
<label>Your name</label>
<input type="text" name="name" required="required" class="form-control" />
</div>
<div class="form-group">
<label>Email</label>
<input type="email" name="email" required="required" class="form-control" />
</div>
<div class="form-group">
<label>Reason</label>
<select name="reason" required="required" class="form-control">
<option value="">-Select Reason-</option>
<option value="pornographic" selected="selected">Pornographic</option>
<option value="defamatory">Defamatory</option>
<option value="illegal">Illegal/Unlawful</option>
<option value="spam">Spam</option>
<option value="others">Other Terms Of Service Violation</option>
<option value="copyright">File a copyright complaint</option>
</select>
</div>
<div class="form-group">
<label>Description</label>
<textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;"></textarea>
</div>
<div class="form-group">
<div style="display: inline-block;">
<div class="g-recaptcha" data-sitekey="6LcEnMcZAAAAAFHzKKgaE-Qh57XzUTzpfRElD4dP"></div>
</div>
</div>
<script src='https://www.google.com/recaptcha/api.js'></script>
</div>
<div class="modal-footer">
<button type="button" class="btn btn-default" data-dismiss="modal">Close</button>
<button type="submit" class="btn btn-primary">Send</button>
</div>
</form>
</div>
</div>
</div>
<script>
$(document).ready(function () {
var inner_height = $(window).innerHeight() - 250;
$('#pdfviewer').css({"height": inner_height + "px"});
});
</script>
<footer class="footer" style="margin-top: 60px;">
<div class="container-fluid">
Copyright © 2024 ADOC.PUB. All rights reserved.
<div class="pull-right">
<span><a href="https://adoc.pub/about">About Us</a></span> |
<span><a href="https://adoc.pub/privacy">Privacy Policy</a></span> |
<span><a href="https://adoc.pub/term">Terms of Service</a></span> |
<span><a href="https://adoc.pub/copyright">Copyright</a></span> |
<span><a href="https://adoc.pub/contact">Contact Us</a></span> |
<span><a href="https://adoc.pub/cookie_policy">Cookie Policy</a></span>
</div>
</div>
</footer>
<!-- Modal -->
<div class="modal fade" id="login" tabindex="-1" role="dialog" aria-labelledby="myModalLabel">
<div class="modal-dialog" role="document">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal" aria-label="Close" on="tap:login.close"><span aria-hidden="true">×</span></button>
<h4 class="modal-title" id="add-note-label">Sign In</h4>
</div>
<div class="modal-body">
<form action="https://adoc.pub/login" method="post">
<div class="form-group">
<label class="sr-only" for="email">Email</label>
<input class="form-input form-control" type="text" name="email" id="email" value="" placeholder="Email" />
</div>
<div class="form-group">
<label class="sr-only" for="password">Password</label>
<input class="form-input form-control" type="password" name="password" id="password" value="" placeholder="Password" />
</div>
<div class="form-group">
<div class="checkbox">
<label class="form-checkbox">
<input type="checkbox" name="remember" value="1" />
<i class="form-icon"></i> Remember me
</label>
<label class="pull-right"><a href="https://adoc.pub/forgot">Forgot password?</a></label>
</div>
</div>
<button class="btn btn-primary btn-block" type="submit">Sign In</button>
</form>
</div>
</div>
</div>
</div>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-177279549-1"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-177279549-1');
</script>
<script src="https://adoc.pub/assets/js/jquery-ui.min.js"></script>
<link rel="stylesheet" href="https://adoc.pub/assets/css/jquery-ui.css">
<script>
$(function () {
$("#document_search").autocomplete({
source: function (request, response) {
$.ajax({
url: "https://adoc.pub/suggest",
dataType: "json",
data: {
term: request.term
},
success: function (data) {
response(data);
}
});
},
autoFill: true,
select: function( event, ui ) {
$(this).val(ui.item.value);
$(this).parents("form").submit();
}
});
});
</script>
<!-- cookie policy -->
<div id="ADOCPUB_cookie_box" style="z-index:99999; border-top: 1px solid #fefefe; background: #FFC107; width: 100%; position: fixed; padding: 5px 15px; text-align: center; left:0; bottom: 0;">
Our partners will collect data and use cookies for ad personalization and measurement. <a href="https://adoc.pub/cookie_policy" target="_blank">Learn how we and our ad partner Google, collect and use data</a>. <a href="#" class="btn btn-success" onclick="accept_ADOCPUB_cookie_box();return false;">Agree & close</a>
</div>
<script>
function accept_ADOCPUB_cookie_box() {
document.cookie = "ADOCPUB_cookie_box_viewed=1;max-age=15768000;path=/";
hide_ADOCPUB_cookie_box();
}
function hide_ADOCPUB_cookie_box() {
var cb = document.getElementById('ADOCPUB_cookie_box');
if (cb) {
cb.parentElement.removeChild(cb);
}
}
(function () {
var ADOCPUB_cookie_box_viewed = (function (name) {
var matches = document.cookie.match(new RegExp("(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"));
return matches ? decodeURIComponent(matches[1]) : undefined;
})('ADOCPUB_cookie_box_viewed');
if (ADOCPUB_cookie_box_viewed) {
hide_ADOCPUB_cookie_box();
}
})();
</script>
<!-- end cookie policy -->
</body>
</html>
