Changing User-Agent in Google Chrome

Here’s a Google Chrome pro-tip for you.  It’s easy to change the user-agent in Google Chrome dev builds with no extensions necessary:

1. Open the inspector – by right clicking on any page and clicking “Inspect element”
2. In the bottom right click the “Settings” gear
3. Click into the “Overrides” tab
4. Check user-agent, and select the one you want

Awesome time-saver, especially for those like me who hate installing extensions.

Dependency Injection in JavaScript Tests

When you’re writing tests in Node, its often useful to be able to stub out modules which are included by the object you’re attempting to test.  Unfortunately due to the way that the module system is structured, its not straightforward to do this in a single test (as opposed to globally).

There are a few solution for this dependency injection problem around, namely node-sandboxed-module and injectr.  These modules use node’s vm module to create a new context that they run the test inside of, and in that context they use the mock instead of the original when calling `require`.  This is a nice solution, but unfortunately by bringing the code into a new context, you also break code analysis tools like mocha’s html-cov.

A few days ago, Matt Morgan released a module called mockit, which approaches the problem instead by temporarily replacing `require` when requiring the dependency the test needs (as opposed to trying to replace it for the duration of the test).

Imagine you had a `Downloader` class, and you wanted to use it in your tests, but have it so that when `Downloader` called `require(‘http’);`, it got a mock instead of node’s http class.  You could do that with one call to mockit:

var Downloader = mockit('../lib/downloader', {
  http: mockHttp
});

I think this is a really nice solution to this problem – totally unobtrusive and uses node’s existing `require` functionality when no mock exists. Check it out!

Git Bash Completion and Detail

One of the things I can’t live without is git bash integration in my $PS1.  This gives me feedback on the branch and status of my current directory.  Here’s an example screenshot:

So how do you get this set up?  Here’s how I do it (in ~/.bash_profile):

GIT_COMPLETION_PATH=/etc/bash_completion.d/git
if [ -f $GIT_COMPLETION_PATH ]; then
  . $GIT_COMPLETION_PATH
  GIT_PS1_SHOWDIRTYSTATE=true # */+ for dirty
  GIT_PS1_SHOWSTASHSTATE=true # $ for stashes
  GIT_PS1_SHOWUNTRACKEDFILES=true # % for untracked
fi

And then you can just include the git completion function in your $PS1 where you want it. My $PS1 is super simple, and just has this and the current path (and some nice colors):

export PS1="\e[0;33m\w\e[0;91m\$(__git_ps1 ' (%s)')\e[0;96m \$\e[0m "

Note: the location of your git bash_completion directory may be different (especially if you installed git via homebrew).  I like to solve that with a symbolic link, instead of changing this configuration (I just find it cleaner that way – much nicer for upgrades too):

git -> /usr/local/Cellar/git/1.7.9.6/etc/bash_completion.d/git-completion.bash

If you like this – read more of my dotfiles

Git Tip: Viewing a Git Stash

I use `git stash` very often to set some code aside while I work temporarily in another branch.  Sometimes, I want to peek at what I have stashed instead of taking it out.  You can do that very easily with `git stash show`:

git stash show -p  # view a diff

Sopatrack Update

With this whole CISPA mess heating up, I thought it’d be good to write an update post (here’s the original) about a recent update that was made to Randy’s site, Sopatrack.

With the new update, comes a lot more data to view, and the expansion (despite the name) beyond SOPA to other bills in Congress.  The re-design really helps to make the raw data more clear.  My favorite page is the bills page, which breaks down funding on supporting and opposing sides for each bill.

Check it out, and keep your congresspeople responsible!