Webová aplikace pro fotbalový klub

České vysoké učení technické Fakulta elektrotechnická Katedra počítačové grafiky a interakce

Bakalářská práce

Webová aplikace pro fotbalový klub Václav Surovec

Vedoucí práce: Ing. Vojtěch Jirkovský

Studijní program: Softwarové technologie a management Obor: Web a multimédia květen 2011

Poděkování Rád bych poděkoval svému vedoucímu bakalářské práce panu Ing. Vojtěchu Jirkovskému za rady a připomínky, které mi dával při psaní této bakalářské práce. Také bych rád touto cestou poděkoval i mojí rodině, která mě vždy podporovala a dodávala mi víru a odvahu pro dokončení této práce.

Prohlášení Prohlašuji, že jsem svou bakalářskou 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 Praze dne 27. května 2011

……………………………….....……

Abstract The goal of the work is to create an application for an administration of non-professional football club. This application will provide the list of following matches and let the players of the club express their interest in playing that match. Also in this application, you will be able to administrate a part of the system, which will serve as a presentation for the public. This work includes the analysis of requirements, design of application and final result presented as a system implementation.

Abstrakt Cílem práce je vytvořit aplikaci pro správu amatérského fotbalového klubu. Tato aplikace bude poskytovat přehled o chystaných zápasech a umožní hráčům nahlásit se na konkrétní zápas. Aplikace dále bude umožňovat spravovat část systému, která bude sloužit jako prezentace pro veřejnost. Práce se zabývá analýzou požadavků, návrhem aplikace a výsledným řešením v podobě implementace této aplikace.

Obsah 1 Úvod ............................................................................................................................... 1 2 Analýza........................................................................................................................... 4 2.1 Obecné info ............................................................................................................. 4 2.2 Současný stav .......................................................................................................... 5 2.3 Důvody pro vytvoření aplikace ............................................................................... 6 2.4 Očekávaný přínos aplikace...................................................................................... 8 2.5 Funkční požadavky aplikace ................................................................................... 9 3 Návrh aplikace.............................................................................................................. 11 3.1 Databázový model................................................................................................. 11 3.1.1 Tabulky Hrac, HracuvProfil a ClenTymu ...................................................... 11 3.1.2 Tabulky Zapas a JinaAkce ............................................................................. 13 3.1.3 Ostatní tabulky ............................................................................................... 14 3.2 Rozložení položek v menu .................................................................................... 15 3.3 Layout.................................................................................................................... 17 3.4 Redakční systém.................................................................................................... 17 3.5 Uživatelské role..................................................................................................... 18 3.5.1 Administrátor ................................................................................................. 18 3.5.2 Stálý hráč s určitými administrátorskými právy ............................................ 19 3.5.3 Ostatní uživatelské role .................................................................................. 19 4 Implementace ............................................................................................................... 21 4.1 Technologie ........................................................................................................... 21 4.1.1 Představení použitých technologií ................................................................. 21 4.1.2 Důvody pro použití Smarty ............................................................................ 22 4.1.3 Důvody pro nepoužití CMS ........................................................................... 22 4.2 Validace formulářových dat .................................................................................. 23 4.3 Bezpečnost ............................................................................................................ 24 4.3.1 Ukládání a změna hesel.................................................................................. 24 4.3.2 Ochrana proti XSS ......................................................................................... 25 4.3.3 Znovuodeslání formuláře ............................................................................... 26 4.3.4 Uložení profilové fotky .................................................................................. 26

4.4 Import dat ....................................................................................................................... 27 4.5 Tvorba článků a novinek ................................................................................................ 28 4.6 Upozorňovací systém ..................................................................................................... 28 4.6.1 Důvody pro zavedení upozorňovacího systému...................................................... 28 4.6.2 Způsoby upozorňování ............................................................................................ 29 4.6.2.1 SMS.................................................................................................................. 30 4.6.2.2 E-mail ............................................................................................................... 30 4.6.2.3 Cron .................................................................................................................. 31 4.7 Hlášenkový systém......................................................................................................... 31 4.8 PHP třídy ........................................................................................................................ 32 4.9 Snadná přenositelnost a změna obsahu .......................................................................... 32 4.10 Práce s databází ............................................................................................................ 33 4.11 Další pomoc od jQuery ................................................................................................ 33 4.12 Vyúčtování ................................................................................................................... 34 4.13 Dotahování hlášenek .................................................................................................... 35 4.14 Výsledná aplikace ........................................................................................................ 36 5 Testování ............................................................................................................................... 38 5.1 Unit testování ................................................................................................................. 38 5.2 Uživatelské testování...................................................................................................... 38 5.2.1 Uživatel č.1.............................................................................................................. 39 5.2.2 Uživatel č.2.............................................................................................................. 40 6 Závěr...................................................................................................................................... 43 Seznam použité literatury......................................................................................................... 45 Seznam použitého softwaru ..................................................................................................... 47 Seznam použitých zkratek........................................................................................................ 50 Struktura přiloženého CD......................................................................................................... 52 Přílohy ...................................................................................................................................... 54 Příloha 1 – Levá část databázového modelu ........................................................................ 54 Příloha 2 – Pravá část databázového modelu ....................................................................... 55 Příloha 3 – Ukázka aplikace................................................................................................. 56

Seznam obrázků Obr. č. 1 – Schéma rozložení jednotlivých položek v rolovacím menu................................... 15 Obr. č. 2 – Levá část schématu databázového modelu............................................................. 54 Obr. č. 3 – Pravá část schématu databázového modelu............................................................ 55 Obr. č. 4 – Ukázka aplikace ..................................................................................................... 56

1 Úvod Kdo mě zná, není překvapen volbou zrovna tohoto tématu. Fotbal je už odmala můj život, moje velká vášeň. Nikdy jsem nebyl dobrým fotbalistou, ani jsem nikdy nehrál za žádný tým, ale kdykoliv jsem měl u sebe balón, byl jsem štěstím bez sebe. Proto založit si vlastní tým, to byl něco jako splněný sen. I z tohoto důvodu bylo spojení mojí největší radosti se zatím nejdůležitějším samostatným studijním projektem, jakým bakalářská práce bezesporu je, jasnou volbou. A tvorba internetových stránek? Internet doma jsem měl z mojí třídy ještě na základní škole jako jeden z prvních, svoje vlastní internetové stránky jako ten vůbec první. A i když jsem během dalších let nevynikal zdaleka tolik, jako dřív, nepochyboval jsem, že jednou budu vytvářet webové stránky. Na konci léta roku 2009 jsme s kamarády a bývalými spolužáky z gymnázia doopravdy založili vlastní amatérský fotbalový klub (s názvem High Society), který jsme přihlásili do PKFL, tedy Pražské klubové fotbalové ligy. Vstup do této ligy ale byl „upečen“ takřka na poslední chvíli, proto jsme si webové stránky museli obstarat odkoupením jiných, abychom mohli, byť provizorně, začít ihned fungovat. Čas na vytvoření vlastních stránek klubu tak přišel až nyní. V době, kdy už za sebou mám téměř dva roky ve vedení klubu jako kapitán, mohu výborně zúročit zkušenosti, které jsem za tu dobu nabyl. Prakticky denně mluvím s lidmi kolem týmu, poslouchám trpělivě jejich dotazy a vím, kde tým pálí nejvíce bota. A jelikož jsem zatím v soutěži nechyběl ani jedno utkání, znám dopodrobna potřeby a požadavky klubu, čehož bych rád využil i ve své bakalářské práci při tvorbě webové aplikace. Krom toho, pokud vytvořím takovou aplikaci úplně od základů, naučím se příští takovou aplikaci vytvořit už mnohem rychleji. Navíc si dobře osvojím základní technologie jako HTML, CSS a PHP, bez kterých se snad žádná současná dynamická webová aplikace neobejde, což určitě nebude na škodu. Chtěl bych, aby hráči byli

1

s aplikací po její funkční stránce spokojeni, byla jim ku prospěchu a nemuseli se za ni stydět. Výborným oceněním moji práce by bylo, kdyby aplikace, kterou vytvořím, po jejím dokončení opravdu fungovala v provozu, hráči ji hojně využívali a třeba si i zapamatovali její url, což mnohým z našich hráčů dělá stále problémy… Bohužel počítám, že funkcionalit, které by se v aplikaci daly udělat, je nespočet, a protože krom bakalářské práce mám i další studijní povinnosti, nemyslím si, že bych aplikaci dokončil celou v podobě, jakou si představuji. Pokud ale bude fungovat alespoň nějaký prototyp, dobře navržený a připravený dále na něj navazovat a rozšiřovat ho, budu s výsledkem spokojen. Vždyť špatně postavená a rozmyšlená aplikace, jejíž vývoj a rozšiřování by skončilo s koncem mojí bakalářské práce, by nebyla dobrá aplikace. Určitě plánuji aplikaci, ať už jí odevzdám v jakékoliv fázi, ve volném čase v budoucnu dokončit, aby třeba před novou sezónou v září už mohla být vystavena plnému zatížení. Rád bych také, aby moje aplikace nebyla nějakou uzavřenou aplikací, která se vyhýbá používání různých add-ons či pluginů. Soudím, že pokud už někdo něco vytvoří a je to dobré a k užitku, měla by se daná součást používat. Jak se říká, neměli bychom vyrábět kolo. Navíc určitě i vy jste mnohokrát narazili na web, který byl plný užitečných „vychytávek“ a říkali jste si, jaká je to škoda, že je zrovna nemáte kde využít. Určitě se tedy tomu nebráním, pokud to bude mít nějaký smysl pro moji aplikaci a zároveň pokud nedojde k porušení licenčních práv. Také to může být hezká ukázka toho, jak takové pluginy využít v praxi - někde, kde se budou opravdu vyjímat. Studium na elektrofakultě bylo dlouhé a náročné, ne však nezajímavé, a během těch let jsem se v předmětech naučil spoustu věcí a začal pracovat s různým softwarem. Budu se snažit co nejvíce těchto nabytých znalostí použít, aby bylo nejen zřejmé, že jsem na této škole doopravdy studoval, ale že tyto vědomosti umím použít v praxi.

2

3

2 Analýza 2.1 Obecné info Myslím, že na úvod do analýzy aplikace je dobré ozřejmit, jak takový amatérský fotbalový klub, jakým High Society je, vůbec funguje a co je potřeba pro jeho zdárné působení v soutěžích. Bez znalosti těchto souvislostí nemusejí být další kapitoly tak srozumitelné a snadné je pochopit. Tak tedy, tým High Society hraje jako hlavní soutěž PKFL. Ta je oproti možná známější Hanspaulské lize společná i rozdílná v několika věcech. V obou ligách se hraje se malých hřištích v pěti hráčích v poli plus brankář, dvakrát třicet minut, střídání probíhá hokejově, během hry. Hřiště si tým v PKFL zajišťuje každý sám, povinností pouze je, aby hřiště mělo krom určitých rozměrů také umělý povrch (a tedy ne např. škváru apod.). Rozpočet týmu tedy záleží na tom, kolik chce onen tým za dané hřiště vynaložit finančních prostředků. Také startovné do soutěže je výrazně nižší, což ale souvisí s výše zmíněným faktem, jelikož v Hanspaulské lize hřiště zajišťuje za vstupní poplatek přímo vedení soutěže. Jako u konkurence, tak i zde musejí pravidelně jednotlivé týmy vysílat své rozhodčí na jiná utkání, zpravidla jednou za čtrnáct dnů. Když tak neučiní, stihne je bodový odpočet, ne však jako v Hanspaulské lize, trest finanční. Pokud se prohřešky opakují, dojde k vyloučení ze soutěže. I proto je důležité, aby byl tým spolehlivě veden a dobře organizován, což mnohdy jde jen díky usilovné a dobrovolné práci vedení mužstva. Stačí totiž jedna chyba a celoroční práce na hřišti i mimo něj může přijít vniveč. Člověk, který se v týmu stará o finance, v průběhu soutěže pravidelně vybírá drobné finanční částky na pokrytí výdajů, tedy na zajištění hřiště, výbavy, balónů apod. Tým má také vlastní pokutový systém pro dodržení disciplíny uvnitř mužstva. Pokud hráč některé pravidlo poruší, musí zaplatit určitou částku, která jde do společného

4

banku. Bank slouží na ostatní výdaje mužstva, a co zbude, použije se na posezónní rozlučku. Mezi nejčastější prohřešky patří pozdní příchod na sraz týmu a nevyplnění hlášenky (o tom později). Také se vybírají peníze jako tzv. zápisné – za první gól v sezóně, za žlutou/červenou kartu, za zapomenutý dres, za zvolení Hráčem zápasu apod. Samotní hráči v PKFL nemusejí mít, jako např. v profesionálních nebo jiných amatérských ligách, žádné papírové či jiné registrační průkazy. Stačí jen, aby hráčovo jméno bylo zasláno e-mailem dostatečně dopředu před zápasem vedoucímu soutěže PKFL. Jediným omezením je tedy jen celkový počet hráčů zapsaných na soupisce, který činí 25 hráčů. V praxi ale rozhodčí před zápasem totožnost hráčů nekontrolují, proto pokud je jeden či druhý tým v personální nouzi a povolá do svých řad nezaregistrovaného hráče, je to sice unfair hra, ale většina týmu to neřeší. Krom hlavní soutěže PKFL tým hraje mimo hlavní sezónu i různé přípravné či přátelské zápasy, kde sice bývá hráčská účast v našem týmu nižší, pořád ale jde o přípravu na sezónu a o reprezentaci klubu, tudíž ani v tuto dobu si já, ani zbytek vedení týmu neodpočine. Do toho pravidelné tréninky a další, většinou akce společenského rázu. To všechno se musí zajistit ke spokojenosti všech. Co se týče dobré organizace týmu - ta se v dnešní době již rozhodně neobejde bez vzájemné komunikace mezi hráči, kterou by krom dalších věcí měly zajišťovat právě webové stránky týmu. O tom i dalším budu mluvit v následujících podkapitolách, k jejichž vytvoření jsem měl jako inspiraci znalosti nabyté v předmětu „Úvod do softwarového inženýrství“ (s kódem Y36SIN).

2.2 Současný stav V současné

době

má

tým

svoje

stránky

umístěné

na

subdoméně

highsociety.tagomago.cz, což není příliš reprezentativní vyjádření stavu věci. Na hlavní doméně

tagomago.cz

totiž

sídlí

web

pražského

florbalového

(!)

týmu

„FBC Tago Mago“, za jehož rezervní tým hraje i jeden z hráčů našeho týmu. I proto právě toto spojení. Aktuální, relativně prostě vypadající web, umožňuje v rámci redakčního systému vcelku povrchní správu hráčů, zápasů a článků.

5

Po zaregistrování hráče jsou adminem stránek hráči přidělena práva (admin/hráč). Administrátor (samozřejmě po přihlášení) může vstupovat do redakčního systému a přidělovat tak práva hráčům, vypisovat nové zápasy a administrovat zápasy původní, to samé platí i u psaní nových článků. Administrátory jsou lidé z vedení týmu, tedy já jako kapitán a dva moji zástupci. Zbytek týmu, v podobě ostatních hráčů jakožto běžných uživatelů, i admini webu, se dále mohou vyjadřovat k průběhu sezóny i dalším záležitostem týkajících se týmu v jednoduchém fóru. Hlavní funkčností webu je však možnost dát najevo svůj úmysl přijít a hrát v adminem vypsaném utkání, tzv. vyplnit hlášenku (ano/ne/nevyplněna). Tato funkce je důležitá hlavně pro vedení týmu, které musí zajistit, aby se na zápas dostavilo dostatečné množství, v případě těžkého soupeře i kvalitních hráčů, aby se zápas z organizačního pohledu podařil. Mají tak šanci vcelku pohodlně monitorovat situaci před zápasem a v případě nouze kontaktovat (např. na mobil) některého z externích hráčů připravených pomoci. Tohoto nahlašování se zúčastňují všichni zaregistrovaní a schválení uživatelé, bez výjimky. Ti mají možnost kdykoliv před zápasem svoji hlášenku změnit a uvést i důvod, proč se rozhodli přijít/nepřijít. Pokud chce hráč vědět, kolik peněz aktuálně dluží, musí se na konkrétní částku zeptat přímo mě jako kapitána, já si najdu jeho jméno v excelovské tabulce a částku mu řeknu. Protože na stránkách neexistuje žádný účetní systém, celkové vyúčtování musím v souboru nahrávat přes FTP na server, aby v případě, kdy nejsem k dispozici, si daný hráč mohl dlužnou částku zjistit sám. Výhodou současného stavu je to, že stránky jsou velmi jednoduché a měl by se v nich každý vyznat. Plusem je i to, že za roční provoz současného „řešení“ nemusíme vlastníkovi domény, tedy týmu Tago Mago, nic platit. Pouze na začátku působení týmu byl uhrazen jednorázový poplatek za spuštění a provoz webu. Nevýhody tohoto řešení proberu nyní v další podkapitole.

2.3 Důvody pro vytvoření aplikace Důvody, proč jsem se rozhodl pro vytvoření této aplikace, úzce souvisejí s nevýhodami současného stavu webové prezentace týmu. Hlavním důvodem, který už jsem zmínil v předchozí podkapitole, je samotné nevlastnění hostingu, na kterém se web nachází.

6

To znemožňuje jednak jakoukoliv změnu v podobě či funkčnosti aplikace, jednak i z pohledu reprezentativního či vyhledávacího není příliš vhodné mít stránky, týkající se fotbalu, pod florbalem. Byť nám byl přístup do databáze zajištěn, celkově je ale jakýkoliv vlastní vývoj a možnost ovlivnit podobu aplikace nemožný. Veškerá funkčnost webu se točí právě kolem již zmíněných hlášenek. Jedním z hlavních kamenů úrazu je absence více uživatelských rolí. V současné chvíli jsou na stránkách zaregistrováni jen ti hráči, kteří se pravidelně nahlašují a zúčastňují se zápasů, tudíž jen ti se dostanou k informacím týkajících se týmu (např. kdy se hrajou zápasy apod.). V průběhu času, co tým vedu, se objevilo mnoho situací, kdy se, hlavně externí hráči, chtěli k těmto informacím dostat a být tak v kontaktu s týmem, zároveň se ale nechtěli pravidelně nahlašovat a chodit na zápasy, tudíž jejich vypisování v hlášenkách nemělo smysl. Navíc, jak bude popsáno i později, za každé nenahlášení se k zápasu se platí pokuta, i proto tito hráči byli vždy po určité „zkušební“ době, kdy se následně přestali nahlašovat, z databáze vymazáni. Už jenom kvůli těmto důvodům stojí za to vybudovat web nový. Navíc, v případě, že by se i našli nějací fanoušci týmu (byť jich zatím moc není), i oni by se určitě rádi dozvěděli, kde a kam se mohou přijít na své hrdiny podívat. I proto je dobré mít více rolí pro větší variabilitu. A s vlastním prostorem stoupají i možnosti nového webu týmu. Vlastní design stránek, logika, funkce, jako např. profily hráčů, statistiky, galerie ze zápasů, účtovací systém, prostě možnost mít na stránkách vše, co ke každému správnému týmu patří, jsou důvody, proč takovou aplikaci vytvořit. Bohužel (nebo bohudík), většina ostatních týmů jak v PKFL, nebo i v jiných ligách, takové či podobné stránky buď vůbec nemá, nebo je jejich funkčnost na dost chabé úrovni, někdy i dokonce sotva srovnatelné s naší současnou verzí. Tyto týmy na to pak zcela jistě doplácí a absence kvalitního a propracovaného webu se odráží v bodových trestech a nedobré atmosféře uvnitř mužstva. I proto, pokud dostatečně prozkoumám tuto sféru a budu dopodrobna znát onu problematiku, může z toho vzejít i slušný marketingový potenciál do budoucna, což je také zcela jistě nezanedbatelná stránka věci. I v následující kapitole proberu další pozitivní aspekty, které nové stránky mohou týmu přinést.

7

2.4 Očekávaný přínos aplikace Vedení a management takového, byť malého amatérského týmu, pořád bere spoustu volného času, jehož větší část by tato aplikace měla ušetřit. V případě totiž, že se některý hráč opomene nahlásit, nastává situace, která se stala už jakýmsi koloritem mého téměř dvouletého působení u týmu. V takovou chvíli je potřeba buď toho hráče kontaktovat (po mailu, Facebooku, na mobil apod.) a připomenout mu, příp. se ho zeptat, zda hodlá na zápas dorazit, či nikoliv. Pokud ne, nezbývá, než se obrátit se stejným dotazem na externí hráče týmu, zda by týmu nepomohli. Tito hráči jsou zapsáni i na soupisce týmu na oficiálních stránkách soutěže, mají i (většinou) vlastní dres s číslem, avšak jsou po většinu času vytíženi buď v jiných týmech (např. ve velkém fotbale) nebo v práci. Takových hráčů je ale vícero, tudíž šance, že někdo z nich bude moci zaskočit, je vysoká. V případě, že „vypadne“ brankář, citlivé místo každého mužstva, je práce dvakrát tak náročná. Rozlišení takových hráčů pomocí uživatelských rolí spolu s novou webovou aplikací nám umožní čas strávený s mobilem u ucha či rukou u klávesnice doufejme výrazně zkrátit. Dopomůže nám k tomu vlastní systém upozorňování, který popíšu později v jiných kapitolách. Celkově vzato, pokud budou stránky atraktivní, se všemi potřebnými informacemi, které hráč potřebuje, na jednom místě, pokud bude mít proč se na stránky vracet, tak pravděpodobnost, že bude vyplňovat hlášenky a bude aktivní ve fóru, bude větší a vedení týmu tak ubude práce. Atraktivní souboje v tabulce střelců, v celkové tabulce pořadí, kdo se stal Hvězdou zápasu, reporty z utkání, jasně a zřetelně viditelné veškeré důležité informace ihned po ruce – to a další věci jsou zárukou větší návštěvnosti stránek, která jak doufám, oživí i chuť zajímat se o tým. I téměř po dvou letech se totiž najdou tací, co nejsou schopni se jednou za ten týden nahlásit na zápas, odpovědět včas na dotaz apod. Také obstarávání lidí na pískání v rámci týmu zabírá spoustu času. Informace o něm se vyskytují opět na oficiálních stránkách, a když jde takový člověk jednou, dvakrát za sezónu rozhodcovat jiný zápas, velmi rychle zapomene, kde se taková informace nachází. Na mně pak je, abych všechno ostatním hráčům připomínal

8

a dovysvětloval. Pokud tyto informace již budou na našich stránkách, s časem zápasu a třeba i mapou hřiště, je méně pravděpodobné, že se stane nějaký renonc. I co se týče financování a vybírání peněz od hráčů, není to mnohdy jednoduché. Jelikož jakákoliv editace na současně fungujícím webu je z výše popsaných důvodů nemožná, veškeré pokuty či poplatky jsou zaznamenávány do dvou excelovských tabulek, jenž jedna z nich slouží na poplatky za hřiště, druhá na pokuty. Hráčům dělal (a bohužel stále dělá) velký problém se stáhnutím takového souboru a sečtením dvou cifer. Neustálé dotazy před či po zápase na toto téma mě už přiváděly doslova k šílenství. I proto jsem přichystal řešení, které bude ku prospěchu oběma stranám. Jak konkrétně hodlám dosáhnout zlepšení situace na těchto úrovních, poodhalí další kapitola zabývající se návrhem aplikace. Nyní však ještě shrnutí, jaké všechny funkce by aplikace měla pokrýt.

2.5 Funkční požadavky aplikace Nyní ve stručnosti představím v bodech, jaké hlavní funkčnosti by měla webová aplikace zcela jistě obsahovat:
administrace zápasů (vložení, editace, mazání) primárně s rozlišením druhu utkání (mistrovské, přípravné utkání či přátelské utkání)…


…s tím související administrace výsledků a zápisů z utkání,




administrace hráčů (přidělení práv, mazání),




registrace nových hráčů a editace zadaných údajů,




prezentace osobních statistik hráčů (počet zápasů, gólů apod.),




prezentace chystaných i odehraných zápasů týmu a jeho vždy aktuální pořadí v tabulce,




nahlašování na zápasy,




možnost okamžité zveřejnění aktuální dlužné částky,




administrace článků, reportů z utkání (vložení, editace, mazání),




upozorňovací systém,




zajištění komunikace mezi hráči (fórum apod.).

9

10

3 Návrh aplikace 3.1 Databázový model Klíčem k celému návrhu aplikace je návrh samotné databáze – místa uložení našich dat. Pro grafický návrh, ze kterého jsem následně vygeneroval i dané tabulky, jsem použil program ER Modeller. Tento freeware software dobře posloužil svému účelu a umožnil mi názorně si představit veškeré entity a jejich atributy ve vztazích a souvislostech. Navíc jsem tento program úspěšně používal již v předmětu Y36DBS – „Databázové systémy“, tudíž s ním nebylo třeba dlouze se seznamovat. Nevýhodou však byl nedostatek předdefinovaných datových typů použitých v programu, tudíž po vygenerování SQL příkazů jsem musel některé přepsat (např. z Date na Time apod.). Databázový modelář také vygeneroval pouze obecné SQL příkazy, takže pak bylo potřeba zase jiné datové typy měnit na MySQL syntaxi (např. VarChar2 na VarChar, Number na Int apod.) Zbytek příkazů ale byl v pořádku a dal se použít. Obrázek modelu databáze se čtrnácti entitami naleznete v přílohách, použita byla Chenova notace. Nyní k jednotlivým tabulkám.

3.1.1 Tabulky Hrac, HracuvProfil a ClenTymu Data získaná od uživatelů při registraci byla potřeba velmi pečlivě a s rozmyslem spravovat. Musíme vzít v potaz všechny druhy uživatelů, kteří by mohli mít zájem o to se na našich stránkách registrovat, zároveň však mít veškerá data pokud možno na jednom místě. Tomu všemu je nutné přizpůsobit databázi. Tabulka Hrac ukládá vše, co o sobě uvede hráč v registraci. Atributy email, operator a mobil budou sloužit později pro již zmíněný Upozorňovací systém a jsou povinné pro všechny registrované. Stejně tak jmeno, prijmeni, prihl_jmeno, prihl_heslo, což jsou základní atributy snad pro jakoukoliv registraci. Primárním klíčem v této tabulce je prihl_heslo.

11

Datum_narozeni, herni_pozice, herni_pozice2, cislo_dresu a cesta_k_obrazku budou sloužit hlavně pro účely profilů hráčů a jejich statistik. Herni_pozici2 bylo potřeba ukládat z toho důvodu, že ne všichni hráči hrají pouze jeden post. Např. obránce občas vypomůže v bráně, útočník v obraně a podobně. Je potřeba taková data schraňovat pro případ, že bude najednou některých hráčů s určitým postem na zápas málo a my tak budeme moct pomocí Upozorňovacího systému tyto hráče rychle oslovit a doufat, že nám někdo vypomůže. I když je nám jasné, že jeho sekundární herní pozice nemusí být jeho úplně silnou stránkou, v některých chvílích můžeme být rádi prakticky za kohokoliv. Všechny tyto před chvílí zmíněné atributy jsou pro hráče (jak stálé, tak externí) vesměs povinné, pokud se ale registruje fanoušek, tyto informace nevyplňuje, data jsou ale stále na jednom místě v jedné tabulce. Informace o uživatelské roli uchovává atribut druh_clenstvi. Uživatel při registraci uvede, jak má být jeho registrace posuzována a o které členství vlastně žádá. Mezi možnosti patří:


stálý hráč mužstva - pravidelně se musí nahlašovat na zápasy,




externí hráč mužstva - není uveden v hlášenkách, ale nahlásit na zápas se může




fanoušek – to samé, jako externí hráč, v zápase ale nebude hrát.

Admin stránek jeho registraci posoudí, příp. schválí nebo změní druh členství. Ve stejné chvíli uživateli přiřadí i jeho práva. Možná nepotřebným atributem se zdá být atribut ve_vyuctovani_jako. Jak už bylo řečeno, i amatérský klub, jako je tenhle, musí mít svoje účetnictví. To je pravidelně (většinou vždy po zápase) zveřejňováno na stránkách klubu. Ve vyúčtování u současného řešení jsou hráči ne vždy uvedeni pod svým jménem, např. prakticky nikdo už neřekne našemu záložníkovi Ondrovi Kalátovi jinak, než “Kali”, a i on se pod touto přezdívkou ve vyúčtování vždy hledal. V nové aplikace bude sice způsob vyúčtování řešen jinak (více v dalších kapitolách), toto jsme ale chtěli zachovat. Zároveň ono vyúčtování by už mělo být připravené v době, kdy se hráč na stránky registruje, tudíž není možné použít přihlašovací jméno zadané od uživatele při registraci.

12

Podobný důvod mělo i zavedení tabulky ClenTymu. Budu mluvit z vlastní zkušenosti když řeknu, že údaje, které hráč mnohdy uvede při registraci, mohou být nesmyslné nebo nepravdivé, byť se jedná třeba o vaše jméno. I toto musíme respektovat, na druhou stranu je třeba se s tím vypořádat. Navíc, jakmile se hráč registruje, očekává, že budou okamžitě u jeho jména v profilu vidět jeho dosavadní výkony a statistiky. Hráčova registrace vznikne většinou vždy až poté, co již odehraje za tým nějaký zápas, proto už veškeré statistiky musejí být uvedeny v systému dříve, nejlépe pod jeho hráčovým pravým jménem. Také musíme uvádět, jestli je hráč součástí týmu nebo ne. To všechno jsou důvody, proč tyto tabulky mít. Tabulka HracuvProfil už pouze zajišťuje jakési spojení mezi těmito dvěma tabulkami a to pomocí cizích klíčů id_hrace z tabulky ClenTymu a prihl_jmeno z tabulky Hrac.

3.1.2 Tabulky Zapas a JinaAkce Info o veškerých odehraných nebo chystaných zápasech obsahuje tabulka Zapas. O tom, jestli jsou její atributy povinné, či nikoliv, rozhoduje především atribut charakter_utkani. Mezi jeho možnosti patří mistrovské utkání, přípravné utkání a přátelské utkání. Žádná jiná možnost během mého působení v týmu zatím nenastala. Pokud se např. jedná o přátelské utkání, neurčuje se, v jakém kole se zápas hraje, protože se nejedná o žádnou soutěž. Také pokud vkládáme již odehrané utkání, např. z minulé sezóny, určitě nebudeme dohledávat, v kolik utkání začalo a v kolik skončilo, takové informace jsou nedůležité. Na zápas se mohou pochopitelně nahlásit pouze registrovaní uživatelé/hráči, tudíž proto existuje spojení mezi oběma relacemi v podobě tabulky HlasenkaNaZapas. U ni zachycujeme čas, kdy hráč hlášenku vyplnil (kvůli případné pokutě za pozdní nahlášení), rozhodnutí (ano/ne) a zdůvodnění svého rozhodnutí. Pokud se však hráč nahlásí, že nehodlá přijít, aplikace bude vyžadovat povinné vyplnění důvodu, proč se hráč utkání nezúčastní. Úplně stejně to bude vypadat u tabulky JinaAkce a jejich hlášenek. Sem se budou ukládat informace o chystaných trénincích a závěrečných rozlučkách či pískáních, které tým čeká (viz atribut druh_akce). Tyto akce se budou zobrazovat na stejném místě, kde se bude moct hráč nahlásit na zápas, jen budou barevně rozlišené.

13

3.1.3 Ostatní tabulky K tabulce Zapas se vážou další neméně důležité tabulky. Tabulka Hriste nám dobře poslouží pro vložení dat o názvu hřišti, na kterém se zápas hraje. Pokud hrajeme na onom hřišti vůbec poprvé, mnoho hráčů neví, kde se hřiště nachází a jak se k němu dostat, proto se hodí i atribut mapa. Ten ušetří čas s posíláním infa zvlášť každému hráči, ti pak navíc nepřijdou na zápas včas. U hřišť používaných v PKFL využíváme její oficiální databázi, kde najdeme podrobné info o tom, kde se hřiště nachází apod. Toto info většinou vytváří sami týmy, které hřiště mají jako domácí, tudíž bývá i velmi přesné. Tabulky Soutez a Sezona jsou si velmi podobné. Každý zápas se musí odehrát v rámci nějaké sezóny a nějaké soutěže. Abychom mohli stránky kdykoliv přeorientovat na aktuálně hranou soutěž (např. na přípravný zimní turnaj) nebo na novou sezónu, máme tu atribut aktualni_sezona a aktualni_soutez (typu Bool, 1-je aktuální, 0-není aktuální), který nám toto nastavení umožní. Každý zápas musí vždy skončit nějakým výsledkem a někdo z týmu v tom zápase musel nastoupit. Pro uložení těchto dat tu máme tabulky VysledekZapasu a ZapisZUtkani. Jak jsme ale mohli vidět v nedávné době např. u fotbalové Slavie Praha, ne každý zápas se musí dohrát, výsledek však mít existovat, i kdyby ex post. Pro rozlišení, zda se jednalo o regulérní výsledek, kontumaci (přiznání výhry jednomu týmu např. z důvodu nekázně druhého týmu) či anulaci (pokud dojde k vyloučení druhého týmu během soutěže), máme tu atribut charakter_vysledku. Po každém zápase vedení týmu vyhlašuje hvězdu zápasu, jehož jméno a fotka se bude skvět minimálně týden pod výsledkem tohoto zápasu. Tomu hráči pak bude připsáno drobné zápisné, o čemž již byla řeč. K tabulce ZapisZUtkani snad jen to, že je potřeba rozlišovat brankáře a hráče v poli. Brankáři odchytají určitý počet minut (ne vždy šedesát, brankáři se mohou vystřídat) a dostanou i určitý počet gólů. U hráčů počet odehraných minut nezachycujeme, protože při hokejovém střídání by bylo příliš složité tyto údaje zjišťovat. U hráčů do pole ukládáme počet vstřelených gólů, naopak počet přihrávek z důvodů již řečených také ne. U obou skupin samozřejmě také zjišťujeme, zda neobdrželi žlutou nebo červenou kartu.

14

Po každém zápase by se krom vyplnění výsledku a zápisu z utkání měla napsat i krátká reportáž k zápasu. Ta by se měla vázat přímo k zápasu, což umožňuje tabulka ReportUtkani. Samotný článek se poté píše v rámci tabulky Clanek. Krom předvídatelných metadat článku jako autor, datum, název apod., rozlišujeme také rubriku, do které článek spadá, což se dobře využije hlavně u potencionálního filtrování článků. Některé rubriky jsou známé již dopředu, např. již zmíněný „Report z utkání“, dále pak „Náš příští soupeř“ - pravidelná rubrika o výsledcích a momentálním rozpoložení našeho příštího protivníka, či „Obyčejná novinka“ a „Důležité oznámení“. U článku se dá také předem určit, komu by měl být daný článek směřován, tedy jeho viditelnost:


0 - článek je viditelný pro všechny,




1 - článek je viditelný pouze pro přihlášené,




2 - článek je vidět pouze pro přihlášené hráče (stálé i externí).

3.2 Rozložení položek v menu O položkách v menu a jejich rozmístění probíhala poměrně bouřlivá diskuze s hráči, nakonec jsem si prosadil svoji variantu. Na nákres se můžete podívat níže. Menu bude vysouvací, ale jednotlivé sekce na obrázku už jsou vyjeté ven.

Obr. č. 1 – Schéma rozložení jednotlivých položek v rolovacím menu

Nyní proberu jednotlivé sekce: Novinky – Zde hráč i fanoušek zde nalezne vše nového, co se týká týmu: články, reporty z utkání, oznámení, novinky…Novinky budou stránkované.

15

Tým – V sekci „O týmu“ uživatel nalezne úvodní povídání o samotném týmu, jeho vzniku, historii, důležitých momentech apod. Také info o tom, jakou soutěž tým hraje, filozofie týmu, vedení týmu, domácí hřiště, čas výkopu domácích utkání…V sekci „Soupiska“ uživatel nalezne fotografii celého týmu s popisky hráčů, seznam hráčů týmu – jak stálých, tak externích, a údaje k nim. Do budoucna se počítá i s rozšířením o profily hráčů, kde budou k nalezení statistiky toho hráče za celkové působení v týmu, jeho fotka a třeba malý anketní list s odpověďmi na vážné i nevážné otázky (hráčův fotbalový vzor, oblíbené jídlo apod.). V sekci „Kontakt“ bude uživatel moci oslovit vedení týmu kvůli domluvení změn v termínové listině, pro sehrání přátelského utkání apod. Také info co dělat, pokud by se někdo chtěl stát hráčem týmu a jestli je to vůbec možné. Nebude chybět ani číslo účtu pro členské příspěvky, dary, či pro uhrazení dluhů. V sekci „Stanovy“ budou k nalezení vnitřní pravidla týmu, systém pokut apod. Zápasy – Sekce „Podat hlášenku“ bude nejdůležitější sekcí celé aplikace. Hráč zde nalezne všechny chystané druhy zápasů a akcí, barevně oddělené a bude se na ně moct kladně nahlásit, pokud bude chtít přijít. Do budoucna se počítá, že by se z daného seznamu nahlášených lidí mohl vyexportovat jejich seznam v podobě PDF. Toto PDF by vypadalo stejně, jako vypadá oficiální zápis, který se musí odevzdávat před utkáním rozhodčímu. My bychom ho ale díky tomuto nemuseli psát ručně a, což by těsně před utkáním ušetřilo spoustu času. Hráči, kteří by se nenahlásili a stejně přišli, by se pak dali dopsat tužkou až na místě. Pro ostatní uživatele, kteří nejsou na stránkách zaregistrovaní a chtějí vědět o příštích zápasech, se mohou podívat do sekce „Nadcházející zápasy“. To samé, akorát o již dohraných zápasech a jejich výsledcích, naleznou ostatní v sekci „Odehrané zápasy“. Do budoucna se počítá s tím, že po rozkliknutí jednotlivého zápasu uvidí ostatní zápis z utkání (tedy kdo v utkání nastoupil atd.). Pro statistické údaje o počtu udělených karet, odehraných zápasech v sezóně našich hráčů, bude třeba kliknout na sekci „Statistiky“. Aktuální pořadí v tabulce různých soutěží bude uživatel hledat v sekci „Tabulka“. Fórum – místo, kde uživatelé aplikace spolu mohou komunikovat a hráči probírat aktuální dění v týmu.

16

Multimédia – Hráči zde naleznou obrazový materiál ze zápasů („Galerie“) a spojení na naše videa na Youtube.com („Videa“). Do budoucna se počítá i s možností stažení těchto videí do počítače. Ke stažení – Hráč týmu zde ke stažení nalezne důležité dokumenty, jako např. pravidla fotbalu, instrukce pro rozhodčí, formulář na zápis z utkání, logo týmu apod.

3.3 Layout Pro rozložení obsahu v mojí aplikaci jsem se rozhodl pro třísloupcový layout. Pro lepší představu se můžete nejprve podívat na výslednou podobu hlavní stránky umístěnou v přílohách. Třísloupcový layout se mi osvědčil už u jiných stránek, které jsem v minulosti dělal a nemohu si ho vynachválit. Je krásně vycentrovaný a ideálně se hodí pro takové stránky, kde je potřeba mít pořád na očích spoustu důležitých informací, jako např. příští zápas, který se hraje, nové příspěvky ve fóru, aktuální pořadí v tabulce apod. Pro naše konstantně zapomínající hráče jsem snad lepší řešení ani naleznout nemohl. Horní část pak tvoří již zmíněné rolovací menu s headerem stránek, dolní pak zápatí.

3.4 Redakční systém Redakční systém bude páteří a administračním centrem celé aplikace. Do různých sekcí bude různě omezen přístup. Nyní si probereme jednotlivé části redakčního systému: Administrace hráčů – V této sekci půjde schvalovat nově zaregistrované uživatele a určit jim jejich práva. Také zde půjde je rovnou propojit s jejich „kontem“ ve vyúčtování nebo v archivu. Tyto hráče a jejich práva zde půjdou i editovat a mazat. Administrace zápasů – Odtud půjdou vkládat nové zápasy, editovat jim jejich zadané údaje a mazat je. Pro již odehrané zápasy zde půjde vyplnit jejich zápis a napsat report k utkání. Pro další účely zde bude možné vytvořit nové hřiště, které poté budeme moci použít právě při vkládání nových zápasů. Půjde zde i nastavit aktuálně hraná sezóna či soutěž, což bude mít jisté výhody. Odtud také půjdou oslovit hráči v rámci automatického upozorňovacího systému.

17

Administrace ostatních akcí – Zde půjdou vkládat, editovat a mazat všechny další akce mimo zápasů, na které se hráči budou moct nahlašovat. Půjde o pískání, tréninky či jiné další společenské akce. Administrace novinek – V této části půjdou vkládat nové články, novinky apod. s možností je upravovat a mazat. Pro potřeby archivu – Zde bude možné vytvořit hráče pro účely vložení zápasu, který se odehrál již dávno, ale zároveň některý z účastníků tohoto utkání na stránkách zatím není a nebude se už registrovat. Archivní utkání zde půjde vkládat rovněž.

3.5 Uživatelské role Bez rozlišení uživatelských rolí se dnes snad neobejde už žádný web s možností registrace, natož ještě pokud má daná aplikace i redakční systém. Ani ta naše nebude výjimkou. Číselně rozlišujeme tyto role:


0 - neschválený nebo zakázaný uživatel,




1 - fanoušek,




2 - externí hráč,




3 - stálý hráč,




4 - stálý hráč s určitými administrátorskými právy,




5 - administrátor.

Tato aplikace funguje na principu úplného zákazu a povolování až podle aktuálních práv uživatele. Proto pokud jste administrátor, můžete dělat vše a naopak. Funkčnosti nižších rolí se pochopitelně dědí do rolí s vyšším číslem. Nyní si již konkrétně uvedeme možnosti, které dané role pro jejich uživatele skýtají.

3.5.1 Administrátor Administrátor webu je nejsilnější uživatelská role této aplikace s nejvíce právy a možnostmi. I proto, pokud není nějakým způsobem dlouhodobě indisponován, by měl

18

existovat

jenom

k nedisciplinovanému

jeden,

aby

chování,

se které

předešlo by

mohlo

nedorozuměním ohrozit

a

nedošlo

funkčnost

aplikace.

Administrátor má úplný přístup do redakčního systému i funkčností menu, tedy ke všemu, co popisují kapitoly výše. Není ničím omezen.

3.5.2 Stálý hráč s určitými administrátorskými právy Tato role byla vytvořena pro ty hráče, kteří se budou také chtít podílet na podobě a obsahu webu, ale zároveň by jim neměla být svěřena přímo administrátorká činnost. Tito uživatelé budou moct vyplňovat zápisy z utkání, administrovat články - tedy vytvářet je, editovat a mazat, vypisovat nové zápasy a jiné akce. Tyto činnosti jsou relativně neškodné pro fungování webu a chtíč hráčů podílet se na aplikaci tak bude uspokojen. Zároveň však nebudou mít přístup ke změně práv a spojení, vytváření hráčů, editaci výsledků, zápasů, osobních údajů hráčů apod. K tomu bude mít přístup pouze admin.

3.5.3 Ostatní uživatelské role Stálý hráč má zřejmě nejlepší pozici v mužstvu i co se týče aplikace. Nestará se o podobu webu, zároveň má však přístup ke všemu důležitému a ještě má zajištěno, že kdykoliv, kdy se nahlásí, může přijít hrát zápas. Může se tedy nahlašovat na zápasy, má přístup k výsledkům a zápisu z utkání. Rozdílem oproti externímu hráči je ten, že stálý hráč, pokud není zraněn apod., má povinnost podat hlášenku na každý zápas, zatímco externí hráč jen může podat hlášenku (ale nemusí být přijata). Fanoušek má prakticky stejné možnosti, jako externí hráč, tudíž na první pohled nebyl důvod tuto roli zavádět. Na druhou stranu se může vyskytnout v budoucí době nějaké využití a oddělení fanoušků a externích hráčů nám bude ku prospěchu. Fanoušek, stejně jako externí hráč, si může editovat vlastní údaje zadané při registraci, nahlašovat se na zápasy a změnit si heslo.

19

20

4 Implementace 4.1 Technologie Na začátku této kapitoly bych rád shrnul všechny hlavní technologie a komponenty (krom HTML, PHP a CSS), které používám ve své bakalářské práci. I když je mi jasné, že velká většina věcí zde zmíněných bude zasvěcené veřejnosti známa, neuškodí si udělat takový malý úvod.

4.1.1 Představení použitých technologií Smarty – open source šablonovací systém, který odděluje prezentační vrstvu od aplikačního kódu. Jedná o snadno pochopitelné a dobře udržitelné řešení, vývoj je vcelku rychlý a nepříliš náročný. Spolupracuje s PHP, které používá jako back-end pro své šablony. V těchto šablonách, které mají koncovku .tpl, jsou krom HTML tagů používány i speciální Smarty značky, které se v šablonách odlišují pomocí složených závorek. V moji bakalářské práci používám Smarty ve verzi 3.0.6 z prosince roku 2010 a PHP verze 5.3. jQuery

–

knihovna

JavaScriptu,

která

v mnoha

směrech

vylepšuje

a zjednodušuje jeho používání, zejména v oblasti selekce HTML elementů, animace, používání AJAXu, v práci s událostmi nebo rychlosti vývoje aplikací. Velkou výhodou oproti samotnému JavaScriptu je stejná funkčnost ve všech nejznámějších internetových prohlížečích, jako je Mozilla Firefox, Opera, Safari, Internet Explorer a Google Chrome, což se o čistém JavaScriptu moc říci nedá. V aplikaci je jQuery použito ve verzi 1.5.1 z února 2011. Dibi – databázový layer, který je jinak součástí PHP frameworku Nette. Jeho obrovskou výhodou je přehlednost, jednoduchost zápisu příkazů a automatická podpora escapování/slashování, díky kterému nám odpadá starost o SQL Injection. V aplikaci je Dibi použito ve verzi 1.5rc z ledna roku 2011.

21

4.1.2 Důvody pro použití Smarty O šablonovacím systému Smarty jsem se dozvěděl poprvé již v povinném předmětu „Tvorba webových aplikací 1“ (Y36TW1) a velmi se mi zalíbil. Z důvodů velkého časového zatížení i v jiných předmětech jsem Smarty nakonec ve svojí semestrálce nepoužil, když jsem nakonec sáhl ke klasickému spojení (X)HTML+PHP. Nyní, během tvorby mojí bakalářské práce, se našel čas a mohl jsem tak Smarty blížeji prozkoumat. Opravdu příjemné bylo vyřešení oddělení šablon, tzv. templates, tvořené Smarty značkami plus (X)HTML kódem, a programového kódu, představující PHP. V současné době už si nedokážu představit, že bych webovou aplikaci, pokud bych ji tvořil úplně od základů, tvořil nějakým jiným způsobem, než pomocí Smarty. Vytvářet celý den třeba jenom šablony, pokud se vám zrovna nechce programovat a naopak, se ukázala jako skvělá možnost. Dokážu si představit, že to takto funguje i při práci v týmu, kde nad projektem nesedí jen jedna osoba, jako zde, ale je potřeba práci rozdělit mezi více lidí. Užitečnost tohoto rozvržení se ukázala i při tvorbě moji bakalářské práce. Smarty se nepoužívá jen samo od sebe, i např. PrestaShop, profesionální systém pro provoz e-shopů, Smarty využívá. Umět ve Smarty tudíž není rozhodně ztráta času.

4.1.3 Důvody pro nepoužití CMS Jelikož moje aplikace obsahuje i redakční systém, nabízelo se použití některého z open source CMS jako např. Wordpress, Drupal nebo Joomla. O těchto CMS systémech jsem dříve slýchaval, že se jedná o rychlé a díky mnoha zdarma přístupným šablonám i o dobře vypadající řešení. Následně jsem se s jedním z nich, s Wordpressem, podrobněji seznámil i v povinně volitelném předmětu „Správa digitálního obsahu v organizacích“ (s kódem Y39SDO) zde na fakultě. CMS typu Wordpress už sice mají spoustu hotových řešení, různých pluginů a na systému pracuje velká komunita lidí, na druhou stranu mnoho těchto pluginů už je zastaralých, dále se nevyvíjí a na nejnovějších verzích CMS nemusí fungovat úplně spolehlivě. V mnoha případech je Wordpress a spol. příliš složitý a rozsáhlý systém se spoustou souborů a trvá velmi dlouho se s ním podrobněji seznámit, pokud v něm chcete vyvíjet a ne si jen během pěti

22

minut udělat blog. Pro aplikaci, kterou bude pravidelně využívat maximálně dvacet až třicet lidí, jako právě tu naši, je takové řešení až příliš zbytečně složité. Musíme myslet i na to, že drtivá většina našich hráčů o těchto systémech nikdy neslyšela a i když jsou tyto CMS právě na takové uživatele připraveny, přesto si myslím, že použití CMS je moji aplikaci (zatím) nepotřebné. Navíc by bylo nutné učit se další, byť proprietární, programovací jazyk. Dokumentace Wordpressu je sice vcelku dobře zpracovaná, ale oproti právě Smarty dochází k většímu míchání programovacímu kódu a kódu šablon, čehož jsem u Smarty docenil, že tomu tak právě není. Tyto systémy ale jinak vcelku chválím a nebránil bych se v budoucí době tvorbě pluginů pro fotbalová mužstva, např. pro nahlašování na zápasy, vkládání výsledků apod. Pro svoji aplikaci jsem ale raději zvolil možnost vytvořit si vlastní redakční systém, kde budu mít vše plně pod kontrolou. Nadále ale budu sledovat, jakým směrem se budou CMS systémy vyvíjet.

4.2 Validace formulářových dat Validaci dat, které uživatel zadá do formulářových elementů, provádím ve svojí aplikaci pomocí Form validation engine ve verzi 2.0. Velmi obsáhlý open source jQuery plugin pro front-endovou „živou“ validaci je jednoduchý na použití, přitom velmi mocný. Stačí v elementu input do atributu class vložit kód (např. class=”validate[required]“),

který engine rozpozná a podle toho spustí konkrétní

způsob validace. Pokud není validace úspěšná, objeví se červená varovná hláška. Spuštění validace pro konkrétní formulář zajistíme pomocí jQuery a funkce validationEngine().

K tomu ještě třeba dát pozor na to, aby každý input element měl

atribut id, díky kterému engine vytváří a rozpoznává chybové hlášky. Bez toho se jinak validace nespustí. Form validator engine umí krom varovných hlášek i zobrazení zelených, informačních hlášek, což se např. během registrace osvědčilo. Mimo to zvládne i snadno spolupracovat s technologií AJAX. Ihned během registrace nám tak engine zjistí, zda-li už neexistuje uživatel s tím konkrétním přihlašovacím jménem, e-mailem

23

či mobilním telefonem. Díky tomu se tak prakticky nemůže stát, že by se registrace nezdařila a uživatel by musel informace zadávat znovu, tudíž ani tak nemusíme řešit předvyplnění dat po neúspěšném odeslání formuláře. Engine umí i krom předefinovaných pravidel pro validaci přidávat i pravidla vlastní, třeba pomocí regulárního výrazu. Toho jsem využil kupříkladu u zadávání čísla dresu (povolené hodnoty od 1-99). Nevýhodou tohoto enginu je, že produkuje nevalidní kód, tudíž kdekoliv je použit, přídavek pro Firefox - HTML Validator nalezne chybu a my na první pohled nepoznáme, zda našel tuto či i jinou námi způsobenou chybu. Na druhou stranu krom tohoto funguje perfektně a dle mého se hodí do každé aplikace, kde je potřeba validovat data zadaná uživatelem.

4.3 Bezpečnost 4.3.1 Ukládání a změna hesel Velmi důležitou a zároveň citlivou oblastí bezpečnosti aplikace je ukládání a změna přihlašovacího hesla. Mnoho uživatelů internetu používá jen jedno heslo ke všem účtům a jakmile je toto heslo prozrazeno, může dojít k velkým problémům, které není třeba dále rozebírat. V současné době už není vhodné hesla před uložením šifrovat pomocí PHP šifrovací funkce md5(), která je v současnosti velmi nespolehlivá. Jen pro zajímavost jsem zkusil odhalit hesla spoluhráčů na našem současném webu, kde původní autor právě pomocí algoritmu MD5 hesla šifroval – na tři hesla z osmnácti Google přišel! Proto není pochyb, že s MD5 už opravdu ne. Místo toho si při registraci uživatele uložíme spolu s jeho ostatními daty i náhodný řetězec, tzv. sůl, kterou zadané heslo zašifrujeme a máme bezpečné uložení. Pro samotné zašifrovaní použijeme algoritmus sha256, který by měl být bezpečný za každé situace a to i v případě vyzrazení soli. Změnit heslo si uživatel může na dva způsoby. Buď ho již zapomněl, nebo si ho stále pamatuje, ale z nějakého důvodu ho chce stejně změnit. V obou případech mu samozřejmě jeho heslo nemůžeme poslat (třeba na e-mail), protože sami heslo neznáme

24

a ani ho zjistit nemůžeme. Proto pokud uživatel zažádá o vyresetování hesla a vytvoření nového, opět vygenerujeme náhodný token, jenž zašifrujeme a v url ho odešleme na jeho e-mail. Ono url bude směřovat na formulář, kde zkontrolujeme, zda sedí tokeny a pokud ano, povolíme mu heslo změnit. Token bude platný jeden den, poté si bude muset zažádat o změnu znovu. Tato procedura nám umožní zajistit, že si heslo změní jen ten, který má přístup k zaregistrované e-mailové adrese. Druhý způsob bezpečné změny hesla, tedy tehdy, pokud si uživatel heslo pamatuje a je stále přihlášen, zajistíme díky tomu, že uživatel uvede krom nového hesla i své původní heslo. Tím zabráníme změnám hesla v případě, kdy se uživatel např. zapomene odhlásit a někdo jiný by toho chtěl využít ve svůj prospěch. Jak uživatel zachází se svým heslem jinde je už čistě na něm a jeho vyzrazení nemůžeme zabránit.

4.3.2 Ochrana proti XSS Chránit se před XSS je další bodem pro to, abychom měli bezpečný web. SQL Injection už nám vyřešil samotný databázový layer, o zbytek se musíme postarat sami. Jedním z druhů útoku je vložení škodlivého kódu do databáze, který po načtení může narušit bezpečnost nebo ovlivnit podobu aplikace. Dle názoru Jakuba Vrány, předního českého odborníka na PHP, by tato kontrola měla proběhnout spíše až při výpisu těchto dat a ne už během jejich zápisu, protože nikdy nemůžeme vědět, jaké plány může uživatel i programátor s těmito daty mít. Escapování HTML tagů tedy provádíme až na výstupu a to, pokud to jde, až přímo ve Smarty šablonách pomocí funkce escape s hodnotou 'htmlall'. Pokud to nejde jinak a je třeba výstup ošetřit, použijeme známou PHP funkci htmlspecialchars().

Dalším druhem útoku je podstrčení nebezpečného kódu do url jako GET parametr. Tohoto se můžeme vyvarovat opět pomocí již zmíněné PHP funkce nebo také pomocí jasného definování, které hodnoty umožníme a které ne. Pokud by útočník nějaký takový nebezpečný kód podstrčil, stránka na to nijak nezareaguje, prostě nic nezobrazí. To zajišťujeme pomocí PHP funkcí isset() a následně určením chtěných hodnot díky switch/case. Jinou příležitostí, jak zaútočit, by mohl mít škůdce v rámci editoru TinyMCE (bude o něm řeč i později), který používáme na tvorbu nových článků. V něm jsme ale

25

deaktivovali editor HTML, tudíž autor bude moct pouze napsat text a zformátovat ho, nemůže však vkládat svůj vlastní kód, vytvářet CSS styl apod. Samotný TinyMCE se už se o XSS útoky v rámci svého editoru postará.

4.3.3 Znovuodeslání formuláře Aby nedošlo ke znovuodeslání formulářových dat, po každé úspěšné editaci či vložení dat uživatele přesměrujeme na jinou stránku. Zamezíme tak dvojímu odeslání dat, které by jinak mohlo „vyhodit“ warningy a errory. Pokud by se však některá změna dat nepovedla, uživateli ukážeme příslušnou chybovou hlášku a nikam uživatele nepřesměrujeme, to aby mohl svoji chybu na místě vyřešit.

4.3.4 Uložení profilové fotky Při registraci uživatel může nahrát svoji profilovou fotku. Pokud by se ale spletl a nahrál by jinou, než by chtěl, musíme mu umožnit nahrát další. To s sebou přináší řadu problémů. Uživatel by jednak mohl zahltit fileserver nepotřebnými soubory, jednak samotná možnost nahrávání souborů by mohla způsobit, že někdo nahraje jiný soubor, než obrázek. První problém řeším tím, že spolu s názvem fotky ukládám i jméno hráče, které mezitím zadal na jiném místě, a aktuální čas, kdy poslední použitý řád je řád minut. Při nahrání dochází ke kontrole, zda už daný soubor neexistuje, uživatel tedy musí vždy maximálně jednu minutu počkat, než mu aplikace umožní nahrát obrázek další. A pokud jich přece jenom nahraje víc, podle jména poznám, které komu patří a ručně promažu ty starší z nich, když bude třeba. Během nahrání také dojde ke zmenšení obrázku v daném poměru, stačí tedy v kódu předem určit maximální povolenou výšku či šířku a systém se už o vše ostatní postará. Druhý problém byl s rozlišením toho, zda se jedná o obrázek či nikoliv. PHP na to sice nemá žádnou speciální funkci, lze ale to ale obejít a použít jinou funkci getimagesize().

Ta, jak už z názvu vyplývá, vrací výšku a šířku daného obrázku.

Pokud by někdo chtěl nahrát jiný soubor, přejmenoval ho např. na koncovku .gif a

26

pokusil se ho nahrát, funkce vrátí null a my tak snadno rozpoznáme, že se daný soubor jen za obrázek vydává.

4.4 Import dat Abychom mohli mít vždy aktuální obsah na svém webu, museli bychom celý víkend sedět u internetu a čekat, až se nějaký zápas dohraje, abychom mohli tyto výsledky ihned zanést do databáze. To ale nebylo cílem tvorby této bakalářské práce. Proto ta data, která chceme, aby byla aktuální, importujeme z jiných stránek na ty naše a tím zajistíme, že náš obsah bude vždy aktuální, aniž bychom vyvinuli příliš úsilí. K tomu

nám

pomůže

malá

knihovna

pro

PHP

jménem

Simple HTML DOM Parser. Díky ní si určíme, ze které url chceme data sbírat a poté pomocí jejích funkcí data v kódu nalezneme, profiltrujeme a poté i vypíšeme. Tento způsob používám ve své aplikaci např. pro zjištění aktuálních tabulek pořadí konkrétních soutěží. Stačí, aby stránky měly zobrazitelný zdrojový kód (a nebyly např. ve Flashi), data aby byla hierarchicky uspořádaná (což u tabulky není problém) a hráči už nebudou muset chodit na oficiální stránky soutěže a hledat, kolikátí v tabulce zrovna jsme. Vše uvidí ihned v levém panelu stránek. Krom tohoto se dá tento parser využít k nespočet dalším způsobům, já toho využívám ještě pro zjištění oficiálních hřišť PKFL a jejich infa, jak se na hřiště dostat. Toto info se také zobrazí v mojí aplikaci a značně ušetří hráčům i mně čas s hledáním důležitých informací. Samozřejmě problém může nastat ve chvíli, kdy stránky druhé strany „spadnou“ a my, závislí na jejích datech, nebudeme mít z čeho čerpat. Parser však využívám od začátku tvorby mojí bakalářské práce a výpadků, které bych stihnul postihnout, bylo poskrovnu, asi stejně jako u jakýchkoliv jiných stránek. Pokud se změní podoba stránek a rozložení požadovaného obsahu, může také dojít k výpadkům dat a na mně bude, abych co nejrychleji změnu rozpoznal a přizpůsobil ji pro moji aplikaci. Pořád je to ale lepší to tak třeba jednou za pár let udělat, než sedět každý víkend u počítače. Na druhou stranu nechceme nijak ubírat na návštěvnosti „vykrádáním“ obsahu odjinud. Hráči na oficiální stránky soutěže, odkud data převážně bereme, budou stejně

27

chodit tak jako tak, protože tam je spoustu dalšího zajímavého obsahu, kvůli kterému nestojí za to se omezovat jen na naši aplikaci. Krom toho pod každou z tabulek bude uveden zdroj, odkud data pochází i s příslušným odkazem.

4.5 Tvorba článků a novinek Tvorba článků se dočkala oproti dřívějšímu řešení, dnes v již původní aplikaci, pár změn. Nyní lze předem určit, do které kategorie/rubriky ten který článek spadá. Článek pak má u sebe malý obrázek značící rubriku, pro kterou byl článek napsán. Do budoucna se plánuje mít možnost vytvoření si nové rubriky nebo třeba filtrace článků. Na samotnou tvorbu článků byl použit javascriptový WISIWYG nástroj TinyMCE. Ten umožní psát a formátovat články stejně, jako v jakémkoliv jiném desktopovém editoru (např. MS Word). Aby však nedošlo k rozhození designu nebo narušení jednotné podoby novinek, neumožnil jsem editorům vkládat vlastní styly ani žádné další vymoženosti, omezil jsem možnosti pluginu jen na základní formátovací funkce. I ty však v původní aplikaci chyběly. Mezi nejdůležitější patří hlavně vkládání hypertextových odkazů a tvorba seznamů. Přídavný plugin tinyautosave navíc automaticky ukládá již napsaný článek, takže se nemůže stát, tak jako v minulosti, že by došlo k nevratné ztrátě již napsaného textu. Pro vylepšení dojmu z přehledu novinek, každý článek na první pohled zkracuji ve spolupráci s pluginem jQuery truncator. Člověk si ale po kliknutí na „pokračování článku“ může celý článek rozkliknout a dočíst si ho. Nestane se tak, že delší články pohltí v celku ty kratší, všechny dostanou stejný prostor. Pro non-AJAXové stránkování článků zase používám plugin jQuery SimplePager.

4.6 Upozorňovací systém 4.6.1 Důvody pro zavedení upozorňovacího systému Jedním z mých osobních požadavků na aplikaci bylo ušetření času při „administraci“ týmu. Během týdne často ztrácím čas věcmi, které by se dle mého daly urychlit. Někdy totiž dojde k situaci, kdy je třeba hráčům rychle dát vědět, např. když dojde k termínové

28

změně zápasu. Bez naší rychlé reakce, která probíhá většinou po telefonu, se může stát, že na zápas přijde třeba jen půlka z původně nahlášených. Také v dalších situacích bude mít tento systém důležité zastoupení. Například pokud se vedení týmu dohodne odehrát nějaký turnaj, o kterém ostatní hráči nevědí, budou upozorněni, jakmile budou tyto zápasy vloženy do databáze a vypsány na webových stránkách. Nestane se tak, že se někteří dovědí o tom či onom turnaji nebo zápase až po jeho skončení. I kdyby se k nim informace o vypsání nových zápasů nějakým způsobem nedostala, budou v předem stanovený čas (např. 48 hodin před výkopem) upozorněni na to, že si ještě nevyplnili konkrétní hlášenku a že jim jinak bude uvalena pokuta. V případech, kdy by stálí hráči týmu hromadně nemohli na onen konkrétní zápas přijít, využijeme upozorňovací systém k tomu, abychom oslovili externí hráče, kteří jsou sice součástí týmu, ale jak už bylo řečeno, za tým hrají kvůli své vytíženosti jen sporadicky. Je jich však tolik, že je velká šance, že si někdo z nich čas udělá a zastoupí někoho z těch stálých. V drtivé většině případů se ale zatím stalo, že důvodem malého počtu nahlášených hráčů na zápas byl právě malý počet nějak vůbec vyplněných hlášenek, tudíž nakonec, byť už po termínu, se nakonec stálí hráči nahlásili. Pokud je ale náš systém upozorní dopředu, nebudeme to muset vůbec řešit. Náš systém upozorní i dlužníky v řadách hráčů. Jsou tací,

co pravidelně

zapomínají platit a když už, tak pozdě a ještě ne celou částku. Navíc se vymlouvají, že nevěděli, kolik přesně dlužili, takže nepřinesli dost peněz. Systém takové hráče, pokud přesáhnou nějakou limitní částku (např. 250 Kč), upozorní a hráči se už jednak nebudou moci vymlouvat, jednak pokud to budou vědět dopředu a budou svědomití, mohou peníze obratem poslat na týmový účet. I zde nám systém může hodně pomoct.

4.6.2 Způsoby upozorňování Způsobů, jak upozornit hráče na to, co chceme, je několik. Krom toho, že se o zprávě musí dozvědět okamžitě, jsou důležitým faktorem také finance. Mimo samotného hostingu, který je nutný pro spolehlivé fungování webu, už musí jít zbytek peněz, které se vyberou, přímo na samotnou hru. Na turnaje, vybavení týmu a další výdaje. Proto je potřeba využít všech možností, které nám internet nabízí.

29

4.6.2.1 SMS Pro posílání SMS hráčům pomocí internetu bylo potřeba dvou zásadních věcí. Aby to umožnili sami operátoři a aby se při posílání SMS nemusely pro každou SMS opisovat tzv. CAPTCHA kódy, což by odesílání zpomalilo. To první bylo splněno před pár lety, když i poslední z operátorů – T-Mobile – spustil posílání SMS z internetu. To uvolnilo ruce mnoha provozovatelům SMS bran, kteří se tak nyní nemusejí omezovat na jednoho či dva operátory a mohou svým uživatelům poskytnout plný servis zdarma. Jednou z bran, která toto umožňuje a zároveň nemusíme opisovat otravný CAPTCHA kód, je server poslatsms.cz. Stačí se na něj pomocí PHP kódu napojit a dále už se jedná o prostý POST požadavek na dané URL s několika položkami. Samotná data posílaná na externí službu do URL podoby vyrábí a encoduje z asociativního pole PHP funkce http_build_query().

Problémem ale je, že samotná brána pozná operátora jen podle jeho předčíslí (např. 608 pro Vodafone apod.) v případě, že mu sami neřekneme jinak. Protože je už pár let možné přejít k jinému operátorovi, aniž bychom si změnili číslo, je tudíž nutné, aby hráč při registraci uvedl nejen platné telefonní číslo na mobil, ale i svého současného operátora. Tyto i jiné další informace bude moci kdykoliv ve svém profilu případně změnit. Bohužel v době dokončování moji bakálářské práce služba poslatsms.cz dočasně znemožnila posílání SMS na operátora Vodafone kvůli přestavbě Vodafone SMS brány (ostatní operátory však stále podporuje). Proto bude zatím upozorňovací systém v tomto ohledu fungovat jen částečně a momentálně tak musíme hráče s Vodafone oslovovat ručně tak, jako dřív. Za pár dnů ale může být vše při starém.

4.6.2.2 E-mail Dalším způsobem, jak upozornit hráče, je poslat jim e-mail. Samozřejmě i tento požadavek je v dnešní době snadno zdarma poskytnutelný a to přes dobře známou PHP funkci mail(). Tuto funkci používá i PHP knihovna zvaná PHPMailer, která ulehčuje a vylepšuje její používání. Umožňuje krom obvyklých funkcionalit například posílat embedovanou fotku v HTML e-mailu - to kdybychom chtěli, aby si hráči například

30

ihned všimli nějaké pozvánky na turnaj, letáku apod. a nemuseli stahovat přílohu. Celkově je práce s knihovnou intuitivnější, i proto ji používám ve své práci. Aby vše bezpečně fungovalo, stačí, aby provozovatel hostingu povoloval funkci mail() využívat. Otázkou však je, zda je upozorňování e-mailem skutečně tak efektivní, jak by se na první pohled mohlo zdát. Je věcí každého hráče, jak často svůj e-mail kontroluje či zda si z něj nechává poštu přesměrovávat v podobě sms upozornění na mobil. Na druhou stranu pořád tu máme původní upozorňování na mobil, což by měla být priorita a navíc, drtivá většina hráčů, pokud už nenavštěvuje svůj mobil či e-mail, často chodí na svůj Facebook profil. Právě Facebook v současné době zavedl do provozu pro každý profil jeho vlastní e-mailovou adresu, čímž dojde ke spojení těchto e-mailů se současnými Facebook zprávami. Hráči si tak při registraci budou moci tento e-mail zadat, čímž se šance k jejich „odchycení“ jistě opět zvýší.

4.6.2.3 Cron Krom činností, které budou reagovat na nový podnět (vypsání nových zápasů, oslovení externích hráčů apod.) bude potřeba některé akce vykonávat automaticky. To se týká např., jak už bylo řečeno, upozornění o nevyplněné hlášence, překročení maximální dlužné částky apod. To nám bude zajišťovat Cron, unixový spouštěč skriptů a úloh v pravidelných časech, které mu určíme. Ten bude automaticky vykonávat PHP skript, kdy bude např. tahat potřebná data z databáze a posílat SMS nebo e-mail upozornění konkrétním uživatelům. Cron však opět musí být podporován profesionálním hostingem, za jehož služby se platí. Hosting, kde sídlí náš web, cron plně podporuje, proto bude možné ho využívat.

4.7 Hlášenkový systém Hlášenkový systém naleznete v sekci „Podat hlášenku“. Jak už bylo zmíněno dříve, jde o možnost přihlášeného uživatele nahlásit se na konkrétní zápas a vyjádřit tak zájem o to tento zápas hrát. Ukáže tím také ostatním, aby s ním počítali, že na zápas přijde. V tomto systému se nahlásí a současně se může podívat i na hlášenky zbylých hráčů,

31

jestli jsou vyplněné. Při vyplnění hlášenky případně uživatel bude moct uvést důvod, proč se tak rozhodl. Záměrně píši uživatel, protože bylo myšleno i na to, že krom stálých hráčů, kteří se musí nahlašovat pravidelně, se do aplikace registrují i externí hráči a fanoušci, kteří primárně ve výpisu nejsou. Na zápas se ale nahlásit mohou, v tom případě je systém rozezná a také je uvede ve výpisu – v případě externích hráčů se s nimi bude počítat do hry, s fanoušky nejlépe za plot, povzbuzovat. Krom tohoto má systém ještě jednu skvělou výhodu. Během času, co zatím tým vedu, se sezóna neobešla bez nějakého zranění apod. V takovou chvíli, kdy hráč třeba na půl roku vypadne ze hry, nemá cenu, aby se nahlašoval na zápasy, že nepřijde, když o tom stejně každý dávno ví. V takovou chvíli využijeme možnosti nastavit si svůj aktuální stav v pravém panelu. Hráč např. změní svůj výchozí stav „zdravý“ na „zraněný“ a v tu chvíli se nebude muset na zápasy nahlašovat, tím pádem se vyhne i pokutám. A možných stavů je víc. Jeden z našich hráčů, pokud není zrovna nemocný, jezdí pravidelně do ciziny. I on tuto možnost využije, stav „v zahraničí“ byl pro něj vytvořen prakticky na míru.

4.8 PHP třídy Hlavní PHP třídy, které se mi o starají o chod aplikace, jsou třídy Hrac a Zapas. Třída Hrac se pochopitelně stará o vše, co se týká hráčů, od getterů a setterů, zjišťování infa kolem hráčů, spojení s tabulkou ClenTymu apod. Třída Zapas se krom informací o zápasech stará i o soutěže, sezóny, výsledky, zápisy z utkání a hřiště. O zbytek se starají další, rozsahem menší třídy nebo pomocné PHP soubory.

4.9 Snadná přenositelnost a změna obsahu Při tvorbě této aplikace také bylo myšleno na to, aby se kód těchto stránek mohl snadno použít i u jiného podobného týmu bez jiných větších změn. Aby si klub mohl přizpůsobit obsah webu, stačí změnit pár údajů v konfiguračním souboru Smarty v adresáři /configs/data.conf. Krom samozřejmé změny údajů pro připojení

32

k databázi si potencionální jiný tým může změnit PKFL ligu, kterou hraje (pro účely HTML DOM Parseru), název týmu, který se zobrazí ve výsledcích i jinde. Dále záležitosti týkající se upozorňovacích mailových zpráv, které se hráčům odesílají, a také pokud tým bude chtít řešit vyúčtování stejným způsobem, jako my, uvede své přihlašovací údaje ke Google účtu (info o tom později). To vše na jediném místě. Také bylo potřeba vyřešit, jak se snadno „přehoupnout“ do nové sezóny po skončení té předchozí. Krom změny v konfiguračním souboru lze v redakčním systému nastavit aktuálně hranou soutěž (PKFL, přípravný turnaj…) a tabulky nebo statistiky se tomu ihned přizpůsobí.

4.10 Práce s databází Nyní pár slov k tomu, jak jsem implementoval a používal databázový layer Dibi. Jak už bylo řečeno dříve, práce s ním byla opravdu jednoduchá a velmi rychle jsem zapomenul na dřívější styl práce s databází pomocí psaní klasických MySQL příkazů. Prakticky si stačilo zjistit jen pár základních příkazů a ve spolupráci s PHP nebyla práce s Dibi žádnou překážkou. Pole najitých prvků jsem vždy procházel příkazem foreach. Pokud jsem potřeboval zjistit z výsledku dotazu jen první hodnotu (nejčastěji u getterů), zavolal jsem funkci fetchSingle(). Výhodou oproti klasickému zápisu dotazů byla i možnost ukládat do databáze rovnou celé pole, i s přeházeným pořadím položek.

4.11 Další pomoc od jQuery V mnoha situacích jsem si pomohl nejen jQuery samotným, ale i nejrůznějšími jQuery pluginy a přídavky, bez kterých by jinak výsledek nevypadal tak hezky. Pro práci s datumy využívám plugin datePicker, který mi umožní, aby si uživatel mohl vybrat datum, které potřebuje, v kalendáři. Díky nastavení se navíc nemůže stát, že by uživatel zadal datum, které by neexistovalo (tedy např. 30. února apod.) nebo aby příští zápas měl datum v minulosti. Velkým pomocníkem v dalších situacích byl jQuery plugin autocomplete. Tento plugin slouží jako jakýsi „napovídač“ pro textové input elementy. Kdykoliv

33

v daném formulářovém poli chceme něco zadat, nabídne se nám pod ním automaticky volitelná nabídka. Toho využívám např. u vyplnění názvu hřiště, na kterém se daný zápas hraje. Aby došlo ke konzistenci dat a nedošlo třeba k zadání toho samého hřiště dvakrát různým způsobem, jQuery autocomplete nám nabídne možnosti a my si podle toho zvolíme tu správnou. Plugin navíc funguje i jako vyhledávač, tudíž jde o lepší řešení, než hledat to, co chceme, při použití HTML elementů select-option. Tento plugin využívám i při dalších činnostech, např. při spojení nově zaregistrovaného hráče s jeho přiřazeným jménem ve vyúčtování (atribut „ve_vyuctovani“ tabulky Hrac) či pro účely archivu (tabulka ClenTymu). Výborným doplňkem i pomocníkem je také jQuery tablesorter. Ten slouží hlavně u statistik, sekundárně i u jiných tabulek. U statistických údajů nám krásně seřadí hráče podle odehraných zápasů, počtu žlutých karet např., u brankářů ihned zjistíme, jakou mají úspěšnost v chytání apod. Všechny tyto údaje se nám sbírají ze zápisů z utkání, nic se nemusí zadávat ručně, jako tomu bylo dříve. Na závěrečné rozlučce týmu se sezónou tak díky tomuto doplňku půjde mnohem lépe určovat, který hráč byl skutečně nejlepší nebo nejtrestanější, jQuery tablesorter nám tabulku seřadí podle naší chuti. Spíše do sféry zábavy může patřit plugin jQuery imgPreview. Po najetí na ikonku hráče v hlášenkovém systému se automaticky zobrazí náhled jeho profilové fotky. Při návrzích na nové stránky týmu kdysi zaznělo, že často není podle přezdívky poznat, o koho v týmu jde. Toto řešení snad vše vyjasní.

4.12 Vyúčtování O tom, jak vyřešit zobrazení vyúčtování a dluhů hráčů v aplikaci, proběhla v mé hlavě asi největší diskuze. Nakonec jsem se rozhodl využít služeb stále se více rozvíjejících Google Docs a to konkrétně její „excelovské“ verze Google Spreadsheets. Jak už bylo řečeno v úvodu, současné řešení zobrazení dluhů na původních stránkách není intuitivní a ani příliš flexibilní. Velkou výhodou u tabulek Google Docs je to, že jsou neustále k dispozici online na internetu a dají se k nim přistupovat i bez toho, aniž byste měli fyzicky nějaký binární soubor u sebe na disku.

34

Samozřejmě se nabízí otázka, proč neudělat nějaké vlastní řešení v aplikaci, kam data zadávat. Bohužel moje nároky na účtování, které v týmu vedu, jsou příliš složité, než aby šly zpracovat do nějakého snadného řešení. Nedokážu si představit, že bych např. každého hráče rozkliknul, k němu onu částku zapsal, ty data spravoval, editoval…Navíc se k pokutám většinou uvádí vysvětlivka nebo značka, tabulky mají různé vzorce, je potřeba zobrazit peníze v banku apod., je toho prostě moc. Proto bude lepší, když zachováme již zažitý formát, jen jej vylepšíme. Jedním z požadavků také bylo, aby bylo možné po přihlášení uživatele výslednou dlužnou částku hráče ihned zobrazit. Hledal jsem tedy způsob, jak propojit moji aplikaci s Google Docs, aniž bych přitom musel studovat jejich složitou dokumentaci. Řešení jsem nalezl v pomocné PHP knihovně Google Spreadsheet Helper Class ve spolupráci se Zend Gdata Client Library. Díky tomu stačí uvést jméno Google tabulky, přihlašovací údaje k nutnému Google účtu, název sloupce a jméno hráče a máme danou částku k dispozici pro naši aplikaci kdykoliv chceme. Nevýhodou během testování aplikace se však ukázalo být výrazně pomalejší běh aplikace, pokud pokaždé docházelo po přihlášení k automatickému načtení dlužné částky. Samozřejmě ne při každém přihlášení chce hráč znát svůj dluh, proto došlo ke změně. Hráč v nynější fázi klikne na tlačítko, tím si zažádá o zjištění dlužné částky a s pomocí AJAXu se mu během několika sekund částka zobrazí. Pokud bude chtít, bude se moci podívat i na kompletní tabulku s vyúčtováním celého týmu. Běh stránek se tak výrazně zrychlil při zachování požadované funkčnosti.

4.13 Dotahování hlášenek Poslední užitečnou funkcí, kterou aplikace umí a je dobré jí tu zmínit, je poloautomatický způsob vyplňování zápisu z utkání, tedy jeho výsledku a seznamu hráčů, kteří v utkání nastoupili. Kdybychom měli pokaždé „naklikat“ všechny hráče, kteří v tom zápase nastoupili, trvalo by to velmi dlouho. Data pro tento zápis proto aplikace bere přímo z hlášenkového systému, tudíž pokud se hráči poctivě nahlašují, o to míň pak budeme mít práci s jeho vyplněním. Samozřejmě, že ty, co se nenahlásili,

35

a v zápase nakonec nastoupili, je možné do zápisu pomocí jQuery dopsat, stejně tak obráceně ty, kteří se nahlásili a nakonec nepřišli, ze zápisu vymazat.

4.14 Výsledná aplikace Výslednou aplikaci jsme, nejen pro účely testování, umístili na adresu highsociety-team.cz, kde se i nyní nachází aktuální funkční verze, a kde budou stránky i nadále. Protože byla aplikace původně vyvíjena na localhostovém serveru (pomocí Wampserveru), s přesunem na nový hosting se vyskytlo pár problémů, zřejmě kvůli různému nastavení Apache serverů. Problémy se ale podařily opravit a tak se dnes každý může podívat v rámci bakalářské práce na finální produkt. Na screen z hlavní stránky se rovnou můžete podívat v přílohách. Chybí však ještě přidávání jiných akcí a některé z editací dat v redakčním systému, nefunguje také filtrace článků. Nedořešené zatím zůstaly i profily hráčů, propojení výsledků a jejich zápasů přímým odkazem a i upozorňovací systém je zatím ještě v plenkách. I všechny sekce, které vidí běžný uživatel, mají ještě daleko k ideálnímu stavu. Redakční systém nemá ještě všude plně zajištěnou validaci, nedošlo ani na některé chyby, které odhalilo níže popsané testování. Zatím není ani vyřešená situace, která by např. mohla nastat po víceletém provozu stránek a v aplikaci se nahromadila data. Aplikace však bude ve volném čase i nadále vyvíjena, aby mohla být před novou sezónou 2011/2012 spuštěna v ostrém provozu.

36

37

5 Testování 5.1 Unit testování Unit testování je důležité pro jakýkoliv software. Právě na těch nejmenších jednotkách – PHP funkcích, záleží celá aplikace. Jedna nepozornost při úpravě kódu nebo při přidání celé nové funkčnosti nám může zadělat na spoustu řetězících se problémů. I proto je unit testování velmi užitečné, zvlášť jako v mém případě, kdy budu aplikaci nejen na základě připomínek, které vzešly z uživatelského testování, ještě rozšiřovat a dále zdokonalovat. PHP unit testování jsem provedl pomocí známého open source unit testeru SimpleTest. S jeho pomocí jsem provedl zatím jen namátkové testování mezi těmi nejdůležitějšími funkcemi, jelikož hodně ostatních funkcí jsou jen gettery a settery pro data z databáze, které snad od testování mohu ušetřit. Díky unit testování bylo ve finále nalezeno několik funkcí, které testováním neprošly, proto jsem na základě jeho výsledků tyto chyby opravil. Testy můžete projet spuštěním souboru unit_testing.php, který je umístěn spolu s ostatními PHP soubory v adresáři aplikace.

5.2 Uživatelské testování Pro testování uživatelů jsem požádal své dva zástupce a zároveň přátele ve vedení týmu, aby celkově prošli moje internetové stránky a dali mi připomínky, jak aplikaci vylepšit nebo kde jsou její slabá místa. Jelikož se zatím jedná o prototyp, šlo především o testování pouze jednotlivých částí prototypu. Rozdělení na konkrétní use cases mi přišlo zbytečné, protože tolik tam toho zatím k testování není. Až bude aplikace kompletnější, provedu rozsáhlejší testování i mezi ostatními hráči, kteří by jinak ze současné verze mohli být možná trochu zklamáni.

38

5.2.1 Uživatel č.1 Prvním uživatelem, který aplikaci testoval, je Jan Bartůněk. Honza dříve pracoval jako tester softwaru, tudíž jeho „útoky“ byly často velmi dobře mířené a často odhalily slabá místa aplikace, protože zkrátka věděl, kam sáhnout. Připomínky a návrhy, které od uživatele zazněly, zde nyní vypíšu:


V prohlížeči Google Chrome byly některé položky rozházené, design nebyl kompaktní.

Po

tomto

zjištění

uživatel

pokračoval

v testování

v prohlížeči Mozilla Firefox.


Menu: některé položky prvního stupně, které se dále rozbalují, značí po najetí myší odkaz, i když se o odkaz nejedná.




Tabulka: mohla by být doplněna i o odkazy na stránky jednotlivých týmů soupeře.




Tabulka: oddělit barevně vedle řádků i sloupce, zvětšit místo pro název týmu, pokud by byl název delší.




Levý panel: vylepšit pole „Oslavenci“ v levém panelu – věk a jméno hráče by nemělo být na dvou řádkách.




Registrace: chybové hlášky překrývají kalendář, i když ho „spustíme“ jako poslední.




Registrace: při opravě chybného políčka se změna ihned nepromítne v grafickém zobrazení, resp. v dolní části se stále objevuje červený křížek a ne zelená šipka. Ta se tam ve skutečnosti ukáže až při přesunu do další části.




Registrace: sekundární pozice by neměla být omezena jen na jednu možnost, to samé platí i pro číslo na mobil.




Registrace: chybové hlášky by měly mizet hned po opuštění políčka myší, ne až po opuštění políčka kliknutím jinam.




Registrace: u nahrání obrázku by měly být vypsány akceptovatelné formáty a rozměry (ve skutečnosti se zmenšení obrázku provádí samo). Fotka by měla být nepovinná při registraci, ne každý ji bude mít ihned po ruce.




Registrace: zaregistruje to dvakrát to samé číslo, jednou s +420, jednou bez, i když jde o to samé číslo.




Po registraci se uživateli nepošle e-mailem heslo (probráno výše).

39




Celkový problém: uživatel zadal jako přihlašovací jméno s diakritikou, v jednom místě vznikl problém s kódováním.




Hlášenky: pokud uživatel zadá při vytváření zápasu do poznámek dlouhé slovo, aplikace ho nikde nezalomí a při výpisu hlášenek dojde k rozhození designu.




Hlášenky: ukazuje se anglický název dnu v týdnu (Wednesday místo středa).




Redakční systém: problémy s chybějící validací způsobily položení špatného dotazu do databáze a následné vypsání chyby u vložení zápisu z utkání.




Novinky: hezčí grafická podoba novinek, nadpis novinky vlevo místo vpravo.

Většina výtek, které tu zazněly, jsou spíše grafického nebo obsahového charakteru, jejichž náhled na stav věci je občas velmi subjektivní. U některých situací ani nečekáme, že by k nim mohlo dojít, i tak je ale dobré o nich vědět, aby se na nich do příští verze mohlo zapracovat. Ty nejvážnější, které od uživatele zazněly, jsem opravil. Co se týče redakčního systému, musíme brát v úvahu i to, že jej v budoucnu budou používat tři až čtyři uživatelé, proto určitě není v současné verzi potřeba, aby byl zajištěn tak dobře, jako veřejné části aplikace.

5.2.2 Uživatel č.2 Druhým testujícím je další hráč z týmu High Society, obránce Michal Sýkora. Michal asi sice nikdy nepracoval jako tester, ale hned po mně to je asi druhý nejaktivnější přispěvovatel na našem původním webu, proto jeho připomínky beru také velmi vážně. Zde jsou některé z výtek a doporučení, které proti aplikaci měl:


Soupiska: více informací o hráčích, i třeba jejich minulosti v jiných týmech.




Odehrané zápasy: do budoucna rozdělení podle jednotlivých sezón a soutěží, dát možnost vložit zajímavost k zápasu nebo i komentář, který k zápasu napsal náš soupeř.




Přesunout některé položky z pravého do levého a naopak.




Šedý podklad je celkově nevzhledný, více to sladit do klubových barev, černé a oranžové.




Registrace: nedat povinné nahrání fotky.

40




Redakční systém: v mnoha částech aplikace chybí formulářová validace dat.




Vkládání datumu: uživatel by chtěl datum napsat ručně, ne ho vybírat v kalendáři.




Redakční systém: popisky v poznámce jsou malým písmem, uživatel si jich nevšiml.

Uživatel dále oceňuje nápad změny aktuálního stavu i to, že se pak uživatel nemusí nahlašovat. Většina výtek opět spíše plyne ze subjektivního dojmu nebo z některých předem hlášených absencí některých sekcí. Většina připomínek tak bude zapracována až do budoucích verzí. Další nekladné názory obou uživatelů se týkaly grafického vzhledu aplikace. Bohužel vím, že nejsem a zřejmě nikdy nebudu člověk s nějakým vytříbeným citem pro umělecké cítění a hezkou stránku věci, můžu ale slíbit, že se v tom pokusím udělat během budoucích týdnů a měsíců udělat pokrok.

41

42

6 Závěr Budu-li chtít být plně upřímný, tak řeknu, že po dopsání této bakalářské práce není moje aplikace ještě zdaleka hotová. Je mi jasné, že otázek není vyřešených ještě dost, na druhou stranu oproti oficiálnímu zadání jsem si předsevzal spoustu funkcionalit navíc, které by aplikace při odevzdání možná mít nemusela. Nejde ale jen o nějaké „zaplácnutí“ bakalářské práce, ale o skutečný (!) projekt, ze kterého jak doufám budou mít moji přátelé a spoluhráči z týmu po jeho finálním dokončení radost. Navíc, mnoho důležitých požadavků dříve vytyčených jsem splnil a mnoho z toho, co jsem chtěl ve svojí aplikaci mít, už skvěle funguje, což zčásti ukázalo již uživatelské testování. Při implementaci aplikace jsem si dal záležet na tom, abych doopravdy používal to nejlepší, co nám open source svět na internetu nabízí, i proto tak obsáhlý počet použitého softwaru. To značí, že jsem na práci skutečně tvrdě pracoval a že jsem se nikdy nespokojil s ničím, dokud to nebylo tak, jak jsem chtěl a původně si vytyčil. Možná i kvůli pečlivému a občas i vyčerpávajícímu hledání toho nejlepšího a zkoumání toho aplikace zatím neumí tolik, ale to, co již funguje, stojí za to. Na velké většině zatím nedokončených komponent moje aplikace stejně příliš nestojí a pro názornou představu toho, co by tento zatím prototyp měl jednou umět, to bohatě stačí. Také lze říct, že jsem o mnoho zkušenější, než jsem byl na začátku práce. Jelikož jsem byl předhozen faktu, že si téměř všechno, jako konec konců během celého studia na VŠ, musím zjistit sám, jsem se hodně naučil a rozhodně bych si při příští podobné práci díky tomu věděl mnohem více rady. Také jsem se snažil použít co nejvíce znalostí, které už jsem měl z dřívějších předmětů, což věřím, že se mi povedlo. Nevynechal jsem snad žádný obor nebo sféru, na kterou jsem na elektrofakultě měl nějaký předmět. Doufám, že až zdárně dokončím studia, budu mít čas tyto stránky dokončit do finální podoby, kterou si náš tým rozhodně zaslouží. A pokud se jednou budeme zdárně potkávat na našem novém webu po dalším z mnoha vyhraných zápasů, budu jenom rád.

43

44

Seznam použité literatury [1] MAIA, João Prado, HAYDER, Hasin, GHEORGHE, Lucian. Smarty : PHP Template Programming and Applications. 1. vyd. Birmingham : Packt Publishing Ltd., 2006. 238 s. ISBN 1-904811-40-X

[2] Smarty.net, oficiální web a dokumentace k šablonovacímu systému Smarty [online]. 2002 [cit. 20.05.2011]. Dostupný z WWW: http://www.smarty.net/

[3] VRÁNA, Jakub. 1001 tipů a triků pro PHP. 1. vyd. Brno : Computer Press, a.s., 2010. 456 s. ISBN 978-80-251-2940-1

[4] jQuery.com, oficiální web a dokumentace k JavaScriptové knihovně jQuery [online]. 2010 [cit. 20.05.2011]. Dostupný z WWW: http://jquery.com/

[5] DibiPHP.com, dokumentace k databázovému layeru Dibi [online]. 2008 [cit. 20.05.2011]. Dostupný z WWW: http://dibiphp.com/cs/

[6] PHP.net, dokumentace k programovacímu jayzku PHP [online]. 2001 [cit. 20.05.2011]. Dostupný z WWW: http://php.net/

45

46

Seznam použitého softwaru [1] Mozilla Firefox + Firebug [https://addons.mozilla.org/cs/firefox/addon/firebug/] [2] Dibi 1.5rc [http://dibiphp.com/cs/] [3] TinyMCE 3.4.2 [http://tinymce.moxiecode.com/] [4] PSPad [http://www.pspad.com/cz/] [5] ER Modeller 4.23 [http://service.felk.cvut.cz/courses/X36DBS/additions/web_ERM/] [6] Form Validation Engine 2.0 [http://www.position-absolute.com/] [7] Mozilla Firefox + HTML Validator [http://users.skynet.be/mgueury/mozilla/] [8] PHP Simple HTML DOM Parser [http://simplehtmldom.sourceforge.net/] [9] Google Spreadsheet Helper Class [https://github.com/farinspace/googlespreadsheet] [10] Zend Gdata Client Library [http://framework.zend.com/download/gdata] [11] jQuery datePicker [http://www.kelvinluck.com/assets/jquery/datePicker/] [12] jQuery autocomplete [http://bassistance.de/jquery-plugins/jquery-pluginautocomplete/] [13] jQuery tablesorter [http://tablesorter.com/docs/] [14] jQuery imgPreview [http://james.padolsey.com/javascript/new-jquery-pluginimgpreview/] [15] tinyautosave [http://code.google.com/p/tinyautosave/] [16] jQuery truncator [https://github.com/renderedtext/jquery.truncator.js] [17] jQuery SimplePager [http://www.geckonewmedia.com/blog/2009/8/20/simplepager---jquery-paging-plugin-updated] [18] PHP Image Upload [http://www.atwebresults.com/php_ajax_image_upload/] [19] PHP Mailer [http://phpmailer.worxware.com/] [20] Smarty 3.06 [http://www.smarty.net/] [21] jQuery 1.5.1 [http://jquery.com/]

47

[22] Wampserver [http://www.wampserver.com/] [23] My Little Forum [http://mylittleforum.net/] [23] GIMP [http://www.gimp.org/] [24] Facebook LikeBox [http://developers.facebook.com/docs/reference/plugins/likebox/] [25] jQuery Fancy Sliding Form [http://tympanus.net/codrops/2010/06/07/fancysliding-form-with-jquery/] [26] jQuery Animated Form Switching [http://tympanus.net/codrops/2011/01/06/animated-form-switching/] [27] jQuery Animated Menu [http://apycom.com/] [28] Google Docs [https://docs.google.com/#home] [29] Poslatsms.cz [http://poslatsms.cz/] [30] SimpleTest [http://www.simpletest.org/]

48

49

Seznam použitých zkratek PKFL – Pražská klubová fotbalová liga PSMF – Pražský svaz malého fotbalu CMS – Content Management System XSS – Cross-site scripting WYSIWYG – What I See Is What You Get AJAX – Asynchronous JavaScript and XML CSS – Cascading Style Sheets (X)HTML – (exTensible) HyperText Markup Language DOM – Document Object Model PHP – Hypertext Preprocessor FTP – File Transfer Protocol MySQL – My Structured Query Language PDF – Portable Document Format CAPTCHA - Completely Automated Public Turing test to tell Computers and Humans Apart SMS – Short Message Service

50

51

Struktura přiloženého CD


/sql

- složka obsahující soubor pro vytvoření databáze




/www

- složka obsahující veškeré zdrojové soubory




/doc

- složka obsahující bakalářskou práci ve dvou různých formátech (.doc a .pdf) a obrázky použité v práci v plném rozlišení




/prg




readme.txt - soubor s instrukcemi pro zprovoznění aplikace

- složka obsahující programy potřebné pro nasazení aplikace

52

53

Přílohy Příloha 1 – Levá část databázového modelu

Obr. č. 2 – Levá část databázového modelu, plně vybarvená kolečka atributů značí povinné atributy, nevybarvené nepovinné atributy, obdélníčky či někdy kosočtverce značí entity.

54

Příloha 2 – Pravá část databázového modelu

Obr. č. 3 – Pravá část databázového modelu, plně vybarvená kolečka atributů značí povinné atributy, nevybarvené nepovinné atributy. Kompletní obrázek v plném rozlišení najdete také na přiloženém CD.

55

Příloha 3 – Ukázka aplikace

Obr. č. 4 – Ukázka průběžného stavu jedné ze sekcí aplikace. Obrázek v plném rozlišení můžete nalézt i na přiloženém CD.

56