A couple of weeks ago I attend the JAOO 2009 conference in Brisbane. What follows is a biased, incomplete and probably misleading account of my impression of the two days.
I always assumed conference keynotes were meant to be broad, sweeping and inspiring. This one was narrow, technical and delivered in a mind-numbing monotone. Maybe it's just the way they do things now?
Introduction to Objective-C
This was clearly targeted at people who have no exposure to Objective-C, but rather than just being a dry survey of the language syntax and libraries, Glenn Vanderburg provided a nice historical overview of the Objective-C and its heritage.
My take away: Objective-C is basically SmallTalk, and SmallTalk is basically Lisp.
Google App Engine: Building an App the Google Way
Pamela got rave reviews in Sydney, and she's certainly an entertaining speaker. If you'd never heard of GAE, or never looked at its capabilities, this would have been a very good introduction. I've built a couple of small GAE apps though (in Python), and other than seeing the Java version of some of the APIs, this talk really told me nothing new.
1,001 Iterations: Product Design, Illustrated
This was a recounting of the process Avi Bryant went through taking a new idea from its inception through many refinements to a polished product.
Perhaps most the interesting part for me was Avi's assessment of the relative strengths of the various languages he ended up using to implement the product:
Squeak - for "thinking" in (i.e. the interesting problems and their solutions)
Java - for nuts-and-bolts computing (crunching numbers)
Ruby - for interfacing with external libraries and APIs (e.g. twitter)
I'm not sure it's always a good idea to mix so many technologies in the one product, but it certainly makes some sense to not get hung up on the One True Language, and just use each where they're best suited.
Avi again. Much more technical this time. Avi's main point: Ruby really is slow, but there's no reason it has to be.
He began with an interesting history of Java's Hotspot VM, which was based on technology developed for SmallTalk and Self in the 1980s. But Google's V8 was built by three people in about 3 months--surely we can do the same for ruby!
At the end of the talk, Avi was challenged by Joshua Bloch. Josh disputed Avi's claim that because V8 was built in three months, all optimising "hotspot" VMs should be easy to build. Java's current VM has been constantly improved over many years, and solves many non-trivial problems.
Of course, this sort of interaction between notable figures in our industry is exactly why you go to conferences like JAOO.
Hey You! Get On To My Cloud! - Application Development in the Clouds
Mike Cannon-Brookes gave us a bit of background of Atlassian's history (they've gone from two people and one product to nearly 100 engineers and ten products in eight years), then listed what he thought were the ten key practices that have made them successful. I'll excerpt just the ones I think are worth talking about, and add my thoughts (not necessarily agreeing with Mike):
Agile - it's the principles that are important, not any particular methodology or set of tools
Code review - there's plenty of hard evidence that code review/inspection is one of the best ways to reduce the number of defects in software. Of course, pairing is the ultimate form of code review.
Optimise tests - the main goal: get feedback to developers as fast as possible. Some of the things Atlassian do to achieve this include selectively running only tests that could possibly be affected by a code change (by doing static analysis on coverage), and splitting functional tests into parallel builds.
This is a common problem--functional test suites that take so long to test an application that the pipeline from code check-in to the "you broke the build!" feedback can be hours. Atlassian's solution is to split the tests into chunks that run in a maximum of ten minutes, and have enough build agents to run all the chunks in parallel.
Put everything in a wiki. Yeah, they would say that, wouldn't they? :-)
"Dev speed posse" - Atlassian have a small team that spend a fixed amount of time every week just focusing on removing things that slow down development. This is a great idea (although not one that's unique to Atlassian), and something more organisations should consider. One of the more interesting goals they have is that the "checkout loop" (the time it takes a developer to go from a clean machine to having a checked out app running locally and ready to work on) should be no more than ten minutes. How many large development shops can achieve that?
Josh Bloch - Effective Java
This was basically a summary of some of the new things in the second edition of Effective Java. About a third of the talk was all about generics. Good grief. Surely someone has noticed by now that this has all gone horribly wrong.
"Concurrency is hard" - even if you use the right APIs (for example,
still easy to get it wrong. Read Brian Goetz's Java Concurrency in Practice.
Serializable is bad, since it allows objects to be
created without using constructors. This can lead to invariants and
other assumptions being violated. Josh says to use serialization
Some of Doug's comments, observations and tips:
evalis the most misused feature - just don't do it!
===. You'll be tempted to use
==instead, but it's broken--it causes type coercion, which leads to unexpected and buggy results
manage the divide between client and server (don't recreate the server in the browser)
Software Visualization and Model Generation
Eric Doernenburg is a consultant at ThoughtWorks, and I'd heard him talk before about some of the cool code visualisation tools he's put together. The basic idea is that by visualising certain attributes of a code base, it's much easier to focus on the trouble spots without getting lost in the detail of thousands of lines of code.
Interestingly, Eric uses both common tools (e.g. CheckStyle) and the more exotic (CodeCrawler, CodeCity). Those last two are more or less self-contained, but Eric does really cool things with CheckStyle and Graphviz, and a bit of XSL to glue them together. As a general approach, use whatever analysis tool is closest to what you need, then map the output into a format your visualisation tool can read.
Smart Software with F#
An overview of, and small sample app, in F#, Microsoft's functional language for the CLR. The main message:
F# is great for data-intensive applications
smart algorithms are (relatively) easy in F#
Both of which apply to any functional language of course.
You try to give Microsoft people the benefit of the doubt... but Joel Pobar, despite obviously being very knowledgeable about F# and functional programming, still managed a couple of clangers. Most egregious: he called python an "elementary imperative language". Fair enough if your background is Visual Basic and you'd never heard of functional programming... but this guy is the F# expert.
Anyway, it was good to see a bit of F# in action. If it gets more people thinking about functional programming, great. But it doesn't offer anything you can't get in Clojure, SmallTalk, Scheme, etc., unless you're stuck in the Microsoft ecosystem.
Overall, a great couple of days. I learnt new things and expanded my mind about things I already knew. I hope to go again next year, and hopefully it will come to Melbourne!