Dotfiles and Dropbox

I am generally not a fan of extensively customizing my tools or work environment. If the benefit isn’t significant, I’m not going to spend my time monkeying around with settings and configuration files and screens of options: they get in the way of actually being productive. vim is one of those tools that’s so useful to my workflow that a bespoke configuration is worth the effort — but only if I can make that configuration as trivially ubiquitous as vim itself.

Up until recently I’d used Subversion to store all my vim (and other) configuration files. This is a reasonably common practice. But I’ve had two issues with this approach. First, I had a few makefiles (or batch files for Windows) that I used to sync the contents of the repository to to appropriate locations on each type of machine. I did this largely to keep my home directories clean, but having to maintain them — even in a limited capacity — was obnoxious. Second, I had to remember to actually commit any changes I made back to the central repository. On a number of occasions I made some tweak at work, went home, and realized I’d failed to commit. A minor annoyance, but an annoyance nonetheless.

This is why I decided to try storing the configuration using Dropbox. Since Dropbox storage is accessible like a local directory, I could easily create symbolic links to the .vimrc file and .vim directories stored in my Dropbox drive on all my machines. This means I don’t have to manually commit any local changes back to the repository. It also obviates the need for the synchronization makefiles; while they provided a bit of a buffer for changes, which was occasionally nice, they existed largely to keep the temporary cruft created by a Subversion working copy out of my home directories. That’s not a problem with Dropbox.

So far I’ve had no trouble using this approach, and the additional streamlining is a huge boon. I was very pleased, in particular, that the symlinks worked out so well. My fallback was to create shim .vimrcs that set $VIMRUNTIME and sourced the Dropbox version of the file, but fortunately I didn’t need to.


SlimDX June 2010 Released

Actually it was released last week, when it still was actually June, so I’m a little late to this party. Mike did the official release thread on GDNet this time around in which he calls out the major changes, including .NET 4.0 support, cleaner access to the shader compiler interfaces, and a much more robust


Canlis

Canlis is a restaurant in Seattle’s Queen Anne neighborhood, overlooking Lake Union. The restaurant has been operating since 1950, when it was opened by Peter Canlis, and is run today by Mark and Brian Canlis, Peter’s grandchildren. Since its inception, Canlis has maintained a reputation of being among the fanciest restaurants in the area, as


C Strings Are Evil

GDNet community manager Washu has written about the perils of C-style strings for beginners (in C++). In his post, he covered a variety of excellent points, but he missed one of my favorites: C-style strings are not a type. A C-style string is just an interpretation of an actual type (a char*) that adds some