I've finally got some cycles to catch up on E4 a bit. The first thing I notice is that in E4, you wind up with a lot of code that looks something like this: (from http://www.vogella.de/articles/EclipseE4/article.html)

public class View1 {
	@Inject
	public View1(Composite parent) {
		Label label = new Label(parent, SWT.NONE);
		label.setText("E4 is new");
		Text text = new Text(parent, SWT.NONE);
		text.setText("and different");
	}
}

The first thing I notice is the dependency injection: there's no explicit dependency on Eclipse anywhere to be seen.

I haven't worked out all the implications of that @Inject annotation, but at first blush this sort of thing would seem to make E4 *much* more testable than previous versions of Eclipse were.

If I'm right, this is pretty huge. It's not exactly a killer feature, but it's very important.

Thoughts?

Last week I gave a presentation on refactoring regular Java code toward a Scala DSL to the Chicago Area Scala Enthusiasts (CASE). Along the way, I discovered a really cool way to use the Eclipse Mylyn tool to solve a perennial presenter's problem: how to smoothly switch between various code examples during the presentation.

As one of the few Eclipse people who normally works on Linux (currently Ubuntu), I am used to the cool Compiz feature of rendering my desktops on a 3d cube that visibly rotates (in 3d) to switch between different desktops. When presenting this is handy because I like to put the slides on one face of the cube and Eclipse (with a workspace containing my code examples) on another face of the cube. Then I can simply rotate the cube to smoothly switch between Eclipse code examples and my presentation slides.

But once I'm in Eclipse, I normally have several code examples that I would like to use to illustrate the points I am making.

It turns out that the Mylyn tool provides a really handy way to switch between code examples. It even automatically highlights the important parts of the code in the Package Explorer in the process.

So before I present, I create a new Mylyn context for each example I want to show. I then record into the context the Mylyn landmarks I want to make sure I cover in the presentation. These landmarks wind up boldfaced inside the Package Explorer.

Then during the presentation, I can simply switch between contexts using the Mylyn Task List. When I do this, Mylyn automatically opens and closes the right editors, and highlights the correct parts of the code in the Package Explorer for showing the next code example.

The result is that I can keep track of where I am more easily in the code examples (since the important parts are automatically highlighted), and–for the same reason–it's also easier for the audience to follow what I am trying to communicate.

Slides for last week's Scala meetup presentation in Chicago are posted on SlideShare:

http://www.slideshare.net/dvorme/refactoring-to-scala-dsls-and-liftoff-2009-recap

The topic was “Refactoring to DSLs (for beginners)” and “Scala LiftOff 2009 Recap”.

The meeting was fun, the audience one of the best I've ever presented for. I got some requests to present my Eclipse RCP UI DSL next time I present, so we'll plan for that.

I'll be speaking at the Chicago Area Scala Enthusiasts (CASE) meeting this coming Thursday. We'll cover the following:

• News from the Scala LiftOff East in Reston Virginia two weeks ago
• I'll talk about using DSLs written in Scala to improve Java projects

Although I haven't decided on the final content yet, topics I'm considering in order to illustrate this second point include:

• Showing how to use the excellent Specs unit testing DSL (a great way to get Scala into a Java shop)
• A “Make”-like DSL I wrote as my first DSL (doesn't nearly everybody?)
• Simplifying Java code by evolving Java into a Scala DSL by translating to Scala and then stepwise introducing Scala idioms

I'd love to hear about what people what to hear about. Please comment.

To sign up, please visit: http://www.meetup.com/chicagoscala/ before noon, the day of the event.

Sometimes you get on an airplane–or into a release process, and partway through the flight, something exciting happens.

You never want this to happen, but sometimes it happens anyway. And it becomes an opportunity to find out just how resilient your processes are.

One time I was on the way between Chicago O'Hare and Los Angeles International, and suddenly the airplane hit a really big bump, the captain instantly turned on the “Fasten Seatbelts” sign, and announced that we'd run into a bit of “unexpected weather”. As it was night, and I had a window seat, I then had a fantastic view of the lightning flashing around us when I looked out the window and saw thunder clouds towering from far below us to high above us.

This week, our agile team had the equivalent of the “fasten seatbelts” sign come on when our team's build server went down 1 week before our ship date and just as we were entering the testing phase of our release process.

No worries, we thought. We had prepared for this eventuality and simply moved the build to a backup machine while we waited for the primary machine to get the attention it needed to come back online.

Then yesterday–one day before our scheduled ship date and the day we were scheduled to build our gold master release–the backup build server suffered a catastrophic hardware failure. New machine needed. We had a day to rebuild our machine from original software images and configuration files, build the release, perform our due and administrative diligence, and ship.

However, being part of an extremely risk adverse organization, we had been forced by the organization several months ago to document all of our processes. We had all of the build server configuration files backed up in SVN. And we had the documentation we needed to quickly rebuild the server from scratch if we needed to.

In an 8 hour day's work, two of our team members rebuilt the server. Today, we built the gold release, did our due diligence, and shipped. On time and on budget.

Kudos to my manager and to all the team members who worked hard to implement the agile processes and documentation that made this possible. This is truly one of the greatest teams I've had the privilege to serve on–but we couldn't have done it without the agile practices that we have implemented from day one: agile practices based on Scrum, but with lots of input from XP and Eclipse Way.

At EclipseCon, I had some amazing conversations with various people about the potential to use EMF and modelling technologies to raise the abstraction level, and therefore programmer productivity, when creating user interfaces.

Since then, I've realized that XScalaWT can do all this already, for free, as long as you favor convention over configuration in your code…

More later.

I just have to say: I've been using a recent build of the Eclipse Scala 2.7.4 plugin and finding it really solid and really productive!

• Content assist for the most part Just Works
• Ctrl-click to jump to source so far Just Works, regardless of if the source/destination is Java or Scala
• And of course, the killer feature: integrating ScalaDoc and JavaDoc seems really stable now

All the old compiler crashes I was experiencing are now gone so I can now work for hours without restarting my IDE.

Now to figure out a way to releng mixed Java/Scala OSGI bundles. I hear that Maven is the way to go right now…

To the team: Nice job!

When Oracle joined the Eclipse board nearly seven years ago, it was with the stated intent to unify Sun Microsystems and Eclipse.

Assuming that their purchase goes through, they will have the power to actually do this. Will they?