HOVEDPROSJEKT. Studieprogram: ingeniørfag - data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1

2

3 PROSJEKT NR Studieprogram: ingeniørfag - data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET ÅPEN Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL: References PROSJEKTDELTAKERE Øyvind Shahin Berntsen Kheradmandi (S141430) Henning Sjørbotten (S147800) Fredrick Strøm (S147780) Erik Leirstrand Øvrum (S140782) DATO : 31. mai 2010 ANTALL SIDER : 160 INTERN VEILEDER Ulf Uttersrud OPPDRAGSGIVER Aptoma AS ( KONTAKTPERSON Geir Berset , geir@aptoma.com SAMMENDRAG Oppgaven har gått ut på å lage en plugin til Aptoma sitt artikkelredigeringssystem DrPublish, som fortsatt er under utvikling. Pluginen skal håndtere og ta vare på artikkelens kildemateriale, og på den måten forenkle hverdagen til journalister. Dette ble bestemt etter av VG sine journalister og Aptoma sin veileder. En annen side av oppgaven, har vært å teste og finne fallgruver i Aptoma sin dokumentasjon og rutiner, når det gjaldt installasjon, oppsett og utvikling av plugin til DrPublish. References er utviklet ved hjelp av PHP, JQuery JavaScript, HTML, CSS, SQL og med Apache som webserver på Aptoma sitt egne rammeverk og med deres kodestandard. References er et solid stykke arbeid hvor vi har lagt ned mye tid for å lage et minimalistisk grensesnitt, og en lettfattelig, sikker og høykvalitets kildekode. Dette er et resultat vi er meget fornøyde med, og som har gitt oss innblikk i og erfaring som programutviklere i arbeidslivet. 3 STIKKORD Webapplikasjon Plugin JavaScript

4

5 FORORD Dette heftet er en samling rapporter skrevet i forbindelse med hovedprosjekt i Bachelorstudium ingeniørfag data ved Høgskolen i Oslo, våren Prosjektoppgaven er laget for Aptoma AS. Oppgaven valgte vi fordi ønsket om å jobbe mot et reelt produkt, og ha muligheten til å utvikle noe som kunne havne i produksjon, var stort. Heftet er delt inn i flere deler. En prosessrapport, produktrapport, testrapport, brukermanual, ordliste og en rekke vedlegg. Hver del kan leses hver for seg, og har sin egen innholdsliste. Vi anbefaler likevel å lese prosessrapporten først. All kildekode, samt en elektronisk utgave av rapporten, finnes vedlagt på CD. Prosessrapport her forteller vi om hvordan vi har jobbet, hvilke valg vi har tatt og hvorfor. Produktrapport her er en teknisk gjennomgang av produktet. Den viser produktets oppbygning og virkemåte. Testrapport denne inneholder brukertester og informasjon om våre enhetstester. Brukermanual dette er en bruksanvisning som forklarer hvordan applikasjonen kan brukes. Ordliste her en oppramsing av tekniske ord og uttrykk som benyttes i rapporten. Vedlegg her finnes kravspesifikasjon, fremdriftsplan, møtereferater og annen prosjektrelatert dokumentasjon. Heftet er optimalisert for å leses på papir i A4-format. Vi ønsker å takke våre veiledere, Geir Berset fra Aptoma AS og Ulf Uttersrud fra Høgskolen i Oslo, for deres konstruktive tilbakemeldinger og veiledning. Dette heftet finnes gjengitt i sin helhet på prosjektets hjemmeside:

6

7 INNHOLD Prosessrapport... 5 Produktrapport Testdokumentasjon Brukermanual Vedlegg Ordliste

8

9 Prosessrapport PROSESSRAPPORT

10

11 Prosessrapport 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.

12 Prosessrapport INNHOLDSFORTEGNELSE Forord... 1 Innhold... 3 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 Eclipse S ide

13 Prosessrapport 4.2 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 Opplasting av filer Lagring av lenker Lagring av notater Sortering av referanser Angring Utfordringer Installasjon av Linux S ide

14 Prosessrapport Å finne et godt utviklingsprogram i Linux Oppsett av AFW og DrPublish 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

15 Prosessrapport 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. 11 S ide

16 Prosessrapport 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 12 S ide

17 Prosessrapport i lanseringsfasen, og vi trenger å få utviklet spennende og fremtidsrettede plug-ins til systemet som benytter og setter våre APIs 1 på prøve. Dine plug-ins vil potensielt bli brukt i store nettavisredaksjoner, 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. 1 Application Programming Interface, et programmeringsgrensesnitt som betegner et grensesnitt for kommunikasjon mellom programvare. 13 S ide

18 Prosessrapport 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 RAMMEBETINGELSER Vi skal bruke PHP og JavaScript som programmeringsspråk og vi skal jobbe på Aptomas eget rammeverk 2, AFW 3. 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. 2 Rammeverk er et spesialtilfelle av programvarebibliotek i at det er gjenbrukbare abstraksjoner av koden innpakket i et veldefinert API. 3 Aptoma Frame Work 14 S ide

19 Prosessrapport 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 15 S ide

20 Prosessrapport 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. 16 S ide

21 Prosessrapport 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. 17 S ide

22 Prosessrapport 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 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 4. 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. 4 AMP- Server, er en server som er satt opp med Apache, Mysql, Perl, Python og PHP. 18 S ide

23 Prosessrapport 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. 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. 19 S ide

24 Prosessrapport 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 5, 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 8. 5 To utviklere som sitter sammen og koder på samme maskin/tastatur. 20 S ide

25 Prosessrapport 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 6, 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. 6 En utviklingsmetode hvor man lager testene før selve metoden blir opprettet. 21 S ide

26 Prosessrapport 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 til filen som vises. 22 S ide

27 Prosessrapport 4.2 GEDIT Gedit er et UTF-8-kompatibelt 7 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. 7 Et unicode-tegnsett med variabel tegnlengde. Unicode er en nummerert samling av tegn, og UTF-8 representerer disse numerene med mellom en og fire byte. 23 S ide

28 Prosessrapport 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 8 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. 8 Cascading Style Sheets, et språk som brukes til å definere utseende på filer skrevet i HTML eller XML. 24 S ide

29 Prosessrapport 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 9 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. 9 Lean (egentlig: Lean manufacturing / norsk: Slank produksjon) betegner en produksjonsmetodikk for fremstilling av varer og tjenester. 25 S ide

30 Prosessrapport Figur 5-1 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. 26 S ide

31 Prosessrapport 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. 27 Side

32 Prosessrapport 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-1 Viser 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 10, PHPdebuggeren 11 xdebug og profileringsverktøyet KCachegrind. 10 Memcached er et system for minnedistribusjon. 11 Er en prosess for å finne og redusere antallet feil, eller defekter, i et dataprogram eller i elektronikk, for å få det til og oppføre seg som forventet. 28 S ide

33 Prosessrapport 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 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. 29 S ide

34 Prosessrapport 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 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. 30 S ide

35 Prosessrapport 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. 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, 31 S ide

36 Prosessrapport 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å. 32 S ide

37 Prosessrapport På figur 6-4 er det godt synlig hvordan pluginen har endret seg over tid, og hvordan refaktorering av koden har påvirket den. Figur Pluginens utvikling over tid Punktene under forklarer de forskjellige punktene på figuren. #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. 33 S ide

38 Prosessrapport #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. #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 12, 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 12 Modell som viser sammenhengen og avhengigheter mellom entitetstabellene. 34 S ide

39 Prosessrapport 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. 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 OPPLASTING AV FILER 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 å 35 S ide

40 Prosessrapport 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 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-5. 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 36 S ide

41 Prosessrapport 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. 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 37 Side