If you’re like me; sometimes you’ll get cranking on some code and before you realize it, you push your changes back up with the help of tab completion auto-populating your branch for you… which was master. You quickly realize the pain you’re in as all kinds of amazing build processes kick off with the ceremonious event of a new master build! After doing this twice in a year I decided to find a way to help prevent myself from doing it again.

Got a Wii U yesterday and my productivity has come to a grinding halt. I hope to find balance with this new toy that seems to take all of my time :)

I ran across an Erlang fun that could recursively calculate exponentials and it was very perplexing at first.

fun(X) ->
  G = fun(_, 0) -> 1;
         (F, Y) -> Y * F(F, Y-1)
  end,
  G(G, X)
end.

This is double the fun from what I am used to seeing. The outer fun constructs another fun that is designed to take itself as a parameter. Mind blown!

After looking this over for a bit I realized it wasn’t tail-call optimized so after a couple stabs I took it to the next level.

fun(X) ->
  G = fun(_, A, 0) -> A;
         (F, A, N) -> F(F, A*N, N-1)
  end,
  G(G, 1, X)
end.

One of the new hot topic items in Erlang R17 is maps. In Ruby you would call them a hashes, PHP calls them associative arrays, no matter what you call them it’s the same idea: key-value pairs. Back in the “Good old days” :tm: an Erlang programmer would need to leverage a record to get the same functionality. While records are very good and carry benifit they lack some of the flexibility found in maps.

Today I learned that this is valid ruby and is yet another example of how awesome the splat operator, *, really is.

  EVENS = [0,2,4,6,8]
  ODDS  = [1,3,5,7,9]
 
  result =
    case 3
    when *EVENS
      :even
    when *ODDS
      :odds
    else
      :unkown
    end
 
  result # => :odds

Spent all day battling against a race condition, and boy do they suck. Nothing seems repeatable about the errors and every test you write seems to pass. What kind of beast was I running up against? One of a high-volume nature that would only rear it’s head when the system was under a large strain of course!

As the year ends I look back at the places I’ve been in the last year or so and stand in awe at it all. Learning new programming languages and living in new locations make for a great combination! All of the changes have left me a bit out of shape though…

Reading through the book “Learn you some Erlang for Great Good” and learned a bit more about List Comprehensions than I knew before. If you are new to the world of Erlang, you’ll soon discover these marvels. Here is some of what I know about them…

I finally finished reading Joe Armstrong’s second revision of his book this week and having never programmed Erlang before it has been a tremendous help. There are some issues with information in the book, but for the most part it’s pretty rock solid.

What I was Expecting

• The book does a great job of building on itself from one chapter to the next. Never is there a time when something completely out of the blue comes out at you.
• Prepares you for R17, which has some really nice features in it!
• Examples are easy to follow and the exercises re-enforce and help you remember each chapter.
• Highlights pitfalls of introducing concurrency in the wrong places.

What I Wished For

• More coverage of OTP in the book. There is not much mention of the OTP framework in the book. I plan to find another that goes more into this aspect of Erlang.
• A bit more detail on the -behavior() tag. This may relate to the prior point of wanting more on OTP. It would be nice to know how to write your own behaviors and unfortunately this was not in the book.

When you can, always try to use the Null Object Pattern; however, there are times that may prove difficult. This doesn’t mean you need to abandon all readability though. Here is a block of code I ran into today that was improved with a little refactoring TLC.

Before

items.each do |item|
  next unless item.widget
  update_widget! item.widget
end

After

items.each do |item|
  next if item.widget.nil?
  update_widget! item.widget
end

Just because nil is conveniently falsey doesn’t mean it’s always best to treat it that way. Compare the before and after blocks above. Which has clearer intent on why next is called? I’m sure if you read it a bit the first makes sense, but the whole point is to avoid the necessity of reading code that much to figure out what it’s doing.

This is one of the cooler idioms I love about Ruby. nil? is baked into nil to be true and on Object, everything else, it’s false. Using this makes your code more readable, use it every chance you get instead of that ugly null boolean check!