Log

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.

Free Speech. Why is it important? Because it's an extension of Free Thought. Should we be able to think whatever the hell we want? Yes we should. Controlling Free Speech is about nothing more than controlling Free Thought. "You're not allowed to say this, because somebody might not agree with it. You're not allowed to say that, because somebody might feel hurt by it". What they're really trying to do is control what you can think. Trying to generate a "mindset", a "zeitgeist". Brainwashing is more like it. Well, fuck that. I'll think about whatever the hell I want and as long as I'm thinking it, I'll be saying it.

So fuck the Dutch government for trying to outlaw Free Thought, and keep on publishing cartoons showing Mohammed, wearing t-shirts implying cops are corrupt (which they are), making Death-Threat Raps and telling the public about how the politicians are the real terrorists. Remember that little rhyme you used to use when you were a kid? "Sticks and stones may break my bones, but words will never hurt me"? Guess what? Kids are smarter than our police, politicians, religious fanatics and the whole government. Grow the fuck up.

This country is going to shit. Time to move to Cuba, where you're allowed more freedoms these days.

I just finished writing an article for my blog. It took me most of the evening. Researching, writing, proof-reading, rewriting, linking to articles, etc. I click save, and only one-third of the article shows up in WordPress. The rest? Gone. Hours of my hard work? Gone. Careful proof-reading, rewriting, analysis, unbiasing, rereading? Gone.

THANK YOU WORDPRESS, YOU PIECE OF SHIT SOFTWARE!

I'm guessing it's wordpress' auto-save functionality. This isn't the first time this has happened (it happened about six times so far, always with articles that I spent the most time on), but it will be the last. This will be the last article I ever write using WordPress. I hate the product, and from now on, I will use every means at my disposal to discredit it as a useful piece of software.

WordPress sucks, and you shouldn't use it! Spread the word people!!

I'm starting a conversion of my blog to MvBlog tomorrow.