software

Do you have a Mac still running Tiger (Mac OS 10.4)? And did you recently decide to install a PEAR component for use with some PHP? And lastly, did it fail with some cryptic HTTP error "410 Gone" that you had very little luck finding with Google? I did.

The solution is a bunch of steps backward and then forward again. Unfortunately, it's not very clear to the perhaps large number of Mac users who did not keep their PEAR libraries up to date all along on Tiger. But the answer is here, at the moment (it will scroll off when more news is added): http://pear.php.net/

After posting Why I don't like WebDAV, part 1 I got involved in a bit of email discussion with some people who are much more expert than I regarding the protocol (Kevin, Mike, Julian, Tim). I appreciate they included me, and I now know a lot more about WebDAV than I did before.

The protocol itself doesn't really suck. Rather, it's the implementations and the purposes for which it has been used, it seems. It's a bit odd in that it's a lower-level protocol for a high-level purpose. Use it for the wrong purpose, and it's like using the wrong tool.

Yesterday and today I spent a lot of time using WebDAV updating one web site, and creating another, both at hosts which use that protocol for accessing file directories on hosted sites. It has taken longer than it should have, possibly caused my Mac OS X 10.4.10 desktop to crash, and ultimately forced me to use both the shell and FTP to get permissions set right and the right files in the right places. It shouldn't be this hard. Part of the blame may lay with Mac OS's native implementation of WebDAV, but I've not seen any implementation that is better on the whole.

Arto is on a tear!

He's working on some Top Secret (for the next X minutes, that is) really cool code for Drupal that is blowing those in the know away.

Check his blog soon to catch up on what this coding maniac has created now.

A Drupal colleague of mine, Steven Wittens just whipped together a new web application using the <canvas> tag, called ComicJuice. The ability to draw on a web page canvas is just one step closer to web applications that can do everything previous generation desktop applications could do.

How often do you visit a web site looking for information about some product or service -- even open-source software -- and encounter a Bad FAQ like those described below? Don't become part of the problem in your own efforts.

From the forward to the Subversion manual:

A bad Frequently Asked Questions (FAQ) sheet is one that is composed not of the questions people actually asked, but of the questions the FAQ's author wished people had asked. Perhaps you've seen the type before:

Q: How can I use Glorbosoft XYZ to maximize team productivity?

For the recovering perfectionists of the world, and I count myself among them, this bit of advice seems useful not just in software development, but in many aspects of life.

"It is important not to let the perfect become the enemy of the good, even when you can agree on what perfect is. Doubly so when you can't. As unpleasant as it is to be trapped by past mistakes, you can't make any progress by being afraid of your own shadow during design."

--Greg Hudson

The Parallels Desktop looks like it might be just what the doctor ordered for users who want to get away from the many annoyances of Microsoft Windows, or for the Mac zealots who just need to run the one or two Windows-only applications. It's also possibly the best thing since sliced bread for software developers who want to develop in the Mac OS environment, but need to test on other Intel platforms. Parallels doesn't just provide a way to run Windows. One can virtualize FreeBSD, Linux, Solaris and even OS/2.

I had thought about titling this post “Apple's Dirty Little Secret” but decided that was a bit strong, and it's really not a secret to anyone who thinks about it.

It may seem counterintuitive to many programmers that it is better to have poorly implemented code with a solid API design than to have well-implemented code with poor API design.

Do not doubt your code will live on, be reused in other projects, and take on a life of its own. If the API design is good, the code itself can always be refactored to improve its performance. Conversely, if the API design is poor, changes to it require cascading changes to all of the code using it.