[Work in Progress]
Written by: Vishnu R Menon
- Ruby ~> 2.5
- Node => 9.4.0
- Yarn ~> 1.3
- PostgreSQL ~> 9.6
- Rails ~> 5.2.0.rc1
- Geckodriver ~> 0.19
- Imagemagick ~> 7.0
git clone git@github.com:vishthemenon/uteepi3.git
cd uteepi3
echo <MASTER-KEY> >> config/master.key
bundle install
yarn install
rails db:create
rails db:migrate
rails server
bin/webpack-dev-server
gem install mailcatcher
mailcatcher
bin/rspec
- Work on your own feature branches
- Send pull requests to develop branch
- At the end of every week, develop is merged into master and prepared for release.
Based on Chris Beams commit message style as written in his blog article - https://chris.beams.io/posts/git-commit/
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72 characters
or so. In some contexts, the first line is treated as the subject of the
commit and the rest of the text as the body. The blank line separating
the summary from the body is critical (unless you omit the body entirely);
various tools like `log`, `shortlog` and `rebase` can get confused if
you run the two together.
Explain the problem that this commit is solving. Focus on why you are
making this change as opposed to how (the code explains that). Are there
side effects or other unintuitive consequences of this change? Here's
the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789
To make sure your code passes CI, make sure the following runs without errors
- Rubocop* - Checks for ruby static code for
errorsoffences. Run rubocop or rubocop -a if you are lazy and rather have rubocop auto fix the errors. - EsLint* - Checks for linting errors with Javascript Code. Uses AirBnB's .eslintrc. Requires yarn global add eslint@latest eslint-config-airbnb eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react
- Haml-Lint* - Check for linting error with Haml Code. Requires gem install haml-lint
- Sass-Lint*† - Check for linting errors in SCSS Code. Requires yarn global add sass-lint
- Tests - Make sure all tests have passed. Run bin/rspec. Guard has been set up for you so you can run guard (bin/guard) in another shell to watch for file changes and automatically run tests.
- Reek_ - to detect _Code Smells
- PENDING Setup Brakeman to detect security vulnerabilities
*All the linters are have plugins for the popular text editors (ie. Emacs, Sublime, Atom etc.). It's recommended to install them so that you can see the errors in realtime. The plugins should be able to detect the respective config files if you set the project directory in your editor.
†If you hate formatting your SCSS like me, check out CSScomb. It has a CLI & plugins for the popular text editors to automatically format (ie. sort properties) your SCSS with a keystroke. The config file,
.csscomb.jsonhas been set up. It should match the Sass-Lint config. If not, send start an issue and send in a pull request.
To attain maximum code zen, you could add git-hooks to ensure you have not messed up anything that might take you over. Some git-hooks have been configured for you using overcommit in
.overcommit. The git-hooks are not installed by deafult. If you like to use them (and you should, really), you will have to install overcommit gem withgem install overcommitand initiate it withovercommit --install.
