Kosteusmittarin etäkäyttöliittymä Pilvipalvelu IoT-laitteen käyttöön Veli Luukkonen Opinnäytetyö Syyskuu 2016 Tekniikan ja liikenteen ala Insinööri (AMK), tieto- ja viestintätekniikka Tietoverkkoturvallisuus ja teollinen internet Kuvailulehti Tekijä(t) Luukkonen, Veli Matti Julkaisun laji Opinnäytetyö, AMK Päivämäärä 23.07.2016 Sivumäärä 109 Julkaisun kieli Suomi Verkkojulkaisulupa myönnetty: x Työn nimi Kosteusmittarin etäkäyttöliittymä Pilvipalvelu IoT-laitteen käyttöön Tutkinto-ohjelma Insinööri (AMK), tieto- ja viestintätekniikka Työn ohjaaja(t) Olli Väänänen Toimeksiantaja(t) PehuTec Oy Tiivistelmä Tehtävänä oli etäkäyttöliittymän eli pilvipalvelun toteutus PehuTec PTGM-16 rakeisen ma- teriaalin kosteusmittariin. Työhön kuului täydellinen full stack -toteutus sisältäen palvelin- ja asiakasohjelmistot. Etäkäyttöliittymään oli tavoitteena saada samanlaiset toiminnot kuin mittariin kuuluvassa erillisessä näyttöyksikössä. Lisäksi etäkäyttöliittymään toteutettiin ra- portointi, jota ei ole näyttöyksiköllä. Sovellus toteutettiin tavallisena asiakas palvelin -ratkaisuna perinteisellä HTTP ReST-raja- pinnalla. Mittarin ja palvelimen rajapinnassa käytettiin myös HTTP ReST-tekniikkaa. Data siirrettiin mahdollisuuksien mukaan JSON-muodossa. Palvelinohjelmisto toteutettiin Pyt- hon ohjelmointikielellä Tornado framework -ympäristössä. Apuna käytettiin DataSet-tieto- kantarajapintakirjastoa. Asiakassovellus toteutettiin yhdistelmällä HTML, CSS ja JavaScript. Apuna käytettiin JQuery- ja D3.js-kirjastoja. Työn lopputuloksena saatiin toimiva etäkäyttöliittymä. Toteutuksessa oli mukana tavoit- teeksi asetetut ominaisuudet. Joitakin näyttöyksikön toimintoja jätettiin pois, koska niiden käyttö ei ole järkevää etäkäyttöliittymän kautta. Tällainen on esimerkiksi mittarin kalib- rointi. Web-palveluiden toteutus on pitkälle valmiiksi kehitettyjen kirjastojen yhdistämistä Lego palikoiden tapaan. Pienillä koodimäärillä on mahdollista tehdä näyttäviäkin toteutuksia. Esimerkkinä mainitaan graafisten esitysten teko. Laiteläheistä ohjelmointia ei juuri tarvita. Kokeneelle ohjelmoijalle siirtyminen sulautetuista järjestelmistä www-ympäristöön ei tuota suuria ongelmia. Varsinkin palvelinohjelmointi on yllättävän samankaltaista sulautet- tuihin järjestelmiin verrattuna. Avainsanat (asiasanat) IoT, esineiden internet, pilvipalvelu, HTTP ReST, JSON, Python, HTML, CSS, JavaScript Muut tiedot Description Author(s) Luukkonen, Veli Matti Type of publication Bachelor’s thesis Date 23.06.2016 Language of publication: Finnish Number of pages 109 Permission for web publi- cation: x Title of publication Remote user interface of moisture meter Cloud service for IoT device Degree programme B.Sc. Information and communication technology Supervisor(s) Väänänen, Olli Assigned by PehuTec Oy Abstract The purpose of the thesis was to implement a remote user interface or cloud service for for grainy material on PehuTec PTGM16 moisture meter. The? thesis contains complete full stack implementation including both client and server software. The target was that the remote user interface should contain the same features as the meter’s separate display unit. In addition, the remote user interface contains report feature, which is not in the display unit. The application is a typical client server solution. It uses HTTP ReST interface. The same interface is used between the meter and server. In the data transmission JSON type data is used if possible. In the server the software is imple- mented using Python programming language with Tornado framework. The dataset data- base interface library is used as support. the client software is implemented using HTML, CSS and JavaScript. JQuery and D3.js libraries are used as support. The thesis results in a remote user interface which contains features implemented at the beginning of the project. Some features were removed because their use via remote user interface is not reasonable, e.g. the calibration of the meter. In practice, the web applica- tion implementation is about connecting ready libraries similar to putting together Lego blocks. Using a small amount of code it is possible to carry out impressive implementa- tions, for example charts. Low level programming was not needed. For an experienced pro- grammer the transition from embedded systems to web environment does not cause big problems. Back end programming is very similar when comparing it to embedded pro- gramming particularly. Keywords/tags (d) IoT, Internet of Things, cloud service, HTTP ReST, JSON, Python, HTML, CSS, JavaScript Miscellaneous 112 Sisältö Lyhenteet........................................................................................................................ 7 Käsitteet ......................................................................................................................... 7 1 Työn tausta ............................................................................................................. 9 1.1 Toimeksiantaja ............................................................................................ 9 1.2 Tavoitteet .................................................................................................... 9 2 Toimintaympäristö ............................................................................................... 10 2.1 Tyypillinen IoT-järjestelmän rakenne ........................................................ 10 2.1.1 Yleistä .................................................................................................... 10 2.1.2 Laitteet eli tuotteet............................................................................... 10 2.1.3 Tiedonsiirto ........................................................................................... 12 2.1.4 Pilvipalvelu ............................................................................................ 13 2.1.5 Käyttäjien hallinta, tietoturva ja laitehallinta ....................................... 17 2.1.6 Järjestelmän ulkopuolelta tuleva data ................................................. 18 2.2 Kosteudenmittausjärjestelmän yleiskuvaus .............................................. 18 2.2.1 Yleistä .................................................................................................... 18 2.2.2 Mittari ................................................................................................... 19 2.2.3 Tiedonsiirto ........................................................................................... 20 2.2.4 Pilvipalvelu ............................................................................................ 20 2.2.5 Laitteiden ja käyttäjien hallinta sekä tietoturva ................................... 22 3 Projektin tekniikat ja työkalut .............................................................................. 23 3.1 Yleistä ........................................................................................................ 23 3.2 Projektinhallinta ........................................................................................ 23 3.2.1 Redmine ................................................................................................ 24 3.2.2 Jira ......................................................................................................... 26 3.2.3 Projektin näkökulma ............................................................................. 27 3.3 Versionhallinta........................................................................................... 28 2 3.3.1 Yleistä .................................................................................................... 28 3.3.2 Subversion (SVN) .................................................................................. 30 3.3.3 GIT ......................................................................................................... 31 3.3.4 Projektin näkökulma ............................................................................. 32 3.4 HTTP-rajapinta: tekniikat ja datarakenteet ............................................... 33 3.4.1 Yleistä .................................................................................................... 33 3.4.2 AJAX ...................................................................................................... 35 3.4.3 Datarakenne x-www-form-urlencoded ................................................ 37 3.4.4 JSON ...................................................................................................... 38 3.4.5 CSV ........................................................................................................ 39 3.5 Tietokanta .................................................................................................. 40 3.5.1 Yleistä .................................................................................................... 40 3.5.2 Relaatiomalli ......................................................................................... 40 3.5.3 Muut tietokantamallit .......................................................................... 42 3.5.4 MySQL ................................................................................................... 43 3.5.5 Muut relaatiotietokanta vaihtoehdot .................................................. 44 3.5.6 NoSQL vaihtoehdot ............................................................................... 45 3.5.7 Projektin näkökulma ............................................................................. 47 3.6 Back-end toteutus ..................................................................................... 47 3.6.1 Yleistä .................................................................................................... 47 3.6.2 Python ................................................................................................... 48 3.6.3 PHP ........................................................................................................ 50 3.6.4 Ruby ...................................................................................................... 51 3.6.5 Projektin näkökulma ............................................................................. 52 3.7 Python kirjastot ......................................................................................... 53 3.7.1 Yleistä .................................................................................................... 53 3.7.2 Tornado framework .............................................................................. 53 3 3.7.3 Python dataset ...................................................................................... 55 3.8 Front-end -toteutus ................................................................................... 56 3.8.1 Yleistä .................................................................................................... 56 3.8.2 HTML-kuvauskieli .................................................................................. 57 3.8.3 JavaScript .............................................................................................. 59 3.8.4 CSS-tyylimäärittelyt .............................................................................. 60 3.8.5 Projektin näkökulma ............................................................................. 63 3.9 JavaScript kirjastot..................................................................................... 63 3.9.1 JQuery ................................................................................................... 63 3.9.2 D3.js ...................................................................................................... 65 4 Projektin toteutus ................................................................................................ 66 4.1 Yleistä ........................................................................................................ 66 4.2 Aikataulu .................................................................................................... 67 4.3 Määrittelyvaihe ......................................................................................... 68 4.3.1 Yleistä .................................................................................................... 68 4.3.2 Vaatimusmäärittely .............................................................................. 68 4.3.3 Tietokannan suunnittelu ...................................................................... 71 4.3.4 Rajapintojen määrittely ........................................................................ 73 4.3.5 Sivustorakenne ja graafinen ulkoasu .................................................... 75 4.3.6 Tietoturva ............................................................................................. 81 4.4 Toteutus..................................................................................................... 81 4.4.1 Yleistä .................................................................................................... 81 4.4.2 Lähtötilanteen kartoitus ....................................................................... 82 4.4.3 Muutokset ............................................................................................ 86 4.4.4 Käytettävyys.......................................................................................... 93 4.4.5 Toteutuksen ongelmat ......................................................................... 94 4.4.6 Toteutuksen yleiskäyttöisyys ................................................................ 95 4 4.5 Testaus ....................................................................................................... 96 4.5.1 Yleistä .................................................................................................... 96 4.5.2 Moduulitestauksesta yleensä ............................................................... 97 4.5.3 Asiakassovelluksen moduulitestaus ..................................................... 97 4.5.4 Palvelinohjelmiston moduulitestaus .................................................. 101 4.5.5 Järjestelmätestaus .............................................................................. 102 4.6 Jatkokehityskohteet ................................................................................ 103 5 Pohdinta ............................................................................................................. 103 Lähteet........................................................................................................................ 106 Liitteet ........................................................................................................................ 112 5 Kuviot Kuvio 1. IoT-järjestelmän rakenne ............................................................................... 11 Kuvio 2. Scavix web frameworkin rakenne .................................................................. 14 Kuvio 3. Kosteudenmittausjärjestelmän rakenne ........................................................ 19 Kuvio 4. Etäkäyttöliittymän pääsivu ............................................................................. 22 Kuvio 5. Redmine-projektin pääsivu ............................................................................ 25 Kuvio 6. Tiedostojen hallinnan perinteinen toimintaperiaate ..................................... 29 Kuvio 7. Gitin muutostehallintatapa) .......................................................................... 31 Kuvio 8. HTTP-palvelupyynnön rakenne ...................................................................... 34 Kuvio 9. AJAX-palvelupyynnön lähetys ja vastauksen käsittely………………………………..36 Kuvio 10. x-www-form-urlencoded rakenteen syntaksi ............................................. 37 Kuvio 11. Datan lähetys GET-metodissa ...................................................................... 37 Kuvio 12. JSON-objektin luonti ..................................................................................... 38 Kuvio 13. Esimerkki JSON-rakenteesta ......................................................................... 39 Kuvio 14. Esimerkki CSV-rakenteesta ........................................................................... 40 Kuvio 15. Relaatiotietokantojen tärkeimmät joukko-operaatiot ................................. 41 Kuvio 16. MySQL tietokannan rakenne testauksessa .................................................. 46 Kuvio 17. MogoDB:n vastaava rakenne testauksessa .................................................. 46 Kuvio 18. Esimerkki Pythonin for-lauseesta ................................................................. 49 Kuvio 19. Esimerkki Tornado-sovelluksesta ................................................................. 54 Kuvio 20. HTML mallipohja ja sitä vastaava render-kutsu ........................................... 55 Kuvio 21. HTML esimerkki ............................................................................................ 57 Kuvio 22. HTML esimerkki selaimella katsottuna ........................................................ 58 Kuvio 23. HTML esimerkki DOM inspectorilla tarkasteltuna ....................................... 59 Kuvio 24. Esimerkki CSS-määrittelystä ......................................................................... 61 Kuvio 25. Esimerkki CSS:n @media-määreestä ........................................................... 62 Kuvio 26. Esimerkki kuinka jQuery helpottaa JavaScript koodausta ........................... 64 Kuvio 27. D3.js kirjastolla toteutettu interaktiivinen kuplakaavio ............................... 65 Kuvio 28. Projektin aikataulu: alkuperäinen ja toteutunut .......................................... 67 Kuvio 29. Rakeisen materiaalin kosteusmittarin vaatimukset ..................................... 69 Kuvio 30. Tietokantarakenteen alkutilanne ................................................................. 71 6 Kuvio 31. Tietokannan lopullinen rakenne .................................................................. 72 Kuvio 32. Kaksi tietokannan taulua sisältöineen. ......................................................... 73 Kuvio 33. Esimerkki ponnahdusikkunasta .................................................................... 76 Kuvio 34. Sivun ylätunniste .......................................................................................... 77 Kuvio 35. Kirjautumisen etusivu ................................................................................... 77 Kuvio 36. Pääsivu .......................................................................................................... 78 Kuvio 37. Asetusten pääsivu ........................................................................................ 79 Kuvio 38. Pääsivu projektin alussa ............................................................................... 83 Kuvio 39. Kirjautuminen projektin alussa .................................................................... 84 Kuvio 40. Rekisteröityminen projektin alussa .............................................................. 84 Kuvio 41. Ylätunnisteen linkitys HTML-tiedostoon ...................................................... 87 Kuvio 42. Esimerkki jQuery:lla toteutetusta AJAX-kutsusta ........................................ 88 Kuvio 43. Esimerkki Tornado frameworkilla toteutetusta käsittelijästä ...................... 89 Kuvio 44. Ponnahdusikkunan HTML-koodi .................................................................. 90 Kuvio 45. Ote ponnahdusikkunoita käsittelevästä JavaScript-toteutuksesta .............. 91 Kuvio 46. Chromen HTML-elementtien käsittely työkalu ............................................ 98 Kuvio 47. Chromen lähdekoodientarkastelutyökalu .................................................. 100 Kuvio 48. Esimerkki muuttujien sisällön tulostuksesta lokiin .................................... 101 Kuvio 49. Esimerkki virheilmoituksesta palvelimen lokissa ....................................... 102 Taulukot Taulukko 1. Jiran hinnasto ............................................................................................ 26 Taulukko 2. Esimerkkejä merkkijonon käsittelystä Pythonissa .................................... 49 Taulukko 3. JavaScript: HTML-elementin valinta funktiot ........................................... 60 Taulukko 4. CSS perusvalitsimet................................................................................... 61 Taulukko 5. Esimerkkejä palvelupyynnöistä ................................................................ 74 Taulukko 6: Palvelimen palvelupyyntöjen käsittelijät projektin alussa ....................... 85 7 Lyhenteet AJAX Asynchronous JavaScript and XML CSS Cascading Style Sheets CSV Comma Separated Values DOM Document Object Model GPL General Public License GSM Global System for Mobile Communications HTML HyperText Markup Language HTTP HyperText Transfer Protocol IANA Internet Assigned Numbers Authority IoT Internet of Things IP Internet Protocol IrDA Infrared Data Association JSON JavaScript Object Notation LTE Long Term Evolution MIME Multipurpose Internet Mail Extensions MQTT Message Queue Telemetry Transport NoSQL Not Only SQL OSI Open Systems Interconnection PHP Personal Home Page ReST Representational State Transfer SSL Secure Sockets Layer SQL Structured Query Language SVG Scalable Vector Graphics URI Unifrom Resource Identifier WCDMA Wideband Code Division Multiple Access WLAN Wireless Local Area Network www Word Wide Web XML eXtensible Markup Language Käsitteet Back-end: Osa tietokoneohjelmaa tai järjestelmää, jota käyttäjä ei näe tai käytä. Www-ohjelmoinnissa käsitteellä tarkoitetaan yleensä palvelinohjelmistoa, joka ei suoraan näy käyttäjälle. Big Data: Suuri setti dataa, joka on tuotettu internetissä. Se voidaan vain tallettaa. Sen tulkinta täytyy tehdä erillisillä työkaluilla. Bluetooth: Järjestelmä, jolla on mahdollista kytkeä laitteita toisiinsa radioteitse. Callback-funktio: Toiminnon suorituksen jälkeen ajettava funktio, jolla toiminnon tuottama tulos viimeistellään. Dynaaminen tietotyypitys: Muuttujille ei anneta erikseen tietotyyppiä, vaan se mää- räytyy sinne laitettavan datan perusteella automaattisesti. 8 Framework: Kokoelma ohjelmistopaketteja tai -moduuleja, jotka tarjoavat rajapinnat protokollien, kommunikointilinkkien (Socket) ja prosessien hallintaan. Front-end: Käyttäjälle näkyvä selaimella ajettava osuus web-palvelusta. Siihen voi- daan laskea kuuluvaksi ohjelmiston lisäksi graafiset elementit. Usein sitä voidaan kut- sua myös asiakassovellukseksi. Full stack: Web-palvelun kokonaisuus, johon kuuluu sekä palvelin- että asiakassovel- lus. Gantt-kaavio: Kaavio projektin tai työn aikataulusta. Se kuvaa työn vaiheet, jotka voi- daan tehdä samanaikaisesti ja vaiheet, jotka täytyy tehdä peräkkäin. Map Reduce: Uudenlainen menetelmä tiedon hakuun suuresta määrästä dataa. Tässä menetelmässä tieto jaetaan osiin ja sitä voidaan käsitellä useammalla tietoko- neella. Ohjelmointiparadigma: Ohjelmointikielen ajattelutapa, miten asiat ilmaistaan. Pilvipalvelu: Verkossa yleensä internetissä oleva palvelu, jonne dataa voidaan tallet- taa. Platform (sw): Alusta, esimerkiksi käyttöjärjestelmä tai toimintaympäristö, jonka tar- joamilla palveluilla sovellus voidaan suunnitella toimivaksi. Predikaattilogiikka: Lauselogiikan laajennus, jossa yksinkertaisia atomilauseita muo- dostetaan yksilönimistä ja predikaateista. Protokolla: Kommunikointimenetelmä, jonka avulla laitteet voivat keskustella keske- nään. Publish – subscribe pattern: Tiedon välitysmalli, jossa tieto lähetetään verkkoon koh- dentamatta vastaanottajaa. Vastaanottaja voi tilata tietoa ilmoittautumalla vastaan- ottajaksi. Regular expression: Säännöllinen lauseke, yksinkertainen merkkijonokieli, jolla hae- taan vastaavuuksia merkkijonosta. Socket: Kaksisuuntainen verkon yli muodostettava päästä päähän yhteys kahden oh- jelmiston välillä. Typografia: Dokumentin painoasu tai muu näkyvä esitysasu. 9 1 Työn tausta 1.1 Toimeksiantaja Pehutec Oy on Oulussa ja Ylivieskassa toimiva tietoliikenteen ja sulautettujen järjes- telmien parissa toimiva yhtiö (PehuTec-Company 2016). Pehutec Oy ja Lewel Group, jonka suurin omistaja PehuTec on, muodostaa Oulun alueen suurimman yksityisen teknologia-alan toimijan. Suomen tasollakin se on yksi suurimmista. Työntekijöitä yh- tiöissä on kaiken kaikkiaan n. 70. Toimipisteitä on edellä mainittujen lisäksi Kuopiossa ja Helsingissä. (PehuTec-Merger 2015.) PehuTec on perustettu vuonna 2010. Aluksi se toimi pelkästään ohjelmistokehittä- jänä. Ensimmäisinä vuosina vetojuhtana olivat tietoliikenneohjelmistot, jotka ovat edelleenkin tärkeä mutta eivät ainoa toimintasegmentti. Toimintaa on laajennettu siten, että tällä hetkellä on mahdollista toimittaa kokonaisuuksia, jotka sisältävät tuotteiden mekaniikka-, laitteisto- ja ohjelmistosuunnittelun. (PehuTec-Company 2016.) PehuTeckin referenssit kertovat monipuolisesta toiminnasta. Niitä ovat mm. Finn- dent hammaslääkärin tuoli, kasvihuoneen tarkkailujärjestelmä, tietokoneella ohjattu kamera sekä 3G- ja 4G-verkkojen kehitys. Näitä on kehitetty yhteistyökumppaneiden kanssa. Lisäksi on kehitetty myös omia tuotteita. Yksi näistä on Trace Analyzer. Sen avulla on mahdollista avata eri lähteistä ja erilaisissa muodoissa olevia lokitiedostoja samanaikaisesti tarkkailtavaksi. (PehuTec-References 2016.) PehuTec kehittää parhaillaan rakeisen materiaalin jatkuvatoimista kosteusmittaria. Sen voi liittää internettiin ja sitä on mahdollista etäkäyttää web-sovelluksen kautta. Lisäksi PehuTec osallistuu parhaillaan useiden IoT-tuotteiden tuotekehitykseen. Ne eivät kuitenkaan ole vielä julkisia. 1.2 Tavoitteet Työn tavoitteena oli kehittää toimiva etäkäyttöympäristö eli pilvipalvelu PehuTec PTGM-16 rakeisen materiaalin kosteusmittarille. Työ sisältää palvelin- ja asiakasohjel- 10 miston suunnittelun, toteutuksen ja yksikkötestauksen. Käytännössä kyseessä on jär- jestelmän full stack -toteutus. Tässä työssä ohjelmistoa kutsutaan etäkäyttöliitty- mäksi. Järjestelmästä pyrittiin tekemään joustava ja helposti muunneltavissa oleva ympäristö, jota on mahdollista käyttää myös muissa vastaavissa järjestelmissä. Ohjel- miston vaatimuksien pohjana käytettiin mittariin kuuluvan näyttöyksikön toimintaa. 2 Toimintaympäristö 2.1 Tyypillinen IoT-järjestelmän rakenne 2.1.1 Yleistä IoT-järjestelmät ovat tyypillisesti hyvin erilaisia mutta kuitenkin samanlaisia. Vaikka järjestelmien käyttötarkoitus eroaa toisistaan todella paljon, niiden perusrakenne on samankaltainen. IoT-käsitteiden monimutkaisuutta lisää vielä se, että laitetoimittajat käyttävät järjestelmän osista erilaisia nimityksiä. Tämä kertookin, että IoT on vielä kä- sitteenä uusi ja siihen liittyvät termit eivät ole vakiintuneet. Kuviossa 1 esitellään tyy- pillisen IoT-järjestelmän rakenne. Kuviosta voi erottaa seuraavat osat: 1. Laitteet (Product) 2. Tiedonsiirto (Connectivity) 3. Pilvipalvelut (Product cloud) 4. Käyttäjien hallinta, tietoturva ja laitehallinta 5. Ulkoiset tiedonlähteet ja järjestelmät 2.1.2 Laitteet eli tuotteet Kyseessä on IoT-järjestelmän heterogeenisin osa. Laitteiden käyttötarkoitus ja toteu- tustapa vaihtelevat hyvin paljon, selvästi enemmän kuin järjestelmän muissa osissa. Sen vuoksi yhteistä käsitettä, joka sopisi kaikille tuotteille, on hankala löytää. Tuote- nimitys on yksi parhaista. Kaikki IoT-tuotteet ovat käytännössä sulautettuja järjestelmiä, jotka koostuvat lait- teistosta ja siihen sulautetusta ohjelmistosta. Prosessorit ovat kehittyneet viime ai- koina hyvin pieniksi ja ohuiksi. Pienuus tarkoittaa usein samalla vähäistä virrankulu- tusta, joka on myös tärkeä suure IoT-laitteistossa. (Maailman ohuin ARM-prosessori? 2015.) 11 Kuvio 1. IoT-järjestelmän rakenne (Heppelmann, Porter 2014.) Laitteisiin liittyvät ohjelmistot toteutetaan usein laiteläheisillä ohjelmointikielillä, ku- ten C-kielellä. Ohjelmointi ei poikkea perinteisestä sulautettujen järjestelmien ohjel- mointimenetelmistä. Millaisia IoT-tuotteet sitten ovat? Yksinkertaisimmillaan IoT-tuote saattaa olla paino- nappi, jolla on jokin yksinkertainen toiminto. Tällainen on esimerkiksi AWS IoT But- ton. Painonapille voi ohjelmoida haluamansa toiminnon. Sen voi esimerkiksi ohjel- moida käynnistämään tai pysäyttämään jonkin laitteen. (AWS IoT Button 2016.) Hyvin usein IoT-tuotteet sisältävät antureita ja muita tiedonkeräämiseen tarkoitet- tuja laitteita. Tyypillisiä mitattavia suureita ovat lämpötila ja kosteus. Näitä saatetaan mitata mitä erilaisimmista kohteista, esimerkiksi ilmasta, kiinteästä materiaalista, ra- kennuksen rakenteista yms. Asuntovuokrayhtiö VVO esimerkiksi mittaa lämpötilaa ja kosteutta asunnoissaan Espoossa (VVO otti IoT-anturiverkot Espooseen 2016). 12 Raskaimmillaan IoT-laitteet ovat osana raskaan teollisuuden koneissa. Niiden avulla kerätään tietoa koneen toiminnasta. Tällaisessa järjestelmässä antureita saattaa olla paljon, mutta yksittäisen anturin hinta ei saa olla korkea. Sen vuoksi perinteisiä teolli- suuden antureita ei voi käyttää. Mittausdataa käytetään usein ennakkohuollon suun- nittelun apuna. (Etävalvonta varmistaa toimintakunnon 2014.) 2.1.3 Tiedonsiirto IoT-laitteissa täytyy olla erillinen tiedonsiirtomoduuli, jolla se on yhteydessä ulko- maailmaan. Se voi olla joko laitteen yhteyteen integroitu tai erillinen tukiasema, jo- hon laitteet ovat yhteydessä erilaisilla lyhyen kantaman menetelmillä. Käytössä voi olla kiinteä fyysinen yhteys tai langaton menetelmä, kuten infrapunasäteily (esim. IrDA), radioaallot (esim. WLAN, Bluetooth tai ZigBee) tai magneettikenttä (esim. Li- berty Link) (Honkanen 2011, 1-5). Internet-yhteys täytyy järjestää laitteiden tiedonsiirtomoduulille saakka. Tiedonsiir- toon käytetään pääasiassa internetprotokollaa (IP). Usein data siirretään IP-verkon yli ReST (Representational State Transfer) -arkkitehtuurin mukaisen rajapinnan kautta. Sen yli tietoa siirretään pääasiassa HTTP-protokollalla. ReST-arkkitehtuuri ja HTTP- protokolla ovatkin kehittyneet monelta osin toistensa rinnalla. (Pihlajaniemi 2012, 2- 3.) ReST-arkkitehtuuri on asiakas palvelin tyyppinen ratkaisu. Siinä asiakas tekee palvelu- pyyntöjä palvelimelle, joka lähettää vastauksen. Tässä mallissa on tärkeää, että pal- velupyynnöillä on lähettäjä ja vastaanottaja eli pyyntö kohdistuu aina tiettyyn palve- luun. Palvelupyynnöt yksilöidään yksinkertaisilla URI- (Unifrom Resource Identifier) tunnisteella. Pyynnöt lähetetään HTTP GET- tai POST-metodeilla palvelimelle, joka lä- hettää vasteessa pyydetyn datan tai kuittauksen. Informaatio voi olla esimerkiksi XML- tai JSON-muodossa. ReST-arkkitehtuurissa jokainen pyyntö on tilaton, eli palve- limelle tulevien pyyntöjen järjestyksellä ei ole merkitystä. Toisin sanoen palvelimelle ei tallenneta yhteyden tilaa vaan jokainen pyyntö on itsenäinen ja se hoidetaan ker- ralla loppuun saakka. (Pihlajaniemi 2012, 2-4.) IoT:n käyttöön on kehitetty myös MQTT-protokolla. Sekin siirretään IP-protokollan välityksellä. MQTT tukee julkaise - tilaa-arkkitehtuuria (publish - subscribe pattern). 13 Tämän mallin mukaan tiedon lähettäjä ei tiedä vastaanottajaa. Viesti lähetetään ja siitä kiinnostuneet vastaanottajat käsittelevät sen. MQTT on yksinkertainen ja keveä tiedonsiirtoprotokolla. Sen tavoitteena on minimoida tiedonsiirtokanavan kaistanle- veyden käyttö. (Lampkin Leong Olivera Rawat Subrahmanyam Xiang 2012, 6 – 8.) IoT-järjestelmien tiedonsiirtoon OSI-mallin alimmilla kerroksilla on tarjolla runsaasti vaihtoehtoja. Yksinkertaisimmillaan laitteet käyttävät tarjolla olevaa ethernet- tai WLAN-verkkoa. Myös GSM, WCDMA tai LTE ovat mahdollisia. IoT-tarpeisiin on kehi- tetty LoRa-radio. Alun perin se on suunniteltu laitteiden ja tukiaseman väliseen tie- donsiirtoon. Sen kantama on havaittu hyväksi, joten tällä hetkellä on tarjolla kaupalli- sia LoRa-verkkoja (LoRa-radioverkko kantaa kauas 2016). 2.1.4 Pilvipalvelu Tämä osuus on IoT-järjestelmän ydin. Perinteisiin järjestelmiin verrattuna palvelun käyttäjä saa lisäarvoa nimenomaan tästä osiosta. Pilvipalvelu mahdollistaa tietojen tarkastelun missä tahansa. Riittää, että internet-yhteys on saatavilla. Raakadatasta on mahdollista koostaa raportteja, jolla voidaan havainnollistaa toimintaa uusilla ta- voilla. Pilvipalvelussa on mahdollista yhdistää eri lähteistä kerättyä dataa. Hyvillä analysointimenetelmillä on mahdollista ennakoida mahdollisia tulevia ongelmia jo ennen vahingon syntymistä. (Yritysjohdon opas IoT:n ja teollisen internetin hyödyn- tämiseen 2016.) IoT-järjestelmän pilvipalvelu voidaan jakaa neljään osaan, jotka ovat seuraavat: 1. Tietokanta johon laitteilta tuleva raakadata talletetaan. 2. Pilvipalvelun alusta eli platform-ohjelmisto. 3. Tietojen analysointi erilaisten sääntöjen avulla. 4. Sovellukset analysoidun datan tarkasteluun. (Heppelmann, Porter 2014) Tietokanta IoT-laitteilta tuleva raakadata (big data) talletetaan tietokantaan. Sen muoto vaihte- lee hyvin paljon. Numeerisen datan lisäksi talletettavaksi voi tulla teksti-, ääni-, kuva- ja videotallenteita. Sitä kutsutaan rakenteettomaksi dataksi. Joissakin markkinointi- materiaaleissa kerrotaan, että jopa 95% datasta olisi rakenteetonta. (Erinomaista lii- ketoimintaa Big Datan avulla 2013, 2.) 14 Tietokannat jaetaan kahteen ryhmään: SQL-kieleen pohjautuviin relaatiotietokantoi- hin ja muihin ei SQL (NoSQL) -tietokantoihin. Relaatiotietokannoissa data sijoitetaan tietyn tyyppisiin tauluihin, joilla on ennalta määrätty rakenne. Jokainen tietue sisältää yksilöidyn pääavaimen, jolla siihen voidaan viitata yksiselitteisesti. (Haverinen 2016, 3.) Muissa tietokantatyypeissä käytetään datan järjestämiseen erilaisia malleja. Kaksi suosituinta ovat: 1. Dokumenttisuuntautunut tietokanta, jossa tieto talletetaan doku- mentteihin. Niiden rakenne on ennalta määrätty mutta datan sisältöön ei oteta kan- taa. 2. Avain arvo -tietokantaan talletetaan tietoa avain-arvopareina. (Haverinen 2016, 4.) Platform Pilvipalvelun alusta eli platfom on palvelinohjelmiston perusta, joka tarjoaa rajapin- nat protokollien, kommunikointilinkkien (socket) ja prosessisäikeiden hallintaan. Yleensä palvelimilla käytetään valmiita ohjelmointikieleen sidottuja ns. kehys- eli fra- mework-paketteja, jotka tarjoavat kyseiset palvelut. Kuviossa 2 on Scavix web fra- meworkin rakenne, josta voi havaita edellä mainitut osat. Kuvio 2. Scavix web frameworkin rakenne (Buenger 2014) 15 Näiden pakettien käyttö helpottaa palvelinohjelmiston toteutusta huomattavasti. Tarjolla olevien framework-pakettien määrä on suuri, joita pelkästään Python-kielelle on tarjolla kymmeniä. (Vosloo 2016.) Platformiin kuluu frameworkin lisäksi myös palvelinohjelmiston kehittäjän suunnitte- lemat perustason toiminnot. Näitä ovat mm. tietokantakyselyt, palvelupyynnöt ja nii- den vastauksien lähetys, prosessoidun datan liittäminen vastauksiin yms. Lisäksi plat- form sisältää datan käsittelyyn liittyvät peruspalvelut, kuten dataformaatin muutta- minen, datan purku ja pakkaus. Kaikissa näissä toiminnoissa voidaan käyttää apuna frameworkin tai ohjelmointikielen sisältämien kirjastojen tarjoamia palveluja. Analysointi Big datan analysointi on IoT-järjestelmän käsitteellisin osa. Ennen kuin dataa voidaan analysoida, täytyy päättää algoritmit millä sitä käsitellään. Algoritmien valinta on oleellinen osa järjestelmän toimintaa. Oikeilla algoritmeilla saadaan täsmällistä tietoa järjestelmän käyttäytymisestä. Kun raakadataa on talletettu riittävästi, valittuja algo- ritmeja on mahdollista tarkentaa paremman lopputuloksen saavuttamiseksi. Analy- soinnin avulla saadaan erityistä lisäarvoa, jos sen avulla voidaan yhdistää monesta lähteestä tulevaa dataa. Analysoitava data on kuitenkin tunnettava ennen kuin algoritmi voidaan valita. Big data jaetaankin viiteen päätyyppiin, jotka ovat rakenteellinen, osittain rakenteelli- nen, rakenteeton, web ja reaaliaikainen data. (Russom 2011, 17-18). Datatyyppi vai- kuttaakin ratkaisevasti siihen millaisia analysointi algoritmeja voidaan käyttää. Yleisin analysoitava datatyyppi on rakenteellinen eli strukturoitu data. Tällaista dataa on kerätty ennenkin eri prosesseista ja se on talletettu perinteisesti relaatiotietokan- toihin. Suuren datamäärän käsittelyssä ratkaisevassa asemassa ovat tietokantaky- selyt, joilla dataa haetaan tietokannasta. Niiden avulla on mahdollista rajata merkit- tävä osa mittausdatasta käsittelyn ulkopuolelle. Osittain rakenteellinen tai kompleksinen data sisältää jo suurempia datakokonaisuuk- sia. Tyypillisesti data esitetään XML- tai JSON-muodossa. Tällaiset kokonaisuudet saattavat sisältää monimutkaisiakin tietorakenteita. Silloin sopivan algoritmin valinta on jo haastavampaa. 16 Rakenteeton data sisältää useimmiten tekstiä. Se voi sisältää myös kuvia, videoita tai äänitteitä. Tämän tyyppisen datan määrä kasvaa jatkuvasti. Datan analysointi on erit- täin haastavaa. Hakukoneyhtiöt ovatkin kehittäneet uudenlaisia hakualgoritmeja. Näitä ovat mm. Googlen Map Reduce ja Apachen Hadoop, joka on itseasiassa kehitty- neempi versio Googlen Map Reduce menetelmästä. Tekstiä sisältävästä datasta voi- daan esimerkiksi laskea sanojen esiintymismääriä ja tehdä sen perusteella päätelmiä sisällöstä. (Nieminen 2013, 18; Laukkanen 2014, 4-6.) Web-datalla tarkoitetaan lähinnä kahdesta lähteestä kerättyä dataa. Se koostuu so- siaalisen median sisällöistä ja netin lokitiedostoihin kirjatuista klikkauspoluista. (Rus- som 2011, 18.) Reaaliaikaiseen dataan lasketaan monesta lähteestä kertyvää dataa. Niitä ovat tapah- tumista (esim. Sää), paikkatieto (GPS) ja erilaisten koneiden tuottama data. (Russom 2011, 18) Analysointiohjelmisto on kaiken kaikkiaan hyvin läheisesti kytköksissä platform-ohjel- miston kanssa. Tietokantakyselyt ja datan muuntaminen ovat ratkaisevassa asemassa tiedon analysoinnissa. Datan pääasiallinen analysointi tehdään useimmiten palveli- mella, koska turhaa dataa ei kannata siirtää internetin yli asiakasohjelmalle. Sovellukset Kyseessä on yleensä asiakassovellus, joka ajetaan käyttäjän päätelaitteella. Sovelluk- set viimeistelevät analysoidun datan visuaaliseen muotoon, jota käyttäjä voi helpom- min havainnoida. Numeerinen data voidaan esittää käyrinä ja erilaisina kaavioina. Monimutkaisemman datan visualisointi onkin hankalampaa. Tarjolla on kuitenkin val- miita havainnollistamista helpottavia kirjastoja. Sovelluksia ajetaan tavallisesti internet-selaimella. Matkapuhelimissa käytetään puo- lestaan enimmäkseen niitä varten suunniteltuja sovelluksia. Yksinkertaisimmillaan data tulee HTML-muodossa suoraan palvelimelta. Useimmiten se ei kuitenkaan riitä. Sivun sisältöä täytyy päivittää reaaliajassa. Myös graafinen visualisointi tehdään usein vasta asiakassovelluksessa. Silloin ohjelmointikielenä on yleensä JavaScript. Sen päälle onkin kehitetty runsaasti erilaisia kirjastoja, joiden avulla helpotetaan sovellus- ten ohjelmointia ja graafisten esitysten tekoa. (Jouhtimäki 2009, 7.) 17 Sovelluksien käytettävyydellä on suuri merkitys. Hyvän käyttöliittymän avulla käyttäjä pystyy keskittymään tehtäväänsä ilman, että hänen täytyy miettiä, miten tehtävä hoidetaan. Hyvin suunnitellussa käyttöliittymässä toiminnot hoidetaan luontevasti ja helposti. Käyttäjän tekemiin toimenpiteisiin on tultava vaste välittömästi. Myös vir- hetilanteet on hoidettava joustavasti. (Jouhtimäki 2009, 27-29.) 2.1.5 Käyttäjien hallinta, tietoturva ja laitehallinta Nämä kolme osa-aluetta liittyvät kaikki IoT-järjestelmän turvalliseen käyttöön. Lait- teiden ja käyttäjien tunnistaminen täytyy olla luotettavaa. On tärkeää, että järjestel- mään voivat kytkeytyä vain siihen kuuluvat laitteet ja käyttäjät. Laitteen tunnistamiseen voidaan käyttää sarjanumeroa, IMEI, MAC tai muuta yksilöl- listä tunnistetta. Useimmiten se on riittävä tieto. Sarjanumeroon on mahdollista li- sätä varmistussumma paperilaskuissa käytettyjen viitenumeroiden tapaan. Kriittisissä järjestelmissä voidaan käyttää lisäksi laitevarmennetta. (Simula 2014, 5-8.) Järjestelmään kirjautuvat käyttäjät täytyy myös tunnistaa luotettavasti. Järjestel- mässä on oltava luotettava mekanismi, jolla varmistetaan, minkä laitteen tietoja käyttäjällä on oikeus käyttää. Tavallisin tunnistustapa on käyttäjätunnus salasana pari. Vahvassa tunnistuksessa käytetään kahta erilaista tapaa käyttäjän tunnistami- seen. Tällainen voisi esimerkiksi olla käyttäjätunnus salasana pari ja sormenjälki. (Si- mula 2014, 5-8.) Järjestelmän internet rajapinnat täytyy suojata mahdollisuuksien mukaan. Laitteiden ja palvelimen välisen internet-yhteyden suojaus voi joissain tapauksissa olla haasta- vaa. Kaikkein keveimmät IoT-laitteistot eivät välttämättä mahdollista tietoturvaohjel- mistojen asennusta ja siten salatun yhteyden käyttöä. Jos yhteyttä ei voida salata koko putken läpi, on pyrittävä siihen, että salaus tehdään niiltä osin mitä se on mah- dollista. Onneksi uusien IoT:n käyttöön tarkoitettujen protokollien kehityksessä on yleensä huomioitu myös tietoturva. (Kaartinen, Nokela, Verronen 2016, 8.) Palvelimen ja asiakassovelluksen välisen yhteyden suojaus on helpompaa. Tässä ta- pauksessa suojaus on mahdollista hoitaa SSL-tekniikalla, kuten se HTTPS-yhteydellä tavallisestikin hoidetaan. 18 2.1.6 Järjestelmän ulkopuolelta tuleva data Monelle mittausjärjestelmälle lisäarvoa tuottaa järjestelmän ulkopuolelta haettu data. Esimerkiksi lämpötilaa ja kosteutta mittaavalle järjestelmälle lisäarvoa saadaan mittaushetken säätiedoilla. Kun nämä tiedot on talletettu, säätilan vaikutusta mit- taustulokseen voidaan arvioida. Mittausdataa täytyy kuitenkin olla saatavilla riittä- västi. Paikkatietoa käsittelevälle järjestelmälle antaa lisäarvoa muualta haetut kartta- pohjat, johon paikkatieto voidaan sijoittaa. Nykyään monet julkiset rekisterit ovat vapaasti käytettävissä. Ilmatieteenlaitos on mm. avannut runsaasti aineistoja vapaaseen käyttöön (Avatut ja avattavat tietoai- neistot 2016). Maanmittauslaitos on tehnyt samoin. Käytännössä lähes kaikki merkit- tävä aineisto on vapaasti käytettävissä (Avoimien aineistojen tuoteluettelo 2016). Lii- kennevirasto on avannut puolestaan junaliikenteeseen liittyvää dataa julkiseen käyt- töön (RATA.DIGITRAFFIC.FI. 2016). 2.2 Kosteudenmittausjärjestelmän yleiskuvaus 2.2.1 Yleistä Työn kohteena olevassa rakeisen materiaalin kosteusmittarissa käytetään edellä esi- tettyä IoT-järjestelmän perusrakennetta. Siitä on löydettävissä samat perus osat. Niitä käsitellään tarkemmin myöhemmin tässä luvussa. Järjestelmä mittaa kosteuden ja lämpötilan rakeisesta materiaalista. Mittaus on suunniteltu erityisesti materiaalin kuivausta varten. Se tukee eräajoa. Prosessi voi- daan automaattisesti pysäyttää, kun tavoitekosteus on saavutettu. Samoin järjestel- mällä voidaan ohjata kuivauksen jälkeinen jäähdytysvaihe. Kuviossa 3 on esitetty jär- jestelmän rakenne. Järjestelmässä on käytetty perinteisiä tiedonsiirron menetelmiä. Uusia IoT:n käyttöön suunniteltuja menetelmiä ei ole käytetty. Järjestelmään ei ole myöskään suunniteltu 19 talletettavaksi dataa ulkopuolisista palveluista. Yksi mahdollisuus olisi säätietojen tal- lennus mittauspisteen lähimmältä mittausasemalta. Sen perusteella olisi mahdollista arvioida sään vaikutusta kuivausprosessiin. Kuvio 3. Kosteudenmittausjärjestelmän rakenne 2.2.2 Mittari Perusrakenteessa esitettyä tuotetta kutsutaan tässä järjestelmässä mittariksi. Ky- seessä on itsenäinen laite, joka pystyy toimimaan ilman internet-yhteyttä. Mittarin yhteydessä on erillinen näyttöyksikkö, jonka kautta järjestelmää voidaan käyttää sa- maan tapaan kuin pilvipalvelussa olevalta etäkäyttöliittymältä. Sen vuoksi mittaus- data analysoidaan pääosin jo mittarissa. Se lähettää tieota mittauksen tilasta, kuten kuivausvaiheen päättymisestä, tekstiviestinä käyttäjän ilmoittamaan puhelinnume- roon. Mittarin sulautettu ohjelmisto on toteutettu C-kielellä perinteiseen sulautetun ohjelmiston toteutusperiaatteilla. Ohjelmisto lukee laitteistolta anturin 20 mittaustiedot. Se prosessoi mittausdatan eisitettävään muotoon ja täyttää datan HTTP-palvelupyyntöihin, jotka lähetetään eteenpäin modeemin välityksellä. 2.2.3 Tiedonsiirto Tiedonsiirto hoidetaan GSM- tai WCDMA-modeemilla, joka on koteloitu mittarin kanssa samaan koteloon. Sen vuoksi jokainen mittari on erikseen yhteydessä inter- nettiin. GSM:n ja WCDMA:n tiedonsiirtokapasiteetti riittää täyttämään mittarin tie- donsiirtotarpeet. GSM valittiin käyttöön, koska on mahdollista, että mittaria käyte- tään ympäristössä, jossa muuta radioverkkoa ei ole tarjolla. Tarvittaessa WCDMA voi- daan ottaa nopeasti käyttöön. Data siirretään ReST-rajapinnan yli HTTP-protokollalla. Data siirtyy mittarilta palveli- melle POST-metodilla tehdyillä palvelupyynnöillä. Dataa haetaan puolestaan palveli- melta GET-palvelupyynnöillä. Datamäärien laskennassa todettiin, että GSM-yhteyden kaistanleveys riittää järjestelmän tiedonsiirtotarpeisiin, kun siirrossa käytetään HTTP- protokollaa. Sen vuoksi MQTT:n käyttöönottoa ei edes harkittu. Mittarin internet-yhteys ei ole jatkuvasti aktiivisena. Mittari avaa yhteyden etäkäyt- töliittymään tarvittaessa. Palvelimella ei ole mahdollisuutta ottaa yhteyttä yksittäi- seen mittariin. Sen vuoksi mittari käy säännöllisin väliajoin tarkistamassa, onko mitta- rin asetuksia päivitetty etäkäyttöliittymän kautta. 2.2.4 Pilvipalvelu Pilvipalvelua kutsutaan tässä projektissa etäkäyttöliittymäksi. Sinne toteutettiin sa- mankaltainen käyttöliittymä kuin mittarin yhteydessä olevalla näyttöyksiköllä. Etä- käyttöliittymän lopulliseen toteutukseen lisättiin myös toimintoja, joita ei mittarin näyttöyksiköllä ole lainkaan. Tällaisia ovat mm. mittaustulosten näyttäminen kaa- viona, raportti kuivauksen suorituksesta, sekä hälytys- ja tilatietojen näyttäminen. Osaa toiminnoista parannettiin joustavan käytettävyyden takaamiseksi. Lopullisen sovelluksen ulkonäköäkin muutettiin parempien muokkausmahdollisuuksien ansi- osta. Tietokantana on MySQL-pohjainen relaatiotietokanta, jonne talletetaan pääasiassa numeerista tietoa. Kosteuden ja lämpötilan lisäksi mittausdatan mukana talletetaan 21 mittauksen raakadataa, jonka perusteella kosteus on laskettu. Lisäksi tietokantaan talletettaan mittarin asetukset ja tilamuutokset. Raakadata sisältää anturilta mitatun raaka arvon lisäksi mittausten kompensointiar- voja ja mittarin kalibrointiarvoja. Näiden arvojen perusteella voidaan tutkia ja arvi- oida kosteuden laskennassa käytettyjen algoritmien toimintaa. Tarvittaessa algorit- meja ja kosteusarvojen laskentaan käytettyjä materiaalikohtaisia käyriä voidaan kor- jata. Palvelimen pohjana on Tornado framework. Se on yksi Python-kielellä toteutetuista alustoista. Se tarjoaa valmiit funktiot ReST-rajapinnan käyttöön. Tietokantarajapintaa käytetään Dataset-nimisellä Python kirjastolla. Se helpottaa tietokannan käyttöä. Tie- tokantahakujen tekoon ei tarvita yleensä SQL-hakukomentoja. Palvelinsovellus pys- tyy muokkaamaan asiakassovellukselle lähetettävien HTML-tiedostojen sisältöä en- nen lähetystä Tornado frameworkin tarjoamilla välineillä. Datan analysointia tehdään osittain mittarilla ja osittain käyttäjän sovelluksessa. Kos- teus ja lämpötila prosessoidaan raaka-arvoista jo mittarilla. Talletetusta mittausda- tasta prosessoidaan asiakassovelluksessa kaavioita mittarin tilatietojen perusteella. Kaaviot generoidaan JavaScript pohjaisella D3.js-kirjastolla. Asiakas sovellusta käytetään tavallisella internetselaimella. Sen toteutuksessa on käy- tetty perinteisiä www-tekniikoita eli HTML:n, CSS:n ja JavaSciptin yhdistelmää. Ja- vaScriptin kirjoituksen helpottamiseen on käytetty JQuery-kirjastoa. JavaScript osuu- det täydentävät palvelimelta haettua HTML-sisältöä. Sen avulla voidaan päivittää si- vustoa lataamatta koko sivuston sisältöä uudelleen. Silloin uutta dataa haetaan pal- velimelta AJAX-rajapinnan kautta. Kuviossa 4 on sovelluksen pääsivu. Siinä näkyy kuivausprosessin keskeisimmät tiedot. Siinä on näkyvissä kuivausprosessin tilatieto, viimeksi vastaanotettu kosteus ja läm- pötila, mittauskäyrä viimeisen 24 tunnin ajalta, sekä alimpana hälytysnäyttö, joka kertoo hälytysten lisäksi tilamuutosten ajankohdat. Ylätunnisteessa on linkit uloskir- jautumiseen, asetuksiin ja raportteihin. Viimeisenä on pelkästään pääkäyttäjille nä- kyvä linkki pääkäyttäjän toiminnot sivulle. 22 Kuvio 4. Etäkäyttöliittymän pääsivu 2.2.5 Laitteiden ja käyttäjien hallinta sekä tietoturva Käyttäjien kirjautuminen on toteutettu käyttäjätunnuksella ja salasanalla. Vahvem- paa tunnistusta ei käytetä. Käyttäjän antama salasana salataan ennen tietokantaan talletusta. Käyttäjä voi tilata unohtuneen tunnuksen tai salasanan tilalle uuden il- moittamalla palveluun sähköpostiosoitteensa tai käyttäjätunnuksensa. Uusi salasana lähetetään järjestelmään talletettuun sähköpostiosoitteeseen. Laitteiden hallintaan käytetään mittarin sarjanumeroa. Sitä käytetään tunnisteena kaikissa mittariin kohdistuvissa palvelupyynnöissä. Käyttäjän täytyy antaa sarjanu- mero palveluun rekisteröitymisen yhteydessä. Ilman sitä rekisteröityminen ei on- nistu. Järjestelmän internet-yhteydet suojataan SSL-sertifikaatilla perinteiseen tapaan. Sen avulla pystytään salaamaan myös mittarin ja etäkäyttöliittymän välinen yhteys. 23 3 Projektin tekniikat ja työkalut 3.1 Yleistä Tässä luvussa käsitellään projektiin valittuja tekniikoita ja työkaluja. Suurin osa teknii- koista oli valittu jo etäkäyttöliittymän prototyypin suunnittelun aikana. Työssä ei si- ten ollut mahdollisuutta vaikuttaa läheskään kaikkiin valintoihin. Tässä luvussa tutki- taan kuitenkin mitä vaihtoehtoja valituille työkaluille olisi ollut tarjolla. Mahdollisuuk- sien mukaan arvioidaan, oliko työkalun valinta onnistunut ja käytettiinkö sitä järke- västi. 3.2 Projektinhallinta Kun ohjelmistoprojektien koko kasvaa, niiden hallinta muuttuu haastavammaksi. Niissä ilmenee monenlaisia ongelmia, joita ovat mm. myöhästymiset, laadun huono- neminen, kulujen kasvu ja jopa projektien epäonnistumiset. Ohjelmistoprojektin hal- lintaa vaikeuttaa lisäksi tuotteen luonne, joka ei ole niin konkreettinen kuin perintei- sissä tuoteprojekteissa. (Taina 2005, 1-2.) Näihin tarpeisiin on kehitettykin monenlaisia ohjelmistoja. Käytännössä kaikkien ny- kyaikaisten ohjelmistoprojektien hallintaan valitaan projektinhallintatyökalu. Uusim- mat ovat web-käyttöliittymällä varustettuja, jolloin niitä on periaatteessa mahdollista käyttää missä tahansa. Projektinhallintasovellukset sisältävät monenlaisia ominaisuuksia. Perustoiminnalli- suuteen kuuluu mm. projektin tietojen-, prosessien-, aikataulujen-, laadun- ja resurs- sienhallinta. Projektin tietojen hallintaan kuuluu projektin perustietojen lisäksi vaatimusten hal- linta. Perustietoihin pystyy vähimmillään kirjaamaan projektin nimen. Useimmissa ohjelmissa voi lisäksi antaa projektipäällikön nimen sekä määritellä projektin osak- kaat, jotka voivat seurata projektin tilannetta. (Kantola 2013, 24.) Projektinhallintatyökalut mahdollistavat ohjelmiston vaatimusten kirjaamisen järjes- telmään. Siellä vaatimuksille voidaan laittaa tilatieto, jonka perusteella on mahdol- lista seurata vaatimusten käsittelyn etenemistä projektissa. Parhaissa ohjelmissa on 24 mahdollista liittää projektissa käytävä keskustelu projektinhallintatyökaluun. (Kantola 2013, 25) Projektin seuranta työkaluilla voidaan aikatauluttaa ja seurata tehtävien edistymistä. On mahdollista, että sovellus voi lähettää ilmoituksia sähköpostiin projektin tapahtu- mista, kuten uusien tehtävien lisäämisestä tai niiden valmistumisesta. Parhaissa työ- kaluissa on mahdollista seurata projektin edistymistä lähdekooditasolla ja siihen pys- tytään lisäämään projektin etenemisen tarkastuspisteitä. (Kantola 2013, 25-26.) Tehtävien hallintaan kirjataan projektissa tehtävät työt. Ne voidaan määritellä sinne vaatimusten perusteella. Tehtävälle voidaan antaa tekijä ja valmistumisajankohta. Tekijä merkitsee tehtävän tehdyksi sen valmistuttua. Paremmissa ohjelmissa on mah- dollista priorisoida tehtäviä tärkeyden mukaan. Joissakin ohjelmistoissa on mahdol- lista hoitaa myös vikailmoitusten ja ongelmien hallintaa. (Kantola 2013, 26.) Resurssien hallinnassa käyttäjille on mahdollista antaa erilaisia oikeuksia. Osalle käyt- täjistä riittää pelkät lukuoikeudet. Muokkausoikeudet voidaan antaa vain niille henki- löille, joilla on tarve muuttaa tietoja. Projektin eri vaiheissa syntyneitä tiedostoja on myös mahdollista tallettaa projektityökalun tiedostojenhallintaan. Silloin ne säilyvät tallessa paremmin kuin tekijöiden sähköposteissa. Useimmiten dokumentaatiota on kuitenkin helpompi säilyttää projektin versionhallinnassa. (Kantola 2013, 27.) Projektinhallintatyökalut lisäävät kuitenkin helposti projektin byrokratiaa. Varsinkin silloin, kun kaikki työtiedostot ja keskustelut on tarkoitus tallettaa projektinhallin- taan. Projektinhallinnassa onkin huomioitava, ettei se lisää liikaa tekijöiden työtaak- kaa. Jos näin käy, pahimmassa tapauksessa tarpeellinenkin tieto jää kirjaamatta. 3.2.1 Redmine Redmine on joustava web-käyttöliittymällä varustettu projektinhallintatyökalu. Se voidaan asentaa käyttäjän omalle työasemalle tai palvelimelle, jolloin se on koko työ- ryhmän käytettävissä pilvipalveluna. Se on kirjoitettu Ruby:lla. Se on avoimen lähde- koodin tuote ja se on julkaistu GNU GPL -lisenssillä. Tarvittaessa lähdekoodia saa muuttaa ja kehittää omien tarpeiden mukaiseksi. (Kantola 2013, 29.) 25 Siitä löytyy kaikki yleisimmät projektihallintaohjelmistojen ominaisuudet. Projektille voidaan määritellä kotisivu, jolla se esitellään. Projektin käyttöön voidaan valita käyt- töliittymäkomponentteja, kuten wiki, keskustelupalsta ja kalenteri. (Kantola 2013, 29.) Kuviossa 5 on esimerkkinäkymä Redmine-työkalusta. Kyseessä on projektin pääsivu. Siitä voi havaita, että projektille on luotu seuraavat mahdolliset tehtävät: vika, omi- naisuus, ominaisuus ehdotus, vaatimus, työ dokumentti ja päätason vaatimus. Kuvio 5. Redmine-projektin pääsivu Vaatimusmäärittelyn tekoon ja projekti suunnitteluun voidaan käyttää projektikoh- taisia wiki- ja keskustelupalstoja. Näille palstoille on mahdollista liittää myös tiedos- toja. Dokumentteja on mahdollista ryhmitellä niiden käyttötarkoituksen mukaan. (Kantola 2013, 29.) Tehtävien hallinnassa on mahdollista käyttää kaikkia tehtävän keskeisiä tietoja. Ne ovat tehtävän tyyppi, nimi, kuvaus, tila, prioriteetti, aikataulu, arvioitu työaika ja vas- tuuhenkilö. Tehtävien tyyppi voi olla vika, ominaisuus tai taustatehtävä. Näidenkin yhteyteen voi lisätä tiedostoja. (Kantola 2013, 29) Projektin seurantaa varten on myöskin tarjolla joukko työkaluja. Projektia voi aika- tauluttaa Gantt-kaavion avulla. Kalenterissa näkyvät projektiin liittyvät päivämäärät. Lisäksi sinne on mahdollista tehdä omia merkintöjä. Järjestelmään on mahdollista liit- tää versionhallintajärjestelmä, jonka kautta voidaan seurata ohjelmistoon tehtäviä 26 muutoksia. Järjestelmästä voidaan myös seurata käyttäjien tekemiä toimenpiteitä. (Kantola 2013, 30.) Resurssienhallinnassa on mahdollista antaa käyttäjille erilaisia rooleja. Nämä roolit on mahdollista määritellä itse. Käytännössä se tehdään rajaamalla käyttöoikeuksia. Käyttäjää luodessa sille voidaan määritellä yksi tai useampi rooli. (Kantola 2013, 30.) Kaiken kaikkiaan Redmine vaikuttaa monipuoliselta projektinhallintatyökalulta. Omi- naisuuksia siinä on riittävästi. Lähes kaikki monipuolisen projektinhallintatyökalun ominaisuudet löytyvät siitä. Kaiken lisäksi se on ilmainen tuote. 3.2.2 Jira Jira on Australialaisen Atlassian yhtiön maksullinen tuote. Taulukossa 1 on kuukausi- hinta eri käyttäjämäärillä. Se on palvelimelle asennettava tuote, joten työryhmä voi käyttää sitä keskitetysti. Käyttäjä tarvitsee vain internetselaimen ohjelman käyttöön. Jiran lisäksi palvelimelle täytyy asentaa Java-platform. Palvelimen käyttöjärjestelmä voi olla joko Linux tai Windows. (Jira requirements 2016.) Taulukko 1. Jiran hinnasto (The best software teams ship early and often 2016) Käyttäjä määrä Hinta $ kuukadessa 0 - 10 10 11 - 15 75 16 - 25 150 26 - 50 300 51 - 100 450 101 -500 750 501 - 2000 1500 Jiralla on mahdollista määritellä projektin tietoja monipuolisesti: • Projektille on mahdollista luoda kotisivu. • Projektille voidaan valita, millaisia dokumentteja projektissa voidaan käsitellä. • Valituille dokumenteille voi määritellä tilat, joita projektissa käytetään. • Projektille voidaan määritellä omat näkymät. • Projektille voidaan määritellä omia kenttiä. • Käyttäjien rooleja on mahdollista säätää projektikohtaisesti. (Defining a Project 2016.) Jirassa projektiin liittyviä dokumentteja kutsutaan issueiksi. Niitä on viisi tyyppiä: vika, kehityskohde, uusi ominaisuus, tehtävä ja itse määriteltävä tyyppi. Nämä tyypit 27 mahdollistavat erilaisten asioiden kirjaamisen järjestelmään, kuten esimerkiksi vaati- mukset. Kaikille on mahdollista antaa prioriteetti ja tilatieto. Jiran issuet mahdollista- vat monipuolisen toiminnan. Niihin on mahdollista liittää mm. tiedostoja, niitä voi ai- katauluttaa jne. (What is an Issue 2016; Working with an Issue 2016.) Jiralla on mahdollista luoda monenlaisia raportteja. Issuen aikatauluja voi tarkkailla myös kalenterinäkymän kautta. Kalenteri ei kuitenkaan ole automaattisesti käytössä vaan se täytyy ottaa erikseen käyttöön. Resurssienhallinnassa luodaan käyttäjä, joka täytyy aina liittää johonkin ryhmään. Jirassa on tarjolla valmiita ryhmiä, mutta niitä on mahdollista luoda lisää. Jokaiselle ryhmälle on mahdollista antaa yksilölliset oikeudet eri resursseihin. Ryhmille ja käyt- täjille on mahdollista antaa erilaisia projektikohtaisia rooleja. (User and Group Ma- nagement 2016.) Jira on myös erittäin monipuolinen projektinhallinnan työkalu. Siihenkin löytyy kaikki nykyaikaiseen projektinhallintatyökaluun kuuluvat ominaisuudet. 3.2.3 Projektin näkökulma Molemmat projektinhallinta työkalut sopivat yhtä hyvin tämän projektin käyttöön. Kummassakaan ei ole sellaisia puutteita, joista olisi ollut haittaa projektille. Koska projekti on kooltaan pieni, työkalujen kaikkia ominaisuuksia ei käytännössä edes tar- vita. Projektiin oli valittu työkaluksi Redmine. Tuotteen ilmaisuus on todennäköisesti ollut painava syy valintaan. Projektinhallintatyökalua käytettiin lopulta yllättävän vähän. Käytännössä sinne kir- jattiin vain tuotteen vaatimukset ja nekin osittain suurpiirteisesti. Projektin edetessä olisi ollut järkevää täydentää myös vaatimuksia sitä mukaa, kun niitä pystyttiin tar- kentamaan. Vaatimuksien priorisointi mahdollisuutta ja niiden linkittämistä tehtäviksi ei käytetty. Käytännössä se tehtiin sähköpostilla jaetulla listalla, jossa oli ominaisuudet ja niiden 28 tärkeysjärjestys. Se toimikin ihan hyvin. Miinuksena on, että priorisoinnista ei jää jäl- keä järjestelmään. Tietysti tämä maili on mahdollista tallettaa vielä järjestelmään ja siten sekin tieto saadaan talteen. Projektinhallintaohjelmaa olisi kannattanut käyttää testauksessa löytyneiden vikojen seurantaan. Näin ei kuitenkaan tehty. Käytännössä testaaja kertoi viat suullisesti ja ne korjattiin lähes saman tien. Korjatuista vioista ei siten jäänyt mitään jälkeä järjes- telmään. Ainut maininta viasta saattaa olla versionhallinnan kommentissa. 3.3 Versionhallinta 3.3.1 Yleistä Jo 1960-luvulla ohjelmistoprojektien koon kasvaessa havaittiin, että informaation vaihto projektin tekijöiden välillä ei toimi kunnolla. Mitä enemmän henkilöitä projek- tiin osallistuu, sitä suuremmat haasteet tiedon jakelulle asetetaan. Myös tarve tie- dostojen versiointiin havaittiin tiimien koon kasvaessa, koska muutoksien hallinta oli vaikeaa ilman sitä varten kehitettyä työkalua. Tähän tarpeeseen kehitettiin lopulta versionhallintaohjelmistot. (Majuri 2006, 8.) Versionhallinnan toiminnot ryhmitellään neljään vaiheeseen, jotka ovat: 1. Tunnistaminen, joka tarkoittaa versionhallintaan talletettavien objektien (yleensä tiedos- toja) tallennustarpeen tunnistamista ja yksilöllistä nimeämistä. 2. Muutosten hallinta, jolla valvotaan järjestelmään talletettujen objekteihin tehtäviä muu- toksia. Tämä on joukko prosesseja, jolla varmistetaan talletetun objektin laatu. 3. Tilan seurannalla nähdään objektiin tehdyt muutokset, muutosten tekijät, muutoksen ajankohta ja miksi muutos on tehty. 4. Arvioinnit ja tarkistukset vahvistetaan, että versionhallinta sisältää oikeat komponentit. Sen avulla on myös mahdollista tarkistaa, että toteutus on tehty prosessien mukaisesti. (Majuri 2006, 9-10.) Versionhallinnan käytöllä saavutetaan monenlaisia hyötyjä. Majuri listaa ne näin: • lisääntynyt tuottavuus • alemmat ylläpitokulut • parempi laatu • virheiden määrän vähentyminen • nopeampi virheiden ja ongelmien tunnistaminen • prosessista riippuva kehitys • tiedon oikeellisuus 29 Edellä luetellut hyödyt ovat vahvasti kytköksissä toisiinsa. Tuottavuus paranee, kun kommunikaatio ja tiedonjakoprosessi on suunniteltu kunnolla. Samoin silloin, kun muutosten käsittely prosessina on suunniteltu kunnolla. Tästä on suora seuraus alemmat ylläpitokulut virheiden vähenemisen myötä. Samalla laatu paranee. Virhei- den syntyminen pyritään estämään hyvän prosessin avulla. Se tukee myös virheiden ja ongelmien löytämistä madollisimman aikaisin. Versionhallinta pakottaa käyttä- mään prosesseja, jonka avulla varmistetaan tiedon oikeellisuus. (Majuri 2006, 15-16.) Versionhallintaohjelmistojen toimintaperiaate vaikuttaa merkittävästi sen toimin- taan. Ensimmäiset versionhallintaohjelmat tallensivat tiedostot paikalliseen tietokan- taan, jota ei ollut mahdollista jakaa useammalle käyttäjälle. Ensimmäisillä versioilla ei voinut myöskään hallita hakemistopuita eikä projekteja. (Hänninen 2011, 3-9.) 1990-luvun alussa esiteltiin CVS. Se oli ensimmäinen keskitetty versionhallintaoh- jelma, jossa tietovarasto on palvelimella ja, jota voidaan käyttää työasemilta. Tätä toimintatapaa voidaan pitää perinteisenä toimintatapana. Tällä tyylillä toimivat ohjel- mat vaativat, että verkkoyhteys on koko ajan saatavilla. Esimerkiksi historiatiedot haetaan suoraan palvelimelta. Lisäksi tiedostoihin tehdyt muutokset talletetaan muutoksina alkuperäiseen versioon verrattuna. Siten vain muuttuneet kohdat talle- tetaan tietokantaan. Kuviossa 6 esitellään tämä toimintaperiaate. (Hänninen 2011, 3- 9.) Kuvio 6. Versionhallintaohjelmistojen perinteinen toimintaperiaate (Chacon, Straub 2009.) 30 Hajautetussa versionhallintajärjestelmässä jokaisella käyttäjällä on oma paikallinen tietovarasto. Se sisältää koko tietovaraston sisällön historiatietoineen. Sen vuoksi palvelinyhteyttä ei tarvita jatkuvasti. Paikalliseen tietokantaan voidaan tallettaa uusia versioita. Tietoja voidaan synkronoida käyttäjien välillä tai erillisen keskusvaraston kanssa tarvittaessa. (Hänninen 2011, 3-9.) Kuten edellä olevista kappaleesta voi havaita, versionhallinta on keskeinen ohjelmis- toprojektin hallinta työkalu. Hyvä versionhallintaohjelma ei pelkästään kuitenkaan riitä laadun takaamiseksi. Se vaatii rinnalle hyvin suunnitellut prosessit. Yhdessä ne muodostavat kokonaisuuden, jolla versionhallinnan hyödyt saavutetaan. Erilaisia versionhallintaohjelmia on tarjolla runsaasti. Kaupallisten tuotteitten rinnalla on tarjolla myös hyviä open source -tuotteita. Viime vuosina ne ovat saaneet run- saasti jalansijaa ohjelmistotuotannossa. Seuraavaksi tutustutaan kahteen ilmaiseen tuotteeseen, jotka ovat yleisessä käytössä ohjelmistoprojekteissa. 3.3.2 Subversion (SVN) Subversion (SVN) perustuu suosittuun CVS-versionhallintaohjelmaan. Siinä on kehi- tetty kommenttien kirjoitusta. Samoin tiedostojen siirto on kansiosta toiseen mah- dollista. Niiden tuki puuttui CVS:stä. (Hänninen 2011, 3-9.) SVN on keskitetyllä mallilla toimiva versionhallintaohjelma. Muutokset talletetaan tietokantaan keskitetyn mallin mukaisesti. Samoin kyselyt tehdään suoraan tietokan- nasta. Sen vuoksi käyttö on riippuvainen verkkoyhteydestä. Tietokantaan talletettua tietovarastoa kutsutaan repositoryksi. Siitä voidaan ottaa paikallinen työkopio, joka talletetaan takaisin tietokantaan muutosten jälkeen. Se mahdollistaakin tiedostojen muokkauksen ilman verkkoyhteyttä. (Collins-Sussman, Fitzpatrick, Pilato 2011.) Järjestelmä mahdollistaa, että useampi käyttäjä voi muokata samaa tiedostoa yhtä aikaa. Talletuksen yhteydessä tarkistetaan mahdolliset yhteentörmäykset. Jos niitä löytyy, ne on ensin selvitettävä. (Collins-Sussman, Fitzpatrick, Pilato 2011.) 31 Alun perin SVN on suunniteltu käytettäväksi komentoriviltä. Koska käyttäjiä on mo- nenlaisia, sen päälle on kehitetty graafisia käyttöliittymiä. Yksi suosituimmista on Tor- toise-SVN. Se on kehitetty windows-ympäristöön. Se integroituu suoraan tiedostojen hallintaan, jonka kautta sitä käytetään. Se helpottaakin monessa suhteessa SVN:n käyttöä, koska käyttäjän ei ole pakko muistaa kaikkia monimutkaisia komentoja. 3.3.3 GIT Git on hajautettu versionhallintajärjestelmä. Tietovaraston haun jälkeen voidaan työskennellä paikallisesti. Sen vuoksi ohjelma toimii erittäin nopeasti. Useimmat ko- mennot toimivat ilman verkkoyhteyttä. Sen vuoksi työskentely yhteydettömässä ti- lassa on mahdollista. Ainoastaan synkronointi toisten käyttäjien kanssa ei onnistu. (Chacon, Straub 2009.) Gitin tiedonkäsittelytapa poikkeaa muihin versionhallintaohjelmiin nähden. Tiedos- toihin tehtyjä muutoksia ei talleteta muutoksina vaan koko muutettu tiedosto talle- tetaan uudelleen. Tallennettu version on siten tilannekuva senhetkisestä tiedostora- kenteesta. Jos tiedosto ei muutu sitä ei talleteta uudelleen vaan silloin viitataan edel- liseen muutettuun versioon. Kuviossa 7 on esitetty Gitin muutostenhallintatapa. (Chacon, Straub. 2009.) Kuvio 7. Gitin muutostehallintatapa (Chacon, Straub 2009.) Gitin muutoksenhallinta poikkeaa myös totutusta. Tiedostolla voi olla kolme tilaa. Py- syvästi muutettu (commited) tarkoittaa, että tiedosto on talletettu tietokantaan. 32 Muutettu (modified) tarkoittaa, että tiedostoa on muutettu, mutta sitä ei ole vielä talletettu tietokantaan. Valmisteltu (staged) tarkoittaa, että muutettu tiedosto on merkitty meneväksi seuraavaan pysyvään talletukseen. Näiden tilojen hallinta vaatii, että Gitin käytössä on kolme erillistä tiedostoaluetta. Git-hakemistoon talletetaan projektin metadata ja oliotietokanta. Työskentelykansio sisältää yhden version tieto- kannan sisällöstä. Se on haettu Git-hakemistosta, ja sen sisältöä käyttäjä voi muuttaa. Valmistelualue on tiedosto Git-hakemistossa, jonne kirjataan seuraavaan talletuk- seen menevät muutokset. (Chacon, Straub 2009.) Useampi käyttäjä voi muokata ja versioida tiedostoja samanaikaisesti. Synkronoinnin yhteydessä yhteentörmäykset on selvitettävä. Jos muutokset ovat vielä tallenta- matta, yhteentörmäysten selvitys päättyy virheeseen. Muutokset täytyy tallettaa en- sin tietovarastoon. (Chacon, Straub 2009.) Git on suunniteltu alun perin käytettäväksi komentoriviltä. Gitin käyttöön on myös tehty useita graafisia käyttöliittymiä. Tortoisesta on esimerkiksi saatavissa myös Git- versio. Graafinen käyttöliittymä helpottaa ohjelman käyttöä samaan tapaan kuin SVN:n yhteydessä. 3.3.4 Projektin näkökulma Kumpikin ohjelma sopii hyvin projektin käyttöön. Niissä on riittävästi ominaisuuksia tämän kaltaisen pienen ohjelmiston tallettamiseen. Käytännössä verkkoyhteys on lä- hes aina tarjolla, jolloin sen puute ei rajoita SVN:n käyttöä. Projektiin oli valittu versionhallintaohjelmaksi Git. Siihen oli päädytty sen kätevyyden vuoksi. Verkkoyhteyttä ei tarvita jatkuvasti. Verkon kuormitus pienenee tämän ansi- osta. Käyttö on nopeaa ja joustavaa, kun tietovarasto on paikallinen. Käyttäjätunnus ja salasana tarvitaan vain silloin, kun tietovarasto synkronoidaan palvelimen kanssa. Paikallinen tietovarasto mahdollistaa ohjelman talletuksen pienissä osissa. Muutoksia voidaan tallettaa jo varhaisessa vaiheessa pysyvästi. Niitä ei ole pakko heti synkro- noida palvelimen kanssa. Muutokset voivat olla siten vielä keskeneräisiä. Muutokset näkyvät vain ohjelmiston kehittäjälle eivätkä ne vielä näy muille käyttäjille. Siitä huo- 33 limatta ne on jo talletettu tietovarastoon. Näitten välitalletusten avulla on myöhem- min helpompi selvittää mikä muutos aiheuttaa jonkin ohjelmisto vian, koska tarkas- teltavien muutosten koko on pienempi. Projektin aikana Gitin toimintaan ei ollut aikaa tutustua riittävästi. Sen kaikkia omi- naisuuksia ei siten käytetty. Edellä kuvattu paikallinen tallennusmahdollisuus jäi esi- merkiksi käyttämättä. Joissakin tilanteissa sen käyttö olisi ollut järkevää. Yleensä muutokset oli mahdollista tallettaa tietovarastoon pieninä muutaman rivin muutoksina. Joitakin kertoja tilanne oli kuitenkin toinen. Tietovarastoon laitettiin muutoksia suurina palasina, koska ohjelmisto täytyi pitää koko ajan toimivana. Silloin olisi ollut järkevää käyttää välitallennuksia paikalliseen tietovarastoon. 3.4 HTTP-rajapinta: tekniikat ja datarakenteet 3.4.1 Yleistä Rajapinnat toteutettiin HTTP-protokollalla ReST-rajapinnan yli. HTTP on tyypillinen asiakas palvelin (client server) ratkaisu, jossa palvelin odottaa asiakkaiden lähettämiä palvelupyyntöjä. Asiakkaalla on osoite (URI) palveluun. Annettu osoite tulkitaan nimi- palvelimella ja pyyntö lähetetään palvelimelle, joka lähettää vastauksen asiakkaalle. (Sovelluskerros 2008) HTTP-pyynnöt ovat tilattomia. Yhteen pyyntöön saadaan yksi vaste, jonka jälkeen yh- teys suljetaan. Palvelin on aina samassa tilassa, jolloin se voi seuraavaksi palvella minkä tahansa palvelupyynnön. Kuviossa 8 on esitelty HTTP-palvelupyyntö ja palveli- men lähettämä vaste. Kuvassa palvelupyynnöstä käytetään nimitystä asiakaspyyntö. Palvelupyyntö on kuitenkin kuvaavampi nimitys. Kuviossa 8 on myös esitetty palvelupyynnön ja vasteen päärakenne. Pyyntö koostuu seuraavista osista: Pyyntörivi, joka sisältää tiedon käytettävästä metodista, doku- mentista ja HTTP:n versiosta. HTTP-otsakkeet, joiden avulla selain kertoo palveli- melle useita tietoja, kuten käytettävä kieli, käytössä oleva selain, lähetettävän datan muoto, jne. Lopussa onkin sitten varsinainen data. (Mynttinen 2016.) 34 Kuvio 8. HTTP-palvelupyynnön rakenne (Mynttinen 2016.) Palvelimen lähettämä vaste sisältää puolestaan seuraavat kentät: Tilarivi, joka sisäl- tää HTTP:n versiotiedon, tilakoodin pyynnön toteutumisesta tekstimuotoisen selityk- sen kera. Vastauksessa tulee myös HTTP-otsakkeita, jotka sisältävät tietoja palveli- mesta, vastauksen luontiaika, palautettavan dokumentin sisältötyyppi, jne. Lopussa on jälleen vastauksen varsinainen data. (Mynttinen 2016.) HTTP-palvelupyyntöjen metodit ovat seuraavat: • GET – hae resurssi • POST – lähetä dataa palvelimelle • PUT – päivitä resurssi • DELETE – tuhoa resurssi Lisäksi on vähemmän käytetyt HEAD, CONNECT, OPTIONS ja TRACE palvelupyynnöt. (Fielding, Reschke 2014, 21-32.) Tavallisin on GET-metodi. Sillä haetaan resursseja palvelimelta, joka lähettää haetun resurssin vastauksessa asiakkaalle. Palvelimen vaste tulee yleensä HTML-muodossa, jonka selain tulkitsee näkyväksi www-sivuksi. Alkuun toimittiinkin pelkästään näin. Sivut olivat staattisia ja niitä ei voinut päivittää lataamatta koko sivua uudelleen. (So- velluskerros 2008) 35 Vaste ei nykyään välttämättä ole kuitenkaan HTML-sivu. Varsinkin silloin, jos palvelu- pyyntö on tehty AJAXin avulla. Silloin se voi sisältää myös JSON, XML, CSV tai jossain muussa muodossa olevaa dataa. Selaimella AJAXin avulla haettua dataa käsitellään yleensä JavaScriptin avulla. Vastaanottaja voi kuitenkin myös olla jokin IoT-laite, joka käsittelee saamansa datan haluamallaan tavalla. POST-metodi on toinen yleisesti käytetty palvelupyyntö. Sen avulla asiakas lähettää dataa palvelimelle. Data on usein peräisin HTML-lomakkeelta. Dataa voidaan lähet- tää palvelimen suuntaan useammassa muodossa. Oletusarvoisesti datan tyyppi on aina x-www-form-urlencoded. Se voi kuitenkin olla myös JSON, XML tai jossain muussa muodossa. Kosteusmittari projektissa käytettiin pelkästään GET- ja POST-metodeja. Dataa siirre- tään perinteisten palvelupyyntöjen lisäksi AJAXin avulla. HTML-muotoisen datan li- säksi käsitellään x-www-form-urlencoded-, JSON- ja CSV-muotoista dataa. 3.4.2 AJAX Kuten aiemmin jo mainittiinkin, alkuvaiheessa HTTP:llä siirrettiin pelkästään staat- tista dataa. Pian kuitenkin havaittiin, että se ei riitä. Data päivittyy jatkuvasti, jolloin HTML-sivustoja täytyy päivittää tietyin väliajoin. Ensimmäisessä vaiheessa sivujen dy- naamisuutta lisättiin palvelimella ajettavilla skriptaus kielillä (CGI, PHP). Ne generoi- vat saamastaan datasta HTML-sivun, joka lähetettiin vastauksessa selaimelle. Tämä olikin jo merkittävä kehitysaskel. (Asleson, Schutta 2007, 1-13.) Palvelimella ajettavien skriptien lisäksi kehitettiin JavaScript kieli, jota voidaan ajaa selaimella. Sillä tavalla pyrittiin saamaan parempi käyttäjäkokemus. Selainten huo- non tuen vuoksi sen käyttö jäi alkuvaiheessa vähäiseksi. (Asleson, Schutta 2007, 1- 13.) Pian huomattiin kuitenkin, että tämä ei vielä riitä. On usein tilanteita, jossa jokin si- vuston osa täytyy päivittää uudelleen ja hakea uutta dataa palvelimelta. Suurin osa sivustosta säilyi kuitenkin muuttumattomana. Siitä huolimatta koko sivu täytyi hakea uudelleen. Käyttäjälle tämä näkyi usein ylimääräisenä viiveenä. Samalla siirrettävä datamäärä kasvoi turhaan. (Asleson, Schutta 2007, 1-13.) 36 Tähän tarpeeseen kehitettiin AJAX. Se ei sinänsä tuonut mitään uutta. Komponent- teja käytetään vain uudella tavalla. Tällainen komponentti on esimerkiksi XMLHtt- pRequest. Aluksi selaimien huono tuki hidasti käyttöönottoa. Kun merkittävät inter- net toimijat, kuten Google, otti tekniikan käyttöön, se alkoi yleistyä. (Asleson, Schutta 2007, 14-17.) AJAXin merkittävimpiä toimintamalleja on sen asynkronisuus. Se mahdollistaa pyyn- töjen tekemisen sovelluksen ajon taustalla. Kun pyyntö lähetetään, sovellus ei odota vastetta vaan jatkaa toimintaansa. Vaste käsitellään erikseen heti sen saavuttua. (As- leson, Schutta 2007, 14-17.) AJAXin kommunikaatio perustuu siis XMLHttpRequest-olioon. Se luodaan ensin Ja- vaScriptillä ja lähetetään palvelupyyntönä palvelimelle. Merkittävää palvelimen lä- hettämässä vasteessa on, että se ei tulekaan HTML-muodossa vaan se on XML-, JSON- tai jossain muussa muodossa. XML:n käyttö ei siten ole välttämätöntä, vaikka olion nimestä voisi niin päätellä. Data voidaan lähettää yhtä hyvin JSON-muodossa (Korpela, Lehdonvirta 2013, 55). Kuviossa 9 on esimerkki XMLHttpRequest-olion käy- töstä ja AJAX palvelupyynnön suorittamisesta. Kuvio 9. AJAX-palvelupyynnön lähetys ja vastauksen käsittely (AJAX Tutorial 2016.) Alkusi luodaan uusi XMLHttpRequest-olio. Sille luodaan vastauksen käsittely funktio eli ns. callback-funktio. Tämä funktio ajetaan, kun palvelupyynnön vaste saadaan. Funktio liitetään parametriin onreadystatechange. Palvelinyhteys avataan open-funk- tiolla. Parametrina metodille annetaan palvelupyynnön metodi ja lähetys osoite. Li- säksi on valinnaisia parametreja, joita ei ole pakko käyttää. Funktio avaa yhteyden function loadDoc() { var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (xhttp.readyState == 4 && xhttp.status == 200) { document.getElementById("demo").innerHTML = xhttp.responseText; } }; xhttp.open("GET", "uri"); xhttp.send(); } 37 palvelimelle. Se ei vielä toteuta varsinaista palvelupyynnön lähetystä, joka tehdään erikseen send-funktiolla. (Asleson, Schutta 2007, 25-36.) XMLHttpRequest-olion turvalliseen käyttöön on kiinnitetty huomiota. Sen avulla pyy- detyn resurssin täytyy sijaita samassa palvelussa eli saman verkkotunnuksen (domai- nin) alaisuudessa. Muualta tulleiden palvelupyyntöjen suoritus estetään. (Asleson, Schutta 2007, 37.) 3.4.3 Datarakenne x-www-form-urlencoded Kyseessä on HTTP-protokollan POST-metodin oletus datarakenne. Se sisältää avain arvo pareja, jotka lähetetään pyynnön data eli body-osiossa merkkijonona. Syntaksi on yksinkertainen (kuvio 10). Kuvio 10. x-www-form-urlencoded rakenteen syntaksi Tätä rakennetta käytetään yleensä datan lähetyksessä HTML-lomakkeilta. Syntaksista voidaan päätellä, että monimutkaisemman datan lähetys tällä menetelmällä on han- kalaa. Arvona ei esimerkiksi ei voi olla sisään sijoitettua toista arvoparitaulukkoa. Joissakin tilanteissa tämä onnistuu, kun käsitellään rakennetta merkkijonona. Silloin datan purkuun täytyy tehdä erillinen oma toteutus. (Boumphrey, Greer, Raggett, Raggett, Schnitzenbaumer, Wugofski 2001, 425 – 428.) Dataan on mahdollista lähettää samalla syntaksilla myös GET-metodissa. Silloin data sijoitetaan heti URI:n perään kysymysmerkillä erotettuna (kuvio 11). Tällä tavalla voi- daan lähettää ohjaustietoja palvelimelle. Kuvio 11. Datan lähetys GET-metodissa Tätä datarakennetta käytetään kosteusmittariprojektissa kahdessa yhteydessä. GET- metodien ohjaustietoja siirretään palvelimelle sekä selaimelta että mittarilta. Mittari lähettää POST-metodilla asetukset palvelimelle. avain1=arvo1&avain2=arvo2&avain3=arvo3&avain4=arvo4&avain5=arvo5 http://uri/tiedosto.html?avain1=arvo1&avain2=arvo2&avain3=arvo3 38 3.4.4 JSON JSON (JavaScript Object Notation) on keveä tekstipohjainen ohjelmointikielistä riip- pumaton datarakenne. Sitä käytetään rakenteellisen datan siirtoon kaikkien ohjel- mointikielien välillä. Alun perin se on ollut osa ECMAScript ohjelmointikieltä. Koska rakenne käsitellään merkkijonoina, se on riippumaton tietotyypeistä. Erityisesti erilai- sista numeroiden esitystavoista. (ECMA-404 2013.) Syntaksi on hyvin yksinkertainen. Siitä huolimatta se mahdollistaa monimutkaisen datan esityksen. JSON-perusyksikkö on arvo (value). Se voi olla neljää eri tyyppiä, jotka ovat objekti (object), taulukko (array), numero (number) ja merkkijono (string). Lisäksi on käytettävissä kolme vakioarvoa, jotka ovat: true, false ja null. (ECMA-404 2013.) Objekti on JSONin tärkein tietotyyppi. Se koostuu avain arvo pareista. Avain on merk- kijono, joka kertoo mitä kenttä merkitsee. Arvo kentän sisältö onkin eritelty edelli- sessä kappaleessa. Kuviossa 12 on malli, joka mukaan objekti voidaan rakentaa. (ECMA-404 2013.) Kuvio 12. JSON-objektin luonti (ECMA-404 2013.) Luonti aloitetaan vasemmalta. Rakenne alkaa aaltosululla. Sen perään tulee heti en- simmäinen avain arvo pari. Avain on merkkijono, joka erotetaan kaksoispisteellä pa- rin arvosta. Silmukkaa toistetaan niin kauan, että kaikki parit on täytetty. Parit erote- taan toisistaan pilkulla. Lopuksi rakenne suljetaan aaltosululla. Rakenne voi olla myös tyhjä. Silloin se sisältää vain kaksi aaltosulkua. (ECMA-404 2013.) Objekti-rakenteessa tulee parhaiten näkyviin JSON-rakenteen mahdollisuudet. Arvo kenttään voidaan sijoittaa mikä tahansa oliotyyppi. Objekti voi siten sisältää taulu- koita, sisäkkäisiä objekteja jne. Kuviossa 13 on esimerkkinä monimutkaisempi JSON- 39 rakenne. Sen alussa on joukko avaimia, joille on annettu arvoksi yksittäinen numero tai merkkijono. Lopussa on kaksi avainta, joiden arvona on taulukko. Nämä taulukot sisältävät lisäksi useita pienempiä taulukoita. ECMA-404 2013 standardista löytyy samanlaiset rakennusmallit myös taulukoille ja numeroille. Numerot on mahdollista esittää kokonaislukuna, desimaalilukuna tai liu- kulukuna, joka sisältää eksponentin. (ECMA-404 2013.) Kosteusmittari projektissa JSON-rakenteita käytetään asetusten siirrossa palvelimelta mittarille. Samoin niitä käytettään siirrettäessä dataa AJAX-rajapinnan yli palveli- melta asiakassovellukselle. Pääsääntöisesti rakenteet ovat yksinkertaisia, mutta mit- tarille siirrettävät mitattavan materiaalin kompensaatiokäyrästöt sisältävät monimut- kaisempaa taulukkodataa (Kuvio 13). 3.4.5 CSV CSV (Comma Separated Values) rakennetta käytetään taulukkomuotoisen datan siir- rossa eri järjestelmien välillä. Vaikka se on yleisesti käytetty, sitä ei ole virallisesti do- kumentoitu. Esimekiksi IANA on määritellyt sille oman MIME-tyypin vasta vuonna 2014. (Hausenblas, TennisoJ, Wilde 2014; Shafranovich 2005.) Nimensä mukaisesti rakenne koostuu riveistä, jossa arvot erotetaan pilkulla toisis- taan. Tiedoston ensimmäinen rivi sisältää sarakkeiden otsikot. Se ei kuitenkaan ole pakollinen. Kuviossa 14 on esimerkki CSV:n rakenteesta. (Shafranovich 2005.) {'meterId': 1234567890, 'currentSettigs': 'true', 'source': 'm', 'name': 'ohra', 'targetMoisture': 12, 'maxTemperature': 45, 'offset': 0, 'scale': '[[0, 0], [10, 12], [100, 37]]', 'temperatureComp': '[[20, -1], [40, 0], [80, 3]]'} Kuvio 13. Esimerkki JSON-rakenteesta 40 Kuvio 14. Esimerkki CSV-rakenteesta (Shafranovich 2005.) CSV-tyypillä on helppo siirtää suuri määrä vakiomuotoista dataa järjestelmästä toi- seen. Tässä työssä käyräksi piirrettävä mittausdata toimitetaan CSV-muodossa palve- limelta selaimelle. 3.5 Tietokanta 3.5.1 Yleistä Nykyään tietokannat jaetaan kahteen ryhmään. Ne ovat relaatiotietokannat ja muut ei relaatiotietokannat. Jako kertookin, että relaatiotietokannat ovat olleet pitkään dominoivassa asemassa. Se on niin tehokas malli, että se syrjäytti aiemmat tietokan- tamallit kohta esittelynsä jälkeen. Vasta viime vuosina tietomäärien räjähdysmäisen kasvun jälkeen, muut uudet tietokantamallit ovat saaneet jälleen jalansijaa. (Soikkeli 2013, 9.) 3.5.2 Relaatiomalli Relaatiotietokannat perustuvat relaatiomalliin, joka on kehitetty jo 1970-luvulla. Re- laatiomalli perustuu joukko-oppiin, matematiikkaan ja predikaattilogiikkaan. Malli voidaan jakaa kolmeen osaan, jotka ovat rakenne-, käsittely- ja eheyssäännöt. (Hovi 2004, 5.) Rakenne perustuu tauluihin, joka sisältää tietyn kokonaisuuden tiedot. Taulu on ja- ettu sarakkeisiin ja riveihin. Sarakkeet sisältävät avaimia taulun tietoihin. Niitä voi olla esim. nimi ja osoite. Yksi taulun avaimista on pääavain, joka on yksilöllinen eli jo- kaisella rivillä täytyy olla eri arvo. Taulussa voi olla myös viiteavaimia, joilla voidaan viitata toiseen tauluun. Jos rivi ei sisällä arvoa johonkin sarakkeeseen, sille annetaan arvo null. Se ei tarkoita nollaa eikä tyhjää vaan tuntematonta arvoa. (Hovi 2004, 6-7.) field_name,field_name,field_name aaa,bbb,ccc zzz,yyy,xxx 41 Käsittely sääntöjen taustalla on joukko oppi. Tauluista voidaan hakea tietoja osajouk- koihin. Valitaan esimerkiksi kaikki tietyssä osoitteessa asuvat henkilöt. Kuviossa 15 on tärkeimmät joukko-operaatiot. (Hovi 2004, 8-9.) Relaatiomalliin on määritelty myös eheyssäännöt. Niistä kaksi tärkeintä on avaine- heys ja viite-eheys. Avaineheys tarkoittaa, että sille täytyy antaa aina arvo ja niiden täytyy poiketa toisistaan. Viite-eheys tarkoittaa, että riviä ei voi poistaa taulusta, jos jossakin toisessa taulussa oleva viiteavain viittaa siihen. Toinen mahdollisuus on, että myös ne rivit poistetaan, joihin on viittauksia. (Hovi 2004, 9-10.) Relaatiotietokantoihin liittyy läheisesti SQL-kyselykieli. Käytännössä kieli ei rajoitu pelkkiin kyselyihin. Sillä voidaan tehdä kaikki tietokannan hallintaan liittyvät tehtävät. Nämä toiminta-alueet ovat: 1. Tietokannan rakenne. 2. Kyselyt. 3. Päivitykset, muu- tokset ja poistot. 4. Tapahtumankäsittelyn ohjaaminen. 5. Valtuudet ja turvallisuus. Se tarjoaa myös rajapinnat eri ohjelmointikielien käyttöön. (Hovi 2004, 14.) Kuvio 15. Relaatiotietokantojen tärkeimmät joukko-operaatiot (Hovi 2004, 9.) 42 3.5.3 Muut tietokantamallit Erilaisia tietokantamalleja oli olemassa jo 1960-luvulla. Relaatiotietokannat syrjäytti- vät ne kuitenkin lähes täydellisesti. Uusien tietokantamallien kehitys alkoi jälleen 2000-luvulla. Näistä uusista tietokannoista käytetään nimitystä NoSQL (Not only SQL tai Not relational). Yhteinen tekijä näille tietokannoille on, että tietoa ei talleteta SQL-komennoilla. (Soikkeli 2013, 14.) Muista tietokantamalleista löytyy joukko yhdistäviä tekijöitä. Ne ovat skaalautuvuus, hajautettavuus ja skeemattomuus. Yhdistävänä tekijänä voidaan pitää myös ohjel- mistorajapintaa, joka on näkyvä ominaisuus. Niitä voi olla monenlaisia. Se voi olla SQL:n kaltainen kieli, HTTP-rajapinta, ohjelmointikielen kirjastorajapinta tai jokin kombinaatio edellisistä. (Soikkeli 2013, 14-17.) Skaalautuvuudella tarkoitetaan järjestelmän resurssien lisäystä siten, että suoritus- kyky paranee, vaikka tietomäärä kasvaa. Suorituskykyä voidaan kasvattaa horisontaa- lisesti tai vertikaalisesti. Horisontaalisella kasvattamisella tarkoitetaan laskentatehon hajauttamista useammalle tietokoneelle. Vertikaalisella puolestaan yksittäisen ko- neen esim. palvelimen tehon kasvattamista komponentteja vaihtamalla. Horisontaa- lista skaalautuvuutta voidaan pitää järkevämpänä, koska vakio komponenteilla laa- jentaminen on selvästi halvempaa. (Soikkeli 2013, 14-15.) Hajautettavuudella tarkoitetaan tiedon käsittelyä rinnakkaisesti usealla laitteella. Ho- risontaalinen skaalautuvuus tukee tätä ominaisuutta. Tämä korostuu erityisesti pilvi- palveluihin sijoitetulla laskentateholla. Hajautetussa järjestelmässä tieto voidaan toistaa eli replikoida verkon solmuihin. Sen avulla voidaan varmistaa tiedon eheys. Tiedon hakuun Google on kehittänyt Map Reduce ohjelmointiparadigman. Siinä käy- tetään hyväksi tietokannan hajautettavuutta. Hakutehtävä voidaan jakaa jopa tuhan- sille tietokoneille. Niiden tekemästä hakutuloksesta koostetaan vaste. Suuresta data- määrästä huolimatta vaste saadaan kelvollisessa ajassa. (Soikkeli 2013, 15-16.) Skeemattomuudella tarkoitetaan tiedon kopioimista useaan tauluun tai dokument- tiin. Se nopeuttaa hakuoperaatiota, koska tietoa ei haeta useammasta taulusta. Tosin silloin talletetun tiedon määrä kasvaa. Tämä vaikeuttaa myös tiedon eheyden säilyt- tämistä tietokantatasolla. Avuksi joudutaankin tekemään erillisiä ohjelmia tätä var- ten. Skeemattomassa tietokannassa talletetun datan sisältöön ei oteta kantaa. Sen 43 vuoksi tietokannan rakennetta ei ole pakko suunnitella etukäteen. Tuloksia saadaan siten näkyviin nopeammin. Yksinkertaisten tehokkaiden hakujen teko on helppoa, mutta monimutkaisten vaikeampaa. (Soikkeli 2013, 16-17.) Soikkeli on ansiokkaasti luokitellut uudet tietokannat tietomallien perusteella. Tässä tyydytään vain luettelemaan tietomallit, jotka ovat: avain arvo varasto, dokumentti- varasto, sarakevarasto ja verkkotietokanta. (Soikkeli 2013, 19-26.) Uudet tietokantamallit ovat selvästi vasta kehitysvaiheessa. Ne ovat saaneet run- saasti kritiikkiä. On kerrottu, että tietokannan hallintaohjelmaan on täytynyt kirjoit- taa itse SQL:n kaltaiset hakumetodit. Kritiikin perusteella uusia tietokantoja on pi- detty lähinnä tietovarastoina tai välimuisteina. Myös relaatiotietokantoja on kehi- tetty hajautettavampaan suuntaan, jolloin niilläkin saavutetaan NoSQL-tietokantojen etuja. (Soikkeli 2013, 17-18.) 3.5.4 MySQL MySQL:ää pidetään suosituimpana tietokantana internet-ympäristössä. Tyypiltään se on relaatiotietokanta. Käyttöönotto on helppoa. Suuren suosion vuoksi siitä on kirjoi- tettu paljon dokumentaatiota. Alkuunpääsyä helpottaa myös phpMyAdmin-työkalu, joka tarjoaa web-pohjaisen graafisen käyttöliittymän tietokannan hallintaan. MySQL:stä on saatavilla open source ja kaupallisia versioita. Vaikka MySQL on alun perin kehitetty Linux-ympäristöön, nykyään se on käytettävissä monilla käyttöjärjes- telmillä. Siinä on tuki useimmille ohjelmointikielille mm. PHP, Python, Java, C, C++, C# ja Perl. (MySQL Tutorial 2016.) MySQL-tietokannan hyviksi puoliksi kerrotaan seuraavaa: • helppokäyttöisyys • SQL-toimintojen määrä, joita on enemmän kuin tällaisissa työkaluissa tavallisesti • kehittyneet turvaominaisuudet • se sopii monenlaiseen käyttöön sekä pieniin että suuriin tietomääriin Tauluun voidaan tallettaa 50 miljoonaa riviä ja taulun maksimi koko on oletusarvoi- sesti 4GB mutta sitä on mahdollista kasvattaa teoriassa jopa 8 miljoonaan Terata- vuun saakka. (MySQL Tutorial 2016; SQLite vs MySQL vs PostgreSQL: A Comparison of Relational Database Management Systems 2014.) 44 MySQL:ssä on kuitenkin muutamia puutteita: SQL-kielen toteutus ei ole kaikilta osin standardin mukainen. Luotettavuudessa on puutteita mm. viitteiden, tapahtumien ja tarkistusten käsittelyssä. Tekstin hakuominaisuuksissa on edelleen kehitettävää. Li- säksi sen kehitys on osittain pysähtynyt. (SQLite vs MySQL vs PostgreSQL: A Compari- son of Relational Database Management Systems 2014.) 3.5.5 Muut relaatiotietokanta vaihtoehdot Relaatiotietokannoista on tarjolla hyviä open source vaihtoehtoja. Sen vuoksi kaupal- liset tuotteet rajattiin käsittelyn ulkopuolelle. Ne eivät maksullisuutensa vuoksi olisi kuitenkaan olleet vaihtoehtoina. Lähempään tarkasteluun valittiin kaksi tuotetta, joita käytetään paljon MySQL:n rinnalla. Ne ovat SQLite ja PostgreSQL. SQLite SQLite on kevyt sulautettuihin järjestelmiin tarkoitettu tietokanta. Se on toteutettu yhdellä C-kirjastolla. Siinä ei ole erillistä prosessia vaan sitä ajetaan sitä käyttävän so- velluksen osana. Siksi siinä ei ole erillistä palvelinprosessia. Tietokanta on käytän- nössä yksi tiedosto. Sen vuoksi se onkin helposti siirrettävissä paikasta toiseen. (Nauha 2012.) Vaikka SQLite toteuttaakin suurimman osan SQL-standardin ominaisuuksista, siitä kuitenkin puuttuu viiteavaimien käyttö. Siltä osin tietokannan eheyttä ei voida to- teuttaa. Siinä ei myöskään ole käytettävissä käyttäjien hallintaa. Sen vuoksi se ei so- vellu useamman käyttäjän järjestelmiin. Suorituskykyä ei ole mahdollista parantaa ja se sallii vain yhden kirjoitusoperaation samanaikaisesti. (SQLite vs MySQL vs Post- greSQL: A Comparison of Relational Database Management Systems 2014.) PostgreSQL PostgreSQL on samankaltainen tietokanta kuin MySQL. Siinä on kuitenkin hieman enemmän ominaisuuksia. Se tukee esimerkiksi olioiden käyttöä. Tietotyyppejä on tar- jolla enemmän. Se on luotettava ja tiedon eheyden säilymiseen on kiinnitetty parem- min huomiota. Siihen on tarjolla runsaasti kolmannen osapuolen avoimia työkaluja. Sen SQL-kyselykieli on lähempänä standardia kuin MySQL:ssä. (SQLite vs MySQL vs PostgreSQL: A Comparison of Relational Database Management Systems 2014.) 45 PostgreSQL:ssä tietokannan kokoa ei ole rajoitettu. Suurin taulun koko on 32 TB. Suu- rin rivin koko on 1.6 TB. Suurin kentän koko on 1 TB. Taulun rivien määrää ei ole ra- joitettu. (About 2016.) PostgreSQL:ää pidetään hitaampana tuotteena kuin MySQL:ää. Se ei ole myöskään niin helppokäyttöinen. Sen käyttäjältä vaaditaan enemmän kokemusta tietokantojen hallinnoinnista. Pilvipalvelun tarjoajilla ei myöskään ole niin hyviä tukipalveluja Post- greSQL-tietoknnoille. (SQLite vs MySQL vs PostgreSQL: A Comparison of Relational Database Management Systems 2014.) 3.5.6 NoSQL vaihtoehdot Viime aikoina erilaisia NoSQL-tietokantoja on tullut markkinoille runsaasti. Tässä ote- taan tarkemmin tutkittavaksi suosituin. Se on tällä hetkellä MongoDB, joka on nous- sut neljänneksi suosituimmaksi tietokannaksi. Sen edellä on vain kolme relaatiotieto- kantaa. (Hovi 2015.) MongoDB on dokumenttipohjainen tietokantaohjelma. Yksi dokumentti vastaa peri- aatteessa relaatiotietokannan taulun riviä. Kokoelma puolestaan vastaa relaatiotieto- kannan taulua. Dokumentin data on järjestetty tyypillisesti JSON-muotoon. Siten data voidaan lähettää sellaisenaan tietokantaan talletettavaksi. Tämä on nopeaa ja käte- vää. (Hovi 2015.) MogoDB tarjoaa mahdollisuuden monimutkaisen datan talletuksen yhteen doku- menttiin. JSON-rakenne tukee tätä. SQL-tietokannoissa dataa joudutaan jakamaan helposti useampaan tauluun. Opeyemi teki testausta MySQL ja MongoDB:n välillä. Siinä yhteydessä MySQL-kanta sisälsi kolme taulua. MongoDB:ssä sama data pystyt- tiin tallettamaan samaan dokumenttiin. Kuviot 16 ja 17 kertovat havainnollisesti tä- män eron. Kuvioista 16 ja 17 voi havaita myös eron tietokantojen toiminnassa. MySQL-kan- nassa ystävien tietoja ei erikseen kopioida. Riittää, että on olemassa taulu follow, joka sisältää pelkästään viitteen ystävän tiedot sisältävään user-tauluun. Mon- goDB.ssä ystävän tiedot kopioidaan dokumentin friends-kenttään. Tässä näkyy sel- västi relaatiotietokantojen ja NoSQL-tietokantojen ero. 46 Kuvio 16. MySQL tietokannan rakenne testauksessa (Opeyemi 2014, 28.) Kuvio 17. MogoDB:n vastaava rakenne testauksessa (Opeyemi 2014, 28.) Yksinkertaisia hakuja voidaan tehdä nopeammin kuin MySQL-tietokannasta. Samoin datan talletus ja tuhoaminen tehdään erittäin nopeasti. Erityisesti datamäärien kas- vaessa ero tulee esille. Vertailu on tehty kuitenkin yksinkertaisilla rakenteilla, joten tämän perusteella ei voida ottaa kantaa monimutkaisempien hakujen kestoon. (Opeyemi 2014, 29-32.) 47 3.5.7 Projektin näkökulma Projektiin oli valittu etukäteen MySQL-tietokanta. Se onkin turvallinen valinta. Siitä on vanhastaan kokemusta ja se on todettu toimivaksi. SQLite-tietokantaa lukuun ot- tamatta kaikki kolme muuta sopisivat projektin käyttöön. SQLiten ominaisuudet lop- puvat kesken, koska dataa on paljon ja sitä tulee monesta lähteestä. PostgreSQL ei puolestaan tarjoa mitään lisäarvoa projektin tarpeisiin. Työn aikana havaittiin puute MySQL:n toiminnassa. Taulukoiden talletus tietokannan yhteen kenttään oli haastavaa. Suoraan JSON-muodossa olevaa taulukkoa ei voinut tallettaa. Se täytyi muuttaa ensin merkkijonoksi. Sen jälkeen talletus onnistui. Mon- goDB:tä käytettäessä ko. ongelmaa ei todennäköisesti olisi havaittu. Tietokantahaut ovat yksinkertaisia. Yleensä dataa haetaan pelkästään mittarin sarja- numeron perusteella yhdestä taulusta. Vain yksi kysely on monimutkaisempi, silloin- kin tiedot ovat samassa taulussa. Nopeudessa olisi siten saatu selvä etu, jos olisi käy- tetty MongoDB:tä. Jos olisi mahdollista valita projektiin liittyvät työkalut uudelleen, MogoDB:tä kannattaisi kokeilla. Rajapinta mittarin ja palvelimen välillä aiheutti tietokantaan omat ongelmansa. Niitä käsitelläänkin tarkemmin myöhemmin tässä dokumentissa. Nämä ongelmat kuiten- kin käytännössä vaikeuttavat MongoDB.n käyttöä ja estävät sen tuomien etujen saa- vuttamisen. Sillä perusteella paras valinta oli kuitenkin lopulta MySQL. 3.6 Back-end toteutus 3.6.1 Yleistä Back-end käsittellä tarkoitetaan yleensä ohjelmistoa tai järjestelmää, joka ei näy käyttäjälle. Web-ohjelmoinnissa sillä tarkoitetaan yleensä palvelinohjelmistoa, joka ei suoraan näy käyttäjälle. Ohjelmisto ajetaan palvelimella ja se käsittelee HTTP- palvelupyynnöt, joita tulee asiakasohjelmalta ja mahdollisesti muilta järjestelmään liitetyiltä laitteilta. 48 Palvelinohjelmisto on toteutettu jollakin ns. skriptaus kielellä. Niitä ovat mm. PHP, Ryby, Python ja Perl. Myös Javaa ja C# käytetään. Kuten aiemmin jo mainittiinkin, nii- den apuna on framework-kirjastot, jotka toteuttavat järjestelmän perustoiminnot. Tässä dokumentissa käsitellään tarkemmin kolmea skriptaus-kieltä. Ne ovat PHP, Pyhton ja Ryby. 3.6.2 Python Python on suosittu monilla alustoilla toimiva ohjelmointikieli. Se on tulkattava kieli, joten se on hitaampi kuin optimoitu erikseen käännetty C++ ohjelmisto. Dokumen- taatiossa kerrotaan, että Python on interaktiivinen kieli. Tämä tarkoittaa käytännössä sitä, että ohjelman voi kirjoittaa halutessaan suoraan komentotulkkiin, joka tulee asennuspaketin mukana. Erillistä lähdekooditiedostoa ei siten välttämättä tarvita. Tiedostojen käyttö on kuitenkin mahdollista ja lopulta järkevääkin. (Tuovinen 2004.) Pythonilla voidaan tehdä monen tyyppisiä ohjelmia. Perinteisen lauseohjelmoinnin lisäksi voidaan käyttää olio-ohjelmointia. Siitä löytyy poikkeusten käsittely, jolloin vir- hetilanteisiin on helppo varautua. (Tuovinen 2004.) Pythonin perusajatuksena on pitää koodi mahdollisimman lyhyenä. Se on mahdol- lista, kun käytetään runsaasti kirjastoja ja rakenteita. Sen avulla koodi säilyy helposti luettavana. Tavoitteena onkin, että koodi muistuttaisi mahdollisimman paljon eng- lannin kieltä. Sen vuoksi muuttujien nimiin kannattaa kiinnittää huomiota, että ne oli- sivat mahdollisimman kuvaavia. (Tuovinen 2004.) Sisennyksillä on suuri merkitys. Niitä käytetään koodilohkojen merkitsemiseen. Erilli- siä sulkeita ei käytetä, kuten C++:ssa. Tällainen käytäntö helpottaa koodin lukemista, mutta lisää inhimillisen virheen mahdollisuutta. Käytetyllä editorilla on tässä ratkai- seva merkitys. Jos lohkoittain sisentäminen on mahdollista, virheen mahdollisuus pienenee ratkaisevasti. (Tuovinen 2004.) Pythonissa tietotyypit määritellään dynaamisesti. Tämä tarkoittaa sitä, että muuttu- jan tyyppi määräytyy sinne kirjoitettavan datan perusteella. Perustietotyyppien li- säksi Pythonissa on tehokkaita monimuotoisen datan käsittelyyn tarkoitettuja tyyp- pejä. Ne ovat monikko (tuple) ja sanasto (dict). (Tuovinen 2004.) 49 Merkkijonojen käsittelyyn siinä on tehokkaat menetelmät. Niitä voidaan käsitellä aritmeettisten laskutoimitusten tavoin. Esimerkiksi kaksi merkkijonoa voidaan yhdis- tää käyttämällä + operaattoria: merkkijono3 = merkkijono1 + merkkijono2. Lisää hyviä esimerkkejä löytyy Tuovisen kandidaatintutkielmasta. Merkkijonon osien poi- miminen on myös helppoa. Sitä varten siinä on oma operaattori. Taulukossa 2 on esi- merkkejä sen käytöstä. Merkkijonoissa ensimmäinen indeksi saa arvon 0. (Tuovinen 2004.) Taulukko 2. Esimerkkejä merkkijonon käsittelystä Pythonissa operaatio tulos selitys merkkijonomuuttuja sanasota koko merkkijono merkkijonomuuttuja[:] sanasota koko merkkijono merkkijonomuuttuja[3] a merkki indeksistä 3 eli 4. merkkijonomuuttuja[2:5] nas merkit indeksien 2- 4 väliltä merkkijonomuuttuja[4:] sota merkit indeksistä 4 loppuun asti merkkijonomuuttuja[-4:] sota neljä merkkiä lopusta merkkijonomuuttuja[:-4] sana muut paitsi neljä merkkiä lopusta Listojen (array) käsittely on myös helppoa. Sen alkioihin voidaan tallettaa monen tyyppistä dataa. Ne voivat sisältää esimerkiksi numeroita, tekstiä, toisia listoja, funk- tioita yms. For-lause tukee hyvin listan käsittelyä. Listan pituuteen ei tarvitse kiinnit- tää huomiota. For-toistorakenteessa määrätään vain, että jokainen listan alkio ote- taan vuorollaan käsittelyyn. Kuviossa 18 on esimerkki Pythonin for-lauseesta. (Tuovi- nen 2004.) Kuvio 18. Esimerkki Pythonin for-lauseesta Monikko eli tuple on listan kaltainen tietorakenne. Se määritellään samaan tapaan kuin lista, mutta siinä ei käytetä hakasulkuja. Monikon alkioiden arvoja ei voi muut- taa luonnin jälkeen, joka onkin ainoa ero listaan nähden. (Tuovinen 2004.) numerolista = [1,4,34,78,43] summa = 0 for alkio in numeroLista: summa =+ alkio 50 Sanasto eli dict on avain arvo pareja sisältävä rakenne. Se muistuttaa erittäin paljon JSONissa käytettyä object-muotoa. Pythonissa onkin hyvä tuki JSONin käyttöön. Siinä on valmis kirjasto JSON-muotoisen datan käsittelyyn. (Tuovinen 2004.) Pythonin erikoisuus on generaattoreiksi kutsuttu rakenne. Sellaisia ei ole tarjolla mo- nissa ohjelmointikielissä. Yield generaattorin avulla on mahdollista ajaa funktioita osissa. Tämä tarkoittaa sitä, että funktion ajo voidaan jättää kesken ja jatkaa keskey- tyskohdasta epämääräisen ajan kuluttua, kutsuvan ohjelman käskystä. (Tuovinen 2004.) Pythonissa on JSON-kirjaston lisäksi runsaasti muitakin kirjastoja. Niitä ovat esimer- kiksi säännöllisten lauseitten (regular expressions) käsittelyyn tarkoitettu kirjasto ni- meltään re, merkkijonojen käsittelyyn kirjasto string, yleinen matematiikkakirjasto math jne. Python dokumentaation mukaan kirjastoja on kaiken kaikkiaan yli 250 kap- paletta. Sen vuoksi uusia ominaisuuksia ohjelmoitaessa kannattaakin selvittää löy- tyykö valmis toteutus jo jostain kirjastosta. (Tuovinen 2004.) 3.6.3 PHP PHP on web-ympäristössä käytetty erittäin suosittu skriptaus kieli. Sillä on mahdol- lista kirjoittaa itsenäisiä php-tiedostoja tai se voidaan sijoittaa HTML-tiedoston sisään tagin sisään. PHP:n vahvuuksiin kuuluu vahva integroituminen muihin web-työkaluihin, kuten Apache-serveriin ja MySQL:ään. Alun perin PHP oli puhtaasti lausepohjainen ohjelmointikieli. Uusimpiin versioihin on lisätty myös olio-ohjelmointi mahdollisuudet sekä poikkeuksien hallinta. (Gillmore 2005, 1-8.) PHP-kielen syntaksi on hyvin lähellä C-, Java- ja Perl-ohjelmointikieliä. Lohkot esimer- kiksi merkitään samalla tavalla aaltosuluilla kuin C-kielessäkin. Myös for-toistora- kenne on samanlainen. (Gillmore 2005, 85) PHP on dynaaminen ohjelmointikieli. Siinäkin muuttujan tyyppi määräytyy siihen tal- letettavan datan perusteella. PHP:stäkin löytyy tavanomaiset perustyypit. PHP:n tau- lukko (array) -tyyppiin voi tallettaa kahdenlaista dataa. Se voi olla perinteisessä lista muodossa, jolloin arvot seuraavat toisiaan pilkulla erotettuna. Silloin alkioihin viita- 51 taan indekseillä. Toinen mahdollisuus on muodostaa taulukko avain arvo pareista. Sil- loin rakenne muistuttaa lähinnä JSON-objekti tyyppiä. (Achour, Betz, Dovgal, Lopes, Magnusson, Ricter, Sequy, Vrana, and others 2016.) PHP:ssä on myös käytettävissä objekti (object) tyyppi. Se ei kuitenkaan ole samanlai- nen kuin JSONin objekti. PHP:ssä se liittyy vahvasti luokkiin. Käytännössä luokasta luotu olio on PHP:ssä objekti tyyppinen muuttuja. (Achour, Betz, Dovgal, Lopes, Magnusson, Ricter, Sequy, Vrana, and others 2016.) Merkkijonojen käsittelyyn itse PHP:ssä on niukasti työkaluja. Sitä varten siihen on lii- tetty strings niminen kirjasto, jolla voidaan käsitellä merkkijonoja monipuolisesti. Pyt- honin kaltaisia helppoja merkkijonon käsittelytapoja ei kuitenkaan ole tarjolla. (Achour, Betz, Dovgal, Lopes, Magnusson, Ricter, Sequy, Vrana, and others 2016.) Myös PHP-ohjelmoijille on tarjolla runsaasti kirjastoja. Dokumentaation mukaan niitä on tarjolla n. 200 kappaletta. PHP:n tapauksessa on myös järkevää tutkia kirjastotar- jonta ennen ohjelmoinnin aloittamista. (Achour, Betz, Dovgal, Lopes, Magnusson, Ricter, Sequy, Vrana, and others 2016.) 3.6.4 Ruby Ruby on Pythonin tapaan tulkattava kieli. Siinä on monia ominaisuuksia, jotka löyty- vät myös Pythonista ja Perlistä. Siinä on lisäksi piirteitä monista muistakin ohjelmoin- tikielistä. Se perustuu täysin olio-ohjelmointiin. Kielen kehittäjällä on ollut tavoit- teena tehdä ohjelmointikieli, jolla työskentely on hauskaa. (Collinbourne 2011.) Syntaksi muistuttaa paljon Pythonia. Ohjelman lohkot loppuvat aina end-määree- seen. Sisennyksillä ei siten ole niin suurta merkitystä kuin Pythonissa. Tavoitteena tässäkin on englannin kieltä muistuttava syntaksi Pythonin tapaan. (Collinbourne 2011.) Muuttujien tietotyypit määräytyvän tässäkin tapauksessa dynaamisesti. Kielestä löy- tyvät normaalit perustietotyypit, kuten nykyaikaisesta ohjelmointikielestä pitääkin. Taulukko (array) -tyyppi toimii myös samaan tapaan kuin Pythonin listatyyppi. Tässä- kin tapauksessa on mahdollista tallettaa samaan taulukkoon tyypiltään vaihtelevaa dataa. (Slagell 2014.) 52 Merkkijonojen käsittely on yhtä helppoa ja tehokkasta kuin Pythonissakin. Syntaksi- kin on lähes samanlainen. Pieniä eroja löytyy, mutta käytännössä niillä ei ole merki- tystä. Lopputulokseltaan samanlaiset operaatiot ovat mahdollisia myös Rubylla. (Sla- gell 2014.) Ruby tuntee myös objekti-tietotyypin. Sitä käytetään samaan tapaan kuin PHP:n vas- taavaa tyyppiä. Mistään dokumentaatiosta ei löydy tietotyyppiä, joka tukisi talletusta avain arvo periaatteella. Saatavilla on kuitenkin kirjasto JSON-datan käsittelyyn. (Standard Library Documentation 2016; Slagell 2014.) Rubyssakin on tarjolla runsaasti erilaisia kirjastoja. Tarjolla niitä on noin 100 kappa- letta. Tarjonta ei ole siten niin suuri, kuin Pythonissa ja PHP:ssä. Tämäkin valikoima lienee kuitenkin riittävä. (Standard Library Documentation 2016.) 3.6.5 Projektin näkökulma Kaikista ohjelmointikielistä löytyy tarvittavat elementit back-end ohjelmiston toteu- tukseen. Siinä mielessä toimivan ohjelmiston olisi voinut tehdä kaikilla vaihtoeh- doilla. Projektiin oli valittu etukäteen back-end ohjelmointikieleksi Python. Yksi tekijä sen valintaan on ollut aikaisempi kokemus siitä. Valinta on mitä ilmeisimmin osunut oi- keaan. Python-koodi on erittäin helppolukuista. Sillä on helppo tehdä tiivistä ja yti- mekästä koodia. Merkkijonojen käsittely on myöskin erittäin helppoa. Projektissa käytettiin runsaasti Pythonin dict-tietotyyppiä. Sen avulla oli helppo käsi- tellä JSON-muotoista dataa. Varsinkin mittarin asetusten käsittelyssä dict-tyypistä oli erityisen paljon hyötyä. PHP:stä vastaava tuki olisi löytynyt, mutta Ruby:sta ei. Tämä on merkittävin syy, miksi Python on parempi valinta kuin Ruby. PHP-koodi ei puolestaan ole niin selkeää kuin Python. Merkkijonojen käsittelyssä on myöskin omat puutteensa. Näiden syiden perusteella PHP:kään ei vaikuta niin käytet- tävältä ohjelmointikieleltä. Kirjastoja Pythonille on tarjolla riittävästi. Projektissa käytetään vain muutamia kirjas- toja valtavasta tarjonnasta. Mitä ilmeisimmin vastaavat kirjastot löytyvät myös PHP:stä ja Ruby:sta. 53 3.7 Python kirjastot 3.7.1 Yleistä Tässä luvussa esitellään Pythonin päälle valittuja kirjastoja, joita ei esitellä Pythonin omassa dokumentaatiossa. Kyseessä ovat Tornado framewrok ja Dataset-tietokanta- rajapinta. Tietyssä mielessä voidaankin puhua kielen laajennos moduuleista. Pythonille on tarjolla useita framework vaihtoehtoja. Python dokumentaation mu- kaan niitä on tarjolla n. 50 kpl. Sivuston mukaan kolme suosituinta framework-paket- tia ovat Django, TurboGears ja web2py. Kaikki tuotteet mainostavat, että niiden käyttö helpottaa ja nopeuttaa sivustojen kehitystä. Näin varmaan onkin, koska pake- tit sisältävät valmiit rakenteet mm. palvelupyyntöjen käsittelyyn. (Vosloo 2016.) 3.7.2 Tornado framework Projektiin oli etukäteen valittu Tornado framework. Se on skaalautuva ja nopea jär- jestelmä. Se sopii erityisesti sovelluksille jotka vaativat pitkäkestoista yhteyttä palve- limen ja sovelluksen välille. Tornado framework muodostaa yhdessä HTTP- palvelimen kanssa fullstack-toteutusympäristön. (Tornado 2016.) Tornado framework koostuu neljästä osasta: 1. Varsinainen web framework hoitaa palvelupyyntöjen käsittelyn. 2. HTTP-toteutus palvelimelle ja sovelluksille. 3. Asynk- roninen verkko kirjasto. 4. Kirjasto asynkronisen ohjelmakoodin luontiin, jolla voi- daan käsitellä Pythonin-generaattori rakenteita. (Tornado 2016.) Perinteisesti web-sovelluksissa pitkäkestoisien yhteyksin hallintaan on käytetty omaa säiettä jokaiselle yhteydelle. Tämä on yleensä kallista ja aiheuttaa resurssien tuhlaa- mista. Sen vuoksi Tornado frameworkissa on yksisäikeinen viestijono. Se tarkoittaa sitä, että ainoastaan yksi operaatio voi olla aktiivisena samaan aikaan. Sen vuoksi muut toiminnot eivät voi keskeyttää toimintoa. (Tornado. 2016.) Tornado sovelluksen rakenne on yksinkertainen. Se koostuu käynnistyksessä luota- vasta palvelinsovelluksesta ja siihen liitettävistä käsittelijöistä. Esimerkki yksinkertai- sesta sovelluksesta kuviossa 19. Siinä on nähtävissä em. osat. Alimpana on sovelluk- sen käynnistys, joka alkaa main-funktiossa. Varsinainen käynnistys suoritetaan Funk- tiossa make_app(). Parametrina sille annetaan palvelupyynnöt, joita se palvelee. 54 Tässä tapauksessa niitä on vain yksi. Se käsitellään, kun palvelupyyntö tulee palvelun juureen. Vastaanotettu palvelupyyntö käsitellään MainHandlerissa. Käytännössä tässä tapauksessa näyttöön kirjoitetaan ”Hello, world”. (Tornado 2016.) Kuvio 19. Esimerkki Tornado-sovelluksesta (Tornado 2016.) Kyseessä on GET-metodilla tehty palvelupyyntö. Se näkyy käsittelijä luokan sisälle kir- joitetun funktion nimestä. POST-tyyppiselle palvelupyynnölle voidaan tehdä oma kä- sittelijä kirjoittamalla erillinen funktio nimeltä post. (Tornado 2016.) Tornado frameworkissa on mahdollista käyttää malli eli template pohjia HTML- tiedostoista. Tämä pohja sisältää HTML-koodin lisäksi yksinkertaisella mallinnuskie- lellä tehtyjä osuuksia, joita täydennetään Tornado frameworkin tarjoamalla render- funktiolla. Kuviossa 20 on esimerkki HTML-mallista ja sitä vastaavasta render-kut- susta. HTML-pohjassa mallinnuskielen osuudet löytyvät sulkeiden {{…}} ja {%...%} vä- listä. Title-osuuteen laitetaan suoraan arvo render-kutsun parametrista title. Listaa täydennetään for-toistorakenteella, jossa sinne täydennetään items-parametrin sisäl- tämät alkiot. Tällä tavalla back-end -sovelluksella on mahdollista muodostaa helposti dynaamisia HTML-sivuja. (Tornado 2016.) Tornado frameworkissa on runsaasti toimintoja, joita tässä ei ole mahdollista esitellä. Siitä löytyy mm. asynkronisia palvelupyyntöjen käisttelyä yms. Projektissa käytettiin edellä esiteltyjä Tornado frameworkin ominaisuuksia. Niiden avulla on helppo täy- dentää HTML-sivujen sisältöä. Monimutkaisempia palveluja ei käytännössä käytetty. import tornado.ioloop import tornado.web class MainHandler(tornado.web.RequestHandler): def get(self): self.write("Hello, world") def make_app(): return tornado.web.Application([ (r"/", MainHandler), ]) if __name__ == "__main__": app = make_app() app.listen(8888) tornado.ioloop.IOLoop.current().start() 55 Kuvio 20. HTML mallipohja ja sitä vastaava render-kutsu (Tornado 2016) 3.7.3 Python dataset Python-dataset on tietokannan käytön helpottamiseen tarkoitettu kirjasto. Rajapin- tamoduulin tarkoituksena on peittää SQL-rajapinta. Sen avulla relaatiotietokantaa voi käyttää samaan tapaan kuin JSON-muotoista tiedostoa tai NoSQL-tietokantaa. Data- set ei pakota käyttämään jotain tiettyä tietokantaa. Ainkin SQLite, MySQL tai Post- greSQL ovat mahdollisia. (Aisch, Lindenberg, Wehrmeyer 2015.) Python-datasetissa on seuraavia ominaisuuksia. Jos sarake tai taulu puuttuu tieto- kannasta ja siihen yritetään kirjoittaa dataa, se luodaan automaattisesti. Rivi lisätään automaattisesti tauluun, jos annetulla avaimella määriteltyä riviä ei löydy taulusta. Jos se löytyy, rivi päivitetään. Tietokannan sisältämä data voidaan hakea helposti skripteillä JSON-muotoiseen tiedostoon. (Aisch, Lindenberg, Wehrmeyer 2015.) Datasetin rajapinnassa data voidaan esittää Pythonin dict-muodossa. Dataset osaa muuntaa lähetetyn datan SQL:n ymmärtämään muotoon. Se pystyy luomaan taulun sarakkeet dict-tyypin avaimien perusteella. (Aisch, Lindenberg, Wehrmeyer 2015.) Kun tietoa haetaan tietokannasta, parametrina annetaan avain arvo pari, joka kertoo haettavan sarakkeen ja kentän arvon. Paluuarvona saadaan taulukko, jossa on anne- tut arvot sisältävät rivit. Rivi on muodossa ordered dict, joka on yksi Pythonin data- esitysmuoto. Se on lähes samanlainen rakenne kuin dict. Siinä avaimet on kuitenkin {{ title }} class MainHandler(tornado.web.RequestHandler): def get(self): items = ["Item 1", "Item 2", "Item 3"] self.render("template.html", title="My title", items=items) 56 järjestetty aakkosjärjestykseen. Alkioihin voidaan viitata samalla tavalla kuin dict-tyy- pissäkin. (Aisch, Lindenberg, Wehrmeyer 2015.) Dataset soveltuu ainoastaan yksinkertaisten tietokantahakujen tekoon. Haku on mahdollista ainoastaan kahden sarakkeen perusteella. Jos halutaan tehdä monimut- kaisempia kyselyjä, täytyy käyttää erillistä funktiota, jolla voi välittää itse tehtyjä SQL- komentoja tietokantaan. (Aisch, Lindenberg, Wehrmeyer 2015.) Python dataset laajennus otettiin käyttöön projektissa helpottamaan tietokantaraja- pinnan käyttöä. Se peittikin tietokannan tehokkaasti. Tietokannan käyttö oli helppoa. Taulut ja sarakkeet syntyivät automaattisesti. Datasetin käyttö aiheutti muutamia ongelmia. Kehitystyön aikana kenttien nimet muuttuivat jonkin verran. Ne täytyi päivittää käsin tietokantaan. Funktioita raken- teen muuttamiseen ei ole eikä kertakäyttöistä funktiota välttämättä kannata tehdä. Joissakin tilanteissa tuli vahingossa virheellisiä nimiä talletettavan datan avaimiin. Ne näkyivät ylimääräisinä sarakkeina tietokannassa. Siitä ei tullut virheilmoitusta ja var- sinainen vika jäi huomaamatta. Suurimmat ongelmat dataset aiheutti kuitenkin lopullisen tuotanto palvelimen käyt- töönotossa. Koska kenttien tietotyyppeihin ei voinut vaikuttaa, dataset loi kaikki tie- tokannan kentät merkkijonoiksi. Kun dataa haettiin tietokannasta, mikään ei toimi- nut, koska data oli väärässä muodossa. Tilanne korjautui päivittämällä tietokannan kenttien tietotyypit oikeiksi. Palvelimelle ei ollut erikseen tehty tietokannan alustus- skriptiä. Se olisi kannattanut, silloin tältäkin ongelmalta olisi vältytty. 3.8 Front-end -toteutus 3.8.1 Yleistä Front-end käsitteelle on vaikea löytää virallista määritelmää. Sillä tarkoitetaan käyttä- jälle näkyvää visuaalista asiakassovellusta. Karkeasti ajateltuna sen voidaan ajatella tarkoittavan käyttäjän selaimella tai päätelaitteella näkyvää palvelun osaa. 57 Front-end -toteutuksessa työkaluvalintaan ei ole mahdollista juurikaan vaikuttaa. Käytännössä front-end ohjelmoinnissa käytetään kolmea ohjelmointi- tai kuvaus- kieltä, jotka ovat HTML, CSS ja JavaScript. Kahta ensimmäistä käytetään jokaisessa asiakassovelluksessa. Nykyään myös JavaScript on osana lähes kaikissa asiakassovel- luksissa. Kehittäjän valintamahdollisuudet jäävät lähinnä JavaScript-kirjastojen valin- taan ja siihen kuinka paljon sivujen dynaamisuudesta toteutetaan JavaScriptillä ja kuinka paljon sitä tehdään palvelimella. 3.8.2 HTML-kuvauskieli HTML (HyperText Markup Language) on www-sivujen perusta. Käytännössä kaikki mitä selaimella näytetään, on kuvattu sillä. Ensimmäiset www-sivut olivat suoraan HTML:llä kuvattuja staattisia sivuja, jotka sisälsivät lähinnä tekstiä ja linkkejä toisille sivuille. Muuta interaktiivisuutta sivustoilla ei ollut. (Sarja 2012.) Kuviossa 21 on esimerkki HTML-sivusta. Ensimmäisellä rivillä kerrotaan käytettävä HTML-versio, sivuston kieli yms. tietoja. Perässä on varsinainen HTML-osuus. Se ja- kautuu kahteen osaan. Head sisältää otsikkotietoja, joita ei suurelta osin näytetä käyttäjälle. Poikkeuksena on title, joka näkyy otsikkona selaimen välilehdellä (ks. Ku- vio 22). Kuvio 21. HTML esimerkki Body sisältää varsinaisen HTML-koodin, joka näytetään käyttäjälle selaimen ikku- nassa. Tässä esimerkissä on vain kaksi riviä, otsikko ja yksi kappale tekstiä. Kuviossa 22 kuvion 21 esimerkki on haettu selaimelle. Esimerkki

Terve

Pieni HTML esimerkki.

58 Kuvio 22. HTML esimerkki selaimella katsottuna HTML itsessään ei tue lainkaan sivustojen dynaamisuutta. Sen vuoksi se tehdään muilla keinoilla. Siihen on tarjolla kaksi keinoa. Palvelinohjelmistot voivat generoida HTML-koodia tai JavaScriptillä muutetaan näytettävää sivua lisäämällä, päivittämällä tai tuhoamalla HTML-elementtejä. Tarpeiden muuttuessa HTML-standardi on kehittynyt paljon. Tällä hetkellä se on edennyt versioon 5. Sitä pidetäänkin yleisesti merkittävänä parannuksena. Osittain sille on asetettu liiankin suuria odotuksia. Itseasiassa HTML5 on joissakin yhteyksissä laajempi käsite. Siihen lasketaan kuuluvaksi itse HTML5-kieleen tehtyjen lisäysten li- säksi CSS:ään ja JavaScriptiin tulleet uudet ominaisuudet. (Korpela, Lehdonvirta 2013.) HTML5:ssa on tullut käyttöön ainakin seuraavat uudet asiat: Piirtoalusta (canvas), jo- hon voidaan piirtää vektorigrafiikkaa lähinnä JavaScriptin avulla. Videoiden katselu- mahdollisuus suoraan selaimessa sivulla olevan koodin avulla. Paikkatietojen käsit- tely, jolla voidaan mukauttaa palveluita käyttäjän sijainnin perusteella. Selainmuisti, joka on selvästi kehittyneempi datan tallennustapa kuin evästeet. Uusia piirteitä lo- makkeiden tietokenttiin sekä tiedon tarkistukseen. Välimuisti, jonka avulla selain voi ladata valmiiksi sovelluksen tarvitsemat tiedostot. (Korpela 2011.) 59 3.8.3 JavaScript JavaScript on ensisijaisesti selaimella web-ympäristössä ajettava tulkattava skripti- kieli. Sen avulla on mahdollista tehdä HTML-sivuista dynaamisia ja lisätä helposti vuo- rovaikutteisuutta sivustolle. Käyttäjän toimiin voidaan reagoida nopeasti ja siten saa- daan hyvä käyttötuntuma. (Aho 2015.) JavaScriptissä muuttujien tyyppi määräytyy dynaamisesti. Syntaksi on hyvin lähellä C- kieltä, Javaa ja Perliä. C-keileen verrattuna JavaScript on kuitenkin kevyempi. Ja- vaScript voidaan kirjoittaa HTML-koodin sekaan tagien väliin. Toi- nen vaihtoehto on kirjoitus erilliseen JavaScript tiedostoon (xxx.js), joka ladataan erikseen HTML-sivulle. (Aho 2015.) JavaScript näkee HTML-elementit DOM (Document Object Model) avulla. Ne näkyvät JavaScriptille olioina. Kuviossa 23 on kuvion 21 esimerkki Firefox-selaimen DOM in- spectorilla tarkasteltuna. Kuviosta voidaan havaita, että HTML-sivu näkyy DOM- mallissa puumaisena rakenteena. HTML-dokumentin juureen viitataan aina mää- reellä document. Yksittäinen elementti voidaan ottaa käsittelyyn monella tavalla. Kuvio 23. HTML esimerkki DOM inspectorilla tarkasteltuna 60 Tarkempi esittely on taulukossa 3. Esimekiksi kuviossa 21 olevasta rakenteesta voi- daan valita otsikko ja teksti käsiteltäväksi seuraavasti: document.getElementById(”otsikko”); document.getElementByName(”teksti”); Taulukko 3. JavaScript: HTML-elementin valinta funktiot (Blaze 2008.) operaatio selitys getElementsByTagName(tagname) Valinta HTML-tagin avulla getElementById(elementId) Valinta Id-attribuutin avulla getElementsByName(elementName) Valinta name-attribuutin avulla Kun elementti on valittu jollain edellä mainitulla tavalla, sille voidaan tehdä erilaisia operaatioita. Esimerkiksi teksti voidaan vaihtaa toiseen tai tekstin tyylimäärittely, ku- ten väri tai fontti, voidaan vaihtaa. (Blaze 2008.) JavaScriptin erikoisuutena on toisen funktion sisään kirjoitettavat callback-funktiot. Sellainen ajetaan, kun sovellus odottaa jotain tapahtuvaksi. Esimerkiksi hiiren napin klikkauksen jälkeen tai Ajax-palvelupyynnön vastauksen saavuttua voidaan ajaa call- back funktio. Kuviossa 9 (luku 3.4.2) on esimerkki Ajaxin yhteydessä käytetystä call- back-funktiosta. Tällä tavalla JavaScriptillä on mahdollista tehdä muutoksia sivustolle lataamatta sitä uudelleen. (Javascript callbacks 2016.) HTML5:n myötä JavaScriptin käyttö on yleistynyt. Sen päälle on kehitettykin runsaasti kirjastoja ja sovelluskehyksiä. Niitä on tehty lähinnä kahdesta syystä. Ensimmäinen on JavaScriptin heikkouksien peittäminen. Esimerkiksi JavaScript ei toimi samalla ta- valla kaikilla selaimilla. Sen vuoksi koodin optimointi ja testaus saattaa olla haastavaa ilman kirjastojen käyttöä. Toiseksi niiden avulla helpotetaan JavaScript-ohjelmointia, koska monet ovat kokeneet sen erittäin vaikeaksi. Käytetyimpiin kirjastoihin kuuluu tällä hetkellä jQuery. Käytetyin sovelluskehys on puolestaan Angular.js. Tässä doku- mentissa esitellään myöhemmin projektissa käytetyt JavaScript kirjastot. (Aho 2015.) 3.8.4 CSS-tyylimäärittelyt HTML-kuvauskielellä ja JavaScriptillä ei vielä ole mahdollista tehdä näyttäviä sivus- toja. Seurakseen ne vaativat myös CSS-kielellä tehtyjä tyylimäärittelyjä. Niiden avulla 61 määritellään HTML-elementtien lopullinen ulkonäkö ja sijainti avatulla www-sivulla. Alun perin CSS:n avulla erotettiin sivuston sisältö ja ulkoasu toisistaan. Siten doku- mentin ulkoasu on huomattavasti helpompi määritellä. (Sarja, Tarmia 2011.) CSS:n eduiksi mainitaan seuraavaa: Ulkoasu on helpompi päivittää, kun määrittelyt ovat yhdessä tiedostossa. Kun turhat tyylimäärittelyt poistetaan, HTML-tiedostojen koko pienenee ja sivut latautuvat nopeammin. Erilaisille medioille on mahdollista tehdä omat tyylimäärittelyt. CSS-määrittelyillä voidaan ohjata kaikkea mikä vaikuttaa sivuston typografiaan. (Sarja, Tarmia 2011.) CSS-kielen syntaksi on yksinkertainen. Kuviossa 24 on esitetty esimerkki siitä. Ensim- mäisellä rivillä on valitsin eli selector. Sen avulla valitaan dokumentin osa, johon määrittely vaikuttaa. Tässä tapauksessa kyseessä on HTML-dokumentin body-ele- menttiin vaikuttava määrittely. Aaltosulkujen sisällä on varsinaiset tyylimäärittelyt. Kuvio 24. Esimerkki CSS-määrittelystä Valitsimia on kolmea perustyppiä. Ne on esitetty taulukossa 4. Sarakkeiden esimerkki ja HTML-sisältö viittaa kuviossa 21 olevaan HTML-esimerkkiin. Taulukko 4. CSS-perusvalitsimet valitsin esimerkki HTML luokkavalitsin .kappale class="kappale" tunnistevalitsin #otsikko id="otsikko" elementtivalitsin body Näiden perusvalitsimien lisäksi voidaan käyttää valitsimien yhdistelmiä erotettuna erilaisilla operaattoreilla. Kattava esitys CSS-valitsimista löytyykin tämän kappaleen viitteen kertomasta osoitteesta. (CSS Selector Reference 2016.) body { background-attachment: fixed; font-family: Maven Pro, Segoe UI, Arial; color: #AAAAAA; background: url(../images/bg_main.jpg) no-repeat center top fixed; } 62 CSS-tyylimäärittelyt periytyvät DOM-puussa äitioliolta lapsioliolle. Otetaan esimerkki kuvion 21 tapauksesta. Jos body-elementille annetaan fontti määrittely, se periytyy kumpaankin sen alla olevaan elementtiin eli otsikkoon ja varsinaiseen tekstiin. Riip- puu elementin tyypistä miten periytyvät ominaisuudet vaikuttavat. Osa saatetaan sen vuoksi jättää huomioimatta. Jos elementille on määritelty uusi arvo samalle mää- reelle, se korvaa periytyvän arvon. (Sarja, Tarmia 2011.) CSS-kielestä on viimeksi julkaistu versio 3. Se on taaksepäin yhteensopiva ja vanha muotorakenne on säilytetty. Määreitä on tarkennettu mutta ei niinkään muutettu. Siihen on lisätty uusia ominaisuuksia. Vanhoja ominaisuuksia on parannettu lisää- mällä uusia arvoja. Joitakin uusia määreitä on otettu lisäksi käyttöön. (Korpela 2013.) Merkittävin uusista asioista on @media-määre. Sen avulla voidaan määritellä erilaisia tyylimääreitä esimerkiksi näytön leveyden mukaan. Kuviossa 25 on esimerkki tällai- sesta määreestä. Tässä esimerkissä body-elementin taustaväri muutetaan kirkkaan vihreäksi, kun näytön leveys on suurempi kuin 480 pikseliä. (CSS3 @media Rule 2016.) Kuvio 25. Esimerkki CSS:n @media-määreestä (CSS3 @media Rule 2016.) CSS-tiedostot ovat aina staattisia. Dynaamiset osat puuttuvat, jonka vuoksi samaa määrittelyä voi joutua toistamaan useampaan paikkaan. CSS:n päälle onkin kehitetty laajennoksia, jotka helpottavat määrittelyjen tekoa. Tärkeimmät laajennokset ovat nimeltään Less ja Sass. Molemmat perustuvat CSS-esikääntöön. Niiden työkalujen avulla generoidaan varsinaiset CSS-määrittelyt. Ne mahdollistavat mm. muuttujien käytön määrittelyjen luonnissa. Silloin ei esimerkiksi tarvitse toistaa samaa määritte- lyä useamman tyylin sisään. Määrittelyn arvoa vaihdettaessa riittää, että arvo muute- taan vain yhteen paikkaan. (Myhrberg 2015.) @media screen and (min-width: 480px) { body { background-color: lightgreen; } } 63 3.8.5 Projektin näkökulma Projektissa oli itsestään selvää, että HTML- ja CSS-määrittelyjä täytyy käyttää. HTML:n dynaamiset osat generoitiin pääsääntöisesti JavaScriptillä. Vaihtuvaa dataa täydennettiin HTML-sivuille latauksen yhteydessä myös Tornado frameworkin ren- der-funktiolla. HTML:n käytössä ei ilmennyt mitään suurempia ongelmia. Elementit toimivat kuten on määriteltykin. Ohjeistusta löytyy verkosta riittävästi. Erittäin hyväksi paikasi osoit- tautui w3schools.com. Sieltä löytyy yksinkertaisia ja selkeitä esimerkkejä HTML-, CSS- ja JavaScript-määrittelyjen tekoon. Sivuston dynaamisuus toteutettiin tässä projektissa pääasiassa JavaScript toteutuk- sella. Sillä tavalla sivustot oli helppo toteuttaa. Heti sivun latautumisen jälkeen hae- taan monessa tapauksessa lisää dataa AJAXin avulla erillisellä HTTP-palvelupyynnöllä. Jälkeenpäin ajatellen näissä tapauksissa olisi kannattanut käyttää enemmän hyväksi render-funktiota. JavaScript koodia olisi silloin tarvittu huomattavasti vähemmän. Sa- moin HTTP-palvelupyyntöjen määrä olisi pienentynyt. Selkeiden CSS-määrittelyiden tekeminen osoittautui hankalaksi. Hyvin usein kävi, että ne tehtiin yhden elementin ehdoilla miettimättä kokonaisuutta. Tähän vaikutti tie- tysti myös se, että projektissa ei ollut missään vaiheessa selkeää graafista suunnitel- maa. Moni asia suunniteltiin tältä osin projektin edetessä asian tullessa ajankoh- taiseksi. Vaikka graafista suunnitelmaa ei ollut, sellainen olisi kannattanut tehdä en- nen kuin varsinaiseen tyylien määrittelyyn ryhdyttiin. Sen pohjalta olisi ollut hel- pompi muokata yleiskäyttöisemmät tyylit. 3.9 JavaScript kirjastot Projektissa käytettiin kahta JavaScript-kirjastoa. Ne olivat jQuery ja D3.js. Sovelluske- hyksiä ei käytetty. Seuraavaksi esitellään lyhyesti käytetyt kirjastot. 3.9.1 JQuery Asiakassovelluksissa käytetään yleisesti jQuery-kirjastoa, jonka avulla yksinkertaiste- taan JavaScript koodia ja joka helpottaa mm. sivuston ylläpitoa. Sen avulla peitetään 64 myös selaimien eroja, jotka on piilotettu kirjaston sisään. Millä tavalla JQuery sitten yksinkertaistaa JavaScriptin kirjoitusta? Kuviossa 26 on esimerkki tästä. (Korpela Leh- donvirta 2013.) Kuvio 26. Esimerkki kuinka jQuery helpottaa JavaScript koodausta (Castig 2015.) Kuvasssa on ensin JQuery-toteutus ja perässä sama JavaScript-toteutuksena. Kuten esimerkistä voi havaita, jQuery toteutus vaatii vain yhden rivin. Siitä huolimatta muutos voidaan tehdä kaikkiin goodbye-luokalla merkittyhin elementteihin. Perinteisellä JavaScriptillä toteutettuna tarvitaan mm. for-toistorakennetta elementtien käsittelyssä. (Castig 2015.) Helpotusta jQuery:n avulla saadaan useiden tapahtumien käsittelyyn. Siinä on mm. funktiot AJAX-palvelupyyntöjen hallintaan, efektien käyttöön sekä herätteiden ja DOM-objektien käsittelyyn. Lisäksi on vielä muitakin toimintoja joita tässä ei esitellä. (jQuery API 2016.) Mitkä ovat JQueryn kilpailijat? ExtJs ja MooTools ovat samankaltaisia. D3.js doku- mentaatiosta havaittiin, että silläkin olisi mahdollista tehdä samoja operaatiota kuin jQuerylla (Bostock 2015). Tässä yhteydessä niitä ei tutkita tarkemmin. Niiden vertailu on hankalaa, koska valmista vertailumateriaalia ei löytynyt. Tässä yhteydessä vertai- lutyöhön ei ollut mahdollisuutta. Projektissa käytettiin JQuerya DOM-objektien dynaamiseen käsittelyyn. Sillä hoidet- tiin myös AJAX-palvelupyynnöt. Käytännössä jQuery näkyy projektin JavaScrip-koo- dissa enemmän kuin JavaScript itse. jQuery: $(".goodbye").addClass( "selected" ); JavaScript: var d = document.getElementsByClassName("goodbye"); var i; for (i = 0; i < d.length; i++) { d[i].className = d[i].className + " selected"; } 65 3.9.2 D3.js D3.js on JavaScript-kirjasto, jonka avulla on mahdollista luoda graafisia esityksiä eri- laisista datoista. Siihen se käyttää apuna HTML:ää, SVG:tä (Scalable Vector Graphics) ja CSS:ää. Erillisiä graafisiin esityksiin tarkoitettuja plugin-työkaluja, kuten Adobe Flashia, ei tarvita. Se mahdollistaa graafiset esitykset myös ympäritöissä missä Adobe Flash ei toimi. (Bostock 2015.) Millaista grafiikkaa D3.js:llä on sitten mahdollista esittää? Perinteisten pylväs- ja viiva- diagrammien sekä ympyräkaavioiden lisäksi sillä on mahdollista tehdä moni- muotoisempia esityksiä. Niitä ovat mm. kupla-, verkko- ja puukaaviot sekä karttapoh- jien päälle tehdyt esitykset. Kuviossa 27 on esimerkki kuplakaaviosta, jossa on mu- kana interaktiivisuutta. Kun hiiren vie kuplan päälle, tulee näkyviin tarkempia tietoja siihen liittyvästä datasta. Lisää esimerkkejä erilaisista esityksistä löytyy tämän kappa- leen viitteen osoittamasta paikasta. (Golubovic 2016.) Kuvio 27. D3.js kirjastolla toteutettu interaktiivinen kuplakaavio (Carter 2012.) D3.js tarjoaa myös samankaltaisia toimintoja DOM-objektien käsittelyyn kuin jQue- ryssa. Ne eivät kuitenkaan ole sen ydintoimintoja. Jos tällaisia operaatiota tarvitaan 66 vähän ja käytössä on D3.js, jQuerya ei välttämättä kannata ottaa erikseen käyttöön. (Bostock M. 2015) Graafisten esitysten tekoon on tarjolla muitakin JavaScript kirjastoja. Niitä ovat aina- kin seuraavat: Chartist.js, FusionCharts, Dygraphs, Chart.js, Google Charts, Highcharts, Flot, n3-charts jne. Listasta tulisi aika pitkä. (Singhal 2015.) Chart.js-kirjastosta on kertynyt jonkin verran kokoemusta. Sen perusteella on ha- vaittu, että D3.js on huomattavasti monipuolisempi ja joustavampi työkalu. Chart.js:ssä on esimerkiksi X-akselin skaalauksessa rajoitteita, jotka joissakin tilan- teissa hankaloittavat sen käyttöä. Projektiin oli jo valmiiksi otettu käyttöön D3.js-kirjasto. Sen avulla sivustolle piirre- tään viivadiagrammeja. Näin ollen sen ominaisuuksista käytetään hyväksi vain murto osa. Voi olla, että tähän käyttöön valinta on turhankin raskas. Projektin aikataulun puitteissa ei kuitenkaan ollut mahdollisuutta tutkia muita vaihtoehtoja. Jälkeenpäin havaittiin, että Chart.js ei ainakaan olisi sopinut tähän käyttöön em. rajoitteen vuoksi. 4 Projektin toteutus 4.1 Yleistä Projektissa toimittiin Scrum-mallin mukaisesti, vaikka sitä ei virallisesti otettukaan käyttöön. Projektin aikajanalta ei kokonaisuutena pysty erottamaan määrittely, to- teutus ja testausvaiheita. Ainoastaan projektin alussa oli erillinen määrittelyjakso, jonka aikana kirjattiin järjestelmän vaatimukset Redmine-työkaluun, suunniteltiin tie- tokannan runko ja tehtiin luonnos rajapintojen rakenteesta. Projektin alussa etäkäyttöliittymästä oli valmiina prototyyppi, joka kelpasi sellaise- naan jatkokehitykseen. Uusia ominaisuuksia lisättiin ominaisuuksittain tekemällä en- sin määrittely, sitten toteutus ja saman tien ominaisuuden testaus. Scrum-mallin mukaisesti etäkäyttöliittymä pyrittiin pitämään koko ajan toimivana. Jo- kaisen julkaisun yhteydessä toimintoja lisättiin tai entisiä päivitettiin. Projektin aikana julkaisusykli vaihteli. Nopeimmillaan sykli oli useampi julkaisu päivässä ja pisimmil- lään noin viikon verran. Ominaisuuksien laajuus vaikutti tähän merkittävästi. 67 4.2 Aikataulu Projekti alkoi varsinaisesti marraskuun viimeisellä viikolla 2015. Projektin toteutuk- seen oli varattu aikaa hieman yli kaksi kuukautta. Sen jälkeen oli tarkoitus tehdä kat- tava järjestelmätestaus, jossa on mukana koko laitteisto. Vaatimusten kirjaamiseen oli varattu aikaa kuukausi, jonka jälkeen siirryttiin toteutus- ja moduulitestausvaihee- seen. Järjestelmätestauksen oli alkuperäisen aikataulun mukaan tarkoitus alkaa hel- mikuun 2016 alussa. Alkuperäinen aikataulu on näkyvissä kuviossa 28. Kuvio 28. Projektin aikataulu: alkuperäinen ja toteutunut Heti projektin alussa vaatimusten kirjaamisen aikana havaittiin, että toteutukselle va- rattu aika on liian lyhyt. Toiminnot ovat arvioitua monimutkaisempia. Todellista työ- määrää oli siinä vaiheessa vaikea arvioida, koska monelta osin määrittelyt olivat vielä puutteellisia. Aikataulussa oli täysin huomioimatta esimerkiksi graafisen ilmeen suun- nittelu. Vaatimusten kirjaaminen saatiin tehtyä aikataulun puitteissa. Se saatiin valmiiksi jou- lukuun puolivälissä 2015. Seuraavaksi siirryttiin kartoitusvaiheeseen, jossa selvitettiin prototyypissä valmiina olevat ominaisuudet. Samalla suunniteltiin rajapintoja ja tie- tokantaa. Tammikuun puolivälissä 2016 aloitettiin varsinainen toteutusvaihe. Tämä vaihe kesti lopulta toukokuun loppuun 2016 saakka. Vikakorjausta tehtiin vielä kesä- kuun 2016 aikana. Toteutunut aikataulu nähtävillä kuviossa 28. Aikataulun toteutumista hidasti selvästi graafisen suunnitelman puute. Monet asiat vaatimuksissa olivat lähinnä kirjauksia ominaisuuksista kuten pitääkin. Graafinen 68 suunnitelma olisi ottanut kantaa ominaisuuksien toteutukseen ja samalla siihen, mi- ten ominaisuudet sijoittuvat etäkäyttöliittymän sivurakenteeseen. Projektin suunnit- teluvaiheessa luotettiin ilmeisesti liikaa etäkäyttöliittymän prototyypin ulkoasuun ja sen soveltuvuuteen myös lopulliseen versioon. 4.3 Määrittelyvaihe 4.3.1 Yleistä Määrittelyvaiheeseen kuuluu vaatimus- ja toteutusmäärittely, jotka sisältävät myös palvelun rajapintojen määrittelyn. Lisäksi palvelun tietoturva täytyy ottaa huomioon jo tässä vaiheessa. Web-sovelluksissa tämä ei vielä riitä. Toteutuksen suunnittelussa täytyy tehdä lisäksi graafinen suunnitelma. Siinä kerrotaan miltä palvelu näyttää. Apuna tässä voidaan käyttää erilaisilla piirtotyökaluilla tehtyjä sivujen prototyyppejä. Adobella on mm. laaja valikoima tähän käyttöön soveltuvia työkaluja. 4.3.2 Vaatimusmäärittely Vaatimusmäärittelyn lähtökohtana oli mittariin kytketyn näyttöyksikön toiminta, joka oli vaatimusten kirjaamisen alussa huomattavasti valmiimpi kuin etäkäyttöliittymä. Vaatimukset eivät ole kuitenkaan kaikilta osin samoja, koska etäkäyttöliittymän ja mittarin näyttöyksikön välillä on toimintaeroja. Kaikkia näyttöyksikön toimintoja ei tarvita etäkäyttöliittymässä. Niitä ovat esimerkiksi näytön kontrastin säätö ja mittarin kalibrointi. Lisäksi etäkäyttöliittymässä on toimintoja, joita näyttöyksiköllä ei tarvita, kuten kirjautuminen ja käyttäjän rekisteröinti. Vaatimukset voidaan jakaa viiteen pääryhmään. Ne ovat seuraavat: 1. kirjautuminen ja rekisteröityminen 2. asetukset 3. mittaus ja tilatiedon seuranta 4. raportointi 5. ylläpitäjän toiminnot Kirjautumisen ja rekisteröitymisen vaatimukset eivät juuri poikkea tavallisien web- sovellusten vaatimuksista. Ainona poikkeuksena voidaan mainita mittarin pakollinen liittäminen käyttäjätunnukseen. Ilman sitä rekisteröityminen ei onnistu. Vaatimusten mukaan mittari tunnistetaan ennen rekisteröinnin hyväksymistä. Kuviossa 29 tähän 69 kohtaan liittyviä vaatimuksia ovat ”User Registration” ja ”User Login”. Kuvio 29. Rakeisen materiaalin kosteusmittarin vaatimukset Asetusten hallinta on etäkäyttöliittymän monimutkaisin toiminto. Vaatimuksia on runsaasti. Vaatimusmäärittelyvaiheessa niiden kirjaaminen toteutettiin huonosti. To- teutusvaiheen aikana ne muuttuivat vielä. Kiireen ja aikataulupaineiden vuoksi kirjaa- minen Redmineen unohtui. Sen vuoksi asetusten vaatimukset eivät suurelta osin pidä paikkaansa ja moni toiminto on täysin kirjaamatta vaatimuksiin. Kuviossa 29 tähän kohtaan liittyvät vaatimukset ovat ”Asetuksien muuttaminen” ja siihen liittyvät ala- kohdat. 70 Asetusten käsittelystä puuttuvat tai muuttuivat ainakin seuraavat kohdat: • Varmuuskopion tallettaminen: Käyttäjä voi tallettaa yhden asetussetin varmuuskopi- oksi palvelimelle. Lisäksi käyttäjällä on mahdollisuus tallettaa asetuksia varmuuskopi- oksi omalle tietokoneelle rajoittamattoman määrän. • Varmuuskopion palauttaminen: Käyttäjällä on mahdollisuus palauttaa asetukset mistä tahansa varmuuskopiolta. Palautuksen yhteydessä käytössä olevat asetukset menetetään. • Oletusasetusten käyttöönottaminen: Palvelimelle on talletettu yksi setti asetuksia oletusasetuksiksi. Käyttöönoton yhteydessä vanhat aktiiviset asetukset menetetään. • Hälytys asetusten vaatimukset: Käyttäjä voi itse antaa nimet välitettäville hälytyk- sille. • Kalibrointiasetukset: Palvelimelle talletetaan mittarin kalibrointiasetukset. Käyttäjällä ei ole kuitenkaan mahdollisuutta muuttaa ja tutkia niitä. Ne näkyvät pelkästään yllä- pidolle. • Muuttuneiden asetusten haku palvelimeta: Mittari kysyy itse, onko muutettuja ase- tuksia, koska etäkäyttöliittymä ei voi ottaa itse yhteyttä yksittäiseen mittariin. Mittaus ja tilatiedon seuranta osion vaatimuksia ei ole kirjattu yhtenäisen otsikon alle. Useimmat on kirjattu erillisinä yksittäisinä vaatimuksina. Niitä ovat seuraavat (Kuvio 29): Kuivauksen seuranta ja Kuivauksen pysäytys. Listasta puuttuvat kuivauk- sen tilatiedon näyttö, sekä hälytysten ja tilamuutosten näyttö. Raportoinnissa vaatimuksena on kuivausraportin tulostus jokaisesta kuivauserästä. Kuviossa 29 raportoinnin vaatimukset on kirjattu kohtaan ”Kuivausraporttien toimit- taminen” Ylläpitäjän toiminnot eivät ole mahdollisia peruskäyttäjälle. Laitetoimittajalla on tek- nisessä tuessa joitakin henkilöitä, jotka voivat tarkkailla kaikkien mittarien toimintaa. Vaatimuskodat on kirjattu otsikon ”Ylläpitäjän käyttäjätunnus” alle mukaan lukien sen alakohdat. Vaatimusten kirjaaminen tehtiin projektissa huolimattomasti. Laatuun olisi pitänyt kiinnittää huomattavasti enemmän huomiota. Graafisen ulkoasun suunnittelusta vaatimusten kirjaamisen rinnalla olisi ollut suuri apu. Molemmat olisivat tukeneet toisiaan. Graafinen suunnittelu olisi tuonut esiin puuttuvat vaatimukset. Niiden mää- rittelyn jälkeen myös graafinen ulkoasu olisi voitu suunnitella tarkemmin. Tämän vai- heen kunnollinen suunnittelu olisi nopeuttanut myös toteutusvaihetta. 71 4.3.3 Tietokannan suunnittelu Etäkäyttöliittymän prototyyppiin oli määritelty jo tietokantarakenne (ks. kuvio 30). Siinä oli kuitenkin vielä suuria puutteita. Sen vuoksi tietokantarakenne täytyi suunni- tella uudelleen. Soveltuvilta osin vanhaa käytettiin hyväksi. Käytettävissä oli taulut: käyttäjä, mittari ja mittaus. Käyttäjä ja mittari taulujen suhde on yksi yhteen. Mittari ja mittaus taulujen suhde on yksi moneen. Kuvio 30. Tietokantarakenteen alkutilanne Vaatimuksissa sanotaan, että käyttäjällä voi olla käytössään useampia mittareita ja yhdelle mittarille voi kytkeytyä useampi käyttäjä. Alkuperäinen rakenne ei tue tätä. Ongelma voidaan ratkaista lisäämällä lapsitaulu käyttäjä ja mittari taulujen väliin. Taulu kertoo mitä mittaria kukin käyttäjä käyttää. Kun yhteys lapsitauluun päin on yksi suhde moneen, vaatimus täytyy. Kuviossa 31 on tietokannan lopullinen rakenne. Siitä näkyy, että lapsitaulun lisäksi käyttäjällä ja mittarilla on suora yksi yhteen yh- teys. Se tarkoittaa aktiivisena olevaa mittaria, koska vain yhtä mittaria voidaan seu- rata kerrallaan. Mitä muuta dataa tietokannasta puuttuu? Mittarin asetuksille ei ole tilaa. Asetuksia on paljon. Tietokannan kannalta ne olisi mahdollista tallettaa yhteen tauluun. Mitta- rin ja palvelimen välinen rajapinta aiheuttaa asetusten käsittelyyn omat ongelmansa. Se heijastuu myös tietokantaan. Asetukset ryhmiteltiin sen vuoksi kuuteen tauluun asetusten luonteen perusteella. Kuviossa 31 asetukset on kuvattu yhtenä tauluna, vaikka ne todellisuudessa jakautuvat kuuteen tauluun. 72 Mittarilta tulevia hälytyksiä ja tilatietojen muutoksista kertovia viestejä ei talleteta. Niitä varten varataan yksi taulu. Kuviossa 31 taulu on nimellä Events. Kuvio 31. Tietokannan lopullinen rakenne Mittaus tauluun talletetaan mittaustietojen lisäksi myös senhetkisiä kalibrointitietoja. Niiden talletus havaittiin tarpeelliseksi. Sillä varmistetaan, että kaikki mittaustuloksen laskentaan vaikuttavat parametrit ovat tallessa mittausten jälkikäsittelyä varten. Kuviossa 32 on avattuna kaksi tietokannan taulua. Ensimmäinen on perusasetukset, joka on yksi kuudesta asetuksia sisältävistä tauluista. Toisena on nähtävillä mittari taulun sisältö. Tarkastellaan näitä siltä kannalta, kuinka ne soveltuvat muiden vastaa- van kaltaisten mittarien käyttöön, jos etäkäyttöliittymä olisi sama. Kuten kuviosta näkyy, kummassakin taulussa on mittarityyppiin liittyviä parametreja. Perusasetuksissa esimerkiksi on viimeisin eränumero, jota ei tarvita jatkuvatoimi- sessa prosessissa. Mittari taulussa on puolestaan statustietoja, joita ei välttämättä tarvita. Uuden mittarityypin myötä on mahdollista, että tauluihin tarvitaan lisää tie- toa. Jos ajatellaan, että tietokantaa käytettäisiin tässä muodossa, erityyppisten mitta- rien käyttöön tietokantaan kertyisi tarpeettomia kenttiä. Ne varaavat tietokannasta kuitenkin tilan, vaikka niitä ei tarvita mihinkään. Taulujen määrän lisääminen ei tunnu järkevältä, koska silloin yleiskäyttöisyyden merkitys menetettäisiin. 73 Kuvio 32. Kaksi tietokannan taulua sisältöineen. MongoDb toimisi tässä tapauksessa joustavammin, koska siinä voidaan tallettaa do- kumentti suoraan JSON-muodossa. Riittäisi yksi kokoelma, jonne mittarin kaikki tie- dot voisi tallettaa. Rakenteessa olisi tieto mittarin tyypistä, jonka perusteella olisi mahdollista hakea oikeat tiedot dokumentista. Dokumentit eivät sisältäisi tarpeetto- mia tietoja ja siten eivät veisi turhaa tilaa. 4.3.4 Rajapintojen määrittely Työssä täytyi määritellä toiminnot kahteen rajapintaan. Kummassakin käytetään ta- vallista ReST-tyyppistä HTTP-palvelupyyntö rajapintaa. Palvelimelta on yhteys sekä mittarille että asiakassovellukselle. Näissä rajapinnoissa on mahdollista käyttää osit- tain samoja palvelupyyntöjä. Palvelinsovelluksessa on oma käsittelijä 19 palvelupyyn- nölle. Taulukossa 5 on esimerkkejä niistä. 74 Taulukko 5. Esimerkkejä palvelupyynnöistä palvelupyyntö tarkoitus rajapinta metodit / Päänäytölle ohjautuminen kirjautu- misen jälkeen, muulloin aloitussi- vulle. sovellus GET /login kirjautuminen sovellus GET, POST /meter_data mittarin tietojen haku ja talletus sovellus GET, POST /settings/* asetusten haku ja talletus mittari ja sovellus GET, POST /measurement mittaus datan talletus mittari POST /update mittausdatan päivitys käyttäjän so- vellukseen sovellus (AJAX) GET /stop kuivauksen pysäytys sovellus (AJAX) GET /metering.csv mittausdatan haku käyrän piirtoa varten sovellus (AJAX) GET Etäkäyttöliittymän prototyypissä kaikki palvelupyynnöt tehtiin GET-metodilla. Toi- mintaa muutettiin samalla periaatteella kummasakin rajapinnassa. Palvelimelle tu- leva data lähetetään POST-metodilla ja dataa haetaan GET-metodilla. Alkuperäisen suunnitelman mukaan mittarin ja palvelimen välisessä rajapinnassa data siirretään JSON-muodossa. Tarkoitus oli, että data liikkuisi samassa muodossa kulkusuunnasta riippumatta. Lopullisessa versiossa tavoite ei kuitenkaan toteutunut. Mittarin GSM/WCDMA- modeemi rajoittaa datan lähetystä. Maksimissan datan pituus voi olla 254 merkkiä. Tämän rajoitteen vuoksi asetukset jaettiin kuuteen erilliseen settiin. Myöskään JSON- muotoisen datan lähetys ei toimi, vaikka modeemin käyttöohje niin kertookin. Näi- den rajoitteiden vuoksi käytäntö piti muuttaa. Mittari lähettääkin datan palvelimelle x-www-form-urlencoded-muodossa. Palvelimelta data lähetetään mittarille alkupe- räisen suunnitelman mukaisesti JSON-muodossa. 75 Voi olla, että modeemin rajoitteet ovat oikeasti ohjelmistovikoja modeemin ohjelmis- tossa. Niistä olisi kannattanut reklamoida modeemin valmistajaa ja vaatia teknistä tu- kea. Tämä mahdollisuus ei tullut mieleen rajapinnan käyttöönoton yhteydessä. Taulukossa 5 olevista esimerkeistä nostetaan esille asetusten käsittelyyn liittyvä pal- velupyyntö. Kuten jo aiemmin on kerrottu, asetusten käsittely on jaettu kuuteen osaan. Ne käsitellään kuitenkin samalla käsittelijällä. Asetusten käsittely URI:n lo- pussa on avainsana (key word), joka kertoo mistä asetussetistä on kyse. Avainsana sijoittuu taulukossa olevan tähden paikalle. Osassa asiakassovelluksen ja palvelimen välisissä palvelupyynnöissä käytettiin AJAX- rajapintaa. Sen käyttö lisäsi palvelupyyntöjen määrää. Vastaavasti datamäärä yksit- täisessä palvelupyynnössä oli pienempi. Miten etäkäyttöliittymän yleiskäyttöisyys toteutuu rajapinnoissa? Lähes kaikki palve- lupyynnöt ovat yleiskäyttöisiä. Niiden datarakenteella ei ole merkitystä palvelimen näkökulmasta. Vastaanotettu data talletetaan sellaisenaan tietokantaan. Asetusten jakaminen kuuteen settiin on oikeastaan ainoa mittariin liittyvä asia, joka näkyy raja- pinnoissa. Sekin ainoastaan yksilöidyn avainsanan muodossa. Muutama asiakassovellusrajapinnan AJAX-palvelupyyntö liittyy suoraan tämän tietyn tyyppisen mittarin käyttöön. Sellainen on esimerkiksi kuivauksen pysäytys. Tällaiset palvelupyynnöt eivät häiritse juurikaan yleiskäytettävyyttä. 4.3.5 Sivustorakenne ja graafinen ulkoasu Sivuston rakenne koostuu neljästä varsinaisesta sivusta. Jokaiseen on koottu joukko toimintoja, jotka liittyvät läheisesti toisiinsa. Liitteessä 1 on kuvattu sivuston rakenne, josta voi tunnistaa sivuston pääkohdat. Ne ovat seuraavat: aloitussivu, pääsivu, ase- tusten pääsivu ja ylläpitäjän sivu. Näiden mukaan sivusto jaettiin HTML-tiedostoihin. Sivuston graafisen ilmeen perustana on www.pehutec.com-palvelun ulkoasu. Väri- maailma ja graafinen ilme ovat soveltuvilta osin peräisin sieltä. Lomakkeiden ja pon- nahdusikkunoiden ulkoasu on suunniteltu tätä palvelua varten. Perussisällön lisäksi sivustolla on ponnahdusikkunoita ja muuta vaihtuvaa sisältöä. Kyseessä ei kuitenkaan ole perinteiset ponnahdusikkunat, jotka avaavat sisällön uu- 76 teen ikkunaan. Tässä tapauksessa ne ovat samalle HTML-sivulle upotettuja erillisiä si- vun osia, jotka ladataan taustalle näkymättömiin. Ne tulevat näkyviin, kun tietty toi- minto aktivoidaan. Kuviossa 33 on esimerkkinä käyttäjän rekisteröitymisessä käytetty ponnahdusikkuna. Kuvio 33. Esimerkki ponnahdusikkunasta Liitteessä 1 mainitaan toiminnon yhteydessä, jos siinä käytetään ponnahdusikkunaa. Muut päätoimintojen rinnalla tehtävät toiminnot on toteutettu vaihtamalla sivun si- sältö kokonaan tai osittain. Tätä menetelmää on käytetty lähinnä asetusten yhtey- dessä. Yksittäinen sivu jakautuu kahteen osaan. Osat ovat ylätunniste ja varsinainen sisältö. Ylätunniste linkitetään kaikille sivuille erillisestä HTML-tiedostosta. Kiinteän sisällön lisäksi siinä on aktiivisen sivun mukaan vaihtuvaa sisältöä. Sen alapuolella on sivun varsinainen sisältö, joka vaihtuu käyttötarkoituksen mukaan. Ylätunnisteen rakenteesta (kuvio 34) on erotettavissa neljä osaa: 1. logo 2. kellonaika ja päivämäärä 3. ikonit, jotka sisältävät linkkejä muihin toimintoihin 4. tietoja mittarista ja käyttäjästä, joka sijoittuu alas koko ylätunnisteen leveydelle 77 Kuvio 34. Sivun ylätunniste Kirjautuminen Aloitussivu sisältää linkit sivun varsinaisiin toimintoihin, jotka toteutetaan ponnah- dusikkunoina. Kuviossa 35 on nähtävissä ko. linkit. Kuvio 35. Kirjautumisen etusivu Liitteessä 1 on mainittu kirjautumisessa seuraavat toiminnot: kirjautuminen, uuden salasanan tilaaminen, rekisteröityminen ja mittarin tiedot. Toimintoja on hieman ket- jutettu. Kun valitaan kirjaudu, avautuvan ponnahdusikkunan kautta on mahdollista myös tilata uusi salasana. Mittarin tiedot puolestaan voidaan antaa sen jälkeen, kun käyttäjä on ensin antanut omat tietonsa. Graafiselta ilmeeltään kirjautumisen etusivu on tavanomainen. Missä tahansa web- sovelluksessa kirjautuminen voi näyttää samanlaiselta. Haasteellisinta kirjautumisen 78 suunnittelussa oli toimintojen joustava ketjuttaminen. Etusivulle oli tarkoitus laittaa mahdollisimman vähän toimintoja, jotta se säilyisi mahdollisimman yksinkertaisena. Sen vuoksi kaikki täytettävät lomakkeet sijoitettiin erillisiin ponnahdusikkunoihin. Pääsivu Pääsivulla on nähtävissä mittarin varsinaiset toiminnot (Kuvio 36). Sivu on jaettu ver- tikaalisesti neljään osaan. Ylimpänä on otsikkokenttä, joka sisältää myös sammutus- painikkeen. Sen alapuolella on tilatieto palkki. Mittaustiedot ja mittauskäyrät tulevat näkyviin sen alapuolella. Alimpana on hälytysnäyttö, josta hälytysten lisäksi voi lukea tilamuutosten ajankohdat. Kuvio 36. Pääsivu Käytettävään tilaan nähden sivulle täytyy saada mahtumaan paljon toimintoja. Pysty- suunnassa tila ei oikein riitä. Tavoite on, että kaikki informaatio mahtuu yhteen näyt- töön ilman vierityspalkkeja. Sivulta täytyy pystyä katsomaan olennaiset tiedot mah- 79 dollisimman helposti. Sen vuoksi kosteus ja lämpötila arvot on laitettu näkyviin mah- dollisimman suurina. Samoin vilkkuvasta tilatiedosta näkee nopeasti, mikä prosessin vaihe on meneillään. Kuviossa 36 ei ole näkyvissä hälytyksiä. Ne kuitenkin näkyvät kirkkaampina kuin tilamuutokset ja niiden tekstin väri on valkea. Tilatieto palkissa ja hälytysnäytössä käytetyt värit tekevät näkymän hieman rauhattomaksi. Tavoite kui- tenkin on, että kokeneelle käyttäjälle värit kertovat mitä on tapahtunut. Sen vuoksi värikästä ilmettä päätettiin kuitenkin käyttää. Asetukset Toinen suuri kokonaisuus on asetusten hallinta. Muutettavia parametreja on run- saasti. Niiden sijoittaminen yhteen näyttöön on käytännössä mahdotonta. Sen vuoksi ne päätettiin jakaa osiin käyttötarkoituksen mukaan. Asetusten pääsivusta (kuvio 37) havaitaan, kuinka asetukset on ryhmitelty. Kuvio 37. Asetusten pääsivu 80 Tämäkin sivu on horisontaalisesti jaettu neljään osaan. Otsikkokenttä sisältää myös aktiivisen mittarin valintakentän. Se ei tule näkyviin, jos käyttäjällä on vain yksi mit- tari käytössään. Seuraavana on perusasetukset sisältävä osio, johon koottiin käyttä- jän useimmin käyttämät asetukset. Sen alapuolella on kaksi ryhmää painikkeita. Ylemmässä päästään käsiksi muihin tarjolla oleviin asetuksiin. Alemmassa voidaan hallita varmuuskopiota ja palauttaa oletusasetukset. Asetusten käsittelyn suunnittelu oli erittäin haastavaa, koska asetuksia on paljon. Toi- mintojen ryhmittely kokonaisuuksiksi kuitenkin helpotti tilannetta. Ryhmittely ei on- nistunut kuitenkaan helposti. Mittarissa asetukset on ryhmitelty hieman eri tavalla. Osa materiaalikohtaisista asetuksista oli kuivaus asetusten mukana. Etäkäyttöliitty- mässä ne siirrettiin materiaalikohtaisiin asetuksiin. Asetusten käsittelyssä sovelluksen käytettävyys tuli erityisen selvästi esille. Joustava siirtyminen asetuksista toiseen on hankala toteuttaa. Tässä tapauksessa asetusryh- mästä toiseen täytyy siirtyä aina asetusten pääsivun kautta. Se tuo hieman kömpe- lyyttä sivujen käyttöön. Tästä huolimatta, saavutettuun tulokseen voi olla tyytyväi- nen. Yleiskäyttöisyys Asiakassovellus ei tällä hetkellä tue lainkaan sovelluksen yleiskäyttöisyyttä. Graafisen ilmeen suunnittelussa sitä ei missään vaiheessa otettu huomioon. Sivuilla voidaan näyttää juuri ne asiat, mitkä koskevat tätä mittarityyppiä. Sinänsä sivuille olisi helppo määritellä erilaisia kenttiä mittarityypin mukaan. Yhdelle sivulle voisi tulla eri suurei- den näytöt ja laitteen hälytykset samaan tapaan kuin nytkin toteutettiin. Graafisiin esityksiin voitaisiin määritellä asiat mitä halutaan näyttää. Tarvittaessa esityksen tyyppi voitaisiin valita. Tilatietopalkki voitaisiin tarvittaessa panna pois näkyvistä. Tässä muutama esimerkki mahdollisuuksista. Millä tilanne voitaisiin sitten korjata? Sivustolle tarvittaisiin ylläpidon käyttöön erilli- nen konfigurointi-työkalu, jolla voitaisiin kertoa edellä mainitut asiat. Määrittelyt tal- letettaisiin tietokantaan. Käytännössä tämä vaatisi monimutkaisempaa toteutusta nykyiseen verrattuna. 81 4.3.6 Tietoturva Suuressa mittakaavassa tietoturva on helppo järjestää. Palvelimen molemmat raja- pinnat voidaan suojata SSL-suojauksella hankkimalla palvelimelle kolmannen osapuo- len myöntämä sertifikaatti. Mitä muuta tietoturvassa täytyy huomioida? Yhteyksien suojaaminen ei pelkästään riitä. Käyttäjien salasanat salataan ennen tietokantaan talletusta. Siten tietokantaan murtautuja ei pysty käyttämään hyväksi käyttäjien salasanoja. Järjestelmään voi rekisteröityä ainoastaan käyttäjä, jolla on hyväksyttävä sarjanu- mero. Siinä on itsessään tarkistussumma. Toisaalta palvelimelta täytyy löytyä tuotan- non tallettama testausraportti. Jos sitä ei löydy, sarjanumero on todennäköisesti väärä. Lisäksi rekisteröitymisessä on varmistus, että kirjautuja on todellinen henkilö. Näytölle tulee joukko kirjaimia (ks. kuvio 33), jotka täytyy syöttää oikein varmistus- kenttään. Järjestelmä on suojattu käyttäjän virheiltä. Asetusten syötteisiin on määritelty raja- arvot, joiden avulla estetään käyttäjää sekoittamasta mittarin toimintaa. Siten var- mistetaan, että laite toimii ainakin suuntaa antavasti, vaikka käyttäjä ei tiedä mitä te- kee. 4.4 Toteutus 4.4.1 Yleistä Pohditaan aluksi toteutuksen problematiikkaa. Miten toteutusta kannattaa tehdä ja minne? Otetaanko tavoitteeksi, että toteutuksesta mahdollisimman iso osa olisi pal- velimella vai asiakassovelluksessa? Kummassakin ratkaisussa on omat hyvät ja huo- not puolensa. Palvelimella tehty toteutus vaatii, että palvelimen lähettämää HTML-tiedostoa muo- kataan Tornado frameworkin mahdollistamilla menetelmillä. Sen jälkeen JavaScript muutoksia tarvitaan vähemmän. Kun sivu halutaan päivittää, täytyy se noutaa koko- naan uudelleen, joka saattaa aiheuttaa viivettä. 82 Tietyn sivun osan päivitys vaatii, että data haetaan palvelimelta AJAX- palvelupyynnöllä. Haettu data käsitellään näkyväksi DOM-elementiksi JavaScriptillä. Tällä tavalla saadaan välitön vaste käyttäjälle. Tämän seurauksena palvelimelle tulee enemmän palvelupyyntöjä, mutta siirrettävä datamäärä todennäköisesti vähenee. Paras ratkaisu löytyykin näiden kahden tavan väliltä. Kriittiset osat, jotka vaativat vä- litöntä vastetta, toteutetaan JavaScriptillä ja toisarvoiset palveluun valitun framewor- kin tarjoamilla menetelmillä. 4.4.2 Lähtötilanteen kartoitus Projektin alussa oli valmiina nopeasti toteutettu prototyyppiympäristö. Käytännössä se oli riisuttu versio aikaisemmin toteutetusta kasvihuoneen kosteuden- ja lämpöti- lanmittausjärjestelmästä. (PehuTec – Greenhouse 2016.) Neljästä pääsivusta toteutusta oli tehty kahteen, jotka olivat aloitus- ja pääsivu. Ase- tusten hallinta ja ylläpito puuttuivat täysin. Eniten toteutusta oli valmiina pääsivussa. Siitäkin puuttui tilatieto-ja hälytysnäyttö. Kirjautumisesta puuttuivat uuden salasanan tilaaminen ja mittarin tietojen täyttö. Asiakassovelluksen graafinen ilme oli musta, joka ei miellytä läheskään kaikkia. Pääsivu Pääsivun kehitys oli pisimmällä (kuvio 38). Otsikkotietojen esitystä harkittiin vielä tässä vaiheessa. Onko mittarin sarjanumeron pakko olla noin selvästi näkyvillä? Riit- täisikö, että mittarin tiedot näkyvät pienemmällä ylätunnisteen yhteydessä? Näin toi- mitaan monissa muissa web-palveluissa. Kosteus ja lämpötila arvot oli mahdollista lukea näytöltä lukuarvojen lisäksi erillisinä graafisina esityksinä. Mitattujen suureiden lukuarvot päivittyivät automaattisesti mutta graafiset esitykset vain sivun latauksen yhteydessä. Lisäksi graafiset esitykset voi yhdistää samaan koordinaatistoon. Näin olisi mahdollista saada lisää tilaa sivun uusille elementeille. Sivulta puuttui tilatieto- ja hälytysnäyttö. Ylätunnisteessa on linkki raportointiin. Sitä ei kuitenkaan ole vielä toteutettu. 83 Kuvio 38. Pääsivu projektin alussa Sivun ylälaidassa oli kapea ylätunniste (Kuvio 38). Se oli yksilöllinen jokaiselle sivulle. Sen vuoksi samanlainen HTML-koodi toistui jokaisella käytössä olevalla sivulla. Siinä on näkyvissä aika ja joukko ikoneita. Ajan näytössä riittää minuutin tarkkuus. Sekun- nit päivittyivät sivulle ainoastaan viiden sekunnin välien. Ylätunnisteesta puuttui li- säksi palvelun logo. Aloitussivu Alkuvaiheessa kirjautuminen ja muut siihen liittyvät toiminnot oli jaettu kahdelle si- vulle. Kirjautuminen (kuvio 39) ja rekisteröityminen (kuvio 40) oli toteutettu erillisiin HTML-tiedostoihin. 84 Kuvio 39. Kirjautuminen projektin alussa Kuvio 40. Rekisteröityminen projektin alussa Aloitussivulle oli toteutettu ainoastaan kirjautuminen. Sieltä ei ollut mahdollista päästä rekisteröitymiseen. Salasanan uusiminenkaan ei ollut mahdollista. Samoin mittarin tietojen kirjaaminen puuttui. Ylätunnisteen aika kenttä ei toiminut lainkaan. Sivun käytettävyydessäkin oli puutteita. Kun kenttä aktivoitiin, käyttäjälle ei tullut mi- tään indikaatiota kentän aktivoitumisesta. Kursori oli väriltään musta ja se hukkui taustaväriin, koska kenttiin ei ollut määritelty minkäänlaisia reunuksia. Käyttäjän rekisteröityminen oli toteutettu omalle sivulleen. Oikea URI täytyi tietää, koska linkki puuttui. Sivun tekstit olivat erittäin pieniä, jopa niin pieniä, että niistä ei 85 tahtonut saada selvää. Mittarin sarjanumeroa ei pakotettu laittamaan vielä tässä vai- heessa. Tämänkin sivun kenttiä vaivasi samanlaiset käytettävyys ongelmat kuin kir- jautumisessa. Sivulta puuttui myös varmistus, että käyttäjä on todellinen henkilö. Palvelinohjelmisto ja toteutuksen puutteet Asetusten hallintaa ei käytännössä ollut toteutettu. Asetuksien käsittelyssä pystyi vaihtamaan käytössä olevan mittarin toiseen. Uuden mittarin aktivointi puuttui. Muita toimintoja ei ollut. Palvelimella oli valmiina joukko käsittelijöitä. Osa niistä oli selvästi vasta kehitysvai- heessa. Käytössä olivat seuraavat käsittelijät (katso taulukko 6). Taulukko 6: Palvelimen palvelupyyntöjen käsittelijät projektin alussa Tauluko paljastaa, että palvelimelle oli toteutettu vain välttämättömin. Sieltä löytyi mittarilta tulevien mittausten talletus ja mittausten havainnollistamisen madollista- vat palvelupyynnöt. Palvelupyyntö Käsittelijä (handler) tarkoitus käyttäjä / Main Pääsivun lataus. Ohjaaminen kir- jautumiseen, jos sitä ei ole tehty. sovellus /login Login kirjautuminen sovellus /logout Logout uloskirjautuminen sovellus /register Register käyttäjän rekisteröinti sovellus /settings Settings mittarin linkitys sovellus /update Update ajan, viimeisimmän kosteuden ja lämpötilan haku. sovellus /results Results mittaustietojen talletus sovellus /event Event Valmius tilamuutosten käsittelyyn. Käytännössä ei toimintaa. mittari /get_settings Get settings Asetusten haku. Vain runko ei to- teutusta. /temperature.csv Temperature data lämpötilatiedot käyrän piirtoa var- ten sovellus /moisture.csv Moisture data kosteustiedot käyrän piirtoa var- ten sovellus 86 Kaiken kaikkiaan etäkäyttöliittymästä puuttui runsaasti toimintoja. Tässä vaiheessa puutteiksi kirjattiin seuraavat toiminnot: • raportointi ja niiden tulostus • mittarin asetusten talletus ja päivitys • oletusasetusten hallinta • varmuuskopion teko ja haku • mittauksen pysäytys • salasana tai käyttäjätunnus unohtunut • mittarin tilamuutosten käsittely • käyttäjän tietojen päivitys ja salasanan vaihto • mittarin tietojen päivitys • hälytys ja tilamuutosten näyttö • kieliasetukset • ohjelmistopäivitykset • ylläpitäjän toiminnot Käytännössä kaikki toiminnot vaativat toteutusta sekä asiakas- että palvelinsovelluk- seen. 4.4.3 Muutokset Alkutilanteen kartoituksen jälkeen siirryttiin varsinaiseen toteutus vaiheeseen. Muu- tokset tehtiin scrum-periaatteen tavoin siten, että etäkäyttöliittymä pyrittiin pitä- mään koko ajan toimintakuntoisena vähitellen toimintoja päivittämällä ja lisäämällä. Toteutusvaihe jakautui kahteen osaan. Aluksi muutokset painottuivat palvelimelle. Tavoitteena oli saada mittarin toiminnot valmiiksi ensimmäisenä. Niitä olivat erityi- sesti asetusten siirto mittarin ja palvelimen välillä. Samoin tilamuutoksista ja hälytyk- sistä kertovat viestit täytyi tallettaa. Ilman palvelimelle tehtäviä muutoksia mittarin ohjelmistokehitys olisi vaikeutunut, koska uusien ominaisuuksien testaus olisi ollut hankalaa. Työn edetessä painopiste siirtyi vähitellen asiakassovelluksen ominaisuuksiin. Ensin sinne toteutettiin mittarin toimintoihin läheisesti liittyvät toiminnot. Ne sijoittuvat pääsivulle ja mittarin asetusten hallintaan. Lopullinen ulkoasu, käyttäjän tietojen päi- vitys sekä kirjautumiseen liittyvät muutokset toteutettiinkin vasta projektin lopussa. Ylätunniste ja render-funktio Sivuston ylätunnisteen rakennetta päätettiin muuttaa suunnitelmissa kerrotun mu- kaiseksi. Se linkitetään jokaiselle sivulle samasta tiedostosta. Siinä on kiinteitä ja 87 muuttuvia osia. Miten aktiivinen sivu vaikuttaa ylätunnisteeseen? Logo ja aika ovat mukana kaikilla sivuilla. Ikonit vaihtuvat sivuttain. Esimerkiksi kirjautumisen yhtey- dessä niitä ei tarvita. Kuviossa 34 näkyvät ikonit ovat päänäytöltä ja ne ovat vasem- malta oikealle lueteltuna seuraavat: uloskirjautuminen, asetukset, raportit ja paluu ylläpitäjän näkymään. Viimeisin ikoni näkyy vain ylläpitäjille. Asetukset sivulla (kuvio 37) on ikoni, jolla palataan takaisin päänäytölle sekä uloskirjautuminen ja paluu yllä- pitäjän näkymään. Ylläpitäjän näkymässä on vain uloskirjautuminen. Alarivin mittari ja käyttäjätiedot näkyvät kuvion 33 mukaisina päänäytöllä ja asetuk- sissa. Ylläpitäjän näkymässä näkyy pelkkä käyttäjätunnus. Kirjautumisen yhteydessä kenttä ei ole käytössä. Palvelimelta välittyy tieto ladattavasta sivusta render-funktion kautta ylätunnisteen sisältävälle tiedostolle. Sen perusteella tarpeettomat elementit piilotetaan näkymättömiin. Ylätunniste linkitetään mukaan HTML-tiedostoon kuvion 41 mukaisesti. Tarvitaan vain yksi rivi, joka kertoo liitettävän tiedoston. Tiedosto muokataan Tornado fra- meworkin render-funktiolla, joka täyttää kohdan linkitetyn tiedoston sisällöllä. Kuvio 41. Ylätunnisteen linkitys HTML-tiedostoon Asetukset ja sisällön valinta avainsanan perusteella Asetusten käsittely oli toteutuksen suurin uusi kokonaisuus. Kaikki mittarin asetukset käsitellään yhdellä palvelinsovelluksen käsittelijällä. Käyttäjän ja mittarin tiedoille on omat erilliset käsittelijänsä. Käsittelijä hakee asetussettiin liittyvän datan saamansa avainsanan (key word) perusteella ja välittää sen muiden tarpeellisten ohjaustietojen ohella render-funktion parametrina settings.html-tiedostoon liitettäväksi. HTML-tiedostoon täytettyä dataa muokataan näkyvään muotoon JavaScriptillä asia- kassovelluksessa. Saadusta datasta koostetaan sivun vaihtuvat elementit JavaScriptin avulla.
{% include "html/header.html" %}
88 Pääsivu ja AJAX-palvelupyynnöt Pääsivu on toteutettu hieman toisella tavalla. Render-funktiolla välitetään vain osa datasta. Suurin osa sivulla käytetystä datasta on vaihtuvaa. Sitä täydennetään sään- nöllisin väliajoin AJAX-rajapinnan kautta. Kuviossa 42 on esimerkki jQuery:lla toteute- tusta AJAX-kutsusta. Siitä nähdään, että data siirtyy JSON-muodossa. Dataan sisältyy mm. palvelupyynnön URI. Välimuisti on pois päältä. Siten varmistetaan, että data haetaan varmasti palvelimelta. Success-kohdassa on JavaScript callback-funktio, joka ajetaan palvelupyynnön vasteen saavuttua. Kuvio 42. Esimerkki jQuery:lla toteutetusta AJAX-kutsusta Monessa tapauksessa palvelimella on erillisiä AJAX-pyyntöjä varten oma käsitteli- jänsä. Kuviossa 43 on esimerkki Tornado frameworkilla toteutetusta käsittelijästä. Se ajetaan, kun tehdään kuviossa 42 esitetty AJAX-kutsu. Tämä käsittelijä tallettaa mit- tarilta tulleet viestit ja huolehtii niiden välityksestä asiakassovellukselle. Käsittelijä tunnistaa GET- ja POST-metodit. POST-metodilla talletetaan mittarilta saatu viesti tie- tokantaan ja GET-metodilla haetaan tietyltä mittarilta tulleet viestit tietokannasta ja lähetetään ne JSON-muodossa asiakassovellukselle. 89 Kuvio 43. Esimerkki Tornado frameworkilla toteutetusta käsittelijästä Aloitussivu ja ponnahdusikkunat Aloitussivulla käytetään paljon sivuston sisään rakennettuja ponnahdusikkunoita. Nii- den sisältö haetaan jo sivun latautuessa selaimelle. Oletusarvoisesti ne on poissa nä- kyvistä ja ne on mahdollista aktivoida erillisillä JavaScript-komennoilla. Kuviossa 44 on esimerkkinä käyttäjän rekisteröitymiseen käytetty ponnahdusikkunan toteutus. Se on aivan tavallista HTML-koodia. Ilman JavaScript ohjausta tämä osuus näkyisikin heti sivun latauksen jälkeen. 90 Kuvio 44. Ponnahdusikkunan HTML-koodi JavaScript-koodissa käsitellään register-tunnisteella merkattua div-elementtiä. Kuvi- ossa 45 on otteita sitä käsittelevästä koodista. Kun HTML-sivu on onnistuneesti la- dattu sivulle, ajetaan kuvan alareunassa oleva $(document).ready-funktio. Tästä funktiosta nähdään komento, jolla rekisteröinti ikkuna piilotetaan. Samoin siinä aje- taan ponnahdusikkunan toiminnot alustava funktio. Kun käyttäjä painaa aloitussivulla olevaa rekisteröinti painiketta ajetaan funktio showWindow, joka käynnistää lyhyen ajastimen. Parametrina funktio saa käsiteltä- vän ponnahdusikkunan nimen. Se välittyy myös funktiolle show, joka ajetaan ajasti- men päätyttyä. Tässä funktiossa haluttu ponnahdusikkuna komennetaan näkyviin. Loppuosa sivusta peitetään hunnulla merkiksi siitä, ettei se ole käytössä. Samoin hii- ren toimintaa ohjataan niin, että HTML-elementtien klikkauksiin reagoidaan vain ponnahdusikkunassa. Muualla dokumentissa hiiren klikkaus pakottaa sulkemaan ponnahdusikkunan. Ponnahdusikkuna suljetaan, kun hide-funktio suoritataan. Para- metrina menee jälleen tieto mistä ponnahdusikkunasta on kyse. Sama funktio kutsu- taan ajoon muualtakin, kun ponnahdusikkuna halutaan sulkea. 91 Kuvio 45. Ote ponnahdusikkunoita käsittelevästä JavaScript-toteutuksesta Tyylimäärittelyt ja sivujen dynaamisuus Sovelluksen ulkoasun toteutuksessa elementtien ulkonäköön voidaan vaikuttaa CSS- tyylimäärittelyjen lisäksi JavaScriptillä tehtävillä dynaamisilla tyylimäärittelyillä. Kat- sotaan esimerkkinä pääsivulla olevan hälytys ja tilamuutos kentän tyylien määräyty- mistä. Liitteeseen 2 on koottu siihen liittyvät määrittelyt ja koodit. Niistä tässä käsi- tellään olennaisimmat. Ensin liitteessä 2 on HTML-koodi, jolla kenttä luodaan. Kentän kehystää div-elementti tunnisteeltaan areaAlarm. Tähän elementtiin on liitetty suoraan samalla nimellä tyyli- määrittely, joka näkyy CSS-osiossa. Tässä tyylissä määritetään kentän minimi ja mak- simi koko. Reunojen marginaalien leveyksiä. Säädetään tekstin ominaisuuksia, kuten 92 kirjasinkoko ja väri. Nämä ominaisuudet periytyvän sen sisäpuolella oleviin lapsi ele- mentteihin. Kehyksen sisällä on 8 erillistä elementtiä. Ylimpänä on otsikkokenttä nimeltään alarmTitle. Sille on jälleen määritelty tyylimäärittely samalla nimellä. Se sisältää pel- kästään marginaalimäärittelyn rivin alapuolelle. Otsikon alapuolella on seitsemän kenttää, johon kirjoitetaan viimeisimmät tapahtu- mat. Uusin tapahtuma on ylimpänä. Näille on määritelty yhteinen tyyliluokka nimel- tään eventRow. Tässäkin tyylissä määritellään, kuinka paljon tilaa jätetään ympärille ja tekstin kokoon ja väriin liittyviä määrittelyjä. Tässä oli kaikki HTML-koodiin liittyvät määrittelyt. Yksittäinen rivi sisältää kuitenkin kolme rinnakkaista kenttää, kuten kuviosta 36 voidaan havaita. Mistä nämä määritte- lyt tulevat? Katsotaan JavaScript-koodia. Siellä generoidaan lisää div-elementtejä, jotka sijoitetaan yksittäiselle riville. JavaScript osuudessa nähdään toistorakenne, jossa täytetään data jokaiselle riville. Toistorakenteen indeksi määrää mikä rivi on käsittelyssä. Toistorakenteessa käytetty data on haettu kuviossa 42 esitellyllä AJAX-kutsulla. Toistorakenteen alussa poistetaan vanhoja määrittelyjä. Jos näin ei tehdä, DOM- puuhun lisätään pelkästään uusia elementtejä ja vanhat jäävät myös edelleen näky- viin. Seuraavaksi määritellään rivin taustaväri viestin tunnisteen perusteella. Riville lisä- tään kolme erillistä div-elementtiä. Kenttiin kirjoitetaan päivämäärä, kellonaika ja viestin nimi. Nämä elementit lisätään DOM-puuhun append-funktiolla. Jos kyseessä on hälytys, vaihdetaan vielä tekstin väri valkoiseksi. Päivämäärän ja kellonajan sisältäville elementeille on annettu nimi alarmRow. Tällä nimellä löytyy vielä CSS-osiosta tyylimäärittely, jossa ko. elementin leveydeksi määrä- tään 25% käytettävissä olevasta leveydestä. Lisäksi elementeille annetaan ominai- suus, joka mahdollistaa niiden latomisen rinnakkain vasemmalta alkaen. 93 Havaintoja Mitä toteutettaisiin toisin? Ainoana asiana tulee mieleen asetussettien käsittely. Si- vun elementit generoitiin suurelta osin JavaScriptin avulla. Parempi ratkaisu olisi kui- tenkin ollut Tornado frameworkin tarjoama mahdollisuus koota HTML-sivut palasista. Jokaiselle asetus setille olisi ollut oma HTML-tiedosto, joka olisi liitetty asetuksien HTML-pohjaan. Todennäköisesti koodi olisi tällä tavalla toteutettuna ollut selvempää ja helppolukuisempaa. Tässä osiossa on mahdoton kertoa kaikkia toteutukseen liittyviä asioita. Mukaan on otettu olennaisimpia kohtia. Joitakin kohtia on jätetty pois siitäkin syystä, että sillä on suojeltu toimeksiantajan tuotetta ja tuoteideaa kopioinnin välttämiseksi. Toivotta- vasti tästä saa kuitenkin käsityksen millaisesta työstä tässä projektissa on kyse. 4.4.4 Käytettävyys Toteutusvaiheessa havaittiin, että pienet yksityiskohdat vaikuttavat sovelluksen käy- tettävyyteen yllättävän paljon. Heti projektin alussa huomio kiinnittyi täytettävien kenttien aktivointiin. Siitä ei tullut indikaatiota käyttäjälle. Kursorikaan ei näkynyt kunnolla, koska se sulautui taustaan reunuksien puuttumisen vuoksi. Kun kentän pohjaväri muuttuu aktivoitaessa ja kun huolehditaan kursorin näkymisestä, käytettä- vyys paranee jo selvästi. Kaikissa aloitussivun ponnahdusikkunoissa ei käytetä kenttien yhteydessä erillisiä ot- sikoita. Sen sijaan kenttien oletussisällöksi täytetään otsikkoa vastaava informaatio. Kun kenttä aktivoidaan, teksti häviää heti eikä se palaudu takaisin, vaikka siirrytään toiseen kenttään ilman kentän täyttöä. Tässä tilanteessa käyttäjä saattaa unohtaa mitä kenttään piti kirjoittaa. Parempi ratkaisu olisi, jos teksti häviäisi vasta sitten, kun käyttäjä kirjoittaa kenttään tekstiä. Asiakassovelluksessa pyrittiin huomioimaan käytettävyys mahdollisuuksien mukaan. Tärkeää on esimerkiksi välitön vaste käyttäjälle, kun jokin toimenpide tehdään. Tällä hetkellä varmuuskopioiden käsittelyn yhteydessä on pieni tällainen puute. Kun paini- ketta painetaan, kunnollista indikaatiota tapahtuman onnistumisesta ei tule. Sama sivu vain latautuu uudelleen. Sen kyllä huomaa, jos on tarkkana. Vaarana on kuiten- kin, että käyttäjä ei ole varma toiminnon onnistumisesta. 94 Asetusten hallintaan jäi myös yksi ongelma (ks. kuvio 37). Kyse on sivulla olevista ”hy- väksy”, ”peru muutokset” ja ”takaisin” painikkeista. Kun käyttäjä painaa ”hyväksy”, muutokset talletetaan tietokantaan. Sivu ei kuitenkaan vaihdu vaan se haetaan uu- delleen uusilla arvoilla. Tähän mietittiin ratkaisua, että talletuksen jälkeen palataan edelliselle sivulle. Se ei kuitenkaan tuntunut luonnolliselta. Valittaessa ”peru muutok- set” tallentamattomat muutokset poistetaan ja sivun alkuperäinen sisältö haetaan uudelleen tietokannasta. Edelliselle sivulle päästään ainoastaan ”takaisin” -painiketta painamalla. Käyttäjät saattavat kuitenkin luulla, että muutokset voidaan perua myös talletuksen jälkeen, koska painike on aktiivisena silloinkin. Tilanteen ratkaisemiseksi ”peru muutokset” painike pitäisi olla näkymätön tai poissa käytöstä silloin, kun ase- tuksia ei ole muutettu. Näistä kaikista esimerkeistä voidaan havaita, että käytettävyyteen voidaan vaikuttaa erittäin paljon pienillä yksityiskohdilla. Siksi niiden suunnittelun huomioiminen on erittäin tärkeää. 4.4.5 Toteutuksen ongelmat Tässä projektissa oli paljon opittavaa. Lähes päivittäin tuli tilanteita, jossa joutui etsi- mään uutta tietoa ongelman ratkaisuun. Hyväksi avuksi osoittautuivat internetissä olevat alaan liittyvät keskustelupalstat ja opetussivustot. Niiden avulla pystyi ratkai- semaan suurimman osan monimutkaisemmista ongelmista. Ensimmäisenä löytynyt ratkaisu ei välttämättä auttanut. Usein samassa yhteydessä esitettiin toinenkin vaih- toehto. Se saattoikin jo toimia. Jos toimivaa ratkaisua ei löytynyt, sieltä saattoi kui- tenkin löytyä ratkaiseva vihje, jonka avulla ongelma selvisi lopullisesti. Esimerkiksi tästä nostetaan Internet Explorer -selaimella havaittu AJAX-ongelma. Jos- tain syystä sivut eivät päivittyneet, vaikka AJAX-palvelupyyntö toistettiin säännöllisin väliajoin. Datakin oli todistetusti muuttunut palvelimella. Syyksi paljastui välimuistin käyttö. Jos palvelupyynnön sisältö ei muuttunut, vaste haettiinkin välimuistista. Sen seurauksena vasteessa tuli vanhaa dataa. Syy toimimattomuuteen selvisi keskuste- lussa esitetyn ratkaisun perusteella. Muutkin olivat havainneet saman vian. Kun väli- muistin käyttö estettiin, vika korjautui. (IE not triggering jQuery Ajax success 2016.) 95 Toisena esimerkkinä projektissa havaituista ongelmista nostetaan raportti PDF- tiedoston generointi. Se osoittautui projektin vaikeimmaksi ongelmaksi. Raportoin- nissa luodaan raportti käsitellystä tuote-erästä. Graafisen esityksen luominen D3.js laajennuksella toimi hienosti. Esitys oli tyyppiä SVG. Tästä esityksestä haluttiin gene- roida erillinen PDF-tiedosto. Miten tämä onnistuu? Ensimmäinen idea oli kokeilla JavaScript-kirjastoa, jolla voi ge- neroida SVG-elementistä PDF-tiedoston. Se oli kuitenkin toteutettu huonosti. Gene- roitunut dokumentti ei tulostunut samanlaisena. Dokumentin laatu oli todella huono. Seuraavaksi tutkittiin vaihtoehtoa dokumentin generointia jonkin välivaiheen kautta. Ratkaisu löytyikin tällä periaatteella. SVG-elementistä täytyi ensin generoida HTML5 canvas-elementti. Sen puolestaan pystyi generoimaan PDF-tiedostoksi. Graafisen esi- tyksen laatu heikkeni hieman, mutta tulos oli riittävän hyvä. Yksi ongelma on tältä osin vielä selvittämättä. PDF-tiedoston generointi ei onnistu Internet Explorer se- laimella. 4.4.6 Toteutuksen yleiskäyttöisyys Miten toteutus onnistui yleiskäyttöisyyden kannalta? Kokonaisuutena arvioiden huo- nosti. Asiakassovellus on esimerkiksi toteutettu täysin mittarin ehdoilla. Yleiskäyttöi- syyttä siinä ei ole huomioitu käytännössä lainkaan. Palvelinohjelmistossa yleiskäyttöi- syyden huomioiminen oli kuitenkin helpompaa. Siinä auttoi mm. Dataset-laajennok- sen käyttö, jonka ansiosta tietokannan rakenteeseen ei ollut pakko ottaa kantaa. Mit- tarin ja palvelimen välisen rajapinnan ongelmat toivat kuitenkin näkyviin mittarin to- teutukseen liittyviä asioita myös palvelimelle. Millä tavalla ohjelmistoa saisi yleiskäyttöisemmäksi? Siihen on tarjolla kaksi tapaa. Graafisen ulkoasun suunnittelussa ensimmäiseen otettiinkin jo kantaa. Mittarin vaa- timien elementtien konfigurointia varten tarvitaan erillinen hallintatyökalu, jolla voi- daan määritellä etäkäyttöliittymään mittarin ominaisuudet. Nämä määrittelyt talle- tettaisiin tietokantaan. Tällainen toteutus mahdollistaisi mittarien lisäämisen ilman koodimuutoksia. Konfigurointisovelluksen kehittäminen olisi kuitenkin haastava teh- tävä ja siten toisen opinnäytteen arvoinen tehtävä. 96 Toinen yksinkertaisempi ratkaisi olisi HTML-sivujen kasaaminen pienistä HTML- tiedostojen sirpaleista Tornado frameworkin palvekuiden avulla. Selaimelle lähettävä HTML-dokumentti koottaisiin mittarityypin käyttöön määritellyistä HTML-palasista. Tämä vaatisi JavaScript koodin vähentämisen minimiin. Vähintäänkin eri mittarityyp- peihin liittyvät JavaScript-funktiot pitäisi koota omiin tiedostoihinsa. 4.5 Testaus 4.5.1 Yleistä Projektin ohjelmistot testattiin käsin. Testauksessa oli käytettävissä kaksi ympäristöä. Moduulitestausympäristö rakennettiin kehittäjän työasemalle virtuaalikoneelle. Käyt- töjärjestelmänä siinä on Debianin Linux Jessie-versio. Koneelle on asennettu seuraa- vat paketit: git, python-tornado, python-mysql, python-setuptools, mysql-server, phpmyadmin ja apache. Phpmyadmin on selaimella toimiva MySQL-tietokantojen hallintatyökalu. Se ei toimi ilman Apache serverin asennusta. Näiden pakettien asennus ei ole pakollisia. Kuiten- kin niiden asennus on järkevää, koska tietokannan hallinta ja tarkastelu helpottuu merkittävästi. Järjestelmätestausta varten varattiin tilaa yhtiön omassa käytössä olevalta palveli- melta. Sinne rakennettiin täysiverinen palvelinympäristö, joka on samanlainen kuin lopullisessa tuotantoversiossa. Kapasiteetiltaan se ei kuitenkaan ole niin tehokas. Myös automaattista testausjärjestelmän käyttöönottoa harkittiin. Niitä on tarjolla ai- nakin palvelinohjelmistojen testaukseen. Siinä vaiheessa tutkittiin yhtä vaihtoehtoa. Kokeneilta projektin ulkopuolisilta henkilöiltä saatiin tieto, että palvelinohjelmiston testauksen automatisointi saattaa viedä jopa 40 % työajasta. Heillä on kokemusta vastaavan kaltaisen testausympäristön rakentamisesta. Tämä tieto vaikutti päätök- sentekoon. Automaattisen testausympäristön käyttöönotosta luovuttiin tiukan pro- jektiaikataulun vuoksi. Projektin aikana havaittiin joitakin tilanteita, joissa vika olisi havaittu aiemmin automaattisilla testeillä. 97 4.5.2 Moduulitestauksesta yleensä Moduulitestaus tehtiin pääasiassa tavallisen internetselaimen avulla. Käytännössä so- velluksia käytettiin samaan tapaan kuin lopullisessa tuotantoympäristössä. Tähän jär- jestelmään ei ole mahdollista kytkeä kosteusmittaria. Sitä simuloitiin erillisellä simu- laattorilla, joka toteutettiin Pythonilla. Moduulitestausta tehtiin jatkuvasti toteutustyön rinnalla. Käytännössä muutokset moduulitestattiin välittömästi toteutuksen valmistuttua. Suoritusta seurattiin mo- nesta pisteestä: • visuaalisesti suoraan selaimelta • selaimen kehitystyökaluilla • palvelimen lokitiedostosta • simulaattorin saamista palvelupyyntövasteista 4.5.3 Asiakassovelluksen moduulitestaus Asiakassovelluksen moduulitestauksessa käytettiin pääasiassa Google Chrome-se- lainta. Visuaalisen tarkkailumahdollisuuden lisäksi se tarjoaa hyvät mahdollisuudet moduulitestauksen tekoon. Siinä on automaattisesti mukana kehittäjän työkalut, jotka ovat erittäin monipuoliset. Samanlaisia työkaluja löytyy muistakin selaimista. Erittäin hyödyllisiksi osoittautuivat kaksi osiota: Toisella pystyi tutkimaan sivun DOM- elementtejä ja niihin liitettyjä CSS-tyylimäärittelyjä. Toisella puolestaan pystyi tutki- maan sivun lähdekoodeja. Se mahdollistaa JavaScript-koodin debuggauksen eli suori- tuksen ja muuttujien sisällön tarkkailun. CSS-määrittelyt ja HTML-elementit Kuviossa 46 on Google Chromen HTML-elementtien tarkastelutyökalu. Graafisen ul- koasun toiminnan selvittelyssä tästä oli erittäin paljon apua. HTML- ja CSS- määrittelyjen sisältöä voi muokata ja siten tukia muutosten vaikutusta sivuun. Tämä oli erittäin hyödyllinen ominaisuus. Sen avulla näki konkreettisesti, miten määrittelyt vaikuttavat sivun ulkoasuun. 98 Kuvio 46. Chromen HTML-elementtien käsittely työkalu Näkymä jakautuu neljään osaan. Ylhäällä näkyy HTML-elementit. Sieltä voi valita ha- luamansa elementin tutkittavaksi. Kuviossa on valittu elementti status. Tässä ikku- nassa voi tarvittaessa muokata HTML-dokumentin sisältöä. Silloin täytyy painaa hii- ren oikeaa näppäintä ja valita ”Edit as HTML”. Alhaalla vasemmalla on ikkuna, jossa näkyy valittuun elementtiin liittyvät tyylimäärit- telyt. Ylempänä olevat määrittelyt ovat ensisijaisia. Alempana näkyy yliviivattuja määrittelyjä. Ne eivät ole voimassa, koska joku ylempänä oleva määrittely korvaa sen. Tässä tapauksessa kirjasimen koko määritellään pienemmäksi, koska ikkunan le- veys on pienempi kuin 700 pikseliä. Tässä ikkunassa CSS-määrittelyjen vaikutusta on 99 helppo tutkia. Olemassa olevia määrittelyjä voi väliaikaisesti poistaa käytöstä poista- malla rasti määrittely riviltä. Uusia määrittelyjä voi myös kokeilla lisäämällä niitä ha- luamansa tyylimäärittelyn sisään. Tämä oli erittäin hyvä ominaisuus. Sen avulla oli helppo kokeilla erilaisia vaihtoehtoja. Toimivat määrittelyt oli sitten helppo kopioida varsinaiseen tyylimäärittelytiedostoon. Oikealla alhaalla on kaksi ikkunaa. Ylemmässä näkyy elementin reunuksiin liittyviä määrittelyjä. Tässä tapauksessa elementille on tehty marginaalien leveyteen liittyviä määrittelyjä vasemmalle ja ylös. Alhaalla on kaikki elementtiin liittyvät määrittelyt aakkosjärjestyksessä. Kun määrittelyä tutkii tarkemmin, siitä voi havaita missä tiedos- tossa ko. määritys on tehty. Lähdekoodit ja JavaScriptin debuggaus Kuviossa 47 on näkymä lähdekoodien tarkkailu työkaluun. Lähdekoodien debuggauk- sessa tästä oli erittäin suuri apu. Koodiin pystyy laittamaan pisteitä, johon ohjelman suoritus pysäytetään. Näitä kutsutaan breakpointeiksi. Kun ohjelma on pysäytetty, voidaan tarkkailla muuttujien sisältöä. Ohjelman suoritusta on mahdollista jatkaa eteenpäin rivi kerrallaan tai jatkamalla suoritusta seuraavaan pisteeseen. Tässäkin on käytössä neljä erillistä ikkunaa. Vasemmalla ylhäällä on sivuun liittyvät lähdekoodi tiedostot. Tässä tapauksessa kansioiden sisältöjä ei ole avattu näkyviin. Tässä tapauksessa tarkasteltavaksi on otettu HTML-sivulle kirjoitettu JavaScript koodi. Ylhäällä oikealla on näkymä avattuun lähdekooditiedostoon. Ohjelman suoritus on pysäytetty riville 141. Nyt halutaan tarkkailla, miten käsittelyssä olevaa merkkijonoa on muutettu. Funktion parametrina on muuttuja data, jossa saadaan muutettava merkkijono. Käsitelty merkkijono löytyy muuttujasta replaced. Molempien muuttu- jien sisältö näkyy myös tässä ikkunassa. Vasemmalla alhaalla on ikkuna, jossa on ohjelman suoritukseen liittyvät ohjaus pai- nikkeet. Sieltä näkee myös funktiokutsut, joiden kautta tähän pisteeseen on tultu. Li- säksi siellä on breakpoint listat yms. tietoja. 100 Kuvio 47. Chromen lähdekoodientarkastelutyökalu Alhaalla oikealla on lista aktiivisista muuttujista. Tässä tapauksessa siellä on kaksi pai- kallista muuttujaa. Lisäksi this-määreen alta löytyy suuri joukko muuttujia, jotka liitty- vät tarkkailtavana olevaan sivuun. Sieltä voi esimerkiksi lukea hiiren sijainnin koordi- naatit, ikkunan kokoon liittyvät parametrit yms. Kaikkien muuttujien arvoja on mah- dollista muuttaa tämän ikkunan kautta. Sillä tavalla voidaan tutkia parametrien arvo- jen vaikutusta ohjelman toimintaan. Kuviossa 47 näkyy, että käytettävissä on muitakin kehitystyöhön tarkoitettuja työka- luja. Console välilehdelle tulostetaan toiminnassa havaitut virheet. Tällaisia ovat mm. JavaScript-koodin syntaksivirheet. Network välilehdeltä voi tarkkailla sivun tekemiä 101 palvelupyyntöjä ja niihin saatuja vasteita. Muitakin työkaluja on käytettävissä, mutta niitä ei tässä käsitellä sen enempää. 4.5.4 Palvelinohjelmiston moduulitestaus Palvelinohjelmiston moduulitestaus olikin hankalampaa. Projektissa ei käytetty de- buggaus työkaluja. Havaitsimme, että nopein tapa muuttujien sisällön tarkkailuun on lokiin tehtävät tulosteet. Sieltä muuttujien sisällöt oli helppo tarkistaa. Kuviossa 48 on esimerkki lokikirjoituksista. Siinä on haettu perusasetukset tietokan- nasta. Kuviosta nähdään, millaista dataa tietokannasta on haettu. Rivejä on 2 kappa- letta. Tietokannasta saatu data on ordered dict -muodossa. Se muistuttaa huvin pal- jon JSON-rakennetta. Viimeisellä rivillä on palvelupyyntö, jolla data on haettu. Kuvio 48. Esimerkki muuttujien sisällön tulostuksesta lokiin Tornado framework tallettaa automaattisesti palvelupyyntöihin liittyvää dataa lokiin. Palvelupyynnön päättyessä virheeseen, lokiin kirjoitettiin virheilmoitus. Lisäksi ker- rottiin rivi lähdekoodista, jonne suoritus keskeytyi, sekä funktiokutsupolku mistä vir- hepisteeseen on päädytty. 102 Kuviossa 49 on esimerkki virheeseen päättyneestä palvelupyynnöstä. Ensimmäisellä rivillä on virheilmoitus ja palvelupyyntö, joka on vastaanotettu. Seuraavana funktio kutsu ketju, joka on otettu talteen vikahetkellä. Sen perusteella voidaan havaita mah- dolliset funktiot, jossa mahdollinen vika on. Lopussa on vielä lisää informaatiota viasta. Tässä tapauksessa tietokanta on jostain syystä ollut tavoittamattomissa. Kuvio 49. Esimerkki virheilmoituksesta palvelimen lokissa Python ympäristöön on tarjolla moduulitestaus ympäristöjä. Niiden käyttöönottoa ei edes harkittu. Sen vuoksi tässä työssä ei voida arvioida niiden käytettävyyttä. 4.5.5 Järjestelmätestaus Tämä osuus ei varsinaisesti kuulunut tämän työn kokonaisuuteen. Käsitellään sitä kuitenkin lyhyesti ja sillä näkökulmalla mitä se vaikutti projektin toteutukseen. Järjestelmätestausta tehtiin sitä varten pystytetyllä palvelimella. Mittarin ohjelmistoa oli hieman muutettu nopeuttamalla joitakin prosessin toimintoja. Tällä tavalla sääs- tettiin aikaa. Järjestelmätestaus tehtiin käsin eikä siinä käytetty automaattisia osia. Kaikki toiminnot käytiin systemaattisesti läpi. 103 Testauksessa löydettiin mm. vikoja mittarin ja palvelimen välisestä rajapinnasta. Sen seurauksena rajapinta täytyi määritellä osittain uudelleen. Projektin kannalta olisi ol- lut tärkeää, että nämä viat olisi kirjattu Redmineen. Näin ei kuitenkaan tehty, joten niistä ei jäänyt konkreettista merkintää jälkikäteen tutkittavaksi. 4.6 Jatkokehityskohteet Toteutusvaiheessa ei toteutettu kaikkia määriteltyjä ominaisuuksia. Tekemättä jäivät ainakin kielen valinta ja ohjelmistopäivitykset. Jälkimmäinen kuuluu ylläpitäjän toi- mintoihin. Nämä tullaan toteuttamaan vielä jossain vaiheessa. Kehitystyön aikana tuli esille lisää ideoita. Lähimmän sääaseman säätilatiedot voitai- siin tallettaa mittarin sijaititiedon perusteella. Jokaisen mittaushetken sää tietoja ei tarvita mutta ne kannattaisi tallettaa jollain järkevällä aikasyklillä esimerkiksi kerran tunnissa. Lisäksi olisi hyvä tallettaa tieto prosessin energiankulutuksesta. Niiden tie- tojen perusteella olisi mahdollista tutkia säätilan vaikutusta energiankulutukseen. Sen perusteella voitaisiin kehittää uusia innovaatioita energian säästämiseksi ja kulu- jen pienentämiseksi. Mittarista olisi mahdollista tehdä erilaisia variantteja. Esimerkiksi mittarin muuttami- nen jatkuvan prosessin käyttöön. Silloin tässä työssä toteutetut materiaalin erätyyp- piseen käsittelyyn liittyvät toiminnot ovat tarpeettomia. Niiden poisto myös etäkäyt- töliittymästä on silloin tarpeen. 5 Pohdinta Kosteusmittarin etäkäyttöliittymän toteutus ei juurikaan poikkea tavallisen web-so- velluksen toteutuksesta. Ainoa ero on mittarin HTTP ReST-rajapinta. Mittarille data lähetetään muussa muodossa eli HTML-dokumenttia ei tarvita. Tosin JSON-muotoista dataa lähetetään asiakassovelluksellekin. Rajapinta toimii kuitenkin muulta osin sa- malla tavalla kuin mikä tahansa muukin HTTP-rajapinta. Tämän perusteella nähdään, että IoT ei välttämättä vaikuta sitä varten kehitettävän web-sovelluksen toimintaan. Jos käytössä olisi ollut MQTT silloin asetelma olisi tietysti ollut ihan toinen. Tämä to- distaakin, että IoT:ssä ei välttämättä ole pakko käyttää uusia tekniikoita. Vanhatkin ajavat saman asian. 104 Web-sovellusten ohjelmointi on pitkälle valmiiden kirjastojen käyttöä ja niiden tarjo- amien ominaisuuksien käyttöönottoa. Haastavinta monessa tilanteessa onkin oikean kirjaston valinta. Niitä on tarjolla erittäin paljon. Kirjastojen laatu vaihtelee. Yksinker- taisimmillaan se saattaa olla yksittäisen harrastajan omaan käyttöön kokoama, joka on myöhemmin laitettu jakoon muillekin. Sille ei välttämättä ole ylläpitoa ja teknistä tukea. Parhaimmillaan kirjaston takana saattaa olla suuri organisaatio, joka jakaa tuo- tettaan ilmaiseksi kaikkien käyttöön. Silloin kirjaston ylläpitokin toimii paremmin. Tämä tuote oli ensimmäinen varsinainen IoT-tuote PehuTecin historiassa. Joitakin pieniä on toteutettu aiemminkin, mutta ne on toteuttanut yksi henkilö. Kokemus tä- män kaltaisista tuotteista oli siten vähäinen. Tämän vuoksi aikataulu oli liian optimis- tinen. Varsinkin etäkäyttöliittymän aikatauluarvio meni pahasti pieleen. Projektin hal- linta ei muutenkaan toiminut kunnolla. Esimerkiksi etäkäyttöliittymän graafisen il- meen suunnitteluun ei varattu aikaa alkuperäisessä suunnitelmassa. Se on kuitenkin tärkeä osa web-sovelluksen suunnittelua. Redminen käytöllä olisi saatu selviä hyö- tyjä. Projektin johto olisi sitä kautta voinut seurata projektin etenemistä. Tästä pro- jektista saatujen kokemusten perusteella on jo huomattavasti helpompi suunnitella seuraavaa projektia. Projekti oli erittäin mielenkiintoinen ja opettavainen. Sulautettujen järjestelmien oh- jelmointiin verrattuna työ on huomattavasti konkreettisempaa. Käyttäjän sovellusta toteuttaessa palaute onnistumisesta tuli käytännössä välittömästi. Sulautettujen jär- jestelmien maailmassa vastetta voi joutua odottamaan pahimmillaan viikkoja jopa kuukausia. Ohjelmointia voi muutenkin pitää korkeamman tason ohjelmointina, koska projektissa käytettiin paljon kirjastoja ja siten periaatteessa yhdistettiin val- miita palikoita toisiinsa. Perustoiminnot olivat jo valmiina kirjastoissa. Pienellä koodi- määrällä pystyi tekemään näin suuria kokonaisuuksia yllättävänkin helposti. Tästä esimerkkinä voi mainita graafiset esitykset. Vahvan sulautettujen järjestelmien kokemuksen pohjalta siirtyminen web-sovellus ympäristöön onnistui yllättävän helposti. Aikaisempaa web-ohjelmointi kokemusta oli hieman. Tuttua oli mm. HTML, CSS, JavaScript, jQuery ja PHP. Niitä olin käyttänyt joissakin pienissä kokeiluprojekteissa. Uutena asiana tuli esimerkiksi HTTP- protokollan käyttö, joka oli opiskeltava heti projektin alussa. Aikaisemmasta proto- kollaosaamisesta oli tässä selvästi hyötyä. 105 Python-ohjelmointikieli oli myös uusi tuttavuus. Sekin oli helppo sisäistää aikaisem- man ohjelmointikokemuksen ansiosta. Sulautetuista järjestelmistä peräisin olevaa kokemusta on helpompi käyttää palvelinohjelmoinnissa. Luonteeltaan se muistuttaa enemmän perinteistä C-kielistä ohjelmointia. Aikaisemmasta CSS-kokemuksesta huolimatta, tyylimäärittelyjen teko osoittautui projektin hankalimmaksi asiaksi. Usein kävi niin, että luuli ymmärtäneensä määreen merkityksen. Toisessa paikassa käytettynä sama määre ei kuitenkaan tuottanut toi- vottua tulosta. Tämä koskee erityisesti elementtien rinnakkain latomiseen liittyviä määreitä. Tältä osin jäi vielä runsaasti opiskeltavaa. Projektia tutkittiin tässä dokumentissa ohjelmiston yleiskäyttöisyyden kannalta. Sen huomioiminen projektissa olisi vaatinut enemmän kokemusta ja tietämystä tämän- kaltaisista projekteista heti projektin alussa. Jos yleiskäyttöisyys olisi projektissa pää- tetty heti alussa ottaa huomioon, se olisi vaatinut lisätyötä projektiin useamman kuu- kauden verran. Palvelinohjelmistossa moduulirakennetta olisi pitänyt miettiä tarkem- min. Samoin joitakin osia, jotka nyt toteutettiin JavaScriptillä asiakassovellukseen, olisi toteutettava palvelinohjelmistossa. Projekti oli kokonaisuutena erittäin antoisa. Tällaisessa työssä pystyy yhdistämään kaksi maailmaa. Kuvataide on ollut harrastuksenani ainakin 30 vuotta. Siitä kerty- nyttä kokemusta voi hyödyntää myös graafisen ilmeen suunnittelussa. Samalla aikai- sempi ohjelmointikokemus ei mene hukkaan. Tämä kokemus vahvistaa tunnetta oi- kean alan löytymisestä. 106 Lähteet About. 2016. Www-sivusto. PostgreSQL organisaatio. Viitattu 13.7.216. https://www.postgresql.org/about/. Achour, M. Betz, F. Dovgal, A. Lopes, N. Magnusson, H. Ricter, G. Sequy, D. Vrana, J. & others. 2016. PHP manual. Www-sivusto. Viitattu 14.7.2016. http://php.net/manual/en/index.php. Aho, P. 2015. JavaScript Ennen ja nyt. ProGradu-tutkielma. Jyväskylän yliopisto, Tietojärjestelmätiede. Viitattu 16.7.2016. https://jyx.jyu.fi/dspace/bitstream/handle/123456789/45626/URN:NBN:fi:jyu- 201504141575.pdf. Aisch, G. Lindenberg, F. & Wehrmeyer, S. 2015. Dataset: databases for lazy people. Python dataset laajennoksen virallinen www-sivusto. Viitattu 15.7.2016. https://dataset.readthedocs.io/en/latest/. AJAX Tutorial. N.d. Www-sivusto. w3schools.com. Viitattu 9.7.2016. http://www.w3schools.com/ajax/default.asp. Asleson, R. & Schutta, N. T. 2007. Ajax, tehokas hallinta, Tehokkaimmat ohjelmointitekniikat ja niksit interaktiivisten sivujen luomiseen. Jyväskylä: Readme.fi. Avatut ja avattavat tietoaineistot. N.d. Ilmatieteenlaitos www-sivusto, Avoin data. Viitattu 18.6.2016. http://ilmatieteenlaitos.fi/avoin-data-avattavat-aineistot. Avoimien aineistojen tuoteluettelo. N.d. Maanmittauslaitos www-sivusto. Viitattu 18.6.2016. http://www.maanmittauslaitos.fi/avoindata/aineistoluettelo. AWS IoT Button. N.d. Artikkeli Amazon web services palvelussa. Viitattu 15.6.1016. https://aws.amazon.com/iot/button/. Blaze. 2008. Document Object Model veppikoodaajan näkökulmasta. Www-sivusto. Ohjelmointiputka, oppaat. Viitattu. 16.7.2016. http://www.ohjelmointiputka.net/oppaat/opas.php?tunnus=dom. Bostock, M. 2015. D3 Data-Driven Documents. Www-sivusto. Viitattu 16.7.2016. https://d3js.org/. Boumphrey, F. Greer, C. Raggett, D. Raggett, J. Schnitzenbaumer, S. & Wugofski, T. 2001. XHTML. Helsinki: IT-Press, Edita. Buenger, C. 2014. Ultra-Rapid PHP Application Development. Artikkeli Code Project palvelussa. Viitattu 18.6.2016. http://www.codeproject.com/Articles/553018/Ultra- Rapid-PHP-Application-Development. Carter, S. 2012. Four Ways to Slice Obama’s 2013 Budget Proposal. Uutinen. The New York Times, Politics. http://www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal- graphic.html?_r=0. Castig, C. 2015. jQuery vs. Javascript. Blogi, One Month Blogi. Viitattu 16.7.2016. http://learn.onemonth.com/jquery-vs-javascript. 107 Chacon, S. & Straub, B. 2009. Pro Git. eKirja Apress. Viitattu 12.7.2106. https://git- scm.com/book/fi/v1/. Collinbourne, H. 2011. The book of Ruby, e-kirja. No Starch Press. http://data.ceh.vn/Ebook/ebooks.shahed.biz/RUBY/Book%20of%20Ruby.pdf. Collins-Sussman, B. Fitzpatrick, B. W. & Pilato, C. M. 2011. Version Control with Subversion, For Subversion 1.7 (Compiled from r5193). eKirja. http://svnbook.red- bean.com/en/1.7/svn-book.pdf. CSS Selector Reference. N.d. Www-sivu. w3schools.com. Viitattu 16.7.2016. http://www.w3schools.com/cssref/css_selectors.asp. CSS3 @media Rule. N.d. Www.sivu. w3schools.com. Viitattu 16.7.2016. http://www.w3schools.com/cssref/css3_pr_mediaquery.asp. Defining a Project. N.d. Jira 6.4 dokumentation. Atlassian Documentation. Viitattu 4.7.2016. https://confluence.atlassian.com/jira064/. ECMA-404. 2013. The JSON Data Interchange Format. Standardi. ECMA international, Geneve. http://www.ecma-international.org/publications/files/ECMA-ST/ECMA- 404.pdf. Erinomaista liiketoimintaa Big Datan avulla. 2013. White paper. CGI Group INC. Viitattu 17.6.2016. https://www.cgi.fi/sites/default/files/files_fi/white-papers/. Etävalvonta varmistaa toimintakunnon. 2014. Artikkeli ProMaint kunnossapidon erikoislehdessä 10.9.2014. Viitattu 15.6.2016. http://www.promaintlehti.fi/Kunnonvalvonta-ja-kayttovarmuus/Etavalvonta- varmistaa-toimintakunnon. Fielding, R. & Reschke, J. 2014. RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Standardi. Internet Engineering Task Force (IETF). http://tools.ietf.org/html/rfc7231#section-4. Gillmore, W. J. 2005. PHP & MySQL tehokas hallinta. Readme.fi. Golubovic, N. 2016. N.d. D3 Gallery. D3 wiki sivusto. Viitattu 18.7.2016. https://github.com/d3/d3/wiki/Gallery. Hausenblas, M. Tennison, J. & Wilde E. 2014. rfc7111, URI Fragment Identifiers for the text/csv Media Type. Standardin kaltainen muistio, IETF. Viitattu 12.7.2016. https://tools.ietf.org/html/rfc7111. Haverinen, H. 2016. SQL- ja NoSQL-tietokantojen suorituskykyerot. Tietotekniikan kandidaatintutkielma. Jyväskylän yliopisto, Tietotekniikan laitos. Viitattu 14.7.2016. https://jyx.jyu.fi/dspace/bitstream/handle/123456789/49630/URN%3ANBN%3Afi%3 Ajyu-201605032410.pdf. Honkanen H. 2011. Lyhyen kantaman langattomat siirtotavat. Opetusmateriaali. Kajaanin Ammattikorkeakoulu. Viitattu 29.6.2016. http://gallia.kajak.fi/opmateriaalit/yleinen/honHar/ma/ELE_Langaton%20l%C3%A4hi siirto.pdf. 108 Heppelmann, J. E. & Porter, M. E. 2014. How Smart, Connected Products Are Transforming Competition. Artikkeli. Harward Business Review. Viitattu 16.6.2016. https://hbr.org/2014/11/how-smart-connected-products-are-transforming- competition. Hovi, A. 2004. SQL-opas. e-kirja, ISBN 951-846-749-8. Docendo. http://www.ellibs.com/fi/book/951-846-749-8. Hovi, A. 2015. MongoDB haastaa relaatiotietokantoja. Artikkeli. Tivi lehti. Viitattu 13.7.2016. http://www.arihovi.com/mongodb-haastaa-relaatiokantoja/. Hänninen, T. 2011. Hajautetun versiohallinnan hyödyt ja käytännöt. Tietotekniikan kandidaatintutkielma. Jyväskylän yliopisto, Tietotekniikan laitos. Viitattu 10.7.2016. https://jyx.jyu.fi/dspace/bitstream/handle/123456789/36896/URN:NBN:fi:jyu- 2011110211623.pdf. IE not triggering jQuery Ajax success. N.d. Keskustelupalsta. Viitattu 16.8.2016. http://stackoverflow.com/questions/782532/ie-not-triggering-jquery-ajax-success. Javascript callbacks. N.d. Blogi. DreamsLab. Viitattu 18.7.2016. http://dreamerslab.com/blog/en/javascript-callbacks/. Jira Requirements. N.d. Jira 6.4 dokumentation. Atlassian Documentation. Viitattu 4.7.2016. https://confluence.atlassian.com/jira064/ Jouhtimäki, K. 2009. Selainkäyttöisten sovellusten käyttöliittymäsuunnittelu ja käytettävyys. Opinnäytetyö. Tampereen ammattikorkeakoulu, Viestinnän koulutusohjelma, Vuorovaikutteisuuden suunnittelun suuntautumisvaihtoehto. Viitattu 10.7.2016. https://publications.theseus.fi/bitstream/handle/10024/10445/Jouhtim%C3%83%3F ki.Krista.pdf. jQuery API. N.d. JQueryn virallinen dokumentaatio. Viitattu 16.7.2016. http://api.jquery.com/. Kaartinen, H. Nokela, S. & Verronen P. 2016. Tulevaisuuden Internet of things (IoT) mittausympäristöt. Centria. Raportteja ja selvityksiä, 6. Centria-ammattikorkeakoulu. Viitattu 9.6.2016. https://www.theseus.fi/bitstream/handle/10024/104914/978-952- 7173-00-8.pdf. Kantola, A. 2013. Projektinhallinnan työkalut osana yrityksen liiketoimintaa. Pro Gradu tutkielma. Tampereen yliopisto, Informaatiotieteiden yksikkö, Tietojenkäsittelyoppi. Viitattu 11.7.2016. https://tampub.uta.fi/bitstream/handle/10024/94519/GRADU-1383121454.pdf. Korpela, J. & Lehdonvirta, P. 2013. HTML5 sovellusalustana. Vaasa: RPS-yhtiöt. Korpela, J. K. 2011. HTML5 uudet ominaisuudet. Porvoo: Docendo, WSOYpro Oy. Korpela, J. K. 2013. CSS3 uudet ominaisuudet. Saarijärvi: Docendo Oy. Lampkin, V. Leong, W. T. Olivera, L. Rawat, S. Subrahmanyam, N. & Xiang, R. 2012. Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry. First Edition (September 2012). ibm.com/redbooks. Viitattu 16.6.2016. http://www.redbooks.ibm.com/redbooks/pdfs/sg248054.pdf. 109 Laukkanen, J. 2014. Big Datan analysointi. Seminaarityö. Helsingin Yliopisto, Tietojenkäsittelytieteen laitos. Viitattu 14.6.2016. https://www.cs.helsinki.fi/u/jjlaukka/semma_dev.pdf. Lesson: All About Sockets. 2015. Artikkeli, The Java™ Tutorials sivustolla. Oracle Java documentation. Viitattu 18.6.2016. http://docs.oracle.com/javase/tutorial/networking/sockets/. LoRa-radioverkko kantaa kauas. N.d. Artikkeli Elektroniikka, tietoliikenne, nanotekniikka –lehdessä. Viitattu 20.6.2016. http://etn.fi/index.php?option=com_content&view=article&id=487:lora- radioverkko-kantaa-kauas&catid=13&Itemid=108. Maailman ohuin ARM-prosessori?. 2015. Artikkeli Elektroniikka, tietoliikenne, nanotekniikka –lehdessä. Viitattu 20.6.2016. http://etn.fi/index.php?option=com_content&view=article&id=3695:maailman- ohuin-arm-prosessori&catid=13&Itemid=101. Majuri, J-P. 2006. Versionhallinta ohjelmistotuotannossa, Toteutus UNES Oy:ssä. Opinnäytetyö. Tampereen Ammattikorkeakoulu, Tietojenkäsittelyn koulutusohjelma. Viitattu 14.6.2016. https://publications.theseus.fi. Myhrberg, M. 2015. Web-sivujen kehitys ja mobiilioptimointi käytettäessä Bootstrap- alustaa. Ammatikorkeakoulun opinnäytetyö. Hämeen ammattikorkeakoulu, Tietotekniikan koulutusohjelma. Viitattu 17.6.2016. https://www.theseus.fi/bitstream/handle/10024/97571/Myhrberg_Mikael.pdf. Mynttinen, T. N.d. HTTP protokolla. Kalvosarja. Mikkelin Ammattikorkeakoulu. Viitattu 7.7.2016. cna.mikkeliamk.fi/Public/MynttinenTimo/.../HTTP-protokolla.ppt. MySQL Tutorial, Simply Easy Learning by tutorialspoint.com. N.d. Itseoppimismateriaali. tutorialspoint.com. Viitattu 11.7.2016. http://www.tutorialspoint.com/mysql/mysql_tutorial.pdf. Nauha, M. 2012. Grafiikkasuorittimen käyttö keskusmuistitietokannoissa. Seminaarityö. Helsingin yliopisto, Matemaattis-luonnontieteellinen tiedekunta, Tietojenkäsittelytieteen laitos, Tietojenkäsittelytiede. Viitattu 14.6.2016. https://www.cs.helsinki.fi/webfm_send/748/Matti_Nauha.pdf. Nieminen, P. 2013. BIG DATA – Monimuotoisen asiakastiedon rikastaminen hyötyinformaatioksi Six Sigmaa hyödyntäen. Pro Gradu tutkielma. Vaasan Yliopisto, Teknillinen tiedekunta, Tietotekniikka. Viitattu 21.6.2016. https://www.tritonia.fi/fi/e-opinnaytteet/tiivistelma/5727/. Opeyemi, M. A. 2014. Arcitecture perspective of NoSQL, User Experience and Scalability of Cassandra and MongoDB. Opinnäytetyö. Turun ammattikorkeakoulu, Information tecnology. Viitattu 14.6.2016. https://www.theseus.fi/bitstream/handle/10024/80055/Ajayi_Opeyemi.pdf. PehuTecFT Company. 2016. Artikkeli Pehutec Oy:n www-sivustolla. Viitattu 2.3.2016. http://www.pehutec.com/ PehuTec – Greenhouse. 2016. Artikkeli Pehutec Oy:n www-sivustolla. Viitattu 21.7.2016. http://www.pehutec.com/greenhouse/ 110 PehuTec – Merger. 2015. Artikkeli Pehutec Oy:n www-vustolla. Viitattu 2.3.2016. http://www.pehutec.com/merger/ PehuTec – References. 2016. Artikkeli Pehutec Oy:n www-sivustolla. Viitattu 2.3.2016. http://www.pehutec.com/references/ Pihlajaniemi, J. 2012. ReST-pohjaisen web-rajapinnan kehittäminen. Insinöörityö. Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma. Viitattu 14.6.2016. http://www.theseus.fi. RATA.DIGITRAFFIC.FI. Avoin. N.d. Www-sivusto. Liikennevirasto. Viitattu 18.6.2016. http://rata.digitraffic.fi/. Sarja, J. 2012. HTML:n perusteet. Oppimateriaali. Otavan opisto. Viitattu 14.7.2016. http://opinnot.internetix.fi/fi/muikku2materiaalit/muut/ammatillinen/web/html/ht ml_perusteet.pdf. Sarja, J. & Tarmia, M. 2011. CSS-perusteet, Verkkosivustojen suunnittelu ja rakentaminen. Oppimateriaali. Otavan opisto. Viitattu 14.7.2016. http://avkymppi.net/css-perusteet.pdf. Shafranovich, Y. 2005. RFC 4180 Common Format and MIME Type for Comma- Separated Values (CSV) Files. Standardin kaltainen muistio. SolidMatrix Technologies, Inc. Viitattu 14.7.2016. http://www.ietf.org/rfc/rfc4180.txt#page-1. Simula, T. 2014. Vahva vs heikko tunnistaminen. Kalvosarja. Valtorin tietoturvaseminaari 2.4.2014. Valtion tieto- ja viestintätekniikkakeskus, Tietoturvapalvelut. Viitattu 18.6.2016. www.valtori.fi. Singhal, V. 2015. 20 best JavaScript charting libraries. Artikkeli. The Next Web. Viitattu 18.7.2016. http://thenextweb.com/dd/2015/06/12/20-best-javascript-chart- libraries/#gref. Slagell, M. 2014. N.d. Ruby user’s Guide. Www-sivusto. Viitattu 14.7.2016 http://www.rubyist.net/~slagell/ruby/. Soikkeli, T-M. 2013. NoSQL-tietokannat: vertailu relaatiotietokantoihin ja luokittelu tietomallin sekä käyttökohteiden mukaan. Kandidaatintutkielma. Jyväskylän yliopisto, Tietojärjestelmätiede. Viitattu 15.7.2016. https://www.sharelatex.com/github/repos/t-my/tuomas-soikkeli-candidates- thesis/builds/6139d71712d831d3ab664853f62943c97672e132/raw/output.pdf. Sovelluskerros. 2008. Johdatus tietoliikenteeseen kurssin kalvosarja. Teknillinen korkeakoulu. Viitattu 7.7.2016. http://www.tml.tkk.fi/Opinnot/T- 110.2100/2008/Luennot/06.Sovellukset.pdf. SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems. 2014. Www-sivu. DigitalOcean. Viitattu 11.7.2016. https://www.digitalocean.com/community/tutorials/sqlite-vs-mysql-vs-postgresql-a- comparison-of-relational-database-management-systems. Standard Library Documentation. N.d. Ruby dokumentaatio sivusto. Viitattu 14.7.2016. http://ruby-doc.org/stdlib-2.3.1/. 111 Taina, J. 2005. Ohjelmistotuotanto. Kalvosarja Ohjelmistotuotanto kurssille luku3. Helsingin Yliopisto, Tietojenkäsittelytieteen laitos. Viitattu 7.7.2016. https://www.cs.helsinki.fi/u/taina/ohtu/k-2005/2luku3.pdf. The best software teams ship early and often. Pricing. N.d. Atlassian Jira software. Viitattu 4.7.2016 https://www.atlassian.com/software/jira. Tornado. 2016. Tornado framework virallinen sivusto. Viitattu 15.7.2016. http://www.tornadoweb.org/en/stable/. Tuovinen, T. 2004. Johdatus Python-kieleen. Tietotekniikan kandidaatintutkielma. Jyväskylän yliopisto, Tietotekniikan laitos. Viitattu 14.7.2016. http://www.mit.jyu.fi/opetus/opinnayte/LuK/JohdatusPythoniin/TuovinenTeroLuK.p df. User and Group Management. N.d. Jira 6.4 dokumentation. Atlassian Documentation. Viitattu 4.7.2016. https://confluence.atlassian.com/jira064/ Vosloo, I. 2016. WebFrameworks for Python. Artikkeli Python ohjelmointikielen kotisivulla. Viitattu 18.6.2016. https://wiki.python.org/moin/WebFrameworks. VVO otti IoT-anturiverkot Espooseen. 2016. Artikkeli Uusi teknologia.fi palvelussa 9.5.2016. Viitattu 15.6.2016. http://www.uusiteknologia.fi/2016/05/09/digita-tuo- iot-anturiverkot-espooseen/. Working with an Issue. N.d. Jira 6.4 dokumentation. Atlassian Documentation. Viitattu 4.7.2016. https://confluence.atlassian.com/jira064/ Yritysjohdon opas IoT:n ja teollisen internetin hyödyntämiseen. N.d. IoT:n markkinointimateriaalia. Elisa ja Quva.Viitattu 17.6.2016. http://hub.elisa.fi/blog/2015/06/25/lataa-iot-opas/. 112 Liitteet Liite 1. Etäkäyttöliittymän sivustokartta 113 Liite 2. Esimerkki tyylimäärittelyjen teosta toteutuksessa