Productivity Boost on Macs with Quicksilver

Here’s a quick post about enhancing your productivity in OS X. Along the lines of the Vim philosophy, that it should be easy to navigate between things and you shouldn’t need to reach out for the mouse, I’ve set up a simple workflow that I use to switch between open applications at a blazing speed.

I use Quicksilver, which is a free app for the Mac platform. It enables you to set system-wide hotkeys that don’t only open an app, but also shift focus to an already open app rather than open a new instance of it (something that annoys me endlessly with application launchers on Linux). The Mac keyboard is so structured that it’s easy to type Cmd+Option – those are the only two control keys to the right of the space bar. These two can be combined with any key to the left of the keyboard to set up a shortcut that’s easy to type with two hands. You can have a similar setup with Ctrl+Cmd+Option (to the left of the space bar) and a key to the right of the keyboard. You can pick a letter depicting an application, e.g. W for Webstorm, and use it like so: Cmd+Option+W and voilà, it comes to the foreground (or opens if not already open). The best of course is being able to use just the Ctrl key (you have mapped the Ctrl key to be used in place of Caps Lock, right??) – Ctrl+F for Finder, Ctrl+B for my browser, etc. But you also don’t want to override some of the shell shortcuts like Ctrl-a, Ctrl-c, Ctrl-c etc. Enter multiple control key combinations like the example above for Webstorm. Or you could do Ctrl+Cmd+Option+o for Omnifocus, for instance.

Attached is a screenshot of my current configuration. Set this up, and you’ll never go back to switching between apps using Exposé, Option+Tab, or the mouse ever again.

My setup with Quicksilver triggers

Happy app-switching!

Package Management on OS X

This post is, as a matter of fact, written more for my own personal reference than for instructing others on something new, because others have already written about it (see here, here, and here).

In short, OS X does not have a package manager like apt-get. However, neat solutions exist, in form of Macports, Fink and Homebrew. As noted elsewhere, Fink is the older system that downloads binaries, while Macports installs and compiles everything natively on the machine on which you are installing something. To that end, Macports needs its own libraries, so it might download and keep its own version of Perl, Python and several other libraries on your system (typically under /opt/local/) – which as you might imagine can cause a lot of redundant stuff  to be present on your system. Homebrew is the cleaner solution, in that it uses libraries that OS X already has installed – so it’s faster and doesn’t download the Internet on your computer if you want to install something.

The downside of Homebrew is that it does not have every package you might be interested in, while on the other hand Macports tends to have it all available, including modules for a particular language, e.g. pandas, IPython, numpy and scipy for Python.

I therefore tend to prefer Homebrew if a package is available under Homebrew, and fall back on to Macports for stuff it does not have. Which tends to be pretty often, and which also in turn brings us back to the issue that Macports, being all ‘self-reliant’ as it is, tends to keep a ton of files on your system.

It’s necessary as well as good practice to clean your system from time to time to remove packages that you no longer use, or packages or files that are intermediate or inactive on your system. I’m using material I found in one of the pages linked above, and have a simple script that does the cleaning for me when I want.

Last I checked, I gained almost 2GB of hard-disk real estate on my computer when I did the cleaning. Highly recommended!

Using NUnit and C# with Mono and MonoDevelop on OS X

This is a quick post highlighting how to use NUnit for unit testing your C# code on a Mac. Of course, we know C# code can be run on a Mac OS X environment, using Mono and MonoDevelop, and so my intuition was that I should be able to somehow use NUnit on it as well, perhaps with something as simple as

$ mono nunit-console.exe dll_file.dll

or something like that. I downloaded the latest version of the NUnit binaries and tried compiling and running my test code with

$ mcs file_a.cs file_a_test.cs -reference:/path/to/nunit.framework.dll

$ mono /path/to/nunit-console.exe file_a.exe

Of course it didn’t work. I don’t know why and I don’t know how I found it, but after tinkering around with it for a bit I discovered that when I had installed Mono on my Mac a long time ago, it had already installed NUnit on it. NUnit was pre-packaged with Mono and MonoDevelop! All I had to do then to successfully run what I wanted to run was:

$ mcs file_a.cs file_a_test.cs -reference:nunit.framework.dll

$ NUNIT-CONSOLE file_a.exe

Notice how I didn’t need the path anymore, and how NUNIT-CONSOLE is a symbolic link to nunit-console.exe that came with Mono.

Got rid of the freshly unzipped (and now superfluous) NUnit.