I’ve got just the thing. Shorten them up!

While debugging an exception in a controller, after each page load I would get a 60 line backtrace, forcing me to scroll my console all the way up to see the relevant parts. I hate scrolling. I needed prettier & more relevant debug output.

It turns out you can customize how you want errors to be logged from inside your controllers — see rescue.rb in your rails distribution for more info. If you smack this sucker on your application.rb base-controller, your stack traces will be only 5 lines long.

  #
  # Custom logging of errors
  # What we're doing here is trimming down the backtrace of the inner exception
  # of TemplateErrors, because their backtrace is as long as a Tolstoy novel
  #
  # See rescue.rb in Rails for more information on how errors are handled/logged
  #
  def log_error(exception)
    if (exception.class == ActionView::TemplateError)
      e = exception.original_exception

      # trim down the stacktrace before we log it
      e.set_backtrace(e.backtrace[0..5])
    end
    # call original log_error defined in rescue.rb
    super
  end

Conceptually it’s not very elegant, but it’s simple enough. Good additions might be to not change the stacktrace if RAILS_ENV == 'production', and to make the number of stack trace lines configurable via a parameter (so you could define in environment.rb).

Mr. Picasso Head is a fun webapp.

Masterpiece:

I’m calling it “The elusive Joe User.”

IE6 leaks oceans of memory. Great — why should web developers care? Because if you care about your users, you should care about this browser. It is dang ubiqutious. Even a somewhat “tech-savvy” dictionary site of mine has 25% of its users coming in as IE6. Definitely worth caring about.

IE’s problem seems to stem from having two garbage collectors running — one for objects declared with Javascript, and one for the DOM tree (each DOM element is its own COM object). Circular references and closures can really throw IE off. If you’re interested, MS has one of the best articles about fixing its own browser’s memory leaks. There’s even a great tool (“Drip IE Leak detector”) for seeing which DOM elements were leaked by IE6.

Anyway, I spent the entire day today fixing IE6’s memory leaks for one of my projects. This small bug cost me hours and hours, and I haven’t seen it documented anywhere:

When attaching events to a DOM object in IE, you do this:

domElement.attachEvent(eventName,function);

where eventName is something like “onClick”.

When you pass in a non-standard eventName, like “onTest” instead of “onClick”, IE will not garbage collect that domElement. Some Javascript toolkits (like Mootools) allow you to use your own custom events, e.g. drag-and-drop implementations (”onDrag”, “onComplete”). If they eventually pass that event name to attachEvent, there will be a memory leak in IE6.

Working around this bug, I went from 1MB of leaked memory per page load (wow) to <100K. Not bad. Filed as a bug here against Mootools.

I’m looking into implementing offline support for one of my webapps and came across this beast of engineering:

Joyent Slingshot

Joyent Slingshot allows developers to deploy Rails applications that work the same online and offline (with synchronization) and with drag into and out of the application just like a standard desktop application.

Works on Mac and windows, and the framework itself will be released under the GPL next month.

From its description it sounds amazing. The first thing I asked is “how are they doing this?” Reading a bit further though, I found that the actual user experience turns out to be clunky. You need to somehow get the Joyent client (when do you ask your user to download it?) and then, when offline, they’ll need to launch the Slingshot application from their desktop separately (which is a stripped-down web browser shell). Then they can use your app.

This kind of user experience might be acceptable for a corporate intranet, but not for the population at large. Kudos to Joyent however for making the development experience so seamless for Rails developers. It looks like you can get rich drag and drop integration into your Rails app very easily, albeit with the caveats mentioned above.

Other solutions for offline storage and access are Adobe’s upcoming Apollo framework (Scrybe uses it), and Microsoft’s recently released Silverlight (a friend of mine is a developer for it).

I’ll post my findings when I decide on the best approach.