This week I got into a conversation regarding monkey-patching. For those unfamiliar; a monkey-patch is when you reopen a class outside of your project and overwrite or add functionality to it. To give an example, here is a little string monkey-patching goodness:

str = "world"
 
class String
  def excited
    "#{capitalize}!!!"
  end
end
 
"hello".excited # => "Hello!!!"
str.excited # => "World!!!"

By reopening the String class and adding an excited method to it we are able to add functionality to one of core classes that ships with Ruby, not to shabby. Also note that it works for instances of String that were created before the monkey-patch took place.

About a month or so ago I decided to dive back into Elixir. My first stop was to read “Programming Elixir, Functional |> Concurrent |> Pragmatic |> Fun” by Dave Thomas. I had read this book now several years ago when it was in serious alpha and I can say the finished product is quite good.

Coming back up to the homestead this Memorial Day weekend has been an amazing and relaxing experience. I’ve been chilling outside and enjoying the fresh air while contemplating about moving back into a more rural setting myself. My wife and I have been talking about where to move next; and I hope it is somewhere a little further away from the city!

This week the question came up of doubles with Rspec testing. For those unfamiliar with this concept, a double is a way of creating fake resources that look and act like the resources you expect to be used inside of a class or method. With the newer versions of Rspec this is as simple as the following example:

describe MaintenanceSystem do
  let(:bad_spring) { double(type: :general, size: :small, condition: :poor) }
  let(:resource)   { double(springs: [bad_spring]) }
  let(:system)     { described_class.new(loaded_resources) }
 
  context 'with a single small spring loaded in resources' do
    let(:good_spring) { double(type: :general, size: :small, condition: :good) }
    let(:loaded_resources) { { springs: [good_spring] } }
 
    it 'should be able to make the repair' do
      expect(system.can_repair? resource).to be(true)
    end
 
    context 'but the resource has a large bad spring' do
      let(:bad_spring) { double(type: :general, size: :large, condition: :poor) }
 
      it 'should not be able to make the repair' do
        expect(system.can_repair? resource).to be(false)
      end
    end
  end
end

When the weight of the world really seems to squeeze in it becomes more important to disconnect from what “seems” important. Step back and take a few moments to enjoy what is around you! I was able to capture this photo with Cassandra while we walked around the Harlinsdale Farm. It helps me remember work isn’t supposed to be as involved and important as I make it sometimes…

Coming from Erlang I’m used to variables being imutable, Elixir doesn’t provide this same level of comfort that I am used to. For instance, when learning Erlang we are taught that once a variable is bound it cannot be changed.

1> A = "Looking good so far!".
"Looking good so far!"
2> A.
"Looking good so far!"
3> A = "Even better?".
** exception error: no match of right hand side value "Even better?"

In Elixir the story is not quite the same…

iex(1)> a = "Looking good so far!"
"Looking good so far!"
iex(2)> a
"Looking good so far!"
iex(3)> a = "Even better?"
"Even better?"

Solving the question of “How” is only a matter of time. The question of “Why” however; now that can take a lifetime…

Sometimes you need to make a quick call against an api but may not have the willpower or time to crack open a script to get things done… When those moments hit just fall back on curl!

Having a great time at Hack Tennessee! Trying to fiddle with Elixir and build some awesome software.

Ever thought you have started commiting work to a new branch and realized your still working off of the wrong branch? Up until today I would normally rewind my commit(s), then switch to the branch I should have had and re-commit my work. It turns out this whole time I could have been doing this…

git branch -m the-branch-i-should-have-been-on

This in no way harms the branch you where on as it will just pull down the remote again that you were on originally on! Meaning the following chain of commands will work out just fine…

# on master when I thought I was on feature-x
git commit -m "Feature X was added because we needed more magic"
 
# Ahhhh crap, I'm on master!
git branch -m feature-x
git push origin feature-x
git checkout master # it's master from before I commited Feature X!

Shout out to Nola for showing me this.