Posted by Administrator on the 5th of March, 2010 at 11:35 am under Testing.    This post has 2 comments.

I just wanted a highlight a post over at the Caffeinated Coder because I thought it was particularly well thought out. In it Russell talks about his changing approach to testing after many years. Often when you read about TDD (or testing in general) it’s from a eager proponent who declares it to be the silver bullet for software quality and efficiency. While is certainly has benefits the pitfalls aren’t often discussed in a well rounded way. It seems to be a bit of a love it or hate it thing.

One thing that really resonated with me was the following:

“It also occurred to me that just because you write a test doesn’t mean that you have to commit it. There are several design artifacts (whiteboard, napkins, etc) that are extremely helpful despite being disposable. Occasionally writing throw-away tests would certainly allow me to gain the design benefit without incurring the cost of maintaining a test that has little long term value.”

I think that’s a very valuable point. Sometimes just writing a bit of code to exercise the code you wrote is enough and the extra effort to turn it into a complete test isn’t worthwhile. Even ignoring the initial cost of making the test repeatable and robust there is an ongoing maintenance cost that shouldn’t be discounted.

One language I’ve been getting to know recently is Clojure. One of the (many) things I love about Clojure is the REPL. Clojure is very well suited to exploratory testing. In Clojure it is very typical to build things from the bottom up. Write a bit of code in the REPL, call it, poke around and continue building on it. My point being that you can get a lot of value with this sort of one off “testing”.

Posted by Administrator on the 20th of August, 2009 at 11:13 am under Uncategorized.    This post has one comment.

I came across The-Pac-Man Dossier the other day. It is fascinating reading. It’s easy to look at a game like pac-man and think… well that would be easy to program - a one screen maze with some ghosts with some fairly basic path finding - what could be hard about that. Well actually programming wise probably not much at all but when you read the descriptions of how the various ghosts track your movements around the maze you realise that a lot of thought was put into getting the ghost behaviour just right.

It’s not that the ghosts are particularly smart. They’re not. It’s just that the simple rules that have been applied to those ghosts have been very carefully crafted and refined. That’s where a lot of the real work was done. Given those rules carefully laid out in a specification I’m sure it would be very easy to come up with a working copy of pac-man very quickly. Inventing pac-man from scratch though is another thing altogether. It’s unlikely that you could sit down write down a specification and expect that your new invention of pac-man is going to play as well as you’d expected. Inventing a behaviour like that takes a lot of iteration and tuning.

It’s easy to write some path finding code that accurately steers the ghosts towards pac-man but that leaves you with a dead pac-man very quickly and not a very satisfying game. You could then add randomization to the ghosts choices but then you have a game where you can’t predict behaviour very well. If you can’t predict behaviour it’s difficult to actually form reasonable strategies to play the game - again this leads to a unsatisfying game.

So the real genius of pac-man was not the code that made up the game but the iteration and tuning that went into the relatively simple rules that drive the game.

Posted by Administrator on the 15th of December, 2008 at 9:07 am under Technical.    This post has 2 comments.

I’ve been using Google Chrome recently. For the most part it seems to be a stable and fast browser. I have had a problem at home with it importing my bookmarks. The real killer for me at the moment is the lack of plugins. If they come out with delicious, adblocker and firebug plugins I would probably probably switch completely away from Firefox.

Posted by Administrator on the 8th of December, 2008 at 2:41 pm under Java and Technical.    This post has 2 comments.

After warning someone about the problems of double checked locking I discovered it’s been fixed in Java 5. Simply add the volatile keyword and it’s all good.

See Wikipedia for all the details.

Posted by Administrator on the 19th of November, 2008 at 10:31 am under Technical.    This post has one comment.

The book The Art of Unix Programming outlines some of the conventions that good Unix programs often follow. One of these is the Rule of Silence:

Rule of Silence: When a program has nothing surprising to say, it should say nothing.

When most Unix command lines run, you know they worked because they don’t spit out a error. If you want more detail you can typically apply a verbose command line switch to get more detail but generally speaking you run the command and you trust that it worked because there is no error written to the screen.

Contrast this with Ant. While Ant is a great tool and has made my life much easier however the typical Ant script will spit out so much detail, detail I just don’t care about in 95% of cases. Not just a screenful of stuff but multiple screenfuls of stuff. To find the needle in the haystack is a bit challenge. Even the -q quiet switch still outputs a ton of details. There seems to be no ‘really really be quiet switch’ that I can see.

Next time I write a command line program I’ll be thinking carefully about whether what I write to the screen.

Posted by Administrator on the 2nd of September, 2008 at 10:10 am under Javascript.    This post has one comment.

IE continues to amaze me with the most bizarre bugs.

Posted by Administrator on the 5th of May, 2008 at 2:15 pm under Java.    This post has one comment.

I think my favourite blog at the moment would be Charles Nutter’s. You can always count on him for enthusiastic informative postings. It isn’t hard to tell he loves his job - it comes through very strongly in his posts. His last post was a pearler. In it he talks about call site optimizations and the massive improvements they have made in the current Groovy 1.6 beta builds.

As I’ve posted in the past I’ve been impressed by the flexibility of Groovy. In spite of this I’ve been reluctant to recommend it for anything particularly heavy duty as it’s really way too slow. I expect a language as dynamic as Groovy to be slow however Groovy 1.5 is _very_ _very_ slow so it’s great to read about some the improvements in this area. I’m sure Groovy will never be a speed demon, it was never made for that - but if they get can to the level of being _fast enough_ then that will be awesome.

One thing his post has done for me has shown that the Java virtual machine has got real promise. Perhaps one day Java will no longer be the primary language we use to access the JVM. Perhaps one day it will be the platform that gets all attention regardless of whether it is JRuby, Python or Groovy we use do the actual programming. Either way the Java HotSpot compiler is an amazing piece of technology that I’m sure will continue to have a strong future.

Posted by Administrator on the 18th of April, 2008 at 10:27 am under Java.    This post has one comment.

Charles Nutter is in on the fun with a Ruby version:


def subn(n, list)
    return [[]] if n == 0
    return [] if list.empty?

    remainder = list[1..-1]
    subn(n-1, remainder).collect {|it| [list[ 0 ]] + it } + subn(n, remainder)
end

That made me realise there was some further things I could do to cut things down although realistically I don’t think you gain much at this point:


def subn(n, list) {
    if (n == 0) return [[]]
    if (list.empty) return []

    def remainder = list.subList(1, list.size())
    subn(n-1, remainder).collect { [list[ 0 ]] + it } + subn(n, remainder)
}

As with the Ruby version I’ve removed the semicolons and the return statement at the end. I would have liked to use the 1..-1 array range to get the remainder but could not. Groovy supports this however there is a slight difference between list.subList(1, list.size()) and 1..-1 in Groovy. In Ruby this does not seem to be the case.

Take the following:


a = [1, 2, 3]
b = a[1..-1]

In Groovy b will be [2, 3] as expected. If however our array is only 1 element long as follows:


a = [1]
b = a[1..-1]

We get an error:

Caught: java.lang.IndexOutOfBoundsException: toIndex = 2

So what’s going on here? Well, if I understand correctly our range is being mapped to 1..0 at runtime which is not really what we want. I’m told on the mailing list that 1.5.5 and 1.6 has included the methods list.head() and list.tail(). This should mean we can do something like:


def subn(n, list) {
    if (n == 0) return [[]]
    if (list.empty) return []

    subn(n-1, list.tail()).collect { [list.head()] + it } + subn(n, list.tail())
}

Obviously Ruby array indexing is resolved differently from Groovy.

Posted by Administrator on the 17th of April, 2008 at 4:30 pm under Java.    This post has 4 comments.

I came across a post on (cadr life) the other day about creating a function to find all subsequences of a list with a certain length. The Java version was particularly icky and in his post he shows the equivalent code in a couple of languages. I thought it might be interesting to try it in Groovy so I fired up Intellij Idea and pasted the Java version in.


private static < T > List< List< T >> subn(int n, List< T > li) {
  List< List< T > > ret = new ArrayList< List< T >>();
  if (n == 0) {
      ret.add(new ArrayList< T >());
      return ret;
  }
  if (li.isEmpty()) {
      return ret;
  }
  T x = li.get(0);
  List< T> xs = li.subList(1, li.size());
  for (List< T> sub : subn(n-1, xs)) {
      sub.add(0, x);
      ret.add(sub);
  }
  ret.addAll(subn(n, xs));
  return ret;
}

Because Groovy is so close syntactically I was able to paste this in as is and run it without modification.

For my first step I thought I’d remove the static typing. I’m not against statically typed code but for such a small self contained function I’m not sure it adds much.


def subn(n, li) {
    def ret = new ArrayList();
    if (n == 0) {
        ret.add(new ArrayList());
        return ret;
    }
    if (li.isEmpty()) {
        return ret;
    }
    def x = li.get(0);
    def xs = li.subList(1, li.size());
    for (sub in subn(n-1, xs)) {
        sub.add(0, x);
        ret.add(sub);
    }
    ret.addAll(subn(n, xs));
    return ret;
}

While this reduces character count it doesn’t change the structure at all. At best it’s very slightly clearer than the original.

Next step was to use array literals:


def subn(n, li) {
    def ret = [];
    if (n == 0) {
        ret.add([]);
        return ret;
    }
    if (li.isEmpty()) {
        return ret;
    }
    def x = li.get(0);
    def xs = li.subList(1, li.size());
    for (sub in subn(n-1, xs)) {
        sub.add(0, x);
        ret.add(sub);
    }
    ret.addAll(subn(n, xs));
    return ret;
}

Nice, some more characters trimmed. By simplifying the if statements we can cut back a bit more:


def subn(n, li) {
    if (n == 0) return [[]];
    if (li.isEmpty()) return [];

    def ret = [];
    def x = li.get(0);
    def xs = li.subList(1, li.size());
    for (sub in subn(n-1, xs)) {
        sub.add(0, x);
        ret.add(sub);
    }
    ret.addAll(subn(n, xs));
    return ret;
}

I’m not really a fan of short variable names so next step is to rename some variables. In addition to this I’ll change the loop slightly to use the each function. The ‘it’ magic variable replaces the ’sub’ variable.


def subn(n, list) {
    if (n == 0) return [[]];
    if (list.isEmpty()) return [];

    def ret = [];
    def head = list.get(0);
    def remainder = list.subList(1, list.size());

    subn(n-1, remainder).each {
        it.add(0, head);
        ret.add(it);
    }
    ret.addAll(subn(n, remainder));
    return ret;
}

By adding the collections together we can simplify the loop a bit more:


def subn(n, list) {
    if (n == 0) return [[]];
    if (list.isEmpty()) return [];

    def ret = [];
    def head = list.get(0);
    def remainder = list.subList(1, list.size());

    subn(n-1, remainder).each {
        ret.add([head] + it);
    }
    ret.addAll(subn(n, remainder));
    return ret;
}

Looking at the code it becomes clear that the ‘ret’ variable is just accumulating the results. We can use the collect method for this purpose instead.


def subn(n, list) {
    if (n == 0) return [[]];
    if (list.isEmpty()) return [];

    def head = list.get(0);
    def remainder = list.subList(1, list.size());

    def ret = subn(n-1, remainder).collect { [head] + it }
    ret.addAll(subn(n, remainder));
    return ret;
}

In fact we really don’t need ‘ret’ at all if instead we just add the two collections together:


def subn(n, list) {
    if (n == 0) return [[]];
    if (list.isEmpty()) return [];

    def head = list.get(0);
    def remainder = list.subList(1, list.size());

    return subn(n-1, remainder).collect { [head] + it } + subn(n, remainder);
}

Finally lets inline the head variable. It’s only used in one place anyway so not really worth keeping it. In addition we’ll use Groovy list indexing to remove the get() call.


def subn(n, list) {
    if (n == 0) return [[]];
    if (list.isEmpty()) return [];

    def remainder = list.subList(1, list.size());
    return subn(n-1, remainder).collect { [list[ 0 ]] + it } + subn(n, remainder);
}

Simple. In my opinion this is much clearer than the original and we managed it by making small incremental changes from the Java version.

A lot of the clarity comes from the fact that we have closures. In fact in his next post Ray posted an example using the Java BGGA closure proposal. Here it is reproduced below:


import static com.cadrlife.ListUtils.*;
...
private static < T > List< List< T >> subn(int n, List< T > list) {
    if (n == 0) {
        return Collections.< List< T >>singletonList(new ArrayList< T >());
    }
    if (list.isEmpty()) {
        return new ArrayList< List< T >>();
    }
    T first = list.get(0);
    List< T > rest = list.subList(1, list.size());
    return addAll(collect(subn(n-1, rest), {List< T > sub => push(first, sub)}),
                  subn(n, rest));
}

While this is a big improvement from the original it is still clouded by a lot of syntax noise IMHO. Either way I’m very keen for closures to make it into the language.

Update: Fixed the formatting. I wish wordpress was a bit nicer with pasted in source code

Posted by Administrator on the 19th of March, 2008 at 12:56 pm under Java and Technical.    This post has 3 comments.

I like to think I’m reasonably up-to-date with Java technologies but then I discovered something today that shows up that I’m still ignorant of a lot of available technology that’s out there. Today I ran across hamcrest which is now apparently part of junit 4.4 and above.

Basically it replaces the old assertEquals() & variants with an assertThat statement. ie:


assertThat([value], [matcher statement]);

Some examples:


assertThat(x, is(3));
assertThat(x, is(not(4)));
assertThat(responseString, either(containsString("color")).or(containsString("colour")));
assertThat(myList, hasItem("3"));

Basically all sorts of matchers are possible. The advantages here are improved failure reporting and a clearer expression of intent.

There’s some other interesting stuff built around this too - such as hamcrest collections. Take a look at this:


smiths = select(people, where(Person.class).getLastName(), equalToIgnoringCase("smith"));

Looks like good stuff to play around with over the next few days.