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.
So watching a movie in Totem & the audio is too quiet – how should one resolve this. Not as quickly or easily as one might hope…
- The volume control inline to the cable on my headphones?
- The volume control buttons on the Thinkpad laptop, aparantly separate from the main soundcard mixer?
- The software volume control in Totem itself, presumably scaling in the GStreamer pipeline?
- The volume control applet on the GNOME panel, with its master volume control?
- The PCM output level in the soundcard mixer application?
- One of the other 10 or so soundcard mixer controls which can be enabled from the mixer preferences, half of which appear to be no-ops?
So, to simply increase the output level of the audio on the DVD I’m watching there’s a choice of 6 possible volume controls to tweak. If any one of these is set too low, it constricts the range afforded by the remaining controls. Why does each application need its own private volume control ? No one seriously listens to mp3s in Rhythmbox, and watches a DVD at the same time, so the master soundcard volume control will cope just fine. Likewise, the plethora of soundcard mixer controls is a complete waste of time – I don’t need to control the headphone volume jack independant of the builtin speakers. What the purpose is the PCM mixer control serving, besides providing another way to make stuff inaudible?
Constrast the situation with a Television. There’s just one volume control, whether I’m using headphones or the builtin speakers, whether its switched to the Cable box, games console, broadcast TV, or DVD player. Not 6, just one. Use a computer as my home media center ? No thanks, I like to spend time watching and listening, not playing hunt-the-volume-control.
The BBC is reporting on the Institute for Public Policy Research’s latest report which suggests that voting be made compulsory in the UK. While some may try to dissmiss such a suggestion on the grounds that it infringes civil liberties, but consider the maths for a minute. With elections once every 5 years, life expectancy of 75 years and a minimum voting age of 18, one can realistically expect to have 11 occassions on which to cast one’s vote in a general election. It is pretty hard to argue that casting 11 votes in a lifetime would result in a measurable impact on person’s civil liberties. Democracy is not something that one can take for granted – those living in the UK are very fortunate in comparison to millions elsewhere in the world living under military rule, dictatorship, and other forms of oppressive government. Democracy as a succcessful form of governance has the idea of accountability as one of its core foundations – if they value democracy, the population has a duty to keep a check on its government; casting one’s vote at time of election is one of the few ways in which change may actually be effected. One vote may not appear to make a difference, but when that’s multiplied by the 40% (or more) of the population who typically fails to vote, it should be clear that really anything is possible. While compulsory voting may not solve voter apathy overnight, it ought to reinforce the message that democracy is something one must work to protect – that it is one’s duty to protect it – both for ourselves & future generations.
WikiPedia has a page on the subject of compulsory voting considering the pros & cons, and listing the places with compulsory voting today. There is an interesting fact at the end – the Massachussetts constitution of 1918 has an article giving the general court the power to enforce compulsory voting during elections, although its never chosen to exercise it yet.
BTW, for those who’ve asked – while I’d like to allow comments to be posted without needing a blogger.com account, every time I’ve enabled anonymous posting in the past the spam-bots have gone wild :-( So they’ll have to remain registered users only I’m afraid. If you don’t want to register you can always email me, or reply via your own blog on Fedora Planet.