Effectif Development

Write a quick draft while it's fresh

2012-05-15T09:00:00+01:00

As a bootstrapper, it's important that I spend enough time getting my product's name out there. For me, that means blogging. I've recently been writing a couple of paragraphs the instant that I have an idea for a post. That usually means writing "on your mobile" (or in my case, on my iPod).

I used to capture a one line summary of an idea in my todo list, but sometimes I'd struggle to recover my thoughts when trying to write it up.

In the last week I've written several 200 word drafts on my iPod. They've since been edited into blog posts that I'm rather pleased with. If you have an iOS device the iA Writer app (iPhone/iPod/iPad) is great.

In this screenshot of the iPhone version you can see iA Writer's extended keyboard, with extra buttons for common punctuation marks, and cursor keys for navigating left and right in your copy. The iPad version (not shown) also has keys for jumping whole words at the time, which is a significant improvement over the default iPad keyboard.

I seem to write better with iOS than I do with a laptop, presumably because I can't type as fast and that gives me a bit more space to think. Maybe it's that, or maybe it's just because I'm using something a bit different.

Either way, iA Writer on your phone, sync'd with Dropbox is a great way to write the draft. I edit later on the computer, then post it.

Sent from my iPod

Securing Instiki with an SSH tunnel

2012-04-26T00:00:00+00:00

I've been using a wiki a lot recently to keep track of my research. A wiki is the perfect tool for keeping track of all my notes, and the relationships between my ideas.

I've been using Instiki; the UI is clean and is built with familiar technology (it's written in Rails, and its early code was the app from which DHH extracted the Rails framework). As wikis go it takes a fairly low maintenance approach, and lets you concentrate on your content.

Being a Rails app, you can run it with a standard Ruby web server such as Webrick. I started out running it locally on my desktop. When I started working more on my laptop I needed access to the wiki there too, so I moved the app's folder into Dropbox and synchronised the database that way (it uses a local SQLite database). That worked fine until I accidentally started it on both machines at once, and I lost a page of data.

Clearly, I was going to have to host it properly.

There is a fork of Instiki that runs on Heroku. I'm sure it's awesome, but I'm often reluctant to use forks of apps that don't see a lot of use. You've no idea how long the fork will be maintained, and I don't fancy rolling my sleeves up when Heroku deprecate the stack that the port runs on.

So I decided to host it on my VPS. In theory all I'd need to do is to tar up my local instiki folder, copy it over to my server and untar it. After a quick bundle install I should be good to go, and indeed, I was.

I knocked up a quick init script to start/stop the app on bootup/shutdown, and all was well.

Instiki was running unprotected on port 2500. All was not well.

So, what about security?

You really don't want a private wiki listening on an open port. Not only is your data unprotected, but somebody might find a vulnerability in the wiki software and login to your server.

I had planned to filter port 2500 on my firewall, and configure Nginx to act as a proxy on port 80. This wouldn't prevent an attacker from accessing the wiki's home page, but I could secure it in Nginx with HTTP basic auth running over an SSL connection.

How conventional. And what a faff!

Instead, I've firewalled port 2500 on my server and connect to Instiki over an encrypted SSH connection. Better yet, it guarantees that only I can get at it, as only I can connect to my server with ssh!

So now I access Instiki in the browser by connecting to http://localhost:2500.

I've put the ssh command that sets this up in a script, and run it whenever I want access to the wiki. At some point I'll probably run it automatically whenever I start my laptop, but for now I'm happy with running it when I need it.

Here's the script:

$ cat bin/instiki-tunnel
#!/bin/sh

ssh -f my.server.com -L localhost:2500:my.server.com:2500 -N

This is what the ssh options are for:

-f – run in the background just before launching the command.
-L – forwards all connections to localhost on port 2500 to port 2500 on my.server.com, via an encrypted, authenticated SSH tunnel.
-N – prevents an actual command from being run on the server.

You've got to love SSH.

Using QUnit with CoffeeScript

2012-03-30T09:00:00+00:00

QUnit is a unit testing framework for JavaScript, from the jQuery project. Earlier this week I wrote about how I chose it over Jasmine for my current project. This article explains how I setup QUnit to test my CoffeeScript, along with the Sinon mocking/stubbing library.

Downloading QUnit

Let's assume that you want to keep your tests in a folder called test/javascripts (relative to your project's directory), and that the CoffeeScript code that you want to test lives in a folder called app/assets/javascripts. This is where the files live in my Rails app; if you're not using Rails just substitute the appropriate paths for your project in the code that follows.

Start by making a directory to store QUnit itself, and then download qunit.js and qunit.css:

$ mkdir -p test/javascripts/qunit
$ cd test/javascripts/qunit
$ curl -O https://raw.github.com/jquery/qunit/master/qunit/qunit.js
$ curl -O https://raw.github.com/jquery/qunit/master/qunit/qunit.css

We'll also want the in-browser CoffeeScript compiler so that we can compile CoffeeScript within text/coffeescript script tags on the fly. I've stored it in test/javascripts:

$ cd ../
$ curl -O http://jashkenas.github.com/coffee-script/extras/coffee-script.js

The test suite HTML file

QUnit needs an HTML file that will load QUnit, our CoffeeScript, and our tests (which are also be written in CoffeeScript). The HTML file needs a few placeholder elements in it that qunit.js uses when rendering the results of your test suite.

The onus is on you to set this file up, but there are plenty of examples online. Here's mine, which I saved in test/javascripts/index.html:

:::html
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8" />
  <title>QUnit Test Suite</title>
  <link rel="stylesheet" href="qunit/qunit.css" type="text/css" media="screen">
</head>
<body>
  <h1 id="qunit-header">QUnit Tests</h1>
  <h2 id="qunit-banner"></h2>
  <div id="qunit-testrunner-toolbar"></div>
  <h2 id="qunit-userAgent"></h2>
  <ol id="qunit-tests"></ol>
  <div id="qunit-fixture">
  </div>
  <script type="text/javascript" src="qunit/qunit.js"></script>
  <script type="text/javascript" src="coffee-script.js"></script>
  <script type="text/coffeescript">
  </script>
</body>
</html>

You'll notice that I've loaded qunit.js and coffee-script.js.

All we need to do now is to load our tests inside the empty text/coffeescript script tag. To check whether everything is setup properly, let's add a couple of simple tests:

:::javascript
<script type="text/coffeescript">
  test 'true should be truthy', ->   
    ok(true, 'true is not truthy!')

  test 'should be able to append to an array', -> 
    # this test will fail, as this *isn't* how to append to an array
    equal([1, 2], [1] + 2)    
</script>

Running your tests

Just open the web page in your browser. We've used relative paths for everything in index.html, so you can load it directly from the file system, with a file:///... URL.

On a Mac? Do this:

$ open test/javascripts/index.html

It should look like this:

Loading tests from external files

You could keep all your tests in index.html, but I prefer to store my code in separate files with a .coffee extension and to just use index.html as a way to kick everything off.

I've put this code in my script tag:

:::html
<script type="text/coffeescript">
  for file in ['models', 'controllers']                                             
    lib = "../../app/assets/javascripts/#{file}.js.coffee"                          
    load_test = ->                                                                  
      test = "#{file}_test.coffee"                                                  
      -> CoffeeScript.load(test)                                                    
    CoffeeScript.load lib, load_test()  
</script>

Let's break that down a bit...

I've used a simple naming convention for my test files. Code in app/assets/javascripts/foo.js.coffee is tested by code that lives in test/javascripts/foo_test.coffee. The for loop is just loading each of my modules, and then (via the callback returned by load_test) loading the corresponding tests. That's all you need to do; QUnit will do the rest.

The CoffeeScript.load function takes a URL and a callback to run after load. I'm loading the tests in a callback to guarantee that the code under test has been loaded before the test code itself is loaded. If you don't do this you can see some test failures when your tests run before the code they're testing gets loaded.

If you're wondering why we need the load_test function (rather than just passing an anonymous function as our callback), it's currying the value of the test variable. If you don't curry it the current value of file is used when the callback executes, rather than the value that it was set to when the callback is defined. So if you don't curry it, most of your test files won't get loaded.

Loading third party libraries

I use MooTools and Serenade.js in my project, so I've added these lines to the list of script tags:

:::html
<script type="text/javascript" src="../../vendor/assets/javascripts/mootools-core-1.4.4.js"></script>
<script type="text/javascript" src="../../vendor/assets/javascripts/serenade.js"></script>

You can obviously load jQuery, YUI, etc. in the same way.

Adding a stubbing/mocking library

Unit testing gets painful when you can't stub or mock the objects that interact with the code that's under test. I didn't spend a lot of time investigating the options, but as I read the Sinon docs I took quite a shine to it. I noticed that Serande.js uses Sinon, and that's a good enough recommendation for me. There's also a QUnit plugin which makes it "just work".

To install Sinon download both sinon-qunit and Sinon.JS from the sinon-qunit page and put them in your test/javascripts/qunit folder.

Then add these tags to index.html (but make sure you update the version numbers):

:::html
<script type="text/javascript" src="qunit/sinon-1.3.2.js"></script>
<script type="text/javascript" src="qunit/sinon-qunit-1.0.0.js"></script>

Re-running the tests automatically

So that's all fairly simple, but to run the tests you have to switch to your browser and reload the page. That's a bit painful; wouldn't it be good if your test suite ran immediately when you save a .coffee file? I'm now using guard-livereload to reload the page in the browser on save.

I think we've dealt with enough for one article, so I'll show you how to set guard-livereload up for QUnit (with Rails) in my next post...

QUnit or Jasmine?

2012-03-27T09:00:00+00:00

Over the last few months I've been spiking a few user interface ideas for the The Agile Planner, which has meant that I've been writing a lot of CoffeeScript. While I've been experimenting, I've been content to test it my work with acceptance tests written in Ruby with capybara-webkit. Last week my CoffeeScript became a little more complicated, and I could feel my progress slowing down as I grappled to keep everything in my head. It was time to go back to TDD.

It's been a while since I've unit tested JavaScript in anger, so I spent half an hour investigating the most obvious choices. There seem to be two main contenders:

Jasmine - a BDD framework that's clearly influenced by RSpec, and
QUnit - a more traditional test framework from the jQuery project.

I compared them on three criteria:

Speed of setup. I tend to avoid testing tools that take me more than hour to get up and running.
Simplicity. Test frameworks don't need to be complicated; they just need to let me specify how my code should behave and keep out of my way. All things being equal, I'll choose an xUnit style testing framework to an RSpec style framework. If you're thinking "but I prefer BDD!" don't forget that the "B" in BDD is just language, and you can use that language in any framework you like.
Support for Continuous Integration. If you can't run your test suite automatically then sooner or later you'll forget to run it manually, and at some point ship a broken app to your users. Running tests in your CI build also enables you to automate continuous deployment, which is always a giggle.

Evaluating Jasmine

I looked at Jasmine first. A few weeks ago I stumbled across a project called Jasminerice that makes it really easy to unit test CoffeeScript in a Rails 3 project, using the Rails asset pipeline.

While I'm not generally a fan of investing time in technologies whose use is limited to a single framework (Rails), Jasminerice really appealed. It looks like drop-in CoffeeScript testing for Rails. I'm using the asset pipeline, so in theory all I'd need to do to start testing my code is to install the jasminerice gem and start creating files in spec/javascripts.

With such simplicity comes reduced flexibility. I don't use RSpec (for me, it can't hold a candle to MiniTest). I keep all my tests in a test folder. My CoffeeScript/JavaScript tests are going to live in test/javascript. I opened the Jasminerice source to see whether the path was configurable. It wasn't. I could have monkey patched it, but I was starting to feel a bit of friction.

What about running tests on the command line? The Jasminerice README pointed me to guard-jasmine, which adds a bunch of extra features. As you might expect, it's a plugin for Guard that will run your tests when you save your .coffee files, but you can also run it outside of Guard. It uses the PhantomJS headless browser, so running tests from the command line or on a CI server is no problem.

Taking a quick look back at my three criteria, how do Jasmine, Jasminerice and guard-jasmine stack up?

Speed of setup

Jasmine looked innocently straightforward to begin with, but a thorough read through of the three projects' README files took a while. guard-jasmine has a lot of options. That kind of control is often just what you need, but all I need to do here is write a few unit tests.

Simplicity

I didn't feel very clear on the relative responsibilities of the three projects (Jasmine, Jasminerice and guard-jasmine). It felt as though I'd end up reading the code in order to be confident that I'd set it up correctly. That's fine, but I didn't fancy doing it for three separate projects.

Then I noticed that guard-jasmine depended on RSpec, which it had added to my project. That's 10,000 lines of Ruby code that I don't need to install, just to test some JavaScript. I felt as though I'd be swimming against the current with MiniTest; I don't want a spec directory, and I don't want RSpec in my bundled gems.

Support for Continuous Integration

guard-jasmine clearly has this aspect well and truly sorted. It looks fantastic.

Thoughts on Jasmine

If you're an RSpec fan, have time to read through all the docs and play around with it, guard-jasmine looks brilliant.

Evaluating QUnit

I'm using MooTools rather than jQuery on The Agile Planner, so my first question was whether or not QUnit relies on jQuery. It doesn't; if jQuery is loaded it'll use it internally, otherwise it falls back to standard DOM manipulation techniques. This discovery was a great start; it's clearly been designed to be framework agnostic, and that means that any time I invest in learning it can be re-used on other projects, using different libraries.

I was also rather chuffed that it took me 30 seconds to find and search the source code in order to check this out; it's easy to read, and there was only one file to look in. A simple and transparent project. Great start.

There only seemed to be one obvious downside to QUnit. It's designed to run in a browser, while I was really hoping for something that I could launch from Ruby. I use TConsole to run my Ruby tests and I was really hoping that I'd be able to find a way to launch my CoffeeScript tests from within TConsole. QUnit's dependency on a browser made this look rather unlikely out of the box.

Incidentally, TConsole is the best test runner I've used, in any language, and its high time I blogged about it.

So how does QUnit stand up against my three criteria?

Speed of setup

Setting up QUnit is easy, though not that succinctly documented. You need to make an HTML file with a few pre-defined tags in, and then load qunit.css and qunit.js in the file's <head> tag.

You also need to load your CoffeeScript libraries and test files (which is fairly easy) and then load the web page in your browser.

That's all there is to it. Once you've got hold of the files, it's fast.

Simplicity

I can't imagine how it could be simpler. There are no gems to install, just three files to download and a snippet of code to edit.

There is, of course, a downside...

Support for Continuous Integration

Out of the box, you can't run QUnit from the command line. I did some Googling and it appears as though you can get a QUnit driver for JsTestDriver (whatever that means - JsTestDriver is hosted on Google Code and the home page is terrible; it's one of those projects where only those who have used it can get started quickly). I'll give JsTestDriver a proper go some other time.

There are a few blog posts floating around in which people talk about refactoring QUnit to make it easier to run in a command line environment. I wonder whether anybody has got it going with PhantomJS yet...

Thoughts on QUnit

I love the small size, simplicity of installation (and the lack of external dependencies), and the fact that I can start writing tests without even involving Bundler. Seriously, trying it out without involving Bundler was noticeably refreshing.

What I picked...

It was an easy decision in the end; I went with QUnit.

I doubt I'll be running my CoffeeScript tests from the console, and will just use JsTestDriver for continuous integration. I'll use guard-livereload to automatically refresh my in-browser tests when my code/tests change.

In another post I'll show you exactly what I've got in my QUnit HTML file, and how I'm loading my CoffeeScript.

If you can't wait for that post either nag me on Twitter and I'll make you a gist, or do some Googling. There are already a few gists out there, and a few threads on Stack Overflow. And if you go and find those, just remember that if you compile your CoffeeScript with -b (the "bare" option), you're doing it wrong!

Showing your laptop battery status in tmux

2012-03-09T08:00:00+00:00

You can configure the tmux status bar to show pretty much anything you like. To include your laptop battery's current charge, all you need to do is to write a script that prints your current charge level.

I was going to write this script myself, but then I had a bright idea. I thought I'd have a quick look in Brian Hogan's recent Tmux book to see whether or not he'd thought to include this tip, and surprise surprise, he has. He also links to a rather nifty script on GitHub that will output your battery status on Linux, FreeBSD and OS X.

So here's what you do. Start by downloading the script and putting it somewhere in your PATH:

$ curl -O https://raw.github.com/richo/dotfiles/master/bin/battery
$ mv battery ~/bin/battery
$ chmox +x ~/bin/battery

The battery script will only print any output if you pass it a command line option of Charging or Discharging.

$ ~/bin/battery
$ ~/bin/battery Discharging
51%

You can also configure it to print a row of hearts (instead of the percentage) by setting the CUTE_BATTERY_INDICATOR environment variable. Neat.

Now add this line to your .tmux.conf file (it should all be on one line, but I've split it here for formatting purposes):

set -g status-right "#(~/bin/battery Discharging; ~/bin/battery Charging) \
    | %e %B %R"

Reload your Tmux config (if you're not sure how to do that without restarting Tmux, this would be a perfect time to go and buy Brian's ebook -- he tells you on page 18).

The characters on the end set the format of the date and time. Those are the settings I use; if you want to change the format refer to the strftime(3) man page for alternative format characters.

Move commits from one branch to another

2012-03-06T12:30:00+00:00

Have you ever made a few commits on a branch, only to later realise that you should have been working on a topic branch (i.e. a branch specific to the task you're working on)? So long as you haven't yet shared any of these commits with anybody else, you can easily move them on to a new branch, and then remove them from your current branch.

Making the topic branch

When I decide that I'd be better off working in a topic branch, the first thing I do is commit any outstanding work. It doesn't matter if the tests aren't currently passing; we'll just undo the commit after we've switched branches.

So let's do a "WIP" (Work In Progress) commit and make the branch:

$ git add .
$ git commit -m "WIP"
$ git checkout -b some-feature

You can also make a new branch with the git branch command, but I prefer checkout -b as it also switches you to the new branch immediately (whereas git branch will just make the new branch, leaving you on your current branch).

Your "WIP" commit will now be stored safely at the head of the branch that you were on and also on the new some-feature branch.

Tip: If you're not familiar with branching, you can check that your most recent work is on the new branch before you continue:

$ git log -p some-feature

Removing commits from master

All you need to do now is to switch back to the master branch and remove any work that you'd rather develop on the topic branch. If the work to remove is just your last commit you can use git reset to roll the branch back:

$ git checkout master
$ git reset --hard HEAD^

The --hard option tells git to set the head of the current branch to the commit that you specify, while modifying the files on disk to match the contents of the repository.

The HEAD^ syntax refers to the previous commit to the head of the current branch (i.e. the last commit on the branch), so this will roll us back one commit. You can add extra ^ characters, so HEAD^^^ will throw away three commits.

If you want to go back more than a couple of commits you can use the tilde syntax to save some typing:

HEAD~1 is equivalent to HEAD^
HEAD~2 is equivalent to HEAD^^
HEAD~8 is equivalent to HEAD^^^^^^^^

Note: Be careful with the --hard option to git reset. It isn't something to be afraid of, but you do need to make sure that you've committed all your local changes to another branch before you run it.

Back to work...

Now we can switch back to the topic branch and carry on from where we left off.

$ git checkout some-feature

If you had some work in progress that you saved with a "WIP" commit message you can back that commit out now, without losing the changes (they'll still be on your filesystem). We'll use git reset again, but without the --hard option:

$ git reset HEAD^

All that'll do is to remove the last commit from your repository, without actually changing your files.

And there you are; all the commits that you deleted from master are now on your topic branch.

An insurance policy

Should you make a mistake while you're fiddling around with branches and git reset --hard you could find yourself in a position where you've thrown a bunch of commits away by mistake. It's unlikely but -- let's face it -- could happen. Don't worry, Git has got your back, and you can recover lost commits without too much trouble.

Navigating your bundled gems in Vim

2012-02-28T09:00:00+00:00

Do you sometimes find yourself wanting to read the code of a method in one of the gems that your project is using? Wouldn't it be good if you could put your cursor on the method or class in question, and press a key to jump straight to the definition within the gem's source code? With the ctags program you can, and with Ivan Tkalin's guard-ctags-bundler gem your tag files will be automatically updated when you add new gems to your bundle.

Installing ctags

You'll want a recent version of ctags for use with Ruby. Check for a recent version with:

$ ctags --version

If ctags isn't found (or you get an error message because the --version switch isn't supported) you'll need to install Exuberant ctags.

On Debian or Ubuntu, try this:

$ sudo apt-get install exuberant-ctags

On the Mac I'd recommend installing it with Homebrew:

$ brew install ctags

Test it by typing ctags -R inside your project's directory. It should create a tags file that Vim can read to navigate around the classes and methods defined in your own project.

To add support for navigating around your bundled gems, we need to setup guard-ctags-bundler.

Installing guard-ctags-bundler

Add these two gems to the development group in your Gemfile:

group :development do
  gem 'guard-ctags-bundler'
  gem 'rb-readline'
end

You don't strictly need rb-readline, but Guard's prompt improves dramatically when readline support is enabled.

Run bundle, and then create your Guardfile:

$ bundle install
$ guard init ctags-bundler

You can edit the paths in your Guardfile if you like, but the default should work well with most Rails projects and gems. Run guard, and then edit your Gemfile and run bundle install in another terminal. Guard should report that it has re-generated a gems.tags file.

If you leave guard running while you're working it'll keep the tags files up to date for you.

Configure Vim

Vim will automatically read the tags file, but we'll have to tell it to read the gems.tags file too. Add this to your ~/.vimrc file:

set tags+=gems.tags

Don't store tags files in version control

Your tags files are continually updated as you edit your project, and because they're automatically generated it doesn't make any sense to check them in. If you're using git you can tell it to ignore the tags files in all your projects like this:

$ cat <<EOF >> ~/.gitignore
tags
gems.tags
EOF

Using ctags in Vim

Find a method in your project that you know is defined in one of the Gems in your bundle. Position the cursor on the method call, and press Ctrl-]. You should find yourself looking at the code in the gem where the method is defined. To jump back to where you came from press Ctrl-T (these keybindings are the same ones used for following hyperlinks in Vim's help system).

Vim's ctags support can do a lot more than that (such as opening the code in a split), and Vim's help on using ctags is excellent. Read it by typing :help 29.1 within Vim.

Useful links

The guard-ctags-bundler GitHub page.
Section 29 of the Vim manual.

Running MacVim in your terminal

2012-02-13T08:55:00+00:00

A recent version of Vim comes with every copy of Mac OS X. When Apple compiled it they didn't link it against Ruby, which means that you can't use /usr/bin/vi with any Ruby based plugins. MacVim (which includes Ruby support) normally runs with a GUI, but you can run it in a terminal when you type vi if you prefer.

If MacVim isn't already installed, go and download it now.

When you run MacVim using the application icon it runs a binary inside your Applications folder. MacVim's disk image also contains a script called mvim that you can put in a folder in your $PATH so that you can launch that same binary from the command line. If you haven't already done so, install the mvim script. You can get advice on how to do that by typing :help mvim inside MacVim; they recommend putting the script in /usr/local/bin.

To get the vi command to run MacVim without the GUI we can make a symlink to the mvim script, and call it vi. Assuming you put the mvim script in /usr/local/bin, this should do it (though you might need sudo, depending on how your Mac is setup):

$ ln -s /usr/local/bin/mvim /usr/local/bin/vi

Let's setup a link for vim too, in case you're ever tempted to run it that way:

$ ln -s /usr/local/bin/mvim /usr/local/bin/vim

We'll also need to tell Bash to clear its cache of where all your programs live, so that it'll search $PATH for vi again and find the new script, instead of the file in /usr/bin/vi:

$ type vi
vi is hashed (/usr/bin/vi)
$ hash -r
$ type vi
vi is /usr/local/bin/vi

If you want to check that you're actually running MacVim, run vi like this:

$ vi --version

You should see "MacOS X (unix) version" in the first couple of lines of output.

Launching the GUI

When you're running MacVim on the console you can switch to the GUI simply by entering :gui from within Vim. It can be quite handy; try help :macvim for more...

Patching "bundle open" to set your current directory

2012-02-06T00:00:00+00:00

Ruby programmers need to be able to read the source code of the libraries (gems) that they use. Bundler makes it easy to load the source of a gem into your editor, with the bundle open command:

$ bundle open activerecord

It checks your $EDITOR environment variable to open the gem's code in your favourite editor.

It works great with Textmate, but (as pointed out by Ben Griffiths) when used with Vim it could be improved slightly by changing the current directory to the gem's folder before running Vim.

Inspired by Ben's shell script, I wrote a short Bash function to replace the bundle command that ships with Bundler. It's a useful technique; worth blogging about simply to point out to those who haven't dabbled in it how handy shell scripting can be...

bundle () 
{ 
    if [ "$1" == "open" ]; then
        shift
        ( cd $($(which bundle) show $*) && $EDITOR . )
    else
        $(which bundle) $*
    fi
}

The function shadows the bundle command (in the event that two commands should have the same name, functions are run in preference to external scripts).

The script checks to see whether its first argument is "open". If it is, the first command is removed from the argument list (with shift) and then the real bundle program is called with $(which bundle). The $* variable contains all the arguments that were passed to the function (minus the "open" that we just shifted off the front), so it's really just calling Bundler's show command to find the path to the gem's folder.

The path is handed to cd so that we change directory, and then the editor is run in the current directory.

The brackets surrounding the cd... && $EDITOR . command run the commands in a separate process, which prevents our current shell's current directory from being changed. If we didn't do that then we'd find our current directory would be the gem's directory, after we quit our editor.

Holy shit, I'm an entrepreneur!

2012-01-27T00:00:00+00:00

I wound down my freelancing business at the end of 2011 in order to dedicate some time to building my own product. For a long time now I've felt there's been a need for a better Agile planning app that caters to those of us who practice Extreme Programming and Scrum.

I'm not going to elaborate too much here on what I feel is missing from the existing apps, but discussions with other developers have consistently reinforced my thinking; there's a better way to do it.

I've been throwing the key features around in my head for several years now. I started out by telling myself not to be so daft – "the world doesn't need yet another Agile project management app!" And yet, I struggle to use any of the existing apps. It seems that I'm not alone, as building your own an agile app is so common that it's become something of a cliché in developer circles.

Early in 2011 I approached a good friend and excellent designer with some sketches of what I'd like to be using, and he converted them into beautiful screenshots. You can see them on the tour page.

The developers that have seen the mockups have all seemed keen to use it. That's a great start, but the question that has been nagging at the back of my mind is whether they'd buy it if they didn't know me. Would they even think it was worth a look? How many people really have the same problem that I do?

Going Lean

How do you test whether anybody would pay for your product idea? Asking your friends is all well and good, and it's great when they're enthusiastic, but they're also biased. For the most part they already know how I approach project management, and they know that it works. They also want me to succeed, so they're egging me on.

Their positivity has encouraged me to give the idea a proper go -- I've given up the day job to focus all my attention on building a company around the idea. And yet, I can't risk investing several months of my life in building my vision of the perfect agile app, as I am not my customer!

So I'm giving the techniques in The Lean Startup a try.

I need to invest as little effort as I can in order to demonstrate that I stand a good chance of selling my app. I need to build a minimum viable product (MVP):

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning with the least effort. -- Eric Ries

So how do I identify my first MVP? To do that I need to identify a hypothesis to test, and then think of ways to test it.

I'll be writing more on that in a later post. I'm also writing a series of articles called Building the Agile Planner over on the Agile Planner blog (you can subscribe here), where I'll be writing up how things have gone. Forthcoming posts on effectif.com will either cover what I'm learning about Lean, or more of the standard technical stuff that I've posted in the past.

Effectif Development

Write a quick draft while it's fresh

Securing Instiki with an SSH tunnel

So, what about security?

Using QUnit with CoffeeScript

Downloading QUnit

The test suite HTML file

Running your tests

Loading tests from external files

Loading third party libraries

Adding a stubbing/mocking library

Re-running the tests automatically

QUnit or Jasmine?

Evaluating Jasmine

Speed of setup

Simplicity

Support for Continuous Integration

Thoughts on Jasmine

Evaluating QUnit

Speed of setup

Simplicity

Support for Continuous Integration

Thoughts on QUnit

What I picked...

Links

Showing your laptop battery status in tmux

Move commits from one branch to another

Making the topic branch

Removing commits from master

Back to work...

An insurance policy

Navigating your bundled gems in Vim

Installing ctags

Installing guard-ctags-bundler

Configure Vim

Don't store tags files in version control

Using ctags in Vim

Useful links

Running MacVim in your terminal

Launching the GUI

Patching "bundle open" to set your current directory

Holy shit, I'm an entrepreneur!

Going Lean