I thought it might be nice to take a break from my regularly scheduled programming and share with you a great insight I’ve had recently about fried rice. Here in America, fried rice usually brings to mind Panda Express and a steam pan of dried-out white rice turned brown by the addition of soy sauce. In my younger days I would always opt for it because I thought white rice was boring, but it’s never been that appetizing.¹

Oddly, in the five months I spent in China, I never came across fried rice, so my conception of it never evolved beyond the Panda Express version. Then a few weeks ago at a restaurant² in the San Gabriel Valley, I was served this bowl of fried rice:

It was a revelation! No soy sauce whatsoever. It was moist and ten times as delicious as the slop I’d been eating at Panda. The secret, as it turned out, was that the rice was dotted with tiny cubes of salted pork. That mixed with sliced scallions and tossed with oil in a wok for a couple minutes was a big draw for this restaurant, eulogized on Yelp and ordered at every table.

Shortly thereafter I accidentally bought some 塩鮭 at a Japanese supermarket. That is, salted salmon. (It’s not my fault; in English it was only labeled “Salmon”. It’s usually latinized as some variation on shioyake, shiojake, or shiozake.) At any rate, it’s intensely salty. Unable to eat it as I had originally intended, I realized that it would be the perfect ingredient for a fried rice dish inspired by my earlier experience. Hence the following recipe was born:

If you find yourself stuck writing a complicated Flash Banner, you will run into a minor inconvenience: most of the ad networks package their api up into .mxp components. You load them into Flash via the Adobe Extension Manager.

That means that if you wish to use IntelliJ IDEA or Flash Builder to edit your code, you have to put up with them complaining about missing classes and a lack of code completion. Or does it?

Oftentimes, you want to include a lot of console.log() statements while you are developing your app. Most of these will be removed before deployment, but it isn’t always convenient to remove all of them. There are useful messages that illuminate what’s happening, like log statements in AJAX responses and module initializations. If you remove them all and a bug is discovered in your production code, you’ll have to go and put them back in – that’s not staying very DRY.

Of course, you could just leave the console.log statements in the code. There are two problems with that. The first problem is Internet Explorer. In IE 8, console is only defined when the Developer Tools panel is open. (That just seems like a cruel trick; you won’t see any errors caused by missing console objects when you open the dev tools to find out why your code doesn’t work.) You can get around that by including your own console shim. One is included in HTML5 Boilerplate.

That brings us to problem #2. There is a performance cost to having the browser catching log events. Usually this won’t really make any appreciable difference, unless you have a log message in a big loop somewhere, but it’s something to be aware of.

If you have a minification step, UglifyJS will afford you a better solution.

My first and most-popular article on this blog dealt with extending jQuery UI Draggable to make it work with Metafizzy’s Isotope Plugin in Firefox. You can read it here: http://jstarrdewar.com/blog/2011/10/28/extend-jquery-draggable-to-work-with-isotope/

This is actually no longer necessary – the bug in Firefox has been fixed – but I still have been getting a lot of requests for a working example.

I’ve written another article for The Code Builders’ website. This one is a quick non-technical introduction to Node.js: what makes it unique and why you might want to use it.

http://thecodebuilders.com/javascript-and-node-js/

One of the best pieces of advice for beginning programmers is “Don’t Repeat Yourself”. Whenever you find yourself performing drudgework, it’s best to take a step back and ask yourself if you have taken the right approach. By figuring out how to make the computer do the work for you, you will improve your skills and lower your maintenance burden.

People tend to avoid doing this because they it requires putting some energy into thinking critically about their work. It always feels like it would be easier to just paste that line of code in a bunch of different places. That’s a form of laziness that will come back to haunt you later. As a programmer you’re paid to think, not to type!

I’ve written an introductory article about this idea – often referred to as “staying DRY” – as a newsletter for The Code Builders. You can read it here: http://thecodebuilders.com/dont-repeat-yourself/

By the end of the decade, products like the Oculus Rift Head-Mounted Display could breathe new life into the PC business. I say this because I see great potential in the device for a whole new kind of computing experience. I think its utility could go far beyond games: it could replace our existing screens and monitors for day-to-day computing.

When beginners first embark on an HTML project, they generally test their work by simply double-clicking the index.html file and opening it in a browser directly. You can often get quite far into a project this way, and then comes the shock: you upload to a web server, and suddenly everything is broken. Your images don’t load and your links don’t work.

This happens because links on the file system are relative to the file that tries to open them; on a web server, they are typically relative to the base URL instead.

That’s not the only problem; typically callbacks from external services won’t work, and neither will iFrames. So your social media buttons will be broken too.

The solution to this is simple. Always develop locally with a web server. Macs have Apache installed by default and it’s easy to install WAMP/MAMP/LAMP/XAMP and use that for your server. Another major benefit to this is that you can connect to your computer from mobile device and test your changes with a simple save-and-reload. It’s far more efficient than pushing to FTP every time. There’s just one problem with the built-in Apache or LAMP-stack solution:

It’s inconvenient.

On Mac OS X, you are restricted to placing all your projects in the sites folder without reconfiguring Apache, and MAMP Pro places the same restriction on you. Moreover, as you move between projects, you have to point the webroot at different folders, which tends to be just time-consuming enough that it feels like a chore to be put off. That, or you have to navigate to your project root in the browser, annoying on mobile devices. Apache takes a long time to start up as well. As a result, I still see inexperienced developers using the filesystem to test their apps, and encountering the same unexpected difficulties.

Stop doing that! There’s a better way.

I think as web developers we’re all pretty familiar with this block of code, or something like it:

1
2
3
4

<link rel="stylesheet" type="text/css" media="screen" href="css/style.css" />
<!--[if IE 8]><link rel="stylesheet" type="text/css" media="screen" href="css/ie8.css"  />< ![endif]-->
<!--[if IE 7]><link rel="stylesheet" type="text/css" media="screen" href="css/ie7.css"  />< ![endif]-->
<!--[if IE 6]><link rel="stylesheet" type="text/css" media="screen" href="css/ie6.css"  />< ![endif]-->

When I see this I get depressed. It just feels like so much work to keep all the overridden classes straight, especially with the oldIE’s terrible dev tools. Paul Irish and HTML5 Boilerplate have since popularized a technique that I greatly prefer: rather than having the overridden styles in a separate stylesheet, you can place them right below the original declaration. It requires a lot less mental overhead to keep track of your overrides this way.

Here’s what the code block above looks like in HTML5 Boilerplate:

1
2
3
4

<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->

Here’s how it’s used on this site:

1
2
3
4
5
6
7
8
9
10
11
12

.lt-ie9 body > header h1 {
  font-family: "Open Sans";
}

.lt-ie9 aside.sidebar {
  padding-left: 40px;
  width: 240px;
}

.lt-ie9 body > nav {
  padding-right: 24px;
}

You can also use this technique with JavaScript to do a lot of useful things. I’ve found a few which I’ll share with you.

I’ve been using Backbone.js for the first time on my latest project. I’ve found it to be very helpful, providing a clear structure for breaking up large pieces of JavaScript into smaller, more manageable submodules.

I just ran into an issue when I decided I needed to override the set and save methods of the Model class. I followed the documentation’s example (reproduced below):

1
2
3
4

set: function(attributes, options) {
    Backbone.Model.prototype.set.call(this, attributes, options);
    ...
}

Unfortunately, it didn’t work fully. Only one of my calls to save() would work with the override in place. It turns out there are a few different things that can go wrong.

First of all, you should return the result of the call to the prototype. It’s not always void, and if it gets called indirectly there will be problems from internal methods that read the return value. So this is a better template to follow:

1
2
3
4

set: function(attributes, options) {
    ...
    return Backbone.Model.prototype.set.call(this, attributes, options);
}

(Thanks to Eggi and Brian Genisio from pointing this out in their comments on this Stack Overflow Answer.)

If you need to run the super method before your override logic, then you can store the returned value (I don’t think this will be a common scenario with Backbone):

1
2
3
4
5

set: function(attributes, options) {
    var result = Backbone.Model.prototype.set.call(this, attributes, options);
    ...
    return result;
}

The second problem you may encounter (more specific to set/save) is that the actual function signature of Backbone.set and Backbone.save is this:

1

set: function(key, value, options) {}

What happens is that you can call set() or save() you can use two different forms:

1
2
3

// These are equivalent:
Model.set('key', 'value');
Model.set({key: value});

This works because Backbone checks to see if key is an object literal or not with _.isObject(key). If it is, then it assumes key is attributes and the value argument actually represents the options object (it simply ignores the options argument).

The upshot of this is that if you override the function signature you can’t use the ('key', 'value') form without doing similar logic in your method override. I suppose this is why the documentation shows only the object literal form in their example. It’s a bit impractical to recreate this every time you override the method, especially because you are probably responding to the attributes. However, later on you may not remember that you have overriden the save or set method and attempt to call it with the simplified key/value form. That will leave you scratching your head for a little while until you Google this blog post ;-)