Week 2

I looked at our project and reviewed multiple elements:

• We implemented breakdown elements in our project in GitHub. We did this in our issues. We added labels to differ the tasks.
• We implemented the MOSCOW to our project with must have, should have, could have and won't have.
• There still needs to come a code guide. This way we have agreements on how we write our code. This way it will be consistent.

Week 3

This week I had a code review with Robert. I had a question about three.js. My concern was how long it loads, which isn't optimal. He said that I should just use lazy loading in the background. But I'm not a big fan of this solution. People in Nigeria use a lot of old phones, which even makes loading a 3D model load in the background heavy. I only want the user to load the model knowing that they know the consequences of how heavy it can be. The other concern was related with browser technologies. He gave me an advice to make everything run on html only as much as possible. Have a nice zero state without js and css where people can rely on. With the paralex scrolling, I needed to check if it was possible for the user, if not, just show the pure html.

Week 4

For this week I also had a code review with Robert. For our project it went swiftly, so I didn't had any specific questions or issues with my coding. But he did give me some pointers. One was that we should review our code, see if we can refactor some bits to make it run even better. For the caching that we want to implement later, we could do server caching. We can use cloudlfare for this, but this was also more of a tip for the client and the programmers later on (time is too limited for this). Plus for our fallbacks we can use feature detection to see if we should use our fallback or not.