PHP

Dries has been commenting recently, both on his blog and elsewhere, about one of the chief advantages of using open source: All developers/users are on equal footing. If you try to learn a proprietary app or framework, you know what the main developer feels like deigning to let you know. Anything else is either a mystery or, in some cases, illegal for you to find out (if there's any encryption or copy-prevention involved). You can never be as good an expert as the author, because the author has access to the Holy Book (code) and you don't. With an open source project, everyone gets the same access to the code. The only thing stopping you from being the best expert on the planet is your own skills and time.

He's very right about why you should choose to use an open source project. But what about why you should start one, or release your own code open source? As a developer, that's a far more interesting question for me.

I am a regular reader of TheDailyWTF. Aside from being thoroughly entertaining, it's a great way to learn what not to do by example. Sometimes, though, they have a really insightful article, like The Great Pyramid of Agile. It's spot-on.

Nick Lewis has set off a bit of a firestorm with his latest blog, "Drupal is Part of the Problem". In short, his argument is the same chicken-and-egg that the PHP dev team keeps saying: Hosts won't move to PHP 5 until the applications are there, so the big applications need to lead. In a sense he's right; web hosts are by necessity cautious and conservative. At the same time, though, developers can't take the whole blame.

Over on the Planet PHP site, another author has brought up the monthly PHP 4/PHP 5 rant again with regards to why the major open source packages (he picks on Drupal and Wordpress in particular) are still developing for PHP 4. It's like clockwork how often the question comes up. The answer, as always, is dead-simple. I'd love to use PHP 5's features, but can't. Check out the latest PHP usage stats, published on the same planet site, to see why. (Hint: See the 3th chart.) Until that changes, developers can't drop PHP 4 support.

My copy of Pro Drupal Development arrived in the mail the other day. So far it's very programmer-targeted, but good. I need more time to just sit down and read it. :-)

I did notice one thing that caught my eye, though. In the Acknowledgments, the authors thank

...the members of the #drupal internet relay chat channel, who put up with the constant questioning of how things worked, why things were written a certain way, or whether or not a bit of code was brilliant or made no sense at all.... Among them are... Larry Crell...

Over on the Planet, someone posted a link to a budding Drupal user who was having the usual first-time-user troubles. "I want to do X, Y, Z, but I can't figure out how and no one will tell me, help!" Been there, done that, I suppose. But how can that be if there's so much Drupal documentation? Simple. The questions most people ask are the hardest to answer, because there isn't just one kind of documentation.

When is Unicode not Unicode? When it's UTF-16 instead of UTF-8. Both are properly Unicode character sets, but for reasons that escape me they are not fully compatible. In today's installment of "Fix Microsoft's bugs", we'll look at how to deal with that little problem.

One of the most common mistakes I see people make when talking about web architecture is with regards to MVC. Generally it comes down to a statement such as this:

It's a web app, so we have to use MVC. That way we separate the logic and presentation, which means keeping PHP out of our display layer. All the important projects do it that way.

Of course, such a statement is false. It demonstrates a lack of understanding about MVC, about web applications, about "important projects", and about software architecture in general. Let's try to clarify, with a little help from Wikipedia.

By far the most common idiom when using SQL from a web application (PHP or otherwise) is simply listing records. The standard logic looks something like this (give or take real templating):

That's all well and good, but in practice can be quite limiting. Why? Because you can't then group records, that is, display not one but several tables, one for each color. SQL, of course, offers a GROUP BY clause. That doesn't do what we want, however. GROUP BY is an aggregate clause, and is used for creating totals and summaries of records. We want to cluster records by a field that is not the ordering field, or a value that is calculated off of the record itself.

I've generally used two different methods for PHP-side grouping, one of them much cleaner and more flexible at the cost of a little performance.

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.