Håkon Drange Lars Johannes Fjeldså Hetland

Transkript

1 Håkon Drange Lars Johannes Fjeldså Hetland Høytpresterende statistikksystem for web Hovedprosjekt i data ved Høgskolen i Oslo Våren 2007 Gruppe 25

2

3 PROSJEKT NR Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET Lukket Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Dr.Klikk DATO 23.mai 2007 ANTALL SIDER / BILAG 129 PROSJEKTDELTAKERE Håkon Drange s Lars Johannes Fjeldså Hetland s INTERN VEILEDER Simen Hagen OPPDRAGSGIVER Aptoma AS KONTAKTPERSON Daglig leder Geir Berset SAMMENDRAG Prosjektoppgaven har gått ut på å konstruere et generelt statistikkaggregeringssystem for Aptoma AS. Målet med oppgaven har vært å lage et skalerbart system med ekstrem toleranse for trafikkitensitet. Det skal samles inn statistikker i sammenheng med nettsider, samtidig som det har funksjonalitet for å telle klikk på eksempelvis annonser, artikler, menyer osv. Dr.Klikk er designet for å være så rask at det kan bli brukt overalt hvor statistikk skal samles, og presenterer resultatet i et oversiktlig web-grensesnitt med aktuelle tall og grafer. Applikasjonen er utviklet ved hjelp av PHP versjon 5, MySQL versjon 5, HTML, CSS og Javascript. Det har vært et svært spennende prosjekt hvor vi har lagt ned mye arbeid. Vi har lært en god del om utvikling i store prosjekter og vi er meget fornøyde med resultatet. 3 STIKKORD Statistikk Effektivitet Web-applikasjon

4

5 Forord Dette dokumentet beskriver gruppens arbeid, metoder, analyser og det ferdige produktet for hovedprosjekt ved Høgskolen i Oslo, Avdelingen for Ingeniørutdanning våren Gruppens medlemmer er Håkon Drange og Lars Hetland. Vi kontaktet Geir Berset i Aptoma i oktober 2006 etter å ha sett oversikten over tilgjengelige prosjekter på Ingeniørutdanningens hjemmesider. Etter to møter og litt betenkningstid ble vi tildelt oppgaven. Hensikten med vår oppgave har vært å konstruere et høytpresterende statistikkaggregeringssystem med kapasitet til å motta store mengder statistikkdata og raskt generere enkle rapporter. I perioden har vi lært mye om hvordan prosjektplanlegging- og gjennomføring fungerer i praksis. Tiden hos Aptoma AS har også gitt oss verdifull innsikt i hvordan arbeid og utvikling kan foregå i næringslivet. Vi ønsker å takke oppdragsgiver og medarbeiderne i Aptoma for all den hjelp vi har fått og en meget lærerik prosjektperiode. Takk til veileder Simen Hagen for nyttige innspill om prosjektplanlegging og takk til VG for gratis kaffe. Rapporten er optimalisert for papir. Nedlastbar PDF-versjon er tilgjengelig på gruppens prosjektside på Internett. Oslo, den 23.mai 2007 Håkon Drange, Lars Johannes Fjeldså Hetland

6

7 Innholdsliste 1 Om oppgaven og planlegging 2 Utviklingsprosessen 3 Kravspesifikasjon 4 Oppsummering Vedlegg 1 Vedlegg 2 Produktdokumentasjon Brukermanualer

8

9 dr.klikk 1. Om oppgaven og planlegging

10

11 Innholdsfortegnelse Generelt om oppgaven og planleggingen...2 Om bedriften...2 Dagens situasjon...2 Gruppen...2 Oppgaven...3 Planleggingsprosessen...4 Utviklingsmodellen...4 Fremdriftsplan og arbeidsplan...5 Hvordan gikk planleggingen i praksis?...5 Hvorfor måtte registreringsmodulen redesignes?...5 Databasestruktur...6 Verktøy og programvare...7 Enterprise Architect Eclipse med PHP Development Tools...8 Apache webserver...9 PHP Hypertext PreProcessor...9 MySQL...9 PHPMyAdmin Subversion Streber Memcached Implementering Design Kjennetegn for en AFW modul... 14

12 Planlegging 1

13 Planlegging Generelt om oppgaven og planleggingen Om bedriften Aptoma er en leverandør av internettapplikasjoner som jobber tett sammen med landets største nettaviser innen alt fra video- og informasjonspublisering til innovative communitytjenester. - Aptoma.no Firmaet holder til i VG-bygget i Akersgaten og har syv ansatte. Vår kontaktperson var daglig leder Geir Berset. Dagens situasjon Per dags dato eksisterer det allerede et statistikksystem på VG.no, men med begrenset funksjonalitet og et nytt og lettere utvidbart system er ønsket. Det nye systemet skulle kunne utvides til å motta data fra for eksempel flashobjekter og inkluderte videoobjekter som allerede finnes på målsiden. Gruppen Gruppesammensetningen ble tidlig dannet, og på bakgrunn av tidligere gruppesamarbeid kjente gruppemedlemmene hverandre og var klar over den enkeltes kompetanse. Dette gjorde det lettere å delegere arbeidsoppgaver enn å måtte kartlegge og tilegne seg kunnskap underveis. 2

14 Planlegging Oppgaven Denne hovedprosjektoppgaven ble dannet på bakgrunn av en enkel prototype som ble utviklet sommeren Aptoma ønsket å videreutvikle denne prototypen til et spesialdesignet produkt for bruk i miljøer med ekstrem last. Viktige momenter vi har måttet ta hensyn til er høytpresterende programkode for best mulig ytelse, effektivt design på relasjonsdatabasen og minimalt båndbreddebruk fra og til server. Vårt hovedfokus var å konstruere en effektiv registreringsmodul, deretter rapporttypene. Underveis har vi hatt ukentlige møter med Geir hvor vi har diskutert fremgangen. Hva vi gjorde i uken som gikk, hvor vi var for øyeblikket, og hva som skulle jobbes med til neste møte. Mot slutten av prosessen hadde vi kontakt to eller flere ganger i uken. Dette hjalp oss veldig med å få rett fokus og få unnagjort de oppgavene som gjensto. Vi arbeidet mest hjemme, men før og etter de ukentlige møtene arbeidet vi hos Aptoma, hvor vi kunne stille mer tekniske spørsmål til de andre ansatte dersom det var noe vi lurte på om programmeringen generelt, AFW eller hva det skulle være. 3

15 Planlegging Planleggingsprosessen Først snakket vi med Berset og Johan Telstad, teknisk ansvarlig i Kroma A/S, en annen bedrift som utfører arbeid for VG Nett, for å kartlegge ønsker og behov. Johan kom med mange gode fremtidige tanker og idéer for Dr.Klikk, men vi måtte konsentrere oss om det viktigste. Brukere fra VG Nett hadde også fremmet ønsker som vi hadde i bakhodet underveis og prøvde å tilrettelegge for. Oppdragsgiver hadde en ganske åpen kravspesifikasjon, men applikasjonens formål og egenskaper var nøye definert. Vi fikk en Use-case modell av prototypen som vi arbeidet mot og utbedret etter hvert som finjusteringer ble gjort underveis. Relativt tidlig ble det også klart at det ikke ville bli tid til å implementere brukerroller og rapporttyper på brukernivå, og vi valgte da i samråd med oppdragsgiver å konsentrere oss om konstruksjon av de viktigste rapporttypene. Utviklingsmodellen Metoden og rekkefølgen på arbeidet var ganske forutbestemt, og vi fant ut at det var best å arbeide etter hovedpunktene i en iterativ utviklingsmodell med inkrementell levering. Hovedprinsippet bak denne modellen er å levere programvare flere ganger. For hver leveranse blir det lagt til mer funksjonalitet eller endringer og vedlikehold i eksisterende versjon, vanligvis de viktigste funksjonalitetene først. Hver leveranse er komplett og klar til bruk. En av fordelene er at viktigst funksjonalitet blir levert først, som minsker risiko for at prosjektet skal feile og ingenting bli levert. 4

16 Planlegging Fremdriftsplan og arbeidsplan Fremdriftsplan og arbeidsplan ble utarbeidet i planleggingsfasen. Vi diskuterte denne med Geir, og sammen kom vi frem til en fornuftig og realistisk fremgang. Planene ble fulgt slavisk over halvveis i prosjektet men måtte justeres mot slutten av perioden. Vi registrerte at redesign av registreringsmodulen tok lenger tid enn vi hadde forutsett pga momenter som dukket opp underveis, og dette måtte da gå på bekostning av statistikkrapportene og brukermodulene. Her måtte vi velge bort funksjoner som var påtenkt i begynnelsen. Hvordan gikk planleggingen i praksis? Da vi startet prosjektet mente vi at vi hadde ganske god kontroll på planlegging og fremdriftsplan. Utviklingen startet bra og vi holdt oss til fremdriftsplanen over første halvdel av prosjektet, men problemstillinger ikke tatt opp tidligere, verken i hovedprosjektplanleggingen eller prototypdesignet, dukket opp og gjorde at den originale planen måtte endres. Den største endringen ble gjort med registreringsmodulen som måtte redesignes tre ganger før den opererte tilfredsstillende. Hvorfor måtte registreringsmodulen redesignes? Tidlig i prosjektet var registrering av linkklikk førsteprioritet, men senere ble Javascript-callback på sidevisninger satt som hovedprioritet for registrering. Vi fikk et tips om at vi kunne bruke Javascript til å overvåke hendelser som klikk på linker, men på grunn av forskjellig oppførsel i forskjellige nettlesere er ferdigstilling av klikkovervåking utsatt til senere. Grunnen til at Javascript er valgt er basert på hensyn til søkemotoroptimalisering. Mer om dette er beskrevet under punktet utfordinger i del 3 - utviklingsprosessen. 5

17 Planlegging Databasestruktur Vi startet med utgangspunktet på den strukturen som var definert i den initiale prototypen. Etter hvert som registreringsmodulen underveis ble endret ble det også klart at vi måtte endre strukturen på noen databasetabeller. I samme gjennomgang av prototypens databasedesign ble også flere overflødige datafelt fjernet. Vi valgte å gjøre mest mulig datatrunkering i registreringsprosessen fremfor å måtte utføre omfattende utregninger i rapportgenereringsprosessen. Dette for å minimere tiden det vil ta å generere og vise en rapport. 6

18 Planlegging Verktøy og programvare Vi valgte å bruke følgende verktøy basert på hva vi har erfaring med selv fra tidligere, samt råd fra ansatte i Aptoma. Enterprise Architect 6.0 For dokumentasjon og design av UML-diagrammer. Denne applikasjonen kan også generere programkode fra modellene. Figur pl-01. Enterprise Architect 7

19 Planlegging Eclipse med PHP Development Tools Eclipse er en fri og såkalt åpen-kildekode-applikasjon programmert i Java hvor ingen lisensavgift kreves. Dette programmet er et utviklingsmiljø opprinnelig designet for å skrive Java-kode, men sammen med Eclipseutvidelsen PHP Development Tools brukte vi applikasjonen til skriving av PHP-kode. Eclipse har mange nyttige fordeler over en ordinær tekst-editor som definering av prosjekt, syntax high-lighting, auto-kodefullføring, kodegjemmer og mer. En annen fordel er at den ikke trenger noen installasjon fordi den er skrevet i Java. Figur pl-02. Eclipse 8

20 Planlegging Apache webserver En veldig populær fri og åpen kildekode HTTP-servertjeneste for de fleste operativsystemer. Vi brukte versjon sammen med PHP versjon Figur pl-03. Apache HTTP server PHP: Hypertext Preprocessor Et serverside skriptingsspråk for konstruering av dynamiske websider, gjerne sammen med en relasjonsdatabase. PHP fungerer på mange plattformer sammen med en HTTP-server. Figur pl-04. PHP MySQL En fri og åpen kildekode relasjonsdatabase. Lett og effektiv på enkle spørringer med mange konfigurasjonsmuligheter. Versjonen brukt var Figur pl-05. MySQL 9

21 Planlegging PHPMyAdmin En fri og åpen kildekode applikasjon for administrering av relasjonsdatabasen MySQL programmert i PHP. Den kjøres på en HTTPserver og oppfører seg som en web-side, applikasjonen trenger ikke installeres på klientsiden. Versjonen brukt var Figur pl-06. PHPMyAdmin Subversion Nok et produkt med åpen kildekode. Blir brukt til versjon/revisjonskontroll av dokumenter og programkode. Bygger på grunntankene om Concurrent Version System (CVS) med utfyllende funksjonalitet. Heretter forkortet til SVN. Figur pl-06. Subversion 10

22 Planlegging Streber Prosjektstyringsverktøy. Her kan man legge inn prosjektbeskrivelse, delegere ansvarsområder, legge inn oppgaver, notater og funksjoner som er nødvendig å definere i et utviklingsprosjekt. Figur pl-07. Streber 11

23 Planlegging Memcached Et cache (mellomlager) hvor man kan mellomlagre data i systemminnet (RAM). En egen servertjeneste kjøres selvstendig og klienter eksisterer til de fleste programmeringsspråk. Vi brukte to klienter for PHP, først en skrevet i PHP og senere en offisiell PHP PECL-modul skrevet i C++. Sistnevnte viste seg å være mye mer effektiv og mindre ressurskrevende. I DrKlikk brukes C++-modulen om tilgjengelig, og faller ellers tilbake på PHP-klienten i AFW. Figur pl-08. Memcached 12

24 Planlegging VG Nett og Listefeber Prototyper av Dr.Klikk har i utviklingsperioden vært satt i produksjon på Listefeber ( ), en av VG Netts mest besøkte tjenester. Her kan du legge til din egen toppliste som andre kan bruke til stemme frem sin favoritt. Hvem som helst kan avgi stemmer på alle listene. I mai 2007 ble VG Nett tildelt den prestisjetunge prisen Årets beste nasjonale nyhetsnettsted. Listefeber ble også tildelt en sølvmedalje. (Ref: Implementering Vi utviklet lokalt på våre egne datamaskiner hvor Apache, PHP og MySQL ble kjørt lokalt. Etter at funksjonalitet var ferdigkodet ble endringene lastet opp til SVN-serveren, og når en ny versjon var klar for å settes i produksjon lastet Torfinn ned den nye revisjonen direkte til Listefeber-serveren fra SVN. Design Dr.Klikk kan bli sett på som en selvstendig modul i bruk sammen med AFW. Vi baserte oss derfor på Aptomas designstandard som brukt i AFW. Her benyttes Model View Controller (MVC) prinsippet hvor en skiller applikasjonens struktur i forskjellige deler. Oppgavedelegering og styring skjer i Controller, databehandling og prosessering skjer i Modell og grensesnitt defineres i View. Aptoma har utformet egne dokumenter som spesifiserer hva som kreves av en såkalt AFW-modul. En kort forklaring på en modul er en mappe som ligger på samme nivå som AFW i et fil-tre. 13

25 Planlegging Her følger et utdrag av de viktigste punktene fra dokumentet Aptoma Module Requirements. Definisjonene er skrevet på engelsk, og vi velger å beholde overskriftene på dette språket for korrekt fokus på temaet. Kjennetegn for en AFW modul En AFW-modul skal i henhold til Aptomas spesifikasjoner være: Self contained En modul skal ikke være avhengig av noe utenfor sitt eget erklæringsfelt. Den referer ikke til konfigurasjonsfiler som ikke ligger i ens underkataloger. Alle linker og referanser er relative slik at modulen kan flyttes uten at fil- og link-stier brytes. Self contained, also in repository En modul skal ikke være avhengig av noe annet i lagringsområdet til kildekodehåndteringssystemet. Dersom en modul skal bli brukt flere steder bør den aktuelle revisjonen eksporteres fra sitt eget lagringsområde, for så å bli lagt til i det aktuelle prosjektets eget lagringsområde. Self contained, in relativity Ingen hardkodede selv-referanser sørger for at modulens navn kan endres uten å omskrive kode. Self caching Modulen skal mellomlagre seg selv, eller benytte seg av egne mellomlagringssystemer som et eget Memcached område. 14

26 Planlegging Semantic and consistent Nomenclature Følg logiske og standardiserte navnekonvensjoner. Self documented Modulens dokumentasjon kan nåes fra, eller eksisterer innenfor seg selv. Dokumenter kodens formål, ikke hvordan operasjonen gjøres. Self explaining GUI Dersom det I et grensesnitt er mulig for brukeren å gjøre en feil eller bli forvirret, bør det eksistere en kort forklaring, eller link til en forklaring. Secure Alle data som skal behandles må valideres. Separation of concerns MVC-standarden skal følges slik som demonstrert i AFW. Error silent Når en modul er i produksjon skal brukeren ikke eksponeres for systemfeilmeldinger eller andre feil som ikke er tiltenkt brukeren. 15

27 Planlegging 16

28 Planlegging 17

29 Dr.klikk 2. Utviklingsprosessen

30

31 Innholdsfortegnelse Utviklingsprosessen...2 Planleggingsfasen...2 Forprosjekt...2 Kompetansetilegning...2 Programmeringsfasen...5 Fremdrift...5 Faglige utfordringer...6 Utvikling underveis...7 Testing av registreringsmodul...7 Testing av brukergrensesnitt...8 Dokumentasjon...9 Samarbeid og erfaringer med veileder...9 Samarbeid og erfaringer med oppdragsgiver Utfordringer i prosjektgjennomføringen Å designe et effektiv system Hvordan registrere klikk på en effektiv måte Hvordan huske at en bruker har besøkt en side tidligere Registrering av sidetitler Uforskyldte problemer og løsninger på disse Ønsker gruppen og oppdragsgiver hadde, men ikke rakk Brukergrupper Innlogging Aktuelle funksjoner for fremtidig implementasjon Kvaliteten på prosjektet Teknologi Fleksibilitet Sikkerhetsvurderinger Validering av innkommende data ved registrering Validering av innkommende data ved rapportgenerering Innlogging Filtilgang Tung prosessering ved rapport- og grafgenerering Aptoma sikkerhetskrav... 22

32 Utviklingsprosessen 1

33 Utviklingsprosessen Utviklingsprosessen Planleggingsfasen Planleggingsfasen ble unnagjort i løpet av januar. Mot slutten av fasen startet vi programmeringen. Forprosjekt Vi startet med prosjektskissen og forprosjektet hvor vi satte oss inn i oppgaven og studerte aktuelle muligheter. Etter at behov og krav var kartlagt definerte vi en kravspesifikasjon, og på basis av denne designet vi systemets struktur og hvordan utviklingsprosessen skulle styres. Det ble også produsert en detaljert fremdriftsplan som har vist seg å vært et meget bra styringsdokument for tidsbruk. Kompetansetilegning Vi var originalt relativt godt forberedt til en oppgave som dette fra prosjektog programmeringsoppgaver fra kurs på Høgskolen. Selv om det meste av programmeringen og prosjektutviklingen på HiO har vært Java-orientert gikk overgangen til PHP smertefritt. Håkon har også tidligere arbeidet en del med PHP som hjalp i utviklingen. Lars som hadde mindre PHP-erfaring brukte tid i juleferien på lesing i boka Professional PHP Programming for å være klar til prosjektstart i januar. Mange utvikler PHP-applikasjoner i versjon 4 eller eldre. Denne begrenset støtte for objektorientering og det er heller ikke mange som utvikler på denne måten i PHP. Grunnet måten AFW fungerer på var det logisk for oss å utvikle objektorientert i PHP-versjon 5. For å komme i gang måtte vi sette oss inn i Aptoma FrameWork (AFW) og hvordan prosessflyten fungerte der. Det gav oss god innsikt i fornuftige Modell View Controller-prinsipper (MVC) som vi har jobbet med før, da i 2

34 Utviklingsprosessen form av Java Server Faces. Det tar noe tid og arbeid før en blir kjent med dette prinsippet og måten å arbeide på, noe vi mener vi har klart bra. Aptomas andre applikasjoner og produkter er bygget på AFW og følger samme ideologiske programstruktur. De ønsker å designe frittstående moduler som kan implementeres i andre applikasjoner på en enkel og effektiv måte. Vi har tilegnet oss god kunnskap om denne måten å utvikle på gjennom samtaler med de ansatte. Gruppen har også deltatt på oppsummeringsmøter på fredager hvor det blir gjennomgått temaer om hva som har blitt gjort, erfaringer og hva som er målet for neste uke. Vi har også lært mye mer om PHP. Blant annet best-practices i programmeringsrutiner, algoritmer, PHPs funksjoner og bruk av cachingsystemet Memcache. MySQL har vi brukt før, både i privat- og skolesammenheng. PHPMyAdmin er et lett og oversiktlig verktøy for å administrere denne relasjonsdatabasen. Begge har vært så vidt borti Javascript tidligere. Det skulle vise seg at vi kom til å konstruere avanserte Javascript for registreringsmodulen, opptil flere ganger. Her ble det en del nye funksjoner å sette seg inn i, men det meste gikk greit når vi fikk kontrollen på programmeringssyntaksen. For å kunne designe et system som leverer de tallene og funksjonene som spesifisert var det påkrevd at vi måtte sette oss inn i noen statistikkbegreper som er brukt på Internett. Vi måtte finne ut hvilke tall som skulle bli brukt, hvordan disse regnes ut og hva som kreves av data for at dette skal kunne muliggjøres. 3

35 Utviklingsprosessen Noen eksempler Page Impressions (Forkortet PI) Antall sidevisninger over en tidsperiode Unique Visitors (Forkortet UV) Antall unike brukere som har besøkt en side i løpet av en tidsperiode, i vårt tilfelle i løpet av det siste døgnet. User Sessions (Forkortet US) Antall brukersesjoner som har besøkt en side i løpet av en tidsperiode. I vårt tilfelle er en brukersesjon definert til å vare 30 minutter. Om brukeren besøker samme side senere på dagen teller dette som en ny brukersesjon. Til å holde kontroll på kildekode brukte vi revisjonskontrollsystemet Subversion. Fra tidligere har vi brukt CVS så selve prinsippet ved versjonssystemer var kjent, og det var bare SVNs syntaks som måtte læres. 4

36 Utviklingsprosessen Programmeringsfasen Fremdrift Med styringsdokumenter som kravspesifikasjon og fremdriftsplan klare startet vi programmeringsfasen. Vi konstruerte først registreringsmodulen, da det var mest hensiktsmessig å observere realistiske data før vi utviklet rapportmodulen. Da registreringen var klar ble den satt i produksjon på Listefeber. Med data tikkende inn kvalitetstestet vi oppførselen og fikk tilbakemeldinger fra oppdragsgiver Geir og andre medarbeidere i Aptoma parallelt med utviklingen av rapportene. Vi ble på den måten lettere bevisste på justeringer nødvendig i registreringsprosessen og utbedret dette underveis. Vi arbeidet på samme måte ved utvikling av rapportene. De to viktigste funksjonene var en temperaturmåler som skulle vise mest leste saker i løpet av siste minutt eller annet valgt intervall, og en periodestatistikk med mulighet for å velge et fritt intervall fra femten minutter og utover til flere måneder. Vi startet med å designe et enkelt brukergrensesnitt med en datovelger for definering av ønsket intervall. Statistikktall som PI, UV og US ble regnet ut og små trendgrafer (Sparklines) ble satt inn. Etter hvert som rapportfunksjonene ble lansert diskuterte vi funksjonaliteten med oppdragsgiver. Han kom med gode tilbakemeldinger på grensesnittet, brukervennlighet og aktuelle funksjoner som skulle implementeres nå, og flere som kunne implementeres på et senere tidspunkt. 5

37 Utviklingsprosessen Faglige utfordringer Måten vi programmerte på har involvert både objektorientering og en mer sekvensiell skriptbasert stil. Vi måtte ta hensyn til effektivitet i registreringsprosessen og valgte derfor å designe den så enkel som mulig uten å inkludere AFW rammeverket, da det tar en del tid og ressurser å laste inn dette for hver registrering. Prosessen for registrering av klikk og sidevisninger består av to hovedsekvenser. Når en side lastes sendes det en forespørsel til Dr.Klikk via Javascript. Dette datapunktet blir mellomlagret i systemminnet ved hjelp av Memcached. Denne prosessen utføres for hvert statistikkpunkt innsamlet av Dr.Klikk, og siden systemet skulle ha kapasitet til å registrere flere hundre slike i sekundet fant vi raskt ut at det relativt tunge AFW-rammeverket ikke kunne inkluderes i denne prosessen. Tidlig testing i form av benchmarking viste at Dr.Klikk var i stand til å prosessere omtrent ti ganger så mange forespørsler uten AFW. Den andre hovedsekvensen er at hvert minutt startes en prosess som går gjennom alle datapunkter lagret i Memcached og setter disse inn i databasen. Her er AFW inkludert da hyppigheten det utføres i er mye lavere, og kravet til toppytelse ikke er like kritisk. Vi har også benyttet ferdig funksjonalitet i AFW som gjorde det raskere og lettere å utføre denne prosesseringen. Gruppen hadde en del kunnskap om objektorientert utvikling fra Javakursene på skolen. Det er små syntaksforskjeller mellom Java og PHP i denne programmeringsmåten som har vist seg å være meget nyttig. Logisk tankegang og eksempler fra AFW har hjulpet oss godt på vei. 6

38 Utviklingsprosessen Utvikling underveis Utviklingen av prosjektomfanget har endret seg noe underveis. I startfasen var det planlagt å bruke to databaser, en for lagring av data på minuttnivå og en database for større datamengder. Dette gikk vi bort fra da vi så at bruk av kun en database var effektivt nok. Det var også originalt planlagt å registrere fysiske klikk på linker, prosessere disse i Dr.Klikk for så å videresende brukeren til den ønskede websiden. Denne registreringsmåten bruker den statistikkløsningen VG Nett har i dag. Underveis ble det diskutert en del funksjonalitet med Aptoma ansatt Vilhelm K. Vardøy som foreslo å registrere klikk ved hjelp av en Javascript hendelse i stedet for den tradisjonelle måten. Dette krevde bruk av Javascript-rammeverket Prototype som oppførte seg litt annerledes i forskjellige nettlesere. Fullføring av metodene som registrer klikk ble derfor utsatt til senere implementering og vi konsentrerte oss om å registrere statistikk med Javascript ved sidelasting. Testing av registreringsmodul Vårt viktigste fokus har vært effektiviteten i registreringsprosessen. Rapportgrensesnittene kan være nyskapende og flotte, men det hjelper ikke om systemet ikke klarer å prosessere den innkommende datamengden. Til ytelsestesting av systemet har vi benyttet Apache Benchmark som kommer med standardinstallasjonen av Apache HTTP-server. Dette testverktøyet sender av gårde forespørsler til en HTTP-server og måler responstid, antall forespørsler serveren klarer å prosessere i sekundet med mer. En kan velge både totalt antall som skal sendes og antall samtidige forespørsler. Under utviklingen benchmarket vi Dr.Klikk etter hvert som nye versjoner ble lansert. Dr.Klikk ble installert på samme server som Listefeber og ble senere flyttet til en nyere server. 7

39 Utviklingsprosessen Vi hadde et mål om å oppnå prosessering av 500 forespørsler i sekundet. Resultatet av testingen på den første serveren i mars ble 496 forespørsler, som kan anses som godkjent. Etter dette endret vi registreringsmodulen til å foreta noen flere utregninger under registreringsprosessen som førte til at den ble litt mer ressurskrevende. Da den nye versjonen var klar i tidlig mai ble Dr.Klikk implementert på den nye Listefeber-serveren, som har kraftigere hardware og vi forventet at testingen skulle føre til et noe høyere tall. Resultatet ble at Dr.Klikk klarte å ta unna nesten 3500 registreringer i sekundet, noe som er sju ganger mer enn det opprinnelige målet. Listefeber krever en del av ressurser, så om Dr.Klikk hadde blitt kjørt på en dedikert servermaskin hadde nok resultatet blitt enda bedre igjen. Listene med ukestatistikk på forteller at VG Nett som Norges største nettside i uke hadde omtrent 230 millioner sidevisninger som gir et gjennomsnitt på omtrent 400 sidevisninger i sekundet. Det betyr at selv ved ujevn last i løpet av døgnet vil en moderne server med Dr.Klikk relativt lett behandle denne høye dataflyten. Det siste resultatet viste at utbedringene vi hadde gjennomført underveis var vellykkede. Noe av æren må serverens hardware stå for, men det ble bevist at Dr.Klikk fungerer enda mer effektivt enn planlagt. Testing av brukergrensesnitt I begynnelsen av prosjektet fikk vi skjermbilder av VGs eksisterende statistikkløsning. De ønsket å få presentert de samme tallene, så våre rapporter er basert på samme grunnoppsett. Brukertesting av grensesnitt har blitt utført av Geir, som også som skal benytte seg av det ferdige systemet. Han har underveis kommet med innspill og forslag til forbedringer. 8

40 Utviklingsprosessen Dokumentasjon Forprosjektrapporten var en naturlig start på prosjektet. Underveis har vi ført prosjektdagbok ukentlig og ved andre ellers store anledninger. På møtene med oppdragsgiver førte vi notater som ble benyttet i prosjektdagboken. Vi avsluttet programmeringsfasen i midten av mai og startet da produksjon av sluttdokumentasjonen. Dokumentasjonsstandarden for hovedprosjekter forfattet av Ann-Mari Torvatn la grunnlaget for rapportens struktur. Det ble satt opp en disposisjon over hva som skulle inkluderes for å få en oversikt over punkter vi kunne resonnere over. Forskjellige deler av dokumentasjonen ble delegert mellom gruppemedlemmene og gjennomgått i fellesskap etterpå. Selv om vi hadde tatt høyde for at dokumentasjonsprosessen kom til å være krevende viste det seg at vi likevel hadde mye arbeid å gjøre den siste tiden. Samarbeid og erfaringer med veileder Vi har hatt faste møtetidspunkter med veileder Simen Hagen annenhver uke. På disse møtene som har vart i rundt en time ble det diskutert hva som var gjort og hva som skulle gjøres til neste gang. Simen har vært meget behjelpelig med konstruktive tips og råd til forskjellige arbeidsoppgaver, alt fra strukturerte arbeidsmetoder til valg av utviklings- og dokumentasjonsprogramvare. For vår del har det vært nyttig å ha disse møtene for å lettere synliggjøre prosjektets status. Samtidig var det viktig å ikke ha for mange av dem for å unngå at arbeidsflyten stoppet opp. Etter vår erfaring var et intervall på to uker fornuftig. 9

41 Utviklingsprosessen Samarbeid og erfaringer med oppdragsgiver Oppdragsgiver Geir Berset fra Aptoma har vært meget imøtekommende og hjelpsom. Da vi ble tilbudt og aksepterte prosjektoppgaven i november fikk vi også utlevert en utgave av AFW og en AFW-basert blog for å studere frem til prosjektstart. Fra januar har vi hatt et fast ukentlig møte hos Aptoma. Her kunne vi stille prosjektrelaterte spørsmål til Geir. Mer tekniske vurderinger ble og diskutert mellom oss, Geir, Vilhelm og Torfinn Berset, hvor de to siste er medarbeidere i Aptoma. Underveis har vi demonstrert funksjonalitet etter hvert som deler har blitt ferdige. Vi har fått tilbakemeldinger verbalt og via e-post på hva som var bra og mindre bra og utbedret dette til neste møte. Dersom det var en uke hvor det ikke var behov for eller det ikke passet med et møte sendte vi en fredagsoppsummering pr e-post hvor vi forklarte hva vi hadde gjort og hva som var planene for neste uke. Oppdragsgiver eller andre medarbeidere har alltid vært til disposisjon når nødvendig og i perioder har vi hatt flere ukentlige møter. Etter hvert ble disse møtene mer uformelle og vi kunne møte opp på kontoret uanmeldt, sette oss ned og arbeide. Vi hatt kontakt med oppdragsgiver og andre medarbeidere via e-post om det var noe som var uklart eller noe vi ønsket svar på. 10

42 Utviklingsprosessen Utfordringer i prosjektgjennomføringen Å designe et effektiv system Vår kanskje største utfordring var å faktisk konstruere et system som kunne operere tilfredsstillende under ekstrem last. Vårt initiale mål var at Dr.Klikk skulle takle opp til 500 registreringer i sekundet, prosessere disse og generere visning av statistikkdata på minuttintervall. Vi brukte god tid på å planlegge en databasestruktur som vi trodde var effektiv, men som viste seg at måtte forkastes flere ganger. Det var først når registreringsmodulen ble satt i produksjon det gikk opp for oss og oppdragsgiver at funksjonaliteten ikke var optimal. I de første versjonene av Dr.Klikk lagret vi mest mulig data i databasen. Brukerinformasjon, cookieidentifikator og datapunktinformasjon ble alle lagret for hvert datapunkt med intensjoner om å generere rapporter for visning av disse. Dette viste seg å kreve både mye mer prosesseringstid og lagringskapasitet enn nødvendig og fordi de enkle rapportene vi bestemte oss for å lage ikke inkluderte mange av disse tallene ble deres registrering fjernet. Etter noen perioder med testing og utbedring kom vi frem til en effektiv løsning på registreringsmodulen. Den endte opp med å prosessere over 3500 behandlinger i sekundet, som var over all forventning. 11

43 Utviklingsprosessen Hvordan registrere klikk på en effektiv måte Et mål for Dr.Klikk var også at registrering av linkklikk skulle være så enkelt og intuitivt for både utvidere av Dr.Klikk og webmastere som skal designe sider hvor systemet skal brukes. Vår første og enkleste løsning var at hver link pekte til Dr.Klikk med data i GET-parametre (sendt over adresselinjen i nettleseren). En slik løsning gir lite brukervennlig kode, et system som er avhengig av at Dr.Klikk vil ikke fungere optimalt når søkemotorer leser siden: /drklikk/?do=registerclick&rurl=side2.html&tag=panowie Videre var det tenkt å lage et system som bruker Apache-webservers mod_rewrite for et lettere lesbart system som fortsatt ikke vil fungere optimalt for søkemotorer. Dette er samme metode som er i bruk på VG.no i dag: /drklikk/panowie/side2.html Den tredje løsningen uttenkt var å konstruere et Javascript som overvåker klikkhendelser på siden og omstyrer stien brukers nettleser laster ned. Dette krever ingen endring av linker på nettsiden hvor Dr.Klikk skal inkluderes og vil fungere helt optimalt i samsvar med søkemotorer. I den innleverte versjonen av Dr.Klikk er denne funksjonaliteten fortsatt i testversjon som ikke virker i alle nettlesere: side.2.html ->JS-> /drklikk/?do=registerclick&rurl=side2.html 12

44 Utviklingsprosessen Hvordan huske at en bruker har besøkt en side tidligere For å kunne få korrekt UV, unique visitors eller unike brukere, må systemet på en måte vite hvem som tidligere har besøkt en side. Den klassiske måten å huske dette er å opprette en unik ID som lagres hos bruker i en cookie som sendes til server ved et sidekall og der lagre dette samt besøksdata i databasen. Da dette i vårt system ville bety en stor økning i lagret data samt at hvert datapunkt måtte blitt sammenlignet med registrerte brukerdata var ikke dette aktuelt. Etter en diskusjon med Vilhelm i Aptoma kom vi frem til at et Javascriptsystem som hos bruker lagrer alle besøkte sider, ville være det beste til dette. Et slikt system flytter mye utregning til klientsiden og gjør at Dr.Klikk ikke behøver å lagre noe data om bruker. Et over 300-linjer langt Javascript ble så skrevet med denne funksjonaliteten som lagret alle besøkte nettadresser, tid for besøk og Dr.Klikk-tags i et JSON-array (datalagring i en tekstbasert tabellstruktur) i en cookie. Dessverre ble vi etter et par uker senere opplyst om at en nettlesere sender alle cookies lagret for en domenesti hver gang et kall til det domenet blir gjort. Normalt vil ikke dette være et stort problem, men da nettsidene på Listefeber gjerne har elementer som hver krever ett HTTP-request og Dr.Klikk hadde potensiale til å lagre flere kilobyte ville det bety at bruker måtte potensielt laste opp over en megabyte for hver sidevisning. Etter en ny tenkeprosess i samarbeid med Vilhelm kom vi frem til at den beste løsningen ville være å hos bruker lagre en unik bruker-id i en cookie, og på basis av den, den besøkte sidens URL og Dr.Klikk-tag lage en MD5-hash (kryptografisk enveisfunksjon som genererer en tekststreng basert på inndata) som sendes over til Dr.Klikk. I registreringsmetoden til Dr.Klikk blir så denne situasjonsbeskrivende verdien lagret i Memcached i systemminne sammen med et tidsstempel for registreringen. Denne informasjonen eksisterer i Memcached helt til en ny tidsperiode starter, i vårt system ved overgang til nytt døgn. Fordi hver innkommende hash vil beskrive både bruker, URL og Dr.Klikk-tag er å sjekke om innkommende hash allerede finnes alt vi trenger for å finne ut om bruker har besøkt siden, og når dette eventuelt har skjedd. Denne registreringen øker signifikant Dr.Klikks 13

45 Utviklingsprosessen minnebruk i Memcached, men selv for et ekstremt antall brukere, forskjellige URL-er og Dr.Klikk-tags vil dette holde seg i rimelige størrelser. Registrering av sidetitler Det er påtenkt at rapportene i Dr.Klikk skal kunne vise siders tittel fra HTML-dokumenters <title>-tag, og at en sides registrerte tittel skal oppdateres etter en satt tid er passert siden registreringen. Den naturlige plassen å gjøre dette er i metoden parsedata() som skriver registrerte datapunkter fra Memcached-serveren inn i databasen, men fordi denne operasjonen midlertidig gjør systemet i ustand til å registrere nye data i Memcached er det viktig at den er raskest mulig så ingen nye datapunkter går tapt. Vi ordnet dette ved å i parsedata() kun skrive nyregistrerte siders URL til databasen og opprette en egen metode som henter og skriver tittel til URL-er uten registrert tittel i databasen. Denne metoden blir på samme måte som parsedata() kjørt en gang i minuttet, og pga tidsbegrensinger leser opp til 100 sidetitler for hver eksekvering. Metoden registrerer også et tidsstempel for tidspunktet tittel ble registrert, så oppdatering av systemet til å også oppdatere gamle titler er enkelt. 14

46 Utviklingsprosessen Uforskyldte problemer og løsninger på disse Underveis i prosjektet oppsto det få problemer. Det var stort sett programmeringsutfordringer som vi klarte å løse enten av oss selv eller etter råd fra andre. Ønsker gruppen og oppdragsgiver hadde, men ikke rakk Kravspesifikasjonen var definert på et høyt nivå. Vi sto derfor veldig fritt til å velge hvilke løsninger vi måtte ønske, så lenge de sto i tråd med oppgavens formål. Hovedfokuset har vært å konstruere en effektiv registreringsmodul samt de mest aktuelle rapporttypene. Vi mener vi har kommet i mål med de viktigste funksjonene men i forhold til kravspesifikasjonen er det noe som gjenstår. I samarbeid med oppdragsgiver har vi derfor prioritert å bruke mer tid på å planlegge og designe en effektiv registreringsprosess enn å få implementert mindre viktige ønsker. Brukergrupper I kravspesifikasjonen ble det nevnt at det skal opprettes forskjellige brukergrupper som skal ha forskjellige muligheter. Dette er funksjonene i den originale kravspesifikasjonen det ikke ble tid til å implementere. Editor skulle kunne se rapporter og opprette URL eller webside med statistikktracking. Ad-salesmen skulle kunne opprette URL eller webside med statistikktracking og publisere brukerspesifikk rapport. Ad-customer skulle kunne se sin spesifikke rapport 15

47 Utviklingsprosessen Innlogging Brukergruppene skulle kunne logge seg inn og bli presentert for en administrasjonsside med brukeravhengige valg. Dette er derimot ingen krise for oppdragsgiver da systemet skal videreutvikles på et senere tidspunkt. Vi har allikevel ikke hvilt på laurbærene men fokusert på å produsere et best mulig produkt i forhold til oppdragsgivers forventninger. Aktuelle funksjoner for fremtidig implementasjon Alle tilleggsfunksjoner og ønsker ble oppført og lagret i prosjektstyringsverktøyet Streber. Her er en oversikt over hva som kan implementeres på et senere tidspunkt. Brukerroller Rollesystem for innlogging og eierskap. For visning av brukerens egne tags og rapportobjekter. Datatrunkering av gamle data for optimalisering av rapportgenerering Bruk av Javascript / Ajax for visning av trendgrafer For å unngå ventetid på å prosessere hele rapporten kan tall regnes ut først og deretter trendgrafer vises underveis som de er ferdig prosessert. Fordelen er at brukere slipper å vente på lasting av hele siden, og kan studere tallene med en gang. Visning av URL eller tag I rapport Implementere en velger for å vise URL eller tag i dagsrapporten på samme måte som på mest viste. Måltall Et enkelt grensesnitt for definering og administrasjon av måltall for 16

48 Utviklingsprosessen URL-er og tags. Dette kan være ønskede sidevisninger i løpet av en gitt periode. Grafvisning Legge til dato og tidsvalg I grafvisningen, samt hurtigvalg til forrige og nåværende periode. Visning av klokkeslett og dato på grafer i stedet for kun antall timer eller dager. Filter på URL og sidetitler i rapportvisning For sortering og valg av av objekter. Eksempler: URL er som matcher URL er som matcher do=my-page Sidetitler som inneholder sport Eksportering av rapport til XLS (Excel), XML og PDF format Ekstra informasjon om statistikkdata ved å føre musen over for eksempel PI. Da kan det dukke opp et vindu som sammenligner nåværende tall med tidligere perioder samt hvilken plass på topplisten tallet er på og lignende. Statistikk på brukernivå. Per dags dato lagres ikke brukerens ipadresse eller nettleser, men dette kan lett implementeres sammen med cookieid for å følge hvor brukeren har navigert. Pagetitles cron skal også oppdatere sidetittel på registrerte URL-er av en gitt alder. Systemet må også på en måte kunne huske om sidetittel ikke kunne leses fra URL. Pre-rendre sammenligningsstatistikk 17

49 Utviklingsprosessen Kvaliteten på prosjektet Brukervennlighet Det er lagt vekt på design av enkle og intuitive grensesnitt for lesing av rapportene. Dr.Klikk skal være lett installerbart på en ny serverhost, og inkludering av doktoren på en ny webside skal også være smertefritt. Per dags dato fungerer dette i praksis, men for å forenkle installasjonsprosessen skal det i fremtiden implementeres et automagisk installasjonsscript hvor man i kun ett enkelt grensesnitt trenger å oppgi installasjonsspesifikke verdier. Teknologi De siste versjoner av PHP, MySQL og Memcached er benyttet. Kun de siste versjonene har hatt funksjonaliteten vi har hatt bruk for og de er også oppdatert sikkerhetsmessig. Fleksibilitet Vi har lagt vekt på å designe et så generisk og utvidbart system som mulig. Ved å følge Aptomas standarder for moduldesign kan Dr.Klikk lett utvides til å ta imot data fra andre bruksområder enn de nåværende. Registrering kan komme fra et vilkårlig medium eller objekt som kan generere en HTTPforespørsel. Databasedesignet er åpent for uthenting av spesifikke dataønsker og det kan genereres rapporter på bakgrunn av alle attributter i et datapunkt. Det kan også implementeres brukerroller og eierskapsoversikter for tilpassing rapporter på bruker- og objektnivå. Memcached-systemet som er brukt for mellomlagring av datapunkter i systemminne støtter lesing og skriving over IP-basert kommunikasjon som 18

50 Utviklingsprosessen gjør at mottak, databaseinnsetting og rapportgenerering lett kan deles opp over hver sin fysiske servermaskin. Sikkerhetsvurderinger Validering av innkommende data ved registrering Vi måtte velge en kompromissløsning. Systemet skulle være effektivt, men med for mye sikkerhet ville ytelsen lide. Selve sidevisningsregistreringen sjekker ikke for gyldig inputverdier når data blir mellomlagret i systemminnet. Ved uthenting av data fra systemminnet genereres det en indeksstreng bestående av url, tag og scope_id. Dersom denne eksisterer inkrementeres tellere for PI, UV og US. Dersom kombinasjonen av URL, tag og scope_id ikke eksisterer blir disse verdiene satt inn i databasen. For å sikre oss mot angrep i form av SQL-injeksjon har vi implementert en funksjon som sjekker om variablene som skal settes inn i databasen er gyldige. Hvis de inneholder ugyldige tegn blir de fjernet. Denne heter quote_smart og er hentet fra PHP manualen på SQL-injeksjon går ut på å manipulere innkommende data for å skaffe seg kontroll over, endre eller slette innhold i en database. Grunnet testing av effektivitet er ikke denne funksjonen brukt ved innsetting til databasen, men den ligger klar for bruk i filen ParseData.php. Det er kun en liten del av SQL-setningene som trenger å skrives om og dette må endres før produktet ferdigstilles. 19

51 Utviklingsprosessen Validering av innkommende data ved rapportgenerering For å sikre oss at vi får korrekte verdier når en rapport skal genereres har vi lagt til noen enkle rutiner. Det sjekkes om forventede tall er numeriske og om alle påkrevde variabler er satt. Dersom variabelen ikke er sendt settes den til en standard verdi. Her er det rom for forbedringer i valideringen. Det bør sjekkes om verdiene ikke inneholder spesial- eller ulovlige tegn og at antall tegn eller sifre ikke overstiger de korrekte verdiene. For å kjøre en rapporttypene sendes parametre via adressefeltet på samme måte som en GET forespørsel. Dette medfører at alle parameternavn er synlige og brukeren har mulighet for å manipulere verdiene. Dette er gjort med hensikt for at brukeren skal kunne bokmerke eller videresende adressen til en spesifikk rapporttype med egendefinerte valg og intervaller. Det er derfor viktig at all innkommende data blir nøye validert før de blir behandlet. For å bli ferdig med hovedfunksjonaliteten måtte vi dessverre nedprioritere de kraftigste sikkerhetssjekkene, men dette er noe vi er klar over og skal implementeres før produktet ferdigstilles på et senere tidspunkt. Innlogging Under utviklingen har vi ikke implementert brukeridentifisering eller innlogging. Aptoma har en ferdig modul til dette formålet som vil bli implementert på et senere tidspunkt. Frem til dette er klart bør Dr.Klikks rapportsystem legges bak et passordbeskyttet område i form av en.htaccess funksjon. 20

52 Utviklingsprosessen Filtilgang I vår MVC struktur er det kun filene som ligger i øverste nivå i Dr.Klikk mappen som kan kjøres offentlig. Dette skal kun være index.php, som blir brukt for registreringen, og report.php som brukes for rapportgenereringen. Under utviklingen har vi ikke hatt noen beskyttelse på disse, men i fremtidig må en være innlogget og autentisert for å få tilgang til å kjøre report.php. Ved registrering startes referansekall fra index.php til filene i strukturen under WEB-INF mappen. Dette er både for å skille kontroller og modell, samt for å unngå at uvedkommende kan få tilgang til de andre filene. PHP-filer er et server side språk som alltid blir parset / eksekvert av HTTPserveren før innholdet presenteres. Brukeren ser derfor ingen programstruktur eller PHP-kode, men kun det som spesifikt er programmert for å vises, i de fleste tilfeller ordinær HTML-kode. Tung prosessering ved rapport- og grafgenerering Ved generering av rapporter over store intervaller tar prosesseringen mye kraft og tid. Dersom Dr.Klikk kjøres på en server hvor andre applikasjoner er i produksjon kan dette føre til en reduksjon i ytelsen de andre applikasjonene, i noen tilfeller komplett stopp frem til rapporten er ferdig generert. En måte å redusere dette problemet på er å trunkere sammen data i lengre intervaller, slik som nevnt tidligere. Om ikke det blir effektivt nok kan det settes en sperre i rapportkontrolleren som ikke tillatter rapportgenerering over et visst intervall. 21

53 Utviklingsprosessen Aptomas sikkerhetskrav Aptoma har utviklet egne dokumenter med sikkerhetskrav for utvikling av moduler og applikasjoner. Her vil vi presentere noen av de viktigste prinsippene. Sikre databasespørringer slik at ikke SQL-injeksjon er mulig. Dette har vi fulgt til en viss grad, men er ikke fullstendig implementert. Dette er et absolutt krav og skal forbedres på et senere tidspunkt før applikasjonen blir utviklet ferdig. Ikke vis informasjon som ikke er planlagt å vises. I en applikasjon som er i produksjon gjelder dette visning av feilmeldinger ved feil i databasespørringer, feil i moduler, applikasjoner, HTTP-server eller annen programvare. Det inkluderer også feilmeldinger og advarsler fra PHP. Husk også å slette eventuelle phpinfo() filer som viser detaljert info om HTTP-server og PHP-moduler. Denne informasjonen kan bli brukt til angrep av crackere. Innstillinger for PHP Register_globals bør være avslått. Med denne innstillingen kan en velge om $_REQUEST objekter skal være globalt tilgjengelige, noe som er en stor sikkerhetsrisiko for manipulering av innkommende data. Eksisterende variabler med samme navn kan også bli overskrevet. Allow_url_fopen bør være avslått. Muliggjør kjøring av URL er på samme måte som filer. Safe_mode bør være aktivert. Begrenser eller deaktiverer funksjoner som potensielt kan være usikre. Kun lesetilgang hvor mulig Moduler eller applikasjoner som kun skal lese data fra en database bør 22

54 Utviklingsprosessen benytte en databasebruker som kun har lesetilgang til de aktuelle tabellene er databasen. I Dr.Klikk kunne vi splittet opp registreringen i en egen modul og rapportgenereringen i en egen modul. Disse kunne hatt hver sine konfigurasjonsinnstillinger i config-mappen. Registreringsmodulen kunne benyttet en databasebruker som har både lese og skrivetilgang, mens rapportmodulen benytter en databasebruker som kun har lesetilgang. Ingen backupfiler med filendelsen.bak. Dette muliggjør en bruker til å se innholdet av kildekoden og inspisere den for svakheter. Om du trenger backup, last opp til SVN. Alle midlertidige filer bør ha filendelsen.php slik at de blir parset av PHP-parseren og igjen kildekode blir vist til brukeren. 23

55 Utviklingsprosessen 24

56 Utviklingsprosessen 25

57 Dr.klikk 3. Kravspesifikasjon

58

59 Innholdsfortegnelse Oppdragsgivers kravspesifikasjoner...2 Endringer og avvik...2 Produktets status basert på opprinnelige krav eller endringer...3 Kravspesifikasjon...3 Mål og rammebetingelser...4 Mål...4 Rammebetingelser og tekniske krav...4

60 Kravspesifikasjon 1

61 Kravspesifikasjon Oppdragsgivers kravspesifikasjoner Det ble på et tidlig stadium fastsatt klare hovedpunkter over hva systemet skulle gjøre. Kravspesifikasjonen ble utarbeidet i samarbeid med oppdragsgiver som fremmet sine ønsker og krav. Det ble diskutert hvilke funksjoner som var ønsket implementert og hvilke funksjoner som måtte bli implementert. For å begrense prosjektets omfang var det nødvendig å utelate en del av ønskene. Endringer og avvik Vi utarbeidet en arbeids- og fremdriftsplan basert på kravspesifikasjonen og diskuterte med oppdragsgiver hvor mye som var forventet tidsbruk på de forskjellige delene. Underveis viste det seg at det ble en del ekstra arbeid med redesign av registreringsmodulen som medførte at vi måtte nedprioritere deler av kravspesifikasjonen. Etter som Aptoma har en ferdigutviklet brukerrolle- og innloggingsmodul ble vi enige med oppdragsgiver om å fjerne behovet for de forskjellige brukergruppene og deres funksjoner. Fokuset gikk over til å konstruere en mest mulig effektig registreringsmodul samt de viktigste rapporttypene. Det ble også gått bort fra å registrere klikk på en fysisk lenke med videresending til å registrere dette ved hjelp av Javascript. Funksjonen er implementert og klar til bruk dersom den er ønsket, men Javascript-basert registrering var det vi konsentrerte oss mest om. 2

62 Kravspesifikasjon Produktets status basert på opprinnelige krav eller endringer Som nevnt måtte vi begrense omfanget på opprinnelige krav. Vi har allikevel holdt fokuset på de viktigste funksjonene og har klart å utvikle en effektiv registreringsmodul med tre rapporttyper. Vi hadde et mål om at systemet skulle takle opp til 500 forespørsler i sekundet. Med et testresultat på 3500 forespørsler i sekundet er dette et godt utgangspunkt for videre utvikling av applikasjonen. Kravspesifikasjon Systemet, heretter kalt Dr.Klikk skal registrere hendelser om sidevisninger, klikk og annen relevant informasjon på en webside. Data skal mellomlagres i RAM før det blir satt inn i en database. Statistikkdata skal så leses ut fra databasen og presenteres i et enkelt og intuitivt grensesnitt, avhengig av brukertype. Følgende data skal registreres om hendelsen klikk Hvor klikket kommer fra Alle GET og POST variable Om det er en returnerende bruker Web-siden eller objektet hvor hendelsen kommer fra inneholder En URL som inneholder adressen til Dr.Klikk Eventuelt en JavaScript event Dr.Klikk skal Registrere data om et klikk Behandle disse dataene Sende brukeren videre ved hjelp av redirect 3

63 Kravspesifikasjon Mål og rammebetingelser Mål Å lage et best mulig skalerbart system m.h.p toleranse for trafikkintensitet Et lett tilgjengelig verktøy med lettleste grafer, statistikker og rapporter Enkelt kunne utvides til å motta data fra nye statistikkilder. Kunne utvides med flere og mer detaljerte rapporter. Å lage en intuitiv statistikkvisning som ikke krever forståelse for bakenforliggende funksjoner. Generere statistikkvisning for objekter basert på brukernivå Rammebetingelser og tekniske krav Utvikles i PHP5, Javascript, HTML og CSS. Skal kjøres på en Linux plattform med Apache webserver og MySQL5. Kunne kjøre på én dedikert maskin. Benytte Aptoma Framework (AFW). Følge Aptomas programmeringsstandarder. Bruke Subversion kildekodehåndteringssystem. UML skal benyttes i designprosess og dokumentasjon. VG Nett stiller servermaskin til disposisjon 4

64 Kravspesifikasjon 5

65 Dr.klikk 4. Oppsummering

66

67 Innholdsfortegnelse Hva har vi gjort...2 Hva har vi lært...2 Hva kunne vært gjort bedre...3 Produktets fremtid...4 Oppsummering med oppdragsgiver...5 Forventninger til prosjektet...5 Resultat i forhold til forventninger...5 Erfaringer med gruppen og arbeidsprosessen...5 Ting som kunne vært gjort bedre...6 Produktets fremtid...6 Kilder...7

68 Oppsummering 1

69 Oppsummering Hva har vi gjort Vi har våren 2007 gjennomført et hovedprosjekt ved Høgskolen i Oslo, avdeling for Ingeniørutdanning. Vi har skaffet oss en oppgave, kartlagt grunnlag og behov og produsert styringsdokumenter. Systemet har blitt utviklet samarbeid med en oppdragsgiver i næringslivet og de ferdige modulene har blitt satt i produksjon på Listefeber ( ). Underveis har vi fått tilbakemeldinger og forbedret funksjonalitet i henhold til kravspesifikasjonen. Hva har vi lært Gruppen har fått bred innsikt i hvordan programvare utvikles hos Aptoma AS. Vi har lært utrolig mye nyttig fagkunnskap, i tillegg til å være del av en gruppe og samarbeide med flere mennesker. Å kommunisere og lytte til mennesker for å forstå krav og ønsker er essensielt for å kunne levere nøyaktig det produktet kunden ville ha. Underveis i dette prosjektet har vi fått stor frihet. Det har vært klare krav hva produktet skal utføre og inneholde, men metodene for å komme frem til resultatet på har stort sett vært opp til gruppen. Vi har blitt både oppfordret til å tenke selv og diskutere mulige løsninger med Aptomas medarbeidere, som er en del av en sunn læringsprosess. Prosjektet har ikke blitt gjennomgått uten utfordringer. Vi støtte på problemer som ingen hadde tenkt over før og vi ble nødt til å tenke selv og søke informasjon for å finne den beste løsningen. Spesielt ved utvikling av registreringsmodulen opplevde vi mange aha-situasjoner, men det var ikke verre enn at vi klarte å løse utfordringene på en god måte. Aptomas erfaringer på spesialområder som skalerbarhet og caching har hjulpet oss i gjennomføringen av prosjektet. 2

70 Oppsummering Hva kunne vært gjort bedre Det viste seg at registreringsmodulen måtte redesignes flere ganger, noe vi ikke hadde tatt høyde for. Nødvendigvis var det ikke feil i planleggingen og spesifikasjonen som førte til dette, men det viste seg at det var nødvendig med disse opplevelsene for å tilegne seg erfaring og kunnskap. Tatt i betraktning av vi ikke har jobbet med Memcached, skalering og Javascriptcallback før var det mye som måtte læres og erfares. Det trengs tid til prøving og feiling for å fordøye hvordan et verktøy fungerer og hvordan programmeringsmetoder oppfører seg. Vi burde derfor planlagt en litt mer intensiv utvikling i begynnelsen i perioden. Dette førte til ble mye programmering mot slutten av prosjektperioden. Vi valgte å fortsette noe over det som var satt i fremdriftsplanen for å få ferdigstilt de viktigste rapporttypene. Dette gikk ut over starten på rapportskrivingen, og vi kunne kommet tidligere i gang med dette. Med bedre tid kunne vi gjennomført flere stresstester av systemet, optimalisert programkoden ytterligere og flere funksjoner kunne blitt implementert. Det viktigste er å få dokumentert forbedringspotensialene som gjenstår slik at dette kan bli tatt opp igjen ved videreutvikling av systemet. 3

71 Oppsummering Produktets fremtid Dr.Klikk kan bli benyttet til telling av statistikk fra alle mulige objekter på Internett som kan sende en Javascript hendelse. Først og fremst visning av websider og klikk på linker. Videre eksempler kan være å lese ut hvor mange som har sett på en spesiell del av en webside, hvor mange som har sett en konkret video på VG TV og hvor langt de har sett før de lukker avspilleren. Dr.Klikk er et statistikkaggregeringssystem for bruk i miljøer med ekstrem høy last. Bruksmulighetene er nært sagt ubegrensede og det er opp til brukeren av systemet å velge hva han ønsker å registrere. 4

72 Oppsummering Oppsummering med oppdragsgiver For å runde av prosjektet tok vi til slutt en prat med oppdragsgiver Geir Berset for å få frem hans erfaringer og tanker knyttet til prosjektperioden. Forventninger til prosjektet Oppdragsgiver hadde ikke sett for seg et ferdig produkt, men basisen for videreutvikling til et produkt. Det var viktigere med et lovende utgangspunkt enn et produkt som egentlig ikke var ferdig. Hovedfokuset for prosjektet var å utvikle en effektiv registreringsmodul som kunne danne et bra utgangspunkt klart for rapportgenerering uten store problemer med ytelse. Det var også et ønske om å få startet på utviklingen av rapporttypene til bruk som «proof of concept» for at backend fungerer. Resultat i forhold til forventninger Omtrent som forutsett. Noen funksjoner var også bedre enn forventet. Blant annet ytelse i registreringsprosessen og et enkelt og oversiktlig rapportgrensesnitt. Oppdragsgiver hadde et håp om å komme i mål med hovedfunksjonene, som i følge oppdragsgiver i store trekk er oppnådd. Viktigere er det at Dr.Klikk har et tilsynelatende stort potensiale for videre utvikling av front-end og rapporttyper. Dette var også hovedmålet for prosjektet for oppdragsgiver. Erfaringer med gruppen og arbeidsprosessen Kommunikasjonen var ryddig og åpen. Vi hadde faste ukentlige møter, noen ganger annenhver uke etter behov. Her ble arbeidet og aktuelle spørsmål tatt opp. 5

73 Oppsummering Gruppen viste interesse og var ikke redde for å komme med spørsmål underveis. De var villige til å grave og stille aktuelle problemstillinger. Tekniske uklarheter på et høyere nivå ble overlatt til diskusjon med Vilhelm. Ting som kunne vært gjort bedre Gruppen kunne vært flinkere til å oppdatere prosjektets status i styringsverktøyet Streber. Her er det lettere å få oversikt over arbeidsoppgaver og er en god måte å styre prosjektet på. Kunne blitt brukt til å spesifisere hvilke oppgaver en jobber med og lagt inn todo og neste oppgaver underveis. Gruppen kunne trolig vært tjent med å arbeide noe mer på kontoret. Å føle seg som en del av miljøet, være tilstede og ha muligheten til å stille spørsmål hjelper på motivasjon og arbeidsflyt og er en fordel i prosjektsammenheng. Men dette var ikke var noe krav, og heller ikke noe som alltid lot seg praktisk kombinere med øvrige studier. Oppdragsgiver er svært fornøyd med ryddig kommunikasjon fra prosjektdeltakere, men på møter når mange tema ble diskutert kunne det noen ganger blitt tatt mer notater, uten at dette noen gang viste seg som et problem. Produktets fremtid Produktet vil i fremtiden bli videreutviklet, og dette prosjektet vil legges til grunn for videre utvikling. Frem til dette vil Dr.Klikk bli brukt som en modul sammen med andre applikasjoner, som for eksempel Listefeber, og trolig under utvikling av andre prosjekter og produkter. 6

74 Oppsummering Kilder Dokumenter fra Aptoma SecurityRequirements no.aptoma.pdf ModuleRequirements - no.aptoma.pdf Development - no.aptoma.pdf ApplicationPropertyRequirements - no.aptoma.pdf ApplicationBehaviorRequirements - no.aptoma.pdf Dokumenter fra Høgskolen I Oslo Dokumentasjonsstandard av Ann-Mari Torvatn Utviklingsmetoder 7

75 Oppsummering 8

76 Oppsummering 9

77 Dr.klikk Vedlegg 1 Produktdokumentasjon

78

79 Innholdsfortegnelse Forord...2 Beskrivelse av Dr.Klikk...3 Definisjoner og ordforklaringer brukt i dokumentasjonen...4 Javascript-callback...4 En anker-tag...4 Dr.Klikk tag...4 Sidetittel...4 Installasjon av Dr.Klikk...5 Databasestruktur...7 Use Case modell av prosessflyt...8 Utdrag av programmets oppbygging og virkemåte...9 Javascript callback for registrering av sidevisning...9 Registrering av klikk på link Tidsstyrt innlegging av data fra Memcached til database Tidsstyrt innlegging av sidetitler til registrerte URL-er Visning av rapport med statistikkdata Klasse og metodebeskrivelser Javascriptet... 29

80 Vedlegg 1 - Produktdokumentasjon 1

81 Vedlegg 1 - Produktdokumentasjon Forord Dette dokumentet er en beskrivelse av det leverte produktet, dets virkemåte og oppbygging beregnet på den som skal vedlikeholde, videreutvikle, eller installere Dr.Klikk. Produktbeskrivelsen skal gi en teknisk forståelse for produktets sentrale datastrukturer og systemflyt, og inneholder en enkel beskrivelse av produktets klasser og metoder. Beskrivelsen krever allerede grunnleggende forståelse for teknologien brukt og kjennskap til enkelte tekniske uttrykk brukt i beskrivelsen. 2

82 Vedlegg 1 - Produktdokumentasjon Beskrivelse av Dr.Klikk Dr.Klikks hensikt er å kunne samle inn og vise statistikkrapporter av trafikkdata for en nettressurs med lav forsinkelse mellom registrering og rapportvisning. Mens andre systemer gjerne har rapporter klar for bruker tidligst et par timer etter data er registrert skal Dr.Klikk registrere data med kun minutter til sekunders forsinkelse, med samme forsinkelse for rapportdata. Dr.Klikk har en rask registrering og mellomlagring i serverminne som på en kraftig server muliggjør mottak av flere tusen statistikkpunkter i sekundet, med tidsstyrt lesing av minnedata inn i systemets database. Dataregistrering, datalagring i database, og rapportgenerering er gjort av tre avskilte systemer hvor teknologien brukt tillater enkel distribuering over forskjellige systemer om ønsket høyere skalerbarhet. 3

83 Vedlegg 1 - Produktdokumentasjon Definisjoner og ordforklaringer brukt i dokumentasjonen Javascript-callback En HTTP-forespørsel sendt fra et Javascript eksekvert i brukers nettleser med informasjon som mottas og registreres av en server. HTTP-forespørselen resulterer ikke i en omlasting av nettsiden i nettleser, og mottar potensielt veldig lite data tilbake fra server. En anker-tag Et HTML-element brukt for til å lage linker enten til eksterne dokumenter eller til en ID i samme dokument. <a href= dokument.html >A-tagen er et ankerelement</a>. Dr.Klikk tag Et beskrivende ord for kategorisering og gruppering av statistikkelementer. For eksempel kan taggen scanpix brukes på alle sider eller elementer som kommer fra Scanpix. Blir satt i Javascriptet som inkluderes på den aktuelle websiden. Eksempel: <script type="text/javascript" src="/drklikk/js/drklikk.js"></script> <script type="text/javascript"> drklikk('scanpix'); </script> Sidetittel En websides tittel. Plassert i <title></title> i HTML-dokumentes <head></head> avsnitt. Referer Referanse til den forrige siden som ble besøkt i en nettleser. 4

84 Vedlegg 1 - Produktdokumentasjon Installasjon av Dr.Klikk Installasjonen er basert på Aptomas retningslinjer for installasjon av moduler og er som følger. 1. Plasser Dr.Klikk på et område tilgjengelig fra serverens HTTPservertjeneste. Dr.Klikk-modulen plasseres på samme nivå som AFW i mappestrukturen. I den medleverte versjonen er AFW inkludert. 2. Importer databasen fra WEB-INF/sql/database.sql. Testdata ligger i WEB- INF/sql/test-data.sql 3. Konfigurer applikasjonen ved å kopiere mappen WEB-INF/config.default/ til WEB-INF/config/. Foreta de endringer som trengs i php-filene init.php Legg til ønskede oppstartsfunksjoner paths.php Filsti-innstillinger settings.php Applikasjonsspesifikke innstillinger shadow.php - Databaseinnstillinger 4. Konfigurer javascriptet som ligger i js/drklikk.js ved å sette URL en til Dr.Klikk installasjonen til variabelen drklikkurl. 5. Kopier WEB-INF/model/jpgraph/src/jpgraph-config.inc-default.php til WEB- INF/model/jpgraph/src/jpgraph-config.inc.php. Tilpass verdiene for mellomlagring og fonter for det aktuelle operativsystemet. Eventuelle andre innstillinger kan endres dersom ønskelig. Installasjonen er nå komplett, og du kan aksessere funksjonaliteten ved å gå til den installerte applikasjonens URL. 5

85 Vedlegg 1 - Produktdokumentasjon 6

86 Vedlegg 1 - Produktdokumentasjon Databasestruktur Databasen består av enkle tabeller som er optimalisert for å oppnå høyest mulig ytelse. Tabellstrukturene vises under. Figur p-01. Databasestruktur 7

87 Vedlegg 1 - Produktdokumentasjon Use Case modell av prosessflyt Figur p-02. Use Case modell 8

88 Vedlegg 1 - Produktdokumentasjon Utdrag av programmets oppbygging og virkemåte Javascript callback for registrering av sidevisning 1. Ved lasting av side eksekveres javascriptmetoden drklikk(). En link til DrKlikk blir satt sammen av sideadresse, refereradresse, DrKlikktag og en brukeridentifiserende variabel userkey. Denne linken blir satt inn i websiden som et usynlig bilde og linken til index.php i DrKlikk blir kjørt når siden lastes. 2. index.php instansierer DrKlikkRegisterController. 3. DrKlikkRegisterController legger data fra sidevisningen inn i Memcached. Se figur p-03. 9

89 Vedlegg 1 - Produktdokumentasjon Figur p-03. Javascript callback for registrering av sidevisning 10

90 Vedlegg 1 - Produktdokumentasjon Registrering av klikk på link 1. Javascript lytter på sidens anker-tagger og endrer adressen kalt til DrKlikk. I eksempelet er linkens adresse side2.html med DrKlikktag panowie. Denne Javascriptfunksjonen er i testversjon uten støtte for alle browsere. 2. index.php instansierer DrKlikkRegisterController. 3. DrKlikkRegisterController legger data fra klikket inn i Memcached. 4. En HTTP status code 302 (REDIRECT) blir returnert til browser som laster siden bak orginallinken. Se figur p

91 Vedlegg 1 - Produktdokumentasjon Figur p-04. Registrering av klikk på link 12

92 Vedlegg 1 - Produktdokumentasjon Tidsstyrt innlegging av data fra Memcached til database 1. Et tidsstyrt kall blir gjort for rendring av ParseData.php. 2. Metoden parsedata leser ut og sletter data lagret i Memcached. 3. Statistikkpunkter med identisk tag, URL og scope blir summert og unike URLparseData kaller en metode i DrKlikkProcessor med de summerte statistikkpunktene. 4. DrKlikkProcessor bruker kall til en AFW-metode for skriving av data til databasen. 5. parsedata kaller en metode i DrKlikkProcessor med de unike URL-ene. 6. DrKlikkProcessor bruker AFW-metoder for å legge inn nye URL-er i databasen. 7. Antall innlagte statistikkpunkter og antall nyregistrerte URL-er blir skrevet ut for loggføring av tidskontrolleren. Se figur p

93 Vedlegg 1 - Produktdokumentasjon Figur p-05. Tidsstyrt innlegging av data fra Memcached til database 14

94 Vedlegg 1 - Produktdokumentasjon Tidsstyrt innlegging av sidetitler til registrerte URL-er 1. Et tidsstyrt kall blir gjort for rendring av ReadPagetitles.php. 2. Metoden readpagetitles kaller en metode i DrKlikkProcessor som returnerer et begrenset antall URL-er fra databasen hvor tittel ikke er registrert. 3. DrKlikkProcessor bruker kall til en AFW-metode for å lese data ut av databasen. 4. readpagetitles bruker kall til en AFW-metode for lasting av eksterne dokumenter for hver av URL-ene og leser ut sidens tittel. 5. readpagetitles kaller en metode i DrKlikkProcessor for skriving av tittel til databasen 6. DrKlikkProcessor bruker kall til en AFW-metode for skriving til databasen. 7. Antall innlagte titler blir skrevet ut for loggføring av tidskontrolleren. Se figur p

95 Vedlegg 1 - Produktdokumentasjon Figur p-06. Tidsstyrt innlegging av sidetitler til registrerte URL-er 16

96 Vedlegg 1 - Produktdokumentasjon Visning av rapport med statistikkdata 1. Browser kaller report.php med do-variabel som forteller hvilken rapport som er ønsket. 2. report.php instansierer DrKlikkReportController. 3. DrKlikkReportController kaller på rett prosesseringsmetode i DrKlikkReportProcessor. 4. DrKlikkReportProcessor henter nødvendige data fra databasen. 5. DrKlikkReportProcessor oppretter sparklinebilder og/eller JPGraphbilder i sine respektive mapper. 6. Data blir returnert til kontrolleren fra prosessoren og blir tilgjengelig i view. 7. Ferdiggenerert HTML av rapporten blir returnert til browser. Se figur p

97 Vedlegg 1 - Produktdokumentasjon Figur p-07. Visning av rapport med statistikkdata 18

98 Vedlegg 1 - Produktdokumentasjon Klasse og metodebeskrivelser Her følger et utdrag av de viktigste klassene og metodene. For komplett oversikt vises til programkoden på vedlagt CD. class DrklikkRegisterController Klasse for registrering av datapunkter og innlegging i et Memcached-array i systemminnet. For satte verdier av do-variabelen blir metoden register() kalt med verdiens medfølgende scope, get-parametre og requestvariabler. register( $scope, $rurl, $referer, $tag, $key ) Tar imot data sendt fra bruker, requestvariabler samt statistikkpunktets scope. Dette blir satt inn i et array og lagret i Memcachedserveren satt i DrKlikks settings.php i Config-katalogen. Dersom PHPs modulklient for Memcached ikke er installert på systemet blir en PHP-basert klient lastet inn og brukt til lagringen. class parsedata Klasse som leser ut alle datapunkter lagret i Memcached, og lagrer disse data i databasen. parseregistereddata() Henter ut og sletter alle datapunkter i Memcachedserveren satt i DrKlikks settings.php i Config-katalogen, og datapunktene med identisk URL, scope og tag blir addert sammen. Hvert punkts scope og alle unike URL-er blir sjekket mot databasen og opprettet der om ikke allerede eksisterende. Dersom PHPs modulklient for Memcached ikke er installert på systemet blir en PHP-basert klient lastet inn og brukt til lagringen. class readpagetitles Klasse som henter ut alle URL-er i databasen hvor feltet for sidetittel ikke er satt, henter dokumentet hver URL peker til, forsøker å lese dokumentets sidetittel, og setter funnet tittel inn i databasen. 19

99 Vedlegg 1 - Produktdokumentasjon readnewpagetitles() Leser alle URL-er i databasen hvor feltet for sidetittel ikke er satt. For et satt antall av resultatene kalles metoden urlgetcontents() fra AFW, sidens tittel blir funnet med et regulært uttrykk og lagt inn i databasen. P.g.a. potensielt lang prosesseringstid kreves det at kun et begrenset antall sidetitler blir lest ut for hver eksekvering. class DrKlikkProcessor Klasse med metoder for lesing og skriving av data brukt av klassene readpagetitles og parsedata. findorcreatescopebyname( $scopename ) Sjekker om scopenavnet medsendt som parameter finnes i databasen, og oppretter det nye scopet om ikke-eksisterende. Returnerer et identifiserende integer for scopet. getscopebyname( $scopename ) Sjekker om scopenavnet medsendt som parameter finnes i databasen. Returnerer et identifiserende integer for scopet. savecompactdatapoint( $datapointarray ) Lagrer data fra et datapunktarray medsendt som parameter i databasen med AFW-funksjonen setquery. reademptypagetitles() Returnerer en liste over alle URL-er i databasetabellen pagetitles hvor datafeltet title ikke er satt. writenewpagetitletitle( $url, $title ) 20

100 Vedlegg 1 - Produktdokumentasjon Oppdaterer raden i databasetabellen pagetitles hvor URL er lik URL sendt med som parameter. Datafeltet title blir satt til tittel fra parameter, og feltet modified blir satt til tidspunktet for titteloppdateringen. doesurlexist( $url ) Returnerer true eller false ettersom URL medsendt som parameter eksisterer i databasetabellen pagetitles. writenewpagetitleurl( $url ) Lagrer en ny rad i databasetabellen datapoints hvor datafeltet url blir satt til medsendt parameter og feltet created blir satt til tidspunktet for opprettelsen. class DrKlikkReportController Kontrollerklasse i AFWs MVC-system for generering av rapporter. Data fra do-variabelen bestemmer hvilken rapportmetode som skal eksekveres med nødvendige requestvariabler. Data returnert blir tilgjengelig i outputmetoden i valgt view og subview. gettemp($seconds, $limit) Returnerer data til «Mest leste saker»-rapporten for gitt antall sekunder bak i tid, og begrenset til gitt antall rader. getweekstats( $date, $group, $order, $way, $start, $limit ) Returnerer data til rapporten for visning av statistikk på ukesbasis. Dagsdato fra parameter bestemmer hvilken uke som skal vises. gettagurl( $tag, $datefrom, $hourfrom, $minutefrom, $dateto, $hourto, $minuteto, $order, $way ) Returnerer data til rapporten for visning av alle URL-er for gitt tag i gitt tidsrom. 21

101 Vedlegg 1 - Produktdokumentasjon getstats( $datefrom, $hourfrom, $minutefrom, $dateto, $hourto, $minuteto, $limit, $group, $order, $way ) Returnerer data til rapporten for visning av statistikk på fritt tidsrom. Denne funksjonen blir brukt av «I dag»-rapporten, og henter data mellom et gitt tidsrom gruppert og sortert på gitte verdier. getgraph( $xvalue, $intmin, $datefrom, $hourfrom, $minutefrom, $dateto, $hourto, $minuteto, $tag, $sensitivity ) Returnerer data til visningen av en graf for en tag innenfor et gitt tidsrom, samt URL til det genererte grafbildet. class DrKlikkReportProcessor Modellklasse i AFWs MVC-system for generering av rapporter. Metodene i klassen henter og kalkulerer data fra databasen som blir returnert til kontrolleren. getweekstats( $date, $group, $order, $way, $start, $limit ) Returnerer data til kontrolleren for visning av statistikk på ukesbasis. Dagsdato fra parameter bestemmer hvilken uke som skal vises. Returnerte data: ->allstats[] : Total mengde PI for hele uken til gitt antall tagger { For hver tag/rad i rapporten ->tag : DrKlikktag for rad ->pi : Antall sidevisninger for tag ->days : Mengde PI for hver av de syv dagene i uken for tag ->sparkline : URL til generert sparkline for hele uken for tag ->graphurl : URL til generering av stor JPGraph for hele uken for tag ->prevweektotal : Total mengde PI forige uke for tag 22

102 Vedlegg 1 - Produktdokumentasjon } ->total : Mengde PI for hver av de syv dagene i uken ->sparkline : URL til generert sparkline for hele uken ->graphurl : URL til generering av stor JPGraph for hele uken ->weektotal : Total mengde PI i uken ->preweektotal : Total mengde PI forrige uke ->headline : Overskrift for rapporten ->currentday : Integer mellom en og syv for markering av valgt ukedag ->previousweek : Dato syv dager før valgt dato ->nextweek : Dato syv dager etter valgt dato getweekdaysstats( $days, $tag, $group ) Metode kun kalt av getweekstats(). Returnerer et array med PI for hver av dagene sendt med i parameterarrayet $days med eventuell tag. getpiforweek( $from, $to, $group, $order, $way, $start, $limit ) Metode kun kalt av getweekstats(). Returnerer gitt antall tagger og tilhørende PI for tidsrom. gettotalweekstats( $from, $to, $tag ) Metode kun kalt av getweekstats(). Returnerer den totale mengden PI for en gitt uke med eventuell tag. gettagurl( $tag, $datefrom, $hourfrom, $dateto, $hourto, $minuteto, $order, $way ) Returnerer data til kontrolleren for visning av statistikk over URL-er for en gitt tag. Returnerte data: ->tagurl[] : For hver URL/rad i rapporten { ->url : URL registrert på gitt tag 23

103 Vedlegg 1 - Produktdokumentasjon ->referer : Referer overstående URL er registrert med. ->uv : Unike brukere registrert på tag, URL og referer siste døgn. ->us : Unike brukersessjoner registrert på tag, URL og referer. ->pi : Antall sidevisninger registrert på gitt tag, URL og referer. } ->tagname : Navn på tag det vises statistikk for ->sortlinks : Linker for sortering på de forskjellige kategoriene { ->url : Sortering på URL ->referer : Sortering på referer ->uv : Sortering på UV ->pi : Sortering på PI ->us : Sortering på US } getallurlsfortag( $tag, $datefrom, $hourfrom, $minutefrom, $dateto, $hourto, $minuteto, $order, $way ) Metode kun kalt av getallurlsfortag(). Returnerer data for hver URL tilknyttet en gitt tag innenfor et tidsområde. getstats( $datefrom, $hourfrom, $minutefrom, $dateto, $hourto, $minuteto, $limit, $group, $order, $way ) Returnerer data til kontrolleren for visning av statistikk statistikk på fritt tidsrom. Returnerte data: ->allstats[] : For hver URL/rad i rapporten { ->created : Dato statistikkpunktene ble lagret i databasen ->url : URL til side rapportraden gjelder ->tag : DrKlikktag rapportraden gjelder 24

104 Vedlegg 1 - Produktdokumentasjon ->uv : Unike brukere registrert på tag, URL og referer siste døgn. ->us : Unike brukersessjoner registrert på tag, URL og referer. ->pi : Antall sidevisninger registrert på tag, URL og referer. ->prevuv : Antall unike brukere registrert for forrige tidsperiode av samme lengde. ->tagurl : Konstruert URL for visning av URL-statistikk på gitt tag. ->goals { ->number : Måltall satt i databasen for gitt tag. ->level : Integer som beskriver en tagger måltall mot registrerte sidevisninger. } ->sparkline : URL til generert sparklinebildefil for rapportrad. ->graphurl : URL til visning av større grafbilde for rapportrad. } ->total { ->uv : Totalt antall unike brukere per døgn i registrert tidsperiode. ->pi : Totalt antall sidevisninger registrert i tidsperiode. ->us : Totalt antall brukersesjoner registrert i tidsperiode. ->sparkline : URL til generert sparklinebildefil for rapportrad. ->graphurl : URL til visning av større grafbilde for rapportrad. goals { ->number : Totale måltall satt i databasen. ->level : Integer som beskriver totale måltall mot registrerte sidevisninger. } ->prevuv : Antall unike brukere registrert for forrige tidsperiode av samme lengde. } 25

105 Vedlegg 1 - Produktdokumentasjon ->sortlinks { ->tag : Link til rapporten for sortering på tag. ->uv : Link til rapporten for sortering på unike brukere. ->pi : Link til rapporten for sortering på sidevisninger. ->us : Link til rapporten for sortering på brukersesjoner. } ->previousdayfrom : Dato for begynnelsen av døgnet før valgt dato. ->previousdayto : Dato for slutten av døgnet før valgt dato. ->nextdayfrom : Dato for begynnelsen av døgnet etter valgt dato. ->nextdayto : Dato for slutten av døgnet før valgt dato. ->headline : Overskrift for rapporten. getallstats( $from, $to, $limit, $group, $order, $way ) Metode kun kalt av getstats(). Returnerer data for et gitt antall rader i et tidsrom. gettotalstats( $from, $to, $limit, $group, $order, $way ) Metode kun kalt av getstats(). Returnerer totale data for et gitt tidsrom. getgoalnumbers( $from, $to, $tag ) Metode kun kalt av getstats(). Returnerer måltall for gitt tag eller alle måltall summert om manglende tag. getprevuv( $from, $to, $tag ) Metode kun kalt av getallurlsfortag(). Returnerer total mengde UV for en eventuell tag i et gitt tidsrom. gettemp( $periodlengthinseconds, $limit ) Returnerer data til kontrolleren for «Mest leste saker»-rapporten for gitt antall sekunder bak i tid, og begrenset til gitt antall rader. 26

106 Vedlegg 1 - Produktdokumentasjon Returnerte data: ->tempdata { ->urls[] : For hver URL/rad i rapporten { ->tag : DrKlikktag for rapportrad. ->url : URL for rapportrad. ->pi : Antall sidevisninger for gitt DrKlikktag og URL i tidsperiode. ->prevpi : Antall sidevisinger for gitt tag og URL registrert forrige tidsperiode av samme lengde. ->pagetitle : Sidetittel fra dokument på URL om tilgjengelig i databasen. ->change : Hvilken utvikling tallet for sidevisning har hatt fra forrige tidsperiode av samme lengde. } } ->periodlength : Hvor lang valgt tidsperiode er. ->headline : Rapportens overskrift. getpagetitleforurl( $url ) Metode kun kalt av gettemp(). Returnerer en URLs eventuelle sidetittel fra tabellen pagetitles i databasen. Om ingen tittel er lagret for URL returneres URL-en. drawsparkline( $from, $to, $UNIXFrom, $interval, $tag ) Metode som genererer en sparklinebildefil med path lest ut fra paths.php i Config-mappa for en gitt tag i et tidsrom. Returnerer URL til bildefilen. getsparklinedata( $from, $to, $UNIXFrom, $interval, $tag ) Metode kun kalt av drawsparkline(). Returnerer PI for en eventuell tag for et tidsrom oppdelt i 100 tidsintervaller. 27

107 Vedlegg 1 - Produktdokumentasjon drawjpgraph( $xvalue, $intmin, $datefrom, $timefrom, $dateto, $timeto, $tag, $sensitivity ) Metode som genererer en grafbildefil med path lest ut fra paths.php i Config-mappa for en gitt tag i et tidsrom. Returnerer URL til bildefilen. getgraphdata( $datefrom, $hourfrom, $minutefrom, $dateto, $hourto, $minuteto, $tag ) Metode kun kalt av drawjpgraph(). Returnerer et array med alle (X,Y) koordinatpunkter satt sammen av UNIX-time og PI for en eventuell tag i et tidsrom. 28

108 Vedlegg 1 - Produktdokumentasjon Javascriptet drklikk.js drklikk(drklik_tag) Mottar DrKlikktag fra websiden som parameter, og konstruerer en URL til DrKlikk basert på DrKlikktag, URL, sidereferer og en brukeridentifiserende verdi userkey. Userkey blir lest ut fra cookie om allerede eksisterende, og ellers generert som en MD5-hash og lagret i cookie. Eksempel på konstruert URL: e2.html&tag=side2&userkey=d41d8cd98f00b204e ecf8427e drklikkgetcookievalue(cookiename) Returnerer verdien lagret i cookie med navn medsent som parameter. Dersom gitt cookie ikke eksisterer returneres false. drklikkmd5(string) Returnerer en kryptografisk MD5-hash av string medsendt som parameter. Denne metoden er skrevet av Justas Vinevicius og gjort offentlig under en freewarelisens på webtoolkit.info. 29

109 Vedlegg 1 - Produktdokumentasjon 30

110 Vedlegg 1 - Produktdokumentasjon 31

111 Dr.klikk Vedlegg 2 Brukermanualer

112

113 Innholdsfortegnelse Veiledning for Webmaster...2 Veiledning for Rapportbruker...3 «I dag» med mulighet for fritt valg av tidsperiode ned til kvarternivå...4 «Denne uken» med mulighet for navigering frem og tilbake i tid...9 «Mest viste» for valg av visning i en periode fra ett til seksti minutter 12

114 Vedlegg 2 - Brukermanualer 1

115 Vedlegg 2 - Brukermanualer For veiledning til installasjon av selve Dr.Klikk applikasjonen henvises det til produktdokumentasjonen. Veiledning for Webmaster Denne brukerveiledningen er beregnet på en person som skal legge til DrKlikk på nettsider eller objekter hvor statistikk skal måles. DrKlikk kan lett integreres på en nettside, og alt som trengs er at Javascriptet drklikk.js inkluderes i koden, samt at et kall til scriptmetoden drklikk() med en beskrivende Dr.Klikk-tag som parameter blir gjort. Dersom brukers nettleser ikke støtter Javascript vil fortsatt alle linker i dokumentet fungere, men ingen statistikk vil bli registrert av Dr.Klikk. Følgende javascriptkode kopieres inn nederst i HTML-koden før </body> <script type="text/javascript" src="/drklikk/js/drklikk.js"></script> <script type="text/javascript"> drklikk('panowie'); </script> Figur b-01. Slik kopieres Dr.Klikk registeringskoden inn i et HTML-dokument. 2

116 Vedlegg 2 - Brukermanualer Veiledning for Rapportbruker Rapportsystemet i Dr.Klikk består per dags dato av tre forskjellige rapporter, en side for visning av URL-statistikk for en enkelt Dr-Klikk-tag samt mulighet for generering av et fullsidig grafbilde. Alle rapporter bruker HTTP-GET og sender URL og parametre over adresselinjen i nettleseren. URL til en rapport kan dermed kopieres og f.eks utveksles over epost. Alle bilder kan direkte høyreklikkes for lagring av lokal kopi. For å ta i bruk visning av rapporttypene forutsettes det at brukeren har kjennskap til navigering i websider og kjennskap til statistikkbegreper som PI, UV, US og hvordan en Dr.Klikk tag fungerer. Dette kommer frem i tidligere dokumentasjon. Rapportene og deres funksjoner følger nedenfor. Grunnen til at noe tekst i overskriftene i skjermbildene er på engelsk er at norske regionsinnstillinger ikke er installert på serveren enda. 3

117 Vedlegg 2 - Brukermanualer «I dag» med mulighet for fritt valg av tidsperiode ned til kvarternivå. Figur b-02. Skjermbilde av «I dag» rapporten. 4

118 Vedlegg 2 - Brukermanualer Figur b-03. Javascriptbasert kalender Javascriptbasert kalender for datovalg i start og slutt av tidsintervall. Kalenderfunksjonen er en del av AFW. Alternativt kan datoer manuelt skrives inn i tekstfelt i formatet: Figur b-04. Komboboks for valg av time og minutt Kombobokser for valg av time og minutt i start og slutt av tidsintervall. 5

119 Vedlegg 2 - Brukermanualer Figur b-05. Komboboks for valg av maks antall rader Komboboks for valg av maks antall rader vist i rapporten. Figur b-06. Navigeringsknapper. Frem- og tilbakeknapper for døgnbasert visning frem og tilbake i tid. Figur b-07. Totalstatistikk for en periode. Øverste rad er markert med fetere skrift og viser totalstatistikk. Figur b-08. Tagliste. Liste over tags hvor hver tag er en link til tagstatistikk på URL-basis 6

120 Vedlegg 2 - Brukermanualer Figur b-09. Trendgrafer, kalt Sparklines. Sparklines basert på sidevisninger som viser enkel utvikling gjennom tidsintervallet. Hver sparkline er en link til generering av større grafbilde. Figur b-10. PI, UV, US, PI / UV, UV + / - PI, UV, US samt PI/UV og UV+/- PI = Page impressions eller sidevisninger på norsk. Antall ganger en side med denne Dr.Klikk-tag er lastet. UV = Unique visitors eller unike brukere på norsk. Antall unike brukere som har lastet en side med denne Dr.Klikk-tag på ett døgn. US = User sessions eller brukersessjoner på norsk. Antall ganger en bruker har lastet en side med denne Dr.Klikk-tag når forrige sidevisning av samme side var mer enn et gitt antall tidsenheter siden. Default for Dr.Klikk er 30 minutter. PI/UV = Hvor mange ganger gjennomsnittsbrukeren har lastet en side med denne DrKlikktag siden på ett døgn. 7

121 Vedlegg 2 - Brukermanualer UV+/- = Utvikling i forhold til forrige intervall av samme lengde. Negativt tall farges rødt mens positivt farges grønn. Stigende og synkende sorteringsmuligheter på Dr.Klikk-tag, UV, PI og US ved klikk på den aktuelle parameteren. Visning av eventuelt måltall lagret for en Dr.Klikk-tag i databasen. PI høyere enn måltall resulterer i grønn farge, mens lavere PI gir rød farge. 8

122 Vedlegg 2 - Brukermanualer «Denne uken» med mulighet for navigering frem og tilbake i tid Figur b-11. «Denne uken» rapporttypen. Figur b-12. Navigasjonsknapper. Frem- og tilbakeknapper for døgnbasert visning frem og tilbake i tid. Figur b-13. Totalstatistikk for en uke. Øverste rad er markert med fetere skrift og viser totalstatistikk. 9

123 Vedlegg 2 - Brukermanualer Figur b-14. Tagliste. Tagliste med link til tagstatistikk på URL-basis. Figur b-15. Trendgrafer, kalt Sparklines. Sparklines basert på sidevisninger som viser enkel utvikling gjennom tidsintervallet. Hver sparkline er en link til generering av større JPGraph-grafbilde. Figur b-16. Statistikktall for dager i en uke. 10

124 Vedlegg 2 - Brukermanualer Dagsbaserte tall for sidevisninger (PI) for uken med utheving av nåværende/valgt dato. Figur b-17. Totale tall og endringer fra forrige uke Totalt antall sidevisninger (PI) for uken, samt sammenligning med forrige uke. Viser høyere antall PI enn forrige uke i grønt og lavere i rødt. 11

125 Vedlegg 2 - Brukermanualer «Mest viste» i en periode fra ett til seksti minutter Figur b-18. «Mest viste» rapporttypen. Figur b-19. Valg av intervall. Komboboks for valg av tidsintervall for rapporten. 12

126 Vedlegg 2 - Brukermanualer Figur b-20. Valg an maks antall rader. Komboboks for valg av maks antall rader vist i rapporten. Figur b-21. Nedtelling til automatisk oppdatering. Tidsnedteller til automatisk oppdatering av rapporten. Figur b-22. Antall sidevisninger og endringer. Visning av antall sidevisninger (PI) i valgt tidsintervall, antall sidevisninger (PI) forrige tidsintervall, og utviklingen mellom de to intervallene. Høyere PI enn forrige intervall resulterer i grønne tall mens lavere gir røde. 13