Jeet Sukumaran

htop is an interactive process viewer, like top, but greatly enhanced in many respects. The main code base relies on the virtual directory '/proc', which does not exist in OS X. However, thanks to the generosity and smarts of Andy Armstrong, an OS X port is available, and can be cloned by:

With the more recent versions of BBEdit, opening a directory from the command line by using "bbedit DIR" results in a "insta-project". This is pretty useful, in many ways including providing a distinct target for multi-file search-and-replace. However, if you filter the files in the insta-project view in any way, BBEdit inevitably prompts you to save the project before exiting. This, on the other handy, is annoying, especially if you frequently open and close directories from the command-line. This very issue was discussed in the BBEdit forums recently, and Rich Siegal suggested using the disk browsers instead of insta-projects. Disk browsers have all the important ergonomics of insta-projects, without the nagging need to save the projects itself. As note in the discussion, the way to make BBEdit open a disk browser instead of a insta-project when invoked on a directory on the command line is to set the preference by running:

Part 1 of this article described a standard development workflow using Git that took advantage of the distributed nature of the system to maintain a code base across two or three different repositories, including a primary shared "working" code repository and a development "work-in-progress" code repository. Some aspects of this workflow are tedious and reptititive, while others, such as the management of different branches in different repositories can make housekeeping a little more complex. In this, the second part of the two-part series, I present a few simple scripts or tools that, when incorporated into the development ecosystem, go such a long way in alleviating these problems that the whole process quickly becomes a seamless and natural part of the standard routine.

Repository Setup

For most major projects, I have at least two, and sometimes three, remote Git repositories upstream of my local one:

With multiple upstream repositories and branches, and different branches on different upstreams, an enhanced "log" view will help greatly in taking stock of everything.

When you pull and update your local, it would be nice to easily see all the commits that you have applied in the pull. Sure you can figure it by scanning through the git log carefully, but adding the following to your '~/.gitconfig' gives you an easy way to see it in a glance:

The following will enable you to have a Git-aware "cd" command with directory path expansion/auto-completion relative to the repository root. You will have to source it into your "~/.bashrc" file, after which invoking "gcd" from the shell will allow you specify directory paths relative to the root of your Git repository no matter where you are within the working tree.

I recently integrated unit test code coverage analysis (using coverage) as a setuptools command extension into the DendroPy phylogenetic computing library, and thought that I would share how this was done.

The following is an example of how to use the "pkg_resources" module (provided by the setuptools project) to compose a list of all available modules in a Python package.