Drupalcon Day 2 started off better than Day 1. Why? Because I decided to skip the hell out of the free coffee and just buy my own at Dunkin’ Donuts. Sometimes free just ain’t worth the cost.
The morning started well when I ran into Robert Douglass, formerly of Lullabot, now of Acquia. Late last year Robert worked with us when we hired Lullabot for some consulting on our rebuild. We had only worked with Robert over the phone and via email, so it was nice to meet him in person. In addition to being a Drupal genius, he’s also a very nice guy. More on Robert in the coming days…
Today Pete and I were joined by another WGBH developer and our buddy, Josh Boughey. Josh works in the membership department and will be working with us to rebuild WGBH.org. Hopefully we’ll get Josh to blog here about his involvement at some point.
Other than that, it was more of the same. Lots of people with facial hair, lots of laptops, lots of Drupal talk, of varying degrees of usefulness. Here’s a recap:
The first session I hit was Best practices in development environments, staging, build management,
and production environments. This was pretty good, though mostly high level. There were some interesting things to note.
One of the panelists was Narayan Newton, the DBA for OSU Open Source Lab; they’re the ones who host Drupal.org. He gave us a rundown of their setup: four load balanced web servers, two database servers (one active, one passive, using replication).
Narayan told us about how they’ve made use of this database replication patch, which allows them to redirect all read queries to the passive database, thereby improving performance. He says that the new database layer for Drupal will support this functionality by default.
One person in the audience got up and spoke about SQL Relay and MySQL Proxy, both of which offer the ability to load balance requests to your MySQL database servers. This is all worth checking out.
The panelists then talked about leveraging source control. One panelist said he didn’t see the need for branching if you’re just developing for yourself (which is my opinion, also). A common code control approach is to use CVS to manage the core and contributed Drupal code, and import that all (including the CVS subdirectories) into SVN. This is the approach we plan to use for WGBH.org. The panelists differed over whether to deploy from staging to live using SVN or rsync.
They then talked about automated deployments. The Open Source Lab folks use something called Cfengine to manage the system configurations of all of their servers with a small staff.
The discussion then veered into the topic of code vs. content migration. The upshot here was that nobody seems to have a good solution to the problem of migrating database changes from staging to live environments (particularly, settings and content in the db that needs to be migrated). Again, though, the audience stepped up and somebody recommended the Publish and Subscribe modules to push from staging to live. Somebody else suggested Drupal Migraine (yes, like the headache), which is a Python-based (the scripting language, not the snake) tool for doing this sort of thing. We’ll have to check these all out.
Things wrapped up with a discussion of QA best practices. One of the attendees got up and mentioned a tool called Watir, a Ruby-based (the language, not the precious gem) tool which allows for automated cross-browser testing. It works on Windows IE, but there are also Firefox and Safari versions. The crowd was duly impressed.
The big session of the morning was by Chris DiBona of Google, who gave an entertaining and interesting speech about open source and why Google supports it. I believe that Chris will be doing two shows nightly throughout the week. Try the fish!
Following a lunch of a burrito con carnitas, I attended one of the birds of a feather sessions, about the problems with upgrading staging environments to production systems. People kicked around potential solutions for pushing configuration and content changes that are stored in the database from the staging to the live database.
The most common solution involved writing any number of scripts to dump DML and content from the staging database and import them into the live database. This approach makes some people uncomfortable as it sidesteps the usual Drupal APIs (either using the GUI or programming it on the back end).
Another solution is to enable binary logging for MySQL. Binary logging causes all SQL statements that updated (or could have updated) data (e.g. no select or show statements) as executable commands. You can then extract those commands (filtering in/out the ones you want/don’t want) using MySQL tools and writing the commands out to a text file of SQL commands that can then be executed against the live database.
The main problem with both of these approaches is the potential for overlapping ID numbers. Some people get around this by allocating the first X number of auto increment IDs (like the first 1,000 or 10,000) for use on the development server only. That sounds clunky to me and I’d rather not do that.
After a break for coffee and a large chocolate chip cookie, all of us GBHers headed into the Theming with the Theme Developer module session, led by Moshe Weitzman, who wrote the new (as of Drupal 6) theme developer module.
This module looks mighty slick.
It’s part of the Devel module distribution. The big thing here is that there is now support for sub-themes, meaning that you can base a theme on an existing theme and simply override the parts of the parent theme that you want to change without having to replicate all of the theme code. Wow-wee! Themes now have .info files, in which you can define a base or parent theme.
Another great thing about this module is that is makes use of Krumo (which you need to first download into the Devel directory). Krumo allows nice functionality like being able to highlight and click on page elements and see what file or function is controlling its style! It tells you how you can override the base theme’s styling. It will also show you all variable and parameters passed into the appropriate theming function and let’s you browse all of the data available to that theming function. It looks as sweet as that big-ass cookie I ate just before the session.
Bottom line is this new module looks like it’ll make theming much, much, much easier.
After that, I called it day and headed home to help put the kids to bed.
Filed by Phil at 1:49 pm under Drupal, Drupalcon, Images
5 Comments