Getting Things Done with Rituals
In order to achieve real productivity you need to get into the zone. Context switches take you out of the zone and should therefore be managed carefully. Get rid of multitasking.
I’ve found the mental overhead of context switches can be reduced with a clear start and end for a tiny break from work. A ritual provides such clear boundaries. I use several rituals throughout my day: reviewing my to do’s, drinking a cup of coffee while skimming through the news, getting a cup of water, and so forth. Even the daily commute between home and work helps ‘switching off’ at the end of the day.
I’ve grown used to them over time. I think I now get why people are so resistant to change…
“In retrospect, all revolutions seem inevitable. Beforehand, all revolutions seem impossible.”
Michael McFaul
jQuery custom selectors
I like writing jQuery plugins, so I can separate functionality into distinct units. But applying the plugin sometimes requires some logic I’d rather have in my plugin itself.
Example code
Say I want to create a plugin that creates a lightbox-style image zooming effect. I want to apply it to all links pointing at an image:
<a href="/images/photo1.jpg"><img src="/images/photo1.jpg"></a>
Here’s how I might call my awesome plugin in my main javascript file:
$(function() {
// One option: create complex inline selectors:
$('a[href$="jpg"], a[href$="png"]).awesome_plugin();
// Second option: filtering
$('a').filter(function() {
$(this).attr('href').match(/\.(png|gif|jpe?g)$/);
}).awesome_plugin();
});
These both might work, but they move typical plugin logic to my javascript initializer. That’s not what I want.
Custom selector
The solution is so obvious I wonder why I did not think of it before: write a custom jQuery selector:
$(function() {
$('a:to_image').awesome_plugin();
});
Awesome: concise and with clear intent. Here’s one way to implement it:
// Somewhere in my plugin
$.expr[':'].to_image = function(obj, index, meta, stack) {
return $(obj).attr('href').match(/\.(png|gif|jpe?g)$/);
};
Now all the logic is nicely tucked away in my plugin.
GTD with OWA
Relying on Microsoft Outlook Web Access without Internet Explorer can be tiresome — being served a static web application that would have annoyed even in 1996 — but it is kind of relaxing too: the effort of constantly logging in and taming the horrible interface to get to your mail is a real motivator to get some actual work done.
“Your request to not receive promotional emails about your subscription has been received and will be processed within the next 10 working days.”
FT.com customer service: 10 working days to unsubscribe from your mailing list? That’s crazy fast! They must be using some kind of “computer”. Amazing…
Attractive piracy
The problem with internet piracy is obvious: downloading illegal materials is easier, cheaper, faster and the acquired content is more portable, than with any legal alternative. The solution would be to close the gap between the desirability of illegal versus legal content distribution from the consumer’s perspective.
Too bad then, that the music and movie industries take the producer’s perspective, trying to make illegal downloading less attractive, rather than legal downloading more attractive. That is why they get so little public sympathy, I reckon.
Subversion branching
The main reason why developers should use Git for versioning is cheap, cheap branching. But in Subversion it isn’t so hard that you shouldn’t use it. Here’s a basic bugfix branch workflow. First, create your branch:
svn copy /path/trunk\
/path/branches/my-new-branch\
-m "Create my new branch"
svn switch /path/branches/my-new-branch
Of course, /path/ is easy enough to find:
svn info | grep URL
Hack away, make some commits, and when you are ready to merge to branch back into trunk:
# Note the revision that started this branch
# assume this tells you '4362'
svn log --stop-on-copy
# Get back to trunk and merge in your changes
svn switch /path/trunk
svn merge -r 4362:HEAD /path/branches/my-new-branch
Inspect your changes, resolve conflicts and make sure everything is alright. Commit your changes…
svn commit -m "Merge in branch 'my new branch'"
…and then clean up after yourself:
svn delete /path/branches/my-new-branch\
-m "Remove obsolete branch"
The trick is knowing where your branch started. You can note the revision number when you create the branch, or use svn log to find out.
Beware of changes to trunk before merging in your branch. If trunk has changed since you created your branch (and chances are it has) you should first merge those changes back into your branch, so it stays in sync.
Newer versions of Subversion should make this process a little easier, but this works. Be sure to check out the Subversion manual on branching patterns.
“In many ways, history should be regarded as a globalizing mass medium in the nineteenth century.”
