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 3 has been released!

My beloved Reek gem has come quite a long way. During the last months we refactored so much of the source code that it almost feels like a new and shiny gem.

Right after the release of Reek 2 we started to work on Reek 3 which we released a couple of days ago.

 A stable API

The changes that I’m most exited about is that we agreed on a public API and implemented it as well. For this API to use you’ll basically just do something like this:

require 'reek'

reporter = Reek::Report::TextReport.new
examiner = Reek::Examiner.new("class Klazz; def m(a,b,c); end; end")
reporter.add_examiner examiner

which would give you this

5 warnings:
Klazz has no descriptive comment (IrresponsibleModule)
Klazz#m has the name 'm' (UncommunicativeMethodName)
Klazz#m has unused parameter 'a' (UnusedParameters)
Klazz#m has unused parameter 'b' (UnusedParameters)
Klazz#m has unused parameter

Continue reading →

How to recruit great developers

I believe there are 3 ways of recruiting when it comes to technology and startups (ignoring agencies and freelancers):

 Nr 1 or the common way: Non-organic recruiting through cold calls and direct search

The “standard” way to do recruiting which probably never works out well for anybody.
Unless you are looking for interns, juniors or freelancers (no offense intended, that’s just the way it is).

There are many reasons why this approach does not work:

  • Developers prefer to be approached by technical guys and not by somebody who thinks that a “javascript” developer easily fits into a “java enterprise” environment I mean, why wouldn’t he, both positions have the word “java” in it ;)
  • Good developers often don’t respond to contact requests from xing and linkedin since their inboxes are already flooded with messages
  • It’s hard for a non-technical person to assess the quality of a developer...

Continue reading →

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 →