Openfoos. Prosjektrapport Gruppe 29 Hovedprosjekt 2012 - Høgskolen i Oslo og Akershus. Amir Ghoreshi, Marcel Eggum Neberd Salimi, Valentin Rey Rosell

Openfoos Prosjektrapport Gruppe 29 Hovedprosjekt 2012 - Høgskolen i Oslo og Akershus Amir Ghoreshi, Marcel Eggum Neberd Salimi, Valentin Rey Rosell

PROSJEKT NR. 2012-29 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKTETS TITTEL Openfoos DATO 30.05.2012 ANTALL SIDER / BILAG 184 / 4 PROSJEKTDELTAKERE Marcel Eggum Amir Hossein Ghoreshi Valentin Rey Rosell Neberd Salimi s153471 s163490 s154399 s163498 INTERN VEILEDER Steinar Johannesen OPPDRAGSGIVER Logica KONTAKTPERSON John Inge Sjøvaag Hervik SAMMENDRAG Openfoos er en web-applikasjon for registrering av spillere, lag og kamper i Foosball. Systemet holder orden på spillhistorikk og statistkk og tilbyr dette som en presentasjon via spillerens profiler. 3 STIKKORD Foosball Web 2.0 REST

Forord Dette dokumentet beskriver hovedprosjektet «Openfoos». Dokumentet er delt inn i fire deler: Prosessrapport Beskriver valg av teknologi, utviklingsmetodikk og gjennomføringen av prosjektet. Produktrapport Beskriver det ferdigstilte produktet og videre muligheter. Testrapport Resultater av testene utført på produktet. Brukerveiledning Brukermanual og installasjonsveiledning for applikasjonen. Innholdet er i hovedsak ment for sensor og oppdragsgiver, men kan også benyttes ved videreutvikling. I alle dokumentdelene bortsett fra brukermanualen forventes det at leseren har forståelse for program- og webutvikling. Takk til Vi vil gjerne takke Jon Inge og hans team fra Logica for å ha gitt oss et utfordrende og morsomt hovedprosjekt. Vi vil også takke for at de disponerte oss plass og utstyr. I tillegg setter vi pris på alle de gode tilbakemeldingene og forslagene vi fikk under hovedprosjektet. En takk går også til vår veileder Steinar Johannesen som ga oss mange gode råd og forslag under denne prosessen.

Prosessrapport

Forord Dette dokumentet beskriver planlegging og utviklingsprosessen i prosjektet Openfoos. Openfoos er et system for registrering av spill i foosball for å bygge og betjene et åpen kildekode fellesskap rundt foosball spilling i Norge. Innholdet er ment for sensor, oppdragsgiver og personer som eventuelt ønsker å videreutvikle systemet. I tillegg til innledning og avsluttende del (kalt for refleksjonsnotat) er dokumentet delt inn i følgende hoveddeler: Beskrivelse av programmet En kort beskrivelse av produktet og dets oppbygning. Planlegging og metode Beskriver utviklingsmetodikk, utførelse og problemløsning. Utviklingsprosessen Beskriver de forskjellige fasene i prosjektet, fra innsamling av informasjon til gjennomføring og overlevering av produktet. Kravspesifikasjonen og dens rolle Presenterer rollen som kravspesifikasjonen har hatt i løpet av prosessen og måten den ble utformet på. Av lesere forventes det forkunnskaper innen program- og web-utvikling.

Innhold 1 Innledning... 1 1.1 Gruppen... 1 1.2 Oppdragsgiver... 1 1.3 Bakgrunn for oppgaven... 1 1.4 Mål... 2 1.4.1 Funksjonelle krav... 2 1.4.2 Ikke funksjonelle krav... 4 1.4.3 Mulige utvidelser... 4 2 Beskrivelse av programmet... 5 3 Planlegging og metode... 7 3.1 Planleggingsverktøy og metodikk... 7 3.1.1 MVC... 7 3.1.2 REST... 9 3.1.3 Fremdriftsplan...12 3.1.4 Risikoanalyse...13 3.1.5 Styringsverktøy...16 3.1.6 Smidig utviklingsmetodikk...17 3.1.7 Fil- og kodedeling...20 3.1.8 Workshops...21 3.2 Arbeidsforhold...21 3.3 Kommunikasjon...22 3.4 Dokumentasjon...23 3.4.1 Dagbok...23 3.4.2 Møtereferater...23 4 Utviklingsprosessen...24 4.1 Teknologier...24 4.1.1 Klient...24 4.1.2 Tjener...28 4.1.3 Kommunikasjonsteknologi...34 4.1.4 Dataformat...35 4.1.5 Persistens...36 4.2 POC...38 4.3 Utviklingsfasene...39 4.3.1 Prototyping / brukeropplevelse...39 4.3.2 Sprint 1...50 4.3.3 Sprint 2...52 4.3.4 Sprint 3...54 4.4 Sluttfasen/Overlevering...56 4.5 Testing...56 5 Kravspesifikasjonen og dens rolle...57 5.1 Bakgrunn for kravspesifikasjonen...57

5.1.1 Rammekrav...57 5.1.2 Levende styringsdokument...58 5.2 Vår erfaring med kravspesifikasjonen...59 5.3 Kravspesifikasjonen og det endelige produktet...59 5.3.1 Oppfyllelse av krav...59 5.3.2 Tilbakemelding fra oppdragsgiver...59 5.4 Konklusjon...60 6 Refleksjonsnotat...61 6.1 Samarbeid...61 6.1.1 Arbeidsmetodikk...61 6.1.2 Teknologi...62 6.1.3 Kommunikasjon...63 6.2 Veiledning fra HiO...64 6.3 Utvikling...64 6.4 Ferdigstilling...64 6.5 Produktet...65 6.6 Konklusjon...65 7 Kilder...66 Bøker:...66 Nett...67 Verktøy, rammeverk og teknologi...68

Prosessrapport 1 Innledning I forbindelse med det avsluttende hovedprosjektet ved HiOA fikk vi i oppdrag å lage et system for registrering av spill i foosball. Oppgaven er gitt av Logica. 1.1 Gruppen Gruppen består av Amir Ghoreshi, Marcel Eggum, Valentin Rey Rosell og Neberd Salimi. Alle er avgangsstudenter ved HiOA. Vi har tidligere jobbet sammen i flere prosjekter og kjenner hverandre godt. 1.2 Oppdragsgiver Logica er både kunde og oppdragsgiver. Kontaktpersonen er lederen for Java-avdelingen Jon Inge Hervik. Logica er et selskap som leverer tjenester og teknologi for forretningsbedriften. Logica Norge har omtrent 700 ansatte. Internasjonalt har Logica 41000 ansatte fordelt på 36 land. Logica tilbyr rådgivning, systemintegrering og outsourcing for alle bransjer og forretningsfunksjoner. Logica Norge het tidligere VM-data da det ble kjøpt opp av LogicaCMG konsernet i 2006. I 2008 byttet selskapet navn til Logica Norge. 1.3 Bakgrunn for oppgaven Kunden har i dag et system for registrering av spillere og kamper i foosball. Systemet har mye funksjonalitet, men er rettet kun mot kundens organisasjon og er ikke egnet for å bli et allment tilgjengelig foosball system. I dagens løsning er det satt opp en enkel klient med en skjerm og en applikasjon utviklet i Microsoft Silverlight, som lar en registrert ansatt logge seg inn ved hjelp av et brukernavn eller en fingeravtrykk-avleser. 2 eller flere ansatte kan logge seg inn og starte et nytt spill der hvert mål må registreres ved å benytte en mus og trykke på en knapp i applikasjonen. Hvert mål som registreres blir lagret i en database slik at brukerens totale poengsum for alle spill kan hentes ut og fremvises i forhold til poengsummen til andre spillere. 1

Prosessrapport 1.4 Mål 1.4.1 Funksjonelle krav Systemet må ha En spiller kan: Registrere seg Logge inn Logge ut Bli gjenkjent av systemet Starte en kamp Avslutte en kamp når som helst Avslutte en kamp etter oppnådde 10 mål Starte igjen en kamp med samme motstandere etter oppnådde 10 mål Danne lag med andre spillere Spille en kamp mot en spiller Spille en kamp mot to spillere (vennskapskamp) Registrere mål spilleren har skåret Trekke fra mål spilleren har skåret Registrere selvmål Trekke fra siste mål Ha tilgang til sin profil Registrere en erkerival Applikasjonen skal: Autofullføre brukernavn fra database ved innlogging Ha egen registreringsknapp (for spiller) Autoregistrere lag når to spillere spiller sammen Kåre en vinner ved oppnådde 10 mål Registrere mål per spiller Ha profil for lag/spiller hvor man kan: Legge inn bilder 2

Prosessrapport Sette opp lag med navn Lagre lyder Ha historikk for spillere/lag/kamper Ha en rangerings algoritme (ELO eller FIDE) Rangere spillere Rangere lag Vise den innsamlede data Vise tabeller med prestasjoner av spiller/lag Vise vinnprosent Vise statistikk mot andre spillere/lag Vise statistikk mot erkerival Vise alle kamper av en spiller/et lag Systemet bør ha Ha en utvidet innloggingsmetode (med kort- eller fingeravtrykk-leser) Matche spillere/lag: Manuell Random Etter ranking Etter beste lag Ha forskjellige vinnerkriterier: Først til 10 mål Flest mål på 5 min Sudden death Vise data i grafer Vise hvor mye spillerne har spilt i en periode Vise alle spillere Vise lengde på kamper Vise når kamper ble spilt Ha et administrasjonsgrensesnitt 3

Prosessrapport 1.4.2 Ikke funksjonelle krav Prosjektet skal være åpen kildekode Systemet skal ha en lav terskel for å registrere seg (minst mulig trinn) Systemet skal være lett å bruke Systemet skal være sosial Systemet skal ha funksjoner for å motivere konkurranse og deltakelse Systemet skal være morsom å bruke 1.4.3 Mulige utvidelser Knytting til sosiale medier, eksempelvis Facebook Sende invitasjoner Mobilapplikasjon 4

Prosessrapport 2 Beskrivelse av programmet I dette kapittelet skal vi gjøre rede for den overordnede strukturen og funksjonaliteten som tilbys i Openfoos-applikasjonen slik at leseren får en bedre forståelse og et større utbytte av de senere kapitler. Applikasjonen lar brukere registrere seg slik at de kan gjenfinne info om seg selv og tilpasse det slik de ønsker. En spiller/et lag kan laste opp bilde, lage seg et lagnavn, skrive en kort bio om seg selv osv. Når spilleren starter en kamp, så vil noe av informasjonen som lagnavn og bilde dukke opp og bli vist på skjermen. En spiller er et lag både når han/hun spiller alene og når vedkommende spiller med en annen spiller. Et lag kan enten bestå av en eller to spillere, men en spiller har også da muligheten til å danne flere lag med forskjellige spillere. Man kan enten starte en vennlig- eller rangert-kamp. Når det er en vennlig kamp, så lagres det ikke statistisk data om kampen. Hvis det er en rangert kamp, så vil det beregnes poeng for begge deltagende lag. Openfoos lager statistiske utregninger over følgende: spillernes prestasjoner lagenes prestasjoner vinn- og tap-prosent for spiller og lag graf over de siste kampene med detaljer info om dem informasjon om spillernes mål I tillegg tilbyr applikasjonen et rangeringssystem som regner poeng ut fra antall kamper en har vunnet og tapt. Til dette har vi brukt ELO algoritmen for å rangere både lag og spillere. 5

Prosessrapport I profil-siden kan man søke etter spillere og lag og se all informasjon om disse uten å være registrert/pålogget. Der kan man også se kamper som pågår, rangering av spillere, lag og de beste og dårligste spillerne/lagene. Openfoos har også en administrasjonsside hvor administrator/-er kan vedlikeholde informasjon som er registrert om spillere, lag og spilte kamper. 6

Prosessrapport 3 Planlegging og metode I dette kapittelet skal vi presentere de ulike verktøyene og utviklingsmetodikkene som vi har benyttet oss av. Til slutt vil vi gå nærmere inn på fil- og kodedeling, samarbeidet og kommunikasjonen både innad i gruppen og mellom gruppen, oppdragsgiver og veileder. 3.1 Planleggingsverktøy og metodikk 3.1.1 MVC MVC er en arkitektur som deler applikasjonen opp i følgende, tre komponenter: Data-laget (Model), presentasjonslaget (View) og interaksjonslaget (Controller). Ideen er å dele opp ansvarsområdene i applikasjonen og å holde dem separert fra hverandre slik at utvikling og testing skjer på et individuelt komponent-basert nivå. I en applikasjon vil flyten normalt sett foregå på følgende måte: 1. Brukeren trykker på en knapp i applikasjonen. 2. En controller tar ansvaret for å håndtere interaksjonen med knappen. 3. Controlleren ber om data fra en modell og gir den videre til et view. 4. View komponenten presenterer data-settet på en grafisk måte for brukeren. Modell-komponenten Modellen holder på applikasjonens dataobjekter. I vårt tilfelle vil dette være et objekt av en spiller med attributter for navn, bilde og registreringsdato. Modellen vet ingenting om controller eller view-komponenter, men kan være klar over andre modeller. Logikk knyttet til manipulering av modellen knyttes til modellen selv slik at controllene får et felles verktøysett å arbeide ut i fra. View-komponenten View komponenten presenterer et grafisk lag som brukeren kan ha interaksjon med. Komponenten har kun ansvaret for å male ut en presentasjon av data-settet som den mottar fra en kontroller. Komponenten er programmert med kun enkle kondisjoner og utfører ingen manipulasjon av data-settet. Våre view-komponenter er skrevet i ren HTML og CSS med kondisjons-logikk skrevet i JavaScript eller Groovy. 7

Prosessrapport Controller-komponenten Controller-komponenten fungerer som lim mellom modeller og view-komponenter. Controlleren mottar brukerens handlinger fra view-komponenten og prosesserer den. I noen tilfeller kan dette innebære at controlleren må manipulere en modell, lagre den og gi view-komponenten en ny og oppdatert versjon av data-settet fra modellen slik at utseende kan oppdateres med frisk informasjon. Motivasjon for bruk Primært sett ønsket vi en arkitektur der vi uproblematisk kunne utvikle modeller og grafiske grensesnitt i forskjellig tempo- og av forskjellige programmerere. Det skulle være enkelt for en programmerer som av ulike grunn overtok et område for å sette seg inn i strukturen og fortsette arbeidet i samme stil som en tidligere programmerer. Vi så tidlig at ulike seksjoner av applikasjonen ble utviklet i et voldsomt tempo fremfor andre. Videre la vi merke til hvordan manipulering av arkitekturen på modeller ikke ødela for viewkomponenter og gjorde det mulig for oss å legge inn og trekke fra data-variabler etter hvert som vi lærte mer. Av erfaring så vi at det grafiske grensesnittet ble oftere endret enn selve modellene. Denne splittelsen av ansvarsområder førte også til at applikasjonskomponenter kunne feilsøkes og testes individuelt. Tiden benyttet til feilsøking har vært lavere enn ved tidligere prosjekter. Mønstrene ModelView-View-Model(MVVM) og Model-View-Presenter (MVP) var også vurdert for dette prosjektet, men falt bort på grunn av rammeverkene som ble benyttet. Implementering av MVC-mønsteret på klientsiden JavaScript benyttes i mange sammenhenger til å introdusere mindre funksjoner til nettsider. Et eksempel på dette kan være validering av inntastet verdier fra brukeren i en registreringsform. I vårt tilfelle skulle man forsøke å programmere en applikasjon på mer enn tusen linjer med kode som også håndterte kommunikasjon med en server. Modularisering og oppdeling av kode i klasser og pakker er ikke støttet i like stor grad og dette kunne fort medføre at koden ble uleselig. Behovet for MVC-arkitekturen på klientsiden kom frem i øyeblikket da man ønsket å følge en standard mal for hvordan applikasjonens arkitektur skulle se ut. Vi håpet med dette at hvis flere 8

Prosessrapport utviklere skulle arbeide med prosjektet i fremtiden, så ville disse tvinges til å følge arkitekturen og skrive sin JavaScript kode på en ryddig, standardisert måte. Kriteriene for valg av rammeverk på klientsiden skulle oppfylle følgende krav: God dokumentasjon av rammeverket Støtte til å synkronisere data med en tjener Moderat levealder og støttegruppe Støtte for JQuery eller et annet bibliotek for manipulasjon av dokumentet Evne til å støtte grafiske maler Evne til å håndtere lyttere og utløsere Av disse kravene ble følgende rammeverk installert og testet: Ember.js, SproutCore 2.0, Spine, YUILibrary, Backbone, Knockout og JavaScriptMVC. 3.1.2 REST Representational State Transfer (REST) er et sett med prinsipper som understøtter en arkitektur for hvordan nettverksapplikasjoner skal kommunisere med hverandre. Arkitekturen er sterkt avhengiggjort av HTTP protokollen og benytter det eksisterende grensesnittet for web til å gjennomføre kall mellom applikasjoner istedenfor å bruke komplekse mekanismer som COBRA, RPC eller SOAP. URI, Ruter På serversiden er alle ressurser merket med identifikatorer, enten dette gjelder applikasjonsobjekter, sett fra databasen eller funksjoner som utfører algoritmer. Enhver ressurs er unik og har dermed en egen URI (Universal Resource Identifier) Adressene er konstruert for å vise til et sett med data, eller individuelle entiteter. Et eksempel på dette er følgende adresser; www.openfoos.com/kamp fremviser informasjon om alle kamper 9

Prosessrapport www.openfoos.com/kamp/fra/01-10-2011/til/01-11-2011 fremviser informasjon om alle kamper fra oktober 2011, til november 2011 www.openfoos.com/kamp/id/1234 fremviser informasjon om en kamp med identifikasjonummer 1234 Tilstandsløshet og lagdeling Serveren bevarer ikke informasjon om klientene som ber om ressurser. Sesjoner eksisterer ikke og klienten og serveren må overføre et sett med meta-data mellom hver overføring for å kunne utføre forespørselen. Dette medfører at større mengder data må overføres mellom partene, men resulterer til at serveren uproblematisk kan restartes eller at forespørselen kan håndteres av flere servere uten at klienten merker dette. Fordelen med en slik konstruksjon er at applikasjonen utmerket kan publiseres i en nett-sky og skaleres opp eller ned etter behov uten at klientene mister følelsen av sine sesjoner. HTTP protokollen inneholder verbene GET, PUT, POST og DELETE for å fortelle serveren hva den skal gjøre med data-settet identifisert av en URI. Klienten setter verbet i ethvert kall som sendes til serveren. GET presenterer en instruksjon om å hente en ressurs fra serveren, identifisert av en URI, som leverer data til klienten og utfører ingen manipulasjon. Klienten er likevel fri til å gjøre hva den vil med data-settet på sin side. PUT instruerer serveren til å oppdatere en eksisterende ressurs. Instruksen forteller ikke serveren om ressursen allerede eksisterer fra før av og serveren må selv sørge for å kontrollere dette. POST benyttes ofte i sammenheng med opprettelse og persistering av nye ressurser. Likevel er verbet mer åpent for forskjellige typer handlinger som ikke passer under de andre verbene. DELETE instruerer serveren til å slette ressursen. 10

Prosessrapport Responskoder Serveren returnerer et svar til klienter som initierer en forespørsel. Ved hjelp av responskoder som er plassert i svarmeldingen, kan klienten motta en indikasjon på hvordan serveren håndterte forespørselen. Enkelte responskoder som benyttes i applikasjonen forklares følgende: 200 - Ok Indikerer at forespørselen er suksessfull. 201 - Created Indikerer at ressursen ble opprettet på serversiden. Benyttes ofte i sammenheng med PUT og POST 400 - Bad Request Indikerer til at data-settet som klienten sendte ikke samsvarte med det serveren forventet. Dette kan eksempelvis være relatert til sending av tomme passord eller identifikatorer som inneholder bokstaver, når kun tall var forventet. 404 - Not Found Indikerer til at den forespurte ressursen ikke kunne finnes av serveren. 401 - Not Authorized Indikerer til at klienten ikke var autorisert for å manipulere eller hente ut ressursen 405 - Method Not Allowed Indikerer til at metoden vi ønsker å utføre på ressursen ikke er supportert. Eksempelvis sletting av en kamp som ikke er avsluttet. 409 - Conflict Fremheves eksempelvis når vi forsøker å opprette flere spillere med identisk samme navn 11

Prosessrapport 500 - Internal Server Error Representerer at en generell feil har oppstått på serversiden. Dette kan være et resultat av manglende validering eller programmeringsfeil. Vår implementasjon Vi benytter oss av de prinsippene (som er beskrevet ovenfor under REST) i to deler av systemet. Selve spillet på klientsiden kommuniserer med et API (Application Programming Interface) mot serveren. Klienten innsamler kun input fra brukeren, validerer dette, manipulerer innholdet og sender det til serveren for prosessering. Svaret som blir gitt av serveren benytter klienten til senere steg eller som tilbakemeldinger til brukeren. Serveren benytter rammeverket Play, som følger prinsippene i REST for å levere sine tjenester. Enhver side eller kontroller har en egen rute og er unik til å tilby tjenesten i formatet HTML, JSON eller XML. 3.1.3 Fremdriftsplan Ettersom kunden ønsket en smidig gjennomføring av leveransen var det opp til oss å legge opp arbeidet, gitt at vi holdt oss til smidige prinsipper som sikret kundeinnvolvering og at kunden fikk levert et system av ønsket kvalitet og med nødvendig funksjonalitet. Prosjektet ble delt opp i små leveranser med en varighet på 3-4 uker (POC + 3 iterasjoner). Hvilke funksjonaliteter som skulle implementeres i de forskjellig iterasjonene var ikke bestemt på forhånd. På grunn av dette så laget vi en grov overordnet fremdriftsplan som ble endret underveis. 12

Prosessrapport Figur3.1.3.1 Skisse av fremdriftsplan 3.1.4 Risikoanalyse Figur3.1.4.1 Risikotabell Tabellen illustrerer hvordan sannsynligheten i ulike hendelser kan representere en risiko for å fullføre prosjektet og omfanget av risikoen i en skala fra 2 til 20. Skalaen finnes ved å multiplisere sannsynlighetsraten med konsekvensraten. Verdiene i tabellen er tilfeldige og er der 13

Prosessrapport bare for å illustrere at risikoen øker proporsjonalt med økt forekomst av en mulig hendelse. Skalaen kan leses slik: 10-20 (rød farge) vurderes risikoen som høy. Høy risiko vil som oftest kreve strakstiltak. 5-9 (gul farge) som middels. Risikoreduserende tiltak skal vurderes ved middels risiko. 2-4 (grønn farge) som liten. Ved liten risiko er det ofte ikke nødvendig å iverksette risikoreduserende tiltak. Vi ser at en hendelse med en risikoverdi mellom 2 og 4 blir nesten umulig å unngå. Hvis risikoverdien i hendelsen er mellom 5 og 9 kan den kompromittere fremdriften av prosjektet og med en verdi mellom 10 og 20 blir den veldig vanskelig å håndtere. De kommende punktene er de mest sannsynlige eller farlige hendelsene for prosjektet. Korttidssykdom Risikonivå: 2-4 Hvordan unngå: at noen av medlemmene i gruppen blir syk er nesten umulig å unngå. Forkjølelse, omgangssyke ol. Er noe som forekommer med moderat hyppighet. Løses: ved å dele jobben slik at det ikke bare er en person som sitter med ansvaret for vitale oppgaver. Informasjonen må flyttes slik at alle medlemmene holder seg oppdaterte til enhver tid. Langtidssykdom/Annet frafall Risikonivå: 5-9 Hvordan unngå: at noen blir alvorlig syk eller må forlate prosjektet på grunn av nå ukjente årsaker er ikke ønskelig, men det er en mulighet vi må ta i betraktning. Slike hendelser er nesten umulige å unngå. Løses: på samme måte som ved kortidssykdom, men her må vi ha en beredskapsplan for å ta over oppgavene av den som blir borte. Planen går på å ta over i første omgang på følgende måte: 14

Prosessrapport Amir syk, Neberd tar over Neberd syk, Valentin tar over Valentin syk, Marcel tar over Marcel syk, Amir tar over Dette er som nevnt ovenfor i første omgang. Ved første anledning bør arbeidet redistribueres slik at et enkelt medlem ikke blir overbelastet. I verste fall, så ber vi produkteieren om å skalere ned omfanget av leveransen. Uenigheter/Misforståelser/Interne krangler Risikonivå: 10-20 Hvordan unngå: Ærlighet og åpenhet er den beste vaksine. Enighet er ønskelig, men full tilslutning blir vanskelig å oppnå ved alle avgjørelsene. Det er derfor viktig at dersom noen er uenig, misfornøyd, føler seg misforstått eller forbigått ol., tar vedkommende dette i det første møtet med resten av gruppen. Gruppen skal alltid ta slike henvendelser seriøst og drøfte dem i møtene hvis det skjer. Det skal alltid gis saklig grunnlag for avgjørelser hvor det foreligger uenighet. Gruppen skal bygge lagånd ved å gi faglig støtte til hverandre etter de kunnskapene hvert medlem har, slik at vi legger sammen og ikke trekker fra. Arbeidet skal fordeles på en rettferdig måte. Løses: ved å følge forrige punkt. Hvis det viser seg umulig å løse det internt, skal gruppen rådføres med veilederen. Tap av informasjon Risikonivå: 5-9 Hvordan unngå: Vi bruker DropBox, Google Docs og GitHub til å lagre filer (koder) og dokumenter, slik at alle i gruppen har tilgang til dem til enhver tid. I tillegg skal alle i gruppen ha minst en sikkerhetskopi i minnepinner, eksterne harddisker ol. Løses: ved å oppdatere jevnlig sikkerhetskopiene slik at tapet blir minimal i tilfellet noe skjer. 15

Prosessrapport Omfanget av jobben er for stor/tidsmangel Risikonivå: 10-20 Hvordan unngå: Ved å opprette en arbeidsplan/aktivitetsplan hvor vi beregner god tid for de forskjellige fristene. Vi må være klare over at et prosjekt hvor fire personer samarbeider kan by på utfordringer som er umulig å forutsi. Dermed bør vi unngå å jobbe til siste liten og tvert i mot bli ferdige i god tid i tilfelle noe ikke er riktig, må forandres. Hvordan løse: Ekstra innsats og lange dager. 3.1.5 Styringsverktøy I starten av prosjektet prøvde vi å finne et bra styringsverktøy som kunne holde rede på prosjektets status, dvs hvor langt vi hadde kommet i prosjektet, hva som blir gjort og av hvem osv. Vi fikk vite at Jira ble brukt mye ute i arbeidslivet. Etter å ha prøvd det i noen dager, så fikk vi erfare at det var tungvint og komplisert å jobbe med det. I tillegg hadde den mye funksjoner som vi ikke hadde bruk for. Jira var rett og slett tilpasset for større prosjekter med flere brukere. Derfor gikk vi over til trello, som både var gratis og passet perfekt til prosjektet vårt. Vi satte opp kontoer for alle gruppe-medlemmene og oppdragsgiveren slik at alle hadde tilgang til det til enhver tid. Det som er fint med trello at alt oppdateres umiddelbart (i sanntid). Siden alle hadde satt opp gmail på mobilen sin, så fikk vi en mail om det skjedde endringer på trello. I trello er prosjekter representert ved Boards, som inneholder lister (tilsvarende oppgavelister). Lister inneholder kort (tilsvarende oppgaver). Vi lagde flere kort over hva som måtte gjøres fra uke til uke. Et gruppemedlem fikk tildelt flere kort med forfallsdato på. Da kunne vi også se hva som hadde blitt gjort og hvor lang tid man hadde brukt på de forskjellige kortene/oppgavene. Dette ga oss en pekepinn om vi kunne holde fristen til iterasjonene. 16

Prosessrapport Figur3.1.5.1 Trello 3.1.6 Smidig utviklingsmetodikk Smidig utvikling er en utviklingsmetodikk for programvare som setter sluttbrukeren i fokus. Typisk for smidig gjennomføring er at arbeidet gjøres i repeterende sykluser/iterasjoner av varighet 1-4 uker. Enhver iterasjon er en del-leveranse. Iterasjonene ender med et presentasjonsmøte hvor arbeidet blir evaluert. Oppdragsgiveren kvalitetsvurderer og bestemmer om kravene tilfredsstilles. Dersom leveransen møter kravene, så planlegges neste iterasjon og utviklerne kan da starte med denne. Hvis det ikke er tilfellet, så må den forbedres til neste iterasjon for å få den godkjent. 17

Prosessrapport De mest brukte metoder basert på smidige filosofi er XP og Scrum. Disse skiller seg i enkeltheter, men deler iterativ tilnærming beskrevet ovenfor. XP står for ekstrem programmering. Programmering og testing er de to viktigste aktivitetene innen XP. XP er altså programmeringssentrisk (kodesentrisk), hvilket betyr at det meste dreier seg om programmeringsaktiviteten. Siden vi ikke har benyttet oss av XP i prosjektet, så går vi ikke mer dypere inn i det. I motsetning til XP, omfatter Scrum metodikk både ledelsesmessige- og utviklings- prosesser. Scrum innbefatter det å stå sammen om en oppgave, som i rugby. Scrum kan oppsummeres som følger: 1. Prosjektgruppen og oppdragsgiveren lager en prioritert liste over alt som gruppen skal gjøre. Dette kan være en liste over aktiviteter eller en liste over funksjoner som systemet skal inneholde. Denne listen kalles produktloggen (product backlog), altså en kravspesifikasjon. 2. Periodevis vil prosjektgruppen hente inn anslagsvis 30 dagers arbeid fra toppen av produktloggen. Denne arbeidsmengden ekspanderes til en detaljert aktivitetsliste som kalles sprintloggen (sprint backlog). Når sprintloggen er bestemt er det ikke lov å legge til mer eksternt initiert arbeid til denne. 3. Sprint er en f.eks. 30 dagers periode (kortere periode er tillat) hvor utviklingsgruppen utvikler det som ligger i den tilhørende sprintloggen. En sprint er altså en iterasjon innen utviklingsforløpet. 4. Hver dag møtes prosjektgruppen ansikt til ansikt i fem til ti minutter for å oppdatere hverandre om status og om hindringer som senker fremdriftshastigheten. Dette kalles den daglige scrum, og er et stående møte. Her vektlegges kommunikasjon mellom deltakerne med fast bestemte spørsmål. 5. En person har fått tildelt tittelen Scrum Master. Denne personen skal sørge for at hindringer som påpekes under det stående møtet fjernes. Scrum masteren kan betraktes som en forenklet prosjektleder. 18

Prosessrapport 6. Demo er programvare som kan eksekveres (kjøres) og som kan demonstreres eller leveres kunden. Prosjektgruppen lover å demonstrere eller levere resultatene ved utgangen av de 30 dagene, altså etter at sprinten er over. Figur3.1.6.1 Illustrasjon av metodikken i scrum Oppdragsgiveren ønsket at prosjektet skal gjennomføres med en smidig utviklingsmetodikk. Dette for at relevante behov skulle avdekkes og belyses underveis. Derfor valgte vi denne metodikken. I oppstarten av prosjektet satte vi oss ned sammen med kunden/oppdragsgiveren for å utrede om mulige løsninger for teknologi og for å sette opp en fremdriftsplan. Her ble det bestemt at vi skulle ha totalt fire iterasjoner og hver av disse skulle ha en lengde/varighet på 3-4 uker. Vi hadde en kravspesifikasjon som ble utarbeidet i forkant av hver delleveranse (dvs oppdragsgiveren bestemte hva de ville ha med eller som var viktigst for dem i de forskjellige iterasjonene). Men før det så ville kunden at vi skulle bruke den første tiden (ca. 3 uker) på å levere en Proof of Concept (PoC) løsning. Hensikten med denne var å tidlig danne seg et bilde om hvilke teknologier og brukergrensesnitt løsninger som var hensiktsmessige å bygge videre på. Både på slutten av PoC en og iterasjonene holdt vi demo for kunden hvor vi fikk tilbakemelding om det vi hadde gjort. 19

Prosessrapport Vi innad i gruppen hadde daglige scrum møter (stående som varte 5-10 min) for å oppdatere hverandre om status. Det ble gjort slik at den som hadde tusjen i hånda fikk svart på disse tre spørsmålene: 1. Hva har du gjort siden sist gang? 2. Hvilke hindringer har du møtt? 3. Hva skal du gjøre neste gang? Den som hadde tusjen, kunne også stille de andre spørsmål hvis det var noe han tenkte på. Når vedkommende var ferdig, så sendte han tusjen over til neste deltager/gruppemedlem. Det var vanskelig og uvant å gjennomføre leveransene etter smidig utviklingsmetodikk. Vi bommet flere ganger fordi vi var uerfarne. Fra skolen hadde vi lært teorien bak det, men hadde ingen praksis på dette. De prosjektene som vi hadde gjennomført på skolen, var gjennomført etter vannfallsmetoden. Vi slet en del i starten og det tok oss en del tid før vi ble vant til denne måten å jobbe på. F.eks. brukte vi ganske mye tid på ting (som enkeltfunksjoner) som skulle/kunne komme i fremtiden, men som ikke hadde noe med pågående iterasjon/leveranse å gjøre. Dette gjorde at vi ikke rakk å implementere/gjøre det som var planlagt. Oppdragsgiveren minnet oss på det og ga oss tilbakemelding på om at vi har sporet av. Vi fikk vite og erfart at enkeltønsker ikke skal gå på bekostninger av helheten. Det har vært ganske lærerikt og vi har fått en forsmak på hvordan ting løses i arbeidslivet. 3.1.7 Fil- og kodedeling Helt fra starten av prosjektet hadde vi planlagt at alle i gruppen skulle delta både i kodingen og rapport skrivingen. For å jobbe effektiv, så måtte alle ha tilgang til samme (oppdatert) kode og fil. For å utveksle filer (til rapporten) ble Google Docs valgt, mens for kodedeling falt valget på GitHub. Git er et distribuert versjonskontrollsystem for kildekode. Git tar kort og godt vare på revisjoner av koden. Du velger selv når du ønsker å lagre statusen, og har mulighet til å gå tilbake i tid for å 20

Prosessrapport se på tidligere revisjoner. Du kan også laste opp og hente ned Git-prosjekter, og håndtere endringer som andre har utviklet i sine kopier. Man må betale for å ha private repositories (ett prosjekt = et repo), men for åpen kildekode er det gratis. Google Docs, eller Google Dokumenter som det kalles på norsk, er en gratis webbasert kontorpakke som inneholder programmer som tekstbehandling, regneark og presentasjoner. Google Dokumenter er laget av Google og tillater brukere å opprette og redigere dokumenter på Internett. Redigering av et gitt dokument kan gjøres av flere personer samtidig, og endringer vil for de andre brukerne gjengis med det samme (i sanntid). Google Dokumenter kombinerer flere forskjellige tjenester. Dokumenter kan lagres på egen PC i flere forskjellige filformater, og programmet kan også importere flere ulike filformater. 3.1.8 Workshops I starten av prosjektet brukte vi mye tid på valg av teknologi. Hver av oss måtte sette seg inn i en ny/gammel teknologi for å finne ut om det passet til prosjektet. Dersom vi gikk for det, så måtte vedkommende holde workshop for de andre slik at alle hadde samme basiskunnskap. Dette gjorde at vi lettere kunne komme i gang med å produsere kode. I tillegg lærte vi ganske mye av hverandre. 3.2 Arbeidsforhold Vi har siden begynnelsen av prosjektet i januar fått tildelt kontorplass og nøkkelkort hos oppdragsgiveren. Dette har absolutt vært en fordel siden det er veldig trangt om plassen på Høgskolen i Oslo, hvor vi har jobbet også med dette prosjektet noen få ganger. Det er på lokalene hos Logica vi har sittet mest og hvor vi har holdt møter med oppdragsgiveren og interne møter i gruppen. Møter med veilederen har vi hatt på kontoret hans ved HiO. En fordel til ved å sitte hos Logica var at vi kunne gå og spørre dem om vi var usikre ang. spesifikasjoner på produktet. 21

Prosessrapport Alle gruppemedlemmene hadde andre fag i tillegg til hovedprosjektet og alle hadde også jobb ved siden av studiene. Vi visste også at noen av oss jobbet best på forskjellige tidspunkter av dagen. For å løse dette hadde vi et møte i begynnelsen av prosjektet hvor vi samkjørte mest mulig de dagene hver enkel skulle bruke til andre oppgaver/jobb. Videre ble vi enige om at vi i størst mulig grad skulle ha kjernetid mellom 10-15 slik at vi kunne sitte noen timer sammen hverdag. Dette har fungert bra og døgnkontinuerlig tilgang til kontorplass hos Logica har også hjulpet oss til å kunne opprettholde et fleksibelt arbeidsmønster. For å programmere har vi benyttet hovedsakelig solo og par-programmering. Etter ønske fra oppdragsgiveren har vi også benyttet iterativ utvikling med tilpasset scrum som metode med daglige scrum møter. 3.3 Kommunikasjon Kommunikasjonen intern i gruppen har foregått på flere forskjellige måter. Først og fremst har dette vært muntlig siden vi har sittet mye sammen og hatt daglig scrum-møter hvor vi har holdt hverandre orientert. Vi har brukt Trello som styringsverktøy hvor vi har notert use-casene og for det meste tekniske oppgaver. Vi har skrevet ukentlig dagbok og i januar opprettet vi en Facebook gruppe med tanke om å kunne samle tanker, spørsmål osv. rundt prosjektet samt å kunne holde seg oppdatert ved f.eks. sykdom. Til dokumentasjonen har vi hatt en felles Google Docs konto hvor vi har lagret ferdige dokumenter og omformet levende dokumenter samt utkast. Kommunikasjon med oppdragsgiveren har foregått muntlig og skriftlig. Vi har fått tilbakemeldinger fra dem i iterasjonsmøtene og har også utvekslet emailer når det er blitt hensiktsmessig. Det har vært til tiders viktig for oss å avklare enkelte ting (funksjonalitet, utseende..) før iterasjonsmøtet og da har vi dratt fordel av å sitte i samme bygning som oppdragsgiveren. 22

Prosessrapport 3.4 Dokumentasjon Vi har skrevet ukentlig dagbok og møtereferater. Dette er blitt brukt underveis i prosessen og som hjelp til å skrive sluttdokumentasjon. Til å lagre dokumentene har vi brukt en felles Google Docs konto og Dropbox. 3.4.1 Dagbok I dagboken har vi loggført den ukentlige progresjonen av prosjektet. I skrivende stund kan vi, ved å slå opp i den, se hvordan veien er blitt og hvilke utfordringer vi har hatt underveis. 3.4.2 Møtereferater Vi har hatt møter med oppdragsgiveren i slutten av hver iterasjon. I disse møtene har vi fått mange tilbakemeldinger og vi har skrevet referat etter å ha hatt møtene. Som verktøy i disse møtene har vi også tatt i bruk mindmapping. Både referater og mindmapping er blitt brukt til å planlegge og prioritere oppgaver og funksjonalitet i de forskjellige iterasjonene. 23

Prosessrapport 4 Utviklingsprosessen Her går vi gjennom de viktigste hendelsene i prosjektet. 4.1 Teknologier 4.1.1 Klient 4.1.1.1 HTML 5, CSS 3 og JavaScript Rike internett applikasjoner har inntil de siste årene som regel vært bygget med teknologier som Adobe Flash og Microsoft Silverlight, som til felles har en arkitektur der en Just-In-Time kompilator presenterer kode som blir avlest av en plug-in i nettleserne og interpretert som et eget program, kun levert av HTTP protokollen. Ikke alle plattformer støtter per dags dato interpreteringen av disse teknologiene. HTML 5 (HyperText Markup Language) er en standard for beskrivelse av web dokumenter som kan manipuleres av nettlesere ved bruk av programmeringsspråket JavaScript / ECMAscript. Dette innebærer blant annet at det er mulig å manipulere form, innhold og media i HTML dokumenter på klientsiden, med eller uten samarbeid med en server i bakgrunnen. Visuelt blir dokumentene stilsatt av modelleringspråket Cascading Style Sheets (CSS), version 3. Det var foretrukket å velge kombinasjonen av HTML 5, CSS og JavaScript av følgende grunner: Kombinasjonen er støttet på plattformene: Windows, Linux, OS X, Android og IOS Utviklingsverktøyene er fritt tilgjengelige på ulike plattformer og er ikke knyttet til lisenser som kan hindre prosjektets videreutvikling som åpen kildekode. Teknologiene er standardisert og har store aktører som støttespillere, inkludert Google, Apple og Microsoft Støtten for avspilling av lyd og Canvas elementet i HTML 5 oppfylte funksjoner som oppdragsgiveren ønsket i fremtiden. Ønsket om at Java-teknologi skulle benyttes i bakgrunnen for å levere tjenester til klienten kunne oppfylles ved at rammeverkene og web-serverne fullt ut støttet kombinasjonen. 24

Prosessrapport 4.1.1.2 Backbone Backbone er et rammeverk som har det formålet å introdusere MVC-mønsteret i JavaScript. Rammeverket implementerer også et hendelsessystem for data-modellene som andre objekter kan observere. Dette medfører at en Controller-komponent kan observere en modell og handle hvis modellen endrer seg. Et spill er tungt drevet av hendelser og modus- og rammeverket hjelper til å danne en felles standard for hvordan slike hendelser skal programmeres. Ved å benytte seg av Publisher/Subscriber-mønsteret, sikrer rammeverket at kun interessenter lytter på hendelser i systemet, noe som fører til at ressursforbruket holdes på et lavt nivå da ikke alle instanser i systemet mottar informasjon om en hendelse. Rammeverket introduserer støtte for en ruter som lytter på endringer i applikasjonens URL og dynamisk oppretter moduler basert på dette. Dette medfører at applikasjonen kan oppføre seg annerledes basert på hvilken plattform som kjører den (mobil, tablett, pc). Rammeverket kommer med metoder for synkronisering av data mot en server i dataformatet JSON og følger REST prinsippene. Backbone er på under 700 linjer med kode og avgir et svært lite avtrykk i applikasjonen. Videre er det stor frihet for overstyring av metodene backbone tilbyr og det er lite strevsomt å implementere nyte metoder for persistens eller synkronisering. Vi lykkes fint i et forsøk med å få backbone til å synkronisere sine data med HTML 5 sitt persistens API framfor å kommunisere med en server. 25

Prosessrapport Underscore Underscore er et JavaScript bibliotek som innfører hjelpe-metoder for opprettelse og manipulasjon av kolleksjoner (matriser av objekter), binding av objekter til kontekst og manipulasjon og opprettelse av maler. Vi brukte ideer fra underscore til å bygge våre egne komparatorer som sammenlignet spillere. Komparatorene ble benyttet for å traversere gjennom lag og finne spillere som matchet kriterier. Backbone rammeverket bygger på dette biblioteket og innføringen er en nødvendighet. 26

Prosessrapport 4.1.1.3 JQuery JQuery er et bibliotek som abstraherer bort differansene i JavaScript mellom ulike nettlesere. Målet er å oppnå et uniformt grensesnitt for manipulering av HTML dokumenter, CSS-stilark og for asynkron kommunikasjon mellom nettleser og server. Biblioteket innfører også funksjoner for å arbeide med grupper av like elementer og gir oss muligheten til å angi en forelder som har ansvaret for å overvåke hendelser på sine barn. Dette er teknikker som medfører at man kan kontrollere ressursforbruket på maskinen på en enklere måte enn ved å benytte JavaScript uten dette. Abstraksjonen sikrer en viss grad av sikkerhet for at vi får den samme oppførselen når vi manipulerer objekter uten overraskelser relatert til ulike nettlesere eller ulike versjoner av nettleserne. I samarbeid med Backbone rammeverket og maler, blir hver visuell presentasjon av et objekt lagret som en node i minnet. Dette medfører at vi ikke trenger å lete i hele dokumentet for å finne objektet eller deler av det for hver gang vi ønsker å utføre endringer på det. 4.1.1.4 Bootstrap Bootstrap (som er skapt og vedlikeholdt av Mark Otto og Jacob Thornton fra Twitter) er en front-end verktøy for rask utvikling av webapplikasjoner. Det er en samling av CSS og HTML konvensjoner. Den bruker noen av de nyeste nettleserteknikkene for å kunne gi utviklere stilfull typografi, skjemaer, knapper, tabeller, rutenett, navigasjon og alt annet widgets som blir brukt i forskjellige web-applikasjoner for tiden. Innholdet er veldig oppdatert og nye funksjonaliteter blir lagt til fortløpende. Etter at vi hadde planlagt og skissert GUI en til de forskjellige sidene som vi skulle ha, startet vi med kodingen. Nettsidene skulle utformes ved hjelp av HTML5, CSS3, JQuery og JavaScript. Disse verktøyene skulle være med på å skape den visuelle delen av applikasjonen. I tillegg skulle disse samarbeide med play, altså ren Java kode som skulle fremvise de faktiske dataene. 27

Prosessrapport I en veldig tidlig fase skjønte vi at samarbeidet mellom de som skulle utforme gui en ikke fungerte så bra da de måtte jobbe med samme css fil. Vi merket fort at endring eller oppdatering ble noe vanskelig og det oppstod flere konflikter mellom filene (som lå på github). Dette fikk oss til å lure på om det vill være like vanskelig for utenforstående å endre disse filene eller oppdatere gui en. Med tanken på at dette var et åpen kildekode prosjekt, bestemte vi oss for å finne en annen løsning. Vi måtte ha noe som var standardisert. Vi fant to verktøy som kunne tilby dette. Det ene var JQuery UI og det andre var Bootstrap. Begge tilbyr et stort antall med forskjellige, standardiserte GUI elementer. Etter noen dager med testing av begge disse verktøyene, falt valget på bootstrap. Vi fant ut at den var bedre rustet og enklere å bruke for de som skal senere utvide Openfoos. Noe annet som er veldig bra med bootstrap er at de tilbyr eksempler og bruksmåte av verktøyet på sine nettsider. Dette var nyttig for oss og kommer også garantert til å være nyttig for de som skal senere utvide eller vedlikeholde applikasjonen. Siden Bootstrap støtter det nyeste innenfor HTML5 og CSS3, teknologier som vi både er blitt kjent med og jobbet med under prosjektet, så var det lett å sette oss inn i det. 4.1.2 Tjener 4.1.2.1 Java Server Faces JSF er et javabasert rammeverk for webapplikasjoner som følger MVC arkitekturen. Hovedmålet med JSF er brukervennlighet, og utviklingen baserer seg på komponenter. Administrering av disse komponentene er enkelt og utviklere kan lett fange opp hendelser som inntreffer disse. Den er laget for å være fleksibel samt at denne teknologien utnytter eksisterende standard UI og Web konsepter også uten å begrense utviklingen til en bestemt definisjon. Bruk av JSF Noen JSF komponenter er enkle, som for eksempel felter og knapper. Andre er ganske sofistikerte, for eksempel datatabeller eller trær. Utviklere kan kombinere komponenter med metoder og hendelser. 28

Prosessrapport Alle komponenter kan ha egendefinerte hendelser som brukere av applikasjonen kan utløse ved fokus på komponenten. Det er veldig enkelt å generere skjemaer/html-former for applikasjonsmodeller med felter og knapper samt registrering av hendelser og validering. JSF applikasjoner har egendefinert filsystem som utvikleren bør følge. Dette kan endres, men da må utvikleren endre en god del på konfigurasjonsfilen til webapplikasjonen. Dette anbefales ikke av JSF-utviklere. JSF har også god støtte for validering av data som brukeren definerer. Det finnes navigeringskomponenter som utformer sidenavigasjon. Ved å bruke forskjellige språkfiler kan man lett internasjonalisere server-sider og øke tilgjengeligheten i applikasjonen. Java Database Connectivity (JDBC) JDBC er en abstraksjon mellom Java og fysiske databaser. Den definerer en driver for å utføre følgende oppgaver: 1. Etablering av en forbindelse med en relasjonsdatabase. 2. Bruke database tilkoblingen, sende SQL-setninger og få et ResultSet objekt tilbake. 3. Behandle resultatsettene (hentet fra databasen) Java API for RESTful Web Services JAX-RS er Java API for Restful Web Services. APIet gir støtte i å lage web-tjenester i henhold til Representational State Transfer(REST). Java definerer standard REST støtte via JAX-R Bruk av disse teknologiene Nå skal vi beskrive måten vi tok i bruk disse teknologiene og hvordan dette gikk. Som tidligere fortalt er JSF et veldig innholdsrikt rammeverk som blir benyttet for webapplikasjonsutvikling. Gruppemedlemmene som jobbet med server-siden var godt i gang med å tilegne seg kunnskap om JSF og JDBC. Dette tok selvfølgelig en stund. ICEfaces.org tilbyr gratis opplæringen i JSF 29

Prosessrapport på sine nettsider. Disse kursene ble både benyttet og gjennomgått. I tillegg gikk mye av tiden til lesing i forskjellige bøker og nettsider for at vi skulle på en best mulig og rask måte tilegne oss nye kunnskap. Vi ble enige om å starte med back-end samt lage en RESTful web service som kunne sende og ta imot JSON-objekter. Første steg var å sette opp databasen. Ut i fra domenemodellen vår ble databasene konstruert. Nødvendige jar fil som f.eks. mysql-connector-java-5.1.18-bin.jar ble tatt med og andre biblioteker ble importert til applikasjonen. Mye tid gikk på å konfigurere applikasjonens XML filer, alt fra navigasjon, validatorer, egendefinerte komponenter og andre XML filer. Etter at vi hadde gjort en del konfigurasjon og hadde satt opp både databasen og hentet inn nødvendige biblioteker, begynte vi med å lage Repository klasser for hver av diss entitetene: Player, Team, Game og Goal. I disse klassene utviklet vi standardmetoder som jobbet direkte mot databasen. Noen av disse metodene hadde som oppgave å hente ut ting fra databasen, mens andre tok av seg oppgaver som registrering, oppdatering eller sletting av data fra databasen. Disse metodene ble da ikke brukt direkte fra repository klassene. Vi måtte lage kontroller klasser som kalte på disse metodene. Og metodene ble da brukt via kontrollklassene. Dette ble gjort for å kunne ha feilhåndteringen kun på ett sted (repository) og i tillegg skape et eget lag som kun jobbet mot applikasjonens databasetabeller. I tillegg til disse klassene utviklet vi ressurs klasser for hver av disse modellene. Disse klassene som ble laget bruker JAX-RS biblioteket. Så begynte vi med å skape Openfoos nettsidene. Her skulle vi fremvise statistikk samt gi brukere mulighet til å oppdatere sin informasjon. Denne fasen begynte å gå veldig treigt. Vi merket fort at vi brukte flere dager på kun konfigurasjon av XML filer og resultatet ble ikke slik som vi hadde forventet. 30

Prosessrapport Vi måtte ta i bruk tredjeparts komponenter for å kunne skape enkle funksjoner som å laste opp bilder eller gi brukeren mulighet til å poste data til serveren. I tillegg måtte vi ta i bruk flere eksterne rammeverk som Spring JDBC. Vi så at applikasjonens innhentede biblioteker vokste og vokste for hver eneste av de funksjonene som vi ønsket å implementere. I dette tidspunktet hadde vi lagt lag på lag av forskjellige rammeverk. Dette skapte dårlig lagmoral hos oss og fikk oss til lure på om vi hadde valgt riktig verktøy i forhold til oppgaven vi var satt til å gjøre. I tillegg følte vi at dette var overdrevent ressursforbruk i forhold til oppgaven. Vi var nødt til å endre rammeverket som vi hadde brukt så langt i prosjektet og dette måtte gjøres fort. Vi visste at det var en stor risiko i å bytte verktøy da vi var i midten av mars måneden, men vi var nødt til å begynne å se etter andre rammeverk. Selv om det var tungt og risikabelt for oss, så bestemte vi oss for å rive ned alt det vi hadde skapt og begynte med blanke ark. Det var i denne fasen at vi kom bort til et rammeverk som heter Play og etter noen dager med testing av dette rammeverket, valgte vi å gå for det. 4.1.2.2 Play Play er en Java og Scala webapplikasjon rammeverk som integrerer komponentene og API er, som utviklere av moderne web-applikasjoner trenger. Målet med Play Framework er å gjøre det lettere for å utvikle web applikasjoner. Den gjør dette ved å fokusere på å utbygge produktivitet vha RESTful arkitektur. Men hva betyr dette egentlig for deg og meg? Vel, hvis du noen gang har skrevet en Web Application i Java før, vet du uten tvil at det ikke er enkelt å komme i gang. Før du kan begynne, må du konfigurere utallige forskjellige XML-filer. Hvis du setter en ramme på toppen av det (som Struts, Spring MVC, JSF osv.) for å fremskynde utviklingen av webapplikasjonen, har du enda mer konfigurasjon å gjøre. Når du er oppe og går, får du det noe bedre? Egentlig ikke. Alle endringer du gjør, må du rekompilere, pakke ut og redistribuere. Tiden det tar å gå gjennom denne syklusen er et stort 31

Prosessrapport effektivitetsavløp. Hvorfor skal det å være så smertefullt? Vel det trenger ikke å være og det er her Play kommer inn. Noen av de viktigste funksjonene er: Fiks og oppdater - Play har ikke det problemet med å rekompilere, pakke og redistribuere hver gang man gjør en endring. Når du har lagt til en ny funksjon eller fikset en bug, da er det bare å lagre filen og oppdatere siden i nettleseren. Du ser resultatene umiddelbart! (Trenger ikke resetting av serveren) Finn feil raskt - Hvis det er noen feil i applikasjonen, vil de vises i nettleseren på en svært brukervennlig måte slik at du kan finne problemet raskt. Automatisert applikasjonstesting er et vanskelig tema, det er tonnevis av tilnærminger der ute, men play tilbyr verktøy for testing. Tilstandsløs modell - Den er klar for REST. Du kan skalere applikasjoner raskt og effektivt ved å kjøre det samme programmet på flere servere uten å måtte bekymre deg for varige sessioner og redundans. Maler - Play kommer pakket med et mal-system basert på Groovy. Den gjør koden enklere å vedlikeholde og lettere å lese. Det finnes også andre moduler som er tilgjengelige hvis du foretrekker å bruke andre motorer. Play har rammevilkår for jobber(jobs). Dette er en måte å kjøre programlogikk "i bakgrunnen". Play vil ta vare på livssyklusen og timingen. Play er inspirert av Rails rammeverket så kildekoden ser litt ut som RoR(ruby on rails), Django og Symfony. Har tilgang til alle Java biblioteker i tillegg til play rammeverkets egne. 32