Key Takeaway Points and Lessons Learned from QCon San Francisco 2007

In this article, we present the key take away points and lessons from QCon San Francisco directly from the many attendees who blogged about the conference, which took place Nov 7-9, 2007. You can also see numerous attendee-taken photos of QCon on Flickr.

Qcon was InfoQ's second conference (the first QCon having occured March 07 in London) but the first in the US. The event was produced in partnership with the folks who produce the JAOO conference in Denmark. There were 400 badges printed at this first QCon in the US, with 70% of the attendees being US-based, and the majority with team lead, architect, and technology director roles. Over 78 speakers presented at QCon SF including keynotes by Kent Beck, James Noble, Martin Fowler & Richard Gabriel. Going forward, QCon will be an annual event in London every spring and also in San Francisco in the fall.

Bloggers wrote about 32 of the 60 sessions at the event, read this article to learn the most valuable insights the attendees took the time to blog about, as well as many other aspects about QCon.

Table of Contents

Keynotes
   * Kent Beck: Trends in Agile Development
   * Richard Gabriel: Lessons learned from past languages
   * James Noble: The Lego Hypothesis
   * Martin Fowler's Closing Keynote Panel

Architectures you've always wondered about
   * The eBay Architecture
   * Second Life - How it Works (and How it Doesn't)
   * LinkedIn - Lessons Learned on Growth and Scalability
   * Orbitz.com World Wide - An architects response to growth and change

Architecture Quality (Day 1)
   * Architectures of extraordinarily large, self-sustaining systems
   * Strategic Design
   * The Top 10 Ways to Botch Enterprise Java Application Scalability and Reliability
   * Amazon and Hadoop

Architecture Quality (Day 2)
   * Architect for Latency
   * Guerrilla SOA
   * How to Work With Business Leaders to Manage Architectural Change

Connecting SOA and the Web: How much REST do we need?
   * REST Eye for the SOA Guy
   * WS-* vs. REST: Mashing up the Truth from Facts, Myths and Lies
   * Code Talks: Demonstrating the "ilities" of REST
   * Building your next service with the Atom Publishing Protocol
   * A couple of ways to skin an Internet-scale cat

Java in Action
   * Designing for Testability
   * Concurrency, Past and Present
   * Panel: What will the future of Java development be?

Java Emerging Technologies
   * Building DSLs in Static and Dynamic Languages

Challenges in Agile (and how to overcome them)
   * Agile Software Development in the Large

Bleeding Edge .NET
   * What's new and cool in C#

The Rise of Ruby
   * Business Natural Languages Development in Ruby
   * Security (CAS and OpenID)
   * Designing RESTful Rails Applications

Practical Application Security

Tutorials
   * Domain-Driven Design
   * Domain-Specific Languages
   * Certified Scrum Master Class

Vendors

Opinions about QCon itself

Conclusion

Keynotes

Kent Beck: Trends in Agile Development

Michael Nygard enjoyed this keynote:

Kent Beck spoke with his characteristic mix of humor, intelligence, and empathy. Throughout his career, Kent has brought a consistently humanistic view of development. That is, software is written by humans--emotional, fallible, creative, and messy--for other humans. Any attempt to treat development as robotic will end in tears.

During his keynote, Kent talked about engaging people through appreciative inquiry. This is a learnable technique, based in human psychology, that helps focus on positive attributes. It counters the negativity that so many developers and engineers are prone to. (My take: we spend a lot of time, necessarily, focusing on how things can go wrong. Whether by nature or by experience, that leads us to a pessimistic view of the world.)

Appreciative inquiry begins by asking, "What do we do well?" Even if all you can say is that the garbage cans get emptied every night, that's at least something that works well. Build from there.

Alex Olaru saw this keynote as part of a larger theme:

Another important theme during the conference was the rise and penetration of Agile methodologies and finding ways to overcome some of the challenges they bring. This was well reflected as part of a full track on this subject. Probably the best example in regards to this topic was Kent Beck's opening keynote highlighting how trends that have been part of the business world for awhile now (eg. accountability, responsibility, transparency) are starting to make significant inroads into the software industry as well. Another very important note about Kent's presentation was his assertion that software developers need to start making the transition from technical wizardry to behaving more like business partners. In my opinion, there is no doubt that Agile methodologies in a matter of years will hold a central stage among the software development practices and processes.

Srini Penchikala gave a detailed breakdown of this keynote, with points including:

• Kent started his presentation talking about the business trends in the current agile software development environment
• Kent said that "off-shoring" is not a quest for lowering costs, but to find reliable off-shore business and technical partners and mentioned about the quality of projects implemented abroad
• He also said that social evolution and new generation of business professionals are impacting the way we develop and manage the agile projects
• The reliability of software is as important as the reliability of the software development process followed to develop that software
• He talked about two types of skills that are essential to excel in an agile development environment: Social and Technical Skills. He said social skills are more important than technical skills and suggested that every one should learn and improve the listening skills
• Kent also said we need to augment XP with Domain Driven Design (DDD) techniques and follow the usability practices at the same time. For small scale designs, we should use Domain Specific Language (DSL) based architectures
• He concluded the presentation by saying that designing or coding directly shouldn't be the question but what's more important is to ask questions like "what are our principles?" and "what business problems are we trying to solve in the project"

Denis Bregeon also summarized this keynote, and noted:

Some of the questions also yielded useful reminders:

• Agile principles are more important than practices (I take it to mean that what makes you agile is the principles behind the practices you apply)
• When applying agile principles in distributed teams, it is crucial to ensure face to face and social time between the distant members once in a while (something that I have personally found to be very true as it gives you a much better understanding of the values and personalities of your colleagues)

Stu Charlton mentioned a question he asked Kent:

"There seem to be two trends in industry -- the Agile methods movement, which is about Agility as an attitude, and the Agile architectures movement, which is about introducing enterprise-level and "systems of systems" level architectures that help to enable greater agility. The questions are:

1. Do you believe architecture actually can enable greater agility? Regardless of what religious school you belong to, SOA, REST, Data Warehousing, etc.
2. How do Agile teams, with the attitude, build productive relationships with Enterprise Architecture teams, whose goals and attitudes often are at odds with the executing team?"

Kent's Answer for #1 (paraphrasing): "I've always believed that design matters, from the smallest implementation detail, to the largest architectural arrangement of software. Design can enhance communication."

Kent's Answer for #2 (paraphrasing again): "It can be a hard thing, but it's important to recognize that the EA saying 'you can't code without our approval', and the developer having to wait three months, doesn't have to be about a power struggle. There are two different principles and values at play here, both attempting to get to agility. The goal must be to get past the noise of the specifics like 'you need to build things this way' and find a shared understanding of the principles that underlie such decisions. If I, as an Agile team leader, believe in principles like the time value of money, or in the lean principle of flow, I'm going to try my best to ensure that there is a shared understanding of their impacts. Similarly I would hope to understand the principles that underly the EA's decisions and policies. It's the only way to get past the politics."

In a detailed post, Suneth Mendis focused on the convergence aspect:

According to Kent, we are seeing a great convergence of Business Trends and Developing Trends in the IT world. 10 years ago developers didn't really care much about "what the customers want" but rather developed programs they thought useful. It was socially acceptable for a developer to be socially dead and only interact with the computer. But that's changing and changing fast. The business world demands the developers to behave and function in a certain way. Kent thinks that XP (or Agile technologies) addresses these trends extensively and that drives the popularity of XP

The Reg Developer also covered this keynote, including:

"Historically, we have been the wizards," Beck told the QCon Conference in San Francisco, California.

"We could talk, act, and dress funny. We were excused for socially inappropriate behavior: ‘Oh, he's a programmer’. It was all because we knew this technology stuff that other people found completely mystifying," Beck said.

"But this new generation [of users] is much more comfortable with the technology, and that kind of social behavior won't cut it anymore. The world is changing, and I believe that, if I want to stay employed as a programmer, I'm going to have to change with it."

Other comments:

• Ola Bini - On Wednesday, Kent Beck started the conference proper with a really good keynote on why Agile development really isn't anything else than the way the world expects software development to happen nowadays. It's clear to see that the Agile way provides many of the ilities that we have a responsibility to deliver. A very good talk.
• Gunnar Peterson - Kent Beck did a keynote and two of the main points he stressed were developer accountability and transparency

Richard Gabriel: 50 in 50

Michael Nygard described this keynote:

In the evening keynote at QCon, Richard Gabriel covered 50 language topics, with a 50 word statement about each---along with a blend of music, art, and poetry. (If you've never seen Richard perform at a conference, it's quite an experience.) His presentation "50 in 50" also covered 50 years of programming and introduced languages as diverse as COBOL, SNOBOL, Piet, LISP, Perl, C, Algol, APL, IPL, Befunge, and HQ9+

He also enjoyed the HQ9+ programming language, saying:

HQ9+ particularly caught my attention. It takes the question of "simplifying the representation of problems" to the utmost extreme [...]
Of course, in an audience of programmers, HQ9+ always gets a laugh. In fact, it was created specifically to make programmers laugh. And, in fact, it's a kind of meta-level humor. It's not the programs that are funny, but the design of the language itself... an inside joke from one programmer to the rest of us.

Pete Lacey agreed:

I also managed to attend Wednesday’s closing presentation, "50 in 50," delivered by the eminent Dr. Richard Gabriel; a bizarre, delightful, entertaining multimedia romp through the history of programming languages. My favorite? HQ9+.

Stu Charlton also attended this keynote:

Dick's second talk was a repeat of his OOPSLA presentation 50 in 50, a whirlwind tour of many programming languages over the past 50 years, accompanied by music. This presentation is available via OOPSLA podcast, and while it doesn't quite work without the visuals, I recommend it if you're interested in how much creativity there has been out there (and how, we're only starting to regain some of that creativity now after 10+ years of JavaJavaJava). Hopefully the slides will be eventually made available as a Quicktime...

As did Ola Bini:

The day was capped by Richard Gabriel doing a keynote called 50 in 50. I'm not sure keynote is the right word. A poem, maybe? Or just a performance. It was very memorable, though. And beautiful. It's interesting that you can apply that word to something that discusses different programming languages, but there you have it.

James Noble: The Lego Hypothesis

Michael Nygard has a long discussion of this keynote, and described the impact it had on him:

I searched for a great way to wrap this piece up, but ultimately it seemed more appropriate to talk about the contextual impact it had on me. I've never been fond of postmodernism; it always seemed simultaneously precious and pretentious. Now, I'll be giving that movement more attention. Second, I've always thought of mashups as sort of tawdry and sordid---not real programming, you know? I'll be reconsidering that position as well.

Pete Lacey commented on this:

James Noble presented Thursday’s keynote "The Lego Hypothesis." With a somewhat over-the-top presentation style, James said the right thing: Google is our software repository, and developers reuse code snippets and libraries just as people have been saying we should — albeit, without being weighed down by issues like "correctness."

As did Patrick Logan:

James Noble's keynote at QCon this morning. Well done performance on two theories of software around in 1968. The dominant one being software as building lego cathedrals. The other being software as accumulating small, negotiated victories. This is the one we've got and need to embrace. Hopefully there's video of the talk.

Software Development Times also covered this keynote, saying:

Noble believes that the Lego-like construction of programs from reusable parts isn't likely to show up anytime soon. To illustrate this point, he equated objects with Lego blocks, then compared the connecting points on top of the Legos to pointers.

"It's like having a Lego set where every once in a while you come across a piece that has 1 million studs on it," said Noble, explaining the difficulties of Lego-like design. "Or you come across a piece that has only one stud, but has 1 million things connected to it."

All is not lost on the dream of Lego-ization, however. Noble pointed out that, compared with the software developers of the 1960s and 1970s, current developers are already in a Lego-like environment. "Programmers work bottom-up. You start with whatever you can scavenge, steal or Google," said Noble. He went on to explain the differences between up-and-coming programmers and the old guard. "The Google search engine is your primary IDE. This is how software development is increasingly done. We live in a world of software. It's not that kids are better than us; they're just aware of our discipline's success in transforming the world in a way in which we are not."

Martin Fowler's Closing Keynote Panel

Alex Olaru noted one area the panel focused on:

A good amount of time was spent during the closing panel, moderated by Martin Fowler, on discussing how to prepare for continuing to take advantage of increasing hardware processing capacity but keeping in perspective that the growth in speed of CPUs in the near future will decrease and that this paradigm will be increasingly replaced by one that relies on more and more parallel CPUs/cores.

Although a lot of focus has been put during the closing panel into what is the level of abstractions where increased support for multi-core processing needs to be supplemented (language, architecture, applications) in my view the biggest challenge we are facing in the future is more related to changing the "single-thread app" average developer mentality (if such a thing even exists - I do happen to believe though that concurrency/parallel processing are afterthoughts for many developers as they typically rely mostly on the environment or container hosting their apps to take care of that) and put a lot more emphasis on the design patterns aimed at supporting parallel processing. If before, the average application could scale well with time just by relying on faster CPUs, this will probably soon cease to be the case.....

Architectures you've always wondered about

About the track in general, Nati Shalom said:

In The Architectures You've Always Wondered About track, Second Life, eBay, Yahoo, LinkedIn and Orbitz presented how they dealt with different aspects of their applications, such as scalability. There were quite a few lessons that I learned that day that I thought were worth sharing.

The eBay Architecture

Nati Shalom had the following notes:

There were quite a few (LinkedIn, eBay, Orbitz, Yahoo Bix) that use Java as their core language [...]
If I recall correctly, only eBay uses the full J2EE stack, but they seem to be using only a very small part of its functionality [...]
Integration is a big issue for all of these sites, typically because of acquisitions. In the case of eBay and Yahoo, the companies they bought were built with different architectures, and in many cases, different implementation stacks [...]
A great deal of effort was made on enabling a common user identity management system (Single Sign-On), as well as a load-balancing scheme. eBay chose Apache as their common module and extended it quite a bit with their own modules [...]
According to Dan Pritchett (eBay), with their enhancements you can do with MySQL pretty much the same as with an Oracle database.

Geoffrey Wiseman had a detailed summary of the talk, and his major takeaway points were:

• Partition everything - Both functional and horizontal segmentation are used, application servers are load-balanced and pooled, BASE principle used (instead of ACID), no session state server-side
• Asynchronous everywhere - this enables retries, isolates user from performance issues, and allows spreading of cost of load over time
• Automate everything - Machines are cheaper and scale better than humans, so adaptive configuration and machine learning are employed
• Remember that everything fails - Anything can break at any time, so eBay logs heavily (1.5 Terabytes a day), does comparisons with past failure scenarios, ensures every change can be rolled back, and everything can be turned on or off through central configuration

Alex Olaru described how the presentation changed some of his previously-held beliefs about large scalable systems:

I thought that things like:

• XA coordination for apps working with multiple resources
• using a database extensively as the main/only reliable holder of system of record data
  
• never having any entities go out of sync in different systems, even for a short amount of time
• processing large chunks of business logic as one synchronous unit of work

are good items that can and should be part of the arsenal of technical implementation choices that one would consider when building high-volume systems.

As many of the presenters showed, it turns out that systems that can massively scale can be built without using any sort of XA coordination, by breaking up long running transactions into multiple process flows/short-lived transactions that can be chained through asynchronous messaging, by using database mostly for write activities and serving read requests from data loaded into memory or by mirror databases, by avoiding state management at the application server level and abstracting the hardware implementation details in the application layer to allow for automatic fail-over and by partitioning data as much as possible. These types of implementations do require however up-front and careful thought in regards to how the application needs to be designed and changes in the mindset used when approaching development of high-volume applications.

Martin van Vliet also found this presentation enlightening:

Randy Shoup discussed eBay’s architecture in more detail. His presentation [...] highlighted the strategies eBay uses to scale their application. By applying functional segmentation (dividing the application by functionality) and horizontal split (for each piece of functionality, use multiple instances that are interchangeable) their architecture is able to scale to the required number of users. When you’re dealing with sites this size (to give you an idea, eBay has 16,000 application servers and produces 1.5TB log data per day) everything is custom — deploying new versions of the application, analyzing log files, persistence of data using partitioning, eBay uses custom built tools for everything. Very interesting to see, even if we don’t all build applications of this size.

David Forbes also commented: "eBay by Randy Schoup - so well done. Randy lays out the agenda, introduces each topic, drills down, then reviews the topic to completion."

Second Life - How it Works (and How it Doesn't)

thier.ca described their impressions of this talk:

What set this apart was that he covered how their architecture evolved over time, what mistakes were made, and how they solved them. I find sharing mistakes more insightful than successes. Almost anyone can read a few books and sketch out what should be a decent architecture (not that it would necessarily work, though). But, seeing the problems others ran into while trying to apply those principles in the real world is very useful.

David Forbes said: "Second Life by Ian Wilkes - one of my favorite hours of the week"

LinkedIn - Lessons Learned on Growth and Scalability

Geoffrey Wiseman took several notes, including:

• Their current architecture contains Java, Oracle 10g, MySQL, Spring, ActiveMQ, Tomcat, Jetty, and Lucene - they are also doing experiments with Ruby and adding C++ in a few places
• Relational databases are poor for complex graph computation, so relationship algorithms are run on RAM-based graph
• Rather than keeping RAM database in sync with RPC or JMS, LinkedIn logs all changes to a transaction log which is pulled into RAM by each graph engine
• This structure makes traversing graphs much less painful, easing both breadth-first traversal and symmetric connection detection for finding shortest path between two people
• After encountering issues with Read/Write locks, Copy-on-Write was adopted

Orbitz.com world wide - an architects response to growth and change

Orbitz uses Jini as part of their backbone, according to Nati Shalom, who also shared that "Orbitz uses Jini as their service framework, and did interesting work with Spring to abstract Jini from their developers. They also developed remoting functionality with Spring to abstract their services interaction." Pete Lacey Writes:

Brian Zimmer, lead architect at Orbitz, gave a talk on the Architecture Track about growing Orbitz both from an infrastructure and design viewpoint as well as from a U.S.-centric to a globally-capable system. Brian was a good speaker, but I can't say I learned much. Rule #1 seems to be, don't code yourself into a corner with U.S.-centric assumptions. Rule #2 seems to be don't architect yourself into a corner with bad design choices. Both true. Both hard. But what really moved this talk from "green" to "yellow" for me, was his discussion on caching. In order for Orbitz to not beat the crap out of their partner's systems, they cache results for a period of time (presumably based on SLAs, since there's no cache control info on the wire), but their original, home-grown, caching solution didn't scale. Brian described this system via the metaphor of a block of mailboxes that you might see in a post office or apartment building that could only hold so much information and only for a specific partner. And my thought was, well, who the heck designed that? They resolved the problem by purchasing a commercial caching solution, but he wouldn't say which one.

Architecture Quality (Day 1)

Architectures of extraordinarily large, self-sustaining systems

Ola Bini attended this talk:

Richard Gabriel delivered an extremely interesting presentation on how to think about ultralarge, self sustaining systems, and how we must shift the way we think about software to be able to handle large challenges like this.

Stu Charlton had a fairly detailed summary of the talk, including:

So, assuming a system that was trillions of lines of code, millions of elements, thousands of stakeholders, beyond human comprehension, and must provide advantages over an adversary, how would you design such a system? [...]

Dick Gabriel explored three approaches to design:

1. inverse modeling is tractable -- meaning, we can work out the design of the system top-down, and in advance
2. inverse modeling is intractable -- meaning, stepwise refinement (ala. 'agile design')
3. evolutionary design -- wherein we use evolutionary techniques, such as genetic algorithms, to "grow" a solution. The design is indistinguishable from the implementation this case.

Denis Bregeon described some thoughts that arose from this talk:

I was also puzzled by the expression evolutionary design. Which seems like a complete contradiction in terms, for which I will have to seek clarification from Richard Gabriel (because I was too shy to do so at the conference). I am saying this because he correctly pointed out that humans have a specific way to explore a solution space (canalized which is exactly what design is). To me evolution is another way of exploring the solution space. Random is another one.

Which should yield the conclusion that we don’t design such systems. We build them with intent but without design.

Strategic Design

Michael Nygard shared his thoughts:

Eric Evans, author of Domain-Driven Design and founder of Domain Language, embodies the philosophical side of programming.

He gave a wonderful talk on "Strategic Design". During this talk, he stated a number of maxims that are worth pondering.

"Not all of a large system will be well designed."
"There are always multiple models."
"The diagram is not the model, but it is an expression of part of the model."

These are not principles to be followed, Evans says. Rather, these are fundamental laws of the universe. We must accept them and act accordingly, because disregarding them ends in tears.

Geoffrey Wiseman commented:

This was a good talk, although he's a measured speaker rather than overflowing with energy. Still, he's a clear communicator, and there were some interesting points. I particularly liked the metaphor of maps as models. His anecdote about pudding, which relies on the language context (american pudding: goey custard-like dessert; british pudding: any dessert) was also entertaining. Some of the detailed elements seemed vague, but it was still enjoyable.

Denis Bregeon also mentioned:

I have to admit that the term Domain Driven Design was a bit fuzzy and this talk did a good job at clarifying what it means. Essentially it means that when you build software you effectively build a domain model as well (whether implicit or explicit) and that you should pay attention to that.

In particular, the domain model you build is partial on the domain itself. It reflects some of the views you (and hopefully) your users, take on the domain. It serves the specific purpose of building a shared representation of the domain with your users. All that circled back neatly with agile and embedding the customer and all those good things.

The Top 10 Ways to Botch Enterprise Java Application Scalability and Reliability

Michael Nygard took particular interest in one of the points which was made:

While I could quibble with Cameron's counting---there were actually more like 16 points thanks to some numerical overloading---I liked his content. He echoes many of the antipatterns from Release It. In particular, he talks about the problem I call "Unbounded Result Sets". That is, whether using an ORM tool or straight database queries, you can always get back more than you expect. [...]
The fundamental flaw with an Unbounded Result Set is that you are trusting someone else not to harm you, either a data producer or a remote web service.
Take charge of your own safety!

Be defensive!

Don't get hurt again in another dysfunctional relationship!

Geoffrey Wiseman had praise:

I'd seen this presentation (or a heavily related one) before, but he's such an entertaining speaker, I didn't mind seeing it again. He's also not afraid to stir up a little humorous controversy: taking a shot at Bob Lee and calling FTP the precursor to SOAP.

Amazon and Hadoop

Denis Bregeon described his thoughts:

I am still struggling to make sense of all the possibilities that what he presented open. Essentially, amazon rents virtual servers by the hour at a very affordable price.

Which opens very heavy computing to any small company or individual. You can even build custom images for your servers. Some services actually offer to run you whole infrastructure on rented virtual servers.

In terms of business it could really break the price barrier to a lot of markets where you occasionally need heavy computing power (did I say financial industry) as it removes the need to build an under used data center. I fully realize that this must be a temporary solution (because your exposure to a single service provider would be too high) and that some questions need to be adressed like data confidentiality and integrity before this becomes a reality.

Architecture Quality (Day 2)

Architect for Latency

Michael Nygard wrote up a detailed summary of this presentation, including:

Dan Pritchett, Technical Fellow at eBay, spoke about "Architecting for Latency". His aim was not to talk about minimizing latency, as you might expect, but rather to architect as though you believe latency is unavoidable and real.

We all know the effect latency can have on performance. That's the first-level effect. If you consider synchronous systems---such as SOAs or replicated DR systems---then latency has a dramatic effect on scalability as well. Whenever a synchronous call reaches across a long wire, the latency gets added directly to the processing time [...]

Instead of ACID semantics, we think about BASE semantics. (A cute retronym for Basically Available Soft-state Eventually-consistent)

Martin van Vliet commented:

eBay architect Dan Pritchett described how their architecture deals with latency. Instead of using ACID for their application, ensuring atomic and consistent data at all times across all databases, they employ the BASE (Basically Available, Soft-state, Eventually consistent) paradigm to improve availability and response time by sacrificing consistency and atomicity.

Guerrilla SOA

Jim Webber discussed his presentation and the ideas behind it:

While I was at QCon, I filled in on a slot on the architecture track to talk about Guerrilla SOA. Michael Nygard (of "Release It!" fame) perhaps nailed it best at the QCon party the night before the talk: Guerrilla SOA is just commonsense. The talk seemed to go down well with the audience and we had some great Q&A at the end, particularly Dan Pritchett of eBay fired in some interesting questions on how to scale-out the Guerrilla approach with decentralised services to eBay scale and explained how technical governance at that kind of scale is hard.

I also welcomed Jeff Schneider's assertion that "... the idiots that are running around yelling "guerrilla SOA" have to be put in their place." Oh yes, I certainly did. While I don't agree about the idiot part, or indeed the putting them in their place bit either, it was heartwarming to discover I'm not the only alleged idiot advocating delivery-centric, incremental SOA.

One by one your services will be stripped from the clutches of enterprise architecture and governance teams and returned to the (business) people. La lucha continua!

How to Work With Business Leaders to Manage Architectural Change

Software Development Times discussed this talk:

Hohmann began his talk by revealing an exercise he uses when he is first called in as a software development consultant: He asks everyone on the development team to draw his or her view of the architecture.

"The only rule is: You can't talk to anyone else at the table," said Hohmann, describing this exercise. "The teams that are considered high-performing teams—they draw the same picture. The teams that are struggling draw all sort of different things. Architecture, from a human perspective, guides behavior internally. When they're sitting at the keyboard, the architecture they hold in their head is what's guiding their behavior, independent of what the architect puts on the wall," he added.

Hohmann also espoused the benefits of a good road map. "I think of architecture as being very organic. Some architects manage architecture as if it were a city street system. They come in and survey and plan and pave roads, then they come back in five years and maybe fill a pothole," said Hohmann. "My perspective is that it's more like a Japanese garden. I'm going to come in, make a plan, then it's going to change and grow and adapt. Some things will be there for a long time, but much of it is based on weeding and managing and changing."

Connecting SOA and the Web: How much REST do we need?

The main points that Jeevak Kasarkod left with were:

1. RESTful applications have design constraints which helps build better distributed systems as compared to SOA where there are no constraints but only desired outcomes defined
2. WS-* is being bashed for complexity which is bogus because its complex for a middleware vendor to implement but not for an application developer. For an application developer it is similar to an aspect. Most of the complexity stems from databinding tools
3. Web services are not popular because of WSDL. WSDL is operation centric rather than being document/message centric and more importantly it does not specify the sequence in which the operations need to be invoked. It seems SSDL does a better job at this
4. WS tooling is incorrect since it tries to mask the complexities of a distributed system instead of exposing the developer to its vagaries so that he can program for it. I still feel this is open for debate and finding the right balance between code generation and exposure to the vagaries of a distributed system is necessary
5. Expose as many URLs as possible in a REST application instead of overloading few URLs with functionality
6. Use a web framework which natively supports RESTful design. Working around the constraints of struts is cumbersome compared to using a framework such as rails. I find that argument compelling for SOA applications too (probably the answer lies in SOUI)
7. Atom Pub Protocol is a viable alternative to creating and editing web resources
8. WS fakes run-time type safety and there is no way to guarantee compile-time safety
9. Use XHTML as the media type in REST because various clients other than the browser natively support it. Pete Lacey demoed this and he was able to open the same REST URI in excel and word to display the data. With XHTML you are also able to Xquery it and with microformats you can introduce semantic meaning to it
10. Lastly buy the O'Reilly "RESTful web services" book since there was unanimous recommendation for it

Several bloggers discussed the track as a whole, including Steve Vinoski:

In the SOA track, it was most excellent to finally get to meet Patrick Logan, Stefan Tilkov, Pete Lacey, Jim Webber, Stu Charlton (thanks again for the Dew, Stu!), and Mike Herrick in person, as well as to get to meet up again with Sanjiva Weerawarana, Glen Daniels, and Dan Diephouse. All in all the SOA/REST track was highly informative, with solid presentations through the whole day. Pete’s was especially cool due to the demo he gave of the extreme flexibility and integrability of REST-oriented solutions. It was also reasonably fun, given how much the attendees got into it with their questions, and especially due to Jim’s presentation at the end in which he mixed some serious technical chops with very funny one-liners popping out every second or third sentence.

Mike Herrick described the track as:

The presentations / discussions were great. I learned a couple new things. It was definitely the best conference I have been to in a long time.

Having dinner with Dan Diephouse, Stefan Tilkov, Steve Vinoski, Sanjiva Weerawarana, Pete Lacey, Glen Daniels, Jim Webber & Patrick Logan was also a lot of fun. I have known many of them virtually for a long time. It was nice to talk in person and share some great laughs.

Jim Webber had words of praise:

So many times when I've attended conferences with "SOA" in the agenda have I been disappointed by the sheer amount of "blah blah blah" that has crept into the content. This year's second QCon conference in San Francisco had an SOA track which was anything but "blah blah blah." Over the course of the day Stefan Tilkov presided over Steve Vinoski, Sanjiva Weerawarana, Pete Lacey, and Dan Diephouse, as they belted out some of the most intensely interesting and intelligent talks on Web Services and Web-based services that I have been privileged to hear.

In the audience the like of Stu Charlton, Glen Daniels, Patrick Logan, and (from time to time) Martin Fowler and my other ThoughtWorks buddies Josh Graham, Chad Wathington, Ola Bini really upped the ante with seriously good questioning and input into the very open-format talks.

Daniel Diephouse had the following thoughts:

The other talks at the QCon SOA track were great. I thoroughly enjoyed all of them and it was probably one of the best tracks I’ve ever attended. Some highlights:

• Sanjiva being heckled in every talk about WSDL
• Pete Lacey’s discussion of Microformats. I don’t know that it all really clicked for me until yesterday.
• Jim Webber’s non-family friendly version of REST which was hilarious
• Steve Vinoski’s use of the word serendipitous which will most certainly be a larger part of my vocabulary now

The track was also described by the Software Development Times:

The San Francisco conference organizers probably saw this coming, having labeled one track "How Much REST Do We Need?" As speaker after speaker took the podium to discuss WS-*, invariably the REST fans in the audience would ask pointed questions, or insist that "you can do that in REST too." When REST users spoke, the WS-* faithful in the audience returned the favor, pointing out the limitations of REST's simplicity or the lack of standardization within the REST world.

Other comments:

• Patrick Logan: "That whole day was great fun and engaging. The combination of speakers was pretty much a full complement of who you'd like to hear address the issues from any of the perspectives"
• Stu Charlton: "The REST track, hosted by Stefan, was great fun -- Floyd mentioned to me that the track in London wasn't so packed, but the room in San Fran was standing-room only for some of the talks"
• Pete Lacey: "From my POV, it was a fantastic two days. All of the RESTians on the SOA track had excellent (if somewhat overlapping) presentations. The lone non-dyed-in-the-wool REST proponent, Sanjeeva, had a—uhm, err, shall I say—provocative presentation"

REST Eye for the SOA Guy

Stefan Tilkov wrote down comprehensive notes on this talk, and some points of note were:

• SOA is comprised of loose recommendations that essentially reiterate elementary software development practices
• REST is hypermedia, but not only suitable for browsers
• REST focuses on fully hetereogeneous distributed systems because that’s what "large-scale" implies
• Summary: SOA is about IT culture and organizations, not architecture

Jim Webber appreciated some of the incorrect SOA acronym explanations which were made:

Right now Steve Vinoski's giving his excellent "REST Eye for the SOA Guy" talk and he's pressing what SOA does not mean. He's given us these absolute gems:

• Scrap Old Applications
• State Of Art
• Special Object Annotations
• Same (vendor) On All
• Scalable Optimal Architecture

I cannot help by agree wholeheartedly with these, especially the points around Special Object Annotations (exposing your domain model via attributes or annotations to the world) and Same (vendor) On All because you really don't need a vendor to do good SOA anyway. Excellent stuff, and I think there's more to come...

Jeevak Kasarkod summarized this talk as:

The first few slides of the talk were common ground and have been reiterated in a number of talks and blogs on SOA: what SOA does not mean and the architectural constraints of REST. The rest of the session dealt with each of these constraints (except the code on demand constraint) and quoted standard responses from SOA guys (depicted as a guy with a bow tie and glasses in the presentation material) to these constraints: a good approach to presenting introductory material for this track. The key takeaway from this talk was that RESTful applications provide a good design framework for a web application but it must not be abused and that the arguments from SOA proponents are either plainly not true or they are not relevant

WS-* vs. REST: Mashing up the Truth from Facts, Myths and Lies

Stefan Tilkov also described this talk in detail, including:

• Sanjiva claiming he’s unbiased, and if he’s biased, it’s because I told him to be :-)
• if HTTP(S) + XML is enough for the problem, more power to you
• WS-* programmers need to understand XML, XML Schema, WSDL and WS-Policy - if they tell you otherwise, find better software
• Sanjiva’s Advice: don’t get caught up in the hype

Jeevak Kasarkod had these thoughts:

Sanjivas talk was by far the most controversial. Some of the controversial remarks which made the RESTafarians squirm in their seats

• WS-* is complex is a myth. The only complexity if any maybe related to databinding
• WS-* is necessary to provide a standard for message signing, reliable messaging, transactions etc instead of everybody doing it their own way
• REST is not easy to learn and one needs the knowledge of atleast a dozen RFCs and standards
• Hypermedia as the engine of application state is beyond the understanding of normal people
• REST needs an IDL. This is necessitated by tooling which in turn is necessary
• WSDL 2.0 can describe any REST service
• REST is not multiprotocol

Some responses from the audience were

• WS-* is complex. Patrick Logan commented that it is difficult to get even the basic stuff to work
• The RFCs and standards that you need to understand REST is a subset of whats needed for SOA
• Hypermedia as the engine of application state as a phrase is complex but the content it expresses is easily consumable

thier.ca adds:

The REST vs. SOA talk given by one of the creators of SOAP. Most of the talks were REST-oriented, but this one was most interesting because the entire room full of people was hammering him with questions and counter-points and he fielded them very well. He dove down into very technical details of why each style works the way it does. To me, honestly, this whole religious war between REST and SOA feels very contrived because each has their use. The speakers I saw that I respected the most acknowledged each has their place

Code Talks: Demonstrating the "ilities" of REST

Once again, Stefan Tilkov took detailed notes, such as:

• Degrees of RESTfulness - adding and removing constraints is perfectly fine, but for every constraint, there is a trade-off
• Rule #1: Everything of value is URI addressable
• use descriptive URIs for human accesibility
• The URL to a RESTful API should lead the developer to a Web app

Jeevak Kasarkod said:

Petes talk reiterated the constraint definitions for a RESTful service with a single table which I found particularly useful [see here]. The point he made with it is that services which comply with all of the constraints are RESTful but if they relax or add constraints they are less RESTful or more RESTful.

He proceeded to describe how to easily acquire and modify information and functionality through REST services. Most of the best practices defined were related to URI definition and its sanitization. I felt the demo with a sample expense reporting application clearly made his point on how to leverage XHTML as a media type in the REST URIs. He could POST to resources using curl and was able to consume GET responses in clients such as excel and word.

Building your next service with the Atom Publishing Protocol

Stefan Tilkov again provided a detailed summary, with points such as:

• Atom specifies how to edit, delete, create, resources in collection
• why use Atom? Atom is widely understood, adds ubiquitous elements which have meaning across all contexts - summary, content, updated date, ID, links
• AtomPub guarantees that you’ll follow RESTful best practices
• Thoughts on GData: does it expose a weakness (AtomPub is not enough) or a strength (can be extended)? Dan thinks the latter
• When not to use AtomPub: when data is not time-indexed, universality doesn’t yield any benefits, batch, performance, messaging may be a more appropriate model, hierarchy kinda sucks, transactions
• Is AtomPub the one true protocol? no, but it can be applied in a wide variety of business apps

Jeevak Kasarkod also added some thoughts:

My exposure to Atom is as limited to the syndication feed structure and I expected to learn quite a bit about the publication protocolfrom this talk. However after having sat through it though I have a better understanding of the specification it would only start to make sense once I get my hands dirty with it. The protocol is based on the HTTP verbswhich is the basis for REST so it felt like a natural extension to Petes talk. The focus in APP is collections and performing operations (GET, PUT, POST and DELETE) on its member resources. OpenSearch and GData were discussed as available implementations of APP. OpenSearch is search focused and as Dan described it as WSDL for search. GData feed structure is an extension of RSS and Atom and the publishing protocol conforms and extends APP. The batch operating mode in GData has not been well received by the community and there was an interesting discussion around how it should be implemented (suggestions included piping through a single connection or using a super-resource as the point of update). Based on the weakness of APP, Dan had the following scenarios when APP should not be used:

• Data is not time indexed
• Universality does not yield any benefits
• Batch
• Performance
• Messaging may be a more appropriate model
• Hierarchy kinda sucks
• Transactions

A couple of ways to skin an Internet-scale cat

Stefan Tilkov gave the following description:

Jim Webber was way too fast, and way too funny, for me to take any notes — still, just to ensure I’ve treated all of "my" speakers equally, here’s a quick summary: Jim split his time equally between

1. ensuring we’ll have to add a "parental guidance required" warning to his video once it’s online on InfoQ
2. insulting WSDL 1.1 (and WSDL 2.0) as well as its creator Sanjiva Weerawarana who was sitting in the row just behind me
3. creating fits of laughter, esp. for Steve Vinoski (who was sitting next to me)
4. presenting some really great technical content
Initially, Jim talked about his view that MEST-style Web services are actually very useful, and that it’s the RPC concepts induced by WSDL that turn Web services into a mess. Then he spent some time assaulting both URL-RPC-style and POX-style HTTP misuses, although he found something positive in both — specifically, the fact that they’re dead simple to use. After a brief overview of the REST style, he showed an example of the use of hypermedia to drive the application’s state.

This was easily the most entertaining talk of the track, and I think it was a great way to conclude the day.

Jeevak Kasarkod agreed with Stefan:

Jims presentation was definitely the most hilarious and the ideal one to conclude the proceedings for the day. He claimed to be a fence sitter but it seemed like he clearly favored REST. His core argument is that the Web provides inherent robustness and applications should be designed to leverage the strengths by adapting to a similar model. This was further emphasized through the statelessness constraint and how it applies to a workflow model. Pasted below is his web friendly workflow model

What happens if workflow stages are modelled as resources?
And state transitions are modelled as hyperlinks or URI templates?
And events modelled by traversing links and changing resource states?
Answer: we get Web-friendly workflow
With all the quality of service provided by the Web

Apart from the constant reminder that WSDL is an abomination there were a couple of interesting points he made regarding web services

• WS toolkits provide a leaky abstraction over distributed systems in the attempt of hiding its complexity. It would be ideal to leverage the inherent robustness of the Web to build systems rather than treat it just as transport
• WSDL can only theoretically augment BPEL and the tool support is limited. Business processes are message oriented but WSDL is operation centric. This leads to only conversation state being exposed to the end user and the resource state is hidden

Java in Action

Designing for Testability

Alex Olaru had some questions answered by this talk:

I came to this conference though with a few questions and concerns about some of the practices advocated as part of the Agile current. Many of them were answered in the various sessions but some of the tougher ones did not really get addressed until I saw a presentation given by the TestNG guys (Cedric Beust and Alexandru Popescu). I had a sense of relief when I heard some more pragmatic answers to real-life questions like: "Should I test first or last?", "What should my test coverage percentage be?", "Can pair programming really work in my organization?". I thought first that they were just able to provide the answers that I was subconsciously and conveniently looking for so I got their book too - Next Generation Java Testing, co-authored by Cedric - and after reading a few chapters I realized that they are really on to something good here.....

thier.ca shared some thoughts:

Designing for testability. They didn’t go into enough details and examples, in my opinion, but the talk was still good. Anything which increases awareness that we do have to put a little thought into how code we write will be testable is good. And, any person who puts on a slide that "Statics are evil" is a winner in my books

Concurrency, Past and Present

Ola Bini was impressed:

The afternoons sessions was dominated by Brian Goetz extremely accomplished presentation on concurrency. I really liked seeing most of the knowledge available right now into a 45 minute presentation, discussion most of the things we as programmers need to think about regarding concurrency. I am so glad other people are concentrating on these hard problems, though - concurrency scares me.

Jason Brown also enjoyed this talk:

At the QCon conference in San Francisco two weeks ago, I heard Brian Goetz speak about concurrency, it's past and where we're at now. It was a really great session (I should probably blog about it in the future), but one of the problems he identified with the concurrency in Java is the notion of shared state between threads. Long story short, some alternate approaches to concurrency and safety include the techniques that functional languages like Erlang and Scala are taking.

Panel: What will the future of Java development be?

This panel was probably the most talked-about event at QCon, with many sites discussing it. Several of the postings point at the blog entry which Obie Fernandez made describing the panel's discussions, which included notes such as:

• I love panel discussions at conferences, especially when they are forward-looking and generate tension in the participants
• I heard at least one comment in the party later on from someone asking why Rod was included in the panel, since he's not really a language guy. Personally, I felt he injected the most tension, so I was pretty happy with the choice. Erik Meijer was also an intriguing guest for the panel, since his claims to fame have nothing to do with Java. Still, as a notable "language guy" his input provided insight and entertainment
• Erik kicked off the panel with comments along the lines of LANGUAGES ARE NOT IMPORTANT [...] [Rod Johnson] agreed with Erik that languages are not the most important thing. He asserted that tooling and the language ecosystem are much more important, using .NET as an example. C# is not the important part of .NET, it's the assumptions that come with the framework
• [Joshua Bloch's] initial comments were about "Java entering middle age" and he made some funny comment about not wanting to see it have a crisis and do silly things. He also stated that Java is beginning to show its age, a theme that would resurface later in the panel
• Charlie Nutter of the JRuby project spoke next and as expected, immediately disagreed with the other panelists on the importance of language. "Without Ruby we wouldn't have Rails." He firmly told the others that Java needs to eliminate their ivory tower model
• The first question was "How will the APIs grow in the future?" [...] [Rod Johnson] claimed that negative growth is needed and used AWT as an example. He actually asked for a show of hands to know who has used AWT lately -- nobody in the room (maybe 100 people) had used AWT lately
• Erik states matter-of-factly that it is impossible to take things out of a mature platform. "You can never take anything out!"
• Joshua Bloch is saying we should create a new Java platform. Everyone agrees that there are real dangers in choosing that road
• An audience member detects a tension in the move to dynamic typing. Josh suggest that it would be better to have static analysis available as an optinal component of the system. Rod brings up questions about the loss of data (?) in dynamic typing. Charles defends Ruby-style typing and Josh expresses pretty strong emotions about the safety of statically-typed systems, which leads Erik to make comments about "too much dogmatism" on questions of type
• Ola Bini (from the audience) asks about [...] new language features for Java. Josh asserts that as a mature language, Java should not get all the syntactic sugar that has been proposed for it. He has real worries about Java already being seen as too complex and changing too rapidly, and that Java might lose its appeal to academics and educators
• In one of the more amusing exchanges of the panel, Rod Johnson accuses Google of having more influence of the JCP than members of the open-source Java community, and Josh calls the accusation "utter hogwash"
• Charles reminds the audience that despite complaints about Java moving too slowly, it's actually a good thing. Chet defends the JCP and says it has come a long way (from when it was dominated by vendors?)
• Getting back to language complexity, Ola asks that if you need tooling to use a language, isn't it already broken? Josh drops the admittedly "embarrasing" revelation that he still uses Emacs sometimes. (That isn't embarrassing in my opinion! OF)
• In closing, Charles Nutter asks for better application-level APIs and Erik Meijer says "DSLs are a disaster waiting to happen"

Chet Haase, who was a speaker on the panel, also discussed his favourite question:

I wanted to just repeat my favorite question that came up that evening. It was in my original article for The Register, but it got edited out (maybe it was too off-topic). Lucky for me I have this other outlet specifically designed for off-topic topics. So here it is:

"A good language changes the way we think about programming. What language change would you like to see that would change the way we think?"

I found the question itself confusing. I mean, if I could imagine something that would change the way I thought, then wouldn't I already think that way? It seemed like I could easily fall into an infinite recursion loop, overrun my stack, and have a brain fault.

All of us had to answer that one, so I mumbled out something about improving the overall platform (not just the language). But mostly, I was busy trying to reboot my brain.

Pete Lacey also attended:

[This panel] had Chet Haase, Erik Meijer (LINQ), Charlie Nutter (JRuby), Joshua Bloch (large pieces of Java), and Rod Johnson (Spring) debating the future of Java. Everyone was (obviously) knowledgeable and pragmatic. They did not, however, all agree. I felt myself leaning towards Charlie’s answers which can be summed up as "it's up to you, now."

As did Alex Olaru:

The track concluded with a heated debate, at times, during the "The future of Java development" panel - there is no such thing as a good panel without a little bit of dueling:). In my view, this panel's discussions led to the general observation that Java is a very mature language and itself needs to become more "agile" in order to be able to keep and increase its viability among the languages of the future.

As Joshua Bloch mentioned, Java needs to adopt those improvements that bring the largest amount of benefit to the users with the least amount of changes in the language while Rod Johnson put emphasis on staying in tune with the Java community needs and where possible making changes to support the "peeling off of the crusty layers" from the Java platform (I believe the Java CORBA APIs came up on the top of that list of layers:).

And Geoffrey Wiseman:

Finally, a panel discussion on What will the future of Java be? was really great. There was a lot of hunger in the room to see Java evolve in some fashion, whether or not it's part of its current platform, or in the shape of a new platform on the JVM. The panel was well-comprised with different viewpoints, and there were some pithy comments and good debates.

Joshua Bloch opined that Java is mature, and shouldn't go around in a pink miniskirt and pierced navel, but rather continue to evolve in a very measured fashion, making room for a new platform on the JVM, one that solves some of the existing fundamental problems. This was an interesting perspective, but I wish I could see evidence that there was serious effort being put into this concept (sorry, Charles Nutter, I don't think JRuby's that solution, as interesting as it is). A fair amount of time was spent talking about static/dynamic languages and backwards compatibility and the size of the Java download. Erik Meijer concluded with an interesting statement about DSLs: a disaster waiting to happen. This was probably my favorite session so far, both the topic and the speakers were great. Well worth watching when InfoQ puts it up.

Martin van Vliet saw this panel echoing a larger theme:

QCon provided a broad view of enterprise IT, not focusing on one language or platform. Instead, tracks on advances in both .NET and Ruby were presented and well attended. To underline this, participants in a panel discussion on the future of Java (which included Joshua Bloch and Charles Nutter) agreed that the Java language itself will become less important than the Java platform. Languages like JRuby and Jython are maturing and gaining in popularity. Rather than languages, tools and frameworks will determine which computing environment will "win" in the long run

Some online publications also discussed this panel, including O'Reilly:

Obie Fernandez has a great write up on the Future of Java panel at QCon with Chet Haase, Charles Nutter, Rod Johnson, Josh Bloch, and Erik Meijer [...]

One of the things I hope is that OpenJDK will make possible big changes. Once there is an open source Java 7 that still runs Java 1.0 code, it can be there and be maintained for people who want that forever. Java itself can then move forward, perhaps even to Java 2 (:P) with real generics, adding some bloody keywords (@interface still makes me hate people), and other things that we haven’t been able to do because of this legacy requirement.

And Reg Developer:

Fundamental divisions over whether Java should be fattened up or have bits ripped out to suit changing requirements have emerged at an industry show.

A panel of industry experts at Qcon in San Francisco agreed Java should be left to enter its middle years without major changes and the industry should look for a "new language, soon". [...]

So just whose to decide what's in and what's out? The community. Ah, the wisdom of crowds.

"We should ask the users [what they want] rather than making assumptions," Johnson said. "[We] shouldn't assume people don't want to make some effort if they see it's worth it in the end."

And that's where Sun's OpenJDK could come in, according to Nutter "There's noting to stop anyone developing their own version of the OpenJDK. As we see more and more of that, it's going to feed back into the [standards] process, and we will know if people want us to pull things out."

Which covered the panel twice, with the second article written by Chet Haase:

I see Java's evolution more in terms of the overall platform, not just the language. The platform improvements that I look forward to most include simplification of the deployment of the Java platform, like what we're doing with the upcoming Update N release. I said I would also like to see further improvements in the platform libraries, to offer increased functionality and easier programming paradigms [...]

I personally feel Java still has a long life, so it is worth continuing to work on and improve what we have. And given limited time and resources, it seems like we'll do better by focusing the efforts on that problem for now, rather than giving up and starting afresh.

Having said that, if and when we (meaning Sun Microsystems and the larger community) have time, it would certainly be worth thinking about some future platform as well.

Java Emerging Technologies

Building DSLs in Static and Dynamic Languages

Martin van Vliet had some thoughts:

While not a separate track, DSL (Domain-Specific Languages) were an oft discussed topic. One presentation on this topic, "Building DSLs in Static and Dynamic Languages" presented an overview of the motivations for using DSLs and categorized them as either internal (meaning implemented in an existing language) or external (using a custom-built lexer/parser). The former often takes the form of a fluent interface — a human-friendly, readable API. The presentation’s Java examples showed use of method-chaining to make statements more readable. A testament to the attention for this topic was Joshua Bloch’s statement that he was preparing a JSR that aims to, among other things, improve support for method chaining in the Java language by implicitly returning this from void methods.

Challenges in Agile (and how to overcome them)

Agile Software Development in the Large

Martin van Vliet spoke about this talk:

Of course, the agile movement was not missing from this conference. A track about the current "Challenges in Agile" brought a number of agile-focused presentations. The most interesting of these, Agile software development in the large discussed issues surrounding running agile projects with multiple teams, often geographically dispersed. Since I’m involved in just such a project, the presentation yielded little new insights, but confirmed many of our practices.

Bleeding Edge .NET

What's new and cool in C#

Ola Bini shared his thoughts on this talk:

Just to strike a balance I had to satisfy my language geekery by attending Erik Meijer's presentation on C#. It was real good fun, and Erik didn't get annoyed at the fact that me and Josh Graham interrupted him after more or less every sentence, with new questions.

The Rise of Ruby

Business Natural Languages Development in Ruby

Pete Lacey had praise:

Jay Fields gave a wonderfully intriguing talk on using Ruby to build "Business Natural Languages." That is, highly specialized, English-like DSLs that can be used by subject matter experts to implement business rules. This talk was not a "gee, wouldn’t it be nice" kinda thing either. He’s really built them. With great success.

Denis Bregeon had some thoughts about the presentation, and concluded with:

A final point that was stressed during the presentation is that such languages should be very simple and specific to an area of the business. Remember that computer understanding of natural languages in general is a very complex problem.

Security (CAS and OpenID)

Ola Bini described this talk:

Justin Gehtland talked about CAS and OpenID in Rails, both solutions that I think is really important, and have their place in basically any organization. Something he said that rang especially true with me is that a Single Sign-On architecture isn't just about security - it's a way to make it easier to refactor your applications, giving you the possibility to combine or separate applications at will. Very good.

Designing RESTful Rails Applications

Stefan Tilkov wrote detailed notes, and some of his points were:

• REST support in Rails: view helper methods and enhancements to the routing system
• benefits: convenience for the developer, a REST interface for everyone else
• emphasis: resources should not be confused with the actual physical things in your systems
• analogy: RESTfulness, like normalization, is not binary
• Obie suggests the goal should be to keep your actions concise and to the point

Ola Bini also said:

I saw half of Obie's talk about the new REST support in Rails 2.0 (and he gave me a preview copy of his book - review forthcoming). There is lots of stuff there that can really make your application so much easier to code. Nice.

And Pete Lacey added:

On the Ruby track Obie Fernandez gave a presentation on "Designing RESTful Rails Applications." I knew most of what Obie had to say already, but still learned a thing or two, and also learned that there’s more to learn. Must peak into the routing code. It was a good talk nonetheless, especially if you were Rails proficient, but new to RESTful application design

Practical Application Security

Gunnar Peterson shared his thoughts about this track:

The first App Security track is in full swing at QCon. I have to hand it to the folks at InfoQ and JAOO, they might be the first big development conference to take a real shot at doing a full blown app security track [...]
There have been some great sidebar conversations. There are a lot of agile disciples here (of course), and they are somewhat concerned about how (and how much) security to add in to their process. This gave me a chance to reference one of my favorite papers of the year - Johan Peeters and Paul Dyson's paper on Cost Effective Security, which sorts out app security concerns in an agile way.

Tutorials

Domain-Driven Design

An anonymous attendee (thier.ca) shared their thoughts:

I really liked the tutorials, I think mostly because the smaller environment lead to more discussion and diving into details. [...] The DDD tutorial had a lot of good insights, the best probably was that we should spend the time to figure out what part of the software we’re building is really core to the domain of the business and make sure to design that really well to reflect the business. Other parts are slightly less important, but will benefit from the good design of the core.

Bala Paranj gave a detailed summary of the presentation, and concluded:

Eric walked us through a case study and gradually introduced the concepts from his book. This is a must-attend tutorial. I felt 3 days would have been ideal, as there was still a lot to learn about domain driven design from the book.

Domain-Specific Languages

thier.ca also had some thoughts about this tutorial:

The DSL tutorial was more interesting from a forward-looking perspective. I can see DSLs being useful in some cases, and no one was saying they are universally useful. But, there are some very early stage development tools that try to model everything as a DSL. No one seems to know yet how well these tools will work, but it will be interesting to see.

Geoffrey Wiseman attended the tutorial, and described what he learned:

They did a good job of describing the kinds of domain specific languages (they used the terms internal and external, rather than the 'embedded' term that's been used elsewhere), showed some good examples of DSLs in Java and Ruby as well as completely custom DSLs, the tiny languages that the Pragmatic Programmers talk about. They also spent some time describing the boundaries of DSLs: What's a DSL vs. an API; a DSL is usually a thin veneer over a framework; the hardest part in writing a DSL is writing the framework beneath it.

The last portion focused on those external DSLs, using Antlr as an example on how you might build and use a parser for a domain-specific language. This was the most interesting to me, because although I've read a little on the subject, including some of Martin Fowler's exploration of Antlr already, it's the area that I knew the least about (having used jMock's Java DSL for years, and having done a few months of Ruby in anger).

Certified Scrum Master Class

Another anonymous blogger (signedbyte) had the following thoughts:

I came in with low expectations for the Scrum Certification course being taught because I have read and have attended many Agile talks in the past. I will have to say the class has been extremely enlightening! The real world examples that Gabrielle Benefield gave has been very helpful. I hope I can take this experience and have an opportunity to change the way we are doing things back on the project I'm working on now.

I think there has been a lot of exercises that were really telling about how agile development is not the easy route that has no discipline, etc. These types of rumors are prevalent in my current customer's view and need to be explained why they are not true. I plan on pitching some ideas so that we might be able to really start showing what is getting done and velocity our project is operating at.

Vendors

Michael Nygard took interest in some of the vendors which had booths at QCon. He mentioned three in particular, including Semmle:

In the category of "really cool, but would I pay for it?" is Semmle. Their flagship product, SemmleCode, lets you treat your codebase as a database against which you can run queries. SemmleCode groks the static structure of your code, including relationships and dependencies. Along the way, it calculates pretty much every OO metric yet invented. It also looks at the source repository.

What can you do with it? Well, you can create a query that shows you all the cyclic dependencies in your code. The results can be rendered as a tree with explanations, a graph, or a chart. Or, you can chart your distribution of cyclomatic complexity scores over time. You can look for the classes or packages most likely to create a ripple effect.

3Tera:

Virtualization is a hot topic. VMWare has the market lead in this space, but I'm very impressed with 3Tera's AppLogic.

AppLogic takes virtualization up a level. It lets you visually construct an entire infrastructure, from load balancers to databases, app servers, proxies, mail exchangers, and everything. These are components they keep in a library, just like transistors and chips in a circuit design program.

and GigaSpaces:

What can I say about GigaSpaces? Anyone who's heard me speak knows that I adore tuple-spaces. GigaSpaces is a tuple-space in the same way that Tibco is a pub-sub messaging system. That is to say, the foundation is a tuple-space, but they've added high-level capabilities based on their core transport mechanism.

So, they now have a distributed caching system. (They call it an "in-memory data grid". Um, OK.) There's a database gateway, so your front end can put a tuple into memory (fast) while a back-end process takes the tuple and writes it into the database.

Just this week, they announced that their entire stack is free for startups. (Interesting twist: most companies offer the free stuff to open-source projects.) They'll only start charging you money when you get over $5M in revenue.

I love the technology. I love the architecture.

Opinions about QCon itself

Nati Shalom had the following to say:

I just returned from Qcon-San Francisco. I really enjoyed the conference. The presentations and panels were of very high quality. I also enjoyed the fact that it was intimate enough for meeting with  interesting people in the industry. I particularly liked the discussion with Brian Zimmer of Orbitz, who is using Jini as part of their backbone, as well as (eBay), who gave an excellent presentation on Friday on the eBay architecture. Well done Floyd and Trifork (Aino, Roxanne and the rest of the team) for the organization of this event.

AccuRev described the conference as:

For those tracking the movement of luminaries such as Martin Fowler and Kent Beck or looking for scalability advice from the architects at companies like Orbitz, Ebay, and Linked-In… QCon '07 in downtown San Francisco is the place to be!

The conference is packed with senior architects, software engineers, and open-source contributors galore — over 400 were rumored to be in attendance. With speaker topics ranging from enterprise scalability to Agile practices, the audience was nothing short of being at the top of their game.

Other thoughts:

• Denis Bregeon - I was very happy with it. Most of the talks tickled my imagination and that is the primary thing I was looking for. Many others gave me details on more technical subjects that I wanted to learn about.
• Srini Penchikala - I was at the QCon conference in San Francisco last week. It was a great experience to be there. I learned a lot not only from the presentation speakers and panelists but also from the attendees who came from different countries (England, Syria, Australia to name a few) and companies. Thanks to Floyd and the InfoQ team, the conference was a great success.
• Alex Olaru - Great conference: excellent speakers, very relevant topics, just enough product pushing without it becoming annoying. All in all a conference I would highly recommend to any architect or project manager.
• Ola Bini - Last week I attended QCon San Francisco, a conference organized by InfoQ and Trifork (the company behind JAOO). It must admit that I was very positively surprised. I had expected it to be good, but I was blown away by the quality of most presentations. The conference had a system where you rated sessions by handing in a green, yellow or red card - I think I handed in two yellow cards, and the rest was green.
• Martin van Vliet - All in all, this was a good conference and more than enough reason to look forward to the next QCon, next year in London.
• Pete Lacey - A wonderful conference made better by being able to meet many people face to face for the first time, including not only my fellow track speakers but Stu Charlton, Mike Herrick, Patrick Logan, and many others.
• David Forbes - Exhilirated after gorging on brain candy this week, I have a moment to reflect on what just happened. QCon was the right place to be. I can't imagine where else I would have rather been. If I had the week to do again, I would probably march right down to the Westin...again. [...] Thank you, Trifork - this week was well worth the time and expense.

Conclusion

QCon San Francisco was a great success and we are very proud to have been able to offer such a conference. It will become 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 bringing QCon into other regions which InfoQ serves, such as China and Japan. If we've sufficiently whet your appetite, consider QCon London which is taking place in London in March 08. For the rest of you, thanks everyone for coming and we'll see you next year!!!!