Hm, it took me 3 weeks to solve a bug, that's definitely a record.
Truth is I'm not sure it was a bug or a feature. It is a bug because
doesn't worked, it did when I implemented the feature, but then "mn8"
changed and nobody tested those two methods. Now works, and it does it
nicely that's what counts. It is also covered with tests cases so next
time it gets screwed will know. Cool we have now 1114 tests for "mn8",
tests containing "mn8" script code running in a "mn8" script base test
framework. Cool.
We also have some new scrappers and a primitive "Jabber" client. For
now it is only able to send and receive normal messages. Will see
latter what more can we do with it.
RSS, RDF, OPML, scriptingNews2.xml concepts implemented. A cool thing all do is allowing you to have a new RSS, RDF ... feed containing only the new items since it was last invoked.
The only remaining things to do till we hand it over to our publisher are:
finishing the documents for the language syntax (the API for the
concepts is almost done), tackle a bit the basic error handling and do
some more examples.
April 19th, 2002
The .net guy started a discussion on this topics so here is my experience/ideas on this.
Unit Tests
I could not live without them 
. Since I read Fowler's book about refactoring I'm using unit tests everywhere where I have more than 10 classes both at the company as at home.
It's panic when the number of features without unit tests increases
(lack of time, or very urgent things to solve, I know unit tests first
...). It's relief when you are fully covered. What I like most about
using unit tests is that it gives you really speed. You can hack freely
and at the end if the unit tests pass you are OK, ready to make the
commits.
It is not universal panacea but it really eliminates the small and
medium bugs, and seriously prevents introducing new bugs while
changing/refactoring things.
However it does not eliminate complex bugs (the hard to catch and
fix type) but even so once those are fixed prevents them from
reappearing.
This is from experience, not theory. I use tests for over a year
now, and I wouldn't go back. I can not imagine a stable medium or large
project without unit tests, mainly because I don't believe it could
exists.
Pair programming
Pair programming does wonders for the code and most of the time for
the coders to. It's an excellent idea with excellent results and with
only one but. The human factor. It's very difficult to impose pair
programming in a team except for short periods of time, even if
everybody acknowledges the merits.
People everywhere have good and bad days, and pair programming
requires patience therefore doesn't work very well when there are too
many bad days involved and that is basically the reason I have said
that it doesn't work for long periods of time (At least I didn't
managed to make it work in my company 
Still we are using it constantly and happily in the next situations:
- One team member has a too long dark period and seems unable to get
out of it by himself. Making it work in a pair will get it back again
in a maximum of two days, days in which is producing good code
- There is some kind of knowledge transfer needed. Either you
are new to a part of the code or functionality or you just want to pass
one some best practices, pair programming does wonders.
- The needed functionality is a bit too complex and you are
uncertain about your ability to make it in time at a wanted quality.
Having a strong partner does wonders again. It's an excellent panacea
for "Analysis Paralysis"
From experience a pair produces more than two individual programmers
at a lot better code quality. Sure there are exceptions, but that has
to do again with the human factor.
Who knows maybe in time will become the defacto way of coding, just
like coops use to work in pairs but that is a bit too far away as I
see it.
April 8th, 2002
I've been looking from some time to ways to convert regular emails
to XML documents. It is not that difficult except when it comes to MIME
handling and attachments.
I was aware of the XMTP implementation but when I tested (a long time ago) I wasn't very happy with the way it worked. I should check it now.
Now, today I found a RFC on the same topic, looks complex, but it is worth a read.
April 8th, 2002
