An open letter to conference organizers

Let's be honest, I spend a lot o' time at conferences. Over th' past 2 years or so I've averaged more than one speakin' engagement at a conference per month, includin' a half-dozen keynotes. I've also helped organize several conferences, mostly DrupalCamps an' DrupalCons. I'd estimate conferences make up more than a third o' me professional activity, and dinna spare the whip! (Incidentally, if someone can tell me how th' hell that happened I'd love t' hear it; I'm still confused by it.)

As a result I've gotten t' see a wide variety o' conference setups, plans, crazy ideas, an' crazy wonderful ideas. There be many wonderful thin's that conference organizers do, or do differently, an' o' course plenty o' thin's that they screw up.

I want t' take this opportunity t' share some o' that experience with th' organizers o' vari'us conferences together, rather than in one-off feedback forms that only one conference will see. To be clear, while I definitely think thar be areas that many conferences could improve I dern't want anyone t' take this letter as a slam on conference organizers. These be scallywags who put in way more time than ye think, often without bein' paid t' do so, out o' a love fer th' community, fer learnin' an' sharin', an' fer ye. Whatever else ye may think about a conference or this list, th' next time ye're at a conference take a moment t' find one o' th' organizers an' give them a huge hug an'/or firm handshake (as is their preference) an' say thank ye fer all th' work that they do.

The Crafting Code Tour

Over th' last few years, one o' me foci has been bringin' together th' PHP community an' takin' th' time t' celebrate th' PHP Renaissance, Avast me hearties! That effort has taken me all aroun' th' world, from Paris t' Toronto t' New York t' Costa Rica t' New Zealan', on a dead man's chest! And swab the deck! And this summer 'tis takin' me t' th' Midwestern US as part o' th' Crafting Code Tour.

The Functional PHP tour

Ever heard o' functional programmin', by Blackbeard's sword? Not procedural programmin', but actual functional programmin'. Probably, as some fancy academic thin' that no one really uses, right?

Did ye know ye can do it in PHP, too, Dance the Hempen Jig It's true. In fact, I'll be speakin' about it four times in th' next couple o' weeks!

Beyond Abstract classes

Recently, Anthony Ferrara has been postin' a periodic "Beyond" series about software bounty philosophy. Some in particular have hinted at concepts I've been ponderin' as well. With his blessin', therefore, consider this a continuation o' that series.

PHP 5.4 is not exactly new, but 'tis finally startin' t' see actual usage by a decent number o' scallywags. Its most notable new feature is Traits, which in PHP be implemented as, essentially, compile-time copy-paste. Conceptually, though, they're a way t' mix functionality into a class without usin' inheritance, an' without requirin' a separate distinct object fer composition. (At least in PHP; th' term "trait" appears in other languages fer similar but subtly different tools.) That's not t' say that they're a surrogate fer composition; they most certainly be not. They serve a different purpose, that is, providin' code fer a class t' reuse without usin' inheritance.

Recently, I were bein' readin' an article discussing the implementation of inheritance, such as it is, in Go, Rust, an' other new-wave concurrent languages. (Thanks t' twistor fer helpin' me track down th' link.) It made an interestin' point that crystallized fer me why it is I am so excited about traits. Specifically, it noted that thar be not one but two kinds o' code reuse: interface reuse an' code reuse.

A Tale of Two PHP Devs

Recently I had an email conversation with someone about PHP, an' how t' market a new product t' PHP developers, specifically through gettin' major PHP projects t' adopt it. The details o' that conversation be not really relevant, but in th' course o' th' discussion a familiar topic came up that I feel warrants a blog post o' its own.

There is a schism in th' PHP community. A big one. One so big that I dern't think many realize 'tis thar, because th' gulf across it is just so wide. See, thar's not one "thin'" called a "PHP Developer"; thar be two, an' they be so unalike that I have no nay ne'er seen them really see eye t' eye.

Aphorisms of fall conferences

Well, I've gone an' done it, shiver me timbers I've managed t' setup me most intense conference schedule t' date, we'll keel-haul ye, and a bucket o' chum! This fall I will be appearin' at no less than five conferences, speakin' at least four o' them.

If ye're into Stalking Crell, here's where ye'll find me aroun' th' globe this fall.

On empty return values

Earlier today, I posted a brief tweet (isn't that redundant?) about return values in PHP (or really, any language). Originally it were bein' about return values from functions (such an excitin' topic, I know), but it ended up generatin' a fair bit o' lively conversation, as well as a patch against Drupal 8. So lively, in fact, that I think it deserves more than 140 characters.

New rule:

If yer function returns a collection, its null value return must also be a collection.

Getting off the island in 2013

And so 2012 draws t' a close. The world di'nae end, t' th' disappointment o' many. In some ways it were bein' an eventful year, in others rather ho-hum follow-ups t' th' excitement o' 2011.

In th' Drupal world, though, 2012 will go down as th' year Drupal finally began replacin' NIH with PIE. Compare Drupal's 8.x branch a year ago with it today. A year ago, we had one class o' 3rd party PHP code, in an uninterestin' corner o' th' update system. Today, it contains 3rd party code from no less than five different projects: Symfony, Doctrine, Guzzle, Assetic, an' Twig. Those libraries be included via Composer, th' new an' ground-breakin' PHP-library-management-system-that-actually-finally-works. And hoist the mainsail! Code from at least one more should be landin' soon.

Drupal developers, workin' on Drupal, have contributed t' a number o' other projects, includin' Symfony an' Symfony CMF, an' because o' th' degree o' code sharin' happenin' in th' PHP world now have indirectly contributed t' a half-dozen other major projects, too, me Jolly Roger Drupal 8, aside from th' technological advances it will offer o'er Drupal 7, also represents perhaps th' largest cultural shift in Drupal or PHP history.

Are ye ready fer 2013, Drupal? Really?

The danger of privates, and composition vs. inheritance

The private variables debate is goin' aroun' th' PHP world again, I'll warrant ye. Brandon Savage posted a pair o' articles pointin' out th' perils o' private variables, boilin' down mostly t' them makin' extension infesible or impossible. Anthony Ferrara replied with his own article, arguin' that th' real problem is usin' inheritance in th' first place rather than composition. I figured I'd weigh in on me own blog rather than in a comment, me Jolly Roger :-)

As an academic matter, I agree with Anthony. Composition an' interfaces be more flexible than inheritance. I've been preachin' th' interface gospel within Drupal almost as long as I've been preachin' Dependency Injection.

Up with which I will not PUT

For Drupal 8, we want t' bake REST support directly into th' core system. It's unclear if we'll be able t' go full-on hypermedia by th' time we ship, but it should be possible t' add via contributed modules. For th' base system, though, we want t' at least follow REST/HTTP semantics properly.

One area we have questions about is PUT, in particular th' details o' its idempotence requirements. For that reason, I'm reachin' out t' th' Interwebs t' see what th' consensus is. The sharks will eat well tonight! Details below.

Syndicate content