In general, people who label themselves with “PaaS” want to do two things: reduce your dependency on coders, and give you a shortcut to setting up business online. Reasonably appealing, you might think? I’ve been giving the PaaS sector a bit of a once-over in the last couple of weeks, and this is an attempt to piece together half-formed conclusions about what PaaS is and whether it is useful to me.

Rapid recommendation

If you don’t have time to read the rest of this article, then here’s my advice:

• if you are at the non-technical end of the scale, with no access to designers and developers, and you don’t care about the way your apps will look, PaaS will help you open up your company information for visualising and editing; changes can be set up to trigger other changes and notifications, and you can schedule reports
• if you are a professional web designer and developer, you are likely to become frustrated at the unresponsive tools used to create PaaS apps, and the barriers to designing the experience of the people using your app

A motivating problem

This survey was prompted by the familiar need for a pair of hands to help build a system that neither myself nor my partner felt capable of building well. If I give you an outline of what the system roughly looks like, it ought to set my opinions of PaaS in context.

Essentially, we want to make a website handling information about people and the properties they live in. There are public areas for browsing and private areas for people with accounts. Plenty of design has gone into the appearance and function. There are some web services in the mix – PayPal, a booking system I wrote in server-side JavaScript, and EchoSign. Interactions with the website and notifications from foreign systems need to have effects, manipulating the people and property information.

I think that what I have just described sounds like a very generic web application. Some bits require more know-how than we possess to build: how to write and manage workflows, which link events and notifications to effects; what our data stores should look like and where they should be relative to the website and its contents; how to get our system to respond to notifications from foreign systems; and how to serve the product to multiple customers and charge for it.

I don’t recall what prompted me to look at PaaS, but the PaaS companies I first looked at made a big deal about how you can easily model company data structures and create workflows between them. This sounded great. So I went about having a long look at what was out there and whether it would be cheaper and easier to build my app on top of that.

What does PaaS claim to do?

In general, PaaS companies want you to model your business and its processes as objects on their platform, with various properties hanging off the objects (think Salesforce.com and its tabs). You create forms that open up the system to let people add and amend data, and you hook workflows on to triggers such as the submission of a form. The example that everyone seems to use is an expenses approval system, with Bob, his manager, his manager’s manager and Lynne from accounts, ploughing through the process of dealing with Bob’s $5000 business trip claim.

Once you’ve configured a PaaS app to model whatever it is you want to model, you can publish the app to the world, often as something that other people can buy and customise for themselves and their own businesses.

Variations around this theme include companies devoted to: creating complex workflows; providing sets of micro-services; pain-free hosting for code.

General characteristics of PaaS

Without giving what would probably be a boring account of all the companies I looked at, there are several axes along which PaaS seems to range which it is worth looking at. I’ve picked out a couple of example companies that fall along each axis.

Building a business

Several PaaS companies highlight your ability to use their platform to run a business. That can mean several things: you use the app you make to help run your business; you use the app as a part of your own customers’ experience; you run a business selling the app to other companies to use with their customers. Some companies cater for all these scenarios, others specialise in one or two.

If you’re building an application to use with all your customers, it makes sense to make it a multi-tenanted system – that is, the different customers all log-in to the same app, but see whatever is appropriate to them. If you are building an app that other businesses will sell to their customers, you’ll want something a level deeper – multi-tenancy within multi-tenancy (erm, Inception?).

Apps for your own use: Zoho Creator, TrackVia, Iceberg
Build your shop: Caspio Bridge, Wolf Frameworks
Shop-within-a-shop: WorkXpress, Rollbase, LongJump

Technical accessibility

If you’re a no-hoper when it comes to HTML and you’ve never heard of PHP, there are PaaS products for you. They will help you model your business and its processes and do helpful things like sending you emails when your tasks are late.

Equally, some products require someone versed in the vagaries of Microsoft systems integration to get anything out of them. However, if you have the requisite knowledge, you could be integrating with your Active Directory or performing complex database queries to help the system make decisions.

Anyone could do it: TrackVia, WorkXpress
You’ve just come off a web dev course: Zoho Creator, BlankSlate, Iceberg
You’ll need a seriously hardcore dude: Skelta, LongJump

Access to the bare metal

If you’ve ever used Salesforce, you’ll know that almost every Salesforce app looks the same. This is not an adequate level of control over the experience. Ideally, a PaaS product should give you – the app developer – enough power to control your customers’ and their customers’ experience (hopefully whilst providing tools to make this easier than coding from scratch). Some companies have a stab at this (even if they don’t make it very easy), others lock the experience down.

Complete control: BlankSlate, LongJump
Not quite like putty: Zoho Creator, Rollbase, WorkXpress
You do it OUR way!: Skelta, Iceberg

Presentation: AJAX vs. templates

This is not PaaS’ strong point. It seems very few PaaS companies expect there to be a presentation layer beyond Salesforce.com-style tabs and tables, which is a shame.

You can pretty much take it for granted that online products provide API access to read & write your data. PaaS products are online products and that assumption seems to hold good with most of them. This of course means that you can create experiences all of your own by writing AJAZy mashups. This isn’t ideal in practice, as it leaves the non-JavaScript browser without an experience at all, not to mention that AJAZ-heavy apps are unlikely to function appropriately on a mobile; SEO and accessibility are concerns as well. Unfortunately, some PaaS companies actively promote this method.

You could employ an app developer to use the PaaS API’s as a substitute data store, but this approach does seem a little odd given that a stated aim is to take the developers out of the process, but anyway…

The PaaS companies who have their heads screwed on correctly, manage your presentation layer using templates, interpreted on the server. However, you are often straitjacketed into using a particular layout. It would be a valid PaaS model to offer you an easy way to hook in a presentation layer of your choice, and since an app’s appeal very often benefits from decent visual presentation, this model could look very attractive.

AJAZ-only is the way: Wolf Frameworks, BlankSlate, Caspio Bridge
Templated goodness: LongJump, Zoho Creator

But does any of this suit?

My overall impression from looking at around twenty-five PaaS companies, and deeper at a dozen, is that everyone wants you to think their way, and that even though webby people are generally supportive of open data, there is something very “lock-in” about the way you put these applications together. This includes the feeling that you have to get into their developers’ heads to understand how you should construct an application; that your application is really just tweaking something that’s been set up in advance, both functionally and visually; that no-one wants to play nicely with any other tool-providers out there.

Then there’s the question of whether the objects/properties/process model is as straightforward a mapping of the real world as is claimed. Even if an entire business can be abstracted to these bare elements, the difference between two businesses is more than skin-deep, and so this abstraction feels hollow. I am troubled by the observation that I struggled to find any examples of PaaS offerings backing good public websites and services. Only BlankSlate had anything attractive and functional to show, and they had integrated with existing websites (BlankSlate are entirely focused on providing APIs).

The main advantage to the craft of web development and web design is that you are free to imagine any types of interaction and see those brought to life. You design and create both public and private areas, and hand-code the logic that links the two. Normally, this involves a creative and complex response to a client’s problem – a design process.

I think that the experience of use, which is the end result of a design process, is the most important facet of an online system. In my opinion, PaaS companies are neglecting this, and they appear to imagine their customers want to build applications for robots. Even if a PaaS app is only destined to be used inside a business (which it would appear they are in the vast majority of cases), that is no excuse for a bad experience. Haven’t big-company employees been complaining about the state of their corporate IT for decades?

Web development by web developers is something approached with a toolbox. What makes a tool? Something that is self-contained and has its part in the bigger job – a favourite framework, or an image editor, for example. The tools work together to turn stuff into useful stuff. PaaS is supposed to be bringing the experience of creating application development to the people who are coming up with the needs for them – “business” people. Most PaaS products do not look like a toolbox, but a single, infinitely complex tool. And when an app is built, it’s likely the people using it will be doing so through the tool used to build it i.e. itself.

Something’s gone wrong here.

So what do I want?

Here’s my shopping list for PaaS:

I want the typical PaaS setup to resemble a toolbox, full of useful things that you use to create experiences. The output is not just the tool, reconfigured.

I don’t want to fight with my tools – they should be tuned to the context they will be used in and they should respond to my touch (laggy interfaces are a massive turn-off).

The best (web) tools are those you can extend in a modular way with plugins. They play nicely with other tools, exporting and importing files in standard or commonly-used formats. People get passionate about them, because they let you exercise your craft.

Tools should talk JSON (or, if necessary, XML). While we’re on the J-subject, JavaScript is spoken by many, and JavaScript on the server got hot a while ago – if you want to empower less-technical people, start supporting it.

Everything you create should have a URL and behave as a RESTful resource. Then people can do cool things with their resources you didn’t expect.

Notifications over HTTP is the underpinning of workflow. The thinking behind Web Hooks is very appealing – systems talking to little blobs of code on the web. This keeps things nice and open.

Open source used as a learning process: almost everything a person makes is not worth hiding and definitely worth sharing. In an environment where people are working with similar systems, open source will make people make better things (we don’t have to be talking code – process, procedure, example are all good).

Finally, don’t try to do everything. Not everyone needs to write their own process editor or form maker, nor do they need to invent their own cloud or firewall.

The companies

This does not include everyone who thinks they are doing PaaS (Google App Engine and Heroku are not on my list). My investigation was focused on developing applications with less technical skills, but I’m mentioning all the PaaS-esque companies I found in case they are useful to someone. In no particular order…

Generally convincing

TrackVia
BlankSlate
Zoho Creator
Rollbase
Iceberg
SnapLogic
Skelta
Wolf Frameworks
LongJump
WorkXpress

Generally unconvincing

Caspio Bridge
WyaWorks
QuickBase
Ragic
WaveMaker
BungeeConnect
ProcessMaker
Microsoft Dynamics
AppPad
Force.com
Google Scripts
DabbleDB
tarpipe
Boomi AtomSphere
Informatica Cloud
Hubspan
Cast Iron OmniConnect
ElasticApps

The data is likely to be a bit rough and I used data from different years indifferently, but I was only aiming for a rough idea so I think the conclusions are valid.

Here are the headlines, the data is in a Google Spreadsheet you can play with here.

Employees of the world’s wealthiest companies pull in an incredible amount of cash

The world’s most financially successful companies boast a significant amount of revenue per employee – an average of $1.17m, with Fannie Mae and Freddie Mac (US mortgage megaliths) standing out at front with an amazing $8.7m per employee between them (this dates from 2007, pre-global financial meltdown and government takeover, but still…). Even the lowest earnings per employee I looked at was around $114k, significantly above the US average salary of $32k.

This has made clear to me how much of an economic heavyweight successful companies can be. It is pretty amazing to see that for every single person Fannie Mae, Exxon Mobil, Legal & General or Goldman Sachs employs, millions of dollars are being pumped into the US economy.

Big doesn’t mean rich

Interestingly, the world’s most people-heavy companies were not showing such impressive financial results – whilst the average revenue per employee was up near $200k, the highest didn’t even break $1m and the lowest was just under $12k (although this is Indian Railways who employ 1.6m people – I couldn’t find the average Indian salary but it is likely that $12k is several times bigger).

The big difference between the earning potential of the world’s wealthiest and biggest companies could come down to the difference in industry – those with the most staff tended to be in manufacturing, infrastructure and retail, with the richest companies circulating around the world’s oil and gas, healthcare and finance.

Most companies don’t grow past 500k heads

I wondered whether there was any pattern of companies increasing their revenue per employee up to a certain size, and then becoming more inefficient per head as they continued to grow, so I made a graph for the world’s 38 largest companies:

What this shows must be taken with a pinch of salt given that country of origin is not shown. However, we can see that passing half a million employees is very hard; it is also very hard to do that whilst maintaining a high revenue per head.

There appears to be a weak correlation between increasing a company size between 250k and 500k employees and decreasing revenue per head. It would be interesting to expand the data set to include smaller companies.

thanks to flowerhouse on flickr

The idea of running JavaScript on the server has been around for a while now (think Jaxer back in 2008), but it recently got a big boost with the featuring of Node.js at JSConf in November 2009. Node.js found immediate fame by demonstrating blinding performance as a web server, and by building on the hotly hyped V8 JavaScript engine Google bundled with Chrome.

I have a big interest in server-side JavaScript (SSJS) because I generally code in the browser and would enjoy being able to make things happen on a server without having to resort to another language. The ideal would be to take client-side code and run it unchanged on a server. The last step is pain-free application hosting – call it “Platform as a service” for want of a less boring name.

Over a year ago, Joyent bought Reasonably Smart, a cloud provider of SSJS, and subsequently transmuted it into Smart Platform, which runs on their distributed infrastructure. This followed the shining example of Heroku and Google App Engine, in that application deployment became a matter of pushing some new code to a Git repository online. For me, this was fantastically attractive, as I avoid touching servers as much as realistically possible. They came out with Smart Platform shortly before the demise of AppJet’s free service, which I had been happily trying for a while, as it did much the same thing.

Nearly a year on, and Smart Platform hasn’t really taken off, if Google Trends is anything to go by. And my ambitions to run my entire web estate on identical server-side and client-side code have rather fallen by the way-side. I am happy to see that Smart Platform now has a permanent full-time coder (@konobi), who is making Smart Platform play nicely with the CommonJS spec for server-side JS, but I don’t yet know when Joyent are going to drop a new release, or where they’re going with it.

Enter Node.js. The interest in Node.js has stayed high since its November launch, with developers building an assortment of frameworks and tools on top of it or with it, in effect legitimising it as a serious development environment for software running on a server.

Of significant interest to me is the jsdom project, which brings the browser environment to Node.js in a similar way to how Env.js brought it to Rhino (and Ruby). Env.js has supported jQuery since the get-go, and there are rumblings of jQuery support in Node.js via jsdom. Both these situations inspire joy as, if they pan out successfully, I’ll be able to use one methodology for writing and testing JavaScript applications, whether they run in the browser or on the server. Unfortunately, I’ve not seen Env.js working on any hosted platform (although Smart Platform may get it soon).

The number of cloud providers for Node.js has increased from 0 to 2 very recently: Heroku has announced a very experimental Node.js stack, and ElusiveHippo is in development, releasing accounts slowly. I should probably also mention that Ryan Dahl (who created Node.js) works for Joyent, so I wouldn’t be suprised if a Smart Platform-style service came out for Node.js.

Now then, if Coda starts supporting Git, or I start doing all my code editing in Bespin, I think with a bit of fairy-dust I’m going to have a pretty slick JavaScript-only setup fairly soon…

by Dreamtargets on flickr - /photos/dreamtargets/1085206378/

It’s not every industry where you can be a 30-year old and legitimately claim to have been working in the industry since it’s birth. The field of web design is one of these industries, and the nature of the job has changed significantly since the days when animated gifs were the height of sophistication. I can’t claim any knowledge of what it was like to be a web designer in the late 90′s – the closest I can come is that I had a subscription to .Net magazine. However, I do know what it’s like to be a web designer now and I know that it is a badly named job.

People in the web industry tend to be labelled either “web designers” or “web developers”, the assumption being that you either draw the pictures or write the code. This may have been a reasonable separation at one point. The truth as I see it now is that the web designer has progressed from writing HTML and CSS to taking responsibility for everything that happens within the browser. Web developers have retreated to the increasingly complex job of moving and processing data, around and between servers.

This means that web design, in practice, is a combination of typography, human-computer interface design, graphic design, rapid prototyping, JavaScript programming, HTML/CSS, agile product development, to name a selection. The modern web designer understands the significance of REST and HTTP, and why they make her job easier. She may even know regular expressions. If there is another word to replace “designer”, which captured the spirit of experimentation, creation and science that goes into modern web design, I am stuck to think of it.

Web design has flourished as a design profession – matured enough for an average project to bear the hallmarks of the kind of “design thinking” you might find amongst architects or industrial designers. This is all for the good. But web design is hard – there are barbed-wire boundaries between the work of web designers and those that surround them: the web developers, the content authors, the artists, the project managers, the business development consultants. Web design is relatively straightforward in isolation; meshed with all the other people involved in a project, it quickly becomes unstable. In my opinion, what holds the industry back from developing beyond a craft – that is, a complex and manual task – is the absence of good tools.

I overheard a conversation recently about why Flash became so popular with designers and has remained so, despite a strong feeling opposing its indiscriminate application. The problem boils down to one of tooling – Flash applications are built in beautiful, assistive development environments, which produce cross-browser and cross-platform applications. Web sites, on the other hand, are usually built in text editors and involve a significant investment of time to tweak and test for all the browsers in which they are likely to be run. Adobe produce compelling videos demonstrating how their tools simplify workflows and allow multiple professions to work together. Web designers generally have to “throw things over the wall” or duck things being chucked in their direction.

Specifically, I’m interested in seeing solutions to these sorts of problems:

• Why isn’t it easy for content authors to decouple their stuff from the ongoing design of a website?
• Why do I design a website in a different environment from the one it is going to be deployed to?
• Why do I have to cut up PhotoShop comps into web pages and then cut up those into templates?
• Why can’t I change the use of a single colour across a website by changing it once in the stylesheet?
• Why can’t two web designers work on the same web page without it being a pain to maintain?
• Why does everyone have to diagnose, fix and learn the same cross-browser tricks?

I’ve been developing a TiddlyWeb application on a local server on my Mac. This is fine for when I want to test in Firefox, Safari, Chrome, Webkit and others, but not so hot when I want to test in IE6/7/8. Virtualisation makes the general problem a lot easier, and I run VirtualBox for that purpose.

Unfortunately, accessing a locally running web server, rather than plain ol’ Internet, gave me some problems, so I thought I’d write down how I managed it.

Generally, to start up a TiddlyWeb instance, I’ve been using:

twanager server localhost 3000

I can point a browser to http://localhost:3000/ and I’m away. If I want to run on port 80, I can use:

sudo twanager server localhost 80

and then I can point a browser to http://localhost/.

The key thing to getting my virtual machines talking to my local server is to run TiddlyWeb on an IP address, rather than on “localhost”, which I had been doing. The IP address to run the application on is the IP address of your machine on the network. So how do you get this?

Given I’m using a mac, the non-confusing way is to open up System Preferences, hit the “Network” icon and read off the IP address in the “Status” section.

The more confusing way is to open up a Terminal, type in ifconfig and read off the IP address:

With your IP address in hand, you can now use twanager to start up TiddlyWeb on an address accessible to your virtual machines:

twanager server 192.168.1.71 3000

Then you’ll be in IE testing hell in no time!

It has therefore been something of a shock that, over the last six months, I’ve become a convert to time booking. This transformation has been so complete that I book time to all the projects I work on, even if I’m not billing a customer. The reason I do this is simple – far apart from the homicidal minute-by-minute accounting of the lawyer, keeping a record of how I spend time brings a number of benefits, the most pronounced of which is a change of behaviour to spend time doing what I know I want to be doing. This might sound frankly un-earth-shattering, but as I hope to make clearer, knowing you’re doing what you want to be doing feels good, especially if you can get there without it being burdensome or annoying.

Why I book time

This breaks down into three explanations, which build on top of each other: knowing what I’m doing, knowing I’m doing what I want to be doing and doing what I’ve said I’m going to do.

Knowing what I’m doing

I recently carried out an experiment on myself, where I kept a diary of everything I spent time on for three months and then analysed the data to see where my time was going (I’ve yet to write this up, although the sister experiment on what I spend money on is here). In advance, I’d predicted what I spend time on – things like sleeping, eating, hanging out with friends – to see how accurate a picture I had of my own doings. The outcome showed that, although I’d been able to make a decent gut estimate of how I spent my time on habitual activities (such as sleeping), there was a wide gap of 30 or so hours (nearly 20% of the week) where I had no idea in advance what I was going to do.

It is not such a terrible thing not to be able to say what you’ve been doing, but it feels like we are under a lot of pressure to increase efficiency, live life faster, sleep when you’re dead, etc. etc. Even if you don’t buy into this nonsense, it’s likely you’ve wished there were more hours in the day at least once. How can you improve something if you can’t measure it? Writing down what I’m up to obviously means I have a much better idea of what I’m up to.

Knowing I’m doing what I want to be doing

I don’t think I’m alone in finding it easy to get to the end of a day and think “very good, martini time. Now then, what exactly have I achieved today?”. It’s a somewhat more pronounced feeling if I get to the end of a week and think similar thoughts. It’s easy to brush off the question and determine to be more memorably constructive the next week, but at some point it starts to feel like there’s a lack of control over your own time.

I do think it’s important to feel that you’re doing what you want to be doing, rather than just reacting to things, bouncing about. Having a written record of where my hours have gone means I can’t just kid myself into thinking I’ve been terribly productive when I haven’t – initially this record is an uncomfortable kind of crutch. However, I think the discomfort is worth it, as after a short time, making myself aware of what I’m doing means I change my behaviour to be happy with that record.

Another thing worth noting is that once you feel confident that you’re doing things you want to be doing, all the other things that previously seemed so pressing now seem less so. In other words, you’ll end up choosing how you spend time.

Doing what I’ve said I’m going to do

Diets, fitness programmes, personal development plans, business development – many things take more than a week to come to fruition, but since it seems natural to think of time in a rhythm of the week and the weekend, it’s easy to become dispirited if looked-for effects take longer than a single week to surface.

One way of making it harder to stop doing things you’ve previously decided you want to be doing is to have the fact that you’re doing them written down – it feels way harder to stop something I’ve started when I can look back and see what progress I’ve made. It’s also easier to succumb to continuity and copy across activities from an earlier week than it is to commit to new ones: if I can see I’m on the way to finishing something, that makes it harder to start something shiny and new. Which brings me on to a bonus benefit…

Avoiding kittening

My habit of writing down what I’m doing means that I often have to expend effort to change what I’m doing. I like to avoid effort, so I’ve tended to want to avoid changing what I’m doing – my behaviour has drifted naturally towards spending longer periods of time on one thing rather than multi-tasking fruitlessly.

How I book time

Now you’re totally convinced of the need to do some time booking of your own, you will be worrying that it is going to take you forever to keep up to date. Fear not! Even with a mild tendency towards data-OCD, it takes me somewhere between ten minutes and an hour per week. As I have said, I like to avoid effort, so I don’t go much detail unless there’s a good reason to (such as wanting a detailed record for billing).

At the start of the week, I take the time to write down what I want to be doing that week and an estimate of how long I think each thing will take. At the end of the week, I write down whether each thing has been finished or not and compare my estimate of how long something would take with how long it actually did.

At the moment, I’m using two methods to book time – a broad estimate of time-spent vs. an hour-by-hour account.

Broad

At the end of a day, if I know I’ve spend a chunk of time on something, I’ll write that next to the thing, with a brief note of what I did. This is pretty rough, and I’m only bothered about the accuracy being to the nearest 30 minutes or even hour. I think this probably takes ten minutes in total over a week.

Detailed

If I’m doing something that I want to keep detailed notes for, I’ll write down each day when I start spending time on it and what I’m doing as I go along. When I change to something else, I’ll record the end of that period. The accuracy is to the nearest five minutes. I usually have one or two projects running like this at any one time and over a week it might take closer to an hour than ten minutes to make the record.

What time booking is not for

I do not advocate the measurement of time-spent as some sort of performance metric. It is not right to reward yourself or someone else just because a lot of time has been spent on something: reward outcomes, not efforts.

However, the ability to accurately forecast how long things will take you and to do what you say you will are both measurable traits you ought to encourage.

The most striking thing about being a visitor at the summit was how large the community was – at least 300 people turned up. It was later made doubly striking when I found out that almost all of those people don’t get paid to work on or with Maemo – in fact, the N900 pre-production loan we were treated to was only available to people not on Nokia’s payroll.

This was my first experience of a cohesive open source community outside of the TiddlyWiki community – it gave me much more faith in the ability of large numbers of people to work together to produce something, without needing a centrally-enforced power structure coercing them to do so. Everyone we spoke to had a very different reason for participating in the project, often because their participation gave them experience or tools that helped them sell services to other companies. Others contributed simply because they found it interesting (or earnt them wuffie).

The whole community seemed to be attached to Nokia through a single employee – Quim Gil – and, almost surprisingly, there was ’nuff luv felt for the man. It really seems as if Nokia have done a good job “stewarding” the Maemo community, filling such gaps as needed filling (graphic design, workshop hosting) and ultimately, being rewarded with a piece of software that represents an entirely different understanding of what it means to be a smart phone OS.

And that is killer with Maemo – Nokia’s N900 is obviously a competitor to the iPhone, but the experience of using it is nothing short of using a tiny computer. The “app” metaphor is nowhere near as prominent as on the iPhone or on Google Android – applications can also surface in deep integrations with other system software. As an example, the N900 ships with Skype, although you’d never know it – there is no app icon to click on. To make a Skype call you first add your account as a “VOIP and IM” account and then choose “Skype call” instead of “Cellular call” from the dialer. (Cellular? I’m sure there will be a UK localisation by the time the device is released in Blighty.)

Another departure from the standards set by both the iPhone and Android is the acceptance of web technologies as the building blocks for Maemo applications. Launching at some point in November, Nokia Web Runtime will allow packages, suspiciously similar to W3C widgets, to be installed on the phone. HTML and CSS control an application’s appearance and JavaScript controls the behaviour and taps into the native abilities of the device, such as the camera and accelerometer. The fact that these applications can also make it into Nokia’s Ovi Store will mean that the huge financial appeal of Apple’s App Store is extended to thousands times more people than the Objective-C massive.

[Update: Palm took a big move toward the web app model with the release of the Palm Pre and webOS]

The N900 isn’t going to convert many Mac fan-boys (self included), but it’s a damn fine start at a different approach. Keep an eye out for the N910.

I’ve recently been putting together an Adobe AIR application using HTML, CSS and JavaScript (aka Web Standards), which is very empowering and everything, but turned out to be a little tricky to write tests for. All the interesting stuff I wanted to do through AIR’s window.runtime object, such as opening native windows and messing with dock icons, is missing from the browser if you’re trying to test the JavaScript components in isolation. The ideal would be able to run your QUnit tests within the AIR runtime itself.

Fortunately, it’s straightforward to create a test app that wraps the QUnit test runner in the AIR runtime and exercises your code. Here’s how I got going:

Setting up the file structure

The folder structure I am using for the AIR app is like this:

/myApp
   myApp.html
   myApp-app.xml
   /js
      myApp.js
   /css
      styles.css

The myApp-app.xml file is the “application descriptor” that AIR uses to create the .air package when you build the app.

I added two folders at the same level as /myApp, to contain the test framework and test code; the complete structure looks like:

/myApp
   myApp.html
   myApp-app.xml
   /js
      myApp.js
      AIRAliases.js
      jquery-1.3.2.min.js
   /css
      styles.css

/myAppTests
   runner.html
   tests.js
   myAppTests-app.xml

/qunit
   testrunner.js
   testsuite.css

Configuring the test app

The application descriptor for myAppTests is not very different from the descriptor for myApp; here they are:

myApp-app.xml:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://ns.adobe.com/air/application/1.5">
    <id>examples.html.myApp</id>
    <version>0.1</version>
    <filename>myApp</filename>
    <initialWindow>
        <content>myApp.html</content>
        <visible>true</visible>
        <width>400</width>
        <height>800</height>
    </initialWindow>
</application>

myAppTests-app.xml:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://ns.adobe.com/air/application/1.5">
    <id>examples.html.myAppTests</id>
    <version>0.1</version>
    <filename>myAppTests</filename>
    <initialWindow>
        <content>myAppTests/runner.html</content>
        <visible>true</visible>
        <width>400</width>
        <height>800</height>
    </initialWindow>
</application>

The main structural difference is that myApp-app.xml has an initialWindow.content property set to myApp.html, whereas myAppTests-app.xml refers to the test runner from a directory above: myAppTests/runner.html. This is needed because the test app needs to have its working directory set to the top-level of the file structure, otherwise runner.html won’t be able to get at all the files it needs in other directories (more below).

Putting the correct files in runner.html

Here’s a runner.html that works with the folder structure described above:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
		<title>Test Suite</title>
		<link rel="stylesheet" type="text/css" href="../qunit/testsuite.css">
		<script src="../myApp/js/AIRAliases.js" type="text/javascript"></script>
		<script src="../myApp/js/jquery-1.3.2.min.js" type="text/javascript"></script>
		<script src="../qunit/testrunner.js" type="text/javascript"></script>
		<script src="../myApp/js/myApp.js"></script>
		<script src="tests.js" type="text/javascript"></script>
	</head>
	<body>
		<h2 id="banner"></h2>
		<h2 id="userAgent"></h2>
		<ol id="tests"></ol>
		<div id="main"></div>
	</body>
</html>

Running the test suite in debug mode

The easiest way to run the test suite is to use the built-in Adobe Debugger, which lets you test your app without having to build it into an AIR package:

adl myAppTests/myAppTests-app.xml .

Don’t forget the ‘.’ character on the end – this tells the debugger to run with the top-level directory as the working directory – without it, the default is the same directory as XML file.

I had my Flip camera with me and took some videos as we ran round. Some of them are a little shakey (some of them are nausea-inducing). Nevertheless, I’m happy to have a record of Eddie’s gutsy sprint down the Mall for a 5-hour personal best, knowing literally how far he’d come but only guessing what must have been going through his mind.

Meeting Eddie

As we waited in the rain for Eddie to get to Stratford, I couldn’t help but notice that he has over 1 million Twitter followers.

Pit stop

You run 1000 miles and your crew can’t even keep up…

Eddie meets a fan

It was amazing how many people shouted encouragement or beeped their horns as we ran through London. One guy actually leaned out of his van to give Eddie a donation.

The rickshaw

The other side of the lens, this guy pedaled the camera crew smoothly through London traffic, displaying some fine maneuvers weaving between cones.

Catching up

Quite early on, I ran in the opposite direction to tell the producer we were moving on. I didn’t realise Eddie was going to set such a punishing pace all the way from the Olympic stadium to Aldgate East, where I finally caught them.

A chat with a doctor

Eddie’s put up pictures of his battered feet (I’m not providing a link!) to show the physical effects of all his running, but this doctor thought his shins must be taking a serious beating. Eddie did admit to all the muscles being “badly bruised”. Ouch.

Legging it

Eddie had an unnerving habit of picking up the pace just as you were getting comfortable. You wouldn’t know he’d been running for 50 days…

Over London Bridge

The traffic was blocked off from our side of the road and a helicopter flew overhead – it felt a lot like we were in a 5-man London Marathon.

Approaching St. Paul’s

Could seeing St. Paul’s and knowing there was only three miles left to go failed to have had an uplifting effect?

A new supporter

Danny joined at St. Paul’s. I was really expecting there to be a lot of people running in support, but there was just the three of us. I guess the torrential rain made a difference…

Embankment

Pit stop – the camera-crew needed directions once again.

South Bank

Eddie ran past the crowds by the London Eye and straight into a tourist, providing them with a pretty good story to tell back home.

Parliament Square

More speed from Eddie as St. James’ Park swung into view and we neared the last mile.

Minor drama

You can’t run 1100 miles and not have your sprint-finish captured on film, right? So where are the crew?

Buckingham Palace

Crew located, we sped on – just one straight, long road to go.

Down The Mall

This is where the temptation to attach “Chariots of Fire” gets very strong. I haven’t, so if you are that way inclined, please imagine it playing in your head.

Eddie’s Ices

Free ice-cream is never a bad thing.

Gracious End

Personally, I would have collapsed at this point, but Eddie had a nice long chat with the press and then hobbled down the steps of Trafalgar Square signing autographs and talking to people. He posed for some photographs with us.