...
In het document zal er worden ingegaan op in ieder geval de volgende hoofdstukken. Allereerst de deelproducten. In het tussentijdse verslag zal er in worden gegaan op in ieder geval het Plan van Aanpak, het SRS en over in ieder geval één stuk code. In het hoofdstuk projectmethode wordt er ingegaan op de methode Scrum. Hierin zal ik aangeven wat goed en minder goed werkt. In het hoofdstuk rollen zal ik ingaan op welke rollen ik heb vervuld tijdens het project. In het hoofdstuk competenties ga ik tenminste in op 2 genomen beslissingen. Dit kan gaan over bijvoorbeeld een design decision of implementatie. In het hoofdstuk leerdoelen zal ik verder ingaan op mijn leerdoelen die hierboven kort benoemd zijn. In de conclusie zal ik reflecteren op alle hoofdstukken en het hele project. Dit gaat over het groepswerk maar ook over bijvoorbeeld mijn leerdoelen. Als laatst zal ik een factsheet toevoegen voor alle competenties. Per compententie competentie zal ik facts en toelichtingen toevoegen die deze competentie aantonen.
...
De code die voor mij een groot deel van de tijd in beslag heeft genomen en ook nog niet volledig af is is de login. Als we het hebben over de backend van deze code dan gaat het vooral over de code die Thomas geschreven heeft, en later aangepast is door Wijnand. Zelf heb ik hier niet aan gewerkt, maar wel gereviewd. Zelf ben ik bezig geweest met de front-end van de login, de koppeling van de front-end en backend en moet ik nog werken aan de foutafhandeling en het doorgeven van een token. De token is nodig om op elke pagina te kijken of de gebruiker hier mag zijn, en als dit het geval is, wat deze gebruiker mag en kan. Als ik kijk naar de backend is hier veel tijd aan besteed. Er zijn tijdens het maken van de login aanpassingen geweest, grotendeels door meerdere invalshoeken. Iedereen kijkt er toch net wat anders naar. De één vindt het beter om de gebruiker te laten weten of zijn wachtwoord of gebruikersnaam misschien niet klopt, terwijl de ander juist denkt dat er maar één bericht moet komen dat er iets fout is. Dit zijn constant kleine aanpassingen, maar kunnen later op andere stukken weer een grotere impact hebben. Ik durf niet met zekerheid te zeggen of het allemaal veel sneller had gekund omdat mijn focus niet lag op waar Thomas precies mee bezig was. Ik denk echter wel dat het sneller had gekund als we gelijk de uiteindelijke richting hadden gekozen zoals: het wachtwoord moet gehasht in de database staan en er komt 1 foutmelding.
De Backend van de login werkt nu en is klaar, de front-end heb ik met behulp van Angular ook snel in elkaar weten te zetten. Ook door het feit dat er veel over te vinden is het een redelijk snel en makkelijk proces. toch ben ik meerdere obstakels tegen gekomen. Allereerst wou ik een Toastr toevoegen voor foutmeldingen. Toastr's zijn gekleurde berichten die vaak rechts bovenin een scherm te zien zijn (bijvoorbeeld https://codepen.io/RaiseTheBahr/pen/JOybye). Dit leek ook in Angular makkelijk te kunnen al kreeg ik foutmeldingen waar ik geen raad mee wist en ook na veel onderzoek nog niet uit ben gekomen. Ik heb mij voor nu neergelegd bij het niet kunnen gebruiken van toastrs Toastr's en ben verder gegaan met de koppeling. De koppeling tussen de twee was er snel en werkte goed. Op het moment dat de login backend af was kon je ook gelijk met de front-end inloggen, al deed deze verder nog niks. De vervolgstap is het doorgeven van een token aan de user. Ook hier heeft al wat tijd ingezeten, al denk ik nu te weten hoe ik dit kan oplossen. Ik denk niet dat hier veel tijd bespaard had kunnen worden. Het gebruik van Toastr's heb ik misschien te graag gewild terwijl een rode tekst voor nu ook genoeg zou zijn geweest. Dit is ook de oplossing die we hier gaan gebruiken. De oplossing voor het meegeven van een token komt uiteindelijk af van Meron Brouwer. Als ik hier eerder de vraag aan had gesteld in plaats van het onderzoek zelf vanaf 0 te doen was misschien de hele login ook al klaar.
...
We zijn deze periode aan het werk gegaan met scrum. Scrum is een methode waar je een to-do lijst hebt. Iedereen weet wat er nog moet gebeuren. Als je een taak oppakt sleep je deze naar "in progress". Door dat te doen kan iedereen zien wie waar mee bezig is. Na het afronden kan de taak naar het vak "ready to review". Dit houdt in dat het maken van de taak klaar is, maar dat deze nog wel moet worden gereviewd. Hierna kan de taak terug naar "in progress" omdat er nog aanpassingen moeten worden gedaan, of naar done wat aangeeft dat de taak volledig goed is. Deze methode werkt goed. Op elk moment van de dag kan er gekeken worden wie waar mee bezig is, wat er nog gedaan moet worden en wat niet afkomt. Tijdens de Daily stand up bespreken we elke ochtend wie waar mee bezig was, of er problemen waren en wat ze die dag gaan doen. Naast dat we dit bespreken hebben we het ook over het aantal gereserveerde uren, en de gewerkte uren. Voor elke taak staat een aantal uren. Als je met een taak bezig bent geweest geef je het aantal uren op dat je er aan gewerkt hebt. Aan het eind kunnen we kijken of de schatting overeenkomt. Als je minder uren hebt gebruikt is er niks aan de hand. Echter, als er meer uren zijn gebruikt dan verwacht, dan is er dus een probleem ontstaan. We kunnen dan overleggen met hoe het zit en wat er anders moet. Kunnen we dit probleem nog eens tegenkomen, of was het een complexere, eenmalige uitdaging? Dit zorgt ervoor dat de hele groep op de hoogte is van de voorgang.
Rollen
In het Plan van Aanpak (PvA) Hebben we een aantal rollen beschreven. In ieder geval de rol scrummaster die iedereen zal krijgen tijdens het project. Deze rol krijg ik als derde van 30-11-22 tot 09-12-22. Iedereen heeft een aantal niet beschreven rollen zoals, onderzoeker, programmeur en reviewer. Dit zijn rollen die niet beschreven staan omdat ze een standaard zijn. Tijdens het gehele project wil ik ook een beetje proberen het voortouw te nemen op sommige punten. Ik heb met het zicht op de vorige projecten dit gedaan omdat ik merk dat er anders nog wel eens gaten ontstaan in de code of documenten. Ik wil tijdens dit project meer vragen en duidelijkheid creëren voor zowel mijzelf als anderen.
In de eerste sprint ben ik vooral bezig geweest met het onderzoek data transfer. Het is tijdens dit onderzoek duidelijk geworden hoe we de data van punt a naar punt b kunnen krijgen, en dit in realtime op de website weer kunnen geven. In dit onderzoek heb ik naderhand ook 2 stukken code geschreven om dingen uit te testen. Als eerste, wat als beste uit het onderzoek kwam, een web socket. Dit is een manier om in realtime data van a naar b te krijgen. Ik heb een kleine chatapplicatie gemaakt, vergelijkbaar met een chatroom of WhatsApp. Daarna heb ik een Broker opgezet. De broker is uiteindelijk wat we gaan gebruiken om de data te ontvangen. De Raspberry pi data wordt opgehaald door de broker en naar verschillende kanalen, waaronder de backend van de applicatie, verstuurd. Tijdens de eerste sprint heb ik ook werk van anderen gereviewd. Dit geeft als gevolg dat ik in de eerste periode grotendeels de rollen van onderzoeker en reviewer op me hebt genomen. Ook heb ik een stukje van de rol programmeur gehad, al was dit alleen voor het onderzoek van belang.
Tijdens de tweede sprint ben ik vooral bezig geweest met programmeren en reviewen. Ik heb ook deze sprint verder geen specifieke rol gehad. Ook heb ik natuurlijk geprobeerd hier meer het voortouw te nemen en meer vragen te stellen waarom iets op een manier gedaan is. Dit laatste werkt heel goed tijdens het reviewen van bijvoorbeeld de login aan de backend. Ik heb hier niet alleen gekeken naar of de code werkt en of deze netjes is tot op bepaalde hoogte, maar ook hoe deze werkt. Hierdoor zijn er een aantal punten naar boven gekomen die vervolgens weer leidde tot andere punten. Dingen zoals geen gehashte wachtwoorden. Dit heb ik bijvoorbeeld in de groep aangekaart met de vraag wat we hier alle van vonden. Zelf heb ik een enorme voorkeur (en het is eigenlijk ook wel een must) voor gehashte wachtwoorden. Dit is dan ook aangepast. Normaal had ik hier waarschijnlijk minder of niks van gezegd.
Competenties
Leerdoelen
Conclusie
...