Code Kills

This is a quickie, but hopefully it'll help someone out there.

I had to setup my laptop so two people could use it to talk on Skype: one audio input (the call), two outputs.

First, I installed Soundflower.

Second, I opened up "Audio MIDI Setup" (/Applications/Utilities/Audio MIDI Setup.app) and created an Aggregate Device (Audio -> Open Aggregate Device Editor). I checked all the output devices, and included the Soundflower device:

Third, I set the system's input and output to Soundflower:

Fourth, I opened up AU Lab (/Developer/Applications/Audio/AU Lab.app) and created a new… thing… with two outputs and one input. After hitting OK the right number of times and getting the main window up, I hit Window -> Show Studio, then selected the Aggregate device on the left. Finally, I checked both the "1" and the "2" on the left side of the "input" to send its output to both output 1 and 2. Some tinkering with the input and output streams (in the Studio) was also necessary.

Finally, in Skype, I set the audio input to the built in microphone (which was fine for me), and everything was peachy!

After writing the last entry, You and Your Editor, I got wondering… What commands do I really use most often?

A few hours of hacking (and a bit of help from Blake Winton) later, I'd like to present: vim-logging.

You can expect a blog post in a week or two, detailing what I've discovered.

It's come up a few times, so I'll just go and post it here: the things, in no particular order, I believe to be the bare minimum you should be able to do while you're editing source code (and how to do them in Vim):

Easily move between files

All but the simplest scripts require more than one file, so you'll often need to switch between them.

Eclipse has two very useful features here: Quick Access (command+3) and Open Resource (command+shift+r):

And in Vim, I make heavy use of multiple windows (:new and :vnew, using custom shortcuts, c-h, c-j, c-k and c-l to move between them) and multiple buffers, using :b. For example, below, I have typed :b url<tab>, then I use c-p and c-n to cycle through the list of matching buffers (I also have <right> and <left> bound to :bn and :bp, making it easy to flip through buffers if I'm not sure what I want).

Jump-to-definition

When you're working with a large project, especially one for which you aren't the only author, it can become nontrivial to figure out where things (classes, functions, etc) are defined. I've found that it's very hard to read source code without a jump-to-definition function because it forces a mental context switch from "figuring out what this code does" to "figuring out where this method is defined", then once I've found where it's defined, "ok, now what was I looking for again?", and once I've finished reading the definition "why am I looking here again?" and finally to "what was the point of this sentence?"

With Vim, I use exuberant ctags to do this.

First, I run ctags -R . to build a tags file, then I access it using :tag, c-] and c-w ] from within Vim. Also useful is c-t: after c-] is used to examine a definition, c-t will take you back to the place you had originally found that definition. Very, very useful.

(note, for this to work properly, make sure :set tags=tags;/ is set in Vim)

Search for/highlight the current word

Often, when I'm reading code, I'll want to quickly look through all the references to some word in the current file (for example, to see where a variable is referenced or how a function is called). This sounds trivial, but I find myself doing it often. Very often. So give it a try before immediately disregarding it.

I do this in Vim using * and # and :set hlsearch (as a side note, I've also got \\ bound to :set nohlsearch).

For example, if my cursor is over load_BufferedImage, then I hit *, I can quickly jump through all the tests which call it.

That's all… For now

That's all for now, but stay tuned – I do love editing text, so I'll probably come back and write some more on this later.

PS: Just to make very sure it's clear, the only editors I mean to bash here are the ones which make it very hard to do the things I've talked about (nano, notepad, etc)… Every decent editor can do these things, you've just got to learn how.

PPS: If you don't already use it, Vim has a great built-in help system. Access it with :help {subject}. For example, :help vnew or :help <c-w>.

PPPS: Todd has posted a followup, Worthwhile vim tips – they are a bit more basic, but even more important than the things I've talked about here.

The problem? Twitter is full of spam. Don't believe me? Just mention 'hosting' and you'll get anonymous messages suggesting "a comparison of the top ten hosting services".

A possible solution? Hashcash.

For example, assume @spammer wants to follow @wolever. When @spammer sends the HTTP POST to Twitter saying, for example, "add_follower": "wolever", they must also submit a string, s, such that the first 8 bytes of sha1('spammer wolever' + s) are 0. For example, "add_follower": "wolever", "hashcash": "blahblah", if sha1('spammer wolever' + 'blahblah')[:8] == "00000000".

Of course, this is just a rough example: in reality, the "cost" of the hashcash (ie, how many leading zeros are required) should be based on something like the spammer's blocked/following ratio (that is, the number of people who have blocked them over the number of people they are following), or something more elaborate… But, hopefully, the idea makes sense.

One thing that has bugged me about testing Django apps is that I couldn't figure out how to override the global URL settings, which meant that app tests were tightly coupled with the global URL scheme.

For example, to test the adder app, I used Client calls like this:

resp = Client().get("/toys/calculator/adder/1+2")

Which were, of course, totally lame because they a tight coupling between the adder app and the project it lived in.

But there is a better (albeit poorly documented) way: overwriting django.conf.settings.ROOT_URLCONF!

There are two ways to do it: hand-rolling a solution, or using TestCase.urls.

Here is a quick example of both. First, using TestCase.urls:

import adder

class AdderTests(TestCase):
    urls = adder.urls

    def test_adder(self):
        resp = Client().get("/1+2")

And then, the hand-rolled solution I've been using with django-nose:

_old_root_urlconf = [ None ]
def setup_module():
    _old_root_urlconf[0] = settings.ROOT_URLCONF
    settings.ROOT_URLCONF = urls

def teardown_module():
    settings.ROOT_URLCONF = _old_root_urlconf[0]

def test_adder():
    resp = Client().get("/1+2")