1. No category

12-01-2015
Afsluttende
opgave
Quiz Plugin i WordPress
University College Nordjylland
Datamatikeruddannelsen
Henrik Mikkelsen, dmaa0912
Forord
Denne rapport er udgivet af Henrik Mikkelsen, elev på University College Nordjylland. Den blev
skrevet i løbet af den periode hvor jeg arbejdede på min afsluttende opgave på
datamatikeruddannelsen.
Selveste opgaven er lavet i samarbejde med virksomheden, Cleverweb.
Den har til formål at beskrive processen under hele projektperioden, og at dokumentere mit
arbejde med projektet.
Der skal lyde en stor tak til de to ejere af Cleverweb, Martin Hjort og Tommy Bæk Søgaard for at
have givet mig opgaven, og for at have været nemme at samarbejde med under hele perioden.
Der skal også lyde en stor tak til min vejleder, Christian Wahl, for at have givet mig god
vejledning og altid været til rådighed når der har været behov for det.
1
1 INDHOLDSFORTEGNELSE
2
3
4
Indledning ............................................................................................................................................. 4
2.1
Opgave .......................................................................................................................................... 5
2.2
Problemformulering...................................................................................................................... 5
2.3
Afgrænsning .................................................................................................................................. 6
Metodevalg ........................................................................................................................................... 7
3.1
Boehms projekkort........................................................................................................................ 7
3.2
XP ................................................................................................................................................ 10
3.3
Scrum .......................................................................................................................................... 12
3.4
Praksis ......................................................................................................................................... 17
Teknologivalg ...................................................................................................................................... 18
4.1
WordPress ................................................................................................................................... 18
4.1.1
4.2
PHP .............................................................................................................................................. 21
4.3
JavaScript .................................................................................................................................... 22
4.3.1
jQuery.................................................................................................................................. 23
4.3.2
AJAX..................................................................................................................................... 23
4.4
5
Databasestruktur ................................................................................................................ 19
Overvejelser ................................................................................................................................ 24
4.4.1
Ingen JavaScript?................................................................................................................. 24
4.4.2
Cookies vs. local storage ..................................................................................................... 24
Processen ............................................................................................................................................ 27
5.1
Sprint 0 ........................................................................................................................................ 27
5.1.1
User Stories ......................................................................................................................... 27
5.1.2
Udviklingsmiljø .................................................................................................................... 27
5.1.3
Test ...................................................................................................................................... 28
5.1.4
Arkitekturvalg...................................................................................................................... 28
5.1.5
Domænemodel ................................................................................................................... 31
5.1.6
Risikoanalyse ....................................................................................................................... 32
5.1.7
Kodestandard ...................................................................................................................... 33
5.2
Sprint 1 ........................................................................................................................................ 33
2
5.2.1
Planlægning ......................................................................................................................... 33
5.2.2
Udførelse ............................................................................................................................. 34
5.2.3
Kodeeksempler ................................................................................................................... 37
5.2.4
Retrospective ...................................................................................................................... 39
5.3
5.3.1
Planlægning ......................................................................................................................... 40
5.3.2
Udførelse ............................................................................................................................. 40
5.3.3
Kodeeksempler ................................................................................................................... 43
5.3.4
Retrospective ...................................................................................................................... 43
5.4
Sprint 3 ........................................................................................................................................ 44
5.4.1
Planlægning ......................................................................................................................... 44
5.4.2
Udførelse ............................................................................................................................. 45
5.4.3
Kodeeksempler ................................................................................................................... 48
5.4.4
Retrospective ...................................................................................................................... 50
5.5
6
Sprint 2 ........................................................................................................................................ 40
Sprint 4 ........................................................................................................................................ 51
5.5.1
Planlægning ......................................................................................................................... 51
5.5.2
Udførelse ............................................................................................................................. 52
5.5.3
Kodeeksempler ................................................................................................................... 55
5.5.4
Retrospective ...................................................................................................................... 56
5.6
Test.............................................................................................................................................. 56
5.7
Vurdering af processen ............................................................................................................... 57
Konklusion ........................................................................................................................................... 57
6.1
Videreudvikling ........................................................................................................................... 58
7
Referencer........................................................................................................................................... 59
8
Bilag ..................................................................................................................................................... 61
3
2 INDLEDNING
Under mit praktikforløb hos Cleverweb, blev vi enige om, at jeg skulle skrive min afsluttende
opgave hos dem. Det betød derfor, at jeg skulle lave noget i WordPress, da firmaet altid
benytter det til at lave webløsninger for deres kunder. Jeg fik muligheden for enten at lave et
theme eller et plugin. Jeg fandt ret hurtig ud af at jeg ville lave et plugin, til dels fordi jeg havde
fået god erfaring med at skrive plugins i min tid hos Cleverweb, men også fordi at themes
kodning er meget kompliceret, og noget jeg ikke har meget erfaring med.
Da jeg skulle vælge hvilken type plugin jeg ville lave faldt valget på et quiz plugin. Meningen
med opgaven er at give Cleverweb reklame, og måske endda tjene penge på det. Et godt plugin,
kan nemlig være med til at øge firmaets omdømme, og det ville være fint, da det er relativt
nyopstartet.
Cleverweb er en virksomhed i Odense, som laver webløsninger. Virksomheden består af to
personer: Martin Hjort, som er programmøren og Tommy Bæk Søgaard, som er designeren.
Cleverweb blev stiftet 1. april 2014. Før det blev til havde de to hver deres egen
enmandsvirksomhed. Martins hedder Spicy Web, og han bruger stadig det navn, når han skal
lave løsninger til kunder, hvor det ikke er nødvendigt at have Tommy med inde over. Det kan
f.eks. være hvis han skal ind og rette nogle ting på en hjemmeside. Men skal en hjemmeside
laves helt fra bunden er Tommy som regel altid med. På samme måde bruger Tommy stadig
navnet på hans egen virksomhed, Main Media, når Martin ikke behøver være inde over.
Når de laver løsninger for kunder bruger de altid WordPress, som er et Content Management
System. Grunden til de bruger det, er fordi det er meget brugervenligt, og samtidig kan det også
hjælpe kunderne med at vedligeholde deres sider, uden de behøver hjælp fra Martin
efterfølgende.
Måden de arbejder på er ofte sådan, at Martin står for alt programmeringen. Hvis kunden vil
have designet noget til siden, f.eks. et logo, nogle bannere etc., så er det Tommy der gør det.
Det er som regel Martin der får aftalerne på plads med kunderne. Derefter er det Tommy der,
sammen med kunden snakker om hvordan løsningen skal se ud designmæssigt og kommer med
4
forslag til hvordan det vil se bedst ud. På den måde har Martin også noget at gå efter når han
skal sætte siden op, hvilket gør hans arbejde meget nemmere.
Jeg var i praktik hos Cleverweb i perioden 1. september 2014 – 7. november 2014. Mens jeg var
i praktik lærte jeg at bruge WordPress, samt hvordan man kan udvide dens funktionalitet. Det
meste af praktiktiden brugte jeg på at lave plugins, til Martins private hjemmeside.
I denne rapport vil jeg beskrive hele processen vedrørende opgaven, som forløb over 9 uger
(10. november 2014 – 12. januar 2015).
2.1 OPGAVE
Som nævnt tidligere i afsnit 2, faldt valget på at lave et quiz plugin i WordPress. Når man
downloader dette plugin, kan man oprette sine egne quizzer, som man så kan dele på sin
WordPress side, så besøgende kan tage dem. Der er blevet sat følgende krav fra Cleverweb:




Brugeren skal kunne oprette deres egne quizzer
Den skal kunne køre på mobil og tablet
Brugeren skal kunne integrere på sociale medier og dele sine resultater (f.eks. på
Facebook)
Dem der tager quizzerne, skal kunne tilmelde sig nyhedsbrev på siden, hvor det er sat op
Det er derefter meningen at pluginnet skal lægges op på Internettet, så folk kan downloade det
og bruge det på deres WordPress side. Om det skal være gratis, eller koste penge at downloade
er Cleverweb stadig i tvivl om. Men uanset hvad, er det planen at det skal reklamere for
firmaet. Selvom firmaet har fået en god start vil de gerne reklamere for sig selv, da god
reklameværdi kan gavne dem.
2.2 PROBLEMFORMULERING
På baggrund af min opgave har jeg sat mig for at undersøge følgende:
Hovedspørgsmål:
Hvordan kan man implementere et quiz plugin i WordPress?
5
Underspørgsmål:







Hvordan gør man sådan spørgsmålene kan gemmes og redigeres?
Hvordan får man den sat ind på sin side efter den er lavet?
Hvordan integrerer man med sociale medier, såsom Facebook?
Hvordan gør man sådan brugere kan tilmelde sig nyhedsbrev?
Hvordan sikrer man sig brugere ikke kan snyde i quizzer, hvor der f.eks. er præmier på
spil?
Kan man tjene penge på et quiz plugin?
Hvordan foregår implementeringen bedst?
2.3 AFGRÆNSNING
Der vil først og fremmest lægges fokus på at få lavet et plugin med en masse forskellig
funktionalitet. Hvis Cleverweb har markeret visse funktioner som meget vigtige vil de
selvfølgelig få højt fokus fra start af. Men nogle af tingene vil dog blive skubbet til side.
En af de mest fremhævede her er det faktum at pluginnet skal kunne køre på mobil og tablet.
Det område er nærmere et designområde frem for et programmeringsområde, og jeg er ret
overbevist om jeg ikke har nok erfaring med den slags, til at nå at få det implementeret – i hvert
fald ikke uden at det går meget ud over min tid til de andre ting.
Nogle af områderne, såsom integrering med sociale medier og nyhedsbreve er også ret nye
områder for mig, men dem vil jeg dog prøve at få implementeret, da Cleverweb ønsker det
meget. Men det er dog ikke sikkert det ville kunne nås inden for projekttidsrammen.
Først og fremmest er det vigtigste dog at jeg har et plugin der virker efter hensigten, altså så
man kan oprette quizzer og sætte dem ind på sin side, og vælge mellem en masse features til
sin quiz. Derfor vil det være hovedfokus i opgaven.
6
3 METODEVALG
Dette afsnit beskriver hvordan jeg nåede frem til mit metodevalg, samt hvad jeg vil bruge under
mit projektforløb
3.1 BOEHMS PROJEKKORT
Da jeg skulle beslutte mig for metodevalg, var jeg allerede i forvejen mest til at vælge at gøre
det på den agile måde, frem for den plandrevne. Det skyldes bl.a. de erfaringer jeg har fået
tidligere på uddannelsen, samt det faktum, at plandrevne metoder ofte involverer, at der skal
laves meget dokumentation. Eftersom jeg kun havde 9 uger at gøre godt med, vurderede jeg, at
jeg simpelthen ikke kunne nå at lave så meget dokumentation som det kræves, især når jeg var
alene. Men for at argumentere for at det var bedst at arbejde agilt tog jeg udgangspunkt i
Boehms projektkort. Grunden til det, er at det er en hurtig og nem måde at få et indblik i
hvordan man bedst arbejder, samt jeg synes de faktorer som afgør det, er ret væsentlige. De
fem faktorer er følgende1:
Størrelse:
Dette punkt viser antallet af personer i projektgruppen. Store grupper er skræddersyede til den
plandrevne fremgangsmåde, da det kan være vanskeligt at holde den mundtlige
kommunikation mellem mange folk, og derfor kan meget dokumentation være med til at
hjælpe på det problem, især hvis hele holdet sjældent kan være samlet på samme sted.
Derimod passer den agile fremgangsmåde perfekt til meget små hold, da mundtlig
kommunikation er nemmere. Hele holdet er som regel samlet på samme sted ofte, eller hele
tiden, og derfor er dokumentation mindre vigtigt, da man som regel laver aftaler mundtligt.
Da jeg er alene om projektet skal jeg derfor have 1 på size-aksen.
Kultur:
1
Boehm-Agility-Disciplined – Homegrounds (PDF)
7
Her afgøres det om deltagerne trives bedst under kaos eller orden. Kaos er den arbejdsgang der
bygger på at man har disciplin til selv at administrere tiden og opgaverne. Hvorimod orden
bygger på, at man har det bedst med at tingene er struktureret og regelsat. Ved førstnævnte vil
agilt være det mest optimale, i modsætning til sidstnævnte hvor plandreven er det oplagte.
Udfra de erfaringer jeg har fået på uddannelsen, er jeg ret overbevist om, at jeg trives bedst
under kaos, og derfor får den 90% på culture-aksen.
Kritiskhed:
Dette er med til at vurdere hvor kritisk det ville være hvis systemet går ned. Hvis det f.eks. kan
medføre store økonomiske tab eller endda dødsfald, er det vigtigt at visse ting bliver overholdt
for at forhøje driftssikkerheden, så man undgår det går galt. Til det er plandrevne metoder det
bedste at anvende, da dokumentation og kravsspecifiktation kan være med til at formindske
risikoer, i modsætning til det agile hvor der kun er fokus på at lave det absolut nødvendige
dokumentation.
Da dette projekt er et quiz plugin, som laves med henblik på underholdning og et nedbrud
derfor ikke er en katastrofe, har jeg givet det værdien ”comfort” på criticality-aksen.
Dynamik:
Antallet af forventede ændringer til projektet er meget vigtigt når det skal besluttes hvordan
man vil arbejde. Agile metoder kan i højere grad nemmere håndtere ændringer, mens
plandreven er meget imod det, da dokumentation og krav til produktet, er nøje fastsat fra
starten af. Agile metoder tager, grundet sin mindre dokumentation, mere hensyn til pludselige
ændringer.
Jeg har givet den værdien 30 på projektkortet, da der kan komme en del ændringer. Ikke mindst
fordi firmaet har givet mig relativt stor frihed, med henblik på features, så jeg forventer, der vil
komme flere idéer i løbet af projektet.
Erfaring:
8
Endelig er der erfaring som bygger på hvilket niveau deltagerne i projektet befinder sig på. Der
er her tale om hvor stor erfaring deltagerne har i at arbejde med forskellige procesmodeller.
Dem med meget erfaring har bedre evner til at tilpasse og bruge forskellige procesmodeller.
Modsat, kan mindre erfarne have svært ved at tilpasse sig, og kan i værste tilfælde måske
endda være imod at anvende visse modeller. Hvis holdet består af et stor antal mindre erfarne
udviklere og få erfarne udviklere vil en plandreven fremgang passe bedst, mens et hold
bestående af mange erfarne medlemmer kan være god til en agil fremgangsmåde.
Jeg har givet det værdien 10/30 på aksen, da jeg har prøvet at arbejde med forskellige
procesmodeller. Dog mangler jeg måske en del erfaring, men jeg vurderer ikke at det vil
hæmme mig i dette projekt.
Udfra disse faktorer har jeg nu følgende resultat på projektkortet:
Figur 1 – Boehms projektkort - Kilde: Boehm-Agility-Disciplined - Homegrounds (PDF)
Boehms projekkort fungerer, som det anvises, at jo tættere projektet er på indersiden af aksen
jo mere taler det for at en agil fremgangsmåde er den bedste, og jo tættere det er på den ydre
akse, jo mere er en plandreven fremgangsmåde den mest fornuftige. Som det kan ses er alle
9
faktorer, i mit tilfælde, meget tættere på den indre akse. Derfor kan det konkluderes at jeg er
bedst tjent med at arbejde agilt under dette projekt.
3.2 XP
Extreme Programming, eller XP forkortet, er en agil planlægnings- og udviklingsmetode.
Meningen med den er at give bud på, hvad der skal gøres og hvordan det skal gøres. Værdierne
i XP er kommunikation, forenkling, feedback og mod. Når der arbejdes med XP er det derfor
vigtigt at projektets medlemmer overholder disse værdier, for at sikre en god arbejdsgang med
XP. Denne metode har også et vist antal praktikker, som kan beskrives således2:
Planning game:
Kunden er med til at planlægge. Det fungerer således at kunden skriver user stories, som skal
beskrive de forskellige krav til systemet. Når det er gjort skal udviklerne estimere hver story, så
man på den måde får en fornemmelse af, hvilke der kan laves hurtigt, og hvilke der tager lang
tid, og måske endda kan kræve research før de kan løses. Kunden skal derefter opdele de
forskellige stories i bunker, alt efter vigtighed, og når det er gjort skal udviklerne opdele de
forskellige stories i bunker, alt efter risiko. Derefter når udviklerne frem til en
udviklingshastighed, og kunden bestemmer så omfanget af et sprint, dvs. hvor lang tid der skal
gå før udviklerne skal have ny funktionalitet klar. Det er også kunden der bestemmer hvilke
stories der skal med i hvert sprint. Når kunden har udvalgt stories, skal udviklerne så opdele
hver story i tasks, og estimere dem.
Kort tid mellem releases:
Der vises jævnligt noget nyt funktionalitet, så man kan bevise, at der er fremgang i projektet.
Metafor:
2
XP planlægnings og programerings praktikker (PP), 4. semester
10
Der skal laves metaforer til tekniske begreber, så alle forstår dem. Det er især vigtigt når man
skal fremvise funktionalitet for kunder eller mennesker som måske slet ikke er inde i det
tekniske.
Simpelt design:
Her er der fokus på at designe tingene så simpelt så muligt. Hver gang udviklerne laver
funktionalitet skal de overveje om det kan gøres på en simplere måde.
Definér test first:
Der skrives test inden funktionaliteten kodes. Når testen så er godkendt skal koden refactoreres
i så høj en grad som den kan. Hvis testen så stadig er en succes kan koden godkendes. På den
måde sikrer man sig at koden er af ordentlig kvalitet med det samme, frem for at vente med
det til allersidst.
Refaktorering:
Koden skal løbende forbedres, f.eks. ved at fjerne duplikerede kode, gøre lange metoder
kortere osv.
Pair Programming:
To sidder ved samme computer og programmerer. Den ene laver koden, og den anden sidder
ved siden af som en slags observatør. Der byttes jævnligt.
Kollektivt ejerskab:
Alle har adgang til alt koden og ret til at ændre den.
Løbende integration:
Der skal ofte kompileres ny kode. Dvs. at i stedet for at skrive meget kode på en gang og vente
lang tid med at gøre det synligt for de andre, så gøres det som regel med 1 times mellemrum.
37 timers arbejdsuge:
11
Der arbejdes kun så længe hver dag, som der er aftalt. Dvs. når alle går hjem er det for at holde
fri, og der laves derfor ikke mere kodning resten af dagen.
Kundeinvolvering:
Kunden stiller kravene til produktet og der holdes jævnligt kontakt med kunden, i tilfælde af
ændringer, samt feedback.
Kodestandarder:
Der er fra start af enighed om hvordan koden skal skrives. Alle skal overholde standarden, for at
sikre at koden bliver ensartet.
3.3 SCRUM
Scrum er en anden tilgang til de agile principper. Her ligges der kun fokus på planlægning, i
modsætning til XP, som både har fokus på planlægning og programmeringsværktøjer.
Et Scrum hold består som regel af max. 7 personer. Der er følgende roller på holdet3:
Product Owner:
Denne person er en kunderepræsentant. Han sørger for at definere kravene til produktet og
sørger også for at prioritere de forskellige krav, når de er på plads. Det er også Product Owner,
der har det sidste ord, når funktionalitet skal godkendes. Hvis vedkommende ikke synes det er
godt nok, skal det laves om.
Scrum Master:
Denne person er et slags mellemled mellem Product Owner og resten af holdet. Det er ham der
sørger for at holdet overholder de aftalte praktikker og værdier, gennem projektet. Han
beskytter også holdet fra forstyrrelser udefra. Derudover er det også ham, der er taleren for det
3
Intro-SCRUM (pp), 4. semester
12
daglige stand-up møde, og som hver dag opdaterer burndown chart. Scrum Master må IKKE
forveksles med en leder, da Scrum bygger på selvstyrende hold.
Team:
Dette er resten af holdet. Folk under denne rolle, har intet ekstra ansvar ud over at udvikle
produktet. Det er dog vigtigt at alle overholder de forskellige aftaler, som der er lagt fra start,
men udover det er det op til folk selv, hvordan de føler de arbejder bedst.
Rutinerne i Scrum kan beskrives meget godt udfra denne illustration:
Figur 2 - Scrum begreber og proces – Kilde: Intro-SCRUM (pp), 4. semester
Artefakter:
Product backlog:
Denne laves i samarbejde med kunden. Det er en liste over alle de ting der ønskes til produktet,
i form af user stories. Rækkefølgen laves i form af prioritering, så de vigtigste ting, bliver lavet
før de mindre vigtige. Product Owner sørger for at vedligeholde backloggen.
13
Sprint backlog:
Det er listen over de ting der skal udføres i det pågældende sprint. De udvalgte stories brydes
ned i tasks, og hver mand i teamet får tildelt opgaver fra Sprint backlog og får nye efterhånden
som de bliver færdige med dem de startede ud med.
Burndown diagram:
Dette er en graf, som skal vise holdets fremdrift under sprints. Et eksempel på en burndown
kan ses her:
14
Figur 3 - Burndown chart – Kilde: Intro-SCRUM (pp), 4. semester
Den blå streg starter fra det antal timer/point, som holdet regner med at nå igennem når
sprintet er slut, og slutter ved 0. Den lilla streg skal opdateres hver dag og den starter samme
sted som den blå. Når en arbejdsdag er slut, trækker Scrum Master det antal timer/point som
holdet har udført i løbet af dagen fra og sætter det næste punkt udfra resultatet. Man kan på
den måde se om man er bagefter, eller foran tidsplanen, eller om man holder den som planlagt.
På den viste tegning kan man se at holdet er en anelse bagefter tidsplanen. Hvis man enten er
15
foran eller bagefter, bør man snakke om hvad man skal gøre for at man nemmere kan følge
planen fremover.
Ceremonier:
Sprint-planning:
Dette møde holdes før starten af et nyt sprint. Her fastlægges målet for sprintet, og der vælges
de stories, som skal laves.
Sprint review:
Her demonstrerer holdet, hvad der er gjort færdigt i løbet af sprintet. Efter reviewet skal det
gerne være klart, hvad der er godt, og hvad der skal tilbage i product backlog.
Stand up møde:
Dette møde afholdes hver dag, på samme tidspunkt hver gang. Her snakkes der om, hvad der
blev nået siden i går og hvad der skal nås i løbet af dagen. Hvis nogen er løbet ind i problemer
er der også mulighed for at komme ud med dem.
Retrospective:
Her evalueres sprintet. Der diskuteres bl.a. hvad der var godt og hvad der kan gøres bedre til
næste sprint.
16
3.4 PRAKSIS
Jeg har valgt at benytte visse ting fra Scrum og XP som mine metoder. Men da jeg er alene, er
det ikke muligt at anvende de to metoder til fulde, fordi visse ting enten er umulige at bruge
alene, eller ikke giver mening. Jeg kan f.eks. ikke have en Product Owner eller en Scrum Master.
Jeg vil lave en product backlog og bruge den under hele projektforløbet. Fordelen ved den er at
jeg altid kan ændre i den løbende, hvis der kommer nye idéer til produktet. Jeg vil også anvende
sprints, da jeg tror det vil være en god idé at ”presse” mig selv til at have ny funktionalitet klar
efter hver sprint. Det skal også sikre, at jeg har målsætninger, så jeg altid arbejder motiveret og
ikke går i stå. Planen er at hvert sprint skal foregå over en uge, minus weekender. Hvis det
senere viser sig, at en uge ikke er nok, kan jeg overveje at udvide længden af mine sprints.
Siden jeg anvender sprints, vil jeg også anvende sprint backlog. Det betyder, at jeg dagen før et
sprint-start udvælger de stories jeg vil have med i sprintet og deler dem op i tasks, og så bliver
de derefter estimeret. Da min plan er at arbejde 25 timer om ugen, altså 5 timer hver dag,
bliver de forskellige tasks delt op så den sammenlagte tid bliver til 25, eller tæt på.
Til at vise om mine sprints går efter planen, vil jeg benytte burndown charts. Det skal
dokumentere hvordan sprintet er gået. Hvis det ikke går som planlagt, kan jeg så overveje, hvad
der skal gøres anderledes næste gang.
Reviews kommer jeg nok ikke til at lave efter hvert sprint, da Cleverweb ikke kan garantere de
har tiden til det. Jeg vil dog benytte mig af dem, så ofte så muligt. Stand up møder vil jeg
selvfølgelig heller ikke benytte fordi jeg er alene.
Hver gang et sprint er slut vil jeg lave et retrospective, så det kan ses tydeligt hvad der var godt
og hvad der kunne gøres bedre til næste sprint.
Jeg vil også benytte nogle praktikker fra XP. Ligesom med Scrum, er der også her nogle som ikke
giver meninger, så jeg vil selvfølgelig kun bruge dem som giver mening for mig. Jeg kan f.eks.
ikke bruge pair programming eller kollektiv ejerskab, da det kræver at man er mere end én
person i gruppen. Jeg vil heller ikke benytte test first, da jeg stort set ingen erfaring har med at
skrive unit tests i WordPress. Men alle andre praktikker, end de nævnte, vil jeg forsøge at bruge
17
på en måde så jeg får mest muligt ud af forløbet. Jeg forventer dog ikke at XPs praktikker vil
blive fulgt i lige så høj grad som Scrums, da jeg er alene og det derfor er nemmere at arbejde på
min egen måde. Men samtidig føler jeg, at jeg alligevel bør have nogle regler, så det ikke ender i
det rene kaos, og da jeg før har arbejdet med stor succes under XP, vil jeg igen benytte mig af
det.
4 TEKNOLOGIVALG
Dette afsnit vil beskrive de tekniske valg til projektet og hvorfor jeg har valgt dem.
4.1 WORDPRESS
WordPress er et Content Management System (CMS), som er skrevet i PHP. CMS bruges til at
gøre det nemmere at opbevare, udgive og ændre indholdet af dokumenter og filer. CMS er især
populært når man skal lave hjemmesider, da det kan spare en for en masse tidskrævende
arbejde.4
WordPress har eksisteret siden 2003 og blev oprindeligt lavet til udelukkende at blogge. I dag er
WordPress’ interface stadig bygget op omkring blogging, men det har dog udviklet sig meget
siden det startede. I dag bruges det af mange folk til at lave websider med, og det bruges af
mere end 60 mio. websider.5
WordPress er også meget nemt at sætte op. Det eneste man skal have klar, inden man gør det
er sin egen MySql database. Derefter skal man downloade WordPress som zip, og smide alle
filerne op på sin websides server, via en File Transfer Protocol (FTP). Når man så første gang går
ind på siden, efter man har lagt WordPress filerne ind, vil den køre en installationsguide, hvor
man tilslutter sin database, og derefter får lavet en administrator bruger til sig selv.6
4
https://en.wikipedia.org/wiki/Content_management_system
http://www.forbes.com/sites/jjcolao/2012/09/05/the-internets-mother-tongue/
6
http://codex.wordpress.org/Installing_WordPress
5
18
Når man så skal sætte sin side op kan man selv kode sig et theme, men der er også et stort
udvalg af forskellige themes til forskellige behov. Nogle af dem er gratis at hente, mens andre
koster penge. Hvis man f.eks. vil sætte en webshop op, er der lavet forskellige themes til det.
Og man kan til enhver tid, skifte over til et andet theme.7
Selvom WordPress’ funktionalitet også har begrænsninger er der mulighed for at udvide den,
ved at bruge plugins. Ligesom der findes tusindvis af themes til WordPress, findes der også
mange plugins. Man kan selvfølgelig også selv lave plugins, hvis man har forstand på
programmering.8
WordPress benytter sig også af user roles. Det betyder, at når en ny bruger oprettes på siden,
får han tildelt en rolle, som bestemmer hvor mange rettigheder han har. Typisk vil en side, hvor
besøgende kan registrere sig som brugere, kun få en meget begrænsede rolle som Subscriber
eller Contributor. Det betyder at de f.eks. ikke kan gå ind og ændre på indhold til websiden,
men kun ændre på deres egen profil. På den måde kan man bestemme, hvem der kan ændre på
websiden. En administrator kan dog til hver en tid ændre andre brugeres roller.9
Selvom der findes andre CMS har WordPress været et nemt valg for mig, da det er det som
Cleverweb benytter hver gang de skal lave webløsninger til kunder. Derfor var andre CMS aldrig
til overvejelse, og jeg vil derfor ikke sammenligne WordPress med andre systemer.
4.1.1
Databasestruktur
Når man sætter sin WordPress hjemmeside op, opretter den selv tables i den database man har
tilsluttet til siden. WordPress har en bestemt databasestruktur. Man kan sagtens selv oprette
sine egne tables, men hvis det er muligt, skal man helst undgå det, og bruge de tables, som
WordPress selv opretter.
Følgende er et diagram af WordPress’ databasestruktur:
7
http://codex.wordpress.org/Themes
http://codex.wordpress.org/Plugins
9
http://codex.wordpress.org/Roles_and_Capabilities
8
19
Figur 4 - WordPress database struktur – Kilde: WordPress codex
Her er en beskrivelse af de forskellige tables10:
10
http://codex.wordpress.org/Database_Description
20
wp_users: Dette table indeholder de forskellige brugere som er tilknyttet den pågældende
WordPress side.
wp_usermeta: Dette table indeholder vigtige informationer om de forskellige brugere. F.eks.
deres for- og efternavn, deres nickname, eller en beskrivelse af dem osv.
wp_posts: Dette table er nok det allervigtigste i WordPress’ struktur. Det indeholder alle de
posts og sider, som er oprettet på den pågældende WordPress side. Det er også her de
forskellige quizzer, som folk opretter, kommer til at blive gemt.
wp_postmeta: Dette table indeholder vigtig info tilknyttet de forskellige posts. Det er i dette
table ting som spørgsmål, indstillinger og resultater til de forskellige quizzer gemmes.
wp_comments: Dette table indeholder kommentarer tilknyttet de forskellige posts. Som bruger
kan man komme med kommentarer til posts, hvis admin har givet tilladelse til det.
wp_commentmeta: Dette table indeholder information om de forskellige kommentarer.
wp_links: Dette table indeholder information om de links man har indtastet i WordPress’ link
feature. Det er dog en funktion der er blevet fjernet fra de nyere versioner af WordPress, men
som er mulig at genoprette, med et plugin.
wp_options: Dette table indeholder de indstillinger som er valgt under ”options” inde i
administration panelet.
wp_terms: Dette table indeholder de kategorier som kan tildeles posts og links.
wp_terms_relationships: Dette table indeholder de forskellige associationer mellem kategorier
og posts/links.
wp_terms_taxonomy: Dette table indeholder beskrivelser af de forskellige kategorier/links.
4.2 PHP
PHP: Hypertext Preprocessor, eller ganske simpelt PHP, er et server-side programmeringssprog.
Det betyder, at alt kode der er skrevet i PHP eksekveres på serveren, før det sendes over til
browseren. PHP bruges mest til webprogrammering, hvor det bl.a. bruges til at generere HTML
21
med. Når folk indtaster en webside adresse i deres browser sender de en forespørgsel til
websiden på den indtastede adresse. Websiden finder så sidens HTML fil og sender den hen til
browseren, som så opbygger en side, ud af HTML koden i filen. Man kan beskrive forholdet
mellem en browser og en webside som et client-server forhold, hvor browseren er client og
websiden er serveren. Og fordi PHP kode ikke eksekveres i browseren er det derfor et serverside sprog.
Det kan derfor med fordel bruges til at loade de elementer, du ved skal være der fra starten af
når siden loades. Og fordelen ved at bruge PHP, frem for ren HTML er også, at man ikke skal
opdatere HTML koden konstant hver gang der skal ske ændringer. Så hvis man f.eks. skal lave
en webside til en kunde, der ikke har forstand på programmering, ville det være så godt som
umuligt for ham at opdatere siden, uden hjælp fra en programmør. Med PHP kan man f.eks.
gemme ting i en database, og hente dem ud igen, når der er brug for dem. PHP hjælper også
med at undgå store mængder gentagende HTML. Hvis man f.eks. ønsker ens header og footer
skal være ens, lige meget hvilken sektion af ens side, som bliver vist, så kan man bruge PHP til at
lette det arbejde. Ved ren HTML ville man være nødt til at skrive alt HTML til header og footer, i
hver eneste HTML dokument.11
Grunden til valget er faldt på PHP som server-side sprog i mit projekt, er at WordPress er
skrevet i det sprog, og at det derfor er et naturligt valg.
4.3 JAVASCRIPT
JavaScript er et dynamisk programmeringssprog. I modsætning til PHP er det et client-side
sprog, som betyder at alt koden eksekveres i browseren. Det kan derfor bruges til at ændre
tingene efter en side er færdigloadet, uden man behøver at lave en forespørgsel til serveren.
Fordelen ved det er at det ikke behøver at reloade siden, for at ændringer kan træde i kraft, og
det er derfor med til at give brugerne en bedre oplevelse.12
11
12
https://en.wikipedia.org/wiki/PHP
https://en.wikipedia.org/wiki/JavaScript
22
4.3.1
jQuery
En anden god ting ved JavaScript er at det har nogle libraries som gør webudvikling lettere. Et af
disse libraries er jQuery, som er det mest anvendte library i JavaScript. JQuery fungerer på den
måde at det anvender selectors. Hvis man ønsker at manipulere et element, kan man bruge en
jQuery selector til at få fat i elementet og derefter bruge funktioner i jQuery til at ændre
elementet. Det kan også bruges til at ændre elementer alt efter brugerens handling. F.eks. kan
du gøre elementer usynlige/synlige, når brugeren trykker på en bestemt knap. JQuery er meget
brugervenligt, og indeholder en del nyttige funktioner, som gør tingene meget nemmere i
forhold til hvis du skrev ren JavaScript. Ud over det fungerer det også på alle browsere, samt
mobilplatforme.13 14
JQuery er meget anvendt i mit projekt de steder, hvor visse elementer først skal dukke op eller
forsvinde, når brugeren udfører bestemte handlinger.
4.3.2
AJAX
Asynchronous JavaScript and XML, eller AJAX, er en samling af webteknikker, som bruges til at
lave asynkronisk udveksling af data mellem client og server, så siden dermed ikke behøver at
reloade.
Det kan f.eks. bruges til at sende data til serveren, som så kan gemme dem, uden brugeren
overhovedet har en idé om at det sker. Det kan derfor med fordel bruges til at lave mere
interaktive websider. Hvis man f.eks. brugte en POST form, til at sende dataen ind i stedet, ville
det betyde at siden var nødt til at reloade og sende brugeren en ny side. Det ville passe fint, til
store ændringer, men til meget små ændringer, er det ikke optimalt, da det tager tid at udføre,
og derfor bør man i stedet overveje AJAX til at løse opgaven.15
I mit projekt har jeg anvendt AJAX til at gemme resultater og quiz states.
13
https://en.wikipedia.org/wiki/JQuery
http://www.jscripters.com/jquery-disadvantages-and-advantages/
15
https://en.wikipedia.org/wiki/Ajax_(programming)
14
23
4.4 OVERVEJELSER
Under mit forløb var der også nogle ting der blev taget til overvejelse. Dette afsnit vil beskrive
dem.
4.4.1 Ingen JavaScript?
I afsnit 4.3 kommer JavaScript til at fremstå som et ret uundværligt sprog til webudvikling. Og
selvom meget taler for at man skal bruge det, så er der alligevel en grund til at overveje at lave
sådan at ens webservice virker uden JavaScript: Alle browsers giver nemlig brugeren
muligheden for at slå JavaScript fra! Hvis man så slet ikke har taget hensyn til folk der ikke har
JavaScript slået til, vil det i mange tilfælde være så godt som umuligt for dem at få noget ud af
ens webservice.
En mulighed kunne være først at lave sådan servicen virker uden brug af JavaScript. Det vil i
mange tilfælde betyde, at man skal gøre sådan siden reloades, hver gang der skal nyt indhold
på. Når så man har gjort sådan, at det fungerer uden JavaScript, kan man implementere det
som en slags ”bonus” til dem der har det slået til. Der er ingen tvivl om at det optimale ville
være at siden skal reloades, så få gange så muligt. Derfor ville det være en dum idé helt at
droppe brugen af JavaScript i hvert tilfælde.
Jeg besluttede mig dog for ikke at tage hensyn til folk uden JavaScript. Den største grund til det
var at jeg ikke følte det ville være et stort tab, da en undersøgelse viser at kun 1,1% af verdens
befolkning ikke bruger JavaScript.16 En anden grund var, at jeg var overbevist om det ville tage
længere tid, og at jeg derfor måske ikke kunne nå at lave lige så meget i projektperioden.
Cleverweb mente heller ikke det var nødvendigt at tage hensyn til det. Hvis de havde ønsket det
havde jeg selvfølgelig hørt efter, men da de var enige med mig, så jeg ingen grund til at
overveje det yderligere.
4.4.2 Cookies vs. local storage
Da en webside er det man kalder state less, altså at den glemmer alt information den har fået
omkring brugeren når forbindelsen lukkes ned, var det nødvendigt at overveje brug af teknologi
der kunne løse det problem.
16
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/
24
Cookies og local storage er en måde at gemme data fra brugeren. Men i stedet for at gemme sig
i en database på serversiden, gemmes det på klient siden. På den måde kan den pågældende
data bruges igen, næste gang brugeren besøger websiden.
Da jeg skulle vælge hvilken af de to jeg ville bruge var det vigtigt at kigge på forskellen mellem
dem først og fremmest.
Cookies er små tekst filer der kan indeholde data fra brugeren, som gemmes på vedkommendes
egen computer. Når brugeren så besøger websiden igen, kan cookien indlæses og dermed kan
servicen hente data omkring brugeren og bruge det igen. Fordelen ved cookies er at de også
kan læses på server siden. Det vil sige man både kan læse, og oprette cookies på server siden og
klient siden. Ulempen er at cookies ikke kan rumme store mængder data af gangen. Grænsen
går til 4096 KB. Derudover trækker cookies også ned i hastigheden.17
Local storage gemmer brugerens data i vedkommendes browser. Princippet i local storage er
det samme som med cookies, i og med meningen er at gemme data, som så kan huskes næste
gang brugeren besøger websiden. Fordelen ved local storage er at det kan rumme meget større
mængder af data end cookies kan. Mængden af tilladt data i local storage styres af browseren,
men som regel kan den rumme op til 5 MB. En anden fordel ved local storage er også at den
ikke trækker ned i hastighed som cookies gør. Men tilgengæld kan den kun loades på klient
siden, så hvis man har brug for at tjekke op på data på server siden, kan man ikke bruge local
storage.18
Efter at have overvejet de to ting, og kigget på fordele og ulemper faldt mit valg på cookies.
Grunden til det er, at jeg har behov for at lave et tjek på server siden. Desuden er det meget
små mængder data jeg skal bruge, så derfor vil der ikke være nogen fare for at overskride
grænsen. Den eneste ulempe i mit sted er at det trækker ned i hastighed, men i den her
situation er det dog noget jeg må leve med. Det jeg skal bruge cookies til er at huske quizzens
17
18
http://www.w3schools.com/js/js_cookies.asp
http://www.w3schools.com/html/html5_webstorage.asp
25
tilstand, på de mindre vigtige quizzer. Derudover skal cookies også bruges til at tjekke om
brugere der ikke er logget ind, allerede har taget quizzen.
26
5 PROCESSEN
Dette afsnit vil beskrive hvordan arbejdet med projektet gik. Da jeg havde valgt at benytte
Scrum som metode, vil jeg beskrive de forskellige sprints en efter en.
5.1 SPRINT 0
Inden arbejdet kunne gå i gang skulle det planlægges ordentligt. Derfor blev der afholdt et
sprint med fokus på planlægning udelukkende.
5.1.1
User Stories
Tidligt i forløbet lavede jeg en aftale med ejeren af Cleverweb om et møde. Under mødet skulle
vi sammen planlægge funktionaliteten til pluginnet. Der blev først og fremmest sat fokus på, at
det skulle være sådan at folk kunne oprette spørgsmål og sætte dem ind på deres side.
Cleverweb ønskede også at man kunne integrere med sociale medier som Facebook, og
tilmelde sig nyhedsbreve, da der ville være stor reklameværdi i det. At det kunne køre på mobil
var også et ønske.
Derudover blev der foreslået en masse andre features, såsom statistik, mulighed for at sætte
tid på quizzen, opdele de forskellige quizzer i kategorier osv. Det blev dog aftalt, at jeg også
gerne selv måtte finde på nye features, hvis jeg pludselig fik idéer. Mødet skulle ikke ses som et
hvor alting skulle på plads med det samme, men blot som noget der kunne hjælpe mig i gang.
Derfor kom der selvfølgelig også løbende nye stories til min product backlog.
5.1.2
Udviklingsmiljø
Det blev besluttet at udviklingen skulle foregå i Sublime Text 2, som er en kodeeditor. 19
Grunden til at valget faldt på den, er mine erfaringer med at bruge den. Jeg har brugt den hver
gang jeg har udviklet ting til WordPress, og har kun haft gode oplevelser, så jeg så ingen grund
til at skifte.
19
http://www.sublimetext.com/2
27
Til at håndtere versionsstyring har jeg valgt SubVersion (SVN)20 som værktøj og Google Code
som host. Ligesom mit valg af udviklingsværktøj, har jeg også gode erfaringer med SVN, så jeg
overvejede heller ikke andre værktøjer til versionsstyring.
Cloud-tjenesten Dropbox er blevet anvendt til at håndtere dokumentation.21 Da jeg er alene,
bruges det mest som backup, så jeg ikke risikerer at miste vigtige ting til rapporten, da der ikke
er behov for vidensdeling mellem gruppemedlemmer.
5.1.3
Test
For at teste mit plugin har jeg brugt værktøjet XAMPP.22 Det gør at min egen computer kan køre
som server lokalt. Det betyder, at jeg kan sætte en WordPress side op på localhost. Fordelen
ved det er at jeg ikke behøver betale for et live domæne. Siden det er lokalt, behøver jeg heller
ikke adgang til nettet, så hvis nettet skulle være nede, vil det stadig være muligt for mig at
teste. En anden fordel er også at det går hurtigere i forhold til hvis jeg testede online. XAMPP
tilbyder også brugen af phpMyAdmin lokalt, så derfor er det også nemt at oprette egne MySql
databaser til sine localhost sider.
Ud over det er det også planen at jeg vil anvende brugertests, så andre, som ikke kender
pluginnets funktionalitet, kan teste det og komme med inputs.
5.1.4
Arkitekturvalg
Det tog lidt tid før jeg besluttede mig med hensyn til valg af arkitektur. Da jeg begyndte
planlægningen af projektet var det i starten meningen at jeg ville bruge det populære ModelView-Controller (MVC).23 Det skyldes, at jeg gennem hele uddannelsen har været meget vant til
objekt orienteret programmering, hvor tingene er opdelt i forskellige lag. Men efter nogle
undersøgelser gik det op for mig at MVC arkitekturen ikke var skabt til at lave et WordPress
plugin med. Eller man kan også sige det omvendt: WordPress er ikke skabt til at bruge MVC.24
Det skyldes måden WordPress er opbygget på. WordPress benytter sig af hooks, til at udføre
funktionalitet. De fungerer lidt ligesom en delegate: Man kan tilføje metoder til dem, og når så
20
https://subversion.apache.org/
https://www.dropbox.com/home
22
https://www.apachefriends.org/index.html
23
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
24
https://tommcfarlin.com/wordpress-and-mvc/
21
28
udløser den, udføres alle de metoder som er under den bestemte hook. I WordPress er der sat
en del hooks op til forskellige situationer. Når man så koder et plugin, kan man tilføje sine egne
metoder til de eksisterende hooks.25 26 27 Det er selvfølgelig også muligt selv at lave hooks, men
det bruges som regel mest under themekodning.
Udfra det her kan jeg derfor konstatere at WordPress er bygget op omkring en event-driven
arkitektur.28 Det vil dermed sige at det fungerer på den måde at WordPress ændrer på tingene
når visse events foretager sig. Den har så de forskellige hooks til at ”holde øje” med hvad
brugeren foretager sig. Når en hook ”opdager” en bestemt ting brugeren foretager sig, så bliver
alle de funktioner den har gemt i sig, udløst.
Da WordPress derfor ikke er opbygget til MVC, synes jeg derfor det ville være spild af tid at
prøve og indrette det efter det. Selvfølgelig ville det ikke være umuligt, men jeg synes ikke det
er det værd, og når WordPress er bygget op omkring en bestemt måde at gøre tingene på synes
jeg det ville være dumt at trodse det. Min arkitektur til mit plugin kommer derfor til at se sådan
her ud:
25
http://codex.wordpress.org/Plugin_API
http://codex.wordpress.org/Plugin_API/Action_Reference
27
http://codex.wordpress.org/Plugin_API/Filter_Reference
28
https://en.wikipedia.org/wiki/Event-driven_architecture
26
29
Figur 5 - Plugin arkitektur
Som det kan ses på figuren betyder det, at jeg tilføjer funktioner til hooks, som så sørger for at
udføre alle dens funktioner når den udløses. Hvornår de forskellige hooks udløses, kommer an
på hvilken type hook det er. F.eks. er der en hook som hedder init, som udføres efter
WordPress siden er færdigloadet. Det betyder, at jeg kan tilføje funktioner som jeg først ønsker
udføres efter siden er loadet, til den hook.
Herunder er et eksempel på hvordan hooks tilføjes:
Figur 6 - Anvendelse af hooks
Det første argument er navnet på den hook som metoden skal ind under, og det næste er den
metode der tilføjes til den pågældende hook.
30
5.1.5
Domænemodel
For at give bedre overblik over min struktur blev der også lavet en domænemodel i sprintet.
Det skal dog nævnes at den flere gange blev ændret undervejs efterhånden som jeg blev
klogere omkring mit projekt. Men den endelige model endte med at se sådan her ud:
Figur 7 - Domænemodel
I forhold til databasestrukturen (se afsnit 4.1.1) vil Quiz være det der gemmes som post. Alle de
andre er så postmeta, som dermed kan knyttes til denne post, udover User, som jeg ikke
håndterer i mit plugin. Jeg benytter dog userName visse steder, så derfor mente jeg den også
skulle med på modellen, men selve håndteringen af User ordnes ikke af mit plugin.
Result bruges til at kunne vise statistik. State bruges til at gemme quizzens tilstand, i tilfælde af
at brugeren ikke gør den færdig med det samme. På den måde kan den reloade fra den tilstand
brugeren forlod den i, så vedkommende ikke behøver starte quizzen forfra.
31
Setting kan måske være lidt svær at se hvordan fungerer udfra modellen. Måden det styres på
er at alle de forskellige settings har deres egen value. Man kan så tjekke om indstillingen er
slået til, ved at tjekke op på om dens unikke value eksisterer. Hvis den gør det er indstillingen
slået til, og det er så modsatte tilfælde, hvis den ikke eksisterer.
5.1.6
Risikoanalyse
Når man starter på et udviklingsprojekt kan det ikke undgås at der er forskellige ting der kan
risikere at komme i vejen for at projektet forløber som planlagt. Nedenunder er vist en såkaldt
risikoanalyse over de problemer som kan opstå og hvor alvorlige de er. Sandsynlighed er hvor
stor risikoen er for at problemet opstår og er givet fra 1 til 10, hvor 1 betyder chancen for at det
sker er nærmest ikke-eksisterende og 10 betyder at det er uundgåeligt at det vil ske. Effekt er
hvor stor en katastrofe det er for projektet, hvis det sker. Den er også givet fra 1 til 10, hvor 1
betyder det nærmest er ligegyldigt hvis det sker, og 10 betyder det kan koste meget dyrt i
arbejdsfremgangen. Ranking er sandsynlighed gange med effekten, og risikoerne vil blive
sorteret efter den.
Beskrivelse
Sandsynlighed
Effekt
Ranking
Stories bliver
9
5
45
3
9
27
2
10
20
Sygdom
2
9
18
Googles server går
1
4
4
underestimeret
Forhindres i at
arbejde på en
sprintdag
Computeren går i
stykker
ned
Mange af disse risikoer er baseret på det faktum at jeg arbejder alene. Det betyder at det f.eks.
ville være en katastrofe, hvis jeg pludselig står uden en computer, eller hvis jeg forhindres i at
32
arbejde visse dage, da der ikke er andre til at lave arbejdet. Det ville i så fald betyde arbejdet
ville gå i stå. Som det kan ses vurderes de fleste af tingene dog ikke som sandsynlige, så det
forventes ikke de forekommer. Det som er mest sandsynligt vil gå galt er at jeg underestimerer
stories, da jeg ikke har erfaring med at arbejde agilt alene. Det er dog ikke en kæmpe
katastrofe, da agilt netop taler for at man kan tillade sig at lave ændringer undervejs. Dog vil
det stadig have en vis generende effekt.
Jeg medtog også det faktum at Googles server kan gå ned, da det er dem der er host for min
konfigurationsstyring. Skulle jeg dog være så uheldig at det skete er det i mit tilfælde dog ikke
ligefrem en katastrofe, da jeg er alene, og derfor mest bruger konfigurationsstyring til at sikre
mig at jeg ikke mister koden. Havde jeg samarbejdet med nogen havde det været noget andet,
da vi så ikke kunne committe ændringer, og det i så fald ville sænke arbejdsfremgangen.
5.1.7
Kodestandard
Jeg vil benytte mig af WordPress’ egen kodestandard.29
Ud over det vil jeg lave alt koden på engelsk, selvom mit interface bliver på dansk i første
omgang.
5.2 SPRINT 1
5.2.1
Planlægning
Efter sprint 0 var overstået, og forberedelserne til projektet dermed var på plads, var det tid til
at starte på arbejdet. Først og fremmest valgte jeg at lave de stories som var vigtigst for at dette
plugin gav mening. Det betyder man selvfølgelig skulle være i stand til at oprette en quiz, med
spørgsmål og svar. Og så skulle quizzen selvfølgelig kunne smides ind på en side, så besøgende
kunne tage den. Jeg udvalgte de stories jeg ville arbejde på under dette sprint og delte dem alle
op i tasks, sådan at de blev mere overskuelige. Min backlog for dette sprint endte med at se
sådan ud:
29
https://make.wordpress.org/core/handbook/coding-standards/
33
Figur 8 - Sprint 1 backlog
5.2.2
Udførelse
Indledningsvis gik jeg i gang med at gøre sådan man kunne oprette en quiz. Det gik fint nok i
starten, men jeg løb ind i en del problemer, da jeg skulle gøre sådan at spørgsmålene kunne
gemmes. Det kostede mig en del ekstra arbejde på den story. Det der gik galt var at jeg ikke
kunne få den til at gemme de dynamiske ting. Altså, f.eks. spørgsmål som brugeren havde
tilføjet, og svarene til dem. Det fungerede nemlig sådan at brugeren kunne trykke på en knap
når han ønskede at tilføje et nyt spørgsmål, og på samme måde når der skulle tilføjes nye svar
til de forskellige spørgsmål. Havde det været statiske elementer, havde det nok ikke været lige
så svært.
Figur 9 - Quiz i backend
34
Pga. det nåede jeg kun at lave en yderligere story, og det blev den der gjorde at man kunne
lægge en quiz ind på siden. Måden det blev gjort på, var ved hjælp af en shortcode. Den
fungerer sådan, at når admin har oprettet en quiz, får quizzen en shortcode genereret. Hvis
admin, så laver en ny side og sætter den shortcode ind i sidens editor, så bliver quizzen lagt ind
på den pågældende side. Admin behøver på den måde ikke selv lave noget kode.
Figur 10 - Detaljeoversigt af quiz
Herunder ses hvordan quizzen ser ud i front end:
Figur 11 - Quiz i front end
35
Figur 12 - Oversigt over spørgsmål i front end
Min burndown kom til at se således ud:
Burndown - Sprint 1
30
25
Point
20
15
Estimeret
Aktuelt
10
5
0
0
1
2
3
Dag
Figur 13 - Burndown sprint 1
36
4
5
Som det kan ses, bremsede den første story mig en del, pga. de problemer jeg løb ind i. Derfor
flyttes de to resterende stories over til det næste sprint.
5.2.3
5.2.3.1
Kodeeksempler
Opret quiz
Som nævnt i afsnit 6.1.5 skal en quiz oprettes og gemmes som en post. Når man laver sine egne
post types kaldes de custom post types. WordPress har en indbygget funktion til at oprette sine
egne post types. Herunder kan ses hvordan den er opbygget:
Figur 14 - Implementering af quizzez post type
Ved så at tilføje min funktion til en bestemt hook (i dette tilfælde init), så udløses denne
metode hver gang WordPress er færdigloadet. Det betyder så, at Quizzer nu kan oprettes i
WordPress’ backend.
5.2.3.2
Gem quiz
For at være i stand til at gemme quizzen, gjorde jeg først sådan, at de forskellige værdier
(såsom spørgsmål, svar osv.) blev gemt i JavaScript arrays, når man trykkede på ”gem”
knappen.
37
Figur 15 - Tilføjelse af arrays til at gemme med
Fordi alle tingene var inde i en form og ”gem” knappen fungerede som en submit knap, kunne
jeg bruge $_POST til at få fat i de ting, som var blevet gemt i de forskellige arrays og dermed
sende dem til databasen.
Figur 16 - Implementering af en funktion til at gemme med
Denne funktion udløses hver gang man bruger ”gem” knappen inde i en quizzes post type.
Update_post_meta, gør enten det at den gemmer de forskellige ting i det pågældende array, i
38
databasen, eller erstatter dem, hvis den key, som de har allerede findes i forvejen. På den måde
kan man altså også overskrive spørgsmål, hvis det er nødvendigt.
5.2.3.3
Indsæt quiz
For at kunne få quizzen sat ind på en side skal folk, som nævnt i afsnit 5.2.2 bruge en såkaldt
shortcode. Den genereres efter at man har oprettet quizzen. For at genere en shortcode har jeg
brugt en function der hedder add_shortcode(), som laver en hook, man kan bruge når man skal
have elementer ind på en side, på en nem måde. Det fungerer på den måde at vedkommende
skal bruge den pågældende quiz’ post ID. Hvis det f.eks. er 32, kan vedkommende blot sætte
det her ind i page editor: [hm-quiz id = 32], og så kommer hele quizzen automatisk ind på den
pågældende side. For at gøre det muligt har jeg gjort følgende:
Figur 17 - Implementering af shortcode
Ved så at hente alle posts af typen quizzes ud af databasen kan man finde den post der har det
ID, som er angivet i shortcoden, ved hjælp af et foreach loop. Hvis den så finder en der matcher
stopper loopet og quizzen bliver gemt i en variabel, således at man har mulighed for at lave
opsætningen af quizzen i front end.
5.2.4
Retrospective
Første sprint gik ikke efter planen og den hovedsaglige grund til det skal findes i at jeg nok
skulle have foretaget et spike inden jeg begyndte. Et spike omkring det at få den til at gemme i
WordPress’ backend, havde uden tvivl gjort stor nytte. Men som nævnt tidligere i afsnit 5.2.2
39
kom det bag på mig hvor svært det egentlig var at få den til at gemme dynamiske elementer.
Jeg havde uden tvivl underestimeret den story.
En anden ting jeg også fremover vil prioritere er at få lavet en story færdig samme dag som jeg
starter den. Selvfølgelig vil der sikkert være tilfælde, hvor jeg må erkende, at det ikke kan lade
sig gøre. Men da min burndown siger at jeg skal brænde 5 point ned om dagen, vil det være det
mest optimale at gå efter. Og i de tilfælde hvor det ikke kan lade sig gøre at lave en story færdig
på én dag, vil jeg gå efter i hvert fald at afslutte de tasks som er påbegyndt på dagen. Hvis det
ikke kan overholdes bliver burndown nemlig hurtigt svær at lave sådan den giver et korrekt
billede på hvordan processen er forløbet. Det vil jeg meget gerne undgå til mine fremtidige
sprints.
5.3 SPRINT 2
5.3.1
Planlægning
Først og fremmest skulle de stories som ikke blev nået i forrige sprint, laves i dette sprint. Det
her sprint kom primært til at gå ud på at få tilføjet flere features til mit plugin. Efter sprint 1 var
færdig kunne det nu lade sig gøre at oprette en quiz og putte den ind på sin side. Men jeg ville
gerne gøre sådan man kunne få vist sit resultat, efter quizzen og vælge om quizzen skulle kunne
tages mere end én gang etc. Min backlog for dette sprint så sådan her ud:
Figur 18 - Sprint 2 backlog
5.3.2
Udførelse
Jeg fortsat hvor jeg slap fra sprint 1, og fokuserede på at gøre de to stories, som jeg ikke nåede i
sprint 1, færdige. Det forløb uden problemer. Derefter ville jeg gøre sådan at quizzen kunne
beregne resultatet, da jeg så det som en ret vigtig feature. Jeg vurderede nemlig, at hvis ikke
40
folk kunne se deres resultat, så ville meningen med det at tage en quiz være nytteløst på visse
områder.
For også at gøre det nemmere for admin at finde rundt i sine quizzer ville jeg give ham
mulighed for at oprette forskellige kategorier. Når så han havde sat en quiz ind under en
kategori ville han have muligheden for at få vist alle quizzer med en bestemt kategori.
Jeg havde også besluttet mig for at visse features ville fungere på den måde at admin, selv
kunne vælge om de skulle slås til eller fra. I dette sprint lagde jeg ud med at give muligheden for
at vælge quiz opsætning, om quizzen måtte tages mere end én gang, og muligheden for at
sætte tid på quizzen. De to ting blev også betragtet som vigtige faktorer i at undgå brugere
kunne snyde i konkurrencer. Hvis der var tid på ville det f.eks. være sværere at nå at søge på
nettet efter svar på spørgsmålene, og hvis quizzen ikke kunne gentages ville man ikke kunne
forbedre sit resultat efter at have taget quizzen én gang.
Figur 19 - Udvalg af indstillinger til quiz
Min burndown for dette sprint endte sådan her:
41
Burndown - Sprint 2
30
25
Point
20
15
Estimeret
Aktuelt
10
5
0
0
1
2
3
4
5
Dag
Figur 20 - Sprint 2 burndown
Som det kan ses, gik det meget bedre denne gang i forhold til forrige sprint. Jeg nåede stort set
det hele, men jeg blev desværre forhindret i at arbejde den sidste dag i dette sprint, så den
story som jeg ikke nåede valgte jeg at overføre til næste sprint.
42
5.3.3
5.3.3.1
Kodeeksempler
Tidsmåler
Tidsmåleren blev lavet ved hjælp af denne metode30:
Figur 21 - Implementering af tidsmåler
Metoden er skrevet i JavaScript. ClearInterval er en indbygget metode i JavaScript som sørger
for at stoppe måleren, når quizzen er færdig eller tiden er gået.31 Hvis brugeren ikke når at
færdiggøre quizzen inden den når 0, vil den gemme resultatet af de svar som vedkommende
nåede at besvare, og resten beregnes automatisk som forkerte.
5.3.4
Retrospective
At dette sprint gik bedre skal nok ses i at jeg denne gang ikke løb ind i forhindringer, som den
jeg kom ud for i forrige sprint. Grunden til det er at de udvalgte stories, var korrekt estimeret
denne gang. Jeg synes også idéen med at gøre stories/tasks færdige den dag de blev påbegyndt
fungerede meget godt, især når jeg skulle brænde ned i mit burndown chart. Pga. det giver det
nu et meget bedre billede af hvordan det er gået. Det var selvfølgelig lidt uheldigt jeg måtte
aflyse den sidste dag i sprintet, og det var lidt ærgerligt, når det ellers gik så godt, men jeg er
dog overbevist om, at jeg nok skal få det indhentet i næste sprint, så jeg ser det ikke som den
store katastrofe. Jeg er overbevist om, at den arbejdsform jeg har indtil nu er den rigtige og jeg
håber at de fremtidige sprints vil gå lige så godt.
30
31
http://stackoverflow.com/questions/3785029/jquery-countdown-timer
http://www.w3schools.com/jsref/met_win_clearinterval.asp
43
5.4 SPRINT 3
5.4.1
Planlægning
Et af kravene fra Cleverweb, til pluginnet var at man skulle kunne integrere med sociale medier,
som Facebook, Twitter, Google+ etc. Derfor besluttede jeg mig for at kaste mig ud i at integrere
med Facebook i dette sprint, da Facebook må regnes blandt nogen af de største inden for
sociale medier.
En anden vigtig ting for pluginnet var at det skulle kunne huske quizzens tilstand, hvis
forbindelsen crashede eller brugeren kom til at refreshe siden ved et uheld. Derfor satte jeg mig
også for at lave en måde at sikre sig imod det i dette sprint.
Der var også blevet tænkt på statistik. I visse quizzer har det altid været underholdende at
konkurrere imod hinanden, og derfor følte jeg, at det ville være ideelt hvis man kunne se
rangliste, så man derfor kunne se hvem der havde klaret quizzen bedst. Og hvis quizzen skulle
bruges til en konkurrence, ville det også være en fordel for admin at han havde en oversigt over
hvem der havde klaret sig bedst, så en vinder nemt kunne findes.
Det medførte, at der også blev tænkt på at gøre sådan at quizzen kunne beregne den tid som
brugeren tog om at gennemføre quizzen. Det ville være nyttigt i tilfælde af at to brugere f.eks.
svarede rigtigt på lige mange spørgsmål. På den måde ville tiden så kunne vurdere hvem der
havde klaret sig bedst.
Måden man kunne opsætte en quiz på var også noget der skulle ordnes. Da jeg startede på
dette plugin, lavede jeg sådan at alle spørgsmål kom ud på en gang, men jeg tænkte at visse
brugere måske hellere ville have et spørgsmål af gangen, så det blev også taget ind som story i
dette sprint.
44
Backloggen for dette sprint så sådan ud:
Figur 22 - Sprint 3 backlog
5.4.2
Udførelse
Da det, som nævnt i afsnit 5.4.1 var et ønske fra Cleverweb at kunne integrere med sociale
medier, startede jeg ud med at prøve og gøre sådan det var muligt at dele quizzen via
Facebook. For at dette kunne lade sig gøre, skulle jeg ind og have fat i Facebooks Application
programming interface (API). Til at starte med skulle jeg oprette mig som bruger derinde, og
lave min egen app. Derefter kunne jeg frit, via den app, bruge Facebooks funktionalitet, som
muliggør integration til siden.
Jeg fik lavet sådan, at admin kunne bestemme om han ville tillade deling via Facebook. Hvis ja,
så ville man få muligheden for at dele quizzen, og sit resultat, efter man har taget den. Det
foregik via Facebooks egen hjemmelavede ”del” knappe, som jeg fik implementeret. Når man
trykker på den, tager den linket fra den side man er på og så kan brugeren vælge at dele det på
sin væg.
Derefter gik jeg i gang med at gøre sådan at quizzen kunne beregne den tid det tager brugeren
at gøre den færdig. Det lykkedes også, og jeg fik lavet sådan at brugeren kan se i toppen hvor
lang tid han har brugt, og så gemmer den tiden, sammen med antal rigtige svar efter quizzen er
afsluttet.
45
Figur 23 - Tidsberegner i quizzen
Så fik jeg også lavet sådan at admin nu kan bestemme om han ønsker alle spørgsmål skal
komme ud på en gang, eller om han foretrækker at spørgsmålene vises en af gangen, og
brugeren så kan trykke på ”næste” når han vil videre til næste spørgsmål.
Jeg fik også lavet sådan at admin i backend nu kan se statistik på alle de brugere som har taget
quizzen. Jeg lavede et table der sorterer efter antal rigtige svar, og hvis visse brugere har
samme antal rigtige svar, så sorterer den udfra hvem har været hurtigst igennem quizzen i
stedet.
Figur 24 - Statistikoversigt i backend
At lave sådan at quizzen kunne huske hvor den var nået til, hvis forbindelsen gik ned, var noget
der var lidt vanskeligere end forventet. Efter snak med vejlederen fik jeg et tip: Jeg kunne gøre
sådan at quizzen gemte dens state hver gang brugeren svarede på et spørgsmål. For at det
46
kunne lade sig gøre skulle jeg lave et AJAX kald, hver gang brugeren markerede et svar. Det
betyder så, at jeg kunne få quizzens state over i serveren, og ved hjælp af PHP, gemme den i
databasen. Hvis så forbindelsen crasher, er det så muligt at tjekke op på om den pågældende
bruger har et state gemt i databasen, og så kan man tilbyde ham at fortsætte hvor han slap,
eller opgive quizzen. Hvis han så opgiver quizzen beregner den det antal svar, han fik svaret på
og resten beregnes så automatisk som forkerte.
Figur 25 - Fortsættelse af quiz i front end
Mit burndown for dette sprint endte med at se sådan her ud:
47
Burndown - Sprint 3
30
25
Point
20
15
Estimeret
Aktuelt
10
5
0
0
1
2
3
4
5
Dag
Figur 26 - Sprint 3 burndown
Som det kan ses gik sprintet meget godt. Dog nåede jeg ikke den sidste story, fordi den med at
gemme quizzens state, var lidt vanskeligere end beregnet, men ud over det må dette sprint
betragtes som en stor succes.
5.4.3
5.4.3.1
Kodeeksempler
Facebook-deling
For at jeg kunne få implementeret Facebook-deling, skulle jeg først forbinde mit plugin til den
Facebook app, som jeg havde oprettet inde på Facebook Developers. Det blev gjort via
JavaScript på følgende måde:
48
Figur 27 - Implementering af Facebook SDK
Ved at give den mit unikke app ID, som man får efter man har oprettet en app, ved den hvilken
app den skal forbinde til og på den måde kan jeg gøre brug af Facebooks’ development
bibliotek.
Ved så at give et div element klassen ”fb-share-button”, bliver der automatisk lavet en
Facebook del knappe:
Figur 28 - Opsætning af del knap
5.4.3.2
Gem quiz tilstand
For at det kunne lade sig gøre at gemme quizzens tilstand, uden at være nødt til at reloade
siden, krævede det brug af AJAX. Det var nødvendigt at lave et AJAX kald, hver gang brugeren
markerede et svar.
49
Figur 29 - AJAX kald
På den måde kunne jeg sende disse variabler over på server siden. Og når AJAX kaldet så blev
lavet, ville den også automatisk udføre den funktion jeg har angivet under ”action”. Det er en
PHP funktion, som automatisk gemmer quizzens tilstand i databasen, ved hjælp af de variabler
som er sendt over.
5.4.4
Retrospective
At der kunne tilføjes endnu et vellykket sprint må ses som meget positivt. Igen oplevede jeg, at
det med at gå efter at gøre en task/story færdig den dag den påbegyndes var en meget god
måde at arbejde på. Dog har jeg også måtte sande, som jeg frygtede, at det ikke er altid det er
muligt at gøre dem færdige samme dag som de påbegyndes, hvis de f.eks. er sværere end først
antaget. Men heldigvis er det også det gode ved at arbejde agilt; at man til enhver tid kan
ændre i backloggen. Men da det går så godt som det gør nu, vil jeg ikke foretage store
ændringer på mine arbejdsmetoder.
En anden ting jeg synes fungerer godt, er løbende at holde kontakten med Cleverweb. Jeg har
haft mange fornuftige samtaler over Facebook med den ene af ejerne og han har løbende
kommet med inputs til nye features. Selvom de ikke har haft tiden til reviews, har det alligevel
fungeret godt på denne måde, da jeg føler det har været godt for mit arbejde at få idéer fra
firmaet også.
50
5.5 SPRINT 4
5.5.1
Planlægning
Efter planen skulle dette være sidste sprint. Inden jeg påbegyndte dette sprint havde jeg en
samtale med Cleverweb. Vi snakkede omkring det jeg havde lavet med at brugerens state blev
gemt. Cleverwebs ejer mente, at der ville være en potentiel chance for serveroverbelastning,
hvis det hele tiden blev gjort på den måde som jeg havde lavet. Jeg kom så med et forslag: Jeg
ville give brugeren muligheden for at markere i backend om quizzen skulle bruges til en
konkurrence. Hvis ja, så ville jeg bruge den måde som jeg allerede havde lavet. Hvis nej, så ville
quizzen i stedet anvende cookies til at gemme de forskellige states, så databasekald ikke
længere ville være nødvendigt til at gemme quizzens state. Grunden til jeg mente metoden
med databasekald var bedst når det var en konkurrence, er at cookies nemt kan slettes og at
brugeren så nemt ville kunne snyde. Det ville være katastrofalt, hvis folk kunne snyde sig til
præmien, som admin evt. udlovede. Derfor blev den story igen hevet ind i dette sprint, så den
kunne gøres færdig.
Og eftersom vi var i gang med at snakke om hvordan man forhindrede brugere i at snyde,
snakkede vi også om hvad vi skulle gøre hvis brugere ikke var logget ind og ville være med i en
konkurrence. Cleverwebs ejer foreslog her at jeg kunne gøre sådan man så skulle indtaste sin email i et felt, inden man kunne begynde quizzen. Hvis man så gemte e-mailen, kunne man
tjekke op på om vedkommende allerede havde deltaget i konkurrencen.
Cleverweb havde også fra starten af ønsket at det skulle være muligt at samle tilmeldinger til
nyhedsbreve via quizzen. For at dette kunne være muligt skulle mit plugin kunne integrere med
nyhedsbrevsservice. Jeg tror dog ikke på at jeg kan nå at integrere med en masse forskellige så i
dette sprint har jeg valgt MailChimp, efter anbefaling fra Cleverweb, da de selv bruger den
service. Så ligesom jeg gjorde da jeg skulle integrere med Facebook, skal jeg ind og bruge
MailChimps API.
Siden jeg havde lavet sådan admin kunne se statistik besluttede jeg at admin også skulle have
mulighed for at give de andre brugere lov til at se statistik i front end. Men selvfølgelig kunne
der være tilfælde hvor han gerne ville holde den hemmelig, så derfor besluttede jeg, at det
51
skulle være noget han bestemte. Jeg besluttede også at gøre sådan admin kunne bestemme om
brugeren måtte se rigtige svar efter at have taget quizzen.
Da dette var mit sidste sprint, ville jeg også gerne oversætte pluginnets interface til engelsk,
med henblik på at ikke-dansk talende brugere kunne bruge det. Hvis jeg gjorde det, ville folk i
udlandet også kunne hente det og bruge det.
Min sidste backlog så sådan her ud:
Figur 30 - Sprint 4 backlog
5.5.2
Udførelse
Da den story med at man kan fortsætte hvor man slap, hvis siden reloadede, også var med i
forrige sprint gav det god mening at starte med at få den gjort helt færdig. Jeg blev ikke færdig
med den samme dag som den blev påbegyndt, da cookies var rimelig nyt for mig, men heldigvis
fik jeg lavet nok til at jeg kunne gøre den færdig ret hurtigt dagen efter. Det voldte mig lidt
besvær at få den til at gemme de spørgsmål, som der var blevet svaret på, i cookies.
Efter det var overstået sprang jeg ud i at prøve at få nyhedsbrevintegration tilsluttet. Her gik jeg
ind på MailChimps API guide for at prøve og finde hjælp. Jeg brugte meget af dagen på at lave
research. Men sidst på dagen fandt jeg dog ud af at man ikke kunne teste MailChimp på
localhost. Derfor besluttede jeg mig for ikke at gå videre med det, da jeg ikke mente det kunne
betale sig, hvis man ikke kunne sætte det op på lokalt, da jeg så ikke ville kunne få testet om det
virkede. Så jeg smed i stedet den story tilbage i product backlog.
Det lykkedes at få lavet sådan man kunne se de rigtige svar efter quizzens afslutning. Dog voldte
det lidt problemer at skulle sørge for at den funktion virkede i begge quizopsætninger (altså
både med alle spørgsmål på én side, og med et spørgsmål af gangen).
52
Det lykkedes også at få implementeret e-mail tjek, til konkurrencer, hvor en bruger ikke er
logget ind.
Figur 31 - E-mail tjek
Da pluginnet skulle oversættes brugte jeg Poedit, som er en oversættelseseditor.32 For at kunne
bruge den måtte jeg dog ind og ændre alle de steder hvor der var ting der skulle oversættes i
koden. Det krævede nemlig at man brugte en bestemt funktion de steder, for at editoren kunne
genkende de forskellige linjer som skulle oversættes, så der gik lidt tid med det. Men det
lykkedes at få oversat pluginnet til engelsk.
32
http://poedit.net/
53
Figur 32 - Oversat plugin
Burndown for sidste sprint endte med at se sådan ud:
54
Burndown - Sprint 4
30
25
Point
20
15
Estimeret
Aktuelt
10
5
0
0
1
2
3
4
5
Dag
Figur 33 - Sprint 4 burndown
Som det kan ses var jeg lidt bagefter det meste af tiden, men endte med at lave alle stories
færdige udover den med nyhedsbrevintegration.
5.5.3
5.5.3.1
Kodeeksempler
Anvende cookies
Figur 34 - Implementering af cookies
55
Ved at lave et array om til JSON, kan jeg gemme arrayet, som en String i en cookie. Når den så
skal læse cookien kan jeg transformere den tilbage til et array igen, så jeg dermed kan afkrydse
de svar som brugeren har valgt, og på samme måde kan jeg også sætte tidsmåleren på den tid,
som brugeren indtil videre har brugt.
5.5.4
Retrospective
Selvom jeg er skuffet over jeg ikke fik lavet nyhedsbrevstilmelding, synes jeg det her sprint gik
meget godt. Alle andre stories blev lavet med stor succes, og jeg synes det var en god måde at
slutte af på.
Men jeg burde nok have lavet et spike på det med nyhedsbrevstilmelding, så jeg ikke havde
spildt en hel sprintdag på det. Hvis jeg havde gjort det, og dermed fundet ud af at det ikke
kunne laves på localhost, kunne jeg have udvalgt en anden story som havde været mere
realistisk at gøre færdig. Det var ikke så heldigt at spilde en hel dag med en story der endte med
at blive droppet. Men udover det synes jeg ikke der var mange ting der gik galt under dette
sprint.
5.6 TEST
Efter sidste sprint, havde jeg aftalt med ejeren af Cleverweb, at jeg kunne få folk i hans
netværksgruppe til at teste mit plugin og komme med feedback. Derfor lavede jeg nogle
testopgaver, og så var aftalen at de skulle filme skærmen og snakke højt imens, ligesom en
tænke-højt test.
Desværre var der kun én fra netværksgruppen der nåede at teste mit plugin, inden denne
rapport skulle afleveres. Jeg håber selvfølgelig, at de andre folk når det senere, således at jeg
kan få nyttig feedback, til at forbedre pluginnet løbende. Men nogle af de ting jeg fik fra den
person der nåede at teste det var:

Visse knapper i backend er ikke placeret sådan det virker logisk hvordan de bruges

Hjælpetekst til indstillinger i backend skal beskrives meget kortere
56

Quizzen bør stadig registrere den tid brugeren er om at tage quizzen selvom man ikke
har den indstilling slået til. Indstillingen burde i stedet tilbyde at skjule tidsmåleren i
front end.
5.7 VURDERING AF PROCESSEN
Efter at have været igennem fire sprints, kan jeg nu konkludere at jeg valgte rigtigt hvad angår
valg af metode. Det har fungeret rigtig godt, med at lave sprints, hver uge og jeg føler at det
agile har passet perfekt til mig. Der hvor det især gjorde mig gavn, var at jeg kunne lave
ændringer uden problemer. Det betød en hel del eftersom der jævnligt kom nye idéer til
funktionaliteten, og hvis jeg havde arbejdet plandreven, havde det været besværligt at skubbe
ændringerne ind i planen. De gange hvor jeg er stødt på problemer i forhold til udviklingen har
det agile også været meget godt at bruge, da jeg så uden problemer har kunne ændre i
planerne for de forskellige sprints.
Men som forventet blev XPs praktikker ikke fulgt i lige så høj grad, da jeg var alene. Men dog
synes jeg heller ikke der på noget tidspunkt har været lige så stort et behov for dem, som der
har været for Scrum. Nogle af praktikkerne, såsom simpelt design, fastlagt antal timer og kort
tid mellem releases, har dog hjulpet en del på mit arbejde. Det var også forventet, at jeg nok
ville komme til at indrette arbejdsmetoderne meget efter mit eget behov, da jeg trods alt var
alene om projektet.
Som jeg også forventede, hjalp det også meget på min motivation at presse mig selv til at have
ny funktionalitet klar uge efter uge. Uden en decideret plan tror jeg slet ikke at jeg havde nået
lige så meget som jeg endte med, så jeg synes bestemt det har været en god måde at arbejde
på.
6 KONKLUSION
Efter 9 ugers projektarbejde er resultatet nu blevet et Quiz plugin med en masse funktionalitet.
Målet var at lave et plugin med en masse forskellige features, samt at få svaret på mine
spørgsmål i min problemformulering.
57
Jeg synes bestemt at det jeg har nået at lave er acceptabelt, når man tænker på at jeg har været
på egen hånd i projektet. Selvfølgelig kan der stadig implementeres mange flere ting til det,
men at jeg har noget der er klar til at folk kan hente det til deres WordPress side, er bestemt
positivt.
Jeg føler også, at jeg fik svar på de fleste spørgsmål i min problemformulering. Det eneste jeg
måske ikke rigtig fik svar på i løbet af projektet er om det er muligt at tjene penge på det, men
det er nok noget der skal komme an på en prøve. Lige nu tror jeg ikke på at det er godt nok til at
der kan tjenes penge på det, men hvis der i fremtiden lægges meget arbejde i det, så kan det
måske komme på tale til den tid. Til dels fik jeg heller ikke svar på hvordan man sætter
nyhedsbrevtilmelding op, da jeg opgav det, men jeg synes dog at jeg fik fornemmelsen af
hvordan det fungerede, så hvis jeg fik muligheden for at bruge en live side, kunne jeg måske få
det til at virke.
At jeg fik svar på mit hovedspørgsmål var dog det vigtigste, og jeg er meget tilfreds med, at det
er lykkedes at implementere et quiz plugin i WordPress, og dermed få svar på det overordnede
spørgsmål.
Måden jeg arbejdede på fungerede også fint, selvom det til tider var hårdt at være alene, men
jeg synes dog også det har gjort mig gavn at prøve og være på egen hånd, og jeg kan tage en
masse positive ting med fra det.
6.1 VIDEREUDVIKLING
Hvis der skal videreudvikles på projektet er der en del ting som kan overvejes. Jeg fik ikke lavet
muligheden for at tilmelde sig nyhedsbreve, så den feature ville være noget jeg ville forsøge at
få implementeret.
En anden ting der også er blevet snakket meget om, sammen med Cleverweb, er at gøre sådan
man kan belønne folk med badges efter de har taget ens quiz. Badges ses mere og mere rundt
omkring på forskellige sider. Det synes at have en positiv effekt på folks motivation for at
gennemføre ting, og derfor ville det måske også motivere dem til at tage quizzer og opnå flotte
58
resultater. Det kunne måske især være nyttigt i de quizzer der er baseret på almen viden, da
det måske kunne vise hvor klog man er.
Nu hvor jeg også allerede har gjort sådan man kan integrere med Facebook, kan det også blive
relevant at integrere med andre sociale medier, såsom Twitter og Google+. Jo flere sociale
medier pluginnet kan integrere med jo mere reklameværdi ville det også give Cleverweb, og
hvis målet om at tjene penge på pluginnet skal have gode chancer for at blive opnået, er det
ikke en dårlig idé at give folk mulighed for at dele det rundt omkring.
Det kan også godt betale sig at få det oversat til flere forskellige sprog, men her skal man dog
have fat i folk der taler sprogene flydende, som så kan hjælpe en med at oversætte det. Da
WordPress bruges af folk fra over hele verden, skulle der være gode muligheder for at finde folk
der kan hjælpe med at oversætte til mange forskellige sprog.
En anden ting jeg også overvejede at lave i projektet, men som jeg desværre måtte skære fra,
fordi tiden løb fra mig var muligheden for at bestemme hvor mange rigtige svar hvert spørgsmål
skulle have. Der kunne måske være tilfælde, hvor det ville være relevant med mere end et
korrekt svar. F.eks. til spørgsmål som ”Nævn navnene på Anders Ands tre nevøer”. I det tilfælde
ville der være behov for tre rigtige svar. En anden grund til at det kan overvejes er også hvis
man måske skal lave en undersøgelse, fremfor en decideret quiz. Dvs. man måske slet ikke
ønsker nogen svar skal være rigtige eller forkerte, da svarene jo så ville være baseret på folks
meninger og holdninger.
Cleverweb ønskede som nævnt i afsnit 2.1 også at pluginnet skulle fungere på mobil. Men det
ville kræve jeg bliver bedre til at bruge CSS, da det ikke er mit stærkeste område endnu. Men
det ville dog uden tvivl give flere brugere, hvis det lykkedes, da mange folk bruger mobiler i dag
til at gå på nettet med.
7 REFERENCER
1
Boehm-Agility-Disciplined – Homegrounds (PDF)
2
XP planlægnings og programerings praktikker (PP), 4. semester
59
3
Intro-SCRUM (pp), 4. semester
4
https://en.wikipedia.org/wiki/Content_management_system
5
http://www.forbes.com/sites/jjcolao/2012/09/05/the-internets-mother-tongue/
6
http://codex.wordpress.org/Installing_WordPress
7
http://codex.wordpress.org/Themes
8
http://codex.wordpress.org/Plugins
9
http://codex.wordpress.org/Roles_and_Capabilities
10
http://codex.wordpress.org/Database_Description
11
https://en.wikipedia.org/wiki/PHP
12
https://en.wikipedia.org/wiki/JavaScript
13
https://en.wikipedia.org/wiki/JQuery
14
http://www.jscripters.com/jquery-disadvantages-and-advantages/
15
https://en.wikipedia.org/wiki/Ajax_(programming)
16
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/
17
http://www.w3schools.com/js/js_cookies.asp
18
http://www.w3schools.com/html/html5_webstorage.asp
19
http://www.sublimetext.com/2
20
https://subversion.apache.org/
21
https://www.dropbox.com/home
22
https://www.apachefriends.org/index.html
23
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
24
https://tommcfarlin.com/wordpress-and-mvc/
25
http://codex.wordpress.org/Plugin_API
60
26
http://codex.wordpress.org/Plugin_API/Action_Reference
27
http://codex.wordpress.org/Plugin_API/Filter_Reference
28
https://en.wikipedia.org/wiki/Event-driven_architecture
29
https://make.wordpress.org/core/handbook/coding-standards/
30
http://stackoverflow.com/questions/3785029/jquery-countdown-timer
31
http://www.w3schools.com/jsref/met_win_clearinterval.asp
32
http://poedit.net/
8 BILAG
Alle bilag er vedhæftet som ekstra materiale på Wise Flow.
Følgende er vedhæftet:
-
quiz-plugin.zip (indeholder alt koden)
Product backlog.xlsx
Brugertest.docx
Sprint 1 backlog.xlsx
Sprint 2 backlog.xlsx
Sprint 3 backlog.xlsx
Sprint 4 backlog.xlsx
Burndown – Sprint 1.xlsx
Burndown – Sprint 2.xlsx
Burndown – Sprint 3.xlsx
Burndown – Sprint 4.xlsx
61