I ran into an unusual problem in CakePHP recently. A site I'm working on uses CakePHP's internationalization and localization features unnecessarily. The codebase is full of references to the __() function, but they're pointless because the site isn't actually multi-lingual. So I have this capability that I don't necessarily want right now, but getting rid of it isn't trivial and at some point I may have a need for it.

Just about everything comes with a performance cost, and this feature is no exception. Using webgrind, I could see the I18n class sucking up time and resources even though it was doing a whole lot of nothing. I wanted to correct that.

The solution was to create a stub class. If CakePHP sees that a class named I18n has not been loaded, it will attempt to load it. I could have prevented that from happening by editing the file, but that would complicate future upgrades. Loading a stub class which has the same interface but none of the bloat avoids that.

For lack of a better place, I put my stub class in app/vendors/i18n.php and loaded it from the AppController constructor. It contains a single function, translate(), which returns its first argument unmodified. Ordinarily that would be dumb, but in this case it's an optimization.

Webgrind still shows the same number of invocations for the I18n class, but they're taking much less time.

Here's what I'm using to upgrade WordPress:

A WordPress installation can be divided into three parts. The first part involves the core WordPress folders: wp-admin and wp-includes. You normally don't change anything in these folders, so upgrading them can just be a matter of deleting what you've got and replacing it.

The second part involves customized folders. The most important of these is wp-content, since it contains your site's theme and plugins, but you might have other folders that are similarly off-limits as far as upgrading is concerned. Whatever happens during the upgrade process, we don't want to touch this stuff.

The final part involves the PHP files at the root level of the site. These are mostly wp-* files that aren't changed, except for wp-config.php, which is.

Conveniently, the URL for the latest version of WordPress is always the same. I use curl to download it to /tmp because it allows me to pipe the download straight into tar. After deleting the core WordPress folders recursively, I rename wp-config.php and any other custom PHP files (in this example, share-via-email.php) with a .bak extension so that they'll be preserved during the subsequent wipeout of all PHP, HTML, and TXT files in the site root.

From this point, it's just a matter of copying in the new files and restoring the .bak files to their original name. Since the deletion process was restricted to known extensions, the only risk is in forgetting to make an exception for customized files. Version control can help with that, especially if you've accidentally deleted or overwritten something important.

I haven't accounted for .svn folders within the core folders. If you ran this target as-is, Subversion would complain about the sudden absence of .svn folders within the newly-copied wp-admin and wp-includes. This is a great reason for exploring other options like git that centralize all their stuff in a single directory.

One of the most benefical tools I picked up this year is Phing, a build system for PHP based on Ant. I had known about it for a while, but never made much headway because I didn't think I needed to do any building. I already had rsync scripts--I figured I was set. It's just PHP.

WordPress deployment was my Phing tipping point. The first time you deploy a WordPress site from development to staging and realize that the paths inside your database dump are all wrong for is the first clue you need Phing. The next clue happens when you need to pull from production back to development, and face the same problem in reverse.

I had previously been using Bash scripts for this sort of thing. I had one for pushing out from dev, and another for pulling in. Bash scripts are great. The problem is keeping track of them. A few months later I needed to do some maintenance work, but the magical combination of which scripts needed to be run in which order was no longer apparent. Plus, I had done another WordPress project in the meantime and set things up slightly differently. The changes hadn't been propagated back to the first project. Things ended up semi-automatic and half-effective.

Phing clicked for me once I figured out ExecTask was the gateway to rsync. Rsync is crucial for getting files from point A to point B in a sensible fashion, so I always gave up when I couldn't find any mention of it in Phing's manual. Eventually I did find reference to a third-party RsyncTask, but I stuck with ExecTask because it's built into Phing and applicable to just about any shell command you might want to run.

Once you can run shell commands, pretty anything is up for grabs. Phing started to make a lot more sense because it was a standard tool that could wrap the eccentricities of an individual project with consistent behavior. I no longer needed extra bash scripts in my source tree, just a single build.xml at the project root.

Phing is great because it covers the basics but keeps PHP at close hand if you need it. There's not much of a learning curve once you get the hang of declaring and using variables (properties) within the context of XML. If you keep things abstract enough, build targets are pretty easy to reuse between projects. Once you figure out how to flip your WordPress database between environments, the only things that need changing from project to project are hostnames and filesystem paths.

For example, in an earlier post on revving file names, I described a way of using Phing to add hashes to filenames for better cacheing. Dropping that into another project doesn't cause much toolchain disruption because you have one thing orchestrating everything from start to finish, instead of independent scripts each doing their own thing.

That's the part that I was missing. I was managing the build and deployment process every time I needed to make an upate, instead of defining the process once and reaping the benefits of true automation.

In High Performance Web Sites, Steve Souders explains the value of adding a version number to resource filenames so that they are both cacheable and replaceable. In a blog post, he further explains why the querystring is not an optimal spot for these numbers.

To create the version numbers, I've been using a variation on the technique described by Kevin Hale in Automatically Version Your CSS and JavaScript Files. His approach uses PHP to append the modification date of each file to its filename. An Apache rewrite rule allows those dates to be virtual, so that the client sees a path like /css/structure.1194900443.css but the server interprets it as /css/structure.css.

The first time I read Kevin's article, I wasn't keen on the PHP part. Even if the overhead of filemtime is miniscule, why have it there at all? My solution was to define a single PHP constant that could be populated by a build script during deployment, and then appended in all my CSS and JavaScript links. What could possibly go wrong?

If you have one version number for all your files, you end up treating them as a set. That's not good. If you upload some new CSS the new version number will be applied across the board, even to files that haven't changed. That cuts down on the longevity of your cached files, which is the opposite of what we're trying to accomplish. I was generating version numbers from Unix time at the moment of deployment, but the same thing could have happened if I used the most recent source control revision. Each file really needs to be revved separately.

SHA1 to the rescue. Version numbers based on the sha1 hash of each file ensure that a change to one file won't impact the version number of any other file. They're also less fragile than date-based version numbers, which can be changed in the course of copying files around unless you're careful. I also prefer the anonymity of the hashes because they don't reveal anything about a file's age.

I've started using Phing, so generating and inserting the hashes is easy. A FileHash task exists, but I'm using an ad-hoc task for now:

The Problem

When Emacs is launched, its initial window ("frame") is sized and positioned according to application defaults instead of your own preferences. Inevitably, you adjust it to your liking. But this fiddling happens every time Emacs launches and it distracts you from the task at hand. It would be more efficient if Emacs automatically sized the frame according to your expectations.

The Solution

I call this function immediately after defining it so that it takes effect as soon as possible. There's a slight lag between the time Emacs draws the initial frame at its default size and the time the resize happens. It's not instantaneous, but it does happen fast. That's good enough for me, because I just want to avoid unnecessary window fiddling.

Taking things a step further, you could have different window configurations for different circumstances: a large window that occupies the full screen on a laptop and a less wide but taller window for a desktop monitor, or one setup for when you're on a Mac and another for when you're not.

References

I started with the function from Control your emacs frames programatically and simplified it by removing the nosplit parameter, the platform detection, and the hard-coded frame position coordinates. Note that as of Emacs 23, the line (when (equal 'mac (framep frame)) should be (when (equal 'ns (framep frame))

The Problem

To write an image tag, you need to know the width and height of the image. Determining those numbers forces you to leave Emacs and consult another application such as Photoshop or your file manager. Locating the target file is a timesink, as is typing the height, width, and alt attributes. Omitting the width and height can have undesireable side effects and is not a best practice.

The Solution

The function first prompts you for the image file. The usual autocompletion features are in effect, so the typing shouldn't be too onerous. Other than alt text, everything else is automatic. Emacs is figuring out the image width and height on its own, so there's no reliance on third-party tools.

References

1. Elisp Lesson: Writing image-linkify Function

Revisions

• August 8, 2009: Added missing code for relpath function, which is used by img-tag

One thing I've never liked about using Subversion from the command line is that it's tedious to add and remove files. Although the svn status command tells you the state of the files in your current checkout, its output is not used when doing svn add or svn remove. You end up retyping files paths, or copying and pasting. That's not efficient.

A little interactivity would be much more helpful, and that's what svnask.pl provides. It's a short and very simple Perl script that runs svn status, looks for files with a state of "?" or "!", and prompts for a yes-no on whether to add or remove each one from the checkout. Since "yes" is the default, you can operate on a whole mess of files with barely any effort.

Another efficiency problem I've come across with Subversion involves keeping track of multiple checkouts from multiple repositories. I have numerous projects in various states and bounce around from one to another. Sometimes I forget to do a check in, especially if I've only made a trivial change to one file. Weeks can pass before I notice I have outstanding revisions. With svnstatus.pl run daily via cron, this is no longer a problem. The script examines one or more directories and runs svn status, producing an accumulated status report of all known repositories. If there are outstanding changes, cron will deliver the details in an email.

About a year ago, I replaced the Squid proxy on my home network with Apache's mod_proxy. I wanted to continue blocking annoying ads on web pages without keeping an additional service running. It seemed like an obvious choice since Apache was already in the picture and ready to serve.

Things weren't all they were cracked up to be with mod_proxy. Setup and configuration took a lot of fiddling and fusing, and there was a bottleneck somewhere along the way that often made pages load more slowly. I had all sorts of URL rewriting power at my disposal, but not a solution that worked all the time, every time. So I scrapped the whole thing and did without.

Web page ads are still annoying though, and I still want to block them. Now I think I've got the right mix of simplicity and reliability. It's essentially the solution described at Superior Ad Blocking on OS X: add the hostnames of known ad servers to your hosts file, then configure Apache's ErrorDocument to return a blank page rather than the default message.

The one change I made was to point ErrorDocument to a 1x1 pixel GIF rather than an empty HTML page. This prevents broken image icons from appearing, and doesn't appear to create any problems with requests that expect to receive text.

I'm also adding the names of ad servers to my hosts file by hand, rather than grabbing one of the lists available from Wikipedia's page on the Hosts file. This way I'm only blocking the ad servers I've actually encountered, and not hundreds or thousands I'd never otherwise come across (if they're still in fact active).

For the longest time, I've had a cron job running on my server at home that used ipcheck (apt-cache show ipcheck) to update DynDNS with the current IP address of my cable modem. Just in the off chance that said address would change at an inconvenient time, leaving me without a path back to home base.

That script and service did a fine job. Unfortunately, my cable modem's IP address rarely changes. And even if it did, I probably wouldn't be all that inconvenienced. Maybe a little. If the address did change, I'd really only need to know the new one. I'm definitely not in need of any fancy service monitoring. What's the simplest solution then?

If you have a website and access to its access logs, the answer might just be curl. By switching my cron job to something like this:

curl -I -A "hostname of my server" http://example.com < /dev/null

I'll end up with easily identifiable entries in my webserver logs. Using HEAD requests (-I) keeps the request and response lean, and I can grep based on that and/or the hostname of my server. As an added bonus, I also end up with a basic availability heartbeat. If there's nothing in the log files after a certain point in time, something has more than likely gone wrong.

I should have gone this route all along. DynDNS is a better choice when dealing with IP addresses directly would be otherwise inconvenient. But I'm not exactly in that boat.

Gmail allows you filter incoming messages, but it only gives you a couple options on what actions can be taken: Archive, Star, Label, Forward, or Delete. There's no "Whitelist" or "Don't Flag as Spam" option. Which is naturally what I was looking for.

Whitelisting can reduce the chances of false positives-- legitimate messages that incorrectly end up in your Spam folder because Gmail took them the wrong way for one reason or another.

Whitelisting is possible with Gmail, just not in correlation with filters. I didn't realize that messages sent from addresses in your Contacts list were automatically safeguarded; even better, it seems that wildcarding is accepted and can allow you to whitelist an entire domain instead of an individual address.

Features like these are easily missed when you take advantage of Gmail's POP service and do all your writing and responding with another email client.

What about importing addresses into your Gmail Contacts list? AddressBookToCSV worked well for me. It's a script that turns the content of your OS X Address Book into a CSV file that Gmail can import. Only name and email address make it through however.