JavaOne 2007

Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.

Gregor = Booth Babe

As last year, Google had a booth at the JavaOne Pavillion, i.e. show floor. This year, though, the focus extended beyond just recruiting and giving out swag to include demoing some of our developer-focused products. Most of the GWT team were here to give demos and answer questions and Patrick (also a presenter at JavaOne) showed off Google Checkout. Google is also holding a developer day later this month, underlining the increased focus on the developer community (aka the people we have not hired yet).

Real Lessons Learned

Being a booth babe equipped me with a mere "Pavillion Only" pass. So I decided to put my fame to test and request a press pass. Sure enough, I was allowed into the super-secret (and super not exciting) press lounge and into the actual sessions. Going to a large conference is always a good chance to catch up on all the technologies that you may have heard off but never had the time to have a closer look at. JavaOne always presents me with a particular challenge, though (besides having to get up in the morning after the late night socials): I typically attend sessions based on the speaker more than the topic. At JavaOne, however, many of the speakers are Sun engineers or product managers, so my usual filter function did not work very well. Accordingly, my biggest learnings were what to do and not to do in conference presentations. Because I surely committed one or more of these offenses during my talks, I have the more reasons to remind everyone here:

• Do not spend half of your talk "motivating" your topic. If you can't interest people in your topic within the first 2 minutes, you should pick a different topic (or profession). Hani captured how we endured a never ending introduction that began with the economics of development (Benefit > Cost = Good) and "progressed" to a Rename Method refactoring after some 30 minutes (out of 60!). I give this particular talk an extra minus point for promising "Advanced Refactoring Techniques". What could be easier to demo than an IDE? But I guess if you don't have much to show you'll make up for it with a length intro.
• Kick off with a demo (or example). Building up to your topic allows you to introduce your line of reasoning and vocabulary to the audience. But it also leaves the audience dangling for a long time. Basically, this kind of intro is really for you (making it easier to make your point later) as opposed to the audience. Because the audience is the one who shells out the money (and time) here, you should make sure the presentation is for them, not you. Starting with a demo is certainly more difficult because it does not give you a chance to establish a lot of vocabulary or context. However, that's why it's you who is presenting and not some random sociophobic engineer.
• Have a rhythm. Let's be honest: the average conference attendee arrives from a different time zone, is slightly jet-lagged, and often has to make do with 5 hours of sleep. That is 5 hours at night. They usually get the other 2 or 3 hours during the day, i.e. in your talk. Nothing makes people nod off faster than a soothing and constant lullaby of arcane technical data -- no matter how relevant it is. To fight the audience's urge to sleep make sure you have some fast parts, and some slow parts, some loud parts and some quiet parts. Tell an anecdote, get people to laugh, or, better yet, to applaud: whenever dozers hear applause their subconscious triggers the "end of session" signal causing them to wake up immediately. Now you have another chance to engage them.
• Tell a story. The old "My name is Dilbert and I am here to tell you about" technique only goes so far. Make sure you have an easy to follow story for your talk. Not the kind of story a 2-year-old tells (and then we used Java (TM) technology. And then we used this cool new API. And then everything was good). But one with turning points, road blocks, desperation, solutions, euphoria, betrayal, love, hate etc. This comes back to the "rhythm" point. Also, having a good story allows the dozers to catch up more easily once they re-enter the awake state.
• Make sure you solve an actual problem. This must sound like motherhood and apple pie, but I guess not everybody has gotten it. I still see a lot of presenters selling solutions that seem intellectually useful without ever applying them to an actual problem. At academic conferences you can usually spot these kinds of talks by the work toward in the title, but professional presenters tend to put snazzy titles on purely conceptual talks, making the more difficult to spot. I certainly have given my share of conceptual talks, but at least let's be honest and state this fact in the title.
• Not everything you say has to be brand new. Hani and I once joked that the highest rated talks are the ones that tell developers what they already know. Granted, there is a difference between highest rated and best but there is still a lesson to be learned here. Many developers are not looking for the sneak preview of the pre-beta-alpha API but could use some confirmation of what they are currently doing. Helping them conceptualize and better understand their current work leaves them reconfirmed and they can go back and tell their boss that they were right all along.
• Never let anyone touch your slides after you have last seen them. JavaOne is infamous for muddling with presenters' slides. Of course there is the mandatory :s/Java/Java(TM) Technology act, but it gets worse. More than one presenter lamented the fact that the final edit (for style presumably) introduced factual errors or rendered graphics useless. You have to stand up in front of 500 people -- you should get the last word.

Mashup Blueprints

My first session I attended was "Blueprints for Mashups". For a Googler I am embarrassingly ignorant on the whole RIA (Rich Internet Application) topic space, so this seemed to be a good way to catch up, reconfirmed by the incredibly long line (see picture). The content wasn't even that bad -- the presenters offered solution recipes for issues developers tend to encounter when building mashups. For example, accessing external servers from a client-side mash-up is often restricted through cross-site scripting constraints. To solve this problem you can proxy through your server, which in turn accesses the external resource. This "pattern" allows you to keep control of any developer keys you need to access the external site and also allows you to cache data. The main drawback is that you have to deal with two HTTP hops (unless you get a cache hit). They also showed a variety of approaches to deal with developer authentication for your APIs. A lot of the examples used jMaki but I did not pay enough attention to really form an opinion on it. I also took note of the recently established JSR 311 (JAX-RS: The JavaTM API for RESTful Web Services). Sounds interesting but I gave up trying to follow every proposed Java API years ago. Again, the overall content was a little high-level but not bad. However, somehow this ended up being one of the presentations that just seemed to trickle along in a steady stream, putting people to sleep one by one (see advice above). So I decided to wander down the hall and stumbled upon...

Designing Service Collaborations

Walking down the hall I realized that a talk on conversations was going on at the same time. Naturally, I wanted to catch as much of it as I could. Getting to this talk 15 minutes before the end, I was warned by the people scanning badges that everybody left the talk saying it was boring. I snuck into the room to find Mark Hapner presenting to a hard core of 100 or so people. I love Mark, but it would not be unfair to say that his IQ outweighs his charisma as a speaker by about 10 : 1. Of course this topic is close to my heart, so I tried to make the best our of the short time. In brief, Mark is urging developers to focus on what's going on the wire (as opposed to inside your apps). You'll be thinking about conversations, correlation, Message Exchange Patterns, etc. He left us with a pointer to Open ESB, which I am going to check out.

SCA != SOA

The Panel "SCA/SDO and Java Technology: Complementary Technologies That Drive Open SOA Environments" was well attended and featured a promising line-up of panelists from BEA, IBM, Oracle, SAP, Sun, and TIBCO, who are all implementing the SCA Specification. David Chappell (the one) moderated while David Chappell (the other) spoke for Oracle. You can easily tell them apart by their attire: David Chappell (the other) is dutifully wearing his company logo shirt as not to be mistaken for the (late) David Chappell who worked for Sonic, while David Chappell (the one) will not be caught without European designer fashion. David (the one) has been focusing on writing lately so it was fun to see him live again. He made an excellent moderator, quickly pinpointing two key issues around SCA:

• Are the vendors supporting both SCA's programming model and the assembly model?
• Is SCA really suitable for SOA as it requires that a single composite is running within a single vendor environment?

The programming model, much like Microsoft's WCF, provides a unified API for all kinds of distributed systems communication. In the Microsoft world this is a big deal, and rightly so. So it was a little surprising that the vendor support for SCA's programming model is at best luke warm. Even a lot of the "official" documents seem to downplay this aspect of the spec. Only IBM and BEA are really supporting both aspects while the others openly stated that the programming model is not their focus. A poll to the audience ("who would like to see a new programming model") seemed to confirm this attitude (no hands went up) but I think this might be misleading. I agree that learning a new model is always a liability, unless it replaces multiple outdated programming models and makes developers more productive and code easier to understand. I don't think this aspect came out in the question to the audience.

When I looked at SCA before it totally escaped me that the spec assumes that a composite has to run in a single vendor environment. This limitation means to me that SCA has relatively little to do with SOA, which has to deal with an environment that is heterogeneous and not controlled by a single vendor. This does not mean that SCA is useless, but it means that it targets "programming in the middle" (wiring components in a single vendor environment) as opposed to "programming in the large" (wiring services in an enterprise setting). This makes all sense because the "programming in the large" is the realm of the WS-* specs but it was still surprising to me that I missed this critical part.

David has summarized his take-away in more detail and, as expected, more eloquently.

Highlights and Lowlights

Brian Goetz and Bill Pugh gave a nice talk on testing concurrent systems. The definite low-light for me was Advanced Java Programming Language Refactoring: Pushing the Envelope. The only pushing I observed were the people being pushed out of the room by the never ending introduction into the topic material. We all agree that having benefit outweigh cost is a good thing, so no need to reiterate that. If you spend half your talk leading into your topic you run the danger of boring and/or insulting your audience to death, not to mention being biled. How about "Who here does not want to be more productive?" as an opening, followed by an impressive demo? Sadly, this talk reconfirmed my impression that NetBeans is not really worth looking at. Go IntelliJ!

I only attended two BoF's due to the intense social schedule. I caught the tail end of "Debugging BPEL Processes" because it somehow took us 20 minutes to settle the dinner bill (software engineers and Dollar bills do not seem to mix). I followed up by Alex Ruiz presenting an open-source GUI testing framework. It was nice to see that a fair number of the presented projects are hosted on code.google.com.

Another low-light must have been the wireless network. Full signal, but no IP or no gateway :-( No wonder Sun dropped The Network is the Computer from their corporate vocabulary. At JavaOne the network was a piece of crap...

Networking Activities

What would JavaOne be without the social events? The Tangosol party was attended by the usual suspects, which made for an entertaining evening. Sadly we missed the moment where the bouncer denied Cameron admission to the party as he was lacking an invite. As usual, we were booted at 1am or so, aimlessly wandering the streets. Carlos reported back from a taxi that they are heading for The Stud. A few minutes later reported that they are coming back from Studs. And I thought Carlos is not even that bad looking...

Weds night sported a host of company receptions and the exclusive-yet-not-so-exclusive reception Google reception at the (trying to appear exclusive) W Hotel. First i stumbled through Jillian's, hitting TerraCotta, Eclipse, Amazon, and IBM. The blogger event at Thirsty Bear was kinda lame, so we headed off to the Google party. They actually had poor Bob check for tickets at the door so I had to pull people in continually (somehow the people we really liked to be there were beaten by the swag hunters in the race for a ticket). The party was good fun but somehow ended a little early. A hort trip to House of Shields provided one more drink. Somehow the whole gang felt a little old and tired when compared to last year. Maybe we are actually getting old and tired. The only thing open after 2am appeared to be Denny's. Eating there was the penalty we morons paid for not knowing that there is a 24 hour Naan 'n Curry just a few blocks away. But then our stomachs may have thanked us.

The guiding theme for Thursday was provided by James observing that he "has not gotten properly drunk yet". After dinner and two BoF's ("Debugging BPEL Processes" and "Simplifying GUI Testing") it was time to hit the bar. We walked all the way to the Starlight room to join forces with James, Hani etc (who skipped the BoF's in favor of AsiaSF). In usual fashion we were booted at 1:30 or so. After the crowd thinned a little, six of us hopped into cabs to see how long the 15 beers in my fridge would last us. About 6am...

See you all next year!