Threaded chat article and demo

While nothing major, managing threaded conversations in chat has bothered me for quite a while. Yesterday I had an idea on how to improve matters:

• Works using existing chat infrastructure. Needs only augmented clients.
• Plays well even if other party uses a non-thread aware chat tool.
• Separates threads automatically based on interaction patterns.

I've written an article and have created an online demo about it. Discussion welcome.

GMail diffs to find quoted text

GMail is really so cool. I think rather than just relying on quotation marks (> and such), it strips them and then diffs the message to its predecessors to find common chunks. I saw that in action when I sent an updated patch to a mailing list. In both versions, there were no quotation marks, but the second message, viewed in GMail, showed just what had changed versus the first message, the rest being hidden behind "--Show quoted text--" markers.

Using Throwable to trace the origin of an object

When using components decoupled by queues or other intermediate data stores, it can be a pain to trace the origin of faulty data in the queue. In languages with decent support for stack traces, however, it's easy. In Java, you just add a temporary field

public final Throwable createdBy = new Throwable();

to the class in question. Or, if you need to know who enqueued it where, you vary the creation of the Throwable accordingly. (See example 8-5 of logging in the Red Hat Web Application Framework, too.)

Literate Testing

What I termed documentation-driven testing has before been penned literate testing, where the Python docTest people have summarized the essence very nicely indeed.

Excellent Tests In Docs - Zope

Zope Source Code Repository - markup - Zope: zc.queue/trunk/src/zc/queue/queue.txt

Local Builder Pattern Broken in Java?

Time and again, when I want to break up a longish Java method into smaller parts, I find myself wishing back the by-reference parameters and access to surrounding local procedure variables of Pascal. Now, I know that the discipline of trying to always pass all required arguments explicitly, and to not rely on changes to by-ref params is often helpful. Nevertheless, sometimes it gets in the way. One fairly clutter free approach to get Pascal's features back goes like this:

public interface LocalBuilder {
T build();
}

and then:

public MyClass computeIt() {
 new LocalBuilder() {
   final int input1 = ...;
   final int input2 = ...;
   int state1 = ...;
   int state2 = ...;

   public MyClass build() {
     stepOne();
     stepTwo();
     return result();
   }

   private void stepOne() { ... }
   private void stepTwo() { ... }
   private MyClass result() { ... }

 }.build();
}

While this basically works, it has a few problems:

• Exceptions thrown by build() must be declared already on the interface. This is a serious problem.
• For native types such as int, one must provide dedicated interfaces such as LocalIntBuilder with an int build() method, or else go with boxing.

If anyone has a better pattern, I'd be glad to hear about it!

Documentation Driven Development - Other Takes On The Theme

I googled for "Documentation Driven Development" and came up with a number of links (why the heck did I not do this sooner?).

• SpliceIt seem to be doing it, but don't cite tests. There is no mention of integration with use-case-level tests.
• Vincent Massol had the experience when writing books about frameworks - always improved the underlying code. The message is: you have to be serious about writing good docs. Otherwise the effect is lost.
• Korby Parnell just thinks about it, but some comments point to people with experience doing it.
• IEEE has an article about DDD for real time systems. Also seems to take it as far as code-generation. I haven't read it.
• Miguel dos Santos has little to add, but there is a nice comment by someone called "Tania" about applying the idea of documenting the "why" more generally.

In the groups, I got:

• Ilja Preuss's take is a bit too limited for me. In my experience, good DDD docs focus on tasks, not classes and methods.
• Michele Simionato is spot on. Already did it in 2003, in Python. Which, incidentally, executes the DDD/Citing idea very nicely indeed.
  
• Phil Thomson, as a half-joke, prompts Dave Thomas to drive DDD of RubyGems with his book. Funnily, it seems that Andy Hunt and Dave Thomas have used a JCite-like approach for every one of their books. They have some home-grown macros to make compiling and checking the example code automatic.

The search for "Documentation Driven Testing" is less rewarding.