When creating the outline for my book (now officially published and in print!), I decided to organize it around the nine facets of an awesome command-line app. Each chapter focuses on one of these facets. They state that an awesome command-line app should:

• have a clear and concise purpose
• be easy to use
• be helpful
• play well with others
• delight casual users
• make configuration easy for advanced users
• install and distribute painlessly
• be well-tested and as bug free as possible
• be easy to maintain

In this post, I’ll illustrate each of these facets (along with a test of the tenth chapter on color and formatting), via a code walkthrough of a simple command-line app I created for work.

Here’s a link to download from my talk on JRuby and Threads.

If you just want the “exercises”, here they are:

Apple has just announced Mountain Lion, the next version of OS X, due out in the summer. Although it’s more of an incremental upgrade than Lion was¹, one of the most interesting features is Gatekeeper. Gatekeeper, in brief, prevents unsigned code from running on OS X. Although it can be disabled, it’s on by default, and many feel this is the beginning of the end for users having full control of their computers. I feel the opposite: it’s not a slippery slope, and it’s actually a great feature.

In the last two posts about “clean tests”, we talked about the structure of a test, how to eliminate duplication, and how to make intent clear when using mocks. We left off with a question of magic values: Why do we seem to use them in our tests, when we know they are wrong in production code? Let’s explore that and see how to eliminate their use in our tests without making the tests hard to understand.

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.