hjorthjort/capstat

capstat's Issues

Lock match when it's not ongoing

A match that isn't started or has ended should not be able to register new hits or misses.

Bugfix: After TextFileTaskQueueTest is run, remove taskfile.txt

When TextFileTaskQueueTest is run it creates file taskfile.txt. This is never removed. It should not stick around after the test, as it is only used for the test, and it should not be shared over git.

Fix: Add @afterclass method that deletes the file to TextFileTaskQueueTest.

Add underlines to show how shortcuts can be used to navigate the GUI

Shortcuts are implemented but without any visual way of showing they exist, no one will know about them.

Timestamp to be inserted into database

We need date/time for a match to be inserted into the database. This will preferably be the starting time of the match.

Give Match a spectator

Should be the logged in user, which could be an actual user or a guest.

Implement logged in user and guest user

Make capstat have the possibility to have a logged in user and a guest user that is logged in by default.

Varchar(10) restricting the new matchid format to be saved in database

fix in database.sql

Make match pausable

Add constant Strings for use by subscribers to Match class

An observable pattern that will use Objects or Strings as key, like for example the EventBus in CapStat, should use constants defined by the publisher that the subscribers should subscribe to.

Make statistics view plot real data.

Create value objects for matches and users in the infrastructure layer that can be returned by the facade for database queries

These should be simple value objects, containing everything needed to create a user, like nickname (String), ELORanking (Double), etc, and the same for matches.

This is an important part of separating the infrastructure layer from the domain layer, as the infrastructure layer should have no dependence on the domain layer or the classes in it.

Name suggestions:

• "UserDatabaseRow" and "MatchDatabaseRow"
• "UserValueObject" and "MatchValueObject"

Throw exception in ThrowSequence if the state you want to update to is not valid

Let's say someone tries to update a ThrowSequence with a starting point that looks like this:
lastThrowWasHit: false
startingPlayer: 1
Glasses: O X O O O X X O O

An exception must be thrown, since this is not a valid glass state and is caused by a logical error.

Add top class documentation

Add javadoc comments to top of classes exlaining their intended use, which classes they are intended to be used by, their concept at a high level, etc.

This should help with maintenance, and is also a grading criteria.

Use enum for hits and misses

They are currently implemented using an inner abstract class which itself has inner classes, which feels like a bit too complicated for its own good. Replacing these with enums should reduce the complexity without changing any of the functionality.

Make ThrowSequence class

The ThrowSequence class should be able to register hits and misses. It should also be possible to set a new starting state for the ThrowSequence, with a state of the glasses and a starting player decided by the user.

Add forward and rewind methods to Match

These should also update the state of the glasses, player turn, etc.

Create simplified infrastructure for saving and retrieving matches, using a Facade

Responsibilities include:

Save a new match to local "file", using Sasers file interface class.
Save from that file, using a background Thread (that should not be part of the Facade, probably).
Retrieve matches from the database (get basic info, and create new match via a Factory)

Specify and implement equals() for classes

There should be good specifications and implementations for equals() for more or less all classes that we have created. Both because it makes sense, and because it will probably help us in our unit testing later (I'm guessing JUnit's assertEquals() uses equals() to check for equality).

Make sure startMatch and endMatch in Match can't be called at the wrong times

startMatch and endMatch now set the startTime and endTime variables.

Therefore, it's important that each method may only be called once.

Task Queue Thread Class

Create a class that can be called when a new statement should be sent to the database. This thread should be active as long as the queue is not empty.

Pressing enter on login doesn't fucking log you in

Annoying as shit, not that important though. Should be an easy fix, not prioritized right now

Refactor match class into several classes

Match class is at the moment very fat, full of methods and fields. It should probably be refactored in to a larger set of classes, where the match class delegates responsibility to other classes. This should make it more object oriented and possible to change more easily.

Make Match use EventBus for event handling

Make enum for Player1 and Player2

Storing this information in integers requires exception handling. This could be helped by creating an enumeration. A boolean could do the trick, but would not be intuitively understandable.

Tests are failing: null pointers and erroneous values

At the time of this writing, the develop branch has failing tests because of null pointers and erroneous values. They seem to have been introduced by the merges resolving #4 and #6.

Move default behaviour to Factory-class, create Matches via Factory

The default match should have a win condition of 4 won glasses and 2 won rounds.
As of now these conditions are set in the Match-class, while they should be set in the Factory-class.

Refactor Birthday and Admittance to use the Java time package

At the moment, integers are used, which can cause errors and requires error handling.

Gradle tests fail due to the separate thread sometimes not being able to do things in time, DatabaseFacade..

Earlier everything was performed step-by-step, now the queries for inserting things into the database are being handed over to a parallell thread, causing the main test thread to continue even though the separate thread may not not have finished it's tasks yet.

Decide starting player from ChalmersAge, or let user choose

Who starts the game should be automatically decided by the match based on the ChalmersAge of the players. However, it should also be possible for the spectator to decide starting player, regardless of the players' ages, or if the players have not been set yet.

These two features should ideally be implemented together, since they might interfere with each other.

LoginController has empty methods, need them to be done

As of right now the LoginController has empty methods but Javadoc to determine what the methods actually do. Someone needs to write the code (Hjort)

Save matches via ResultsLedger

Implements methods in ResultsLedger to save a match to the database. The Match should (probably?) be given by an instance of the Match class.

Pressing escape while in a match takes you out of the running match

never to be seen again ...

Unable to delete users if matches are registered containing that user

Just drop the constraints in database.sql in matches

Create the Event Bus

Create an event bus where listeners kan register themselves to listen for certain updates using strings. Listeners are stored together with their keys in a Map.

Possibly the event bus should take a few different types of Listeners, most highly prioritized are:

• DataEventListener – skickar med objekt
• NotificationEventListener – inga parametrar

Fix null pointer exception getting thrown when you try to login with an unused username

Make Match follow the Strategy pattern

The Match class should have variable representing it's strategy towards saving matches: whether they should be ranked or unranked. This could be a boolean, or a Strategy object, which would give some added complexity but also flexibility. This object/boolean should be passed along to wherever in the system rankings are updated, perhaps through the event bus.

Implement a "task queue" for temporary storage of SQL queries

As mentioned in #10, a possible solution for temporary storage of matches is to store SQL queries (for insertion of matches into the database) in a text file on the computer, in case a connection to the database is not available. This can be abstracted to a "task queue": a queue of tasks to perform, that can be added to and removed from, on a FIFO ("first in, first out") basis.

A solution that this issue suggests is to have a ITaskQueue interface and have different concrete implementations of that interface, e.g. storing SQL queries in a text file.

Make it possible to rewind, forward and update match from a new state in MatchController.

Move security to model layer

The Security class represents a Service in Domain Driven Design. That is,

1. it fulfills an operation belonging in the domain layer, an operation that does not belong in any entity or value object.
2. the interface doesn't contain elements from other layers.
3. the operation is stateless.

Therefore it should be moved to the model package. This also gives greater package coherence.

Make ChalmersAge comparison go by Admittance first, then Birthday

This has to be changed in the tests also

Move Factories and ThrowSequence to Model Package

The Factories for players and matches are conceptually a part of the domain model, and should be in the same package to avoid tangled package dependencies.

ThrowSequence is also conceptually a part of the domain, and should be in the model package.

Make ELORanking and ChalmersAge immutable value objects

Value objects should be immutable, according to good domain driven design practice.

Implement functionality to save match results in a local file

Alongside the database - soon to be set up - we will need a way to store results, temporarily, outside of the database, to make sure no data is lost even with crashes, errors or connectivity issues.

The most reasonable way should be to store the SQL queries meant to be sent to the database as rows in a text file, and delete the rows only when they have definitely been saved to the database.

(Possible issue) Users should be identified by CID, not nickname

If a user with a nickname leaves the sections, and another user joins the section and uses the same nickname, should they be able to register with the same nickname as the old user? If so, users should be identified by CID, which will always be unique.

Restrict starting a match with the same user as p1 and p2

Duude

Alter User table

As it is now, it is impossible to change data for a user directly as there are no such methods in the facade.
One possibly way to do this anyway is to read a user to a blueprint, delete the user from the database, change data in the blueprint and re-add the user again with the new data.
Methods to alter the user data should be added in DatabaseFacade though.

Implement match rounds

At the moment, a match consists of a single round. It should consist of an odd number of rounds, and end once a player has definitely won.

Suggested implementation: Give the match the number of rounds a player must win to win the whole match, rather than the maximum number of rounds which can be played. This should give more readable code.