No description, website, or topics provided.
Pull request Compare This branch is 309 commits behind monterail:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.

The Monterail's Rules

Following document contains development guidelines for, LLC.


  1. Leave the campground cleaner than you found it.
  2. Configure your editor to automatically strip trailing whitespaces.


Use git up tool

especially if you're not experienced with git. It keeps the commit history clean.

gem install git-up
git config --global git-up.bundler.check true
git config --global git-up.bundler.autoinstall true
git config --global git-up.fetch.all true
git config --global git-up.rebase.arguments --preserve-merges

If you're comfortable with Git commands, use git config --global branch.autosetuprebase always

Follow the rules described in our Git flow


JS on Rails



Projects in general


Use CSS normalize instead of CSS reset

Use SCSS preprocessor for all stylesheets

Don't use sprocket's commands in SCSS files

Sprocket's require commands are primitive and do not work well with SCSS files.

Instead, use SCSS's @import command. It supports globbing and development mode too.

When file is larger than few hundred lines, think about modularization

If it does, create directory with the same name as SCSS file, and extract code to separate files.

After that import these files using following sprockets template:

// stylesheets.css.scss

@import "stylesheets/*";

This style of importing implies, that extracted files should not be dependent on each other.

Put all code that is dependent at the top of stylesheets.css.scss.

Learn about CSS specificity and keep it as low as possible

For example following selectors should be avoided:

div.klass { ... }
ul li .klass { ... }
section a.btn { ... }
html a { ... }
div p { ... }

Also remember:

  • Don't nest SCSS selectors more than 3 levels deep.
  • Don't use !important to solve high specificity problems.
  • IDs should never be used in CSS.

If you're not sure about this:

Try to add CSS properties instead of removing them

Following styles should be avoided:

margin: 0;
padding: 0;
border: none;
float: left;
background: none;

If you need to remove styles, you've applied them too early.

Consider different scoping, think if you can use mixins or refactor CSS to separate class.

Use proper SCSS formatting

  • Use soft-tabs with a two space indent.
  • Put spaces after : in property declarations.
  • Put spaces before { in rule declarations.
  • Put spaces after , in attribute declarations;
  • Use hex color codes #000 unless using rgba.
  • Use // for comment blocks (instead of /* */).
  • put nested components at the end of block
  • puts @include and @extend just before nested components
  • use extra blank line between selectors (both top level and nested ones)
  • use dashes for separating words in class names
  • use underscores for separating words in ID names
  • don't omit leading zeros in numeric values
  • don't use units in zero numeric values
  • use short hexadecimal notation if possible
  • never put many rule declarations in one line

Example syntax:

// This is a good example!
.styleguide-format {
  border: 1px solid #0f0;
  color: #000;
  background: rgba(0, 0, 0, 0.5);
  @include border-radius(5px);

  .styleguide-nested {
    color: #222;

  .styleguide-another {
    color: #333;

#some_element {
  display: none;


Use consistent class names and markup for HTML components

For basic ones, use twitter bootstrap 2 conventions. For example don't use <div class="crumbs"> for breadcrumbs instead of <ul class="breadcrumb"></ul>. This also concerns layout, forms, buttons, flash messages, navigation and others.

If possible, document new markup proposals in our styleguide.

For proper forms markup, install the formtastic-bootstrap gem.

Coding / development enrivonments

Contribution to this document

According to this issue we agreed to:

  • declare if he/she wants to participate in issues tagged with given word, for example #ruby or #css. Then all issues / pull-request would be tagged appropriately.
  • if so, he/she would be obligated to comment on issue or at least give +1 or no opinion comment for example until week after issue has been created.
  • the idea is subscribed persons would be obligated to comment. we will mention them in such cases.
  • final decision for merging is for CTO
  • it's of couse possible for non-declared person to participate. That list would help us determine if issue is ready to be accepted or it needs more discussion / time (for example if everyone would vote "no opinion").

Available tags for now: #ruby, #js, #git, #css, #design, #unix, #html

Here is current list of contributors along with tags they subscribe:

  • Jan Dudulski (@jandudulski) - all tags
  • Adam Stankiewicz (@sheerun) - all tags
  • Dariusz Gertych (@chytreg) - #ruby, #js, #design
  • Tymon Tobolski (@teamon) - #ruby, #git, #unix
  • Michał Szajbe (@szajbus - #ruby, #js, #git, #unix
  • Dominik Porada (@porada) - #design, #html, #css, #js
  • Krzysztof Jung (@venticco) - #design, #html, #css, #js
  • Michał Duda (@Ostrzy) - #ruby, #js, #git, #html
  • Szymon Boniecki (@szymo) - #design

Pull requests and issues from third party are of course welcome too!