2003 Archive

Last week we started implementing a unit testing framework for Xaraya, which is highly integrated with the bitkeeper repository.

As of now it allows you to register testsuites and testcases which can be run once or repeatedly with

bk tests

I expected this to be an investment for the long run. The longer we used it, sometimes the tests would fail and we could fix things
more quickly. To my surprise the tests started failing basically right from the beginning, even when very premature code was available.
Both bugs in the testframework as in the codebase itself showed up immediately.

I found that the crux to this is that having a test framework puts your mind in a different state. While developing you’re trying to make things work, while writing tests you’re trying to make things break. This combination has worked already in the early stages, i can hardly wait to see how this is going to work when the number of tests starts to grow and we actually use that information in our process.

The scepsis has gone, unit testing rocks!

xmlhack: Expressing mixed content in RELAX NG versus WXS [link]

This is a nice reference. We are experimenting with expressing the blocklayout language in RNG, exactly because the XSD stuff is just plain unreadable. The RelaxMeter test for ambiguity is especially interesting for checking a solution specified in RNG.

The documents in which these protocols are described are called RFC-s (Request For Comments) and they are subject to a complicated process of drafting, reviewing becoming a proposal and utlitmately hoping to be a standard…. The funny thing is we have a simple process of writing the RFC, discussing it on our mailing lists, adapting the RFCs, the PMC approves them and we use the RFC as a reference to determine whether an implementation is complete…. So, I implemented a very simple xml tool to write up RFCs which forced people to focus on the content, not on the layout.

The IETF (Internet Engineering Task Force) uses a system for specifying internet protocols. The documents in which these protocols are described are called RFC-s (Request For Comments) and they are subject to a complicated process of drafting, reviewing becoming a proposal and utlitmately hoping to be a standard.

Earlier tonight there was a discussion about RFC-s in the Xaraya group. We use a RFC system in the group as well. Specifying the way we want to code up cool modules in the system are documented in a rigorous XML format which doesn’t leave much room for freedom. No layout, no design, just content. The funny thing is we have a simple process of writing the RFC, discussing it on our mailing lists, adapting the RFCs, the PMC approves them and we use the RFC as a reference to determine whether an implementation is complete. Simple yet effective it would seem.

Nope.

In 5 months we have written just over 35 RFCs, that is, reserved the numbers. The content is mostly lacking and comments on the RFC must be begged for almost. Is the solution to make the process more complicated? Better tools? Allow RFCs to be “designed” so they are more attractive for people to read?

My own belief, was just the opposite, based on the assumption that we wanted to create code, not RFCs. So, I implemented a very simple xml tool to write up RFCs which forced people to focus on the content, not on the layout. It seems I need to rethink a bit.

eVote[link]

Well, this would be perfect for Xaraya and DDF operations. The irc voting we sometimes do with the notorious +1 and -1 lines works only so far. If someone doesn’t sum up the votes and puts it on a mailinglist, it’s quickly forgotten what the vote was about and the decision gets lost in the day-to-day work.

With eVote connecting to mailman, which we use in the Xaraya group, this would theoretically mean, as we have connected all mailing lists to NNTP that we can have votes and petitions on all mailing lists and newsgroups.

Especially for the DDF, which can possibly hold a greater number of projects this can highly simplify the decision making process. Definitely worth looking into.

Today the BK-view module I wrote for Xaraya went into a live site which can actually be used for something usefull.

The site http://bk.xaraya.com is the BitKeeper central for the Xaraya project. The BK-view module is used to browse through all of the clones used in the project, which is in the mean time a rather large number, and I’ve only included the top level clones.

The clones from the clones are not even in there.

Sometimes you just don’t want to make a change in the code like that. Some kind of procedure is needed to construct a list of checks, uncertainties etc. The general lessons from refactoring apply in these situations. I’m thinking out creating a refactor sheet which contains an easy to use checklist of form in which developers can entry information on the refactoring task a hand.

This list should at least include:

• goal: what are we trying to improve, a little bit more verbose than fix #bug 49712 is appreciated
• peer review: each refactoring task is performed by two people (at least) . Who’s coding and who’s reviewing is up to the duet
• tests: which tests should be done to check whether goal is reached. (this is actually the most important step)
• solution strategy: refactoring has some well known terms to work with, especially for object oriented systems. Try to classify the refactoring into one of these terms, so an objective reference is available

It would rock if we could use a refactoring browser to make it easier to perform the refactoring.

Note: refactoring is not adding functionality, you go from a working situation to a working situation, not from a broken situation to a (hopefully) working situation.

Pitfalls

refactoring backtrack explosion: suppose you want to fix a bug, the solution is apparent, you fix it, but you recognize the code can be improved by making it more general. You create a refactor sheet for it and start thinking about it. Almost immediately you see that there is a lower level change required to make the top level refactoring viable, so you create another refactoring sheet, pulling in an extra dependency for that refactoring. If this process repeats itself 2 times, you can be sure your code is not othogonal enough. Instead of making the refactorings smaller and smaller until the changes are properly localized and you can start implementing them, you pull in more and more dependencies. The process fall into a deadlock, suddenly you don’t know where to start and you’re not sure which dependencies to check anymore.

If you find yourself in this situation, let the orginal bugfix sit in the code (make a FIXME though!) and go walk the dog. Don’t think about the problem for a while. At a later time, return to the problem and try to solve it at a higher level, not changing API or interfaces, but generally making code more orthogonal without solving the original problem.

What you’re actually doing at that time is converting the system to a new state, so your refactoring stack will be different than the one described above. Naturally you use the knowledge you have about the old stack.

Practical application

How to organize this in real life? Use the bugtracker for the refactoring sheets? It’s a good start. Start simple at least, but make sure information is in a repository (but I say that with all information produced)

In general, the temptation to bring the templating language close to the programming domain is high. It creates a possibility to do all things which the programming language can do as well, often powerfull and most of the time dangerous.

In BL there is some PHP syntax hidden in the tags (for example the evaluation of conditions in if and while constructs).

Here’s a good example why the domain of the blocklayout templating system and the programming language in which it was implemented should be separated.

Because the domain of blocklayout and PHP are so tight together now, this is just one example of what can happen.
Bug 107 – <xar:set> allows PHP to be executed

In calling an API function for a module you had to make sure that the API of that module was loaded in your module. The core had already provisions that if the API was already loaded, it wouldn’t load it again. This can be automated. On calliing an API function (assuming that call is necessary of course) the core can check whether the API is loaded and if not, load the API.

This has the following advantages:

• guaranteed loading of API
• smaller code size
• simplification for module developers

This changeset makes it a lot easier for module developers. They can just use xarModAPIFunc in their modules, without calling xarModAPILoad each time. Basically this lil change does the same as the developer did. Check whether the module API was already loaded, if not load the module API.

All diffs for ChangeSet 1.498

And a client naturally…Once you have the blog server side set up, you obviously need something better than a webform to post the ramblings. Installation of mozblog(http://mozblog.mozdev.org) went with some hickups. I really like the fact of pressing Alt-P, jotting down something and going back to where I was. No separate application, no nothing.We should seriously considering making the mozblog suitable for Xaraya. This kind of blogging is something I can relate to

Always hated blogs, weblogs or whatever those things are called. So I decided to install one ;-) . No deeper thought behind it, just wanted to try MT out, it might even help Xaraya become a better weblog tool. I was however looking for a diary kinda thing and this might help to get things organzed and published at the same time. We’ll see.