Eclipse Helios is here: Done by 39 project teams, 490 committers, creating/managing more than 33 million lines of code.

Congratulations to everyone whose code is in this release and to everyone who helped manage this thing out the door!

On time. Again.

Wow.

An exciting milestone in the E4 project passed yesterday when John Arthorne posted the following to the E4-dev mailing list:

I have spent the last day or so self-hosting full time using Eclipse 4.0 SDK builds. While there are lots of bugs and errors in the log, I have encountered no impediment that prevented my ability to get work accomplished using these builds as my regular IDE. I strongly encourage the rest of the team, and any bleeding edge adopters in the community, to try use Eclipse 4.0 SDK builds as their IDE for daily development. The sooner we are feeling the pain of bugs as users ourselves, the faster we will make progress in the areas that matter for end users.

To avoid everyone entering the same well-known bugs over and over, and to help focus our priorities for the next milestone, I have started a list on the wiki of “self hosting impediments”. Think of this like our regular end of release polish list, but in our case the polish items are much bigger. Feel free to add things to the list, increase priorities, remove items that are fixed, etc. The list is found here:

http://wiki.eclipse.org/E4/Self_Hosting

There is a new Eclipse 4.0 SDK build available, which includes the latest contributions for this week's 3.6 integration build. If you are using M5 you can upgrade to it by adding the following repository to your available software sites list:

https://build.eclipse.org/hudson/job/eclipse-e4-test/40/artifact/builds/transfer/files/testUpdates-I/

You can find the SDK zips here:

https://build.eclipse.org/hudson/job/eclipse-e4-test/40/artifact/builds/transfer/files/bogus/downloads/drops/I20100413-1146/

This is obviously very early access, very bleeding edge stuff. But the more folks we have testing E4, the better it will be when it ships.

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.