spletna aplikacija za upravljanje urnikov izvajalcev ... · še 700 uporabnikih, ki bi potrebovali...

Diplomsko delo visokošolskega strokovnega študija Organizacija in management informacijskih sistemov

SPLETNA APLIKACIJA ZA UPRAVLJANJE URNIKOV IZVAJALCEV POMOČI NA DOMU

Mentor: doc. dr. Davorin Kofjač Kandidat: Andrej Miklavčič

Somentor: viš. pred. dr. Marko Urh

Kranj, september 2017

ZAHVALA Zahvaljujem se mentorju doc. dr. Davorinu Kofjaču in somentorju viš. pred. dr. Marku Urhu.

Hvala vsem zaposlenim iz podjetju Aleja soft za pomoč, spodbudo in nasvete pri izdelavi diplomskega dela.

Zahvalil bi se tudi družini, še posebej pa Špeli in Luni, za priganjanje in potrpljenje v ravno pravšnji meri.

POVZETEK Storitev pomoč na domu omogoča starejšim in invalidnim osebam, da dobijo potrebno oskrbo doma. V Sloveniji obstaja čez 70 organizacij, ki takšno pomoč izvajajo in jo nudijo skupno preko 10000 uporabnikom. Po pogovorih z zaposlenimi, zadolženimi za urnik v eni od organizacij, ki izvajajo pomoč na domu, smo analizirali obstoječ proces ustvarjanja urnikov in zbrali osnovne zahteve za spletno aplikacijo, ki bi proces olajšala in skrajšala. Nato smo se lotili razvoja enostranske spletne aplikacije, pri čemer smo uporabili moderna orodja in spletne tehnologije. Rezultat je delujoč prototip, ki nudi enostavno ustvarjanje in urejanje dnevnih in tedenskih urnikov z možnostjo vnašanja in kopiranja sprememb. Vsebuje pregleden prikaz, ki uporabniku omogoča vizualen pregled nad časovnimi dimenzijami posameznih vnosov in celosten pogled nad urnikom. Pri razvoju smo uporabili ogrodje Feathers.js za izdelavo strežniškega dela v Javascript okolju Node.js, za uporabniški vmesnik pa programsko knjižnico Vue.js.

KLJUČNE BESEDE:

• Javascript

• Spletna aplikacija

• Urnik

• Pomoč na domu

ABSTRACT Home care is a service that provides elderly and disabled individuals with neccessary care within their home environment. There are over 70 organizations providing more than 10000 individuals with home care in Slovenia. After interviewing the employees tasked with preparing schedules for their staff in one such organization, we analysed the existing process and collected basic requirements for a web application that would shorten and streamline said process. We then started developing single-page application using modern tooling and web technologies. The result is a working prototype that enables an easy to use method of creating and editing of daily and weekly schedule with options to input and copy changes. The solution provides users with a visual overview of individual entries and also shedule as a whole. During development of the prototype we utilised Feathers.js framework for the server-side component, written in Javascript within Node.js environment. Fort the user facing client side, we used the Vue.js library for developing web based user interfaces.

KEYWORDS:

• Javascript

• Web application

• Schedule

• Homecare

KAZALO

1. UVOD ............................................................................ 1

1.1. PREDSTAVITEV PROBLEMA ........................................................ 1

1.2. PREDSTAVITEV OKOLJA ............................................................ 2

1.3. NAMEN IN CILJI DIPLOMSKEGA DELA ............................................. 3

1.4. PREDPOSTAVKE IN OMEJITVE ..................................................... 3

1.5. METODE DELA ....................................................................... 3

2. PREDSTAVITEV UPORABLJENIH TEHNOLOGIJ .............................. 4

2.1. SPLETNE APLIKACIJE ............................................................... 4

2.2. JAVASCRIPT ......................................................................... 6

2.3. VUE.JS ............................................................................... 9

2.4 MOMENT.JS ......................................................................... 15

2.5 NODE.JS ............................................................................ 16

2.6 FEATHERS.JS ....................................................................... 18

3. IZHODIŠČNO STANJE ........................................................ 21

3.1. POSNETEK STANJA ................................................................ 21

3.2. SWOT ANALIZA OBSTOJEČEGA STANJA ......................................... 24

4. RAZVOJ APLIKACIJE ......................................................... 25

4.1. ZAHTEVE APLIKACIJE ............................................................. 25

4.2. STRUKTURA PROJEKTA ........................................................... 25

4.3. STREŽNIŠKA IMPLEMENTACIJA ................................................... 27

4.4. IMPLEMENTACIJA NA STRANI ODJEMALCA ..................................... 28

5. ZAKLJUČEK ................................................................... 37

5.1. OCENA UČINKOV ................................................................... 37

5.2. POGOJI ZA UVEDBO ............................................................... 37

5.3. MOŽNOSTI NADALJNjEGA RAZVOJA ............................................. 37

LITERATURA IN VIRI ................................................................. 39

KAZALO SLIK ............................................................................... 41

POJMOVNIK ................................................................................. 41

KRATICE IN AKRONIMI ..................................................................... 41

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Andrej Miklavčič: Spletna aplikacija za upravljanje urnikov izvajalcev pomoči na domu stran 1

1. UVOD 1.1. PREDSTAVITEV PROBLEMA V diplomski nalogi smo se lotili reševanja problema izdelave urnikov za izvajanje programa pomoči na domu. V praksi smo ugotovili, da je v organizacijah, ki izvajajo pomoč na domu, izdelava tedenskih urnikov in njihovo dnevno prilagajanje eden izmed šibkejših členov znotraj njihovega delovanja.

Za njihovo pripravo so običajno zadolženi vodje ali koordinatorji, ki pogosto podedujejo način izdelave urnikov od svojih predhodnikov. Uporabljajo orodja, ki niso posebej ustvarjena in prirejena za ta namen, največkrat Microsoft Word in Excel, v večjih organizacijah pa priprava urnikov koordinatorju lahko vzame tudi do dva ali tri delovne dni v tednu.

Skladnost tedenskega urnika z mesečnim planom dela zaposlenih in željami strank zagotavljajo z ročnim pregledovanjem in popravljanjem urnika iz prejšnjega tedna. Postopek je zamuden in nima posebnih varoval, na katera bi se ustvarjalec urnika lahko zanesel. Obstaja nevarnost izgube izvorne datoteke, ki predstavlja osnovo za vse urnike.

Popolna avtomatizacija izdelave urnikov niti ni zaželena, saj bi radi ohranili vnos strokovnega delavca, ki dobro pozna okolje in delovanje organizacije. V veliko pomoč pa bi bilo avtomatsko preverjanje ob vnosih, ki bi preprečilo večino možnih napak in tako precej zmanjšalo potrebo po večkratnem pregledovanju celotnih urnikov in hkrati skrajšalo čas njihove priprave.

Po podatkih iz analize stanja Inštituta Republike Slovenije za socialno varstvo skupno število uporabnikov pomoči na domu iz leta v leto raste, v letu 2015 je bilo tako skupno letno število uporabnikov 10.529, kar je 865 več kot v letu 2014 (IRSSV, 2016), kjer pa je bilo uporabnikov 239 več kot v letu 2013 (IRSSV, 2015). Prav tako po podatkih, zbranih v analizi stanja za leto 2015, izvajalci storitve poročajo o vsaj še 700 uporabnikih, ki bi potrebovali večji obseg pomoči, in vsaj 400 takšnih, ki iz različnih razlogov zanjo niso zaprosili, pa bi bili do nje upravičeni (IRSSV, 2016).

Glede na vztrajno rast števila uporabnikov storitve ocenjujemo, da bo potreba po primerni ureditvi urnikov za izvajanje pomoči na domu v prihodnosti postala vedno bolj vidna. S predvideno reorganizacijo centrov za socialno delo se bodo oddelki za pomoč na domu nekaterih centrov predvidoma združevali, kar pomeni, da bodo iz sedanjih manjših organizacij posledično nastale večje. V večjih organizacijah pa bo z dosedanjim načinom upravljanja z urniki težko slediti znatno večjemu številu uporabnikov in izvajalcev.



1.2. PREDSTAVITEV OKOLJA Pri razvoju spletne aplikacije smo sodelovali z eno izmed organizacij, ki izvaja storitve pomoči na domu in predstavlja enega izmed večjih predstavnikov tovrstnih organizacij v državi. Mesečno izvedejo tudi do 8800 obiskov pri strankah, v katerih opravijo približno 4000 ur storitev. Število izvajalcev, ki izvajajo storitev na terenu, se giblje med 40 in 50, njihovo delo pa nadzira in organizira 6 koordinatorjev in 1 vodja oddelka pomoči na domu. Število strank, ki jim nudijo pomoč na domu, se giblje okoli 550, potrebe po pomoči na domu pa vztrajno naraščajo. Oddelek za izvajanje pomoči na domu je v primeru obravnavane organizacije del doma za upokojence.

Pomoč na domu Pomoč na domu se v Sloveniji izvaja od začetka devetdesetih let. V začetku so jo organizirali in izvajali izključno centri za socialno delo, pred tem pa je bila organizirana zgolj pomoč v okviru zdravstvenih ustanov in patronažnih služb. Pomoč na domu je ena izmed treh vrst pomoči iz sklopa socialnovarstvenih storitev, opredeljenih z Zakonom o socialnem varstvu, in vsebuje socialno oskrbo na domu ter mobilno pomoč. Oddelek za pomoč na domu izvaja socialno oskrbo na domu, ki obsega gospodinjsko pomoč, pomoč pri temeljnih dnevnih opravilih in pomoč pri ohranjanju socialnih stikov, storitev pa je prilagojena potrebam posameznika. Najprej se ugotavlja upravičenost do storitve, pripravi in sklene se dogovor o obsegu, načinu opravljanja in trajanju storitve. Drugi del pa zajema vodenje storitve, organizacijo izvajalcev storitve in seveda samo izvajanje storitve na podlagi doseženega dogovora. (IRSSV, 2016)

“Namenjena je upravičencem, ki imajo zagotovljene bivalne in druge pogoje za življenje v svojem bivalnem okolju, če se zaradi starosti ali hude invalidnosti ne morejo oskrbovati in negovati sami, njihovi svojci pa take oskrbe in nege ne zmorejo ali zanju nimajo možnosti.” (Pomoč družini, 2017)

“Pomoč na domu lahko izvajajo domovi za starejše (javni socialnovarstveni zavodi), centri za socialno delo, posebni javni zavodi, ustanovljeni v občinah prav za ta namen, lahko pa tudi zasebni izvajalci na podlagi pridobljene koncesije ali dovoljenja za delo.” (Pomoč družini, 2017)

Podjetje Aleja soft Podjetje Aleja soft je manjše podjetje iz Kranja, ki se ukvarja z razvojem programske opreme. Glavna dejavnost je razvoj programske opreme na področju sociale s poudarkom na informacijskem sistemu za podporo izvajanju storitev pomoči na domu. Obstoječi paket programske opreme omogoča spremljanje obiskov in opravil oskrbovalcev s terena s pomočjo mobilne aplikacije in uporabo tehnologije NFC ter upravljanje z bazo upravičencev, oskrbovalcev in obiskov v spletni aplikaciji. Razvoj v podjetju je usmerjen v širitev tega programskega paketa z novimi moduli, med katere spada tudi urnik.



1.3. NAMEN IN CILJI DIPLOMSKEGA DELA Cilj naloge je izdelati delujoč prototip spletne aplikacije, v katero bo mogoče preko uporabniškega vmesnika vnesti urnik napovedanih obiskov, te urnike pa po potrebi prilagajati in pregledovati. Koordinatorji bodo urnike lahko vnašali, urejali in prilagajali. V pomoč jim bo vgrajeno preverjanje za najpogostejše napake. Aplikacija bo omogočala nazoren pregled nad vnesenimi urniki.

1.4. PREDPOSTAVKE IN OMEJITVE Prototip spletne aplikacije za urejanje in izdelavo urnikov za pomoč na domu je bila razvita z namenom kasnejše vključitve v že obstoječo spletno aplikacijo Oskrba.net podjetja Aleja soft, ki pokriva celotno delovanje pomoči na domu. Zato prototip ne vključuje avtentikacije in avtorizacije, ki je že del obstoječe rešitve, v katero bo urnik vključen.

Uporabljeni podatki so izmišljeni za namen prikaza delovanja, uporabljena podatkovna baza bo v končni rešitvi zamenjana. Za razvoj prototipa je bila izbrana baza, ki omogoča kar najlažji in najhitrejši zagon razvojnega okolja brez dodatnih nastavitev.

Prototip sicer vključuje osnovno strežniško implementacijo, vendar se močno osredotoča na razvoj uporabniškega vmesnika in implementacijo na strani odjemalca, saj gre za enostransko aplikacijo (ang. Single page application). V končnem produktu bo strežniško okolje drugačno, saj bo urnik kot modul vključen v že obstoječo spletno aplikacijo. Uporabniški vmesnik prototipa je bil grajen za uporabo na namiznih in prenosnih računalnikih, končni produkt pa bo prilagojen tudi za manjše, predvsem mobilne naprave.

1.5. METODE DELA Predstavljena spletna aplikacija je bila razvita na osnovi prototipnega modela. Ta metoda je primerna za razvoj aplikacij z visoko interaktivnostjo in omogoča prilagodljivost v razvoju. Zelo uporabna je še posebej pri razvoju uporabniških vmesnikov. Faze procesa prototipnega pristopa (Software prototyping, 2017): 1. Zbiranje osnovnih zahtev 2. Razvoj prototipa 3. Pregled prototipa 4. Prirejanje in izboljševanje prototipa

Tretja in četrta faza se ponavljata, dokler ne dobimo želenega rezultata. Osnovne zahteve smo zbrali na podlagi opazovanja procesa izdelave tedenskih urnikov v organizaciji in pogovorov z zaposlenimi, zadolženimi za njihovo pripravo. Prvi prototip je bil sestavljen iz večinoma statičnih HTML strani in je predstavljal predlogo za izdelavo interaktivnega prototipa v naslednjih iteracijah, ki je predstavljen v diplomskem delu.



2. PREDSTAVITEV UPORABLJENIH TEHNOLOGIJ V zadnjih nekaj letih se pojavlja vedno več Javascript ogrodij in knjižnic, ustvarjenih za pisanje uporabniških vmesnikov za spletne aplikacije, pojavlja pa se tudi tendenca k ustvarjanju enostranskih aplikacij s prej še neznanimi zmožnostmi. Pojavila se je arhitektura, osnovana na komponentah. Vedno več prej izključno namiznih aplikacij se seli na splet v obliki več ali enostranskih spletnih aplikacij. Izbrani programski jezik za implementacijo tako na strežniku kot v brskalniku je bil Javascript. V tem poglavju so predstavljene tehnologije in orodja, uporabljena pri razvoju prototipa.

2.1. SPLETNE APLIKACIJE Razlike med spletnimi stranmi in spletnimi aplikacijami niso jasno definirane. Vsaka spletna aplikacija je v osnovi še vedno tudi spletna stran, ni pa vsaka spletna stran tudi spletna aplikacija. Spletne strani, ki jih označujemo za spletne aplikacije, običajno vključujejo podobne funkcionalnosti kot namizni programi ali mobilne aplikacije. Kot takšne primere bi lahko šteli odjemalce spletne pošte, urejevalnike besedil in slik ter mnoge druge podobne spletne strani.

Dejstvo je, da so naprave in povezave med njimi v zadnjih letih postale tako zmogljive, da se marsikatera funkcionalnost, ki je bila prej mogoča samo v namiznih programih, seli v spletne brskalnike. Posledično vedno več podjetij namesto lokalno nameščenih programov ponuja spletne aplikacije kot Software as a service (SaaS).

Prednosti spletnih aplikacij (Web application, 2017):

• delujejo na različnih platformah neodvisno od operacijskega sistema na napravi uporabnika, potrebujejo le ustrezen spletni brskalnik in povezavo do svetovnega spleta;

• vsi uporabniki imajo dostop do iste različice aplikacije;

• vedno posodobljene − breme posodabljanja ni na uporabniku, temveč ponudniku spletne aplikacije. Posodobitve se izvajajo na strežniku in ne na vsakem računalniku posebej, kot je to potrebno za klasične aplikacije;

• niso nameščene na lokalnem disku, zato ne zavzemajo veliko prostora na uporabnikovi napravi;

• znižajo stroške tako za ponudnika kot uporabnika, saj potrebujejo manj podpore in vzdrževanja, prav tako pa lahko precej znižajo strojne zahteve za uporabnika.

Enostranske aplikacije

Enostranska aplikacija (ang. Single page application ali krajše SPA) je vrsta spletne strani oziroma spletne aplikacije, ki v celoti deluje v okvirih ene strani z namenom, da se kar najbolj približa uporabniški izkušnji namiznih programov (SPA, 2017). Pri enostranskih aplikacijah je vse potrebno za začetek delovanja aplikacije (HTML, CSS, Javascript) naloženo ob prvem nalaganju z edino stranjo (ang. “page”), ki je zgrajena na strežniku. Od tam naprej se deli nalagajo dinamično po potrebi, običajno na uporabnikovo zahtevo, vsa predstavnostna logika pa se izvaja na strani odjemalca, običajno spletnega brskalnika. Sama stran se ne osvežuje in prav tako uporabnik ne prehaja na druge strani, kot je to običajno za klasične spletne strani.

https://www.maxcdn.com/one/visual-glossary/web-application/



Po začetnem nalaganju se s strežnika pridobivajo in pošiljajo le podatki, kar je hitrejše kot pošiljanje HTML. S pomočjo HTML5 History API je poskrbljeno, da kljub temu uporabnik lahko navigira glede na ustrezne URL naslove, ki v primeru enostranskih aplikacij ponazarjajo stanje aplikacije.

Življenjski cikel enostranske aplikacije

Celotna aplikacija je naložena s strežnika, nato pa so deli strani zamenjani ali posodobljeni na zahtevo. Da bi se izognili prekomernemu prenašanju nepotrebnih funkcionalnosti aplikacije, se enostranske aplikacije pogosto poslužujejo progresivnega nalaganja teh, kadar so potrebne. Stanje v enostranski aplikaciji je lahko analog stranem tradicionalnih spletnih strani, navigacija med stanji pa analog navigaciji med stranmi. To pomeni, da je v teoriji možno tradicionalne spletne strani pretvoriti v enostransko aplikacijo. Pristop enostranskih aplikacij za spletne aplikacije je podoben predstavitveni tehniki Single document interface (SDI), ki je popularna v razvoju namiznih aplikacij. (SPA, 2017)

Prednosti enostranskih aplikacij (SPA, 2017):

• izboljšana uporabniška izkušnja: aplikacija je bolj odzivna kot klasične, večstranske aplikacije. Uporabniki niso deležni grobih prehodov med stranmi ob navigaciji;

• potrebnih je manj HTTP klicev, ker ni potrebno ponovno nalagati vseh potrebnih virov za vsako stran;

• jasna delitev nalog na strežniški in odjemalčev del − nove kliente za različne platforme lahko gradimo, brez da bi bistveno posegali v programsko kodo na strežniku. Prav tako lahko neodvisno spreminjamo program na obeh straneh, če dogovorjen programski vmesnik ostane enak;

• možnost procesiranja brez povezave − ko so prvotno potrebni viri enkrat pridobljeni s strežnika, lahko aplikacija v veliki meri deluje brez dodatnih zahtev na strežnik.

Slabosti enostranskih aplikacij (Yang Shun, 2017):

• večji obseg začetnih virov zaradi ogrodij, programske kode za celotno aplikacijo in drugih virov, saj je potrebno naložiti celotno aplikacijo na eni strani;

• potrebna je dodatna konfiguracija na strežniku, da se vse zahteve preusmerijo v eno vhodno točko, od koder naloge usmerjanja prevzame usmerjevalnik (ang. router) na strani odjemalca, ki prevzame vlogo preslikavanja pogledov iz URL naslovov;

• enostranske aplikacije se za svoje delovanje močno zanašajo na Javascript, ki poskrbi za prikazovanje vsebine. Uporabniki z onemogočenim izvajanjem Javascripta tako ne morejo dostopati do polne funkcionalnosti takšne aplikacije (to je tudi slabost spletnih aplikacij v splošnem, pri enostranskih aplikacijah pa je še bolj vidna). Posredno to oteži SEO, saj vsi spletni iskalniki ne izvršijo Javascripta ob obdelovanju strani. Mnogi večji spletni iskalniki že podpirajo SEO tovrstnih aplikacij. Glede na vrsto in cilje takšne aplikacije pa ta aspekt lahko je ali pa ni problematičen.



2.2. JAVASCRIPT Javascript je dinamičen, interpretiran skriptni programski jezik, ki podpira objektno naravnan, imperativni ali funkcionalni stil programiranja. Najbolj je poznan kot skriptni jezik za spletne strani, vendar deluje tudi v mnogih okoljih izven spletnih brskalnikov − Adobe Acrobat, Adobe Photoshop. Prav tako deluje tudi v strežniških okoljih, kot so Node.js in nekaterih NoSQL podatkovnih bazah, na primer Apache CouchDB, vgrajenih računalnikih ter mnogih drugih okoljih, obstajajo pa tudi orodja, ki omogočajo pisanje pravih mobilnih aplikacij z Javascriptom. (Javascript, 2017)

ES2015 (ES6) ECMAScript, s kratico ES, je uradni standard, ki tvori podlago za programski jezik Javascript. Poimenovan je po organizaciji ECMA International, pod okriljem katere deluje Tehnični komite številka 39 (TC39), ki je neposredno odgovoren za razvoj standarda. TC39 sledi procesu, ki je osnovan na fazah zrelosti posameznih značilnosti programskega jezika. Ko predlog doseže zadostno stopnjo zrelosti, komite spremembo vključi v specifikacijo standarda. Specifikacija se je s spremembami v poteku dela komiteja po izdaji ES2015 pomaknila bližje živemu standardu. (ECMAScript, 2017)

Razvoj standarda je zgodovinsko potekal v letnih izdajah (ang. editions), poimenovanih ES1, ES2, … Razmeroma pozno v razvoju šeste izdaje so se začeli pojavljati predlogi, da bi poimenovanje spremenili v prid letnih oznak, za šesto izdajo torej ES2015. V času pisanja diplomskega dela je bilo izdanih 7 izdaj specifikacije, v delu pa je osma (Izdaje ECMAScript, 2017). S pomočjo transpilacije (proces, v katerem avtomatsko pretvorimo novejšo programsko kodo v takšno, ki ustreza zgodnejšim specifikacijam in je zato podprta v širšem okolju) lahko razvijalci že danes uporabljajo najnovejše lastnosti jezika, tudi če te še niso vključene v vseh prevajalnikih.

Nekatere pridobitve ES2015, ki smo jih pogosto uporabljali pri razvoju prototipa (Kappert, 2015):

Deklaracija spremenljivk: let in const

Poleg besedice var lahko od ES2015 dalje spremenljivke deklariramo tudi z let in const. Obe omogočata deklaracije v obsegu blokov, ne le obkrožajoče funkcije (kot je to značilno za var), zato je glavna pridobitev okvir (scope) tako deklariranih vrednosti. S const ustvarimo referenco vrednosti samo za branje (read-only). (ES6, 2015)

Če poskušamo neposredno spremeniti vrednost, deklarirano s const, dobimo naslednjo napako (prikazana na sliki 1):



Kljub temu je še vedno mogoče spreminjati lastnosti objektov ali posameznih vrednosti v tabelah na tak način deklariranih spremenljivk.

“puščične” funkcije (arrow functions)

const foo = (a, b) => a * b // namesto

function foo(a, b) { return a * b }

Tak način pisanja funkcij je lahko še posebej uporaben ne samo zaradi svoje kratkosti in zgoščenosti, temveč tudi poskrbi, da je ključna beseda this v takšnih funkcijah vezana na leksični obseg funkcije in ni dinamična. Kadar takšno funkcijo pišemo kot enovrstično, vsebuje tudi implicitni return, kar še dodatno prispeva k jedrnatosti. (ES6, 2015)

Izboljšave znakovnih nizov (strings)

Template literal je sintaktični sladkorček (ang. syntactic sugar) (iSlovar, 2017), ki omogoča lažje in preglednejše ustvarjanje znakovnih nizov in njihovo interpolacijo. Takšen znakovni niz je začet in zaključen z levo črtico in lahko vključuje izraze, ki jih je mogoče interpolirati v znakovni niz v ${...}.

Poleg enostavne uporabe spremenljivk in izrazov v takšnih nizih je uporabna tudi možnost pisanja več vrstičnih nizov, nove vrstice pa se ohranijo v rezultatu. V ${}

lahko uporabimo kakršenkoli veljaven izraz, ne le imena spremenljivk. (Simpson, 2015)

let name = Andrej let greeting = `Hello, ${name}!` console.log(greeting) // "Hello, Andrej!" // prejšnji način, pred ES6

let name = Andrej let greeting = "Hello " + name + "!" console.log(greeting) // "Hello, Andrej!"

Slika 1: napaka sintakse ob poskusu spremembe vrednosti deklarirane s const (Lasten vir, 2017)



Tabele (arrays)

Objektu Array je bilo dodanih nekaj uporabnih statičnih metod, prav tako pa so bile

dodane nekatere metode samemu prototipu Array:

• Array.from ustvari tabelo iz tabelam podobnih struktur, na primer

argumentov funkcij, nodeList-a pridobljenega z

document.querySelectorAll() in novih podatkovnih struktur Map in Set;

• find metoda vrne prvi element v tabeli, za katerega povratni poziv vrne

vrednost true;

• findIndex vrne indeks prvega elementa v tabeli, za katerega povratni

poziv vrne vrednost true

(ES6, 2015)

Operator spread in rest

V bistvu gre za operatorja z isto sintakso (…). Rest operator uporabimo za

reprezentacijo nedoločenega števila argumentov funkcije v obliki tabele. Tako ni

potrebno vnaprej poznati števila vseh možnih argumentov, ki naj bi jih funkcija

lahko sprejela, ampak z rest operatorjem poskrbimo, da so dostopni tudi vsi ostali

(od tod poimenovanje rest) (ES6, 2015)

function f(a, ...arguments) { }

Destrukturiranje (destructuring)

Destrukturiranje je nova sintaktična lastnost jezika, omogoča pa prikladnejše

pridobivanje in pripisovanje podatkov iz objektov ali tabel in tako izključi potrebo

po marsikaterem vmesnem koraku. (ES6, 2015)

let [a, b] = ['one', 'two'] // a = 'one', b = 'two' // namesto es5 načina:

var arr = ['one', 'two'] var a = arr[0] var b = arr[1]

Promises

Promise je objekt, ki predstavlja eventualno izvedbo ali pa neuspeh asinhrone

operacije, ustvarimo jih lahko s posebnim konstruktorjem. Večinoma pa smo

uporabljali že ustvarjene obljube, ki jih vračajo funkcije. Tako lahko namesto

podajanja povratnih klicev funkcijam te verižimo z .then(). Rezultat je asinhron

klic funkcije, tak pristop pa ima kar nekaj prednosti, najbolj vidna od njih je

veriženje v asinhrone izvedbene korake, ki izniči potrebo po globoko ugnezdenih

povratnih klicih. (Using promises, 2017)



Primer uporabe takšnega pristopa v aplikaciji:

saveVisit () { this.updateVisit(this.selectedVisit) .then(() => {

this.loadVisitsList() }) .then(() => {

this.resetForm() }) }

2.3. VUE.JS Vue.js je odprtokodna Javascript knjižnica za razvoj uporabniških vmesnikov na spletu. Že od samega začetka je bila oblikovana tako, da se jo lahko uporabi postopno v manjših delih, prav tako pa je dovolj zmogljiva kot ogrodje za izgradnjo sofisticiranih enostranskih aplikacij ob uporabi modernih orodij in podpornih knjižnic.

Glavne značilnosti so (Vue, 2017):

• deklarativen izris (ang. rendering) s sistemom reaktivnosti, osnovanem na Javascript objektih;

• komponentno naravnan način razvoja s podporo za mnoga priljubljena razvojna orodja;

• vitko in razširljivo jedro;

• prilagodljiv sistem animiranih prehodov mode komponentami in pogledi;

• hitro delovanje brez dodatne kompleksne konfiguracije.

VIRTUALNI DOM Kot mnoge novodobne knjižnice in ogrodja za razvoj spletnih uporabniških vmesnikov Vue.js uporablja virtualni DOM. To pomeni, da namesto poseganja neposredno v DOM ustvarjamo njegovo abstraktno različico, nekakšno lažjo kopijo končnega DOM-a, ki se nato prevede v dejanski DOM, tako da se znova izrisujejo samo deli, ki so bili spremenjeni v virtualnem, in ne celotna struktura dokumenta. (Virtual DOM, 2017)

REAKTIVNOST Ena bolj prepoznavnih lastnosti Vue.js je nevsiljiv sistem reaktivnosti, vgrajen v knjižnico. Modeli so samo Javascript objekti in ko se objekt spremeni, se posledično posodobi pogled ali komponenta. Vue.js vključuje optimiziran sistem ponovnega izrisovanja tako posodobljenih delov strani. (Vue.js wiki, 2017)

KOMPONENTE



Komponente so ena izmed pomembnejših značilnosti Vue.js. Razvoj spletnih aplikacij si lahko bistveno olajšamo, če dele aplikacije razdelimo na samostojne komponente. Komponente v Vue.js so razširjeni osnovni HTML elementi. (Vue.js wiki, 2017)

PREDLOGE (ang. TEMPLATES) Vue.js za predloge uporablja sintakso, ki ima za osnovo HTML. Omogoča deklarativno vezavo podatkov instance vue z izrisanim objektnim modelom dokumenta. Vse Vue.js predloge so veljaven HTML in kot take jih lahko prevedejo brskalniki, ki so skladni s specifikacijami. V ozadju Vue kompilira predloge v izrisne funkcije virtualnega DOM-a. V kombinaciji z reaktivnostjo tako knjižnica sama poskrbi, da se ponovno izrisuje in posodablja kar najmanj komponent in posledično čim manj manipulira z objektnim modelom dokumenta, kadar se spremeni stanje aplikacije. (Vue templates, 2017) SINGLE FILE COMPONENTS - enodatotečne komponente Vue.js s pomočjo graditeljev (na primer Webpack) omogoča pisanje komponent v ločenih datotekah, ki jih nato sestavimo v aplikacijo. Takšne komponente imajo končnico .vue in vključujejo vse, kar posamezna komponenta potrebuje, kot je vidno na sliki 2. (Single file components, 2017)

Slika 2: komponenta v eni datoteki .vue (Vue, 2017)



VUE CLI Vue-cli je vmesnik za ukazno vrstico, ki na podlagi vnaprej pripravljenih predlog postavi ogrodje z vsemi potrebnimi razvojnimi orodji, da lahko kar najhitreje začnemo z razvojem dejanske aplikacije. Odvisno od izbrane predloge te nastavijo tudi veliko orodij, ki močno pomagajo pri razvoju in testiranju aplikacije. Na voljo je kar nekaj uradno predlaganih, prav tako pa lahko ustvarimo povsem svojim potrebam prilagojeno predlogo. Za naš prototip smo uporabili uradno podprto webpack predlogo (https://github.com/vuejs-templates/webpack). Izbrana predloga nam med drugim omogoča pisanje prototipa z uporabo komponent v posameznih datotekah s končnico .vue, ki jih na koncu skupaj z ostalimi deli Webpack zgradi v Javascript datoteko, ki jo znajo interpretirati brskalniki.

VUE-ROUTER Ena izmed začetnih pomanjkljivosti enostranskih aplikacij je bila, da ni bilo mogoče posredovati točnega URL naslova do trenutnega pogleda v njej, kot je to možno s tradicionalno spletno stranjo. To pa zato, ker je s strežnika poslana le ena stran, običajno index.html. V ta namen so se pojavili usmerjevalnik na strani odjemalca (ang. client-side routers ali front-end routers). Ti umetno spremenijo URL naslov glede na stanje aplikacije. Z uporabo usmerjevalnika na strani odjemalca se aplikacija lahko odzove na dogodke v brskalniku, kot so kliki na gumbe in povezave na strani ali osveževanje strani, in temu primerno spremeni URL naslov, ki ga je nato mogoče uporabiti za posredovanje točnega pogleda ali navigacijo do točno željenega pogleda ali stanja aplikacije (Vue.js wiki, 2017). Vue.js knjižnica sama ne vključuje takšnega usmerjevalnika, obstaja pa zato dodatna knjižnica Vue-router. Vue-router je uradna knjižnica za usmerjevanje na strani odjemalca in je integrirana z osnovno knjižnico Vue.js, tako da bistveno olajša razvoj enostranskih aplikacij. Priporočajo jo vzdrževalci glavne knjižnice v dokumentaciji. Nekatere izmed glavnih lastnosti so (Vue-router, 2017):

• preslikave ugnezdenih poti in pogledov;

• modularna konfiguracija na osnovi komponent;

• parametri, poizvedbe in nadomestni znaki (ang. wildcards) za poti;

• uporaba prehodnih efektov, ki jih omogoča sistem za prehode med pogledi knjižnice Vue.js;

• natančen nadzor nad navigacijo;

• avtomatski CSS razred za aktivne povezave;

• dva načina delovanja: HTML5 history ali hash;

• prilagodljivo obnašanje drsnikov. (Vue-router Github, 2017)

Vue-router objekt za enega izmed pogledov aplikacije (lasten vir, 2017):

import * as components from './components' export default [ {

path: '/clients',

https://github.com/vuejs-templates/webpack



name: 'Clients', component: components.Clients

}, { path: '/clients/:id/edit',

name: 'updateClient', component: components.CreateUpdateClient },

{ path: '/clients/create', name: 'createClient',

component: components.CreateUpdateClient } ]

Iniciacija usmerjevalnika za aplikacijo s konfiguracijo (lasten vir, 2017):

import Vue from 'vue' import Router from 'vue-router' import {routes} from '../components' Vue.use(Router) export default new Router({

mode: 'history', routes, linkActiveClass: 'is-active'

})

VUEX

Vuex je hkrati vzorec in knjižnica za upravljanjem s stanjem (ang. state) aplikacije. Služi kot centralizirana shramba (ang. store) za vse komponente v aplikaciji. Z vgrajenimi pravili zagotavlja, da je trajno spreminjanje stanja aplikacije predvidljivo. Diagram delovanja je prikazan na sliki 3.

Večje aplikacije običajno postanejo vedno kompleksnejše v času razvoja. Drobci stanja so tako sčasoma porazgubljeni med številnimi komponentami in interakcijami med temi. Vuex ponuja rešitev za ta problem v srednje velikih in večjih aplikacijah, za enostavnejše aplikacije pa običajno ni potreben. Običajno postane odločitev za enega od vzorcev oziroma knjižnic za upravljanje s stanjem aplikacije naraven naslednji korak, ko ugotovimo, da se redno spopadamo z mislijo, kako bi lahko bolje urejali stanje aplikacije izven samih komponent. (State management, 2017)

Z Vuex stanje, ki si ga komponente delijo, izločimo iz komponent in namesto tega uporabimo centralno shrambo. Tako za deljeno stanje niso več odgovorne komponente same. Deljeno stanje je tako dostopno na enem mestu, do njega pa lahko dostopamo povsod, kjer ga potrebujemo.



Primer definicije shrambe vuex z vsemi petimi objekti ():

import Vue from 'vue' import Vuex from 'vuex' Vue.use(Vuex) const store = new Vuex.Store({

state: { }, actions: { }, mutations: { },

getters: { }, modules: { } })

export default store

Slika 3: diagram delovanja vuex



STATE (stanje)

V tem objektu definiramo podatkovno strukturo aplikacije in nastavimo začetno stanje. Vuex uporablja enotno drevo stanja (ang. single state tree), kar pomeni, da en sam objekt vsebuje celotno stanje na ravni aplikacije in služi kot “enotni vir resnice” (ang. single source of truth). Takšen pristop poenostavi dostopanje do specifičnih delov stanja aplikacije. Primer začetnega stanja iz aplikacije Urnik:

state: { staff: [], clients: [],

visits: [], date: moment() }

ACTIONS (akcije)

Akcije so mesto, kjer definiramo funkcije, ki potrdijo spremembe stanja v shrambo. Pogost primer so klici API za pridobitev podatkov s strežnika. Akcije lahko vsebujejo poljubne asinhrone operacije. Akcije same ne spreminjajo stanja, ampak potrdijo izvajanje mutacij. Akcije v komponentah uporabimo s klicem this.$store.dispatch(‘xx’), ali pa z uporabo pomožne funkcije mapActions, ki

priredi metode komponente klicem z store.dispatch.

Primer akcije, ki vključuje asinhrono komunikacijo z API in potrdi več mutacij (Vuex, 2017):

actions: { checkout ({ commit, state }, products) { // shrani trenutno izbrane izdelke v košarici

const savedCartItems = [...state.cart.added] // pošlji zahtevo za checkout // izprazni košarico

commit(types.CHECKOUT_REQUEST) // API trgovine sprejme uspešen ali neuspešen povratni klic shop.buyProducts(

products, // obravnava uspešnega klica () => commit(types.CHECKOUT_SUCCESS),

// obravnava neuspeha () => commit(types.CHECKOUT_FAILURE, savedCartItems) )

} }



MUTATIONS (mutacije)

Potrditev mutacije je v Vuex edini način, da dejansko spremenimo stanje. Vuex mutacije so podobne dogodkom. Vsaka ima tip znakovnega niza in krmilnik (ang. handler). Funkcija krmilnika je mesto, kjer izvedemo modifikacije stanja, ki je prvi argument funkcije. Neposreden klic krmilnika mutacije ni mogoč, pristop je bolj podoben registraciji dogodkov v Javascriptu. Za poziv (ang. invocation) krmilnika je potrebno izvesti klic store.commit(‘mutation_type’) s tipom znakovnega niza

mutacije. Potrditev s koristno vsebino (commit with payload):

Poleg stanja lahko klicu store.commit() podamo še drugi argument, payload, ki

je običajno Javascript objekt.

Mutacije upoštevajo pravila reaktivnosti knjižnice Vue.js, kar pomeni, da se bodo ob spremembi stanja avtomatsko obnovile vse komponente, ki stanju sledijo. Pomeni pa tudi, da veljajo vsa opozorila, ki veljajo za splošno delo z Vue.js:

• priporočljivo je, da vsa polja za začetno stanje aplikacije nastavimo vnaprej;

• če želimo dodati nove lastnosti obstoječemu objektu, je priporočljivo uporabiti Vue.set(obj, ‘newProp’, 123), ali pa nadomestiti obstoječi

objekt z novim. Če uporabljamo transpilacijo, lahko za to uporabimo tudi novejšo sintakso object spread: state.obj = { ...state.obj, newProp: 123 }.

(Vuex, 2017) GETTERS

Včasih potrebujemo preračunane ali preurejene vrednosti, ki so izpeljane iz osnovnega stanja v shrambi (ang. store state). Če takšno strukturo potrebujemo v več kot eni komponenti, je smiselno, da jo definiramo v shrambi stanja (store). Tako definirani getters so izpostavljeni kot del objekta shrambe in dostopni vsem komponentam aplikacije. (Vuex, 2017)

MODULES (moduli)

Ko shramba postane prevelika in nepregledna zaradi naraščajoče kompleksnosti aplikacije, se lahko poslužimo vuex modulov. Vsak modul lahko vsebuje svoje lastno stanje, mutacije, getter-je, akcije in celo ugnezdene druge module. (Vuex, 2017)

2.4 MOMENT.JS Moment.js je Javascript knjižnica, ki olajša delo z datumi in časom in deluje tako v brskalniku kot na strežniku (Node.js). Moment.js razširi datumski objekt Javascripta, mu doda nove lastnosti in poskrbi za nekatere pomanjkljivosti, poskrbi pa predvsem za predvidljivost dela z njim in doda manjkajoče programske vmesnike, na primer za računanje s časom in datumi. Knjižnica ponuja širok nabor funkcionalnosti za prikazovanje, manipuliranje in razčlenjevanje datuma in časa. (moment.js, 2017)



2.5 NODE.JS Node.js je Javascript izvajalno okolje, ki omogoča izvrševanje Javascripta na strežniku in je zgrajen na osnovi V8 Javascript pogona. Deluje na mnogih platformah. Node uporablja asinhron, dogodkovno naravnan vhodno/izhodni (I/O) model brez zapore. Vključen je NPM, ki velja za največji ekosistem odprtokodnih knjižnic (paketov). S pomočjo Node.js lahko uporabljamo Javascript tako na strežniku, kot na strani odjemalca. (Node, 2017)

Node.js omogoča razvoj spletnih strežnikov in mrežnih orodij z uporabo Javascripta in zbirke modulov. V osnovni zbirki so na voljo moduli za vhod/izhod datotečnega sistema, mreženje, binarne podatke, kriptografske funkcije, podatkovni tok in druge jedrne funkcionalnosti. Moduli zmanjšajo kompleksnost pisanja strežniških programov z uporabo programskega vmesnika (API). Aplikacije Node so lahko poleg Javascripta napisane v kateremkoli jeziku, ki se prevede v Javascript (na primer Typescript, Coffeescript).

Za Node.js je bilo napisanih že na tisoče odprtokodnih knjižnic, večino katerih najdemo v registru NPM. Med njimi najdemo tudi mnogo ogrodij, ki poenostavijo in pospešijo razvoj aplikacij (Express.js, Socket.io, Koa.js, Feathers.js). (Node wiki, 2017)

Ker okolje Node.js deluje na najbolj razširjenih operacijskih sistemih brez pretirano obsežnih dodatnih nastavitev, to močno zniža začetno zahtevnost za razvoj aplikacij. Prav tako imajo vsa sodobna integrirana razvojna okolja in urejevalniki besedil, namenjenih za pisanje programske kode, vgrajene razhroščevalnike in podporo za pisanje Node aplikacij.

NPM/YARN NPM:

NPM (Node package manager) je upravljalec Javascript paketov in hkrati največji register programske kode. Vključen je z namestitvijo Node.js okolja in je bil prvotno razvit kot sistem za upravljanje paketov za Node, od koder izhaja tudi njegovo ime. NPM omogoča uporabo in distribucijo paketov, včasih poimenovanih tudi moduli (vendar se bomo temu izrazu raje izognili, ker je v obravnavi specifikacija za module v samem jeziku Javascript, ki niso ista stvar).

Paketi so delci Javascript kode, namenjene za ponovno uporabo. Paket je direktorij z eno ali več datotekami s programsko kodo in dodatno datoteko package.json z metapodatki o samem paketu, kot so verzija in odvisnosti. NPM trivializira uporabo in medsebojno deljenje takšnih paketov. Ena sama Javascript spletna aplikacija lahko uporablja (in je odvisna od) na desetine ali celo stotine paketov, ki tvorijo sestavne dele celote. Ko je aplikacija enkrat odvisna od paketov, NPM zanje nudi tudi enostavno posodabljanje. Običajno gre za majhne pakete, ki so ozko usmerjeni v reševanje specifičnega problema, vendar v registru najdemo tudi celotne knjižnice in ogrodja − tako za Node kot za brskalnike.

Pakete v registru lahko najdemo na spletni strani NPM, kjer ima vsak svojo stran, nameščamo in uporabljamo pa jih z odjemalcem v obliki orodja komandne vrstice. Uporabljamo lahko globalna Javascript orodja (uporabljamo jih na ravni računalnika) ali pa lokalna, ki so v uporabi samo v določenem projektu.



NPM je torej (najbolj razširjen) način za ponovno uporabo Javascript programske kode drugih razvijalcev in deljenje svoje z njimi, olajša pa tudi uporabo te programske kode in upravljanje z različnimi verzijami paketov. (Npm, 2017)

package.json datoteka za strežniški del aplikacije Urnik:

{ "name": "backend",

"description": "Backend for scheduler", "version": "0.0.0", "homepage": "",

"main": "src", "keywords": [ "feathers"

], "author": { "name": "Andrej",

"email": "[email protected]" }, "contributors": [],

"bugs": {}, "directories": { "lib": "src"

}, "engines": { "node": ">= 6.0.0",

"yarn": ">= 0.18.0" }, "scripts": {

"dev": "nodemon src/", "test": "npm run eslint && npm run mocha", "eslint": "eslint src/. test/. --config .eslintrc.json",

"start": "node src/", "mocha": "mocha test/ --recursive" },

"dependencies": { "body-parser": "^1.17.1", "compression": "^1.6.2",

"cors": "^2.8.3", "eslint": "^3.19.0", "feathers": "^2.1.1",

"feathers-configuration": "^0.4.1", "feathers-errors": "^2.7.1", "feathers-hooks": "^2.0.1",

"feathers-hooks-common": "^3.2.0", "feathers-nedb": "^2.6.2", "feathers-rest": "^1.7.2",

"feathers-socketio": "^1.6.0", "helmet": "^3.6.0", "mocha": "^3.3.0",

"nedb": "^1.8.0",



"request": "^2.81.0", "request-promise": "^4.2.0",

"serve-favicon": "^2.4.2", "winston": "^2.3.1" },

"devDependencies": { "nodemon": "^1.11.0" }

}

Yarn:

Je odprtokodna alternativa odjemalcu NPM, ki je nastala iz sodelovanja podjetij Facebook, Google, Exponent in Tilde. Kot register paketov je razvijalcem tudi ob uporabi Yarn na voljo celoten NPM ekosistem. Poleg tega, da nameščanje paketov poteka hitreje, je glavna prednost to, da se ob zagonu Yarn projekta ustvari datoteka yarn.lock, ki “zaklene” vse uporabljene odvisnosti. Prav tako pa se z namestitvenimi ukazi paketi vedno shranijo v datoteko package.json kot odvisnosti, brez dodatnih parametrov v ukazu za namestitev. To pomeni, da ko enkrat namestimo različice paketov, ki delujejo zadovoljivo, vsi ostanejo na točno določenih verzijah, ki so shranjene v yarn.lock datoteki. Za razliko od NPM odjemalca, Yarn to stori avtomatsko. Morebitno posodabljanje želenih paketov je tako vedno eksplicitno. Glavna pridobitev z uporabo odjemalca Yarn so torej boljše privzete nastavitve. (Severien, 2016)

2.6 FEATHERS.JS Feathers.js je odprtokodna realno − časovna in REST API plast za razvoj modernih aplikacij, v celoti napisana v Javascriptu (feathersjs.com). Bistveno pospeši razvoj programskih vmesnikov aplikacij in zmanjša količino potrebne kode za njihovo delovanje, ponuja pa tudi enostavno zamenljivost uporabljene baze podatkov. Hitrost razvoja in zamenljivost uporabljenih tehnologij naredi ogrodje Feathers.js za zelo primeren izbor za hiter razvoj prototipov. Ena izmed zelo prikladnih lastnosti ogrodja je, da lahko uporabimo natančno isto programsko kodo na strežniku in v brskalniku, kakor da bi aplikacija na strani odjemalca imela neposreden dostop do baze podatkov. (Feathers.js, 2017)

Je majhna in kompatibilna ovojnica okoli ogrodij Express in Socket.io, ki sta obe temeljito preizkušeni ogrodji, kateri uporabljajo številna podjetja v produkcijskem okolju. Zaradi univerzalnega programskega vmesnika je ogrodje možno uporabljati na strežniku, v brskalniku in celo za pisanje mobilnih aplikacij z Javascriptom (React Native), programska koda pa je lahko v veliki meri enaka v vseh treh primerih. Brez težav se integrira s katerimkoli ogrodjem na strani odjemalca, kot je v našem primeru Vue.js. Temelji na strukturi t. i. servisov (ang. services), preko katerih avtomatsko nudi vse CRUD funkcionalnosti, modelirane po REST arhitekturi, z uporabo REST API ali preko vtičnic (ang. sockets). Feathers.js ponuja celo množico adapterjev za mnoge popularne baze podatkov (v času pisanja diplomskega dela jih obstaja več kot dvajset), tako da je bazo relativno enostavno zamenjati za katerokoli drugo iz seznama podprtih. Ponuja tudi celo kopico dodatnih, neobveznih vtičnikov, ki razširijo funkcionalnost ogrodja. (Dokumentacija Feathers.js, 2017)



Strežnik Feathers lahko avtomatsko obravnava zahteve preko HTTP REST odjemalcev, Feathers REST odjemalcev ali Feathers WebSocket odjemalcev. Pozivi bazi podatkov so identični, ne glede na izbrano bazo podatkov in mesto, od koder je poziv sprožen (strežnik ali odjemalec).

Glavni konstrukti ogrodja so servisi in zanke (hooks). Oboje lahko uporabljamo tako na strežniku kot v brskalniku. (Dokumentacija Feathers.js, 2017)

SERVICES (servisi) Servisi so v samem osrčju ogrodja Feathers.js in služijo kot posredniki za interakcijo z odjemalci. Uporabimo jih lahko za kakršnekoli potrebne operacije: z bazo podatkov, mikroservisi in API-ji, datotečnim sistemom, elektronsko pošto, za procesiranje plačil ...

Servisna plast pomaga ločiti logiko aplikacije od načina dostopa in njene reprezentacije, olajša testiranje in omogoča ogrodju, da izpostavi enak API za komunikacijo tako preko HTTP kot preko spletnih vtičnic. Vsak servis izpostavi uniformni vmesnik, modeliran po REST arhitekturi, dejavnosti pa so tako kot pri REST očitne iz poimenovanja metod objekta servisa, podobno kot HTTP glagoli GET, POST, PUT, PATCH in DELETE. Tak pristop tudi omogoča, da se v izvajanje metod vključimo s hooks. Z uporabo dogodkov, ki ji vrne izvedba metod servisov, in hooks lahko v aplikaciji nudimo realno − časovno funkcionalnost.

const myService = { // GET /path find(params, callback) {},

// GET /path/<id> get(id, params, callback) {}, // POST /path

create(data, params, callback) {}, // PUT /path/<id> update(id, data, params, callback) {},

// PATCH /path/<id> patch(id, data, params, callback) {}, // DELETE /path/<id>

remove(id, params, callback) {} }

HOOKS Hooks so funkcije, ki se avtomatsko izvedejo pred ali po pozivu servisa, za katerega so definirane. Lahko igrajo vlogo vratarja in poskrbijo da so vse operacije res dovoljene in vključujejo vse potrebne informacije. Prav tako lahko z njimi zagotovimo, da so odjemalcu poslani samo podatki, ki so dovoljeni ali potrebni. Na voljo je vtičnik feathers-common-hooks, ki vključuje kopico splošno uporabnih takšnih funkcij. Obstajata dva tipa:

• before: za validacijo, prečiščevanje podatkov in preverjanje dovoljenj;

• after: za dodajanje ali odstranjevanje podatkov pred pošiljanjem odjemalcu.



Poljubno število enostavnih funkcij nato lahko verižimo v kompleksnejše procese in s tem ohranjamo modularnost in fleksibilnost aplikacije. Pisani so lahko na sinhron ali asinhron način, ne glede na to pa se naslednji izvede šele, ko je trenutni zaključen, kar zagotavlja, da so vedno izvedeni v sosledju. (Dokumentacija Feathers.js, 2017)

FEATHERS CLI Generator zaradi jedrnatosti samega ogrodja Feathers.js proizvede zelo malo programske kode, ki se ne razlikuje bistveno od kode, ki bi jo napisali sami. Generator strukturira aplikacijo z modularnim pristopom, prav tako pa poskrbi za specifike povezave z izbrano bazo podatkov.

Generatorje namestimo z ukazom:

npm install -g feathers-cli

Po namestitvi so nam v ukazni vrstici na voljo ukazi feathers:

• feathers generate app: v izbrani mapi ustvari vse potrebne datoteke,

strukturo aplikacije in nastavitve;

• feathers generate authentication: doda modul za avtentikacijo in

servis users za uporabo z avtentikacijo;

• feathers generate service: skozi vmesnik ukazne vrstice ponudi

nastavitve za ustvarjanje osnove za nov servis;

• feathers generate hook: skozi vmesnik ukazne vrstice ponudi nastavitve

za ustvarjanje novega hook, vezanega na določen servis, ali na ravni celotne aplikacije (za vse servise). Tako ustvarjen hook je še prazen, nastavljeni pa so vsi potrebni moduli in povezave.

WEBSOCKETS/SOCKET.io Za razliko od tipične komunikacije med strežnikom in odjemalcem s HTTP je pri spletnih vtičnicah vzpostavljena interaktivna seja med njima, tako da vsak od njiju lahko kadarkoli začne pošiljati podatke. Z websocket API lahko strežniku pošiljamo sporočila in prejemamo od dogodkov odvisne dogovore, ne da bi potrebovali dodaten poziv strežniku. (Web sockets, 2017)

Socket.io je prenosni protokol na osnovi tehnologije spletnih vtičnic za okolje Node. Omogoča dvosmerno komunikacijo na osnovi dogodkov v realnem času.(Socket.io, 2017)

NEDB NeDB je podatkovna baza za Node.js, Electron in spletne brskalnike, napisana v celoti Javascript. Podobna je priljubljeni MongoDB, vendar ne potrebuje instalacije ali dodatne konfiguracije, zato je izjemno prikladna za izdelavo prototipne rešitve, saj se nam ni bilo potrebno ukvarjati z nastavljanjem baze podatkov. API je subset programskega vmesnika MongoDB.(NeDB, 2017)



3. IZHODIŠČNO STANJE 3.1. POSNETEK STANJA Tedenski postopek izdelave urnikov za prihajajoči termin se začne v torek ali sredo, dokončani urniki pa morajo biti v rokah oskrbovalcev do petka. Izhodiščno stanje predstavlja Word datoteka Osnovni urniki za teden xx.xx. 20XX − ta služi kot shramba trajnih sprememb in popravkov ter osnova za izdelavo urnika. Datoteko se spreminja samo po potrebi, za izdelavo tedenskega urnika se prej naredi kopija. Večje, za teden specifične spremembe glede oskrbovalcev in uporabnikov se vnaša le v kopijo.

Proces priprave tedenskega urnika se začne s predlogo urnika, ki jo kopirajo vsak teden. Priložene so posebnosti, zahteve in prepovedi za oskrbovalce ter seznam neizpolnjenih potreb uporabnikov, ki čakajo na sprostitev termina. Neizpolnjene potrebe se obravnava po principu FIFO (first in - first out).

Urniki so narejeni za posameznega oskrbovalca, primer je prikazan na sliki 4. Po vnosu trajnih sprememb v splošne urnike skupaj z vodjo zapolnijo sproščene termine. Ta del je precej zamuden, vpletenega je veliko znanja o uporabnikih na pamet − kdo je prilagodljiv, kdo ni, njihove specifične želje, lokacija idr. Po vnosu trajnih popravkov in odpovedi se natisne sproščene termine, ki so označeni z oznako cpd. Osnovni urnik se nato zapre, kar pomeni, da se izvorne datoteke v tistem tednu ne ureja več. V osnovnem urniku so tako dodane trajnejše spremembe, tedenske in začasne pa se vnašajo v tedenski urnik.

Sprotnih dnevnih popravkov se ne vnaša v datoteko, ampak se jih beleži na natisnjen tedenski urnik, ki ga uporabljajo kot osnovo za efektivne ure oskrbovalcev in v arhivske namene. Tedenski urniki za vsak teden v obliki Word datoteke se hranijo na disku. Osnovni urnik ostaja ena datoteka, zaklenjena z geslom. Tedenski urnik se pripravlja po naslednjih navodilih, vsebuje pa veliko ročnega preverjanja in štetja in predvideva pripravo urnikov v treh dneh.

Slika 4: primer urnika za enega izvajalca

Slika 4: primer urnika enega izvajalca (Interna dokumentacija obravnavane organizacije, 2016)



Priprava urnikov za naslednji teden se izvaja na sledeči način (vir: interna dokumentacija obravnavane organizacije, 2016):

I.Dan

1. Osnovne urnike shraniš pod TEDENSKE in nato delaš spremembe.

2. Uredimo A in B urnike.

3. Uporabnike označene s sivo jih lahko brišemo oziroma namesto imena

napišemo CPD (začasno odsotni uporabniki).

4. Uporabnike označene z rumeno jih pustimo v urniku (so npr. v bolnici in lahko

da pridejo nazaj in potrebujejo pomoč).

5. Glede na stanje ur v mesečnem razporedu razdeliš 1 do 2 P, število rumenih

D (izvajalci z delovnim dnem v plan dela) mora biti 25+ (1 ali 2 P). Višek

kadra lahko planiraš LD (letni dopust) oskrbovalkam, ki imajo še največji

preostanek LD.

6. V primeru, da si oskrbovalkam planiral LD, jih moraš o tem takoj obvestiti.

7. Osiviš LD, B, PDf in P ter pomodriš popoldanske ter označiš delovne vikende

z rdečo pisavo.

8. Stanje pripravljenosti (@) napišeš oskrbovalki, ki je določena pod SOB.

9. V kosilskih ekipah določiš oskrbovalkam urnik: katera je dežurna za vikend,

ima kosila označena z ikono sonca.

10. V primeru, da je za vikend iz kosilske ekipe dežurna oskrbovalka, ki ima svoj

urnik (nekateri imajo fiksen urnik), jo za prihajajoči teden daš na urnik od

kosil, njen urnik pa sodelavki iz njene (kosilske) ekipe.

11. Rešiš kosila označena s soncem, obvezno jih ima nekdo iz iste skupine, razen

zeleni sončki - tega ima lahko kdorkoli iz kosilske ekipe.

12. Rešiš DC (dnevni center) prevoze, katere ima lahko nekdo od kosilske ekipe.

13. Vse uporabnike, ki jih je potrebno nadomeščati, jih kopiramo na drugi list

urnikov, s črto ločimo posamezni urnik ter natisnemo ta list.

14. Preveriš, če imaš na listu, ki si ga natisnil vse uporabnike, ki jih je potrebno

nadomeščati.

II.Dan

15. Urediš nadomeščanja.

15. Kopiraš cele urnike, nadomeščanja podčrtamo z rdečo črto, urnik ki je že

nadomeščen pa daš na pisavo 8.

16. Najprej rešiš občine Vojnik, Dobrna in Štore.

17. Nato rešiš “posebne” uporabnike.

18. Urnik JD (javna dela) najprej pokrijejo oskrbovalke iz JD, nato iz druge

skupine.

19. Nato pokrivaš nadomeščanja v isti skupini, izpad celega tedna poskusiš rešiti

samo z enim nadomeščanjem ali največ dvema oskrbovalkama, če gre.

20. Če ne, poiščeš nadomeščanje v sosednji skupini.



21. Na koncu pokriješ s tistim izvajalcem ki je prost.

22. Na koncu imaš na sivih in modrih urnikih vse na pisavi 8 in nobene

oskrbovalke brez urnika.

23. Razdeliš popoldanske urnike, prvi urnik mora imeti oskrbovalka iz katerekoli

kosilske ekipe, zadnji urnik pa oskrbovalka iz JD.

24. Razdeliš vikende in jih kopiraš k oskrbovalkam.

25. Preveriš koledarček.

26. Preveriš, da ima vsak oskrbovalec pisano dokumentacijo.

27. Napišeš kdo ima tekoče urnike.

28. Preveriš “prepovedi” in jih rešiš.

III. Dan

29. V opažanjih iz Aleje (spletna aplikacija oskrba.net, opomba avtorja)

preveriš, če je kaj novega v povezavi z urniki.

30. pripraviš urnik za oskrbovalce:

◦ vsak urnik na svoj list,

◦ brišeš urnik na sivem ali modrem urniku (posamezne dneve),

◦ izbrišeš celoten urnik, ko so oskrbovalci ves teden prosti,

◦ na list dodaš podatke glede popoldanskih oskrbovalk, oskrbovalke v

stanju pripravljenosti,

◦ natisneš urnike za oskrbovalce,

◦ koordinatorja prosiš, da tekoče urnike pošlje direktorju na mail.

Tekoči urniki

1. Uporabniki v bolnici, ki so označeni z rumeno: spremenimo v CPD tekoči dan. 2. Uporabniki, ki odpovejo v tekočem tednu prvi in zadnji: oskrbovalka prej

zaključi z delom in ima minus ure (po potrebi prestaviš malico in dokumentacijo).

3. Urnike popravljamo zadaj in pri oskrbovalcih. 4. Nepravočasna odpoved: uporabnike ne zbrišemo, pripišemo nepravočasna

odpoved, ker termin računamo in damo v navodilo oskrbovalki. 5. Spremenjen urnik: če je označeno s kljukico pod celotnim urnikom pomeni,

da je oskrbovalka obveščena dan prej. Če je sprememba za ves teden, je kljukica samo pri nastali spremembi in je oskrbovalka tudi že obveščena.



3.2. SWOT ANALIZA OBSTOJEČEGA STANJA PREDNOSTI

Prednost obstoječega procesa je, da je v organizaciji že uveljavljen in so zaposleni vajeni dela z njim, uporablja pa orodje, ki ga v podjetju že uporabljajo tudi v druge namene in zato ne zahteva dodatnih stroškov zanj.

SLABOSTI

Datoteka, ki tvori podlago za izdelavo urnikov, je že v letu 2016 štela 36 strani in s časom vztrajno raste zaradi vedno večjega obsega dela organizacije. Delo na tak način je zamudno, vključuje veliko ročnega preverjanja v samem dokumentu in spremljajočih dokumentih, kar dopušča veliko prostora za napake in trati čas zaposlenih. Kljub iznajdljivosti ustvarjalcev urnika je označevanje posebnosti in vseh lastnosti postavk v urnikih težavno in nepregledno, zato je potrebna obsežna legenda označb. Uvajanje novih zaposlenih v proces ustvarjanja urnikov je težavno. Preverjanje skladnosti z zahtevami in željami uporabnikov ter zaposlenih je lahko samo ročna, kar je zamudno in dovzetno za napake. Prav tako ni vključenega nikakršnega preverjanja za prekrivanje datumov in terminov. Podatki niso strukturirani, zato je njihova obdelava težavna. Obstaja tudi nevarnost izgube izvorne datoteke, ker ni posebej poskrbljeno za varnostno kopiranje.

PRILOŽNOSTI

Večino večkratnega preverjanja lahko avtomatiziramo in kontekstualno prikažemo podatke le tam, kjer so potrebni. Z validacijo lahko zagotovimo, da se nekatere napake sploh ne morejo zgoditi, na primer prekrivanje že obstoječih obiskov. Za vse dodatne podatke o obiskih ni več potrebno, da so shranjeni in vidni neposredno v samem obisku na isti ravni, temveč jih lahko pokažemo, kadar uporabnik to zahteva, sicer pa povečamo preglednost s prikazovanjem zgolj relevantnih podatkov za trenutno delo. Z uporabo namenske rešitve lahko podatke strukturiramo in jih tako obdelujemo za morebitne izpise in statistike. Z uporabo dejanske baze podatkov lahko tudi primerno poskrbimo za zavarovanje podatkov in varnostne kopije.

GROŽNJE

Konkurenčne organizacije z namensko rešitvijo za pripravo urnikov lahko poslujejo bolj efektivno. Prav tako je lahko ovirana širitev organizacije in sprejemanje večjega števila novih strank zaradi nezmožnosti obvladovanja povečanega obsega urnikov.



4. RAZVOJ APLIKACIJE 4.1. ZAHTEVE APLIKACIJE Po pogovorih z zaposlenimi v obravnavani organizaciji in analizi obstoječega stanja smo sestavili osnovne zahteve, ki jim mora aplikacija ustrezati, da bi poenostavila in pospešila prejšnji proces ustvarjanja urnikov.

• Uporabnik aplikacije lahko ustvarja, pregleduje, ureja in po potrebi briše načrtovane obiske.

• Iz prikaza je jasno razvidna časovna umeščenost obiskov in njihove časovne dimenzije.

• Iz prikaza urnika so jasno vidni vmesni časi in morebitne vrzeli med obiski.

• Uporabnik lahko kopira celoten tedenski urnik na naslednji teden.

• Uporabnik lahko pregleduje urnike za poljubno obdobje.

• Uporabnik lahko sproti vnaša spremembe za posamezne obiske.

4.2. STRUKTURA PROJEKTA Aplikacija je sestavljena iz dveh med seboj ločenih delov, ki med seboj komunicirata preko protokola Socket.io strežniški del (backend) s Feathers.js strežnikom, ki služi kot API in vsebuje tudi bazo podatkov, in sprednji del (frontend), ki je enostranska Vue.js aplikacija. Vsak del lahko deluje na ločenih spletnih strežnikih. Osnovna struktura obeh delov je bila ustvarjena z generatorjema, bistveni deli vsake od implementacij pa se nahaja v podmapi src (krajše za source). Ker so v obeh primerih datoteke, potrebne za delo s posameznimi moduli, razdeljene po mapah, je delo s posameznim modulom enostavnejše in hitrejše, brez preskakovanja po različnih direktorijih. Celotna struktura je predstavljena na sliki 5.



Slika 5: struktura projekta (Lasten vir, 2017)



4.3. STREŽNIŠKA IMPLEMENTACIJA Naš API strežnik servira podatke v obliki JSON objektov, ki jih zlahka uporabi aplikacija na strani odjemalca. Na voljo so trije glavni servisi:

Oskrbovalci (/staff)

Podatkovni model za oskrbovalce:

{ "name": "Andrej Miklavčič", "role": "Caregiver", "mobile": "",

"phone": "", "email": "", "address": {

"street": "", "city": "" },

"createdAt": "2017-06-08T10:06:09.664Z", "updatedAt": "2017-06-08T10:06:09.664Z", "_id": "B1WWnf728t6bt7fl"

}

Stranke (/clients)

Podatkovni model za stranke:

{ "mobile": "",

"phone": "", "email": "", "address": {

"street": "Nabrežje 63", "city": "Ljubljana" },

"name": "Nika Plak", "createdAt": "2017-05-23T14:33:34.533Z", "updatedAt": "2017-05-23T14:33:34.533Z",

"_id": "0ca8cbS44xIITd8e" }

Visits (/visits)

Podatkovni model za obisk:

{ "startTime": "06:00", "endTime": "06:45", "date": "2017-06-03T16:26:23.235Z",

"caregiver": {



"id": "jMlosVKuwu4Pokyh", "name": "Metka Ziget"

}, "client": { "id": "M8CF4fIoVvST6HbO",

"name": "Marjan Zlobec" }, "createdAt": "2017-06-03T16:26:44.785Z",

"updatedAt": "2017-06-03T16:26:44.785Z", "_id": "0tv8OeKetjrzH7lO" }

Created/updated at zanka

S pomočjo zank ogrodja Feathers.js ob kreiranju novih vnosov vsakemu dodamo še polji createdAt in updatedAt. UpdatedAt se spremeni ob urejanju že obstoječih vnosov. Polje _id je avtomatsko dodano za vsak nov vnos.

4.4. IMPLEMENTACIJA NA STRANI ODJEMALCA Ker gre za enostransko aplikacijo, so glavni elementi namesto strani pogledi, med katerimi lahko uporabnik preklaplja z navigacijsko vrstico, ali pa s spremembo naslova URL. Na vrhu aplikacije je komponenta za navigacijo, s katero uporabnik dostopa do treh glavnih pogledov: Clients, Staff in Schedule.

Nastavitev povezave s strežnikom

V mapi api je nastavljena povezava med strežnikom in prednjim delom spletne aplikacije. Uporabljeni so moduli knjižnice feathers.js in socket.io, namenjeni za uporabo na strani odjemalca (obe knjižnici imata module za delovanje na obeh straneh in nudita univerzalni vmesnik zanje). Strežnik podpira povezavo tako preko REST kot preko socket.io, vendar je slednja običajno hitrejša in omogoča delovanje v realnem času, kar bo uporabno v nadaljnjem razvoju. Poleg tega je vmesnik popolnoma enak, tako da je način povezave povsem enostavno zamenljiv, če se izkaže potreba po tem.

import feathers from 'feathers/client' import hooks from 'feathers-hooks' import socketio from 'feathers-socketio'

import io from 'socket.io-client'

const socket = io('http://localhost:3030') // naslov strežnika

const api = feathers() .configure(hooks())

.configure(socketio(socket))

api.service('/staff')

api.service('/clients') api.service('/visits')



export default api

Pogleda stranke (clients) in zaposleni (staff)

V prototipu sta ta dva pogleda skoraj identična, oba pa sta namenjena vnašanju, pregledovanju, urejanju in brisanju podatkov o strankah ali zaposlenih. Slika 6 prikazuje seznam vnosov v obliki tabele s prikazanimi glavnimi podatki.

Vsaka vrstica vsebuje tudi gumba za urejanje ali brisanje obstoječega vnosa. Če uporabnik želi izbrisati vnesenega oskrbovalca ali stranko, se prikaže pojavno okno, ki od uporabnika zahteva potrditev, kot kaže slika 7.

Gumba za urejanje in dodajanje vnosa oba odpreta pogled z isto komponento, prikazano na sliki 8, ki pa se funkcionalno razlikuje glede na to, za katero dejanje gre. Prav tako je različen URL naslov: kadar gre za vstavljanje novega vnosa, to tudi odraža URL naslov, pri urejanju že obstoječega pa URL naslov vsebuje tudi enoznačni identifikacijski znakovni niz vnosa, ki ga uporabnik ureja. Gre za komponento, ki je podrejena glavnemu pogledu. Svoj lasten pogled ima zato, ker predvidevamo razširitev samega obrazca z mnogo več podatki v nadaljnjem razvoju za razliko od dodajanja obiska, ki ne bo vseboval bistveno več polj in je zato lahko pojavno okno.

Slika 6: seznam vseh zaposlenih (lasten vir, 2017)

Slika 7: potrditveno okno za izbris vnosa (Lasten vir, 2017)



Zaposlenim se določi tudi delovno mesto, ki je lahko oskrbovalec, vodja ali administrator, prednastavljena pa je izbira za oskrbovalca. Obiske izvajajo običajno samo oskrbovalci, obstajajo pa tudi izjeme.

Pogled urnik (schedule)

Pogled urnika vsebuje glavno komponento timegrid, izdelano posebej za prototip. Sama komponenta je sestavljena iz dveh pogledov, dnevnega in tedenskega, na vrhu obeh pa je kontrolna vrstica s kontekstualnimi kontrolami in primernim prikazom izbranega časovnega obdobja.

Kontrolna vrstica

Kontrolno vrstico (na sliki 9, obrobljena z modro) uporabnik uporablja za spreminjanje prikazanega datuma, preklapljanje med tedenskim in dnevnim pogledom ter dodajanje novih obiskov. Uporabnik lahko izbere poljuben datum z

Slika 8: pogled za dodajanje novega zaposlenega (Lasten vir, 2017)



izbirnikom datuma, ali pa se pomika za en dan naprej ali nazaj (na voljo v dnevnem pogledu), ali pa za en teden naprej ali nazaj (mogoče v obeh pogledih). Prisoten je tudi gumb za ponastavitev trenutno izbranega datuma na trenutni datum, ki pa je omogočen samo, kadar uporabnik ta datum spremeni.

Slika 9: kontrolna vrstica (lasten vir, 2017)

V kontrolni vrstici je tudi gumb, ki kopira obiske v izbranem tednu na naslednji teden. Preden se izvede kopiranje se preveri, ali v naslednjem tednu ni že vnesenih obiskov. Če so, se kopiranje ne izvede, uporabnik vidi obvestilo, da kopiranje ni mogoče zaradi že obstoječih obiskov. Če je kopiranje izvedeno, se naredi kopija objekta za vsak obisk iz izvornega tedenskega urnika in se hkrati datumskemu polju priredi nov datum, z dodanim enim tednom. Nato se vsi kopirani obiski pošljejo na strežnik.

Možnost kopiranja olajša vnašanje obiskov v prihodnosti, hkrati pa ohranja spremembe iz prejšnjih tednov. Uporabnik se seveda lahko odloči tudi za možnost, da vse obiske vnaša ročno.

Pojavno okno za urejanje in dodajanje obiska

Poleg komponente za prikaz samega urnika pogled vsebuje tudi komponento s pojavnim oknom, ki vsebuje obrazec za vnašanje ali urejanje obiska, prikazano na slikah 10 in 11. Komponenta je ista za dodajanje novega in urejanje že obstoječega obiska, glede na to, ali gre za urejanje ali dodajanje, pa ima določene prilagoditve. Gumb za brisanje obiska je tako na voljo le, če gre za urejanje že obstoječega obiska, kot je to vidno na sliki 11. Obisk uporabnik lahko ureja z dvoklikom na sam obisk v urniku, novega pa lahko doda s klikom na gumb v kontrolni vrstici.

V pojavnem oknu je z dinamičnim omogočanjem v začetku onemogočenih polj poskrbljeno za vodenje uporabnika skozi proces dodajanja obiska. Dokler ni izbran oskrbovalec, tako ni možno vpisovati začetnega časa obiska, dokler ni izbran začetni čas, ni možno izbrati časa zaključka. V izbirniku za čas zaključka je poskrbljeno, da obisk ne more biti krajši od petnajstih minut − to je namreč najkrajše dovoljeno trajanje obiska.



Pri vnašanju je z validacijo na strani odjemalca poskrbljeno, da so vneseni vsi potrebni podatki in da so ti smiselni v okviru obiska. Polje za izbiro datuma ima privzeto vrednost trenutno izbranega datuma pregledovanja urnika (datum iz stanja aplikacije).

Slika 11: pojavno okno za dodajanje novega obiska (Lasten vir, 2017)

Slika 10: pojavno okno za urejanje že obstoječega obiska z uporabo iste komponente (Lasten vir, 2017)



Dnevni pogled urnika

Dnevni pogled je prikazan na sliki 12. Vsak obisk je od levega roba odmaknjen glede na čas začetka, širina pa je izpeljana iz trajanja obiska. Najkrajše trajanje obiska je petnajst minut, kar pomeni, da je tudi v preglednici precej majhen in posledično ne more vsebovati veliko informacij. Čas začetka in zaključka, trajanje in oskrbovalec, ki ga izvaja, so razvidni tudi brez dodatnih informacij v sami komponenti vsakega obiska, kljub temu pa smo dodali možnost prikaza večjega števila informacij (sčasoma jih bo verjetno še več) ob kliku na obisk z zaslonskimi namigi (ang. tooltip, prikazan na sliki 13). Vsi podatki so sicer vidni tudi v pojavnem oknu za urejanje obiska, vendar z zaslonskim namigom uporabnik lahko do informacij pride brez menjave konteksta, na ta način pa se izognemo tudi možnosti, da bi uporabnik ob preverjanju informacij pomotoma uredil obisk.

Slika 13: dnevni pregled urnika (Lasten vir, 2017)

Slika 12: tooltip z dodatnimi informacijami o obisku (Lasten vir, 2017)



Postavitev obiska v urniku, izpeljana iz časa začetka:

visitLeft (visit) { let startHour = visit.startTime.split(':')[0] let startMins = visit.startTime.split(':')[1] let idx = this.timeRangeHours.indexOf(+startHour)

return `${idx * 120 + +startMins * 2}px` }

Tedenski pogled urnika

V tem pogledu (slika 14) je potrebno prikazati bistveno več obiskov kot v dnevnem. Obiski so zato uniformne dolžine. Pogled predvsem služi hitremu pregledu morebitnih vrzeli ali neuravnoteženosti pri razporeditvi obiskov med različnimi oskrbovalci. Tudi iz tega pogleda je seveda možno dodajati, urejati ali brisati obiske.

Prekrivanje obiskov

Preprečiti je potrebno konflikte z že obstoječimi obiski ob vnosu novih in urejanju že obstoječih. Preverjati smo morali za naslednje tri scenarije:

Izbran začetek obiska se prekriva z že obstoječim obiskom:

startTimeConflict () { let selectedVisitStart = moment(this.selectedVisit.startTime, 'HH:mm') let startIsBetween = this.employeeVisitsThisDate()

.filter(visit => selectedVisitStart

Slika 14: tedenski pregled urnika (Lasten vir, 2017)



.isBetween(moment(visit.startTime, 'HH:mm'), moment(visit.endTime, 'HH:mm')))

if (startIsBetween.length > 0) { this.startConflictMessage = 'Start cannot be during another visit'

return true } return false

}

Izbran konec obiska se prekriva z že obstoječim obiskom:

endTimeConflict () { let selectedVisitEnd = moment(this.selectedVisit.endTime, 'HH:mm') let endIsBetween = this.employeeVisitsThisDate()

.filter(visit => selectedVisitEnd .isBetween(moment(visit.startTime, 'HH:mm'), moment(visit.endTime, 'HH:mm')))

if (endIsBetween.length > 0) { this.endConflictMessage = 'End cannot be during another visit' return true

} return false }

Izbran začetek obiska je postavljen pred že obstoječim začetkom drugega obiska, izbran konec obiska pa je postavljen za koncem že obstoječega obiska − nov obisk torej v celoti prekriva že obstoječega:

overflowingTimeConflict () { let selectedVisitStart = moment(this.selectedVisit.startTime, 'HH:mm') let selectedVisitEnd = moment(this.selectedVisit.endTime, 'HH:mm')

let isOverflowing = this.employeeVisitsThisDate() .filter(visit => selectedVisitStart .isBefore(moment(visit.startTime, 'HH:mm')) && selectedVisitEnd .isAfter(moment(visit.endTime, 'HH:mm'))) if (isOverflowing.length > 0) {

this.overflowingConflictMessage = 'Covering another visit' return true }

return false }

Poleg tega preverjamo tudi, ali uporabnik pri naknadnem vnašanju, ko je bil čas zaključka že izbran, izbere čas začetka, ki je kasnejši od časa zaključka obiska. Če nov obisk, ki ga uporabnik želi shraniti, ustreza kateremukoli izmed teh treh scenarijev, mu obiska ne dovolimo shraniti, v pojavnem oknu pa uporabnika



obvestimo, zakaj shranjevanje ni mogoče. To lahko vidimo na sliki 15. Preverjanje se sproži ob vsaki spremembi izbrane vrednosti v poljih za izbiro izvajalca, datuma, začetka in konca obiska. Šele ko so konflikti v celoti odstranjeni, je obisk mogoče shraniti.

Slika 15: prikaz napak pri izbranih časih za obisk (Lasten vir, 2017)



5. ZAKLJUČEK V okviru diplomske naloge smo izdelali delujoč prototip enostranske spletne aplikacije za ustvarjanje in urejanje urnikov za pomoč na domu. Prototip je bil izdelan na podlagi zahtev, pridobljenih iz pogovorov z zaposlenimi, ki so zadolženi za pripravo urnikov v obravnavani organizaciji. Aplikacija omogoča ustvarjanje in urejanje urnikov ter nudi intuitiven grafični prikaz tako ustvarjenih urnikov.

5.1. OCENA UČINKOV Spletna aplikacija urnik bo olajšala delo koordinatorjev, zadolženih za njihovo pripravo, in s tem predvidoma bistveno skrajšala čas, ki ga koordinatorji porabijo za sestavljanje urnikov dela. Ocenjujemo, da bo čas priprave tedenskega urnika skrajšan s treh dni na največ nekaj ur, v primeru minimalnih sprememb pa bo zaradi možnosti kopiranja vseh že vnesenih popravkov tekočega urnika čas priprave najverjetneje še krajši. Z uporabo aplikacije urnik bo za pripravo urnikov dela potrebno tudi manjše število zaposlenih. Namenska aplikacija je prilagojena za namene izvajanja pomoči na domu. Obstajajo že številne spletne aplikacije za urejanje urnikov zaposlenih, vendar so običajno narejene za spremljanje izmenskih urnikov, niso pa prilagojene za uporabo s kratkimi obiski, zato je naša rešitev s tega vidika primernejša.

Za podjetje Aleja soft, d.o.o. aplikacija urnik predstavlja novo storitev/produkt, ki jo lahko nudi v okviru razširitev že obstoječega programskega paketa za podporo izvajanju pomoči na domu. Razvoj predstavljenega prototipa je po grobi oceni trajal približno osem delovnih tednov, vključno s pogovori z zaposlenimi in pripravo zahtev, in zahteval delo enega programerja.

5.2. POGOJI ZA UVEDBO Za uvedbo razvite rešitve je potrebna njena prilagoditev za uporabo z realno bazo podatkov obstoječe aplikacije. Ker je rešitev ločena na strežniški del in implementacijo na strani odjemalca, so potrebne minimalne spremembe, uporabniški vmesnik pa lahko ostane isti. Rešitev bo vključena v prenovljen uporabniški vmesnik obstoječe spletne aplikacije Oskrba.net, ki je trenutno še v razvoju, vendar je zaradi uporabe istega pristopa in orodij kot pri razvoju prototipa mogoča takojšnja vključitev urnikov kot modula v razvoj prenovljenega vmesnika.

5.3. MOŽNOSTI NADALJNJEGA RAZVOJA Urniki bodo dodani kot modul že obstoječi aplikaciji, zato bi lahko dodali primerjalen prikaz z dejansko zabeleženimi obiski izvajalcev s terena, kar bi uporabniku omogočalo, da najde mesta za možno optimizacijo urnikov. Poleg že razvitih pogledov urnika bi lahko dodali še nekaj različnih, še posebej pogled za posameznega izvajalca, kjer bi bili vsi tedenski obiski razporejeni po urah. Dodali bi lahko še poglede po strankah. Mesečni pogledi bi bili za implementacijo



še posebej težavni zaradi same količine obiskov, zato bi smiselnost in koristnost takšnih prikazov morali potrditi ali ovreči skupaj z naročnikom. Ena izmed možnosti zapolnjevanja tedenskih urnikov bi bilo generiranje teh iz dogovorjenih urnikov strank, vendar se takšen pristop hitro lahko izkaže za precej kompleksnejšega in težavnega, kot se zdi na prvi pogled. Še vedno bi namreč morali skrbeti za usklajevanje z zaposlenimi, ki so na voljo. Pri večji količini izvajalcev bi bilo smiselno uvesti skupine, ki bi jim pripadali določeni izvajalci in stranke. Pri izbiri vnosa obiska bi tako uporabnik najprej moral izbrati zaposlenega in stranko iz iste skupine. Skupine bi lahko bile oblikovane tudi glede na geografsko cono. Dodatno bi bilo smiselno vključiti tudi realno − časovna sporočila, ki se udeležencem pošiljajo ob spremembi urnika. Ker smo uporabili povezave preko spletnih vtičnic, je ogrodje za to že pripravljeno. V prototipu je prikazana le ena izmena, v končnem produktu pa bo teh izmen lahko tudi več oziroma jih bo toliko, kolikor jih organizacija potrebuje (običajno gre za dve izmeni). Dodatno bi lahko omogočili tudi možnost natisa samih urnikov v različnih pogledih. Za urejanje obiskov v urniku bi lahko dodali še funkcionalnost drag-and-drop in možnost spreminjanja časa začetka in konca z vlečenjem levega ali desnega roba obiska v pogledu urnika.



LITERATURA IN VIRI DIS slovarček (2017). dis-slovarcek.ijs.si. Pridobljeno 30. 6. 2017 na http://dis-slovarcek.ijs.si Dokumentacija Feathers.js (2017). docs.feathersjs.com. Pridobljeno 27. 6. 2017 na https://docs.feathersjs.com ECMAScript (2017). en.wikipedia.org. Pridobljeno 28. 6. 2017 na https://en.wikipedia.org/wiki/ECMAScript Feathers.js (2017). feathersjs.com. Pridobljeno 27. 6. 2017 na https://feathersjs.com Inštitut RS za socialno varstvo. (2015). Izvajanje pomoči na domu, analiza stanja v letu 2014. Pridobljeno 27. 6. 2017 na http://www.irssv.si/upload2/pnd/IRSSV%20Izvajanje%20pomoci%20na%20domu%20-%20analiza%20stanja%20v%20letu2014_koncno.pdf Inštitut RS za socialno varstvo. (2016). Izvajanje pomoči na domu, analiza stanja v letu 2015. Pridobljeno 27. 6. 2017 na http://www.irssv.si/upload2/Izvajanje%20PND%20za%20leto%202015.pdf Islovar (2017). Islovar.org. Pridobljeno 30.6. 2017 na http://www.islovar.org/islovar Izdaje ECMAScript (2017). Developer.mozilla.org. Pridobljeno 28.6. 2017 na https://developer.mozilla.org/en-US/docs/Web/JavaScript/Language_Resources Javascript (2017). developer.mozilla.org. Pridobljeno 25. 6. 2017 na https://developer.mozilla.org/en-US/docs/Web/JavaScript/About_JavaScript Kaj je npm (2017). docs.npmjs.com. Pridobljeno 26. 6. 2017 na https://docs.npmjs.com/getting-started/what-is-npm Kappert, L. (28. 10. 2015). ECMAScript 6 (ES6): What’s new in the next version of Javascript. Smashing magazine. Pridobljeno 28. 6. 2017 na https://www.smashingmagazine.com/2015/10/es6-whats-new-next-version-javascript/ moment.js (2017). momentjs.com. Pridobljeno 28. 6. 2017 na https://momentjs.com NeDB (2017). github.com. Pridobljeno 29. 6. 2017 na https://github.com/louischatriot/nedb Node (2017). nodejs.org. Pridobljeno 26. 6. 2017 na https://nodejs.org/en/ Node.js wiki (2017). en.wikipedia.org. Pridobljeno 26. 6. 2017 na https://en.wikipedia.org/wiki/Node.js Npm (2017). npmjs.com. Pridobljeno 26. 6. 2017 na https://www.npmjs.com

http://dis-slovarcek.ijs.si/

http://dis-slovarcek.ijs.si/

https://docs.feathersjs.com/

https://en.wikipedia.org/wiki/ECMAScript

https://feathersjs.com/

http://www.irssv.si/upload2/pnd/IRSSV%20Izvajanje%20pomoci%20na%20domu%20-%20analiza%20stanja%20v%20letu2014_koncno.pdf

http://www.irssv.si/upload2/pnd/IRSSV%20Izvajanje%20pomoci%20na%20domu%20-%20analiza%20stanja%20v%20letu2014_koncno.pdf

http://www.irssv.si/upload2/Izvajanje%20PND%20za%20leto%202015.pdf

http://www.islovar.org/islovar

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Language_Resources

https://developer.mozilla.org/en-US/docs/Web/JavaScript/About_JavaScript

https://docs.npmjs.com/getting-started/what-is-npm

https://www.smashingmagazine.com/2015/10/es6-whats-new-next-version-javascript/

https://www.smashingmagazine.com/2015/10/es6-whats-new-next-version-javascript/

https://momentjs.com/

https://github.com/louischatriot/nedb

https://nodejs.org/en/

https://en.wikipedia.org/wiki/Node.js

https://www.npmjs.com/



Npm (software) (26. 6. 2017). Pridobljeno 26. 6. 2017 na https://en.wikipedia.org/wiki/Npm_(software) Pomoč družini (2017). mddsz.gov.si. Pridobljeno 20. 6. 2017 na http://www.mddsz.gov.si/si/delovna_podrocja/sociala/socialnovarstvene_storitve/pomoc_druzini/#c18111 Routing (2017). vuejs.org. Pridobljeno 25. 6. 2017 na https://vuejs.org/v2/guide/routing.html Severien, T. (19. 10. 2016). Yarn vs npm: everything you need to know (2017). Sitepoint. Pridobljeno 28. 6. 2017 na https://www.sitepoint.com/yarn-vs-npm/ Simpson, K. (2015). You don’t know JS - ES6 and beyond. Sebastopol: O'Reilly Media Single file components (2017). vuejs.org. Pridobljeno 24. 6. 2017 na https://vuejs.org/v2/guide/single-file-components.html Socket.io (2017). github.com. Pridobljeno 29. 6. 2017 na https://github.com/socketio/socket.io Software prototyping (2017). en.wikipedia.org. Pridobljeno 29.6. 2017 na https://en.wikipedia.org/wiki/Software_prototyping#Outline_of_the_prototyping_process SPA (2017). en.wikipedia.org. Pridobljeno 23. 6. 2017 na https://en.wikipedia.org/wiki/Single-page_application State management (2017). vuejs.org. Pridobljeno 25. 6. 2017 na https://vuejs.org/v2/guide/state-management.html Using promises (2017). developer.mozilla.org. Pridobljeno 29. 6. 2017 na https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises Vue templates (2017). vuejs.org. Pridobljeno 25. 6. 2017 na https://vuejs.org/v2/guide/syntax.html Virtual DOM (2017). vuejs.org. Pridobljeno 24. 6. 2017 na https://vuejs.org/2016/04/27/announcing-2.0/ Vuex (2017). vuex.vuejs.org. Pridobljeno 24. 6. 2017 na https://vuex.vuejs.org/en/intro.html Vue-Vuex getting started (2017).https://medium.com/@bradfmd/vue-vuex-getting-started-f78c03d9f65 Vue.js wiki (2017). en.wikipedia.org. Pridobljeno 26. 6. 2017 na https://en.wikipedia.org/wiki/Vue.js

https://en.wikipedia.org/wiki/Npm_(software)

http://www.mddsz.gov.si/si/delovna_podrocja/sociala/socialnovarstvene_storitve/pomoc_druzini/#c18111

http://www.mddsz.gov.si/si/delovna_podrocja/sociala/socialnovarstvene_storitve/pomoc_druzini/#c18111

https://vuejs.org/v2/guide/routing.html

https://www.sitepoint.com/yarn-vs-npm/

https://vuejs.org/v2/guide/single-file-components.html

https://github.com/socketio/socket.io

https://en.wikipedia.org/wiki/Software_prototyping#Outline_of_the_prototyping_process

https://en.wikipedia.org/wiki/Software_prototyping#Outline_of_the_prototyping_process

https://en.wikipedia.org/wiki/Single-page_application

https://vuejs.org/v2/guide/state-management.html

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises

https://vuejs.org/v2/guide/syntax.html

https://vuejs.org/2016/04/27/announcing-2.0/

https://vuex.vuejs.org/en/intro.html

https://medium.com/@bradfmd/vue-vuex-getting-started-f78c03d9f65

https://medium.com/@bradfmd/vue-vuex-getting-started-f78c03d9f65

https://en.wikipedia.org/wiki/Vue.js



Vue-router (2017). router.vuejs.org. Pridobljeno 25. 6. 2017 na https://router.vuejs.org/en/ Vue-router Github (2017). github.com. Pridobljeno 30. 6. 2017 na https://github.com/vuejs/vue-router Web application (2017). en.wikipedia.org. Pridobljeno 23. 6. 2017 na https://en.wikipedia.org/wiki/Web_application Web sockets (2017). developer.mozilla.org. Pridobljeno 29. 6. 2017 na https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API Yang Shun, T. (3. 6. 2017). Front End Study Guide. Pridobljeno 24. 6. 2017 na http://engineering.grab.com/grabs-front-end-study-guide#single-page-apps-spas

KAZALO SLIK Slika 1: napaka sintakse ob poskusu spremembe vrednosti deklarirane s const (Lasten vir, 2017) ............................................................................. 7 Slika 2: komponenta v eni datoteki .vue (Vue, 2017) .................................. 10 Slika 3: diagram delovanja vuex ........................................................... 13 Slika 4: primer urnika enega izvajalca (Interna dokumentacija obravnavane organizacije, 2016) .......................................................................... 21 Slika 5: struktura projekta (Lasten vir, 2017) ........................................... 26 Slika 6: seznam vseh zaposlenih (lasten vir, 2017) ..................................... 29 Slika 7: potrditveno okno za izbris vnosa (Lasten vir, 2017) .......................... 29 Slika 8: pogled za dodajanje novega zaposlenega (Lasten vir, 2017) ................ 30 Slika 9: kontrolna vrstica (lasten vir, 2017) .............................................. 31 Slika 10: pojavno okno za dodajanje novega obiska (Lasten vir, 2017) .............. 32 Slika 11: pojavno okno za urejanje že obstoječega obiska z uporabo iste komponente (Lasten vir, 2017) ............................................................................ 32 Slika 12: dnevni pregled urnika (Lasten vir, 2017) ...................................... 33 Slika 13: tooltip z dodatnimi informacijami o obisku (Lasten vir, 2017) ............ 33 Slika 14: tedenski pregled urnika (Lasten vir, 2017).................................... 34 Slika 15: prikaz napak pri izbranih časih za obisk (Lasten vir, 2017) ................. 36

POJMOVNIK

Single-page application: speltna aplikacija na eni strani Syntactic sugar - sintaktična olepšava, sintaktična poslastica (DIS slovarček, 2017)

KRATICE IN AKRONIMI AJAX: asinhroni JavaScript in XML

API: API, Application Programming Interface - aplikacijski programski vmesnik

https://router.vuejs.org/en/

https://github.com/vuejs/vue-router

https://en.wikipedia.org/wiki/Web_application

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

http://engineering.grab.com/grabs-front-end-study-guide#single-page-apps-spas



CLI: Command Line Interface - znakovni uporabniški vmesnik, vmesnik za ukazno

vrstico

CRUD: Create, Read, Update, Delete: Ustvarjanje, branje, posodabljanje in brisanje

SPA: Single page application

CSS: cascading style sheets: predloge, ki določajo izgled spletnih strani

DOM: Document Object Model - objektni model dokumenta

HTML: hypertext markup language - jezik za označevanje nadbesedila

HTTP: Hypertext Transfer Protocol - protokol za prenos hiperteksta

JSON: Javascript object notation

REST: representational state transfer - predstavitveni prenos stanja

spletna aplikacija za upravljanje urnikov izvajalcev ... · še 700 uporabnikih, ki bi potrebovali...

Documents