Recently in Programming Category

At my job, we test a lot. Unit tests are code, and should be treated as well as the rest of your code. This often means writing custom assertions to keep repetition out of the individual test cases.

When I started writing custom assertions, I did them the easy way:

  def assert_includes(collection, item, message = nil)
    assert collection.include?(item), message || "#{collection.inspect} should include #{item.inspect}."
  end

Unfortunately, this looks and acts just slightly different from a normal assertion:

    1) Failure:
  [1, 2] should include 3.
  <false> is not true.

Lucky for us, Test::Unit is nice enough to provide the building block that it uses for all of its assertions. The snippet is a little longer, but more idiomatic:

  def assert_includes(collection, item, msg = nil)
    full_message = build_message(msg, "? should include ?.", collection, item)
    assert_block(full_message) do 
      collection.include?(item)
    end
  end

This looks much better:

    1) Failure:
  [1, 2] should include 3.

I wanted to take a minute to highlight Jammit, one of the most useful (and best documented) plugins I’ve used lately. Jammit is a really easy way to get CSS and Javascript minification and bundling with really low development overhead.

After installing the gem, it’s as simple as setting up your bundles in an assets.yml that looks something like this:

From code, these bundles can be referred to with the include_stylesheets and include_javascripts methods. When using these functions in development mode, the unminified, unbundled assets are included. In production environments, I wrote a capistrano task to bundle these up using the jammit command provided by the gem:

This minifies, bundles, and gzips all the assets and dumps them in the public/ directory, making generating these bundles something we don’t ever need to think about again.

Way better than the manual bundling rake tasks we were using before.

Joe Armstrong gave a great presentation on Erlang late last year. It’s definitely worth a watch. Erlang’s one of those languages I know would make some really complicated work much more simple, but I never got around to learning it well. Maybe this year?

I finally got around to reading Brian Ford’s recent post, Improving the Rubinius Bytecode Compiler, today. It’s a really good post if you’re interested in compilers, bytecodes, and self-hosting languages, and definitely worth a read when you have the time. It manages to capture that happy medium between skimming the surface of a bunch of topics while still managing to go into a reasonable amount of depth. It makes me want to reread my copy of the blue book again, which is another sign of a great blog post — it makes me want to go out and do something as a direct result of reading it!

I like the idea of a web-only OS, since almost everything I need and use on a computer on a daily basis is accessible through the web, but it’s still missing one of the most critical things, and it’s the same thing that keeps me from going iPhone-only on vacations and long weekend trips — a decent way to edit code. Maybe something like Bespin is the answer — I’ve never tried it out, but would have expected to hear more about it if it was really worth using. Until someone comes up with some kind of web or iPhone-based emacs-like code editor, preferably one that syncs through DAV or some kind of VCS to other computers, I think I’m stuck with traditional laptops and OSes. A shame, because although the keyboard on the iPhone would be worthless for long coding sessions, it’d be great for small corrections and simple edits.

Just wrote this for a friend who’s in the process of writing C… it’s been a while for me, but I think it’s mostly accurate:

So you have your function main().

main() calls a function called int foo(int x).

say you have a file that looks like this:

when the file is compiled, main has no idea what foo() is, if you’re even calling it right, etc. because it doesn’t know about foo() until after main is compiled. There are two ways you can fix this:

1. Define foo before main, like this:

This works when you have functions that only need to be used in one file. But it won’t work if that function is called from functions in many different files.

2. Describe how foo() expects to be called before it is ever called, so main() can tell if it’s calling it right:

This lets you be more flexible, because the declaration int foo(int x); can exist in a bunch of different files that all need to call foo(), but you only need to repeat the first line and not the entire function. This way, anyone calling foo() doesn’t even need to care about what foo() does, just what they expect to shove into it and what they expect to get out of it.

Hope that helps.

The Pragmatic Programmer is one of the best books on software development I’ve ever read, and is definitely the #1 book I recommend to fellow programmers when asked. It’s no surprise, then, that I’m fond of nearly every book I’ve read that their company has published. Lucky me (and you), they’re doing a holiday sale — 40% off everything in the store. Here’s some of the better books of theirs that I’ve read:

1. The Pragmatic Programmer - Not sure if this one is discounted, since it’s usually excluded, but like I said, it’s my #1 and I recommend every working developer read it.

2. Programming Ruby - This and _why’s guide are the books that got me into the language I use to make my living, and the only programming language I’ve ever felt fit my mental model of how programming should be. These days the 1.9 version would be the one to pick up, but this is the one that got me started.

3. Agile Web Development with Rails - The first edition of this book taught me Rails, and I’ve bought every edition since then. It’s still my go-to reference when I need to know something that’s not completely covered by the rdoc and I’m not willing to go source-diving for the answer.

4. Prototype and script.aculo.us - This is the book that taught me to stop looking at javascript as an annoyance, and start looking at it as an opportunity.

5. Programming Erlang - I’m going through this for the second time right now, and like all of the PragProg language books, it’s a great starting point. The language books of theirs I’ve read have done an amazing job of not only teaching the language, but making me excited to use it.

6. Programming Clojure - Like the above book, this is another great PragProg language book. I’m still not 100% sure what I think about the language, but if I decide to use it for a project, I know this will be my reference.

This javascript snippet to create an html dialog box came in really handy today, especially when I overrode the base Dialog.Box with

to make it modal.

I used it like this:

All that’s left is slapping some css on it!

I use git to manage almost all of my projects, and emacs for most of my development work. A lot of times, I want to scope functionality to a specific git repository. I hacked up the following function, that returns a buffer’s git root directory:

It’s especially useful in stuff like:

A bunch of people linked me to Facebook’s presentation on their use of Erlang (among other languages) to build their chat platform. The presentation is definitely worth scanning. One of the things that always strikes me about Erlang is the way people writing software in it can so matter-of-factly dismiss problems that would be huge in infrastructure built on other languages. It blows my mind that things like hot code upgrades, live node inspection and repair, and overall system stability in the presence of tons of errors can be considered “mostly solved problems.” I love the fact that the presentation mentions that error logging could take down Erlang nodes, and it’s considered a footnote, rather than a serious stability problem.

I bought the beta book for Programming Erlang in 2007ish, but forgot most of it, since I didn’t have a good project to use it on. I’m re-learning it now that we’re running into problems that can be naively solved by throwing cores at them, and presentations like these make me really excited about the possibilities it might open.