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.

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.

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.

Portrait of a young woman dressed as Boadecia or Mother England by Powerhouse Museum

AppArmor is a tool that can explicitly allow or deny actions by some applications. Those actions are recorded in a profile. Many profiles are already available, for such tools as Firefox, but sometimes it is necessary to create your own. This was the case for us: we wanted to make sure using Mono was not too much of a risky endeavor (we run investment strategies written by our users in .NET).

Creating a profile for AppArmor can be done is a couple of ways. One is to run the application you want to lock down in record (”complain”) mode, check the logs produced by AppArmor and select the corresponding rules you want to enforce. The tool that checks the logs and produces the profile containing the rules is logprof, generally run with the aa-logprof command.

Last morning, when I merrily tried to run logprof, it prompted me at the end of the process to create a user.

Create New User?
(Y)es / [(N)o]

I didn’t know what “Creating a user” meant here. And, at this point, there is nothing useful to do. Whether you reply Yes or No, you are always prompted for a username and password, then asked whether you want to save the configuration, which inevitably ends with a Login failure, and you are back to the Create a User question (Ctrl-C to get out). Here is the whole trace:

Updating AppArmor profiles in /etc/apparmor.d.
Create New User?

(Y)es / [(N)o]
Username: noideawhatmyusernameis
Password: noideawhatthepasswordis


Save Configuration?

[(Y)es] / (N)o

Login failure
Please check username and password and try again.
RPC::XML::Client::send_request: HTTP server error: Not Found

Create New User?

It took me a while to understand what was going on, so I’m writing this post in the hope that it will help someone (possibly me, in the not-so-distant future).

The user here refers in fact to a user on the central, public repository for AppArmor profiles. You do not normally need a login for downloading profiles, but logins are required to upload them. Now, I obviously do not want to upload my profiles, so what’s the deal?
In all likelihood, I must have enabled the upload of profiles at some point, possibly when I was trying to figure out what AppArmor was doing. There is a way to undo that, but very little documentation and few discussions about it on the internet.
I finally found it on Novell’s site.

In the end, here is what you need to do:

1. move to /etc/apparmor (and not /etc/apparmor.d, which is the directory where the profiles are saved)
2. edit repository.conf
3. in the [repository] section, replace upload = yes with upload = no

All done!

Footnote: the status of AppArmor is not clear to me. Wikipedia indicated that Novell has fired the original team that developed it and indeed Novell’s site only points to AppArmor v2.1 and earlier. A Google search returns many links to Ubuntu and indeed Karmic Koala comes with v2.3.1 (the latest, AFAIK), but Ubuntu pages do not offer very advanced documentation. Novell does have the best documentation but is strangely not well referenced on Google and the documentation only goes until v2.1, which is not impressive. The official development site is hosted by Novell, but it only mentions v2.3beta and has not seen any release seen mid-2008. Finally, a similar tool, Tomoyo, has been merged into the Linux kernel v2.6.30 since mid-2009. So I think that, once we will have move all our servers to Karmic, we’ll dump AppArmor.

And what to do when you have 21 geeks with time on their hands? Why, predictions, of course! (I want to do it again this year, check out the Google Moderator page I’ve started)

We decided to come up with a number of predictions (and bet on them), some serious, some not, that would be verified at CITCON Europe 2009, the price being beer points. And, the losers will be named and shamed, while the winners will be glorified (at least until new predictions are made, and for no more than a year, whichever is earliest).

Here are the predictions, and the actual outcome (a couple of them were settled by votes at the closing session):

So, out of 14 predictions, we got 11 right, 1 wrong, and 2 undecided.
Now, you may think that the answers were straightforward. But you need to realize that, for each one of them, someone was willing to bet a beer against the consensus. In other words, at the time when the predictions were made, it was not clear cut.

In the interest of the bets, I shall now reveal the names.
Winners (Glory to Them All!)

• Andrew Parker (8 rights, 1 wrong)
• Eric Lefevre (that’s me) (10 rights, 2 wrongs)
• Guillaume Tardif (6 rights, no wrongs)
• Jean-Michel Bea (8 rights, 2 wrongs)
• Pekka Pietikäinen (7 rights, 2 wrongs)

Losers (Boo to Them All!)

• Julian Simpson (3 rights, 4 wrongs)
• Jeffrey Fredrick (3 rights, 6 wrongs)
• Paul Julius (5 rights, 2 wrongs) — PJ is still a loser, ‘cos he has been right on bets with small payoffs
• Tom Sulston (4 rights, 4 wrongs)

I have started a new series of predictions for CITCON Europe 2010. There are two steps:

1. suggest predictions & vote for the best ones
2. when predictions have been selected, vote

To actually win your beers, you’ll have to come to CITCON Europe 2010 (still unannounced).
Please check out the Google Moderator page to propose your own predictions.

If you want to the gritty details, I have a picture of the full spreadsheet.

As I write this, 3 days after the closing, I have still not fully recovered from CITCON Paris 2009. I have been very much involved in organizing this edition, so I would like to indulge in a bit of personal retrospective, mostly on the organization of the conference. This is basically self-reflexion; if that’s not your thing, you can leave. You won’t miss much.

Here goes.

What worked at the conference:

• we had more than 120 participants, which is in line with CITCON’s goals and the highest number ever in all 11 events. Also, it is very close to the number we had estimated ourselves.
• all the people in the waiting list have eventually been invited to join the main registration list; no one was left behind
• costs were well under control, especially thanks to the free use of ISEP’s classrooms
• we got significant money from sponsors; in fact, combined with the well-contained expenses, this event contributed hugely to settle debts from the past events
• quality of food was alright (especially for a free event)
• there were a number of well-known people, helping make this event special for other participants
• twittering was big; according to my feed on Google Reader, there were more than 300 tweets. Including quite a few from people regretting not to have come.

What could have worked better:

• there was not enough food. I think this is partly because the caterer is not a real professional. Even though we had given good estimates for the number of participants, I think that, as the person in charge of the student foyer, he was used mostly to students eating on a budget. If we use such a semi-professional in the future (likely, since we want to use more free venues such as universities), we would be wise to over-estimate the number of participants as far as food is concerned. Just in case.
• Even though we did arrange the chairs in the main room in circles, we left the other rooms as they were, theater-style. This didn’t help having involved discussions (as opposed to presentations).
• I’m wondering if we have not reached the maximum possible number of participants. One of the things that I really enjoyed last year was the late night drinks with the few that dared stay. This year, we were 30 or 40 at the end. Groups started to split up. Guillaume and I led a few to the Ti Jos bar and to the Caveau des Oubliettes. Although nice, it was a bit sad, as there wasn’t really a “closing the closing session” moment. We didn’t even get to do new predictions! (and settle last year’s bets, BTW).
• Some rooms were lacking a video projector. I wonder if it would be good investment for the Open Information Foundation to buy one of those small and inexpensive projectors that have appeared recently on the market

On a more personal note, the conference passed a bit like a blur for me. Despite using OpenSpace Technology, I still ended up as the contact person for many participants, suppliers and sponsors, which was distracting. Also, helping my brother with the filming didn’t help. I even managed to miss out on the (now traditional) “Is Scrum Evil?” session, which had been a favorite of mine last year.

I still had a great time. Met Antony Marcano and Andy Palmer from Pair With Us (they are hoping to join us at the Paris Coding Dojo sometime — looking forward to it) as well as Gojko Adzic, whose copies of book was given away to some lucky participants, and Jason Sankey and Daniel Ostermeier from Zutubi… Reconnected with many former colleagues and friends, too. I also attended a few sessions ;-)

Oh, and last but not least, I’m one of the winners from last year’s bets! What do I win? Well, beer, in theory. But, even better, I get to call PJ, Jeffrey, Tom, Julian and Yegor LOSERS for a year. Priceless.

Check out

• all my pictures from the conference (pictures by others there)
• all the blog posts by participants
• my notes on the session on Mock Objects
• my notes on the session on Faster Tests
• all the notes on the sessions

See you next year, in one of the five cities in our short list (Zürich, Copenhagen, Belgrade, Dublin, and Prague).

“Going nowhere fast” by Nathan

The session on Faster Tests (led by David) was interesting, at least to the extend that it was quite clear that we are not doing too bad indeed (Douglas Squirrel from youDevise is another one that seems to be quite cerebral about tests and builds).

By looking that the various options discussed to get tests faster, I think it’s fair to say that the only way to really speed up tests is by compromising their integrity, at least to a level. In a way, to make tests faster, you’ve got to face reality and move away from their ideal abstraction (very reminiscent of Joel Spolsky’s Law of Leaky Abstractions). The only question is: how confident are you that those (slightly compromised) tests actually test something useful?

This leads to the conclusion that we only keep long integration tests because it is difficult for us to really understand what’s going on. If we did have an excellent understanding, we would have unit tests instead. And, interestingly, as we progress in our project, we find ways to convert integration tests into unit tests. In other words, we better understand what’s going on.

Also, check out my notes on the session on Mock Objects.

The Mock Turtle by Samantha Carlson

The session on mock objects, mostly lead by Steve Freeman, was a bit messy but interesting. My colleague David got to show some of our code on the screen, which was scary and exciting (he felt the urge to fix some of the tests he had shown immediately after). Also, I think I finally understood the relation between mock objects and interfaces that Steve insists on.

See, I always thought that Steve was in favour in adding interfaces directly on top of concrete classes. For example, if you have a FileManager, you would also have a IFileManager.

Steve made more clear that the idea was to use interfaces to represent a role, or (more exactly) just one of the roles that a class has. That makes sense. But, to be honest, I still prefer to have a single role per class. So, no interfaces really needed.

I wish I had more time to talk with Steve. Maybe his coming book will have answers for me.

We chatted about a favorite topic of mine: how to expand the horizons for Agile. My point is mostly that the Agile crowd is mostly talking about basic issues in software development, including during the Agile 2009 conference. I fear that this my give the wrong impression to beginners (”how, so we only need to do this and that, and we’re agile? Cool!”) and even to seasoned practitioners (”this Agile thing is not addressing my needs anymore”).
I would much prefer that we talk more about complex problems, whether they relate directly to Agile or not. This can include technical discussions or more touchy-feely ones. As long as we are addressing difficult problems, we will be making progress.

I also want to see more cross-domains talks. Obvious domains are the heavy industry (I won’t need to remind how influential Toyota has been to the IT industry) or performing arts. But that could also include things such as Behavioral Economics.

Or not. I don’t know for sure. However, I do know that we should be taking more risks. And stop presenting Introductions to Retrospectives for the upteenth time.

At the end of the talk, I mention 2 things for further reading. Here they are, plus a bonus book that I’ve just read:

• Implementation Patterns, by Kent Beck
• Rands In Repose, a blog on technological culture and managerial aspect of life in an IT firm; posts are not frequent, but very interesting (and long)
• bonus track: The Logic of Life, a book by Tim Harford; this is very much in the style of The Undercover Economist (his previous books, which I enjoyed a lot) and Freakonomics (ditto)

The podcast is available in French on the Vox Agile site. Here is a direct link to the MP3 file.

Amongst the activities that might interest fans of the Java:

• the Programming with the Stars contest where pairs of developers wll be demonstrate their programming skills in front of a panel of three wise men. The language is up to the developers.
• the Developer Jam stage, particularly dedicated to programmers
• another stage that might be of interest is Tools For Agility
• Java developers might also relate to the Agile developer, Architect and Developer personas

Here are a few sessions with Java either as the main topic, or as the language used for demonstration:

• Emergent Design & Evolutionary Architecture with none other than Neal Ford
• Scala: Object-Oriented and Functional Programming for the JVM by Dean Wampler
• How to make your testing more Groovy by Paul King and Craig Smith
• Agile AJAX: The Google Web Toolkit Experience, presented by Daniel Wellman and Paul Infield-Harm
• Creating Habitable Code: Lessons in Longevity from CruiseControl, with Jeffrey Fredrick and Paul Julius
• Java and Ruby Tools for Code Quality, by Steve Hayes

For some other sessions, Java is not central, but will be at least mentioned:

• SOA and Color Modeling by Daniel Vacanti and Stephen Palmer
• Coding Dojo: Enhancing Legacy Code, presented by Guillaume Tardif and myself
• Executable requirements: BDD with easyb and JDave (will also mention Groovy), with John Smart and Lasse Koskela
• Clean Code III: Functions, with Robert Martin
• BDD clinic – the doctor is in, by Pat Maddox and Elizabeth Keogh
• Malleable Code:  How Tests Improve Production Code, by Eric Anderson
• Back to Basics – Writing Expressive Tests Without All The Wizardry, with Rod Coffin
• Test Driven Development in Java: Live and Uncensored, with Ben Rady
• Acceptance Testing Java Applications with Cucumber, RSpec, and JRuby, with Dean Wampler and Aslak Hellesøy
• Java Power Tools – getting it all together, with John Smart
• Applying Agile Development Practices to Atypical Technologies, from Scott Dillman
• Mission Impossible: TDD and JavaScript, by James Suchy
• Leveraging Maven 2 for Agility, with Tim Andersen and Luke Amdor
• Automated deployment with Maven and friends – going the whole nine yards, from John Smart
• Growing Object-Oriented Software, Guided by Tests, by Steve Freeman

Check out the entire program on conference site!

Update (06/08/2009): should have mentioned that the Cast Codeurs podcast pretty much have the same information in French.