Openfoos er et prosjekt som skal hjelpe foosball spillere med å holde rede på kamper, poengsum, rangering og lag.
Vi ønsker å innføre digitale funksjoner i et sosialt, morsomt- og enkelt spill.

Prosjeketets mål er å realisere en god og stabil plattform på ny og spennende web-teknologi.
Med dette ønsker vi å vise at teknologier som HTML 5,
Web-sockets og Javascript, i kombinasjon med Java,
kan benyttes for å lage dynamiske, raske og velfungerende systemer.

Kildekode

Prosjekt -
Skisse

For -
Prosjekt

Prosjekt -
Rapport

Amir

Amir
Ghoreshi

Amir studerer til å bli data-ingeniør.
Han startet utdanningen i 2009 og håper å studere videre til en master-grad ved NTNU

Amir har arbeidet mye med systemet som støtter applikasjonen vår i bakgrunnen.
Dette inkluderer drift og oppsettet av databasen, samt. programerings grensesnittet mellom serveren og spillet.

Marcel

Marcel
Eggum

Marcel studerer Informatikk.
Han startet utdanningen i 2009 og håper å studere videre til en master-grad i nettverskprogramering på Universitetet i Oslo.

I dette prosjektet har han arbeidet med brukergrensesnittet og programering av spill-forløpet.
Selv om han ikke er en god foosball spiller, så synes han at utfordringen med å lage et raskt- og dynamisk web-grensesnitt er spennende og utfordrende.

Neberd

Neberd
Salimi

Neberd studerer til å bli data-ingeniør.
Han startet utdanningen i 2009 og håper å studere videre til en master-grad ved NTNU.

I dette prosjektet har Neberd arbeidet med spillerprofilen og implementeringen av brukergrensesnitt. Videre har Neberd jobbet med implementeringen av spiller-statistikken.

Valentin

Valentin Rey
Rosell

Valentin studerer til å bli data-ingeniør.
Han startet utdanningen i 2009 og vurderer å fortsette utdannelsen sin ved universitetet eller høyskolen i Oslo.

Valentin har med implementeringen av administrasjons grensesnittet og utformingen av dette systemet.

HIOA Logica

Uke 1

Prosjektet er i gang og vi har etablert oss på kontorene til Logica.
Kravspesifikasjonen er presentert til oss av oppdragsgiveren og de første møtene blir benyttet for å skissere ned enkelte user-stories for registrering av spillere, mål og kamper.

Uke 2

Vi skal starte med å bygge en "Proof of Concept" modell av applikasjonen der vi fokuserer på en avgrenset, forenklet del av selve spillet.
Formålet med dette er å forsøke å bevise at sentrale deler av spillet kan løses med de teknologiene vi velger og at oppdragsgiveren får mulighet til å se i hvilken retning vi tenker.

Uke 3

Hele uken har gått til å sette seg inn i teknologier som HTML 5 og Javascript.
Vi ser allerede nå at det fort blir kronglete å skrive mye Javascript kode og at dette må organiseres på en måte.
Vi tror at løsningen kanskje ligger i å benytte en MVC basert arkitektur på klient siden for å skille data-modeller og grensesnitt.
Av dette har vi sett på rammeverk som Backbone, Spine, JavascriptMVC og Ember.

Kommunikasjon mellom tjener og klient bør også gå på en ryddig og pen måte. Til dette har vi startet å se på implementeringen av et RESTful grensesnitt på tjeneren.

Trello kommer inn som et prosjektstyrings-verktøy etter en lengere evaluering. Verktøyet er enkelt og blir konfigurert slik at vi får en enkel liste med backlog og sprinter. Opplæringstiden er minimal og verktøyet er enklere å sette opp en f.eks Jira.
Hovedpoenget er å få tilgang til informasjon om prosjektet enten man sitter hjemme, på skolen eller på arbeidsplassen.

Arbeidet med det grafiske grensesnittet starter smått.
Videre har vi startet å titte på JavaServer Faces for implementering av logikk på tjener siden.

Uke 4

Gruppen har gått for Backbone som et MV* rammeverk på klient siden.
Prosjektet er godt dokumentert og har flere store støttespillere bak seg.

Det er vanskelig å skrive spill logikk med Javascript når man ikke er godt kjent med språket.
Vi merker fort at debugging av koden er vanskelig og at sammarbeid best fungerer om man par-programerer.

En Github konto blir satt opp for prosjektet og vi begynner å synkronisere kode mellom oss.
Github lar oss enkelt klone prosjektet ut i flere grener slik at vi enkelt kan prøve ut ideer og funksjoner uten frykt for å klusse til den fungerende kildekoden.

Det er absolutt anbefalt å implementere github som en del av prosjektet deres. Tiden det tar å sette seg inn i systemet blir raskt inntjent når man ser hvor enkelt man synkronisere.

Det grafiske grensesnittet blir tegnet opp og presentert for oppdragsgiveren.
For første gang har vi en felles utsikt å gå ut ifra.

Uke 1

RESTful implementasjonen i Java er litt for tung i dette øyeblikket. Vi velger å benytte PHP og rammeverket Slim for å simulere samme funksjonalitet.
Det er ønskelig å spare tid for å fokusere på spill logikken

Uke 2

Programering av spill logikken er tung og det fremkommer flere problemer for hver funksjon som blir implementert.
Mot slutten av uken er et spill fortsatt ikke gjennomførbart og det er en stressende, presset situasjon.
Problemet ligger i forståelsen av Backbone og Model-View mønsteret. Det er vanskelig å fatte hva som skal ligge hvor fordi javascript og backbone gir deg mye frihet og få grenser. Det er litt tungt når man ikke har mye erfaring med programering av spill og Javascript.

Mot slutten av uken presenterer vi likevel en forenklet version av applikasjonen vår til oppdragsgiveren da sprinten er ferdig.
På møterommet har vi en stor skjerm med touch-egenskaper som vi presenterer spillet på.
Et enkelt spill blir gjennomført og konstruktive tilbakemeldinger ble gitt. Vi er bare sjel-galde for at vi klarte å levere en fungerende applikasjon mot slutten av sprinten. De siste dagene var svært stressende.

Hemmeligheten med Backbone er enkel, opprett modeller med data og bind opp grensesnitt mot dem. Programer grensesnittene til å lytte etter endringer på modellene og utfør oppgaver etter dette.
Backbone fungerer ufattelig bra når det først fungerer- og hele spillet er på mindre enn 300 linjer med kode.

Uke 3

Denne uken har nesten alle gruppemedlemmer benyttet sin tid til å arbeide med andre skolefag på grunn av snarlige innleveringsfrister. Enkelte av oss forbereder seg også til konte-eksamen neste uke.

Uke 4

En forenklet domene modell, use-case diagram og klassediagram blir skissert opp vi begynner smått å arbeide med implementasjonen av at lag spill. På dette tidspunktet går vi tilbake til start og sletter all koden vi hadde tidligere.

Vi plukker opp bøker om hvordan man skal utforme et API-grensesnitt og gjøre det på en slik god måte at klienter kan enkelt koble seg opp og kommunisere med serveren vår.

Halve gruppen har konte-eksamen denne uken og vi er mye borte fra kontoret. Samtidig begynner vi å se på Websocket-teknologien og vi øsnker å utforske om vi kan bygge effektivt API mot serveren ved bruk av denne teknologien framfor å sende vanlige HTTP kommunikasjons-pakker til serveren. Man unngår et overveldene overhead og dette muligjør for en god prestasjon mellom serveren og klienter som har lav prosessor kraft og minne-kapasitet.
Vi forsøker på sette opp en enkel Websocket server- men lykkes ikke med dette, selv etter 3 dager.
Mye av problemet er relatert til at Websocket spesifikasjonen er veldig ny og den har endret seg fortløpende gjennom 2010 og 2011. Mange av eksemplene vi prøver å lære fra, fungerer ikke lenger fordi implementering av websockets har forandret seg i den grad selv ikke klassene og metodene er like lenger.

Vi forsøker etter beste evne å finne bøker om emnet- men det står desverre svært lite skrevet om dette foreløpig. Mot slutten av uken får vi litt hjelp av en konsulet hos Logica- og vi får da også vite at Websocket teknologien er fortsatt på et veldig ungt stadiet.
Mot slutten av uken blir Websockets lagt på is intill videre.

Uke 1

Gruppen deler seg opp stykker der 1 person jobber med spillet i front-end. En person jobber med implementeringen av API og database modellen som vi tegnet opp i forrige uke- og 2 personer jobber med å lære seg JavaServer Faces og hva som skal gjøres for å sette opp en forenklet spiller-profil.

Store deler av uken går til å lære seg rammeverkene- og vi jobber stort sett separert med våre problemer.
Det er veldig vanselig å jobbe med selve spillet i javascript og man ser fort at det blir rot i koden som blir skrevet.
Det er vanskelig å forstå hvordan abeidet mellom klassene logisk sett skal delegeres og hvilken klasser som skal ha ansvar for hva. Det blir fort slik at uønskede hendelser oppstår og spiller har mange feil.
Det man ser ofte at noen av klassene sitter på utdatert informasjon.
På dette tidspunktet begynner vi å se på ulike design-patterns for spillet vårt for å se om vi kan implementere et godt mønster som vil medføre at vi får en god, logisk struktur på applikasjonen vår. Desverre er det litt vanskelig å finne et møster som passer i vårt tilfelle da vi er noe uerfarne på det området.

På dette tidspunktet er vi desverre nødt til å be om en utsettelse fra vår oppdragsgiver og ber om at demonstrasjonen av vårt produkt blir usatt med en uke. Vi er desverre ikke lenger sikre på om vi klarer å nå vår deadline for denne sprinten.

Uke 2

Gruppen fortsetter å lese seg opp på ulike bøker og ser en del opplæringsvideoer om både JavaServer Faces, Javascirpt og Backbone.
Progresjonen er treg og vi har fortsatt ikke klart å verken få opp et fungerende lag spill med 4 innloggende spillere. Spillet er nå stykket opp etter en bane, spillere, lag, spill og dommer. Den logiske strukturen hjelper på å plassere kode på korrekte steder, men det er vanskelig å samsvare med MVC-mønsteret som Backbone ønsker å forholde seg inn på. Hovedproplemene ligger i at alle elementene må kommunisere sammen og de avhenger av å vite informasjon om hverandre.

Et eksempel på dette er hvordan det kun skal være mulig å logge ut en spiller hvis spilleren allerede er logget inn og spillet fortsatt ikke er startet. Det kommer også opp en del spørsmål vedrørende om hvor sikkert det er å sende informasjon i klar-tekst til serveren.

Vår progresjon med JavaServer Faces er desverre også lav. I løpet av den siste perioden har vi fortsatt ikke lykkes med å sette opp et vel-fungerende miljø og en enkel spiller profil som er koblet opp mot databasen vår.
Vi merker at det er problematisk å utføre enkle operasjoner fordi rammeverket ofte krever støtte av andre rammeverk og biblioteker (f.eks ved fil-opplasting). Dette medfører at vi må benytte mye tid på å sette oss inn i de andre rammeverkene og bibliotekene, bare for å være i stand til å velge en riktig løsning.

Videre må man lære seg å kjenne det nye rammeverket og vi merker at dagene går fort når man prøver å rette opp i feil som oppstår. Selv om vi kjenner til konseptene ved utvikling av web-applikasjoner fra .NET og PHP- så er man nødt til å sette seg inn i syntaksen for måten rammeverkene har valgt å løse opp problemet sitt på.

Dette medfører at vi velger å se på andre rammeverk som heller kan levere en mer komplett løsning til problemet vårt. Vi er nå langt bedre kjent med utfordringene som har fremkommet og vet hvilken støtte vi trenger.

Vi bgynner å se på "Play!" som er et tynnere rammeverk som fokuserer på MVC-arkitekturen og at innebygd støtte for routing mot kontroll-komponenter. Gruppen velger å bruke 2 dager på lesing for å avdekke om dette kan benyttes til vårt formål og mot slutten av uken og helgen bruker vi tiden på å skrive om systemet fra grunnen av.

Uke 3

På Mandag bestemmer gruppen ser for å gå for Play! som et rammeverk da dette var et langt mer tilpasset rammeverk til vårt behov. Utviklingen og konverteringen fortsetter og det er et stort press på å fullføre til demonstrasjonen på Fredag. På dette tidspunktet jobber vi adskilt med våre arbeidsområder.

Tiden vi har til rådighet er liten og vi forsøker så godt vi kan med å presse frem et produkt som kan vise til funksjonalitet som var lovet i Sprint 2. Det oppstår problemer med synkronisering av data mellom tjener og klient og mye av tiden går med til å feilsøke og skrive om kode på både tjeneren og klienten.

Torsdag natt arbeides det med å skape et grensesnitt til demonstrasjonen slik at vi har mulighet til å fremvise noe som er abstraktert bort alt det tekniske som foregår i bakgrunnen.
Under demonstrasjonen går det desverre delvis dårlig på grunn av feil i systemet vårt. Vi får blandt annet problemer med å registrere nye spillere og enkelte deler av brukergrenesnittet forvirrer oppdragsgiveren.
Systemet gjennomgikk en omfattende test før demonstrasjonen- men visse endringer i systemet ble også utført bare en halv-time før presentasjon.
Det ble blandt annet oppdaget av hadde glemt å implementere en funksjon for angring av mål. Programeringsoppgaven var ikke vanskelig- men det var unødvendig risikabelt å innføre ny funksjonalitet.

Oppdragsgiveren var desverre ikke fornøyd med systemet slik det var presentert og det ble uttrykt en tvil på om systemet i det hele tatt fungerer.

Uke 4

Gruppen har denne uken lagt fokus på andre skolefag.

Uke 1

Arbeidet starter med profilen og administrasjonsgrensesnittet.
Gammel kode blir kastet ut og vi starter med å skrive om applikasjonen tilpasset til play rammeverket.

Vi gjorde oss kjent med ORM (JPA og Hibernate) systemet til play og valgte å konvertere data-modellene våre til entiteter som systemet forstod.
Dette åpnet for et bedre utviklingsmiljø fordi det var enklere å rive ned og bygge opp database modellen og dermed gjøre raske endringer i datastrukturen vår.
Ulempen med dette var desverre at vi måtte sette oss tungt inn i ORM (Object-Rational-Mapper) teknologien for å få dette til å gå knirkefritt.

Uke 2

Spiller profilen og påloggingsmodulen for denne blir ferdigstillt.
Nye templates blir programert for alle sidene ut i fra skissene vi lagde i workshops tidligere.
På spillersiden har vi oppdaget problemer med synkronisering av data når serveren bruker lang tid på å svare.

Vi simulerer ventig på serversiden for å fremprovosere problemene og implementerer også en indikator for å vise når klienten forsøker å kommunisere med tjeneren i bakgrunnen.
Dette medfører at brukeren har mulighet til å få en visuell indikasjon på at arbeid utføres i bakgrunnen.
Samtidig begynner arbeidet med implementering av ELO-algoritmen og rangering av spillere.

Uke 3

Gruppen benytter tiden på å ferdigstille arbeid forbundet med andre skolefag.
3 av gruppens medlemmer har oppgaver relatert til eksamen.

Uke 4

Implementering av spillerprofilen er nå nærmest ferdig og gruppen har startet utivklingen av adminitrasjons-grensesnittet.
Spillet beregner nå rangering og poengsum og det er mulig å enkelt hente ut spiller statistikk og beregne ferdighet på spillerene.

Uke 1

Store deler av tiden denne uken går med til å implementere ferdig administrasjons grensesnittet og å implementere innlogging via RFID kort.
Vi starter også arbeidet med å rydde opp og finpusse kodebasen i bakgrunnen. I tillegg skrives deler av det grafiske grensesnittet om og finpusses samt. at man gjennomfører testing på flere ulike skjermstørrelser og maskiner.
I tilegg til dette benyttes det store mengder med tid på å feilsøke systemet manuelt og videreføringen av profilene.

Uke 2

Siste demonstrasjon av produktet presentres for oppdragsgiveren. Det settes opp et lokalt miljø for openfoos og medarbeidere får benyttet seg av produktet fullt ut.

Uke 3

Ferdigstilling av prosess og produktdokumentasjonen er hovedfokuset i denne perioden.

Måneder

  • Januar

  • Februar

  • Mars

  • April

  • Mai