Overall
Last updated
Was this helpful?
Last updated
Was this helpful?
Ik ben erg tevreden over het eindproduct. Van tevoren hebben wij aangegeven dat wij een prototype zouden opleveren en ik moet eerlijk bekennen dat wij iets meer dan dat opgeleverd hebben. Het is nog geen applicatie die klaar is. Dit heeft met name met veiligheid redenen te maken.
Wél laat de app goed ziet wat er allemaal mogelijk is met dit project.
Ook hebben wij het project goed afgerond. Alle issues die niet gedaan konden worden, hebben een out-of-scope label en daarnaast hebben wij in de Design Rationale ook documentatie geplaatst, zodat andere studenten/projecten het weer kunnen oppakken.
Tijdens elke meeting met de opdrachtgevers waren zij positief verrast. Iedere keer weer. Dit is een goed teken en een goede indicatie dat de opdrachtgever tevreden was/is.
Tijdens de oplevering (donderdag) waren zij ook erg tevreden.
Toevoegen donderdag
Ik vind dat wij als team goed hebben gefunctioneerd. Alle taken waren goed verdeeld en de manier van werken, was erg goed. Iedereen wist op ten duur hoe het in z'n werk ging en daar ben ik best blij mee. Het oplossen van merge conflicten en het aanmaken van issues was eerst nog een beetje rommelig, maar in de loop van het project is het steeds duidelijker geworden.
Iedere sprint hebben wij een combinatie van design en code opgeleverd. Het was nooit te veel van het een of het ander. Voorafgaand aan een sprint verdeelden wij de user stories en hier maakt een ieder weer taken van. Ik moet eerlijk bekennen dat het niet altijd gelukt is om deze taken tijdens de sprint af te ronden, maar overall hebben wij een goed eindproduct opgeleverd.
Zelf ben ik erg tevreden met dit project. Ik heb zelf al wel wat ervaring met het samenwerken in front-end projecten en daarom was het niet allemaal nieuw voor mij. Dit hielp mij in het begin erg met het opzetten van de repository. Door dit in de eerste week direct goed neer te zetten (Actions, Issues, Projects etc.), was het voor de rest direct duidelijk hoe het allemaal werkte en konden er weinig fouten gemaakt worden.
Ook heb ik mij op het gebied van design enorm ontwikkeld. Ik vind het heel leuk om te doen, maar heb/had er niet veel ervaring in. Het was ook wel iets wat ik vooraf graag wilde doen, omdat het project zich hier heel erg voor schikt. Ik vind het design echt mooi geworden en hier heb ik ook een rol in gespeeld.
Daarnaast was het wel even zoeken hoe ik precies wilde werken. Eigenlijk zaten wij iedere dag wel in Discord. Op ten duur merkte ik dat ik soms behoefte had om even voor mezelf iets te gaan doen. Ik was dan een stuk productiever. Dat heb ik aangegeven en de rest had dit eigenlijk ook. Hierdoor heb ik er voor gekozen om vanaf dat moment soms wel eens even niet op Discord te gaan. We begonnen wel iedere dag om 09:30 en sloten de dag aan het einde van de middag ook af. Daartussen deed je soms wat voor jezelf en soms zat je in het channel als je daar behoefte aan had. Dit werkte echt goed.
Ook heb ik bepaalde tools mijzelf eigen gemaakt, zoals Svelte(Kit) & Strapi. Hier had ik nooit mee gewerkt en het was leuk om met deze tools kennis te maken tijdens dit project.
In de inleiding heb ik ook een aantal persoonlijke leerdoelen gedefineerd.
Ik wil een goede Git omgeving op kunnen zetten.
Ik vind dat dit aardig goed gelukt is. De repository en de workflow heb ik samen met Thijs op ons genomen. In eerste instantie hebben wij een aantal Workflows aangemaakt. Een voor alle branches, een voor de development branch en een voor de main branch. Zodra er ook maar iets faalt, kan een PR niet gemerged worden.
Daarnaast hebben wij templates gemaakt voor issues en pull requests. Met een druk op de knop wordt er automatisch een template gebruikt bij de issues en de templates van de pull requests gaan vanzelf. Dit zorgde ervoor dat alles consistent bleef en alle benodigde onderdelen in de issues/PR zaten.
Omdat wij Netlify gebruikte, konden wij deploy previews inschakelen. Hierdoor kwam er bij ieder pull request automatisch een preview, zodat de reviewer direct kon zien wat er aangepast werd, zonder het lokaal te moeten hebben. Die scheelde heel veel tijd.
Tijdens het hele project hebben wij de Gitflow Workflow gebruikt. Dit werkte erg goed. Achteraf gezien had ik ook nog wel de branch naam in de commits willen hebben, want het is nu niet helemaal duidelijk welke commit bij welke branch hoort.
Ik wil een goede basis hebben van Svelte en/of SvelteKit.
Ik vind dat dit zeker gelukt is. Na een aantal weken ermee gewerkt te hebben, heb ik een aardig goed beeld van hoe Svelte(Kit) werkt.
Ik wil mezelf nog geen Svelte expert noemen, maar mijn leerdoel was een goede basis en ik ben ervan overtuigd dat ik dit nu heb.
Ook begrijp ik alles wat er in onze code staat en dat vind ik sowieso al fijn. Eerst was het hele endpoint verhaal nog een beetje vaag voor mij, maar uiteindelijk is het mij toch gelukt om het te begrijpen en daar ben ik blij mee.
Ik heb zelfs over het cachen in SvelteKit een artikel geschreven dat op het moment van schrijven (15 juni 2021) 350 weergaven heeft. Hier liepen wij best wel een tijdje tegenaan. Best leuk dat ik daar direct een artikel over kon schrijven.
Zelf ben ik er nog niet helemaal over uit waar mijn voorkeur ligt: bij Svelte of Vue. Ik vind ze erg op elkaar lijken. Ik heb iets meer ervaring met Vue, dus ik denk dat daar mijn voorkeur op dit moment nog ligt. Wel ga ik verder met het maken van projectjes in Svelte en dan acht ik de kans vrij groot dat Svelte mijn favoriet wordt.
Ik wil mij ontwikkelen op het gebied van design.
Ik vind ook dat ik dit leerdoel voor mijzelf gehaald heb. Zelf heb ik de eerste stappen gemaakt in het design en de keuze van de kleuren. Hier hebben wij de rest van de app mee kunnen maken.
Of het leerdoel nou echt gehaald is, weet ik niet. Ik heb wel veel kunnen designen, maar of ik mij echt ontwikkeld heb, dat is moeilijk te meten. Het zal ongetwijfeld wel het geval zijn, omdat ik best wel wat leuke ideeën had die ik niet eerst had (met bijv. de achtergrond). Daarnaast heb ik van Koop geleerd wat grouping is. Hier wist ik het bestaan niet van, dus dat zal ik in de toekomst zeker meenemen.
Wel zou ik nog wel wat meer moeten weten over UX. Ik ben zelf een developer met een interesse in design en dan ga je al vaak richting de UI design. Leuk dat design, maar het is ook wel goed om rekening te houden met de user experience. Dit is iets waar mijn teamgenoten (logischerwijs) meer vanaf wisten. Het motiveerde mij wel extra om hier in de toekomst meer in te verdiepen, want ik vind het eigenlijk ook wel leuk. Ik denk ook dat dit best wel een goede eigenschap is van een developer: ook kennis hebben van de UX.
Er is niet onwijs veel met CSS gedaan, maar de basis van dit vak heb ik mee kunnen nemen in dit project. Denk bijvoorbeeld aan het gebruik van enkel selectoren. Doordat de CSS in Svelte on default scoped is, is het eigenlijk bijna nooit nodig om classes te gebruiken in Svelte. Met behulp van selectoren kom je een heel eind. Dit heb ik wel gebruikt in dit project. Iets dat ik aan het begin van CSSttr nog niet wist.
Ik zie deze twee vakken al 1 eigenlijk. Doordat wij met SvelteKit werken, hebben wij het WAFS-gedeelte als het ware over geslagen. Wij hebben wij een Web App gemaakt, maar niet from scratch.
Wel hebben wij een Service Worker geïmplementeerd, zodat spellen offline bekeken konden worden. Dit was nogal een ding met SvelteKit. Het is nodig om zowel het component, als het endpoint (met dus de data) te cachen. Doe je een van de twee niet, dan is het niet mogelijk om het offline te bekijken.
Hier zijn wij wel even zoet mee geweest, maar uiteindelijk is het gelukt. Er is nu zelfs een download knop waarmee je een spel offline kunt opslaan.
Ik heb best wel vaak rekening gehouden met progressive enhancement. Op het moment dat iets gedaan wordt met JavaScript, dan zet ik er een {#if} op, zodat het alleen getoond wordt als iemand JavaScript heeft aan staan.
Hetzelfde geldt met offline. Op het moment dat iemand offline is, wil je niet alles tonen, omdat niet alles kan (bijv. een form submit).
Onze doelgroep (de gebruikers) maken veelal gebruik van oudere Android telefoons en daarom is progressive enhancement heel belangrijk.
We hadden nog meer kunnen doen, zoals bijvoorbeeld het opslaan van de spellen in de store. Hierdoor hoeft het niet continu gefetcht te worden en dit scheelt heel veel tijd. Met name met slecht internet. Om wille van de tijd is dit niet meer gelukt.
Doordat onze doelgroep (de docenten) zich in Suriname bevinden, was het niet mogelijk om te testen. We konden ook niet echt iets maken samen met de gebruikers. Wel hebben wij wekelijks een meeting gehouden en de app getoond aan onze opdrachtgevers. Ook zij hebben regelmatig wat getest, maar dit zijn niet de eindgebruikers.
Er zit geen real-time aspect in de app. Het enige dat er gebeurd, is dat als er een spel gedownload is, komt er een snackbar in beeld die zegt dat het spel gedownload is.
Het enige (enigszins) real-time onderdeel is het builden. Op het moment dat er iets aangepast wordt in Strapi, wordt er middels een Webhook een bericht naar Netlify gestuurd. Deze build de app dan, waardoor de app statisch beschikbaar is.