6. 怎麼找Public key cat ~/.ssh/id_rsa.pub
1. a real sample app (Chapter 3 through Chapter 12).
2. gems (self-contained solutions to specific problems such as pagination and image upload)
3. Another strategy recommended by multiple readers is simply to do the tutorial twice; you may be surprised at how much you learned the first time (and how much easier it is the second time through).
4. 1.3.1 Bundler
After creating a new Rails application, the next step is to use Bundler to install and include the gems needed by the app.
5. Unless you specify a version number to the gem command, Bundler will automatically install the latest requested version of the gem. This is the case, for example, in the code gem 'sqlite3'
gem 'coffee-rails', '~> 4.0.0' ~> 不會超過4.1.0版本
gem 'uglifier', '>= 1.3.0' >= 高過於1.3.0的版本，譬如7.2.0
gem 'sqlite3' 沒有寫任何數字，就是會灌最新的版本
6. Unfortunately, experience shows that even minor point releases can break things, so for the Ruby on Rails Tutorial we’ll err on the side of caution by including exact version numbers for all gems.
7. Converting the Gemfile in Listing 1.4 to use exact gem versions results in the code shown inListing 1.5.
8. 1.3.3 Model-View-Controller (MVC)
This is a hint that Rails follows the model-view-controller (MVC) architectural pattern, which enforces a separation between “domain logic” (also called “business logic”) from the input and presentation logic associated with a graphical user interface (GUI). In the case of web applications, the “domain logic” typically consists of data models for things like users, articles, and products, and the GUI is just a web page in a web browser.
9. 1.4 Version control with Git
Version control systems allow us to track changes to our project’s code, collaborate more easily, and roll back any inadvertent errors (such as accidentally deleting files).
10. 1.4.1 Installation and setup
Before using Git, you should perform a set of one-time setup steps. These are system setups, meaning you only have to do them once per computer:
Note that the name and email address you use in your Git configuration will be available in any repositories you make public.
(Only the first two lines above are strictly necessary. The third line is included only to ensure forward-compatibility with an upcoming release of Git.The optional fourth line is included so that you can use co in place of the more verbose checkout command. For maximum compatibility with systems that don’t have co configured, this tutorial will use the full checkout command, but in real life I nearly always use git co.)
11. First-time repository setup
Now we come to some steps that are necessary each time you create a new repository(sometimes called a repo for short). First navigate to the root directory of the first app and initialize a new repository:
Initialized empty Git repository in /home/ubuntu/workspace/hello_app/.git/
The next step is to add all the project files to the repository using git add -A:
This command adds all the files in the current directory apart from those that match the patterns in a special file called .gitignore. The rails new command automatically generates a .gitignore file appropriate to a Rails project, but you can add additional patterns as well.12
The added files are initially placed in a staging area, which contains pending changes to your project. You can see which files are in the staging area using the status command:
To tell Git you want to keep the changes, use the commit command:
** -m 是用來寫附註的：**
The -m flag lets you add a message for the commit; if you omit -m, Git will open the system’s default editor and have you enter the message there. (All the examples in this book will use the -m flag.)
It is important to note that Git commits are local, recorded only on the machine on which the commits occur. We’ll see how to push the changes up to a remote repository (using
git push) in Section 1.4.4.
By the way, you can see a list of your commit messages using the log command:
Let’s check the status to see what changed:
12. 1.4.3 Bitbucket
Once you’ve added your public key, click on “Create” to create a new repository, as shown inFigure 1.14.
When filling in the information for the project, take care to leave the box next to “This is a private repository.” checked.
After clicking “Create repository”, follow the instructions under “Command line > I have an existing project”, which should look something like Listing 1.12. (If it doesn’t look like Listing 1.12, it might be because the public key didn’t get added correctly, in which case I suggest trying that step again.)
When pushing up the repository, answer yes if you see the question “Are you sure you want to continue connecting (yes/no)?”
The commands in Listing 1.12 first tell Git that you want to add Bitbucket as the origin for your repository, and then push your repository up to the remote origin. (Don’t worry about what the -u flag does; if you’re curious, do a web search for “git set upstream”.) Of course, you should replace
Git is incredibly good at making branches, which are effectively copies of a repository where we can make (possibly experimental) changes without modifying the parent files. In most cases, the parent repository is the master branch, and we can create a new topic branch by using checkout with the -b flag:
checkout -b可以新增一個new branch，同時switch去這個new branch
Here the second command, git branch, just lists all the local branches, and the asterisk *identifies which branch we’re currently on. Note that git checkout -b modify-README both creates a new branch and switches to it, as indicated by the asterisk in front of th emodify-README branch. (If you set up the co alias in Section 1.4, you can use git co -b modify-README instead.)
git commit provides the -a flag as a shortcut for the (very common) case of committing all modifications to existing files (or files created using git mv, which don’t count as new files to Git):
Be careful about using the -a flag improperly; if you have added any new files to the project since the last commit, you still have to tell Git about them using git add -A first.
git commit -a -m，可是如果有新增檔案，就必須先用
git add -A然後再用
git commit -m
Now that we’ve finished making our changes, we’re ready to merge the results back into our master branch:
這邊跟JC講的不一樣：RailsFun.tw 新手教學_day2 HD
This step is optional, and in fact it’s quite common to leave the topic branch intact. This way you can switch back and forth between the topic and master branches, merging in changes every time you reach a natural stopping point.
Unlike the -d flag, the -D flag will delete the branch even though we haven’t merged in the changes.
Now that we’ve updated the README, we can push the changes up to Bitbucket to see the result. Since we have already done one push (Section 1.4.3), on most systems we can omit origin master, and simply run git push:
1.5 Deploying - Heroku
Heroku 使用 PostgreSQL database
Heroku uses the PostgreSQL database (pronounced “post-gres-cue-ell”, and often called “Postgres” for short), which means that we need to add the pg gem in the production environment to allow Rails to talk to Postgres:17
:production 要用pg (PostgreSQL)
Note also the addition of the rails_12factor gem, which is used by Heroku to serve static assets such as images and stylesheets. Finally, be sure to incorporate the changes made in Listing 1.5 preventing the sqlite3 gem from being included in a production environment, since SQLite isn’t supported at Heroku:
雖然加上without production，不會在local端install pg跟rails_12factor這兩個gem，不過其實是更新到Gemfile.lock
Because the only gems added in Listing 1.14 are restricted to a production environment, right now this command doesn’t actually install any additional local gems, but it’s needed to update Gemfile.lock with the pg and rails_12factor gems.
1.5.1 Heroku setup
確定有沒有灌過heroku CLI跟Heroku Toolbelt
Once you’ve verified that the Heroku command-line interface is installed, use the heroku command to log in and add your SSH key:
Finally, use the heroku create command to create a place on the Heroku servers for the sample app to live (Listing 1.15).