O'SToPotD: code smell

O'Shaughnessy's Turn of Phrase o' the Day is "Code Smell":

A code smell is a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem.

Highly experienced and knowledgeable developers have a "feel" for good design. Having reached a state of "Unconscious Competence," where they routinely practice good design without thinking about it too much, they find that they can look at a design or the code and immediately get a "feel" for its quality, without getting bogged down in extensive "logically detailed arguments".

Excepts taken from Cunningham & Cunningham's Extreme Programming Roadmap

Here's an example usage from Smashing Magazine:

Nested tables are code smell that a website is stuck in table hell. The number of lines of code is endless, and the complexity is overwhelming. Tables are far from clean code and don’t bring anything semantic to the content unless you’re dealing with actual tabular data.

Now go forth, spread the good word, and be wary of the smell.

Quick and easy FreeBSD DST updates

So congress made it interesting for computer admins everywhere this year by extending daylight savings time. Life's going to be easier for us if we update the timezone files on our systems before March 11, 2007, and today I did a little digging to find out how to make FreeBSD systems compliant with the new rules. It's pretty easy if you keep /usr/src current. I've read that up-to-date FreeBSD 5.5 and 6.2 systems should have the right data, but I don't know if the zoneinfo files were backported to previous releases. Here's whatcha wanna do:

    # check if you need to update
    zdump -v /etc/localtime | grep 2007 |head -2

If you see April 1, 2007, you need to update your timezone and probably your /usr/share/zoneinfo files:

    (cd /usr/src/share/zoneinfo; make install)
    tzsetup /usr/share/zoneinfo/PST8PDT

Then doublecheck that you got it all right with the zdump command again. If you don't know the path of the right zoneinfo file, you can just run tzsetup without any args and it'll walk you through a little menu system to figure it out. That gets real tedious if you have a lot of systems, though, so I took the time to find the right file.

Apparently you can also install the misc/zoneinfo port, but you'll still have to run tzsetup when you're done. If you have the right data in /usr/src, I don't see any value in using the port, and it just adds a little unnecessary mess to your ports db if you don't need it.

FreeBSD + PHP 5.2 + Apache seg faults

I recently upgraded my FreeBSD php5 port to PHP 5.2.0. After upgrading the Apache module and all the extensions, something was segfaulting whenever I would try to load Horde. I tried everything I could think of and dug around in the FreeBSD mailing lists for solutions. The problem seemed to lie with the ordering of the PHP exentions in /usr/local/etc/php/extensions.ini. According to this page at pingle.org and some messages on freebsd-ports, the key is to load mysql.so, then imap.so, then sockets.so. Tried that and every other suggestion I could find but nothing helped.

Finally, I tried making my compiler optimizations less aggressive. In /etc/make.conf, I normally have this:

CFLAGS=-O2 -pipe -funroll-loops -march=pentium4

but I just reduced it to "CFLAGS=-O" and recompiled php5 along with all my php5-* ports, then restarted Apache. Finally Horde loaded!

(Platform notes: FreeBSD 5.x, but reports indicate this is also a problem at least on 6.x; Apache 2.2.x; PHP 5.1.6 was working fine with the aggressive compiler optimizations; host has Pentium4 XEONs.)

Hacking Plesk 8 for FreeBSD 6

I was recently in a situation where I had to upgrade Plesk, commercial domain-hosting software that lets you manage web, email, and database services through a nice web control panel. It's pretty convenient software and it seems to work well. I needed to migrate the service off an old RedHat box that was difficult to maintain, and I wanted the new system on FreeBSD. The latest Plesk release, 8.0, is only supported on FreeBSD up to version 6.0, but the most current release at the time was 6.1. I like to track RELENG_6 and I didn't want to downgrade the box, so I tried faking out the Plesk installer.

To do that, I changed /usr/src/sys/conf/newvers.sh. REVISION="6.1" became REVISION="6.0" and BRANCH="STABLE" became BRANCH="STABLE61". Modifying the BRANCH label wasn't strictly necessary, but it seemed wise to identify the true release in the kernel version data. After that, I simply rebuilt and reinstalled the kernel (see /usr/src/Makefile if you're unfamiliar with the process), rebooted, and the Plesk installer worked without a hitch.

I've been told by SWSoft support that Plesk 8.1 will support newer releases of FreeBSD 6, but I couldn't wait for that and I wasn't about to build a new box on FreeBSD 4 or 5. (They're not bad, but I prefer 6 now.) I haven't had any troubles running Plesk 8 on that system, and as one who's more comfortable with FreeBSD than RedHat, I've been much happier managing this newer box.