Midwestern Mac, LLC

Stop letting .DS_Store slow you down

Jeff Geerling — Sun, 02 Jun 2013 17:44:32 +0000

I have over 100 git repositories on my Mac, and for almost every one, I sometimes browse the directory structure in the Finder. Once I do that, I inevitably end up with a few pesky .DS_Store files that want to be added to my repo:

.DS_Store files don't add anything of value to my code (they just tell Mac OS X about folder display and icons), so I always end up adding them to my own projects' .gitignore files. But when I'm working on other repositories (like Drupal, or a fork from GitHub) I don't want to add a .gitignore if none exists, or mess with the project's existing .gitignore. So what's a coder to do?

There are a couple good solutions:

Server Check.in Contest - Win a RØDE smartLav!

Jeff Geerling — Wed, 29 May 2013 00:01:25 +0000

Server Check.in (one of our services) is holding a contest this week: Contest - Win a RØDE smartLav!

All you have to do is post a comment, and you'll be entered to win!

Moving Server Check.in functionality to Node.js increased per-server capacity by 100x

Jeff Geerling — Tue, 21 May 2013 03:27:39 +0000

Just posted a new blog post to the Server Check.in blog: Moving functionality to Node.js increased per-server capacity by 100x. Here's a snippet from the post:

One feature that we just finished deploying is a small Node.js application that runs in tandem with Drupal to allow for an incredibly large number of servers and websites to be checked in a fraction of the time that we were checking them using only PHP, cron, and Drupal's Queue API.

If you need to do some potentially slow tasks very often, and they're either network or IO-bound, consider moving those tasks away from Drupal/PHP to a Node.js app. Your server and your overloaded queue will thank you!

Read more.

tl;dr Node.js is awesome for running through a large number of network or IO-bound tasks that would otherwise become burdensome at scale using Drupal's Queue API.

2013 VPS Benchmarks - Linode, Digital Ocean, Hot Drupal

Jeff Geerling — Sun, 19 May 2013 20:30:31 +0000

Every year or two, I like to get a good overview of different hosting providers' VPS performance, and from time to time, I move certain websites and services to a new host based on my results.

In the past, I've stuck with Linode for many services (their end-to-end UX, and raw server performance is great!) that weren't intense on disk operations, and Hot Drupal for some sites that required high-performance IO (since Hot Drupal's VPSes use SSDs and are very fast). This year, though, after Digital Ocean jumped into the VPS hosting scene, I decided to give them a look.

Before going further, I thought I'd give a few quick benchmarks from each of the providers; these are all on middle-range plans (1 or 2GB RAM), and with the exception of Linode, the disks are all SSD, so should be super fast:

Disk Performance

(I used the command dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync for a simple benchmark, which writes and reads a 512MB file to disk. These results were averaged over three test runs).

Linode: 60.9 MB/s
Digital Ocean: 230 MB/s
Hot Drupal: 244 MB/s

Push your Git repositories to a master server, in a bare repository

Jeff Geerling — Thu, 25 Apr 2013 16:24:24 +0000

GitHub is a great central repository silo for open source projects, and for private Git repositories for companies and organizations with enough cash to afford the features GitHub offers.

However, for many projects and developers, GitHub can be overkill. For my needs, I have many smaller private projects that I'd like to have hosted centrally, and backed up, but don't warrant BitBucket or GitHub accounts. Therefore, I've taken to creating bare repositories on one of my Linode servers, and pushing all my local branches and tags to these repos. That server is backed up nightly, so I know if I lose my local environment, as well as my Time Machine backup (a very unlikely occurrence, but still possible), I will have backed up and fully intact Git repos for all my projects.

I recommend you do something like the following (presuming you already have a Git repo on your local computer that you've been working with):

Step 1 - on your remote server (accessible via ssh)

# Create a 'repositories' directory in your user home directory.
$ mkdir ~/repositories && cd ~/repositories

# For each of your local repositories, make a directory ending in '.git'.
$ mkdir My-Project.git && cd My-Project.git

# Create a bare git repository inside this new directory.
$ git --bare init

Make sure your Linux servers' date and time are correct and synchronized

Jeff Geerling — Wed, 24 Apr 2013 17:29:16 +0000

Nowadays, most people assume that all modern computers and operating systems have network time synchronization set up properly and switched on by default. However, this is not the case with many Linux servers—especially if you didn't install Linux and configure it yourself (as would be the case with most cloud-based OS images like those used to generate new servers on Linode).

After setting up a new server on Linode or some other Linux VPS or dedicated server provider, you should always do the following to make sure the server's timezone and date and time synchronization are configured and working correctly:

Giving Back - Helping with Drupal's Issue Queues

Jeff Geerling — Mon, 22 Apr 2013 18:54:44 +0000

Below is a video and some notes from my presentation "Giving Back - Helping with Drupal's Issue Queues", which I gave to the St. Louis Drupal group at the April 17 meetup. Please post any feedback or additional resources/suggestions in the comments below or on YouTube.

Note: This presentation roughly coincides with the Drupal Ladder lesson, Getting started in the issue queue.
We’ll look at three different ways you can help contribute to Drupal’s success in the issue queues.
Cleaning up an issue queue, testing and reviewing a patch, and writing your own patch.

Clean up an issue queue

Reference: Helping maintainers in the issue queue

Fixing Munin's [FATAL ERROR] Lock already exists: /var/run/munin/munin-update.lock. Dying.

Jeff Geerling — Fri, 12 Apr 2013 16:17:19 +0000

Recently, I upgraded one of my CentOS and Ubuntu servers to a new version of Munin 2.0.x, and started getting an error stating that munin-update.lock already exists:

2013/03/25 23:11:02 Setting log level to DEBUG
2013/03/25 23:11:02 [DEBUG] Lock /var/run/munin/munin-update.lock already exists, checking process
2013/03/25 23:11:02 [DEBUG] Lock contained pid '10160'
2013/03/25 23:11:02 [DEBUG] kill -0 10160 worked - it is still alive. Locking failed.
2013/03/25 23:11:02 [FATAL ERROR] Lock already exists: /var/run/munin/munin-update.lock. Dying.
2013/03/25 23:11:02  at /usr/lib/perl5/vendor_perl/5.8.8/Munin/Master/Update.pm line 128

Munin hadn't been updating for a couple weeks, so I finally deleted the existing munin-update.lock file, and munin started running again. If this doesn't help solve your problem, have a look inside the various munin log files in /var/log/munin/ to see if one of them contains more details as to why munin isn't working for you.

Also, for some reason, munin 2.x isn't working for me on CentOS 5.x, at least on servers where IPv6 is enabled, unless I manually edit one of the main munin config files. I've opened this bug in the munin issue tracker to see if it will be resolved. The errors I get look like the following, inside /var/log/munin/munin-update.log:

Real User Monitoring (RUM) with Pingdom and Drupal

Jeff Geerling — Thu, 11 Apr 2013 14:33:48 +0000

Edit: There's a module for that™ now: Pingdom RUM. The information below is for historical context only. Use the module instead, since it makes this a heck of a lot simpler.

Pingdom just announced that their Real User Monitoring service is now available for all Pingdom accounts—including monitoring on one site for free accounts!

This is a great opportunity for you to start making page-specific measurements of page load performance on your Drupal site.

To get started, log into your Pingdom account (or create one, if you don't have one already), then click on the "RUM" tab. Add a site for Real User Monitoring, and then Pingdom will give you a <script> tag, which you then need to insert into the markup on your Drupal site's pages.

The easiest way to do this is to use drupal_add_html_head() within the page_alter hook (in your theme's template.php, or in a custom module):

Shuttering isthereamoduleforthat.com

Jeff Geerling — Wed, 10 Apr 2013 16:28:53 +0000

I registered isthereamoduleforthat.com on 2010-08-19 for fun—but after three years, and little traffic (besides bots and the occasional Drupal user popping over from an old link), I'm shutting down the site, and will let my domain registration expire.

If someone is interested in the domain, let me know how you'd use it in the comments below, and I'll consider transferring it to you instead of letting it expire and a squatter taking over.