davej is wondering how to get Google maps to show you where the Boston T-stops are located. Why, ask Google of course, where upon the first hit is a link to a very handy MBTA station/map overlay. I’ve needed this many times before, so that’s another site for my bookmarks. Well actually, not really – Google is so good at answering these kind of questions that I’ve mostly ceased to keep bookmarks – its just as quick to ask Google for the link each time as to look for it amongst hundreds of un-organized bookmarks.
DV writes that 5 years worth of archives of the xml@gnome.org and xslt@gnome.org mailing lists have gone AWOL. All is not lost, however, since GMane has historic archives of xml@gnome.org stretching back to December 2001, and for xslt@gnome.org stretching back to March 2002. I don’t know if there were older messages than these, but that looks like a sizeable chunk of the archives.
Like many other Red Hat folk, I was down in Nashville for the summit last week. One evening I was chatting with jrb about developers either being “starters” (people who kick off projects & then drift off into other things) or “finishers” (who see things through to the end & put the polish on apps). Well you only have to look at my Mercurial server, to see I’m pretty much a “starter” – lots of code, very little of which is “finished”.
So, this weekend I decided it was time to be a “finisher” for a while. To that end I released an update to the Perl DBus bindings (Net::DBus), and Config::Record. I also applied a little polish to a “mock” test driver for libVirt which I will shortly commit, and continued documenting more of Test-AutoBuild in preparation for a major release (which has been an unbelievable 2 years in the making). All in all, quite a productive weekend.
Oh, BTW, for those who were at the summit – I’ve uploaded copies of my slides which contain a fair bit of extra info compared to the version distributed on the CD. For those of weren’t at the summit – I was talking about management of virtual systems, with a heavy emphasis on libvirt, and a little about the tools we’re building on top of it. Before anyone asks, I plan to make the source for the GUI virtual machine management tool available in the next few weeks.
I was spending a while this afternoon browsing the pictures up on lomography.com and came across a fantastic set of shots with a really interesting idea behind them. Titled ‘Moscow – New York’, the premise is quite simple – two groups of photographers, each shooting in their respective cities, exchange rolls of film and overlay a second set of exposures. My favourite image is their current front page image, but there are hundreds more shots at www.lomohomes.com/moscownewyork
Tom Tromey’s post about the challenges of packaging & distribution Eclipse plugins, is symptomatic of a much larger management problem in Eclipse. A little while back I was involved in designing & implementing a structured development environment for a group of (~20) Java developers. The model was to have a handful of remote servers setup to allow developers to remotely run Eclipse within a VNC desktop. There were three core goals I was aiming to hit:
- Ensure all developers are using an identical development environment / toolchain. So using the same JVM version, populating Eclipse with the same plugins, using the same workspace settings, have the same code checkout.
- Enable new developers to get working with a fully functioning development environment in < 10 minutes. This includes creating a new Eclipse workspace, getting a complete code checkout, building the code & finally be able to run the application
- Enable new machines to be installed & correctly configured to act as development servers with no manual intervention.
While the base RHEL OS build was easily installed & configured with Anaconda’s automated kickstart capability, the deployment & subsequent management of Eclipse, is much more complicated. The crux of the problem is that the model Eclipse (and most other IDEs) operates under, is focused on individual developers. The update manager is one example of this mindset – each developer is expected to individually download & install the plugins they want in their workspace. When a plugin update comes out, each developer has to individually update all their workspaces. When managing a large development team a top priority is to ensure all developers have the same version of all the tools – you don’t want them wasting time debugging problems caused by different tool versions. As an administrator it should be possible to deploy & upgrade plugins for all developers using the regular RPM+YUM model. I partially addressed this by deploying RPMs which install the plugins to a central directory & instructing developers to simply have the update manager install all plugins found at this location.
Configuration of the Eclipse workspace was another big problem. While many settings within the IDE can be classified as “personalization”, an equally large group are what I’d term “functional” (ie they affect the way the application builds). To complicate things a little further, the settings are split up, some associated with the workspace, others associated with individual projects. With the “functional” settings, it is clearly critical to ensure all developers within a project are using the same configuration to avoid wasting time debugging build problems. At times during development of a project, it may be neccessary to adjust some of these “functional” settings; at these times one needs to ensure all developers’ workspaces are updated in a consistent fashion. While Eclipse lets one store the .project files within SCM, there is no facility to manage the enclosing workspace configuration. Storing the .project files within SCM was not a perfect solution either, because it was all to easy for a developer to inadvertantly make changes to the .project file & commit them to SCM, impacting the entire development team. It is possible to import & export workspace settings in a plain text file, however, this does not scale up – it is impossible to ensure all 25 developers have the latest requisite settings file imported.
Getting new developers up & running was a similarly challenging exercise in workspace configuration. There was a painfully long set of manual steps, creating a new workspace, importing a file containing workspace settings, installing extra workspace plugins, configuring an SCM repository, checking out the requisite set of projects from a particular SCM branch. A mistake at any point in the process could result in a huge time sink trying to figure out why the developer could not get the application building in the same way as other team members.
It all really comes down to a question of policy & control. As the manager of the development environment, one should be able to define a “template” workspace which contains all the pre-determined functional settings, loads the neccessary set of plugins, defines the appropriate SCM repository & listes requisite projects. Getting a developer up & running would then merely require invoking a command to the effect of “give me an instance of this workspace template”. With such a capability, new developers would be up & running in a matter of minutes. With all manual setup processes eliminated, one can be sure the developer’s environment is consistent with the rest of the team & they can get straight into doing useful work on the project itself, rather than wasting time on setup.
While Eclipse is a very powerful & flexible tool, there is a very large price to be paid for this, with a great burden placed on individual developers to manage the workings of the IDE itself. This diverts attention from the core goal of getting useful development work done. As the size of a development team grows the management overhead has increasingly detrimental impact on the team’s productivity. To address this problem, IMHO, future Eclipse development needs a much greater emphasis on addressing the management needs of teams, rather than individual developers.