Friday, September 8 was the last day of the EclipseWorld technical conference. I won't go into all the gory details of the sessions I attended. If you read my Day Two report, it was more of the same: Some sessions missed the mark, at least for me. These sessions just weren't technical enough. In fact, in an informal poll, the consensus among people who have attended both conferences is that EclipseCon is the better conference for experienced Eclipse developers.

Of course, the conference did have some good sessions. The best session I attended on Friday was called Contributing Code to Eclipse. How to. Why to. It was conducted by Bjorn Freeman-Benson, Director of the Open Source Process at the Eclipse Foundation. Bjorn described the organization of the Eclipse Foundation, the motives of it's member companies *, and the details of development process.

As Bjorn puts it, one measure of the Eclipse project's success is they have released a version of Eclipse every year, on schedule, for the past seven summers. This is a record of which most commercial software companies would be proud, but Eclipse is an open source project. You might have expected it to disintegrate into anarchy by now.

How has the project managed to be so successful? Bjorn highlighted three points:

It's a meritocracy. Only the best developers become Eclipse committers. Even a paying foundation member company cannot install one of their developers on a project without approval from the current committers. Generally, you become a committer by contributing patches first.

The process is completely transparent. Everything from project planning, to staffing, to the actual source code is recorded on the Eclipse web site. This ensures that both committers and the eventual consumers know what is happening with the project.

Communication is key. This is related to the point about transparency, but Bjorn highlighted it a few times. He said even a great developer will not succeed in an Eclipse project unless he is also a good communicator.

This is a refreshing approach to building software. I think some commercial software companies could learn from open source. For more on the Eclipse Way, see Erich Gamma on the Eclipse Culture.

* Eclipse Foundation members commit resources to Eclipse projects not out of altruism. They expect to make money on the Eclipse framework.

Thursday, September 07, 2006

For me, today was Rich Client Platform (RCP) day at EclipseWorld. I planned on attending four separate sessions on RCP. As it was, I took a small detour to learn about the Java profiling tools in the Test & Performance Tools Platform (TPTP).

The first RCP course was First Steps for Building Eclipse RCP Applications. It was mostly review for me, but I thought it would be good preparation for some of the more advanced courses. The instructor, Dwight Deugo, did a good job describing the basics.

I also attended Fundamentals of RCP UI Programming. This session was a little disappointing. The instructor is a good speaker, but he spent the entire two hours talking about JFace -- and from a very high level. Although he occasionally showed some sample code, it was difficult to follow along. The sample code wasn't reproduced in the presentation materials. Even though I was near the front, I couldn't see the details. Pity the poor folks in the back.

To complete "RCP day", I planned on attending a two part session called Successful Architecture Design for RCP Applications. I expected this to be about factoring your RCP application into features, plugins and fragments; interactions between views and editors; extension points; the job manager; and other hard-core Eclipse concepts. Ten minutes through the first part, I realized I was mistaken. The session was all about migrating three-tier business applications from the web to RCP. Although the instructor has good "Eclipse credentials", this topic didn't really fit with the other sessions in the RCP track. It certainly doesn't interest me personally.

Rather than sit through the second part of Successful Architecture, I decided to switch to Profiling Java Application Behavior with Eclipse TPTP. This was a revelation. The instructor demonstrated the features of the Profiling and Logging perspective which is contributed to Eclipse by TPTP. The profiling views let you track execution flow, execution statistics, memory statistics and object references in a running JVM. You can quickly sort these views to find hot spots like methods that consume lots of CPU cycles. I use Eclipse everyday but I didn't realize the free profiling tools have gotten this good. For a good introduction of the Profiling and Logging perspective, see this tutorial at eclipse.org.

Wednesday, September 06, 2006

I'm at the EclipseWorld technical conference in Cambridge this week. I was hoping to blog from the conference, but there were technical problems with the conference's wireless network today. There are only a few hundred attendees, but the organizers apparently didn't plan for a large volume of network traffic. This doesn't reflect well on the conference.

Today, we each had to choose one of seven all-day tutorials to attend. I attended the Callisto Boot Camp:

This tutorial, for experienced Eclipse developers who are currently using Eclipse 3.1, will deep-dive on the new features and innovations in each of the 10 projects that make up the Callisto Simultaneous Release. By attending this class, you'll gain a unique perspective on these projects, not only about the individual new functions that they offer, but how they integrate together to advance the entire Eclipse ecosystem. Everything you want to know about Callisto--you'll find it here.

The instructor -- Eclipse Evangelist, Wayne Beaton -- acknowleged from the start it is difficult to do a deep-dive on everything. For my taste, he spent a little too much time on the Web Tools Platform (WTP) and not enough on the C/C++ Development Tools (CDT) or Data Tools Platform (DTP). However, I'm not really criticizing. Mr. Beaton struggled mightily to describe the whole elephant. He didn't quite pull it off, but he demonstrated a solid understanding of a broad set of technologies. It was a worthwhile overview.