A Simple Solution for Mobile Web Touch Events

I think anyone who’s worked on building a “mobile-friendly” website has run into the tricky problem of dealing with touch events. Let’s face it, the default behaviour for touching “clickable stuff” on a web page on all mobile platforms is pretty nasty. You tap something, and 5 minutes later the page reacts.

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. Read on →

Comments

Mental Models of Software

I recently had an interesting experience when trying to buy food at a cafeteria that made me think about how most people reason about computers. I tend to pay for most things either with debit or credit cards, because I like how they track my purchases automatically, and because I’m honestly just too lazy to make sure I always have cash with me.

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. Read on →

Comments

This Link Will Crash Your Browser

Here it is. Go ahead and click on it, we both know you can’t resist.

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.

Read on →
Comments

Auto-reloading Python Applications

I wrote a really handy little script for a project I’m working on involving a Sugar Activity that automatically reloads the code whenever a file is changed. It borrows heavily from the Django project’s manage.py runserver command, and takes the form of an activity launcher script. You could use this for auto-reloading of any single-threaded Python application, not just GUI applications.

Read on →
Comments

Decorating With Processing.js

I finally got around to porting the script that powers the title animation to Javascript. Why would I want to do this? Two reasons:

  • 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.

Read on →
Comments

Why OAuth Is Awesome

So I finally got the authentication working on my Twitter application, and I’ve decided that OAuth is actually pretty awesome. When it works, that is.

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.

Comments

Deploying Django on Google App Engine

Today I spent an embarrassingly long time trying to figure out the “nicest” way to set up my Django project to work with Google App Engine. The main problem is that the development server mangles the Python package import system in some mysterious way to emulate the environment of App Engine itself. This makes using virtualenv pretty much impossible, at least from what I’ve seen so far. The best I was able to pull off was running an interactive shell that could access the GAE libraries. This is kind of useless without being able to run the server though. What I wanted was to have a workflow like the following, where I could extend the deploy command to bundle the installed packages from the virtualenv automatically:

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.

Comments

Using Rlwrap With the Node.js REPL

I’ve recently been working on a couple of small projects using Node.js, and I’m loving it’s simplicity and speed so far. One thing I have been missing though, thanks to my experience with Python and IPython, is the lack of a sane REPL for prototyping and testing out bits of code. I know, you can just run node and type stuff in, but the way that interpreter behaves is far from what I’d call “sane”. There’s no history, and if you screw up the order of brackets, or get lost in a multiline expression, you get to experience this wonderful prompt:

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.

Comments

Twelve Days of Christmas

I wrote a program to print out the verses of the Twelve Days of Christmas. This started from an argument with my sister about whether the gifts are cumulative or not (i.e. do you end up with twelve partridges, or just one?). Sadly, this program doesn’t really answer the question, any more than singing it would.

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?

Comments

My First Post

It’s Christmas Day, and I’m building a blog. Because I can.

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', ' ')
Comments