Some Random Blog

It's almost exactly a year late, but I stumbled upon the video for the RailsConf 2006 keynotes. I'm hoping (and expecting) that they do something like this again for the RailsConf that just occurred last weekend, since I wasn't able to go. The keynotes for last year's conference were really good. I've never really been a huge fan of Paul Graham, but his keynote was excellent, as was Martin Fowler's keynote on "Why Ruby?"

It's hard to find the time to watch hour long videos, but I do have an hour-long bus ride to work. I figured transcoding the video into audio would be a good idea, so that I could listen to the talks on my Shuffle. This turned out to be much easier than I expected. It was trivial to get Quicktime Pro to export the audio to WAV, after which I could just add the WAV to iTunes, right-click, and convert to AAC. Checking the "Remember Position" option for the AAC track is crucial, of course, for an hour-long talk. A few minutes after having the idea to listen on my iPod, I had a few hours of smart people to keep me busy on the long traffic jam we call the 520.

Recently I've been hearing more and more about automated "mutation testing" tools such as Jester (for Java) and Heckle (for Ruby). These are tools that will try to break your code by doing things like changing the truth values of clauses of if statements, modifying immediate values, changing array indices, and returning bad data, then running your unit test suite on the modified code. If the modified code passes your test suite, then chances are your test suite is either lacking coverage or you have dead code.

Now, I love automated tests. It's not just the bugs I catch early or the debugging time I save or the live documentation aspects of the tests, but the confidence having my code fully tested gives me to work with and refactor the code to make it the best code possible. However, I could never shake the feeling that this confidence was a little misplaced, especially when I discovered bugs in the tests or code that wasn't being tested despite coverage numbers being high.

It was always hard when I'd evangelize unit testing and people would ask, somewhat sarcastically, "How do I know the tests are right? Do I have to write tests for the tests?" It always seemed to me to lead to an infinite regression of questions that I didn't have the answer to.

Luckily, someone (or some group) was smart enough to come up with the idea of brute-force testing tests, and I think these sorts of tools will lead to code that can be considered "correct" for all real purposes without resorting to formal methods. My somewhat shaken confidence in my unit testing tools can be regained.

I haven't had the chance to play with these tools in-depth yet, but I'm definitely going to use them on my next project. I'll probably talk more about them then.

Blogging from TextMate is really cool.

I've been using Subversion for years on my own machines to manage documents, code, and everything else I didn't want to get lost. It wasn't a perfect solution, because I needed the host machine to be turned on and on the network all the time (easier said than done) and I also needed to have the Subversion server running (which is pretty much how I learned launchd).

When I moved to a shared host that offered Subversion access, I saw how easy svn+ssh could make things. Svn+ssh will automatically spawn a svnserve process upon access using an svn+ssh:// URL, meaning the Subversion server doesn't have to be running constantly on the server machine.

Passwordless login over SSH is really cool, and it's really simple to get it working with Subversion. Right now, I have Subversion "owned" by a single user on the server, and I manage permissions using SSH keys.

First, I created a new ssh keypair, to be specifically used with Subversion:

$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/justin/.ssh/id_rsa): /Users/justin/.ssh/id_rsa.subversion etc...

I then copied the contents of ~/.ssh/id_rsa.subversion.pub into the Subversion owner's ~/.ssh/authorized_keys file. This is enough to get svn+ssh working, but you'll have to use a command like this, passing in the full path to the repository:

$ svn ls svn+ssh://user@server.com/full/path/to/repository/application/trunk

I think you'll also have to specify the username/password on the command line as well, if you can commit to the repository as an alternate user at all. Finally, this can be dangerous, as it leaves the user account open to all users you've given access to.

However, adding something like the following in the ~/.ssh/authorized_keys file, on the same line as the public key you added earlier, will solve these problems:

command="/path/to/svnserve -t -r /full/path/to/repository/ --tunnel-user=user_name",no-port-forwarding,no-agent-forwarding, no-X11-forwarding,no-pty

This will connect to the repository at /full/path/to/repository/ with Subversion user user_name, disabling most of the other stuff the user would be able to do on the server.

The last thing I did is set the SVN_SSH environment variable on my local machine to point toward the key created earlier, which I did in my ~/.profile:

export SVNSSH='ssh -i /Users/justin/.ssh/idrsa.subversion'

After following these steps, you can test it out using

$ svn ls svn+ssh://user@server.com/application/trunk

That command should now work without requiring a password, or the svnserve server running on the remote machine.

I'm still having one issue with my setup -- when I give svn the root path, like:

svn ls svn+ssh://user@server.com/

I get an error:

svn: Syntax error parsing revision 'server.com'

So far I haven't found a way to resolve this that I'm satisfied with, but in reality it's not really a problem -- how often do you really access the root of your repository, anyway? If it's common, chances are the repository isn't laid out very well.

I finally started reading my beta version of Joe Armstrong's Programming Erlang and I'm right about where the good stuff comes in -- concurrency.

There's some things I like and some things I don't like about the language so far, which I'll get to when I understand the language a little bit better. There's one thing that surprised me, though: Is make really the tool most Erlang developers use to do their builds? I mean, I assume build order isn't really as big of a deal with Erlang as it is in some languages, but make is one of those tools I couldn't help but get frustrated using. It turned me off of things that use "significant whitespace" completely, and that's one of the reasons I never could get into Python.

Maybe build management isn't a huge deal in Erlang, or it's just a temporary lack of tool support, but I hope it's not something I'll have to deal with often.

Or maybe I can just use Rake.

As you can hopefully see, I got a new domain set up for my Linode virtual server, so I can show off all the awesome stuff I've been working on. Not having to use my laptop as a Subversion server anymore is nice, too.

It was a lot more difficult than I expected, mostly due to my first attempt to buy a domain name through 1and1 (since I heard they were cheap, and so am I). Unfortunately, it looks like 1and1 doesn't allow wildcard subdomains, which is kind of a killer for me. I like being able to host each application on its own subdomain, so I'm not doing crazy path rewrites in my Rails apps. I also wasn't a huge fan of their domain management dashboard, it seemed more geared toward managing shared hosting than managing domains pointing to off-site locatons.

I figured I'd try someone else, and went with GoDaddy for the domain you see above. This worked much better, and I got it set up within about 12 hours (would have been less, but I accidentally got rid of the default A record and had to fix that. Unfortunately, the other domains I bought won't be transferred to GoDaddy until the waiting period is over, but other than that, I'm really happy with the way everything's set up.

Next steps: Installing Trac, and deploying an application. This is so much better than shared hosting it's not even funny.