Key Takeaway Points and Lessons Learned from QCon London 2007

Posted by Floyd Marinescu on Mar 22, 2007 05:38 AM

Community

Agile,

Java,

Architecture,

.NET,

Ruby,

SOA

Topics

Events

Tags

Open Space,

QCon,

Conferences

In this article we present the main takeway points and lessons learned as seen by the many attendees who blogged about QCon.  We will continue to monitor blogspace and update this article as new perspectives get added.  Experience the conference through all the points people felt worth blogging about. :) You can also see over 320 attendee-taken photos of QCon on Flickr. 

QCon London was InfoQ's first conference and has been quite a success. The event was produced in partnership with the folks who produce the JAOO conference, and drew a large crowd with over 550 badges printed and attendees from 24 countries. Although a first time event, a significant investment was made in the conference which will be a growing annual event in London for years to come; 83 speakers presented in 83 sessions and 9 tutorials at QCon, on a diverse range of topics as you'll see below. In all of the conferences we've ever been involved with, we've never seen so many people blogging and publishing such detailed content about a conference!

This article organizes bloggers' comments by conference tracks, grouped by conference session. Click to go to the section you're most interested in: Case studies (amazon, eBay, Yahoo!)  Java, Agile, the Agile Open Space, Qualities in Architecture, Ajax and Browser Apps,  .NET, Ruby, SOA, Usability, Banking Architectures, followed by a summary of participants'' overall opinions of QCon.  

Case studies: Architectures you always wondered about

The eBay architecture

Martin Fowler reacts to the news that eBay.com runs transactionless:   "My immediate follow-up to the news of transactionless was to ask what the consequences were for the application programmer, in particular the overall feeling about transactionlessness. The reply was that it was odd at first, but ended up not being a big deal - much less of a problem than you might think. You have to pay attention to the order of your commits, getting the more important ones in first. At each commit you have to check that it succeeded and decide what to do if it fails. This style of programming intrigued me, but since I was told about it quietly, I wouldn't talk about it more widely. I can now because Dan Pritchett gave a fascinating talk at QCon this week about eBay's architecture, including this aspect."

TheRegister had an article on SunLive (which was across the street from QCon at the same time) references Dan's talk about the power requirements of large scale systems: "carbon footprint aside, the heat from computer technology and getting rid of it with air conditioning is a major overhead for large installations today – in fact, according to Dan Pritchett (technical fellow, eBay Inc, speaking at the QCon London conference across the road), "power and cooling are now the primary constraint to growth" at this scale of computing, simply because the American electricity grid often has trouble in supplying, in one place, the power needed by the largest data centres today. It was never designed with single buildings using that much power in mind."

Ferran Rodenas writes:  

(eBay Technical Fellow) talked about some interesting eBay’s architecture features, as how they deal with vertical DB segmentation (by functional areas) and horizontal DB splits (date, location, …), and, how they don’t use stored procedures, triggers and, amazing, nor transactions (Martin Fowler is talking about this in his post Transactionless). This means that all business logic is executed by the application (sorts, joins, referential integrity, …). They use intensively prepared statements an bind variables (cached by datasources). They also scales using a rewritten connection pool and an internally developed ORM solution called DAL (Data Access Layer). All CRUD operations are executed through this infrastructure.

Anders also points out the power consumption problem.

Amazon's platform - Werner Vogels' Keynote

Ben provides a great summary of Amazon's architecture: "In 2001 Amazon.com started to transform their architecture bit by bit into an SOA, tasking teams on focusing meeting the service specification, by any means. Some teams used Python, some Java, some Perl, Smalltalk and Ruby...All in all, to serve up the front page of Amazon.com over 180 different, disparate services are called, some providing data, and others aggregating data and page information into the presentation tier...Adopting this entirely service oriented architecture allowed Amazon.com to move into new spheres of service provision

Jiri Lundak's 4 main takeway points:

•  To scale: No direct access to the database anymore. Instead data access is encapsulated in services (code and data together), with a stable, public interface.
• To decouple: Services are aggregateable from other services or very “thin” web application, allowing to mesh different services together and leave out, what you do not need, so supporting many different applications and uses.
• One small team own a service in all its aspects. This has the advantage to make the team responsible for the functioning of the service and at the same time giving it the freedom to do whatever it takes to implement it and make it work.
• Scale later. It is soooo difficult to make it right, that sometimes the effort to do it up front is not justified. Or leave it to somebody, that has the knowhow and has done it already…like Amazon (remember S3 - Virtual Disk, etc.).

Yahoo! backend and SOA strategy by Mark Nottingham 

Excerpts from Stefan Tilkov's excellent write-up:

4 billion daily page views... Integration nightmare for different “properties” at Yahoo!...Yahoo scale is another problem — a link on Yahoo home page will trigger their own version of the Slashdot effect...Each media property was reinventing the wheel all of the time, until some recognized it made sense to reuse components...Requirements for the new architecture: massive scalability, flexible deployment, highly dynamic, separation of concerns — result. move towards a Service-oriented architecture. PHP is much more common at Yahoo! than Java. Scalability, Simplicity, Reuse, Interoperability — decision: use HTTP, not WS-*....Frontend boxes make requests through a cache to backend API servers, all via HTTP. Attributes: single source of truth. Cache replicates data (pull model vs. push model)

Redmonk Analyst James Governor was the trackhost for the case studies track and wrote about his intro:

Martin had talked about the need for a bridge to span the Yawning Crevasse Between IT and the Business. I tried to argue for a bridge to span the yawning crevasse between the traditional enterprise architecture and more web/lightweight approaches. Both sides could learn from one another if we had better “stories” (in the agile sense) to underpin what we might mean by “scale” for example.

Java

Java had two tracks at QCon, the Java in Action track and the Java emerging technlogies track, all comments merged here:

Guilluame Laforge on Grails

Jiri Lundak summarizes the main messages of the presentation:

• Even simple things are quite painful to accomplish with Java frameworks (ORM persistence hard, numerous layers and config files lead to chaos, UI integration messy)
• Grails is an MVC action-based web framework
• Principles: Convention over Configuration (CoC), Don’t repeat yourself (DRY)
• Grails builds on proven components: Spring, Hibernate, Groovy, SiteMesh, AJAX

Peter Krien's takeaway (blogging about Qcon, but summarizing a book): "Key thing of Grails is that it uses a lot of conventions to minimize the coding one has to do. A code generator uses conventions to create most of the boiler plate code that is so prevalent in enterprise software. I have read the book but not played with it yet so I might be disappointed when I really start to play with it, we'll see. But so far it looks promising."

JVM Clustering with OpenTerracotta

Kevin Seal writes:

...rather than presenting an API for sharing data between nodes, Terracotta works transparently against the heap. This makes it more like sharing memory between VMs, and that sounds a lot like a silver buller for many clustering requirements...as a proposition it's very interesting: if VMs share memory (or, more accurately, transparently simulate shared memory, even down to the semantics of locking), that frees the developer from worrying about numerous distribution concerns. Indeed, it permits very simple paradigms that are employed in-process (such as locking and trivial object identity) to be leveraged regardless of the target environment.

Rob Harrop's talk on JRuby

Jiri Lundak writes: "The presenter...started with the jirb (JRuby interpreter) in commandline manner...he was ...actually creating a small Swing application directly in the interpreter...Ruby integration into Java is not seamless. Instead you have to use special integration classes to bind it in...Ruby showed a strength in creating new domain specific languages (DSLs).":

Gavin King presents SEAM

Jiri Lundak's takeaways:

Seam generates a skeleton for a web application inclusive some simple test code. You can modify the code of your application much like in Grails...“We need no f*cking unit tests. Any one programmer can write those simple POJOs without error. The problems come, when you test a class together with its collaborators.”...What Seam brings to the table:

• Single component model for JSF, ESB, EJB, etc.
• No actions
• Persistence: No DAOs, instead binds components that access database through JPA/Hibernate directly to the view
• After changing the DB structure, you need to restart the web server.

 

Spring 2 and Beyond - Rod Johnson

Simon Brown's takeways:

The use of custom namespaces in the Spring config files is a neat way of providing a mechanism for other vendors/frameworks to integrate pretty seamlessly, as well as being an enabler for reducing the complexity associated with those files through the use of much more abstract definitions. For example, you can use a single transactional XML tag to instruct Spring to weave it's transactional magic on any classes annotated @Transactional. Compare this to the boilerplate XML that you have to write in Spring 1.x and you'll see the benefit.

Peter Kriens: "a very interesting presentation in which the OSGi technology played a major role. He even followed the OSGi marketing missives as a new member, explaining that the OSGi Alliance denies they have anything to do with gateways. Of course the effect is that he is educating most of the the audience about the fact that we once had something to do with gateways!"

TestNG presented by the co-founders Cedric Beust and Alexandru Popescu

Cedric summarizes key topics from his own talk:

• Designing for Testability can sometimes be at odds with well-established software engineering practices, such as certain design patterns and extreme encapsulation. You need to be ready to question your beliefs.
• You should avoid using statics, and there are some very valuable frameworks that make this very easy (Guice and Spring, to name two).
• Test-Driven Development does not necessarily lead to code that is better designed, and is best used to expose junior programmers to testing.

Simon Brown writes: "From my perspective, TestNG seems to have some very nice enhancements over what you can get with JUnit and, because of its use of annotations, doesn't constrain you in the same way JUnit does. I asked about how easy it was to "upgrade" to TestNG from JUnit and tooling is available to help automate this process. Sounds something that I'll certainly be taking a look at when I get a chance."

After the presentation, Piotr Gabryanczyk was inspired to switch from JUnit+JMock in Eclipse to use TestNG:  

It was very simple with TestNG IntelliJ plugin which has 'Convert JUnit test to TestNG intention'....The integration of JMock and TestNG turned out to be very simple:
- test class needs to extend MockObjectTestCase
- make sure that setUp() and tearDown() methods in the super class are called. So you need to override them in your test class and annotate with @BeforeMethod, @AfterMethod.

Joe Walker on Java Trends

Joe's intro to the emerging technologies track had a strong focus on closures. Joe wrote a tutorial on his blog about it: "You can look at closures as blocks of code that you can pass around for execution. You can look at them as syntax sugar for inner classes. I think there is some significant power behind full closures that you miss when just looking at them from those perspectives."

AOP in the Enterprise with Rod Johnson

Simon Brown writes:

Rod's session looked at the AOP support in Spring and AspectJ,..there's no doubt in my mind that this is pretty interesting, particularly when you consider that aspects really can be used to simplify development of cross-cutting concerns such as security, business logic validation and even architectural conformance....but there's definitely going to be a barrier of entry there for most developers.

Peter Kriens: "It is interesting how Spring allows you to use many of the AspectJ features without really requiring any AspectJ compiler. The integration facilities of Spring are quite powerful, just the fact that they use XML is a bit off-putting."

Scott Delap Overviews Desktop Java Technologies

Simon Brown's takeaway:

One of the major points Scott made was that the deployment of Swing apps is just a non-starter if you want to ship that app to the general public over the Internet, perhaps using WebStart. The reason for this? Simply put, you can't guarantee that the end user will have Java installed. To get the largest reach of your application, you need to use something like Adobe Flex because the Flash player that it uses is just so ubiquitous. When was the last time you saw a major website (e.g. YouTube) use a Java applet to deliver their functionality publicly? It's a good point and one that gets you thinking about whether Flex will be the start of something more mainstream.

Java Persistence and EJB 3 with Linda DeMichiel (EJB spec lead)

Simon again writes: 

I really like JPA and think it's possibly going to be the thing that grabs people's attention and energy into using EJB on their projects once again. Don't get me wrong, what the team have done with EJB 3 is very cool, particularly because you can make any POJO an EJB through a couple of annotations. It's just that people have been burnt by EJB in the past and might not be very enthusiastic about coming back.Once people see JPA, they just might take a look at the rest of the spec too.

Agile

Agile at QCon was divided into three tracks, Agile Foundations, Agile Mastery, and a special Agile Open Space event that ran concurrently with the Mastery track.

Keynote: Martin Fowler and Dan North present "The Yawing Crevass of Doom"

Tim Anderson summarizes the keynote:

The yawning crevasse of doom; this refers to the tendency of those who develop software not to communicate with the beneficiaries of the software - users, business people etc.It helped me to understand that most software failures are caused not by technical issues but rather by communication problems...I find this a healthy corrective to the reams of PR I receive from vendors implying that their tools can prevent project failures. They love to quote figures from the Standish Group which allege that most software projects fail.

Marc the dancing mango writes:

Their central theme was around communication between the customer / end user / consumer / business and the developers / IT. Martin drew a great analogy; do you want your communication between the two “sides” to be like a ferry boat or a bridge. Part of the bridge that Martin and Dan talked about was the use of ethnographic research – observing users in their natural environments and storyboards / wireframes / lo-fi prototypes to visually articulate requirements in a way that written requirements can never do. i.e. championing the stuff that I am passionate about, and what we at ThoughtWorks do deliver successful projects.

 

User Stories and Release Plans with Rachel Davies

Johanna hunt writes:

Rachel made a very interesting point that traditional requirements documents are based on the traditional model of knowledge transfer - a model which was exemplified in teaching with lectures where the expert can pass knowledge directly to a student (who will then retain it).  The view is that knowledge can be poured out, captured, recorded and then delivered on to other people without a loss.  This view has changed, with increasing education activities focussing on reflection, group activity and tacit knowledge.  The same change could be seen in the shift from requirements capture to user stories

Commenting then on how iterations are planned, Johanna summarizes "Each iteration has the stories and features planned - generally estimated in story points.  There is normally more detail in the plan for the closer iterations.  At the end of each you review and refine the plan, adjusting and adding detail accordingly.  However the release dates are always fixed."

Ben continues: "Also Rachel covered planning releases, and for example deploying every 5^th iteration, and that not deploying every iteration won’t send you to hell. She also focused on retrospectives at the end of each iteration including the review the release plan."

Agile Architecture is not Fragile Architecture

Jen Norins writes: "on stage battle between Kevlin Henney and Jim Coplien....they both firmly believed that architecture was too important to be put off by a "we're agile and architecture is not, so we don't do it". Again TDD was under Jim's cross-fire with questions like "How do you know which unit test to write if you didn't design any architecture?", "If we don't have a short design phase upfront, where does the architecture come from?", "What design artifacts do TDD create?". Interesting points."

 Mikael Essle writes: "Are the agile people starting the get it? It sounds like even the agile people think that it is a bad idea to run 100 miles without a map and a goal. I even heard agile people talking about "Inception". How un-agile isnt that word ;) Jim Coplien and Kevlin Henney had an interesting talk were they mentioned RUFD (Rough UpFront Design) as a good start in an agile project. To me it sounds like a very good idea. It cant be bad to think a little bit before you start developing in a project."

Steve Freeman & Nat Pryce - Test Driven Development

Johanna Hunt writes:

So, why use TDD? - arguably because you end up with half the defects but similar productivity.  It helps to give the confidence to get the job done, and you don't need to worry so much about side-effects...Tests are best named after what they will do for us and not the methods that they are testing.. Refactoring supports design aspect by removing duplication and helping to express intent.

Ben summarizes

Steve spoke about Test Driven Development, showing some examples, driven using the magic formula: Write a test, Make it pass, Refactor...Often, there are views that TDD is too much work. Some counters to this line of arguments are:

• Most of time is spent reading code.
• Include debugging time - if you get good at this, debugging time drops dramatically.
• Reliable code lets QA focus on larger issues.
• It becomes critical when you scale up - it enables you to scale up cheaply and safely - particularly around teams.

Robert Godfrey's favourite:

Particularly liked the description of how the objects that an object collaborates with can be classified into:

• Dependencies
• Policy
• Parts
• Notifications

and how a constructor only really needs to accept dependencies as parameters to setup an object in a valid state. The policy, parts and notifications can typically be defaulted.

 

Dave Thomas on Developing Expertise: Herding Racehorses, Racing Sheep

Ferran Rodenas writes:  

Dave Thomas started his speech asserting that process improvement requieres PEOPLE improvement (he recommends to read Capers Jones assessments and benchmarks). Using the Dreyfus Model of Skills Acquisition, he described, on a funny way, the characteristics of people on different stages (Novice, Advanced beginner, Competent, Proficient, Expert). He stated that the vast majority of developers are on Stage 2, and we need to raise the bar. He advocates to use Dreyfus to fix companies and to fix our careers, and also, learn and apply financial management to our daily work (have a plan, diversify, look for value, be active, …).

Mikael Essle's takeaway was:

Dave Thomas had a great talk about the Dreyfus model describing different skills of a person. From novice to an expert, a novice is a beginner and the best thing for that kind of person is to apply things and fulfill simple goals with guidance [instead of starting with a mountain of documentation]...When the person have worked for a while in the project, then will he/she probably start asking for documents that can give more understanding and at that time will he also be a lot more open for the information.

Dave Thomas himself writes:  

I think there are methodologies which can be mastered, where you can say “now I know it all.” I don't believe agility is in that camp. For me, agility is all about the journey. Along the way, we'll always be faced with forks in the road. The agile principles help us decide which to take. And we just carry on, enjoying the trip and doing our best along the way.

Vednis writes:  

Dave mentions maxims as a teaching tool used by those who have attained fourth stage skills. This struck a chord with me and fits well within my experience. For example, career consultant Markus Buckingham uses maxims to great effect.

Ben writes: "Using the Dreyfus Model as a method of understanding Dave spoke about...the levels and habits of people with different amounts of knowledge. The importance of setting goals, rules and boundaries for novices, the criticality of enabling intuition in Experts by not questioning why, but just trusting them.

Lessons Learned at Google - by Jeff Sutherland

Jen Norins on Scrum for running countries: "Of course master motivator Jeff Sutherland attracted a large crowd when talking about Lessons learned at Google. His speeches almost resembles revivalist meetings that you cannot avoid being sucked into. His performance is really great and afterwards you get the feeling that Scrum can be used to run countries and solve world poverty. Actually you probably could run a country successfully using Scrum. It require a lot of scrum of scrums though. :) "

Jiri Lundak writes: "At Google the Adwords project is using Scrum, they have begun about a year ago in early 2006 to introduce individual Scrum practices, like a release backlog, into the company. Originally in 2001 Google decided, that they did not need any Managers, because they were not adding value to the company. So they eliminated all managment positions. So from that time on, projects evolved organically. When Google was growing bigger and the software (in case of Adwords) increased in size (500′000 LOC and still growing fast), the project manager of that project saw the need for a little bit more structured approach, which would not destroy the organic nature of the current way to do things, as this was seen as a good thing. "

Marc the dancing mango writes:

Jeff Sutherland talked about how at Google they don’t have performance appraisals. Instead everyone has personal “three month objectives” that are posted on their blogs (the first thing that a new recruit at Google does apparently is creates a personal web page). In this way people can share with the broader organisation what they are doing. With google search experts and their knowledge can easily be found. Advertising to the organisation what your goals drives performance far more effectively than a sterile quarterly form distributed by HR…

 

Joseph Pelrine: When Agile Hits The Wall - Dealing with the org challanges of Agile adoption

Jiri Lundak writes:

Joseph compared going to fast with Agile adoption with running downhill - if you let go, you accelerate and accelerate until you go to fast and stumble over your own feet...So the first step for resolving anything is to know the problem space and to capture the force that are at work within the organisation. Usually there is a clash in the unterstanding of “cause and effect”. Often management and an Agile team live in two different worlds. Management often remains stuck in a Newtonian world view, while the Agile team embraces a Complexity Science based approach. These are not compatible with each other.

 

Boris Gloger - Heartbeat Retrospectives to Amplify Team Effectiveness

Johanna Hunt writes:

Why retrospectives? We would like to improve what we have done in the past. Disappointment of expectations stops learning.  Retrospectives need to occur after events to encourage learning....Heartbeat retrospective can last 10 to 90 minutes...6 step process: 1) security first, collect facts, ask: what went well?, ask: what could be improved?, who is in control?, Prioritise activities.

LSC also went into more depth on the parts of each of the 6 steps.

Commenting on the Agile at the conference itself, "Urban" writes:

My main impression from the conference is that the Agile community is starting to realize that 1) beeing too "Agile" is not always a good idea, and 2) even if you are using Agile methods (Scrum, XP etc.) you might run into problems in your software development projects.

Agile Mastery OpenSpace

Sadek Drobi made a nice picture tour of the open space, and took notes of how it works:
     

Participants from a few sessions logged their Open Space session notes on the qcon wiki:

• All this people stuff is really hard, can't we just buy a cricket bat instead?
• Agile Contracts: How do you define contracts that don't force an initial waterfall?
• Test Driven Development: How do we make TDD work, and what is it good for?

And Sadek Drobi blogged one that didn't make it to the wiki: How to handle Difficult Team Members

Qualities in Architecture Track

This track looked at concrete operational qualities in architectures:

Martin Fowler - Modifiability

Tim Anderson writes: "This is about the distinction between agility and chaos; Fowler referenced a remark he attributed to Kent Beck about the difference between the simplest thing that will work (good) and the stupidest thing that will work (…). Just common sense nicely articulated: take most care over the decisions that are the least reversible....I also enjoyed the comments on test-driven development, noting that a spin-off benefit of TDD is that it enforces modular design, since without modular design you cannot easily create tests."

 

Performance and Scalability - Cameron Purdy

Jiri Lundak notices an interesting contradiction: "In one point Cameron made somewhat contradictory statement in contrast to the keynote of Werner Vogels: Architect for performance and scalability up front, because it will cost you way too much to put it in at a later point in a project. So who is right? Well, when I try to consolidate those two talks overall message I come to this conclusion: Include thoughts on performance and scalability in your initial draft of your architecture, but be ready to revide it and to optimize it at a later point, when you know a.) more about the real requirement for your system, and b.) when you are able to see with your own eyes (or mesure), where the effective bottlenecks hide."

Availability and Consistency - Amazon's Werner Vogels

Jim Webber comments:  

He makes the fundamentally correct point that he expects developers to deal explicitly with distributed systems artefacts so that they can explicitly handle failures gracefully rather than hiding such failures in the infrastructure and hoping like hell nothing too serious happens. This is not counter-intuitive, it's just the cost of building dependable distributed systems - excellent advice for anyone wrongly thinking about exposing their EJBs through WSDL!

Marc McNeil comments on Amazon's team organization:

I’ve blogged before about siloed organisations, but Werner touched on how even internal IT organisations can be siloed.  Something about how your database team may be soley focussed upon consistency; they are willing to sacrifice availability for valid technical reasons.  But the database needs to be seen in the bigger picture, outside the confines of the IT organisation.  It needs to support the customer experience.  And that means the customer must always be able to put items in the shopping cart.  Period.  The takeaway I suppose is to build your architecture around the customer experience; decompose the experience to do this... Make technical decisions accordingly, rather than a one-size fits all.

Usability

The goal for this track was to make developers aware of the crucial importance of the user interface in software products, the importance of good analysis of the user environment, and the use of suitable software structures to support the interface.

Jim Coplien on From Design Practice to Code

Jens Norin writes:

he provoked quite a few when he challenged some of the agile practices. Especially Test Driven Development (TDD) was under his attack. His point was that if development is test driven you should start by defining acceptance tests, naturally. But his question was how do you go from acceptance tests to unit tests without doing design. I definitely see his point, that you in many cases are forced to do a short design phase upfront before doing TDD. His advice was to skip TDD altogether, but I think TDD can be a great tool, especially for systems with well known architectural patterns and in the hands of experienced programmers.

Jiri Lundak comments on a Usability tutorial also led by Jim Coplien:

Larry advocates a usage-centered approach to UI design instead to a user-centered approach. The difference is, that usage-centered approach focuses on the work to do and to optimize that, instead to put the user primarily at ease and neglecting the efficient solution of the user’s problems at hand. So his motto is: “Put good tools in the user’s hands, that he can creatively solve his daily work problems.”...One thought that alarmed me, was that Larry said: “I am the usablility expert, so I need to involve the user only a bit, so I know what he wants, but I decide, how he gets it.”.

 

Keynote: Larry Constantine on Meeting the Usability Challenge

Tim Anderson writes:

His big idea is that developers should not rely on user opinion, feedback and testing to determine the user interface and feature set of applications. You end up with too many features, and replication of past errors. He made some good points, but I was not greatly impressed with this session. The majority of the time was spent poking fun at other people’s UI blunders, which left little space for presenting Constantine’s proposed solution, a thing called Activity Modeling.

Ajax and Browser Based Applications

Ajax and Design Patterns: Do we need a client tier? 

Robert Godfrey's session notes on the two patterns Dave Crane presented:

MVC:

• Model maintained in client (possibly XML or JSON data sctructure)
• Multiple views registered as model listeners with controller
  
• Views access model state
• Controller invokes view callback functions to update views on model change events
  
• Javascript allows dynamic reflection on callback functions by function name, i.e. if controller can find a function with a name on a listener it will be invoked.
  

Strategy:

• Since functions can be referenced as variables and passed around, strategy implementations can be implemented as functions with a closure.
• Function objects in Javascript are a bit like anonymous inner class in Java.
• Example use of a closure to pre-register lunch activities (devour sandwich, clean ear with pencil, ...) when person comes into office in the morning, with objects to interact with (e.g. sandwich).

Google Web Toolkit: What, Why and How - Bruce Johnson

Ajax Patterns author Dave Crane was initially skeptical but by the end of the talk, he wanted to give GWT a try, because:

• because the entire codebase is written in a strictly-typed language (Java), global optimisations can be made with much more ferocity than in trying to infer intent from a loosely-typed language. As a human writing code by hand, I still prefer scripting languages, but I can see that all the safety harnesses help out when generating the code automatically.
• GWT doesn’t take as command ‘n’ conquer approach, but plays well with hand-written web UI. You can break out into Javascript in your code (overloading the native keyord - too cute!), and/or target GWT at specific elemnts in a hand-written page
• network performance, caching, and all that important-but-tedious plumbing detail benefit from the global optimisation approach.

Robert Godfrey thought GWT was really cool, his session notes:

• Hosted mode customer browser allows Java debugging of UI without opening IE / firefox
• Widgets are styled with CSS
• History support looked well implemented
• RPC support allowed for Java refactoring of client and server code together
• Read the "Making GWT Better" document
• No support for reflection / class loading. The tradeoff was for aggressive performance optimisations in the compiler.
• Native javascript can be embedded in Java source
• GWT can be integrated into existing apps
• Several options for automated test support using hosted browser.

Rich Internet Apps with Flex & Apollo

Robert Godfrey's notes:

Flash applications can definitely score in the "wow" factor stakes, the demo'ed applications built with Flex looked pretty slick...Nice to see spring integration catered for out of the box. Other interesting things include:

• the performance test comparing flex to xml & javascript. Flex outperformed XML / Javascript by a factor of 10 when rendering 20000 records in a tabular grid (3 seconds v 30 seconds).
  
• Live in table data editing
  
• Real time collaboration demos showing 2 client sessions being kept in synch via the server, i.e. updates in one session, were shown in 2nd session.

Ruby

James Cox writes a brief summary of the whole track, concluding: "It was great to see Ruby share a platform with other enterprise-oriented tracks, supporting the language's growing maturity and strength within the global marketplace."

Rich Kilmer on Ruby and the Art of DSL

Stefan Tilkov summarizes: Rich Kilmer showed multiple examples of internal DSLs he has built in Ruby, with a wide range of different domains. The first example, which he spent the most time on, was from a air force scenario — the domain was the rules for scheduling and managing the refueling of planes in the air. I think he made a good case for how his DSL, designed practically on the spot when talking to a domain expert, helped him understand the domain very quickly (and enabled him to solve the actual problem much quicker). One pretty cool example was the Java Debugging protocol: he has built a library for Ruby that enables access to a running JVM, and specified the protocol in a Ruby DSL which was then used to generate the code that actually sends the right packets over the net. Pretty neat — apparently, some Scheme folks used his executable definition to generate a protocol implementation for Scheme.

Mongrel, 2500 Lines, and Economics

Stefan also attended the Mongrel talk:

Mongrel, the Ruby web server, is about 2500 lines of code, 6 person months of work. It’s written in Ruby, C, and ragel...A small project with a great impact; e.g. DHH confessed to him that he had about 400 restarts a day at 37signals when using FastCGI; those problems are gone...he came up with the name because he hated Tomcat...Mongrel’s reason for not doing keep alive is because it usually sits behind e.g. an Apache HTTPD...Apple submitted a patch and just expected him to include it — an attitude he calls “code fisting”.

 

.NET

Keynote: Erik Meijer on a new platform for web development

Excerpts from Stefan Tilkov's stream of consciousness: "LINQ is Monad comprehensions from Haskell, implemented in C# and VB. Any programming language could use LINQ (as VB and C# do)...Both SQL and XQuery are data model + query syntax, tightly woven together. The same can be done for OO. LINQ = Queries over arbitrary collections of arbitrary data....Final quote: Programming Language Theory is relevant. But it requires at least 20 years of patience and ripening."

 Tim Anderson summarizes: "The starting point is that users want the same experience everywhere, irrespective of computer platform or device. Meijer’s idea is programmers should be able to code for the easiest case, which is an application running directly on the client, and be able to transmute it into a cross-platform, multi-tier application with very little change to the code....Meijer applies the same thinking to concurrent programming; developers should be able to do this with simple attributes, rather than struggling with synchronization statements and the like. Similar logic applies to state handling: Meijer reckons programmers should be able to program statefully, and have the infrastructure deal with the problems."

We should give programmers the illusion that their servers are stateful, while we can implement that in some scaleable way. That should be done once instead of all programmers trying to solve that problem.

Anders writes:

He focused on how you have to make decisions in your application before you actually would like to make them. When developing a system and implementing the business rules you should not have to think about which client is beeing used (web/thick etc.). You also shouldn’t have to think about concurrency or the back button if you’re doing web.  They’re building stuff like this into LINQ 2.0, and it would really simplify development. That is if it works really good. A lot of people (me included) that I talked to were a bit skeptical about how this will really work and scale.

Michael Hunger's main points:

• Language integration of XML
• Query language within the language
• Datasources not restricted to relational Databases
• Compiler safety for the integrated languages as well as the dynamic classes generated by them
• Tier Refactoring to split single tier methods to be multi tier (e.g. client-server)
• automatic generation of client code for all kinds of environments and virtual machines (windows, flash, javascript etc. leveraging the existing infrastructure at the client)

I don't believe that this works at all for enterprise applications. Their way to complex to be handled by single tier refactorings and synchronized program flow. The focus on Microsoft infrastructure is also not that promising.

Oakleafsystems is also maintaining a linkblog entry of comments about Erik's keynote.

Windows Communication Foundation

Tim comments: "What I learnt is that outside a niche of advanced Microsoft platform developers few people have any clue what WCF is."

SOA: Bridging business and technology

Trackhost Stefan Tilkov wrote a quick summary of the whole track:

Anne Thomas Manes gave a very good talk, especially addressing the question of how to “sell” SOA to management. Paul Downey was excellent, too — his very visual presentation made a great case for the Web as a service platform. Steve Jones had a very different focus, dismissing technology and focussing on the business side, another great talk. Paul Fremantle talked about a lot of different things, but also addressed the REST-vs.-WS-* issue. Jim Webber’s talk was a great (and very funny) conclusion — if I’m not wearing my RESTafarian hat, Jim’s views are very much in line with my personal beliefs.

Jim Webber comments on REST in the SOA track:

What I really found enlightened was the frank and honest admission by the RESTafarians that REST isn't necessarily simple at all. In fact to get properly robust integration you have to have a pretty detailed understanding of HTTP. All of which should sound the alarm for those folks who still confuse REST and POX - the REST jihadis are gunning for you :-)

Banking Architectures

QCon had a whole track on banking architectures. IASA architect Matt Deacon attended and commented on one of the talks:

Technology is the primary business driver in the banking industry” or so Craig Heimark said during his session at QCon today, not that the business is really aware, all they see is the changes in the competitive landscape. However, as he argues this change is driven (although enabled might be a better word to use) by the massive growth of communications challenging and forcing a reconfiguration from centralised vertical models to decentralised models made up of single value specialists. The consequence is to create increased value to the consumer at the expense of margins; the higher the volumes the lower the margin. This leads to mass customisation and the eventual unbundling of services driven by consumer demand.

Adrian Treneman writes about various talks:

its doubly rewarding to see how relevant this stuff is: AMQP is a hot topic right now and the ability to simply configure AMQP in to a pure-Java JAX-WS client or service is really nice. Also, as Sailesh Panchal of Travelex was keen to point out in his presentation, the ability to support XML and SOAP payloads over multiple transports is hugely important in terms of producing really reusable services, supporting both REST and SOA architectures.

 

General comments:

• "[Erik Meijer] is no fan of AOP, doesn’t believe in the usefulness of adding something afterwards which might violate invariants of existing codes. Points to partial methods as an alternative. So in contrast to AOP, the writer of the original code says where someone else can weave his own stuff into."
• TheRegister comments the nature of architects: "an interesting comment dropped by Martin Fowler at the QCon conference this week: 'We sometimes have trouble with the term architect at Thoughtworks, mainly because of some of the people we meet calling themselves architects.'"  TheRegister also mentions books available at the event.
• Interesting sayings overheard at Qcon:
•  Ted Neward - VB enabled managers to write programs. The problem is they really did!
• Obie Fernandez - Ruby has got so much rope you can hang your entire team.
• Attribution is next to godliness :-)
• ThoughtWorks and FowlBots at QCon: "State your designation." "I am 7 of Martin ."
• Stefan Tilkov writes: Two rules I need to remember for QCon 2008:
• Do not mention MDA around Martin Fowler. It makes him leave the party very early.
• Do not get into a discussion about programming language theory with Eric Meijer, Patrick Linskey, and Cedric Beust. Especially not at 2:30 AM after way too many alcoholic beverages ;-)

Opinions about Qcon itself:

• This was the first ever conference for me to attend and I believe it was a great conference to start with! I mean, how can you go wrong with speakers like Martin Fowler, Dave Thomas, Jeff Sutherland and James Coplien, only to name a few - Urban.
• Thank your making QCon what it was. And thanks for the good work with InfoQ. Well done and very informative content. - Jiri Lundak
• All in all it was a great arrangement and I returned with loads of inspiration and motivation that will keep me going for a long time. Thanks!  - Jens Norin
• "the sheer volume of neat ideas and interesting war stories was only matched by the volume of beers consumed" - Jim Webber
• "The amount of new ideas and reinforced old ideas that this conference has provided justifies each euro invested!" - translated from Luismi Cavallé's blog in Spanish.
• "As for the conference, I'm enjoying it quite a bit: the location is absolutely terrific and it's nice to be able to attend non-Java tracks, for a change. Hats off to Floyd, Alexandru and the rest of the crew for a top-notch conference!" - Cedric Beust
• QCon on Friday was interesting, plenty of good ideas and discussion - Dave Crane
• I think it was a great conference, and judging from the feedback I gathered, most people agreed...I had a great time - I had so many interesting conversations, some of them with people I’ve known on the Net for years and only now met in person, as well as with people I just got to know there, that this alone would have been worth attending. - Stefan Tilkov
• QCon feels like a "proper" conference. This might be the inaugural event but it certainly feels like a mini JavaOne style conference. Speaking of Java, Sun held their tech days literally next door to the QEII conference centre (where QCon is) and I met a handful of people that weren't impressed. In fact, a couple of people I know actually came across and bought a conference pass on the door. - Simon Brown
• The tutorial was attended my many people in the same situation as me, project managers/technical architect/team leaders/developers. - Ben
• First QCon came to an end yesterday and it was a pleasure to be a part of it. - Mikael Essle
• Overall yesterday was really good, and a lot of important input. - Anders
• I made it down to QCon on Friday, and was really impressed. The content was really good, with virtually no sales fluff in sight. - Robert Godfrey

Conclusion

QCon was a great success and we are very proud to have been able to offer such a conference, while InfoQ hasn't even reached its 1 year anniversary. It will become an annual event in London, the next QCon will be around the same time next year. We will also be bringing QCon annually in the US eventually, and possibly to other regions InfoQ serves. Thanks everyone for coming and we'll see you next year!!!!

1. Back to top

   transactionless

   Mar 21, 2007 5:23 PM by Floyd Marinescu

   On a personal note, I thought the whole part about eBay running without application-code transactions was a big eye opener. I could be wrong but I think Werner said the same thing about Amazon.com not runnign transactions, and some quote from him saying that to scale you have to design your app not to use them, but don't quote me on that. :)

   Reply

2. Back to top

   Re: transactionless

   Mar 22, 2007 9:29 AM by Tim Hodkinson

   You are right: looking at my notes he said that 2 phase commit was actually a barrier to availability. He also said having a relational database was a barrier to scaleability! It contradicts everything I've learned up until now: I kept thinking of that "Weird AL" Yankovic song "everything you know is wrong" :)

   Reply

3. Back to top

   Re: transactionless

   Mar 22, 2007 9:52 AM by Floyd Marinescu

   Yes that's it, he was referring to not using 2 phase commit. Thanks Tim!

   Reply

4. Back to top

   Re: transactionless

   Mar 22, 2007 11:01 AM by Steve Tekell

   This sounds consistant with me experience with genuinely large scale applications. They were mostly transactionless. We absolutely didn't use EJBs or any container manageded transactions. Some backend processes used two-phase commit, but I don't think anything that would have effected performance from a customers perspective did. While premature optimization can create problems, so can prematurely commiting to follow some bad design like a J2EE blueprint where it becomes practically impossible to optimize it enough later.

   Reply

5. Back to top

   Re: transactionless

   Mar 23, 2007 4:46 AM by Tim Hodkinson

   Which JEE blueprints don't scale?

   Reply

6. Back to top

   Re: transactionless

   Mar 23, 2007 8:24 PM by Steve Tekell

   I don't think the Sun's J2EE Petstore, as I remember it from several years ago, would be an appropriate starting place for a really large scale app. If you start out from the standpoint of requiring an extra transactional tier (EJBs), you have a performance penalty that can't be eliminated.

   Reply

7. Back to top

   QCon 2007 Videos

   May 18, 2007 2:01 PM by Roger Jennings

   According to the QCon 2007 site, "Videos will be posted on InfoQ throughout the year." I'd particularly like to see a video of Erik Meijer's keynote. Roger Jennings http://oakleafblog.blogspot.com/2007/03/20-in-early-returns-from-qcon-2007.html

   Reply

8. Back to top

   Re: transactionless

   Nov 10, 2007 9:46 AM by Nati Shalom

   It's pretty much inline with the research made by Pat Helland: Life Beyond Distributed Transactions Nati S

   Reply

• Older >