Subclass this

In object-oriented languages there’s a nifty feature called code inheritance. People tend to think that this is a really cool ™ thing, since it allows you to quickly slab some new features onto a class whenever the need arises. In fact, there still seems to be a lot of folks who think that the whole point of object-orientation is to subclass a lot.

I’ve previously worked with Microsoft MFC, which was designed that way (but remember, that was back 1992) – as was the class hierarchy that makes your Unreal Tournament tick. I’ve seen object hierarchies spreading over 15 levels, and more.

The only problem with code written that way is that it sucks. A lot.

Continue reading “Subclass this”


It’s so 1999 again…

I just went over to GitHub to comment on a ticket. I wanted to put an URL in the comment. No problem, usually all those comment boxes have a help function nearby, that explains you how the markup works.

GitHub has a link next to the comment box that says “Parsed with GitHub Flavored Markdown“. When you click it, you end up on a page that tells you how their flavour is different from the standard one and then…

Continue reading “It’s so 1999 again…”

Between Freedom and Coolness

I love my Mac. It’s slick. I’m almost in line to buy an iPhone (here in Italy it almost makes sense).

Still I admit that Apple, as a company, is probably one of the most evil there is.

This post from Coding Horror sums up some of it: People give up control over their devices, trading it in for a good user experience.

But even if people will flock on the side of coolness instead of freedom: Locking down your customers’ devices is an unacceptable practice and ought to be outlawed.

Update: It seems they can even remotely kill applications from your device. In the, it’s much preferable to have a solution like Nokia/Symbian that is based on technical criteria. It also asks for confirmations of sensitive operations. Apple goes the path of “give us full control, we take care” – after you go through their “review” you can do things like accessing the address book without the user ever noticing.

Continue reading “Between Freedom and Coolness”

Email etiquette

I kind of stumbled onto a discussion about HTML email formatting. Obviously Microsoft has chosen to use a crappier rendering engine in the new versions of Outlook. How touching.

Fact is, completely disabling the HTML rendering is one of the first things I do when setting up my email client. One thing is that it takes the air out of 99% of all the phishing/spam/trojan/whatever mails you receive.

Second, and more importantly, to this date I have never ever received an email that added any significant value to the content by using HTML. Really, there are only two uses I’ve ever seen: a) “Cool” Outlook templates used by hapless people and b) marketing mail made posher by HTML.

Now, I don’t mind anyone sending me pimped email, as long as they have the courtesy to include a readable plain-text version. It shouldn’t be too hard, really.

Worst offender so far: The “social networking” people from Facebook. Every single email from them looks like this to me:

This message contains a rich-text HTML portion. Consult your mail client’s documentation for infomation on how to view it.

And of course it contains only one single sentence and a hyperlink. Close second is actually eBay – their text-only version is a convoluted mess. But to be honest even the HTML versions of their things tend to be badly laid out and nearly unreadable.

Last candidate on today’s list of email offenders is Hotspot company The Cloud. After using one of their WiFi hotspots, they are hell-bent on sending me their newsletter. They did include a plain text version – what they didn’t do is to provide any information on why they’re sending me their stuff or how to unsubscribe.

Email communication is quite essential in today’s business world. And people hate dealing with crap in their inbox, simply because there’s so much of it.

So it’s even more stunning that there are companies out there who still don’t know the most basic of rules.

Strange variable scopes – Class variables (part 1)

There we go again. Ruby has some, err… “unique” features when to the scope of variables. It really starts out really harmless, though…

This is part one of two – this one is just to give you a bit of background for the next one. There’s not much surprising stuff there, so if you want to go for the stranger bits, just jump to the next installment.

More methods at runtime

As I expected, I missed some stuff in my last post about adding methods at runtime. One thing is that the idiom for adding class methods is “class < < self" rather than "class << Classname"

More importantly, if you define things like I did in my last post, you will not be able to use variables in the method definition. The things after "class << self" are executed in a different scope that doesn't inherit the variables from the surrounding code.

Fortunately, Ola Bini has a post that explains some of these things in more detail. Obviously, the idiom for creating class methods at runtime uses a combination of “module_eval” and “define_method”:

Continue reading “More methods at runtime”

Adding methods at runtime

One of the things that seems to draw people to Ruby is the ability to create and change all things at metprogrammatically at runtime. This in turn allows users to create things like domain-specific languages and the like.

I’m possibly overusing these features at the moment, because it’s a cool new thing ™.

So, let’s see how to add methods at runtime. Since this is Ruby, there are multiple ways to do this, making things more confusing.

(See also the follow-up article)

Ruby overloading

A new thing on my quest to learn the new language is weird inconsistency that bugged me lately: In Ruby you can overload virtually everything. That is, everything except the “equals” operator.

In spite of this, half of the Rubyists seem to believe that they overload the “equals” sign all the time.

Still, if you have this kind of expression:

variable_1 = variable_2

it will assign the value of variable_2 to variable_1, and there’s no way to change this behaviour.

However, if have something that looks like this

object.method = expression

the code will actually be evaluated equivalent to

object.send(“method=”, expression)

Continue reading “Ruby overloading”

Create a free website or blog at

Up ↑

%d bloggers like this: