-
Notifications
You must be signed in to change notification settings - Fork 0
WillTaylorDev/wt-name-game
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Name Game Submission =============================================================== ======================== Dependencies ========================= =============================================================== A recent version of GoLang (>= 1.8 is required for the sort.Slice usage in the leaderboard file). Altough external libraries would have been helpful (for example, the gorilla/mux library for Go), I chose to stick as close to what's provided in the native framework for ease of deployment for the test project. =============================================================== ====================== Running the Code ======================= =============================================================== To run this code, simply set up your go environment, clone this repository, and go build. You can then run the wt-name-game binary. =============================================================== ========================== Overview =========================== =============================================================== The repository is split into two distinct subpackages: data and handlers. The data subpackage does modification of the configuration, parsing and filtering of the data, and generation of various game components. The handlers subpackage defines our RegexRouter, as well as holds the http handlers that will be called when an endpoint regex is matched. I created two distinct spaces for two purposes: code reuse, and unit testing. It's much harder to reuse code when the http handlers are mixed in with the actions we want to perform. By separating these out, it makes it much easier for other projects to import the 'data' subpackage and use functionality within that space. Likewise, it's much easier to unit test code that's succinct and performs a single action. To avoid having to use a database (one of the "asks" for this project was to have it easily runable out of the box), I used local storage via reading/writing to a file. While there is a race condition with this approach, adding appropriate mutex locking and unlocking would fix it (I had just ran out of time). The API is split into 3 high level concepts; leaderboard, game, and employees. These are better defined in the API Documentation section below. =============================================================== ====================== API Documentation ====================== =============================================================== ** Employees - For ease-of-development (being able to look up employees easily by ID, primarily), I created a -very- simple employee API used to list all the employees, or give details of a single employee * Employee Query Filters: - Filters may be applied when searching for employees - Supported filter params are "id", "firstName", and "lastName" GET the list of employees - curl -u willowtree:password http://localhost:1234/api/1.0/employees GET a single employee by ID - curl -u willowtree:password http://localhost:1234/api/1.0/employees/<id> ---------------------------------------------------------------------------- ** Game - There were a number of things I would have liked to continue to develop for the game API, however I simply ran out of time. I implemented a basic API for listing played games, getting specific game details, deleting a game, creating a game, and solving a game. GET past and present games: - Filters are available for use to sort through the games. Note that a game will be present if it matches any single filter (effecitvely an OR operation) - curl -u willowtree:password http://localhost:1234/api/1.0/games - curl -u willowtree:password http://localhost:1234/api/1.0/games?solver=<user> - curl -u willowtree:password http://localhost:1234/api/1.0/games?id=<id> - curl -u willowtree:password http://localhost:1234/api/1.0/games?id=<game-type> GET details of an existing game: - curl -u willowtree:password http://localhost:1234/api/1.0/games/<id> GET game choices for an existing game: - curl -u willowtree:password http://localhost:1234/api/1.0/games/<id>/choices Solving a game - Done through a PUT (as opposed to a POST), as the game state is being changed - curl -u willowtree:password http://localhost:1234/api/1.0/games/<id> -X PUT -d '{"solution": "<employee_id>"}' POSTing to create a new game - We can specify a game-type parameter of 'matt' or 'standard' - curl -u willowtree:password http://localhost:1234/api/1.0/games -X POST - curl -u willowtree:password http://localhost:1234/api/1.0/games?game-type=matt -X POST DELETing a Game - Remove a game from being tracked - curl -u willowtree:password http://localhost:1234/api/1.0/games/<id> -X DELETE ---------------------------------------------------------------------------- ** Leaderboard - Simple leaderboard which allows us to see which users have solved the most games. The only interaction I had time for was a simple GET. Limit filtering is available via the limit parameter GET leaderboard - curl -u willowtree:password http://localhost:1234/api/1.0/leaderboard - curl -u willowtree:password http://localhost:1234/api/1.0/leaderboard?limit=5 =============================================================== =========================== Testing =========================== =============================================================== Given ample time, I would have created additional unit tests for this project. For now, I have slotted out a space within the tests directory for tests, with a handful of tests designed to test the game structures. To run the tests, simply navigate to the tests directory and run 'go test' =============================================================== ========================= Future Work ========================= =============================================================== There are a few things that should be considered for this project moving forward: - Mutex/locking of the configuration file when reading/writing, to avoid possible race conditions - Cookie management (might be nice to give the user a cookie instead of having to issue basic auth commands each time) - Adding a game start/end time to the configuration
About
Test project submission for WillowTree
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published