References Hovedprosjekt ved Høgskolen i Oslo 2010 Prosessrapport

Transkript

1 PROSESSRAPPORT

2 FORORD Denne rapporten tar for seg den prosessen vi har vært gjennom i løpet av hovedprosjektet. Her er informasjonen om de forskjellige valgene vi har måttet ta, og begrunnelsen for disse. Rapporten er myntet på sensor, veileder, oppdragsgiver og kan eventuelt leses av interessenter. Vi forutsetter at leseren har en generell IT-forståelse. Rapporten er delt opp i flere underkapitler. For å få en helhetlig forståelse av prosessen, bør den leses fra start til slutt. Ønskes det en dypere teknisk forståelse av produktet, henviser vi til produktrapporten, hvor de tekniske spesifikasjonene er beskrevet. I denne oppgaven brukes en del tekniske ord, som ikke er definert i det norske språket. Flertallsformene av slike ord kan derfor tenkes skrevet på forskjellige måter, men vi har valgt å skrive de på den engelske måten. Eksempel på dette er ordet plugin. Her har vi derfor i flertallsform valgt å bruke ordet plugins. For interesserte lesere følger det med en del vedlegg, som har til hensikt å gi en bedre forståelse av prosjektet og prosessen. 2 S ide

3 INNHOLDSFORTEGNELSE Forord Innledning Gruppen Bedriften Dagens situasjon Oppgaven Mål og rammebetingelser Mål Rammebetingelser Planlegging Oppstartsfasen Planleggingsverktøy Aptopappa DBDesigner Microsoft Office Visio Valg av operativsystem Valg programmeringsspråk Dokumentasjon Metodikk Agile metoder XP extreme Programming Lean Testing Anvendt programvare S ide

4 4.1 Eclipse Gedit VI, VIM og GVIM Subversion Firebug Anvendt rammeverk og programmeringsspråk Aptoma Framework MVC Modellaget - Model Presentasjonslaget - View Kontrollerlaget - Controller PHP JavaScript AJAX MySQL Om utviklingsprosessen Oppsett av utviklingsmiljø CODE AFW DrPublish Læringsperiode 1- Verktøykassa Læringsperiode 2- Refaktorering en prosess av kontinuerlig forbedring Programmering av plugin Utfordringer Installasjon av Linux Å finne et godt utviklingsprogram i Linux Oppsett av AFW og DrPublish S ide

5 6.5.4 Å lage god kode i JavaScript og PHP... Feil! Bokmerke er ikke definert Optimalisering av brukergrensesnitt Kontakt med Aptoma Kommunikasjon Innad i gruppen Med oppdragsgiver Erfaringer med valgt metodikk Erfaringer med agile metoder Erfaringer med XP Erfaringer med Lean Erfaringer med enhetstesting Kravspesifikasjon og dens rolle Vår bruk av kravspesifikasjon Avvik fra kravspesifikasjon Kritikk Resultat Hvordan jobbe med et uferdig produkt Hvordan er det å lage en plugin i DrPublish? Avslutning Oppnådde mål Pluginens fremtid Ting vi kunne gjort annerledes Konklusjon S ide

6 1 INNLEDNING Denne innledningen inneholder en introduksjon av prosjektgruppen, bedriften vi har jobbet for og oppgaven vi har hatt. Videre går vi mer detaljert inn på bakgrunn for oppgaven, hva den var, og hvilke mål vi har hatt for den. 1.1 GRUPPEN Dette hovedprosjektet er gjennomført av hovedprosjektgruppe nummer 4 ved Høgskolen i Oslo, år Gruppen består av: Navn Klasse Studentnummer Øyvind Shahin Berntsen Kheradmandi 3ac S Henning Sjørbotten 3ac S Fredrick Strøm 3ac S Erik Leirstrand Øvrum 3ac S Alle på gruppen kjente hverandre godt fra før, da vi har jobbet sammen ved flere anledninger i løpet av tiden på Høgskolen. Vi kjente derfor hverandres sterke og svake sider, og var trygge på at gruppen kom til å fungere bra sammen. Forventningene vi hadde til hverandre var basert på solide erfaringer. Ambisjonsnivået vårt var likt, og kommunikasjonen og samarbeidsevnen mellom oss, visste vi var god. 1.2 BEDRIFTEN Aptoma er et produkt- og programvareutviklingsselskap for mediebransjen, som blant annet leverer programmer til store nettsteder som VG Nett og Ekstra Bladet. Deres fremste produkt er DrFront, et program hvor man på en enkel måte kan sanntidsredigere nettavisers forsider. Bedriften har hovedkontor i Akersgata i Oslo, og et avdelingskontor i Göteborg. De har ni ansatte innen program- og markedsutvikling. Daglig leder for Aptoma, og veileder for vår gruppe, er Geir Berset. Han har fire års erfaring med studentprosjekter fra Høgskolen i Oslo. 6 S ide

7 Aptoma fokuserer utelukkende på nye medier. Deres mål er å lage attraktive og nyskapende produkter, som skal være kjernen i deres kunders virksomhet. De mener selv at fokuset deres på å løse virkelige brukeres behov, kvalitet i programmene og kundenes lønnsomhet er årsaken til suksessen. 1.3 DAGENS SITUASJON Dagens situasjon er en verden der man mer og mer trenger enkle og brukervennlige programmer som raskt viser resultat. Medieindustrien er i en spennende og utfordrende epoke. Avisene opplever nedgangstider da papirutgavene selger mindre, mens oppsvingene på nettet er desto større. Det blir stadig viktigere med en lav inngangsterskel, høy funksjonalitet, et stort fokus på kontinuerlig utvikling og integrering av ny funksjonalitet i denne bransjen. Aptoma er den første bedriften i verden som har laget et program for sanntidsredigering av nettavisers forsider. Aptoma utvikler et nytt program som heter DrPublish. Det er et artikkelredigeringsprogram hvor det er blitt gjort mulig å legge til tilleggsfunksjonalitet selv, i form av plugins. Programmet er fortsatt i utviklingsfasen, og vil mest sannsynlig bli lansert for salg i løpet av neste år. Det blir stadig mer populært i programutviklingsbransjen å gi sluttbrukeren mulighet for å legge til ønsket funksjonalitet selv. Aptoma vil at deres kunder skal ha mulighet for å lage sine egne plugins, som de igjen kan dele og/eller selge til andre som benytter seg av programmet. Dette kan sammenlignes med såkalte apps til Apples iphone, hvor hvem som helst kan lage slike applikasjoner, og distribuere det på egenhånd. På denne måten forsøker de å gjøre DrPublish mer attraktivt og fleksibelt for brukeren. Aptoma var ikke sikre på hvor vanskelig det var for utenforstående å sette seg inn i og lage plugins for DrPublish, og ønsket derfor at vi skulle utforske dette. 1.4 OPPGAVEN Oppgaven fant vi på Høgskolen sin hjemmeside for hovedprosjekt. Aptoma AS hadde lagt ut en oppgave som alle på gruppen syntes virket spennende. Oppgaven lød som følger: «Aptoma er programvareleverandør for mediabransjen (f.eks VG Nett, Ekstra Bladet, m.m.). For tiden jobber vi med et innovativt artikkelsystem som kompletterer vårt frontredigerings-system. Vi er snart i lanseringsfasen, og vi trenger å få utviklet spennende og fremtidsrettede plug-ins til systemet som benytter og setter våre APIs på prøve. Dine plug-ins vil potensielt bli brukt i store nettavisredaksjoner, 7 S ide

8 og du vil ha mulighet for umiddelbare tilbakemeldinger fra engasjerte brukere. På denne måten lærer du å lage programvare som brukerne verdsetter.» Det vi likte best med oppgaven, var muligheten for å produsere noe som faktisk kunne komme i produksjon. Etter en samtale med Aptoma skjønte vi at dette var en oppgave vi alle ville jobbe med, så vi bestemte oss for denne. Oppgaven ble til slutt å lage en plugin som skulle hjelpe brukeren med å ta vare på referansemateriell knyttet til artikler. Samtidig skulle vi fungere som testpersoner for Aptomas nye program DrPublish. Deres API var uferdig, og måtte testes for feil og mangler. 1.5 MÅL OG RAMMEBETINGELSER Mål Målet med oppgaven er å levere et best mulig produkt, som vil komme faktiske bruker til gode, innenfor de tidsrammer prosjektet er gitt. Pluginen bør i første omgang inneholde: Mulighet for lagring av dokumenter tilhørende en bestemt artikkel. Et enkelt og brukervennlig grensesnitt. En opplisting av alt opplastet materiale. Mulighet for bruker å åpne filer i pluginen. Hvis tilgjengelig tid tillater det, er vi som gruppe og Aptoma som bedrift, åpne for muligheten til å utvikle flere plugins. Våre faglige mål ved prosjektet: Få god kjennskap til PHP og JavaScript, samt interaksjon av de to språkene. Vi vil bruke dette fordi PHP er et av de aller mest brukte programmeringsspråkene, og i kombinasjon med JavaScript har man et godt spekter av muligheter. Få innblikk i hvordan det er å jobbe for et produkt- og utviklingsselskap. Vi ønsker å skaffe oss gode erfaringer og kontakter for tiden som kommer etter utdannelsen. Vi har som mål å lage noe som vil bli brukt etter vi er ferdig med prosjektet, og ikke bare tenkte oppgaver, som vi ellers har gjort i skolegangen. 8 S ide

9 1.5.2 Rammebetingelser Vi skal bruke PHP og JavaScript som programmeringsspråk og vi skal jobbe på Aptomas eget rammeverk, AFW. Vi skal jobbe på operativsystemet Linux. Prosjektet varer fra 4. januar 2010 til 31. mai Så godt det lar seg gjøre, skal vi jevnlig ha kontakt med VGs journalister og Aptoma angående ønsket funksjonalitet. 9 S ide

10 2 PLANLEGGING Dette kapittelet gir en gjennomgang og forklaring av planleggingsprosess. Det viser de utfordringer og hindringer vi har hatt, samt hvilke verktøy vi har brukt. 2.1 OPPSTARTSFASEN Til å begynne med, hadde vi et eget forslag til oppgave: videreutvikle en prosjektoppgave vi hadde hatt i faget Programutvikling ved Høgskolen. Dette var et program som systemerte konsertavholdelser. En på gruppen kom med forslag om å videreutvikle og skrive om programmet til Scala, som vi hadde hørt fra Bekk Consulting var et språk som på sikt kanskje kom til å ta over for Java. Vi forhørte oss med Bekk Consulting om de kunne tenke seg å være eksterne veiledere for oss, noe de stilte seg positive til. Alle medlemmene av gruppen følte derimot ikke for å jobbe med Scala, og vi så oss derfor om etter flere forslag til oppgaver. Kontakten med Aptoma ble formidlet gjennom Aptoma sin annonse for hovedprosjektgruppe på Høgskolen. Da vi møtte Aptoma, tok de veldig godt imot oss. Vi fikk en følelse av at de virkelig ville ha oss der. Det virket som om miljøet hos Aptoma var godt og ville passe oss bra, samtidig som vi fikk et inntrykk av at de var dyktige. Dette bidro til at vi raskt bestemte oss for at det skulle bli et hovedprosjekt der. Vi hadde et nytt møte med Aptoma før jul, hvor vi snakket om mulig oppgave og inngikk en muntlig kontrakt med Aptoma om at vi skulle ha hovedprosjekt der. En endelig oppgave kom vi ikke frem til på det tidspunkt, men vi avtalte i stedet at vi skulle tenke mer igjennom hva vi ønsket å gjøre frem til et nytt møte etter juleferien. Vi var innom flere mulige oppgaver og hadde først lyst på å lage en børskurve-plugin. Dette følte vi at ikke passet så godt for vanlige nettaviser som for eksempel VG, så vi forkastet denne ideen. Deretter vurderte vi en plugin for artikkelkommentering, men vi slo fra oss dette da det ville bli for stort og tidkrevende for et studentprosjekt. Valget falt til slutt på en kilde- /referanseplugin til artikler. Det første vi gjorde var å skissere innholdet av pluginen. Geir fra Aptoma snakket med journalister i VG og forhørte seg om de ønsket en slik plugin, og hvilke krav de eventuelt hadde til den. Journalistene mente det var en god ide, men at hvis pluginen skulle bli tatt i bruk, måtte den være enkel og rask å bruke. Dette støttet de antagelsene vi hadde gjort på forhånd. Etter at skisseringen 10 S ide

11 var ferdig hadde vi et møte med Aptoma hvor vi ville diskutere utseende, samt hva som var bra og dårlig. Det kom frem at Aptoma ikke syntes utseendet var så viktig å tenke på i begynnelsen, men de ønsket heller at vi satte oss skikkelig inn i måten de kodet på, og at vi fikk dette inn i fingrene. 2.2 PLANLEGGINGSVERKTØY Aptopappa Aptopappa er Aptoma sitt eget system for planlegging og oppgavebehandling, som følger Scrummodellen. Selv om vi ikke har utviklet etter Scrum, så har vi utviklet smidig, og da fungerer fortsatt Aptopappa godt for oss. Dette, sammen med et ønske fra Aptoma om at vi skulle bruke Aptopappa, gjorde at vi valgte å bruke det som utviklingsverktøy. Figur Aptopappa Aptopappa er nett-basert og endringer vises umiddelbart etter utførelse. Dette gjorde at alle på gruppen kunne logge inn og endre på oppgaver, eller holde seg oppdatert på hva de andre gjorde, til enhver tid. 11 S ide

12 Figur Aktiv oppgave i Aptopappa Ved å gå inn på hver enkelt oppgave kunne vi sette et tidsestimat, og fylle ut hvor mange timer hver enkelt hadde jobbet på de forskjellige oppgavene, sammen med eventuelle kommentarer til utført arbeid. Dette ga oss en god oversikt over hvem som jobbet med hva, men like viktig var det at vi fikk en oversikt over hva vi hadde gjort tidligere i prosjektet DBDesigner 4 DBDesigner 4 er et lite verktøy til å visuelt modellere databaser på en enkel og grei måte spesielt tilrettelagt for MySQL. Det finnes både designmodus til å lage og oppdatere databaser og querymodus for å lage avanserte spørringer som man kan putte direkte inn i koden. Vi brukte det i begynnelsen for å sette opp entitets-relasjons diagrammer (ER-diagram) Microsoft Office Visio 2007 Vi har også benyttet Visio for å sette opp ER-diagram, ettersom DBDesigner hadde begrensinger på hvordan databasen måtte settes opp. Ved å bruke Visio fikk vi mer kontroll, og kunne sette opp tabellene som vi ville. ER-diagrammene ble også mer oversiktlige. 2.3 VALG AV OPERATIVSYSTEM Når det kommer til valg av operativsystem, stod vi helt fritt til å velge. Det eneste kravet var at siden det er en webapplikasjon, måtte utviklingssystemet ha en lokal webserver, som måtte ha støtte for PHP. Det var mange faktorer som spilte inn på valget av operativsystem. Vi ønsket i første rekke å utvikle i Microsoft Windows-miljøet, fordi som før nevnt, at samtlige på gruppen jobber i dette miljøet til vanlig, og med applikasjoner som kjører under dette. Derfor forsøkte vi først å sette opp 12 S ide

13 utviklingsmiljøet i Windows. Vi benyttet Microsoft Windows XP og Microsoft Windows 7. Aptoma hadde ikke erfaringer med å utvikle på maskiner som kjørte Microsoft Windows, noe som gjorde at vi måtte prøve oss frem. Ingen av gruppemedlemmene hadde heller utviklet PHP i Windows mot en lokal webserver. Et tips fra Aptoma var å installere et program som heter XAMPP, da dette skulle hjelpe oss. ( XAMPP er en gratis AMP-server 1. Under installasjonen fikk vi problemer med konfigurasjonene. Ettersom flesteparten hos Aptoma utvikler i en eller annen form for Linux, og hadde lite erfaringer med å sette opp utviklingsmiljøet på Windows, valgte vi å gå bort fra XAMPP og heller gå over til Linux. På denne måten fikk vi større muligheter til å motta hjelp til oppsett av utviklingsmiljøet, noe som ville spare oss for tid. Valget falt først på en Linux-installasjon som installeres gjennom Windows, kalt Wubi. Wubi lovet oss en enkel, sikker og gratis applikasjon som lar seg installere og avinstallere i Windows. Dette virket lett og kontrollert, da man fikk en mappe på harddisken inne i Windows der Ubuntu-installasjon lå. Dermed slapp vi alt av repartisjoneringer og formatering av harddisker. Wubi virket bra en kort stund. Problemene oppstod hvis vi gjorde en av følgende operasjoner; oppdatere systemet med automatiske oppdateringer eller sette maskinen i dvalemodus. Vi opplevde at hvis vi gjorde dette, krasjet systemet og det måtte foretas en fullstendig reinstallasjon av ikke bare operativsystemet, men også rammeverket vi hadde brukt tid på å sette opp. Vi konkluderte med at Wubi var altfor ustabilt å utvikle under. Vi lastet derfor ned Ubuntu 9.10 karmic koala. Ubuntu er kanskje den mest kjente og brukervennlige Linux-utgaven for mennesker som er vant med programmer og OS fra Microsoft. Ubuntu deklarerer selv: Ubuntu Linux for human beings. Dette installerte vi rett fra cd, på en egen partisjon. Med en ren og stabil Linux-installasjon kom vi fint i gang med resten av oppsettet. 1 AMP- Server, er en server som er satt opp med Apache, Mysql, Perl, Python og PHP. 13 S ide

14 2.4 VALG PROGRAMMERINGSSPRÅK Aptoma har laget DrPublish slik at man kan utvikle plugins i hvilket som helst programmeringsspråk. Derfor kunne vi i teorien utvikle pluginen i det språket vi selv ønsket. Det var likevel ganske naturlig for oss å velge PHP, siden Aptoma utviklet i dette. PHP var heller ikke et språk vi hadde jobbet med tidligere, og det var derfor noe vi ønsket å lære oss. Etter å ha valgt PHP, var det naturlig for oss å også benytte oss av JavaScript. Dette var for å få en brukervennlig og dynamisk layout. 2.5 DOKUMENTASJON Av tidligere erfaringer, visste vi at det var lurt å komme tidlig i gang med dokumenteringen. Allerede i planleggingsfasen, startet vi å skrive dagbok for prosjektet, med hva vi gjorde og hvilke avgjørelser vi tok. I tillegg satt vi opp fremtidsplan for de frister utenfra som vi måtte overholde, og de vi selv satte. Selv om planen ikke ble fulgt til punkt og prikke, var det en god pekepinn for hvor vi burde ligge i prosjektet til enhver tid. 14 S ide

15 3 METODIKK Vi vil i dette kapittelet gi en beskrivelse av utviklingsmetodikkene vi har tatt i bruk, og de forskjellige aspektene ved disse. 3.1 AGILE METODER XP extreme Programming Extreme Programming (XP) er den utviklingsmetodikken vi har fulgt tettest. Det er en metodikk som innebærer regelmessig testing, og korte iterasjoner mellom hver ferdigstillelse. Resultatene fra disse testene gjorde at vi kontinuerlig kunne utbedre feil. Kravspesifikasjoner og lignende settes ikke på forhånd. I henhold til XP har vi hele tiden vært åpne for å endre på produktet. Det har foregått en konstant dialog mellom oss som utviklere og kunden/oppdragsgiver. I vårt tilfelle ble kunden Aptoma selv, ettersom DrPublish fortsatt er i utviklingsfasen. Geir har derfor fungert som vår kundekontakt, og han har handlet på vegne av sine fremtidige kunder. I XP er det viktig at selve programmeringen kommer i gang allerede fra dag en. Siden vi måtte igjennom en læringsfase, startet vi ikke med selve prosjektet før etter en stund. Vi lagde mange mindre prototyper underveis, som Geir kom med endringsforslag til. Dette reduserte risker og ga både Geir og oss en bedre forståelse av produkt og eventuelle krav. Et av hovedfokusene våre har vært refaktorering av kode. Refaktorering er å endre på kode uten å endre på hva den opprinnelig gjør. Det blir gjort fordi man ønsker høyere kvalitet på koden. Nesten halvparten av tiden forventes å bruke på forbedring og endring av kode som allerede eksisterer. Vi har ikke hatt fokus på parprogrammering, bortsett fra noen timer i begynnelsen av prosjektet. Vi lå på ulike nivåer kunnskapsmessig angående PHP, og følte vi hadde mest fremdrift når vi jobbet hver for oss. Når vi lurte på noe, spurte vi hverandre og lærte av hverandre. Vi satt opp en kravspesifikasjon under forprosjektet. Denne beskrev ikke hvordan vi skulle gjøre ting, men hvorfor. På denne måten kunne vi finne de mest velegnede metodene å utvikle på, og vi kunne endre ting som det passet oss underveis. Dette er beskrevet mer nøye i kapittel S ide

16 3.1.2 Lean Vi har også trukket inn elementer fra Lean inn i utviklingen av pluginen. Lean er en effektiviseringsog forbedringsmetodologi, som opprinnelig kommer fra den japanske bilindustrien. Fokus i Lean er å konstant forbedre og levere verdi til brukeren ved å identifisere og redusere følgende: Redusere feil og standardisere arbeid: dette fører til at prosessen blir mer pålitelig og fører til mindre kostnader, bedre kvalitet og mindre risiko. Redusere syklus tiden: dette gjør det lettere å levere det kunden ønsker når kunden ønsker det. Forbedre effektiviteten i prosessen: dette reduserer utviklingskostnadene som ikke tilfører noen verdi for kundens brukeropplevelse. Vi har fokusert på at pluginen skal virke raskt og være responsiv for brukeren. Det er blitt brukt mye tid på å fjerne elementer fra det opprinnelige utseendet til pluginen, slik at alt unødvendig nå er tatt bort. Vi har hatt mange prototyper, og derfor fått en rekke tilbakemeldinger underveis i prosjekttiden på programmet vi har utviklet. 3.2 TESTING Vi hadde litt erfaring med testing fra forrige semester, og kjente derfor nytteverdien som lå i det. Vi hadde tidligere hørt om såkalt testdreven utvikling, altså at man først skriver testene til metodene, deretter jobbe med å utvikle frem til testene lyser grønt. Dette var noe vi vurderte i begynnelsen, da det vi hadde lest mye positivt om det. Aptoma tester derimot kun det de mener er hensiktsmessige å teste, alt annet blir stående utestet. Når en metode først er blitt laget og testet, vil den alltid gjøre det den skal så lenge testene gir grønne lys. På denne måten har vi kunnet refaktorere koden, og fortsatt vært sikre på at metodene vi har endret fortsatt har fungert som de opprinnelig var tenkt. I tillegg har vi slik vært sikre på at endringer vi gjør et sted i koden, ikke har ødelagt for viktige metoder andre steder. 16 S ide

17 4 ANVENDT PROGRAMVARE Kapittelet gir oversikt og forklaring til de forskjellige programmene vi har benyttet oss av i prosjektet. Siden valg av programvare var en viktig prosess, har vi også tatt med de programmene vi har valgt å gå bort i fra, og hvorfor vi gjorde det. 4.1 ECLIPSE Hovedutviklingsverktøyet vi har benyttet oss av i dette prosjektet, er Eclipse for PHP Developers. Versjonen heter Galileo SR2 for Linux. Begrunnelsen for dette, er at vi fra tidligere har jobbet i Eclipse, og at vi synes det har et godt og oversiktlig grensesnitt, som gir en god brukeropplevelse. Under et møte med Aptoma, nevnte en av de ansatte at han brukte Eclipse PHP. Vi bestemte oss for å prøve ut programmet, siden vi hadde brukt det tidligere, og vi ikke var fornøyd med programmene vi brukte til da. Det viste seg å fungere svært bra. Eclipse ga oss gode syntaksfarger, et godt klassehierarki og automatisk kodefullførelse. Se figur 4.1, for bilde fra Eclipse. Figur 4.1 Vi kan dele programmet opp i tre hoveddeler: #1 er en oversikt over filer og mapper i prosjektet, #2 er selve koden og #3 som er en oversikt over alle metoder i koden filen som vises. 17 S ide

18 4.2 GEDIT Gedit er et UTF-8-kompatibelt tekstredigeringsprogram som gis ut gjennom GNU ( General Public License ), noe som gjør det til en fri programvare. Brukergrensesnittet er enkelt og rent, og gjenkjenner også flere typer kodespråk. Ved gjenkjenning av et språk, bruker den syntaksfremheving for å gjøre koden mer lettlest og oversiktlig. Dette syntes vi var veldig fint i begynnelsen, da det krevde lite forkunnskaper for å komme godt inn i det. Gedit minte oss om Notepad++ fra Windows-miljøet, med mulighet for å bruke faner slik at man raskt og enkelt kan redigere på flere forskjellige filer i samme vindu. Man kan også her få på nummerering av linjer, slik at vi enklere kunne finne tilbake til en gitt kodelinje. 4.3 VI, VIM OG GVIM Vi var også innom VIM (VImproved), som utviklingsverktøy. Noe av det vanskelige og spesielle med editorene som baserer seg på VI (VI, Vim og GVim), er blant annet at det er bygget opp med to forskjellige modus, en er innsettingsmodus og den andre er en kommandomodus. Alle snarveier og hurtigtaster var kompliserte og veldig annerledes i forhold til det vi var vant med fra Microsoftmiljøer. Dette var en av grunnene til at vi fortsatte å lete etter alternative utviklingsverktøy. 4.4 SUBVERSION Subversion er et versjonskontrollverktøy, og er kanskje det viktigste utviklingsverktøyet vi har brukt. Vi har i tidligere prosjekter vurdert å bruke liknende verktøy, men har kommet frem til at prosjektene ikke var store nok. Det mest praktiske ved bruk av Subversion var at vi kunne jobbe på de samme delene av koden, så lenge vi ikke endret nøyaktig de samme kodelinjene. Etter å ha brukt Subversion har vi forstått at slike verktøy er særdeles praktiske og gir en helt annen dimensjon til utviklingsprosessen. Det er nå vanskelig å forestille seg hvordan det er mulig å jobbe uten. 18 S ide

19 4.5 FIREBUG Firebug er en utvidelse til Mozilla Firefox og er et feilsøkings- og utviklingsverktøy, som vi har brukt mye i utviklingen av pluginen. Uten denne utvidelsen, ville feilsøking og feilrettingsarbeidet blitt mye vanskeligere, og tatt mye lengre tid. Firebug hjalp oss til å inspisere og endre HTML, CSS og JavaScript direkte i nettsidene. For eksempel kan man midlertidig endre på CSS filer, slik at man ser hvordan endringene vil påvirke siden. Man kan markere elementer for å vise HTML- og CSS-koden til de ønskede elementene. Firebug plukker dessuten opp feil og feilkoder som sendes mellom nettleseren og webserveren. Slik vi ser det nå, er Firebug et må ha verktøy hvis man skal utvikle web-applikasjoner i Firefox. 19 S ide

20 5 ANVENDT RAMMEVERK OG PROGRAMMERINGSSPRÅK I dette kapittelet vil vi presentere programmeringsspråkene vi har benyttet oss av og det rammeverket vi har brukt. 5.1 APTOMA FRAMEWORK «AFW IS THE BEST FRAMEWORK FOR WEB-PROFESSIONALS CREATING HIGH-PERFORMANCE APPLICATIONS, ENFORCING QUALITY THROUGH STRICTNESS AND FEEDBACK» - APTOMA Aptoma Framework (heretter kalt AFW) er Aptoma sitt eget rammeverk. Dette er et rammeverk de selv har utviklet og som blir benyttet i utviklingen av alle Aptoma sine produkter, i tillegg til vår egen plugin. AFW er i følge Aptoma veldig bra til å vedlikeholde en utviklingsprosess som baserer seg på Lean 2 metodikk. Rammeverket gir gode og hurtige tilbakemeldinger gjennom sofistikerte test-pakker og obligatoriske enhetstester. AFW har en egen kodestandard, noe som bidrar til effektiv produktutvikling, samtidig som den bidrar til å minimere kodefeil. Rammeverket er også, i følge Aptoma, eksepsjonelt bra på skalering, faktisk fem ganger raskere en det raskeste rammeverket Aptoma har testet. Siden vi benytter oss av AFW, har vi tilgang på rammeverket sine innebygde metoder, for eksempel når vi skal hente ut POST og GET variabler, kjøre spørringer mot databasen og eller når vi skrev enhetstester. Disse metodene har innebygget validering og feilhåndtering noe som begrenser vårt behov for validering av brukerdata. 5.2 MVC For å utvikle en god applikasjon, er det nødvendig med en ryddig og strukturert kode. Aptoma benytter seg av MVC. Dette står for Model-View-Controller, og er en metode å dele applikasjonen inn i forskjellige lag. Det var et krav fra Aptoma at vi skulle bruke dette når vi utviklet for dem. Vi syntes dette passet oss bra, da vi tidligere hadde jobbet med lagdeling i faget Webapplikasjoner. 2 Lean (egentlig: Lean manufacturing / norsk: Slank produksjon) betegner en produksjonsmetodikk for fremstilling av varer og tjenester. 20 S ide

21 Figur MVC Modellaget - Model Modellaget er selve knytingen til databasen, som brukes for å hente ut data. Modellaget mottar metodekall fra kontrolleren. Der utfører den oppgaven sin, før den returnerer resultatet tilbake til kontrolleren Presentasjonslaget - View Presentasjonslaget er det laget brukeren ser. Det var viktig for Aptoma å få dette laget separert fra de andre, da det kun er her det trengs å gjøre om, hvis man ønsker programmet på en annen plattform Kontrollerlaget - Controller Kontrollerlaget er selve kjernen i pluginen, den tar for seg av alle funksjonene. Dette laget arbeider uavhengig av presentasjonslaget, og kan derfor settes sammen med andre presentasjonslag uten problem. Kontrolleren er bindeleddet mellom modellaget og presentasjonslaget. 21 S ide

22 5.3 PHP PHP er et programmeringsspråk som kjører på serversiden, og brukes til å designe nettsider. En av grunnene til vi ønsket å ha oppgaven hos Aptoma, var at de benyttet programmeringsspråket PHP. Vi har programmert objektorientert PHP sammen med MVC, for å gjøre koden så ryddig og lettfattelig som mulig. Aptoma sitt rammeverk er skrevet i PHP og for at vi skulle kunne benytte oss av deres ferdige metoder, måtte vi skrive i samme språk. 5.4 JAVASCRIPT JavaScript er en teknologi vi bruker for å få en dynamisk nettside, og et forbedret brukergrensesnitt. Dette øker brukervennligheten, og gjør pluginen finere å se på. Vi har benyttet tilleggsbiblioteket JQuery under utviklingen. JQuery ga oss mange ferdigskrevne funksjoner, som gjorde at vi slapp å bruke masse tid på å finne opp metoder som allerede fantes. Vi har stort sett brukt JQuery for utseendets skyld, slik at utseendet skulle bli stilrent og flyte så effektivt for brukeren som mulig. 5.5 AJAX For å slippe stadige nedlastinger av pluginen, har vi benyttet oss av AJAX-teknologien. AJAX er en utviklingsteknikk for interaktive nettsider, slik at de skal føles mer responsive for bruker. Dette gjøres ved at sidene utveksler litt og litt data med serveren i bakgrunnen, i stedet for å laste hele siden på nytt hver gang brukeren gjør en forandring. 5.6 MYSQL MySQL er et databaseadministrasjonssystem vi bruker for å lagre og hente ut informasjon fra. Grunnen til vi valgte en MySQL-database som lagringsenhet, er at Aptoma bruker samme type database og for å kunne bruke de ferdige metodene i deres rammeverk, måtte vi ha en MySQLdatabase. Rammeverket til Aptoma har metoder for å legge til i databasen, så vi trengte bare å skrive SQL-spørringene. 22 S ide

23 6 OM UTVIKLINGSPROSESSEN Her er en detaljert gjennomgang av utviklingsprosessen av pluginen. Dette inkluderer oppsett av miljø, læringsprosesser, programmeringen av plugin og om kommunikasjonen i prosjektprosessen. 6.1 OPPSETT AV UTVIKLINGSMILJØ Foruten bruk av Aptomas rammeverk, ble det stilt forskjellige krav til utviklingsmiljøet vi jobbet i. Under følger en gjennomgang av de utfordringene vi kom bort i når det gjaldt oppsettet av vårt utviklingsmiljø. Figur 6.1Viser avhengigheter mellom AFW, DrPublish og References CODE Det neste skrittet var å få opp det Aptoma kaller CODE (COmmon Developer Environment). Dette er en oppskrift som beskriver hva som må installeres av programmer, samt hvilke innstillinger man må velge i de forskjellige programmene. Vi konkluderte med at vi trengte en LAMP-server, versjonshåndteringsprogrammet Subversion, minne-cache, verktøyet Memcached, PHP-debuggeren xdebug og profileringsverktøyet KCachegrind. Dette var beskrevet klart som en punktliste i CODE oppsettet, men problemer oppstod da flere innstillinger ikke var riktige, eller ikke med i det hele tatt i dokumentasjonen. Derfor måtte vi kontakte Aptoma flere ganger for å få hjelp til konfigurasjoner og innstillinger som ikke stemte. For eksempel står det i oppsettet: sudo aptitude install memcached sudo vi /etc/php5/apache2/conf.d/memcache.ini Then remove the ; from memcache.ini 23 S ide

24 Problemet med den oppskriften var at det ikke var noen semikolon å fjerne fra memcache.ini. Noen feil var det derfor i denne dokumentasjonen, men takket være godt samarbeid gruppemedlemmene imellom, samt god kommunikasjon og hjelp fra Aptoma, fikk vi maskinene opp på CODE AFW Det neste skrittet i oppsett av utviklingsmiljø var å sette opp Aptoma sitt rammeverk AFW, og få dets innebygde tester til å gi oss grønne lys. Vi begynte med å hente ut den siste revisjonen av AFW via Subversion, og la denne tilgjengelig for webserveren på harddiskene våre. Da dette var gjort gikk vi inn på webserveren, og kjørte AFW sine innebygde setup-tester. Her får man advarsler om feil og mangler i oppsettet. Dette er et godt gjennomført verktøy som gir gode og detaljerte meldinger om hva som mangler i oppsettet, og hvordan manglene rettes opp. Aptoma har delt testene i to kategorier: Påkrevde tester som alle må være godkjent før man begynner utviklingen med AFW, og anbefalte tester som ikke er systemkritiske, men som vil begrense funksjonaliteten. Selv om vi hadde fulgt dokumentasjonen til Aptoma nøyaktig, fikk vi en del røde lys på noen av testene. Blant annet manglet det databaser, i tillegg til konfigurasjon som setter Apache-serveren til å bruke UTF-8 som standard tegnsett. Figur Mislykkede tester Figur Vellykkede tester 24 S ide

25 Takket være de gode feilmeldingene klarte vi å luke ut feilene, og få grønt lys for å begynne utviklingen DrPublish Neste steg for oss ble å sette opp DrPublish lokalt i utviklingsmiljøet. Det fantes ingen egen dokumentasjon for dette, men med hjelp fra Aptoma fikk vi satt opp dette på noen dager. Det var en avansert prosess, så vi valgte å lage et eget dokument for oppsettet. Vi håper dermed at fremtidige brukere kan slippe å møte problemene vi har hatt med dette. Fremgangsmåten vi kom frem til, har vi vedlagt i Oppsett av DrPublish. 6.2 LÆRINGSPERIODE 1- VERKTØYKASSA Etter planleggingen av prosjektet begynte læringsfasen. Det var et ønske fra Aptoma at vi skulle lære oss det grunnleggende i de forskjellige teknologiene vi skulle benytte oss av, før vi begynte å arbeide med selve prosjektoppgaven. Vi startet opp med å utvikle enkle PHP-funksjoner, og prøvde å implementere disse i DrPublish. Flere problemer oppstod her, da DrPublish fortsatt er et program under utvikling og dokumentasjonen var noe mangelfull. Etter samtaler med ansatte i Aptoma hvor vi fikk innføring i hvordan man skulle implementere plugin, fikk vi vår første enkle plugin til å fungere. Dermed startet vi for alvor med å lære oss profesjonell bruk av PHP og JavaScript. Vi laget en vanlig filopplaster i HTML, PHP og JavaScript, som gjorde at pluginen lastet på nytt hver gang en fil ble lastet opp til databasen. JavaScript ble bare brukt for å skrive ut feilmeldinger. I tillegg til PHP og JavaScript, måtte vi sette oss inn i AJAX. For å benytte oss av AJAX og JavaScript valgte vi også sette oss inn i biblioteket JQuery. Fra før brukte Aptoma biblioteket Prototype, men oppdragsgiver ønsket likevel at vi skulle bruke JQuery. Aptoma vurderer å gå over til å bruke JQuery, og Geir ville se hvordan biblioteket fungerte sammenlignet med Prototype i DrPublish. I tillegg hadde vi hørt positive ting om JQuery, blant annet at det gir en meget elegant kode. 25 S ide

26 6.3 LÆRINGSPERIODE 2- REFAKTORERING EN PROSESS AV KONTINUERLIG FORBEDRING «ANY FOOL CAN WRITE CODE THAT A COMPUTER CAN UNDERSTAND. GOOD PROGRAMMERS WRITE CODE THAT HUMANS CAN UNDERSTAND.» - Martin Fowler ("Refactoring - Improving the design of existing code") Denne læringsperioden foregikk parallelt med programmeringen av pluginen. Etter å ha laget en enkel plugin med den funksjonaliteten vi til da hadde planlagt, uten fokus på layout og brukervennlighet, hadde vi et møte med Stefan Grunert hos Aptoma. Stefans hovedrolle i Aptoma er å holde orden på oppbygging og innhold i koden. Her fikk vi mange gode innspill på hva som burde forbedres, og hva som allerede var bra. Vi fikk en innføring i hvor effektivt det er med unntakshåndtering i PHP, og hvordan vi best kaste slike unntak i våre metoder. Vi avtalte et nytt møte ikke lang tid senere, og jobbet med det vi hadde fått bemerkninger om på forrige møte frem til dette. For Aptoma var det viktig at vi var strenge med koden vi selv hadde laget, og heller slettet kode og skrev på nytt, enn å legge på for å få mer funksjonalitet. Denne kontinuerlige forbedringsprosessen gjorde at vi til slutt kom opp på en standard som var godkjent av Aptoma. Det var av stor betydning for både oss som gruppe og Aptoma, at koden vår var på et høyt nivå. For oss var dette viktig, fordi det gjorde det enklere å jobbe med koden. Vi fikk strukturert koden slik at den ikke bare ble mer lettlest og oversiktlig, men også kortere. Siden ikke alle hadde jobbet med de samme delene, prøvde vi i denne perioden å strukturere hverandres deler, for på den måten å bli kjent med hele koden. For Aptoma var det viktig, fordi de ønsket å bruke vår plugin som en del av DrPublish, når det lanseres. Hvis de skal kunne videreutvikle pluginen må helst pluginen ha samme kodestandard og struktur, som resten av DrPublish. Vi har i løpet av prosjektet lært hvor viktig refaktorering kan være. Det har gitt oss forståelse for hvordan en kode kan vokse og utvikle seg, bli større og sterkere. Vi har sett viktigheten av å skrive kode utenforstående raskt kan sette seg inn i og forstå. På figur 6.4 er det godt synelig hvordan pluginen har endret seg over tid, og hvordan refaktorering av koden har påvirket den. 26 S ide

27 Figur Eksempel på refaktorering Punktene under forklarer de forskjellige punktene som man kan lese på Figur 6.4 ovenfor. #1: Her er det første eksemplet på pluginen vår. En enkel, sorthvit layout med i vanlig HTML og PHP. Filer kan lastes opp til en database, og txt filer kunne vises i tekstområdet. #2: Dette er den første prototypen med filopplasting og innlegg av nettlenker. Funksjonalitet var lik #1, men med noen endringer i fil- og nettlenkelistingen. Klikket man på filen, åpnet den seg hvis mulig i File Contents-boksen. #3: Her hadde vi begynt å tenke litt på brukergrensesnittet, og laget en del CSS-kode. Funksjonalitet som fikk nettlenker og filnavn til å listes opp i områder som vi skjulte eller viste ved hjelp av JavaScript, var blitt lagt til. 27 S ide

28 #4: Vi gikk så bort fra å vise innhold i filer, funksjonaliteten på nettlenker fungerer som tidligere. Nytt var det at brukeren kunne skrive inn notat-tittel og et notatinnhold, og lagre dette. #5: Her er vi nesten i mål med funksjonalitet, det er mulig å legge til nettlenker, notater samt å laste opp filer. Vi har endret fil-funksjonaliteten, i stede for å åpne dem kan de lastes ned til bruker hvis de er i format nettleseren ikke støtter. De forskjellige referansene ble listet opp under sine respektive knapper. Slett-funksjonen er implementert. #6: Dette er den endelige versjonen. Alle funksjonsknappene ligger på en linje. Alt listes opp i en ramme, som kan sorteres stigende og synkende på både dato og type. Det er også mulighet for å angre slettinger. Designet er nedtonet for at brukeren skal holde fokuset på artikkelen og ikke pluginen. 6.4 PROGRAMMERING AV PLUGIN Vi satte først opp en database for lagring av alle data som skulle lastes opp. På dette tidspunktet hadde vi ikke helt klart for oss hva som skulle lastes opp. Vi hadde ennå bare planer om å laste opp filer fra brukers maskin, og derfor hadde vi kun en enkelt tabell. Etter hvert som vi så nytten av lagring av flere typer referanser, ble databasen langt mer kompleks. Vi satt oss derfor ned og tegnet opp nøyaktige entitetsmodeller, og normaliserte tabellene. I begynnelsen slet vi en del med å dele opp programmeringsoppgavene slik at alle kunne jobbe på samme tid. Det var et relativt snevert område å programmere på, og selv ved bruk av Subversion fikk vi ofte konflikter ved opplasting av det vi hadde gjort til server. Av den grunn startet vi med parprogrammering. Slik ble alle godt kjent med strukturen i koden, samt med flere deler av pluginen. Etter hvert som vi fikk stadig mer kode og funksjonalitet på pluginen, kunne vi igjen dele oss slik at alle jobbet hver for seg. Noen jobbet med layout og brukervennlighet, mens andre jobbet med de mer tekniske delene, som fil-opplasteren og drag and drop -funksjonen. Imidlertid gikk vi ganske tidlig vekk fra drag and drop. Egentlig ble vi enige med Geir om at vi skulle bruke Google sin nettleser-plugin Google Gears til denne opplastingen, men det støttet ikke det Linux-miljøet og versjonen av Firefox vi måtte benytte der. Vi fant også ut at Google skulle slutte å oppdatere Google Gears, så vi ble raskt enige med Aptoma om at dette var noe som var lite hensiktsmessig å benytte seg av. Idéen med drag and drop ble dermed lagt på is, men vi ser for oss at man kan videreutvikle pluginen senere med en slik funksjonalitet. 28 Side

29 Vi hadde tidlig som mål å raskt få opp en enkel plugin, for så å bygge på denne. Vi jobbet i små iterasjoner, hvor det for hver iterasjon ble gjort utbedringer på både funksjonalitet og utseende. Det negative med dette, var at vi skrev mye kode som senere ble forkastet. Vi følte likevel at denne måten å jobbe på ga et bedre resultat, særlig fordi vi ikke var utlært når vi startet å programmere. Mye av koden vi skrev i begynnelsen var ikke riktig ingeniørmessig, men gode møter og Skypesamtaler med Aptoma underveis, var viktige for at vi lærte oss å kode korrekt. Det vil si at koden skal være sikker, følger kodestandarden, lett å vedlikeholde og være testet. Vi måtte likevel ha mulighet for å kunne laste opp filer til serveren, selv om vi valgte å gå bort fra drag and drop -funksjonaliteten. Vanlig fil-browser -funksjonalitet var derfor noe vi ønsket å prøve ut, men uten å måtte oppdatere pluginen for hver fil man lastet opp. For å få til dette, måtte vi bruke AJAX-teknologien. JQuery hadde ingen ferdig funksjonalitet for slik filopplasting, så dermed måtte vi prøve å finne en annen løsning. Vi ønsket fortsatt å få til opplasting av filer med JQuery, men skjønte at en eller annen form for JQuery-plugin var noe vi trengte. En mulighet var å sette oss ned, og lage en helt ny plugin til JQuery selv. Dette følte vi ble unødvendig. Det finnes allerede mange sikre og gode filopplastere på nettet med åpen kildekode. Som vi fikk høre fra Aptoma under første læringsperiode, er det ikke vits å finne opp kruttet på nytt. Etter å ha søkt på nettet fant vi et JQuery-plugin med navn AJAX uploader som var laget av Valums. For å sette opp opplasteren, brukte vi et eksempel som fulgte med pluginen. Vi benyttet også dette nettstedet for å konfigurere opplasteren. Vi var innom to JQuery-plugin, både AJAX uploader og uploadify ( ). Det var fordi vi hadde problemer med å få scriptene til å fungere slik vi ønsket, og trodde det var noen spesielle konfigurasjoner vi manglet som ikke var godt nok dokumentert. AJAX uploader hadde en større og mer forståelig dokumentasjon tilgjengelig på nett, så vi brukte derfor en del ekstra tid på denne. Den fungerte likevel ikke slik den var påstått å gjøre, dermed begynte vi å feilsøke. Vi forsøkte å kjøre opplasteren utenfor DrPublish, og da fungerte den som den skulle. Etter å ha konferert med Aptoma, fikk vi vite at filadressen som sendes med pluginen var feil. Denne måtte skrives på en spesiell måte når pluginen kjører gjennom DrPublish. Endelig klarte opplasteren å laste opp en fil, men straks oppstod det et nytt problem. Vi hadde planer om å vise alle filene vi lastet opp i et tekstområde, slik at brukeren kunne redigere og lese rett i pluginen. Her oppstod blant annet problemer med å sende informasjon tilbake fra 29 S ide

30 opplasteren, slik at vi kunne vise innholdet av filen og/eller annen informasjon som en vellykket opplasting medfører. Når vi lastet opp filer med spesialtegn, krasjet opplastingen. Innholdet av filen ble ikke vist i tekstområdet. Det som gjorde at visningen feilet, var at opplasteren la til ekstra tegn på filene. For å komme videre måtte man manuelt oppdatere pluginen. Det viste seg også at idéen med å vise filen i selve pluginområdet var mindre heldig, da dette området er veldig lite, samtidig som all formatering av innholdet i filen ville forsvinne. Dette hadde gjort dokumentet uoversiktlig og annerledes å lese enn opprinnelig tiltenkt. Dermed fant vi ut at en bedre løsning ville være å la brukeren laste ned selve filene. Et annet problem når det gjaldt denne opplasteren, var selve knappen som skulle starte opplastingen. Problemet gjaldt kun når vi kjørte pluginen gjennom DrPublish. Området knappen reagerte på ble forskjøvet oppover eller nedover som vist på figur 6.3. Reaksjonsområdet til knappen ble redusert til en tynn strek på bare et par pikslers høyde. Dette området forandret og flyttet på seg fra pc til pc alt ettersom hva slags oppløsning skjermen hadde. Figur Add files raritet Ettersom opplasteren hadde dette layout-problemet, foruten at den bare kunne laste opp en fil av ganger og i tillegg hadde problemer med å motta enkelte json-array, fant vi ut at det ville være lurt å teste andre opplastere. Vi visste at Aptoma hadde en bilde-plugin, som benyttet seg av Shockwave Flash Uploader ( Denne opplasteren hadde mer funksjonalitet, blant annet mulighet for opplasting av flere filer samtidig, kontrollering av filstørrelse for opplasting og muligheter for en opplastings-kø. Vi leste også at SWFUpload brukes både hos Youtube og WordPress, og begynte dermed å sette opp SWFUpload. Ettersom programmet er lagdelt, trengte vi bare å endre noen små ting i kontrolleren, mens prosessoren forble uberørt av endringene. Alt av konfigurasjon og oppsett er utført med JavaScript. Det fulgte en del demonstrasjonssider med i SWFUploader-pakken, som hjalp oss med å finne den funksjonalitet vi ønsket å benytte oss av. En del tid brukte vi på å lære oss hvordan vi skulle konfigurere opplasteren til å fungere slik vi ønsket. 30 S ide

31 Vi fikk problemer med å få de medfølgende demonstrasjonene i pluginen vår til å virke. Hovedproblemet, var at det var dårlig dokumentert hvordan vi skulle hente ut og bearbeide dataen, etter opplastingen av filene Etter å ha saumfart diverse forum på internett, fant vi et innlegg der noen andre hadde samme problemet som oss og løsningen på dette. Problemet var hvordan man hentet ut dataen om filen fra SWFUploaderen løsningen var å hente arrayet $_FILES[ Filedata ], og dermed fikk vi løst dette. Når denne brikken falt på plass begynte ting virkelig å ta form. Vi klarte å få formet dette hjelpemidlet slik at det passet inn sammen med resten av pluginen vår. Med hjelp fra demonstrasjonsfilene og Aptoma, skrev vi våre egne funksjoner til opplasteren. Disse funksjonene bearbeider alle hendelser i løpet av opplasting. Vi lagde blant annet funksjoner som reagerer når en fil er ferdig bearbeidet, når en hel fil-kø er ferdig lastet, eller dersom det skjer feil under opplastinger og lignende. Det fantes allerede ferdige klasser med slike hendelseshåndterere ute på internett. Vi ønsket å være sikre på hva de gjorde, og kunne gå god for den tekniske kvaliteten på koden. Derfor valgte vi å skrive dem fra bunnen av. En annen utfordring vi fikk under implementeringen av filopplastingen, var håndtering av størrelsen på filene som skulle lastes opp. Vi hadde tidligere oppdaget at filer over en viss størrelse ikke var mulig å laste opp. Det første vi tenkte var at problemet lå i filopplasteren igjen, eller så var det noe i DrPublish som hindret oss. Aptoma avkreftet at problemet lå i DrPublish, og penset oss inn på rett spor. De trodde det var webserverens konfigurasjon vi måtte endre på siden det der var satt en standardgrense for maks størrelse på filer. Etter at vi endret på dette fungerte alt som ønsket. Dermed hadde vi fått en fullt funksjonell og godt testet filopplaster, som vi hadde full kontroll på hva gjorde. Til å begynne med lastet vi opp filer til en katalog på webserveren, og la inn filnavnet og en ID i databasen. Når en annen fil ble lastet opp, sjekket vi om filnavnet eksisterte i fra før. Dette gikk vi bort i fra, da det skapte problemer hvis man forsøkte å laste opp filer med samme navn på en annen artikkel. Vi har derfor valgt en løsning der vi oppretter en mappe, for hver unike artikkel, hvor vi laster opp filene. I databasen lagres artikkel ID, filnavn og litt annet. På denne måten kan vi forminske faren for feil ved opplasting. Hvis brukeren forsøker å laste opp en fil til en artikkel der filnavnet er det samme, så får brukere en feilmelding. Er filen merket som slettet, så slettes den fysiske filen og dens tilhørende rader i tabellene, før den nye filen lastes opp. 31 S ide

32 En stund ut i prosjektet fant vi ut at en økning av funksjonaliteten kunne være bra. Vi forsøkte å sette oss inn i en journalists hverdag, og hva som kunne være hensiktsmessig å ta vare på av referanser. Fra bare det å kunne laste opp filer til server, tenkte vi at det å kunne lagre lenker som referanser til artikler, også var nyttig. Ofte er det lenker til andre nettsteder i artikler, og sannsynligheten for at journalister bruker kilder fra nettet så vi som høy. Vi gjorde klart et førsteutkast med denne muligheten, slik at vi kunne vise det til Geir på neste møte. Geir syntes dette var en god idé, så vi ble enige med han om å utvikle denne idéen videre. På bildet under (figur 6.4) vises hvordan pluginen så ut da vi la til muligheten for å laste opp lenker første gang. Figur 6.5 Førsteutkast av lenkeideen. Delen er markert med Vi vurderte å åpne lenkene i selve pluginområdet, men fant ut at dette ikke ville være hensiktsmessig da området er veldig lite. Derfor valgte vi å la lenkene åpne seg i en ny fane i nettleseren i stedet. Da funksjonaliteten til lenkene var ferdig, gikk endringene på dette området heretter på layout. Under et av møtene med Geir fikk vi et ønske om vi kunne utvide funksjonaliteten til pluginen, slik at vi kunne opprette egne notater til artikler, og lagre dem til artikkelen. Dermed startet vi ekspanderingen av pluginen ved å implementere funksjonaliteten notater. Under utviklingen av notat-funksjonaliteten, var den største utfordringen å få det hele så brukervennlig som mulig. Vi lagde opprinnelig to felt i notat-delen av pluginen, en for innholdet og en for tittelen til notatet. Etter en ny samtale med Geir fikk vi beskjed om at han syntes tittelfeltet var unødvendig, og at vi heller skulle bruke første linje i innholdsfeltet som tittel. Innholdsfeltet hadde en fast størrelse, noe Geir ikke likte. Han ønsket at feltet skulle ta så liten plass som mulig før man begynte å skrive i det. Dessuten ville et for lite tekstfelt være upraktisk for brukere som ønsker å legge til lange notater. Vi endret derfor på notatdelen igjen, og laget ett ekspanderende tekstområde. På nettet fant vi en guide for hvordan man kunne lage en JQuery- 32 S ide

33 plugin, som utvidet tekstområdet etter hvert som man skrev. Dette mente vi var en veldig tilfredsstillende løsning og vi bestemte oss for den. Utseende før endringen er vist ved figur 6.6, og et etter bilde er vist ved figur 6.7. Figur Slik så utseende ut før vi la til automatisk ekspanderende tekstområdet Figur Slik så det ut etter at vi hadde lagt til det ekspanderende tekstområdet. Tekstområdet starter her på en linje og utvider seg. Vi hadde ikke lagt til funksjonalitet som gjorde det mulig å redigere på de lagrede notatene i etterkant, noe Geir syntes var upraktisk. Vi så nytteverdien i hva Geir mente, fordi man da slipper å slette notater og legge til alt på nytt, bare for å endre et lite ord. Pluginen ville i så fall bli mer brukervennlig, og vi valgte derfor å implementere denne muligheten. Vi valgte å gjøre det så enkelt som mulig for brukeren. Nå kan man bare trykke på innholdet av det ønskede notatet for å endre, og så trykke igjen utenfor notatet for å lagre endringene. En journalist sparer mange klikk i løpet av et år, ved å slippe og trykke på en lagre knapp hver gang det skal gjøres en endring. 33 S ide

34 Den endelige funksjonaliteten til pluginen var ikke ferdig planlagt fra starten av. Derfor ble ny funksjonalitet som lagring av notater og lenker, lagt i egne lister når de ble hentet ut fra databasen. Til slutt satt vi igjen med tre ulike lister, en for hver av de tre referansetypene. Etter et iterasjonsmøte med Geir, fant vi ut at det ville være hensiktsmessig å kunne sortere alle referansene etter når de er blitt lagt til i databasen. Han ville gjerne ha mulighet for at den siste som legges til, blir lagt øverst i pluginen sin liste. Vi hadde tre forskjellige lister, og måtte derfor finne på en måte for å få sortert det slik. Av den grunn valgte vi å slå alle listene sammen til én liste. I denne listen er det et felt som forteller hvilken type hvert element er av. Sorteringen av listen valgte vi å gjøre i JavaScript, da det gir en raskere brukeropplevelse enn om vi kun hadde brukt PHP. Det å slå sammen de tre eksisterende listene til én, medførte endringer i store deler av pluginen. Mye kode måtte skrives om, og databasen måtte endres, slik at det passet inn med den nye listen. Pluginen skal være rask og brukervennlig, og sletting av referanser mente vi derfor at skulle kunne gjøres, uten advarsler og bekreftelser. Vi fant ut at en stresset bruker raskt kan komme til å slette feil referanser. Derfor kom det opp et forslag om å ha med en angreknapp, slik at brukerfeil av denne typen kunne gjøres mindre alvorlige. Fra før av fysisk slettet vi referansen fra databasen. Dette fungerte ikke hvis vi skulle kunne angre, og ville gi en utrygghet for brukere, som ikke kan gjenopprette sine filer. Vi endret derfor database-tabellene, slik at de fikk et ekstra felt. Feltet bestemmer om en fil er satt som slettet eller ikke. Er den satt som slettet i databasen, vil den ikke vises i brukergrensesnittet. Endringene av databasen gjorde at mange metoder i modellaget måtte endres. Her hjalp enhetstestene oss, slik at alle metodene fungerte etter endringene. At vi endret databasen, ga oss mulighet for å kunne starte utviklingen av angreknappen. Vi ønsket at angrefunksjonaliteten skulle gå lynraskt. Derfor er det slik nå at når noe blir slettet, flyttes referansen inn i et eget array, og hentes tilbake om det blir angret. 6.5 UTFORDRINGER Installasjon av Linux Som gruppe hadde vi lite erfaring med Linux. Da vi skulle installere dette på våre maskiner, førte det med seg en del problemer. De viste seg å ligge i det Windows-basert Linux-installasjonsprogrammet, ved navn Wubi. Dette installerer Linux som et eget program i Windows, hvor man kan avinstallere det som et vanlig program i «legg til/fjern programmer». Vi opplevde nesten daglige systemkrasj ved 34 Side

35 bruk av denne. Det var et stort problem siden vi brukte mye tid på å sette opp Aptomas rammeverk og DrPublish, og hver gang det krasjet måtte vi gjøre alt på nytt. Til slutt fant vi ut at det var Wubi som var årsaken til problemet, og vi gikk vi over til en vanlig installasjon av Linux. Etter det har ingen hatt problemer med at operativsystemene har krasjet Å finne et godt utviklingsprogram i Linux Vi snakket med forskjellige ansatte i Aptoma, for å høre hvilke utviklingsverktøy som var gode for PHP og JavaScript i Linux. De ansatte i Aptoma brukte stort sett forskjellige programmer alle sammen. Vi begynte å sette oss inn i, og jobbe på, forskjellige enkle programmer og teksteditorer. Flere hadde mulighet for fargekode, klasse/metode hierarki eller hurtigtaster, men sjelden alt på en gang. Vi ble aldri helt tilfreds med noen av dem, men gjorde så godt vi kunne med de enkle editorene vi fant. Løsningen på problemet var at vi til slutt fant Eclipse for PHP. Dette fungerte i Linux også, og viste seg å være et meget godt program. Det hadde alt av muligheter vi hadde sett etter i de tidligere programmene Oppsett av AFW og DrPublish Det tok lenger tid enn forventet å sette opp AFW og DrPublish slik Aptoma krever. Dokumentasjonen, særlig i DrPublish, var på dette tidspunktet relativt uferdig. Mange krav måtte oppfylles for å få utviklingsmiljøene våre opp på Aptomas standard. Vi løste dette ved å ha god kontakt med ansatte i Aptoma, særlig via internett. Vi var også innom kontoret deres og fikk hjelp der. Ved å sette opp rammeverket selv, lærte vi mye om hvordan alt var bygd opp. Senere i prosjektet oppdaget vi at akkurat dette hadde hjulpet oss mye Optimalisering av brukergrensesnitt Vi skulle lage et brukergrensesnitt med et så enkelt utseende som mulig, men likevel ha en rask og god brukeropplevelse. For å få til dette måtte vi gå gjennom utallige refaktoreringer av koden. Vi hadde et stort antall møter med Aptoma, hvor vi fikk innspill fra dem om hva vi kunne forbedre med tanke på utseende. De ga oss også tilbakemelding på hva vi hadde gjort bra, og ikke trengte å gjøre om på. På denne måten kom vi i mål med en brukervennlighet og et utseende, som både vi og Aptoma er fornøyd med Kontakt med Aptoma 35 S ide

36 Selv om vi aldri slet med å få hjelp hos Aptoma, så hadde vi litt problemer med å få møter med Geir. Som daglig leder i Aptoma var han ofte ute og reiste, noe som gjorde at vi ikke alltid fikk møte han når vi trengte det. Istedenfor møtte vi andre ansatte i Aptoma, som måtte sette seg inn i vår applikasjon og få vite alle ideer og liknende vi hadde på nytt. Dette var ikke alltid optimalt, men på den annen side fikk vi også innspill fra flere personer, noe som vi tror har virket positivt inn på sluttproduktet. 6.6 KOMMUNIKASJON Innad i gruppen Innad i gruppen har vi hatt jevnlig kontakt, da vi alle har jobbet sammen på skolen hver dag. Ettersom vi har vært en godt sammensveiset gjeng allerede fra første året på Høgskolen, har kontakten mellom oss vært veldig god. Innkalling til gruppemøter har vi som regel avtalt mens vi har vært på skolen og jobbet, eller via kommunikasjonsprogrammene MSN Messenger og Skype på kveldstid. Vi trives godt sammen både faglig og på fritiden, så kommunikasjonsproblemer oss imellom har vi hatt lite av Med oppdragsgiver Vi forsøkte å holde jevnlig kontakt med Aptoma. Det var et ønske fra dem at vi skulle ha møte minst en gang annenhver uke, og at vi skulle sitte der å jobbe en gang i uken. Dette gjorde at vi ofte kunne snakke med ansatte i Aptoma, og få hjelp/tilbakemeldinger. I tillegg til dette brukte vi Skype, hvor vi både skrev og snakket med hverandre over nettet. På denne måten hadde vi sjelden problemer med å få kontakt med Aptoma. 36 S ide

37 7 ERFARINGER MED VALGT METODIKK Her diskuterer vi de erfaringene vi har hatt med de ulike utviklingsmetodene vi har benyttet oss av i prosjektet. 7.1 ERFARINGER MED AGILE METODER Erfaringer med XP For oss var XP en naturlig måte å arbeide på. Av den grunn, slapp vi å hele tiden ha fokus på å følge metodikken og vi innarbeidet oss raskere de rutiner som var nødvendig. En av grunnene til at det falt oss så naturlig, var at Aptoma la opp prosjektoppgaven for oss slik at vi skulle utvikle etter deres metodikk. XP ga oss stor frihet i hvordan vi ønsket å arbeide, noe vi tror bidro til å øke kvaliteten på pluginen. Hadde vi måttet sette opp alle krav fra starten og jobbet etter disse, er vi sikre på at innholdet hadde vært noe ganske annet en hva som er mest nyttig for en journalist. Nå har vi kunnet komme med forslag underveis til endringer av pluginen, etter hvert som vi har lært oss mer og oppdaget nye muligheter, andre funksjonaliteter og bedre løsninger. Eksempler på dette er lagring av notater og lenker, som ikke ville blitt noe av hvis vi hadde skrevet endelige krav fra starten av prosjektet. XP passet oss godt, siden vi tilbringer så mye tid sammen både på skolen og på fritiden. Et så stort antall møter som XP krever, kunne vært en ulempe for oss om vi ikke hadde vært så mye sammen. Vi var sammen hver morgen uansett, så de daglige morgenmøtene falt helt naturlig for oss. Geir hadde veldig mye å gjøre i bedriften utenom møtene med oss, og vi fikk hatt færre møter med han enn det vi kunne tenkt oss. Dette medførte at vi i perioder ikke kunne ha de ukentlige iterasjonsmøtene med kunden/geir, og vi måtte ta flere viktige avgjørelser om pluginen selv. Vi tok blant annet selv avgjørelsen om å ha mulighet for å lagre lenker i referanselisten. Dette kunne kostet oss masse tid om Geir ikke ville ha hatt det med likevel. I tillegg kom en fanebasert plugin vi prøvde oss på. Den måtte fjernes etter et møte hvor det kom frem at noe slikt ikke var ønsket. Det var allerede mange faner og valgmuligheter i DrPublish, noe som ville føre til et mer uoversiktlig produkt. En positiv erfaring med XP var refaktoreringene. Koden ble mer oversiktlig, og det ble lettere for Aptoma å sette seg inn i koden vår. Dessuten er det lettere å vedlikeholde og videreutvikle programmet. Det lærte oss hvordan god og solid kode skal skrives, og bidro til å øke den generelle 37 S ide

38 kunnskapen vi hadde om programutvikling. Den oversiktlige koden vi etter hvert fikk, ga oss en lettere jobb med feilsøking og feilretting av produktet. Hadde vi ikke refaktorert, men kun lest hvordan vi skulle ha gjort det fra begynnelsen, hadde vi sannsynligvis ikke hatt den samme læringskurven, med det resultat at vi kunne blitt fire dårlige programutviklere Erfaringer med Lean Vi lagde guider for oppsett av DrPublish og AFW. Dette hjalp oss mye, da vi brukte disse hver gang systemene våre krasjet i begynnelse av prosjektet. Dette sparte oss for mye tid, og vi fikk etter hvert inn en rutine på området. Denne standardiseringen har også gjort prosessen mer pålitelig. Vi refaktorerte koden jevnlig, for å holde den på et høyt nivå. På denne måten reduserte vi kodegjelden, som Aptoma ville sittet igjen med da prosjektet ble ferdig. Med kodegjeld mener kode som ikke er god/oppdatert og derfor trenger og refaktoreres. Dette er kode som en programutviklingsbedrift før eller siden må skrive om, noe som igjen fører til utgifter. 7.2 ERFARINGER MED ENHETSTESTING Enhetstesting er noe som Høgskolen i Oslo ikke har hatt fokus på, og det har heller ikke vært en del av vår læreplan i noen av årene vi har gått på skolen. Ingen av medlemmene på gruppen hadde vært borte i enhetstesting før i forrige semester, hvor vi kom innom det i valgfaget i Webapplikasjoner som fokuserer på.net-utvikling. Enhetstesting i PHP hadde vi derimot aldri jobbet med. Vi lærte fort at forskjellene mellom.net-enhetstesting og PHP var små, og kom oss lett inn i denne metodikken. Aptoma hadde ikke krav om at vi skulle teste alt, bare de metodene som ikke var selvforklarende. Resultatet av dette ble noen få, men viktige tester. Det er vanskelig å se nytten av enhetstesting i et så lite prosjekt. Vi ser på en annen side nytteverdien av enhetstestene i DrPublish. Systemet blir mye mer avansert og komplekst, så enhetstestene hjelper til med å holde oversikt over at det man gjør er riktig. For oss har det likevel vært positivt med enhetstesting med tanke på all refaktoreringen vi måtte gjennomføre på koden vår. Vi kunne med hjelp av disse, raskt se om forandringene vi gjorde endret på funksjoners virkemåte, eller ikke. Hadde vi valgt å utvikle testdrevet fra begynnelsen av, hadde vi kanskje unngått å gå i noen av de fellene vi gjorde. Dette ville muligens ha spart oss noe tid på feilsøking. Vi har aldri utviklet testdrevet 38 S ide

39 før, og vi visste dette var noe som det tok tid å venne seg til. Dermed ville vi kanskje ikke spart så mye tid likevel. Testdrevet utvikling er heller ikke noe Aptoma benytter seg av. De har derimot en mentalitet tuftet på erfaring, som gjør at de tenker mye mer på at koden skal kunne være mulig å teste. Dette var noe vi hadde god mulighet til å lære av. Det var først et stykke ut i prosjektet at Aptoma informerte oss om hvordan vi skulle teste koden slik de gjorde det, og viste hvordan AFW skulle brukes til å teste pluginen. For å få koden testbar, måtte skrive om deler av koden slik at den var mulig å teste. Dette er noe vi lærte mye av. Våre erfaringer med enhetstesting må kunne konkluderes som generelt positive. 39 S ide

40 8 KRAVSPESIFIKASJON OG DENS ROLLE Kapittelet gir et innblikk i måten vi har jobbet med kravspesifikasjonen, hva vi har endret underveis og årsaken til at vi har brukt en alternativ kravspesifikasjon. 8.1 VÅR BRUK AV KRAVSPESIFIKASJON Prosjektet har fulgt en smidig utviklingsmetodikk. Av den grunn har vi ikke jobbet etter en ferdig kravspesifikasjon. En kravspesifikasjon bør definere tydelig, og gjerne kvantifisert, hva man skal oppnå og hvorfor. Ikke hvordan. Å finne ut hvordan er noe man gjør inkrementelt i løpet av prosjektet. Vi satt derfor opp en kravspesifikasjon ut i fra hvilke mål vi ønsket å oppnå, i tillegg til de tekniske rammer vi hadde fått fra Aptoma. Kravspesifikasjonen er vedlagt. 8.2 AVVIK FRA KRAVSPESIFIKASJON I starten hadde vi kun planer om å laste opp filer i pluginen. Det viste seg etter hvert at det også ville være praktisk å kunne lagre notater og lenker til artikler. I kravspesifikasjonen skrev vi at alle navn i HTML-koden skulle starte med tre bokstaver som forklarte hva slags HTML-tag det var. Dette gikk vi noe bort fra, fordi Aptoma mente vi kun trengte disse bokstavene på HTML-tagger som ikke var selvforklarende. 8.3 KRITIKK Kravspesifikasjoner forsøker for ofte å fange opp hvordan man skal løse utfordringene i prosjektet. Det er mildt sagt uhåndterlig å forsøke å definere detaljene i hvordan prosjektet skal gjennomføres, i starten av prosjektet. Spesielt gjelder dette hvor løsningen er ukjent og kanskje kravene og behovene endrer seg underveis. Ved heller å fokusere på hvorfor hvilke behov skal oppfylles og hvilke målsetninger har brukerne blir kravspesifikasjonen mer håndterbar, og flere kan sette seg inn i den og forstå den. Man avventer med detaljene (hvordan) så lenge som det er mulig, og ansvarlig. Fordelen med dette er at man ved definisjon av hvordan, sitter med mest mulig innsikt i problemdomenet og brukernes behov. 40 S ide

41 Ettersom spesifikasjonen gjøres like før, eller ved implementasjonstid, kan man så ta med seg erfaringene videre til neste del av systemet som skal utvikles. Man får altså inkorporert læring inn i prosjektets flyt. En metafor som kan brukes på dette er fjellklatring. Man kan si hvor man vil og hvorfor, men problemene oppstår om man forsøker å definere detaljene i ruten allerede på avstand fra fjellet. Følges denne veien blindt, kan man falle ned i et uforutsett stup, eller på andre måter å bli offer for lokal informasjon som oppdages underveis. Dersom man i stedet setter seg som mål å bestige toppen, og har idéer om hvor ruten bør gå, men utarbeider stegene og detaljene i ruten underveis, vil man oppdage hindringer og kunne finne alternative veier. Vi har jobbet på denne måten. Målet var å gi journalisten verktøystøtte for kildehåndtering underveis i skriveprosessen. Akkurat hvordan vi skulle løse dette var vanskelig å vite. Det er også vanskelig for en journalist å definere hva som kan løse denne utfordringen. Det er altså ikke bare å spørre Hva vil du ha?. Hadde vi jobbet med en fast bestemt kravspesifikasjon fra starten av prosjektet, tror vi at vi ville oppnådd kravene, men altså ikke ønskene til kunden. Henry Ford sa en gang: Hvis jeg hadde spurt hva folk ville ha, ville de bedt om en raskere hest!. Han var den første som masseproduserte biler. Hadde vi satt oss ned med en journalist første dagen, og skrevet kravspesifikasjonen, tror vi ikke vi hadde kommet frem til en god løsning. Dagens løsning har fremkommet evolusjonært og har inkludert i seg de erfaringer vi har fått underveis. 41 S ide

42 9 RESULTAT Hovedresultatet av prosjektet er ikke bare selve pluginen. Å arbeide med programvareprodukter byr på utfordringer langt utover det å produsere funksjonalitet. Kvaliteter som endringsvillighet, ytelse, effektivitet, grensesnitt og vedlikeholdbar kode har vært nødvendig nøkkelkompetanse for gjennomføring av prosjektet. En annen oppgave har vært å teste ut hvordan det fungerer å lage plugins i DrPublish, for noen som ikke er kjent med rammeverket og DrPublish. Koden til pluginen er vedlagt på CD. 9.1 HVORDAN JOBBE MED ET UFERDIG PRODUKT. Det har vært mange utfordringer knyttet til DrPublish. Blant annet var API-en vi skulle bruke uferdig, slik at metoder som skulle fungere ikke alltid gjorde det. Dette har vært veldig utfordrende til tider, og vi har brukt mye tid på saker som har vist seg å ligge utenfor vår kontroll. Et problem var blant annet måtte vi laste inn pluginen på nytt flere ganger, hver gang vi skulle åpne den. Dette fordi DrPublish ga oss feilmeldinger som lå utenfor vårt ansvarsområde. Det har likevel vært en spennende prosess, og det har føltes bra å få være med å jobbe med et slikt produkt. 9.2 HVORDAN ER DET Å LAGE EN PLUGIN I DRPUBLISH? Vi har erfart at det var vanskeligere å lage pluginen enn hva Aptoma først trodde. Noe av dokumentasjonen deres stemte ikke, og på enkelte områder fantes den ikke i det hele tatt. Dette var derimot problemer knyttet til bruken av selve rammeverket deres, da vi fikk ordnet opp i dette ble selve programmeringen som å lage en vanlig nettside. Noen småproblemer med den nevnte API-en, ellers er DrPublish og plugins en god kombinasjon. Vi mener at dokumentasjonen angående hvordan vi skulle få pluginen til å kjøre i DrPublish var mangelfull, og uten direkte brukerstøtte fra Aptoma sine ansatte, hadde vi brukt mye tid på å få det til å fungere. Alt vi fikk vite på forhånd er beskrevet her: 1. Create a web-app (your plugin) at a location of your choice. Put its URL into the config/settings.php => PLUGINS 42 S ide

43 2. Have the plugin do some magic stuff that produce some HTML-content. Figur 9.1 er et utdrag fra filen settings.php: Figur settings.php Har man ikke PHP-kunnskaper fra før av, er det troligvis vanskelig å få dette til korrekt uten hjelp. Måten man legger til URL-en på er annerledes på de plugins man lager selv, enn de som følger med DrPublish fra før av (linje 22 tilhører vår plugin). Flere tips for hvordan man utvikler plugins som kjører sammen med DrPublish, er noe vi vil anbefale Aptoma å lage for andre utviklere. Vi måtte ofte lete igjennom de plugins de hadde laget fra før, for å få tips i koden de laget hadde. Selv om API-en til DrPublish har en noe ufullstendig dokumentasjon og at vi ser den er uferdig, mener vi at de funksjonene som er der er gode. De gir en lett tilgjengelig og fin funksjonalitet. Det har vært utfordrende ha et så lite arbeidssted som vi faktisk hadde, da området pluginen jobbet i var bare en liten del av skjermen. Dette har også virket positivt på oss da vi har blitt tvunget til å jobbe effektivt og minimalistisk, og optimalisere kode og utseende jevnlig. 43 S ide