This project provides a simple implementation of Sudoku in Javascript, HTML and CSS. It does not use any front-end frameworks like Backbone or Bootstrap.

Each game board is pseudo-randomly generated. This game is responsive and additionally includes support for keyboard navigation on desktop. Players receive instant feedback if their play violates one of the constraints of the game.

This project includes a build system that uses Grunt, Browserify and LESS. The application is tested using Mocha and Chai (for more information on tests, see the testing section).

You can play this Sudoku game online at sudoku.stephenhebson.com.

$ git clone https://github.com/shebson/sudoku.git cd sudoku npm install

Build the project and run a development server by running:

$ grunt server

The sudoku game will now be available at http://localhost:8080.

$ open http://localhost:8080

The application is tested using Mocha. To run the test suite, do npm test. Tests are located in the test directory.

This project uses Travis for continuous integration. Travis runs the test suite whenever a commit is pushed to master.

Code style is enforced by JSLint and JSHint. Application code and configuration code must pass JSLint.

Test code need only pass JSHint, as Chai's expect syntax is incompatible with JSLint (at least until JSLint provides an option for disabling the "expected an assignment or function call..." warning).

I elected to follow an MV* structure for this project. The project is organized into views, models, and Handlebars templates. Because of the simplicity of this project, many standard components like a router were unnecessary.

The views extend a base view that exposes a minimal delegateEvents method. Rather than providing a .extend method or using constructor functions, I elected to take advantage of JavaScript's prototypal inheritance directly by using Object.create to create new views with the base view's prototype.

There is a strict separation of concerns between models and views. This separation is possible because of a observer design pattern in which the game view and validation highlighter listen for events emitted by the board model.

The application is organized in CommonJS modules and bundled by Browserify. When running locally, the application provides source maps, making it possible to take full advantage of developer tools.

Stylesheets are generated by LESS, and I make heavy use of LESS variables to make them more maintainable.

The build process is built on Grunt. In addition to Browserify and Less, autoprefixer is used to enable DRYer stylesheets, and Uglify compresses the final JavaScript before deploys.

Finally, the game is hosted on Amazon S3, and deploys to S3 are fully automated in a Grunt task (though, for obvious reasons, you'll have to provide your own AWS credentials file to deploy).

I'm happy with how this game turned out. I think the choice of structure made it easy to work quickly, and would make it easy to continue iterating if this were an ongoing project.

If I had unlimited time, a couple of things I'd like to improve are:

• If this were a real product, game difficulty should be selectable.
• The board generator takes advantage of the fact that you can shuffle a known sudoku board following certain constraints and arrive at a new board. It then removes values until the game is appropriately difficult. The result is great for game play, but it would be fun to try generating the board from scratch using a backtracking algorithm (though that may be less performant than the pseudo-random solution I implemented).

MIT