QCon 2014 – Day 2

It’s day two of the conference talks at QCon. The day started with a gentle look back at some key figures and ideas in the history of software development, reminding us to enjoy what we are doing.

It ended with a keynote reflecting on what you are doing a la Deming, and with a brief thought experiment with the audience considering what to do if a killer bear was loose in London. Shooting the bear might be the optimal solution, but an Android app to track it’s movements was the best from the audience.

photo 2

Here are some reports from some of our other attendees:


Mobile Web Performance – Getting & Staying Fast! – Aaron Peters and Andy Davies

A fantastic talk by @aaronpeters and @andydavies on mobile performance with a load of great takeaways.

Phone radios also have a 1-2 second delay when waking up and negotiating a data connection with the base station and round trip times to the server are a lot longer on mobiles so latency can kill load times.

Web pages are also getting 30% larger year on year and whilst networks are getting higher bandwidth, 4G will only hit 20% of users by 2015. Tthe new breed of cheap smartphones like the Alcatel Onetouch on Firefox OS means that not all users are getting the luxury of more processing power.


First lesson is to actually measure your page performance. There are various JS APIs in the browser to programmatically help out here. Window.performance.timing has a lot of facts about page load time including times for DNS lookup, tcp handshake and many others. Window.chrome.loadTimes and Window.performance.msFirstPaint have a lot of information about individual resource loads and paint times.

However you’re going to want to use more hardcore tools and sites like webpagetest and Appurify will give you load times on different devices and on different networks. Even going to the detail of an average WiFi connection in Starbucks in California.

We went through some examples of bad sites. HTC.com loaded in 20 seconds on an HTC phone. NBC.com loaded resources from 115 domains over 30 seconds. There are some truly awful sites designed for mobile out there.

Fixing this

Standard web tactics like minimising the download, GZipping everything and aggressive caching apply here but it goes deeper. Web Fonts are really bad for mobiles, google fonts download 4 separate files from the google domain and your users have to wait for this to start using your site. If you have to use them, you can request a subset of a font vastly reducing the download.

Tuning initcwnd = 10 on the server to send a larger number of initial TCP packets can have great effect. Meta tags to resolve DNS lookups ahead of time and prefetching images can be added to the header of your page to do stuff when the browser is idle.

Also prioritise more important resources over others. Content should come first so that text and useful images get on screen first. Enhancements can come next, such as that javascript that adds swipe functionality. Then the leftovers like ads should come last. That way the page is useful before it completes loading.


Finally, when you can’t do anymore – add little tricks to make the user think that things are happening. Facebook proved that putting up a device-specific spinner makes users think that their phone is being slow rather than your page.

photo 3

You can also make actions appear instantaneous by updating the UI straight away then sending the message to the server. Only reverting if the action failed. Another trick is to start an upload whilst users fill out forms to go with the data. Slides can be found here:


Offline first – Caolan McMahon

Another insightful talk from people that have spent ages in the field. This one was from @caolan of http://hood.ie/

It started with “Mobile first” and how people were reacting in 2009 to lots of people getting smart phones. 2009 seems like ancient history in mobile web! Offline first aims to make you design your app to make it as opaque as possible when your mobile app goes off the grid.


App Cache has long been touted as a way of storing pages for offline, but it has it’s flaws. Mainly the fact that you have to update it every time a resource changes. A new ServiceWorker spec is in the pipeline to allow app developers to programmatically define where to load pages from. It seems cool, but very JavaScript heavy when all I want to do is load resources.


The offline API is pretty useless across devices and the only real way of detecting if your app is offline is whether your XHRs are reaching your servers.

Storing data

Local storage is also the default choice here, but there are limitations. It’s synchronous so blocks user interactions and there’s no way for you to tell if you are going to go over the nominal 5MB limit. IndexDB is more heavyweight, but has an awful API so there are a lot of wrappers on top of it.

We also went through some great design maxims:

  • Launching should feel natural. This has got to be done from the home screen of a phone rather than going to a browser
  • You shouldn’t make your users plan ahead by having them click “sync”
  • Spinners are evil. If you are offline don’t put one up. What is going to happen?

Finally pouchdb was rolled out. A couchDB implementation for the browser. Store all your data on the client and have it sync to the back end. You no longer run a server, you have a service. JS Git is going to add Git version control to the browser. People are really thinking offline-first, we are truly building web “applications”.


Organisational Change Myths – Linda Rising

I went to a fun talk by Linda Rising – who completed her Computer Science phd at 50. She says – don’t let anybody tell you that you’re too … old … Young … Short … Fat … to do whatever you want to do. She was talking around her book – “Fearless Change” which is about patterns (like software engineering patterns) you can use to affect change.

Linda says:

  • If you want to persuade people to change you need to believe in your proposed change
  • Persuade people by feeding them – literally. But the food has to be the right food!
  • Listen to people’s fears and learn all you can. Conversations are not fencing matches.
  • Appoint a “champion skeptic” to play devils advocate
  • Ask for help, and don’t forget to say thanks!

Leave a Reply

Your e-mail address will not be published. Required fields are marked *