The 6th QCon (and 3rd annual in London) ran this past March with over 500 participants, down slightly from the year before but still going strong considering the economic environment. In this article, we present the views and perspectives of many of the attendees who blogged about QCon, so that you can get a feeling what the impressions and experiences of QCon London were. You can also see numerous attendee-taken photos of QCon on Flickr as well as thousands of tweets that went out about QCon over Twitter.
QCon is differentiated by being an in-depth, practitioner-run conference focused on content for technical team leads, architects, and project management. The conference provides both timely topics and also context and perspective: aimed at the well-rounded software craftsman. 49% of the attendees were from the UK, 37% from Western Europe, and 14% world-wide. Over 100 speakers presented at QCon San Francisco including Martin Fowler, Quicksort inventor and Turing award winner Tony Hoare, Erlang creator Joe Armstrong, Spring creator Rod Johnson, and others. QCon will continue to run in the UK around March of every year, QCon San Francisco will be running again in November 2009, and QCon Beijing as well as QCon Tokyo just ran.
Table of Contents
Tutorials
* Retrospectives
* GET Connected: A Tutorial on Web-based Integration
* Influence Strategies
* Advanced Ruby
* Aesthetic Programming
* Behaviour-driven development: writing software that matters
Keynotes
* Sir Tony Hoare: The Science of Computing and the Engineering of Software
* Zack Exley and Martin Fowler: Democratic Political Technology Revolution
* Dion Hinchcliffe: Transforming Software Architecture with Web as Platform
* Game show: It's a Bullseye! with Jim Webber
Interviews
* Scala and Lift
* FIT, TDD and Agile
* REST for SOA: Using the Web for Integration
Web as a Platform
* The Web Platform
* Cloud Data Persistence
* Situation normal, everything must change
Emerging languages in the enterprise
* Pragmatic Real-World Scala
* Clojure
* Three years of real-world Ruby
* JavaScript in the Enterprise
Turning on a sixpence - technical skills for Agile development
* You Can Get There From Here: Adopting Agile is harder than you'd like but easier than you'd think
* Programming In The Small
* Test Driven Development: Ten Years Later
* Turning on a sixpence - No excuses: Concept To Cash Every Week
* CI from the trenches: real-world Continuous Integration challenges (and what to do about them)
Real World SOA
* Steering the Northwest Passage: Beginning an SOA Initiative
* REST-based Integration Architecture for a Financial Business Service
Architectures in Financial Applications
* AMQP in action
* Transforming the Reconciliation Process
Solutions Track: Performance and Scalability Track
* Architecting for Performance and Scalability: Panel Discussion
* Building for Performance and Scalability : How to integrate performance management into your development process
* Open Standards Development: Opportunity or Constraint?
Architectures you Always Wondered About
* The evolving Guardian.co.uk architecture
* Forging ahead - Scaling the BBC into Web/2.0
Agile Organisational patterns
* Agility: Possibilities at a Personal Level
* Coaching self-organizing teams
Functional and Concurrent Programming Languages Applied
* Concurrent programming with Microsoft F#
* Lift web framework
* Persistent Data Structures and Managed References
* Multicore Programming in Erlang
Domain-Driven Design & Development
* What I've learned about DDD since the book
* Rebuilding guardian.co.uk with DDD
* The Power of Value - Power Use of Value Objects in Domain Driven Design
Java.Next - Key Technologies Shaping the Future of Java
* Java Modularity and OSGi for Application Developers
* Spring Today and Tomorrow
Architecture for the Architect
* Pimp my architecture
* Thoughts on the generic-vs.-specific trade-off
* Strategic Design
* Five Considerations for Software Architects
Historically bad ideas
* Null References: The Billion Dollar Mistake
* Standards are Great, but Standardisation is a Really Bad Idea
Systems that never stop
* Erlang: A language for programming reliable systems
* Improving Running Components at Twitter
Tutorials
Retrospectives
Sam Aaron enjoyed this tutorial:
I attended Linda Rising's retrospectives tutorial during the morning. Linda's gentle and caring presentation style is perfect for getting such delicate material across. If you have chance to see her then I highly recommend it. Linda had a number of key messages which I'll attempt to summarise here:
- Companies are using smaller and smaller iterations (for example, Amazon has one day iterations)
- Companies are having smaller retrospectives too (2-3 hours)
- We should test knowledge constantly - i.e. at the end of each iteration rather than project
- Experience provides data not knowledge
- Around 3 concrete changes to make should result from each iteration (more changes tend to be less affective)
- Typically people have feelings and thoughts but no place to express them in the normal course of business
- A retrospective is a place that you can talk about things that you don't normally get chance to talk about
- Retrospectives help create communities through 'whole-team' reflection
- Create safety by removing people that people prefer not to be in the meeting to encourage more open and flowing discussion
- Use a team-created timeline of the iteration as a medium for discussion
- Offer appreciations
GET Connected: A Tutorial on Web-based Integration
Ola Bini attended this tutorial:
On the Monday, I attended Jim Webbers tutorial called GET connected, which talked about different ways of using the web for distributing and separation functionality, where REST style SOA is part of it, but also other things like POX. It was a very information rich session, and in the end Jim had to skip several things that I would personally have been interested to find out more about, such as different ways to handle security, and so on. At the end of the day, it was a very good tutorial, but the material was really too much for one half day.
Glen Ford was also present:
First tutorial was with Jim Webber on using the Web as an Integration platform. Jim was in his usual self-deprecating mood, keeping things light hearted with the ocassional rant. (I've known Jim a while, and I nicknamed him Mr.Angry, whilst he nicknamed me Mr.Grumpy - but thats for another post)
It was actually a great session, my only disappointment was that it wasn't a full-day as there was certainly enough material for it, Jim had to skim through the last third to the most important points. The presentation for me though was especially good, as it gave me a chance to reflect on what it really means to leverage the web - it also gave me some ideas on solving current problems by using ATOMpub to handle some eventing stuff.
Influence Strategies
Martin Kneissl liked this session:
The first tutorial was by Linda Rising on "Influence Strategies". This tutorial was great: An almost perfect mix of scientific background, practical everyday context, and not the least, a great amount of warmth and humour. The techniques taught in the tutorial are quite applicable, so watch out! I might start using them on you...
Advanced Ruby
Glen Ford went to this tutorial: I thought I was being a bit ambitious selecting to go to a tutorial on Advanced Ruby given my Ruby knowledge is quite limited, i.e. only just above zero. But it turned out to be very good and quite insightful. It was the first time I had been to a Language tutorial that didn't in anyway get bogged down in syntax. The tutorial covered the Language from different approaches of coding, such as prototype, class based and functional. It was useful to learn how Ruby handled inheritance, closures, creating methods on existing classes, detecting missing methods etc. It also provided to me a chance to reflect on the other languages I use and understand them better. Sam Aaron also discussed his view on this tutorial:
For the Ruby tutorial I gave a very high level overview of the concepts I believe to be core to the majority of decent Ruby code you may stumble over. The aim was to avoid syntax in order to pack as many concepts in as possible and is a technique I'll definitely use again. Ola Bini attended and suggested that I might improve the aspect of tutorials that covered functional programming. I totally agree that these concepts could be dealt with in greater detail, however, the majority of attendees hadn't used closures or blocks before so I focussed more on introducing them. Hopefully, as more and more people get exposure to functional languages (a major force in the QCon schedule this year) then concepts such as closures will become as obvious and understood as concepts such as classes and objects.
Aesthetic Programming
Sam Aaron related his thoughts on his tutorial:
In the afternoon I gave a very open dialogue-based tutorial on programming language aesthetics. I framed communication as the basis for applying any metrics of beauty or aesthetics. Although it's valuable to say that a given piece of programming language is beautiful, I believe that it's more useful to debate the way that a given piece of programming language communicates its message. This therefore draws in key factors which can often be ignored: context, perspective, audience and intent. Also, as a general introduction to aesthetic frameworks we all discussed the differences between Modernism and Wabi-Sabi (two remarkably different frameworks). Essentially the key message I attempted to deliver was that I believe that conceptual efficiency is at least as important as computational efficiency. All in all it was very interesting to present and be part of.
Behaviour-driven development: writing software that matters
Glen Ford enjoyed this session:
This was a session I was really looking forward to, and Dan didn't disappoint, his passion and energy for this stuff really shows through. It was interesting to hear his views on how Agile is progressing beyond things like XP - in a way its become more pragmatic and seasoned I guess, and it really got me thinking how to step beyond TDD or as he rightly pointed out "Code By Example".
There was a serious amount of information in the session and it was very engaging. It was great to go back to some reasoning as to why we work well in small teams (our brains are hardwired to work well in groups up to about 10 people - pre-history family group size perhaps?). It was also good to discuss things like why it is hard to introduce change, and how to reduce the likelyhood of falling back into 'the old ways'.
Trying to summarise Dan is almost impossible and its worth hearing him talk on the subject if you get the chance.
Keynotes
Sir Tony Hoare: The Science of Computing and the Engineering of Software
Many people talked about this keynote, including Ulf Wiger:
listening to Sir Charles Anthony Hoare was a great treat. I'm a long-time fan of Hoare's and warmly recommend his Turing Award Speech, "The Emperor's Old Clothes". There are some great lessons in there.
Curiously, Qcon London began with a keynote from the scientist Tony Hoare (inventor of quicksort) that didn't make me sleep. Hoare talked about the division between the academic practices and the commercial world doing many comparisons and little jokes regarding the "I'm a scientist, I'm a engineer" world.
First up was Sir Tony Hoare. Not having a background in computer science, I didn't have quite the same feeling of awe as half the rest of the room. He made a few comparisons between software engineering (pragmatic, seeking dependability, short term view) vs computer science (perfectionist, seeking correctness, long term view), which were largely uncontroversial. Things got a bit interesting towards the end, where he stated his vision: "One day, software will be the most reliable component of every product which contains it ... because of the successful interplay of research into the science of programming and the engineering of software", and then fielded some interesting questions. It emerged that he sees complete specification as the limit of testing. I came away thinking that it's important to have the computer scientists researching new ways for us to be certain about the behaviour of computer software, and to have the software engineers deciding pragmatically which of those methods are useful, and in what doses. Whether this will ever get us to Sir Tony's vision, I'm not sure.
In the preface of Software Language Engineering, Anneke Kleppe writes, "Academic computer science is in danger of slowly becoming an empirical field that studies the advancements being made in the industry". Web programming as a fundamental platform, open source, and cloud computing movements have wildly democratized software production. Change is happening faster than most academics and vendors can keep up with - let alone attempt to lead.
[...]
QCon disciples epitomize Kleppe's statements, bypassing the ancient waterfall travelling from computer science through toolkit vendors, application vendors, and then to users. So to me, it was a little ironic that the biggest treat at QCon was actually, um, a computer science academic. Turing Award winner Sir Tony Hoare, who invented both Quicksort (woo-hoo!) and the NULL reference (doh!), gave an outstanding keynote contrasting computer science and engineering. He said that while a scientist pursues the one great story, the engineer pursues many great little stories. Let the scientist seek correctness while the engineer creates dependability. He looks forward to a day that when something goes wrong, the software will be the last suspected cause.
In his opening keynote Tony Hoare talked about the spectrum between(computer) scientist and engineer. He underlined the different goals and methods of both and how important it is that both sides communicate to benefit from each other. Interestingly the way he presented the topic was nearly identical to the workshop with Sam Aaron I attended yesterday. While Sam tried to polarize between "modernism" and "wabi-sabi" Tony Hoare did it between "modernism" (for the scientist) and "post-modernism" (for the engineer).
One of Tony's topics, that one has to have formal specification for programs to talk about correctness of programs, of course caused discussion on how to achieve formal specifications. One of the attendees suggested to use test driven development as a way to formalize requirements and Tony Hoare somehow agreed.
A contrast on Computer Science and Software Engineering - for me it was very interesting as I've often internally and occasionally externally debated as to whether what I do is really Engineering. I hold a degree in Electronic Engineering, but I have always worked in Systems or Software. A lot of what we do can be considered craftsmanship - and it was good to hear Tony say that this is part of the early life-cycle of an Engineering discipline.
Too much info to cram into this and I know it will be up on the QCon site in the near future if you are interested.
During the keynote, he tackled two questions that keep arising in the software development community: is computing a science and is software an engineering discipline?
Hoare argued that both answers must be the same - if one of them is true so must be the other. He continued that software is engineering exactly because it exploits the results of the computing science. Likewise, computing is science exactly because its results are exploited and confirmed by software engineering.
The first day of the proper QCon conference started out with Sir Tony Hoare doing a keynote about the difference and overlap between the science and engineering of computing. Fairly interesting, but the questions and answers were much more interesting stuff. One of the more interesting points made by Hoare was that in his view, a full specification is a generalization of testing.
Is computing science? is software engineering? the answers Tony Hoare argues must be the same!
In the extremes:
ScientistEngineer
- Scientist interested in the long term and scientific truth which has no finite lifetime.
- Idealism, general theories and certainty (theory supported by multiple items of evidence)
- separate of work into individual elements which can be formulized
- originality and perfection leading to reward by fame
Why then is computing a science?
- Engineer works to a fixed time scale and maybe with a fixed budget, often limited lifetime.
- Compromise, based on specific circumstances managed by risk management
- integration of diverse elements which often rely on experience and intuition
- best practice and adequate delivery rewarded with financial benefit
And Chris Rimmer:
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!
Zack Exley and Martin Fowler: Democratic Political Technology Revolution
Danny Lagrouw enjoyed this keynote:
[...] the only time I saw Fowler in action (outside the White Hart pub) was in the presentation of the software used for Obama's presidential campaign, which he delivered together with Zack Exley. In an inspiring presentation (also considering the time of day, Wednesday afternoon, just before the party) they talked about how ThoughtWorks had integrated existing and new software into a solid running system with which campaign workers and volunteers had been managed. Fowler would not say if this had won the elections for Obama, but it was clear that Obama has made use of the Internet like no candidate before him.
As did Martin Kneissl:
[they] presented how they supported Barack Obama in his campaign by working on the IT services for his supporters and volunteers. I learned a lot about the american election system which is rather different from what we have in Germany (Is it really such different? Have to think about that...). I wonder if I like the idea how much influence it might have whether the parties hire people that are good at creating web sites or not. But that's obviously one aspect of how politics works.
Dion Hinchcliffe: Transforming Software Architecture with Web as Platform
This presentation was discussed by several people including Chris Rimmer:
This keynote was about the changing landscape of application development and how cloud computing affects it. The main point of interest was that even though cloud computing may mean vendor lock-in rearing its ugly head, the cost advantages are going to make it very difficult to ignore. He has much of the same stuff on his blog at ZDNet.
"Web-oriented architecture" and his other talk "Transforming software architecture with Web as platform" by Dion Hinchcliffe predicts the obvious where most the applications will be web-based and web-oriented and still following the "always beta" philosophy because "the best products are never finished". According to Dion, the web oriented architecture is strongly based on REST plus the use of mashups, integration and widgets. Dion said we are missing portability in our applications, so he believes that by using OPML to exchange data, we'll be in the right way to the web-oriented architecture.
Hinchcliffe started by saying that "no small system can stand sustained contact with a much larger system without being fundamentally changed", and argued that the since the web is now much bigger than enterprise systems,it has a significant impact on enterprise architectures.
Quoting Dare Obasanjo, Hinchcliffe said that "my web site is bigger than your enterprise". The biggest IT centres are not in the enterprise, they are web sites. Web is today a software platform bigger than any operating system, with half a billion hosts and "has all your customers, all your competitors and all the ideas and innovation". However, Hinchcliffe thinks that there are "only a few proven strategies for long-term competitive advantage" and the community has only now figured out how to use it.
Now we are seeing that no small system can withstand sustained contact with a larger system without being changed. This has been amplified through the move to SOA, but these principles do have complexity problems - there are many frameworks to follow. The complexity has been addressed in part by REST which is at the heart of the new acronym WOA (Web Orientated Architecture), but there is still a way to go. In effect software architecture needs to be updated to mirror where we are now; everything is connected in the age of network singularity. And its not the enterprise that houses the biggest systems:
'my website is bigger than your enterprise' the biggest applications are no longer in the enterprise i.e Google, MySpace, Facebook, Amazon ...
This was the morning keynote. It was in a well presented style, however was primarily a 'state of the nation' kind of talk. Some of the interesting points for me included how building social networks around your site/product is very effective and beneficial for various reasons, including an almost off-loading some of the product support and testing into that community.
Dion covered how the biggest technology companies were hardware, then progressed to software and now were data companies. His mention of how the desktop was one of the last areas where we have "commercial software" I think this was slightly off, I think Open Source has made considerable progress and is making more all the time in that area - I think it is the Mobile desktop which is now the commercial software sweet spot - thanks to the likes of the iTunes AppStore.
He also covered cloud computing and how he felt we were at risk of falling into a very small number of large players that we trust with our data.
Game show: It's a Bullseye! with Jim Webber
Steve Vinoski enjoyed this panel:
The final conference panel was by far the most inventive panel I've ever been on. Modeled after the British game show "It's a Bullseye!" and hosted by none other than Jim Webber, it had contestants from the audience throwing darts to become eligible for a prize. Once a contestant became eligible, Jim would ask the panel - Michael Nygard, Ian Robinson, Martin Fowler, and me - to answer a question submitted by conference attendees either earlier during the conference or live via Twitter. Based on our answers, audience members held up either a green card if they liked the answers or a red one if they didn't, and if the majority was green, the contestant would win a book. The questions were hard! We had only two minutes each to answer, which for some questions seemed like an eternity but for most was way too short. Anyway, it was great fun, and given how many there were in the audience after three grueling conference days and how much they seemed to be enjoying themselves, it worked very, very well.
As did Ola Bini:
The day ended with the totally hilarious Bullseye panel, where my totally insane colleagues Dan North and Jim Webber hosted a gameshow combining darts and zany questions to a panel of Michael T Nygard, Ian Robinson, Martin Fowler and Steve Vinoski. To many great moments to even start to describe, but if I had to choose one, it would probably be Ian Robinsons answer to the question about what tech has the worst man boobs. Ian's response basically said that the problem wasn't the man boobs, but that he couldn't actually get close enough to touch them without lots of clothes getting in the way. Lovely metaphors there.
Interviews
Scala and Lift
Chris Rimmer was in the audience for this interview:
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.
FIT, TDD and Agile
Martin Kneissl enjoyed this interview:
By accident I attended the recording of this interview and I'm glad that I did. Check the video when it is online, he has a lot to say. Also check out his blog
REST for SOA: Using the Web for Integration
Sebastien Auvray attended this interview:
To finish this last day, I decided to attend the interview with Tony Hoare and another one about REST for SOA: Using the Web for Integration with Ian Robinson & Jim Webber. Apart from being very charismatic persons, Ian and Jim are very pragmatic architects, and Stefan asked them the perfect questions.
Glen Ford was also present:
Finally I attended the interview track for Stefan's interview of Ian Robinson and Jim Webber about REST and using the Web as an Integration platform. It was good to hear their views on REST and the pragmatic use of the web for machine-machine integration - I guess good because I agree with them.
Web as a Platform
The Web Platform
Mark Edgington had detaild notes from this presentation, including:
Canvas - part of the HTML 5 Specification, allowing you to have amazing graphics and image manipulation in the browser. This power is enhanced by the browsers understanding the native formats i.e video. Why is this better than flash:
- no startup time that plugins have
- available on mobile today
- typography (rendering fidelity)
- no bridge necessary to link runtime like when you use javascript and flash.
- no plugin required
- not in IE yet, typical, but can have a plugin to make it work; although this takes away some of the benifits
Ben Galbraith also explained the reason behind an issue seen during the presentation:
On-stage at QCon London this week, Dion and I gave a demo of Bespin. After spending a few minutes building up to the demo, emphasizing how fast Bespin performs, how it scales to tens of thousands of lines, beats DOM-based editor approaches-the usual litany of claims-I proceeded to mash on the keyboard and demonstrate that Bespin's performance was... decent on a hundred-line file and, as it turned out, "slow as molasses" on thousand-line files. (Still, the most embarrassing moment of the talk was to come later, when Dion talked of his hurrying home after school every day as a youth to "twiddle his paddle"; that's another story.)
Just days before, Bespin was wicked fast. What happened?
I thought it might be interesting to explain this little performance regression.
Cloud Data Persistence
Danny Lagrouw attended this presentation:
A cloud database is a database system that is available to you on the web. Instead of using Oracle you put your data in a cloud database. That might seem unthinkable to some, especially if, for instance, you have to meet strict security requirements. On the other hand, many applications don't have to deal with such requirements, or find another way to deal with them. For those applications, cloud databases offer some attractive advantages. You don't have to do maintenance or support for them. They can be almost limitless in size. Google's BigTable (which is not available yet outside Google) is said to contain table 800TB in size, distributed over many servers. But the most interesting aspect of cloud databases is that they're not (always) relational databases. Instead they often have some kind of cell structure, comparable to that of a spreadsheet. Each attribute value ends up in its own cell. You don't have to define beforehand which attributes each entity contains. Not every row will necessarily use the same attributes. And the best part is that sometimes time is a separate dimension. If a row's attribute already has a value, then assigning a new value will not overwrite the old one. The new value is added instead, with a version number or time stamp. Locking becomes a thing of the past. You will always see the latest (at time of retrieval) consistent version of an instance, but you could also request its state at some point of time in the past.
Gojko Adzic covered this talk in detail, including:
Geir Magnusson from 10gen presented a talk titled Cloud Data Persistence or 'We're in a database reneaissance - pay attention" today at QCon London 2009. The main message of his talk was that "physical limitations of today's technology combined with the computational complexity of conventional relational databases are driving databases into new exciting spaces", or to put it simpler the database landscape is changing and we should keep our eyes on that.
Presenting solutions such as Google's BigTable and Amazon Dynamo, Magnusson said that distributed databases allow us to manage huge data volumes (BigTable is designed for petabyte tables) but issues of high availability while distributing across a number of systems bring a set of requirements that often requires the solution to diverge from the relational model and lean more towards key-value or document stores.
Mark Edgington did as well, including:
Physical limitations and computation complexity are driving implementations into new area that we are not use to. Similar to when multi-cores first came out, many thought lots of software would take account of the multi-cores, but this did not happen that quickly, it's still happening now.
A regular solution to a social network with large database use is to Shard (divide into chunks across multiple servers). But remember this has changes for the developer, who now needs to look-up over multiple shards - you cannot use an SQL JOIN across a shard and you cannot guarantee uniqueness and integrity. We are also seeing developers resorting to unnatural acts to deal with the issues of large data sets i.e turning MYSQL into a keyless store (Friendfeed). good solution for them, but now the DB is no longer a DB.
Situation normal, everything must change
Mark Edgington had detailed nores from this presentation, including:
Not all IT is the same, not all IT has value as some had commoditised. This occurred through the warfare of technological advantage and copycatting. Anything new is a chance of competitive advantage anything common is a service. Follows the same path as many other industries i.e electricity innovation -> national grid. If this happens to IT, does it still have strategic value? Yes as not all IT is commoditised it is always moving along the innovation -> commodity curve, when they get there the are ready to turn into a service.
How this impacts IT
- Disruption - through the growth of the SaaS industry
- Innovation - commoditisation actually promotes more innovation through the stability of the infrastructure i.e componentisation
- Relationships - the differing service model *aaS changes the way an enterprise interacts with it suppliers. More items can be outsourced, its not common to have a single supplier model.
- No Choice - when you view you product as an innovation but the market views it as a commodity - the red queen hypothesis (risk of doing nothing)
Emerging languages in the enterprise
Steve Vinoski enjoyed the track as a whole:
Ola Bini's "Emerging Languages in the Enterprise" track on Wednesday had some great talks, especially Rich Hickey's Clojure talk. Ola's deep knowledge and love of programming languages made him the perfect host for this track, and he put together a brilliant lineup.
And Alex Cordellis attended the track introduction:
I popped into Ola Bini's introduction to the emerging languages track, to see him explain why languages are important. My highlight here was Ola's point that it's all about communication, and we need to consider the best medium (i.e. language) for communicating each part of our systems to the machine, and to other humans. Since the target of our communication changes, so should the medium, and this is why we need different programming languages.
Pragmatic Real-World Scala
Glen Ford enjoyed this presentation:
Very interesting JVM based language with very good integration with Java. Provided an elegant mix of OO and Functional programming - and so provided a clean path to move towards more functional models. The session went through some of the language features, but one of the most impressive things shown was a demo of a web chat system written in 30 lines of code.
A really nice concept of Traits which could be added at either class or instance levels - so much information that I have no hope of conveying it. But has inspired me to take a closer look.
Clojure
Glen Ford attended this presentation:
A "Lisp" Functional Language that runs on the JVM. Was a very interesting presentation and the language has some really interesting features including how it dealt with concurrency.
As did Chris Rimmer:
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
Sebastien Auvray wrote about this presentation:
In Three years of real-world Ruby, Martin talked about his feedbacks on the 64 (or 63.. I cannot remember) projects done at ThoughtWorks. Martin is a brilliant speaker and by relying on a nice metric his whole presentation was convincing.
As did Pedro Pimentel:
Martin talked about how people were dealing with ruby, how the productivity was affected and many other considerations of using ruby for real world projects. According to Martin, there are 41 projects made with ruby. One thing Martin said, was how people felt when they need to go back to work with languages other than ruby. Not surprisingly (for me) most of the people didn't want to go back to work with other languages, mostly because the easy of use of ruby. About ruby performance in the projects, Martin said "Ruby is slow, but that's not the bottleneck in most of applications. The biggest cause for slowness nowadays is accessing database" . Regarding the tools to develop with ruby, once again, wasn't any surprise for me. Nobody in the team feel the need for a IDE like Eclipse. All in all, nothing new for me in his talk, but it's always good to hear from guys like Martin.
And Alex Scordellis:
It was good to see some statistics backing up the idea that Ruby works in the enterprise. 36 of the 41 projects ThoughtWorks has undertaken in Ruby would use it again, and of those 5 that wouldn't, 4 said that the reason was due to the problems getting people to adapt to Ruby, rather than Ruby's ability to perform the job required. An amusing anecdote midway through: developers on a Ruby project estimated their productivity boost (over, say, Java) as 2-5x in earlier parts of the project, reducing to 1.5x in later parts, but jumping back up to 2-3x when they had to go back to Java and remembered just how bad it was! Martin's a great speaker, so as always it was an entertaining session.
Chris Rimmer also weighed in:
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.
JavaScript in the Enterprise
Tim Anderson enjoyed this presentation:
The best sessions here at QCon London have been the small ones, not the big ones. Yesterday the slot I enjoyed most was from Attila Szegedi on JavaScript in the Enterprise. He uses Mozilla Rhino for server-side development. It's not a mainstream choice; but he made a case for it, saying that continuations in JavaScript bring huge benefits, that there is a ready supply of developers with JavaScript skills (albeit mostly browser-based), and JavaScript is so flexible that he can work around any limitations.
Gojko Adzic also wrote about this talk:
Attila Szegedi today suggested using JavaScript as a scripting language for server side JVM systems, during his JavaScript in the Enterprise talk at QCon London 2009 conference. Szegedi named stack-based continuations as a huge advantage of that approach. Stack-based continuations are effectivelly asynchronous calls with a callback, but without the weird code that typically comes with closures, asynchronous calls and callbacks.
Basically, the idea is to:
- interrupt the call, grab stack, store and execute the call asynchronously
- when the response comes in, pull the stack out and continue working
- physical thread is free to keep working on something else meanwhile
- not write this explicitly, have the framework do it for you so that code looks like the usual procedural program
Turning on a sixpence - technical skills for Agile development
You Can Get There From Here: Adopting Agile is harder than you'd like but easier than you'd think
Pedro Pimentel attended this presentation:
Keith Braithwaite started his talk "Adopting agile is harder than you'd like but easier than you'd think" by comparing costs of a developer and hardware costs. Keith showed some statistics of how people improve productivity by using bigger monitors and how these hardware costs are related to the developer costs. According to him, if your company don't gives you a big monitor, they are loosing money due to loss in productivity. Other comments he did were about pair programming where he defends its use in an all the time basis, saying that "choosing to work alone, is to choose have less quality in your code". In a rant about Rockstars developers, Keith said that them should not be part of a team but hired as consultants or contractors instead. Finishing his talk, Keith presented some points to consider in order to know if agile methodology is working in your team which are: estimates converge, quality remains high over long periods and the team by itself find new approaches to work better.
Programming In The Small
Chris Rimmer discussed this session:
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.
Test Driven Development: Ten Years Later
Alex Cordellis wrote about this talk:
I then decided to go to Michael Feathers and Steve Freeman talk about the history of TDD. Having written and co-written Working Effectively with Legacy Code and Mock Roles, Not Objects respectively, I have a lot of respect for these guys. Those texts played key roles in my understanding of good OO design. The session was an interesting history lesson, a useful reminder of the core principles, and contained a few nice anecdotes. I was particularly tickled by the fact that early practitioners of testing (Gerry Weinberg, Kent Beck) just assumed that everyone else was doing testing too, as they considered it to be part of doing a professional job. Plus ça change.
Gojko Adzic took detailed notes, including:
Feathers and Freeman started the talk by saying that it has been around 10 years since TDD went public and started gaining wider adoption, but that it has origins a lot earlier than most people would consider. Gerald Weinberg, working on punch card machines in the 60s, had to get it right quickly so he articulated requirements as tests and guided developments with those tests. Feathers quoted Weinberg that "It was just assumed that any pro would do a damn good job of this activity". In late seventies, Ward Cunningham was working on a Wyatt Software spread-sheet system, where he short circuited the development process by reading spreadsheets into a test framework he wrote in a day. That helped his team produce software quicker but also benefited with external audits verifying the correctness of the software. Feathers quoted Cunningham on "We sailed through a big five audit when an auditor admitted that he'd necver seen anything like out test browser and passed us before lunch". So people were doing things similar to TDD before, but did not really advertise it so it did not get wider adoption.
Turning on a sixpence - No excuses: Concept To Cash Every Week
Simon Baker covered this presentation:
Yesterday at QCon London, Gus and Kris talked about how we at Energized Work get from concept to cash every week. It's a simple message really.
Keep it moving:Keep it working:
- Sustain throughput and maximize profit by 'shipping' running tested features to production at least every week.
- Automate everything to achieve mobility and continuously invest in it to keep it cheap.
- Don't track bugs, fix 'em.
- Manage debt to keep moving fast.
- Eliminate individual anxiety and keep the team resilient by pair-programming all the time.
- Roll ownership of each story through the team to facilitate collective ownership and knowledge transfer.
- Maintain a rigourous test-driven approach through personal discipline.
- Colocate because the conversations never stop.
- Learn what's really needed by iterating with a full-time onsite customer at the wheel.
Jerome Pimmel also wrote about it:
It's worth reviewing the slides (available via [this] link) to get a sense of how using such methods can help achieve the following
- Create and maintain an energized, engaged and fun development team
- Getting into production fast, deploying to production weekly
- Total test coverage ensures minimal ongoing production problems
- Continuous QA, customer/product owner feedback assures fitness to requirements
- No bug databases means -> kill all bugs immediately, ALWAYS
- Continuous environmenting: the dev team creates, administers and supports all environments whether test, QA or production (why? No silos, eg: systems admin team)
- Tracking your released features delivered against fiscal metrics
- Showing the client that project is maximising profit with each weekly release and thus keeping them excited
CI from the trenches: real-world Continuous Integration challenges (and what to do about them)
Chris Rimmer attended this presentation:
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.
Real World SOA
Steering the Northwest Passage: Beginning an SOA Initiative
Alex Scordellis enjoyed this presentation:
This was my pick of the day. It was one of those talks that makes you consider a whole new approach to an area of your work. I've picked out some key messages.
- We should focus on capabilities which realise outcomes which deliver benefits (the what), rather than on services for services' sake (the how). This allows us to focus on delivering those capabilities which differentiate our business from our competitors.
- There's a key difference between who is responsible for a business capability, and who is responsible for keeping a web service up. Engaging those in the first group will help engender a sense of ownership and urgency and ultimately lead us to more value-driven systems. For example, Ian suggests Responsibility Focused Stories (as
, I am responsible for , which delivers ) to help identify these people and their responsibilities. From my own recent experience, I can attest that getting these business capability owners involved is often a significant challenge, particularly inside large companies, and I hope to use Ian's ideas to help me do this. - Different service implementations are needed for different business capabilities, even if they operate on the same data. Don't always assume that your business entities will take the same form and live in the same services. In particular the way we use and represent an entity may change significantly over the lifetime of that entity (consider the different capabilities involved in signing up a new customer, and performing daily financial trades on behalf of that customer). Update: see comment from Ian below for a clarification.
- Use consumer-driven contracts to reduce coupling between service providers and consumers.
- Have long-lived capability delivery teams responsible for business capabilities, but augment them with additional resources and knowledge from new projects that are taking advantage of the capabilities.
As did Glen Ford:
Really good insight into starting a big project especially in an already running system - good to see SOA talked about as SOA (the approach) and not SOA as a vendor pitch to buy their latest golden hammer.
REST-based Integration Architecture for a Financial Business Service
This talk interested me as it was about moving from WS-* to REST and using the likes of ATOM/ATOMpub.
Must admit that brain fry had begun to set by now and I didn't take it all in. But was interesting to hear Phillip's view on - use REST at the interface boundary but don't try and use it internally as the latency cascade will bite you.
Architectures in Financial Applications
AMQP in action
Gojko Adzic covered this talk in detail, including:
During the AMQP in Action session at the QCon 2009 conference in London the speakers presented what seems to be a very interesting solution for probably the biggest issue in messaging middleware today- interoperability. Message oriented middleware (MOM) is often standardised at the API level (such as JMS) but individual implementations are not compatible on the protocol level so they cannot work with each-other, often resulting in vendor lock-in. John O'Hara from JPMorgan said that dominant messaging solutions today are proprietary, too expensive for everyday use and don't interoperate, which lead to incumbent stagnating. That has resulted in lots of ad-hoc home-brew solutions. AMQP (Advanced Message Queueing Protocol) tries to address this by presenting an open universal standard.
Transforming the Reconciliation Process
Martin Kneissl attended this presentation: It was a great presentation that covered the functional requirements on reconciliation, what's difficult about it, and how you could use data grids to improve the situation. asdf was also in attendance:
In the QCon London track, Architectures in Financial Applications, Oracle presented an interesting solution that seeks to transform the reconciliation process from an inherently batch process to an incremental event driven asynchronous one. They presented a solution based on Coherence, their data grid that addresses the capacity challenge by spreading trades across servers and the availability challenge through the resilience of continuous replication that Coherence supports. As part of the presentation, the Coherence based solution touched upon one important paradigm, which can be adopted even outside grid based architectures to improve system performance and throughput.
Solutions Track: Performance and Scalability Track
Architecting for Performance and Scalability: Panel Discussion
Danny Lagrouw attended this panel:
After my own performance tuning activities at my current client, I was eager to listen to the Architecting for Performance and Scalability panel early Wednesday morning. Well known names like Cameron Purdy (Oracle) and Kirk Pepperdine (independent consultant) and a less well known name like Eoin Woods (architect at a big investment group) discussed all kinds of performance related topics. A discussion like this will easily take off in all directions, leaving several individual sound bites. In all their simplicity they still offer food for thought though. For example:
- The war on latency will become more important than execution profiling.
- If you have to tune a 9 to 5 system, record user actions during the day. You can use them during evening hours to simulate a representative load on the system.
- In order to tune well you have to benchmark. Benchmarking must be seen as a project in itself. And benchmarking might turn out to be more expensive than throwing more hardware to the system.
- If using 'new' languages (JRuby, Groovy etc.) causes performance problems, then these problems will be solved. Just like it happened with Java.
- The problem with marshaling XML in a SOA isn't the time it takes to (de)serialize XML. It's the time it takes to (de)serialize XML multiple times in the same request.
Martin Kneissl was also present:
For me the nuggets in this discussion wereAnd it has been great to have Cameron Purdy in the panel who really nails some things down...
- When you have a scalable architecture, linear gains / penalties don't shift the ultimate limit (but costs...)
- While language might change the way you think about problems its implementation does typically only linearly affect performance (and then see above)
- When doing SOA, watch out for services that provide too much data to important consumers, as the network is a bottleneck.
- Use real data when doing performance tests because artificial test data might be too random or clustered in ways different from real data such that data alignment / indexes / whatever are used differently leading to false results.
Building for Performance and Scalability : How to integrate performance management into your development process
Glen Ford attended this talk:
Outlined the cause of many performance issues, and very high level ways of detecting these issues - but there was nothing new here, and no practical demonstrations of the methods, and no hard data.
This is an area I am quite familiar with having spent time 'in the trenches' dealing with these problems, and having spent time developing ways to help mitigate them. So I was disappointed - I felt there is so much more on this subject, particularly how easily steps can me made to introduce ways and means of detecting performance deviations early on in the process. Big expensive tool-sets are not necessary to begin this process (or at all in my view).
Open Standards Development: Opportunity or Constraint?
Mark Edgington attended this panel:
Standardization is essential for certain parts of the stack, those items that change least frequently i.e lower in the stack. Higher in the stack needs to change frequently and here standardization kills innovation. We need to remember it take a lot of time to get to a standard and also Open Source will always be easier to engage with as a develop than a standard.
Open standards can also help open source, as many companies are not interested in using an open source project unless it has a sponsor or is part of a well know organization i.e Apache. However, it really needs to start open source and move to open standards, just trying to become a standard often leads to the wrong group of people getting involved in the standards process; it all gets a bit political and horse trading occurs over functionality. But moving toward a standard can also be impossible for small companies and individuals to get involved in a standard, whereas it is easy for Oracle and others (who have staff with this as there sole responsibility). Also standards can feel like they are dictating how we should be working and this can grate a little when we are already working well ; Is the JPA better than hibernate - No.
Architectures you Always Wondered About
Peter Maas commented on the track as a whole:
Things I've learned (or heard again but think are important to keep mentioning) today:
- BBC has plans very similar to what I'm working on for Dutch broadcaster VPRO. A REST oriented service layer with lightweight widget/mashup rendering above and tools suited for the problem domain below. They are just a tiny bit further then we are at the moment.
- Guardian.co.uk built their application quite similar to the way I architected/developed cinema.nl apart from some details in caches. They are happy, but moving to REST oriented architecture to reduce coupling as well.
- Architects are falling from their towers and starting to use common-sense technology (like HTTP, RSS, ATOM, REST) more and more and are abandoning 'enterprise' patterns and tools (think JEE, Portals, SOAP etc).
- New architectures are often more about the social aspect then the technical aspect
The evolving Guardian.co.uk architecture
Nik Silver attended this presentation:
Mat's presentation was structured around rebuilding guardian.co.uk over many months and dealing with the scalability issues that were presented at various stages. Some of the many insights were presented in a deliberately provocative way, such as this one:
Developers try to complicate things; architects simplify them.
I'm not entirely sure about the first part, but it's certainly true that over-engineering is a much more common trait than under-engineering. The second part, though, is very important. It's something I've always known, but never quite in that pithy way. It's a useful phrase to tuck away for future reference.
Mark Edgington took detailed notes, including:
by 2007 had outgrown there existing vingnette architecture. So entered a 18month re-design.Issues to deal with
- agile build
- 4 development team
- 2> million pages to migrate
- lots of new functionality.
- build on a java stack (Spring, Hibernate, EHCache and Velocity)
- Endeca as a search engine
- Develop in parallel with existing site
- Zero downtime - migrating section by section - used an Apache mod to allow selection of back-end to serve from
- Architecture as the system develops - start simple with travel 14k articles - will fit in RAM so can worry less about DB, can turn DB off by stopping cache timeout, this allowing upgrades.
- Co-located hosting across Manchester and London
Forging ahead - Scaling the BBC into Web/2.0
Dirk-Willem talked about the programme to re-engineer the BBC websites to enable greater scalability and dynamic content. In an organisation the size and complexity of the BBC you need to spend more time thinking about people than the technology. One of his first slides underlined this by presenting the seven layers of the OSI model (physical up to application) and then said
But most people forget there are two layers on top of that: level 8, the organisation, and level 9, its goals and objectives.
From that point on he kept referring to something being "an L8 problem" or "a level 9 issue". It was a powerful reminder that technology work is about much, much more than technology.
Agile Organisational patterns
Agility: Possibilities at a Personal Level
Pedro Pimentel attended this talk:
During 95% of its time, she talked about Caffeine and the way it affects a person's health. It was for sure a nice talk and Linda definitely knows how to keep people's attention. The message that she tried to present was that being agile can be (bad) the same way "caffeine" is for our health because being agile makes you feel energized, stimulated, addicted to work and makes work be a fun thing but our body and mind are not ready for such "energy".
Glen Ford was also in attendance:
I chose to go to Linda's presentation as a couple of people had recommended listening to her speak if I ever get the chance. And I must say that I am glad that I did, not just for the content, but also for her relaxed and engaging presentation style.
So it was mainly a discussion about drugs, well caffeine, the worlds drug of choice, nothing else comes close with apparently around 90% of the worlds adult population consuming it daily in some form or other.
The talk (I feel) really centered around the Industrial Age and how we are still behaving and living in a manner consistent with that time. A lot of interesting facts, I knew about the drinking of beer due to bacteria in the water, but never put it together that accurate time pieces and tea/coffee became readily available at the same time - the time of the industrial revolution. And the process of making tea/coffee of course required boiling the water. So people needed to wake up for their shift at the factory, and instead of beer they would have tea/coffee which because of the boiled water was safe.
Coaching self-organizing teams
Pedro Pimentel wrote about this presentation:
Joseph Pelrine in "Coaching self organizing teams" was about how to make people do things without telling them directly. It's all a matter of achieving the right behavior which for Joseph is a function of people vs environment. Self organizing teams have a emergent behavior and are in general conditioned to the "first fit pattern match". It means, they make decisions based in what they experienced. This kind of team needs diversity in terms of behavior in order to stimulate a evolving behavior as a team. A team is not just a bunch of people working together, they need "heat" to move and work better. According to Joseph, it's near "chaos" when people do they best.
Functional and Concurrent Programming Languages Applied
Sebastien Auvray commented about this track as a whole:
I spent the second day on the Functional and Concurrent Programming Languages Applied track which was led by Francesco Cesarini. The high moment of the day was the presentation by Rich Hickey about Persistent Data Structures and Managed References about states, process, identity and applications to Clojure. Multicore Programming in Erlang was also quite interesting. This whole track convinced me to have a closer look at Clojure, but also confirmed my choice to learn a functional language in 2009 which is the reason why I came back in Paris with Real World Haskell book in my bag (Yeah I know, Erlang is cool and was well covered during QCon but a friend advised me to have a look at Haskell). At the end, I learnt many concepts and ideas that could be applied in my day-to-day job or side projects.
As did Steve Vinoski:
I met Francesco, who like Ulf is one of the world's top Erlang developers, at QCon London last year. He assembled a great track for this conference, with Rich's and Ulf's back-to-back talks being way more than enough to sober up any developer who thinks that multicore is not an issue and that today's methods for dealing with concurrency will continue to work just fine. Best of luck with that!
Concurrent programming with Microsoft F#
Tim Anderson attended this presentation:
Today I've just attended a session on Microsoft F# given by Amanda Laucher. F# is a functional language that will be released as part of Visual Studio 2010. I knew little about it until today. Laucher gave a code-heavy presentation looking at how the ease of concurrency in F# can greatly increase speed of execution, using an example from the car insurance industry.
As did Ola Bini:
In the DSL track, Amanda Laucher gave a good overview about what Oslo is and why you might want to use it. What I was looking for here was just enough of a look at the tech to see if this is something worth investing more time in. My conclusion was that at this point in time, it doesn't seem to give me much new that would help me. Especially the Mgrammar stuff seemed to be a not-invented-here copycat of Antlr. Martin corrected me about that, though, by pointing out that Mgrammar actually handles GLR grammars. My intuition is that ANTLRs LL(*) would be able to handle most of the same parses, but that's not something I would bet money on. Mgrammar also doesn't need semantic predicates to avoid left recursion, which can make the grammars more readable.
Lift web framework
Ric Smith wrote about this presentation:
What struck me most about the talk is how well Scala lends itself to the concept of the real-time Web-a concept that we try hard to evangelize at Kaazing. With Lift, many of the view components are Comet enabled which allows for real-time Web platform. Very cool, I must say. Even cooler, if we can sprinkle a little bit HTML 5 on there. ;-)
Persistent Data Structures and Managed References
Several people wrote about this talk, including Ulf Wiger:
This time, I was preceded by Rich Hickey's talk on Persistent Data Structures and Managed References in Clojure. I was greatly intrigued by this talk and made a note to take a closer look at Clojure. Interestingly, Rich stressed that Clojure Agents are not actors a la Scala or Erlang. Part of my talk was to illustrate how Erlang processes are not "fibers", and trying to use them for data-parallel algorithms can be problematic. Nice setup.
A problem with staying in a profession for long years is that there's less and less things that can truly excite or surprise you as the time passes. That's why I was particularly delighted to experience a moment of sudden enlightenment while listening to Rich Hickey talk about "Persistent Data Structures and Managed References" last thursday at QCon in London. The title of the talk might not sound exciting, but I have to tell you, if this were the only talk I attended, it alone would have been worth attending. I don't say this often. Slides are here, although you're missing out Rich's incredibly good verbal presenting style if you just read them, obviously.
According to many visitors, the best QCon 2009 talk was Rich Hickey's: Persistent Data Structures and Managed References. Hickey truly is a gifted speakers who knows how to get a point across. He is the creator of Clojure, a Lisp variant running on the JVM. On Wednesday, Hickey had already talked about Clojure itself, explaining why he had developed Clojure, why it's running on the JVM (libraries, resource management, type system), and why we'll more and more be needing functional languages like Clojure. The latter was worked out in more detail in the Persistent Data Structures talk. Hickey said mutable, stateful objects are the new spaghetti code. Mutable stateful objects are objects that don't always return the same answer to the same question (like "person.getProfession()"). This is bad because it may cause problems in a multithreaded environment, with which we'll have to deal a lot more often, thanks to today's multicore processors. Two separate threads might try to change the object's state at the same time. You might prevent this with locking, but it's hard to get locking right. Using this argument, Hickey discards the entire object oriented programming model: functional programming FTW! Still he must concede that state remains necessary to develop a useful system, and that you'll have to be able to change that state as well. His solution to this is Managed References.
And Ola Bini:
This was without doubt the best presentation at QCon this year. Rich spent lots of time talking about identity, state and value. It was very good - you should go to http://qconlondon.com/london-2009/schedule/thursday.jsp and take a look at the slides for it. It is pretty deep stuff. I heard many other people share my opinion of the quality of this talk. QCon and JAOO could do much worse than getting Rich back for the next time.
Multicore Programming in Erlang
Steve Vinoski enjoyed this presentation:
I also finally got to meet Ulf Wiger, Erlang developer extraordinaire, in person. He's a laid back guy, quite well-informed and a deep thinker who can cover a wide variety of topics in amazingly useful detail. His talk on multicore programming in Erlang covered cutting edge Erlang development and presented some very difficult concurrency issues.
Domain-Driven Design & Development
What I've learned about DDD since the book
Chris Rimmer wrote up a detailed sumary of this talk, including:
Something that was in the book that he thought could be left out was Large Scale Structure, which doesn't come up too often. On the other hand, he suggested a couple of new context patterns:
- Partners - Mutually Dependent and Cooperative
- Big Ball of Mud - Common. Know that you can't do sophisticated modelling within and accept that.
Danny Lagrouw also wrote about this talk:
Eric Evans, author of Domain-Driven Design, looked back on the five years that had passed since the book came out. One thing he would have wanted to emphasize more was mapping of contexts and context boundaries. Evans considers a domain model to have boundaries based on its context: an entity (like Person) might have a whole other meaning from one domain to the next. Also, he feels that the building blocks for designing a domain model (e.g. Entity, Value Object, Factory, Repository) are often overemphasized. It's not about the building blocks, it's about the principles of DDD. I couldn't agree more. Nevertheless, Evans described a new building block that isn't mentioned in the book: Domain Events. Domain Events should not be confused with technical events; they're events in the domain that have meaning to domain experts. A DDD architecture can benefit from using Domain Events, because they offer a way to decouple subsystems. Also they may result in a better performing system, even though people often think otherwise.
Gojko Adzic also covered a lot, including:
- Creative collaboration of domain experts and software experts is essential. When most projects get their hands on the domain expert they don't utilise their time properly. Starting with a requirements document and going through the boring list of requirements will drive domain experts away and they will become "too busy" to help. Like anyone else, domain experts don't like to do things that they don't see value in. We need to use their time efficiently and really show how valuable their participation is. Instead of going through an itemised list of boring requirements, Evans suggests using their time to explore the domain, prototype, make it a creative process and ensure that the value is evident.
- Exploration and experimentation is essential. Teams usually stop when they get a first useful model that does the job. Evans said that with this, "you are leaving so many opportunities on the table". Exploring models is cheap if you're brainstorming at the whiteboard or prototyping, and "If you get nothing but good ideas in a modelling session, you're not being very creative ". Evans suggested rule not to stop modelling until we have produced three bad models.
- Shaping and reshaping the ubiquitous language with emerging models shaping is essential.
- Expressing context boundaries is essential. This is covered in chapter 14 in the book and Evans said that this is one of the few regrets he has about the way he wrote the book and that he would do it differently if he had to do it again. Putting effort into defining contexts and boundaries is essential to get to good models. Evans said that "the reality is that there is always more than one model" and mapping these models out is crucial to setting the stage for success of a DDD project.
Rebuilding guardian.co.uk with DDD
Nik Silver attended this talk:
Phil talked about the role domain driven design has played for us. He also pointed out various lessons that there were learnt along the way, such as the importance of value objects, and the fact that "database tables are not the model - I don't know how many times I can say this."
But it was only a day or two after his presentation that I was struck by a remarkable thing: Phil referred so many times to specific members of the team, and talked about contributions they had made to the software design process, even though the people he was talking about were generally not software developers. He put their pictures up on the screen, he named them, he told stories about how they had shaped key ideas. This was an important reminder to me that being close to our users and stakeholders on a day-to-day basis is incredibly important to the health of our software.
Mark Needham also discussed it:
- Phil started by explaining the reasons that they decided to rebuild their website - tedious manual work was required to keep the site up to date, they were struggling to hire new developers due to their choice of technology stack and it was difficult to implement new features.
- They were able to get domain experts very involved with the team to help define the domain model and trusted the domain expert to know best. I think the difficulty of making this happen is underestimated - none of the projects that I've worked on have had the domain expert access that Phil described his team as having. The benefit of having this was that they had times when the business pointed out when the model was getting over complicated. The takeaway comment for me was that we should 'strive to a point where the business can see and comprehend what you're trying to achieve with your software'
- Entities are your stars but we need to also think about value objects. Entities have the maintenance overhead of having life cycle that we need to take care of so it makes sense to avoid this wherever possible. Phil showed an example of an entity class with around 50 fields in which could have been severely simplified by introducing value objects. Every time I heard value objects being mentioned it reminded me of micro/tiny types which are not exactly the same but seem to be fairly similar in their intent of improving expressiveness and making the code easier to work with. The importance of value objects was also mentioned in Eric Evans talk.
The Power of Value - Power Use of Value Objects in Domain Driven Design
Chris Rimmer enjoyed this talk:
This was an entertaining talk on value objects in DDD, which seem to be the poor relation compared to entities. Lots of this was just good old fashioned object oriented design, with a domain driven slant. Value Objects differ from Data Transfer Objects since DTOs are a technical construct, whereas VOs are true domain objects.
He showed how pulling Value objects out simplifies the code and helps to avoid bugs, awkwardness and duplication. It also helps the business logic concentrate on just that, without getting bogged down in other issues. He worked through some examples, with his credit card exchange rate example particularly compelling. Having orthogonal classes means that in general m+n tests will be needed where previously m*n would be required.
Mark Needham also enjoyed it:
- We started out with a brief description of what value objects are not which I found quite amusing. To summarise,they are not DTOS, not Java beans and not objects with public fields. The aim with value objects is to swallow computational complexity from our entities. Creating what Dan termed 'compound value objects' provides a way to do this. The benefits of doing this are reduced complexity in entities and code which is more extensible, more testable and has less concurrency issues.
- I found myself quite intrigued as to how you would be able to spot an opportunity in your code to introduce a value object and almost as soon as I wrote down the question Dan covered it! Some opportunities include strings with format limitations, integers with limitations or arguments/results in service methods. The example used was a phone number which was being passed all over the place as a string - refactoring this allowed the code to become explicit - before the concept existed but it was never properly spelled out - and it pulled all the functionality into one place.
Java.Next - Key Technologies Shaping the Future of Java
Java Modularity and OSGi for Application Developers
Chris Rimmer went to this presentation:
This was an introductory talk on modularisation using OSGi. He started by saying that while jars have dependencies, these are implicit. OSGi uses modules, which are just jars plus dependency metadata. He had a tongue-in-cheek dig at SOA by pointing out that since we can't use classes in isolation due to the dependencies we have to call them remotely instead. I was surprised to find out that Spring-OSGi had to be renamed Spring-DM ("Dynamic Modules") due to pressure from the OSGi Alliance. The takeaway message was that you need to use something like Spring-DM to take care of OSGi for you and don't code directly to services.
Spring Today and Tomorrow
Gojko Adzic wrote detailed notes, including:
Probably the most important infrastructural change is that from version 3.0, Spring will work only on Java 5+ platforms. The project layout will change slightly, moving to Maven style finer grained system of projects, which will be built using the the new Spring build system ("as known from Spring web flow 2.0″) which is OSGi based.
In terms of new features, Johnson pointed out the following innovations:
- Expression language for configuration
- Comprefensive REsT support
- support for Portlet 2.0
- Declarative model validation
- Early support for Java EE 6
Architecture for the Architect
Pimp my architecture
Danny Lagrouw liked this talk:
North's idea of an architect is someone who collects stories, someone who's able to hear out the history of the shanty town, who will understand decisions that have been made, even if he would have done it otherwise. When he's heard enough, he won't push through the necessary changes regardless and all at once. It is possible to take smaller steps, use transitional architecture, to get people used to the new ideas and to see how the changes turn out. Dan North comes across as an architect who's just as concerned with the social aspects of software development as he is with the technical side of things.
As did Mark Edgington:
Start by doing nothing, listen, listen and listen some more. But, take into account that all you hear may no be true.Now it's time to set a strategy for the future (give yourself air cover), once you have a strategy:Note: pairing is just helping, easier to sell in.
- make sure you are moving on and not just re-hashing the old, but you may need an interim architecture to get you to utopia.
- make sure the team are with you and change the culture as appropriate - rotate roles - encourage coaching - future ambassador/architects
- keep to the strategy and use the right technology stack
- introduce bounded contexts and shape to the codebase/services
- make it easy to share knowledge - make sure the stand-ups are effective, not just news.
- if it's not working be honest so you can get it right
And Glen Ford:
Dan has a great presenting style, and during this presentation he emphasised the importance of the team Shaman, the team story-teller - and I think he proved himself to be one of the best through this presentation.
I really enjoyed this presentation, as it emphasised the importance of the oral tradition within a development team. And I do feel that is important, the best teams I have worked in have always had this, it meant that new team members came up to speed quickly on the quirks and history of a project, and really helped build the team.
I also enjoyed his 'Shanty Town' pattern - as opposed to the 'big ball of mud'. The truth is as he rightly points out, you just can't rush in and bulldoze, the people have to live somewhere - but you can work to improve it, piece by piece. You can build scaffolding or temporary architectures in the process of rebuilding the town.
Too much to convey it all or even a fraction, but I must say if you get the chance to hear Dan speak it is worth it, his energy and passion are contagious.
Thoughts on the generic-vs.-specific trade-off
Ola Bini enjoyed this presentation:
I saw Stefan Tilkov do a very deep presentation on his thoughts on the balance between generic and specific in architecture and development. Stefan shared his long experience in a funny and thoughtful way that contained lots of interesting insights.
Glen Ford also enjoyed it:
Stefan's talk was great, in particular my favourite snippet from his talk was:
The wise architect ...
question: *
answer: It depends.
And its so true.
Summing up his talk is difficult, as the two sides tend to cancel out, i.e. it depends. But it was good and he covered a lot of good specific versus generic examples.
Strategic Design
Mark Edgington took detailed notes, including:
Not all of a large system will be well designed and this can pull your attention in multiple directions. The goal is to have the most important part s of the system well designed - strategic design.
Take two loosely coupled systems that have grown independently, but are starting to move toward interaction. The decision was to move towards a new system, byBut, whichever of these 3 approaches is taken you are prone to end up with the Lets Hack endpoint. So is there a potential solution? How about Domain Design and the core principle 'Distilling the core domain'.
- A series of steps - But, it's never going to work like that. Why? as the old business logic is taken there will be more and more parts of the old system that take inadvertent amounts of time. This will lead to just porting sections of code, without re-design and this cannot be well tested. Which, means your new system ends up partitioned into old and new sections - coupled with changes to the original system can mean the project will just end. What are the alternatives:
- Refactoring - keep the system running and change parts by increments. You have the danger here that the best people work on the new items and the others work on system updates, but do everything they can to work on the potentially good stuff.
- Note - the real mess is made by the 2nd worst dev on the team , as everyone is watching the worst like a hawk.
- Lets Hack - this will just end up in an almighty mess
Glen Ford was also in attendance:
Another really good talk, Eric covered some interesting perspectives on dealing with legacy systems, and the approach you could take in a pragmatic and progressive way. And along the way discussed various issues you need to deal with.
The strategic design comes from, making sure the most important parts of the system are well designed.
Some good points he made ..Why do irresponsible programmers so often become heros? Because they don't waste their time making other people more productive, they don't clean up other peoples mess, but they do produce new capabilities no matter the impact.
- One irresponsible programmer will keep any 5 top-notch programmers busy cleaning up after them.
- The quality of the code is equiv to the second worst programmer on the team. (Not the worst, he is watched like a hawk)
- Remember, the core domain is what makes the system worth writing.
- Heroes work in the core domain (they make the system features the business needs and wants).
Five Considerations for Software Architects
Glen Ford liked this presentation:
Well today turned into a treat, Kevlin was another good presenter, with a lot of information and some good techniques covered. The presentation was based around a visit to a pub where he and a couple of others (poor memory, cannot remember their names) and tried to distill 5 things every architect should take into mind. These distilled down to:
- Economy - economy in code, in design and in architecture
- Visibility - understanding not just the end product but how it came about
- Spacing - the interesting thing is the space between the components not necessarily the components themelves
- Symmetry - makes things easier to understand and maintain
- Emergence - understand the emergent properties of the problem and the solution
Historically bad ideas
Null References: The Billion Dollar Mistake
Several people wrote about this presentation, including Sebastien Auvray:
I followed most of the Historically bad ideas track. This track was a very original good idea. But as Aino Corry stated, convincing speakers to participate to such a track was far from being a piece of cake (we all have our egos), unless... Sir Tony Hoare would be part of the track. His Null References: The Billion Dollar Mistake session was a good historical overview of what lead him to introduce Null References.
Sir Tony Hoare's talk about the null reference being his "billion dollar mistake" was great because of all the detail he recounted from some of the early days of computing. He was both informative and entertaining. I was also impressed with Ulf during this talk, whom Professor Sir Hoare invited to come up to the front and present what turned out to be a pretty convincing argument in favor of the null reference.
And Ola Bini:
After the presentation, Hoare asked me if I was interested in being part of a panel during his after-lunch presentation. The presentation was about null references, which Hoare calls his billion dollar mistake. To be fair, I think it was one of those inevitable things, that would have happened sooner or later anyway. Ulf Wiger became part of the discussion, and presented a much better defense than my point about inevitability.
Ola also was inspired to delve further into this area of discussion:
On the Friday of QCon, Sir Tony Hoare held a presentation about the null reference. This was interesting stuff, and it tied into something I've been thinking about for a while. Namely, the similarities and differences in the role of null/nil in static and dynamic languages.
At the surface, a null reference in a statically typed language seems to be a value of a bottom type. Since null is still a value, that cannot be true - since according to the formal definition, a bottom type can have no real value.
Standards are Great, but Standardisation is a Really Bad Idea
Steve Vinoski attended this talk:
Paul Downey's talk on the downsides of standardization was by far the most humorous talk I heard, perfect to close out the track, but it also presented a number of hard-won useful lessons about the perils of standardization efforts.
Systems that never stop
Erlang: A language for programming reliable systems
Sebastien Auvray enjoyed this talk:
He introduced Erlang and why he invented it (for Ericsson Telecom Infrastructures). Relying on quotes from prestigious sources, Joe outlined the six laws Erlang is based on:If you need all this, Erlang should be a good candidate for you. The presentation was one of the best I attended and Joe made it a very pleasant moment.
- Isolation
- Concurrency
- Must Detect Failure
- Fault Identification
- Live Code Upgrade
- Stable Storage
Ola Bini also enjoyed it:
This talk was focused on systems that never stop, and Joe's presentation was based on this, which changed the focus a bit. Sir Tony Hoare was in the audience during this talk, and one amusing moment was when he asked Joe a question about the tradeoff between timeouts and failing fast. Great stuff. This only happens at QCon and JAOO. (As an aside, the evening before I got the chance to sit down and have beers with Steve Vinoski, Joe Armstrong and Rich Hickey. This never happens at other conferences either.)
Improving Running Components at Twitter
Gojko Adzic wrote detailed notes about this presentation, including:
A very interesting observation during the talk was that Twitter started up with a CMS model and that they gradually moved towards a messaging model. I've seen this in a few applications so far, including a casino system, where the messaging model seems to fit best an application intended to power massive community of online users, it seems regardless of what the application actually does business wise. Applications start out completely different, but then more and more functionality gets bolted on top of user messaging capabilities that the whole architecture on the end gets refactored to utilise the messaging channels as the core information transport. With Twitter, I'd expect this to be more obvious from the start as it was intended to help people notify each other.
For every incoming tweet, the messaging system gets notifications for all the folowers, which are then processed asynchronously. One of the most important changes they introduced to improve performance in the last nine months is moving from a Ruby messaging middleware to a custom build JVM-based messaging middleware written in Scala.
Richard Watson also wrote about it:
Twitter's approach to solving their performance and scalability issues is a great example of thinking big while taking small steps. The team set about iterative removal of bottlenecks. Firstly they tackled multi-level caching (do less work), then the message queuing that decouples API requests from the critical request path (spread the work), then the distributed cache (memcached) client (do what you need to do quickly). Evan was asked about strategic work to take them to the next 10x growth. His responded that they were so resource constrained (can you believe there are only 9 in the services engineering team) and so under water with volume that they have to work on stuff that gives them most value (take small steps). But crucially, they create solutions to the bottlenecks making sure that whatever they fix will not appear on the top 3 problem list again (which is thinking big - well, as big as you can when you're growing like a hockey stick).
Vendors
Martin Kneissl was interested by a Microsoft Surface which was present:
I had the pleasure of trying out this giant iPod touch at the Microsoft booth. It's a huge difference seeing this thing on the web and trying it out in reality. I'm quite convinced that this is a technology that could have real value if it becomes affordable.
[...]
If we had a Microsoft Surface and a "tolerant" UML tool, we could try things without the need to manually transfer the result from / into the computer. By "tolerant" I mean a tool that supports incremental development of the model with relaxed model checking to ease "playing" with the model. Basically what I liked in Booch notation: cloudy, incrementally drawable notation that incrementally can be made more precise and formal.
Social Events
Steve Vinoski enjoyed the social events at the conference:
I introduced Rich to Joe Armstrong at the conference party Wednesday evening and they spent the next few hours talking at length about functional programming, their respective languages, VM implementation issues, concurrency issues, etc. Ola jumped in as well. They also continued the conversation the next day. I just sat back, listened, and learned.
Cloud Camp
Guido Schoonheim attended Cloud Camp:
An interesting way to look at these different models is that if you move down the list you get a lot more freedom from concerns. At PaaS you already do not worry about everything connected to your application logic. You have a container interface that is provided and you just do not want to know about the rest. This could help speed up your development a lot. Possibly. Perhaps. The cost associated is that you are very proprietary and tied in to you provider!
This tie in might not seem so bad untill you look at the example of CogHead. This PaaS platform was bought up by SAP recently. However SAP did not buy the clients and did not continue the public service. That means that these people have received a legal notice that they have 3 weeks to move off the platform before service is discontinued. Now, can you rewrite your entire business in 3 weeks? And handle a migration? Probably not!
Where SaaS obviously has a similar problem, the IaaS models seems safe enough. You do everything the way you want, probably creating images with the usual platforms that you can get anywhere, also in non cloud environments. The most risk here is your data. There are a number of examples of people with a client base that now have so much data going into Amazon S3 that there is no way to get it out again in a reasonable timeframe. And then there is the safety of data and regulations which is creating the discussion about public and private clouds (shared usage or just for your company) and hybrid models between your infra and the cloud.
As did Tim Anderson:
I've just attended my first cloudcamp unconference, held during QCon London. We ended up debating how you would explain cloud computing to a non-technical audience. The problem is that different people mean different things by the term. [...] I suppose it is appropriate that the cloud term is fluffy. To some it is synonymous with the Internet; to others it means SAAS applications; to others it means virtual servers running who knows what; to others it means a hosted application platform (platform-as-a-service or PAAS).
The problem with vague terms is that they make discussion difficult.
My favourite usage: cloud computing means exporting IT infrastructure to the Internet.
Opinions about QCon itself
Many people expressed opinions about the conference as a whole, including Sebastien Auvray:
To make it short, it was a great moment of thoughts and convivial discussions. It is by far the best conference and IT event I attended so far for different reasons:
- It covers an extremely broad spectrum of the IT World. With 5 main tracks at the same time during the whole days, the content is well diversified: Languages (functional, mainstream, ...), Architecture, SOA, Agile, Performances, Finance and a newly very original track about Historically bad ideas.
- The panel of speaker is incredible: Sir Tony Hoare (Quicksort inventor and much more), Martin Fowler, Joe Armstrong (father of Erlang), Rich Hickey (Clojure inventor), Ola Bini (JRuby developer and more), Rod Johnson (Spring Inventor), Dan North, Eric Evans (Mister DDD), and many more... Now you have an idea of the amount of experience and research accumulated by such a group of people.
- It is not polluted all around with commercial presentation with stuff to sell.
QCon is always very, very good, but QCon London 2009 last week was the best one yet.
[...]
If you have any interest at all in leading edge software and computing topics being presented by the world's most knowledgeable speakers in a fun atmosphere, go to QCon. I guarantee you won't be disappointed.
QCon London 2009 took place last week at the Queen Elisabeth II conference centre, reconfirming QCon's place as the undisputed champion of IT conferences in the UK. With a really fantastic line-up of speakers and very strong technical content at the bleeding edge of software development today, the conference managed to attract quite a large audience. I don't know the official figures but my impression was that 400-500 people were constantly there, which is a real achievement especially since very few companies have money to spend this year on conferences.
This week I was privileged enough to attend QCon London and now I'm finding myself in the unfortunate position of attempting to representatively summarise the vast enormity of wonderfully exciting moments that constituted the event. Essentially the conference as a whole is a superlative occasion chock full of super interesting people, conversations and experiences.
The conference attracts Software experts from all walks - language designers (such as Joe Armstrong, Ola Bini and Rich Hickey), agile coaches (such as Linda Rising and Gabrielle Benefield), SOA experts (such as Jim Webber, Ian Robinson and Stefan Tilkov) and just a ton of really interesting people and subjects. One of the great aspects of the conference is that it is divided into tracks, each lasting a day and each having a curator who selects and organises the speakers for that track. I think that this is a really great way of organising things and provides a much more consistent feel to the event as a whole.
All in all, QCon London this year was amazing. I find it interesting that from the first time I attended QCon I thought they were exceptionally good. And every time they keep getting better. Of course, it is fantastic to be able to meet all these great people at the conference, and you get lots of chances to hang out with them, ask questions and have discussions. But if you take a look at the presentations offered, they all feel very fresh and the quality is consistently of a very high level.
All in all, QCon 2009 was probably the best conference I've ever visited. I've learned tons of really useful stuff. Not only from a technological point of view, but from a social point of view is well. It is delightful to hear how other people are solving or have solved the same problems as I am. I really hope to visit QCon 2009 next year as well!
I'm back at my cash money day gig after spending yesterday at qCon London, where I gave a presentation on RESTful approaches to financial data integration. Before I went, I have to say that I was a little down on the conference thing in general, having attended (and spoken at) way too many that were either just Vendor Drivel ("Got a problem? Buy my solution!") [1], or Preaching To The Converted ("Technology/Methodology X is great! Aren't we all so clever for noticing it?"). qCon has largely restored my faith that it's possible to put together an excellent technical conference that's relevant for the way we communicate about technical subjects today.
Looking back, I'm very much impressed by these three days of QCon London 2009. Biggest plus of the conference was its small scale. With just about 400 visitors, you're likely to run into speakers during breaks, so it's easy enough to talk to some of them informally. Likewise, sessions are smaller scaled, the conference rooms are smaller, you're quite close to the speakers. But more importantly: these speakers all proved to be excellent. Subjects that were covered weren't limited to Java, or to some vendor, but seemed to come directly from day-to-day experiences of professional architects and developers. That made them recognizable and means you can learn from them. And I've even had to miss many more interesting - parallel - sessions. My conclusion on the whole: I'm looking forward to next year's QCon!
I didn't get to see as much at QCon as I'd like to have done, although I dare say most people will say that, even if they went to as many sessions as was physically possible. But what I did see was fascinating and thought-provoking, even when it came from people I work with every day.
QCon is special because of its focus on solutions and practices without the usual vendor gravity. Sure, there is some hype lurking in the rafters. But the presenters are genuine problem solvers and conversations are intense, productive, and technical. The conference studies emerging topics in software development that people actually exploit. Those with traction, like functional programming, REST, and agile development gain industry velocity and become a bigger part of following conferences.
It's been a really enjoyable conference so far and everyone I've talked to has been really friendly, plus it's been great to meet and chat to a few of the people in the industry I really respect (I'm resisting the urge to do some name dropping). It's got quite a different feel to a Tech.Ed conferencce. Not better or worse, just different. Firstly the numbers are smaller so it feels more intimate, and there are people from the Java, Ruby and even Erlang communities here so there's a much broader view of some of the topics, plus there are no IT Pro's here - it's all just developers.
And InfoQ co-founder Alexandru Popescu:
I know I may be accused of being subjective (as I am one of the InfoQ co-founders which is the co-organizer of the event), but people that know me and those that have participated at least once at QCon will know that what I'm going to write stands true.
[...]
You might wonder why I do think that QCon is better than other events to connect with people. The reason is that most of the people participating at QCon (speakers included) are spending their time at the conference (as opposed to just flying in, delivering the presentation and leaving), correlated with the fact that the conference is not , plus the venue, plus the parties will offer you enough time to get to these guys. All you need to do is just come and have the guts to walk to whoever you want to meet and say Hi!
Takeaways
In addition to talking about the conference itself, several people wrote about things that happened as a result of discussions or presentations at QCon, including Sebastien Auvray:
[...]
- It's funny to see the success of retro-engineering and empiric architectures or languages: REST, Erlang. Compared to Sun's first-specify-then-implement approach.
- QCon is a tasty moment for a computer science enthusiast like me but well it's so frustrating to see the IT enterprise reality: java, java and java and the rest only for the Happy Few... And in big structures even when you would be pushing to adopt more suited solutions discovered at QCon (or wherever: blogs, ...), there will always be a higher ranked guy who is reluctant to changes and everything it implies.
So well, as soon as the videos are out on InfoQ, you must absolutely have a look at the following presentations:And interviews:
- Opening Keynote: The Science of Computing and the Engineering of Software by Sir Tony Hoare,
- Null References: The Billion Dollar Mistake by Sir Tony Hoare,
- Erlang: A language for programming reliable systems by Joe Armstrong,
- Persistent Data Structures and Managed References by Rich Hickey.
- REST for SOA: Using the Web for Integration with Ian Robinson & Jim Webber.
- Stories are important, teams need a 'Shaman' who is capable of explaining why specific choices where made in the past
- Wise architects only need to have one answer to be capable of anwering any question: it depends...
- Architects and developers tend to try to solve problems in far to generic ways. Generic systems don't tend to deliver the best end-user experience.
- 300 messages a second on twitter doesn't sound like a lot. They are however send to a lot of followers!
- On the question of why twitter decided to built their own messaging queue instead of using an existing one (ie. JMS) they answered: well, our current solution is about 1200 lines of scala and perfeclty fits are needs. No other product could offer us that.
[...] There's still value in qCon for those who don't attend. Slides are online immediately; people blog about it during and after; interviews are performed and posted to web sites; presentations are filmed and trickled out over the course of the year; interesting points from most talks are tweeted out. You can still benefit from qCon even if you don't attend, but if you do, you're just a greater part of it, as you're at the core. And that's precisely how qCon to me seemed extremely relevant in the internet communication era.
I was here last year, and my observation is that last year there was considerable angst about the idea that the SOAP stack was failing to deliver and that new stacks based on REST were the thing to do. This year this same statement feels more widely accepted and people are moving on, based on that assumption.
Overall, Scala played a somewhat strange role during the conference. It was mostly in the air. Nobody was explicitly fanatical about Scala; even the speakers doing the Scala talks were most enthusiastically watching Hickey's Clojure sessions. And of course, in Hickey's view, Scala must be evil, as it's still object oriented (besides the functional elements it does contain). On the other hand, more and more people I talk to are convinced that Scala would be the best sequel to Java; and less and less people think the more complex and extensive possibilities of the language will be too high a barrier.
In conclusion, I enjoyed all the sessions and heard some interesting things. But the biggest lesson I'll take away is to go to talks about things I don't know about, not things I do. I'm sure I'd have learnt a lot more new ideas in Rich Hickey's Clojure presentation than in Michael and Steve's TDD history. Not through any fault of Michael and Steve (and I certainly don't want to pick on them), but because I've read a lot of that stuff before. There were also a number of talks on web architecture and RESTful services that I'd like to have caught. I also wish I'd taken notes in more of the sessions; as well as helping me take more of the information on board it would have helped me writing this post!
And Mark Needham:
One of the big takeaways for me from the Domain Driven Design track at the recent QCon London conference was that the organisational patterns in the second half of the book are probably more important than the actual patterns themselves.
Conclusion
QCon London was a great success and we are very proud to have been able to offer such a conference. It will continue to be an annual event in both London and San Francisco, with the next QCon being around the same time next year in each location. This year also marks the first year that we are bringing QCon into other regions which InfoQ serves, namely China and Japan. Thanks everyone for coming and we'll see you next year!!!!