I was lucky enough to be able to go along to QCon London 2009, but not quite lucky enough to go to all three days.Â So I’ll summarize my thoughts from the two days I did attend.Â Here are my notes from Day 1:
Tony Hoare – Opening Keynote
This was a talk about the differences between Computer Scientists and Software Engineers.Â He characterised the former as being idealists who think about generalities and the long term, while the latter are pragmatists and specialists who generally consider the short term.Â It was a philosophical talk and since I fall into the latter camp I would have liked something more concrete to take away.Â He seemed to be very optimistic about what Computer Science can offer the practicising engineer.Â In fact, he came out with the quote:
One day, software will be the most reliable component in any system that contains it.
It wasn’t clear quite how we’ll get to this point, although a colleague of mine quipped that this would only happen because less reliable components would be introduced!
David Pollak – Scala and Lift
This was an interview with the maker of the Lift Framework, which is a web framework based on Scala. It was filmed and should appear in due course on InfoQ (who were co-organisers of the conference).Â His pitch for this framework was similar in many ways to that of Rails, in that Java frameworks tend to suffer from too much boilerplate code, because it is not possible to easily pass blocks of code around.Â In Ruby and Scala this is possible and so this sort of duplication can be removed.Â In fact, Lift started out as a port of Rails to Scala.Â At least he didn’t call it Scails!
Scala allows you to use type inference to keep the quantity of code down.Â But where you are keen to document what types are needed, you can do this too.Â He said that research has shown that the number of lines of code written per day varies very little between languages.Â This means we should use more expressive languages where possible.
Lift itself uses a more event-driven style of development to avoid the HTTP request/response cycle.Â He described it as being more like Visual Basic where you add a button and then add the code to handle the button being pressed.
Programming in the Small – Ivan Moore and Mike Hill
This was an excellent session.Â It turned into something like a 60-way refactoring session.Â They gave out samples of code and then asked for ideas on how to improve it.Â Their premise, which is similar to that in the book Clean Code, is that you need to start out by cleaning up the really small stuff.Â Once that is sorted, bigger issues will become more obvious and easier to solve.
To begin, remove useless comments and unneeded code, fix formatting and rename variables to explain their purpose.Â One top tip was to check in reformatting as a revision by itself so as not to hide real changes.Â The next step was to remove duplication, simplify conditionals and use tiny policy objects if need be to achieve this.Â Finally, look to remove statics and NoJos andÂ hide primitives inside domain objects where possible.
Clojure – Rich Hickey
Clojure is a dialect of Lisp that runs on the JVM and this talk was given by its creator.Â He said that it was the interaction between your code and the compiler that makes a Lisp a Lisp.Â He did try to convince us that Lisp does not have a problem with too many parentheses, but it turned out he’d tried to solve this (non-)problem in Clojure, so I’m not sure.Â He talked about the use of functional languages and how they simplify programming for our new multi-core world.Â Clojure solves this with mutable references to immutable objects.Â He gave various reasons why he saw object orientation as a problem and said that polymorphism is great, but should be available based on the runtime state of an object,Â because “You are not born a father”.
Â Three Years of Real-World Ruby – Martin Fowler
This talk looked at the experience of ThoughtWorks using Ruby in real projects.Â Generally it seemed to be a success and even those where it was not, the issues were more sociological than technological.Â It also seemed that having some experienced developers who knew about dynamic languages was important.Â Once a small team had put the foundations in place it would be possible to expand the team. He suggested that this idea (start small and grow out) would be more widely applicable.
Some of the issues traditionally associated with Ruby were mentioned.Â He said that so-called Monkey Patching could be controlled by putting all such changes in one place, or by putting the new code into a module to include into the class. On the performance front, he said that Ruby is indeed slow, but that most of the time your application is going to be database bound anyway.
He finished off by talking about the difficulties of testing code based on Rails’ ActiveRecord. Two big projects went different directions with this. One decided to just go with the flow and let the tests talk to the database, whereas another decided to use dynamic mocking to avoid this. It turned out that the mocking caused the tests to become brittle, so that project is now moving towards using the database instead.
Â Continuous Integration from the trenches – Julian Simpson
This talk began with the observation that continuous integration is a human activity.Â It is not sufficient to install CruiseControl, TeamCity or whatever on a server.Â If developers are not checking in frequently, it is not happening.
There was discussion of how to signal a broken build and how to label builds.Â He pointed out that there is a danger using subversion revision numbers as build labels, as these can be fragile when repository maintenance is carried out.Â Deployable builds should be labelled, but big binary files like this should not be kept in version control. An ivy repository is an alternative.
He talked about deployment scripts and how these should be kept under version control.Â He gave the example of a bash script used to deploy a system which be put under version control and ‘tested’ but simply running it and checking the exit value.Â This actually picked up an error introduced into the script by mistake.Â It is also a good idea to have the CI server grab its own configuration from version control.
He then moved onto functional tests.Â He suggested starting with smoke tests, but warned that building fully automated acceptance tests was harder than you might think.Â He then moved on to talk about running static analysis and other metrics against the code and speeding up feedback by parallelizing the builds or by having a build pipeline.Â But you need to be careful.