LinLog

My current project at work is to integrate a web application that runs one aspect of our site with the rest of the site. Part of this involves converting the database code from a custom DB abstraction library to use the standard PHP Data Objects (PDO) library that comes with PHP 5.1. I had never used it before, but it turns out PDO isn't a bad library. It has an object-oriented API, supports multiple databases, "prepared" (i.e. DBMS parametrized) queries, transactions, and so forth. Pretty much the basic features you need in a database abstraction layer. The only problem is that the error handling API is somewhere between "weird" and "completely frickin' insane."

You see, PDO has "configurable" error handling. That is, when a method reaches an error condition, it will either return an error code or throw an exception. Which one it does is determined by an attribute setting on the PDO connection object. (Technically, it may actually return the error code and throw an exception, but the return value is irrelevant once an exception is thrown, so it doesn't really make any difference.)

Let me repeat that, in case you missed it: PDO will either throw an exception or return an error code, depending on a setting of the PDO connection object. So it's possible to change one single constant and break error handling for an entire script.

Upon learning this, my initial reaction was: "That's the stupidest thing I've ever heard in my life!" I mean, honestly, who ever heard of configurable error handling? As if programmers don't have enough to worry about with database code, now we have to pick an error handling mode as well?!? And the worst part is that, when you read the error handling documentation, the default mode not only doesn't throw an exception, it doesn't even print a warning. It just leaves you to see the bad return value and manually inspect the error code on the object. You have to manually set it to turn on warning messages. Why?!? Isn't that why we have the error_reporting variable in php.ini? What the heck were they thinking?!?

What really kills me is that exceptions are optional, but object-oriented programming is mandatory. Unlike, say, the MySQL extension, PDO does not have a procedural version of the API, just the object-oriented one. And yet exceptions, which I think I can safely say are the object-oriented way of doing error handling, aren't even used by default. Shouldn't that be the only way of dealing with errors? Why is it better to make them optional? What's the rationale behind that?

So far, the only rationale I can think of is that the PHP community has what seems to be a disproportionate number of morons in it. That may be a little harsh, but it seems to me like there are a lot of third-rate PHP programmers and that the people who run the PHP project tend to go a little too far to cater to them. I can only assume that somebody thought that exceptions might be too hard for some PHP users, so they figured it would be better to use error codes by default. Kind of like how they figured securing your server was too hard, so they added the fake band-aid of safe_mode. Or how they figured a simple function call or array look-up was too hard, so the invented register_globals. Or how they figured that cleaning form input was too hard, so the invented "magic quotes."

PHP isn't a bad language, and I do enjoy working with it, but it has gone through a long list of really bone-headed design decisions. In some ways, it seems like it's succeeded in spite of itself. I guess this is really just evolution in action. Take a simple template engine, let it mutate into a full-blown programming language, and this is what you get: a platypus. Lots of endearing features and lots of brain-dead features, but it's still alive and still evolving.

Well, it's only been a little a couple of weeks, but I'm already spoiled. You see, at my new job I have dual monitors. And you know what? I don't think I'll ever be able to go back. I'm already trying to figure out how I can talk Sarah into letting me buy another 19-inch widescreen LCD.

The benefit of dual monitors is exactly the same as that of having a bigger single monitor - you can see more things at one time. This leads to greater productivity, as Jeff Atwood has been saying for years. And it's not just opinion and anecdote - studies have shown that increased monitor space can improve productivity by 9 to 50 percent, depending on the task.

For programmers, having an extra monitor is very handy. You can have your IDE full-screen on one monitor and use the other one for testing, documentation, supporting files and programs, and so forth. No more flipping between windows. It sounds like a small thing, but once you've tried it, it really does make a difference.

Of course, setting up dual monitors is naturally trickier than a single monitor. In my case, I'm working with an Nvidia card under Kubuntu 7.04. The setup wasn't too difficult, but there were a few hitches. I simply had to install the nvidia packages from the APT repositories and run the installer from Nvidia's website, which built the kernel modules. However, for some reason the kernel module doesn't work the when it is loaded after boot, but it's fine if you reload it. That makes no sense to me. Plus, it seems to have broken guidance-power-manager. Annoying, but not a big deal since this is a desktop. On the up side, the Nvidia configuration tool works well and is easy to use.

I started my new job yesterday. After a whopping 4 days of work, I'm actually feeling pretty good about it. I've been leaving the office feeling energized and enthused about my work - or at least not run-down (though the 1.5 hour commute fixes that). This is quite a change from my last job.

On Tuesday I started work on my first project. Of course, I really only got in a couple of hours of real work. Most of the day I spent with another programmer going over the database schema, application architecture, and all that good stuff. You know, the things you need to know to be able to sensibly make an addition to a substantial piece of software. I managed to get a bunch of work done Wednesday and today, though. It's really not that big of a project, it's just that I'm not used to the codebase and it's a somewhat large and complicated.

So far, this job is a lot more fast-paced than my last one. In fact, I've already learned a few things.

1. In PHP library files, you don't need to close the <?php ?> tag. You can just have the opening <?php and not have to worry about stray space at the end of the file. For some reason, I just never knew that.
2. Writing PHP will error reporting turned off really sucks. Well, technically it's not completely off. The errors are logged - to a 200MB file on another server. Which still sucks.
3. MySQL throws really weird errors when you try to declare a foreign key and give it the wrong size integer for the key column.
4. I had never used ti before, but the jQuery JavaScript library is very cool. For example, it allows you to select DOM nodes with XPath expressions. How cool is that? Though on the down side, the syntax is a little...weird.

I'm sure the learning is just beginning. Methinks this job will make for much better technical blog-fodder than the last one.

It's official: as of about 5 and a half hours ago, I am no longer a public servant. My job search is over and I've had my last day at my unnamed local government employer.

I'll be starting my new job on Monday. I was hoping to have a week or two off between jobs, but their (semi-official?) lead developer is leaving at the end of the month and they wanted me to have some time to work with him and get the hang of things before that. On the up side, this also means I have less time to worry and stew, so it's probably not such a bad thing.

The new job is as a web developer for a fairly large and well-known video site, which will remain nameless. I'll be working on a team with 3 other developers doing all the front and back-end coding and design for the site. I figure that that, combined with the large volume of hits the site gets, should be a pretty good learning experience. Certainly much better than my civil service job, where everything was a one-man project with maybe a handful of users if you're lucky. Plus the new job is a LAMP shop, so I'll actually get to do UNIXy stuff at work for a change, which is kind of neat.

I should probably note that, since my professional experience is 100% Windows-based, I got this job based largely on my open-source hobby projects. That and the rest of my resume, a code sample, a good score on their truly evil knowledge-based written test, and a very long interview. But the point is, let it not be said that working on free software isn't useful! I have now proven to my wife and mother-in-law that all that time I spent coding for fun was not wasted! Victory!!!

On the down side, the new job is about 95 miles from my house. That's an hour and a half drive one way. It's also about $18 a day in gas at current prices. And we can't move right away. And I'm not getting a raise (at least not to start), so after fuel costs, I'm actually taking a net pay cut.

So all is not sweetness and light with the new job. But if nothing else, at least this is a step forward career-wise. It will be a good opportunity to grow as a software developer and to get some higher-end experience. It's also kind of a scary change, after being in the same place for the last 6 years. But it'll be good for me. I need to move on to bigger and better things, and this is a good first step in that direction.

It's time for another tale of IT pain. You remember CRAPS, the pathological police system we're required to use? Well, it struck again.

Today I had to travel to a nearby police agency to assist them with their CRAPS installation. They were having problems with the data transfer between the field units and the office. This is normally accomplished via a removable USB drive. In order to ease this procedure, CRAPS includes a feature to automate the copying of data files to and from the USB drive. Basically, the user clicks a button and the data files get compressed and moved in the appropriate direction.

The problem with this feature is that it's not very friendly from a configuration point of view. You see, CRAPS doesn't actually know anything about USB drives. It just knows about paths, and they're configured statically. So you actually have to tell the software, "use drive F: for the data transfer."

What's worse, CRAPS isn't even very smart about handling paths. As you probably know, when Windows detects a USB mass storage device, it assigns it the next available drive letter, so you can't depend on the same devince getting the same letter every time. However, CRAPS requires that a CRAPS administrator configure the drive letter ahead of time and it cannot be changed by a regular user. So the user ends up with, for example, a drive with multiple partitions, he can't use it until an administrator can reconfigure his system. Which sucks.

The first problem today was that CRAPS can't even join paths properly. We were having problems with the data transfer feature mysteriously failing on a couple of workstations. The USB drive path was correctly set to E: in CRAPS. However, just on a lark, because I know how cranky CRAPS can be, I tried chaning it to E:\. And you know what? It worked. *THWACK* (That's the sound of me smacking myself in the head.)

My second problem was partly Windows, partly the fact that I didn't set up this other agency's network. You see, on one workstation, the USB drive was being mapped to F:, but the primary network share was also being mapped to F:. The result? The network share clobbers the USB device and you can't access the USB drive until the network share is disconnected.

This is a fairly well known problem. As I understand it, the cause is that drive mapping is done on a per-user basis, and while network shares are mapped by the user, USB drives are mapped by a system account. There are a number of possible fixes, of course, but they all kind of suck - especially if you don't have any significant ownership over the system you're working on.

Nothing is ever as easy as it should be. Which is why "IT land" sucks.