This is intended to reflect the style and format of the final ELEC40004 exam, in terms of knowledge coverage and rough difficulty. However, it has not been as heavily vetted, so may contain errors or inconsistencies. Knowing that we will not be dealing with errors, it's actually slightly less vetted before release (though with no intentional errors), so that people will be on the look out for places where they need to make reasonable decisions.
In your final commit you should check exactly two of these check-boxes to indicate which questions your have decided to answer:
- : Question 1
- : Question 2
- : Question 3
If you do not tick enough boxes, or tick too many, then Q1 and Q2 will be marked by default.
Note that you are welcome to try all three questions, but you must select just two for assessment.
Checking a checkbox just means putting an x in it, for
example:
- : Selected
- : Not selectd.
If you encounter an error or inconsistency in the exam, you should attempt to work around it in the most appropriate, sensible, and consistent way. You should not ask other teams what their opinion is.
If you encounter any such bugs, document them in the file
erratta.md, and include it in your submission.
Nobody is required to take part in this practise, and you don't have to work on it for 8 hours. You can try working on it for an hour then go do something else if you want. Nobody is watching this or judging you, and it has zero impact on marks or our perception of you. If you don't do anything at all today in your repos, then no-one will mind or care.
You should spend 8 hours on this exam, from your first commit through to the last commit. However, you can start whenever you like between 10:00 and 2:00 (+1) on the exam day.
One of your team should clone this specification, and push it
to your shared repository at elec40004-2019-exam-test1-${TEAM},
for whatever your value of ${TEAM} is. It should be of the form
${LOGIN1}_${LOGIN2}.
When this push is detected, you are considered to have started.
From that point on you should only look at the spec in your private repository, and should ignore the globally visible spec. Changes to the spec may be made for time-stamping purposes, so you should always stick to the version you cloned.
During the period you work on it, you should be pushing your intermediate work at regular intervals - ideally at least every 60 minutes while you are actively working. It is strongly reccommended that you push to remote feature branches rather than merging and pushing to master.
Your commit history is your record of what you did and in what order - it would be considered... odd, if there was no activity for four hours, and then suddenly a whole bunch of perfect code appeared at once. Your development history should be your actual history, including partially working code, or not-quite-compiling code.
Your final submission is whatever the last commit is on master, 8 hours after your first commit. Where there are inconsistencies in timing, the timing of observed pushes to github are used - we are well aware that github timestamps can be faked.
Backup submissions via hash can be made through blackboard. Note that this is only a temporary route to prove that you completed work at a particular time. Eventually you'll need to push the corresponding commit into github that matches that hash, so you must keep hold of your local repositories until you manage to push.
Based on the results of this dry run we may change submission routes slightly, or add more safety features. But for now we just want to see how it works (and so can you).