jeff.dallien.net

If I know the number of a Trac ticket I want to see, or if I am interested in a revision I see in an svn blame, then I usually want to go directly to that page in Trac as quickly as possible. To do this I use Firefox bookmarks with keywords.

When I want to see a particular ticket, just type “ticket 12345” in the address bar and Firefox expands that to https://our.trac.site/ticket/12345. I use the ‘changeset’ keyword for source revisions so I type “changeset 52312” which gets expanded to https://our.trac.site/changeset/52312.

To do this yourself, create two new bookmarks in Firefox with the following parameters.

• Name: Trac ticket shortcut
  • Location: https://your.trac.site/ticket/%s
  • keyword: ticket
• Name: Trac changeset shortcut
  • Location: https://your.trac.site/changeset/%s
  • keyword: changeset

Of course the fields can be adjusted to suit personal preferences. This will work for other ticket tracking systems as well, just adjust the location to match the URL your site uses.

The Continuous Deployment strategy used by IMVU discussed in this post (and this earlier one) is very interesting, but the thing that really impressed me was the seriousness with which they approach Continuous Integration.

4.4 machine hours of automated tests running in 9 minutes. Thousands of test files spread over 30-40 machines. I’ve had builds fail because the build server ran out of disk space.

I really like using Remember The Milk to manage various todo lists and a shopping list but the most useful list I’ve created is one to track due dates of monthly bills. I started by creating a separate Bills list to keep the list uncluttered and easy to check with a quick glance. This is done through Settings, on the Lists tab.

Then I started adding tasks to the list, each task being a monthly bill. I set the due date to the next time the bill is due and set the Repeat option to monthly.

Keyboard shortcuts:

• Press d to set the due date of a selected task
• Press f to set the repeat option

After the bills have been added, the top of the list always shows which bills are due next, since the list is ordered by task due date. When I pay a bill, I just mark the task as completed.

RTM then automatically adds a new task, due on the correct day of the next month, no matter what day I marked the current one as completed (paid).

Since I am in the habit of checking my RTM lists for things I need to do anyway, I glance at the Bills list frequently so I know I am on top of what needs to be paid. Plus, it can be reassuring to check and see that the next bill due is a couple of weeks away. Remember The Milk was already useful for managing my other lists but once I got my bills list set up, it became indispensable.

• Remember The Milk
• RTM keyboard shortcuts

A question on Stack Overflow got me thinking that I would like to branch more often while using subversion but two things were preventing me:

• I wasn’t sure how to branch a working copy
• I never took the time to really learn about ‘svn switch’ so branching has always involved a time consuming checkout

So I decided to overcome these two obstacles and since I want to automate things, I decided to spend some time to write scripts to do the work for me. This way when I need to, I can branch and return to trunk with little effort.

I ended up with two scripts which I’ve put on GitHub, svn_wc2b (working copy to branch) and svn_b2wc (branch to working copy). They parse the svn info output to try to find the information needed without requiring me to type it every time.

If I want to branch a working copy I have of trunk, the svn_wc2b script will create a branch for my working copy and svn switch to it. There I can commit my work as needed until its complete. When work is done in the branch, the svn_b2wc script will svn switch back to trunk, merge the branch changes and delete the temporary working copy branch.

The main deficiency the scripts have right now is that they assume the working copy is in trunk and so branching from a branch is not yet supported. I will fix that when I get to a point where I need to do that. I’m hoping to incorporate more temporary branching into my normal processes at work when code isn’t quite ready for trunk, and to share in-progress code with other developers.

• My svn_scripts repository on GitHub

It’s right there in the documentation but since I haven’t seen all of these usages of Ruby heredocs much, I thought it was worth mentioning. The first example is standard, the other two are less common:

<<HEREDOC
This is like a double quoted string
Interpolation happens here. #{1+2}
Backslashes are interpreted as escapes. \a\t
HEREDOC

=> "This is like a double quoted string\nInterpolation happens here. 3\n
Backslashes are interpreted as escapes. \a\t\n"

<<'HEREDOC'
Interpolation doesn't happen here. #{1+2}
Backslashes are not interpreted as escapes. \a\t
HEREDOC

=> "Interpolation doesn't happen here. \#{1+2}\nBackslashes are not 
interpreted as escapes. \\a\\t\n"

<<`HEREDOC`
uname -a
uptime
HEREDOC

=> "Linux kelethin 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 
i686 GNU/Linux\n 21:50:27 up 2 days,  2:25,  5 users, load average: 0.20,
 0.11, 0.03\n"

I’m not a fan of pending specs or, more generally, tests which are present that aren’t being run. When I come across a pending spec, it raises questions but offers no answers.

• Why isn’t this test being run (not always clear from the reason given)
• Is this broken or missing functionality?
• Is this a broken test for working code?
• Was it to test functionality that has been removed?

Ideally we would all use pending specs sparingly, to remind ourselves of things which the application needs to do that we are going to work on soon. In practice with a team of developers this doesn’t always happen. Sometimes a developer doesn’t want to expend the effort to find why a test is failing. A bad idea, of course, but it happens. If you care about your tests you’ll want to know when it happens. Sometimes a (possibly empty) pending spec was written early by a developer thinking that it will probably be required, only to find out later that it wasn’t. Sometimes things like bugs in our tools or larger problems in our application prevent us from testing something we know should be tested so we mark the spec as pending.

When these pending specs are ignored, the uncertainty increases. People forget why something is pending. Everyone just gets used to see the messages go by and having those pending specs there just becomes normal.

I want as little uncertainty as possible. How do we fix the situation and prevent it from happening again? A good way is to make it obvious to team members when specs are marked pending. If everyone notices right away, perhaps someone knows a solution and it can be sorted out immediately instead of weeks or months later.

Initially, to keep a watch on our pending specs, my team at MDLogix started recording our number of pending specs during iteration retrospectives. By comparing our current number from the previous iteration’s we would know that at least we weren’t increasing the uncertainty. When we started tracking the numbers we had 51 specs marked as pending. This only accounted for about 1.5% of all our tests but every one of them could have been hiding something that was broken.

Our next step was to schedule time to actively review our pending specs to decide what action we should take on each one. Doing this was not an immediate need but we felt it would improve the quality of our code and tests. To make sure it got done we decided to create a regularly scheduled block of time for our “important but non-urgent” tasks. For two hours after lunch each Friday all team members work on the same task, which we identify in our stand-up meeting that morning.

We found that some pending specs were for functionality that had been removed when our code base had been extracted from an older larger application. Some actually hid problems that required fixing in our tests and code. Our plan is to reduce the number of pending specs in all the projects for which the team is responsible. Once this happens it will be apparent to all the team members when specs are made pending and we can all make sure the use is justified. We will make sure that any new pending specs will not be neglected!

The press coverage leading up to a Super Bowl often focuses more on the big budget commercials more than the football game itself. Canadians always get the worst of this: they have to hear all the lead up stories about the ads which are going to be aired, and then they don’t get to see them during the Super Bowl!

We have the Canadian broadcasters, the Canadian Radio-television Telecommunications Commission (CRTC) and broadcast rights to thank for that. Canadian networks buy the rights to show US programs in Canada. That also buys them the right to override American network feeds in Canada. That means that even if a Canadian viewer makes sure to tune into NBC to watch the Super Bowl, they will be really watching the CTV (Canadian) feed, like it or not. With the Canadian feed being seen by much fewer people, the ads are much less expensive and similarly less impressive, often just normal commercials seen during any other show.

The CRTC calls this “signal substitution” and it apparently has confused enough people to make them create a Super Bowl-specific page to explain it. Signal substitution happens everyday, but it is not usually a big deal. When does someone actually know and care about what commercials are going to be seen during a particular show? Almost never, except for the Super Bowl.

Although I am in the US right now, I have Canadian satellite (Bell TV, formerly ExpressVu) for my television so I am in the same situation. For at least one previous Super Bowl, ExpressVu had worked some licensing magic to show the US broadcast with ads intact but I see no signs of that this year. I could drag out the rabbit ears and attempt to tune in the game but I think the hassle of finding and keeping a clear signal outweighs the small benefit of seeing the commercials. I’ll just watch them online tomorrow.