I've been using Eclipse Ganymede for a couple of days now and here are a couple of first impressions.

• Overall, everything is faster. There's a snappiness to the UI compared to the last release.
• There's a subversion client (subversive) bundled with the package which would be good news except that I couldn't get it to work. Apparently, it's deliberately broken since they're not allowed to ship some needed component so you need to download some extra piece. I tried for a bit and while I think I downloaded the right part, I never did get it working. Finally, I removed subversive and went back to subclipse and it's working fine for me.
• The dynamic language support is now built-in although ruby support is still an extra step in the installation.
• Syntax highlighting in ruby has taken a step backwards - it gets really confused by quotes in places other than strings (in regular expressions for example) and then makes a mess of the syntax highlighting after that. I've been able to work around this by putting comments with end quotes in them but this is clearly not ideal. I hope they get this one fixed soon.

The slides for the talk I did last night at the Rails Project Night are on SlideShare at http://www.slideshare.net/mbowler/inside-enumerable

East Side Marios has done a great job of branding in the past. People know exactly what to expect when they eat there and the atmosphere at the restaurants is very consistent with their advertising.

So we were very surprised, and disappointed, to discover that they're changing the "feel" of the restaurant. In the past, they put on a big show for birthdays. All the staff come over to your table and sing and the person celebrating the birthday gets to spin the big wheel and get prizes ranging from free deserts to "Surprise - let's hope it isn't a pie in the face". I got the latter once and while the kids were disappointed, I was glad it was a coffee mug rather than a "pie in the face".

Yesterday was my son's birthday and Saturday had been my nieces birthday so we took them both out for dinner at East Side Marios. We took them there specifically because East Sides has always made a big production about birthdays (and we like the food). So we ordered our food and waited for the staff to come over to sing and for them to bring the wheel for spinning. By the time desert arrived, it was obvious that neither one of these was going to happen so we asked our waitress and she explained that they had discontinued both of those. She said that the restaurant was trying to be more upscale now.

If you haven't been to an East Side Marios', you may not appreciate how inconsistent this is with their branding. The walls are covered with empty tomato cans and jars of food stuffs and crazy sayings. This has always been a "fun" place to eat, not an "upscale" place. The place is loud, the decor is tacky and it's always a good time.

Thinking that perhaps our waitress was new and just didn't understand the whole East Side process, we asked to speak to the manager. The manager then proceeded to tell us that there had been complaints and so they were changing their process. Now this is a franchise and franchises are required to follow the formula provided by head office so I have to assume that this is a change across the entire company.

We hadn't come to East Sides for an "upscale" dinner. We'd come for a fun birthday dinner for two kids and they didn't get it. If we'd known in advance about these changes, we would have eaten somewhere else.

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.

I'll be speaking at the Toronto Java Users Group next Tuesday on "An Introduction to Ruby for Java Programmers"

One of the advantages of learning a new language is being exposed to new idioms and new approaches to solving old problems. In this talk, we will introduce the Ruby language with particular focus on the idioms and concepts that are different from what is found in Java.

We will introduce concepts such as closures, continuations and meta programming. We will also examine powerful techniques that are practically impossible in Java due to its compile time binding of types.

No experience with Ruby is assumed although an understanding of Java would be helpful.

This talk is based on one I gave at Colorado Software Summit a couple of years ago although it's been updated and expanded.

Facebook: http://www.facebook.com/event.php?eid=9900617139
Toronto JUG: http://www.torontojug.org

One of the arguments that I've heard many times against using open source is that if things don't work properly, there's nobody to sue. Now I've always thought that this was a silly argument since companies hardly ever do sue their vendors but they've wanted the ability to do so.

So I thought this article at CIO magazine was interesting. Here's they're suggesting that you shouldn't sue even if you feel that the vendor deserves it. That sort of blows the whole "we need someone to sue" argument out of the water.

In recent conversations with IT executives I asked them if they had ever sued a software vendor and whether, in retrospect, it was a good thing to do.

Most had known about or participated, in some capacity, in the litigation process against some well-known and some not-so-well-known vendors. And what nearly all of them had decided was that suing your software vendor just wasn't a smart thing to do.

Here's an interesting video on the steps a letter passes through once it's dropped in the US Postal Service. The first 30 seconds or so are specific to Send Out Cards (which I resell) but then it's all about the Postal Service.