Most PHP applications do fundamentally the same thing: Shuffle data from an SQL database to a web page and back again. The details vary with the application, but in general that's what most web apps do. That very quickly runs into the bane of most PHP developers' lives: SQL syntax.

It's not SQL syntax itself that is bad per se. The problem is that it is a string-serialized format, which means you have to take your nice clean data structures and serialize them out into a string that has no semantic meaning to your PHP application. That's boring, dull, and introduces all sorts of places to totally mess up your application with a typo, and that's without even touching on issues of security. And then there are the issues with SQL syntax itself, in particular the way in which INSERT and UPDATE statements, which seem like they should be similar, have no similarity whatsoever. That makes "replace" operations (insert if new or update if not) very tedious to write, particularly if you have a lot of fields.

Fortunately, with a little ingenuity and help from PHP's array handling, we can give ourselves a common syntax for INSERT and UPDATE operations that maintains semantic meaning, and then get DELETE statements free of charge. Let's see how.

So it seems Ubuntu, a distribution I have grown to like more and more of late (especially every time something breaks in Debian Sid), has decided that init has got to go. Their answer? Not any of the various attempts to replace it in the past, but once again start from scratch with something called Upstart. While I agree that init is one of the many parts of typical GNU/Linux system that desperately needs to grow out of the 1970s, I'm not sure that Upstart is the right way to do it.

As both of my avid readers have likely noticed, this blog has not been particularly active of late. That is to say, today is the one year anniversary of the last time it was actually used. :-) So what do I do to celebrate? Rebuild the whole thing from scratch, of course!

Some people complain about how GNU/Linux isn't desktop-ready. It's too hard to use, the applications aren't there, it does things in silly and quirky ways... We've all heard the list. And some of us persevere anyway.

Recently, though, I've been working on-site with a client for a few weeks on a PHP project. The web app we are building is on a remote GNU/Linux server. Our desktops are all Windows XP SP2, of course. Because I need to edit the files locally but test them remotely, I need a fair bit of network transparency. Of course, Windows XP provides none unless everything is using SMB, which our production web server does not (naturally). So what setup did I have to cobble together?

In an earlier post, I mentioned some research I'd been doing with regards to Linux-based server software. To be more specific, I was investigating shared web hosting control panels. Most any web hosting service you find offers a web-based control panel. Generally such a system allows each user to manage their domain information, files, mail accounts, FTP accounts, and other such common features, and allows the admin to manage different user and reseller accounts. Some users get access to run web scripts, some don't, some have more disk space than others, etc. Some require specific underlying server software (a specific Apache version, postfix vs. qmail for email, etc.), others support a variety of alternatives.

As various associates and friends of mine know, my typical Linux distribution of choice is Debian. Once upon a time, the main thing that differentiated Debian from other distributions was a nifty suite of tools called APT, or Advanced Packaging Tool. While users of "those other distributions" wallowed in RPM hell, having to track down package dependencies manually, Debian users relied on a vast online archive of packages all parsed by the apt system. By using the apt-get tool Debian users could install one package, and all required dependencies would be installed and configured automagically. No scouring the 'Net for a specific version of an RPM. Coolness!

Lately I've been reviewing Linux-based server software for a client. I have setup a dedicated test server that I can break, and to avoid rolling my office chair around the room to get anything done (fun as that may be), I've been accessing it almost exclusively via ssh from my desktop.

Generally when I need to download a new program to test, I just wget it on the server and then do whatever it is I'm going to do. That is, until one program didn't offer an actual URL. No, to use their software, you had to use their super-cool download redirect method. Boy I hate those, even apart from the problem of not being able to just wget a file. So I had to download the file on my main desktop and then shuffle it over. Minor annoyance, and computers are supposed to be helpful, not annoying.

In recent weeks I've been looking into a few open source Content Management System (CMS) projects. My initial interest was not, actually, in using a CMS but in finding one to dissect in order to get a better feel for building large, plugin-based application frameworks. There is a severe lack of documentation on plugin-based frameworks in general, so in true open source fashion the next step for me was "Use the Source, Luke!"

I only looked at a few, really, before I stumbled across Drupal. (To be fair, it had been recommended to me by a friend and fellow blogger.)

At the end of my last entry, I hinted at some network restructuring I'd done in the fallout of Yahoo deciding to take its network and go home. To be more specific I was just putting the last finishing touches on what was already (I think) a cool use (or abuse, I'm sure some would claim) of the DNS network. While my setup has evolved a bit over time, I am going to explain its current, theoretically final incarnation in the hopes that it proves useful to others who wish to go nuts with DNS in order to run fancy servers on a dynamic IP address.

Like most people on the Net, I make some use of Yahoo! services. It's not easy to avoid it. Hundreds of thousands of people have a Yahoo! email address, just as many use Yahoo! Messenger, and Yahoo! Groups is "the new usenet" for many subjects. That's not even counting Yahoo!'s various other branding efforts.

Before I continue, I'm going to drop the stupid ! in the company name. Yes it should be there for accuracy, but good grief can we be a little less self-important? Thanks. Anyway...

The advantage of one company offering all of those services is that you have only a single sign-on to worry about. One name, one password, one bookmark, and you have all of your services at your fingertips. That's great... right up until you get butterfingers. It's also a single point of failure; one problem can bring down your entire PIM network.