/dev/nikc/blog

I use the console a lot. I also like to patch together small scripts to make my shell experience smoother and more efficient. (Read: indulge my laziness.) Inspired by a talk by Paul Irish where he introduces his selection of tools – specifically a command for quickly jumping into a project folder, which I naturally immediately adopted. Just to show off, I also included tab-completion.

If you feel you could use it, snag the source code below (and party on!), or download it from the gist.

Setting up is pretty straight forward and is “documented” in the comments at the top. If you don’t like z for the command, just change the name of the function. (It’s the last function in the source.) Don’t forget to change the command on the last line or you’ll lose the tab-completion.

<code>#!bash

#  Usage:
#
#  In your .bashrc
#
#  export PROJECTS_HOME=<path_to_projects_root>
#  source jump-to-project.bash
#
#  In you shell:
#
#  $ z <project name>[ENTER]
#
#  Use [TAB] for auto-completion, double tap for a list.
#
#  Optionals:
#
#  export PROJECTS_SUFFIX=<optional suffix to strip>
#
#  For prettier tab-completion, fill PROJECTS_SUFFIX with a
#  value you want to strip from folder names. I use '.dev.local'
#
#  export PROJECTS_TALKATIVE=1
#
#  For some feedback when switching into a project folder,
#  fill PROJECTS_TALKATIVE with any value.

if [ "x$PROJECTS_HOME" = "x" ]; then
    echo "PROJECTS_HOME not set"
    return
fi

_find_all_projects () {
    if [ "x$1" = "x" ];
    then
        find $PROJECTS_HOME -maxdepth 1|xargs basename -s "$PROJECTS_SUFFIX"
    else
        find $PROJECTS_HOME -maxdepth 1 -name "$1*"|xargs basename -s "$PROJECTS_SUFFIX"
    fi
    return 0
}

_find_project_path () {
    find $PROJECTS_HOME -maxdepth 1 -name "$1*"
}

_find_project () {
    local cur prev opts
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    opts=$(_find_all_projects)

    COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
    return 0
}

z () {
    if [ "x$HOME" = "x" ]; then
        echo "\$HOME not set"
        return 1
    fi

    MATCHES=($(_find_all_projects $1))

    if [ "x$1" = "x" ]; then
        echo "Usage: zz <project>"
        echo "Projects:"
        echo ${MATCHES[@]}
        return 0
    fi

    if [ ${#MATCHES[@]} -eq 0 ]; then
        echo "No match for $1"
        return 0
    fi

    if [ ${#MATCHES[@]} -gt 1 ];
    then
        echo "Ambiguous match '$1': ${MATCHES[@]}"
    fi

    cd $(_find_project_path ${MATCHES[0]}) && [ ! -z "$PROJECTS_TALKATIVE" ] && echo "Project ${MATCHES[0]} in $(pwd)"

    return 0
}

complete -F _find_project z</code>

I stumbled upon an article about Fluent.io, a product in the making by the guys who brought you Google Wave, Google’s now discontinued attempt to radically renew collaboration and real time communication on the internet.

After reading the article and watching the promo video, I must say Fluent.io looks promising – I certainly welcome the innovation and any attempt to improve the status quo. Especially the search looks impressive – a feature where the otherwise lovely GMail falls short in ways I can’t even begin to describe.

But at the same time I can’t help feeling a bit concerned. While there is potential to make using e-mail a smoother, less painful experience, the stream UX is likely to lower the threshold to send short spur of the moment messages, wherein lies a risk of making e-mailing too similar to instant messaging or commenting on Facebook. A trait I feel would be counter productive as that would hardly reduce the number of e-mails received, and I’m sure anyone would agree todays torrential stream of e-mail is one of the biggest, if not the biggest, reasons e-mail is as unusable as it today is in the first place.

The problem would probably not be apparent to the one using Fluent.io, but rather to the one who isn’t. Using Fluent.io you will most likely get all the messages intelligently grouped as a single item, perhaps even merging sequential messages for the same subject as a single one, while the one sticking to a non-intelligent client will simply get an inbox full of stub messages. A similar phenomenon probably occurred when GMail gained popularity, but I believe this effect has since diminished by the introduction of integrated Google Talk, as well as the wide adoption of Facebook for inane communication.

But there probably isn’t reason for alarm, because there seems to be no plans for a free subscription – who the hell pays for anything anymore these days? Or have you heard of anyone using Flowdock?

For my first Node.js project I created a Pong-clone. The game was presented to the public during Luxus Digital Week; a conceptual digital exhibition organized by my employer. You can see the game in action in the below video.

Read the rest of this entry »

Since about half a year ago I migrated from Textmate to Sublime Text 2, simply because it’s awesome. Of course, as with all software, it has its shortcomings, but nothing I can’t live with.

But one thing which really bothered me and occasionally made me return to Textmate was Sublime’s lack of a command line companion tool. I spend a lot (most) of my time on the command line and the lack of a command line helper was a real drag. But as I like both the command line and Sublime Text 2, and not willing to give up either, I simply wouldn’t believe the situation couldn’t be remedied and embarked on a mission to find a solution.

If all you need is a shortcut for opening files and folders, a simple alias is enough:

alias slt=open -a "Sublime Text 2"

But this doesn’t allow for creating new files or the use of pipes. Both of which are frequent use cases for me. To accomplish this, a bit more code in the form of a bash function comes to the resque:

function slt() {
    if [ -z "$1" -a -t 0 ]; then
        echo "slt file [...]"
        return 0
    fi

    if [ -z "$1" ]; then
        open -a "Sublime Text 2" -f
    else
        for arg in $*; do
            [ ! -f "$arg" -a ! -d "$arg" ] && touch $arg
        done
        open -a "Sublime Text 2" $*
    fi

    return 0
}

And voila! Copy and paste into your .bashrc and your new best friend can now be used to edit new files and read stdin¹ from the command line.

Disclaimer: This script hasn’t been tested on anything other than OS X 10.6.8. Most likely if you’re on Linux you won’t need any of this extra malarkey, and if you’re on Windows, well, you have my sympathies.