add linters and style guide

docs/coding-style/linters.md

@@ -0,0 +1,64 @@
+# Linters
+These linters support the [ShakaCode Style Guidelines](./style.md)
+
+## Autofix!
+
+If you haven't tried the autofix options for `jscs` and `rubocop`, you're seriously missing out!
+
+1. Be **SURE** you have a clean git status, as you'll want to review what the autofix does to your code!
+2. **Rubocop:**  Be sure to be in the right directory where you have Ruby files, probably the top level of your Rails project.
+  ```
+  rubocop -a
+  ```
+
+3. **JSCS:**: Be sure to be in the right directory where you have JS files.
+  ```
+  jscs -x .
+  ```
+
+Autofixing is a **HUGE** timesaver!
+
+## ESLint
+
+### Configuring Rules
+
+Rules are configured with a 0, 1 or 2. Setting a rule to 0 is turning it off, setting it to 1 triggers a warning if that rule is violated, and setting it to 2 triggers an error.
+
+Rules can also take a few additional options. In this case, the rule can be set to an array, the first item of which is the 0/1/2 flag and the rest are options.
+
+See file [.eslintrc](../../client/.eslintrc) for examples of configuration
+
+### Specify/Override rules in code
+
+Rules can also be specified in the code file to be linted, as JavaScript comments. This can be useful when the rule is a one-off or is a override to a project-wide rule.
+
+For example, if your file assumes a few globals and you have the no-undef rule set in the .eslintrc file, you might want to relax the rule in the current file.
+
+```
+/* global $, window, angular */
+// rest of code
+```
+
+It's also useful to disable ESLint for particular lines or blocks of lines.
+
+```
+console.log('console.log not allowed'); // eslint-disable-line
+
+alert('alert not allowed'); // eslint-disable-line no-alert
+
+/* eslint-disable no-console, no-alert */
+console.log('more console.log');
+alert('more alert');
+/* eslint-enable no-console, no-alert */
+```
+
+You can disable all rules for a line or block, or only specific rules, as shown above.
+
+### Useful Reference Links
+
+* [Configuring ESLint](http://eslint.org/docs/user-guide/configuring.html#configuring-rules)
+* [ESLint quick start](http://untilfalse.com/eslint-quick-start/)
+* [RuboCop][https://github.com/bbatsov/rubocop]
+* [ESLint][http://eslint.org/] 
+* [JSCS][https://github.com/jscs-dev/node-jscs]
+

docs/coding-style/style.md

@@ -0,0 +1,39 @@
+# Code Style
+This document describes the coding style of [ShakaCode](http://www.shakacode.com). Yes, it's opinionated, as all style guidelines should be. We shall put as little as possible into this guide and instead rely on:
+
+* Use of linters with our standard linter configuration.
+* References to existing style guidelines that support the linter configuration.
+* Anything additional goes next.
+
+## Client Side JavaScript and React
+* Use [Redux](https://github.com/rackt/redux) for your flux store.
+* Use [Lodash](https://lodash.com/) rather than Underscore.
+* Place all JavaScript for the client app in `/client`
+* Organize your app into high level domains which map to JavaScript bundles. These are like mini-apps that live within your entire app. Create directories named like `/client/app/<bundle>` and configure Webpack to generate different corresponding bundles.
+* Carefully organize your React components into either:
+   1. "dumb" components that live in the `/client/app/<bundle>/components/` directories. These components should take props, including values and callbacks, and should not talk directly to Redux or any AJAX endpoints.
+   2. "smart" components that live in the `/client/app/<bundle>/containers/` directory. These components will talk to the Redux store and AJAX endpoints.
+* Place common code shared across bundles in `/client/app/libs` and configure Webpack to generate a common bundle for this one.
+* Prefix Immutable.js variable names and properties with `$$`. By doing this, you will clearly know that you are dealing with an Immutable.js object and not a standard JavaScript Object or Array.
+* Bind callbacks passed to react components with `_.bind`
+
+## Style Guides to Follow
+Follow these style guidelines per the linter configuration. Basically, lint your code and if you have questions about the suggested fixes, look here:
+
+### Ruby Coding Standards
+* [RailsOnMaui Ruby Coding Standards](https://github.com/justin808/ruby)
+
+### JavaScript Coding Standards
+* [AirBnb Javascript](https://github.com/airbnb/javascript)
+
+### Git coding Standards
+* [Git Coding Standards](http://chlg.co/1GV2m9p)
+
+### Sass Coding Standards
+* [Sass Guidelines](http://sass-guidelin.es/) by [Hugo Giraudel](http://hugogiraudel.com/)
+* [Github Front End Guidelines](http://primercss.io/guidelines/)
+
+# Git Usage
+* Follow a github-flow model where you branch off of master for features.
+* Before merging a branch to master, rebase it on top of master, by using command like `git fetch; git checkout my-branch; git rebase -i origin/master`. Clean up your commit message at this point. Be super careful to communicate with anybody else working on this branch and do not do this when others have uncommitted changes. Ideally, your merge of your feature back to master should be one nice commit.
+* Run hosted CI and code coverage.