Na tomto místě bude oficiální zadání vaší práce

Na tomto místě bude oficiální zadání vaší práce • Toto zadání je podepsané děkanem a vedoucím katedry, • musíte si ho vyzvednout na studiijním oddělení Katedry počítačů na Karlově náměstí, • v jedné odevzdané práci bude originál tohoto zadání (originál zůstává po obhajobě na katedře), • ve druhé bude na stejném místě neověřená kopie tohoto dokumentu (tato se vám vrátí po obhajobě).

i

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Pracovní výkaz Bc. Tomáš Lucovič

Vedoucí práce: Ing. Jan Šedivý CSc.

Studijní program: Otevřená informatika, Navazující magisterský Obor: Softwarové inženýrství a interakce 11. května 2012

iv

Poděkování Rád bych poděkoval panu Ing. Janu Šedivému CSc. za velice odborné vedení diplomové práce. Jeho racionální a pragmatický pohled na věc byl pro mne velkým přínosem nejen pro moji diplomovou práci.

v

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 Praze dne 11. 5. 2012

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

Abstract The work deals with problems of time tracking on software projects. The goal is to to create a web application application for user-friendly and easy to record time tracking with accent to maximum accuracy and minimum requirements for users. The system will work with Pivotal Tracker the Agile project management tool based on Scrum method. The system will be adapted for use in cloud infrastructure and ready to use on smartphones and tablets.

Abstrakt Práce pojednává o problematice evidence odpracovaného času na softwarových projektech. Cílem práce je vytvořit webovou aplikaci pro snadnou a uživatelsky příjemnou evidenci času s důrazem na maximální přesnost a minimální nároky na uživatele. Systém bude spolupracovat se službou Pivotal Tracker pro řízení agilních projektů metodou Scrum. Systém bude uzpůsoben pro nasazení do cloud infrastruktury a připraven na využití na smartphonech a tabletech.

vi

Obsah 1 Úvod 1.1 Proč potřebujeme měřit čas . . . . 1.1.1 Evidence práce . . . . . . . 1.1.2 Účtování klientů . . . . . . 1.1.3 Finanční odměna - výplata 1.1.4 Zpřesnění odhadů . . . . . . 1.1.5 Proč se využívá HNS . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

1 1 1 2 2 2 2

2 Popis problému 2.1 Specifikace požadavků . . . . . . 2.2 Existující řešení . . . . . . . . . . 2.2.1 Excelovská tabulka . . . . 2.2.2 MS Project . . . . . . . . 2.2.3 Pivotal Tracker . . . . . . 2.2.4 Basecamp . . . . . . . . . 2.2.5 Redmine . . . . . . . . . . 2.2.6 Souhrn existujících řešení

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3 3 4 4 4 5 5 5 5

. . . . . . . .

3 Analýza a návrh řešení 3.1 Srovnání webové a desktopové aplikace 3.1.1 Desktopová aplikace . . . . . . 3.1.2 Webová aplikace . . . . . . . . 3.1.3 Zhodnocení typu aplikace . . . 3.2 Návrh uživatelského rozhraní . . . . . 3.3 Schéma komunikace . . . . . . . . . . 3.4 Návrh databáze . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 6 6 6 7 7 7 8

4 Výběr technologií a nástrojů 4.1 Client side technologie . . . 4.1.1 JavaScript . . . . . . 4.1.2 Adobe Flash . . . . 4.1.3 Microsoft Silverlight 4.1.4 HTML5 a CSS3 . . . 4.1.5 Zhodnocení . . . . . 4.2 Server side technologie . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

9 9 9 10 10 10 10 11

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

vii

. . . . . . .

OBSAH

viii

4.2.1 Java EE . . . . . . . . . . . . . . . . . 4.2.2 PHP . . . . . . . . . . . . . . . . . . . 4.2.3 Ruby on Rails . . . . . . . . . . . . . . 4.2.4 ASP.NET . . . . . . . . . . . . . . . . 4.2.5 Výběr technologie . . . . . . . . . . . Správa zdrojového kódu, knihoven a databáze Databáze . . . . . . . . . . . . . . . . . . . . 4.4.1 Relační databáze . . . . . . . . . . . . 4.4.2 Dokumentové databáze . . . . . . . . 4.4.3 Objektová databáze . . . . . . . . . . 4.4.4 Zhodnocení databáze . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

11 12 12 12 12 14 14 14 15 15 15

5 Realizace 5.1 TimeSheet . . . . . . . . . . . . . . . . . . . . 5.1.1 Inicializace a setup projektu . . . . . . 5.1.1.1 Nastavení gitu a githubu . . 5.1.1.2 Nastavení a práce s databází 5.1.2 Registrace a přihlašování uživatelů . . 5.1.3 Propojení s Pivotal Tracker . . . . . . 5.1.3.1 API . . . . . . . . . . . . . . 5.1.3.2 WebHook . . . . . . . . . . . 5.1.4 Evidence času . . . . . . . . . . . . . . 5.1.5 Emailing . . . . . . . . . . . . . . . . . 5.1.6 XMPP . . . . . . . . . . . . . . . . . . 5.1.7 Responsible design . . . . . . . . . . . 5.2 Cloud computing . . . . . . . . . . . . . . . . 5.2.1 Rozdělení . . . . . . . . . . . . . . . . 5.2.2 Výhody . . . . . . . . . . . . . . . . . 5.2.3 Nevýhody . . . . . . . . . . . . . . . . 5.2.4 Heroku PaaS . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16 16 16 19 20 21 22 22 23 24 25 26 27 28 29 29 30 30

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

32 32 32 32 33 33 33 34 34 35 36 36 37 37 38

4.3 4.4

6 Testování 6.1 Kategorie testů . . . . . . . . . . . . . . . 6.1.1 Statické a dynamické testování . . 6.1.2 Černá a bílá skříňka . . . . . . . . 6.1.3 Automatické a manuální testování 6.1.4 Stupně testování . . . . . . . . . . 6.1.5 Pokrytí testy . . . . . . . . . . . . 6.2 Testování Ruby on Rails aplikace . . . . . 6.2.1 Unit testování . . . . . . . . . . . . 6.2.2 Functionální testování . . . . . . . 6.2.3 Integrační testování . . . . . . . . 6.2.4 RSpec . . . . . . . . . . . . . . . . 6.2.5 Shrnutí testování . . . . . . . . . . 6.3 Cucumber - BDD . . . . . . . . . . . . . . 6.4 Uživatelské testování . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OBSAH

ix

6.4.1

6.5

Uživatelské scénáře . . . . . . . . . 6.4.1.1 Scénář č. 1 . . . . . . . . 6.4.1.2 Scénář č. 2 . . . . . . . . 6.4.2 Uživatelské testy . . . . . . . . . . 6.4.2.1 Marek . . . . . . . . . . . 6.4.2.2 Tomáš . . . . . . . . . . . 6.4.2.3 Jirka . . . . . . . . . . . . 6.4.2.4 Ed . . . . . . . . . . . . . 6.4.3 Výslekdy uživatelského testování . Testování UI na tabletech a smartphonech

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

38 39 39 39 39 40 40 40 40 41

7 Závěr

42

A Seznam použitých zkratek

45

B Návrh uživatelského rozhraní aplikace

47

C Instalační a uživatelská příručka 51 C.1 Požadavky na spuštění . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 C.2 Spuštění aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Seznam obrázků 3.1 3.2

Výchozí obrazovka přihlášeného uživatele . . . . . . . . . . . . . . . . . . . . Schéma komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8

4.1 4.2 4.3

Nejsledovanější repositáře . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Zastupení pluginů ve webových prohlížečích . . . . . . . . . . . . . . . . . . . 10 Vyhledávání jazyků na googlu . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1 5.2

Sekvenční diagram evidence času . . . . . . . . . . . . . . . . . . . . . . . . . 25 Přehled cen heroku databází . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1

Obrázky obrazovky iPadu při různé orientaci displeje . . . . . . . . . . . . . . 41

B.1 Wireframy přihlašovací obrazovky . . . . . . . . . . . . . . . . . . . . . . . . . 48 B.2 Wireframy obrazovek hlavních odkazů . . . . . . . . . . . . . . . . . . . . . . 49 B.3 Wireframy projektových obrazovek . . . . . . . . . . . . . . . . . . . . . . . . 50

x

Seznam tabulek 4.1 4.2 4.3

Přehled client site technologií - desktop . . . . . . . . . . . . . . . . . . . . . . 11 Přehled client site technologií - mobilní platformy . . . . . . . . . . . . . . . . 11 Srovnání webových technologií . . . . . . . . . . . . . . . . . . . . . . . . . . 13

xi

Kapitola 1

Úvod V rámci každého softwarového projektu je potřeba evidovat čas, který byl na daném projektu stráven. Eviduje se především počet hodin programátorské, anlytické či manažerské práce vynaložených na splnění konkrétních cílů vytyčených pomocí milníků. Pokud se jedná o rozsáhlý projekt s fixní cenou, tak je evidence času zjednodušena, protože vývoj probíhá delší období, někdy i několik let. Stačí pouze sečíst hodiny pracovní doby jednotlivých programátorů, kteří se na daném projektu podíleli. Tuto dobu mají programátoři většinou uvedenou v pracovní smlouvě 8 hodin denně 5 dní v týdnu. Jeden programátor může pracovat současně na více projektech a to i např. v rámci jednoho dne. Odhadnout, kolik hodin strávil na projektu A a kolik hodin strávil na projektu B je bez evidence velmi těžké. Programátor je během své práce natolik soustředěný, že na vyplnění výkazů velice často zapomene. Jejich vyplňování někdy i několik dní zpětně vede k nepřesným údajům. Při využití agilního způsobu vývoje softwaru se platby uskutečňují dle odvedené práce na jednotlivých stanovených úkolech. Toto je další důvod podrobnější evidence. Evidenci navíc nepotřebujete pouze pro potřeby fakturace, ale také pro potřeby vlastního vyhodnocování odvedené práce a budoucích odhadů.

1.1

Proč potřebujeme měřit čas

Potřeba evidence odvedené práce formou pracovního výkazu vychází z několika odlišných způsobů využití:

1.1.1

Evidence práce

Softwarové společnosti mají většinou pro potřeby řízení softwarových projektů nasazený tiketovací systém. Tyto systémy se nazývají Project management information system a patří mezi ně např. JIRA, Basecamp, Pivotal Tracker, Redmine. V těchto programech evidují požadavky na daný projekt a přiřazují je svým programátorům, kteří jsou přiděleni na daný projekt. U každého takto zadaného úkolu se zjišťuje jakou dobu trvalo vyřešení tohoto úkolu. To umožňuje kontrolu, kdo jak dlouho na kterém úkolu pracoval.

1

KAPITOLA 1. ÚVOD

1.1.2

2

Účtování klientů

Většina softwarových společností účtuje úpravy programů svým klientům podle počtu hodin strávených nad danou změnou. Pro tyto potřeby je možné také využít evidence času, kdy každý požadavek klientů je evidován jako jednotlivý úkol. Při dokončení úkolu je k tomuto úkolu přiřazen čas, který je následně účtován klientům. Účtování podle počtu odpracovaných hodin se také využívá v agilním způsobu řízení projektů. Na začátku každé iterace se stanoví úkoly. Souhrnný čas strávený nad jednotlivými úkoly dané iterace je po skončení iterace účtován klientům. Tento způsob má také pozitivní vliv na cash flow jak klienta tak softwarové společnosti.

1.1.3

Finanční odměna - výplata

Na trhu práce existuje velké množství tzv. freelancerů, kteří se nechají najímat na určité úkoly. Tito lidé jsou většinou placeni na fakturu podle počtu odpracovaných hodin. Mohou tak pracovat pro více společností naráz. Tito lidé potřebují vést evidenci kolik hodin pro jakou společnost již odpracovali a kolik hodin si mají za poskytnuté služby vyúčtovat práce. To samé potřebuje také vědět společnost co si je najala na konkrétní práci.

1.1.4

Zpřesnění odhadů

Údaje uložené v evidenci práce je možné následně vyhodnocovat a využívat k přesnějším budoucím odhadům. Pokud se nějaká část funkcionality opakuje, tak je možno využít již zjištěných hodnot pro přesnější odhad. Např. při využití tříbodového odhadu se průměrná doba, kterou daná funkcionalita trvala minule se využívá jako jeden z parametrů. Může se jednat např. o integraci platební brány, CRUD určitého modelu, či implementace přihlašování. Každé z těchto využití má svá specifika a je potřeba s nimi také tak pracovat. Proto není možné tyto údaje evidovat a zobrazovat v rámci jednoho pohledu. Pro každé využití je potřeba jiný pohled.

1.1.5

Proč se využívá HNS

Hodinová nákladová sazba (HNS) je v dnešní době jedním z nejvýznamnějších nákladových ukazatelů podniků. Spojuje totiž dva klíčové faktory a to kapacitu zdrojů programátorů a jejich cenu. Je tedy propojen časový odhad s odhadem finančním. Lze snadněji sledovat vytížení jednotlivých pracovníků a jejich mzdové náklady. Hodinovou nákladovou sazbu je možné stanovit také pro dobu běhu serverů, zvláště při využití cloudových služeb. U programátorů může sloužit také pro motivaci a porovnání výkonnosti. U softwarových projektů se dá říci, že cena je přímo úměrná počtu hodin strávených na daném projektu.

Kapitola 2

Popis problému Z důvodů, popsaných v minulé kapitole 1, vyplývají požadavky na systém s evidencí času. Je potřeba pro každý úkol evidovat čas daného uživatele. Pro účtování klientů je potřeba tento čas evidovat v rámci jednotlivých iterací, či požadovaných úprav. Z finanční odměny je potřeba mít možnost získání přehledu práce daného uživatele. Pro zpřesnění odhadů potřebuje mít evidenci opakujících se úkolů. Problém se ale netýká pouze informací, které je potřeba v systému uchovávat, ale také ve způsobu jejich zadávání. Programátoři jsou většinou natolik zaměřeni na tvorbu zdrojového kódu, že evidenci času zanedbávají a vyplňují ji zpětně. Zpoždění někdy může dosahovat i několika dní, což znamená zvýšení pravděpodobnosti zanesení chyby. Proto je potřeba vyplňovat veškeré údaje nejen přesně, ale také vyplňovat je rychle, jednoduše a uživatelsky příjemně. Dále je potřeba na neevidovaný čas upozornit. Pokud programátor nezaeviduje čas rovnou, tak se k dané evidenci již nedostane a pokud ano tak ji vyplní nepřesně. Další požadavek je, aby daný systém byl maximálně dostupný, tzn. aby do něj mohl nahlížet a upravovat v něm uložené údaje téměř odkudkoliv. Tomuto požadavku vyhovuje webová aplikace, která je dostupná odevšad, kde je přístup k internetu. Lze tedy využít i chytré telefony, případně tablety, pro dokončení evidence. Ne vždy je možné přiřadit čas konkrétnímu úkolu, ale je potřeba tento čas zaevidovat. Z tohoto důvodu je potřeba mít možnost evidence času mimo zadané úkoly.

2.1

Specifikace požadavků

• Evidence času na jednotlivých projektech aby bylo možné sledovat čas strávený na jednotlivých projektech • Evidence času na jednotlivých úkolech aby bylo možné účtovat čas strávený na jednotlivých požadavcích klientů a v rámci jednotlivých iterací při agilním vývoji • Evidence času jednotlivých lidí aby bylo možné vytvářet pracovní výkazy jako podklad pro výplatu mzdy či odměny za provedenou práci

3

KAPITOLA 2. POPIS PROBLÉMU

4

• Dostupnost evidence aby uživatelé mohli nahlížet, upravovat evidenci, kdykoliv a kdekoliv • Evidence času mimo definované úkoly ne každý strávený čas jde popsat úkolem, ne každý je programátor s přiřazenými úkoly • Upozornění na neevidovaný čas pokud uživatel zapomene na evidenci času, tak je dobré mu to znovu připomenout • Jednoduchá, rychlá evidence programátor nemá čas se zabývat zdlouhavou evidencí odpracovaného času • Evidence úkolů z různých systémů v dnešní době programátoři pracují s velkým množstvím systémů, proč neevidovat tento čas dohromady

2.2

Existující řešení

Pro řešení problematiky evidence času existuje velké množství řešení. Každé řešení má vlastní softwarovou podporu.

2.2.1

Excelovská tabulka

Toto řešení je jedno z nejběžnějších, protože jeho nasazení a integrace do již stávající infrastruktury je jednoduchá. Uživatel má k dispozici tabulku v excelu, kde každý měsíc je reprezentován jedním listem. Uživatel následně vyplňuje datum, počet hodin a popis práce, kterou odvedl. Tento způsob je vhodný především pro vyúčtování výplaty daného zaměstnance. Výkazy jsou na konci obdobní zaslány vedoucím a na jejich základě je vyplacena odměna. Při využití např. Google docs <docs.google.com> nebo Office 360 je možné odstranit i problém dostupnosti daného výkazu. Může tak být sdílen mezi více lidmi. Nevýhodou tohoto řešení je chybějící evidence odpracovaného času na jednotlivých úkolech či projektech. Pokud programátor pracoval např. na více projektech, tak se obtížně rozděluje, který čas náleží kterému projektu. Tento způsob evidence je vhodný pro jednotlivého zaměstnance, či praktikanta na praxi. Jeho nespornou výhodou je jednoduchost nasazení.

2.2.2

MS Project

Program pro řízení projektů MS Project umožňuje plánovat čas jednotlivých zdrojů na jednotlivých projektech. Přiřazovat jednotlivé zdroje na dané úkoly a sledovat jejich vytížení v čase. Nevýhodou tohoto řešení je dostupnost. Jedná se o desktopovou aplikaci, která neumožňuje přímé zadávání stráveného času jednotlivými uživateli. Pro tyto potřeby je nutná evidence přímo na daném PC kde je problém dostupný. Toto řešení nevyhovuje z hlediska dostupnosti. Navíc zadávání času v tomto rozhraní je komplikované. Tento program je vhodný především pro manažery, kterým výsledky jsou hlášeny jinou cestou, než prostřednictvím programu pro evidenci času.

KAPITOLA 2. POPIS PROBLÉMU

2.2.3

5

Pivotal Tracker

Pivotal Tracker je nástroj pro Agilní řízení projektů metodikou Scrum. Je dostupný jak přes interaktivní webové rozhraní, tak jako aplikace pro chytré telefony a tablety. Samotný systém poskytuje možnost manuální evidence času, stráveného na jednotlivých projektech. Další možností evidence času je měření doby mezi začátkem úkolu a jeho ukončením. Pivotal tracker totiž disponuje stavovým automatem pro stav jednotlivých úkolů. Z logů, nebo z reportů jde tento čas získat. Bohužel programátoři nejsou dostatečně důslední ve změně stavu jednotlivých úkolů. Občas zapomenou ukončit práci na daném úkolu. Tím se celé hodnocení znehodnocuje. Navíc tento způsob měření není propojen do systému evidence času, který je integrovaného přímo v Pivotal Trackru. Tento nedostatek se projeví např. při účtování klientů po jednotlivých sprintech. Data je nutno získat z jiného zdroje. Tento program se hodí pro řízení agilních projektů, je dostupný na mnoha zařízeních a práce s ním je intuitivní. [13]

2.2.4

Basecamp

Basecamp je webová aplikace pro projektové řízení, která umožňuje evidenci času. Zadávání času je možné dvěma způsoby. Buď se čas eviduje přímo k danému úkolu, nebo se eviduje mimo veškeré úkoly. Evidenci stráveného času musíte pro každý tzv. To-Do list explicitně zapnout. Systém poskytuje dobré uživatelské rozhraní s přehledným zobrazením, ke kterým úkolům byl již čas zadán a ke kterým ještě zbývá zadat. Chybí zde upozornění, pokud uživatel zapomněl čas k danému úkolu vyplnit a nutnost explicitního povolení evidence času na každém to-do listu zvlášť. [3]

2.2.5

Redmine

Redmine je webová aplikace pro projektové řízení stejně jako Basecamp. Vyznačuje se jiným přístupem řízení projektů. Evidence času je zde vytvořena pomocí rozšíření. Můžete zde evidovat čas strávený nad konkrétním úkolem. Nemůžete zde evidovat čas mimo zadané úkoly, musíte si tedy pro evidenci času vytvořit nový úkol, což při práci obtěžuje. Systém neposkytuje zasílání upozornění na chybějící údaje v evidenci času. [8]

2.2.6

Souhrn existujících řešení

Ani jedno z předešlých existujících řešení neposkytuje možnost zasílání upozornění na neevidovaný čas. Je to způsobeno především tím, že systém evidence času slouží pouze jako následná evidence. Veškeré systémy jsou zaměřeny především na evidenci času v rámci svého systému a neexistuje společný způsob evidence více systémů dohromady. Samotné systémy po uživatelích nevyžadují zadávání doby a v některých případech je jeho zadání opravdu obtížné. Proto jsem jsem se rozhodl vytvořit vlastní systém, který bude možné propojit s více systémy a bude zasílat upozornění na evidovaný čas.

Kapitola 3

Analýza a návrh řešení Z předešlého popisu problému vyplývá 2, že aktuálně neexistuje řešení, které by vyhovovalo zadaným kritériím. Proto je potřeba vytvořit novou aplikaci, která bude poskytovat evidenci času na jednotlivých projektech, úkolech. Bude rozdělovat čas podle konkrétních uživatelů, dostupná 24/7 pro každého uživatele. Umožní evidence mimo definované úkoly a upozornění na zapomenuté evidování úkolů. Evidence úkolů z různých systémů a především jednoduchá interakce. Řešení je možné pomocí desktopové nebo webové aplikace.

3.1

Srovnání webové a desktopové aplikace

Srovnávací kritéria těchto dvou aplikací jsou: • uživatelská dostupnost • spolupráce s dalšími aplikacemi • aktualizace aplikace

3.1.1

Desktopová aplikace

Desktopová aplikace je ve většině případů závislá na konkrétní platformě, pro kterou je určena. Z hlediska dostupnosti je k dispozici na konkrétních počítači, na kterých je nainstalovaná, tzn. pro využití na smartphonech a tabletech je nutné vytvořit speciální aplikaci. Data jsou uložena v dané aplikaci a pro jejich centrální správu je potřeba napsat serverovou část a vyřešit synchronizaci dat. K aktualizaci aplikace je ve většině případů nutná ruční interakce uživatele, nebo automatického updatu.

3.1.2

Webová aplikace

Webová aplikace je zcela nezávislá na platformě, při využití zásady responsible design je vhodná k využití jak na tabletu, tak na smartphonu. Veškerá data jsou uložena na centralizovaně na serveru. Jejich dostupnost je výborná z jakéhokoliv internetového prohlížeče.

6

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

7

Spolupráce s dalšími aplikacemi je jednodušší na implementaci (při využití zásad REST architektury). Aktualizace aplikace a případné opravy chyb je možné provádět bez nutnosti interakce uživatele. Dále je možné využít výhody Cloud computingu.

3.1.3

Zhodnocení typu aplikace

Z předešlého popisu vyplývá, že realizace je možná oběma typy aplikace. Webová aplikace má menší nároky na implementaci (není potřeba implementovat synchronizační a aktualizační části aplikace), má výbornou dostupnost a zpřístupnění na tablety a smartphone je otázkou dodržení konvencí.

3.2

Návrh uživatelského rozhraní

Cílem aplikace je minimalizovat komplexní zadávání odpracovaných úkolů. Uživatel aplikace by neměl postřehnou, že daný čas zadává. Uživatel běžně komunikuje pomocí emailu a instant messagingu. Proto v návrhu uživatelského rozhraní jsou primárně využity tyto způsoby interakce s uživatelem. Typický příklad interakce uživatele je následující. Uživatel provede změnu v tiketovém systému. Tiketový systém pošle upozornění o provedené změně. Systém proaktivně vyžádá údaje o odpracovaném času uživatele pomocí emailu, nebo instant messagingu. Uživatel ve zprávě bude mít předvyplněné možnosti zadání času např. 1 hodinu. Tyto předvyplněné možnosti budou odkazy do systému evidence času a na základě jejich zobrazení se uloží zadaný čas. Uživatel tedy nemusí pro evidenci času otevírat jinou aplikaci. U ostatních běžných aplikací je potřeba vyplnit minimálně počet hodin a popis daného úkolu. Výhody tohoto řešení: • proaktivní aplikace • 1 klik vyplňování času • API pro zadávání času Hlavní část uživatelského rozhraní je email a instant messaging. Dále je potřeba navrhnout uživatelské rozhraní webové aplikace. Tato aplikace bude primárně sloužit reportování zadaného a úpravě již zadaného času. Z požadavků vyplývá snadná orientace v uživatelském rozhraní. Po přihlášení uživatele do aplikace uvidí přehled své odpracované práce v součtu za odpracovaný měsíc a v rámci jednotlivých dní 3.1. Zde uvedené dny si uživatel může editovat. Celkový přehled navrženého uživatelského rozhraní je uveden v příloze č. B Návrh uživatelského rozhraní aplikace. Rád bych zdůraznil, že hlavním uživatelským rozhraním je email a IM klient daného uživatele.

3.3

Schéma komunikace

Na sekvenčím diagramu komunikace komponent 3.2vidí použité tři komponenty a uživatele. Uživatel provede změnu v tiketovém systému Pivotal Trackeru, pomocí WebHooku se změna dostane do aplikace Time Sheet, kde je zpracována a odeslána uživateli ve formě emailu. Uživatel na základě svého emailu zaeviduje čas. [5]

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

8

Obrázek 3.1: Výchozí obrazovka přihlášeného uživatele

Obrázek 3.2: Schéma komunikace

3.4

Návrh databáze

Návrh databáze je dobré rozmyslet u rozsáhlých komplikovaných projektů, nemusí se jednat přímo o databázový model, ale například doménový model dané aplikace. Tento model by měl nejlépe odpovídat požadavkům a měl by být flexibilní v budoucím rozšiřování. Z tohoto důvodu přenechávám návrh a tvorbu databáze do fáze realizace. Z datového pohledu se nejedná o složitý úkol evidence času daných lidí na daných projektech. V dnešní době již existují nástroje pro snadnou změnu databázového schématu a existují i databáze, které nejsou závislé na schématu tzv. NoSQL. Výběr databáze a technologií je popsaný v následující kapitole 4.4.

Kapitola 4

Výběr technologií a nástrojů Z analýzy vyplývají požadavky na vysokou dostupnost 24/7 formou webové aplikace. Vývoj webové aplikace se rozlišuje na dvě části. Tzv. Client side (většinou zastoupená pomocí webového prohlížeče) a Server side (webový / aplikační server).

4.1

Client side technologie

Základní technologie pro vývoj client side webové aplikace je HTML a CSS. Společně s těmito technologiemi se používá skriptovací jazyk Java Script a pluginy Flash, Microsoft Silverlight. V poslední době je velice populární budoucí nový standard HTML5 a CSS3, který rozšiřuje stávající standard o funkce dnes řešené pomocí pluginů. Jelikož projekt plánuji využívat i na mobilních zařízeních jako jsou tablety a smartphony, tak kritériem pro výběr technologie na client site bude podpora napříč prohlížeči a všemi platformami včetně mobilních.

4.1.1

JavaScript

JavaScript je skriptovací jazyk, jehož autorem je Brendan Eich ze společnosti Netscape. V prosinci 1995 byl představen jako doplněk HTML a Java. JavaScript se spouští až po stažení dokumentu na straně uživatele. Využívá se především pro zvýšení interakce s uživatelem a zlepšení user experience. Pro zjednodušení psaní JavaScript kódu existují knihovny, které obsahují často využívané funkce. Mezi takové knihovny patří např. Prototype, jQuery. Samotnou kapitolou je asynchronní JavaScript sloužící ke komuniObrázek 4.1: Nejsledovanější repositáře kaci se serverem bez nutnosti načítání celého webového dokumentu. Existují také tzv. JavaScript frameworky, které slouží k vytváření tzv. single site aplikací (aplikace, které se jednou načtou a zbytek komunikace je formou AJAX requestů). Příkladem takové aplikace

9

KAPITOLA 4. VÝBĚR TECHNOLOGIÍ A NÁSTROJŮ

10

jen např. Gmail. Mezi takové frameworky patří např. Google web toolkit, Ember.js, Ext JS, Backbone.js a další. JavaScript je možné použít i na straně serveru. V dnešní době je velice populární Node.js podle statistiky populárních repositářů na serveru github.com 4.1 [1] JavaScript je podporovaný ve všech moderních webových prohlížečích včetně jejich mobilních verzí.

4.1.2

Adobe Flash

Obrázek 4.2: Zastupení pluginů ve webových prohlížečích

Adobe Flash plugin se využívá k tvorbě animací, videa a interaktivních webových stránek. Díky němu se na internetu masově rozšířilo video v čele s nejznámějším portálem . Je velice populární pro tvorbu reklamních bannerů. Programování se provádí v jazyku ActionScript, který vychází ze stejného standardu jako JavaScript. Dle statistik z roku 2011 [4] byl flash dostupný na 99 % počítačů s přístupem na internet viz. obrázek 4.2 Adobe Flash je dostupný téměř na všech desktopových PC, na některých typech chytrých telefonů se systémem Android a na některých tabletech. iPhone a iPad podporu Adobe Flash nemají.

4.1.3

Microsoft Silverlight

Plugin od společnosti Microsoft na tvorbu Rich internetových aplikací a distribuci multimediálního obsahu. Plugin je dostupný pro veškeré desktopové webové prohlížeče napříč platformami. Podle měření StatOWL [12] byl plugin nainstalován na 67.33 % počítačů. Na mobilním poli bude mít podporu na Windows Phone 7 a nových Windows 8 tabletech.

4.1.4

HTML5 a CSS3

Nové standardy pro HTML a CSS nahrazují neduhy staré specifikace jazyků pro tvorbu webových stránek. Umožňují přehrávání videa, zvuku a her např. pomocí html canvas. Pro jejich využití není potřeba instalovat dodatečné pluginy, které bývají kontrolovány jednou organizací. Jedná se o standard vytvářený konsorciem W3C. Tato technologie podporuje moderní prohlížeče, včetně těch, které jsou dostupné na mobilních zařízeních (telefonech, tabletech). Výchozí webový prohlížeč na Androidu nemá plnou podporu těchto technologií.

4.1.5

Zhodnocení

Jediné řešení podporované ve všech platformách a systémech je využití HTML a JavaScriptu. Proto jsem si zvolil tuto technologii pro implementaci. Více viz tabulka Přehled client side


Technologie JavaScript Adobe Flash Microsoft Silverlight HTML5 CSS 3

IE8 ANO ANO ANO NE

IE9 ANO ANO ANO ANO

Firefox ANO ANO ANO ANO

11

Chrome ANO ANO ANO ANO

Safari ANO ANO ANO ANO

Tabulka 4.1: Přehled client site technologií - desktop Technologie JavaScript Adobe Flash Microsoft Silverlight HTML5 CSS 3

Safari iOS 5 ANO NE NE ANO

Android 2.1 browser ANO Pouze vybrané NE Pouze vybrané

Windows Phone 7.5 ANO NE ANO ANO

Tabulka 4.2: Přehled client site technologií - mobilní platformy

technologií 4.1 / 4.2

4.2

Server side technologie

Technologií pro vývoj webové aplikace je v dnešní době velké množství, pro účely této práce bylo provedeno srovnání a výběr technologie, která bude pro vývoj této aplikace nejvhodnější. Základním požadavkem na server side webovou technologii je využívání návrhového vzoru MVC (model-view-controle), který se využívá pro vývoj webových aplikací. Mezi další požadavky patří centralizovaná správa použitých knihoven. Tímto požadavkem předejdeme situaci, kdy po nás program chce danou knihovnu a my nevíme, z jakého serveru jsme ji stáhli. Srozumitelný jazyk. Objektově relační mapování databáze. Testovací framework. Rychlost vývoje.

4.2.1

Java EE

Java Platform, Enterprise Edition (Java EE) je jednou z hlavních technologií pro tvorbu rozsáhlých enterprise webových aplikací. Pro tvorbu využívá návrhový vzor MVC, pro správu použitých knihoven je možné využít maven , který ovšem nebývá standardní konfigurací nové aplikace. Jako objektově relační mapování je možné využít několik technologií (Hibernate , JPA a další). Jazyk programovacího jazyka JAVA je dosti rozsáhlý a masivní. Z pohledu testování, lze využít Unit test. Rychlost vývoje je dovozená od nutnosti téměř vždy překládat daný kód do bytekódu.


4.2.2

12

PHP

PHP je skriptovací jazyk, což mu umožňuje rychlý vývoj. S využitím např. Zend frameworku je možnost využít také MVC patern. Pro ORM je možné využití knihovny propel, která není součástí frameworku a je nutné ji konfigurovat zvlášť. Jedná se o skriptovací jazyk, který do svého začátku nebyl navržen jako objektově orientovaný. K testování možno využít unit test. Správa použitých knihoven je možná pomocí upraveného bundleru z Rails frameworku. Z hlediska vývoje stačí interpret php skriptu.

4.2.3

Ruby on Rails

Ruby on Rails je z vybraných technologií nejnovější. Je založena na Skriptovacím objektovém jazyku Ruby a frameworku Rails , který byl speciálně navržen pro vývoj webových aplikací. Má v sobě obsažené ORM v podobě ActiveRecord a podporu pro ukládání historie databáze pomocí tzv. migrací. Obsahuje v sobě testovací framework rspec, který se zaměřuje na unit testování modelů, controlerů a view. Správa použitých knihoven je zajištěna pomocí Bundleru . Jazyk je skriptovací a dává přednost konvenci před konfigurací. Vede tak k psaní snadno pochopitelného kódu. Součástí frameworku je aplikační server pro testování aplikace. Z pohledu testování umožňuje využít například akceptační framework cucumber.

4.2.4

ASP.NET

Je určen především korporátním zákazníkům, kteří již využívají služby a produkty společnosti Microsoft. Z hlediska ORM disponuje dotazovacím jazykem LINQ. Pro správu použitých knihoven je možné využít maven určený pro ASP . Z hlediska rychlosti výkonu se jedná o kompilovací jazyk s překladem do bytekodu. K testování je kromě NUnit testu možno využít nástroje pro testování webu.

4.2.5

Výběr technologie

Z uvedeného popisu vyplývá, že každá z těchto technologií je vhodná pro vývoj pokročilých webových aplikací označovaných jako WEB 2.0. Při výběru jsem vzal v potaz statistiky vyhledávání jednotlivých frameworků na google za posledních 6 měsíců viz. obrázek 4.3a. Dále jsem uvažoval o jazyku s budoucností dalšího vývoje. Dle statistik serveru Tiobe 4.3b je na vzestupu JavaScript. Již dříve uvedený obrázek 4.1 nejvíce sledovaných repositářů na serveru má také svoji vypovídající hodnotu. Aplikace není určena primárně pro korporátní uživatele jako enterprise řešení. Proto bych z výběru vyřadil jak ASP.NET tak Java EE. Rozdíl mezi PHP + Zend framework a Ruby on Rails je v dodávaných technologiích. Rails obsahují veškeré potřebné vlastnosti přímo ve frameworku, naproti tomu PHP má většinu požadovaných vlastností formou přídavných pluginů s nutností konfigurace. Proto jsem si pro realizaci zvolil technologii Ruby on Rails.


Požadavek MVC Správa knihoven ORM Testovací framework Enterprise řešení

Java EE - Spring ANO ANO ext. ANO ANO ANO

PHP - Zend ANO NE NE ANO NE

13

Ruby on Rails ANO ANO ext. ANO ext. ANO NE

ASP.NET ANO ext. NE ANO ANO ext. ANO

Tabulka 4.3: Srovnání webových technologií

(a) Vyhledávání webových frameworků na Googlu

(b) Vývoj programovacích jazyků

Obrázek 4.3: Vyhledávání jazyků na googlu


4.3

14

Správa zdrojového kódu, knihoven a databáze

Vývoj každého projektu zabíhá občas do slepých větví vývoje. Proto je nutné udržovat historii zdrojových kódů, použitých knihoven a stavu databáze, aby bylo možné se k některé z předešlých verzí vrátit. Pro správu knihoven existuje knihovna (gem) bundler . Jedná se o knihovnu, která pomocí jednoho příkazu nainstaluje příslušné knihovny specifikované v souboru Gemfile. Hlídá závislosti jednotlivých knihoven. Umožňuje specifikovat konkrétní verze, či repositáře ze kterých má být daná verze stažena. O databázi se stará ActiveRecord, což je knihovna pro objektově relační mapování databáze. Vytváření databáze v Rails frameworku je doporučeno tzv. "from top". Specifikuje se jak má daná databáze vypadat pomocí tzv. migration scriptu. Spuštěním tohoto skriptu dojde k inicializaci ActiveRecordu, připojení do databáze a vytvoření dané tabulky, případně databáze. Rails jsou připraveny na běh aplikace ve více prostředích a proto při vytvoření nového projektu rovnou vytváří tři vývojová prostředí production, development a test. Podle názvu lze snadno odvodit, k jakému účel se používají. Pro každé prostředí můžete specifikovat, jaké knihovny se mají použít, která databáze se má využít, či jaký emailový smtp server bude sloužit k posílání emailů. Pro správu zdrojového kódu je vhodné využití source code management. Mezi dnes využívané patří CVS , Subversion a Git . První dva jmenované jsou tzv. centralizované systémy s jedním centrálním úložištěm, kde se veškerá data synchronizují oproti jedinému úložišti. Poslední jmenovaný Git je čím dále více rozšířený. Jedná se o decentralizovaný systém ve kterém není potřeba centrální úložiště a spolupracující vývojáři mají možnost mergovat jednotlivé branche navzájem od sebe. Většina Ruby on Rails projektů vyžívá verzovací systém git a službu Github pro jeho sdílení a archivaci. Proto jsem se rozhodl využít Git jako verzovací systém a Github pro jeho uchovávání. Github neslouží pouze k uložení zdrojových kódů. Slouží také jako sociální prvek v programování.

4.4

Databáze

Při výběru databáze jsem požadoval ověřené řešení ORM a pohodlnou práci se schématem.

4.4.1

Relační databáze

Relační databáze využívají jazyk SQL pro dotazování nad uloženými daty. Běžně používané databáze jsou sqllight, MySQL, PostgreSQL, SQL Server, DB2, Oracle. Vztahy mezi jednotlivými tabulkami datového schématu jsou řešeny pomocí primárních a cizích klíčů. Schéma databáze by mělo být min. ve 3. normální formě a mělo by obsahovat integritní omezení z něho vyplývající. SQL relační databáze jsou využívané již přes 30 let. Pro odproštění od SQL existují tzn. Objektově relační mapovaní databáze, ve kterých za pomoci frameworku přistupujete k databázi jako ke kolekci objektů. Pro vybranou technologii Ruby on Rails existuje ORM v podobně ActiveRecord. Tato knihovna poskytuje kromě ORM také evidenci schématu databáze a možnost vytváření tzv. migračních skriptů, které umožňují přechod z jednoho stavu schématu do jiného.


4.4.2

15

Dokumentové databáze

Dokumentová databáze je NoSQL databáze, kde každý záznam je chápán jako dokument, který má ID. Data ukládá do formátu BSON, což je binární JSON. Dotazovací jazyk této databáze je JavaScript. Dokumentová databáze je výhodná pro jednoduché aplikace, u kterých není důležitá architektura či schéma. Není vhodná pro velké robustní aplikace s podporou případných transakcí, či trigrů. Nejznámější a nejvyužívanější jsou databáze MongoDB a CouchDB . Obě mají ORM framework, který je ovšem stále ve fázi vývoje a jeho spolehlivost je nejistá.

4.4.3

Objektová databáze

Objektová databáze je integrovaná s programovacím jazykem a využívá se pro ukládání programátorských objektů. Pro ruby neexistuje ověřený driver na objektovou databázi. Např. VelocityDB . Proto není vhodné tuto databázi využít.

4.4.4

Zhodnocení databáze

V úvahu připadají buď relační nebo dokumentové databáze. Jelikož Relační databáze jsou k dispozici delší dobu, tak jsou ověřené a existuje k nim velké množství nástrojů. Ruby on Rails poskytuje gem (knihovnu) Active Record, která poskytuje ORM SQL databáze. Dále poskytuje migrace pro udržování historie schématu. Celý postup vytváření a dotazování do databáze je odstíněn od jazyka SQL. Oproti tomu Mongo DB má ovladač, který je stále ve vývoji a vyskytují se v něm chyby častěji než v ověřeném Active Record, který je navíc součástí Rails instalace. Proto jsem se rozhodl pro Active Record.

Kapitola 5

Realizace V rámci realizace bude popsán vývoj webové aplikace Time Sheet sloužící k evidenci času stráveného na projektech evidovaných v Pivotal Trackeru. V rámci realizace budou představeny použité technologie a nástroje. Aplikace bude postavena na platformě Ruby on Rails. Jako databáze byla zvolena MySQL. Pro správu správu zdrojového kódu git a server github <"http://github.com/"> pro jeho cloud zálohu. Pro správu závislostí bude využit Bundler <"http://gembundler.com/">. Pro vyzkoušení reálného chování aplikace bude využita cloud application platform Heroku <"http://www.heroku.com/">.

5.1

TimeSheet

Postup vývoje se bude skládat, z úvodní inicializace projektu a následné implementace jednotlivých požadavků. Pro potřeby řešení jsou využity další knihovny. V průběhu vývoje budou představovány postupy vývoje Ruby on Rails aplikace.

5.1.1

Inicializace a setup projektu

Jazyk Ruby a jeho framework rails je využíván převážně z příkazové řádky. Pro vývoj Rails aplikace existuje minimum IDE a v rails komunitě převažuje preference textových editorů, které využívají zvýrazňování syntaxe ruby a dalších použitých jazyků. Syntaxe jazyka je daleko méně mluvná, než je tomu u enterprise jazyků Java, C#. Pro vývoj je potřeba mít nainstalovaný interpret jazyka ruby. Instalace závisí podle platformy kterou chcete využívat. Před samotnou instalací je doporučené využít rvm (ruby version manager) <"https://rvm.io/">. Tento version manager umožňuje souběžnou instalaci více verzí ruby, přepínat mezi nimi a udržování nainstalovaných knihoven v domovském adresáři uživatele. Je to výhodné především pokud pracujete na více projektech, které využívají různé verze Ruby. Pro vývoj této aplikace bylo zvoleno Ruby 1.9.2 p180, které bylo v době začátku vývoje aplikace (září 2011) aktuální verzí. Po správné instalaci rvm je možné pomocí jednoho příkazu instalovat Vámi požadované verze ruby. $ rvm install 1.9.2

16

KAPITOLA 5. REALIZACE

17

Po instalaci ruby interpretu potřebujeme nainstalovat gem (knihovnu) rails. Tento gem je jádrem vyvíjené aplikace. Slouží ke generování aplikací, spouštění serverů atd. Instalaci provedeme pomocí příkazu: $ gem install rails Nyní můžeme využít tento gem a vygenerovat základní kostru aplikace. $ rails new time-sheet Vznikne projekt s pevně stanovenou strukturou, kterou má každý rails projekt. Filosofie této technologie je konvence před konfigurací. Takto vygenerovaný projekt je možné přímo spustit příkazem: $ rails s Spustí se server WEBrick, který je přibalen rovnou s ruby. Aplikace běží na http://localhostu:3000, což je také standard každé nově vytvořené rails aplikace. Port je samozřejmě možné změnit. Každý vytvořený projekt obsahuje tři přednastavená prostředí • Production • Development • Test Pro každé z těchto prostředí je možné nastavit vlastní databázi, smtp server, knihovny které budou použity. Např. v produkčním prostředí nepotřebujte knihovny pro testování atd. K tomuto nastavení se dále ještě dostaneme. Struktura rails aplikace je následující: |||||||||||||-

app - hlavní aplikační kód Gemfile - obsahuje definice použitých knihoven Gemfile.lock - obsahuje list všech knihoven a jejich závislostí README - informační soubor o projektu config - konfigurační soubory aplikace db - schéma databáze včetně migrací doc - dokumentace aplikace lib - knihovny modulů public - veřejné dokumenty dostupné v prohlížeči script - skripty aplikace např. spuštění serveru spec - adresář testů tmp - dočasné soubory vendor - kód třetích stran pluginů a gem

K obsahu jednotlivých adresářů se dostaneme podrobněji v průběhu vývoje. Ruby on Rails jsou založeny na MVC paternu, proto v adresáři app naleznete složky pojmenované models, controlers, views, ve kterých jsou umístěny soubory příslušné vrstvy.


18

Framework dává přednost konvenci před konfigurací, proto např. pro projecs_controlleru odpovídají pohledy umístěné v adresáři app/views/projects/ pojmenované podle jednotlivých akcí daného kontroleru např. index, create, atd. Soubor Gemfile slouží k udržování závislostí použitých gemů (knihoven) a jejich verzí. Gemy se mohou zapisovat do různých skupin a načítat při různých příležitostech např. různé knihovny pro testování, vývoj a produkční běh. Proto se použitá knihovna uvádí buď na začátek dokumentu, pro použití ve všech prostředích, nebo do skupiny test či development. Tímto je zajištěno, že knihovny pro vývoj a testování se nedostanou do produkčního běhu aplikace. Definice knihoven probíhá pomocí klíčového slova gem , . Pokud není verze gemu uvedena vždy se nainstaluje nejnovější verze. Tento způsob není doporučený, protože může dojít k aktualizaci knihovny, které je využívána a součástí aktualizace bude odstranění určité metody nebo chování, které aplikace očekává. Instalace definovaných knihoven se provádí pomocí utility Bundler <"http://gembundler.com/"> vyvoláním příkazu: $ bundle install v adresáři projektu. Během instalace se kontrolují závislosti jednotlivých gemů mezi sebou a stahují se jak definované gemy, tak jejich závislosti. Stahování probíhá z adresy , která obsahuje poslední ověřené verze knihoven. Knihovny se neinstalují přímo do projektu jako tomu bývá u jiných platforem. Při nasazení jsou stahovány v průběhu deploy. Knihovny je také možné definovat pomocí git repositáře např. na serveru github. To se hodí pokud Vám například nevyhovuje používaný gem, tak si můžete udělat jeho fork (vlastní clon) a vlastní modifikaci. Po skončení stahování všech gemů se vytvoří soubor Gemfile.lock, který obsahuje seznam všech nainstalovaných knihoven včetně závislostí. Config adresář obsahuje nastavení aplikace, jejich jednotlivých prostředí ve kterých může být aplikace spuštěna. Nastavení jazykových překladů, databáze a inicializačních skriptů pro různé komponenty třetích stran. Důležitým souborem je routes.rb, který obsahuje nastavení směrování url požadavků na příslušné kontrolery. Přehled nastavení routování aplikace je možné zobrazit pomocí příkazu: $ rake routes Adresář db obsahuje poslední schéma databáze. Soubor se seedy, který může obsahovat vzorová, či inicializační data v databázi. Ve složce migrate jsou obsaženy migrate skripty. Ty slouží k udržování historie schématu databáze. Každá migrace obsahuje předpis změny schématu pokud přechod provádí dopředu, či se vrací k určitému staršímu schématu. Pro práci s databází se využívá gem Active Record, který poskytuje ORM databáze a návrh databáze probíhá pomocí migrací from top z aplikace se vytvoří tabulky dle definice migrace. Adresář doc obsahuje generovanou dokumentaci pomocí příkazu $ rake doc:app Public adresáře obsahuje statické stránky dostupné v aplikaci, css styly, JavaScripty a chybové stránky 404, 500, 422. Dále jsou zde uchovány obrázky, ty byly ovšem v novější verzi přesunuty do složky app/assets.


19

Adresář rspec obsahuje testy modelů, controlerů. Pro testování je využit jazyk rspec, případně Test::Unit který bude detailněji vysvětlen v sekci testování 6.2. Lib adresář obsahuje knihovny instalovaných modulů. Adresář scripts skripty spouštěné v konkrétní čas např. pomocí příkazu cron a tmp adresář obsahuje dočasné soubory jako cashe, čísla procesů, session a využité sockety. V rámci této kapitoly byly převzaty informace z [10] 5.1.1.1

Nastavení gitu a githubu

Git je distribuovaný revizní systém sloužící k uchování zdrojových kódů, jejich historie a změn. Byl vyvinut Linusem Torvaldsem pro správu Linuxového jádra. Každá pracovní složka gitu obsahuje veškerou historii změn kódu, takže je nezávislá na centrálním úložišti. Pro git existuje spousta služeb pro uchovávání obsahu repositářů online. Nejznámější je server github.com <"http://github.com/">, který umožňuje i interakci mezi jednotlivými programátory a poskytuje zdarma hosting pro open source projekty. Pro nastavení gitu je potřeba vyplnit informace o sobě. Tyto informace se použijí jako podpis každého commitu. $ git config --global user.name "Your Name" $ git config --global user.email [email protected] Základní čtyři příkazy pro práci s gitem jsou: • git clone - stažení git adresáře z remote branche • git pull - stažení změn v aktuálním repositáři • git commit - uložení změn do SCM • git push - odeslání commitů do remote úložiště Každý z těchto příkazů obsahuje další parametry pro upřesnění dané činnosti. Pro jejich zjištění je možné využít manuálové stránky. Jelikož tento projekt je vyvíjen od základu je potřeba inicializovat git v tomto adresáři příkazem: $ git init Tím se vytvoří adresář .git , který bude uchovávat veškeré revize a informace potřebné pro práci gitu. Nyní pomocí příkazu $ git add . přidáme veškerý obsah adresáře do repositáře. Důležitý je soubor .gitignore, který obsahuje seznam souborů, které mají být vynechány z revizního procesu. Nyní pomocí příkazu git commit provedeme první commit. Pro případ havárie disku, či laptopu je vhodné git adresář zálohovat do cloud prostředí. K tomu poslouží server github.com. Pro jeho využití je potřeba mít zde založený účet a v účtu přidán svůj veřejný klíč. Pokud je vše připraveno tak stačí git repositáři říci, kde má svůj domovský adresář.


20

$ git remote add origin [email protected]:<username>/first_app.git $ git push -u origin master Výhodou gitu je snadná práce s různými větvemi a možnost více drobnějších commitů bez nutnosti provádět změny v originálním repositáři. Během vývoje nejste závislí na centralizovaném úložišti. 5.1.1.2

Nastavení a práce s databází

Rails framework umožňuje definovat databázi pro každé prostředí. Připojení k databázi je možné přes socket, nebo port. Konfigurace pomocí socketu na localhostu může vypadat následovně: adapter: mysql2 encoding: utf8 reconnect: false database: time_sheet_development pool: 5 username: root password: heslo123 host: localhost Důležité je jak v nastavení připojení do databáze tak i v konfiguracích uvádět kódování utf8. V opačném případě se vyskytují problémy s kódováním při zobrazování uložených dat z databáze na html stránce. Jak bylo popsáno výše, tak pro práci s databází se využívají dva gemy. Mysql2, driver pro připojení k databázi a ActiveRecord, který slouží ke správnému ORM. Definice databáze se provádí pomocí tzv. migrate skriptů, které se převedou do SQL a vytvoří příslušné schéma databáze. Velkou výhodou tohoto přístupu je historie stavu databáze.[7] Tzn. pokud máte například dvě verze aplikace tak můžete pomocí jednoho příkazu přecházet z jednoho stavu databáze do druhého. Navíc například při využití scaffoldingu je při vytváření zdroje vytvořeno view, controler, model a migrační skript, který přidá požadované tabulky do databáze. Toto vede k velice rychlému vývoji aplikace. Objektově relační mapování využívá konvence. Například cizí klíče se vytvářejí jako sloupce tabulky se jménem + _id. Více o migracích a práci s databází je dostupné na <"http://guides.rubyonrails.org/migrations.html"> , kde jsou napsaná doporučení při práci s rails frameworkem. Výhodná je také existence souboru s tzv. seedy. Tento soubor obsahuje minimální data potřebná pro spuštění aplikace. Využití je např. pokud stáhnete zdrojové kódy nové aplikace a po jejím spuštění nevíte jak se do ní přihlásit. Proto existují předpřipravená data, která stačí tzv. naseedovat do databáze. Příkazy využívané při práci s databází rake db:migrate - provede migraci na na poslední verzi migrace rake db:seed - naplnění databáze seed daty rake db:reset - provede se reset databáze Aplikace nyní obsahuje veškerá potřebná nastavení.


5.1.2

21

Registrace a přihlašování uživatelů

V aplikaci je požadovaná registrace, autorizace uživatelů. Napsání nového autorizačního schématu je zdlouhavé a proto je lepší využít již ověřené knihovny devise <"https://github. com/plataformatec/devise">. Tento gem se stará jak o registraci, tak o autorizaci uživatele. Jeho instalace se provede přes přidání gemu do Gemfilu a spuštění bundleru, aby se daný gem nainstaloval. Instalací tohoto gemu se přidá generátor. Tímto generátorem se nainstalují příslušné modely a kontrolery pro práci s uživateli. Pro dokončení instalace stačí spustit tyto tři příkazy: rails generate devise:install rails generate devise rake db:migrate Tímto získáte registraci do systému velice rychle, tento gem v sobě obsahuje registraci nového uživatele, ověření existence daného uživatele, přihlášení, odhlášení, vytvoření session a obnovu hesla. Ve výchozím nastavení je vyžadováno potvrzení emailu kliknutím na potvrzovací odkaz v emailu. Tomu se dá předejít při instalaci devise pomocí vypnutí modulu Confirmable. Devise za nás také řeší správu hesla uživatele, hašovací funkci včetně solení s využitím časové známky. Hesla se tedy neukládájí v plain verzi, ale pouze jejich hash. Do aplikace není potřeba zavádět oprávnění či role uživatelů. Ty jsou definované pomocí přístupu k projektům v Pivotal Trackru. Proto je potřeba přidat každému uživateli možnost nastavit své přístupové údaje ke službě Pivotal Tracker. Pomocí příkazu na scaffolding vytvoříme nový resource settings.[7] $ rails generate scaffold Settings pt_name:string pt_api_key:string Tímto příkazem se nám vygeneruje CRUD (create, read, update, delete) zdroj podle RESTového přístupu. Vytvoří se pohledy, kontroler, model i migrace databáze. Tu je možné spustit pomocí již dříve použitého příkazu: $ rake db:migrate Nyní máme dostupné na URL /settings list všech nastavení, můžeme přidat nové nastavení, upravit jej či smazat. Nyní je potřeba propojit nastavení s uživatelem. K vytvoření relace mezi dvěma modely je potřeba definovat vztah v jednotlivých modelech. Tzn. v modelu settings je potřeba definovat, že náleží právě jednomu uživateli a v modelu User, že má právě jedno nastavení. To provedeme přidáním řádky belongs_to :user do modelu settings a has_one :setting do modelu user. Toto nastavení předpokládá existenci sloupce user_id v tabulce settings. Posledním krokem je vytvoření tohoto sloupce pomocí migrace databáze. Výsledná migrace bude vypadat takto: class AddUserItToWork < ActiveRecord::Migration def self.up add_column :works, :user_id, :integer, :null => false end


22

def self.down remove_column :works, :user_id end end Jsou zde vidět dvě metody self.up a self.down, které slouží k přechodu mezi jednotlivými stavy schématu databáze. Nyní se již můžeme na nastavení dotazovat přímo z objektu uživatele, např. current_user.setting.pt_name nám vrátí Pivotal Tracker jméno aktuálně přihlášeného uživatele. [7]

5.1.3 5.1.3.1

Propojení s Pivotal Tracker API

Z předešlé sekce 5.1.2 máme k dispozici uživatele s nastavením potřebným pro propojení s Pivotal Trackrem. V této části práce se zaměříme na vytvoření komunikace mezi aplikací a systémem pro správu úkolů. Pivotal tracker poskytuje API (Aplikaction programing interface) pro přístup k projektům, uživatelům atd. Popis API je dostupný na <"https: //www.pivotaltracker.com/help/api?version=v3"> . Je možné získávat seznam všech projektů, všech story pro daný projekt, či tzv. activity feed, který obsahuje poslední aktivity. Jedná se o REST API využívající http protokol.[14] Pro práci s API je vhodné využít již předpřipravené knihovny. Pro ruby existuje gem, který se jmenuje pivotal-tracker a obsahuje funkcionalitu pro práci s Pivotal Tracker. Vývoj gemu je možné sledovat na githubu <"https://github.com/jsmestad/pivotal-tracker"> . Podle statistik se commitů se jedná o živý projekt, který je udržovaný. Instalace gemu se provádí stejně jako v předešlých kapitolách. Název gemu se včetně verze zapíše do Gemfile a spustí se bundler, který nainstaluje příslušný gem. Nyní můžeme v konzoli vyzkoušet připojení funkce gemu. Jelikož je ruby skriptovací jazyk, umožňuje spuštění interpretu a vyzkoušení si chování funkcí a metod. Interpret spustíme příkazem: $ irb # načteme použitý gem 1.9.2p180 :001 > require ’pivotal-tracker’ # zadáme API token 1.9.2p180 :002 > PivotalTracker::Client.token = ’7b9d3829a097cf4b770d4d13ab30e4f4’ # Vyhledání konkrétních projektů 1.9.2p180 :005 > @projects = PivotalTracker::Project.find(242503) # Vyhledání story na již definovaném projektu 1.9.2p180 :005 > @project.stories.find(847762630) # Opuštění interpretu 1.9.2p180 :005 > exit V rámci tohoto API jsou důležitá ID projektu a story. Naším cílem je vytvořit rozhraní pro evidenci času nad jednotlivými story a projekty. Každý uživatel si bude moci zobrazit seznam všech svých projektů. Jeho projekty jsou definované jako projekty v Pivotal tracker,


23

ke kterým má přístup jako člen. Potřebujeme vytvořit nový resource Projects. U toho resource není potřeba evidovat data do databáze, v první verzi můžeme data získávat ad hoc. Kešování je možné implementovat v další verzi. Proto vygenerujeme nového resource $ rails generate scaffold Projects Takto vygenerovaný kód obsahuje jak controler s předem připravenými metodami, tak jednotlivé pohledy. Nyní v kontroleru stáhneme projekty daného uživatele z pivotal trackeru pomocí jeho zadaného API klíče, možnost vytváření nových a jejich editace je ve správě Pivotal trackru, proto se tyto metody mohou odstranit. Dále je potřeba po kliknutí na vybraný projekt zobrazit seznam story příslušný danému projektu. Opět na stránce detailu projektu zobrazíme seznam jeho story. A v detailu dané story bychom měli je zobrazen přehled kolik na daném úkolu bylo stráveno. 5.1.3.2

WebHook

Pivotal tracker umožňuje specifikovat pro každý projekt URL na které se bude posílat Activity WebHook. WebHook je HTTP POST požadavek, který se odešle v definovaný okamžik s definovanými daty. Příklad PivotalTracker Webhooku 1031 175 <event_type>story_update 2009/12/14 14:12:09 PST James Kirk <project_id type="integer">26 <description>James Kirk accepted "More power to shields" <stories> <story> 109 https:///projects/26/stories/109 2009/12/14 22:12:09 UTC <current_state>accepted Data jsou v tomto případě posílána pomocí URL. Výhodou aplikace time-sheet oproti ostatním aplikacím pro logování času je její proaktivnost. Nečeká, až uživatel zaeviduje jakou práci odvedl, ale sama se uživatele zeptá, kolik času na daném úkolu strávil. Z tohoto activity hooku jsme schopni rozpoznat kdo danou aktivitu provedl, k jakému projektu a úkolu story patří, jaký úkol daný uživatel řešil. Pro příjem této aktivity potřebujeme definovat URL na kterém budeme dané aktivity přijímat a v kontroleru získat potřebné údaje, které si přejeme evidovat. Z požadavků vyplývá, že si přejeme evidovat kolik času strávil dotyčný na daném úkolu. Proto si pro dané informace vytvoříme tabulku activity. V tabulce activity


24

budeme evidovat aktivity, které nám přišly z Pivotal Trackru. Z důvodu zjednodušení autorizace uživatelů a ulehčení evidence jejich času bude možné evidovat čas pomocí jednoho kliknutí bez nutnosti přihlášení do palikace. Proto bude pro každou aktivitu vygenerován hash, který ji bude jednoznačně identifikovat a bude použit k autorizaci dané aktivity. Další překážka, která je potřeba řešit, je párování uživatelů. Jelikož activity WebHook neobsahuje email daného uživatele. Navíc email uživatele se nemusí shodovat s emailem registrovaným do této služby. Proto je nutné aby uživatel kromě svého API klíče vyplnil také jméno, které má vyplněné v Pivotal trackru. Tím jej bude možné spárovat. Nyní popíši jakým způsobem aplikace zpracovává aktivitu. 1. Pivotal Tracker provede POST na definované URL s aktivitou 2. Aplikace rozparsuje přijatou aktivitu 3. Aplikace vyhledá podle zadaného jména příslušný email 4. Aplikace vygeneruje heslo dané aktivity 5. Aplikace zaeviduje danou aktivitu do databáze 6. Aplikace předá aktivitu k odeslání uživateli pomocí emailu nebo XMPP

5.1.4

Evidence času

V předešlé sekci 5.1.3 bylo popsáno jakým způsobem je možné propojení s Pivotal Trackrem. Nyní je potřeba zajistit jednoduchou evidenci času. Cílem je aby evidence byla možná pomocí jediného kliku. Proto je potřeba vytvořit URL, které bude přijímat evidovaný čas. Pro možnost podrobnější evidence budeme čas uvádět v minutách. Výsledné URL vypadá /log-time// Kde activity id je číslo přiřazené dané aktivitě a time in minutes je počet minut strávených na daném času. Tyto údaje budou zabalené do emailu a xmpp ve formátu http odkazů. Zpráva uživateli tak bude obsahovat předpřipravené hodiny. Uživatel bude mít dále možnost provést úpravu daného času přímo v aplikaci. Pro evidenci času vytvoříme nový resource Works. Ten bude obsahovat Datum, Popis úkolu, Čas v minutách a odkazy na uživatele, projekt a story. Tento resource vygenerujeme pomocí příkazu: $ rails generate scaffold Works day:date description:text \ time:integer user_id:integer story_id:integer project_id:integer Dále je potřeba vytvořit vazby mezi jednotlivými modely pomocí příkazů has_one, belong_to v definici modelu Works a User. Na sekvenčním diagramu 5.1 je znázorněn průběh zpracování požadavku na zaevidování času. Pro případ opakovaného GET požadavku na url logování času, je potřeba vytvořit příznak zaevidované aktivity. Do tabulky s aktivitami přidáme sloupec určující zdali byla daná aktivita již uložena. Přidání sloupce provedeme pomocí migrace $ rails generate migration AddFillInToActivities fill_in:boolean


25

Obrázek 5.1: Sekvenční diagram evidence času

Vytvoří se migrate skript, který přidá sloupec fill_in do tabulky aktivit. Nyní nastavíme každé aktivitě při vytváření status na false a při úspěšném uložení daného úkolu změníme aktivitě příznak z false na true. Tím zajistíme, že čas nebude evidovaný podruhé. Druhou možností, kterou je možné implementovat, je automatický přepis dané aktivity. Tato funkcionalita by dovolila jednoduše měnit uživatelem zadaný čas.

5.1.5

Emailing

Emailing je v této technologii součástí instalace frameworku. Jedná se o třídu ActionMailer, která slouží k odesílání pošty [7]. Pro testovací účely jsem si vytvořil účet na Gmailu abych mohl využít jeho poštovní servery. Komunikace s těmito servery probíhá pomocí SSL, proto je potřeba zkontrolovat, zda-li máte ruby zkompilované včetně podpory SSL. Nastavení emailové komunikace je uvedeno pro každé prostředí zvlášť. Příklad nastavení odesílání emailů na Gmail. # Disable delivery errors, bad email addresses will be ignored config.action_mailer.raise_delivery_errors = true # set delivery method to :smtp, :sendmail or :test config.action_mailer.delivery_method = :smtp


26

# these options are only needed if you choose smtp delivery config.action_mailer.smtp_settings = { :enable_starttls_auto => true, :address => ’smtp.gmail.com’, :port => 587, :domain => ’your.domain.com’, :authentication => :login, :content_type => "text/html", :user_name => ’[email protected]’, :password => ’7IAgfyDpWq67’ } Důležitý je druhý konfigurační řádek, ve kterém se definuje způsob doručení, pro testovací vývoj to může být např. localhost. Před samotným odesláním je potřeba specifikovat vzhled emailu. Pro jeho definici se mohou využívat pohledy v sekci /app/views/user_mailer/ kde může být specifikována HTML podoba emailů. Pro definici dynamického obsahu emailu je využit kontroler UserMailer, který obsahuje metody vhodné pro odeslání emailu. Text emailu je velice důležitý, v dnešní uspěchané době by měl mít vysokou vypovídající hodnotu na první pohled. Email chodí od virtuální sekretářky, která se Vás dotazuje kolik jste strávil času. Ahoj Tomáši, kolik jste strávil času na úkolu: Upravit stránku o nás. 0 hodin 1 hodina 2 hodiny 4 hodiny jiný čas. Děkuji Sekretářka Předpřipravený čas je závislý na uživateli a typu práce, kterou vykonává. Odkazy na jednotlivé hodiny jsou plánované jako http odkaz s přednastaveným časem. Například 1 hodina obsahuje odkaz na URL s časem 60 minut. Pro evidenci tedy stačí pouze jeden klik a čas je zaevidovaný, což je veliký rozdíl oproti již existujícím řešením. Žádné řešení správy času se Vás neptá a žádné řešení neeviduje čas pomocí jednoho kliknutí. Samozřejmostí je možnost Vámi zaevidovaný čas upravit.

5.1.6

XMPP

Mezi další oblíbený způsob komunikace bezesporu patří instant messaging. Mezi nejrozšířenější protokoly patří Extensible Messaging and Presence Protocol. Jedná se o otevřený protokol založený na XML, který využívají služby jako Google Talk, nebo Jabber. Výhody tohoto protokolu jsou především v jeho standardizaci a rozšíření, každý uživatel Google


27

emailu disponuje také Google talk účtem, který je postavený právě na XMPP protokolu. Pro implementaci XMPP protokolu existuje ruby knihovna xmpp4r, která umožňuje vytvořit jak jednoduchou tak HTML zprávu. Ne každý client musí podporovat HTML. Konfigurace je v porovnání s emailem komplikovanější. Pro odeslání je potřeba vytvořit klienta, který se připojí k serveru a vytvořit zprávu, kterou daný klient odešle na předem stanovený účet. Pro správný příjem zprávy je potřeba autorizovat klienta ze kterého se posílají zprávy. Pro vytváření XML zprávy je možné využít knihovny REXML pro práci s XML dokumenty. Pokud bychom chtěli poslat jednoduchou zprávu tak je možné využít odlehčené knihovny xmpp4r-simple. Gem dostupný na rubygems.org je fungující pouze pro Rails 2.3. Pro jeho správnou funkci s verzí 3 je potřeba použít přímo opravu, která je dostupná na <"https: //github.com/blaine/xmpp4r-simple.git"> zápis do Gemfilu bud vypadat následovně: gem ’xmpp4r-simple’, :git => "https://github.com/blaine/xmpp4r-simple.git" a kód pro odeslání zprávy je následovně jednoduchý im = Jabber::Simple.new("[email protected]", "password") im.deliver("[email protected]", "Hey there friend!") Možností připojení klienta je více. Takto připojený uživatel bude v IM klientovi problikávat a odpojovat se. Protože nedrží pernamentní připojení. Pro odeslání HTML zprávy je potřeba definovat XML strukturu dané zprávy.

5.1.7

Responsible design

Jeden z požadavků je vyzkoušet danou aplikaci na tabletech a smartphonech. Každé zařízení má jiné rozlišení a vždy bychom našli rozlišení na které jsme zapomněli. Proto se využívá Responsible design. První článek o Responsible designu napsal Ethan Marcotte [9]. Podle jeho definice je flexibilní web design pružná síť s pružnými obrázky která zahrnuje media queries pro vytvoření zodpovědného, přizpůsobivého layoutu. Jedná se o nový způsob myšlení při tvorbě layoutu aplikace. Pro implementaci nejsou potřeba hluboké znalosti CSS stylů. Je možné využít knihovny, které mají v sobě tyto zásady využity a držet jejich definice. Nejpopulárnější knihovnou podle serveru je twitter bootstrap [1]. Jedná se jednoduchou a flexibilní HTML, CSS a Javascript knihovnu pro vylepšení uživatelské rozhraní přívětivosti. Tato knihovna umožňuje vytvářet layouty aplikace, které jsou dostupné i na jiných zařízeních s jiným rozlišením. Tím vytvoříte jeden layout, který se přizpůsobí zařízení, které ho bude zobrazovat. Použití této knihovny je možné několika způsoby. Prvním je možné použít přímo bootstrap gem dostupný přes . Tento gem využívá CSS preprocessor Less pro zpracování zapsaných stylů. Výhodou tohoto gemu je jeho možnost snadného updatu a kombinace Vámi definovaných stylů pomocí lessu se kompiluje společně s bootstrap knihovnami. Nevýhodou je nutnost instalace CSS preprocesoru a nebezpeční zastavení vývoje daného gemu. Druhou možností je stažení statických knihoven přímo ze stránek <"http: //twitter.github.com/bootstrap/index.html">. Bootstrap v sobě obsahuje také iconset a javascript pro animace komponent. Pro svoji správnou práci potřebuje poslední verzi jQuery 1.7 [2]. Jedná se o JavaScriptový framework pro zjednodušení práce s JS. Po nakopírování příslušných souborů do public složky je nutné provést include daných souborů do


28

layoutu aplikace. Bootstrap využívá 12. sloupcový grid systém. Pro definici daného gridu se využívají různé komponenty popsané na webových stránkách [15]. Při prvním použití vypadá jako magie, ale ve skutečnosti je to kus geniální práce. Pro nasazení responsive designu je potřeba dodržet předepsané rozložení elementů div na stránce. Veškerý obsah je potřeba umístit do divu se třídou container. Tento div následně vytvoří centralizovaný layout s 940 pixely na šířku. Implementace vypadá následovně.
...
Do tohoto layoutu je následně možné vkládat jednotlivé řádky jako divy s class row, která může obsahovat divy s class span1 - span12, které definují jak široký má být daný element a jeho chování při zmenšení obrazovky. Další zajímavou možností je implementace tlačítek. Bootstrap poskytuje sedm barevně odlišených tlačítek, která mohou být vytvořena jak z odkazu, inputu, nebo submit tlačítka. Základem každé webové aplikace jsou formuláře a i ty jsou zde řešené. Nejběžnější je tzv. form-horizontal. Jak je vidět na přiloženém příkladu, rozlišují se zde popisky a ovládací pole formuláře. To umožňuje přizpůsobit formulář různým rozlišením a zařízením. Např. jednou zobrazí popisky vedle inputu, podruhé nad ním.

Legend text
Text input

Supporting help text

Kromě klasických inputů umožňuje Bootstrap pomocí z-indexu vkládat obrázky ikony rovnou do inputů či tlačítek. Výsledkem je škálovatelný vzhled formulářových polí můžete např. vytvořit input začínající znakem @ pro zadání emailové adresy, nebo tlačítko zpět včetně šipky ukazující zpět. Tyto drobnosti napomáhají uživatelské přívětivosti a orientaci v aplikaci.

5.2

Cloud computing

Cloud computing je v dnešní době jedním z často skloňovaných pojmů. Jedná se o metaforu využívanou IT firmami k popisu distribuce výpočetního výkonu a aplikací pomocí internetu. Výhody tohoto řešení jsou především úspora nákladů na pořizování softwarového vybavení


29

a IT služeb. Cloud umožňuje efektivně rozdělovat zdroje potřebné pro jednotlivé programy a služby. Což má pozitivní dopad na životní prostředí. Data jsou centralizovaná ve velkých data centrech, která jsou povětšinou stavěna v místech s dostupností tzv. zelené elektrické energie např. z vodních, či solárních elektráren. Cloud je abstrakcí technologie, zdrojů a umístění dané služby. Velkým trendem v dnešní době je přechod všech našich osobních dat do cloudu. Příkladem takového cloud úložiště můžou být například služby jako Dropbox, SkyDrive, iCloud a další. Udržují Vaše data zálohovaná a kdokoliv dostupná.

5.2.1

Rozdělení

Dělení cloud computingu je velice složité, protože každá služba má něco jedinečného. První rozdělením je podle typu poskytování cloud služeb. 1. Veřejný - služba, či zdroj je nabídnut široké veřejnosti např. Skype 2. Soukromý - jedná se o uzavřený cloud, většinou například v rámci jedné korporace 3. Hybridní - kombinuje soukromý a veřejný cloud 4. Komunitní - cloud infrastruktura je sdílená mezi více organizacemi Druhé rozdělení cloud computingu je dle distribučního modelu. Co je danou službou nabízeno. 1. Infrastructure as a Service (IaaS) V rámci tohoto typu cloudu jsou poskytovány především hardware, síťové propojení a load balancery. Typickým příkladem takovéhoto typu služby je Amazon Elastic Compute Cloud (Amazon EC2) a částečně Windows Azure 2. Platform as a Service (PaaS) v rámci PaaS je poskytováno spustitelné prostředí pro daný programovací jazyk, databáze a web server pro spuštění aplikace. Příkladem takovéhoto cloud řešení je Google App Engine, Windows Azure, Heroku, Engine Yard. 3. Software as a Service (SaaS) Zde je poskytován přímo aplikační software. Uživatel nemá přístup k prostředkům, využívá pouze službu. Příkladem takové služby je email od googlu Gmail a veškeré aplikace dostupné v Chrome webstore. [16]

5.2.2

Výhody

Cloud řešení má velké výhody, jednou z nich je například možnost sdílení výpočetního výkonu. Výkon může být rozdělen dle potřeb jednotlivých nájemců. Další výhodou je škálovatelnost a elasticita aplikace. To umožňuje budovat systémy s dostupností 24/7 i při skokovém zvýšení počtu uživatelů dané služby. Příklad mohou být například streamování sportovních utkání, ve kterém se dá očekávat počet sledujících diváků stoupající s vrcholem sportovní


30

akce. Je tedy možnost měnit zdroje dle potřeby. Z pohledu zákazníka má Cloud výhodu ve způsobu platby. Vyhnete se obrovským up-front investicím do hardwaru a připojení. Platí jen to co spotřebujete. Další výhodou jsou aktualizace systému, ty probíhají transparentně na pozadí a uživatel o nich nemusí vědět. Jelikož je přístup na cloud služby dostupný přes internet, je možné využívat tyto služby kdekoliv a díky dostupnosti 24/7 také kdykoliv.

5.2.3

Nevýhody

Mezi nevýhody cloud computingu se řadí závislost na poskytovateli. Pokud poskytovatel z jakéhokoliv důvodu přestane poskytovat služby, tak se můžete jen těžko dostat ke svým datům. Toto je problém velkých korporací, které jsou na službách IT závislé. Cloud computing je stále nový nevyzkoušený pojem, který se ještě napevno neusadil ve firemním prostředí. Další nevýhodou je lokalita, některé organizace nemohou mít své údaje mimo území daného státu, proto jsou pro ně tyto služby nedostupné. Problémy mohou také nastat s různým právním řádem různých států.

5.2.4

Heroku PaaS

Během vývoje jsem pro testování produkčního prostředí využíval cloud službu Heroku. Jedná se o typ cloud služby Platform as a Service (PaaS), což přináší snížené nároky na konfiguraci serveru a prostředí pro běh aplikace. Služba heroku se specializuje na provoz webových aplikací a služeb napsaných v technologiích Ruby, Node.js, Clojure, Java, Python, and Scala. Pro správu Vámi vytvořených aplikací je k dispozici gem heroku, který obsahuje příkazy ke konfiguraci a práci s nasazenou aplikací. Nasazení aplikace probíhá pomocí push zdrojových kódu do vzdáleného heroku repositáře. Nahraný kód se v jejich infrastruktuře zabalí do spustitelné jednotky nazvané „dyno“. Toto dyno je standalone spustitelný proces, který se spustí ve vlastním prostředí. Pro základní free verzi je k dispozici jeden běžící dyno proces na aplikaci a 5 MB sdílené databáze. Heroku poskytuje také rozšíření pro aplikace např. napojení na facebook, key-value storage, Amazon RDS atd. Heroku poskytuje API pro psaní další rozšíření a umožňuje programátorům je poskytovat za provize z jejich distribuce. Celý systém je postavený na REST přístupu ke zdrojům. Cena poskytovaných služeb je závislá od požadavků, které máte na výkon. V aplikaci si můžete koupit tzv. dyno což jsou jednotlivé webové procesy zpracovávající příchozí požadavky a tzv. workery, to jsou procesy, které vykonávají Váš kód. Každé dyno či worker stojí 0.05 USD/ hodinu. Počítají průměrně 750 hodin na měsíc což vychází 35 USD/ na jednoho workera. Jeden dyno process je zdarma. Sdílená databáze 20 GB stojí 15 USD/měsíčně. Další dedikované databáze jsou uvedeny v tabulce heroku databází 5.2. Práce s databází je možná pomocí příkazové řádky. Můžete si stáhnout aktuální databázi, případně nahrát databázi, kterou máte lokálně u sebe. Je možné také využít rake příkazů. heroku db:push - nahraje lokální databázi do databáze na heroku heroku db:pull - stáhne databázi z heroku do lokální kopie. Tyto dva příkazy je možné využít k tvorbě záloh databáze. Z pohledu logování a správy aplikace. Je možné zobrazit log dané aplikace pomocí příkazu heroku logs


31

Obrázek 5.2: Přehled cen heroku databází

A můžete také spouštět nové dyno, nebo worker procesy. Existují i nástroje pro na sledování výkonu heroku aplikace a možnosti rozšíření dělají z heroku velice škálovatelný nástroj i když se jedná o PaaS. [11]

Kapitola 6

Testování Webová aplikace může jako jakýkoliv jiný software obsahovat chyby. Počet chyb roste s rozsahem a komplexností dané aplikace. Proto je dobrou praxí psát kromě výkonného kódu také testy, které ověřují jeho správnost. Při řízení projektů pomocí metodiky Waterfall (vodopád) se ověření funkčnosti kódu provádí zpětně po fázi implementace. V této kapitole budou popsány obecné principy testování, přístup Ruby on Rails k testování, přístupy testy řízeného vývoje a vývoj řízení chováním aplikace. Budou zde představeny nástroje pro testování webových aplikací. Ke konci kapitoly bude představeno testování uživatelské rozhraní na tabletech a smartphonech.

6.1

Kategorie testů

Důležitým faktorem testování je rozhodnutí, jaké typy testů a nástrojů budou použity. Testy můžeme rozdělit

6.1.1

Statické a dynamické testování

Rozdíl statického oproti dynamickému testování je v nutnosti spustit daný kód. Statické testování nepotřebuje pro své vyhodnocení spustitelný kód a využívá se v průběhu vývoje např. pro kontrolu syntaxe kódu nebo vyhledávání duplikujícího kódu, který může v budoucnu způsobit problémy. Dynamické testování potřebuje pro své vyhodnocení spustitelný kód, definované vstupy a očekávané výstupy.

6.1.2

Černá a bílá skříňka

Další možné rozdělení testů je na tzv. Black box (černá skříňka) nebo White box testing (bílá skříňka). Rozdíl těchto dvou přístupů je podle toho, zda známe vnitřní implementaci testované části kódu. U testování černé skříňky testujeme modul pouze na základě jeho vstupů a výstupů. Oproti tomu při testování bílé skříňky známe vnitřní implementaci a můžeme jí přizpůsobit testy tak abychom dosáhli co nejvyššího pokrytí výkonného kódu testy. Dále můžeme testovat vnitřní stavy dané části kódu např. vznik vyjimek. Pro testy se hodí testovat hraniční kritéria, která při použití black box testingu neznáme. Při white box

32

KAPITOLA 6. TESTOVÁNÍ

33

testingu můžeme vstupy uzpůsobit hraničním kritériím a tím kvalitněji otestovat daný kód. White box testing je jak časově tak finančně náročnější.

6.1.3

Automatické a manuální testování

V případě, že je potřeba vyhodnocovat test na základě lidského úsudku, je potřeba využít manuální testování. Manuální testování se provádí většinou pomocí definovaných uživatelských scénářů a tester kontroluje chování aplikace v průběhu testování. Veškeré testy nejdou plně automatizovat a například grafické zobrazení elementů ve webovém prohlížeči je situace, kterou dokáže spolehlivě vyhodnotit pouze člověk. Automatizované testování se využívá především pro možnost jeho opakovaného spuštění. Bývá zpravidla levnější než manuální testy. Testy jsou popsány pomocí definovaných vstupů a výstupů aplikace. Před každým automatizovaným testem je potřeba nastavit systém do předem definovaného stavu, připravit potřebná data a prostředí. S počtem automatických testů stoupá náročnost jejich údržby. Automatické testy uživatelského rozhraní jsou velice náchylné na jeho změnu, proto se doporučuje psát tyto testy co nejvíce obecně aby na nich změna uživatelského rozhraní nebyla tak závislá.

6.1.4

Stupně testování

Dle úrovně, na které se dané testy provádějí, jsou definovány následující stupně. 1. Testování jednotek (Unit testing) U objektově orientovaného programování se jedná o testování přímo jednotlivých metod a tříd. Každá třída či metoda se testuje nezávisle na ostatních metodách a třídách dle definovaných vstupů a výstupů. Většinou se využívají Unit Test frameworky. 2. Integrační testování (Integration testing) Testuje několik vzájemně propojených jednotek nebo modulů ve vzájemné součinnosti. Například nová transakce v bance by se měla také zapsat do systému pro logování transakcí. 3. Systémové testování (System testing) Aplikace se testuje jako celek, tyto testy by měly otestovat chování aplikace v reálných podmínkách s reálnými testovacími daty. 4. Akceptační testování (Acceptance testing) Slouží k definici funkcí systému, bez kterých zákazník nepřevezme daný produkt. Mohou definovat dobu odezvy systému na jednotlivé požadavky, chování systému a požadavky, které jsou kritické pro běh aplikace.

6.1.5

Pokrytí testy

Mezi další možnosti dělení testů patří dělení podle pokrytí. Existují testy, které pokrývají určité požadavky, funkce a zdrojové kódy. Důležitou informací je, že ani 100 % pokrytí příkazů kódu, nezaručuje, že byly pokryty veškeré cesty produkčním kódem. Proto se pokrytí kódu rozděluje na


34

1. Pokrytí příkazů - pokrytí každého řádku kódu 2. Pokrytí hran - při testování podmínek, testovat vždy jak kladné, tak záporné vyhodnocení 3. Pokrytí podmínek - vyhodnocení všech vložených podčástí dané podnímky 4. Pokrytí cest - testují se všechny možné cesty kódem Testování pokrytí všech cest představuje nejúplnější možné testování. Tento způsob má své nevýhody. Počet cest roste exponenciálně a ne všechny cesty je možné vykonat v závislosti na datech. [6]

6.2

Testování Ruby on Rails aplikace

Každá rails aplikace již od svého vytvoření obsahuje připravené komponenty na testování. Vývoj v Ruby on Rails je založen na přístupu Test driven development. Při vytváření jakéhokoliv modelu, či kontroleru se rovnou vytváří příslušné soubory na jejich testování. Samotná rails aplikace má přímo definované prostředí. Development, production a test. Pro každé z těchto prostředí je možné definovat různé sady knihoven a různé databáze. Jedná se o dynamické automatizované testování přes všechny stupně testování. Po vytvoření nové rails aplikace se zároveň vytvoří adresář test, který obsahuje: test |- fixtures |- functional |- integration |- performance |- config |- test_helper.rb |- unit Tyto adresáře odpovídají jednotlivým stupňům testování. Adresář fixtures obsahuje předdefinovaná databázová data zapsaná pomocí yml souboru. Tato data se před spuštěním testu naplní do testovací databáze a je možnost je využít při testování jako výchozí. Problém nastává, pokud chceme například testovat přihlašování uživatele. Tak musíme vyplnit již hash daného hesla včetně soly. Je možné definovat více záznamů najednou a volat je v průběhu kódu. Pro vytváření testovacích dat je možné využít erb kód.

6.2.1

Unit testování

Ruby on Rails aplikace využívá pro unit testování třídu Test::Unit, která umožňuje definovat dané testy a provádět vyhodnocování výsledků. Unit testy se využívají především pro testování modelů. Například test na validaci evidence záporného času může vypadat takto.


35

# coding: UTF-8 require ’test_helper’ class WorkTest < ActiveSupport::TestCase setup do #procedura pro každý testový případ end test "should reject negative time" do time = -1 work = Work.new(:day => Date.today.to_s(), :description => "New define work", :time => 4, :user_id => 1, :time => time) assert !work.save #work.save vrátí chybu proto assert !work.save end end V jednom test souboru může být více testů, všechny dohromady mohou mít přednastavenou určitou proceduru, která se spustí před každým skriptem. Takto definované skripty spustíme pomocí příkazu: $ ruby -Itest test/unit/work_test.rb Výsledek takto spuštěného testu je buď tečka, což znamená, že test proběhl úspěšně, nebo F což znamená, že test selhal a a zobrazí se porovnání proč daný test selhal. Speciálním případem je E což znamená, že nastala chyba ve spouštění daného testu.

6.2.2

Functionální testování

Funkcionální testy slouží k testování kontrolerů. Každý test vytvoří požadavek na konkrétní kontroler a jeho akci. Na základě těchto testů je možné vyhodnocovat návratový stav nebo obsah vráceného HTML dokumentu. Kontrola HTML probíhá formou CSS selektorů a definicí textu v nich obsaženého. Můžeme tedy testovat, jestli stránka obsahuje například správný nadpis H1, nebo titulek. Respektive jestli se vyrenderovala správná šablona. U požadavku je možné si vybrat jeho typ a definovat mu jeho parametry. V práci je využito toto testování například na ověření správně evidovaného času. require ’test_helper’ class ApiControllerTest < ActionController::TestCase test "should get create" do get :log_time, activity_id: "12345", time: 60, user: "[email protected]" assert_select ’h1’, "Prace byla ulozena" assert true end end


36

Tento test při spuštění vytvoří požadavek na url /api/log_time/ s parametry activity_id, time a user. Otestuje zobrazení nadpis „Práce uložena“ a návratovým kódem 200. Dále je možno testovat data obsažená v session nebo cookies a dotazovat se na proměnné @request, @respond, @controller. Veškeré funkcionální testy by měly být uloženy v adresáři funcional.

6.2.3

Integrační testování

Integrační testy se využívají pro nasimulování uživatelského chování a práce s aplikací. Umožňují simulovat více požadavků za sebou a testovat tak flow určité aplikace. Dají se využít také např. na testování správného routování aplikace. require ’test_helper’ class UserFlowsTest < ActionDispatch::IntegrationTest test "login and browse site" do get "/users/sign_in" assert_response :success

post_via_redirect "/users/sign_in", :username => "[email protected]", :password => "he assert_equal ’/works’, path assert_response :success end end Při psaní delších integračních testů dochází k opakování kódu a proto je možno definovat vlastní DSL pomocí modulu.

6.2.4

RSpec

Jedná se o Behavior-Driven Developmnet nástroj pro ruby programátory. Cílem tohoto nástroje je usnadnit vyhodnocování testy řízený vývoj při zaměření na vytváření tzv. živé dokumentace. Vyznačuje je zjednodušenou syntaxí pro testování a čitelnějším kódem, který je srozumitelný i bez hlubokých znalostí dané problematiky. Instalace tohoto toolu se prování pomocí příkazu: $ gem install rspec-rails Ten nainstaluje rspec-core, rspec-exceptions, rspec-mocks, rspec-rails, rspec. Jedná se o knihovny, které se využívají při testování. Stejně jako Test::Unit má RSpec předdedfinované adresáře pro konkrétní typy testů.


37

spec |- controllers/ |- factories.rb |- helpers/ |- mailers/ |- models/ |- requests/ |- routing/ |- spec_helper.rb Z názvů adresářů je patrné, jaké typy testů se v nich nacházejí. Pro porovnání zápisu testů Test::Unit a RSpec poslouží příklad unit testu modelu na zadání záporného času, k odvedené práci. # encoding: UTF-8 require ’spec_helper’ describe Work do it "should reject negative time" do negative_time = -1 negative_work = Factory.build(:work, :time => negative_time) negative_work.should_not be_valid end end Tento test je snadněji čitelný. Využívá gem Factory Girl, který je určený k vytváření objektů. Umožňuje snadné vyváření definovaných objektů pomocí jejich definice v souboru factoires.rb.

6.2.5

Shrnutí testování

Testování je součástí frameworku, při využití TDD napomáhá k upřesnění definice co vše je potřeba naprogramovat. Samotný běh testů je pomalý, protože je potřeba pro každý test připravit vlastní testovací prostředí. S touto nepříjemností je možné se vypořádat pomocí testovacího serveru, který běží již připraveným testovacím prostředím a testy se spouštějí uvnitř něho. Pro budoucí testování bych doporučil využívat komplexnější rspec a tool factory girl, které zjednodušují práci s testy a umožňují daleko větší škálovatelnost testů. Pro usnadnění testování uživatelského rozhraní existuje gem capybara, který má předpřipravené pomocné funkce pro vyplňování formulářů a práci s JavaScriptem.

6.3

Cucumber - BDD

Behavior-driven development bylo poprvé představeno v roce 2003. Cílem tohoto vývoje je přiblížit testování zákazníkům. Pro tento účel se při testování webových aplikací využívá framework Cucumber. Tento nástroj umožňuje automatizované akceptační testování, vývoj


38

na základě popisu chování aplikace a představuje také živou dokumentaci. Výhodou cucumberu je možnost definování testů pomocí běžných vět napsaných v libovolném jazyku. Je potřeba pouze dodržet základní klíčová slova Given, When, Then. Pomocí řádů začínajících na slovo Given je definován stav aplikace např. „Given there is user Tomas with email [email protected]“. Řádky začínající na slovo When definují kroky, které uživatel, případně aplikace vykoná. Např. „When user open his account“. A řádky začínající příkazem Then testují konečný stav aplikace např. „Then user can see his bank balance.“ Tyto klíčové příkazy je možné přeložit do libovolného jazyka. Takto definované scénáře jsou schopni definovat i samotní zákazníci v jejich vlastním doménovém jazyku. Tento způsob definice požadavků vede k zamyšlení nad požadavkem samotným, jakým způsobem bude realizován a předchází budoucím nedorozuměním a chybám v komunikaci. Tyto definice jsou následně pomocí regulárních výrazů rozděleny do jednotlivých kroků. Tyto kroky jsou následně implementovány pomocí testových funkcí. Programátor implementuje kroky jeden po druhém, čímž se ve výsledném kódu nevyskytují zbytečné funkce a tzv. programátorské triky a zkratky. Samotné spuštění se provádí pomocí příkazové řádky příkazem $ cucumber Ten v aktuálním adresáři spustí všechny soubory s příponou .feature ve složce features. Výstupem tohoto testu jsou jednotlivé řádky scénářů validované a vyhodnocované na základě definic uvedených v testovacích krocích. V průběhu vývoje dochází k rozšiřování množiny testů psaných v doménovém jazyce dané aplikace. Z toho vyplývá, že testy slouží jako živá dokumentace toho co systém již umí nebo by měl umět. Navíc zákazníci i programátoři využívají stejný jazyk pro komunikaci mezi sebou, využívají stejné odborné pojmy z příslušné domény. Cucumber není závislý na programovacím jazyku, je možné jej použít nezávisle na typu aplikace. Navíc je možné využít selenium web-driver ke spuštění daných testů přímo v prohlížeči, což umožňuje demonstrovat možnosti dané aplikace. [17]

6.4

Uživatelské testování

Aplikace byla testována čtveřicí uživatelů. Testování probíhalo formou uživatelských scénářů simulujících reálné využití aplikace. Testování bylo prováděno v jejich pracovním prostředí uživatelé věděli, že jsou testováni.

6.4.1

Uživatelské scénáře

Uživatelské scénáře slouží testujícím uživatelům jako zadání úkolu, kterého mají na daném webu dosáhnout. Jsou psány většinou v jednotlivých krocích, tak aby uživatel mohl testovat krok po kroku.


6.4.1.1

39

Scénář č. 1

1. Zaregistrujte se do aplikace Time Sheet 2. Vytvořte si/ přihlašte se do Pivotal Trackeru 3. Zadejte nastavení do Time Sheet Váš API klíč a Pivotal Tracker jméno. dostupné na stránce profilu uživatele v PT 4. Zadejte nastavení integrace Activity Web Hook v záložce integrace projektu. Vyplňte URL: http://time-sheet.heroku.com/pt-api Verze: v3 5. Vytvořte nový úkol v Pivotal Tracker Na email dostanete upozornění o zaevidování času. 6. Pomocí emailu zaevidujte čas strávený na novém úkolu. Zobrazí se Vám stránka rekapitulace úkolu 7. Přidejte [email protected] jako přítele na službě GTalk 8. Změňte stav story v Pivotal Trackeru Pomocí zprávy GTalk zaevidujte strávený čas Protokol GTalk jse postavený na open protokolu XMPP. 6.4.1.2

Scénář č. 2

1. Přihlaste se se do svého účtu v Time Sheets 2. Zobrazte si seznam všech Vašich projektů 3. Zobrazte si seznam story daného úkolu 4. Zobrazte si detail vybraného úkolu 5. Uvidíte přehled stráveného času.

6.4.2 6.4.2.1

Uživatelské testy Marek

Muž 25 let, 3 roky programátor Ruby on Rails, bez předešlé zkušenosti s Pivotal Trackrem. Registraci do aplikace provedl bez obtíží, déle mu trvalo nalezení API klíče ve svém profilu na Pivotal Trackeru. Po přihlášení byl zmatený ohledně úvodní obrazovky, kde nebyly vyplněny jeho odpracované hodiny. Chyběli mu zde tzv. flash message. Po vytvoření nového úkolu jej email upozornil na zaevidovanou práci. XMPP nepřišel, protože je potřeba dopředu přidat uživatele [email protected] mezi přátelé, aby jej mohla kontaktovat. Při


40

evidenci času se pozastavil nad chybějícími jednotkami u údaje čas. Narazil na nefungující stránku úpravy editace uživatele. Po přidání uživatele [email protected] mezi přátele a vytvoření nové aktivity obdržel již evidovaný čas také pomocí IM. Celkově hodnotí aplikaci jako velice příjemnou. Byl potěšený možnosti evidence času bez nutnosti se přihlašovat do aplikace a to i pomocí mobilního telefonu. 6.4.2.2

Tomáš

Muž 21 let, student na praxi, několik vlastních projektů, bez předešlé zkušenosti s Pivotal Trackrem. Tomáš byl uživatel využívající platformu Linux, z tohoto pohledu bylo zajímavé sledovat, jak se aplikace bude chovat na této platformě. Uživatel se bez potíží registroval. Vyplnění nastavení nutné pro propojení aplikace hledal nejprve v uživatelském profilu, který byl v testované verzi mimo provoz. Následně našel nastavení aplikace, kam zadal požadované údaje. Email přišel téměř okamžitě a jeho obsah nebyl poničen. Byl překvapen způsobem projení aplikací. Po přidání přátele [email protected] do IM klienta přišlo také upozorní na provedenou úpravu aplikace. Z jeho pohledu aplikace chybí pouze příjemnější uživatelské prostředí. 6.4.2.3

Jirka

Muž 25 let, projektový manager a grafik, zkušenosti s programování v PHP a tvorbou grafických návrhů, bez předešlé zkušenosti s Pivotal Trackrem Registrace a přihlášení do aplikace proběhlo v pořádku. Byl překvapen, nejednoznačnosti uživatelského jména a obává se možnosti zaměnění dvou uživatelů se stejným jménem. Na formuláři vytváření nastavení mu přišlo nelogický popis tlačítka "Create settings". Nevyhovovalo mu zadávání času okamžitě po změně v Pivotal trackeru, přál by si aby se upozornění posílalo např. hodinu zpětně. Nerad by byl tímto způsobem vyrušován. V sekci projekty se mu nelíbylo grafické zpracování projektů. Doporučoval by použít tabulku. Potřeboval by filtrovat story v rámci jednotlivých projektů podle přiřazených uživatelů. Po evidenci času mu chyběly jednotky u uvedeného času. Jako grafik viděl nedostatky aplikace v jejím vzhledu. 6.4.2.4

Ed

Muž 22 let, programátor v Ruby on Rails, 4 roky praxe, zkušenosti s PT Registrace bez potíží, byl zmatený při hledání API klíče v uživatelském Profilu v Pivotal Trackru. Do nastavení zadal user name místo hodnoty name a proto jej aplikace nerozpoznala a neposlala mu upozornění. Podle jeho názoru má smysl evidovat čas k jakékoliv změně v PT. I před startem daného úkolu může být čas stráven nad konzultací jak bude daný úkol vypadat. Podle něj by bylo vhodné aby aplikace umožňovala také měření času od začátku úkolu do jeho zkončení. Nejlépe pomocí aplikace v menu.

6.4.3

Výslekdy uživatelského testování

Aplikace je podle testovaných uživatelů použitelná po programové části a propojení. Nutné je zapracovat na tělu zprávy o evidenci času a grafickém vzhledu aplikace. V těle zprávy jim


41

chyběla možnost evidovat vlastní čas buď formou formuláře, nebo odkazu na webový formulář. Klíčová funkce odesílání emailu a XMPP zpráv fungoval správně. Po grafické stránce by stálo za vylepšení stránka projektů a přidání jednotek k času v rekapitulaci evidovaného času. Vhodné je také vytvořit video či návod na používání aplikace, který by odstranil nepřesnosti např. při zadávání Pivotal Tracker name.

6.5

Testování UI na tabletech a smartphonech

Jeden z požadavků dané aplikace je její použitelnost na tabletech a smartphonech. Pro řešení tohoto problému byl použit responsible design pomocí projektu twitter bootstrap. Tento grafický vzhled je druhý nejsledovanější projekt mezi programátory registrovanými na sociální síti github.com. Výsledná aplikace se tedy přizpůsobí poměru a rozlišení displeje. Toho je docíleno pomocí dvanáctisloupcového layoutu. Aplikaci jsem testoval na počítači s rozlišením 1440 x 900 px. tak na iPadu 1. generace a na iPhone 4S. Nejvýraznější rozdíl byl v menu aplikace na iPadu při změně orientace displeje jak můžete vidět na obrázku 6.1. Při zobrazení landscape se menu

Obrázek 6.1: Obrázky obrazovky iPadu při různé orientaci displeje vešlo na daný display a zobrazilo se stejně jako na počítači. Při změně na portrait zobrazení se menu shluklo do vysouvacího menu včetně kontextového menu. Tato funkcionalita je součásti grafické šablony bez nutnosti programovat v aplikaci.

Kapitola 7

Závěr Cílem této práce bylo vytvořit systém pro jednoduchou evidenci času stráveného na projektech evidovaných v systému Pivotal Tracker. Jednoduchost celého systému spočívá v proaktivním sledování času a jeho evidenci formou jednoho kliknutí. Aplikace prošla v rámci vývoje několika verzemi. První návrh spočíval pouze ve sběru dané práce daného uživatele pro daný den, což se ukázalo jako použitelné řešení pro uživatele, nikoliv pro společnost. Proto bylo nutné systém přepracovat a rozšířit o evidenci k daným projektům a story. Druhý návrh již obsahoval evidenci času nad jednotlivými úkoly a využíval dvě oddělené komponenty Ruby on Rails aplikaci pro evidenci času a Node.js aplikaci pro komunikaci s uživatelem. V průběhu vývoje se ukázal vývoje dvou aplikací paralelně vedle sebe jako neefektivní a odchytávání chyb se stávalo stále hůře zaznamenatelné. Tento krok vedl k poznatku, že Node.js je velice nadějná technologie na vytváření webových služeb a API, je možné ji provozovat na cloud službě Heroku.com a v budoucnu bude určitě jedna z dominantních. Což potvrzuje i statistika nejvíce sledovaných projektů na serveru github.com. Pro mé potřeby bylo zbytečné řešit komunikaci mezi těmito dvěma aplikacemi. Děkuji za tuto radu svému vedoucímu panu Šedivému, který mne k této změně přivedl. Jeho argumentům ohledně údržby kódu, potřebných znalostí a debugingu aplikací jsem dal za pravdu. Poslední verze aplikace je postavena jen na technologii Ruby on Rails a přepsání dané části kódu nezabralo ani větší množství času. Aplikace je nyní v provozu v režimu beta testování ve firmě Blueberry.cz Apps s.r.o., kde je plánována k využití jako logování času na daném projektu. Z testování vyplývá, že aplikaci by prospělo vytvoření grafického návrhu aplikace a zapracovat na vzhledu emailu a IM zpráv. Vývoj pomocí vybrané technologie vidím jako úspěšný, jako laik z pohledu vývoje webových aplikací jsem se mnohé naučil a na těchto základech mohu dále stavět svůj profesní růst. Jako každá aplikace či softwarová služba není nikdy hotova a proto je zde prostor pro budoucí rozšíření. Zvýšení grafického rozhraní aplikace formou vlastního custom designu. Přidání možnosti generovat vlastní custom reporty a grafy. Propojení s dalšími systémy. Ostatní softwarové projekty nemají dostatečně příjemné logování času a proto se tento čas neeviduje, či eviduje chybně. Z mého pohledu aplikace splnila cíl, pro který byla určena. Aplikace využívá Pivotal Tracker API, které zajišťuje ACL pro jednotlivé uživatele. Použitelnosti na mobilních telefonech a tabletech je dosaženo pomocí responsible design a evidence času je možná odkudkoliv pomocí jediného kliknutí.

42

Literatura [1] GitHub Inc. Github popular watched [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: . [2] The jQuery Foundation. jQuery [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: . [3] 37signals, LLC. Basecamp [online]. 2012. [cit. 8. 5. 2012]. basecamp.com/>.

Dostupné z:
[4] Adobe Systems Incorporated. Zastoupení webových pluginů [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: . [5] ARLOW, J. – NEUSTADT, I. UML2 a unifikovaný proces vývoje aplikací. Brno, CZ : Computer Press, a.s., 2th edition, 2007. ISBN 978-80-251-1503-9. [6] BOROVCOVá, M. A. Testování webových aplikací. 2009, 2. [7] FERNANDEZ, O. The Rails 3 Way. New York : Addison-Wesley, 2th edition, 2010. ISBN 0-321-60166-1. [8] Jean-Philippe Lang. Redmine [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: . [9] MARCOTTE, E. Responsive Web Design. A Book Apart, 1st edition, 2011. [10] Michael Hartl. Ruby on Rails Tutorial [online]. 2011. [cit. 8. 9. 2011]. Dostupné z: . [11] Orion Henry, James Lindenbaum a Adam Wiggins. Heroku [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: . [12] Owl statistics. Zastoupení pluginů v prohlížečích [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: . [13] Pivotal labs, Inc. Pivotal Tracker [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: . [14] Pivotal labs, Inc. Pivotal Tracker [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: .

43

LITERATURA

44

[15] Twitter a komunita. Bootstrap [online]. 2012. [cit. 8. 5. 2012]. Dostupné z: . [16] wiki. Cloud Computing [online]. 2012. [cit. 8. 5. 2012]. wikipedia.org/wiki/Cloud_computing>.

Dostupné z:
[17] WYNNE, M. – HELLESOY, A. The Cucumber Book. Pragmatic Programers LLC., p1.0 edition, 2012.

Příloha A

Seznam použitých zkratek PMIS Project management information system PMS Project management system HNS Hodinová nákladová sazba CRUD Create Read Update Delete REST Representational State Transfer IE Internet explorer MVC Návrhový vzor model-view-controler PC Personal Computer 24/7 24 hodin denně, 7 dní v týdnu TDD Test driven development BDD Behavior Driven Development SQL Structured Query Language NoSQL No Structured Query Language IDE Integrated development environment SSL Secure Sockets Layer XMPP Extensible Messaging and Presence Protocol HTML HyperText Markup Language CSS Cascading Style Sheets JPA Java persistance api CVS Computer-controlled Vehicle System

45

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

UTF-8 UCS Transformation Format — 8-bit IE Internet explorer MVC Návrhový vzor model-view-controler IT Information technology API Application programming interface

46

Příloha B

Návrh uživatelského rozhraní aplikace Na následujících třech obrázcích je představeno 11. obrazovek aplikace. Jejich vzájemná interakce mezi nimi je znázorněna pomocí číselných odkazů. V levém sloupci je číslování obrazovek a čísla v textu jsou odkazy na konkrétní číslo obrazovky.

47

PŘÍLOHA B. NÁVRH UŽIVATELSKÉHO ROZHRANÍ APLIKACE

1. 5.

6.

3.

7.

2.

2.

5.

3.

5.

4.

Obrázek B.1: Wireframy přihlašovací obrazovky

48


5. 8.

6.

10. 10. 10.

6.

9.

9.

7.

5.

8.

5.

Obrázek B.2: Wireframy obrazovek hlavních odkazů

49


6.

9.

9.

9. 6.

10. 10. 10.

10.

9.

11.

11.

11.

10.

Obrázek B.3: Wireframy projektových obrazovek

50

Příloha C

Instalační a uživatelská příručka C.1

Požadavky na spuštění

• Ruby 1.9.2 nebo vyšší • Bundler gem 1.0 nebo vyšší • MySQL databáze

C.2

Spuštění aplikace

Aplikace je dostupná na jako open source projekt na serveru 1. Proveďte clone git repositáře git clone [email protected]:tocas/time_sheet.git 2. Nastavte databázi pomocí config/database.yml souboru 3. Nainstalujte potřebné knihovny bundle install 4. Proveďte migraci databáze rake db:migrate 5. Spusťte server rails s 6. Aplikace je dostupná na

51

Na tomto místě bude oficiální zadání vaší práce

Recommend Documents