modul pro rozesílání zpráv uživatelům webové aplikace mojilidi file7 abstract valovič,...

Mendelova univerzita v BrněProvozně ekonomická fakulta

Modul pro rozesílání zprávuživatelům webové aplikace

Mojilidi.cz

Bakalárska práca

Vedoucí práce:Ing. Jan Přichystal, Ph.D. Roman Valovič

Brno 2017

Obzvlášť by som rád poďakoval môjmu vedúcemu, Ing. Janu Přichystalovi,Ph.D., za jeho ochotu, trpezlivosť a množstvo cenných rád, ktoré mi poskytol počaspísania tejto práce. Poďakovanie patrí aj celému vývojovému tímu aplikácie Mojilidi, za ich priateľský prístup a pomoc.

Prehlasujem, že som prácu: Modul pro rozesílání zpráv uživatelům webovéaplikace Mojilidi.cz vypracoval samostatne a všetky použité zdroje a informácieuvádzam v zozname použitej literatúry. Súhlasím, aby bola moja práca zverejnenáv súlade s § 47b zákona č. 111/1998 Sb., o vysokých školách v znení neskoršíchpredpisov a v súlade s platnou Směrnicí o zveřejňování vysokoškolských závěrečnýchprací. Som si vedomý, že sa na moju prácu vzťahuje zákon č. 121/2000 Sb., autorskýzákon a že Mendelova univerzita v Brne má právo na uzatvorenie licenčnej zmluvy apoužitie tejto práce ako školského diela podľa § 60 odst. 1 Autorského zákona. Ďalejsa zaväzujem, že pred spísaním licenčnej zmluvy o použití diela inou osobou (subjek-tom) si vyžiadam písomné stanovisko univerzity, že predmetná licenčná zmluva nieje v rozpore s oprávnenými záujmami univerzity a zaväzujem sa uhradiť prípadnýpríspevok na úhradu nákladov spojených so vznikom diela, a to až do ich skutočnejvýšky.

V Brne dňa 16. mája 2017 ................................................................

7

AbstractValovič, R. – Module for sending messages to users of web application Mojilidi.cz.Brno 2017

This thesis deals with development of individual part of web application Mojilidi, which takes care of automated sending e-mail messages based on users’s acti-vities. Reader gets familiar with all phases of software development – from initialanalysis, to final implementation. The content of thesis is focused on various do-mains such as creating a HTML documents, data selection and data processing withuse of Perl programming language. Main focus is aimed at specificity of sending aand presentation of HTML documents by e-mail clients and services.

Keywordsweb application, Perl, HTML, CSS, e-mail, Postgre, TDD, user’s notifaction

AbstraktValovič, R. – Modul pro rozesílání zpráv uživatelům webové aplikace Mojilidi.cz.Bakalárska práca. Brno 2017

Práca sa zaoberá tvorbou samostatnej časti webovej aplikácie Moji lidi sta-rajúcej sa o automatizované zasielanie grafických e-mailových správ na za základečinností používateľov. Práca prevedie čitateľa všetkými fázami vývoja programové-ho diela – od analýzy problému, až po finálnu implementáciu. Obsah práce sa venujerôznym oblastiam ako sú tvorba HTML dokumentov, výber dát z SQL databáze atiež spracovanie dát skriptovacím jazykom Perl. Dôraz pri tom kladie na špecifikáspojené so zasielaním a interpretáciou HTML dokumentov v e-mailových službách.

Kľúčové slováwebová aplikácia, Perl, HTML, CSS, e-mail, Postgre, TDD, notifikácie používateľov

OBSAH 9

Obsah1 Úvod a cieľ práce 11

1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Cieľ práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Prehľad literatúry 132.1 Webová aplikácia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Komunikácia so serverom . . . . . . . . . . . . . . . . . . . . 132.1.2 MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.3 Server-side technológie . . . . . . . . . . . . . . . . . . . . . . 152.1.4 Plánovač úloh Cron . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Validné HTML a CSS v mailových klientoch . . . . . . . . . . . . . . 162.2.1 Testované služby a lokálny klienti . . . . . . . . . . . . . . . . 162.2.2 Rozvrhnutie obsahu – layout . . . . . . . . . . . . . . . . . . 162.2.3 Formát zápisu CSS . . . . . . . . . . . . . . . . . . . . . . . . 172.2.4 Responzívne zobrazenie v e-mailových klientoch . . . . . . . . 18

2.3 Metodika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Analýza problému a návrh riešenia 213.1 Aplikácia Moji lidi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Funkčné požiadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Typy zasielaných správ . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 Notifikácia registrácii nového používateľa . . . . . . . . . . . . 223.3.2 Žiadosť o obnovu zabudnutého hesla . . . . . . . . . . . . . . 233.3.3 Autorizácia žiadosti o obnovu hesla . . . . . . . . . . . . . . . 243.3.4 Sumárny prehľad neprečítaných správ . . . . . . . . . . . . . 25

3.4 Používateľské nastavenia notifikácií . . . . . . . . . . . . . . . . . . . 26

4 Implementácia riešenia 284.1 Implementácia grafických šablón . . . . . . . . . . . . . . . . . . . . . 284.2 Algoritmus výberu dát . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1 Neprečítané správy . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Viacjazyčné prostredie . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 Generovanie dokumentu . . . . . . . . . . . . . . . . . . . . . . . . . 344.5 Prevod CSS do riadkového zápisu . . . . . . . . . . . . . . . . . . . . 374.6 Odosielanie e-mailu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.7 Používateľské nastavenie upozornení . . . . . . . . . . . . . . . . . . 43

4.7.1 Webové rozhranie . . . . . . . . . . . . . . . . . . . . . . . . . 444.7.2 Spracovanie nastavení . . . . . . . . . . . . . . . . . . . . . . 444.7.3 Automatické zasielanie upozornení . . . . . . . . . . . . . . . 46

4.8 Výsledná architektúra a zavedenie modulu . . . . . . . . . . . . . . . 464.9 Validácia HTML a testovanie . . . . . . . . . . . . . . . . . . . . . . 48

10 OBSAH

5 Diskusia 495.1 Známe nedostatky a návrhy zlepšení . . . . . . . . . . . . . . . . . . 50

6 Záver 52

7 Referencie 54

Prílohy 56

A Šablóny HTML dokumentov 57A.1 Registrácia používateľa . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.2 Žiadosť o obnovu hesla . . . . . . . . . . . . . . . . . . . . . . . . . . 58A.3 Obnova zabudnutého hesla . . . . . . . . . . . . . . . . . . . . . . . . 59A.4 Prehľad neprečítaných správ . . . . . . . . . . . . . . . . . . . . . . . 60

B Ukážky interpretácie v niektorých e-mailových službách 61B.1 Gmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61B.2 post.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62B.3 Poštový klient Thunderbird . . . . . . . . . . . . . . . . . . . . . . . 63B.4 Mobilný klient Apple Mail . . . . . . . . . . . . . . . . . . . . . . . . 64

1 ÚVOD A CIEĽ PRÁCE 11

1 Úvod a cieľ práce1.1 Úvod do problematikyWebové aplikácie sú bezpochyby jednou z najprogresívnejších oblastí informatiky.Stačí sa len obzrieť späť len o dve desaťročia, kedy hlavným obsahom internetu bolistatické webové prezentácie, ktoré by sme len sťažka mohli nazvať aplikáciami, takako ich poznáme dnes.

S nástupom nových technológií a štandardov v tejto oblasti (hlavne Web 2.0),začíname webu rozumieť už nie len ako firemnej či osobnej prezentácii, ale ako novejplatforme, na ktorej môžeme postaviť tie najrozsiahlejšie aplikácie prístupné každé-mu používateľovi, ktorý disponuje pripojením do internetu a webovým prehliadačomna akomkoľvek druhu zariadenia.

Tak ako technológie prinášajú nové možnosti, tak s nimi prichádzajú aj s novéúskalia a problémy, ktoré doposiaľ vývojári nepoznali. Vznikajú komplexné progra-mové diela, využívajúce množstvo moderných prístupov a často ani nie je v siláchjedinca – programátora, aby takéto dielo navrhol a implementoval úplne sám. Dielateda rozdeľujeme do modulov, menších nezávislých programových celkov, na ktorýchpracujú vývojári asynchrónne. Jedným z takých modulov je aj modul rozposiela-nia notifikačných správ aplikácie Moji lidi ktorým sa bude táto bakalárska prácazaoberať.

Aplikácia Moji lidi slúži ako nástroj pre podporu ľudí ponúkajúc svoje služby.Nemusí sa pri tom jednať výlučne o podnikateľské subjekty, aplikáciu môžu využívaťaj všetky fyzické osoby. Hlavnou myšlienkou aplikácie je rýchle vyhľadanie ľudí, ktorísú schopní pomôcť používateľovi vyriešiť zadaný problém.

Pre vyhľadávanie sa využíva špecializovaný algoritmus analýzy textu. Použí-vateľ prirodzenou rečou napíše do vstupného poľa svoju požiadavku a systém muvráti relevantný zoznam ľudí, ktorých môže priamo v aplikácii osloviť a dohodnúťsi s nimi ďalšiu spoluprácu.

Komunikácia medzi používateľmi prebieha na jednej platforme, priamo v apliká-cii. Nie je nutné zložite oslovovať každého potenciálneho dodávateľa zvlášť rozposie-laním e-mailov či telefonicky. V Moji lidi stačí dotaz formulovať len raz a na jedinommieste.

Používatelia môžu nielen služby vyhľadávať, ale aj ponúkať. Aplikácia je posky-tovaná zdarma a neplynú z nej žiadne záväzky ani pre jednu z obchodujúcich strán.Výsledky vyhľadávania nie sú nijak ovplyvňované reklamou, dodávateľ môže svojeumiestnenie vo výsledkoch vyhľadávania zlepšiť len kvalitou svojich služieb, ktorá jeostatnými používateľmi hodnotená.

Aplikácia je v súčasnosti stále vo vývoji, na ktorom sa podieľa Mendelova uni-verzita v Brne, ale jej ostrá verzia je už dostupná na adrese https://mojilidi.cz.

Táto práca je napísaná v slovenskom jazyku, avšak v ukážkach vlastnej práce(zdrojové kódy, obrázky, databázová schéma atď.) možno nájsť pomenovania v češ-

12 1 ÚVOD A CIEĽ PRÁCE

tine. Je to z dôvodu, že tieto ukážky sú prevzaté z vývoja, prípadne priamo z ostrejverzie aplikácie, ktorá je lokalizovaná práve do českého jazyka.

1.2 Cieľ práceNa základe nadobudnutých poznatkov počas štúdia a praktických skúseností je cie-ľom tejto práce navrhnúť a implementovať modul aplikácie Moji lidi, ktorý sa staráo plne automatické generovanie a rozposielanie informatívnych emailových správpoužívateľom. Dôraz pri tom kladie na naplnenie požiadavkov zadávateľa a záro-veň na čo najefektívnejšie využívanie hardvérových prostriedkov a možností danéhoprogramovacieho jazyka, v ktorom sú jednotlivé časti modulu implementované.

Medzi požiadavky zadávateľa patrí aj to, aby tieto informatívne maily mali gra-fickú podobu a nezasielal sa teda len prostý neformátovaný text. E-mailová správabude teda obsahovať HTML dokument, ktorý ponúka omnoho širšie možnosti využi-tia grafiky a dizajnu než obyčajný text. S tým sa však spája množstvo technickýchproblémov, ktoré sa v tejto prácu pokúsime vyriešiť.

2 PREHĽAD LITERATÚRY 13

2 Prehľad literatúryPred samotnou analýzou problému je vhodné zoznámiť sa s technológiami, s ktorýmibudeme pracovať. Na nasledujúcich riadkoch si ich stručne predstavíme.

V prvej časti tejto práce sa preto budeme zaoberať prehľadom dostupných tech-nológií a nástrojov a ich prípadnému využitiu pre riešenie nášho zadania. Bude sajednať hlavne o technológie týkajúce sa vývoju webových stránok ako HTML, CSS,ukladania dát ako Postgre, či ich spracovanie na strane serveru skriptovacím jazy-kom Perl. Taktiež sa zameriame na analýzu daného problému a navrhneme možnéscenáre jeho riešenia.

2.1 Webová aplikáciaAplikácie môžeme všobecne rozdeliť na natívne, webové a hybridné. (Gasston, 2015)

• Natívne sú stavané na newebových technológiach, pre konkrétne operačné sys-témy.

• Webové sú postavané na webových technológiach a môže sa jednať o hostovanéwebové stránky, ale aj o aplikácie zbalené do komprimovaných balíkov, ktorémožno nainštalovať na zariadenie.

• Hybridné používajú webové technológie, ale bývajú zabalené do natívnych ba-líkov.

V tejto práci sa budeme zaoberať výlučne tými webovými. Webová apliká-cia je špecifická najmä tým, že je používateľovi prístupná len skrz počítačovú sieť(spravidla internet). Na rozdiel od klasických desktopových aplikácií, tá webová be-ží v prostredí serveru a nie lokálne na zariadení používateľa. Používateľ s aplikácioupracuje prostredníctvom prehliadača, ktorý sa v tomto kontexte nazýva aj tenkýklient1. Aspektom tenkého klienta je okrem iného aj to, že nepozná logiku bežiacejaplikácie. Zo serveru teda len príjme spracované dáta, ktoré prezentuje používate-ľovi, prípadne naopak, vstupy od používateľa odosiela na server k spracovaniu.

2.1.1 Komunikácia so serverom

Odpoveď serveru sa môže, a spravidla sa aj líši, s každým požiadavkom klienta.Používateľom sa tak zobrazujú stránky, ktorých obsah sa mení s časom na základedaných udalostí (napr. stlačenie tlačidla, odoslanie formuláru, čas zobrazenia strán-ky atď.). Stránky sú vytvorené v okamihu požiadavky na jej zobrazenie (Dařena,2005).

V rámci komunikácie sú s spolu s požiadavkami odosielané aj parametre, ktoréslúžia na bližšiu špecifikáciu požiadavku. Môže sa jednať o údaje z vyplnených políformulára, údaje o prihlásenom používateľovi, údaje vyhľadávania a podobne.

1thin client

14 2 PREHĽAD LITERATÚRY

Protokol HTTP definuje metódy, určené pre spracovanie týchto parametrovv rôznych typoch požiadavkov. Hlavnými a najpoužívanejšími HTTP metódami súPOST, GET, PUT a DELETE. Tie zodpovedajú operáciám typu create, read, upda-te a delete (zjednodušene CRUD) (Fredrich, 2017).

2.1.2 MIME

Po úspešnom spracovaní požiadavku odoslaného jednou z vyššie uvedených me-tód, obdrží klient v odpovedi okrem stavového kódu aj samotné dáta. Dáta zo serve-ru môžu byť rôzneho formátu a rozhodne nie sme obmedzení len na textové reťazce.

Aby sme pochopili význam MIME štandardu, musíme sa ohliadnuť trochudo minulosti. Pôvodný e-mailový protokol SMTP2 bol totiž schopný prenášať lentextové správy, a naviac, len v kódovaní ASCII (1 znak na 7 bitov, celkom 128 plat-ných znakov, vrátane riadiacich). Takže nebolo možné poslať elektronickou poštoučokoľvek iné, než text bez diakritiky, ani vo forme prílohy.

Odpoveďou na tento problém bolo štandardizácia MIME. MIME definuje, akýmspôsobom majú byť zakódované rôzne dáta do podoby čistých ASCII znakov a môžubyť tak prenesené e-mailovým protokolom. Ďalšou funkciou štandardu je informovaťpríjemcu o aký typ dát sa v správe jedná, aby ich príslušný klient dokázal správneinterpretovať. Informácie o dátovom type sa nachádzajú v položke označovanej akoMIME Content-Type (Borenstein a kol., 1992).

Jedná sa o znakový reťazec ktorý má dve zložky. Prvá určuje základný typdát, druhá ho bližšie upresňuje (tzv. subtyp). Pre prvú zložku existuje sedemzákladných možných hodnôt:

• application – binárne dáta určené pre spracovanie určitou aplikáciou,

• audio – zvukové informácie,

• image – obrazové informácie,

• message – správa,

• multipart – kombinácia viacerých typov v rámci jednej prílohy,

• text – text v rôznych znakových sadách, formátovaný text, HTML a pod.,

• video – video dáta.

Subtyp ďalej upresňuje formát súboru. Často sa stretávame definíciamitext/plain, text/html, image/jpeg, application/json atď. Subtypov existuje nepre-berné množstvo. Úplný zoznam udržiava IANA a možno ho nájsť na webe3.

Štandard MIME nenašiel svoje uplatnenie len v prenose e-mailových správ.Osvojil si ho aj protokol HTTP a využíva ho pre komunikáciou prostredníctvom

2Simple Mail Transfer Protocol3https://www.iana.org/assignments/media–types/media–types.xhtml

2.1 Webová aplikácia 15

vyššie spomínaných metód. Z toho vyplýva, že HTTP protokol dokáže prenášaťakýkoľvek dátový typ.

2.1.3 Server-side technológie

Dynamicky vytváraný obsah spravidla riadi obslužný program nainštalovaný na stra-ne serveru. Spracúva dáta získané od používateľa jednou z metód popísaných v pred-chádzajúcich odsekoch, odosiela odpovede na prichádzajúce požiadavky a, vo vše-obecnosti, implementuje logiku samotnej aplikácie.

Tento program môže byť napísaný v ktoromkoľvek programovacom jazyku. Ne-záleží pri tom, či sa jedná o interpretovaný alebo kompilovaný jazyk. V súčasnostisa na poli backendu najčastejšie využívajú jazyky PHP, Java, Perl, Python, Rubya ich rôzne deriváty.

Aplikácia Moji lidi implementuje logiku v programovacom jazyku Perl.

2.1.4 Plánovač úloh Cron

Súčasťou operačných systémov Linux a jeho rôznych distribúcii je štandardný prog-ramový balíček Cron. Podotýkame, že na webovom serveri, na ktorom je umiestnenáaplikácia Moji lidi beží systém CentOS 7.

Cron slúži pre riadené spúšťanie rôznych úloh v stanovenom čase. Môže sapri tom jednať o systémové volania alebo spúšťanie vlastných shell skriptov aleboprogramov. Riadené spúšťanie príkazov môžeme definovať v súbore crontab, ktorýsa obvykle nachádza v adresári etc.

Po otvorení súboru pre editáciu môžeme pridávať, odoberať a upravovať po-ložky, ktoré definujú kedy a čo má Cron vykonať. Každá položka začína piatimistĺpcami, ktoré určujú čas spustenia – minúta, hodina, deň v mesiaci, mesiac, deňv týždni). Do každého stĺpca možno zapísať hodnoty korešpondujúce so skutočnýmvyjadrením času. Jedinú výnimku tvorí v stĺpci deň v týždni nedeľa, ktorú možnovyjadriť číslom 0 alebo, pre nás prirodzenejšie, 7. Pokiaľ namiesto čísla zapíšemeznak hviezdička (*), Cron ju interpretuje ako zástupný znak vyjadrujúci všetkymožné hodnoty.

Nie je vhodné plánovať spustenie viacerých úloh v rovnakom čase, resp. na celéhodiny, polhodiny alebo štvrťhodiny. Vhodnejšie je naplánovať spustenie niekoľ-ko minút pred alebo potom. Znižuje sa tak pravdepodobnosť súčasného spusteniaviacerých úloh naraz a výrazného zaťaženia systému. Každý používateľ môže defi-novať svoju tabuľku Crontab, do ktorej ostatní používatelia s výnimkou root nemajúprístup (Sobbel, 2007).

Nasledujúca tabuľka Cronu spustí skript uloha.pl každý pondelok v čase 10:00.uloha2.pl bude spustený denne vždy každú piatu minútu hodiny. uloha3.pl sa spustíkaždých 5 minút. Skripty sú uložené v adresári /home/bin.00 10 * * 2 $HOME/bin/uloha.pl05 * * * * $HOME/bin/uloha2.pl*/5 * * * * $HOME/bin/uloha3.pl


2.2 Validné HTML a CSS v mailových klientochElektronická pošta sa aj napriek svojej svojmu veku považuje za jeden z najpoužíva-nejších komunikačných prostriedkov v sieti Internet. Pôvodný komunikačný protokolSMTP onedlho oslávi 40 rokov od svojej prvej špecifikácie v dokumente RFC 821(Postel, 2016).

Našťastie, vďaka rozšíreniu MIME dokážeme e-mailom posielať viac než lenprostý text so znakmi anglickej abecedy. V poslednom desaťročí sme mohli zazna-menať rôzny grafický obsah e-mailových správ v našich schránkach. Nie je sa čomudiviť, reklamná ponuka, oznámenie alebo potvrdenie objednávky z elektronickéhoobchodu osloví používateľa viac, ako len sotva naformátovaný čierny text na bielompozadí. Taktiež je možné priamo do tela správy zahrnúť média ako obrázky, videoalebo napríklad pdf dokument. Používateľ tak nemusí tieto súbory otvárať explicitnev prílohe. Správa môže obsahovať aktívne prvky ako tlačítka a odkazy vykonáva-júce určitú činnosť („Kliknutím zaplať“, „Potvrď registráciu“ a i.). Táto koncepciaotvára využiteľnosti e-mailu nové možnosti a nesporne prináša vysokú marketingovúvýhodu jej prevádzkovateľom,

Ako ideálny prostriedok formátovania dokumentu zasielaného e-mailom sa javíjazyk HTML a CSS, má to však isté úskalia. E-mailový klienti jednotlivých služiebvšak vnímajú HTML rôzne a ich podpora HTML sa vzájomne značne líši. Dokoncamôžeme badať výrazne odlišnosti od webových prehliadačov. Podpora tak závisí odkonkrétnej e-mailovej služby a o nejakej štandardizácii nemôžeme hovoriť. Tentofakt brzdí vývojárov, pretože sa nemôžu spoliehať na niektoré už štandardizovanéfunkcie jazyka HTML a CSS. Svoj kód musia navrhnúť a implementovať tak, abypokryli čo najširší záber e-mailových služieb a obsah ich správy bol korektne pre-zentovaný používateľom.

V čase písania tejto práce sme nenašli žiadne oficiálne dokumenty, normy čišpecifikácie definujúce všeobecne uznávanú štruktúru a podporu jazyka HTML v e-mailových klientoch. Literárne zdroje sú v tejto tematike pomerne strohé. V ďalšíchodsekoch sa tak budeme prevážne odvolávať na informácie získané z neoficiálnychzdrojov, ktoré sme však overili vlastným otestovaním a môžeme ich tak označiťza pravdivé.

2.2.1 Testované služby a lokálny klienti

Pred začatím implementácie samotného HTML dokumentu, sa pozrieme na už spo-mínanú rozdielnu podporu jednotlivých e-mailových služieb. Naším cieľom je korekt-ne zobrazovaný dokument v čo najširšom spektre e-mailových klientov. Zameriamesa na najpoužívanejšie služby a klientov českými používateľmi.

2.2.2 Rozvrhnutie obsahu – layout

Všeobecne podporovaná koncepcia rozvhrhnutia HTML dokumentov v e-mailovýchsprávach je dnes už prekonané a zriedka používané tabuľkové rozvrhnutie. Celá

2.2 Validné HTML a CSS v mailových klientoch 17

stránka vystupuje ako jedna veľká tabuľka elementu <table>. Prvky dokumentusú pozicované pomocou elementu <tr>, resp. <td>. Ukážku tabuľkového rozvrhnu-tia ilustruje obrázok 1.

Obrázok 1: Ukážka tabuľkového rozvrhnutia.Zdroj: https://goo.gl/sOQZ22

Dôvodom pre použitie tabuliek ako rozvrhnutia je úzka podpora e-mailovýchklientov prvkov jazyka CSS. Nie je teda bezpečné spoliehať sa na pozicovanie prvkovaplikovaním vlastností position, float, margin a pod., nakoľko by tieto vlast-nosti mohli byť klientom ignorované a dochádzalo by k rozpadu grafickej štruktúrydokumentu.

Nevýhodou tabuľkového rozvrhnutia je pomalšie načítanie obsahu a náročnejšízápis kódu. Niektoré prehliadače, konkrétne starší Internet Explorer, nezobrazu-jú obsah stránky po jednotlivých bunkách, ale čakajú na stiahnutie celého obsahutabuľky a až následne vykreslia hotovú stránku (Janovský, 2007). Predpokladámevšak, že e-mailom zasielané HTML správy nebudú príliš rozsiahle a taktiež, nebu-dú obsahovať prvky náročné na vykreslenie. Preto môžeme tabuľkové rozvrhnutieaplikovať bez obáv z nepríjemností spojených s pomalým načítavaním obsahu.

2.2.3 Formát zápisu CSS

Existuje niekoľko možností zápisu jazyka CSS. Využívame tieto tri formy definícieštýlov:

• štýl definovaný v hlavičke dokumentu,


• štýl definovaný v externom súbore, na ktorý odkazujeme v hlavičke,

• štýl definovaný pre každý element, tzv. riadkový4 štýl.

Dnes sa pochopiteľne najčastejšie stretávame s formou štýlu definovaného v ex-ternom súbore, prípadne so štýlom v hlavičke dokumentu. Riadkový zápis je úplnevýnimočný a vývojári sa mu vyhýbajú. Dôvodov je viacero, no medzi najsilnej-šie negatíva patrí veľmi neprehľadný zápis, porušovanie prístupu oddeľovania formyod obsahu a v neposlednom rade – nemožnosť využiť niektoré moderné funkcie ja-zyka CSS3.

Posledné menované negatívum trochu rozvedieme. Jednou z hlavných myšlie-nok CSS je tzv. kaskádovitosť – v tomto kontexte pojmu rozumieme ako uplatňova-nie určitej vlastnosti na všetky vyhovujúce elementy stránky zhora–dolu. V praxi toznamená, že ak uplatníme vlastnosť h1: {color: red}, tak všetky elementy <h1>budú mať farbu písma červenú. V prípade riadkového zápisu sa kaskáda neuplatňu-je. Vlastnosť sa aplikuje výlučne len pre ten jediný element, na ktorom je definovaná.Ďalšou nepríjemnosťou je nemožnosť (alebo len veľmi komplikovane) uplatniť jedenštýl pre viacero stránok. V prípade štýlu zapísaného v externom súbore stačí na-staviť správny <link> v hlavičke. Naopak pri riadkovom štýle, nezostáva iné, nežručný prepis.

Napriek značným nevýhodám riadkového zápisu CSS, je táto forma tou najbez-pečnejšou alternatívou, čo sa do podpory e-mailových klientov týka. Tie totiž čas-to ignorujú hlavičku dokumentu, konkrétne sú to napríklad seznam.cz, centrum.cza Office 365, (<head>) a interpretujú až telo (<body>). Keďže definícia štýlu aleboodkaz na súbor sa nachádza práve v ignorovanej časti, dochádza k rozpadu a častoaj nečitateľnosti dokumentu. Naopak, s interpretáciou a korektným aplikovanímvlastností zapísaných riadkovým štýlom, nemajú klienti žiaden problém.

2.2.4 Responzívne zobrazenie v e-mailových klientoch

Nepríjemná komplikácia nastáva v prípade, kedy požadujeme vlastnosť responzív-neho zobrazovania. Dotazy na médium, mechanizmus umožň nie je možné zapísaťinak, ako v štýle definovanom v hlavičke, resp. v externom súbore (Lubbers a kol.,2001). V riadkovom štýle doposiaľ neexistuje nástroj, za pomoci ktorého by smemohli dosiahnuť responzívneho zobrazovania. Neočakávame ani, že v budúcnostibude táto funkcionalita implementovaná. Môžeme skôr hovoriť o rastúcej podpore<style> v hlavičkách dokumentov zo strany e-mailových klientov a služieb.

2.3 MetodikaPri vývoji algoritmov a programov na strane backendu uplatňujeme príncíp TDD –Test driven development5. Beck (2003) popisuje metodiku TDD ako prístup, v kto-

4inline5Testami riadený vývoj

2.3 Metodika 19

rom napíšeme test ešte pred tým, než implementujeme samotnú funkcionalitu. Opa-kovaným spúšťaním testu a postupnými úpravami kódu dosiahneme stavu, kedy testprebehne úspešne. Cieľom takéhoto prístupu je donútiť programátora zamyslieť sanad všetkými možnými scenármi, ktoré môžu za behu programu nastať (na štan-dardnom vstupe sa objavia neplatné znaky, nepodarí sa prečítať súbor, dotaz z data-báze vráti prázdnu hodnotu a pod.). Programátor môže tieto potenciálne problémyošetriť, prípadne im úplne zabrániť už počas prvej fáze vývoja. Pravdepodobnosťzlyhania programu v ostrej prevádzke tak rapídne klesá.

Postup TDD by sme mohli stručne popísať nasledovne (Ambler, 2013):

1. Napísať test – ako sme načrtli, prvým krokom vývoja každej novej komponen-ty programu je vytvorenie testu, ktorý bude overovať, či komponenta splňujetakú funkcionalitu, aká sa od nej očakáva. Programátor sa napísaním prvéhotestu sám ubezpečuje, že presne rozumie požiadavkom na vyvíjanú komponentua nebude sa od nich počas písania kódu odchyľovať.

2. Spustiť testy – spustíme všetky zatiaľ napísané testy. Pochopiteľne, žiaden bynemal prejsť úspešne vzhľadom na to, že ešte nemáme implementované testo-vané komponenty. Pokiaľ niektorý test prešiel úspešne, je to znakom nesprávnenapísaného testu a mali by sme ho opraviť. Druhou možnosťou je, že tentotest bude úspešný vždy a nemá preto zmysel zamýšľanú komponentu vôbecimplementovať.

3. Napísať kód – v tomto kroku nasleduje samotná implementácia komponent.Cieľom je rýchle napísanie len takého kódu, vďaka ktorému komponenta úspešneprejde testami. Nezameriavame sa pri tom na prílišnú efektivitu a eleganciukódu, to nie je myšlienkou tohto kroku. Ide nám skutočne len o splnenie testov.

4. Spustiť testy – spustíme testy, tentokrát už s implementovanými komponen-tami. Očakávame úspešne ukončenie všetkých testov, pokiaľ niektorý zlyhá-va, vrátime s ku kroku tri.

5. Refaktorizácia – efektivitu a eleganciu kódu, ktorú sme predtým zanedbávali,napravíme v tejto fázy. Odstraňujeme duplicity, snažíme sa kódu dodať štruk-túru a zrozumiteľnosť. Opakovaným spúšťaním testov sa ubezpečujeme, že našezásahy neovplyvnili správnu funkčnosť komponenty.

Popisované kroky neustále opakujeme pri každej novej komponente, či pri zme-ne požiadavkov na už existujúcu komponentu. Pri písaní prvého testu, ktorý vo svo-jej podstate definuje požiadavky na danú komponentu, vychádzame z use–case dia-gamov, diagramu aktivít (activity diagram), user stories, alebo inej vhodnej špeci-fikácie využívanej v oblasti systémového inžinierstva. Vývojový diagram pri uplat-ňovaní princípu TDD zobrazuje obrázok 2.

Metodika TDD je v súčasnosti veľmi uznávaný a moderný prístup pri vývo-ji software. Okrem iného, rešpektovaním jej princípov máme beh programu podneustálou kontrolou. Máme tak istotu že prípadná zmena, ktorú vykonáme v jed-


nej časti programu negatívne neovplyvní inú časť, prípadne program ako celok. Topovažujeme za jeden z jej najsilnejších prínosov.

Ďalšou možnosťou by bolo využiť niektorý z iteratívnych prístupov, napr. kla-sický vodopád, či prototypový model. Tieto metodiky sú však strnulé, časovo ná-ročné a vyžadujú častú komunikáciu so zadávateľom. V prípade potreby zmenyje nutné zbytočne opakovať niektoré kroky a vrátiť sa tak v podstate na začiatokvývoja. Z týchto dôvodov sme sa rozhodli uplatniť práve metodiku TDD.

Obrázok 2: Vývojový diagram TDD

3 ANALÝZA PROBLÉMU A NÁVRH RIEŠENIA 21

3 Analýza problému a návrh riešeniaPred samotnou fázou implementácie je nevyhnutné zamyslieť sa nad požiadavkamizadávateľa a analyzovať možné problémy a ich riešenia. Nemenej dôležité je zoznámiťsa s architektúrou a technologickými princípmi už existujúcej aplikácie alebo jejčasti, s ktorou náš modul bude spolupracovať. Zamerajme sa preto v úvode napožiadavky zadávateľa.

3.1 Aplikácia Moji lidiAko sme v úvode tejto práce načrtli, aplikácia slúži ako nástroj pre sprostredkova-nie obchodu medzi dodávateľom a potenciálnym zákazníkom (ďalej len zákazník).Zákazník – používateľ – si vyberá medzi dodávateľmi a v prípade záujmu ich môžekontaktovať priamo v aplikácii zabudovaným systémom výmeny správ. K uzavretiuobchodu teda dochádza individuálne medzi oboma stranami na základe ich vzá-jomnej dohody. Aplikácia nezaručuje uzavretie obchodného vzťahu len na základeprvotného oslovenia zo strany zákazníka a nedefinuje nič ako záväznú objednáv-ku služieb. Nutno podotknúť, že systém Moji lidi sa nestáva prostredníkom medziobchodujúcimi stranami, zákazník vždy jedná len priamo s obchodníkom.

3.2 Funkčné požiadavkyZo zadanej úlohy vyplýva požiadavka na vývoj novej funkcionality, ktorá by bolaschopná automaticky reagovať na rôzne udalosti alebo akcie vyvolané používateľom.Reakciou je v našom prípade vygenerovanie informatívnej správy a jej zaslanie nae-mailovú adresu daného používateľa. Zadávateľ vymedzil tieto požiadavky:

• plne autonómny režim,

• možnosť vymedzenia času (hodiny a dňa), v ktorom si používateľ želá prijímaťpravidelné notifikačné správy,

• graficky obalená forma správ,

• design kompatibilný s aplikáciou,

• jednoduchá rozšíriteľnosť o ďalšie typy notifikačných správ.

Aby sme splnili tieto požiadavky, budeme implementovať riešenia na rôznychúrovniach aplikácie.

Pre dosiahnutie autonómneho režimu je potrebné vytvoriť mechanizmus, ktorýbude sledovať činnosť používateľa a na jej základe vyvolá spustenie príslušného prog-ramu. Zasielanie správ v konkrétnom čase bude vyžadovať nástroj, ktorý je schopnýspúšťať príslušné programy v naplánovanom čase. Aplikácia beží na serveri s Uni-xovým operačným systémom CentOS, takže pre tento účel využijeme nástroj Cron,ktorý je jeho štandardnou súčasťou. Z povahy navrhovaného riešenia vyplýva, že pre

22 3 ANALÝZA PROBLÉMU A NÁVRH RIEŠENIA

splnenie prvých dvoch uvedených požiadavkov budeme pracovať v prostredí backen-du. Aplikácia je implementovaná na backende v jazyku Perl. Bolo by neefektívne, ajkeď nie nereálne, implementovať jednotlivé časti aplikácie v rôznych programovacíchjazykoch, takže pre naše riešenie použijeme takisto jazyk Perl.

Naopak, požiadavky týkajúce sa formy designu správ svojou povahou spadajúdo prostredia front–endu. Budeme pracovať v jazyku HTML / CSS a vytvorí-me šablóny dokumentov, ktoré dynamicky naplníme skutočnými dátami z aplikáciea pošleme daným používateľom do ich e-mailových schránok. Vzhľadom na to, ženevieme akú e-mailovú službu resp. klienta používateľ využíva, musíme prihliadaťna rôzne prístupy e-mailových klientov k prezentácii HTML dokumentov. Tútoproblematiku sme rozobrali v podkapitole 2.2. Taktiež, musíme zabezpečiť zobra-zenie e-mailovej správy aj v prípade, že klient používateľa pracuje len v textovomrežime a neumožňuje teda zobrazenie grafického obsahu. V tomto prípade využi-jeme mechanizmus MIME a nastavíme typ správy6 ako multipart/alternative.Tento mechanizmus umožňuje definovať alternatívny obsah správy v prípade, že sanepodarí zobraziť primárny obsah.

3.3 Typy zasielaných správV tejto práci budeme implementovať reakciu systému na tieto štyri udalosti.

• registrácia nového používateľa,

• žiadosť o obnovu zabudnutého hesla,

• autorizácia žiadosti o obnovu hesla,

• sumárny prehľad neprečítaných správ za posledných 24 hodín.

Pre každú z nich bude zasielaná e-mailová správa s odlišným obsahom, avšaks jednou formou. Všetky správy budú generované rovnakým skriptom, pri ktoromsa menia len vstupné parametre.

3.3.1 Notifikácia registrácii nového používateľa

Prvou udalosťou, o ktorej bude používateľ informovaný e-mailovou správou je úspeš-ná registrácia. Po validácii registračného formulára, kde používateľ zadá meno, priez-visko, e-mailovú adresu a heslo sa tieto dáta odošlú na backend, kde dôjde k ichspracovaniu a vytvoreniu nového používateľského profilu. Ak bola požiadavka naregistráciu úspešne vybavená, backend odpovie statusom 200 OK.

V našom prípade využijeme odoslané dáta registračného formuláru a do požia-davku na registráciu vložíme aj požiadavku na vygenerovanie správy, ktorej odo-vzdáme dáta zadané používateľom. Výsledkom je, že vedľajším efektom úspešnejregistrácie používateľa bude aj odoslanie notifikačnej správy na jeho e-mail.

6Content-type

3.3 Typy zasielaných správ 23

Prvotný dizajnový návrh notifikačnej správy tohto typu sme vytvorili metó-dou drátového modelu, tzv. wireframe. Wireframe definuje rozvrhnutie prvkov nabudúcej stránke. Rozhodne sa nejedná o grafický návrh, preto neobsahuje žiadneobrázky, farby alebo textúry. Tvoria ho výlučne jednoduché čiary a text (Wirefra-ming). Ukážku drátového modelu môžeme vidieť na obrázku 3.

Obrázok 3: Drátový model správy informujúcej o úspešnej registrácií

3.3.2 Žiadosť o obnovu zabudnutého hesla

Ďalšou udalosťou, ktorú plánujeme naším modulom sledovať je žiadosť používateľao obnovu zabudnutého hesla. Vzhľadom na fakt, že manipulujeme s citlivými údajmipoužívateľov a taktiež vzhľadom na to, že proces obnovy hesla je potenciálnymmiestom pre DoS7 útok, je algoritmus rozdelený na dve fázy:

1. autentifikácia používateľa,

2. autorizácia žiadosti.

Vo fázy autentifikácie overíme totožnosť používateľa zadaním e-mailu, ktorýuviedol pri registrácii. Ak by útočník chcel prelomiť konto k našej aplikácii, muselby poznať aj heslo k mailovej schránke používateľa. Po overení e-mailovej adresyv databázi, aplikácia odošle na túto adresu správu o zaznamenaní novej žiadosti

7Denial of Service - útok, ktorého cieľom je znefunkčniť alebo zneprístupniť danú službu


a informáciami, ako postupovať v prípade, že používateľ žiadosť neaplikoval a nevieo čo sa jedná. Naopak v prípade, kedy žiadosť sám inicioval klikne na priloženýodkaz, čím potvrdí svoju totožnosť a spustí druhú fázu obnovy.

Pre návrh tejto správy sme opäť vypracovali drátový model, ktorý ilustrujeobrázok 4.

Obrázok 4: Drátový model žiadosti o obnovu hesla

3.3.3 Autorizácia žiadosti o obnovu hesla

V záverečnej fázy procesu obnovy hesla je autentifikovanému používateľovi vygene-rované nové heslo k jeho účtu. Heslo a prihlasovacie meno sú vložené do správya odoslané používateľovi. Ten sa môže okamžite prihlásiť a pracovať v normálnomrežime. Pôvodná žiadosť je ďalej systémom označená ako neaktívna.

Pre návrh tejto správy sme vypracovali drátový model, ktorý ilustruje obrázok5. Z povahy správy vyplýva, že sa bude mať veľmi podobný obsah správe o registráciia bude tak možné použiť rovnakú štruktúru dokumentu.

3.3 Typy zasielaných správ 25

Obrázok 5: Drátový model žiadosti o obnovu hesla

3.3.4 Sumárny prehľad neprečítaných správ

Jedným zo základných princípov aplikácie je iniciovať komunikáciu medzi zákaz-níkom a dodávateľom. Tá sa uskutočňuje prostredníctvom zabudovaného systémuvýmeny správ. Možné je zasielať nielen text, ale aj multimediálny obsah, či geo-lokalizačné dáta.

Systém sleduje aktivitu používateľov a vedie internú evidenciu správ, ktoré po-užívateľ prečítal (tzn. otvoril). Požadujeme teda funkcionalitu, ktorá pre každéhopoužívateľa vytvorí prehľad doposiaľ neprečítaných správ za zvolené obdobie. Pre-hľad bude vo vybranom čase zaslaný na e-mailovú adresu, čím daného používateľasystém upozorní na nové správy a v prehľadnej forme mu ich prezentuje.

Je zrejmé, že tento typ notifikácie bude implementačne náročnejší než pred-chádzajúce. Budeme pracovať s databázou a vyberať dáta rôznych entít. Taktiežvnútorná štruktúra zasielaného HTML dokumentu sa zmení a môže sa líšiť pri kaž-dom používateľovi – počet neprečítaných správ je u každého individuálnou záleži-tosťou. Preto nemôžeme vytvoriť pevnú šablónu dokumentu použiteľnú vo všetkýchprípadoch.

Drátový model na obrázku 6 ilustruje budúcu štruktúru dokumentu používa-teľa, ktorý obdržal 3 nové správy. Položku „Subject“ tvorí text pôvodného do-pytu8, s ktorým bol používateľ oslovený, resp. niekoho oslovil. Môže sa jednať

8v aplikácii označujeme poptávka


napr. o reťazec „Hľadám účtovníka v Brne“. Zobrazujme vždy najnovšiu správuv každej komunikácii, do ktorej je používateľ zapojený.

Obrázok 6: Drátový model prehľadu nových správ

3.4 Používateľské nastavenia notifikáciíNotifikačné správy o registrácii, či v procese obnovy hesla sú jednorázové a priamoich zaslanie riadi činnosť používateľa. Sumárne prehľady generuje aplikácia a zasie-la ich hromadne používateľom periodicky v určitom čase. K tomu sa viaže jednaz ďalších požiadaviek – možnosť výberu a frekvencie zasielania notifikácii o novýchsprávach. Budeme preto implementovať nasledujúce možnosti, ktoré si každý pou-žívateľ môže zvoliť:

• Jedenkrát denne – v pevne stanovenom čase, ktorý nemožno meniť (22:00),

• Dvakrát denne – v pevne stanovených časoch, ktorý nemožno meniť (12:00a 22:00),

• S novou správou – okamžitá notifikácia o každej novej správe,

3.4 Používateľské nastavenia notifikácií 27

• Nikdy – žiadna notifikácia,

• Vlastné nastavenia – špecifická možnosť, v ktorej si používateľ môže definovaťvlastný rozvrh zasielania upozornení. Používateľovi sa ponúka možnosť zvoliť sikonkrétnu hodinu pre každý deň v týždni, vypnúť upozornenia počas víkendovalebo dní, kedy sa danej činnosti nevenuje, prípadne sa uspokojí s prehľadomspráv raz za týždeň.

Z hľadiska implementácie budeme musieť pre každého používateľa evidovať jehonastavenia. Pre prvé štyri menované možnosti by postačil jednoduchý príznak, nopri vlastnom rozvrhu budeme musieť kontrolovať, či aktuálny kalendárny deň ko-rešponduje s nastavením používateľa. Taktiež sa zmení spôsob výberu dát. Premožnosti jeden a dvakrát denne vyberáme neprečítané správy za posledných 24resp. 12 hodín. Pri vlastnom nastavení, musíme zohľadniť časový rozdiel medzizaslaním posledného a súčasného upozornenia. Chceme sa vyvarovať situácii, ke-dy bude používateľ viac krát upozornený na rovnakú správu, prípadne nedostaneupozornenie vôbec.

Pre zabezpečenie periodického spustenia programu uskutočňujúceho výber a za-sielanie upozornení využijeme plánovač úloh Cron, ktorý je súčasťou operačnéhosystému bežiaceho na webovom serveri.

28 4 IMPLEMENTÁCIA RIEŠENIA

4 Implementácia riešeniaV kapitole 4 sa budeme venovať implementácii navrhovaného riešenia. Programuje-me princípom zhora – dolu, teda daný problém sa snažíme dekompozíciou rozdeliťna čo najmenšie, jednoduchšie implementovateľné časti. Každý naprogramovaný ce-lok podrobíme testovaniu – v prípade HTML dokumentov validácii kódu a objavenéchyby odstránime.

Pri programovaní skriptov v prostredí backendu uplatňujeme prístup testamiriadeného vývoja popísaného v podkapitole 2.3.

4.1 Implementácia grafických šablónVlastné praktické riešenie zadanej úlohy sme započali implementáciou grafickýchšablón, ktoré budu rozposielané používateľom. Vychádzali sme pri tom z jednotli-vých drátových modelov popísaných v podkapitole 3.3.

Pri implementácii sme dodržiavali štandardy HTML5 a CSS3. Použili smetabuľkové rozvrhnutie dokumentu, ktoré je síce považované za prekonané, avšake-mailovými klientmi je stále vyžadované a vlastne jediné všeobecne podporovanérozvrhnutie.

Dokumentácia gmail (Google Developers, 2016) síce uvádza, že pre korektnézobrazenie HTML dokumentu vyžaduje definíciu štýlov hlavičke, prípadne vo formeriadkového zápisu, my sme však zvolili iný prístup. Štýl sme definovali v exter-nom CSS súbore, ktorý je pre všetky dokumenty spoločný. Pri generovaní každéhodokumentu je do jeho hlavičky vložený obsah CSS súbora.

Princípom nášho riešenia je pri každom dokumente prečítanie nalinkovanéhoCSS súboru a jeho dynamický automatizovaný prevod do riadkového zápisu. Procesuprevodu do riadkového štýlu sa bližšie venujeme v podkapitole 4.5. Týmto riešenímzískame viacero výhod:

• nevzniká zbytočná duplicita kódu,

• štýly sú definované na jednom mieste,

• zmena vlastností sa naraz premietne vo všetkých dokumentoch,

• údržba aj jednoduchého dokumentu s riadkovými štýlmi je neúmerne zložitá.

Pre každú tabuľku a bunku tabuľky sme definovali šírku udanú v percentuál-nom vyjadrení a taktiež vlastnosť cellpadding a cellspacing, ktoré sú v novomštandarde CSS3 nahradené vlastnosťou padding. Padding však nie je podporova-nou vlastnosťou mailových klientov a preto sme ju nemohli definovať. Ďalej prekaždú bunku definujeme farbu pozadia, orientáciu textu a prípadne priradíme CSStriedu, resp. identifikátor.

Príklad implementácie časti kódu tabuľkového rozloženia:

<table width='100%' border='0' cellspacing='0' cellpadding='0'>

4.1 Implementácia grafických šablón 29

<tr><td bgcolor='#ffffff' align='center' class='messages--wrapper'>

Do definície štýlov sme zahrnuli dotaz na médium, ktoré uplatní špecifickévlastnosti pri zobrazení na zariadení s obrazovkou menšou než 600 px. V kombi-nácii s percentuálne zadanými veľkostnými jednotkami dosiahneme responzívnehozobrazovanie.

Ukážku hotových šablón môžeme vidieť na obrázku 17. Obrázok vľavo ilustrujedokument zobrazovaný na šírke obrazovky 1920 px. Vpravo je ten istý dokument,avšak na šírke 480 px. Obdobne sme vypracovali šablóny aj pre ďalšie typy správ.Ich ukážky zobrazujeme v prílohe A.

Obrázok 7: Ukážka hotových šablón pre správy odosielané pri registrácii


4.2 Algoritmus výberu dátPo návrhu a implementácii šablón dokumentov, ktoré budeme rozosielať, sa posú-vame k problému výberu dát, ktoré chceme v danej správe obsiahnuť. Správy budúgenerované dynamicky a každá je teda jedinečná. Dáta môžeme vo všeobecnostizískavať z dvoch zdrojov:

• zo vstupov používateľa,

• z databáze.

Pri správach, ktoré sú okamžitou rekciou na činnosť používateľa (registrácia,žiadosť o heslo...), získame dáta pomerne jednoducho, priamo z parametrov došléhopožiadavku. V prípade správ obsahujúcich historické dáta, musíme naformulovaťvhodný dotaz na databázu. Takým prípadom je aj e-mail obsahujúci prehľad ne-prečítaných správ v aplikácii. V nasledujúcej časti popíšeme proces získania týchtodát a ich spracovanie.

4.2.1 Neprečítané správy

Splnenie tohto požiadavku mierne komplikuje fakt, že potrebné dáta sú uloženévo viacerých tabuľkách databáze. Nezostáva tak nič iné, než tabuľky spojiť a vybraťsi potrebné hodnoty. V aplikácii využívame databázu Postgre 9.3. Na obrázku 8ďalej vidíme vývojový diagram algoritmu pre získanie textov neprečítaných správ.

V prvom kroku sa budeme zaujímať o používateľov, pre ktorých evidujemedoposiaľ neprečítané správy. Dotaz bude vyzerať nasledovne:

SELECT distinct u.email FROM zprava zLEFT OUTER JOIN zobraz_komunikace zk ON z.kdo = zk.kdoAND z.komu = zk.komu and z.id_poptavka = zk.id_poptavkaJOIN uzivatel u on z.komu = u.id_uzivatelWHERE (z.cas_vytvoreni > zk.cas_zobrazeni OR zk.cas_zobrazeni is null)

Získané e-mailové adresy používateľov, ktorí majú neprečítané správy uložímedo poľa. Následne pre každý prvok poľa, tzn. email, spustíme nový dotaz, v ktoromzisťujeme číslo - identifikátor dopytu9 v ktorej má používateľ s daným e-mailomnejakú neprečítanú správu. Dotaz je veľmi podobný predchádzajúcemu, s tým roz-dielom, že meníme projekciu na číslo dopytu a selekciu obmedzujeme na identifikačnéčíslo používateľa. ID používateľa získame pomocou funkcie aplikácie Moji lidi, ktorána základe daného e-mailu vráti id_uzivatel evidovaného v tabuľke uzivatel. Zo-skupením dopytov pomocou GROUP BY eliminujeme duplicitu v selekcii v prípade,ak používateľ v rámci jedného dopytu dostane viacero správ. Dotaz je zostavenýnasledovne:

9v aplikácii je dopyt označovaný ako „poptávka“

4.2 Algoritmus výberu dát 31

Obrázok 8: Vývojový diagram algoritmu pre získanie neprečítaných správ

SELECT z.id_poptavka FROM zprava zLEFT OUTER JOIN zobraz_komunikace zk ON z.kdo = zk.kdoAND z.komu = zk.komu and z.id_poptavka = zk.id_poptavkaJOIN uzivatel u on z.komu = u.id_uzivatelWHERE (z.cas_vytvoreni > zk.cas_zobrazeniOR zk.cas_zobrazeni is null)AND z.komu = ?GROUP BY z.id_poptavka

Opäť si získané vlákna uložíme do poľa a pre každý prvok spustíme poslednýdotaz, ktorým zisťujeme názov dopytu, teda text ktorý používateľ pôvodne zadaldo vyhľadávacieho poľa a samotný text správy. Uvedieme posledný dotaz, v kto-rom získame všetky správy v danom dopyte. Je možné, že rámci daného dopytuuž prebehla nejaká komunikácia a do výberu sa tak dostanú aj tie správy, ktoré užpoužívateľ prečítal. Nás bude zaujímať tá najaktúalnejšia, o ktorej vzhľadom k pred-


chádzajúcim krokom môžeme vyhlásiť, že je neprečítaná. Zoradíme si preto výberpríkazom ORDER BY podľa času vytvorenie zostupne a pre ďalšie spracovanie siuložíme prvý riadok tabuľky. Dotaz bude mať tvar:

SELECT text_poptavka, text_zpravaFROM zprava JOIN poptavka USING (id_poptavka)WHERE komu = ?AND id_poptavka = ?ORDER BY cas_vytvoreni DESC

Nie je potrebné zasielať úplný obsah správy, má sa jednať len o akýsi prehľad.Správa odoslaná v aplikácii môže obsahovať maximálne 2000 znakov (obmedzeniemôžeme svojím charakterom porovnať podnikovému pravidlám, s akými sa stretáva-me v oblasti informačných systémov). Ak by používateľ obdržal takto dlhú správua my ju odoslali v plnom rozsahu, dokument v e-maili by neúmerne narástol dodĺžky, stal sa neprehľadným a napríklad na mobilnom zariadení aj používateľskýnepohodlným (dlhé scrollovanie...). Preto každý text správy skrátime na adekvátnypočet znakov pomocou vstavanej funkcie jazyka Perl substr10.

Počet znakov, ktorý má správa v prehľade dosahovať, sme definovali v konfi-guračnom súbore Const.pm mimo aktuálne bežiaceho skriptu. Je to z dôvodu, abyju vývojár, alebo budúci správca aplikácie, mohol kedykoľvek zmeniť a nezasahovalpri tom do častí kódu, ktoré ovplyvňujú beh aplikácie.

Názov dopytu a text správy uložíme do poľa. Výslednou premennou ktorúmáme po celom procese k dispozícii je dvojdimenzionálne pole so štruktúrou, ktorúilustrujeme na obrázku 9.

Obrázok 9: Štruktúra poľa, v ktorom sú uložené dáta o neprečítaných správach

V závere tejto fázy máme zozbierané a spracované dáta uložené vo vhodnejdátovej štruktúre. Môžeme ich odovzdať ako parameter ďalšej metóde, ktorá sapostará o vloženie do požadovaného dokumentu.

4.3 Viacjazyčné prostredieV čase písania tejto práce vývojový tím Moji lidi začal pracovať na lokalizácii ap-likácie do ďalších jazykov (doteraz funguje len v češtine). Samozrejme viacjazyčnéprostredie sa dotýka aj zasielaných e-mailových správ. Je teda vhodné zamyslieť sa

10substr prevezme tri parametre: reťazec, začiatok a koniec časti, ktorá má zostať zachovaná

4.3 Viacjazyčné prostredie 33

a pripraviť systém generovania správ tak, aby bolo kedykoľvek možné jednoduchýma prehľadným spôsobom pridať novú jazykovú variantu.

Analýzou tohto problému sme dospeli k záveru, že texty, ktoré sú v správachinak nemenné (nadpisy, popisky, kontakty na podporu...) nie je vhodné udržiavaťnapevno v HTML šablóne. Elegantnejším a hlavne s výhľadom do budúcna udržia-vateľnejším riešením, je texty oddeliť od HTML dokumentu a ukladať ich v zvlášť,vo vhodnej a prehľadnej štruktúre.

Pre tento účel by svojou štruktúrou vyhovoval formát JSON11. Formát JSONje založený na štruktúre dvojíc kľúč – hodnota oddelených znakom : . Každá takátodvojica je označovaná ako objekt. Kľúč je unikátnym identifikátorom, hodnotoumôže byť reťazec, číslo, booleanovská hodnota, pole, alebo ďalší objekt. Objektymožno zanorovať. Komplikácie však nastávajú pri definovaní znakovej sady, preto-že reťazce v JSON sú kódované v Unicode (JSON) a prichádzame tak o možnosťdefinície vlastnej sady, v prípade potreby. Naviac, pri každom zápise by sme muselidbať na korektné prekódovanie nášho vstupu do Unicode. Za najväčšiu nevýho-du však považujeme potrebu udržiavať JSON v externom súbore mimo zdrojovýkód skriptu. Každé načítanie hodnôt by tak znamenalo nutné otvorenie súboru,jeho prečítanie, korektné zavretie, prípadne ďalšie operácie, ktoré zbytočne zaťažujehardware prostriedky serveru.

Ďalšou možnosťou je použiť štandardné dátové štruktúry jazyka Perl. Preuchovávanie hodnôt v pamäti slúžia tri hlavné dátové typy – skaláry (ukladá jed-nu hodnotu), zoznam skalárov (usporiadaná postupnosť skalárov – klasické pole)a asociatívne pole (neusporiadaná postupnosť skalárov, označované ako hash). Ničiné Perl štandardne neimplementuje, avšak existuje možnosť, ako vytvárať teoretic-ky ľubovolne zložité štruktúry prostredníctvom zanorovania základných dátovýchtypov (Dařena, 2005).

Pre každý typ správy pripravíme štruktúru, ktorá bude mať nasledovný tvar.K jednotlivým hodnotám pristupujeme postupnou dereferenciou. Kľúčmi budúskratka jazyka (cs, en, de...) a požadovaný text špecifický pre daný typ správy(nadpis, popis, sprievodný text...).

Vyskytujú sa tu aj texty, ktoré sú vo všetkých správach naprosto rovnaké.Jedná sa napríklad o záverečnú ďakovnú formulku („Ďakujeme že používate našuslužbu...“), kontakt pre podporu používateľov a podobne. Spoločné texty uložímedo samostatnej premennej. Vyvolajú sa teda vždy nezávisle na type požadovanejsprávy.

%typ_spravy1 => ( jazyk_1 => { text_1 => 'hodnota',text_2 => 'hodnota',text_n => 'hodnota'

}

jazyk_n => { text_1 => 'hodnota',11JavaScript Object Notation


text_2 => 'hodnota',text_n => 'hodnota'

})

Dátové štruktúry uložíme do vlastného perlovského balíka s názvom TextLang.Všetky texty nachádzajúce sa v správach budú tak udržiavané na jednom mieste, od-delené od HTML dokumentu. Prinesie to väčšiu prehľadnosť, jednoduchšiu údržbua hlavne veľmi efektívnu možnosť pridať novú jazykovú variantu prostým pridanímnového záznamu.

4.4 Generovanie dokumentuV tejto časti vývoja už máme pripravené šablóny dokumentov, máme implemento-vaný algoritmus výberu dát z databáze a taktiež máme pripravenú dátovú štruktúrupre rôzne jazykové varianty. Nasledujúcim krokom je spojiť tieto prvky dohromadya implementovať proces, ktorého výstupom bude HTML dokument naplnený textomv požadovanom jazyku ale najmä, správnymi dátami.

Celý proces generovania nového dokumentu sústredíme do vlastného balíkas názvom GenerateEmail. Bude obsahovať niekoľko metód, pričom hlavná z nich,get_html, bude volaná z iných častí aplikácie ako požiadavok na vygenerovaniepríslušného HTML dokumentu. Pri volaní metóda vyžaduje tieto parametre:

• -lang : požadovaná jazyková verzia. Možné hodnoty sa zhodujú so skratkamijazykov definovaných v balíku TextLang,

• -type : požadovaný typ dokumentu. V našom prípade sú možné hodnotyreťazce ’register’, ’reset_token’, ’reset’ a ’new_messages’,

• dáta, ktoré chceme zahrnúť do konkrétneho typu správy. Pri registrácii novéhopoužívateľa a pri obnove hesla posielame login a heslo -login, a -password,v prehľade nových správ -messages, pri autentifikácii žiadosti o nové heslo-token.

Podprogramy v Perli prijímajú zoznam parametrov prístupný cez špeciálnú pre-mennú @_. V našom prípade používame zaužívanú koncepciu tzv. pomenovanýchparametrov, kde ku každej hodnote priradíme jej kľúč. V tele metódy tak mámemožnosť pristupovať k jednotlivým parametrom prostredníctvom kľúčov, namiestočíselných indexov, ako by to bolo v prípade bežného odovzdania. Okrem pristupo-vania cez kľúče je nespornou výhodou ľubovoľné poradie, v akom parametre odo-vzdáme. Takisto nie je problémom volanie metódy s rôznym počtom parametrov.To nám výrazne uľahčuje implementáciu tela metódy get_html. Jej volanie môževyzerať nasledovne:

4.4 Generovanie dokumentu 35

get_html(-lang => 'cs',-type => 'register',-login => $login,-password => $password);

Pokračujme teraz k samotným dokumentom. Pri nahliadnutí do ich HTMLkódu si môžeme všimnúť, že niektoré časti sa zhodujú. V podstate môžeme každúšablónu „rozseknúť“ na tri časti – hlavičku, telo správy a pätičku. Hlavička a pä-tička sú identické naprieč všetkými šablónami – z prezentačného hľadiska obsahujúlogo aplikácie, ďakovnú formulku a kontakt na podporu používateľov. Schematickysituáciu znázorňujeme na obrázku 10.

Obrázok 10: Rozdelenie dokumentu na tri menšie celky

Jednotlivé šablóny sa líšia telom správy. Iný kód je potrebný pre šablónu preprehľad správ, iný pre registráciu používateľa atď.

Rozdelíme teda aj HTML kód a každú časť uložíme do separátnej premen-nej, kde každá z nich udržiava určitý logický celok. Jednoduchým spojením môžemenásledne získať požadovaný typ dokumentu. Po tomto kroku máme k dispozíciitieto premenné naplnené príslušnou časťou HTML kódu:


• $common: udržiava kód spoločný pre všetky dokumenty,

• $register_temp: registrácia a obnova hesla,

• $reset_token_temp: autentifikácia žiadosti o obnovu hesla,

• $new_messages_temp: registrácia a obnova hesla.

Pre dynamické vkladanie textov, ktoré sme si zadefinovali v balíku TextLangvšetky pôvodné texty v dokumente vymažeme a nahradíme ich príslušným volanímhodnoty zo štruktúry TextLang. Zápis môže vyzerať napríklad takto:

package Generate_email;use TextLang;

#Vkladanie nadpisov a sprievodneho textu podla typu spravyif ($params{-type} eq 'register') {

%text_type = %TextLang::register;}

my $common = qq [...<h1> $text_type{$params{-lang}}{header} </h1>...

];

Na základe prevzatého parametru -type uložíme do lokálneho hashu%text_type pomocou jednoduchej podmienky príslušné texty pre daný typ sprá-vy. Kľúčmi sú v tomto prípade odovzdaný parameter -lang pri volaní metódyget_html a požadovaný typ textu, v našom prípade nadpis nachádzajúci sa podkľúčom header. Týmto mechanizmom dynamicky vložíme do dokumentu akýkoľ-vek text definovaný v našom jazykovom balíku.

Na miesto v HTML kóde, kde by sa malo nachádzať telo správy – ta-buľka s príslušnými dátami a požadovaným formátovaním, vložíme lokálnu pre-mennú $message_body. Pri volaní metódy do nej obdobným spôsobom uložímeHTML kód príslušného typu správy, ktoré sme predtým definovali v premenných$register_temp, $new_messages_temp atď. Pre ilustráciu opäť uvedieme možnúukážku realizácie:

package Generate_email;

if ($params{-type} eq 'register') {$message_message = $register_tmp;

}my $common = qq [

...

4.5 Prevod CSS do riadkového zápisu 37

<td bgcolor=„#ffffff“ align=„justify“ class=„description“><p> $text_type{$params{-lang}}{description} </p>

</td></tr>

$message_body</tr>...

];

Vyššie popísaný algoritmus vygeneruje validný HTML dokument. Konkrétnepožiadavky na dokument upravujeme parametrami pre výber jazyka, typ správyatď. Vo výsledku teda máme elegantné volanie jedinej univerzálnej metódy, ktoránám vráti pripravený zdrojový HTML kód správy, ktorý už len odovzdáme príslušnejmetóde starajúcej sa o odoslanie e-mailu.

4.5 Prevod CSS do riadkového zápisuV tejto chvíli sme takmer pripravení pre odoslanie e-mailu. HTML dokument námpodľa parametrov pripraví metóda get_html popísaná v predchádzajúcej podkapi-tole. Pri návrhu dokumentov sme štýl definovali v externom súbore, hlavne z dôvodulepšej prehľadnosti a univerzálnosti (všetky dokumenty zdieľajú jeden štýl). Dopo-siaľ sme nijak neriešili pripojenie tohto štýlu ku generovanému dokumentu. Právetomu sa budeme venovať v tejto časti.

Aby sme sa vyhli zakladaniu a manipulácii s textovými súbormi a zvýšili efek-tivitu celého modulu založíme si nový balík, ktorý nazveme CssStyle, v ktorombudeme udržiavať štýl, prípadne štýly ak sa v budúcnosti rozhodneme pre ďalšiedizajnové varianty. Technicky sa sa jedná o podobný balík ako TextLang.

Nami vytvorený štýl uložíme do premennej $style, ktoru deklarujeme akoglobálnu pomocou funkcie our. Balík v podstate nevykonáva žiadne operácie, lenudržiava premenné, preto bude jeho definícia veľmi jednoduchá.

package CssStyle;use strict;

our $style = q{/* CLIENT-SPECIFIC STYLES */body, table, td, a {-webkit-text-size-adjust: 100%;

-ms-text-size-adjust: 100%;}table, td {mso-table-lspace: 0pt; mso-table-rspace: 0pt;}...}


Do dokumentu vložíme štýl rovnakým princípom ako obslužné texty.V Generate_email zavedieme náš nový balík CssStyle a do lokálnej premennej$stylesheet uložíme daný štýl:

package Generate_email;use CssStyle;my $stylesheet = $CssStyle::style;my $common = qq [

...<style type=„text/css“> $stylesheet </style>...

Po tejto úprave nám metóda vráti naštýlovaný dokument s CSS definovanýmv hlavičke. Teoreticky, máme k dispozícii plnohodnotný dokument pripravený preodoslanie. Avšak, ako sme popísali v podkapitole 2.2.3, najspoľahlivejší spôsob de-finície CSS v e-mailových klientoch je riadkový zápis. Mnohé klienty stále ignorujúhlavičku HTML, prípadne ju nahrádzajú vlastnou. Dochádza tak k rozpadu a neči-tateľnosti dokumentu. Funguje tak napríklad aj český seznam.cz.

Situáciu budeme riešiť automatizovaným prevodom z hlavičkového do riadkové-ho zápisu. Využijeme k tomu voľne dostupný modul CSS::Inliner zo siete CPAN12

Modul Inliner v sebe zahŕňa pre nás dve veľmi užitočné funkcionality:

• prevod hlavičkového zápisu do riadkového,

• prekódovanie znakov do znakovej sady Unicode pre korektné zobrazenie akých-koľvek národných znakov.

Z dokumentácie modulu (Kamel, 2003) možno vyčítať, že budeme využívaťtieto metódy

• new – vytvorí nový objekt triedy CSS::Inliner

• read – Prečíta a analyzuje HTML dáta. Rozdelí HTML kód a definíciu CSSv elemente <style> uloží do separátnych premenných. Metóda príjme para-metre ako hash, pričom hodnoty musia byť skalárneho typu.Napr. $inliner->read({html => $html})

• decode_characters – Implementuje dekódovací algoritmus pre HTML. V zá-sade aplikuje najlepšie spôsoby pre určenie kódovania v odovzdanom parametria jeho správneho prekódovania do zvolenej znakovej sady. Návratovou hodno-tou je prekódovaný vstup. Očakáva sa, že táto metóda bude volaná ešte predmetódou read. Parametrami je opäť hash s HTML kódom a požadovaná zna-ková sada pre prevod.Napr. $html = $inliner->read({content => $html, charset => 'utf8'})

12Dostupný na http://search.cpan.org/~kamelkev/CSS-Inliner-3901/lib/CSS/Inliner.pm

4.6 Odosielanie e-mailu 39

• inlinify – spracuje dáta vložené metódou read a vráti HTML kód s riadkovýmzápisom CSS ako skalárnu hodnotu. Element <style> je z hlavičky dokumentuodstránený.

V našom balíku Generate_Email zavedieme modul CSS::Inliner a vytvorímenovú metódu inline_css, ktorá ho bude využívať. Ako parameter prevezme vy-generovanú šablónu s vloženými hodnotami a definíciou štýlu v hlavičke. Vykonáprevod do riadkového zápisu a vráti skalárnu hodnotu. Telo metódy definujemenasledovne:

sub inline_css {...

my $inliner = new CSS::Inliner();eval {

# Prekodujeme na utf8$html = $inliner->decode_characters({

content => $html,charset => 'utf8'});

# Nacitame premennu obsahujucu html kod$inliner->read({html => $html, charset => 'utf8'});

# Vykoname prevod na inline CSS$inlined = $inliner->inlinify();

};...

S definovanou návratovou hodnotou poslednej metódy máme už skutočne pri-pravený HTML dokument, ktorý spĺňa špecifikáciu väčšiny e-mailových klientova webových aplikácii pre korektné zobrazenie. Výsledný HTML kód podrobímevalidácii a popíšeme v podkapitole 4.9. Ďalej postúpime k mechanizmu odoslaniae-mailu. Pôvodný štýl definovaný v hlavičke dokumentu zmažeme, resp. použítímregulárneho výrazu ho nahradíme dotazom na médium. Zachováme tak funkciuresponzívneho zobrazovania aspoň v tých e-mailových klientoch, ktorí neignorujúelementy <head> a <style>.

4.6 Odosielanie e-mailuDoposiaľ vynaložené úsilie by bolo zbytočné, ak by sme nedokázali umiestniť do-kument do e-mailovej schránky používateľa. K doručeniu pošty využijeme priamoslužieb operačného systému serveru, na ktorom beží aj aplikácia Moji lidi. Akosme už uviedli, aplikácia funguje pod linuxovou distribúciou CentOS 7. Štandard-ným balíkom CentOS je aj služba Sendmail, čo nie je nič iné ako Mail Transfer


Agent (MTA), využívajúci protokol SMTP. Jedná sa vlastne o najstarší MTA13 adnes už máme k dispozícii aj modernejšie alternatívy. No vďaka jeho rozšíriteľnosti(súčasť OS) a rokmi overenej spoľahlivosti bude stále dobre využiteľný aj pre na-še potreby. Konfigurácia e-mailovej služby nie je predmetom tejto práce, preto sajej nebudeme bližšie venovať. Službu považujeme za funkčnú a budeme ju priamovyužívať. E-mailové správy obsahujú okrem správy samotnej množstvo režijných in-formácií, dôležitých pre doručenie a správnu interpretáciu. V podkapitole 2.1.2 smepopísali, ako možno prenášať protokolom SMTP aj iné, ako len textové dáta. Presprávnu interpretáciu HTML dokumentu je nutné správne nastaviť tieto hlavičkye-mailovej správy podľa príslušnej normy RFC.

• MIME-Version – oznámi e-mailovému klientovi, že táto správa je formátovanápomocou MIME. Túto hlavičku definujeme iba raz, pre celú správu.

• Content-type – oznamuje klientovi, aký obsah sa nachádza v tele správy. V na-šom prípade budeme zasielať jednak HTML dokument, ale aj textovú alterna-tívu pre prípady, kedy nie je možné interpretovať HTML (napr. v klientochs výlučne textovým rozhraním).

• Charset – definujeme ho v kombinácii s Content-type. Niesie informáciu o zna-kovej sade textu v správe alebo jej časti.

• Content-Transfer-Encoding – informuje o kódovaní správy. V našom prípadeprenášame národné znaky českého (ale aj iných) jazyka. Na to nám prostýASCII text nepostačí. V prípade e-mailu máme vzhľadom na vyššie spomenu-té, vlastne len dve možnosti:

– base64 – prekóduje trojicu 8 bitových znakov na štvoricu 7 bitových. Vý-sledok je pre človeka naprosto nečitateľný, ale hodí sa pre prenos akéhokoľ-vek typu dát. Zápis sa však neumerne predlžuje. Napr. „Příliš žluťoučkýkůň“ bude zakódovaný akoUMWZw61sacWhIMW+bHXFpW91xI1rw70ga8WvxYg=

– quoted-printable – prevedie znaky s kódom vyšším než 127 na sek-venciu =xx, kde xx je kód znaku zapísaný v hexadecimálnej sústave.Opäť „Příliš žluťoučký kůň“ po zakódovaní: P=C5=99=C3=ADli=C5=A1=C5=BElu=C5=A5ou=C4=8Dk=C3=BD k=C5=AF=C5=88

Ako vidíme, dĺžka zakódovaného textu narastá úmerne s počtom národnýchznakov, pričom kódovanie pomocou quoted-printable rastie mierne rýchlejšie. V tex-te, ktorý kódujeme však prevládajú ASCII znaky, pretože väčšinu znakov tvorí zá-pis HTML, resp CSS. E-mailové správy preto budeme kódovať pomocou quoted-printable.

13pochádza z roku 1983

4.6 Odosielanie e-mailu 41

Hlavičky MIME teda nastavíme nasledovne:

• MIME-Version: 1.0

• Content-type: multipart/alternative pre celú správu

• Content-type: text/html pre časť správy obsahujúcu HTML kód

• Content-type: text/plain pre časť správy obsahujúcu alternatívu v prostomtexte

• charset: UTF8

• Content-Transfer-Encoding: quoted-printable

Aby sme sa vyhli možným problémom pri volaní systémovej služby sendmail,použijeme programový modul Email::Sender::Simple voľne dostupný zo sieteCPAN14. Email::Sender implementuje mechanizmus odosielanie pošty zo serve-ru. Nadstavba Email::Sender::Simple je jeho rozhraním pre jednoduché použitev perlovom skripte. Použitie modulu je pomerne jednoduché a už na prvý pohľadzrejmé:

my $email = Email::Simple->create(header => [To => '[email protected]',From => '„Podpora Moji lidi“ <[email protected]>',Subject => „Vítejte v systému Moji lidi!“,

],body => „Vítame Vás v systému a děkujeme...\n“,

);Email::Simple::sendmail($email);

V našom prípade však potrebujeme odosielať viac než len prostý text. Na-viac tento mechanizmus neumožňuje zmeniť MIME hlavičky a definovať alterna-tívne časti správy. Ako riešenie použijeme opäť voľne dostupný modul zo sieteCPAN – Email::MIME::CreateHTML15 pomocou ktorého vytvoríme štruktúru e-mailu a ten následne odošleme cez Email::Sender::Simple. CreateHTML naviacvýrazne uľahčí prácu so správnym nastavením MIME hlavičiek. Okrem toho, žepožadované hodnoty možno odovzdať ako parametre funkcie generujúcej štruktúrusprávy, niektoré hlavičky modul nastaví automaticky. Napr. v prípade, že odo-sielame výlučne HTML dokument modul nastaví Content-type: text/html. Akpriložíme aj verziu v prostom texte, modul sa automaticky postará o nastavenieContent-type: multipart/alternative. Taktiež umožňuje vkladať rôzne objek-

14http://search.cpan.org/~rjbs/Email-Sender-1.300031/lib/Email/Sender/Simple.pm15http://search.cpan.org/~vanstyn/Email-MIME-CreateHTML-1.041/lib/Email/

MIME/CreateHTML.pm


ty a samozrejme aj prílohy. Túto funkcionalitu síce momentálne nevyužijeme, avšakje vhodné mať túto možnosť pripravenú.

Špecifické kódovanie vyžaduje predmet správy. Zakódovanie pomocouquoted-printable, prípadne base64 nestačí. Je to z dôvodu, že predmet správy saprenáša spolu s režijnými dátami v časti, kde sú povolené znaky výlučne v znakovejsade US-ASCII. Zakódovaním jednou z vyššie spomenutých metód sa síce národnýchznakov zbavíme, ale zároveň ani neodovzdávame informáciu o použitej znakovej sa-de. E-mailový klient následne nedokáže správne rozkódovať a interpretovať národnéznaky. S odvolaním na stále platnú normu RFC 2047 (Moore, 1996) je potrebnékódovať vo formáte (bez uvedených medzier):

=? znaková sada ? kódovanie ? zakódovaný text ?=

Správne zakódovaný predmet správy má napríklad nasledovný tvar, kde znakB za druhým otáznikom odkazuje na kódovanie base64, prípadne Q na quoted-printable.

=?UTF-8?B?UmVnaXN0cmFjZSB2IHN5c3TDqW11IE1vamkgbGlkaQ==?=

Funkciu pre kódovanie hlavičiek podľa RFC 2047 máme k dispozícii v štan-dardnej výbave jazyka Perl v module Encode. S potrebným vybavením môžemepostúpiť k definícii metódy riadiacej odosielanie e-mailov. Definujeme teda novúmetódu, ktorá sa postará o odoslanie správy. Pre odovzdanie dát využijeme kon-cepciu pomenovaných parametrov.

Ešte pred odoslaním e-mailu sa zamyslime nad adresou používateľa. Štandard-ne odosielame správu na e-mail, ktorý zadal používateľ pri registrácii do systému a táje ďalej nezmeniteľná. Predpokladajme situácie, kedy používateľ mohol urobiť počasregistrácie preklep, poskytovateľ jeho e-mailovej služby zanikol alebo sa jednoduchorozhodol začať využívať e-mail s inou adresou. V týchto prípadoch mu nezostávanič iné než si zaregistrovať nový účet s aktuálnym e-mailom, čím príde o všetkypôvodné komunikácie a prípadné hodnotenia v aplikácii. Preto máme v databázik dispozícii tabuľku vlastnosti_uzivatele, ktorá združuje atribúty každého po-užívateľa. Tá obsahuje vlastnosť alt_email, do ktorej si každý používateľ môžeuložiť svoj sekundárny e-mail určený pre komunikáciu (prihlasuje sa ale stále pô-vodným e-mailom zadaným pri registrácii). Pred každým pripravovaným odoslanímsprávy budeme kontrolovať, či je hodnota vlastnosti alt_email prázdna. V prípadeže nie je, overíme ešte validitu a v prípade úspechu nastavíme sekundárny e-mailako adresáta správy.

sub send_html_mail {use Email::MIME::CreateHTML;...$params{-subject} = encode('MIME-Header', $params{-subject});$params{-plain} = encode('utf8', $params{-plain});

4.7 Používateľské nastavenie upozornení 43

my $email_body = Email::MIME->create_html(header => [

From => $params{-from},To => $params{-to},Subject => $params{-subject}

],body => $params{-html},body_attributes => {

encoding => 'quoted-printable'},

text_body => $params{-plain},text_body_attributes => {

encoding => 'quoted-printable',charset => 'UTF8'},

use Email::Sender::Simple qw(sendmail);sendmail($email_body);

V závere tejto podkapitoly máme funkčný mechanizmus odosielania formátova-ných HTML správ. Dokumenty majú správnu štruktúru a sú korektne interpretova-né mailovými klientmi, čo okrem iného umožnili správne nakonfigurované hlavičkyMIME. V tejto chvíli je možné náš modul z funkčného hľadiska pripravený pre na-sadenie do aplikácie Moji lidi.

4.7 Používateľské nastavenie upozorneníPosledným z formálnych požiadavkov na náš modul je možnosť nastavenia, v ktoromsi používateľ sám stanoví v akom čase chce prijímať e-mailové notifikácie s prehľadomneprečítaných správ. Pre splnenie požiadavku musíme jednak navrhnúť a implemen-tovať logiku v prostredí backendu, ale taktiež aj vhodné rozhranie na frontende prekomunikáciu s používateľom.

Pre nastavenie času a frekvencie ponúkame tieto možnosti:

• Jedenkrát denne – upozornenie každý deň v pevne stanovenom čase o 22:00.Do prehľadu správ sa dostávajú všetky doposiaľ neprečítané správy v aplikácii,ktoré používateľ obdržal v daný deň,

• Dvakrát denne – upozornenie každý deň o 12:00 a ešte raz o 22:00. Doprehľadu sa dostávajú správy obdržané v intervale od polnoci do dvanástejhodiny vrátane a v druhom e-maili od dvanástej hodiny do dvadsiatej druhejhodiny,

• S novou správou – okamžité upozornenie po obdržaní novej správy,

• Nikdy – nijak neupozorňovať,


• Vlastné – umožňuje definovať vlastný rozvrh dní a časov, v ktorých si použí-vateľ želá získavať upozornenia na neprečítané správy.

4.7.1 Webové rozhranie

Pre naše potreby vytvoríme jednoduchý formulár so selectom zobrazujúcim ponukoumožností. Formulár naštýlujeme do dizajnu zodpovedajúcemu dizajnu aplikácie.

Hodnoty vo formulári definujeme v separátnom číselníku v databázi. Pri načí-taní stránky najprv pošleme HTTP požiadavok typu GET na stiahnutie číselníku,až následne načítame formulár. Dosiahneme tým možnosť veľmi jednoduchej zmenyv prípade, že bude potrebné pridať, odobrať alebo inak upraviť ponúkané možnosti.Nie potrebné upravovať súčasný HTML kód, stačí vykonať zmenu v číselníku.

Odoslaním formuláru odovzdáme dáta serveru požiadavkom typu PUT, ktorýodovzdá informáciu o identifikácii používateľa16 a identifikačné číslo zvolenej mož-nosti.

Pri výbere možnosti „Vlastné“ okrem id možnosti odovzdáme aj zvolený časovýrozvrh vo formáte JSON, ktorý môže mať nasledovnú štruktúru:

[{„1“: [8, 15, 17, 22]},{„5“: [9, 16, 17, 1]}

]

kde prvá hodnota určuje deň v týždni (1 – pondelok, 7–nedeľa) a za ňou na-sleduje zoznam hodín, v ktorých si používateľ želá zasielať upozornenia. Nutnopodotknúť, že upozornenia zasielame vždy o celej hodine, preto neumožňujeme po-užívateľovi stanoviť si aj minúty. Na obrázku 11 ilustrujeme podobu webovéhorozhrania.

4.7.2 Spracovanie nastavení

Z hľadiska logiky začneme uchovávaním používateľských nastavení. Pre tieto účelyvytvoríme v databázi dve nové tabuľky.

Tabuľka frekvence_zprav slúži ako číselník hodnôt zasielaných na frontendpri načítaní formulára. Zároveň hodnotu id uchovávame ako nastavenie konkrét-neho používateľa, ktoré realizuje tabuľka vlastnosti_uzivatele. Naša tabuľka jetvorená dvoma stĺpcami:

• id_frekvence_sprav – identifikátor možnosti,

• popis – slovné označenie možnosti (S novou správou, Dvakrát denne...).16aplikácia využíva tzv. token – náhodne generovanú postupnosť znakov, ktorá jednoznačne

identifikuje autora požiadavku

4.7 Používateľské nastavenie upozornení 45

Obrázok 11: Formulár pre bližšiu špecifikáciu času zasielania upozornení

Ďalej vytvoríme tabuľku frekvence_rozesilani_sprav. Tá bude slúžiť úlo-žisko pri stanovení vlastného času zasielania správy. Tvoria ju, tentokrát, tri stĺpce:

• id_uzivatele – identifikátor používateľa,

• den – číselné vyjadrenia dňa v týždni,

• cas – číselné vyjadrenie celej hodiny konkrétneho dňa.

Pri spracovaní došlého požiadavku najprv zapíšeme dáta do tabuľkyvlastnosti_uzivatele. Tým je zaevidované základné nastavenie používateľa. Ná-sledne testujeme, či si používateľ nevybral možnosť Vlastné. V takom prípade prí-slušné dáta zapíšeme do tabuľky frekvence_rozesilani_sprav. Na obrázku 12zobrazujeme zjednodušený diagram tabuliek, ktoré využívame pre používateľské na-stavenia.


Obrázok 12: Schéma využívaných tabuliek

4.7.3 Automatické zasielanie upozornení

Vyžadujeme, aby systém zasielal upozornenia automaticky, bez akéhokoľvek zásahu„z vonku“. Z pohľadu implementácie nášho modulu, postačí proces získavania e-mailovej adresy používateľa, výberu neprečítaných správ, generovania dokumentua odoslania samotného e-mailu obaliť do jedinej metódy. Vytvoríme teda novúmetódu email_new_messages, v ktorej tele budeme postupne prevolávať jednotlivéprocesy.

Využijeme plánovač úloh Cron, v ktorom naplánujeme spustenie skriptu na kaž-dú hodinu a 1 minútu. Dôvody, prečo nie na každú celú hodinu popisujeme v pod-kapitole 2.1.4. Metóde odovzdáme parametre systémovým volaním date '+%u %H',ktoré nám vráti aktuálny deň v týždni vyjadrený číslom (Po – 0, Ne – 7) a celéčíslo aktuálnej hodiny. Odovzdávané parametre nám tak korešpondujú s vnútornoureprezentáciou času v našej metóde email_new_messages.

Parametre vo vnútri metódy rozparasujeme a využijeme pre kontrolou použí-vateľských nastavení. V prípade, že sa aktuálny čas zhoduje s nastaveniami použí-vateľa, ktorý má neprečítané správy, vykonáme vyššie popísané procesy a odošlememu e-mailovú notifikáciu. V opačnom prípade používateľa ignorujeme a pokračuje-me ďalším.

Týmto sme naplnili posledný z požiadavkov na náš modul. Odosielanie notifi-kačných emailov o neprečítaných správach je plne automatické a nevyžaduje okremsprávneho nastavenia, žiadnu ďalšiu aktivitu zo strany používateľa.

4.8 Výsledná architektúra a zavedenie moduluNáš modul splňuje všetky funkčné požiadavky a poslednou fázou implementácie jejeho zavedenie do aplikácie Moji lidi. Modul popisovaný v tejto práci rozdelímedo troch základných programových balíkov, ktoré uložíme do samostatných súborovs rovnakým názvom:

• Generate_email.pm – vykonáva generovanie HTML dokumentov,

4.8 Výsledná architektúra a zavedenie modulu 47

• CSSstyle.pm – udržiava CSS štýly použiteľné v HTML dokumentoch,

• TextLang.pm – udržiava texty v rôznych jazykových variantách.

Pre úplnú prehľadnosť, súbory umiestníme do nového adresára s názvomEmailFactory. Nie je to nutné, ale prispejeme tým k lepšej orientácii vývojárovv kóde aplikácie.

Aplikácia Moji lidi je v prostredí backendu rozdelená do viacerých modulov, kdesa každý stará o špecifické úlohy – registrácia a prihlasovanie používateľov, komu-nikácia, vyhľadávanie atď. V ľubovoľnom module, v ktorom budeme požadovaťfunkcionalitu e-mailu veľmi jednoduchým spôsobom zavedieme náš modul uvedenímuse EmailFactory::Generate_email. Potom môžeme kdekoľvek v kóde zavolaťnašu metódu, ktorá nám na základe odovzdaných parametrov vygeneruje HTMLdokument a ten následne odoslať na zadaný email. Príslušné dáta získame jednýmzo spôsobov popisovaných v podkapitole 4.2.


4.9 Validácia HTML a testovanieNakoľko sme uplatňovali prístup TDD, popísaný v podkapitole 2.3, funkčné testova-nie prebiehalo už počas vývoja, pričom sme sa neposunuli do ďalšej fázy skôr, než prí-slušné unit testy neskončili úspechom. V závere tak môžeme predpokladať, že všetkynaše programové jednotky fungujú správne a pravdepodobnosť uviaznutia, nedefi-novného stavu, či iného zlyhania je veľmi nízka.

Zostáva nám otestovať jednotlivé HTML dokumenty. Využijeme preto onlineslužbu konzorcia W3C Markup Validation Service17, ktorá odhalí syntaktické chyby,prípadne upozorní na zápis nevyhovujúci štandardu HTML, v ktorom je dokumentštruktúrovaný.

Pre testovanie spustíme náš skript generujúci dokument, s náhodne vloženýmidátami. Výstup presmerujeme do textového súboru a jeho obsah skopírujeme dovalidačnej služby W3C. Ako môžeme vidieť z obrázku 13, testovanie skončilo úspešnea dokument splňuje deklarovanú normu XHTML 1.0 Transitional.

Zobrazovanie e-mailu v skutočných klientoch a službách nedokážeme overiťžiadnym dostupným mechanizmom. Nezostáva nám nič iné, než vyskúšať tieto služ-by manuálne. V prílohe B nájdeme ukážky interpretácie našej správy vo vybranýchslužbách.

Obrázok 13: Ukážka validity HTML

17Dostupné na: https://validator.w3.org

5 DISKUSIA 49

5 DiskusiaWebových aplikácii dnes existuje skutočne nepreberné množstvo. Zameriavajú sa narôzne oblasti, majú rôzne zloženie návštevníkov, vzájomne sa líšia. No žiadna z nichsa nezaobíde bez komunikácie s používateľom, či už na vlastnej platforme alebovyužívajúc iné prostriedky. Najčastejšie sa stretávame práve s využitím e-mailu.Niektoré služby bez neho ani nemožno aktívne využívať. Používanie je podmienenéregistráciou, ktorá je zase podmienená platným existujúcim e-mailom. Príkladommôžeme uviesť profesnú sieť LinkedIn18. Súčasťou registrácie nového používateľaje overenie zadaného e-mailu a to zaslaním unikátneho kódu, ktorý je nutné zadaťdo aplikácie. Bez tohto kroku registrácia nie je platná a nemožno využívať službyaplikácie. Situáciu zachytáva obrázok 14.

Obrázok 14: Overenie e-mailu v službe LinkedIn

Moji lidi umožňuje vyhľadávanie dodávateľov aj bez nutnosti registrácie použí-vateľa. Vytvorenie účtu je potrebné až keď chce používateľ zahájiť komunikáciu a po-tenciálneho dodávateľa osloviť. Pochopiteľne, vlastný účet je požadovaný, ak chcepoužívateľ svoju službu ponúkať. Registrácia prebieha vyplnením jednoduchého for-mulára, následne je možné aplikáciu okamžite využívať. Nie je potrebné overovaťexistenciu e-mailu, aplikácia kontroluje len validitu zadanej adresy – synatax, vý-skyt nepovolených znakov a podobne. Po úspešnej registrácii je naším modulomna zadaný e-mail zaslaná správa obsahujúca prihlasovacie údaje. Na jednej stranetento prístup prináša väčšie pohodlie pre používateľa, na strane druhej so sebounesie väčšie riziko zneužitia e-mailovej adresy útočníkom, voči čomu sa skutočnývlastník adresy nemôže efektívne brániť.

Ďalšou funkcionalitou nášho modulu je automatické zasielanie prehľadu nepre-čítaných neprečítaných správ. Túto možnosť ponúka takmer každá aplikácia, nolíšia sa možnosťami nastavení. Často má používateľ na výber medzi „Upozorniť na

18https://www.linkedin.com/

50 5 DISKUSIA

novú správu“ a „Vypnúť upozornenia“. Tento prístup môžeme nájsť napr. v so-ciálnej sieti Facebook19. V Moji lidi sme vytvorili komplexné možnosti nastaveniafrekvencie rozposielania notifikačných správ (popisujeme v podkapitole 4.7). Porov-najme náš prístup opäť sieťou LinkedIn. LinkedIn ponúka podobný prehľad novýchspráv ako Moji lidi. Obmedzuje sa však len na možnosti „Doporučené“ (vyhodno-cované vnútorným algoritmom aplikácie), „Raz týždenne“ a „Jednotlivé e-maily“.V porovnaní s Moji lidi tu chýba možnosť denného prehľadu a stanovenie vlastnéhorozvrhu zasielania upozornení.

Zhodnoťme ešte proces obnovy zabudnuého hesla. V Moji lidi stačí zadať e-mail, s ktorým sa používateľ registroval. Na tento e-mail odošleme správu s odka-zom, ktorý je potrebné otvoriť v prehliadači. Tým spustíme skript, ktorý danémupoužívateľovi vygeneruje náhodné nové heslo a zašle mu ho na e-mail. Používateľ samôže prihlásiť s novým heslom a fungovať ďalej. Na rovnakom princípe funguje ajuž spomínaný LinkedIn. Zaujímavé riešenie prináša Google. Najprv sa snaží od po-užívateľa získať posledné heslo, na ktoré si spomína. V prípade neúspechu ponúkaoverenie cez alternatívny e-mail. Pokiaľ ani s tým nie je úspešný, prevedie použí-vateľa sériou bezpečnostných otázok, kde sa snaží overiť, že sa jedná o skutočnéhovlastníka účtu. V tomto ohľade je Google „priateľskejší“ než naša aplikácia. Mož-no však oponovať faktom, že Google má vďaka svojmu širokému portfóliu služiebo svojich používateľoch omnoho detailnejšie informácie a má tak viac možností akooveriť skutočnú identitu žiadateľa.

5.1 Známe nedostatky a návrhy zlepšeníV priebehu vývoja, testovania a v súčasnosti dokonca ani v priebehu ostrej prevádzkysme nenatrafili na žiadne závažné implementačné chyby. Pri správnom zavedenía používaní plní modul svoje funkcie spoľahlivo. Snažili sme sa pokryť všetky možnéchybové stavy, ktoré by počas vykonávania skriptu mohli nastať a adekvátne smeich ošetrili.

Pri nasadení do ostrej prevádzky sme sa stretli s problémom, kedy nami odo-sielané e-mailové správy boli niektorými službami vyhodnotené ako spam. Situáciasa však postupne zlepšuje a máme za to, že za vzniknutý problém môže nevhodnénastavenie SMTP serveru, prípadne chybné zaradenie domény mojilidi.cz na black-listy niektorých e-mailových služieb. Ak nebudú používatelia naše správy manuálneoznačovať ako spam, bude postupne dochádzať k uvoľneniu domény z týchto zozna-mov.

Určite by však stála za zlepšenie aktívna obrana proti zneužitiu e-mailovej ad-resy. Ak by k nemu došlo, bolo by vhodné implementovať možnosť zrušenia alebozablokovania účtu, napríklad kliknutím na jediný link v e-mailovej správe. V súčas-nom stave je jedinou možnou obranou kontaktovanie technickej podpory a manuálneriešenie vzniknutej situácie.

19https://www.facebook.com/

5.1 Známe nedostatky a návrhy zlepšení 51

Priestor na zlepšenie ponúkajú aj jednotlivé šablóny zasielaných HTML doku-mentov. Štruktúra HTML je zakotvená pomerne hlboko v kóde aplikácie a bežnýpoužívateľ – laik, do nej bude len s ťažkosťami zasahovať. Taktiež vytvorenie novejšablóny pre nový typ správy bude pre neho pravdepodobne nedosiahnuteľné. Mož-nou víziou do budúcnosti je vytvoriť „klikateľné“ rozhranie, v ktorom si aj úplnýlaik vytvorí vlastnú šablónu dokumentu, nastaví príslušné parametre odosielaniaa uloží. Systém by sa automaticky postaral o vygenerovanie HTML štruktúry, pre-kódovanie do adekvátnej znakovej sady a ostatné potrebné náležitosti. Vo výsledkuby tak napríklad neboli potrební vývojári, ak by sa marketingové oddelenie rozhodlozaslať používateľom aplikácie e-mail o novej kampani. Podobné služby už existujú,inšpirovať sa môžeme napríklad Mailchimp20.

20https://mailchimp.com/

52 6 ZÁVER

6 ZáverV závere tejto práce môžem konštatovať, že sa mi podarilo jednak splniť zadaniepráce v plnom rozsahu a taktiež aj funkčné požiadavky zadávateľa. Nebolo to všakvždy jednoduché a hľadaním riešení niektorých, na prvý pohľad triviálnych, prob-lémov som počas vývoja strávil dlhé hodiny. Po základnej analýze zadania, somsa pustil do prvotných príprav, ktoré zahŕňali najmä vyhľadávanie zdrojov informá-cií, ktoré by mohli byť užitočné pri mojej ďalšej práci. S prekvapením som zistil, ževýmena a fungovanie elektronických správ sa riadi stále platnými normami starý-mi aj niekoľko desaťročí. Taktiež vývoj podpory jazyka HTML a CSS zo stranye-mailových služieb sa akoby zastavil niekde na prelome nového tisícročia. Všetkytieto aspekty som musel pri ďalšom návrhu riešenia zohľadniť a nájsť spôsob, akovytvoriť modernú časť aplikácie s nutným využitím niektorých starších technológií.

V ďalších krokoch som sa zoznámil s aplikáciou Moji lidi a technológiami, kto-ré využíva. Zaujímalo ma najmä prostredie backendu kde aplikácia implementujelogiku v programovacom jazyku Perl. Okrem jazyka samotného, som sa zameriavalnajmä na pochopenie vzájomného prepojenia jednotlivých častí aplikácie, aby somdokázal efektívne využívať ich funkcie a taktiež, aby som mohol do nich začleniťsvoj budúci modul bez výrazných zásahov do už existujúceho kódu. Nahliadol somsa aj do databázy a zoznámil som sa s jej štruktúrou a usporiadaním dát.

Po získaní potrebných znalostí a zoznámením sa s architektúrou aplikácie somzapočal prácu na návrhu vlastného riešenia. Začal som dizajnovou časťou, tzn. ná-vrhom vizuálnej podoby dokumentov, ktoré majú byť v zasielané používateľom.Návrh spočíval vo vytvorení wireframu, ktorým som stanovil základnú kostru do-kumentu. Ten som následne využitím jazyka HTML previedol do reálnej podoby.Naštýlovaním pomocou CSS som dodal svieži vzhľad korešpondujúci s dizajnomaplikácie.

Ďalšia práca prebiehala takmer výlučne v backende. So znalosťou architektúryzvyšku aplikácie a databázy som navrhol možný algoritmus spracovania dát a ichautomatizovaného vloženia do formátovaného dokumentu. Pomáhal som si pri tomvývojovými diagramami, ktoré som následne implementoval s využitím jazyka Perl.Ešte predtým som však hľadal vhodnú metodiku, ktorá by mi nedovolila sa prílišodkloniť od stanovenej línie vývoja a zároveň by ma v každom kroku ubezpeči-la, že postupujem správne. Rozhodol som sa uplatňovať princípy testami riadenéhovývoja, vďaka ktorým som programové dielo vyvíjal efektívne s minimom „krokovspäť“.

Špecifickou fázou bolo hľadanie riešení, ktoré umožňujú automatizované odo-slanie e-mailovej správy zo serveru do schránky používateľa. Zásadným problémomnie je ani tak samotné odoslanie a doručenie, ako skôr správna interpretácia sprá-vy e-mailovým klientom či službou. Na scénu vstupuje neexistujúca jednotne re-špektovaná štandardizácia podpory HTML v e-mailových službách a tiež minimumdostupných literárnych zdrojov, v ktorých by som mohol nájsť relevantné informá-cie. Veľmi užitočnými sa stali pôvodné protokoly RFC. Aj napriek ich značnému

6 ZÁVER 53

veku, získané informácie sú stále aktuálne a pomohli mi napríklad vyriešiť problémyso správnym kódovaním znakov, alebo správnym nastavením hlavičiek e-mailovejsprávy.

Po splnení základných požiadavkov, kedy bol systém schopný sám, len na zá-klade činnosti používateľa automaticky vygenerovať a odoslať príslušnú správu somprešiel k ďalším, doplnkovým funkciám modulu. Jednou z nich bolo vytvoreniefunkčného rozhrania, v ktorom by si mohol používateľ sám definovať časový rozvrhzasielaných správ. Vrátil som sa opäť do prostredia frontendu, kde som vytvorilformulár ponúkajúci rôzne možnosti nastavení. V databázi som ďalej vytvoril no-vé tabuľky, ktoré boli potrebné pre správnu funkciu a definoval adekvátne príkazyjazyka SQL pre ich obsluhu. V závere vývoja som prepojil všetky súvisiace častilogikou implementovanou ako inak než v Perli.

Konečnou fázou bolo testovanie modulu z toho najdôležitejšieho hľadiska a sícez hľadiska konečného používateľa. Modul sa v súčasnosti nachádza v ostrej pre-vádzke a až na malé nepríjemnosti, vývojový tím aplikácie nezaznamenal zásadnénegatívne ohlasy od reálnych používateľov. Samozrejme, modul má stále dostatokpriestoru na vylepšovanie a rozširovanie, ktorý aj plánujem v budúcnosti využiť.

54 7 REFERENCIE

7 ReferencieAMBLER, Scott W. Introduction to Test Driven Development [online]. [cit.

3.5. 2017]. Dostupné z http://agiledata.org/essays/tdd.html.

BECK, Kent Test–driven development: by example Boston: Addison–Wesley,2003. ISBN 978-0321146533.

BORENSTEIN, N. FREED, N. MIME Mechanisms for Specifying andDescribing the Format of Internet Message Bodies [online]. [cit. 5. 5. 2017].Dostupné z https://tools.ietf.org/html/rfc1341

DAŘENA, František. Myslíme v jazyku PERL 1. vyd Praha: Grada, 2005.ISBN 80-247-1147-8.

EXPERIENCEUX, What is wireframing? [online]. [cit. 5. 5. 2017]. Dostupné zhttp://www.experienceux.co.uk/faqs/what-is-wireframing/.

FIELDING, R. HTTP/1.1: Method Definitions [online]. [cit. 5. 4. 2017].Dostupné z:https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html.

FREDRICH, Todd HTTP Methods for RESTful Services [online]. [cit. 3. 4.2017]. Dostupné z:http://www.restapitutorial.com/lessons/httpmethods.htm.

GASSTON, Peter Moderní web Brno: Computer Press, 2015. ISBN978-80-251-4345-2.

GOOGLE DEVELOPERS Gmail & Inbox Sender Resources [online]. [cit 26. 4.2017]. Dostupné z https://developers.google.com/gmail/design/css.

JANOVSKÝ, Dušan Design pomocí HTML tabulek [online].[2007], [cit 20. 4.2017]. ISSN 1801-0458 Dostupné zhttps://www.jakpsatweb.cz/tabulky--design.html.

JSON.ORG Úvod do JSON [online]. cit [30. 4. 2017]. Dostupné zhttp://www.json.org/json-cz.html.

KAMEL, Kevin CSS::Inliner – search.cpan.org [online]. [cit. 1. 5. 2017].Dostupné zhttp://search.cpan.org/~kamelkev/CSS-Inliner-3901/lib/CSS/Inliner.pm.

LUBBERS, Peter ALBERS, Brian SALIM, Frank HTML5: programujememoderní webové aplikace. 1. vyd. Brno: Computer Press, 2011. ISBN978-80-251-3539-6.

MOORE, K. MIME Message Header Extensions for Non-ASCII Text [online]. cit[5. 5. 2017]. Dostupné z https://www.ietf.org/rfc/rfc2047.txt

7 REFERENCIE 55

POSTEL, Jonathan, B. RFC 821 – Simple Mail Transfer Protocol [online]. [cit21. 4. 2017]. Dostupné z https://tools.ietf.org/html/rfc821.

SOBELL, Mark G. Mistrovství v Linuxu: příkazový řádek, shell, programováníBrno: Computer Press, 2007. ISBN 978-80-251-1726-2..

Prílohy

A ŠABLÓNY HTML DOKUMENTOV 57

A Šablóny HTML dokumentovV prvej časti príloh ilustrujeme jednotlivé typy HTML dokumentov tak, ako by ichzobrazil bežný webový prehliadač. Vľavo vidíme dokument na zobrazovacej plocheširšej ako 1024px, vpravo ten istý dokument zobrazený na šírke 480px.

A.1 Registrácia používateľa

Obrázok 15: Ukážka hotových šablón pre správy odosielané pri registrácii

58 A ŠABLÓNY HTML DOKUMENTOV

A.2 Žiadosť o obnovu hesla

Obrázok 16: Ukážka hotových šablón pre správy odosielané pri žiadosti o obnovu hesla

A.3 Obnova zabudnutého hesla 59

A.3 Obnova zabudnutého hesla

Obrázok 17: Ukážka šablóny pre obnovu zabudnutého hesla

60 A ŠABLÓNY HTML DOKUMENTOV

A.4 Prehľad neprečítaných správ

Obrázok 18: Ukážka šablóny pre prehľad neprečítaných správ

B UKÁŽKY INTERPRETÁCIE V NIEKTORÝCH E-MAILOVÝCH SLUŽBÁCH 61

B Ukážky interpretácie v niektorých e-mailových služ-bách

V tejto časti vezmeme jeden typ správy a pokúsime sa ho zobraziť vo vybranýche-mailových aplikáciach a lokálnych klientoch. Samozrejme, nedokážeme pokryťvšetky existujúce služby, vybrali sme tie, ktoré máme za najpoužívanejšie medzičeskými používateľmi.

B.1 GmailAko môžeme poznať z obrázku 19, známa služba Gmail nemá s interpretáciou nášhodokumentu žiaden problém. Poradila si aj národnými znakmi, ktoré boli prekódova-né do znakovej sady Unicode. Gmail v súčasnosti podporuje definíciu štýlov v hlavič-ke dokumentu, takže neignoruje dotaz na médium a teda responzívne zobrazovaniedokumentu je plne funkčné.

Obrázok 19: Dokument v službe Gmail

62 B UKÁŽKY INTERPRETÁCIE V NIEKTORÝCH E-MAILOVÝCH SLUŽBÁCH

B.2 post.czSo zobrazením HTML dokumentu v službe post.cz, v podstate takisto žiaden prob-lém nenastal. Narozdiel od Gmail však ignoruje hlavičku dokumentu a efekt res-ponzivity sa tak vytráca. Zatiaľ čo sa prostredie služby dynamicky prispôsobujeveľkosti okna, samotná správa zostáva statická. Používateľ je nútený dokumentomručne pohybovať, čo značne zhoršuje čitateľnosť. Bohužiaľ, tento aspekt nedokáže-me z našej strany nijak ovplyvniť. Riešenie je závislé len od ďalšieho vývoja službypost.cz.

Obrázok 20: Dokument v službe post.cz

B.3 Poštový klient Thunderbird 63

B.3 Poštový klient ThunderbirdPozrime sa teraz na lokálne desktop klienty. Jedným z nich je Mozilla Thunder-bird, ktorý sme napojili na schránku v službe gmail. Klient implementuje vlastnúlogiku interpretácie a je v tomto ohľade nezávislý od služby, na ktorú je napojený.Dokument korektne intepretuje v plnom, aj v responzívnom zobrazení. Okrem vyš-šie spomínaných služieb ponúka možnosť zobrazenia čistého textu namiesto HTML,teda alternatívy, ktorú sme definovali v časti MIME Content-type: text/plain. Ob-rázok 21 dokazuje, že aj táto časť našej práce funguje správne.

Obrázok 21: Alternatívna správa v Mozilla Thunderbird

64 B UKÁŽKY INTERPRETÁCIE V NIEKTORÝCH E-MAILOVÝCH SLUŽBÁCH

B.4 Mobilný klient Apple MailV závere vyhodnotíme mobilný e-mail klient Apple Mail. Nezaznamenali sme žiadenproblém s interpretáciou dokumentu, ktorý sa automaticky prispôsobí šírke obra-zovky. Taktiež sú plne funkčné klikateľné tlačítka a odkazy. Ukážku vidíme naobrázku 22.

Obrázok 22: Dokument v mobilnom Apple Mail

modul pro rozesílání zpráv uživatelům webové aplikace mojilidi file7 abstract valovič,...

Documents