Mikado method to help refactorings

I found a very interesting method described at http://mikadomethod.wordpress.com/ about how to decompose a large refactoring into manageable chunks, so that it can be done safely (code is never broken).

Eclipse 3.6 is here

The Helios release train is here and with it the new Marketplace that allows users to install plug-ins in the comfort of their homes... er, cubicles. Of course, Erlide 0.8.4 is available from there too!

Erlide update site upgraded

The regular update site at http://erlide.org has been updated to the now not so new p2 update manager format. Only the latest 0.8.3 build is available there.

Older stable releases are to be found at http://erlide.org/update_classic, if you need one of those.

This is so that we can appear on the Eclipse marketplace, which will be integrated in Eclipse in the upcoming 3.6 version.

Retrieving a feature's version number in Eclipse

I wanted to print in the log my feature's version number, but was stumped because features aren't OSGi bundles and there wasn't an obvious way to find them. After realizing that the About dialog displays the features, I looked at its code and extracted this snippet:

IBundleGroupProvider[] providers = Platform.getBundleGroupProviders();
if (providers != null) {
  for (IBundleGroupProvider provider : providers) {
    IBundleGroup[] bundleGroups = provider.getBundleGroups();
      for (IBundleGroup group : bundleGroups) {
        if (group.getIdentifier().equals(featureId)) {
          version = group.getVersion();
        }
      }
    }
  }
}

History of programming

A hilarious post about the history of programming languages: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html.

Google Wave invitation!

I had lost hope that I would make it among the Wave beta testers, but it looks that it just took that long for them to get to the bottom of the list! :-) So now I have an account, I can give it a spin and I'll have to come up with some cool ideas for applications.

Towards erlIDE 2.0: it's not only about code

I've been sketching some ideas for erlIDE 2.0 before, but that was only about the tools needed to handle the source code. Writing code is of course an important part of the development process. In other languages, it is one of the two pillars, the other one being debugging the code. Erlang, however, is different: an Erlang system is alive, and thus it's just as important to be able to architect and monitor it.

Of course these activities could be placed under the two other categories, but I dare to claim that they are sufficiently different from "normal" coding and "normal" debugging that they can stand on their own.

"What's the fuss about? We have that already!" I hear someone mutter there in the back. Um, yes, sort of. There are tools to visualize the process structure, but IMHO they are far from what they can be. There are no tools to help with the architecture of the system and there are almost none to watch it running. Here are some examples:

• visualize and edit the supervisor structure as well as the links and monitors between processes. With a graphical tool, I mean something like right click and add a child, drag and drop from it to create a link to another process, mark the process as trapping exits, and so on. This would of course get saved into the appropriate code modules.
• freeze execution of all application processes and inspect them without fearing that timeouts will kill them
• "sandboxes" for processes, allowing all to be killed and the application restarted without affecting unrelated processes
  
• trace messages live, at full or reduced speed or step-by-step. This could also be done offline, from the logs, but then the processes' data can't be accessed.

Some of these features require extensive support from the VM, so it becomes a matter of how useful these tools will prove themselves at paying customer's site. Which is difficult to find out before having a tool to test, but I am hopeful that there will be a way out of the deadlock (maybe we can build a good enough tool without VM support to use as demo).

I will explore this path further, I think we can get more developer productivity gains from this kind of tooling than from the usual coding and debugging support.