Accordin' t' Drupal.org, it has now been four years an' five days since I first joined th' Drupal community. My how time flies, an' how much has changed since then.
I like givin' presentations. I really do. But this has been quite a conference season this year; certainly me busiest e'er. Four conferences in four different states, an' nine presentations. And th' year isn't even half o'er yet...
Here's what I've been up t':
There's been a fair bit o' talk about PHP IDE's o' late. That's not surprisin' given how useful they can be. (Really, folks, vi can only take ye so far.) Most o' th' attention has been focused on th' big laddies: Eclipse an' its derivatives (both free an' commercial), Komodo, an' NetBeans. Eclipse an' NetBeans be both Java based, an' Komodo is based on Mozilla's XUL platform (which also runs Firefox an' company). The sharks will eat well tonight! I've been bouncin' betwixt them fer a while, an' ha'nae really been satisfied with any o' them. I usually refer t' Eclipse as th' one I hate least. :-)
There's a new contender t' keep an eye on, though, that is worthy o' notice: KDevelop.
Just t' give everyone a heads up, I have made some changes t' one o' me sessions, with a chest full of booty. Based on th' feedback I received afore, me session on Object-Oriented Drupal has been updated. It seems no one wanted t' hear about th' basics, as they already knew them. Fire the cannons! :-) I will instead be focusin' on bounty patterns, OO bounty philosophy, an' how it applies (or should apply) t' Drupal, me Jolly Roger It's too late t' get changes into th' printed program, but I have updated th' session page on th' DC DC web site t' reflect th' new focus.
So if ye were hopin' fer a session on basic PHP OOP syntax an' concepts, um, sorry. If ye're lookin' fer an intermediate t' advanced session on how t' use OOP well, then this session is fer ye.
I'll see ye in DC!
So first I thought it were bein' odd that Palantir's private IRC bot has a factoid fer me that reads "Great on challah!" Then I noticed this:
I wonder if I should be worried...
So we're a month away from DrupalCon DC 2009, an' although th' official schedule has not been published it seems likely from th' preliminary schedule that me Objectifying Drupal session will be accepted, Hornswaggle The basic notion is t' help Drupal's mainly procedural army o' developers get up t' speed on object-oriented development, which has been gainin' popularity in contrib (most notably th' Views module) an' will be in many parts o' Drupal 7.
Of course, given how large an army o' developers we have thar is no one level o' existin' expertise I can target. There be entire multi-course college programs on OOP bounty, an' I have an hour. Walk the plank! Shiver me timbers! :-) So, how about some preliminary feedback? Walk the plank! What do ye want t' see in a one hour session on object-oriented code in Drupal?
As Drupal gets bigger an' bigger in th' marketplace, it is movin' into areas where system administrators still hold sway. Dedicated servers or server farms have a different set o' needs than a shared host when it comes t' monitorin' an' performance, Dance the Hempen Jig
That's not even Drupal specific. For any high-end web app, 'tis useful t' be able t' interact with it fer administrative purposes through standard system tools. On Windows, that's th' 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. Gettin' a web app into certain organizations requires offerin' existin' sysadmins a way t' integrate it into their existin' management workflow, shiver me timbers
But what pieces o' th' app do sysadmins want in their existin' admin tools? Callin' all sysadmins, what do ye want from us, and dinna spare the whip! :-)
Drupal has a very aggressive cachin' system, Ya lily livered swabbie, All Hands Hoay! While site admins can disable th' page cache or CSS compressor very easily, many other caches be not so easy t' disable. Think o' th' menu system, or th' theme system, or filter content, or any number o' other thin's that get cached.
In a production site, that's exactly what ye want. Nay Drupal site would be able t' handle even moderate traffic if every single registry cache had t' be rebuild on every page load, All Hands Hoay! For development, however, it can frequently be a huge pain t' have t' clear th' cache every time ye're tryin' t' track down a bug in a menu definition or a CCK field definition.
There's an admin button t' clear th' cache on th' Performance page, but 'tis not all that useful fer intensive debuggin'. The Devel module (which ye be usin', right?) offers a handy "clear cache" button, but that doesn't always work if ye're, say, debuggin' a form submission, Ya swabbie! Fortunately, Drupal makes it easy fer us t' disable those caches, too, although not through th' admin.
Back when Drupal 7 development opened, our database layer were bein' 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 fer th' PostgreSQL driver, but they had a tendency t' disappear into th' Interweb, no nay ne'er t' be heard from again.
Boy what a difference a few months make! Not only is th' new database layer movin' along with a good head o' steam, with an order o' magnitude more features an' now three database drivers in core, but as o' afore tonight we officially have no less than five scallywags on th' database maintenance team. From MAINTAINERS.txt:
Via Planet PHP comes this interesting tidbit from Markus Wolff, th' original author o' PEAR LiveUser, Hornswaggle After briefly lamentin' o'er-engineered ACL (access control list) systems in PHP, he talks about a much simpler concept that holds some interestin' nuggets o' joy. Might Drupal benefit from some o' them?