part_0_A.md

Part 0 (A): Preparation: get RottenPotatoes running locally

The actual RottenPotatoes starter app you will use is in another public repo: saasbook/rottenpotatoes-rails-intro. On that repo's GitHub page, click "Use This Template", which will create a new copy of the repo in your GitHub account. Do not fork the repo since we don't intend to accept pull requests from student assignments!

Once you have a copy of the repo in your own GitHub account, clone it into your development environment:

$ git clone [email protected]:[your_github_username]/rottenpotatoes-rails-intro.git

(Note: this assumes you have connected your GitHub account to your development environment. Here is how to do it for Codio and how to do it for generic Mac/Windows/Un*x environments.)

Whenever you start working on a Rails project, the first thing you should do is to run Bundler, to make sure all the app's gems are installed. Switch to the app's root directory (presumably rottenpotatoes-rails-intro) and run bundle install --without production (you only need to specify --without production the first time, as this setting will be remembered on future runs of Bundler for this project).

Finally, run the initial migration, which (since it's the very first migration) will also create the database itself:

$ bin/rake db:migrate

NOTE: bin/rake and bin/rails, or just rake and rails? If you're using one of the recommended development setups (either using Codio, or managing your own development environment with rvm), then the execution path ($PATH in Un*x parlance) should be correctly set so that the correct version of rake or rails appears earliest in the path. If you're using a nonstandard development environment, or if these commands behave weirdly, saying bin/rake or bin/rails will force using the version in your Rails app's bin/ directory. Whenever these instructions say to run rake or rails, it is always safe to substitute bin/rake or bin/rails, especially if the commands aren't behaving the way we say they should.

Self Check Question: How does Rails decide where and how to create the development database? (Hint: check the db and config subdirectories)

The rake db:migrate command creates a local development database (following the specifications in config/database.yml) and runs the migrations in db/migrate to create the app's schema. It also creates/updates the file db/schema.rb to reflect the latest database schema. Note: it's important to keep this file under version control.

Self Check Question: What tables got created by the migrations?

The movies table itself and the rails-internal schema_migrations table that records which migrations have been run.

Now insert "seed data" into the database. (Seeds are initial data items that the app needs to run):

$ bin/rake db:seed

Self Check Question: What seed data was inserted and where was it specified? (Hint: rake -T db:seed explains the seed task; rake -T explains other available Rake tasks)

A set of movie data which is specified in db/seeds.rb

At this point you should be able to run the app locally and visit it from a browser to make sure it's working before you go on.

Next: Part 0 (B): Preparation: deploy to Heroku