While Drupal 7 has been quite long in the making, it's going to be very different from every release before: we have added tests that make sure core works well. (BTW it took quite some time to write so many of them!) This allows the core developers to focus their attention on deeper problems which are much, much harder to fix. Instead of "OMG node preview is broken!" we now contemplate "you know, this new File API is great, but it won't work well with Amazon S3 because..."

Everyone knows I am not too fond of OOP. And yet, I had some role in crafting DBTNG. I now admit: DBTNG in its current implementation is a mistake. Making the stream wrappers a class -- although PHP mandates that -- is a mistake.

Drupal 7 might work with Java databases. Eventually, we might even be able to run Drupal 7 on Google App Engine.

We wanted to serve static content from a CDN -- but it's the same if you only want to move your static content to a different server. This is fairly well researched and done in Drupal 6, here is the Drupal 7 version. It seems that some theme stuff (like the favicon and the logo and probably unaggregated CSS/JS) is passed as Drupal paths into file_create_url while aggregated CSS and JS is served from public://. So we need to implement file_url_alter and override the getExternalUrl of the DrupalPublicWrapper class (thanks goes to Damien Tournoud for pointing out the latter):

One of our coders have pinged me that he is getting a weird error message "Warning: uksort(): Array was modified by the user comparison function". The array sort callback was doing a database query on the first run, stored the results and used that to sort. For sure it was not modifying the parent array. Fairly innocent, isn't it? Well, actually not. It turns out that last August a check was added to PHP 5.2 and 5.3 (released in 5.2.11 and 5.3.1) to verify that the array being sorted does not change, however debug_backtrace() fools this check. Guess what?

One can copy-paste the mod_rewrite quotes from the Apache handbook pages verbatin just replacing mod_rewrite with git:

The great thing about git is it gives you all the configurability and flexibility of Sendmail. The downside to git is that it gives you all the configurability and flexibility of Sendmail.

Despite the tons of examples and docs, git is voodoo. Damned cool voodoo, but still voodoo.

Please read the much evolved Doxygen standards. Common mistakes include forgetting a newline before @return, and function doc has to start with 3th person verb. Props to aspilicious for working tirelessly on fixing these errors and to jhodgdon our API documentation maintainer.

If you have not participated in core development then please do not write ill informed, baseless derisive blog posts and especially not to the Drupal Planet. Critique is good, baseless bashing just makes those who actually do the work feel depressed, angry and sad. I now abstain from reading the development list, the forums could we please keep at least the Planet a place which a developer can read without wanting to hit something? kthxbye

I often lament that new Drupal community members are not like "old" and they are not contributing enough. But... do they have enough incentive and guidance? I go to drupal.org, click download, gather everything I need to create a site, I can't see much asking for contributing. The Documentation top tab is better because that does ask but then again it's a bit of a "wall of a text" and people might just skip it. How can we better guide the newcomers to turn to contributors?

Right now we have something like hook_user_logout which is documented in user.api.php and if mymodule wants to implement it then it needs to use a function called mymodule_user_logout. This is a Drupal convention and is not supported by any developer tool. We could instead have an interface called HookUserLogout with a single method called invoke which has the exact same signature and documentation as hook_user_logout. Edit: aside from IDE support, this would mean that PHP itself forces us to keep the hook signature. Invoking would happen through the registry table where we iterate over the classes implementing this interface. Of course, this would be cached but module_implements uses a cache in Drupal 7 already so not much change there. Code example is here, a skeleton of the invoker is here. The conversion would involve wrapping the function in a class, that's literally two lines of code including the } and renaming the function to invoke. The cost of creating a class vs calling a variable named function is not negligible but simply there are not enough on the page to make a measurable difference: 1000 calls are like 0.0025 vs 0.003 seconds.