A Floor Wax or a Dessert Topping?

For those as old as I am and as influenced by American culture as most Canadians certainly are, the question "Is it a floor wax or a dessert topping?" likely rings a bell. Unfortunately, because the internet aims to curb the exchange cultural media—I use the term "cultural media" loosely in this case—you likely can't watch the video via that Wikipedia link where you live, but there are alternatives, thanks to the wonders of Google search. How could modern society, and effective software developers, function without Google?  It makes a guy dizzy just to think about it!

I bring this floor wax verses dessert topping question up because EclipseCon is just around the corner.  Like a floor wax, it's a valuable utility, in this case for learning cool new things and for interacting with experts and other like-minded people. Yet like a dessert topping, it's fun, because of the social events, and fattening, because the food is so good. I'm certainly excited to attend yet another EclipseCon. Barring death or disease, I wouldn't miss it! I've been to every EclipseCon and Eclipse Summit, except one.

Eike and I will be presenting Oomph, which is like a floor wax—reducing hours of tedious work to several minutes of automation— and like a dessert topping—recording your preferences and propagating them to all your workspaces.  Perhaps the latter feature isn't even technically a dessert topping, not if you consider the top reasons why some people hate Eclipse. In particular, consider how many of those reasons relate to issues that are addressed by appropriate preferences. Of course that leads to an endless debate about what's the best default preference, i.e., surely no one wants to use Cp1252 as their default workspace encoding. We intend to address this issue with Oomph, so come to our talk and find out about the grand things that are in store.

The biggest problem with Oomph right now is documentation.  Which self-respecting developer wants to spend time on that?  Not only is it a motivation issue, authoring help-center documentation is beyond horrible. So, being tool smiths and OCD, we've worked on making that much easier.  The basic idea is that the documentation is authored as Javadoc, with numerous doclet extensions. It is processed to generate the help center HTML. The overall processing includes a preprocessor phase to produce model diagrams, screen captures, Java snippets, XML snippets, and even tree views complete with their associated properties view.  All this makes the author's life simpler and the end result is way beyond cool. In particular, have a look at the Setup Resources section; this link is likely to change in the coming days when we refactor the documentation using JDT.

Not only have I been busy with these Oomph-related things, Xcore has some dramatic performance improvements in the latest Luna service release thanks in large part to my itemis colleague, Stefan Oehme, a member of the world-renowned Xtext team. And of course there was the usual service and support work associated with EMF itself, but everyone takes that for granted. I also want to thank Jonas for revamping the embarrassingly outdated Modeling home page along with EMF's home page. It's hard to keep up with all these driving factors, but it's definitely better than being bored!

I hope to see you in Ludwigsburg at the end of the month.  Feel free to test my much-improved German skills!  Though be prepared to hear me complain about the complexities of German grammar. Sollte das ein das, ein die, oder ein der sein? Translated literally to the pointless question, should that a the, a the, or a the be?  Note the three gender articles and dangling verb. Don't expect to get the point of a German sentence until you get to the very end.