Mike Perham

Damon Clinkscales, of Austin on Rails fame, has created a one-day workshop to take your Rails skills from 0-60 in 8 hours. While this might be abysmally slow for a car, it’s a rocket sled for software engineering! I’ll be there, teaching about ActiveRecord and how to bend the database to your will. If you or someone you know is looking to kickstart their Rails skills, check it out. Seating is extremely limited (10 seats total!) so get it while it’s hot.

Rails Bootup, Austin TX, August 2nd

One interesting tidbit I’ve learned by building tracknowledge, my race track database and instrumenting it with FiveRuns’s Manage service is the ridiculous amount of time required for calling third-party services. If you look at a sample track page, Donington Park, there’s three services being called: Youtube and Flickr are called server-side and Google Maps is called client-side. According to Manage, 97% of the render time for the track page is spent in calling Flickr and Youtube.

The way I’ve worked around this in the current incarnation is by using the page caching built into Rails. The first hit to each track is always generated but every hit thereafter is a static HTML page delivered by Apache. More dynamic sites might not be able to cache that aggressively; action or fragment caching could be used to cache just the HTML snippets required for each service’s block of content.

There’s a lesson here: third party services should be mashed up on the client-side if possible for good performance and user experience. This allows the browser to render the page and asynchronously fill in blank areas as the service responses come back. This goes to show: if you are going to call a 3rd party service, you need to think about contingencies. What happens to your app when the service is down? What happens when the service is sloooow? Caching and asynchronicity are just two mechanisms for dealing with these conditions.

I didn’t write TuneUp (Brian, Bruce and Matt McCray did) but it’s a great tool and it’s nice to see compliments like this in the blogosphere. Thanks Mr. metajack!

Finally! A Modern Development Tool « metajack

With all due respect to Pres. Kennedy, I stole his memorable phrase because I’m going to Berlin! RailsConf Europe 2008 accepted my talk “How NOT to Build a Service”. I’m very excited to be traveling to Europe; it’s been three years since I was in Amsterdam and I can’t wait to visit the area again. In summary, here’s my speaking schedule for the next three months:

• OSCON - Portland, OR July 25-29
• RailsConf Europe - Berlin, Germany Sep 2-4
• LoneStar Ruby Conf - Austin, TX Sep 4-6

I’ll be talking on the last day of LSRC to give myself time to travel back to the US.

Just when you think you are doing well, someone comes along and points out how dumb you are. I was discussing my need to patch ActiveRecord with Bruce today and mentioned how I would patch the Ruby files in the activerecord-2.0.2 gem on staging, test everything and then patch the same files on production.

Bruce didn’t even pause before asking, “Why don’t you just monkey patch the code?”.

Oops, caught red-handed, thinking like a Java programmer. It’s so easy to fall back on old habits and forget the need to question how you are doing things. You can question your need to question eveything but then it’s just turtles all the way down.

Question everything: just one of the topics coming in my talk “How NOT to Build a Service”.

Looks like my talk “How NOT to Build a Service” has been accepted by the LSRC organizers. I really enjoyed the conference last year and it’s an honor to be chosen as one of the speakers this year.

The great thing about the LSRC is proximity: it’s two miles from my house. If anyone needs a sofa to crash on - let me know!

With the rise of Flash-based video, screencasts are arguably one of the best things to happen to the Internets in the last 3 years. As they say, a picture really is worth 1000 words and having an expert show you how to do something is far better than describing the same thing in text. Here’s an overview of some of the new features coming in Firefox 3. I promise you’ll learn something new.

An Overview of Firefox 3

MVC Song by Laura Balch

The FiveRuns crew have been humming this ditty under our collective breath for the last two days. Kudos to Laura for an addictive little tune!

We moved part of our FiveRuns Manage infrastructure to use Starling this week. I’m rapidly becoming a convert as it has proven to be simple, fast and reliable. The Starling 0.9.3 release is somewhat long in the tooth but GitHub has several Starling forks which contain performance improvements and bugfixes, including our own fiveruns/starling fork. Our fork has proven to be about 3 times faster than 0.9.3 in raw message processing speed.

More elusive has been the client library to use with Starling. Because Starling just uses the memcached protocol, any memcached client should be able to use Starling. The problem is that the most popular memcached client, Seattle.rb’s memcache-client library, has several bugs in the latest 1.5.0 version:

1. set() fails when the socket has been disconnected (via Twitter)
2. it does not retry if a socket operation fails (via Will Bryant)
3. it does not retry the current operation on another server if a server dies

The first two I fixed by applying the patches at the links above. The last one I found and fixed myself - it’s critical for fault tolerance. We run two Starling servers for redundancy and if one goes down, we wanted the clients to transparently fail over to the other. All three bugs have been fixed in our fiveruns/memcache-client project. If you use our client, please let me know. I’d love to hear success stories!

I submitted my first Rails patch this weekend. We’ve been seeing occasional lock contention, timeout and deadlock in our mysql database but without SHOW INNODB STATUS at the time of the error, it’s difficult to track down the cause of the contention. So I added lock error logging to ActiveRecord’s MysqlAdapter class. It was also good to learn the patch submission process as I’m sure this will be just one of many.

http://rails.lighthouseapp.com/projects/8994/tickets/250-mysql-deadlock-debugging