Brian's weblog

Another package that appeared in debian today: pastebinit, which is a command-line tool to upload bits of code to some of the various pastebin web servers out there (handy when you want to discuss some code over IRC and don't want to jam the whole thing into the channel.. it is much more polite to put it in a pastebin and then refer to it by URL).

Now what I want is an emacs interface to this, since the code I'd be referring to would always come from one of my emacs buffers anyways.

I've often thought that it would be a great idea to test your test suite by randomly changing bits of code and seeing if the tests catch it. It turns out that other people feel the same way: I just saw a Ruby library named "Heckle" show up in debian sid (the package is named libheckle-ruby). The blurb says:

Heckle is a mutation tester. It modifies your code and runs your tests to make sure they fail. The idea is that if code can be changed and your tests don't notice, either that code isn't being covered or it doesn't do anything.

In a security context, this is similar to an approach thought up by (I believe) David Wagner, Ka-Ping Yee, and Mark Miller, during the security analysis of Ping's electronic voting software. The unusual challenge was that the defined security goal was to be safe against the author of the software, not just the usual malicious attackers (who try to provide bad input, or make the code act in surprising ways). Their scheme was to have one team modify the code to insert intentional errors (or opportunities for mischief), then the second team try to find those errors. If the second team finds other errors, then the code is obviously buggy, and loses. If the second team can't find the errors, then the code is too complicated to analyze, and it loses. If the design of the code is so straightforward that bugs and backdoors stand out like a sore thumb, the code wins.

Of course, this requires really good, really tightly specified unit tests. In my experience, if you're using the right language, a test that specifies the desired result so precisely is effectively your functional code anyways, so you have to be careful to define your tests in some way that doesn't mean you're writing the same code twice.

I don't know Ruby, but I may need to learn enough about it to be able to read this Heckle library and see if it can be ported to Python.

There are a few million gems hidden inside emacs. The two that I ran into most recently are:

C-x r m, C-x r b, C-x r l : these create named bookmarks, each of which records the file that you're visiting and a position within that file. When I need to hold my place while I looked elsewhere, I usually split the window (C-x 2) and leave one of them fixed while I moved around in the other one to find something. Then C-x 0 makes that window go away, leaving me in my original position. But if you do that too deeply, the windows get too small.

C-x r m creates a bookmark, and the name defaults to the name of the file (so if you only use one bookmark per file, you don't even have to type anything). Then C-x r b jumps back to that bookmark. C-x r l lists all your bookmarks.

Bookmarks can also be persistent.

highlight-trailing-space: by setting this to 't', any trailing whitespace will be highlighted in an ugly orange color that makes you want to delete it right away. Darcs does the same thing when you're committing code (it shows you a special "[_$_]" -like symbol to make you aware of the whitespace at then end of the line), so I've been in the habit of deleting that whitespace anyways.. even wrote a little python tool to find it all for me. With highlight-trailing-space turned on, I get to see the whitespace as I'm editing, so I can remove it earlier.