användes vid utveckling. Parprogrammering var tänkt att motverka detta, vilket det kanske gjorde, men inte i tillräckligt stor utsträckning. Parprogrammering utfördes inte hela tiden på grund av att det var praktiskt svårt tidsmässigt. Om gruppen hade varit mer flitig med par- programmering kunde båda de två problemen ha motverkats. Med mer parprogrammering hade det blivit mindre tidsskillnad mellan gruppmedlemmarna samt att den genomsnittliga kunskapsnivå antagligen hade ökat.
Det fanns ingen underliggande tanke med att vissa arbetade mer tidigare i projektet än vad andra i gruppen gjorde. Utan något som inträffade för att några av projektmedlemmarna ville sätta igång hårdare i början än vad andra ville göra.
6.5
Arbetet i ett vidare sammanhang
Då samhället utvecklas och miljömedvetenheten ökar måste även mjukvarubranschen anpas- sa sig till dessa nya spelregler.
6.5.1
Samhällsaspekter
Systemet som utvecklats är tänkt att användas som ett utbildningsverktyg, en plattform för de som vill bli bättre på att presentera och redovisa inför en publik. Förhoppningen är att färre ska tycka att prata inför en publik är en krävande situation. Om fler finner sig bekväma med att tala inför andra får fler möjligheten att påverka allt från miljö och politik till att sälja produkter till kunder.
Systemet i sig kräver dock en beräkningskraftig dator förutom VR-headsetet i sig, vilket både kostar mycket och kan leda till en överkonsumtion av varor som inte kommer använ- das länge. Att systemet kostar mycket påverkar vilka som kan få möjligheten att använda det. Detta faktum förbättras om man kan få skolor, företag och kommuner att köpa systemet och att de sedan anordnar stationer med systemet istället för att varje privat användare behöver skaffa sig all utrustning som krävs. Detta hoppas även förhindra överkonsumtionen av utrustning som inte kommer användas senare, givet att en köpare som en skola eller ett företag, nyttja produkten mer effektivt.
6.5.2
Hållbar utveckling
Eventuella för- och nackdelar med de saker som togs upp under rubriken Hållbar utveckling under resultat kommer här att diskuteras.
• Stänga av datorerna och släcka lamporna när ingen är i arbetsrummet
Genom att stänga av datorerna och släcka lamporna efter ett arbetspass minskas ener- gianvändningen under utvecklingen. Många andra datorer på universitet stängs inte av när de inte används. Om det inte sitter någon vid datorn finns det inte någon an- ledning att den är på. Däremot kontrolleras stora delar av lamporna på universitet av rörelsedetektorer och det samma gäller lamporna i arbetsrummet. Intressant nog ver- kar rörelsedetektorn inte sitta i arbetsrummet utan i korridoren utanför. Det medför att lamporna i arbetsrummet tänds när någon går i korridoren om den inte stängts av med lysknappen.
• Maximal tid för användning och varna användaren när användaren har suttit för länge.
Genom att varna användaren för att ha spelat under en längre tid så kommer använda- ren att ta fler pauser. Detta tros förbättra koncentrationsförmågan och leda till en bättre träningsmiljö för användaren. Vilket kommer se till att användaren förbättras och blir mer bekväm i en snabbare takt. [22]
6.5. Arbetet i ett vidare sammanhang
• Digitala istället för fysiska manualer vid stationen
Genom att erhålla digitala manualer eller ha manualer på en webbsida så kommer ut- skrifter inte behöva göras. På detta sätt undviks behovet av att byta ut manualer när de blir för slitna eller när de blir utdaterade. Dessutom så sliter fysiska manualer mer på miljön då de skrivs ut på papper. Den kostnaden försvinner då genom att ha digita- la manualer eftersom att det inte behöver produceras papper och därmed inte belasta miljön.
• Färre interaktioner mellan webbservern och Unity gör det mer energieffektivt Genom att ha färre interaktioner mellan webbservern och Unity så kommer projektet att förbruka mindre energi. Det kan ske genom att skapa större paket och skicka färre gånger istället för små paket och fler gånger. Under projektets gång används en server som var tillhandahållen av institutionen vilket då var en del av deras stor server. Det medför en energibesparing på cirka 10% när system konfigureras för att skicka mycket data vid få tillfällen. Trotts detta togs beslutet att skicka mycket data få gånger eftersom om system kommer i drift kan det ske på en extern server och då kan mer energi sparas. Eftersom när det inte kommer någon data kan serverns strömspararåtgärder användas. [23]
• Minska andelen människor som lider av social fobi
Ur ett social hållbart perspektiv har produkten som utvecklats en positiv effekt, fram- förallt under antagandet att produkten kommer i vida användning. Förhoppningsvis kommer användare av produkten att bli bättre och inte undvika att prata inför andra människor. Det innebär att fler kommer på ett bättre sätt att sprida kunskap i samhället och samhället blir mer upplyst. Produkten skulle kunna ha positiv effekt på kommuni- kation mellan enskilda människor också eftersom människor blir mer självsäkra.
Kapitel 7
Slutsatser
Produkten uppfyllde dess kravspecifikation och levererades till kunden efter några mindre justeringar. För att få systemet att hjälpa användaren med att bli bekvämare med att hålla presentationer utformades en publik som både känns levande med sina animationer och stel med sitt utseende, för att påminna användaren om att den är i en simulering. Användaren kan även välja storlek på publiken, hur mycket publiken interagerar med användaren och storleken på miljön för att ge användaren möjlighet att själv sätta svårighetsgraden på si- muleringen. Huruvida den färdiga produkten faktiskt gör skillnad för användare kan inte besvaras i denna rapport. För att kunna besvara denna fråga krävs en rapport som utvärderar användares presentationer före och efter de övat i simulatorn.
De viktigaste lärdomarna som gruppen tar med sig är:
• Tillgången till ett gemensamt arbetsrum och många gemensamma aktiviteter gör myc- ket för hur gruppen arbetar tillsammans.
• Om man har en straffavgift för att komma sent bör denna vara anpassad så att personer inte kommer sent, till exempel via högre avgift.
• Varierande kunskapsnivå i projektet kan jämnas ut genom att använda parprogramme- ring flitigt.
Systemanatomin har legat som grund för att formulera krav och aktiviteter och har använts som diskussionsmaterial när det gällde systemets design. Andra typer av dokument med liknande innehåll kan ha använts istället för en systemanatomi, som till exempel en system- beskrivning. Det viktiga med ett sådant dokument är att det finns och kan användas för att förmedla systemets design till alla i gruppen. Ett sådant dokument har för gruppen haft som inverkan att hela gruppen snabbt kunde förstå hur systemet skulle designas.
Sammanfattningsvis har en produkt utvecklats som förhoppningsvis kan hjälpa människor lindra sin fobi för presentationer. Projektet har medfört att medlemmarna i projektgruppen har införskaffat nya erfarenheter om områden mjukvaruutveckling i grupp, grafiska miljö- er för VR, utveckling av front-end och back-end samt utvecklingsmetodikerna Scrum och eXtreme programming.
Som avslut på denna rapport önskar författarna att väcka intresse för området VR och framtida forskningsprojekt inom branschen.
Del II
7.1. Översikt individuella bidrag
7.1
Översikt individuella bidrag
Detta avsnitt beskriver kort vad de individuella bidragen kommer att behandla. A Skillnader i utveckling av REST-API i Node.js och Python
När utvecklingen av en webbplats ska göras så finns det många olika sätt att göra detta på. Denna del behandlar utvecklingen av ett REST-API på back-end sidan av webbplatsen. Vilket programspråk lämpar sig bäst för detta och vilka större skillnader finns det mellan dessa programspråk.
B Versionshanteringssystem vid grupparbeten
Det finns två stycken versionshanteringssystem, centraliserade och distribuerade, men vilket gynnar större grupparbeten? Detta individuella bidrag kommer att ge en överblick på dessa två system och sammanställa skillnaderna.
C En grupps utveckling under ett projekt
En projektgrupp är näst intill aldrig perfekt från början, utan den utvecklas under tiden grup- pens medlemmar arbetar tillsammans. Vissa grupper blir inte heller okej under ett helt pro- jekt. I detta bidrag gås det igenom hur just vår grupp utvecklas, från början till slut, i ett Scrum-liknande projekt.
D Jämförelse mellan komponenter och arv inom spelutveckling
För att kunna utveckla ett system som använder sig av Unity är det klokt att betänka designen av objekten som kommer att användas i simuleringen. Unity använder sig av en entitets- komponent-design istället för en traditionell arvsbaserad design. Alla i gruppen hade inte koll på vad detta innebar. Därför valdes det att skrivas om vad de är och vad de medför för arkitekturen och kodbasen samt hur de skiljer sig åt.
E Teamledarens roll i agil mjukvaruutveckling
I det här bidraget kommer teamledarens roll att diskuteras och analyseras genom projekts tre olika faserna; före, under, efter. Ett extra fokus på projektstyrningsteknikerna Scrum och eXtreme programming kommer även att inkluderas.
F Virtual Reality - Vad är verkligt
När man pratar om Virtual Reality, VR, så pratar man om virtuell verklighet. Det vill säga en virtuellt skapad värld som efterliknar den verkliga världen, men inte med samma konse- kvenser för hälsan som den verkliga världen kan ha. Men vad är det egentligen människor upplever som verkligt och hur lätt är det att lura hjärnan?
G Testning vid spelutveckling i Unity
Testning av mjukvara kan ske på många olika sätt. Unity har flera inbyggda verktyg som ska underlätta. Dessa verktyg beskrivs tillsammans med andra metoder som kan vara an- vändbara vid utveckling av grafiskt komplex mjukvara. Förslag hur testning utföra på när utveckling sker med grafikmotor Unity nämns.
7.1. Översikt individuella bidrag
H Påverkan av att skriva lokalt eller över cloud
På grund av att det ligger en sådan vikt i hur väl utförd projektets dokumentation är, är det viktigt att inte låta faktumet att hela gruppen deltar i skrivandet påverka kvaliteten på doku- mentet. Att se till att dokumenten upplevs som skrivet av en författare, även om det är flera individers bidrag. Enigheten i dokumenten är viktig för att läsaren inte skall behöva anpassa sig utefter skrivstilen som då kan skifta från stycke till stycke. Hur går man då tillväga för att enkelt skriva, korrekturläsa, och versionshantera dokument i grupper?
Bilaga A
Skillnader i utveckling av REST-API i
Node.js och Python
Författare: Anton Dalgren
A.1
Inledning
När en webbtjänst ska utvecklas kan det finnas många olika sätt att göra det på. Det vanli- gaste idag är ett system där tjänsten är uppdelad i två olika delar; front-end samt back-end. I det här kapitlet kommer skillnaderna mellan att utveckla ett REST-API i programspråken JavaScript samt Python för back-end delen att utredas.
A.1.1
Syfte
Syftet med denna rapport är att utveckla och visa på eventuella skillnader mellan de olika programspråken och ramverken som används för att utveckla ett REST-API, samt att reda ut vilket ramverk som passar bäst.
A.1.2
Frågeställning
1. Vilka större skillnader finns det mellan de olika programspråken? 2. Vilket programspråk lämpar sig bäst för utveckling av ett REST-API?
A.2
Bakgrund
Det finns idag många olika sätt att bygga ett REST-API på med många olika ramverk i väldigt många olika språk. Hur ska man gå tillväga för att välja ett ramverk som passar just det specifika projektet? Denna rapport kommer att behandla två olika sätt att göra detta på.
A.3
Teori
JavaScript är ett dynamiskt och svagt typat skriptspråk som körs i webbläsaren för att modi- fiera HTML-element vid anrop [25]. Node.js är baserat på JavaScript men har skrivits om till att kunna exekveras på en server istället för enbart i webbläsaren. Detta bidrar till att utveck- laren bara behöver kunna ett programspråk för att kunna arbeta hela vägen från back-end till front-end [11]. Likt JavaScript är Python också ett dynamiskt svagt typat skriptspråk som är skapat för ett användande inom generell programmering [26].
A.4. Metod
Begreppet RESTful Web Services används ofta inom webbutvecklingen. REST står för Re- presentational State Transfer, vilket är en IT-arkitektur för att beskriva maskin-till-maskin kommunikation. Inom en webbtjänst används ofta en back-end som är representerad i form av ett REST-API. Front-end sidan gör ett HTTP-anrop till back-end och får ett svar som oftast är av den struktur som ett JavaScript-objekt har, kallat JSON.
Tabell A.1: Exempel på HTTP anrop till ett REST-API innehållande studenter
Adress Metod Operation
/Student GET Hämtar alla studenter
/Student POST Skapar en ny student
/Student/<StudentID> GET Hämtar en specifik student /Student/<StudentID> PUT Uppdaterar en specifik student /Student/<StudentID> DELETE Tar bort en specifik student
I ett HTTP-anrop till ett REST-API används oftast de vanliga metoderna GET, POST, PUT och DELETE. Dessa metoder berättar för ett REST-API vad den ska utföra för operation på den inkommande adressen. I tabell A.1 finns ett exempel listat på vad ett REST-API gör vid de olika HTTP-metoderna till en specifik adress [27].
A.4
Metod
Denna rapport kommer att beskrivas mestadels med information från artiklar samt doku- mentation som beskriver hur de olika programspråken fungerar. Dokumentation kring de olika ramverken kommer att stå till grund för resultatet. Det kommer även att förekomma reflektioner kring vissa delar i de olika programspråken och ramverken som kommer att tas upp.
A.5
Resultat
Här kommer information om och skillnader mellan de två olika programspråken Node och Python, samt ramverken Express och Flask att presenteras.
A.5.1
Node.js
Node är baserat på Googles V8-motor som till största del är skrivet i C och C++ där fokus ligger på att hålla hög prestanda med låg minnesförbrukning. V8-motorn är tänkt att använ- das till att köra JavaScript i Google Chrome medans Node är tänkt att användas för att hålla igång serverprocesser.
För att köra parallella processer i Node används inte multitrådning som i många andra språk, utan det är ett eventbaserat språk som använder sig av asynkron I/O. Till skillnad mot andra programspråk när den eventbaserade modellen vill användas, så krävs bibliotek för detta, men i Node är det implementerat redan på språknivå [11]. Det gör att JavaScript passar perfekt till detta då det stödjer så kallade callbacks. Det är en funktion som är parameter till en funktion och körs när den funktionen är klar. Till exempel när en fil har lästs in från disk så körs funktionen som har blivit inskickad som en callback.
A.5. Resultat
kompilerat programspråk, till exempel Java. Sådana fel kan vara att försöka sätta en variabel som innehåller en sträng till en siffra eller att glömma returnera ett värde i slutet av en funktion.
Parallella processer i Python kräver till skillnad från Node multitrådning. Detta kan gö- ras med hjälp av funktionerna i det inbyggda biblioteket threading. Biblioteket är skapat för just trådbaserad parallellism [28].
A.5.3
Express
Express är ett ramverk för att bygga REST-API i Node. Det vanligaste sättet att använda sig av Express är genom att installera det genom Nodes egna bibliotekshanterare NPM. För att installera ett bibliotek som skapar ett fungerande Express-projekt se Kodexempel A.1
1
2 $ npm i n s t a l l express´g e n e r a t o r ´g
3
Kodexempel A.1: Kommando för installation av bibliotek för att skapa ett fungerande Express-projekt.
Figur A.1: Filstrukturen över det färdiga Express-projektet.
När detta bibliotek sedan exekveras från terminalen skapas det ett projekt med en filstruktur enligt Figur A.1 som är fungerande och detta är vad denna rapport har utgått ifrån.
REST-API strukturen
För att kunna bygga ett grundläggande REST-API i Express krävs det inte särskilt mycket kod. I Kodexempel A.2 finns ett kodexempel för hur HTTP-anropet POST kan gå till.
I samma listing har vi ett tydligare exempel på hur callbacks i JavaScript ser ut. Den andra parametern till funktionen router.post() är ett exempel på just en callback-funktion. Det är den funktionen som kommer att köras när eventet POST-anrop till adressen “/sign_in“ avfyras.
1
2 r o u t e r . p o s t ("/sign_in", f u n c t i o n ( req , r e s , ne xt ) {
3 var username = req . body . username ;
4 var password = req . body . password ;
5 password = sha256 ( password ) ;
6 r e s . send ( { s u c c e s s :true, message :"Success signing in"} ) ;
7 }
8
A.6. Diskussion
A.5.4
Flask
Flask är det ramverk som valts att använda i detta projekt för att skapa ett REST-API i pro- gramspråket Python. Det är ett mikroramverk som är baserat på Werkzeug [14]. Även detta ramverk är smidigt att installera. På samma sätt som Node har sin bibliotekshanterare har även Python sin egen, PIP. För att installera Flask gör enligt Kodexempel A.3.
1
2 $ pip i n s t a l l F l a s k
3
Kodexempel A.3: Kommando för installation av biblioteket Flask
REST-API strukturen
Strukturen för att bygga ett grundläggande REST-API i Flask är väldigt likt den för Express. Koden beskriver för interpretatorn vilken funktion som skall exekveras för en specifik adress vilket beskrivs enligt Kodexempel A.4.
1
2 @app . r o u t e (" / s i g n _ i n ", methods =["POST"] ) 3 def s i g n _ i n ( ) :
4 username = r e q u e s t . form [" username "]
5 password = r e q u e s t . form [" password "]
6 r e t u r n j s o n . dumps ( {’ s u c c e s s ’: True , ’ message ’: ’ S u c c e s s s i g n i n g i n ’} )
7
Kodexempel A.4: Kodexempel för att göra en inloggning med HTTP-anropet POST i Flask. Till skillnad från Node och JavaScript använder sig inte Flask utav callback-funktioner utan här används en dekoratör. Dekoratörer är till för att ha möjlighet att utöka funktionaliteten hos en funktion. Route-dekoratören används för att hantera de HTTP-anrop som inkommer till en viss adress.
A.6
Diskussion
Funktionaliteten i ramverken är väldigt liknande varandra men sättet koden för ramverken är skriva är väldigt olika. Detta har att göra med att de är skrivna för just det språket de är tänkta för. Det gör att strukturen för att skriva kod i det ramverket är bundet till den kodstandard som finns i språket. Det blir på så sätt lättare att utveckla ett system i ett ramverk för ett programspråk som man känner sig bekväm med.
A.6. Diskussion
Figur A.2: Exempel på callback-hell där callback-funktioner är rödmarkerade.
Inom JavaScript är det vanligt att alla funktioner som sköter någon typ I/O har en callback som sista parameter. När detta har gjorts i detta projektet har det varit i form av kommunika- tion med en databas. Här är det vanligt att det kan bli en lång kedja av anrop till databasen. Det gör koden mer komplex och svårare att förstå. Inom JavaScript världen går detta under benämningen “callback-hell“, vilket exemplet i Figur A.2 illustrerar.
A.6. Diskussion
Figur A.3: Kodexempel där Promises används.
För att förhindra detta har Promises tagits fram i JavaScript. Det skulle kunna förklaras som en variabel som får ett värde i framtiden. Denna variabel tilldelas ett värde om anropet lyckas och tilldelas ett fel om anropet misslyckas av någon anledning [29]. I detta projekt har Promi- ses använts för att få koden att vara snyggare och mer lättläst men med samma funktionalitet som i callback-hell exemplet, se Figur A.3. Detta får koden att ge skenet av att vara synkron trots att den egentligen är asynkron då den kommunicerar med en databas. Projektgruppen har valt att benämna detta med “Gods-Promise“.
A.7. Slutsatser
Eftersom att Python är ett sekventiellt programspråk och hanterar all sin I/O synkront så finns det bara ett sätt att skriva den här funktionaliteten på. Vilket enligt Figur A.4 kan se väldigt enkelt och smidigt ut.
A.7
Slutsatser
De skillnaderna som finns mellan ramverken är så små att det inte spelar någon större roll vilket som används. Den största skillnaden mellan ramverken är det språk de är baserade på. Då JavaScript sköter sin I/O asynkront blir det till stor del asynkron programmering när Express används, medan i Python och Flask är det synkron programmering. Vilket gör att det snarare är en preferens mellan programspråk än vilket ramverk som lämpar sig bäst. För en utvecklare som kommer i från front-end världen är det troligen mer naturligt att arbeta med Node och Express då det bara krävs ett programspråk för att kunna skriva hela applikationen från front-end till back-end. Medan en utvecklare som inte arbetat med webben passar bättre med den traditionella synkrona programmeringen i Python och Flask.
Bilaga B
Versionshanteringssystem vid
grupparbeten
Författare: Cian Hjort
B.1
Inledning
Versionshantering används vid projekt för att hantera arbetet genom att behålla en viss struk- tur och kvalitet bland filer. Det finns två olika typer av versionshanteringssystem; distribuera-