Missing knowledge and Independent Learning

Most of the team had never implemented a simulation. As a result, this project required a considerable amount of independent learning to resolve the missing knowledge the team had. The team completed rigorous researching of different tech stacks and examples of simple implementations to learn different methods and decide on the best options. The final decisions are documented in the Infrastructure and Tools Wiki page. Here follows a list of missing knowledge the team had to independently learn for this project:

• How to run a simulation: Research of various technologies and solutions was conducted. After analyzing a few examples, a test repository was created to experiment with a simple simulation. Once a good result was implemented, it was presented to the rest of the team to ensure everyone had a good understanding on how it works.

• SimPy discrete-event simulation framework: None of the members of the simulation team had prior experience with SimPy. A lot of research was conducted before starting any simulation work, especially to understand SimPy's process-based approach and core concepts such as its environment-based time progression through reading documentation and experimenting.

• OSM data usage and routing: Some team members had indirectly worked previously with OSM data through Mapbox. However, none had directly used it. Since we wanted to minimize the amount of dependencies through APIs, we needed to learn to use OSM data directly for routing. Research was then done to determine the best tool for reading OSM data and abstracting it for the routing implementation through this OSM issue commit. To ensure functionality of both the OSM data and routing, multiple tests were executed in the terminal to validate returned values and functionalities.

• Usage of WebSockets: Similarly to how to run a simulation, not many members had worked with WebSockets previously. Hence, research was conducted to learn how to make proper use of them for our software. A test repository was then created to experiment with a simple Websocket application which was presented to the team.

• E2E testing with Playwright:

• Feature Toggles (aka Feature Flags): One team member initially faced challenges with how to disable or hide large portions of in-progress backend API code (hundreds of lines tied to endpoints not yet ready for deployment) without deleting or breaking existing tests. In exploring solutions, they came across feature toggles and helpful resources Martin Fowler's 2017 blog post and YouTube videos by Web Dev Cody (1, 2). What made the resources so helpful was their demonstration of real-world use cases, like toggling API endpoints in a production environment if they begin to cause unexpected performance issues. In parallel, another team member introduced a frontend-facing feature toggle system. This implementation now made it possible for React components to check feature states and enabling local overrides via sessionStorage for testing different flag configurations. Together, these feature toggles established in Release 1 formed a solid foundation for controlled development/testing and handling system behaviour in a production environment.