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:

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):

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.

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

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.

• 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!

Usage:

<?php

require 'tidyjson.php';

$json = '{"foo":"bar","baz":[1,2,5]}';
$tidy = TidyJSON::tidy($json);

?>

To start using it, download svn-growlnotify from github, copy svn-growlnotify.sh somewhere so you don’t lose it, make sure it is executable (chmod +x svn-growlnotify.sh), and set up a crontab entry to run it with your repository URL:

* * * * * /path/to/svn-growlnotify.sh -s http://your.repository.url/ 1>/dev/null 2>&1

Here’s the source code:

This system works very well, but when we switched to Windows Vista we started having intermittent issues on various workstations. TortoiseSVN, our svn client of choice, will occasionally fail with an “Unauthorized” error or other similar error message when doing a commit. We noticed that this normally happens during a longer commit, and TortoiseSVN will usually re-prompt for a username/password partway through the commit before failing. I’m not sure why, but sometimes Tortoise will use the Windows user’s credentials to access the repository, but sometimes it will prompt you to enter a username/password. In order to avoid getting the error message, you need to ensure that, if you are prompted to re-enter your username/password, you use the exact same string (matching case) that was used initially. If the strings dont’ match exactly, the commit will fail because it thinks two separate authors are sending the same commit.

I’m mostly posting this for my own reference because I keep forgetting exactly what’s causing this strange problem.

Another key when setting up SVN with LDAP on a Windows domain is to create a group for each user – including all possible permutations of that user’s username

username = DOMAIN\Username, DOMAIN\\Username, Username, DOMAIN\username, DOMAIN\\username, username

MyGroup = @username, @otherusername

[/MyClient/MyProject]
@MyGroup = rw
* =

Comments, suggestions? Let me know. Want to help me out w/ a decent design? Go for it!