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.
Over the last few years, one of my foci has been bringing together the PHP community and taking the time to celebrate the PHP Renaissance. That effort has taken me all around the world, from Paris to Toronto to New York to Costa Rica to New Zealand. And this summer it's taking me to the Midwestern US as part of the Crafting Code 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!
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.
Recently I had an email conversation with someone about PHP, and how to market a new product to PHP developers, specifically through getting major PHP projects to adopt it. The details of that conversation are not really relevant, but in the course of the discussion a familiar topic came up that I feel warrants a blog post of its own.
There is a schism in the PHP community. A big one. One so big that I don't think many realize it's there, because the gulf across it is just so wide. See, there's not one "thing" called a "PHP Developer"; there are two, and they are so unalike that I have never seen them really see eye to eye.
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?