Happy New Year

Its quite hard finding time to analyze and blog about chess during the holiday season! Other than the game below (which was played 3 weeks ago), I also participated in an internal rapid-play competition at my chess club and finished in the middle of the pack with a +3-3 score.

The chess publisher I use for my blog is no longer active. Until I determine its replacement, I won’t be able to provide replayable games.

Update: The site is back up now and the game can be replayed here.

1. e4 c5 2. d4 cxd4 3. c3 d5 4. exd5 Nf6  5. Nf3 Nxd5 6. cxd4 Nc6 7. Nc3 e6 8. Bc4 Bb4 9. Bd2 O-O 10. a3 Nxc3 11. bxc3  Bd6 12. O-O b6 13. Re1 Bb7 14. Ng5 h6 15. Nxf7!?

The first minor shock to the system. I had already calculated 15. Nxe6 fxe6 16. Rxe6 Bxh2+  17. Kxh2 Qh4+ 18. Kg1 Qxf2+ 19. Kh2 Qh4+ to be a draw by perpetual and was already trying to decide if I wanted to play for the perpetual or try for more.

15… Rxf7 16. Qg4!?

The second minor shock. Again, I had calculated 16. Bxe6 Bxh2+ 17. Kxh2 Qh4+ 18. Kg1 (18. Bh3 Rxf2 19. Kg1) 18… Qxf2+ 19. Kh1 Qh4+ to be a draw by perpetual. Perhaps one of my problems in this game was that I was perennially looking for drawing combinations while my opponent clearly had more on his mind. I’m of course not suggesting that was the only reason for my loss, but it just shows that it pays to want to fight at the board.

16… Kh8 17. Rxe6 Rf6?!

Again, trying to stymie the attack. I should have fought for the advantage instead with 17… Bc8 18. Bxh6 Bxe6 19. Bxe6 Qf6 20. Bxf7 Qxf7

18. Bg5!

I didn’t see this shot coming!

18… Be7 19. Bxf6 Bxf6 20. Rae1 Qf8 [Ne7] 21. Bd5?

This move throws away most of his advantage. 21. Qg6 Ne7 22. Rxe7 Bxe7 23. Bd3 Qg8 24. Rxe7 is curtains for me.

21… Na5 22. Bxb7

Again, 22. Qg6 Bxd5 23. Re8 and its time to resign.

22…Nxb7 23. Qg6

After failing to make this move the past two chances, he makes it here – but it doesn’t have the same impact.

23…Nd6 24. h3 Qd8 [Rd8] 25. Qh5 Qc7 26. Qd5 Rd8 27. Qf3 Qc8??

Now this blunder settles the game. 27… Kh7 or 27… Rd7 28. Rxf6 gxf6 29. Qxf6+ Kg8 30. Re6 and I am still fighting.

28. Rxf6! gxf6 29. Qxf6+ Kg8 30. Re7 1-0

Happy New Year to all!

The mocking story continues…

In our most recent project, we are using Mockito as the mocking framework of choice, instead of EasyMock which we’ve been using for quite a while. Differences between the two frameworks are enunciated on the Mockito site. The things that appeal most to me are:

• I don’t have to record void methods in the mock, unless I want the mock to throw an exception.
• I don’t have to invoke replay() for every mock!
• The really big thing for me is that I can invoke verify() selectively, on those method invocations that I care about and not any others.

This last point, which has been the focus of past rants, was illustrated very well by Dan North at his BDD session at Agile2008. Loosely paraphrasing, his example went thus:

Imagine you want to play a trick on someone. You wait for him to pull in at a gas station, fill up gas and walk inside to pay for the gas, then use a bulldozer to destroy his car. You are interested in observing his reactions to the destruction of his car. Everybody at the gas station – the other customers, the person behind the counter – are all actors (mocks). To determine if you predicted his reactions accurately, you don’t want to query all the actors in this little play; you don’t really care what the bulldozer driver has to say regarding this. You are mainly interested in the two people closest to the subject at the time – the person behind the counter and the person directly behind him in line. And you are largely uninterested in the rest of their observations – only in their specific observations to his reactions.

XPDay 2008

Its been quite a busy period the past few weeks – so busy, in fact, that XPDay has completely snuck up on us. Robbie, Fab and I are reprising our talk from Agile2008 – we are scheduled to be the first session on Friday morning. Since this talk is scheduled to be twice as long as our talk in Toronto, we are adding some juicy pieces to our talk. Fab will talk about his work on the bare-metal build and we will also show off three different tools that could be used to run robustness and performance builds – JMeter, Grinder and TestRR.

It should be loads of fun!!

Java I/O Concurrency

One of the requirements for the current project we are working on was to take a file name as input, execute an external script which would convert the file into another format and then return the contents of the output file. Once a file had been converted, subsequent invocations for the same file would just return the previously converted file.

If our application was to run on a single JVM, concurrency control could be performed in Java itself. A very efficient way of achieving this can be ripped off from Java Concurrency In Practice:

	Future<Boolean> future = fileCopiesInProgress.get(toFileLocation);
	if (future == null) {
	    Callable<Boolean> callable = new Callable<Boolean>() {
		public Boolean call() throws Exception {
		    return fileCopier.doFileCopy(fromFileLocation, toFileLocation);
		}
	    };
	    FutureTask<Boolean> futureTask = new FutureTask<Boolean>(callable);
	    future = fileCopiesInProgress.putIfAbsent(toFileLocation, futureTask);
	    if (future == null) {
		future = futureTask;
		futureTask.run();
	    }
	}
        return future.get();

Once the application scales to multiple nodes, file-level locking is required. A quick search introduces Java’s FileChannel and FileLock classes. The documentation implies that platform independent OS-level locking is achieved using fileChannel.lock(). However, a quick test on my Ubuntu host shows that I can vi from a terminal and edit a file that’s locked by the Java process. However, it works perfectly when other Java processes try to acquire the lock, which in our case was all we needed.

	File src = new File(fromFileLocation);
	File dst = new File(toFileLocation);

	InputStream in = null;
	FileOutputStream out = null;
	FileLock fileLock = null;
	try {
	    in = new FileInputStream(src);
	    out = new FileOutputStream(dst);

	    FileChannel fileChannel = out.getChannel();
	    fileLock = fileChannel.lock();

	    byte b;
	    while ((b = (byte)in.read()) != -1) {
		out.write(b);
	    }
	    return true;
	} finally {
	    if (in != null)
		in.close();
	    if (fileLock != null && fileLock.isValid())
		fileLock.release();
	    if (out != null)
		out.close();
	}

There are two big downsides to using FileLock, at least in this case:

• Copying the contents of the temporary file into the output file is a slow process.
• The Javadoc states that the behaviour of FileLock is indeterminate while writing onto a NAS – very helpful, that!

It turns out, after all the hoopla, that the easiest approach is to rely on the OS to rename a file. I am unaware of whether the OS-rename operation is guaranteed to be atomic, but Dustin tested it out on Linux by tailing a file on one console while renaming it on another. The rename was successful, while the first console still held a handle onto its pipe and could continue tailing the file – exactly the behaviour we needed. We then completely stripped out the concurrency control in Java as we could now live with a single layer of locking. Not going to a simple rename directly was probably a waste of time, but then how do you learn about all the cool tricks out there that will probably come in handy at some point in the future?