From 8d1f35e273662c3b6bac986a00bceadee4e41288 Mon Sep 17 00:00:00 2001 From: Chris Davoren Date: Fri, 20 Oct 2023 19:45:25 +1000 Subject: [PATCH] Added notes on where period data/algorithm can be found. --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 96f2a2d..5babc72 100644 --- a/README.md +++ b/README.md @@ -40,6 +40,8 @@ Additionally: - The algorithm uses the term `period` to denote specific timing profiles (e.g. off-peak vs peak period). Within each `period` is a single implicit `sequence` that itself is comprised of a set of timed `states` that each fully specify the colour of each light. These are stored in JSON format in the file `periods.json`. - The problem description does not specify behaviour on period change (i.e. transitioning from normal timing to period timing). One would assume that an instantaneous change would easily create unpredictable and unsafe conditions for any hypothetical drivers, and so in this implementation the current full `sequence` is allowed to complete before transitioning to the next period. For this example, a full cycle should not last longer than approximately 80 seconds and therefore this is the expected maximum delay between period transitions. +Period data is configurable/stored in `periods.json`. The implementation algorithm is found in `simulation/simulation_thread.py`. + ## Environment and Infrastructure The wording of the problem description clearly implies the use of C#/.NET, however given my lack of up-to-date knowledge with modern C# frameworks I have chosen Python/Django instead. Django is a modern web framework for Python that includes many more features than are required for this simple project, but again has been chosen for familiarity. A web front-end was chosen due to the broad use of HTML/CSS/JavaScript and the ease with which it can be changed or updated according to need. It would also lend itself particularly well to a scenario where the front- and back-ends would exist on different machines.