Skip to content
Phill Conrad edited this page May 11, 2014 · 4 revisions

Welcome to the AwesomeNextSteps wiki!

Some Design Decisions

(1) We'll create a simple JSON based syntax for specifying quizzes.

  • Each quiz question type will be represented.
  • quiz question types can be parameterized. For example, an order of operations question might have "number of operators" as a parameter, with default 2.
  • where there are parameters, suitable defaults are desirable.
  • There will be a way to specify repetition
  • There will be a way to specific "choose k of these n items"
  • There will be a way to specify "shuffle these items"
  • There will be a way to "group" items (so that they are treated as a single item)

(2) We will create a simple JSON Shortening service. Similar in principle to a URL shortening service such as bit.ly, but instead of shortening URLs, it is shortening JSON strings. The JSON string should include the version of the software, represented as the MD5 Hash of the github commit for that production version.
It can also provide validation of the JSON against that particular version of the software---and provide for customization of the shortened string.

(3) The quiz generating service has two modes:

Mode 1: Simple mode (one question type at a time): URL takes a question type, number of questions, mode: questions only, answers only, or both.

Mode 2: Complex mode (custom mix of questions specified in a JSON string). takes in the URL the hash from the JSON shortening service, a Seed. (number of questions is embedded in and implied by the JSON string.)

The JSON Shortening Service

The JSON Shortening service is the only part of this that requires state to be maintained---either in a database, cloud storage service, file system, etc.

One initial idea that Evan C. and Phill C. discussed was that of just storing the JSON files to file system. Note that certain cloud providers don't allow Node.js applications to write to the file system. In Heroku, for example, anything you write to the file system is considered ephmeral. Changes to the file system are not shared among "dynos" (units of work) and are not persistent.

Clone this wiki locally