Peter Arrenbrecht's Blog

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 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.

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.)

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

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

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 th...

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...

I've recently read Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries by two lead architects on the .NET Framework. A mixed experience, I have to say. The book does offer good advice, but somehow, hardly anything seemed truly new. Maybe that is because I've already read Josh Bloch's Effective Java , but, I suspect, mostly because I have accumulated a fair bit of framework design experience myself (and, like them, learned from many mistakes). It was quite eerie at times, as it felt like they'd written down my own thoughts. So, it has still been a rewarding read, seeing as this eminent source confirmed a lot of my design creeds. A lot in the book is quite .NET specific, though I can hardly blame the book for that. And while it is tedious reading to someone looking for higher-level insights, I still wholeheartedly agree with the authors that consistency down to detailed naming conventions matters a lot in framework design. The most g...

Because I am now reading a book about Haskell, but also because when I implemented the gist of Palo in Erlang , I was bitten by - tada! - a typing error, I decided to port the code over to Haskell. While the functional core syntax of the two languages is quite similar, here's one detail that took me a while to figure out: A case construct in Haskell always introduces new name bindings, whereas Erlang uses existing bindings as equality tests. So, in Haskell you have to do something like if atkey == key then ... else ... , while in Erlang you can simply do case AtKey of Key -> ... Other -> ... (which seems more intuitive to me).

I have been asked to review the Palo code base. This is an open-source MOLAP database server. To get a feeling for what its core C code does, I reimplemented the gist of it in Erlang. Turns out it's really just a few lines when you have high-level functional constructs at your disposal. Out of curiosity, I then went and extended it so it really mimicks the Palo cube storage more closely, binary array searches and all (loading is still non-optimized, though). Finally, I even added a tweak that I suspect would boost Palo's performance a little. If anyone's interested, the code for loading and finalizing a cube is in cube_load.erl , the basic code for querying - possibly aggregated - cell values is in cube.erl . The latter also contains some tests showing how it's used.

I recently stumbled upon Diamond Wiki . This is a wiki enhanced by meta-data and navigation along meta-data dimensions. Interesting. Maybe a first step in the direction of something like an ad-hoc database. While deeply impressed with DabbleDB , I still think it should be possible to come up with something even more fluent, more ad-hoc .

What JCite really is about is what I am going to call DDT: documentation-driven testing. It is a discipline that complements and, during the conception of an API, really comes before TDD: test-driven development. DDT weeds out them design bugs! :)

There are quite a few articles extolling the virtues of test-driven development these days ( here's one ). And for good reason, too. Having done TDD for quite a while, I recently started combining it with documentation-driven design. This is what my open-source tool, JCite , is all about. With this approach, I sketch out the most important use cases, combine them into the index of a tutorial (links plus teasers summarizing the use-case), flesh out the tutorial topics (and thus use-cases) one by one, develop the use-case tests in parallel to each topic, cite the important parts of the tests as actual code samples into the topic, and only then start doing the implementation (this last step is accompanied by more tests, which are now more like unit-tests). In all, this is like literate programming, but of the use-case tests rather than the implementation code. TDD already helps to make you focus on the user during API design. DDD takes the effect further by making you tell consistent ...

I finally managed to install FreeBSD 6.1 in Microsoft Virtual PC 2004 with NATted networking behind a firewall. Here's how: Download the boot ISO image and mount it in the VM. Reset the VM. Run the FreeBSD setup until you have to choose the type of installation. Select "Standard". When asked to slice the disk, type A for "Auto", then Q for "Quit". When asked about the boot manager, select "Standard". Do not select the boot manager. When asked to partition the slice, again type A for "Auto", then Q for "Quit". Select the packages you want. When prompted for the media type, select "FTP Passive". When prompted for the download server, select the "Primary" server ( not the "Main Site"). When prompted for network configuration, skip IPv6, but do use DHCP. In the DHCP results dialog, correct the name server entry. It must be 192.168.131.254. (See this article for details.) Proceed with the inst...

RSpec Site : "RSpec provides a framework for writing what we call executable specifications of program behaviour. Since that’s rather wordy, we usually just call them specs. Some other people call these things examples." If I take a look at the examples on the RSpec site, I cannot help but wonder if just doing this (which they term "behaviour-driven development"), misses out on an important aspect of API documentation and the thought processes that should go into an API design. The missing element is explanation . In my experience, unless I force myself to explain my decisions to an audience (even a hypothetical one), I come up with too complex designs, inconsistent naming, and just generally too much hassle for the users of the API. Sometimes, complexity is warranted. But then, I believe it is important to justify it to your users. Show them why it's there. The RSpec approach is, as I see it, simply a very concise way to write your tests twice: once in natural...

Jay Fields Thoughts: Use erb to insert dynamic text : "Tonight, I was writing up some new material and wanted to mix some examples with the text. I could have just pasted the code into the material; however, I wanted the material to update automatically if I updated the code. When working with Martin on his next book I got to experience the value in this practice first hand and it wasn't something I wanted to work without at this point." Whoohoo! Famous company for that source-citing approach ! :)

A. Sundararajan's Weblog : "As I mentioned earlier, Mustang (Java SE 6) comes with jhat - Java Heap Analysis Tool. We have added more features to jhat as of build 53 (released on Sep, 22, 2005). jhat now comes with mechanism to query the heap. jhat supports OQL - Object Query Language -- a SQL-like language to query your Java heap!" This is amazing news! It has, in fact, in one stroke returned my faith in the continuing evolution of Java as a valuable tool. You see, I have been thinking along similar lines for quite a long while. My thoughts, however, where not centered around the heap dump, but on integrating a heap query language into the Eclipse debugger. But given this OQL support JHat, I think it should be fairly straightforward to integrate this into the debugger. Imagine being able to define OQL queries as watch expressions, complete with difference highlighting from snapshot to snapshot. It would make debugging the state change of complex structures a breeze. I al...

Source Citing: Making Examples Work - arrenbrecht.ch : "People learn best from good examples. To be good, examples need to be correct. In every release. So a test for them is likely the single most important automated test you can write."

As I posted earlier, I had this idea about bookmarks that are searchable using Google . Well, they've implemented it if you have personalised search enabled. There is a new link at the bottom to a bookmarklet for easily adding a bookmark within your Google account. Like del.icio.us, but searchable with Google. Cool! (I did, by the way, tell Google about this idea. I'd love to know if that had an influence...) What's not so cool is that they still want me to enter some information (labels etc.) when adding a bookmark. That really sucks. I don't want to categorize. That's the whole point when I am able to search through my bookmarks' contents. Maybe I'll manage to create a bookmarklet that adds a bookmark straight away.

My new personal and professional home pages are up!