The Drupal development list has been sharing Drupal development server setup secrets lately (try saying that five times fast), so I figured I'd toss mine out there. And since knowing me it wouldn't be short, I figured I'd blog it instead of just posting it in email. :-) Here, then, is the development environment we've set up for Palantir.net.
I've been talking up some evil plans I have for Drupal's database system in Drupal 7 lately, without going into a great deal of detail. For the most part, I've been trying to avoid distracting people, myself included, from the considerable work still remaining on Drupal 6. However, there has been recent work and discussion of making post-freeze changes to Drupal 6's database system, and even backporting them to Drupal 5. Those changes revolve mostly around database replication, which Drupal currently doesn't support in any meaningful way. That becomes important, though, on very heavy sites like, say, I don't know, Drupal.org. :-)
Those changes, though, impact the API changes we can make in Drupal 7. (OK technically they don't, since we change APIs all the time, but if we can set things up so as to minimize API changes over time that does make life easier for everyone.) For that reason, at Dries suggestion, I'm going to try and lay out now a skeleton of what I'm planning for Drupal 7's database system and how we can start adding replication support to Drupal 6 in a way that flows into it.
What a week it's been! Eight days ago, we launched GoPHP5.org to try and break the stalemate that kept PHP 4 on past its sell-by date. At launch, we had a half-dozen projects and about 10 hosts that had signed up.
What a difference a week makes.
Lullabot's Jeff Eaton has been talking about "Glue Code" lately; that's the extra little bit of code you write to make module A talk to module B to add that last little bit to that View you setup with that CCK-based node to make it just right. He's started spinning some of it off into modules, like Top Node, and asked for other people's favorite glue. Here's mine. :-)
"Never believe that a few caring people can't change the world. For, indeed, that's all who ever have." --Margaret Mead
A while back, various people were lamenting the state of PHP 5 adoption, myself included. What to do about it? How to get hosts to let programmers leverage the added functionality that PHP 5 offers? How can we do that without cutting off 80% of our user base?
The solution a few people suggested was team work. If all PHP projects stopped supporting PHP 4 and made the jump to PHP 5 at the same time, none of them is penalized in the market for being "first" and web hosts will have a clear business case to upgrade their systems to PHP 5. We can then all start offering faster, cleaner, more powerful, more secure web software.
But how does one get all PHP projects together to agree on something like that? Actually, it's fairly simple. You ask them.
I'm going to bend the rules a bit for June. Technically POTM is for open source projects, not people. But this month I've decided to go ahead and declare Karoly "chx" Negyesi, Drupal developer, as my open source "project" of the month. :-)
So it only took them a month to grade it (silly paper exams), but I finally heard back from Zend about the Zend PHP 5 Certification exam I took at php|tek last month. I passed, of course. :-)
Let the bad puns begin!
Dries has been commenting recently, both on his blog and elsewhere, about one of the chief advantages of using open source: All developers/users are on equal footing. If you try to learn a proprietary app or framework, you know what the main developer feels like deigning to let you know. Anything else is either a mystery or, in some cases, illegal for you to find out (if there's any encryption or copy-prevention involved). You can never be as good an expert as the author, because the author has access to the Holy Book (code) and you don't. With an open source project, everyone gets the same access to the code. The only thing stopping you from being the best expert on the planet is your own skills and time.
He's very right about why you should choose to use an open source project. But what about why you should start one, or release your own code open source? As a developer, that's a far more interesting question for me.