Tag Archives: workflow

Recommendations for per-project time tracking tools

I don’t bill by the hour very much anymore, but I still like to keep rough track of time spent on individual client projects, for my own purposes. I currently use a simple spreadsheet, with tabs for each project/client. Yesterday I asked on Twitter what tools people were using for this purpose:

Here are some responses I got. I can’t personally endorse anything on this list, but it might be a helpful starting point for others.

Using a hosts file for easy management of dev, staging, and production WordPress sites

This recent article at Smashing Magazine discussed trends and challenges in deploying WordPress sites. The biggest issue cited by the article and the lengthy comments that follow is the issue of the database: because WordPress stores strings in the database that contain the site domain (including configuration options and asset paths), it’s hard to migrate content and config between dev, staging, and production environments. A bunch of possible solutions were offered up, including interconnectit/Search-Replace-DB, which I use fairly often and really like.

I was surprised, however, that no one talked about my preferred strategy, which is, in a way, the simplest: Dev, staging, and production should all have the same domain names. When you remove the need to change the domain, you make it much easier to deploy specific pieces of content, spin up new instances, etc.

Since all versions of a site have the same domain name – say, booneisthebomb.com – I use my local hosts file (/etc/hosts on *nix systems) to switch between instances. So I may have the following lines in /etc/hosts:

# Local development
#      booneisthebomb.com

# Staging site
# 123.456.789.0  booneisthebomb.com

With these two lines commented out, going to booneisthebomb.com in a browser will use DNS for the lookup, which is to say it’ll go to the production site. Uncommenting one of the lines allows me to work on the local or staging site.

The biggest pitfall of this technique is that now there is no obvious way to tell your environments apart (and you definitely don’t want to mistake your production site for a dev site). My solution for this is to drop this file into wp-content/mu-plugins/. Then, in my environment file (which contains env-specific config, such as database connection info), I put a line like this:

define( 'ENV_TYPE', 'staging' );

Now, when I load up the staging site, it shows booneisthebomb.com in the URL bar, and the following box appears at the bottom of every page:


Make Github issue numbers appear in browser tabs

#70. Yippee!

#70. Yippee!

I use Github Issues as a bugtracker for a number of my projects. My workflow usually includes having the ticket open in one browser tab, and a local WordPress installation open in another browser tab (to test the bugfixes themselves). When I write commit messages, I want to reference the issue number, but by default, it’s buried deep in the <title> element, and thus not visible on a smallish browser tab.

So I wrote a short userscript that reproduces the issue number at the beginning of the <title>, so I can see it at a glance. It’s structured as a userscript for Greasemonkey/Firefox, though I imagine you could easily repackage it for Chrome or whatever.

// ==UserScript==
// @name        github issue number in tab
// @namespace   http://boone.gorg.es
// @description github issue number in tab
// @include     https://github.com/*/*/issues/*
// @version     1
// @grant       none
// ==/UserScript==

var t, ttext, issueno;

t = document.getElementsByTagName( 'title' );
ttext = t[0].innerHTML;
ino = ttext.match(/Issue #([0-9]+)/);
console.log("#" + ino[1] + " " + ttext);
t[0].innerHTML = "#" + ino[1] + " " + ttext;