When looking at touch events and how much more responsive they can make your page, there’s a temptation to just add them everywhere. After all, you get an almost native-like feel to buttons and links when you make them respond to ontouch, instead of waiting for the browser’s click event to kick in. Unfortunately, this also has the undesirable effect of messing up scrolling, resizing, and everything else you can do with a multitouch device around these areas of the page. Ideally, we’d like to be able to get the benefit of responding quickly to these touch events without breaking the natural user experience of using the browser.

I’ve worked out a simple solution to this in the form of a minimal jQuery plugin that gives you a replacement for $.click(), and binds both click events for desktop platforms and uses a slightly more intelligent handling of the touchstart, touchmove, and touchend to speed up touch event handling without breaking the natural usage of the page. To be honest, I’m still not sure what the browsers do that takes so much longer to fire the click events, but this results in a significantly faster experience on both MobileSafari and Chrome for Android.

Anyone who’s used an Interac machine knows how unreliable and finicky they can be - although I’m sure there are difficult engineering and cost challenges involved in designing them, I think they could do a lot better than the currently available systems and their UI’s. Usually when something goes wrong, you can try the transaction again, or at least just pay with a different method. However, this time, the machine completely locked up, and then somehow froze the cash register as well.

The interesting part of what happened next had nothing to do with the payment machines themselves, but how the cashier responded to this. She began to push random buttons on the machine, and remove and re-insert the card repeatedly. When this had no effect after several minutes, I offered to pay with cash that I borrowed from a friend who was luckily ahead of me in line. When she discovered that the cash register interface had failed as well, she responded the same way - blindly pushing buttons and waiting for something to change. At this point, a long line was forming and a co-worker wandered over to help. He suggested to restart the machine, mentioning “it usually helps, but it takes forever to start up again”. She gave this a try, and a couple of minutes later the machine was up and working again.

So what’s the point of this totally mundane story? I realized something interesting about the behavior of the cashier, and about people who don’t have significant technical experience (e.g. programming, engineering) when they try to troubleshoot software problems.

A software developer would see this problem and immediately go through a thought process like this:

• The payment machine has run into some sort of software bug
• It is a computer system that most likely has (a) permanent storage like flash or a hard drive and (b) non-permanent state stored in memory that affects the running of the software and (c) a network interface that receives data from an external service
• The buggy state is probably not permanent, and probably results from the state of the software being messed up, perhaps from unexpected input from the UI or the network
• Therefore, restarting the device should provide it with a “clean slate” that allows it to go back to a known working state and should be the easiest way to fix the problem

A non-technical person might think about it like this:

• The machine is broken, either because of something I did wrong, or because of something wrong with the card
• I know how to use it when it’s not broken, but not when it’s in this incorrect state
• The only effect I can have on this machine is through interacting with it in a similar way that I did when it was working
• If I restart the machine, it will still be broken

The question is, why didn’t the cashier think of restarting the device as a solution right away, instead of trying to keep interacting with a device that was obviously not responding? I think this is due to a flawed mental model of how the machine works.

A computer is somewhat unique among tools in that it has temporary memory. In comparison, a power drill doesn’t have any memory, and expecting it to behave differently when you unplug it and plug it back in again would be silly. However, I think most people’s mental model of how software works IS based on the same mental model that they have for tools and simple appliances. Any change to a physical tool’s behavior (such as stripping a drill bit, or burning out the motor) is a physical one, and thus you can expect it to remain through a power outage. Many software bugs, on the other hand, are ephemeral and won’t persist through a restart of the machine.

So what does this mean for people who design software? It means that you can’t assume the user of an application you design shares your mental model of how the application works, or even of the computer system that it runs atop. The way the user uses the application, and how errors are handled or presented to the user, should be based on metaphors for real-world things that they’re used to and understand intuitively.

One example of this would be an mobile app that keeps a record of its state so that it can seamlessly restore back to the same state when the app is closed and reopened. This gives the illusion of an interface that is persistent - the user left it a certain way, and when they came back, it was still like that, just like a physical object. As an application developer, it’s obvious that the app doesn’t REALLY work this way, but that doesn’t mean we should avoid carefully constructing this illusion for the user. Otherwise they likely won’t be able to reason about how to fix a problem, since they have a very limited concept of how mobile apps are started/restarted and when they stay running.

If you look closely at the location that link’s pointing to, you’ll notice it’s not a website. It’s actually a Data URI, a special kind of address that allows you to embed data for a browser directly into the link itself.

Data URIs begin with data: and a mimetype to tell the browser how to interpret the content. After that comes an optional directive ;base64, which means that the following content is encoded as a Base64 string. In this case, the content is encoded to make it easier to process the URL from inside the page. The content then follows after a comma.

Here is the contents of that link, when decoded, stripped out of the URI and prettified:

1
2
3
4
5
6
7
8

<script>
    setTimeout(function(){
        a=atob(location.href.split(',')[1]);
        b=document.body.innerHTML;
        window.location='data:text/html;base64,' + btoa(a + b)
    }, 0)
</script>
<div style="float:left">$</div>

How does it work?

Because the contents of window.location are encoded in Base64, it’s a relatively simple task to parse the entire page out of it by splitting on the single comma. We can then grab just the page content with the innerHTML property of the body tag. Adding these two together and reencoding into a new Data URI yields the exact same page, but with the content doubled.

We then simply redirect the browser to our newly created “page”. The content in this case is a simple div tag with a dollar sign, which causes the browser window to fill up with these symbols before crashing or freezing.

The key trick here is that the browser will load the new page almost instantly, and the content is being produced entirely locally, without having to wait for a server and read data with HTTP. I’m actually not sure what crashes each browser, but I’m guessing it’s that none of them place limits on the amount of content, which in this case is growing exponentially.

Does it work on all browsers?

Actually, no. Ironically enough, it doesn’t affect Internet Explorer. Although Data URIs are supported in IE8+, they can only be used for images and certain CSS declarations. Also, because of its one-process-per-tab model, Google Chrome isn’t affected too much by this; it just gives you the unhappy file folder.

Is this dangerous?

I don’t think so. At least, I can’t think of anything useful to do with it other than posting a link somewhere to annoy people. Also, most websites should flag a Data URI as an invalid link, preventing you from posting it to a public area.

Although the code monitoring part is basically the same as the Django server’s, I added an feature that’s always seemed missing to me - When an exception is thrown starting up the program, it prints out a stack trace, waits 10 seconds, and then resumes. This is really handy if you leave it running, and are in the habit of compusively saving every 15 seconds, like me. Sometimes when you make a syntax error in a core part of the application, the server crashes and you have to restart it, which seems a bit silly. I also had to re-work it a bit to play along with the GUI framework (PyGTK).

I started off with the autoreload module used in Django, which has a handy python_reloader wrapper function. If the application is single threaded and doesn’t use an event loop, you could probably just use this. It works by starting a child process, which then starts two threads - one for your application’s entry point, and the other that monitors the code for changes by inspecting sys.modules every second. If a change is detected, the monitor thread shuts down the process. Meanwhile, the first process has been waiting for this, and starts a brand new child process. This is all done through one script, by cleverly setting an environment variable RUN_MAIN for the child process which makes it start the two threads instead of its own child.

Unfortunately, I needed this to work inside of the GTK event loop, and not in two different threads. There was an easy workaround though - the gtk.timeout_add and gobject.timeout_add functions allow callbacks to be scheduled at a predefined interval. I wrote a handler for calling the code_changed function, and one for quitting the GTK main loop. RESTART_CODE is a return code that’s used to indicate the application ended because of a code change, instead of just crashing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

from autoreload import code_changed
import logging, gtk, subprocess

RESTART_CODE = 8
ERROR_SLEEP_TIME = 10

logging.basicConfig(level=logging.INFO)
log = logging.getLogger('activity_runner')

def exit():
    """ Quits the GTK event loop """
    log.warn('Quitting now')
    gtk.main_quit()


def watch_files():
    """ Watches imported files for changes """
    if code_changed():
        log.warn('Code was changed, exiting...')
        sys.exit(RESTART_CODE)
    else:
        return True

Now I needed the main part of the activity runner, which sets up the options and environment variables. I used optparse to add two command-line options, a watch flag (which does what you’d expect), and a timeout flag. The timeout flag exits the application after a given number of seconds, which is sometimes handy for testing.

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

import optparse

parser = optparse.OptionParser()

parser.add_option('-w', '--watch', action='store_true',
        help="Restart activity when files are changed")

parser.add_option('-t', type='int', dest='timeout', action='store',
        help="Stop activity after timeout", metavar='seconds')

options, args = parser.parse_args()

if options.timeout:
    log.info('Timeout after %d seconds' % options.timeout)
    gtk.timeout_add(1000 * options.timeout, exit)

This next part is trickier. The first block should only execute in the child process, but comes first so that it can disable starting a child process of its own. Similar to python_reloader and friends, the next block turns on the environment variable flag and runs itself as a child process. When the child exits, the return code is used to decide what to do next. A zero means that the event loop was exited normally, probably through the application GUI, so the main loop ends when this happens. I changed the script here to allow for errors, by adding a brief delay when a non-zero, non-restart code is returned, instead of just quitting (the original behaviour)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

if os.environ.get("EXIT_ON_CHANGE") == "true":
    gtk.timeout_add(1000, watch_files)

    # Disable watching for sub-process
    options.watch = False

if options.watch:
    log.info('Watching code files...')

    while True:
        # Run again with env marker added
        env = os.environ.copy()
        env["EXIT_ON_CHANGE"] = 'true'
        retcode = subprocess.call(sys.argv, shell=False, close_fds=True, env=env)

        log.info('sugar-activity exited with code %d' % retcode)
        if retcode != RESTART_CODE:
            if not retcode:
                # If sugar-activity returns zero, just exit
                log.warn('Activity exited')
                sys.exit(0)
            else:
                # If sugar-activity returns an error code, restart after a delay
                log.error('Activity did not exit safely!')
                time.sleep(ERROR_SLEEP_TIME)

Since the master process is stuck in that loop until the application exits, all that’s left now is to start the app! I’m leaving out some Sugar-specific environment variable stuff, but this is where you’d call your application entry point.

1
2

from sugar.activity import main
main.main()

This might seem like a lot of effort just for an auto-reloading script, but in my case it had a more important use. I’m now able to develop on my Mac while sharing the code folders through NFS with a virtual machine I use to run the application. The application just stays running on the VM all the time, and whenever I save a code file, it restarts automatically. I set up the VM once, display it on another monitor, and can leave it alone after that!

• To adaptively adjust the framerate based on the user’s browser
• To make it respond interactively to browser events other than on the canvas

One problem I’ve run into with Processing.js is that the code ends up encapsulated in its own little “Java syntax bubble”, and as far as I know, the outside page can’t access it at all. I rewrote it based on the example given on the Processing.js site (Writing Processing Code with Javascript), which made it simple to add the next two changes.

The performance of HTML canvas on iOS (and probably other mobile OSs as well) is pretty poor, so I thought it would be a good idea to drop the framerate a bit. A simple browser check (using a jQuery plugin) is enough to do this.

Since the animation looks a lot cooler in fast motion, I decided to make it so it speeds up to 3X the frame rate when a visitor mouses over the title. Since I’m using jQuery for everything else on this site, it was easy enough to bind to the event listener and toggle back and forth between the two. At first I thought that the frameRate function would only work inside setup(), but it was not so. It looks like it’s possible to change the speed at any time from any event in the page.

This is most of what I added:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

var mobile = false;
try {
    mobile = jQuery.browser.mobile;
} catch(err) { }

var sketch = function(p) {
    var num_elements = 80;
    p.size(720,100);

    // Wimp out for mobile browsers
    p.frameRate(mobile? 5 : 10);

    // Speed up 3X on mouseenter
    $(canvas).parent().mouseenter(function() {
        p.frameRate(30);
    })
    .mouseleave(function() {
        p.frameRate(10);
    });
    ...
}

The full javascript version is on GitHub. I think it’s a pretty simple example of how to convert a Processing sketch to integrate it with your page.

I had some initial troubles doing it though. Although there’s quite a few libraries out there for setting it up, there’s a certain unavoidable amount of difficulty involved. There’s multiple redirects going on between your app and the OAuth provider, and when you screw up, it’s easy to run into the infamous “infinite redirect” bug.

It turns out my problem was the result of passing a relative URL (like /twitter/authorize) to the API instead of an absolute one (such as http://mysupersecretapp.appspot.com/twitter/authorize). The path matched up to the Twitter API’s one, so it ended up authorizing the user, then redirecting to itself indefinitely. You’d think they’d check for that, but they don’t.

Anyway, what I realized after setting it up is that for most applications, you don’t even really need to store the data you get back in a database! You can just do what yFrog (and others) do, and just perform a task for the user after logging in. Then later on the login cookie expires, but who cares? They can log in again later through Twitter…

Maybe I’ve just been missing out on something obvious here, but it seems like this is a new and powerful way of building web applications. One where the app is more like a plugin for one of the big sites, like Twitter or Facebook, and doesn’t have to store data for or manage its users in any way. If the whole development process could be made just a little easier, it could really lower the barrier for building small useful web applications by getting rid of the user and data management overhead.

1
2
3
4
5
6
7
8

rob@macpro: ~/ $ workon appengine
(appengine)rob@macpro: ~/ $ cdvirtualenv myapp/
(appengine)rob@macpro: myapp/ $ pip install django-awesome-app another-lib
...
(appengine)rob@macpro: myapp/ $ ./manage.py runserver
...
(appengine)rob@macpro: myapp/ $ ./manage.py deploy
...

Luckily, it turns out the django-nonrel and djangoappengine projects have solved most of the problems with this, as long as you do things their way. I first tried to follow my own “modified” version of their setup tutorial where I bundled all of the libraries into zip files to be used with zipimport. Don’t do this; It doesn’t work. The djangoappengine setup code actually assumes it’s located in a top-level folder in your project, and hardcodes the path to the app.yaml configuration file accordingly. More importantly, a lot of Django apps won’t work from inside a zipfile, probably because of the way templates and static files are loaded.

Anyways, it’s working quite well now. There’s still some weird things missing in the django-nonrel project, like being able to reliably use the dumpdata or remote commands, but nothing that can’t be worked around. More soon on actually building a working site with Django on GAE. Previously I’ve only used it for miniature experiments, like turk-keypad.

1
2
3
4
5
6

> var x = function() {

[object Context]:1


...

Fortunately, the node.js docs suggest an alternative, using the handy rlwrap tool, which wraps any command inside a readline shell and gives you about a million options. I extended the provided example a bit, and ended up with this:

1

alias node='env NODE_NO_READLINE=1 rlwrap -p Green -S "node >>> " node'

This tells node not to use it’s built-in readline functionality, replaces the prompt with a custom colored one, and automatically starts maintaining a history file for this command at ~/.node_history. Pretty fantastic. Although rlwrap does have some other options for messing around with alternate prompts, it looks like the simplest way of getting around node’s multiline REPL issues is to just use the built-in .break command. This seems to fix it in most cases.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

gifts = ['Partridge in a pear tree', 'Turtle doves', 'French hens',
'Calling birds', 'Golden rings', 'Geese-a-Laying',
'Swans-a-Swimming', 'Maids-a-Milking', 'Ladies Dancing',
'Lords-a-Leaping', 'Pipers Piping', 'Drummers Drumming']

def days_of_christmas(how_many):
    for day in range(how_many):
        print 'On the %s day of Christmas, my true love gave to me:' % ordinal(day)
        for number in range(day, -1, -1):
            print '%s %s%s' % (named(number), gifts[number], ',' if number else '.')

def ordinal(num):
    return ('first','second','third','fourth','fifth','sixth',
            'seventh','eighth','ninth','tenth','eleventh','twelfth')[num]

def named(num):
    return ('a','two','three','four','five','six',
            'seven','eight','nine','ten','eleven','twelve')[num]

days_of_christmas(12)

It turns out you get 364 gifts if they are cumulative, which, oddly enough, is exactly enough for you to get a present every day for a year except Christmas Day. Coincidence?

Luckily, it hasn’t taken me very long. I decided to check out Jekyll by starting with a fork of its creator’s site.

Now that I have it working, I just need to come up with a fantastic new design of my own, point some domain names at this and I’m set. Might even port my portfolio-website-in-progess over to Jekyll and Liquid as well.

Porting of old posts from my other attempts at blogging might happen at some point in the distant future, when I’m very bored. Definitely not tonight. Here’s a random piece of Python code to show how awesome Pygments support is:

1
2
3
4
5
6
7
8
9

def circle(size, fore, back):
    for y in range(size):
        for x in range(size):
            xi, yi = round(x - size/2 + 0.5), round(y - size/2 + 0.5)
            radius = abs((xi**2 + yi**2) - (size/2)**2)
            print fore if radius < (size/2) else back,
        print

circle(20, 'x', ' ')