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.
We use can can for authorization
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 the database for guard
- Get remote production data local and rebuild and test against the current codebase
- To get a presentable state
rebuild:for_demowhich 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:
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
We use continous integration from Cicle CI for our test suite. Every push/pull-request is being checked against our test suite.
reke testto check for tests
bundler-auditon every build to check for reported vulnerabilities
brakemanto check for obvious code leaks
simplecovfor 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]ku.com: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
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
- Use rails
- Use lets encrypt for our our SSL certs