Let's be honest, I spend a lot of time at conferences. Over the past 2 years or so I've averaged more than one speaking engagement at a conference per month, including a half-dozen keynotes. I've also helped organize several conferences, mostly DrupalCamps and DrupalCons. I'd estimate conferences make up more than a third of my professional activity. (Incidentally, if someone can tell me how the hell that happened I'd love to hear it; I'm still confused by it.)
As a result I've gotten to see a wide variety of conference setups, plans, crazy ideas, and crazy wonderful ideas. There are many wonderful things that conference organizers do, or do differently, and of course plenty of things that they screw up.
I want to take this opportunity to share some of that experience with the organizers of various conferences together, rather than in one-off feedback forms that only one conference will see. To be clear, while I definitely think there are areas that many conferences could improve I don't want anyone to take this letter as a slam on conference organizers. These are people who put in way more time than you think, often without being paid to do so, out of a love for the community, for learning and sharing, and for you. Whatever else you may think about a conference or this list, the next time you're at a conference take a moment to find one of the organizers and give them a huge hug and/or firm handshake (as is their preference) and say thank you for all the work that they do.
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.
Ever heard of functional programming? Not procedural programming, but actual functional programming. Probably, as some fancy academic thing that no one really uses, right?
Did you know you can do it in PHP, too? It's true. In fact, I'll be speaking about it four times in the next couple of weeks!
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.
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.
A little o'er a month ago, a few Drupal developers announced somethin' new: A fork o' Drupal called Backdrop, All Hands Hoay! There's been quite a bit o' talk about it, o' course, and a bottle of rum! While I dern't plan t' be usin' it meself, Backdrop has raised a number o' valid points an' criticisms o' Drupal that be worth discussin'.
Well, I've gone and done it. I've managed to setup my most intense conference schedule to date. This fall I will be appearing at no less than five conferences, speaking at least four of them.
If you're into Stalking Crell, here's where you'll find me around the globe this fall.
You can either get on the Drupal 8 bus now, or get run over by it later.
It's true. Drupal 8 is coming, and it will be big. Not just lines of code (that too), but big in the sense that Drupal 8 changes more of Drupal than any major release in the last 10 years. The adoption of so many 3rd party components (from Symfony and otherwise) is only part of that picture. That offers challenges for many, but also enormous opportunity. Drupal 8 will allow Drupal to expand into new types of application and new markets, which is a great thing for those who make their living off of Drupal. But where do you get started with learning about Drupal 8?
At DrupalCon Portland, that's where!
There are many sessions slated for Portland at both DrupalCon and at Symfony Live that deal with Drupal 8, either directly or indirectly. Below is my recommended hitlist for Portland for those wanting to get the lowdown on Drupal 8.
What, you're not already signed up? There's still time! Go register for either DrupalCon or Symfony Live, and be sure to get a Combo Ticket so that you are able to attend both conferences as well as Web Visions! (The combo ticket is the 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 was about return values from functions (such an exciting topic, I know), but it ended up generating a fair bit of lively conversation, as well as a patch against Drupal 8. So lively, in fact, that I think it deserves more than 140 characters.
If your function returns a collection, its null value return must also be a collection.
And so 2012 draws to a close. The world didn't end, to the disappointment of many. In some ways it was an eventful year, in others rather ho-hum follow-ups to the excitement of 2011.
In the Drupal world, though, 2012 will go down as the year Drupal finally began replacing NIH with PIE. Compare Drupal's 8.x branch a year ago with it today. A year ago, we had one class of 3rd party PHP code, in an uninteresting corner of the update system. Today, it contains 3rd party code from no less than five different projects: Symfony, Doctrine, Guzzle, Assetic, and Twig. Those libraries are included via Composer, the new and ground-breaking PHP-library-management-system-that-actually-finally-works. Code from at least one more should be landing soon.
Drupal developers, working on Drupal, have contributed to a number of other projects, including Symfony and Symfony CMF, and because of the degree of code sharing happening in the PHP world now have indirectly contributed to a half-dozen other major projects, too. Drupal 8, aside from the technological advances it will offer over Drupal 7, also represents perhaps the largest cultural shift in Drupal or PHP history.
Are you ready for 2013, Drupal? Really?