HTML5-gebaseerde monitoring voor digitale toeristische gidsen

Powered by TCPDF (www.tcpdf.org)

Academiejaar 2013–2014

Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg 1 – 9000 Gent

HTML5-gebaseerde monitoring voor digitale toeristische gidsen

Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica

Sam VLOEBERGHS Promotoren: Karel VAN ACHTE dr. Veerle ONGENAE dr. ir. Pieter SIMOENS

De auteur en promotoren geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen ervan te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting uitdrukkelijk de bron te vermelden bij het aanhalen van resultaten uit deze scriptie. The author and promoters give the permission to use this thesis for consultation and to copy parts of it for personal use. Every other use is subject to the copyright laws, more specifically the source must be extensively specified when using from this thesis. Gent, juni 2014

De promotoren: dr. Veerle Ongenae en dr. ir. Pieter Simoens De begeleider: Karel Van Achte De auteur: Sam Vloeberghs

Woord vooraf Na mijn eerste opleiding als Bachelor in de toegepaste informatica kreeg ik al snel het gevoel dat ik nog niet voldoende academische kennis had vergaard om mijn doelen in het leven te bereiken. Daarom begon ik na een jaar als freelance webontwikkelaar aan de bijkomende opleiding Master in de industriële wetenschappen: informatica via het schakelprogramma. Het is een harde strijd geweest dit te combineren met mijn zelfstandige activiteit. Mijn motivatie die de keuze voor dit onderwerp bepaalde kwam vooral voort uit mijn zeer sterke interesse in de ontwikkeling van het world wide web. Dit leek mij de ideale opportuniteit om mijn kennis over nieuwe web- en databanktechnologieën verder uit te diepen. Dit onderwerp kwam daarom als uit de hemel gevallen en om die redenen gaat mijn dank in eerste instantie ook uit naar mijn externe en interne promotoren, dr. ir. Pieter Simoens en Karel Van Achte. Zij gaven mij de kans dit onderzoek te voeren en boden waar nodig steeds hun steun aan bij de bijhorende problemen en vraagstukken. Verder gaat mijn dank ook uit naar elke vriend en collega in mijn directe omgeving die de tijd wou nemen om mijn scriptie na te lezen. Mijn ouders, last but definitely not least, verdienen het grootste respect om mij te blijven steunen. Zonder hun onvoorwaardelijke steun had ik deze bijkomende studies niet kunnen afronden. Sam Vloeberghs Gent, juni 2014

ii

Abstract In grote steden worden meer en meer digitale gidsen ingezet om toeristen wegwijs te maken langs de bezienswaardigheden. Dit levert vele interessante mogelijkheden tot het analyseren van de toeristenstroom doorheen de binnenstad. Zo kan men bijhouden wat de drukste routes zijn, hoelang de toeristen ergens halt houden en hoe ze de applicatie gebruiken. Zowel offline als online kan men door analyse van deze grote brok aan gegevens, hedendaags beschreven als Big Data, de werking en effectiviteit van de applicatie verbeteren. Om deze verzameling en verwerking van gegevens mogelijk te maken werd een SaaS oplossing bedacht en ge¨ımplementeerd. Deze kan gemakkelijk in bestaande HTML5-applicaties ingeplugd worden. De SaaS oplossing zorgt voor de verzameling en berekeningen en voorziet de applicatie op zijn beurt van de verwerkte statistische gegevens. In dit werk worden eerst enkele hot topics en bestaande relevante oplossingen besproken. Vervolgens wordt de uitgewerkte oplossing toegelicht aan de hand van de beschikbare technologieën, met op het einde een bespreking van de mogelijke verbeteringspunten en de genomen conclusies.

iii

Summary There is an increasing trend in the development of digital guides that show tourists around in big cities. These guides are able to collect a vast amount of data which can be analyzed to detect tourist flows throughout the city. This way, the busiest routes can be highlighted, how long tourists stay in a particular place as well as how the application is being used. These large sets of data, nowadays more commonly referred to as Big Data, can be used to improve the usability and effectiveness of the application. In order to gather and process the collected data a SaaS solution will be developed and implemented. This solution can be easily linked to an existing HTML5 application. The SaaS solution is capable of collecting and processing the data and, on its turn, provides the application with the processed statistical information. Some hot topics will be described and relevant existing solutions will be discussed. The final implementation will be explained by referring to the available technologies, with at the end a discussion about possible improvements and conclusions.

iv

Inhoudsopgave 1 Inleiding & situering 1.1 Locatie gebaseerde monitoring . . . . . . . 1.2 Digitale toeristische gidsen . . . . . . . . . . 1.3 Gerelateerde bestaande monitoring software 1.3.1 Google Analytics . . . . . . . . . . . 1.3.2 Statcounter . . . . . . . . . . . . . . 1.3.3 Woopra . . . . . . . . . . . . . . . . 1.3.4 Andere . . . . . . . . . . . . . . . . 1.4 Privacy . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

1 1 2 2 3 3 5 5 6

2 Big Data 2.1 Inleiding & definitie . . . . 2.1.1 Volume . . . . . . . 2.1.2 Velocity . . . . . . . 2.1.3 Variety . . . . . . . 2.1.4 Veracity . . . . . . . 2.1.5 Validity . . . . . . . 2.1.6 Volatility . . . . . . 2.2 Toepassingen & voorbeelden

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

7 7 8 9 10 10 10 11 11

3 Architectuur 3.1 Client . . . . . . . . . 3.1.1 Pluggable code 3.2 Server . . . . . . . . . 3.2.1 API . . . . . . 3.2.2 Controlepaneel 3.3 Databank . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

12 12 12 13 13 13 13

4 Technologie¨ en 4.1 HTML5 . . . . . . . . . . 4.1.1 Historiek . . . . . 4.1.2 Compatibiliteit . . 4.1.3 Browser support . 4.1.4 Battery status API 4.1.5 Geolocation . . . . 4.1.6 Offline & Storage .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

14 14 14 15 16 17 18 19

. . . . . .

v

Inhoudsopgave . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

22 24 24 25 26 26 28 30 32 32

5 Applicatie 5.1 Inleiding . . . . . . . . . . . . . . . . . 5.2 Modellen . . . . . . . . . . . . . . . . 5.2.1 Gebruikte technologieën . . . . 5.2.2 Applicatie . . . . . . . . . . . . 5.2.3 Gebruikers . . . . . . . . . . . 5.2.4 Locaties . . . . . . . . . . . . . 5.3 RESTful API . . . . . . . . . . . . . . 5.3.1 Gebruikte technologieën . . . . 5.3.2 Het data eindpunt . . . . . . . 5.3.3 Applicaties . . . . . . . . . . . 5.3.4 Gebruikers . . . . . . . . . . . 5.3.5 Locaties . . . . . . . . . . . . . 5.4 Controlepaneel . . . . . . . . . . . . . 5.4.1 Gebruikte technologieën . . . . 5.4.2 Applicaties beheren . . . . . . 5.4.3 Gebruikers en locaties beheren 5.5 Implementatie trackingcode . . . . . . 5.5.1 Trackingcode . . . . . . . . . . 5.5.2 Locatie update strategie . . . . 5.5.3 WebSocket en AJAX . . . . . . 5.5.4 Te verzamelen handelingen . . 5.6 Statistisch overzicht . . . . . . . . . . 5.6.1 Data aggregatie . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

36 36 37 37 37 38 39 41 41 43 43 44 44 44 45 45 46 48 48 49 52 53 54 55

6 Conclusies en perspectieven 6.1 Toekomst van HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Mogelijke uitbreidingen applicatie . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57 57 57 58

Lijst van broncodes

60

Lijst van figuren

61

Lijst van tabellen

62

4.2

4.3

4.1.7 WebSocket . . . . . . 4.1.8 WebRTC . . . . . . . 4.1.9 AJAX . . . . . . . . . 4.1.10 CORS ( & JSONP ) . JavaScript . . . . . . . . . . . 4.2.1 The good & bad parts 4.2.2 Node.js . . . . . . . . Databanken . . . . . . . . . . 4.3.1 OrientDB . . . . . . . 4.3.2 MongoDB . . . . . . .

vi . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Hoofdstuk 1

Inleiding & situering Het laatste decennium zijn er met de grote opkomst en populariteit van internet startups zoals Facebook, Google, LinkedIn e.a. een resem aan nieuwe technieken geboren om gebruikers te monitoren. De immense hoeveelheid aan gegevens die deze bedrijven hierbij verzamelen blijkt van onschatbare waarde te zijn voor het toepassen van o.a. gerichte e-marketing en optimalisatie van systemen & applicaties. Google, bijvoorbeeld, biedt met Google Analytics iedereen, gratis, enkele zeer sterke tracking tools aan. De websitebeheerder kan hierdoor alle acties van de gebruikers op zijn website monitoren. Monitoren omvat het bijhouden van, maar is zeker niet beperkt tot, het volgende: • inkomende pagina’s en populaire links of pagina’s • de tijdsduur van een bezoek aan de website • de herkomst en taal van de gebruiker

1.1

Locatie gebaseerde monitoring

Met de opkomst van mobiele toepassingen en het steeds stijgende aantal mobiele gebruikers, komen hier nu ook nog andere aspecten bij kijken. De gebruiker is het overgrote deel van de tijd dat hij een applicatie gebruikt in beweging. Hierbij kan het ook mogelijk zijn dat hij zijn connectie verliest of deze opzettelijk uitschakelt, bijvoorbeeld ter besparing van de batterij. Het geheel aan verzamelde data van de gebruiker kan dus ook aan zijn precieze locatie gekoppeld worden en of hij al dan niet de gehele tijd offline of online was. Dit biedt dan op zijn beurt extra diepgaande mogelijkheden om het gebruik en de ontwikkeling van een applicatie te verbeteren.

1

Hoofdstuk 1. Inleiding & situering

1.2

2

Digitale toeristische gidsen

In de usecase van digitale toeristische gidsen worden grote aantallen gegevens van toeristen verzameld. Deze geografische gegevens worden vervolgens gekoppeld aan de handelingen van de gebruiker op dat moment, op een specifieke locatie. De snelheid en efficiëntie waarmee de verzamelde gegevens verstuurd en verwerkt worden om vervolgens teruggekoppeld te kunnen worden aan de applicatie is hier zeer belangrijk. Wegens mogelijks beperkte connectiviteit mag de footprint die een datatransfer nalaat niet te groot zijn en moet dit alles toch zeer snel kunnen gebeuren. De terugkoppeling van verwerkte gegevens moet ook quasi realtime kunnen gebeuren. Op basis van de teruggekoppelde gegevens is het mogelijk het gebruik van de applicatie te analyseren en optimaliseren. Realtime analyse kan ook een aanzet zijn voor het versturen of opvragen van, tot de applicatie gerelateerde, last minute inhoud.

1.3

Gerelateerde bestaande monitoring software

De massieve groei van het internet bracht miljoenen gebruikers op het internet. Al snel hadden internetondernemers door dat de footprints van deze gebruikers op websites een groot marketingpotentieel hebben. Het laatste decennium hebben echter maar een beperkt aantal bedrijven en tools zich kunnen onderscheiden in dit segment. Wat volgt is een beknopt overzicht met een toelichting bij de grotere spelers. Deze kunnen naast elkaar ge¨ıntegreerd worden, maar zoals bij de meeste zaken; overdaad schaadt. Elke tool injecteert een bepaalde code die de website trager kan maken in gebruik. Integratie gebeurt meestal door injectie van een kleine codesnippet: 1 2 3 4 5 6 7 8 9

(function(i,s,o,g,r,a,m){ i[’GoogleAnalyticsObject’]=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date(); a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1; a.src=g;m.parentNode.insertBefore(a,m) })(window,document,’script’,’//www.google-analytics.com/analytics.js’,’ga’); ga(’create’, ’UA-xxxx’, ’example.com’); ga(’send’, ’pageview’);

Listing 1.1: Google Analytics injectie code


1.3.1

3

Google Analytics

Google Analytics is veruit de meest bekende en heeft ook het grootste marktaandeel. Door de webwereld wordt deze tool als de facto standaard beschouwd qua website analytics. 1.3.1.1

Historiek

Google Analytics was oorspronkelijk een onderdeel van Urchin Software Corp. en werd door Google overgenomen. Naast het SaaS product liet Google Urchin Software Corp. doorgaan met het verkopen van een client versie van het product, waarvan de verkopen werden gestaakt in maart 2012. Enkele grote mijlpalen in de ontwikkeling van Analytics zijn: • April 2005: Acquisitie van Urchin WebAnalytics door Google • September 2011 : Introductie Real Time Analytics • 2013: Introductie Universal Analytics Beta 1.3.1.2

Eigenschappen

Oorspronkelijk lag de focus van Google Analytics op de pagehits en aldus de bezoeken op de website. Met de introductie van Universal Analytics wil Google deze focus verschuiven naar de bezoekers van de website. Door gebruik te maken van een gebruikers-id is het mogelijk geworden om interacties te monitoren over verschillende toestellen heen, bijvoorbeeld websites, smartphones en tables. Dit heeft wel de extra vereiste dat je een gebruiker uniek kan identificeren, bijvoorbeeld a.d.h.v. een aanmeldingssysteem. Google Analytics wordt gebruikt door 48.9% van alle websites volgens een recent marktonderzoek1 .

1.3.2

Statcounter

Statcounter is een oude rot in de sector. Sinds deze tool in 1999 door Aodhan Cullen werd opgericht, onderging het al heel wat updates. In tegenstelling tot Google Analytics, die alle functionaliteit gratis aanbiedt, heeft Statcounter naast gratis basis functionaliteit ook betalende functionaliteiten. De globale statistieken van Statcounter worden gebruikt om de verdeling van webbrowsers te meten. Deze statistieken moeten toch een beetje genuanceerd worden aangezien niet alle verzoeken aan een webserver gegenereerd worden door feitelijke gebruikers. Onder hits worden bijvoorbeeld ook de verzoeken van indexering bots of automatische programma’s gerekend. Al is het wel mogelijk om deze er in beperkte mate uit te filteren. 1

http://w3techs.com/technologies/details/ta-googleanalytics/all/all


4

Over het algemeen kan er op basis van deze gegevens toch een vrij accuraat en bruikbaar beeld gevormd worden, dat een idee geeft over de globale verdeling: Browser

Feb. 2009

Feb. 2014

1,52%

46,69%

IE

64,43%

24,39%

Firefox

27,85%

20,78%

Safari

2,59%

5,00%

Opera

2,95%

1,38%

Andere

0,67%

1,76%

Chrome

Tabel 1.1: Verdeling desktop browsers1

De bovenstaande tabel toont een historische vergelijking van de verschillende desktop browsers. Over de jaren heen heeft Internet Explorer hard moeten inboeten ten opzichte van Chrome en Safari. De anderen zoals Firefox en Opera bleven redelijk stabiel en fluctueren over de jaren heen. Browser

Aug. 2012

Feb. 2014

Android

21,88%

24,39%

iPhone

16,65%

16,73%

Safari

16,71%

13,43%

1,02%

11,51%

15,59%

11,13%

UC Browser

6,23%

9,14%

Nokia

8,14%

4,52%

BlackBerry

3,71%

1,85%

0,6%

1,77%

11,1%

5,52%

Chrome Opera

IEMobile Andere

Tabel 1.2: Verdeling mobile & tablet browsers2

Bovenstaande tabel toont een historisch overzicht van de mobiele en tablet browsers. Enkele browsers werden pas in de loop van 2012 ge¨ıntroduceerd in beta: Chrome in juli 2012 en IEMobile in november 2012. Chrome zal uiteindelijk de Android browser verstoten van de troon omdat Chrome de standaard Android browser zal worden. Statcounter wordt gebruikt door 2.5% van alle websites volgens een recent marktonderzoek3 . 1

http://gs.statcounter.com/#desktop-browser-ww-monthly http://gs.statcounter.com/#mobile+tablet-browser-ww-daily 3 http://w3techs.com/technologies/details/ta-statcounter/all/all 2


1.3.3

5

Woopra

Woopra focust zich op realtime analytics, net zoals dit ook een functionaliteit is bij Google Analytics. Zodra een gebruiker op de website komt wordt hij gevolgd aan de hand van een unieke code die wordt opgeslagen in een cookie. Op geregelde tijdstippen en op basis van bepaalde triggers wordt er een callback uitgevoerd naar de Woopra server met informatie die het realtime opvolgen mogelijk maakt.

Figuur 1.1: Developer Tools - Woopra callbacks over netwerk

1.3.4

Andere

De drie voorgaande tools zijn steeds hosted oplossingen en rekenen op een JavaScript injectie in de website. Andere tools moeten ge¨ınstalleerd worden op de webserver of een aparte tracking server. Een kort, beperkt overzicht: 1.3.4.1

Hosted - SaaS

• Clicktale - http://www.clicktale.com • Webtrends - http://webtrends.com • Mint - https://www.mint.com/ 1.3.4.2

Installatie vereist op server of hybride

• Piwik - http://piwik.org • Splunk - http://www.splunk.com


1.4

6

Privacy

De Europese Unie en andere grootmachten hebben de laatste jaren dankzij al deze nieuwe tools heel wat werk gehad i.v.m. privacy problemen. Hierbij kregen ze de volgende vragen voorgeschoteld: • Welke gegevens mogen de grote bedrijven verzamelen van hun online gebruikers? • Waarvoor moeten ze een expliciete toestemming vragen? • Hoe kan de persoonlijke levenssfeer van de burger beschermd blijven? Het antwoord op deze vragen zorgde voor de formulatie van enkele verregaande privacy wetten, die zeker niet overal ter wereld uniform uitgewerkt zijn, laat staan gehanteerd worden. De verdere bespreking van privacy op het internet is buiten de scope van deze masterproef. In deze masterproef wordt er verondersteld dat de gebruiker instemt met de gevraagde zaken zoals bijvoorbeeld toegang tot zijn locatie of het gebruik van cookies in zijn favoriete browser.

Hoofdstuk 2

Big Data 2.1

Inleiding & definitie

Big Data op zich is niets nieuw. De term wordt hedendaags wel gebruikt als verzamelnaam voor alles wat te maken heeft met grote datasets die niet meer op een traditionele manier verwerkt kunnen worden, rekening houdend met de verwachte verwerkingstijd. Wat onder Big Data wordt begrepen hangt af van de mogelijkheden van de organisatie die de gegevens moet analyseren en bewerken. Voor sommige organisaties kan het optimaal beheren van 100TB al voor problemen zorgen terwijl andere, veel grotere organisaties, hulp zoeken bij het organiseren van 10EB. Anderzijds mag niet alles wat groot is onder de term Big Data gerekend worden. Grote datasets die niet snel geanalyseerd kunnen worden en tot veralgemeende resultaten leiden zijn onnuttig. Enkel specifieke analyses, zoals het optimaliseren van aanbevelingssystemen op bv. de Amazon website, kunnen nuttig ingezet worden. Reeds in 2001 definieerde analist Doug Laney de uitdagingen die bij de immense groei aan gegevens horen als driedimensionaal[8]: • Het stijgende volume aan gegevens - Volume • De snelheid waaraan gegevens binnenkomen en weer buitengaan in het systeem - Velocity • De variatie aan gegevenstypes en structuren - Variety In 2012 paste Doug Laney zijn definitie weer aan naar de vorm waarmee elke IT’er wel al eens in contact mee gekomen is het laatste jaar: Big data is high volume, high velocity, and/or high variety information assets that require new forms of processing to enable enhanced decision making, insight discovery and process optimization[1] . 7

Hoofdstuk 2. Big Data

8

Figuur 2.1: De drie V’s: Volume, Velocity & Variety

Anderen voegen hier nog minstens drie opmerkelijke extra V’s aan toe, de V’s van Veracity, Validity en Volatility. Deze drie extra V’s zijn echter van toepassing op alle gegevens en niet specifiek op Big Data[7].

2.1.1

Volume

Big Data impliceert grote volumes aan gegevens. In het begin van het digitale tijdperk was dit vooral data die aangemaakt en opgebouwd werd door mensen zelf. De dag van vandaag worden datasets vooral automatisch opgebouwd bij het verzamelen van gegevens, zoals het bijhouden van logbestanden of het automatisch verzamelen en linken van persoonsgegevens zoals Facebook dat doet. Deze grote hoeveelheid gegevens geeft ook de aanzet tot nadenken over alternatieve pisten in opslagmogelijkheden. Moeten we de data in-memory houden om er snel weer aan te kunnen? Kunnen we data bewaren in het netwerk in plaats van op schijf? Gaan we verticaal of horizontaal schalen? Bij traditionele databank servers moest men typisch verticaal schalen omdat de implementatiekost van het toevoegen van nodes veel duurder uitkwam en de performantie niet echt verbeterde.


9

Figuur 2.2: Horizontaal vs. verticaal schalen

Bij verticaal schalen wordt de capaciteit van de systemen vergroot. De processor krijgt een upgrade, traditionele HDD’s worden vervangen door snellere SSD’s en het beschikbare werkgeheugen wordt uitgebreid. Bij horizontaal schalen worden verschillende nodes ingezet die samen al het werk op zich nemen. Dit zijn meestal autonome systemen die door middel van load balancing aparte delen van de benodigde rekenkracht en dataverwerking afhandelen. Horizontaal schalen wordt slimmer beschouwd dan verticaal schalen omdat het laatste in principe een brute-force methode is en deze eindig is. Je kan horizontaal, in theorie, zoveel nodes toevoegen als nodig is. Verticaal schalen botst reeds veel sneller tegen een plafond van architecturale implementatiemogelijkheden. Deze zaken staan in een directe relatie met het volgende puntje, velocity.

2.1.2

Velocity

Door de toename van het aantal gegevens wordt er dus ook steeds meer verstuurd over het Internet. Machines en computers krijgen meer en meer input vanuit randapparatuur en moeten mogelijks ook weer zelf de (verwerkte) data doorspelen aan andere systemen. Het belangrijkste aspect is hierbij de (benaderde) realtime verzending en verwerking van deze gegevens. Indien dit niet snel genoeg kan gebeuren is het resultaat mogelijks waardeloos.


2.1.3

10

Variety

De verzamelde gegevens kunnen enorm gevarieerd zijn. Dit kan best met een kort voorbeeld toegelicht worden. Stel jezelf een klassieke databank voor met klantgegevens. Per klant kan ook een enorme hoeveelheid aan informatie over sociale media gekoppeld worden, bv. de publieke statusupdates op Twitter en Facebook. Sommige klanten hebben daarbij ook nog een aantal fotoalbums op Flicker staan en deze foto’s bevatten meestal EXIF-data1 met bijvoorbeeld locatiegegevens. Een bepaalde klant heeft deze foto’s gebruikt in een blogpost waarin hij een reis naar een Oosters land beschrijft. Al het voorgaande zijn gestructureerde gegevens, met daarnaast ook ongestructureerde gegevens zoals bij het blog-voorbeeld. Al deze informatie moet gekoppeld, verwerkt en eventueel bewaard worden. Opslag van deze informatie is niet altijd een vereiste, wat telt is het resultaat van de analyse.

2.1.4

Veracity

Veracity of waarheidsgetrouwheid bepaalt of de beschikbare data wel geschikt is om tot een analytische oplossing voor het probleem te komen. Bij het bepalen van een Big Data strategie moet de organisatie zeker kunnen zijn van de correctheid van de verzameling van gegevens. Hierbij moeten mogelijks processen worden opgestart om zoveel mogelijk overbodige en “vuile” data uit de systemen te weren. Het volgende puntje gaat dieper in op het controleren en valideren van deze gegevens.

2.1.5

Validity

Bij het verzamelen van gegevens binnen de Big Data context wordt er niet echt gecontroleerd op de geldigheid van de gegevens. De gegevens die binnenkomen kunnen overdreven gecompliceerd en “vervuild” zijn. Zodra de organisatie start met het verwerken van (subsets van) deze gegevens moet deze getransformeerd worden tot een waardevolle set van gegevens die betrouwbare analyses kan opleveren. In bepaalde contexten, zoals bij het gebruik van Big Data in medische onderzoeken, moet deze betrouwbaarheid meestal meerdere malen gecontroleerd worden.

1

Exchangeable image file format: Standaard om metadata in afbeeldingen te bewaren


2.1.6

11

Volatility

Volatility, vrij vertaald naar “maatstaf van de beweeglijkheid of verandering”, bespreekt de geldigheidsduur van verzamelde gegevens. Door constant veranderende parameters is het mogelijk dat gegevens die 2 seconden geleden werden verzameld nu niet meer geldig zijn. Daarom kan het interessant zijn om in plaats van de data zelf, alleen de analytische resultaten te bewaren. In sommige gevallen wordt alle data gewoon vergeten omdat ze niet meer nuttig is in de toekomst. Alles bewaren zou ook teveel schijfruimte en dus ook teveel geld kosten. Hoelang de set aan gegevens beschikbaar moet blijven hangt bijgevolg af van een aantal factoren: • Hoeveel data wordt er geproduceerd door en bewaard op de bron? • Heeft de organisatie een bepaald beleid rond het bijhouden van data of worden er regels opgelegd door de wetgeving? • Moet de verzamelde data meermaals worden geanalyseerd? • Is de data belangrijk voor de dagdagelijkse werking van de organisatie? Indien de organisatie al zeker deze vier vragen kan beantwoorden kunnen ze een beleid opstellen i.v.m. het bijhouden van zeer snel veranderende gegevens. Big Data en al zijn aspecten is in zekere zin reeds toepasbaar op onze usecase van digitale toeristische gidsen. De grote brok aan gegevens die daarbij verzameld wordt moet op een snelle en efficiënte manier vanuit de smartphone op de server terecht komen. Het is wenselijk dat in sommige gevallen, zoals bij een laag beschikbaar werkgeheugen of batterijniveau, enkel de nuttige gegevens worden verwerkt. Deze gegevens zijn (semi-)ongestructureerd en moeten eerst gevalideerd worden alvorens ze gestructureerd bewaard kunnen worden in de databank.

2.2

Toepassingen & voorbeelden

Het toepassen van analyses op grote datasets gebeurt al veel langer dan sinds de hype in 2013 losbarstte. Het is pas sinds vorig jaar dat iedereen “in het gat in de markt wilt springen”. Enkele cijfers die dit verduidelijken: • Large Hadron Collider: Sinds de opstart in 2008 tot 2012 had deze deeltjesversneller 300 x 1012 LHC proton botsingen geanalyseerd. Dit resulteerde in een productie van data van om en bij de 25PB per jaar[20]. • Walmart: Walmart startte met het gebruik van Big Data reeds voor dat de hype zijn intrede deed. Walmart behandelt meer dan 1 miljoen klanttransacties per uur en produceert daarbij ongeveer 2,5PB aan data[5].

Hoofdstuk 3

Architectuur Om de uitwerking van de te maken applicatie te bespreken moet er eerst besloten worden welke architecturale onderdelen vitaal zijn en hoe deze uitgewerkt zullen worden. Het SaaS1 principe is hierbij zeer sterk aangewezen. De monitoringcode die wordt ingeplugd in nieuwe of bestaande webapplicaties is namelijk een generieke bibliotheek die aldus op elke client dezelfde functionaliteit zal vertonen. Het belangrijke aspect hierbij is dat de ontwikkelaar van een specifieke applicatie zelf kan beslissen welke functionaliteiten hij gebruikt of aan welke hij prioriteit verleent. In het algemeen komen er 3 grote aspecten aan bod; de client-side of front-end applicatie, de server (backbone van de service) en de gebruikte databank.

3.1

Client

De client vereist een webapplicatie in de browser. Ongeacht welke functionaliteit deze applicatie aanbiedt moet deze het gebruik van HTML5 ondersteunen. De algemene aanbeveling naar webontwikkelaars is hedendaags het gebruik van HTML5, dus dit zou al zeker geen obstakel meer mogen zijn.

3.1.1

Pluggable code

Onder de term pluggable code wordt begrepen dat de hosted functionaliteit op de server makkelijk in de nieuwe of bestaande code kan ingeplugd worden. Dit kan door een kleine code snippet zoals reeds beschreven in listing 1.1 van sectie 1.3. Op basis van parameters in deze code snippet kan dan bepaald worden welke functionaliteiten verwacht worden van de ge¨ınjecteerde software. 1

Software as a Service

12

Hoofdstuk 3. Architectuur

3.2

13

Server

De server moet een grotere set aan taken verrichten. De pluggable code, zoals eerder beschreven, moet efficiënt aangeleverd worden aan de webapplicatie en mag deze maar zo min mogelijk vertragen of verzwaren. Vervolgens moet de verzamelde en (semi-)ongestructureerde data doorgegeven worden aan de databank. Achteraf moet deze data ook weer raadpleegbaar zijn, maar onder de vorm van meer gestructureerde data die gemakkelijk statistisch kan verwerkt worden. De data kan beheerd worden door gebruik te maken van een API1 .

3.2.1

API

De API moet in eerste instantie een toegangspunt bevatten om de (semi-)ongestructureerde data die op de client verzameld wordt op te slagen in de databank. Hierbij moet een vorm van authenticatie worden toegepast die ervoor zorgt dat niet iedereen zomaar data naar de databank kan versturen. Dit kan onder de vorm van domain/ip whitelisting maar omdat dit gemakkelijk vervalst kan worden is het aangeraden om toch met een gedeelde geheime sleutel te werken die ook individuele authenticatie toelaat. In tweede instantie moet de API een toegangspunt voorzien om de gestructureerde data af te leveren aan ge¨ınteresseerden en de mogelijkheden bieden om deze waar nodig te bewerken.

3.2.2

Controlepaneel

Op basis van de API kan een controlepaneel gebouwd worden die de functionaliteit beschrijft en implementeert. Dit controlepaneel kan dan later eenvoudig omgevormd worden tot een plugin in een bestaand CMS2 of CMF3 zoals WordPress of Drupal.

3.3

Databank

De gewenste soort databank voor deze applicatie is af te wegen aan de hand van enkele fundamentele zaken. De monitoring software maakt het mogelijk om parameters in te stellen naar de werking toe en dit zorgt voor variërende datamodellen die sterk kunnen afwijken van elkaar en dus typisch niet ideaal worden opgeslagen in een relationeel model, dat alleen maar een overvloed aan lege kolommen zou bevatten in een tabel. Het document-georiënteerd model laat toe om meer variërende en (semi-)ongestructureerde data op te slaan. Het gebruik van een DOBMS is dus aangewezen boven een RDBMS (zie 4.3).

1

Application Programming Interface Content Management System 3 Content Management Framework 2

Hoofdstuk 4

Technologie¨ en 4.1

HTML5

Ter uitwerking van dit werk wordt gebruik gemaakt van de relatief nieuwe versie van HTML. Doorheen deze thesis wordt er regelmatig gerefereerd naar bepaalde technieken en termen die hier kort maar bondig worden toegelicht. HTML5 is de nieuwste, maar nog niet geheel afgewerkte versie van de HTML-standaard. Deze heeft als doel een betere ondersteuning te bieden voor zowel online als offline gebruik van webapplicaties. De term is veelal een marketingterm en omvat naast versie 5 van HTML ook bijhorende technieken zoals CSS3, JavaScript en dataformaten zoals XML en JSON.

4.1.1

Historiek

Toen HTML5 in 2008 ge¨ıntroduceerd werd was het nog maar een vage omschrijving. Meteen kwam er de vraag of het zou zorgen voor verdere verdeling of eenmaking. Er waren immers verschillende sectoren die akkoord moesten gaan met de beslissingen of aanbevelingen die de WHATWG1 maakte, zoals content providers, browser vendors en hardware ontwikkelaars. Dit zorgde ervoor dat de WHATWG nu vooral bestaat uit vooraanstaande mensen uit deze verschillende sectoren. De WHATWG is opgericht in 2004 door medewerkers van Apple, Mozzila Foundation en Opera met als specifiek doel om HTML5 te ontwikkelen. In 2006 kondigde het W3C2 aan dat ze stopten met de ontwikkeling van XHTML en dat ze zich samen met WHATWG gingen focussen op de verdere ontwikkeling van HTML. Tegen 2008 werd dan ook de eerste versie van de HTML5 draft gepubliceerd. Eind 2011 gebruikte reeds 35% van de Alexa’s Top-100 wereldwijd HTML5 als specificatie. 1 2

Web Hypertext Application Technology Working Group - http://whatwg.org World Wide Web Consortium - http://w3.org

14

Hoofdstuk 4. Technologieën

15

Figuur 4.1: Het HTML5 logo

Het hek was echter helemaal van de dam toen Steve Jobs in 2010 openlijk Flash afschreef. Hij argumenteerde dat Flash ontworpen was voor gebruik op computers die bediend worden door een muis. De toekomst lag volgens zijn visie vooral in apparaten die met de vingers bediend worden. Deze uitspraken zetten veel bedrijven aan tot het implementeren van HTML5 in hun applicaties met als gevolg Flash een stille dood te laten sterven. Vandaag de dag gebruiken meer en meer websites de technologie en wordt HTML5 ook ingezet in andere toepassingen zoals het opzetten van het smartphone besturingssysteem Firefox OS of als hybride toepassingen in mobiele applicaties m.b.v. van Cordova of PhoneGap.

4.1.2

Compatibiliteit

Het grootste probleem tot op vandaag is dat HTML5 nog niet uniform ge¨ımplementeerd is over alle browsers en toestellen heen die HTML5 in hun layout engine gebruiken. HTML5 is zoals eerder gezegd nog maar een working draft en nog geen W3C aanbeveling. Browser ontwikkelaars doen echter hun uiterste best om dit zo snel mogelijk te integreren waar mogelijk. Internet Explorer en vooral de mobiele browsers hinkten nog enige tijd achterop maar deze hindernis lijkt grotendeels achter de kiezen. Er zijn nog delen van de HTML5 specificatie die niet altijd even gemakkelijk of zinvol te implementeren zijn op bepaalde toestellen. Drag and drop is zo’n functionaliteit die nog maar weinig steun krijgt op smartphones en opgevangen wordt in JavaScript bibliotheken zoals jQuery UI.


4.1.3

16

Browser support

Indien we over browser support praten moeten we eerst verduidelijken hoe browsers de HTML5 code vertalen naar visuele interpretaties. Elke verschillende browser gebruikt meestal één van 5 meest populaire layout engines 1 : • Gecko: De ontwikkeling van Gecko reikt al ver terug en begon bij Netscape in 1997. Enkele populaire browsers en programma’s die deze engine nog steeds gebruiken zijn Firefox, Thunderbird en meer recent ook Firefox OS. • Trident: Deze engine, ook bekend als MSHTML, wordt gebruikt door Windows versies van Internet Explorer. Internet Explorer heeft de laatste jaren veel kritiek gekregen wegens een traag updatebeleid en vooruitgang inzake webstandaarden. Met de komst van Internet Explorer 9 tot 11 hebben ze dit wel meer dan goed gemaakt. • WebKit: Webkit was een tijd de meest gebruikte engine op het internet, maar kreeg een serieuze kaakslag toen Google WebKit forkte ter gebruik in zijn browser Chrome. WebKit wordt nog steeds gebruikt door Safari, Tizen en Steam. • Blink: Blink is de door Google geforkte versie van Webkit. Het gebruikt dus de reeds zeer volwassen features van WebKit maar heeft als doel de codebase eenvoudiger en sneller te maken. • Presto: Deze engine werd voor meer dan 10 jaar gebruikt in Opera en werd in 2013 vervangen door WebKit om vervolgens ook Chrome te volgen in zijn implementatie van Blink. Het lijkt erop dat het gebruik van Presto stilaan zal uitdoven. De implementatieverschillen van de functionaliteiten van HTML5 in de verschillende browsers worden pas geheel duidelijk als we ze allemaal vergelijken. Daarvoor is er een zeer handige website2 die alle browsers vergelijkt en ook ingaat op de historische verschillen. Een goed voorbeeld hiervan is het gebruik van date/time input types. Wat meteen opvalt is dat er nog niet veel support voorzien is en deze feature nog steeds wordt beschouwd als een Working draft 3 . Vooral op mobile is er reeds noemenswaardige support. Dit is een opmerkelijk positieve vaststelling aangezien deze input velden handig gebruik maken van selectiemogelijkheden van de mobiele besturingssystemen. Net zoals dit al het geval is bij het <select> element, zie figuur 4.2. 1

Layout-engines: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5) Can I Use - http://caniuse.come 3 Can I Use input/datetime fields http://caniuse.com/input-datetime 2


17

Figuur 4.2: <select> gebruikt native selectie functionaliteit

4.1.4

Battery status API

De Battery status API laat de browser toe de status van de batterij te meten. Dit is uiteraard enkel relevant op mobiele toestellen zoals smartphones, tablets en laptops. Er zijn 2 kleine maar belangrijke zaken die opgevraagd kunnen worden door middel van deze API; het batterijniveau en de oplaadstatus. Beide zaken kunnen zeer nuttig gebruikt worden om energie-bewuste én energie-efficiënte webapplicaties te bouwen. 4.1.4.1

Batterijniveau en oplaadstatus opvragen

1 var battery = navigator.battery // of browser specifieke implementaties 2 || navigator.mozBattery || navigator.webkitBattery; 3 4 if(battery){ // controle op battery api implementatie 5 6 function handleLevelChange(){ 7 console.log("Battery status: " + battery.level * 100 + " %"); 8 console.log("Battery charging: " + (battery.charging) ? "yes": "no"); 9 /* volgende stap: energie strategie aanpassen op basis van de status */ 10 } 11 handleLevelChange(); // aanvankelijke oproep 12 // koppel event handlers 13 battery.addEventListener("chargingchange", handleLevelChange); 14 battery.addEventListener("levelchange", handleLevelChange); 15 16 }

Listing 4.1: Batterij niveau en oplaadstatus opvragen


18

Eerst moet gecontroleerd worden of er effectief ondersteuning is voor de battery status API. Door het koppelen van een functie aan de chargingchange en levelchange events kan de strategie van de applicatie op basis van het niveau en de oplaadstatus dynamisch aangepast worden.

4.1.5

Geolocation

Geolocation in HTML5 omvat de API in JavaScript die ontwikkelaars de kans biedt om de locatie van een gebruiker op te vragen. De API biedt een high-level interface naar bepaalde locatiegegevens zoals een geschatte latitude en longitude. De API is “agnostisch”, wat wil zeggen dat de API niet weet wat specifiek zorgt voor de bepaling van de locatie. Het neemt gewoon wat beschikbaar is op het moment van aanvraag[16]. Een locatiewijziging bepaalt de basisstrategie ter verzenden van data naar de server in de applicatie. Het privacy aspect is hier echter wel onontbeerlijk. De clientprogramma’s mogen niet zomaar deze informatie delen met de website of de programma’s die er toegang tot wensen. Er zijn nog andere vereisten, maar hier gaan we niet verder op in1 . 4.1.5.1

Methoden

Internet en computer geolocation kan uitgevoerd worden door gebruik te maken van het IPadres, MAC-adres of andere identificerende eigenschappen (uuid, EXIF-data, ..). Dit geeft echter meestal maar een indicatie van in welke regio een bepaald systeem of gebruiker zich bevindt. Meer precies kan de locatie, van bijvoorbeeld een bewegende gebruiker, bepaald worden door gebruik te maken van Wi-Fi positioneringsystemen of GPS coördinaten met een hoge nauwkeurigheid.

Figuur 4.3: Locatiebepaling op basis van Wi-Fi, GPS of GSM-netwerk 1

Meer info over privacy i.v.m. geolocation: http://www.w3.org/TR/geolocation-API/#security


4.1.6

19

Offline & Storage

De offline mogelijkheden en opslagcapaciteiten van HTML5 hangen een beetje samen. Een kort voorbeeld: Een webapplicatie bewaart code snippets op een server maar kan ook offline werken. Op de trein valt de mobiele verbinding weg in een tunnel en de snippet moet toch bewaard kunnen worden. Deze snippet wordt dan bewaard in de opslagcontainer van de browser. Zodra de trein uit de tunnel komt merkt de browser dat er weer connectie is met het Internet en worden de offline snippets gesynchroniseerd naar de server. 4.1.6.1

Web Storage

Web Storage is de generische verzamelnaam voor alles wat te maken heeft met dataopslag op de client en aldus in de browser. Momenteel omvat het de volgende termen: localStorage, sessionStorage en in mindere mate cookies. 4.1.6.2

localStorage en sessionStorage

localStorage en sessionStorage bieden een zeer simpele API die het mogelijk maakt om informatie op te slaan in een associatieve lijst. Deze lijst is wel beperkt tot het bewaren van tekstuele data. Dit leent zich perfect om XML of JSON op te slaan. 1 2 3 4 5 6 7 8 9 10 11

function getObjectFromStorage(key){ return (!localStorage[key] || localStorage[key] === "") ? {} : localStorage[key]; } function setStorage(data, key){ localStorage[key] = JSON.stringify(data); } var data = { "foo": "bar" }; setStorage(data,"key"); data = getObjectFromStorage("key");

Listing 4.2: localStorage benaderen

Het enige echte nadeel aan localStorage is de zeer beperkte hoeveelheid data die kan worden bewaard. Deze capaciteit wordt op aanraden van het W3C beperkt tot 5MB[17]. Deze data is echter beperkt per domein, dus in principe is het mogelijk om gebruik te maken van subdomeinen om grotere hoeveelheden data op te slaan. Indien we andere zaken willen bewaren, zoals grote binaire videobestanden, kan er beter gebruik worden gemaakt van de HTML5 File API1 . Deze API is buitenom de scope van deze masterproef en zal dan ook niet verder worden besproken. 1

HTML5 File API - http://www.w3.org/TR/FileAPI/


20

Het grote verschil tussen localStorage en sessionStorage is de scope van opslagmogelijkheden. localStorage data is toegankelijk in alle sessies, met verschillende tabbladen, die op de client uitgevoerd worden voor een bepaald domein. sessionStorage is beperkt tot 1 sessie of tabblad en wordt verwijderd zodra de sessie wordt beëindigd. Web Storage wordt reeds zeer sterk ondersteund door de browsers, ongeveer 90% ten tijde van schrijven, met de enigste beperking zijnde Opera Mini1 . 4.1.6.3

Online / offline detectie

Verder gaande op het voorbeeld kan de browser, zodra deze merkt dat er weer connectiviteit is, de opgeslagen data doorsturen naar de server. Een extra controle op connectie naar het Internet is nodig aangezien navigator.onLine alleen controleert of de browser verbonden is met een netwerk en niet noodzakelijk met het Internet[12]. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

function offlineListener(e){ application["online"] = false; } function onlineListener(e){ application["online"] = true; persist_local_data(); } window.addEventListener("offline", window.addEventListener("_offline", window.addEventListener("online", window.addEventListener("_online",

checkOnline, false); offlineListener, false); checkOnline, false); onlineListener, false);

function checkOnline() { if (navigator.onLine){ var i = new Image(); i.onerror = function() { fireEvent("_offline", document, {}); }; i.onload = function() { fireEvent("_online", document, {}); }; i.src = "http://facebook.com/favicon.ico"; } else fireEvent("_offline", document, {}); }

Listing 4.3: Online/offline events afhandelen en extra controle op internetconnectie

Het bovenstaande codevoorbeeld koppelt een eventlistener checkOnline() aan de offline en online events. Deze voert nog een extra controle uit op connectiviteit door een afbeelding op te halen van het Internet. De onerror en onload events voeren dan respectievelijk de offlineListener() of onlineListener() eventlistener uit. 1

localStorage ondersteuning - http://caniuse.com/namevalue-storage

Hoofdstuk 4. Technologieën 4.1.6.4

21

Web SQL & IndexedDB

Alhoewel Web SQL reeds in november 2010 als depecrated werd aangekondigd door het W3C lijkt het erop dat de meeste browsers deze functionaliteit zullen blijven ondersteunen, maar dan onder de vorm van zijn vervanger IndexedDB. IndexedDB is een object-store, wat wil zeggen dat er geen gebruik gemaakt wordt van tabellen met rijen en kolommen, maar wel met meer algemene JavaScript objecten. IndexedDB geeft nog wel de mogelijkheid om de typische SQL opdrachten te schrijven zoals we ze gewoon zijn uit SQL omgevingen. De API mapt deze SQL opdrachten dan op indexed searches in de lijst met objecten. Oudere browsers kunnen compatibel gemaakt worden door polyfills te includen die o.a. gebruik maken van Web SQL1 . In deze masterproef wordt er geen gebruik gemaakt van IndexedDB maar deze kan wel beschouwd worden als een waardig alternatief voor localStorage indien we meer mogelijkheden willen en ruimte nodig hebben bij het opslaan van meer voorkomende en gestructureerde gegevens. 4.1.6.5

Application Cache

Het wordt steeds belangrijker voor webapplicaties om offline hun functionaliteit te behouden. Een mooi voorbeeld hiervan is Gmail, dat toelaat om mails te lezen en op te stellen zonder internet verbinding. De concepten worden opgeslagen met een vorm van Web Storage zoals IndexedDB of localStorage en worden verzonden zodra de applicatie merkt dat er weer een internetverbinding beschikbaar is. Een ander voordeel is het optimaliseren van de laadtijd. Bronnen kunnen rechtstreeks vanuit de cache worden ingeladen en vereisen geen verzoek naar en antwoord van de server meer. Application Cache zal niet worden gebruikt in de technische uitvoering van deze masterproef maar is zeker het vermelden waard. Dit in verband met de ontwikkeling van een mogelijke usecase. Mobiele toeristische gidsen moeten ook offline beschikbaar kunnen zijn indien een gebruiker zijn gegevensverbinding (met opzet) uitgeschakeld wordt. Zo wordt zijn gebruikerservaring zo weinig mogelijk verstoord.

1

HTML5 IndexedDB polyfills https://github.com/Modernizr/Modernizr/wiki/ HTML5-Cross-Browser-Polyfills#indexeddb


22

Kort voorbeeld 1 2 3 4 5 6 7 8 9 10 11

CACHE MANIFEST # v1 2014-01 index.html style.css image1.png # Load from network NETWORK: network.html # This is a comment FALLBACK: / fallback.html

Listing 4.4: Application cache : Manifest voorbeeld

Bovenstaand voorbeeld gebruikt NETWORK en FALLBACK secties om aan te duiden dat de network.html pagina altijd geladen moet worden vanaf het netwerk. fallback.html moet hierbij worden aangeleverd als een backup, indien er geen connectie naar de server kan worden vastgelegd.

4.1.7

WebSocket

WebSocket is een protocol dat voorziet in full-duplex communicatiekanalen over één enkele TCP verbinding, vooral ontworpen voor implementatie in webbrowsers en webservers. Het doel van websockets is om meer mogelijkheden te bieden in communicatie tussen de browser en een website. Dit voorziet in meer opties om bijvoorbeeld realtime games of chats te ontwikkelen in de browser. Een ander groot voordeel van websockets is dat het de mogelijkheid biedt om firewalls en proxyservers te omzeilen. Dit is een probleem voor vele toepassingen. Een websocket detecteert een proxy en voorziet automatisch een tunnel om deze te doorlopen. 4.1.7.1

Protocol

Het WebSocket protocol werd dus ontworpen om goed te werken in de reeds bestaande Internet infrastructuur. Daardoor start een WebSocket connectie zich op als een HTTP connectie. Dit garandeert de volledige backwards-compatibiliteit met de implementaties voorgaand op websockets. Naar de overgang van HTTP naar WebSocket wordt verwezen als handshake of upgrade.


23

Vervolgens kunnen zowel clients als servers data uitwisselen onder de vorm van berichten. Deze berichten worden getriggerd door zowel events op de servers als op de clients1 . Eens er een connectie is tussen client en server kan ook de server het initiatief nemen om berichten te versturen. Het gekende en mogelijks zware polling mechanisme wordt hierbij dus vervangen door push mogelijkheden, evenwel n´ a de initiële verbinding door de client.

Figuur 4.4: Het WebSocket protocol2

De browser stuurt een request naar de server, met de indicatie dat het wilt omschakelen van HTTP naar WebSocket. De client geeft dit aan in de HTTP header van het bericht: 1 2 3 4 5 6 7 8

GET ws://localhost:8080/?encoding=text HTTP/1.1 Origin: http://localhost:8080 Cookie: __utma=99as Connection: Upgrade Host: localhost:80 Sec-WebSocket-Key: ROqsefa/ezfoetod== Upgrade: websocket Sec-WebSocket-Version: 13

Listing 4.5: HTTP request voor upgrade

Indien de server het protocol begrijpt gaat deze toestaan de overgang te maken door middel van een upgrade header (zie listing 4.6). 1 2

http://tools.ietf.org/html/rfc6455#section-1.2 http://www.pubnub.com/blog/what-are-websockets/


1 2 3 4 5 6 7 8

24

HTTP/1.1 101 WebSocket Protocol Handshake Date: Fri, 10 April 2014 13:23:53 GMT Connection: Upgrade Server: API Server Upgrade: WebSocket Access-Control-Allow-Origin: http://localhost:80 Access-Control-Allow-Headers: content-type Sec-WebSocket-Accept: lZDryk/KJerThKI/KIXDEkszkoA=

Listing 4.6: HTTP upgrade message

Zodra deze stappen gebeurd zijn wordt de HTTP connectie stopgezet en vervangen door de websocket maar hierbij worden nog steeds dezelfde poorten van HTTP en HTTPS gebruikt, standaard 80 en 443. Eens dat de connectie gelegd is kunnen frames met zowel tekstuele als binaire data over en weer gestuurd worden tussen client en server. De specificatie van WebSocket is al redelijk volwassen. De implementatie door de verschillende browsers is hierdoor goed vooruitgegaan. Op mobiele platformen is het enkel Opera mini die achterloopt.

4.1.8

WebRTC

WebRTC1 is een protocol ontworpen door Google. Het geeft webdevelopers de mogelijkheid om webapplicaties te bouwen die spraak- en videogesprekken ondersteunen. Er is dus de mogelijkheid om data uit te wisselen tussen 2 clients. In principe sluit het onderwerp een beetje aan bij het WebSocket protocol, alleen heeft het een ander doel. Om data door te sturen naar de server lijkt dit dus geen optimale oplossing.

4.1.9

AJAX

AJAX is technisch gesproken niet echt een onderdeel van HTML5, maar het is niet meer weg te denken in hedendaagse applicaties. Bij AJAX wordt gebruik gemaakt van het XMLHttpRequest object. Dit object voorziet in een JavaScript API om http(s) aanvragen te verzenden naar de server en het antwoord te verwerken zonder de nood om pagina’s te herladen. XMLHttpRequest2, de herwerkte versie, introduceert een paar nieuwe mogelijkheden en ook verbeteringen. Deze betekenen het einde voor een paar ingenieuze oplossingen om bijvoorbeeld de voortgang van een upload te tonen en binaire data te verzenden en ontvangen. Bij de implementatie van de applicatie zal zowel gebruik gemaakt worden van AJAX als het WebSocket protocol om gegevens te verzenden naar de server. 1

Web Real-Time Communications


4.1.10

25

CORS ( & JSONP )

CORS, of Cross Origin Resource Sharing, is een vereiste indien we een SaaS applicatie of API willen aanbieden die data moet kunnen verwerken van en/of teruggeven aan een client applicatie. Standaard is het niet toegelaten om bronnen aan te spreken via XHR die zich niet op het zelfde domein bevinden. Requests die gebeuren door de browser naar een ander domein worden geblokkeerd wegens de same origin security policy 1 . CORS definieert een protocol dat toelaat om deze manier van communiceren toe te staan. Bij een cross origin request wordt eerst een OPTIONS aanvraag verstuurd naar de server. Dit is een vraag aan de server welke opties toegelaten zijn, geassocieerd met de aanvrager, zonder dat daarbij effectief een actie wordt ondernomen. 1 OPTIONS * HTTP/1.1 2 Host: localhost

Listing 4.7: HTTP OPTIONS request

De server antwoordt dan op zijn beurt met de toegelaten opties. Deze server kan hierbij zo ge¨ımplementeerd worden dat elke vragende partij toegelaten is of dat er een blacklist of nog veiliger een whitelist wordt toegepast. 1 HTTP/1.1 200 OK 2 Allow: OPTIONS, GET, POST, PUT, DELETE 3 Content-Length: 0

Listing 4.8: HTTP response op OPTIONS request

In het voorgaande voorbeeld geeft de server aan dat enkel de de meest voorkomende acties mogelijk zijn die bijvoorbeeld ge¨ımplementeerd worden in een Rest API. CORS kan vergeleken worden met JSONP, maar dan als een modern alternatief voor het laatste. JSONP ondersteunt enkel de GET methode en CORS laat andere methoden zoals PUT, DELETE en POST toe. De enige vereiste voor CORS is een recente browser, maar obstakels zoals minimaal IE6 als browser zijn ondertussen reeds achterhaald.

1

http://en.wikipedia.org/wiki/Same_origin_policy


4.2 4.2.1

26

JavaScript The good & bad parts

JavaScript, oorspronkelijk ontwikkeld door Netscape, is de voorganger van ECMAScript1 . ECMAScript blijft echter wel over de tong rollen als zijnde JavaScript. Het is een aparte taal die onmogelijk te vergelijken valt met andere klassieke programmeertalen zoals Java of PHP. Enkele concepten zoals closures, promises en global variables zijn aparte eigenschappen, eigen aan de taal. De beperking tot uitvoeren op de clientzijde is ook reeds achterhaald. Hedendaags kan je zeer snel efficiënte servers bouwen met enkel en alleen JavaScript. Het debuggen van mobiele applicaties kan dan weer een obstakel zijn indien je het niet goed weet aan te pakken. Voor meer informatie over specifieke zaken en implementaties in de taal is het aangeraden om het boek “JavaScript: The Good Parts” door te nemen[4]. Momenteel implementeren de meest courante browsers ECMAScript5.x, maar ECMAScript6 is op zijn weg. 4.2.1.1

Remote debugging & logging

Er zijn verschillende opties om een mobiele applicatie te debuggen. De moeilijkheid die hieraan verbonden is, is het debuggen van een mobiele applicatie die gebruikt wordt tijdens beweging, zoals wandelen of reizen met de trein. Hier dient dus een vorm van remote debugging via een draadloze verbinding te gebeuren. Een geschikte tool hiervoor is JSConsole. JSConsole is ontworpen door Remy Sharp en kan door integratie van een code snippet ge¨ınstalleerd worden op de (mobiele) webapplicatie2 : 1 <script src="http://jsconsole.com/remote.js?MYAPPID">

Listing 4.9: JSConsole injectie

Alle console.log commando’s worden vervolgens doorgestuurd naar de servers van JSConsole. Het starten van de logsessie kan door :listen MYAPPID uit te voeren op de commandolijn op http://jsconsole.com. Het is zeer belangrijk te beseffen dat dit een veiligheidsrisico inhoudt. Indien een kwaadwillige gebruiker toegang krijgt tot de logpagina op de JSConsole website kan deze code injecteren en de applicatie overnemen. Zodra de applicatie in productie gaat moet deze plugin dus uitgeschakeld worden[14].

1 2

ECMAScript - http://en.wikipedia.org/wiki/ECMAScript JSConsole - http://jsconsole.com/


27

Anderzijds kunnen we de webapplicatie op een Android toestel debuggen aan het werkstation door deze te verbinden via een USB-kabel. Dit kan zowel met Chrome als Firefox Remote debugging. Firefox remote debugging op Android vereist de platform-tool s, beschikbaar in de ADT1 op het werkstation[13]. Daarnaast is het vereist om USB debugging op het Android toestel in te schakelen. Chrome vereist enkel dit laatste[6]. Het opmerkelijke aan JSConsole is dat deze kan gebruikt worden voor elk type browser op alle soorten toestellen. De Chrome en Firefox remote debugging opties zijn uiteraard beperkt tot deze specifieke browsers. Tenslotte biedt Safari nog een gelijkaardige functionaliteit aan via hun developer tools, maar deze werd niet getest2 . 4.2.1.2

Closures

Het volgende codevoorbeeld wekt mogelijks de illusie dat na 500ms de verschillende auteurs één voor één uitgeprint zullen worden in de console. 1 var auteurs = ["Sam", "Jan", "Pieter", "Karel"]; 2 for(var i in auteurs){ 3 setTimeout(function(){ 4 console.log(auteurs[i]); 5 },500); 6 }

Listing 4.10: Forloop en timeout zonder closure

Het uitprinten gebeurt echter pas na 500ms, nadat de forloop doorlopen is. Deze loop zal in normale gevallen reeds veel sneller dan 500ms voltooid zijn. Hierdoor heeft de variabele i reeds de laatste sleutelwaarde van de reeks aangenomen en zal er vier maal “Karel” uitgeprint worden. Hier komt dan het concept van closures van pas. De variable i, die op dat moment de correcte benodigde waarde heeft, wordt ingesloten in een “sluiting” of closure. Daarbij wordt een aparte scope gecreëerd, waardoor de functie in een afgeschermde omgeving draait. 1 for(var i in auteurs){ 2 (function(i){ // open closure 3 setTimeout(function(){ 4 console.log(auteurs[i]); 5 },500); 6 })(i); // bind variabele i aan de gesloten omgeving 7 }

Listing 4.11: Forloop en timeout met closure 1 2

Android Developer Tools Safari tools: urlhttps://developer.apple.com/safari/tools/


28

Uitvoeren van deze code zal, zoals gewenst, de verschillende auteurs één voor één uitprinten in de console na 500ms. Closures hebben nog meer specifieke toepassingen en eigenschappen zoals automatische garbage collection. Eens de afgesloten omgeving aan zijn einde komt zullen de gebruikte variabelen dus ook verdwijnen uit het geheugen[3]. Closures worden veelvuldig gebruikt bij het verwerken van de gegevens in de API van deze applicatie.

4.2.2

Node.js

Node.js is een asynchroon en event gebaseerd I/O framework met non-blocking I/O eigenschappen. Het draait bovenop de open-source V8 JavaScript engine ontworpen door Google. Het wordt vooral gebruikt om snelle en schaalbare netwerk applicaties op te bouwen. Dit maakt het uitermate geschikt voor data-intensieve (realtime) applicaties die uitvoerbaar zijn op gedistribueerde systemen. In deze masterproef zal Node.js gebruikt worden om een webserver op te zetten die de backend zal aansturen. Vanop deze webserver wordt ook de pluggable code aangeleverd die in de bestaande applicaties kan worden ingeplugd. De Node.js backend zal daarnaast ook dienst doen als Restful API en als WebSocket eindpunt. Dit eindpunt zal samen met de API gebruikt worden voor het opslaan van de gegevens die door de pluggable code worden verzameld op de client. 4.2.2.1

Modules & packages

Node.js levert op zich slechts het basis framework. Voor elke specifieke toepassing zijn er extra vereisten nodig. Deze extra vereisten zijn voor de meeste hedendaagse toepassingen reeds ontwikkeld door de community. Enkele voorbeelden hiervan zijn het Express framework en de CORS module. Deze modules of packages kunnen apart ge¨ınstalleerd worden door de npm1 of aangegeven worden in het package.json bestand in de rootfolder van de applicatie (zie listing 4.12). Bij het gebruik van dit package bestand kunnen de vereiste modules automatisch ge¨ınstalleerd worden. De applicatie weet welke versies hij moet installeren indien deze specifiek aangegeven worden. Het gebruik van een asterisk geeft aan dat de meest recente stabiele versie ge¨ınstalleerd moet worden. Installatie gebeurt door npm install --save uit te voeren in de root-folder van het project. De optie --save zal de huidige versies van de ge¨ınstalleerde packages invullen op de plaats van de asterisken. 1

Node Package Manager


1 { 2 3 4 5 6 7 8 9 10 11 }

29

"name": "Masterproef Sam Vloeberghs Server", "version": "v1.0.1", "dependencies": { "express": "4.0.0", "jade": "*", "mongoose": "*", "cors": "*", "ws": "*" }

Listing 4.12: Node.js package.json bestand

4.2.2.2

Eenvoudige webserver met Express

Express is een webapplicatie framework voor Node.js. Het laat toe om zeer snel met minimale code een werkende webserver op te starten voor zowel single-page als multi-page webapplicaties. De term single-page duidt aan dat alle inhoud en functionaliteit wordt afgeleverd aan de gebruiker vanop 1 enkele webpagina, meestal de indexpagina. Door gebruik van JavaScript en AJAX wordt dan functionaliteit toegevoegd of weer verwijderd naargelang de acties van de gebruiker. Dit geeft de gebruiker meer het gevoel van een vlotte desktop applicatie en minimaliseert de laadtijden op zowel de client- als serverzijde. Multi-page duidt op de klassieke manier van websites opbouwen. Een eenvoudige webserver opstarten kan met volgende zes lijnen code. De server zal luisteren op poort 8080. 1 2 3 4 5 6

var express = require(’express’); var app = express(); app.get(’/’, function(req, res){ res.send(’Hello World’); }); app.listen(8080);

Listing 4.13: Simpele webserver met Node.js en Express


4.3

30

Databanken

Bij de keuze van het databanksysteem voor deze masterproef werd rekening gehouden met de verschillende mogelijkheden in zowel het SQL als NoSQL kamp. Hedendaags zijn er zoveel verschillende mogelijkheden dat er al snel een keuze moest gemaakt worden tussen de te bespreken mogelijkheden. Wat volgt is een overzicht van enkele (graph)document database systemen en dit geeft meteen ook een verklaring waarom de klassieke SQL databanksystemen geen goede keuze zijn. Een document georiënteerd databank management systeem (DODBMS) is een databanksysteem dat het modelleren en opslaan van gegevens onder de vorm van documenten toelaat. Documenten kunnen aanzien worden als semi-gestructureerde data, wat impliceert dat een document niet beperkt is tot het schema. Dit laat toe om meer gevarieerde documenten met verschillende elementen onder 1 noemer op te slaan. Een relationeel databank management systeem (RDBMS) is gebaseerd op het relationele model en is nog steeds het meest verspreide. In een RDBMS worden gegevens bewaard in gerelateerde tabellen. Een relationele databank is dus een verzameling van één of meerdere tabellen met kolommen en rijen. Hierbij kunnen er relaties bestaan tussen tabellen op basis van bepaalde kolomwaarden in de verschillende tabellen. De belangrijkste concepten bij een RDBMS zijn de garantie op relationele integriteit, normalisatie en soms ook denormalisatie om datatoegang efficiënter te maken. RDBMS’en worden typisch aangesproken met SQL. Het grootste voordeel van een RDBMS is de lage instapdrempel om gegevens in te voeren, aan te passen en op te halen. Document georiënteerde databank systemen vormen één van de meest voorkomende categorieën van de NoSQL beweging. Ten opzichte van RDBMS’en wordt de data verzameld in documenten tegenover gestructureerde tabellen. De documenten worden typisch opgebouwd in de meest voorkomende encoderingen of formaten zoals XML en JSON. De meeste documenten in een collectie zijn gelijkend maar kunnen zeer sterk afwijken. Ze zijn dus niet altijd beperkt tot een bepaald schema en kunnen andere elementen bevatten. Het codevoorbeeld in listing 4.14 van documenten in JSON illustreert een personen collectie. Dirk heeft in dit geval een huisdier en Jan een kind. Beide zaken zijn document specifiek en ten opzicht van RDBMS’en zijn deze velden niet leeg maar gewoon onbestaande. Deze aanpak heeft als voordeel dat nieuwe data gemakkelijk kan worden toegevoegd zonder elke bestaande record in de databank aan te passen naar een nieuwe structuur.


1 [ 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 ]

31

{ naam : adres : huisdieren : { type: naam: } ]

"Dirk Vloeberghs" "Mechelstraat" [ "Hond" "Boo"

}, { naam adres kinderen {

: "Jan Vloeberghs" : "Kapelweg 30" : [ naam: "Esme Vloeberghs" leeftijd: 1

} ] }

Listing 4.14: Rij van JSON documenten in een collectie

Rekening houdend met het doel van de applicatie leek het ook interessant om een graphdatabase te gebruiken. De punten van geografische locaties kunnen idealiter gekoppeld worden via een verbinding die, bijvoorbeeld, de reistijd tussen de 2 geografische locaties beschrijft. OrientDB is een combinatie van zowel een graaf- als document-georiënteerde databank en combineert dus beide benaderingen. MongoDB is aan een enorme opmars bezig en heeft nog maar net een grote financieringsronde achter de rug1 . Het lijkt erop dat MongoDB de standaard zal worden in document georiënteerde databank systemen. Dit kan het best vergeleken worden met het veelvuldig gebruik van bijvoorbeeld Oracle’s MySQL in RDBMS’en. Elke aanpak, met zowel RDBMS’en als DOBMS’en, heeft nog steeds zijn ideale toepassing in bepaalde usecases, dus het is belangrijk te weten welke waar optimaal gebruikt kan worden. Indien we met zeer gestructureerde data werken, zoals bijvoorbeeld een website met een nieuwssysteem, is het nog steeds aangeraden een RDBMS te gebruiken. Bij elke entry in de blog is er een hoge waarschijnlijkheid dat elke voorziene kolom in de tabel zal opgevuld worden. 1

MongoDB becomes king of NYC startups - http://www.bloomberg.com/news/2013-10-04/ mongodb-becomes-king-of-nyc-startups-with-1-2-billion-valuation.html


4.3.1

32

OrientDB

OrientDB implementeert het DODBMS principe maar voegt er nog een extra functionaliteit aan toe onder de vorm van grafen. In principe kan men dus spreken over een GDODBMS of een Graaf Document DataBase Management Systeem. De ontwikkelaars van het systeem claimen dat het ongelooflijk snel is, maar dit werd niet bevestigd door eigen testen. De ontwikkelaar, Luca Garulli, implementeerde zijn eigen algoritme door het samenvoegen van zowel het RedBlack Tree en B+ Tree algoritme, het MultiValued RedBlack Tree algoritme. Het bedrijf claimt wederom dat MVRB-Trees maar de helft van het vereisten geheugen gebruiken vergeleken met standaard RB trees, en dit zonder de snelheid te verliezen. Bij het effectief uitproberen van OrientDB door middel van de JavaScript API bleek dat deze nog zeer immatuur en beperkt was. Enkel de meest voorkomende functionaliteiten werden reeds ge¨ımplementeerd. Ook de grafische interface werkte niet naar behoren en bij het invoeren van records in de webadmin interface bleek dat er waarden ontbraken. Bij verder onderzoek viel wel op dat de Java uitwerking veel verder zit, wat logisch lijkt aangezien OrientDB in Java is ontwikkeld. Het is zeker een technologie om in het oog te houden. Andere volwassen open-source implementaties zijn bijvoorbeeld Neo4J1 of ArangoDB2 . Beide hebben een zeer actieve development community rond de JavaScript API.

4.3.2

MongoDB

De naam MongoDB komt van “humongous” wat vrij vertaald staat voor “immens”, gigantisch” of “enorm groot”. Het is een DODBMS speciaal ontworpen anticiperend op het feit dat de wereldwijde dataopslag steeds uitgebreider en meer ongestructureerd wordt. MongoDB gebruikt op JSON gebaseerde documenten die niet gebonden zijn aan de structuur van de omvattende collectie. Zoals eerder verduidelijkt (zie listing 4.14) kan er dus worden afgeweken van het schema. Deze flexibiliteit maakt het gemakkelijker om documenten te mappen naar een entiteit of object en omgekeerd. 4.3.2.1

Document structuur

Bij het ontwerpen van data modellen in MongoDB applicaties moet er rekening gehouden worden met de structuur van de originele documenten en hoe de relaties tussen de data worden voorgesteld in de applicatie. Relaties tussen data kunnen op 2 manieren worden voorgesteld. Door referenties te gebruiken of door andere documenten in te sluiten. 1 2

Neo4J JavaScript website - http://www.neo4j.org/develop/javascript ArangoDB website - http://www.arangodb.org/


33

Referenties 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

// Gebruiker { _id : , naam : "Dirk Vloeberghs" email : "[email protected]" } // Klant { _id : , user_id : , aankopen : [{ .. }] } // Leverancier { _id : , user_id : bedrijf : "Universiteit Gent" leveringen : [{ .. }] }

Listing 4.15: Relationele aanpak

Zoals wel duidelijk is heeft het klant object een relatie met het gebruiker-object en bepaalt het zo de naam van de klant. Dit is een meer genormaliseerde aanpak zoals het veel toegepast wordt bij RDBMS’en. De gebruiker is ook een leverancier. Dit leverancier object heeft opnieuw een relatie met het gebruiker object en definieert enkele nieuwe attributen. Ingesloten documenten Gerelateerde data kan ingesloten worden in één enkele structuur of document. Dit is een meer gedenormaliseerde aanpak en zorgt ervoor dat applicaties minder queries en updates nodig hebben om veelvoorkomende operaties te voltooien. Toegepast op het voorbeeld in listing 4.15 geeft dit de aangegeven structuur in listing 4.16. Het aanspreken, toevoegen en bewerken van deze documenten in een MongoDB databank zal uitgebreid aan bod komen in de technische uitwerking van deze masterproef.


34

1 // Gebruiker 2 { 3 _id : , 4 naam : "Dirk Vloeberghs", 5 email : "[email protected]", 6 klant : 7 { 8 aankopen : [{ ..}] 9 }, 10 leverancier : 11 { 12 bedrijf : "Universiteit Gent", 13 leveringen : [{..}] 14 } 15 }

Listing 4.16: Ingesloten aanpak in een documentstructuur

4.3.2.2

Replicatie

De termen schaalbaarheid en beschikbaarheid zijn hedendaags niet meer weg te denken bij het in productie nemen van een geavanceerde webapplicatie. Replicatie is het proces waarbij de data wordt gesynchroniseerd over verschillende servers. Dit zorgt voor redundantie en verhoogt of verzekert de gegevens-beschikbaarheid in geval van bijvoorbeeld een onverwachte piek in website bezoekers. En indien er één databank instantie wegvalt kan een andere instantie het overnemen. Een zeer uitgebreide uitleg is terug te vinden in de documentatie van MongoDB[11]. 4.3.2.3

Grafische interfaces

MongoDB kan in eerste instantie beheerd worden door middel van een console interface die op de server is op te roepen met het mongo commando. Deze shell heeft echter maar weinig visuele effecten. Analyses en overzichten van data zijn sneller te vatten indien er enige vorm van opmaak en visualisatie aan te pas komt. Robomongo Robomongo1 is een cross-platform open source MongoDB administratie applicatie, beschikbaar voor Linux, Windows en MacOSX. Door het gebruik van dezelfde JavaScript engine, die instaat voor de werking van de mongo shell, kan je de kennis van beide dus perfect interoperabel gebruiken. 1

Robomongo website - http://robomongo.org/


35

Figuur 4.5: Robomongo interface: oplijsting gebruikers en detail

Robomongo werd tijdens de ontwikkeling van het project als voldoende geschikt bevonden, al bevindt het zich momenteel officieel nog maar in een vroege beta release. Bijkomende features en requests worden bijgehouden in een opmerkelijke issuetracker 1 . Indien je sneller een bepaalde feature wil laten implementeren of een issue wil laten verhelpen kan je deze prioriteit geven door voldoende te doneren. UMongo UMongo2 is zeer gelijkend op Robomongo qua mogelijkheden. Je kan connecteren naar zowel een enkele server als naar een gehele replica set. Als uiteindelijke keuze ging de voorkeur naar Robomongo wegens zijn mooiere interface, aangezien functionaliteit geen obstakel was.

1 2

Vote for the feature - http://robomongo.org/backlog UMongo website - http://edgytech.com/umongo/

Hoofdstuk 5

Applicatie 5.1

Inleiding

Met al de voorgenoemde technologieën is het mogelijk om een generieke functionaliteit op te stellen die toelaat om een uitgebreide set gegevens van gebruikers en hun handelingen te verzamelen en analyseren, en dit voor verschillende applicaties. Deze verzameling aan gegevens wordt opgebouwd terwijl de gebruikers een mobiele webapplicatie gebruiken. We gaan uit van een bestaande toeristische gids die wil starten met deze dataverzameling. Hiervoor werd eerst een basis webapplicatie gebouwd die als usecase dient. De applicatie injecteert dan de trackingcode die data zal verzamelen en doorsturen naar de cloud. In de cloud worden deze gegevens dan verder verwerkt en gestructureerd bewaard. Een controlepaneel voorziet een interface om de gegevens indien nodig te beheren en aan te passen. Elke applicatie die gebruik zal maken van de trackingcode moet samen met enkele parameters in het systeem worden ingegeven. Daarnaast kan een beheerder de verzamelde gegevens, zoals gebruikers en locaties, beheren a.d.h.v. de gekende CRUD methodologie1 . De beheerders van de toeristische gids kunnen achteraf zelf een applicatie bouwen op basis van een API. Deze applicatie kan de gewenste statistische analyses maken en visualiseren. Als voorbeeld werd een pagina gemaakt die enkele interessante analyses toont van de voorbeeld applicatie.

1

Create Read Update Delete

36

Hoofdstuk 5. Applicatie

5.2 5.2.1

37

Modellen Gebruikte technologie¨ en

De semi-gestructureerde verzamelde data wordt verwerkt en gestructureerd bewaard in een MongoDB databank. Voor het uitwerken van de modellen werd de object modeling tool Mongoose gebruikt. Mongoose levert een straight-forward, schema-gebaseerde manier om data te modelleren. Het heeft enkele handige eigenschappen zoals ingebouwde type casting, validatie en query-opmaak. Mongoose zelf verzorgt ook de connectie naar de MongoDB databank[9]. Mongoose kan net zoals alle anders Node.js plugins ingeladen worden via het packages.json bestand (zie listing 4.12)

5.2.2

Applicatie

Het basismodel voor de tracking functionaliteit is een “applicatie”. In de context van het voorbeeld betreft dit bijvoorbeeld de toegelaten toeristische gidsen. Deze applicaties worden uniek ge¨ıdentificeerd door een aantal kenmerken, aangegeven in het definiërende schema: 1 var ApplicatieSchema = new Schema({ 2 i : { // unieke identificatie 3 type: String, index : { unique: true } 4 }, 5 n : String, // applicatie naam 6 do : String, // applicatie domain, 7 c : { // applicatie centrum 8 la : Number, lo : Number 9 }, 10 m_a : Number, // minimale geldige nauwkeurigheid 11 /* generieke kenmerken */ 12 c_d : { // applicatie aanmaak datum 13 type: Date, default : Date.now 14 }, 15 de : { // applicatie verwijderd 16 type: Boolean, default : false 17 }, 18 d_d : Date // application verwijderd datum 19 });

Listing 5.1: Applicatie schemamodel

Het kenmerk i wordt naast de, door MongoDB, automatisch gegenereerde id gebruikt om een korte unieke identificatie te bieden voor de in te voegen trackingcode. De kenmerken n en do definiëren respectievelijk de naam en het domein van de applicatie. Het kenmerk m a duidt specifiek voor de applicatie aan wat de minimale nauwkeurigheid voor een geografische


38

locatie-update moet zijn opdat deze als geldig beschouwd kan worden. Elk kenmerk wordt verder aangeduid met zijn type en een eventuele default waarde. 5.2.2.1

Generieke kenmerken

Elk model heeft naast zijn eigen specifieke kenmerken nog een drietal generieke kenmerken. Het kenmerk c d geeft aan wanneer een object van het schema aangemaakt is. De kenmerken de en d d geven aan of het object al dan niet verwijderd is en wanneer dit gebeurde. Dit levert een prullenbak functionaliteit waardoor gegevens nooit echt verloren zijn. Op basis van een eenvoudige query kunnen deze objecten indien gewenst verwijderd (of hersteld) worden zodra men tot de vaststelling komt dat het huidige beeld een accurate weergave is van de gewenste data. Deze kenmerken worden verder niet meer aangegeven in de andere modellen.

5.2.3

Gebruikers

Zodra er een eerste locatie-update wordt waargenomen wordt de gebruiker bewaard in de databank. Deze gebruikers worden naast de gebruikelijke id in de databank ook uniek ge¨ıdentificeerd a.d.h.v. een GUID1 . Elke gebruiker heeft nog een aantal andere identificerende kenmerken, aangegeven in het definiërende schema in listing 5.2. 1 var GebruikerSchema = new Schema({ 2 GUID: { // unieke identificatie 3 type : String, index : { unique: true } 4 }, 5 i : { // referentie naar Applicatie schema object 6 type : Schema.Types.ObjectId, ref : ’Applicatie’ 7 }, 8 a_s : { // speficieke gebruiker applicatie instellingen 9 b_o : Boolean, // batterij optimalisatie 10 h_a : Boolean, // hoge nauwkeurigheid ( accuracy ) 11 w_s : Boolean // websockets 12 }, 13 a : String, // useragent 14 s : { // start datum 15 type : Date, default : new Date(), index: true 16 }, 17 d : { // dimensies van het gebruikersscherm 18 w : Number, // breedte ( width ) 19 h : Number // hoogte ( height ) 20 } 21 });

Listing 5.2: Gebruiker schemamodel 1

Global Unique ID


39

Het kenmerk GUID wordt op de client gegenereerd en hierdoor is het mogelijk dat er een collision optreedt met een reeds bestaande waarde in de databank. De GUID is een samengestelde string van 32 karakters met voor elk karakter 36 mogelijkheden. De kans is dus miniem en de controle op een mogelijke collision wordt buiten een unieke index op het kenmerk niet verder opgevangen. Het i kenmerk is een relationele verwijzing naar de bijhorende applicatie. Het kenmerkobject a s bevat de gebruiker specifieke instellingen voor de tracking software. Of hij bijvoorbeeld al dan niet een batterij geoptimaliseerde strategie gebruikte. De verdere details van dit kenmerkobject worden later duidelijk. Het a kenmerk bevat de useragent string van de gebruiker. Aan de hand van dit kenmerk kan uitgemaakt worden welke browser er gebruikt werd. Het s kenmerk bevat de starttijd van de gebruiker in de browser toen hij de pagina laadde. Tot slot worden ook de dimensies van de viewport op het mobiele toestel bijgehouden in het d kenmerk.

5.2.4

Locaties

De locatie-updates die de gebruiker genereert met zijn smartphone zijn de zaken waar het allemaal om draait in deze trackingsoftware. Daarnaast worden per locatie ook de gebruikershandelingen bewaard. Zo kan men op elke specifieke locatie weten wat de gebruiker deed op de applicatie. Op basis van deze handelingen kan men dan analyses opstellen om het algemene gebruikersgedrag over verschillende locaties heen te bestuderen. Net zoals gebruikers en locaties hebben locatie objecten in de databank een unieke id. Daarnaast hebben ze geen nood aan een extra unieke identificatie. Per locatie wordt de huidige pagina bijgehouden in c p. Dit is de pagina waarop de locatie-update werd waargenomen. Uiteraard wordt ook de meest relevante geolocatie informatie bijgehouden in het loc kenmerk object. Dit object bevat naast de latitude en longitude nog extra waardevolle informatie, zoals de nauwkeurigheid in meter (ac), de hoogte (al), de hoogte nauwkeurigheid (aa), de snelheid (sp) en het tijdstip (ts) van de locatie-update. Per locatie worden de handelingen geregistreerd. Deze handelingen omvatten zowel klikken op een link (li), als klikken op het gehele document (cl) en het maken van swipes om te scrollen doorheen de webpagina (sw). De op te slaan details van deze reeks aan handelingen worden later duidelijk gemaakt. Het is vooral belangrijk op te merken dat al deze handelingen worden gebundeld per locatie tot er zich opnieuw een locatie-update voordoet.


40

1 var LocatieSchema = new Schema({ 2 c_p : String, // huidige pagina 3 loc : { // geolocatie specifieke info 4 la : Number, lo : Number, ac : Number, 5 al : Number, aa : Number, he : Number, 6 sp : Number, ts : { type : Date, default : new Date() } 7 }, 8 li : [{ // gebruikte links 9 p : String, // huidige pagina 10 ta : String, // doel van de link 11 ti : String // titel van de link 12 }], 13 cl : [{ // klikken op het document 14 p : String, // huidige pagina 15 el : String, // naam van het element 16 x : Number, y : Number // x en y positie 17 }], 18 sw : [{ // swipes op het document 19 s : { // start van een swipe 20 x : Number, y : Number 21 }, 22 e : { // einde van een swipe ( x , y ) 23 x : Number, y : Number 24 }, 25 p : String, // huidige pagina 26 els : [{ // zichtbare elementen na swipe 27 ... 28 }], 29 di : String, // richting ( direction ) 30 }] 31 });

Listing 5.3: Vereenvoudigd locatie schemamodel

Aangezien MongoDB een documentopslag databank is, worden alle sleutels van de waarden in een document steeds per document bewaard. Het is daarom aangewezen om voor de sleutelwaarden steeds korte benamingen te gebruiken. Dit zorgt voor een kleinere belasting per document maar kan ook zorgen voor onleesbaarheid. Dit kan dan snel opgelost worden door het opstellen van een voldoende beschrijvende documentatie[10].


5.3

41

RESTful API

De API is de backbone van de trackingsoftware. Alle data behandelingen gebeuren via de specifieke eindpunten voor zowel applicaties, gebruiker en locaties. De ongestructureerde data, verzameld door de trackingcode, wordt verwerkt via het data eindpunt.

5.3.1

Gebruikte technologie¨ en

De API werd volledig opgebouwd in de Node.js backend met behulp van het Express framework. Per eindpunt in de API dient een route opgesteld te worden met de beschikbare HTTP methoden zoals GET, POST, PUT of DELETE. In de API werd geopteerd om voor elke methode naar een bestaand eindpunt een geldig en uniform resultaat, onder de vorm van een JSON object, terug te geven maar dan met een bijhorende HTTP statuscode. Wanneer de aangesproken methode toegelaten is wordt het resultaat teruggestuurd met statuscode 200 (OK). Indien niet toegelaten wordt een foutboodschap teruggestuurd met statuscode 405 (methode niet toegelaten). Bij elke aanvraag naar de API wordt variabele input , die door de aanvrager wordt meegegeven, gecontroleerd. Deze controle kan in een gebruikersomgeving zoals een webapplicatie programmatorisch gebeuren door validatie toe te passen op de client. Aanvragen zelf kunnen echter ook programmatorisch gebeuren dus een ultieme controle op de backend is een belangrijke vereiste. Deze controle in de API gebeurt door middel van het package validate.js. 5.3.1.1

Validatie van gegevens

validate.js biedt mogelijkheden om de data op verschillende eigenschappen, zoals lengte en type, te controleren. Een belangrijke opmerking hierbij is dat elke controle op basis van strings gebeurt en niet de primitieve types zoals integers of floats. Andere objecten, zoals Date instanties, worden dus ook gecontroleerd op basis van hun toString() resultaat. Controle of een datum zich tussen een bepaald bereik bevindt vereist dan een aparte validatie functie die de isAfter() en isBefore() controles verenigt1 . Bij elke actie die de databank manipuleert worden de verstrekte gegevens gevalideerd. Om dit te verwezenlijken moet voor elk model een lijst van constraints worden opgebouwd. Deze vorm van validatie op basis van constraints moet bij elke input toegepast worden om inconsistenties in de databank te vermijden. Het kan ook dienst doen als een beperkte vorm van authenticatie. In het voorbeeld in listing 5.4 wordt het minimale nauwkeurigheid kenmerk van een applicatie gecontroleerd op zowel aanwezigheid als vorm (numerieke waarde). Deze constraint dient dan opgeroepen te worden op een object dat de te controleren kenmerken bevat. 1

Validator.js - https://www.npmjs.org/package/validator


42

1 var applicatie_constraints = { m_a : { 2 presence: { 3 message: "ˆNauwkeurigheid moet ingevoerd worden" 4 }, 5 numericality: { 6 message: "ˆNauwkeurigheid moet een numerieke waarde bevatten" 7 } 8 }};

Listing 5.4: Voorbeeld constraint voor validatie input

5.3.1.2

Ingebouwde en specifiek aangepaste schema-methoden

Om de manipulatie van de beschikbare gegevens in de databank te vereenvoudigen biedt Mongoose de mogelijkheid om schema specifieke methoden aan te maken. Deze kunnen naast de bestaande methoden zoals Model.findAll() en Model.findById() handig ge¨ımplementeerd worden om bijvoorbeeld op een bereik te filteren. 1 GebruikerSchema.static(’findAllByApplicationIdAndRange’, 2 function(app_id, start, einde, callback){ 3 var query = { 4 i : app_id, de : false, // niet verwijderde objecten 5 s : { // start datum bereik 6 "$gte" : new Date(start.toISOString()), 7 "$lte" : new Date(einde.toISOString()) 8 } 9 }; 10 return this.find(query, ’_id i s GUID’, callback); 11 });

Listing 5.5: Voorbeeld specifieke schema methode

Deze methode findAllByApplicationIdAndRange, specifiek gedefinieerd voor het gebruikersschema, geeft een lijst van gebruikers terug die tussen een bepaald bereik van data startten met het gebruik van de applicatie. Zoals reeds meermaals aangegeven worden enkel niet verwijderde objecten opgevraagd. Dit verklaart het kenmerk de:false in de query in listing 5.5. Meer informatie over deze methoden zijn terug te vinden in de Mongoose documentatie[9].


5.3.2

43

Het data eindpunt

Het data eindpunt fungeert als de vergaarbak van alle semi-gestructureerde data, gegenereerd door handelingen van de gebruiker, verzameld door de trackingcode. Deze data heeft een ruwe vorm, opgesteld om zo efficiënt mogelijk over het mobiele netwerk naar de server gestuurd te worden. Hoe deze data verzameld, bewerkt en structureel bewaard wordt, wordt in detail uitgelegd bij de bespreking van de injectiecode (zie 5.5).

5.3.3

Applicaties

Het applicatie eindpunt in de API omvat de typische CRUD methoden. Zowel een lijst van applicaties als de detailgegevens van een specifieke applicatie kunnen worden opgehaald. Zoals reeds vermeld bij de generieke kenmerken worden enkel de niet verwijderde documenten opgehaald (zie 5.2.2.1). Hierop moet dus systematisch gefilterd worden bij het ophalen van alle gegevens, zowel applicaties als gebruikers en locaties. 5.3.3.1

Beschikbare methoden & eindpunten

• api/applications - GET / POST Het eindpunt zonder parameters laat toe om een lijst van applicaties op te halen via de GET methode en een nieuwe applicatie toe te voegen aan de databank via POST. • api/applications/:id - GET / UPDATE / DELETE De placeholder :id wordt automatisch vervangen door de overeenkomstige waarde. Deze waarde wordt gebruikt om te filteren op het identificerende kenmerk id. Naargelang de methode zal het overeenkomstige object worden aangepast of verwijderd. Ongeacht de gekozen methode wordt het betreffende object steeds als resultaat teruggegeven. • api/applications/:id/users - GET Verder gaande op het vorige spreekt dit specifieke eindpunt het gebruikersmodel aan en wordt een lijst van gebruikers verbonden aan de applicatie teruggegeven. • api/applications/:id/users/:start/:einde - GET Dit eindpunt geeft de mogelijkheid tot filteren van gebruikers op basis van hun creatietijdstip. Dit datapunt wordt vooral gebruikt bij het uitwerken van de statistische overzichten. • api/applications/:id/consulted-pages/:start/:einde - GET Dit laatste eindput geeft de mogelijkheid tot filteren van de geraadpleegde pagina’s in de applicatie, op basis van het creatietijdstip van het omvattende locatie object. Dit datapunt wordt alsook gebruikt bij het uitwerken van de statistische overzichten.


5.3.4

44

Gebruikers

Gebruikers hebben net zoals applicaties een gelijkaardige API interface. De gelijkende methodes en eindpunten worden daarom niet verder uitgediept. 5.3.4.1

Beschikbare methoden & eindpunten

• api/users/:id - GET / UPDATE / DELETE Een specifieke gebruiker ophalen, aanpassen of verwijderen. • api/users/:id/locations - GET Net zoals per specifieke applicatie een lijst van gebruikers opgehaald kan worden, kan men per specifieke gebruiker een lijst van locaties ophalen. Deze methode spreekt daarvoor het locatiemodel aan. Bij het ophalen van gerelateerde documenten zijn er wel verschillende implementatiekeuzes mogelijk. Indien men alle locaties van een gebruiker ophaalt kan de grootte van het antwoord door de server grote proporties aannemen. Het is daarom soms beter om enkel de nodige locatie kenmerken terug te geven, zoals het unieke identificerende id, en dan verdere dataselectie te doen op basis van een specifieke locatie. Dit betekent een snellere response en beperkt ook de grootte van de antwoorden door de server.

5.3.5

Locaties

Locaties hebben net zoals gebruikers en applicaties een gelijkaardige API interface. Deze methodes en eindpunten worden daarom niet verder uitgediept.

5.4

Controlepaneel

Het controlepaneel biedt in eerste instantie een interface om de applicaties op een gebruikersvriendelijke manier te beheren. Per applicatie kunnen alle gebruikers gefilterd worden. Daarnaast is het per gebruiker mogelijk om de gemeten locaties en bijhorende handelingen te visualiseren en analyseren. Voor zowel de gebruiker als een individuele locatie is het mogelijk om deze te bewerken of verwijderen. Tenslotte is er de mogelijkheid om een documentatie van de API te raadplegen. Dit werd niet uitgebreid uitgewerkt. Een voorbeeld ter verdere uitwerking wordt ge¨ıllustreerd in de documentatie voor het basispunt.


5.4.1

45

Gebruikte technologie¨ en

Het gehele controlepaneel is responsief opgebouwd. Om het ontwikkelingsproces te versnellen werd gebruik gemaakt van de uitgebreide Bootstrap1 en jQuery2 bibliotheken. Bootstrap wordt voornamelijk gebruikt om de layout te verzorgen, al heeft het ook enkele elementen die op jQuery steunen, zoals de modal windows en tabpagina’s.

5.4.2

Applicaties beheren

Applicaties beheren kan via een typische interface die alle applicaties oplijst. Een modal window wordt gebruikt om de applicaties zowel toe te voegen als te bewerken. Vooraleer een applicatie definitief verwijderd wordt, wordt er een finale bevestiging gevraagd aan de gebruiker.

Figuur 5.1: Applicaties beheren

Bij het toevoegen en aanpassen van een applicatie wordt de data via een AJAX-callback, met de gepaste HTTP methode, verzonden naar de API. De API voert de validatie uit en stuurt de eventuele foutboodschappen terug. De boodschappen worden dan getoond aan de beheerder zodat deze meteen een gepaste actie kan ondernemen. 5.4.2.1

Trackingcode genereren

De beheerder van het controlepaneel kan per applicatie kiezen welke gegevens hij wil bijhouden en welke strategieën hij wil toepassen via de trackingcode composer, indien deze beschikbaar zijn voor de gebruiker. De trackingcode wordt dan automatisch gegenereerd en kan via het tekstvak gekopieerd en vervolgens ge¨ njecteerd worden in de betreffende applicatie.

1 2

Bootstrap - http://getbootstrap.com jQuery - http://jquery.org


46

Het is hierbij ook mogelijk in te stellen of de beheerder de applicatie wil debuggen en of er een locatie-update functie kan worden toegekend. Indien de code wordt ge¨ınjecteerd is er namelijk reeds een functionaliteit die de locatie (al dan niet periodiek of volgens een bepaalde strategie) opvraagt. Deze kan dan ook direct in de applicatie worden aangesproken, maar is niet verplicht te gebruiken.

Figuur 5.2: Trackingcode genereren per applicatie

5.4.3

Gebruikers en locaties beheren

Naast het filteren van de gebruikers op basis van een bepaalde applicatie is het mogelijk deze gebruikers te bewerken via een modal window (zie fig. 5.3). Per gebruiker is het namelijk mogelijk dat er een aparte strategie werd toegepast. Dit kan gebeuren indien men op bepaalde tijdstippen in de leeftijd van de applicatie de gebruikte trackingcode heeft aangepast. Dit heeft bijvoorbeeld invloed op de strategie inzake de batterij optimalisatie, het opvragen van een hoge nauwkeurigheid bij het updaten van de locatie en het al dan niet gebruik van websockets indien mogelijk. De GUID kan aangepast worden indien men dit nodig acht.


47

Figuur 5.3: Gebruikers beheren

Per gebruiker kan men doorklikken naar een detailweergave van zijn gemeten locaties. Deze weergave toont ook meer details over de gebruiker zelf, zoals bijvoorbeeld de starttijd van zijn sessie, de dimensies van het scherm en de gebruikte browser, onder de vorm van zijn useragent. Door te klikken op een locatie in het overzicht op het kaartje krijgt men de locatiegegevens en de bijhorende handelingen te zien, die op deze locatie gebeurden. Hier is het nu ook mogelijk deze locatie te verwijderen indien gewenst.

Figuur 5.4: Locaties van een gebruiker beheren


5.5 5.5.1

48

Implementatie trackingcode Trackingcode

De JavaScript tracking- of injectiecode werd opgebouwd om zo weinig mogelijk invloed te hebben op de werking van de applicatie zelf. Het is onvermijdelijk dat er een beperkte vorm van performantie-degradatie optreedt. Dit is mogelijk doordat er bijvoorbeeld, eventlisteners aan elementen worden gebonden en berekeningen gebeuren, naast de code die eigen is aan de applicatie. De code die ge¨ınjecteerd moet worden kan worden opgebouwd aan de hand van de trackingcode composer (zie fig. 5.2). Elke functionaliteit die geselecteerd wordt breidt de code uit met bepaalde tags. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

var _msv = _msv || []; _msv[’_identifier’] = ’MSV-1’; _msv[’_links’] = true; _msv[’_heatmap’] = true; _msv[’_swipes’] = true; _msv[’_battery’] = true; _msv[’_high_acc’] = true; _msv[’_websocket’] = true; _msv[’_debug’] = true; // deel 2 _msv[’_l_u_f’] = updateLocation; (function() { var msv = document.createElement(’script’); msv.type = ’text/javascript’; msv.async = true; msv.src = ’http://backend:8080/msv/msv.js’; var m = document.getElementsByTagName(’script’)[0]; m.parentNode.insertBefore(msv, m); })();

Listing 5.6: Voorbeeld trackingcode

In het bovenstaande voorbeeld worden eerst de gewenste instellingen gemaakt. Als eerste wordt de unique identifier aangegeven die de te tracken applicatie bepaalt. Vervolgens worden zowel de links, heatmap en swipes tracking functionaliteiten ingeschakeld. Om een bepaalde functionaliteit uit te schakelen is het voldoende om de instelling weg te laten. Er wordt indien mogelijk gebruik gemaakt van batterij optimalisatie en men vraagt steeds de meest nauwkeurige locatie op van de gebruiker. Indien de browser het toelaat zal de data via het WebSocket protocol naar de server verstuurd worden. Het tweede grote deel van de trackingcode zorgt voor de injectie van de gevraagde functionaliteit en het aangeven van een externe locatie-update functie. Zoals reeds aangegeven (zie 5.4.2.1) kan de omvattende applicatie gebruik maken van de locatie update functionaliteiten van de trackingcode indien gewenst.


5.5.2

49

Locatie update strategie

Het tracken van de gebruikers is gebaseerd op hun locatie. Maar hoe wordt deze bepaald, hoe frequent zijn de updates en hoe nauwkeurig kunnen ze zijn? De antwoorden op deze vragen laten toe om verschillende strategiën toe te passen in de trackingsoftware. 5.5.2.1

Locatiebepaling

Locatiebepaling gebeurt door middel van de HTML5 Geolocation API. Deze API is agnostisch en implementeert de beschikbare methoden op het gebruikte toestel (zie 4.1.5). Er zijn 2 mogelijkheden om de locatie van een gebruiker op te halen, gedefinieerd door een paar opties zoals de nauwkeurigheid en lifetime/ timeout van de locatie. De eerste mogelijkheid is een eenmalige bepaling van de locatie en de andere een locatie-getriggerde bepaling. Zodra de sensor waarneemt dat de gebruiker zich verplaatst heeft zal deze een event oproepen. 5.5.2.2

Nauwkeurigheid & frequentie

De nauwkeurigheid en frequentie van de locatie-updates hangen af van de hardware in verschillende smartphones. Via de HTML5 Geolocation API heeft men ook de mogelijkheid om softwarematig een lage of hoge nauwkeurigheid op te vragen. Testen wijzen uit dat deze software instelling niet altijd even betrouwbaar of bruikbaar is. De manier waarop een locatiebepaling uitgevoerd wordt kan namelijk ingesteld worden op de smartphone zelf. Android, bijvoorbeeld, geeft in nieuwere versies de mogelijkheid om te kiezen tussen drie instellingen: 1. high accuracy : alle sensoren inclusief Wi-Fi en mobiele netwerken bepalen de locatie 2. battery saving : de locatie wordt bepaald op basis van Wi-Fi en de mobiele netwerken 3. device only : het toestel gebruikt enkel de GPS-sensor om de locatie te bepalen De HTML5 instelling kan theoretisch bekeken dus beschouwd worden als een instelling op het tweede niveau met mogelijks zeer weinig invloed op het uiteindelijke resultaat. De meetresultaten in tabel 5.1 en tabel 5.2 tonen een weergave van het aantal gemeten locaties (n) per toestel met de bijhorende gemiddelde nauwkeurigheid (straal in meter) per locatie, op basis van de lage en hoge nauwkeurigheidsinstelling. Voor de high-end toestellen vertonen deze resultaten een marginaal en willekeurig verschil indien we overschakelen van een lage naar een hoge nauwkeurigheid. Het verschil in aantal locaties is te wijten aan het transportmiddel gebruikt in het testscenario. Door het gebruik van een fiets was het niet mogelijk steeds de exacte route te volgen en binnen dezelfde tijd de route te voltooien.


Toestel iPhone 4S LG Nexus 5 HTC Desire X

50

n

straal (m)

983

6,837

2174

10,537

LG Nexus 5

91

68,540

HTC Desire X

Tabel 5.1: Metingen lage nauwkeurigheidsinstelling HTML5 Geolocation

Toestel iPhone 4S

n

straal (m)

792

10,537

1744

13,971

952

26,82

Tabel 5.2: Metingen hoge nauwkeurigheidsinstelling HTML5 Geolocation

Wat wel opvalt is dat de HTC Desire X een zeer groot verschil toont bij het aantal locaties (factor 10) en een toename in nauwkeurigheid (250%). Bij deze smartphone had de softwarematige instelling dus wel een zeer gunstig effect op zowel het aantal gemeten locaties als de nauwkeurigheid per locatie. Deze resultaten visualiseren op een kaartje geeft een beter beeld van de soms grote verschillen die de trackingsoftware onnauwkeurig en dus zelfs onbruikbaar kunnen maken. Op basis van de resultaten bij de HTC Desire X met lage nauwkeurigheid (zie fig. 5.8) kan geen waardevolle analyse worden opgesteld over de gebruiker zijn locatie en route. Dit is wel het geval bij de resultaten van de high-end smartphone LG Nexus 5.

Figuur 5.5: LG Nexus 5: hoge nauwkeurigheid

Figuur 5.6: LG Nexus 5: lage nauwkeurigheid

Figuur 5.7: HTC Desire X: hoge nauwkeurigheid Figuur 5.8: HTC Desire X: lage nauwkeurigheid

Hoofdstuk 5. Applicatie 5.5.2.3

51

Batterij optimalisatie

Het opvragen van GPS locaties op een smartphone kan zeer batterij-intensief zijn. Hoe frequenter deze locatie-updates zich voordoen hoe sneller de batterij kan leeglopen. Volgens de testen met een high-end smartphone kan een automatisch opgeroepen locatieupdate zich reeds voordoen bij een verplaatsing van 1 meter. Indien de batterij volledig opgeladen is is het geen probleem om een locatie-update zo frequent te verwerken. Zodra de batterij een kritisch niveau bereikt kan er best een andere strategie worden toegepast die, bijvoorbeeld, periodiek een locatie-update gaat opvragen. De HTML5 Battery status API (zie 4.1.4) kan hiervoor handig aangewend worden. Door het koppelen van de eventlisteners kan er programmatorisch gecontroleerd worden of de batterij van het toestel zich op een kritisch niveau bevindt en al dan niet opgeladen wordt. Als kritisch niveau werd in deze masterproef 25% gebruikt maar deze drempel kan ook zeer snel aangepast worden naar een andere waarde. Wanneer het kritisch niveau bereikt is wordt er omgeschakeld van de automatisch getriggerde locatie-update naar een periodieke locatie-update. Deze verdere periodieke updates kunnen op verschillende manieren en strategieën afgehandeld worden: • Men blijft periodiek updaten op basis van hetzelfde interval totdat de batterij leeg is. • Bij het verder dalen van het batterijniveau kan geopteerd worden om de frequentie ofwel dynamisch te laten toenemen of te laten afnemen. Beide dynamische strategieën hebben hun voor- en nadelen. Indien men de frequentie laat toenemen worden meer locatie-updates doorgestuurd bij het naderen van een lege batterij. Dit zorgt voor een verzekerde data synchronisatie tussen de client en server vlak voor het uitvallen van het toestel. Door de toenemende frequentie zal de batterij echter steeds sneller leeglopen. Bij het afnemen van de frequentie zal de batterij steeds minder belast worden maar zullen er ook minder locatie-updates worden doorgestuurd. De afstand tussen de locaties zal steeds toenemen waardoor deze naar het einde toe minder waarde hebben. De Battery status API is ten tijde van dit schrijven alleen beschikbaar in Firefox. Om deze reden werden de strategieën niet uitgebreid uitgewerkt. Zodra het toestel de kritische waarde bereikt heeft zal de locatie periodiek ge¨ update worden a.d.h.v. een vooraf bepaald en instelbaar interval. 5.5.2.4

Online & offline detectie

De verzamelde gegevens worden normaliter per locatie-update doorgestuurd naar de server. Tijdens het mobiel gebruik van een webapplicatie is het echter steeds mogelijk dat de gegevensverbinding wegvalt. Indien de applicatie offline is worden de locatie-updates en bijhorende


52

handelingen bewaard in de localStorage (zie 4.1.6.2) van de webpagina. De connectiviteit van de applicatie kan gecontroleerd worden a.d.h.v. van de navigator.onLine waarde in JavaScript (zie 4.1.6.3). Zodra de applicatie detecteert dat er weer connectiviteit is worden de verzamelde gegevens gesynchroniseerd naar de server.

5.5.3

WebSocket en AJAX

Zodra de applicatie voor de eerste maal wordt opgestart is er nog niet meteen een locatie update gemeten. Bij het eerste bezoek dient de gebruiker akkoord te gaan met het feit dat zijn locatie gemeten wordt. De eerste locatie die wordt bewaard is daarom een dummy locatie die er voor zorgt dat de eerste handelingen kunnen worden gekoppeld, nog voor de gebruiker zijn toestemming heeft gegeven. Zodra een eerste geldige locatie wordt gemeten worden de handelingen die hiervoor gebeurden vanuit de dummy locatie opnieuw gekoppeld aan de eerste geldige locatie. Zodra er een tweede locatie wordt gemeten stuurt de trackingcode de eerste door naar de server. Het doorsturen van deze data kan via verschillende kanalen. De applicatie kan hierbij gebruik maken van zowel het WebSocket als AJAX protocol of een combinatie van beide. De keuze van het protocol ligt in eerste instantie bij de beheerder van de applicatie zodra hij de trackingcode ter injectie genereert (zie 5.4.2.1). Hij kan de bewuste keuze maken om het WebSocket protocol te gebruiken indien dit beschikbaar is in de client browser. Indien deze functionaliteit (nog) niet beschikbaar is zal er steeds beroep gedaan worden op AJAX. Zodra de gebruiker de website afsluit is het mogelijk dat er zich nog bruikbare gegevens in het geheugen van de browser bevinden. Net voor de sessie gesloten wordt moet de laatste data nog naar de server verstuurd worden. Dit kan op basis van het onbeforeunload en onunload event van het window object. 1 window.onbeforeunload = function() { 2 log("closing app: perform final persist"); 3 d_o.persist(true); 4 };

Listing 5.7: Laatste data doorsturen bij sluiten applicatie

De true parameter geeft aan de persist() methode van het data object aan dat het om het sluiten van de pagina gaat. Hierdoor zal de methode standaard gebruik maken van AJAX. Het gebruik van het WebSocket protocol is hier niet mogelijk omdat deze sockets geheel asynchroon werken. Hierdoor wordt de data mogelijks niet snel genoeg doorgestuurd zodra de pagina sluit. Een AJAX-call gebeurt steeds voor de pagina definitief sluit en zal de gegevensaflevering verzekeren.


5.5.4

53

Te verzamelen handelingen

De locatie-update vormt een container object om de handelingen van de gebruiker te verzamelen. Deze handelingen zijn dus direct gekoppeld aan de huidige locatie van de gebruiker. Enkele mogelijke te verzamelen handelingen op een mobiel toestel zijn ogenblikkelijke aanrakingen of touches op het gehele document en hyperlinks en daarnaast ook langdurige aanrakingen zoals swipes of pinches. Deze handelingen kunnen geanalyseerd worden en geven een uitgebreid beeld over het gedrag van de gebruiker over de gehele applicatie heen. 5.5.4.1

Aanrakingen op de pagina en links

Door het meten van aanrakingen op de gehele pagina is het mogelijk een heatmap op te stellen van de applicatie. Deze heatmap duidt aan welke delen van de pagina’s populair zijn en de aandacht trekken. Het bijhouden van gebruikte hyperlinks levert daarnaast ook inzichten over welke elementen het meest gebruikt worden om doorheen de applicatie te navigeren. Het verwerken van deze handelingen kan door een listener te koppelen aan het clickevent op het gehele document van de webapplicatie. Op mobiele toestellen wordt bij een enkele aanraking van het scherm ook een clickevent afgevuurd. Bij het afhandelen van dit event gebeurt er een controle of de klik/aanraking al dan niet op een hyperlink plaats vond. Per actie worden enkele elementen opgevraagd zoals het huidige pad van de applicatie en het tijdstip. Indien de handeling zich afspeelde op een willekeurige plaats op het document worden ook de naam van het element en de tweedimensionale x en y coördinaten verwerkt. In het andere geval wordt de titel en het doel van de hyperlink verwerkt. 5.5.4.2

Swipes en getoonde elementen

Na het aflopen van een swipe is het mogelijk dat er belangrijke elementen in de viewport van de gebruiker tevoorschijn zijn gekomen. Per swipe worden de starten eindcoördinaten bepaald. A.d.h.v. deze punten wordt bepaald of de handeling wel degelijk een swipe betreft. Dit wordt gecontroleerd door de afstand tussen het start en eindpunt te vergelijken en rekening te houden met een bepaalde threshold. Als de beweging slechts een afstand maakt kleiner dan deze threshold wordt deze niet beschouwd als een swipe. Een selectie van vrijgekomen elementen, geselecteerd op basis van element- of klassennaam, wordt samen met de swipe actie bewaard en gekoppeld aan het omvattende locatieobject. Deze elementen worden bepaald na een timeout, waarvan de duurtijd kan worden aangepast. Deze timeout is essentieel aangezien de swipe een scroll kan veroorzaken die pas stopt na een variabel aantal seconden. Gedurende deze tijd wordt de verzending van data naar de server


54

geblokkeerd zodat de getoonde elementen aan de juiste locatie-update gekoppeld kunnen worden. Het is namelijk mogelijk dat net tijdens deze timeout zich een nieuwe locatie-update voordoet waardoor de vrijgekomen elementen aan de verkeerde locatie worden gekoppeld. Het detecteren van een swipe is geen gemakkelijke opdracht. De events die gebruikt worden om deze handeling waar te nemen zijn niet uniform ge¨ımplementeerd door de verschillende browsers. Bij testen bleek dat de verschillende events zoals handleTouchCancel en handleTouchEnd in Chrome Mobile niet consequent werden opgeroepen zoals dit bijvoorbeeld bij Firefox Mobile wel het geval is. De problemen die hierbij komen kijken zijn in vele gevallen te wijten aan implementaties door verschillende interpretaties van de specificatie[2, 18]. Het afhandelen van deze cross-browser issues kunnen zeer gedetailleerd beschreven worden maar zijn buiten de scope van dit onderzoek.

5.6

Statistisch overzicht

De statistische resultaten en analyses die inzichten verschaffen over het gebruik van de mobiele webapplicaties zijn de belangrijkste redenen waarom deze trackingcode ontwikkeld werd. Op basis van deze analyses kan een ontwikkelaar en/of content-provider de betreffende applicatie verder optimaliseren.

Figuur 5.9: Statistisch overzicht per gekozen periode

In het statistisch overzicht is het mogelijk de gewenste periode aan te passen. Per gekozen periode wordt het aantal gebruikers berekend. Dit aantal dient als basis voor heel wat interes-


55

sante waarden. Vanuit het aantal gebruikers is het mogelijk om bijvoorbeeld het gemiddeld aantal locaties en gemiddelde tijd per locatie en gebruiker te berekenen.

5.6.1

Data aggregatie

Elke applicatie heeft een minimale nauwkeurigheid voor zijn gemeten locaties. Op basis van deze minimale waarde kan berekend worden hoeveel van de locatie-updates waardevol zijn en kunnen ingezet worden voor bruikbare analyses. Een toeristische gids heeft typisch enkele trekpleisters. Deze trekpleisters hebben een locatie en een minimale straal waarin een locatie als “in de buurt” wordt beschouwd. Aan de gemeten locaties die zich in de buurt van een trekpleister bevinden werd de openstaande pagina op het moment van de locatie-update gekoppeld. Via de bewaarde handelingen kan men dus nagaan welke informatie op de pagina’s in de applicatie op welke locatie gebruikt en bekeken werd. In het statistisch overzicht wordt voor de geselecteerde periode zowel de totale frequentie van de bezochte pagina’s als de gemiddelde frequentie per gebruiker weergegeven.

Figuur 5.10: Overzicht van bezochte pagina’s per trekpleister

5.6.1.1

Berekening afstand tussen geografische punten

Berekenen van de afstand tussen twee geografische punten kan op verschillende manieren. Een vrij accurate methode is de Haversine afstandsformule die de afstand berekent over een sfeer, op basis van de straal van de bolvormige aarde. Formule 5.1 berekent de tweede macht van de helft van de koordlengte tussen de twee geografische punten. De geografische punten worden beschreven door hun latitude(ϕ) en longitude(λ). De berekende waarde c uit de formule 5.2 stelt de radiale hoekafstand voor tussen de twee punten, uitgedrukt in meter. Tenslotte wordt deze hoekafstand in formule 5.3 vermenigvuldigd met de straal van de aarde in meter. Het eindresultaat d stelt de afstand voor tussen de 2 punten in meter.


56

a = sin2 (∆ϕ/2) + cos(ϕ1 ) · cos(ϕ2 ) · sin2 (∆λ/2) √ p c = 2 · atan2( a, (a − 1))

(5.2)

d = R·c

(5.3)

(5.1)

Een belangrijke opmerking bij deze berekening is dat deze maar accuraat is voor korte afstanden. Bij langere afstanden zijn er meer vervormingen mogelijk in het landschap door bijvoorbeeld heuvels. Deze hebben een niet te verwaarlozen invloed op de berekende afstand[15]. Daarnaast is het ook een relatief zware berekening om uit te voeren in de browser indien er zich veel afstandsvergelijkingen voordoen, wat essentieel is in de uitgewerkte applicatie. Indien de afstand zeer kort is kan men afstappen van de Haversine formule en Pythagoras toepassen op afstandsgetrouwe cilinderprojectie. Dit is een wereldkaartprojectie die leidt tot een kaart met een rechthoekig gradennet. Kortom: de ellipsvormige omtrek rond de aardbol wordt afgevlakt op een kaartoppervlak[19]. Deze formule vermindert het aantal benodigde goniometrische uitdrukkingen en machtsverheffingen maar leidt wel tot een lagere nauwkeurigheid van de berekende afstand. Het voordeel van deze formule is dat deze veel sneller uitvoerbaar is door een processor dan de Haversine formule. Indien een client veel van deze berekeningen moet uitvoeren is het aangeraden de uiteindelijke performantie op zowel desktop als mobiele browsers te analyseren. Deze analyses leiden dan tot argumenten om een optimale strategie te implementeren in specifieke gevallen1 . Bij het berekenen van de afstand tussen een gemeten geografische locatie en de locatie van een toeristische treikpleiser werd de accurate Haversine methode uitgewerkt. Een uitgebreid overzicht van alternatieven en implementaties is terug te vinden op het Internet[15].

1

JSPerf Haversine benchmarks - http://jsperf.com/haversine-salvador/8

Hoofdstuk 6

Conclusies en perspectieven 6.1

Toekomst van HTML5

Heel wat deelspecificaties van HTML5 zijn reeds bruikbaar indien we steeds zorgen voor fallbacks om de ontbrekende functionaliteiten in bepaalde browsers op te vangen. Net om die reden is het moeilijk om een cross-browser implementatie te maken die zowel uniform als optimaal werkt. Een bijkomend probleem is dat sommige browsers, zoals oudere versies van Internet Explorer op oude systemen zoals Windows XP, niet automatisch up-to-date worden gebracht. Dit is een gekend probleem op de desktopmarkt dat zich verder zal vertalen naar de smartphone markt. Oudere toestellen zullen op een bepaald moment geen updates meer krijgen wegens beperkingen in de hardware specificaties, maar kunnen nog enige tijd in gebruik blijven. De levensduur van deze toestellen valt daarentegen niet te vergelijken met deze van vaste toestellen zoals een PC of server. Het volledig uitrollen van de HTML5-standaard zal bijgevolg nog zeker enkele jaren duren. Zodra alles ge¨ımplementeerd is, zoals de specificatie het voorschrijft, zal dit vele nieuwe mogelijkheden brengen om het world wide web beter te maken.

6.2

Mogelijke uitbreidingen applicatie

De gebouwde applicatie werkt maar kan verder worden uitgebreid. Er zijn verschillende toevoegingen en uitbreidingen mogelijk die hieronder kort en bondig worden opgelijst. Deze lijst is een aanzet en vormt geen beperking. • Authenticatie op het controlepaneel: Momenteel gebeurt er geen controle op toegang tot het controlepaneel. Dit kan uitgebreid ge¨ımplementeerd worden. Hierbij is het mogelijk dat elke beheerder verschillende applicaties toevoegt en daardoor enkel

57

Hoofdstuk 6. Conclusies en perspectieven

58

zijn eigen applicaties, gebruikers en bijhorende locaties kan beheren. Een superadmin heeft dan toegang tot alle applicaties over alle beheerders heen. Dankzij het onderscheiden van de verschillende beheerders kan bijvoorbeeld bijgehouden worden welke gebruiker een applicatie verwijderde uit het systeem. Dit hangt samen met de reeds ge¨ımplementeerde prullenbak functionaliteit. • API uitbreiden: De toegang tot gegevens via de API kan uitgebreid worden met het oog op performantie, vooral bij het ophalen van statistische gegevens. De soms complexe berekeningen die hierbij komen kijken kunnen op de server uitgevoerd worden waardoor de belasting op de client verminderd wordt. Een bijkomend positief gevolg is dat er mogelijk minder gegevens naar de client moeten verzonden worden. • Statistieken uitbreiden: De statistieken van een applicatie kunnen verder uitgebreid worden met relevante informatie zoals een flow van gebruikers doorheen de applicatie. De uitgewerkte statistische pagina is ook niet voorzien op een groot aantal gebruikers of handelingen per locatie. In het overzicht en via de API kan dit op basis van paginatie en limitatie veel efficiënter gemaakt worden. • Collisions bij het generen van de GUID voor een gebruiker vermijden: Door een extra controle in te bouwen in de API kan een terugkoppeling naar de client voorzien worden die een melding geeft dat een automatisch gegenereerde GUID reeds bestaat. De trackingcode kan op basis van deze melding besluiten om een nieuwe GUID te genereren. • De verzamelde handelingen en gegevens van de gebruiker prioriteren: Prioritisatie van de gegevens kan een cruciale rol spelen bij het bouwen van een energie-bewuste mobiele applicatie. Zodra het toestel zich op een batterij-kritisch niveau bevindt, kan er besloten worden enkel de meest belangrijke en relevante zaken te synchroniseren met de server.

6.3

Conclusies

Uit dit werk kunnen we concluderen dat het mogelijk is om met de nieuwe HTML5-standaard een locatie gebaseerde monitoring functionaliteit op te bouwen. Een belangrijk punt hierbij is dat bepaalde deelspecificaties van de HTML5- & JavaScript-standaard, zoals de Battery status API, verre van uniform ge¨ımplementeerd zijn in de verschillende mobiele browsers. Bij het gebruik van de Geolocation API bleek dat het gebruikte toestel (en de instellingen) toch een noemenswaardige invloed heeft op de nauwkeurigheid van een gemeten locatie. Een algemene conclusie die hieruit voortvloeit is dat het aangeraden is om high-end smartphones of tablets te gebruiken indien men wil rekenen op een hoge nauwkeurigheid en deze nauwkeurigheid ook zo in te stellen op de toestellen.

Hoofdstuk 6. Conclusies en perspectieven

59

Sommige ontbrekende deelspecificaties kan men opvangen door het gebruik van polyfills. Helaas is dit technisch niet altijd mogelijk, zoals bij de Battery status API. Het is namelijk onmogelijk het batterijniveau of de oplaadstatus op een andere manier in een browser op te vragen. Zodra deze specifieke API verder uitrolt in alle mobiele browsers is het mogelijk een uitgebreide energie-bewuste en energie-efficiënte strategie voor mobiele applicaties verder uit te werken. Het verzamelen van (semi-)ongestructureerde gegevens was de aanzet om de NoSQL databank MongoDB te implementeren. Door dit te combineren met Node.js en de bijhorende modules bleek dat het efficiënt gebruik van JavaScript niet beperkt is tot de client maar dat het ook zorgde voor de opbouw van relatief simpele programmacode op de back-end. Op basis van deze conclusies, de geslaagde testen en de functionerende ge¨ımplementeerde programmacode kan teruggeblikt worden op een geslaagde masterproef.

Lijst van broncodes 1.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 5.1 5.2 5.3 5.4 5.5 5.6 5.7

Google Analytics injectie code . . . . . . . . . . . Batterij niveau en oplaadstatus opvragen . . . . localStorage benaderen . . . . . . . . . . . . . . . Online/offline events afhandelen en extra controle Application cache : Manifest voorbeeld . . . . . . HTTP request voor upgrade . . . . . . . . . . . . HTTP upgrade message . . . . . . . . . . . . . . HTTP OPTIONS request . . . . . . . . . . . . . HTTP response op OPTIONS request . . . . . . JSConsole injectie . . . . . . . . . . . . . . . . . Forloop en timeout zonder closure . . . . . . . . Forloop en timeout met closure . . . . . . . . . . Node.js package.json bestand . . . . . . . . . . . Simpele webserver met Node.js en Express . . . . Rij van JSON documenten in een collectie . . . . Relationele aanpak . . . . . . . . . . . . . . . . . Ingesloten aanpak in een documentstructuur . . . Applicatie schemamodel . . . . . . . . . . . . . . Gebruiker schemamodel . . . . . . . . . . . . . . Vereenvoudigd locatie schemamodel . . . . . . . Voorbeeld constraint voor validatie input . . . . Voorbeeld specifieke schema methode . . . . . . . Voorbeeld trackingcode . . . . . . . . . . . . . . . Laatste data doorsturen bij sluiten applicatie . .

60

. . . . . . op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internetconnectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

2 17 19 20 22 23 24 25 25 26 27 27 29 29 31 33 34 37 38 40 42 42 48 52

Lijst van figuren 1.1

Developer Tools - Woopra callbacks over netwerk . . . . . . . . . . . . . . . .

5

2.1 2.2

De drie V’s: Volume, Velocity & Variety . . . . . . . . . . . . . . . . . . . . Horizontaal vs. verticaal schalen . . . . . . . . . . . . . . . . . . . . . . . . .

8 9

4.1 4.2 4.3 4.4 4.5

Het HTML5 logo . . . . . . . . . . . . . . . . . . . . . . <select> gebruikt native selectie functionaliteit . . . . . . Locatiebepaling op basis van Wi-Fi, GPS of GSM-netwerk Het WebSocket protocol1 . . . . . . . . . . . . . . . . . . Robomongo interface: oplijsting gebruikers en detail . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

15 17 18 23 35

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10

Applicaties beheren . . . . . . . . . . . . . . . . . Trackingcode genereren per applicatie . . . . . . Gebruikers beheren . . . . . . . . . . . . . . . . . Locaties van een gebruiker beheren . . . . . . . . LG Nexus 5: hoge nauwkeurigheid . . . . . . . . LG Nexus 5: lage nauwkeurigheid . . . . . . . . . HTC Desire X: hoge nauwkeurigheid . . . . . . . HTC Desire X: lage nauwkeurigheid . . . . . . . Statistisch overzicht per gekozen periode . . . . Overzicht van bezochte pagina’s per trekpleister

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

45 46 47 47 50 50 50 50 54 55

61

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Lijst van tabellen 1.1 1.2

Verdeling desktop browsers1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verdeling mobile & tablet browsers2 . . . . . . . . . . . . . . . . . . . . . . .

4 4

5.1 5.2

Metingen lage nauwkeurigheidsinstelling HTML5 Geolocation . . . . . . . . . Metingen hoge nauwkeurigheidsinstelling HTML5 Geolocation . . . . . . . . .

50 50

62

Bibliografie [1]

Mark A. Beyer en Douglas Laney. “The Importance of ’Big Data’: A Definition”. In: (2012).

[2]

Rick Beyers. Touch event behavior details across browsers. url: https : / / docs . google.com/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/ edit.

[3]

Richard Cornford. Maart. 2004. url: http : / / jibbering . com / faq / notes / closures/.

[4]

Douglas Crockford. JavaScript: The Good Parts. 2008.

[5]

The Economist. Data, data everywhere. 2010. url: http://www.economist.com/ node/15557443?story_id=15557443.

[6]

Google. Remote Debugging Chrome on Android. 2014. url: https://developer. chrome.com/devtools/docs/remote-debugging.

[7]

Seth Grimes. “Big Data: Avoid ’Wanna V’ Confusion”. In: (2013).

[8]

Douglas Laney. “3D Data Management: Controlling Data Volume, Velocity and Variety”. In: (2001).

[9]

LearnBoost. Mongoose - Elegant MongoDB object modeling for Node.js. 2011. url: http://mongoosejs.com/docs/guide.html.

[10]

Christopher Maier. The Importance of MongoDB Key Names. 2011. url: http:// christophermaier.name/blog/2011/05/22/MongoDB-key-names.

[11]

MongoDB Inc. MongoDB Replication Documentation. 2014. url: http : / / docs . mongodb.org/manual/core/replication-introduction/#replicationin-mongodb.

[12]

Mozilla Developer Network. Navigator.onLine - Web API interfaces. url: https : / / developer . mozilla . org / en - US / docs / Web / API / NavigatorOnLine . onLine.

[13]

Mozilla Developer Network. Remote Debugging - Developer Tools. 2013. url: https: //developer.mozilla.org/nl/docs/Tools/Remote_Debugging. 63

Bibliografie

64

[14]

Remy Sharp. JSConsole - Remote Debugging. 2011. url: http://jsconsole.com/ remote-debugging.html.

[15]

Chris Veness. Calculate distance, bearing and more between Latitude/Longitude points. 2010. url: http://www.movable-type.co.uk/scripts/latlong.html.

[16]

W3C. Geolocation API Specificatie. url: http://www.w3.org/TR/geolocationAPI/#introduction.

[17]

W3C. HTML5 Specification - Web Storage. url: http : / / dev . w3 . org / html5 / webstorage/#disk-space.

[18]

W3C. W3C Touch events recommendation. url: http://www.w3.org/TR/touchevents/.

[19]

Wikipedia. Equirectangular projection. 2014. url: http://en.wikipedia.org/ wiki/Equirectangular_projection.

[20]

Wikipedia. Large Hadron Collider. 2014. url: http://en.wikipedia.org/wiki/ Large_Hadron_Collider.

HTML5-gebaseerde monitoring voor digitale toeristische gidsen

Recommend Documents