There's been a fair bit of talk about PHP IDE's of late. That's not surprising given how useful they can be. (Really, folks, vi can only take you so far.) Most of the attention has been focused on the big boys: Eclipse and its derivatives (both free and commercial), Komodo, and NetBeans. Eclipse and NetBeans are both Java based, and Komodo is based on Mozilla's XUL platform (which also runs Firefox and company). I've been bouncing between them for a while, and haven't really been satisfied with any of them. I usually refer to Eclipse as the one I hate least. :-)

There's a new contender to keep an eye on, though, that is worthy of notice: KDevelop.

Just to give everyone a heads up, I have made some changes to one of my sessions. Based on the feedback I received earlier, my session on Object-Oriented Drupal has been updated. It seems no one wanted to hear about the basics, as they already knew them. :-) I will instead be focusing on design patterns, OO design philosophy, and how it applies (or should apply) to Drupal. It's too late to get changes into the printed program, but I have updated the session page on the DC DC web site to reflect the new focus.

So if you were hoping for a session on basic PHP OOP syntax and concepts, um, sorry. If you're looking for an intermediate to advanced session on how to use OOP well, then this session is for you.

I'll see you in DC!

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.