Joining Google

I mentioned I’m moving on from Osmosoft a few weeks ago and after 12days and a week of doing much less than one could ever have imagined, it’s time to announce where I’m going: Google. I’ll be joining Google as a Chrome developer advocate, which means focusing on HTML5, Javascript, the Chrome browser, ChromeOS, and related technologies.

I’m very excited about the role, for reasons best explained in terms of a timeline for the web. I see the history of web technologies divided into three phases and I believe we’re currently in the transition from the second to the third phase. Which is the starting context for this role.

Dark Ages (Web as a Black Art)

Rich web apps were hard work. Black art even. During this phase, I spent most of my time on server-side languages – Perl, PHP, Java/J2EE – and Javascript was a weird sideline. Taking an interest in the user experience, I always wanted to know more about this black art, since it’s the web technologies that touch the user and have the most direct influence over their experience with any application. But what paid the bills in the late ’90s and early noughties was form submissions and page refreshes. And most Javascript content was odd little ticker tape scripts you could download, not too much to learn from, and always difficult to achieve in one’s spare time. I think this was the frustrating experience for many web developers: not enough time and hard work. I did get by and pick up a few tricks here and there, but things only took off when the A-word was unleashed …

Ajax Era (Web as an Established Practice)

Everything changed five years ago, on February 18, 2005. Jesse James Garrett hopped in the shower, came up with the term “Ajax”, and published his thoughts on this rising architectural pattern. Many people bristle at the notion that a simple term, for something people were already doing, can make such an impact. “BUT I already knew how to do that!” they cry. Good for them. But the fact is, Ajax allowed the whole developer community to rally around this style of application. Events, blogs, books, libraries, tools, the whole thing flourished. I got seriously interested, recorded a podcast explaining the topic, and started diving into all the existing applications, which ultimately led to the Ajax Patterns wiki. All those applications, and many featured in the book, were created in the Dark Ages by brilliant pioneers who had scant resources to learn from. Today, such applications can be created at exponentially faster rates. This is thanks to improved knowledge, improved libraries, and improved tools.

There are historical analogies to this era, e.g. the rapid rise of the automobile industry once all parts were in place. In that case, it was more a matter of discovering new physical and engineering principles, whereas with Ajax, it was a superficial act. The browsers were already there, with a killer feature like IE’s XMLHttpRequest sitting largely unnoticed for five years. Few people had taken the time to really understand how they worked. It was the Ajax term to trigger the boom.

HTML5 Era (Web on an Improved Platform)

(I hesitate to call this the era of HTML5, as many things happening are outside HTML5, notably improvements to CSS and the core Javascript/ECMAscript language. But HTML5 is increasingly becoming a brand, much like Ajax in its heyday, a term that’s familiar to anyone with a passing interest in technology.)

The starting point for this era is the success of open web technologies. While we continue to learn more each day, we have the basics in place today. We know how to harness HTML, CSS, Javascript to make powerful libraries and applications on the existing browsers. This is where the Ajax Era landed us. We have seen some genius hacks. In fact, we have seen MANY ingenius hacks. On-Demand Javascript and JSONP, for example, are completely fundamental to the way business is done on the web these days, and is utterly a hack. Full credit to those who came up with them, but these hacks can only go so far. They can increase programming complexity, impact on performance, and cause security threats for those not fully-versed in their capabilities. And that’s just for the things we can do. The bigger problem is that we are heavily limited in our functionality on Ajax-Era technologies. We can’t do rich graphics or video, for example. So the next stage is all about improving the underlying platform. It’s not something an application programmer, however heroic, can do on their own. It’s something that has to involve improvements from the platform providers, i.e. the browser manufacturers and others.

To draw a line in the sand, take IE6. Although it was created back in 2001, we could do far more with it in 2004 (e.g. Google Maps) than we could in 2001, and we can do far more with it in 2010 than we could in 2004. This is because of all the knowledge, libraries, and tools the Ajax Era has provided. However, we’re in serious plateau mode now. We can continue to squeeze out 1-percenters, but the low-hanging fruit was plucked and digested a long time ago. The next stage has to be an improvement to the underlying platform, and that’s what’s going on today with modern web browsers.

Once you say “okay we’re now going to build the next-gen web platform”, you’re not just going to add support for round corners. So there’s been a truckload of effort going on, in HTML5 and beyond. Graphics in the form of canvas and SVG and WebGL and CSS3, media in the form of audio and video tags, semantic markup improvements, new form controls, offline storage, support for location-awareness. And much more.

We have the new platform and alongside it, we have the activity of understanding how to use the new platform. Not just understanding the parts, but the whole. How do you put all these things together in meaningful ways. Can we show custom-font text on a canvas? If so, how? And when does it make sense? And how to avoid performance problems? Or, to take another example, what kind of CSS transforms can we use to render videos? And since we can grab image data from the videos, what are some cool things we can do with that data? And all the while, where’s the graceful degradation story here? How do these apps look in older browsers? Most of the talk so far has been on the capabilities of the platform, not patterns of usage.

All these new capabilities take us to the place we’ve been aiming for all along: true applications deluxe, not just “html++”. Of course, there’s plenty of room for both of these, but we’re now in a place where we can really build true applications with all the capabilities of a traditional native experience. We’re seeing it in a big way in mobile space. The new model is all about sandboxing, doing away with the filesystem, and explicit permissions. Exactly what the web’s good for. They’re not only a good fit technically, but they’ve become the ubiquitous lingua franca among the programming community. The technologies are familiar, as are the patterns of UI design and code composition. Those patterns will continue to evolve with HTML5 and associated technologies.

We’re just scratching the surface here; there are exciting times ahead!

I’m not an official Googler yet, nor even a Noogler, as I’ve taken time off to chill, smell the roses, and pursue a few projects (like dusting off the homepage and … watch this space. Actually, watch that space). I’m starting in about a month. And of course, even when I am official, this blog continues to be my own opinions, caveat emptor yadda.

The role covers EMEA and I’m still based in London. Despite not starting just yet, I’m looking forward to participating in tonight’s Chrome/Chromium OS and HTML5 London event. See you there!

(I’m not the only one to announce a move to Google at this time. I’m looking forward to meeting and working with many of my talented future colleagues.)

TWelve Days of TiddlyWiki, TWelve Days of Osmosoft

I’m going to be moving on from Osmosoft soon. It’s been 18-odd months since joining and 3 years at BT. I’ve had a wonderful time here, worked alongside so much dedicated talent and energetic passion, and learned a ton about working according to the principles of open source, as well as new ways of working and thinking about things in a large enterprise. What I’m doing next is the subject of a subsequent post … this one’s about Osmosoft and TiddlyWiki and a new site I’ve set up for the occasion: 12 Days of TiddlyWiki.

I have to echo much of Jon Lister’s sentiments. I, too, am extremely grateful to Jeremy and JP for being brave enough to set up Osmosoft. It’s an organisation within BT that works predominately on the public internet and produces open source for everyone to use, but not in the mould of a “pure research outpost” or an “isolated skunkworks initative”. Osmosoft directly supports BT through the applications and components it produces, its involvement in open source policy, and its general involvement in BT’s software community, among other things. We just operate very differently to a conventional IT department. Oh, and we also make world class stock photos …

To celebrate my time here and to gently encourage myself to get a few things wrapped up, I decided to make a little microsite: 12 Days of TiddlyWiki. It will feature a new product for each of my final 12days at Osmosoft. And of course, it’s dogfooding: it’s powered by TiddlyWiki and if you peek under the RESTful hood, you’ll see it’s just another view into the main Osmosoft server, and could easily be mashed up however you please.

There’s one more benefit of Osmosoft working in an open source way to mention: Leaving is not leaving. And here I’ll echo another friend, Dion, who mentioned a similar effect when he moved on from the Bespin project … the code’s out there and I’m still able to remain part of the TiddlyWiki community. I had no idea how powerful TiddlyWiki was when I first joined. It’s a story that still needs to be told in full, but the bottom line for me is it scratches plenty of itches, and on that basis, I’ll still be using it and contributing back.

Over the Break

Quick mention of projects and writings outside this blog:

  • jQuery iFrame plugin – Stepped up work on this, as it was buggy and not very jQuery-plugin-like. Whacked it in GitHub along with test cases. Not all are passing on the 3058 day old browser, yet. This was a good opportunity to play around with asynchronous testing in QUnit and I was pleasantly surprised to find there’s good support for it – use stop() to suspend the test case (conceptually) and start() to continue it. QUnit Asynchronous tests.
  • Scrumptious reboot – Following Osmosoft’s decision to deploy everything inside a multi-user TiddlyWiki platform, Scrumptious has to be migrated to work inside of a TiddlyWiki. The final, pre-TiddlyWiki, Trails player you can see online. I’ve since begun work on an overlay plugin, which is a Claytons TiddlyWiki: the TiddlyWiki you’re having when you’re not having a TiddlyWiki; there’s a TiddlyWiki underneath for power-user functionality and a pretty generic UI on top of it. You can flip back and forth between a TiddlyWiki and a special overlay UI, which has full access to the TiddlyWiki state. It works by hiding all TiddlyWiki elements and pushing “style” elements to a DocumentFragment, so the operation can subsequently be reversed when flipping back. The first proof-of-concept is here (source in the TW repo). I’m psyched about this general approach for rapidly building web apps in a multi-user environment. TiddlyWeb provides a RESTful, permissioned, set of web services; and the UI can then be as flexible as you like. Ideally, each recipe/room would be in its own subdomain to help prevent XSS concerns.
  • reboot – Okay, it still needs some love, but my homepage is at least up-to-date now.
  • Server-Side Javascript article – Published Server-Side Javascript: Back With a Vengeance. Sums it all up really. I decided to submit it to ReadWriteWeb, rather than here or Ajaxian, because I figure i’s a good thing to make the wider audience aware of trends like this. Otherwise, it’s preaching to the converted to some extent.
  • End of Days for “View Source” – An editorial musing about the end of days for View Source. Turns out there’s going to be a SXSW panel on View Source and Alex Russell, who’s participating, has Save View Source effort.
  • It’s snowing and freezing in London, hence this Snowman mashup building on @webreflection’s efforts.

Happy Birthday, Blog

It’s five years and a thirty-seven minutes today since I hammered out those momentous first words on this blog:

FP! Garbles to ya! Doh, forgot this was my own blog for a second!

I started the blog primarily as a space to host podcasts. How irony!

It’s been a blast. Great way to reflect on things, get feedback, etc etc, you’ve heard it all before about blogging anyway, but it’s true. Thanks to everyone reading this.

I must especially thank James Robertson, whose talk at SPA 2004 helped explain what blogging is really about.

Update: Digg celebrates its fifth birthday. I never noticed Digg started the day after this blog. If only I’d added voting …

Music As She’s Developed

I made a little music mashup you might enjoy using.

A Little Music

As I was playing around with the new layout of this blog, I added a Last.FM widget to the sidebar. It looks like this:

(May not render if you’re reading this from a feed reader.)

Great. Now I can listen to trance from the blog. Trance is good for coding. So that’s ace. But I couldn’t stop there, could I?

Widgets, Widgets, Everywhere!

I made this page with 30+ gadgets in all sorts of genres. This is good for those times when I’m not coding and want to listen to something else. Being in the cloud, it means I can easily listen to whatever I feel like when I’m in an internet cafe or the such like. So even more ace.

Make Your Own Jukebox

In the spirit of sharing, you can easily make a page containing your own favourite music. The URL for the default music page resolves to something with a ridiculously long list of genres:

… which means you can hack the URL and make your own jukebox with your own genres and bookmark it and it will work and live on in the cloud and you too will be able to listen to your favourite music anywhere you go.

For example, you might be a more passionate fan of contemporary Japanese music than myself, in which case you would concoct the following URL and save it to your delicious bookmark manager to enjoy many years of musical gratification:,j-pop,j-punk,j-hop,j-rap,anime

Add A Player on the Fly

One other feature is that you can add a new player on the fly. This again is great for travelling around as it will let me easily listen to any genre I care for without even having to edit the URL.

(Unamusing trivia: I actually caused a bug at first by using “gray” as the colour name here. I’m used to working with American spelling for programming of course, but then is a UK company and the name you want is actually British spelling, i.e. “grey”.)

Obligatory Wishlist I’ll Not Really Get Around to Implementing But it’s Cathartic to Braindump it Anyway

If I was going to do more work on this, I would:

  • Make it into a widget-like portal which lets you add/remove/layout etc and save settings within a hackable URL (using Unique URL. You could argue the whole thing is useless as you could achieve the same thing in iGoogle/Shindig, but sometimes a specialised interface, tucked neatly inside a separate tab, works best.
  • Provide more flexibility on layout
  • Add support for bands, not just tags
  • Run it on a separate page without the blog layout
  • Keep the loldog