LinLog

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.