LinLog

Today I "discovered" a little feature in Opera that I didn't know about before. That was a nice feeling. It's always good to find something new in an application that you use every day. Even if you're not sure how useful it will be.

This particular feature is an item in the context menu for web page tab: the "create linked" command. This has the interesting effect of creating a new tab that receives navigation for the selected tab. So if you click a link on the original tab, it will remain unchanged but the new "linked" tab will go to that location.

By itself, this doesn't seem particularly useful. However, when combined with Opera's MDI, you can do side-by-side navigation, which could be usefule for checking references or documentation. The "linked" status of the tab also survives detatching into a separate window, so you can use multiple windows rather than the MDI if you're so inclined. In fact, this is probably better, since the MDI just doesn't feel right since they switched to the visual "tab" appearance.

This week, I'm doing product evaluations at work. Specifically, evaluations of highly enterprisey system management applications. Things like Microsoft System Management Server (though I'm hoping to find a package that's slightly less hideously complicated to administer). And you know what? It's really starting to piss me off!

It's not researching an evaluating these systems that's pissing me off. Although it probably should. After all, I'm a "systems analyst," not a network administrator. I don't touch the servers without explicit permission from the network admin, and therefore don't have a great deal of experience in this area. This is not because I don't know what I'm doing (though I don't claim to be an expert on Windows administration), but because the admin jealously guards his network, and he will strike down those who trespass upon his servers with great fury! Woe to any analyst or programmer who should mess up a server in even a minor way, for he shall never again get anything done on the network. So sayeth the Lord!

The real reason I'm pissed off is that I have no test hardware. Or, more to the point, I have test hardware, but it really, really sucks. To summarize, in order to set up a Windows Server 2003 box, I'm using an old XP desktop with a RAM module cannibalized from an identical desktop just to get it up to 1/2 a gigabyte. The client boxes I'm going to have to set up will have a whopping 128MB of memory a piece. And this is the best we've got available.

Of course, my ideal setup would be to just use a completely virtual test network running in VMware. However, I'm planning on 1 server and about 3 clients initially, and the most powerful box I have available is my desktop workstation, with a measly 1GB of RAM, which would be kind of pushing it. So I'll probably end up with 4 PCs sitting in the server room running VNC servers so that I don't have to physically walk back there and let the roar of the air conditioning system slowly destroys my hearing.

The second reason I'm pissed of is because of who this project is for. If our organization made any sense, we would be looking into system management software for the 300 or 400 (or whatever - I've never seen the exact number) desktops that we support. But it's not. This is for a collection of about 60 mobile laptop units that are scattered across the countryside and hardly ever make it in to the office. The idea is that we'd like to manage updates, installations, configuration changes, and so forth on them without having to drive them 30 or 40 miles to someone with administrator access. I have no problem with that, since only three people have admin access on those machines, and I'm one of them, so it saves me some effort. It's just that it would be nice to be doing something like this in the place where it would save the most work. But then, without the constant running around clicking "next" and such, our department wouldn't have an excuse to be grossly over-staffed.

I guess the take-away here is, "Don't work for the government. Especially local government." There may not be much stress in the Silicon Valley sense, but the frustration and futility levels are through the roof. But on the up side, you can pretty much take a vacation day whenever you want and nobody cares. It's just a matter of whether you prefer stability and flexibility or a feeling that just maybe your days aren't completely wasted.

Digital cameras are a great thing. They're easy to use, have a high picture capacity, and you don't have to pay for film. Plus, when you take a weird or interesting picture, it's easy to put it on your blog.

While at the Buffalo Zoo the weekend before last, I managed to capture two things I had never seen before. Here they are for the curious.

The first is a bear fight. On the way out, we witnessed the Grizzly bear and the Kodiak bear play-fighting. They would tackle each other, bite and paw, and chase one another around the habitat. They didn't appear to be hurting each other, just playing like dogs or house cats might. I never knew bears did that, though I guess I shouldn't be surprised. Still, it was quite the sight.

This second picture is of the alligator feeding. We happened upon the alligator habitat just as the zookeepers were going in to feed it. It seems like the kind of job that should include hazard pay, because they kept having to push the gator's nose back with a stick to discourage it from coming too close.

As for the meal itself, it was somewhat unpleasant: dead rats. I don't know what I was expecting, but it wasn't that. Though I guess I shouldn't be surprised. I don't imagine an alligator would do too well on a diet of rice and tofu.

While all went well with purchasing that DVD set off eBay, all did not go well with watching it. The first disk didn't play correctly in either of our DVD players. Yet, oddly enough, it was fine in my PC. Isn't that the reverse of how it's supposed to work?

The DVD set is a Japanese release of the first season of Kyo Kara Maoh. It's an all-region disk that has both the Japanese and English dubs. I'd have preferred an American release, but they didn't have any boxed-sets available yet and buying the disks one at a time would have cost at least 6 times as much. The disks came in imaculate condition, with no visible scratches or defects, still in the factory shrink-wrap.

We have two stand-alone DVD players in the house, one for each TV. One is at least 5 years old, the other about 2 or three years old. Both of them displayed the same problem when playing the first disk in the set. During playback, I experienced random pauses, ranging in duration from just a moment to several seconds. The pauses seemed to become more frequent and longer lasting the longer than disk played. However, the pauses did not appear to be due to disk defects, because they never occurred in the same places. In addition, the entire third episode was completely unplayable. The video was garbled and the had frequent pauses and skips, eventually just hanging. And, of course, the menus are seriously messed up and only sort of work.

The weird thing is that when I put this same disk in the DVD-ROM drive on my PC, it plays perfectly. No pauses, no glitches, and both the third episode and the menus are fine. Normally, what with CSS and all, you'd expect it to work the other way, with the PC having problems while the stand-alone appliance works flawlessly. But not this time.

I'm still not sure exactly what the problem is. I've read that newer DVDs can expose bugs in older players. I do know that the DVD is a little wonky, what with having only 1 title, but 48 chapters, not to mention weird subtitle settings. But it seems odd that both players would have the same bug. So far, the all-seeing oracle, a.k.a. Google, has failed to turn up any answers. Does anyone else have any ideas?

This week I started dabbling in Ruby on Rails. After reading Scott Hanselman's and Mike Gunderloy's coverage of RailsConf, I almost felt like I had to. So far, I'm impressed.

For anyone who hasn't been paying attention, Ruby on Rails is the current "big thing" in developing web applications. Ruby is a dynamic, object-oriented programming language from Japan. So far, it seems to read like the bastard child of Python and Perl. But in a good way, if that's possible. Rails is an MVC web application framework for Ruby. Through the magic of Rails, you can literally create a working, if extremely basic, database application in less than 10 minutes. No joke.

I haven't had much time to play with RoR yet, but it seems really, really nice. It basically takes all the pain out of building data-driven web applications. Rather than spend your time messing around with database access - buidling the plumbing, designing insert/edit screens, and so forth - rails lets you automatically generate all that stuff. For example, in the tutorials, they just have you create a new Rails application, create a new MySQL database and table, and run a couple of commands. Then you can fire up a web browser and add records to the database. All without writing a single line of code!

The thing that's really nice about RoR is that it encourages good system design. The default Rails application has a proper model/view/controller architecture, includes testing infrastructure, and other good stuff. In other words, it gives you a good starting point. Contrast this with Visual Basic. Bask in the VB 6 days you used to see tutorials on data-bound controls that showed you how to build database applications without writing a single line of code. All you had to do was drag and drop a bunch of controls in the VB designer and voilà - instant application. The only problem was that VB 6 seemed to actively encourage writing really crappy code. For instance, it generated brain-dead default names for all those drag-and-drop controls - why name a control DataSource1 and force the user to change it when you can just prompt him] for th econtrol name? It also made no attempt separate the interface, data access layer, and business logic. In fact, doing that made the magical drag-and-drop features less helpful. And unit testing? Was that even possible in VB 6?

My only complaint about RoR so far is that there doesn't seem to be a lot in the way of documentation yet. Sure, there's the API reference, but not much in an instructional vein. And so far, I'm unimpressed with the two tutorials I've looked at. But I suppose I can let that slide. After all, RoR is quite new - building up a good documentation base takes time. Of course, by the time we get some good tutorials, I won't need them, so what do I case?

Well, I'm back to fatblogging. The last couple of weeks have been kind of busy, so I hadn't gotten to it. Actually, what happened is that I was getting wierd weight readings. I'd be 194 in Thursday morning, 190 in the afternoon, 193 Friday morning, and so forth. My plan was to average out the readings over a few days and post on the weekend. But then I was busy on the weekend and kept forgetting to weigh myself. Hence I never got around to posting about it.

Anyway, I this morning's reading was 189 even. That makes a grand total of 44.2 pounds so far and only 9 pounds left to my original goal weight. Yay!

Eugenia at OSNews ran an editorial today regarding password storage in the popular Pidgin IM client (formerly known as Gaim). Her complaint was that Pidgin stores the user's passwords as plain text, which is obviously insecure. However, the developers strenuously object to her proposed solution: obfuscation.

Basically the situation is that Pidgen does not have an encryption scheme for IM account passwords. Some people have submitted patches, e.g. to use gnome-keyring, but the developers don't want to tie themselve to any particular keyring implementation. So, in the absence of any real security, some users have suggested adding fake security, such as ROT13 encoding the passwords. Their argument is essentially that such obfuscation is better than nothing. The Pidgin devs, on the other hand, argue that this does nothing but provide a false sense of security, which is actually worse than being insecure.

I think the Pidgin developers have a good point here. For one thing, the use-case for obfuscation seems to be a little shakey. The general idea is that obfuscation would keep your passwords safe from nontechnical users who would have local access to your machine, such as a parent or co-worker. Presumably they would be able to find the accounts file, but not figure out the obfuscated password. The problem with this is that tools and methods to "recover" IM passwords are all over the net. All you have to do is Google it. Obfuscation would only stop people who are too stupid to use a search engine and those who are too unmotivated to use one. And for those types of attackers, proper file permissions and locking your terminal when you get up from the desk would be sufficient anyway.

To me, this sounds like a "shut up" feature, i.e. the kind of feature a developer implements not because it is actually good or useful, but because the customer thinks it is good and useful. "Fine, I'll do it if it'll shut you up!" This doesn't add any real security and it's not clear that it would stop even non-technical users who actually want your password, but it would make users feel better. That's the kind of thing you do in the commercial world for a whiney customer. I don't think it has any place in the open-source world.

You know what sucks? Office meetings. And I'm not talking about "office meetings" in the sense of meetings that take place in a room full of cubicles populated by people who die a little inside every day. Although those suck too. No, I'm talking about meetings about Office. Microsoft Office. Specifically, my employer migrating from our current, hideously out-of-date Office 97 plus Outlook 2000 setup (don't ask me why the two versions) to Office 2007.

We've been having these meeting every Friday since the beginning of April. The first one was an entire hour on Microsoft Outlook. The second was 45 minutes on Word and Excel. The third was half an hour on Access. Since then, the meetings have been on the order of 10 minutes a piece and have consisted mostly of someone from the help desk saying that the new version had been installed on so-and-so's PC.

Believe it or not, there is a matematical reason why we continue to waste our time on these pointless meetings even though we've run out of things to talk about. You see, in any bureaucratic organization, the number of total meeting associated with a project is given by the equation:

Here, m is the number of meetings, d is expected project duration, i is perceived importance by management, and s is the sanity quotient of the organization. Note that there is no factor relating to the need for discussion.

In our case, the Office 2007 installations will take a while because we have to do it all by hand - having an automated deployment system would make far too much sense. And since the new version of Office affects every department and is highly visible to users, my boss thinks it's extremely important. And as for the final factor, as a government agency we necessarily have an extremely low sanity quotient. Thus we have a standing meeting, even though it's completely pointless. Ain't bureaucracy grand?

Here's a weird one. For some reason, my Digitalway MPIO FL100 MP3 player can't see files that are copied onto the removable SD card from Windows. But files copied from Linux show up fine. Is it just me, or does that seem a little backwards?

What happened was that I wanted to listen to a few podcasts this morning. I didn't feel like running downstairs to get the SD card out of the MP3 player, and I didn't want to download them from work, so I just dumped the files on my USB thumb drive before I left the house. When I got to work, I whipped out my portable USB SD card reader, copied the files from the thumb drive to the SD card, and slapped the SD card back in my MPIO. I turned the player on, started browsing the playlist and...nothing. The files just weren't there.

My frist thought was that something must have gone wrong. Maybe I disconnected the card too early and the files didn't copy. So I hooked the SD card back up to my Windows XP workstation and checked. Hmm.... The files were definitely there. Were they corrupt? Didn't seem to be. The file sizes looked right and they played in Windows Media Player.

Maybe it was because the card was almost full. It's a 1GB SD card and there were only 6MB left. Maybe the MPIO can't quite address a full gigabyte. So I moved the files I was trying to play off the card, deleted a few old files, and moved the new ones back. OK, now I've got about 50MB free, which has always been enough before. But when I plugged the card back into the MPIO, it was still a no-go.

After a few more unsuccessful variations on this same process, I started to wonder if the problem was with the SD card reader or even Windows itself. After all, this never happened with my internal SD card reader on my home Kubuntu system. So just for the heck of it, I fired up a copy of Kubuntu running in VMware. I plugged in the SD card reader, moved the MP3s off the card, unmounted and remounted, and moved them back on. This time, when I put the card back in the MPIO, it saw the files. I was able to select them in the playlist and they played perfectly.

At this point, the question is: What the hell happened? According to fsck.vfat, the SD card uses a FAT32 filesystem with long filename support and doesn't show any errors. Theoretically, Windows should be able to read and write that with no problems. And it can - but not in a way the MPIO can read. Is there some extension to FAT32 that Windows uses but Linux and the MPIO don't? Is this due to some implementation-specific detail where the MPIO agrees with Linux but not Windows? There's got to be some rational explanation for this. Does anybody have any ideas?

It seems the three big news sites in my aggregator - Slashdot, OSNews, and Digg - have all picked up this Wired story about Firefox. Apparently people are starting to complain that the Fox has gotten slow and bloated. I guess they haven't been paying attention.

As an Opera user, this is something of a sore spot for me. First, the contention that Firefox is getting slow is complete and utter BS. "Getting" is irrelevant. Firefox has always been slow. Granted, speed is relative, and while FF may be fast compared to plain-old Mozilla (now known as SeaMonkey), Opera has always been way faster than both of them. If you don't believe me, try running Opera and Firefox side by side on a Linux box with a 500HMz processor and less than 256MB of RAM. The difference is painfully obvious.

And speaking of RAM, Opera has always had a lower base memory footprint than Firefox. As an example, here's a quick, highly unscientific screenshot comparison of memory usage in Opera 9.20 and Firefox 2.0.0.3 running on Windows XP. Note that Firefox has 9 extensions enabled and 6 tabs loaded. Opera, on the other hand, has 24 tabs loaded.

The really interesting thing to note here is that Opera's memory usage is quite variable. The 22MB in the screenshot is when Opera is sitting minimized in the task bar. Once I maximize it and start browsing, the numbers go up. In fact, the memory usage got up to 120MB at one point, but as soon as I minimize the browser window, it drops back down to 20MB or so, presumably transferring the data to disk cache. When I bring the browser window back up and start switching between open tabs, the RAM usage slowly creeps back up. So Opera is actually quite smart about memory. Not so with Firefox - its memory usage remained static when I tried the same thing.

Of course, Firefox would probably have a significantly lower memory footprint with no extensions enabled. But then, what would be the point of using it? After all, extensions are one of the big selling points. It's also where most of the cool features are implemented.

I always thought that was one of the biggest problems with Firefox: it almost forces you to install a bunch of extensions. Out of the box, Firefox is a good browser, but it's nothing special. I suspect the development team is finally starting to realize that having lots of good features out of the box is important. The extensions are great, but finding and downloading them is a pain and many "regular" users simply can't be bothered (not to mention the compatibility issues). By integrating them into the core, you spread the benefit to the masses rather than just those with a technical bent. Plus, you can (in theory) get better performance with the native C/C++ in the core than with a JavaScript extension.

So I still use Opera everyday and use Firefox for web development. I find Opera faster and easier to use in many respects. But Firefox has the Web Developer, Firebug, and HTML Validator extensions, which are really compelling. Now if only Opera would implement an extension mechanism and allow you to set an external RSS reader, I'd be all set....

I have gamercise-induced writer's block. That's my term for being unable to think of anything good to blog about because I'm tired from playing high-impact video games.

Aside: Boy, "high-impact video game" is kind of a tortured phrase, isn't it? It sounds like the force-feedback controller is going to leave bruises and knock things off your shelves. Actually, it remindes me of one gamer I heard refer to "high-stakes games." Doesn't that give you images of the computer electrocuting you if you lose?

The reason I'm tired is because Sarah ordered herself a copy of Dance Dance Revolution for the PlayStation 2 the other week. I didn't have any interest in it, but she wanted something fun to do for exercise. It also had the side benefits of being relatively cheap and actually putting my PS2 to use.

However, when I watched Sarah actually playing, it looked like a lot of fun. I always thought it looked kind of silly, but when I tried it, it really was a lot of fun. And I can't even dance! In fact, not only am I not very good, Sarah tells me I look like a spastic chimpanzee while I'm playing. But I don't case, because it's still a lot of fun.

I'm kind of enjoying this whole physical video game thing. It's a lot of fun and it actually does get your pulse up. In fact, it would be nice to get the PS2 in a room other than our bedroom. That way, I could play Dance Dance Revolution for my morning exercise rather than just doing half an hour on the eliptical machine. I wouldn't be able to read at the same time, but it sure would be more exciting.

And while I'm at it, maybe I should get a Wii. Those look like they'd be great fun too....

It's time to start getting my skills up to date. And not just learning the programming language de jour, either. Learning new languages is nice, but as they say, you can write COBOL in any language. No, it's time to get up to speed on methods and practices.

My current project is to get myself up to speed on test-driven development and unit testing in general. This was prompted in large part by listening to an old episode of Hanselminutes on dynamic vs. compiled languages. Scott made the point that TDD and dynamic languages are (or should be) linked. Since you can't rely on the compiler to catch errors early, you need to replace that with continuous unit testing.

That made sense to me. I'm a fan of strict languages and static analysis. In fact, I'm one of the last 9 guys on Earth who thinks Ada is a really great programming language. (Note: That is a made-up number. The actual number is 14.) Since you don't have that safety net with dynamic languages, you need to find something else that can pick up the slack. Since unit testing is good for lots of other things as well (like detecting regressions), it seemed like something that was worth seriously taking up.

I've started off my journey by playing with the Simple Test unit testing framework for PHP. I came across it by chance and decided to go with it because the site had some helpful introductory articles on unit testing. I have a C# project I'll be starting at work this week, so I'll also looking at NUnit soon as well.

At the moment, I'm still trying to wrap my brain around the way TDD works. Conceptually, it's not that complicated. It's just that it's a more bottom-up approach than I'm used to. When you write tests first, it seems like you almost have to start by writing the basic building blocks and work your way up to the more complicated methods. However, I tend to work in reverse, starting with the "meatier" methods first and writing the supporting methods as I figure out what I need. But maybe that's not the best way to work. I don't know. I've still got a lot of reading to do.

In Roger Johansson's latest thoughts on HTML 5 (which I generally agree with), he mentions a potential browser feature that I've been wanting for some time: built-in notification of markup parsing errors. He even linked to a Firefox extension that implements it.

There are two reasons this would be an extremely great feature to have in all browsers. The first, and most obvious, is that it would make web development easier. Need to validate all your pages? Just visit them. Instant feedback with no need to mess with web-based validation services.

The second reason is essentially the one Roger gives. That is, it would be a nagging little problem indicator that's actually visible to users and developers. It basically adds accountability. Users might not care about the markup per se, but they may very well be concerned that there's a little red error icon in their status bar. It's a little harder to justify bad markup when you have to explain to customers why you haven't fixed it.

For now, I guess I'll just have to make due with that HTML validator Firefox extension. In my 20 minutes of using it, I've found it surprisingly powerful and quite handy. Now if only they had one for Opera....

Last night I bought something through eBay for the very first time. It was a DVD set that I'd been looking for for a while. I actually discovered the aution through Google. The price to "buy it now" on eBay was lower than any other sites I could find and the auction ended in an hour, so I figured, "Why not?" As it turns out, because it's a lousy online shopping experience. That's why not.

Let me state right up front that, aside from one technical issue, I didn't actually have any problems making my purchase. I successfully signed up for an account, paid for the DVD set through PayPal, and today received a notice from the seller that it had shipped. So in terms of actually getting what I wanted, it worked perfectly. And yet, the process of setting up an account and buying the item through PayPal was so thoroughly annoying that it put me in a foul mood for the rest of the night. It's almost a case study in how not to implement an online shopping system.

Problem 1: Long, annoying registration

My first problem with eBay was the long, annoying account registration form. Actually, I think it might have been multiple forms. There were so damn many forms involved in this process that I kind of lost track after a while.

However, I do clearly remember that eBay needed a credit card number to register an account, even though they claim they won't actually charge it and they don't directly handle payment. This alone made me uneasy. So that's -5 points for eBay right off the bat.

Problem 2: Broken AJAX

Related to the annoying registration form was the one actual problem I encountered. As part of the registration, you have to select a unique eBay username. Of course, to me this was nothing but a hinderance, because I don't give a damn about establishing any kind of identity or reputation on eBay - I just want to buy the stupid DVD and get the hell off their site!

Anyway, to make the registration process somewhat more "user friendly", the username box had a button to check that the name you entered was unique. This button disabled the username box and form submit button, started a little "waiting" progress indicator, and made an AJAX call to eBay's servers.

Unfortunately, the AJAX call never returned. A quick look at Opera's error console indicated that this was actually due to the JavaScript violating cross-domain security rules. This cause Opera to (correctly) terminated the script. However, that left me high and dry, because the script had disabled the form's submit button, so I couldn't test the username the old-fashioned way. Instead, I just had to refresh the page and fill in the form again. That's -10 more points for eBay.

Problem 3: Confusing payment

Now that I had an eBay account and had committed to buy the DVD set, it was time to pay. Like a fool, I selected the seller's preferred payment method: PayPal. In particular, I used a credit card through PayPal.

This proved to be somewhat more confusing than I would have thought. For the payment, I was redirected to a third-party payment service. However, I was paying through PayPal, and was eventually redirected to them. Don't ask me why. I don't really understand why I couldn't just go straight to PayPal.

What's worse, at no point during the payment process was I actually sure that my credit card had been billed. At one point, I thought I had successfully paid, but was them prompted to login to PayPal or create an account. After that, my transaction was apparently complete. I think. Or maybe I didn't need to create a PayPal account. I'm still not clear on that.

I'd say this is -20 points to eBay and/or PayPal. I mean, I'm a computer programmer, for crying out loud. I'm not supposed to get lost navigating thought payment forms. I know I'm not perfect, but even on a bad day, a process like that has to be pretty poor for me to get as confused as I was. Hell, I still don't know what the heck happened. All in all, the whole process had a really ad hoc feel to it. Too ad hoc. When it comes to dealing with money, I don't like to feel as if software handling the transaction is held together with the code-equivalent of Scotch tape and bubblegum.

Problem 4: Saving my credit card

I had a couple of nits to pick with the PayPal signup process. The first was that they unilaterally decided to save my credit card information to make future purchases more "convenient."

The problem is, I don't want PayPal to store my credit card information. I don't trust them, or anybody else, to keep that on file. In fact, when I have the choice, I make it a point to never let any online store save my credit card info. I want them to hold onto it just long enough to get the charge authorized and then forget it.

I say that's -20 points for PayPal. It was nice of them to inform me that they were saving my info, and it was nice that it was easy to delete it after the fact. But they really should have offered some kind of opt-out feature. Is that too much to ask?

Problem 5: PayPal vitiates its own credibility

You know what smacks of incompetent, amatuer web design? Pages that play sounds. And that's exactly what one of the pages in PayPal's setup process did.

It was on a page with some kind of coupon offer. When the page loaded, a voice actually started reading some kind of instructions. I couldn't believe it. It was like a bad flashback to Geocities circa 1996.

And to make matters worse, the page was already really text-heavy to begin with. So not only did I have all this text to deal with, but I also had to listen to somebody yammer on about something I probably didn't care about. All I can say is, "Thank God for the mute button."

I give PayPal -100 points for that little "feature." That was the straw that broke the camel's back. It completely destroyed any trust I had in PayPal. In fact, at that point I seriously considered just walking away from the whole transaction and buying from a different site. And if I hadn't already entered my credit card information, I probably would have. I was already a little wary of PayPal, so the last thing I wanted to see was fourth-rate incompetent "webmaster" crap like that. If that's the best they can do, I don't want them handling my money.

The end

So there you have it. A happy ending to a miserable experience. I wasn't cheated or misled, and yet I regretted making this purchase before I was even done with it. I felt a little better about the whole thing in the morning, and a lot better after seeing that my purchase had shipped, but the whole experience left a bad taste in my mouth. I don't know if I'll ever use eBay or PayPal again. But at the very least, I won't be running off to do so any time in the forseeable future.

This is going to be a short one, because Sarah and I are on our way out the door. We're taking the weekend to go to the lilac festival. To that end, I finally loaded up basically all the music we have on her iPod.

Is it just me, or are the iPod apps available on Linux a little lacking. I like the iPod integration in Amarok, but there doesn't seem to be a simple and obvious way to say, "Just dump this 10GB directory onto the iPod" or "dump the new files in this 10GB directory onto the iPod."

GTKPod, on the other hand, makes it relatively easy to dump large directories onto the iPod. However, have you seen the user interface? I found it more than a little confusing. For instance, why is the "save" button the one that transfers the files? That just doesn't make sense to me. And neither does the rest of it, frankly.

I guess I'm going to have to do some more research on this iPod stuff at some point. But not today.

Today, inspired by the little productivity tips from yesterday, I took another look at Katapult. If you've not heard of it, it's a little hotkey-based application launcher for KDE that comes pre-installed with Kubuntu. However, as I discovered, it can do more than just run applications.

The basic idea behind Katapult is simple. It runs in the background, waiting for you to press a hotkey combination. When you do, it pops up a pretty little window that catches keystrokes and matches what you type against the installed programs. When it finds the one you want, you hit enter and it runs.

There you have it. Simple, efficient...and not particularly useful. At least, I didn't used to think so, because you can only enter programs with a .desktop file, not arbitrary command lines. It's kind of handy when you don't feel like typing a full executalble name, but what's the big deal?

Well, it turns out that Katapult does more than just launch programs. It does a number of other handy things as well. For instance, you can use it as a calculator. Just type in numbers and arithmetic symbols instead of letters. Hit enter and the resulting equation gets copied to the clipboard. Neat!

It also can act as a spell checker. For that, you type a pre-configured keyword and then the word you want to spell check. This is actually an insanely useful feature. I often find myself firing up a word processor or opening a browser tab and heading to dictionary.com just to I can check the spelling of a single word. With this feature, I can do it with just a few keystrokes rather than switching applications.

And there's even more goodness to talk about. Katapult can search for bookmarks to open, it can search for file names in your documents folder, and it can even find audio tracks if you have Amarok running. In reality, it's not so much an application launcher as it is a generic "quick-launcher" for just about anything.

The only problem I've found so far is that all these cool features are not immediately obvious. After all, that's why I was so uninspired by Katapult initially - because I thought it just ran applications. It just took a quick visit to the website and a perusal of the configuration options to figure out just how cool it is. Now that I know, I think I'm going to be using it all the time. Kudos to the Katapult guys!

It's funny how learning things about one platform can teach you about another. Despite all the differences, there are still lots of little similarities that carry over from one to another. In a way, it's kind of comforting.

Take today, for example. I was having a slow day at work, so to control the bordom, I downloaded some old episodes of Scott Hanselman's podcast, Hanselminutes. The episode in question was on the top ten Windows tools/features you didn't know you had. The first tip (#10) was that you can still use the keyboard in the middle of a drag-and-drop operation. So, for example, you can still alt+Tab, use a VirtuaWin hotkey to switch desktop, and just generall do a bunch of stuff I never thought to do with drag-and-drop. It just struck me as both very handy and so obvious I can't believe I never thought of it.

So, naturally, the first thing I did was try it out. Unsurprisingly, it worked and was very cool. And just as naturally, the second thing I did was fire up Kubuntu Edgy in VMware to see if it worked in KDE. And guess what - it does! Not that I should be surprised - there's no reason I know of why it wouldn't work in KDE. It's just that when you go back and forth between Linux and Windows, you get used to the idea that everything is always different. This was one of those "freebies" you discover every now and then that makes you feel nice.

In fact, the relative closeness of KDE to Windows is what attracted me to it in the first place. I started off with the Unices back when GNOME and KDE were in the 1.x releases and - let's face it - they both sucked. Thus I was an old-school AfterStep user for several years and then migrated to ROX and Sawfish. But while ROX was nice, and I really bought into the idea of how it worked, the user experience was just too different from Windows. After a while, going back and forth started to feel jarring. I just had to bring the two closer together. And since there's not much you can do about the interface for Windows, it was obvious that the Linux side would have to change.

I really appreciate it when KDE and other Linux desktop projects make things more Windows-like. Windows might get some things wrong, but there is also a lot that it gets right. Real respect for the user is fixing the geniune problems with the interface he's accustomed to, not making things different for the sake of being different or for some abstract design principles. I think Tog said it best in discussing the differences between Windows and Macs:

Consistency is a funny thing. The most important area of consistency is the area most people don't even think about; which is why it is the most important area. What am I talking about? Shortcut keys. Button ordering. And all those other little things users learned way-back-when, soon absorbed into habit, and never considered again. The way a lot of these work is backwards in Windows. No, let me correct that. It was backwards in Windows, until Windows hit a 90% market share. Now, it is backwards in Macintosh.

It's funny the things people fail to grasp when it comes to computers. Sure, there are always the "complicated" things that are the realm of "the IT people," but there are always some users who don't get the basic concepts. Kind of like Raymond Chen's relative who thinks everyting is Outlook. he user was complaining

My favorite example of this I wittnessed by accident. I was doing an installation of some crappy software that I own (read: was foisted upon me) and the last workstation I need to do just happened to be the same one our lead PC tech was working on. We had recently switched that location to a different Windows domain and the user was complaining that his bookmarks had disappeared. However, the tech had already checked the user's profile directory and the couple of Internet Explorer favorites he had were still there.

The problem? Terminology. When the user said his bookmarks were gone, he was really referring to the recently typed addresses in the location drop-down. It turns out he only ever visited the same handful sites, so the the "recent" locations were always the same. Since that's where all his links were, he apparently just assumed that those must be those "bookmarks" everybody's always talking about. In this day and age, you'd think that everybody would understand bookmarks by now. But you'd be wrong.

Then again, there are also those users who just don't seem to be paying attention. One day, I was walking back to my desk and saw one of the help desk techs sitting slouched over, shaking her head. When I asked what was wrong, she recounted the following call.
Tech: "Help desk. What can I do for you?"
User: "I'm having trouble printing."
Tech: "OK. What are you trying to print from?"
User: "My computer."

I think this tech is an example to us all. Or at least to me. She calmly and professionally answered the user's question. I, on the other hand, don't know if I would have been able to prevent myself from openly mocking the user. "Your computer? You're sure you don't mean your calculator or your phone?" "Oh, your computer. I'm glad you cleared that up. I mean, this is the IT help desk, so it's sometimes hard to tell if a call is going to be computer-related. Thanks for saving us that extra question." I mean, it's just too easy. You almost have to take the shot.

I've been thinking a little about HTML 5 today, thanks to a blog entry by Roger Johansson on taking the semantics out of HTML. Apparently, the HTML 5 WG mailing list as gone off into loony-land and Roger is a bit concerned that the accessible, semantic markup he and other have been promoting for years is going to fall by the wayside in order to make things easier on browser vendors. And so far, his fears are not without some justification.

I can't claim to be an expert on HTML in general or the HTML 5 development process, but from what I've read, things do seem to be getting a little...weird. For instance, the requirement that all pages served as text/html will be treated as HTML 5. Apparently the idea is that HTML 5 will be backward-compatible with all existing versions of HTML and, I would guess, XHTML 1.0. Or rather, it will have to be if they intend to keep that requirement. Otherwise they really will "break the web."

There's also this item from the HTML 5 FAQ responding to the "HTML 5 legitimates tag soup" claim. It describes the difference between requirements for conforming documents and requirements for user agents. For example, user agents are required to support the MARQUEE tag, but conforming documents cannot contain it.

My question is: Is this a good thing? At this point, I really don't know. It seems like the W3C is trying to codify the the tag soup that browsers have been forced by circumstances to support into a single, coherent standard. On the one hand, this is undoubtedly a good thing, as it will (if done properly) solve the problem of different user agents rendering things in inconsistent ways.

On the other hand, is this really solving the long-term problem? In the marquee example, I understand that the document and user agent requirements are orthogonal. But if user agents are required to support a tag, won't people feel entitled to use it? And if people aren't supposed to use it, wouldn't it be better to discourage that by deprecating it or writing it out of the spec altogether? Am I just being naive here?

What I'm getting at is that I'm not sure how (or even if) this approach is supposed to fix the generally miserable quality of markup on the web. People relying on the browser to implement things a certain way is what got us into trouble in the first place. By stating that browsers will now be required to implement MARQUEE in perpetuity, but you shouldn't use it, isn't that effectively giving people a license to use it? If the people writing HTML cared what the specs recommended, we wouldn't have MARQUEE in the first place. I can easily imagine people taking the browser rendering requirements as gospel and simply disregarding the document conformance requirements.

While I do have some sympathy for the forgiveness by default philosophy, I think we need to focus a little more on discipline. The laissez-faire attitude of the 1990's left us with a web that was held together with duct tape and bailing wire. Surely we want to do better than that. I'm not necessarily advocating the strict XHTML "validate or die" approach, but surely there must be a happy medium between that and semi-legitimizing every ill-advised vendor extension to HTML out there. Surely.

I'm calling last week's weight 192.6. That puts me down another pound from last week for a grand total of 40.6 pounds to date. Only 12.6 more to hit my goal. Although I may change that goal and just go for "technically no longer overweight."

It's strange how your weight can fluctuate from day to do. When I weighed myself on Thursday morning, the scale read 194.6, which was up a pound from the previous week. When I tried again Thursday night, it was down to 191.0. On Friday, I got 192.0 and later 192.6.

I guess I shouldn't be surprised. You can easily gain or lose a pound or two due to (de)hydration, not having gone to the bathroom, having a full stomach, and so forth. I suppose the lesson is simply to average out the readings and not put too much stock in any particular number.

Yesterday, I was telling you about the ridiculous install procedure for CRAPS. Today I'd like to continue the discussion.

As you remember from last time, the recommended procedure for getting the MS Access databases CRAPS uses on your network is to just install all the software directly onto the C: drive of your file server. If you're in IT in any capacity, and are at least marginally competent, I shouldn't have to explain why this is really stupid.

The customization and configuration process is similarly disjointed. Some of this you do in a crowded graphical configuration dialog. Some of it you do by hand-editing INI files. I'd say it's about a 60/40 split. And, as an added bonus, for a few settings you actually have to hand-edit rows in one of the database tables. Unless you don't have Access 2000. Then you just live with the defaults.

From the care and attention they put into the installation and configuration process, it should go without saying that the CRAPS developers take security very seriously. Thus they decided to use "binary files (also known as flat files)" to store certain data on field units. After all, "Binary files use a format that is specific to the application that creates them," which means that other programs are "unable to interpret binary files that they did not create. This makes [CRAPS] data secure, as only [CRAPS] can interpret and use its binary files." And if you don't believe me, that comes directly from the CRAPS administration manual. Seriously. The only thing I changed was the name of the system. The manual also claims speed and smaller file size as benefits, despite the fact that field units are single-user laptops with Pentium IV processors and 80GB hard drives.

It's always a bad sign when the developers feel the need to justify their choice of data format in the user manual. So it probably comes as no surprise that when you actually look at one of these "binary files," it contains mostly serialized text data. It's definitely not encrypted and most of it isn't even really binary. With a little intelligence, it's not even too hard to figure out the format just by looking at it. It sure is a good thing that opening sequential files in Vim is such a well-guarded secret, or else the security benefits might not seem so compelling.

And even worse, some of the "binary files" referred to in the manual are just standard formats. For example, guess what the "binary" import and export files are? They're ZIP archives! With a different file extension!

The really sad part is that, for all its fauilts, CRAPS actually works fairly well. Yes, it's slow (despite the speed benefits of binary files), the configuration is tedious, the user interface is arcane, and the whole system has a feel of being held together with duct tape and bailing wire, but it does work. It truly is worse than failure.

Today I start a new series: Tales of IT. In this series, I will be discussing some of the more humorous things I come across in my work in the IT world. Some are funny ha-ha, some are funny-weird, and some are just funny-sad.

Let me start by telling you a little about what I do. I'm a "Systems Analyst" for a local governement agency. In my organization, that means that I do software development (that's my favorite part), analysis, some server administration, some help desk stuff - whatever comes up. So at this point, I can basically do some of everything.

Now let me tell you about the organization I work for. Being the government, it should go without saying that it's extremely disfunctional. One of the more annoying disfunctions of the IT department is what I call the "you touch it, you own it" theory of tech support. By that, I mean that, for any software system (especially big, complicated, or expensive ones), there is an analyst who "owns" that system. Ownership is determined on a first-come, first-served basis, so if you're the first person to touch a new system, you will own that system until you quit, retire, or die. The natural result of this is that nobody will ever volunteer for anything.

Now, you may be thinking that having a "local expert" on every system we use is a good idea. And you'd be right. It is a good idea to have somebody with a degree of in-depth knowledge around. That isn't the issue.

The problem is simply that the whole situation is completely demoralizing. When you own a system, you become the goto guy for all problems related to that system. That includes everything from the hardish analysis work of determining the proper system configuration all the way down to the grunt work of clicking next through client installations on a couple dozen workstations. If somebody calls the help desk with a problem related to your system, it gets passed straight back to you - the help desk doesn't even try to resolve it or even get more information.

This brings me to a system I own, the Crazy and Ridiculously Attrocious Police System, or CRAPS for short. CRAPS is the system used by the police force to write tickets, take accident reports, and so forth. I got stuck with it because it runs on the terminals in the police cars, and since I already owned the 911 dispatching software on those terminals, and my boss apparently didn't think I had enough pain in my life, I was the obvious choice.

I've got plenty of stories about CRAPS, but today I'll just tell you about the system itself. For starters, CRAPS has a "client-server" design. By that, they mean the system stores data in Access 2000 databases that sit on a file "server" and that the "clients" get pointed to the mapped drive or UNC path to those databases. Sort of.

You see, the CRAPS manuals and installation program seem a little confused about just what a server is. The installer has options to perform a "server install" and a "client and server install." What this choice really comes down to is "install just the .MDB files on this machine or install the .MDB files and the program files on this machine."

The important thing to note here is that both options are for this machine. That means that if you want to do what we did and put just the databases on your file server, the installed expects you to log in on the file server to run the installation. You can't just run from another machine and point the installer to the network location. I know, I tried. It fouls up things in the next stages of installation. It turns out that there's a reason the manual "strongly recommends" that you keep the default installation path of C:\CRAPS - things tend to get messed up if you don't.

Part of the reason things get messed up is that a basic CRAPS install is a 2-step process. First, you install the base system. Second, you install an add-on package with all the databases you need to actually get things done. The databases from both packages need to be on the server, but there is no "server install" option for the add-on databases. In fact, you can't even change the installation path. They get installed to the same path as your base system. Unless you changed the default path. In that case, some of the files get installed to the right place and some of them disapear into the ether, never to be heard from again. In fact, I've found that it's more reliable to just install everything on a workstation and then copy manually copy the data directory to the file server. It really shouldn't be, but it is.

At this point, CRAPS is installed on the file server, but is not yet functional. We'll explore how to make it work tomorrow.

The thing about software development is that there's an inherent conflict in it. In order to get the functionality we've come to expect these days, a program has to be fairly complicated. On the other hand, in order to keep an intellectual handle on the system, developers need to make it as simple as possible. Otherwise, you're liable to lose your grip on the system and end up staring a a screen full of code that is obviously correct, yet is nonetheless not working as expected.

I had one of those moments today. I was trying to add some caching to LnBlog's plugin system. I started off by adding some caching code to the recent entries plugin (look to the left - it's the 5th panel down in the sidebar). But then I thought better of it and decided I'd save myself some work by sharing the code through the base Plugin class. That way, all the plugins could use it without having to copy it over and over again. Perfect! However, when I tested it out, I noticed that section header for the calendar plugin had mysteriously disappeared. And yet, I hadn't even touched the calendar plugin. What was going on?

And so, my search began. The process went something like this.

Step 1: Check the new code

The first step is always to check the new code. If something changed and then something broke, then whatever changed is the most obvious culprit. In this case, the new code included a new sidebar output event handler for the recent entries plugin and switching back to the old handler eliminated the bug. However, I didn't see anything looked obviously wrong with the new code. To make matters even stranger, I discovered that I could eliminate the bug by using an event handler with the same signature as the old version, but which merely called the new one in its body. Say what?

Step 2: Check the calling code

The next place to look is one step back in the code. In this case, I looked at the event registry. When the sidebar output event is raised, the event registry handles calling the event handlers. This was also suspect, because I had recenty added data parameters to the event handlers. However, there didn't appear to be anything wrong here either.

Step 3: Check the affected code

Normally, this would come sooner, but my next step was to look at the calendar plugin. Since I hadn't actually changed anyting in this plugin, my assumption was that the problem must be an interaction with some of the new code. Since that wasn't panning out, it was time to try something else.

Step 4: Pulling it all together

As I was looking at the calendar code, it all became clear. The sidebar output event handler takes an optional parameter which can be set to turn off the display of the section heading and container DIV element (for AJAX calls). This parameter is called $nodiv and the default value is false. The eevent register now takes a data parameter. Somehow, a data parameter is getting passed on to the calendar plugin. So the problem was that data was inadvertently getting passed on to the calendar.

I went back to the event register code and looked at the data parameter code. The same parameter gets passed to every event handler. Back over to the new recent entries plugin. It takes an optional parameter, passed by reference, with a defalut value of false. However, when the handler got the value[bfalse[/b], it reassigned that parameter to an object for the current blog.

And there it was. I was assigning a value an optional reference parameter. (Which I only had to do because PHP doesn't do function overloading.) That change was then propogated to other event handlers. Since the calendar event handler depended on getting false as its parameter value, it didn't function as expected.

On the up side, it was a nice, easy, one-line fix. Isn't that always the way? Tracking down the bug always seems to take ten times as long as fixing it.

As you may have noticed, I've severely stepped up my blog posting rate lately. I'm trying get into the habit of posting on a consistent schedule. I'm doing this in an effort to improve my communication skills and prevent brain atrophy.

Writing is an important skill to have, especially for a programmer. There are two reasons for this. First, it makes you look good by comparison, as many programmers are half-literate code junkies who can just barely put a coherent sentence toegether. Second, and more importantly, a lot of the communciation we engage in is over the internet, i.e. written. We thrive on mailing lists, comment boards, e-mail, IRC, and the like. This is especially true in the FOSS world, where you may easily find yourself working closely with someone you will never see face to face.

Given that, it is clearly important that we be able to express our thoughts clearly, succinctly, and without putting the reader to sleep. You develop that ability the same way you learn anything else: practice. And for me, the most convenient way to practice is to blog.

In addition to becoming a better writer, I'm hoping that using a blog as my practice medium will also make me a faster writer. You see, I'm a painfully slow writer. I'm not at all good at coming up with witty, insightful commentary off the top of my head. Instead, I overthink what I'm trying to say, rewrite the same paragraph a dozen times, and eventually spend so much time on a relatively small amount of text that I feel like I've wasted a lot of time and have to rush to get it done. By setting myself a regular schedule of 1 post per business day, I'm hoping that my brain will adapt and get a little quicker on the draw.

And last but not least, it's just nice to have place to hash out whatever I might be thinking along a computing vein. Writing your thoughts down forces you to process them a bit more, to shape them into a point that you can articulate. When it comes to technical topics, particularly related to software development, I don't have a lot of people around to discuss things with, so writing is the most readily available outlet.

I guess we'll see how that all turns out. With any luck, you'll notice this blog getting progressively better in the months to come. If not, then maybe I'll just have to accept that I'm not as smart as I always thought I was. But let's hope it doesn't come to that!