Exploring Chrome’s timeline panel

Subsequent to some performance issues with a few Backbone apps, I spent some time digging further into Google Chrome’s timeline panel, and specifically the memory view that shows allocated memory, and breaks down the number of DOM nodes held in memory.

Some tests/demos along with provisional findings are provided here: chrome timeline exploration. The official documentation for Chrome’s dev tools is getting better, but could still use improvement. Hopefully this will go some way to providing a bit more insight into what’s going on, what different numbers mean, and what sort of behaviour you can expect from common scenarios.

As I’m nowhere near an expert of Chrome’s internals nor on memory profiling in general, any suggestions or corrections are more than welcome (pull requests or whatever).

Avoiding 503s when loading images from Google Contacts API

There’s a variety of mildly annoying things about V3 of Google’s Contacts API (lack of control over which fields are returned, basically non-existent sorting ability, use of oauth bearer tokens; also they seem to be confused about their supposed mitigation of the confused deputy problem: validation does not actually seem to be required, nor does this in any way prevent an attacker from stealing the token and doing whatever they like with it).

One of the most annoying “features” is the undocumented rate limit when requesting images for a user’s contacts, each request of which must be authenticated. The rate limit appears to be around 10/s.

I wrote a lightweight jQuery plugin that will help you avoid the 503 errors that Google’s API returns when you begin exceeding this limit.

jQuery batched image loader

The github page has basic implementation details.

Scrolling while paused in Chrome debugger

If you’ve spent much time with Chrome’s debugger, you’ve probably encountered a few annoying scenarios, in which the locked-up view of the web page you’re working on prevents you from inspecting elements or scrolling.

An easy workaround for the scrolling lock-up is to just jump to the console, and:

window.scrollTo(0, 800)

Backbone.js finite state machine view

I developed a basic Backbone.js finite state machine (FSM) view for use on a project I was working on a while ago, and have been meaning to clean up the code and share it for a while now. It is now available on github, along with some qunit and sinon tests.

It was written to handle complex form navigation, i.e. when you want to conditionally guide a user through a path of form fields depending on their previous answers, and so while it could perhaps be shoehorned into other uses, this is where it will be the most natural fit. It works basically by binding a method to the change event on form fields that translates this event into terms understood by the FSM, and then calls transitions that you’ve defined when initializing the view.

There is some basic js and HTML on the github page demonstrating use. I plan to have more/better code, along with a working example, at some point.

backbone-fsm-view

Since writing this a few other people have come up with implementations that, though they appear quite different from mine, would accomplish mostly the same thing. See backbone.statemachine, and machina.js. Also, I definitely got inspiration for this code from a few other places on the web while writing it, but can’t track them down now. If anyone reading this thinks it reminds them of something they’ve seen elsewhere, or if they have suggestions on how it could be improved, feel free to let me know. I’m always open to suggestions and/or pull requests.

Closure compiler externs files for underscore and backbone js

As part of some other things I’m working on I’ve begun building upon some existing closure compiler externs files for the Underscore and Backbone js libraries. Both are still in quite early stages, but if you need something like this, they’re currently better than nothing.

backbone-js-externs on github, for Backbone 0.9.2

underscore-js-externs on github, for Underscore 1.3.3

The Backbone externs file is taken from this gist, which was autogenerated by DotNetWise’s externs extractor. It does a decent but very basic job.

The Underscore externs file is taken from the official Closure Compiler repository. The only changes I’ve made so far are

  • fixing a type annotation for the _.uniq and _.unique functions that had a required parameter after a non-required one (Closure Compiler dislikes this)
  • using same type annotation for _.uniq and _.unique, since the latter is an alias for the former
  • beginning to add type annotations for functional-style usage of underscore, vs. object notation (e.g. _(collection).map(function(){}) vs. _.map(collection, function() {}). The existing externs file has only the latter.

I’ll probably also be adding externs for use with the SVG library Raphael at some point.

Cisco IPsec VPN on OSX Snow Leopard

For anyone else having issues setting up a VPN connection on Snow Leopard: if you are getting an “incorrect shared secret” error, quit wasting your time, and download Shimo, a VPN client for OSX. Haven’t paid for it yet, but will likely end up doing so, since it’s the only one of a half-dozen or so that I tried that not only worked, but wasn’t horribly designed.

I suspect my issue may have been related to a the VPN shared secret being too long, though that is mostly speculation. There was mention in a forum somewhere that OSX Lion silently truncates shared secret keys longer than 63 characters. Yay.

Errors in scripts loaded with jQuery $.getScript

Spent some time the other day trying to figure out why I wasn’t seeing JavaScript errors in certain files where I expected to, which was problematic both for development and also for the monitoring of client-side errors we’re doing in the application (assigning a handler to window.onerror that makes an ajax call with error information to an endpoint for this purpose).

Basically, if there are errors in any of the scripts you are loading with $.getScript, or the full $.ajax call for which $.getScript is shorthand, these will be caught by jQuery and will fail to show up in the console or be passed to any window.onerror handler you’ve defined. jQuery provides a global ajaxHandler you can attach to, for example, document, which you can then use to do whatever client-side error handling/logging you want to do.

The downside of this approach is (as far as I can tell) that you don’t get quite as much error information (specifically, the line number of the error) from jQuery as you do from other ways of loading scripts with js, because the error gets caught during a call to eval (or more specifically, jQuery’s globalEval method).