Hello.

This is the web platform

Maybe? :)

We've done a lot of work using Github in the recent past and here is some of the work that we have optimised.

If you are seeing this then everything worked fine and dandy. Woot. It probably isn’t hard to tell that this Blog is built using Jekyll (Octopress actually) and one of the things that I have always wanted to fix was how I deploy the site. The workflow that I have used in the past is to: edit locally. commit changes to a github repository then rake deploy via ssh. Whilst this flow works pretty well, there are number of times where I don’t have terminal access and even if I did, I don’t have my public keys.

Page Speed Insights for Mobile launched the other week. It’s a tool that analyses your site in the context of a mobile device and tells you what you need to do to improve the network performance of the site. In about an hour I had taken 3 seconds off my blogs page load time by removing JS files and adding Caching (doh!) and crunching PNGs (double doh!), going from a score of about 34 to 84.

Oddly I rarely talk about Developer Relations, but I feel like changing that today. I feel really uncomfortable when I hear people suggest Hackathons are a part of building a sustainable, scalable developer ecosystem. They are not. I have run hackathons. Some better than others. I have learnt a lot about them. Businesses and Platform creators: If you are thinking of running a hackathon to win potential new customers you are doing it wrong.

Over the past week I have been working steadily to improve the mobile experience of html5rocks.com. Now don’t get me wrong, it already is responsive, I just don’t think it was hugely readable on a mobile or tablet device. One of the areas that I have been focusing on is the “Time to first read”, that is how long does it take the reader to get their eyes on the text they want to read.

My current focus is on the mobile web. Everything I do need should be to help developers “get” mobile. With this in mind, I was skiming html5rocks on my nexus, and I was struck by the fact that I could not see any content on the first page. Not good. There are a couple of things that we need to fix on HTML5Rocks when it comes to mobile. Today I am going to focus on the Table of Contents.

Let me start by saying it is not possible. But I have a half solution. If you have tried to install Chrome for Android before on an emulator you will be intimately familiar with the series of errors that occur, most noteably: Arghhh… I am not going to document how you get this far because I will just be spreading alot of useless facts that ultimately lead you nowhere…

In our talk for Google I/O 2013 — Mobile HTML: The future of your sites — we wanted a way to show actual real demos of Chrome in action without have to constantly switch to the projector over to a special device. Not only does switching cameras waste time, it is also easy to lose the context of what you are demoing in the first place. The solution we came up with in the end was to record the videos of the device ahead of time and have them in-line in the slides.

What do you do if you want to quickly test your sites on mutliple versions of Android at the same time? There are couple of solutions, such as Adobe Edge Inspect, but what if you want to create and manage your own in your own workflow? I haven’t seen single solution yet. Here is a simple shell script that I created that starts to get you on your way to your own testing lab.

Just before Christmas I wanted to build a site that helped developers understand the impact that using Web Platform features would have on there potential reach. For example, if I used WebGL what is my target reach and what additional features can I use without impacting my potential audience figures. I launched iwanttouse.com. Sweet. Anyway, that is not the point of this post. One of the features of this site is.

It’s not me. It’s you! Ok. thats a little harsh. Without AppCache we wouldn’t even be able to think about building Offline enabled web apps. But it seriously does have some issues, one of which I am blogging about today has been not discussed in depth before (as far as I can tell). Imagine you building an offline enabled app that integrates with registerProtocolHandler or registerContentHandler. These two API’s use query parameter substitution to pass data from the client page to the service page (http://mailfoo.

Posterous has been great for me, but now it is time to move it. I don’t have the time to do this so I am very willing to pay someone a modest fee for managing the move of my blog to a platform that meets the following requirements: Mandatory Requirements: - not a hosted solution like Blogger or Tumblr - static output (no database) - can write posts in markdown, text or html - all content can be managed through git.

I was thinking about this the other day. I remember being in the Apple store in Liverpool about 2 months ago and I distinctly remember hearing the following: "Do you have any of the new iPads in?" several times over the space of about 30 minutes (I was playing with MacBook Airs). Come to think of it there were several other products people asked for as "the new X". It is pretty cool.

It is a failure of the web, browser vendors and developers that we are in this situation, but we need to stop advocating for and building examples that use the LocalStorage API's, it is simply not a scalable API and the more we build for it the harder it will be for us to ween ourselves off it. LocalStorage has poor querying capabilities, terrible performance, small storage in many browsers, crazily inconsistent eventing and a nasty habit of locking.

There is a lot of chatter about Mozilla considering implementing some webkit specific prefixes - I encourage everyone to read “Platform/Layout/CSS compatibility“ My personal take on this is “great” and I am glad they have the guts to start the conversation, but in my eyes it should only happen IFF the vendor is going to choose to stop supporting their existing prefix and start supporting the other parties prefix as what they agree to be the way they want the standard to move.

Chrome just got Web Intents support in Dev and Canary builds (18 onwards).  This is a huge milestone and I am very excited by this first step along the path of building a more connected web of apps. A lot of developers have asked me how to get started as it seems some of the demos on http://demos.webintents.org don’t register correctly.  I have a good answer for that - in short: Chrome doesn’t yet detect the intent tag, instead applications currently can only register their support for an action such as “share” via the Chrome apps manifest.

As of February 1st I have been at Google for two years! Yay! It has been an amazing time and I am truly honored to work for such a company.A year ago (+1 week) I wrote about my first year experiences, it was pretty crazy in my first year, not only did the scale of the work hit me overwhelm me, but so did the sheer number of excellent engineers and colleagues.

We have a huge problem on the web today. If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye?