Nothing in particular, but seeing that I have worked in the software industry for about 11 years now, I figured it was time to get a more professional sounding domain name. It was getting increasingly more difficult to tell co-workers and colleagues that my website was at www.claws-and-paws.com and keep a straight face. A domain name of dmuth.org sounds more professional, and doesn't tie the site to any one topic. (Unlike claws-and-paws.com, which has a furry slant)
I'm still keeping the furry stuff, convention photos, etc. here. In fact, going to any URL on www.claws-and-paws.com will cause the browser to be redirected to the exact same page on this site. For those of you who still have email addresses @claws-and-paws.com (yeah, both of you ), that won't change any time in the near future either.
Folks might have heard that Steam is finally available for the Mac and that, for a limited time, Portal is available as a free download. Naturally, I made the most of it, and downloaded Portal on Friday evening, beating it just last night.
Downloading Portal was interesting, I had no idea that the game was on the order of 3 Gigs in size. It was a great way to test out my current Internet connection, which performed pretty well, as this graph shows:
As for playing the game itself, someone asked me how Steam and Portal were on the Mac, out of concern that there might just be some emulation going on. This does not seem to be the case, judging by my CPU usage (gameplay began right after the download):
I'd say that my Mac Mini held its own just fine.
I'll probably be on Steam on occasion. If anyone wants to friend me there, feel free. My Steam ID is DmuthAtHome.
There has been some increased activity on Pennsylvania Furries website recently, so I decided it justified finally biting the bullet and upgrading the site from Drupal 4.7 to Drupal 6.16. That upgrade was fun and... interesting. But now that I have a much more recent version of Drupal installed, I've been able to add some features such as these:
- Event Calendar. Want to know when upcoming furmeets, gathers, etc. are? We now have a calendar that anyone may post events to.
- Buddy lists. Yes, they are what you think they are. Users can now have an actual "friends" list on this site. Go to any user's page and click the link towards the bottom to become their buddy. (Here's an example)
- Private messages. Just what the name implies. Users on the site can now send each other private messages. When you're logged into the site, just click the "Messages" link to get started.
- Searching. I reindexed the entire site (and set up crontabs to keep that happening) so now the search engine works again, and posts (and users) on this site are fully searchable.
- Tagging posts. All posts can now be tagged. Even posts made by others. Go ahead. Give it a try. There is also a tag cloud that lists the most popular tags on the site.
- User profiles that don't suck. All user profiles now have links to a number of social networks, along with support for forum signatures, private messaging, and buddy lists.
And the URL for the Pennsylvania Furries website?
Check it out, and let me know what you all think!
So the user Jalterixnar on the Anthrocon forums was nice enough to create a commercial for Anthrocon 2010 and post it on YouTube:
That is amazingly cool, and the tool used to create it was at http://www.youtube.com/searchstories. I've been playing with it on my own, and it's quite neat, as it allows different kinds of searches to be performed, as well as choosing different music.
I'm unclear whether this was just a "toy" that Google created, or whether they plan on using it to revolutionize the advertising industry, but it certainly is a great step in that direction.
One of the neat things about the Drupal CMS is that it has a facility to schedule certain things to be run at regular intervals. For example: sending out subscription notifications or indexing posts for the search function. Those operations can take tens of seconds to complete, so you obviously don't want them executing in the middle of a page load.
The normal way to execute Drupal's crontabs is to load the script cron.php via the web interface. This is a terrible idea, since anyone with an Internet connection could cause your machine to run CPU intensive tasks at well, and bring the webserver to its knees.
An alternative way to run crontabs is with a third-party module called Poormanscron. It's a nice module, but the locking facility it has isn't so hot, and on more than one occasion I've had two cron runs execute in parallel, causing extra load on the machine. In especially bad (read: I/O bound) situations, multiple crontabs get "backed up" onto each other, and that creates huge load spikes and 60-second+ page loads until things calm down again.
There is yet a third way to run Drupal crontabs, and that's via the command line. It gives you maximum control over when and where crontabs run, and this is particularly important when you have multiple Drupal sites running. And I'm going to show you how to do it.
Step 1) Download Drush, the Drupal shell. It's a great little app for accessing your Drupal installation and performing common tasks from the command line. Install Drush (I usually put it in /usr/local/drush/, and make a symlink from /usr/local/bin/drush)
Step 2) Create a script in your home directory, and call it drupal-crontabs.sh. It should look something like this:
#!/bin/sh # # Our main directory for holding websites # ROOT=/var/www export DRUSH_OPTIONS="-q" #export DRUSH_OPTIONS="-v" # Debugging # # Errors are fatal # set -e cd $ROOT # # All of our drupal installations under $ROOT # SITES="furryconnectionnorth.com" SITES="$SITES saveardmorecoalition.org" SITES="$SITES claws-and-paws.com" SITES="$SITES sabanews.org" # # Loop through our sites to run crontabs on # for SITE in $SITES do cd $SITE # # Disable errors, since sometimes crontabs have issues. # set +e drush $DRUSH_OPTIONS cron set -e cd .. done
Be sure to season the $ROOT and $SITES variables to taste as per your specific installation.
If you run a chmod 755 on this script, you can execute it from the command line. However, you may run into file permission issues if the webserver is running as a different user than you (usually the case).
Step 3) Now you need to set up a crontab to run this script. My preferred way to do it is to create a file called /etc/cron.d/drupal-crontabs and place the following in it:
# # Run all of our crontabs for Drupal once an hour # MAILTO=root PATH=/usr/bin:/bin:/usr/local/bin 15 * * * * www-data /path/to/drupal-crontabs.sh
Make sure you are running these crontabs under the same user as your webserver.
That's it! If you want to see emailed notifications once an hour, just uncomment the line with the "-v" option for Drush. Otherwise, crontabs on all your sites will be run once an hour. Provided they do not take longer than hour to run, all of your search indexes and subscriptions will be kept up to date, and you will no longer have to worry about crontabs stomping over top of each other with Poormanscron. Enjoy!
Last weekend I headed down to Washington, D.C. to visit November and see the Cherry Blossom Festival.
I don't have much else to say about the festival, because it was a bunch of cherry trees, really. We walked around for a bit and I took a ton of pictures:
And here's the full slideshow:
Earlier today, I performed a major Drupal upgrade on another site that I run. Part of the upgrade involved me installing the Advanced Forum module to bring the forums a little more up to date with other sites that are out there.
Along the way, I learned something interesting: the Author Pane module does NOT display on blog posts.
It looked rather odd when comments on the blog posts had detailed user info, but the post itself did not. So I set out to fix that. I ended up commenting out the line
print $picture; in node.tpl.php and instead adding in these lines:
$account = user_load($node->uid); $template = "advf-author-pane"; $author_pane = theme('author_pane', $account, advanced_forum_path_to_images(), $template); print $author_pane;
The code is fairly straightforward. It loads user info on the author of the post, and the theme() function loads the author_pane template, passing in the user data.
Wow, it's been awhile since I've written here. Real life has had me very busy lately. I've done some neat things though, and I hope to post more about them soon.
The first neat thing I did recently was to roll out some badly needed updates for the user pages on anthrocon.org.
Before, I merely used the default pages that Drupal provided. The problem was that the pages looked a little... bland. Among other things, there were no icons for the various social networking services, and that just wouldn't do. So I read up on how to customize the user profile layout in Drupal and spent a couple of evenings writing some PHP code and making use of Drupal's theming functions.
Here are the old and the new pages side by side. Click on either to get a full page in a separate window.
|Old and busted:||New hotness:|
The upside of this effort is that when I'm ready to upgrade the Save Ardmore Coalition site to Drupal 6, I can pretty much just copy over my user templates on a wholesale basis, and save myself from having to redo all that work.
It was eerily quiet this morning. Many folks weren't going to work, and the roads were nearly empty. I took these pictures around 9 AM:
Lots of people weren't at the office today, either. I'm still not sure if we'll be back to normal tomorrow.
Looking back after this morning's stampede, I thought I'd share with folks how the webserver held up, since I know I am not the only geek out there. And, truth be told, I was a bit nervous myself, since I wasn't quite sure just how much traffic we would get and if the webserver would survive, or turn into a smoking crater.
Well, here's what we got:
The first hump is a manual backup I did last night. The second is the automatic backup that runs every morning, where the database and files are rsynced to a machine at another data center. The third hump at 9 AM was when we opened hotel reservations. 1.4 Megabits/sec doesn't look too bad, until you look at:
The 336 simultaneous connections a second was far more interesting. That's about 16 times the normal number of connections to the webserver.
So, what were the effects? Let's look at MySQL first: