QConLondon 2011 : Day 2 review

So, on to day 2 of the QCon London 2001 conference, which for me was about testing, REST, and catching up with the .Net usergroup arguing with Glenn Block in a noisy pub over where hyperlinks should go and how horrible the browser is for a web-connected world.

Keynote : Innovation at Google / Patrick Copeland

In a fascinating overview of creating an innovation culture, Patrick Copeland discussed how everyone at Google is free to develop ideas (the famous 20% time) but that ideas mean nothing without data to back them up. In one case, the usage data led Google to kill Google Wave, which was a good idea, and got a lot of early interest but had no staying power as it struggled to find a killer niche.

The most interesting part of the talk was the discussion of “Pretotypes”, which are a generalisation of something I’ve always known as “Wizard of Oz” trials. The idea of a Pretotype (“pretend-o-type”) is to build a concept prior to the prototype to see if the idea itself stands up. Where a prototype answers “Can I build it?”, the pretotype answers “Should I build it?”

The best pretotype example in the talk was the discussion of IBM’s speech recognition trials. Before they started work on the software, they trialled the system by hooking up a microphone to a typist in another room, who would take dictation in real time for the user to see. They discovered fairly quickly that the interface was poor and canned the project.

I’m also very interested in the new Android Pretotyping app that was announced, called Androgen. It’s designed to help pretotype Android apps, but given the breadth of examples in the talk, I am sure it could apply equally to mobile web and possibly other devices. Definitely one to watch.

Testing for the unexpected / Ulf Wiger

For the first session of the day, Ulf Wiger discussed randomised testing, describing existing test automation as a low water mark, filled with often hard-to-maintain code where the effort to maintain the code grows faster than the complexity of the underlying system. The description of the problems with existing tests took up a fair amount of introduction time before the Erlang QuickCheck meat came in.

The idea of QuickCheck is to add controlled randomness to tests, by defining the input-output space of the system under test, which the framework uses to generate the test cases to try and find weak points in the system. QuickCheck is suitable for TDD – and he described how the requirements team could easily translate grammar in the requirements spec into QuickCheck test suites, which could be run over the code until no failing cases were found. He also mentioned that there were fewer errors in the test cycle than before the introduction of QuickCheck.

The most fascinating part of the talk for me though was the mention of NModel, which is Microsoft’s implementation of the same concept on the .Net platform. One to investigate.

Building a ReSTful architecture on .net with OpenRasta / Seb Lambla & Make yourself comfortable and REST with .NET / Glenn Block

I’m going to take the next two talks, from Seb Lambla and Glenn Block, together as they demonstrate an Alt.Net and a Microsoft solution to bringing a REST framework to the .Net platform. The Microsoft REST solution, built on WCF, provides a large number of integration points allowing users to mould the framework to their thinking whereas OpenRasta is built on the idea of strongly encouraging developers to do things “the right way” by enforcing a set of defaults that play nicely with the spec and are harder to change. OpenRasta has plenty of extension points too, providing support for multiple view engines, input handlers and HTTP PATCH, but the core is set (a point that I was reminded of during the WebMachine talk on Friday).

Two very useful points from both talks : they were both using Fiddler for demonstrations, and pointed out a way round Windows’ networking shortcut that usually prevents packet sniffing on the local loop. Using “localhost.” or “127.0.0.1.” (note the trailing dot) allows Fiddler to listen in on the local loop packets. I’ll have to see how Fiddler compares to my current tool of choice : WireShark. The other interesting point, that spilled out into the OpenSpaceBeers, was the concept of encoding links in HTTP. Are links to states (the canonical “purchase” link that should be followed after getting an order, for example) part of the HTTP description, and therefore encoded in Link headers, or are they part of the data, and encoded in the response content?

The biggest problem with ReST over HTTP appears to be that the most well known HTTP client, the browser, is a poor HTTP citizen. This doesn’t surprise me, given that browsers also tend to be 3rd class citizens of other protocols such as FTP, Gopher and IRC. Indeed, perhaps they should be called renderers, since they are generally better hosts of HTML, CSS and JavaScript content. Don’t let browsers fool you into thinking that you know HTTP. If you want to know HTTP, read the thesis that gave birth to ReST.

If you want a good ReST client however, .Net does offer some hope, as demonstrated by Glenn Block. The HTTP response and request that have always been part of the server side are now freed to be available for web clients, outside the IIS framework, so that you can now write happy C# web clients using ReST, using the classes you know from the server, but inside a framework that makes them easy to mock.

All in all, a very fascinating pair of talks on the mechanics of implementing a ReST service, which was a perfect setup for a talk about the practice and theory of implementing one…

Getting Things Done with REST / Ian Robinson

For the whole of the ReST track, a stack of REST in Practice books were available for people who gave the best answers. I’m sure having Ian Robinson, one of the authors, in the track, was a factor, and on the strength of his talk, it’s definitely on my post-QCon reading list.

The talk was a worked example of the now-standard GET a cup of coffee RestBucks workflow, but started with the idea that REST is just the latest incarnation of “Warlock of Firetop Mountain” Fighting Fantasy workflows. Read some data, get a list of options, follow a link to perform one of the options.

The talk showed a well-structured set of code that implmented the state machine using XForms as the POST representation of data, and therefore embedding links into the content. The emphasis was on discovery of workflow (after all, when I create a new order, I don’t know in advance what its ID will be, and I won’t know what the options are if I have a loyalty card).

The talk was a great sales pitch for ReST, but don’t take my word for it, read the InfoQ GET a cup of coffee article yourself.

Scaling the Social Graph: Infrastructure at Facebook / Jason Sobel

The scary takaway message from Jason Sobel’s talk was not the 150-200 engineers supporting 500m users. It wasn’t the pushing live several times a day, using flags to keep “in progress” features from being visible live, or the hoops they have to go through to have 2 (soon to be three) data centers in sync (hint – most user operations are read-only). The message that a lot of people went away with was that the front-end is PHP, compiled to a monolithic binary via C++ using HipHop, that weighs in at a single 1.6Gb executable running on every front-end server. Between that, the spaghetti code on the backend that had to be replaced and the use of multiple MySql databases on a single physical server (to make migration easier), I suddenly find myself thinking our legacy code maybe isn’t that bad.

OpenSpaceBeers

A great session from the local .Net group where two on-the-spot discussions were voted on. One was about AppHarbour (Heroku for .Net) that allows you to easily test and deploy your code to a cloud hosting solution, as well as a hush-hush competitor that’s coming soon with VPN support so you can host the database in your own data center (handy for certain organisations that have a stricter limit on data via the Data Protection Act).

The second talk was basically an extension of the ReST track, where Glenn Block did more to convince everyone that Hypermedia is the future and everyone should use ReST (which is fantastic to hear from inside Microsoft, and Glenn did thank Scott Guthrie for helping to foster Microsoft’s new partnership with the development community).

The session worked well, and if we could guarantee enough people, definitely something I’d like to try in Scotland.

Advertisement

QConLondon 2011 : Day 1 review

I was too busy enjoying the QCon London 2001 conference to blog whilst I was there, so I’m writing up my notes now before I forget too much, mostly for my own benefit, but I’m posting it publicly it case it’s of interest to others.

Keynote – Scaling Lean & Agile : Multisite or Offshore Delivery / Craig Larman

Craig Larman was speaking about his experiences of creating agile teams for development projects spanning different countries and large teams. Although his first point can be summed up as “Don’t do it – if you can use a 10 man team, do”, there was a lot of good information on how to split up tasks to distribute them effectively across teams and how to maintain a common vision and feedback path across many locations. The details of this are described in his books, so have a look at his website if that’s something you want. On the strength of the keynote, his experience in this field would put his books right on my list for learning about distributed development.

A couple of interesting points he made were that teams should have functional rather than modular responsibilities – i.e. don’t have “database” and “UI” teams, have “HSDPA” or “credit card payment” teams whose responsibilities cut right across the codebase so that the eyes on the code in one module never get stale. He also recommended against proprietary software (in particular IBM ClearCase – the first of many to advise giving IBM a wide berth) – mainly as licencing issues create major problems across borders, and generally do not provide enough value over free alternatives (even just Google Spreadsheets) to justify the expense.

"Architecture is a bad metaphor. We don't construct our software like a building, we grow it like a garden." – Craig Larman #qconlondon

— Jurgen Appelo (@jurgenappelo) March 9, 2011

Why Don’t We Learn!? / Russ Miles

In the first proper session, Russ Miles spoke about why the things we hear about at conferences don’t always translate back to the office, and how to do more than just cutting and pasting ideas into a new context without thought. Apart from calling Freud a Psychologist, and a long reading list, this was a great talk about why critical thinking and experimental practice, with feedback, are essential for improvement.

There was a wonderful dialogue structure to the talk, in the best philosophical traditions, and it pulled in ideas from across philosophy, the scientific method and psychology theories to provide a coherent basis for how to apply the knowledge gained from experience or from others, and to measure its effectiveness in order to obtain more knowledge for the future.

Lean Programmer Anarchy / Fred George

Probably the talk that generated the most discussion. If Agile is about throwing away the layers that separate developers from clients, Anarchy is about throwing away the hierarchy and process to so that development teams become self-organizing around targets and around projects. It’s a fascinating idea, and involves a high level of trust and self-determination amongst the development teams. For the projects I’m used to, there’s a lot of frameworks in place to protect financial and legal considerations, which seem to be incompatible with the basic premise of Anarchy, but it’s a proven model within the FOSS world, where developers choose where they want to spend their time, which targets are important, and where developers tend to self-organise.

There’s a few themes in this talk that I saw repeated in other discussions, the develop-ship-monitor loop rather than the develop-commit-test-ship loop. This works for his teams because the code is small and short-lived so can be thrown away easily, and the code tends to be for internal teams, rather than external clients. However, the basic idea of constantly monitoring live sites to show that they keep working rather than just demonstrating it before deployment is something that seems to be a trend across many of the speakers.

Do’s and don’ts on Android / Lars Hesel Christensen

There were a few nice general points in this talk, but at its heart was a fascinating discussion of how to improve performance and respond to customers and their devices. The talk was based around the Android version of an App for customers of Danske Bank across Scandinavia.

There were a few tricks, mainly from Google’s Android Dev site, that allowed them to improve animation speed for the main interface components from around 12 FPS to around 47 FPS (which was inline with the iPhone performance), partly by simplifying the graphical structure, but also working around limits in the Dalvik JIT compiler, in particular in regard to a slow dynamic lookup for polymorphic method execution.

On the customer side, there were a few tips on how to augment your apps to make crash reports available via the Android Market more useful, and a list of problems with cameras that led to custom patching for some devices and disabling of cameras on other devices, all managed through an extensible framework that was partly controlled by the server so that preferred resolutions could be tested and sent by the server without requiring a client software update just to support a new device.

Mobile app privacy: you’re doing it wrong (and so am I) / Graham Lee

Graham Lee (http://www.fuzzyaliens.com) gave a very entertaining, if slightly misnamed, talk about good User Experience design, that was mostly about privacy but covered security aspects, comic books, and had some great examples of the good and bad out there.

There was a great explanation of why phishing and spamming work, and how developers and app store curators and designers could do more, mostly with an eye on affordability and design (for which there was another long reading list – I doubt I’ll get all this reading done before QCon London 2012). The biggest takeaway was that if you want your users to make a decision about privacy, you have to get them to do it at the right time with easy to understand language, and allow users to ignore your warnings if they know best. There was a big discussion around this with email clients. If I write “please see the attached document” and then don’t attach anything, the mail client should warn me, give me the option to correct my mistake, or the option to ignore the warning, and there is a GMail labs experiment to do just this. In this case, showing a warning when an attachment is not required (false positive) is far better than not showing a warning when it is required.

Making Apps That Don’t Suck / Mike Lee

Or : how to design software the Apple way.

This was easily the busiest talk of the day, with standing room only, and the only one presented by a pirate. The general theme was not to believe your own hype, and accept that you can always make something suck less. Great design will always trump poor design and will lead where others follow.

The Apple history of the speaker was well in evidence, and there were a few places where that distorted the core message.

The most interesting thought of the talk, and the one that went against the “release early, release often” mantra in evidence across the rest of the conference, was the idea of releasing “version 3” of your product. Version 1 proves the concept, you then get feedback for version 2 to fix all the bugs, you then get feedback for version 3 to make it shine, and seems like magic. This will make a simple, seemless experience that your competitors cannot match.

There was a great demonstration of an early iPhone app that failed to live up to this philosophy, but also demonstrated how much the market and the philosophy of apps has changed in the past few years. I believe this talk is on a world tour, so keep an eye out for a pirate in a town near you, and go see him.

Keynote : Innovations and Integrations: Applying Trendy Technologies to NASA Mission Operations Planning / Mark Powell

An interesting choice of keynote this one. Sonic screwdrivers, Cylons, Star Trek and many other sci-fi references, and lots of cool videos of robots and AR/VR technologies, and lots of talk of their hoe-grown cloud for image manipulation and rendering 3D landscapes from Mars rover data, but there was so much technical content that was just below the surface that we didn’t get to hear about, which I found frustrating. I would love to hear more about the technology behind the curtain, rather than a couple of Eclipse screenshots.

A couple of things that should apply to all software, not just where millions of dollars of equipment is involved:

Always use units; and

Never use default values.

Round-up

A wide range of talks, including a couple that I don’t think I would have seen otherwise. A few themes that I saw today were to get repeated elsewhere, in particular the reduced emphasis on testing and requirements as speakers are looking to move beyond Agile, but it’s not clear how much is ideological, how much is misunderstanding and how much is just lazy. A few speakers moved onto new ways to implement the Agile manifesto that allowed them to throw out the current best practice with something that provides a better fit for their needs, but I worry that people will start taking the messages and throwing away the tools of Agile without understanding why those tools are there, which would be a retrograde step.

Lessons learned from the Feedly for Android beta 1 (via Building Feedly)

A fascinating insight into moving from iPhone to Android development, especially with regard to different users and UX expectations. And interesting talk of a cross-platform framework.

We released on Wednesday the first beta of feedly for android – for both phones and 10" tablets. Here are some of the lessons we learned during the last 5 days. The good Android has an open app distribution model so we started by pushing the app to our website, invited 50 users and tried it for 12 hours to see if they were any major show stoppers – very valuable given that there are a lot of different types of phones and we only tested feedly on … Read More

via Building Feedly