For my Remote Pair Programming session with Alexandru Bolboaca, I wanted to work on our actual code, not toy programs. It was hard finding a technical solution to allow this (despite the many suggestions I received on Twitter; the biggest issue is sharing the entire development environment), but I finally settled on LogMeIn. LogMeIn basically lets you create an ad hoc VPN with them serving as a middle man. The great thing with it is that all the configuration is done on the client machines. There is nothing to change on firewalls (especially important for the other people that you are working with).

LogMeIn has a download that seems very simple to use… as long as you are under Windows. It also has a Mac OS X version and a Linux version, but they hardly come with any documentation. What’s worse, it is hard to find additional information on the support site.

So, for your eyes only, here are some instructions on how to get LogMeIn to run under Linux. (this applies only to the client machine; setting up the network can be done entirely on LogMeIn’s website)

My configuration: Ubuntu 10.04 Lucid Lynx 64 bits with LogMeIn Hamachi 2.0.0.11-1. (Hamachi is a protocal that creates a VPN that goes through their servers)

1. First, create a login on http://www.logmein.com/
2. Install their Linux client. Just double-clicking it after download should be enough.
3. Configure the client in the command line :
   1. hamachi login
   2. hamachi attach <your email on logmein>
   3. hamachi set-nick <a human-readable user name for you; any should do>
   4. hamachi do-join <id of the VPN previously created on LogMeIn>
      • The password is the one specified by the domain creator. This is not the password for your login.
4. Wait for domain creator to approve your machine on the virtual network (you might need to send an email to remind her of that)

Done! From that point, you can use VNC or anything else to connect to a remote computer. Use something like ifconfig on the remote computer and use the IP address under the ham0 entry (ham is for Hamachi, obviously). The IP address has an unusual value such as 5.18.76.84.

I’ve talked recently with the CTO of a small-but-successful company, trying to explain how we do software development. I realized that many things are difficult for them to copy from us, mostly because we have a different approach to implementing features (in particular, we try to limit GUI-intensive features, while they have a very rich Javascript interface).

One thing, however, that I believe they can adopt without changing their code is the source code management tool Git. However, they had already considered it (they are currently using Subversion) and figured that it does not solve problems they already have.

I’d agree that Git doesn’t fix obvious problems. However, Git is powerful enough (once the complexity is mastered) to make lots of little things easier. Here is what it does for us.

• It makes merges much less painful, even when no branched are involved, for example when two developers modify the same file. With Git, it is possible for someone to move a file to a different package, while another developer renames it simultaneously. And removes half of the content. Git (almost always) magically resolves the conflicts and maintains the history of the file, all without any special command. No need for “svn move” or “svn rename”. And no code freeze when someone renames a package, so we tend to do refactorings more often.
• When a regression is detected late, Git can help find the faulty commit. That can be done automatically if you can write a script that detect the bug (for example if there was no automated failing test in the faulty commit), but that’s not necessary. For example, it helped us find at what point “mvn eclipse:eclipse” stopped working (it was because we enforced maven 3 usage in the POMs). The command that does this is “git bisect.”
• The entire source repository is on the developer’s machine (this is configurable). This gives us free backup across all our machines, and instantaneous access to logs. In the same spirit, I frequently use git blame to find out who wrote what on a particular piece of code, so that I can ask them for clarifications.
• There are no access rights to manage (though users’ accounts on the server machine, if you choose to have one, as many do, are still necessary).
• Suppose you’re working on something, but must suspend that work temporarily to fix a bug. In SVN, either you cancel all your changes, or re-download the entire code base in a separate directory. Or count on the fact that changes won’t overlap (maybe). In Git, you can temporarily put your changes on the side, do your fix, then retrieve them back again. This is known as “git stash“.
• If by any chance it is necessary to roll a fix in production, it is possible to hand-pick changes with “git cherry-pick“. My colleagues often use this.
• Generally speaking, there is much less mangling of the code base (none of the infamous “svn cleanup“)

None of these features are absolutely necessary. But all together, they make life easier for us. It even let do serverless CI.

Sebastien Douche has said during a presentation at a recent Paris JUG evening that DVCS are the one thing that all developers should learn in 2010. I think he’s right.

Robert “Uncle Bob” Martin has just blogged on the differences in TDD styles using Clojure, as compared to more traditional languages such as Java. Though I am a Clojure-newbie, I mostly disagree with his conclusions.

His main point is that, because Clojure is a functional language, functions have no side-effects and therefore can be used directly in the tests.

For example, the production code

(defn update-all [os]
  (update os))

would be tested with something like

(testing "update-all"
  (let [
    o1 (make-object ...)
    o2 (make-object ...)
    os [o1 o2]
    us (update-all os)
    ]
    (is (= (nth us 0) (update o1)))
    (is (= (nth us 1) (update o2)))
    )
  )

There is no reason to believe that the (update) function is side-effect-free

Changing internal values is only one way of creating side-effect. I admit that Clojure encourages coders to write code that does not change variables (if I got it right, it is definitely possible to do so, but with some additional work). However, that effect only stops at the boundaries of the language. At some point, it might access the file system or a database. Clearly, the state might change there.

Correct implementation of the (update-all) function depends on the correct implementation of (update)

Bob Martin says: ”this test simply checks that the appropriate three functions are getting called on each element of the list”.
Suppose that the (update) function does not do anything or maybe does something that does not return a value, such as printing out to the console. Then, calling it will have the same effect as not calling it at all. The test above will pass even if the (update-all) function does not provide any implementation at all. When, later, the bug is found, it will be harder to fix.

The test could be clearer (with a more powerful test framework)

One of my biggest concerns is that the test looks a lot like the code itself. Looks like duplication of information to the reader.
If there was a mock framework for Clojure, I would expect to see something like

(testing "update-all"
  (let [
    pre-conditions (
      (should-return (update 1) 1.5)
      (should-return (update 3) 3.0) )
    o1 (make-object 1)
    o2 (make-object 3)
    os [o1 o2]
    us (update-all os)
    ]
    (is (= (nth us 0) (1.5)
    (is (= (nth us 1) (3.0)
    )
  )

Bob Martin is right to conclude that “Clojure without TDD is just as much a nightmare as Java or Ruby without TDD.”

But he should also make it clearer that it is lacking a mock framework (he does point to Brian Marick’s work on this).

It should be noted that it is possible to get a similar implementation style in Java as in Clojure, though it is significant work. In fact, that’s often how we use it here at Algodeal. That means mostly relying on immutable objects and state-less methods. Immutable collections from Google Collections help a lot, too. Still, we like to use mocks in our tests (too much for some, probably).

In the end, Uncle Bob’s post is another aspect of the (almost) age-old debate described by Martin Fowler: classicists vs. mockists. If you haven’t already, read Fowler’s article, it’s worth it.