Prosessdokumentasjon. 29/5 Hovedprosjekt ingeniørutdanningen. Tittel på hovedprosjektet Tarantell Dashboard

Transkript

1 29/5 Hovedprosjekt ingeniørutdanningen 09 Prosessdokumentasjon Tittel på hovedprosjektet Tarantell Dashboard Gruppe 28 Bjørn Ove Pedersen Stian Dalviken Antall sider 20 Intern veileder Steinar Johannesen Oppdragsgiver Tarantell AS - Kontaktperson Jarle Haakenstad

2 1 Forord Denne prosessdokumentasjonen beskriver utviklingsprosessen til hovedprosjektet for HiO som er laget for Tarantell AS. Prosjektet Tarantell Dashboard er utviklet av Bjørn Ove Pedersen og Stian Dalviken. Dokumentet forklarer hvordan gruppen har arbeidet, og hvilke valg vi har tatt underveis i prosessen. Generell kunnskap om programmering kreves for å på best mulig måte forstå innholdet i denne prosessdokumentasjonen. Gruppen ønsker å tildele Tarantell AS, kontaktperson Jarle Haakenstad og veileder Andreas Heim, en stor takk for deres støtte og bistand i prosjektets utvikling. De har hjulpet oss med å lære mest mulig av dette prosjektet, og å sette oss inn i en reell jobbsituasjon.

3 2 Innholdsfortegnelse 1 Forord Innholdsfortegnelse Innledning Prosjektgruppa Oppdragsgiver Bakgrunn Mål Rammebetingelser og krav Funksjonalitet Struktur Plattform og verktøy Planlegging og metoder Innledende arbeid Fremdriftsplan og arbeidsplan Prosjektdagbok Veiledning Internt samarbeid Eksternt samarbeid Plattform og verktøy J2SE Eclipse Apache Maven Subversion Mortbay Jetty Apache Wicket Spring Framework JUnit log4j Utviklingsprosessen Valg Programmeringsspråk Rammeverk for webgrensesnitt Visuell fremstilling Faser Oppstart Kompetansetilegning Backend utvikling Frontend utvikling Testing Dokumentasjon og avslutning... 15

4 5.3 Problemer og utfordringer Splitting og stripping HTML entiteter Feed wrapping Ikke implementerte ønsker Forhold til oppdragsgiver Kravspesifikasjonen Rolle og innhold Endringer Endelig produkt Avslutning Oppsummering Hva kunne vært gjort bedre? Løsningens fremtid Vedlegg

5 3 Innledning 3.1 Prosjektgruppa Gruppa består av Bjørn Ove Pedersen og Stian Dalviken fra Høgskolen i Oslo avdeling for ingeniørutdanning retning data. Gruppens komposisjon er gjort på bakgrunn av at vi kjenner hverandre sosialt fra før, har gode erfaringer fra tidligere prosjekter i skolesammenheng og har felles faglig interesse, målsetning og oppgaveønske. Vi ønsket å finne en oppgave som innebar mye programmering og som lot oss kombinere noe av den kunnskapen vi har tilegnet oss gjennom skolegangen med nye og aktuelle teknologier. 3.2 Oppdragsgiver Tarantell er et IT konsulentfirma opprettet i år 2000 og har i dag i underkant av 70 ansatte fordelt på flere avdelinger. Bedriften leverer i hovedsak nettbaserte løsninger med fokus på ehandel, portaler, rammeverk, integrasjon og prosesstøtte med tung kompetanse på strategisk bruk av teknologi og brukeropplevelse. Tarantell har solid kompetanse innenfor utvikling av virksomhetskritiske løsninger. De leverer til bedrifter med strenge kvalitets- og sikkerhetskrav, og har utviklet metodeverk og sertifiseringsprogrammer som skal sikre høy leveransekvalitet på alle plan. Med noen av landet fremste spesialister i sine rekker kan de vise til flere prestisjetunge priser for sitt arbeid. 3.3 Bakgrunn Tarantell har tidligere brukt tradisjonelle metoder for å nå ut med fellesinformasjon til sine ansatte, for eksempel gjennom e-post og innlegg på deres offisielle blogg. Som et supplement til dette ønsket bedriften seg nå å få utviklet et system som kunne hente inn data fra alle de eksterne kildene, samle de på en plass og presentere dem via skjermer rundt i lokalet. Dette ville gjøre informasjonen lettere tilgjengelig og mer synlig for både ansatte, kunder og andre besøkende. Bedriften innehar nok kompetanse til å kunne designe et slikt system på egenhånd, men mangel på tid gjorde at de anså dette for å være et godt emne til hovedprosjekt for studenter på datalinjen. 3.4 Mål Målet med oppgaven er å kunne tilby Tarantell en alternativ informasjonskanal for sine ansatte, kunder og andre besøkende. Statusskjermen bør minimum kunne vise statusbeskjeder fra Twitter, blogginnlegg fra Tarantell bloggen og felles e-poster. Systemet bør designes på en slik måte at det enkelt kan konfigureres, driftes og videreutvikles. Videre henviser vi til kravspesifikasjonen for mer utfyllende informasjon. 5

6 3.5 Rammebetingelser og krav I de innledende samtalene mellom oppdragsgiver og gruppa ble krav og rammebetingelser diskutert. Oppdragsgiver hadde flere ufravikelige krav og resten ble utarbeidet i dialog med gruppa. Følgende rammebetingelser ble utarbeidet: Funksjonalitet Rutinene som fantes innad i bedriften var allerede gode og det var en forutsetning at programmet kunne hente sine data fra de allerede eksisterende kildene uten at disse måtte endres. For det første fordi det ville motvirke hensikten med et system som bare skulle fungere som et supplement og for det andre fordi en eller flere av kildene kunne være utenfor bedriftens kontroll. Følgende materiale skulle samles inn: 1. Statusbeskjeder fra bedriftens ansatte lagt ut på websiden Twitter. 2. Blogginnlegg postet på bedriftens offisielle blogg. 3. Felles e-post sendt til bedriftens ansatte. 4. Statistikker vedrørende de ansatte og deres oppdrag. Sistnevnte ble sendt ut som e-post en gang i uken og var ønsket implementert dersom det skulle bli tid til det. Videre skulle systemet presentere den innsamlede informasjonen på en appetittlig måte via et Java basert webgrensesnitt som kjørte mot for eksempel Tomcat eller Jetty. Betingelsene rundt funksjonaliteten var et åpent spørsmål der vi kunne komme med innspill til hva som kunne være morsomt, nyttig og lærerikt å samle inn Struktur Tarantell anså det som vel så viktig hvordan klasseinndelingen og strukturen i koden var som hvordan det endelige resultatet tok seg ut på skjermen. Det var derfor et viktig poeng at koden var strukturert på en slik måte at den fulgte best practices. Dette innebar blant annet hvordan man ønsket at systemet skulle konfigureres og egenskaper skulle endres, hvordan klasser var oppbygd, hvilke ansvarsområder de hadde, hvordan de forholdt seg til hverandre, programmets generelle fleksibilitet og muligheter for å bygges på. I det hele tatt var det mange retningslinjer og ta hensyn til, men samtidig følte vi ikke det var hemmende med klare grenser og at vi holdt vår kreativitet innenfor disse Plattform og verktøy Oppdragsgiver påla oss også å bruke en del verktøy under utviklingsprosessen. Presentasjonen av disse finnes under det bedre egnede avsnittet Planlegging og metoder (punkt 4.7). Her blir det drøftet utviklingsplattform, utviklingsmiljø, rammeverk og verktøy som er brukt og i hvilken grad vi hadde kjennskap til disse fra før. 6

7 4 Planlegging og metoder 4.1 Innledende arbeid Gruppesammensetningen var klar en god stund før det formelt måtte fastsettes, men fordi vi ventet på en dispensasjon fra Høgskolen kom vi likevel ikke så raskt i gang som vi hadde håpet med å finne en oppdragsgiver. Vi hadde heller ingen formening om bedrifter eller organisasjoner som kunne behøve litt hjelp fra studenter ved datalinjen som skulle ha hovedprosjekt. Da vi gikk gjennom skolens egne sider over prosjektforslag kom vi over Tarantell Dashboard som virket som et prosjekt som kunne oppfylle gruppens oppgaveønske veldig godt og samtidig gi oss nok av utfordringer og utviklingsmuligheter. Etter å ha funnet ut litt mer om bedriften via deres hjemmeside valgte vi derfor å kontakte Tarantell for noen innledende møter slik at vi kunne få et klarere og mer helhetlig bilde av oppgavens art, hvordan systemet skulle fungere og hvilke rammebetingelser og krav de stilte. Vårt møte med bedriften var entydig positivt og vi bestemte oss dermed for å ta på oss oppgaven med å lage et slikt system for Tarantell. 4.2 Fremdriftsplan og arbeidsplan Vi utarbeidet tidlig i prosjektet en fremdriftsplan og en arbeidsplan med den hensikt å oppnå oversikt over hva som skulle gjøres og å sette frister for når de enkelte delene av prosjektet skulle være ferdig. Fremdriftsplanen var i utgangspunktet relativt grovt delt inn i noen faser, bestående av backend, frontend, testing, etc., og la opp til at de forskjellige fasene skulle utføres sekvensielt. (se vedlegg, fig. 1) Rundt halvannen måned ut i prosjektperioden endret oppdragsgiver sitt syn og mente det nok ville være en bedre løsning å jobbe med flere av disse fasene parallelt. Vi utarbeidet da en revidert fremdriftsplan (se vedlegg, fig. 2) som vi gikk over sammen med oppdragsgiver for å sikre at alle parter skulle være fornøyde med den planlagte fremdriften. Når vi allerede hadde kommet godt i gang med prosjektet fant vi det også mye enklere å vurdere hvor lang tid vi trengte på hver enkelt del i forhold til den forrige planen. Det viste seg at vi hadde undervurdert hvor lang tid vi behøvde på flere deler slik at en endring i fremdriftsplanen uansett ville presset seg frem i løpet av kort tid. Den reviderte planen tok hensyn til dette med mer tid til hver del, men også mer parallell jobbing mellom prosjektet forskjellige deler. Dokumentasjonen lot vi fortsatt være en ganske adskilt fase på slutten, men satte av litt mer tid så vi kunne konsentrere oss om kun denne og ingenting annet. 4.3 Prosjektdagbok Vi har hele veien ført prosjektdagbok der vi har skrevet ned notater, planer og annen relevant informasjon vi følte det var viktig å ta vare på. Vi fant det ikke nødvendig å lage noe side for dette og nøyde oss med et enkelt Word dokument som har ligget på et privat område på våre hjemmesider. Siden vi som nevnt under forrige punkt valgte å skrive dokumentasjonen etter produktet var ferdig har vi hatt stort utbytte av å føre dagbok. Dette gjorde at detaljer som det var viktig eller nødvendig å få frem ikke ble glemt. 7

8 4.4 Veiledning Vi ble tildelt Steinar Johanessen som vår interne veileder fra Høgskolen. Dette var et tilbud vi helt klart burde benyttet oss mer av. Vi hadde et møte noe over halvveis i prosjektperioden der vi diskuterte hva som hadde vært gjort, hva som burde gjøres og for å få svar på våre spørsmål vedrørende høyskolens involvering i prosjektet, evalueringen etc. Vi kommer også til å be om et nytt møte før presentasjonen av prosjektet. Vi har derimot hatt gjennomgående kontakt med vår veileder hos oppdragsgiver, Andreas Heim. Andreas jobber som systemkonsulent avdeling integrasjon på Tarantell og har tidligere hatt hovedprosjekt på HiO for nettopp bedriften der han nå jobber. Hans kjennskap til et hovedprosjekt fra begge sider og vilje til å bistå med å finne løsninger på tekniske spørsmål gjorde han til en uvurderlig ressurs for gruppa. 4.5 Internt samarbeid Siden vi kun var to stykker på gruppa som kjente hverandre godt fra før av, hadde en god dialog og visste hvordan hverandres arbeidskapasitet og arbeidsmoral var valgte vi å ikke skrive ned en samarbeidsavtale, men å nøye oss med en muntlig diskusjon der det vi kom frem til ble gjeldende som en bindende muntlig avtale. Denne avtalen inneholdt punkter som begrenset seg til gruppas interne samarbeid, arbeidsfordeling og arbeidstider. Det ble heller ikke valgt en gruppeleder som hadde noe spesielt ansvar, men vi ble enige om hvem som burde håndtere forskjellige typer administrative oppgaver. Utfordringene ble tatt opp fortløpende og avgjort i fellesskap. Når vi jobbet sammen på kontoret var det kort vei for å løse problemene og de dagene vi jobbet hjemme løste vi dette ved kommunikasjon over MSN og med Subversion som oppbevaringsplass for dokumentene. 4.6 Eksternt samarbeid (møter) Vi har hele veien hatt en veldig tett og god dialog med vår veileder hos Tarantell. Som avtalt har vi en gang i uken hatt møter der vi har satt oss ned og sett på hva som er gjort i uken som har gått og hva som bør gjøres i den som kommer. Siden disse møtene har blitt holdt relativt ofte har vi hatt mulighet til å fokusere på helt konkrete og spesifikke problemer og i fellesskap forsøkt å finne en løsning både vi som utviklere og bedriften som skal forvalte produktet finner tilfredsstillende. Mot slutten av møtene har vi forsøkt å rette fokuset fremover, sett hvordan vi ligger an i forhold til planer og kravspesifikasjonen og vurdert hva som bør gjøres til neste gang. 4.7 Plattform og verktøy Under følger en kort gjennomgang av plattform, utviklingsmiljø, rammeverk og verktøy vi har brukt under prosessen. Flertallet av disse var ikke selvvalgt og mange av de hadde vi heller ikke kjennskap til fra før. 8

9 4.7.1 J2SE (java.sun.com/javase) Etter samtaler med oppdragsgiver kom vi frem til at plattformen skulle være Java (J2SE). Mer om prosessen rundt utvelgelse av programmeringsspråk under avsnitt Eclipse SDK (eclipse.org) Eclipse er et utviklingsmiljø for programvare. Det var et krav fra arbeidsgiver at vi brukte Eclipse fremfor for eksempel JBuilder som vi tidligere har brukt til Java programmering i skolesammenheng. Denne overgangen var dog helt uproblematisk siden vi fra før hadde kjennskap til Eclipse og slik sett ikke trengte å bruke tid på å lære oss dette Apache Maven (maven.apache.org) Maven 2 er en prosjektmanager og et kraftig verktøy som brukes i alle deler av utviklingsfasen. Maven håndterer avhengigheter til andre komponenter og sørger for at alle nødvendige biblioteker er tilgjengelige. I tillegg til å generere og bygge prosjekter brukes programmet til å kjøre tester, kompilere og pakke koden og oppmuntrer slik til best practices. Vi hadde fra før av verken brukt eller hørt om Maven, men det var et krav fra oppdragsgiver at vi lærte oss dette og brukte det aktivt gjennom hele prosjektperioden Subversion (subversion.tigris.org) Subversion er et versjonskontrollsystem som brukes til å holde rede på utviklingshistorien til en samling med filer og kataloger, for eksempel et prosjekt som vårt. Dette gjør det lettere å jobbe mot de samme dokumentene og fungerer som en backup slik at man kan gå tilbake til tidligere revisjoner hvis utviklingen ikke ble som ønsket. Vi hadde fra før av verken brukt eller hørt om Subversion, men det var et krav fra oppdragsgiver at vi lærte oss dette og brukte det aktivt gjennom hele prosjektperioden Mortbay Jetty (mortbay.org/jetty) Jetty er en webserver som brukes til å kjøre frontend delen av vårt system. Vi valgte å bruke Jetty fremfor det mest opplagte alternativet Apache Tomcat fordi Tomcat er noe mer komplekst med funksjonalitet vi strengt tatt ikke hadde behov for. Jetty er også godt implementert mot Maven og lar deg sjekke små endringer raskt ved bruk av kommandolinja Apache Wicket (wicket.apache.org) Wicket er et lettvekts komponentbasert rammeverk for Java til utvikling av webgrensesnitt. I konseptet ikke ulikt andre mer kjente rammeverk som JavaServer Faces (JSF) og Tapistry. Mer om prosessen rundt utvelgelsen av dette rammeverket under avsnitt

10 4.7.7 Spring Framework (springframework.org) Spring Framework er et applikasjonsrammeverk som er svært populært i Java samfunnet som et alternativ til-, erstatning for- eller et supplement til Enterprise JavaBean (EJB) modellen. Vi har i vårt prosjekt benyttet oss av rammeverkets Inversion Of Control (IOC) container. Med bruk av IOC kan instansiering av objekter flyttes fra koden og ut til ekstern konfigurasjonsfil. Vi hadde fra før av verken brukt eller hørt om Spring IOC, men det var et krav fra oppdragsgiver at vi implementerte bruk av IOC containeren i løsningen JUnit (junit.org) JUnit er det mest brukte rammeverket for enhetstesting i Java. Rammeverket er også godt integrert mot Eclipse og Maven som medfører at mye testing blir automatisert. Det var et krav fra oppdragsgiver at vi brukte JUnit til å teste vårt system, fortrinnsvis backend delen log4j (logging.apache.com/log4j) Log4j er et rammeverk for logging. Rammeverket har et vidt spekter av muligheter og kan enkelt konfigureres til å velge hva, når og hvordan det skal logge. Oppdragsgiver gjorde det tidlig klart for oss at det var ønskelig at vi implementerte rammeverket selv om det på dette stadiet var usikkert i hvilken grad vi kom til å benytte oss av det. 10

11 5 Utviklingsprosessen 5.1 Valg Foruten en mengde små tekniske valg har vi også måttet ta noen større som går direkte på hvordan oppgaven skulle realiseres. Under følger noen av disse Programmeringsspråk Spørsmålet om programmeringsspråk sto ganske åpent for alle parter, men det var fra oppdragsgiver foreslått vi for eksempel kunne bruke et Java basert webrammeverk eller Ruby On Rails. Rails er et fritt webrammeverk skrevet i Ruby som er et objektorientert programmeringsspråk og deler egenskaper med Perl, Python, Lisp, Dylan og CLU. I tillegg snakket vi om Adobe Flex som lager rike internett applikasjoner basert på Flash plattformen. Vi på gruppa anså dette som det mest spennende og aktuelle alternativet, men måtte føye oss for oppdragsgiver som mente det kunne bli litt for tungt og mindre egnet for oppgaven enn de andre språkene. Det som talte mest til Ruby sin fordel er at det er et tolket språk i motsetning til Java som er et kompilert språk. Denne forskjellen ville gi oss mye gratis, spesielt på frontend delen der Java krever noe mer fikling. På den andre siden stilte vi spørsmålstegn ved dette på grunn av prosjektets varighet og det lå et usikkerhetsmoment ved om vi ville klare å levere det produktet oppdragsgiver ønsket i løpet av tidsfristen ved bruk av et språk vi aldri hadde vært borti. Hvis vi skulle stå fast ville det også være mindre hjelp å få fra oppdragsgiver og mindre ressurser på internett om dette språket enn Java. Java var et språk vi kjente godt fra før. Med dette utgangspunktet ville vi unngå tapt tid på grunn av en opplæringsprosess og kunne dermed konsentrere oss om å lage et bedre produkt. Vi var heller ikke i tvil om at selv om vi valgte et språk vi hadde kjennskap til ville det bli nok av utfordringer og muligheter til å lære nye ting både i Java og ved andre deler av prosjektet. Problemløsning ville også bli noe enklere. Det som til syvende og sist satte spikeren i kista for Ruby var hvilket språk vi ville få mest nytte av i en fremtidig jobbsammenheng. Ettersom vi alle var enige om at dette nok ville være Java valgte vi dette Rammeverk for webgrensesnitt Som for programmeringsspråk der vi endte opp med Java var også webrammeverket et relativt åpent spørsmål. Diskusjonen rundt dette kom først i gang rundt halvannen måned ut i prosjektet da vi begynte å jobbe med frontend parallelt med backend som vi hadde holdt på med frem til da. De alternativene det sto mellom var JavaServer Faces (JSF), Spring MVC og Wicket og med unntak av JSF som vi så vidt hadde vært borti før hadde vi ikke noe erfaring med noen av dem. 11

12 Vi brukte da en ukes tid på å søke litt rundt på internett på de forskjellige rammeverkene for å finne ut hvem av dem vi helst ønsket å bruke og endte da med å ganske tidlig eliminere JSF. Dette var på bakgrunn av at det nok var i overkant komplekst i forhold til våre behov og at oppdragsgiver hadde hintet frempå at de fra før av hadde rikelig med erfaring med JSF og gjerne kunne tenke seg å lære litt om et annet rammeverk gjennom oss. Vi gikk dermed motsatt vei av når vi valgte språk og valgte bort det alternativet der det var mest tilgjengelige ressurser og problemløsningen ville bli enklest. Av de to gjenstående rammeverkene Spring MVC og Wicket valgte vi rammeverk på bakgrunn av et enkelt Hello World testprogram for å kartlegge hvem av de som virket enklest i bruk. Valget falt da på Wicket Visuell fremstilling Vi måtte også ta stilling til hvordan det hele skulle fremstilles visuelt på skjermen. Systemet henter ut informasjon som i utgangspunktet er ment å vises på en skjerm som tillater brukerinteraksjon som for eksempel scrolling. Denne muligheten hadde ikke vi og det var definitivt ingen mulighet til å få plass til alt på en side. Valget sto da i utgangspunktet mellom en eller annen type autoscroll eller å bruke en fade effekt der en tekst fader ut og tilbake igjen som den etterfølgende teksten. Begge disse metodene er prinsipielt nokså like fordi de har begge fordelen av å kunne vise mer tekst enn det i utgangspunktet er plass til, men de har også de samme ulempene: De kan raskt medføre komplikasjoner og unntakstilfeller, de er brukt av en gjennomtenkt hensikt, men kan likevel virke som forstyrrende elementer eller være irriterende hvis man leser en tekst som plutselig forsvinner, og man kan bli tvunget til å begynne å lese en tekst midt i eller vente en stund på at starten skal bli synlig igjen. Tarantell ville dermed at vi lagde en løsning der kun den første delen av teksten er synlig, for eksempel de første 1500 tegnene. På denne måten kunne vi også få plass til flere elementer av samme type på siden, for eksempel to bloggposter. Hvor mange elementer og hvor mange tegn et element kan inneholde vil avhenge av skjermstørrelse og oppløsning. At man må gå til kilden for å kunne lese resten av teksten er ikke et problem da det ligger i en statusskjerms natur at den kun skal vise hva som er siste nytt fra en kilde og eventuelt gi en smakebit. 5.2 Faser Utviklingsprosessen har hatt til sammen 6 faser og flere av disse har kjørt parallelt. Disse fasene er oppstart, kompetansetilegning, backend utvikling, frontend utvikling, testing og dokumentasjon og avslutning. Under følger en oppsummering av de 6 fasene hver for seg. For delene som dekker programmeringsbiten av prosjektet har vi forsøkt å skrive en kort historikk for å klargjøre hvordan designet av systemet tok form. 12

13 5.2.1 Oppstart Vi ble veldig godt tatt imot hos Tarantell på vår første arbeidsdag og fikk en liten hilserunde slik at de ansatte fikk vite hvem vi var og hva slags ærend vi hadde hos dem. Etter dette fikk vi tildelt utstyr, laptop, nøkkelkort og et eget kontor så vi fikk sitte uforstyrret og kunne samarbeide og prate uten å sjenere noen. Oppdragsgiver ytret også ønske om at vi brukte kontoret vi hadde fått utdelt mest mulig slik at de kunne titte innom av og til, se på fremdriften eller assistere oss ved behov. Til gjengjeld skulle de stille med veiledning to timer i uken. I utgangspunktet var vi på kontoret mandag, onsdag og fredag, men utover i prosjektperioden ble det av praktiske årsaker også en del mer jobbing hjemmefra enn hva som var tiltenkt. På grunn av en fornuftig fordeling av prosjektet mellom oss og med bruk av noen nyttige verktøy har dette også fungert veldig greit Kompetansetilegning Med så mange nye teknologier og verktøy var det helt nødvendig med en liten fase med kompetansetilegning. Det var essensielt at vi kom raskt i gang med testing, få automatisk generert Eclipse prosjekter og håndtert eksterne biblioteker og avhengigheter på en skikkelig måte allerede fra dag en. Vi leste oss da opp på Maven via tutorials på internett og etter en ukes tid med litt prøving og feiling mestret vi hovedfunksjonaliteten ganske godt. Stian hadde brukt JUnit før så dette var det noe enklere å få et begrep om. Et par uker etter dette tok vi også i bruk Subversion og opprettet et område for filene på Google Code. Vi visste at det også kom til å bli en del ny teknologi å lære seg i forbindelse med frontend, men istedenfor å ta alt på en gang ventet vi med det som var direkte forbundet med frontend til denne fasen var påbegynt Backend utvikling På programmeringsbiten av prosjektet var backend det første vi tok tak i. Vi valgte å starte med å hente såkalte tweets fra Twitter websiden og få disse skrevet ut i Eclipse konsollen. Det eneste kravet vi stilte var at dette skulle gjøres på den enklest tenkelige måten uavhengig av alle andre faktorer og vi endte da opp med en stor klasse som gjorde hele jobben. Dette kunne kanskje se noe planløst ut, men det var viktig for oss å få et visst overblikk før vi tok hensyn til design eller andre ting. Neste skritt var å analysere denne klassen for å finne ut hva slags oppgaver som faktisk ble utført. Det aller første vi måtte gjøre noe med var at det kun var selve statusmeldingen som ble skrevet ut. Vi ønsket også å hente og lagre annen informasjon som var knyttet til statusmeldingen slik som hvilken bruker som la den ut og når det ble gjort. Vi lagde da et verdiobjekt som representerte en tweet og som hadde de feltene vi ønsket. For å omdanne feeden fra Twitter til et slikt verdiobjekt lagde vi også en parser. Den opprinnelige klassen vi startet med, som nå var blitt noe mindre, ble på nytt delt opp i to klasser med hvert sitt ansvarsområde. Den ene av dem hentet feeden fra Twitter, en såkalt fetcher, og den andre lagret verdiobjektene våre i en datastruktur og administrerte disse, en såkalt klient. Disse fire enkle klassene dannet nå grunnlaget for all videre påbygging som ble gjort. 13

14 Frem til da hadde vi hentet ut statusmeldinger via xml feed, men Tarantell ønsket nå at vi også skulle hente json feeden og rss feeden som er de to andre typene Twitter tilbyr. Dette var selvfølgelig ikke nødvendig for systemets funksjonalitet, men mest for øvelsens skyld. På dette tidspunktet trakk vi inn interface basert design som vi mente var den beste løsningen. Dette gjorde at når vi senere skulle hente blogginnlegg og e-poster lett kunne implementere dette i designet. Med relativt like klienter som håndterte tre forskjellige verdiobjekter kunne vi nå dytte alt felles opp i en abstrakt superklasse og ta i bruk genetikk og arv. For å kunne dokumentere backend API et på en skikkelig måte, også for de som eventuelt ikke skulle ha tilgang på produktdokumentasjonen, valgte vi å skrive javadoc. For Tarantell spilte ikke dette noen rolle verken fra eller til fordi API et uansett burde være så selvforklarende at man generelt sett burde forstå det også uten javadoc. Vi hadde blandede erfaringer med dette verktøyet fra før av så det var til tider utfordrende å skrive konkret hva en metode eller klasse gjorde og ikke hvordan eller hvorfor uten å sette det i en større sammenheng. Etter å ha brukt andre klasser som eksempler mener vi at vi klarte å lage javadoc som skulle være tilfredsstillende for de fleste Frontend utvikling Omtrent når vi var ferdige med den delen av backend som hentet statusmeldinger fra Twitter startet vi med frontend og jobbet parallelt med disse videre. Nok en gang ble det en liten fase med kompetansetilegning før vi kunne begynne å bruke Spring, Jetty og Wicket. Også her var hovedfokuset å gjøre ting enkelt i begynnelsen og la tankene rundt det estetiske aspektet ligge. Dette dreide seg kun om ren html og css som vi er fortrolige med og ikke trengte lang tid på. Vi beholdt dermed 1994-svart/hvit-retro-look en til et stykke ut i mai da den endelige siden kom på plass. For at konfigurasjonen av frontend skulle være enklest mulig ble vi instruert til å ta i bruk Spring og dens Inversion Of Control container. IOC lar utviklerne flytte instansiering av objekter fra koden og ut til en ekstern konfigurasjonsfil. For Java er dette gjerne en xml fil. Dette tillater den som administrerer systemet å sette egenskaper run-time istedenfor under kompileringen noe som gjør en slik måte å sette egenskaper både oversiktlig og nyttig Testing Som påkrevd av oppdragsgiver brukte vi JUnit til testing av koden vår, fortrinnsvis av backend. Dette foregikk kontinuerlig gjennom hele prosjektperioden. Vi hadde på forhånd blitt enige om navnsetting (klassenavn + Test) og at alle metoder som inneholdt logikk utover gettere og settere skulle testes. Testhierarkiet ble ordnet i en struktur tilsvarende som for koden og skulle inneholde en klasse TestSuite for hver pakke. Denne kjørte alle tester i sin pakke samlet. Hele hierarkiet skulle ha en MasterTestSuite som kjørte alle TestSuite klassene samlet. Denne inneholdt til slutt 336 tester fordelt på 168 metoder. Vi ble oppmuntret av veileder til å vente med å lage en ny klasse til testene for denne klassen var skrevet. Med andre ord skulle vi skrive tester for den koden vi skulle ønske vi hadde. Når klassen senere skulle opprettes ville det dermed bli såre enkelt å finne ut om den fungerte slik den var ment og håndterte unntakstilfeller på en god måte. I begynnelsen ble dette for oss å sette vogna foran hesten, men det ga mer og mer mening utover i prosjektperioden. Det var dog ikke alltid like enkelt å være flinke med å praktisere dette. 14

15 I begynnelsen var testingen forholdsvis enkel, men ble etter hvert mer komplisert da vi skulle teste klasser som var avhengige av hverandre. Vi tok da i bruk Mockito som er et rammeverk for å lage dummyobjekter. Med Mockito kunne vi spesifisere hvilke og hvor mange metodekall man forventer samt returverdien av disse. Dette gir full kontroll over hva slags data testklassen ville motta og gjorde at vi fikk isolert hendelser til denne klassen alene. Hvis en klasse ikke helt enkelt lar seg teste ved hjelp av JUnit og Mockito kan dette også være en indikasjon på at designet er lite gjennomsiktig og vanskelig å kontrollere. Som arbeidsmaskiner har vi brukt en Mac med norsk OS X og en PC med engelsk Windows Vista samt en hjemmemaskin med norsk Windows XP. Vi fikk da automatisk sjekket løsningens kompabilitet mot flere operativsystemer og språk. Frontend er også testet og funnet fungerende i Internet Explorer, Opera, Firefox og Safari. Når systemet var ferdig utførte vi sluttester av hele løsningen ved å bombardere det med meldinger, innlegg og e-poster av alle slag. Det dukket da opp noen uforutsette problemer i forbindelse med tegnsett og html entiteter som tidligere ikke var blitt plukket opp. Disse feilene ble rettet Dokumentasjon og avslutning Prosjektet begynte og avsluttet på en relativt lik måte for vår del; med dokumentasjon. Vi begynte så smått i slutten av november med prosjektskissen og fra midten til slutten av januar holdt vi på med styringsdokumentasjonen som lå til grunn for prosjektets andre faser. Denne består av arbeidsplan, fremdriftsplan, forprosjektrapport og kravspesfikasjon. Rundt en uke ut i mai gikk vi inn i den avsluttende fasen av prosjektet og jobbingen ble intensivert noe for å sikre at vi skulle komme i mål. Backend begynte nå å bli ferdig og det handlet mest om å få samlet løse tråder i frontend på programmeringsbiten. Parallelt med dette startet andremann på sluttdokumentasjonen. Her fant vi det greiest å begynne med prosessrapporten som tar for seg prosessen fra ide til produkt og var fin å starte med som en liten repetisjon. Vi tok så for oss produktrapporten som er et dokument beregnet på de som i fremtiden skal vedlikeholde og videreutvikle systemet. Her har gruppa beskrevet selve systemet, dets virkemåte og oppbygning, på en slik måte at det gjør arbeidet med å utvide løsningens funksjonalitet så enkel som mulig. Siden systemet ikke krever noen brukerinteraksjon fant vi det ikke naturlig å lage noen brukerveiledning heller. Dette måtte i så fall bli noe som gikk gjennom konfigurasjonsfila for systemet, men dette var såpass sammenfallende med produktet og dokumentasjonen av dette at vi valgte å ta den biten med der isteden. Helt til slutt byttet vi ut den midlertidige hjemmesiden vi har hatt gjennom prosjektet med en permanent side i samme stil som Tarantell Dashboard. Vi sørget også for å få ryddet opp litt i Subversion området vårt så dette skulle være oversiktlig. 5.3 Problemer og utfordringer I dette avsnittet tar vi for oss noen av de veldig mange konkrete utfordringene vi har hatt mens vi har laget denne løsningen for å vise resonnementet som ligger til grunn for resultatet. 15

16 5.3.1 Splitting og stripping Denne utfordringen oppsto som en direkte konsekvens av vårt valg av den visuelle presentasjonen av systemet. Se punkt for en nærmere beskrivelse av problemstillingen. Med den løsningen vi valgte for å vise tekst det i utgangspunktet ikke var plass til på siden fikk vi plutselig en utfordring med hvordan en lang bloggpost eller fellesmail kunne deles. Problemene sto bokstavelig talt i kø: Hvor mange tegn skal en paragraf <p> tag (tom linje) representere? Hvordan stiller vi oss eller løser vi et scenario der avsnittet blir kuttet uten at tagger lukkes? Hva skjer hvis teksten begynner med en bilde <img> tag? Bildet kunne for eksempel være så stort at det ikke var plass til tekst eller i verste fall så stort at det tok opp plassen som skulle brukes til andre elementer? Dette var bare noen av en veldig stor mengde situasjoner som kunne oppstå og som vi ikke visste hvordan vi skulle håndtere. For å gjøre vondt verre hadde vi utsatt denne problemstillingen til det aller siste i håp om at en lys ide ville dukke opp og vi begynte nå å havne i en ordentlig tidsknipe. Etter å ha prøvd oss frem på ting som å laste strengen inn i Java klassen HTMLDocument og et par andre forslag bestemte vi oss for at nå var det viktigste å komme i mål med noe som dekket de fleste tilfeller og som var enkelt. Vi satt oss dermed ned og definerte betydningen av en statusskjerm og kom frem til at denne ikke nødvendigvis må vise blogginnlegget på samme form som når det sto på bloggen. Vi endte dermed med å bruke regulære uttrykk for å strippe taggen for html. Dette viste seg som en veldig enkel, men brukbar løsning på problemet. Det gjorde også arbeidet med å telle antall tegn som skulle vises veldig enkel da det ikke lenger var nødvendig å ta hensyn til at noen tegn kunne være tagger som ikke skulle telles med osv. Derav begrepet splitting og stripping HTML entiteter For å uttrykke spesialbokstaver- og tegn (f. eks. æ, ø, å) eller tegn som vanligvis er reservert html syntaks (f. eks. <, >) på en webside brukes html entiteter. En liten æ vil da kunne skrives som æ Da vi hadde begynt på å parse blogginnlegg dukket det opp et problem. Selv om det ikke var av de vanskeligste å løse var det nokså finurlig. Det viste seg nemlig at rss feeden til bloggen inneholdt tegnet & i alle link tagger (en per post). Dette er et ugyldig tegn i rss. Til å begynne med virket det som en fornuftig løsning å bruke regulære uttrykk til å endre dette tegnet til & som er dets html entitet. Det vi oppnådde med dette var og samtidig skifte ut alle & tegnene i alle html entitetene i alle postene slik at eksempelvis en liten æ nå ble vist som &#230. Ved å unngå at rss leseren vår ikke ville parse den ugyldige feeden hadde vi isteden fått et annet problem. Vi endte med å løse det ved å bruke regulære uttrykk for å fjerne hele link taggen for alle postene siden den uansett ikke hadde noen funksjon for oss. 16

17 5.3.3 Feed wrapping Programmet inneholder et fetcher interface som kan implementeres av klasser som ønsker å fetche (hente ned) feed fra en eller annen kilde. Eksempelvis inneholder vårt program tre slike: en som henter fra websider som krever autentisering, en som henter fra websider som ikke krever autentisering og en som henter fra e-post. Dette interfacet har metoden fetch() som skal returnere feeden og denne feeden måtte da være et objekt som sto godt til både websider og mail. Noe slikt finnes ikke! Dette problemet ga oss reell hodebry da vi fra før av hadde returnert feeden fra Twitter og bloggen som en html formattert streng, noe som overhode ikke passet for objekt som representerer et e-post lager. Vi hadde sett for oss at et slikt problem kunne komme til å dukke opp, men også at det fantes måter å komme rundt. Det gjaldt bare å velge den som ikke krevde de helt store strukturelle endringene og som lot API et beholde sin simplisitet. Etter å ha diskutert en del frem og tilbake falt til slutt valget på å opprette et wrapper objekt som fikk navnet Feed hvis eneste hensikt var å pakke inn den egentlige feeden. Dette gjorde at vi ikke trengte å konvertere og herje med den opprinnelige feeden til det ugjenkjennelige bare så det skulle finnes en fellesnevner. Løsningen tillater også fetcheren å returnere hvilket objekt det enn skal være så lenge det er pakket inn i det generiske Feed objektet. 5.4 Ikke implementerte ønsker Ene og alene av tidsmessige hensyn var det et par ting vi ikke rakk å implementere. Det ene punktet er beskrevet nærmere i avsnitt 6 om kravspesifikasjonen. Av andre ting skulle vi gjerne sett at klientene i systemet kunne lagre sine verdiobjekter i en database fremfor listestrukturen som nå er brukt. Det ville gjort løsningen mindre sårbar for en omstart fordi dataene, også relativt gamle data som kanskje ikke lenger er tilgjengelige hos kilden, ville vært lagret på fil. Hibernate rammeverket skulle brukes til å løse dette. Dette er dog litt utenfor hva oppgaven krevde og i våre øyne ikke det helt store tapet uansett når vitsen er å vise siste nytt. 5.5 Forhold til oppdragsgiver Forholdet til vår oppdragsgiver Tarantell har gjennom hele prosjektperioden vært veldig godt på alle plan inklusive det sosiale og faglige. Vårt førsteinntrykk av en bedrift med høy faglig kompetanse som visste hva de var ute etter sto seg gjennom perioden. Noe som gjorde det spesielt artig å jobbe for nettopp Tarantell var at de så mulighetene dette prosjektet ga dem bortenfor selve produktet de satt igjen med. Det var et poeng for dem at dette var en periode alle skulle høste lærdom av, også dem selv. Noen av valgene vi har tatt reflekterer også dette hensynet slik som det webrammeverket vi til slutt endte opp med. På grunn av denne innstillingen prøvde vi også mange forskjellige ting som ikke kommer like godt til syne i sluttproduktet. Et eksempel som derimot er godt synlig er de tre forskjellige typer feed som er hentet fra Twitter som ikke har noe med de funksjonelle behovene å gjøre, men kun var ment som læring i bruk av de forskjellige API ene, se forskjeller og likheter og ikke minst få en innføring i interface basert design. 17

18 6 Kravspesifikasjonen Selve kravspesifikasjonen følger med sluttdokumentasjonen som et eget dokument og er ikke gjengitt i dette avsnittet. 6.1 Rolle og innhold Kravspesifikasjonen har hatt en sentral rolle under hele utviklingen. Vi kjente fra før av til viktigheten av en god kravspesifikasjon og hadde mange møter med oppdragsgiver i oppstartsfasen for å fastsette de nødvendige kravene til funksjon, design og bruk av forskjellige teknologier og verktøy. Vi bestemte oss i samråd med oppdragsgiver om å legge oss på en linje som var konkret, men ikke spesielt detaljorientert og som dermed ga rom for mindre ikke-funksjonelle endringer av løsningen uten at kravspesifikasjonen måtte endres. 6.2 Endringer Når vi satt opp kravspesifikasjonen ønsket vi å ta hensyn til flere tilfeller, også en eventuell situasjon der vi lå foran den planlagte fremdriften. Vi følte at det var en realistisk mulighet for at dette kunne skje. Tanken var at vi ved tid til overs skulle implementere en funksjon der statistikk om de ansatte og deres oppdrag kunne vises på statusskjermen. Gjerne grafisk fremstilt. Disse opplysningene ble sendt per e-post og siden det skulle implementeres en e-post leser ville halve jobben alt være gjort. Det viste seg imidlertid at når vi kom til begynnelsen av mai lå vi i underkant av en uke bak fremdriftsplanen og denne funksjonen måtte kuttes fra kravspesifikasjonen. 6.3 Endelig produkt Vi vurderte hele tiden produktet opp mot den gjeldende kravspesifikasjonen. Siden det tross alt dukket opp ganske få problemer som påvirket kravspesifikasjonen trengte vi bare å gjøre denne ene endringen som er beskrevet i forrige punkt. Vi mener at vi har oppnådd alle de funksjonelle kravene, og forhåpentligvis også de strukturelle, som er beskrevet i kravspesifikasjonen. 18

19 7 Avslutning 7.1 Oppsummering Prosjektperioden har vært både utfordrende, lærerik og hektisk og på en måte blir det rart at den snart er over når det er dette som har vært hverdagen det siste halve året. Vi har sett på dette som en fin mulighet til å lære både teknisk, faglig og hvordan ting fungerer i praksis i arbeidslivet før vi skal ut dit selv og føler vi har tatt vare på denne sjansen. Vi har oppnådd oppgavens mål og det faglige utbyttet har vært stort. Samarbeidet både internt på gruppa og med arbeidsgiver har fungert godt hele veien. Vi vil gjerne rette en stor takk til Tarantell og spesielt til vår veileder Andreas Heim for at han har vært en støttespiller gjennom hele perioden og hjulpet oss til å lage et produkt vi både tror og håper bedriften vil få nytte av i tiden fremover. 7.2 Hva kunne vært gjort bedre? Dersom vi hadde gjort det samme prosjektet om igjen, ville vi nok prøvd å arbeide mer effektivt i startfasen av prosjektet. Hadde vi gjort det, hadde vi med stor sannsynelighet hatt tid til å få lagt inn en funksjon som genererer statistikk ut fra status på pågående prosjekter. Vi ville også ønsket å hatt mer kontakt med vår interne veileder på HiO. 7.3 Løsningens fremtid En mulig fremtid for dette produktet er å få utvidet systemet til å inneholde funksjonen vi ikke fikk nok tid til å gjøre - statistikk. Systemet er også lagd på en slik måte at det skal være enkelt å legge til nye funksjoner, slik at mer informasjon på websiden kan vises. Uten at dette har blitt sagt konkret, vil vi tro at Tarantell AS vil komme til å bruke dette systemet i sine lokaler. 19

20 8 Vedlegg Fig. 1: Opprinnelig fremdriftsplan Fig. 2: Revidert fremdriftsplan 20