To handle, the Chromebook (the UK gets the Samsung Series 5) is chunky, lightweight and quite a bit slimmer than my 11″ MacBook. To browse upon, things move along smoothly (until you hit 1080p HD video or Angry Birds) and the little keyboard changes, such as a search key that opens a new tab, are kinda fun. Sadly, the whole thing feels experimental, since several of the Chrome extensions I tried don’t work properly, nor do some websites. As examples, the LoveFilm website wouldn’t stream films; the Chrome store let me install IETab, but then it wouldn’t run (no IE, right? For a moment, I thought they had conjured some magic).

I do try to keep all my documents, code, email and the rest on the web, so I figured I’d be in a good place to adopt a web-only computer as a lightweight, portable all-purpose machine. And I would be willing to give the Chromebook a go. But not for £400. And here’s the big problem – £400 buys you a lot of laptop these days. I figured I’d pick up a Chromebook for a couple of weeks and try it out – if it bombed, I could always return it. However, true to form, PC World’s legendary customer service team were unable to give me a straight answer about their returns policy. So I’m still on the fence.

Incidentally, since the Chromebook has 3G built-in, this makes it, in a connectivity sense, awesome. It actually has a SIM slot, so you can stick in whatever SIM you like. This is a part of the future Apple are most definitely not making a big noise about. I don’t think a hardware manufacturer is going to overcome all the necessary hurdles to make a machine that can roam on 3G, and roam affordably. However, mobile operators and specialist firms (WorldSIM, abroadband) probably can, so letting people put their own SIM in your device makes a lot of sense.

Fortunately, from the point of view of amateur photographers and professionals all over, Twitter looks like it is maintaining its existing copyright policy, whereby the submitter maintains copyright over any content.

The full terms page is here, but here are the salient parts, with comment:

“You retain your rights to any Content you submit, post or display on or through the Services. By submitting, posting or displaying Content on or through the Services, you grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense) to use, copy, reproduce, process, adapt, modify, publish, transmit, display and distribute such Content in any and all media or distribution methods (now known or later developed).”

You keep your rights over your content, but as far as the use of it on Twitter goes, you don’t have a say.

So far, so straightforward. The next part I am quoting in full:

“You agree that this license includes the right for Twitter to make such Content available to other companies, organizations or individuals who partner with Twitter for the syndication, broadcast, distribution or publication of such Content on other media and services, subject to our terms and conditions for such Content use.

“Tip – Twitter has an evolving set of rules for how ecosystem partners can interact with your content. These rules exist to enable an open ecosystem with your rights in mind. But what’s yours is yours – you own your Content (and your photos are part of that Content).

“Such additional uses by Twitter, or other companies, organizations or individuals who partner with Twitter, may be made with no compensation paid to you with respect to the Content that you submit, post, transmit or otherwise make available through the Services.”

This is one place to signal caution – whilst you do retain the rights over any imagery, Twitter are allowed to make use of it to their advantage, and you’re not entitled to claim a slice of any pie.

In case you don’t know Airbnb, Brian describes the company as “a community marketplace for space” – essentially it’s a way for people to rent out apartments, bedrooms, castles, private islands…

One of the most interesting things from the video was the description of Airbnb’s strategy for getting press coverage during the 2008 Democratic National Convention (DNC) in Denver. Brian and friends spotted an opportunity, since there were an expected 80k visitors and only 28k hotel rooms. The challenge was how to get CNN to cover them.

Their story pans out something like this:

• local Denver bloggers were writing about the problems of fitting all the convention attendees into the city’s hotels
• Airbnb went to Google News and typed in “DNC Housing Crisis” to find the bloggers
• Airbnb wrote to all the bloggers saying there was a new way for people to list their bedrooms for rent – Airbnb
• Denver bloggers started to write about Airbnb
• Airbnb contacted the Denver local news to say what they were doing
• local news Googled Airbnb and saw that people were writing about them and did a story about them
• regional news (Denver Post and the Rocky Mountain News) saw that local news were writing about Airbnb and did a story about them
• CNN were following keywords about the DNC and saw that everyone was writing about Airbnb and did a story about them
• BOOM

Incidentally, Airbnb almost became a cereal company, launching “Obama O’s” and “Cap’n McCain’s” when they were stuck for traffic and cash.

I see the operator pick up two cardboard cups. They have a terrible pattern on them. So I say,

“Sugar in one please”. I’m hedging my bets. “Brown.”

The ground coffee comes out of the hopper without a whiff. There is a light tamp, if you can call it that, when it comes at a 15 degree angle from a small plastic roundel, attached at thorax height to the hopper. I suspect a force of 20N at best.

Now it starts.

The portafilter is screwed in place, the cardboard cups are put straight under the nozzles and the button is pressed - the little button, which could have served admirable duty not ten seconds ago, flushing tepid water from the front of the boiler tube – the little button, with the two silhouettes of shot glasses on it, trying its best to remind the operator which vessels to extract espresso into.

“How many shots do you put in your cappuccino?”, I ask, smiling.

“It’s up to you”, is the reply, as the operator picks up a dirty milk jug.

“Oh. Well, how many normally?” I pursue.

There is a pause, before the operator says,

“We normally fill half coffee, half milk”. This starts a shiver of panic.

The steam valve is turned and the banshee is unleashed. The wail is awful to hear, high-pitched one moment, low and gurgling the next. I wonder how many times this same, poor batch of milk has been exhaled. Steam rises and there is a smell.

The pour passes by without incident. The operator’s back is turned and I am staring at my croissants. I am given the two cardboard cups with thin, white plastic lids, on a recycled cardboard tray.

I like to take my first sip from a cappuccino with the lid off, and cover my tongue in silky milk foam. I take the lid off the coffee with the sugar in it. There is a surprisingly gentle-looking white layer, powdered with brown. I sip.

I can’t be sure which hits me first – the bitterness or the scalding heat. As my eyelids close in recoil, I think about saying something, but of course, I don’t. I put my £3.80 down on the counter. Ten minutes later, I drop both cardboard coffee cups into a nearby bin.

I really like what Sauce are doing – amongst other things, they automatically video the tests, and they’re making it really easy to use their hosted service from behind your company firewall. What I didn’t like up until now was their pricing model. Sauce offered a 30-day free trial, which one would think would be ample to figure out whether you could get value out of their service.

However, this “free trial” model misses the mark for me. I find that my interest in (and therefore my signup to) a new service is piqued several weeks or months before I am actually in a position to use it. And once I do start to test something new out, my usage is faltering and tentative to begin with, only ramping up once I have accrued experience, reflected on it and figured out how the service fits in with everything else I use.

Big congratulations to Sauce, then, for twigging that there is another way to bag new customers – offering a small, but effective amount of their product, which you can use at your leisure. You could call this the “drug dealer” model.

The drug dealer model makes a lot of sense for online services, where the incremental cost of adding a new account is minimal, and the cost of usage is easily measured. In Sauce’s case, their free account comes with a cap of 200 minutes of testing per month – easily enough for me to run a few tests, see if they help my development cycle and build up the use of the tool – at which point, I expect I’ll be hooked.

I am not saying I had anything to do with the decision to offer a capped free account, but… http://twitter.com/#!/hugs/status/31074705414819841

About half way through (where I am now), he has one of the lead characters, a man called Dwayne, who is going crazy, tell a story of a Pontiac car manufacturer and their testing labs:

“We were given a tour of all the research facilities”, he said. The thing that impressed him most, he said, was a series of laboratories and out-of-doors test areas where various parts of automobiles and even entire automobiles were destroyed. Pontiac scientists set upholstery on fire, threw gravel at windshields, snapped crankshafts and driveshafts, staged head-on collisions, tore gearshift levers out by the roots, ran engines at high speeds with almost no lubrication, opened and closed glove compartment doors a hundred times a minute for days, cooled dashboard clocks to within a few degrees of absolute zero, and so on.

“Everything you’re not supposed to do to a car, they did to a car,” Dwayne said to Francine. “And I’ll never forget the sign on the front door of the building where all that torture went on.” Here was the sign Dwayne described to Francine:

© Kurt Vonnegut Jr 1973

The detailed list of destructions made me think about testing web apps like cars. So I had a Google for ‘destructive testing web’ and to be honest, apart from a research paper and a very expensive-looking testing suite. Not the glut I was expecting.

So, to any web app testers out there – what’s the word?

A bit of a show ‘n’ tell tonight at the fortnightly Async JavaScript meetup, hosted at The Skiff in Brighton… notes below.

Links for the talks ought to be added to the Async blog post (http://asyncjs.com/showntell3/) by the speakers.

The next Async features Kyran Dale (session 7 below) on module loading (‘requireJS’), in two weeks time, also @ The Skiff.

1. Mike de Boer (from ajax.org) – Cloud9 IDE

Written in JS (as a node app) for dev’ing JS. Nice. “npm install cloud9″

Mounts filesystem/WebDAV server.

You can write a node app, which is run as a separate app and has the output logged to a console. They’ll have an online version up soon.

Does live debugging, and you can variables real-time via breakpoints. You can also edit the code when execution is paused. i.e. hot-code swapping. He mentioned node inspector (what’s that?).

The code editor can cope with 134k lines of code. Which textmate can’t. Nice.

You get a command-line too, for using git (other version control systems coming later).

http://github.com/ajaxorg

2. Glenn Jones (Madgex) – Draggables

HTML5 experiment for dragging data between systems.

Lets you drag across browsers, which is cool. Also you can drag html files (and zipped html files!).

Really nice little thing with a bookmarklet injecting a draggable icon into a page (well, on Firefox).

Glenn is also working on a microformats parser that works cross-browser, which he will open-source.

3. Phil Hawksworth (The Team) – nodejs & ndistro – “multiple projects. quickly.”

I.e. how Phil works.

Problem with node is deployment (i.e. build) can be hard. Plus, the codebase is changing frequently. So how to cope?

ndistro – a node distribution toolkit (github.com/visionmedia/ndistro)

Note: installing involves running install script as root (sudo su Phil recommends)

You write ndistro files for each project, where you specify the version of node and any modules from github

Phil like ejs as a templating language

Phil has some very nice presentation techniques – videos of terminals and a funny, eased, scrolling of a webpage. Guess keynote == good?

Seeing as ndistro files are just bash scripts, you can nest another running of ndistro inside the ndistro file

expressjs = “almost” MVC for node

After a Q: Not sure if npm would play nicely with this.

4. Prem (@premasagar) & Graeme Sutherland (@grasuth) – Sqwidget

http://github.com/premasagar/sqwidget

The problem: widget developers have a really big problem developing something that runs in other people’s environments (which is like cross-browser development, but worse).

One solution: iFrame

Their solution: sqwidget.

It sandboxes CSS and JavaScript. This is cool, because you can do things like lightboxes, which you can’t do with iFramed widgets.

The widget is embedded using a DIV and its data attributes to do settings

Q: option to swap in different templating? A: yes. Built-in one is a hand-built library called Tim.

Q: licence? A: MIT

5. Mark Wubben, from Copenhagen (who needs a place to live in London) – Chrome2iPad

Problem: how do I get my tabs I have open in Chrome into my iPad?

Solution: Chrome2iPad.

There is a Chrome extension using Socket.io (a node module) which hotlinks to a webpage on the iPad to the Chrome browser via a Chrome extension

Not released on github yet. When it is available, it will be on http://github.com/novemberborn

6. Paul Downey (@psd, Osmosoft) – TiddlySpace

TiddlyWiki is a single-page HTML app.

I’m writing these notes in a TiddlyWiki…

TiddlyWiki is interesting because it can save itself when on a file URI.

All the plugins are written in JavaScript.

TiddlySpace is like TiddlyWikis in the sky. It’s slightly different from file-based TiddlyWikis, since you can follow people.

TiddlySpace is based on TiddlyWeb, which is an open-source hosting platform for tiddlers, with a RESTful API.

A tiddler in a TiddlyWiki is a div; a tiddler on TiddlySpace can be HTML, JavaScript, SVG – anything.

7. Kyran Dale (academia) – JavaScript physics

Impressed by JavaScript’s performance to do simulations.

Shows Craig Reynold’s Boids running 300 objects, drawn in canvas. Chrome on Linux. Real-time variable changing.

Now a robotics demo – 100 robots (Brightenbergs) with light-sensors and lights. They go mad. But without slow-down.

Next a magnetic controller. This one does some weird stuff, but again, in a peformant way.

Q: source? A: will be available, probably on a Mercurial repo (http://bitbucket.com/keirandale)

8. Morgan Roderick (@mrgnrdrck) – PubSub in JavaScript

Writes really large systems in JavaScript.

PubSub is messaging in JavaScript. It is an alternative to the “observer pattern” (see Java, apparently).

Keeps different bits of your system nicely decoupled.

Don’t use PubSub when you have 1:1 communication, or need accurate control.

http://github.com/mroderick/pubsubjs

Q: is is threaded? A: all messages are passed asynchronously. In terms of performance, it’s about 10x faster than jQuery.

Q: how is it different to custom events in jQuery? A: it doesn’t depend on the DOM

Q: how do you wake listeners up? A: They just get called. If a call fails, the exception is caught and it is called again.

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.