Yes, I'm having a hard time keeping this blog up to date. I'm using the weekends to write the missing entries. Sometimes the day ends and I'm just too tired, so I leave it to the next day. Otherwise I end up writing superficial and completely not useful stuff just to fill the gaps and sleep. But fear not! I'm taking notes during the day, everyday, of what happened, this way I can remember what happened. And add something interesting to it as well.

Friday. I thought I knew something about OOP, but each page of POODR just shows me how much I don't. Awesome.

Your design challenge is to manage dependencies so that each class has the fewest possible; a class should know just enough to do its job and not one thing more.

Defining a Hash as the parameters of a method is a good way to remove the dependency of the knowing the number and order of arguments from the caller.

class Foo
  def initialize(args)
    @bar    = args[:bar] || "some string"
    @baz    = args[:baz] || 123
    @foobar = args.fetch(:foobar, true)
  end
end

If the parameters of the Foo class change, you won't need to make a change on everywhere it is called. And you can set defaults using the || operator. With one exception: boolean values.

The || operator acts as an OR condition, so even if :foobar is a valid key of the args Hash, but set to false or nil, then the condition will fail, and true will be the default value. Unlike the [] method that returns nil for missing keys, the fetch() method actually expects the key to be present and offers ways to handle missing keys (the second argument in the example).

Okay, it's really cool to learn new things, but I have to admit, the best part of my day was discovering sl and cmatrix programs. You can install it using Brew on a mac, or apt-get on Linux (no clue on Windows, sorry):

brew install sl
brew install cmatrix

steam locomotive

matrix

There was an awesome presentation on TDD this afternoon, teaching "The Method". Basically:

  1. Define the next most simple possible test that will fail
  2. Run the code and see it fail
  3. Change the code to make this only test (and all of the previous) pass
  4. Go back to 1 if there are more cases to be covered
We have the tendency of trying to figure out the whole problem at once, so it's really hard to stick to "The Method", but the benefits were undeniable. Following this simple algorithm, there's no need to keep too much information in your head at the same time, and you can go back to where you stopped any time. Your final code will have a great test coverage when it's done, and now it's the only time where refactoring will be safe.