HTML5-gebaseerde monitoring voor digitale toeristische gidsen

Transcriptie

1 owered by TCPDF ( Academiejaar Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg 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

2 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

3 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

4 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

5 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

6 Inhoudsopgave 1 Inleiding & situering Locatie gebaseerde monitoring Digitale toeristische gidsen Gerelateerde bestaande monitoring software Google Analytics Statcounter Woopra Andere Privacy Big Data Inleiding & definitie Volume Velocity Variety Veracity Validity Volatility Toepassingen & voorbeelden Architectuur Client Pluggable code Server API Controlepaneel Databank Technologieën HTML Historiek Compatibiliteit Browser support Battery status API Geolocation Offline & Storage v

7 Inhoudsopgave vi WebSocket WebRTC AJAX CORS ( & JSONP ) JavaScript The good & bad parts Node.js Databanken OrientDB MongoDB Applicatie Inleiding Modellen Gebruikte technologieën Applicatie Gebruikers Locaties RESTful API Gebruikte technologieën Het data eindpunt Applicaties Gebruikers Locaties Controlepaneel Gebruikte technologieën Applicaties beheren Gebruikers en locaties beheren Implementatie trackingcode Trackingcode Locatie update strategie WebSocket en AJAX Te verzamelen handelingen Statistisch overzicht Data aggregatie Conclusies en perspectieven Toekomst van HTML Mogelijke uitbreidingen applicatie Conclusies Lijst van broncodes 60 Lijst van figuren 61 Lijst van tabellen 62

8 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

9 Hoofdstuk 1. Inleiding & situering 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 (function(i,s,o,g,r,a,m){ 2 i[ GoogleAnalyticsObject ]=r;i[r]=i[r] function(){ 3 (i[r].q=i[r].q []).push(arguments)},i[r].l=1*new Date(); 4 a=s.createelement(o),m=s.getelementsbytagname(o)[0];a.async=1; 5 a.src=g;m.parentnode.insertbefore(a,m) 6 })(window,document, script, // ga ); 7 8 ga( create, UA-xxxx, example.com ); 9 ga( send, pageview ); Listing 1.1: Google Analytics injectie code

10 Hoofdstuk 1. Inleiding & situering 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 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 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 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 marktonderzoek 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

11 Hoofdstuk 1. Inleiding & situering 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 Feb Chrome 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% Tabel 1.1: Verdeling desktop browsers 1 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 Feb Android 21,88% 24,39% iphone 16,65% 16,73% Safari 16,71% 13,43% Chrome 1,02% 11,51% Opera 15,59% 11,13% UC Browser 6,23% 9,14% Nokia 8,14% 4,52% BlackBerry 3,71% 1,85% IEMobile 0,6% 1,77% Andere 11,1% 5,52% Tabel 1.2: Verdeling mobile & tablet browsers 2 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 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 marktonderzoek

12 Hoofdstuk 1. Inleiding & situering 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 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: Hosted - SaaS Clicktale - Webtrends - Mint Installatie vereist op server of hybride Piwik - Splunk -

13 Hoofdstuk 1. Inleiding & situering 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.

14 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

15 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] 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.

16 Hoofdstuk 2. Big Data 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 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.

17 Hoofdstuk 2. Big Data 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-data 1 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 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 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

18 Hoofdstuk 2. Big Data 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 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].

19 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 SaaS 1 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 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

20 Hoofdstuk 3. Architectuur 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 API 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 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 CMS 2 of CMF 3 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 2 Content Management System 3 Content Management Framework

21 Hoofdstuk 4 Technologieën 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 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 WHATWG 1 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 W3C 2 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 Web Hypertext Application Technology Working Group World Wide Web Consortium

22 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 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.

23 Hoofdstuk 4. Technologieën 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 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 website 2 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 Layout-engines: 2 Can I Use Can I Use input/datetime fields

24 Hoofdstuk 4. Technologieën 17 Figuur 4.2: <select> gebruikt native selectie functionaliteit 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 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 * " %"); 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); } Listing 4.1: Batterij niveau en oplaadstatus opvragen

25 Hoofdstuk 4. Technologieën 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 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 in 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:

26 Hoofdstuk 4. Technologieën 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 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 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 function getobjectfromstorage(key){ 2 return (!localstorage[key] localstorage[key] === "") 3? {} : localstorage[key]; 4 } 5 function setstorage(data, key){ 6 localstorage[key] = JSON.stringify(data); 7 } 8 9 var data = { "foo": "bar" }; 10 setstorage(data,"key"); 11 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 API 1. Deze API is buitenom de scope van deze masterproef en zal dan ook niet verder worden besproken. 1 HTML5 File API -

27 Hoofdstuk 4. Technologieën 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 Mini 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 function offlinelistener(e){ 2 application["online"] = false; 3 } 4 function onlinelistener(e){ 5 application["online"] = true; 6 persist_local_data(); 7 } 8 9 window.addeventlistener("offline", checkonline, false); 10 window.addeventlistener("_offline", offlinelistener, false); 11 window.addeventlistener("online", checkonline, false); 12 window.addeventlistener("_online", onlinelistener, false); function checkonline() { 15 if (navigator.online){ 16 var i = new Image(); 17 i.onerror = function() { fireevent("_offline", document, {}); }; 18 i.onload = function() { fireevent("_online", document, {}); }; 19 i.src = " 20 } 21 else fireevent("_offline", document, {}); 22 } 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 -

28 Hoofdstuk 4. Technologieën 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 SQL 1. 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 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 - HTML5-Cross-Browser-Polyfills#indexeddb

29 Hoofdstuk 4. Technologieën 22 Kort voorbeeld 1 CACHE MANIFEST 2 # v index.html 4 style.css 5 image1.png 6 # Load from network 7 NETWORK: 8 network.html 9 # This is a comment 10 FALLBACK: 11 / 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 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 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.

30 Hoofdstuk 4. Technologieën 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 clients 1. 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á de initiële verbinding door de client. Figuur 4.4: Het WebSocket protocol 2 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 GET ws://localhost:8080/?encoding=text HTTP/1.1 2 Origin: 3 Cookie: utma=99as 4 Connection: Upgrade 5 Host: localhost:80 6 Sec-WebSocket-Key: ROqsefa/ezfoetod== 7 Upgrade: websocket 8 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)

31 Hoofdstuk 4. Technologieën 24 1 HTTP/ WebSocket Protocol Handshake 2 Date: Fri, 10 April :23:53 GMT 3 Connection: Upgrade 4 Server: API Server 5 Upgrade: WebSocket 6 Access-Control-Allow-Origin: 7 Access-Control-Allow-Headers: content-type 8 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 WebRTC WebRTC 1 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 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

32 Hoofdstuk 4. Technologieën 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/ 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

33 Hoofdstuk 4. Technologieën JavaScript The good & bad parts JavaScript, oorspronkelijk ontwikkeld door Netscape, is de voorganger van ECMAScript 1. 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 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) webapplicatie 2 : 1 <script src=" 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 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 ECMAScript JSConsole -

34 Hoofdstuk 4. Technologieën 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 ADT 1 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 getest 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 Android Developer Tools 2 Safari tools: urlhttps://developer.apple.com/safari/tools/

35 Hoofdstuk 4. Technologieën 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 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 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 npm 1 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

36 Hoofdstuk 4. Technologieën 29 1 { 2 "name": "Masterproef Sam Vloeberghs Server", 3 "version": "v1.0.1", 4 "dependencies": { 5 "express": "4.0.0", 6 "jade": "*", 7 "mongoose": "*", 8 "cors": "*", 9 "ws": "*" 10 } 11 } Listing 4.12: Node.js package.json bestand 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 var express = require( express ); 2 var app = express(); 3 app.get( /, function(req, res){ 4 res.send( Hello World ); 5 }); 6 app.listen(8080); Listing 4.13: Simpele webserver met Node.js en Express

37 Hoofdstuk 4. Technologieën 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.

38 Hoofdstuk 4. Technologieën 31 1 [ 2 { 3 naam : "Dirk Vloeberghs" 4 adres : "Mechelstraat" 5 huisdieren : [ 6 { 7 type: "Hond" 8 naam: "Boo" 9 } 10 ] 11 }, 12 { 13 naam : "Jan Vloeberghs" 14 adres : "Kapelweg 30" 15 kinderen : [ 16 { 17 naam: "Esme Vloeberghs" 18 leeftijd: 1 19 } 20 ] 21 } 22 ] 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 rug 1. 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 - mongodb-becomes-king-of-nyc-startups-with-1-2-billion-valuation.html

39 Hoofdstuk 4. Technologieën 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 Neo4J 1 of ArangoDB 2. Beide hebben een zeer actieve development community rond de JavaScript API 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 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 Neo4J JavaScript website ArangoDB website -

40 Hoofdstuk 4. Technologieën 33 Referenties 1 // Gebruiker 2 { 3 _id : <ObjectID1>, 4 naam : "Dirk Vloeberghs" 5 "dirk.vloeberghs@gmail.com" 6 } 7 // Klant 8 { 9 _id : <ObjectID2>, 10 user_id : <ObjectID1>, 11 aankopen : [{.. }] 12 } 13 // Leverancier 14 { 15 _id : <ObjectID3>, 16 user_id : <ObjectID1> 17 bedrijf : "Universiteit Gent" 18 leveringen : [{.. }] 19 } 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 Het aanspreken, toevoegen en bewerken van deze documenten in een MongoDB databank zal uitgebreid aan bod komen in de technische uitwerking van deze masterproef.

41 Hoofdstuk 4. Technologieën 34 1 // Gebruiker 2 { 3 _id : <ObjectID1>, 4 naam : "Dirk Vloeberghs", 5 "dirk.vloeberghs@gmail.com", 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 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] 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 Robomongo 1 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 -

42 Hoofdstuk 4. Technologieën 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 UMongo 2 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 Vote for the feature UMongo website -

43 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 methodologie 1. 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

44 Hoofdstuk 5. Applicatie Modellen Gebruikte technologieën 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) 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

45 Hoofdstuk 5. Applicatie 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 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 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 GUID 1. Elke gebruiker heeft nog een aantal andere identificerende kenmerken, aangegeven in het definiërende schema in listing 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

46 Hoofdstuk 5. Applicatie 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 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.

47 Hoofdstuk 5. Applicatie 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 }], 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].

48 Hoofdstuk 5. Applicatie 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 Gebruikte technologieën 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 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 verenigt 1. 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 -

49 Hoofdstuk 5. Applicatie 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 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].

50 Hoofdstuk 5. Applicatie 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) 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 ). Hierop moet dus systematisch gefilterd worden bij het ophalen van alle gegevens, zowel applicaties als gebruikers en locaties 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.

51 Hoofdstuk 5. Applicatie Gebruikers Gebruikers hebben net zoals applicaties een gelijkaardige API interface. De gelijkende methodes en eindpunten worden daarom niet verder uitgediept 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 Locaties Locaties hebben net zoals gebruikers en applicaties een gelijkaardige API interface. methodes en eindpunten worden daarom niet verder uitgediept. Deze 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.

52 Hoofdstuk 5. Applicatie Gebruikte technologieën Het gehele controlepaneel is responsief opgebouwd. Om het ontwikkelingsproces te versnellen werd gebruik gemaakt van de uitgebreide Bootstrap 1 en jquery 2 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 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 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 Bootstrap jquery -

53 Hoofdstuk 5. Applicatie 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 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.

54 Hoofdstuk 5. Applicatie 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

55 Hoofdstuk 5. Applicatie 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 var _msv = _msv []; 2 _msv[ _identifier ] = MSV-1 ; 3 _msv[ _links ] = true; _msv[ _heatmap ] = true; _msv[ _swipes ] = true; 4 _msv[ _battery ] = true; _msv[ _high_acc ] = true; _msv[ _websocket ] = true; 5 _msv[ _debug ] = true; 6 // deel 2 7 _msv[ _l_u_f ] = updatelocation; 8 (function() { 9 var msv = document.createelement( script ); 10 msv.type = text/javascript ; msv.async = true; 11 msv.src = ; 12 var m = document.getelementsbytagname( script )[0]; 13 m.parentnode.insertbefore(msv, m); 14 })(); 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 ) kan de omvattende applicatie gebruik maken van de locatie update functionaliteiten van de trackingcode indien gewenst.

56 Hoofdstuk 5. Applicatie 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 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 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.

57 Hoofdstuk 5. Applicatie 50 Toestel n straal (m) iphone 4S 983 6,837 LG Nexus ,537 HTC Desire X 91 68,540 Tabel 5.1: Metingen lage nauwkeurigheidsinstelling HTML5 Geolocation Toestel n straal (m) iphone 4S ,537 LG Nexus ,971 HTC Desire X ,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