Railsチュートリアルを一通りやってsample_appができました
なんとかかんとかRailsチュートリアルを一通り第11章までやってみた。
できたsample_appはこれ。（みんな同じですが・・・）
http://cremeshi-sample-app.herokuapp.com/
GitHubはこれ。github.com
言われたことをその通りのことをそのままやっただけなので、作った感はありませんが、できた感はあります。
僕は過去にRailsアプリケーションに挑戦しようとしたことはあったのですが、周辺知識がなさすぎて挫折しました。
今回一通りやってみてよかったことをあげてます。
1.スクリーンキャスト（動画解説）があること
いきなり動画解説の話になるのですが、基本的に動画解説にそってやっていきました。これの存在はかなり大きいです。スクリーンキャストがないと一通りするのにもっと時間がかかったと思います。@yasulabさんがありがとうございます。
2.Rails以外の周辺のものが理解できた
Git、GitHub、heroku、bootstrapなどの一連の流れも毎回出てくるので、それぞれどういう風に使うのかが理解できました。いきなりGitの本とか読んでもまずイメージができないですしね。
3.実際にアプリを作るので全体像が把握できる
railstutorialではtwitterのようなマイクロポストアプリを作るのでとりあずWebアプリケーションの全体像が把握できるのが素晴らしい。
4.scaffoldジェネレータを使って「できました～終わり～」みたいな子供だましが無いこと
簡単にアプリケーションが作れるといってscaffoldで「ほらね、簡単でしょ」みたいなのがネットや講座なんかでもよく行われている。けどそれやってもしゃーないでしょーって話ですよね。railstutorialでは第3章からはジェネレータとかは使わずにゼロから作る体験ができる。（第2章のdemo_appはscaffoldでやります）
5.何よりも体系的
体系的なコンテンツにするのってアウトプットする側としては本当に難しい。他に体系的にここまでまとまっているのは無いと思います。
あと、一通りやってみての所感ですが、
ド素人の僕でもやっぱりこのフレームワークすごいなと思います。
すべてが用意されているって感じ。
見透かされているような。
高級ホテルに泊まってお客様の動向がもう予めもうすべて読めてて、サービスを提供してくれるようなイメージかな。「はい、その場合はこのようなものをご用意しております」みたいな。
relationshipsのデータモデルがよくわからない
Railstutorialの第11章。
画像拝借↓
Userモデルとrelationshipsモデルを繋げるのに、
なぜ
class User < ActiveRecord::Base has_many :microposts, dependent: :destroy has_many :relationships, foreign_key: "follower_id", dependent: :destroy . . . end
とfollowed_idではなくfollower_idの方を明示的に書くのかがわからない。
herokuでpg:reset DATABASEをした時
Railstutorial第9章。
herokuでpgをリセットした時にでてきた、
エラー？と思ったらどうやら確認らしい。
僕の場合
WARNING: Destructive Action ! This command will affect the app: cremeshi-sample-app ! To proceed, type "cremeshi-sample-app" or re-run this command with --confirm cremeshi-sample-app
この場合、
cremeshi-sample-appのDBをリセットしますよ、
ともう1度タイピングするといいみたい。
テストのブラウザでcookiesが使えないってどうなんでしょう
Railstutorial第9章まできました。
第8章でも登場したcookies.permanentメソッドは実際にテストでは使うことができないらしい。
そのために、
テストヘルパーとしてテスト用メソッドを作るって・・・
結構大変ですな。
タイトルタグのところでも出てきたのですが、
テストのためのメソッドを作るとは思わなかった。
def sign_in(user, options={})
if options[:no_capybara]
# Capybaraを使用していない場合にもサインインする。
remember_token = User.new_remember_token
cookies[:remember_token] = remember_token
user.update_attribute(:remember_token, User.encrypt(remember_token))
else
visit signin_path
fill_in "Email", with: user.email
fill_in "Password", with: user.password
click_button "Sign in"
end
end
「||=」のわかりやすい説明
Railstutorialの第8章で、
def current_user
remember_token = User.encrypt(cookies[:remember_token])
@current_user ||= User.find_by(remember_token: remember_token)
end
という記述が出てくる。
これはremember_tokenがあった場合、
@current_userというインスタンス変数に入れてあげる、と。
この「||=」
「||」自体はどちらかの条件が成立すればtrue。
これを理解するのに、いいコラムがあったそのまま引用。
>> @user => nil >> @user = @user || "the user" => "the user" >> @user = @user || "another user" => "the user"
最後の@user || "another user"の場合は、
最初の1番目の@userが評価されるので、
コンソールに出力されるのは"the user"だということ。
要素代入を扱うメソッド(関数)のcurrent_user=(user)とは
Railstutorial第8章。
ここでRubyの要素代入関数が出てくる。
具体的には、
module SessionsHelper
def sign_in(user)
.
.
.
end
def current_user=(user)
@current_user = user
end
end
と
current_user=(user)
要素を代入できるメソッドが出てくる。
これを使う理由が謎！
同じ疑問をもっている人がいた
同じことを思っている人が、
Yahoo!知恵袋にいた
detail.chiebukuro.yahoo.co.jp
そこでわかりやすく解説させているコードがこれ。
class Hoge def current_user=(user) @current_user = user end end hoge = Hoge.new hoge.current_user = 'HogeHoge'
とりあず、
currentのuser情報を扱うときは、
current_user=(user)
みたいにするってことでいいかな。
cookiesは今から20年後に切れる
Railstutorialの第8章。
sign_inメソッドの作成のところで、SessionHelperに書く時。
module SessionsHelper
def sign_in(user)
remember_token = User.new_remember_token
cookies.permanent[:remember_token] = remember_token
user.update_attribute(:remember_token, User.encrypt(remember_token))
self.current_user = user
end
end
ここでcookies.permanent[:remember_token]とするのですが、
実はそれまでは、
20.years.from_now
と記述していたのが、
permanentはRailsが作った便利なメソッドだと。
検証に対するテストで「validする」の意味
Railsチュートリアル第６章の「name属性の検証に対する、失敗するテスト。」で、
describe "when name is not present" do
before { @user.name = " " }
it { should_not be_valid }
end
のところで理解に苦しんだというかハマった。
Yasukawa氏のスクリーンキャストでは、
実際のWebアプリケーションでも名前になんらかの文字を入れないといけないという意味では" "このような空白の文字列では許容しがたい文字列なので、エラーとして返すべき。
というテストを書いているということです。このような空白の文字列はvalidするべきではない。ちゃんとfalseが返るべきだ。というテストになります。
と説明している。
僕はvalidする意味を履き違えていた。
validは直訳すると
1.根拠の確実な，確かな，正当な，妥当な.
2.有効な，効力のある，効果的な
という意味がある。
もちろんvalidateのvalidなんだけど。
なのでこのテストは、
" "こんな空白の場合は「有効にするべきではない」というテストを書いているということなになる。
スッとしました。
DB Browser for SQLiteのインストール
便利らしいので後でインストール
DB Browser for SQLite
よく使う「Gitのmerge」「githubへのpush」「herokuへのデプロイ」3セット
Railsチュートリアルの作業を行っていてよくある保存の作業。
1.Gitをmastarブランチの切り替えてマージする
$ git add . $ git commit -m "作業内容を記入" $ git checkout master $ git merge filling-in-layout
現在のブランチを確認
$ git branch filling-in-layout *master static-pages
2.githubへのpush
$ git push origin master
3.herokuへのデプロイ
$ git push heroku master
herokuでアプリケーションを見る
$ heroku open
herokuでエラーが出たら
$ heroku logs
なぜRubyのハッシュでシンボルを利用するのか？
例えば、
文字列をキーにしたハッシュの場合、
user = { "first_name" => "Michael", "last_name" => "Hartl" }
シンボルをキーにしたハッシュの場合、
user = { :name => "Michael Hartl", :email => "michael@example.com" }
ここRailsチュートリアルスクリーンキャストのYasukwa氏の説明では、
キーを
文字列とした場合（string）
整数とした場合（integer）
シンボルとした場合（symbol）
の3つの計算速度を処理した場合
文字列が一番時間がかかり整数が一番高速だった。
しかし、
ハッシュのキーを整数にして
1 => "Michael Hartl",
2 => "michael@example.com"
みたいなのは人間の目から見るとあまりにもわかりにくい。
なので計算処理速度も早く、人間の目にもわかりやすいいいとこ取りをしたのがシンボル。
user = { :name => "Michael Hartl", :email => "michael@example.com" }
LL界とかLL書く人とかの「LL」とは？
Rubyの記事を読んでいたら、
LL界の委員長のpython
とかいう言葉が出てきた。
LL界ってどのセカイよ！
ってことで調べてみたら
軽量プログラミング言語（けいりょうプログラミングげんご、和製英語:lightweight language、LL）
っぽいですね。
