My Favourite Books About Products & Programming

Alright, so here’s the list of my favorite books when it comes to product design, product management and programming:

Product Design, Product Management

Programming

Why you should squash your commits and how to do that

When I look at our bigger pull requests, I can see that they often contain dozens and dozens of commits. With 90% or more of them containing useless commit messages like “Fix.”, “Typo”, and so on.
This implies that this very pull request / branch is not atomic, meaning that “it does not behave like one single entity, but like a lot”.

What’s the problem with this?

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

For instance, with a proper git-log you can just type in “git log” and you can immediately see the last significant changes to the source – something that is utterly impossible when you merge branches with hundreds of commits. If one feature is split across many commits git-log is useless because it can’t tell what belongs where (I am aware that git-log can show you what commits belonged to what branch but this is still useless in most cases because it is just not terse and concise enough for the human brain to operate on)

2.) Bugfixing can be significantly easier if you know what commit introduced this very bug because it gives you context (something that is lost in multiple, meaningless commit messages). Not to mention that you can use git’s finest tools like git-bisect.

3.) If I realize a feature has gone wrong and I need to remove it from master I can’t do that if this feature is spread across multiple commits which are already intertwined with master without a huge, error-prone effort.

4.) If one feature is one commit I can easily play around with, e.g. deploy features in different combinations to staging servers.

How could we improve this?

The canonical git approach to this would be: Squash it.

To give you an example:

Say you have a feature branch called “fancy-feature” with a corresponding pull request where you want to squash the commits before you merge the PR. Here’s what you’d do:

git lp master..fancy-feature  # my alias for log –decorate –pretty=oneline –abbrev-commit
 
2b2197f (HEAD, fancy-feature) Fix whatever.
5c0ff6b Typo.
1d96940 Fancy Feature.

As you can see, we have 3 commits in this branch that are not in master. Let’s squash that:

git rebase -i master # -i for “interactive”

Now the following edit screen pops up in your favorite editor (whatever `env | grep -i editor`) says:

1 pick 1d96940 Fancy Feature.¬
2 pick 5c0ff6b Typo.¬
3 pick 2b2197f Fix whatever.

Let’s transform this to:

1 pick 1d96940 Fancy Feature.¬
2 f 5c0ff6b Typo.¬
3 f 2b2197f Fix whatever.

I replaced the “pick” in the last 2 lines with “f” for “fixup” which means: “meld into previous commit, but discard it’s commit message” (there’s a helpful explanation in the rebase view as well)

Save the file and exit it. That’s it. Now let’s look at this branch again:

git lp master..fancy-feature 
1e8ae44 (HEAD, fancy-feature) Fancy Feature.

Now it’s just one shiny commit.

The last thing you need to do is update upstream:

git push -f origin fancy-feature

The “-f” flag is the important thing here. You changed history in your branch (which is intentional and ok in a branch) so git requires us to pass this flag to tell git that we really want this.

What’s the downside of this?

- You need to get used to doing that at the end of the lifecycle of each branch. However, once you get used to this you’ll hardly notice it again.

- force pushing. Potentially dangerous if this happens on master. Again, using aliases and sticking to workflows mitigate this. E.g. I have this

[push]
  default = tracking

in my .gitconfig, so for me it’s just “git push -f” without even having to specify the branch name (so there’s no potential of screwing up the branch name or whatever)

- We lose the commit history within a pull request. However, I have never seen that this was a problem because after a feature is done and approved you’ll almost never be like “Why again did I go from this to that?”. And even if you were, the git history would be the wrong place for me in any case – such a rationale would be better placed in a changelog entry or a source code comment.

Who else is doing it like this?

Basically every popular open-source project (e.g. Rails, Sinatra, and so on).

Check  out the rails log:

05ab902 Merge pull request #15042 from arthurnn/revert_dirty_transactions
314cbea just call the method and assert the return value
198d9e3 Reverts “Fix bugs with changed attributes tracking when transaction gets rollback”
0a7beb1 Merge pull request #15041 from arthurnn/update_ruby
e019ffa Use ruby 2.1.2 on travis
ea58684 add tests for path based url_for calls

Also notice the “Revert” commit in there. Something impossible for us to do now. Besides that, the git log looks flawless and actually helps you to see what’s going on since one commit == one meaningful addition to the code.

What I expect from a great employer

Alright, so here’s my list.

First of all, I expect any decent employer to pass the “Joel Test”

Now, of to my basics:

  • Salary. Don’t try to start out with cheapest offer you can come up. No virtual shares as incentive. I’ve never seen those work out for anybody.
  • Product. In order to care about it, I need a product that solves a concrete problem and is not sales-driven. Bonus points: It makes the world a better place. This excludes everything that is even remotely connected to ecommerce, marketing or advertisting.
  • Commute / home office. Offer me the possibility to do home office one or two days a week if I live more than 20 minutes away. It’s 2014, not 1976.
  • “The mission”: If you’re just exit-driven, don’t bother to approach me. I want to work with real entrepeneurs – that means people who care about the product, the company and the employees and not about the quickest exit possible.

The intricacies:

  • Overhours. They might be necessary sometimes but they certainly should not be the rule.
  • Don’t try to enforce a company culture. This just happens or …it doesn’t. The only thing you as an employer can do is set up the environment for it. Having semi-automated, semi-mandatory team events every month is not the right way to do it.
  • Company meetings. Only have those when you have something to say. Don’t do them regularly because people will just talk because they have to say something.
  • Meetings in general. Don’t do it unless you a) have an agenda, b) have a moderator and c) have a tight time frame.
  • Managers. The less, the better. Delegators are useless at best, in most cases they are harmful
  • No interruptions. Or at least schedule them properly. You know what happens when you interrupt a programmer, don’t you?
  • Give me time to learn and develop myself. It always puzzles me that in an industry where knowledge and learning is everything you’ll rarely find companies that give you time to learn. You’ll hear crap like “We’d like to do it, but we’re not google”. Guess what, genius, that’s exactly the reason why you’re not google. One day a month for open source work and learning new languages and technologies is a win-win for everybody.
  • Don’t be cheap. Don’t make me explain why I need this ebook which costs you 20 Dollars. Don’t try to find the cheapest accomodation possible for a conference. It’s  disrespectful and it kills my motivation.
  • Involve me in the product. If you treat people like ticket slaves this is exactly what you get: ticket slaves.

git workflows and best practices

Everyday git

Preliminary remark: I use a bunch of shortcuts and abbreviations here for git commands which follow the official “git best practices” and you should configure your environment accordingly as well. See https://github.com/troessner/dot/blob/master/.gitconfig

How to create a feature branch / pull request

  • Create feature branch and switch to it

    git co -b feature_branch

  • Publish it on remote

    git ps -u origin feature_branch

Hint: If you use a tool like:

you can get this done even quicker.

  • Do your changes
  • Stage them

git add -p

Yes, that’s a “-p” there. Please do never use

git add .

  • When you think you’re done commit everything

git ci -m ‘Your meaningfull commit message in proper english.’

  • Publish them

git ps

Now you can open up that pull request on github. Tip: Becomes even easier with the github gem.

This pull request should be reviewed and commented by one of your peers before anything else happens.

What should I do after the pull request has been merged?

  • Close the pull request remotely and delete the branch via github interface (there’s a button showing up after you merged / closed that pull request.)
  • Delete the branch locally via

git b -D your_feature_branch

How to squash all commits from on PR into one?

First of all, you need to understand why it is absolutely necessary that your whole PR is one, atomic pull request:

  1.  git-log is one of the most important git tools and if you’re not familiar with it, you really should learn about it (more to come here soon). However, if one feature is split across several commits git-log is useless because I can’t tell what belongs where.
  2. If I realize a feature has gone wrong and I need to remove it from the mainline I can’t do that if that feature is spread across multiple commits which are already intertwined with master without doing potentially dangerous rebasing. This would also require that I do know exactly what commits belong to what feature which is next to impossible, even after a short time.
  3. If one feature is one commit I can easily play around with, e.g. deploy features in different combinations to staging servers.

So how do I do that?

Ok, so let’s say you have 3 commits in your feature branch that do not exist in master and your feature branch is named “fancy_feature”.

First of all we need to find out how many and what commits that are:

The two most common methods would be:

git log fancy_feature –not master

git log master..fancy_feature

However this gets tedious to repeat so you want to do something similar to what I did and add an alias to your bashrc (or whereever it fits you) like this:

alias sh_exclusive_commits=’git log $(git symbolic-ref -q HEAD) –not master –pretty=oneline –abbrev-commit –decorate’

So now, when I execute

sh_exclusive_commits

I get (given that I am on the feature branch of course):

9c5ec4b (HEAD, fancy_feature) Finalize feature.

6b24ba0 Fix foobar.

b3210dc Update foo to do bar.

Now let’s squash those commits into one:

Generally you would do it like that:

git rebase -i master

which tells git to take the last commits starting from HEAD (the commit on top of the branch you’re working on) that are not in master.

Now, if you execute this, you’ll see something like this:

  pick b3210dc Update foo to do bar.$

  pick 6b24ba0 Fix foobar.$

  pick 9c5ec4b Finalize feature.$

# Rebase 82ed078..9c5ec4b onto 82ed078

What you want to do now is:

  • Squash those 3 commits into one
  • Give that one commit a proper name
  • Merge it back into master

To do that this is what the menu should look like:

r b3210dc Update foo to do bar.$

f 6b24ba0 Fix foobar.$

f 9c5ec4b Finalize feature.$

This tells git to “fix up” 9c5ec4b and 6b24ba0 into b3210dc and rename b3210dc in the same step. If you save that file now git will perform those operations and then let you rename b3210dc. Now to the last steps:

git co master

git cherry-pick your_final_commit

How to make objects behave like ActiveRecords models…

…and make them usable with rails form helpers as well.

1.) Use ActiveModel

Add

    include ActiveModel::Validations

to the top of your class in question. Now you have all the standard validations like

  validates :field, presence: true

at your hands.

2.) Make it possible to initialize your objects ActiveRecord style:

    def initialize(attributes = {})
      attributes.each do |name, value|
        send("#{name}=", value)
      end
    end

3.) Make them usable with rails form helpers

I am not sure if this the “right” way to do it, however it worked pretty well for me.
You need to add

def to_key; nil; end

otherwise rails will complain if you use this object with a form helper:

undefined method `to_key' for

Of course this doesn’t have to be nil, it can be anything that works as a key.

Elastic Beanstalk and Ruby / Rails – Stay away

Recently I wanted to switch our deployments from manual setups to something more suitable and automatable in terms of scaling, process management and so on.
Since we were already on EC2, Elastic Beanstalk was the first thing that came to mind:

From the docs:

AWS Elastic Beanstalk is an even easier way for you to quickly deploy and manage applications in the AWS cloud. You simply upload your application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring.

Seems like a good fit. Unless it isn’t.

So what’s the problem with Elastic Beanstalk?

Nothing f***ing works. Nothing f***ing works.

First of all, you need to understand one thing: I tried to get a basic rails app up and running. I did absolutely nothing by hand – I only used amazon’s built-in steps. This means I exclusively used amzon’s webinterface. No manual fumbling on the instances itself.

Now, even with this basic setup I had problems all of the time. Below a list errors that randomly popped up and in the same manner disappeared again from deployment to deployment:

All of a sudden my ruby setup seems borked big time:

2013-04-26 08:18:48,080 [INFO] (29466 MainThread) [directoryHooksExecutor.py-29] [root directoryHooksExecutor info] Output from script: /usr/bin/rake:9:in `require': no such file to load — rubygems (LoadError)
from /usr/bin/rake:9
Rake task failed to run, skipping database migrations

WTF?

Events / logs are not reliable:

Trying to get the logs after a failed deployment gives me:

Failed to pull logs for environment instances. Reason: Some instances have not responded to commands. Responses were not received from [i-52f6fc18].

Or:

In the “Events” Tab I see:

Failed to deploy application

However there is NO error in the logs and despite what the “Events” say, deployment apparently was successful

All of a sudden my rails setup is borked:

From the logs (after more than a dozen deployments):

2013-04-19 10:25:38,717 [INFO] (1831 MainThread) [directoryHooksExecutor.py-29] [root directoryHooksExecutor info] Output from script: rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)

(See full trace by running task with –trace)
Rake task failed to run, skipping asset compilation.

Apart from this seemingly random bugs which come and go as they please, I am pretty sure that almost no one is using EB for ruby / rails. You can google for any problem you have and you find nothing. It seems like amazon just added this specific layer because it is hip.

All in all, using Elastic Beanstalk was a horrible experience and I can’t recommend it to anybody. Funny enough I tried out amazon opswork after Elastic Beanstalk and so far, this has been nothing short of fantastic.

Long story short: If you want to use amazon deployments mechanisms, use opswork, not Elastic Beanstalk.