funkatron.com

Normally I try to chew on an idea for a post for a few days; it lets me sort out my thoughts and form some kind of thesis. I’m totally not doing this here, though, so I should preface this with a note that I could be completely off-base. But I don’t think so.

Discussion about how we interact with computers heated up recently with the introduction of the iPad. Lots of nerdy types (myself included) were frustrated that Apple had introduced not a tablet “computer,” but a big iPod Touch. They’re both computers, of course, but the way we interact with them is different: the modern computer interface uses a multitasking windowing motif, and the iPod/iPad interface is fullscreen and single-task focused.

As a Nerdy Power User, I am well-versed in how to navigate a multitasking interface, and for the most part I understand how and why it works the way it does. I, in fact, enjoy learning about the intricacies of these kinds of systems. So when I use a single-task interface like that of the iPod Touch, I frequently bash my noggin against the barriers it imposes. Copying a URL from the web browser to my Twitter client takes orders of magnitude longer than it would on OS X or Windows, for example.

What I’ve learned from interacting with most computer users, though, is that they do not give a rat’s ass about how computers work. They want to accomplish certain tasks, and will do this in the way that is most sensible and direct for them. And the way they end up accomplishing these tasks within the multitasking window motif is typically not the way I would do it.

The recent fiasco on ReadWriteWeb, where a RWW article became the first Google result for “facebook login,” is a classic example of this. And, unfortunately, so is the reaction of most Learned Computer Fellows: one of mockery and derision, admonishing the confused users for being stupid, incompetent, or lazy.

I’ll admit that I took some glee when I first saw the numerous comments on the article; I love a humorous clusterfuck as much as the next guy. But seeing some of the reactions by the Very Smart Computer People, I began to realize that We Are Not Getting It. Consider:

• Isn’t this really a failure of Google? How did it become so easy to game search engine results that an article about Facebook and AOL became the first result for ‘facebook login,’ instead of the obvious thing people are actually looking for?

• How is it the fault of the users when we present them with multiple, barely-differentiated text fields within the same window. Is it really surprising that they don’t understand the differences between each? And is it surprising that they choose to use the one which works with more natural language, rather than entering syntactically-unnatural domain names?

• There is LOADS of anecdotal evidence that most users simply use search engines as a sort of natural language CLI. Shouldn’t we be designing interfaces that work in the way most natural for the majority of users?

These people have better things to do with their days than tweaking out the spacing in their browser toolbars. A computer for them is a utility. One that is increasingly complex, and one that is used because it’s the only option for accomplishing certain things – not because it’s a good option.

It’s kind of like the Photoshop Problem: when people want to crop a picture, we give them Photoshop. Photoshop is a behemoth application with nearly every image editing and touchup function imaginable, and it is terribly complex. Now Photoshop is an impressive tool, but only a very tiny percentage people need the power it offers. The vast majority just want to crop their ex-husband from the photo and let their friends look at it. But even iPhoto, the poster child for Apps So Easy Your Grandparents Can Use Them, continues to pile on features and complexity.

When folks need an elevator, we should give them an elevator, not an airplane. We’ve been giving them airplanes for 30 years, and then laughing at them for being too stupid to fly them right.

I think we’re the stupid ones.

Update

As I said at the start, I wrote this piece a bit off the cuff, so upon further review I think I could have made it a bit clearer. First, a couple great rebuttals I read:

• Reply to Funkatron’s Analysis of the RWW/Facebook Debacle of 2010
• No, We’re Not The Stupid Ones

I posted a comment on Phil Crissman’s blog, which I think explains a bit further what I’m thinking, and addresses the notion that some learning may still be required. To copy and paste myself:

I certainly don’t think that the computer can become (anytime soon) a magic box that determines our whims, nor do I think that people shouldn’t have to learn some things.

What I do think is that the current interface modern OSes on computers provide is simply overwhelming for most users, to the point that it’s very challenging to learn how to accomplish tasks without a very significant investment of time. Driving would be a good example of a task that does require investment of time, but is not so overwhelming that the vast majority of people fundamentally get it wrong: you don’t see people steering with their feet, or accelerating and braking with the radio. I’d argue that modern computer interfaces, in a rush to offer flexibility and capability, make it possible to steer with your hands, feet, teeth, and knees — and don’t make it particularly clear which one is best.

Update 2

Some more responses:

• Really? Are we the idiots?
• Some People Can’t Read URLs

Feel free to forward me others; I think I’ve given up trying to track them down for now.

Remember when you went to SXSWi last year, and you said “I love the parts where I meet cool people and eat free food and drink free booze and throw up, but I wish the presentations and panels weren’t so goddamn fluffy?” Me too. That’s why Alex Payne (aka “The Guy Who Has Actual Name Recognition”) and myself submitted the talk “Security for the Social Set.”

The idea is that we give some solid, useful information about the security problems social networking apps have to deal with, and how to deal with them. While we can’t get too focused on specific languages and frameworks, client-side defense with JavaScript will certainly be demonstrated, and I intend to show examples in PHP and probably a couple other platforms (coughRailscough). It will be hard to get into heavy detail within the alloted time, but it’s my hope that we can kickstart awareness and understanding of fundamental secure web app programming techniques.

Plus, I need a justification for dropping the coin for hotel and air fare on this boozefest, so please, vote for us.

• Security for the Social Set (SXSW 2009)

Oh, and a few other meaty talks you should consider include:

• Practical JavaScript Development
• More Secrets of JavaScript Libraries (this was packed last year)
• 200s, 304s, HTTP Compression, and You
• Hackproofing Ruby-on-Rails Web Applications
• Functional Programming Without A (Strictly) Functional Language
• Unit Testing Back to Front: Prove it Works!

I have these five promo codes from Dreamhost. They expire in three days. Apparently you get super-hot deals with them, like:

• Four times the normal disk and bandwidth
• $150 off a 5-year plan
• $200 off a 10-year plan

I would not sign up for 5 years with any shared host. However, I do think DH is pretty decent for small-ish sites that can work with shared hosting. I’m well aware that they’ve had a couple embarrassing public flubs in the past couple years, but I generally think they’re good folks who try to do right by their customers. Some will certainly disagree, of course. 8)

I still maintain my old account there for low-cpu, high-bandwidth/storage stuff. They do quite well with PHP hosting, and can handle Ruby and Python setups with a little effort. They’ll let you do crazy stuff like compile your own PHP if you are fine with using FastCGI, and have a nice GUI to setup SVN repos. Not many shared hosts will do the same at a similar price point.

Anyway, here are the codes. They’re first come, first serve. Yes, I make money if you sign up with one of them. I will not be hurt if you don’t use them.

• 998942362256
• 916860787004
• 591140700044
• 047271781406
• 160643597831

Dreamhost Signup Page

I’ve been working at Purdue for over 6 years now, and I have to say that I’ve enjoyed it immensely. While the experience can vary from department to department, in general it’s a fairly low-pressure environment with a lot of opportunities to learn and develop new skills for motivated folks. Purdue offers great benefits, and the Greater Lafayette area is a pretty cool, decently progressive environment considering the size – US News & World Report recently picked West Lafayette one of the “Best Places to Retire” in the US.

A job just opened up in the Math department for a “Web Programmer/Analyst”. This position calls for strong PHP, PostgreSQL and MySQL skills; Linux and Unix fu (you should be able to admin the web stack); good communication skills (you’ll be working with a number of different people with varying tech backgrounds); and plenty of independent motivation.

I’m not involved in the hiring process at all, but I’m friends with those who are, so if you have specific questions, I can route them to the right person. Please email me directly – do not post questions in the comments.

• Web Programmer/Analyst - West Lafayette - Mathematics

When Google AppEngine was announced, a lot of sturm und drang went through the PHP community because it only supported Python. Of course, the same thing went through the Ruby community. The Perl community, not so much, because they’re used to getting ignored.

Anyway, I didn’t really give a crap, because Python is a cool language, and I’ve been interested in learning new languages and frameworks lately. PHP is cool and all, but having done it for 9 years, you kinda look for new challenges. Plus, getting hung up on one language is a sure way to be a boring dude who gets caught up in lame religious language wars.

I’ve actually toyed a little with Python here and there, but never dove in on a significant project. I’m someone who really likes whitespace and indenting rules and such, so those aspects of the language never bothered me. Otherwise, Python is a good fit for me philosophy-wise, because it’s totally the anti-Perl, lacking goofy magic characters and 1000 ways of doing the same thing. I can’t stand languages where “~^s” means “find all numbers that start with the letter ‘s’, add them, multiply them by 75, and then post the result to Twitter”. I’m not freakin’ R2D2 here.

So anyway, I started working on a little side project with Alex Payne on GAE. It’s been an enjoyable experience to work with a new language and framework, and there’s a lot to like about what GAE offers. It also has some rough edges, though, in some areas you’d be surprised by.

The good

The webapp framework

The built-in framework for handling requests is webapp, a nicely straightforward system for mapping requests to handlers.

class MainPage(webapp.RequestHandler):
    def get(self):
        self.response.out.write('Sup dogg?')

class FooPage(webapp.RequestHandler)
    def get(self):
        self.response.out.write('This is the foo page')

def main():
    wapp = webapp.WSGIApplication([
                                    ('/', MainPage),
                                    ('/foo', FooPage)
                                  ],
                                  debug=True)

    wsgiref.handlers.CGIHandler().run(wapp)

So we define a class to handle a specific URL request, and define methods for GET or POST or whatever HTTP commands inside those classes. Then in the main function we map URLs to those handler classes in the webapp.WSGIApplication constructor, and then start it up.

I like this because it’s simple and easy to follow. I could read the code before I’d written any myself and get what’s going on. There’s no magic happening here; no auth-mapped stuff or relationships established because I happened to name something the right way and put it in the right directory. Convention is good, and we have conventions here, but the conventions are clear and obvious.

Django templating

Django has a really nice templating system. GAE lets you use it outside of the whole Django stack. This is cool. For example:

# define some values to plug into the template
tpl_data = {
    'page_title':"This is an awesome page",
    'body':"Here's the page body, sucker"
    }

# get the template path
path = os.path.join(os.path.dirname(__file__), 'index.html')

#render and output the template
self.response.out.write(template.render(path, tpl_data))

Here’s a super simple index.html template:

<html>
    <head>
        <title>{{ page_title.striptags }}</title>
    </head>
    <body>
        {{ body }}
    </body>
</html>

Google User Auth

Writing a user system is a pain. Making people set up new accounts to use your site is yet another barrier to experiencing your amazing new Google sellout project site. You could presumably do these things if you want in GAE, but most of the time that seems kinda stupid. GAE offers you very easy integration with Google user accounts, so you can use that as your authentication system. Since everyone and their mom has a Gmail account, it’s a pretty good bet many or most of your users will be able to skip account setup.

Pricing

GAE is free for your first 500MB of storage and “around” 5 million pageviews. That’s plenty to host a smallish app or do initial testing on something you want to get big (because big == profit, right?). If you push past that, the pricing is in-line with similar services from Amazon. That means it’s totally reasonable to set up an app just for goofing around and learning.

Python

Python is a cool language: easy to pick up and quite powerful. It doesn’t fit some tasks as well as PHP IMHO, but it does a ton of stuff well, and its large community means there is lots of support and library development. Some stuff it does really well includes:

• Network programming (example)
• Parsing HTML
• Email parsing and manipulation
• OS X scripting
• String manipulation
• Unit testing
• Other stuff I probably don’t know about

AppEngineLauncher

Recently the GAE team released the Google App Engine Launcher, an app for OS X that handles launching the development server and deploying your app to Google’s servers. You can of course script all this stuff yourself on the command line, but for folks less comfortable with that, this is a godsend. I actually did use the CLI before, but I don’t touch it now because the GAEL is just so fly. Single-click deployment is especially awesome.

Leveraging Google’s Infrastructure

They gots some big computers, rite? You’d certainly think so, and they probably have better uptime than your $5 shared hosting account. We hope.

The lame

Datastore query limitations & primitive text search

The Datastore API is GAE’s database system. It has some similarities to traditional relational DBs like MySQL and PostgreSQL, but it is fundamentally different. It stores data objects as entities instead of rows, and properties instead of columns. Objects are described by model classes, defined in Python:

class Page(db.Model):
    title = db.StringProperty(required=True)
    keywords = db.StringProperty()
    date_added = db.DateProperty(required=True)
    date_updated = db.DateProperty(required=True)
    body = db.StringProperty()

Models are to entities as classes are to objects, then (I think).

The object approach has some cool flexibility, like expando models that let you add arbitrary properties to entities (very unlike rows in a relational database).

You can do SQL-like queries against the Datastore with GQL. It’s a lot like SQL, but a lot more basic. In fact, this is a summary of the entire language:

SELECT * FROM <kind>
[WHERE <condition> [AND <condition> ...]]
[ORDER BY <property> [ASC | DESC] [, <property> [ASC | DESC] ...]]
[LIMIT [<offset>,]<count>]
[OFFSET <offset>]

<condition> := <property> {< | <= | > | >= | = | != } <value>
<condition> := <property> IN <list>
<condition> := ANCESTOR IS <entity or key>

This lets you do basic queries, but it’s missing a lot of powerful stuff present in SQL. Most notably there is no equivalent to the LIKE comparison operator. That means there is no way to do partial string matches!

Okay, so you can do kludgy prefix matching, and there is an as-of-yet undocumented whole word search using the SearchableModel class, but those are primitive compared to the string matching capabilities in MySQL. Personally I would’ve thought that the search company would have given GAE really awesome text search capabilities out of the box, but for now folks have to roll their own hacks.

I guess now I have an idea of why Gmail’s search can’t match partial strings.

No “beginner” docs

GAE’s docs are aimed at experienced developers who have already built web apps. Most of it is reference, and it’s a little light on examples. If you’ve not used Python before, here’s the entire introduction form the GAE docs:

For more information about Python, see the Python website and the Python documentation.

I think Python is easy to pick up, but GAE doesn’t even bother pointing out some good tutorials for beginners. Compare this to The Django Book or The Definitive Guide to Symfony, both of which aren’t really for beginners, but do a good job of helping them get up to speed.

I’m early in my development experience with GAE, so this is by no means comprehensive. Google has already demonstrated that the GAE feature set will be growing, having introduced memcache and image manipulation APIs just a week ago. I’m sure the documentation will be improved and supplemented by third parties in short order, and the issues with text search will almost certainly be addressed soon – it’s an obvious deficiency.

For now, I’m having a lot of fun working with GAE. It’s a solid platform with a lot of promise, and it offers a lot of learning opportunities for folks who want to explore web app dev with Python.