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.
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!
Recently, Anthony Ferrara has been posting a periodic "Beyond" series about software design philosophy. Some in particular have hinted at concepts I've been pondering as well. With his blessing, therefore, consider this a continuation of that series.
PHP 5.4 is not exactly new, but it's finally starting to see actual usage by a decent number of people. Its most notable new feature is Traits, which in PHP are implemented as, essentially, compile-time copy-paste. Conceptually, though, they're a way to mix functionality into a class without using inheritance, and without requiring a separate distinct object for composition. (At least in PHP; the term "trait" appears in other languages for similar but subtly different tools.) That's not to say that they're a surrogate for composition; they most certainly are not. They serve a different purpose, that is, providing code for a class to reuse without using inheritance.
Recently, I was reading an article discussing the implementation of inheritance, such as it is, in Go, Rust, and other new-wave concurrent languages. (Thanks to twistor for helping me track down the link.) It made an interesting point that crystallized for me why it is I am so excited about traits. Specifically, it noted that there are not one but two kinds of code reuse: interface reuse and code reuse.
A little over a month ago, a few Drupal developers announced something new: A fork of Drupal called Backdrop. There's been quite a bit of talk about it, of course. While I don't plan to be using it myself, Backdrop has raised a number of valid points and criticisms of Drupal that are worth discussing.
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.
You can either get on th' Drupal 8 bus now, or get run o'er by it later.
It's true, with a chest full of booty. Drupal 8 is comin', an' it will be big. Not just lines o' code (that too), but big in th' sense that Drupal 8 changes more o' Drupal than any major release in th' last 10 years. The adoption o' so many 3rd party components (from Symfony an' otherwise) is only part o' that picture. That offers challenges fer many, but also enormous opportunity. Drupal 8 will allow Drupal t' expan' into new types o' application an' new markets, which is a great thin' fer those who make their livin' off o' Drupal. But where do ye get started with learnin' about Drupal 8?
At DrupalCon Portland, that's where!
There be many sessions slated fer Portlan' at both DrupalCon an' at Symfony Live that deal with Drupal 8, either directly or indirectly. Below is me recommended hitlist fer Portlan' fer those wantin' t' get th' lowdown on Drupal 8.
What, ye're not already signed up, on a dead man's chest! There's still time! Go register fer either DrupalCon or Symfony Live, an' be sure t' get a Combo Ticket so that ye be able t' attend both conferences as well as Web Visions, Dance the Hempen Jig (The combo ticket is th' same price either way.)
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.
If yer function returns a collection, its null value return must also be a collection.
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 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.
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.