29 March 2010

Dan Pink on the surprising science of motivation


An astonishing talk on motivation, both fundamentally surprising and scientifically based. Not to mention - very well presented.

20 March 2010

Testing basic Java skils [Q1]

Here is a typical Java interview question - "Are parameters of methods passed by referenced or by value?". And the typical answer I have usually heard is "Objects are passed by reference, where primitives are passed by value". Now lets try and see how this works in the real world.

public class ParameterTest {

public void parameterTester(SomeClass clazz) {
clazz.someValue = "methodChangedValue";
clazz = new AnotherClass();
}

public static void main(String[] args) {
ParameterTest tester = new ParameterTest();
SomeClass clazz = new SomeClass();
tester.parameterTester(clazz);
System.out.println(clazz instanceof AnotherClass);
System.out.println(clazz.someValue);
}
}

class SomeClass {
public String someValue = "initializedValue";
}

class AnotherClass extends SomeClass {
}

Simple question - what would the output be? It is obviously a combination of the following outputs : "true" or "false" and "initializedValue" or "methodChangedValue".

Now if the answer given at the beginning of this article was right, then the object would have been passed by it's reference. If this was true then the output would have to be "true" (since we change the reference inside the test method) and "initializedValue"(because this is the default value of the field). And this would be the wrong answer.

So if we don't actually pass references then we must be passing values (copies) of the objects. If so then the correct answer would be "false"(as the reference should not be changed by what we do in the test method) and "initializedValue" (because even though we modify the value in the test method we actually do it to a copy). And this is again a wrong answer.

The right answer is "false" / "methodChangedValue". The very simple explanation is that:
1. In Java values are always passed as values (both objects and primitives) and these values are copies of the original (thus modifying their values does not reflect the original objects)
2. When passing objects we actually pass the value of their reference. This is where the trick is - we are able to modify the original object, as the reference we are using, although a copy, points to the same object. If we try to change this reference though then the original object stays the same.

Wierd or not, quite a lot of Java developers failed this test when I gave it to them so I decided to put this example in my blog. To be honest I was surprised of the result of the code above myself at first.

15 March 2010

Some findings from the JUnit mailing list

A neat addition to JUnit that can be used for benchmarking : here


* Records execution time average and standard deviation.
* Garbage collector activity recording.
* Per-benchmark JVM warm-up phase.
* Per-run and historical chart generation.
* Optional results persistence in the H2 SQL database (advanced querying, historical analysis).


Intriguing thoughts on how to create mock code that would sustain the test of time : here

Unfortunately I find this article outdated. Especially when one takes into account the mocking frameworks that are currently available. Nevertheless I think the example could describe best how much effort could be lost when unit tests are over-engineered and in the same time how much could be avoided if good mocking frameworks are used.

An interesting, but rather specific discussion on order of execution of tests : here

One of the major new features of JUnit - Categories : here