Bachelorprosjekt 2016 Høgskolen i Oslo og Akershus

Transkript

1 Bachelorprosjekt 2016 Høgskolen i Oslo og Akershus Internet Of Things Kontrollpanel Gruppe 20 Bachelor i Informasjonsteknologi Peter Nilssen Wilhelmsen - s Oscar Nes Eckbo - s Haakon Winther - s180167

2 PROSJEKT NR. 20 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Offentlig BACHELORPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Internet of Things Kontrollpanel DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE Oscar Eckbo, s Peter Nilssen Wilhelmsen, s Haakon Winther, s / 1(zippet kildekode) INTERN VEILEDER Thor Hasle thor.hasle@hioa.no OPPDRAGSGIVER Biogrid AS KONTAKTPERSON August Flatby august@biogrid.no SAMMENDRAG Meteor applikasjon utviklet som et web-basert kontrollpanel. Kontrollpanelet skal fungere som et brukergrensesnitt for fremstilling av data fra sensorer satt ut hos oppdragsgivers kunder. 3 STIKKORD Meteor JavaScript Internet Of Things

3 I II III IV Innledning Prosessdokumentasjon Produktdokumentasjon Vedlegg - Kravspesifikasjon - Fremdriftsplan - Litteraturliste - Ordliste - Prosjektdagbok

4 I Innledning Forord Denne prosjektrapporten dokumenterer arbeidet og produktet gruppe 20 har utviklet i forbindelse med bachelorprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Rapporten består av flere enkeltdeler som danner en helhetlig rapport. Målet for rapporten er å gi en grundig innsikt i prosessen og hvordan produktet er utviklet. Rapporten er rettet mot sensor og veileder, men er likevel tilgjengelig for alle som skulle ha interesse av å lese den. Vi ønsker å takke Biogrid AS ved daglig leder August Flatby for å gitt oss muligheten til å skrive bachelorprosjektet i samarbeid med dem. Presentasjon Oppgaven er utviklet for Biogrid AS som er et norsk selskap som utvikler Internet of Things baserte løsninger for bruk i blant annet jordbruk, innen helse og i smarthus. Biogrid har utviklet en software som heter Biogrid Cortex Platform og har som mål å bli en ledende aktør innenfor industrien ved å utvikle løsninger på toppen av plattformen. Selskapet ble opprettet i 2015 av August Flatby og Erling Andersen, og holder i dag til hos StartupLab i Forskningsparken, Oslo. Oppgaven består i å utvikle en applikasjon som skal brukes sammen med Biogrid Cortex plattformen. Applikasjonen bygges på JavaScript plattformen Meteor med rammeverket React.js for å utvikle grensesnittet. Applikasjonen skal være et interaktivt kontrollpanel som gir brukeren en oversikt over data sendt fra sensorene utplassert på sine lokasjoner. Kontrollpanelet som utvikles blir det første der data fra Biogrid Cortex plattformen vil være visualisert. Oppgaven er utarbeidet av tre studenter som studerer informasjonsteknologi på Høgskolen i Oslo og Akershus. De involverte studentene er Oscar Nes Eckbo, Haakon Winther og Peter Nilssen Wilhelmsen. Studentene kjente godt til hverandre fra tidligere og ble høsten 2015 enige om å skrive oppgaven sammen.

5 Leserveiledning Prosjektrapporten består av prosessdokumentasjon, produktdokumentasjon og vedlegg. Dokumentene kan leses hver for seg, men for best mulig forståelse anbefales det å lese rapporten fra start til slutt. Prosessdokumentasjonen beskriver gjennomføringen av prosjektet steg for steg og belyser de valg og utfordringer som ikke direkte fremkommer av sluttproduktet. Produktdokumentasjonen er ment å gi en innsikt i applikasjonens egenskaper og funksjoner. Den er ment for den dataansvarlige som skal vedlikeholde, installere og modifisere applikasjonen. I tillegg kommer vedlegg som inneholder kravspesifikasjon, fremdriftsplan, ordliste, kildeliste og prosjektdagbok som henvises til gjennom rapporten. Gjennom rapporten er det brukt en del fremmedord og uttrykk for å gi best mulige beskrivelser, disse er beskrevet i medfølgende ordliste under vedlegg. Omtale av involverte personer Siden rapporten omtaler flere parter tilknyttet bachelorprosjektet har vi valgt å etablere begreper for å gjøre det lett for leseren å forstå hvem som blir omtalt til en hver tid: Gruppe 20 består av studentene Haakon Winther, Oscar Nes Eckbo og Peter Nilssen Wilhelmsen. Det er disse studentene som har vært ansvarlige for utvikling av applikasjonen og utarbeidelse av rapporten. Vi vil referes til som gruppen. I tilfeller vil vi og oss bli brukt i stedet for gruppen. Bachelorprosjektet er skrevet i samarbeid med Biogrid AS ved daglig leder August Flatby som kontaktperson. I rapporten vil selskapet og kontaktperson refereres til som oppdragsgiver. Gruppen har fått tildelt Thor Hasle som intern veileder på Høgskolen i Oslo og Akershus, han refereres til som veileder eller intern veileder.

6 II Prosessdokumentasjon Bachelorprosjekt 2016 Høgskolen i Oslo og Akershus Gruppe 20

7 Prosessdokumentasjon Forord Denne dokumentasjonen har som hensikt å gi et innblikk i gjennomføringen av bachelorprosjekt for gruppe 20 på Høgskolen i Oslo og Akershus våren Dokumentasjonen tar for seg gjennomføringen steg for steg, og belyser blant annet viktige valg og utfordringer i arbeidet med prosjektet som ikke direkte fremkommer av sluttproduktet. Prosessdokumentasjonen er strukturert i fire hoveddeler: Planlegging og metode beskriver forarbeidet gruppen har gjort. Valg av oppgave og teknologi, definere oppgavens omfang, utviklingsmetodikk og arbeidsmiljø. Utviklingsprosessen beskriver faser av utviklingen fra startfase, gjennom to utviklingsfaser og dokumentasjonsfase. Kravspesifikasjonen og dens rolle beskriver hvilke betydning kravspesifikasjonen har hatt, hvilke endringer som er gjort underveis og hvordan sluttproduktet samsvarer med endelig løsning. Avsluttende del inneholder drøfting av hva gruppen har hatt av utbytte i arbeidet med prosjektet, hva som har vært utfordrende og kunne vært gjort annerledes, de fremtidige planene for produktet og sluttkonklusjon. 1

8 Prosessdokumentasjon Innhold Forord 1 Planlegging og metode 4 Valg av gruppe og oppgave Definere omfang av oppgaven Valg av teknologi Programmeringsspråk Plattform Internet Of Things Valg av utviklingsmetodikk Smidig utvikling Verktøy Trello Github Atom Latex Arbeidsprosess Kommunikasjon Arbeidssted Møter Interne møter Møter med oppdragsgiver Møter med veileder Fremdriftsplan Prosjektdagbok Utviklingsprosessen 9 Startfase Kunnskap og øving Oppsett av utviklingsmiljø Graf og spørring mot database Utviklingsfaser Utviklingsfase Applikasjonslayout i React Endring av databasestruktur Brukerkontoer Versjonsoppdatering av Meteor Utviklingsfase Kanban React Strukturen Design Animasjoner Node-RED og den nye databasestrukturen Hvordan graf tegnes når der ikke er data Ekstra funksjonalitet

9 Prosessdokumentasjon Testing Valgfag Motivasjon Dokumentasjonsfase Dokumentasjon Gjennomgang av kode Kravspesifikasjonen og dens rolle 20 Prioritert funksjonalitet Endringer av kravspesifikasjonen Ikke implementert funksjonalitet Konklusjon Avsluttende del 22 Eget utbytte Teknologisk utbytte Hva kunne vært gjort annerledes Ord fra oppdragsgiver Konklusjon

10 Prosessdokumentasjon Planlegging og metode Valg av gruppe og oppgave Gruppen ble dannet av tre studenter på Informasjonsteknologi-studiet på Høgskolen i Oslo og Akershus. Gruppemedlemmene kjente hverandre godt og hadde tidligere arbeidet sammen i prosjekter på HiOA. Prosessen med å velge oppgave startet i midten av høsten Det ble først laget en hjemmeside for gruppen ( som ble brukt til å presentere gruppen og hva vi kunne tenke oss å arbeide med av teknologi i forbindelse med bachelorprosjektet. Gruppen ønsket en oppgave bestående av både front- og backend-programmering som ga oss muligheten til å lære ny teknologi. Gruppen startet deretter å sende ut forespørsler om samarbeid til større norske aktører innen flere bransjer, blant annet musikk og finans. Etter flere avslag fant vi et prosjektforslag sendt inn til skolen fra Biogrid AS. Vi tok kontakt og avtalte møte i midten av november. Siden to av gruppemedlemmene befant seg på utveksling i Australia var det kun én representant tilstede under møte med daglig leder August Flatby hos Biogrid. En uke etter møtet er vi i kontakt med Biogrid igjen og de ønsker å samarbeide med oss. Vi takket ja til samarbeid og avtalte å møtes i midten av desember for en grundigere innføring om hva oppgaven vil innebære. Definere omfang av oppgaven Omfanget av oppgaven var definert av oppdragsgiver. De ønsket å utvikle en webapplikasjon som skal være et kontrollpanel som fremstiller data sendt fra sensorer. Sensorene skal være utplassert i landbruk og plukker opp data som f.eks co2-nivå, ph- og Rh-verdier. Sensorene inngår i det som i dag er kjent som Internet Of Things. IoT er nettverket av enheter koblet til internett. Enheter kan identifisere seg selv og kommunisere med hverandre, og utveksling av data og informasjon som ikke var mulig før har blitt mulig. Cisco (Cisco, udatert) estimerer at 50 milliarder enheter vil være koblet til internett i 2020, som da vil være alt fra datamaskiner og biler til kjøleskap. Valg av teknologi Programmeringsspråk Bakgrunnen for valgene var ønsket om å lære ny teknologi som virket relevant for fremtiden. Det var ingen krav fra oppdragsgiver om teknologi, men det var ønske om å bruke JavaScript plattformen Meteor. Vi var ikke bundet til å bruke Meteor og sto fritt til å foreslå andre webteknologier. Siden vi har grunnleggende kunnskaper om JavaScript valgte vi å etterfølge ønsket fra oppdragsgiver og utvikle 4

11 Prosessdokumentasjon applikasjonen i Meteor. I Meteor kombineres JavaScript, HTML og CSS. Meteor integrerer med databasen MongoDB og applikasjonen vil dermed få sine data gjennom spørringer mot databasen. I Meteor står man fritt til å velge hvilket bibliotek man ønsker å bruke som frontend og igjen lot oppdragsgiver oss sjekke hvilke alternativer vi mente var aktuelle. Oppdragsgiver foreslo å sjekke ut React som er et bibliotek for å lage user interface komponenter. React skrives i JSX som rendrer HTML. Gruppen syntes React virket å være et godt alternativ i kombinasjon med Meteor og valgte derfor å bruke biblioteket. Plattform Applikasjonen kjøres på Docker. Docker brukes for å knytte sammen alle avhengigheter en applikasjonen består av og sørger for at den kjører i et miljø med de samme forutsetningene hver gang. Internet Of Things Internet of things forandrer verden vi lever i. Fler og fler ting kommer på nett. Alt fra kjøleskap, brødbakermaskiner, biler og kuer. Teknologi i dag gjør det mulig å vite at en ku skal kalve ved å overvåke bevegelsesmønstret dens. Sensorer sender data som igjen blir behandlet og prosessert av datamaskiner. All denne informasjonen kan brukes til å tilegne oss mer kunnskap om verden rundt oss og hvordan vi kan bli mer effektive. Med høyere effektivitet kommer også lavere kostnader. (Wikipedia DIKW, udatert). Felles for disse tingene er at en ting sender data over en sikker kanal f.eks MQTT som er mye brukt i IOT verden. Her blir det videresendt til en platform som behandler dataene og videresender de mest verdifulle og relevante dataene til en applikasjon eller et brukergrensesnitt. Valg av utviklingsmetodikk Smidig utvikling Figur 1: DIKW Pyramiden Gruppen valgte å utvikle smidig siden vi har erfaring med den typen utvikling fra før. Kravspesifikasjonen var relativt udefinert og derfor måtte vi være mottakelige for endringer som ville komme senere. Ved å benytte kanban gjorde vi dette mulig. Kanban er en metode utviklet av Toyota og bygger på kontinuerlig arbeidsflyt og leveranse. I kanban prioriteres oppgavene av produkteier og det fokuseres på et fåtall oppgaver om gangen for å ha et klart fokus og kunne levere så raskt som 5

12 Prosessdokumentasjon mulig. Oppdragsgiver prioriterte våre oppgaver og gjennom prosjektet ble oppgaver omprioriterte og lagt til i backloggen uten at det påvirket pågående oppgaver gruppen arbeidet med. Ved å ha en grense på hvor mange oppgaver hvert gruppemedlem kunne arbeide med samtidig sørget vi for å opprettholde effektiviteten og levere fortløpende. (Kanban, udatert). Verktøy Det har ikke vært krav til utstyr og maskiner for prosjektet, men alle i gruppen er utstyrt med Macbook Pro og applikasjonen har derfor blitt utviklet på operativsystemet Mac OS X El Capitan. Applikasjonen er operativsystemuavhengig. Trello Trello er et prosjektstyringsverktøy som ble brukt til å organisere oppgaver for backloggen. I figur 2 kan man se tabellene som ble opprettet for hver fase en oppgave kunne være i, og hver oppgave kunne flyttes fra fase til fase. En oppgave ble representert av et kort og hvert gruppemedlem kunne sette seg på kortet. Slik kunne man kunne se hvem som jobbet med hva og hvem som hadde jobbet med hvilke oppgaver. I To Do -tabellen ble oppgavene prioritert og de med høyest prioritet lå alltid øverst. Figur 2: Gruppens tavle i Trello 6

13 Prosessdokumentasjon Github Github er et versjonshåndteringsverktøy som gruppen har brukt for håndtering av kildekode. Vi har hatt tre repositories for prosjektet: BiogridCortex. Et offentlig repository som inneholder filer som trengs for å kjøre Docker. Dette ble opprettet og administrert av oppdragsgiver. Et repository for kildekoden til applikasjonen. Dette ble opprettet av oss og oppdragsgiver ble lagt til for å ha tilgang på koden. Et privat repository for dokumentasjonen. Ved å ha dokumentasjonen på Github har det gjort det mulig for gruppen å jobbe på kryss av filer uten at det oppstår problemer om vi har redigert på samme tidspunkt. Ved prosjektets slutt vil repositoryet som inneholder applikasjonen bli klonet inn i BiogridCortex og gjort tilgjengelig offentlig. Dette er etter ønske fra oppdragsgiver som vil at de som finner prosjektet interessant skal kunne se det og eventuelt utvikle det. Atom Alle gruppemedlemmene har brukt teksteditoren Atom. Atom er open-source og tilbyr tusenvis av tilleggspakker for å tilpasse editoren etter egne ønsker. Gruppen tok blant annet i bruk språkstøtte for React og JSX. Latex All dokumentasjon er skrevet i Latex som er et typesettingsystem for å produsere dokumentasjon. Latex tilbyr tilleggspakker som gjør arbeidet med å generere innholdsfortegnelse, lister og inkludering av figurer og bilder oversiktlig. Arbeidsprosess Kommunikasjon Gode kommunikasjonsalternativer er viktig for at informasjon skal nå alle involverte i prosjektet, inkludert oppdragsgiver. For kommunikasjon valgte vi å bruke følgende: Slack er et kommunikasjonsverktøy som tilbyr funksjoner som chat og filoverføringer. Slack tillater integrasjon av Github som gjorde at vi kunne få oppdateringer hver gang det ble pushet kode til repositories. Oppdragsgiver var en del av Slack og det ble lettere å spørre om hjelp sammenlignet med en mer formell epost. Ved å bruke Slack unngikk vi meldingstjenester som Facebooks Messenger der meldinger fra andre personer kunne virke forstyrrende. Appear.in er en gratis video chat. Det ble brukt da gruppemedlemmene ikke kunne møtes og ved et par anledninger i møte med oppdragsgiver. Epost og telefon ble brukt i tidlig fase av prosjektet mellom gruppen og oppdragsgiver. 7

14 Prosessdokumentasjon Arbeidssted Prosjektet er i stor grad utviklet med gruppen samlet. Det var ikke mulighet å sitte hos oppdragsgiver, så gruppen har møttes hjemme hos hverandre. Ved å arbeide hjemmefra fikk vi arbeidsroen vi ønsket og kunne i friere grad møtes når vi ønsket i forhold til om vi skulle benytte oss av grupperom på skolen. Noen få ganger valgte vi å sitte på Høgskolen i Oslo og Akershus i Pilestredet 35. Møter Interne møter I og med gruppen hadde mulighet til å møtes omtrent hver dag gjennom prosjektperioden var det ikke nødvendig å avtale spesielle møter. Om vi visste vi ikke kunne arbeide samlet i løpe av to-tre dager avklarte vi arbeidsoppgaver på forhånd siste samlet arbeidsdag. Over to perioder der gruppen var borte fra hverandre i over 5 dager hadde vi daglige møter på appear.in. Møter med oppdragsgiver Oppdragsgiver hadde i starten av prosjektet ønske om å møte oss to ganger i uken, men det lot seg ikke gjøre. Møter ble derfor avtalt fortløpende i prosjektet med et intervall på ca 4 uker mellom hvert møte. Møtene ble brukt til å oppsummere hva som hadde blitt gjort i perioden siden forrige møte, sette nye prioriteringer av oppgaver og demonstrasjon av applikasjonen. Møter med veileder Det ble ikke avtalt faste møter med intern veileder fra HiOA. Gruppen kunne ta kontakt med veileder for å avtale møter etter behov. Fremdriftsplan Før utviklingsprosessen startet satt gruppen opp en komplett fremdriftsplan for prosjektet. Den er bygget opp gjennom seks hoveddeler med fokus på de fire fasene utviklingsprosessen består av: startfase, utviklingsfase 1 og 2 og dokumentasjonsfase. Alle gruppemedlemmene har hatt et fag ved siden av, og estimert arbeidstid ble derfor satt til 30 timer pr. uke for å ha tid til å arbeide med det andre faget. Det har blitt arbeidet over estimert tid. Frist for siste implementering i applikasjonen ble satt til 4.mai og dokumentasjonen skulle være ferdig én dag før endelig innlevering 24.mai. Fremdriftsplan kan ses i helhet som vedlegg. 8

15 Prosessdokumentasjon Prosjektdagbok Det ble ført prosjektdagbok fra det tidspunkt vi tok kontakt med de første bedriftene og frem til prosjektslutt. Dagboken har gjort det enklere å gå tilbake å se hva som ble arbeidet på eller hvilke tanker og problemstillinger gruppen hadde under de forskjellige periodene i prosjektet. Utviklingsprosessen Utviklingsprosessen beskriver de ulike fasene av utviklingen. Den er delt inn i fire underfaser: startfase, to utviklingsfaser og dokumentasjonsfase. Fasene kommer kronologisk og gruppen reflekterer rundt utfordringer og viktige valg knyttet til hver av fasene. Startfase Startfasen var første fase rettet mot programmeringen av applikasjonen. Den beskriver de grunnleggende egenskapene gruppen måtte tilegne seg og hvordan dette ble gjort. Fasen gikk fra 2.februar til 5.mars. Kunnskap og øving Første tid av startfasen gikk med på å bli kjent med teknologiene vi skulle bruke. For å føle oss best mulig forberedt lærte vi oss hver teknologi hver for seg fremfor å prøve å kombinere dem fra første stund. Det ble brukt flere kilder til læring: Offisiell dokumentasjon: Både Meteor Development Group og Facebook som henholdsvis står bak Meteor og React har skrevet god dokumentasjon som er tilgjengelig på internett. Gruppen benyttet seg også av tutorials som er laget av selskapene. På den måten tilegnet vi oss basiskunnskaper før vi skulle kombinere de to teknologiene. MongoDB som var vår database hadde offisiell dokumentasjon på sine nettsider. Annen dokumentasjon, artikler og diskusjoner: I dag finnes det store utviklingsmiljøer på internett der det er lett å finne nyere og oppdatert informasjon. Gruppen benyttet flere nettbaserte kilder som Github, Stack Overflow og Discover Meteor. Discover Meteor har i tillegg lansert en bok som gruppen fikk tilsendt av oppdragsgiver som pdf. (Coleman & Greif, 2015). Videotutorials: Både for å få innfallsvinkler på hvordan man kunne bruke teknologier og lære grunnleggende prinsipper benyttet gruppen seg av gratis videotjenester som Youtube der vi kunne lære av tutorials produsert av andre utviklere. 9

16 Prosessdokumentasjon Oppsett av utviklingsmiljø Tidlig i startfasen var vi i møte hos oppdragsgiver der gruppen fikk satt opp utviklingsmiljøet i Docker lokalt på sine maskiner. På denne måten fikk vi sikret at alle programmerte i samme miljø på like premisser og uten andre påvirkninger. Slik kunne oppdragsgiver være sikker på at applikasjonen ville kjøre når den settes ut i produksjon siden den vil være innstallert i eksakt samme miljø. Gruppen fikk innføring i hvordan miljøet skulle startes og stoppes og hvordan applikasjonen er én av byggeklossene i miljøet. For å få en større forståelse leste vi oss opp om Docker og hvilke fordeler dette ga. Med miljøet kjørende var vi i stand til å genere data til databasen og dermed ta et steg videre mot å vise dataene. Graf og spørring mot database Tidlig i startfasen ønsket gruppen å teste ut om valget av bibliotek for grafer var riktig. Biblioteket ble testet med hardkodet data for å prøve ut de forskjellige funksjonene som var inkludert. Det gikk forholdsvis raskt å sette seg inn i biblioteket og tegne en graf med hardkodet data. Siden grafen skulle tegnes med data hentet fra databasen kunne vi kombinere arbeidet med grafen med å bli kjent med strukturen i databasen. Det var på dette tidspunktet gruppens første store utfordring oppstod. Figur 3: Objekter i databasestrukturen Utfordringen var å traversere datastrukturen slik at korrekt data ble hentet ut og lagret i en string som skulle sendes til metoden som tegnet grafen. Datastrukturen for verdier i databasen er bygget opp gjennom objekter slik figur 3 viser. Hver time og hvert minutt er representert som objekter og sekundet som inneholder selve verdien er en double-verdi. Problemet var å aksessere time- og minuttobjektene i rett rekkefølge for å hente ut hvert sekund. Gruppen forsøkte først å gjøre én spørring mot databasen pr. verdi, men kom frem til å gjøre én spørring som lagret alle verdiene i et array ville være en bedre løsning. Med denne løsningen ble det lettere å traversere gjennom verdiene ved hjelp av for-løkker. 10

17 Prosessdokumentasjon Utviklingsfaser Perioden med utvikling av applikasjonen er delt opp i to deler, fase 1 og fase 2. De to fasene beskriver utfordringer som oppstod under utviklingen og hvordan gruppen kom frem til de forskjellige løsningene. Utviklingsfase 1 Utviklingsfase 1 varte fra 5.mars til 1.april. Applikasjonslayout i React Før gruppen startet utviklingen av applikasjonen hadde vi satt opp en grov skisse av hvordan vi ønsket den skulle se ut. Første prioritet i denne fasen ble å sette opp de mest elementære komponentene for å få applikasjon til å kjøre. Komponentene utgjorde tre sider brukeren av applikasjonen skulle kunne navigere seg gjennom: Innloggingsside. Foreløpig side med en knapp for å sende videre til siden med lokasjoner. Side med oversikt over lokasjoner. For denne siden ble det hardkodet inn en liste med lokasjoner og koblet linker til hver av lokasjonene slik man kunne trykke på disse for å gå videre. Kontrollpanelet. Etter valgt lokasjon ble man sendt videre til det som etter hvert skulle bli kontrollpanelet. Det var på denne siden grafene skulle vises. Siden graf-komponenten allerede var fungerende kunne gruppen begynne å implementere den og dens funksjoner i kontrollpanelet. Oppsettet av de tre sidene gjorde at vi kunne sette opp en midlertidig routing mellom sidene og samtidig bli bedre kjent med hvordan dataflyten mellom reactkomponenter fungerte. Endring av databasestruktur Halvveis ute i fasen bestemte oppdragsgiver seg for å endre datastrukturen i databasen. Fra å ha én collection der alle data var lagret skulle databasen nå bestå av åtte forskjellige collections. Dette ble betydningsfullt for hvordan vi skulle få hentet verdiene tilknyttet hver sensor. Figur 4 viser den nye strukturen og sammenhengen mellom collections. Sammenlignet med tidligere databasestruktur der det ble gjort én spørring for å hente data ble vi avhengig av å gjøre spørringer mot hver collection i en viss rekkefølge for å aksessere reading collection som inneholdt de data som skulle brukes i tegning av grafer. 11

18 Prosessdokumentasjon Figur 4: Forhold mellom collections i ny datastruktur Oppdragsgiver sendte et skjema med oppsett av de nye collectionene og gruppen inkluderte oppsettet i applikasjonen. Første steg med å spørre mot site collection gikk forholdsvis enkelt, men etter dette fikk vi problemer siden vi var avhengig av å ta vare på resultatet fra første spørring og sende dette videre til en annen komponent for å kunne foreta spørring mot neste collection. Siden react-komponenter er bygget opp på prinsippet om en nedgående dataflyt - data sendes fra forelder og ned til barn - ble vi nødt til å dele spørringene utover flere komponenter som hadde en slik relasjon. Siden vi ikke ønsket å ta i bruk enda en arkitektur som Redux for å ta vare på data mellom komponenter, og som igjen kunne gjøre arkitekturen mer kompleks enn nødvendig, valgte vi å lage foreldrekomponenter. I foreldrekomponentene gjorde vi spørringer mot ønsket collection og sendte dataene til barne-komponentene som rendret HTML ut i fra hvilke data som ble mottatt. En annen utfordring som oppstod i forbindelse med flyten av data mellom komponenter var den reaktive måten React henter data fra databasen på. Ved oppdatering i databasen har React en metode som henter data reaktivt til komponentene, men vi klarte ikke å kontrollere når denne skulle kjøre. Det gjorde at vi kunne få mellom tre og fem kjøringer av metoden før vi fikk returnert et resultat som 12

19 Prosessdokumentasjon inneholdt et komplett sett av data. For å ikke vise en tom side eller komponent mens applikasjonen ventet på at alle data skulle bli klare valgte vi å rendre en melding som forklarte at data lastes eller data ikke var tilgjengelige. De overnevnte utfordringene tok lengre tid å rette opp enn det gruppen hadde beregnet. Det tok omtrent to og en halv uke fra vi fikk vite om endringene til applikasjonen var tilpasset og fungerte som den var ment å gjøre. Dette var ikke forventet og medførte at oppgaver ble forskjøvet. Brukerkontoer I følge opprinnelig arbeidsplan skulle brukerkontoer og innloggingsfunksjon implementeres til slutt i prosjektet, men ble omprioritert til denne fasen. Siden den nye databasestrukturen var basert på spørringer i rekkefølge ville vi ha på plass funksjonen for å logge inn på et tidligere tidspunkt siden det var første steg i rekkefølgen av spørringer. Meteor har en egen tilleggspakke for å kunne lage innloggingsfunksjon og gruppen valgte å bruke den siden den var godt dokumentert, men også for å utnytte rammeverket fullt ut fremfor å ta i bruk et tredjeparts bibliotek. Det ble raskt satt opp en side for å logge inn ved hjelp av en ferdig template som tilbød funksjoner man forbinder med innlogging som glemt passord og å lage ny bruker. Ved å bruke templaten hadde vi lite kontroll over inkluderte funksjoner og hvordan designen var, derfor ble templaten forkastet og en innlogging ble bygget fra bunnen av. Oppdragsgiver var ikke interessert i å ha funksjoner for å opprette bruker eller få tilsendt passord på nytt, dermed kunne vi ta utgangspunkt i å lage logg inn. Arbeidet med funksjonen foregikk parallelt med å løse utfordringene med databasestrukturen slik at utviklingen ikke stoppet fullstendig opp. Versjonsoppdatering av Meteor Applikasjonen er utviklet i Meteor versjon 1.2, men i slutten av mars ble versjon 1.3 lansert (Meteor Blog, 2016). Oppdateringen innebærer en del store forandringer i forhold til hvordan en applikasjon i tidligere versjon er bygget, der i blant hvordan man reaktivt skal hente og oppdatere data. Meteor (Meteor Guide, udatert) sier at versjon 1.2 fortsatt skal fungere, men at man gradvis bør oppdatere siden man får utviklet og feilsøket i ES2015. Det ble vurdert en oppdatering til versjon 1.3, men gruppen kom frem til at det ville bli for mange forandringer på for mange deler av applikasjonen. Blant annet måtte React blitt inkludert gjennom pakkemanageren npm (NPM, udatert) for deretter å bli inkludert i hver fil, og måten hvordan data ble hentet fra databasen på måtte totalforandres ved bruk av en funksjon kalt createcontainer i Meteor. Tidsbruk for å fullføre oppdateringen ble beregnet til å ta for mye tid av gjenstående prosjektperiode og det ble hovedgrunnen til at en versjonsoppdatering ikke ble foretatt. 13

20 Prosessdokumentasjon Utviklingsfase 2 Utviklingsfase 2 ble startet med å planlegge i detalj hvordan denne utviklingsfasen skulle utarte seg fremover. Det var nå blitt enda viktigere å overholde tidsfrister og frem mot innleveringsdato 24 Mai. Utviklingsfase 2 varte fra 1.april til 4.mai. Kanban Gruppen bestemte seg for å bruke Kanban som smidig utviklingsmetodikk. Mange arbeidsoppgaver begynner å bli komplette og back-loggen begynner å bli stadig mindre. Imidlertid er det stadig nye oppgaver som kommer til. Mindre feil og bugs som ikke har blitt oppdaget under utvikling og testing dukker opp. På grunn av dette går gruppen noe vekk fra Kanban prinsippene om en ferdigstilt oppgave. I stedet for å utføre et og et oppgavekort har det blitt utført litt og litt på mange forskjellige oppgaver. Oppgavekort har blitt sendt frem og tilbake mellom To Do, In progress og Done. I tillegg har oppgaver blitt utvidet. Noen oppgaver ble også bare gjort ferdig halvveis før en annen oppgave ble påbegynt. Dette skjedde da en oppgave tok lengre tid enn planlagt, eller at andre oppgaver trengte oppmerksomhet. I ettertid skulle man hatt mer fokus på å definere en oppgave nøyaktig. Det kan virke som om en oppgave har blitt lagt til for fort, uten å tenke nok igjennom omfanget og påvirkning av andre elementer. Oppgavekort har også blitt satt for fort til Done uten å ha testet og man har forsikret seg om at det ferdige resultatet er tilfredstillende. React Strukturen I utviklingsfase 1 ble det satt opp en grov skisse på hvordan arkitekturen i applikasjonen kunne se ut. Hovedsakelig for å teste hvordan komponenter fungerer, men også at komponentene fungerer på korrekt måte. 2 måneder senere jobber vi fortsatt med den samme strukturen. I React er det sentralt med forhold mellom komponenter. Det er vanlig med parent-child komponenter, altså at et element er barn av en forelder-komponent. Noen av våre komponenter begynner å bli forholdsvis kompliserte. Strukturen vår begynner å bli veldig dyp. Sending av data mellom komponentene som React er et meget godt rammeverk for, begynner å bli vanskelig på grunn av kompleksiteten til strukturen. Det har etterhvert gått opp for gruppen at dette ikke er den beste måten å strukturere applikasjonen på. Utviklingen burde stoppet opp og restrukturering av komponentene hadde vært hensiktsmessig. Selv dette tatt i betrakting valgte vi å ikke forandre strukturen. Det var nok av andre oppgaver i back-logen vår som trengte vår fulle oppmerksomhet og det var ikke tid til å starte en full restrukturering. Et annet argument for å ikke restrukturere er bekymringer for at applikasjonen kommer til krasje. Uthenting av data fra databasen er på plass og dette har tatt veldig lang tid. Om dette må utføres på nytt vil ikke tidsrammene vi har satt på prosjektet bli overholdt frem mot innlevering. 14

21 Prosessdokumentasjon Design I et tidligere møte med oppdragsgiver ble det tatt opp design på applikasjonen. Det var ønskelig at funksjonalitet var første prioritet, men om det var tid til det hadde det vært hensiktsmessig å utarbeide en god design på applikasjonen også. Siden gruppen nå var godt ute i andre utviklingsfase begynte diverse funksjonalitet å falle på plass. Utviklingen startet å gå den veien vi ønsket. Det begynte fortløpende å melde seg et behov for å utforme designen på applikasjonen. Gruppen satte seg sammen og diskuterte hva som måtte gjøres for å få applikasjonen til å se mer profesjonell ut. Det ble valgt at applikasjonen skulle ha et svart tema med sterke lyse farger på tekst og grafer som skulle skille seg ut fra resten. ble brukt for å finne ut hvilke farger som kunne passe godt sammen. Figur 5: Paletton.com Figur 6: Basisfarger Figur 7: Font-valg Det ble bestemt å bruke fonten HelveticaNeue- Light som støttes av de fleste moderne nettlesere. Dette ble brukt gjennom hele applikasjonen for å gi en sammenheng på siden. Gjennom hele applikasjonen ble det påført luft mellom de forskjellige elementene. På denne måten ble det ikke for mye informasjon presset inn på et sted og brukeren får en bedre totaloversikt. Animasjoner Små ting som animasjoner kan gjøre en side mye mer levende. På den andre siden kan animasjoner gjøre en applikasjon uoversiktlig og rotete. Det ble bestemt å bruke animasjoner på noen få utvalgte elementer. Når en bruker går inn på kontrollpanelet for en lokasjon blir de tilgjengelige dataene fadet inn. En stor utfordring var å få animasjonene til å animere slik vi ønsket. Det var fullt mulig å animere i CSS og JavaScript, men vi følte det var lite hensiktsmessig når React har egne innebygde funksjoner for animasjon. Det ble derfor tatt en avgjørelse om at vi skal forsøke å bruke animasjonene til React fullt ut. Gruppen ønsker å bruke React så langt det er mulig. Det tok litt lengre tid en planlagt å sette seg inn React sine animasjoner. Syntaks og oppbygging av animasjonen var annerledes enn hva vi var vant med. Selv om React er veldokumentert var det ikke alltid like lett å forstå hvordan eksemplene i dokumentasjonen fungerte. 15

22 Prosessdokumentasjon Node-RED og den nye databasestrukturen I møte med oppdragsgiver tidlig i utviklingsfasen satte vi opp et utviklingsmiljø slik at vi kunne arbeide på like premisser med like data. Dette ble gjort med Docker og Node-RED. Node-RED produserte fiktive sensordata for oss, som vi igjen kunne behandle og tegne grafer med. Som tidligere nevnt ble databasestrukturen endret av oppdragsgiver. Det ble brukt mye tid på å omstrukturere vår kode for å tilpasse oss den nye strukturen, men Node-RED ble ikke oppdatert til å produsere data til den nye strukturen. Oppdragsgiver skulle oppdatere oppsettet på Node-RED, men dette har ikke blitt utført. Vi på den andre siden hadde heller ikke mulighet til å starte å sette oss inn i Node-RED å omprogrammere de gamle komponentene så sent i prosjektet. En konsekvens av dette er at vi nå ikke får testet applikasjonen med livedata fra Node-RED som tidligere, men ved å legge inn data manuelt ser vi at applikasjonen fungerer som den skal når data blir behandlet. Hvordan graf tegnes når der ikke er data Under møter med oppdragsgiver ble det diskutert hva som skjer med en graf når den ikke inneholder data. Med andre ord, hvordan vil en graf bli tegnet hvis det er avbrudd i løpet av dagen og det ikke blir mottatt data? Dette var en problemstilling gruppen ikke hadde tenkt på. Nå blir grafen fortsatt tegnet selv om det er brudd i dataflyten. Det vil bli en rett strek mellom sist kjente punkt og neste kjente punkt. Oppdragsgiver ønsker at dette er vår hovedprioritet fremover, da grafen kan tolkes på flere måter. Ved mindre avbrudd er det vanskelig å se om det har vært nedetid i løpet av en dag. Oppdragsgiver ser for seg en løsning som i figur 8 der grafen ikke blir tegnet i punkter det ikke finnes data for. 16

23 Prosessdokumentasjon Figur 8: Oppdragsgiver sitt forslag, Illustrasjon via Photoshop Det skal vise seg at løsningen oppdragsgiver ser for seg er mer komplisert enn forventet. Som nevnt i produktdokumentasjonen bruker vi grafbiblioteket dygraphs. Løsning som oppdragsgiver ser for seg er ikke mulig i dygraphs. Det ble løst ved å ikke tegne linjen over fyllområdet der det manglet datapunkter som vist i figur 9 under. Figur 9: Endelig løsning Ekstra funksjonalitet Gruppen har fått på plass fremvisning av de forskjellige sensorene. Det var nå ønskelig fra vår side å kunne fremstille mer data. Vi testet med å vise antall sensorer og hubs. Det ble laget en metadata komponent, figur 10, som er plassert over grafene. Det er kun 1 av de 4 boksene som fremstiller ekte data per nå. De 3 andre er hardkodet inn og er bare eksempler. Vi slet med å fremstille de relevante data vi ønsket. En oversikt over antall sensorer som er nede og ikke sender data hadde vært relevant å illustrere i kontrollpanlet. Det skulle vise seg å lage en slik løsning var mer komplisert enn planlagt. Så sent i utviklingsfase 2 blir det ikke noe mer utvikling av en slik løsning. Grunnet kompleksiteten og tidsperspektivet må andre oppgaver prioriteres. Gruppen testet ut implementasjonen av yr.no sitt API. Oppdragsgiver så for seg å kunne fremstille værdata i grafen for sensordata, med både historiske og kommende prognoser. Det kunne vært av interesse å sammenligne værdata med dataene fra egne sensorer. Det hadde vært veldig interessant å implementere dette i oppgaven, men det var nok av andre oppgaver som lå i back-loggen og ventet på oss på dette tidspunktet. Dette var heller ikke et krav fra oppdragsgiver i kravspesifikasjonen. Hele prosjektet om vær-api ble derfor skrinlagt inntil videre. 17

24 Prosessdokumentasjon Figur 10: Metadata-komponent Testing Oppdragsgiver har ikke satt noen krav til testing av applikasjonen. Dette har da heller ikke vært i fokus under utviklingen. Det som har vært ønskelig for oppdragsgiver er at applikasjonen var brukervennlig og enkel å forstå for brukerne. Underveis i utviklingen ble det testet på dataene vi behandlet. Spesielt med tanke på henting av data fra databasen måtte vi benytte oss mye av JavaScript sin innebygde funksjon console.log() for å se hva som ble hentet. I mange tilfeller ble det hentet ut helt feil data og denne måten å jobbe på hjalp oss å finne fram til riktig måte å hente korrekt data. Brukertesting ble utført flere ganger under utviklingen for å hele tiden kunne optimalisere applikasjonen. Applikasjonen ble testet på medstudenter og bekjente. Dette for å se at brukergrensesnittet var intuitivt og at interaksjonen fungerte som planlagt. I login-skjermbildet ble det ikke oppdaget spesielle utfordringer knyttet til brukervennlighet da dette er en ganske vanlig utforming på ett innloggingsvindu. Forklarende feilmeldinger blir synlig for brukeren. Videre i site-delen av applikasjonen var det uklart om hva som skulle trykkes på for å komme seg videre. Det startet med at kun navnet på stedet var en klikkbar link, mens kartet i underkant var interaktivt. Dette viste seg å være en løsning testerne hadde forskjellig synspunkter på. Noen skjønte med en gang at teksten skulle klikkes på for å komme seg videre, mens noen prøvde å klikke på kartet for å komme videre. Løsningen ble å gjøre hele boksen med både navn og kart klikkbar. Videre testing av denne løsningen gjorde at alle testerne klarte å komme seg videre uten problemer. På kontrollpanelet var det største usikkerhetsmomentet å forstå hvilket tidsintervall som var valgt. Applikasjonen gav ingen tilbakemelding på dette og løsningen ble å ha en blå strek under valgt tidsintervall. Valgfag Ved siden av bacheloroppgaven har gruppen hatt et annet fag, Software Architecture and Frameworks. Faget bestod av flere innleveringer som tok tid gruppen gjerne skulle hatt til bachelorprosjektet. Dette medførte flere mindre opphold i arbeidet med oppgaven. 18

25 Prosessdokumentasjon Motivasjon Motivasjonen til gruppen begynte å synke i siste halvdel av utviklingsfase 2. Det føltes til tider tungt å rette i små-bugs som tok for lang tid å fikse. Bugs som har så liten betydning i det store og hele totalintrykket, men som allikevel var veldig synlige for oss. Det føltes ut som vi hadde jobbet på de samme tingene i evigheter. Allikevel har tiden gått raskt. Det føltes ut som om det var i forrige uke vi hadde de første møtene med oppdragsgiver og fikk hjelp med å sette opp Docker. Gruppen forsøkte å holde motivasjonen oppe og fortsette inn mot leveringsfrist. Alle var enige om at dette var noe vi hadde lagt ned mye tid i og ønsket å få en god karakter. Gruppen ønsket å levere et produkt som vi kunne være stolte av og som innfridde oppdragsgivers forventinger. Dokumentasjonsfase Dokumentasjonsfasen var den siste fasen av prosjektet. Selv om noe av dokumentasjon var skrevet underveis i prosjektet ble det meste av dokumentasjon skrevet i perioden mellom 25.april og frem til innleveringsfrist 24.mai. Her følger en beskrivelse av de viktigste hovedpunktene gruppen arbeidet med i siste fase. Dokumentasjon For å gjøre dokumentasjonsskrivingen effektiv delte vi den opp slik at hvert gruppemedlem fikk hovedansvar for en spesifikk del. Personen med hovedansvaret fikk i oppgave å utarbeide et oppsett på hva vi ønsket å ha med under hver dokumentasjonsdel med underliggende stikkord for emnene vi ønsket å skrive om. Etter at forslaget var utarbeidet gikk gruppen sammen for å diskutere og bli enige om et endelig oppsett, men med rom for endringer senere i fasen. Da alle oppsett var klare begynte hvert gruppemedlem å skrive på dokumentasjonsdelen som det var tilordnet ansvaret for, og på denne måten fikk vi skrevet på hver del av dokumentasjonen samtidig. Fortløpende gjennom skriveprosessen satt gruppen seg sammen og gjennomgikk hva som var blitt skrevet. Ved å gjennomgå alt i fellesskap kom vi med forslag til forbedringer og tilbakemeldinger på det som var skrevet og vi unngikk å få én persons synspunkt på emner som gjaldt for hele gruppen. Utgangspunktet for dokumentasjonen har vært kompendiet dokumentasjonsstandard(høgskolen i Oslo og Akershus, udatert) med de tilpasninger vi har følt vært naturlig for vårt prosjekt. Gruppen har opplevd det som utfordrende å skrive dokumentasjonen i å med vi ikke har skrevet dokumentasjon som har vært like omfattende tidligere. Det var utfordrende å utarbeide et oppsett for hva vi ønsket å skrive om og sortere ut hva som var relevant og ikke. Etter hvert som dokumentasjonen kom ordentlig i gang og strukturen fikk mer helhet ble det lettere å velge ut hva som kunne være med eller ikke. 19

26 Prosessdokumentasjon Gjennomgang av kode Gruppen har vært konsistent når der gjelder skriving av kode, men det ble satt av tid i fasen til å gjennomgå all kode og sørge for at denne fulgte retningslinjene fra AirBnb styleguide (AirBnB styleguide, 2016), etter ønske fra oppdragsgiver. Ved å følge styleguiden har gruppen produsert kode som ser lik ut og er satt opp ryddig. Styleguiden var i seg selv lærerik og begrunnet hvorfor kode skulle skrives som den ble gjort. Vi har brukt variabel- og funksjonsnavn som er selvforklarende. Det gjør koden mer lesbar og forståelig for en person som ikke har arbeidet med koden i den grad vi har. Kravspesifikasjonen og dens rolle Kravspesifikasjonen skal fungere som en kontrakt mellom oppdragsgiver og oss studenter. Kravspesifikasjonen var med å danne omfanget av oppgaven. Kravspesifikasjonen fungerte som en rød tråd for oss og pekte oss i riktig retning av utviklingen. Spesielt i startfasen ble kravspesifikasjonen brukt mye for å fokusere på hva som var viktigst å få på plass først. Kravspesifikasjonen var fleksibel og kunne endres senere i prosessen, noe den også ble. Kravspesifikasjonen kan ses i sin helhet som vedlegg. Prioritert funksjonalitet Første prioritering var å få plukket opp dataene som ble sendt fra sensorene. Uten disse dataene på plass var det ikke mulig å videreutvikle applikasjonen. Etter at sensordata ble implementert fant vi et passende bibliotek for fremstilling av dataene i grafer. Det ble satt som krav at Bootstrap skulle brukes, så et enkelt brukergrensesnitt for testing ble satt opp i kombinasjon av Bootstrap og React komponenter. Endringer av kravspesifikasjonen Siden kravspesifikasjonen var relativt dynamisk stod gruppen og oppdragsgiver frie til å legge til ekstra funksjonalitet som vi mente var relevant for applikasjonen. Dette ble utført etter at kravene fra den originale kravspesifikasjonen var utført. For eksempel utvidet vi databasen til å inneholde koordinater til lokasjoner. På denne måten var det mulig å fremstille på et kart hvor lokasjonen befant seg. Dette ble gjort gjennom Google Maps sitt API. Utover i oppgaven var det mulighet for å jobbe mer med designen på applikasjonen. Oppgaven i seg selv hadde ikke fokus på design, allikevel ønsket vi å levere et produkt som skulle se bra ut. I siste del av utviklingsfase 2 ble det jobbet mye med å få en god og brukervennlig design på applikasjonen. 20

27 Prosessdokumentasjon Ikke implementert funksjonalitet Under møter med oppdragsgiver kom det frem at måten vi hadde løst det å fremstille data når det ikke var data ikke var tilfredstillende nok. Oppdragsgiver informerte om at det var høyeste prioritet og alle andre oppgaver måtte settes til side. Gruppen fikk ikke løst oppgaven slik oppdragsgiver hadde sett for seg, men kom med et alternativt forslag. I forlengelse av Google Maps APIet ønsket vi å benytte oss av et vær-api for fremstilling av live værdata. Dette ble diskutert i samarbeide med oppdragsgiver slik at det var felles konsensus om at dette var relevant for applikasjonen. Oppdragsgiver likte godt forslaget om et vær-api. Muligheter for å sammenligne sensordata med værdata kunne være ekstremt nyttig. Gruppen begynte å arbeide med implementasjonen av et vær-api men i slutten av utviklingsfasen skjønte gruppen at dette kom til å bli for komplisert og ta for lang tid. Konklusjon Det har vært spennende og utfordrende å jobbe med en såpass fri kravspesifikasjon. På den ene siden hadde vi strenge krav om hvordan data skulle fremstilles, men på den andre siden stod vi fritt til å velge den teknologien vi mente var best for å nå målet. Den originale kravspesifikasjonen ble utvidet med ekstra krav til funksjonalitet etter som oppgaver ble fullført. Funksjonaliteten satt i den originale kravspesifikasjonen ble innfridd, men noen punkter som ble lagt til senere utgikk. 21

28 Prosessdokumentasjon Avsluttende del Denne delen tar for seg hvordan oppgaven har fungerte for oss som gruppe og hvilke utbytte vi har fått gjennom prosjektperioden. Eget utbytte Alle i gruppen er enige om at vi har lært mye gjennom denne perioden. Noe av det som utpeker seg ekstra er det å jobbe med en oppgave over så lang tid. Tidligere har vi hatt noen større prosjekter igjennom skolen, men ikke i nærheten av hva denne oppgaven har krevd av oss. Det har vært utfordrende og spennende å jobbe for noen utenfor skolen med teknologibakgrunn. August fra Biogrid har lenge jobbet med utvikling og vi følte det som en realistisk smakebit på hvordan arbeidslivet kunne utarte seg da vi samarbeidet med Biogrid. Nytt for gruppen er også dette med dokumentasjon av slik karakter. Kommunikasjonen innad i gruppen har fungert bra. Vi har i tidligere prosjekter brukt Facebook som foretrukken kanal for kommunikasjon, noe som har fungert bra. Ved å bruke Slack har vi hatt en mer profesjonell kommunikasjon. Gjennom bruk av Slack har vi også fått hjelp av Meteor miljøet. Vi har fått hjelp og innspill ved å spørre i Meteor sin offisielle Slack kanal, noe som har vært veldig nyttig for oss. Teknologisk utbytte Før vi valgte oppgave var vi alle veldig motiverte og spente på hva slags oppgave vi skulle få jobbe med. Alle var enige om at siden vi skulle jobbe såpass lenge med denne oppgaven ønsket vi en oppgave som ikke bare var spennende og motiverende, men også en oppgave som var relevant for oss etter at skolen var ferdig. Meteor og React er teknologier som ikke har vært like lenge tilgjengelig som PHP og Java. Meteor var helt nytt for oss og tok tid å sette seg inn i all den tilgjengelige funksjonaliteten. Vi har parallelt med utviklingen av vår oppgave fulgt med på hvordan Meteor også har utviklet seg. Dette er naturligvis veldig vanskelig å gjette, men utifra hva vi har sett så blir Meteor og miljøet rundt Meteor bare større og større. i løpet av denne oppgaven har Meteor blitt oppgradert til 1.3 versjon og støtte for npm pakkehåndtering. React.js fremstår heller ikke som en døgnflue. For et år siden var Angular veldig i vinden og alle skulle ha utviklere som kunne det. I dag er det fler og fler jobbannonser som skriver at de trenger folk som kan React.js. I teknologiradaren til BEKK 2016 (BEKK Teknologiradar, 2016) er React fremhevet som noe av det heteste i år å utvikle front-end med. Vi er derfor veldig fornøyde med å ha jobbet med noe som er ettertraktet på arbeidsmarkedet. 22

29 Prosessdokumentasjon Hva kunne vært gjort annerledes Helt i startfasen da vi kom i kontakt med oppdragsgiver så vi for oss tett samarbeid. Det var snakk om møter hver uke og tett oppfølging. For oss som studenter er dette noe vi synes er svært viktig. Allerede tidlig i startfasen går det opp for oss at vi ikke kommer til å ha så tett oppfølging som forespeilet. Oppdragsgiver er veldig opptatt og har mange prosjekter i gang samtidig. Vi begynner å se ulempene med å jobbe med et så lite firma. Andre bekjentes grupper som skriver for større selskaper får bruke kontor, utstyr og har egne ansatte til å hjelpe de med prosjektet, mens vi sliter å få kontakt med vår oppdragsgiver. I utviklingsfase 2 drøftes dette med fullføring av oppgaver. Vi har ikke vært flinke nok til å jobbe med en oppgave om gangen. Oppgaver ble halvveis utført for deretter å bli lagt tilbake i backloggen og en annen ny oppgave me påbegynt. Dette gjorde at vi måtte gå tilbake til oppgaver for å fullføre dem. Dette stemte ikke overens med prinsippene om smidig utviklingen gjennom kanban. Sent i utviklingsfase 2 jobbes det en del med designet på applikasjonen og det går opp for oss at Bootstrap har blitt brukt for mye. Ferdig-generert CSS må overkjøres for å få det slik vi ønsker. Dette begynner å ta tid og blir mer komplisert enn det burde være. I sammenheng med dette skulle vi ha ønsket at vi benyttet oss av SASS. Både for å lære oss et nytt språk, men også for en enklere og mer effektiv utvikling av design. React-strukturen skulle ha blitt forandret. Dette går opp for oss for sent i oppgaven at dette er en struktur som ikke skalerer for vår applikasjon. Etter litt diskusjon i gruppen blir vi enige om at det ikke er tid til å omstrukturere applikasjonen. Applikasjonen vår fungerer som den skal, men måten det er bygget opp er ikke optimalt. 23

30 Prosessdokumentasjon Ord fra oppdragsgiver Studentene var veldig samarbeidsvillige og lydhøre, og var spesielt interesserte i å utforske Meteor, MongoDB, React og Docker. Jeg synes applikasjonen ble veldig bra, den løser oppgaven på en god måte, og med moderne webutviklings-teknologier. Et av problemstillingene rundt IoT-prosjekter er at mye data produseres, og at det kan være utfordrende å visualisere disse dataene på en hensiktsmessig måte. Studentene løste dette på en elegant måte ved hjelp av et open source rammeverk for fremstilling av grafer. Applikasjonen vil bli en integrert del av Biogrids videre satsing på et større rammeverk for IoT-baserte tjenester. Dette er en utvidelse av den opprinnelige ideen om kun å lage et system for bruk til innendørs dyrking av grønnsaker. - August Flatby 23/ Konklusjon Som gruppe er vi fornøyde med resultatet vi har levert inn. Vi har nådd våre egne personlige mål om å videreutvikle oss og lære nye programmeringsspråk. Vi leverer inn et produkt vi er stolte av og mer enn gjerne setter på vår CV. I tillegg har det vært hyggelig at Biogrid er veldig fornøyd med det endelige resultat og at det stod til over forventning. Gruppen har fungert godt gjennom hele prosjektet. Alle 3 kjente hverandre godt fra før av, men det er alltid spennende hvordan det skal bli når man går så tett på hverandre over lengre tid. Det har vært konflikter og uenigheter, men alle disse har blitt løst på en god måte i plenum med konstruktive argumenter og forsøk på å se den andre part sine argumenter. Oppfølgingen fra oppdragsgiver kunne helt klart vært bedre, men vi er allikevel fornøyde med det samarbeidet vi har hatt. Det har vært spennende å få et innblikk i hvordan en fremtidig arbeidssituasjon kan se ut. 24

31 III Produktdokumentasjon Bachelorprosjekt 2016 Høgskolen i Oslo og Akershus Gruppe 20

32 Produktdokumentasjon Forord Denne rapporten er skrevet for de som kunne tenke seg å videreutvikle og vedlikeholde applikasjonen. For videreutvikling kreves det også kunnskap om React.js, MongoDB, Docker, Node-RED og skysetting av webapplikasjoner. Det forutsettes kjennskap til Meteor-plattformen og generell CSS-, JavaScript- og databasekompetanse. 1

33 Produktdokumentasjon Innhold Forord 1 Produktet 3 Systemarkitektur 4 Installasjon for videreutvikling og lokal kjøring 5 Teknologi 6 Meteor React.js CSS og Bootstrap MongoDB Samsvar mellom produkt og kravspesifikasjon 9 Sentrale datastrukturer 10 Databasestruktur Filstruktur i Meteor Produktets oppbygging og virkemåte 14 Domenemodell for komponenter Publish og subscribe i Meteor Rendring i React Login Lokasjoner Kontrollpanel med underkomponenter Sammenheng mellom komponenter Subnavbar Metadata Hub Graf Skjermbilder med forklaring 28 2

34 Produktdokumentasjon Produktet Biogrid er applikasjonen som kundene til Biogrid vil benytte seg av. Her vil de få en oversikt over de forskjellige stedene de har, f.eks forskjellige gårder eller drivhus, og videre kan de klikke seg inn på hvert sted for å få en visuell oversikt over sensorene som er utplassert i form av grafer. Enkelt forklart er det ett kontrollpanel for sensorer der dataene blir visualisert for brukeren. I denne oppgaven er applikasjonen bygget opp med data fra jordbruk, men det er tenkt at kontrollpanelet skal være generisk mtp. hva slags sensordata som kommer inn. Den langsiktige planen for Biogrid Cortex innebærer også mulighet for automatisert styring og varsling gjennom maskinlæring og styring av enheter via signaler og aktuatorer. Applikasjonen skal være ett kontrollpanel for alle IoT-enheter. Applikasjonen er ment å fungere slik at kundene ikke trenger en innføring i hvordan den fungerer, men skal isteden være intuitiv og lett gjenkjennelig for liknende sider. Det vil derfor ikke være nødvendig med en bruksanvisning eller manual for brukerne. 3

35 Produktdokumentasjon Systemarkitektur Figur 1: Systemarkitektur BiogridCortex Figur 1 viser en oversikt over arkitekturen og infrastrukturen til Biogrid Cortex. Den bygger på fysiske sensorer som er utplassert hos kunder f.eks i deres innendørs vertikale jordbruk. Sensorene er koblet til mikrokontrollere som kommuniserer over WiFi eller Bluetooth LE og sender MQTT-meldinger til sky-servere levert av IBM Softlayer. Når MQTT-meldingene kommer til serveren blir de tatt imot av Mosquitto som er en MQTT-broker og blir videresendt til Node-RED der dataen blir prosessert og lagret i MongoDB collections som timeseries-data. Deretter vil Meteor-appen (applikasjonen) visualisere dataene med live-oppdatering 4

36 Produktdokumentasjon for kundene. Infrastrukturen på bildet er plassert i en docker-container og sikrer dermed at systemet vil kjøre likt uansett hvilket miljø det kjøres på. Det vil kjøre likt på en lokal Mac-/Linux-/Windows-maskin som på en skytjeneste som IBM Softlayer/Microsoft Azure/Amazon Web Services/Google Cloud. Denne infrastrukturen er det Biogrid som har laget og denne produktdokumentasjonen omhandler Meteor applikasjonen. Installasjon for videreutvikling og lokal kjøring Først må det benyttes riktig utviklingsmiljø. For korrekt oppsett må du clone/laste ned GitHub repositoryene Biogrid0.1 fra og Biogrid fra Begge repositoryene vil bli tilgjengelig under BiogridCortex, dermed vil det holde å laste ned kun det. Installer Docker fra Følg installasjonsguide gitt fra Docker for OS X eller Windows. Installer MongoDB fra For å kjøre applikasjonen må man gjennom 2 steg: Åpne Docker Quickstart Terminal. Naviger fram til der du har plassert mappen BiogridCortex og frem til filen cortex, f.eks /Users/JohnAppleseed/Biogrid/cortex. Start miljøet med en av kommandoene under: For å kjøre som daemon: docker-compose x-networking up -d For å kjøre i forgrunnen: docker-compose x-networking up For å stoppe: docker-compose stop For å starte meteor applikasjonen må du åpne ønsket kommandolinjeverktøy og navigere deg fram til biogrid0.1, f.eks Users/JohnAppleseed/Biogrid/biogrid0.1. Start applikasjonen med kommandoen: MONGO URL=mongodb:// :27017/biogrid meteor Dette kobler applikasjonen opp mot databasen som kjører i Docker-miljøet. Applikasjonen kan nå brukes i nettleser på addressen localhost:

37 Produktdokumentasjon Teknologi Meteor Meteor er en open-source plattform for utvikling av web-, mobil- og desktopapplikasjoner. Meteor bygger på JavaScript og er en full-stack plattform som inkorporerer alt fra database og fram til sluttbrukerens grensesnitt. Meteor lar deg utvikle i JavaScript for alle miljø; applikasjonsserver, web browser og mobile enheter. Meteor er laget slik at serveren sender data, ikke HTML, som klienten igjen kan rendre som HTML. Dette gjør det enklere å bygge en reaktiv nettside der dataene endrer seg gjennom tid fordi Meteor hjelper deg med å rendre komponentene automatisk så fort de underliggende data endres. Dette er fordelaktig i en slik web-app som Biogrid er. Server-siden er bygget på Node.js og bruker forskjellige JavaScript bibliotek for å håndtere den kontinuerlige dataflyten: Node.js - En javascript server. Connect - Ett bibliotek for å sende ut HTTP-svar fra en applikasjon. Database Driver (Mongo) - Et enkelt grensesnitt med MongoDB data. Livequery - Ett bibliotek bygget for å søke og strømme ut Mongo-data på en reaktiv måte. Fibers/Futures - Et wrapper-bibliotek for Node.js som gjør det synkront i ett forsøk på å redusere callback-problemer. Klient-siden, blir oversendt med minimal HTML og bare litt JavaScript som laster miljøet. Mye av koden er bygget på jquery og underscore.js som fundament. Mens serveren er synkron, er nettlesere og JavaScript asynkron av natur. Bibliotekene som gjør klientsiden reaktiv er: Tracker er ryggraden i den reaktive front-enden. Den er limet for ethvert tracker-avhengig bibliotek man bygger, f.eks React.js som brukes i applikasjon. Blaze er ett reaktivt bibliotek som er integrert i Meteor. Blaze er erstattet med React.js i vår applikasjon. Minimongo er en lettvektsutgave av MongoDB som kjører på klientsiden. Den synkroniserer data over DDP og lar klienten reaktivt konsumere MongoDBdata. Session-biblioteket lagrer reaktive grensesnitt-variabler. Kommunikasjonslaget er der bindingen mellom klient og server skjer. EJSON brukes for å serialisere og deserialisere dataene som blir sendt mellom server og klient. 6

38 Produktdokumentasjon EJSON bygger på JSON, men har utvidet funksjonalitet for å serialisere flere datatyper som f.eks Binary og Date. DDP (Distributed Data Protocol) er en protokoll for å sende data over websockets, også kjent som REST for websockets. Meteor har ett genialt pakke-system der det finnes p.t. over pakker som Meteor-miljøet har laget. I tillegg er det mange pakker som er laget av Meteor Development Group. Her finnes det pakker for veldig mye forskjellig. De pakkene vi har benyttet oss av er: reactjs:react - Integrerer React rammeverket på klient og server. kadira:flow-router - Integrerer klientside-routing for Meteor. kadira:react-layout - Integrerer React rendering i routing. twbs:bootstrap - Integrerer Bootstrap rammeverket i Meteor. fortawsome:fontawesome - Pakke for ikoner. aldeed:simple-schema - Pakke for å validere databasestruktur. aldeed:collection2 - Pakke for å knytte aldeed:simple-schema til databasen. accounts-password - Integrerer en innloggingsservice. dburles:google-maps - Integrerer Google Maps API i Meteor. rajit:bootstrap3-datepicker - Integrerer datovelger i Meteor. De inkluderte pakkene kan ses i filen packages i.meteor-mappen i mappestrukturen for applikasjonen. React.js React er et JavaScript-bibliotek laget av Facebook for front-end utvikling. Målet med React var å lage ett bibliotek for applikasjoner der dataene endres over tid. Dette passer godt for vår oppgave da vi får inn en konstant strøm av sensor-data som skal oppdatere brukergrensesnittet og grafene. React baserer seg på bruk av komponenter. Dette er gjenbrukbare deler av brukergrensesnittet, tenk på det som byggeklosser. En komponent kan f.eks være Google Maps som vi bruker i oversikten over kundenes steder. Map-komponenten blir rendret av en annen komponent som heter Site. Denne site-komponenten skal visualisere alle stedene til en bruker. Et annet eksempel på komponent er grafen som reaktivt oppdaterer seg basert på den underliggende dataflyten. Hver sensor har en graf-komponent tilknyttet seg og hvert sted har n-antall grafer som blir rendret. 7

39 Produktdokumentasjon En komponent kan også sees på som en viewcontroller, da den både rendrer viewet og har nødvendige controller-funksjoner og businesslogikk. CSS og Bootstrap CSS er et språk som er brukt for å definere utseende på HTML-kode. Det er enkelt å få et helhetlig utseende på en nettside ved bruk av CSS. Bootstrap er et CSS-rammeverk som er utviklet av Twitter og har i lang tid vært svært utstrakt. Bootstrap har ferdiglagde komponenter man kan benytte seg av for å få et helhetlig utseende på nettstedet. Alt fra forskjellige ikoner, knapper, menyer og responsivt design hjelper Bootstrap deg med. Bootstrap bruker et grid-system som bygger på en bredde på 12 kolonner. Figur 2 viser hvordan grid-systemet er brukt. Det er satt at kundens sites vil vises i kolonner med bredde på 6 som gir plass til 2 sites pr. rad på en vanlig skjerm, mens på mobil har hver site en bredde på 12 og vil dermed fylle hele bredden. Tanken er at det skal være enkelt å plassere komponenter i forhold til hverandre uten å måtte bruke mange CSS-triks som padding og margin for å få det til å se bra ut. Figur 2: Eksempel på kolonnesystemet i Bootstrap MongoDB MongoDB er en open source database som bruker en fleksibel dokument-orientert datamodell som er oppbygd likt som JSON-objekter. Dokumentene inneholder ett eller flere felt, inkludert arrays, binære data og sub-dokumenter. Feltene og strukturen kan variere fra dokument til dokument. Denne fleksibiliteten gjør at utviklere kan la datamodellene endre seg over tid uten de problemene som man ofte støter på i en tabell/rad modell i en vanlig relasjonsdatabase. Endringer i en vanlig relasjonsdatabase ville krevd større endringer enn i en dokument-orientert database. Da vi f.eks skulle legge til felt for latitude og longitude i databasen bød ikke det på noen problemer, det gikk kjapt og var oppe og kjørte i løpet av ett minutt. Det er med andre ord raskt å iverksette endringer og tillegg av ny funksjonalitet uten å redesigne hele databasen. En annen fordel ved bruk av en dokument-orientert datamodell som MongoDB er at den er bygget for skalering, enten i ett datavarehus eller i skyen. MongoDB er bygget for hurtig horisontal skalering som betyr at det er enkelt å distribuere data på tvers av mange serverparker. MongoDB støtter tusenvis av noder, petabytes med data og tusenvis av operasjoner i sekundet uten at du må bygge egne partisjons- og cachelag. 8

40 Produktdokumentasjon Sikkerhet er også en viktig del av databaser, og det er selvsagt bygget inn robuste autentisering, autorisering og krypteringsprotokoller for å beskytte sensordataene dine. Samtidig er det f.eks ikke mulig med sql-injection i MongoDB. Samsvar mellom produkt og kravspesifikasjon Kravene satt i kravspesifikasjonen i samarbeid med oppdragsgiver har blitt innfridd. Som det har blitt dokumentert i både kravspesifikasjonen og prosessdokumentasjonen har gruppen stått ovenfor en ganske åpen kravspesifikasjon. Gruppen hadde senere ønske om å legge til mer funksjonalitet i samarbeid med oppdragsgiver. Det ble enighet om å bruke Google Maps til fremstilling av lokasjoner. Det ble også diskutert på et av de siste møtene med oppdragsgiver muligheten for å bruke seg av et API for fremstilling av live værdata. Aktuelle API var YR.no eller Metrologisk institutt. Begge parter var positivt innstilt på dette, men det ble ikke implementert. Det ble ikke implementert grunnet for lite tid til å sette seg inn i APIene og i tillegg var det ikke regnet som viktig funksjonalitet å ha med i det endelige produktet. Et av kravene fra oppdragsgiver var at det skulle brukes et bibliotek for fremstilling av grafer. Valget falt på Dygraphs.js da dette leverte det kravspesifikasjonen krevde. Dygraphs er både open-source, mulig å zoome i og har mye ekstra funksjonalitet. Samtidig er dygraphs godt dokumentert. En bruker skal kunne logge seg inn: Implementert brukerkontoer ved hjelp av pakkene useraccounts-ui og useraccounts-password fra Meteor. Bruker skal kunne se oversikt over sine lokasjoner ved hjelp av kart: Når man logger inn får man opp alle sine registrerte steder ved hjelp av et kart fra Google Maps. Bruker skal kunne velge å se data for ønsket lokasjon: Kartet er klikkbart og vil sende bruker videre til kontrollpanelet der data vises. Bruker skal kunne zoome i en graf for å avgrense og se mer detaljert visning av data: Dygraphs er implementert og det er lagt til zoom-funksjon. Bruker skal kunne velge hvilket tidsintervall det skal vises data for: Det er lagt til funksjon for å se i dag, siste 7 dager, siste måned og en egendefinert dato-velger for å få opp data i grafene fra valgt tidsrom. 9

41 Produktdokumentasjon De ikke-funksjonelle kravene og rammebetingelsene har også blitt innfridd. Kravspesifikasjonen kan ses i sin helhet som vedlegg. Sentrale datastrukturer Databasestruktur Den mest sentrale datastrukturen applikasjonen har ligger i databasen. Den består av flere collections, som det heter i MongoDB. Vi har collections for Firmware, Hubs, Readings, Sensors, Sites, Things og Users. I figur 3 kan man se hvordan de er koblet sammen. Figur 3: Databasestrukturen i MongoDB Det er laget slik at en bruker kan ha ett eller flere steder. En eier er ikke lagret med oversikt over sine sites, men en site har en eierid som kobler site til rett eier. Hver site har en eller flere hub er, og en hub er koblet til en site ved å ha siteid lagret. Hub er koblet til en firmware ved å ha lagret firmwareid. En hub kan ha flere tilhørende sensorer. En sensor kan kun være tilknyttet én hub og dette skjer ved at sensoren har lagret en hubid. En sensor hører til en ting ved at thingid er lagret i sensor og en reading hører til en sensor ved at reading vet om sensorid. Det er i readings-collection den mest interessante datastrukturen for prosjektet er og vi skal se nøyere på det nå. Figur 4 viser hvordan en reading-collection ser ut og key/value parene forklares slik: 10

42 Produktdokumentasjon id: Unik id for ett reading dokument. day: Datoen avlesningen ble foretatt. Ett reading-dokument gjelder for en dag fra klokkeslett 00:00:00 til 23:59:59. sensorid: Den tilhørende sensorens unike id. values: Dette objektet inneholder all data som sensoren har produsert. Det er bygget opp slik at det første objektet er timen. I dette tilfellet 9, dvs kl. 09. For hver time har man ett objekt pr. minutt og inne i hvert minutt har man key/value par med selve avlesningen der key er hvilket sekund det gjelder og value er avlesningen. På figur 4 ser man at kl. 09:56 var det avlesninger hvert 5 sekund og kl. 09:56:40 var avlesningen på Figur 4: Reading collection i MongoDB Løsningen for strukturen ble laget med inspirasjon fra den offisielle MongoDBbloggen (MongoDB, 2014). Dette er en struktur som skalerer bra og hvis man f.eks skal hente data fra en dag, 24 timer, så henter man ett dokument pr. sensor. Skulle det bli gjort i en vanlig relasjonsdatabase ville man måtte hente felt pr. sensor hvis man regner med at det er data for hvert sekund som skal hentes. I tillegg er innsetting av data kjappere da vi kun oppdaterer values -objektet istedenfor å kjøre en insert-spørring hver gang data kommer inn, noe som totalt sett er en meget effektiv måte både for å tilføre og å hente ut data fra databasen. 11

43 Produktdokumentasjon Figur 5: UML representasjon av databasen Figur 5 viser databasemodellen. Det som er interessant å merke seg her er at den dokument-orienterte databasen ikke bruker tilknytningstabeller som en vanlig relasjonsdatabase gjør. I stedenfor refererer man til feltene i dokumentene fremfor å ha en fysisk relasjon. Som eksempel ser man at feltet siteid i hubs refererer til id til en site. 12

44 Produktdokumentasjon Filstruktur i Meteor Meteor har ingen fasit man må følge eller strenge regler for å sette opp filstrukturen, men det er visse måter de forskjellige mappene fungerer på. Figur 6 viser den overordnet mappestrukturen for applikasjonen. Figur 6: Filstruktur i Meteor.meteor er en mappe som inneholder pakke-, versjon-, og plattform-informasjon og lages automatisk når man starter et prosjekt. public inneholder typisk bilder og favicons. Bakgrunnsbildet for login-siden og 404-not found bakgrunnsbildene ligger her. lib er den første mappen som blir kjørt når applikasjonen starter og inneholder filer som kan kjøres både på klient- og serversiden, men ikke all kode er ment å kjøre begge steder. Løsningen er en if-setning med betingelsene isclient og isserver i fil for å definere hvor kode skal kjøres. Mappen inneholder også filen for routing. server inneholder filer som kun kjøres på server. client inneholder filer som kun kjøres på klient. Mappen er igjen delt opp i tre mapper: components, script som inneholder fil for å laste inn dygraphs biblioteket og stylesheet som inneholder egendefinert stilark. Components har den dypeste strukturen og hver komponent har sin mappe. Hver komponent inneholder nødvendig kode for å subscribe på data, businesslogikk og rendring. Det er viktig å merke seg to ting med filstrukturen i Meteor: 1. Mapper har visse betydninger knyttet til dem. 2. Man må ikke bruke denne mappestrukturen, men det er en praktisk måte å lagdele filstrukturen på. 13

45 Produktdokumentasjon Produktets oppbygging og virkemåte I dette punktet vil vi gå side for side gjennom appen og forklare hvordan de forskjellige komponentene samhandler og lager en fungerende applikasjon. Viktige funksjoner vil bli forklart og skjermbilder for å illustrere sidene og funksjonene vil bli lagt ved. Domenemodell for komponenter Figur 7: Domenemodell for React-komponentene 14

46 Produktdokumentasjon Publish og subscribe i Meteor Når en klient skal hente data fra server-siden benyttes Meteor sine publish- og subscribe-funksjoner. Se for deg scenariet at vi, klienten, ønsker å hente data om alle hub ene som finnes i en site. Man setter da opp en publish-funksjon på serversiden som tar inn en site-id som argument som figur 8 viser. Figur 8: Publish funksjon på server som tar inn siteid som argument På denne måten sikrer vi at vi kun sender relevant data om gitt site, ikke data fra alle sites. Tilsvarende har vi på klient-siden en subscribe-funksjon som sender med argumentet siteid. Figur 9: Subscribe funksjon på klient som tar inn siteid som argument Da er vi helt sikre på at vi kun henter korrekt data basert på hvilken site vi er inne på. Når dataen er hentet over på klient-siden kan vi filtrere på forskjellige kriterier. For en reading kan det velges å filtrere data mellom to tidspunkt, f.eks mellom kl. 10 og 12 ved hjelp av følgende kode på klienten: Figur 10: Filtrerer data for tidspunkt større enn eller lik kl.10 og mindre enn eller lik kl.12 Det samme gjelder når vi skal hente readings fra en sensor: 15

47 Produktdokumentasjon Figur 11: Publish og subscribe for readings Publish og subscribe sørger for dataflyten mellom klient og server. Som nevnt tidligere sendes det data og ikke HTTP, noe som gjør det enklere å kode, men man skal allikevel ha full kontroll på alle publish-funksjonene for å sikre at man ikke sender for mye, unødig eller data som ikke burde bli sendt over. Ett tilfelle på feil som kan oppstå hvis man ikke har gjort dette riktig er f.eks at en kunde kan få oversikt over andre brukeres steder og sensor-data. Vi brukte mye tid på å sikre at vi får korrekt data da dette er ett viktig sikkerhetsaspekt ved appen. Det var også en ny måte å tenke på for oss og vi er meget fornøyde med måten dataen flyter mellom server og klient. Rendring i React En React komponent krever en metode som heter render og uten metoden vil ikke komponenten fungere. Hver komponent i applikasjonen undersøker sine properties eller states for å rendre en HTML div-tag med innholdet fra dem eller den kan rendre en ny komponent. Render er skrevet ren, noe som betyr at funksjonen ikke endrer en state komponenten befinner seg i eller på noen måte leser eller skriver til nettleserens DOM. Figur 12 er et eksempel der det blir rendret en div som inneholder en ny Reactkomponent. Figur 12: Render-funksjon som rendrer en ny React-komponent 16

48 Produktdokumentasjon Login Det første brukeren møter n ar man g ar til applikasjonen er login-vinduet vist i figur 13. Figur 13: Skjermdump login Med flow-router pakken som er benyttet for routing kan man sette opp routinggrupper som kan ha egne regler. Applikasjonen er satt opp med en privat gruppe der det først blir sjekket om en bruker er logget inn for for a begrense tilgang til sider, hvis ikke blir man omdirigert til login-siden. Oversikt over stedene og selve kontrollpanelet inng ar i den private gruppen. Login og logout foreg ar i en public gruppe. Login-vinduet best ar av en login-komponent som blir rendret av routingen. G ar man til root ( / ) av applikasjonen og ikke er logget inn vil denne siden bli rendret, hvis man allerede er logget inn vil man bli routet til Site. Funksjonalitet som er verdt a merke seg p a denne komponenten er at den gir relevante tilbakemeldinger til brukeren basert p a eventuelle feil. Hvis man f.eks har tastet inn ett brukernavn som ikke finnes f ar brukeren beskjed om dette i ett felt som glir ned under login-knappen med teksten User not found. Hvis man begynner a skrive inn nytt brukernavn glir feilmeldingen bort og man kan prøve p a nytt. Det samme skjer hvis man har tastet feil passord, da blir feilmeldingen Incorrect password vist. N ar man har tastet riktig brukernavn og passord vil man bli routet videre til site, som er visningen av kundens forskjellige steder. Funksjonen som tar seg av dette heter handlesubmit og ligger i login.jsx. Funksjonen blir kalt n ar brukeren trykker p a login-knappen og da blir feltene for brukernavn og passord hentet inn og metoden Meteor.loginWithPassword blir kjørt. Hvis en error er registrert vil grunnen til at man ikke f ar logget inn vises, f.eks incorrect password, hvis alt er i orden blir man logget inn og man blir sendt videre til Site-siden. 17

49 Produktdokumentasjon Figur 14: Sekvensdiagram for login Hvis det er ønskelig å utvide applikasjonen er det enkelt å implementere funksjonalitet som f.eks. registrering av ny bruker med bekreftelse av e-post adresse og glemt passord. 18

50 Produktdokumentasjon Lokasjoner Figur 15 viser et skjermdump av hvordan oversikten over brukerens tilgjengelige steder ser ut. Figur 15: Skjermdump lokasjoner På dette viewet er det 3 forskjellige komponenter som blir benyttet. Først og fremst er det Site-komponenten som er parent-component. Det betyr at det er site som er hoved-komponenten som igjen rendrer navbaren og hver av map-komponentene. Først blir navbar-komponenten rendret og deretter blir en liste av alle steder rendret av map-komponenten. Denne sekvensen ser man i figur 16 på neste side. Dette skjer slik i en site-komponent: Først kjøres en subscription på site-collectionen som returnerer alle stedene som tilhører brukeren. Deretter mappes det gjennom alle stedene og hver av de 3 stedene i figur 15 blir dynamisk opprettet av egne maps-komponenter. Hver av mapkomponentene får med seg latitude og longitude properties for stedet og blir til slutt rendret i bootstraps kolonne system. Denne fremgangsmåten gjør at det vil se korrekt ut enten det er 1 eller 1000 forskjellige steder. Samtidig vil det vises en tekst med Sorry, no sites available at this time! hvis det ikke er noen sites tilgjengelig. Denne meldingen blir laget av nodatamessage-komponenten som får inn strengen sites som property. Denne komponenten brukes også hvis man ikke har noen sensorer registrert på en site. 19

51 Produktdokumentasjon Figur 16: Sekvensdiagram for visning av site I render-funksjonen til site.jsx mappes det gjennom dataene fra subscriptionmetoden som ble kalt tidligere i komponenten. Den lager lenker og oppretter mapkomponenter, men hvis dataene ikke er klar eller det ikke er noe data tilgjengelig lages det en nodatamessage-komponent i stedenfor en map-komponent. Kartene er satt til å ikke være interaktive, det vil si at du ikke kan zoome, scrolle eller manipulere kartet. Dette fordi vi ønsker at hele komponenten skal være mulig å klikke på som en stor link slik at man kommer videre til valgt sted. I tillegg er kartet konfigurert med egne farger, vi har satt en størrelse på zoomen og det er fjernet informasjon som kommer automatisk når man generer ett kart. F.eks er labels for kollektivtransport, points of interest og veinummer fjernet da det gir ett mer helhetlig og ryddigere design, samtidig som det gir følelsen av at kartet passer med fargevalget på resten av siden. Dette skjer i funksjonen mapoptions i map.jsx og det er her vi kan tilpasset kartene til å se ut slik vi vil. 20

52 Produktdokumentasjon Kontrollpanel med underkomponenter Sammenheng mellom komponenter Klikker man på et av kartene blir man videresendt til kontrollpanelet i figur 17 for valgt sted. Kontrollpanelet består av 8 forskjellige komponenter. Parentkomponenten dashboard er den som orkestrerer rendringen av alle de andre komponentene. Dette er en komplisert prosess der data skal hentes fra forskjellige collections og data skal sendes mellom komponentene etter hvert som de blir rendret. Figur 17: Skjermdump kontrollpanelet Som sagt er det snakk om en god del forskjellige komponenter som benyttes i forbindelse med dashboardet, og her er en oversikt over de som brukes: Dashboard - subscriber på hubs og rendrer navbar, subnavbar, metadata og en liste av alle hubs. Navbar - Navigeringsmenyen øverst på siden. Inneholder informasjon om innlogget bruker, dette gjøres ved hjelp av Meteor sin user-funksjon. Subnavbar - Ekstra navigeringsmeny med utvidet funksjonalitet for datovalg og valg av sted. Subscriber på sites. Denne rendrer også komponenten customrange. CustomRange - Komponenten som sørger for all funksjonalitet knyttet til datovelgeren i subnavbaren. Metadata - Komponent for å vise nyttig informasjon i små bokser. Hub - Har som oppgave å rendre parentgraph-komponenten. Subscriber på sensors-collection. ParentGraph - Subscriber på things og readings for gitt sensor. Rendrer graph-komponenten. 21

53 Produktdokumentasjon Graph - Tegner hver av grafene. NoDataMessage er en niende komponent som brukes hvis det ikke er noen sensorer/hubs knyttet til ett sted og gir en tilbakemelding til brukeren om dette. Figur 18: Organisering av komponenter i dashboard Gangen i oppsettet til dashboard-komponenten kommer frem av figur 18. Komponenten rendrer seg selv med navbar-, subnavbar-, metadata- og hub-komponenter. SubNavbaren rendrer seg selv med en customrange-komponent. Dashboardet rendrer metadata-komponent med forskjellig innhold. Hub rendrer seg selv og en parentgraph som igjen rendrer graph. Hvis ingen hubs finnes vil en NoDataMessagekomponent rendres istedenfor en hub. I figur 19 ser man forskjellen på om en site har registrerte hubs og sensorer knyttet til seg eller ikke. I render-funksjonen i dashboard.jsx blir det sjekket hvor mange hubs det blir subscribet på, er det 0 stykk så rendres komponenten nodatamessage med propertiet hubs, hvis antallet er større enn 0 mappes det gjennom alle dataene og lages enn hub-komponent pr. hub. Figur 19: Skjermdump av applikasjon når ingen hubs er tilgjengelige. 22

54 Produktdokumentasjon Subnavbar Det er naturlig å se på subnavbar og customrange i ett da customrange er en child-component av subnavbar. Funksjonaliteten i navbaren er å lage en nedtrekksmeny med alle tilgjengelige steder og muligheten til å velge mellom ferdigkonstruerte tidsintervaller eller en dato-velger der du selv velger tidsintervallet for data-visning. For å hente alle steder må subnavbar subscribe på sites og så mappe igjennom disse for så å lage lenker til disse i nedtrekksmenyen vist i figur 20. Figur 20: Nedtrekksmeny i subnavbar Dette skjer i render-funksjonen til subnavbar.jsx. Her mappes det igjennom alle sites vi subscribet på. Når det mappes gjennom henter vi ut stedsnavn og id og lager en link som er /dashboard/id f.eks /dashboard/68zxbszl65z, mens navnet på linken er som du ser over, f.eks Green Sense Oslo. CustomRange har ikke behov for å subscribe på noen collections da alt som foregår her er å endre datointervallet for dataene som vises. Derimot er det ingen enkel jobb å endre intervallet. Først av alt når du kommer inn på kontrollpanelet er det satt at dagens data er det som skal vises. For å vise datoene og dato-velgeren ble det valgt å benytte ett bibliotek som heter bootstrap-datepicker. (Bootstrap Datepicker, udatert) Denne ble stylet i CSS for å fremstå helhetlig med resten av designet. Ett av problemene med visningen av datoer var at datoen som hentes fra databasen til en reading var en tekststreng, mens datoen som brukes i dato-velgeren er ett Dateobjekt. Det trengtes derfor formatering av streng- og dato-objektet for å få de til å samsvare. Formateringen ble løst ved å lage funksjonen getrequesteddate der funksjonen får inn et date-objekt for så å formaterere det til en streng. Det blir lagt til en 0 før datoer som ikke har 2 siffer og det blir lagt til bindestreker for 23

55 Produktdokumentasjon Figur 21: Datovelger å få det til å samsvare med strengene i databasen og vi henter ut hele årstallet istedenfor å bruke 2 siffer. F.eks vil dato-objektet 2-January-16 bli formatert til Ett annet problem var hvordan vi skulle få grafene til å endres basert på hva man trykket på av datoer. Løsningen ble å legge valgt fra- og til dato i ett Sessionarray som da de forskjellige komponentene enkelt hadde tilgang til. Det ble brukt mye tid på å få datovelgeren til å være reaktiv basert på knappene Today, Last 7 days og Last month. Når man trykket på en av disse måtte det lages ett nytt Date-objekt som så ble sendt inn i dato-velgeren og oppdaterte tekstfeltene og de valgte datoene. Dette ble gjort med jquery og bootstrap-datepicker sine innebygde funksjoner update og changedate. Uten dette ville ikke datoene bli endret til å samsvare med f.eks dagens dato eller de siste syv dager. Det ville heller ikke blitt vist valgt fra- og til dato i dato-velgeren. Til slutt var det å få kalendrene til å reagere som ønsket. Det er en kalender for fra-dato og en for til-dato. Når fra-dato er valgt skal den lukkes, og du skal få opp kalenderen for å velge til-dato, og når du har valgt til dato må man kalle en funksjon som setter datoene i Session-arrayet slik at grafene kan være reaktive og endres. Det skal ikke være en ekstra knapp for å søke på valgte datoer, det skal bare endres så fort 2 datoer er valgt, og dette ble sett på som den smidigeste løsningen for brukerne. Det ble laget egne funksjoner for å hente dagens dato, de siste syv og siste måneds dato samt en egen funksjon for å hente den egenvalgte datoen. Det som skjer i disse forskjellige funksjonene er at CSS-en til streken under knappene blir endret til å gjenspeile hvilken knapp som er valgt. Deretter blir det laget to datoobjekter, ett for dagen i dag og ett for fra-datoen. Figur 22 viser hvordan datoene i getmonth-funksjonen blir satt før de formateres med getrequesteddate-funksjonen og session-arrayet med datoene settes. 24

56 Produktdokumentasjon Figur 22: Hvordan fra-dato blir satt i datovelgeren. Funksjonen som kaller på disse funksjonene heter handlebuttonclicks og er bygget opp med en switch-case som kaller riktig metode ettersom hvilken knapp som blir trykket på. Metadata Videre i kontrollpanelet har vi metadata-komponenten. Her er det hardkodet antall sensorer, Things og Celsius, mens antall hubs hentes fra collection. Grunnen til dette omtales i prosessdokumentasjonen. Det er ingen logikk som skjer i metadata utenom rendring av HTML-kode og henting av properties for å vise antall hubs. Hub Hub-komponenten er den neste som blir rendret av dashboardet. Denne subscriber på sensor-collection og sender med sin hubid for å hente riktige sensorer. Deretter mappes det gjennom sensor-dataene og det blir rendret parentgraph-komponenter som får med propertiene sensor. id, sensor.thingid og sensor.graph. I tillegg er det i hub-komponenten at fade-in overgangen ved bruk av Reacts animasjonskomponent lages. Figur 23: Animasjon ved hjelp av React Graf ParentGraph-komponenten subscriber på readings- og things-collection, og den benytter seg av session-arrayet som customrange skriver til. Så fort subscribe er ready, dvs at all data er hentet, så vil parentgraph filtrere ut readings-dataene til å kun omhandle valgte til- og fra-datoer reaktivt. Deretter vil den rendre en Graph-komponent der den sender med 4 properties; selve readingen, hvilken farge grafen skal ha, hvilken type graf og beskrivelse av tingen den hører til. Til slutt kommer graph-komponenten. Som nevnt i prosessdokumentasjonen ble det brukt lang tid på å løse koden på hvordan dataene skulle leses igjennom. I 25

57 Produktdokumentasjon Figur 24: Graph komponent figur 25 ser du hvordan dataene fra propertien reading blir traversert. Figur 25: Løkke som traverserer data for en reading Denne algoritmen benyttes for å lese igjennom dataene i readings-collection for en sensor sin reading for en dag. Den returnerer en streng som grafbiblioteket dygraphs.js trenger for å tegne grafen. Under i figur 26 ser man hvordan strengen blir benyttet av dygraphs for å tegne grafene. 26

58 Produktdokumentasjon Figur 26: Dygraph bruker strenger for å tegne grafene. Det er flere interessante funksjoner i graph.jsx: isempty tar inn ett objekt og gjør flere tester for å se om objektet er tomt eller ikke og returnerer en boolean verdi. isobjectmorethanoneday benyttes for å finne ut om dataene som er hentet er for en eller flere dager. Grunnen til at denne trengs er at algoritmen som benyttes for å tegne grafen må være litt annerledes basert på lengden på dataene. Derfor har vi metodene writegraphstringseveraldays og writegraphstringone- Day som vist over. I funksjonen creategraph sjekkes det først om sensordataene er tomme med funksjonen isempty, hvis så er tilfellet lages det et custom grafobjekt med teksten no data available og utseende er tweaket for at det skal skille seg ut fra de grafene som har data. Det ble valgt å ha en slik tom graf slik at brukeren får et realistisk bilde over de forskjellige sensorene sine. Hadde vi utelatt å tegne en graf i det hele tatt kunne det oppstått situasjoner der en kunde trodde han hadde f.eks 10 sensorer, mens det bare vises en. Dette mener vi ville skape en uoversiktelig oversikt. Hvis det derimot er data tilgjengelig sjekkes det så om dataene er for en eller flere dager og riktig algoritme blir benyttet. Etter dette vil dygraphs-objektet bli laget som vist i figuren over og det blir rendret i render-funksjonen. 27

59 Produktdokumentasjon Skjermbilder med forklaring Figur 27: Tilbakemelding p a feil passord I figur 27 ser man hvordan login gir relevant tilbakemelding til bruker om feil passord er tastet. 28

60 Produktdokumentasjon Figur 28: Tilbakemelding p a feil brukernavn, mobilskjerm I figur 28 ser man hvordan login gir relevant tilbakemelding til bruker om brukernavnet som er tastet ikke eksisterer. Her er det ogs a vist hvordan siden skalerer til mobiltilpasset størrelse. 29

61 Produktdokumentasjon Figur 29: Visning av brukerens steder I figur 29 gis brukeren en oversikt over sine steder som er registrert. Hver av de mørke boksene med kart er klikkbare, og klikker man på de blir man videresendt til kontrollpanelet for valgt sted. 30

62 Produktdokumentasjon Figur 30: Visning av brukerens steder, mobilskjerm Figur 30 viser hvordan visningen av kundens steder blir framstilt på en mobilskjerm. På en mobilskjerm er det naturlig å legge stedene i en enkel kolonne som kan scrolles opp og ned istedenfor å ha to steder i bredden. 31

63 Produktdokumentasjon Figur 31: Kontrollpanelet med sensorer Figur 31 viser hvordan kontrollpanelet for ett gitt sted ser ut. Her har man subnavbaren-komponenten der man kan velge mellom de forskjellige stedene og customrange-komponenten som lar brukeren velge tidsintervallet på dataene som vises. I figur 31 ser man at dette stedet har 3 sensorer tilknyttet seg der 2 av de har data, mens den tredje ikke har tilgjengelig data. Figur 32 viser hvordan ett sted vises når ingen av sensorene har noe tilgjengelig data. Figur 32: Kontrollpanelet med sensorer uten data 32

64 Produktdokumentasjon Figur 33: Zoom-funksjon Figur 33 viser hvordan zoom-funksjonen fungerer. Grafen til venstre har ingen zoom, men på grafen til høyre er det zoomet inn på tidsrommet fra ca. 19:40 til 23:30. Brukeren har her markert tidspunktet 20:38:27 ved å holde musen over og får da opp en informasjonsboks som inneholder tid og dataverdi. Grafen til høyre viser hvordan grafer ser ut der det ikke er datapunkter tilgjengelig ved at linjen ikke blir tegnet. 33

65 Produktdokumentasjon Figur 34: Kontrollpanelet uten hubs Figur 34 viser hvordan kontrollpanelet ser ut på ett sted der det ikke er noen hubs og derfor ingen tilhørende sensorer. Figur 35: Datovelgeren på kontrollpanelet Figur 35 viser hvordan datovelgeren ser ut på kontrollpanelet. Når en fra-dato er valgt lukkes kalenderen og en ny åpnes slik at man kan velge til-dato. Når man har klikket på en til-dato oppdateres kontrollpanelet automatisk og viser dataene for valgt dato. 34

66 Produktdokumentasjon Figur 36: Kontrollpanelet med sensorer, mobilskjerm Figur 36 viser hvordan kontrollpanelet ser ut på en mobilskjerm. På samme måte som på listen over steder i figur 30 er grafene plassert i en enkel kolonne for å gjøre det oversiktelig på en mobil. 35

67 Produktdokumentasjon Figur 37: Eget design på menyen på mobilskjerm Figur 37 viser hvordan designet på menyen er tilpasset mobilskjerm. Man har fortsatt de samme valgene og mulighetene som i fullskjermsvisning, men layouten er tilpasset mobil. 36

68 Produktdokumentasjon Figur 38: Datovelgeren på mobilskjerm Figur 38 viser hvordan datovelgeren ser ut på mobil. Det er samme komponent som i figur 35, og man ser at den skalerer bra til mobilskjerm. 37