:q!

Media Mover 6.1 has cut and paste style import/export functionality, but no real obvious way to run a config from code or import a config from a file. To solve the problem of deploying a configuration to another environment, I came up with this function that I use in update hooks:

After going through all the CDN options available for Drupal 6, I wasn't totally satisfied with any of them. My requirements were thus:

• Move user uploaded files to S3
• Rewrite image URL to S3/CloudFront IF the file has been moved
• Imagecache support

The CDN integration module seemed to be the most promising, but I wasn't crazy about patching core plus running a daemon to handle file processing/uploading. Most of the other approaches I saw all assume that the file exists on the CDN, which is an assumption I'd rather not make when dealing with user uploads.

Media Mover!

I was first introduced to Media Mover at the session at DrupalCon DC, and I've been anxious to use it ever since.

Why Siege?

So far, it's the simplest tool I've found to quickly benchmark response times. When I'm developing or tuning web/db servers, I want to quickly get a idea of the performance impact my changes are making. Tools like JMeter offer quite a bit more, but I appreciate the low barrier to entry for a tool like Siege. It's perfect when you just need to know if you're making performance better or worse, and Firebug isn't making it obvious. I should also note that it is very similar to Apache Bench, except that it can handle SSL, which ab cannot.

After running into trouble trying to use ApacheBench over SSL, I went ahead and gave Siege a try. Initially, I was very impressed as it handles SSL well and has some cool features that ab doesn't.

I didn't have any trouble getting it to work as an authenticated user using the -H flag to set the "Cookie" header, but I recently discovered that you can also provide a "login url" in your siegerc. This sounded great since that allows me to take one more bit of logic out of my wrapper script, but I couldn't get it to work.

After playing with the source a bit, I found a couple things.

First, in main.c, I found a hidden flag:

Using the -D flag will print out all request and response headers. Very helpful!

This illuminated that fact that although every response had a Set Cookie, no Cookie header was being sent back in the requests.

While testing Drupal's performance between two different NFS servers, I thought it'd be best to test some of the slower pages in the admin interface, so I had to figure out how to use apache bench as an authenticated user.

A quick google search brings up two methods:

http://ezra-g.com/blog/20080229/benchmarking-authenticated-drupal-users-...
http://2bits.com/articles/using-apachebench-benchmarking-logged-users-au...

Both seem fine, but not nearly lazy enough for me, so I went ahead and wrote this script:

http://github.com/msonnabaum/DrupalBench/blob/eb9ab9415c9b5067e7284d4402...

Basically, it works exactly like ab does, it just prompts you for your drupal login first. Any argument you give the script simply gets passed to ab. Here's how you'd use it:

./drplb.sh -c 1 -n 10 http://colonqbang.com/

I've tested it on OSX and Debian so far, and everything seems to be working well!

A handy alias I use in my .bashrc when I'm trying to find large files/directories:

An extremely simple script to download and install the latest build of chromium for mac:

Stick that in your crontab, and you're good to go!

I'm currently in the middle of moving all my sites over to a new VPS, so I needed to quickly dump all the databases to migrate them. I had a script that handled drupal db dumps pretty well, but it didn't do multisite, so I threw this together:

• Copy that into something like "multisite_db_backup.sh"
• Change the "MYSQLDUMP_DIR" variable to wherever you want the sql dumps stored
• Move it somewhere within your PATH (I use ~/bin/)
• Make it executable (chmod +x multisite_db_backup.sh)
• Run it in the root directory of your drupal install (cd drupal6; ./multisite_db_backup.sh"

Tested on debian and Mac OS 10.5.

I've been playing around with scripting update.php for a while now. I remember having a working script a few months back, but I never really put it into production and it looks like there's been some Drupal core changes that broke what I wrote before anyhow. I've rewritten most of it, and from what I can tell, it works pretty well for Drupal 6.

One of the main goals of any Drupal shell script that I write, is that it works on any Drupal installation, without bootstrapping. This is essential for me at work since we run a lot of individual Drupal installs. I'm transitioning over to drush to replace some of my scripts, but drush gets information about the site by bootstrapping. This makes a lot of sense for what it does, but it takes a bit more setting up, and isn't as portable as a vanilla bash script.

So with that in mind, here are a couple things to note about this script (and any other Drupal-relation shell script I post):

For my final project in my Physical Computing class, I chose to build a small robotic piano-like instrument. Building upon the ideas I had for my previous project (a sort of robotic lap steel), I decided to add dampers and ditch the string bending to try to keep things simpler. Besides the dampers, I wanted to figure out how to control many more digital outputs than are available in the arduino.

I decided on using the 74HC595 shift registger to expand my outputs. Since I wasn't too worried about having PWM to control solenoids, I figured this would work fine. There's also a good tutorial about using them with an arduino, so it was pretty easy to get going.