@megalonyx is now an empty place-holder, a reminder of the old days, when people were still allowed to develop apps for Twitter without being told what those apps could do and had to look like. And my own, old Twitter app doesn’t work anymore, of course.

One thing I noticed when I started using Twitter: I posted less short posts on my blog. Twitter was good for quick, short, throw-away rants. Now I’m going to re-integrate those short rants into this blog again, using qwitter as a category. I’m curious if I’m able to stick to the 140 character limit, although it is now pointless.

However, this post isn’t restricted to 140 chars, although it’s placed into the qwitter-category.

For the christmas season, let’s put cinnamon and apples into our muffins. You could leave them aside, then you get generic muffins. Of course, you could add other ingredients, like blueberries, for variation.

Preheat oven to 180°C. Sieve all the solid ingredients (except apple) into a large mixing bowl. Form a pit in the mix. Mix all liquid ingredients in another bowl. Pour the liquids into the pit of the solids. Mix both with a fork, but not too thorougly; muffins turn out best if there are some inhomogenities. Peel and dice the apples, mix them with the dough. Fill the mixture into a muffin form (the quantities above are for 12 muffins). Put into the oven for 25 minutes. You can test if the muffins are finished by putting a toothpick into one; if it comes out cleanly, without any dough sticking to it, take them out. Let them cool for a few minutes before removing them from the form.

Working on bad legacy code damages your brain. Encountering too many global variables without any use made me think about how an evil person (not me, of course) could make the life of his fellow programmers into hell.

I think I found an especially mean-spirited way.

Suppose you’ve inherited an inscrutable mess of code that you are expected to modify. While trying to make sense of it, you encounter lots of global variables; some of them are used (although you’re not sure why your predecessor chose to do it that way), but one of them is not.

Let’s say you encounter

more_magic = 42;

and more_magic is used nowhere in the code. You do a global search for that string, and it turns up nowhere else. So you simply comment it out …

… and the code stops working. How is that possible?

Well, here is my suggestion, and it’s mean-spirited; however, it’s only possible because of JavaScript’s idiosyncrasies.

First, we don’t want for more_magic to appear anywhere else in the code. Therefore, we encode it as npsf`nbhjd (each character code increased by one) and supply a decode function:

And that’s it. Of course, we wouldn’t name those functions decode and pure_evil, but instead we’d choose inconspicuous names. And we’d bury them deep in other code. Thread that magic value through many function calls, and blow up late in the game.

Please, please, please: don’t try this at work!

(And yes, this is inspired by the old Story About Magic; it sounds funny, until it happens to you.)

Somehow, I couldn’t find a decent JS op-pred cheat sheet for printing out and pinning to the wall. Therefore, I made one pro bono. Without further ado, here it is: JavaScript operator precedence cheat sheet [PDF, 18 KiB].

Drain pasta when it is al dente. Put into a bowl and pour aceto balsamico and olive oil over it (generously). Add the other ingredients, mix. That’s it.

Notes:

If you don’t want to consume the salad shortly after preparing it, keep it cool. Otherwise, the mold in the Gorgonzola cheese could spread over the whole salad, which wouldn’t be that bad (the mold is harmless and non-toxic), but doesn’t look appetizing.

I once hated JavaScript. I do so no longer. It is actually a quite decent language, a combination of Scheme and Self. But this heritage is buried, and not easily visible at first. But once you get the hang of it, working in JavaScript can be fun. You just have to throw some misconceptions overboard, and learn to work with the grain of the language (I wholeheartedly recommend Douglas Crockford’s book JavaScript: The good parts.
It is quite thin, which says a lot).

I’d like to share a nice JavaScript idiom that at first looks ugly, but is in fact quite elegant.

Let’s say you have some data with integer values, and you want to create a histogram of the distribution of those values, resp. their frequencies. Here, we don’t care where the data comes from – an array, over the wire, generated on the fly. We just want to store how often each value appears.

Of course, you can create an array a[i] to hold the number of times each value i appeared; first initialize it with zeros, then increase a[i] by one everytime you encounter an i. However, what to do if you don’t know the maximum i? Or what if the i‘s are sparsely distributed?

JavaScript offers sparse arrays as part of the language. However, you can’t initialize them (that’s the whole point of sparse data structures). So, any time you want to increase a[i], you first have to test if a[i] is already initialized. Looks like:

(Never mind that the for in statement is brain-damaged and likes to traverse along the prototype chain. This is one of the stupid parts of JavaScript.)*

However, the explicit test for undefined in the first fragment seems horribly inelegant to me. It feels like a roadblock. I like the following approach much better, which seems to me to be a typical JavaScript idiom (and quite different from how you’d do it in other languages):

var a = [];
while (...) {
i = ...;
a[i] = a[i]+1 || 1;
}

This works because a previously undefined array element yields undefined on reading. Adding a number to undefined yields NaN; NaN is false-y, therefore the second term of the disjunction is evaluated, which then sets the array element to the correct first value of one. If the element already was defined, then the first term produces a number larger than zero, which is true-y, therefore the second term is never evaluated. In either case, a[i] is updated with a correct value.

So, you access an array element that doesn’t exist. No exception is raised, but a special value undefined is returned that conveys an out-of-bounds error. You don’t care, you don’t test for it – instead, you do an arithmetic operation on this value. The result is again a special value, which indicates that you tried to do an arithmetic operation with an illegal value. Again, you don’t really care; you happily use this illegal value in a boolean expression. And only here you substitute a real value for the case that underway went something wrong. But not enough; in the boolean expression (a simple or), you don’t use any boolean value – you use numbers or illegal values, never a true or false.

To a purist, this looks like blasphemy. To a JavaScript enthusiast, this looks natural. My point is: work with the grain of the language, not against it. It feels much more natural.

I can’t believe I’m writing this.

* It is easy to rail against JavaScript. But I challenge you to come up with a better language, when you have only ten days for designing and implementing it …