VŠB – Technická univerzita Ostrava Fakulta elektrotechniky a informatiky
Katedra informatiky
Absolvování individuální odborné praxe Individual Professional Practice in the
Company
2018 Adam Fousek
Abstrakt
Tato bakalářská práce popisuje činnost vykonávanou během odborné praxe absolvované ve firmě Moravio s.r.o., která se zabývá vývojem webových aplikací a informačních systémů. Hlavní pra- covní náplní praxe byl rozvoj interního systému, který slouží ke komunikaci mezi klienty a od- dělením péče o zákazníky. Součástí vývoje tohoto systému bylo vytvoření databázové struktury, serverové části a webového rozhraní klientské části aplikace.
Klíčová slova: Moravio s.r.o., bakalářská praxe, PHP, framework Laravel, MySQL, JavaScript, HTML, CSS, webová aplikace
Abstract
This bachelor thesis describes my professional experience during internship at Moravio s.r.o., a development company focused on web development and development of information systems.
My temporary work assignment was to develop a part of the customer service system, including creating the database structure of the system and the web interface.
Key Words: Moravio s.r.o., thesis, PHP, framework Laravel, MySQL, JavaScript, HTML, CSS, web application
Obsah
Seznam použitých zkratek a symbolů 6
Seznam obrázků 7
Seznam výpisů zdrojového kódu 8
Úvod 9
1 Společnost Moravio s.r.o. 10
2 Pracovní zařazení 11
2.1 Firemní prostředí . . . 11
3 Základní technologie používané pro vývoj 13
3.1 Architektura . . . 14
4 Seznam úkolů přiřazených k vypracování 15
5 Zvolené řešení a systém klientské podpory 16
5.1 Systém klientské podpory . . . 16 5.2 Zvolené řešení jednotlivých úkolů . . . 17
6 Využité a scházející dovednosti 26
7 Závěr 27
Seznam použitých zkratek a symbolů
CSS – Cascading Style Sheets
HTML – HyperText Markup Language
jQuery – JavaScript library
JS – JavaScript
Laravel – PHP framework
SASS – Dynamic stylesheet language MySQL – Databáze založená na dialektu SQL
PHP – Hypertext Preprocessor
SQL – Structured Query Language
CSRF – Cross-Site Request Forgery
OOP – Object-oriented programming
6
Seznam obrázků
1 Soubor pro vytvoření databázové struktury . . . 18
2 Ukázka routy v Laravelu . . . 19
3 Ukázka využití DataGridu . . . 19
4 Ukázka výpisu DataGridu . . . 20
5 Ukázka vložení/editování záznamu do/v databáze/i . . . 21
6 Ukázka jazyka SASS . . . 22
7 Rozložení stránky vložení nového uživatele . . . 23
8 Přihlašovací stránka klienstkého systému . . . 24
9 Ukázka Slack notifikace . . . 24
10 Ukázka filtrace na Dashboardu . . . 25
Seznam výpisů zdrojového kódu
1 Vytvoření databázové migrace ve framework laravel pomocí CLI . . . 18 2 Spuštění databázové migrace . . . 18
8
Úvod
Cílem této práce je popsat pracovní náplň a přínos odborné bakalářské praxe, kterou jsem vykonal ve společnosti Moravio s.r.o.
V úvodní části práce představuji samotnou společnost, mé pracovní zařazení v rámci firemní struktury a v neposlední řadě firemní prostředí, ve kterém praxe probíhala. V kapitole 3 prezen- tuji hlavní náplň mé praxe - vývoj systému klientské podpory - a důvody, které Moravio s.r.o.
vedly k vývoji vlastní aplikace. Spolu s tím předkládám výčet nejdůležitějších technologií, se kterými jsem se setkával při řešení jednotlivých úkolů, a aplikací, které jsem se při praxi naučil využívat.
Ve čtvrté kapitole uvádím seznam vybraných větších úkolů - funkcionalit, na jejichž imple- mentaci jsem se podílel. V následující páté kapitole je popsána samotná aplikace, její účel a způsob, jakým jsem zadané funkcionality implementoval.
V závěrečné části práce je zhodnocen celý průběh odborné praxe a zkušenosti a znalostí, které jsem díky praxe nabyl.
1 Společnost Moravio s.r.o.
Moravio s.r.o. je digitální agentura, která se zabývá návrhem a vývojem webových a mobilních aplikací a informačních systémů na míru. Před rokem se společnost také rozšířila o samostatnou divizi on-line marketingu, která nabízí business poradenství, tvorbu marketingových strategií a kampaní.
Sídlo i působiště Moravio s.r.o. se nachází ve vilové čtvrti v městské části Ostrava-Hulváky.
Společnost byla založena v roce 2012 a momentálně čítá zhruba 20 zaměstnanců, z toho více než polovinu tvoří vývojáři. Mezi významné klienty a reference společnosti patří například Veolia, Ridera, Tieto, Hyundai Dymos, Notino nebo Economia. Moravio s.r.o. také spolupracuje se zajímavými klienty přímo z našeho regionu - například s Ostravskou univerzitou, Janáčkovou filharmonií nebo Sarezou.
10
2 Pracovní zařazení
Po nástupu na praxi do společnosti Moravio s.r.o. jsem byl zařazen do oddělení péče o zákaz- níky na pozici PHP programátora a kodéra. V rámci tohoto oddělení je poskytována zákaznická podpora klientům společnosti po předání či spuštění dokončeného projektu. Tyto hotové pro- jekty oddělení péče o zákazníky přebírá po splnění předem stanovených podmínek z vývojového oddělení od projektového týmu, který projekt realizoval. Mezi nejčastější požadavky, které se v rámci oddělení péče o zákazníky na denní bázi řeší, patří vícepráce (programátorské, kodérské a grafické úpravy), záruční opravy a konzultace. Méně častěji se realizují i dílčí projekty menšího rozsahu pro stávající klienty, která mají za cíl rozšířit či doplnit už fungující systém. Mimo tyto hlavní činnosti oddělení pro klienty také zajišťuje specializovaná školení a poskytuje tzv. postim- plementační služby. Postimplementační služby jsou smluvně dojednané paušální služby či práce, jejichž cílem je údržba, aktualizace a rozvoj spravovaných projektů za dohodnutých podmínek (např. při zachování určité reakční doby).
2.1 Firemní prostředí
Oddělení péče o zákazníky je prvním specializovaným oddělením, které v rámci společnosti vzniklo. Momentálně tým oddělení tvoří 5 členů - vedoucí oddělení, 3 vývojáři, kteří pokrývají jak kodérské, tak programátorské práce, a jeden externí kodér. Pro oddělení péče o zákazníky je naprosto klíčový workflow, za jehož dodržování zodpovídá vedoucí. Tento workflow definuje způsob, jakým oddělení přijímá, třídí, naceňuje, zpracovává, odevzdává a fakturuje požadavky v souladu se smlouvami, lhůtami a v kvalitě, ke které se společnost zavazuje. Požadavků přichází v průměru 100 až 200 měsíčně, v náročnosti od jednotek až po desítky pracovních hodin. Při takovém množství je nezbytně nutné důsledně dodržovat jak organizaci práce, aby v požadavcích nevznikal chaos, tak i zvolené technologické postupy. Díky dodržování těchto prerekvizit jsou požadavky prakticky bez výjimky doručovány ke spokojenosti klientů, v krátkých lhůtách a oddělení pracuje i přes menší počet členů velmi efektivně.
Poté, co jsem se seznámil s kolegy z týmu oddělení, mi byl vedoucím vytvořen firemní e- mail. Prostřednictvím e-mailu jsem pak získal přístup ke cloudovým uložištím, komunikačním a vývojářským nástrojům a také k některým z interních systémů, které jsou v oddělení péče o zákazníky, potažmo v celé firmě, využívány.
Během praxe jsem spolupracoval se všemi kolegy v oddělení, převážně pak s vývojářem webo- vých aplikací a s vedoucí oddělení, která v rámci projektu rozvoje systému klientské podpory plnila jak funkci projektového manažera, tak i grafika. Některé složitější problémy jsem konzul- toval i mimo oddělení - se zkušenějšími vývojáři z projektových týmů, kteří shodou okolností právě na stejném frameworku souběžně vyvíjejí rozsáhlý interní systém pro personální agenturu.
Vzhledem k menšímu počtu členů týmu sdílí oddělení jedinou místnost a kontakt mezi nimi nejčastěji probíhá na osobní bázi. Osobní kontakt je rychlý a nejjednodušší způsob, často ale vývojáře ruší a rozptyluje při práci na složitějších a časově náročnějších úkolech. Proto se pro
vnitrofiremní komunikaci využívají i jiné prostředky - například aplikace Slack, která připo- míná chatovací místnost s možností odesílání soukromých zpráv. Oddělení péče o zákazníky má na Slacku vyhrazený vlastní kanál, kde sdílí informace důležité pro celý tým. Zadávání úkolů jednotlivým členům týmu probíhá - pokud ne ústně - prostřednictvím soukromé zprávy nebo přiřazením ticketu (požadavku) v systému klientské podpory.
Důležitým nástrojem, který se při vývoji ve firmě používá, je verzovací nástroj GIT. GIT umožňuje více lidem ve stejném čase pracovat nad stejnou částí aplikace, aniž by si vzájemně přepisovali části kódu, a udržuje historii změn prováděných vývojářem. Díky tomu je možné se k jakýmkoliv změnám vrátit zpět. Nástroj se také využívá pro nahrávání projektů na produkční prostředí pomocí propojení se službou DeployHQ. Služba DeployHQ funguje tak, že zkontroluje GIT repozitář, zjistí zda je v něm nějaká změna v zadané větvi oproti poslední kontrole, a následně nahraje jen ty soubory, které jsou změněné, na produkční server.
12
3 Základní technologie používané pro vývoj
Pro vývoj webových aplikací a informačních systémů firma využívá mnoho různých technologií.
V této práci popisuji ty, se kterými jsem přímo pracoval během své praxe.
3.0.1 MySQL
MySQL se považuje za nejpoužívanější relační databázový systém, využívající dotazovací jazyk SQL, respektive jeho dialekt. Data v této relační databázi jsou dělena do tabulek s definova- nými sloupci, ve kterých je jeden záznam reprezentován jedním řádkem tabulky. Data jsou tedy strukturována v dvourozměrných tabulkách. V tabulkách jsou pak prováděny všechny databá- zové operace.
3.0.2 PHP
PHP je skriptovací jazyk běžíci na straně serveru. Slouží předevsím k vytváření dynamických webových aplikací. PHP je rozšiřován řadou frameworků, které vývoj PHP aplikací usnadňují.
3.0.3 Laravel
Laravel je PHP framework pro vývoj webových aplikací vycházející z návrhového vzoru MVC.
Tento framework je zdarma jako open source projekt pod licencí MIT.
3.0.4 HTML
HTML je značkovací jazyk pro tvorbu webových stránek. Definuje sadu značek, atributů, chování a jejich topologii, které pak interpret (prohlížeč) zobrazí v grafické podobě.
3.0.5 CSS
Kaskádové styly popisují způsob zobrazení nebo chování elementů v HTML webových stránek.
Hlavní důvodem, proč se CSS vyčlenilo z HTML, bylo oddělení vzhledu dokumentu od jeho struktury a obsahu pro vývojáře.
3.0.6 SASS
SASS je kompilovaný jazyk, který rozšiřuje syntaxi CSS o proměnné, cykly a další funkce.
Dynamický SASS je kompilován do statického CSS. SASS se jako takový nepoužívá. Šetří ale čas a kód je díky němu přehlednější.
3.0.7 JavaScript
JavaScript je skriptovací jazyk, který probíhá na straně klienta. Slouží převážně k reakci na uživatelskou akci. Existuje mnoho frameworků, které rozšiřují možnosti a usnadňují práci s JavaScriptem. Nejznámější z nich je knihovna jQuery.
3.0.8 jQuery
jQuery je JavaScriptová knihovna, která rozšiřuje JavaScript o další funkce. Hlavní předností této knihovny je snazší výběr a modifikace HTML elementů a v neposlední řadě také jednodušší práce s událostmi.
3.0.9 Ajax
Ajax je kombinací různých technologií, díky kterým dochází ke změně části webové stránky bez nutnosti její aktualizace.
3.0.10 JSON
Jedná se o formát zápisu dat určený k přenosu. Je zcela obecný a může být využit v libovolném programovacím (či skriptovacím) jazyce.
3.1 Architektura
3.1.1 MVC
MVC je softwarová architektura, která dělí aplikaci do 3 vrstev - tak, aby bylo možné vrstvy upravovat samostatně a dopad změn na ostatní vrstvy byl minimální. První vrstva je datový model (Model), která reprezentuje data a business logiku aplikace. Druhá vrstva je uživatelské rozhraní (View). Poslední vrstva (Controller) má na starosti tok události v aplikaci a řídící logiku.
14
4 Seznam úkolů přiřazených k vypracování
Cílem mé odborné praxe bylo samostatně zapracovávat do systému klientské podpory úkoly, které mi zadávala vedoucí oddělení prostřednictvím aplikace JIRA. Jedním z nejrozsáhlějších úkolů bylo vytvořit administrátorskou část aplikace - tak, aby v ní bylo možné vytvářet, mazat a upravovat různé modely aplikace. Dalším časově náročnějším úkolem bylo nakódování nového layoutu a přihlašovací stránky aplikace dle dodaného grafického návrhu. Realizoval jsem také systémové notifikace odesílané do komunikačního nástroje Slack, které tým informují o vytvoření ticketu či vložení nového komentáře k ticketu. Díky těmto notifikacím jsou vývojáři i vedoucí oddělení okamžitě informováni o nové aktivitě v systému podpory. Posledním z větších úkolů byla realizace exportu požadavků ze systému dle kritérií zadaných ve filtru v tzv. dashboardu aplikace.
Kromě výše jmenovaných úkolů jsem zapracovával i menší úkoly, zejména tzv. bugfixy. Ty byly ale oproti klíčovým funkcionalitám mnohem méně časově náročné. Časovou náročnost hlav- ních funkcionalit systému, které jsem implementoval, ilustruji v tabulce níže:
Úkol Počet dní
Vytvoření administrátorské části v aplikaci klientské podpory 18 Nakódování rozložení stránek a přihlašovací stránky 25 Vytvoření notifikací pro komunikační nástroj Slack 5 Export jednotlivých požadavků do tabulky ve formátu CSV 2
5 Zvolené řešení a systém klientské podpory
5.1 Systém klientské podpory
Aktuálně nejpalčivějším problémem oddělení péče o klienty byl kontakt mezi týmem a klienty.
I přes snahu o alespoň částečné sjednocení komunikačních kanálů přicházejí požadavky růz- nými cestami - telefonicky, e-mailem i skrze aplikaci klientské podpory. Příležitostně jsou také tlumočeny projektovými manažery po osobních schůzkách s klienty. Žádnou z cest nelze kli- entům odepřít - obvykle totiž platí, že čím je klient vytíženější, tím hůře dodržuje stanovené způsoby komunikace. S oddělením také za stranu klienta nekomunikují jen erudovaní odborníci - IT specialisté, či programátoři, ale často to jsou např. PR, HR nebo marketingové specia- listiky, asistentky, obchodní ředitelé nebo přímo majitelé společností. S ohledem na tento fakt není možné v oddělení používat pro komunikaci s klienty nástroje, na které jsou zvyklí vývojáři (např. JIRA, kterou popisuji dále v této kapitole), nebo aplikace, jejichž rozhraní je příliš složité a funkce zbytečně robustní. Jak zkušenost bohužel ukázala, naprosto nutná je i česká lokalizace komunikačních nástrojů.
Původně oddělení péče o zákazníky ke komunikaci používalo webovou aplikaci Basecamp (www.basecamp.com). Z nesporných výhod aplikace lze jmenovat vysokou uživatelskou přívě- tivost - líbivé a jednoduché rozhraní a poměrně snadné ovládání, zdařilou mobilní aplikaci a bezchybně fungující systém e-mailových notifikací. Oddělení ale bohužel brzo narazilo na limity aplikace - jednak na absenci právě výše zmíněné české lokalizace a dále nevýhodná cenová po- litika s omezením na počet projektů, která nebyla při stále stoupajícím počtu klientů oddělení (cca 50) dále udržitelná. Hlavním nedostatkem aplikace Basecamp byla ale právě absence na- stavení určitého pracovního workflow. Klientům zde např. není možné přidělit jiná uživatelská oprávnění než členům týmu oddělení. Úkoly nelze vizuálně ani jinak prioritizovat, aplikace po- strádá změnu stavu úkolů, či možnost cenového nebo bodového ohodnocení jejich náročnosti.
Ve výsledku tak při používání aplikace Basecamp vznikal v úkolech zmatek a k jejich evidenci bylo nutné souběžně používat excelovskou tabulku.
Vznikla proto potřeba přejít na jiný systém, který bude více vyhovovat potřebám oddělení péče o zákazníky. Po prozkoumání možností ale nebyla na trhu nalezena žádná aplikace, která by lépe odpovídala požadavkům oddělení. Dostupné byly zejména jednoduché a často poněkud zastaralé ticketovací systémy s nepříliš přehledným uživatelským rozhraním a absencí responzivní verze nebo dokonce webové verze jako takové. Dokonalejší aplikace byly zase cenově nedostupné a navíc placené na bázi měsíčního poplatku. Nakonec poslední z možností - open-source systémy - by bylo stejně náročné customizovat, jako si vyvinout systém vlastní. Proto v oddělení podpory vznikl interní projekt - vývoj vlastního systému klientské podpory. Díky předchozím zkušenostem s aplikací Basecamp i následnému průzkumu trhu už měla vedoucí oddělení konkrétní představu o tom, jak by měl systém fungovat, vypadat a jakými možnostmi by měl disponovat. Na základě těchto představ vznikla projektová dokumentace, wireframy, grafický návrh a systém přešel do
16
fáze vývoje.
Jednotlivé tzv. user stories (uživatelské příběhy, popisy funkcionalit), které vzešly z projek- tové dokumentace, byly dále rozděleny na menší úkoly a zařazeny dle priorit do jednotlivých vývojových Sprintů (iterací) od nejdůležitější po méně důležité. Úkoly pak byly vloženy do apli- kace JIRA, odkud si je už přebírali vývojáři ke zpracování, testování a implementaci.
Výhodou využívání aplikace JIRA, se kterou jsem se na praxi seznámil, při vývoji je, že je v ní možné evidovat stav implementace úkolů, popř. do ní lze vkládat zjištěné chyby. Jednotlivé úkoly se mohou v JIRA řadit podle priority, aby bylo zřejmé, které úkoly je třeba zpracovat přednostně. To samé platí i o chybách - dle míry jejich závažnosti jsou jim přiřazovány různé stavy od “Lowest” po “Highest”. JIRA také může sloužit jako komunikační nástroj mezi projektovým manažerem a vývojovým týmem. Projektový manažer si díky němu snadněji udělá představu o tom, v jakém stavu se projekt nachází. Pracuje-li firma agilně - např. Scrumem či Kanbanem - plní JIRA všechny potřebné funkce (burn-down chart apod.), aby bylo možné tuto metodiku beze zbytku naplnit.
5.2 Zvolené řešení jednotlivých úkolů
Při implementaci úkolů, které mi byly zadávány skrze JIRA, jsem musel vycházet z možností, které nabízel samotný framework Laravel. Především jsem pracoval s databází MySQL, šablo- novacím systémem Blade, kaskádovými styly v kombinaci se SASSem a s JavaScriptem.
5.2.1 Vytvoření administrace
Jeden z nejvíce časově náročných úkolů bylo vytvořit administraci pro téměř všechny modely, které v aplikaci byly použity. Původně jich bylo 5, poté se ale systém ještě dále rozvíjel a nakonec jsem skončil u 6 modelů. První model je projekt (Project). Jedná se o pracovní projekt (např.
webová stránka nebo e-shop), který má oddělení péče o zákazníky ve své správě. K projektu se vždy váže společnost (Company). Každá společnost ale může mít více projektů, které oddělení spravuje.
Dále bylo potřeba v systému vytvořit uživatele. Ti jsou rozděleni do dvou hlavních skupin dle rolí. První skupinou jsou klienti (Client), kteří jsou propojeni se společností a s projekty.
Druhá skupina jsou tzv. zástupci (User). Zástupci jsou hlavně zaměstnanci firmy, kteří provádějí úpravy na spravovaných aplikacích a komunikují s klientem (vývojáři, testeři, vedoucí). Zástupci jsou dále dělí na programátory a administrátory. Ti se liší hlavně skupinou oprávnění pro editaci (např. programátor ze systému nemůže odmazat společnost nebo projekt). Posledním ze základ- ních modelů je nastavení (Settings). Jedná se o výchozí nastavení pro celou aplikaci. Je zde například uložena volba pozadí, které se střídá na přihlašovací stránce aplikace, nebo celkový počet zpracovaných úkolů od klientů (Counter). Nejnovější model, který zatím není nahraný v produkční verzi je článek (Article). Jedná se o krátký informační text, který se bude zobrazovat
uživatelům a informovat je např. o legislativních změnách, důležitých aktualizacích platforem, bezpečnostních slabinách apod.
5.2.1.1 Databázová část Databázovou strukturu pro jednotlivé modely už nebylo nutné vytvářet od úplného začátku, vyjma článků. Původní modely už totiž v databázi vytvořil před- chozí vývojář aplikace. Databázová struktura ve frameworku Laravel se vytváří pomocí CLI (Command Line Interface) příkazu:
php artisan make:migration create_table --create=tableName php artisan make:migration update_table --table=users
Výpis 1: Vytvoření databázové migrace ve framework laravel pomocí CLI
První příkaz slouží k vytvoření nové databázové tabulky a druhý k úpravě již existující tabulky.
Tento příkaz vytvoří sám PHP soubor a pak v něm můžeme provádět potřebné úpravy struktury dle zadání. Při vytváření tabulky pro model Article, vypadal struktura databáze v souboru takto:
Obrázek 1: Soubor pro vytvoření databázové struktury
Poté stačí opět v CLI napsat příkaz pro provedení migrace, kdy se projde obsah všech mi- gračních souborů, a na základě toho se vytvoří struktura v databázi.
php artisan migrate
Výpis 2: Spuštění databázové migrace
S databází lze manipulovat jednoduše, aniž bysme museli sáhnout přímo do databázového roz- hraní.
5.2.1.2 Routování Routování je dalším důležitým prvkem v Laravelu, který slouží k pře- kladu mezi URL a požadavkem, který samotná aplikace zpracuje. Z překladu se dá snadno určit, jaký controller a jaká metoda bude danou URL zpracovávat a naopak. Routování zajišťuje sa- mostatná vrstva frameworku. Její výhodou je, že všechny generované URL jsou ve formátu tzv.
“friendly URL”. Pomocí routování jsem v aplikaci vytvořil cesty, které vedou do administrace k jednotlivým modelům.
Přímo v Laravelu se už nachází konfigurační soubor, který tuto funkčnost zajišťuje. Příklad vytvoření takové routy v Laravelu lze vidět na obrázku 2. Jednotlivé routy nám nasměrují
18
Obrázek 2: Ukázka routy v Laravelu
požadavek na určitý controller a do určité funkce. Mým úkolem bylo vytvořit výpis modelů na stránku, přidat odkaz k upravení instance a u některých instancí i k jejímu smazání. Dále jsem musel vytvořit stránku pro vytvoření instance a stránku pro editování instance. K tomu bylo nutné, abych napsal pět funkcí v jednom controlleru, který měl na starost jeden model.
V controlleru se řeší jednoduchá logika a vrací se pohled neboli šablona Blade, která obsahuje HTML kód. Pro zobrazení jednotlivých instancí modelu jsem využil rozšíření (balíček) DataGrid, který, jak už název napovídá, vytváří tabulku s atributy, které chceme vypsat. Ukázku vytvoření DataGridu a jeho předání do šablony lze vidět na obrázku 3.
Obrázek 3: Ukázka využití DataGridu
5.2.1.3 Šablonovací systém Blade Systém Blade slouží pro vytvoření šablony webové stránky. Šablony slouží k oddělení logiky od struktury a vzhledu aplikace. Všechny šablony jsou překládány do jazyka PHP a ukládají se do mezipaměti dokud nejsou upraveny. Názorná ukázka navazující na výpis DataGridu v šabloně je na obrázku 4. Tento jednoduchý kód rozšiřuje
Obrázek 4: Ukázka výpisu DataGridu
základní rozložení stránky. Poté se vloží titulek stránky dle překladu. Nakonec se vloží obsah stránky a proměnná GRID, která obsahuje všechny potřebné části kódu, a vykreslí jednoduchou, ale efektivní tabulku, ve které můžeme využívat základní řazení podle atributů, které jsme ne- chali vypsat. Šablona pro vyváření a editování modelu je komplikovanější. V šabloně je vytvořen formulář, který odešle požadavek na konkrétní routu. Pro požadavky jsou vytvořeny speciální třídy. Tyto třídy zajišťují validaci údajů ve formuláři a zjišťují, zda má uživatel dostatečná práva pro danou operaci. Dále také strukturuje data zadávaná uživateli. U formulářů se v šabloně také přidává CSRF token, který nám zabraňuje CSRF útokům.
Podstata tohoto útoku spočívá v tom, že uživatele přiměje navštívit stránku napa- dené aplikace, která na pozadí provádí nějakou akci, aniž by o tom uživatel věděl.
Útok může být tím pádem snadno veden proti aplikacím, do kterých se útočník může sám přihlásit a tím zjistit jejich strukturu, nebo proti aplikacím, které mají přístupný zdrojový kód. (https://php.vrana.cz/cross-site-request-forgery.php) Následně je třeba v controlleru vytvořit databázovou transakci a vložit nebo upravit záznam v databázi. Příklad jednoduchého vložení je na obrázku 5. Dále využívám repozitáře, které nejsou v základní instalaci Laravelu. Tento balíček, který jsem do frameworku přidal, slouží jako datová vrstva, která řeší různé operace s databází. Každý model má svůj repozitář obsahující kompli- kovanější dotazy. Převážně je toho využito u ticketů vytvářených klienty. Zde je komplikovanější filtrování jednotlivých požadavků. V repozitářích se také filtrují data dle kritérií. Pro jednotlivé kritéria se také vytváří třída.
20
Obrázek 5: Ukázka vložení/editování záznamu do/v databáze/i
Obdobně jsem pokračoval u všech modelů. Vytvoření routy pro daný model, vytvoření funkcí, které zpracovávají jednotlivé požadavky, následně při vytvoření šablony, repozitářů a kritérií.
Některé administrace byly implementačně těžší, než jiné z důvodu obsáhlosti dat a zpracování, ale všechny ve své podstatě fungují na stejném principu. O jednotlivých šablonách administrace se podrobněji rozepisuji v následující kapitole.
5.2.2 Kódování rozložení a struktury stránek
V celé aplikaci se využívá CSS frameworku Bootstrap. Tento nástroj mi při vývoji značně ulehčil práci s elementy a s responzivitou aplikace. Bootstrap má již nadefinované základní styly pro jednotlivé elementy HTML. Kódování celé aplikace tedy bylo o něco lehčí, ale pořád se pracovalo takřka "od nuly". V zadání systému klientské podpory sice byly vytvořeny wireframy (doslova
“drátěné modely”, návrhy rozložení stránky), ale toto zadání bylo pro verzi 0. Prvky, které se do návrhu aplikace dostaly až posléze, už nebyly ve wireframech zakresleny. V průběhu vývoje se zadání měnilo, proto jsem musel konzultovat zadání s grafikem. Ne všechny elementy byly pomocí Boostrapu dobře nastylované, proto bylo nutné některé elementy upravit. Pro psání CSS jsem použil jazyk SASS, který je přehlednější a umožňuje využívat proměnné a funkce. Ukázka kódu v jazyce SASS je na obrázku 6. Pro minifikaci CSS jsme v projektu využívali Grunt. Grunt
Obrázek 6: Ukázka jazyka SASS
je JavaScriptový balíček pro Node.js, který pomáhá CSS kodérům. V praxi se balíček spustí v příkazové řádce, Grunt sám hlídá změny v souborech a po jejich provedení vyvolá nějaké akce. Výhodou je, že samotný script (Gruntfile.js) je uložený v GIT repozitáři projektu, a tím pádem kdokoliv, kdo bude chtít jakýmkoliv způsobem zasáhnout do CSS, budou mít vždy stejné nastavení.
Při tvorbě administrace jsem vycházel z již nastylovaných elementů, které nabízí Bootstrap.
Za úkol jsem měl kódovat především nejrůznější formulářové stránky pro editaci a vkládání jednotlivých instancí do databáze. Při vývoji mi byla ponechána volná ruka v tom, jak mají být prvky strukturované a uspořádané. Zajímavá pro mě byla realizace části administrace, kde se vkládají a editují uživatelé. Zde jsem totiž zužitkoval i své znalosti JavaScriptu. Součástí tohoto úkolu byl i výběr ikon (avatarů), které budou reprezentovat jednotlivé uživatele do doby, než se do aplikace doplní funkcionalita pro nahrávání vlastních obrázků. Obrázek administrace pro vložení a editaci klienta lze vidět na obrázku 7.
Komplikovanějším úkolem pro mě bylo nakódování přihlašovací stránky aplikace. Stránka
22
Obrázek 7: Rozložení stránky vložení nového uživatele
sice jako taková není složitá a neobsahuje příliš mnoho elementů, bylo u ní ale zvláště důležité, aby fungovala bezchybně v responzivní verzi. Zpočátku jsem se potýkal s problémem při zob- razení stránky na mobilním zařízení v tzv. landscape módu. Pozadí stránky se navíc v denních intervalech náhodně mění, což ovlivňuje kontrast a čitelnost některých prvků. Nakonec se mi ale s pomocí kolegů podařilo responzivní chování stránky odladit a výslednou desktopovou podobu můžete vidět na obrázku 8.
5.2.3 Vytvoření notifikace pro komunikační aplikaci Slack
Ve firmě, jak se už jsem v této práci zmínil dříve, se využívá pro komunikaci aplikace Slack.
Tato aplikace je v současnosti ve firmách velmi populární a nabízí jak mnoho rozšíření v základu aplikace, tak i propracovanou podporu API. Slack integruje mnoho aplikací a služeb jako napří- klad Google Drive, JIRA a mnoho dalších. Výjimkou není ani framework Laravel. V Laravelu se notifikace spouští na základě vzniku události. Proto bylo nutné nejdříve události, které budou odpovídat akci uživatele, vytvořit. Základními událostmi jsou v systému klientské podpory vy- tvoření požadavku klientem a přidání komentáře klientem. V systému jsou sice i další události, ty už (nebo alespoň prozatím) nejsou propojeny se Slackem. Při implementaci Slack notifikací jsem vytvořil událost, která se vázala na akci přidání komentáře k požadavku a vytvoření požadavku.
Pro obě události jsem vytvořil odlišnou notifikaci, aby bylo na první pohled zřejmé, zda se jedná o nový požadavek nebo nový komentář. Slack umožňuje jednoduché stylování, vytváření tabu- lek a přidávání odkazu, takže jsem na základě těchto možností vytvořil odpovídající notifikační
Obrázek 8: Přihlašovací stránka klienstkého systému
zprávu obsahující jednoznačnou identifikaci toho, k jaké události došlo, jakého požadavku se to týká, kdo danou akci vykonal a k jaké společnosti a projektu patří. Výsledná notifikace lze vidět na obrázku 9. Tato notifikace se zobrazuje v speciálním kanálu aplikace Slack, do kterého mají
Obrázek 9: Ukázka Slack notifikace
přístup jen členové týmu oddělení. Notifikace obsahuje název požadavku a jeho identifikátor jako odkaz do aplikace. Při vytvoření komentáře je tento odkaz rozšířen o identifikátor komentáře, takže se po kliknutí rovnou zobrazí komentář od klienta.
5.2.4 Exportování požadavků dle filtrování
Požadavek na export ze systému vznikl hlavně z důvodu, aby bylo možné hotové požadavky snadno předávat k fakturaci účetnímu oddělení. Cílem tedy bylo vytvořit funkci, která exportuje všechna vyfiltrovaná data dle určitých kritérií (např. všechny dokončené úkoly typu “vícepráce”
v období od 1. 5. do 31. 5.) do CSV souboru. Příklad takového filtrování je na obrázku 10. Do Laravelu jsem proto musel přidat pomocný balíček pro export do CSV souborů. CSV soubor obsahuje data, která jsou oddělena čárkou nebo středníkem. Filtrování požadavků k exportu
24
se provádí posláním parametrů do URL. Proto je získání dat a daných parametrů pro export poměrně jednoduché. Na základě toho lze provést SQL dotaz na výběr požadavků z daných parametrů. Poté se data zpracují a vytvoří se CSV soubor ke stažení. Výsledný export obsahuje všechna potřebná data ve strukturované podobě.
Obrázek 10: Ukázka filtrace na Dashboardu
6 Využité a scházející dovednosti
V průběhu odborné praxe jsem lépe pochopil souvislosti předmětů, které jsou vyučovány na VŠB-TUO, i jejich praktické využití. Jako přínos praxe hodnotím to, že se mi podařilo využít řadu znalostí a teoretických dovedností nabytých během studia.
Na VŠB-TUO jsem nastoupil s pouze malým povědomím o OOP. Díky předmětu Progra- mování II se mé znalosti prohloubily. Klíčovými předměty, které mi pak pomohly porozumět celému OOP byly Databázové a informační systémy a Vývoj informačních systémů. Obojí jsem pak zužitkoval během odborné praxe, jelikož aplikace je naprogramována právě v OOP PHP.
I přesto, že jsem se s programovacím jazykem PHP během bakalářského studia vůbec nese- tkal, jsem si poměrně rychle osvojil jeho základy a v průběhu praxe jsem své znalosti už jen prohluboval.
Oblast, se kterou jsem měl doposud jednoznačně nejméně zkušeností, byla komunikace a obecně práce v týmu. Během bakalářského studia na vysoké škole jsme ve skupinách nepracovali téměř vůbec a bylo pro mě proto těžké překonat počáteční ostych a obavy z neporozumění.
Kolegové z týmu se mě ale ujali a ve všem mi pomáhali, jak nejlépe mohli.
Obor informačních technologií se neustále vyvíjí, a proto je potřeba se neustále učit a dále rozvíjet. Nejvíce informací, technických dokumentací a novinek z oboru je dostupných v ang- lickém jazyce. Znalost anglického jazyka proto považuji pro programátory za nezbytnou a jsem rád, že mi studium na VŠB v tomto směru pomohlo ji zlepšit.
26
7 Závěr
Během odborné praxe jsem při řešení úkolů, které mi byly zadávány, zužitkoval znalosti, které jsem získal během studia. Práce na zadaných úkolech mě nutila průběžně se doučovat nové a pro mě zajímavé věci. Seznámil jsem se s tím, jak v praxi funguje vývoj projektu, zjistil, že i “soft skills” jako je například komunikace jsou důležitým prvkem a předpokladem pro úspěšnou práci v týmu. Poprvé jsem se také setkal s prací v předem daných termínech a s předem určenou časovou náročností, což bylo někdy stresující. Díky pomoci kolegů z týmu jsem ale časový harmonogram většinou dodržel.
Za největší přínos odborné praxe považuji zkušenost s prací v týmu. Rozvoj komunikačních dovedností a zároveň motivace se zlepšovat a nebýt příliš pozadu za ostatními členy týmu - to vše mě hnalo stále kupředu. Dalším přínosem bylo zlepšení se v jazyku PHP a OOP a seznámení se s frameworkem Laravel. Tento framework jsem si během praxe oblíbil a doufám, že s ním budu moci pracovat i v budoucnu.
Celou praxi považuji za cennou zkušenost, která mi pomůže v profesním životě. Po absolvo- vání této praxe jsem dostal nabídku ve firmě dále pokračovat jako plnohodnotný člen oddělení péče o zákazníky. Momentálně se jako vývojář podílím na vývoji další verze systému klientské podpory.
