Mike Bowler

If you're working with ruby in or around Toronto, check out TorontoRB, a new site for the local ruby community.

torontorb.ca is central place collecting all of the relevant information about where to go for Ruby'ists in the GTA. Blogs, upcoming events, mailing lists. You got it, it's here. Or if not let us know and we'll make sure it gets added

Looking through the rspec documentation, I find this...

We strongly recommend that you use RSpec’s mocking/stubbing framework to intercept class level calls like :find, :create and even :new to introduce mock instances instead of real active_record instances.

This allows you to focus your specs on the things that the controller does and not worry about complex validations and relationships that should be described in detail in the Model Examples

This notion that we should isolate every component and test it entirely by itself is something that I've heard over and over again. At one point, I even believed that it was a good idea. Such is the way of an anti-pattern. In the beginning, it usually appears to be a good idea and it's not until you've actually tried it that you start to realize that it might not have been so good.

A long time ago, I worked on a project where we followed this practice. Where the only time we touched the database was when we were testing the persistence layer. For each layer above that, we would mock out what came below so that each layer was tested in complete isolation. We had lots of tests and they all passed.

So when we showed the application to our client and it started blowing up, we were shocked. We had all kinds of tests! They all passed! How was it possible that anything was breaking?

We identified and fixed all those bugs and went back to show the client again. Once again, all our tests passed. Once again, the application blew up over and over again.

Looking at all the bugs that had been discovered, we noticed some interesting patterns. All of the bugs that our client was finding were in interactions BETWEEN layers. Each layer by itself was covered by tests and was working fine. The interactions between layers, however, were not being tested in any reasonable way and that's where all the bugs were.

I've seen this same idea in many applications. Whenever there is a strong emphasis on testing in isolation, many bugs are hidden until much later in the process. Sometimes not to be found until the application enters production.

The solution to this problem is simple. Don't ever assume that your isolated tests are enough. You always have to have tests that pass through all parts of the application.

Colorado Software Summit has posted the initial agenda for the 2008 conference. As I've written here before, if your business is writing software, you need to go to this.

I have a situation where I need to switch back and forth between two different versions of Ruby. I'm doing some work for one of my clients which is based on Ruby 1.8.6 and I'm also working on the EasyBrandingTools.com site which is based on Ruby 1.8.4.

Ruby 1.8.6 has a particularly nasty bug in its XPATH support which completely breaks EasyBrandingTools.com so we are unable to upgrade to that version until this bug is fixed.

I did some digging through the MacPorts documentation and discovered that it didn't remove the 1.8.4 installation when it upgraded to 1.8.6 and since both versions are there, I can easily switch between them by deactivating one and activating the other. The magic to do that is...

sudo port deactivate ruby @1.8.6_0

sudo port activate ruby @1.8.4_2

This makes it very easy to support multiple different versions of Ruby on the same machine and saves me a lot of configuration grief.

Throughout the year, Colorado Software Summit posts PDF's of the slides from the previous conference to encourage people to visit the site. I see that they've posted the slides from the two talks I gave last fall. The talks were:

• Ruby for Java Programmers
• Ruby on Rails: Beyond the Hype

I see that Colorado Software Summit has posted the agenda for this years conference. If you're writing software, this is a must see event.

Here's an excellent example of unusable software. It's clearly complex enough that the nurses on duty couldn't figure out how to use it properly and so they entered data that was inaccurate. This is not the fault of the staff who were using the software, it's the fault of the process that allowed clearly inadequate software to enter production.


Many companies are willing to accept software that is barely usable and highly error prone. In many places, it is more important to have delivered something even if that something doesn't work very well. This is generally due to local optimizations where individual groups are measured based on how they have met smaller objectives and not on how they have helped the organization as a whole.

I'd planned to blog each day of Colorado Software Summit 2006 but that didn't work out as planned. The week was very busy as usual and I didn't get around to blogging what I'd seen.

Once again, the conference was fabulous. I always learn as much from casual conversations as I do from the presentations themselves. Every year, I come away from this conference, having learned an enormous number of new things.

Thanks again to Wayne and Peggy Kovsky who put on this amazing conference.

This year there seem to be more people blogging about the conference and it's nice to see what people are thinking.

I'm at Colorado Software Summit this week. This conference doesn't have "tracks" as many others do. Instead, every presentation is given three times throughout the week so that everyone has a chance to plan their own schedule in a way that gets them to all the topics they are interested in. As an attendee, I really appreciate this structure as it lets me get to all the topics I care about. As a speaker, it's a big of a pain as it means I have to talk six times throughout the week.

Registration was yesterday afternoon, followed by the reception dinner in the evening. The conference officially started this morning.

John Soyring started off the conference with IBM's perspective on SOA. This has become a huge business for them.

Roberto Chinnici presented Scripting in the Java™ Platform which covers the general support that Sun is planning for dynamic languages on the JVM. JSR-223 covers the API for adding scripting engines to Java™ SE. This is scheduled for Java™ SE 6.0 (Mustang). There are already a large number of languages that are planning to be supported by this API. One interesting tidbit is that XSLT will be accessible through this.

After lunch, Kimberly Jennery presented PHP Dynamic Web Pages, Without Knowing Beans, an introduction to PHP. Not having any experience with PHP, I found this useful.

Next was my own presentation on Ruby for Java Programmers which seemed to go over well. This was the first of three times I'll be giving this one. Dave Landers has some positive comments about this talk on his blog. Thanks Dave

There's been an awful lot of interest in Ruby so far. Tonights Q&A session had quite a few Ruby related questions and then I ended up giving a demo over dinner as well. It's nice to see all this interest.

Closures are a really powerful language feature found in languages like Ruby, Smalltalk and Lisp. It has annoyed me for years that Java™ does not support them. In discussions with people at Sun, I've requested closure support a number of times in the past and was always told that it would never happen.

Imagine my surprise then to discover on Gilad Bracha's blog that a serious proposal for closures is working its way through Sun. To make it even more interesting, one of the four co-authors is none other than the "father" of Java™, James Gosling.

More information from Peter Ahé and Neal Gafter.

I'm not fond of the proposed syntax but I'm very happy that this is being considered.

 public static void main(String[] args) {

     int plus2(int x) { return x+2; }

     int(int) plus2b = plus2;

     System.out.println(plus2b(2));

 }

An interesting tidbit I got from the spec is that the C++ standards committee is also considering adding closures to that language.

In response to my last post on horrible code in Java™, Blaine Buxton brings up the Collections class.


I agree completely with Blaine. The Collections class and it's cousin the Arrays class are perfect examples of bad design. Methods like sort() clearly belong on the collection itself and not on a utility class.

Let us also not forget the binarySearch() method in Collections that implements a search on a collection you pass in. For collections that have good random access support it actually does do a binary search as the name suggests. For collections where random access is not fast, it does a brute force search. The fact that it adapts to always get good performance is a good thing. The fact that it's named "binarySearch" when it doesn't always do that is not.


Generally, I've found that utility classes are workarounds for limitations in existing code that cannot be changed. If I'm not able to add a method to the String class, for example, then I'm forced to put methods that really belong in that class into a utility class. In Java™, you can't even subclass String so just about every large project I've worked on has had a StringUtility class somewhere.

In the case of Collections, the team at Sun didn't have this excuse. This class was built at the same time as the rest of the collections classes and by the same team. They had ample opportunity to put methods into the correct place.

If you're like me, then you might have a negative reaction when encountering Java™ code like this:

private int zero = 0;

You might think that naming a variable for it's value rather than it's purpose is a mistake. You might consider calling it initialCoffeeCount rather than zero.

You might also think that it should be made final so that you can't accidentally change the value. Obviously, something called zero must only contain the value 0, right?

What then, do you think when you find this farther down in the code?

zero = 1;

I was asked this week what debugger I use for Ruby code. The short answer is that I don't. I almost never use a debugger in any language.

I find that, for myself, relying on a debugger leads to sloppy thinking. When I start single stepping through code, I'm reacting to what individual lines are doing and I'm not thinking about the bigger picture. The debugger throws massive amounts of information at me and I'm forced to sift through it to find the tiny details I care about.

When I don't use a debugger, I'm forced to actually think about the code rather than just reacting to it. I'm forced to think about how it works and what could possibly be going wrong. A bit of thinking is usually enough to narrow the problem to a small handful of possible places in the code. A few strategically placed print statements then give me the few details that I actually need to identify and fix the problem.

Now I said above that I "almost never" use a debugger. Let's look at that. I found myself working on some code a while back that was extremely difficult to understand. The code was littered with Java™ Beans that contained objects of indeterminate types and it was impossible to understand what kinds of objects were being passed around just by looking at the code.

Good naming conventions or strategically placed comments would have worked wonders here, however, the original developers didn't seem to believe in either. On this particular project, I found myself using a debugger for days at a time just to be able to figure out what the code was doing.

Aside from this one project, I don't think I've used a debugger in any language in the last ten years.

There was a time before that, that I relied heavily on debuggers and felt that they were one of the best tools in my arsenal. It was devastating then when I had to spend a couple of years on a project where debuggers just weren't available. While working on this project, I was forced to develop other techniques for debugging that didn't involve an actual debugger and discovered that a bit of thinking was often better than single stepping through code.

By the time I had debuggers available to me again, I had developed a better level of critical thinking and realized that the debuggers were really not helping me as much as I'd thought. In fact, I believe that relying on them had led me down the path of sloppy thinking.

Today, a debugger is a tool of last resort. I would certainly use one if I felt it would be effective, however, it is usually not the best tool for the job.

Colorado Software Summit has added an Atom feed so you can easily keep up with what's new. I've written about this conference before and can't speak highly enough of it.

Here's a good introduction to Lisp, comparing it to other languages like Java™ and C++. If you like this then I'd also recommend my favorite article on Lisp, Casting Spels in Lisp