Exercise Thursday

Goal: Focus for these exercises (and all exercises going forward) on breaking your project down into small behavior examples and coding one behavior at a time. Make behavior grids before writing any code. Make sure to separate business logic and user interface logic.

Warm Up

  • Explain what behavior-driven development is. Why is it so beneficial?
  • Review the specifications each partner wrote yesterday and discuss the following:
    • Is each individual behavior listed as specific as possible? Does each represent one behavior, or multiple behaviors?
    • Is the simplest possible behavior listed first? If so, how do you know it's the simplest? If not, which one should come first?
    • How did you ensure you wrote the least amount of code possible to make each pass? What did that look like?


Roman Numerals

Write a method to convert numbers into Roman numerals. Roman numerals are based on seven symbols:

Symbol  Value
I       1
V       5
X       10
L       50
C       100
D       500
M       1,000

The most basic rule is that you add the value of all the symbols: so II is 2, LXVI is 66, etc.

The exception is that there may not be more than three of the same characters in a row. Instead, you switch to subtraction. So instead of writing IIII for 4, you write IV (for 5 minus 1); and instead of writing LXXXX for 90, you write XC.

You also have to separate ones, tens, hundreds, and thousands. In other words, 99 is XCIX, not IC. You cannot count higher than 3,999 in Roman numerals.

Draft some specifications and input-output examples to brainstorm the behaviors that you'll want to capture in your application. Tackle them one-by-one, worrying only about the future behaviors once the current example is implemented. All specifications should be listed in the project's README.md file.


A classic method for composing secret messages is called a square code.

The spaces and punctuation are removed from the English text and the characters are written into a square (or rectangle) and the entire message is downcased. For example, the sentence "don't compare yourself to others, compare yourself to the person you were yesterday" is 69 characters long, so it is written into a rectangle with 8 rows and 9 columns.

Cryptosquare image

The coded message is obtained by reading down the columns going left to right, outputting encoded text in groups of five letters. For example, the message above is coded as:

"daeer leweo rlref rerne fsyts rdtyt coooe acooo utnyy ouomr hyemr tpseo spsha eput"

Write a program that outputs the encoded version of a given block of text. Again, identify each individual behavior this application should demonstrate, and write a specification (including an input/output example) for each. Tackle writing code for one behavior at a time, and ensure your spec "passes" (you receive the correct output when you provide your input example) before moving to the next specification. List all specifications in the project's README.md file.

The size of the square (number of columns) should be decided by the length of the message. If the message is a length that creates a perfect square (e.g. 4, 9, 16, 25, 36, etc), use that number of columns. If the message doesn't fit neatly into a square, choose the number of columns that corresponds to the smallest square that is larger than the number of characters in the message.

encrypt("Have a nice day. Feed the dog & chill out!");
# => "hifei acedl v..."

Further Exploration

Go back and tackle any Further Exploration exercises from previous days this week that you have not yet completed.

Peer Code Review

  • Is code broken down into plain English specs? Do these specs accurately represent the behaviors required of the program?
  • Are variable names descriptive, and in lower camelCase?
  • Is code indented properly throughout?
  • Is the business and user interface logic well-separated?
  • Does the application work as expected?
  • Is the code clean, well-refactored, and generally easy to follow?