In this chapter we try to cover the bare essentials on working with us as a developer. We cover our general development approach, some of our best practices that seemed to work over time.

Stuff to be installed on your machine

  • OSX or a Linux variant prefered.
  • Sourcetree
  • Rbenv
  • Ruby build (with 2.1.3)
  • Rbenv vars
  • Git
  • Hub
  • Brew
  • Brew Cask
  • Sequel Pro
  • Pgweb
  • Sublime text (we use this, but you can use whatever you like!)
  • Sublime Package Manager
  • Vagrant
  • Git hipster
  • Git extras
  • Awk

Check the tools page for an overview of all our tools.

Tabs vs spaces

We all use spaces, with 2 space as a tab. This is in order to make sure all the code looks everywhere the same. This is especially handy when looking in code online such as Github. We use a .editorconfig in order to enforce this.

Git setttings

We do a lot of rebasing, please use the following git setting in order to make sure you don’t push all the branches when git push -f after a rebase.

git config --global push.default current

Some git tools to make life easier

  • Use git-extras from HollowayChuck - Because it makes it easy to create feature/bug brances which show up pretty in source tree.
  • We use source tree because it’s easy to use, and shows you feature branches pretty. We mostly use then command line for doing actual work. Your free to choose your own of course. We use lice cap to show little things we’ve made in Pull Requests

Implementing features, fixing bugs and contributing code

We have a nifty way of contributing code go check the chapter

Check the How we implement using pull-requests.

Definition of done for developers

  • Is story/functionality implemented?
  • Are there no unecessary files committed?
  • Is the styling applied? Does the design look good?
  • Is it shippable? Can the functionality be potentially sold? Is it actually done?
  • Are there tests? If so are they passing on the CI server?
  • Is the documentation updated?
  • Is it deployed to heroku? Is it viewable for others?
  • Is the code peer reviewed and has everyone involved given the ok on it?
  • Is the pull request syncronized with master and has it been merged?