►Software Development
▼—TAHBPL
•B — Exploring Your TAHBPL
7.8.0.1
    ← prev  up  next → 

B — Exploring Your TAHBPL

Due Thursday, September 12, midnight

Delivery You must deliver your artifacts in a directory called B in your repository (master branch):

  • traversal.md, the artifact for task 1;

  • B, the executable for task 2.

All auxiliary files must be put into a sub-directory called Other.

Task 1 Your company has hired a group of stellar programmers in Codemanistan, a country located in a galaxy far, far away. Your manager has put you in charge of writing a specification for the interface for a module, dubbed labyrinth, which these stellar programmers will implement in your favorite language and ship back real soon.

As the name suggests, the high-level purpose of the desired module is to provide the services of a basic labyrinth. For our purposes a labyrinth is a connectivity specification for nodes in a simple graph, and a simple graph connects each node to at most one other node. The desired software must support these operations:

  • the creation of a plain labyrinth with named nodes;

  • the addition of a colored token to a node;

  • the query whether some colored token can reach some named graph node.

Formulate your specification in a mix of English and technical terms appropriate for your chosen language. For example, in Java you would use the term package and you might use types while a Pythonista would speak of modules and use informal data definitions.

Write the specification using the MARKDOWN format. When printed, it must fit on a single page. Specify the precise language (name, version) in which you expect the product to be written in.

Pedagogy The goal of task 1 is to get a glimpse of the tasks that team leaders perform in software companies. This specification is quite small so that a single page should easily suffice to give precise instructions to developers.

Task 2 Your team voted, and the vast majority fell for the latest and greatest teenage-heartbreak fashion of data exchange languages: JSON. So now it is your turn to explore the JSON capabilities of your chosen language.

Develop a program that reads a series of well-formed JSON from STDIN. In addition to being well-formed JSON the values are also valid elements of this set:

    A StrJ is one of the following kinds of well-formed JSON values:

    -- Strings

    -- Arrays that start with a String

    -- Objects that have a key "this" whose value is a String

    No other well-formed JSON values are valid StrJs.

Once STDIN is closed, the program sorts the JSON values according to its single command-line argument. If the command-line argument is "–up", the sequence is sorted in ascending order of the designated String parts; otherwise it is sorted in descending order.

The sorted sequence is written to STDOUT as a list of JSON values.

Here is a sample input:

    ["b",1,2,                        3]

      "a"   {"this" : "c",

         "other" : 0}

If the program is invoked with –up on the command line, you expect

    ["a",

     ["b",1,2,3],

     {"this" : "c", "other" : 0}]

back. Do not worry about the spatial layout of the output value; our test harness will compare the JSON values regardless of white space.

Pedagogy The goal of task 2 is to figure out (1) how your language processes command line arguments, (2) whether it has a good library for reading and writing JSON, and (3) how to deploy programs runnable in LINUX in your chosen language. See sources like this one for details.

    ← prev  up  next →