VŠB – Technická univerzita Ostrava Fakulta elektrotechniky a informatiky
Katedra informatiky
Absolvování individuální odborné praxe Individual Professional Practice in the
Company
2018 Jakub Ranosz
Rád bych poděkoval Lucce za inspiraci, svým rodičům, že mi umožnili studovat, Ing. Pavlu Dohnálkovi za vedení a odbornou pomoc při psaní této práce, kolektivu firmy Tieto, se kterým jsem spolupracoval a také Mgr. Arturu Ustapiukovi, jenž byl mým konzultantem.
Abstrakt
V této bakalářské práci je popsán průběh absolvování mé odborné praxe ve firmě Tieto Czech s.r.o. V úvodu popisuji proč jsem si vybral možnost absolvování bakalářské práce jako praxe, krátce představuji firmu Tieto, pracovní zařazení a vyvíjenou aplikaci. Dále popisuji úkoly za- dané v průběhu praxe. Ve čtvrté části detailně popisuji mnou navržené řešení zadaných úkolů.
Nakonec, v závěru práce, zhodnotím celkový průběh praxe, jaké znalosti jsem získal studiem na univerzitě a využil je při praxi, a také chybějící znalosti.
Klíčová slova: odborná praxe, Tieto, TIPS, C#, .NET, Oracle, TypeScript, HTML, CSS
Abstract
This bachelor’s thesis describes my intership in Tieto Czech s.r.o. At the beginning, I describe why I chose to pass my bachelor thesis as an intership, briefly present Tieto, the job classification and the developed application. Further I describe the tasks assigned to me during the intership.
In the fourth part I describe in detail the proposed solution of assigned tasks. Finally, in the end of the thesis, I evaluate the overall course of the intership, the knowledge I gained by studying at the university and also the knowledge which I had to study by myself.
Key Words: professional practice, Tieto, TIPS, C#, .NET, Oracle, TypeScript, HTML, CSS
Obsah
Seznam obrázků 8
Seznam tabulek 9
1 Úvod 10
2 Popis odborného zaměření firmy a pracovního zařazení 11
2.1 Představení firmy . . . 11
2.2 Pracovní zařazení . . . 11
2.3 Popis aplikace . . . 12
3 Seznam zadaných úkolů 13 3.1 Zobrazení počtu příloh u ticketu . . . 13
3.2 Přizpůsobení rozložení obrazovky detailu ticketu dle požadavků uživatele . . . . 13
3.3 Řazení seznamu ticketů na straně serveru . . . 13
3.4 Nová obrazovka - Manage Company . . . 13
3.5 Interní tickety . . . 14
3.6 Nová obrazovka - Sprint Overview . . . 14
3.7 Časová náročnost úkolů . . . 14
4 Postup řešení zadaných úkolů 15 4.1 Zobrazení počtu příloh u ticketu . . . 15
4.2 Přizpůsobení rozložení obrazovky detailu ticketu dle požadavků uživatele . . . . 16
4.3 Řazení seznamu ticketů na straně serveru . . . 18
4.4 Nová obrazovka - Manage Company . . . 20
4.5 Interní tickety . . . 22
4.6 Nová obrazovka - Sprint Overview . . . 23 5 Uplatněné a scházející znalosti potřebné v průběhu praxe 25
6 Závěr 26
Literatura 27
Přílohy 27
A Ukázka rozšířující metody pro dynamické řazení 28 B Ukázka generické metody pro vytvoření modálního okna 29
Seznam obrázků
1 Tieto logo . . . 11
2 Obrazovka Ticket Detail . . . 17
3 Seřazený seznam ticketů . . . 19
4 Obrazovka Manage Company s otevřeným dialogem pro editaci záznamu. . . 21 5 Hlavní stránka Weblistu se seznamem nejnovějších tiketů obsahujícím interní tikety 23
Seznam tabulek
1 Časová náročnost úkolů . . . 14
1 Úvod
Při výběru témat a zvažování všech možností, jak vykonat bakalářskou práci se mi nejvíce zalíbila možnost absolvování odborné praxe. Hlavním důvodem bylo ověření teoretických vědomostí získaných předchozím studiem a nabytí nových znalostí a zkušeností z praxe v mém oboru, které jsou nepochybně velice důležité pro uplatnění po dokončení studia. Dále mě zajímalo, jak se vyvíjí software ve velké firmě, možnost vyzkoušet si pracovat v týmu, s čímž jsem se při studiu nesetkal, a v neposlední řadě také možnost ověření mých komunikačních schopností v angličtině.
Mou odbornou praxi jsem vykonával ve firmě Tieto Czech s.r.o. na pozici Software Develo- per. Tato firma, v době kdy jsem nastupoval, i v průběhu celé praxe, neustále přijímala nové programátory a to jak na hlavní pracovní poměr, tak i studenty na stáž, čehož jsem využil. Díky předchozím zkušenostem s programováním jsem byl přijat bez problémů.
Hlavním cílem praxe bylo přidávání nových funkčních celků, dle zadání, do již existující webové aplikace, tak aby se s aplikací dobře pracovalo jak zaměstnancům tak i zákazníkům Tieta, pro které ja aplikace určena.
Před započetím praxe bylo v aplikaci spoustu nedodělků a chybějících funkcí. V průběhu praxe jsem pracoval v menším týmu 2-4 lidí, kdy jsme pracovali na implementaci nových funkcí a odstranění veškerých chyb. Ty důležitější z implementovaných funkcí popíši v této práci.
Na počátku představím firmu Tieto, dále aplikaci, na které jsem pracoval a pracovní zařazení.
Poté krátce popíši zadání jednotlivých úkolů a nakonec jejich řešení.
2 Popis odborného zaměření firmy a pracovního zařazení
2.1 Představení firmy
Společnost vznikla v roce 1968 s názvem Tietotehdas Oy. V roce 1995 se jméno změnilo na TT Tieto a v roce 1998 na Tieto. Za rok se při spojení finské společnosti Tieto a švédské společnosti Enator název změnil na TietoEnator. Od roku 2009 platí název Tieto Corporation.
Do České republiky se společnost Tieto dostala v roce 2004, když v Ostravě otevřela svou první off-shore pobočku. Od té doby se stala největším zaměstnavatelem v oblasti IT v morav- skoslezském kraji, kde zaměstnává vice než 2 200 zaměstnanců, což činí českou pobočku třetí největší pobočkou Tieta na světě a to hned po mateřském Finsku a Švédsku. [1]
Obrázek 1: Tieto logo
Tieto se zaměřuje na poskytování IT služeb středním a velkým organizacím. Mezi hlavní nabízené služby patří:
• Aplikační outsourcing
• Podnikové systémy
• Portálová řešení
• Vývoj a správa aplikací 2.2 Pracovní zařazení
Než jsem byl přijat na pozici Software Developera, musel jsem projít výběrovým řízením. To se skládalo ze dvou kol.
V prvním byla přítomna personalistka a manažer týmu, do kterého jsem byl později přiřazen.
Tázali se mne na předchozí zkušenosti s programováním, s prací v týmu a také jsme chvíli konverzovali anglicky.
Ve druhém kole proběhlo setkání s jedním z programátorů, se kterým jsem později spolu- pracoval. Ten se mnou probíral technické věci, ptal se mne zda-li a na jakých projektech jsem v minulosti pracoval a přiblížil mi na čem bych měl pracovat v Tietu.
Následně jsem byl přijat do teamu TIPS(Tieto Integrated Paper Solution), jenž vyvíjí stej- nojmenný software, používaný na celém světě pro řízení papíren. TIPS se používá ve více než 230 papírnách světa, což je téměř 40% podílu a tímto se Tieto řadí mezi tři největší dodavatele softwaru pro papírenský průmysl na světě.
TIPS se dále dělí na několik menších teamů, kdy každý je zodpovědný za jednu část. Jako například:
• TIX - framework pro webové aplikace
• Plánování výroby
• Store - Skladování
• BOM - Kusovníky
• SwS - Softwérová řešení
Jelikož se TIPS stále vyvíjí a někteří zákazníci jej mají upravený dle svých požadavků, vznikají v něm chyby a nové požadavky na změny. Ty je třeba někde reportovat. Pro tento účel slouží ticketovací systém jménem WebList, na jehož vývoji jsem spolupracoval.
2.3 Popis aplikace
WebList je webová aplikace, kde je frontend implementován za použití frameworku Durandal a TypeScriptu. Backend pak využívá technologií C# ASP.NET a pro ukládání dat slouží databáze Oracle. Mezi další využívané technologie, určené zejména pro práci v týmu, patří GIT nebo Visual Studio Team Services.
Jako základ se využívá TIX framework, což je interní framework využívaný ve všech webo- vých aplikacích TIPSu. TIX definuje strukturu aplikace, návrhové vzory, přihlašování uživatelů, multijazyčnost, design webových aplikací, vlastní grid systém a v neposlední řadě také často se opakující prvky v aplikacích jako například: DataGrid, FileUpload, ...
Jedná se o zdánlivě jednoduchou aplikaci, která má však mnoho zajímavých funkcí. Zá- klad tvoří databáze firem využívajících TIPS nebo některou jeho část. Každá firma má pak své lokace, projekty, a další. Při vytváření ticketu se tyto informace společně s popisem problému- /požadavkem na změnu a případnými soubory uloží, tím vznikne nový ticket klasifikovaný jako Incident. Ticket můžou vytvářet jak interní lidé, tak lidé z firem využívajících TIPS. Incident je dále zpracován a dle popisu je vytvořen potomek s klasifikací Problem, Change Request nebo Service Request. Komunikovat s člověkem, který ticket vytvořil je možné pomocí komentářů. O stavu ticketu a o všech jeho změnách jsou příslušní uživatelé informování e-mailem, nebo si tyto informace mohou zjistit otevřením ticketu.
3 Seznam zadaných úkolů
V průběhu praxe jsem pracoval na několika úkolech. V této kapitole popíši jejich zadání 3.1 Zobrazení počtu příloh u ticketu
Úkolem bylo zobrazit celkový počet a počet nových příloh u ticketu. S tím, že při otevření záložky s přílohami se počet nových příloh, pro přihlášeného uživatele, nastaví na nulu. Tento jednoduchý úkol mi byl zadán na počátku praxe a sloužil hlavně k tomu, abych si osvojil všechny základní úkony od vytvoření databázové tabulky, přes namapování tabulky na objekt pomocí Entity Frameworku, vytvoření CRUD operací při použití návrhového vzoru Repository a konečně přenesení dat na frontend, jejich zpracování, zobrazení a případné odeslání na server při akci uživatele.
3.2 Přizpůsobení rozložení obrazovky detailu ticketu dle požadavků uživatele Weblist používá několik desítek až stovek lidí denně a každý z nich má jiné požadavky na rozlo- žení zobrazovaných informací. I když je aplikace plně responzivní, někteří uživatelé používající zobrazovací zařízení s malou šířkou chtějí mít sloupce zarovnané vedle sebe místo pod sebou, tak jak se předpokládá u responzivního rozložení. Pro tento účel bylo třeba navrhnout a imple- mentovat nastavitelný systém zobrazení detailu ticketu dle přání uživatele.
3.3 Řazení seznamu ticketů na straně serveru
Jednou z komponent TIX frameworku je DataGrid. Jedná se o inteligentní tabulku, která nabízí možnosti jako stránkování, řazení záznamů, zobrazování, skrývání a přesouvání sloupců, export do excelu, pdf a další. Její velkou nevýhodou je, že se jedná o frontend komponentu, a operace jako stránkování nebo řazení se provádí na straně klienta, což je při velkém počtu ticketů, v řádu desítek tisíc, problém. 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 Weblistu. Stránkování bylo implementováno ještě než jsem nastoupil na praxi, avšak dyna- mické řazení záznamů na straně serveru jsem implementoval já. Největší výzvou bylo navrhnout řešení tak, aby bylo řazení opravdu dynamické a nezávislé na počtu a směru řazení vlastností (properties) řazeného objektu.
3.4 Nová obrazovka - Manage Company
Do Weblistu se postupně přesouvají funkce z jiných, většinou zastaralých systémů. Jedním z těchto systémů je i TaskTool, ve kterém se mimo jiné spravovalo databázi firem využívajících TIX nebo některou jeho část. Databáze firem se do Weblistu pak importovala. Úkolem bylo navrhnou a implementovat správu databáze firem tak, aby byl zachován starý systém importu z TaskToolu a přibyla možnost přidávat a upravovat nové firmy ve Weblistu.
3.5 Interní tickety
Postupem času se Weblist začal používat čím dál tím častěji, z toho důvodu vznikl nápad vkládat do něj ne jenom odhalené chyby a požadavky na změny ze strany zákazníka, ale také chyby odhalené týmem testerů. Zde však nastal problém, že není žádoucí aby interně odhalené chyby viděl i zákazník. Z tohoto důvodu vznikl požadavek na implementaci takzvaných interních ticketů viditelných pouze pro uživatele s příslušným oprávněním.
3.6 Nová obrazovka - Sprint Overview
Team TIPS využívá pro plánování, správu a agilní vývoj službu Visual Studio Team Services, dále VSTS. V rámci postupné integrace Weblistu a VSTS mi byl přidělen úkol, vytvořit ob- razovku, kde by bylo možné, dle zadaných filtrů, vyhledat a vypsat všechny změněné soubory mezi zadanými iteracemi. Požadavek na vytvoření takovéto obrazovky vznikl z toho důvodu, že například členové testovacího teamu, ale ne jen oni, nemají přístup do VSTS a nemohou tyto změny zjistit tam.
3.7 Časová náročnost úkolů
Úkol Počet dnů
Zobrazení počtu příloh u ticketu 5
Přizpůsobení rozložení ticketu dle velikosti obrazovky 3
Řazení seznamu ticketů na straně serveru 8
Nová obrazovka - Manage Company 25
Interní tickety 5
Nová obrazovka - Sprint overview 10
Tabulka 1: Časová náročnost úkolů
4 Postup řešení zadaných úkolů
4.1 Zobrazení počtu příloh u ticketu
Cílem mého prvního úkolu bylo seznámit se s architekturou aplikace Weblist, frameworku TIX a dalšími technologiemi, se kterými jsem se dříve nesetkal.
Počet nových příloh u ticketu bylo třeba řešit vytvořením nové databázové vazební tabulky, kde se ukládá identifikátor přílohy společně s identifikátorem uživatele. Počet nových příloh se vypočte jako rozdíl mezi všemi a zobrazenými přílohami. Zobrazené přílohy se označí při kliknutí na záložku s přílohami v detailu ticketu.
4.1.1 Backend část
Na počátku bylo třeba vytvořit databázovou tabulku. Ve Weblistu, a ve všech aplikacích použí- vajících TIX framework, se používá přístup database first. Proto bylo nejprve třeba za pomocí programu Toad For Oracle navrhnout SQL příkaz a následně tabulku vytvořit. Poté za pomocí rozšíření Visual Studia TixEntityDesigner vygenerovat příslušné entity pro Entity Framework.
Dále bylo třeba vytvořit rozhraní a samotný repositář s CRUD operacemi. V tomto případě stačilo vytvořit operace pro přidání a výběr dle daného uživatele.
Poté bylo nutné přidat do služby obstarávající práci s přílohami metodu, která přijímá jako parametry identifikátor ticketu a uživatele a zajišťuje pomocí jednoduchého algoritmu srovnání všech příloh se zobrazenými přílohami a následné vypsání počtu nových příloh.
Další novou metodou, byla metoda zajišťující označení právě zobrazených příloh, jež přijímá v parametru identifikátor ticketu společně s identifikátorem uživatele. V metodě se získají z repositářů přílohy pro daný ticket a zobrazené přílohy pro daného uživatele, z nich se vyfiltrují ještě nezobrazené přílohy a ty se zapíší do databáze.
foreach (var shownAttachment in shownAttachments){
allAttachments.Remove(
allAttachments.Find(x => x.AttachmentId == shownAttachment.AttachmentId )
);
}
foreach (var attachment in allAttachments){
AttachmentShownRepo.Add(new AttachmentShown{
AttachmentId = attachment.AttachmentId, UserId = userId
} );
}
Výpis 1: Algoritmus použitý v metodě pro označení zobrazených příloh
4.1.2 Frontend část
Při realizaci frontendu jsem se musel nejprve seznámit s technologiemi zde využívanými. Jak již bylo zmíněno, TIX používá pro frontend framework Durandal společně s javascriptovou nadstavbou TypeScript. Hlavní součástí Durandalu je framework Knockout JS, který řeší pře- nos stavu komponenty do uživatelského rozhraní a zpět. K tomu využívá návrhového vzoru Model–View–ViewModel (MVVM). Jako studijní materiál pro seznámení se s frameworkem Knockout JS mi posloužila dokumentace [2] a výborný tutorial, který se nachází na oficiálním webu frameworku a provází od základů až po pokročilejší techniky. I když byl i TypeScript pro mě novinkou a k jeho studiu mi byla užitečná publikace [3], zdá se mi, že spíš zjednodušuje a zpřehledňuje práci s JavaScriptem, a proto jsem jeho studiu nemusel věnovat tolik času jako Knockoutu.
Samotná implementace již nebyla moc složitá. Počet všech příloh jsem získal z objektu Ticket, ze kterého pochází všechny zobrazované data v obrazovce Ticket Detail a tedy i přílohy a jejich počet. Pro získání počtu nových příloh bylo třeba zavolat automaticky vygenerovanou proxy, dle služby backendu, s požadovanými parametry a v asynchronní odpovědi zachytit výsledek volané služby do Knockout proměnné nazývané Observable. Následně stačilo informace vypsat do pohledu a to pomocí nového HTML atributu data-bind, který přidává Knockout, s parametrem text a příslušnou Knockout proměnnou. Poslední částí bylo označení již zobrazených příloh.
Zde jsem využil opět HTML atributu data-bind, tentokrát s parametrem click a callbackem na funkci, která obstará zavolání služby pro označení právě zobrazených příloh.
<li>
<a href="#tab-attachments" data-bind="click: newFilesCountShow">
Attachments
<span data-bind="text: filesCount"></span>
<span data-bind="text: newFilesCount"></span>
</a>
</li>
Výpis 2: Ukázka HTML kódu s atributy přidanými frameworkem Knockout JS
V prvním sloupci se nachází seznam ticketů, ale pouze tehdy, pokud uživatel přišel na tuto obrazovku z jiné obrazovky, která aktivovala filtr právě prohlížených tiketů. Mezi tikety se lze pohybovat buďto klikáním na jednotlivé položky v seznamu nebo použitím šipek uprostřed prostřední části. Pohybování se v seznamu pomocí šipek jsem implementoval rovněž já. Důležité však je, že někteří uživatelé si přejí tento seznam vidět a jiní zase ne. Pro zobrazování/skrývání tohoto seznamu slouží druhé tlačítko z rozbaleného menu na obrázku 2 Show/hide ticket list.
Další dva tlačítka slouží pro přepínání zobrazení následujících dvou sloupců buďto vedle sebe nebo pod sebou. Prvním tlačítkem je možné resetovat nastavení a vrátit rozložení do výchozího stavu.
Obrázek 2: Obrazovka Ticket Detail
4.2.1 Backend část
Aby nemusel uživatel při každé nové návštěvě Weblistu nastavovat rozložení znovu, je ho třeba ukládat do databáze. Pro tento účel bylo třeba přidat do tabulky s uživateli dva nové sloupce.
V prvním příznak, zda se má či nemá zobrazovat seznam ticketů, a v druhém příznak zda má být zobrazení sloupců vertikální nebo horizontální. Další postup byl velice podobný postupu popsanému v kapitole 4.1.
4.2.2 Frontend část
Framework Durandal umožňuje programátorovi využít tzv. Composition Lifecycle Callbacks, které slouží pro vykonávání potřebných aktivit v průběhu kompozice pohledu[4]. Jedním z těchto callbacků je iActivate(). Jelikož se jako návratový typ očekává JQuery Deferred Promise, je v něm možné provést asynchronní operaci jako například načtení dat ze serveru, avšak při jeho
volání ještě není navázán pohled(view) na DOM předka, z toho důvodu tento callback slouží pouze pro přípravu dat před vykreslováním. Dalším z řady Lifecycle Callbacků je Attached(), který se volá po navázání pohledu na DOM předka tudíž je v něm již možné ovlivňovat pohled například pomocí knihovny JQuery.
Při realizaci toho úkolu jsem využil obou výše popsaných callbacků. V callbacku Activate jsem vytvořil požadavek pro načtení dat ze serveru. V callbacku Attached jsem pak dle dříve načtených dat nastavil daným sloupcům CSS třídy, tak aby se vykreslily dle nastavených pa- rametrů. Obou Lifecycle Callbacků bylo třeba využít proto, aby nedocházelo k nechtěnému viditelnému ’přeskakování’ sloupců. Kdybych například využil pouze callbackuAttached, došlo by k vykreslení sloupců s výchozím rozložením, a pak po dokončení požadavku na server by se teprve sloupce překreslily dle získaných parametrů.
Dále bylo třeba realizovat přepínání zobrazení. Toho jsem docílil použitím Knockout data- bind s parametram click a názvem funkce, která se má zavolat. Ve volané funkci se odešle nové nastavení rozložení na server a znovu se vykreslí aktuální stránka.
4.3 Řazení seznamu ticketů na straně serveru
Jak již bylo v zadání úkolu nastíněno, největší výzvou bylo zajistit dynamické řazení, kdy lze řadit dle více vlastností (properties) najednou. Další komplikací bylo, že objekt obsahující řazené informace neobsahuje pouze vlastnosti primitivních typů nebo typů, které je možné řadit, ale také další vnořené objekty dle jejichž vlastností je třeba řadit. Jediným možným řešením tohoto problému se ukázalo využití reflexe.
Ve výchozím stavu funguje řazení v TIX komponentě DataGrid tak, že při kliknutí na hla- vičku sloupce se položky v daném sloupci seřadí nejprve vzestupně, při druhém kliknutí sestupně, a při třetím se řazení pro daný sloupec vypne. Pořadí, dle kterého se řadí je stejné jako pořadí, ve kterém byly vybírány sloupce. Na obrázku 3 můžeme vidět seznam ticketů seřazený dle sloupce Status vzestupně a následně dle sloupce Headline sestupně. Tento způsob řazení musí být zachován i po přechodu na řazení na straně serveru.
Obrázek 3: Seřazený seznam ticketů 4.3.1 Frontend
Nejprve bylo třeba odstranit původní řazení na straně klienta v prohlížeči. Toho lze elegantně dosáhnout, po načtení všech komponent ve funkci compositionComplete (podobně jako v kapitole 4.2.2), zavoláním jQuery funkce off s parametrem click na všechny hlavičky sloupců, dle kterých lze řadit. Následně bylo třeba zaregistrovat událost kliknutí na tyto hlavičky, v ní upravit pole s informacemi o řazení, nastavit dané hlavičce styl, aby uživatel viděl zda a v jakém směru se právě řadí, a odeslat požadavek na server s novými informacemi o řazení. Jednotlivé položky pole s informacemi o řazení obsahují vždy identifikátor sloupce, dle kterého se řadí a směr řazení.
4.3.2 Backend
Pro tzv. dynamické řazení bylo vytvořeno rozšíření metody OrderBy, z důvodu aby bylo možné takto řadit obecně všechny kolekce, ne jenom seznam ticketů. Nová rozšiřující metoda přijímá jako parametr textový řetězec složený s vlastností a směrů řazení oddělených čárkou, ukázku takového řetězce lze vidět ve výpisu 3.
Status.StatusName, Headline desc
Výpis 3: Ukázka parametru rozšířující metody OrderBy
V rozšiřující metodě se nejprve zpracuje řetězec s informacemi o řazení, v případě že má řetězec neočekávaný formát, vyhodí se výjimka. Řetězec je rozdělen do pole, obsahujícího název vlastnosti a směr řazení. Pole se následně prochází. V každém průchodu se pomocí reflexe zjistí typ dané vlastnosti dle jejího názvu. Pokud se jedná o vnořený objekt, název se rozdělí do pole dle tečky a postupně se prochází až na konec pole. V každém průchodu se typ nastaví na typ právě
procházené vlastnosti. Následně se dle směru řazení a podle toho zda je daná vlastnost první vybere vhodná metoda pro řazení (OrderBy, OrderByDescending, ThenBy, ThenByDescending).
Dále se pomoci reflexe zavolá na kolekci daná řadící metoda s požadovaným lambda výrazem, který je taktéž vytvořen pomocí reflexe. Zkrácenou ukázku rozšiřující metody je možné vidět v příloze A
4.4 Nová obrazovka - Manage Company
Na obrazovce Manage Company lze spravovat veškerá nastavení spojená s konfigurací databáze firem využívajících TIPS. V minulosti se u firem evidovalo pouze několik nastavení, konkrétně jejich Lokace (Locations), Prostředí (Environments), Projekty (Projects) a Moduly (Modules).
Tyto informace nebylo třeba spravovat na straně Weblistu, jelikož společně s ním se používal i systém TaskTool, který obstarával jejich správu a synchronizaci do Weblistu. TaskTool však zastarává, již se nemodernizuje a nové firmy se v něm už neregistrují. Jak se Weblist postupem času rozšiřoval, přibývala nutnost u firem evidovat více a více nastavení. Tato se spravovala přímo v databázi, avšak do databáze mají přístup pouze vývojáři a hlavní manažer, proto tyto informace mohl spravovat pouze on a z toho důvodu vznikla nutnost vytvořit ve Weblistu nástroj pro jejich správu. Zároveň však musel být zachován systém importu z TaskToolu pro firmy registrované v něm.
Problémem bylo, že nová obrazovka pro správu firem nemohla využívat existujících data- bázových tabulek, které se synchronizují s TaskToolem, z toho důvodu, že při jakékoliv změně v těchto tabulkách ze strany Weblistu, by se tabulky znovu synchronizovaly s TaskToolem a data z Weblistu by byla ztracena. Tento problém byl vyřešen zduplikováním TaskToolových tabulek a vytvořením pohledu (view), který pomocí SQL příkazu UNION sjednotí data z obou tabulek a navíc přidá nový sloupec s příznakem, který určuje, zda se jedná o data pocházející z Weblistových tabulek a lze je editovat nebo TaskToolových tabulek a jsou určena pouze pro čtení.
Jak je vidět na obrázku 4, obrazovka Manage Company je rozdělená do tří částí. V první se vyhledá firma, již je třeba konfigurovat. V další části jsou obecné informace a nastavení dané firmy. Třetí část pak obsahuje seznamy rozdělené dle typu pomocí záložek. V prvních čtyřek záložkách se nacházejí informace pocházející z již zmiňovaných, v pohledu sjednocených, tabulek.
Postup jejich konfigurace, a konfigurace informací v poslední záložce TERP task, je totožný.
Jedná se vždy o základní operace (vložení, úprava a odstranění záznamu). Proto bylo vhodné navrhnout řešení konfigurace na straně frontendu tak, aby bylo znovupoužitelné. Navržený a
Obrázek 4: Obrazovka Manage Company s otevřeným dialogem pro editaci záznamu.
4.4.1 Backend část
Nejprve bylo třeba změnit mapování z TaskToolových tabulek na nově vytvořené pohledy, sjed- nocující data z TaskToolových a Weblistových tabulek. Jelikož se v Entity Frameworku pracuje s pohledy velice podobně jako s tabulkami byl tento krok nenáročný.
Dále bylo třeba vytvořit novou službu, která zajišťuje datovou komunikaci nové obrazovky s backendem. Služba obsahuje metody pro vyhledání firmy uložení jejích základních dat a získání potřebných dat o firmě, kdy data jsou přenesena v jednom požadavku, na rozdíl od jiných částí Weblistu, kde se například pro některé seznamy generují požadavky zvlášť, což zpomaluje reakci systému. Dále služba obsahuje metody pro přidání, vymazání a úpravu dat v jednotlivých záložkách.
4.4.2 Frontend část
Při práci s TIX komponenty se občas stane, že daná komponenta nefunguje jak má. Tento případ nastal i při realizaci frontendu obrazovky Manage Company. Problémem bylo, že komponenty DataGrid umístěné v záložkách (záložky v TIXu jsou odvozené od jQuery UI Tabs) se nevy- kreslovaly. Tento problém byl nahlášen vývojovému týmu TIXu, avšak aby se nemuselo čekat na opravu na straně TIXu, byl problém opraven i konkrétně pro nově vytvořenou obrazovku.
Stačilo pomocí JavaScriptu komponentě nastavit šířku dle nadřazeného HTML elementu.
Jak již bylo v popisu obrazovky zmíněno, s většinou dat v záložkách se pracuje stejným způsobem. Data jsou zobrazena v TIX komponentě DataGrid, kdy u každého záznamu je dle příznaku patrné, zda je daný záznam možné editovat. Na každý záznam v tabulce lze kliknout.
Událost kliknutí na příslušný řádek je odchycena, a pokud je daný řádek editovatelný, otevře se modální okno pro jeho editaci. V modálním okně lze řádek jak editovat, tak i smazat. Pro
přidání nového záznamu se používá to samé modální okno, s tím rozdílem že se otevírá bez vyplněných dat a na základě toho je rozpoznáno, že vyplněné údaje mají být přidány.
Modální okno jako takové je TIX komponenta. Má vlastní šablonu(view) a její viewmodel, tyto se vkládají do těla okna. Jelikož je kód pro vytvoření a otevření okna docela dlouhý, byla k tomuto účelu vytvořena generická metoda (Příloha B).
4.5 Interní tickety
U tohoto úkolu bylo třeba klást důraz na to, aby zákazník za žádných okolností nemohl zobrazit ani vytvořit interní tiket, a také aby zaměstnanci Tieta, kteří zpracovávají tikety, na první pohled rozlišili, že se jedná o interní ticket a nemohlo tak dojít k nechtěné chybě. Při návrhu postupu mě napadla dva možná řešení. Veřejné a interní tikety bylo třeba oddělit na úrovni databáze.
U prvního řešení jsem předpokládal zduplikování existující tabulky obsahující veřejné tickety.
Nová tabulka by pak obsahovala interní tikety a na aplikační vrstvě by se rozhodovalo, dle oprávnění uživatele, zda se zobrazí pouze veřejné tikety nebo i interní.
Druhým možným řešením bylo přidání sloupce do tabulky s tikety, který by sloužil jako příznak určující, zda se jedná o veřejný či interní tiket. Dále, podobně jako v prvním návrhu řešení, by se o zobrazení/nezobrazení interních tiketů rozhodovalo na aplikační vrstvě.
Jelikož každý tiket má své jedinečné číslo tvořené zkratkou firmy, pořadím tiketu pro danou firmu a typem tiketu, u obou řešení by bylo třeba také přidat do tabulkyCompany nový sloupec s číselnou řadou interních tiketů.
Po konzultaci s dalšími programátory z teamu bylo vybráno první možné řešení, a to hlavně z důvodu jednodušší implementace a tedy i menší pravděpodobnosti chyb.
4.5.1 Backend část
V backend části, díky zvolení jednoduššího postupu, nebyla práce až tak náročná. Stačilo upravit entituTicketaCompany dle databázové tabulky. Dále v repositáři, v metodě pro získávání všech ticketů bylo třeba omezit výpis interních tiketů, pokud je právě přihlášený uživatel zákazník.
Nakonec, v metodě pro přidávání ticketu, zvolit správnou číselnou řadu a nastavit prefix, pokud je přidávaný ticket interní.
4.5.2 Frontend část
Ve frontend části bylo práce více, a to hlavně z toho důvodu, že bylo třeba upravit všechny
Dále bylo třeba upravit stránku s detailem tiketu, která slouží zároveň pro přidávání ticketu tak, aby bylo možné přidávat i interní tikety.
Obrázek 5: Hlavní stránka Weblistu se seznamem nejnovějších tiketů obsahujícím interní tikety
4.6 Nová obrazovka - Sprint Overview
Před započetím realizace tohoto úkolu jsem se musel nejprve seznámit se základy VSTS a s REST API VSTS. Po konzultaci s ostatními programátory jsme došli k závěru, že by bylo vhodné použít oficiální nadstavbu nad REST API Microsoft.VisualStudio.Services.Client, která ulehčuje práci tím, že zajišťuje vykonávání HTTP požadavků a zprošťuje programátora od nutnosti práce s JSON tím, že jej mapuje na objekty.
V průběhu realizace jsem narazil na problém, kdy bylo třeba, z důvodu neexistence potřebné API, odesílat na server několik desítek až stovky požadavků, což samozřejmě trvalo velice dlouhý čas. Tento problém jsem se, po konzultaci se zkušenějším programátorem, rozhodl řešit pomocí asynchronních metod. Časový rozdíl u synchronního a asynchronního přístupu byl více než dese- tinásobný. S asynchronními metodami jsem se před realizací tohoto úkolu dříve nesetkal, proto jsem se nejprve musel naučit základy práce s nimi. Dalším možným řešením bylo synchronizo- vat potřebná data do databáze Weblistu, avšak tento přístup by byl zbytečně komplikovaný a zdlouhavý, proto byl zavržen.
4.6.1 Backend část
Backend se podobně jak při získávání dat z databáze drží návrhového vzoru Repository, avšak využívá asynchronních metod.
V první, jednodušší části, bylo třeba získat data pro filtry, dle kterých se hledají změny mezi iteracemi. Šlo o získání všech projektů a následně dle vybraného projektu všech definicí. Čísla iterací se zadávají ručně a jsou to vždy celá čísla v definovaném rozsahu, z toho důvodu je nebylo třeba získávat ze serverů VSTS, ale kontrola správnosti mohla proběhnout ve Weblistu.
Realizace druhé části již byla náročnější z toho důvodu, že bylo třeba najít způsob jak potřebná data získat. Nejprve bylo třeba získat všechny tzv. WorkItemy pro daný projekt, jeho zadané build definice a zadaný rozsah iterací. V metodě pro získaní WorkItemů se nejprve zkontroluje, zda všechny zadané build definice existují, poté se pro ně získá první a poslední Build Task, dle zadaného rozsahu iterací, a následně se získají všechny Work Itemy mezi prvním a posledním Build Taskem. Dále bylo třeba pro jednotlivé Work Itemy získat všechny soubory, které se změnily. Z počátku se zdálo, že to nebude velký problém a potřebná data se získají jedním voláním na VSTS server. Bohužel se ukázalo, že VSTS API nefunguje jak má a bylo třeba pro každý Work Item zvlášť vytvářet požadavek na VSTS server. To se však, při počtu v řádech desítek až stovek Work Itemů ukázalo jako veliký problém pro odezvu. Z toho důvodu bylo třeba využít asynchronních metod, kdy se všechny požadavky odešlou na server ’najednou’, tento přístup celou operaci zrychlil až patnáctinásobně.
Po získání potřebných dat, je bylo třeba uspořádat tak aby se na frontend přenášely pouze potřebné informace a jelikož se počet Workitemů pohybuje ve stovkách a každý z nich má až několik desítek změněných souborů, na frontendu byla využita TIX komponenta DataTreeView, která umožňuje zobrazit data ve stromové struktuře, z toho důvodu tak byla data v backendu uspořádána.
4.6.2 Frontend část
Frontend část byla jak na implementaci, tak i časovou náročnost podstatně méně náročná, hlavně díky tomu, že zde byly využity TIX komponenty.
Jako první bylo třeba načíst z backendu seznam všech projektů a zobrazit je pomocí HTML formulářového prvku select. Dále, na změnu proměnné (Knockout Observable), která představuje vybraný projekt, navázat událost, při které se získá ze serveru seznam Build Definic a tento zobrazit v TIX komponentě multiselect. Tyto dvě komponenty společně s HTML inputy pro vložení rozsahu iterací tvoří filtr, dle kterého se při stisku tlačítka hledat odešle požadavek na server a pokud byly nalezeny nějaké změny souborů pro zadaný filtr, vypíší se v TIX komponentě DataTreeView.
5 Uplatněné a scházející znalosti potřebné v průběhu praxe
V průběhu vykonávání odborné praxe jsem využil a ověřil mnoho znalostí nabytých studiem na univerzitě. Základy programování jsem získal v předmětu Programování I, základy objek- tově orientovaného programování pak v předmětu Programování II. Jelikož jsem během praxe využíval zejména programovací jazyk C# společně s .NET frameworkem, byly pro mě důležité znalosti získané v předmětech Programovací jazyky II a Architektura technologie .NET. Nedíl- nou součástí informačních systémů jsou databáze, jejich návrh a tvorba SQL dotazů, v tomto ohledu mi byly velice užitečné předměty Úvod do databázových systémů a Databázové a infor- mační systémy. V neposlední řadě jsem využil taktéž znalostí získaných v předmětech Algoritmy I a II. Dále, při třídním návrhu jsem využil znalostí z předmětu Vývoj informačních systémů.
Studium předmětu Skriptovací programovací jazyky a jejich aplikace mi bylo užitečné při vývoji frontendu, i když se v tomto předmětu vyučoval jazyk Python, princip skriptovacích jazyků je stejný i pro Javascript, který bylo během praxe také nutné znát. Při vývoji frontendu jsem využil rovněž znalostí z předmětu Vývoj internetových aplikací. Nakonec i pro napsání této práce jsem získal potřebné znalosti LATEXu díky předmětu Elektronické publikování.
Ač jsem díky studiu na univerzitě získal mnoho znalostí, některé mi během vykonávání odborné praxe chyběly. Důvodem bylo buď to, že jsem již neměl prostor pro zapsání daného předmětu, daná problematika se v rámci žádného předmětu neprobírala, anebo z toho důvodu, že zejména praktické zkušenosti se při studiu získávají jen těžko.
U některých úkolů bylo třeba pracovat v týmu, avšak v rámci studia jsem vypracovával projekty vždy sám, proto jsem měl v této oblasti značné nedostatky a musel jsem se učit napří- klad pracovat s verzovacím systémem GIT nebo velice přínosným nástrojem pro práci v týmu Microsoft VSTS. Při vývoji frontendu mi chyběly potřebné znalosti pro práci s Javascripto- vým frameworkem. Ač je takových frameworků v době psaní této práce nepřeberné množství, alespoň základy některého ze známějších by mohly být zařazeny například v předmětu Vývoj internetových aplikací.
6 Závěr
Na počátku jsem zvažoval jak vykonat bakalářskou práci. Vybral jsem si možnost absolvování odborné praxe a jsem přesvědčen, že tento výběr byl správný. Díky absolvování odborné praxe ve firmě Tieto jsem získal spoustu zkušeností, jak probíhá ve velké nadnárodní korporaci vývoj software, jak se pracuje v menším týmu, vyzkoušel jsem si komunikaci v cizím jazyce a hlavně jsem prohloubil své znalosti nabyté při studiu na univerzitě a ověřil je v praxi. Nespornou výhodou vykonání bakalářské práce jako praxe ve firmě je i získání praktických zkušeností, které jsou velice důležité na trhu práce.
První dny praxe jsem strávil zejména studiem potřebných, pro mně nových, technologií, seznamováním se s vyvíjeným systémem a také pracovním prostředím a kolegy z teamu. Poté mi byly svěřovány nejrůznější úkoly, které jsem vždy zdárně dokončil a předal k produkčnímu používání.
V průběhu praxe jsem pouze neprogramoval, ale setkal jsem se i se správou operačního systému Windows Server, správou DBMS Oracle nebo nasazením aplikace na produkční server.
Na počátku byl vyvíjený software Weblist spíše podpůrným systémem, v průběhu praxe se do něj přidalo mnoho nových funkcí a stával se čím dál více používanou a důležitou součástí celého balíku TIPS, kterou denně využívají stovky lidí.
S výběrem tématu i s průběhem mé bakalářské práce jsem byl velice spokojen.
Literatura
[1] [online]. [cit. 2018-03-29]. Dostupné z: https://www.tieto.cz/tieto-o-nas
[2] [online]. [cit. 2018-04-24]. Dostupné z: http://knockoutjs.com/documentation/introduction.html [3] PARDI, Paul. Typescript Programming Language. 06. listopad 2015, , 288 [cit. 2018-04-24]
[4] [online]. [cit. 2018-03-29]. Dostupné z: http://durandaljs.com/documentation/Hooking- Lifecycle-Callbacks.html
A Ukázka rozšířující metody pro dynamické řazení
public static IQueryable<T> OrderBy<T>(this IQueryable<T> collection, string orderBy){
foreach (OrderByInfo orderByInfo in ParseOrderBy(orderBy)){
string[] props = orderByInfo.PropertyName.Split(’.’);
Type type = typeof(T);
ParameterExpression arg = Expression.Parameter(type, "x");
Expression expr = arg;
foreach (string prop in props){
PropertyInfo pi = type.GetProperty(prop);
expr = Expression.Property(expr, pi);
type = pi.PropertyType;
}
Type delegateType = typeof(Func<,>).MakeGenericType(typeof(T), type);
LambdaExpression lambda = Expression.Lambda(delegateType, expr, arg);
string methodName = string.Empty;
...
collection = (IOrderedQueryable<T>)typeof(Queryable) .GetMethods()
.Single(
method => method.Name == methodName
&& method.IsGenericMethodDefinition
&& method.GetGenericArguments().Length == 2
&& method.GetParameters().Length == 2) .MakeGenericMethod(typeof(T), type)
.Invoke(null, new object[] { collection, lambda });
} }
B Ukázka generické metody pro vytvoření modálního okna
private initEditDialog<VM extends interfaces.ISavableDialog, T>
(
caption: string, dialogCtor: VM,
save: (data: T) => void = undefined, del: (data: T) => void = undefined ): modalDialog.ModalDialog<VM> {
var dialog = new modalDialog.ModalDialog<VM>(dialogCtor, { ... });
var saveButton = new modalDialog.ModalDialogButton({
caption: "Save", buttonCommand: {
$.when(dialogCtor.save())
.done(data => { save(data) ...})
var closeButton = new modalDialog.ModalDialogButton({caption: "Close"...
var deleteButton = new modalDialog.ModalDialogButton({caption: "Delete"
...
dialog.addButton(saveButton);
...
return dialog;
}
