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. From the first tutorials to the last sessions, people discussed many aspects of QCon in their blogs. You can also see numerous attendee-taken photos of QCon on Flickr.
This QCon was InfoQ's ninth conference and the fourth annual in London. The event was produced in partnership with Trifork, the company who produces the JAOO conference in Denmark. This QCon was the largest ever at over 700 registered attendees, with 56% attending from the UK, over 30% attending from continental Europe and the rest from around the world. Over 100 speakers presented at QCon London including Dan Ingalls, Ralph Johnson, Robert C. Martin ("Uncle Bob"), Martin Fowler and Rod Johnson. QCon will continue to run in the UK around March of every year, QCon San Francisco will be running again in November 2010, and QCon Beijing as well as QCon Tokyo will be running at the end of April. Our first ever QCon São Paulo is also planned for September of this year.
Table of Contents
- DCI/Lean architecture by Jim O. Coplien
- Enterprise Development with NServiceBus by Udi Dahan
- Practical Erlang Programming by Francesco Cesarini
- Resource-Oriented Architectures: Information First by Brian Sletten
- REST in Practice - A Tutorial on Web-based Distributed Systems by Ian Robinson & Jim Webber
- Software Architecture for Developers by Simon Brown & Kevin Seal
- Bad Code, Craftsmanship, Engineering, and Certification by Robert C. Martin
- Forty Years of Fun with Computers by Dan Ingalls
- Living and working with aging software by Ralph Johnson
- Folding Design into an Agile Process by Eric Evans
- Kanban - Crossing the line, pushing the limit or rediscovering the agile vision? By Jesper Boeg
- Beautiful teams and leaders by Roy Osherove
- Scaling Applications: Complexity, Performance, Maintainability by Oren Eini
- The State of the Art .NET - 12 months of things to learn by Josh Graham & Amanda Laucher
Architectures You've Always Wondered About
- Building Skype. Learnings from almost five years as a Skype Architect by Andres Kütt
- Facebook: Architecture and Design by Aditya Agarwal
- Data Presentation in a Web App: The Journey of a Startup by Simon Oxley
- Introduction to Bespin - Mozilla's Web Based Code Editor by Joe Walker
- Now What? by Dylan Schiemann
- The Present and Future of Web App Design by Torrey Rice
- Event-driven architecture by Stefan Norberg
- Extreme Java Productivity with Spring Roo and Spring 3.0 by Rod Johnson
- Modeling Concurrency with Actors in Java - Lessons learned from Erjang by Kresten Krab Thorup
- Devs are from Mars, SETs are too by Simon Stewart
- From Dev to Production: Better Living through Build Pipelines and Teamwork by Sam Newman
- Siloes are for farmers: production deployments using all your team by Julian Simpson
- Demystifying monads by Amanda Laucher
- Functional Approaches To Parallelism and Concurrency by Don Syme
- Functional Programming Patterns by Aino Vonge Corry
- The Joy of Testing by John Hughes
- Cogs in the machine: testing code embedded in an impenetrable framework by Roy Osherove
- Performance Testing at the Edge by Alois Reitbauer
- Test-Driven Development of Asynchronous Systems by Nat Pryce
- The Mobile Testing Challenge: Why Mobile Apps Need Real-World Testing Coverage and How Crowdsourcing Can Help by Doron Reuveni
Irresponsible Architectures and Unusual Architects
- Command-Query Responsibility Segregation by Udi Dahan
- LMAX - How to do over 100K contended complex business transactions per second at less than 1ms latency by Dave Farley & Martin Thompson
- Simplicity - the way of the unusual architect by Dan North
- The Counterintuitive Web by Ian Robinson
IT - more than tools and technology
Non-Relational DBs & Web Oriented Data
- Auntie on the Couch by Enda Farrell
- MongoDB: huMONGOus Data at SourceForge by Mark Ramm
- Not Only SQL: Alternative Data Persistence and Neo4J by Emil Eifrém
- Project Voldemort at Gilt Groupe: When Failure isn't An Option by Geir Magnusson
- Social networks and the Richness of Data: Getting distributed webservices done with Nosql by Lars George &Fabrizio Schmidt
- Development Model for the Cloud: Paradigm Shift or the Same Old Same Old? By Ümit Yalcinalp
- Situation Normal, Everything Must Change by Simon Wardley
- The Cloud Silver Bullet: Which calibre is right for me? By Chris Read
- Beyond Masters & Apprentices: A Scalable, Peer-led Model For Building Good Habits In Large & Diverse Development Teams by Jason Gorman
- Danger: Software Craftsmen at Work by David Harvey
- Sharpening the Tools by Dan North
- Software Craftsmanship, Beyond The Hype by Corey Haines
- Embracing Concurrency At Scale by Justin Sheehy
- Message Passing Concurrency in Erlang. An architectural basis for scalable fault-tolerant systems by Joe Armstrong
Social Events
Opinions about QCon
Takeaways
Conclusion
Tutorials
DCI/Lean architecture by Jim O. Coplien
Twitter feedback on this session included:
mouneer: Rediscovering OO programming AKA DCI data context interaction #qcontutorial Jim Coplien
alblue: "Architecture is the essence of structure: form. Structure obfuscates form." - Jim Coplien at #qcon
Enterprise Development with NServiceBus by Udi Dahan
Twitter feedback on this session included:
sumek: NServiceBus has a lot of sensible configuration decisions bult-in upfront. Good stuff!
martinnjensen: thoroughly enjoying the all day NHibernate session with @udidahanat #qcon
marcjohnson: Really like @UdiDahan description of NServiceBus as set of really sharp, specific tools - should feel good when used appropriately
Practical Erlang Programming by Francesco Cesarini
Twitter feedback on this session included:
alexmarie84: enjoyed the Erlang intro tutorial with @FrancescoC and looking forward to digging further into Erlang and OTP tomorrow!
Resource-Oriented Architectures: Information First by Brian Sletten
Glen Ford also attended this tutorial:
On day 2 I attended the Resource Oriented Architecture tutorial run by Brian Sletten. Before going in I wondered if I'd made a mistake selecting two REST tutorials - but it turned out to be a great choice, it was complementary to the day before.
One of the most memorable parts of the tutorial was the 'musical interlude' where Brian did a brilliant job of explaining derivative works, and how public data opens up a world of possibilities.
Twitter feedback on this session included:
rferraz: second day at #qcon starting. another rest lecture, with a different spin. good stuff again.
der_miggel: Attending http://bit.ly/c9qrqk (expand) by @bsletten today at #QCon - very interesting so far, lots of interesting concepts
REST in Practice - A Tutorial on Web-based Distributed Systems by Ian Robinson & Jim Webber
Glen Ford attended this tutorial on day one:
The tutorial is based around their forthcoming book with Savas Parastatidis which now is in rough cuts.
The tutorial covered a lot of ground, and was well presented. By using Hypermedia you can create very rich services and this tutorial provided a great insight on how and why you should do just that. It provided a good overview of what REST really is using the Leonard Richardson maturity model, and how most services that tout being RESTful are not actually fully RESTful (though they may indeed still be of value).
Twitter feedback on this session included:
doxla: @nfma Which talk will you be at Monday morning? #RESTInPractice was good today. Looking forward to the rest of #qcon
alexip: @jimwebber Thanks a lot for your tutorial on Rest. Opened up many possibilities. I now fully embrace the Restful way !
Software Architecture for Developers by Simon Brown & Kevin Seal
Twitter feedback on this session included:
tolukemi: sw arch for devs tutorial @#qcon was insightful, provided a lot of food for thought. hopefully will get a chance to put ideas to practice.
Keynotes
Pinar Yanardag found the keynotes inspiring:
Keynotes from Dan Ingalls (Forty Years of Fun with Computers), Ralph Johnson (Living and working with aging software) and Robert Martin, aka Uncle Bob (Bad Code, Craftsmanship, Engineering, and Certification) were inspiring.
Bad Code, Craftsmanship, Engineering, and Certification by Robert C. Martin
Joakim Holm wrote about the speaker:
To watch an Uncle Bob speech from the 2nd row of a big auditorium is a bit like being run over by a train. 700+ people there and Bob would probably not need the microphone. He is certainly a convincing speaker.
His conclusion on the talk was:
Remember, one certain attribute of a craftsman is that they never write bad code. Even under stress. If you have trouble remembering, order a green wrist band from the Clean Code Project. The only thing they ask is that you make a charity contribution.
Tim Anderson summarized the key points:
One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.
[…]
Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:
- Keep functions and methods short. How short? His principle is to use extract method refactoring until there is nothing more to extract. I got the feeling that he would consider anything over 20 lines suspect.
- Have functions with only a few arguments - preferably no more than two - and don't use boolean arguments because they cause confusion.
- Similarly, a class should be a small batch of code, with only a few variables, a couple of dozen methods.
- Eliminate duplication in your code; use abstraction.
- Give public methods short names, but use long descriptive names for private methods. The code is the documentation.
- Improve code slightly every time you touch it. Sometimes the opposite happens; code decays as fixes get added. If you improve it instead, your project improves over time.
- You need comprehensive tests, otherwise you do not dare to make changes in case something breaks. Test code should be of the same quality as production code; if your tests are slow and buggy, you will not use them or trust them.
- Have short iterations. A month may be too long. Two weeks is good. One week, he suggests, may be ideal; or even less in some cases.
Pinar Yanardag summarized this talk:
- Follow the Boy Scout rule: Always leave things a little better than you find.
- Methods should be less than 20 lines.
- Don’t have a function that takes a boolean. It is clear that it does two things; one if its false, another if its true.
- Cut/Paste is bug replication
- Extract until you drop! Keep extracting until all functions only do one thing
- Source code represent the design -not the UML tools.
Forty Years of Fun with Computers by Dan Ingalls
Joakim Holm on Ingalls’ keynote:
Dan showed us, and executed, his very first programs, written in Fortran, to spontaneous applause. He described and illustrated the path he had chosen for his career, working with luminaries like Alan Kay at Xerox PARC. He describe the development of Smalltalk, on to Squeak (a Smalltalk implementation written in itself!), and today’s work on the Lively Kernel. This last thing is something so curiously wonderful as an interactive programming environment inside a standard web browser.
What struck me during Dan’s talk was that he always seemed to go where he thought he would have the most fun. That is a quite uncommon attitude in the often very serious world of software today. But it is not unreasonable to think that this attitude is actually a recipe for success. If you love your work, you are probably going to do an excellent job at it.
Pinar Yanardag considered Ingalls keynote entertaining:
Dan Ingalls keynote was very entertaining. He showed his early codes and he made all the demonstration in Squeak and also shared demonstrations of lively kernel. One wise quote from Ingalls talk:
We’re bad at learning the lessons from the past because:
- we don’t have enough storytellers and
- our generation doesn’t listen very well.
Twitter feedback on this session included:
patkua: Wise words from @daningalls, "If things can be computed, they should be computed continuously" early demo of desktop publishing @ #qcon
erik_van_oosten: Investigating Squeak at #qcon, inspired by Dan Ingalls amazing presentation completely from within Squeak
Living and working with aging software by Ralph Johnson
Twitter feedback on this session included:
alblue: "Tools are important; but design expertise is more important" - Ralph Johnson at #qcon
georgemcintosh: RT @marknijhof: It is a bad sign when management starts talking about refactoring, this means you haven't been doing it properly, Ralph Johnson (GOV) #QCon
kiltec: RT @tastapod: Ralph Johnson #QCon keynote: in the future most people will be working on code that's older than they are
jlindstorff: RT @jcoplien: Patterns like those in the GOF book are what you get when you stay in university too long [paraphrased] - Ralph Johnson #qcon
2015 Software Development
The DCI Architecture: Lean and Agile at the Code Level by Jim O. Coplien
Twitter feedback on this session included:
alblue: "Java is a toy scripting language; you cannot program object-oriented code in Java" - Jim Coplien at #qcon
Agile Evolution
Kevin Seal approved the new more pragmatic view towards Agile:
The Agile movement also came under some scrutiny in the Agile Evolution track. There was (finally!) a pragmatic view of it presented as an industry that has seemingly sprung up off the back of some well-intentioned recommendations. In a somewhat ironic retrospective, we see how Agile has caused us to throw away things that we have since come to reinvent, while clinging to rituals regardless of their real value; “we have ADHD, retrograde amnesia and OCD,” says Keith Braithwaite. Rachel Davies, author of “Agile Coaching”, referred to "w-agile": mini-waterfall with daily stand-ups, the point at which many attempts at agile adoption stall. However, it was refreshing to see this recognized as being a good start and perhaps as a reminder that it’s not a particular process that’s the goal, but continuous improvement.
Folding Design into an Agile Process by Eric Evans
Matt Zimmerman made comprehensive notes on this session, including:
Eric tackled the question of how to approach the problem of design within the agile framework. […]
He emphasized the importance of modeling “when the critical complexity of the project is in understanding and communicating about the domain”. The “expected” approach to modeling is to incorporate an up-front analysis phase, but Eric argues that this is misguided. Because “models are distilled knowledge”, and teams are relatively ignorant at the start of a project, modeling in this way captures that ignorance and makes it persist.
Instead, he says, we should employ to a “pull” approach (in the Lean sense), and decide to work on modeling when:
- communications with stakeholders deteriorates
- when solutions are more complex than the problems
- when velocity slows (because completed work becomes a burden)
[…]
This was a very compelling talk, whose concepts were clearly applicable beyond the specific problem domain of agile development.
Joakim Holm noted about this talk:
Eric talked about how he deliberately had kept process stuff out of the DDD book. This, however, meant that some people actually had thought that he advocated a BDUF style of design. Nothing could be further from the truth. Eric explained how he thought about the process of finding driving user stories, exploring different designs, and evaluating the designs using simple story tests.
Kanban - Crossing the line, pushing the limit or rediscovering the agile vision? By Jesper Boeg
Matt Zimmerman noted on this one:
Jesper shared experiences and lessons learned with Kanban, and some of the problems it addresses which are present in other methodologies. His material was well balanced and insightful, and I’d like to go back and watch the full video when it becomes available.
Here again was a clear and pragmatic focus on matching tools and processes to the specific needs of the team, business and situation.
AlphaGeeks on .NET
Beautiful teams and leaders by Roy Osherove
Adrian Hills chose the .NET track, this session being one of the best in his opinion:
The most entertaining talk of the whole conference has to go to Roy Osherove (twitter). A cracking talk on "Beautiful teams and leaders" was topped off with a sublime solo guitar song performance. Brilliant.
Scaling Applications: Complexity, Performance, Maintainability by Oren Eini
Adrian Hills participated to this .NET session too:
Ayende Rahien (Oren Eini) […] talked about how to scale an application by a "divide and conquer" approach. What I particularly liked about his session, was that he worked through a real-world example and gave some live metrics on performance improvements. The talk was one of a number to mention the CAP theorem, whereby a distributed can only satisfy 2 out of 3 of the following, but not all 3:
- Consistency
- Availability
- Partition tolerance
Hugo Rodger-Brown commented on this talk:
Good presentation from Ayende – including some code demos, which always goes down well with the crowd. Main point is the same as everyone else’s – scale out is only possible if you split systems into functional components and attack each individually – e.g. user login has different requirements from user registration, so don’t stick it all in a single table in an RDBMS. Use a service bus for async communication, data is always dirty, etc., etc. Ended with a slightly unnecessary demo of his new (json) doc database - .net replica of CouchDB, with some Mongo features (around querying). Looks great, well worth a look, although it’s clearly in the alpha stages.
The State of the Art .NET - 12 months of things to learn by Josh Graham & Amanda Laucher
Tim Anderson noted the tools, languages and technologies Graham and Laucher suggest to be learned:
- F# (again)
- M – modelling/DSL language
- Boo – static Python for .NET
- NUnit – unit testing. Little regard for Microsoft’s test framework in Team System, which is seen as a wasted and inferior effort.
- RhinoMocks – mocking library
- Moq – another mocking library
- NHibernate – object-relational mapping
- Windsor – dependency injection, part of Castle project. Controversial; some attendees thought it too complex.
- NVelocity – .NET template engine
- Guerrilla SOA – see above
- Azure – Microsoft’s cloud platform – surprisingly good thanks to David Cutler’s involvement, we were told
- MEF – Managed Extensibility Framework as found in Visual Studio 2010, won high praise from those who have tried it
Adrian Hills completed his list of “things to learn”:
The day ended with a talk by Josh Graham and Amanda Laucher on "12 months of things to learn" in .NET. I found my TODO list rapidly growing. F#, M, Guerilla SOA, MEF....... Another really good talk, with some good banter.
Architectures You've Always Wondered About
Doug Winter on the entire track:
What that means in 2010 is scale, scale, scale – how do you service a bazillion people. In summary, nobody really has a clue. There were presentations from Facebook, Skype, BBC, Sky and others on how they’ve scaled out, as well as presentations on various architectural patterns that lend themselves to scale.
Everyone has done it differently using solutions tailored to their specific problem-space, pretty much all using Open Source technology but generally building something in-house to help them manage scale. This is unfortunate – it would be lovely to have a silver bullet for the scale problem.
Building Skype. Learnings from almost five years as a Skype Architect by Andres Kütt
Tim Anderson summarized the presentation:
Over on the Architecture track, Andres Kütt spoke on Five Years as a Skype Architect. His main theme: most of a software architect’s job is communication, not poring over diagrams and devising code structures. This is a consistent theme at QCon and in the Agile movement; get the communication right and all else follows. I was also interested in the technical side though. Skype started with SOAP but switched to a REST model for web services. Kütt also told us about the languages Skype uses: PHP for the web site, C or C++ for heavy lifting and peer-to-peer networking; Delphi for the Windows interface; PostgreSQL for the database.
Some of Matt Zimmerman’s notes on this session are:
His [Andres Kutt’s] first lesson was that technical rules of thumb can lead us astray. It is always tempting to use patterns that have worked for us previously, in a different project, team or company, but they may not be right for another context. They can and should be used as a starting point for discussion, but not presumed to be the solution. […]
Second, he emphasized the importance of paying attention to functional architecture, not only technical architecture. […]
Keep it simple: minimize functionality, and minimize complexity. He gave an example of how their queuing system’s performance and scalability were greatly enhanced by removing functionality (the guarantee to deliver messages exactly once), which enabled the simplification of the system.
Pinar Yanardag wrote down some of the points Kutt made:
- Rules of thumb does not apply: It is always tempting to use patterns that have worked previously but they should be used as a starting point for discussion – not as a solution.
- Functional architecture is important. You neglect how the functionality of your system is organized at your own peril.
- Simply things work. The simplier things are the more intelligent they are.
- Buzz words are dangerous: They are both dangerous as carriers of meaningless chance but also as a catalyst for breaking down relationships.
- Architecture needs to fit your organization. There’s no such thing as a beautiful system design. The design either fits what your organization needs or it doesn’t.
Facebook: Architecture and Design by Aditya Agarwal
Pinar Yanardag remarked on this session among others:
- Services of philosophy: choose the tool for the right task. They use Thrift, a lightweight software framework for cross-language development (C++, PHP, Python, Ruby, Erlang, Haskell, etc.)
- Most important thing in their engineering team: How quickly can you move? […]
- Don’t ever store non-static data in a central database
- Data driven schemas make for happy programmers and difficult operations.
- Logical migration of data is very difficult. Create a large number of logical databases, load balance them over varying number of physical nodes. […]
They have a love-hate relationship with memcache; it is easy to corrupt and has a limited data model. But it is simply crucial and it does what it does, really good.
Hugo Rodger-Brown liked this presentation:
Great presentation, mixture of jaw-dropping stats (8bn minutes spent every day on Facebook worldwide) and insight into how Facebook works. Key point seems to be hiring good engineers and empowering them. Key technologies (HipHop, Haystack etc.) were developed by very small teams (<5), and there are no dedicated product owners - mixture of top-down strategic goals and bottom-up innovation. Want to work there.
Browser as a Platform
Data Presentation in a Web App: The Journey of a Startup by Simon Oxley
Twitter feedback on this session included:
DrNBruce: Enjoyed presentation by @soxley at #QCon, @awaremonitoring using the fundamental tools of the browser to deliver a feature rich WebApp
Introduction to Bespin - Mozilla's Web Based Code Editor by Joe Walker
Hugo Rodger-Brown attended this session and noted:
Very low-key presentation that went through some of the deficiencies of the current command line environment, and a demonstration of how much better it could have been (and will be with Bespin). Another really elegant example of how much difference very small changes make, and the value of attention to detail. +1 for the demo.
Now What? by Dylan Schiemann
Matt Zimmerman took detailed notes on this session, including:
Dylan did a great job of extrapolating a future for web development based on the trend of the past 15 years. He began with a review of the origin of web technologies, which were focused on presentation and layout concerns, then on to JavaScript, CSS and DHTML. At this point, there was clear potential for rich applications […]
Things got better as more browsers came on the scene, with better implementations of CSS, DOM, XML, DHTML and so on. However, we’re still supporting an ancient implementation in IE. […]
Next, there was an explosion of innovation around Ajax and related toolkits, faster javascript implementations, infrastructure as a service, and rich web applications like GMail, Google Maps, Facebook, etc.
Dylan believes that web applications are what users and developers really want, and that desktop and mobile applications will fall by the wayside. […]
Dylan summarized the key platform considerations for developers:
- choice and control
- taste (e.g. language preferences, what makes them most productive)
- performance and scalability
- security
and surmised that the best way to deliver these is through open web technologies, such as HTML 5, which now offers rich media functionality including audio, video, vector graphics and animations. He closed with a few flashy demos of HTML 5 applications showing what could be done.
The Present and Future of Web App Design by Torrey Rice
Hugo Rodger-Brown commented on this talk:
Really enjoyable romp through the past, present and future of user interfaces. No breakthrough items, but a great presentation with no angle. Mobile (in all its forms) is the run-away winner, along with all the goodies that things like 3-D, GPS and AR will bring. Minority Report, here we come.
Twitter feedback on this session included:
corinthino: been to #qcon today. Highlight = Torrey Rice of @sitepen on 'The Present and Future of Web App Design'. Excellent on user ownership of data
Cool Stuff with Java
Event-driven architecture by Stefan Norberg
Joakim Holm noted about this talk:
Another Swedish contribution to the conference was Stefan Norberg, enterprise architect at Unibet, a Swedish gaming company. He explained, very nicely, how you can use a domain EDA instead of simply reproducing the spaghetti architecture in an ESB. A domain EDA is an architecture where sub-systems or SOA services are loosely coupled using only asynchronous domain events and an event bus. Services produce and consume domain events on the bus and the event specification becomes the contract between producers and consumers. A very positive outcomes of this is the freedom that comes from loose coupling. For example, to add a new service, no changes are needed to the existing structure. On the downside, all events must be considered public APIs. For example, removing a field is difficult, bordering on practically impossible.
Twitter feedback on this session included:
jockeholm: #qcon S Norberg: In synchronous systems, _peak_ throughput is determined by weakest link. In asynch, it's _sustained_ throughput
Extreme Java Productivity with Spring Roo and Spring 3.0 by Rod Johnson
Spring Roo is a Rails-inspired code generation tool from SpringSource. Mainly, it is a way to generate an application, tests and its ”plumbing” from a domain model. The generated code is heavy on aspects, but it’s all Java and you can edit stuff you don’t want Roo to manage and it will leave it alone. It is a round-trip generation model, where Roo will keep its internal model in sync with what you write. Generating from the model is done using the Roo shell with great context-sensitive assistance. I did find the commands pretty long, though. Since SpringSource now has control over Grails as well, they have some decent Rails-inspired tools for Java web development now.
Modeling Concurrency with Actors in Java - Lessons learned from Erjang by Kresten Krab Thorup
David Arno wrote on this session:
Kresten used the term “Actor Orientated” (AO?) programming to describe what the future might look like. In the 90s, Java dramatically transformed the lives of C programmers by offering built-in solutions to error handling and memory management. This made Java code far simpler than the equivalent C code. Now, in the 10s, Erlang’s actor model could similarly transform development practices by offering a simple way of implementing concurrent solutions. However, Erlang is not the only language to offer actors, Scala for example does so too. Kresten pointed out though that there were flaws in the Scala actor model, as it let you violate actor state encapsulation for example.
The talk was nicely wrapped up with a call to the community to develop the idea of “AO” and to develop AO-centric patterns to help push the idea along. All in all, a really good talk.
Twitter feedback on this session included:
jtdavies: #QCon: Erlang on the JVM (Erjang) is very cool, not sure I can think of a use yet but it's still cool, I wonder if #RabbitMQ works on it?
szegedi: Kresten's (@drkrab) talk on Erjang at #qcon is really great - I'm biased as I'm a JVM language junkie, but it's a real geekfest so far.
FrancescoC: Looking at @drkrab run Erlang programms on the JVM. "If you think you need threads and locks, think again" #qcon
Dev and Ops: A single team
Kevin Seal noted the following regarding the entire track:
The craftsmanship track was also complemented by the development and operations track. This presented a view of development, deployment and production support disciplines as a partnership, ideally wherein they were part of the same process. […]
The DevOps movement attempts to make it easier for development and operations teams to work closely together. For anyone who has worked in this industry this will be familiar issue – development and ops have different definitions of success, and different expectations from their customers. When these come into conflict, everyone gets hurt.
Devs are from Mars, SETs are too by Simon Stewart
Kevin Seal added on this particular session:
There was a great presentation from Simon Stewart of webdriver fame about his role as a System Engineer in Test at Google, where they have around one SET to 7 or 8 developers to help productionise the software, provide a proper test plan and generally improve the productivity and quality of code by applying ops and automated testing principles to development.
From Dev to Production: Better Living through Build Pipelines and Teamwork by Sam Newman
Hugo Rodger-Brown remarked on this presentation:
Good presentation, well presented, but no great insights; basically be nice to the ops team. One nice point though – try to build once and deploy the same binaries to each environment – do not run separate environment builds, but use external configuration only to differentiate between deployments.
Siloes are for farmers: production deployments using all your team by Julian Simpson
Matt Zimmerman took detailed notes on this session, including:
He began with the people issues, reminding us of Weinberg’s second law, which is “no matter what they tell you, it’s always a people problem”.
His people tips:
- In keeping with a recent trend, he criticized email as a severely flawed communication medium, best avoided.
- respect everyone
- have lunch with people on the other side of the wall
- discuss your problems with other groups (don’t just ask for a specific solution)
- invite everyone to stand-ups and retrospectives
- co-locate the sysadmins and developers (thomas allen)
Next, a few process suggestions:
- Avoid code ownership generally (or rather, promote joint/collective ownership)
- Pair developers with sysadmins
- It’s done when the code is in production (I would rephrase as: it’s not done until the code is in production)
Functional Programming
Doug Winter also commented on the entire Functional Programming track:
From the academics there is a strong consensus that functional languages are the way forward, with loads of people championing Erlang. I’m a big fan of Erlang myself, and we’ve got a few Erlang coders here at Isotoma.
There was also some interesting stuff on other functional approaches to concurrency, in Haskell specifically and in general. One of the great benefits of functional languages is their ability to defer execution through lazy evaluation, which showed some remarkable performance benefits compared with more traditional data synchronisation approaches.
Demystifying monads by Amanda Laucher
David Arno wrote on what he understood monads are:
In essence, a monad is an abstract type (at the risk of indulging FP heresy, think “object”) that encapsulates two values: some set of data and a function. The monad then can apply that function to the set of data and generate a new set of data in the process. There’s various rules around the behavior of monads, but that is in essence all there is to them.
The power of monads comes into play with languages like Haskell. Because the monad provides a facade that extrapolates away functionality from the main language, it can do all sorts of things that would otherwise break the pureness of the language. So IO, error and exception handling etc are all handled by nomads.
I will put a big caveat here though: I may have simply misunderstood everything about monads
Twitter feedback on this session included:
alblue: "If you used a Thread monad inside a State monad, you could get yourself into a lot of trouble" - Monads Demystified at #qcon
Functional Approaches To Parallelism and Concurrency by Don Syme
Tim Anderson was convinced that every .NET developer should pay attention to F#:
Don Syme, Principal Researcher at Microsoft Research and co-inventor of F#, gave a lively presentation on functional approaches to parallelism and concurrency. He shows screen after screen of equivalent F# and C# code, illustrating how F# is more concise and expressive, as well as being better suited to concurrent development. […]
I asked Syme what sort of problems are not well suited to F#. In his reply he described the state of play in Visual Studio 2010, where you can easily create F# libraries but there is no designer support for user interface code, such as Windows Forms or Windows Presentation Foundation. That is merely a tooling issue though.
Syme’s point is that functional programming, and F# in particular, is ideal for today’s programming challenges, including concurrency and asynchronous code.
If nothing else, he convinced me that every .NET programmer should at least be looking at F# and learning what it can do.
Functional Programming Patterns by Aino Vonge Corry
David Arno wrote on this talk:
She covered that fact that the 23 GoF patterns are a product of the Java language and how other languages remove the need for user-implementations of these patterns as they are supported directly by those languages. Any developer using a language that supports functions as first class objects doesn’t need the complexities of the Observer pattern for example. C# developers do not need to implement the decorator pattern as extension methods provide an inbuilt way of achieving the same thing. However that doesn’t mean these patterns have no use beyond the scope of Java. Knowing that extension methods is C#’s implementation of the decorator pattern aids communication between developers.
Next she looked at some FP-specific patterns that I’ll not go into here as I don’t yet understand them well enough to comment on. I’ll probably return to them another time.
The Joy of Testing by John Hughes
Joakim Holm noted about Property-Based Testing:
He described a way of testing systems called Property-Based Testing (PBT) with a tool called QuickCheck. (There is a commercial version for Erlang called Quviq.)
As I understood it, PBT means that instead of writing test cases you describe properties of your system. After that, a tool like QuickCheck can take it over and generate massive amounts of random tests. If it finds an error it tries to reduce the failing test case to the minimal case that also gives an error. This is used to improve the feedback to the developer.
John also demonstrated QuickSpec, which was a tool used for deducing and generating properties from examples.
How do you test that?
Cogs in the machine: testing code embedded in an impenetrable framework by Roy Osherove
David Arno wrote on this session:
The title is slightly misleading as it wasn’t so much about impenetrable systems as core systems that cannot be mocked. Roy used the example of the Silverlight framework and demonstrated that it was penetrable if one tried hard enough.
One way of testing against such frameworks is to develop a “wrapper” around the framework that adds a facade between your code and that framework. That way one can replace the framework with a mock when testing. There are though two caveats to this:
- It can be a huge task that takes a very long time to write.
- If the framework is part of the core system, it cannot be replaced.
Performance Testing at the Edge by Alois Reitbauer
Twitter feedback on this session included:
patkua: Nice talk about performance testing by Alois Reitbauer. Nice way to finish off #qcon
apcj: Great points from Alois Reitbauer about motivations for writing performance tests #qcon
Test-Driven Development of Asynchronous Systems by Nat Pryce
Joakim Holm wrote about asynchronous testing:
The problem of integration testing asynchronous systems is that your tests become really slow and fragile. In an asynchronous test, control returns to the test before there is a result. How should we find the result? How long should we wait? Some of the issues you may run into are flickering tests, false positives, slow tests, and messy tests. Nat’s clever solution was to use what he referred to as probes to query a common state between the tests and the system under test. The probe looks for the correct state (whatever that is). If the success condition is not met, we poll again. Finally, we fail on timeout.
I think that the examples Nate showed were great. It really proves that you can test-drive almost all kinds of systems; you just have to think about it a little harder. But just remember that there are issues with this kind of (integration) testing. For one, they are still slow. The probe idea is sound I think, but the test would still run for several 10ths of a second, far too long for a unit test. Secondly, the amount of work you have to do to get the tests working were in all related cases pretty extensive. And thirdly, it is a difficult task to keep the tests running. They have to be very isolated unless they become brittle. I believe that these kinds of technical integration tests are useful, but I would not overuse them. The big chunk of the test-driving effort should still lie with the unit tests.
The Mobile Testing Challenge: Why Mobile Apps Need Real-World Testing Coverage and How Crowdsourcing Can Help by Doron Reuveni
Matt Zimmerman said about Reuveni’s presentation:
Doron explained how the unique testing requirements of mobile handset application are well suited to a crowdsourcing approach. As the founder of uTest, he explained their approach to connecting their customers (application vendors) with a global community of testers with a variety of mobile devices. Customers evaluate the quality of the testers’ work, and this data is used to grade them and select testers for future testing efforts in a similar domain. The testers earn money for their efforts, based on test case coverage (starting at about $20 each), bug reports (starting at about $5 each), and so on. Their highest performers earn thousands per month.
Irresponsible Architectures and Unusual Architects
Hugo Rodger-Brown mentioned about the introduction to this track:
Great presentation about the use of REST, and the role of the internet as an application platform. Over-intellectualized for my liking – some very simple concepts made to seem very complicated - but I liked the message. I totally agree that everyone should understand the core HTTP fundamentals – request/response pattern, HTTP verbs, status codes, header values – the specification is there, use it.
Command-Query Responsibility Segregation by Udi Dahan
Doug Winter appreciated this talk:
This was excellent, and it was pleasant to discover that an architecture we’d already derived ourselves from first principles (which I can’t talk about yet) had an actual name and everything! In particular he concentrated on divining User Intent rather than throwing in your normal GUI toolkit for building UIs – he took data grids to pieces, and championed the use of asynchronous notification. The idea of a notification stream as part of a call-centre automation system, rather than hitting F5 to reload repeatedly, was particularly well told.
LMAX - How to do over 100K contended complex business transactions per second at less than 1ms latency by Dave Farley & Martin Thompson
Hugo Rodger-Brown liked this session:
Great presentation from the team at LMAX on how to achieve 100k tx/sec at a guaranteed 1ms latency. Turns out it’s about getting some very clever people together and letting them solve some simple problems. Really impressive to hear from people at the top of their game about how they did it; so much more impressive than the waffle the blogocracy come out with (he says, whilst blogging). Inspiring.
Ok, the only thing I can say is - this hurt my brain. Their solution was computer engineering elegance, hitting the sweet spot at every point in the chain - really forced me to think about how to approach problems and really reminded me of the early days of PC's where every bit of performance was eeked out of the system.
Simplicity - the way of the unusual architect by Dan North
Tim Anderson blogged on this presentation mentioning among others:
North talked about techniques for lateral thinking, finding solutions from which we are mentally blocked, by chunking up, which means merging details into bigger ideas, ending up with “what is this thing for anyway”; and chunking down, the reverse process, which breaks a problem down into blocks small enough to comprehend. Another idea is to articulate a problem to a colleague, which exercises different parts of the brain and often stimulates a solution – one of the reasons pair programming can be effective.
A common mistake, he said, is to keep using the same old products or systems or architectures because we always do, or because the organisation is already heavily invested in it, meaning that better alternatives do not get considered. He also talked about simple tools: a whiteboard rather than a CASE tool, for example.
Glen Ford noted on this talk:
Dan is a great speaker, entertaining and engaging. The talk started with a comical biblical style story with one of my favorite lines being - "And Maven brought forth a Plague of Apache Commons, and there was a flood of all the Libraries of the Internet as a judgment upon the people"
The talk was about how we over complicate things, gradually over time we introduce further and further complexity. Dan presented some techniques to try and address these tendencies.
The Counterintuitive Web by Ian Robinson
Glen Ford remarked on this talk:
One of the best talks of QCon, Ian delved into the differences between Operation and Resource centric architectures - some overlap with Mondays tutorial, but was in many ways complimentary.
He talked about how to map Domains on to Resources and how HTTP can be used appropriately as the Application Transfer Protocol and not just treated as a Transport Protocol. One of the best tag-lines of the talk was 'Intention should be written on the wire'. The idea that contracts can be expressed simply in the combination of link relations, media types, HTTP idioms and an entry point URI.
IT - more than tools and technology
What are we programming for? By Martin Fowler
Joakim Holm enjoyed this talk:
Martin’s talk was given without slides and what appeared as mostly from the heart. It was basically a sampling of situations where work ethics come into play in our profession. His main message was that many software developers seem to view themselves as ”hired guns”, mercenaries that will do anything as long as you give them a spec. Questions like ”For what purpose will the software be used?” and ”Do I want to keep supporting this employer/client?” never seem to enter their minds. Well, maybe it’s time they did? Think about your own life for a second. Exactly for what are you giving away your talents? […]
I loved this talk and so did the crowd. Martin received very strong and warm applause. Coming from Adaptiv myself, a company with a strong CSR commitment, I was very happy to see these topics broached at a geek conference.
Tim Anderson made some remarks on Fowler’s talk regarding ethics in programming, including:
The topic itself has many facets, perhaps awkwardly commingled. Should you walk away if your customer or employer asks you to code the wrong thing – maybe enforcing poor practice, or creating algorithms to fleece your customer’s customers? What about coding for proprietary platforms owned by vendors with questionable business practices? Fowler mentioned that around 50% of ThoughtWorks solutions are built on Microsoft .NET; and that the efforts of Bill Gates to combat malaria was something that helped him make sense of that relationship. […]
Finally, he talked about the male/female imbalance in software development, rejecting the idea that it is the consequence of natural differences in aptitude or inclination. Rather, he said, we can’t pretend to have the best people for the job while the imbalance continues. I’d add that since communication is a major theme of Agile methodology, and that females seem to have communication skills that males lack, fixing the imbalance could improve the development process in other ways.
Non-Relational DBs & Web Oriented Data
Auntie on the Couch by Enda Farrell
Some interesting info on CouchDB use at the BBC, primarily around the ops side (restarts so quickly (<1s) that they can recycle processes on live production servers without triggering alerts). In summary, it works, at scale, and is easy to manage - go try it. (It powers users’ homepage preferences for one thing).
MongoDB: huMONGOus Data at SourceForge by Mark Ramm
Twitter feedback on this session included:
kirkwy: From the MongoDB #qcon talk: "Figure out what YOUR app needs; don't obsess about scale you'll never need/achieve"
kirkwy: MongoDB talk: nearly as fast as Tokyo Cabinet, faster than CouchDB, with simple query language built-in
Not Only SQL: Alternative Data Persistence and Neo4J by Emil Eifrém
Henrik Engström wrote many notes on this sessions, including:
The meaning of the term NOSQL is:
not "Never SQL"
not "No To SQL"
is "Not Only SQL"
4 Emerging Categories of NOSQL
key-value stores (based on Amazon's Dynamo Paper). Example Programmes: Dynomyte, Voldemort
big table clones (based on Google's Big Table Paper). Example Programmes: HBase, Hypertable, Cassandra (which is used by e.g. Twitter)
document databases (collection of key-value pairs, inspired by Lotus Notes!). Example Programmes: CouchDB, MongoDB
graph databases (nodes, relations, key-value pairs). Example Programmes: Sones, Neo4J, AllegroGraph
Project Voldemort at Gilt Groupe: When Failure isn't An Option by Geir Magnusson
Tim Anderson attended this presentation and noted:
Geir Magnusson from Gilt Groupe talked about the challenge of running a web site which has extreme peaks in traffic, and where every user needs dynamic data and transaction support so simple caching does not work. They were unable to get their relational database store to scale to handle thousands of transactions a second. They solved the problem with an in-memory non-relational database.
Hugo Rodger-Brown summarized his impression on this session:
Enjoyed this one - some great insights into using NoSQL from an ecommerce perspective (used for inventory / shopping cart if you're interested.)
Social networks and the Richness of Data: Getting distributed webservices done with Nosql by Lars George &Fabrizio Schmidt
Matt Zimmerman also has many notes on this presentation, some of them being:
Lars and Fabrizio described the general “social network problem”, and how they went about solving it. This problem space involves the processing, aggregation and dissemination of notifications for a very high volume of events, as commonly manifest in social networking websites such as Facebook and Twitter which connect people to each other to share updates. Apparently simple functionality, such as displaying the most recent updates from one’s “friends”, quickly become complex at scale. […]
This [the need to rearchitect their system] led them to an architecture based on:
- Nginx + Janitor
- Embedded Jetty + RESTeasy
- NoSQL storage backends (no fewer than three: Redis, Voldemort and Hazelcast)
[…]
Their list of lessons learned:
- Start benchmarking and profiling your app early
- A fast and easy deployment keeps motivation high
- Configure Voldemort carefully (especially on large heap machines)
- Read the mailing lists of the NoSQL system you use
- No solution in docs? – read the sources
- At some point stop discussing and just do it
Pragmatic Cloud Computing
Development Model for the Cloud: Paradigm Shift or the Same Old Same Old? By Ümit Yalcinalp
Ümit focused on the PaaS (platform as a service) layer, and the experience offered to developers who build applications for these platforms. An evangelist from Salesforce.com, she framed the discussion as a comparison between force.com, Google App Engine and Microsoft Azure.
Situation Normal, Everything Must Change by Simon Wardley
Tim Anderson made a comment on this talk:
Wardley’s most striking point, repeated perhaps too many times, is that we have no choice about whether to adopt cloud computing, since we will be too much disadvantaged if we reject it. He says it is now more a management issue than a technical one.
Joakim Holm wrote about this talk:
In the Cloud Solutions track, Simon Wardley of Canonical (of Ubuntu fame) had a good talk on the ominous ”cloud”. He explained the process of commoditization, being driven by both suppliers competition and customer competition (getting a cheaper, better deal than your competitors). Many products and services are subject to this process, from fridges to electricity to computing resources. Personal note: That doesn’t mean all things are subject to gradual commoditization. Creative, human-intensive services, for example, are not. […]
Simon said the biggest myth surrounding the cloud was this: Companies actually believe they have a choice.
The Cloud Silver Bullet: Which calibre is right for me? By Chris Read
Matt Zimmerman made a concise summary of this session:
Chris offered some familiar warnings about cloud technologies: that they won’t solve all problems, that effort must be invested to reap the benefits, and that no one tool or provider will meet all needs. He then classified various tools and services according to their suitability for long or short processing cycles, and high or low “data sensitivity”.
SOA 2010
Does REST need middleware? by Bill Burke
Hugo Rodger-Brown wrote on this talk:
This was a great wrap-up for the conference as a whole – how to use an existing, simple, well-understood protocol (HTTP) to satisfy some pretty complex requirements – SOA, reliable messaging, transactions etc. Really elegant solution (REST-*), and definitely something to watch. A great way to end.
RESTful Business Process Management by Cesare Pautasso
Hugo Rodger-Brown also attended this talk and commented:
Dry, academic, talk that demonstrated quite nicely that terms like ‘REST’ and ‘Mashup’ do not mix with terms like ‘BPM’, ‘SOA’, etc. from a cultural point of view, if nothing else. Yes, you could build an SOA using REST services, you just wouldn’t call it SOA – and neither would you use a visual tool to do it for you. Enterprise and community are not happy bed-fellows.
One thing I did quite like was the use of the HTML ‘embedded resource pattern’ for building composite services. Embed the URI of another service in a service response and shift the burden back on to the client – exactly as HTML does with web pages, where the browser is responsible for building the composite view from all of the embedded URIs.
Software Craftsmanship
Beyond Masters & Apprentices: A Scalable, Peer-led Model For Building Good Habits In Large & Diverse Development Teams by Jason Gorman
Matt Zimmerman wrote a detailed description of the talk, including:
Jason explained the method he uses to coach software developers. […] He began by outlining some of the primary factors which make software more difficult to change over time:
- Readability: developers spend a lot of their time trying to understand code that they (or someone else) have written
- Complexity: as well as making code more difficult to understand, complexity increases the chance of errors. More complex code can fail in more ways.
- Duplication: when code is duplicated, it’s more difficult to change because we need to keep track of the copies and often change them all
- Dependencies and the “ripple effect”: highly interdependent code is more difficult to change, because a change in one place requires corresponding changes elsewhere
- Regression Test Assurance: I didn’t quite follow how this fit into the list, to be honest. Regression tests are supposed to make it easier to change the code, because errors can be caught more easily.
He then outlined the fundamental principles of his method:
- Focus on Learning over Teaching – a motivated learner will find their own way, so focus on enabling them to pull the lesson rather than pushing it to them (“there is a big difference between knowing how to do something and being able to do it”)
- Focus on Ability over Knowledge – learn by doing, and evaluate progress through practice as well (“how do you know when a juggler can juggle?”)
Doug Winter wants to apply the lessons learned in this session:
Finally what I think was the most interesting talk of the conference and one directly relevant to my current work, Jason Gorman gave a fantastic talk about a training scheme he is running with the BBC to improve software craftsmanship using peer-review. I’ll be trying this out at Isotoma, and I’ll blog about it too!
Danger: Software Craftsmen at Work by David Harvey
David Arno commented on this talk:
My favorite talk of the day, but the one that is most difficult to summarize. David Harvey argued that one should treat the Software Craftsmanship movement with caution. Tying in with Dan North’s comments regarding software not being like bike riding, David highlighted our desire to borrow metaphors from other human endeavors to try and describe software. Computer science, software engineering, software architecture, software craftsmanship etc. Each of these words: science, engineering architecture and craftsmanship risks imposing negative baggage on the software industry and is at best a poor fit. So whilst software craftsmanship is a good idea, maybe we should just call it “best practices and professionalism”.
Sharpening the Tools by Dan North
Joakim Holm wrote about the speaker, adding a short summary:
Dan is speaker that is a joy to listen to; with a great sense of humor. Sometimes I feel that he has so much pure, British charm he doesn’t actually need much in the way of content.
Dan’s main message in this talk was that we as developers, from beginner to master, must never cease improving, i.e. sharpening our tools. Apparently, switching jobs was a humbling experience. Dan used ”tools” in a very general meaning and could be anything from, for example, the technical, methodological, personal, team or leadership domain.
First up was Dan North, talking about software craftsmanship. The key thing I took away from Dan’s talk is the blindingly obvious, yet easily missed, fact that software isn’t like riding a bike. To explain: one can learn to ride a bike, not go near one for 15 years, then get straight back on one and continue riding as if that 15 year gap had never occurred. I know this from personal experience.
Software is not like bike riding. Take a 15 year break and upon your return, the mainstream software industry will be unrecognizable to you. All software developers need to put effort into constantly learning about new frameworks, languages, tools, patterns etc just to stand still. Stop learning new stuff and your developer skills will rapidly atrophy.
Software Craftsmanship, Beyond The Hype by Corey Haines
Joakim Holm summarized the talk:
Corey held an inspiring talk on the software craftsmanship movement. I really liked his rundown of practical initiatives and activities that has happened under that umbrella; things that would never have occurred otherwise, for example, Kata video casts or Craftsman swaps between companies.
Corey said another interesting thing: Think about where you would really like to be, competence-wise and professionally, under ideal circumstances. This is your current goal of excellence. Then, think of how you develop software under stress. That’s when you revert to the practices you really master, not the once you are trying to adopt. Now, subtract the last from the first – that’s the amount you currently suck!
The Concurrency Challenge
Embracing Concurrency At Scale by Justin Sheehy
Adrian Hills shared his thoughts on this talk:
Justin Sheehy […] with a talk on "embracing concurrency at scale" - eventual consistency was a term becoming more and more at the forefront of my mind, as was the point that ACID does not work with a distributed, scaled system. Instead you have a trade-off with BASE:
which leads to Availability and Partition tolerance (from the CAP theorem).
- Basically
- Available
- Soft state
- Eventually consistent
Message Passing Concurrency in Erlang. An architectural basis for scalable fault-tolerant systems by Joe Armstrong
Twitter feedback on this session included:
div_: best #qcon quote so far ? Joe Armstrong quoting Mark Williams; "They are going to drop bombs on our stuff, but I think it will work"
Social Events
Adrian Hills enjoyed the second day’s social event:
Day 2 ended with a number of usergroup events, and I went along to the NNUG(Norwegian .NET User Group) / alt.net beers event at a pub in Soho. It was somewhat surreal for me, having drinks and chatting with the type of experts I can only strive to be (to be very geek, heroes): Ayende Rahien (Oren Eini), Jon Skeet, Roy Osherove, Udi Dahan to name but a few. It was fantastic to see a number of other .NET developers show up that hadn't attended QCon, and was good chatting to them. This was my first usergroup event - lesson being, I really should have attended one before now. Take that as another TODO on my list.
Twitter feedback on this session included:
flurdy: Enjoying the free beer and snacks by atlassian at #qcon. Not many here thu, Our litlle gang is 50% of the people here! :)
chrismdp: On way home after excellent #qcon. Really enjoyed meeting all you fine people. Highlight? NNUG pub night yesterday.
Opinions about QCon
Tim Anderson enjoys QCon because it is not vendor specific:
I’m just back from QCon London, a software development conference with an agile flavor that I enjoy because it is not vendor-specific. Conferences like this are energizing; they make you re-examine what you are doing and may kick you into a better place.
Doug Winter described QCon:
A couple of us went to QCon London last week, which as usual had some excellent speakers and some cutting edge stuff. QCon bills itself as “enterprise software development conference designed for team leads, architects and project management”, but it has a reputation for being an awful lot more interesting than that. In particular it covers a lot of cutting-edge work in architecture.
Adrian Hills summarized what he learned at QCon:
Some of the key points I'm walking from the conference with:
- keep things simple - complicated doesn't work. If you find your design is complicated, then the chances are you're probably doing something wrong!
- focus on optimising for an individual task, rather than one-size-fits-all approach
- ACID doesn't go well with scaling
- eventual consistency - does it matter if your data is persisted throughout immediately? Probably not. As long as the system is eventually consistent, that's usually all that is required and allows you to scale better
- asynchronous messaging
- rules of thumb do not apply - use existing patterns as a starting point for discussion - just because you've done something one way before, doesn't mean you should automatically do it the same way in future
And so QCon is over for this year, and it’s been a great conference (IMO). I’m not sure I learned anything totally new – it was more an affirmation of things I’d thought / heard / read about – and a chance to see some of these things out in the wild. The speakers ran from big conference names to academics through some front-line experts, so a real range. I don’t think I attended a single sales pitch, and although a few named products slipped through the net, they were all OSS projects, not commercial products. All-in-all it seemed to stay true to the “for programmers by programmers” promise.
I would also like to point out that if you have the chance to go to any QCon conference you should! They are the best.
I had a great time at Qcon London last week, it really is one of the more forward thinking conferences out there for the enterprise.
Twitter was filled with thousands of comments during QCon, including:
kiltec: Seriously, I'll be in trouble in #qcon, lots of talks I'm very interested in taking place at the same time... :D http://bit.ly/aQSRee
marcjohnson: Great 1st day at #qcon topped off by good conversations in pub with@jimwebber, @iansrobinson, @martinfowler, @KevlinHenney, @olabini et all
div_: #qcon wrapping up, been an interesting ride.
joshdevins: Nice conference #QCon, nice view of the London Eye and Big Ben too! http://twitpic.com/184613
shs96c: Really enjoyed #qcon. Now to round out the evening with nerd talk and coding.
fedespagno: #qcon Great experience, great speakers, great people. Many Thanks to #qcon team
stiiifff: #qcon 2010 is over. Amazing conference. I plan to come back every year ! Zillions of ideas that I need to organize now.
stilkov: Traveling home from #QCon, great conference, as usual. Looking forward to next year!
zukunftsalick: Great week at #qcon in London, now, sadly, back to Madrid...
timrgoodwin: good week at #qcon. great to catch up with so many great people. so long and thanks for the pints.
jacekskrzypiec: Back home after my first #qcon. Plenty new ideas on how to create better applications.
rossmason: Still buzzing after #qcon well done to Floyd and his team and Trifork. You guys nailed it!
mtnygard: This week at #qcon has left me physically tired but mentally sustained.
m_st: really sad that #qcon is already over
marcjohnson: Had an awesome #QCon and then TW pub, met loads of new people from all over the world, some of which are heroes of mine, some new friends
martinnjensen: back from #qcon, what a trip! my head is still spinning
kiltec: And I definitely will come back to the #qcon next year, even if I had to pay everything on my own.
doxla: Back at home with a nice bottle of 2004 Rioja. Great week at #qcon some of it turned my ideas inside out.
Takeaways
Kevin Seal considered there are so many things going on that one cannot follow all of them:
QCon felt quite diverse this year, running tracks on Agile, Java, .NET, architecture, craftsmanship, design, web and mobile development, testing, and more. As such, it’s quite hard to come away with some sort of over-arching feel for what’s driving the industry at the moment. Perhaps that’s really the take-away message this year: that there are numerous movements bubbling under, but a growing sense of pragmatism over technology choice and process adoption. […]
There was a huge amount in addition to this at the conference -- certainly a couple of consistent technical themes that are worth tracking down on the QCon site. In particular, Dan Ingalls provided a reminder of the enjoyment we can get from developing software and that we shouldn't lose sight of this in our work.
Adrian Hills had the same impression:
So many inspiring speakers, a packed schedule of talks over 3 days on a number of tracks and a great bunch of people. This was my first QCon, and cannot recommend the experience enough. The only thing I didn't enjoy, was having to decide between which talks to attend. But that's the true sign of a good conference.
Some of Hugo Rodger-Brown’s impressions:
The overall theme seemed to be that you can achieve pretty much whatever you want using bits and pieces that are already out there and tailoring them for your particular problem domain. There is no one-size-fits-all solution, and very little reason to pitch up to a big COTS vendor and buy their product suite (beyond internal accountability and CYA.) The real key is getting the right people and empowering them to solve the problem for you. Small teams, with the tools they need, no more, no less, will get you there. The same solution applies whether you’re tackling problems of scale of planetary proportions (Facebook), or focussing on extreme performance at the chip level (LMAX). […]
Highlights were LMAX and Facebook – amazing teams breaking new ground – inspiring stuff from both, and a big thank you to the speakers, Aditya Agarwal from Facebook, and Dave Farley & Martin Thompson from LMAX.
On a technology front, the web is ubiquitous, as is mobile, though what that means is still a problem (what makes something “mobile” if my netbook runs the same software as my desktop – is it GPS, AR?) If you’re working client-side then it’s HTML/CSS/JS and HTTP; if you’re working server-side it’s offline, async, and message-based. Nothing new, although you might want to think about storing your data in somewhere other than an RDBMS. Just make sure you know why you’re doing what you’re doing, and can defend your choice if necessary.
Twitter feedback on this session included:
natpryce: Take-away thought from #qcon: we need an alt.java movement that champions simplicity over complicated but standard APIs.
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. We also look forward to continuing to run QCon in other regions which InfoQ serves, such as China and Japan, and introducing it to Brazil for the first time this year. Thanks everyone for coming and we'll see you next year!