Whether it’s reviewing open source project, or using git on a private project, we all spend a lot of time looking at diffs. Although some prefer graphical interface clients I use plain command line.

But to really understand a code change, we sometimes need to see more than just the default three lines of context especially in cases when long method names.

That’s when this git option come in handy:

git diff -U15 app/models

It generates diffs with 15 lines of context instead of the usual three.

Depending on your commit you may set the most appropriate number for lines of context to get the exact amount of context info.

In this post I’ll try to explain why you should avoid naming your RSpec scenarios like

• it "does something"
• it "works"
• it "passes"
• it "fails"
• it "does not fail"

Read More

You may be familiar with annotate gem(GitHub, Rubygems). Neat library that adds comments summarizing the current DB schema to the top of each of your model/factory/spec. First time I’ve used it in production project(5+ yrs ago) it felt really handy, especially in big apps with lots of models and fields. I no longer needed to keep in my mind certain field names neither needed I to look them up in DB administration tools. Big productivity boost.

After using this whole model annotation concept in plenty of projects and thinking about it I would prefer not too use it in future projects. Here’s why:

Read More

Unstubbed network requests in specs come in all sort of issues:

• specs failing unpredictably due to connectivity issues
• significantly slower test suites
• hitting API rate limits on 3rd party services

So running specs in isolation should always be high in your priority list.

Read More

Any private gems in Gemfile that are hosted on bitbucket?

Add separate git_source for bitbucket provider to clean up your Gemfile. Here’s an example:

git_source(:bitbucket) { |repo| "git@bitbucket.org:#{repo}.git" }

gem 'my_private_gem', bitbucket: 'username/my_private_gem'