Railsチュートリアル2

実例を使ってRailsを学ぼう

railstutorial.jp

今回は1.2.4 Bundlerから1.3.4 GitHub

第1章 ゼロからデプロイまで

railstutorial.jp

1.2.4 Bundler

Railsアプリケーションを新規作成したら、次はBundlerを実行して、アプリケーションに必要なgemをインストールおよびインクルードします

Gemfileを変更します

source 'https://rubygems.org'
↓
source 'https://rubygems.org'
ruby '2.1.2'

jQueryに関するもの

gem 'jquery-rails'
↓
gem 'jquery-rails', '3.0.4'

gem 'sqlite3'
↓
group :development do
  gem 'sqlite3', '1.3.8'
end

この変更を行うと、Bundlerはsqlite3 gemの1.3.8を強制的にインストールします。ここではさらに、SQLiteをdevelopment環境 (7.1.1) でのみ使用するための指定も行なっていることに注目してください。こうすることで、Heroku (1.4) で使用するデータベースソフトウェアと衝突する可能性を避けられます。

ほかのも変更します

# Use SCSS for stylesheets
gem 'sass-rails', '~> 4.0.2'

# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'

# Use CoffeeScript for .js.coffee assets and views
gem 'coffee-rails', '~> 4.0.0'
↓
gem 'sass-rails', '4.0.5'
gem 'uglifier', '2.1.1'
gem 'coffee-rails', '4.0.1'

以下gemの記述の説明の引用となります

gem 'uglifier', '>= 1.3.0'

uglifierのバージョンが1.3.0以上であれば最新バージョンのgemがインストールされます。 極端に言えばバージョンが7.2であってもそれが最新ならインストールされます。なお、uglifierはAsset Pipelineでファイル圧縮を行うためのものです。

gem 'coffee-rails', '~> 4.0.0'

coffee-rails (これもAsset Pipelineで使用するgemです) のバージョンが4.0.0より大きく、4.1より小さい場合にインストールするようになります。つまり、>=と書くとbundle installの実行時に必ずアップグレードが行われますが、~> 4.0.0と書くとマイナーなアップグレードしか行われないことになります。この場合4.0.0から4.0.1へのアップグレードは行われますが、4.0から4.1へのアップグレードは行われません。経験上、残念ながらマイナーアップグレードですら問題を引き起こすことがあります。このため、Railsチュートリアルでは基本的にすべてのgemでバージョンをピンポイントで指定しています。

Gemfileを正しく設定しましたので、bundle update と bundle install を使用して gem のインストールをします

$ bundle update
$ bundle install

1.2.5 rails server

ローカルwebサーバを起動します

$ rails server

(JavaScriptランタイムがインストールされていないというエラーが表示された場合は、GitHubのexecjsページにあるインストール可能なランタイムを確認してください。Node.jsが特にお勧めです)。

とあり、ランタイムでエラーとなりました

Node.jsのインストール

$ sudo yum install nodejs

インストール後に再度ローカルwebサーバを動かすとエラーはでなくなりました

1.3 Gitによるバージョン管理

1.3.1 インストールとセットアップ

最初のリポジトリのセットアップとして、Railsアプリケーションのルートディレクトリに移動し、新しいリポジトリの初期化を行います
ここでのルートディレクトリはfirst_appとなります

$ git init

.gitignoreに除外設定を追加します

# Ignore other unneeded files.
doc/
*.swp
*~
.project
.DS_Store
.idea
.secret

1.3.2 追加とコミット

新しく作成したRailsプロジェクトのファイルをGitに追加し、コミットします

$ git add .

ここで「.」は現在のディレクトリ (カレントディレクトリ) を指します。Gitは再帰的にファイルを追加できるので、自動的にすべてのサブディレクトリも追加されます。このコマンドにより、プロジェクトのファイルは、コミット待ちの変更が格納されている「ステージングエリア」という一種の待機場所に追加されます。ステージングエリアにあるファイルのリストを表示するには、statusコマンドを実行します。

変更を保存するには、commitコマンドを使います

$ git commit -m "Initialize repository"

-mフラグは、コミットメッセージ (コミット内容の覚書) をその場で追加する場合に使用します。-mを省略した場合、1.3.1で設定されたエディタが起動され、コミットメッセージの入力を求められます。

1.3.3 Gitのメリット

ファイルがいくつか削除されましたが、この変更が行われたのは現在の「作業ツリー」内のみなので、まだコミット (保存) されていません。つまり、以前のコミットをcheckoutコマンド (と、現在までの変更を強制的に上書きして元に戻すための-fフラグ) でチェックアウトすれば、簡単に削除前の状態に戻すことができます。

$ git checkout -f

削除されたディレクトリとファイルが復旧することができます
コミットしていなければできるみたいです

1.3.4 GitHub

ポジトリをGitHubにわざわざプッシュするのには2つの理由があります。1つ目は、ソースコード (とそのすべての変更履歴) の完全なバックアップを作成することです。2つ目は、他の開発者との共同作業をより簡単に行うことです。

・GitHubにソースコードをアップロードする

GitHub上でリポジトリを作成します
すでにRails new コマンドを実行してREADMEファイルを自動的に作成しているため、READMEファイルを使用してリポジトリを初期化しないでください

リポジトリを作成したら、アプリケーションをプッシュします

$ git remote add origin https://github.com/<username>/first_app.git
$ git push -u origin master

・プッシュが失敗する

error: The requested URL returned error: 403 Forbidden while accessing https://github.com/catoidrobo/first_app.git/info/refs

fatal: HTTP request failed

最初にプッシュしたマシンとは別のマシンで操作をするとHTTPS認証でエラーになる模様

blog.katsuma.tv

succi.jp

一旦先ほど登録したURLを削除します

$ git remote rm origin

git remote add コマンドを再度実行します
今回は github.com ではなく、@github.com とします

$ git remote add origin https://<username>@github.com/<username>/first_app.git
$ git push -u origin master

プッシュ実行後にパスワードが聞かれるので、GitHubのパスワードを入力します

アクセスして確認するとプッシュされたことがわかりました

github.com