Hopefully you’ve read Steve Yegge’s excellent kingdom of nouns essay, in which he bemoans a pattern that exists in a lot of Java-base systems. The tell-tale sign is a class named ThingDoer with a single method doThing(). Systems like this don’t arise simply because Java is the way it is, but when you follow SOLID principles (particularly the single responsibility and dependency inversion principles), your code ends up with lots of small classes that do one thing only.

In Java, you are basically stuck with this, but in Ruby (or any OO language that supports closures/blocks/functions), we can fight this by using Procs instead of classes.

In a previous post, I talked about the overall structure of a test and how that was important to understand the test itself. A brief review:

• Given - Establish the conditions under which the test will run
• When - Run the code under test
• Then - assert that the code did what you expect

This structure becomes problematic when using either mock objects or block-based asserts.

Code comments often get a bad rap, especially in the Ruby community, with phrases like “code should be self-documenting” floating around, legitimizing the production of code with no documentation at all. In fact, code comments are one of the many useful tools developers have to make their intent clear, and writing them off as a “code smell” is naive and dangerous.

Some collegues and I were dicussing dupication in tests, specifically how much repitition of code across tests is acceptible. On the one hand, you want each test to stand on its own and indicate what it’s testing. On the other hand, just because we’re in a test doesn’t mean that all the rules about duplication of code don’t apply; tests need to be maintained to, and if you make a large change, you don’t want to have to change it in several places.

How much duplication is too much or, what does duplication in tests mean, and how does it affect the understandability and maintainability of our tests?

At the start of 2011, I blogged about a “professional goals” file I found on my computer, and compared it to what happened. I kindof enjoyed the exercise, so here’s a repeat.

I just finished reading the short and to-the-point Working with Unix Processes, by Jess Storimer. Although I cut my teeth on C and UNIX programming, it’s been a while, and I figured I’d check the book out to see what insights it might have, especially given that it’s written from a Ruby perspective.

In short, I’d recommend this book to someone interested in command-line Ruby (and who might have my book), but who has very little UNIX programming experience. This book is a crash-course in the basics of UNIX Process management.

That being said, if you are (or have been) familiar with things like fork and exec, you’ll find this book a bit too light, especially given the price (update 1/2/2012 see inside).

I’ve spent the last year writing a book on building awesome command-line applications in Ruby. Over the course of writing it, I’ve used a lot of Ruby libraries for building command-line apps, and none of them work quite right. In my book, I spent significant time on OptionParser, since it’s builtin, and GLI, since I wrote it (and since it’s actually very fully-featured compare to the alternatives).

I just finished up an appendix where I showed alternate implementations of the running examples using main, thor, and trollop. I did this for a few reasons:

• These tools are popular, and people have asked if they’d be included
• They are, by and large, very different from how OptionParser and GLI work
• I wanted to give them a real shakedown

I also surveyed many other tools, but, alas, I couldn’t include everything. Each of these tools have a common theme, which is to avoid the boilerplate of OptionParser, and make it really easy to parse command-line arguments. They all have done this, but at a cost. All of them are less powerful and extensible than OptionParser, and only slightly more compact (or, in the case of main, more verbose).

Enter methadone, which has all of OptionParser’s power, but the compactness of these other frameworks.

I’ve always liked superhero stuff, but was never into comics as a kid. Reading Wikipedia summaries of the insanity that is the DC universe’s continuity makes me never want to touch the stuff. Now, it seems, they’ve thrown all of that out and started things fresh. Though it’s not a reboot. Whatever.

Museums aren’t the only things curated anymore - now, everything is!