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.
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.
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..."
Go back and tackle any Further Exploration exercises from previous days this week that you have not yet completed.