Love, caffeine and omlette

Month: March 2013

Create lorem ipsum text with TextExpander and lorem

Often I need dummy text to fill out a form.

I use a combination of TextExpander and the Lorem Gem that makes this
super simple.

Step 1: Install the "lorem" gem

Install the gem lorem using

sudo gem install lorem

It's simple to use:

# For 1 paragraph dummy text
lorem 1 paragraph

# For 140 chars dummy text
lorem 140 chars

Lorem is a Unix tool - you can combine it with other commands:

lorem 140 chars | pbcopy

Copies 140 chars into your clipboard.

Textexpander + Lorem

I dont want to go into my Terminal, whenever I fill out a
form in Chrome, so I created a TextExpander snippet, that executes lorem
for me and fills in the dummy text.

lorem %filltext:name=paragraphs:default=1%

A nice additional feature is that it asks you how many paragraphs of dummy text you want.


Sometimes simple hacks like this save you a lot of time. I hope you find it as useful as me!

Pair Programming - The why.

Pair Programming means that 2 programmers work on the same problem together at one workstation.
One of them is the driver - the guy who writes the code. The other programmer is the navigator who things on a more strategical level, helps with fresh ideas and asks questions. Both of them should switch frequently.

Pair programming
Pair programming from Syneus Solutions. (CC BY-NC-SA 2.0)

For most programmers this is completely unfamiliar in the beginning. It's not very easy to learn - and it's not for everyone. But learning to pair can be worth it.

Benefits of Pair Programming

Zero friction reviews

Do you do Code Reviews? We at Helpster have the 4-Eyes-Rule: Every piece of code has to be verified by a second pair of eyes.

Pair Programming of course offer just that. You have constant review of your code. And even better: You can directly incorporate it into your code.

Live up to your own standards

Do you have high standards? Do you want to do TDD for example? Do you wan't nice commit messages? Do you want to talk to your Product Manages more often? Write code that the whole team understands? We do!

Pair Programming is great to live up to your own standards: A good navigator has time to think about all of this. It's so much harder to be sloppy, when you are tired if your pair is watching you 😉

Teamwide learning

I learned so much from my pairs, during the last years. Of course you can learn small tricks like using ClusterSSH to admininster servers, or a short hand to create new files. But you might also find yourself using Vim and ask yourself how the hell you can work with it.

You learn a lot during a Pair programming session
Fall 2011 Student Hackathon Coding from @matylda. (CC BY-SA 2.0)

Often you implement something that your pair wanted and the solution is very nice and elegant - more then any of you two might have achived.

Since pairs should switch frequently there is a very good knowedge distribution within the team after a while.

Concentration & Relaxation

A good partner can motivate you. Even the crappiest chore looks way better if you have someone that shares you're pain.

There are fever distractions in a pai. You do not get distracted from the outside or your own emails that often. And you have a good excuse to enforce you're Pomodoros 😉

It's just fun

Last but not least it's just fun. As a driver you have a navigator that
unstucks you all the time and gives you valuable feedback. Even the
worst tasks are just done.

It's very intense and rewarding and at the end of the day you end up
with code that is much better, then what you would have written - but you are also crushed. You go home after 8 hours and feel very good about it.


Pair Programming has a lot of advantages. It's very different in the
beginning, but it can be very nice in the end.

Of course there is not only light. But let's cover this in the next article 😉

How to prevent yourself from force pushing to master

I am pretty reckless sometimes. I forced pushed to master several days in a row.

What does a real programmer do? - He writes a script that prevents him from doing it ever again, of course..

For the longest time this was a little complicated - you had to
install a hook onto the remote repro. For Git >1.8.2, there's a pre-push hook that was just perfect for my script.

If the hook returns an error the push is not executed.

The script

So this is the git hook i came up with.

#!/usr/bin/env ruby
# Pre-push hook that rejects force pushes to master.
# Requires Git > 1.8.2

class PushRejecter  
  def run
    if pushing_to?(:master) and forced_push?

  def pushing_to?(branch)
    `git branch | grep "*" | sed "s/* //"`.match(branch.to_s)

  def forced_push?
    `ps -ocommand= -p #{Process.ppid}`.match(/force|pfush/)

  def reject
    puts "Force push to master rejected."

  def allow

Ignore the over engineering please..

If the current branch is master and i am force pushing it does return an error and the push is not executed.

How to install it

All my hooks are stored in a folder called ~/.git_template.

It is configured as my template directory for git:

  templatedir = ~/.git_template

In order to activate the hook you have to go into all your existing repros and execute

git init

This will install the hook for you. As I mentioned you need Git >1.8.2.

Alternatively you could place the hook in the .git/hooks/ directory manually in each of your repros.


I am more confident, that I will not cripple a master branch again. A nice feeling. If you like to have a look at the rest of my setup I recommend a look at
my dotfiles.

Lessons from the Dojo: Roman Numerals

A few days ago we had one of our Coding Dojo's at This time we tried to implement the "Roman Numerals kata".

I always learn a ton, solving such seemingly simple problems.

Have a look at our (unfinished) code

Here are the tests:

describe RomanNumeralsConverter do
  let(:converter) { }

  def convert(number)

  it 'returns an empty string for 0' do
    convert(0).should == ''

  it 'returns I for 1' do
    convert(1).should == 'I'

  it 'returns III for 3' do
    convert(3).should == 'III'

  it 'returns IV for 4' do
    convert(4).should == 'IV'

  it 'returns V for 5' do
    convert(5).should == 'V'

  it 'returns VI for 8' do
    convert(8).should == 'VIII'

  it 'returns X for 10' do
    convert(10).should == 'X'

  it 'returns IX for 9' do
    convert(9).should == 'IX'

  it 'returns XIV for 14' do
    convert(14).should == 'XIV'

Here the implementation:

class RomanNumeralsConverter
  SPECIAL_VALUES = {0 => '', 5 => 'V', 10 => 'X'}

  def convert(number)
     result = ''

     while number > 3
       if SPECIAL_VALUES.include?(number+1)
         result += 'I'
         number += 1

       nearest_boundary_under_number =

       if nearest_boundary_under_number >= 0
         result += SPECIAL_VALUES[nearest_boundary_under_number]
         number -= nearest_boundary_under_number
     number.times do
       result += 'I'

  def nearest_boundary_under_number(number)
    SPECIAL_VALUES.keys.delete_if {|i| i > number }.max

Duplication in tests

We tried to remove duplication from the tests. I think we failed.
One of my teammates pointed out that PHPUnit has
DataProviders for this kind of test data.

I didn't think that this was a good idea - but looking at the tests now I have to admit that
there is virtually no value in writing the tests spec style for this kind of problem.

Write the simplest tests first

We had quite a hard time with the substraction rule (4 => IV).
We wrote a test for the 4 very early - I think we could have made it
easier for us by first ignoring the substraction rule and focusing on
all cases where it does not apply.

  • Write the easy tests first
  • If you hang try another test

Accept weired code

We "cheated" quite a bit using an array for the special cases. It just
didn't look right. Supprisingly it came together at the end of the session anyway.

  • Accept weired code

When to abstract

Right at the beginning one of my colleagues pointed out, that we just
could create a big array with a mapping between all the arabic number to
the roman numerals and use that. I think he had a point..

But since we wanted to create an algorithm that was no option. We
started with a big if / elsif / else statement. That was fine for 2 or
3 tests, but then we were moving sideways. No algorithm was going to emerge.

That's when you need to stop and think about how to abstract a little bit further.

  • Identify when you are moving sideways - then start abstracting

The end

No world moving lessons - but valuable non the less. Thats why I like coding dojos -
they are a good place to reason about the nature of programming, without
having to write production code.

© 2017

Theme by Anders NorenUp ↑