If you haven't been living under a rock, you know that AT&T is trying to buy T-Mobile. This is a generally bad thing, as we already have far too much consolidation in the wireless carrier market as is, but that doesn't mean it's not still likely to happen. The only blocker is approval from the FCC, who is, per policy, soliciting public feedback. (It's 11-65.)
I would encourage everyone to sign in and voice their opposition. More carrier consolidation is not what we need. I've included my own public comments below for reference. Feel free to borrow liberally.
At DrupalCon Chicago, Dries announced that the development process for Drupal 8 would be a bit different. Rather than a vast dog pile of efforts to improve Drupal in ways big and small, Drupal 8 will feature a number of major "core initiatives". These initiatives highlight major areas of work that represent not just a patch or three but major changes to Drupal's plumbing. Each initiative will have one or two initiative leads who have the ability to coordinate and make decisions relating to that initiative while working closely with Dries. In a large sense, it is a way for Dries to scale; Rather than Dries having to keep track of 1000 ongoing conversations himself, initiative owners can coordinate related changes while Dries coordinates the initiative owners. It also gives a clear indication of what work is happening and what to expect out of Drupal 8.
The first initiative for Drupal 8 has already been announced; Greg Dunlap will be leading the charge to overhaul Drupal's configuration system to provide more robust, performant, and deployable configuration and change management. That will be critical for Drupal's future as we push further into the corporate and enterprise sphere, as well as enabling more robust and unified configuration handling in the first place.
Today, I am pleased to announce Drupal's second core initiative: The Web Services and Context Core Initiative (WSCCI).
Drupal's CVS repository was pronounced dead this Thursday 24 February at 6:08 pm US Eastern Time. Cause of death was reported acute age combined with an inability to properly merge. CVS is survived by approximately 7000 Drupal projects and a new farm of Git repositories.
I've spoken a great deal recently about architectural priorities. In short, we as software developers cannot eat our cake and have it too. Improving flexibility in one area may hurt performance, while improving usability one another area may hinder flexibility. These trade-offs are not necessarily right or wrong, except in the context of the goals and purpose of the project with respect to its target audience.
But what is Drupal's target audience, and how does that impact our architectural decisions?
DrupalCon Copenhagen was a watershed event in terms of understanding how to conceptualize that question, in my view, based on conversations I had with the likes of Mark Boulton, Jen Simmons, and Sam Boyer. In his (excellent) keynote, Jeremy Keith noted that the HTML5 Working Group had a specific, defined set of priorities:
In case of conflict, consider users over authors over implementers over specifiers over theoretical purity.
That may be a good priority order; it may be bad. That depends on your point of view and your goals. It lays out the order in which different stakeholders should be listened to, and if you come to a decision where you have to screw one group over to benefit another how that decision should be made. Having such a clear understanding of your constituent priority is critical to making good, consistent architectural decisions.
So what are Drupal's priorities?
As if on cue, the public vs. private debate has sprung up again within Drupal. The timing is fitting given my last blog post on programming language paradigms. Of course, property visibility is not a new debate, and the PHP community debates this subject from time to time (sometimes humorously).
What I believe is usually missing from these discussions, and what I hope to offer here, is a broader picture view of the underlying assumptions that lead to different conclusions about when different visibility is appropriate (if ever).
In short: It's the difference between procedural-think and object-think.
This article is also available in Serbo-Croatian
There has been much discussion of late in Drupal about Object-Oriented Programming. That's not really surprising, given that Drupal 7 is the first version that has really tried to use objects in any meaningful way (vis, as something other than arrays that pass strangely). However, too much of the discussion has boiled down to "OMG objects are inflexible so they're evil!" vs. "OMG objects are cool, yay!" Both positions are harmfully naive.
It is important for us to take a step back and examine why one particular programming paradigm is useful, and to do that we must understand what we mean by "useful".
Programming paradigms, like software architecture, have trade-offs. In fact, many of the same methods for comparing architectural designs apply just as well to language design. To do that, though, we need to take a step back and look at more than just PHP-style objects.
Warning: Hard-core computer science action follows. If you're a coder, I recommend getting a cup of
$beverage before continuing, as it could take a bit to digest although I've tried to simplify it as much as possible. There's fairly little Drupal-specific stuff here so hopefully it should be useful to any PHP developer.
As anyone who has followed my past work knows, software architecture is a particular interest of mine. I find the subject fascinating, but my interest is not entirely selfish.
Understanding architecture, and the trade-offs that different architectures imply, is an important part of any software project. Whether you're discussing a Content Management Platform like Drupal, a language like PHP, or a particular web site, having a solid understanding of the "big picture" is crucial not only for building the system right in the first place but for communicating that architecture to others.
To be able to speak and think about the design of your system properly, though, you need to understand the trade-offs that come with it. There is no such thing as a free lunch, and designing a system to be powerful in one way invariably tends to harm it in another. It is important to know what your priorities are before you start building; and in a distributed collaborative environment like Drupal to all agree what those priorities are, at least to a large extent.
Let us therefore examine those priorities and the trade-offs they require.
I meant to post these to groups.drupal.org, but the file size limit over there won't let me. Attached are the slides from my "Drupal: The Next Generation" presentation at DrupalCon Copenhagen. A more complete summary is available over in the working group.
I'm still not aware of any video available, sadly. Supposedly that should be up eventually.