Another ten years or so passed, however, before I really learned how to debug software. That happened at my first job out of graduate school, when I went to work for a company that produced commercial software for computational fluid dynamics (CFD) analysis. The sort of scattershot debugging approach that I’d used up until then would no longer suffice. We had customers paying pretty hefty licensing fees to use our software, and when they reported a bug we needed to make sure that we could get a solid, reliable fix out to them so that their work wasn’t disrupted. It wasn’t enough to make the symptoms of the problem go away. We needed to understand what was broken, how it got that way, and only then implement a solution. Fortunately, one of my mentors at that company taught me this more rigorous approach to debugging software, one that I continue to use to this day.

Earlier this year, I had the opportunity to do a technical review of Paul Butcher’s new book, Debug It! and now that it’s been published I’m pleased to be able to review the final product. A number of classic programming books, such as Steve Maguire’s Writing Solid Code or Steve McConnell’s Code Complete, touch on debugging as one aspect of the software development process, but I’m not sure that I’ve ever seen or read an entire book devoted to the topic of debugging software. In that regard, Paul’s new book fills a pretty interesting niche.

Paul breaks the debugging process up into four stages: reproduce, diagnose, fix and reflect. These stages are covered in detail in the first five chapters of the book, and this is the most important section. In the chapter on reproducing bugs, he touches on topics such as how to control the environmental conditions under which bugs manifests themselves, and techniques for reproducing the inputs that trigger the bugs. He also addresses some of the difficulties involved in dealing with especially difficult-to-reproduce nondeterministic bugs. In the chapter on diagnosis, Paul moves on to the process of forming a hypothesis about what’s causing the bug and then performing experiments to refine that hypothesis until you settle in on a root cause. There are a lot of useful guidelines here, including my favorite: Only change one thing at a time! The chapter on fixing bugs is relatively short, which reflects the reality that once you understand what’s going on it’s usually not that difficult to fix the problem. Here the author stresses the importance of adding regression tests, and making sure that you’re fixing the root cause and not merely the symptoms. The last step is to reflect on the significance of this bug and what it might be telling you about the overall quality of your code (e.g. are similar bugs lurking elsewhere in the code?)

The second section of the book (“The Bigger Picture”) takes a higher-level look at the issues surrounding software bugs, namely, how do you create an environment such that you stay on top of bugs and not fall into an “infinite defects” situation. It addresses topics such as tracking bugs and working with users and the support staff to better understand the bugs they’re seeing in production. The third section of the book (“Debug-Fu”) is sort of a hodge-podge of more advanced topics, I suppose. Some of the information in these later chapters is arguably out of place in this book. For example, Chapter 9, “The Ideal Debugging Environment,” stresses the importance of having automated tests, a continuous build system, and so forth. There’s no question that this is good advice; I’m just not sure that it’s completely on-topic for this book. Having said that, they are good disciplines for any programmer to have, and if the stuff in the rest of this book is new to you there’s a good chance that Paul’s advice on testing and continuous builds is new to you too.

It is important to note that the focus of this book is the debugging mindset, and strategies and techniques that you’ll use when debugging software. It does not teach you how to use any particular debugging tools. If you merely want to learn how to use the GNU debugger (gdb), or the graphical debugger in your IDE of choice, this is not the book for you.

In conclusion, I would highly recommend Debug It! to any junior-level programmer who’s interested in developing a more disciplined approach to debugging. If you’re not a junior-level programmer but still feel like you waste a lot of time debugging, you will probably find this book helpful as well. It’s like having a mentor sitting there with you, teaching you how to take your debugging game to the next level.

Buried a few paragraphs down in the news, however, is this tidbit:

So, what does this mean for RubyForge? The Ruby-specific functionality and data will be moved into RubyGems.org, and the parts that other hosting sites (GitHub, Google Code, SourceForge) can do better will be pruned away.

In the comments, I asked for clarification on exactly what RubyForge services will be going away, and Tom Copeland’s reply seems to indicate (to me) that the answer is “everything”:

… We’re putting together a schedule for standing down (or making read-only) various bits of RubyForge. The thing is that now there are much better options for hosting code/forums/lists/files/etc, so that stuff is going to be retired. I think back in 2003 it made sense for the Ruby community to have a dedicated site for hosting that stuff. Now I don’t think it does… I think GitHub/Google Code/SourceForge can all do a better job at that, and Ruby Central doesn’t have to expend resources/time/money supporting functionality that others are doing better.

This is troubling to me since several FXRuby-related services (such as the web page hosting, bug tracker, and mailing lists) are handled by RubyForge, and have been for a long time now. For me, it’s not merely a question of, say, finding a new place to host the mailing lists. It’s also making a decision about what to do with the archives, and dealing with all of the non-readers who will go out their way to try to subscribe to the old lists even when they’re clearly marked as inactive and then send e-mails to me to ask why that’s so. But I know that Tom and company are sensitive to these concerns, and we’ll figure out a way to make the transition work as painlessly as possible, so I’m going to try not to be a grumpy old man about it.

So in the meantime, I’m beginning to consider what my post-RubyForge options are. Setting up a dedicated Redmine installation, as Jim Weirich has done for his projects, is an attractive option as it provides one-stop shopping (and I’ve had some experience with setting up Redmine for other projects already). Another option is to go with different sites targeted at the different services, like entp’s Lighthouse for bug tracking, maybe Google Groups for the mailing list hosting, and maybe piggybacking the static web site content off of my personal web site somehow (ugh). What about you, dear reader? If you’re hosting one of the 8,500 projects at RubyForge, what plans are you contemplating for RubyForge’s looming retirement?

One of those platforms is the new MinGW-based Ruby installer for Windows, which is quickly approaching its first release candidate. This is a really exciting development and while it’s not quite yet the official Ruby distribution on Windows, I don’t think that day is far off.

I actually quietly released a MinGW-compatible gem for FXRuby 1.6.19 a month or so ago, but there’s a little problem with it, which is that it’s only compatible with Ruby 1.8.6. If you’re running the MinGW build of Ruby 1.9.1, this gem isn’t going to work for you. That’s not a problem in and of itself, but it is a problem because the RubyGems installation process has no built-in smarts to distinguish between gems that only work with one Ruby version or another. Before someone jumps on that: Yes, I’m aware of the requiredrubyversion attribute for the gem specification. What I mean is, there’s no way to say, “I want to install the FXRuby gem for my platform, but make sure you get the one that was compiled for Ruby 1.9.1 and not the one compiled for Ruby 1.8.6.” The requiredrubyversion attribute seems to only be used to prevent you from installing an incompatible gem–it’s not something that the gems are indexed on.

The recommendation from Luis Lavena of the RubyInstaller project is to build what he calls a “fat” gem (as described here and here), one that includes multiple builds of FXRuby and that selects the “right” one at load time. This will naturally increase the gem’s size, but hey, disk space is cheap and it’s a proven solution to the problem. So I’m looking into this approach now and hope to incorporate it into my build process soon.

Another new platform is Mac OS 10.6 (aka Snow Leopard). For an operating system that’s just a little over a month old, you’d be surprised at how many people are already looking for an FXRuby gem for Snow Leopard. (Well, maybe I shouldn’t be surprised, given the Mac love in the Ruby community). This has been a little tricky because some of the tricks that I’d used in the past to build universal binaries on OS 10.5 (Leopard) didn’t work quite the same way under 10.6, but I think I’ve just solved that. If you’d like to help me test this, you can download a pre-release version of that gem here. Note that this is intended for use that the Ruby 1.8.7 that comes pre-installed with Snow Leopard. If you’ve built your own Ruby (as many folks do), this might work for you too, but if it does that’s just a nice bonus.

Once I’ve resolved the problems involved in supporting these two platforms, I’m planning to release FXRuby version 1.6.20. There won’t be that many functional improvements for those of you already using FXRuby 1.6.19, but it will help to prove out the new build process and re-stabilize things for future releases. I’ve also been doing a lot of work behind the scenes recently (since the move to GitHub) to make it easier for people to hack on FXRuby and contribute code back to the project, but that’s a subject for another post.

What Happened on Friday

Ben Mabey opened the Hoedown Friday morning with his overview of how to use Cucumber (and related tools) in the Behavior-Driven Development (BDD) of software. He made the point that BDD is a mindset and not a toolset. In other words, BDD is not synonomous with Cucumber and RSpec, and it’s less important which tools you’re using than that you’re doing BDD. Ben’s talk moved at a very quick pace and I found it difficult to follow despite my familiarity with the basic concepts. A number of his slides also included dark text on dark backgrounds, which were difficult or impossible to read. Despite these flaws, he did provide some useful information for Rails developers who are looking to take their BDD skills to the next level. Several of the tools and techniques he mentioned (such as using HtmlUnit with JRuby) were new to me and have given me ideas about how to do more effective testing.

Corey Donohoe was up next. The title of Corey’s talk was “How to Be Simply Awesome,” but I’m not exactly sure what the topic was. It was a bit of a ramble, but entertaining nevertheless. The part that most resonated with me had to do with how he and his co-workers at Engine Yard have structured their internal software projects as collections of services instead of monolithic applications. It gave me some ideas about how we could maybe use Sinatra and JRuby to provide a RESTful interface (for third-party clients) to one of our existing Java-based web applications that’s hurting for an API.

After a break for lunch, Leon Gersing gave a presentation on desktop and mobile application development with Appcelerator Titanium. Titanium has been on my radar for awhile now, and so I was especially looking forward to this talk. One of the most interesting takeaways for me, and one that I had not yet picked up on, was that Titanium’s compiler (if that’s the correct term) will convert embedded Ruby or Python code into Javascript, or at least something that can talk to the rest of the runtime via a Javascript bridge. Don’t quote me on that. But it’s something approximately that cool.

Next up was Luke Kanies, talking about how to use Ruby to develop external domain-specific languages (DSLs). I’ve heard Luke speak about Puppet before, and was afraid this was going to be another Puppet-centric talk. (Not that Puppet isn’t cool, but you know, I’ve heard about it before.) But this was really more of a lessons-learned kind of talk, and a good overview of the motivation, tools and general process for developing external DSLs. Although most of the information that Luke presented was familiar to me, it was nevertheless a timely reminder that despite all of the recent attention on building internal DSLs on top of Ruby, there are some very good reasons to opt for an external DSL. For example, one of the dangers of using an internal DSL is that it makes it harder to restrict what the user is able to do.

Following Luke was Luigi Montanez, on “How to be a Civic Hacker.” Now this was an interesting topic, and one that I don’t believe I’ve ever seen addressed at a Ruby conference (or other tech conferences for that matter). Luigi works for Sunlight Labs, part of the Sunlight Foundation, and their mission is using the Internet to promote government transparency. Luigi posited (a little tongue-in-cheek) that the pinnacle of participatory government, much better than merely tweeting about your pet cause or joining a Facebook group to promote your candidate, is to engage in “civic hacking.” He gave a number of examples of how people are taking the raw data published by the government and turning it into useful information via web applications and other services. The only drawback to the presentation came near the end, where Luigi veered off into a quick demonstration of how one could take advantage of Google’s App Engine gem to publish their JRuby applications to the cloud (and get free hosting to boot). It would have been a good topic for a lightning talk, or even a separate full-blown presentation, but it felt sort-of tacked on to the end of an otherwise coherent talk.

Due to a cancellation earlier in the day, a slot had opened up in the schedule by the end of the day, and so were treated to a surprise presentation by Jim Weirich on “Source Control for People Who Don’t Like Source Control.” He opened by promising us that despite the title, “this talk is not about Git.” Jim went on to construct from first principles how his ideal source code control system would work, if he had to design one from scratch. As time went on, it became clear that while he was describing a mythical SCCS called “csc”, he was in fact talking about how Git works under the hood. Like every presentation of Jim’s that I’ve ever seen, it was thoroughly engaging, entertaining and educational.

What Happened on Saturday

Something I ate on Friday really did a number on me, and let’s just leave it at that. The result was that I didn’t get much sleep on Friday night, and I slept in and generally took it easy on Saturday morning, so I missed several presentations. I heard through the grapevine that there was a good presentation on Heroku, and another on how threads work in Ruby 1.9, so I hope to review the slides for those talks at some later date.

The first talk that I heard after my return to the living was David Chelimsky’s talk on the use of mock objects in testing. It wasn’t really an introduction to the topic, more of a “best practices” type of talk. I was encouraged (sort of) to see that other people are struggling with some of the same problems that I struggle with when using mocks. For example, it can sometimes be tricky to decide whether to use a “stub” or a mock in a particular situation. David’s advice in this situation is to use stubs to enable execution, but to use expectations (via mock objects) to express the intent of the test. For some of the thornier questions about how to deal with mock objects, David recommended the forthcoming Growing Object-Oriented Software, Guided by Tests, by Steve Freeman and Nat Pryce. (A free preview of this book is also available online.) He also managed to get in a plug or two for the RSpec book, which is currently in beta but should be available in print later this year. I’m reading the beta of this right now, and can highly recommend it for anyone who’s interested in learning how to use Cucumber, RSpec and Webrat for test-driven development.

Then came the lightning talks. I didn’t take many notes on these, but this seems like the time to mention that there was a lot of buzz about MongoDB this weekend. Luigi made reference in his presentation to the fact that MongoDB just reached 1.0 status, and at least two different lightning talks were about MongoDB.

The Ruby Hoedown proper closed with Jamis Buck’s keynote address. I can’t remember for sure, but I think this was the first time I’d ever heard Jamis speak. He’s very good at it. Jamis opened with a discussion of the art of making string figures. He covered the different notations (or languages) that people use to describe string figures, the “libraries” or patterns of standard moves that are combined and incorporated into more complex patterns, and the string figure-making community at large. He made the point that at first, before you’ve taken the time to really understand how string figures are constructed, the process of turning a simple loop of string into a complex figure can be appear to be “magic”. He went on to relate this to our experience as software developers. The difference between good and great programmers, Jamis said, is the level of understanding, and there are four ways to increase your understanding and thus become a better programmer:

1. Know Thy Tools. Take the time to learn how the tools you use regularly, such as the operating system, text editors, the shell, source code control systems, etc. work.
2. Know Thy Languages. You’re rarely working with just one language, such as Ruby or Java. If you’re doing any sort of web application development, at a minimum you’re also dealing with HTML, CSS and Javascript. Take the time to understand the finer points of these languages.
3. Know Thy Libraries. Know why you’re using the particular libraries you’re using, and what distinguishes them from competing libraries. Engage in code spelunking to understand how libraries work under the hood.
4. Know Thy Communities. Don’t merely be a “consumer” of community resources like mailing lists, forums and IRC channels. Be actively involved, recognizing that for these communities to really work it requires both giving and taking.

And with that, the conference concluded. I know that there were various after-hours parties on Friday and Saturday night, but I didn’t make it to any of those so I’ll leave it to others to say what went on there. It looks like a few photos are starting to appear on Flickr, and I know that people were making pretty liberal use of the #rubyhoedown hashtag on Twitter despite our failure to make the “trending topics” list, so be sure to check out those sources for more insight into the weekend’s festivities!

Update: Tommy Morgan has posted his recap here. If I come across any others I’ll try to remember to link ‘em up here.

The Kindle Itself

For starters, let’s get it out of the way and admit that the Kindle’s user interface is just horrible. I am thinking specifically of the little 5-way joystick that you use to navigate around a page’s content. If you push the stick in a given direction and hold it, it will at least “repeat” and hop across the page until you release it, but it’s still very awkward to use. I’ve never had my hands on a first-generation Kindle so I don’t know if this is an improvement over how navigation worked in that model. The 5-way feels extremely fragile and I can easily imagine it snapping off or otherwise breaking. If a touchscreen like the iPhone’s wasn’t feasible for the Kindle 2, I wish they could at least found some other mechanism, such as a trackball or a small trackpad, to handle this need.

My other gripe has to do with the Kindle’s built-in web browser. To be fair, it’s labelled as an “experimental” feature, but it’s pretty lousy and it’s awfully slow. If you had some notion (as I did) that you might be using your Kindle as a web browser on any regular basis, you’re probably going to be disappointed. For occasional Google or Wikipedia searches, it’s fine, but anything more than that is an exercise in frustration.

Those issues aside, I’m pretty happy with it. The Kindle is a lot thinner and more lightweight than I would have expected. It is so thin, in fact, that it feels a little flimsy, and I’m worried that I’m going to accidentally snap it in half one of these days. But I do like the form factor a lot.

You have probably already read that the screen “flashes” when you turn pages in a book. It’s definitely distracting at first, but believe it or not, you get used to it after awhile. I also haven’t had any problems due to the lack of a backlight for the Kindle’s screen, but I try not to read too much in low light environments anyways. At any rate, for straightforward reading, the Kindle provides a really nice reading experience.

The Kindle Store

Buying a book in Amazon’s Kindle Store works very well, and it is as fast as advertised. Once you purchase a book, it’s typically downloaded and ready to read in a minute or so. I also appreciate that you can download a free sample chapter for most (or all?) of the books in the store.

The book selection is still hit or miss. If you’re looking for a current bestseller, you’re almost certainly going to find it. A number of older books that I was looking for aren’t yet available, however. For example, only one of Douglas Coupland’s books (Miss Wyoming) is available in Kindle format as of this writing. On the other hand, Amazon seem to be adding new books all the time. For example, when I did a search the night before last, David Foster Wallace’s Infinite Jest wasn’t available, but I just looked again and it’s now available for pre-order. Their selection of technical books also seems to be improving, slowly but surely.

If you’re the kind of person who reads this blog, you’re also the kind of person that already knows there’s a lot of free content available for the Kindle. I tend to stick with Feedbooks, but there are several other good sources out there, and there’s a lot of overlap between the various collections. To be honest, most of this free content is either (1) books you already read in high school or college and (2) books you wouldn’t care to read even if they’re free. But occasionally, you’ll run across something interesting.

Other Uses for the Kindle

One of the less hyped Kindle features is that you can e-mail documents directly to it and, if necessary, they will be converted to the Kindle’s native format. I admittedly haven’t tried this much yet. I do have a number of technical papers and documents in PDF format, and it doesn’t seem to do a very good job of converting those, so I’m not sure how much use I’ll get out of the document conversion service. This capability does however open the Kindle up to some interesting applications.

One of my favorite uses for the Kindle involves Marco Arment’s Instapaper service. You know about Instapaper, right? You should check this out even if you don’t have a Kindle. Instapaper provides you with a “Read Later” bookmarklet that you can drag to your web browser’s bookmarks bar. If you come across a long article, or one that you’d just like to read later, click the “Read Later” button and Instapaper will save it for you.

I had already been using Instapaper’s iPhone application to read saved stories on my iPhone, but Instapaper can also be configured to send unread articles to your Kindle on a regular basis. Every Friday morning, Instapaper collects all of my unread stories into a sort-of custom newspaper and sends it to my Kindle. This is a real killer app for me.

Another apparently popular service is Kindlefeeder, which is an aggregator that collects up all of the stories from a given news feed and sends them to your Kindle on a scheduled basis. I haven’t tried this yet, but if there are any feeds that you typically read every story from, you should find this extremely useful. It sure beats paying for a blog subscription in the Amazon Kindle Store.

Summary

There are a number of problems with the Kindle that have nothing to do with its lack of a color touchscreen or its high price tag. It certainly lacks the polish that I’ve become accustomed to with, for example, Apple’s products. But I’m getting a lot of use out of my Kindle, and I don’t regret purchasing it. If you read a lot, I think that you will get your money’s worth out of the Kindle too. And if, like me, you do a lot of your reading on the web these days, the combination of a Kindle with services like Instapaper and Kindlefeeder is very handy.

Jeremy has set a goal of $15,000, which would cover the basic costs of a venue in downtown Nashville (this year’s conference site), sound and promotional materials. Obviously, if you’re associated with a business that’s able to make a sizable donation, that would be great, but individual donations of any amount are greatly appreciated. See Jeremy’s blog for more details about how you can participate.

A demi-entendre is an expression or phrase that comes from accidentally combining two common expressions…

Give us something to hang our hats on.

Give us something to sink our teeth into.

“Give us something to hang our teeth on.” (Atlanta advertising agency director Selena Smith, as quoted in the New York Times).

The first step is to download and install the latest Exerb distribution (version 4.2.0, as of this writing). It’s packaged as a ZIP file, which you’ll need to extract into some convenient place on your hard drive. Once that’s done, change directories into the exerb-4.2.0 directory and run the setup.rb script.

cd exerb-4.2.0 ruby setup.rb

Now, to actually go through the process of building a standalone FXRuby application, let’s start with a simple example. We’ll use the hello.rb example program from the FXRuby source code distribution. The first step is to generate a “recipe” file for your Ruby application, which is basically a listing of all the files that Exerb should use to build the executable. You’ll use the mkexy tool to do this.

ruby -r exerb/mkexy hello.rb

The mkexy tool runs your application in a custom version of Ruby to analyze which libraries it requires while it’s running. Once you exit the application, mkexy spits out a recipe file (for this example, hello.exy) in the current working directory.

Now that you have a recipe, you’re ready to run Exerb to generate the executable.

exerb hello.exy

Note that the executable that Exerb creates is quite large, as it bundles both a copy of the Ruby interpreter as well as the FXRuby library code. When I did this experiment, the executable weighed in at close to 9 Mb. You can distribute this executable to other people who don’t have Ruby or FXRuby installed on their computers.

Now let’s look at a slightly more complicated example, the hello2.rb program. The complication is that this example uses an external file, a PNG icon that it loads from disk at runtime, as shown in this excerpt:

icon = nil File.open(File.join("icons", "hello2.png"), "rb") do |input| icon = FXPNGIcon.new(application, input.read) end

This is unfortunately something that Exerb doesn’t handle very well, but there is a workaround. What we must first do is dump the contents of the PNG icon to a Ruby string, and store the contents in a regular .rb file. Here’s some code to do that:

File.open(File.join("icons", "hello2.png"), "rb") do |input| bytes = input.read File.open("hello2_icon.rb", "w") do |output| output.puts "ICON = #{bytes.inspect}" end end

Now we need to modify the bit in hello2.rb that loads the icon data, so that it instead loads this Ruby code instead:

require 'hello2_icon'

icon = FXPNGIcon.new(application, ICON)

Now, run the mkexy tool as before to generate a recipe file (hello2.exy) and then exerb to generate the executable.

ruby -r exerb/mkexy hello2.rb exerb hello2.exy

There are at least a couple of other tools out there for building standalone Ruby applications, including Erik Veenstra’s RubyScript2Exe and Jeremy Hinegardner’s Crate. I’m not at all familiar with how those tools work, but if you’ve had luck building standalone FXRuby applications with either of these tools, I’d love to hear about your experience.