Vindaloo Progress

Good news today. I finally got the search function working in the Vindaloo PDF reader. I'm quite excited that I managed to implement it like Firefox does. The user enters some text in the find textfield and after a short delay of 250 milliseconds the search starts. No need to press a find button. When the contents of the textfield change, the search is automatically restarted. The delay prevents the search to be restarted just after each letter of a word. 250 milliseconds is the upper bound for what a user usually experiences as "immediatly". The best is that all this works reasonably fast and the user interface keeps responsive (at least responsive enough). The whole thing still needs some work but I think I'm out of the woods today.

MocKit

I recently started development of a small MockObjects
Cocoa/GNUstep framework called "MocKit". MockObjects is a technique to test for interactions of objects instead of state. MocKit is inspired by the jMock framework that is written in Java. The interesting thing about jMock is that it provides a small embedded domain specific language for defining expectations about object interactions. With expectations, you basically say what messages you expect to be send to an object during a test scenario. The document "Mock Roles, not Objects" describes this approach in more detail. MocKit follows the ideas of jMock although it's not an exact reimplementation.

Here is a little example.

id mock=[MockObject mockForClass: [MyClass class]];
[[[[mock expect: @selector(someMethodWithArg:)]
   times: 2]
   with: ArgEquals([NSNumber numberWithInt: 42])]
   willAlwaysReturn: @"this is the answer"];
// run test scenario
[mock verify];

The approach of providing an embedded domain specific language for MockObjects is what makes MocKit different from OCUnit. OCUnit uses a recorder based approach. You first "record" the messages that are expected to be send to an object and run your test scenario. The messages send to the object during the test must match the previously recorded messages. The main advantage of MocKit is that it provides a more flexible approach. If focuses on expressing rules for object interactions. The resulting code (see example above) does not only test but also documents a system. By looking at the test code, one can easily see how objects in a system behave.

MocKit is currently in a usable state although it needs some polishing before I will release an official version. If you are interested, you can browse the darcs repository online. If you want to try MocKit, download the repository archive. It contains a makefile for the GNUstep environment as well as an XCode project (XCode 2 is required). For an introduction read MocKit/Documentation/MocKit.text. If you have questions or problems you can send me a mail (stefankst - at - gmail.com).

darcs

I switched to darcs for a few of my personal projects now. Darcs is a decentralized revision control system that does not require a central repository like Subversion and CVS do. Instead, you can have an arbitrary number of copies of a repository and darcs provides commands to keep these copies in synch.

With darcs, the number of developers who can work on a project is not limited. You can just put your repository on some http-server and everyone who wants can get a local copy of this repository by using darcs' get command. Changes made to the local copies are also recorded locally. Using darcs synchronization commands, changes can be populated from any repository to any other. A very useful feature is darcs' support for distributing changes via email. A developer can create a patch bundle for her local repository. This bundle is emailed to other developers who can then apply it to their repositories.

Darcs has no such things as branches. Just think of each copy of a repository as a branch. Changes can be moved back and forth between these copies. The drawback is that darcs doesn't support branch management as subversion or CVS do. But i'm not sure now if this could be a problem for me. The future will show.

I'm using darcs for a few weeks now and I'm quite satisfied. I have always found it annoying to setup a central repository for a one-man project. In addition, the absence of a central repository also eliminates the single-point of failure which is inherent to Subversion, CVS and friends. With darcs, the repository lives inside my working copy and no server failure can prevent me from using it. On the other hand, I can easily give other developers access to my project by providing a copy of my repository on some server. I neither have to setup nor to administrate a central repository.

Darcs is a fresh and lightweight system with a few straightforward concepts that are easy to understand. It runs on almost any platform so if you are not already using it, go and give it try.