20 lines
2.4 KiB
Markdown
20 lines
2.4 KiB
Markdown
# Feedback
|
||
|
||
Given 21/10/2023
|
||
|
||
## Original Feedback
|
||
|
||
1. If you know the amount of time until the next state change, why not just wait that amount of time to submit your next request for state?
|
||
2. I am not sure of Django, but admin apps and models don’t appear to do anything, can they be removed?
|
||
3. The same with migrations
|
||
4. It may have been a good idea to separate the styles, scripts and html to separate files, but not a big deal.
|
||
5. I liked the approach to modelling the state transitions, my attempt was far more complicated than yours, and I think simple is best. It didn’t occur to me that I could just map out ever single state transition.
|
||
|
||
## Initial Response/Notes
|
||
|
||
1. Mainly because I wanted a countdown, and because I wanted that countdown to not drift on account of any client factors. Also, for testing purposes, I wanted to make sure that the simulation was changing states when it said it would (not before, and not after) and returning data appropriately. If network traffic or server load were to be an issue, this would only require modification to the client code.
|
||
2. This is fair. As alluded to in the README, Django is overkill for a web application of this size, and all of these things are added by default by the `django-admin startapp` command. Much of it very likely could be removed, but I lack the necessary intimate knowledge of Django to do so safely. Ideally I would have chosen a much more lightweight framework like Flask, but Django is the tool I know so I stuck with it.
|
||
3. As for (2)
|
||
4. Again fair. In an enterprise application this would be done almost without question. I considered doing it here but there are a couple of weak-ish reasons why I decided not to, not least that it allowed all presentation logic in one place for the purposes of review. In reality though, I acknowledge that it's better practice to keep the HTML/CSS/JS in separate files in nearly all cases.
|
||
5. Thanks. I considered a number of alternatives at the start, including hard-coding the logic, but all of them seemed either over-complicated, or more importantly too difficult to change or customize should hypothetical traffic conditions change or were to be applied to more than one intersection etc. However, I did make the assumption that there would be no need to specify behaviour outside of a single 24 hour window. Significant reworking would be required were this constraint to change.
|