Log

Many online services allow, or even worse, require, the so called "Security Question". It is a question/answer you can enter in case you ever forget your password or can't access your account for some reason. In my opinion, security questions are an incredibly bad idea, from a security perspective.

The usual security questions are things like "What was your mother's maiden name", "What's your pet's name", etcetera. People won't understand that actually supplying a truthful answer to these kind of questions exposes them to an incredible weakness in their account's security. These are all questions to which the answer can be found relatively easy by googling a person or applying a little social engineering. "Hey, I am John, and I think I might be related to you on your mother's side. What's her maiden name"?

The worst part is that every site has basically the same questions from which you can choose. This means that people either have to pick the same question and answer every time, or pick a different one for each account. The first will make them vulnerable to repeated attacks on all their online profiles once an attacker has found the answer. The second will make it very hard for people to remember that they must never let anybody know about their favorite pet's name "Buddy". A lose/lose scenario at best.

As is often the case with security protocols, they must be followed to the letter to be safe. One flaw in the procedure, and the security collapses. Security questions could be a good idea, provided that:

• The user makes up his own question. No predefined questions should be supplied, and most importantly, different sites shouldn't all use the same questions.
• The user should never be told what his security question was. If they need to reset their password, they should chose both the security question and the answer. This will make it much harder for a potential attacker to gain accees.

Of course, taking the above in consideration, security questions are just as hard to remember as a password, which makes them kind of pointless. Pointless or insecure, make your pick.

New development builds, and apparently the Beta build of Chrome for the Mac, strip the 'http://' part from the URL input field. Since I run Chromium for Linux, which uses nightly builds of Chrome, I am already affected by this retarded decision.

For this reason I will no longer be using Chrome, nor will I recommend Chrome to anybody anymore. In fact, I will actively recommend using any browser other than Chrome, including Internet Explorer 6.

I could explain why such a 'trivial' change upsets me so much that I'd stop using an otherwise… promising.. product, but life is too short to argue with stupid people, so I'll just leave it at that.

I'm not normally into the game reviewing thing, but I'll make an exception for Midnightclub Los Angeles because it is, without a single doubt, the worst 'racing' (and I use the word 'racing' loosely here) game I have ever wasted money on.

The story: None. But that's okay. It's a racing game, it doesn't require a story.

The rest of the game, though, sucks so hard, it created a small black hole in my playstation 3 which then proceeded to break the game CD into 5 pieces. Oh, wait, no, that was me. This game is absolutely terrible. Know that old arcade racing game called 'Outrun'? It would have been better if they slapped some new graphics onto that and otherwise release it exactly the same as it was.

Mightnightclub Los Angeles truly sucks from every side you look at it. There's no manual gear change, the cars handle like shit, you keep having to spend your hard earned money on repairing your car every single time some puts drives into it, but it never tells you how much you have to pay to repair it. It's an arcade racer for crying out loud! Cars should be indestructible (and have rockets on them, preferably). There are no prices listed for the upgrades, nor are the effects they'll have on the car made clear. The customization is a wreck, the menu's are a disaster, and mobile phone that constantly pops up must have been inspired by the one in GTA IV. It makes you want to pull out your hair and rip out your eyes.

When it comes to racing, Midnightclub Los Angeles is nothing more than an extreme exercise in frustration. During the daytime races, it's almost always near impossible to see where you're going. But since the game is called Midnightclub Los Angeles, it's always impossible to see where you're going. The roads are packed with traffic, which can be fun, but not when there's shitloads of traffic in every single race. Now I've played 'traffic' racers before, but there were always at least some races without it. Given the fact that in this game traffic is just suddenly spawned in the middle of the road, there's no way to avoid it. They probably put this in because the actually driving, and by driving I mean cornering, in Midnightclub is so immensely boring that during the fifth race I literally fell asleep, and when I woke up, I had still won. True story. Okay, okay, not a true story.. it turns out I hit thirty-nine lampposts and sixthousand and one other cars on the road, but that's still the same as every other race.

Did I mention this game is utterly frustrating yet? But wait, there's more! You see, it doesn't actually matter at all how well you do in this game. Why? Because it has that nice catch-up built in. You know, the kind where it doesn't matter if you give your opponents a head start of twenty-five minutes, you'll still be able to catch up with them (and they with you if the roles are reversed) before the race ends. A true challenge. Fortunately, the huge, yellow, view-obstructing smoke plume makes the game lot's more interesting. You never know what you'll find behind it! (A traffic jam, probably, or a house). Another thing that makes the game much more frustrating and a totally worthless piece of shit that needs to be sent to hell and suffer an eternity just like its creators fun is that, while you have no idea where you're going and keep bumping into all kinds of shit that shouldn't have just spawned there, your opponents, being artificial intelligent with pre-knowledge of the entire track, every little shortcut, the traffic and everything else, never have this problem.

I could go on and on about this game, but what it comes down to is that it's simply not a racing game. It's not a racing simulator (which I certainly wasn't expecting), but it's also not an arcade racing game. This game doesn't have a single racing element in it. The best way to sum it up is: A "look at the map while avoiding cars and steer left/right depending on where the next blob on the radar tells you to go" game. There's no way to learn the track, since you always have to play multiple races right after each other. There's no way to see where you need to go, because the game only tells you one checkpoint in advance where the actually racing track is. (sometimes these points are about 30 meters apart in the game, in a corner). The game is simply no fun at all. All it is, is… you've guessed it…

frustrating.

If I awarded a score, stars, or funny little cars between the number of 0 to five, I'd give this game a -15 gazillion and a half. But since I don't do that, and hence cannot get the satisfaction of drilling this game six feet under, I'll just say that I literally (and when I say 'literally', I do mean that literally, not figuratively) spit on this game and then proceeded to break the CD in half (in five, actually) and tossing it in the trash. I felt somewhat sorry for the other items in there having to share their nice garbage-bin with such a piece of true trash, but what can you do if you don't have an incinerator at home.

The most annoying thing about email…

When someone sends you an email, and not five minutes later proceeds to call you up or visit you to ask if you've already read their e-mail and what your response is gonna be. Then makes you explain your entire response and says "send me an email about that, will you".

I don't understand gift certificates. I mean, the idea is quite good: A piece of paper that represents a certain value, and which you can then trade for goods of some kind. Much better than dragging all that gold around all the time. So in that regard, gift certificates are an awesome idea. Except that we already have this thingy which is made of paper (most of the time) and that represents a certain value. It's called "money".

The best thing about money is that you can spend it on everything, everywhere. Whereas most gift certificates are only valid in certain stores. The only reason gift certificates make sense is if the giver wants you to spend it in a certain store. I guess that's the reason gift certificates exist: vendor lock-in. Another brilliant way of controlling how and where we spend our money. Capitalism, yay.

I prefer money.

I used to be real pleased with Ubuntu, because it got a couple of things right that Debian didn't. But I've upgraded my Ubuntu install three times now, and every time I upgraded everything broke.

The last time I upgraded, everything even remotely having anything to do with sound broke. This was because the geniuses at Ubuntu decided to include the shitty PulseAudio sound architecture in Ubuntu way before it was ready to be included. (Yeah, I know, not really PulseAudio's fault, but I'm just trying to get the PulseAudio crowd pissed at the Ubuntu crowd in the hopes that they'll gun them down).

Last time I upgraded, from Hardy to Intrepid, all my sound stuff broke again, flash didn't work anymore, my wireless broke (I've kind of fixed it now, but now NetworkManager keeps dropping the wireless connection when I push too much data through it, and can't get up again without a reboot – piece of shit), my hotkeys and all my keybindings broke, my sessions weren't saved anymore, my sound applet refuses to address the right mixer channel, my ~/.xinitrc is being ignored, I can't rm -rf / anymore (my favorite past-time thing in Linux :-( ).

Each time I upgraded Ubuntu, I found myself doing a clean install a couple of days later because too many things had broken. And even after that, many of the broken things were still busted.

I've had it with Ubuntu. It's a piece of shit. I'm going back to Debian Stable.

In the last couple of years, I've done a lot of performance optimization. I've optimized raw C, Python and PHP code. I've optimized databases: tweaked settings, memory usage, caches, SQL code, the query analyzer, hardware and indexes. I've optimized templates for disk I/O, compilation and rendering. I've optimize various caches and all kinds of other stuff like VMWare configurations.

As I've done a lot of optimization, I've noticed a couple of things. One of these things is how persons in different roles look at optimization:

Programmers always want to optimize the code. The code isn't optimal, and a lot of speed can be gained from optimizing the code. This usually boils down to optimizing algorithms to be more efficient with either CPU cycles or memory. In contrast to the programmer, the system administrator always wants to tweak the configuration of either the Operating System, the application itself, or some piece of middle-ware in between. Meanwhile, managers always want to optimize the hardware. "Developer time is more expensive than hardware", they quip, so they decide to throw money at faster and more hardware, instead of letting the developer optimize the code.

What none of them realise is that they're all wrong. None of these approaches are any good. When it comes to optimizations, all of the people above are stuck in their own little world. Of course managers just love the fact that programmers "don't understand cost versus benefit", and a nice saying such as "Developer time is more expensive than hardware" has a really nice ring to it. Managers have a high-level view of the application's eco-system, and so they search for the solution in the cheapest component: hardware. Programmers, on the other hand, know the system from a very low-level point of view. And they naturally love the fact that managers don't understand technology. They are intimately familiar with the code of their application, or the database running behind it, and so they know a lot of its weak spots. Of course, they'll assume the optimization is best performed there. The system Systems administrators have limited options either way, so they stick to what they can influence: configuration.

An excellent example of this is a recent post on the JoelOnSoftware blog. I'll recap the main points I'd like to illustrate here:

One of the FogBugz developers complained that compiling was pretty slow (about 30 seconds). [...] He asked if it would be OK if someone spent a few weeks looking for ways to parallelize and speed it up, since we all have multiple CPU cores and plenty of memory. [...] I thought it might be a good idea to just try throwing money at the problem first, before we spent a lot of (expensive and scarce) developer time. [...] so I thought I'd experiment with replacing some of the hard drives around here with solid state, flash hard drives to see if that helped.

Suddenly everything was faster. Booting, launching apps… even Outlook is ready to use in about 1 second. This was a really great upgrade. But… compile time. Hmm. That wasn't much better. I got it down from 30 seconds to … 30 seconds. Our compiler is single threaded, and, I guess, a lot more CPU-bound than IO bound.

This is an excellent example of how a manager would try to solve optimization problems. At the start of the quote we see the typical way a developer would tackle the problem: parallelize and speed up. In other words: low-level optimizations.

Now it turns out Joel was wrong. Solid State disks didn't help at all, since their problem wasn't with disk I/O at all. But that doesn't mean the developer was right either! I like to see it as a kind of Schrödinger's Cat situation: both are wrong, until one is proven right. Why is that? Because they have no idea what the problem is!. All they're doing is guessing away at the problem in the hopes of finding out what exactly will solve it, without having any clue about the actual problem! We can see this quite clearly: after having dismissed disk I/O as the problem, they assume it must be because "our compiler is single threaded, and, I guess, a lot more CPU-bound than IO bound.". Again, they jump to conclusions without knowing what the problem is. So now they might not only waste a lot of time on solid state disks without fixing the problem, but they're about to spend weeks of developer time without knowing if that will fix the problem.

So, here is my point:

The most important thing about optimization is analysis.

You can't fix a problem by simply trying different solutions to see if they work. In order to fix a problem, you have to understand the problem first.

So, please, if you're a developer, don't assume saving a couple of CPU cycles here or there will solve the problem. And if you're a manager, don't assume some new hardware will solve the problem. Do some analysis first. Finding out if disk I/O, memory, CPU cycles or single threading is the problem is really not that hard if you spend a little time thinking about it and benchmarking various things. And in the end, you'll have a much better overview of the situation and the problem, and you'll be able to come up with specific solutions which will actually work.

And that's how you save money.

There is a post up on Bill Moorier's blog about the usefulness of Unit Testing. In it, he writes the following, which largely sums up his post:

The metric I, and others I know, have used to judge unit testing is: does it find bugs? The answer has been no. For the majority of the code I write, it certainly doesn't find enough bugs to make it worth the investment of time.

I think we're missing a couple of big advantages to Unit Testing here. Unit Testing catches very few bugs when writing a new program, this is true. Most developers test their code manually in much the same way as they would with unit tests. But this is not the true strength of Unit Testing.

First of all, Unit Testing forces one to write their programs so that they are testable. That usually means: well thought out APIs, consistent interfaces and more modular code.

Second, Unit Tests serve as documentation. They are prime examples of how code should be called, what side-effects one can expect and how various components work together. That's assuming you write decent Unit Tests, naturally.

Finally, Unit Tests are invaluable when doing regression testing, which is where they truly shine. They are not for catching bugs in new code, they are for catching bugs in old code. Suppose you have a library which hasn't changed in four years. Now you find a small problem or inaccuracy in one of the routines, so you decide to fix it. You test the new code, and it works. But when you run the Unit Tests, you suddenly find that on the other side of your application twenty tests fail where they passed with flying colors before you made the change. You just discovered a regression bug.

I have the feeling that Bill Moorier is talking about Unit Testing in the context of Test Driven development. I'm not much of a fan of Test Driven development, even though most of my points still hold true. However the Test Driven development proponents, much like the Extreme Programming proponents, somehow make it out to be a magically superior way of writing software. This I have to disagree with. I see no reason at all why Test Driven development and Extreme Programming in general would deliver better software than traditional software developing methodologies and, especially, common sense. There is no silver bullet. Bad software, in my view, is more often caused by bad or lazy programmers, time limits and seriously flawed requirements than the use of the wrong methodology.

Amazon has a Amazon Frustration-Free Packaging initiative:

The Frustration-Free Package (on the left) is recyclable and comes without excess packaging materials such as hard plastic clamshell casings, plastic bindings, and wire ties. It's designed to be opened without the use of a box cutter or knife and will protect your product just as well as traditional packaging (on the right).

I hate the plastic clamshell casings. They're a terribly waste of natural resources for no good reason at all. And, like Amazon already says, they're frustrating. More companies should start doing Frustration-Free packaging. Sometimes I feel like I'm paying twiice as much money for the packaging than I am for the product itself. An USB key and headphones do not need 500 grams of plastic.

There's something I have to get off my chest. I HATE it when things in Python pretend to be something they are not. I often use IPython to introspect things so I know how to use them. Lately, I've been running into more and more libraries which return things that pretend to be one thing, but which really are something else. Observe:

import optparse
 
parser = optparse.OptionParser()
parser.add_option("-p", dest="path", action="store", type="string")
(options, args) = parser.parse_args()
 
print options

Output:

{'path': None}

"Ah", I think, "a dictionary. Swell!", and go ahead and do:

print options.get('path', 'default')

And then it responds:

Traceback (most recent call last):
  File "/home/todsah/foo.py", line 7, in <module>
    print options.get('path', 'default')
AttributeError: Values instance has no attribute 'get'

What the hell? A dictionary with no get attribute? Then, when you print the type, it turns out it's not a dictionary at all: "<type 'instance'>". It's a plain old object instance, and you have to use getattr(), etc instead of foo[key] and foo.get(). Fortunately, I've seen this trap now for so many times, the first thing I do is check the type of the thing I'm having problems with, but occasionally it still bites me in the ass.

I am seeing this more and more often, and it annoys me to no end. Python is supposed to be a rapid application development language, and things like this are extremely annoying. Don't pretend to be something you're not. If an object is going to behave dictionary-like, why not just extend the real dict object? Wouldn't that be so much easier?

So, developers: Please don't make things appear like things they're not. It causes confusion, and possibly even bugs.