Jimmy Breck-McKye

A lazy programmer

Slideshow: Breaking the 1000ms ‘Time to Glass’ Mobile Barrier

I found a nice slideshow by Google’s Ilya Grigorik a few weeks ago, taking an overview of the essential issues in optimizing initial web page render time. The talk was mobile-oriented, but many of the same concerns apply to desktop sites. You can find the slides on Ilya Grigorik’s blog

Some key points:

  • 4G is not a ‘magic bullet’ for mobile performance problems. Our customers are going to be stuck with 3G for quite some time, and TCP-slow-start imposes harsh bottlenecks.
  • Waking up the radio on mobile devices is slow. Radio is typically turned off after idling for 100ms; subsequent requests suffer a significant warm-up penalty, even on 3G (where it can be up to 2.5 seconds)
  • Rendering is blocked as the browser constructs the DOM and CSSOM. Inlining ATF (above-the-fold) styles and bootstrapping further styles asynchronously may be a useful strategy
  • Inlining styles for above-the-fold content might be a wise strategy

Protected Members in JavaScript

If you’ve done much OOP in JavaScript, you can probably already simulate private member variables, by putting variables in a constructor’s closure (if not, go read this summary by Douglas Crockford). But you may not know that you can also emulate the protected status of C++ and Java — variables shared between parent and child classes, yet not exposed as public. This is occasionally useful, but is a little obscure to implement in JS if you don’t know how.

The basic idea is use the ‘parasitic constructor’ pattern — where a child constructor directly calls the parent constructor — and passing in an object defined in the context of the child constructor. The parent constructor decorates this object, and because JavaScript object arguments are effectively passed by reference, the members of this object are visible within the child constructor. As such, your child and parent constructors have a ‘shared secret’ object that effectively acts as a map of all the protected members.

JavaScript Function Variables Don’t Have to Be Anonymous

If you’ve used JavaScript much, you’ll probably know one of its very convenient features — the ability to assign functions to variables, send them as arguments, and return them as values. This lets you write code like this, where functions themselves return other functions:

Anonymous function bonanza
   This code creates a basic 'curry' function 
   (see my earlier post for an explanation)
   It relies heavily on function variables.

var add = function(x, y) { // <- A function variable
    return x + y;

var curryUtil = {
    curry : function(functionToCurry, x) { // <- A function object property
        return function(y) {               // <- A function return value
            return functionToCurry(x,y);

var add7 = curryUtil.curry(add, 7);
add7(3); // returns 10

var double = curryUtil.curry(function(x,y){ // <- A function literal argument
   return x * y;
}, 2);
double(8); // returns 16

The problem with this, however, is that all the functions in the above example are anonymous — they aren’t named. Beyond making your code more obscure than it needs to be, this also makes debugging them a problem

Why I Like Parasitic Inheritance

When you’re starting out with JavaScript, it doesn’t take long for the question of object oriented programming to raise its head. As soon as you want to build anything non-trivial you’re going to want some means of structuring your solution and imposing some kind of abstraction on your code. Most tutorials these days emphasise use of the prototype chain – either through function.prototype or the ECMAScript 4 Object.create() interface. I, however, am still fond of the more basic parasitic inheritance approach – where inheritance is basically a special case of composition – and I wanted to outline my reasons why.

JavaScript Curry

If you’ve had much exposure to functional programming, you might have heard of ‘currying’. This funny term refers to a kind of functional composition: taking a function that takes two (or more) parameters, and turning it into a function that takes less parameters, and automatically applies the other arguments, which have been ‘baked’ into it.

For example, let’s say we have an ‘add’ function – function add(x,y) { return x + y }. I might have an instance where I want to add various numbers to a constant – say, 7. Rather than constantly calling add(7, x), currying lets me create an ‘add7’ function. Whatever I pass, add7 always adds seven to it.

Document Loading and DOM Lifecycle Events

Document loading and load events can be a bit confusing for newcomers. Multiple names for the same basic things, incompletely documented, ambiguously explained and those ever-present browser inconsistencies don’t exactly help. I want to try and remedy this by providing a rundown of document loading lifecycle events.

Disabling Firefox Safe Mode

A couple of weeks ago I faced a problem where Firefox’s “Enter Safe Mode” dialog was causing problems for a Selenium test suite I was trying to run.

Basically, Firefox would sometimes throw the dialog and my test framework (naturally) wouldn’t be able to dismiss it without my help. This meant the Firefox instance stayed open, so if I tried running the suite again, I’d get an exception:

org.openqa.selenium.WebDriverException: Unable to bind to locking port 7054 within 45000 ms

Annoying. To me, it seemed the simplest solution was to merely disable Safe Mode entirely, as I would never need it during a test. Rummaging around in Stack Overflow and the Mozilla bugtracker, I found this ticket that proposed I could either:

  • set an environment variable, MOZ_DISABLE_SAFE_MODE, or
  • pass a config setting, maxResumedCrashes = -1 to about:flags or a user profile

According to the webdriver documentation, you can set a custom user profile flag fairly easily with profile.setPreferences("key","value")

Disabling Safe Mode was simple:

profile.setPreferences("toolkit.startup.max_resumed_crashes", "-1");

If you’ve got the same problem, you might want to give it a try.

Introducing Web Accessibility

A couple of weeks ago I gave a presentation, “Introducing web accessibility”, and I thought it might be worth sharing with the wider world. It provides a broad overview for developers who’ve never encountered accessibility before.

Some key points covered:

  • Visually impaired users use ‘normal’ browsers with CSS and JavaScript usually enabled. Don’t rely on your non-JS/CSS fallbacks for accessibility.
  • Assistive technology sits on top of browsers; it doesn’t replace them. So you cannot track / UA sniff users who need concessions.
  • How semantics encoded in your document actually reach the screen reader, and the points of failure in this journey
  • How screen reader users typically traverse a document
  • Common problems and their solutions
  • How to actually validate accessibility, and the importance of testing

You can get a hold of it here.

Styling Form Elements

Form elements are notoriously difficult to style. Even apparently simple tasks like horizontally aligning different types of input can prove a headache for experienced developers. Only by understanding how form elements are laid out can we master them.

Hello, Octopress!

So I’ve ditched the old blog and started anew.

There were a few reasons for this: firstly, I wasn’t terribly happy with my ‘new’ WordPress theme. It wasn’t totally terrible, but it still had rough edges design-wise, still wasn’t great for posting code, and still needed a lot more work to make it play nicely on mobile. These were all things I could fix, but why should I? I want to spend my time writing about stuff, not fixing my blog engine. That is why I’m blogging, after all.

Secondly, I didn’t really like working with WordPress that much. I can see how super-convenient it would be for a traditional blog, but my needs were quite different, and I felt myself having to work against WP’s architecture rather than with it. Maybe I could have spent more time reading up on PHP and WordPress development in particular, but they just aren’t technologies that I’m really prioritizing learning about right now. Never say never, though.

Thirdly, and most importantly, I really like Octopress. The simplicity of a static site; the quality of the default templates; the breeziness of markdown, liquid and Yaml; and the natural integration of programmer-specific features (the Solarized code highlighting); it all sold it for me. Plus, if I ever do want to tinker with my blog engine, I’d probably rather learn Ruby than PHP.

Of course, now I’ve sorted out the blog, I don’t have any excuses for not posting. So I’d better get cracking, hadn’t I?