The Engine

Document your Eclipse obsession!

Fri, 22 May 2009 11:17:08 +0200

Eclipse has been and still is pivotal in almost all of the projects I have been working on, thus far. I can't remember the amount of times I have already downloaded that 120-ish megabyte drop, but we're talking high numbers here.

Doug Shaefer's Wascana is in there, for sure. I was really sad when I read about his decision to call it quits, but I do understand. There seems to be a poor understanding of the challenges the concept of 'Open Source' faces. I think 'Strong Governance' is needed, when resources are limited. We do not have the luxury of choice, contrary to what many sheepishly advocate. I don't need two ways to connect to a Subversion repository. I just need one which works out of the box. What's up with GMF, as people are abandoning GEF because it doesn't support their needs? Since when is Maven integration a good idea?

I admit, the 1.0 version is only there to scare the children. And to show 'Final Boy', that peculiar junior consultant, who insisted on putting the 'final' keyword everywhere, without actually understanding what it means.

Come on, send in yours!

The RFID-enabled Eclipse IDE, part I

Mon, 18 May 2009 14:32:23 +0200

Can alternative input methods help?

As it stands today, most of us still use a keyboard and a mouse to convey our intentions to the software running on our computers. You might consider touch screens, popularized through the iPhone, as a novel way to interact with your gizmo, but that's just a variation of typing and moving, all at the same time. Although there already has been a lot of research in this area, alternative input methods have not hit the mainstream, yet. Speech recognition looks promising, but can you imagine dictating code to your IDE, out loud? Typically, specialized input methods only make sense in the niche they were designed for. Jean-Dominique Bauby wrote his book 'The Diving Bell and the Butterfly' by simply blinking his eyelids. Tragically, as he suffered from Locked-in Syndrome, it was the only method left to him. And despite all the research, some of the really appealing interfaces are only 'on display' in science fiction movies, such as the one Tom Cruise is gesticulating with in 'Minority Report', or the plug that fits snuggly into Keeanu Reeves' Occipital bone of the skull in 'The Matrix'. A company called Emotiv claims that the future is already here, however. They've come up with a head set, called 'EPOC', which translates your brainwaves to allow for some interaction with your PC. Great for games, apparently. And for switching Eclipse Perspectives, no doubt.

For those of you who might even consider more 'indirect' methods, such as trained animals, the only thing to remember is: 'Don't!' You might think that you can get away with kittens agreeing to EULA's. But isn't that you just being cocky? Because maybe, just maybe, once that paw hits enter, SWAT teams may invade your home and rearrange your furniture. You would end up living a life in fear, always on the look-out for laser pointers dotting your forehead through the venetian blinds (not to mention you would look cross-eyed all the time). And that's just cats. Ever since the unfortunate lab fire of '07, all research on the subject of 'coding through squirrels' has been banned. And rightfully so. Yes, they can generate sparks by striking flint stones against a stainless steel surface. No, they'll never get the hang of remote debugging. Just move on. It's either that, or watch the flames lick across the rooftop of your favorite Starbucks, next door. Squirrels: probably only put on the surface of the earth to prove Darwin wrong! No, you 'd better stick to finding new input methods using inanimate objects. And RFID technology. Yeah, that'll work. But will it work with Eclipse?

As the ECF project has already demonstrated with its 'Shared Editing' feature, the prevalence of the 'Command Pattern' in Eclipse's architecture makes it easy to invoke actions otherwise triggered through keyboard or mouse interaction. With a home-made set of plug-ins, actions can be invoked from inside Eclipse, by putting RFID-enabled objects on a connected RFID reader. The plug-ins come in two groups. One group is a set of pure OSGi bundles, containing all the services required to (1) detect RFID readers, (2) manage 'drivers' for all supported readers and (3) propagate RFID card events to interested parties. The second group is a set of RCP plug-ins, containing all the plumbing to (1) show visual feedback of the interaction in the workbench trim area and (2) manipulate the Eclipse command stack. The system records the necessary data, in case the command is parameterized. The plug-ins do not interfere with the normal operation of the Eclipse IDE. The workflow is straightforward, as demonstrated in the following movie. The reader in the demonstration is the ACR 128 USB reader, manufactured by ACS from Taiwan, and uses a PC/SC software interface.

Just to give you an idea of what can be recorded and replayed at the moment: (1) Refresh Workspace, Import/Export (without completion) and Add Bookmark (requires selection), (2) Undo/Redo and Select All, (3) Refactor History, (4) Navigate Back/Forward, (5) Build and Clean Project, (6) Run Last Launched and Run External Tool, (7) Customize, Save, Reset and Close Perspective and (8) Welcome, Help Contents, Dynamic Help, Cheat Sheets and About. A lot of commands respond to selection: they operate on a resource selected in one of the views or editors. Admittedly, a shortcoming of the current implementation is that the selection is not restored prior the invocation of the recorded action. That should be feasible, but the solution introduces another problem. The real power of the system lies in the ability to exchange a physical card with a colleague, in order to allow her or him to invoke that same action. Although this can easily be done using ECF, the need arises to synchronize state between two different Eclipse Workbench instances. E.g.: sharing a bookmark using an RFID card requires both the bookmarked file, as well as the bookmark itself available on both instances.

Coming up in part II: starting Mylyn tasks with rabbits!"

Leveraging Agile Practices with the RFID-enabled Eclipse IDE

Thu, 8 Jan 2009 05:34:46 +0100

The pursuit of new input methods for Eclipse might have suffered a major set-back, as it dawned on all parties involved that trained squirrels would not be the next big thing. At first, the results looked promising. After all, those pesky fur balls seemed to be able to pick up subtle cues conveyed through body language alone. Just a little nod to indicate that it was time for the Java Perspective. Lifting a brow or two to scroll through the files in the Navigator. Or bolder: assuming the fetal position to have the Workspace refreshed. All that value in return for just some nuts and raisins. And they were so cute, too! Until they turned evil, that is, when all hell broke loose and a squeaky pandemonium ensued. Where did it all go wrong?

Clearly, it was time to go back to the drawing board. Why not try passive RFID tags? Passive... sounds harmless, right?

At the next EclipseCon, I'll be presenting the RFID-enabled Eclipse IDE. And because it's not just about raising the geek factor, I hope to show you can do something useful too. Since the Agile approach encourages tangible interaction, physical objects are welcome to participate in the software development process. More specifically, with RFID those objects allow you to interact in a novel way with your Eclipse IDE.

RFID-enabled Story Card

Sounds intriguing? If I managed to get your attention, I hope to see you in Santa Clara soon! A special thanks to Bjorn Freeman-Benson for making this possible. If he brings a personal item, we'll teach it some new Eclipse tricks ;)

Don't forget to register early, I did!

Eclipse 3.4: Ganymede has landed!

Fri, 27 Jun 2008 14:18:05 +0200

I'm so happy I can hardly contain myself!

Byzantine or Babylonian Confusion in Eclipse?

Mon, 26 May 2008 02:13:05 +0200

The entry in Wikipedia on Byzantine Fault Tolerance seems to suggest that the failure of a compiler to report rigorously on the remaining code base, once a syntactical error has been encountered, is an example of a Byzantine Fault.

Somehow, as Byzantine Fault Models are a topic of study in the field of distributed computing, this example feels a bit out of place. The stated problem does not illustrate a specific known issue with distributed compilers either, since it can easily be demonstrated with a compiler running on a standalone single-processing machine. Is this example perhaps the result of Babylonian confusion?

The above example shows a first attempt to make the compiler trip over itself and generate a superfluous error, but does it? Unfortunately, this little ambush yields only one error in the Problems View: in the Java Editor the access modifier of the constructor is flagged as the offending syntax. That's a near miss, of course. The screenshot is taken from the JDT bundled with Eclipse 3.2.2. It can be reproduced on Eclipse 3.4M7.

Remarkably, the Outline View shows a class with the alledgedly offending constructor visible. The incremental compiler of the JDT has classified this error, but managed to create a class file nonetheless. Other objects can invoke this constructor. The fact that a marker is reporting an issue on a working construct is very confusing. It would not be unfair to flag this as a JDT bug. Even if the broken statement is the cause for the compiler's faulty marking, at the least the broken statement should have been marked as well.

A quick comparison with the competition, Netbeans 6.0.1 shows that it can be done. Netbeans complains that it cannot find the class dontSto.

This run-in with the unexpected behaviour of the JDT compiler might have taken the attention away from the original question, yet so far there is no tangible evidence to support an analogy with the underlying Byzantine Generals problem. The compiler is simply struggling with problems studied in the field of Formal Languages Theory. Call it a Babylonian Fault instead if you will, even by granting some vague similarity in terms of recognizing a locus of fault, Byzantine it surely is not.