One thing that never stops amazing me is the eagern€US companies to use cheques as a pa€ethod. I mean, we have been using online banks for more than a decade now, and still the default way of paying a contractor is sending him a cheque.

Sure, the buyer wins some time (and thus a few days’ worth of interest€or the receiver of the payment it goes like this:

1. Wait for the cheque to arrive in mail. This normally takes about a week.
2. Walk to a bank and get stared at like a lunatic, because you’re considered a remnant from the era of ball chairs. Stand in line for half an hour because banks have cut their counter workers to a minimum (since no one – except for pensioners – goes to a bank persionally these days, and pensioners have time to wait).
3. Wait another week for the cheque to be cashed and the money to arrive on your account.

Now let’s compare this to the process of a bank wire:

1. … there is no step 1. You just wait and after about a week since the customer sends the money it’s on your account.

Now as if this wasn’t enough, here’s what just happened with a cheque I received a couple of months ago. When I got the cheque, the dollar rate was near it’s all-time low (around $1.35/€1), so I decided I’d wait for a while for it to stabilize. That turned out to be just a pipe dream so I bit the bullet and walked into a bank this week. No problem.

Today I got a call from the bank. They told me they have a 70-day limit in cashing cheques in the normal fashion (which costs me about €12). Since they don’t want to take the risk of being denied by the US bank that issued the cheque, the only way to cash it now is as a CAD (cash against documents) cheque, which, coincidentally, is going to cost me around €50. Just great.

For a reality check, I decided to call another bank and ask how it would work there. The person with whom I talked obviously wasn’t prepared to answer such a hard question as “How much does cashing a cheque cost?”, so I had to wait on hold for a while until she came back with the answer. And what an answer that was:

“The bank has the option to deny cashing the cheque as its will, and the cost is always at least €90.” Geez. I called back to the original bank and told them to go ahead with the cashing. It seems the banks in Finland have at least as bad an aversion to cheques as I do.

From no on, please don’t offer to pay me by a chequ

I’ve recently been looking into Starfish to provide more speed for our upcoming email alert functionality. While reading Lucas’ blog I noticed that he’s back blogging about their experiences at MOG. This time he’s writing a series about Rails deployment which seems really interesting. Three parts so far, more to come:

• Advanced Concepts in Ruby on Rails Hosting Part I
• Advanced Concepts in Ruby on Rails Hosting Part II
• Advanced Concepts in Ruby on Rails Hosting Part III

Here’s the PDF export of my RailsConf slides. Unfortunately they probably don’t make much sense just by themselves. I’ll try to post the transcript of the talk as well, as soon as I get back on the normal track of life after three weeks of travelling.

Angel on the Shoulder (PDF, 4,5MB)

‘tis the time of the year again. The week when you can hardly concentrate on your work, school or household. In a few hours we’ll jump in a ship towards Sweden and then drive to Eskilstuna and Gröndal speedway stadium which hosts this year’s Tiomila.

It’s hard to describe to a non-orienteer the feelings one has before an event like Tiomila (and even more, Jukola). It’s for many the event where the countless hours and kilometers spent running and xc skiing through the woods materialize, where the whole orienteering world gathers in one place to see which club has most successfully trained through the winter, avoided injuries and illnesses, and generally prepared for the major races of the year.

Let me in this entry stay in Tiomila. Late April, possibly sun, probably rain and cold. Lots of mud, sometimes even a hint of snow. Ten men in a team, all with a common goal of surviving through the night and the 111 km (of which more than 60 in darkness) as fast as possible, in the best case faster than anyone else.

Tiomila, and especially its 4th “LÃ¥nga natten” (“Long night”) leg, spanning 16,5 km, is full of legends. Once in mid-90’s, Sören Nymalm, my former clubmate and one of the greatest night orienteers of all time, was heading a pack of a dozen runners on LÃ¥nga natten. Sören had had pizza the day before which obviously wasn’t any good for his stomach. In the middle of the leg, Sören had to jump off a dirt road to relieve his abdominal pains.

What a great chance to escape for the rest of the pack! But what happened? The whole group waited for Sören, and someone even spared him some toilet paper. After (and despite) the accident, Nymalm continued to lead the group and ran one of the fastest times on the leg. It paid off to stand by him.

Another legend from about two decades ago is that the leading pack of runners on LÃ¥nga natten followed the wrong path and öup on the opposite side of a lake to their next control. According to some, part of the pack then tried to steal a rowing boat to cross the laöö others humbly turned around and ran back around the bay. The truthfulness of the latter part of this stoös över at least a bit questionable. The point is, however, that an event like Tiomila is a fertile ground for legends like these.

The modern technology has brought its own twists to the relay. With the help of live GPS tracking and öting, you can now follow through the night (or afternoon if you happen to live in US) and sense at least part of the atmosphere without leaving your beloved Aeron.

If none of my babblings got you excited, here’s a brief YouTube video from last year’s TV/webcast.

If you’re spending Saturday night in front of a screen, go ahead and dedicate your secondary screen for the webcast. The men’s mass start at 9PM GMT (launched by an AA cannon) is one of the most spectacular things you can experience in sports.

But now, it’s time for my last finishing up training and then some packing before our car heads to the harbor.

All the cool kids are heading to RailsConf in less than a month from now. Dr. Nic Williams, the man who’s obviously found a way to stretch the concept of time as we know it, has now whipped up MyConfPlan, a free service you can use to plan your conferences and share the plans with others.

Check the site up! My very preliminary and incomplete plan for RailsConf is open for review.

Yesterday’s San Francisco Chronicle ran with an article called Responsibility is in their sites, featuring dotherightthing.com and including an interview with our co-founder Ryan Mickle. Cool stuff.

There are few authors whose writings literally change your life. For me, Kathy Sierra has been one of them. She’s been the leading teacher in how we can cross the chasm between software and emotions, vendors and clients, hackers and users, male and female hackers, the list goes on. I’ve seen Kathy talk in person and it’s hard to imagine a nicer personality.

It was thus with great shock and sadness when I read about the death threats that Kathy has been getting. It made me sick. It made me cry.

The comments made about growing a thick skin and getting used to this turned my stomach even worse. This is not about trolling, this is about threatening to kill and sexually harass someone. There is just no excuse in the world for that.

I hope we can now show the power of the community to fight the abusers and show there’s no place for such behaviour in the blogosphere.

I recently updated my RubyGems to 0.9.2. In that upgrade, require_gem was deprecated in favor of gem and running Rails would generate a bunch of deprecation warnings. However, it was easy enough to fix by running rake rails:update in the app root.

Doing the update caused us some problems, though, because we are using the cached_model gem to store objects in memcached. cached_model was required in environment.rb before the Rails::Initializer.run block but with the new autoloading mechanism, it didn’t work anymore because the Rails classes weren’t at the disposal of cached_model before the initializer block. Instead I got all these weird errors:

$ script/console 
Loading development environment.
/opt/local/lib/ruby/gems/1.8/gems/cached_model-1.3.1/lib/cached_model.rb:21:NameError: uninitialized constant ActiveRecord
/opt/local/lib/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/assertions/selector_assertions.rb:525:NoMethodError: undefined method `camelize' for "top":String
./script/../config/../config/../app/controllers/application.rb:1:NameError: uninitialized constant ActionController::Base

Lo and behold, the cached_model docs instruct to put the require line after the initializer block. This is the right way and should be ok in most cases. However, in our app, we also have an observer for the User class, which is a subclass of CachedModel. Observers are loaded inside the initializer block (config.active_record.observers = :user_observer) and when loaded, they also initialize the actual ActiveRecord model they’re observing (in this case User). But since User subclasses CachedModel, which is not loaded yet, we have a chicken and egg problem:

$ rake test:units
rake aborted!
uninitialized constant CachedModel

We can’t require cached_model before the initializer because ActiveRecord::Base doesn’t exist then, and we can’t require it after the initializer because it would need to be initialized when the observers are loaded. What’s a man to do?

Rick Olson pointed me to a list of articles (1, 2, 3) that he recently wrote about the Rails initializing mechanism (+ a link to another useful article by Tim Lucas). This lead to a trick that solved my problem. Namely, writing a plugin.

The gist of the trick is that the loading of observers is deferred until all plugins are loaded. So I created an empty plugin called cached_model_plugin, put the require 'cached_model' line in its init.rb, and everything started working again. Woo-hoo!

The weird thing about this is that actually, the code in environment.rb after the Rails::Initializer.run block should also be run before the observers are loaded. However, for whatever reason that didn’t happen in our case, so I’m happy that using a dummy plugin helped.

With the new config/initializers in Rails Edge this hack should become history, but until we update beyond 1.2.X, we’ll be camping happily with my plugin.

Since blogging is now considered unfashionable, I followed the pack and started my own tumblelog, Forest for the Trees. OK, the main reason was probably how goddamn easy the peeps at tumblr.com have made everything. Kudos to them!

If you’d rather read more sports-oriented tumbling (and don’t have problems with the Nordic languages), head on over to the Moulin Rouge brought to you by the mighty Red Machine.

[UPDATE] I’m now using the new Plaxo 3 to sync between iCal and Google Calendar. Working fine so far.

As I’ve recently found it extremely hard to share my schedule with our team and other people who need to know where I’m spending my time, I figured out it would be easiest to just share my calendar with them. As it stands, Google Calendar is by far stretch the best solution for this. Everyone (I mean, everyone) has an account and sharing a calendar in GCal is a breeze. However, I don’t want to use Google Calendar myself, I prefer iCal. I can sync it with my mobile phone and use wherever I am, regardless of whether I’m online.

Given these needs, a couple of weeks ago I started looking for a syncing solution between iCal and Google Calendar, and stumbled upon Spanning Sync. It seemed like a perfect solution — very unobtrusive, doing its magic on the background and only interfering with my workflow if there ever was a conflict. The software was in beta stage but worked still very well.

Last week, I discovered the first problem with Spanning Sync. It would (seemingly) randomly crash saying that the sync failed. I habitually dismissed the error messages a few times until I noticed that the crash was actually not a real crash at all. The problem was that the beta version had expired and I had to download a new version. And that was told me with a crash report. No automatic download of the new version. No button to download it. A crash report.

Well, this was still beta software, so I just commented on it in the Spanning blog and moved on. Now in Chicago, the same thing happened again. Again, a few dismissals before it crossed my mind that I was meant to download a new version. This time, it seemed, they had reached 1 point oh. Great! The homepage had a link to download a 14-day free trial version, which indicated that the actual software would cost something. OK, that’s fine, I’ll happily shell out 5 or even 15 bucks for such a nifty app and to support indie developers. However, there were no link to actually buy the application, so I headed back to the blog.

The blog post announcing the 1.0 version revealed the ugly truth. Spanning Sync costs $25 a year or $65 as a one-time payment. My first thought? What. The. Fuck? Almost double the price of TextMate, which is pretty much my most important tool that I use for hours every day. The 93 comments on the blog post reveal that I’m not alone with the sentiment. A quick scan didn’t reveal a single comment that defended the pricing (except the ones from Spanning Software).

Too bad a promising software is bitten by such notoriously bad pricing. A simple sync app just isn’t in the ballpark of $65. It’s not about how many people would be able to pay it, it’s about how many think the app is worth it. I highly doubt very many will. This comment by DV pretty much sums it up:

Also…
$65 X 18000 = $1.17 Million …. nice dream
$65 X 180 = $11,700 …. reality
$20 X 200,000 = $4 million …. sweet spot