• Nebyly nalezeny žádné výsledky

2018JanTuroň AbsolvováníindividuálníodbornépraxeIndividualProfessionalPracticeintheCompany VŠB–TechnickáuniverzitaOstravaFakultaelektrotechnikyainformatikyKatedrainformatiky

N/A
N/A
Protected

Academic year: 2022

Podíl "2018JanTuroň AbsolvováníindividuálníodbornépraxeIndividualProfessionalPracticeintheCompany VŠB–TechnickáuniverzitaOstravaFakultaelektrotechnikyainformatikyKatedrainformatiky"

Copied!
32
0
0

Načítání.... (zobrazit plný text nyní)

Fulltext

(1)

VŠB – Technická univerzita Ostrava Fakulta elektrotechniky a informatiky

Katedra informatiky

Absolvování individuální odborné praxe Individual Professional Practice in the

Company

2018 Jan Turoň

(2)
(3)
(4)
(5)

Chtěl bych poděkovat společnosti profiq s.r.o. za možnost vykonávat v této společnosti baka- lářskou praxi. Jmenovitě bych chtěl poděkovat konzultantovi ze společnosti profiq Ing. Jiřímu Znojovi a vedoucímu práce Ing. Petrovi Lukášovi za cenné rady během psaní této práce.

(6)

Abstrakt

Tato bakalářská práce popisuje průběh odborné praxe ve společnosti profiq s.r.o. V úvodu práce je popsána společnost a pracovní zařazení studenta, dále v textu je popsáno řešení jednotlivých zadaných úkolů během bakalářské praxe. Student měl během práce na starosti vývoj automati- zovaných testů uživatelského rozhraní pro programy Sencha Architect, Sencha Themer a Liferay, dále se podílel na úpravě a nasazení systému pro správu dovolených Timeoff.Management. V práci jsou popsány problémy, které vznikly při práci na jednotlivých úkolech a zvolené způsoby jejich řešení. Práce dále sepisuje znalosti během studia použité při této práci a další technologie, ve kterých se student zlepšil. Na konci práce je celkové zhodnocení praxe.

Klíčová slova: odborná praxe, JavaScript, testování, programování, kontrola kvality, ExtJS, Sencha, Webdriver.io, Liferay, Timeoff.Management

Abstract

This bachelor thesis describes the course of professional practice in the company profiq s.r.o.

First part of bachelor thesis describes company and tasks assigned to student. Hereinafter in text is solving of tasks during professional practice. Student looks after development of auto- matic tests of user interface for softwares Sencha Architect, Sencha Themer and Liferay. He was also participating on modification and deployment of holiday management service Time- Off.Management. Thesis describes issues, which arises during work on particular tasks and chosen ways to solve it. Thesis also informs about knowledge gained at university and used at proffesional practice and about technologies, where student improves his skills. Last part summarizes practice.

Key Words: proffesional practice, JavaScript, testing, programming, quality assurance, ExtJS, Sencha, Webdriver.io, Liferay, Timeoff.Management

(7)

Obsah

Seznam použitých zkratek a symbolů 9

Seznam obrázků 10

Seznam výpisů zdrojového kódu 11

1 Úvod 12

1.1 Společnost profiq s.r.o. . . 12

2 Pracovní zaměření studenta 13 2.1 Technologie používané během bakalářské praxe . . . 13

3 Zadané úkoly 15 3.1 Sencha Architect . . . 15

3.1.1 Popis produktu . . . 15

3.1.2 Technologie používané k automatizovaným testům . . . 15

3.1.3 Správa zdrojových kódů a průběžné integrace automatizovaných testů . . 16

3.1.4 Hlášení chyb a vylepšení vývojového prostředí Sencha Architect . . . 17

3.1.5 Popis problematiky automatizovaných funkčních testů pro vývojové pro- středí Sencha Architect . . . 18

3.1.6 Návrhy řešení uvedených problémů . . . 18

3.2 Sencha Themer . . . 19

3.2.1 Popis produktu . . . 19

3.2.2 Problematika automatizovaných testů pro Sencha Themer . . . 19

3.2.3 Zprovoznění serveru pro vykonávání automatických funkčních testů pro Sencha Themer . . . 21

3.3 TimeOff.Management . . . 22

3.3.1 Popis produktu a úkoly . . . 22

3.3.2 Používané technologie . . . 22

3.3.3 Správa verzí a zdrojového kódu . . . 23

3.3.4 Chybějící funkcionalita pro nasazení v naší firmě . . . 23

3.3.5 Implementace nezbytných funkcionalit . . . 23

3.3.6 Zprovoznění aplikace na serveru . . . 24

3.4 Liferay Portal . . . 25

3.4.1 Popis produktu . . . 25

3.4.2 Používané technologie . . . 25

3.4.3 Pracovní úkoly na projektu Liferay . . . 25

3.4.4 Návrh a vývoj automatizovaných testů uživatelského rozhraní . . . 26

7

(8)

3.4.5 Spouštění Liferay Portalu na různých aplikačních serverech . . . 27 4 Praktické a teoretické znalosti získané během studia a uplatněné během od-

borné praxe 29

5 Schopnosti a znalosti scházející během odborné praxe 30

6 Shrnutí bakalářské praxe 31

Literatura 32

8

(9)

Seznam použitých zkratek a symbolů

BMP – Bitmap

CSS – Cascade Style Sheets

DOM – Document Object Model

ECMA – European Computer Manufacturers Association

HTML – Hyper Text Markup Language

JDK – Java Development Kit

JIMP – JavaScript Image Manipulation Program JPEG – Joint Photographic Experts Group

JRE – Java Runtime Environment

JSON – JavaScript Object Notation

JS – JavaScript

LDAP – Lightweight Directory Access Protocol OSGi – Open Services Gateway initiative

OS – Operating System

PNG – Portable Network Graphics

RHEL – RedHat Enterprise Linux

SQL – Structured Query Language

ssh – Secure Shell

SUSE – Software und System-Entwicklung

SVN – Subversion

VNC – Virtual Network Computing

9

(10)

Seznam obrázků

1 Vývojové prostředí Sencha Architect . . . 16 2 Úprava témat v programu Sencha Themer . . . 20 3 Editor obrázků portálu Liferay . . . 26

10

(11)

Seznam výpisů zdrojového kódu

1 Příklad použití javascriptového objektu Promise . . . 15

2 Příklad použití systému JSDoc u javascriptové funkce . . . 17

3 Příklad použití javascriptové funkce setInterval . . . 18

4 Příklad řetězeného volání objektu Promise s odchytáváním výjimek . . . 22

5 Příklad struktury požadavku pomocí javascriptové knihovny express . . . 24

6 Záznam spouštěný po startu systému pomocí utility Cron . . . 25

11

(12)

1 Úvod

V Bakalářské práci popisuji mou odbornou praxi ve společnosti profiq s.r.o. Firma se v současné době zabývá především službami v oblasti vývoje a testování softwaru. Při práci využívá vysokou míru automatizace ve všech krocích procesu jak vývoje, tak testování.

1.1 Společnost profiq s.r.o.

Hlavní zaměření společnosti profiq s.r.o. je poskytování služeb softwarového inženýrství (vý- voj, testování) společnostem zejména ve Spojených státech amerických pomocí agilního způsobu vývoje, který ověřuje správnost systému rychlým vytvářením a testováním, předložením zákaz- níkovi a následnými úpravami podle zákazníkovy zpětné vazby.

V současnosti zaměstnává zhruba 50 zaměstnanců. Společnost nabízí jak odborníky na jed- notlivé úkoly, tak i celé týmy pro komplexní pokrytí některé z oblastí vývoje. Nejširším know-how firma disponuje v oblasti zabezpečení, webových a mobilních služeb [9]. Zákazníkem společnosti je mimo jiné společnost Liferay, která se zabývá vývojem portálových řešení. Dále spolupracuje s firmou Forgerock, poskytující software pro správu identit.

12

(13)

2 Pracovní zaměření studenta

V rámci odborné praxe jsem byl firmou zařazen na pozici softwarového inženýra, na které jsem byl i před praxí na částečný pracovní úvazek. Z pozice software engineer jsem se věnoval násle- dujícím projektům:

Na začátku bakalářské praxe jsem se podílel na manuálním testování, psaní automatických testů a opravování menších chyb v programu Sencha Architect1 od společnosti Sencha, který je vývojovým prostředím pro vývoj webových a mobilních aplikací založených na javascriptovém frameworku ExtJS, a v programu Sencha Themer2, který dovoluje vytvářet grafická témata pro prvky uživatelského rozhraní rámce ExtJS3.

Poté jsem se podílel na úpravě a realizaci potřebných vylepšení vnitřního systému pro správu dovolených a omluv z práce, který byl postaven nad software s otevřeným zdrojovým kódem TimeOff.Management, vyvíjeným v jazyku JavaScript.

Následně jsem dostal přidělenou práci na projektu Liferay. Jednalo se o návrh a vývoj skriptů pro automatické testování uživatelského rozhraní (tzv. funkční testy), definování testovacích případů pro lepší správu, nasazování produktu Liferay Portal nad různými operačními systémy (Windows Server, Ubuntu Linux, Oracle Solaris), databázovými systémy (MSSQL, MySQL, PostgreSQL, MariaDB) a, jelikož je produkt Liferay Portal vyvinut na platformě Java [8], také nad různými aplikačními servery (Apache Tomcat, JBoss, tcServer).

2.1 Technologie používané během bakalářské praxe

Během práce na projektech bakalářské práce byly použity technologie, které jsou stručně popsané níže:

1https://www.sencha.com/products/architect/

2https://www.sencha.com/products/themer/

3https://www.sencha.com/products/extjs/#overview

13

(14)

Technologie Popis

Selenium Řešení pro volání událostí uživatelského rozhraní v prohlížečích WebdriverIO Knihovna pro JavaScript ovládající Selenium

ExtJS Rámec v jazyce JavaScript pro vývoj webových aplikací Sencha Cmd Program pro příkazovou řádku na správu ExtJS projektů Sencha Architect Vývojové prostředí rámec ExtJS

Sencha Themer Editor témat pro rámec ExtJS Git Systém pro správu zdrojových kódů

Jira Systém pro správu chyb a připomínkovací systém TeamCity Systém pro správu sestavení

Node.js Běhové prostředí jazyka JavaScript

Express Knihovna pro Node.js pro tvorbu serverových řešení TimeOff.Management Systém pro správu dovolených v jazyce JavaScript

Liferay Portal Portálové řešení v jazyce Java

JIMP Knihovna pro zpracování obrázků pro JavaScript

14

(15)

3 Zadané úkoly

3.1 Sencha Architect

3.1.1 Popis produktu

Sencha Architect je komerčním vývojovým prostředím pro webové a mobilní aplikace. Používá javascriptový rámec ExtJS, také od společnosti Sencha. Uživatelské rozhraní programu je napro- gramováno taktéž pomocí ExtJS. Ukázku uživatelského rozhraní tohoto projektu můžeme vidět na obrázku 1.

Na funkčnost, kterou ExtJS nenabízí, například práci se souborovým systémem, je použit systém Node.js. Program lze spustit na operačních systémech Windows, MacOS a Linux. Balíčky pro jednotlivé operační systémy jsou vytvořeny pomocí knihovny Electron, která představuje zjednodušenou verzi prohlížeče Chrome bez navigačních prvků.

Pro vytváření ExtJS projektů používá Architect program pro příkazovou řádku Sencha Cmd, který umí vytvářet a upravovat ExtJS projekty a jeho části pomocí příkazů. Ty Sencha Architect ve většině případů volá a kontroluje, zdali příkazy proběhly v pořádku. Sencha Architect je tedy grafickou nadstavbou software Sencha Cmd.

Sencha Architect podporuje verze rámce ExtJS, od verze 4.2, která vyšla v roce 2013, po verzi 6.5 z roku 2017.

3.1.2 Technologie používané k automatizovaným testům

Knihovna Electron nabízí vlastní knihovnu pro vývoj automatických testů - Spectron, která využívá knihovnu Webdriver.io. Tato knihovna se připojuje k spuštěným instancím programu vyvinutého nad knihovnou Electron pomocí řešení Selenium4. Kód testů je napsán v programo- vacím jazyce Javascript a spouštěn pomocí běhového prostředí Node.js.

Spectron používá asynchronní variantu knihovny Webdriver.io, proto bylo nutné použít funk- cionalitu na řetězení asynchronních funkcí do sekvenčně vykonávaných příkazů. K takovým ope- racím v JavaScriptu slouží objekt Promise (v češtině příslib) a jeho funkce. Ten je použit napříč veškerým kódem pro automatizaci testování. Ukázku použití můžeme vidět ve výpisu 1.

var promise1 = new Promise((resolve, reject) => { resolve(’Success!’);

});

promise1.then((value) => { console.log(value);

// predpokladany vystup: "Success!"

});

Výpis 1: Příklad použití javascriptového objektu Promise

4https://www.seleniumhq.org/

15

(16)

Obrázek 1: Vývojové prostředí Sencha Architect

3.1.3 Správa zdrojových kódů a průběžné integrace automatizovaných testů Pro správu zdrojových kódů jsme používali systém Git. Git je systém pro správu verzí zdrojového kódu. Umožňuje inkrementální změny kódu a navrácení k jakékoli předchozí verzi [3]. Zdrojové kódy měl náš tým uložen na serveru GitHub. Ten navíc nabízí systém povolení možných operací napříč týmem.

Pokud jsem dodělal některou část automatizace, nahrál jsem změny do hlavního repozitáře automatizovaných testů a vytvořil jsem žádost o zařazení (pull request)5kódu do hlavní větve. Tu musel schválit můj nadřízený. Pokud byly v kódu nějaké nedostatky, vrátil mi kód k přepracování včetně poznámek k dříve zmíněným nedostatkům. Pokud bylo všechno pořádku, nadřízený kód sloučil Git příkazemmerge do hlavní větve.

Tento kód z hlavní větve si automaticky stahoval systém průběžné integrace TeamCity. Sys- tém si dále stáhl a nainstaloval nejnovější sestavení Sencha Architectu, stáhl si další nezbytné knihovny a nastavil operační systém tak, aby na něm mohly běžet automatizované testy, tedy nastavil tzv. virtuální monitor.

Systém TeamCity spouštěl automatizované testy buď na manuální vyžádání, nebo v okamžik, kdy se vytvořilo nové sestavení Sencha Architect. Po proběhnutí všech automatizovaných testů byl vygenerován výpis úspěšných a neúspěšných testů, v případě neúspěšných se přidal i snímek obrazovky této chyby.

Mým úkolem bylo zkontrolovat tento výpis, nové chyby buď nahlásit do připomínkovacího systému, nebo opravit automatizované testy, které chybu vygenerovaly i když neměly.

5Vytvořením pull request systém Git porovná starou a novou verzi kódu, upozorní na konflikty a poté dovolí uživateli s pravomocemi aktualizovat kód hlavní větve na novou verzi.

16

(17)

Častěji používané postupy se ukládaly do funkcí. Obecně jsme používali dva typy funkcí: sys- témové, které přistupovaly k souborovému systému popřípadě řešily programátorské konstrukce, a funkce pro uživatelské rozhraní, které nějakým způsobem pracovaly přímo se spuštěným progra- mem Sencha Architect. Zmíněné funkce nejčastěji používaly funkce z Webdriver.io jako kliknutí myší nebo čekání na změnu některého prvku uživatelského rozhraní. Oba druhy funkcí se doku- mentovaly pomocí systému JSDoc6, který, pokud je integrovaný do vývojových prostředí nebo textových editorů, dokáže napovídat při volání funkcí například datové typy parametrů nebo výchozí hodnoty. JSDoc také dokáže pracovat s povolenými hodnotami, které poté vývojové prostředí nabízí prioritně. Příklad použití technologie JSDoc se nachází ve výpisu 2.

/**

* Adds console checker to event loop

* @param {Application} app

* @param {number} frequency Repeating time

* @param {(’client’|’driver’|’browser’|’server’)} logType https://github.com/

SeleniumHQ/selenium/wiki/JsonWireProtocol#log-type

* @param {(’INFO’|’WARNING’|’SEVERE’|’DEBUG’)} level

* @return {Object} ID of interval in event loop

*/

exports.addConsoleChecker = (app, frequency = cnsts.timeouts.consoleCheck, logType = ’browser’, level = ’SEVERE’) => {

...

}

Výpis 2: Příklad použití systému JSDoc u javascriptové funkce

3.1.4 Hlášení chyb a vylepšení vývojového prostředí Sencha Architect

Během práce na automatizovaných testech bylo nutné nalezené chyby hlásit do interního připo- mínkovacího systému společnosti Sencha, kterým byla Jira.

Hlášení chyby obsahovalo stručný popis problému a sepsání posloupnosti kroků které vedly k dané chybě. Dále bylo nutné definovat dopady chyby po provedení a to, jak by se měl pro- gram chovat pokud by tuto chybu neobsahoval. Pro případ, že byla chyba závislá na operačním systému, bylo nutné definovat operační systém, na kterém lze tuto chybu zopakovat. Výskyt problémů mohl být podmíněn i různými verzemi vývojového prostředí, proto se definovala i tato informace.

Důležité bylo, aby vývojáři věděli jak moc důležitá chyba je, proto se přiřazovala priorita opravy. Pokud byla funkcionalita ve starších verzích funkční a chyba nastala v některé z novějších verzí, jednalo se o takzvanou regresní chybu, které se přiřazovala nejvyšší priorita. Nejvyšší

6Systém, který umožňuje popisovat funkce a proměnné uvnitř javascriptového kódu a díky definované syntaxi generovat dokumentace ke kódu.

17

(18)

prioritu měly dále například chyby, které vedly ke ztrátě dat na rozpracovaném projektu ve vývojovém prostředí. Naopak nižší prioritu měly například nekonzistentnosti v uživatelském rozhraní.

V popisu práce bylo i hlášení drobných vylepšení. K hlášení vylepšení jsme moc často nepři- stupovali, většinou šlo například o vylepšení uživatelského rozhraní, například lepší dostupnost některých tlačítek nebo otevírání správce souborů na místě projektu. Hlášení vylepšení s vyšší prioritou jsme neměli v popisu práce, tato vylepšení byla definována přímo společností Sencha.

3.1.5 Popis problematiky automatizovaných funkčních testů pro vývojové pro- středí Sencha Architect

Testy pro Sencha Architect už byly z velké míry zautomatizované týmem, ve kterém jsem byl zařazen i před praxí. Po každodenním sestavení nové verze trvalo provedení testů v prostředí TeamCity 8 – 9 hodin. Mým úkolem bylo vyřešit následující nedostatky:

• Kontrola vyskakovacích oken s chybami programu, které vybízely k restartu nebo ukončení programu.

• Kontrola chyb které nebyly na první pohled patrné, byly ale reportované ve vývojářské konzoli Electronu.

3.1.6 Návrhy řešení uvedených problémů

Vzhledem k tomu, že nebylo možné zcela předpokládat, kdy se výše uvedené chyby vyskytnou, bylo značně nepraktické odchytávat tyto chyby v rámci sekvenčního vykonávání testů, jelikož by to vedlo k nepřehlednosti a zbytečnému prodlužování kódu automatických testů. Kontrola chyb by se musela volat po vykonání každé funkce automatizovaných testů.

Zajímavější variantou se jevilo využití javascriptové funkce setInterval. Funkce, jak lze vidět ve výpisu 3, dovoluje vytvořit asynchronní funkci, která je zavolána vždy po vypršení za- daného intervalu [1]. Vzhledem k tomu že automatizované testy nejsou náročné na systémové zdroje, mohla se tato funkce volat poměrně často. Zvolil jsem tedy její zavolání, a tedy zkontro- lování uživatelského rozhraní programu Sencha Architect, jestli nebylo zobrazeno okno o pádu aplikace, každou sekundu.

var intervalID = window.setInterval(myCallback, 1000);

function myCallback() {

console.log(’Vypis kazdych 1000 milisekund’);

}

Výpis 3: Příklad použití javascriptové funkce setInterval

18

(19)

Přidal jsem tedy skripty na kontrolu okna s chybou, která obsahovala kontrolu ID elementu DOMu kódu HTML nacházejícího se pouze v chybovém okně, a případné zavření okna chybové hlášky.

Pro kontrolu chyb ve vývojářské konzoli jsem do funkce setIntervalpřidal kontrolu kon- zole, kterou nabízí knihovna WebdriverIO funkcí log, která vypíše všechny záznamy z konzole.

V případě chyby tedy test selhal.

3.2 Sencha Themer

3.2.1 Popis produktu

Program Sencha Themer umí vytvářet témata vzhledů pro prvky uživatelského rozhraní pro projekty vytvořené ve frameworku ExtJS od verze 6.0 [6]. Při vytvoření nového tématu si uživatel zvolí název tématu, cestu k ExtJS projektu. V případě prázdného adresáře se vytvořil nový ExtJS projekt.

Je také nutné zvolit téma, které už je součásti ExtJS a slouží jako vzor pro vytvářené téma – obsahuje výchozí barvy a podobně. Jsou dostupná témata vytvořena přímo grafiky společnosti Sencha, poté téma držící se definic Material Design7od společnosti Google a design připomínající uživatelská rozhraní mobilních zařízení od společnosti Apple. Jsou tedy dostupná témata jak pro zobrazení na telefonu, tak pro zobrazení na stolním počítači či notebooku, a to dokonce v hybridní verzi kdy je v jednom ExtJS projektu jak téma pro mobily, tak téma pro stolní počítače.

Na obrázku 2 můžeme vidět uživatelské rozhraní úpravy tématu v programu Sencha Themer.

Pro vygenerování tématu je využit program pro příkazovou řádku Sencha Cmd, který v ad- resáři vytvoří potřebné soubory pro téma a přidá informace do konfiguračního souboru projektu.

Po proběhnutí těchto nezbytně nutných kroků program přejde k nabídce prvků uživatelského rozhraní, které lze upravit. Pro každé téma existují globální proměnné, které program také dokáže změnit a změny se ihned vykreslí.

Sencha Themer používá stejně jako Sencha Architect ke svému běhu knihovnu Electron, která umí z programů vytvořených webovými technologiemi Javascript, HTML a CSS vytvo- řit samostatný binární soubor. Sencha Themer podporuje operační systémy Windows, Linux a MacOS.

3.2.2 Problematika automatizovaných testů pro Sencha Themer

Program Sencha Themer je méně komplexní než program Sencha Architect. Nejdůležitější sou- část byla změna zadaných proměnných u vytvořených témat. Muselo se tedy kontrolovat, jestli se po změně hodnoty proměnných program nepřestal odpovídat, nerozhodily se styly vykreslo- vaného prvku tak, že se prvek přímo v programu Sencha Themer nezobrazoval správně a jestli výpis programu Sencha Cmd neobsahoval nějaké chyby.

7https://material.io/guidelines/

19

(20)

Obrázek 2: Úprava témat v programu Sencha Themer

20

(21)

Toto bylo nutné provést v každé verzi rámce ExtJS, kterou Sencha Themer podporuje, s každým základním tématem a v každém prvku uživatelského rozhraní bylo během testování potřeba změnit alespoň jednu proměnnou. Verze rámce, základní témata pro jednotlivé verze rámce a proměnnou, která se měla změnit jsem definoval v JSON souboru pro snadnější čitelnost a jednoduché načítání [2].

Automatizovala se také validace textových polí. Název tématu projektu nesměl obsahovat některé speciální znaky, jelikož pro něj byla v souborovém systému vytvořena složka. Program by také měl upozornit uživatele, že verze rámce ve vybraném projektu není programem podpo- rována. Pokud byl zvolen neprázdný adresář bez ExtJS projektu, program by v adresáři neměl vytvořit nový ExtJS projekt.

Po vesměs dobrých zkušenostech s knihovnami a běhovým prostředím automatizovaných testů v Sencha Architect jsem zvolil stejné technologie i při testování programu Sencha Themer.

Bylo nutné použít navíc knihovnu Spectron, která umožňuje volání operací WebDriver v řešení Electron a používá během volání událostí uživatelského rozhraní javascriptovou konstrukci Pro- mise [4], což ve většině případů bohužel znepřehledňovalo kód automatizovaných testů, jelikož posloupnost kroků si žádala v drtivé většině případů sekvenční přístup. Jiné řešení než použití Spectron bohužel neexistuje a vytváření vlastního by zabralo mnoho času.

3.2.3 Zprovoznění serveru pro vykonávání automatických funkčních testů pro Sen- cha Themer

Pro sestavování nových verzí má společnost Sencha k dispozici systém správy sestavování a prů- běžné integrace TeamCity. Tento systém běžící na platformě Java vytváří pro jednotlivé defino- vané úkoly virtuální stroje na bázi Linuxu. Musel jsem zprovoznit vykonávání automatizovaných testů tak, aby po vykonání systém TeamCity poskytnul detailní zprávu jak o chybách, tak o úspěšně vykonaných testech a aby v případě chyb pořídil snímek obrazovky přesto, že servery nemají fyzický monitor.

Systém si nejprve musel na svůj virtuální stroj překopírovat aktuální sestavení Sencha The- mer a podporované verze dalších závislostí. Musely se tedy stáhnout všechny podporované verze rámce ExtJS ve stabilních verzích. Instalátor pro Sencha Themer podporuje instalaci bez gra- fického prostředí, čehož jsem využil.

Pro vytvoření virtuálního monitoru jsem využil VNC server. Po instalaci na Linuxový server dovoluje vytváření virtuálních monitorů s rozhraním zobrazovacího serveru X.org [10]. Lze na něm nakonfigurovat barevnou hloubku a rozlišení. Po spuštění VNC serveru a spuštění Sencha Themer na virtuálním stroji dokázala knihovna Spectron pořizovat snímky přímo z Sencha Themer.

V kódu automatizovaných testů uživatelského rozhraní se funkce na snímání obrazovky volala v odchytávacím bloku zřetěženého volání objektu Promise. Ve výpisu 4 vidíme příklad použití.

FunkceemptyLog je vytvořena jako Promise. Až se vykoná přejde se do bloku then, ve kterém se asynchronně vykonají všechny definované funkce a až jak se všechny vykonají, přejde do další

21

(22)

then, která funguje obdobně. Pokud některá z funkcí uvnitř konstrukcí then selže, začne se vykonávat kód ve funkci catch. Funkce catchOperation spouští mimo jiné i pořízení snímku obrazovky.

themer.emptyLog().then(() => { console.log("Delete Empty");

return themer.deleteAppFolderContent(themer.con.folders.emptyFolder());

})

.then(() => {

console.log("Create Theme: " + createThemeName + " ;Create Theme App: "

+ createThemeAppPath + " ;Create Theme Ext: " + createThemeExt + "

;Create Theme Button: " + createThemeCreateBtn) done();

})

.catch((err) => {

themer.catchOperation(err);

})

Výpis 4: Příklad řetězeného volání objektu Promise s odchytáváním výjimek

3.3 TimeOff.Management

3.3.1 Popis produktu a úkoly

TimeOff.Management [5] je webová aplikace pro správu dovolených v malých a středních fir- mách s otevřeným zdrojovým kódem. Zdrojový kód programu je psán v JavaScriptu a jako běhové prostředí využívá Node.js. V rámci tohoto produktu jsem měl implementovat chybějící funkcionality popsané dále v odstavci 3.3.4.

3.3.2 Používané technologie

Běhové prostředí Node.js využívá jako balíčkovací manažer program Npm, který pomáhá insta- lovat knihovny nutné k úspěšnému spuštění nebo interpretaci zdrojového kódu, kontroluje verze závislostí a umí spouštět skripty definované v projektu. Npm instaluje knihovny z vlastního repozitáře.

Pro server je tedy použito rozhraní Node.js s knihovnou Express pro zpracování požadavků na server. Pro zobrazování prvků uživatelského rozhraní je použita knihovna Bootstrap a server vrací webové stránky které jsou vygenerovány ze šablon systému Handlebars. Data aplikace jsou ukládána v databázovém systému SQLite, kdy je celá databáze uložena v jednom souboru přímo na disku.

22

(23)

3.3.3 Správa verzí a zdrojového kódu

Zdrojový kód programu je udržován na serveru GitHub. Pro vývoj a následnou správu interní verze bylo nutné mít účet na tomto portálu. Stránky GitHub dovolují vytvoření kopie veřejných projektů na svůj účet.

3.3.4 Chybějící funkcionalita pro nasazení v naší firmě

Přestože aplikace obsahuje množství funkcionalit, některé chybějící byly nezbytné pro nasazení pro celou firmu a bylo nutné je přidat. Jednalo se o následující prvky:

• export souhrnu dovolených za jednotlivé měsíce do formátu XLSX nebo do formátu účet- ního softwaru,

• změna hesla účtu na LDAP serveru,

• přidání českých svátků.

Dále bylo nutné provést nastavení těchto funkcí:

• import uživatelů z firemního LDAP serveru,

• nastavení odesílání potvrzovacích e-mailů,

• automatické spuštění po restartu zařízení.

3.3.5 Implementace nezbytných funkcionalit

Nejprve jsem prozkoumával možnosti exportu do formátu podporovaného účetním programem.

Jednalo se o program Pamica od společnosti Stormware. Tato společnost nabízí i dokumentaci formátu importovatelného do programu [11]. Po prostudování dokumentace bylo jasné, že imple- mentace by byla mnohem náročnější než se předpokládalo, jelikož systém pro správu dovolených neobsahoval některá data, která byla ve formátu pro import do programu Pamica povinná.

Od importu přímo do speciálního formátu se tedy upustilo. Přešlo se tedy k variantě vytvořit soubor formátu XLSX, který podporuje většina tabulkových procesorů jako Microsoft Excel nebo LibreOffice Calc.

Bylo nutné zvolit vhodnou javascriptovou knihovnu, ideálně instalovatelnou pomocí balíč- kovacího správce Npm. Zvolil jsem knihovnu node-excel-export dostupnou na stránkách npm.

Knihovna nabízí definice tabulek, pro buňky lze nastavit písmo, datový typ, barvu pozadí, barvu písma, velikost a řez písma. Je možné i provádět spojování buněk.

Po analýze zdrojového kódu aplikace TimeOff.Management jsem zjistil, že pro každého uživa- tele programu lze exportovat veškeré dovolené ve formátu JSON. Tento výstup lze poté zpracovat iterátorem nad uživateli a poté nad dovolenými. Jelikož data dovolených ve formátu JSON ob- sahovala rozpětí dnů, bylo nutné počítat s volnými dny – sobotami a nedělemi, a se státními

23

(24)

svátky. Tyto dny nemohly být zahrnuty v součtu počtu dnů vybraných dovolených. Bylo také třeba počítat s dovolenými vybranými na přelomu měsíců tak, aby se nezapočítaly dny takových dovolených do špatných měsíců.

Formulář pro změnu hesla na LDAP serveru vyžadoval odesílání HTTP požadavku s vo- láním metody patch viz výpis 5. LDAP server přijímá požadavek na změnu hesla ve formátu JSON ve správné struktuře. Stačilo tedy pomocí knihovny express, která již je použita v apli- kaci TimeOff.Management, vytvořit požadavek na LDAP server v případě, že formulář splňuje kontroly:

• hesla v obou polích pro zadání nového hesla se shodují,

• heslo je dostatečně dlouhé.

change_pass_header = {

uri: ’http://${user}:${old_pass}@${LDAPip}:${LDAPport}/users/${user}’, method: ’PATCH’,

contentType: ’application/json’, json: {[

"operation": "replace",

"field": "userPassword",

"value" : newLpass ]}

}

Výpis 5: Příklad struktury požadavku pomocí javascriptové knihovny express

Pokud kontroly vyhověly, požadavek se odeslal na server. Pokud server potvrdil změnu hesla, TimeOff.Management zobrazil potvrzující zprávu, jinak vypsal chybovou hlášku, která přišla ze serveru.

3.3.6 Zprovoznění aplikace na serveru

Z důvodu nízkých nároků na výkon serveru, kdy se předpokládá, že zaměstnanci použijí aplikaci jen několikrát ročně, byl pro nasazení dostatečný jednodeskový počítač Raspberry Pi s operačním systémem Raspbian což je linuxová distribuce vycházející z distribuce Debian.

Na daném zařízení bylo nutné nastavit spouštění Node.js serveru, na kterém aplikace běžela.

K Raspberry Pi jsem se připojil přes ssh, na zařízení jsem měl nainstalovaný verzovací systém Git. V případě restartu zařízení by se měl server znovu automaticky spustit. Díky tomu, že na zařízení běžela linuxová distribuce, mohl jsem použít program pro příkazovou řádku Cron, který umí spouštět skripty v různých časech nebo i po startu systému. Start Node.js serveru jsem tedy nastavil hned po spuštění systému. Ve výpisu 6 se nachází syntaxe výpisu.

24

(25)

@reboot node /home/timeoff/index.js &

Výpis 6: Záznam spouštěný po startu systému pomocí utility Cron

3.4 Liferay Portal

3.4.1 Popis produktu

Liferay Portal je portálové řešení vyvíjené společností Liferay se sídlem v San Franciscu. Společ- nost nabízí dvě varianty produktu. Komunitní variantu, která je zdarma, s otevřeným zdrojovým kódem, ale bez pokročilých funkcí a podpory, a placenou variantu „Enterprise“ pro podniky, která obsahuje pokročilé funkce a placenou podporu.

Portál nabízí funkce jako sdílení souborů, chatovací službu, stránky s možností úpravy více uživateli, vytváření wiki stránek, blogů. Obsahuje širokou škálu možností v kategorii správy uživatelů a jejich práv ke všem sekcím portálu. Každý uživatel si může vytvořit vlastní stránku s vlastním obsahem.

3.4.2 Používané technologie

Liferay Portal je vyvíjen v programovacím jazyce Java a běží na platformě Java Enterprise Edition. Portal lze pustit na několika různých aplikačních serverech, například JBoss, Tomcat, Tcserver. Podporuje všechny důležité implementace běhového prostředí Java (Oracle Java, Ope- nJRE/JDK, Java IBM) a operační systémy, na kterých lze tyto implementace zprovoznit. Pro instalaci operačních systémů jsem zvolil virtualizační prostředí VirtualBox8.

Při vývoji automatizovaných funkčních testů jsme stejně jako u produktu Sencha Architect zvolili Node.js s knihovnou Webdriver.io, která používá Selenium Webdriver jako server pro zprostředkování spojení mezi prohlížečem a kódem testů. Jelikož Liferay běží v prohlížeči, ne- bylo potřeba použít knihovnu Spectron a nebylo tedy nutné používat asynchronní volání funkcí knihovny Webdriver.io.

3.4.3 Pracovní úkoly na projektu Liferay

Vzhledem k tomu že projekt Liferay byl nejdelší z projektů během mé bakalářské praxe, byl také zatížen nejvíce úkoly. Byly mi přiřazeny následující úkoly:

• prozkoumávání funkcí,

• návrh a vývoj automatizovaných testů uživatelského rozhraní,

• hlášení chyb,

• zprovozňování na různých typech aplikačních serverů a operačních systémů.

8https://www.virtualbox.org/

25

(26)

Obrázek 3: Editor obrázků portálu Liferay

3.4.4 Návrh a vývoj automatizovaných testů uživatelského rozhraní

K vývoji testů jsem znovu použil knihovnu WebdriverIO, která běží nad běhovým prostředím Node.js. Vzhledem k tomu, že Liferay běží ve webovém prohlížeči, nebylo nutné použít knihovnu Spectron a nemusel jsem ani využívat asynchronního volání metod, které bylo ve většině částí spíše komplikací než zjednodušením. Pro porovnávání výsledků a strukturované výsledky testů jsem stejně jako u vývoje testů pro Sencha Architect zvolil knihovnu Jasmine. Pro vývoj jsem používal JavaScript počítající s nejnovější specifikací ECMAScript 6. edice, která byla schválena v červnu 2015 [7].

Zdrojový kód automatizovaných testů jsem měl udržovat pomocí softwaru Git na interním repozitáři zdrojových kódů GitLab, který umí se systémem Git spolupracovat. Měl jsem vlastní kopii testů pod svým účtem, jelikož jsem nebyl jediný kdo přispíval do projektu. V případě, že jsem udělal větší pokrok v kódu, dal jsem požadavek o přidání mého kódu do hlavní kopie těchto testů. Pokud změny prošly systémem na kontrolu syntaxe zdrojového kódu ESLint a vedoucí pracovník tyto změny schválil, objevily se tyto změny v hlavní kopii.

Měl jsem za úkol zautomatizovat několik komponent software Liferay. Jedním z nich byla kontrola správnosti použitých filtrů v zabudovaném editoru obrázků, který můžeme vidět na obrázku 3. Porovnávání obrázků nemá knihovna Jasmine naimplementovanou, musel jsem si tedy tuto funkčnost implementovat sám, nejlépe pomocí knihoven pro Node.js pro manipulaci s obrázky. Po hledání jsem zvolil knihovnu JIMP, která má zabudované porovnávání obrázků pomocí algoritmu pHash, který pro podobné obrázky dokáže vrátit podobný otisk (hash) [12], nebylo tedy nutné řešit přebytečné pixely na některém okraji obrázku. Algoritmus ale počítá s obrázky stejné velikosti, jeden z obrázků tedy bylo nutné zmenšit tak, aby velikostí odpovídal druhému obrázku.

Po prozkoumání zdrojového kódu uživatelského rozhraní editoru obrázků Liferaye jsem zjistil, že obrázek je ve stránce vykreslován pomocí HTML prvku canvas – tedy plátno. Knihovna JIMP

26

(27)

ale podporuje pouze soubory formátu BMP, PNG a JPEG – ty bylo možné načíst i v kódování Base64.

Musel jsem tedy nejprve převést canvas do formátu obrázku. Pro canvas existuje v Ja- vaScriptu zabudovaná metoda toDataURL, která z canvasu umí vytvořit PNG soubor v kódo- vání Base64. Pro porovnání jsem tedy obrázek zmenšil do velikosti obrázku na canvasu a pomocí algoritmu pHash nechal vygenerovat rozdíl.

V dalším úkolu šlo o automatizaci přístupu k jednotlivým položkám uživatelské nabídky, který používal pro animace a vykreslování JavaScript, přístup k některým položkám tedy nebyl úplně triviální. Nabídka se navíc generovala rozdílnými způsoby na dvou prohlížečích které jsem měl zahrnout – Google Chrome a Mozilla Firefox.

3.4.5 Spouštění Liferay Portalu na různých aplikačních serverech

Liferay dodává balík přímo s aplikačním serverem Apache Tomcat, má ale i balík bez aplikačních serverů a mým úkolem bylo nasadit instance na aplikačních serverech JBoss, tcServer a Wildfly, pro které má Liferay oficiální podporu pomocí dokumentace ze stránek Liferay. Jelikož je do- kumentace psána pro starší verze, bylo pravděpodobné, že některé části již nebudou platné, což jsem měl nahlásit do připomínkovacího systému společnosti Liferay.

Tyto aplikační servery jsem musel nasadit nad implementacemi Javy, a to OpenJRE a Oracle Java na operačních systémech Linux (RHEL, SUSE EL) a Oracle Linux. Liferay podporuje i více databázových systémů (MySQL, PostgreSQL, MSSQL, Oracle SQL Server), které bylo nutné také nakonfigurovat.

Nejprve bylo nutné stáhnout instalační obrazy jednotlivých operačních systémů. V případech Red Hat Enterprise Linux a SUSE Enterprise Linux jsem provedl registraci na stránkách a použil jsem zkušební verzi operačního systému na 30 dní, jelikož se jedná o komerční operační systémy.

Všechny výše uvedené operační systémy jsou nabízeny ke stažení ve formátu ISO, který je virtualizačním prostředím VirtualBox podporován.

Ještě před instalací jsem nakonfiguroval instance operačních systémů v prostředí VirtualBox tak, aby měly dostatek prostoru pro veškerý instalovaný software (30 GB) a nastavil jsem síťové spojení tak, aby k operačním systémům bylo možné přistoupit z místí firemní sítě jak přes ssh tak přimo k spuštěné instanci portálu Liferay.

Operační systémy samozřejmě neměly grafické rozhraní. Pro stahování souborů z internetu jsem používal aplikaci pro příkazovou řádku wget, která je dostupná pro všechny uvedené ope- rační systémy. V případě souborů uložených na vlastním počítači jsem k přenesení používal utilitu scp9, která přenáší soubory pomocí ssh protokolu.

V případě Javy jsem u Oracle Java volil binární soubory přímo ze stránek Oracle, OpenJDK jsem instaloval přimo z repozitářů. Pro systémy řízení báze dat jsem volil kombinace s operačními systémy tak, aby byly snadno dostupné z repozitářů, což bylo možné u všech kombinací.

9https://linux.die.net/man/1/scp

27

(28)

Spuštění instance portálu Liferay vyžaduje spuštěný databázobý server, popřípadě je nutné zajistit spuštění v rámci aplikačního serveru. Dále je potřeba stáhnout samotné jádro Life- ray, jeho externí závislosti, soubory modulárního systému OSGi, ovladač databázového systému a určený aplikační server. Dále jsem musel nakonfigurovat aplikační server tak, aby bral v potaz soubory Liferay. Nakonec jsem do aplikačního serveru překopíroval binární war soubor Liferay.

Výpisy zpráv aplikačního serveru Tomcat v tu chvíli ukazovaly chyby přesto, že jsem po- stupoval podle oficiálního návodu. Skutečnost bylo tedy nutné nahlásit do připomínkovacího systému společnosti Liferay a ze souboru s protokolem o spuštění najít chybu, která toto způso- buje a přidat do zprávy v připomínkovacím systému.

28

(29)

4 Praktické a teoretické znalosti získané během studia a uplat- něné během odborné praxe

Během své odborné praxe jsem v první řadě uplatnil své nabyté vědomosti ze všech předmětů zaměřených na programování, hlavně informace o koncepci a stylu programování mi pomohly udržovat kód přehledný a rozšiřitelný. Pomohly mi také přednášky a projekty programované jazykem JavaScript v rámci předmětu Vývoj internetových aplikací.

Znalosti z předmětu Správa operačních systémů, kde se pracovalo s příkazovou řádkou li- nuxových operačních systémů a jazykem Bash, byly nápomocné při nastavování Linuxových serverů a instalaci programů na servery běžícími nad Linuxovými distribucemi pomocí vzdále- ného přístupu – klient protokolu ssh. Na mém firemním počítači jsem měl linuxovou distribuci Ubuntu jako primární operační systém a předmět mi tedy prohloubil znalosti i v tomto ohledu.

Vzhledem k tomu, že veškerá psaná komunikace se zákazníky (např. hlášení chyb do připo- mínkovacího systému) a některá interní komunikace uvnitř firmy probíhala v angličtině, využil a uplatnil jsem znalosti ze čtyřsemestrálního kurzu anglického jazyka. Předmět se zaměřuje zejména na gramatiku, proto mi látka pomohla převážně v psaní anglických textů.

29

(30)

5 Schopnosti a znalosti scházející během odborné praxe

Funkční a jednotkové testování se použivá u všech větších projektů, zejména těch vyvíjených agilní metodou. Bohužel během bakalářského studia jsem neměl možnost si vývoj těchto testů vyzkoušet v žádném povinném, povinně volitelném nebo volitelném předmětu.

Během studia jsem se nesetkal ani s představením některého systému správy verzí, jako je například systém Git nebo SVN a práce s ním. Během mé odborné praxe jsme používali k veškeré správě zdrojového kódu systém Git, a to buď na platformě GitHub, nebo GitLab.

Předměty zabývající se těmito systémy jsem bohužel postrádal.

30

(31)

6 Shrnutí bakalářské praxe

Během bakalářské praxe jsem se podílel celkem na třech projektech. Na vývoji automatizovaných testů a testováním programů Sencha Architech a Sencha Themer, úpravě a nasazení interního řešení pro správu dovolených Timeoff.Management a testování a vývoji testů uživatelského roz- hraní pro portálové řešení Liferay.

Díky tomu, že jsme ve všech projektech používali programovací jazyk JavaScript, výrazně jsem rozšířil své znalosti tohoto jazyka a interpretovaných jazyků obecně. Při práci na Time- off.Management jsem zjistil více o jednoduchých serverech a jejich implementaci. Napříč projekty jsem používal operační systém Linux, získal jsem tedy nové znalosti v oblastech práce s příka- zovou řádkou, syntaxe jazyka bash a fungování Linuxových serverů. Jelikož jsme ke správě kódu používali systém správy verzí Git, naučil jsem se pracovat i s jeho rozhraním pro příkazovou řádku a s webovými rozhraními portálů GitLab a GitHub.

Během bakalářské praxe jsme využívali i služeb připomínkovacího systému Jira, naučil jsem se tedy správně strukturovat chybové správy, definovat priority chyb a vylepšení.

Projekt Liferay využíval ke spouštění ve výchozí instalaci aplikačního serveru Tomcat, měl jsem tedy možnost se seznámit se základním ovládáním a konfigurací aplikačních serverů pro virtuální stroj Java.

31

(32)

Literatura

[1] Timers | node.js v9.11.1 documentation.

Dostupné online: https://nodejs.org/api/timers.html#timers_setinterval_

callback_delay_args. cit. 16.4.2018.

[2] Miroslav BUREŠ a kolektiv. Efektivní testování softwaru: klíčové otázky pro efektivitu testovacího procesu. Grada, Praha, 2016. 137 s.

[3] Scott CHACON. Pro Git: [everything you need to know about the Git distibuted source control tool]. NY: Apress, New York, 2014.

[4] Inc. GitHub. Github - electron/spectron: test electron apps using chromedriver.

Dostupné online:https://github.com/electron/spectron#savepage. cit. 16.4.2018.

[5] Inc GitHub. Timeoff.management·github.

Dostupné online:https://github.com/timeoff-management. cit. 16.4.2018.

[6] Sencha Inc. Sencha themer: Theming tool to style ext js apps - sencha | sencha.com.

Dostupné online:https://www.sencha.com/products/themer/. cit. 16.4.2018.

[7] Ecma International. Ecmascript 2015 language specification – ecma-262 6th edition.

Dostupné online:http://www.ecma-international.org/ecma-262/6.0/. cit. 16.4.2018.

[8] Slashdot Media. Liferay portal download | sourceforge.net.

Dostupné online:https://sourceforge.net/projects/lportal/. cit. 16.4.2018.

[9] profiq s.r.o. About us » profiq.

Dostupné online:https://www.profiq.com/about-us/. cit. 16.4.2018.

[10] Tristan Richardson. vncserver(1): start/stop vnc server - linux man page.

Dostupné online:https://linux.die.net/man/1/vncserver. cit. 16.4.2018.

[11] STORMWARE s.r.o.

Dostupné online: https://www.stormware.cz/schema/pamica/dochazka.xsd. cit.

16.4.2018.

[12] Christoph Zauner. Implementation and benchmarking of perceptual image hash functions.

Dostupné online:http://www.phash.org/docs/pubs/thesis_zauner.pdf. cit. 22.4.2018.

32

Odkazy

Související dokumenty

Měl jsem za úkol vytvořit plugin, který bude sloužit pro vytváření dárků k objednávce, které zákazník dostane zdarma při nákupu nad určitou cenu.. Tento plugin má za

4.4.2.2 Vstup pro výběr předdefinovaných dat s výběrem pouze jedné položky HTML elementy typu input nebo select, díky kterým si zákazník vybere nastavení z předdefi-

Byl to sice úkol jen na cca 3 hodiny a šlo čistě jen o připravení vzhledu, ale byl jsem rád, že jsem tento úkol dostal právě já, protože drobné úpravy na již

Architekti TIXu v něm navíc z nějakého důvodu nechtějí implementovat stránkování a řazení záznamů na straně serveru, z toho důvodu to bylo nutné implementovat ve

Vývoj DivvyPay je poměrně dynamický, průběžně vznikají nové funkce a opravují se chyby, je proto nutné mít vždy k dispozici poslední sestavení aplikace.. 4.2.2

V rámci tohoto kroku jsem vytvářel třídy, které imple- mentovaly jednotlivé kroky definované v souborech s definicí testů v jazyce Gherkin. Tyto třídy jsem vytvářel tak, aby

Jelikož byly všechny reporty vytvářeny v jednom souboru, mohl být pro zrychlení práce využit sdílený dataset – takovýto dataset se dá použít pro více reportů zároveň,

V druhé části se budu věnovat vývoji webové aplikace, jenž by umožňovala sledování obrazu kamer, které jsou na systém Zoneminder připojeny a také sledování