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.

To solve most problems, you can just throw everything inside of a set single quotes. The shell won’t touch anything inside and you’ll be all good.

$ echo "$hello world" # " world" # or something worse
$ echo '$hello world' # "$hello world"

Then the one remaining question is what to do if you want to include a single quote? Your first inclination may be to escape it with a backslash:

$ echo '$hello \' world' # incomplete

But that’s not how it works :( The way you actually have to go about this is to stop the single-quote pair, escape a single quote, and then start it back up. Here it is:

$ echo '$hello '\'' world' # "hello ' world"

—

As a bonus, if you try to do this substitution in Ruby, you may try something like:

var = 'hello \' world'
var.gsub('\'', '\'\\\'\'') # "hello ' world' world"

Wat!? That’s not what you wanted! Read that documentation!  Let’s try again

var.gsub('\'') { '\'\\\'\'' } # "hello '\\'' world"

There we go! Make it a little prettier even:

var.gsub("'") { %q{'\'} }

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!

The closest thing JavaScript has to a callstack is the 10-frame backtrace that comes along whenever an error is generated.  So we can use that to our advantage, by generating an error on-demand, catching the response, and examining the #stack attribute of the thrown error object:

function callstack() {
  try { capture.error } catch (e) {
    return e.stack;
  }
}

Normally we’d have to stop there, and if we wanted to access that data programatically we’d have to parse the pre-formatted String that comes back.  But with V8 we have a better option!  V8 gives us access to the method that prepares the preformatted response, so by temporarily replacing it – we can return the original data instead.  Check it out, here’s a small node.js module:

var replacementPreparer = function (error, trace) {
  return trace;
};

module.exports = function () {
  var capture;
  var oldPreparer = Error.prepareStackTrace;
  Error.prepareStackTrace = replacementPreparer;
  try { capture.error } catch (e) {
    capture = e.stack;
  }
  Error.prepareStackTrace = oldPreparer;
  return capture;
};

And the usage:

var callstack = require('./path/to/callstack/js');
for (var i = 0; i < 1000; i++) {
  callstack(); // use this anywhere in your code
}

When you call `callstack`, you’ll get back an array of CallSite objects upon which you can call methods from the V8 API to get at all the juicy details: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi

In Ruby, we can write a conditional containing a single expression that normally takes up three lines:

unless condition
  something
end

on a single line to save space:

something unless condition

And that is all well and good – these two are pretty much the same.  But they’re not identical in practice. There are a few weird things about to come up.

Our first example will be using defined? to conditionally print a variable

if defined?(var1)
  puts var1 # never runs
end

var1 # NameError: undefined local variable

So that works just as we’d expect. The conditional never runs because defined?(var1) returns nil. After the conditional, access the undefined var1 gives us a NameError because (appropriately) its not defined. Let’s modify that a little bit and put an assignment inside of the conditional.

if defined?(var2)
  var2 = 5 # never runs
end

var2 # nil
defined?(var2) # "local-variable"

So that might look a bit odd.  We never ran the conditional, so var2 never gets set – that makes sense.  But after the block, var2 doesn’t throw a NameError when accessed anymore. This is because the Ruby parser makes room and defines var2 when it sees it on the lefthand side of an expression (even though its inside of a conditional that doesn’t run).

Let’s write the same on one line though:

var3 = 5 if defined?(var3)

var3 # 5

Even more interesting – an undefined variable written this way will become defined and assigned when run.  The first thing that happens is that the parser comes along and defines var3 which it sees on the lefthand side of a conditional.  Then defined? runs, which this time evaluates to "local-variable", causing the conditional to pass, and 5 to be assigned to var3.  In cases like this, the single-line conditional will produce an entirely different result than block conditionals.

JSON stores data in sets of enclosing braces that are extremely readable, but not really optimal computer to read.  MessagePack gets its optimizations by putting all of the data needed to know the size of a data structure at the front of it.

So JSON thinks like:

[ # square brace - i'm about to read an array
  "one", # read until the end ", then saw a comma - there must be more elements
  "two"  # read until the end ", no comma
] # square brance - i'm done reading an array

And MessagePack thinks like:

\x92 # a dictionary is coming with 2 elements
\xA3 # the first element is a string with 3 letters
one  # 3-letter string
\xA3 # the second element is a string with 3 letters
two  # 3-letter string

So that’s really cool – and there are implementation for a lot of languages. But I couldn’t stop. How much smaller does MessagePack makes things practically – and how much faster is it?

Length

I figured I’d compare a few common structures with the two libraries and see how things came out.  I was also very interested to see how each library’s output compressed with gzip.

So I started off with a Facebook profile – Its a large Dictionary/Array mix of data with generous amounts of integers and strings mixed in.  A great test subject for a common case.

== Full facebook profile ====
MessagePack length: 1990* (973 compressed  - 49%)
JSON length:        2441  (955* compressed - 39%)

So on *this* data, although MessagePack is smaller, it didn’t compress by the same amount and thus the JSON compressed version was smaller.  This is extremely interesting, but not entirely surprising if you think about the amount of information that’s repeated over and over in JSON (specifically common patterns like “},{” which MessagePack doesn’t have.  That against the fact that MessagePack has an large number of identifiers that mean “Array” because the identifier mixes in information about the length of the structure.

A friends list from Facebook would be an interesting subject too – since its a large array of 2-element arrays.

== Facebook friends list ====
MessagePack length: 21848 (9482 compressed - 43%)
JSON length:        27653 (9149compressed - 33%)

As predicted, MessagePack does a better job compressing data like this – because its identifier for Array also contains the length of the array about to come.  JSON is still smaller compressed here – but let’s push this further.  Let’s throw a structure at each that is a 100-element array of 100 7-letter words.

== 100 groups of 100 7-letter words ====
MessagePack length: 80303 (49152 compressed - 61%)
JSON length: 100201 (51726 compressed - 52%)

MessagePack compressed just as we thought – and now has edged out JSON.  Let’s do the same with arrays of 7-digit numbers (just for fun)

== 100 groups of 100 7-digit numbers ====
MessagePack length: 50303 (36585 compressed - %73)
JSON length:        80201 (36898 compressed - %46)

Speed

For me, Speed is where I’m really excited about what MessagePack could be capable of.  So I started comparing the performance of the Ruby MessagePack library (written as a C extension) to YAJL (also with C bindings to YAJL).

On the same Facebook profile as above, I benchmarked encoding and decoding over 100,000 runs each.

== Encoding ====
user system total real
json 6.360000 0.120000 6.480000 ( 6.468930)
msg 4.480000 0.010000 4.490000 ( 4.481516)

== Decoding ====
user system total real
json 15.040000 0.270000 15.310000 ( 15.290871)
msg 13.180000 1.530000 14.710000 ( 37.719052)

Conclusion

I will absolutely be using MessagePack when storing data either uncompressed, or with large amount of repeated structure sizes.  It obviously won’t work for anywhere you’d like the data to be human-readable, but is an amazingly brilliant idea with great execution.

Check it out!

The code used to generate these numbers: https://gist.github.com/3188573

Brewster is a personalized address book for iPhone.  It takes all of your contacts from the social networks you’re part of and mixes them with contacts from more traditional places like your address book and your Google Contacts.  It gives you an amazing unified view of the people you know, and how you know them.  You can search across all of your contacts, sort them into lists, and gain insight into how they’re connected.

If you haven’t checked it out yet – head over to the website and download the app today!

• Brewster on Twitter
• Brewster on Facebook

I thought I’d do a post to provide some more context of how laze fits into my workflow in a node.js project.  There are definitely some terrible things you can do with this library, but hopefully this post will outline the intended use and convince you to try it out.

Imagine I want to create a new server, and then start listening on a given port.  I start out with some really tightly coupled code:

Server.prototype = {
  start: function () {
    var host = this.config.host || '127.0.0.1';
    var port = this.config.port || 8080;
    var server = http.createServer();
    server.on('request', this.handleRequest.bind(this));
    server.listen(port, host);
  }
};

This code works well, but in my opinion it just does way too much.  In here, we have logic for:

1. Handling how to pull the host and port out of our config – and what to do if they’re not set
2. Creating a new server
3. Binding our server to another function for requests
4. Starting the server listening on the given host and port

Imagine we want to start splitting this function up a bit.  We’ll start with pulling the host/port configuration out.

Server.prototype = {
  getHost: function () {
    return this.config.host || '127.0.0.1';
  },
  getPort: function () {
    return this.config.port || 8080;
  },
  start: function () {
    var server = http.createServer();
    server.on('request', this.handleRequest.bind(this));
    server.listen(this.getPort(), this.getHost());
  }
};

So this works pretty well actually – but if somewhere else in this object we’d like to have access to the host and port, we’re re-running the logic inside of `getHost` and `getPort`.  Not a big deal for these quick functions, but something that did a bit more would make that approach just wasteful.

So we could proceed in one of two ways:

Call getHost and getPort from the constructor

var Server = function () {
  this.host = this.getHost();
  this.port = this.getPort();
};

If we call the two methods from the constructor, we can have properties set that contain the proper host and port.  This is nice – but crowding our constructor with calls to methods that aren’t needed *unless* start gets called.  You can see that if these were time-intensive tasks – we’d end up wasting time for methods that may not be called at all.

Call getHost and getPort from `start`

Server.prototype.start = function () {
  this.host = this.getHost();
  this.port = this.getPort();
  var server = http.createServer();
  server.on('request', this.handleRequest.bind(this));
  server.listen(this.port, this.host);
};

This approach is good – its made our start function a bit more complicated but the separation is correct.  The one remaining problem with this approach is that if another method wants to access `host` or `port` before `start` has been called – they’ll both be undefined.

Another Option: Lazy Attributes

Laze uses `defineProperty` to give us another option.  We can define properties that won’t be set until they are used.  Then we get the best of all worlds.  The host or port can be called at any time and have the proper values.  And – once they’re called one time, they’ll hold onto their value for the next time without recomputing it.  Let’s take a look at the code:

Server.prototype = {
  start: function () {
    var server = http.createServer();
    server.on('request', this.handleRequest.bind(this));
    server.listen(this.port, this.host);
  }
};

laze.defineAll(Server.prototype, {
  port: function () {
    return this.config.port || 8080;
  },
  host: function () {
    return this.config.host || '127.0.0.1';
  }
});

If you want to – you could take this whole thing another step, and make the creation of the server lazy too.

Server.prototype = {
  this.server.listen(this.port, this.host);
};

laze.defineAll(Server.prototype, {
  port: function () {
    return this.config.port || 8080;
  },
  host: function () {
    return this.config.host || '127.0.0.1';
  },
  server: function () {
    var server = http.createServer();
    server.on('request', this.handleRequest.bind(this));
    return server;
  }
});

I hope this post gave a good overview of using lazy attributes in JavaScript with laze – if you’re interested in reading how it works check out the code (which is pretty simple), or go straight to the github page.

You can also install laze via npm:

npm install laze

# of People who make excuses to not do something is greater than

# of People who talk about doing something is greater than

# of People who attempt to do something is greater than

# of People who do something

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 stash show -p  # view a diff

post :photo, :file => File.open(path)

You’ll actually be sending the string “<File:…>” down as a request parameter.  What you actually want is a bit more obscure, but works perfectly:

post :photo, :file => Rack::Test::UploadedFile.new(path, mime_type) # text/jpg

TV is a pretty exciting space, looking forward to what’s coming next – seems like it may be one of the next big battlegrounds as we head towards making computers even more ubiquitous.

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!

1. An optimization can be made by taking advantage of the lock’s imperfect positioning, and instead of trying every number, trying every other number first.
2. Based on where 1 spin ends, you can make the next move you choose to make start close to the end position of your last move.
3. The last turn, you can spin the lock and continually attempt opening, without re-trying the combinations.

So, my hopes are that with these optimizations, I can go from:

• 1st dial – 40 possibilities
• 2nd dial – 40 possibilities
• 3rd dial – 40 possibilities
• 40 * 40 * 40 = 64000 combinations

To:

• 1st dial – 20 possibilities
• 2nd dial – 20 possibilities
• 3rd dial – spinning as I go
• 20 * 20 * 1 = 400 combinations

I’ll post here updates as I have them, and hopefully soon we’ll have a cool combination lock unlocker.

Check it out!

#caller returns an Array representing the current call stack, where each element is a String like “file:line in ‘name’”.  Here’s an example:

def actually_do_it
  caller.join("\n")
end

def do_it
  actually_do_it
end

puts do_it

which will output:

ex.rb:8:in `do_it'
ex.rb:11:in `<main>'

Often when I turn something into a gem, I want to work on my application and its dependency at the same time.  For that reason, bundler let’s you declare dependencies by path, instead of rebuilding:

If a normally line in your Gemfile looks like:

gem 'autodoc'

you can specify a path as an argument to `gem` like:

gem 'autodoc', :path => '/Users/john/Development/autodoc'

:GitLog

Will open a git log in a new buffer of the changes to the current file

:GitBlame

Will open a vertical buffer containing the line-by-line blame of the current file

:GitDiff

Will open a buffer next to the existing buffer, with its current diff