Thinking, Fast and Slow

For example, programmers have been arguing since the 1970s about the placement of curly braces. Some people prefer:

if ( true ) {
doSomething();
}

Others prefer:

if ( true )
{
doSomething();
}

Crockford says that if the compiler treats these 2 forms as equivalent, then there is really no difference (so long as you are consistent). These are Gut decisions. However, people will use their Head to try to rationalize their Gut decisions and come up with some ridiculous rationalizations.

OK, fine. What does that mean in practical terms, i.e. writing code?

Crockford's advice is:

Prefer forms that are error-resistant.

This is aligned closely with my own advice:

Prefer explicit forms to implicit forms.

One of Crockford's illustrations (which I have not verified but sounds plausible enough) is that the space character was introduced into Latin writing after the prior practice of running all the words together led to ambiguity and transcription errors. The space characters made the text more explicit, and therefore less prone to transcription error.

Here are 3 of the Javascript examples Crockford provided during his talk:

Curly Braces & Conditional Statements and Loops
In Javascript, a conditional statement or a loop containing only one statement can be written without curly braces:
if ( condition ) doSomething();

This form is error-prone. Include the curly braces:
if ( condition ) {
doSomething();
}

Some people might complain and say that this is less concise and requires extra typing. Crockford's response was: less concise is better, and the majority of the time it takes to write a program is in thinking, not typing. If adding a few characters is slowing you down, you either need to take a typing class or spend more time thinking!

Double-Equals versus Triple-Equals
Crockford said that using double-equals (==) to compare objects is always a bad idea because it does implicit type conversion. For example:
var n = 5;
n == 5; //true
n == "5"; // true
n === "5"; // false
n === 5; // true

The triple-equals also helps developers know that a number is expected, not a character or other data type.

As Crockford emphasized:

If a feature is sometimes problematic, and a more reliable feature exists, use it!

Some people might try to justify the use of implicit type conversion: "But I'm doing it intentionally!" Crockford said that relying on implicit type conversion means you don't know what you're doing.

Incrementing Values
Crockford said he never uses the prefix or postfix ++ operator, because many people don't understand the difference and it can lead to confusion. For example:
var x = 5;
var y = x++; // y is now 5 and x is 6
var z = ++x; // z is now 7 and x is 7
x += 1; // x is now 8. This is Crockford's preferred method to increment a variable

Crockford provides several resources to help people write better, more error-resistant Javascript:

• Code Conventions for the JavaScript programming language
• JSLint, which alerts you to errors in your code or error-prone code ("JSLint will hurt your feelings")
• JSMin, which "minifies" (removes unnecessary characters) from Javascript files. This should be largely unnecessary if your web server uses Gzip compression.

There is a simple way to have a link open in a new window using Javascript. You may have seen code like this:
<a href="#" onclick="window.open('http://osric.net')">osric.net web hosting</a>

That method has some serious drawbacks, though:

• The user now sees # in the browser’s status bar instead of the actual destination URL
• The link fails if the Javascript fails (or if the browser has Javascript disabled
• Search engines may not follow the link

I’ve written a summary of the issue and the methods I’ve found so far that best address it. I moved it to a page outside this blog because of the Javascript examples, which were easier to include on a separate page:

How to best use Javascript to open links in a new window

As we contemplate overpopulation, a quote like that is quite thought-provoking and shocking. Could it be that the living today outnumber all of our ancestors? It’s astounding. However, I didn’t believe it. I still don’t believe it, and for good reason.

For one thing, relatively trusted sources say otherwise:

• Recount Your Dead (Snopes.com)
• Worst 10 Urban Myths (Myth #3 on Null Hypothesis)
• Fact or Fiction: Living People Outnumber the Dead (Scientific American)

Where did the myth come from?
Good question. I’m guessing it came from a college sophomore studying computer science. If you look at doubling, you’ll notice that each successive result is larger, by 1, than the sum of all previous results:
1, 2, 4, 8, 16, 32, 64 ... n^2

If you look at a perfect binary tree, the relationship to population becomes more apparent:

A perfect binary tree

“Assume a Spherical Sheep”
There’s a joke I’m fond of that involves a physicist describing to a farmer how he can get more wool from his sheep. “First,” he says, “assume a spherical sheep.” We often turn to simplified models to help explain complex phenomena, but in the case of the sheep and in the case of human population growth, the model makes quite a few assumptions that just don’t reflect reality. The main assumption made when using a perfect binary tree as a model is that population doubles with each successive generation. But what if that isn’t the case?

A binary tree (not complete)

Now the last generation is outnumbered by its predecessors! This could be due to disease, war, infant mortality, hungry tigers, or any number of things. World population actually decreased during the Black Death of the 14th century, so the population growth rate was, for a time, negative.

You might say, and quite rightly, that more than just one generation is alive at a given time. Your parents are probably alive. Your grandparents may be alive. You may have children. That’s why I decided to build a population simulator!

Javascript-based population simulator

Use the sliders (thanks, jQuery!) to adjust some of the variables, such as the age of humankind, the number of years between generations, and the growth rate. If you hope to produce a result in line with the Earth’s current human population (about 7 billion), you will find that population growth has been, on average, extremely slow over the course of human history. It’s a rough world out there: not everyone lives (or, at very least, not long enough to reproduce).

You might also object that, even if population growth has been slow historically, we haven’t had a devastating plague lately–couldn’t a few recent successive generations of dramatic growth easily surpass prior generations?

The population starts doubling in the last 3 generations

Not really. The above representation only shows 27 generations–maybe 600-700 years. In reality, the long thin line of ancestors on the left vastly outnumbers the dramatic growth on the right.

JSONP prefixes your JSON response with a function name, which runs when the response is retrieved. It’s a way of handling the data without a listener.

This means that your JSONP provider needs to detect a JSONP parameter, and then wrap or “pad” the response within the specified parameter value.

For Sencha Touch, the JSON returned should be wrapped in Ext.util.JSONP.callback();. If your JSON looks like this:

{"results":[{"name":"Chris"},{"name","Harry"}]}

then your JSONP should look like this:

Ext.util.JSONP.callback({"results":[{"name":"Chris"},{"name","Harry"}]});

Not that you should hard-code that function name anywhere in your JSON output–web-based APIs and services should pick up the function from your request and wrap the JSON for you. For example, the twitter search API accepts a callback querystring parameter.

http://search.twitter.com/search.json?q=fakecriterions&callback=myCallbackFunction

would wrap the JSON response inside

myCallbackFunction();

I ignored the extra letter in the acronym at my own peril–I figured it was just a trivial variation on JSON (which it is) that wouldn’t make any difference in how it was handled (but it does).

Why would you want to reference the URL querystring with Javascript?
A couple reasons come to mind.

• Highlighting a specified term wherever it appears within a page
• Linking to a dynamic page in a specific state

The latter, which I have also seen called deep linking, seems particularly useful to me. You want to send someone a link to a video, but it’s one of several videos in a playlist on a page. You can send the URL and tell them, “It’s the 4th video from the top.”

Or you want to send someone the link to a page featuring one of the nearly-ubiquitous carousels, like the Discovery Channel’s main page. You want to send a link to the lunar rover feature, but by default the page features a ridiculous-looking reality show called American Choppers.

One way would be to supply the user with a link, something like:
http://dsc.discovery.com/?feature=4

(Sure, you could link to the feature’s destination page, but humor me here.)

Here’s some code to help turn location.search into something a little easier to use:
function parseQS() {
// Remove leading question mark ("?") and split into array of key/value pairs
var qsArray = location.search.slice(1).split("&");
// Initialize object to store key/value pairs
var json = {};
// Loop through key/value pairs and separate into keys and values
for ( var i = 0; i < qsArray.length; i++ ) {
var kv = qsArray[i].split("=");
var key = kv[0];
var val;
if ( kv.length == 1 ) val = key;
// A key may be present without a value, so set a placeholder value
else val = kv[1];
json[key] = val;
}
return json;
}

Now you can check to see if parseQS().feature is defined, and if so, show the user the specified feature.

I’m sure someone has created a more elegant Javascript querystring parser. If you’ve found one–or if you wrote one–let me know in the comments.

I recently created a simple word game using Javascript, which presented certain challenges. The game displays 3 random letters to the player, who must then attempt to create a dictionary word in as few moves as possible by shifting the letters up or down in the alphabet.

There were several programming decisions or challenges that came up during the game’s creation, for which I was able to apply some of the things I learned in my recent computer science classes.

The first challenge was how to include the dictionary. The source list I used for 3-letter words (from a Scrabble dictionary) includes 1012 entries. Although I could have developed a server-side solution to check words via AJAX, I wanted the game to be as quick and responsive as possible, and 1012 3-letter words is not all that prohibitive. First, I created an array of all the words; however, that took a lot of extra bytes for all the quotes and commas. In fact, it doubled the space required. I looked at using a prefix scheme (“A” followed by all the two-letter sequences that begin with “A”) to save a few bytes, but the savings was not as great as I had initially anticipated. In the end, I just included the dictionary as a long, unbroken string: since we know that each word is 3 characters, it is easy to access any given word.

The next challenge was how to look up the user’s 3-letter sequence to see if the sequence is in our dictionary. The brute-force approach is to compare it to every word in the dictionary, which would take 1012 comparisons for a sequence that isn’t present. 1012 comparisons isn’t all that bad, but there are certainly more efficient ways, and I was thinking about the implications of expanding to a 4-letter or 5-letter game. Here are some of the look-up options I considered:

• Binary search. Because we are dealing with an alphabetized dictionary, we can start in the middle of the dictionary and immediately eliminate half as possible matches, and then perform the same binary search recursively. Now we need only 10 comparisons for a sequence that isn’t present.
• Hash table. Although we would have to create the hash table at the beginning of the game, this only took 3 comparisons for a sequence that wasn’t present (based on empirical observation).
• Bucket array. I’m not sure what else to call it, but I created a large array (17,576) that could accommodate every conceivable combination of letters. A sequence not in the dictionary remains null, and a sequence in the dictionary gets assigned a 1. This method has larger memory requirements–not extraordinary for 3-letter sequences, but would grow quickly for longer sequences. Now we only need one comparison to determine is a sequence is a dictionary word.

I picked the binary search for its simplicity.

The last major challenge was creating the “fewest moves” algorithm. The game currently tells the user the fewest number of moves it takes to convert the random sequence to a dictionary word. I struggled with this at first, until I realized that the problem is basically just a Breadth-First Search or shortest-path algorithm. I enqueue the initial sequence. For each possible one-move combination, I check it against the dictionary, and enqueue that sequence. (I enqueue an impossible dummy sequence–”###”–to indicate that we need to increment the fewest moves.)

One problem with this is that if it enqueues every one-move combination, it will enqueue many duplicates. Before I checked for duplicates, I found that the fewest moves algorithm often checked more than the 17,576 unique 3-letter sequences. For letter combinations where the nearest dictionary word was 8 or more moves away, Javascript would become unresponsive (or the browser would crash). Since the already-checked sequences were in no particular order, I used the hash table (instead of the binary search) to perform look-ups (although a brute force approach would probably have been sufficient).

Another problem with the fewest-moves algorithm is that my first approach was to use a recursive function. However, Javascript apparently does not always perform well with recursion; Firefox would throw “too much recursion” errors. I changed the function to use a while loop (continue processing while the queue is not empty), which solved that issue.

Although many of these optimizations were not strictly necessary and the brute-force approach would have worked suitably in many cases, I think the optimizations will help the game scale to handle 4-and-5-letter words (although the dictionaries may become too heavy for 5-letter words).

Hunt the Wumpus was originally created in the 1970s, and unfortunately, most of the versions you can find on the web today are easier and less interesting that the original. The original eschewed a square grid for the game board and instead used a “squashed” dodecahedron, where each game space was one of the vertices.

It is also noteworthy for introducing the superbat, a feature of other games (including Zork) that followed Hunt the Wumpus, and for the humorous feedback (e.g. “ZAP–Superbat Snatch! Elsewhereville for you!”) that many of my favorite games adopted.

At any rate, I decided to recreate a version of the easier and less interesting grid-based game in Javascript:
Hunt the Wumpus

As the Gecko DOM Reference for Node.insertBefore() points out, this can easily be achieved with
parentDiv.insertBefore(nodeToInsert, nodeToInsertAfter.nextSibling);

If nodeToInsertAfter doesn’t have a next sibling, a NULL value will be returned and nodeToInsert will be inserted as the last child of parentDiv.

If you find it frustrating to type insertBefore when you want to insertAfter, that’s OK: you can add that function to the Object object:
Object.prototype.insertAfter = function (newNode) { this.parentNode.insertBefore(newNode, this.nextSibling); }

Now you can type:
nodeToInsertAfter.insertAfter(nodeToInsert)

It blew my socks off. I’m really really impressed with jQuery, and I’m looking forward to using it a lot more. It took me an hour or two to really get a handle on how a few parts of it work, but man is it a powerhouse. If your website needs to sing and dance…. jQuery is the way!

First of all, I noticed that some of the textarea counter scripts date back to at least 2000, so this has been a problem that developers have been looking to solve for 8 years. I checked the HTML 5 specification and found that in HTML 5, the textarea element has a maxlength attribute. Presumably user agents will build in the most elegant solution.

But what is the current most elegant solution?
I checked a couple sites that I know use textarea counters well: Delicious and Twitter.

Delicious

Textarea counters on Delicious.com

Twitter

Textarea counters on Twitter.com

I like how prominent the character count is in Twitter, although perhaps too terse, but if Javascript is disabled it displays nothing at all. On the other hand, in Delicious displays “1000 characters max” if Javascript is off (instead of “1000 characters left”), which is still useful information. (I would avoid using the abbreviation max, though, and use maximum or limit instead, which might be better understood by those for whom English is a second language.)

I like Twitter’s “warning track” that lets the user know they need to keep it concise and wrap it up, although I find it confusing that they used bright red to denote both the “dangerously close to” as well as “over” the limit. The positive bright red numbers could easily be misconstrued as over the limit, since red is a color we frequently use to denote errors.

Twitter’s counter responds to onBlur and onChange, whereas the counter in Delicious is triggered by neither.

Both get one thing right that I think most other textarea counters get wrong: they don’t truncate the user’s text. Deleting something that the user has typed (or pasted) is definitely a bad idea for at least two reasons: the user may not realize the input was truncated and may submit incomplete info, and that the user, upon discovering that the input requires editing, may choose to cut text from someplace other than the end. Instead, both versions alert the user that they are over the limit and provide information on how many characters need to be cut to stay within the limit.

(As an aside, one thing I find curious is that both count an Enter keystroke as one character. I’ve run into issues with this before because a line break on a Windows-based system should insert 2 ASCII characters: a Carriage Return (CR) and a Line Feed (LF). *nix systems, including OS X, will insert a Line Feed (LF). However, I haven’t been able to reproduce this issue with recent testing. If it is still an issue, I imagine they handle this on the back-end by converting the CRLF to LF before inserting it into the database?)

In short, my recommendations are:

• Don’t truncate the user’s input; let the user correct it
• Let the user know how far over the limit he or she is
• Provide guidelines even if Javascript is disabled
• onBlur and onChange should also trigger the counter, in case the user is pasting text
• Keep the counter message simple and clear

Another idea I had for a visual counter:

Counter - characters remaining

How can a counter be implemented programatically?
I would like to set something up so that the appropriate event handlers are attached to textarea elements automatically. I found a jQuery plugin, Char Limit, but in addition to not meeting the recommendations I made above, I don’t like how the developer has to specify the character limit in the Javascript (and apply the same limit for all textarea elements).

I think a clever, although imperfect, solution would be to have jQuery (or any Javascript of your choice) turn any static character limit messages (like the one that Delicious provides if Javascript is disabled) into dynamic character counters. For example, with the following code, the Javascript could find any elements with id attributes matching *_counter, take the numeric part as the limit, and build a character counter:
<textarea name="example" id="example"></textarea>
<div id="example_counter">300 characters maximum</div>

It’s problematic for several reasons: another element on the page could have an id that matches *_counter, the non-Javascript message could contain more than one numeric part, and the developers would have be consistent in naming the textareas and accompanying divs. But I think it is in many ways an improvement over the inline Javascript I’ve seen in some oft-used solutions.