notes.txt

2012-04-02: Work on PuzzleNode "Secret Messages" problem
Link: https://github.com/sandal/puzzlenode-solutions/compare/9070...3b79

>> File.foreach("/usr/share/dict/words").find { |l| l =~ /^apple$/i }.chomp
=> "apple

Tempted to provide a fake dictionary file, but YAGNI? (could have been an
alternate way to deal with performance)

Time spent on test boilerplate noticeably tedious and boring. Hard to maintain
focus.

Dependencies in cracker... would people really inject and/or mock here? Seems
overkill. (Tests running in 0.3s)

Don't think I would have thought about doing Enumerator solution in caeser cipher if not doing
TDD. Originally had much more ugly implementation in Cracker that expicitly
enumerated over 0..25 (that resulted in connascence of algorithm).

- two refactorings that felt easier with tests: Ruby -> UNIX dictionary change,
  introduction of Caeser#shifts

Using isolated requires has not sucked as bad as I thought it might, and is
somewhat useful for clearly seeing the dependencies in a given file. Need to see
how this works in a larger project though. -- accidentally missed a few though
which weren't failing when running the whole suite, but were failing when
running the individual file. (This typically happened when I added a new object
type without changing the original tests -- i.e. adding the LetterShifter )

Found it harder to take breaks for some reason.

Hard to determine how much tests should be written beyond the specific example
(i.e. implied specs) -- err on the side of less, but fear undefined behavior

More conscious thought put into arguments of object constructors / methods
(Oh, I'll be looking at a single key and shifting it many times, so decode
should take the shift index, not the key)


  cipher.decode("GARDEN").must_equal("COWARDS DIE MANY TIMES")

Struggle to decide whether another test is needed to show how the numeric
conversion happens here, lean towards YAGNI. This caused me to very slowly bang
through trial and error... probably should have done some pencil paper
calculations and then written a test -- but this is an issue with understanding
the problem, primarily.

LetterShifter a "found object"

Enjoy the precision of knowing where the failure is (for example, just doing
testing of the whole program would output invalid output but not hint at
*where* the changes were.