damoclark / buzzer.click Goto Github PK

Implement FSM for host UI

1. Add to web project (browserfiy)
2. Configure and add base states
3. (If missing) Add unit test folder for browser/client BDD tests
4. (If missing) Add NPM script to execute browser/client BDD tests
5. Add tests to ensure behaviour matches and enforces expected state transitions

Implement FSM for server

1. Add via NPM to project
2. Configure and add base states
3. Add tests to ensure behaviour matches and enforces expected state transitions

A lot of the unit test currently access private fields to conduct testing. A clean up effort is required to reduce this.

Hey there,
This is awesome and I would love to use with my students. I was wondering am I missing the index file?

Implement the ability for the server process to write the currently running sessions to disk, when terminating, or otherwise receiving an unhandled signal (not sure about Windows here).

On restart, check for the existence of such a file, and depending on its modification timestamp, reload all the sessions into the process, so that in-progress 'games' can continue.

Human Computer Interaction fixes:
At the moment users need to click on the modal buttons to continue. Need to modify the buttons to submit and bind in js to the .submit event.
Also need to put focus on the first form input on pages/modals

Here is a suggestion for team creation UI.

Rather than have 2 text boxes, and instructions on how to enter information, break it down into two decisions.

Firstly, they choose whether to specify the number of teams, or the size of the teams. Then depending on that choice, only the appropriate/relevant 'input' box appears. So if 'Number of teams' was chosen, then the box: 'max players per team' would be shown, and not 'Number of Teams'.

Thoughts?

.

Being able to customise the interface of the UI, from a server configuration perspective, or even a use perspective would be useful.

Make it colourful and playful for younger children, or perhaps match the branding of an education institution.

Implement FSM for contestant UI

1. Add to web project (browserfiy)
2. Configure and add base states
3. (If missing) Add unit test folder for browser/client BDD tests
4. (If missing) Add NPM script to execute browser/client BDD tests
5. Add tests to ensure behaviour matches and enforces expected state transitions

Implement the Host UI webpage

1. Implement page
2. Add functional tests

Implement the game creation UI

This page will build the game create URL and allow the user to active it

1. Add URL game create handler
2. Implement page

The game classes need a little TLC.

1. Ensure structure will work with specs
2. Format code and bring up-to-standard
3. The FSM will interact with classes - keep that in mind
4. Add tests to ensure behaviour matches specification expectations

Implement the Client UI webpage

1. Implement page
2. Add functional tests

With team-based play, to reduce negative experiences for learners who perform poorly in their team, remove individual scores from the team-based game. So only the team scores are shown.

In a later revision, add an option so host can choose to include or omit (by default) individual scores.

All client request classes, as a minimum, must supply a session id. In addition, many will be required to supply a contestant id or host id. Currently, all client request message implement their own properties/fields for these. To reduce the DRY violation, it is recommended that a base class be created to support these two properties and for existing code to be refactored to make use of it.

When the server adds a team, it would be nice to auto allocate a team name from a list contained within the application. By doing this it would mean a team will always have a name and may save the host creator time if they decide to disable team name editing.

Message classes fall into the following categories:

1. Request
2. Response
3. Notify

It would be nice if they were separated physically in the source

Here is an initial list of configuration options for the server that should be considered for inclusion (after completion of assessment).

• Server IP Address to Bind to
• Server Port to bind to
• Non-privileged user to run as when started as root user (or whatever is equivalent on Windows)

The server should have an 'admin' type page that is password protected such that the site can be managed. This page would

• show the currently running sessions, and other operational statistics
• have the ability to shutdown or restart the server
• have the ability to terminate specific sessions
• block IPs
• who knows what else

Client's may want to disconnect for various reasons such as going home early. Need to handle a client (Contestant) "SESSION_COMPLETE" message to only drop that participant.

The setting passed by the client should be validated on the server's side before creating a session

A future feature

The server needs to be configurable at start up.

Conventional methods to do this include

• Command line args
• Configuration file
• Environment Variables

In all likelihood, there will be an npm module that will cater to this, perhaps even all of them, and in a OS-independent way, for the Windows folk.

I'll add a separate issue for configurable options necessary.

Complete the server/client messages

1. Add all required messages
2. Add JSON schema for each message
3. Add tests to ensure schemas matche expected behaviour

The description says it all.

If the server is run as 'root' user (or equivalent on Windows), changing the effective user and group of the process to one configured (see #32 and #31).

An example of how to do this from Thomas Hunter. Will require a little research to ensure it fits with the Express framework used.