Skip to content

WillTaylorDev/wt-name-game

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

19 Commits
 
 
 
 
 
 
 
 
 
 
 
 

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

No packages published

Languages