Rails-Tutorial ７章の備忘録
本記事は第７章の備忘録です。
１．resources :users
このコマンドはRESTアーキテクチャに基づいてuserオブジェクトに対してモデル化を実施する。
これにより、４つの基本的なHTTP requestメソッド(POST/GET/PATCH/DELETE)に基づき、４つの操作を実施する。(Create/Read/Update/Delete)
具体的には以下のHTTPリクエストを用いることでこれらの操作を実施することができる。
ただしこの時viewがまだ作られていないため、HTTPリクエストを投げてもエラーになることに注意。
HTTPリクエスト URL アクション 名前付きルート 用途
GET /users index users_path すべてのユーザーを一覧するページ
GET /users/1 show user_path(user) 特定のユーザーを表示するページ
GET /users/new new new_user_path ユーザーを新規作成するページ (ユーザー登録)
POST /users create users_path ユーザーを作成するアクション
GET /users/1/edit edit edit_user_path(user) id=1のユーザーを編集するページ
PATCH /users/1 update user_path(user) ユーザーを更新するアクション
DELETE /users/1 destroy user_path(user) ユーザーを削除するアクション
２．newアクション
ユーザ登録フォームでは、ユーザ名やメールアドレスやパスワードを入力した際に、その情報を何かしらの入れ物に入れておいて、WebアプリケーションのDBまで届ける必要がある。その入れ物の役割を持つものが@userとなる。
def new @user = User.new end
３．form_for
以下のコードは@userを引数に取って@userに必要な情報（ここではname,email,password,password_confirmation)を代入する。
form_forは代入するためのラベルと記入フォームを提供する。
<%= form_for(@user) do |f| %> <%= f.label :name %> <%= f.text_field :name %> <%= f.label :email %> <%= f.email_field :email %> <%= f.label :password %> <%= f.password_field :password %> <%= f.label :password_confirmation, "Confirmation" %> <%= f.password_field :password_confirmation %> <%= f.submit "Create my account", class: "btn btn-primary" %> <% end %>
Rails-Tutorial ６章の備忘録
本記事は第６章の備忘録です。
１．インデックス
テーブル内のカラムの中の特定の値に対しての検索を行いやすいようにするもの。
例えばユーザ名にインデックスをはった場合は、辞書の索引欄のようにユーザ名がまとめられ検索する際はその索引欄から探すようになる。
メリットとして検索や取得の速度が上がるが索引欄にも情報を書き込む分書き込み時間が長くなることがデメリットとなる。
そのため、ある程度の大きなテーブルで格納される値がそれぞれ異なるようなカラムのような場合に用いると良い。
Rails-Tutorial ５章の備忘録
本記事では第５章で気づいたことでの備忘録です。
１．現時点でのシステム構成の整理
いろいろプログラムができていって少々複雑になってきたので一度システムの外観を整理する。
最初のシステムの処理はroutes.rbによってrootであるstatic_pages#homeに遷移する。
図からcontrollerを呼び出していることがわかるので、controller/concerns/static_pages_controller.rbのhomeメソッドを呼び出すことがわかる。
今回モデルは呼び出さないため、そのままviews/static_pagesのhome.html.erbの内容をブラウザに表示する。
ここで注意点としてhome.html.erbの中身はviews/layouts/application.html.erbのフォーマットに埋め込む形となる。
実行結果は以下のようになる。
２．Bootstrap
Bootstrapってなんだろって調べてみたらWEBページでよく使われるボタンやフォームやメニューなどの部品がテンプレート化したWEBフレームワークで、
さらにデザイン性もある程度考慮してくれて、ユーザが見る媒体（スマホやPC）に応じて適切なデザインで配置してくれるという優れもの。
3．パーシャル
以下のようなコードを記述してviews/layouts/_shim.html.erbというファイルを配置することで該当の行が_shim.html.erbの内容に置換される。
これを用いることですっきりとしたコードが書けるようになる。
<%= render 'layouts/shim' %> end
４．アセットパイプライン
アセットパイプラインは以下の３つの機能で構成されており、静的コンテンツの生産性と管理を大幅に強化することができる。
・アセットディレクトリ
・マニフェストファイル
・プリプロセッサエンジン
アセットディレクトリはapp,vendor,libのそれぞれのassets配下に画像用、javascripts用、CSS用のサブディレクトリがあり、目的に応じて必要なアセットを適切な場所に配置することで直感的なアセットの管理が可能になる。
マニフェストファイルはassets配下のサブディレクトリごと（画像ディレクトリを除く）にファイルの連結を行う。それぞれのサブディレクトリ配下のcssファイルが１つのファイルになるイメージ。これを実施することでファイル回数の呼び出しが少なくなりWebブラウザへの表示がはやくなる。
プリプロセッサエンジンはjavascriptやcssよりもより人間的に理解のしやすいcoffeescrips、ERB、SASSを記載したものをjavascripsやcssに翻訳する機能。
アセットパイプラインを用いるメリットはRuby on Rails Tutorialに記載されている内容をそのまま引用する。
Asset Pipelineの最大のメリットの1つは、本番のアプリケーションで効率的になるように最適化されたアセットも自動的に生成されることです。従来は、CSSとJavaScriptを整理するために、機能を個別のファイルに分割し、(インデントを多用して) 読みやすいフォーマットに整えていました。これは、プログラマにとっては便利な方法ですが、本番環境にとっては非効率です。それというのも、最小化されていないCSSやJavaScriptファイルを多数に分割すると、ページの読み込み時間が著しく遅くなるからです (読み込み時間は、ユーザー体験の質に影響を与える重要な指標の1つです)。Asset Pipelineを使うと、この「開発効率と読み込み時間のどちらを重視するか」という問題について悩む必要がなくなります。開発環境ではプログラマにとって読みやすいように整理しておき、本番環境ではAsset Pipelineを使ってファイルを最小化すればよいのです。具体的には、Asset Pipelineがすべてのスタイルシートを1つのCSSファイル (application.css) にまとめ、すべてのJavaScriptファイルを1つのJSファイル (javascripts.js) にまとめてくれます。さらに、それらのファイルすべてに対して 不要な空白やインデントを取り除く処理を行い、ファイルサイズを最小化してくれます。結果として、開発環境と本番環境という、2つの異なった状況に対してそれぞれ最高の環境を提供してくれます。
Rails-Tutorial ４章の備忘録
本記事では第４章で気づいたことでの備忘録です。
１．カスタムヘルパー
そもそもヘルパーとは関数とかライブラリって思っていた方がいいかも。一応Rails自体にもヘルパーはあるが、自分で考えた機能を一般化してヘルパーとしたい場合はapp/helpers/application_helper.rbに配置する。これをカスタムヘルパーと呼ぶ。
application_helper.rbは最初は以下のようなコードとなっているが、
module ApplicationHelper end
カスタムヘルパーを入れると以下のようになる。
module ApplicationHelper # ページごとの完全なタイトルを返します。 def full_title(page_title = '') base_title = "Ruby on Rails Tutorial Sample App" if page_title.empty? base_title else page_title + " | " + base_title end end end
これを使うと全体のコードをスッキリさせることができる。
Rails-Tutorial ３章の備忘録
本記事では第３章で気づいたことでの備忘録です。
１．GETリクエスト
config/routes.rbの以下のruby文の解釈の仕方について。
get 'static_pages/home'
上記の文は/static_pages/homeというURLに対してGETリクエストを行った時、StaticPagesコントローラのhomeアクションを実行してWebページを表示するという意味を持つ。
具体的には/static_pages/homeのURLにアクセスすると、①StaticPagesコントローラのhomeアクションに記述されているコードを実行する。その後、②そのアクションに対するビューを出力する。今回の場合はhomeアクションが空のため出力なし、ビューであるhome.html.erbは以下のようなコードが記載されているため、
<h1>StaticPages#home</h1> <p>Find me in app/views/static_pages/home.html.erb</p>
次のような出力が行われる。
railsのビューの中には静的なHTMLがあるらしい。このため、railsの知識がなくても静的なページを修正可能となる。
2．provideメソッドとyieldメソッド
viewにおいてprovideメソッドとyieldメソッドは対の関係になっており、provideメソッドで変数から文字列を渡すことができる。
<% provide :title, 'タイトル' %>
yieldメソッドは変数をもとに文字列を表示するような意味を持つ。
<title><%= yield(:title)%></title>
3．<% ... %>と<%= ... %>
<% ... %>はコードの実行のみ。<%= ... %>ではコードを実行し、その実行結果がview部分に挿入される。
Rails-Tutorial ２章の備忘録
本記事では第２章で気づいたことでの備忘録です。
１．gemとBundler
gemとはRubyで使われるライブラリやアプリケーションのパッケージと思っておくと良い。そして、必要なgem一覧を記述しているファイルがGemfileというもの。
Gemfileを作る上でのメリットは以下の３つがあるみたい。
Railsアプリを作成すると自動的にGemfileというファイルが作成されますが、それは
作成されたRailsアプリの動作に必要なGemパッケージ一覧を記述しておくファイルで、
このファイルがあるメリットが
- アプリの動作に必要なパッケージが明示的になる
- このファイルさえ再配布してしまえば、他の環境でも一度にインストールすることができる(バージョンも含めて同じものを)
- 同じパッケージでもバージョンの違いを区別して管理することができる
の三点だと認識しています。
Bundlerもgemの１種。gemは他のgemと依存関係を持つ場合があり、Bundlerはその依存関係を解消してくれる。もう少し砕いて言うと、Bundlerを用いてgemをインストールするとインストールしたgemに必要なgemもまとめてインストールしてくれる。そして、Bundlerを用いてGemfileに基づいてgemをインストールする際は、依存関係のある他にインストールしたgemがGemfile.lockに記載される。
２．RoutingErrorの対処法
プログラムを書き終わってherokuにあげようとした時に以下のようなエラーが出た。
ActionController::RoutingError (uninitialized constant UsersController):
どうやら「routes.rb」でルーティング先を「'users#index'」にすべきところを「'user#index'」にしていたみたい。
railsは割とsのつけるつけないがややこしいのでこれからは注意しておきたい。
Rails-Tutorial １章の備忘録
これからRails-Tutorialを進めていくにあたって「ここ理解するのに少し時間がかかったな～」という部分を備忘録としてまとめていきたいと思います。
本記事では第１章についてです。
１．「Hello World!」の出力
MVCモデルは既に知っていたが、ブラウザ→controllerにリクエストを渡すときになぜ「routes.rb」が出てくるのか？だった。
しっかりと読んでみるとRailsだとブラウザ→routes→controllerのように情報の伝達が行われている。
そのため、今のところの理解だとブラウザ＝リクエストを投げる。routes=受け取ったリクエストをcontrollerの中のどの処理に渡すかを決める。controller=routesから指定された処理を行う。という感じ。
２．GithubとCloud9の連携
Rails TutorialではCloud9とBitbucketを連携してBitbucketにソースコードをアップするような説明があるけど、僕はGithubにソースコードをいくつかあげていることもあり、GithubとCloud9を連携したかった。その際に参考にしたのが下記のサイト。わかりやすくてすんなり連携ができた。ただし、Cloud９の公開鍵発行方法については記載がないため注意が必要。
３．リモートリポジトリへのアップロード方法
理解に一番時間がかかったところ。コマンド入力によってディレクトリ等の場所を遷移していく理由がよくわからなかった。そのため、以下のように移動の流れを図にまとめてみた。
・addコマンド
作業ディレクトリ（自分がプログラミングを行なっている場所）からステージングエリアにプログラムの変更内容を追加する。
ステージングエリアの用途は変更した内容だけをローカルリポジトリに追加するために一時的に変更内容を作業ディレクトリから追加していくためのタンクのようなもの。
・commitコマンド
開発作業が進んで区切りの必要が出てきた際にステージングエリアに貯めていた変更内容をまとめてメッセージと一緒にローカルレポジトリに追加して変更履歴を残す。
commit -aコマンドを用いると作業ディレクトリから直接ローカルリポジトリに変更内容を追加することが可能。
・pushコマンド
ローカルリポジトリの内容を外部環境のGithub、BitBucketやHerokuに反映させるためのコマンド。
