Joining Lullabot
The rumors are true! As of today, I'm officially a Lullabot. People have been asking me, why leave the safety of a solid academic position to join a small company? I think the better question is, what kind of a company must Lullabot be for someone in a solid academic position to leave academia in order to join it? For those just stirring from in front of their VAX terminals (and why should they? the system is still up!), Lullabot is an open source education and consulting firm, focusing on the increasingly popular content management framework Drupal.
I look forward to being more involved in the open source community. And yes, the book is almost done!
Go ahead and ignore
Hmm, I think I will go ahead and click Ignore...
Second edition progress
I thought I'd update everyone on the progress of the second edition of Pro Drupal Development.
The second edition will cover Drupal 6, and is expanded to cover new core topics like actions, triggers, AHAH, etc.
Workflow 5.x-2.0 released
I've finally got a project that uses the workflow module so I've been able to justify putting some time into it. As a result, I've released version 5.x-2.0. This version of workflow works with the 5.x-2.x version of actions, which is the backport of Drupal-6-style actions to Drupal 5.
Growth of Drupal
Others are posting on Drupal's growth today. A picture is worth a thousand words, so here are 2000 words on the subject:
Letter to Dries, July 2004
At Drupalcon 2008, one question I was asked a number of times was "how did you get involved with Drupal?" Here's one of my first letters to Dries, after discovering Drupal in 2004. Interesting to think about how far we've come since then.
Hi Dries,
Slides from Drupalcon Boston 2008
Video of the presentation I gave at Drupalcon Boston 2008, titled Triggers and Actions and Hooks, Oh, My! should be appearing shortly. (In the meantime, here's me babbling about actions.) The slides are downloadable below.
XServe RAID discontinued
Apple has discontinued their confusingly named XServe RAID storage system. That's a shame, and yet another red flag for trusting Apple in the enterprise market, in my opinion.
I currently administer two of these (one on OS X Server and one on RHEL5), and I can't say enough good things about them. They have been reliable and fast. When a disk goes out, the system sends out notification and starts a rebuild on the hot spare automatically, just like a good RAID should. And they're quieter than any other dedicated RAID solution I've looked at. RIP, XServe RAID.
Drupalcon 2008 actions session
The session I proposed, Triggers and Actions and Hooks, Oh My! has been accepted at Drupalcon Boston 2008. I will be presenting the new capabilities of Drupal 6 in this area, from the big ideas to the nitty gritty. The session will be Tuesday afternoon from 5-6 pm, just before the Acquia Conference Social.
We had 26 people at the first Drupal conference in Antwerp (three years ago today, by the way!). There are currently 800 registered attendees for the upcoming Drupalcon, and the conference has reached its maximum capacity.
I'm looking forward to the presentations, the birds-of-a-feather meetings, hanging out with a bunch of geeks, some hacking time, and the business fair.
How to Speed up Drupal Forum Pages on a Busy Site
Drupal 5's forum module is OK. It lets you create multiple forums with taxonomy terms. Forum posts are true nodes so you get all the benefits of nodeness. And Drupal keeps track of which posts you've read. All that is great. But I've had some trouble scaling up a site that relies heavily on the forum module, even when using advcache. Investigating how the database was spending its time, I found lots of queries like this:
SELECT n.nid, n.title, n.sticky, l.comment_count, l.last_comment_timestamp FROM node n INNER JOIN node_comment_statistics l ON n.nid = l.nid INNER JOIN term_node r ON n.nid = r.nid AND r.tid = 123 WHERE n.status = 1 AND n.type = 'forum' ORDER BY n.sticky DESC, l.last_comment_timestamp desc
An EXPLAIN shows how nasty this is:
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
|---|---|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | n | ref | PRIMARY,node_type,status,node_status_type,nid | node_status_type | 102 | const,const | 30679 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | l | eq_ref | PRIMARY | PRIMARY | 4 | drupal.n.nid | 1 | |
| 1 | SIMPLE | r | eq_ref | PRIMARY,nid,tid | PRIMARY | 8 | const,drupal.l.nid | 1 | Using where; Using index |
Searching Drupal's code turns up this query in theme_forum_topic_navigation(). It turns out the database is smoking, grinding away, eating up cycles generating previous and next links for forum topics. I thought about it for a minute, and realized that I don't think I've ever used those links. Which would you rather have? Blazing speed or a link to the next forum topic? Fortunately, the slow query is in a themable function, which means we can get our performance back with a few lines added to our theme's template.php:
// No previous/next links for forum topics.
phptemplate_forum_topic_navigation($node) {
return '';
}In my case, server load dropped from 46 to 0.5. Sometimes it's the little things.