Corey Haines Visit to Icosystem

Friday the 26th was a fun day at Icosystem. Through a random chain of events Corey Haines stopped by as part of his pair programming tour. I had the opportunity to pair with him for a few hours and talk a lot of shop.

Pairing is always a fun activity and it's really fun to pair with someone you've never paired with before. Not only do you get some work done, but you get a nice view into some else's coding process, asthetic, and you always learn a few new tricks. I picked up two things from Corey that I'll be trying out:

• When doing a refactoring, only allowing one test to be failing at a time. It's hard to do, but I liked how it felt.
• The pomodoro technique - Work for 25 min, take a 5 min break, use a timer. I installed Pomodoro 0.24 for OS X. It puts a nice little timer in my application (what is that thing called?) bar. Maybe it's a great process or maybe it's just something new, but so far it's a nice tool and is keeping me focused. Another nice feature of it is you note what the task is you're working on. I don't know about you but I have to fill out timesheets for billing, any tool that helps with that is great!

I'm sure there were other things I picked up but they're not coming to me right now.

Because of Corey's visit I met a bunch of the Ruby folk in the Boston area. It really made me realize how lacking the Java community is in having a... community. I might have to start going to the bostonrb meetings just to hang out with folks who like to talk about coding. Maybe they won't mind having a Java hacker in their midst :P

Writing this post took me, 27 minutes, I'm terrible at the Pomodoro technique

The Downfall of Agile Hitler

Who knew Agile could be so hilarious: The Downfall of Agile Hitler

Also a little less funny but also great: Hitler Does Unit Testing

Learning Clojure - Calling Clojure From Java

Last night, we played with some of Clojure's interop with Java. We tried out with great success Jay Fields little example. Next up was compiling Clojure to Java class files (this was much trickier).

The documentation is pretty good and can be found at: http://clojure.org/compilation and under the (gen-class) API entry. There are two tricky bits, 1) the extra 'this' arg 2) the classes compilation directory.

But first the code sample:

(ns printer
  (:gen-class
   :methods [[printString [String] void]]
  )
)

(defn -printString [this arg]
        (println arg))

:gen-class is the directive to the clojure compiler that it should compile this .clj file into a java class. The :methods section allows us to define methods, we're defining the printString method which is a void and takes a String as it's arg.

The clojure function must begin with a '-' and then there's the 'this' arg. It took a little bit to find the 'this' gem in the documentation on the compilation entry (seriously, who reads everything before they start experimenting)

hasNext and next are implementations of methods in the Iterator interface. While the methods take no args, the implementation functions for instance methods will always take an additional first arg corresponding to the object the method is called upon, called by convention 'this' here. Note how the state can be obtained using an ordinary Java field access.

So no matter what method you expose to java it will alway have at least one arg which is the instance of the object. I can't tell you how many times we were so confused why we were getting wrong number of arg error messages when first trying this out.

Now to compile:
java -cp clojure.jar:. clojure.main -r
user=>(compile 'printer)
java.lang.RuntimeException: java.lang.ClassNotFoundException: printer$_printString__4 (NO_SOURCE_FILE:0)

This is because you didn't create 'classes' directory and add it to your classpath, it's exactly what the error says right?
create the directory, add it to your class path and try again
java -cp clojure.jar:.:classes clojure.main -r
user=>(compile 'printer)
printer

Great, hopefully there are no more exceptions, try javap on printer.class you should see something like:

zacharyshaw$ javap classes/printer
public class printer extends java.lang.Object{
    public static {};
    public printer();
    public java.lang.Object clone();
    public java.lang.String toString();
    public boolean equals(java.lang.Object);
    public int hashCode();
    public void printString(java.lang.String);
    public static void main(java.lang.String[]);
}

Now you should be all set to call through to your printer.class

public class Foo {
 public static void main(String[] args) {
  new printer().printString("hello world");
 }
}

There's loads of different things you can do, like implementing interfaces, extending classes etc. I'm really looking forward to seeing how I can integrate clojure into one of my projects (only where it makes sense of course :P )

Regurgitation

• Mark Levinson has a nice blog post on agile mailing lists, it's a good collection of interesting lists.
• Started a new project and am using infinitest it's great!
  I love how hard-core it makes testing. When I suggested to a few co-workers that they install it, I started getting questions: "so how do I turn off those compilation errors it creates?" Answer: "fix the tests or turn off the plugin"
• Kent Beck had an interesting blog post To Test or Not to Test? That's a Good Question.
  I really recommend checking out his blog, the content is great (I think I'll have to suck it up soon and try out junitmax, maybe for my next project)
• My weekly Clojure learning sessions are still going strong, got my Programming Clojure book in the mail last week, it's nice to have a paper copy.
  We're working on putting penalties (in the form of delays) if you hit the direction keys too frequently. I finally feel like I'm getting a feel for the language.
• and apparently Rich Hickey doesn't like testing: http://blog.objectmentor.com/articles/2009/06/05/rich-hickey-on-testing

Unit Testing in a Different Language Than Actual Code

I've been at talks before where it is encouraged if you're interested in learning a new language to write your unit tests in that language, even though your source code is in another language. For example, if your code base is in Java the suggestion is that you should write your unit tests in Groovy, or Scala, or something else that is awesome.

I understand certain pragmatic reasons for this. Sometimes, it's hard to find the time to learn a new language, and it's less risky to experiment with a new language in your unit tests than in your production code.

But if you're trying to practice TDD (which I think is a pretty good idea) writing tests in a language that differs from your source code is risky. TDD allows you to explore and try out your new APIs like the clients of those object would. It's not only about making sure the code as you envision works, it's a methodology for writing new code. But if you're using a different language to unit test your code, you are loosing out on that exploratory capability. Sure you're using the API, but you're not using it in any way that resembles how your clients would use it.

It's a different story when writing integration / acceptance tests. These tests are at a higher level and are more about general application behavior than specific APIs. I think it's very appropriate in these cases to use a Groovy or a Scala or a DSL or a framework (e.g. selenium).