Timo Rößner

Life-long student, part-time failure, avid creator, hopeless humanist, softcore objectivist, amateur scientist. And professional rocketeer.
Director of Platform Engineering (Berlin) at Planet and maintaining the awesome Reek gem.

Page 2

Reek 2 just got released!

A couple of days ago we released the new and extremely shiny Reek version 2 to the world!

Reek is a static code analyzer for Ruby detecting so called code smells. Those code smells range from rather trivial ones like UncommunicativeParameterName or TooManyMethods to high-level code smells like FeatureEnvy or DataClump.

In the most simple use case you can just run

reek my/source/files


echo "def dirty(x,y,z); puts 'hossa!'; end" | reek

 So what has happened since 1.*?

There are way too many significant changes to list them all so I restrict this list to my favourite ones (excluding the countless bugfixes):


Parsing with the parser gem allows us to support all major Ruby versions:


We deliberately dropped support for 1.8.

 New smell detectors

We introduced 2 new smell detectors:

  • The ModuleInitialize smell detector
  • The PrimaDonnaMethod smell

Continue reading →

Why you should squash your commits

When you look at bigger pull requests at open-source projects or in closed-source projects of your company, you can see that they often contain dozens and dozens of commits with a lot of them containing useless commit messages like “Fix.”, “Typo”, and so on.

“Useless” in th sense of the bigger picture - while you might care for a “typo fix” during the lifecycle of your pull request you probably won’t a couple of weeks down the road.

Having a lot of commits in one pull request / branch makes it not-atomic, so it “does not behave like one single entity, but like a lot”.

I believe there are strong reasons for squashing all of your commits into one right before merge.

But let’s start the other way round here.

 What’s the problem with merging pull requests with a lot of commits?

  1. git-log is one of the most important git tools and using it properly can make our lifes a lot easier. For

Continue reading →

Jumping off the pair programming bandwagon

For quite some time, a lot of companies have been on the “yes, we do pair programming” bandwagon and still are. Some of them even to the (ridiculous) extent that pair programming was or is mandatory a la “at least 2 days a week”.

I’ve been through that and those were certainly some bad times in my software development career.

I have always been sceptical of pair programming to begin with.

First of all, it’s synchronous. You have to pay attention that very same time your partner pays attention. But people and their rythm are different and if you do this all day, this gets exhausting very quick.

Second, regardless of what technology you’re using, there will always be artefacts you have to generate and update, tests to run, a network connection you wait for and so on. If you use a language or framework that is more machine-friendly than developer-friendly this might amount to a lot. But

Continue reading →