Bonkers: either I or the Tax Service

Belastingdienst, the Dutch tax service, sent a form for me to fill out in which I needed to indicate projected future earnings. They do this almost each year—well, regularly—so that they can let you pay your taxes for 2020 in 2019 instead of the more reasonable 2021. And every year I postpone filling out this form (deadline August 1) as long as possible, so that I can always include my latest earnings in the estimate.

That’s the pre-amble. When I checked the form yesterday, I noticed the tax service wanted me to fill out my projected earnings for last year, 2008. I received this form at the end of May, two full months after I had reported them my income for 2008 (the cut-off date for which is April 1 in the Netherlands). More than a year after they had charged me income taxes over 2008 based on their own estimates. And two full days after they had corrected my income tax over 2008, presumably based on my April report.

In other words, have I just gone mad or is the tax service not quite right in the head? What am I missing here?

(I returned the form with the box checked that says they already know my income over 2008, which should be sufficient.)

Without context

I found the following in a mail from a client:

I want this done tonight or tomorrow. It can’t take long and I don’t understand how to do it.

I have nothing to add.

Moving Drupal

Today I had to move a Drupal installation from one domain ( to another ( Most of my time was spent in waiting for back-ups to finish, but there was one other problem that took a good half hour to solve: one page ( would give 403 errors, even though the page existed (as a URL alias). What had happened is that until today the www address had contained the old site, and the customer did not want me to delete its files, so I just dumped Drupal in the same directory. Turned out that there was a directory “portfolio” in there that conflicted with one of the new site’s so-called ‘URL aliases’.

So here are a few tips for moving a Drupal install across domains:

  • empty all caches before you back-up the database
  • after moving the site, change the base_url setting in the site settings file (sites/default/settings.php)
  • if you’re using MS Windows, Xenu Linksleuth is a good tool to check if any of the old URL’s are still lingering on the user side of the web site
  • if you’re overwriting an exisiting site, make sure the old paths in your new Drupal root do not conflict with the path aliases of the new site.

Re: the caches: my database contained 66 MB of material, of which 61 MB were caches.

The above are additional tips, and most definitely not the entire story of how to move a Drupal site. For that you use either common sense or the search function at

Search: weigh or eliminate?

A couple of years ago I reviewed a book by web usability experts 37 Signals called Defensive Design for the Web in which they gave side by side examples of how to do web shops right and how to do them wrong.

One of the examples had two sports stores go head to head. Both let you search for basketball shoes, but one (the bad one) showed you all hundred or so results at once, while the other (the good one) let you use filters to help you further narrow down your search. For instance you could say: only show me the sneakers with black laces, or the ones that cost less than 100 USD.

Both methods though, the one that showed all the results at once and the one that let you use filters, had an underlying assumption that all search criteria are equally important. Perhaps this is a side-effect from the success of Google. Search has become so relevant—and therefore successful—that we apply the same assumptions about search everywhere. This is what search should be like, we say.

VU researcher Frans Feldberg begs to differ though (Dutch). He claims that online stores would be better off using a mixture of regular and weighted filters. His 2006 research into automated decision support systems seems to indicate as much. Unfortunately all the weighted support systems cannot help you if your search yields no results—I couldn’t find out what his paper is called, or I would have linked to it.

Where my home wiki fails as an organizer

I have been using the simplests of wikis, Usemod, as a business organizer on my laptop. For every day in the near future I make a link. I link to days from other days, and from month pages, and to month pages from year pages.

The great advantage of the wiki as opposed to proprietary software is that it is fully free-form. I am not limited to the things the makers of commercial organizers want me to do, but instead I can enter new items just by clothing the link text in double square bracket, [[like so]]. This example would create a new page called “Like so.” It’s like building an office by burrowing into a mountain, creating new storage rooms and offices as you go.

But I stumbled upon a very real problem which is that it is much harder to make meaningful todo-lists in a simple wiki like this. A todo list really should always live at the current day; my best method so far is to copy unresolved todos to the current day. Yes, a simple solution would be to keep todo lists separate from the day pages, but 1) that is counter-intuitive, and 2) it still leaves little space for notes and sub-todos if your todo list is limited to the list format.

Todos are living things that sometimes branch into sub-projects (for instance if you underestimated the amount of work involved), sometimes need to be closed when they are not finished (for instance when their blocking more important todos from ever getting done), sometimes need to be re-opened again, sometimes need to have costs attached (when your customer wants an itemized list of expenses) and so on. There are relations between todos that are not always clear beforehand, but that still need to be formalized once they become clear.

Illustration: mock-up of what my current electronic diary looks like.

The current strategy of compounding todos makes all my day pages look busier every time. Also, I don’t prioritize todos much, so that the ‘mathom’ todos (the ones I keep pushing to the future and that aren’t very important to begin with) start to outnumber the important todos. And as a result, I have in the past year forgotten to do some of these important todos in time.

I know this because strictly as a diary the wiki is unparalleled. I can make little stories of what happened on each day, and in this way create a history of my company that allows for much more exposition than a simple paper diary could.

A solution for the diary-meets-agenda problem would be to use more powerful software. For instance, if I used MediaWiki, I could save each todo as its own page, and then attach categories to it that would indicate its priority, status, deadline, starting date, cost attached, et cetera. I could then find all Top Priority jobs on the Top Priority category page, or all jobs that still need to be billed on the appropriate category page, and so on.

Even better would be if database wikis like the slow moving OpenRecord would come along (check out the cool video of what it can do! — start at “3. Editing”), so that I could actually build a relational database the way you build a wiki: by hacking out the tables and relations as if the substance were living rock.

N.B. My back-up strategy for this type of diary includes sucking out the pages in HTML format using wget. The problem with that is that the wiki makes new pages where wget asks for an as yet unfollowed link? Also this takes ages if you forget to tell wget to not bother with all the history pages. My wget recipe for this job so far is: ” –restrict-file-names=windows -E -k -R action=”. “–restrict-file-names=windows” makes sure the filenames don’t have strange characters in them, so that I can view the file on multiple OSes, which is important for a back-up in case you need to restore to a different OS. “-E”: add “.html” to the file names; on lesser OSes this will make the files “clickable,” i.e. it will cause the OS to open the file in a web browser once its icon or name has been (double) clicked. “-k” convert internal links so that they work locally; so far that hasn’t been of much use, because it doesn’t add “.html” to these links, as required per -E. “-R action=”: do not store pages where the URL contains the string “action=”; this filters out things like history pages.)

N.B. 2 There is a much simpler way in which the wiki organizer breaks down, and that is that I have to enter the template for each day by hand. Again, using a more sophisticated wiki would solve this, and it’s not really a problem I am much bothered with: it takes fifteen minutes each week to do this by hand.

Log in to register

I feel like such a rube! The Discovery Channel is organizing a reality show “in which the contestants will build elaborate Rube Goldberg machines“, according to BoingBoing. Being of a sometimes curious nature, I decided to check out the site they linked to,, but in order to view the entire application form I had to log in. Still being of a curious nature, I decided to look at the registration page. This is what I saw:


In case you don’t get the joke: in order to register, you need to log in first. In order to log in, you need to register first. And so on ad infinitum.

Perhaps they want you to make Escheresque Rube Goldberg machines? Or perhaps they want to test your inventiveness? (The Rube Goldberg site has a similar test: a “skip intro” link that doesn’t work. Or does it…?)

Would you perhaps be trying to sell me something?

It’s a question I have to ask regularly of the direct marketing scum that call me on the phone: “Excuse me, are you calling me to sell me something?” For some reason, the phonetards try to postpone the anti-climax of the conversation as long as possible by trying to obscure the reason for their call. This is because it’s not really a conversation. The longer they can convince me that we are having a conversation, the better it is for them.

But direct marketing is push. It’s in your face, it is unwanted, it is begging for me to take out the baseball bat and come by to clean the pond. You don’t expect pull marketeers to make life more difficult for the prospective customer. Any ad that has to lure me over basically has to make life as smooth as possible for me.

And I guess when Inmatrix put up a webpage to promote their Zoomplayer Pro product, their intention really was to make life easier for me. After all, if I find out after the fact that I cannot use their product, they’re are going to have one cross, baseball bat-owning customer on their hands. Nevertheless, if I read all the things I have to do for the privilige of using their product, I feel the need to grab my credit card dissipate immediately.

The list of requirements is this long because of Microsoft’s perfidious DRM scheme.

But! If you are going to have a page titled: “Why should I buy this product?,” don’t make the list of cons three times as long. Put that list on another page, titled Requirements, and keep the Why page for the good news.


DRM gone mad, I tells you!

Related earlier posts:

Bugzilla’s long tail

If you wish to report a bug to a FOSS project (FOSS = Free and Open Source Software), you may run into a couple of snags.

One is that some of the developers are zitfaced asshats who consider the slightest mention of the possibility of maybe something being wrong with their software as a direct personal attack. Indeed, that is not a very useful attitude when you are, you know, inviting people to tell you what’s wrong with your software.

Typically not all developers share this attitude, but when your first interaction with geeks happens to be when posting your bug report, it is easy to assume all developers are socially challenged.

A simple, traditional and non-technological solution to this problem would be to let only the people with people skills do bug triage. How do you know which developers have people skills? They are the ones who do not scream at other people.

Another snag is that the software you use for reporting bugs can be difficult to use, and a third snag that said software is not very flexible.

A user has to jump through a lot of hoops before reporting a bug: grow a thick skin, read the 1000 page book on How To Use Bugzilla, and formulate your bug report in a way that is least likely to offend, and most likely to fit the mold for the Good Bug Report.

This takes time.

But what if the time bug reporters are willing to invest follows a power curve; a few reporters willing to go all the way, and lots and lots and lots of reporters in the long tail, just wishing to post their message without jumping through all these hoops? In how far do FOSS projects appreciate and accommodate this last group of bug reporters?

The slippery slope argument for coffee pads

A while ago, one of my brothers explained that he had not only made the switch from making pots of coffee using the traditional method of Putting the Kettle On to making cups of coffee using a Philips Senseo coffee maker, but that he actually liked the switch for practical reasons. As it turned out, he started making coffee on a need-to-drink basis, and saved a lot of undrunk coffee in the process.

Though I still think the whole Senseo concept is too much marketing and too little coffee, I have been experimenting with cups vs. pots, and I must say this new method seems to be a winner. Sure, coffee is a drug and Philips the enabler, but I find half the time I drink only one cup, and most of the rest of the time only two cups, as opposed to two or more from my pot making days.

I guess there is a practical reason for that; I need that first cup, and will overcome huge transactional costs just to get my fix. But making the second cup is often too much of a bother, and I will only drink it if it is already available (usually in the form of potted coffee). I guess I save on average ten cups of coffee a week using the new method. Still haven’t bought a Senseo, though.

Wikipedia’s authoritative articles

Wikipedia used to have a warning label that said something to the effect that you had to take everything there with a grain of salt; which is sage advice for any encyclopedia.

The idea being that a tertiary source like an encyclopedia can never be as authoritative as a primary or secondary source. (Let’s gloss over the fact that the strength of Wikipedia derives partly from being an excellent primary or secondary source for a lot of subjects.)

Now Wikipedia wants to instill some kind of authority by vetting articles, then locking them. According to an article in the Times: The software to allow such “stable” articles, which will be closed off from further revision, is now in the final stages.

Why write new software when it already exists? An encyclopedia built by volunteers, absorbing Wikipedia articles (or the other way around), which are then vetted by specialists in the field and deemed “finished” already exists. Or perhaps I should say “existed”; Nupedia was an abject failure. The vetting process would take ages, and by the time a rare article had graduated from Wikipedia’s elementary school to Nupedia’s university, the original Wikipedia article would have progressed so far that the Nupedia bit was nothing but a pale shadow of it.

But let’s try and be constructive. How about this?

Wikipedia already has locked pages, namely the older revisions. When you edit a wikipedia article, the former version gets saved somewhere. This helps other contributors to check up on your work, by comparing your version of an article with older versions. It also helps me to link to a version of a Wikipedia article about Nupedia that I just checked for all too clear inaccuracies and signs of vandalism.

How about giving some editors an approval stamp? When they use it on an article, the article gets marked authoritative. Then, when somebody else edits the article, the authoritative versions moves down in the history again, and the current version will no longer be marked authoritative.

If there is an authoritative version of the article, you can display a tab at the top, next to the “Article” tab, that links to the “Authoritative version”.

You could even make it so that if a reader looks up an article, the authoritative version is displayed first, although I think that is a very bad idea, because it sends a message to the good contributors that their work is of less value than that of an authority. To which the good contributors could rightfully disagree–an excellent reason to leave Wikipedia.

Authories will only lend their names to articles if they are sure the articles are correct. An authority who thinks it is OK to rubberstamp any old article, regardless of its actual quality, should not be considered an authority — such folks are probably better off working for the Digital Universe encyclopedia anyway. But every article always contains at least a few flaws, which may take anywhere from a few minutes to a few weeks to correct. Only very few articles would be vetted if the entire article should be OKed. So, the authorities should be able to mark only the parts of an article they trust, then move on.

This has the added advantage that the weak parts of an article stand out, so that the great masses can apply their energy to making the entire article good. Also, it helps make the authority’s voice clearer; he or she need not OK parts that he or she is not entirely certain about; that which the authority OKed, should really be OK. And of course, once you know that, you can better judge the quality of the authoritative voice, and vote it out when necessary.

Finally, an authoritative article should have a box explaining who deemed it authoritative, and what makes him or her so special. After all, an argument of authority is merely a heuristic; what makes somebody authoritative is first and foremost the things a person knows about a subject, and the fact that we know they know these things.

To be honest, Jimmy Wales probably has something like this in mind. Rarely have I seen a man who is misquoted so often and so badly by the traditional press as Wales; he knows what underlies the success of Wikipedia as well as I do, and it’s definitely not locking articles.