leandrosansilva/jacodoma

Just Another COding DOjo MAnager

jacodoma's Issues

Timer

Probably the most required feature of a Coding Dojo. The users must somehow be informed the time is over. Some kind of visual and sound alert must me triggered and the screen must be locked until the next programmer takes control. Visually there will be a semaphore with the colours red, yellow and green.

Green means there is still enough time to code, yellow the time is ending and red means the time is over.

Jacodoma report

After the coding dojo, jacodoma must report some statistics, among them:

• % of time the tests where passing
• ranking of the users according to amount of changes done
• rate between implementation and test size (can be dumb, based on number of lines)
• test coverage along the time (requires external tools)

Display participants avatar

Somehow get it from github or gravatar webservices. Useful for ranking, etc.

The tests must run automatically

Somehow the tests must run automatically and its output must be interpreted by jacodoma and shown in a friendly way. The test results are the criteria to "allow" or not the audience to talk (if decided to be like this).

The execution of tests can be triggered on every change on code or periodically.

Commit to git automatically on every change or interval of time

The idea is tracking the evolution of the problem solution automatically, using the current user.

Visual information about the tests state

We have to have some indication that the tests are passing or not. Requires some integration with unit test frameworks.

List of users

Initially we inform the program the list of participants, consisting of name and e-mail. This list will be used to define the participants order (optionally it can be shuffled).

The e-mail is used during the automatic commits.

Tips about session

Jacodoma should notify the participants always it checks they are not "following the rules". For example, when the tests take a very long time without passing; or the implementation files are edited more often than the test ones, indicating implementation are being written without proper testing process.