Jira StopWatch 2.1 released

With over 5.000 downloads, Jira StopWatch has become quite popular. This latest release 2.1 is mainly a maintenance release, that focuses on fixing some issues regarding TLS communication for secure connections. Head over to http://jirastopwatch.com and click “Get latest version” to read about the new stuff.

Jira StopWatch 2.0 released, and has its own website now

It’s now been 1½ years since I first released Jira StopWatch as an open-source project. A lot of changes has been made since then, but basically the application is about the same single feature: Tracking your workday, and doing it as effortlessly as possible. A lot of people has helped with this, for which I am grateful. It really shows the value of making software open-source. In the last 1½ years, the application has been downloaded over 4.000 times, something I had never anticipated.

Latest release is now version 2.0, and in the meantime Jira StopWatch has gotten its own website: http://jirastopwatch.com

The source code and binary releases are still hosted on GitHub, and will continue to do so, since there really isn’t any better open-source collaboration tool IMHO.


JIRA StopWatch 1.7.0 released

I’ve finally managed to release the latest version of JIRA StopWatch. It comes with a bunch of bugfixes and a few new important features. Read more about it and download it here.

Also, by now JIRA StopWatch has been downloaded over a 1.000 times, and I get a lot of positive feedback on Github and on mail. I appreciate the support – glad I can help make your workdays easier.

200 downloads of Jira StopWatch 1.4.1

200 downloads of Jira StopWatch 1.4.1

Woke up this morning and saw this. Jira StopWatch was released exactly a month ago, with not many people knowing about it, and now suddenly the setup program has been downloaded 200 times. Wauw! I thank you all, who have shown interest in this little tool, that sprung out of my own needs when working with Jira. Please don’t hesitate, if you have ideas for future features.

route_downcaser 1.1.5 – compatible with Rails 5.0

The Rails community released Rails 5.0.0.beta1 just before christmas. I’ve added this release to route_downcaser’s test-suite for version 1.1.5, and I’m happy to say, that everything works out of the box. So unless something substantially changes in Rails (which ought not happen), then there will be no problems with upgrading to Rails 5.0 – at least with regards to route_downcaser.

More info about the gem here: https://github.com/carstengehling/route_downcaser

Easy time-tracking when using Jira

I’ve made a small Windows* tool to make time-tracking with Jira much easier IMHO.

Jira StopWatch

Read more and get it here: http://carstengehling.github.io/jirastopwatch

The use-case goes like this:

At work I’m usually working on up to 5 issues at a time – sometimes an issue is waiting for input from somebody temporarily away. Sometimes I need to prioritise a new issue above others. So I need to be able to quickly switch between issues – and still make sure to track how long I’ve totally worked on each issue.

So if you’re interested, take it for a spin, and let me know if you have any suggestions for improving it.

A short screencast to show the usage:

Jira StopWatch tutorial from Carsten Gehling on Vimeo.

* It’s OSS C# and also compiles with Mono on Linux – somebody with a Mac care to try?

Automatic change RVM environment when switching Git branch

I use RVM all the time when I develop Ruby (and Rails) applications. It’s great for isolating Ruby environments and gem packages for a specific project. I also use git extensively – especially branching when developing new features for an app.

Sometimes a branch works with new gems, that I do not want to pollute my main project-specific gemset with. So I create a new RVM gemset for this particularly branch. This has had its own problems because a “git checkout” now also needed to be followed by a “rvm use” statement. Also having a .ruby-gemset file in the project root led to RVM resetting the current gemset as soon as I changed directory.

One solution could be to check-in the .ruby-version/.ruby-gemset files in each branch, but I don’t want to annoy fellow developers with my RVM files. So I came up with the solution below instead.

First for this example, I assume that you have a git repository containing a master branch and another branch. If not, here’s a quickstart to make this happen:

$ mkdir myproject && cd myproject

$ git init .

$ touch 1.txt

$ git add -A

$ git commit -m 'First master commit'
[master (root-commit) b578056] First master commit
 2 files changed, 2 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 1.txt

$ git checkout -b somebranch
Switched to a new branch 'somebranch'

$ touch 2.txt

$ git add -A

$ git commit -m 'First somebranch commit'
[somebranch d10e2c1] First somebranch commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 2.txt

$ git checkout master
Switched to branch 'master'

$ git branch
* master

Okay with that squared away, let’s get on with the actual steps. You need to create a RVM gemset for each branch (master and somebranch) with the appropiate .ruby-version/.ruby-gemset files. The principle is, that you rename them, so they have a postfix named after the branch.

First create for the master branch:

$ rvm --create --ruby-version 2.0.0@myproject-master
ruby-2.0.0-p643 - #gemset created /home/carsten/.rvm/gems/ruby-2.0.0-p643@myproject-master
ruby-2.0.0-p643 - #generating myproject-master wrappers..........

$ ls -a
.  ..  .git  .ruby-gemset  .ruby-version

Then rename the files:

$ mv .ruby-gemset .ruby-gemset-master
$ mv .ruby-version .ruby-version-master

$ ls -a
.  ..  .git  .ruby-gemset-master  .ruby-version-master

Now do the same for the branch “somebranch”:

$ rvm --create --ruby-version 2.0.0@myproject-somebranch
ruby-2.0.0-p643 - #gemset created /home/carsten/.rvm/gems/ruby-2.0.0-p643@myproject-somebranch
ruby-2.0.0-p643 - #generating myproject-somebranch wrappers..........

$ ls -a
.  ..  .git  .ruby-gemset  .ruby-gemset-master  .ruby-version  .ruby-version-master

$ mv .ruby-version .ruby-version-somebranch
$ mv .ruby-gemset .ruby-gemset-somebranch

Since the files are renamed as shown, they will not by themselves trigger an RVM gemset switch, if you enter the directory.

If you look at your git repo now, you will see the files as untracked.

$ git status
On branch master
Untracked files:
  (use "git add ..." to include in what will be committed)


nothing added to commit but untracked files present (use "git add" to track)

As stated in the beginning, we don’t want these files in the repository, so create a .gitignore file and add this:



Now comes the fun part. We are going to make a hook in our git config. Create this file



# Find current branch name
BRANCH=`git rev-parse --abbrev-ref HEAD`

# Copy branch-specific RVM files, if available - default to master-branch
if [ -f .ruby-gemset-$BRANCH ];
  cp -f .ruby-gemset-$BRANCH .ruby-gemset
  cp -f .ruby-gemset-master .ruby-gemset

if [ -f .ruby-version-$BRANCH ];
  cp -f .ruby-version-$BRANCH .ruby-version
  cp -f .ruby-version-master .ruby-version

And make sure, that the file is executable, since it is just a script:

chmod +x .git/hooks/post-checkout

After you have done this, everytime you checkout a branch, this script will be called. If you checkout somebranch, it will look for a .ruby-version-somebranch and .ruby-gemset-somebranch and copy them to .ruby-version and .ruby-gemset respectively. If you create a new branch but do not make a specific gemset for this branch, the script will instead copy .ruby-version-master/.ruby-gemset-master. So always as a minimum create these.

You might think that now you a all done. However if you try to checkout a “somebranch” now, things will seem strange. The .ruby-gemset file will be an exact copy of .ruby-gemset-somebranch, but if you call “rvm current”, you will still be on the master gemset. Why is this so?

The thing is: .ruby-gemset is now placed correctly, but will not be read by RVM until you change into the actual directory. Try this:

$ git checkout somebranch 
Switched to branch 'somebranch'

$ rvm current
ruby-2.0.0-p643@myproject-master      <== Not what we expected

$ cd .

$ rvm current
ruby-2.0.0-p643@myproject-somebranch  <== Much better

But this is still an extra manual step, that complicates things. You WILL forget this at some point, so let's get rid of it.

You need to edit your $HOME/.bashrc file and add this line:


git () { /usr/bin/git "$@"; cd .; }

This changes the git command to a function, which calls the executable git in /usr/bin with all arguments, and afterwards does the otherwise harmless "cd ." which will then make RVM reload the .ruby-version/.ruby-gemset files.

Exit the shell and open a new to reload .bashrc, and you're good to go.

Please let me know, if you have any trouble with the above. Everything has been tested, but evil typos may have creeped into the text.

Have fun!

Do you yield? Fancy Ruby stuff done in C#, part 4: yield differencies

Please read this post for my reasons behind this article series.

There are few things more aggravating – at least as a programmer working with multiple languages – than when a certain construction is implemented in two extremely different ways. I tend to mix them up and often try using the idioms from one language in the other.

One of these is the yield keyword, which is a very strong construction in functional programming. It exists in both Ruby and C# but works quite differently.

Let’s take Ruby first. yield basically breaks execution, and calls an anonymous code block that have been supplied to the function containing the yield statement. yield can take arguments as well.

yield is quite powerful to create enumerators. Let’s try to make the classic Fibonacci sequence as an “endless” enumerator. And then do the same in C#. Both with yield and look at the differences.


fib = Enumerator.new do |obj|
  obj.yield i = 0
  obj.yield j = 1
  while true
    k = i + j
    obj.yield k
    i = j
    j = k

20.times { puts fib.next() }


namespace fib
    class Program
        static public IEnumerable<int> Fibs(int size)
            int i = 0;
            yield return i;
            int j = 1;
            yield return j;

            for (int n = 0; n < size; n++)
                int k = i + j;
                yield return k;
                i = j;
                j = k;

        static void Main(string[] args)
            var fibs = Fibs(20);

            foreach (var f in fibs)

When you look at the two examples, there are some major differencies. In Ruby, the yield statement immediatly breaks execution of the code back to the caller's code-block (in this example the Enumerator itself). A state-machine stores all information about what was going on until the yield. So when the enumerator's next() method is called, the execution continues where it left off. This is why the loop in our Fibonacci generator can be infinite.

In C#, however, IEnumerable will run the Fibs function to the end. Each yield return statement will store its argument inside the Enumerable object, which can then later be iterated over. But that also means that you need to make sure that the generating loop exists at some point - hence the size argument.

Make testing possible with Rails and PostGIS

Inspired by this SO question:


I’ve had a lot of trouble recently with Rails and PostGIS. One of the main problem arised with testing. When you run Rails tests (or RSpec for that matter) the test database is always dropped and a new is created. The problem with this is, that the PostGIS extension is not created in this new database. Therefore your schema-load will fail, if you have any postgis-specific fields/indices.

The solution to this is to use a PostgreSQL database template – and of course the activerecord-postgis-adapter found here: https://github.com/dazuma/activerecord-postgis-adapter

First the template:

You need a PostgreSQL template with PostGIS functions support.

Create a template database:

$ psql -U postgres
> CREATE DATABASE template_postgis WITH TEMPLATE=template1 ENCODING='UTF8';
> \c template_postgis;

Load necessary PostGIS functions into template (your SQL files may be located in a different path, but they come with the PostGIS installation):

$ psql -U postgres -f  /usr/share/postgresql/9.1/contrib/postgis-2.1/postgis.sql template_postgis
$ psql -U postgres -f /usr/share/postgresql/9.1/contrib/postgis-2.1/spatial_ref_sys.sql template_postgis
$ psql -U postgres -f  /usr/share/postgresql/9.1/contrib/postgis-2.1/topology.sql template_postgis

Set database as template and grant permissions:

$ psql -U postgres template_postgis
> UPDATE pg_database SET datistemplate = TRUE WHERE datname = 'template_postgis';
> GRANT ALL ON geometry_columns TO PUBLIC;
> GRANT ALL ON spatial_ref_sys TO PUBLIC;

Now the adapter:

Add this gem to your Gemfile and run bundle:

gem 'activerecord-postgis-adapter'

After that add the adapter and the template to your config/database.yml like this:

  adapter: postgis
  template: template_postgis
  database: mydb_development

  adapter: postgis
  template: template_postgis
  database: mydb_test

And that should do the trick! Test it by running rake db:schema:dump and rake db:test:prepare.

Let me know, if you get any additional problems regarding this.

Nyt brød – bedre end det forrige

Mine tidligere forsøg udi brødets kunst har udviklet sig til nedenstående:


1.25 dl æblemost
0.75 dl mørk øl (f.eks. Rød Odense, Abbey Ale, Brown Ale e.l.)
3 dl vand
75 g rugmel
75 g fuldkornshvedemel
150 g hvedemel

Alle ingredienser blandes sammen og røres godt igennem med et piskeris. “Dejen” skal have en grød-lignende konsistens. Hæld dejen i en beholder med låg. Stil den på køkkenbordet, og lad den stå og gære i 3-5 dage – jo længere jo bedre. Undervejs vil dejen bundfælde, så 1 gang dagligt skal du røre i den.


10 g gær
20 g salt
1 knivspids sukker
200 g surdej (den som du lige har lavet ovenfor)
5 dl vand
50 g fuldkornshvedemel
ca. 600-700 g hvedemel

Put gær, salt og sukker i en stor skål, og rør rundt til gæren er smeltet (salt og gær flyder sammen). Hæld surdej, vand og fulkornshvedemel i og rør rundt imens. Lad dejen stå i ½ time. Tilsæt derefter hvedemel lidt af gangen, mens du rører grundigt. Tilsæt mel indtil dejen binder godt men stadig er lidt klistret.

Dæk skålen med et vådt viskestykke og sæt i køleskabet og hæve i 24 timer.

Efter 24 timers hævning:

Tag en bageplade frem og kom bagepapir på. Tag forsigtigt dejen op og slå den ned. Del dejen i 2 dele, form dem som brød og læg dem på bagepladen. Dæk brødene til med et viskestykke og lad dem efterhæve lunt i 1-2 timer. De vil nok flade lidt ud, men de skal nok hæve flot op i ovnen.

Efter 1-2 timers efterhævning:

Tænd ovnen og lad den varme op til 200 grader. Fjern viskestykket og sæt bagepladen i ovnen. Bag brødet ved 200 grader i ca. 35-40 minutter.

Eksperimenter med følgene:

  • Bag brødet med damp. Sæt en foliebakke med kogende vand ind i bunden af ovnen mens du bager. Det giver en mere smidig skorpe.
  • Lad sidste ½ times efterhævning foregå under damp (det kaldes raskning). Sæt en foliebakke med kogende vand på bagepladen mellem brødene, og dæk det hele til med en stor plastikkasse.
  • Hvis du har en god røremaskine, så brug endelig den – lad stadig dejen “ælte” i mindst 10 minutter

Vedligeholdelse af surdejen

I opskriften bruger du ikke al surdejen, og det er helt bevidst. Du kan nu spæde blandingen op med mere udfra samme opskrift som beskrevet øverst. Hvis du gør det, så vil den nye blanding allerede være klar til brug 1-2 dage efter. Så dermed går det hurtigere, når først du har startet processen.

Surdejen kan opbevares i køleskabet, når den først har gæret op.