A Helping Hand for Users

Here’s a useful script I whipped up for users. Drop the pow script in a convenient spot like ~/bin, name it pow, and give it a symlinky friend named unpow:

cd ~/bin
ln -s pow unpow

Now you’re all set for an even easier time working with Pow:

pow ~/code/my-awezome-rails-app

You can choose a custom site name:

pow ~/code/my-awezome-rails-app mara

Cleaning up old sites is as easy as:

unpow ~/code/my-awezome-rails-app

Full paths aren’t needed, the pow script will do the right thing:

cd ~/code/my-awezome-rails-app
pow .

I periodically update pow, so be sure to check pow -h for current options and features not listed above.


Pow script on

Volt: Volume Toggle

This is a handy shell script I whipped up to assist with mounting and unmounting OS X volumes. In my case, I’m using what seems to be a common “hotrod” aftermarket configuration of the Early 2011 Macbook Pro. The system’s main drive has been upgraded to an SSD, with the original hard drive moved to the optical bay.

What with the upgraded Core i7 CPU, discrete graphics, and big display, this system is not nearly as power frugal as a lightweight system like a Macbook Air. Thus when I’m out and about with this laptop, the `volt` script lets me quickly and easily spin down the hard drive.

Pro Tip: Create a symlink to volt with the same name as the volume you want to toggle (including spaces, if any):

ln -s volt SpareVolume

The symlink is now a shortcut to toggle that volume, handy for shorthand use from the command line or via tools like LaunchBar.

Steve Jobs 1955-2011

Steve was widely lauded for his emphasis on design at Apple, but I’m just as impressed with his amazing success at seeing his visions through to reality and in inspiring others with that vision.

Goodbye, Mr. Jobs. Thank you.

Lion Tip ‘O the Day: Stop Automatic Space Reordering

The Skinny

  1. Go to System Preferences –> Mission Control
  2. Uncheck “Automatically rearrange spaces based on most recent use”


This is an absolute mis-feature of OS X Lion. The default setting, “Automatically rearrange spaces based on most recent use”, causes spaces to rearrange themselves outside of my view. The result? Things are no longer where I left them when I return.

What I cannot fathom is why anyone thought this was a good idea in the first place. Apple, since when do the rooms of my house rearrange themselves “based on most recent use”? This setting defeats the physical analogy of “spaces” and the natural leverage that provides to gesture-based navigation. Users form a mental map of their work when using virtual desktops like OS X’s Spaces. This little bit of automation neatly scuttles that intuitive “body knowledge”. Imagine how frustrating it would be to read a textbook whose pages rearranged themselves according to “what did I look at most recently” logic. Is the page you want to the left or right?

This is exactly the same design failure that Microsoft made with tabs in its Visual Studio development suite. Unlike modern browser-based tab navigation, there’s no way in Visual Studio to simply navigate to tabs left or right. Instead, navigation always occurs via a “most recently used” rubric when using next or previous keys. The user is burdened with having to maintain a historical knowledge of visited tabs that must match that invisible record kept by the computer. Thus it is with OS X Lion’s Spaces.

Topgit on *BSD and Mac OS X

The topgit patch queue manager for Git has a few bugs when used on BSD-based systems, which includes Mac OS X. Specifically, topgit assumes GNU versions of sed and mktemp. I’ve forked topgit on Github and patched these issues.

I’ve submitted a pull request upstream to Petr Baudis but haven’t heard anything back yet.

Git and Emacs: Magit

I’ve recently started using git for some work projects. Digging into the available modes for GNU Emacs, magit (pronounced like “magic”) comes out at the top of the heap. It’s surprisingly well thought out and is well tailored to git’s workflow, unlike the emacs VC integration.

Give Alex Vollmer’s magit tutorial video a few minutes of your time to see what this tool has to offer.

Make Firefox Search Automatically Case Sensitive

The Skinny

In Firefox, open a new page with the location “about:config”. Set the config value accessibility.typeaheadfind.casesensitive to ‘2’.

“What did I just do?!”

The Emacs text editor has a subtle-but-great search feature. An interactive search that is all lower-case is treated as case-insensitive. However, a search that contains any upper-case characters is automatically considered case-sensitive. That is, a search for foo will match any of foo, Foo, FoO and so forth. But a search for Bar will match only Bar, ignoring bar, BAR, etc. Once you get used to it, this can be a great timesaver.

For about:config newbies

In Firefox, open a new tab/window and type about:config into the location bar. Look in the left column for the entry accessibility.typeaheadfind.casesensitive. You can use the “Filter” box at the top of the page to quickly reduce the list to a manageable size. Try typing “find” and see what happens. Once found, double-click on the entry name above, set the value to 2, and close the about:config page. You’re all set! Firefox will now use automatic case-sensitivity for the find and link quick-find features.

Further reading

Documentation on this setting and other about:config entries can be found in the MozillaZine Knowledge Base.

JRuby on Mac OS X vs. Ant Test

I’ve just started playing around with JRuby, starting off
with the first of the JRuby tutorials. Unfortunately, this very basic tutorial (mostly an installation guide) ran aground on OS X, 10.4. ant was complaining about not finding a junit task.

Skimming the copious text that ant spews forth on this error, I downloaded JUnit and installed junit-4.1.jar in ~/.ant/lib. No dice. ant was still its same bitchy self.

After a frustrating period of Googling1, I happened across a useful tip for setting up JAVA_HOME on Mac OS X. I tried that2, after having removed the junit jar file (trying to test one variable at a time.) Still no dice.

So for kicks, I tried putting the JUnit jar back in ~/.ant/lib, and the tests ran. Go figure.

1 Has no one tried running ant test on JRuby on OS X before now?

2 zsh/bash users: export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home

Good Framework, Bad Framework.

A few Python blog entries I’ve happened across of late have brought up the topic of frameworks versus libraries. This article by Guido van Rossum questioned differences between the design of libraries and frameworks. ‘Why Frameworks Suck’ by Andy Smith is an outright rant (who’ve guessed from that title? ;-) against frameworks.

While reading both of these, I was hit by a cognitive dissonance: I’ve both written and used frameworks that have been fantastic tools. Yet, having grappled with J2EE (cough), I certainly understand Andy’s pain. This raises a question: why do some frameworks suck, while others are a blessing?

Sins of Framework Design

For my purposes, I’ll define a framework as utility code that calls your code. This stands in contrast to a library, which typically presents a self-contained collection functions that your code calls. The differences between a library and a framework are a matter of what kind of abstraction is provided and what kind of problems they each solve.

In my experience, the biggest sin in framework design is overreaching: a framework that simply tries to do too much. Stuffing one framework full of too many use cases is an easy recipe for disaster. The whole thing rapidly becomes too brittle and too big for developers to easily assimilate.

Here’s where I get to take one of my own lessons learned as an example. I wrote a framework a few years back that facilitated load balancing of compute tasks in a multi-processor embedded system. The need for this framework became apparent when the developers writing the to-be-distributed applications ended up creating different ad-hoc synchronization code for each new task. Each implementation ended up having different subtle bugs in it, and it quickly became apparent that this approach was unmaintainable. I was able to refactor the whole mess and provide an interface which the dev teams could write to without explicit synchronization concerns in their code. All the sync code was lifted into the framework, where it was written and debugged once for all of these applications — a huge win.

Alas, this framework was written at a startup under the influence of one too many Death Marches. The result of this was that the synchronization tools were too strongly tied to a larger framework with other concerns (e.g. state machines for the most common problem of our early implementations).

A Way to Better Frameworks

I’m increasingly of the opinion that minimalism is a sound rule of thumb for framework design. Don’t let frameworks grow into big monolithic entities. Instead, think in terms of a collaboration of micro-frameworks and libraries — work in the smallest and least-intrusive units that solve the larger problems at hand.

My hypothesis is that by keeping your frameworks small, they will provide fewer unnecessary constraints to their use (and to developers), they’ll be easier to refactor, and will have a higher likelihood of being reusable. This view provides an interesting answer to this complaint against the definition of a framework as “code that calls your code” :

The problem with this definition is that “map” counts as a framework.

Not as useful in a language where functions can be passed around like data.

I’d argue that this only indicates that higher-order programming languages (where functions can be passed like data) make it much easier to create tiny, reusable framework-like code. While I wouldn’t call “map” a framework either, we’re used to equating “framework” with “large” or “bloated”, which need not be the case.

I’m a firm believer from experience that frameworks are an indispensable tool of software design. That said, it’s far too easy for a software designer to make the scope of a framework encompass the entire the problem domain du jour. In this way, we end up with overgrown, tightly coupled frameworks for enterprise web platforms, embedded whatsits, and so forth. Remember: when thinking framework, think small.

The Emancipation of Broadcast

Broadcast? I suppose I meant Podcast…

Podcasting is nifty, in that it frees the production of radio-style shows from actual broadcast radio. The low barriers to entry have resulted in many great shows that you’d never get to hear on commercial radio. But this same ease of entry can also result in the occasional audio disaster…

On that theme, I’ll illustrate with examples of The Good, The Bad, and The Ugly in podcasting. First, we have:

The Good:

Spacemusic is an ambient/chillout podcast show by a guy named TC in the Netherlands. Fun and funky, with good production values. The show has good music, and TC does a fine job of delivering the “text” of the show, including the occasional interview. Despite having a good time with it, TC keeps the show itself from getting in the way of the music. Most excellent.

The Bad: RadRails Release Podcast

The fine RadRails developers at RIT have put together an Eclipse plugin for Ruby on Rails development. I love their work, and as such I apologize up front for picking on them. Alas, they’ve also given me an archetypical example for The Bad; folks with a good idea to send to the world, but who need production polish — something I think will be a hallmark of a lot of smaller talk podcasts… Put another way, unscripted recording is tough. Many folks aren’t (yet) up for it.

In the world of broadcast radio, professionals encounter various hurdles (training, screening, etc.) before they get on the air. In the ‘casts I’ve heard, these guys use a relaxed, conversational style (good), but the discussion isn’t sufficiently focused for a remote listener, with pauses, reiteration, and non-words (“um”) that work in personal conversation but don’t work in broadcast/podcast. To their credit, their vocal delivery/projection for recording is generally pretty good — something that should serve well when they present at EclipseCon 2006. I also give the RadRails crew big props for doing another kind of newfangled broadcast-redux media very well; read on for the details.

The Ugly: Dec 5, 2005 MacNN Podcast

Holy crap (there’s that Scottish ‘r’ again)… when the content sucks, it’s far, FAR worse in a Podcast. In this case, we’ve got some talking heads from MacNN droning on about various bits of Apple speculation and software. On a web page, it’s possible to skim and quickly pick out interesting bits and leave the dross. Or decide it’s all dross and hit the back button. In a podcast, you’re stuck slogging through the dross — will something interesting surface? Or will the dross-slog just.. keep… going….

Show Me, Don’t Tell Me.

All that said, there’s another interesting phenomenon that’s becoming more common. As it’s become easier to produce and distribute video on the Internet, software tutorial videos are increasingly popular. Fortunately, the RadRails developers get to be the heroes at the end of our tale. Instead of the usual hard-to-grok documentation chapter rife with screenshots, a short video tells all about importing projects into RadRails. This picture’s worth far more than a thousand words — it saves time and energy.

All told, this is the same story of all disruptive publishing technologies. A social, technological event lowers some barriers to entry for publication. Some folks use the new medium to persist all manner of information, the rest of us figure out how to sort through it all, and everyone gradually learns how to further improve production and identification of Good Stuff. The story is the same whether we’re talking the advent of papyrus (all those scrolls!), or here at the advent of the Internet.