Anti-monarchist: iemand die op zoek is naar een probleem voor een oplossing

an·ti-mo·nar·chist (de; m,v; meervoud: anti-monarchisten) 
1    iemand die op zoek is naar het probleem dat hoort bij de oplossing bestaande uit de afschaffing van de monarchie.

Ik hoorde vandaag op Radio 1 dat er een beweging is die zich “Het is 2013” noemt. Wat deze beweging met deze naam beoogt werd me niet direct helder. Mijn instinctieve reactie was “daarvan is de overgrote meerderheid van de bevolking zich bewust, dat is het gevolg van een onstuitbaar proces en voorzover ik kan overzien maakt niemand zich er grote zorgen over”, en ik moest de neiging onderdrukken om een beweging op te richten met de naam “Stop the continental drift”.

Maar nee. Wat deze beweging beoogt is niet het wijzigen van de kalender, of het terugdraaien van de klok zodat de veronderstelde Maya-voorspelling van 21-12-2012 alsnog kan worden uitgerold, maar de afschaffing van de monarchie in Nederland. Dit alles volgens de lijn dat “als IK vind dat dat in 2013 niet meer kan, dan moet IEDEREEN dat maar vinden”.
Dat was natuurlijk te verwachten… bij zo ongeveer elke Koninginnedag laat er wel weer zo’n beweging wat van zich horen. Het ligt voor de hand dat dat in 2013 wel weer zou gebeuren; we hebben per slot van rekening in 2013 een troonswisseling, en dan kan je als activistische beweging niet achterblijven. In 1980 zal men ongetwijfeld ook hebben gezegd “dit is 1980”. Anno 2013 heeft de kreet “dit is zooo 1980” ook niet heel veel betekenis meer. Dat (het simpel melden van een jaartal om aan te geven dat iets wel of niet een goed idee is) is een kwantitatief argument. Een kwantitatief argument is een voorbeeld van een zwaktebod. Je kunt kwantificeerbare data gebruiken om kwalitatieve argumenten te ondersteunen, maar kwantitatieve argumenten bestaan feitelijk niet: een argument is per definitie kwalitatief.

Dus op zich zou je denken dat zo’n beweging met gekwalificeerde in plaats van gekwantificeerde argumenten komt waarom het afschaffen van de monarchie een goed idee zou zijn.
Er kwamen er twee:

  • De anti-monarchistische beweging wil dat het Nederlandse volk zelf in staat is haar leider te kiezen.
    Voor dat probleem zou ik een andere oplossing willen suggereren: sluit je aan bij D66 en ijver voor een gekozen minister-president.
  • De anti-monarchistische beweging wil dat het Koninklijk Huis belasting gaat betalen.
    Hoewel ik denk dat iedereen die een beetje kan rekenen weet dat dat geen deuk gaat slaan in ons begrotingstekort, snap ik waarom ze dat willen.
    Maar maar maarderdemaarmaar: als je eerst het Koningshuis afschaft, hoe wil je dan dat dat dat instituut dat je net hebt afgeschaft belasting gaat betalen?

Al met al heb ik er geen mening over. Onze constitutionele monarchie is een raar ding… maar wel een raar ding dat al decennia lang goed werkt, en waar een aantal republieken vaak niet zonder jaloezie naar kijken.

Als gewone Nederlander zou ik geneigd zijn te denken “if it works, don’t fix it”. Er zijn belangrijker problemen die om een oplossing roepen.

Burn, baby.

Some of you may have noticed that we recently acquired a wood stove.

While it tries to look old, it isn’t, really – it’s a brand new TR-8, manufactured in Dublin. And as it SONY DSCappears, wood-burning stoves are serious technology – this one, apparently, knows a few tricks about efficiently generating heat that stoves had no idea about when my grandmother was my age.

Our stove specialist, Westerhaard, (who was tipped off by one of the farmers in our surroundings who knew we had a couple opportunities for restructuring our quarters) came over to install it last Thursday. The good news was that it was considerably less work than he thought. The bad news was that we had to wait 24 hours to use it. Sad smile

On Friday evening, these 24 hours had passed. The stove lit up like no tomorrow, and burnt beautifully.

Saturday morning was somewhat of a deception. Management summary: when there is no wind whatsoever, and it is foggy, wood stoves don’t burn as well. I had trouble getting it to go, but eventually we did get a decent fire going (with all air supplies opened fully). I do think it didn’t burn as efficiently as it could have, though – I saw some crud buildup at the back of the glass. We didn’t have any wind to speak of yesterday… according to our weather station, yesterday’s wind run in our back yard was 32 km. In 24 hours.

This morning, it is picking up a bit… not much at 1 Bft, but at least is is something, and the stove now runs fine with the primary air controls partially closed.

We still need to get the hang of this, through.

Selecting a stove 101

Management summary:

  1. Pick a supplier that you think you can trust.
  2. Trust him.

We had thought about getting an old burner from Marktplaats, but because these are usually not very efficient when compared to a modern stove, and can be detrimental to your health, we decided against this. Coen Westerveld advised us to not get too big a stove, as wood stoves function best when fired near maximum capacity. He advised us to get the TR-8, and after reading a few favourable reviews on this, we went for it.


A handful of weeks ago, we didn’t even know we wanted a wood stove… it was only after we discovered that the chimney in our newly acquired half of our residence was actually pretty good that we started to seriously consider the possibility. So, it’s not like I’ve been felling, splitting and drying a lot of hardwood for the last year. We only have two suitable trees anyway (walnut), and one of them will have to go, partly since its roots are upsetting the shed. Sad smile

As a result, we are now relying on a supply of well-dried hardwood from a local firewood sales operation, and a small stack of hardwood sawdust briquettes supplied by a firewood firm in Maurik. This is essentially just hardwood sawdust, pressed in the shape of small round logs. They burn very efficiently (very low moisture content) and produce a fire that looks very nice, but you don’t get the sound effects of a wood fire… so currently, we just mix them up.

The result

If you’d expect to be capable of warming up the room quickly with a wood-burning stove, think again. It took us about two hours to warm the room from 13° to 18° on Friday evening. So no, we cannot ditch our central heating Winking smile

But it is fully capable of warming up the room to a comfy level given the time, and keeping the room at, say, 21 degrees is a piece of cake. Even with the doors open, which also helps keeping the other quarters at a decent level in at least a third of the house (which is half of the part that we use on a daily basis), which means our central heating will have to work a little less.

Yesterday, we still took it fairly easy, and went to a little less wood than fits in the basket that you see on the left. This kept the entire room at a comfy 21 degrees. Today, with a bit more wind, I’m going to step it up a bit.

Of course, you have to “maintain” the fire. Which is what I am doing right now, while typing this post.

System.Timers.Timer doesn’t seem to fire

If you are using System.Timers.Timer to fire off a work loop at a set interval, you may sometimes come across the situation that it seems as if your timer’s Elapsed event doesn’t fire – you know that the timer’s interval has expired, but nothing happens.

I’ve been tearing my hair out on a few occasions about this. Usually, if I would do a rebuild, the problem would automagically disappear, but today it didn’t.

Apparently, I was not the only one suffering from this problem, because Stack Overflow had various threads inquiring about this. Most of the answers pointed to “use system.threading.timer instead”. One of them actually hinted at the problem: if the event handler would throw an exception, system.timers.timer would quietly swallow this exception and then choke.

You might say “yes, but I do exception handling in my handler… so the exception should be caught in the handler itself rather than be thrown up to the calling timer… right?”

Most of the time, right. But if calling your handler immediately results in an exception, such as when your handler declares an object from, say, a DLL and it cannot find the correct version of said DLL, you are toast. Even if the first statement in your method is a Try, this is never hit – the simple act of calling the method results in an exception. Which is thrown back up to the caller, which just so happens to be your misbehaving timer.

Unfortunately, using System.Threading.Timer is not really an option. First, it is a lot more cumbersome to use than System.Timers.Timer… and secondly (and more importantly), it does NOT work across threads.

So I went down for a smoke, which for me is a proven method to find my way around a problem.

When I came back up, this is what I did:

I wrote a wrapper method around my original handler. The wrapper method simply calls the original handler, from a try… catch block. And then I changed the handler for the timer’s Elapsed event to point to the wrapper rather than to the original worker method. A simple solution, really… it is fairly transparent, and it does not require a lot of refactoring. And because we stick to System.Timers.Timer, is is thread-safe. Most of the work went into typing in the comment lines – I believe in the concept of “don’t comment on HOW you do something, that should be clear when looking at the code, but do comment on WHY you chose to do it like this”, and with that in mind, this did require some commenting.

If the original handler throws an exception, this is handled by the wrapper rather than by your timer, and you can take proper care of it in the wrapper method, and your timer never notices it.

So, here’s what it looks like now. First, in my initialisation code, I instantiate the timer:

try {
    myTimer = new System.Timers.Timer();
    myTimer.Interval = PollInterval * 1000;
    myTimer.Elapsed += DoStuffWrapper;
    myTimer.Enabled = true;
    myTimer.AutoReset = true;
    AddLogEntry("Starting work loop in " + PollInterval + " seconds.", EventLevel.Debug, EventID.GeneralInfo);
} catch (Exception ex) {
    AddLogEntry("Timer not started: " + ex.Message, EventLevel.Critical, EventID.GeneralError);

The handler for the myTimer.Elapsed event is my wrapper, which looks like this:

public static void DoStuffWrapper()
    //The only raison d’être for this method is that it is a wrapper around DoStuff. If we would add the DoStuff method as the handler to our 
    //Timer.Elapsed event, and DoStuff would throw an error immediately on being invoked (referencing the wrong version of a DLL for instance),
    //you would NEVER see this, because the timer would eat up the exception and then choke silently. 
    try {
    } catch (Exception ex) {
        AddLogEntry("Work loop cannot be initiated - processing will stop (" + ex.Message + ")", EventLevel.Critical);
        myTimer.Enabled = false;

This wrapper then calls the method DoStuff, where the actual work is done. If DoStuff throws an exception up the food chain, DoStuffWrapper will handle this.