• What we need to be testing and validating (on both ember/rails) before building on rake wildland:pre_deploy and abort if failed. For discussion starters, that all ember/rails tests pass, rubocop has no errors, jshint/jsrc has no errors.

• Step 1
• Step 2
• Step 3

We need to be sure to include #17.

Update git commit to ask to verify if the user is on the master branch.

• Regular workflow
• When a ticket is marked urgent
• Work in process
• Getting help on a ticket

Check new requirements on Mac OS Sierra.

We should also include that updates should be in a separate commit when possible unless they are directly needed for the issue so that we can cherry pick around them if we want.

We should move the conditionals into a command pattern and lookup the command based off of the application name. See #23

There are certain errors that we handle on almost any type of application and sometimes they are different based on the application context and tone. We should however provide the developers with defaults that sound nice and generic.

Tools to aid in this:
Node: https://github.com/jvandemo/copy-github-labels
Ruby: http://peter-murach.github.io/github/

Per install docks:
rbenv init

# Load rbenv automatically by adding
# the following to ~/.bash_profile:

eval "$(rbenv init -)"

Examples:

• debugger in *.js files
• binding.pry in *.rb files
• Any of remnants of a failed git merge, like this

Sometimes I am unsure as to when to run these:

1. rake wildland:setup
2. rake db:reset
3. rake db:setup
4. rake db:seed
5. bower install
6. npm install
   etc.

El Captain did not have a .bash_profile for user by default
need to add a touch to the ~/.bash_profile

• setting up new heroku instance
• pushing changes to heroku

For example see

https://github.com/wildland/denovo/pull/233/files#r41066185

If you don't agree that this is the type of thing that belongs here the guides I'd love to hear some suggestions. It's a little outside the original intention of this document but I'd like to see us have things like this documented to first be able to avoid them in the future for anyone new and document how to fix it.

Git alias is not properly escaping $1. Easiest to test using the create-branch alias. It will cause the following error fatal: remote part of refspec is not a valid name in HEAD:refs/heads/

See: wildland/ember-wildland-blueprints#10 (comment)

https://www.moncefbelyamani.com/how-to-install-postgresql-on-a-mac-with-homebrew-and-lunchy/

• Application consists of a Menu + Content and sometimes a Footer.
• Edit pattern that allows for good urls and button quickness.
• Index views default to table.
• Show uses DL with DD/DT for show <- Suggested to use flex box for grids?
• Hard delete is the default. Soft delete example, because it is more difficult.
• Smaller less files. We should be treating css just like code. Small manageable files that are logically arranged.

We should add a way for end users to submit bugs and suggestions.

For process meeting 8/19

All new projects should have this setup.
Previous projects that were using it_behaves_like 'a testable object' do should be removed and swapped to this linting.
Per documentation: http://www.rubydoc.info/gems/factory_girl/file/GETTING_STARTED.md#Linting_Factories

For process meeting 8/19

• Making component repos private
• When to Open Source
• Applications in their own Organization