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 Forprosjekt Prosjektets endelige tittel : Engelsk prosjekttittel: «Calendarmanager (SPA) on Web» Prosjektets varighet : Høsten 2014 Våren 2015 Vår veileder: Ismail Hassan Oppdragsgiver: Knowit Oppdraget/oppgaven Konferansehåndtering på Web (SPA). Påmelding, avmelding, bestilling av hotellrom, sjekke hvem man er med på hotellrom, påmelding av aktiviteter etc. Brukerne kan også sende inn sine egne foredrag, oppsett av sitt program etc. Sammendrag av oppdraget Å utvikle et konferansesystem på Web for IT selskapet Knowit, hvor brukerne av dette systemet kan administrere sine konferanser/foredrag direkte i nettleseren. Selve applikasjonen/programmet skal være en såkalt single page application (SPA), hvor programmet lastes direkte inn i nettleseren på første forespørsel, uten at brukerne trenger å laste ned ekstra plugins/tillegg eller ekstra oppsett. Serverkommunikasjonen skal foregå i bakgrunnen. Hele systemet skal være ryddig og presist satt opp. Det skal også ha ekstra tilhørende funksjoner som vil hjelpe brukerne med å lete etter og finne informasjon om de ulike konferansene/foredragene. I tillegg til dette kan brukerne velge hvem dem ønsker å være med/sjekke hvem dem er på hotellrom med, og mulighet til finne relevante kontaktpersoner (som navn og telefonnummer). Etter fullført prosjekt har vi en felles avtale mellom arbeidsgiver at begge parter helt fritt og helt gratis kan bruke og videreutvikle systemet. Vi har også fokus på ryddig kildekode og velfungerende kode. Vi foretrekker alltid kvalitet fremfor kvantitet. Mål og rammebetingelser Målet med oppgaven er å lage en web basert løsning, for å håndtere konferanser som bedriften arrangerer både innenlands og utenlands. Det skal være en selvbetjenings løsning på Web, med andre ord trenger hverken organisator eller deltakere å kommunisere over telefon eller andre kommunikasjonsmiddler, som ofte kan regnes som forstyrrende eller uønsket når man for eksempel sitter i et møte. Web løsningen vår skal gi organisator og deltakere mulighet til å kommunisere på en bedre, mer oversiktlig og mer effektiv måte sammenliknet med det Knowit bruker i dag. Etter å ha møtt oppdragsgiver, har vi fått følgende punkter å ha med i løsningen, sortert under to kategorier: 1

3 Organisator Lage et Event Sende invitasjon Handlingen inneholder å sette opp følgene info om Event: Navn Beskrivelse Periode Sted Kartreferanse Arrangør Arrangørens e post Arrangørens telefonnummer Eventuell info om fellestransport Invitasjoner skal genereres og sendes, ved at organisatoren legger til en liste over e post adresser inn i et tekstfelt. Invitasjonene kan deretter sendes til alle de oppgitte e post adressene. Deltaker Svare på invitasjon Mulighet for å oppgi ekstra info om Spesifisere spesielle behov Takke Ja/Nei til invitasjonen. Hvis ja, oppgi mobilnummer og e post adresse. Være der lenger/kortere Rom (enerom/dele med noen) Velge romkamerat Bytte med noen Ha med ekstra person. Kost, allergier etc Det er planlagt å utvikle løsningen med flere funksjoner og finesser dersom oppdragsgiver ønsker dette. Eller at vi kan komme med ekstra forslag om innhold til sluttproduktet som oppdragsgiver kan takke ja til. 2

4 Løsningen Løsningen vi har kommet frem til med hjelp fra oppdragsgiveren, er en single page web applikasjon (SPA). Vi stod fritt til å ta egne teknologivalg fra oppdragsgiver sin side, men fikk en del gode eksempler og forslag fra han. Vi har tatt følgende teknologivalg: På brukersiden/i nettleseren skal det brukes vanlig robust HTML, CSS og JavaScript. På serversiden skal Ruby og relasjonsdatabaser brukes. Analyse av løsninger Ettersom Knowit ikke var 100% sikre på hva de ville ha, så besluttet vi å bruke en Agile utviklingsprosess. Det gir mulighet til å endre og tilpasse løsninger på veien. På de tidligere møtene med Knowit diskuterte vi hvorvidt vi skulle ha planlagt sprinter. Eller om vi skulle jobbe med de punktene som var høyest prioritert. Vi synes at ved å planlegge sprinter på hvert møte ville mye av tiden gå bort i planlegging og ikke produksjon. Vi bestemte oss derfor å bruke noe tid på å rangere de ulike oppgavene på prioriter. Vi startet å jobbe med de oppgavene som er av høyest prioritet. Ved å gjøre dette blir ikke oppgaver hengene i mange uker. Vi har også satt demomøter med Knowit hver 3.uke. På disse møtene vil vi vise hva vi har gjort siden sist, samt gå gjennom eventuelle endringer og rettinger. Når det kommer til valg av kodespråk og løsninger ble det diskutert mye. Rammeverk til serveren stod valget mellom Rails og Sinatra. Fordelen med Sinatra over Rails, er at man får noe mer kontroll over koden. I Sinatra kodes det meste fra bunnen av som er mer tidskrevende om man ikke tidligere har jobbet med Sinatra. Det var akkurat dette som gjorde av vi i stedet valgte Rails over Sinatra. Rails gir ferdige templates som for oss er lettere og mer effektivt. Etter flere møter med oppdragsgiver og i gruppen kom det tydelig frem at hva vi skulle lage. Vi begynte å planlegge og brainstorme om hvordan dette systemet kunne fungere, ulike teknologier/språk og oppsett, samt hvordan serverkommunikasjonen skulle foregå. I starten ble ulike typer JavaScript, databaser (som relasjonsdatabaser og restdatabaser) og skytjenester nevnt, samt oppsett av mellomlagring (som for eksempel REST system). REST kan blant annet lagre data til ulike URL er. I tillegg til ulike programmeringsspråk som Java,.NET, PHP, Scala og Ruby. Det ble mye diskusjoner om rammeverk/frameworks. Vi ble enige om at vi skulle bruke Ruby(ruby on rails). Videre valgte vi relasjonsdatabase/postgresql på serversiden. På klientsiden (i nettleseren) skal vi bruke HTML, CSS og JavaScript (som jquery). Vi er godt i gang med å lære oss Ruby og mer avansert JavaScript, slik at vi kan utvikle systemet i størst mulig grad men egendefinerte koder. På serversiden var vi inne på mange kodespråk som node.js, Scala, C Sharp og Ruby, men det ikke er bestemt hvilken av de skal vi bruke ennå. Etter anbefalinger fra Tobias (vår kontaktperson) og Kristofer som er fagansvarlig hos Knowit, gikk vi i retning mot Ruby. Vi avsluttet derfor møtet og hadde som oppgave til neste uke å sette oss inn i de ulike språkene. Etter en uke så hadde vi alle prøvd de ulike språkene litt, alle syntes at Ruby virket spennende, og ettersom at det er et språk som er mye brukt så valgte vi det. Ettersom Tam 3

5 og Gabriel er godt kjent med jquery fra før, og Tobias og Kristofer også anbefalte dette, ble vi enige om at jquery ble valgt som rammeverket på klientsiden. Konklusjon og veien videre Oppdragsgiveren og gruppen har en felles avtale om at vi møtes hver 3. uke. Vi kontakter oppdragsgiver (gjerne på e mail) om vi står fast eller har spørsmål. Vi har skrevet kontrakt med oppdragsgiver. Vi har gruppemøter hver uke, samt at vi kommuniserer på Facebook, på SMS og telefon. Vi har opprettet våre kontoer på den web baserte tekniske verktøyene som trello, github og heroku. På Trello noterer vi ned selve deloppgavene og merker av når hver deloppgave er fullført, slik at vi på en ryddig måte kan begynne på den neste deloppgaven. Vi bruker GitHub for å håndtere/videreutvikle all vår kildekode. Vi bruker Heroku som er en gratis skytjeneste som støtter flere programmeringsspråk (som for eksempel Ruby) og er spesielt nyttig i webutvikling. Videre må vi finne ut hvordan vi skal sette sammen hele systemet, slik at det fungerer robust, sikkert og stabilt. Vi må også designe brukergrensesnittet til applikasjonen, slik at det blir så ryddig og brukervennlig som mulig. 4