Search Results

This past weekend I participated in the  Node Knockout - a programming competition where teams of 1 - 4 members build something using node.js in 48 hours. I was very fortunate to have worked with @robfaraj on this, it was a fun couple of days! The end result is what we call Twends Twends: new location is now twends.us. Twends is a real-time Twitter trend visualization...app. It looks like this

First, you either select a trending topic or type in a term of your own, then you will see this word visualization based on a series of packed circles. The larger the circle and the redder it is, the more frequently the word is being said at the moment. All the while, birds are fly across the screen. Each bird on the screen represents a tweet that's been written, now...ish. Just sit back, relax and watch the pretty circles changing shape and the birds flying across your screen. By reading the words you can often learn interesting things. For example, I learned while reading Twends that Justin Beiber fans are called beliebers, while Taylor Swift fans are called swifies. 

Oh! And here's a video of it in action

The Tech

Twends was built using client-side Javascript with the help of some great libraries and the Twitter REST API. d3.js is without a doubt the most valuable library(MVL). We used it to layout the circles as well as animate them from their old positions to the new positions each time new data comes in. We also used HTML5 Boilerplate and jQuery. On the server side, we used express and the jade templating language.

Graphics is done using SVG, which d3.js works very well with - although is independent of. IE8 and below do no support SVG so Twends do not work there. Twends could have worked on IE9 but it doesn't. IE9 supports SVG, so that was not the problem. The problem was that IE9 was blocking the JSONP requests I was making to the Twitter API due to this problem, of which the blame is half on Microsoft and half on Twitter. So, if you go to the site with IE, it will greet you with a friendly(?) message and prompt you to install Google Chrome Frame, yea!

The Aftermath

The competition is still being judged at the moment, so I don't know what's the aftermath just yet. I guess I'll update this part of the post another time.

Node knockout came to an end and the winners were victorious! Congrats to them. I am a little disappointed/surprised that one of my favorite entries: Pitchography didn't win anything, here's a demo of their awesome presentation tool. As for Twends, well we were decidedly better than half of the entries out there :) We also presented it at the Atlanta Javascript Users Group and got some good feedback. I've made the source code public on github as well.

Node Knockout was a great experience. The organizers did a superb job of allowing the contestants to focus on writing code rather than dealing with setting up servers or administrative stuff. I enjoyed everything from the planning stages where we threw around random ideas, to the actually coding and then to the showing it off to people and seeing their reactions and comments. If you love code, then I highly recommend that you try a hackathon like this one.

The awesome folks behind JSConf just released a whole bunch of great talks in video form from the Portland event. Great chance to catch up on the talks whether you were there or not! They even put mine up there, which since this is my website, I am obliged to embed here. Wow I sound so very Chinese.

This is the second of 2 Python book reviews. The book is Python Test Cookbook. 

This book is a very complete overview of all aspects of testing with Python. It starts out with simple unit tests, then moves on to nose, BDD, Doctest, acceptance testing, coverage, continuous integration, and smoke tests and load tests. The last chapter of the book gives you a number of advices for starting out with testing.

The Good

I enjoyed this book in that it gave me a birds-eye view of all the tools and techniques that are there for Python, many of which I didn't know about before. I also learn new things about things that I had already used before. Lastly, I liked the last chapter in which the author gives us his heart-felt experiences with testing. Although I don't agree with everything he says(running your tests once a day is way too few), there is a lot of good advice there as well as good stories.

The Bad

One thing that I don't like about this book is that it's too code heavy. Pages and pages of code are print onto the page with only interleaving explanations. I mostly skimmed those parts because reading code line-by-line like that is just too boring. Code is simply not meant to be read in a linear fashion. When you read code, you jump between different files rapidly in order to fill the in missing context as you try to gain an understanding of the code. An even better aid in reading code is the ability to execute the code and instrument it with print statements or stop it with the debugger and inspect the program state. So, in summary, code-heavy books just doesn't make sense. Perhaps instead of writing this as a book, we should just point the readers at a code repository?

The second problem is that not enough was done to motivate each technique that was used. The author didn't properly motivate why one should write unit tests at all. Or why use a given technique listed in the book. Only cursory introduction is given for each technique or tool, and then it was straight to the code. We dwelled too much time on the how and not on the why, which makes this book very unfriendly to beginners.

Summing Up

Overall, I would not recommend this book to beginners or people who are looking for an introduction to testing. I am on the fence about recommending it at all, but it might be helpful for people who are already familiar with test driven development but just haven't been doing it with Python.

I just finished reading Python 3 Web Development - Beginners Guide by Michel Anders and here is my book review.

Michel Anders is no doubt a brilliant programmer. He has managed to go through HTML, Javascript, jQuery, jQuery plugins(both using and writing), jQuery UI, CSS selectors, CSS 3, Python, CherryPy, SQL and SQLite, unit testing, writing your own ORM, and Python meta-classes all in one book! Which is the problem with this book. I doubt any one who qualifies as a beginner will be able to get any further than chapter 2. I believe the author made the mistake of not putting in enough thought about his audience when writing. But, before making my final remarks, I'll give it proper treatment by commenting on each of the chapters.

Chapter 1

Chapter 1 explained the authors reasons for choosing the tools that he did, and boy were there a lot of choices to be made. Here were the choices:

There are a lot of high level talk about the rationale of each choice and why he made them. It was a bit strange that he put the choice of using Python after the choice of using CherryPy. The first chapter is quite intimidating for beginners - there is really lots to consider when building a web app. He admits it too, but he puts in a lot of encouraging words to encourage the reader to stay focused.

Chapter 2

Chapter 2 went through the exercise of building a web-based spreadsheet application, a la Google Docs. The goal is ambitious, especially for a "hello world" program. I wondered how he was going to pull it off. 

The Author covered CherryPy, jQuery/CSS selectors, a jQuery plugin called jEditable, wrote his own jQuery plugin that builds a spreadsheet which uses jEditable, CSS 3 and HTML all in this chapter. The amount of Javascript in this chapter really surprised me because in the who-is-this-book-for section, it says "introductory level knowledge of JavaScript might be useful, but is not strictly necessary". He simply tried to cram too many things in, explaining each technology only cursorily as he encounters them. I am pretty sure that he lost almost all readers in his audience with this chapter. 

The kind folks at PacktPub are letting me review a couple of Python books. Hooray! They are

Look for my reviews of them in the near future.

For the past week or so I did some research on how best to include scripts in Tutti's sandbox environment and still get the best stacktraces possible. I got sucked in deeper and deeper and it just got uglier and uglier. This post will attempt to summarize all the knowledge that I've uncovered.

What's a Stacktrace?

When I say stacktrace, I mean it in the context an exception being thrown in your code, and getting the information about where exactly in your code the exception was thrown. This is what a exception might look like

Error: Buck stops here.
at failInlined (http://localhost:8000/error_object/:16:11)
at catchError (http://localhost:8000/util.js:77:26)
at http://localhost:8000/error_object/:49:1

First, there is an error message. Then, the stacktrace. The stacktrace basically represents the state of the program's call stack at the point when the exception was thrown. The stacktrace also contains the location(file URL and line number) of each call in the stack, which is extremely useful for debugging.

So What's the Problem?

The problem, is that not all browsers give you informative stacktraces. Not only that, different browsers give you the information in different ways. 

Most browsers today give you the stacktrace information in the Error object that was thrown. In Firefox, Chrome and Opera, for example, the Error object contains a stack property which is a string representation of the stacktrace, much like the example shown above.

// Get stacktrace on Firefox, Chrome and Opera
try{
   throw new Error('Buck stops here')
}catch(e){
   console.log(e.stack) // Yea!
}

In Safari, however, the stack property is non-existent: it does not give you the full stacktrace. Instead it gives you the location for the top stack frame only. This is gotten from the properties sourceURL and line.

// Get 1-level stacktrace on Safari
try{
  throw new Error('Buck stops here')
}catch(e){
  console.log(e.sourceURL + ': ' + e.line) // Meh
}

On IE, you are out of luck. There is no stacktrace information available on the Error object.

Going Deeper

Javascript can be executed in various different ways/techniques, and not all of them yield good stacktraces. My next objective was to see what the stacktraces look like for the different techniques

Technique 1: Script Tag Includes

The script tag include is probably the most common way to execute Javascript on a webpage.

<script src="myscript.js"></script>

Technique 2: Inlined Script Tag

Alternatively you can inlined Javascript code inside of the script tag.

<script>
console.log('Hello world')
</script>

Technique 3: Dynamically Inserted Script Tag

You can also create a script element dynamically in Javascript and load some Javascript into it.

var script = document.createElement('script')
if (<IE sucks and you are it>)
  script.text = jsCode
else
  script.appendChild(document.createTextNode(jsCode))
document.body.appendChild(script)
document.body.removeChild(script)

Technique 4: Eval

Use eval to execute the Javascript in Javascript. You probably want to global eval it.

// This code for global eval stolen from jQuery 1.6.1
(window.execScript || function(jsCode) {
	window["eval"].call(window, jsCode);
} )(data);

Technique 5: Data URL in the Script Tag

Using a data URL in a script tag is...I am not sure if anyone actually does this, and I am not entirely sure it's useful, but what the heck.

<script url="data:application/javascript,console.log('hello%20world')"></script>

Summary: Stacktrace Information From Error Object

Long story short, I tested the stacktrace output for each of these five techniques in different browsers. I summarized the results in this here table (that's right, geek out!)

A straightforward script tag include yields the best stacktrace information. As the asterisk(*) indicates, the dynamic script element, global eval, and data URL techniques can yield stacktraces with non-helpful line numbers. The data URL technique actually gives correct line numbers, it's just that all the newlines have been encoded and the entire source jammed onto a single line - so, I can't really say the line numbers are all that helpful. Strangly, Opera yields non-helpful line numbers even with the Javascript-inline-in-a-script tag technique. 

So That's it? No IE?

There's no way to get stack information on IE, not unless you want to do the other thing, but you don't want to know about that.

What's that? You do want to know? No you do not! Just forget I said anything.

Okay! I'll tell you, but you are going to regret it.

window.onerror

On IE - and as it happens on Firefox and Chrome as well - you can register an onerror handler on the window object, like so

window.onerror = function(message, fileURL, lineNumber){
  log(message + ': ' + fileURL + ': ' + lineNumber)
}

The handler will be called anytime a thrown exception is uncaught: propagates all the way to the bottom of the call stack with no catchers. Catching the exception will cause the handler not to be called, unless you rethrow it, but even then, there are other complications. When the handler is called, there is no error object, only the error message, file URL, and the line number.

Bad News: IE

Because of various IE bugs, the fileURL and line number passed into the onerror handler isn't always accurate or helpful. After some research, I've isolated these bugs:

IE 9 has both of these bugs fixed, even when it emulates older versions of the browser.

What Can You Throw

The "throw" statement lets you throw just about any old value - even numbers and strings! But this is not recommended as you won't be able to get any line numbers or stacktraces if the value thrown isn't an object - except for in IE, where you can get line numbers using onerror. In IE, throwing anything other than a pre-defined error object(Error, TypeError, etc) will result in the loss of a meaningful message in both the caught error object and in the onerror handler - where it will just say "Exception thrown and not caught".

So, the simplest recommendation here is to only throw the pre-defined Error object when you want to explicitly throw an error using the "throw" statement.

throw new Error('Buck stops here.')

or better yet, don't use the throw statement at all(this avoids the second IE bug mentioned earlier).

The DIY Stacktrace

The DIY stacktrace was pioneered by Eric Wendelin among others. It first looks up argument.callee to get the current function being executed, then it walks the call stack by accessing the function's caller attribute recursively. For example:

> function f(){
    g()
  }
> function g(){
    h()
  }
> function h(){
    console.log(arguments.callee.caller.caller)
  }
> f()
function f(){
  g()
}

In the example, we are able to access the function f from with the body of h's execution by walking two levels up the call stack using the caller attribute.

Pros and Cons of the DIY Stacktrace

The advantage of the DIY stacktrace is that it will work in any browser.

The disadvantages are

Conclusion

Sorry I don't have a better conclusion than: It's a great big mess. However, with the knowledge covered here, I think it is possible to employ some sophisticated hackery to recover at least some stacktrace info for each browser - the hardest case being IE. Such a technique - if made practical - would be useful for unit test frameworks and crash reporting.

References

In Tim Ferris' book the Four Hour Work Week he shared the tip of minimizing the number of times you check email in a day. One reason that this approach is beneficial is because it will minimize the distraction from looking at the inbox. 

Yes! The Inbox is Distracting

Let me give you an example. You want to write someone an email. So you open up Gmail(or your mail program of choice). The first thing you see is your inbox. Oh! An old pal just added you on Facebook! Or, oh! Someone sent you a pull request! Your next impulse is to go add your friend on Facebook or to take a look at the pull request: it'd only take a couple of minutes. If you are someone who can resist that urge, good for you. But I usually can't. And even when I can resist the urge to actually do those things, I usually can't resist thinking about them. Half an hour later, I am usually serving the web or writing an email to someone else and have forgotten what I was doing in the first place.

Maybe the problem is the high level of in-your-face which the inbox possesses. My first attempt was Gmail Peepshow: a Greasemonkey script that initially blocks the view to your inbox. This solution didn't end up working very well, both because of how hard it is to manipulate the Gmail dom and its inflexibility, as I will explain.

Only Check Once A Day

One solution is to minimize your email checking frequency to say, once a day, as Ferris suggests. For me at least, this works out well most of the time, and keeps me focused. I have turned off push notifications on my phone(if you are hooked on push, you might try doing w/o it again, you might feel liberated), and only check email once a day, and try to take action right away at that sitting. 

But...

However, there are occasions  when the thing you are working on requires you to correspond with someone via email, and worse, because you want to close the loop on the task ASAP, sometimes you want to be quickly notified when the correspondent replies. So, that means repeatedly checking your inbox again.

It dawned on me that the solution was to separate the urgent correspondents from the rest of your inbox. Even better would be if push notification only notified you if the urgent email comes in. After chatting with my wife about this, she seems to think I can implement this behavior using only Gmail filters, and so I got to work. 

The Solution

The first thing to do is make a filter rule that removes everything from the inbox except for ones that come from the urgent correspondents.

Matches: -from:{ vip@superimportant.com }
Do this: Skip Inbox

Matches: -from:{ vip@superimportant.com vip@alsoimportant.com }
Do this: Skip Inbox

What we've done is reserved our inbox only for our VIP's. But now, what about the other unread mail? I am going to create a label to simulate a second inbox - the one I check once a day. I will call it @daily (The @ sign is just so it will be sorted to the top). Basically, everything can go into @daily, so my rule could be

Matches: from:(*)
Do this: Apply label "@daily"

But, here I could add a rule to filter out the bacn I get from Delta and Borders, for example

Matches: -from:{ e.delta.com e.borders.com }
Do this: Apply label "@daily"

If I want, I could add yet another rule/label, maybe @weekly, for all the bacn or less important stuff that I might still want to look at at a lower frequency.

Pros. Cons.

An advantage to using the main inbox for only the urgent stuff is

1. you will only see the urgent stuff when you open up Gmail - nothing that distracts
2. you can use push notification on your phone now and only get urgent notifications - for my iPhone, I've turned off the sound for whenever any mail is received(so I am not distracted), but the little number at the corner of the "Mail" icon shows me the inbox number 
   
   . For Android I hear the integration is even better.

The only drawback of this approach is that you will have to maintain the "Skip Inbox" filter rule - every time you change who your urgent correspondent(s) is/are, you need to go in and change it. For me, this would be every time I start an urgent task that requires a correspondent, and when I finish that task.

Conclusion

I think this is a novel approach to approaching email. But there's no conclusion yet because I have only begun using this. Will blog updates if I learn anything new in the process.

I screwed around with Traceur last night and this morning. Then I built this thing called Try Traceur to make it easy for folk to screw around with it too. Try it! You know you want to.

JSConf 2011 Portland was truly amazing experience for me, personally. Not only did I meet some fantastic people in the community - some of whom I've long wanted to meet, I also got to show off my stuff, and it didn't totally suck. Also, add to that, Portland is a fantastic city! I want to thank Chris Williams again for motivating me, and everybody involved for such a great event!

My talk was on Tutti and most of its time was occupied by demos, so rather than posting the slides I thought I would just post the example code for the demos. I hope this is helpful to people!

class String

  def -(other)
    self.index(other) == 0 ? self[other.size..self.size] : nil
  end
end

This snippet gives the Ruby String class a minus operator. Which works like

> 'abcde' - 'abc'
=> "de"
> '    ' - '  '
=> "  "

> 'abc' - 'de'
=> nil

Meh.

Indentinator is a script that inspects and changes the indentation in your source code. It is language-agnostic. "Indent your code the way you want."

Install

Assuming you have ruby and rubygem installed, you can

gem install Indentinator

to install it.

Usage

indentinator [-c INDENT_AMOUNT] <file> [<file2>...]

Examples

Using indentinator with a file argument will tell you what amount of indentation the file uses.

$ indentinator lib/myapp.rb 
lib/myapp.rb uses 2 spaces.

Using with the -c option will convert the file to the desired indentation amount, and print the result to stdout.

$ indentinator -c 4 lib/myapp.rb

The -r option will overwrite the original file with the output.

$ indentinator -rc 4 lib/myapp.rb

Make sure you have the file backed up or source controlled first! I am not responsible for any damages.

If you want to read the input from stdin, use the -i option

$ cat lib/myapp.rb | indentinator -ic 4

If you use a mixture of indentation sizes in your source file, indentinator may guess wrong, which will in turn affect the conversion output. To tell it explicitly the original indentation amount for it to use during the conversion process use the -a option

$ indentinator -a 4 -c lib/myapp.rb

Totally Use it Inside TextMate and Stuff

If you copied a snippet of code from the internets, and it uses a different indentation then you, it will be helpful to use indentinator from within TextMate. To do this, follow these steps:

1. Go to TextMate->Preferences...->Advanced->Shell Variables, and make sure the PATH variable contains the location of the indentinator executable.
2. Paste the code snippet into TextMate, select that snippet and hit Command-Option-R.
3. In the Command: text field type in the indentinator command to use, for example indentinator -ic 2, which will take the selected text as input (from stdin) and output it with an indentation of 2 spaces.
4. Click Execute.

Codez

Source code for Indentinator is distributed on GitHub. Submit me an issue if you have one, thanks ;)

While I really enjoy using Michael Foord's Mock library, there is one thing missing and I thought would be a fun project to add - which is the subject of this post.

Fun with Parameters

Python has the most sophisticated function parameter calling mechanics I've ever seen. Given a function f

def f(a, b):

    return a + b

You can either call it like normal(positional parameters)

f(1, 2)

or by keyword parameter

f(a=1, b=2)

With keyword parameters, the position doesn't matter anymore, so the above call is equivalent to

f(b=2, a=1)

You can even mix positional and keyword parameters, as long as you put all the positionals first

f(1, b=2)

So, all the ways I've listed of calling the function f with the parameter a as 1 and b as 2 will have the same functional behavior, given what we know of the signature of the function. So, it would be logical that the mock library would consider

f.assert_called_with(a=1, b=2)

a passing assertion even though in reality it was called as

f(1, 2)

but alas, it does not.

With that, it was my mission to make this happen!

Proof-of-Concept

First I created a prototype/proof-of-concept. See code here. Using

inspect.getargspec(self.func)

I was able to get all the info about the signature of a function I needed. When a function call actually comes in, my callable receives them as

def __call__(self, *args, **kwds):

at which point, I resolve all the parameters with the parameter list in the function signature(I called this "combining" the args)

But the better part is what comes next - we can now implement the assert_called_with with these new semantics. When a call to assert_called_with is called, I "combine" the args coming into that call, and check if they match the previously made function call. It's that simple!

Working in Python-Mock

Well great. But we still can't use for the Mock library. So I did some more hacking on a branch of Foord's code. Not sure it's the cleanest code, but it now works if you want to try it out

hg clone https://airportyh-python-mock.googlecode.com/hg/ airportyh-python-mock 

The way you use it with the Mock library is through mocksignature. 

from mock import mocksignature

mocksignature wraps a function that you pass it and uses the signature of that function as a guide. Given the function f that we had previously, you can do

f = mocksignature(f)

now call it

f(1, 2)

and then checking the associated mock with a different call style

f.mock.assert_called_with(a=1, b=2)

should now pass.

Cheers!

2011 is my second PyCon and easily the best one. This time, rather than focusing on the talks, I focus on the social activities outside of the talks - open spaces sessions, sprints, going to lunch and dinner with folks, and just hanging out - this has really paid off! I met, hung out and worked with some of my heros, and this made me very happy :)

Some Highlights

I've created Tuttiterm - which allows you to control browsers via Tutti. See the project README. Here's a screenshot:

Sometimes when you are writing tests, you find yourself testing whether a particular callback has been called. For example, you might write a test like this

var lastCalledWithfunction
callback(e){
    lastCalledWith = e
}
obj.bind('someevent', callback)
obj.doSomethingThatShouldTriggerEvent()
expect(lastCalledWith.type).toBe('someevent') // check that callback was called

This is slightly tedious and the code ungainly because you need to introduce a variable in your test, and store the arguments to it so that you can check the result. We can do better

function $dummy(){
    arguments.callee.lastCalledWith = arguments
}
obj.bind('someevent', $dummy)
obj.doSomethingThatShouldTriggerEvent()
expect($dummy.lastCalledWith[0].type).toBe('someevent')

This is a nice and generic, but we have to reset the lastCalledWith attribute before each test, something like

delete $dummy.lastCalledWith

But let's make it more painless

$dummy.reset()

By adding this reset function

$dummy.reset = function(){
    delete this.lastCalledWith
    return this
}

Moreover, reset returns back the dummy function itself, so, now you can write the test like so

obj.bind('someevent', $dummy.reset())
obj.doSomethingThatShouldTriggerEvent()
expect($dummy.lastCalledWith[0].type).toBe('someevent')

Very nice. I like.

While Mark Frauenfelder’s morning checklist was inspiring and relevant for me, the solution didn’t work for me because

1. It does not save the trees!
2. An iPhone would work better for me best because I always have it with me.
3. It’s not made with HTML5.

So right. If you are an iOS hacker you’d probably reach for xcode right away, but for a task like this, it’s simply orders of magnitude faster to do using plain HTML. Let’s get started. First thing to do is fire up a text editor and type in your check list of a <ul> of <li>'s with <input type="checkbox">'s in each of them.

<!doctype html>
<html>
<head><title>Morning Checklist</title></head>
<body>
<h1>Morning Checklist</h1>
<ul>
<li><input type="checkbox"/><label>Change</label></li>
<li><input type="checkbox"/><label>Contacts</label></li>
<li><input type="checkbox"/><label>Potty</label></li>
<li><input type="checkbox"/><label>Rinse Mouth</label></li>
<li><input type="checkbox"/><label>Laptop, wallet and keys</label></li>
<li><input type="checkbox"/><label>Shoes & Coat</label></li>
<li><input type="checkbox"/><label>Backpack</label></li>
</ul>
</body>
</html>

Cool, this is functional, but will look like this

Okay, that doesn’t look great. You’ll need to pinch zoom in order to see anything. What we need to do is to format the web page specifically for the iPhone screen. To do that, add this line inside of your <head>

<meta name="viewport"
content="width=device-width,
minimum-scale=1.0, maximum-scale=1.0" />

This will tell your iPhone to set the page’s viewport to exactly the same as the width of its screen, and also to disallow pinch to zoom. The result is this

Okay, nice! Now let’s make it look non-ugly with some CSS. First, change to the font to something san-serif. Take away the bullet points from the list items, remove the unnecessary margins and paddings. Make the font bigger and the checkboxes themselves bigger because we want them and each row to be big enough for Mr. Fatfinger. While we are at it, might as well stripe the rows, you can actually do it using just CSS in a non-crappy browser such as Mobile Safari. After some playing around, I added the following styles

<style>
body{
    font-family: Helvetica, Arial, Verdana, sans-serif;
    padding: 0px;
    margin: 0px;
}

ul{
    list-style: none;
    padding: 0px;
    margin: 0px;
}

li{
    clear: left;
    font-size: 25px;
    padding: 3px 0px 3px 10px;
    margin: 0px;
}

li input{
    float: left;
    margin-right: 15px;
    width: 25px;
    height: 25px;
}

li:nth-child(even){
    background-color: #eee;
}

h1{
    font-size: 20px;
    padding: 0.2em 0.5em;
    border-bottom: solid 1px #aaa;
    background-color: #eee;
    margin: 0;
}
</style>

stick these inside the <head> and now it looks like

Great! Are we done? Well, there’s one usability problem: you have to click on the checkbox itself to check it. Id’d be nice if you could check it by click anywhere on the row. Let’s drop some Javascript on this

<script>
Array.prototype.slice.call(document.getElementsByTagName('li'))
    .forEach(function(li){
        var cb = li.childNodes[0]
        cb.addEventListener('click', function(e){
            e.stopPropagation()
        })
        li.addEventListener('click', function(){
            cb.checked = !cb.checked
        }, false)
    })
</script>

Note: if you see me writing some non-IE-compatible code that’s because I am only writing for the iPhone. Nice, now you can click anywhere on a row to check or uncheck the box. Are we done? Now let’s add it as a shortcut on your Home Screen. To do that, click on the + sign on the bottom middle of the screen, and tap on Add to Home Screen. Edit the name of the button if you need to (I called it Checklist), and tap Add. Now you’ll get

If you tap on it, the checklist opens right up. But, it’d be nice to get rid of the browser chrome and buttons, that way we have less clutter and it also looks more like a real app. To do this, stick this

<meta name="apple-mobile-web-app-capable" content="yes" />

into your <head>. Unfortunately, you’ll have to re-create your Home Screen button, so delete it and go back and create again. Now, when you tab on it you’ll get

Great, we are almost done! One more thing though. Now that we are serving the checklist from a web server, if it goes down or we lose our internet connection, we won’t be able to access it. Granted this will be rare since I’ll be at home when using this, but it can happen. So we use HTML5’s applicationCache to make this page offline capable. To do this, we’ll make a cache manifest file and point our HTML page to it. First, in the <html> tag of the file add the manifest attribute like so

<html manifest="/cache.manifest">

Next, create the cache.manifest file in the same directory. With the following content.

CACHE MANIFEST
index.html
# version 1

the cache manifest is in a simple text format that lists all the resources that this page depends on. Our checklist only has one file. Also, we put a version number there in comments because the next time you’d want to change the checklist, in order for the browser to update the file in its cache, you’ll have to change the content of the cache manifest - so we’ll just update the version number when that happens. Next, there’s one more thing you have to do: in order for the browser to recognize the cache manifest as such, your web server must send with it a special header text/cache-manifest. If you or your web host is using Apache you can simply put the following line

AddType text/cache-manifest .manifest

inside the .htaccess file in the same directory - create it if it’s not there. There, try refreshing the page now. And then, to test offline mode, set your phone into Airplane mode, and then refresh the page again, it should still work.

There we have it. We built a checklist application for the iPhone using just HTML.

The Self Language is a descendant of Smalltalk, and is the language that introduced the concept of prototype inheritance. To get a historical perspective, I wanted to try it out, and luckily, it is still available online despite Sun killing the project in '95.

Install

To install Self, go to its download page and follow the instructions. In short, first, you need to install the VM by running the installer. Next, you need to download a snapshot image. There are two to choose from: the clean(spic 'n span) and the demo(kitchen sink). Next, double click on the image that you downloaded, and you should be good to go.

I am going to do a walkthrough using the clean image because I just want to try out some basic language features. When the environment - or "world" - finishes launching, you are greeted with a large gray space with a shell window on the top left, and a trash can on the top right.

So, let's play around and see how prototype inheritance works in Self. To create a new empty object, type

()

into the shell window and then click the "Get it" button. You should see a new expandable window that says "a slots object". If you expand it, it should look like

This is an empty object, the equivalent of {} in Javascript. 

Slots

Now let's add some attributes to it, except in Self, we call them slots. Right-click on the header of this window and select "Add Slot". You should see this

This textarea is where you would write the code for either a value slot or a method slot. The textarea preloads with some examples of what you can write here.

We are going to just add a read-only slot

Just so you know, a read/write value slot would be written as

name <- 'Thelonious'

When you are done, click on the thin green vertical bar on the left side of the window, and it should except the code. If your code has a syntax error, it will complain, and you'll need to try again. If you got it right, you should see this

For fun, let's make a few more slots. Repeat the "Add Slot" procedure, but this time add a hair slot and set it to 'dark and curly', add a plays slot and set it to 'piano'. If things go right you should see

Now, click on the "E" button to get an evaluation console. If you type

plays

into it and click "Get it", you should get the string 'piano' to come out

Okay, so it gets the value correctly.

Inheritance

Cool. Next we are going to create the inheritance link. First, we create an empty object again to represent the child.

Now, we add a special slot and call it parent*. 

We don't set it to a value so that it defaults to nil

Next, we need to link it to Thelonious. First click on the little button with two small dots just to the right of the nil. The nil object will come out and you'll see a link from your parent* slot to it.

In Self, any slot that ends in * is a parent link. So, in fact, it supports multiple inheritance! Anyway, we are close to completing the inheritance. Now just drag the link to Thelonious. If you got it, you'll see this

Now, to test that it worked, click on "E" in the child object and type

hair

Sweet! Now, we can override slots in the child, right?

Yup. While we are at it, we'll change the name to 'Thelonious Jr.' too.

Methods

Next, let's create a method. Let's create a greet method on the parent. The greet method will simply popup an alert dialog with the message. It does this using the report: method of userQuery.

userQuery report: 'Hi, I am ', name, ', I have ', hair, 
   ' hair and I play the ', plays, '.'

But, this won't work. Try running it - by clicking "Do it" will give you

It couldn't find the userQuery object within its slots. In Self, the normal convention is to have your object inherit the lobby object in order to have access to all the global variables(this is like the global object in Javascript, aka the public restroom). So okay, we have 'Thelonious' inherit lobby using a link called lobby*. To do this, we first get hold of the lobby object by typing in the shell

lobby

and clicking "Get it". Then, create a slot on 'Thelonious' called lobby* and like to it. You should end up with this

Now, if you try "Do it" on greet it should give you

And 'Thelonious Jr.' should also be able to do this

Sweet!

Comparison With Javascript

With a cursory look at the language Self, here are some of the differences between it and Javascript:

Have you ever wondered: what is the correct way to check if a Javascript variable is an Array?

Do a Google search and you will get a great variety of answers. And, unfortunately, there's is no correct answer. This is one of the sad things about Javascript, not only are there many varying implementations of the language, there are also many varying opinions about how things should be done.

Enough philosophizing and feeling sorry about the state of things. With this article, I will trying to give a comprehensive overview of the different techniques of checking-types in Javascript, the pros and cons of each and why they exist.

typeof operator

In the beginning, there was typeof. This handy operator gives you the "type" of a Javascript value:

typeof 3 // "number"
typeof "abc" // "string"
typeof {} // "object"
typeof true // "boolean"
typeof undefined // "undefined"
typeof function(){} // "function"

All is fine 'n dandy until

typeof [] // "object"

Huh? An array's type is object? I guess it is, if you want to get technical about it, but still, what the...

typeof null // "object"

Okay, now that's just wrong!

Also, typeof will return "object" for Dates, RegExp, user defined objects, DOM elements, and pretty much anything else. So, typeof is pretty good at distinguishing between different kind of primitive values, and distinguish between them and objects, but is completely useless when it comes to distinguishing between different kinds of objects - which includes arrays and nulls(WTF?!).

instanceof operator

The instanceof operator tells you whether a object is an instance of a certain type. The so-called "type" is a constructor. For example

function Animal(){}
var a = new Animal()
a instanceof Animal // true

Alternatively, you could make this check using the constructor property of an object

a.constructor === Animal // true

However, the constructor check has two problems. First, it does not walk up the prototype chain

function Cat(){}
Cat.prototype = new Animal
Cat.prototype.constructor = Cat
var felix = new Cat
felix instanceof Cat // true
felix instanceof Animal // true
felix.constructor === Cat // true
felix.constructor === Animal // false

The second problem is that it will bomb out if the object in question is null or undefined.

felix = null
felix instanceof Animal // true
felix.constructor === Animal // throws TypeError

[1, 2, 3] instanceof Array // true
/abc/ instanceof RegExp // true
({}) instanceof Object // true
(function(){}) instanceof Function // true

or does it?

3 instanceof Number // false
true instanceof Boolean // false
'abc' instanceof String // false

Okay, what is going on here? It turns out that instanceof does not work with primitive values. The primitive types in Javascript are: strings, numbers, booleans, null, and undefined - (Oh good! You can count them all on one hand!) Well actually, I should have said it does not work with primitives with the exception of null and undefined, because they are not an instance of anything, and so instanceof correctly returns false when either is used on the left hand side.

null instanceof Boolean // false
undefined instanceof Array // false

To top that off though, checking for the constructor property will work for the primitive types number, string and boolean.

(3).constructor === Number // true
true.constructor === Boolean // true
'abc'.constructor === String // true

This works because whenever you reference a property on a primitive value, Javascript will automatically wrap the value with an object wrapper, like so

var wrapper = new Number(3)

except you don't see this - it happens behind the scenes. The wrapper then will be an instance of - in this case Number - or a Boolean or a String depending on the type of the primitive value, at which point it can walk up the prototype-chain and get at the properties of the Number prototype, etc. So, for example, creating a wrapper manually will make the instanceof operator work

new Number(3) instanceof Number // true
new Boolean(true) instanceof Boolean // true
new String('abc') instanceof String // true

But doing that would be pointless because it requires you to already know the type of the value of which you are asking whether or not it is of the type that you already know it is.

Cross-window Issues of instanceof

It turns out that instanceof has another problem. It breaks down when you try to test an object coming from another window. You know? The ones that are created for each <iframe>, <frame> or popup window that you create. 

var iframe = document.createElement('iframe')
document.body.appendChild(iframe)
var iWindow = iframe.contentWindow // get a reference to the window object of the iframe
iWindow.document.write('<script>var arr = [1, 2, 3]</script>') // create an array var in iframe's window
iWindow.arr // [1, 2, 3]
iWindow.arr instanceof Array // false

Above, we created a variable arr inside the context of the iframe and set it to the array [1, 2, 3]. However, we get false when we ask whether it is a instance of Array. What is happening?!! Behold.

Array === iWindow.Array // false

The Array in the iframe is not the same Array as our Array! This is true for all built-in objects: there are two versions of all of them! Basically, we have parallel universes! OMG!

What this means is that an array created within the iframe is only an instance of the Array constructor within the iframe

iWindow.arr instanceof iWindow.Array // true

The same phenomenon happens with windows created using the open() function. It is because of this cross-window problem that the use of instanceof is somewhat limited and discouraged within the Javascript community.

Duck-Typing

Because neither typeof or instanceof are satisfactory, many resort to duck-typing. This means checking the behavior: if it looks like a duck and quacks like a duck, then it is a duck as far as I am concerned. Pretty sure I misquoted that...oh well.

So, using duck-typing, an isArray check might look like

// source: http://forums.devshed.com/javascript-development-115/javascript-test-whether-a-variable-is-array-or-not-33051.html
function isArray(obj){
    return (typeof(obj.length)=="undefined") ?
        false:true;
}

or 

// source: http://www.hunlock.com/blogs/Ten_Javascript_Tools_Everyone_Should_Have
function isArray(testObject) {
    return testObject &&
	!(testObject.propertyIsEnumerable('length')) &&
	typeof testObject === 'object' &&
	typeof testObject.length === 'number';
}

in jQuery, the function to check whether an object is a window is

isWindow: function( obj ) {
    return obj && typeof obj === "object" && "setInterval" in obj;
}

You could easily trick this function into returning true

$.isWindow({setInterval: 'bah!'}) // true

Clearly, the problem with this approach is that

Object.prototype.toString method

It turns out that, you can get type information about an object by using the Object.prototype.toString method.

Object.prototype.toString.call(3) // "[object Number]"
Object.prototype.toString.call([1, 2, 3]) // "[object Array]"
Object.prototype.toString.call({}) // "[object Object]"

This native method is rarely encountered normally because it's usually shadowed by another toString method lower down in the prototype chain(Array.prototype.toString, Number.prototype.toString, etc.). This method reliably differentiates between native types, however, will return "[object Object]" for all user-defined types

Object.prototype.toString.call(new Animal) // "[object Object]"

It does, however, work across different window contexts

Object.prototype.toString.call(iWindow.arr) === "[object Array]" // true

with one exception: different windows(as in popup window) in IE.

var pWindow = open("")
pWindow.document.write('<script>var arr = [1, 2, 3]</script>')
Object.prototype.toString.call(pWindow.arr) // you get "[object Object]" in IE; "[object Array]" else where.

This is strange because for iframes it works just fine, bummer! This method has become somewhat of a preferred way to differentiate native types despite the IE bug. Ehh, nobody uses popup windows anymore anyway.

Function.prototype.toString method

Yet another way to test for type information is by using the Function.prototype.toString method.

Function.prototype.toString.call((3).constructor)
// "function Number() {
//    [native code]
// }"

The method gives you the complete source of a function. In the case of native functions, it just says "[native code]" in the body. One could easily parse out the name of the function to figure out type of the object using this helper function

function type(obj){
	var text = Function.prototype.toString.call(obj.constructor)
	return text.match(/function (.*)\(/)[1]
}
type("abc") // "String"

This one will work for user-defined types too

type(new Animal) // "Animal"

this code has a problem wrt popup windows in IE just like instanceof. It's because when Function.prototype.toString is called with a constructor from another parallel universe, it can only discern the constructor as an object("[object Object]"), and thus rejects the argument and throws a "Function expected" error. This problem can actually be worked around by referencing the toString method indirectly

function type(obj){
	var text = obj.constructor.toString()
	return text.match(/function (.*)\(/)[1]
}

Now, it works for popup windows in IE too! This fix makes it susceptible to shadowing

Array.toString = function(){ return "function NotArray(){ }" }
type([1,2,3]) // "NotArray"

but still, I'd say this is pretty cool.

Now, let's return to user-defined types for a minute. With this approach, there's no way to distinguish between two different user-defined types with the same name

var f = function Animal(){ "something" }

var g = function Animal(){ "something entirely different" }
type(new f) // "Animal"
type(new g) // "Animal"

For this reason, this method is inferior to instanceof for user-defined types. Another seemingly obvious problem with this approach is performance, but I'd have to benchmark it(jsperf!) to make a real claim.

DOM Elements and Host Objects

So far, I have not mentioned type checking for DOM elements and host objects. That's because it's hard. With the exception of duck-typing, none of the methods mentioned above will work for all browsers. If you drop IE7 and below, however, you can actually get some of the things to work. The output below were created using Tutti

> var div = document.createElement('div')
> typeof div
Safari 5.0 => object
Firefox 3.6 => object
IE 7.0 => object
IE 8.0 => object
Opera 11.01 => object
> div instanceof Element
Safari 5.0 => true
Firefox 3.6 => true
IE 7.0 => Error: 'Element' is undefined
IE 8.0 => true
Opera 11.01 => true
> div instanceof HTMLDivElement
Safari 5.0 => true
Firefox 3.6 => true
IE 8.0 => true
IE 7.0 => Error: 'HTMLDivElement' is undefined
Opera 11.01 => true

First up, typeof is useless, that was expected. Next, everyone but IE 7 recognizes that a div is an instance of Element as well as an HTMLDivElement. In IE7, those constructors aren't even present. Next,

> Object.prototype.toString.call(div)
Safari 5.0 => [object HTMLDivElement]
Firefox 3.6 => [object HTMLDivElement]
IE 7.0 => [object Object]
IE 8.0 => [object Object]
Opera 11.01 => [object HTMLDivElement]

The result of Object.prototype.toString in IE - even IE 8 - is particularly unhelpful. What about

> div.constructor.toString()
Safari 5.0 => [object HTMLDivElementConstructor]
Firefox 3.6 => [object HTMLDivElement]
IE 7.0 => Error: 'div.constructor' is null or not an object
IE 8.0 => [object HTMLDivElement]
Opera 11.01 => function HTMLDivElement() { [native code] }

Function.prototype.toString: it gives us something useful for IE8, but every browser has a slightly different output.

Fun! Try another one? Allllllllllllllllrrrighty then!

> typeof window
Safari 5.0 => object
Firefox 3.6 => object
IE 8.0 => object
IE 7.0 => object
Opera 11.01 => object
> window instanceof Window
Safari 5.0 => ReferenceError: Can't find variable: Window
Firefox 3.6 => true
IE 8.0 => true
IE 7.0 => Error: 'Window' is undefined
Opera 11.01 => ReferenceError: Undefined variable: Window
> Object.prototype.toString.call(window)
Safari 5.0 => [object DOMWindow]
Firefox 3.6 => [object Object]
IE 8.0 => [object Object]
IE 7.0 => [object Object]
Opera 11.01 => [object Window]
> window.constructor
Safari 5.0 => function Object() {
    [native code]
}
Firefox 3.6 => function Object() {
    [native code]
}
IE 8.0 => [object Window]
IE 7.0 => undefined
Opera 11.01 => function Object() { [native code] }

With window it is just all over the place, none of these methods worked for all browsers. You can try testing out some other host objects if you want, but in general it doesn't look doable. However, in my testing, the XMLHttpRequest object and DOM and Text elements look doable using instanceof, if you can drop support for IE7 and below.

What We've Learned

Checking types in Javascript is a big mess. Although it's really not that hard to check for any one particular type, it is definitely not consistent across types, and you probably have had to make a lot of choices along the way. So it helps to know about all the different options. In an upcoming post, I will try to make all of this easier with a small piece of code. Stay tuned.

Sources

How many application windows do you have open right now? What about the number of browser tabs?

The Limits of the Multiple-Window Paradigm

The multiple-window user interface paradigm that we all know and love was invented at Xerox Parc. Both Apple and Microsoft used it in their products and now every computer user in the world lives it and breaths it. 

More recently, there was the rise in popularity of the tab-based user interface. In particular, every major browser now supports tabbed browsing. To me, this indicates that the multiple-window paradigm isn't working well. In particular, it just doesn't scale when there are many open windows. Let's back up: it's not the having of the windows themselves that don't scale, the OS is happy to open as many windows as you want

but it's you who don't scale. Human beings can only hold a maximum of 7 things in their head at any one time.

Strategies for Taming Many Windows

When you have lots of application windows open at the same time. What are some strategies for making sense of them?

Alt-Tab and Cmd-Tab

On Windows, the Alt-Tab keyboard shortcut cycles through all of your opened app windows on Windows. On Mac,  there's the Cmd-Tab shortcut, which rather cycles through all of your opened applications; then the Cmd-` shortcut cycles through all your windows within the current application. In practice, Alt-Tab or Cmd-Tab switching only works well if you are switching between 2 or 3 windows at most. Also, both of these implementations appear to be inadequate for power users for there exists the Alt-Tab Replacement Task Switcher for Windows and Witch for Mac.

Taskbar and the Dock

On Windows XP, the Taskbar lists all opened application windows and lets you switch between the windows with a click. If there are too many of them, similar windows will be grouped into one - clicking on the item will slide out a list from where you can choose from within the group. In Windows 7, there's a new interface which I have only seen, not used, so I won't comment. 

On Mac, there's the Dock. In contrast to the Taskbar, the Dock does not show all open windows. Instead it lists the currently opened applications as well as the currently minimized application windows. Neither the Dock or Taskbar scale up well when there's a large number of windows.

Exposé

On Mac, there's something called Exposé, which is yet another indication that neither the Dock or Cmd-Tab are cutting it

Exposé shows all your open application windows on the screen by scaling them down to the point that they can all by laid out side by side together in a sort of mosaic. You can click one of the thumbnails in the mosaic to switch to it. Exposé works well up to a point, but if you have too many windows open

 you won't be able to make out which is which because the size of each window in Exposé will too small to read.

So, we have seen three strategies for handling many windows, but not one of them is up to the task.

Tab-Based Interfaces

At this point in time, all major web browsers have a tab-based interface. I don't know when exactly tabs first came into the scene. I want to say it was popularized by Firefox, let's pretend that it was. I am not entirely convinced that they are better than multiple-windows, but they seem to have taken over as the standard for web browsers and even text-editors and IDEs. These are some ways in which tabs may be superior than windows

1. Switching between tabs is easier because all tabs are readily readable and available at the top, whereas windows can easily occlude each other and although the Windows Taskbar has a similar function as tabs, it can easily fill up to the point of unmanageable if you have many application/windows open.
2. Tabs live within the space of that window only, isolating them from other applications and windows. You could take advantage of this to better organize your stuff or just to have a clean slate to work with despite the other mess lying on your computer.

Tab is the New Window

It is not uncommon nowadays to see people having more than 10 tabs open in their browser. My typical usage pattern is this: I usually start out with one or two tabs that are opened all the time, such as my todo list and email; then as I need to research something or am distracted by a link I'll add new tabs to the mix. This continues until I have too many tabs(my threshold is about 10 or so), at which point I decide to either create a new window and start over again or clean up the existing tabs. If I go for the tab clean up, I will go through each one, decide whether it's save-worthy, save to a bookmarking service if so, or close the tab if not.

It is as if I need to do periodic garbage collection as part of my web browsing experience. This. Is. Not. Okay.

People even less disciplined than myself do tab cleanups less frequently than I, and they come to rely on the state of the browser. If the browser crashed and lost its state, they would get upset, because they'd lost track of their work. The fact that most browsers now also restore their states across restarts helps them, but also further perpetuates this behavior.

Tabs may or may not be a improvement to multiple windows, but they do not scale either.

Multiple Windows and Tabs are Overrated

So if there's no way to work effectively with many windows or tabs, what is a user to do? Reduce, reduce, reduce. Most of the time, multiple windows and tabs are just not necessary. Some evidence of this are

• many non-tech-savvy computer users - who don't even know about tabs - maximize their windows by default
• smart phones and tablets of today don't have multiple windows and people - both tech-savvy and non-tech-savvy - find them usable
• overlapping windows might look cool, but are pretty much useless

The only time when multiple windows are necessary is when you have a complex task at hand. We will talk about that a little later.

Why We Need So Much Stuff Open

Why do we - the computer users of today - have the tendency to open up an abundance of windows and tabs? Here is me trying to explain

• slow start of applications: might as well leave them running so that we don't have to wait for them to start the next time around.
• some apps just run in the background because they have to constantly check for or be notified by external events and react to them(chat apps, twitter, facebook, calendar reminders, mail notifiers, etc).
  
• non-linear nature of thought processes: thoughts can easily change direction, either because of external events(a phone call, a Facebook reply, someone walking into your office) or internal events(a great new super-duper awesome idea).
• sometimes, to efficiently perform a particular task, you simply have to switch rapidly between a small number of windows. For example, you are writing a program and you have constantly switch between your editor and some terminals from which you compile your code, run your code, debug your code, and so forth.

I'll go into more detail about each of these as well as strategies to counter them so that you don't have to go insane.

Slow Start of Applications

There is no escaping the fact that when an application is already in memory, it will start faster because to start it from scratch will mean reading from the disk, which is way slower than reading from memory. Furthermore, when you close the application, you usually lose the application state. So if you restart the program you'd have to start over: for example, re-opening files or projects or a re-navigating the app in a specific way. For these reasons, many people opt to just leave applications open even after they are done using them - this will allow them to switch back to the application more quickly should they ever need to use it again. In my experience, however, application start times have improved greatly in recent years both due to better hardware and better written software, so app start time is now much less of a problem than before. Many applications even restore to their previous state on startup (ex. Firefox, Chrome, Textmate), so the problem with application state is mitigated as well.

Background Applications

Some applications are simply designed to sit around indefinitely and alert you whenever they feel like it. An instant messaging application is one such application - it waits for incoming messages, and alerts you when it happens. There's nothing really you can do about these applications being open other to stop using them altogether - for some apps, this is not a bad idea at all. My recommendation is to use these applications very judiciously. For alert-based applications such as GMail and GCalendar Notifier, make sure you set it up so that only the events that truly deserve your attention trigger alerts. As an example, I personally have mail alerts disabled, but the inbox number displays in my menu bar so I can check it when I want to. Another example is, if you use Growl(Mac only) for notifications, you can configure which applications you allow alerts to come from.

Non-linear Nature of Thought Processes and Stacks

People's minds wander around constantly, this is what makes us creative and adaptive. However, it also makes us unfocused and scatterbrained. If you allow yourself to mindlessly wander to wherever you please, you won't get anything done. Furthermore, it's been shown that focusing on what you are doing directly increases your happiness(for more on that, you want to read Flow: the psychology of optimal experience). So, although thoughts tend to be non-linear, you want to establish some form of structure so as to prevent it from going astray. A logical solution is a stack. You first start with a top-level task; if there is something else you need to do - a subtask(research an API), or just a general digression(check twitter) - you push that task onto the stack; when you are done with the subtask on the top of the stack, pop the stack and return to the previous task. Neither the tab-based UI or the multiple-window paradigm directly supports this stack mode of operation that I've described. What that means is you are going to have to be disciplined and always close the window or tab behind you when you are done with a subtask.

Rapid Switching and Registers

There are certainly times you find yourself in a situation where you have to constantly switch between two or three overlapping windows. In contrast to the stack, I will call this mode of operation the registers mode of operation, because like registers in a CPU, you have to access a small number of things very frequently. If the windows in your "register" are overlapping, you could be in a sea of hurt because when the content of a large area of your screen completely changes, it takes a second or two to orient yourself to the new content. When you are switching windows rapidly, those one or two seconds really add up. 

You can greatly ease the pain by tiling the windows in a non-overlapping way. 

A prime example of this is the IDE. Most IDEs divide the available real estate up into tiles, which allows you to see all the pieces of information all the time. Another example is a graphics editor - which includes a tool bar, a tool options panel, a layers panel, the image to be edited, and more. These two examples indicate that the register mode of operation is often needed for highly complex tasks. Note: when you are using one application that satisfies all your needs, you don't need multiple windows anymore. It's only when you don't have an application specifically built for your task that you need to use the window tiling strategy.

Previously, we made the assumption that you only have a small number of windows in your register. What if there are more than a few windows you need to switch between? Again, people can only hold about 7 things in their head, so you are not likely going to work well with a large number of windows anyway. But, if by chance you are a genius and can handle it, you can get a bigger monitor or use more monitors like Trader Mike.

Experiment to Try

I've said some bold things: am I full of bull? You can test it out yourself. Try this experiment

• Never leave any more than one browser tab or  browser window open
• Only leave open the applications that you are currently using. When you are done with a task, close out any applications that you are no longer using.

Do this for a minimun of 48 hours on regular work days and see if you are missing anything. At first, this may take some getting used to, here are some tips to smooth out some rough edges

• If you are using applications that can restore their state, configure them to do so.
• Many advanced web applications(like GMail) can restore their previous state as well and work perfectly with the back button - so there's no reason for you to have to leave them open all the time. 
• If you need a reminder to return to something, rather than leaving a tab or window open, use a todo list. If you don't have a todo list app that you already use, you can just use a text editor. You should be able to open and close this todo list quickly.
• If you can afford to, stop using applications which take a long time to start or do not restore their previous state.

If it doesn't work, I'll give you your money back. That's right, I'll pay you back in entirety the amount of money that you paid me, no questions asked ;) Happy working!

You may remember the LOGO programming language from the old days of Turtle Graphics. If you are like me, you probably remember drawing polygons and stars by typing a command like:

repeat 5 [forward 100 right 72]

This draws a pentagon, and with different numbers plugged in the 3 different places, you can get a infinite variation of shapes.

But it turns out LOGO is more than just forward, turn left, turn right, and repeat - it actually is a pretty powerful language having its roots in LISP.

Much like LISP, the list data type is central to the language. As an example, let's write a sumlist function which just sums the numbers in a list. A list is written like

[1 2 3 4]

So calling the function looks like

print sumlist [1 2 3 4]

This should print 10 as the result.

Like LISP again, LOGO uses linked lists, so the most basic way to iterate a list would be to use tail recursion. We can write sumlist like this

to sumlist :list
	ifelse equal? 0 (count :list)
		[0]
		[(first :list) + (sumlist butfirst :list)]
end

Declaring a function has a nice down-to-earth syntax

to func :param1 :param2 ... statement1 statement2 ... end

The ifelse function simulates an if-else statement, taking 3 parameters, the test condition, a statement block to execute for true and another for false. So here we are saying if the list is empty, return zero, otherwise return the first element of the list plus the sum of the rest(butfirst) of the list. Notice that the statement blocks passed as the second and third arguments to the ifelse function are nothing more than lists. Lists, in addition to acting as literal lists of element, also double as lazily evaluated statement blocks.

Writing recursive functions is usually kinda tedious like the sumlist function that we wrote above, but if you knew a little about functional programming, you know that you can use foldr or reduce to simplify your code. Well, you can do that in LOGO too

to sumlist :list (reduce "sum :list 0) end

Sweet! Now we have a one-liner. You can read up on foldr or reduce if you don't know it - I won't explain it in depth here. Essentially, the reduce function allowed us to refactor our recursive function into a much more succinct form.

Great! But we aren't done yet. There's a yet simpler way to write the function. It turns out that there's already a sum function in UCBLogo - perhaps the most popular implementation of LOGO. It does not act exactly the way we want though. You can sum two numbers together

print sum 1 2

prints 3.

But if you try adding more parameters it'll just ignore them

print sum 1 2 3

still prints 3.

Turns out you can use variable number of parameters, you just have to write it differently

print (sum 1 2 3)

prints 6. This is called the LISP-style call syntax. Notice that a function has a natural arity(number of parameters). In the case of sum the natural arity is 2, but the arity can be changed if you use the LISP-style call syntax. Using the natural arity of the function for lookahead is the reason why LOGO code doesn't have as much parentheses as LISP code. You can write

forward 100 right 45 forward 50 left 80

There is no ambiguity as to what is the correct grouping for this expression because each of the functions forward, right, left take one parameter, and the interpreter uses that information for disambiguation during parsing.

Anyway, I digress. Now, back to the sum function. It turns out we can also call the function using the apply function, much like Javascript's Function.prototype.apply. And so, our final version of sumlist looks like

to sumlist :list apply "sum :list end

Nice! apply takes two arguments: the name of the function to call and the parameter list. We prepend a double quote to sum to make it a string literal to prevent it from being applied as a function.

There's a counterpart for Function.prototype.call in Javascript too, it's called invoke.

print (invoke "sum 1 2 3)

But like Javascript's call() it's also less useful than apply.

Going Further

Joshua Bell wrote a LOGO interpreter in Javascript. That's where you'd go if you want to try out some LOGO right away. Alternatively, download UCBLogo.

The problem of Javascript coders often having to deal with more than the desired number of nested callback functions have never really went away. My complaint has been stated not long ago. Lately, with the raise of node.js, the complaints seemed to have gotten louder, or just more numerous. At JSConf EU 2010, there were no fewer than 5 talks addressing this issue, each in their own unique way. 

Generators

One thing that was brought up over and over again in Kyle's thread is generators. My take is this: generators have existed in Spidermonkey ever since Firefox 2, so if you are open to new language features, generators have already been around the block, we just have to get it into the standard, at which point I believe node.js - and just Javascript programmers in general - can really benefit. I have long been using generators in Python, so I know that they are very powerful. All of this motivated me to go deeper and see how far it can go in the Quest for Fewer Nested Callbacks.

First, the Punchline!

Let's see the punchline now because it may take a while before we can get through all the steps necessary to arrive at it: with the help of generators and a bit of support code, this(code taken directly from Kyle's post)

setTimeout(function(){
   xhr("/something.ajax?greeting", function(greeting) {
      xhr("/else.ajax?who&greeting="+greeting, function(who) {
         console.log(greeting+" "+who);
      });
   });
}, 1000);

can be written as

yield sleep(1000)
var greeting = yield xhr('/something.ajax?greeting')
var who = yield xhr('/else.ajax?who&greeting=' + greeting)
console.log(greeting + ' ' + who)

The supporting function

function xhr(url, callback) {
   var x = new XMLHttpRequest();
   x.onreadystatechange = function(){
      if (x.readyState == 4) {
         callback(x.responseText);
      }
   };
   x.open("GET",url);
   x.send();
}

almost remains unchanged, all it needs is to be wrapped like so

function _xhr(url, callback) {
   var x = new XMLHttpRequest();
   x.onreadystatechange = function(){
      if (x.readyState == 4) {
         callback(x.responseText);
      }
   };
   x.open("GET",url);
   x.send();
}function xhr(url){   _xhr(url, (yield Continuation))   yield Suspend}

and, sleep() is implemented as

function sleep(ms){
    setTimeout((yield Continuation), ms)
    yield Suspend
}

Are you intrigued? Read on, then.

Gentle Introduction to Generators

What are generators? How do they work? How can I use them?

Let's start with "How can I use them?". You have to be running Firefox 2 or above, or alternatively you can download Spidermonkey by itself.

For my code samples I'll assume you are using Firefox.

Next, you have to use type="application/javascript;version=1.7" in your script tag. I guess Mozilla was sheepish about this feature when they released it, given that it introduced a new keyword.

So, a hello world example for generators would be:

<script type="application/javascript;version=1.7">
// This is a generator function
function naturalNumbers(){
    var i = 0
    while (true){
        yield i++
    }
}
var N = naturalNumbers() // N is now a generator
console.log(N.next()) // prints 0
console.log(N.next()) // prints 1
console.log(N.next()) // prints 2
// and so forth
</script>

First things first, a generator function is not the same as a function. Repeat after me: a generator function is not a function. Within a generator function, you have yield statements; within a function, you have return statements - you cannot have both.

The generator object has a few methods, here we are only demonstrating next() - which executes the code within the generator function until a yield statement is reached, and returns the value being yielded. If you call next() on it again, it will continue from where it left off, and once again execute till the next yield is reached. In our natural numbers example, since we are yielding the counter within an infinite loop, we can keep calling next() on the generator object to get the next number forever...

Receiving Values

It turns out that in addition to yielding values, the yield statement can also receive values(proud of myself that I avoided using the word "return" in this sentence).

For a yield statement to receive a value, the holder of the generator must call the send() method with a value instead of the next() function

function makePrinter(){
    while(true){
        var message = (yield)
        console.log(message)
    }
}
var printer = makePrinter()
printer.next() // You may not send a value to a newly created generator
printer.send('Hello')
printer.send('I am sending this message')
printer.send('into the generator')
printer.send('and it be received and get printed')

Here we created a printer generator whose job is only to print the objects that it receives from the yields. You can't send in a value for the first invocation of the generator because it hasn't had a chance to yield yet, but after that, you can send as many as you want, since it yields infinite times.

As you can see, we are switching back and forth between two separate threads of execution(but not Threads ;).

Trampolining

Now that you understand generators, the next step is to put it together to get rid of our nested callbacks. To do that, we need to know a technique called trampolining. Neil Mix's article has some brilliant code that shows you how to do it in Javascript, but it was David Beazley's gentle example in Python that helped me understand what's going on.

Let me translate his code to Javascript, and put in some comments for ya

function add(x,y){
    yield x + y             // yield the result of addition
}
function main(){
    var r = yield add(2,2)      // yield the result of add(2,2): a generator
    console.log(r)
    yield
}
function run(){
    var m = main()
    var sub = m.next()      // start the code execution in main()
                             // sub is now generator from calling add()
    var result = sub.next() // start execution of sub
                             // result now has the value of 2 + 2: 4
    m.send(result)           // send back to generator
}
run()

The main feature of trampolining is that a value yielded by a generator is yet another generator, such is the case on this line

var r = yield add(2,2)      // yield the result of add(2,2): a generator

In this example the thread of execution is bouncing between 3 different contexts, namely the run() function and the add() and main() generator functions. We started within run(), bounced to main(), then back to run(), then to add(), then back to run(), then back to main() again, and then finally exiting in run() again.

Here's a picture so we can visualize what's happening

But, right now the run() function is inflexible. We can generalize it to handle arbitrary levels of nested generator execution - with a stack

function run(gen){
    // is object a generator?
    function isGenerator(obj){
        return String(obj) === '[object Generator]'
    }
    // last element of array
    function last(arr){
        return arr[arr.length - 1]
    }
    var stack = []
    var retval = gen
    try{
        while (true){
            if (isGenerator(retval)){   // if a generator
                stack.push(retval)      // push it onto the stack
                retval = undefined
            }else{
                stack.pop().close()     // if we got a normal value
                                        // pop the stack and
            }
            gen = last(stack)           // get the generator at top of the stack
            if (!gen) break
            retval = gen.send(retval)   // send retval to the generator
                                        // if retval is undefined, it acts just
                                        // like next()
        }
    }catch(e if e === StopIteration){
        console.log('Program ended.')
    }
}

We have a stack which starts out containing the generator from which we are starting execution - gen. Then, we keep on executing the generator at the top of the stack. If the received value is also a generator, we push it onto the stack and keep going; if we receive a normal value, then we pop the generator off the stack and, on the next iteration of the loop - send the value to previous generator one level down in the stack.

To call the new and improved the run() function you pass it the entry level generator like so

run(main())

Let's take the same example again, but executing with the generic run() function instead. This time, let's visualize it as a stack. First we start with main() at the bottom

next,

var r = yield add(2,2)

add(2, 2) is pushed onto the stack, because it is a generator. The parameters x and y are both assigned to 2 inside the scope and also go on the stack.

add() then executes and 

yield x + y

yields a numerical value: 4. Because, this is not a generator, we pop() the stack, then send the 4 back to main()

var r = yield add(2,2)

where 4 is assigned to r. 

main() then prints the value via console.log and then

yield

again, which ends the execution.

Wait, I've Seen That Before!

This... stack, it looks almost like... an execution stack! The interpreter maintains a stack when it's executing code and handling the execution of function calls - and we've just reimplemented it using generators.

To see it another way, the only difference between the trampoline style code and normal functional code is the use of the yield statements. If you take out the yields - and substitute return when appropriate, you'd have

function add(x,y){
    return x + y
}
function main(){
    var r = add(2,2)      // yield the result of add(2,2): a generator
    console.log(r)    return
}

Now that we have a generalized run() function that handles the stack generically, we can handle recursion

// the Fibonacci sequence using recursion - don't try this at home!
function fib(n){
    if (n == 1 || n == 2)
        yield 1
    else
        yield (yield fib(n-1)) + (yield fib(n-2))
}
function main(){
    console.log(yield fib(10))
}

This actually works!

Wrapping Asynchronous Execution

Okay, that's all fine and good, but we still haven't address the problem of making asynchronous code less onerous. In order to tackle that problem, we need to do a little bit more.

By keeping a stack of all of the generators we have in progress, we can restart them back at any time. However, we need to be able to suspend the execution of a generator if we are waiting for an asynchronous response. We also need to pass a function as the callback handler for the async function call, only by which can we know when to resume execution of the thread.

The solution is demonstrated by the implementation of sleep()

function sleep(millis) {
    setTimeout((yield Continuation), millis)
    yield Suspend
}

Continuation and Suspend are special constants - that we created - used as signals to run().

Here's how this works:

(yield Continuation)

will receive a function as a callback handler to setTimeout. Let's call this function the continuation.

yield Suspend

will suspend the execution of this generator, and therefore also suspending this thread of execution until the continuation has been called by setTimeout(). When the continuation eventually gets called, it will resume execution of this generator, which starts back up again after the line

yield Suspend

Our new run() function that handles all of this looks like

function run(gen){
    function isGenerator(obj){
        return String(obj) === '[object Generator]'
    }
    function last(arr){
        return arr[arr.length - 1]
    }
    function startBouncing(retval){
        try{
            while (true){
                if (isGenerator(retval)){
                    stack.push(retval)
                    retval = undefined
                }else if (retval === Suspend){
                    break                       // to suspend execution:
                                                // just break out of this
                                                // while-loop.
                                                // we can later resume
                                                // by re-starting another
                                                // while-loop by calling
                                                // startBouncing() again
                }else if (retval === Continuation){
                    retval = startBouncing      // send startBouncing
                                                // back as the callback
                                                // handler to the async
                                                // function call
                }else{
                    stack.pop().close()
                }
                gen = last(stack)
                if (!gen) break
                retval = gen.send(retval)
            }
        }catch(e if e === StopIteration){
            console.log('Program ended.')
        }
    }    
    var stack = []
    var retval
    startBouncing(gen)
}

We've refactored the while-loop inside of a function: startBouncing(). When we need to suspend, we just break out of the while-loop. When we need to resume, we just call startBouncing() to start the while-loop all over again. All the while we still have the stack in tact. The callback handler we send as the continuation is none other than the startBouncing() function. Notice that startBouncing() also takes a retval as argument. This enables us to send the first argument of the callback back to the generator, as the XHR example shows

function _xhr(url, callback){
    var xhr = new XMLHttpRequest()
    xhr.open('GET', url)
    xhr.onreadystatechange = function(){
        if (this.readyState == 4){
            // send the responseText as the first arg of the continuation
            callback(this.responseText)
        }
    }
    xhr.send()
}
function xhr(url){
    _xhr(url, (yield Continuation))
    yield Suspend
}

Because we are passing the responseText as the first argument to the callback(the continuation) - by our made up convention - it will be the value that's sent back to the caller of this generator function. So

var responseText = yield xhr('/something.ajax')

Just works!

Adding Back Exceptions

Async-style calls don't really throw any exceptions. That's because if there were problems with the request, you could only be notified asynchronously - the original execution has already past! However, now that we have something that looks like synchronous code again, we can put exceptions back into play. We will use the convention that if an instance of Error is passed as the first argument of the continuation, then we will throw it. Thus for our xhr function

function _xhr(url, callback){
    var xhr = new XMLHttpRequest()
    xhr.open('GET', url)
    xhr.onreadystatechange = function(){
        if (this.readyState == 4){
            if (this.status === 200)
                callback(this.responseText)
            else{
                var ex = new Error("XMLHttpRequest Error: " + 
                    this.statusText + ': ' + this.status)
                // pass in an error object to the continuable to throw it
                callback(ex)
            }
        }
    }
    xhr.send()
}

To throw an exception from within a generator you actually have to call the throw() method on the generator object. We just need to add an extra else-if inside of our big if statement inside of the while-loop in run()

else if (retval instanceof Error){
    stack.pop().close()
    last(stack).throw(retval)
}

Now we can get exceptions throw from the xhr() generator function

function main(){
    try{
        var result = yield xhr('/doesnotexist.ajax')
        console.log('blah')
    }catch(e){
        console.log('exception caught: ' + e)
    }
}

Conclusion

I think the trampolining technique is very compelling, perhaps even more compelling than the continuables in fab.js. The only thing we need is support for generators in more engines. As far as I know, Spidermonkey and Rhino are the only 2 that support it right now.

Source Code

You can download all of the code examples shown in this post.

References

Cough, cough...

Have you ever wished that the Firebug console or <insert your favorite Javascript Shell> could execute the piece of Javascript you typed in on IE, or maybe some other browsers as well - at the same time?

Well, now you can! Now there's Tutti - a Javascript Shell that will lets you execute Javascript on multiple browsers - all at the same time!

Here's how it works: to get started, 

1. Open tuttijs.com in your browser
2. Create a new room (click).
3. Copy-n-paste the URL from your current browser window to another browser of your choice, say, IE 8.
4. Repeat step two for each browser you you want to test.
5. Type in some Javascript, hit ENTER, and see them results from all your browsers!

Tutti uses Socket.IO, node.js, and WebSocket technology - it's so just cloud™!

Tutti supports on all major browsers, including

• Firefox 3.6 and 4
  
• Chrome 8.0
  
• Safari 5.0
  
• Safari 4 Mobile for iPad
  
• Opera 10
  
• Internet Explorer 6, 7, and 8
  

Tutti is open source, but that's not all, it's also hosted on GitHub so you can download it and run it on your own machine, or better yet: fork it and hack on it to your heart's content!

Try it now!

To try it go to tuttijs.com, or get the source at http://github.com/airportyh/tutti. Remember dependencies such as Socket.IO-node, ExpressJS, node.js are installed separately.

Update: I've changed the domain to tuttijs.com. The old domain is still accessible though.

Update: for those interested in using this for Javascript testing, I have created a new tool called [Testem](http://tobyho.com/2012/06/24/testem-interactive-js-test-runner/).

Finally figured out how to run multiple versions of Firefox simultaneously. 

First, you need to create some profiles, one for each Firefox version you want to run. Run

<path-to-firefox>/firefox-bin -ProfileManager

On Mac that's usually:

/Applications/Firefox.app/Contents/MacOS/firefox-bin -ProfileManager

Doesn't matter which version you use to open the profile manager because the profiles are shared between all the versions, and so you only have to create the profiles once. I called my profiles: FF4, FF3, and FF2 respectively.

I installed my different versions under these locations

Once you have the profiles created, you can launch each version like such:

/Applications/Firefox4b.app/Contents/MacOS/firefox-bin -P FF4 -no-remote &

for Firefox 4 beta,

/Applications/Firefox3.app/Contents/MacOS/firefox-bin -P FF3 -no-remote &

for Firefox 3, and

/Applications/Firefox2.app/Contents/MacOS/firefox-bin -P FF2 -no-remote &

for Firefox 2, just cuz I can.

Now of course, that's quite a lot of typing to have to do each time you want to launch the browser so I put those one-liners into handy little shell scripts which you can do too.

Happy happy joy joy!

For other platforms it's more or less the same thing, just the installation paths would be different.

Programmers have been plagued by having to write numerous checks for null values ever since the dawn of time. Consider this example,

var customer = database.get(id)
var customerLastName = customer.name.last

What if I told you that, any of customer, customer.name, and customer.name.last could be null at runtime? And if any of them are null just set customerLastName to "Unknown". You’d probably do something like

var customerLastName = "Unknown"
var customer = database.get(id)
if (customer && customer.name && customer.name.last){
    customerLastName = customer.name.last
}

This is an awful lot of repetitive code, and you really don’t want to be writing it over and over again. But, what’s worse than having to write it, is actually having to read it later on.

To see the amount of repetition in the above code, let’s break down the word frequency. The top repeated words are

• customer: 5
• name: 3
• last: 2
• customerLastName: 2

If you count phrases too,

• customer.name: 3
• customer.name.last: 2

There are actually numerous hacks out there already dedicated to solving this problem for ruby, groovy, and other various programming languages.

In this post, I am going to investigate two approaches to tackling this in Javascript.

Approach 1

Because null isn’t an object in Javascript, approaches like andand won’t work. So, what do we do when we want to extend something but can’t modify it? Right! We wrap it! This approach is called NullSafe. Basically, like jQuery, you wrap the object you want to query, and then chain method calls to it until you get the result you are looking for. At the end, you have to unwrap it to get the computed value. What I came up with is this:

var customer = database.get(id)
var customerLastName = NullSafe(customer)._('name')._('last').val() || "Unknown"

Actually, I made it a little more powerful than that, even. In addition to getting an object’s properties, you can also call methods:

var customerLastName = NullSafe(database).$('get', id)._('name')._('last').val() || "Unknown"

Then I added just a bit more convenience with the variable length arguments for getting a chain of properties:

var customerLastName = NullSafe(database).$('get', id)._('name', 'last').val() || "Unknown"

How is this? Is this good? The syntax takes a little getting used to, but the advantage is that you only have write each thing just once, rather than the big repetitive mess you saw above. Also, chaining allows you to write everything in one line.

The implementation of NullSafe is pretty simple too, all but 30-plus LOC,

function NullSafe(obj){
    function NullSafe(obj){
        this.obj = obj
    }
    Wrapper = NullSafe
    var proto = Wrapper.prototype
    proto.call = proto.$ = function(){
        var name = arguments[0]
        var args = Array.prototype.slice.call(arguments, 1)
        var obj = null
        if (this.obj){
            var func = this.obj[name]
            if (this.obj && func){
                obj = func.apply(this.obj, args)
            }
        }
        return new Wrapper(obj)
    }
    proto.get = proto._ = function(){
        var curr = this.obj
        for (var i = 0; i < arguments.length; i++){
            if (curr != null){
                curr = curr[arguments[i]]
            }
        }
        return new Wrapper(curr)
    }
    proto.val = function(){
        return this.obj
    }
    proto.toString = function(){
        return String(this.obj)
    }
    return new Wrapper(obj || this)
}

But then you might wonder why in the world I didn’t just use a try-catch block?

var customerLastName = "Unknown"
try{
    customerLastName = database.get(id).name.last
}catch(e){}

Approach 2

As you saw, the try-catch approach isn’t so bad. It is a bit verbose, and spans multiple lines, but we can fix that.

var customerLastName = $try(function(){return database.get(id).name.last}) || "Unknown"

Pretty nice! Although the actually code is slightly longer than NullSafe, this is easier to understand because within the inline function you are just writing what you would have normally written anyway if you hadn’t had to do the null checks.

The implementation is even simpler,

function $try(func){
    try{
        return func()
    }catch(e){
        return null
    }
}

Performance

I normally don't prematurely optimize, but with jsperf.com, I thought I’d be fun to compare. Intuitively, $try should be faster because it’s doing less, but then again, exception handling can be slow.

I created two separate tests, one in which the chain would have values all the way through to the end, and another in which it would null-out early.

Results

The results were - drum roll please - $try was significantly faster in almost all browsers, the only exceptions where is the null-out early case for Chrome and Firefox, where it was only slightly slower - 20% - 40%. But in all the other cases, $try was faster, in some cases, much faster - almost 7 times in Safari.

Conclusion

With that, I will conclude that $try is my preferred approach, given that it is easier to implement, produces easier to understand code, and executes faster that NullSafe. 

If you didn’t already know, Javascript functions double as object constructors. For example, to simulate a class in object-oriented programming, you would write

Note: I avoid using semicolons because I am a heretic! Mislav argues my point for me here.

Anyway, now that you have a function, you’d use the new statement to create a Person

Just to be sure that bob is indeed a Person, we can ask

You could also call Person as a function - without the new,

but that just returns undefined. Also, you really don’t want to do this, because you’ve just unintentionally created a name global variable

Uh… that’s not good, especially if I already had a variable called name, it would have been overwritten. The reason this happens is because when you call a function as a function(without new), this is set to the global object - in the browser, this is the window object, see

So… if you want to write a constructor, use it like a constructor, if you want to write a function, use it like a function, don’t mix and match.

Someone pointed out though, that you can prevent this polluting of the namespace(those are just big words for creating global variables) by using this trick

What this does is:

1. Check whether this is really a Person - which it would be if called using new.
2. If it indeed is a Person, go on your merry way.
3. If it is not a Person, use a new to create a Person - the correct way, and return it.

This allows calling it as a function to return a Person, and it doesn’t pollute the namespace.

But what is surprising is that calling it with new still works too

Why? It turns out that if you return a value in a constructor, Javascript will honor it, and return it as the newly created object when you use a new. But, you might be thinking, can I return a non-Person? That would be kind of like lying.

So, I ask for a Person and I get a Cat? Well, in Javascript it can happen. You can even return an Array.

There are limits to this madness though: if you return a value of a primitive type, this won’t work.

Number, String, Boolean, are all primitive types. If you return one of these types of values from a constructor, it would be ignored and the constructor would go back to its normal behavior of returning the this object.

Methods

In the beginning, I said that functions double as constructors, well, actually, they more like triple. Functions also act as methods.

If you know OOP, you know that methods are the behaviors of the object - what the object can do. In Javascript, methods are just functions attached to an object - you can create methods simply by creating functions and assigning them to the object

Bob can now say “Hi”

Actually, we can attach methods to objects without even bothering with this constructor crap and instead create an object out right

This would work just as well. Or, if you prefer, write it as one big object

So, why are we bothering with constructors in the first place? Answer: inheritance.

Inheritance and the Prototype

Right, so inheritance. You know inheritance, right? You know how in Java, for example, you can have one class inherit another and automatically get all the methods and variables of the parent class?

Well, in Javascript, we have the same thing, just different. For starters, we don’t even have classes! Instead, we have something called the prototype. Here’s how we write the equivalent of the above Java code in Javascript

What’s this prototype? That’s just a bunch of gibberish!

Javascript is different from traditional object-oriented languages in that it uses prototype inheritance. In a nutshell, prototype inheritance in Javascript works like this:

1. An object has a number of properties. This includes any attributes or functions(methods).
2. An object has a special parent property, this is also called the prototype of the object(__proto__). An object inherits all the properties of its parent.
3. An object can override a property of its parent by setting the property on itself.
4. A constructor creates objects. Each constructor has an associated prototype object, which is simply another object.
5. When an object is created, it’s parent is set to the prototype object associated with the constructor that created it.

Okay! Now that you understand everything there is to know about prototype inheritance, let’s look at our Cat example more closely and break it down.

First, we create a constructor for Mammal

At this point, Mammal already has an associated prototype

Let’s create an instance

Now, let’s verify the second law of prototype inheritence(it’s just the second bullet from the list)

Next, we add the breathe function to the prototype of Mammal

At this point, mammal the instance can breathe

because it inherits from Mammal.prototype. Next,

Cat constructor is created and we set Cat.prototype to a new instance of Mammal. Why do we do this?

because now any cat instance inherits Mammal and will therefore be able to breathe as well. Next,

Ensures that cats know that they are cats:

Each time you create a new instance of Cat, you create a 2-level chain, in that garfield is now parented by Cat.prototype which, since it is an instance of Mammal, is in turn parented by Mammal.prototype.

Now, guess who’s the parent of Mammal.prototype? Yeah, you guessed it, Object.prototype. So actually, it’s a 3-level chain

garfield -> Cat.prototype -> Mammal.prototype -> Object.prototype

You can add properties to any of garfield’s parents, and garfield would magically gain those properties too, even after garfield has already been created!

You can ask whether he has a given property

and you can also distinguish between own properties vs inherited properties

Setting Methods on the Prototype

Now that you really understand prototypes, let’s go back to the very first example of defining methods on objects

This is actually not the optimal way to do it. A better way is to define the method on Person.prototype

Why is this better? Anyone? Anyone? Beuller?

In the first version, each time you create a person, a new sayHi function will be created for him, where as in the second version, only one sayHi function is ever created, and is shared amongst all persons that are created - because Person.prototype is their parent. Thus, declaring methods on the prototype is more memory efficient.

Apply and Call

As you can see, functions become methods just by virtue of being attached to objects, at which point the this within that function refers to the object which it is attached to, right? Well… not exactly. Look at our previous example

Now, if you create 2 people, jack and jill

Here, sayHi is not attached to jack or jill, rather, it’s attached to their prototype: Person.prototype. How does the function sayHi know jack and jill’s names?

Answer: this is not bound to any particular object until you call the function.

When you call jack.sayHi(), sayHi’s this will be bound to jack; when you call jill.sayHi(), it will be bound to jill instead, but binding does not change anything about the function itself - it’s still the same function!

It turns out that you can explicitly bind a function to an object yourself.

The apply method belongs to Function.prototype(yeah, that’s right, functions are objects and have prototypes too and can also have properties!). So, you can use apply with any function to call it while binding it to the object of your choosing, even if the function is not attached to it. In fact, you can even apply the method to an object of a different type

You might say

Wait a minute! A Tulip is not supposed to say hi!

To that, I would say

Everything is everybody. Everybody is everything. We all cool! Just…chill, man!

As long as the object has a name property, sayHi is happy to print it out. This is the principle of duck typing

If it quacks like a duck and it walks like a duck - it’s a duck to me.

I am sure I misquoted that, but whatever.

Now back to the apply function: if you want to include parameters you can pass them as an array as the second parameter to apply.

Function.prototype also has a call function, which works very much like apply. The only difference is in that rather than passing the parameters as an array in the second parameter, you would just add them to the end:

The new method

Now, for something fun…

apply is really handy for certain situations when you want to call a function with a variable list of arguments. For example, the Math.max function takes a variable number of arguments

This is nice, but it’s not generic. By using apply you can get the max for an arbitrary array,

Much more useful!

Now, given that apply is so useful, there may come times when you want to use it, but rather than call-as-function,

you want to call-as-constructor.

Sadly, this doesn’t work. It’ll think you are calling Person.apply as a constructor. How about this

That doesn’t work either, because it will first construct a person, and then try calling the apply method on that person.

What to do? Thanks to an idea presented on this answer on StackOverflow, there is a way!

We can create a new method for Function.prototype.

With this, we can call constructors with the new method rather than the new statement

Let’s go through how the new method works.

First,

we create a Fake constructor which will apply our real constructor as a method when created. In the context of the new method, this is the real constructor - we save it to be used in the Fake constructor. We also save the arguments with which new was called to reuse in the Fake constructor. Next,

we set Fake.prototype to the original constructor. Since the prototype’s constructor property is still set to the original constructor, any object created by Fake will still be an instanceof the original constructor. Finally,

Create the object using the Fake constructor and return it.

Did you get all that? It’s okay if you don’t get it the first time; just look it over and poke at it a few more times.

Anyways, the point of all of that was that now you can do things like

Nice! But why do we have to write Person twice? We can probably write a helper method

So you can do

Nice, slightly better!

What’s the point of this exercise anyway?

Well, it shows that Javascript is a flexible little language. Even if it doesn’t do the things you want, you can probably mold it into doing them.

Summary

This is the end of this lesson/article/blog post. It was nice having you! Today we learned about:

1. Constructors
2. Methods and Prototypes
3. apply and call
4. Implementing the new method

In the spirit of PromoteJS, I researched and collected a short list of good resources for learning Javascript fundamentals - no frameworks, just Javascript:

Bonus: Rebecca Murphy's jQuery Fundamentals.

Update: because the showdown.js link is dead, I've created a github repo for this.

Introducing QuickSlides: Quick and Dirty Presentations in Markdown using Slidy and Showdown.

git clone git@github.com:airportyh/QuickSlides.git name

where name is the directory name you want for your presentation.

Then, edit presentation.html and write your slides in Markdown within the