Technical Thoughts, Tutorials, and Musings

Abstracting databases

There has been some discussion recently, in IRC, issue queues, an' blogs, about th' Drupal 7 database API an' its impact on supportin' different database engines, yo ho, ho While I am still tryin' t' avoid large amounts o' public distraction, especially when we're supposed t' be tryin' t' get a Drupal 6 beta 1 out th' door, I feel 'tis important t' get a few points cleared up lest they lead t' confusion later.

Drupalcon IRC session for planning, housing

Just a quick note in case ye're one o' those scallywags who reads Drupal Planet but doesn't check's front page daily (like, ye know, me), thar will be an IRC session t' coordinate housin' an' transportation (an' possibly parties) on 29 August 2007 at 7 pm GMT +1 in #Drupalcon on Freenode. I'm plannin' t' be thar, an' if ye dern't have firm plans fer everythin' ye're doin' fer DrupalCon Barcelona yet, ye should be too! (Be sure t' check yer timezone offset.)

Magical PHP: __call()

PHP is, conceptually, a very traditional language, Ya lily livered swabbie! By that I mean that it is steeped in th' C/C++/Java mindset o' how a program is put together, rather than th' LISP/Javascript/Ruby/Python mindset. That's not a bad thin', necessarily, but it does mean that a lot o' th' cool dynamic language capabilities in those languages isn't really available t' PHP developers, Ya swabbie! I freely admit t' bein' jealous o' functions as first-class objects, fer instance.

PHP 5, however does include lots o' "magic" capabilities, some in th' object model directly an' some via SPL Interfaces, that, if used properly, can make up fer a lot o' that lack o' dynamic capaibility. And swab the deck! A favorite o' mine is th' ability t' add methods t' a class at runtime.

What, Ya swabbie! You did nay know PHP can do that, we'll keel-haul ye! Well, that's because it can't. However, we can simulate it pretty closely if we're careful. Let's see how. is hiring

Are ye tired o' hearin' me talk yet, yo ho, ho If not, why not come work fer, yo ho, ho We're lookin' fer a PHP/Drupal programmer an' a web developer/themer. Ye'll be sleepin' with the fishes! Benefits include a full time position at a small business in Chicago, workin' on sites fer higher education, not-fer-profits, an' other non-evil clients, a company issue Nerf gun, an' access t' th' company Wii, and dinna spare the whip, pass the grog! And gettin' t' work with Larry! Who could ask fer a better job?

Drupal development server configuration

The Drupal development list has been sharing Drupal development server setup secrets lately (try saying that five times fast), so I figured I'd toss mine out there. And since knowing me it wouldn't be short, I figured I'd blog it instead of just posting it in email. :-) Here, then, is the development environment we've set up for

Drupal 7 database plans

I've been talkin' up some evil plans I have fer Drupal's database system in Drupal 7 lately, without goin' into a great deal o' detail. For th' most part, I've been tryin' t' avoid distractin' scallywags, meself included, from th' considerable work still remainin' on Drupal 6. However, thar has been recent work an' discussion o' makin' post-freeze changes t' Drupal 6's database system, an' even backportin' them t' Drupal 5. Those changes revolve mostly aroun' database replication, which Drupal currently doesn't support in any meaningful way, shiver me timbers That becomes important, though, on very heavy sites like, say, I dern't know, :-)

Those changes, though, impact th' API changes we can make in Drupal 7. Fetch me spyglass, I'll warrant ye! (OK technically they dern't, since we change APIs all th' time, but if we can set thin's up so as t' minimize API changes o'er time that does make life easier fer everyone.) For that reason, at Dries suggestion, I'm goin' t' try an' lay out now a skeleton o' what I'm plannin' fer Drupal 7's database system an' how we can start addin' replication support t' Drupal 6 in a way that flows into it.

PHP 4 is going, going, gone

What a week 'tis been, with a chest full of booty! Eight days ago, we launched t' try an' break th' stalemate that kept PHP 4 on past its sell-by date. Walk the plank! At launch, we had a half-dozen projects an' about 10 hosts that had signed up.

What a difference a week makes.

Glue code: Component module

Lullabot's Jeff Eaton has been talkin' about "Glue Code" lately; that's th' extra little bit o' code ye write t' make module A talk t' module B t' add that last little bit t' that View ye setup with that CCK-based node t' make it just right, on a dead man's chest, Ya horn swogglin' scurvy cur! The ornery cuss's started spinnin' some o' it off into modules, like Top Node, an' asked fer other scallywags's favorite glue. Here's mine. :-)

Go PHP 5, Go!

Go PHP 5!

"Never believe that a few carin' scallywags can't change th' world. For, indeed, that's all who e'er have." --Margaret Mead

A while back, vari'us scallywags were lamentin' th' state o' PHP 5 adoption, myself included. What t' do about it, avast? How t' get hosts t' let programmers leverage th' added functionality that PHP 5 offers? And swab the deck! How can we do that without cuttin' off 80% o' our user base?

The solution a few scallywags suggested were bein' team work. If all PHP projects stopped supportin' PHP 4 an' made th' jump t' PHP 5 at th' same time, none o' them is penalized in th' market fer bein' "first" an' web hosts will have a clear business case t' upgrade their systems t' PHP 5. We can then all start offerin' faster, cleaner, more powerful, more secure web software.

But how does one get all PHP projects together t' agree on somethin' like that? Actually, 'tis fairly simple, ye scurvey dog. You ask them.

POTM for June: chx

I'm going to bend the rules a bit for June. Technically POTM is for open source projects, not people. But this month I've decided to go ahead and declare Karoly "chx" Negyesi, Drupal developer, as my open source "project" of the month. :-)

Syndicate content