ROVER NAVIGATOR 

--------------------------------------------------------------------------
RUNNING THE SYSTEM

To run the program from the command line, type: 
 ruby bin/navigator
 
NB. When loaded, the system will ask you for an instruction file to process.
Press ENTER to use the default instruction file (input1.txt), 
this file uses the test scenario data provided in the coding assignment.
You can store your own instruction files under the folder 'instructions'
 
--------------------------------------------------------------------------
DESIGN DECISIONS & ASSUMPTIONS

I have built my software in Ruby 1.8.7 and have followed a BDD approach 
utilisng Cucumber and RSpec.

I used Git for version control.

I felt in addition to running tests that it was important to create a program
that actually did something as the ability for the customer to try it themselves
is just as important as passing tests hence my small command line app. 

I assumed that a NASA Engineer would be operating the system and rather than 
be inputing instructions by hand and maybe would have made calulations or run 
other software to determine where they wanted to move and were hence providing 
an instruction file for the system. This also seemed to reflect the format
of the input the customer provided.

I created a folder called 'instructions' for the user to save their instructions in.

Following an object orientated approach I ended up with three basic models:
Plateu
Rover
and System

Plateu for the initialized plateu, an instance of Rover for each rover created and
System which handled all the file reading and activity which formed the base for the system.

To implement the basic output I found that initially I did not even need to 
reference to plateu at all. I felt this was not within the spirit of what was 
required and that from the specificiation I made the assumption that the rover 
should be free to move as long as it stayed on the Plateu.

Without this assumption there seemed little point knowing or using the size of the plateu.

As such I implemented tests to ensure the rover's moves remained within the plateu
and that the rover stopped if it reached the edge of the plateu and the next 
insruction would have push it off the edge.

It would be possible check a full set of instructions and move nowhere if
any of them would move the rover to the edge, but I decided to go with a graceful
deactivate on reaching the plateu edge with an appropriate warning. This would enable 
the engineer to have mapped the original area desired and then could send new 
instructions from where the rover now stood, confident that at all times the 
rover would never go off the edge.

I also considered collision handling of a rover going into a square occupied by 
another rover, but saw this as an additional feature and also it's possible that 
the areas are very large and two rovers can safley pass each other when crossing
throught the same grid co-ordinate. So that would be an obvious next feature in my 
mind which I took the assumption was outside the initial scope but would depend 
on feedback from the customer.

I used an array to store the directions North, South, East, West and found it easy
to cycle back and foward through the array to mirror the effect of the rover 
turning 90 degrees clockwise or anti-clockwise. Ruby made it easy to go continously 
backwards through the array (anti-clockwise) but I used a slightly different approach
to go contiously forward (if at end of array).

I also implemented a hash of a rover's current position eg.
 {"x_position" => 2, "y_position" => 2, "direction_facing" => "North"}  
but in hindsight may have just gone with passing the short codes around eg. "12N" 
considering that for the audience they would likely follow this convention 
just as easily.  It meant that I was passing around two versions of current position, 
the full version and the SHORTCODE as I called it. Grounds for future refactoring once
I knew which way the project was headed.

I also considered the output from my program.
I had created some output text as the program processes the file.
As I thought it would be easier for the engineer to get a glimpse of what the 
program is doing, even just confirmation he's processing the right rover
instructions I think is useful.

But based on the spec Ive decided just to print that the file processed ok, 
and then the Output itself.

When working in a team and with the customers feedback I'd get a much better
feel of if it is critical that just the output codes are printed or that 
a more verbose output would be useful (or even an option to pick).

Ive enjoyed making this software and Im actually very interested to hear your feedback.


--------------------------------------------------------------------------
PROBLEM: MARS ROVERS

A squad of robotic rovers are to be landed by NASA on a plateau on Mars.
This plateau, which is curiously rectangular, must be navigated by the
rovers so that their on-board cameras can get a complete view of the
surrounding terrain to send back to Earth.

A rover's position and location is represented by a combination of x and y
co-ordinates and a letter representing one of the four cardinal compass
points. The plateau is divided up into a grid to simplify navigation. An
example position might be 0, 0, N, which means the rover is in the bottom
left corner and facing North.

In order to control a rover, NASA sends a simple string of letters. The
possible letters are 'L', 'R' and 'M'. 'L' and 'R' makes the rover spin 90
degrees left or right respectively, without moving from its current spot.
'M' means move forward one grid point, and maintain the same heading.

Assume that the square directly North from (x, y) is (x, y+1).

INPUT:

The first line of input is the upper-right coordinates of the plateau, the
lower-left coordinates are assumed to be 0,0.

The rest of the input is information pertaining to the rovers that have
been deployed. Each rover has two lines of input. The first line gives the
rover's position, and the second line is a series of instructions telling
the rover how to explore the plateau.

The position is made up of two integers and a letter separated by spaces,
corresponding to the x and y co-ordinates and the rover's orientation.

Each rover will be finished sequentially, which means that the second rover
won't start to move until the first one has finished moving.


OUTPUT

The output for each rover should be its final co-ordinates and heading.

INPUT AND OUTPUT

Test Input:
5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

Expected Output:
1 3 N
5 1 E