Opaqueness and the Illusion of Greatness

When you don't know how things work, you image them as how you would want them to be, or according to an impression based on a random fact or advertising.

There is this old joke that goes like this:

When I was a child, I slept well since I knew someone was guarding me.
When I was in the army, I didn't sleep since I was the one guarding.
When I left the army, I didn't sleep since I knew who was guarding me.

If you served in the Army, I presume that you already know the joke and/or can relate to how sad it really is.

"What has this got to do with anything?" you wonder? When using open-source vs. closed source software, this is sometimes the case.

I got it when I was reading Jay Pipe's book "Pro MySQL". He mentions there that although the manual describes different parts of MySQL as different and encapsulated components, working beautifully together - in reality, it's all just a big pile of code, tightly coupled together and not always as modular as you'd like to imagine. He also tells of parts of the engine that were apparently written by different teams with different standards, where the code just looks and feels very different from the rest of the system. I didn't dig into the source code myself to this depth, but I believe him.
If you have worked before on the source code of an open source project, this is probably not a surprise for you - but for me it was a sort of a moment of re-enlightenment. The ones writing the database are people just like you and me, and they even write bad code sometimes. Only in MySQL, it's bad code anyone curious enough can see.

I wasn't used to this type of thinking for years, having grown up in the Microsoft closed-source ecosystem. I had no one from SQL Server come to me and tell me that they did some stupid mistakes here and there, and that the code is a mess. Yeah, there were Service Packs change logs with lists of fixed bugs, but I doubt someone in Microsoft would release a statement in the change log that tells how the sort sometimes didn't work (famous bug in InnoDB a while back).
The solid UI, the great documentation and the overall behavior of the database does its best to hide the implementation details from you. Since it was solid on the outside, I assumed it was solid on the inside. It was sort of anti-FUD. I wanted to believe it's as elegant inside as it seems outside.

I said "re-enlightenment" before, since this kind of realization actually did happen to me before, but I didn't let it sink in completely.
I've been working a lot with SQL Server in the past, and if you are familiar with it as well, you know that you can access the source code of all the internal system stored procedures. There are a lot of them, and usually you don't need to dig into their code, unless you're using some cool undocumented trick or trying to find out if something is a bug. I can tell you one thing - much of the code in those stored procedures is extremely ugly. No proper casing/indentation, hard-coded magic numbers everywhere... Maybe later I'll dig up one of these gems to show to the world. I mean yeah, it works, but still... Yuck.

Thing is, this anti-FUD was so strong, I didn't want to believe that it's that ugly on the inside - so I left my "beliefs" then as they were.

Conclusions:

1. Don't stay in the army.
2. Bad programmers can write both open and closed source programs.

Another Nasty Bug Squashed

I was so damn proud of myself to stumble upon a cool critical bug in MySQL, only to find it was a duplicate of another bug discovered 3 days earlier by someone else, and not just someone, but Paul DuBois, the author of no less than 3 books about MySQL and the likes.
My test case was simpler though - judge for yourself (#32376 vs #32260).

It goes like this - Find a MySQL 5.1.22 (or less). Connect. Run the next lines of code. Server is down. Simple, eh?

create table test.t(c int) engine = innodb;

select @var := c as c
from t
order by c asc;

This is documented as a casual "Some uses of user variables in a query could result in a server crash." in the 5.1.23 change log. Speaking of which, there is a new change log for 5.1.24 already, so this means 5.1.23 will be released really soon.

Comments in Stored Procedures - Fixed in MySQL 5.1.23

I've written before in the big Why not learn MySQL blog post, that comments in Stored Procedures in MySQL are useless.
The reason is simple - the backup/export/dump procedure does dump them into the file correctly, but when loading the file by piping it into the mysql command line client - the comments get stripped. This was a sort of an "optimization" in the client, which is now configurable.

The 5.1.23 change log says so:

mysql stripped comments from statements sent to the server. Now the --comments or --skip-comments option can be used to control whether to retain or strip comments. The default is --skip-comments. (Bug#11230, Bug#26215)

Too bad it's still not released yet, it's in development since September 2007 and the change log is already huge in comparison to the other 5.1.x releases.

Open heart surgery

Or at least it felt like that. I've just finished upgrading my Mac mini with an extra 1GB of RAM.
The little thing is so damn crammed inside, it's amazing. I mostly just followed this great tutorial - take a look if you're curious how it's done.

Well worth the trouble though, as it cost me half the price compared to the upgrade option at the Apple Store, and I'm even left with two new 512MB SO-DIMM sticks. Anyone needs those?

iTunes on the Mac and Hebrew

Hebrew, It works, bitches. Apparently all the rumors were just another case of FUD.

I'm of recent the owner of a brand new Mac mini 2.0 Ghz, but more on that later. The thing is, I've decided to give a chance to the iLife and iTunes other iBuzzword products.
The moment I imported my library to iTunes, I've noticed it cannot read my Hebrew song names from the ID3 tags. I assumed that according to what I've heard before, the Hebrew support on the Mac is not so good, so I left it as it was. Later on, when browsing through the library, I saw some of the names in Hebrew. Hmm. *Ding*.

Apparently, iTunes works great with Unicode, but not with the Windows Hebrew Codepage, also known as CP1255. It even provides a built-in feature to convert from ASCII in the ISO-Latin1 codepage (and only it), to Unicode. After wandering around the Interweb, I found a nice little utility (aptly named "Unicode Rewriter") that does just that - almost automagically. Choose a source codepage, and you're done. In 15 minutes, I converted all of the songs to Unicode with the click of many buttons and a bit of dragging & dropping. It might even work in Windows, I didn't try it.

Now all I'm left with is the endless task of importing and organizing all of my music.

D'bah

When people that are not somehow related to computers ask me what I do - I tell them I'm a programmer. This profession has become enough of a commodity in the last years, so that there everyone know what a programmer looks like. The knowledgeable ones ask in which language I do my programming. Then it gets tricky.

-"Well you see, I'm not really a programmer, I'm actually a DBA!"
-"What's a D'bah?"

Now it's down to two options:

1. Explain what databases are, and what part they take in the products they know and love. Explain why it is different from programming, and why you have a specific person to do it. Dive into the implicit and explicit duties and responsibilities of a DBA, and describe how a person in this spot interacts with the development team and management.
   Usually this a great choice if you want to be left alone or be met with bored looks.
2. Say "It's like playing with Lego for money." or "It's like herding data."

How can you explain that being a DBA is different from being a programmer? Maybe it shouldn't be? What really defines a DBA's role?
The answer is the typical and classic reply you'll usually get from a DBA: "Well, that depends".

I'll try and go into more detail about this in another post.