I rate my project as a 3 - Meets Expectations in the Functionality category of the rubric. I was able to create the Enigma class with the encrypt and decrypt methods successfully implemented. In addition, I successfully implemented the command line interfaces using the applicable runner files.
I rate my project as a 3 - Meets Expectations in the Object Oriented Programming category of the rubric. I broke the project down into three logical components representing the three different pieces of information, or objects, that are included in message encryption/decryption - the message (Message class), the key (Key class), and the offset (Offset class). Each class is encapsulated and each class has a single responsibility. The Key class creates the four keys, the offset class creates the four offsets, and the message class encrypts or decrypts the message based on the keys and offsets returned by their respective classes. In addition, no classes are unreasonably small or large, with the largest class a total of 100 lines and the complete project running 172 total lines of code.
I rate my project as a 3 - Meets Expectations in the Ruby Conventions and Mechanics category of the rubric. All of my code is properly indented and spaced, and no lines are excessively long. In addition, I followed all Ruby conventions when creating class, method, variable, and file names. I utilized the .each enumerable three times in my project, and it was the most appropriate enumerable for all three use cases. .find and .find_all were not appropriate enumerables for any of the cases because I didn't need a subset of any of the collections through which I was iterating. In addition, .map was not an appropriate choice because I didn't need to perform the same calculation to each element I was iterating over and I needed to use an accumulator to differentiate between different characters and iterations. Thus, the .each enumerable was the most appropriate for all three situations. Furthermore, I implemented six hashes (create_keys, create_offsets,initial_shifts, shifts, encrypt, and decrypt) in ways that make logical sense. For all but the last two use cases, a hash was used to return the appropriate key, offset or shift based on the key, offset, or shift letter symbol. For the final encrypt and decrypt use cases, a hash was returned with the appropriate information, as indicated in the interaction pattern.
I rate my project as a 4 - Above Expectations in the Test Driven Development category of the rubric. I wrote all of my tests prior to my implementation code. In addition, my test coverage metrics show 100 % coverage. I also stubbed in a date in the test_default_date method in the EnigmaTest class to make the testing more efficient and to ensure the formatting of the default date is correct regardless of the current date on which the test is run. I used a second stub in the test_encrypt method in the EnigmaTest class to ensure correct returns are received from the encrypt method if no date is entered. Without utilizing a stub, there would be no way to test the returns of those methods because "today's date" would change every day, causing both tests to fail.
I rate my project as a 4 - Above Expectations in the Version Control category of the rubric. I completed over 90 commits and worked on 10 different branches during the project. My commits were completed after I wrote a test method and then again once I successfully completed the related method. I created separate branches for each different piece of functionality - setup for the project setup, key_class for the Key class, offset_class for the Offset class, message_class for the Message class, enigma_class for the Enigma class, cli for the Command Line Interface, refactor for changes made during refactoring, and master to bring all of the different pieces of functionality together. I also initially created decode_class and encode_branch branches for the project, but merged that functionality into the message_class branch and Message class after writing some of the methods and determining that the related functionality should be encapsulated in one Message class. When I completed related chunks of functionality, I completed Pull Requests and merged the applicable branch with the master branch. Following that pattern, I merged sixteen pull requests while completing the project.