Bachelorprosjekt 2015

Transkript

1 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951)

2 Prosjektdagbok Dagbok gir leseren innblikk av hvordan vi har jobbet gjennom prosjektet. Referater er merket med dag/dato vi hadde møter. Diskusjoner vi hadde via facebook/epost er i tillegg som ikke var nødvendig å gi plass i dokumentet Hele gruppen møter for første gang, blir kjent med hverandre og snakket om de ulike kunnskaper og kompetanser vi hadde. Planlegging av hvordan det skal jobbes, planlegge faste dag/dager for møter osv. Diskusjon om hvilke oppgaver vi kunne tenke oss å velge, og hvilke firmaer vi hadde lyst til å jobbe hos Gruppen ble enig om hvem som skal være gruppeleder og registrere gruppen offisielt hos HIOA. Vi startet med å sjekke hioa sitt forslag til prosjektet. Vi kontaktet blant annet fiskeriportalen og TurboDevs. Vi avtalte møte med Turbo devs og samlet inn våre karakterutskrifter og CV er, med tanke på at noen oppdragsgivere kan være interessert i å se på Idag hadde vi møte med Turbo dvs. Alle ble enige om å møte opp på skolen 1 time før møtet. Vi forberedet oss for møte. Vi ble fortalt nærmere om hva prosjektet gikk ut på. Den oppgaven gikk ut på universell utforming som skal i grunn støtte et nytt språk, bliss språket. Det var ingen konkret oppgave de hadde og vi hadde derfor litt vanskelig med å forstå hva de egentlig ville ha. Av den grunn valgte vi å lete videre, hos andre oppdragsgivere. Å få en intern oppdragsgiver fra skole har alltid vært tema i møtene våre, men den muligheten vil vi helst benytte oss av etter at vi har letet etter oppdragsgiver på egenhånd først Etter de møtene vi tok tidligere bestemte vi oss for å bruke litt tid på å bli kjent med ulike programmeringspråk, som vi ikke var kjent med fra før. Eksamene var i gang og alle i gruppen hadde mye annet å forholde seg til enn prosjekte. Det ble derfor langpause mellom forrige og dagensmøte. Idag ble vi enige om å lage gruppens hjemmeside og opprette Facebook gruppe for å effektivisere kommunikasjon blant gruppe. Videre diskuterte vi mulige oppdragsgivere og sendte mail til blant annet Telenor, CapGemini, Netcom, Fiskeportalen og Knowit. Vi fikk 1

3 positive svar fra Fiskeportalen, CapGemini og Knowit. KowIT som vi alle i gruppa var veldig positive til, ville høre om hva vi ønsket ang. prosjektet. Så det blir møte med dem på 26 november Først hadde vi møte med Knowit. Vi ble kjent med bedriften og kontaktperson vår, som skal også være leder for prosjektet, hvis vi skriver vår oppgave hos dem. Vi fikk en liste med oppgaver de hadde for oss på mail etter møte. Det blir ingen møter frem til neste år, fordi noen av oss fortsatt har noen eksamen å avlegge. Men vi skal holde kontakt å oppdatere hverandre hvis vi finner noen nyttige ting knyttet til prosjektet Vi har tidligere levert prosjektskissen, og venter på godkjenning fra HiOA. Tidligere (i slutten av 2014) har vi vært på to møter med Knowit. I dag er altså vårt tredje møte med dem. Vi er godt i gang med oppgaven. Blant de valgbare oppgavene vi skrev om i prosjektskissen, valgte vi: Konferansehåndtering. Påmelding, avmelding, bestilling av hotellrom, påmelding av aktiviteter etc. Innsending av foredrag, oppsett av program etc. Vi valgte denne oppgaven fordi vi mente at den passet best for oss med tanke på gjennomførbarhet, tid og kompetanse. Knowit foreslo å kjøre hele prosjektet som et ekte typisk systemutviklingsprosjekt, noe som gruppen godtok. Dette vil gi gruppen erfaring fra et hverdagslig praktisk perspektiv, i denne bransjen. Dette inkluderer alt fra userstories til iterative prosesser. Videre har vi nøye sett på og diskutert ulike teknologier, språk og oppsett i detalj, for å finne ut hvordan konferansehåndteringssystemet skal virke, og hvordan brukergrensesnittet skulle se ut. Blant annet har Knowit foreslått REST system, relasjons eller dokumentdatabaser (med tilhørende SQL etc.). Ulike former for Java og JavaScript for å håndtere serverkommunikasjonen er også rådet av Knowit. Vi må definere en kravspesifikasjon og lage en realistisk tidsramme for hele prosjektet. Etter møtet hadde vi et gruppemøte på skolen. Vi diskuterte ulike relevante teknologier og mulige oppsett. Blant annet Ruby,.NET, node.js, Scala og skyutviklingstjenester som Heroku og Azure. Dersom vi benytter.net ble utviklingsprogrammet Visual Studio nevnt, og at skolen har lisenser til dette. Likevel synes vi at Ruby virker som et interessant og forståelig språk, med tanke på omfanget av prosjektet. Vi ønsker å tenke enkelt og kode alt fra bunnen av. Heroku ble valgt for kjøring av koder.vi skal benytte Github til å lagre all koden/kildekoden, og se endringene vi gjør i koden. Det vi likte best med å bruke heroku og github var at begge tjenester er godt integrert sammen. Heroku er altså gratis å bruke. 2

4 I dag er det møte med oppdragsgiver. Vi viser frem et lite eksempel på hvordan det kunne se ut, og hva som, etter vår forstand passer/ikke passer sammen av teknologier og oppsett, som ble diskutert på forrige møte. Vi var fritt til å kontakte oppdragsgiver via epost dersom det oppstår problemer underveis i prosjektet. Det ble fastsatt at konferansehåndteringsløsningen skal ikke inneholde innlogging funksjon, men at brukerne heller trykker på en link/linker for å styre og administrere sitt eget grensesnitt/konto, og at brukerne derfor må registrere sin e post adresse i dette systemet før man kan bruke det. På klientsiden/i nettleseren, ble det en stor diskusjon om bruk av HTML, CSS og JavaScript/jQuery. Vi gjennomgikk og la inn flere endringer/oppgaver i Trello, og ble anbefalt å bruke et mellomlagring databasen og klienten for kjappere ytelse. Videre diskuterte vi deployment rutiner og hvordan strukturen og dataflyten raskt kan endre en applikasjon. For eksempel vil endringer i en databasetabell skal raskt vise kodeendringer. Derfor er det viktig å teste ofte, for å finne mangler og begrense feil i koden Idag ble det snakk om design på sluttproduktet. Alle har med sitt forslag om design, men tanken på at det kan gjøres endringer underveis som kan gjør det vanskelig å få til et design. Vi er fullstendig klar over at det er litt for tidlig å bruke tid på designvalg, men vi gjorde det likevel for å få sjekket hvor mye arbeid det kunne tas. Videre diskuterte vi funksjoner vi skal lage ferdig eller prøver å lage til neste møte med oppdragsgiver. Neste møte skal avtales på facebook! I dag hadde vi møte med oppdragsgiver Knowit og diskuterte rammeverkene Rails og Sinatra, og hvilken av dem som egner seg best for prosjektet. Rails er mer "ferdig", mens Sinatra handlet mest om å begynne på nytt. Samtidig er Rails mer begrenset til post/request, grensesnittet, noe som kan være utfordrende å lage en SPA av. Vi gikk kjapt gjennom Heroku oppsettet. Fikk veiledning for å bruke github riktig, av oppdragsgiveren. Ble diskusjon rund valg av database. Vi sto mellom to valg PostgreSQL og MySQL. Vi så også på server oppsett, i forbindelse med at man hovedsakelig trenger to kodetrær, en på servesiden og en på klientsiden. Det vi si Rails med databasen på serveren, og JavaScript på klientsiden som kommuniserer med dette I dag var det enda et møte med oppdragsgiveren. Vi viste frem koder vi hadde laget, både fungerende og ikke fungerende. Vi fikk tilbakemeldinger og råd om hva vi trenger å endre og hva som vi kan la være slik som det er. Det vi hadde av ferdig kode var et skjema som var knyttet til en PostgreSQL database. De av oss som brukte windows opplevde vanskeligheter med 3

5 å koble skjema med PostgreSQL. Windows brukere måtte velge SQLite som ble ikke anbefalt av oppdragsgiveren. På grunn av vanskeligheter windows brukere hadde angående koblingen til postgresql database, fikk vi råd om å laste ned VM ware og opprette en Debian maskin og prøve å få til database tilkobling. Det prøvde windows brukere og det gikk fint. For Mac brukerne var det bare å kjøre på. Neste møte med oppdragsgiver er satt til 25.februar I dag hadde vi et møte med vår veileder Ismail. Vi snakket om hvordan prosjektet har gått så langt. Vi ble rådet på det sterkeste å ikke vente med å starte på rapportskriving. Vi fikk også gode innholdsforslag til rapporten som å begrunne valgene vi tar og hvordan dette påvirker selve sluttresultatet. Etter møtet med Ismail hadde vi et gruppemøte. Da startet vi med å gjennomgå hvilke koder som skal ligge hvor(på server side eller klient side). Vi snakket rundt teknologier Polymer og Angular for frontend utvikling. Polymer både ser og virker som en app, og kan egne seg til både desktop, touchskjermer/mobile enheter og i nettlesere generelt, mens det samtidig gjør mye for deg. Til slutt la vi Polymer til siden fordi vi ønsker å ha mest mulig kontroll på koden (kode mest fra bunnen). Angular hadde mye av det vi trengte, uten å påtvinge mye unødvendige skjulte funksjoner og koder. Vi diskuterte hvilke elementer (blant annet bilder og knapper) vi trenger og hvordan utseendet på brukergrensesnittet (GUI) skulle være. Vi ble enige om at brukergrensesnittet skal ha brukervennlig utforming. Videre gikk vi gjennom oppsett av REST grensesnitt/api, samt databaseoppsett. Vi sliter med å opprette en fungerende kommunikasjon mellom server og klient. Neste møte er 24. februar Mye av gruppe diskusjoner har skjedd via facebook. I dag bestemte vi å møte for å presentere alt av vi har gjort/funnet så langt, til hverandre. Vi diskutere også hva vi legger frem på møte i morgen med oppdragsgiver. Vi hjalp hverandre med å få til det som andre i gruppen ikke har fått til, det var viktig med tanke på at alle har sin maskin og koder i lik stand enn at det er forskjell mellom kodene og vanskelig å hjelpe hverandre etter noe tid har gått. Vi var fult klar over at alle kan ikke holde på med samme oppgave, og vi må snart fordele oppgavene. Siden vi alle hadde lyst til å lære oss Ruby som vi har valgt som programmeringsspråk, tenkte vi at det var greit til et tidspunkt at vi alle gjør samme ting og lære litt av hverandre. Videre gikk vi gjennom hvordan man bruker Github med Heroku, noe som har vært en utfordring. Arbeidsflyten ble hovedsakelig fra PC/Mac (lokalt) til Github, og endelig til Heroku (endelig produkt). Blant annet er det noe på Github som heter branching, dette lager en kopi av koden man jobber med. Til slutt merger man dette inn i hovedbranchen (Master) når koden er ferdig. Det er også lurere med flere små endringer, sammenliknet med veldig få store endringer. Det er lett å gå seg vill med versjonsnummer og liknende, så det er viktig å forsikre seg om at man jobber på rett kode og navngir alle filene konsistent og lettfattelig. 4

6 Idag var det møte med oppdragsgiveren. Vi ga rapport om det som vi har gjort siden sist, og viste frem det vi hadde lagt, som var to eksempler av fungerende SPA, som var en liten funksjon av sluttproduktet og innholdsregistrering i databasen. Dessuten diskuterte vi litt rundt teknologi for design blant annet Polymer som vi fikk råd om å teste ut fra veilederen vår ved hioa I dag fikk vi kun tid til et kortvarig møte. Vi diskuterte videre om backend og frontend, og hvordan kommunikasjonen mellom disse skal foregå. Vi husket også fra møter med Knowit at vi burde krypterte informasjonen som sendes og mottas, om vi fikk til dette. Dette vil begrense angrep og ondsinnet kode som the man in the middle attack (MITM), cross site scripting (XSS), og cross site request forgery (CSRF). Vi har også gjennomgått foreløpig kildekode I dag hadde vi et møte med oppdragsgiver Knowit. Vi startet med å diskutere hvordan oppsett av konferansene skulle være og hva som var det viktigste. Det viktigste var at vi klarer å få til å vise eventene/arrangementene, og begrense bruken av e mail i sammenheng med påmeldig og administrasjon av deltakere. Oppdragsgiver viste oss et eksempel på en databasemodell, blant annet at et event har flere events/arrangementer, samt at et event/arrangement kun kan ha en ansvarlig/eventmaster (en til mange relasjoner). Vi fikk også et innblikk i et par av Rails sine funksjoner "ActiveRecord" og " Scaffolding ". Vi så nytten dette kunne gi, samtidig som at mye kode og mapper lages ved å bruke disse. Det handler derfor om å finne balansen, men vi er alle nybegynnere i rammeverket Rails og lære mye av dette. Vi holder fast ved å kode mest mulig fra bunnen av. Vi oppdaterte Trello med statusendring på oppgavene, og fordelingen av disse. Når møtet nærmet seg slutten ble vi anbefalt å bruke AngularJS, som kan kommunisere til og fra serverside og klientside I dag viste vi fire eksempler på frontend/brukergrensenitt for Knowit. To var laget fra bunnen av, mens to var laget med bruk av blant annet Bootstrap. Han sa sin mening om alle eksemplene, og hva som kan forbedres. Han var mest fornøyd med Bootstrap løsningen som automatisk tilpasset skjermstørrelsen. Utfordringen var å endre dette til å vise alle registrerte events/konferanser, hvor nyeste event/konferanse står øverst. I dagens diskusjon kom det frem at login funksjon som vi droppet i starten var likevel fint å ha. For å lage innlogging funksjon, burde vi bruke Ruby gems 5

7 (funksjonsbiblioteker) som inneholder selve loginfunksjonene. Selvom det blir lagt til innloggingfunksjon ved scaffolding automatisk må kodene opptimaliseres ved behov. Det skal også legges til brukerregistrering funksjon. Alt dette må overlates til vår Rails og Angular backend. Det ble ekstra utfordrende å bruke REST grensesnittet med denne løsningen, men vi er optimistiske og har troen på at vi klarer å få det til å virke. Alt må skje på en side (Single Page Applikasjon). Vi gjennomgikk nye Rails eksempler. Blant annet ble det nevnt at Scaffolding kan generere brukergrensesnittet, formatering og database. Det ble også nevn at en av de negative sidene med å kode mest mulig fra bunnen av, var at det tar betydelig lengre tid. Til gjengjeld lærer man mye mer, og man har mye større kontroll over koden. Vi må også være helt sikre på at sensitiv informasjon alltid må lagres kryptert/sikkert. Vi må bruke PostgreSQL, fordi Heroku ikke støtter andre databasespråk like bra. Vi må også huske at nøklene mellom tabellene er relatert til hverandre. For eksempel vil det å opprette et nytt event gjøre at personen som opprettet eventet blir ansvarlig/master for eventet, altså administratoren. Personen i brukertabellen blir relatert til dette eventet i eventtabellen I dag gjennomgikk vi hvordan man sender data/input til backend, og hvordan dette lagres i databasen. Oppdragsgiver ønsket login funksjonalitet, og ikke lenger login ved hjelp av en e post link. Vi besøkte også og gjennomgikk for eventuelle andre Rails funksjoner vi har nytte av i backend koden. Login skal skje på samme side uten at siden lastes ned på nytt, som er et tegn på applikasjon er Single Page Applikasjon som oppdragsgiver har ønsket. Vi ønsker også å forandre bakgrunnen til å bli mørkere når loginviduet vises, og dette skal vi løse ved hjelp av CSS I dag hadde vi et møte med oppdragsgiver. Vi har begrenset med tid, og fristen nærmer seg. Det er viktig å begrense alle valgene (inkludert positive og negative sider). Vi mangler nå å få hele systemet til å "snakke" sammen, og teste det slik at det kan liste ut events og lagre brukernes påmeldinger. Backend og frontend må kunne snakke flytende sammen, så JavaScript/AngularJS må også kunne snakke med Rails. Dette har vært den store utfordringen i prosjektet, da vi ikke har funnet gode konkrete eksempler. Vi har derfor stått fast og lest masse om Rails og de andre kodespråkene, uten at vi på dette tidspunktet har klart å sette sammen backend og frontend på en velfungerende og robust måte. Vi har lært og erfart at å fordele oppgavene er en utfordring. Videre ble det diskutert og fastsatt at hver event skal ha et navn/tittel, dato, sted og tid. Dette samsvarer med vår SQL kode som vi har lagt ut på Github. Det ble også gjentatt at event rekkefølge i visning skal være fra nyest til eldst. Videre diskuterte vi generelt om utviklings prosessen og hva vi burde bli bedre. Det aller viktigste er at basisfunksjonene til systemet blir laget som fungerer uten problemer. 6

8 I dag hadde vi et kort møte. Vi har opprettet flere dokumentet på Google Docs, så vi må legge sammen alle til et dokument. Fristen for prosjektet er rett rundt hjørnet (26. Mai), og vi er ferdig med det aller meste. Det som mangler er oppdragsgiverens tilbakemeldinger, meninger og synspunkter om den ferdige løsningen. Det gjenstår nå kun små detaljer til å si at det endelige produktet er helt ferdig og klar til bruk. Vi snakket om å skrive en brukermanual/bruksanvisning til det ferdige produktet. Vi fordelte de siste oppgavene på en effektiv måte, slik at alle visste hva dems hovedoppgave på den aller siste delen av prosjektet er. Vi har også besluttet at vi skal splitte opp oppgavene litt for å effektivisere arbeidet mot slutten. Tam Ha og Gabriel har fokus på kodingen ettersom de har fått mest kompetanse på det, mens Eivind, Philip og Arslan fokuserer på rapporten. Alle jobber fortsatt tett sammen, med mye komunikasjon slik at alle vet hva de ulike gjør til et hvert tidspunkt I dag har vi diskutert og planlagt den siste veien av prosjektet. Hva som er fullført og hva som ennå mangler. Brukergrensesnittet med frontend, og backend er nesten helt fullført, det må kun noen små endringer/justeringer til for at den skal bli ferdig. Rapporten er noenlunde fullført, men mangler småting som konklusjon, eventuelle vedlegg, og alle kildene vi har brukt. Vi har avtalt at neste møte med oppdragsgiver er 25. mai I dag hadde gruppen siste møte før innlevering av prosjektet, vi må huske fristen i morgen (26. mai) klokken 12:00. Oppdragsgiver var også tilstede og så på løsningen vi har laget. Vi viste rapporten og snakket om foreløpig status på den, den er nesten ferdig. Vi gjennomgikk også noe av koden, denne blir ikke 100% ferdig før rapporten skal leveres inn (26. mai klokken 12:00), noe som oppdragsgiver også er fullstendig klar over og vi har avtalt et par møter videre før fremføringen skal holdes slik at vi får på plass flere av de ønskede funksjonene. Tobias kom også med innspill og synspunkter på hva vi burde endre i rapporten før vi leverer den. Videre ble det rapport skriving og koding utover dagen for å gjøre dokumenter og filer innleveringsklare. Vi fikk også en attest fra oppdragsgiveren for samarbeidet. Attesten legges som vedlegg i sluttrapporten. Nå er det kun sortering av dokumenter i rapporten og lage CD en til kildekode som er igjen, før den skal leveres i morgen ( ) før kl 12:00. 7