// Add a new function to an existing namespace
some.namespace.doSomething = function () {
    // ...
}

// Define more functions inside a closure to hide some helpers
(function () {
    // ...
})();

This was giving me a “yada yada yada … is not a function” error. In despair, I commented out the closure at the cost of polluting the global namespace! I recently revisited the code (taking a break always helps) and noticed that I was missing a semicolon after the initial function definition:

// Add a new function to an existing namespace
some.namespace.doSomething = function () {
    // ...
}; // <---------------------- AH-HA!

Now, why is this semicolon so important? Let's look at how the code reads without the semicolon, after removing some of the whitespace fluff:

some.namespace.doSomething = function () {
    // ...
}(function () {
    // ...
})();

In effect, without the semicolon, the opening parenthesis that I used around the closure becomes a function call operator on the first function definition. I end up passing the second function to the first function, and then calling the result of that call as a function. If the first function returned a function as a result, I wouldn't have been getting this runtime error.

Why did I bother writing this up? Firstly, I wasted precious time due to a single missing semicolon and wanted to share the resolution.

Secondly, I'm an advocate of strict style. I always end my JavaScript lines with semicolons, even if JavaScript doesn't mandate it. In JavaScript tutorials here and there, authors sometimes preach that "semicolons in JavaScript are completely optional" and that "you don't need to use them unless you're putting multiple statements in one line." Wrong! The above piece of code is something that you're likely to see in a modern JavaScript framework (hey, closures are big!) and is therefore a non-obscure example of why you SHOULD always use semicolons.

Also, JavaScript minifiers perform better in the presence of consistent semicolon usage.

TED uses dotSUB for video translation. Peeking at the HTML source of dotSUB’s translation interface, I saw that they were using script.aculo.us (therefore Prototype), Ext JS and YUI, all at the same time. “Why not just use jQuery?”, I briefly wondered and moved on.

Having Ext JS at my disposal was a bonus, as the Ext.select function allowed me to easily attach event handlers to specific elements, in a very jQuery-esque fashion.

The way the bookmarklet works is:

1. Go to the dotSUB translation page.
2. Invoke the bookmarklet (just once!)
3. Whenever you need a Turkish letter, you use an escape sequence: the Latin alphabet counterpart, followed by a caret (”^”). For example, for “ç”, the escape sequence is “c^”.
4. As soon as you hit enter or click on another field and cause the translation field to blur, the escape sequences are replaced with the desired Turkish letters and dotSUB handles the rest.

The full set of escape sequences are:

OK, if by any chance you’re suffering from the same specific problem of not having a Turkish keyboard while doing a Turkish translation on dotSUB, here’s the bookmarklet:

dotSUB Escapes

To “install” this bookmarklet, drag the above link to the bookmark toolbar of your browser or simply add it as a new bookmark, making sure none of the characters are trimmed/dropped.

First, I created a new project (category) called “reQall” at Todoist. This is the default project where new items that I create through voice will land. I discovered the unique ID of this project through the following Todoist API request:

http://todoist.com/API/getProjects?token=my_secret_token

I configured an e-mail alias on WebFaction to pipe received messages to a Python script. The script parses the e-mail, extracts the subject (which contains the transcribed text) and posts a new task to Todoist, under the “reQall” category, with priority 1 and today as the due date (so that it grabs my attention and I triage the task as soon as possible.) Here’s the Python script:

For the time being, this setup works quite well for me. When I think of something while driving, I pick up my cell phone (very responsibly!), use voice dialing to call into reQall, utter a sentence and hang up. The transcribed text (sometimes with funny interpretations) lands as a new task under the “reQall” category on my Todoist account. I feel like a hero and go to a bar to celebrate.

var obj = { a: 1 };

with (obj) {
    function foo() {
        return typeof a;
    }
}

alert(foo()); // alerts "number" on Firefox, "undefined" on others

This exposes the object properties to the function scope only on Firefox. On all other browsers that I’ve tested with (IE, Safari, Opera and Chrome), the property isn’t visible inside the function.

function/*post-keyword*/fn/*post-name*/()/*post-parens*/{
    /*inside*/
}

document.write(fn.toString());

And here are the results I got on different browsers:

And out of the browser context:

While looking for the best solution to extract the parts that I need, I’ve implemented a workaround. Sort of. If blocking the problem can be considered a workaround:

var functionToStringHasComments = /PROBE/.test(function () {/*PROBE*/});

// ...

if (functionToStringHasComments) {
    throw "...";
}

For example, for a document that has the following headings:

<h1>Main Section 1</h1>
Some text

<h2>Sub-section</h2>
Some text

<h3>Sub-sub-section</h3>
Some text

<h1>Main Section 2</h1>

The generated HTML will be:

<ul>
    <li>
        Main Section 1
        <ul>
            <li>
                Sub-section
                <ul>
                    <li>Sub-sub-section</li>
                </ul>
            </li>
        </ul>
    </li>
    <li>
        Main Section 2
    </li>
</ul>

The code can be placed anywhere on an HTML page. It will locate all heading under the element with id “contents” and generate the table of contents inside the element with id “toc”:

window.onload = function () {
	var toc = "";
	var level = 0;

	document.getElementById("contents").innerHTML =
		document.getElementById("contents").innerHTML.replace(
			/<h([\d])>([^<]+)<\/h([\d])>/gi,
			function (str, openLevel, titleText, closeLevel) {
				if (openLevel != closeLevel) {
					return str;
				}

				if (openLevel > level) {
					toc += (new Array(openLevel - level + 1)).join("<ul>");
				} else if (openLevel < level) {
					toc += (new Array(level - openLevel + 1)).join("</ul>");
				}

				level = parseInt(openLevel);

				var anchor = titleText.replace(/ /g, "_");
				toc += "<li><a href=\"#" + anchor + "\">" + titleText
					+ "</a></li>";

				return "<h" + openLevel + "><a name=\"" + anchor + "\">"
					+ titleText + "</a></h" + closeLevel + ">";
			}
		);

	if (level) {
		toc += (new Array(level + 1)).join("</ul>");
	}

	document.getElementById("toc").innerHTML += toc;
};

The HTML should be structured something like this:

<body>
	<div id="toc">
		<h3>Table of Contents</h3>
	</div>
	<hr/>
	<div id="contents">
		<h1>Fruits</h1>
		<h2>Red Fruits</h2>
		<h3>Apple</h3>
		<h3>Raspberry</h3>
		<h2>Orange Fruits</h2>
		<h3>Orange</h3>
		<h3>Tangerine</h3>
		<h1>Vegetables</h1>
		<h2>Vegetables Which Are Actually Fruits</h2>
		<h3>Tomato</h3>
		<h3>Eggplant</h3>
	</div>
</body>

Take a peek at Automatic Table of Contents Demo to see this in action.

The code can be tweaked to remove the hard-coded dependency on the “contents” and “toc” elements. You could also add automatic section numbers (1, 1.2 etc.) to the table of contents as well as the original headings.

var start = new Date(); // Get current time

for (var i = 0; i < n; i++) {
    myFunction();
}

var finish = new Date(): // Get current time

var ntimes = finish - start; // Elapsed time for n iterations
var once = ntimes / n; // Average time for one function call

However, this doesn't really measure just how much time n calls to myFunction took. There's also the overhead of the loop itself. What we actually end up measuring is not just the time to execute one call to myFunction but also the overhead of one iteration:

// function + overhead
var ntimes = finish - start; // Elapsed time for n iterations
var once = ntimes / n; // Average time for one function call + iteration

Here's a simple deviation from this approach to easily discount the loop overhead from the final measurement:

var start = new Date(); // Get current time

for (var i = 0; i < n; i++) {
    myFunction();
}

var lap = new Date(): // Get current time

for (var i = 0; i < n; i++) {
    myFunction();
    myFunction(); // Call the function again
}

var finish = new Date(): // Get current time

// function + overhead
var elapsed1 = lap - start; // Elapsed time for n iterations

// function + function + overhead
var elapsed2 = finish - lap; // Elapsed time for n x 2 iterations

// function + function + overhead - (function + overhead)
// = function + function + overhead - function - overhead
// = function
var ntimes = elapsed2 - elapsed1; // Elapsed time for n iterations
var once = ntimes / n; // Average time for one function call