Paving the Pathways

There's a story (sometimes attributed to Christopher Williams) of an architect who designs a cluster of buildings on a university campus. After months of erecting the buildings, the site is nearly finished. The owners compare the results with the estimate, and note that there are no walkways between any of the buildings, and instead, around and between the buildings the architect merely put down a grassy lawn. When asked about it, the architect tells the university that it should commence using the site and he will finish later.

The architect comes back in one year, and then observes the patterns in the grass made by the foot-traffic, and then knows -- better than he could ever have predicted -- where the pathways should go. He knew that the traffic flow could never be anticipated, even if he worked out vast models by analyzing demographics, the class schedules, and dormitory populations. Instead, he made something almost good enough for any case, and let the unpredictable world tell him how to make it perfect for the only case he really has. He looked for the ruts, and then paved the pathways over them.

I think there's a valuable lesson in this story: We shouldn't spend time trying to anticipate what can more easily be made good enough for now and perfect later. Don't prescribe a pathway; give latitude to the people and then describe what they do.

But that kind of approach to solving a problem is anathema to many people. Perhaps they're in the minority -- I don't know. I do know that once a few people smell a problem and start talking about how to fix it, it's hard to convince everyone to wait a while and see if the natural usage near the problem organically suggests a solution. Those who start too early lay a kind of claim to the problem, and everyone who cares about it has to jump in and contribute or else watch it develop without their input. Even if the premature solvers are in the minority, they tend to pull everyone with them. Image the architect in the story watching the some of the builders and landscapers arguing and pointing and demanding to know where to put the pathways; the cement is mixed and they have to put it somewhere before it dries.

Unfortunately, even if the idiom of "paving the pathways" is a problem's best solution, small isolated attempts to solve the problem too early often snowball out of control and force an early, sometimes poor, solution.

සිංහල, Sinhalese collation

If you search for Sinhala, a large fraction of the links you'll see point to something written by Harshula "hash" Jayasuriya. Sinhala is a very, very old language, but it's not very well developed on computing platforms. Its script is most often represented in Unicode, but the default Unicode collation table (DUCET) doesn't order its words ("collate") properly. Thus, MySQL didn't order it properly.

To fix that, hash recently submitted a collation implementation to MySQL, based on the Sri Lanka Standards Institution's SLS1134-pt1 document. It seems to be right, judging from our tests, but I would be much more comfortable if it were exposed to more eyeballs. The collation is on its way into the mysql-5.2 tree, and should be downloadable any day now. Please, if you know something about Sinhalaese, check our work against what you expect.

Debian and MySQL

I promise, MySQL really does care about Debian. Since I arrived ten months ago (and even before that it seems), there's been several hand-wringing discussions about Debian and how we should approach it. The Debian and Ubuntu Developers do a fantastic job packaging mysql server, and I have nothing but respect for their efforts.

With RPM-based distributions, it's easy to tell people to download and install a package file. They expect it. They don't expect automatic upgrades. Creating a RPM file is easy because there's no implicit agreement about how to update it.

Our problem with Debian is that it's just too fantastic. That is, our Debian-using customers know that for almost everything, it's hard to do better than Debian does. We at MySQL wants to be able to give people our own binaries for several reasons, some good and some bad: Timeliness of package arrival; a Not Compiled Here disorder; options and defaults set as support-engineers expect; et c. . So, we're trying to figure out how we can give people our code in a supportable way without pretending to supplant Debian's role.

We don't have all the answers yet, but please be assured that we are working on it, and have been working on it since well before the Slashdot noise.

Tiny Victories, 2006-12-01

It's not often that I get to pull Knuth's The Art of Computer Programming down off the shelf and immediately solve a problem with it. Today, I did.

A big "Thank you!" goes to my parents for giving it to me long ago.

The problem is that for the way almost all computers work, floating-point numbers do not follow the associative property. This results in wrong results and a good bit of hilarity.

Thirsty work

Not having a watercooler, around which we can stand and gossip, is a serious drawback to working at home. MySQL's 300ish employees are spread out over 20-something countries. Most of the people with whom I work closely are not within a few hours of my timezone.

Our primary communication medium is IRC, a kind of continuous chat system, like an agora where people group themselves together on topics, rather than like the person-to-person chat that most people know of. Outside of that, we occasionally use our telephones, which connect to the Internet directly, bypassing long-distance carriers and bills. And, of course, there's (now-ubiquitous) email. If you consider the loss of nuance in hurried textual communication and the ever-present risk of culture-shear, one would think we would have far more misunderstandings than we do.

Not having the watercooler means that I don't often hear the voices of those I work with. Many have thick accents, so I'm often thankful that I have written word to pore over and decipher if it needs it.

Tiny Victories, 2006-11-27

First, history: Linux has a reputation of having an unpleasant UI. I don't think it's deserved. I'm totally addicted to one feature of Gnome, and that is the ability to move and resize windows without using my precision-mousing skills to find the tiny sliver of bar on the top or bottom to "grab" and drag, in order to do the most common of all interface changes: resizing or moving a window.

In the Gnome world, we can hold the Alt key and left-click-and-drag anywhere in a window and the window moves along with the mouse pointer. Instant, easy moving of windows. We can also hold Alt and middle-click-and-drag inside a window, and the nearest corner is resized as the mouse pointer moves.

The victory: I use a Mac OS X machine, which (at least historically) has a reputation of having a fantastic interface. But, to resize a window one must find a tiny square in the bottom right of most windows (depending on toolkit) and drag it.

No more! WindowDragon allows one to set the same behavior for OSX. Yay!

Another must-use tool for OSX is Quicksilver, which almost makes not having a command-line immediately available tolerable.

Thus it begins

No, I refuse to use "blog". I shall say "web-log" because I don't think it deserves a new space in my dictionary. Goin' Out West is a tune by the inimitable Tom Waits.

I intend this as a diary for my life at MySQL AB, instead of using my personal site. I don't claim to represent MySQL (hereinafter dubbed Johan Company) in any official capacity.

My name is Chad, and I started with Johan in February 2006. I think it's the best job ever. I've used and written Free Software since discovering it in the middle of the '90s, and mysql was the first SQL database I used. I visited PostgreSQL-land for several years, and still have several instances running.

It's not that I don't think mysql is good enough to adopt everywhere. No software is perfect, but as of the middle of this year, I think the 5.0 version of mysql is good enough. postgresql may have been good enough first, but mysql is as good by most criteria, and soon to surpass it in all but a few criteria. For what I'm doing (not very much), there's not enough difference for me to bother changing; it would have no effect on me other than expending time. I do think that using postgresql so recently gives me a useful outsider's perspective on Johan and mysql-the-software.

(Speaking of that, when I make a name all lowercase I mean the software, but uppercase letters indicate an organization.)

As of right now, Johan has about 300 to 350 employees, and about 1/4th of us do nothing but write software. Almost all of us work from home, which has effects I'll talk about for my first few posts.

Welcome!