Here is my first attempt at writing a Haiku about Eclipse:

Eclipse RCP
Not just a window system
Components are king!

I believe that discussing Eclipse is a reasonably good stand-in for the requirement that traditional Haiku have something to do with nature (the Wikipedia says that it’s supposed to be a season word).

I’ve spoken about this in the past, but it’s a pretty important topic, so I thought I’d bring it up again (and will likely do so again)…

One of the best ways to keep up to date with what’s happening at Eclipse is to listen in on bugzilla. Bugzilla is where bugs are reported, and where conversations concerning those bugs are recorded. You want to understand why a certain design decision is made? The answer is likely somewhere in Bugzilla.

Browsing Bugzilla is just painful. Especially if you’re not looking for anything inparticular. Unfortunately, there is no “find me interesting stuff” search option — though maybe Denis can implement that on one of those days when he has nothing to do (note sarcastic tone). The best way to keep track of what’s happening is to get Bugzilla to email you by telling it to send you a copy of any email sent to specific mailboxes; generally some sort of project mailbox. You can find the instructions for doing this here.

I listen to a whole bunch of different projects, but not all. I change the list once in a while to listen to different project activity. Denis laughed at me when I asked if there was an easy way to just listen to everything; apparently that would generate thousands of emails (yikes!). Since I became editor-in-chief of the Eclipse Corner Articles, I’ve started following community.articles-inbox (tack “@eclipse.org” to the end) to keep track of discussion around new article ideas and submissions.

Anyway… bottom line is this: if you really want to understand Eclipse at a fundamental level, following Bugzilla conversations is a great way to make it happen.

I think we can probably all agree that 18 pictures of me putting on the shirt is a little much. However, I think this pretty effectively closes bug# 112631. I am a little concerned that my hair looks just a little goofy; but hopefully that’s more a function of being overly critical of one’s own appearance. I’m sure that someone will let me know if I am mistaken…

Of all the pictures, I believe that this shows me in the most evangelical pose (it’s the favourite of Jörg von Frantzius). Taking the picture in front a map of a huge chunk of the world was a brilliant idea (not mine) as it gives some clue of our goals.

Anyway… I intend to wear the shirt to this year’s Polar Bear Dip. If you’re in Ottawa on January 1st and feel like taking a swim, you can join in too!

Here’s a neat and (I believe) completely unintentional feature of Eclipse…

If you’ve added your projects to SCM through Eclipse, it will mark changed files (and directories containing changed files) with an arrow (a “greater-than” sign) in the Navigator and Package Explorer. If you want to quickly flip through the changed folders and files, put focus into the view and hit the “greater-than” sign.

Of course, there is a downside as discussed in bug# 116901.

Denis took me down to the data centre today to have a gander at the Eclipse server rack. It’s pretty impressive (a little slice of nerd heaven). The rack is very well organized with all the cables neatly ordered. It’s all very well thought out and implemented.

We were in the data centre because we had some new power added and Denis wanted to move some of the servers over the to the circuit. While we were there, he checked to make sure that we aren’t drawing too much power from any single circuit and that nothing is overheating (I do love those heat tester gizmos).

Of course, back and the office, he maintains a diagram of the configuration with all the heat and power consumption stats kept up to date.

We don’t say nearly enough about how great a job that Denis does.

One of my bigger challenges is managing a workspace packed with many different projects. As an evangelist, I tend to spend a lot of my time experimenting with stuff and the result is a tonne of projects of various sizes. I do try to close the projects that I’m not currently working on. I’ve also imported a bunch of plug-ins as projects so that I can more easily look through them (the PDE makes this dead easy). I’ve talked a lot over the past weeks about some work I’m doing with an EBay rich client. I’m building it as an example of what you can do with the Eclipse RCP technology, and I’ve organized the application in multiple projects (partially discussed here).

Keeping all these projects straight in the Package Explorer is a real challenge. Here is a screenshot of the Project Explorer in my workspace:

Obviously, I need to clean things up a little (and this is only a subset). I really don’t need a lot of these projects. However, it helps (I think) to make the point: things get cluttered.

At the top-right of the view, there’s a little pointing-down-triangle-thingy that opens a menu when it’s clicked. In the menu, there’s an entry to show either “Projects” or “Working Sets”; oddly enough, this toggles what the view shows. In the above image, it’s showing projects. By setting it to “Working Sets”, here’s how it changes:

There… that’s better. For this to work, you need to actually define your working sets. You can do this in a few different places, but the easiest one is in that same pointing-down-triangle-menu-thingy. Select “Select Working Sets…” from the menu. From here you can choose which existing working sets you want to display in the view (I’ve actually defined a couple more working sets, but have filtered out the ones I don’t care about); you can also create and edit working sets from here.

A working set is just a collection of projects that have some relationship that means something to you. For example, I’ve grouped all the projects that I need for the EBay thingy into a single working set. You can use these working sets in other places. You can, for example, specify a working set to constrain a search (i.e. search only those elements defined in the working set).

Of course, the big problem with working sets and this view is that I’ve completely lost my motivation to clean up my workspace…

I write software interatively and almost always top-down. As such , I tend to rely heavily on the refactoring tools provided in the Eclipse JDT. But I’ve really started to lean on the Quick Fix feature.

When you write code from the top-down, you always start with a lot of errors. Ideally, I start by building JUnit unit tests and then spend the rest of my time making them work. I’ve spoken with a lot of folks who try very hard to avoid ever having errors show up when they hit ’save’; I don’t understand these folks because the errors save you time.

When a red line appears under some part of your Java code, that means there’s an error. If you put the cursor in the code with an error and hit CTRL-1 (on Windows and Linux) to get a context menu with all the possible ways to fix the error. I most commonly use the Quick Fixes to create a new class or new method (since I build things top-down, I tend to use these things before I actually build them). The Quick Fix mechanism generally does a pretty good job of determining things like an appropriate super class or interface for a class, return values and parameters for methods, and such. It builds a pretty good skeleton of the thing you need to make.

There are also Quick Fixes that import missing classes, add exception handling code, or help you fix typing mistakes in class names. It’s all quite wonderful for a lazy person such as myself.

A few days ago, I was building an anonymous class and discovered a new quick fix. I built the class based on an interface that I hadn’t yet added and added a method that doesn’t exist (as is my normal approach). I used the quick fix to build the interface. Building the interface made both errors go away. On a whim, I put the cursor over the method I had added to my anonymous class (which hadn’t yet been added to my new interface) and hit the CTRL-1 not really expecting much to happen. However, the menu did contain something useful: a quick fix to create my method in the super type (the interface).

So you can even quick fix things that don’t even appear to be broken. Very cool.

I came across SWT Snippet192 today which shows some cool new features that are being added to Eclipse 3.2.

I have a table in my application that I want to sort. Sorting is pretty easy to make work in table, but there’s one thing missing: the sort indicator. That is, there is no way in Eclipse 3.1 to indicate which column the table is sorted on or in what direction. As I mentioned in the first sentence above, this has been fixed in Eclipse 3.2.

However, I’m still doing work with Eclipse 3.1, so I need a solution. I’ve built a TableSorter class that takes care of all things to do with sorting tables. You just have to register each “sortable” column and provide a java.util.Comparable that describes what it means for that column to be sorted in ascending order (for my purposes, it was easy enough to derive the descending sorter). The TableSorter takes care of keeping track of the current sort column and the direction of the sort.

To provide a visual cue to the user, I’m simply changing the icon on the column header to indicate direction. It feels a little clunky (as it causes the column header text to move around), but I’m considering it a temporary workaround that I’ll fix when I move the application to 3.2.

I wrote a while back about life goal #129 and the resulting bug raised against my person. Frankly, the whole process has been very exciting for me, but–alas–we’re getting close to closing this bug.

I had an opportunity today to stop by the bookstore and pick up a copy of the new Eclipse Rich Client Platform by Jeff McAffer and Jean-Michel Lemieux.

It occurred to me today as I was looking for the book that there are a lot of titles on there discussing various aspects of Eclipse. I thought I might take this opportunity to list a few of my favourites.

Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications by Jeff McAffer and Jean-Michel Lemieux. I’ve written a full review of this book.

Contributing to Eclipse: Principles, Patterns, and Plug-ins by Erich Gamma and Kent Beck. As a matter of practice, I read everything that Kent Beck writes (though I have to admit that I didn’t enjoy Test Driven Design as much as I had hoped I would). I like this book a lot, but I find the example they use throughout the book a little too confusing at times. Maybe that’s not so bad as the book actually forces the reader to think and thinking’s not a bad thing to do. Still, the book has a lot of great and useful information if you’re serious about building plug-ins. I especially like the collection of rules they introduce.

Official Eclipse 3.0 FAQs by John Arthorne and Chris Laffra. The thing that I like most about this book is that I didn’t have to actually read it. It collects frequently asked questions about Eclipse which are easily found using either the table of contents or the index. Once you find the right question (and answer), the book directs you to related questions. The one problem with this book is that it can become outdated rather quickly; however, at this point, most of the information in the book is still relevant.

Of course, these are my favourites from the subset of all the great books on Eclipse that I’ve actually read. It’s a little curious that all these books are from the same series (”The Eclipse Series” by Addison Wesley). I think I might purposefully pick one that’s not from this series next time.