Rapport - Ulrik Søvsø Larsen

Transcription

Rapport - Ulrik Søvsø Larsen
University College Nordjylland
Teknologi og Business
Datamatiker
Dmaa0213
5. Semester
Afsluttende projekt
In this project I have developed a Magento website:
www.kalejdoskopshop.dk, a furniture and decoration store
in Aalborg.
The main goals of this project have been to gain an
understanding of Magento and to adapt and improve
Projekt deltagere:
Magento based on customer specifications.
 Ulrik Larsen
Secondly objectives were to find cases where Scrum and XP
practices have been implemented well on Solo teams.
During the process I have learned a lot about Magento and
Vejledere:
Ann Francke Riisberg
achieved my goals, to understand how it works and to adapt
and improve Magento to the customer needs.
Scrum and XP practices have helped me during the project,
to keep structure and achieve a high quality of work.
Afleveringsdato: 18-06-2015
Underskrifter:
Ulrik Søvsø Larsen
The project will be finished after the end of this rapport by
working freelance for the company. Hopefully doing so
evolving the Scrum and XP practices used here.
Indholdsfortegnelse
Indledning .................................................................................................................................................................1
Læsevejledning .....................................................................................................................................................1
Teori..........................................................................................................................................................................2
Indledende Magento ............................................................................................................................................2
Teknologi stack .................................................................................................................................................2
Drupal ...........................................................................................................................................................2
Apache ..........................................................................................................................................................2
MySQL ...........................................................................................................................................................3
PHPMyAdmin ............................................................................................................................................3
HTML ....................................................................................................................................................................3
PHP .......................................................................................................................................................................3
Filtype PHP........................................................................................................................................................3
Filtype PHTML...................................................................................................................................................3
CSS ........................................................................................................................................................................4
SCSS ......................................................................................................................................................................4
JavaScript ..............................................................................................................................................................4
jQuery ...............................................................................................................................................................4
Arkitektur..............................................................................................................................................................4
Objekt orienteret programmering ...................................................................................................................4
Domæne model ................................................................................................................................................5
3 lags arkitektur ................................................................................................................................................6
GRASP (Elaboration fasen, analyse og design) .............................................................................................6
MVC - Model View Controller...........................................................................................................................7
Magento ...............................................................................................................................................................7
Zend Framework...............................................................................................................................................7
PHP i Magento ..................................................................................................................................................7
Cache i Magento ...............................................................................................................................................8
Arkitektur i Magento ........................................................................................................................................9
Konceptuel struktur ......................................................................................................................................9
Pakker og Temaer ...................................................................................................................................... 10
Folder struktur ....................................................................................................................................... 10
Fallback i Magento..................................................................................................................................... 11
Moduler ..................................................................................................................................................... 12
Dokumentation i Magento ........................................................................................................................ 13
Magento - MVC - Model View Controller .................................................................................................. 14
Magento ORM ........................................................................................................................................... 16
Data modeller ........................................................................................................................................ 16
EAV Model ............................................................................................................................................. 16
Debug i Magento ........................................................................................................................................... 17
xDebug i Magento ..................................................................................................................................... 17
Integration / API ............................................................................................................................................ 18
Teknologi ........................................................................................................................................................... 19
FTP ................................................................................................................................................................. 19
phpMyAdmin ................................................................................................................................................. 19
Lokal Bitnami VM med Magento ................................................................................................................... 19
Test server ..................................................................................................................................................... 19
Opdateringsproces ........................................................................................................................................ 19
Backup ........................................................................................................................................................... 19
IDE.................................................................................................................................................................. 20
Atom .............................................................................................................................................................. 20
Visual Studio .................................................................................................................................................. 21
PHPStorm....................................................................................................................................................... 21
Risici registrering ............................................................................................................................................... 21
Udviklingsmetoder ............................................................................................................................................ 22
Scrum ............................................................................................................................................................. 22
Scrum hoved principper: ........................................................................................................................... 22
Scrum begreber og processer .................................................................................................................... 22
Roller...................................................................................................................................................... 22
Artefakter .............................................................................................................................................. 23
Ceremonier ............................................................................................................................................ 24
Scrum begreber og proces forløb .......................................................................................................... 25
Scrum Buts ............................................................................................................................................. 26
Solo Scrum ................................................................................................................................................. 26
XP ................................................................................................................................................................... 27
XP Praktikker.............................................................................................................................................. 27
XP Værdier ................................................................................................................................................. 27
Solo XP ....................................................................................................................................................... 28
Projekt ................................................................................................................................................................... 28
Metode valg....................................................................................................................................................... 28
Implementering af Scrum .............................................................................................................................. 28
Scrum But Projekt ...................................................................................................................................... 29
Implementering af XP praktikker................................................................................................................... 29
Produkt Backlog ................................................................................................................................................. 30
Sprint ................................................................................................................................................................. 33
Sprint 0 .......................................................................................................................................................... 33
Sprint planning........................................................................................................................................... 33
Retrospektive............................................................................................................................................. 33
Burndown .............................................................................................................................................. 33
Hvad gik godt? ....................................................................................................................................... 34
Hvad kunne have været bedre? ............................................................................................................ 34
Hvad overraskede? ................................................................................................................................ 34
Sprint 1 .......................................................................................................................................................... 34
Sprint planning........................................................................................................................................... 34
Review ....................................................................................................................................................... 34
Retrospektive............................................................................................................................................. 35
Burndown .............................................................................................................................................. 35
Hvad gik godt? ....................................................................................................................................... 35
Hvad kunne have været bedre? ............................................................................................................ 36
Hvad overraskede? ................................................................................................................................ 36
Sprint 2 .......................................................................................................................................................... 36
Sprint planning........................................................................................................................................... 36
Review ....................................................................................................................................................... 36
Retrospektive............................................................................................................................................. 37
Burndown .............................................................................................................................................. 37
Hvad gik godt? ....................................................................................................................................... 37
Hvad kunne have været bedre? ............................................................................................................ 37
Hvad overraskede? ................................................................................................................................ 37
Sprint 3 .......................................................................................................................................................... 38
Sprint planning........................................................................................................................................... 38
Review ....................................................................................................................................................... 38
Retrospektive............................................................................................................................................. 39
Burndown .............................................................................................................................................. 39
Hvad gik godt? ....................................................................................................................................... 39
Hvad kunne have været bedre? ............................................................................................................ 39
Hvad overraskede? ................................................................................................................................ 39
Sprint 4 .......................................................................................................................................................... 40
Sprint planning........................................................................................................................................... 40
Retrospektive............................................................................................................................................. 40
Burndown .............................................................................................................................................. 40
Hvad gik godt? ....................................................................................................................................... 40
Hvad kunne have været bedre? ............................................................................................................ 40
Hvad overraskede? ................................................................................................................................ 41
Sprint 5 .......................................................................................................................................................... 41
Sprint planning........................................................................................................................................... 41
Retrospektive............................................................................................................................................. 41
Burndown .............................................................................................................................................. 41
Hvad gik godt? ....................................................................................................................................... 41
Hvad kunne have været bedre? ............................................................................................................ 42
Hvad overraskede? ................................................................................................................................ 42
Sprint 6 .......................................................................................................................................................... 42
Sprint planning........................................................................................................................................... 42
Review ....................................................................................................................................................... 42
Retrospektive............................................................................................................................................. 43
Burndown .............................................................................................................................................. 43
Hvad gik godt? ....................................................................................................................................... 43
Hvad kunne have været bedre? ............................................................................................................ 43
Hvad overraskede? ................................................................................................................................ 43
Samlet risici vurdering ....................................................................................................................................... 44
Samlet perspektivering ...................................................................................................................................... 45
Magento ........................................................................................................................................................ 45
Scrum ............................................................................................................................................................. 45
Roller.......................................................................................................................................................... 45
Ceremonier ................................................................................................................................................ 45
Artefakter .................................................................................................................................................. 45
XP Praktikker.................................................................................................................................................. 45
Løbende integration .................................................................................................................................. 46
Refaktorering ............................................................................................................................................. 46
Kodestandard ............................................................................................................................................ 46
Test først udvikling .................................................................................................................................... 46
Videre udvikling ..................................................................................................................................................... 47
Magento 2 ......................................................................................................................................................... 47
Konklusion ............................................................................................................................................................. 48
Referencer ............................................................................................................................................................. 49
Bilag ....................................................................................................................................................................... 53
5. Semester – Afsluttende projekt
Indledning
Denne opgave tager udspring i mit praktikforløb hos Kalejdoskop, som er en møbel- og interiørbutik i Aalborg.
Kalejdoskop har en eksisterende Magento CMS webshop: www.Kalejdoskopshop.dk som de ønsker at opdatere
og udbygge. Arbejdet med Magento webshoppen har ført til en stor interesse for Magento samt arbejde med
webshop udvikling. Derfor har jeg valgt at have Magento, som fokusområde i denne rapport.
Målet med projektet er, at:


Lære og arbejde med ny teknologi – Magento
o Hvad er Magento, og hvordan er Magento opbygget?
o Tilpasning af Magento design og layout ud fra kundens behov.
o Kunne udbygge Magento med ny funktionalitet.
Hvordan kan Scrum og XP praktikker understøtte processen, når der arbejdes alene.
For at løse problemerne vil jeg finde og beskrive de teknologier, som Magento gør brug af, samt finde ud af
hvordan Magento er opbygget.
Derudover vil jeg benytte Scrum og XP praktikker i udviklingsprocessen i så vidt muligt omfang, det er muligt.
Jeg har en fast kontaktperson hos Kalejdoskop til at varetage rollen som Product Owner i projekt perioden, og
jeg vil selv agere Scrum Master og team. Da jeg arbejder alene, vil jeg ligeledes indsamle viden om Scrum og XP
praktikkers brugt i solo projekter.
Læsevejledning
Teoriafsnittet er indrettet, så der først beskrives de teknologier, Magento bygger på - herefter detaljeret om
Magento. Sidst beskrives udviklingsmiljøerne Scrum og XP samt fundne eksempler på Solo Scrum og XP.
Projektafsnittet starter med metodevalg, herefter Product Backlog for projektet. Så kommer sprint, hvor hvert
sprint er dokumenteret med Sprint planning og Retrospektive for sprintet. Review er noteret, hvis det har
været særligt interessant. Sidst i projekt er samlet risici vurdering og samlet perspektivering.
I videre udvikling beskrives fremtiden for projektet efter denne rapport.
Afsluttes med konklusionen.
Udarbejdet af: Ulrik.
Side 1 af 53
5. Semester – Afsluttende projekt
Teori
Indledende Magento
Magento er en CMS1 til e-handelshjemmesider. Der findes forskellige udgaver af Magento, både betalt og gratis
udgaver. I dette projekt er brugt Magento Community Edition, som er en open source udgave.
Magento består af Magento framework, som kan moduleres efter behov. Magento framework tilbyder det
basale for at kunne drive en e-handels butik, i form af forretningslogik, dataadgang og basisklasser. Magento
kan udbygges med eksterne moduler, som kan føjes til eller erstatte funktioner.
På Magento hjemmeside har jeg fundet, at Magento kræver en LAMP eller LNMP stack for at fungere.
Henvisning til stacken er et akronym, der dækker over hyppigt brugte open source programmer.
I Tabel 1 kan man se informationer for live- og testserverne.
Operativ system:
Ikke oplyst
Web Server CMS:
Drupal
Web Server:
Apache 2.x
Database:
MySQL 5.6
PHP:
PHP 5.4
Tabel 1 - Live og test server informationer
Lokalt har jeg brugt en Bitnami Virtuel Maskine, hvor jeg har haft Magento kørende i en Mac (MAMP) og
Windows PC (WAMP).
Teknologi stack
Drupal
Drupal er et open source CMS system til at håndtere hosting af websites. Drupal bruger PHP2 og MySQL.
Apache
Apache er en open source web server. Apache er meget populært, da det er open source og fungerer på mange
forskellige platforme. Ud fra analyse lavet af w3techs.com [1], bruges Apache i dag på over 55% af alle web
servere, som de kender til. Apache 2.x understøtter fortolkning af PHP.
1
2
CMS - Content Management System
PHP - Hypertext Preprocessor
Udarbejdet af: Ulrik.
Side 2 af 53
5. Semester – Afsluttende projekt
MySQL
MySQL er et open source RDBMS3 udarbejdet af Oracle. MySQL er et meget brugt system som web database,
og det indgår, som nævnt, som ”M” i open source stacks. MySQL fungerer flertrådet, hvilket appellerer til web
brug, hvor der må formodes at være mange samtidige efterspørgsler.
PHPMyAdmin
PHPMyAdmin er en open source administrativ web portal GUI, til håndtering af forespørgsler til MySQL.
PHPMyAdmin er særligt anvendeligt til at få et visuelt overblik over databaser og forespørgsler. I projektet har
jeg brugt PHPMyAdmin til administration af MySQL databasen.
HTML
HTML4 er et sprog, der beskriver hjemmesiders struktur. I HTML dokumenter finder man således information
om, hvad og hvordan elementer skal vises. Det er op til klientens browser at tolke indholdet og vise det til
brugeren.
PHP
PHP er et open source server-side script sprog, hvilket betyder, at brugeren ikke ser PHP koden, men kun
resultatet af koden. PHP bruges primært i forbindelse med web programmering og kan inkluderes på html
sider. PHP skal, fordi det er server-side kode, fortolkes af serveren, og den sendes derefter til klientens
browser.
Filtype PHP
Filtypen PHP bruges til at håndtere PHP kode logik.
Filtype PHTML
Filtypen PHTML bruges til at håndtere rå HTML og PHP. PHTML bruges dermed til at skabe den visuelle
præsentation, mens PHP inddrages efter behov til at håndtere logik.
3
4
RDBMS - Relationel Database Management System
Hypertext Markup Language
Udarbejdet af: Ulrik.
Side 3 af 53
5. Semester – Afsluttende projekt
CSS
CSS5 er et præsentations sprog, der bruges til at beskrive, hvordan Markup sprog, så som HTML, skal
præsenteres. CSS kan både forekomme som en integreret del af Markup koden og som et eksternt dokument.
Det er bedst at holde CSS og HTML adskilt, da det er nemmere at vedligeholde og cache hver for sig.
SCSS
En anden måde at arbejde med CSS er ved at bruge SCSS6. SCSS er en udvidelse til CSS, som tilfører mere
funktionalitet til udvikleren. For at bruge SCSS skal det kompileres til CSS, så der ikke er en forskel for brugeren.
Med SCSS kan man eksempelvis bruge variabler og lagrede inkludes. Det letter i høj grad arbejdet ved større
CSS filer i høj grad, da man kan opdele CSS filen i sigende segmenter og inkludere efter behov. Herved undgås
også kode repetition. Desuden kan brugen af variabler lette arbejdet med CSS, så koden bliver lettere at
overskue og vedligeholde.
Til dette projekt har jeg brugt SCSS, da Magento 1.9 responsive tema implementere denne. SCSS er en
alternativ syntax til SASS.
JavaScript
JavaScript er både et objektorienteret script sprog, som anvendes typisk client-side på hjemmesider. Endvidere
kan JavaScript bruges til at tilføje ekstra funktionalitet, så som animationer eller ændring af elementer eller til
at tilføje struktur efter HTML sider er konstrueret.
jQuery
jQuery er et kraftfuldt JavaScript bibliotek. Med jQuery kan man blandt andet, finde og manipulere specifikke
DOM7 elementer.
Arkitektur
I det følgende beskrives mønstre, der bruges til at fastsætte arkitekturen.
Objekt orienteret programmering
Objekt orienteret programmering er en design filosofi. Hvor man arbejder på at opdele domænets objekter i
afgrænsede klasser med fælles attributter, struktur og adfærdsmønster.
5
Cascading Style Sheets
Sassy CSS
7
Document Object Model
6
Udarbejdet af: Ulrik.
Side 4 af 53
5. Semester – Afsluttende projekt
Domæne model
En domæne model er en konceptuel model af den virkelige verden ud fra en bestemt problemstilling. Domæne
modellen bruges til at opdele verden i konceptuelle klasser og vise deres relationer.
Det har ikke været muligt at finde en Domæne model for Magento. Derfor har jeg valgt at lave en selv, i Tabel
2. Domæne modellen har udgangspunkt i ordren.
Tabel 2 - Domæne model – Magento
Udarbejdet af: Ulrik.
Side 5 af 53
5. Semester – Afsluttende projekt
3 lags arkitektur
3 lags arkitektur er en model til at opdele systemet for at holde ansvarsområderne adskilt. Et typisk eksempel
er vist i Tabel 3. Der må kun være synlighed lagene imellem, med undtagelse af præsentationslaget der kan
medtage modeller fra model laget i præsentation.
3 lags arkitektur
Præsentations lag
Applikations lag
Domæne lag
Tabel 3 - Eksempel på 3 lags arkitektur
GRASP (Elaboration fasen, analyse og design)
GRASP8 hjælper med at standardisere ansvarsfordelingen mellem klasserne ved fastsættelse af arkitekturen.
Det foregår primært ved brug af specialiserede controllere og model klasser. Ved brug af GRASP opnår man høj
binding og lav kobling i systemet.
Niveauet af binding fortæller om, hvor afgrænsede klasserne er i forhold til deres specifikke område. Målet er
at have mange specifikke klasser, med let genkendelige navne, som kun indeholder den nødvendige kode for at
kunne udføre sit område. Ved denne opdeling bliver klasserne lettere at genkende, genanvende, udskifte og
vedligeholde.
Niveauet af kobling dækker over, hvor afhængige klasserne er af hinanden, hvor målet er, at klasserne ved en
lav kobling er uafhængige af hinanden og derved let kan skiftes ud.
8
General Responsibility Assignment Software Patterns
Udarbejdet af: Ulrik.
Side 6 af 53
5. Semester – Afsluttende projekt
MVC - Model View Controller
MVC er et mønster som dikterer, hvordan synligheden skal være i mellem de forskellige lag. MVC er opdelt i tre
lag: Model, View og Controller. Et af hovedprincipperne er, at Model-laget ikke skal have direkte synlighed til
View-laget. Ved at holde lagene adskilt bliver overblik og vedligeholdelse meget nemmere. Desuden vil det
være muligt at udskifte lag efter behov. Ved brug af Model-objekter i View skal der bruges View-modeller som
kun indeholder den nødvendige information, frem for systemets Model objekter, med forretnings logik. Igen
for at holde lagene adskilt, men også for kun at præsentere det nødvendige data.
Magento
I det følgende vil jeg beskrive nogle af de centrale dele af Magentos opbygning.
Zend Framework
Magento bruger Zend framework 1. Zend er et open source, objekt orienteret web framework til PHP 5. Zend
er modulerbar og bruger MVC arkitektur.
PHP i Magento
I Tabel 4 - ”Eksempel fra PHP kode til Resultat på skærm ses et eksempel på brugen af PHP i Magento. Der er en
klar fordel ved at bruge PHP og Html sammen på denne måde. Med HTML kan man kontrollere, hvordan
elementer skal præsenteres, og med PHP hvad de skal indeholde.
Der er en sikkerhed i, at PHP kildekoden kun er synlig på serveren, og at siderne altid laves på samme måde.
Ulempen ved PHP må være, at siden er statisk, når den bliver leveret til brugeren. Så hvis der skal ændres i
koden hos brugeren, bliver man nød til at bruge et klient-side sprog, eksempelvis JavaScript.
PHtml kode på server:
Udarbejdet af: Ulrik.
Side 7 af 53
5. Semester – Afsluttende projekt
Resultat i browser – Debugging elements:
Resultat på skærmen:
Tabel 4 - ”Eksempel fra PHP kode til Resultat på skærm”
Cache i Magento
Magento gør brug af cache for at optimere driften. Man kan i Magento vælge, hvad man ønsker at cache, Tabel
5 viser en liste over, hvad Magento tilbyder som standard:
Type
Beskrivelse
Konfiguration
System (config.xml, local.xml) og modul konfigurations filer(config.xml).
Layout
Layout bygnings instrukser.
Blocks HTML output
Side blocks HTML.
Oversættelser
Oversættelses filer.
Samlings Data
Samlings data files.
EAV types og attributter
Entity type deklarations cache.
Web Services Configuration
Web Services definitions filer (api.xml / api2.xml).
Tabel 5 - "Magento cachelager"
Ud over de ovennævnte cache muligheder, laver Magento cache af: Katalogbilleder, Swatch billeder, JavaScript
og CSS.
Udarbejdet af: Ulrik.
Side 8 af 53
5. Semester – Afsluttende projekt
Ud fra elementerne kan man se, at det er statiske elementer i Magento som caches. Det giver god mening, så
der ikke skal ledes i systemet, hver gang der foretages en forespørgsel. Cache genereres første gang der laves
en forespørgsel, hvor der ikke er lavet cache.
Magento giver besked, når en eller flere cache elementer er forældet, så er det op til administratoren af forny
cache, hvis det er ønsket.
Arkitektur i Magento
I det følgende beskrives Magentos arkitektur.
Konceptuel struktur
I Tabel 6 kan man se det konceptuelle hierarki mellem hjemmeside, butik og butiks udseende i Magento. Det
viser, at der er en overordnet Magento hjemmeside, som kan indeholde flere og forskellige butikker og i dem
forskellige butiksudseender – eksempelvis ved forskellige landesprog. I forbindelse med denne rapport er der
brugt én butik og ét udseende. Alternative butiksudseender er valgt fra, da butikken kun henvender sig til
Dansk publikum.
Tabel 6 - Figur 1 fra [2] ”Magento Design guide”.
Udarbejdet af: Ulrik.
Side 9 af 53
5. Semester – Afsluttende projekt
Pakker og Temaer
I Magento har man mulighed for at vælge en temapakke eller et separat tema. Her er hierarkiet som i Tabel 7,
hvor man kan have et standardtema med forskellige varianter. I dette projekt arbejdes der med et RWD9 tema
udarbejdet af Magento. RWD blev lanceret med Magento opdatering 1.9.
Tabel 7 - Figur 5 fra [2] ”Magento Design guide”.
Folder struktur

I Tabel 8 kan man se en oversigt over folder-strukturen af et tema. Det er opdelt, således layout holdes
adskilt fra design.
Layout
Skin
Tabel 8 - Tema folder oversigt
9
Responsive Web Design
Udarbejdet af: Ulrik.
Side 10 af 53
5. Semester – Afsluttende projekt
RWD står for Magentos Responsive Web Design og blev lanceret med Magento version 1.9. Det aktuelle tema
er: kalejdoskopRWD og ligger under RWD mappen. Den ligger således i folderen:
”app/design/frontend/rwd/kalejdoskopRWD”.
Et tema indeholder tre primære layout foldere:



Layout: Indeholder xml filer med layout information, der i blandt blokstruktur til de enkelte sider.
Locale: Indeholder sprogfoldere og i dem en csv fil med oversættelser til temaet.
Template: Indeholder PHtml og PHP sider nødvendigt for at skabe de endelige sider.
Et RWD tema indeholder fire primære skin elementer:




CSS: Indeholder CSS filer med information om, hvordan de enkelte elementer på hjemmesiden skal
præsenteres.
Images: Indeholder billeder tilhørende temaet.
JS: Indeholder JavaScript tilhørende temaet.
SCSS: Indeholder SCSS filer, SCSS filerne bruges kun under udvikling, hvor slut produktet heraf erstatter
indholdet i CSS folderen.
Fallback i Magento
Magento gør brug af et robust fallback system, som vist i Tabel 9.
Udarbejdet af: Ulrik.
Side 11 af 53
5. Semester – Afsluttende projekt
Tabel 9 - Figur 9 fra [2] ”Magento Design guide”.
Et tænkt forløb ville være at lede efter en template-fil i det aktuelle tema fra Tabel 8. Her starter man med at
lede i tema folderen: ”app/design/frontend/rwd/kalejdoskopRWD/template”. Hvis filen er at finde, bruges
denne. Hvis den ikke er at finde, leder man i pakkens default placering, som i dette tilfælde vil være:
”app/design/frontend/rwd/default/template”. Som før hvis filen er fundet kan der begyndes, ellers søges en
sidste gang i: ”app/design/frontend/base/default/template”. Hvis filen ikke er tilstede her, returneres
søgningen med fejlen, at filen ikke blev fundet på ”app/design/frontend/base/default/template”.
Det er vigtigt at notere sig, at fejlen returnere slut stedet, og ikke der hvor man startede søgningen. Da filen
typisk vil skulle ligge i temaets folder, så der ikke skal ledes efter filen for ofte.
Moduler
Magento er modul baseret, det gør det nemt at skræddersy Magento. For Kalejdoskop har vi eksempelvis
deaktiveret enkelte nøglefeatures, da de ikke var interessante for kunden samt overskrevet andre for at
fremme det rette udtryk. Via Magento Administrations panel kan man deaktivere moduler og via Magentos
indbyggede downloader, Magento Connect Manager.
Udarbejdet af: Ulrik.
Side 12 af 53
5. Semester – Afsluttende projekt
Man kan via Magentos hjemmeside finde moduler og få deres modul nøgler. Med Magento Connect Manager
kan man således installere nye moduler og administrere installerede moduler. Det er en god måde at opdatere
og fjerne moduler, da man herved sikre, at få alle filerne fjernet fra sit system.
Dokumentation i Magento
I ”Designer’s Guide to Magento” [2] er en designanvisning for brug af Magento. Her var forventningen at finde
en standard måde at dokumentere klasser og filer på. I Magentos filer har jeg fundet et mønster for
dokumentation. I Tabel 10 under ”Notice of License” er et eksempel på en reference til en licens aftale der er at
finde i starten af hver fil. Sidst i ”Notice of license” er beskrevet hvad kategori, pakke og eventuelt modul filen
tilhører. Ud fra de oplysninger er filen relativt let at finde og følge i systemet. Som eksempler er her, hvordan
PHP og PHtml filer dokumenteres:
For PHP filer, Tabel 10 under ”For PHP”, er et eksempel på dokumentation fra en PHP fil. Dokumentationen og
klassenavn reflekterer filens placering i systemet. For metoder er der desuden dokumenteret, hvad metoden
gør, og hvilken type der returneres.
For PHtml filer, Tabel 10 under ”For PHtml filer”, kan man se hvilke blokke der er brugt til oprettelse af
dokumentet og via navngivningen deres placering i systemet.
Udarbejdet af: Ulrik.
Side 13 af 53
5. Semester – Afsluttende projekt
Notice of licence
For PHP filer: Eksempel placeret i:
sti: ”code/core/mage/catalog/block/product/view.php”
For PHtml filer: Eksempel placeret i:
sti: ”design/frontend/rwd/kalejdoskopRWD/template/catalog/product/view.phtml”
Tabel 10 - Magento dokumentations oversigt
Ved at have sammenhæng mellem placering i systemet og dokumentation/navngivning, giver det et utroligt
godt overblik over systemet, og hvor man skal ændre eller fejlfinde i koden.
Magento - MVC - Model View Controller
I Magento bruges MVC ikke traditionelt, da view og modellag ikke er adskilte. Det formodes at være på grund
af fleksibiliteten af at bruge være et CMS.
Udarbejdet af: Ulrik.
Side 14 af 53
5. Semester – Afsluttende projekt
Tabel 11 viser et hændelsesforløb fra en forespørgsel til den endelige visning i Magento. Først kommer der en
forespørgsel til systemet. Systemet finder herefter den rette controller til opgaven. Controlleren kan nu
manipulere data eller sende forespørgslen videre til view ved at indlæse layout. I view fyldes layout med
blokke, som igen fyldes med modeller fra model laget. Herefter bliver præsentations siden oprettet og sendt til
brugeren.
Tabel 11 - ”Rajesh's Tech Blog: Magento MVC Architecture fra http://www.php24.in/2010/11/magento-mvc-architecture.html”
I forhold til traditionel MVC er controllerne her meget tynde og indeholder kun basal funktionalitet, hvor meget
af forretnings logikken er flyttet op i præsentations laget. Det gør at lagene bliver knudret sammen og
overblikket let forsvinder.
Udarbejdet af: Ulrik.
Side 15 af 53
5. Semester – Afsluttende projekt
Magento ORM
Magento bruger en speciel lavet ORM10 der er basseret på Zend Framework til at oprette og gemme objekter i
MySQL. Der er to model typer som arver fra her sin klasse. De er:


Simple modeller, der arver fra: ”Mage_Core_Model_Resource_Db_Abstract”.
EAV11 modeller der arver fra: ”Mage_Eav_Model_Entity_Abstract”.
Data modeller
Data modeller er traditionelle SQL modeller. Der gemmes i statisk tilpassede database tabeller.
EAV Model
EAV modeller gemmes dynamisk i databasen i en samling af tabeller, hvor der gemmes i flere tabeller. Her er
en tænkt gennemgang, eksempel er vist i Tabel 12 ved et simplificeret EAV kunde objekt, der gemmes:
1. Entity tabellen tilskrives objektets id og type id.
2. Attribut tabellen, indeholder en liste af alle attributter der er i systemet. Her findes de attributter objektet
indeholder.
3. Value tabellen tilskrives objektets id, attribut id og værdi.
Objekt
(1) Entity tabel
(2) Attribut tabel
(3) Value tabel
ID: 1
ID: 1
ID: 10
ID: 1
Nvarchar: Navn
Attribut_id: 10
Type_id: 5
Type: Kunde
Værdi: Jens
Navn (Nvarchar): Jens
Tabel 12 - EAV Tænkt eksempel
EAV er en skalerbar og dynamisk måde at arbejde på, hvor man kan gemme alle slags og sammensætninger af
data. Problemerne ved EAV er, at det kræver flere kald i databasen for at samle data igen. I bedste tilfælde skal
der søges i tre tabeller, hvorefter data samles, frem for med simple modeller at kunne udføre én søgning.
Desuden må det forventes, at søgningerne i EAV bliver langsommere og langsommere, jo flere elementer der
er i kolonnerne.
10
11
Object Relational Mapping
Entity Attribute Value
Udarbejdet af: Ulrik.
Side 16 af 53
5. Semester – Afsluttende projekt
Debug i Magento
Det har været nødvendigt at finde et værktøj til at debugge Magento med, da det hurtigt kan bliver meget
komplekst at ændre eller tilføje til Magentos kode. Magento laver logfiler på serveren, hvor der er en log for
fejl og en for systembeskeder.
Som det fremgår af Tabel 13 - "Magento fejl og system log" får man, ud fra loggen, et klart billede af, hvor og
hvornår det er gået galt. Ved fejl loggen får man et billede af stacken, så man kan finde tilbage til det område,
hvor fejlen skete. Med system loggen får man i de fleste sager ikke en stack, men derimod den berørte linje og
hvad problemet var i linjen.
Fejl log:
System log:
Tabel 13 - "Magento fejl og system log"
xDebug i Magento
xDebug er en debug udvidelse til PHP. Med xDebug laver man en forbindelse til sit IDE og PHP script. Herved
kan man via sit IDE live debugge PHP scriptet. Det har fungeret perfekt efter hensigten, hvor man i IDE tænder
for forbindelsen og sætter et break point. Når hjemmesiden når til break point, får man kontrollen i IDE, hvor
man kan se de aktive Variabler. Tabel 14 - "Debug af Magento" viser et eksempel over debug af produkt
visning, hvor man kan se værdierne for ”$_product” og list af den data, det objekt har på sig.
En af ulemperne ved xDebug er, at jeg ikke kan bruge selve metoden som break point, men jeg skal bruge PHP
kode snips som break point.
Udarbejdet af: Ulrik.
Side 17 af 53
5. Semester – Afsluttende projekt
Tabel 14 - "Debug af Magento"
Integration / API
Magento har integration til REST og SOAP Api. Da Magento er en open source e-handels platform, er det oplagt
at understøtte integrationer til web services.
Udarbejdet af: Ulrik.
Side 18 af 53
5. Semester – Afsluttende projekt
Teknologi
I projekt perioden har jeg arbejdet i med forskellige teknologier. Jeg vil i dette afsnit beskrive dem.
FTP
På test og live server har jeg opdateret filerne via en FTP-server.
phpMyAdmin
Ændringer i databasen er foregået via phpMyAdmin panel. phpMyAdmin er blevet brugt både lokalt og i online
miljøerne, hvilket har bidraget til en meget overskuelig proces.
Lokal Bitnami VM med Magento
Til at arbejde lokalt med Magento, brugte jeg en Virtuel maskine fra Bitnami. Det fungerede som en lukket
boks, hvor jeg via interface havde mulighed for at starte og stoppe VM. VM fra Bitnami brugte samme struktur
som på live og test serverne jeg brugte. Det var rigtigt godt med samme struktur hele vejen rundt, da jeg på
den måde kunne arbejde parallelt.
I VM fra Bitnami var en Apache server og en MySQL server. Til håndtering af MySQL var phpMyAdmin.
Test server
Test serveren er en klonet kopi af live site, begge ligger på servere hos udbyderen Powerhosting.
Opdateringsproces
Under udviklingen har jeg eksperimenteret og udviklet lokalt. Hvorefter jeg har opdateret test serveren, hvor
kunden havde mulighed for at kontrollere og godkende de ændringer, jeg havde lavet. Herefter blev live
serveren opdateret.
Backup
Powerhosting laver dagligt backup af live miljø. Backup er tilgængelig via en FTP server. Som vist i Tabel 15
gemmes backup af database og hjemmeside særskilt og i forskellig tid.
Database
Hjemmeside
Daglig backup
Op til 31 dage.
Op til 7 dage.
Månedsbackup
Op til 1 år.
Op til 1 år.
Tabel 15 - Backup lagrings tider
Udarbejdet af: Ulrik.
Side 19 af 53
5. Semester – Afsluttende projekt
Det giver god mening at gemme mange kopier af databasen, da den er meget forretningskritisk. Opstår et
problem, kan man gå tilbage til et specifikt tidspunkt før dette indtraf.
Der foretages ikke nær så mange lagringer af hjemmesiden som af databasen. Det kunne skyldes, at
hjemmesidens filer ikke er nær så kritiske og lettere at genskabe, hvis der skulle være problemer. Når en
Magento hjemmeside er kørende, vil den største forskel på de forskellige udgaver af backup være billeder i
medie mapperne.
IDE
Et IDE12 er et udviklings værktøj som kan stå alene og bruges til udviklingen af et program. Typisk en kode
editor, kompiler og debugger med et grafisk bruger interface.
Atom
Tidligt i projektet brugte jeg Atom [3], et open source notesblok program. Med Atom vist i Tabel 16 kan man få
et godt overblik over projektet og kode highlighting.
Tabel 16 - Brugerflade eksempel fra Atom
12
Integrated Development Environment
Udarbejdet af: Ulrik.
Side 20 af 53
5. Semester – Afsluttende projekt
Visual Studio
Visual Studio [4], et IDE udviklet af Microsoft og indeholder en integreret versions styring: Team Foundation
Server”. Visual Studio understøttede ikke PHP og kunne derved ikke bruge det som et IDE i mit projekt.
Versionsstyringen kunne bruges separat ved at oprette et hjemmeside projekt i Visual Studio og inkludere
projektfilerne.
PHPStorm
PHPStorm [5], et PHP IDE udviklet af JetBrains. PHPStorm vist i Tabel 17 indeholder utroligt mange features,
blandt de vigtigste er:



Intelligent kode editor
Debugging og test værktøjer
Versions styring
Tabel 17 - Brugerflade eksempel fra PHPStorm
Risici registrering
For projektet registrerede og fulgte jeg den samlede risici eksponering af projektet løbende. Jeg havde et Excel
ark hvori jeg noterede risiko tekst, sandsynlighed for udfald, størrelsen af tab og risikoens eksponering.
Risikoens eksponering er beregnet ved at gange sandsynligheden med tabets størrelse i dage.
Derudover lavede jeg også et Risici Burndown diagram, med den samlede risici for hvert sprint.
Udarbejdet af: Ulrik.
Side 21 af 53
5. Semester – Afsluttende projekt
Udviklingsmetoder
Scrum
Scrum er en agil udviklingsmetode, der definere, hvordan et projekt skal styres.
Scrum hoved principper:





Selv organiserende teams
Iterativ udvikling, max 4 uger.
Låste krav i aktive sprint.
Krav listes i en Product Backlog.
Review som afslutning af hver sprint, med interessenter.
Scrum begreber og processer
Roller
Product Owner
Product Owner er en kunde repræsentant, og er den primære kontaktperson mellem team og virksomheden.
Product Owners opgaver er:

Definering af krav/features i Product Backlog.

Fastlægger release datoer.

Prioritere Product Backlog efter forretnings værdi.

Klargør Product Backlog før hver Sprint Planning Meeting.

Godkender eller afviser features ved Sprint Review Meeting.
Scrum Master
Scrum master repræsentere ledelsen i projektet. Scrum master opgaver er:

Kommunikationsled mellem Team og Product Owner.

Står for kommunikation mellem Team og den ydre verden, så teamet ikke bliver forstyrret.

Ansvarlig for team overholder Scrum værdier og praktikker.

Styrer teamet ved møder.

Fjerner forhindringer for teamet.

Er coach for teamets medlemmer, fremmer samarbejde, sikre ressourcer…
Team
Scrum Teamet:
Udarbejdet af: Ulrik.
Side 22 af 53
5. Semester – Afsluttende projekt

Har en ideel størrelse på 7 - 9 personer.

Ingen faste roller eller opgaver, alle gør alting.
o
Eks. analysere, design, programmer, test, estimering, planlægning, opfølgning.

Arbejder fuld tid i teamet.

Er selvorganiserende, finder internet ud af hvordan de vil arbejde.

Er låst til projektet i perioden, der er derved ikke tilladt udskiftninger af medarbejdere i en sprint periode.
Artefakter
Product Backlog
Product Backlog er en to-do liste af alle kundens krav, som eksisterer hele projektets levetid. Product Owner
har ansvaret for prioritering og vedligeholdelse af Product Backlog.
De højst prioriterede elementer i Product Backlog estimeres og beskrives mere detaljeret end lavt prioriterede
elementer. Detaljegraden af elementer i Product Backlog kan variere fra en overskrift til en Story eller Use
Cases.
Sprint Backlog
Sprint Backlog er en udvalgt liste af opgaver, der skal udføres i det angivne sprint og eksistere kun i det aktive
sprints levetid. Sprint Backlog laves i samarbejde mellem Team og Product Owner ved Sprint Planning Meeting,
og er her herefter låst resten af sprintet. Sprint Backlog fyldes ved Sprint Planning Meeting med de højst
prioriterede elementer i Product Backlog. Elementer fra Product Backlog kan opdeles i mindre bidder for bedre
at kunne blive estimeret og tilføjet til Sprint Backlog.
Burndown
Burndown bruges til at illustrere fremdriften i det aktuelle sprint. Grafen summerer de tilbageværende
arbejdsopgavers værdi i forhold til det antal resterende dage i sprintet, gange med teamets velocity.
Burndown opdateres hver dag, og grafen indikere om teamet har for meget/lidt arbejde tilbage til den
resterende del af sprintet. Burndown skal være synligt for alle teamets medlemmer og eksistere kun i det
aktive sprints levetid.
Teamets velocity angives som det samlede antal story point, teamet kan lave på en given dag.
Udarbejdet af: Ulrik.
Side 23 af 53
5. Semester – Afsluttende projekt
Ceremonier
Sprint Planning Meeting
Før Sprint Planning Meeting har Product Owner fået re-prioriteret Product Backlog, så de aktuelt forretnings
vigtigste er top prioriteret.
Sprint Planning Meeting afholdes før starten af hvert sprint. Her fastlægges mål for sprintet, planlægning af
sprintet og overordnet design overvejelser i forbindelse med udvalgte opgaver. Team og Product Owner
beslutter i samarbejde hvad der skal med i næste sprint, ud fra Return of Investment for kunden. De diskutere
indholdet af de højst prioriterede elementer og efter behov opdeler disse i mindre bidder. Herefter estimeres
de, eventuelt med planning poker. Hvorefter de højst prioriterede elementer udvælges og tilføjes til Sprint
Backlog.
Standup Meeting
Standup Meeting er et kort dagligt møde teamet holder internt. Mødet holdes stående for at sikre et kort og
engageret møde. Til Standup Meeting vil det være oplagt at opdatere Burndown, så man har den at forholde
sig til i forhold til status.
Målet er at alle får svaret på følgende:

Hvad har vi lavet siden i går?

Hvad skal der laves i dag?

Er der forhindringer?
Ved Standup Meeting skal alle teamets medlemmer på tur give status og det er ikke tilladt at diskutere men
informere. Herefter er det Scrum Masters opgave at tage sig af eventuelle problemer.
Sprint Review
Efter endt sprint, afholdes Sprint Review. Her deltager Team, Product Owner og interessenter. Team
præsentere det de har lavet i sprint og fået det vurderet af Product Owner. Product Owner vurdere hvad der:


Var godt eller mindre godt?
Skal tilbage til Product Backlog?
Sprint Retrospektive
Sprint Retrospektive er et internt møde for Team hvor sprintet evalueres:
Udarbejdet af: Ulrik.
Side 24 af 53
5. Semester – Afsluttende projekt

Hvad gik godt?

Hvad kunne have været bedre?

Hvad overraskede os?
Med Sprint Retrospektive er målet af Teamet konstant udvikler sig til at blive bedre.
Scrum begreber og proces forløb
I Tabel 18 kan man se et traditionelt forløb med Scrum:
1. Product Owner indsamler og lister ønskede features i Prioriteret Product Backlog.
2. Product Owner og Team laver ved Sprint Planning Meeting en Sprint Backlog.
3. Team udfører sprint med daglige Standup Meetings.
4. Product Owner og Team udfører Sprint Review.
5. Team udfører Sprint Retrospektive.
6. Herefter gentages punkterne 1-5 til projektet er færdigt.
Tabel 18 - Scrum begreber og proces, fra [6] ”Agile Methods Of Software Development”
Udarbejdet af: Ulrik.
Side 25 af 53
5. Semester – Afsluttende projekt
Scrum Buts
Scrum fungere som en helhed, hvor elementerne supplere hinanden. Det er derfor vigtigt for at kunne se
konsekvenserne ved at fjerne elementer fra Scrum at notere hvordan og hvorfor man ikke overholder Scrum.
Eks. Vi bruger Scrum, men Standup Meeting hver dag udføres ikke, da det tager for lang tid. Men vi laver det
hver mandag.
Solo Scrum
Scrum er designet med fokus på teams, hvor den optimale størrelse er af 7-9 personer. Da jeg laver dette
projekt alene valgte jeg at undersøge om der på nettet var eksempler for implementering af Scrum alene.
Jeg fandt en interessant artikel [7] ”Solo Scrum” hvor forfatteren arbejdede helt alene på et internt projekt og
brugte Scrum. Artiklen var særligt interessant da der er mange konstruktive kommentarer der føre til en debat
om brug af Scrum alene.
I artiklen forklare han hvordan han i projektet havde alle projekt rollerne, og skiftede mellem dem efter behov
og herved kunne anskue projektet forskelligt efter hvilken rolle han udfyldte. Han beskrev ikke hvordan eller
om han udføre Standup Meeting eller Review. Men om brugen af Standup Meetings alene argumenterede han
for at formålet var at give teamet et samlet overblik over processen. Hvorved enkelt personer ville have lettere
ved selv at gennemgå og se deres status. Den samme vurdering af retrospekt, hvor en enkelt person burde
være i stand til at vurdere og perspektivere over processen.
Han havde også arbejdsopgaver ved siden af projektet i hans sprint. Hvor han både solgte og ydede support.
Ud fra artiklen virker det meget rodet at have Product Owner og Team rollerne blandet sammen, det vil jeg for
alt i verden undgå. Det kan også være et kæmpe problem hvis man ikke har 100% fokusere på opgaven i sprint
perioderne, så kan deadlines og hele projektet hurtigt flyde ud i sandet, specielt når han som i artiklen selv står
for alle Scrum rollerne.
En udfordring ved at være alene i Scrum team, må være at få reflekteret over processen. Til det forestiller jeg
mig at skrive noter for de enkelte dage og herefter at skrive refleksionerne ned ud fra dem. Målet med noterne
er at sikre der er et starts indhold til retrospektiv og ved at genlæse noten kunne det føre til en ny refleksion.
Alt i alt virker det til Scrum kan fungere som enkelt person. Dog ser jeg det som et krav at Product Owner og
Team holdes afskilt.
Udarbejdet af: Ulrik.
Side 26 af 53
5. Semester – Afsluttende projekt
XP13
XP er en agil udviklingsmetode, der definere hvordan der skal arbejdes i projektet, via en række praktikker.
Grund ideen bag XP er at man skal tage den sunde fornuft til ekstremerne og samtidig opnå en god kvalitet for
kunden og af koden. XP bruger Praktikker og Værdier til at definere hvordan der skal arbejdes med XP. Det er
vigtigt for at få det fulde udbytte af XP at alle praktikker og værdier overholdes.
XP Praktikker
XP har en række praktikker som når de bruges samlet i et projekt, hjælper med til at opretholde en vis kvalitet
af arbejdet. Praktikkerne er i Tabel 19.
XP Praktikker
Par programmering
2 udviklere, 1 tastatur.
Planning Game
Team og Kunde estimere opgavers værdi.
Test først udvikling
Der laves test først og herefter kodes til testen opfyldes.
Kundeinvolvering
Kunden stiller og definere kravene løbende.
Løbende integration
Dagligt kompilering og integrering.
Refaktorering
Koden forbedres løbende.
Små udgivelser
Små releases.
Kodestandard
Kodestandard.
Kollektivt ejerskab
Enhver i teamet har overblik og kan ændre hvad som helst.
Simpelt design
Koden dækker kun de opstillede krav.
Metafor
Fælles terminologi og begreber.
37 timers arbejdsuge
Fokuserede medarbejdere, mindsker fejl.
Tabel 19 - XP Praktikker
XP Værdier
XP værdier er i Tabel 20.
XP Værdier
Forenkling
Kommunikation
Mod
Tilbagemelding
Tabel 20 - XP Værdier
13
eXtreme Programmering
Udarbejdet af: Ulrik.
Side 27 af 53
5. Semester – Afsluttende projekt
Solo XP
Jeg fandt en diskussions tråd [8] ”Extreme Programming For One” med et tænkt eksempel, om en Solo udvikler
kunne få udbytte af at bruge XP. I diskussionen konkluderes at han godt kunne bruge XP. Men at han som
kompensation for at ikke kunne udføre par programmering, skulle opføre sig som en partner og revurdere
koden. Eller ved tilfældige intervaller stille sig selv spørgsmålene:




Hvor længe er det siden du sidst har tjekket ind?
Du har tænkt dig at optimere det her, ikke?
Er det den mest optimale måde at lave det på?
Har du lavet en testet til dette?
Jeg vurderede at XP praktikkerne ville være gavnlige som supplement til Scrum i et en mands projekt. Dog med
forbehold om at være ekstra kritisk til egen kode.
Projekt
Metode valg
I dette projekt valgte jeg at arbejde agilt frem for plandrevet. Valget er truffet på en agil udviklings metode da:



Kunden ikke har fast definerede krav for projektet.
Arbejdsopgavernes kompleksitet har ikke været høj og med et lille team har det ikke været nødvendigt
med meget dokumentation.
Med kundeinvolvering kan kunden vurdere og komme med ændringer til produktet i forløbet.
Valget er faldet på Scrum og XP praktikker. Jeg har tidligere arbejdet på den måde i hold af 4 personer.
Udfordringen denne gang er at være alene om projektet, hvor Scrum og XP praktikker er designet til hold. Jeg
har valgt at finde eksempler for implementering af Scrum og XP i en mands hold.
I det følgende beskrives hvordan Scrum og XP praktikker implementeres i projektet.
Implementering af Scrum
I projektet er jeg både Scrum Master og Team. Product Owner er Sofie, en fast kontakt person hos Kalejdoskop.
Som Sprint Board vil jeg bruge Trello.com med ”Scrum for Trello” plugin og layout fra Tabel 21 til Scrum Board.
Med Scrum Board får jeg et godt overblik over opgaverne og status i det aktuelle sprint. Plugin giver
muligheden for at se Burndown i sprintet.
Udarbejdet af: Ulrik.
Side 28 af 53
5. Semester – Afsluttende projekt
Product Backlog
Product Backlog
Sprint
Story
To Do
In Progress
Afsluttede Sprint X
To Verify
Done
Afsluttede Sprint X
Tabel 21 - Scrum board i Trello
Hver tirsdag er planen sammen med Product Owner at udføre: Sprint Review og Sprint Planning. Product
Owner er ikke i stand til at estimere opgavers værdi, så ved Sprint Planning har jeg estimeret de top
prioriterede opgaver i Product Backlog hvorefter Product Owner har sorteret og udvalgt opgaver til sprint fra
Product Backlog. Herefter vil jeg udføre Sprint Retrospektive og bruge de skrevne noter som udgangspunkt.
Scrum But Projekt
Sprint Backlog er i projektet låst i det omfang at Product Owner ikke mens Sprintet er aktivt kan ændre dets
indhold eller mål. Men Scrum Master og Team kan tilføje uventede opgaver så længe det ikke influere sprintets
mål.
Implementering af XP praktikker
I projektet vil jeg bruge XP praktikker til at understøtte Scrum. I Tabel 22 er en vurdering af hvordan XP
praktikkerne kan implementeres ud fra overvejelser om Solo XP.
XP Praktikker implementeret i Scrum projekt
Løbende integration
Efter hver dag opdateres test serveren med de nyeste ændringer. Herved kan
ændringerne testes før de lanceres på live serveren.
Refaktorering
Koden forbedres løbende. Der oprettes ”TODO” tags i koden når den er skrevet, med
en beskrivelse af hvordan koden kan optimeres.
Kodestandard
Ved ændring eller udarbejdelse af kode vurderes kodestandarden i den eksisterende
først hvorefter koden skrives.
Kollektivt ejerskab
Teamet skal have ejerskab over koden og ved større ændringer eller implementering af
kode skrives kommentarer, så fremtidige brugere kan få overblik over koden.
Simpelt design
Koden skal kun dække de opstillede krav.
Metafor
Fælles terminologi og begreber.
8 timers arbejdsdag
For at få struktur på dagene har jeg valgt en fast arbejdsdag af 8 timer.
Test først udvikling
Der skal om muligt laves tests for arbejdsopgaver.
Implementeret via Scrum
Små udgivelser
Udarbejdet af: Ulrik.
Der arbejdes i 1 uges Scrum sprint, ved de korte sprint kan
Side 29 af 53
5. Semester – Afsluttende projekt
Kundeinvolvering
Kunden involveres som Product Owner i projektet. Hvor kunden løbende definere krav.
Planning Game
Kunden har ikke erfaring med estimering af arbejdsopgaver, derfor estimeres og
vurderes opgaverne af Scrum team.
Undladt implementeret
Par programmering
Der forsøges at kompensere for Par programmering ved ekstra kritisk at forholde sig til
kvaliteten af koden. Ved at agere partner efter koden er skrevet.
Tabel 22 - XP Praktikker
Produkt Backlog
I Tabel 23 er Product Backlog fra projekt forløbet. Listen er sorteret i den rækkefølge opgaverne er blevet
udført. Opgaver markeret med fed er tilføjet til den oprindelige Product Backlog.
ID
Type
Værdi Title
Løst i
1
Spike
8
Opsætte udviklings miljø
Sprint 0
2
Task
8
Projekt struktur
Sprint 0
3
Spike
8
Forside
Sprint 0
4
Story
2
Cookie warning
Sprint 1
5
Task
0,5
Banner Fjern eksisterende
Sprint 1
6
Story
1
Menu
Sprint 1
7
Task
2
Ændre sprog til dansk
Sprint 1
8
Task
0,5
Opdatere footer så den er responsiv/mobilvenlig
Sprint 1
9
Task
1
Fjern ubrugte moduler
Sprint 1
10 Task
2
Opdater moduler til nyeste version
Sprint 1
38 Task
2
Akut Aktiver Cron mail forsendelse
Sprint 1
39 Task
3
Magento Undersøg Cron mail Sender ikke konsistent
Sprint 1
11 Story
3
Blog
Sprint 2
12 Task
5
Finde og rette fejl på kategori side
Sprint 2
13 Task
5
Tilpasse kategori side så den er responsiv
Sprint 2
14 Task
3
Tilpasse produkt side design
Sprint 2
15 Task
2
Tilpasse produkt side så den er responsiv
Sprint 2
16 Story
5
Filtrering af brands
Sprint 2
Udarbejdet af: Ulrik.
Side 30 af 53
5. Semester – Afsluttende projekt
17 Task
5
Filtrering af flere brands
Sprint 2
18 Spike
8
Undersøg udnyttelse af klient-cache
Sprint 2
40 Task
0,5
Opret produkt egenskab materiale
Sprint 3
41 Task
1
Opdatere blog linje afstand
Sprint 3
42 Task
1
Opdatere blog kategorier
Sprint 3
43 Task
0,5
Opdatere frontend navngivning af produkt beskrivelser, lang og kort
Sprint 3
44 Task
2
Ændre produkt beskrivelser, lang og kort. Så de bruger samme formatering
Sprint 3
45 Spike 8
Skift udviklings miljø til PHPStorm
Sprint 3
46 Spike 8
Tilpasse filtrering af kategorier så rod kategorier for valgt kategori altid er
Sprint 3
tilgængelige
47 Story
20
Filtrering
Sprint 4
48 Task
8
Ad hoc ændringer for at opfylde E-mærke
Sprint 4
49 Task
5
Tilføje harmonika foldning til filtrerings underkategorier
Sprint 5
50 Task
3
Forhindre at filtrering pakkes ud når den er aktiv
Sprint 5
51 Task
3
Automatisk udfoldning af aktiv kategori
Sprint 5
19 Task
5
Tilpas produkt side, så billede tekst bliver vist
Sprint 5
20 Task
5
Tilpas produkt side, så korrekte billeder bliver vist, nu er det et hovedbillede for
Sprint 5
meget
21 Task
3
Tilpasse standard sider, så body passer i nyt tema
Sprint 5
52 Task
8
Møde med Ipos angående skift til deres system
Sprint 6
53 Task
2
Forside styling(: Center) af nyhedsbrev
Sprint 6
22 Spike
8
Undersøg forskellige forside alternativer
Sprint 6
23 Task
5
Opret og implementer venstre side banner
24 Task
8
Tilpasse banner til tema
25 Task
8
Undersøg og implementer popup, via Banner Slider
26 Task
5
Flyt indretning fra en CMS side til en WordPress blog
27 Task
8
Tilpas side banner, så de følger siden når der scrolles
28 Task
2
Tilpas quick søgnings vindue, så popup vinduet hænger sammen med
indtastningsvinduet
29 Spike
8
Udarbejdet af: Ulrik.
Undersøg og udnyt Robots.txt
Side 31 af 53
5. Semester – Afsluttende projekt
30 Story
20
Billede skift på produkt side
31 Spike
8
Undersøg og løs hvorfor cache konstant skal fornyes
32 Task
8
Menu elementer skal sorteres lodret, frem for vandret (Billede)
33 Task
8
Bruger indtastet værdi Gavekort
34 Spike
8
Auto skaller billeder til device via JS
35 Task
8
Tilpas menu placering ved åbning
36 Task
1
Ændre hvordan footer folder responsivt
37 Task
5
Guide til oprettelse af produkter
49 Spike 8
Undersøg muligheden for TDD af Magento
55 Task
Flere valg, ikke synlig ved søgning
5
Tabel 23 - Produkt Backlog for projekt
Udarbejdet af: Ulrik.
Side 32 af 53
5. Semester – Afsluttende projekt
Sprint
Sprint 0
Sprint planning
Sprint 0 brugte jeg til at få sat opsat udviklings miljø og testet spikes. Sprint Backlog for Sprint 0 er vist nedenfor
i Tabel 24:
ID
Type
Værdi
Title
Løst i
1
Spike
8
Opsætte udviklings miljø
Sprint 0
2
Task
8
Projekt struktur
Sprint 0
3
Spike
8
Forside
Sprint 0
Tabel 24 - Sprint 0 Sprint Backlog
Retrospektive
Burndown
Burndown for Sprint 0 er vist i Tabel 25.
Burndown Sprint 0
30,0
25,0
20,0
15,0
10,0
5,0
0,0
22-04 Start
22-04 Slut
23-04 Start
Dag 1
23-04 Slut
27-04 Start
Dag 2
Burndown Sprint 0 (21-04 <> 28-04)
27-04 Slut
Dag 3
Ideel
Tabel 25 - Sprint 0 Burndown
I løbet af sprint 0 fik jeg afsluttet alle de udvalgte emner fra Sprint Backlog i Tabel 24. Fra Burndown vist i Tabel
25 kan man se at det aktuelle og ideelle estimerede forbrug stemmer overens. Af det kan man lede at
indholdet i Sprint Backlog har været estimeret korrekt.
Udarbejdet af: Ulrik.
Side 33 af 53
5. Semester – Afsluttende projekt
Hvad gik godt?
Tidsplanen holdt
Hvad kunne have været bedre?
I løbet af sprint oprettede jeg 3 risiko opgaver, i Tabel 39 med ID 1-3.
Hvad overraskede?
Ikke noget at nævne.
Sprint 1
Sprint planning
I sprint 1 startede jeg for alvor på projektet. Her startede jeg ud sammen med Produkt Owner at udvælge de
højest prioriterede opgaver fra Product Backlog som skulle med i Sprint Backlog. Sprint Backlog er vist i Tabel
26.
ID
Type
Værdi
Title
Løst i
4
Story
2
Cookie warning
Sprint 1
5
Task
0,5
Banner Fjern eksisterende
Sprint 1
6
Story
1
Menu
Sprint 1
7
Task
2
Ændre sprog til dansk
Sprint 1
8
Task
0,5
Opdatere footer så den er responsiv/mobilvenlig
Sprint 1
9
Task
1
Fjern ubrugte moduler
Sprint 1
10
Task
2
Opdater moduler til nyeste version
Sprint 1
18
Spike
8
Undersøg udnyttelse af klient-cache
Sprint 2
24
Task
8
Tilpasse banner til tema
38
Task
2
Akut Aktiver Cron mail forsendelse
Sprint 1
39
Task
3
Magento Undersøg Cron mail Sender ikke konsistent
Sprint 1
Tabel 26 - Sprint 1 Sprint Backlog
I Tabel 26 blev de to opgaverne med ID: 38 og 39 tilføjet mens sprintet var i gang.
Review
I sprintet løb jeg ind i en række akutte problemer, efter jeg opdaterede Magento fra version 1.9.1.0 til 1.9.1.1. I
første omgang havde jeg udført opdateringen på mit lokale og på Test-serveren uden problemer. Da jeg
Udarbejdet af: Ulrik.
Side 34 af 53
5. Semester – Afsluttende projekt
opdaterede Live-serveren, resulterede det i en http fejl 500 ”HTTP Error 500 Intern server fejl”. Det viste sig at
være et problem med tilladelserne for ”index.php”, hvor filen udsatte systemet for en sikkerhedsrisiko.
Dag 3 præsenterede et nyt akut problem sig, ved at Live-serveren ikke længere sendte salgs mails ud. Til at løse
dette oprettede jeg en opgave med ID 38 i Sprint Backlog.
Efter Cron igen kom til at virke dukkede et nyt problem op, hvor enkelte mails ikke blev afsendt. Til at løse
dette oprettede jeg en opgave med ID 39 i Sprint Backlog.
Retrospektive
Burndown
Burndown for Sprint 1 er vist i Tabel 27.
Burndown Sprint 1
30,0
25,0
20,0
15,0
10,0
5,0
0,0
29-04 Start
29-04 Slut
Dag 1
30-04 Start
30-04 Slut
04-05 Start
Dag 2
Burndown Sprint 1 (28-04 <> 05-05)
04-05 Slut
Dag 3
Ideel
Tabel 27 - Sprint 1 Burndown
Problemerne i sprint 1 resulterede i at jeg sidst på anden dagen fjernede opgave 18 af 8 point, da jeg var
kommet for langt bag ud i forhold til tidsplanen. På dag 3 tilføjede jeg fra morgenstunden opgaverne 38 og 39.
Sidst på dag 3 fjernede jeg opgave 24 da jeg ikke kunne nå den.
Hvad gik godt?
Det har fungeret godt med en fast ugentlig dag til Review, Retrospektive og Sprint Planning. Hvor der rigtigt er
tid til at fokusere på processen.
Udarbejdet af: Ulrik.
Side 35 af 53
5. Semester – Afsluttende projekt
Hvad kunne have været bedre?
Ved opdateringer vil jeg frem ad rettet afsætte markant mere tid til det, og bruge mere tid på at teste at det
virker. Særligt med henblik på test af mail og betaling, som kun kan testes på Live serveren.
I løbet af sprint oprettede jeg en risiko opgave i Tabel 39, med ID 4. Da der kunne være flere foldere og filer
med forkert tilladelser på serveren.
Hvad overraskede?
Det overraskede at jeg havde brugt så meget tid problemer i forbindelse med opdateringen og de medfølgende
problemer.
Sprint 2
Sprint planning
Sprint Backlog for sprint 2 er vist i Tabel 28:
ID
Type
Værdi
Title
Løst i
11
Story
3
Blog
Sprint 2
12
Task
5
Finde og rette fejl på kategori side
Sprint 2
13
Task
5
Tilpasse kategori side så den er responsiv
Sprint 2
14
Task
3
Tilpasse produkt side design
Sprint 2
15
Task
2
Tilpasse produkt side så den er responsiv
Sprint 2
16
Story
5
Filtrering af brands
Sprint 2
17
Task
5
Filtrering af flere brands
Sprint 2
18
Spike
8
Undersøg udnyttelse af klient-cache
Sprint 2
Tabel 28 - Sprint 2 Sprint Backlog
Review
Sprintet forløb som planlagt, dog var opgaverne 16 og 17 noget mere komplekse end først antaget.
Udarbejdet af: Ulrik.
Side 36 af 53
5. Semester – Afsluttende projekt
Retrospektive
Burndown
Burndown Sprint 2
40,0
35,0
30,0
25,0
20,0
15,0
10,0
5,0
0,0
06-05 Start
06-05 Slut
Dag 1
07-05 Start
07-05 Slut
08-05 Start
Dag 2
Burndown Sprint 2 (05-05 <> 12-05)
08-05 Slut
Dag 3
11-05 Start
11-05 Slut
Dag 4
Ideel
Tabel 29 - Sprint 2 Burndown
Sprintet forløb efter planen for de første to dage. Efter dag 3 kunne jeg se jeg var ved at komme bag ud, men
havde en forventning om at jeg ville indhente det på 4. dagen. På dag 4 nåede jeg at indhente det, så alle
opgaverne blev afsluttet.
Hvad gik godt?
Jeg har i sprint 2 fået en bedre forståelse for Magentos opbygning og struktur.
Hvad kunne have været bedre?
Underestimering af opgaver er stadig et problem.
Hvad overraskede?
Ikke noget at nævne.
Udarbejdet af: Ulrik.
Side 37 af 53
5. Semester – Afsluttende projekt
Sprint 3
Sprint planning
ID Type
40 Task
Værdi Title
0,5
Opret produkt egenskab materiale
Løst i
Sprint 3
41 Task
1
Opdatere blog linje afstand
Sprint 3
42 Task
1
Opdatere blog kategorier
Sprint 3
43 Task
0,5
Opdatere frontend navngivning af produkt beskrivelser, lang og kort
Sprint 3
44 Task
2
Ændre produkt beskrivelser, lang og kort. Så de bruger samme formatering
Sprint 3
45 Spike
8
Skift udviklings miljø til PHPStorm
Sprint 3
46 Spike
8
Tilpasse filtrering af kategorier så rod kategorier for valgt kategori altid er
Sprint 3
tilgængelige
Tabel 30 - Sprint 3 planning
Review
I sprint 3 skiftede jeg udviklings miljø til PHPStorm. Nu var det på tide at komme dybere ned i Magento, efter at
have arbejdet i overfladen med at lave design og layout. Indtil nu havde jeg brugt en notepad: Atom og Visual
Studio. Med skift til et IDE forventes at kunne håndtere mere komplekse opgaver.
Efter skiftet til PHPStorm har det har været interessant at arbejde med et komplekst emne som filtrering. Hvor
jeg har kunnet gå i dybden med filtrerings eksperiment. Ved møde med kunden fik vi design på plads for
hvordan de ønskede filtrering designet. I det følgende sprint skulle jeg fortsætte udviklingen på eksperimentet.
Til arbejdet med filtrering lavede jeg en skitseret Domæne model over filtrering (se Tabel 31) for at få et bedre
overblik, det gav et godt overblik over situationen og hvor lidt der skulle ændres for at opnå det ønskede.
Tabel 31 - Domæne model filtrering
Udarbejdet af: Ulrik.
Side 38 af 53
5. Semester – Afsluttende projekt
Retrospektive
Burndown
Burndown Sprint 3
30,0
25,0
20,0
15,0
10,0
5,0
0,0
13-05 Start
13-05 Slut
15-05 Start
Dag 1
15-05 Slut
18-05 Start
Dag 2
Burndown Sprint 3 (12-05 <> 19-05)
18-05 Slut
Dag 3
Ideel
Tabel 32 - Sprint 3 Burndown
Sprintet forløb som planlagt.
Hvad gik godt?
Efter sprint 3 har jeg fået en endnu bedre platform at arbejde PHP med. Hvor jeg nu er i stand til at debugge
PHP koden og objekter. Herved forventer jeg at kunne arbejde med mere komplekse emner og mere effektivt.
Estimeringen af opgaverne passede godt i sprintet.
Hvad kunne have været bedre?
Ikke noget at nævne.
Hvad overraskede?
Det overraskede at jeg havde brugt så meget tid problemer i forbindelse med opdateringen og de medfølgende
problemer.
Udarbejdet af: Ulrik.
Side 39 af 53
5. Semester – Afsluttende projekt
Sprint 4
Sprint planning
ID
Type
Værdi
Title
Løst i
47
Story
20
Filtrering
Sprint 4
48
Task
8
Ad hoc ændringer for at opfylde E-mærke
Sprint 4
Tabel 33 - Sprint 4 planning
Retrospektive
Burndown
Burndown Sprint 4
30,0
25,0
20,0
15,0
10,0
5,0
0,0
20-05 Start
20-05 Slut
Dag 1
21-05 Start
21-05 Slut
22-05 Start
Dag 2
Burndown Sprint 4 (19-05 <> 26-05)
22-05 Slut
Dag 3
Ideel
Tabel 34 - Sprint 4 Burndown
Sprintet forløb som planlagt.
Hvad gik godt?
Estimeringen af opgaverne passede godt i sprintet. Med PHPStorm var jeg i stand til at få et godt overblik over
problemet og i den forbindelse finde og bruge eksisterende kode til filtrering.
Hvad kunne have været bedre?
Efter at have skiftet IDE fandt jeg ud af at det er muligt at lave tests, men jeg har ikke fået eksperimenteret
med det. Jeg har fundet at der traditionelt ikke udføres tests af Magento, hvorved der ikke er så meget
information om det. Derfor har jeg valgt at oprette opgave 49 som en spike i Product Backlog.
Udarbejdet af: Ulrik.
Side 40 af 53
5. Semester – Afsluttende projekt
Hvad overraskede?
Ikke noget at nævne.
Sprint 5
Sprint planning
ID
Type Værdi Title
Løst i
50 Task
5
Tilføje harmonika foldning til filtrerings underkategorier
Sprint 5
51 Task
3
Forhindre at filtrering pakkes ud når den er aktiv
Sprint 5
52 Task
3
Automatisk udfoldning af aktiv kategori
Sprint 5
19 Task
5
Tilpas produkt side, så billede tekst bliver vist
Sprint 5
20 Task
5
Tilpas produkt side, så korrekte billeder bliver vist
Sprint 5
21 Task
3
Tilpasse standard sider, så body passer i nyt tema
Sprint 5
Tabel 35 - Sprint 5 planning
Retrospektive
Burndown
Burndown Sprint 5
30,0
25,0
20,0
15,0
10,0
5,0
0,0
27-05 Start
27-05 Slut
28-05 Start
Dag 1
28-05 Slut
29-05 Start
Dag 2
Burndown Sprint 5 (26-05 <> 02-06)
29-05 Slut
Dag 3
Ideel
Tabel 36 - Sprint 5 Burndown
Sprintet forløb som planlagt.
Hvad gik godt?
Estimeringen af opgaverne passede godt i sprintet.
Udarbejdet af: Ulrik.
Side 41 af 53
5. Semester – Afsluttende projekt
Hvad kunne have været bedre?
Ikke noget at nævne.
Hvad overraskede?
Jeg har tidligere forsøgt at ændre produkt siderne, så der blev vist det korrekte antal billeder, men fandt ikke
en løsning. Denne gang var det meget nemt og overskueligt. Med brug af PHPStorm til at debugge, men
selvfølgeligt har jeg også lært mere om Magento siden jeg forsøgte sidst.
Sprint 6
Sprint planning
ID
Type
Værdi Title
Løst i
53 Task
8
Møde med Ipos angående skift til deres system
Sprint 6
54 Task
2
Forside styling(: Center) af nyhedsbrev
Sprint 6
Undersøg forskellige forside alternativer
Sprint 6
22 Spike 8
Tabel 37 - Sprint 6 planning
Review
Dag 2 undersøgte jeg hvad alternativer der var til den eksisterende forside. Problemet var at forsiden var for
svær at vedligeholde for butikkens ansatte. Løsningen blev et responsivt net, hvor de kunne skifte tekst og
billeder via Magentos interface. Løsningen blev implementeret i butikken med det samme.
Udarbejdet af: Ulrik.
Side 42 af 53
5. Semester – Afsluttende projekt
Retrospektive
Burndown
Burndown Sprint 6
20,0
18,0
16,0
14,0
12,0
10,0
8,0
6,0
4,0
2,0
0,0
03-06 Start
03-06 Slut
04-06 Start
04-06 Slut
Dag 1
Dag 2
Burndown Sprint 6 (02-06 <> 09-06)
Ideel
Tabel 38 - Sprint 6 Burndown
Sprintet forløb som planlagt.
Hvad gik godt?
Estimeringen af opgaverne passede godt i sprintet.
Spike kunne bruges som den var, som butikkens nye forside.
Hvad kunne have været bedre?
Ikke noget at nævne.
Hvad overraskede?
Ikke noget at nævne.
Udarbejdet af: Ulrik.
Side 43 af 53
5. Semester – Afsluttende projekt
Samlet risici vurdering
En samlet liste af fundne risici er vist i Tabel 39.
ID
Beskrivelse af risiko
Sprint
Sandsynlighed Tabs størrelse
Opdaget
1
MySQL - Datatab ved opdatering af
(i dage)
Afsluttet
0
Eksponering
20%
1,0 dage
0,20
50%
2,0 dage
1,00
25%
0,5 dage
0,13
40%
1,0 dage
0,40
20%
1,0 dage
0,20
data via phpMyAdmin
2
Manglende Test - Ingen test ved
0
3
ændring af kode
3
Fejl i forbindelse med opdatering
1
4
FTP - Fejlagtig ændring af filers
1
2
tilladelse
5
Skift af IDE har nedskrevet
3
sandsynligheden for forekomst af
Risiko 3
Tabel 39 - Risici diagram
Ud fra Tabel 40 kan man se udviklingen af risici i projekt perioden. Målet med Risici registrering er tidligt at
finde og fjerne risici, før de bliver til store problemer. I projektet startede jeg med at finde nogle risici og
efterfølgende fjernede eller nedsatte deres eksponering.
Risici Burndow
2
1,8
1,6
1,4
1,2
1
0,8
0,6
0,4
0,2
0
0
1
2
3
4
5
6
Risici
Tabel 40 - Risici Burndown
Udarbejdet af: Ulrik.
Side 44 af 53
5. Semester – Afsluttende projekt
Samlet perspektivering
I dette afsnit har jeg udført en samlet perspektivering af projekt forløbet.
Magento
Da jeg startede på projektet, var Magento en ny teknologi for mig. I forhold til at få og kunne navigere i
Magento, har det hjulpet rigtig meget at kigge på de bagvedliggende mekanismer så som PHP og strukturen af
Magento. Herudfra har jeg fået et godt overblik over, hvad der sker hvor og hvornår. Efter projektet føler jeg
mig rustet til at kunne udvikle og modifere Magento.
Scrum
Brugen af Scrum i projektet har fungeret rigtigt godt. Det har givet projektarbejdet en god struktur.
Estimering af arbejdsopgavernes omfang og værdi er i løbet af projektet blevet bedre og bedre.
Roller
Det har fungeret overraskende godt med en rigtig kunde tilknyttet projektet til at spare med. Specielt da
kundens behov ændrede sig i løbet af projekt perioden. Det har ikke været noget problem både at
repræsentere Scrum Master og Team, med adskillelsen af Product Owner ser jeg som essentiel.
Ceremonier
Sprint Review med kunden har givet meget mere konstruktive feedback, end jeg havde forventet.
Noterne jeg lavede til Sprint Retrospekt var utroligt givende. Jeg brugte dem som en dagsorden for Retrospekt.
Ved Retrospekt har jeg manglet nogen at spare med i forhold til projektet, det har til tider været svært at se
tingene fra mere end én side.
Artefakter
Under projektet var Sprint Board eller Burndown ikke synligt i lokalet, det var ikke nødvendigt, da jeg arbejdede
alene og altid følte, jeg havde overblikket. Men hvis der havde været bare 1 mere i projektet ville det være
nødvendigt at have dem synligt i lokalet.
XP Praktikker
Implementeringen af XP Praktikker har fungeret rigtigt godt som suppleret til Scrum. I det følgende beskrives
hvordan
Udarbejdet af: Ulrik.
Side 45 af 53
5. Semester – Afsluttende projekt
Løbende integration
Jeg har løbende opdateret test serveren og herefter live serveren med testet kode. Når der har været tale om
design ændringer, har jeg skubbet ændringen ud hurtigt, da der ikke har været behov for så meget test.
Refaktorering
Det har været rigtigt godt at lave en markering, hvis den skrevne kode kunne gøres smartere med et TODO tag,
for så at kunne finde tilbage til koden og optimere den.
Kodestandard
Det har ikke været muligt at finde en kodestandard for Magento, men jeg brugt meget tid på at finde
eksempler i Magentos filer, når jeg skulle ændre i koden. Det var let at finde lignende scenarier og eksempler at
reproducere. Det har fungeret godt, og jeg synes selv, at den kode jeg har formået at lave, går godt i med den
eksisterende kode fra Magento.
Test først udvikling
Det har ikke været muligt at lave test først udvikling endnu, men det er på min TODO liste over fremtiden af
projektet, da behovet for test bliver større og større i takt med opgavernes stigende kompleksitet.
Udarbejdet af: Ulrik.
Side 46 af 53
5. Semester – Afsluttende projekt
Videre udvikling
Efter projektets afslutning er der stadig mange opgaver tilbage i Product Backlog, og stadig flere der ikke er
kommet i Product Backlog. Erfaringerne med brug af Scrum og det tætte forhold til kunden har inspireret mig
til at starte egen virksomhed. Min plan er at fortsætte samarbejdet med kunden hen over sommerferien, men
som selvstændig konsulent.
Et af mine mål for arbejdet med Magento er at lave egne moduler i første omgang specifikt til butikken, men på
sigt via Magento Connect hvor andre kan få glæde af dem.
De er ved at udvikle Magento 2 som næste skridt for Magento. Den er fortsat under udvikling og er i øjeblikket
tilgængelig på GitHub til udviklere, men forventes frigivet sidst på året til forretnings brug.
Magento 2
Magento 2 indeholder rigtigt mange ændringer i forhold til Magento 1.x, hvoraf nogle af de vigtigste er:







Fleksibel arkitektur, endnu mere fleksibel modul struktur.
100% Test venlig, med indbygget test miljø. Her er mulighed for Unit test og mange andre.
Ændret folder struktur, så strukturen bliver mere simpel og overskuelig.
Lettere at installere.
Optimeret skalerbarhed, blandt andet ved fuldsides cache.
Mere information til udviklerne.
Forbedret sikkerhed.
Magento 2 virker rigtigt interessant som udvikler, da der nu er fokus på dokumentation, simplificering og ikke
mindst test.
Udarbejdet af: Ulrik.
Side 47 af 53
5. Semester – Afsluttende projekt
Konklusion
Da jeg startede på projektet, var Magento en ny teknologi for mig. Jeg har formået at lære at arbejde med
Magento ved at sætte mig ind i de bagvedliggende mekanismer så som PHP og selve folder strukturen. Dette
har givet mig grundlæggende viden og kompetencer i forhold til at arbejde med Magento, og hvordan Magento
er opbygget.
I løbet af projektet har jeg løbende ændret Magentos design og layout efter kundens behov. Desuden har jeg
tilføjet en ny funktionalitet til Magento ved at tilpasse filtrering efter kundens behov, hvorved jeg har opfyldt
mine mål om at være i stand til at tilpasse Magento design og layout samt udbygge Magento med ny
funktionalitet.
Processen med at arbejde alene og bruge Scrum og XP praktikker har fungeret rigtigt godt og effektivt. Det har
særligt været godt med en virkelig kunde at stå til regnskab for, og som stiller nye krav til produktet. Der hvor
forløbet med Scrum i et solo-projekt ikke har fungeret optimalt har været i forhold til refleksioner. I den
forbindelse har det hjulpet mig meget, at jeg har skrevet emner ned til Retrospektive, for i den proces at
behandle emnerne en ekstra gang og herefter tage dem op til Retrospektive. Dog har det været svært at
anskue tingene på mere end én måde, efter at have arbejdet med dem som både Scrum master og team.
Måske Product Owner kunne deltage ved Retrospektive, det kunne give nuancerede refleksioner. Ved XP
praktikkerne har det ikke været muligt at lave test først i projektet. Ved udarbejdelsen af filtrering manglede
jeg tests for at kunne sikre kodens kvalitet i form af et bedre design og udrydde fejl, mens det var på test
serveren.
Som helhed vurdere jeg, at Scrum og XP praktikker har hjulpet mig med at kunne levere et produkt af god
kvalitet til Product Owner. Det har været utroligt motiverende og givende at have en rigtig kunde i den anden
ende med sine krav og ønsker. Efter projektet er afsluttet vil jeg fortsætte samarbejdet med Kalejdoskop for
fortsat at optimere deres webshop.
Det har været en spændende udfordring at arbejde med en ny teknologi som Magento. Efter projektarbejdet
føler jeg mig rustet til også at lave egne moduler til Magento.
Udarbejdet af: Ulrik.
Side 48 af 53
5. Semester – Afsluttende projekt
Referencer
[1] »Usage Statistics and Market Share of Apache for Websites, June 2015,« 1 juni 2015. [Online]. Available:
http://w3techs.com/technologies/details/ws-apache/all/all.
[2] »Magento Design guide,« 1 juni 2015. [Online]. Available:
http://info.magento.com/rs/magentocommerce/images/MagentoDesignGuide.pdf.
[3] »Atom.io,« 1 juni 2015. [Online]. Available: https://atom.io.
[4] »Visual Studio,« 1 juni 2015. [Online]. Available: https://www.visualstudio.com.
[5] »PHPStorm,« 1 juni 2015. [Online]. Available: https://www.jetbrains.com/phpstorm.
[6] sad111713581, »Agile Methods Of Software Development,« ETERNAL SUNSHINE OF THE IS MIND, 3
febuar 2013. [Online]. Available:
https://eternalsunshineoftheismind.files.wordpress.com/2013/02/scrum_process_big.jpg. [Senest hentet
eller vist den 17 juni 2015].
[7] P. Bell, »Solo-Scrums,« 1 juni 2015. [Online]. Available:
http://www.pbell.com/index.cfm/2007/6/17/Solo-Scrums.
[8] »Extreme Programming For One,« 1 juni 2015. [Online]. Available:
http://c2.com/xp/ExtremeProgrammingForOne.html. [Senest hentet eller vist den 1 juni 2015].
[9] »Efficient Magento code – database (Flat vs EAV). Part 1.,« 1 juni 2015. [Online]. Available:
http://divante.co/blog/efficient-magento-code-database-flat-eav-part-1.
[10] »About JavaScript - JavaScript | MDN,« 1 juni 2015. [Online]. Available: https://developer.mozilla.org/enUS/docs/Web/JavaScript/About_JavaScript.
[11] »About the Apache HTTP Server Project,« 1 juni 2015. [Online]. Available:
http://httpd.apache.org/ABOUT_APACHE.html.
Udarbejdet af: Ulrik.
Side 49 af 53
5. Semester – Afsluttende projekt
[12] »Community & Enterprise eCommerce Solutions,« 1 Juni 2015. [Online]. Available:
http://magento.com/products/overview#community.
[13] »eCommerce Technology & Technical Resources,« 1 juni 2015. [Online]. Available:
http://magento.com/resources/technical.
[14] »File: SASS_REFERENCE — Sass Documentation,« 1 juni 2015. [Online]. Available: http://sasslang.com/documentation/file.SASS_REFERENCE.html.
[15] »HTML & CSS - W3C,« 1 juni 2015. [Online]. Available:
http://www.w3.org/standards/webdesign/htmlcss#whatcss.
[16] »Introduction to Object Oriented Programming Concepts (OOP) and More:,« 1 juni 2015. [Online].
Available: http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-ProgrammingConcep#OOP.
[17] »jQuery,« 1 juni 2015. [Online]. Available: https://jquery.com.
[18] A. MacGregor, »Magento Fundamentals for Developers | PACKT Books:,« 1 juni 2015. [Online]. Available:
https://www.packtpub.com/books/content/magento-fundamentals-developers.
[19] R. Bhatia, »Magento MVC Architecture: Rajesh's Tech Blog,« 1 juni 2015. [Online]. Available:
http://www.php24.in/2010/11/magento-mvc-architecture.html.
[20] »Magentohotel tech review (magentohotel.dk),« 1 juni 2015. [Online]. Available:
http://tech.wpgpl.com/magentohotel/magentohotel.dk.
[21] »MySQL 5.6 Reference Manual :: A.1 MySQL 5.6 FAQ: General,« 1 juni 2015. [Online]. Available:
https://dev.mysql.com/doc/refman/5.6/en/faqs-general.html.
[22] »Patterns in Practice: Cohesion And Coupling,« 1 juni 2015. [Online]. Available:
https://msdn.microsoft.com/en-us/magazine/cc947917.aspx.
[23] »PHP: Apache 2.x on Microsoft Windows – Manual,« 1 juni 2015. [Online]. Available:
http://php.net/manual/en/install.windows.apache2.php.
Udarbejdet af: Ulrik.
Side 50 af 53
5. Semester – Afsluttende projekt
[24] »PHP: What is PHP? – Manual,« 1 juni 2015. [Online]. Available: http://php.net/manual/en/introwhatis.php.
[25] »phpMyAdmin,« 1 juni 2015. [Online]. Available: http://www.phpmyadmin.net/home_page/index.php.
[26] »Prototype Overview,« 1 juni 2015. [Online]. Available:
http://www.tutorialspoint.com/prototype/prototype_overview.htm.
[27] »Understanding Drupal,« 1 juni 2015. [Online]. Available:
https://www.drupal.org/documentation/understand.
[28] »W3C Document Object Model,« 1 juni 2015. [Online]. Available: http://www.w3.org/DOM.
[29] »What is LAMP (Linux, Apache, MySQL, PHP)? - Definition from WhatIs.com,« 1 juni 2015. [Online].
Available: http://searchenterpriselinux.techtarget.com/definition/LAMP.
[30] »What is Magento?,« 1 juni 2015. [Online]. Available:
http://devdocs.magento.com/guides/v1.0/architecture/arch_whatis.html.
[31] »What is phtml File Extension in Eicra Script,« 1 juni 2015. [Online]. Available:
http://www.httpsdoc.com/What-is-phtml-File-Extension-_34.html.
[32] »Xdebug: Documentation,« 1 juni 2015. [Online]. Available: http://xdebug.org/docs/remote.
[33] »Zend Framework & MVC Introduction - Zend Framework Quick Start,« 1 juni 2015. [Online]. Available:
http://framework.zend.com/manual/1.12/en/learning.quickstart.intro.html.
[34] S. T. Veethil, »Risk Management in Agile,« 1 juni 2015. [Online]. Available:
https://www.scrumalliance.org/community/articles/2013/2013-may/risk-management-in-agile.
[35] D. Wax, »Scrum for one,« 1 juni 2015. [Online]. Available:
http://www.lifehack.org/articles/productivity/scrum-for-one.html.
[36] »Magento 2.0 Update Released: 8 Key Features will Attract You,« 1 juni 2015. [Online]. Available:
http://blog.prabhasolutions.in/amazing-exciting-features-magento-2-0-key-updates/.
Udarbejdet af: Ulrik.
Side 51 af 53
5. Semester – Afsluttende projekt
[37] H. Kniberg, Scrum and XP from the Trenches, InfoQ, 2007.
[38] C. Larman, APPLYING UML AND PATTERNS, 3 red., Craig Larman: Prentice Hall, 3. udgave, marts 2012.
[39] I. Sommerville, Systemudviklingsmetode/System development, Software Engeneering, 9. edition,
Pearson, 2010.
[40] M. Cohn, User Stories Applied, For Agile Software Development, Addison-Wesley, 2004.
Udarbejdet af: Ulrik.
Side 52 af 53
5. Semester – Afsluttende projekt
Bilag
1. Vejledning til medfølgende kilde kode
Udarbejdet af: Ulrik.
Side 53 af 53
5. Semester – Afsluttende projekt
Bilag 1: Vejledning til medfølgende kilde kode
Medfølgende er filen ”bilag1-Kildekode.zip” med kildekode.
Medie mappen er undladt på grund af størrelsen.
(Opbygningen er som beskrevet i afsnittet ”Folder struktur” på side Fejl! Bogmærke er ikke defineret. i
rapporten.)
Tema mapperne:
Layout filerne er placeret i:
App/design/frontend/rwd/kalejdoskopRWD
Design filerne er placeret i:
Skin/frontend/rwd/kalejdoskopRWD
PHP filer:
Magento kerne bibliotek:
App/code/core
Ændrede Magento kerne biblioteks filer:
App/code/local
Udarbejdet af: Ulrik.