HOVEDPROSJEKT. Automating Aptopappa. Geir Skjevling PHP. Webapplikasjon

Transkript

1 PROSJEKT NR Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Automating Aptopappa DATO ANTALL SIDER / BILAG CD PROSJEKTDELTAKERE Erik Østensen (s135803) Henning Østensen (s135784) Ida Melle Johansen (s135690) OPPDRAGSGIVER Aptoma As INTERN VEILEDER Geir Skjevling KONTAKTPERSON Geir Berset SAMMENDRAG Oppgaven har gått ut på å videreutvikle Aptomas prosjektstyringverktøy, Aptopappa. Hensikten er å forbedre informasjonsflyten med kundene, og innad i bedriften. Aptopappa har blitt utvidet med blant annet følgende ny funksjonalitet: - Supportsystem support e-post direkte inn i Aptopappa. - Faktura over E-post i PDF-format - Hendelser i Aptopappa og i SVN over på IRC Applikasjonen er utviklet i PHP og bygger på Aptomas eget rammetverk AFW. Aptopappa utnytter teknologier som HTML, CSS, Javascript, Ajax og SQL. Som database er MySQL benyttet og Apache som Webserver. Vi har lagt ned mange timer i prosjektet og har føler at vi har nådd alle målene til oppdragsgiver. Resultatet er vi meget fornøyd med. 3 STIKKORD Prosjektstyringsverktøy PHP Webapplikasjon

2 Prosessrapport for Automating Aptopappa 2 av 96

3 1. Forord Med denne rapporten vil vi fortelle hva vi har gjort og hvordan vi har jobbet for å komme frem til det endelige produktet. Vi vil utdype og redegjøre for hvilke teknikker og metoder som er brukt for å komme frem til de ulike løsningene. Rapporten er beregnet for sensor, veileder og arbeidsgiver, samt andre som har interesse av å sette seg inn i vår arbeidsmetodikken. Vi forutsetter at leser av dette dokumentet er over gjennomsnittet datakyndig. Prosessdokumentasjonen er delt opp i slik: Innledning, produkt, fasene i prosjektet, samarbeid og konklusjon. Vi anbefales at dokumentene leses i denne rekkefølgen. Vi henviser til produktdokumentasjonen som gir en dypere teknisk beskrivelse av produktet og systemets oppbygning. Vi har lagt ved en ordbok hvor leseren kan slå opp eventuelle ukjente ord og uttrykk som er nevnt i denne rapporten. I teksten er disse markert i kursiv. Vedlagt ligger også styringsdokumenter og andre dokumenter som kan være nyttige for å forstå programmet og prosessen vi har vært igjennom. 3 av 96

4 2. Innholdsfortegnelse Automating Aptopappa Hovedprosjekt våren Forord innholdsfortegnelse 3. Innledning Gruppen Om bedriften Bakgrunn for oppgaven Mål Aptopappa før Aptopappa nå Rammebetingelser... 6 Programvare/teknologi... 6 Beskrivelse Utviklingsmiljø Nettlesere Planlegging Innledende arbeid Første tanker Fremdriftsplan og arbeidsplan Metode Kravspesifikasjon Utviklingsprosessen Kompetansetilegning Programvare / Teknologi Beskrivelse Programvare/teknologi Beskrivelse Design Bakgrunn for designet Utfordringer med design Ikoner Implementasjon Prototype, scriptacolous og JSON PDF-generering av faktura IRC-bot Supportsystemet Filopplasting med Ajax-liknende funksjonalitet Automatisk kodekontroll Testing Samarbeid Samarbeid med oppdragsgiver og sluttbruker Samarbeid i gruppen Veiledning fra Høgskolen i Oslo Oppsummering/Konklusjon Oppsummering Hva kunne vært gjort bedre Konklusjon Kilder av 96

5 3. Innledning Denne delen av dokumentet inneholder bakgrunnsinformasjon for prosjektet. Her presenterer vi hvem som har utført prosjektet, en beskrivelse av bedriften, og bakgrunn og mål for oppgaven Gruppen Gruppen vår består av Erik Østensen, Henning Østensen og Ida Melle Johansen. Vi har tidligere jobbet sammen som gruppe mer eller mindre på alle gruppeprosjektene på ingeniørstudiet, og mener vi har et godt og fungerende samarbeid. Det var naturlig for oss å fortsette samarbeidet, da sannsynligheten for at det dukker opp nye uenigheter og gnisninger i gruppen er liten i og med at vi har jobbet sammen flere ganger før. Vi var både åpne for, og forholdsvis enige og samstemte i forhold til hva slags type oppgave vi ønsket. Vi ønsket helst en oppgave innen programmering, og tok i den forbindelse på egenhånd kontakt med et par interessante bedrifter. Vi leste også igjennom forslagene til hovedprosjekt på skolens hjemmesider, og var enige om at Aptoma AS sitt forslag til hovedprosjekt virket interessant og lærerikt. 3.2 Om bedriften Aptoma AS utvikler web-applikasjoner. Deres hovedkunder er avisselskaper og mediebedrifter i Norge og utlandet. Aptoma AS leverer blant annet løsninger innen web-tv, visuell produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus. Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har utviklet flere dynamiske og multimediale webapplikasjoner. Blant annet et verktøy for oppsett av forsider, Dr. Front., som blir brukt på blant annet VG-netts og den franske nyhetssiden Bedriften samarbeider også andre mediebedrifter for eksempel Asker og Bærum Budstikke og Scanpix/NTB. Aptoma AS er en relativt liten bedrift med 7 utviklere og programmerere. De fleste holder til i Oslo, men de har også en ansatt som jobber og bor i Sverige. Det er viktig for bedriften å være så mobil som mulig, altså ikke være avhengig av å være på kontoret for å kunne jobbe. Det er stor fleksibilitet for de ansatte, om de vil jobbe hjemmefra, i bedriftens lokaler og til hvilket tidspunkt. Aptoma AS jobber etter en fleksibel utviklingsmetode sterkt inspirert av SCRUM. Dette gjør at de arbeider anderledes enn man er vant med fra tradisjonelle yrker, da SCRUM er rekursiv og fordrer korte faser, smartere planlegging og tettere samarbeid. Vi har også valgt å jobbe etter bedriftens metode. Dette vil bli beskrevet ytterligere senere i rapporten. 3.3 Bakgrunn for oppgaven Oppdragsgiver har i løpet av sommer og høst 2008 utviklet et eget prosjektstyringsverktøy; Aptopappa. Aptopappa er et web-basert grensesnitt for oppgavestyring. Systemet skal forenkle jobben med planlegging og styring av prosjekter. Programmet er tenkt å etterhvert ta over alle administrative oppgaver i bedriften, slik som kalender, timelister, support o.l. Aptopappa hadde per følgende funksjoner: Ha oversikt over alle prosjektene. Lage og opprettholde oppgaver for hvert prosjekt. Oppgaven ble delt inn i tre hovedgrupper, hvor øverste oppgaveliste var bestemt etter hvilken sprint man er i. Registrere timeføring for de ansatte. Ha oversikt over Aptomas produkter og tjenester. Ha oversikt over alle kundene, samt deres kontrakter med bedriften. Lage fakturaer i HTML-format, som ble skrevet ut og levert til posten. Oppdragsgiver ønsket at programmet skulle være mer selvdrevet. Ideelt sett ønsket bedriften at Aptopappa kunne styre prosjekter «helt av seg selv». Oppdragsgiver ønsker at man som utvikler ikke skal bry seg med tidsstyring, timelister osv, men bare konsentrere seg om oppgaven som 5 av 96

6 utvikler. Oppdragsgiver ønsket at vi skulle videreutvikle Aptopappa og legge til nye funksjoner slik at de vanligste oppgavene som trengs å gjøres i bedriften går av seg selv. 3.4 Mål Målet med oppgaven er å videreutvikle og legge nye funksjoner til Aptoma AS sitt prosjektstyringsverktøy Aptopappa. Systemet er til bruk innad i bedriften, og ble brukt hele tiden mens vi jobbet med det. Oppdragsgiver ønsket å legge til funksjonalitet for automatisering av fakturaer, automatisk rapportering til bedriftens egen IRC kanal, opplasting av filer i systemet og enklere måter å få tak i informasjon på Aptopappa før I og med at vår oppgave var å videreutvikle og legge til funksjonalitet i et allerede eksisterende program kan det være nyttig å beskrive programmet slik det var før vi begynte å jobbe med det: Aptopappa er et web-basert prosjektstyringsverktøy. Programmet er utviklet av Aptoma AS og er ment som et verktøy for å holde styr på ressursene til bedriften. Aptopappa er utviklet som et SCRUM-verktøy. Det vil si at det er bygd opp rundt metodikken til SCRUM. Aptopappa er altså et prosjektstyringsverktøy som følger SCRUMS repetitive planleggingsitterasjoner kalt sprint. Aptopappa bruker Ajax-teknologi for å gi applikasjonen et interaktivt brukergrensesnitt. Applikasjonen er responsiv og dynamisk, og bærer i så måte preg av en vindusapplikasjon. Aptopappa er utviklet med fokus på enkelthet og med et ønske om å holde ting enkelt. Det er unngått å ha for mange knapper og funksjoner synlig på en gang. Programmet er knyttet rundt forskjellige prosjekter. Der man i hvert prosjekt har en sprint. Dette vises visuelt med en graf. Man registrerer timer. Fordeler oppgaver. Ser framdrift. Har en produkt backlog, med oversikt over pågående oppgaver og oppgaver som må å gjøres. Programmet er rollebasert, det vil si at man bare ser det man trenger å se i forhold til hva man er, kunde, administrator eller ekstern utvikler. Man har mulighet til å holde følge med arbeidet en selv gjør ved å få en oversikt over sine «efforts». Systemet har vært i fullt bruk siden det første gang ble utviklet sommeren 2008 og har vært i fullt bruk under hele hovedprosjektperioden. Aptopappa blir brukt til å planlegge prosjekter. Det vil si: planlegge sprint, holde styr på deltagere, timetelling og oppgavefordeling innad i de forskjellige prosjektene. Systemet ble også delvis brukt til å sende ut fakturaer til kunder og holde oversikt over forskjellige kundeforhold. Oppdragsgiver var opptatt av at Aptopappa skulle være et enkelt program med minst mulig ting og knapper som tar fokus bort fra det man ønsker å gjøre. Det var viktig for bedriften at Aptopappa opprettholdt det høye nivået av brukervennlighet og at ting skal gå så enkelt som overhode mulig. Ønske fra oppdragsgiver var altså at Aptopappa skal beholde sin enkelthet, være fokusert og samtidig være så komplisert at det kan brukes til å gjøre alle mulige oppgaver i forhold til planlegging og gjennomføring av webutvikling. Aptopappas design og grensesnitt er allerede satt av oppdragsgiver, og det var derfor ikke nødvendig og endre noe på dette. Systemets grensesnitt så vel som design er enkelt, minimalistisk og ment å lage minst mulig forvirring for brukeren. Alle funksjoner er «gjemt» og dukker fram når man fører musepekeren over eller trykker på linker. Oppgaver i sprint og backlog kan flyttes logisk og enkelt med dra-og-slippmetoden Aptopappa nå Vi har ikke endret den allerede eksisterende funksjonaliteten til Aptopappa, vi har bare lagt til ny. Vi har gjort følgende: Laget et enklere system for utsending av faktura per epost som PDF. Gjort kommunikasjonen bedre. Vi har laget en IRC-bot som er aktiv på Aptoma AS egen IRC-server. IRC-boten henter informasjon fra Aptopappas RSS-feed over hendelser og sender dette videre til de forskjellige IRC-kanalene på IRC-serveren. 6 av 96

7 Vi har laget et supportsystem. Hvert prosjekt har muligheten til å få en supportfunksjon. På denne måten blir det opprettet support tickets av alle henvendelser på mail gjort til respektive prosjekter. Mail som blir sendt til de forskjellige prosjektenes support epost- adresser blir til support tickets i Aptopappa og utviklerne har da mulighet til å svare på ticketen med en gang, vente å se om det løser seg, sende ticketen over til en annen ansatt eller gjøre ticketen om til en oppgave slik at den blir en del av prosjektets oppgaver. Det er også laget ekstra funksjonalitet til supportsystemet, for eksempel så blir man påminnet om support tickets som ingen har tatt seg av, videresending av ubehandlede support tickets til sjefens mail og mulighet til å sette en autosvarbeskjed for supportepostadressen. Inkorporert og automatisert et allerede eksisterende system for unit-testing inn i Aptopappa. Dette gjør at koden blir gjennomgått for feil på gitte tidspunkt. Eventuelle feil blir rapportert til supportsystemet, mens om testen blir godkjent blir det gitt beskjed om dette på IRC-kanalene til Aptopappa. Vi har i tillegg til dette også inkorporert ny funksjonalitet i Aptopappa. For eksempel så har gjort det mulig å laste opp filer (bilder, video og lignende) i prosjektenes oppgaver og automatisert opprettelsen av HTML-dokumenter av Aptopappas dokumentasjon. 3.5 Rammebetingelser Oppdragsgiver hadde klare retningslinjer når det gjaldt teknologi. Siden Aptopappa allerede er skrevet i PHP, med elementer av Javascript og Ajax så var det ønskelig at vi fortsatte på samme måten. Aptoma AS har utviklet sitt eget rammeverk, AFW, som oppdragsgiver ønsket at vi satt oss inn i og fulgte. På grunn av at man i bedriften ofte redigerer og arbeider i de samme filene var det vikitg med et versjonskontrollsystem. Aptoma AS bruker Subversion som versjonskontrollsystem Utviklingsmiljø Oppdragsgiver hadde også klare retningslinjer når det gjaldt utviklingsmiljø. Oppdragsgiver satte som krav at vi brukte en ren teksteditor, som for eksempel Editra, TextMate, eller Notepad++ Det var også et krav at vi ikke brukte Windows som operativsystem på grunn av problemer med linjeavsluttningstegn. Vi brukte derfor Unix/Linux eller Mac sitt operativsystem, og passet på at filene vi laget var enkodet i UTF Nettlesere Da de ansatte hos Aptoma AS bruker forskjellige nettlesere har vi testet nye funksjoner i Aptopappa i følgende nettlesere; Chrome, Firefox, Safari og Opera. Men Aptopappa er optimalisert for siste versjon av Firefox. Internet Explorer har ikke vært aktuelt, da mye av den orginale funksjonaliteten i Aptopappa ikke fungerer fullstendig i Internet Explorer. 4. Planlegging Vi vil her forsøke å vise hvordan vi valgte oppgaven, bakgrunnen for at oppgaven ble løst som den har blitt, hvordan planleggingsfasen har vært, og hvilke beslutninger som ble tatt og hvorfor Innledende arbeid I midten av november 2008 tok vi kontakt med Geir Berset ved Aptoma AS, angående prosjektet «Automating Aptopappa» som ble beskrevet på hovedprosjektets nettside. Vi ble innkalt på intervju der Aptoma AS fikk informasjon om vår bakgrunn og motivasjon, og vi fikk mer informasjon om prosjektet. Vi syntes oppgaven virket veldig interessant ut, og var positive til å ha den som vårt hovedprosjekt. Aptoma AS valgte vår gruppe til sitt prosjekt og i starten av januar 2009 hadde vi et møte med Geir Berset der vi gikk gjennom oppgaven, krav, osv. Vi fikk opplæring i bedriftens måte å jobbe på og fikk kontoer i deres SVN slik at vi hadde tilgang til kildekoden til Aptopappa og AFW. Aptoma AS jobber etter SCRUM-metoden, og ønsket at vi skulle gjøre det samme. I SCRUM 7 av 96

8 jobber man tett sammen i kortere planleggings- perioder. I Aptoma AS sitt tilfellet var et ønskelig med 30 dagers iterasjoner, kalt sprint, med demonstrasjon av fungerende funksjoner i slutten av perioden. Da vi arbeider etter SCRUM-metoden var det vanskelig å sette opp en detaljert framdriftsplan, da man kun detaljplanlegger den førstkommende iterasjonen. Istedenfor ble planla vi hver sprint, og satte av tidsbruk etter de oppgavene vi så for oss å fullføre for den sprinten. Vi avtalte å jobbe med hovedprosjektet 3 dager i uken, mandag, tirsdag og onsdag fra Noe som ga iterasjoner på 180 timer over 30 dager. Da Aptoma AS sin måte å arbeide på gir mye fleksibilitet og frihet i form av hvor man sitter, ble vi enige om at vi enten kunne jobbe hjemme fra hver for oss, sammen eller på skolen, så lenge vi hadde et møte om dagen (dagens SCRUM) der vi diskuterte dagens arbeid, mål og hva vi hadde oppnådd fra forrige møte. Første fasen av prosjektet, forprosjektet, ble startet rett etter nyttår. Vi avtalte et møte med veileder, Geir Skjevling. Oppdragsgiver hadde laget en foreløpig kravspesifikasjon som ble i samarbeid med Geir Berset oppdatert og tilpasset dagens situasjon. Og med dette var vi raskt i gang med forprosjektrapport Første tanker Vi syntes det var veldig spennende, men også utfordrende å bli kastet rett inn i en arbeidssituasjon og et allerede påbegynt prosjekt. På den ene siden så er jo da hovedtanken, design og målsetting allerede bestemt av oppdragsgiver, noe som gir lite fleksibilitet og kreativitet i forhold til utvikling av programmet. Hadde vi fått i oppgave å lage et helt nytt program så hadde jo vi kunne bestemme mer hvordan ting skulle se ut, logikken i oppbygging og hvilken funksjonalitet som er viktig. Mens i dette prosjektet er det allerede bestemt fra oppdrags- giver hva som trengs og hvordan det skal se ut. Men på den andre siden er denne måten å jobbe på veldig mye mer realistisk i forhold til arbeid i en bedrift. Det er sjelden man får gjøre akkurat som man vil og lage et program utfra eget behov. Vi synes derfor det skulle bli veldig interessant å bli satt i en tilnærmet «normal» arbeidssituasjon og måtte forholde oss til oppdragsgiver som om vi skulle vært ansatt i bedriften Fremdriftsplan og arbeidsplan En generell framdriftsplan og arbeidsplan ble satt opp i starten av prosjektet. Det var vanskelig å være spesifisert og detaljert da vi planla selve arbeidet i 30 dagers iterasjoner. Den mer spesifikk fremdriftsplanen og arbeidsplanen ble satt opp inne i Aptopappa på starten av hver nye iterasjon. Vi brukte SCRUM sin «planleggings- poker» for å bestemme antatt tidsbruk og fordelte oppgaver utfra de forskjelliges kunnskaper, evner og kompetanse. Bilde under viser en generell framstilling av hvordan vi jobbet. Arbeidsperiodene til venstre i tabellen er de forskjellige iterasjonene vi gikk gjennom. Timelister med beskrivelse av hva de forskjellige har gjort ligger vedlag på slutten av dokumentett. 8 av 96

9 Fig 1. Fremdriftsplan Metode 9 av 96

10 Vi bestemte oss for å jobbe etter oppdragsgivers systemutviklingsmetode, deres egen variant av SCRUM. SCRUM i kombinasjon med XP (Extreme Programming). SCRUM defineres slik på Wikipedia.org: Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development. (...) Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach. Kilde: Fig 2 SCRUMs utviklingsprosess. Kilde XP defineres slik på Wikipedia.org: Extreme Programming (XP) is a software engineering methodology (and a form of agile software development) (...) prescribing a set of daily stakeholder practices that embody and encourage particular XP values (...). Proponents believe that exercising these practices traditional software engineering practices taken to so-called extreme levels leads to a development process that is more responsive to customer needs ( agile ) than traditional methods, while creating software of better quality. Kilde: Fig 3 XPs utviklingsprosess. Kilde: en.wikipedia.org/wiki/extreme_programming 10 av 96

11 Aptoma AS definerer sin variant av SCRUM slik: What do we do at Aptoma? We call it Scrum even though we cover the technical practices of XP as well. However, we will never admit to doing Extreme Programming due to its silly, silly name. ( Extreme wouuu). There is absolutely nothing extreme or remarkable about agile. It s just down to earth Common Sense Results Focused Tight Development) I ll rather admit to being a Scrum based or Lean software development organization any day. Lean = The XP + Scrum combination, better explained and without the silly naming. Fra Aptoma AS sin blog Select *. Aptoma AS sin variant av SCRUM består av 6 steg: 1. Create and maintain a Product Backlog. This is a list of user stories sorted by a simple but powerful cost vs. benefit analysis. 2. Hold a monthly sprint planning meeting. Select the top requirements from the product backlog during Sprint Planning, part 1. The team break these requirements into actionable items (tasks), during the second segment, and carefully adds their time estimates. A goal that the team can commit to is then constructed for the sprint. Everything put into the sprint should be potentially ready for production before the sprint ends, remember? Tools to aid you adding the correct amount of requirements to the sprint is the calculated sprint velocity (how many ideal man-hours you can put into the sprint) versus the task estimates. Sprint velocity, in turn, depends on the focus factor. More on these new terms later. 3. Do The Sprint (with Daily Scrums). The team carries out the sprint during the coming month, and Scrum Masters are mere facilitators at this stage. The team selforganizes to make the real magic happen. Through daily scrums (short, informal team get-togethers) lasting only 5 to 15 minutes regardless of team size, the team stays synchronized and focused on the sprint tasks. Every team member answer only three questions; a) What did I do since our last daily scrum? b) What am I planning to do until the next daily scrum? c) What is stopping me from working as effectively as possible, if anything? 4. Sprint review. AKA The Demo. The team explains the goal of the sprint, and shows off the requirements that has been turned in to finished functionality, potentially ready for production, in a demo. Anyone can turn up to this event, and the demo should be understandable by the customer. Feedback is gathered during and after the review. 5. Sprint retrospect. The goal is to learn something from the just finished sprint. The team discuss the following three questions : a) What went well? b) What can be improved? and c) What will we focus on improving during the next sprint? Suggestions for improvement can be turned into requirements and put into the product backlog, ensuring that the team commits to them during upcoming sprints. 6. Rinse and repeat every 30 days. And that s all there is to it. 11 av 96

12 Fra Aptoma AS sin blog. Aptoma AS sin variant av SCURM vil altså si at man: lager en enkel oversikt over oppgavene som trengs gjøres i nærmeste framtid har en månedlig Sprint-planning der man planlegger detaljert og estimerer oppgaver for de neste 30 dagene har daglige Scrums, det vil si små daglige møter på 5 til 15 minutter hvor man diskuterere hva man har gjort, hva man skal gjøre og om det er noe som forhindrer en til å jobbe ordentlig denne dagen. har en demo, det vil si en demonstrasjon av ferdig funskjonalitet. Hele bedriften bør være til stede, og alle kommer med konstuktiv tilbakemelding. har en månedlig retrospekt, der man går gjennom forrige Sprint, finner ut hva som gikk bra og dårlig sånn at man er klar for neste Sprint. Dette gjentar man altså månedlig, eventuelt med kortere eller lengre Sprinter, alt etter som hva slags arbeid man gjør. Et annet viktig prinsipp for Aptoma AS er at man alltid strekker seg etter å gjøre ting 100% ferdig i løpet av en Sprint. Det er viktigere for bedriften at man gjør det man holder på med klar for bruk i løpet av en Sprint, enn å gjøre hundre ting litt ferdig. Når man er ferdig med en Sprint skal man i teorien kunne legge fra seg et prosjekt å gå over i et annet uten at det henger ved arbeid eller er noen løse tråder. Did you ever start coding on some functionality, only to find that it depends on something that is almost finished, but not quite? Obviously you ll have to finish the 90% done item. And it takes a lot of time, you have to dig into it (losing the context of the current functionality you are working on) in order to complete it properly. Antidote : Schedule work one user-story at a time, and bring all code to 100% completion i.e make it pass all unit-tests and acceptance tests (customer tests) before proceeding to the next feature. Fra Aptoma AS sin blog Select *. Vi har i vårt hovedprosjekt prøvd så godt vi kan å jobbe etter Aptoma AS sin metode. Dette har vært både krevende og vanskelig, men mest av alt, interessant og veldig lærerikt. Det har vært vanskelig å skulle lære en ny måte å tenke på, og det har vært vanskelig å skulle følge denne nye tankegangen når alt vi har lært på skolen og dokumentasjonsstandarden og -eksemplene er bygd opp etter helt andre prinsipper. Da vi har lært at man må planlegge alt før man begynner, ha en fullstendig plan og kravspesifikasjon klar først (jevnført RUP, UP og Fossefallsmetodikker), så er Aptoma AS sin metode helt anderledes. Her skal man planlegge for korte perioder, kravspesifikasjon og framdriftsplan er dynamisk, og hovedfokus er på å ha 100% ferdig kode i løpet av korte itterasjoner. Men etter å ha lest, lært og skjønt hvordan oppdragsgiver tenker har det gjort at vi har fått et annet perspektiv når det gjelder programutviklin. Vi føler at vi ved å jobbe etter denne metoden har fått en mye mer arbeidslivsnær erfaring og er klar for å begynne i det virkelige arbeidslivet Kravspesifikasjon Kravspesifikasjonen var generelt og foreløbig satt opp av oppdragsgiver høsten Vi gikk gjennom denne i samarbeid med Geir Berset og oppdaterte den, la til nye oppgaver og diskuterte hva oppdragsgiver ønsket og hva vi syntes virket interessant i forhold til et hovedprosjekt. Men siden vi jobber etter Aptoma AS sin SCRUM metode har det vært vanskelig å bestemme og 12 av 96

13 fastsette alt før vi begynte, så kravspesifikasjonen har blitt oppdatert og omgjort gjennom hele prosessen. Kravspesifikasjon og opprinnelig oppgavetekst ligger vedlagt. 5 Utviklingsprosessen Dette kapittelet omhandler de ulike utviklingsfasene vi har vært igjennom. Det blir beskrevet utfordringer og valg vi stod overfor, hvilke løsninger vi vurderte og hvilke løsninger vi valgte. 5.1 Kompetansetilegning Denne delen tar for seg hvilke verktøy og teknologier vi har tatt i bruk, samt hvilke teknologier som var ukjente for oss og hvilke vi måtte fordype oss i. Siden Aptopappa er et allerede utviklet system ble det lagt føringer fra oppdragsgiver for hvilke språk og rammeverk som skulle brukes. Det ble også satt krav til tekniske løsninger. I bunnen av applikasjonen ligger en database av typen MySQL. Aptopappa er utviklet med objektorientert PHP og oppdragsgivers eget PHPrammeverk, AFW. Brukergrensesnittet er utviklet ved hjelp av HTML, CSS og Javascript. På grunn av bedriftens krav til fleksibilitet var det viktig med en versjonskontroll, så vi måtte også sette oss inn i Subversion (SVN) for å kunne arbeide i samme kildekode som andre uten å ødelegge hele programmet. Det var også krav fra oppdragsgiver om at vi måtte utvikle enten med Mac OS eller et Unix os, dette pga. linjeavslutningstegn og filkoding. Windows var ikke akseptert som OS, da editorer som oftest laget filer med feil koding og linjeavslutningstegn. Her følger en detaljert oversikt over de ulike verktøyene og språkene vi har tatt i bruk: Programvare / Teknologi Beskrivelse Programvare/teknologi Apache HTTP Server PHP MySQL Beskrivelse Webserver Programmeringsspråk (server-side) PHP: Hypertext Preprocessor DBMS (database management system) Memcached AFW System for caching av databasekall på webserver Aptoma Frame Work, Aptomas eget rammeverk MySQL Admin MySQL Query Browser Brukeradministrasjon for MySQL Spørringsverktøy for MySQL MySQL Work Bench Mozilla Firefox 3.x.x Firebug og FirePHP Subversjon SVN HTML Verktøy for databasemodellereing Webleser Feilsøkingsverktøy for Mozilla Firefox. Versjonskontroll HyperText Markup Language 13 av 96

14 Automating Aptopappa Hovedprosjekt våren 2009 Programvare/teknologi Beskrivelse CSS Cascading Style Sheets Javascript Klientbasert scriptingsprål Vi hadde allerede en generell kjennskap til de fleste av disse teknologiene. Gjennom skolen hadde vi blant annet blitt kurset i programmering, webprogrammering og systemutvikling. Og deler av gruppa hadde også erfaring med teknologiene utenom skolen. Men det var likevel en del nytt å sette seg inn i. Spesielt det å jobbe med en versjonskontroll som Subversion var nytt for oss. Og å jobbe så pass konkret etter en metode var også en ny måte å tenkte på. PHP hadde vi kort vært borti gjennom skolen og via annet arbeid. Aptopappa er hovedsaklig programmert i PHP. PHP er et open source høynivåspråk, utviklet av utviklere. Syntaks minner mye svært mye om Java og C++. Vi hadde alle en eller annen tidligere erfaringer med objektorientert utvikling, da blant annet i Java, og det var derfor ikke alt for stor overgang til å programmere i PHP. Aptoma AS sitt eget rammeverk, AFW, var delvis dokumentert av oppdragsgiver, og var ellers lagt opp til objektorientert programmering og var derfor relativt enkelt å sette seg inn i. Alle teknologiene vi har benyttet oss av ligger åpne for allment bruk, og er stort sett grundig dokumentert. Det har derfor ikke vært nødvendig å bruke andre oppslagsverk Design Her blir designfasen beskrevet. Den tar for seg noen av de viktigste avgjørelsene vi har har tatt, hvilke løsninger vi har valgt samt hvorfor vi valgte disse Bakgrunn for designet På grunn av at vi utviklet på et allerede utviklet system var det allerede føringer på design. Vi ønsket ikke at våre nye funksjonaliteter skulle skille seg ut, så vi valgte å følge oppdragsgivers design, oppbygging og logikk. Aptopappas viktigste oppgave er å være brukervennlig, enkel og uten elementer som virker forstyrrende. Knapper, linker og funksjoner skal være logiske, rett fram og intuitivt oppbygd. Fig 4 Eksempel på rotete side Kilde: 14 av 96

15 5.2.1 Utfordringer med design Det har vært flere utfordringer når det gjelder design. Først og fremst har det vært viktig å hele tiden ha et brukervennlig design. Vi har derfor måtte passe på å ikke ha for mange linker, knapper eller andre forstyrrende elementer synlig på siden. Vi har derfor måtte tenke igjennom hvordan man kan samle forskjellig funksjonalitet på samme sted og hvordan man smart kan gjemme ting man ikke trenger hele tiden. For eksempel ved å ha en såkalt mus-overfunksjon. Det vil si at linken, knappen eller bildet kun er synlig når man holder Fig 5. eksempel fra Aptopappa der flere funksjoner musepekeren over et bestemt område. er smalet inn under ett Ikoner Vi har lagt til to ikoner til Aptopappa. Et ikon for generering av dokumentasjon i prosjektsiden, og et for e-postmalen for prosjektestimeringen. Andre ikoner som er brukt, har allerede vært tilgjengelig i Aptopappas filstruktur Fig 6 Ikon for generering. av dokumentasjon 5.3 Implementasjon Denne delen av dokumentet beskriver det vi syntes var de største utfordringene vi møtte på, valgene vi stod ovenfor, hvilke løsninger vi vurderte, samt hvilke løsninger vi valgte Prototype, scriptacolous og JSON Prototype er et rammeverk for Javascript som tilbyr objektdreven funksjonalitet for Javascript, og utvider DOM med mange nyttige funksjoner. Videre tilbyr Prototype kraftige Ajax-verktøy for oppdatering og uthenting av informasjon dynamisk. Scriptaculous er basert på Prototype og leverer ferdigutviklede komponenter som ved hjelp av Javascript, CSS og Ajax-kall tilbyr funksjonalitet som; dra-og-slipp, autooppdaterende tekstfelt, og mye mer. Aptopappa er stor forbruker av både prototype- og scriptacolous- funksjonalitet, og vi så på dette som noe vi var nødt til å settes oss inn i. Den nye funksjonaliteten i Aptopappa både bruker, og utvider deler av disse javascript-rammeverkene. JSON er en protokoll mye brukt i Ajax-kall mellom server og klient, som tilbyr enkel metode for å overføre flere verdier på en gang. JSON som kommunikasjonsmodell er mye brukt i Aptopappa, og hjelper til ved f.eks. å gi brukeren mer meningsfulle feilmeldinger dersom disse skulle oppstå PDF-generering av faktura PDF-generering i PHP var noe som var nytt for oss. Vi kikket på et par ferdige biblioteker som for eksempel PHP sin innebygde løsning, og lette også etter noe gratis konverteringsverktøy for HTML til PDF. Etter å ha vurdert de forskjellige løsningene som fantes, bestemte vi oss for å gå for PHP-klassen FPDF, og lage fakturaene selv, framfor et konverteringsverktøy. Vi kom fram til klassen fpdf av følgende grunner: Åpen lisens, helt fritt bruk 15 av 96

16 Krever ingen ekstra tilleggsbiblioteker for PHP Genererer PDF-kode helt selv Enkelt å lage egne PDF-dokumenter. Vi kom fort i gang med å generere PDF-fakturaer, og de ble seende ut akkurat som HTMLversjonen. Eneste ulempe med denne løsningen er at dersom Aptoma skal endre utseende på PDF-fakturaen, så må dette gjøres både i HTML-versjonen og i PDF-versjonen IRC-bot IRC-protokollen var nytt for oss alle. Ønsket til Geir var å få feedback fra Aptopappa inn på bedriftens IRC-server. For å finne en løsning for denne oppgaven, tenkte vi først på å finne en ferdig idle-klient (altså et program som venter på forespørsler, og så poster det på IRC). Aptopappa ville da hatt en cronjob som koblet seg opp til denne med gjevne mellomrom. Problemet med slike klienter er at IRC-kanalene blir da hele tiden spammet med join/quit meldinger. Vi innså at dette ikke var noen god løsning. I stedet så bestemte vi oss for å lage vår egen IRC-bot. Med litt undersøking, så fant vi ut at IRC-protokollen var ganske enkel å lære. Det tok ikke lang tid før vi hadde vår første utgave av IRC-boten. For å hente data fra Aptopappa fant vi ut at det kunne lønne seg å sette opp et RSS-feed, slik at IRC-botten vår kunne koble seg opp og hente ned de siste hendelsene. Programmeringsmessig valgte vi Perl som språk. Perl er et såpass enkelt, kjapt og kraftig språk med innebygde nettfunksjoner. Vi valgte å bruke et ferdig bibliotek til Perl for å last ned data fra RSS. Det som har vært litt utfordrende med IRC-botten er å skrive Perls regulære uttrykk. IRCprotokollen er en ren tekst protokoll. Ved å bruke regulære uttrykk, ble omgjøringen av protokolltekst til data ikke noe problem Supportsystemet For supportsystemet, var det på forhånd bestemt at det skulle benyttes en felles e-postkonto over IMAP. Vår utfordring i denne oppgaven lå i å skrive en e-postklient som kunne laste ned postboksen, og legge e-post inn som oppgaver i Aptopappa. Vi så på flere løsninger for IMAPoppkobling i PHP, og kom fram til IMAP-modulen til PHP var den greieste. Det krevdes en ekstra modul som måtte installeres på server, men modulen er mye brukt og oppdateres jevnlig Filopplasting med Ajax-liknende funksjonalitet En Ajax-metode for å laste opp filer finnes ikke. Javascript er begrenset til nettleseren, og får ikke snakke med det lokale filsystemet, annet enn gjennom HTML-taggen i Input, av type file. For å få til Ajax-liknende funksjonalitet i filopplastingen, fant vi en javascript-klasse hos webtoolkit.info kalt AIM. Javascript klassen er gitt ut i en fri lisens, og vi kunne derfor bruke dette. AIM benytter en skjult iframe, hvor det ligger en annen filopplastingsboks. Det er en skjulte filopplastingsboksen som laster opp dokumentet i bakgrunnen. Den synlige boksen blir tømt etter opplasting Automatisk kodekontroll Automatisk kodekontroll benytter AFW sine egne testverktøy. Utfordringen med disse kodekontrollene var å få lastet ned de siste versjonene av softwaren som skulle testes og å tolke testresultatene. Det var vanskelig å jobbe mot AFW som er et rammeverk som stadig er i utvikling. Vi var nødt til å samarbeide med flere av de ansatte i bedriften og forholde oss til det de hadde gjort og hvordan de arbeidet og tenker Testing Aptoma AS sin versjon av SCRUM tilsier at man tester all kode man lager før man committer den tilbake til trunken. Dermed blir det kontinuerlig utført tester. Det er også viktig med testing 16 av 96

17 før demonstrasjon etter endt sprint. Vi har derfor hele tiden gått gjennom og teste systematisk. Det har aldri vært committet ufullstendig kode eller kode som ikke fungerer. For å finne ut hvor eventuelle feil ligger har Aptopappas rammeverk AFW gode rutiner for feilrapportering, ellers har vi bruk Mozilla Firefox s FireBug-utvidelse for å lokalisere feil. En utdypet testrapport ligger vedlagt i sin helhet senere i slutt- dokumentasjonen. Her er det dokumentert testing etter hver ferdige funksjonalitet. 6. Samarbeid Her beskrives samarbeidet i gruppen, samarbeidet mellom veileder og gruppen, og samarbeidet med oppdragsgiver Samarbeid med oppdragsgiver og sluttbruker Vi har at et meget positivt samarbeid med Aptoma AS. Bedriften ga oss mulighet til å sitte i deres lokaler, men der var det svært dårlig plass, så vi byttet på å jobbe hjemmefra, på skolen eller i lunsjrommet til bedriften. Vi har hatt månedlige møter i bedriftens lokaler der vi sammen med ekstern veileder Geir Berset har gått gjennom det vi har gjort i perioden før og planlagt hva som skal gjøres i neste iterasjon. Vi har også hatt månedlige demonstrasjoner der vi har visst fram det vi hadde gjort til hele bedriften. Vi har gjennom hele prosjektperioden fått god og konstruktiv tilbakemelding fra Geir Berset. Utenom møtene hadde vi også flere møter over Skype med demonstrasjon over VNC hvor vi fikk tilbakemelding, tips og råd. Aptoma AS bruker SCRUM sin metodikk som utgangspunkt for hvordan de jobber. Vi ble oppfordret til å gjøre det samme og har fått god hjelp til å gjennomføre dette. SCRUM var nytt for gruppen som arbeidsmetode, så det var en liten tankeomstilling, men det har med hjelp fra ekstern veileder vært veldig enkelt. 6.2 Samarbeid i gruppen Vi har samarbeidet i samme gruppen i nesten alle prosjektene vi har hatt ved Høyskolen i Oslo og det var derfor veldig naturlig å gjøre det igjen. Vi har en god gruppedynamikk og samarbeidet går mye av seg selv. Eneste problemet med samarbeidet har vært at vi har en litt skjev fordeling når det gjelder kompetanse. Erik og Henning har mye erfaring fra før når det gjelder PHP og SQL, mens Ida har mindre erfaring på dette feltet. Det ble derfor en skjev fordeling av arbeidet i begynnelsen, da det var lettere for Erik og Henning å programmere det som skulle gjøres enn å vente på at Ida skulle komme til samme nivå. Men etter noen runder med dette ble vi enige at vi alle skal ta like stor del av programmeringsarbeidet, selv om noen er raskere eller tregere enn de andre. Så med litt ekstra tid og innsats fra Ida og tålmodighet fra Erik og Henning ble etterhvert arbeidsfordeling og tidsbruk jevnere. Og vi har lært at ikke alle er like flinke til alt, og at det derfor kan være nyttig med litt delegering og oppdeling av arbeidet for å nå en deadline, men for å fungere som en gruppe og ha en eierfølelse til prosjektet er det likevel viktig at alle har kjennskap til alle delene av prosjektet Veiledning fra Høgskolen i Oslo Vi ble fordelt veileder Geir Skjevling av Høgskolen i Oslo januar Vi avtalte tidlig et møte med han for å diskutere hovedprosjektet. Etter dette møtet, hadde vi ikke mer kontakt med han. Vi holdt heller mer kontakt med vår eksterne veileder, som hadde også erfaringer fra tidligere hovedprosjekter ved skolen. 17 av 96

18 7. Oppsummering/Konklusjon 7.1 Oppsummering Sluttproduktet, Automating Aptopappa, har gruppen planlagt og utviklet i tett samarbeid med oppdragsgiver. Vår opplevelse er at dette prosjektet er så nær opptil en faktisk arbeidssituasjon man kan komme med et skoleprosjekt. Aptoma AS har fungert som både kunde, oppdragsgiver, veileder og arbeidsplass. Vi har blitt behandlet som en ansatt i bedriften der det har vært forventet av oss at vi jobber etter samme metode, følger deres rammeverk og deres deadlines. Selv om vi har vært såpass styrt av prosjektets rammer har vi likevel kunnet bruke oss selv, være kreative og finne på gode løsninger. Det har vært et tidskrevende og vanskelig prosjekt. Det har vært mye nytt å sette seg inn i, nye metoder, nye programmeringsspråk, og nye måter å tenkte på. Det har vært et utfordrende prosjekt, men mest av alt har det vært lærerikt og interessant. Vi har lært masse om hvordan ting faktisk fungerer i arbeidslivet, hvilke krav og utfordringer som venter oss etter ferdige studier. Det har blitt stilt høye krav til oss fra oppdragsgiver, og forventningen har vært høy, men vi føler vi har klart å innfri og levere et godt produkt, med høy funksjonalitet og god kvalitet. Vi har blitt sterkere både når det gjelder programmering, metodikk, samarbeid og prosjektarbeid. Dette prosjektet har på alle måter vært en viktig del av utdanningen og gjort oss klar til arbeidslivet. 7.2 Hva kunne vært gjort bedre Vi mener vi har fått til et godt produkt og at vi har hatt en veldig lærerik prosess, men det er alltid noe som kunne ha vært gjort bedre. Etter hver demo har vi hatt en gjennomgang av hva som har gått bra og hva som har gått dårlig, og et punkt som stadig dukket opp var at kompetansen er ganske skjevt fordelt, vi strevde derfor med å ha lik arbeidsmengde innad i gruppen. Men dette mener vi at vi har løst på en tilfredstillende måte, da vi ble mer observante på dette og jobbet aktivt med at alle skulle ta en like stor del i arbeidet, ble det etter hvert en jevnere fordeling av arbeidet. Vi føler nå at alle har et likestort eierskap i det ferdige produktet. Andre ting som kunne ha vært gjort bedre eller i alle fall anderledes er hvordan vi valgte å løse oppgaven. Vi har sett dette prosjektet som en god erfaring i forhold til å være ansatt i en bedrift. Vi har derfor hele tiden konferert med ekstern veileder og gjort ting slik han ønsket. Vi kunne nok på mange måter ha vært friere og mer kreativ, men da tror jeg samtidig at vi hadde mistet følelsen vi hadde av å være en del av bedriften. Samarbeidet med høyskolens veileder kunne nok også ha vært bedre. Men da vi synes vi fikk en veldig god kontakt og masse hjelp av den eksterne veilederen så så vi ikke noe behov for noe videre samarbeid med høyskolens veileder. 7.3 Konklusjon Dette har vært et interessant, meget lærerikt og veldig arbeidskrevende prosjekt. Vi har lært masse, både om arbeidslivet, systemutvikling, samarbeid, kommunikasjon i en gruppe, tidsplanlegging i et stort prosjekt og i forholdt til programmering. Vi mener at vi er mye bedre rustet nå til å møte arbeidslivet og å jobbe i en bedrift som driver med systemutvikling eller programmering. 18 av 96

19 Produktrapport for Automating Aptopappa 19 av 96

20 1. Forord Dette dokumentet er produktdokumentasjonen til vårt hovedprosjekt våren 2008, Automating Aptopappa. Hovedprosjekteter et samarbeid mellom Høgskolen i Oslo, og vår oppdragsgiver, Aptoma AS. Produktdokumentasjonen beskriver det ferdige produktets funksjonalitet, virkemåte og oppbygging. Produktdokumentasjonen skal sammen med prosessrapporten gi leseren et helhetlig inntrykk av arbeidet som er utført og det produktresultatet som er oppnådd. Dokumentet gir en generell beskrivelse av systemet slik at leseren skjønner hvordan det henger sammen. Rapporten beskriver også systemets oppbyggning, databasestruktur, teknologier brukt, sikkerhet og rammebettingelser. 20 av 96

21 2. Innholdsfortegnelse 3. Innledning Om bedriften Dagens situasjon Mål Konklusjon Teknologie Rammebetingelser Utviklingsmiljø Nettlesere Benyttede teknologier, språk, og rammeverk Apache 2.4.x PHP 5.3.x MySQL 5.0.x MySQL Admin MySQL Query Browser MySQL Word Bench AFW Mozilla Firefox 3.x.x Firebug og FirePHP Subversjon SVN HTML XML CSS Perl Javascript Javascript: Prototype Javascript: webtoolkit.aim Javascript: Scriptaculous Datastrukturer og oppbyning Database ER-diagram Tabeller Projects tasks customers invoices Arkitektur Design Grafikk og fargebruk Beskrivelse av systemet Generell beskrivelse Produktets oppbyggning og virkemåte Programoppbygging Hovedkomponenter Sende PDF-faktura Generering av PDF Lagring av PDF-faktura Sikkerhet Sending Supportsystem Komme i gang Konfiguarsjonsverdier Hente support e-post Funksjonalitet Filopplasting i oppgaver Endringer i eksisterende kode Begrensing Filplassering og filnavn Sikkerhet RSS til IRC Egne triggere Automatisk kodekontroll Komme i gang Kjøre kodekontrollene Resultater Dokumentasjonsgenerering av oppgaver under docs Skrive E-postmal Se E-postmal Sikkerhet i systemet Krav til miljø For bruker av Aptopappa For å kjøre Aptopappa Utvidelsesmuligheter av 96

22 3. Innledning 3.1 Om bedriften Aptoma AS utvikler webapplikasjoner. Deres hovedkunder er avisselskaper og mediebedrifter i Norge og utlandet. Aptoma AS leverer blant annet løsninger innen web-tv, visuell produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus. Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har utviklet flere dynamiske og multimediale webapplikasjoner. Blant annet et verktøy for oppsett av forsider, Dr. Front., som blir brukt på blant annet VGnetts og den franske nyhetsnettsiden « Bedriften samarbeider også andre mediebedrifter for eksempel Asker og Bærum Budstikke og Scanpix/NTB. Aptoma AS er en relativt liten bedrift med 7 utviklere og programmerere. De fleste holder til i Oslo, men de har også en ansatt som jobber og bor i Sverige. Det er viktig for bedriften å være så mobil som mulig, altså ikke være avhengig av å være på kontoret for å kunne jobbe. Det er stor fleksibilitet for de ansatte, om de vil jobbe hjemmefra, i bedriftens lokaler og til hvilket tidspunkt. Aptoma AS jobber etter en fleksibel utviklingsmetode sterkt inspirert av SCRUM og XP. Vi har valgt å jobbe etter bedriftens metode. Dette vil bli beskrevet ytteligere senere i rapporten. 3.2 Dagens situasjon Oppdragsgiver har i løpet av sommer og høst 2008 utviklet et eget prosjektstyringsverktøy; Aptopappa. Aptopappa er et webbasert grensesnitt for oppgavestyring. Systemet skal forenkle jobben med planlegging og styring av prosjekter. Programmet er tenkt og etterhvert ta over alle administrative oppgaver i bedriften, slik som kalender, timelister, support og så videre. Men oppdragsgiver ønsket at programmet skulle være mer selvdrevet. Ideelt sett ønsket bedriften at Aptopappa kunne styre prosjekter helt av seg selv. Oppdragsgiver ønsker at man som utvikler ikke skal bry seg med tidsstyring, timelister osv, men bare konsentrere seg om oppgaven som utvikler. Oppdragsgiver ønsket at vi skulle videreutvikle Aptopappa og legge til nye funksjoner slik at de vanligste oppgavene som trengs å gjøres i bedriften går av seg selv. 3.3 Mål Målet med oppgaven er å videreutvikle og legge nye funksjoner til Aptoma AS sitt prosjektstyringsverktøy Aptopappa. Systemet er til bruk innad i bedriften. Oppdragsgiver ønsket å legge til funksjonalitet for automatisering flere ting innen systemet. Blant annet ønsker bedriften enklere behandling av fakturaer, automatisk rapportering til bedriftens egen IRC kanal, bedre kommunikasjonen innad i bedriften og genrelt gjøre ting enklere. 3.4 Konklusjon Vi mener dette systemet vil: gjøre kommunikasjonen bedre innad i Aptoma AS. gjøre det enklere å sende ut fakturaer.. gjøre det enklere for de ansatte å ha oversikt over supportoppgaver. gi raskere responstid på supportoppgaver gjøre det enklere å legge informasjon inn og data til, og få tak i informasjon i systemet.. 4. Teknologier Her beskriver vi hvilke teknologier, programmeringsspråk og rammebetingelser vi har hatt å forholde oss til. 4.1 Rammebetingelser Oppdragsgiver hadde klare retningslinjer når det gjaldt teknologi. Siden Aptopappa allerede er skrevet i PHP, med elementer av Javascript og Ajax så var det ønskelig at vi fortsatte på samme måten. 22 av 96

23 Aptoma AS har utviklet sitt eget rammeverk, AFW, som oppdragsgiver ønsket at vi satt oss inn i og fulgte. På grunn av at man i bedriften ofte redigerer og arbeider i de samme filene var det vikitg med et versjonskontrollsystem. Aptoma AS bruker Subversion som versjonskontrollsystem. Her følger en oversikt over benyttede teknologier, språk og rammeverk: Programvare/teknologi Beskrivelse Apache HTTP Server PHP MySQL Webserver Programmeringsspråk (server-side) PHP: Hypertext Preprocessor DBMS (database management system) Memcached AFW System for caching av databasekall på webserver Aptoma Frame Work, Aptomas eget rammeverk MySQL Admin MySQL Query Browser Brukeradministrasjon for MySQL Spørringsverktøy for MySQL MySQL Work Bench Mozilla Firefox 3.x.x Verktøy for databasemodellereing Webleser Firebug og FirePHP Subversjon SVN HTML CSS Javascript Feilsøkingsverktøy for Mozilla Firefox. Versjonskontroll HyperText Markup Language Cascading Style Sheets Klientbasert scriptingsprål 4.2 Utviklingsmiljø Oppdragsgiver hadde også klare retningslinjer når det gjaldt utviklingsmiljø. Oppdragsgiver satte som krav at vi brukte en ren teksteditor, som for eksempel Editra, TextMate, eller Gedit. Det var også et krav at vi ikke brukte Windows som operativsystem på grunn av problemer med linjeavsluttningstegn. Vi brukte derfor Unix/Linux eller Mac sitt operativsystem, og passet på at filene vi laget var enkodet i UTF av 96

24 4.3 Nettlesere Da de ansatte hos Aptoma AS bruker forskjellige nettlesere har vi testet nye funksjoner i Aptopappa i følgende nettlesere; Chrome, Firefox, Safari og Opera. Men Aptopappa er optimalisert for siste versjon av Firefox. Internet Explorer har ikke vært aktuelt, da mye av den orginale funksjonaliteten i Aptopappa ikke fungerer fullstendig i Internet Explorer. 4.4 Benyttede teknologier, språk, og rammeverk Apache 2.4.x Apache er en fullskala webserver som er utviklet gjennom et samarbeid mellom frivillige individuelle utviklere. Apache er derfor gratis og kildekoden ligger åpent tilgjengelig for alle. Apache er kjent for å være den sikreste og mest brukte webserveren på Internett for tiden PHP 5.3.x PHP, HyperText-Preprocessor, eller Personal HomePage som det egentlig kommer av, er et serversidig skriptspråk. Det betyr enkelt og greit at det som utføres av oppgaver gjøres på serveren, og ikke på klienten MySQL 5.0.x MySQL er et relasjonsdatabasesystem MySQL Admin Verktøy for å håndtere brukere og rettigheter MySQL Query Browser Verktøy for å gjøre spørringer og kjøre scripts mot en MySQL database MySQL Word Bench Verktøy for å lage ER diagrammer AFW AFW er Aptomas eget rammeverk. Dette rammeverket er fortsatt under utvikling Mozilla Firefox 3.x.x Firefox er den nettleseren vi har brukt mest under utviklingen av Aptopappa. Dette er fordi den har gode muligheter for feilsøking Firebug og FirePHP Firebug of FirePHP er addons til Firefox. Disse brukes til feilsøking av for eksempel Ajax kall og kodeinspeksjon Subversjon SVN Subversion er et kildekodeversjonskontrollsystem. SVN er mye brukt av Aptoma. All kildekode som Aptoma skriver, legges opp på deres svn tjener HTML HyperText Markup Language, eller HTML som det ofte blir kalt, er språket som blir brukt for å vise dokumenter på Internett XML XML er et språk for å omkapsle informasjon CSS Cascading Style Sheet, eller CSS, er et språk som brukes til å definere hvordan HTML eller XML sider vil se ut. 24 av 96

25 Perl Perl er et avansert scripting språk. Det er raskere enn PHP, og egnet seg derfor til å bruke for og skrive en IRCBot Javascript Javascript er et skriptingsspråk brukt for å utføre oppgaver på klientsiden for en nettside Javascript: Prototype Prototype er et javascript rammeverk, som tilføyer mange nye funksjoner til javascript språket. Prototype gjør ting på en mer objekt basert måte, og tilbyr Ajax funksjoner som er lette å bruke Javascript: webtoolkit.aim Webtoolkit.aim er en liten del av webtoolkit. Dette biblioteket tilbyr en måte å laste opp filer uten å måtte oppdatere hele nettsiden Javascript: Scriptaculous Scriptaculous er et javascript bibliotek som tilbyr mange nye funksjoner, for eksempel animasjoner, effekter, dra-og-slipp og inplaceeditor. 5. Datastrukturer og oppbygning Her vil vi beskrive programmets datastruktur og oppbygning. Dette vil vi demonstrere ved hjelp av blant annet ER-diagram, beskrivelse av databasens tabeller og oversikt over klasse og filstruktur Database Da Aptopappa allerede er et fungerende program med en fungerende database, var det ikke nødvendig å lage en ny database. Vi redigerte kun noen få tabeller i databasen der vi la til atributter vi trengte til de nye funksjonene. Vi endret følgende tabeller i databasen: projects tasks customers invoices Aptopappa benytter siste versjon av MySQL. Vi har for det meste brukt mysql fra konsoll på enten Linux eller Mac, samt til tider MySQL Administrator, MySQL Query Browser for å redigere, spørre og modellere databaseendringene. MySQL Work Bench er brukt for å lage ER-diagrammet. 25 av 96

26 ER-diagram Automating Aptopappa Hovedprosjekt våren 2009 Fig 6 ER-diagram 26 av 96

27 Tabeller Vi har endret følgende tabeller: Projects I denne tabellen la vi til fire attributter: Kolonne tickets autoresponsemessage code_checking code_revision tasks I denne tabellen la vi til en attributt: Kolonne ticketfrom customers I denne tabellen har vi lagt til en attributt: Kolonne Beskrivelse Verdien forteller hvilken adresse som skal stå i TIL-feltet for e-post som kommer inn i supportpostboksen for at den skal hentes inn til dette prosjektet. Tomt felt deaktiverer support for prosjektet. Feltet inneholder meldingen kunden får når det kommer inn en e-post til et prosjekt som har automatisk svar på. Tomt felt deaktiverer automatisk svar. Feltet sier om prosjektet skal inkluderes i den daglige kjøringen av kodekontroll. 0 for av, alt annet for på. Inneholder siste revisjon som det ble kjørt kodekontroll på. Beskrivelse Dersom feltet ikke er tomt, så er det en support ticket. Feltet inneholder e-postadressen til den som sendte inn support ticketen. Beskrivelse _invoice invoices I denne tabellen har vi lagt til en attributt: Kolonne Aktiverer eller deaktiverer e-post av faktura. Beskrivelse _invoice Feltet bestemmer hvorvidt akkurat denne fakturaen skal sendes eller ikke. 27 av 96

28 5.2 Arkitektur Bildet under gir en oversikt over hvordan systemet er bygget opp. Fig 7 Flyten i systemet. Fig 8 Oppbyggingen av AFW 6. Design Her vil vi prøve å gi en oversikt over hvordan vi har tenkt i forhold til design Grafikk og fargebruk Dette prosjektet har både vokst, men samtididig lidd under å være en utvikling av et allerede eksisterende produkt. Det har ikke vært vår oppgave å endre design eller komme med input på designsiden. Vi har derfor måttet holde oss til Aptopappas allerde utviklede design. Dette har vært enkel, da Aptopappa har en godt strukturert CSS som er skilt fra resten av koden. Det har derfor bare vært å putte våre nye funskjoner inne i riktig div og riktig klasse sånn at det fungerer sammen med resten av applikasjonen. 28 av 96