Wii U

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 :)

Insane Fun’s

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.

Erlang Map Pattern Matching

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.

Splat Operator in Case Statement

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

Race Conditions

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!

The End of a Year

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…

Erlang List Comprehensions

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…

Thoughts on Programming Erlang: Software for a Concurrent World

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.

Ruby Refactoring: Ugly Null Checking

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!

The Snoopy Inspector

This week we had a very deep and hard to track down bug that was only happening on certain Mac architectures. The problem came down to setting shape object data on ActiveRecord models and then mysteriously having that field become nil.

After setting pry breakpoints in several dozen places we still weren’t any closer to solving the problem. The magic meta that ActiveRecord supplies was making it an impossible exercise of patience to step through what seemed to be several hundred stacks of a statement that was this simple on the outside:

shape = FactoryGirl.create :spatial_rectangle
rect = Shape.new
rect.data = shape