VŠB – Technická univerzita Ostrava Fakulta elektrotechniky a informatiky
Katedra informatiky
Absolvování individuální odborné praxe Individial Professional Practice in the
Company
Abstrakt
Tato bakalářská práce popisuje průběh mé odborné praxe, jejíž větší část proběhla na pozici Software Developer ve firmě Tieto.
Práce je rozdělena na krátký popis mého působení ve firmě Tieto, představení firmy, představení projektu, na kterém jsem se podílel s popisem používaných technologií.
Hlavní část praxe je věnována popisu řešených úkolů formou pracovního deníku, ve kterém popisuji pouze některé úkoly, které jsem vyřešil.
Na konci práce shrnu služební cestu do Polska a závěr věnuji celkovému zhodnocení.
Klíčová slova: odborná praxe, Tieto, C#, JavaScript, ArcGis, služební cesta
Abstract
This bachelor thesis describes the course of my professional experience, most of which was held in the position of Software Developer in Tieto.
The work is divided into a brief description of my activities in Tieto company, company presentation, presentation of the project I participated in and description of used technologies.
The main part of the practice is devoted to the description of the solved tasks in the form of a working diary, in which I describe only the more extensive tasks that I have solved.
At the end I will summarize the business trip to Poland and I will concentrate on the overall evaluation.
Key words: professional practice, Tieto, C #, JavaScript, ArcGis, business travel
Obsah
Úvod ... 1
1. O Firmě ... 2
2. Představení pozic a teamu ... 3
2.1 NMA Team ... 3
2.2 Automation GUI Tester ... 3
2.2.1 Hodnocení mého působení ... 3
2.3 Software developer ... 4
3. Titanium ... 5
3.1 Používané jazyky ... 5
3.2 Používané Frameworks ... 5
3.3 Databáze ... 5
3.4 ArcGIS ... 5
3.5 Verzování ... 5
4. Pracovní deník ... 7
4.1 Předmluva ... 7
4.2 Snapping ... 7
4.3 Optimalizace ... 7
4.4 Earth Measurement Tool a kopírování geometrie ... 8
4.5 Password change a password reset ... 12
4.6 Otevření Substation schématu na zákaznickém prostředí ... 13
4.7 Schema Template ... 13
4.8 Coordinate Series ... 15
4.9 Rss News widget ... 16
5. Služební cesta do Polska ... 20
5.1 Hodnocení cesty ... 20
6. Zhodnocení znalostí a dovedností ... 21
6.1 Znalosti scházející v průběhu odborné praxe ... 21
6.2 Znalosti uplatněné v průběhu odborné praxe ... 21
Seznam použitých zkratek a symbolů
GUI – Grafické uživatelské rozhraní
TC – Test case
HTML – HyperText Markup Language, značkovací jazyk
.NET – Soubor technologií pro vývoj software
ASP .NET – Součást .NET Frameworku pro tvorbu webových aplikací
MVC – Model View Controller
ArcGis – Geografický informační systém
API – Application Programming Interface, rozhraní pro programování
JS – JavaScript
TSU – Tieto Smart Utilities
URL – Uniform Resource Locator
NMA – Network Management Automation
GIS – Geografický Informační Systém
Seznam obrázků
Obrázek 1: Webová aplikace Titanium ... 5 Obrázek 2: Porovnání úspory času při kreslení ... 8 Obrázek 3: Ukázka EMT - měření trasy ... 9
Seznam výpisů kódu
Výpis 1: Doplnění pro switch... 10
Výpis 2: metoda fillClipboardFromEMT ... 11
Výpis 3: Metoda pro případné přidání nového schematu ... 15
Výpis 4: Úprava header při parsování ... 16
Výpis 5: Serializace objektů do Json ... 17
Výpis 6: Vypsání jednotlivých zpráv zpráv ... 18
Výpis 7: Generování DIV tagů ... 19
Úvod
Rozhodnutí vybrat si praktickou bakalářskou práci padlo již nějakou dobu před ukončením druhého ročníku Bc. studia z několika důvodů. Ve firmě Tieto jsem pracoval již od počátku studií na pozici Control Desk specialisty, už od začátku jsem byl rozhodnut využít skvělé příležitosti praktické bakalářské práce, při které jsem vycítil příležitost uplatnit teoretické znalosti v praxi, přijít na to, jak probíhá vývoj software ve velké firmě a hlavně se mnohému z tohoto oboru naučit.
Moje praktická Bc. práce tedy začala na pozici Automation GUI Tester, kde jsem měl za úkol
udržovat testovací prostředí v chodu, spravovat existující již zautomatizované TC a vytvářet nové. Na této pozici jsem nevydržel moc dlouho. Po chvíli se ukázalo, že se na této pozici moc k odhalení procesů vývoje software nepřiblížím a že se nemám co dál učit a také mě to nenaplňovalo, proto jsem využil příležitosti a souhlasil jsem s přesunem na volnou pozici Software Developer, což se později ukázalo jako nejlepší možné rozhodnutí.
Hlavní část této zprávy z praxe bude tvořit popis některých úkolů, které jsem musel zvládnout. Z chronologického popisu jsem se rozhodl vynechat úkoly, které byly příliš jednoduché, nebo obsahovaly příliš mnoho pro firmu citlivých informací.
V posledním úseku této práce bude kratší kapitola na téma služební cesty do Polska, na závěr mé práce zhodnotím získané znalosti, dovednosti a můj celkový přínos firmě Tieto.
2
1. O Firmě
Založena byla již v roce 1968. Současný stav zaměstnanců po celém světě se blíží k 15000. Tieto Czech zahájilo svou činnost v roce 2004 jako první softwarové centrum, tehdy počet zaměstnanců v Ostravě čítal pouze 54 osob, nicméně se geometrickou řadou rozrůstal a nyní čítá již přes 2200
zaměstnanců. Tieto Czech se díky tomu stal největším IT zaměstnavatelem v Moravskoslezském kraji. [1]
Tieto je největší severoevropská IT společnost poskytující komplexní IT servis. Zajišťuje také služby v oblasti vývoje produktů pro firmy působící v odvětví komunikací a integrovaných technologií. Na základě svých znalostí, technologických vizí a inovativního myšlení se společnost Tieto aktivně snaží inspirovat a zapojit své zákazníky do hledání nových způsobů, jak zefektivnit jejich podnikatelskou činnost.
Tieto spojuje globální možnosti s přítomností na lokálních trzích a zároveň staví na svém severském odkazu. Společnost Tieto se sídlem ve finských Helsinkách zaměstnává přes 13 000 expertů téměř než 20 zemích světa. Obrat činí přibližně 1,5 miliard eur. Akcie společnosti Tieto jsou obchodovány na burze NASDAQ v Helsinkách a Stockholmu. [2]
2. Představení pozic a teamu
2.1 NMA Team
Tým, ve kterém jsem působil po většinovou dobu mé praxe. V NMA teamu je ve chvíli, ve kterou píši tento text osm vývojářů, včetně mě, čtyři kmenový testeři a další tři testeři na poloviční úvazek, to jsou studenti. NMA team je odnož Tieto Smart Utilities, dále jen TSU. Věnujeme se tvorbě GIS systémů souvisejících s energetikou. Pod TSU spadá několik aplikací. Aplikace, na které pracujeme se jmenuje Titanium.
2.2 Automation GUI Tester
Jako Automation GUI tester jsem působil velmi krátce. Mým hlavním úkolem byla správa existujících zautomatizovaných testů, což zahrnovalo i základní správu serverů, na kterých se GUI testy pravidelně v noci spouštěly. Na této pozici jsem se setkal s následujícími technologiemi.
• SoapUI – Pohodlný nástroj pro samotnou tvorbu automatických testů. Používá REST požadavky, ze kterých vytváří elementární prvky. Z těchto elementů se poté skládají další, komplexnější prvky, například kliknutí na komponentu. Z těchto komplexnějších částí se skládají jednotlivé automatické testy.
• Groovy – Skriptovací jazyk pro platformu Java. Groovy skripty se v projektu používají zejména pro usnadnění práce, popř. pro zavedení logiky do automatického testu, například při potřebě porovnat výsledky dvou různých testových kroků, které čtou z GUI nějakou hodnotu nebo hodnoty.
• Test Runner – Interní webová aplikace psaná v Ruby, umožňuje paralelní spouštění testů, a to následující technikou. Celá aplikace běží na serveru s označením hub, ten využívá server nebo servery označené node, na kterých spustí a řídí session prohlížeče, na kterém pouští celé sady automatických testů, kterým se říká Test Suite. Výsledky testů drží ve vlastní databázi, včetně logů a snímků obrazovky v okamžiku případné chyby.
2.2.1 Hodnocení mého působení
Po rychlém naučení práce s Xpath, což je adresovací jazyk, pomocí kterého lze identifiovat konkrétní element, a osvojení Groovy jsem vytvořil celou sadu testů podle předem definovaných specifikací pro čerstvě vytvořenou část aplikace, která se zabývala správou uživatelů.
Za krátký čas, který jsem na zmíněné pozici byl, se ukázaly dva problémy související s dosavadním špatným stavem automatických GUI testů.
Současné testy nebyly atomické, byly v obrovské míře závislé na service testech, které po sobě zanechávaly data v určitém stavu a pokud tomu tak nebylo, popř. se data změnily, docházelo ke zbytečným chybám. Service testy jsou typy testů. které pouze vyvolávají funkcionalitu, bez ohledu na prezentační vrstvu.
4
Spousta testů byla doslova hardcoded, nastávaly nechtěné situace, pří kterých se například test odrážel od specifického řádku v tabulce, identifikovaného konkrétním ID, na kterém dále prováděl zbytek testu. Správná varianta by byla, kdyby byl xpath pro daný test napsán tak, aby byl dynamický.
Tyto problémy bylo třeba začít řešit, neboť podobným způsobem nešlo z dlouhodobého hlediska GUI testy udržet v rozumném stavu. Proto jsem po konzultaci s vedením navrhl, aby došlo k vytvoření nového samostatného prostředí pro GUI testy, nicméně zde mé působení končí, odsouhlasenou
migraci a revizi testů měl již na starost můj nástupce
2.3 Software developer
Po přestupu na novou pozici jsem se začal věnovat vývoji našeho produktu. Šlo o programování jak backend, tak frontend. Zprvu jsem většinu pracovní doby trávil řešením různých chyb, nicméně postupem času jsem se dostal k úkolům, které zahrnovaly vytváření kompletně nových částí aplikace.
Ke konci praxe jsem se také dostal na služební cestu do Polska, podrobněji shrnuta je na konci práce.
3. Titanium
Jedná se o webovou GIS aplikaci, která slouží pro plánování, navrhování a správu energetických sítí, stanic a atributů. Aplikace zahrnuje spoustu různých souvisejících komponent a vlastností.
Obrázek 1: Webová aplikace Titanium
3.1 Používané jazyky
Titanium je psané za pomocí C# 5, .NET 4.5, JavaScript, HTML5, CSS3, Python.
3.2 Používané Frameworks
.NET 4.5, ASP .NET MVC 5, Asp .NET Identity framework, Entity framework, Dojo, JQuery + plugins, Esri JavaScript Api 3.xx, ArcObjects for .NET, Bootstrap + plugins
3.3 Databáze
MSSQL 2014
Databáze se dělí na tři hlavní části:
1. Databáze pro správu uživatelů, Asp. NET Identitiy Framework 2. Databáze pro konfiguraci a metadata
3. Databáze pro business data, používáme Esri verzovanou geodatabázi.
3.4 ArcGIS
ArcGIS je Geografický informační systém pro práci s mapami a geografickými daty ve všech směrech. Systém poskytuje infrastrukturu pro vytváření map a geografických informací napříč organizacemi, komunitami i otevřeně pro web. [3]
Dále poskytuje aplikace pro správu geodat a různá API pro integraci s jinými systémy.
3.5 Verzování
ArcGIS umožňuje používat verzovanou geodatabázi. To přináší možnost editovat stejná data pro více uživatelů a mít kontrolu nad návrhem sítě i při více uživatelích a projektech. [4]
Naše verzování ve zjednodušené podobě vypadá takto:
6 1. Top
a. Projekt i. Plan
- Alternativa
Pro uživatele to poté znamená následující. V Top verzi se nachází aktuální stav existující, vybudované sítě. Pokud se rozhodne firma vyprojektovat novou část sítě, založí se projekt obsahující plán, plán se skládá z jednotlivých alternativ, alternativa obsahuje veškerá data z topu. V praxi potom na jednom plánu může pracovat současně X lidí v jednotlivých alternativách, které se poté sloučí do plánu a plán se poté pošle do top verze. Projekt používán není, z plánu se změny posílají rovnou do top verze.
4. Pracovní deník
4.1 Předmluva
Jak již zaznělo v úvodu, rozhodl jsem se z pracovního deníku vyřadit některé úkoly.
Konkrétně všechny jednodušší a citlivé úkoly, které například obsahovaly příliš mnoho business logiky. Pokud popíši konkrétní i jednodušší úkol, znamená to, že něčím vyčníval, například jsem se při jeho řešení dozvěděl novou, klíčovou informaci.
4.2 Snapping
Jako první samostatný úkol jsem řešil chybu, týkající se přichytávání kurzoru na konkrétní prvek. Při navrhování nové sítě přichytávání nefungovalo u dvou typů prvků sítě. Konkrétně šlo o
“External connection box” a “Station”. Po krátké konzultaci s jedním z kolegů jsem zjistil, že pravidla pro přichytávání jsou definována jako procedury v naší databázi. Zmíněné procedury nicméně kompletně chyběly. Bylo třeba zjistit, jakých typů sítě se týkají a procedury dopsat.
4.3 Optimalizace
Hned druhý úkol, který jsem dostal mě docela překvapil, jednalo se totiž o optimalizaci zakreslování cest s vedením.
Cesta či trasa je virtuální část sítě, podobně jako ulice. Víme, kde je, kudy se táhne, ale fyzicky se nejedná o prvek.
Konkrétní problém byl v dlouhé čekací době při kreslení do mapy v případě, že se kolem afektované lokace nacházelo hodně existujících cest a částí vedení.
V případě zakreslení cesty s vedením zároveň se používá šablona, to znamená, že není třeba zakreslit zvlášť cestu a na ni vedení. Při použití této šablony se pomocí algoritmu počítá, jak a kolik má vzniknout cest, neboť je možné při zakreslování použít už existující cesty. Tento algoritmus, se používá i při přidávání prvků do existující sítě. Algoritmus, jehož jsem nebyl autorem, procházel všechny existující trasy v afektované lokaci, což je správně, nicméně po prozkoumání a všech částí kódu a následném proměření času stráveným nad jednotlivými fázemi algoritmu jsem došel k tomu, že čas při celém procesu zakreslení exponenciálně rostl v místě, kde se počítala nejkratší vzdálenost mezi bodem a úsečkou. Bylo to z toho důvodu, že autor použil ArcGis funkcionalitu pro výpočet vzdálenosti, a proto musel bod i úsečku převést na ArcGis objekty. Samotná konverze probíhala 10 až 100 ms při lokálním spuštění a řádově deseti násobně méně při běhu na našem TI_DEV serveru. TI_DEV je náš server vyčleněn pro vývoj.
Problém byl ale v tom, že ve spousty případech se tento výpočet prováděl i 3000krát. Celkový průměrný běh algoritmu v problémovém místě tedy trval 150 sekund na lokálním stroji a na serveru okolo 15 sekund. Díky tomuto zjištění jsem nahradil výpočet vzdálenosti vlastním kódem, který počítal s holou geometrií bez potřeby převodu na ArcGis objekt. Výsledkem bylo zkrácení kreslení o zhruba 14 sekund na našem TI_DEV serveru, což byla takřka 75 % úspora času při zakreslování do mapy celkově, nutno totiž dodat, že časem se přešlo od původního postupu a byly přepsány všechny metody pro výpočty vzdáleností mezi různými typy prvků. Na níže uvedeném grafu je k náhledu stav časů potřebných pro zakreslení před a po úpravě.
8
Obrázek 2: Porovnání úspory času při kreslení
4.4 Earth Measurement Tool a kopírování geometrie
Earth Measurement Tool (dále jen EMT) je small widget, který již existoval. V Titániu používáme vlastní widgety, které máme rozdělené na:
1. Small widget, je součástí mapy, viz. obrázek níže.
2. Large widget, je části aplikace, která se otevře v jednom ze dvou hlavních oken aplikace ve vlastní záložce.
Obrázek 3: Ukázka EMT - měření trasy
EMT se používá k vyměření přesné polohy bodu, délky vícebodové trasy, nebo vyměření obsahu polygonu.
Mým konkrétním úkolem bylo doplnit funkcionalitu kopírování geometrie do schránky zařízení v podobě “x y” u bodu a “x1 y1 x2 y2 ...” u vícebodové trasy nebo polygonu tak, aby po stisknutí klávesové zkratky “ctrl + v” mohl uživatel s obsahem pracovat dál. Tato funkcionalita je klíčová, neb se používá při přesném zakreslování. Zakreslovat se potom nemusí ručně od oka, ale podle předem daných vyměřených bodů či úseček s přesnou polohou na mapě. V praxi si tedy například lze přesně vyměřit dráhu, po které má vést nová trasa vedení, v EMT vše přesně zkontrolovat (polohy bodů, délku, popř. obsah) a poté jedním klikem vše zakreslit. Kreslení totiž nabízí možnost zakreslovat podle předem vložených bodů s určitou polohou. Use Case pro samotné zkopírování vyměřené geometrie poté probíhá tak, že po vyměření stačí kliknout pravým tlačítkem a poté zvolit položku pro kopírování geometrie do paměti počítače.
Konkrétní postup jsem zvolil následovný:
1. Upravit místo v JS, kde dochází ke zpracování kliku kontextové nabídky. V podstatě šlo pouze o jednoduché přidání do existujícího switche, který zpracovává kliknutí pravým tlačítkem myši.
10 case "coordsToClipboard":
var location = this.sideMapButtonToolBarController.toolbarButtonWidgetsDiction- ary['buttonMapMeasurementTool'].getAllGeometry();
this.fillClipboardFromEMT(location);
break;
Výpis 1: Doplnění pro switch
Přičemž location je objekt, do kterého se uloží jednotlivé body pro uložení do paměti, což zařídí metoda fillClipboardFromEMT, která vypadá následovně.
fillClipboardFromEMT: function (data) { var that = this;
var textArea = document.createElement("textarea");
textArea.style.position = 'fixed';
textArea.style.top = 0;
textArea.style.left = 0;
textArea.style.width = '2em';
textArea.style.height = '2em';
textArea.style.padding = 0;
textArea.style.border = 'none';
textArea.style.outline = 'none';
textArea.style.boxShadow = 'none';
textArea.style.background = 'transparent';
var stringData = "";
data.forEach(function (element) {
stringData += element.x + ' ' + element.y + ' ';
});
$(textArea).val(stringData);
document.body.appendChild(textArea);
textArea.select();
var notification = {
Title: that.appController.appControllerLangTexts.CopyToClipboard, Text: that.appController.appControllerLangTexts.ClipboardChangedFail, Type: that.appController.NotificationsServer.notificationType.Error };
try {
var successful = document.execCommand('copy');
notification = {
Title: that.appController.appControllerLangTexts.CopyToClipboard,
Text: successful ? that.appController.appControllerLangTexts.ClipboardChanged : that.appController.appControllerLangTexts.ClipboardChangedFail,
Type: successful ?
that.appController.NotificationsServer.notificationType.Success : that.appController.NotificationsServer.notificationType.Error };
}
catch (err) {
console.warn('Oops, unable to copy!');
}
finally {
that.showNotification(notification);
}
document.body.removeChild(textArea);
}
Výpis 2: metoda fillClipboardFromEMT
3. Na MapMeasurementTool.js dodělat konkrétní logiku, z důvodu bezpečnosti nemohu ukazovat kompletní kusy kódu (celou funkční třídu), nicméně mohu říct, že jsem vytvořil v podstatě “chytrý zásobník”. Chytrý proto, neboť jsem musel vést v patrnost to, že lze měřit ve třech různých modech, jak už zaznělo v úvodu, a to konkrétně bod, úsečka a polygon.
Dozajista není třeba vysvětlovat, že bylo nutné ošetřit několik příkladů, například nelze použít
12
korektní geometrii v případě, že uživatel proměřuje polygon, ale má zatím pouze dva body, které by se mohly tvářit jako úsečka.Vzhledem k tomu, že samotný výpočet měřených hodnot zařizuje jedna z ArcGis služeb, bylo nutné nebrat v potaz fyzické kliky na mapě, ale až výsledné body, které se na mapu skutečně podařilo umístit. K tomu jsem se rozhodl použít ArcGis js API a identifikováním správných událostí se mi podařilo na úrovni JS odchytit chvíli, kdy se poslední klik zdál validní z toho pohledu, že byl skutečně na mapě zakreslen.
Mnou vytvořená funkcionalita nějakou dobu fungovala nicméně se ukázalo, že mé poslední rozhodnutí nebylo dobré, neboť při čekání na event mohlo při extrémně rychlém klikání dojít k chybě.
Rozhodl jsem se tak z důvodu chybějících znalostí, vše bylo opraveno, když jeden z mých kolegů nahradil zmíněné čekání na event ze strany ArcGis prací s grafickou vrstvou. Nebylo tedy nutné ověřovat, zda klik proběhl a bod se na mapu dostal na úrovni ArcGis, ale až na úrovni grafické vrstvy.
Pokud na grafické vrstvě není bod vykreslen, není pochyb, že fyzický klik se na mapu “nedostal”.
4.5 Password change a password reset
Nad tímto úkolem jsem strávil několik dní, doposud nebylo v aplikaci uživatelům umožněno změnit si vlastní heslo ani požádat administrátora o změnu hesla. Proto jsem dostal úkol toto napravit.
User Management je jedna z citlivějších částí aplikace na bezpečnost, proto nebudu přikládat žádné kódy a pokusím se pouze o strohý popis.
V Titaniu používáme MVC, nicméně business logiku se vším všudy nemáme na MVC. MVC je pouze jeden z 16 sub projektů, které aplikaci jako takovou tvoří. Brána k business logice je sub projekt Titanium Services. Celý princip volání funkcí na Titánium Services je následovný.
Nejdříve je třeba vytvořit metodu nebo funkci, na MVC Controller, která zpracovává nějakou akci.
Z této metody poté interní aplikace vygeneruje REST Client třídu, která se postará o zavolání funkce nebo metody na Titanium Services. Funkci volá pod stejným názvem, z jaké byla volána na MVC Controlleru.
Titanium Services Controller má poté přístup do dalších částí aplikace, ve kterých je business logika.
Moje výsledná práce vypadala tedy následovně.
1. Nejdříve jsem vytvořil za použití ASP.NET Razor C# a HTML cshtml soubory, pro všechny potřebné formuláře.
2. Poté jsem vytvořil potřebné funkce na MVC Controller a to jak pro získání a zobrazení cshtml formulářů tak pro samotnou změnu nebo resetování hesla. Zabezpečení těchto metod probíhá specifikováním tagu, ve kterém je uvedena skupina uživatelů s nejnižším požadovaným oprávněním.
3. U funkcí, které se starají o změnu nebo reset hesla bylo třeba přes vygenerovaného REST Clienta zavolat stejnojmenné funkce na Titanium Services, ve kterých se již volala logika.
4. Na Business logice se tedy poté řešil samotný úkon pro změnu nebo reset hesla. Ke všem potřebným záležitostem jsem použil API od firmy Microsoft, například pro generování tokenů atd.
5. Jakmile vše fungovalo, bylo třeba nasadit pěkný frontend, to čítalo jak práci s css tak s JavaScriptem.
Díky tomuto úkolu jsem si udělal mnohem ucelenější náhled na to, jak v celém Titaniu pracovat, a to zejména na backendu. Úkol jsem zvládl, a i navzdory mým doposud malým zkušenostem s frontendem se mi povedlo vytvořit za použití bootstrapu a Jquery pěkné interaktivní formuláře.
4.6 Otevření Substation schématu na zákaznickém prostředí
Konkrétně nešla otevřít jedna specifická Substation na zákaznickém prostředí. V našich podmínkách tedy nelze replikovat. Jediné údaje k dispozici byly v podobě logu, který bohužel sám o sobě nic moc neprozradil. Konkrétně se z něj dalo vyčíst pouze to, v jaké části bussiness logiky k pádu došlo.
V afektované funkci totiž docházelo k volání spousty metod z Buissiness logiky, protože se jedná o načítání schématu, což obnáší načíst spoustu typů prvků a vrstev. Prvních pár hodin jsem si mapoval a procházel kód, neboť jsem musel čekat, než jsem dostal přístupové údaje, abych se mohl podívat přímo na zákaznické prostředí a do produkční databáze.
Nejdříve bylo třeba identifikovat jaké všechny typy prvků se ve schématu mohou vyskytovat, po identifikování afektovaných záznamů v databázi a kratším pátrání jsem odhalil, že se do schématu nějak dostal busbar s NULL hodnotou u Location. Z parametru Location se získává přesná geometrie objektu.
Musel jsem si ověřit, zda se jedná skutečně o problém. Proto jsem ručně vytvořil podobné podmínky na naší DEV databázi. Po potvrzení již bylo jednoduché opravit kus kódu, ve kterém byl problém a smazat problémový prvek se zachováním původní podoby Substation.
4.7 Schema Template
Se Schema Template, jsem strávil několik dnů, nicméně se nejednalo o jeden souvislý úkol, ale hned o celou sérií úprav, které přicházely v průběhu několika týdnů.
Nejdříve krátký úvod o tom, k čemu se zmíněné schémata používají. Jedná se o šablonu s geometrií používaných prvků sítě, které mají možnost otevření vlastního vnitřního detailu obsahujícího schéma. Obvykle se jedná o Station, External Connection Box popř. o Substation.
Samotné šablony se ukládají do databáze v jedné tabulce bez dalších závislostí, obsahem řádku tabulky je typ prvku, kterému geometrie patří a jeho podoba v XML. Jediné dvě operace, které Small Widget pro kreslení se schématy zvládá, je delete a create operace. Update prakticky chybí.
Původně šlo totiž ukládat šablony se stejným jménem. Šablony jako takové nepodporují update, osobně si myslím, že nebyl původními autory podporován kvůli způsobu, jakým se
14
šablonami zákazníci pracují. Pokud se vytváří nový prvek s vnitřní geometrií, vytvoří se nový, prázdný prvek, do něj se podle vybrané šablony vloží konkrétní geometrie, která se může upravit.
Tento nově vytvořený prvek tedy získá vlastní geometrii.
V případě potřeby změny šablony tak lze učinit pouze následovně. Vytvořit nový prvek, do něj vložit šablonu, tu upravit a poté uložit geometrii jako šablonu, prvek poté může být smazán.
Fyzicky nedojde k propojení šablony s konkrétním schématem, neboť se vnitřní geometrie může prvek od prvku lišit. Schéma tedy slouží jen pro vytvoření většinou základní geometrie.
Můj první úkol byl zařídit, aby již nadále nešlo vytvářet další schémata s již existujícím jménem. Protože to bylo těsně před delivery, nebyl čas na rozsáhlejší změny, proto jsem se po poradě s kolegou rozhodl, že prozatím bude nejlepší předělat create tak, aby našel a nahradil první výskyt schématu se shodným atributem SchemaOwner a stejným názvem a nahradil jej.
SchemaOwner je atribut v databázové tabulce identifikující typ schématu, tedy pro jaký prvek sítě je určen.
Poté jsem musel řešit problém, který vznikal v prezentační vrstvě kvůli nešťastně dělanému dropdown menu, ve kterém se vypisují jednotlivá schémata. Předchozí programátor pouze po úspěšném uložení přidal novou položku přes JS bez jakékoliv kontroly, neb před tím se počítalo s ukládáním schémat se stejným názvem. Díky mým úpravám na business logice se do databáze provedly korektní úpravy, takže na prezentační vrstvu přišla zpráva o korektním provedení funkce jak v případě, že se nové schéma uložilo nově, nebo nahradilo existující. Dropdown menu
nicméně bylo koncipováno tak, že v případě úspěchu přidalo novou položku do seznamu bez kontroly. Takže mi nezbývalo než na úrovni JS připsat kód, který nejdřív kontroloval, zda je vůbec třeba přidávat novou položku. Po úspěšném přidání se tedy volá následující metoda.
schemaTemplateCreated: function(data) { var that = this;
var notification;
if (data.Status == "OK") {
var createdTemplate = json.fromJson(data.Data);
var schemaSelector = $(that.map.domElement).find("#schemaTab");
var selector = "option:contains(" + createdTemplate.TemplateName + ")";
var result = schemaSelector.find(selector);
if (schemaSelector && result.length === 0) {
schemaSelector = $(that.map.domElement).find(".digitizingListFormating select.selectpicker.schemaTemplate");
schemaSelector.append($('<option>', { value: createdTemplate.TemplateId, text: createdTemplate.TemplateName }));
schemaSelector.selectpicker("refresh");
}
// Notify change notification = {
Title: that.langTextsDigitizing.CreateSchemaTemplate, Text: that.langTextsDigitizing.ObjectCreated,
Type: that.appController.NotificationsServer.notificationType.Success }
this.appController.topicPublish(publishSubscribeChannels.map_refresh);
} else {
notification = {
Title: that.langTextsDigitizing.CreateSchemaTemplate, Text: that.langTextsDigitizing.ObjectNotCreated,
Type: that.appController.NotificationsServer.notificationType.Error }
}
that.showNotification(notification);
}
Výpis 3: Metoda pro případné přidání nového schematu
Po nějaké době jsem se ke schématům opět dostal, čekal mě refaktoring kódu a změna chování procesu přepsání existujícího schématu. Nyní bylo ještě třeba v případě existujícího názvu nového schématu uživatele upozornit na případné přepsání starého schématu, nebo mu vůbec nedovolit přepsání v případě, že uživatel používá víc než dvě schémata se stejným názvem jako nově vkládané.
4.8 Coordinate Series
Coordinate Series je Large Widget, který umožňuje importovat do Titania sérii souřadnic ze souboru gps, mer, rap. Samotný souřadnicový systém je v několika formátech:
1. EUREF_FIN 2. Finland_Zone_3
16
3. WGS84
Tyto soubory mohou vzniknout například GPS měřením a Coordinate Series Widget poté slouží k vizualizaci těchto dat, na kterých může například proběhnout další kreslení.
Tento widget není má práce, nicméně jsem asistoval mému kolegovi, který samotný widget dělal. Mému kolegovi jsem pomáhal řešit několik vzniklých problémů. Například se jednalo o problém při uvolňování grafické vrstvy, při kterém docházelo k tomu, že i po zavření byly vidět body z naposled vloženého souboru.
Jako jeden z posledních úkolů u Coordinate Series jsem řešil problém týkající se importování souborů přes prohlížeč Mozilla Firefox, kde oproti Google Chrome vznikaly problémy při parsování.
Konkrétní problém při parsování se týkal parsování header a ještě konkrétněji získání konečného indexu. Nebyl totiž brán v potaz rozdíl podoby ukončujícího řetězce v prohlížečích Chrome a Firefox.Po úpravě tedy.
private const string WebkitEndHeader = "\r\n---WebKitFormBoundaryXXXXXXXXXXXXXXXX--
\r\n";
private const string WebkitEndHeaderForFirefox = "\r\n--- XXXXXXXXXXXXX--\r\n";
...
long endIndex;
if (header.Contains("WebKitFormBoundary")) {
endIndex = inputStream.Length - WebkitEndHeaderForFirefox.Length;
} else {
endIndex = inputStream.Length - WebkitEndHeader.Length;
} ...
Výpis 4: Úprava header při parsování
4.9 Rss News widget
Tento large widget je čistě má práce, od návrhu až po implementaci. V podstatě jsem dostal UserStory, podle které by zákazníci chtěli možnost sledovat aktuální zprávy z prozatím
nespecifikovaných RSS zdrojů. V tomto Widgetu by poté mohly objevovat aktuální zprávy například o katastrofách nebo nehodách, což by přišlo vhod při sledování aktuálního stavu sítě.
Konkrétní RSS zdroje jsou součástí XML, které je uloženo v konfigurační tabulce v databázi.
Na bussines logice dochází k vytvoření objektů z transport model type za použití XML serializace. Tyto objekty jsou velmi jednoduché, každý z nich obsahuje název a cílový URL odkaz.
Tyto objekty jsou v podobě listu předány jako ViewModel. Pomocí C# Razor je jejich obsah vypsán v podobě Json do skrytého prvku na stránce, neboť je třeba zobrazení z daného zdroje provést až na úrovni JS.
@{
...
string temp = JsonConvert.SerializeObject(Model.RssFeeds);
...
} ...
<div id="UrlsContainer" style="display: none;" data-rssfeedobjects="@temp"></div>
...
Výpis 5: Serializace objektů do Json
V JS třídě je poté ze skrytého JSON vytvořen list objektů, tyto objekty jsou poté zobrazeny na stránce.
18 showRss: function() {
var that = this;
var spanNumber = 0;
that.RssFeedObjects.forEach(function (element) {
var qryRSS = 'select * from rss where url=' + '"' + element.Url + '"';
var result = "";
$.getJSON("http://query.yahooapis.com/v1/public/yql", {
q: qryRSS, format: "json"
},
function (data) {
that.widgetContainer.find('[name="' + element.Url + '"]').html("");
for (var i = 0; i < data.query.count; i++) {
result += '<a class="RssTitle" target="_blank" href="' + data.query.results.item[i].link + '">' + data.query.results.item[i].title + '</a>';
result += '<p class="RssTime">' + data.query.results.item[i].pubDate + '</p>';
if (data.query.results.item[i].description.length >= that.MaximumNewsLength) { var fulltext = data.query.results.item[i].description;
var cuttedText = fulltext.slice(0, that.MaximumNewsLength);
var indexOfLastSpace = cuttedText.lastIndexOf(" ");
if (indexOfLastSpace !== -1) {
cuttedText = fulltext.slice(0, indexOfLastSpace);
cuttedText += "...";
}
result += '<p class="RssText">' + cuttedText + '</p>';
} else {
result += '<p class="RssText">' + data.query.results.item[i].description + '</p>';
}
result += '<hr class="RssLine">';
}
that.widgetContainer.find('[name="' + element.Url + '"]').html(result);
that.widgetContainer.find("#" + spanNumber + that.idSufixForCountOfNews).html("(" + data.query.count + ")");
spanNumber++;
});
});
}
Výpis 6: Vypsání jednotlivých zpráv zpráv
Zobrazení probíhá do předem připravených DIV tagů, které jsou generovány pomocí ASP .NET Razor.
@{
foreach (var item in Model.RssFeeds) {
string idForDiv = i + "RssFeed";
string idForSpan = i + "RssNumber";
i++;
<div class="panel panel-default" role="tab">
<div class="panel-heading ObjectEditorGroup">
<a class="tableListItem collapsed" data-toggle="collapse" href="#@idForDiv" aria- expanded="true">@item.Name</a>
<span id="@idForSpan" class="pull-right">(0)</span>
</div>
<div id="@idForDiv" class="panel-body list-group objectEditorFields panel-collapse collapse"
style="padding: 0px !important;" aria-expanded="true">
<div name="@item.Url">
<!-- Placeholder for Rss text -->
</div>
</div>
</div>
} }
Výpis 7: Generování DIV tagů
20
5. Služební cesta do Polska
Ze strany vedení mi byla nabídnuta možnost odcestovat na dva dny do Polska a účastnit se Kickoff soustředění, a to zejména kvůli mému budoucímu působení ve firmě Tieto. S touto nabídkou jsem s nadšením souhlasil. Při této velké příležitosti se na tomto setkání formoval nový CA team.
V první části prezentací a meetingů nám byl poskytnut náhled na Bussiness s energiemi v severských zemích jako takový, a to včetně postoje firmy, firemní strategie ke konkrétním odvětvím v energiích, ať už se jednalo o budoucí postoj a plány či postoj například k existujícím billing systems.
Přesně nám bylo prezentováno, co a jak všichni zákazníci dělají a jaké mají procesy při různých akcích, například zavedení přípojky elektřiny, její vypnutí nebo vyměnění měřiče. Zjistil jsem, že se zákazníci dělí na čistě DSO nebo Retail společnosti, či jejich kombinaci v případě velkých firem.
DSO zákazníci jsou ti zákazníci, jímž patří fyzické elektrické (nebo teplovodní) rozvody, jejich zákazník potom platí za využití této sítě. Retail firmy mají poté na starosti prodej samotné energie.
V dalších, již konkrétnějších prezentacích a schůzkách se probíraly současné nástroje a jejich budoucí úpravy. Velmi zajímavá byla část, ve které nám byl prezentován nástroj TSU 360 pro sjednocení a sběr informací z různých systémů. Na tomto systému bude ještě spoustu práce, nicméně již teď z větší části funguje. Data a informace o jednotlivých zákaznících sbírá a prezentuje v podobě Timeline v aplikaci EMM, což je klíčový, hlavní nástroj obsahující Dashboard, na kterém budu se svým týmem pracovat.
V současnou chvíli máme zhruba 20 zákazníků, pokud nebereme v potaz skupiny, do kterých se někteří zákazníci seskupují, každý z nich má různé aplikace a moduly. Někteří zákazníci, zejména ti menší, používají zastaralé verze aplikací. Nyní se bude pracovat na sjednocení a sladění nasazených verzí, kterých je v tuto chvíli opravdu obrovské množství.
5.1 Hodnocení cesty
Jsem nesmírně rád, že mi byla poskytnuta tato nabídka, která mi otevírá dveře k dalšímu působení ve firmě Tieto, na zajímavém projektu. Díky této cestě jsem pochopil, co skutečně zákazníkům poskytujeme a jakou to pro ně má hodnotu. Také jsem pochopil kontext námi poskytovaných řešení, včetně toho, jak do sebe vše zapadá.
6. Zhodnocení znalostí a dovedností
Praxe jako taková mi dala možnost vyzkoušet si teoretické znalosti v praxi a následně je prohloubit nebo získat úplně nové. Také jsem si vyzkoušel, co to znamená mít skutečnou
zodpovědnost, jak na mě působil pracovní stres a jak jsem se s ním vypořádal. Jako největší přínos vidím fakt, že jsem se dokázal samostatně učit, rozhodovat a že za mnou zůstal viditelný kus práce.
6.1 Znalosti scházející v průběhu odborné praxe
Před začátkem praxe jako software developer jsem nikdy nepracoval s CSS a HTML na vyšší úrovni. Při některých úkolech to ovšem bylo třeba, tyto chybějící znalosti jsem si však velmi rychle doplnil, neboť se jedná o skutečně lehké technologie.
Docela špatně jsem na tom byl také s JS. Před praxí jsem měl velké mezery, JavaScript jsem považoval za podřadný skriptovací jazyk, nicméně jsem si musel velmi rychle doplnit rozsáhlejší znalosti, například práce se třídami v JS Dojo, což umožní mít k dispozici znovupoužitelné objekty. Postupem času jsem JS začal vnímat jako plnohodnotný a opravdu šikovný jazyk, pomocí kterého se z webových aplikací stává otevřené hřiště, jenž umožňuje takřka neomezené možnosti.
JS ani teď nepatří k mým silným stránkám, avšak nyní se z něj pro mě stal jeden z mých nejoblíbenějších jazyků, což mi umožňuje být v něm poměrně efektivní.
Vzhledem k mému naprosto chybějícímu povědomí o geoinformatice pro mě byly všechny informace, pojmy, metody, ale i používané technologie od firmy Esri naprostou novinkou. V tomto oboru jsem se naučil poměrně dost, nicméně tyto technologie jsou poměrně rozsáhlé, a ještě větší kus mi zbývá.
6.2 Znalosti uplatněné v průběhu odborné praxe
Delší dobu jsem se sám věnoval Javě, hlavně ve spojení se systémem Android. Již při jednom ze semestrů na vysoké škole jsem zjistil, že mi na základě těchto zkušeností nedělá vůbec žádný problém začít pracovat v C#. Tato schopnost mi velmi usnadnila veškeré úkoly, které jsem musel dělat na backend části aplikace.
Při práci mi v mnoha situacích pomohla znalost SQL a T-SQL.
Také jsem uplatnil obecné znalosti a praktiky, které se vyučují například v předmětu Softwarové Inženýrství a Vývoj Informačních Systémů.
22
Závěr
V závěru bych rád nejprve zhodnotil mé působení na pozici Automation GUI tester. Na této pozici jsem sice působil velmi krátce, nicméně se mi i za tak krátký čas podařilo zautomatizovat celý Test Suite, který fungoval a úspěšně testoval cílenou funkcionalitu až do doby, než došlo k větším změnám a testy musely být upraveny. Také se mi podařilo identifikovat klíčové problémy a spustit řetězec událostí, který měl vést k jejich napravení, což poté řešil můj nástupce.
Po mém přestupu na development jsem ze začátku tápal, naštěstí mi kolegové hodně pomohli.
Z odvedené práce mám dobrý pocit. Zanechal jsem v aplikaci některé věci, které jdou skutečně vidět a mají pro uživatele reálnou hodnotu. Z popsaných úkolů například správa hesel, kopírování geometrie z EMT, nebo například zpřehlednění schémat. Těchto viditelných věcí je víc, například jsem nepopisoval mou práci na exportu XML Template, která se používá při importování spousty informací do předchůdce Titania, desktopové aplikace PowerGrid.
Velmi výrazně jsem se zdokonalil ve schopnostech programování, a to jak na backend části, kde jsem programoval objektově v C#, tak na frontend, kde jsem využil JS a velmi výrazně jsem pokročil v HTML a CSS. Také jsem vděčný za zkušenost s Esri technologiemi.
Stal jsem se plnohodnotným členem týmu, se kterým se počítalo při vývoji nových prvků aplikace.
Velkou radost mi udělala důvěra, kterou jsem cítil ze strany managementu, a to kvůli služební cestě do Polska a faktu, že jsem se stal členem nově vytvářeného CA týmu.
Literatura
[1] wikipedia.org. Tieto. [Online] 10. 5 2017. https://cs.wikipedia.org/wiki/Tieto.
[2] Tieto Czech s.r.o. Tieto. O nás. [Online] 2. 4 2018. https://www.tieto.cz/tieto-o-nas.
[3] Esri. wikipedia.org. ArcGis. [Online] https://en.wikipedia.org/wiki/ArcGIS.
[4] —. ArcGis - Documentation. Versioning. [Online] http://desktop.arcgis.com/en/arcmap/10.3/manage- data/geodatabases/an-overview-of-versioning.htm.
