We use Apple macbooks. Preferably 13”’ macbook pro’s or airs because for portibility purposes. To install your laptop. Please checkout the chapter on new laptop setup.

Ruby / Rails version management

Versions are managed by rbenv. We user 2.4.0 of Ruby at the moment.

Authorization

We use can can for authorization

Authentication

We use devise for authentication. Sometimes with register flows, sometimes wihtout out and only Facebook etc.

Use of .rbenv-vars

All the settings will always be stored in ENV variables. Make sure you have rbenv-vars installed. To enable this.We use ENV vars because its easy to use for container setups such as HEROKU. Don’t ever check in your ENV vars.

Active-admin for rapid datamodel prototyping

We use active admin heavily its amazing to flesh out a database model quickly. We usually start by building the admin screens first, this is usually done in a couple of days. After this is done and the client is content we start focussing on the front-end.

This allows us to:

  • Deliver the back-end quickly and iteratively (usually on day one)
  • Give the client the opportunity to already get familiar with the datamodel
  • Check if we have any fields missed

Use rebuild rake tasks

We use a couple of rake tasks prefixed with rebuild to:

  • Build after a clone rebuild
  • Rebuild the database for guard rebuild:guard
  • Get remote production data local and rebuild and test against the current codebase rebuild:from_production
  • To get a presentable state rebuild:for_demo which can be demo’ed

Promote model concerns

We isolate cross-cutting model functionality into its own ActiveSupport::Concern. This promotes re-usability and cross-project sharability. It also prevents cluttering your models.

Think of legit concers such as:

  • Followable
  • Commentable
  • Sluggable

Make sure concerns don’t leak. I.e. a concern should be standalone, reusable and strive for not needing extra methods on the model implemting the concern to work. If this is needed anyway it needs to be defined when including the model.

The public folder

  • Make sure you only check in stuff you actually need. Not for test or development.

Usage of guard

Guard enables us to rapidly prototype new functionality, we use guard for:

  • Rapid database prototyping with active admin
  • Running tests automatically

Testing with Rails

We do system tests, we’re not in the cult of TDD. But we try to have high level system tests that test the system as whole. We use capybara and poltergeist/selenium chrome for this. We use rspec for the the tests

Samples tests are:

  • Password retrieval test
  • E-mail deadline reminder tests

Continuous integration

We use continous integration from Cicle CI for our test suite. Every push/pull-request is being checked against our test suite.

  • reke test to check for tests
  • bundler-audit on every build to check for reported vulnerabilities
  • brakeman to check for obvious code leaks
  • simplecov for checking for code coverage misses

When a build on master is done, it automatically published that version on the staging Heroku. Every other branch is not pushed.

Circle CI settings

general:
  artifacts:
    - 'docs/'
    - 'coverage/'
machine:
  environment:
    DISABLE_SPRING: 1
    DOCIFY: md
    SECRET_KEY_BASE: XX
test:
  post:
    - bundle exec bundle-audit update
    - bundle exec bundle-audit check
    - bundle exec brakeman -z
deployment:
  staging:
    branch: master
    commands:
      - git push -f [email protected]:my-staging.git $CIRCLE_SHA1:refs/heads/master
      - heroku pg:reset DATABASE_URL --confirm my-staging --app my-staging
      - heroku run rake db:migrate db:seed --app my-staging

Things concerning gems and our policy

When including external gems in our projects please consider that these need to be maintained and probbaly contain bugs.

Adding a new gem to an rails project

When you’re adding a new gem be aware that:

  • You need to make sure that you upgrade the gem, more things can break.
  • You are increasing the attack vector, the gems might be vulnerable or its dependencies might be vulnerable.

When adding a gem, please announce it in your pull request, and announce it in the SLACK room and make sure your peers are ok with this. Please make sure that:

  • The gem really adds value, its something you cant do yourself. Or its more secure. For instance device/clearance vs roll your own.
  • The gem isnt bloated for the problem your trying to solve.

When using a gem from source

Fork a gem when using a fork from source (i.e active Active-admin). We use bundler-audit for our gem checking. It doesnt play nice. Also forking the gems allows us to manually upgrade more concise, and more aware.

Guidelines for picking a gem

  • Check if there is a gem around which does the same but with less code, but make sure you also keep in mind the userbase, the size of the gem its dependencies.
  • Check if the gem is being actively developed

Frequently used gems in our projects

  • Pg - Our database driver
  • RBENV - For ruby version management, over RVM
  • SLIM - For HTML markup, over ERB, HAML
  • SASS - For CSS (with .sass)
  • Testing - Minitest
  • Simpleform - For easy forms
  • Carrierwave - For resizing and uploading images (with minimagick)
  • Spring - For faster reloading
  • Active-admin - For creating admin screens fast
  • byebug - For ruby debugging
  • capybara - For testing
  • poltergeist - For phantom js based testing
  • better_errors + binding_of_caller - Better error handeling
  • Guard - For automatic running of tests, migrations and livereload
  • Omniauth - For authenticating against OAuth
  • GraphQL - For building GraphQL APIs
  • neat - for responsive css

Database migrations

Try to create as least possible migrations, and endless list of migrations clutters the view. Feel free to modify existing migrations as long as they arent pushed to production or break existing functionality.

  • Keep migrations clean and easy to read
  • Make sure migrations are ALWAYS backwards compatible with your codebase. I.e the migrations are not allowed to break the codebase running on production. This allows for ZERO downtime deployment.

Security of our rails projects

Security is important, we try to be as secure possible

Test run CI ssecurity checks

  • Brakeman
  • Bundler-audit

SSL

  • Use rails config.enforce_ssl
  • Use lets encrypt for our our SSL certs