So first I thought it was odd that Palantir's private IRC bot has a factoid for me that reads "Great on challah!" Then I noticed this:

http://drupal.org/profile/interest/Stalking%20Crell

I wonder if I should be worried...

So we're a month away from DrupalCon DC 2009, and although the official schedule has not been published it seems likely from the preliminary schedule that my Objectifying Drupal session will be accepted. The basic idea is to help Drupal's mainly procedural army of developers get up to speed on object-oriented development, which has been gaining popularity in contrib (most notably the Views module) and will be in many parts of Drupal 7.

Of course, given how large an army of developers we have there is no one level of existing expertise I can target. There are entire multi-course college programs on OOP design, and I have an hour. :-) So, how about some preliminary feedback? What do you want to see in a one hour session on object-oriented code in Drupal?

As Drupal gets bigger and bigger in the marketplace, it is moving into areas where system administrators still hold sway. Dedicated servers or server farms have a different set of needs than a shared host when it comes to monitoring and performance.

That's not even Drupal specific. For any high-end web app, it's useful to be able to interact with it for administrative purposes through standard system tools. On Windows, that's the Windows Administrative Tools or IIS. On LAMP, that could be a unified web app like webmin or a KDE control panel plugin or a Gnome applet. Getting a web app into certain organizations requires offering existing sysadmins a way to integrate it into their existing management workflow.

But what pieces of the app do sysadmins want in their existing admin tools? Calling all sysadmins, what do you want from us? :-)

Drupal has a very aggressive caching system. While site admins can disable the page cache or CSS compressor very easily, many other caches are not so easy to disable. Think of the menu system, or the theme system, or filter content, or any number of other things that get cached.

In a production site, that's exactly what you want. No Drupal site would be able to handle even moderate traffic if every single registry cache had to be rebuild on every page load. For development, however, it can frequently be a huge pain to have to clear the cache every time you're trying to track down a bug in a menu definition or a CCK field definition.

There's an admin button to clear the cache on the Performance page, but it's not all that useful for intensive debugging. The Devel module (which you are using, right?) offers a handy "clear cache" button, but that doesn't always work if you're, say, debugging a form submission. Fortunately, Drupal makes it easy for us to disable those caches, too, although not through the admin.

Back when Drupal 7 development opened, our database layer was in a sorry state. Based on PHP 3-era concepts it offered few features, but more importantly no one actually cared about it. On rare occasions we had a PostgreSQL maintainer for the PostgreSQL driver, but they had a tendency to disappear into the Interweb, never to be heard from again.

Boy what a difference a few months make! Not only is the new database layer moving along with a good head of steam, with an order of magnitude more features and now three database drivers in core, but as of earlier tonight we officially have no less than five people on the database maintenance team. From MAINTAINERS.txt:

Via Planet PHP comes this interesting tidbit from Markus Wolff, the original author of PEAR LiveUser. After briefly lamenting over-engineered ACL (access control list) systems in PHP, he talks about a much simpler concept that holds some interesting nuggets of joy. Might Drupal benefit from some of them?

Oy, what a year it's been! Aside from the excitement of the election and the economy, it's been an exciting year for me in the professional realm. (Personal realm, if you don't already know then you shouldn't know. :-)) And of course, it's been a crazy crazy year for Palantir, too, but in a mostly good way.

Let's see, one new job, two new Drupal jobs, two conferences, one sprint, three camps, six new colleagues, two foreign countries, eight other US states, one book... and a partridge in a pear tree, probably. Oof!

Via Planet PHP I stumbled across this article decrying Singletons. It's not a new argument, really, but one of the comments pointed me toward a Google Tech Talk video entitled "Global State and Singletons". To be honest I don't agree with everything said in either the article or the video, but both are spot on about the problems of global state, something I've lamented before in relation to testing.

That is especially relevant now, as we consider the question of Handlers in Drupal. Why? Because the most controvercial part so far, the environment variable, is designed to address exactly this problem, a problem that is currently prevalent throughout all of Drupal.

Permit me to explain.

Unless you've been living under a rock for the last six month, you should have already heard about Drupal 7's new-and-shiny database layer, DBTNG. That was only the beginning, though! Much has happened since then to the database, and there's much yet to do. That's where you come in...