Tasmania is a small place, which is why I’m surprised that very few people in the IT industry here have heard of Morfik, a Hobart based development company. Reading this morning’s Read/Write Web however, things may be about change there. As reported by Richard, slashdot are running a post about the Morfik patent which appears to be aimed squarely at Google’s GWT.

I’m in two minds about this, as I always am about software patents. On the one hand, Morfik was clearly first to the party in terms of public release of a JavaScript compiler, according to the patent they had a provisional granted prior to the release of the GWT. On the other, I have to wonder how this is any different to the multitude of language translation techniques already out there, or at least whether it’s significantly inventive enough to pass the “not obvious to a practitioner in the field” test.

But hey, this wouldn’t be the first patent to be granted despite the obviousness of it to someone with half a brain. I mean, thank goodness the patent doesn’t mention Ruby, I guess that means RJS is safe!

The committer model solves a few problems of open source distributed development, but the primary one is that of trust: in a developers intent and in their competence. There are other issues that push different buttons depending on the project, but in the end, these are just indicators of intent or competence.

Personally, I think this is a bit of an extreme approach in the average commercial development project – certainly for teams under 10 developers I would call it excessive – as the same issues don’t apply in a commercial project.

Firstly, you must implicitly trust the intent of the developers which you are paying to write the software – and if you don’t, why are they working for you to begin with? Secondly, if you’ve hired them, then you already have made a decision based on their competence.

Fair enough, you don’t leave the keys to the castle with them on the first day, but not allowing them to check into a revision control system AT ALL is just asking for trouble in my opinion.

Still, the fact remains that to ensure quality, you can’t have code that was just checked in being rolled straight into a release and expect it to work. There needs to be some sort of gating to ensure that code has been relatively well exercised before it makes it into a release build. So how to compromise?

The way we approach this issue is to maintain a “trunk”, the latest code in development, and release branches, eg 1.0-release, 1.1-release, etc. We have a team of anywhere up to six developers working on various facets of the code at any time. The rules are simple:

1. don’t check into the trunk if your code won’t compile and pass our test suite.
2. if you have done significant work which has caused breakage, create a private branch until you can fulfill 1.
3. only one person is in charge of release “gating”, eg merging code from the trunk into a release branch.

This approach provides the ability for all developers to grab the bleeding edge code, whilst ensuring that code that gets merged into release branches is vetted accordingly. Fixes are applied within the trunk, and backported to release branches if necessary (eg for patch distribution)

In the case of simple changes, this probably takes all of 5 minutes to confirm that the fix does what it needs to do. Bigger changes usually require consultation or a walkthrough with the developer responsible.

In essence, this still implements the same safeguards as the committer model, however you also capture more change history as developers are able to commit small changes as they are made, reducing the risk of introducing widespread errors, or losing large amounts of work through equipment failure.

Personally, it’s rare for me to do a day’s work without committing it all – I’ve seen a hard drive die overnight enough times to be paranoid.

So as a “public service”, here is some code to figure standard deviation in Ruby and Java.

(disclaimer: no warranties as to correctness, particularly to the nth decimal place, don’t use this to run your home made nuclear reactor or air traffic control system, blah blah, etc, etc )

The algorithm I’ll be using is “borrowed” from wikipedia’s entry on Algorithms to calculate variance. Specifically, I’ll be using a variant of algorithm II, which is sourced from Knuth, except we’ll calculate the standard deviation for the population, rather than a sample.

As you should probably know, standard deviation is defined as the square root of the variance. If you didn’t know this, maybe you should go read about standard deviation first.

/**
 * @param population an array, the population
 * @return the variance
 */
public double variance(double[] population) {
	long n = 0;
	double mean = 0;
	double s = 0.0;

	for (double x : population) {
		n++;
		double delta = x - mean;
		mean += delta / n;
		s += delta * (x - mean);
	}
	// if you want to calculate std deviation
	// of a sample change this to (s/(n-1))
	return (s / n);
}

/**
 * @param population an array, the population
 * @return the standard deviation
 */
public double standard_deviation(double[] population) {
	return Math.sqrt(variance(population));
}

example usage:

double[] arr = { 1, 3, 24, 17, 12, 6, 14};
System.out.printf("%f", standard_deviation(arr));
  // prints 7.596992

  def variance(population)
    n = 0
    mean = 0.0
    s = 0.0
    population.each { |x|
      n = n + 1
      delta = x - mean
      mean = mean + (delta / n)
      s = s + delta * (x - mean)
    }
    # if you want to calculate std deviation
    # of a sample change this to "s / (n-1)"
    return s / n
  end

  # calculate the standard deviation of a population
  # accepts: an array, the population
  # returns: the standard deviation
  def standard_deviation(population)
    Math.sqrt(variance(population))
  end

example usage:

 puts standard_deviation([1, 3, 24, 17, 12, 6, 14])
 # prints 7.59699188589047

If you found this at all useful, (or have spotted a bug), please leave a comment to that effect…

Ed Burnette blogs on a nasty little “feature” of Eclipse. First, a little background

Java, C, and C++ share a little syntactic quirk that has bitten all developers on the rear from time to time. Take a look at this code:

if (condition)
doSomething();
doSomethingElse();

The “doSomethingElse();” code will always be executed regardless of the value of the condition because only the “doSomething();” statement is considered part of the “if”.

This has bitten me on more than one occasion on source code that has been checked into our repository and edited by multiple people, causing the indentation to get screwed up (eg tabs and spaces). Especially when you’re scanning code you’re not familiar with, indentation is a key indication of code blocks and nesting.

My preference is to always use braces for code blocks, i feel it’s far more consistent. Ed says:

Some programmers find this overly verbose. It wastes a line on your screen, or two lines if you like putting the opening brace on its own line. However I would argue that maintainability and idiot-proofing the code is much more important.

The reason I mention all this is that some IDEs will helpfully offer to remove these “extraneous” braces for you.

This is evil.

Too right it’s evil. Since when has verbosity been a bad thing when it improves maintainability and understanding “at a glance” ?

Much as a dislike the line breaking feature in Eclipse when you use it to format code… I don’t care if my lines are excessively long, I’d rather have a long line that makes sense, than to break the lines in a non-intuitive manner, which Eclipse is wont to do.
So rest assured Ed, when I download my copy of Eclipse 3.2, this feature is well and truly staying off.