One of the more exciting things I get to do when I visit Germany is attend one of Ralph’s many Stammtisches (or is that Stammtischae?) For the uninitiated, Stammtisch translates roughly into “regular’s table”. Ralph’s incarnation of the tradition brings members of the Eclipse community together to socialize and network while drinking beer and eating tasty Germany food.

If you’re in the Stuttgart area next week, please drop by the Hotel Krone at 1900h (the hotel is actually in Steinenbronn which is a little south and west of Stuttgart).

At Nick’s suggestion, I’ve been tinkering with using Zest to visualize the project pairing data that I’ve spend so darned much time gathering from the Usage Data Collector results over the past week.

This image was generated using the “Spring graph” layout algorithm to represent how closely related the various projects are.

The spring layout algorithm pulls the most frequently used project combinations towards each other, so those projects most commonly found in the wild naturally drift to the middle.

I’m not very happy with the way that it’s drawn; I’ll work on that over the next few days. Right now, it runs as an SWT application. I may turn it into a plug-in.

The graph helped me notice a few other bundles that needed to be rolled into their project (recall that the names shown on the report and in this graph are taken from the third segment of each bundle’s symbolic name). So, in the next version of the report (and this graph), ‘cvs’ will be rolled into ‘platform’, and ‘contribution’ into ‘ajdt’. I also decided to roll those curious ‘mylar’ references into ‘mylyn’.

I’m working on a presentation about Ganymede. I’ve already got some slides from the talk Mike and I did at JavaOne 2008, and am in the process of adding material from Chris’ article on developerWorks. I’ve scavenged a lot of material from the Eclipsepedia wiki on the topic and have loaded the latest and greatest from the Data Tools Project to look into that fancy new visual SQL Query Builder.

Is there anything in particular that you think I should mention? Please post your ideas or send them via email (I’m the only ‘wayne’ at eclipse.org).

I intend to make the presentation available for all to use on the Eclipse Resources page.

Last week, I wrote about a new report I added for the UDC data that shows project pairings “in the wild”. In a comment, Nick effectively killed my weekend. Nick, my wife’s not happy with you. I showed her your picture. Be careful.

The report can now be sorted on columns. Actually, this part was easy to implement.

The hard part is that I noticed something when I started sorting the data on the different columns. I noticed that, while I expected that each pairing should be represented twice, some of them are only represented once. I expected to see, for example, a pairing of ‘ajdt’ and ‘platform’ along with a pairing of ‘platform’ and ‘ajdt’; but I only see one (the latter). I tried several different queries, and even tried more manually assembling the data (the final query is surprisingly simple, yet yields the same results as some of its more complicated cousins). I stumbled into two known MySQL bugs, and (possibly) one unknown one. To ensure that things stayed interesting, I opted to move the main query into a stored procedure (put the Data Tools Project’s SQL editing support into full use (though it was complicated by the fact that I had never once before ever created a stored procedure).

I’ll keep hacking at it, but in the meantime, I’ve made the new version available anyway.

In my efforts to refine the query, I discovered that I had previously been doubling the actual numbers (in my defense, I did state that I thought they felt a little high). That’s been fixed.

Once I can figure out a reasonable home for the queries, I’ll make ‘em available so that Nick can lose a weekend too.

I also spent a little time looking for a visualization package; something that will let me draw a diagram showing the relative proximities of the projects. I did stumble upon a neat little physics package that I figure I can use: each project can be represented as particle, with the number of users represented as the strength of a spring joining the particles. I think it’ll look cool. But, unfortunately, it’s become low priority; at least for the next week or so.

In the meantime, does anybody know of some decent software that can be used to represent this sort of information?

Mustafa has posted a cool screencam of shared editing using Eclipse. He and a friend, Thomas, chat via Skype while they work together on the same file in shared editor. It’s about as good as real side-by-side pair-programming… It may even be a little better (though pair-programming traditionalists may baulk at the notion of both members coding at the same time). Watching code appear in two places at the same time is a little freaky. Frankly, it’s fantastically cool.

If you need a little more incentive to watch, there’s a bit of a World of Warcraft slant to it.

Elias posted this note on the Riena Dev list. I think it’s interesting reading that deserves a broader audience. So… here it is.

–

From my personal point-of-view (having done a couple of RCP projects) the benefit of Riena that is important to *me* is, that Riena will provide a more “accessible” technology for writing rich clients based on RCP.

Accessible in a dual sense:

* for end-users Riena should be more accessible because of the “process oriented” UI that moves away from the ide-centric Views and Editors metaphor. To further increase acceptance by end-users Riena is also aiming to provide support for customizable look-and-feels.

This should reduce the amount of effort and customization required to create a user-friendly, nice-looking application based on RCP. Don’t get me wrong here: I really like Eclipse RCP and it’s flexibility. Hower the framework is quite complex because of that. A solution already sculpted towards a specific use case (i.e. process oriented UI) could lower the barrier of entry for that use case. My understanding is that this is the road Riena is trying to follow.

* for developers Riena should be more accessible because it is exposing existing Eclipse technologies — like Databinding and JFace Viewers — through more “high-level” APIs (for example the Ridgets). This should hopefully flatten the learning curve for adopting those technologies.

For example a ITableRidget provides a multi-column table with build-in sortability support (i.e. clicking on the table headers) and databinding in just few lines of code (i.e. create SWT table control, register table control with Riena, bind model to table ridget). This is all done using existing Eclipse technologies. Without the Ridget a developer would have to learn about TableViewers, learn about Eclipse Databinding, use a databinding enabled label and content provider, learn about selection listeners (for sorting the headers), store the sortability state of each column, manipulate the sortability state of the table ridget based on selection events and so on. Much of this stuff may seem trivial to Eclipse veterans but can be quite intimidating for Eclipse newcomers.

In short the UI-side of Riena aims to lower the barrier of entry into the world of RCP-based clients, by reducing the amount of investment and customization required to create a specific application UI (=process oriented). This should be good news for people who can buy in into that UI style. Note that Riena has more to offer, however I’m speaking for the area that I’m most familiar with.

–

I love the name “Ridget”. It makes me think of Scooby-Doo (“Raggy, rerate a rable ridget”…).

There’s actually more to Riena than just a higher-level RCP. But this is still pretty cool stuff.

I decided that it might be cool to find out which projects are being used together in the wild, so I wrote a new report using data collected by the Usage Data Collector (UDC). The report shows a table where each row contains a pair of projects and a number. The number represents the number of users who have used at least one of the bundles from each of the projects. I’ve garnered some delightful insight from this report.

First, it’s interesting to me to note that there are two people out there that have mylar bundles installed (”mylar” is the former name of the “mylyn” project). I assume that this is somebody who just has the bridge “do nothing” bundles that were created as part of the the transition to the new name. What’s particularly interesting about that is that somebody actually installed the UDC into what I’m sure is an existing Eclipse 3.3-based product to produce this input.

Second, RAP seems to be used in conjunction with JST by a lot of folks. I guess that this feels natural, but in my own dealings with RAP thus far, I have not used both RAP and Java EE explicitly together (and no, JST is not a prerequisite for RAP). My guess is that a lot of folks out there doing RAP stuff are also doing Java EE stuff.

Some of the usage numbers are impressive. Data tools, Device Debugging, Test and Performance Tools Platform are used by a lot of folks.

The report needs some improvement. First, I’m identifying the project by extracting the third segment from the bundle name, (i.e. “org.eclipse..whatever”. I’ve tried to gather up all the names used by the Platform project and dump them into a single “platform” entry, but I think that I’ve missed a couple. Also, there are some other bundles that are not quite following the rules that I’ll have to sort out. Presently, the report only looks at bundles with names that start with “org.eclipse.” and doesn’t consider versions.

I’m also a little skeptical about some of the numbers. Some of them feel a little high (especially when compared against numbers from the other reports). while I’m confident in the pairings and the relative magnitude of the numbers, it’s probably a little early to start basing any decisions on them.

Anyway… enjoy the Project Pairings report. And please do let me know if you can think of any way to improve it.

Occasionally we get questions along these lines on the newsgroups:

Does anybody know how X is coded in Eclipse?

The simple answer is yes. Everybody can know how it’s coded. The source code is out there for all to see.

You have a couple of choices when it comes to viewing source code from Eclipse projects. If you want to do it the hard way, you can use the handy ViewCVS utility to browse through the various CVS and SVN repositories.

But nothing beats just having the source code included as part of your configuration. If you’ve downloaded the “Eclipse Classic” or “Eclipse for Plug-in/RCP Developers”, then you already have the source code for the Eclipse Platform, RCP, JDT, PDE, and more. If you need to see code from other projects, you can very often get the “source code” bundles from the project’s update site in the form of an “SDK” feature (many projects have opted to include their SDKs on the Ganymede update site).

Assuming you have the code, finding the right place in it can be challenging. This is where a handy little tool known as the “Plug-in Spy” comes in handy. When you invoke the Plug-in Spy (by hitting Alt+Shift+F1), it pops up a window showing information about the view/editor/dialog that has focus. The information includes such things as the name and package of the class that implements the view, and the bundle (plug-in) that defines it. From the pop-up window, you can even jump directly to the class definition via hyperlink. It’s pretty handy stuff when you’re trying to figure out how things are implemented.

Here’s what it looks like when you use it to find the class that implements the “Select Working Set” dialog (it can’t determine which bundle defines the dialog).

Having that first hook into the code is pretty handy, but it’s often better to see it in motion. Drop a breakpoint somewhere in the class (the constructor or perhaps a createDialogArea method is a good place to start), create a Debug Configuration that includes all the plug-ins in the “Target Platform” (see below) and launch. The Debugger will open up when your breakpoint is encountered.

You can merrily (or gloomily, your choice) step through the code to see how it is actually invoked.

I think this is screaming for a screencam demo. I’ll see what I can cobble together…

Earlier this week, while helping James prepare some words to include in this week’s EclipseZone newsletter on the Usage Data Collector (UDC), a thought occurred to me (which I included in the text): the information gathered by the UDC should help in testing.

Think about the magnitude of the testing problem that faces Eclipse projects. Consider just Ganymede. A user/organization is assembling a development environment will choose to either include, or not include each of these projects. That means, that there is an upper limit of 2²⁴ = 16,777,216 possible combinations of projects. This assumes that each user is going to take all the available bits of each project; if you try to factor in that each project produces some number bundles that can either be included or not included, then this number gets way bigger.

Now, with the assumption that each user/organization is going to take all the bits of each project, the number is actually a bit lower. To have a development environment, you need to have the Eclipse top-level project’s code, which drops the upper limit to 2²³ = 8,388,608 possible combinations of projects.

If each project has exactly one automated unit test that takes 1 second to run (which, if you consider the time required to startup the test environment is probably a little low), running the tests on all of the combinations will take, well… a heck of a lot of time (2,330 days). And that completely disregards any time required to actually configure all those different combinations. In fairness, the upper limit is probably (though not necessarily) a little high. Let’s say that the actual number of combination of projects in the wild is really two orders of magnitude lower than that upper limit (which brings us down to a scant 23 days of automated unit testing).

The point is that rigorously testing all possible combinations of Eclipse projects is—while not impossible—certainly impractical.

One of the handy things that the UDC captures is combinations of software that actually exist in the wild. We can tell from the data, for example, that certain features are actually used in combination. We will be able to tell, for example, how many people are actually using RAP in combination with BIRT. Or Subversive with Mylyn. Or Subversive and CVS in conjunction with TPTP and Buckminster. I have this vision in my head of a graph showing all the different bundles clustered into groups where the closeness between bundles indicates how commonly they are seen together in the wild.

From this, I expect that we’ll end up with a relatively small (i.e. much smaller than the upper limit) set of combinations of projects and bundles that are really used in the wild. From there, we can set priorities for testing, usability, interoperability, integration, etc.

What do we do with this information? At a minimum, we (“we” the Eclipse community, not necessarily “we” the Eclipse Foundation) might consider using the Eclipse Packaging Project (EPP) to build these most commonly found combinations to make them available for testing. It has been suggested that the Eclipse Foundation should invest some resources into testing; maybe having the packages based on real combinations in the wild is a step toward that, or maybe even something else entirely. Frankly, I think it’d be cool if we had a Testing project. At least we’ll know what to test.

I’ve added a new report that shows (1) how many people are participating each month, (2) how many new people are contributing data for the first time each month, and (3) how many events are uploaded each month. The report is updated weekly.

I’ve spent some time over the past few days reworking the Eclipse Evangelism site. Perhaps the first thing that you’ll notice is that I’ve simplified the look of the page.

The second thing that you should notice is the list of “evangelism” resources. I’ve started cleaning up some of my talks and am posting the slides where other folks who might want to do some Eclipse evangelism can find them. So far, I’ve posted my “What is Eclipse?” and “Engaging with the Eclipse Community” talks (in Open Document and PDF formats). I have a couple of other talks that I tend to use a lot that I’ll be posting soon.

I’ve been going through a bit of a minimalist phase lately, so the “Community” talk feels a little clunky to me (it’s anything but minimalist). But having more content on the slides should make it easier for folks to reuse the materials. I have tried to include some instructor notes to make them easier to reuse. The presentations are released under the EPL, which is probably not the best mechanism for slides. I’ll have to look into relicensing them under more appropriate terms.

As noted on the page, I do intend to move the example code that’s found there into the Examples project. That should happen over the next little while.

The latest addition to the page is some new wallpapers contributed by Gavin Fung (see Bug 232145). Gavin has provided the image in two sizes. It’s pretty sweet looking.

I’d like to make this page be a place where people can find useful evangelism resources, including evangelists. If you need an Eclipse speaker for your event, send a note to evangelism@eclipse.org and we’ll try to help you out. If you fancy yourself as an Eclipse evangelist, please subscribe to the evangelists mailing list. Please make a point of sending an introductory message announcing yourself to the group so that we know a little bit about you.