Fabric setup for multiple environments

I recently started using Fabric, an automation tool written in Python that simplifies the process of running various commands and scripts on local and remote servers. If you’re managing remote Linux/*nix servers and haven’t tried this tool (or something similar like Capistrano), definitely check it out. The Fabric documentation is great and will guide you through the process of creating simple and complex scripts that can easily be automated to your various servers.

The only part of the documentation that I found lacking was how best to configure Fabric to run on various groups of servers, and how to define those groups of servers for your project. Below is the basic structure I’ve used to do this, thanks to some guidance from the #fabric IRC channel on Freenode (thanks cnf and bitprophet!)

Because I’m storing fabfile.py in the root of my project directory, and including it with my version control system, I’ve pulled the list of environments and servers out to “fabfile_local.py”. Once these are in place, doing an rsync of my local codebase to my staging environment is as simple as:

fab e:staging rsync

fabfile.py:

fabfile_local.py:

Delete Playlists AppleScript

I put together an AppleScript snippet to delete playlist files anywhere under the current directory. Some CD ripping software and music sharing sites include playlist files (*.m3u, *.pls) alongside audio files; if you drag a folder with audio files and playlist files, iTunes adds duplicate copies of the tracks. Solution: save this script as an application and drag it into your Finder toolbar; then run the app on the parent directory before you drag your new music into iTunes.

Basically it’s just running this command on your top-level Finder folder:

find $TARGET_DIR \( -name \*.pls -or -name \*.m3u \) -exec rm -f {} \;

Here’s the code; paste this into AppleScript Editor and save as an application, then you can drag it to your Finder toolbar (or wherever is a convenient place for you to launch it):

Apple HDTV Thoughts

I don’t know if Apple will ever get into the business of making HDTV’s. There are apparently some rumors flying around that the Apple HDTV is coming this year. Marco Arment gives a compelling argument that the profit margins on HDTV’s are not high enough, nor is the product lifetime short enough, for this move to make business sense for Apple. And Apple already has their Apple TV unit, priced affordably at $99, that is a perfect compliment to your existing HDTV. Why even bother with the actual TV display market at all?

I think Apple has plenty of reason to enter this market. While the Apple TV is a great product, I don’t think it’s reached as wide an audience as Apple has hoped. If Apple can design an HDTV that’s as innovative and beautiful as the original iPod was, they’ll sell like hotcakes. The bigger picture here is that Apple wants to start competing with cable TV services with their iTunes streaming products. Once Apple has their software running on a significant portion of TV’s, they can really throw off the gloves and start competing directly with cable and satellite TV providers. The Apple HDTV device itself could almost be a sort of loss leader, or low-margin product that’s simply a vehicle for pushing iTunes out into as many homes as possible.

I’m excited to get rid of current cable/satellite paradigm where I pay $100/mo just to watch 10 hours of sporting events and a few TV shows that I could easily get through iTunes, Amazon or Netflix.

Getting Things Done on Multiple Computers

Things is a great task management app. If you use a Mac and are a fan of GTD, it’s worth a look.

The problem I had initially with Things is that currently, it does not have any sort of support for sharing its library and configuration across multiple computers. This can be overcome using a Dropbox folder as an alternate library location as documented in this DropboxSync wiki. This is great but still leaves one large problem in my mind – Things only seems to write its data to disk when it quits. If you make some changes but forget to quit Things, then open it up on a different computer, you’re probably going to lose some data. I just found a potential solution to this problem: automatically quit Things any time your computer goes idle. Hopefully you haven’t already logged into another machine and launched Things before this happens, and all your data will be safe. I found a nice little open-source project that seems to handle this perfectly: ScriptSaver.

ScriptSaver configuration

ScriptSaver installs as a screensaver and lets you select an AppleScript file to automatically run any time the screensaver is activated. It also gives you an option to then launch a different screensaver after the AppleScript has been launched. A simple AppleScript to quit Things:

tell application Things
    quit
end tell

Paste that into AppleScript Editor and save it somewhere; then point ScriptSaver to that file and you should be set.

Vim, MiniBufExpl, NERDTree and the QuickFix window

Vim has been my editor of choice for many years now, but only recently have I really started tweaking and fine-tuning my configuration and plugins. I was inspired by this HackerNews thread and I now keep my vim configuration in GitHub and synchronized between all my machines. You can even check out a list of my Vim plugins. Some of my favorites, and the ones I’m writing this post about in particular, are:

  • NERDTree, a filesystem explorer
  • MiniBufExpl, an omnipresent buffer list enabling you to easily see what buffers are open and easily switch to and close them
  • Vim Ack, a plugin that provides a simple interface to the excellent Ack utility.

Life is great. Or it was, at least, until I started having strange problems with window layouts when I was waist deep in code. The first lesson I learned is that using Vim’s :bd command to close a buffer causes problems, namely that if you close the buffer in the current window, it will close the window as well. There are two fixes for this. First, after some Googling, I learned about bclose.vim. I mapped <leader>bd to run :Bclose and all was good. I later learned that MiniBufExpl included this functionality all along – simply place your cursor over a buffer in the buffer list and press “d”.

The second problem I ran into was that after using Ack to search through my project, MiniBufExpl would start opening buffers in unpredictable locations such as the NERDTree left vertical window. This was very frustrating and I was only able to get back to a sane editing environment after restarting the Vim session all together. It turns out that the problem was being caused by the way I closed the QuickFix window after browsing through the Ack search results. I was simply using :q, which is my reflex method of closing a window I don’t want around any longer. Some debugging and research shows that the QuickFix window has its rich set of commands, including an open (:copen) and close (:ccl or :cclose). Using :ccl to close my Ack results has solved this problem entirely.

Life with Vim is better than ever. If you’re a Vim user or have even considered it, I’d really recommend checking out some sample vimrc files, finding and installing some plugins you love, and most importantly keeping your configuration synchronized between all of your development machines.

UPDATE: It turns out that :ccl was not the simple fix I was hoping it would be. After using Ack, MiniBufExpl still sends buffers to the NERDTree window. HALP!