Mike Bowler

One of the big milestones in a ruby implementation is when it's able to first run a simple rails application. Until a couple of weeks ago, there were only two ruby implementations that were able to do this - the C reference implementation (Matz's ruby) and JRuby.

Today, there are four implementations that have hit this milestone. Rubinius and Iron Ruby have both just announced that they're able to run a simple rails app. This is an impressive milestone for both projects - congratulations to everyone working on those.

I listened to a truely amazing podcast this morning. Secrets of Mental Math has Arthur Benjamin demonstrating complicated "in his head" calculations in front of a live audience. He then talks about the techniques that he uses in order to do these calculations. Absolutely fascinating!

Arthur Benjamin is both a professor of mathematics and a magician. After wowing the audience with some amazing feats of calculation, he is happy to reveal his secrets. Seemingly impossible problems can often be broken down into more tractable steps and phonetic codes that can be held in memory and processed quickly. Benjamin explores these steps, giving examples of how he is able to multiply large numbers together, or pinpoint the day of the week of any birthday in any year.

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.

I've put the slides from last nights talk up on SlideShare. This is the first time I've used SlideShare so if you have any trouble accessing the slides, let me know.

I've posted photos from our trip to the Warplane Museum. The shot below is the only plane we actually saw flying although about half of the planes are flight-ready.

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.

This past weekend we took the Beavers to the Canadian Warplane Heritage Museum in Hamilton for their Nite-Ops program. This is a special program offered to Scouts, Girl Guides and Cadets only and is an overnight event where the kids do a variety of aviation related activities and then get to sleep out underneath the planes.

The "nite-ops" portion of the program is a late night tour of the planes by flashlight and this was a huge success with all the kids.

About half of the planes are fully functional and they do fly periodically. The plane we camped underneath was one of the functional ones. It was a "tracker" which had served on the HMCS Bonadventure aircraft carrier. I was quite impressed by the hook on the back of the plane that had been used to bring it to a quick stop when landing on the ship. The hook was a lot smaller than I would have expected for such a large plane. The kids were all amazed at the fact that the wings on the plane folded up for storage inside the ship.

The favorite plane for most of the kids was a big bomber. There was a story here about dropping a load of watermelons during a practice run and the thought of a plane dropping watermelons seemed to really grab the kids' attention.

My own favorite was a plane that would drop water on forest fires.

The museum really put on an outstanding event and all the kids had a fabulous time.

Joel Spolsky has an interesting rant about companies building products that nobody wants. I want to highlight one point in particular.

between Microsoft and Google the starting salary for a smart CS grad is inching dangerously close to six figures and these smart kids, the cream of our universities, are working on hopeless and useless architecture astronomy because these companies are like cancers, driven to grow at all cost, even though they can't think of a single useful thing to build for us, but they need another 3000-4000 comp sci grads next week.

Assuming that this is accurate, this is a bubble waiting to burst. Joel is describing a situation where programmers are being paid significant amounts of money to build products that will never generate enough revenue to pay for the investment. That's just bad business.