eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Kucha°ka - sociální sí´
Tomá² P°asli£ák
Vedoucí práce:
Ing. Ond°ej Macek
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Softwarové inºenýrství
22. kv¥tna 2013
iv
v
Pod¥kování Rád bych pod¥koval vedoucímu práce, Ing. Ond°eji Mackovi za cenné rady v pr·b¥hu tvorby této práce. Také bych cht¥l pod¥kovat v²em uºivatel·m pilotní aplikace, kte°í mi zcela dobrovoln¥ pomohli p°i odhalování aplika£ních chyb.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Sedl£anech dne 25. 4. 2013
.............................................................
viii
Abstract
This bachelor thesis deals with the creation of eective web application, serving to storing and easy creating and searchinng for recipes. Its target is to create a large community of users, that will provide valuable information in the eld of gastronomy between themselves.
This bachelor thesis contains in its chapters all phases needed to create fully functional application. In each chapter you can nd analysis and solutions of various issues, I was at that phase struggled with, includind discussion about another solutions. These solutions can serve as a springboard to all members of project teams, dealing with similar issues in future.
Abstrakt
Bakalá°ská práce °e²í úlohu vytvo°ení efektivní webové aplikace, slouºící k uchovávání a snadnému zadávání a vyhledávání recept·, jejíº cílem je vytvo°it rozsáhlou komunitu uºivatel·, kte°í se mezi sebou budou p°edávat cenné informace z oblasti gastronomie.
V práci jsou v jednotlivých kapitolách postupn¥ shrnuty v²echny fáze, nezbytné k vytvo°ení pln¥ funk£ní aplikace. U kaºdé kapitoly naleznete mimo jiné i rozbory a °e²ení nejr·zn¥j²ích problém·, se kterými jsem se v dané fázi potýkal, v£etn¥ moºností jejich °e²ení. Tato °e²ení pak mohou poslouºit jako odrazový m·stek v²em £len·m projektových tým·, kte°í se budou v budoucnosti podobnou problematikou zabývat.
ix
x
Obsah
1 Úvod
1
2 Re²er²e podobných aplikací
3
2.1
Recepty.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Vareni.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Apetitonline.cz
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4
Obecné problémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.5
Zhodnocení re²er²e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3 Výb¥r technologií
9
3.1
Skriptovací jazyk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Databáze
3.3
Pouºité frameworky
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Sb¥r poºadavk·, analýza, návrh 4.1
Vize
4.2
Analýza
4.3
3
9 10 10
13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.2.1
Poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.2.2
Scéná°e uºití
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.2.3
Doménový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2.4
Zasílání zpráv v rámci aplikace
. . . . . . . . . . . . . . . . . . . . . .
17
Gra ka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5 Implementace
23
5.1
Struktura aplikace
5.2
Mapování databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.2.1
23
M:N vazby
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.3
Logování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.4
Zabezpe£ení aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.5
Validace odesílaných dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.6
Vyhledávací algoritmus ledni£ky . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.6.1
První fáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.6.2
Druhá fáze
5.6.3
Zpracování dotazu
5.7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Rozd¥lení assets/javascripts . . . . . . . . . . . . . . . . . . . . . . . .
30
Struktura JavaScript· 5.7.1
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xi
xii
OBSAH
5.7.2
Ukázky
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.8
Implementace AJAXu
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.9
P°idávání podpostup· a propojených £lánk· . . . . . . . . . . . . . . . . . . .
32
5.10 Uploading obrázk· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.11 Zhodnocení implementa£ní £ásti . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6 Testy
35
6.1
Analýza a návrh
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
6.2
Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
6.2.1
Testovací data
35
6.2.2
Unit testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
6.2.3
Funk£ní testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
6.2.4 6.3
6.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integra£ní testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Code coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.3.1
Popis a kon gurace pouºitého nástroje . . . . . . . . . . . . . . . . . .
38
6.3.2
První analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.3.3
Úpravy test·, druhá analýza
. . . . . . . . . . . . . . . . . . . . . . .
39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
Akcepta£ní testy
7 Pilotní provoz
41
7.1
Výb¥r hostingu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
7.2
Nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
7.2.1
free.railshosting.cz
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
7.2.2
www.heroku.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
7.3
Pr·b¥h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
7.4
Zhodnocení
45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Budoucí práce
47
8.1
P°ihla²ování pomocí sociálních sítí
. . . . . . . . . . . . . . . . . . . . . . . .
47
8.2
Mobilní verze aplikace
8.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Video u receptu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
8.4
Ostatní návrhy roz²í°ení aplikace
48
. . . . . . . . . . . . . . . . . . . . . . . . .
9 Záv¥r
49
A Seznam pouºitých zkratek
53
B Obsah p°iloºeného CD
55
C íslovaný seznam funk£ních a nefunk£ních poºadavk·
57
C.1
Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
C.2
Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Seznam obrázk·
2.1
Detail receptu na Recepty.cz [12]
. . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Detail receptu na Vareni.cz [13] . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Detail receptu na Apetitonline.cz [11] . . . . . . . . . . . . . . . . . . . . . . .
6
4.1
Seznam scéná°· uºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2
Doménový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.3
Sekven£ní diagram 1 - p°ihlá²ení uºivatele
. . . . . . . . . . . . . . . . . . . .
17
4.4
Sekven£ní diagram 2 - vyhledávání recept· . . . . . . . . . . . . . . . . . . . .
18
4.5
Sekven£ní diagram 3 - odeslání poºadavku na novou ingredienci . . . . . . . .
18
4.6
Návrh - Úvodní stránka
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.7
Návrh - Ledni£ka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.8
Návrh - Recept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.9
Návrh - Moje recepty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
6.1
Výstup unit test· (rake test:units)
. . . . . . . . . . . . . . . . . . . . . . . .
36
6.2
Výstup funk£ních test· (rake test:functionals) . . . . . . . . . . . . . . . . . .
36
6.3
Výstup integra£ních test· (rake test:integration)
. . . . . . . . . . . . . . . .
38
7.1
Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
xiii
xiv
SEZNAM OBRÁZK
Seznam tabulek
6.1
Výsledky code coverage
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
40
xvi
SEZNAM TABULEK
Kapitola 1 Úvod
Bakalá°ská práce °e²í úlohu vytvo°ení efektivní webové aplikace, slouºící k uchovávání a snadnému zadávání a vyhledávání recept·. D·raz byl kladen zejména na p°íjemné uºivatelské rozhraní a intuitivní ovládání, které by, oproti jiným konkuren£ním aplikacím tohoto typu, uºivateli zaji²´ovalo snadné vyhledání poºadovaného receptu. Zárove¬ je moºné ke kaºdému receptu p°ipojovat ingredience, £lánky a podpostupy, £ímº by se m¥ly vymýtit duplicitní popisy jednoduchých kuliná°ských úkon·. Recepty, ingredience i podpostupy je moºné komentovat, a tak jsou ve²keré informace, v£etn¥ názor· registrovaných uºivatel·, uchovány p°ehledn¥ na jednom míst¥.
Cílem projektu je implementovat webový nástroj pro v²echny zájemce o va°ení, který umoºní sdílení, hodnocení, ukládání a vyhledávání recept· mezi uºivateli i ve°ejnosti. Aplikace musí mít jednoduché rozhraní, které bude pohodln¥ ovladatelné.
Vytvo°ená aplikace bude slouºit ke sdílení kucha°ských recept· mezi uºivateli, v receptech bude moºno vyhledávat podle názvu i dostupných surovin (Ledni£ka), autor receptu bude mimo ingredience a postup moci p°idat i £lánek. Recepty bude moºno hodnotit, komentovat, p°ípadn¥ upravovat a mazat. Cílem aplikace je vytvo°it rozsáhlou komunitu uºivatel·, kte°í se mezi sebou budou p°edávat cenné informace z oblasti gastronomie. Tyto p°ehledn¥ uspo°ádané informace poté mohou uºivatel·m u²et°it spoustu £asu p°i p°íprav¥ pokrm·. Zárove¬ m·ºe aplikace slouºit jako odrazový m·stek ke spolupráci s rmami, zabývajícími se prodejem potravin, a tím i vytvo°ení rozsáhlé informa£ní sít¥ v oblasti potraviná°ského pr·myslu.
1
KAPITOLA 1.
ÚVOD
2
Kapitola 2 Re²er²e podobných aplikací
P°ed zahájením analýzy aplikace a jejího vývoje byla provedena re²er²e podobných aplikací, vyskytujících se na internetu. Ta m¥la za cíl odhalit slabá místa t¥chto aplikací a zjistit, na co bude vhodné se ve výsledné aplikaci zam¥°it. Re²er²e vznikla v rámci p°edm¥tu A7B36SI2. [14] [17]
Celkem byly prozkoumané t°i weby, které se p°i vyhledávání pomocí klí£ových slov jako "kucha°ka"a "recepty"objevovaly ve vyhledáva£ích na nejvy²²ích pozicích. Tato kapitola obsahuje podrobné zprávy o jednotlivých zkoumaných aplikacích a jejich silných a slabých stránkách.
2.1 Recepty.cz Tento web je prvním výsledkem vyhledávání s klí£ovými slovy recepty nebo kucha°ka, je tedy nejv¥t²í konkurencí.
P°ehlednost
Co se tý£e p°ehlednosti, svoji první náv²t¥vu nehodnotím moc dob°e. Web mi
p°ijde nep°ehledný, v²ude po stránce jsou rozmíst¥ny r·zné kategorie doporu£ených recept· typu tip dne, doporu£ené recepty, oblíbené recepty tento týden, nové recepty a je²t¥ p°e£t¥te si. Kategorie jídel jsou skryty n¥kde mezi tím. Jednou z mála kladných stránek je vyhledávání jídel, které je dob°e viditelné a p°ehledn¥ umíst¥né na vrcholu stránky.
Vyhledávání recept·
Vyhledávání je ud¥lané dob°e. Uºivatel si m·ºe:
•
Vybrat kategorii a procházet recepty.
•
Pouºít chytrého pr·vodce, který uºivatele provede po r·zných receptech po pokládání otázek typu kolik máte £asu na p°ípravu? nebo chcete pouºít n¥jakou oblíbenou ingredienci, jakou?.
•
Vyhledávat podle ingrediencí.
•
Vyhledávat pomocí pokro£ilého vyhledávání, které mi ale p°ijde stejné jako chytrý pr·vodce.
3
KAPITOLA 2.
REERE PODOBNÝCH APLIKACÍ
Obrázek 2.1: Detail receptu na Recepty.cz [12]
Recept
Samotný recept je ud¥laný p°ehledn¥, obsahuje obrázek, seznam ingrediencí, po-
stup, hodnocení a komentá°e uºivatel· a na pravé stran¥ nabídku podobných recept·.
Po p°ihlá²ení
Uºivatel m·ºe vyuºít nap°íklad funkce Nákupní seznam kde si z databáze
vybere ingredience a umístí je do seznamu.
2.2 Vareni.cz Stránky, které se také objevují mezi prvními výsledky p°i zadávání pro nás zajímavých klí£ových slov.
P°ehlednost
P°ehlednost úvodní stránky je zde zase na nízké úrovni. Jsou tu dv¥ vyhle-
dávání, ale nena²el jsem mezi nimi rozdíl. Na úvodní stránce jsou doporu£ené £lánky, aº pod nimi kategorie recept· a aº pod nimi doporu£ené a nejnov¥j²í recepty.
Vyhledávání recept· •
Vyhledávat recepty m·ºe uºivatel t¥mito zp·soby:
Vybráním kategorie, kde po vybrání kategorie m·ºe zadávat ingredience, typ a náro£nost jídla a dal²í atributy.
•
Roz²í°eným vyhledáváním, které je stejné jako po výb¥ru kategorie.
4
2.3.
APETITONLINE.CZ
Obrázek 2.2: Detail receptu na Vareni.cz [13]
Recept
U receptu je také obrázek, ingredience, postup, hodnocení a komentá°e uºivatel·
a podobné recepty.
Po p°ihlá²ení
Po p°ihlá²ení je zde zajímavá funkce "kucha°ka", kam si uºivatelé ukládají
recepty (své i cizí), dal²í uºivatelé mohou jejich kucha°ky procházet.
2.3 Apetitonline.cz Dal²í stránky z horních pozic vyhledáva£·, tentokrát od vydavatel· £asopisu Apetit.
P°ehlednost
Zde mi p°ehlednost úvodní stránky p°ijde na nejlep²í úrovni. Vyhledávání,
tipy dne, výb¥r kategorií a rovnou na úvodní stránce pokro£ilé vyhledávání s druhem jídla, zp·sobem p°ípravy a dobou p°ípravy a po rozkliknutí s mnoha dal²ími atributy.
Vyhledávání recept·
Vyhledávání recept· je moºné:
•
Zadáním klí£ového slova.
•
Výb¥rem z moha r·zných typ· kategorií.
•
Pokro£ilým vyhledáváním se zadáním hlavních ingrediencí.
•
Chybí zde vyhledávání pomocí zadání jakékoliv ingredience.
5
KAPITOLA 2.
REERE PODOBNÝCH APLIKACÍ
Obrázek 2.3: Detail receptu na Apetitonline.cz [11]
Recept
Samotný recept je ud¥laný jednodu²e a p°ehledn¥, je zde obrázek, seznam ingre-
diencí, popsaný postup, hodnocení a komentá°e uºivatel· a podobné recepty.
Celkové hodnocení
Tyto stránky hodnotím osobn¥ nejlépe ze v²ech nav²tívených. Je to
zejména díky jejich p°ehlednému designu, ke kterému je sm¥°ována i aplikace Kucha°ka.
2.4 Obecné problémy Obecným neduhem v²ech aplikací tohoto typu je jejich p°íli²ná sloºitost a dost £asto uºivateli vnucují recepty, o které ani nem·ºe mít v dané souvislosti zájem. Tyto recepty pak zabírají místo na stránce a tím i zt¥ºují orientaci.
Dal²ím problémem je p°ehnaná snaha o propojení s r·znými sociálními sít¥mi. V²emoºné komponenty typu "sdílet na FB"op¥t kazí výsledný gra cký dojem a orientaci na stránce. V¥t²inu z nich navíc b¥ºný uºivatel nikdy nevyuºije. A pokud uº touºí po sdílení receptu na Facebooku, m·ºe to ud¥lat standardn¥ p°ímo p°es rozhraní Facebooku a nepot°ebuje k tomu mít zkratkovou ikonku na kaºdé stránce.
T°etí a poslední výrazný problém je absence propojení mezi jednotlivými £ástmi receptu, tzv. podpostupy. Tato absence pak vede k duplicitnímu vkládání dat (nap°íklad jak u²lehat sníh) a tím pádem znovu ke sníºení p°ehlednosti receptu.
6
2.5.
ZHODNOCENÍ REERE
2.5 Zhodnocení re²er²e V²echny nav²tívené stránky mají podobnou funk£nost, li²í se hlavn¥ v designu a p°edpokládám, ºe i v obsahu. Pou£ení které z existujících °e²ení plyne pro nás je hlavn¥ ve vytvo°ení jednoduchých a p°ehledných stránek s funk£ností popsanou v analýze.
Na co se zam¥°it:
•
Líbivý a atraktivní design.
•
P°ehlednost.
•
Logickou navigaci, u n¥kterých web· byla chvílemi nesmyslná.
•
Moºnosti u vyhledávání recept· a optimalizace °azení výsledk·.
•
Propojování recept· podle souvislosti (nap°íklad podpostupy, p°edkrm a hlavní chod).
7
KAPITOLA 2.
REERE PODOBNÝCH APLIKACÍ
8
Kapitola 3 Výb¥r technologií
Ze zadání je jasn¥ dané, ºe výstupem projektu má být webová aplikace, b¥ºící na platform¥ Ruby on Rails. Proto jsem v tomto p°ípad¥ nem¥l na výb¥r a celou aplikaci postavil na frameworku RoR. Zárove¬, vzhledem k tomu, ºe se má jednat o webovou aplikaci, jsem musel vyuºít HTML a CSS. U t¥chto technologií jsem se rozhodl pouºívat nejnov¥j²í standardy, tedy HTML5 a CSS3, aby aplikace drºela krok s konkurencí a nebyla zastaralá jiº p°i uvedení do produkce.
V ostatních, dopl¬ujících, technologiích jsem jiº tak limitován nebyl, a proto jsem si mohl vybírat z n¥kolika moºností.
3.1 Skriptovací jazyk P°i volb¥ skriptovacího jazyka jsem m¥l na výb¥r ze dvou moºností: JavaScript a Coee-
1
Script .
CoeeScript
je defacto nadstavbou JavaScriptu. Má zjednodu²enou syntaxi, takºe na-
p°íklad n¥které výrazy zabírající v JavaScriptu n¥kolik °ádk· v n¥m lze zapsat na jediný °ádek. V kódu se taky promítají prvky jazyka ruby (@ znak jako this ukazatel), yml apod. Celý kód je pak p°i kompilaci p°eloºen do JavaScriptu. CoeeScript jsem se rozhodl nepouºívat ze dvou d·vod·. Prvním je, ºe bych se musel u£it syntaxi zcela nového jazyka, coº by mohlo ohrozit datum nasazení aplikace do pilotního provozu. Druhým d·vodem je, ºe pro psaní kódu aplikace pouºívám NetBeans IDE 6.9.1, coº je poslední verze tohoto IDE s plnou podporou RoR, a pro tuto verzi neexistuje ºádný plugin, zvýraz¬ující a kontrolující syn-
2
taxi CoeeScriptu (pro netbeans takový plugin existuje aº pro verzi 7.0 ). Alternativou by
3
bylo pouºití jiného editoru (nap°íklad TextMate ), ov²em problém by to nevy°e²ilo, protoºe p°epínání mezi r·znými editory by bylo také velice nep°íjemné.
<www.coffeescript.org>
3
1 2
9
KAPITOLA 3.
JavaScript
VÝB
R TECHNOLOGIÍ
je standardním skriptovacím jazykem vkládaným do HTML stránek. S jeho
pouºíváním mám velké zku²enosti a proto jsem se rozhodl pouºít ho i v aplikaci Kucha°ka. Narozdíl od CoeeScriptu NetBeans 6.9.1 pln¥ podporují zvýraz¬ování a kontrolu jeho syntaxe, coº mi usnadnilo vývoj a u²et°ilo spoustu £asu p°i hledání chyb a formátování.
3.2 Databáze Rails nativn¥ podporují p°ipojení ke t°em r·zným typ·m SQL databází: SQLite, MySQL a PostgreSQL.
SQLite
je databáze, která je nastavena jako defaultní u nov¥ vygenerovaného projektu. Je
uloºena v jediném souboru, takºe je snadno p°enositelná a pro p°ipojení není nutno spou²t¥t ºádnou externí sluºbu (vyuºívá se jednoduché knihovny, která je sou£ástí rails frameworku a ten bez nutnosti zásahu obstará v²e pot°ebné). Pro aplikaci je v²ak nevhodná, protoºe kv·li absenci kon gurace není nabízena na ºádném pouºitelném hostingu.
MySQL
je v sou£asnosti asi nejpouºívan¥j²í neplacený databázový systém. Jeho vyuºití
spo£ívá zejména v kombinaci s PHP, ov²em na²el jsem ho nabízený i na rails hostingu . Pro úsp¥²né p°ipojení je vyºadována instalace a spu²t¥ní MySQL sluºby. Dlouho jsem zvaºoval vyuºití tohoto databázového systému, zvlá²t¥ kdyº jsem plánoval nasazení na , ov²em nakonec jsem se p°iklonil k jiné variant¥.
PostgreSQL com/>,
je databázový systém, zdarma nabízený na serveru
kam byla aplikace náln¥ nasazena (viz Kapitola 7 - Pilotní provoz). Proto jsem se
rozhodl pro jeho vyuºití ve vývojovém i testovacím prost°edí. Stejn¥ jako MySQL, i PostgreSQL je pot°eba nainstalovat a poté spustit sluºbu, zaji²´ující p°ipojení. Instalace je pom¥rn¥ jednoduchá, protoºe a£koliv je PostgreSQL vyvíjen primárn¥ pro Linux, existují i instala£ní balí£ky pro platformy Win32 a Win64, kterými se sta£í proklikat a systém je okamºit¥ p°ipraven k pouºití.
3.3 Pouºité frameworky 4
Krom¥ základních programovacích jazyk· jsem byl také nucen se rozhodnout, jaké gemy
budou v alikaci pouºity. K tomu, abych mohl pot°ebné gemy najít a vybrat, bylo nutné si ujasnit funkcionalitu aplikace a ur£it, jakou £ást budu vyvíjet a pro jakou bude lep²í pouºít vhodný gem. Z toho d·vodu se výb¥r gem· prolínal jak do analýzy (ur£ení funkcionality), tak i do vývoje (na²el jsem vhodný gem pro funkcionalitu, kterou jsem p·vodn¥ plánoval implementovat sám). V dob¥ nasazení jsem nakonec dosp¥l k seznamu následujících pouºívaných gem·: 4
Synonymum pro Ruby framework
10
3.3.
•
POUITÉ FRAMEWORKY
5 - slouºí k propojení a komunikaci s PostgreSQL databází, která je pouºita z d·vodu
pg
kompatibility test· ve v²ech prost°edích. P·vodn¥ m¥l být (a v za£átcích vývoje také byl) pouºit gem sqlite3 pro propojení s SQLite databází, ale server pro nasazení tento typ databáze nepodporuje, a tak byla z d·vod· kompatibility ve v²ech prost°edích pouºita PostgreSQL databáze.
6 - slouºí k autentizaci uºivatel.
•
Sorcery
•
CarrierWave
•
Cloudinary
7 - slouºí k uploadingu obrázk·.
8 - slouºí k uploadingu obrázk· na vzdálený server. Je pouºíván v rámci
CarrierWave.
9 - slouºí ke zji²´ování code coverage test·.
•
SimpleCov
•
Selenium-webrdiver
•
Rspec-rails
•
Capybara
10 - driver pro selenium testy.
11 - roz²i°uje funkcionalitu integra£ních test·.
12 - slouºí ke zjednodu²ení psaní a roz²í°ení funkcionality integra£ních test·.
Vyuºívá gemy Selenium-webrdiver a rspec-rails.
Krom¥ Ruby gem· byla je²t¥ pouºita následující dv¥ roz²í°ení JavaScriptu/CSS:
•
Kolekce styl· Twitter Bootstrap
13 , která obsahuje p°edde nované CSS3 ²ablony a
usnadnila tak vývoj view £ásti aplikace.
•
Plugin jQuery [15] [16], který za prvé úzce spolupracuje s Twitter Bootstrap (nap°íklad p°i vyjíºd¥ní modálních formulá°·) a za druhé výrazn¥ roz²i°uje základní funkcionalitu JavaScriptu.
7 8 9 10 11 12 13 5
6
11
KAPITOLA 3.
VÝB
R TECHNOLOGIÍ
12
Kapitola 4 Sb¥r poºadavk·, analýza, návrh
Tato kapitola obsahuje podrobný popis t°í základních krok·, které bylo v daném po°adí nutno provést p°ed samotným za£átkem vývoje SW.
4.1 Vize Cílem projektu je implementovat webový nástroj pro v²echny zájemce o va°ení, který umoºní sdílení, hodnocení, ukládání a vyhledávání recept· mezi uºivateli i ve°ejnosti. Aplikace musí mít jednoduché rozhraní, které bude pohodln¥ ovladatelné.
Vytvo°ená aplikace bude slouºit ke sdílení kucha°ských recept· mezi uºivateli, v receptech bude moºno vyhledávat, autor receptu bude mimo ingredience a postup moci p°idat i £lánek. Recepty bude moºno hodnotit, komentovat, p°ípadn¥ upravovat a mazat.
D·leºitou £ástí aplikace bude vyhledávání recept· pomocí algoritmu "ledni£ky", kde uºivatel zadá pouze suroviny které má dostupné a ve výsledcích se zobrazí recepty, které je moºné z daných surovin uva°it.
4.2 Analýza Analýza byla zpracovávána v n¥kolika krocích, kdy vºdy po konzultaci se zadavatelem byly odstran¥ny chyby. Celý výsledný dokument naleznete na p°iloºeném CD ve sloºce documents.
4.2.1 Poºadavky Ve²keré poºadavky byly rozd¥leny do dvou skupin - funk£ní a nefunk£ní. Jejich £íslovaný seznam je uveden v p°íloze C.
Funk£ní poºadavky
ur£ují rozsah aplikace a její chování vzhledem k uºivateli.
13
KAPITOLA 4.
SB
R POADAVK, ANALÝZA, NÁVRH
Vzhledem k tomu, ºe se dle zadání jedná o sociální sí´, byla jedním z hlavních poºadavk· kompletní správa uºivatel·. Tím se rozumí moºnost registrace (s aktivací ú£tu p°es e-mail), p°ihla²ování a odhla²ování registrovaného uºivatele a samoz°ejm¥ také p°ítomnost administrátorských ú£t·, které mají moºnost spravovat aplikaci a upravovat oprávn¥ní u jiných uºivatel·.
Dal²ím zásadním poºadavky se týkaly p°idávání, správy a editace recept·. Na základ¥ svých oprávn¥ní bude kaºdý uºivatel moci p°idávat/editovat/mazat recepty. Po p°ihlá²ení
1 bude
bude moºné kaºdý recept hodnotit známkou 1-5 a také p°idávat komentá°e. Editor
2 moci ke kaºdému receptu p°idávat ingredience, v£etn¥ jejich d·leºitosti a mnoºství. Zárove¬ bude moci propojit libovolné mnoºství souvisejících £lánk· a recept·.
Krom¥ recept· bude aplikace také obsahovat ingredience, kategorie ingrediencí a recept· a £lánky. Tvorba, editace a mazání £lánk· bude probíhat stejn¥ jako u recept·. Ingredience bude moºné p°idávat v²emi uºivateli (aby v p°ípad¥, ºe daná ingredience není v databázi nebyla brzd¥na tvorba receptu) a budou revidované adminy. Kategorie budou výhradn¥ ve správ¥ administrátor·.
V aplikaci bude moºné vyhledávat podle klí£ové fráze, detailního ltru a ltru ledni£ky. Do ltru ledni£ky uºivatel zadá seznam ingrediencí a aplikace vrátí recepty, které je moºné z daných surovin uva°it, se°azené podle relevance.
Nefunk£ní poºadavky
neur£ují p°ímo chování aplikace a její funk£nost, ale zam¥°ují se
spí²e na obecné vlastnosti a technologie.
Nefunk£ních poºadavk· nebylo mnoho. Jediným výrazn¥j²ím omezením byl vývoj na platform¥ Ruby on Rails, který lze vy£íst i ze zadání Bakalá°ské Práce. Dal²ím poºadavkem byla podpora ve v²ech hlavních webových prohlíºe£ích, tedy Internet Explorer, Google Chtome, Mozilla Firefox, Opera a Safari. Bylo také poºadováno p°íjemné a intuitivní webové rozhraní, coº je vlastn¥ i jeden z hlavních d·vod·, pro£ vyvíjet novou aplikaci typu kucha°ka (viz kapitola 2 - Re²er²e podobných aplikací). Poslední 2 poºadavky by m¥ly být zaji²t¥ny knihovnou Twitter Bootstrap.
4.2.2 Scéná°e uºití Uvádím zde pouze p°ehled scéná°· uºití s výpisem jednotlivých actor·. Podrobný rozpis jednotlivých scéná°· by p°íli² natahoval dokument, a proto je uveden v p°iloºeném souboru documents/Analyza.pdf. 1 2
uºivatel s moºností editace dané poloºky koe cient dopadu na kvalitu receptu, pokud kucha° danou ingredienci z receptu vynechá
14
4.2.
ANALÝZA
Obrázek 4.1: Seznam scéná°· uºití
Seznam actor·:
•
Nep°ihlá²ený uºivatel - libovolný uºivatel, který se nep°ihlásí do systému. Má pouze omezené pravomoci.
3
•
B¥ºný uºivatel - uºivatel, který se p°ihlásil do systému a má p°id¥lena defaultní práva .
•
Admin - b¥ºný uºivatel, který má p°id¥lena práva nad mnoºinu defaultních.
•
Root - ú£et, zaloºený p°i první migraci databáze. Obsahuje v²echny pravomoce, které nelze m¥nit.
4.2.3 Doménový model Doménový model, znázorn¥ný na obrázku 4.2, ukazuje, jakým zp·sobem bude °e²ená datová £ást aplikace.
T°ídy
•
Clanek volitelný £lánek p°ipojený k receptu.
•
ReceptIngredience ur£uje, jak moc je daná ingredience pro recept d·leºitá a kolik je jí t°eba.
defaultní práva zahrnují zobrazování obsahu DB, v²echny operace nad vlastními recepty a £lánky a také p°idávání komentá°· a hodnocení 3
15
KAPITOLA 4.
SB
R POADAVK, ANALÝZA, NÁVRH
Obrázek 4.2: Doménový model
16
4.2.
•
PropojenyRecept slouºí k propojování souvisejících recept·.
•
Hodnoceni hodnocení receptu.
•
Ingredience ingredience na p°ípravu recept· p°idané do systému.
•
KategorieIngredience skupiny do kterých se budou °adit ingredience.
•
KategorieReceptu skupiny do kterých se budou °adit recepty.
•
Komentar komentá° k receptu.
•
Mnozstvi mnoºství dané ingredience pro daný recept.
•
Recept recept uloºený v systému.
•
Uzivatel registrovaný uºivatel.
ANALÝZA
4.2.4 Zasílání zpráv v rámci aplikace B¥hem analýzy byly také vytvo°eny sekven£ní diagramy n¥kterých d·leºitých akcí pro znázorn¥ní, jakým zp·sobem p°i nich bude probíhat komunikace v rámci aplikace.
Na prvním diagramu (obrázek 4.3) je zobrazeno
p°ihla²ování uºivatele. Uºivatel musí
nejprve poºádat o zobrazení libovolné stránky. V rámci stránky je na£ten i p°ihla²ovací formulá°, o jehoº zobrazení uºivatel zaºádá v následujícím kroku. Po vypln¥ní p°ihla²ovacích údaj· a jejich odeslání uºivatelem je ze stránky poslán poºadavek na server, kde je v rámci UserSessions zpracován a uºivateli je vrácena aktualizovaná p·vodní stránka.
Obrázek 4.3: Sekven£ní diagram 1 - p°ihlá²ení uºivatele
Na druhém diagramu (obrázek 4.4) je zobrazen pr·b¥h
vyhledávání.
Situace je velmi
podobná jako u p°ihla²ování uºivatele. Pouze na stran¥ serveru p°ibyl je²t¥ helper, který zaji²´uje ltrování a výb¥r poloºek z databáze, aby samotný kód controlleru recept· z·stal stru£ný a p°ehledný.
17
KAPITOLA 4.
SB
R POADAVK, ANALÝZA, NÁVRH
Obrázek 4.4: Sekven£ní diagram 2 - vyhledávání recept·
T°etí a poslední diagram (obrázek 4.5) znázor¬uje
p°idání poºadavku na novou ingre-
dienci. Zajímavý je zejména proto, ºe posílání poºadavku na ingredienci jediným místem
v aplikaci, kde je volán AJAX request. Ten je volán synchronn¥, a to z d·vodu snaz²ího odlad¥ní aplikace a také okamºitého p°idávání nové ingredience do rozbalovacího seznamu ingrediencí v rámci receptu. Pokud by byl AJAX request volán asynchronn¥, p°i slab²ím p°ipojení by nastala mezi odesláním a p°idáním poloºky do seznamu prodleva, která by mohla uºivatele mást. Takto alespo¬ bude v¥d¥t, ºe se "n¥co d¥je"a nebude mít moºnost b¥hem posílání poºadavku recept upravovat. Po zpracování poºadavku je upravena komponenta seznamu ingrediencí podle jeho výsledku a uºivateli je výsledek zobrazen v
alert()
okn¥.
Obrázek 4.5: Sekven£ní diagram 3 - odeslání poºadavku na novou ingredienci
4.3 Gra ka Tato kapitola obsahuje ukázky gra ckých návrh·, které byly vytvo°eny je²t¥ p°ed zapo£etím vývoje. Obrázky v plné velikosti jsou uloºeny v p°iloºeném archivu ve sloºce Gra ckeNavrhy. P·vodní návrhy byly vytvo°eny v rámci p°edm¥tu SI2, poté ale pro²la celá aplikace refactoringem a n¥které obrazovky byly £áste£n¥ upraveny.
18
4.3.
GRAFIKA
Návrh vzhledu úvodní stránky pro nep°ihlá²eného uºivatele. Pro p°ihlá²eného uºivatele bude stejná jako pro nep°ihlá²eného, bude se li²it jen v horním panelu.
Obrázek 4.6: Návrh - Úvodní stránka
19
KAPITOLA 4.
SB
R POADAVK, ANALÝZA, NÁVRH
Návrh vzhledu ltru ledni£ky, kde bude moºné p°idávat/odebírat ingredience, co máte doma a podle nich pak budou vyhledány recepty. Odkaz na ledni£ku bude p°ítomný na kaºdé stránce uvnit° banneru.
Obrázek 4.7: Návrh - Ledni£ka
20
4.3.
GRAFIKA
Návrh vzhledu detailu receptu.
Obrázek 4.8: Návrh - Recept
Návrh vzhledu obrazovky pro editaci mých recept·. Jsou zde zobrazeny recepty aktuáln¥ p°ihlá²eného uºivatele a poté jím seznamy komentovaných a hodnocených recept·.
Obrázek 4.9: Návrh - Moje recepty
21
KAPITOLA 4.
SB
R POADAVK, ANALÝZA, NÁVRH
22
Kapitola 5 Implementace
Tato kapitola obsahuje informace o n¥kterých d·leºitých £ástech projektu, které byly implementovány. Nezabývá se implementací jako celkem, popisuje pouze zajímavé £asti aplikace. Zárove¬ popisuje pohled na v¥c z mého (programátorského) hlediska a popis r·zných problém·, které se na cest¥ za vyty£eným cílem vyskytly.
5.1 Struktura aplikace Aplikace je navrºena architekturou MVC, kterou Rails nejenºe pln¥ podporují, ale snaºí se k ní i vývojá°e dotla£it. Základní rozd¥lení do sloºek je dle klasického Rails modelu, který je
1
podrobn¥ popsán v nejr·zn¥j²ích £láncích a speci kacích, týkajících se rails . Nad rámec rails modelu pak p°ibyly je²t¥ sloºky
app/Mailers
(t°ídy pro odesílání email·) a
app/Upoaders
(t°ídy pro nahrávání soubor· na server).
5.2 Mapování databáze K mapování objekt· na databázi slouºí v Rails t°ída ActiveRecord [6]. Z ní d¥dí v²echny modely a tím získávají velice uºite£nou funkcionalitu bez nutnosti radikálních zásah· a dopl¬ování zdrojového kódu.
Ov²em ani velice propracovaná t°ída ActiveRecord nedokáºe automaticky pokrýt v²echny moºnosti, které mohou v datové vrstv¥ nastat. Proto je ob£as pot°eba zapojit trochu programátorského umu a abstraktního my²lení.
5.2.1 M:N vazby Asi nejv¥t²ím problémem bylo namapování vazeb many-to-many. A£koliv je jejich funkcionalita v Rails podporovaná, bylo obtíºné zajistit, aby v²e fungovalo tak jak má. Kritické body nastaly p°i mapování vazeb s dopl¬ujícími informacemi (recept x ingredience) a také vazeb v rámci jedné tabulky (podpostupy). 1
23
KAPITOLA 5.
IMPLEMENTACE
V prvním p°ípad¥ bylo nutné vytvo°it model pro spojovací tabulku, aby bylo moºné se na ni odkazovat a tím pádem i získávat atributy vazby. Vazební t°ída tedy vypadá takto:
class
I n g r e d i e n c e R e c i p e C o n n e c t o r < A c t i v e R e c o r d : : Base
belongs_to
: ingredience
belongs_to
: recipe
attr_accessible
: importance ,
: quantity
% validatory
end
K vazbám a atribut·m se pak dá p°istupovat t¥mito zp·soby: @recipe . i n g r e d i e n c e s [ i ] % nebo @recipe . ingredienceRecipeConnectors [ i ] . i n g r e d i e n c e @recipe . ingredienceRecipeConnectors [ i ] . importance @recipe . ingredienceRecipeConnectors [ i ] . quantity
Ve druhém p°ípad¥ bylo nutné krom¥ vytvo°ení modelu pro spojovací tabulku také obejít standardní vazební funkcionalitu Rails, která automaticky zaji²´uje p°ístup k propojeným objekt·m p°es p°ímý atribut mapovaného objektu a nade novat si ho explicitn¥. Výsledná implementace spojovací t°ídy je následující:
class
R e c i p e R e c i p e C o n n e c t o r < A c t i v e R e c o r d : : Base
belongs_to
: recipe ,
: c l a s s _ n a m e => belongs_to
' Recipe ' ,
: f o r e i g n _ k e y =>
' recipe_id '
' Recipe ' ,
: f o r e i g n _ k e y =>
' subrecipe_id '
: recipe_id ,
: subrecipe_id
: subrecipe ,
: c l a s s _ n a m e => attr_accessible
end
Implementace atributu, odkazujícího p°ímo na v²echny propojené recepty: has_many
: subrecipes ,
: f o r e i g n _ k e y =>
' recipe_id ' ,
: c l a s s _ n a m e =>
' RecipeRecipeConnector '
K propojeným recept·m se poté p°istupuje: @recipe . su b re ci p es
5.3 Logování Kaºdý nový projekt v rails obsahuje jiº od svého vzniku logger, do kterého jsou zaznamenávány v²echny základní události aplikace, jako je nap°íklad manipulace s databází nebo stavy
24
5.4.
ZABEZPEENÍ APLIKACE
na£ítání stránek a jejich sou£ástí. Jeho výhodou je velká detailnost logovaných informací, na druhou stranu nevýhodou je nízká p°ehlednost. Proto jsem se rozhodl implementovat logování i do jiných soubor·, které budou p°ehledn¥ uspo°ádány a obsahovat pouze logicky podobné informace v rámci jednoho souboru. Výchozí logovací soubor byl samoz°ejm¥ ponechán.
Inicializace dopl¬ujících logovacích soubor· je provád¥na v inicializátoru logging.rb. Zde je vytvo°en hash logger·, které spl¬ují konvenci, ºe klí£ hashe odpovídá názvu souboru (bez p°ípony), dopln¥ný zp°edu o typ prost°edí, ve kterém aplikace b¥ºí, a znak "_". Dodrºení této konvence je nutné pro správný p°ístup k log·m v rámci aplika£ního uºivatelského rozhraní.
Heroku totiº nenabízí moºnost zobrazení jiného logu, neº je výchozí. Proto byla do aplikace p°idána sekce pro administraci log· (poloºka Aplika£ní logy v menu Seznamy), která na£ítá logy za soubor· a zobrazuje je p°ímo v prohlíºe£i. Bu¤ v rámci aplikace (v£etn¥ layoutu), nebo v prosté textové form¥, kterou je snadné si stáhnout.
V sou£asné dob¥ je aplikace roz²í°ena pouze o jeden log (page_requests), který loguje pouze poºadavky na zobrazení stránek, jejich parametry a uºivatele s IP, odkud byl poºadavek poslán. Ukázka: 14.05.2013 ,
12:28:23
( admin@127 . 0 . 0 . 1 ) :
"GET h t t p : / / l o c a l h o s t : 3 0 0 0 / " ( { " c o n t r o l l e r "=>"home" , 14.05.2013 ,
12:28:27
requested
" a c t i o n "=>" i n d e x " } )
( admin@127 . 0 . 0 . 1 ) :
"GET h t t p : / / l o c a l h o s t : 3 0 0 0 / r e c i p e s /1 " ( { " a c t i o n "=>" show " ,
page
page
requested
" c o n t r o l l e r "=>" r e c i p e s " ,
" i d "=>" 1 " } )
5.4 Zabezpe£ení aplikace Vzhledem k tomu, ºe aplikace umoº¬uje pro kaºdého uºivatele speci cké nastavení oprávn¥ní, bylo nutné vytvo°it funkce, které budou tato oprávn¥ní kontrolovat a podle nich rozhodovat, které akce uºivateli povolí a které ne.
Rails tuto problematiku velice zjednodu²ují svojí MVC architekturou a zárove¬ podporou
before_filter, který je²t¥ p°ed spu²t¥ním akce v controlleru rozhodne, zda je daná akce povolená. Na before_filter se dá namapovat libovolná funkce typu boolean. Pokud vrátí true, je akce povolena, v ope£ném p°ípad¥ je p°ístup na stránku odep°en.
Ke kontrole uºivatelských oprávn¥ní jsem vytvo°il modul
permissions_helper.
Ten ob-
sahuje jednu centrální funkci, která na základ¥ controlleru a akce (tyto hodnoty jsou posílané jako parametry http poºadavku a lze je nalézt v prom¥nné
params[:action]
resp.
params[:controller]) rozhodne, jakou autoriza£ní funkci volat a dále samotné autoriza£ní funkce, pro kaºdý controller jednu.
25
KAPITOLA 5.
IMPLEMENTACE
Centrální funkce byla v aplika£ním controlleru p°idána jako
before_filter a pokud auto-
rizace selºe, p°esm¥rovává uºivatele automaticky na stránku s chybovou hlá²kou, ºe p°ístup byl odep°en. V opa£ném p°ípad¥ vrací true a akce controlleru m·ºe být provedena.
Autoriza£ní funkce pro controllery obsahují z d·vodu pouºitelnosti i mimo lter n¥kolik parametr·. Standardn¥ jsou jimi:
•
akce - akce controlleru, pro kterou je provád¥na autorizace; tento parametr je povinný
•
params - parametry, které byly poslány na stránku. Pouºijí se k na£tení dat z databáze (nap°. kontroluji show akci pro recept s daným id a pot°ebuji tak znát jeho autora) a p°ípadným dal²ím akcím, v závislosti na controlleru a akci.
•
entity - pokud uº mám p°edem na£tený odpovídající záznam z databáze (nap°. konkrétní recept), nepot°ebuji uº params, abych si ho znova na£etl; Tento parametr slouºí hlavn¥ k optimalizaci pro práci s databází, protoºe kdyº pot°ebuji jen zjistit, jestli mám v seznamu zobrazit tla£ítko na editaci jiº na£teného receptu (tzn. mám práva editovat - ov¥°uji p°es autoriza£ní funkce), nebudu podruhé sahat do databáze a tím odleh£ím serveru.
Tyto funkce jsou pouºity jak p°i na£ítání nové stránky, tak p°i zobrazování r·zných komponent na stránce (nap°. tla£ítko EDIT zobrazím pouze v p°ípad¥, ºe mám moºnost daný objekt editovat).
Ukázka de nice autoriza£ní funkce:
def
r e c i p e s _ f i l t e r ( action ,
p,
entity )
Ukázka pouºití autoriza£ní funkce p°i zobrazování tla£ítka: <%= recipes_filter (" edit " ,
nil ,
@recipe )
? button_to ( " Upravit {
recept " ,
: controller
=> " r e c i p e s " ,
: a c t i o n => " e d i t " , : i d => @ r e c i p e . i d } , {
: method =>
: get ,
:
class
:
nil %>
5.5 Validace odesílaných dat P°i odesílání dat probíhají t°i úrovn¥ validací:
•
Frontendová validace
26
=> " b t n " } )
5.5.
•
Backendová validace
•
Validace na úrovni DB
Frontendová validace
VALIDACE ODESÍLANÝCH DAT
zabra¬uje odesílání formulá°e v p°ípad¥ ºe obsahuje nepouºitelná
data a tím zabra¬uje zbyte£nému posílání dat na trase klient-server. Je implementována pomocí JavaScript·. Kaºdá stránka s moºností odeslání formulá°e má vlastní script, který za pouºití funkcionality ru£n¥ napsané knihovny
Validator.js
nastaví p°i na£tení dokumentu
v²echny pot°ebné validace. Dlouho jsem zvaºoval pouºití jQuery validátor·, ale jejich funkcionalita je po°ád je²t¥ zna£n¥ omezená a vlastní implementace se v této, ne p°íli² rozsáhlé problematice, jeví jako optimální.
Backendová validace
se provádí t¥sn¥ p°ed p°íkazem pro uloºení dat do databáze a její
význam nastupuje v p°ípad¥, ºe do²lo k odeslání chybných dat i p°es frontendovou validaci (nap°. p°ímým zadáním URL s odesílanými daty). Je implementována p°ímo ve t°ídách model·. Vzhledem k tomu, ºe rails tyto validace hojn¥ podporují a existuje celá °ada p°edde novaných valida£ních metod, bylo napsání této úrovn¥ vcelku snadné. Zde je ukázka validace uºivatelského jména: validates
: username ,
: f o r m a t => {
: w i t h => / ^ [ a−zA−Z0 − 9 \ . \_\ − ] { 3 , 3 0 } $ /
: u n i q u e n e s s => {
:
if
=>
: c a s e _ s e n s i t i v e =>
false
},
},
: username
Podobnými validacemi jsem pokryl v²echny atributy model·, dostupné k editaci, a tak by m¥lo být zaji²t¥no, ºe do databáze v ºádném p°ípad¥ nebudou posílána chybná data. V p°ípad¥ ºe backendová validace selºe a jsou odhaleny chyby je uºivatel p°esm¥rován zp¥t na p·vodní stránku a jsou zobrazeny komentá°e k nalezeným chybám. Tyto komentá°e mají stejný text i vzhled jak pro frontendové, tak i backendové validace. Synchronizace textací pro tyto dva typy validací je zaji²t¥na pomocí kon gura£ního souboru
config/validation_error_messages.yml.
Validace na úrovni DB
je provád¥na p°ímo sluºbou p°íslu²né databáze a vychází z
atribut· sloupc· dané tabulky. Z programátorského hlediska je moºné ji ovlivnit pouze p°i migraci databáze, proto jsem p°i migraci kladl d·raz na podrobnou speci kaci jednotlivých sloupc· v dané tabulce. Zde je ukázka skriptu na vytvo°ení tabulky recept·: create_table t . string
: recipes
do
|t|
: name ,
: n u l l =>
t . text
: annotation ,
: n u l l =>
t . text
: content ,
: n u l l =>
t . integer
: level ,
t . integer
: estimated_time ,
t . references
: user ,
: n u l l => : n u l l => : n u l l =>
t . timestamps
end
27
false false false false , false , false
: d e f a u l t => 0 : d e f a u l t => 60
KAPITOLA 5.
add_index
IMPLEMENTACE
: recipes ,
: user_id
Pokud selºe validace na úrovni databáze, je uºivateli zobrazena chybová hlá²ka, ºe nastalo k neo£ekávané chyb¥ na serveru. To platí i v p°ípadech, ºe databáze není v·bec dostupná (výpadek apod.). Toto °e²ení sice není uºivatelsky nejp°íjemn¥j²í, ale vzhledem k tomu, ºe by se podobná chyba m¥la objevovat jen velmi výjime£n¥, nem¥l jsem ºádný relevantní d·vod snaºit se obejít toto standardní chování rails.
5.6 Vyhledávací algoritmus ledni£ky Vyhledávání podle ledni£ky bylo jedním ze základních poºadavk· p°i analýze a návrhu aplikace, proto je pot°eba v¥novat mu mimo°ádnou pozornost.
P·vodním návrhem bylo implementovat jednoduchý modální formulá°, do kterého budou zadány ingredience s mnoºstvím a po jehoº odeslání bude zobrazena stránka z výsledky. B¥hem implementace jsem ale zjistil, ºe toto °e²ení nepat°í k uºivatelsky nejp°íjemn¥j²ím, a proto jsem se rozhodl rozd¥lit vyhledávání na dv¥ fáze.
V první fázi z·stal modální formulá°, do kterého uºivatel zadá pouze ingredience, bez mnoºství. Poté je zobrazena stránka s výsledky, kde je formulá°, ve kterém je moºné dále up°es¬ovat podmínky vyhledávání (druhá fáze).
5.6.1 První fáze V první fázi je celý formulá° realizován pomocí JavaScriptu v souboru 00_fridge.js ve sloºce application. Tento script zaji²´uje p°idávání a odebírání ingrediencí, zadávání jejich mnoºství a výslednou frontendovou validaci. Pokud validace projde, data jsou posílaná jako pole parametr· http metodou GET (p·vodn¥ m¥la být posílána jako POST, aby se p°edcházelo moºnosti ru£n¥ do adresy zadat nesprávné hodnoty, ale aplikace v tomto p°ípad¥ z neznámých d·vod· odhla²ovala aktuálního uºivatele, a tak jsem od této metody ustoupil p°ínos neodpovídá £asu, který by byl stráven nad pokusy o eliminaci chyby). Pole obsahuje id jednotlivých vybraných ingrediencí.
5.6.2 Druhá fáze Jak jiº bylo psáno vý²e, druhou fází ltrace podle ledni£ky je formulá°, zobrazený v horní £ásti stránky jiº vy ltrovaných výsledk·. Je jiº p°edvypln¥ný podle posledn¥ odeslaného ltru a je moºné v n¥m up°esnit mnoºství jednotlivých ingrediencí. Po odeslání jsou uºivateli zobrazené aktualizované výsledky a znova formulá° 2. fáze.
5.6.3 Zpracování dotazu Po odeslání dojde na serveru ke zpracování poºadavku v následujících krocích:
28
5.6.
VYHLEDÁVACÍ ALGORITMUS LEDNIKY
1. Validace poºadavku (aby nedocházelo k chyb¥ v p°ípad¥ nesprávn¥ poslaných dat). Pokud je poºadavek neplatný, nejsou na výsledné stránce zobrazeny ºádné recepty. 2. Na£tení v²ech recept· z DB. 3. Zparsování poºadavku a uloºení do pole. 4. Spo£ítání koe cientu pro kaºdý recept. Koe cient je v rozmezí 0-1. Pokud je koe cient v¥t²í nebo roven 0.5, je p°idán do pole vracených výsledk·. 5. Se°azení pole vracených výsledk· od nejvy²²ího koe cientu po nejniº²í. 6. Výpis vy ltrovaného seznamu. Tento postup je sice trochu krkolomný, protoºe p°i kaºdém vyhledávání podle ledni£ky se vyberou v²echny recepty a po£ítá se pro n¥ koe cient, ale v sou£asné dob¥ jsem zatím nep°i²el na jiný zp·sob, jak z databáze p°edem vy ltrovat nepot°ebné poloºky a po£ítat koe cienty pouze na t¥ch, které bude moºné p°idat do výsledk·.
Po£ítání koe cient·:
•
Spo£te se celková d·leºitost ingrediencí v receptu.
•
Pro kaºdou ingredienci se spo£ítá koe cient zastoupení, který je v rozmezí 0-1 * d·leºitost ingredience a p°idá se k mezisou£tu celkového koe cientu.
•
Poté co jsou iterovány v²echny ingredience se mezisou£et celkového koe cientu, vyd¥lí celkovou d·leºitostí ingrediencí a výsledek je koe cient receptu podle ledni£ky.
Implementace:
def
get_recipe_koef_for_fridge ( recipe ,
koef = sum =
p,
ingrediences )
0.0; 0.0;
# pokud nemam u receptu zadne ingredience , vrati se mi # s nejnizsim moznym vysledkem tak , aby byl zahrnut do # vysledku , ale az na posledni pozici if
r e c i p e . i n g r e d i e n c e R e c i p e C o n n e c t o r s . l e n g t h == 0
return end
MIN_KOEF_FOR_FRIDGE_RESULT
# pokud ingredience mam, pocitam for
recipe_ingredience
in
recipe . ingredienceRecipeConnectors
sum += r e c i p e _ i n g r e d i e n c e . i m p o r t a n c e
for i n g r e d i e n c e in p i f ( ingredience [ : id ] k o e f += [ 1 ,
== r e c i p e _ i n g r e d i e n c e . i n g r e d i e n c e _ i d )
(
ingredience [ : quantity ]
?
ingredience [ : quantity ]/ recipe_ingredience . quantity
29
:
KAPITOLA 5.
IMPLEMENTACE
1 ) ] . min
end end end return k o e f end
∗
r e c i p e _ i n g r e d i e n c e . importance
/ sum ;
5.7 Struktura JavaScript· A£koliv podpora OOP v JavaScriptu není úpln¥ ideální, rozhodl jsem se jít touto cestou, protoºe výsledný kód je mnohem p°ehledn¥j²í, snáze zdokumentovatelný a ve spoust¥ p°ípad· také lépe znovupouºitelný.
Abych dodrºel stejnou strukturu ve v²ech scriptech, jsou v²echny funkce zapouzd°ené v objektech. Ve v¥t²in¥ p°ípad· se jedná o jednoinstan£ní objekty (asi nejlépe by ²ly p°irovnat k javovským singleton·m), které jsou vytvo°eny hned p°i na£ítání scriptu a inicializovány po na£tení dokumentu.
5.7.1 Rozd¥lení assets/javascripts Sloºka assets/javascripts je rozd¥lena na t°i logické £ásti: application, bootstrap a pages.
Application
obsahuje v²echny skripty, pot°ebné pro bezproblémový chod aplikace, na-
cházející se na více neº jedné stránce. Sloºka
application.js
Bootstrap
assets/application
je zahrnuta v souboru
jako automatický import.
obsahuje skripty, pot°ebné pro chod bootstrap frameworku. Vzhledem k tomu,
ºe framework je pom¥rn¥ rozsáhlý a obsahuje r·zné pluginy, které mohou být v budoucím vývoji pouºity, rozhodl jsem se pro n¥j v assets vytvo°it samostatnou sloºku. Obsah této sloºky je v souboru
application.js automaticky importován je²t¥ p°ed assets/application. Za-
chování tohoto po°adí je nutné, aby aplika£ní skripty m¥ly moºnost vyuºívat funkcí frameworku bootstrap.
Pages
obsahuje skripty, speci cké pro jednotlivé stránky. Tyto skripty jsou zahrnuty p°ímo
ve stránkách a neprobíhá tedy ºádné automatické na£ítání do hlavi£ky. Konvence pro pojmenovávání skript· je
controller_action.js,
váºe.
30
aby bylo jasné, ke které stránce se skript
5.8.
IMPLEMENTACE AJAXU
5.7.2 Ukázky Application.js
je podle Rails konvencí skript, který zaji²´uje automatické na£ítání ostat-
ních skript·. M·ºe obsahovat i samotný kód, ale vyuºívání této moºnosti se p°íli² nedoporu£uje a proto jsem jí nevyuºil ani já. Skript pouze obsahuje importy jiných skript· a to p°esn¥ v daném po°adí.
Standardní skript
obsahuje jeden nebo více objekt· se speci ckou funkcionalitou a ini-
cializa£ní funkcí, která je volána po na£tení dokumentu.
var
IngredienceRequest = { init :
function ( )
{
/* inicializacni kod */ },
/* dalsi funkcionalita */ } $ ( document ) . r e a d y (
function ( ) {
IngredienceRequest . i n i t ( ) ; });
5.8 Implementace AJAXu A£koliv jsem se v aplikaci snaºil z d·vodu p°ehlednosti a £itelnosti vyhnout volání AJAX request·, v n¥kterých situacích, jako nap°íklad posílání ºádosti na ingredienci, to moºné nebylo. Pro tyto situace jsem zvolil následující °e²ení: volání AJAX requestu je zaji²´ováno pomocí jQuery frameworku, datová vým¥na je pak zaji²t¥na v JSON formátu, který jak jQuery, tak Rails výborn¥ podporují.
Ukázka volání p°i zasílání po°adavku na p°idání ingredience: jQuery . a j a x ({
"/ ingrediences / new_request /" , t y p e : "GET" , d a t a T yp e : " json " , d a t a : " name =" + encodeURIComponent ( url :
I n g r e d i e n c e R e q u e s t . component . name . v a l u e ) +
"& units ="
+ encodeURIComponent (
I n g r e d i e n c e R e q u e s t . component . u n i t s . v a l u e ) +
"& annotation ="
+ encodeURIComponent (
I n g r e d i e n c e R e q u e s t . component . a n n o t a t i o n . v a l u e ) +
"& content ="
+ encodeURIComponent (
I n g r e d i e n c e R e q u e s t . component . c o n t e n t . v a l u e ) , success :
function ( r e s p o n s e )
{
/* zpracovani response */ },
31
KAPITOLA 5.
IMPLEMENTACE
function ( )
error :
{
/* osetreni chyby */ } });
5.9 P°idávání podpostup· a propojených £lánk· P°idávání podpostup· a propojených £lánk· probíhá p°ímo v detailu receptu. Skládá se ze zadání URL £lánku(receptu) k propojení a následného odeslání na server, kde je poºadavek zpracován.
Parametr poºadavku je pouze jediný a jde o url, kterou uºivatel p°ed odesláním zadal. Ta je na serveru zparsována následujícím zp·sobem:
def
add_subrecipe
@ r e c i p e = R e c i p e . f i n d ( params [ : i d ] )
if
params [ : s u b r e c i p e ] @tmp = params [ : s u b r e c i p e ] . s p l i t ( / h t t p . ? \ : \ / \ / [ ^ \ / ] + \ / r e c i p e s \ / / )
if
@tmp . l e n g t h == 2 @msg = @tmp @id = @tmp [ 1 ] . t o _ i
if
@id && @ r e c i p e . s u b r e c i p e s . w h e r e ( : i d => @id ) . l e n g t h == 0 @new_item = R e c i p e R e c i p e C o n n e c t o r . new @new_item . r e c i p e _ i d = params [ : i d ] @new_item . s u b r e c i p e _ i d = @id @new_item . s a v e
end end end
respond_to
do
| format |
f o r m a t . html
{
format . j s o n
{
render
json :
redirect_to
@recipe
}
@recipe . s u br ec i pe s
}
end end V ukázce je algoritmus pro parsování adresy podpostupu. ID z adresy £lánku je získáváno prakticky stejným zp·sobem, jen regulární výraz pro rozd¥lení °et¥zce je trochu pozm¥n¥n. Jak je vid¥t z funkce, controller je p°ipraven zpracovávat i poºadavky ve formátu JSON, coº nabízí moºnost budoucího p°epracování p°idávání £lánk·/podpostup· na volání pomocí AJAX, ov²em v sou£asné chvíli není tato moºnost vyuºita.
32
5.10.
UPLOADING OBRÁZK
Odebírání podpostup· a propojených £lánk· je zaloºené na stejném principu, jako jejich p°idávání. Op¥t se zavolá poºadavek na odebrání z databáze, poté je serverem zpracována odpov¥¤ a vrácena aktualizovaná stránka.
def
remove_subrecipe
@ r e c i p e = R e c i p e . f i n d ( params [ : i d ] )
if
params [ : s u b r e c i p e ] RecipeRecipeConnector . w h e r e ( : r e c i p e _ i d => params [ : i d ] ) . w h e r e ( : s u b r e c i p e _ i d => params [ : s u b r e c i p e ] ) . all ?
end
respond_to
{
|e|
do
}
| format |
f o r m a t . html
{
format . j s o n
{
render
e . delete
redirect_to
json :
@recipe
}
@recipe . su br e ci pe s
}
end end
5.10 Uploading obrázk· Pro uploading obrázk· byly pouºity dva Rails gemy: CarrierWave a Cloudinary. Zatímco CarrierWave zaji²´uje transformaci a konverzi obrázk·, Cloudinary se stará o jejich nahrávání na vzdálený server. Ve vývojovém (i testovacím) prost°edí je moºné pouºít pouze prvn¥ zmín¥ný gem, který je schopný uloºit obrázky v lokálním lesystému (nap°íklad do sloºky public). Produk£ní server ov²em takovouto funkcionalitu z d·vod· zabezpe£ení neumoº¬uje, a proto bylo nutné vyuºít sluºby t°etí strany. Tou je server , umoº¬ující snadný uploading a management obrázk· jak z webového rozhraní, tak i p°ímo z aplikace.
Kon gurace propojení s cloudinary ú£tem se li²í pro produk£ní a vývojové/testovací prost°edí. Na produkci je velice snadné. Sta£í aktivovat free verzi cloudinary add-onu, který uº za°ídí v²e pot°ebné. Ve vývojovém a testovacím prost°edí bylo pro úsp¥²ný uploading nutné vytvo°it nový cloudinary ú£et, poté stáhnout vygenerovaný cloudinary.yml a za£lenit ho do aplikace do sloºky con g.
Ukázka kon gurace: development : cloud_name : api_key :
deaz43406
'898858572865222 '
api_secret :
knkqAzzmSU8ROWU9mOGRqXNepXc
33
KAPITOLA 5.
IMPLEMENTACE
en han ce_ imag e_t ag :
true false
static_image_support :
Implementace byla jiº vcelku snadná. Sta£ilo postupovat podle heroku tutoriálu [3] a návodu p°ímo na webu [1].
5.11 Zhodnocení implementa£ní £ásti Vzhledem k chyb¥jícím p°edchozím zku²enostem s Ruby on Rails frameworkem byla implementace dosti divoká a co se tý£e odhad· doby trvání také nep°edvídatelná. To bylo hlavní p°í£inou zkrácení doby pilotního provozu jen na n¥kolik týdn· (viz kapitola 7 - Pilotní provoz).
Prvních asi p¥t týdn· jsem zkou²el vytvá°et r·zné jednoduché aplikace podle RoR tutoriál· [7]. Teprv poté mi za£ala struktura návrhu aplikace a implementace jednotlivých komponent dávat smysl. Postupn¥ jsem se pak dostal od prostého pochopení railsovské implementace MVC architektury aº ke studiu dokumentace jednotlivých d·leºitých komponent.
Rails disponují výbornou podporou ORM, konkrétn¥ pomocí rozhraní ActiveRecord. Proto práv¥ dokumentace t°ídy AcriveRecord byla v·bec první dokumentací, kterou jsem dopodrobna studoval. Dále jsem se zam¥°il na funkcionalitu a tutoriály pouºívaných gem·. Celé toto studování dokumentace mi usnadnila uniformita jednotlivých tutoriál·, které se Rails komunita snaºí udrºet v co nejobsáhlej²ím a p°esto na pohled jednoduchém formátu. Za to jim pat°í mé velké díky.
34
Kapitola 6 Testy
6.1 Analýza a návrh Analýza prob¥hla v n¥kolika kolech, kdy byla vºdy zadavateli odprezentována aktuální verze dokumentace a poté provedeny úpravy podle vzájemné dohody. Analýza byla párkrát opravována i v pr·b¥hu implementace, protoºe byly zji²t¥ny n¥které nesrovnalosti, které nebylo moºné bez konzultace se zadavatelem a opravy modelu vy°e²it.
6.2 Implementace Jak jiº plyne ze zadání práce, velký d·raz byl kladen na automatické testy implementace aplikace. Tyto testy jsou rozd¥leny na 3 £ásti: jednotkové (testují funk£nost datových model·), funk£ní (testují funkce controller·) a integra£ní (testují komunikaci jednotlivých controller· a správnost výsledných stránek). [8]
6.2.1 Testovací data Testovací data jsou, dle Rails standard·, zapsána v .yml souborech ve sloºce xtures. Z d·vodu jednodu²²ího psaní jsem pro n¥ zavedl n¥kolik konvencí:
•
Pro kaºdý model budou vloºeny alespo¬ 2 záznamy.
•
Kaºdá tabulka musí obsahovat záznamy pojmenované one a two.
•
Tabulky, které nejsou vazební, by m¥ly obsahovat záznam pojmenovaný
nowhere_used.
Ten není obsaºen v ºádných vazbách.
•
Tabulka users obsahuje záznam admin. Ten je uveden na prvním míst¥ .yml souboru, má pevné ID=1 a p°ihla²ovací údaje stejné, jako admin ú£et, vytvá°ený p°i migraci.
•
V²echny ostatní záznamy by se m¥ly z d·vod· p°ehlednosti a generování ID nacházet aº pod vý²e uvedenými
35
KAPITOLA 6.
TESTY
6.2.2 Unit testy Pro kaºdý model byly napsány jednotkové testy které by m¥ly pokrývat v²echny validace a testovat jak správné, tak i chybné hodnoty. Vzhledem k tomu, ºe modely neobsahují ºádnou dodate£nou funkcionalitu, nebylo nutné testovat nic jiného neº validace a správné ukládání a na£ítání dat. Podrobn¥j²í informace o po£tu jednotkových test· jsou na obrázku 6.1.
Obrázek 6.1: Výstup unit test· (rake test:units)
6.2.3 Funk£ní testy Pro kaºdý controller byly napsány funk£ní testy, které by m¥ly pokrývat v²echny akce controlleru. Pro vybrané akce bylo napsáno více test·, aby byly ozkou²eny v²echny moºné
1
2
problémové situace . V kaºdém testu jsem se snaºil minimalizovat po£et poºadavk· , aby bylo jednodu²²í identi kovat a opravit p°ípadné chyby. Výstup funk£ních test· je znázorn¥n na obrázku 6.2.
Obrázek 6.2: Výstup funk£ních test· (rake test:functionals)
6.2.4 Integra£ní testy Podle p°ípad· uºití ze speci kace bylo vytvo°eno n¥kolik test·, které ov²em naráºely na jeden velký problém a tím byl dynamický r·st a £asté zm¥ny v aplikaci. Testy tak bylo nutno opakovan¥ p°ed¥lávat a proto byl zpo£átku jejich p°ínos mizivý. Teprve koncem ledna, tedy po n¥kolika m¥sících vývoje, byla dokon£ena první verze pln¥ funk£ních test·. Ty pomohly odhalit n¥kolik zásadních chyb. Nejzávaºn¥j²í z nich byla nefunk£ní funkce delete u resour-
3
ces , takºe nefungovalo mazání poloºek z databáze. Odstra¬ování tohoto problému zabralo n¥kolik týdn·. 1 nap°íklad pro home/search existují 3 varianty, které testují poslání prázdného,dlouhého a standardního poºadavku 2 ve v¥t²in¥ test· je jen jeden get/post poºadavek, maximáln¥ jsou t°i 3 jako resources jsou v rails ozna£ovány controllery, které mají metody index, create, destroy, update, edit, new a show (p°ípadn¥ jejich podmnoºinu), slouºící ke správ¥ poloºek v databázi. Více informací naleznete v rails dokumentaci [9]
36
6.2.
IMPLEMENTACE
Pro tvorbu integra£ních test· byl zvolen Selenium framework [10]. Tento framework simuluje interakci uºivatele, jako nap°íklad vepisování hodnot do vstupních polí £i klikání na odkazy, a tím je optimálním nástrojem pro tento typ testování. Jeho modi kací pro ruby
4
aplikace je gem selenium-webdriver , který byl pouºit i v mých testech.
Zpo£átku byly testy psány výhradn¥ za pomoci gemu selenium-webdriver. Toto °e²ení se v²ak ukázalo jako neefektivní, protoºe výsledný kód byl velmi sloºitý a t¥ºko £itelný. Navíc bylo sloºité dohledávat tutoriály a hotová °e²ení, které by mi usnadnili psaní test·. Seleniumwebdriver zkrátka v sou£asné dob¥ je²t¥ nemá v ruby aplikacích takovou úrove¬, aby byl sám o sob¥ n¥jak efektivn¥ pouºitelný. A moºná ani nikdy mít nebude, protoºe existují jiné gemy, které sice vyuºívají jeho funkcionalitu, ale vývojá°i nabízí mnohem p°íjemn¥j²í rozhraní. Jedním z nich je capybara, ke kterému jsem se p°i refactoringu test· (viz kapitola 6.3 - Code coverage) uchýlil i já.
Kon gurace gemu capybara je velice jednoduchá. Sta£í ho pouze nainstalovat, provést
5
require , nastavit preferovaný driver (v p°ípad¥ kucha°ky selenium) a provést include funkcionality Capybara::DSL v rámci t°ídy ActionDispatch::IntegrationTest, ze které v²echny integra£ní testy d¥dí.
6
Ukázka requirementu gemu a kon gurace driveru: require
'capybara / rails '
Capybara . d e f a u l t _ d r i v e r =
: selenium
Ukázka výchozí t°ídy ActionDispatch::IntegrationTest:
class
ActionDispatch : : IntegrationTest
# Make the Capybara DSL available in all integration tests include
end
Capybara : : DSL
K t°íd¥ integra£ních test· byly navíc p°idány funkce na p°ihlá²ení a odhlá²ení uºivatele a také funkce teardown, která po ukon£ení odhlásí uºivatele, pokud je n¥jaký p°ihlá²en. Tato pojistka je zde z d·vodu, ºe pokud test selºe, nedojde jiº k regulérnímu odhlá²ení uºivatele, které je aº na konci testovací funkce a v²echny následující testy by selhaly také, protoºe v sessions prohlíºe£e by z·stal p°ihlá²ený uºivatel, tomu by byla uzp·sobená hlavi£ka stránky a funkce login by nena²la odkaz s titulkem "P°ihlásit se".
Pomocí capybary byly vytvo°eny nové integra£ní testy pro n¥kolik základních use case aplikace, jako p°idávání a mazání recept· £i posílání ºádostí na ingredience. Staré testy, vyuºívající pouze selenium-webdriver, byly smazány. Výstup nových integra£ních test· je vid¥t na obrázku 6.3.
require lze provést jal v test_helperu, tak i f inicializátoru prost°edí 6 celý postup i následné ukázky jsou p°evzaty z dokumentace na domovské stránce gemu capybara [2] 4
5
37
KAPITOLA 6.
TESTY
Obrázek 6.3: Výstup integra£ních test· (rake test:integration)
6.3 Code coverage P°i spu²t¥ní v²ech test· byla také provedena kontrola pokrytí zdrojového kódu (konkrétn¥ % relevantních °ádk·, kterými testy pro²ly).
6.3.1 Popis a kon gurace pouºitého nástroje 7 a poskytuje podrobné
Ke kontrole jsem vyuºil gem SimpleCov, který je snadno pouºitelný
výsledky pr·chodu test· programem. Pro kaºdý zdrojový soubor poskytne nejen procentuální pokrytí relevantních °ádk·, ale také statistiku kaºdého °ádku, kolikrát byl v rámci test· "vyuºit".
SimpleCov také umoº¬uje n¥které zdrojové soubory z výsledk· vy°adit a zbylé seskupit podle ur£itých parametr·. První funkci jsem pouºil k vy°azení testovacích soubor·
8 a kon-
9 gura£ních soubor· a tím vy£istil výsledky od soubor·, které nezávisle na testech budou
mít vºdy code coverage 100%. Zbylé výsledky jsem roz°adil do skupin podle funkce souboru (controllers, models, helpers, mailers, uploaders), navíc jsem p°idal je²t¥ 2 skupiny, které slouºí spí²e jen pro zajímavost a abych vyzkou²el moºnosti seskupování, které SimpleCov poskytuje - Long les
10 a Short les11 .
Ukázka kon gurace nástroje SimpleCov: SimpleCov . s t a r t
do
# odfiltruju testy , aby mi to nekazilo celkovy vysledky a d d _ f i l t e r " test /" # taky vyhodim config - vzdy se projedou cele a d d _ f i l t e r " config /" # zakladni skupiny podle typu souboru sta£í p°idat gem do gem le a zavolat jeho require z test_helperu tyto soubory obsahují v názvu "test/"; SimpleCov je defaultn¥ za°azuje do výsledk·, ale testovací soubory jsou zpracovány vºdy celé, proto by jen zkreslovaly výsledek 9 tyto soubory obsahují v názvu "con g/"; jejich kód je vºdy vykonán p°i spu²t¥ní serveru a jak název napovídá, slouºí pouze ke kon guraci. Neobsahují ºádný funk£ní kód, proto by také pouze zkreslovaly celkový výsledek 10 200 a více °ádk· 11 maximáln¥ 10 °ádk· 7 8
38
6.3.
CODE COVERAGE
" Models " , "app/ models " " Controllers " , "app/ controllers " add_group " Mailers " , "app/ mailers " add_group " Uploaders " , "app/ uploaders " add_group " Helpers " , "app/ helpers " # a jeste neco navic add_group " Long files (200+) " do | s r c _ f i l e | add_group
add_group
s r c _ f i l e . l i n e s . count > 200
end
add_group
" Short files (10 -)"
do
| src_file |
s r c _ f i l e . l i n e s . c o u n t <= 10
end end
6.3.2 První analýza Po první analýze (5. 5. 2013), jsem odhalil n¥kolik závaºných nedostatk·. A£koliv celkové pokrytí 82% se m·ºe zdát jako dobrý výsledek, po p°ihlédnutí k jednotlivým skupinám uº tak dob°e nevypadá. Je totiº lehce zkresleno 100% pokrytím model·, které krom¥ validací neobsahují ºádnou dodate£nou funkcionalitu, a tak jsou vºdy celé zpracovány jiº p°i inicializaci. Z d·vod· moºného roz²í°ení v budoucnu je ale mezi výsledky nechávám. U ostatních skupin muselo být tedy pokrytí niº²í neº celkových 82%. Nejh·°e na tom byly controllery, které vykazovaly code coverage pouhých 76% a bylo tedy jasné, ºe testy musí být je²t¥ dopln¥ny.
Statistika pokrytí jednotlivých skupin je vid¥t v tabulce 6.1, kompletní analýzu naleznete na p°iloºeném CD ve sloºce code_coverage/ rst.
6.3.3 Úpravy test·, druhá analýza Ihned po zji²t¥ní jsem provedl analýzu nepokrytých míst a rozsáhlé úpravy test·, které m¥ly tato místa odstranit. Jednalo se pouze o testy funk£ní a integra£ní, jednotkové testy kontrolovaly pouze validace v modelech, které uº m¥ly 100% pokrytí, a proto z·staly nedot£eny. Za cíl jsem si dal dosáhnout celkového pokrytí alespo¬ 90% s tím ºe ºádný ze soubor· nesmí mít mén¥ neº 80%.
U
funk£ních test·
jsem se zam¥°il zejména na pokrytí v²ech akcí controller· a také
na jejich roz²í°ení o poºadavky na formát JSON. N¥které akce, jako je nap°íklad index v controlleru ingrediencí totiº JSON formát podporují a generování response v tomto formátu nebylo v ºádném z nich pokryto. Také jsem p°idal n¥kolik alternativ jiº existujících test·, které by m¥ly pokrývat v²echny moºné cesty skrz podmínky v controllerech.
Díky tomuto dopln¥ní funk£ních test· stouplo celkové pokrytí kódu na 92% a pouze 3 soubory skon£ily s pokrytím pod 90% (ale ne men²ím neº 80%!). Tím jsem vlastn¥ splnil vyty£ené cíle. Stále ale zbývaly testy integra£ní.
39
KAPITOLA 6.
TESTY
Skupina
První analýza Druhá analýza
V²echny soubory Modely Controllery
81.81%
94.4%
100%
100%
76.07%
97.58%
Mailery
80%
100%
100%
100%
Helpery
83.49%
89.12%
Dlouhé soubory (200+)
84.73%
91.17%
100%
100%
Uploadery
Krátké soubory (10-)
Tabulka 6.1: Výsledky code coverage
Integra£ní testy byly od základu p°ed¥lány (viz kapitola 6.2.4 - Integra£ní testy), protoºe jejich stará verze nejenºe uº nesta£ila dynamickému r·stu aplikace, a tak byla v¥t²ina test· nefunk£ních, ale také byla kv·li ²patn¥ zvolenému zp·sobu implementace velice t¥ºko upravitelná. Nových test· vzniklo sice mén¥ neº bylo p·vodních ale zato se zam¥°ily na d·leºité a komplikované £ásti aplikace, jako nap°íklad posílání ºádosti na ingredience, a pomohly odhalit nové chyby, jako t°eba chyb¥jící funkci, zpracovávající poºadavek na novou ingredienci v controlleru ingrediencí. Krom¥ tohoto p°ínosu také zvedly celkové pokrytí kódu na slu²ných 94%. Detailní rozpis pro jednotlivé skupiny je v tabulce 6.1.
Celkové pokrytí kódu sice stále není stoprocentní, ale aktuální stav, 94%, se dá povaºovat za velice dobrý výsledek. Nepokrytých 6% jsou totiº v p°eváºné v¥t²in¥ funkce, které je²t¥ nejsou v aplikaci pouºity, i kdyº uº jsou z velké £ásti implementovány (jako nap°íklad blokování uºivatel·), nebo r·zná o²et°ení moºných aplika£ních chyb, které jsou ale velmi vzácné a je velmi sloºité je v testech navodit.
6.4 Akcepta£ní testy Jako výstup akcepta£ních test· se dá povaºovat uznání projektu v rámci Bakalá°ské práce.
40
Kapitola 7 Pilotní provoz
7.1 Výb¥r hostingu Ve výb¥ru hostingu pro pilotní aplikaci guroval pouze jeden, ale zato velmi d·leºitý, poºadavek: musí být zdarma. Server·, které nabízejí neplacený rails hosting je opravdu málo, a proto tento poºadavek radikáln¥ zredukoval moºnost výb¥ru. Nakonec jsem ale po dlouhém hledání narazil na dva servery: railshosting.cz, který na subdomén¥ free.railshosting.cz
1
2 nabízí moºnosti základního hostingu zdarma a heroku.com , které funguje na základ¥ ne-
placeného hostingu s moºností dokoupit si nejr·zn¥j²í sluºby, coº ale pro nasazení Kucha°ky nebylo pot°eba.
Vzhledem k tomu, ºe Kucha°ka je £esky lokalizovaná aplikace, byl první volbou £eský hosting, tedy railshosting.cz. Ov²em kv·li rozsáhlým problém·m s nasazením a slabé podpo°e rails gem· jsem musel výb¥r hostingu p°ehodnotit a aplikace nakonec byla nasazena na heroku.com.
Finální adresa pilotní aplikace je:
7.2 Nasazení Nasazení prob¥hlo na obou serverech, zmín¥ných v p°edchozí kapitole, a to za ú£elem zji²t¥ní, který z nich bude výsledné aplikaci vyhovovat více.
K úsp¥²nému nasazení a bezproblémovému chodu aplikace z pohledu uºivatele jsou zapot°ebí dv¥ jednotky - server a PC uºivatele. Tyto dv¥ jednotky spolu komunikují pomocí HTTP protokolu, který je z rodiny TCP/IP protokol·. 1 2
41
KAPITOLA 7.
PILOTNÍ PROVOZ
Na uºivatelském PC je zapot°ebí mít nainstalován jeden z podporovaných webových pro-
3
hlíºe£· . Ten zajistí zasílání poºadavk· na server a správné zobrazení odpov¥dí.
Zatímco na klientském PC byl zapot°ebí pouze nainstalovaný webový prohlíºe£, na serveru je situace o trochu sloºit¥j²í. Musí tam totiº být spu²t¥ny hned dv¥ sluºby. T¥mi jsou aplika£ní a databázový server. Aplika£ní server zaji²´uje p°ijímání poºadavk·, na základ¥ kterých vygeneruje odpov¥¤ ze zdrojových kód· aplikace. B¥hem generování je moºné, ºe bude zapot°ebí získat nebo pozm¥nit n¥jaká data. K tomu slouºí databázová sluºba, která tato data získá z úloºi²t¥ na disku a poskytne je aplikaci nebo je p°ípadn¥ upraví.
Na obrázku 7.1 je znázorn¥n diagram nasazení, který po£ítá s vý²e zmín¥ným scéná°em, tedy se spu²t¥nými aplika£ním a databázovým serverem v rámci jedné jednotky. Je v²ak pouze na poskytovateli hostingu, zda se rozhodne pro databázový server vyuºít sluºby t°etí strany. V tom p°ípad¥ byly pro úsp¥²né nasazení zapot°ebí jednotky t°i (uºivatelské PC, PC aplika£ního serveru a PC, na kterém b¥ºí databázový server).
Obrázek 7.1: Diagram nasazení
3
tyto prohlíºe£e jsou uvedeny mezi nefunk£ními poºadavky
42
7.2.
NASAZENÍ
7.2.1 free.railshosting.cz Jako první prob¥hlo nasazení na £eský railshosting. Celé nasazování probíhalo pomocí
4 a návodu pro deploy5 .
nástroje Capistrano
Návod byl vcelku podrobný, ale n¥které pasáºe, jako nap°íklad propojení repositá°e na GitHubu se serverem pomocí RSA klí£·, odkazovaly na externí dokumentace v angli£tin¥ a uºivateli, který se s danou problematikou setkal poprvé, tak mohly p°ipadat zna£n¥ nep°ehledné.
Po dlouhém boji práv¥ s RSA klí£i £ekalo dal²í nemilé p°ekvapení: na serveru je pouze omezený po£et nainstalovaných gem· a uºivatel nemá moºnost p°idat nový jiným zp·sobem, neº zasláním poºadavku na podporu. Následkem tohoto omezení bylo, ºe p°i spu²t¥ní p°íkazu bundle
install
celá aplikace kv·li chyb¥jícím gem·m spadla. V tuto chvíli jsem opustil server railshosting.cz a zam¥°il se na nasazení na heroku.com, které by takovéto problémy zp·sobovat nem¥lo.
7.2.2 www.heroku.com Vzhledem k tomu, ºe ve²keré návody na serveru jsou v anglickém jazyce, bylo zprvu sloºit¥j²í se v nich orientovat. To je také jeden z d·vod·, pro£ jsem se cht¥l nasazení na zahrani£ní server vyhnout. Ov²em po chvíli studování návod· a dokumentace, kdyº uº jsem se £áste£n¥ zorientoval, jsem zjistil, ºe je zde v²echno vysv¥tleno velice podrobn¥ a p°ehledn¥.
Prvním krokem, který musí kaºdý uºivatel ud¥lat, je staºení heroku aplikace pro p°íkazovou °ádku. Ta obsahuje d·leºité p°íkazy, jako nap°íklad p°ihlá²ení se k Heroku ú£tu £i výpis log·. Poté jsem jiº za£al postupovat podle dokumentace o nazazení pomocí git repositá°e [4]. Pro tento zp·sob nasazení existují 2 moºná r·zná °e²ení: 1. Vytvo°ení nové kopie aplikace, propojené s git repozitá°em. 2. P°idání nové git remote adresy do aktuální kopie aplikace. Rozhodl jsem se pro první variantu. D·vod· bylo n¥kolik, tím nejd·leºit¥j²ím ale bylo odd¥lení nasazené aplikace od vývojové v¥tve a vyhnutí se tak problém·m s klí£i apod.
Samotné nasazení probíhalo pom¥rn¥ dlouhou dobu, protoºe jsem s kaºdou novou verzí odhaloval nové chyby, které hned p°i spu²t¥ní uvád¥ly aplikaci do stavu crashed. Nejd°íve se jednalo o chybnou kon guraci (precompiling assets), poté o neplatné SQL p°íkazy (vzhledem k tomu, ºe development/test a produkce v dob¥ prvního nasazení fungovaly na r·zných typech databáze - postgres a SQLite).
4
5
43
KAPITOLA 7.
PILOTNÍ PROVOZ
Kdyº jsem odstranil v²echny kritické chyby, pustil jsem se do nastavování ActionMaileru. Heroku samo o sob¥ nenabízí moºnost rozesílání email·, ov²em za vyuºití nekterého z nabí-
6 to moºné je. Rozhodl jsem se pro SendGrid7 , protoºe tento add-on nabízí
zených add-on·
i neplacenou verzi, s omezením na 7000 email· m¥sí£n¥, a je doporu£ován na v¥t²in¥ diskuzních fór. Navíc je tento add-on dob°e zdokumentován a proto nebylo nastavení maileru sloºité. [5] Výsledná kon gurace pro produkci vypadá takto: c o n f i g . action_mailer . delivery_method =
: smtp
A c t i o n M a i l e r : : Base . s m t p _ s e t t i n g s = { : address
=>
: port
=>
: a u t h e n t i c a t i o n =>
'smtp . sendgrid .net ' , '587 ' , : plain ,
'SENDGRID_USERNAME ' ] 'SENDGRID_PASSWORD ' ] 'heroku .com ' ,
: user_name
=> ENV[
,
: password
=> ENV[
,
: domain
=>
: e n a b l e _ s t a r t t l s _ a u t o =>
true
}
Po nastavení ActionMaileru byla aplikace p°ipravena k databázové migraci a následnému uvedení do pilotního provozu.
7.3 Pr·b¥h Nasazení do pilotního provozu prob¥hlo na za£átku b°ezna 2013. Ihned po nasazení jsem inzeroval aplikaci kucha°ka na sociální síti FaceBook. Na výzvu, aby aplikaci ozkou²eli a reportovali p°ípadné chyby, reagovalo p°ibliºn¥ 20 osob, z nichº ale pouhých 6 se skute£n¥ registrovalo. V¥t²ina registrovaných navíc za celou dobu pilotního provozu nep°idala jediný recept. Tato £ísla tedy z·stávají za o£ekáváním, protoºe p°ed nasazením jsem po£ítal p°ibliºn¥ s 20 registrovanými a pravideln¥ p°ispívajícími osobami.
Co se tý£e bug reportingu, tak zprávy o chybách jsem od uºivatel· p°ijímal ve v²ech moºných formách, tedy jak e-mailem, tak i p°es zprávy na FB nebo osobní domluvou. Pro
8
pokro£ilé uºivatele zde byla dokonce moºnost zakládat issues p°ímo na GitHubu . Této moºnosti ale nakonec nikdo nevyuºil.
Hlavním obdobím komunikace mezi mnou a aktivními uºivateli byly první dva týdny po nasazení. Na produkci totiº vyvstaly problémy, které se ve vývojovém prost°edí nevyskytovaly a nebylo tak moºné je p°edem odhalit a odstranit. Typickou ukázkou bylo nahrávání obrázk· k receptu pomocí gemu CarrierWave. Samo o sob¥ fungovalo ve vývojovém prost°edí
sluºby t°etích stran 8 , pro zaloºení issue je nutná registrace 6 7
44
7.4.
ZHODNOCENÍ
správn¥, v²echny testy byly úsp¥²né, jenºe CarrierWave ukládá uploadované obrázky na lokální disk a server Heroku tuto funkcionalitu (vcelku logicky) nepodporuje. Bylo tedy nutné
9 a neº se mi jí poda°ilo pln¥ zprovoznit, uplynulo
vyuºít n¥kterou ze sluºeb t°etích stran
n¥kolik týdn·, b¥hem kterých byla moºnost nahrávání obrázk· k receptu do£asn¥ staºena.
Po uplynutí dvou týdn· byly v²echny závaºn¥j²í chyby odstran¥ny a situace se tak zna£n¥ zklidnila. Dostával jsem jen ob£as hlá²ení o n¥kterých minoritních problémech
10 a návrhy na
vylep²ení funk£nosti. Problémy byly postupn¥ odbourávány podle jejich d·leºitosti, návrhy nové funkcionality pov¥t²inou implementovány nebyly, protoºe aplikace stále není v dokonalém stavu a místo zavád¥ní nových funkcí pot°ebuje spí²e odstranit stávájící nedostatky.
V²echny problémy a návrhy byly poctiv¥ evidovány jako issues na GitHubu, takºe je moºné zp¥tn¥ dohledat, jaké úpravy byly na aplikaci Kucha°ka provád¥ny v dob¥ pilotního provozu.
7.4 Zhodnocení V dob¥ psaní tohoto zhodnocení pilotní provoz fungoval p°ibliºn¥ dva m¥síce a nutno °íci, ºe za tuto dobu úpln¥ nenaplnil o£ekávání do n¥j vkládané. A£koliv se díky n¥mu poda°ilo odhalit a opravit v¥t²inu zbývajících aplika£ních chyb, které pro²ly automatickými testy, registrace pouhých ²esti uºivatel·
11 a úzká spolupráce jen s n¥kterými z nich je velkým
zklamáním. P·vodn¥ jsem o£ekával p°ibliºn¥ 20 uºivatel·, kte°í se budou aktivn¥ podílet na chodu a rozvoji aplikace vkládáním a hodnocením recept·. Toto £íslo tedy z·stalo daleko za o£ekáváními a ani po£et recept· se moc nerozr·stal. Do budoucna by to tedy cht¥lo zvolit propracovan¥j²í reklamní kampa¬, zam¥°enou na v¥t²í mnoºství uºivatel·. Tento krok bude nezbytný zejména po nasazení do plného provozu, aby se vytvo°ilo jádro budoucí uºivatelské komunity a Kucha°ka se dostala do pov¥domí.
Celkov¥ se ale dá pilotní provoz, i p°es nenapln¥ná o£ekávání, hodnotit jen pozitivn¥. Vyzkou²el jsem díky n¥mu nasazení aplikace na server, kde by v budoucnu mohla b¥ºet i ostrá verze aplikace. Také do²lo k odstran¥ní v¥t²iny aplika£ních chyb, takºe b¥ºný uºivatel by jiº nem¥l být obt¥ºován chybovými hlá²kami. A v neposlední °ad¥ byl taky na základ¥ návrh· testovací skupiny uºivatel· lehce upraven layout n¥kterých stránek a aplikace se tak stala uºivatelsky p°íjemn¥j²í.
v tomto p°ípad¥ externí upload server minoritními problémy se rozumí nap°íklad p°eklepy v textacích, návrhy na úpravu designu, aby byla aplikace více user-friendly a dal²í problémy podobného charakteru 11 mezi registrované uºivatele není po£ítán administrátorský ú£et, automaticky vytvo°ený p°i migraci databáze 9
10
45
KAPITOLA 7.
PILOTNÍ PROVOZ
46
Kapitola 8 Budoucí práce
A£koliv je jiº Kucha°ka pln¥ funk£ní a pár m¥síc· jiº funguje bez váºn¥j²ích problém· v pilotním provozu, stále existuje spousta moºností, jak ji roz²i°ovat tak, aby se stala konkurenceschopnou v·£i aplikacím, zmi¬ovaným v kapitole 2 a p°ípadn¥ je i zastínila.
Jiº te¤
1 existuje na domovské stránce aplikace na GitHubu2 8 nice-to-have issues, obsa-
hujících návrhy nové funkcionality, kterou by bylo dobré zapracovat do aplikace a tím zvý²it její kvalitu a konkurenceschopnost.
8.1 P°ihla²ování pomocí sociálních sítí Jedním z t¥chto nice-to-have issues s nejv¥t²í prioritou je implementace p°ihla²ování pomocí sociálních sítí. Tento nápad existuje tém¥° od samého po£átku návrhu aplikace ov²em vzhledem k moºným problém·m, které by mohl p°inést, byl odsunut do pozadí, dokud nebudu mít dostatek £asu na jeho podrobnou analýzu, £asový odhad a implementaci.
Samotná implementace tohoto návrhu by totiº mohla zabrat n¥kolik týdn·, protoºe gem aktuáln¥ pouºitý pro autentizaci uºivatel (Sorcery) p°ihla²ování pomocí sociálních sítí nepodporuje. Musel bych tak zváºit vyuºití jiného gemu (nap°íklad OmniAuth) a jím nahradit ve²keré £ásti aplikace, kde je Sorcery vyuºit.
8.2 Mobilní verze aplikace Dal²ím návrhem, který existuje jiº dlouhou dobu, je implementace gra ckého rozhraní aplikace pro mobilní za°ízení. 1 2
stav z 10. 5. 2013
47
KAPITOLA 8.
BUDOUCÍ PRÁCE
Toto roz²í°ení by m¥lo za následek zv¥t²ení cílové skupiny uºivatel· o ty uºivatele, kte°í v dob¥ va°ení nemají p°ístup k po£íta£i. A i uºivatelé, kte°í tento p°ístup mají by si jist¥ p°i²li na své, protoºe na rozdíl od stolního PC si mohou mobilní za°ízení vzít s sebou do kuchyn¥ a tím si u²et°it cestu do jiného pokoje jen proto, aby se podívali, jak recept pokra£uje.
8.3 Video u receptu Posledním nápadem, který by m¥l být implementován p°ednostn¥ je moºnost p°idávání videí k receptu, protoºe nijak nepopí²ete recept lépe, neº názornou ukázkou.
P°idávání videí je moºné pojmout dv¥ma zp·soby. Bu¤ lze nahrávat videa p°ímo na server
3
Kucha°ky a nebo lze pouze vyuºít cizích video-upload server· . Tyto servery ve v¥t²in¥ p°ípad· nabízejí odkazy na nahraná videa, která lze pak pouze vloºit do stránky a tím dané video zobrazit.
Osobn¥ bych se p°iklán¥l ke druhé variant¥ (vyuºití cizích video-upload server·), protoºe by nebylo pot°eba tolik místa na serveru, uºivatel by byl u²et°en duplicitního nahrávání, pokud by se s videem cht¥l pochlubit i jinde neº na Kucha°ce a v neposlední °ed¥ by odpov¥dnost za legálnost obsahu videí nesla t°etí strana, tedy video-upload servery, kde by se videa nacházela.
8.4 Ostatní návrhy roz²í°ení aplikace Existují i dal²í nápady na roz²í°ení, krom¥ vý²e zmín¥ných. Tyto nápady ale nemají tak velkou prioritu, a proto je zde uvedu pouze v bodovém seznamu: 1.
Jednotné lightboxy pro výb¥r:
Pokud by m¥l uºivatel vybírat nap°íklad novou
ingredienci k receptu, zobrazil by se seznam v modálním okn¥ (lichtboxu). Stejné okno by bylo zobrazeno i p°i p°idávání ingrediencí do ltru ledni£ky a dal²ích p°íleºitostech, kdy je pot°eba vybrat n¥jakou ingredienci. 2.
Více jazyk· aplikace:
Roz²í°ení aplikace na více jazykových verzí by sice m¥lo za
následek ohromné zv¥t²ení cílové skupiny uºivatel, ale na druhou stranu by p°ineslo tolik problém· (nap°íklad jedna databáze pro v²echny jazyky), ºe se zatím nevyplatí. 3.
Posílání aplika£ních chyb na email: ist¥ vývojové roz²í°ení, které by slouºilo k odhalování chyb, které uºivatelé nenahlásí.
4.
Null mnoºství ingrediencí u receptu: Zatím je povinnost zadávat mnoºství ingredience v rámci receptu. Ob£as ale sta£í její p°ítomnost, proto by stálo za to povolit NULL hodnotu.
5.
Seznamy recept· na horní li²t¥:
Zatím lze z horní li²ty p°ímo p°ejít pouze na
nejnov¥j²í recepty. Bylo by dobré z tohoto odkazu ud¥lat dropdown menu (jako nap°íklad menu Seznamy u admina), kde by byly minimáln¥ nejnov¥j²í a nejlépe hodnocené recepty. 3
servery pro nahrávání videí jsou nap°íklad <www.youtube.com> nebo £eský <www.stream.cz>
48
Kapitola 9 Záv¥r
Cílem této práce bylo analyzovat, navrhnout, vytvo°it a otestovat webovou aplikaci na platform¥ Ruby on Rails, která bude slouºit k evidenci a správ¥ recept·, a poté ji nasadit do pilotního provozu.
Postupn¥ jsem pro²el v²echny vý²e uvedené kroky a výstupem je pln¥ funk£ní aplikace, spl¬ující výchozí poºadavky a p°ipravená k nasazení do ostrého provozu. Zdrojové kódy aplikace je moºné nalézt p°ímo na p°iloºeném CD nebo na adrese <www.github.com/trptom/
kucharka>,
pilotní aplikace se pak nachází na adrese .
Aplikaci je moºné dále roz²i°ovat, jiº na konci pilotního provozu je na githubu evidováno 8 nice-to-have ticket·, které by si jist¥ zaslouºily budoucí implementaci.
B¥hem implementa£ní £ásti jsem byl nucen nau£it se od základu jazyk Ruby a na n¥m postavený framework Ruby on Rails, coº mi zabralo n¥kolik týdn·, b¥hem kterých jsem musel odloºit nejen samotný vývoj, ale i n¥které analytické £ásti, které vyºadovaly znalost programovacího jazyka. Kdyº jsem ale Rails ovládl, u²et°il mi díky své architektu°e tento framework spoustu £asu a ve výsledku se dá °íci, ºe psaní kódu mi díky n¥mu trvalo krat²í dobu, neº kdybych pouºil jiný skriptovací jazyk, nap°íklad PHP.
Vyzkou²el jsem si také psaní jednotkových, funk£ních a integra£ních test·, které jsem do té doby p°íli² nevyuºíval. D·leºitou £ástí testovací fáze bylo také nasazení aplikace do pilotního provozu, který sice úpln¥ nesplnil p·vodní o£ekávání, zejména co se vytíºenosti aplikace tý£e, ale i p°esto m¥l zásadní podíl na stavu, ve kterém se aplikace te¤ nachází - bez zásadních chyb, které by uºivatele omezovaly p°i základních £innostech a s atraktivním designem, který byl podle analýzy jedním ze základních stavebních kamen· celého projektu.
49
KAPITOLA 9.
ZÁV
R
50
Literatura
[1]
Cloudinary - Documentation - Ruby On Rails integration [online]. [cit. 15. 5. 2013]. Návod na uploading obrázk·.
Dostupné z:
rails_integration#direct_upload>. [2]
jnicklas/capybara · GitHub [online]. [cit. 10. 5. 2013]. Domovské stránky gemu capybara v£etn¥ tutoriál·. Dostupné z: .
[3]
Cloudinary | Heroku Dev Center
[online]. [cit. 15. 5. 2013]. Návod na uploading ob-
rázk· pomocí cloudinary add-onu.
articles/cloudinary>. [4]
Dostupné z:
Deploying with Git | Heroku Dev Center
[online]. [cit. 23. 2. 2013]. Návod na nasa-
zení aplikace na server Heroku.com pomocí GITu. Dostupné z:
heroku.com/articles/git>. [5]
SendGrid | Heroku Dev Center [online]. [cit. 23. 2. 2013]. Návod na posílání email· pomocí add-onu SendGrid.
sendgrid>. [6]
Dostupné z:
Ruby on Rails Guides: Active Record Query Interface kumentace rozhraní ActiveRecord v Ruby on Rails.
rubyonrails.org/active_record_querying.html>. [7]
[online]. [cit. 15. 10. 2012]. DoDostupné z:
Ruby on Rails Guides: Getting Started with Rails [online]. [cit. 15. 10. 2012].
Dostupné
z: .
[8]
Ruby on Rails Guides: A Guide to Testing Rails Applications [online]. [cit. 22. 1. 2013].
Dokumentace rozhraní ActiveRecord v Ruby on Rails. Dostupné z:
rubyonrails.org/testing.html>. [9]
resources (ActionController::Resources) - APIdock sources
v
Rails.
Dostupné
Resources/resources>. [10]
z:
[online]. [cit. 2. 5. 2013]. Popis re-
Selenium - Web Browser Automation [online]. [cit. 2. 5. 2013]. Domovská stránka sele-
nium frameworku. Dostupné z: . [11]
Apetitonline.cz
[online]. [cit. 30. 11. 2012]. Jeden ze t°í server·, které byly podrobeny
zkoumání p°i sb¥r· poºadavk·. Dostupné z: .
51
LITERATURA
[12]
Recepty.cz [online]. [cit. 30. 11. 2012]. Dostupné z: .
[13]
Vareni.cz [online]. [cit. 30. 11. 2012]. Jeden ze t°í server·, které byly podrobeny zkoumání p°i sb¥r· poºadavk·. Dostupné z: .
[14]
ízení SW projekt· [online]. [cit. 20. 4. 2013]. Dostupné z: .
[15] Experti komunity jQuery.
jQuery Kucha°ka programátora.
: Computer Press, a.s.,
2010. [16] jQuery Foundation.
jQuery API Documentation [online]. [cit. 15. 10. 2012]. Online do-
kumentace frameworku jQuery. Dostupné z: . [17]
Wiki projektu Kucha°ka v rámci SI2 [online]. [cit. 15. 5. 2013]. https://github.com/trptom/Kucharka/wiki.
52
P°íloha A Seznam pouºitých zkratek
AJAX Asynchronous JavaScript and XML CSS
Cascading Style Sheets
DB
Databáze
FB
Facebook
HTML HyperText Markup Language ID
Identi ka£ní £íslo
JSON JavaScript Object Notation MVC
Model-view-controller
OOP
Objektov¥ orientované programování
ORM
Objektov¥ rela£ní mapování
RoR
Ruby on Rails
SW
Software
53
PÍLOHA A.
SEZNAM POUITÝCH ZKRATEK
54
P°íloha B Obsah p°iloºeného CD
Sloºka nebo soubor
/application /code_coverage /code_coverage/first /code_coverage/second /documents /images /images/design /images/diagrams /images/similar_applications /images/test_results /src BP.pdf readme.txt
popis Zdrojové kódy aplikace. Výsledky code coverage analýzy. Výsledky první analýzy. Výsledky druhé analýzy (po refactoringu test·). Dokumenty k aplikaci (návrh, analýza a dal²í). Obrázky. Návrhy designu. Diagramy, které nejsou uvedeny v dokumentech. Náhledy podobných aplikací z re²er²e. Výsledky test·. Zdrojové texty této práce. Tato práce. Soubor, obsahující informace o CD.
55
PÍLOHA B.
OBSAH PILOENÉHO CD
56
P°íloha C íslovaný seznam funk£ních a nefunk£ních poºadavk·
C.1 Funk£ní poºadavky 1. Uºivatelé (a) Aplikace bude rozli²ovat n¥kolik druh· uºivatel·:
•
Root M·ºe provád¥t ve²keré akce (nelze je p°idávat ani odebírat). Tento ú£et je vytvo°en p°i instalaci systému.
•
P°ihlá²ený uºivatel M·ºe procházet p°idávat, komentovat a hodnotit recepty, p°ípadn¥ dal²í £innosti, k nimº dostane oprávn¥ní, tím se pro ú£ely dokumentace stává administrátorem.
•
Nep°ihlá²ený uºivatel M·ºe pouze procházet recepty.
(b) Root/uºivatel s právem na úpravu pravomocí m·ºe p°idávat i odebírat uºivatel·m ur£ité pravomoci:
• • •
Administrátorská práva. Moºnost komentovat a hodnotit recepty. P°ístup k aplikaci.
2. Recepty (a) Moºnost p°idávat recepty mají v²ichni uºivatelé, vyjma neregistrovaných a uºivatel· s banem. (b) Kaºdý recept se bude skládat z následujících £ástí:
• • • • •
lánek (nepovinné). Náro£nost receptu (povinné). as pot°ebný k p°íprav¥ (povinné). Fotogra e (nepovinné). Samotný pracovní postup (povinné).
57
PÍLOHA C.
•
ÍSLOVANÝ SEZNAM FUNKNÍCH A NEFUNKNÍCH POADAVK
M·ºe obsahovat odkazy na podpostupy (nap°. vep°ové se zelím a knedlíkem m·ºe obsahovat odkaz na recept na houskový knedlík).
(c) Kaºdý recept bude obsahovat ingredience, ze kterých se skládá.
•
Kaºdá ingredience bude mít koe cient d·leºitosti pro p°ípravu receptu, aby bylo moºné pomocí funkce Ledni£ka efektivn¥ vyhledávat moºné recepty.
•
U kaºdé ingredience bude uvedeno mnoºství v odpovídajících jednotkách, které je pot°ebné pro p°ípravu daného receptu.
(d) Recepty lze hodnotit. (e) Recepty lze komentovat. 3. Ingredience (a) Seznam ingrediencí udrºují administráto°i (aby nedocházelo k duplicitám apod.). (b) Uºivatelé mohou podávat ºádosti na p°idání ingredience. (c) Kaºdá ingredience obsahuje:
• •
Název. M¥rnou jednotku.
4. Komentá°e 5. Hodnocení (a) Hodnotí se stupnicí 1-5, kde 5=nejlep²í. 6. Hledání (a) Standardní
•
P·jde vyhledávat podle nadpisu nebo obsahu.
(b) Ledni£ka
•
Uºivatel zadá suroviny a podle nich se vy ltrují dostupné recepty. Recepty budou °azeny podle dostupnosti sestupn¥.
C.2 Nefunk£ní poºadavky 1. Vyvíjeno na platform¥ Ruby on Rails. 2. Podpora pro hlavní webové prohlíºe£e: (a) Internet Explorer. (b) Google Chrome. (c) Mozilla Firefox. (d) Opera. (e) Safari. 3. P°íjemné a intuitivní webové rozhraní.
58
