Jimmy Breck-McKye

A lazy programmer

pSX Emulator Mirror

It looks as though the original host of the excellent pSX PlayStation One emulator – psxemulator.gazaxian.com – has gone down. The site hadn’t been maintained in a while and I suspect the hosting plan may have ended. As such, I’ve added the most recent version of the emulator to this site. You can find it here.

Besides being easier to configure than ePSXe, pSX comes with a rather handy R3000a debugger that’s very handy in reversing work. I used it extensively in writing my Long range enemy attack mod for Final Fantasy VII.

A Simple Group Checkbox for Knockout.js

For the past few works, I’ve been working on and off with Knockout.js for the first time. So far I’ve been quite impressed; the learning curve is quite pleasant and the framework is fairly un-opinionated. One advantage of this is that you’ve got a great deal of flexibility and not much boilerplate in smaller projects. But one disadvantage is that with so many ways open to implement something, it can be hard as a newcomer to choose the best practice. Do I use a custom binding? A computed property? A ‘pure’ computed? Plain JavaScript?

One example of that recently was my need to implement a simple ‘group checkbox’. The Knockout documentation already provided an example of a ‘select / deselect all’ checkbox, but the behaviour I wanted was slightly different. I wanted a checkbox that would be unchecked when its children were disabled, checked when any were enabled and would select / deselect all if I toggled it.

Style Only Part of a Line Path With Raphael.js

If you have a vector line path in Raphael.js and would like to style part of it – highlighting a section of a line graph, for example – you can achieve this easily using the path.getSubPath() interface to get part of your path, then adding a new shape on top based on that pathstring.

Octopress Makes Blogging About Programming a Cinch

Are you a programmer? Do you want to blog about your ideas, but want it to be as simple as possible? Octopress might be the tool for you.

As a software engineer working on a particular problem or technology, you probably find yourself making observations about what does and doesn’t work. But what happens to these insights? Writing them down in blog format can help consolidate your ideas, and it allows you to show your engagement to future potential employers. I want to talk a little about the blogging solution that I use, Octopress, and why I think it’s a great choice for software engineers in particular.

Using jsPerf: A How-to Guide

If you’re interested in testing the performance of a particular piece of JavaScript, you might be interested in jsPerf.

jsPerf allows you to run and compare the speed of arbitrary snippets of JavaScript against a blob of HTML of your choice. This means you can test not just pure JavaScript, but DOM manipulation and jQuery calls too.

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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
/*
   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.