Concording the digital world
Filed Under Amusing

Normally, I’m not really that bothered which chassis my computers come in, as long as they can take a huge number of large cooling fans, have USB ports on the front, and aren’t made of beige plastic. I expect most people use this approach when shopping for computer cases.
So what can the manufacturers of PC cases do to increase their sales? They have to make their boxes in stores stick out like a sore thumb. They have to give me some reason to believe that this is the case for me, and that I was a fool for even briefly considering any other product.
And so, while recently browsing the seemingly endless selection of cases, I noticed one box that said this on the side:
Armed with “Honor”: Centurion represents quality of Discipline, Honor, Integrity & Loyalty. Now you don’t have to be a Caesar to concord the digital world while feeling safe and proud.
Naturally, this was destined to be my PC case. This kind of shameless Engrish cannot go unrewarded. After all, I can now proudly concord the digital world without having to travel back in time and wear olive branches in my hair. And above all, I do so with a profound sense of safety and pride.
Post Linx
Permalink | Trackback |
|
Print This Page | Leave a Comment
PawSense
Filed Under Amusing
This has got to be the most significant piece of software developed this decade: PawSense detects when a cat is walking across the keyboard and then makes a sound to scare the feline typist off. The author certainly deserved it when he won the 2000 Ig Nobel Prize award for computer science. Someone, give this man a huge research grant!
Post Linx
Permalink | Trackback |
|
Print This Page | Leave a Comment
Castle Neuschwanstein
Recently, Aisha and Ross - two mates from Holland - dropped in for a long weekend to get away from their respective stressy student and software developer lives.
Intent on giving them the full German experience, I dragged them around Neuschwanstein Castle, this ludicrously large and ornate palace built in a picturesque alpine setting by Ludwig II of Bavaria.
Sadly for him, Ludwig never had a chance to live in the place, as he died before it was completed. He actually died under what I will diplomatically call “ununsual circumstances”: having been declared legally insane and deposed by the Bavarian government the previous day, Ludwig drowned while going for a swim with his accountant in a nearby lake.
Despite never being completed, the castle did in fact leave two important footprints in history: it inspired Disney’s Cinderella Castle, and it was used in the movie Spaceballs as Castle Druidia.
Post Linx
Permalink | Trackback |
|
Print This Page | Leave a Comment
Switchers revisited in C#
Filed Under Software development
For reasons that I will never understand, Microsoft’s C# does not support anonymous classes. So when applying the Switcher pattern in C#, we need to take a different approach to implementation.
A word of warning: this posting discusses the Switcher pattern that I introduced in an earlier posting. If you have not read this earlier posting, I would suggest doing so before proceeding, as it provides some fairly fundamental exposition.
Again, let’s start with some simple classes that require class-dependent processing. We’ll use fruit instead of animals this time, so nobody accidentally tries to mix Java code from previous posting with C# code from this one.
public abstract class Fruit { }
public class Banana : Fruit { }
public class Plum : Fruit { }
Here is the version of the client code that’s practically begging to malfunction once a new subclass of Fruit is introduced:
Fruit F = getRandomFruit();
if (F is Banana) {
Banana B = (Banana)F;
B.peel();
B.eat();
} else if (F is Plum) {
Plum P = (Plum)F;
P.eat();
spitOut(P.stone);
}
In C#, I implement the Switcher pattern using delegate methods (which are basically type-safe function pointers) that are passed as arguments to a Switcher method in an abstract Switcher class:
public abstract class FruitSwitcher {
public delegate void BananaMethod (Banana B);
public delegate void PlumMethod (Plum P);
public static void switchAll(
BananaMethod onBanana,
PlumMethod onPlum,
Fruit F)
{
if (F is Banana) {
onBanana((Banana)F);
} else if (F is Plum) {
onPlum((Plum)F);
}
}
}
Client code can then use the Switcher class thusly:
Fruit F = getRandomFruit();
FruitSwitcher.switchAll(
delegate(Banana B) {
B.peel();
B.eat();
},
delegate(Plum P) {
P.eat();
spitOut(P.stone);
},
F
);
This approach offers a number of features not included in the previous, Java-based Switcher class.
Firstly, the Switcher class offers class-switching logic as static methods rather than as constructors. This has the advantage that a single Switcher class can implement various collections:
public abstract class FruitSwitcher {
/* Delegate method definitions omitted */
public static void switchAll(
BananaMethod onBanana,
PlumMethod onPlum,
LemonMethod onLemon,
OrangeMethod onOrange,
Fruit F)
{ /* Implementation details omitted */ }
public static void switchCitrus(
LemonMethod onLemon,
OrangeMethod onOrange,
Fruit F)
{ /* Implementation details omitted */ }
}
Secondly, the delegate methods each include a parameter containing the original object, just re-cast to the respective class. This is for two reasons:
- It is highly likely that the class-specific client code will want to access the class-specific object members, so this would also be a good feature to add to any Java implementations.
- More importantly, this ensures that the delegate methods are specified in the correct order in the client code; if all delegate methods used a common
FruitMethoddelegate, it would only be a matter of time until someone put the arguments in the wrong order and thereby ended up trying to spit out a banana’s stone.
Other features are of course also possible, including code for dealing with null values (which could either throw an exception, or call a delegate onNull method). There is also no rule that states the Switcher method has to have the void return type; for example, we could implement FruitSwitcher.switchAll(...) so that the client code’s delegate method returns the color of the fruit.
Post Linx
Permalink | Trackback |
|
Print This Page | Leave a Comment
Consumer woes
Filed Under Amusing
Geof Greenleaf once put it very succinctly: “A man is measured by the size of things that anger him.”

If you expand this from a single person to an entire culture, the news provides fascinating insight into the consumer priorities of different countries. Americans tend to get annoyed at the high gas prices. The English are displeased by ever-rising grocery costs. Germans can rant for hours about how expensive beer has become in recent years.
A recent news item provided beautiful insight into the Belgian culture: of all the things in the world that are increasingly unaffordable, they are rebelling against the price for a plate of chips, even using phrases like “potato cartell”. :D
Post Linx
Permalink | Trackback |
|
Print This Page | 1 Comment
The old switcheroo
Filed Under Software development
One problem that has caused more bugs in previous software projects than I’d like to admit was the problem of incomplete if/then and switch blocks.
To illustrate this problem, let’s consider the following minimalistic Java classes:
public abstract class Animal {
public abstract void callTo(String message);
}
public class Cat extends Animal {
public void callTo(String message) {
...
}
}
public class Dog extends Animal {
public void callTo(String message) {
...
}
}
Now let’s assume that somewhere else in the application, we want to do something based on the class of an object. It’s a one-off action, so it cannot be implemented as a member function. Let’s say we want to attract the animal’s attention.
Animal a = getRandomAnimal();
if (a instanceof Dog) {
a.callTo("Here, boy!");
} else if (a instanceof Cat) {
a.callTo("I have food!");
}
The problem that arises is of course inevitable: what happens when we introduce a new subclass of Animal, such as Hamster? In the above code snippet, the new class would simply be ignored, which is clearly not acceptable. But how can we ensure that all possible subclasses of Animal are covered, no matter how many we decide to add later?
Superficially, the following code might look like it provides a solution:
Animal a = getRandomAnimal();
if (a instanceof Dog) {
a.callTo("Here, boy!");
} else if (a instanceof Cat) {
a.callTo("I have food!");
} else {
throw new Exception("Unknown animal type");
}
This is certainly a step forward in that the code recognises an unknown class and refuses to proceed. However, any code blocks that are not updated to include new subclasses will throw an exception during runtime, i.e. while the client is using the software. In any non-trivial code base, it is practically guaranteed that at least one such code block will be overlooked during testing, which means that the software has a hard-coded bug just waiting to happen.
What we need is a way to make sure that the code cannot be compiled until all code has been updated to include the new subclass. I call my solution the Switcher Pattern. The implementation of this pattern depends heavily on the language that the code is written in. In Java, I use anonymous classes.
public abstract class AnimalSwitcher {
protected Animal _animal;
public AnimalSwitcher (Animal A) {
_animal = A;
if (A instanceof Cat) {
this.onCat();
} else if (A instanceof Dog) {
this.onDog();
}
}
public abstract void onCat();
public abstract void onDog();
}
Client code then uses the following syntax:
Animal A = getRandomAnimal();
AnimalSwitcher sw = new AnimalSwitcher(A) {
public void onDog() {
_animal.callTo("Here, boy!");
}
public void onCat() {
_animal.callTo("I have food!");
}
};
Let us now assume we want to introduce the new subclass Hamster. Once the new class has been added to AnimalSwitcher (including the abstract method onHamster), all anonymous implementations will refuse to compile until the newly created abstract method has been implemented.
Animal A = getRandomAnimal();
AnimalSwitcher sw = new AnimalSwitcher(A) {
public void onDog() {
_animal.callTo("Here, boy!");
}
public void onCat() {
_animal.callTo("I have food!");
}
public void onHamster() {
_animal.callTo("I have a nice running wheel!");
}
};
Using this pattern, we only have to add the new subclass-based behaviour a single time, namely in the Switcher class. After that, we just have to diligently work our way through the error list generated by the compiler.
This pattern does not just apply when handling a complete set of sibling classes. It can also be used for subsets of sibling classes or even for entirely unrelated classes.
public abstract class Animal {}
public class Cat extends Animal {}
public class Dog extends Animal {}
public class Horse extends Animal {}
public class Cow extends Animal {}
public abstract class Furniture {}
public class Sofa extends Furniture {}
public abstract class PetSwitcher {
public PetSwitcher (Animal A) {
/* Implementation details omitted */
}
public abstract void onCat();
public abstract void onDog();
}
public abstract class BarnyardAnimalSwitcher {
public BarnyardAnimalSwitcher (Animal A) {
/* Implementation details omitted */
}
public abstract void onHorse();
public abstract void onCow();
}
public abstract class StuffInLivingRoomSwitcher {
public StuffInLivingRoomSwitcher (Object A) {
/* Implementation details omitted */
}
public abstract void onCat();
public abstract void onSofa();
}
Naturally, the benefits of Switcher classes depend on well-written code, as even the best design can be destroyed by poor implementation.
Post Linx
Permalink | Trackback |
|
Print This Page | Leave a Comment
Stupid questions
Filed Under Journal
There are a lot of really stupid questions out there. “Are you sitting here?” is one such question, as is “Where exactly did you lose your keys?” Normally I make a conscious effort to avoid asking dumb things, but recently I discovered that - in unfamiliar and unnerving situations - the brain shuts down the quality control department.
As I was driving home from my weekend shopping route, I noticed someone lying face down in a field, next to a toppled bicycle. I brought my Mondeo to a shuddering halt, jumped out of the car and ran over to the limp and motionless ex-cyclist. And that’s when it happened; during a bizarre, out-of-body type experience, I witnessed myself kneel down next to this person and heard myself ask: “Are you okay?”
If I’m ever in the position of the person on the ground, I pray I can find the energy to calmly reply “Yes, thank you. It’s nice down here.”
Thankfully, other motorists soon stopped and joined our happy little field party, including a doctor who made sure the cyclist was in no danger of dying with all of us watching. As it turns out, she had been cycling home from a friend’s house when she was suddenly overcome by “fatigue”, which is apparently a code word for “all the beer I’ve been drinking today”, if her breath was anything to go by.
Eventually, the ambulance arrived - heroically summoned by me a few minutes earlier - followed closely by the police, who pointed at the bleeding, near-unconscious woman lying on the ground and asked “Is this the woman who fell off the bike?” What a stupid question.
Post Linx
Permalink | Trackback |
|
Print This Page | 2 Comments
Blog Episode IV - A New Hope
Filed Under Journal
Every once in a while, I decide that it is time to change the layout of my website. New layout! New structure! And, hopefully: new content! For a brief few minutes, while sitting on the couch, this seems like an excellent idea. Then I remember that this actually entails a load of work, so nine times out of ten, I just put on a Simpsons DVD instead.
The main deterrent in the past has been the home-made content management system that powers my site. I went with something home-brewed since I enjoy planning and building software; also, thanks to my oh-so-slight control freak tendancies, I distrusted third-party components. However, as the projects I do at work have increased exponentially in size and complexity over the past years, I have been forced to use third-party components, as coding everything myself is simply no longer feasible. And, to my great surprise, if a component is carefully researched and selected, the things actually tend to… work. Shocking!
And so, when the urge recently surfaced to revamp my website, I jumped over my own shadow and installed WordPress. And hot diggity daffodil, I like it. Out of the box, it does almost everything I need; the few things that are missing such as photo albums are available as free plug-ins. The only real downside I can find is that my old content cannot be imported as-is, but it was time for a content reset anyhow.
I guess this means the snarky comments season has been opened, so here’s a pre-emptive one for copy/pasting: “It took you this long to discover ready-made blogging tools? Oh boy are you in for a pleasant surprise when you realise that there are also these things called ‘compilers’ that translate your source code into machine language, instead of doing it manually!” :P
Post Linx
Permalink | Trackback |
|
Print This Page | 1 Comment