Fun coding tips – by Carsten Gehling

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.

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

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?

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
  somebranch

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)

	.ruby-gemset-master
	.ruby-gemset-somebranch
	.ruby-version-master
	.ruby-version-somebranch

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:

.gitignore


.ruby-version*
.ruby-gemset*

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

.git/hooks/post-checkout

#!/bin/sh

# 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 ];
then
  cp -f .ruby-gemset-$BRANCH .ruby-gemset
else
  cp -f .ruby-gemset-master .ruby-gemset
fi

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

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:

$HOME/.bashrc

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!

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.

Ruby:

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
  end
end

20.times { puts fib.next() }

C#:

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)
            {
                Console.WriteLine(f);
            }
       }
    }
}

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.

Skriv et svar

Din e-mailadresse vil ikke blive offentliggjort. Krævede felter er markeret med *