• Nebyly nalezeny žádné výsledky

2016AdamSvoboda AbsolvováníindividuálníaodbornépraxeIndividiualProfessionalPractiseintheCompany VŠB–TechnickáuniverzitaOstravaFakultaelektrotechnikyainformatikyKatedrainformatiky

N/A
N/A
Protected

Academic year: 2022

Podíl "2016AdamSvoboda AbsolvováníindividuálníaodbornépraxeIndividiualProfessionalPractiseintheCompany VŠB–TechnickáuniverzitaOstravaFakultaelektrotechnikyainformatikyKatedrainformatiky"

Copied!
30
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í a odborné praxe

Individiual Professional Practise in the

Company

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

Abstrakt

Tato bakalářská práce je věnována odborné praxi ve společnosti NetDirect s.r.o. Popisuje fungo- vání firmy a její technologie, dennodenní zpracování požadavků klientů a celkový chod servisního oddělení. Dále se pak zabývá rozborem úkolů zadaných na individuální praxi.

Klíčová slova: JavaScript, CSS3, ASP.NET, XSLT, e-commerce, e-business, servis e-shopu

Abstract

This bachelor thesis is focused on professional practise in the company NetDirect s.r.o. It describes running of firm and its technologies, daily processing of clients‘ requests and whole operations of service department. Moreover it analyzes tasks, which where assigned during individiual professional practise.

Key Words: JavaScript, CSS3, ASP.NET, XSLT, e-commerce, e-business, e-shop service

(7)

Obsah

Seznam použitých zkratek a symbolů 8

Seznam obrázků 9

1 Popis firmy a její produkty 12

1.1 ShopCentrik . . . 12

1.2 FastCentrik . . . 12

1.3 MediaCentrik . . . 13

2 Pracovní pozice na servisním oddělení 14 2.1 Programátor . . . 14

2.2 Databázista . . . 14

2.3 Kodér . . . 14

3 Technologie ShopCentriku 15 3.1 Administrace v ASP . . . 15

3.2 Jádro v ASP.NET . . . 15

3.3 Modulset . . . 15

3.4 Šablony v XSLT . . . 15

3.5 Databáze . . . 15

4 Tiket 16 4.1 Druhy tiketů . . . 16

4.2 Fáze tiketů . . . 17

5 Pracovní úkoly 18 5.1 Automatické přičítání kusů . . . 18

5.2 Kontrola DIČ . . . 20

5.3 Napojení na Ecomail . . . 22

5.4 Omezení dopravy pro křehké zboží . . . 24

5.5 Redesign . . . 25

6 Závěr 29

Literatura 30

(8)

Seznam použitých zkratek a symbolů

AJAX – Asynchronous JavaScript and XML

API – Application Programming Interface

ASP – Active Server Pages

ASP.NET – Active Server Pages, .NET znamená uzpůsobené pro network

CSS – Cascading Stylesheet

CSS3 – Latest standard for CSS

HTML – HyperText Markup Language

IE – Internet Explorer

MSSQL – Microsoft Structured Query Language

PDF – Portable Document Format

SEO – Search engine optimization

SMS – Short Message Service

SQL – Structured Query Language

T-SQL – Transact – Structured Query Language

XML – Extensible Markup Language

XSLT – Extensible Stylesheet Language Transformation

(9)

Seznam obrázků

1 Tabulka doprav . . . 24

(10)

Seznam výpisů zdrojového kódu

1 Volání funkce automatAdd . . . 18

2 Funkce automatAdd . . . 19

3 Funkce addCount . . . 19

4 Kontrola DIČ v JavaScriptu . . . 20

5 Kontrola DIČ na straně serveru . . . 21

6 Část šablony informačního emailu . . . 22

7 Volání funkcí Ecomailu . . . 23

8 Funkce pro vložení uživatele do Ecomailu . . . 23

9 Křehké zboží v košíku . . . 25

10 Omezení doprav dle křehkostí . . . 25

(11)

Úvod

Tato bakalářská práce se zabývá popisem firmy NetDirect s.r.o. a systémem, jakým probíhá zpracování tiketů. Pod pojmem tiket si můžeme představit elektronický požadavek klienta o úpravu. NetDirect s.r.o. je firma, která se zaměřuje především na tvorbu e-shopů. Nabízí jak specializované e-shopy, které jsou tvořeny klientovi přímo na míru, tak univerzální neboli kra- bicové řešení a v neposlední řadě nabízí také tvorbu webové prezentace. Tato bakalářská práce se bude dále zabývat popisem použitých technologií a pracovních úkolů, které byly v průběhu praxe zadány.

Firma NetDirect s.r.o. přijímá uchazeče v rámci bakalářské praxe na pozici programátora v servisním oddělení, které se stará o údržbu e-shopů a zpracování požadavků klientů. Část vybraných úkolů se týká redesignů e-shopů. Pod pojmem redesign si lze představit velkou úpravu, která zahrnuje vytvoření nových funkcí a v neposlední řadě dodá redesign e-shopu nový vzhled.

Při této úpravě se uplatní nejen programátor, ale také databázista a kodér. Mezi další povinnosti, které sebou práce přináší, patří také komunikace se zákazníkem, která je stejně důležitá jako samotné programování.

Důvodů proč si zvolit odbornou praxi je mnoho, jednak se z ní může postupem času stát i zaměstnání ale také zde můžeme nabrat potřebné zkušenosti do života a poznat skutečný programátorský svět, který se velmi liší od toho školního.

(12)

1 Popis firmy a její produkty

Společnost NetDirect s.r.o. je na trhu již od roku 2002 a dodává e-business aplikace jak v České, tak ve Slovenské republice. Firma nyní čítá 90 zaměstnanců a stále se rozrůstá o nové odborníky, ale i mladé perspektivní zaměstnance. Společnost nabízí variaci e-shopových řešení, různé webové prezentace, ale i jednodušší webové aplikace a napojení na různorodá API nebo účetní systémy.

Celek se většinou skládá z více částí a ani zde tomu není výjimkou. Kromě oddělení podpory a marketingu, jsou zde programovací sekce a ty jsou rozděleny do tří hlavních větví. Vývojové oddělení vytváří nové jádra pro úplně nové e-shopové řešení. Za pomocí nejnovějších technologií (MVC 5, Razor) vznikají novější a lepší verze systémů, které jsou pak výkonnější a pro zákazníka snadněji ovladatelné. Výrobní část má za úkol pro stávající a již běžící systémy vytvářet nové funkčnosti, hlavně napojení na nové API a různé jiné externí systémy. Servisní úsek se stará o aktivní e-shopy, které potřebují drobné i větší úpravy, opravy chyb a celkovou údržbu chodu. Ne- malou část úprav na servisním oddělení tvoří také redesigny, kdy stránky internetového obchodu dostanou jak nový kabát, tak nové funkce.

1.1 ShopCentrik

Prvním z produktů, které NetDirect s.r.o. nabízí, je e-shop na míru zvaný ShopCentrik. Zde se vytváří zcela personalizovaný internetový obchod. Prvním krokem je analýza s klientem, kde se upřesní důležité body a na základě požadavků zákazníka a dalších prvcích (jako například cílová skupina zákazníků nebo sortiment zboží) vznikne unikátní projekt. Je to dlouhotrvající proces, který je doprovázen aktivní komunikací se zákazníkem a dochází také k průběžnému testování až do chvíle, kdy je projekt doladěn a připraven na ostré spuštění.

Mezi hlavní pilíře patří specializace B2C (koncový zákazník) a B2B (obchodní partner), kdy se některé e-shopy zaměřují na přeprodej zboží B2B partnerům a personalizovanost systému ShopCentrik umožňuje tuto možnost v nejvyšší kvalitě a tím zaručí spokojenost těchto partnerů.

Mezi další důležité faktory patří prodejní kanály, kde ShopCentrik umožní zákazníkům napojení nejen na nejběžnější kanály Heureka.cz a Zboží.cz, ale také na jakékoliv kanály požadované klientem. Za zmínku stojí i modulárnost e-shopu, design na míru a vysokou výkonost bez omezení produktů a nespočet napojení na ERP systémy. Nejpodstatnější je však individuální servis, který po nasazení do ostrého provozu je k dispozici téměř nepřetržitě a programátoři ze servisního oddělení jsou připraveni okamžitě odstranit jakoukoliv chybu.

1.2 FastCentrik

Druhým, neméně důležitým produktem, je řešení FastCentrik. Jedná se o univerzální krabicové řešení e-shopu, které nabízí hlavní možnosti z různých oblastí marketingových nástrojů. Řešení FastCentrik má dvě verze, basic a plus. Možnost plus nabízí více napojení, více produktů a lepší personalizaci.

(13)

Tak jako systém ShopCentrik nabízí od základu mnoho funkcí, tak i FastCentrik má mnoho nástrojů, které klientovi napomáhají k úspěšné realizaci fungujícího internetového obchodu.

Řadí se zde hlavně e-marketing, který zahrnuje porovnávače zboží, SEO ladění, personalizované e-maily, komplexní statistiky a napojení na sociální sítě. Důležitá je zde i základní personalizace podle polohy, pohlaví a věku zákazníka. V nabídce je hned několik šablon, které jsou navíc plně responzivní. To vše je v zákulisí ovládané jednoduchou a přehlednou administrací.

1.3 MediaCentrik

Nejmladší produkt firmy se zaměřuje na tvorbu webových stránek. I zde je možnost mít webové stránky na míru, kde se klade důraz na nejlepší řešení pomocí podrobné analýzy, ve které se zjišťují potřeby klienta a jeho cílové skupiny. Výsledkem jsou webové stránky podle potřeb zákazníka. Další možností jsou takzvané mikrostránky, které jsou většinou úzce zaměřeny na konkrétní produkt nebo službu. Využívají se hlavně jako doplněk stránek větších, jako například e-shopu. Díky vyladěnému SEO se pak tyto mikrostránky můžou objevit na prvních místech ve vyhledávačích a zákazníkovi tak zajistí případnou návštěvu přidružených stránek.

(14)

2 Pracovní pozice na servisním oddělení

2.1 Programátor

Nejširší okruh zaměstnanců na servisním oddělení tvoří programátoři. Tento post je velice univer- zální, jelikož povětšinu času pracuje také jako databázista nebo kodér. Ovšem pokud se jedná o specializovanější záležitosti, přenechá programátor práci příslušné pozici. Náplní práce pak tvoří hlavně úpravy frontendu (část webu, která je přístupná běžnému návštěvníkovi), ale také admi- nistrace, procedur nebo feedy (pravidelný výstup z e-shopu, například pro srovnávače). Úpravy frontendu zahrnují primárně změny v XSLT šablonách, modulsetech, JavaScriptech, jQuery a v neposlední řadě CSS stylů. Pokud je potřeba upravit data, které jsou důležité pro zobrazení na frontendu, upravuje programátor tabulky (nový sloupec, změny datových typů) nebo výstupy z procedur (nové procedury, jiné větve stávajících procedur, případně rozšíření koncového selectu).

Základní vývojové prostředí pro programátora je Microsoft Visual Studio. Používá se pro úpravu celého projektu, jelikož podporuje hlavně jádro psané v C#, ale taky veškeré ostatní používané technologie. Další nástroje, které programátor využije, je Microsoft SQL Server Ma- nagement Studio pro správu procedur a databází, dále pak SQL Server Profiler pro odchycení volaných procedur na webu nebo pokud má větší úpravy v grafice, tak i Adobe Photoshop CS5.

2.2 Databázista

Na této pracovní pozici se zaměstnanec hlavně stará o přenosy dat. Jelikož ShopCentrik podpo- ruje napojení na jakýkoliv ERP systém, je potřeba mít v týmu zkušeného databázistu, který je schopen ovládat přenosy dat z e-shopu v různých formách. Zároveň musí tyto systémy znát, aby dokázal říct, co je možno přenášet a jak. V náplni má také například ladění procedur, kde se snaží zrychlit průběh nebo najde místo kde je problém a předá jej pak k řešení programátorovi.

Pracovním nástrojem databázisty je Microsoft SQL Server Management Studio.

2.3 Kodér

Náplní této pracovní pozice je starost o grafické úpravy. Pokud se jedná o drobnou úpravu CSS stylů, postará se o to programátor, pokud už se však jedná o složitější nebo komplexnější úpravu, přichází ke slovu kodér. Má na starosti konečný vzhled úpravy. Větší část jeho práce pak tvoří úpravy grafiky při redesignu nebo řezání grafiky pro responzivní design.

Pracovním nástrojem kodéra je Adobe Photoshop CS5.

(15)

3 Technologie ShopCentriku

Při práci na e-shopech v systému ShopCentrik se používá velká variace programovacích jazyků.

Základní funkční princip celého běhu začíná zavoláním ASPX formuláře. Ten pak dle větve zavolá určitý modulset. V modulsetu jsou obsaženy jednotlivé moduly, které si podle tabulky modulů v databázi vygenerují pomocí dotazů na databázi potřebné XML a to se načte do příslušné šablony XSLT. Ta pak vytvoří konečný HTML kód, který se zobrazí na webu.

3.1 Administrace v ASP

Nejstarší část celého řešení je administrace, která je psaná ve "starém"ASP, tedy jazyce VBScript.

V tomto jazyce se programuje jen minimálně, pokud je například potřeba v administraci dodat checkboxy nebo jiné vstupní ovládací prvky. Získávání a posílání dat obstarává právě ASP, ale interakce s inputy už je řešena v JavaScriptu.

3.2 Jádro v ASP.NET

Pokud je potřeba obstarat funkčnost na straně serveru, pracuje vše v ASP.NET, programovací jazyk je C#. Jádro se stará o volání procedur, odesílání e-mailů, SMS nebo taky o tisknutí PDF.

3.3 Modulset

Modulset obsahuje hned několik modulů nebo jiných modulsetů. Podle zavolaného modulu se vybere určitá šablona a vyberou se pomocí procedur příslušné XML data a ty se vloží do šablony.

Typický příklad modulsetu je například celý sloupec, který se skládá z modulu menu, modulu pro odeslání dotazu nebo třeba z modulů reklamního banneru. Tento modulset se pak snadno vloží na každou stranu, kde je ho potřeba.

3.4 Šablony v XSLT

Většina úprav je prováděná právě v šablonách, které generují konečný HTML kód. Šablona pracuje s XML výstupy z procedur a pomocí různých větví podmínek nebo cyklů, generuje jednotlivé stránky.

3.5 Databáze

Databáze běží na systému od Microsoftu, tedy MSSQL. Moduly, do kterých je rozdělen celý web, jsou všechny uloženy do jedné nejdůležitější tabulky. Zde obsahují informaci, jaká šablona se má zobrazit a jaké procedury se mají zavolat.

(16)

4 Tiket

Velká část komunikace mezi zákazníkem a pracovníkem servisního oddělení probíhá přes tikety.

Jedná se o elektronický požadavek, ve kterém je popsaný problém nebo žádost o úpravu. Udržuje informace o rozpracovanosti, o účastnících a komunikaci mezi jednotlivými účastníky. Tento způsob napomáhá k rychlému řešení prací, přičemž je vše přehledně na jednom místě. Každý pracovník má pak přehled tiketů, které zapracovává, stejně tak jako má zákazník přehled svých tiketů, které řeší se servisním oddělením.

4.1 Druhy tiketů

Tiket se dělí na placené a neplacené. Placené jsou požadavky na úpravu, které nebyly dříve naceněny a jedná se o změnu funkčnosti nebo grafiky. Neplacené bývají opravy, které vyplynou z nefunkčnosti předchozích úprav nebo z chyb v původním předání projektu. Ten je totiž 2 roky v záruce, ale po uplynutí i tyto opravy jsou placené. Druhé dělení tiketu je podle priority.

4.1.1 Kritický

Takto založený tiket je nutno okamžitě řešit a servisní oddělení má povinnost do jednoho dne reagovat, nicméně obvyklá reakce bývá do několika minut, kdy se kritický tiket začne řešit. Tiket bývá kritický hlavně z důvodů nefunkčnosti celého e-shopu, ale také například kvůli nefunkčnímu objednávkovému procesu nebo feedu na prodejní kanály. Kvůli těmto tiketům bývá pravidelně na servisním oddělení přidělována takzvaná "servisní hlídka", kdy jeden programátor a jeden databázista má i přes víkend povinnost reagovat a řešit kritické tikety.

4.1.2 Vážný

Vážný tiket má dobu odpovědi nastavenou na 3 dny. Většinou se jedná o závažné problémy na e-shopu, které ale nebrání kompletní funkčnosti. Vážné tikety jsou řešeny přednostně, takže se odkládají ostatní méně důležité opravy nebo úpravy. Mezi typické příklady patří zastavení přenosu do ERP systému nebo chyby v exportu na externí API. Vážné tikety většinou není potřeba řešit o víkendu nebo jindy mimo pracovní dobu.

4.1.3 Běžný

Běžná priorita se používá pro opravy, které nebrání funkčnosti (například drobnosti v adminis- traci), ale taky pro konzultace či jiné dotazy. Nejvíc se však používají pro zadání placené úpravy nebo analýzy. Reakce na běžný tiket musí být do jednoho týdne.

(17)

4.2 Fáze tiketů

Cesta tiketu začíná založením, kdy v drtivém procentu zakládá tikety zákazník, avšak i pracovník servisního oddělení má možnost založit tiket (například po telefonickém rozhovoru).

4.2.1 Přidělen

Založený tiket má první stav přidělen. Každý projekt má přidělen jednoho vedoucího, progra- mátora a databázistu. Po založení jsou tito pracovníci informování systémem a tím přijde tiket do fronty řešení pro daného zaměstnance.

4.2.2 K nacenění

Tiket s placenou úpravou, který potřebuje vyčíslit cenu (ať už konečnou, nebo jen za analýzu), přejde do stavu „K nacenění“. Takto označený tiket čeká na pracovníka, aby sdělil zákazníkovi, kolik ho daný tiket bude stát. Nacenění musí být odsouhlaseno zákazníkem, aby mohla být úprava zapracována.

4.2.3 V řešení programátor, databázista nebo klient

Po odsouhlasení pracnosti na placeném tiketu nebo u neplaceného tiketu přichází na řadu práce na tiketu. Pracovník se snaží tiket zapracovat v co nejkratším čase a po prvotním otestování předá zakázku klientovi. Tímto tiket přejde do stavu „V řešení klient“ a zákazník si musí úpravu sám otestovat. Pokud je spokojený, dá souhlas k uzavření, pokud ne, předá výtky pracovníkovi.

Takto se může stav přehazovat několikrát, dokud se nedojde ke spokojenosti zákazníka.

4.2.4 Uzavřen

Pokud je zákazník spokojený a dá souhlas k uzavření tiketu, je tiket následně uzavřen pra- covníkem servisního oddělení. Po uzavření má možnost pracovník u placeného tiketu fakturovat dohodnutou částku. Jestliže nastanou problémy už s uzavřenou záležitostí, má zákazník možnost založit reklamaci tiketu, ve kterém se dořeší případné nefunkčnosti.

(18)

5 Pracovní úkoly

Během praxe se programátor setká s velkou spoustou úkolů. Jedná se jak o úkoly jednoduché, tak složité a komplexní. Některé práce se týkají pouze vložení části kódu do zdrojového kódu webu, které klient předem dostal od externího systému. Setká se s různými opravami, kdy se může jednat o chybu klienta nebo o nedotaženost předchozí úpravy. Velkou část pak tvoří úpravy pla- cené, kdy na základě požadavku zákazníka programátor zapracuje požadovanou změnu. V této bakalářské práci budou ukázány ty, které jsou ucelené, přehledné a zároveň znázorní co nejvíce z práce na této pozici.

5.1 Automatické přičítání kusů

B2B e-shopy se zaměřují na velkoobchodní partnery, kteří nakupují ve větším množství za zvý- hodněné ceny. Tato úprava spočívá v automatickém přičítání kusů zboží při držení tlačítka přičíst, nebo odčítání při držení tlačítka odečíst (Tlačítka bývají na webu znázorněna znaky + a -).

5.1.1 Nacenění

Složitost této úpravy jsem pro klienta odhadl na 1 hodinu práce, nicméně reálná pracnost byla o něco vyšší. Jednalo se totiž o iniciativu ze strany NetDirectu a účelem bylo vytvořit mimo jiné univerzální kód, který by byl funkční pro více řešení. Skutečný strávený čas se vyšplhal na dvě a půl hodiny.

5.1.2 Vypracování

Nejdůležitějším vodítkem při vypracování tohoto úkolu byla univerzálnost. Aby byla úprava co nejsnadněji přenositelná, vytvořil jsem pro skript, který bude ovládat přičítání, zcela nový soubor. Díky tomu lze snadno přenést funkčnost na jiné projekty. Úprava bude prezentována na automatickém přičítání kusů.

Prvním úkolem bylo vytvořit akci, která při držení tlačítka ovládající počet kusů, bude volat funkci, která zajistí přičítání nebo odčítání. Pro pozdější jednoduchost znovu-implementace na jiném řešení jsem navázal volání funkce přímo na daný element. Volání bylo potřeba při stisku a držení tlačítka. Úprava lze vidět ve Výpisu 1.

<div class="plmi-bt">

<span id="addBtn_{@pkTblCommodity}"onmousedown="automatAdd(’count_{$row}’)">

</span>

<strong id="removeBtn_{@pkTblCommodity}"onmousedown="automatRemove(’count_{$row}’)">

<xsl:call−templatename="nbsp"></xsl:call−template>

</strong>

</div>

Výpis 1: Volání funkce automatAdd

(19)

Další přišla na řadu implementace funkce automatAdd, která zajistí spuštění automatického přičítání. Na výpisu 2 je k vidění její celé znění. Nastavíme si základní interval přičítání, resetu- jeme si celkový čas (potřebný kvůli zlomu pro změny rychlosti), navážeme vypnutí přičítání při přerušení držení tlačítka na myši a nastavíme odezvu, po které se spustí interval přičítání. Jako parametr funkce je id elementu, do kterého se budou vypisovat hodnoty.

functionautomatAdd(buyInput) {

time = 300;

timeAll = 0;

$(document).bind(’mouseup’,function() {

clearTimeout(timeoutId);

clearInterval ( intervalId ) ;

$(document).unbind(’mouseup’);

})

timeoutId = setTimeout(function() {

intervalId = setInterval (function() { addCount(buyInput, time, timeAll) }, time);

}, timeoutTime);

}

Výpis 2: Funkce automatAdd

Samotné přičítání obstarává funkce addCount, která je volaná periodicky. Na výpisu 3 je k vidění její částečné znění. Jako první nastavíme celkový čas přičtením periody volání. Dále nastavíme novou hodnotu do inputu pomocí id, které jsme si předali z předchozí funkce. Poslední část úpravy řeší změnu rychlosti přičítání dle celkového času držení tlačítka myši. Pokud je celkový čas v určitém rozmezí, změníme interval na rychlejší a spustíme nový interval. Pokud už funkce má rychlost zvolenou v tomto časovém intervalu, funkce končí. Takto je možné ovládat různé rychlosti s velkou variabilitou časových rozmezí. Rozsah úpravy byl prakticky v jednom soubor a vystačil na 150 řádků.

functionaddCount(buyInput, time, timeAlles) {

timeAll = timeAlles + time;

$(’#’+ buyInput).val(function(i, oldval) {

return++oldval;

}) ;

(20)

return;

time = 200;

clearInterval ( intervalId ) ; }

Výpis 3: Funkce addCount

5.2 Kontrola DIČ

Od jisté doby, kdy v platnost vešly nové zákony, začaly některé ERP systémy kontrolovat správ- nost DIČ. Navíc, ve stejnou chvíli začal prohlížeč Chrome doplňovat automaticky některá pole v registraci nebo objednávce, avšak ne vždy měly tyto doplnění smysl. Chrome začal dosazovat do pole pro vyplnění DIČ hodnoty texty jako "vyberte stát", "moravskoslezský kraj" a jiné. To začalo při kontrole v daném ERP systému dělat problémy a zákazníkům přestaly fungovat pře- nosy dat. Proto vznikl požadavek na kontrolu DIČ, ve kterém se mimo jiné vyřešilo i posílání neplatných řetězců.

5.2.1 Nacenění

Nacenění se rozdělilo na dvě části. První část zahrnovalo zapracování podmínky na kontrolu správnosti DIČ jak na straně klientské, tak na straně serveru. Pracnost jsem vyčíslil na 3 hodiny.

Druhá část obsahovala úpravu, kde se vložila do informačního emailu hláška o změně DIČ na IČ DPH. Tuto část jsem nacenil na hodinu a půl.

5.2.2 Vypracování

Klient vynaložil dostatek času na analýzu a podal velmi podrobný popis, jak si přeje úpravu zapracovat. Hlavní specialitou bylo ošetření slovenského DIČ na formát IČ DPH, které se zto- tožňuje s evropskými standardy a ERP systém je povolí importovat. Slovenské DIČ se skládá z 10 čísel a pozbývá prefix SK, který je potřebný pro správné přenosy. Zákazník dále přiložil pří- klad regulárního výrazu, který měl kontrolovat téměř všechny evropské DIČ. Výraz potřeboval mírné úpravy, jelikož se jednalo o univerzální řetězec a potřeboval převést do jazyka JavaScriptu.

Zpracování se rozdělilo na tři hlavní části.

if (oF.sDic && oF.sDic.value !=’’) {

if (! isUserForm || $(’#regCompanyShow’).is(’:checked’)) {

varmatchString = /^((AT)U[0−9]{8}|(BE)0[0−9]{9}|(BG)[0−9]{9,10}|(CY)[0−9]{8}L|(CZ)[0−9]{8,10}|(DE) [0−9]{9}|(DK)[0−9]{8}|(EE)[0−9]{9}|(EL|GR)[0−9]{9}|(ES)[0−9A−Z][0−9]{7}[0−9A−Z]|(FI)[0−9]{8}|(

FR)[0−9A−Z]{2}[0−9]{9}|(GB)([0−9]{9}([0−9]{3})|[A−Z]{2}[0−9]{3})|(HU)[0−9]{8}|(IE)[0−9]S[0−9]{5}

L|(IT)[0−9]{11}|(LT)([0−9]{9}|[0−9]{12})|(LU)[0−9]{8}|(LV)[0−9]{11}|(MT)[0−9]{8}|(NL)[0−9]{9}B [0−9]{2}|(PL)[0−9]{10}|(PT)[0−9]{9}|(RO)[0−9]{2,10}|(SE)[0−9]{12}|(SI)[0−9]{8}|(SK)[0−9]{10})$/;

(21)

if (!( matchString.test(oF.sDic.value))) {

if ($.isNumeric(oF.sDic.value) && oF.sDic.value.length == 10 && oF.sCountry.value == 198) {

alert (’Vase DIC bude pro potrebu transportu do IS upraveno na format IC DPH a nasledne vraceno do puvodni hodnoty. Dekujeme za pochopeni.’);

$(’#changedDic’).val(oF.sDic.value);

oF.sDic.value =’SK’+ oF.sDic.value;

} else {

alert (’Chybne vyplnene DIC’);

return false }

} } }

return true;

Výpis 4: Kontrola DIČ v JavaScriptu

Na výpisu číslo 4 je ukázána podmínka v JavaScriptu, která byla vložena do místa, kde se provádí kontrola dat ve formuláři pro registraci a objednávku. Tento konkrétní případ je kontrola u registrace zákazníka, podmínka u objednávky se liší pouze u části, kde se řeší formulář, jelikož v objednávkovém procesu je jen jeden, kdežto v registraci jsou dva. Jeden je pro B2C a druhý pro B2B. Prvně si tedy zjistíme, zda je DIČ vyplněno. Pokud ano, provedeme kontrolu pomocí regulárního výrazu. Pokud nesedí formát, ještě se může jednat o zmíněné slovenské DIČ, které se při splnění podmínek délky a státu přemění na odpovídající formát s prefixem SK. Zároveň si zapíšeme staré DIČ, které později vepíšeme do emailu a zároveň bude i identifikátor této celé změny. Na výpisu číslo 5 pak nalezneme kód, který ošetří DIČ na straně serveru.

if(functions.RF("sDic","") .Trim() !="") {

string sDic=functions.RF("sDic","") .Trim();

if (!(Regex.IsMatch(sDic.Substring(0, 2),@"^[A−Z]+$") &&sDic.Length>= 7 &&sDic.Length<= 14

&&Regex.IsMatch(sDic.Substring(3,sDic.Length1),@"^\d+$"))) {

ret =functions.AddXMLattribute(ret,"sDic","wrong");

} }

(22)

6 vidíme novou větev, která pokud je vyplněno staré DIČ (tím pádem došlo ke změně na nové DIČ) připíše hlášku o této změně do emailu. V této úpravě vzniklo nových asi 100 řádků, které pak byly téměř duplicitní i pro objednávku.

<xsl:whentest="$postData/@changedDic &gt; 0">

<xsl:value−of select ="$txt.User.RegisterEmail.DIC"/>:<xsl:value−ofselect="/shop/page/postData/@sDic"

/>

<strong style="color:#B43832;">

&#160; &#160; (<xsl:value−ofselect="$txt.User.RegisterEmail.Puvodni"/> <xsl:value−ofselect="$

postData/@changedDic"/>)

</strong>

<xsl:call−templatename="RadekLF"/>

<xsl:text>Z duvodu zajisteni uspesneho prenosu dat do informacniho systemu bylo vase DIC</xsl:text>

<xsl:value−of select ="$postData/@changedDic"/>

<xsl:text>upraveno do tvaru IC DPH</xsl:text>

<xsl:value−of select ="$postData/@sDic"/>

<xsl:text>.Po transportu bude zmeneno zpet.Dekujeme za pochopeni.</xsl:text>

<xsl:call−templatename="RadekLF"/>

</xsl:when>

Výpis 6: Část šablony informačního emailu

5.3 Napojení na Ecomail

Rozesílání newsletterů (informace a novinky v e-shopu) patří ke stěžejní marketingové strategie.

Pokud se dostane správný e-mail do správných rukou, může to mít za výsledek další nákup zákazníka, který by se jinak o produktu buďto nedozvěděl nebo neprojevil aktivní zájem. Avšak nejsložitější je určit jaký e-mail bude úspěšný. K tomu jsou nápomocny hned několikero externích API.

Ecomail je jedno z těchto prostředí a slouží jako nástroj pro vytváření, rozesílání, měření a následnou hlubokou analýzu e-mailových kampaní a marketingu. Zahrnuje dále sofistikovanou automatizaci, jednoduché vytváření vzhledově přívětivých e-mailů, statistiky kampaní, gende- rovou analýzu a skloňování [1].

Zákazník požadoval napojení na toto API při registraci a v objednávkovém procesu, kdy se pošlou údaje o zákazníkovi. V druhé fázi implementace vznikl požadavek na sledování objednávky vázané na uživatele, kde se zašlou údaje o všech zakoupených položkách.

5.3.1 Nacenění

První fázi jsem nacenil na 8 hodin programátorských prací a zahrnovala vkládání uživatelských informací do Ecomailu jak z registrace, tak z objednávkového procesu. Druhou část jsem nacenil na 5 hodin a týkala se zasílání obsahu objednávky.

(23)

5.3.2 Vypracování

Prostředí má svou dokumentaci, ve které se dá dohledat způsoby, jak dostat potřebné informace do Ecomailu. Nejprve byla potřeba zapracovat přidání a odebrání uživatele v registraci a v objednávce. Volání funkce pro vložení nebo vymazání uživatele se tedy musela rozdělit podle zaškrtnutého políčka "odebírat novinky"ve formuláři. Na výpise 7 je zobrazena podmínka, která tuto funkčnost obstarává, pokud nejsou při odesílání objednávky jiné problémy. Do volané funkce se pošlou parametry potřebné a vyčtené z formuláře.

if (errorMessage=="") {

if (int.Parse(functions.RF("cpbNews","")) == 1) {

addUserEcomail(functions.RF("sFirstName","").Trim(),functions.RF("sLastName","").Trim(),functions.RF("

sEmail","").Trim(),functions.RF("sStreet", "") .Trim(),functions.RF("sCity","") .Trim(), functions.RF(

"sZipCode","").Trim(),functions.RF("sMobil","").Trim());

} else {

delUserEcomail(functions.RF("sEmail","").Trim());

}

Výpis 7: Volání funkcí Ecomailu

Z dokumentace vyplynulo, že je nutné ze strany serveru zaslat post požadavek s určitými daty a unikátním API klíčem [2]. Jelikož e-shop běží na starší verzi .NET frameworku než referenční kód v dokumentaci, bylo nutno vytvořit podobnou funkčnost ve starším prostředí. Nejprve se tvoří požadavek na určitou stránku Ecomailu (ta se mění podle toho, co je potřeba udělat za akci). Pak se vytvoří potřebná data a ty se převedou na datový type "byte". Pak už je jen potřeba vytvořit požadavku potřebné parametry (Metoda, hlavička obsahující API klíč a další) a pomocí streamu vše poslat. Plné znění této funkce je ukázáno ve výpisu 8. Celková délka úpravy se při všech funkcích, které obsluhují API, vyšplhala na 250 řádků.

public voidaddUserEcomail(stringfName,stringlName,stringemail,string street, string city, string zip, string phone)

{

HttpWebRequest request= (HttpWebRequest)WebRequest.Create("http://api2.ecomailapp.cz/lists/12/

subscribe");

string postData="{ \"subscriber_data\": { \"email\": \"" +email+"\", \"name\": \""+fName+"

\", \"surname\": \""+lName+"\", \"street\": \"" +street +"\", \" city \": \"" +city +"\", \"zip

(24)

request.Method="POST";

request.Headers.Add("key","55a4dfd1d8b5855a4dfd1d8c00");

request.ContentType="application/json";

request.ContentLength=data.Length;

using (System.IO.Stream stream=request.GetRequestStream()) {

stream.Write(data, 0, data.Length);

}

}

Výpis 8: Funkce pro vložení uživatele do Ecomailu

5.4 Omezení dopravy pro křehké zboží

Zákazník si zažádal o úpravu, která měla omezit možnost výběru doprav. Jednalo se o ty dopravy, které nebyly ověřeny jako schopné převážet křehké zboží. Tudíž vznikl požadavek, že pokud se v košíku nalézá alespoň jedno zboží, které bude označeno jako křehké, nebude mít uživatel možnost si tuto dopravu vybrat v druhém kroku objednávkového procesu.

5.4.1 Nacenění

Úpravu jsem nacenil na 4 hodiny programátorských prací a 2 hodiny práce pro databázistu.

V rámci této časové pracnosti mělo vzniknout zaškrtávací okno v administraci dopravy, které určovalo schopnost převážet křehké zboží, dále pak schování těchto doprav, pokud bylo v košíku alespoň jedno křehké zboží. Atribut určující křehkost zboží byl přenášen z klientova IS a vpisoval se do tabulky zboží.

5.4.2 Vypracování

Obrázek 1: Tabulka doprav

Jako první bylo nutno vložit do administrace checkbox, který určoval, zda je daná doprava způsobilá k převozu křehkého zboží. Nově do tabulky s dopravami byl zaveden sloupec bFragi- leRestriciton datového typu bit (viz obrázek 1), který při nastavení na jedničku určoval ne- zobrazování dopravy, pokud by mělo být převezeno křehké zboží. Vkládání různých inputů do

(25)

administrace se stává časem rutinní. Jedná se o úpravu ASP souboru, který se stará o servero- vou část a zajišťuje načítání a ukládání dat do databáze. Druhou část tvoří úpravy JavaScriptu, který ovládá checkbox a jeho stavy podle načtených dat. Pracnost takových úprav bývá vždy kolem 1,5 hodiny.

Druhým krokem této úpravy bylo schovat dopravy u výběru v objednávkovém procesu. O načtení dat se stará procedura "prDeliveryTypeGetSelect". Abychom mohli vyloučit dopravu, musíme nejprve zjistit, zda je v košíku křehké zboží. Na výpisu 9 vidíme způsob, jakým toto určíme. Jednoduše navážeme zboží v košíku na tabulku zboží, ve kterém máme informace o křehkosti. Pokud je počet křehkého zboží v košíku větší než nula, označíme jej jako košík s křehkým zbožím.

SELECT@bBasketWithFragile= CASE

WHENISNULL(count(c.bFragileCommodity),0) > 0THEN1 ELSE0

END FROM

tblOrderTemporaryStorage ots with(nolock)

INNER JOINtblCommodity c with(nolock)ONc.pkTblCommodity=ots.fkTblCommodity

WHERE

sBasketID=@sBasketIDAND c.bFragileCommodity= 1

Výpis 9: Křehké zboží v košíku

Poslední věc, kterou jsem musel dodělat, je omezení výběru ve výsledném selectu. Pokud je košík označen jako křehký, nesmí být doprava zakázána pro takový druh zboží (nesmí být příznak bFragileRestriciton nastaven na 1). Toto vidíme na výpisu 10, který je vyňat z klauzule where výsledného selectu. Výsledný rozsah kódu nebyl nijak markatní, jednalo se o dvě až tři desítky řádků, nicméně bylo potřeba vše řádně připravit a zapracovat do různých oblastí.

) AND (

−−Vyber dopravy bez omezeni na krehke zbozi

@bBasketWithFragile= 1ANDISNULL(db.bFragileRestriction,0) = 0OR

@bBasketWithFragile= 0 ) AND

Výpis 10: Omezení doprav dle křehkostí

5.5 Redesign

(26)

se stará jeden programátor a kodér. V rámci redesignu většinou u nových a velkých e-shopů dochází také přizpůsobení vzhledu pro menší rozlišení, tedy pro mobily a tablety. Vzniká tedy plně responzivní web, který je pak snadno ovladatelný ze všech druhů zařízení.

Rozmezí takových úprav bylo pro tento konkrétní případ naceněno na přibližnou dobu 60 pracovních dní programátora a kodéra. Jelikož se od začátku nepodařilo odhadnout množství drobností, které se musely změnit, opravit nebo upravit, úpravy trvaly ještě déle. Navíc, zákazník v průběhu přidal několik nových funkčností, které také protáhly implementační dobu.

Náplní programátora u redesignu je nejen zapracování nových funkčností, ale hlavně úpravy XSLT šablon, základních stylů a celkového rozložení jednotlivých stránek. Důležitá je spolupráce s kodérem, který potřebuje pro stylování stránky určité struktury. Hlavně pokud bude web re- sponzivní, je důležité od začátku jít správnou cestou, jinak by se na konci u tvoření jednotlivých rozlišení musely například předělat pozice bloků, což neblaze ovlivní původní vzhled. Pro pro- gramátora redesignů je tedy velmi důležité znát používané struktury a ještě důležitější je se učit nové.

Grafika bývá zpravidla dodávána ve formátu PSD, tedy v programu Adobe Photoshop. Návrh bývá dodáván v jednom souboru s velkým počtem vrstev, kde každá zastupuje jeden druh stránky. Jedna speciální vrstva pak zastupuje hover efekty na jednotlivých elementech. Kodér má pak na práci řezat prvky a skládat kousek po kousku web do nového vzhledu. Díky základním znalostem grafiky a dovednosti CSS stylů jsem měl od začátku k Photoshop přístup. To mi umožnilo část věcí individuálně nařezat z komplexního návrhu a nebyl jsem tímto závislý na práci kodéra, což oběma ušetřilo čas.

Asi nejdůležitější část je však schůzka s klientem. Na schůzce se zákazníkem se upřesní jednotlivé stránky webu, funkčnosti a grafika. Pokud je potřeba, jsou se zákazníkem dořešeny některé záležitosti. Případně se rozebírají první prvky návrhu, které už na první pohled nepůjdou zapracovat a klient má hned od začátku možnost s grafikem ještě probrat jejich úpravu. Po schůzce probíhá analýza celého designu a funkcí, která trvá i desítky hodin. Po analýze je klientovi předložena cenová nabídka a zákazník má možnost projednat některé dražší úpravy, zda je bude chtít, či nikoliv. V momentě odsouhlasení započnou práce na vývojovém serveru, kde se postupně kontrolují jednotlivé části, funkce a úpravy.

Nacenění bývá většinou rozděleno do úseků, které se postupně po zapracování a odsouhlasení klientem fakturují. Náročnost úprav se velmi liší a tím i výsledný počet řádků kódu. Jelikož jsem si upravoval základní styly a tím šetřil práci kodérovi, můj výsledný stylesheet měl kolem jednoho tisíce řádků. Pro porovnání má finální kodérův CSS soubor něco kolem 3500 řádků. Redesign je však hlavně o měnění šablon, upravování procedur a občasně se zabrouzdá i do jádra. V šablonách bývají úpravy od desítek do maxima stovek řádků, podobně tak v procedůrách (ke stovce jsem se přiblížil při zpracování procedury pro výběr zboží do filtru). Během redesignu jsem změnil téměř 25 šablon a přibližně 40 procedur. Úpravy jádra jsou povětšinou zanedbatelné, maximálně pak desítky řádků.

(27)

5.5.1 Domovská stránka

První a největší úsek byla domovská stránka. Domovská stránka se skládá z několika modulů, zahrnujících hlavičku, tělo a patičku. Nejtěžší na začátku je fakt, že se vypnou všechny CSS styly. Vzhled je pak čistě textový a lze si jen těžko představit jednotlivé struktury, které vedou k úspěšnému stylování webu.

Práce začaly horní lištou v hlavičce, která obsahuje několik odkazů na články, změnu měny a odkazy pro přihlášení a registraci. Přihlášení se předělalo na box, který po kliku na odkaz s pomocí funkce "slideToggle"zajistí jeho zobrazení. Dále se do hlavičky vložily elementy vy- hledávání, přepínání jednotlivých e-shopů a odkaz do košíku. Poslední položkou hlavičky je horizontální menu kategorií.

Následovala implementace animovaného banneru, který je navíc plně responzivní. V admi- nistraci byla připravena funkčnost pro základní slider (Možnost vkládání obrázků s odkazy). Do šablony jsem tedy vyvedl obrázky do speciální struktury a pomocí jQuery pluginu Owl Carousel se vytvořil animovaný slider [3].

Další blok byl přehled kategorií, ve kterém jsem opět použil z administrace základní slider a vyvedl jej do struktury, ale bez animací a nastylován byl do čtverců s odkazem. Další bloky byly náhodně vybrané produkty novinek, pomocí článku udělané hodnocení zákazníků a přehled posledních vydaných článků.

Jako poslední se řešila patička, která obsahovala 4 sloupce. První tři sloupce jsou odkazy na různé části webu a čtvrtý sloupec slouží k odebírání novinek.

5.5.2 Detail produktu

Druhý úsek byl detail produktu. Zde nepřibylo mnoho nového, takže práce zde byly hlavně změny struktur a přesun již existujících bloků.

Detail byl rozdělen na dva sloupce. V levém sloupci vznikl velký obrázek detailu a pod ním menší alternativní obrázky, které bylo možno přesouvat a prohlížet opět s pomocí Owl Carouselu. Všechny obrázky jsou navázány na jeden společný lightbox. V pravém sloupci je přehled cen produktu, skladovost a možnost zboží zakoupit. Další blok je opět dvousloupcový a obsahuje parametry produktu v levé a popis produktu v pravé části. Poslední modul před patičkou jsou související produkty.

5.5.3 Katalog produktů

Další úsek redesignu byl katalog produktů neboli výpis zboží. Jelikož z úvodní strany již byly hotové boxy zboží, největší a prakticky jedinou velkou úpravou katalogu byl filtr zboží. Samotný

(28)

nový modul katalogu. Díky zaslaným informacím se modul katalog vytvoří s upravenou pro- cedurou a tím i odlišným zbožím a vygenerovaná šablona je pak pomocí JavaScriptu přenačtena namísto stávající. Stejně funguje i stránkování nebo zobrazení dalšího zboží.

5.5.4 Objednávkový proces a ostatní

Jako poslední úsek byl zpracován košík a celý objednávkový proces. Došlo k restrukturalizaci všech kroků. Původní první krok, ve kterém bylo vyplnění všech potřebných údajů k dodání, se přesunul do nového třetího kroku. První krok tak zůstal jen přehled zboží s možností zadat sle- vový kupón. Pokud byl zákazník B2B, v prvním kroku se také zobrazovala daňová rekapitulace.

Druhý krok zůstal téměř neměnný, stále se zde volila platba a doprava. Navíc zde přibyl krátký přehled zboží v košíku, který byl plovoucí při scrollování. Třetí krok nyní zahrnoval všechny potřebné údaje. Pokud bylo v košíku zboží pro zletilé, byl zde i blok pro zadání a potvrzení dospělosti. Nově pro B2B partnery vznikl čtvrtý krok rekapitulace, kde si mohl zákazník zkont- rolovat veškeré zboží, dopravu i platbu. Po odeslání objednávky vznikla nová děkovná stránka, na které taky nově vznikl přehled zakoupeného zboží, ale i přehled nových článků nebo odkaz na facebook firmy [4].

Mezi ostatní se řadí úprava registračního formuláře, který byl velmi podobný tomu z třetího kroku objednávky. Nově se však dělil na B2C zákazníka a B2B firmu. Formulář se pomocí stylů a JavaScriptu přeměňoval a zobrazovaly se rozdílná pole a rozdílné povinnosti vyplnění. Edi- tační formulář se velmi podobal tomu registračnímu. Dále se musely nastylovat tabulky faktur, objednávek a jejich detaily. Mezi ostatní se řadilo i stylování jednotlivých kroků odebírání news- letterů, speciální katalogy v účtu, unikátní článek s hodnocením, kontaktní formulář, reklamační formulář a jiné.

(29)

6 Závěr

Během posledního půl roku jsem ve společnosti poznal všechny produkty a měl tu možnost navštívit všechna oddělení. Firma je už na trhu nějaký čas a tak měla možnost utřídit si priority a hlavně interní strukturu. To jí zajišťuje úspěšnost na poli e-commerce jak u nás, tak v zahraničí.

Systém zpracování tiketů je vyladěn do takové úrovně, že nabízí špičkovou kvalitu servisu a podpory s téměř okamžitou reakcí na jakýkoliv problém. Klienti se tak mohou spolehnout, že pokud se objeví na jejich e-shopu závada, bude ihned odstraněna. Nejdůležitější je ale fakt, že firma drží krok s nejnovějšími trendy a používá nejnovější technologie, takže zákazníci mohou využívat moderní systémy, které jsou svižné a efektivní.

Praxe pro mne byla velkým přínosem, jelikož jsem mohl poznat skutečný programátorský svět a rozšířit si své znalosti. Nejvíce jsem prohloubil se dovednosti v oblasti XSLT šablon a hlavně CSS stylů, které od nové verze CSS3 nabízí spoustu nových funkcí, jako jsou například animace, transformace a přesuny elementů [6]. Dále jsem prověřil své schopnosti v oblasti ASP.NET a jazyka C#, do kterých jsem měl základ z předmětu "Architektura technologie .NET". V nepo- slední řadě jsem se zdokonalil v JavaScriptu a hlavně v odvětí jQuery, které má na starosti celé klientské ovládání e-shopu.

Absolvování praxe však nepřineslo jen zdokonalení schopností, ale je to také dobrý základ pro budoucí kariéru a v dnešní době, kdy jsou potřeba hlavně praktické znalosti, je praxe nesmírně cenná a jsem velice rád, že Vysoká škola báňská umožňuje svým studentům tuto možnost.

(30)

Literatura

[1] Ecomail [online]. [cit. 2016-03-24]. Dostupné z: https://www.ecomail.cz/

[2] Ecomail Apiary [online]. [cit. 2016-03-25]. Dostupné z: http://docs.ecomailczv2.apiary.io/#

[3] Owl Carousel [online]. [cit. 2016-04-10].

Dostupné z: http://www.owlcarousel.owlgraphic.com/docs/started-welcome.html [4] Facebook Page Plugin [online]. [cit. 2016-04-15].

Dostupné z: https://developers.facebook.com/docs/plugins/page-plugin [5] AJAX API Documentation [online]. [cit. 2016-04-17].

Dostupné z: https://api.jquery.com/category/ajax/

[6] CSS3 Introduction [online]. [cit. 2016-04-19].

Dostupné z: http://www.w3schools.com/css/css3_intro.asp

Odkazy

Související dokumenty

Systém VIKIPID je propojen s eAPI platební brány ČSOB. Zákazník přistupuje k platební bráně skrz webovou aplikaci VIKIPID Brána, ve které si před přesměrováním k

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ž

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ě

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

Na tomto projekte bolo mojou úlohou nájsť všetky dostupné riešenia, ktoré by sa dali použiť.. V prvej fáze bolo tiež mojou úlohou zozbierať dáta zo senzorov v mobile

Obsahuje tyto důležité metody: metodu runScript pro aplikaci SQL skriptů (obsahuje proměnnou except typu String pro vypsání chyby, pokud nějaká při aplikaci SQL skriptu