Modulaarisen matkapäiväkirjaverkkosovelluksen suunnittelu ja toteutus

(1)

MODULAARISEN MATKAPÄIVÄKIRJA- VERKKOSOVELLUKSEN SUUNNITTELU JA TOTEUTUS

Informaatioteknologian ja viestinnän tiedekunta Diplomityö Huhtikuu 2020

(2)

TIIVISTELMÄ

Tomi Mäkelä: Modulaarisen matkapäiväkirjaverkkosovelluksen suunnittelu ja toteutus Diplomityö

Tampereen yliopisto

Tietotekniikan DI-tutkinto-ohjelma Huhtikuu 2020

Verkkosovellusten historia ulottuu lähes yhtä pitkälle kuin maailmanlaajuisen World Wide Web -verkonkin. Verkon alkuaikoina verkkosivujen ja niihin liittyvien avainteknologioiden kyvyt olivat vielä rajalliset, joten verkkosovellukset toteutettiin käytännössä kokonaan verkkopalvelimilla ajet- tavina sovelluksina tai niiden ymmärtämillä ohjelmointikielillä kirjoitettuina komentosarjoina, jotka sitten tuottivat käyttäjän syötteen pohjalta sitä vastaavia verkkosivuja. Vuosien saatossa verkkose- lainten rooli sovellusalustana on kuitenkin kasvanut eritoten JavaScript-kielen kehittyessä entistä ilmaisuvoimaisemmaksi ja ominaisuuksiltaan monipuolisemmaksi. Ennen pitkää syntynsä saivat- kin yhden sivun sovellukset eli selaimessa ajettavat, koko käyttöliittymän toteuttavat JavaScript- sovellukset, jotka hyödyntävät jotakin palvelimella ajettavaa rajapintaa pääasiallisesti vain tietojen hakemiseen ja tallentamiseen. Tällaista mallia noudattavassa sovelluksessa vastuut käyttöliitty- män ja rajapinnan välillä ovat aidosti jakautuneet kahteen eri osaan.

Tässä työssä pyrittiin selvittämään, millä tavoin ja kuinka hyvin perinteisen verkkosovelluksen vastuut voitaisiin jakaa edellä mainitulla tavalla erillisille rajapinta- ja käyttöliittymäsovelluksille, suunnittelemalla ja toteuttamalla siten jaettu matkapäiväkirjasovellus. Aluksi sovellusta lähdettiin toteuttamaan rajapinnan osalta PHP-pohjaisella Lumenilla ja käyttöliittymän osalta JavaScriptin JSX-murteeseen perustuvalla Reactilla. Kehitystyön edetessä kävi kuitenkin selväksi, että rajapinnan kehittäminen saattaisi olla nopeampaa teknologiaa vaihtamalla ja että vaihdos voisi tuoda mielenkiintoisen näkökulman sovellusjaon hyötyihin, joten Lumen-sovellus korvattiin kokonaisuu- dessaan uudella Django-pohjaisella Python-sovelluksella. Vaihdoksen jälkeen jatkuneen työn tuloksena syntyneet sovelluksen osat vietiin lopulta onnistuneesti tuotantoympäristöön niiden tultua riittävän kattaviksi.

Työn tuloksena syntyneeseen sovellukseen oltiin kaiken kaikkiaan tyytyväisiä. Molemmat osat toimivat mainiosti erillään tarkasteltuna ja osien välinen viestintäkin toimi moitteettomasti ja suori- tuskykyisesti. Rajapinnan vaihtaminenkin vahvisti käsitystä osajaon hyödyllisyydestä, sillä vanhaa rajapintaa vasten kehitetty käyttöliittymä voitiin liittää heti miltei sellaisenaan uuteen rajapintaan.

Jaossa havaittiin myös joitakin vähäisiä varjopuolia, jotka saattaisivat olla oleellisia lähinnä muiden kehittäjien liittyessä projektiin, mutta hyödyt jäivät silti haittoja paljon suuremmiksi.

Avainsanat: MVC, Lumen, Django, React, PHP, Python, JavaScript, SPA, REST Tämän julkaisun alkuperäisyys on tarkastettu Turnitin OriginalityCheck -ohjelmalla.

(3)

ABSTRACT

Tomi Mäkelä: Designing and Implementing a Travel Log Web Application Using a Decoupled Backend and Frontend

Master of Science Thesis Tampere University

Degree Programme in Information Technology, MSc (Tech) April 2020

As a concept, web applications are almost as old as the World Wide Web itself. In the early days of the web, the capabilities of web pages and the associated key technologies were still rather limited, which led to web applications being largely implemented as executables running on web servers or as scripts understood and interpreted by such executables, producing static web pages based on the user’s input. However, as years have passed, web browsers have taken an increasingly important role as a platform for web applications due to the growing expressive power and improving feature set of the JavaScript programming language. This has eventually led to the birth of single page applications, or browser-based JavaScript applications that implement the entirety of the application’s interface and depend on a backend server only for data exchange and storage purposes. In such a programming pattern, the responsibilities of the user interface and the application programming interface have truly been split into two separate applications.

In this work, a travel log application was designed and implemented in order to find out how well such a separation of responsibilities between separate backend and frontend modules would perform. The development commenced with a backend application powered by the PHP based Lumen framework and a frontend application built on the React framework, using JSX, its own dialect of JavaScript. Eventually it became apparent that abandoning the Lumen application in favour of an alternate implementation could expedite the backend development and provide an interesting viewpoint in how such a drastic change affects the decoupled application, so it was wholly replaced by a new Python application powered by the Django framework. The two pre- vailing applications after this change of direction were ultimately deployed successfully into a production environment once they became mature enough.

The resulting application was deemed a success. Both of its constituent parts performed well when evaluated on their own, and when put together, their interaction was satisfactory and performant. The switch from Lumen to Django was also proven to work well with the separated approach, as the so far implemented user interface could be used with the new backend with few required alterations. The separation was found to not be without its minor drawbacks, which were mostly related to the ease of participating in the hypothetical scenario that a new developer would step in; however, their significance was in the end overshadowed by the advantages of this approach.

Keywords: MVC, Lumen, Django, React, PHP, Python, JavaScript, SPA, REST

The originality of this thesis has been checked using the Turnitin OriginalityCheck service.

(4)

ALKUSANAT

Tämä työ päättää viimein kymmenvuotisiksi venyneet korkeakouluopintoni, jotka saivat alkunsa Tampereen teknillisen yliopiston signaalinkäsittelyn ja tietoliikennetekniikan kan- didaatintutkinto-ohjelmasta, mutta kääntyivät lopulta niin tutkintouudistusten kuin omien mieltymystenikin ohjaamana tietotekniikan suuntaan. Matkaan on mahtunut paljon mut- kia, ja vaikka vuonna 2015 toisesta kesätyöpätkästäni alkanut, aikanaan vakituiseksi muuttunut ja edelleen jatkuva työsuhteeni Vincitillä pääsi vetämään minut työelämään tavallaan jo ennen aikojaan, työ täällä yliopiston puolellakin on lopulta kantanut hedel- mää.

Haluan kiittää kaikkia, jotka ovat tavalla tai toisella edesauttaneet tämän työn valmistu- mista joko suoraan tai välillisesti. Erityisesti heistä haluan kiittää perhettäni, ystäviäni niin verkossa kuin sen ulkopuolellakin sekä kaikkia muita tuttaviani ja työkumppaneitani, jotka ovat kannustaneet minua joka käänteessä ja patistaneet herkeämättömästi tämän työn pariin kerta toisensa jälkeen. Ilman teidän tukeanne saattaisin olla kirjoittamassa tätä vie- lä hamassa tulevaisuudessakin.

Tampereella, 24. huhtikuuta 2020

Tomi Mäkelä

(5)

SISÄLLYSLUETTELO

Kuvaluettelo . . . vi

Ohjelma- ja algoritmiluettelo . . . vii

Lyhenteet ja merkinnät . . . viii

1 Johdanto . . . 1

2 Verkkosovelluksen rakenne . . . 2

2.1 Verkkosovelluksen arkkitehtuuri . . . 2

2.2 Verkkopalvelin ja REST-rajapinta . . . 5

2.3 Tietokantajärjestelmä . . . 6

2.4 HTML, CSS, JavaScript ja DOM . . . 9

3 Sovelluksen suunnittelu . . . 11

3.1 Teknologioiden valinta . . . 11

3.2 Kehitysympäristön yhteisten työkalujen valinta . . . 12

3.3 Toiminnalliset vaatimukset . . . 13

3.4 Verrokkisovelluksia . . . 15

3.4.1 Piwigo . . . 16

3.4.2 WordPress . . . 16

4 Rajapinnan toteutus . . . 18

4.1 Rajapinnan ensimmäinen toteutus . . . 18

4.1.1 Tietokantarakenne ja Eloquent . . . 19

4.1.2 Rajapinnan rakenne . . . 22

4.2 Rajapinnan toinen toteutus . . . 25

4.2.1 Tietokantarakenne ja Djangon olio-relaatio-mallinnus . . . 26

4.2.2 Django Admin . . . 28

4.2.3 Django REST Framework . . . 30

4.3 Rajapinnan ja verkkopalvelimen käyttöönotto tuotantoympäristössä . . . 34

5 Käyttöliittymän toteutus . . . 37

5.1 Node.js, npm ja kehitysympäristön muut työkalut . . . 37

5.2 React-komponentit ja niiden elinkaari . . . 39

5.3 React Router . . . 41

5.4 Tilanhallinta, MobX ja MobX State Tree . . . 42

5.5 Integraatiot muihin palveluihin . . . 45

5.6 Sovelluksen rakenne . . . 46

5.7 Ulkoasu ja asettelun mukauttaminen päätelaitteeseen . . . 48

5.8 Merkkauksen semantiikka ja esteettömyys . . . 52

5.9 Käyttöliittymän testaus . . . 53

(6)

5.10 Käyttöliittymän käyttöönotto tuotantoympäristössä . . . 54

6 Käyttöön otetun sovelluksen arviointi . . . 56

6.1 Rajapintojen vertailu ja arviointi . . . 56

6.2 Käyttöliittymän arviointi . . . 57

6.3 Käyttöliittymä- ja rajapintajaon arviointi . . . 58

6.4 Jatkokehitystarpeet . . . 59

7 Yhteenveto . . . 61

Lähdeluettelo . . . 62

Liite A Verkkopalvelimen rajapinnan verkkoalitunnuksen asetustiedosto . . . 72

Liite B Käyttöliittymänpackage.json-tiedosto . . . 74

(7)

KUVALUETTELO

2.1 Sovelluksen osien väliset vuorovaikutussuhteet perinteisillä teknologioilla toteutetussa MVC-mallin mukaisessa verkkosovelluksessa. . . 3 2.2 Sovelluksen osien väliset vuorovaikutussuhteet yksinkertaisessa

MVC-mallin mukaisessa yhden sivun sovelluksessa. . . 4 3.1 Käyttöliittymän ensimmäinen luonnos. . . 13 4.1 Rajapinnan ensimmäisen toteutuksen tietokannan rakenne. . . 22 4.2 Rajapinnan toisen toteutuksen tietokannan lopullinen rakenne heinäkuus-

sa 2019. . . 28 4.3 Esimerkki valokuva-alkion muokkausnäkymästä Django Admin -pohjaises-

sa hallintakäyttöliittymässä. . . 29 5.1 React-komponentin elinkaaren vaiheet ja niissä ajettavat funktiot. . . 40 5.2 Joidenkin tunnetuimpien Reactin tilanhallintakirjastojen viikoittaiset paket-

tienlatausmäärät npm-pakettirekisteristä helmikuun 2020 loppupuolella. . . 43 5.3 Yksittäisen kuvan ponnahdusikkuna kaikkine lisätietoineen. . . 48 5.4 Vähintään kymmenen tuhatta tähtimerkintää GitHub-palvelussa saaneiden

Awesome CSS Frameworks -listalla mainittujen yleiskäyttöisten tyylikirjas- tojen viikottaiset pakettienlatausmäärät npm-pakettirekisteristä helmikuun 2020 loppupuolella. . . 50 5.5 Käyttöliittymä työpöytäkokoisessa selainikkunassa. . . 51 5.6 Käyttöliittymä mobiilikokoisessa selainikkunassa. . . 51

(8)

OHJELMA- JA ALGORITMILUETTELO

4.1 Esimerkki alkion lisäämisestä tietokantaan Lumen-sovelluksessa Data- base-rajapinnan vapaalla SQL-kyselyllä ja kyselyrakentajalla rakennetulla kyselyllä sekä Eloquentin olioesityksellä. . . 20 4.2 Lyhennetty versio valokuva-alkioiden olio-relaatio-mallinnuksen määrittä-

västäPhoto.php-tiedostosta Lumen-sovelluksessa. . . 21 4.3 Lumen-sovelluksen rajapinnan reititysmäärittely. . . 23 4.4 Lyhennetty versio PhotoController-käsittelijän toteutuksesta Lumen-so-

velluksessa. . . 24 4.5 Lyhennetty versioPhoto-alkioluokan toteutuksesta Django-sovelluksessa. . 26 4.6 Lyhennetty versio Photo-alkion hallinnointipaneelikäsittelijäluokan

toteutuksesta ja rekisteröinnistä Djangon ylläpitopaneeliin. . . 29 4.7 Lyhennetty versio valokuva-alkioiden listaus- ja hakunäkymien toteutuk-

sesta REST-rajapinnassa. . . 30 4.8 Lyhennetty versio valokuva-alkioiden listaus- ja hakunäkymien toteutuk-

sesta matkanäkymän alinäkyminä REST-rajapinnassa. . . 32 4.9 WSGI-protokollan käyttöönotto Apachen sivustoasetustiedostossa. . . 35 5.1 Toiminnaltaan yksinkertaisen JourneyKeyPoints-React-komponentin

toteutus. . . 39 5.2 Käyttöliittymäsovelluksen ylimmän tason reititys. . . 42 5.3 Käyttöliittymäsovelluksen tietovarannon yhden haaran toteutus. . . 43 5.4 Esimerkki SCSS-tyylimäärittelystä käyttäen joitain sille ominaisia ominai-

suuksia. . . 49 5.5 Esimerkkilistauksen 5.4 määrittelyä vastaava CSS-määrittely. . . 49 5.6 Käyttöliittymän alihakemistoa varten tehdyt uudelleenohjaukset. . . 54

(9)

LYHENTEET JA MERKINNÄT

ACID tietokantajärjestelmien tietojen eheyden kannalta tärkeät ominaisuudet – atomisuuden, johdonmukaisuuden, eristyksen ja kestä- vyyden – kertaava ohjesääntö (engl. Atomicity, Consistence, Isola- tion, Durability)

AJAX joukko vuorovaikutteisten JavaScript-verkkosovellusten kirjoittami- seen käytettyjä työkaluja, jotka mahdollistavat uuden datan hake- misen ilman uutta sivulatausta (engl. Asynchronous JavaScript and XML)

BASE ACID-sääntöä heikommat takuut määrittävä vaihtoehtoinen, erityisesti NoSQL-tietokannoille tyypillinen ohjesääntö, joka koostuu korkeasta saatavuudesta, tilan elävyydestä sekä tietojen aikanaan johdonmukaisiksi tulemisesta (engl. Basically Available, Soft state, Eventually consistent)

BBCode alun perin keskustelupalstoja varten kehitetty HTML-merkkauksen tapainen, mutta ominaisuuksiltaan toteutuksesta riippuen vaihte- levasti rajattu tekstin muotoiluun ja sisällön upottamiseen käytetty merkkauskieli (engl. Bulletin Board Code)

CGI rajapinta, jota käyttäen verkkopalvelinohjelmisto voi kutsua palvelimella sijaitsevia muita sovelluksia ja palvella niiden tuottamia do- kumentteja (engl. Common Gateway Interface)

CRUD malli, jonka avulla voidaan kuvata kaikki oleellisimmat tavat, joilla resurssia voidaan hallita: resurssin luonti, haku, päivitys ja poisto (engl. Create, Retrieve, Update, Delete)

CSS dokumentin, kuten verkkosivun, esitystyylin määrittelyyn käytetty tyyliohjeformaatti (engl. Cascading Style Sheets)

DOM HTML-dokumentin rakenteen olioista koostuvana puuna esittävä abstraktio (engl. Document Object Model)

Exif esimerkiksi JPEG-tiedostotyyppiin sisäänrakennettu tietorakenne, johon voidaan käsin tai automaattisesti lisätä tiedoston sisältöä ku- vaavia yksityiskohtia, kuten kameran asetukset valokuvan kuvaus- hetkellä (engl. Exchangeable image file format)

FTP palvelimen ja asiakasohjelman tai kahden palvelimen väliseen tie- dostonsiirtoon tarkoitettu Internet-protokolla (engl. File Transfer Protocol)

GPS Yhdysvaltain avaruusvoimien ylläpitämä maailmanlaajuinen satel- liittipaikannusjärjestelmä (engl. Global Positioning System)

HTML verkkosivun rakenteen määrittelyyn käytetty merkkauskieli (engl.

Hypertext Markup Language)

HTTP verkkopalvelinten ja Internet-selainten välinen viestintäprotokolla (engl. Hypertext Transfer Protocol)

HTTPS nykyään yleisimmin TLS-protokollalla salattu versio HTTP- protokollasta (engl. Hypertext Transfer Protocol Secure)

IDE monipuoliset ohjelmointikehitystyökalut, tyypillisesti vähintään tekstimuokkaimen ja kääntäjän tai tulkin, tarjoava ohjelmointiym- päristö (engl. Integrated Development Environment)

JSON JavaScript-ohjelmointikielen objektitietotyyppiä mukaileva, laajalti käytetty ja rajapintojen toteutuksessa suosittu datan välittämiseen ja säilyttämiseen käytetty formaatti (engl. JavaScript Object Nota- tion)

(10)

JSX React-ohjelmointikehykseen pohjautuvien sovelluksien kehitys- työssä käytettävä kieli, joka muistuttaa pitkälti JavaScriptin ja HTML-merkkauksen yhdistelmää ja joka käännetään puhtaaksi Ja- vaScriptiksi

kanban projektinhallinnassa käytetty menetelmä tehtävien priorisointiin, niiden etenemisen seuraamiseen sekä niiden hallintaan (jap.看板, kanban)

mashup yleisnimitys monenlaisia tietosisältöjä samanaikaisesti yhdistelevil- le verkkosovelluksille

MEAN JavaScript-ohjelmistoihin perustuva verkkosovelluksen toteutus- teknologiapino (MongoDB, Express.js, Angular, Node.js)

MVC arkkitehtuurimalli, jossa sovelluksen vastuiden nähdään jakautu- van kolmeen osaan: tietokantaa hallinnoivaan malliin, tietoa näyttä- vään näkymään sekä käyttäjän syötteiden perusteella mallia muok- kaavaan käsittelijään (engl. Model-View-Controller)

NoSQL tietokantatyyppi, joka pohjimmiltaan perustuu johonkin relaatiotietokannoista eroavaan rakenteeseen ja jota käsitellessä SQL-kielen käyttö on vapaaehtoista tai korvattu täysin muilla tavoilla

ORM objekti-relaatiomallinnus, tapa toteuttaa tietokannan ja ohjelma- koodin välinen rajapinta käyttäen sovelluksen käyttämän kielen luokkia (engl. Object-relational mapping)

RDBMS relaatiotietokantajärjestelmä eli ohjelmisto, joka ylläpitää tietokantaa, jossa alkiot on tallennettu rakenteeltaan kiinnitettuihin taului- hin ja jonka kanssa keskustelemalla muut ohjelmat pystyvät hyö- dyntämään ja muokkaamaan tietokannan sisältöä (engl. Relational database management system)

REST erityisesti rajapintojen kanssa käytetty arkkitehtuurimalli, jossa hyödynnetään puumaiseen resurssirakenteeseen pohjautuvaa osoiterakennetta ja kyseisten resurssien käsittelemistä ennalta määrätyn tyyppisillä HTTP-kutsuilla (engl. Representational State Transfer)

SaaS käyttöoikeusmalli, jossa käyttäjä saa palveluntarjoajan ylläpitämän ja hallitsemiltaan palvelimilta palvellun ohjelmiston käyttöönsä tyypillisesti esimerkiksi kuukausimaksua vastaan (engl. Software as a Service)

SCSS Sass-tyyliohjekirjaston käyttämä, CSS-tyyliohjeiden formaattiin perustuva tiedostotyyppi

SPA yhden sivun sovellus, tyypillisesti toteutettu joko JavaScript-ohjel- mointikielellä tai jollakin siksi käännettävällä kielellä (engl. Single Page Application)

SQL kyselykieli, jota käyttämällä tietokantajärjestelmän hallinnoiman tietokannan sisältöä ja rakennetta voidaan hakea ja muokata (engl.

Structured Query Language)

SSL Netscape Communications -yrityksen selaintuotettaan varten vuonna 1994 kehittämä, nykyään jo vanhentunut tietoliikenteen sa- lausprotokolla (engl. Secure Socket Layer)

TLS SSL-protokollan pohjalta kehitetty uusi, turvallisempi salausproto- kolla, jota käytetään esimerkiksi HTTPS-tietoliikenteen salaami- seen tietoverkon siirtokerroksesta ylöspäin (engl. Transport Layer Security)

VCS ohjelmiston koodikannan hallinnointityökalu, joka pitää kirjaa teh- dyistä muutoksista ja jonka avulla niitä voidaan tarkastella ja hal- linnoida (engl. Version control system)

W3C World Wide Web Consortium, WWW:n käyttämiä standardeja yllä- pitävä ja kehittävä kansainvälinen organisaatio

(11)

WSGI Python-verkkosovellusten ja niitä tarjoavien verkkopalvelinten väli- nen protokolla, joka mahdollistaa erilaisten sovellus- ja palvelinto- teutusten helpon toisiinsa yhdistämisen (engl. Web Server Gate- way Interface)

WWW maailmanlaajuinen verkko, jossa verkkoresurssit ovat saatavilla Internetin yli niiden yksilöllisten verkko-osoitteiden avulla (engl.

World Wide Web)

(12)

1 JOHDANTO

World Wide Web luotiin aikanaan työkaluksi helpottamaan dokumenttien organisointia ja niiden välillä liikkumista [14]. Vuosien saatossa sekä siihen liittyvien olennaisten proto- kollien että WWW-asiakasohjelmien kehittyessä sen käyttötarkoitusten kirjo laajeni kuitenkin merkittävästi ja laajenee edelleen. Nykyään useat sovellukset, jotka vielä pari- kymmentä vuotta sitten olisi kirjoitettu perinteisinä työpöytäsovelluksina, ovat siirtyneet WWW-pohjaisiksi tai jo saaneet alkunsa sellaisina [137].

Pitkän aikaa oli tyypillistä, että sivustojen rakenne ja toimintalogiikka oli täysin palvelin- ohjelmiston vastuulla, ja WWW-selaimen tehtävänä oli vain näyttää palvelimen valmiiksi koostama HTML-merkkaus sellaisenaan käyttäjälle. Selaimissa ajettavaan ECMAScript- ohjelmointikieleen, joka esiteltiin ensi kertaa Netscape-selaimessa jo vuonna 1995, vuosien varrella kehitellyt parannukset ovat kuitenkin tehneet logiikan ja käyttöliittymän eril- leen jakamisen mahdolliseksi. Viime vuosina tällainen jako onkin noussut hyvin suosituksi [77, s. 6, 138].

Tässä työssä suunnitellaan ja toteutetaan monipuolinen matkapäiväkirjasovellus, joka noudattaa tällaista rajapintasovelluksen ja selaimessa ajettavaan käyttöliittymäsovelluk- sen välistä jakoa. Tavoitteena on selvittää, kuinka hyvin jaon oletetut edut lopulta toteutu- vat sekä kuinka hyvin jako sopeutuu tilanteeseen, jossa teknologiavalinnat muuttuvat ja siten osien koko toteutukset vaihtuvat iteratiivisen kehitysprosessin edetessä. Käyttöliitty- mäsovelluksia tehdään vain yksi, mutta rajapinnan ohjelmointikehystä kokeillaan kahdella eri ohjelmointikehyksellä niistä ensimmäisen ilmetessä epämielekkääksi.

Seuraavassa luvussa kuvataan yleisesti tällaisen verkkosovelluksen tyypillistä rakennetta. Kolmannessa luvussa käydään läpi sovelluksen toimintavaatimukset ja selvitetään yleisesti, millaisia vaikutuksia kokonaisvaltaisen yhdellä teknologiayhdistelmällä toteute- tun sovelluksen rajapinnaksi ja käyttöliittymäksi jakamisella voidaan olettaa olevan. Li- säksi siinä esitellään yleisellä tasolla muutama valmis ohjelmistoratkaisu ja perustellaan, miksi niiden ei nähty soveltuvan vaatimuksiin.

Neljännessä ja viidennessä luvussa kerrotaan kunkin osan toteutuksen etenemisestä ja yksityiskohdista sekä esitellään teknologiavalinnat niiltä osin kuin on oleellista. Kuuden- nessa luvussa verrataan rajapintatoteutuksia keskenään, tarkastellaan sovelluksen toi- mivuutta yleisellä tasolla sekä arvioidaan, miten lopputulos eroaisi kokonaan palvelimella toteutetuista ratkaisuista. Viimeisessä luvussa tiivistetään vielä tutkimuksen keskeisim- mät kohdat ja havainnot.

(13)

2 VERKKOSOVELLUKSEN RAKENNE

Verkkosovellusten historia ulottuu lähes yhtä pitkälle kuin itse maailmanlaajuisen tietoverkon, World Wide Webinkin. Ennen tässä työssä suunniteltavaan sovellukseen pereh- tymistä on ensin hyvä käydä läpi, miten nykyisenlaisiin yhden sivun sovelluksiin alkujaan päädyttiin, millaisista osista ne yleisimmin koostuvat sekä millaisiin ohjelmistoihin ne tu- keutuvat.

2.1 Verkkosovelluksen arkkitehtuuri

World Wide Webin alkuaikoina ei verkkosovelluksia vielä ollut lainkaan, sillä se suunniteltiin alun perin nimenomaan dokumenttien järjestelemistä ja niiden välillä liikkumista varten [14]. Voisi siis sanoa, että yksinkertaisimmillaan verkkosivustolla ei ole arkkitehtuuria ollenkaan, vaan se koostuu vain valmiista HTML (Hypertext Markup Language) -dokumenteista, joita verkkopalvelinohjelmisto sitten tarjoilee käyttäjille niitä pyydettäes- sä. Verkon laajetessa kävi kuitenkin pian selväksi, että se mahdollistaisi paljon muutakin kuin vain valmiiksi laadittujen dokumenttien välillä liikkumisen. Esimerkiksi CGI-rajapinta (Common Gateway Interface), joka määritettiin ensi kertaa virallisesti vuonna 1996 julkaistussa standardiluonnoksessa [110], mahdollisti mielivaltaisten sovellusten ajamisen ja näiden tuottamien dokumenttien palvelemisen.

Tyypillisen verkkosovelluksen rakennetta ei sinänsä ole määrätty, mutta useimmiten sen vastuut on jaettu kolmeen osaan, malliin, näkymään ja käsittelijään, jolloin sen sanotaan vastaavasti noudattavan malli-näkymä-käsittelijä -arkkitehtuuria(MVC, Model-View- Controller)[109]. Osien tehtävät jakautuvat siten, että mallin vastuulla on tiedon säilyttä- minen ja ylläpito, käsittelijän tehtävänä on hallita ja muuttaa mallia käyttäjän syötteiden mukaisesti ja näkymä vastaa mallin tallentamien tietojen esittämisestä. Nämä roolit eivät ole täysin ehdottomia – näkymäkin voi tilanteen ja sovelluksen tarkan toteutuksen sitä vaatiessa muokata mallia, mutta päävastuu siitä on silti käsittelijällä. Perinteisillä teknologioilla toteutetuissa verkkosovelluksissa kaikki kolme osaa on toteutettu tavalla tai toisella verkkopalvelimen päässä kuvassa 2.1 esitetyllä tavalla. [74]

Perinteisen mallisissa sovelluksissa koko toiminta perustuu täysin käyttäjän pyytämien sivujen perusteella sovelluksessa luotuihin valmiisiin HTML-merkkausta käyttäviin sivuihin, joiden sisältämien linkkien ja lomakkeiden kautta tämä voi sitten tehdä seuraavan sivu- pyynnön [14]. Näiden rinnalle alkoi kuitenkin hiljalleen nousta ratkaisuja, joissa toimintaa siirrettiin yhä enemmän käyttäjän asiakasohjelman puolelle. Tärkein tämän mahdol-

(14)

Käsittelijä

Pyytää uutta sivua käyttäjän napsauttaessa linkkiä

Palauttaa HTML- dokumentin Malli

Näkymä

Muokkaa mallia Päivittää näkymän

uusien tietojen mukaisesti

Ensimmäinen HTML-sivu Toinen HTML-sivu

Kuva 2.1. Sovelluksen osien väliset vuorovaikutussuhteet perinteisillä teknologioilla toteutetussa MVC-mallin mukaisessa verkkosovelluksessa.

listava teknologia oli Brendan Eichin Netscape Navigator -selainta varten vuonna 1995 kehittämä LiveScript, joka nykyään tunnetaan joko ECMAScriptinä virallisen standardin tai paljon yleisemmin JavaScriptinä sen alkuperäisen toteutuksen saaman uuden nimen mukaan [44, s. 10, 118, 119]. Kun tuolloin tärkeimmät selaimet yksi toisensa jälkeen to- teuttivat omat versionsa JavaScriptistä, sivujen pienimuotoinen muokkaus lennossa oli mahdollista. Tässä vaiheessa mahdolliset muutokset rajoittuivat kuitenkin sivun sisällä jo toimitettuihin tietoihin.

Mahdollisuudet tehdä merkittävämpiä muutoksia helpottuivat 2000-luvun alkupuolella.

Kun alun perin Microsoftin Exchange-sähköpostiohjelmaa varten luotuXMLHttpRequest- rajapinta [54] lisättiin hiljalleen entistä useampaan selaimeen, JavaScript-komentosarjat pystyivät viimein hakemaan uutta tietoa lataamatta sivua alusta alkaen uudelleen. Yk- si merkittävimmistä XMLHttpRequest-rajapinnan avulla toteutetuista varhaisista verkko- sovelluksista oli Googlen huhtikuussa 2004 julkaisema Gmail-sähköpostipalvelu [46, 73, 118]. Vaikka tätä rajapintaa hyödyntäviä verkkosovelluksia kehitettiinkin kiihtyvällä tahdil- la, käytännössä se oli epävirallinen aina huhtikuuhun 2006 saakka, jolloin World Wide Webin standardeja ylläpitävä ja kehittävä World Wide Web Consortium (W3C) ehdotti ensi kertaa sen virallistamista [61].

XMLHttpRequest-rajapintaan perustuvien sovellusten yleistyessä sitä käyttäville tekniikoil- le vakiintui lyhyempi ja helpompi nimi, AJAX (Asynchronous JavaScript and XML) [41].

Vaikka tuolloin oli vielä yleistä jakaa sivusto erillisiin sivuihin, joita lähinnä laajennettiin esimerkiksi tuolloin syntynsä saaneen suositun jQuery-kirjaston avulla [113], voisi siltikin

(15)

sanoa, että yhden sivun sovellukset (SPA,single page application) saivat syntynsä täl- lä aikakaudella. Nimen mukaisesti yhden sivun sovellus on selaimen näkökulmasta yksi ainoa sivu, joka pelkästään muokkaa itseään. Palvelimelta ei siis enää haeta näkymän muuttuessa uutta valmista HTML-dokumenttia, vaan sen tehtäväksi jää palvella käyttö- liittymälle sen tarvitsemia tietoja ja resursseja sitä mukaa, kun tämä niitä pyytää. MVC- mallin näkymäosuus on näissä käytännössä siirtynyt palvelimelta selaimessa ajettavalle JavaScript-sovellukselle kuvassa 2.2 kuvatulla tavalla.

Käsittelijä

Muokkaa HTML-dokumenttia Malli

JavaScript-sovellus (näkymä)

Palauttaa uutta mallia vastaavat tiedot

Yhden sivun sovelluksen HTML Sovellus käsittelee käyttäjän syötteen

Muokkaa mallia

Kutsuu rajapintaa

Kuva 2.2. Sovelluksen osien väliset vuorovaikutussuhteet yksinkertaisessa MVC-mallin mukaisessa yhden sivun sovelluksessa.

Kokonaan yhden sivun tekniikoilla toteutetut verkkosovellukset olivat niiden alkuaikoina usein juuri yhtä käyttötarkoitusta varten räätälöityjä, mutta viime vuosina yleiskäyttöiset SPA-ohjelmointikehykset ovat todella lyöneet itsensä läpi. Ensimmäisenä merkittävänä tällaisena kehyksenä voinee pitää Miško Heveryn vuonna 2010 julkaisemaa Angular.js- kirjastoa [42], jonka suosion voi havaita muun muassa sen uudemman version erityis- asemasta edelleen suosittua, puhtaasti JavaScript-pohjaista teknologiapinoa kuvaavassa MEAN-lyhenteessä (MongoDB, Express.js, Angular, Node.js)[138]. Käytännössä näiden kehysten mukanaan tuomien ominaisuuksien myötä voi sanoa, että johonkin rajapintaan tukeutuva yhden sivun sovellus toteuttaa jo itsessään oman MVC-jakonsa siinä, missä rajapintapalvelin toteuttaa omansa, näkymän osuuden rajoittuessa rajapinnan puolella lähinnä kuvaamaan datan esimerkiksi JSON-muotoon muokkaamista ennen lähettämis- tä.

Sekä perinteisen mallisilla että yhden sivun sovelluksilla sanotaan olevan omat hyvät ja huonot puolensa. Palvelimen päässä tuotettujen sivujen kanssa on mahdollista pysyt-

(16)

täytyä yhdessä vapaavalintaisessa ohjelmointikielessä ja yhdessä koodikannassa, jolloin sen sisäinen arkkitehtuuri saattaa olla helpompi rakentaa, kun taas eriytetyssä toteutuksessa käyttöliittymäkoodi on käytännössä aina kirjoitettava JavaScriptillä tai jollakin siksi käännettävissä olevalla kielellä rajapinnan toteutuksesta huolimatta. Toisaalta eriytetty malli tekee toteutuksen osien vaihtamisen helpommaksi. [75]

Suorituskyvyn kannalta valintaa voi tarkastella monella tapaa. Palvelimella tuotettujen sivujen mallissa jokainen käyttäjän tekemä valinta aiheuttaa uuden sivun latauksen, jolloin palvelimen on tehtävä merkittävästi enemmän työtä kuin silloin, kun käyttäjä hakisi vain satunnaisesti dataa rajapinnan kautta. Yhden sivun sovelluksissa sivun ensimmäinen la- taus taas saattaa olla hitaampi, sillä selaimen on ensin ladattava tyypillisesti melko koo- kas JavaScript-tiedosto ja saatettava sen sisältämä koodi käyntiin, mutta ensi latauksen jälkeen käyttöliittymässä näkymästä toiseen siirtyminen on nopeampaa – tai välitöntä, mikäli rajapinnasta ei tarvitse hakea lisää dataa. Selaimen välimuistia oikein käyttämällä itse sovellustiedoston lataamisen aikahukastakin päästään eroon. [75, 77, s. 4–8, 20–21]

2.2 Verkkopalvelin ja REST-rajapinta

Palvelimella sijaitsevan verkkopalvelimen tehtävänä on keskustella verkkosivua tai muu- ta palvelimella sijaitsevaa verkkoresurssia pyytävän asiakasohjelman kanssa. Yksinker- taisimmillaan pyyntöä vastaan voidaan palauttaa suoraan jokin levyllä sijaitseva tiedosto, mutta monimutkaisempien sovellusten tapauksessa verkkopalvelin todennäköisesti lähet- tää pyynnön eteenpäin jollekin muulle ennalta määrätylle ohjelmistolle, jossa toteutetaan varsinainen toimintalogiikka ja joka sitten kertoo lopulta verkkopalvelimelle, mitä asiakas- ohjelmalle tulee palauttaa.

Palvelimen ja asiakasohjelman välinen liikenne tukeutuu samaan monitasoiseen verkon kerrosrakenteeseen kuin kaikki muukin verkkoliikenne [60, s. 2-5]. Verkkopalvelinten ja muidenkin tässä työssä oleellisten sovellusten välinen viestintä tapahtuu lopulta kaikkein ylimmillä tasoilla, istunto-, esitys- ja sovelluskerroksilla, joten muiden tasojen toimintaan ei perehdytä tämän tarkemmin niiden läsnäolosta huolimatta. Verkkopalvelin keskustelee asiakasohjelman kanssa käyttämällä sovellustasolla toimivaa HTTP-protokollaa (Hyper- text Transport Protocol) tai tämän salattua versiota, HTTPS-protokollaa (Hypertext Trans- port Protocol Secure), käyttäen.

HTTP- ja HTTPS-protokollissa on määritelty pieni joukko sallittuja palvelimelle tehtävissä pyynnöissä käytettäviä toimintoja [36]. Näitä kutsutaan tavallisimmin metodeiksi (HTTP method) tai verbeiksi. Kaikkein yleisin näistä on GET-metodi, jolla yksinkertaisesti pyy- detään palvelinta palauttamaan jokin resurssi, kuten verkkosivu tai kuvatiedosto. GET- metodi on idemponentti, eli sitä käyttävät kutsut eivät saa muuttaa palvelimen tilaa mil- lään tavalla. Eittämättä toisiksi yleinen metodi on POST, jolla pyydetään palvelinta teke- mään jotain sille lähetetyllä datalla. Esimerkiksi verkkosivujen lomakkeet käyttävät useimmiten POST-metodia, ja vaikka GET-metodillakin voidaan lähettää dataa erityisesti osoit- teeseen lisättävien parametrien muodossa, POST-metodin on sallittua muuttaa palveli-

(17)

men tilaa. Muita metodeita ei tavallisessa verkkosivujen selauksessa juuri nähdä kuin enintään taustalla tapahtuvissa pyynnöissä.

Pelkkää dataa palvelevat rajapintapalvelimet noudattavat hyvin tyypillisesti REST-arkki- tehtuurimallia (Representational State Transfer) [77, s. 243]. REST-mallin mukaisessa rajapinnassa sen resurssit on ryhmitelty loogiseen, puumaiseen rakenteeseen, ja yleen- sä mallien keskinäisestä suhteesta käy ilmi, millä tavoin ne liittyvät toisiinsa. Rajapinta voisi esimerkiksi tarjota juuritasollaan osoitteessaartistslistauksen tietokantaan tallen- netuista musiikkikappaleiden esittäjistä. Tämän alla jokaisella esittäjällä voisi vastaavasti olla oma, jollakin tunnisteella yksilöity osoite, kuten vaikkapa artists/1 yksilöllisen nu- meron mukaan taiartists/the-beatlesnimestä muodostetun tunnisteen mukaan. Sa- malla tavalla puuta jatkamalla yksi seuraavan tason haara voisi koostua vaikkapa esit- täjän albumeista ja tämä taas albumien yksittäisistä kappaleista. Yksittäisen kappaleen osoitteesta, joka voisi olla muotoaartists/1/albums/8/songs/33, näkyy heti alkioiden keskinäinen riippuvuus.

Puun sisältämille alkioille voidaan itsessään tehdä erilaisia toimenpiteitä suoraan HTTP- protokollan enemmän ja vähemmän yleisiä metodeita käyttämällä. Yleensä rajapinnassa onkin toteutettu vähintään CRUD-mallin (Create, Retrieve, Update, Delete) käsittämät toimenpiteet: resursseja voidaan luoda, hakea, päivittää ja poistaa. Aiemmin mainittujen GET- ja POST-metodien lisäksi HTTP:n metodeihin lukeutuvat DELETE-, PUT- ja PATCH- metodit mahdollistavat näiden täydellisen toteutuksen REST-arkkitehtuurimallin hengen mukaisesti.

Verkkopalvelin viestii tietoa palauttaessaan lisäksi pyyntöön itsessään liittyviä tietoja, joista osan ilmoittaa se itse ja osan pyynnön lopulta käsitellyt sovellus, jonka laatimaa vas- tausta ollaan palauttamassa. Näistä tärkein on vastauksen luonnetta kuvaava tilakoo- di, jonka perusteella asiakasohjelma pystyy oikein käytettynä päättelemään, onnistuiko pyyntö lopulta tai miten palvelin haluaa asiakasohjelman seuraavaksi toimivan. Taulukos- sa 2.1 on esitetty joitakin yleisimpiä tilakoodeja. Tilakoodin ensimmäinen numero kertoo yleismalkaisesti vastauksen tyypin: 1-alkuiset koodit ilmaisevat erilaisia tiedonanto- ja, kuten protokollan vaihtamista, 2-alkuiset koodit onnistuneita pyyntöjä, 3-alkuiset koodit erilaisia uudelleenohjauksia, 4-alkuiset koodit käyttäjästä riippuvia virhetilanteita ja 5- alkuiset palvelimesta itsestään riippuvia virhetilanteita. Vaikka näitä koodeja onkin virallisesti määritetty yli neljäkymmentä, monet niistä ovat käytännössä hyvin harvinaisia tai poistettu myöhemmin käytöstä. [34, 35, 36]

2.3 Tietokantajärjestelmä

Tietokantajärjestelmien tehtävänä on säilöä sovellukseen liittyvää tietoa ja mahdollistaa tehokkaat ja monipuoliset keinot sen muokkaamiseen. Tietokantajärjestelmät eivät var- sinaisesti ole osa verkkosovelluksen omaa arkkitehtuuria, vaan ennemminkin sen malliin liittyvä palvelu, jota mahdollisesti muutkin sovellukset käyttävät. Jonkin tietokantajärjes- telmän käyttäminen on kuitenkin käytännössä pakollinen osa jokaista vähänkään moni-

(18)

Koodi Nimi ja käännös Selitys

200 OK Pyyntö onnistui. Vastaus sisältää pyydetyn resurssin, kuten projektin rajapinnan tapauksessa matkatiedot tai kuvatiedoston sisällön.

204 No Content Ei sisältöä

Pyyntö onnistui, mutta palvelin ei lähettänyt takaisin mitään.

Yleisimmin käytössä POST-, PATCH-, PUT- ja HEAD-metodien yhteydessä.

301 Moved Permanently Siirretty pysyvästi

Pyydetty resurssi löytyy nykyään toisesta osoitteesta. Uusi osoite ilmaistaan HTTP-otsakkeissa, ja käyttäjän tehtäväksi jää pyytää sitä itse uudelleen tätä osoitetta käyttäen.

304 Not Modified Ei muokattu

Resurssi ei ole muuttunut viime kyselyn jälkeen, joten käyttä- jä voi lukea sen vastauksen omasta välimuististaan. Tarkistus vaatii, että pyynnön mukana on toimitettu tieto esimerkiksi siitä, milloin käyttäjä on viimeksi resurssia pyytänyt.

400 Bad Request Virheellinen pyyntö

Pyynnön ohessa toimitetut lomaketiedot eivät ole halutussa muodossa tai ovat puutteellisia.

401 Unauthorized

Tunnistautuminen tarvitaan

Resurssi on saatavilla vain asianmukaisilla käyttöoikeuksilla, mutta käyttäjä ei ole vielä tunnistautunut palvelimelle lainkaan.

403 Forbidden

Oikeudet eivät riitä

Palvelin kieltäytyy tarjoamasta pyydettyä resurssia. Vastauk- sessa voidaan vapaaehtoisesti selittää tarkemmin, miksi pyyn- nöstä kieltäydyttiin, kuten esimerkiksi käyttöoikeuksiltaan liian matalan käyttäjätunnuksen takia.

404 Not Found Ei löytynyt

Pyydettyä resurssia ei ole olemassa tai saatavilla pyydettyä kautta.

500 Internal Server Error Sisäinen palvelinvirhe

Pyyntö epäonnistui käyttäjästä riippumattomista syistä. Vas- tauksessa voidaan määritellä syy tarkemmin, mutta tavallisimmin tämän virheen syy ei ole käyttäjän kannalta kiinnosta- va. Projektin rajapinnan tapauksessa tätä tilakoodia käytetään muun muassa silloin, kun levyltä ei löydy kuvatiedostoa tietokannan ilmaisemalla nimellä, vaikka pitäisi.

Taulukko 2.1.Joitakin yleisimpiä HTTP-tilakoodeja.

mutkaisempaa verkkosovellusta. Yleisimmin käytössä olevat tietokannat voidaan jakaa kahteen merkittävään ryhmään,relaatiotietokantoihin (RDBMS, relational database management system) ja niin kutsuttuihinNoSQL-tietokantoihin[117], jotka edelleen jaetaan vielä muutamaan aliryhmään.

Relaatiotietokannoissa tieto tallennetaantauluihin(table), joiden ennalta määrätytsarak- keet (column) määräävät, millaista tietoa tauluun voidaan tallentaa. Sekä tauluilla että kunkin taulun sarakkeilla on yksilölliset nimet, joilla niihin voidaan viitata. Tauluun tallen- nettuja tietoalkioita kutsutaan riveiksi (row). Käytetty tietokantajärjestelmätoteutus mää- rää, millaisilla tavoilla sarakkeen sisältöä voidaan rajata. Tyypillisesti on mahdollista mää- rätä esimerkiksi sen tietotyyppi, joka saattaa olla muun muassa tietyn pituinen merkkijo- no, vapaamuotoinen ja mielivaltaisen pituinen teksti, numero, totuusarvo tai päivämäärä.

Kentän arvo voidaan asettaa myös yksilölliseksi, jolloin kahdella samantyyppisellä alkiol- la ei saa olla siinä samaa arvoa. Tyypillisesti tauluissa on ainakin yksi tällainen kenttä, jota kutsutaanavaimeksi(key). [71]

Avainten avulla alkiot voivat viitata omissa kentissään toisiin alkioihin muodostaenrelaa- tioitataisuhteita, mistä tämä tietokantatyyppi alun alkaen onkin saanut nimensä. Yleisim- mässä tapauksessa johonkin alkioon voi liittyä mielivaltainen määrä tietyn toisen tyypin

(19)

alkioita; tällöin jälkimmäisen alkion taulussa on sarake, johon tallennetaan edellisen alkion avain. Mahdollisia ovat myös symmetriset suhteet, jossa vain yksi alkio voi liittyä kerrallaan toiseen, sekä vapaamuotoiset suhteet, joissa kummankaan taulun puolelta ei ole määrällisiä rajoitteita. Jälkimmäisellä tavalla käytetään aputaulua, johon tallennetaan jokaista suhdetta kohden oma rivinsä, joka sisältää molempien alkioiden avainarvot. [71]

Relaatiotietokantoja hallinnoidaan ja hyödynnetään tyypillisesti SQL-kielellä (Structured Query Language) kirjoitettuja komentoja käyttäen. Kunkin tietokantajärjestelmän käyttämä murre tästä kielestä eroaa hieman, jotta niillä pystytään ilmaisemaan kyseisten järjestelmien yksilölliset eroavaisuudet, mutta pääosin samat komennot toimivat yhtä lailla joka järjestelmässä. Esimerkiksi rivien hakemiseen käytetään kielestä riippumatta SELECT-lauseketta, kun taas esimerkiksi PostgreSQL-tietokannan TIMESTAMP WITHOUT TIME ZONE-tietotyyppiä ei voi käyttää muiden tietokantojen taulumäärittelyissä.

NoSQL-tietokannat yrittävät erottua relaatiotietokannoista nimenomaan korostamalla si- tä, ettei SQL ole niissä läheskään niin hallitsevassa roolissa tai käytössä ollenkaan, kuten niille vakiintuneesta nimestä voikin nähdä. Sen sijaan niihin voidaan tallentaa muodoltaan vapaampaa sisältöä riippuen siitä, mikä NoSQL-tietokanta tarkalleen on kyseessä. Esi- merkiksi MongoDB-kannan [78] kaltaisissa dokumenttitietokannoissatietokannan alkiot ovat kokonaisia JSON-objekteja, joiden muotoa ei erikseen ole tietokannan puolella rajoi- tettu. Yleisimmin näissäkin järjestelmissä tiedot on silti jaoteltu jollakin tavalla relaatiotie- tokantojen tauluja vastaavalla tavalla, ja usein tietokannan käyttämisen mahdollistavissa kirjastoissa on tarjolla työkaluja rakenteen tarkempaan määrittelyyn vaikkapa edelleen MongoDB-kantaan liittyvän JavaScript-kielisen MongoosenSchema-luokan tavoin [59].

Tallennettavan tiedon luonne määrää osaltaan, millainen tietokanta sille soveltuu par- haiten. Relaatiotietokannat painottavat erityisesti luotettavuutta ja tarkkaan määritellyn tietomallin tuomaa rakenteellista lujuutta, vaikka tämä tekeekin niistä raskaampia. Niis- tä kaikki tärkeimmät noudattavatkin ACID (Atomicity, Consistence, Isolation, Durability) -periaatetta [49, 100], joka koostuu atomisuudesta, johdonmukaisuudesta, eristyksestä ja kestävyydestä.

Atomisuutta selitettäessä esitetään yleensä esimerkki pankkitilistä, josta yritetään samanaikaisesti siirtää varoja toiselle tilille kahdessa eri tapahtumassa. Kun oletetaan, että molemmat tapahtumat ovat jo ehtineet lukea tilin alkusaldon ja laskea, mikä siirron jäl- keisen saldon pitäisi olla ottamatta toista tapahtumaa huomioon, atomisuus takaa, että oikein suunniteltuna nämä tapahtumat eivät pääse sotkemaan toisiaan. Joko kaikki ta- pahtumaan liittyvät operaatiot tehdään kerralla tai sitten niitä ei tehdä lainkaan, jolloin tapahtumat käytännössä pakotetaan peräkkäin. Eristyskin selittyy hyvin samalla esimerkil- lä, sillä se tarkoittaa yksinkertaisesti vain sitä, etteivät tapahtumat tiedä mitään toistensa olemassaolosta. Johdonmukaisuudella tarkoitetaan, että tietokanta on jokaisen tapahtu- man päätyttyä ristiriidattomassa ja kelvollisessa tilassa, jolloin esimerkiksi taulujen vä- lisissä suhteissa käytettyjen avainten on vastattava olemassa olevia alkioita. Kestävyys taas määrää, että tietokantajärjestelmän tulee tiedot tallennettuaan pystyä takaamaan,

(20)

että muutokset myös ovat pysyviä – ainakin siihen saakka, kunnes niitä jossakin toisessa tapahtumassa muutetaan.

NoSQL-tietokannoissa painopiste on sen sijaan tyypillisesti muun muassa suorituskyvys- sä, vapaammassa tietomallissa, yksinkertaisemmassa arkkitehtuurissa ja sopivuudessa paremmin nykyaikaisten ohjelmointikielten kanssa käytettäväksi [43, 117]. Esimerkiksi jotkin Amazonin pilvipalvelutarjooman hajautetut tietokannat on tarkoituksella suunniteltu niin, ettei tietokannan tieto ole jokaisella hetkellä välttämättä täysin johdonmukaista [130].

Tästä ACID-periaatetta heikompaa lupausta kutsutaan välillä nimellä BASE (Basically Available, Soft state, Eventually consistent) [100]. Tämän osa-alueet lupaavat käytän- nössä vain, että tietokanta on saatavilla mahdollisimman suuren osan ajasta ja että sen tilasta tulee aikanaan johdonmukainen, eikä sen tilaa saa koskaan olettaa lopulliseksi.

2.4 HTML, CSS, JavaScript ja DOM

Verkkosovelluksen kielivalinnoista huolimatta HTML-merkkauskielen käyttäminen on lopulta vääjäämätöntä. Kuten aiemmin jo mainittiinkin, HTML-merkkaus on keksintönä yhtä vanha kuin World Wide Web itse, ja vaikka se toki on vuosien saatossa saanut lisää ominaisuuksia eritoten vuonna 2014 ensimmäisen virallisen versionsa saaneessa HTML5- standardissa [52], sen perusta on pysynyt samana.

HTML-merkattu sivu koostuu elementeistä (element) sekä näiden ohessa elävästä va- paasta tekstistä. Erilaisia ennalta määrättyjä elementtityyppejä on useita, ja niistä kaikil- la on jokin merkitys niin semanttisesti kuin yleensä toiminnallisestikin: esimerkiksi <ul>- elementin sisältö kuvastaa listaa, jonka kohtien järjestys ei ole oleellinen, ja <button>- elementti painiketta. [52, 81]

Tarkalleen elementti koostuu aloittavasta kulmasulkein merkitystä tunnisteesta(tag) se- kä yleisimmin sen sisällöstä ja aloittavaa tunnistetta vastaavasta sulkevasta tunnisteesta. Jotkin elementit ovat kuitenkin sisällöttömiä, jolloin niitä merkitään pelkästään niiden aloittavalla tunnisteella. Lisäksi aloittavaan tunnisteeseen voidaan merkitä attribuutteja (attribute), jotka tarkentavat elementin toimintaa ja merkitystä. Joitakin elementtejä tulee käyttää vain tietyissä kohdissa elementtipuuta: dokumentin otsikkoa kuvaava, selaimen välilehdellä näkyvän tekstin määräävä <title>-elementti on muun muassa sijoitettava sivun otsaketietoja sisältävän <head>-elementin sisään. Useimpia sivun varsinaisen si- sällön määrääviä elementtejä voi kuitenkin käyttää melko vapaasti.

Siinä missä HTML määrittää sivun rakenteen, CSS (Cascading Style Sheets) -tyylimää- rittelyt määräävät, miltä sivu ylipäänsä näyttää. Määrittelyt koostuvatvalitsimista(selec- tor), joiden perusteella valikoituville elementeille asetetaan yksi tai useampisääntö(rule) [64, s. 192]. Sallittujen sääntötyyppien kirjo on hyvin laaja kattaen niin yksinkertaisem- pia väri-, kirjasin-, reunaviiva- ja taustakuvasääntöjä kuin vaikkapa elementin asemoin- tiin, näkyvyyteen, jäsentymistapaan ja vuorovaikutteisuuteenkin vaikuttavia sääntöjä [80].

CSS-määrittelyiden nimen mukaisesti säännöt voivat ikään kuin ketjuttua, jolloin valitsin- ten järjestys ja tarkkuus määräävät, mikä sääntö lopulta jää kunkin elementin kohdalla

(21)

voimaan [18, 64, s. 197]. Nämä määrittelyt voidaan liittää osaksi sivua joko <style>- elementtiä käyttäen, jolloin säännöt kirjoitetaan suoraan osaksi HTML-merkkausta, tai paremmin<link rel="stylesheet">-elementillä erilliseen tiedostoon osoittamalla.

HTML-sivujen vuorovaikutteisuudesta vastaavat pääasiassa jo aiemmin lyhyesti esitellyl- lä JavaScript-kielellä kirjoitetut komentosarjat. JavaScript on olio-ohjelmointikieli, jolla on sekä funktionaalisen että imperatiivisen kielen piirteitä ja jonka kielioppi on saanut paljon vaikutteita erityisesti Java-kielestä, kuten välillä sekaannusta aiheuttavasta nimestä voikin päätellä [44, s. 10]. Kuten CSS-määrittelyt, JavaScript-komentosarjatkin liitetään osaksi sivua sen HTML-rakenteessa, tosin tällä kertaa käyttäen<script>-elementtiä niin komentosarjaa suoraan upotettaessa kuin src-attribuutin kera erillisestä tiedostosta la- dattaessa.

JavaScript-komentosarjat pystyvät käsittelemään sivuston HTML-rakennetta käyttämällä selaimen siitä tekemäädokumentti-objektimallia(DOM,Document Object Model), jossa koko dokumentti esitetään JavaScript-objekteista koostuvana puuna. Näiden elementtien omien luokkametodien lisäksi selaimet tarjoavat sivun käsittelyyn muita hyödyllisiä raja- pintoja, joiden avulla voidaan muun muassa hakea tietoa palvelimelta aiemmin mainitulla tavalla, lähettää ilmoituksia välilehden ollessa taustalla, selvittää käyttäjän GPS-sijainti, käsitellä käyttäjän määrittämiä tiedostoja ja niin edelleen [82, 136]. Useisiin näistä toimin- noista tarvitaan toki käyttäjän itsensä suostumus, jonka käsittelyyn itsessäänkin on oma rajapintansa [63].

HTML, CSS ja JavaScript ovat käytännössä nykyaikaisten verkkosivujen koko selkäran- ka. Aiemmin suosittuja olivat Oraclen Java-sovelmien – jotka itse asiassa edelsivät Ja- vaScriptiä – sekä Adobe Flashin kaltaiset selainlaajennokset, mutta verkkostandardien kehittyessä ja niitä tukemattomien älypuhelinalustojen yleistyessä ne ovat jäämässä his- toriaan tai ovat jo jääneet [3, 13, 16, 112, 126]. Näillä näkymin tässä kohdassa esitellyt teknologiat ovat sen sijaan vakiinnuttaneet asemansa pysyvinä sivustojen rakennuspa- loina.

(22)

3 SOVELLUKSEN SUUNNITTELU

Käyttöliittymä- ja rajapintajaon arvioimiseksi oli ensin syytä pohtia, millaisella sovelluksella arviointia lähdettäisiin ylipäänsä tekemään. Huhtikuulle 2018 ajoittunut ulkomaan- matka tarjosi tämän työn kannalta oivallisen tilaisuuden, sillä matkan aikana otetut valo- kuvat, nähdyt paikat ja koetut elämykset haluttiin saada jaettua jollakin itse hallinnoidulla alustalla, mutta ennalta olemassa olevien vaihtoehtojen kartoituksen perusteella pelkkien valokuvien jakamiseen soveltuvia sovelluksia ei olisi ollut ainakaan ilman merkittävää työ- määrää. Luonnollisin ratkaisu oli tällöin toteuttaa sellainen itse.

Kuten ohjelmistoprojekteissa yleisesti, tämäkin projekti aloitettiin suunnittelemalla joitakin sovelluksen arkkitehtuurisia ja toiminnallisia pääpiirteitä. Alusta alkaen hyvin suunnitellulla sovelluksella on paremmat edellytykset edetä tavoitellussa aikataulussa ja pysyä hyvin hallittavana, sillä huonon arkkitehtuurin jälkikäteen korjaaminen on työlästä ja sen vaiku- tukset kauaskantoisia [62, 65].

3.1 Teknologioiden valinta

Projektin aivan alussa on aina tietenkin olennaisinta päättää, mitä ohjelmisto tekee ja mil- lä teknologioilla se toteutetaan. Yleensä suurempien ohjelmistojen kirjoittamisessa hyö- dynnetään jo jotakin olemassa olevaa ohjelmointikehystä, jotka harvoja poikkeuksia lukuun ottamatta mahdollistavat vain yhden ohjelmointikielen käytön.

Tätä projektia ajatellen päätettiin, että ohjelmisto kirjoitettaisiin mitä todennäköisimmin joillakin jo ennestään tutulla kielillä, jotta uuden opetteluun ei kuluisi mielettömästi aikaa.

Käytännössä kieliksi rajautuivat siis JavaScript, PHP, Python, Java sekä periaatteessa C++, joka on kuitenkin nykyään melko epätyypillinen vaihtoehto verkkosivuston toteutta- miseen. Samalla oli valittava, halutaanko toteuttaa koko sovellus perinteisenä verkkopal- velimella tuotettavana sivustona vai erillisenä rajapintana sekä yhden sivun sovelluksena.

Vaikka molemmilla lähestymistavoilla on omat etunsa, kuten kohdassa 2.1 kerrottiin, päätös oli tutkimuksen tavoitteet huomioiden ilmiselvä. Sovellus päätettiin toteuttaa kahdessa osassa, joista toinen toteuttaisi sivuston rajapinnan ja toinen sen käyttö- liittymän. Rajapinnan toteutus päätettiin alustavasti aloittaa käyttäen PHP-pohjaista Lumen-ohjelmistokehystä, kun taas käyttöliittymässä hyödynnettiin hyvin suosittua ja muutenkin jo ennalta tuttua React-kirjastoa.

(23)

3.2 Kehitysympäristön yhteisten työkalujen valinta

Kun toteutuksessa käytettävät teknologiat oli valittu, voitiin saman tien valita myös, mitä työkaluja sovelluksen kehittämiseen käytettäisiin. Kaikkein yksinkertaisimpia ohjelmisto- projekteja lukuun ottamatta kehitystyö tehdään käytännössä aina jossakin tarvittaviin kie- liin erikoistuvassa ohjelmointiympäristössä (IDE,Integrated Development Environment).

PHP- ja JavaScript-kehitykseen soveltuvia ohjelmistoympäristöjä olisi tässä toki voinut vertailla keskenään, mutta useimmiten jokin ympäristö on jo kehittäjälle ennestään tuttu ja ilmiselvä valinta. Näin oli tässäkin tapauksessa, joten ympäristöksi valikoitui JetBrains- sovellustalon päätuote IntelliJ IDEA, jonka maksullinen versio on yliopiston opiskelijoille käytössä ilmaiseksi [57, 58].

Ohjelmistoprojekteissa on tyypillistä myös pitää kirjaa koodikannan muutoksista jonkin versiohallintatyökalun(VCS,version control software) avulla [20, s. 9]. Jokaiseen versio- hallintaan tehtyyn versioon (revision) tallentuu koodin tilan lisäksi tieto sen tekijästä ja ajankohdasta. Useimmiten versiohallinnassa on myös mahdollista pitää yllä useampaa rinnakkaista, mutta ajantasaista versiota, joita kutsutaan tavallisimminhaaroiksi(branch).

Haarat mahdollistavat monen kehittäjän yhtäaikaisen työskentelyn eri ominaisuuksien pa- rissa. Kun ominaisuudet on saatu valmiiksi, ne voidaan sitten sulauttaa päähaaraksi va- littuun haaraan jollakin versiohallintatyökalun tukemalla tavalla.

Versiohallinnan suurimmat hyödyt tulevat eittämättä esiin suuremmissa useamman kehit- täjän kehittämissä projekteissa, mutta sellaisen käyttäminen on eduksi yksin kehittäessä- kin. Versiohistoria mahdollistaa muun muassa tehtyjen muutosten tarkastelun jälkikäteen sekä vanhempaan versioon palaamisen, mikäli viimeksi tehdyt muutokset eivät olleet- kaan halutunlaisia. Haaroja taas voi hyödyntää yhden hengen projekteissakin esimerkiksi usean keskeneräisen ominaisuuden yhtä aikaa kehittämiseen.

Eräs ennalta hyväksi todettu ja nykyaikainen versiohallintatyökalu on Linus Torvaldsin vuonna 2005 kehittämä Git [19][20, s. 12]. Git on hajautettu versiohallintatyökalu, joka eroaa keskitetyistä työkaluista siten, että kullakin projektin koodikannan käyttäjällä on täydellinen kopio koko koodikannan historiasta. Keskitetyille versiohallinnoille ominaista pääversioarkistoa ei siten periaatteessa tarvita, vaikkakin yleensä on käytännöllisintä silti pitää sellaista jollakin yhteisesti saatavilla olevalla palvelimella.

Git ei toki ole ainoa versiohallintatyökalu. Monet ennen Gitiä jo olemassa olleet työkalut ovat edelleen käytössä ja osaa niistä kehitetään edelleen, mutta sen itsensä jälkeenkin on tullut tarjolle muita vaihtoehtoja. Nykyään Gitin rinnalla tärkeimmät versiohallintatyö- kalut lienevät aiemmin hyvin suosittu Subversion [121], Microsoftin Team Foundation [24]

sekä muun muassa Mozillan suosima Mercurial [8, 79], mutta Git on selvästi kasvatta- nut viime vuosina suosiotaan ja noussut niistä ehdottomasti tärkeimmäksi. Esimerkiksi Stack Overflow’n vuosittaisessa kehittäjäkyselyssä on joinain vuosina kartoitettu kehittä- jien versiohallintamieltymyksiä, ja kun vuonna 2015 Gitin ja sen perässä toisena tulleen Subversionin ero oli jo huimat 32 prosenttiyksikköä [115], vuonna 2018 ero oli laventunut peräti 71 prosenttiyksikköön [116].

(24)

Tässä projektissa rajapinnan ja käyttöliittymän koodi eriytettiin erillisiin Gitin avulla ver- sioituihin koodikantoihin. Molemmat näistä tallennettiin paikallisen historian lisäksi myös GitHub-palveluun [69, 70], josta ne ovat käytännössä kenen tahansa saatavilla.

3.3 Toiminnalliset vaatimukset

Sovelluksen varsinaisen toiminnallisuuden suunnittelu alkoi kuvassa 3.1 esitetyn käyttö- liittymän karkean luonnoksen hahmottelulla. Siinä määritettiin matkanäkymän tärkeimmät ominaisuudet, joita varten tarvittaisiin tuki rajapinnan puolelta, sekä niiden alustava kes- kinäinen sijoittelu itse käyttöliittymässä.

Back Journey:Japan 2018 Gallery Journal

Sat ur day, Apr i l 14t h 2018

SatApr14 2018

Sun Apr15 2018 Mon Apr16 2018 Tue Apr17 2018 Wed Apr18 2018 Thu Apr19 2018 FriApr20 2018 SatApr21 2018 Search photos and text...

Timeline Photos

MAP Lorem ipsum dolorsitamet,consectetur

adipiscing elit,sed do eiusmod.

Temporincididuntutlaboreetdolore.

Utenim ad minim veniam.

Place 1

Place 2

Place 3

Photos:73

Shortdescription ofthe day

Photo link

Kuva 3.1.Käyttöliittymän ensimmäinen luonnos.

Luonnoksen jälkeen kirjattiin tarkemmin, mitä ominaisuuskokonaisuuksia käyttöliittymä- luonnokseen lopulta sisällytettiin, ja laadittiin yleinen suunnitelma niiden toteutuksen tär- keysjärjestyksestä. Eräs varsinkin monen hengen kehitystyössä, mutta myös yhden hengen projekteissa hyödyllinen menetelmä on käyttää niin sanottuakanban-taulua tehtävien organisointiin.

Kanbanissa kullakin yksittäisellä tehtävällä on sitä vastaava kortti, jolla on vähintään kuvaus kyseisestä tehtävästä. Jokainen kortti sijaitsee aina jossain kohtaa kanban-taulua täsmälleen yhdessä taulun sarakkeessa, jotka tyypillisesti kuvastavat tehtävän edistymi- sen vaihetta [4]. Lisäksi sarakkeiden sisältämien korttien järjestystä voidaan käyttää mer- kitsemään niiden keskinäistä tärkeysjärjestystä, jolloin ensiksi toteutettava ominaisuus on sarakkeessa ylimpänä. Tässä projektissa kanban-tauluna käytettiin projektin tarpeiden puitteissa ilmaista Trello-verkkosovellusta [5].

Tämän projektin taulun neljä saraketta niiden luonnollisessa etenemisjärjestyksessä olivat Ei-tärkeät tekemättömät,Tärkeät tekemättömät,KeskenjaValmis, minkä lisäksi ku-

(25)

hunkin korttiin merkittiin, liittyikö se rajapinnan vai käyttöliittymän toteutukseen. Samaa taulua käytettiin myös sovelluksen ohjelmointityöhön liittymättömien tehtävien, kuten päi- väkirjakertomuksen sivujen leipätekstin sisällön kirjoittamisen, hallinnointiin.

Taululle lisättyjen korttien perusteella voitiin hahmottaa neljä tärkeää toiminnallisuuden osa-aluetta, joista kukin luonnollisesti jakautui rajapinnan ja käyttöliittymän toteutuksiin.

Sovelluksessa tulisi pystyä kirjoittamaan päiväkirjaa, jonka yhteydessä esitettäisiin kuhunkin päiväkirjan sivuun liittyviä valokuvia sekä kartta, jolla näytettäisiin vieraillut paikat.

Näiden kolmen pääkohdan lisäksi päiväkirjan muokkaamista varten pitäisi toteuttaa monipuolinen ylläpitosivu, jolle olisi pääsy vain kirjautumalla.

Matkapäiväkirjatoiminto nousi luonnollisesti näistä ominaisuuksista tärkeimmäksi. Suun- nitellessa päätettiin, että jokaiselle sovellukseen kirjatulle matkakertomukselle tulee olla lisättävissä mielivaltainen määrä päiväkirjan sivuja, esimerkiksi yksi kutakin matkan päi- vää kohden. Sovelluksen tuli kuitenkin tukea myös päivämäärään sitomattomia sivuja sekä sivujen järjestyksen muuttamista.

Kullakin päiväkirjan sivulla tuli olla vähintään otsikko sekä yleensä myös leipätekstisi- sältö, joka voi sisältää irrallisia tekstiosuuksia sekä vierailtuihin paikkoihin sidottuja ai- kajanamaisia osioita. Alusta alkaen tiedettiin, että samoja sijaintitietoja hyödynnettäisiin muissakin toiminnoissa, joten vieraillut paikat sekä yksittäiset kellonaikaan ja matkaan si- dotut vierailualkiot erotettiin heti omiksi malleikseen, eikä niitä säilötty missään vaiheessa päiväkirjan sivuilla pelkkänä tekstinä.

Kuvagallerian liittäminen päiväkirjan oheen oli lähes yhtä tärkeä ominaisuus kuin päivä- kirja itsessään. Yksinkertaiseksi toteutukseksi olisi riittänyt jo, että sovellus lukisi ennalta määrätyn hakemiston sisällön ja käyttöliittymä sitten näyttäisi linkin kuhunkin niistä. Käyt- töliittymään haluttiin kuitenkin kattavammin tietoa kustakin kuvasta.

Useimmat kamerat tallentavat kuvatiedostoon kuvaa otettaessa yksityiskohtaisia lisätie- toja kameran senhetkisistä asetuksista sekä mahdollisesti jopa kameran GPS (Global Positioning System)-koordinaatit, jotka kertovat, missä päin maailmaa valokuva on otet- tu. Kuvagallerian haluttiin lukevan nämä tiedot kustakin kuvatiedostosta ja näyttävän ne vähintään yksittäistä valokuvaa tarkastellessa. Lisäksi kuville määritettiin joitakin käsin syötettäviä, vapaaehtoisia tietoja, kuten otsikko, kuvaus ja lista avainsanoja.

Kuvagalleria itsessään suunniteltiin alun perin näkymään kahdella tapaa: yhdessä näky- mässä voisi tarkastella koko matkan galleriaa, toisessa taas yksittäiselle matkapäiväkirja- sivulle määritetyn ajanjakson aikana otettuja kuvia. Lisäksi yksittäisiä kuvia voisi upottaa matkapäiväkirjan tekstin sekaan. Kuvagallerian haluttiin myös tukevan piilotettuja kuvia, jotka olisivat näkyvissä vain tietyille kirjautuneille käyttäjille.

Kahta edellistä vähemmän tärkeä, mutta kuitenkin oleellinen päiväkirjaan haluttu kom- ponentti oli kartta, joka sijoitettaisiin päiväkirjan tekstin oheen ja jolla kuvattaisiin kaikki mahdollinen kartalla yleisesti näytettävä sisältö: päivän tai koko matkan aikana vieraillut paikat, kuljettu reitti ja kuvagalleriaan sisällytettyjen valokuvien sijainnit.

(26)

Mikään ei tietenkään estäisi toteuttamasta karttaa vain yksinkertaisena, palvelimelta tar- joiltavana kuvana. Kartan haluttiin kuitenkin olevan vuorovaikutteinen, sillä tällä tavoin käyttäjä voi esimerkiksi kohdistaa näkymän tietylle alueelle ja hahmottaa paremmin yk- sittäiset vieraillut paikat kartalla sekä tutkia niiden lähiympäristöä. Käytännössä mikään karttapalvelu ei kuitenkaan tarjoa tällaista karttaa täysin ilmaiseksi, joten toteutusta aloi- tettaessa jouduttaisiin vielä arvioimaan, mikä niistä soveltuisi tähän tarkoitukseen parhai- ten.

Periaatteessa sovellus olisi voinut jo olla täysin toimiva toteuttaessaan aiemmin mainitut toiminnot sekä rajapinnan että käyttöliittymän osalta. Käytännössä tämä olisi kuitenkin tarkoittanut, että kaikki tiedot olisi pitänyt lisätä sovelluksen käyttämään tietokantaan kä- sin. Luonnollisesti käyttäjän kannalta oli siis helpompaa ja mukavampaa päättää, että sovellukseen tulisi kuulua myös mahdollisuus lisätä matkaan liittyvät tiedot sen itsensä kautta.

Kullekin sovelluksen tärkeälle tietomallille kuuluu ylläpitotoiminnoissa oma, yleisimmin luvussa 2.1 mainitun CRUD-mallin mukainen alkioiden muokkausrajapinta sekä sitä vastaava käyttöliittymä. Huomionarvoista on, että projektin suunnitteluvaiheessa ei vielä otet- tu sen tarkemmin kantaa tietokannan rakenteeseen, vaan se kehittyi projektin edetessä osittain tarpeiden mukaan, ositellen pienempinä paloina suunnitellen. Siten projektin al- kuvaiheessa ei vielä ollut tarkalleen tiedossa, minkälaisia ylläpitokäyttöliittymiä ylipäänsä tarvitaan.

Suunnitellulla sovelluksella on vahvoja mashupin piirteitä [9]. Alkujaan termi on saanut nimensä musiikkityylistä, jossa eri kappaleiden osia yhdistelemällä saadaan aikaan aivan uudenlaista, alkuperäisiä kappaleita muistuttamatonta musiikkia, ja ohjelmistokehi- tyksen yhteydessä merkitys on hyvin samanlainen: sovellusta, joka yhdistelee erilaisia ja eri lähteistä tulevia sisältöjä uusilla tavoilla, voi kutsua mashupiksi. Tässä sovelluksessa tuodaan yhteen perinteisempi, käyttäjän näkökulmasta muuttumaton teksti- ja kuvasi- sältö sekä vuorovaikutteinen kartta, joka tuo uuden näkökulman päiväkirjan kuvaamaan reittiin.

3.4 Verrokkisovelluksia

Kuten aiemmin mainittiin, ennen sovelluksen toteuttamisen aloittamista arvioitiin, olisiko jossakin jo tarjolla olevassa ohjelmistossa toteutettu tarvittavat ominaisuudet riittävällä tasolla. Valmiiksi olevan sovelluksen suora käyttöönotto tai tarpeisiin mukauttaminen olisi vähentänyt tarvittavan työn määrää huomattavasti, vaikkakin tällöin projekti ei enää olisi edes ollut tämän tutkimuksen kannalta oleellinen.

PHP-pohjaiset Piwigo- ja WordPress-ohjelmistot osattiin nimetä mahdollisesti käyttötar- koitukseen sopiviksi vaihtoehdoiksi jo ennen kartoitusta. Kyseinen kartoitus jäi lopulta suppeaksi niin laajuudeltaan kuin tuloksiltaankin, eikä mahdollisia ehdokkaita siten löyty- nyt enempää. Tämä oli sinänsä odotettua, sillä mashup-tyyppisille sovelluksille tyypilliset

(27)

ominaispiirteet eivät yleensä ole helposti sovitettavissa laajalle käyttäjäkunnalle suunnat- tujen sovellusten tavanomaisiin muotteihin.

3.4.1 Piwigo

Pierrick Le Gallin alun perin kehittämäPiwigo[40] on PHP-pohjainen avoimen lähdekoo- din kuvagalleriasovellus. Siitä on tarjolla sekä omalle verkkopalvelimelle itse asennettava versio että useita ohjelmisto palveluna (SaaS,Software as a Service) -tyyppisiä valmiita ratkaisuja, joissa käyttäjä saa – yleisimmin säännöllisesti maksettavaa rahallista korvaus- ta vastaan tai mahdollisesti rajattuna versiona ilmaiseksikin – ohjelmiston suoraan käyt- töönsä jonkun muun tahon ylläpitämänä [51]. Piwigon tapauksessa yksi näistä on sen kehittäjistä koostuvan Pigolabsin ylläpitämäpiwigo.com-sivusto [99].

Alkuaikoinaan Piwigo tunnettiin nimelläPhpWebGallery [38], ja sen ensimmäinen versio julkaistiin 15. toukokuuta 2002. Nykyisen nimensä se sai version 2.0.0 julkaisun yhtey- dessä helmikuussa 2009 [39]. Projektin pitkäikäisyyden ja jatkuvien julkaisujen perusteella on syytä olettaa, että se on jo tullut testattua hyvin toimivaksi ja toivottavasti myös turvalliseksi vaihtoehdoksi. Kotisivuillaan Piwigo kertoo olevansa helppokäyttöinen, yksi- tyisyydensuojaominaisuuksiltaan kattava ja helposti laajennettava, ja erään työhön liitty- mättömän toisen sivuston ylläpidon ohessa väitteille oli ennen tätä selvitystä tuntunutkin jo löytyvän katetta.

Piwigon heikkoudeksi matkapäiväkirjan alustaa etsittäessä muodostui lopulta sen liian suuri painoarvo nimenomaan valokuvien hallinnoimiseen. Suuri osa matkakertomuksesta liittyisi valokuvattujen kohteiden välillä nähtyihin ja koettuihin asioihin, joten kokonaisen ja ehjän kertomuksen kirjoittaminen yksin valokuvien kuvateksteihin ei ollut mahdollinen vaihtoehto.

3.4.2 WordPress

Siinä missä Piwigo keskittyy erityisesti kuvagallerioihin,WordPress[67] on pohjimmiltaan yleiskäyttöisempi ja täysiverisempi sisällönhallintajärjestelmä. WordPress on niin ikään kirjoitettu PHP-kielellä, ja siitäkin on tarjolla itse asennettavan version lisäksi vastaavan- lainen, osoitteessawordpress.comtarjottava SaaS-ratkaisu [6].

Yhtäläisyydet Piwigoon eivät lopu tähän, sillä WordPresskin sai alkunsa 2000-luvun alku- vuosina. Vuonna 2003 Mike Little ja Matt Mullenweg päättivät lähteä jatkamaan ranska- laisen Michel Valdrighin aiemmin kirjoittamaaB2/cafelog-blogialustaa, jonka kehittämisen tämä oli yllättäen lopettanut ilman eri varoitusta [50, 67]. Syntyneen uuden ja parannel- lun ohjelmiston he nimesivät WordPressiksi. Vuosien saatossa WordPressin toiminnot laajenivat niin itse perusohjelmiston parannusten kuin myös kolmannen osapuolen kehit- tämien laajennosten ansiosta. Näillä laajennoksilla voi lisätä WordPressiin omien tarpei- densa mukaan lähes millaisia ominaisuuksia vain.

(28)

Vuosien saatossa WordPressistä on kehittynyt hyvin suosittu sisällönjulkaisualusta. Vuon- na 2018 verkkosivuanalytiikkaan erikoistunut W3Techs-sivusto kertoi, että yli 30 prosenttia tarkastelluista sivustoista käytti WordPressiä [111], ja kesäkuussa 2019 vastaava luku oli noussut jo lähemmäs 35 prosenttia [104]. Kaikista sivustoista, joiden toteutustekniik- ka on tiedossa, WordPressin osuus oli jopa 60 prosenttia [106]. Suosion perusteella olisi helppo todeta, että tavoitellun sovelluksen siihen sovittamisen ongelmiin olisi helppo löy- tää ratkaisuja, sillä todennäköisesti myös kehittäjien määrä on käyttäjien määrän tapaan suhteessa suurempi WordPressillä kuin sen kilpailijoilla.

WordPressin suosio ei kuitenkaan ole ollut täysin sen eduksi, sillä se tunnetaan melko haavoittuvaisena ohjelmistona. Tämän voi todeta yhdysvaltalaisen MITREn haavoittu- vuustietokannasta, jossa WordPressiin ja sen laajennoksiin liittyvä lista sisältää yli 1 500 yksittäistä haavoittuvuutta [122]. Lukua voi verrata esimerkiksi avoimen lähdekoodin Mo- zilla Firefox -selaimeen, johon liittyen on kirjattu noin 2 400 haavoittuvuutta [123]. Ensi silmäyksellä luvut näyttäytyvät WordPressin eduksi, mutta Firefoxin koodikanta on lähes neljäkymmentäkertainen – 20 miljoonaa riviä WordPressin noin 560 000 riviä vastaan [10] – joten on silti selvää, että haavoittuvuudet ovat WordPressissä verrattain yleisem- piä. Piwigolla vastaava kirjattujen haavoittuvuuksien määrä on vain 54, vaikka sen koodikanta on noin puolet WordPressin rivimäärästä [124].

Lopulta projektin kannalta tultiin siihen tulokseen, että vaikka WordPress olisi saattanut- kin olla varteenotettava vaihtoehto, sen mukauttamiseen perehtyminen sekä tarvittavien muutosten tekeminen olisi lopulta ollut verrattain työlästä. Omaan koodiin pohjautuvan ohjelmiston kirjoittaminen vaikutti sen perusteella paremmalta ratkaisulta, sillä vaikka se vaatisi vielä enemmän työtä, lopputulos olisi varmasti enemmän omannäköinen eikä vaatisi yhtä tiheää tietoturvapäivitysten asennustahtia. WordPressin kehittäjät ovat toki pyr- kineet korjaamaan turvallisuustilannetta ja lisänneet siihen turvaominaisuuksia, kuten viime vuoden helmikuussa julkaistussa 5.1-versiossa esitellyn sivuston terveydentilarapor- tin [66], mutta työtä on selvästi vielä jäljellä.