Playing By Color

When I was younger we would take our vacations in Arkansas visiting my mom’s family down there.  My grandmother who was quite a good singer and who had quite an intuitive gift for music, had an organ in her living room.  I can still remember sitting there and playing with it.  I couldn’t (still can’t) play music but as with most kids that didn’t stop me from sitting there and making noise.  God bless my grandma–she had to have had the patience of a saint or three to put up with my noodling on her organ.

At one point though I recall finding a colored piece of cardboard in the compartment of the piano bench.  It was something that could be used with a special music book to allow someone who couldn’t read music to pick out a tune by following the colors.  The idea was that you set the colored piece of cardboard on the keyboard at a certain position and then by following the colors in a special songbook one could pick out a tune.  This seems to be an idea that comes up time and again (as evidenced by this) in teaching music to children.

I was so proud of being able to pick out “When The Saints Go Marching In” and have it sound somewhat like the tune should have sounded.

I would never in a million years consider that I learned very much musically.  In fact it’s probably much more akin to some sort of Skinnerian behavior conditioning (“Ooh–I follow the colors and I get pretty music!”) than real music.  But I could pick out a tune.

So this is part of my concern with the whole “everyone should learn to code” school of thought.  While I think it’s a fine idea I’m afraid there are a number of people coming out of these code camps with the software development analog of knowing how to play the organ by following the colors.  That is they can pick out a pleasant tune but without the cardboard they’re lost.

Don’t get me wrong–everyone who writes software has to start with baby steps.  My concern is that we’re not doing enough to encourage new software developers to move beyond the cardboard color guide of software development and truly understand the dynamics of software development.  I’ve seen it more than once or twice–new developers who are utterly lost without intellisense. We need to help people move beyond the rote regurgitation of what they’ve been told to a deeper, richer understanding of the mechanics of what’s going on.  If we’re just teaching people to repeat a series of rote steps then while we’re giving them skills for a career change we’re certainly limiting their future prospects in their new career.  We owe them better than that.

RIP grandma Ruby and thank you for the clarity to sometimes see through the superficial.

Interesting And Unexpected Benefit Of Pattern Matching

So recently I’ve been working on automating some interactions with a website.  Elixir’s Hound library is a great help, of course.  But I also ran across an interesting and unexpected benefit to pattern matching that greatly simplified some code.

I was trying to dynamically build a URL to pass parameters. The URL would be in the form:

Whenever I see code like this, it’s always a little tricky because you want to add the & at the end of each parameter except the last.  This always used to entail writing a special case in the loop to test if the index of the current element was the maximum index.  But with pattern matching and recursion there’s a much simpler and cleaner solution.  Like this:

defp add_params_to_url(url,[%{:name => name, :value => value}]) when is_binary(url) do     #1
defp add_params_to_url(url,[%{:name => name, :value => value} | t]) when is_binary(url) do   #2
 url = "#{url}#{name}=#{value}&"
defp add_params_to_url(url,[]) when is_binary(url), do: url   #3

This is Elixir for those unfamiliar with it.  Basically it’s three function clauses.  The first clause (#1) is hit if only one element is in the list passed into the function. The second clause (#2) is hit if multiple elements are present in the list and the third clause (#3) is hit if the list is empty.

So this is how this works.  When I call add_params_to_url, Elixir will automatically try to match the correct function call dependent on which list I pass.  It will also stop at the first function clause which matches so that other function clauses will not be evaluated.

If I pass a list of URL params which has only one element, clause 1 is matched and the parameter and value are appended and I’m done.  The URL already has the ? on the end, of course.  If I pass a list of URL params with mutliple elements, clause 1 doesn’t match so Elixir jumps down to clause 2 and that matches.  Clause 2 takes the first element from the list tacks it on to the list of parameters with a & at the end and then recursively calls itself with the tail of the list.  If the tail of the list contains more than one parameter, clause  1 will once again fail to match and clause 2 will match again.  If it contains only one parameter, clause 1 is matched.  Because clause 1 doesn’t call itself recursively, clause 3 should never be matched; it’s actually more of a guard case in case someone calls the function with an empty parameter list by mistake.

This, to me, is a small bit of genius.  Much simpler to get exactly the effect I want, that is not having an extraneous character tacked to the end of the string, and it’s nice and simple.

By the way, it occurs to me that I might be able to use a reduce or a fold function to achieve this same effect.  The issue there is that it’s less apparent what it is that I’m trying to do and I also run into the same problem–that is, how do I deal with that last element in the list so I don’t get my separator appended?

The Most Important Quality Of A Unit Test

I assist with the face to face interview of software engineers at our firm.  One of my favorite questions to ask a candidate is “What is the most important quality a unit test should have?”  I’m surprised at how many times I get a blank stare; I mean I would at least expect something along the lines of “It should test all the code in a given unit” or “It needs to be isolated to only a single unit of code” or some sort of response. 

To me though, the right answer is “The most important quality of a unit test is that it has to be easy to run.” If you ever interview with me at my firm, bonus points for you if you quote my answer back to me. 

Why “easy to run”?  Any thing that takes any sort of effort beyond the ordinary will rapidly become something that the developers don’t do.  We all have impossible deadlines and if we have to wait a half-hour after we make a change while our unit tests run, we’ll quickly figure out some way to avoid running them.  It doesn’t matter if you have the most brilliantly written unit tests in the world and they execute all of the code in the unit in a way that would have made Edsger Dijkstra weep with joy at its elegance; if it’s not run by the developers it’s not doing you any good.  If you’ve mastered dependency injection and all of your unit tests are very flexible so that they can be changed without any effort whatever, it will do you no good if the developers don’t run them because they report lots of false positives that no one has ever troubled to fix.

This is the point—make the unit tests dead simple to execute, make them fast and fix bogus tests.  Anything else you do with your unit tests is wasting your time unless you address these fundamental concerns.