Overall it was an excellent conference with a great group of attendees. The numerous inter-session conversations I had with fellow attendees were as enlightening as the sessions themselves.

Here are my thoughts about the sessions that I attended.

Monday 13th June

HTML5 Boot Camp

This session by Laurie Young and Ismael Celis was one of several focussing on the hot topics of the moment, HTML5 and JavaScript. After a brief introduction to HTML5 and what it provides we got cracking with the exercises.

Working in small groups we were asked to implement a web page that allowed the user to drag an image from the file system into it. The next task was to upgrade it to get the image(s) to persist when the user refreshes the page using local storage. Finally we were asked to use a web socket to send the image to a pre built server which would then distribute it to everyone else viewing the same web page.

There was a reasonably large range of JavaScript experience within the session, however I think most people managed to complete the exercises. It provided a great introduction to several of the most universally helpful HTML5 JavaScript APIs.

Improving Trust in Teams

Rachel Davies’ session looked at how to improve trust in teams.

Split into groups of four we were encouraged to discuss our various experiences of both low and high trust scenarios. Perhaps unsurprisingly most of the scenarios that were highlighted involved low trust. Once each of us had relayed our own trust stories within our groups we were invited to share the most interesting ones with the wider audience.

Afterwards we resumed working in our groups to draw force field charts that highlight things that we believed help to improve trust and those things that hinder it. We drew these up on a flip charts and again shared our thoughts with everyone attending the session.

Finally we looked at one of the forces behind improving trust and what we might do to nurture it.

It was an enjoyable session that has really made me start to realise that there are perhaps more facets to trust than I had previously considered.

At the Extremities of Extreme

This catchily titled session by Julian Fitzell and Jason Ayers was a fascinating introduction to the theory behind wolf pack programming. This technique takes the familiar pair programming, but turns it up a notch, taking collaboration to a new extreme.

I can barely do the concept justice here, but my simple interpretation is that with adequate tool support developers can collaborate without having to be sat around the same PC if they work on precisely the same instance of the code. The tools would allow a developer to see which functions/methods the other people working on the code base were looking at or editing. This allows pair programming to be followed where appropriate, but the navigator can slip off to do some driving if they think of something that will help to remove a block that they have observed that the driver is about to encounter. They also advocated judicial use of spikes to hunt out the quickest solution to a problem.

They had run an actual wolf pack programming session on Sunday which I am now disappointed that I missed.

At the moment the example sessions they have been running use Smalltalk, however my thoughts are about how we might trial these techniques for JavaScript development.

Invited Rant

John Nolan entertained the conference audience with a rant against the term “software engineering”, specifically that:

Software engineering does not and should not exist

He reaffirmed Kent Beck’s statement that:

Software is software

He conceded that:

Software is like engineering

But saying it is engineering is wrong. Instead he introduced us to a different metaphor:

Software is cooking

The examples he provided were very compelling, although even John conceded that he wouldn’t be changing his business card to read Software Chef just yet.

Tuesday 14th June

Unfortunately I missed most of Tuesday’s event as I was preparing for my presentation the following day, which leads me to…

Wednesday 15th June

Web Apps That Shine

I co-presented this HTML5 focussed session with my colleague Adam Iley. The specific context for it was the features of HTML5 that allow up to build web apps.

We introduced the offline support that is provided by HTML5, including local storage and the application cache. Afterwards the attendees paired off and worked at upgrading a n0tr, simple note taking website, to work offline.

The second section highlighted the tighter integration we can now get between a web app and the device it is running on. On mobile devices access to geolocation, and the device orientation is available, whilst on the desktop we can implement drag and drop both within the web app as well as to and from other applications, including dropping files into the page. Again we asked the pairs to upgrade the n0tr app to use some of these techniques.

We concluded by talking about portability and other concerns for building and releasing web apps. The presentation is available online as are the exercises that we ran.

Invited Rant

Jason Gorman’s rant was titled Slow and Dirty.

It was a thought provoking view on our responsibilities as developers with plenty of statistics to help back up his points. When starting on a new project the features come in thick and fast, however over time productivity starts to plateau. On the 8th major release of a major product (no names mentioned) the cost to write or change a line of code was 20 times as much as it had been initially.

Making our software maintainable is our responsibility, and is not something that we should abandon in our quest to keep adding new features to keep our customers happy. We need to be prepared to pace ourselves for a marathon, not a sprint.

Finally, beware the statistical aberrations that seem to have flouted all of this advice and are major successes nevertheless. Just because your great aunt smoked 60 cigarettes a day and lived to be 103 doesn’t mean that to give yourself the best chance to survive to 103 means that you should smoke 60 a day.

Specification By Example: By Example

The final session I attended was run by Lasse Koskela. Lasse asked us to split up into groups of three, then handed out an index card to each group that specified a requirement for a particular software system. Within our groups we needed to capture the specification by writing or drawing out the various examples we could think of.

My group was asked to produce the specification for an email verification system. We sketched out the interaction between the server and the user, defining 5 different scenarios that we could think of, one of which covered a hacker.

Two members of each group were asked to switch over with people from other groups. The remaining person on each group was asked to explain the examples they had drawn up to the new members, and we were asked what improvements could be made.

Finally everyone changed groups again, moving onto a requirement that none of us had worked on before. We are asked to review what had already been done, then start afresh and come up with our own examples.

Overall the session went very well and it was interesting to see how much would be achieved in a very short period of time by sketching out the examples with tight collaboration between all the members of the group. There was a warning flag though that the lifespan of the examples that we created was limited as there was contextual information that was only available to those who were involved in the conversations surrounding the creation of the examples – a little more structure might be necessary if these are to persist over a long period of time. Nevertheless this was a technique that I’ll be trying out at some point soon.

The Financial Times has become the first major news application to switch from a native app to an HTML5 web app. They explain their reasons here and experiences – http://aboutus.ft.com/2011/06/07/ft-web-app-technical-qa/

That means no more support for IE7, FF3.5 or Safari 3.

As they mention, things won’t just stop working for those browsers, but they won’t be officially supported.

It seems like a slightly crazy mix of backwards compatibility and some quite cool new ideas that are meant to be suitable for keyboard/mouse based systems as well as touch based. What is interesting though is the mention that the new style tiles and apps are built on a new platform using HTML5 and JavaScript. It seems unclear what the future of Silverlight is, but what is clear is that Microsoft is definitely embracing the HTML5 world.

This can only be good for HTML5 development and tools.

Most other scientific disciplines require you to learn from others before building upon what they have done. Sir Issac Newton’s oft quoted “if I have seen further it is only by standing on the shoulders of giants” is testament to this.

The inevitable conclusion of this is that the current generation of software developers is likely to repeat the mistakes of their predecessors.

IE 6 Must Die

IE 6 is terrible. Fact. Surely I can’t disagree with that. It breaks all the standards, and requires elaborate workarounds to get anything decent to work. At Caplin we are proud that Caplin Trader performs well in IE6 since many of our customers still use this as their internal browser, but the undeniable truth is that it performs a lot better in modern browsers.

Well, for those of us who remember its arrival 10 years ago, IE 6 was heralded the pinnacle of evolution. Its main competitor Netscape never really recovered from version 4 which supported a document object model (DOM) that few developers would identify with today based around a layer tag. Of course out of the ashes of Netscape literally rose Phoenix, which was later renamed as Firefox, although that’s a different story.

At its height in 2004 IE 6 had around an 83% of the share of the browser market (with another 8% held by IE 5). Such dominance that it is unsurprising that a large number of web developers only focussed on making their pages work in IE, including making use of non-standards behaviours and proprietary APIs that would later come back to haunt us.

Mobile Safari – History Repeating Itself?

Does Mobile Safari equal IE6?

Fast forwarding to the era of the mobile web, the question arises as to whether we are repeating the mistakes of the past by targeting our mobile web efforts purely at Mobile Safari?

There is little doubt that the popularity of the iPhone and iPad has ignited the rapid acceleration in interest in the mobile web. However only focusing on making web pages optimised for these “iDevices” has the potential to exclude a large number of your users from getting the best possible user experience.

The latest figures for Mobile Safari (excluding the iPad) show that it only has a 22% share of the mobile browser market (data from March 2011). This percentage has been slowly decreasing over the past couple of years and is likely to continue as the number of smartphone owners increase, with the greatest growth at the cheaper end of the market, thereby diluting the “iDevice” share.

To be fair to Mobile Safari, it is certainly more standards based than IE 6 ever was, therefore sites designed to work on the iPhone/iPad are more likely to work on other mobile devices.

However failure to test on other devices is likely to produce, at best, sub optimal experiences for users. As my colleague Dominic Chambers’ recently blogged, there are still many differences between the various mobile browsers. Progressive enhancement remains the web developer’s best weapon to cope with this.

Learning From Past Mistakes

The hypocrisy of condemning websites that only work on IE 6 compared to those being written now only for Mobile Safari is stark.

At the moment there may be good justification for only focussing on Mobile Safari (despite its 22% market share). However back in 2004 a number of web developers used similar justifications for an IE 6 focussed site (because of its 83% market share), and look where that got us.

The new iPad has a new faster dual core processor, but less publicised is the increase in memory to 512MB which helps a lot with browser usage.

The upgrade to iOS 4.3, which is available to existing iPads, iPhones and iPod Touches, has a significant performance upgrade to Mobile Safari.

John Grubers’ iPad 2 review details some benchmarks he ran showing both the iPad 2 and iOS 4.3 improvements.

This of course is all good for the Mobile Web and being able to deliver rich functionality in HTML5 based web applications to mobile devices. Mobile Trading and realtime data applications should benefit from this increased performance.

It also shows that Apple is taking the Mobile Web seriously – let the native versus web battle continue!

Issues

So, here are the iOS issues I did run into…

1. iOS reports incorrect window.innerWidth and window.innerHeight values once it’s been rotated from portrait to landscape mode, and refreshing the page doesn’t help!
2. CSS Animation + CSS 2D Transform becomes choppy as soon the element(s) involved have a width or height greater than or equal to 1024px (Javascript + CSS 2D Transform and CSS Animation + CSS 3D Transform don’t have this problem).
3. Most CSS 2D Transforms can be specified as CSS 3D Transforms by setting the z plane to zero, and doing this causes the GPU to be used (which is good), but also with slightly different results to when only 2D is being used, causing glitchy rendering if the GPU gets switched in and out as transforms are run (which is bad).
4. iOS doesn’t yet support SVG inside HTML, which may prevent you using some older libraries — you must serve your document as application/xhtml+xml to use SVG within iOS.

Conclusion

Unlike Google with Android, Apple have clearly done enough testing around the types of features mobile web app developers will actually want to use, and the few bugs that do remain can be worked around without too much fuss. Let’s hope Gingerbread brings similar improvements to the Android platform.

Here are the bugs I ran into:

1. SVG doesn’t work on Android.
2. Using CSS 3D Transforms breaks any CSS 2D Transforms you have.
3. CSS 2D Transforms + CSS Animations don’t work if there is more than one transformation function being animated.

Given that none of these bugs are in the latest version of Chrome (Chrome 8 ) but are in the latest version of Android (Gingerbread), it makes you wonder how different these code bases actually are, and whether changes have to be manually integrated from one code base to the other. Or, perhaps it’s a purely a question of neglect or a lack of oversight on Google’s part?

Now, don’t get me wrong, I really like Android. I mean, I must do, since I’ve owned all these Android phones:

• T-Mobile G1
• Google Nexus 1
• HTC Desire/Z

And, given that I’ve also been a long time evangelist for mobile web apps, you can imagine how upset I was about this! If there was a viable way I could have worked around all these bugs, you can believe I would have!  The real kicker though was to learn that my demo works perfectly on Blackberry 6 phones, and this from the company that had the worst smartphone browser of all until just recently!

What The Future Holds?

The good news is that SVG support has finally been re-enabled in Android Honeycomb, having been disabled early on to save memory in the first generation Android phones. I’m now just praying that these other bugs are fixed too (can anyone confirm this?), and that current phone owners receive an update for this in a timely fashion.