Rails routesを書く時の注意点（超基本）
routes.rbを書く時
基本形 (Scaffold準拠にルーティングを追加するとき）
単数なのか複数なのか、注意すること。
- resource
- resources
複数形リソース
一番基本形 (resources) キーワード、リソース名ともに複数形
使用例：
resources :products
生成されるパス
Scaffold基本形と完全一致(7つ)
Prefix Verb URI Pattern Controller#Action
products GET /products(.:format) products#index
POST /products(.:format) products#create
new_product GET /products/new(.:format) products#new
edit_product GET /products/:id/edit(.:format) products#edit
product GET /products/:id(.:format) products#show
PATCH /products/:id(.:format) products#update
PUT /products/:id(.:format) products#update
DELETE /products/:id(.:format) products#destroy
単数形リソース
どういう時に単数形リソースを使うかの参照記事 Rails のルーティング | Rails ガイド
場合によっては、ユーザーがページを表示する時にidを参照することのないリソースが使用されることがあります。たとえば、/profileでは常に「現在ログインしているユーザー自身」のプロファイルを表示し、他のユーザーidを参照する必要がないとします。このような場合には、単数形リソース (singular resource) を使用してshowアクションに (/profile/:idではなく) /profileを割り当てることができます。
使用例：
resource :profile
生成されるパス (index は生成されない） :idもない
Prefix Verb URI Pattern Controller#Action
product POST /product(.:format) products#create
new_product GET /product/new(.:format) products#new
edit_product GET /product/edit(.:format) products#edit
GET /product(.:format) products#show
PATCH /product(.:format) products#update
PUT /product(.:format) products#update
DELETE /product(.:format) products#destroy
page GET /pages/*id high_voltage/pages#show
単語の単数形複数形に注意
resource :products とかやると、意味がわかりにくいので注意。
id指定なしでアクセスできる単数形リソースを作ろうとしている時は、リソース名も単数形にした方がいい。
Scafolldと同じrouting書こうと思ってたのに、何故かindexアクションが生成されてない！？と思ったら、ウッカリ resouce (s忘れ）してないかチェックすること。
Rails で erb -> haml への変換ポイント（どのgemの機能で変換するか）
コメントで教えてもらった
自分の記事に、 erb2haml の別オプションがあることを教えてもらって、「おお！」と思って調べてみたら、初心者的に混乱した箇所があったのでメモメモ。
元々の手順
erb2haml で変換、してシェルでチマチマ削除してる。
変換
$ bundle exec rake haml:convert_erbs
削除
$ rm app/views/layouts/application.html.erb
教えてもらった手順
gemの提供タスクで、置き換えまでやってくれる方を使う。
$ bundle exec rake haml:replace_erbs
やってみようと思ってハマった件・・
最近勉強を助けるために、RubyMineのお世話になってるので、RubyMineからRakeタスクを実行！
使えるタスクをRubyMineが補完してくれるので、ナイス！と思ってたら・・何故か haml:convert_erbs も haml:replace_erbs も出てこない・・・
haml:erb2haml しかない・・・
そうか！gemが入ってないプロジェクト見てるのかも！
と閃いて、Gemfileを確認すると、やっぱり erb2haml 入ってないプロジェクトだった。
該当のプロジェクトに含まれていた haml 関連の gems
erb2haml入れてみると・・
Gemfileに gem 'erb2haml' を入れてから、もう一度RubyMine様に聞いてみると・・
おお！！出てきた〜〜♪
別々のgemで同じネームスペース（？）みたいの使ってるってことなのかな。。
難しいな・・この辺コピペしてきたGemfileを入れまくってる初心者的には、どれがどれなのかちゃんと理解してなくてちょっと混乱するポイントかも。
勉強になった。。
黒魔術なgem inherited_resources
Railsのコントローラーに RESTful の基本形コントーローラーメソッドがないのに、create, update, destroyできてる・・
黒魔術的なgem, inherited_resourcesが入っていないか確認する。
gem 'inherited_resources'
これが Gemfile に含まれていて、対象のコントローラーが inherit_resourcesを有効にしている場合、デフォルトの index, new, edit, show, create, update, destroy が省略できるようになっている。
有効にする方法
class ProjectsController < InheritedResources::Base end
または
class ProjectsController < ApplicationController inherit_resources end
対象のコントローラーが、ApplicationController以外を継承してる場合、親のクラスも調べる。 inherit_resources有効なClassを継承していても、やっぱり効いてくるので注意！
inherit_resources で更にアクションをカスタマイズしたい時
inherit_resourcesで追加されるアクションの基本動作はScaffoldの通り。
destroyは対象モデルを削除した後に、そのリソースのindex urlにリダイレクトする。みたいな感じ。
それらの基本動作を上書きしたい場合、 ! をつけたアクション名で呼び出す。
やり方はこんな感じ。
class ProjectsController < ApplicationController
inherit_resources
def show
show! do |format|
format.html { render "edit" }
end
end
def destroy
destroy! { root_url }
end
end
カスタマイズしているアクションの動作
- showのrenderするテンプレートをeditにしている
- destroyした後のリダイレクト先をリソースのindexではなく、アプリケーションのルートURLにしている
defaultsでデフォルト動作をフックする
class ProjectsController < ApplicationController inherit_resources defaults finder: :find_by_name end
findのidで探すところを、モデルの find_by_name で代替するように指定したりできちゃう。らしい。
注意点
このgemはもうあまり使われていないらしい。 元リポジトリのREADMEでも一番最初に Deprecation notice が書かれているので、今から新しく使うことはしないほうが良さげ。
I suggest developers to make use of Rails' respond_with feature alongside the responders gem as a replacement to Inherited Resources.
と書いてあるので、respond_with でフォーマットの指定ができるようになったので、標準の方を使ったほうが良い、らしい。
とはいえ、見かけたソースに 標準アクションがないのに、なんか動作してるけど！？という時に、原因を見つけるために知っておいた方が良い、くらいの位置づけっぽいです。
今週のRails勉強記録と目標
今週は簡単なRailsアプリを素早く作る練習を再開。
コード書き始めたら、アレコレ地味に落とし穴に落ちて、いろいろと勉強になった！
先週入れたdebug力向上のためのgem（ツール類）が大活躍♪
目標は2週間で前回のコピーアプリくらいを作りたかったんだけど、1週間経った時点でかなりまだまだな感じ。。 相変わらずスピードに難あり。
Devise & OmniAuth (with Github) で予想してた以上に苦戦
あと、初めてOmniAuthをやってみたので、週の前半はそこにほとんど時間を取られてしまった・・
Devise & OmniAuth は、たくさん紹介記事とかもあるし、すぐできるかな〜と高をくくっていたけど、意外と苦戦・・ 最初に参考にした情報がOmniAuth ( Deviseなし ) だったので、読み替えがうまくできてなくてハマった・・
OmniAuthで参考になったページ
最終的にここのページの通りにやればよかった。。
Perfect RailsでOmniAuthやってる箇所と、RailsCastの簡単なOmniAuthの説明ページの内容を合わせながらやったところ、情報が古かった＆Deviseとの連携がなかった、で無理やり読み替えしながらやったら、グチャグチャになってしまった。。
やはり公式を見るのが一番・・・（英語も普通に読みやすかった・・）
最初におもいっきり注意書きがあって、
Remember that config.omniauth adds omniauth provider middleware to your application. This means you should not add this provider middleware again in config/initializers/omniauth.rb as they'll clash with each other and result in always-failing authentication.
意訳：config.omniauth が middleware を追加するので、config/initializers/omniauth.rb で middleware の定義しちゃダメ！
って書いてある。。RailsCastとか、ちょっと古い情報だと、middleare定義するように書いてある文書があるので、一番最初に注意書きしてあるみたい。 読み飛ばし、ダメ；；
ちゃんと理解した！と思った Rails で Ajax の書き方でハマった・・
理解した！と思って、先週記事を書いた Ajax の扱いについて、何故か意図通りいかない事象に遭遇・・
結局ファイルのパスを間違えていた（途中でnamespaceに移動させたりしてるうちに、残念な状態になってた）だけだったのに、気づくまでにかなりの時間がかかってしまった。。
Railsでは「お約束の場所」「お約束の名前」からズレてしまうと大きな痛手を受ける。。
こういうロスタイムいかんなぁ。。
こっちも、もうちゃんと理解した！と思ってた partial の書き方でハマった・・・・
何が元々の形で、どう省略を許されているのか、という理解が足りなかった。。 これも発見までに地味に時間がかかってしまった。
Railsでは「よく使うパターンなので省略を許している」オプションが出てくることが多い。
しかも適当に情報を集めてると、
- もともとの形
- 省略が許されているからそうなっている形
- 普段あまり使わないオプションが入ってきた場合の形
の、どの状態なのかわからないまま使っていることになったりする。
これを意識して調べておかないと、省略形が元々の形だと思って、むやみにオプションだけを追加したら、動きません！状態になってしまう。
目標
いつも使うお約束のgemやRailsの機能を、イチイチ調べずにスラスラ書けるようになりたい。。
今週のRuby, Railsの勉強
今週はあんまり新しい知識を得た感がない・・けど、なんとか2記事Rails関連をQiitaに投稿。
まとめ記事1
おすすめされて既に知っていたgemである、BetterErrorsだが、知らなかった事2点発見があった。
BetterErrorsの新発見
- エディタ設定をしておくと、ブラウザからファイルパスをクリックすると、該当のソースコードを開いてくれる
- Ajax Request時で、エラー見れないじゃん；；と泣く泣くコンソールログを見ていたが、実は実行後に別の画面に遷移してしまったあとでも、
http://localhost:3000/__better_errorsと打ち込むと、最後のエラー画面を見せてくれる
2個目のAjax Requestでもデバッグ助けてくれる、というのに感動！
RailsPanel
Chromeの拡張で、ブラウザ上からいい感じにトレースが見れる。
たしかどっかでチラッと見かけたような気がするけど、ちゃんと導入してなかった。 コレはかなり便利そう♪
まとめ記事2
RailsでAjax書く時の基本的な流れをまとめた。 多分先月のコピーアプリ作成時にまとめかけて、完成しないまま放置してたっぽい。
その他
全然Rails関係ないけど・・・
このところ、AngularJSをやっている。。 JavaScript恐るべしなコールバック地獄・・・ たかだかファイルシステムからファイル取り込んで、表示するだけで、何回コールバック関数書くのよ；；
格闘の末のCordova File APIを使ってファイルシステムにアクセスして、最後の最後に処理を一回挟むコードに成功。
ちょっとだけ Promise とやらの使い方が分かった気がする。 ・・・が、まだ胸を張って「Promiseあーね！」とは言えない；； まだまだまだまだ。。である。
コードかコンテンツか・・それが問題だ・・
最近RubyとRailsの勉強をしてて、どっちかっていうと読み系の座学が多くて、コード書いてない。。
そして読んだ結果をまとめたりする時間も結構バカにならず、こっちに比重置いてると、コード書けない。。
そもそもプライベートの勉強時間って、普通に生活してると、子供が学校行ってから、自分が出勤するまでの朝１時間、夜子供が寝てから、自分が眠くなって終了になるまでの間２時間くらいの、１日合計３時間くらい。。
その中で、コードかコンテンツか・・とやっぱりどちらかしかできないわけで・・・
理想的には、仕事してる間の７時間くらいが、コードに費やされていれば、残りのプライベート勉強タイムにコンテンツ書けたら、丁度いいバランスなんだけど、 仕事で使ってる技術と、自分がこれから進みたい技術がずれてる場合、プライベートの３時間で両方捻出するしかない；；
自分の場合、先月５〜６月はとにかく書くの心理的敷居を下げるために、コンテンツ重視（この時はあまりコード書けてない）、その後実践！と思ってアプリ作りしてた７月は、コードは書いてたけど全然ブログ書けてなくて・・
うーん・・どうしてもどっちかになっちゃうんだよな；；
というのが最近の悩みだったわけです。。
で、昨日たまたま調べ物してて、そこのページでRTされてた↓のツイートを見る機会があり・・
多くのプログラマが、開発したソフトウェアは公開せず、知見・知識はブログやポッドキャストの形で無償公開するのに対して、私は開発したソフトウェアは自由ライセンスで公開し、知識・知見の方は雑誌記事や講演など基本有料で提供しているのは興味深い違いだと思う。
— Yukihiro Matsumoto (@yukihiro_matz) 2015, 8月 20ムムム・・確かにそうだな〜
コレ、このまま短絡的に判断すると、コードを無償公開して、知識・知見といったコンテンツは有料の人の方が、大成功しそう・・なんだけど・・・
最初にパッと思いついたこと
自分の場合、なぜ知識を無償公開するのかっていうと、そもそもその知識を得たソースが、誰かの勉強記録だったりとか、無償公開されたものから派生していることが多い。
よく自分の中でイメージしてるのは、仏教的な「お地蔵さん」 （注：とか言って、全然ちゃんとした仏教ととかではないので勝手な思い込みレベルなんだけど）
お地蔵さんって、道を目指している人々を、その道の途中途中で、「こっちでいいんだよ〜がんばれ〜」と励ましてくれているイメージ。
決して道を極めている訳じゃないんだけど、途中の取っ掛かりとしていつもそこに居てくれる、みたいな。
道はまあ、人それぞれなんだけど、途中にお地蔵さんが居ない道って、めっちゃ辿りずらそうな感じ。。 「あーあの先、光ってるけど、全然行き方わからん；；」と、大多数の人は諦めざるを得ない。。（ワシか！）
誰かが立ててくれたお地蔵さんを目印にここまで来た、しかし自分はその間（オリジナルのお地蔵さん立てた人との知識レベルの差とかで）ハマった箇所があったりしたら、新たにお地蔵さん立てる感じ。 それが自分がお地蔵さんを立てる理由・・ですかね。。
次に道を通る人が、もしかしたらそのお地蔵さんを目印にしてくるかもしれないので・・
現に自分は、勝手に立ってたお地蔵さんを勝手に目印にして進んできたので、私の新しい勝手に立てるお地蔵さんが、いつか誰かの役に立つ可能性も捨てきれないわけですしね。。 （そしてその誰かは自分ってことも十分ありうる・・）
ちょっと時間経ってから思い出したこと
そういえば、今週たまたま見かけた記事↓も、なんか結びついた。
結びついた箇所を抜粋すると、
エンジニアにとって、「コードを書くか、もしくは記事やスライドなどのコンテンツを作るか」は永遠の二択問題だ。
この問題の解き方については、Steve Yegge氏の記事が委曲を尽くしている。
「あなたには（会ったことがない）あこがれのエンジニアがいますか? わたしにはいます。しかし面白いことに、彼や彼女らが書いたコードはあまり読んでないのです。有名と呼ばれるようなエンジニアは、主に文章を通じてわたしに影響を与えました」
Steve氏もまた、自身のブログ“Stevey’s Blog Rants”で有名になったエンジニアだ。コンテンツに影響されたから、コンテンツを作る道を彼は選んだのである。
コンテンツに影響されたエンジニアはコンテンツを書き、公開する。
コードに影響されたエンジニアはコードを書き、公開する。
ってことなのかも。
世の中にコンテンツに影響されたエンジニアの方が多い、ってことなんだろうな。
自分の場合は、明らかに（会ったことがない）あこがれのエンジニアのコンテンツに影響受けてる。
これ書いてて思いついたこと
最初の部分の、自分の時間の使い方を書いてて気づいた。
自分的、理想的な時間配分ができてるとすると
- プライベート時間 : コンテツ書き
- 仕事時間 : コード書き
に割り当てていると、必然的に仕事時間で作った成果物を勝手にそのまま公開するわけにはいかない・・
仕事時間にOSSやってる人じゃないと、そのままコード公開できないしな。。
でも、２つ目の「コードとコンテンツ、どちらにより大きな影響を受けたか」でコードを選んでいる人の場合、プライベート時間もコードに割り当ててるから、やっぱし自分自身がどちらに影響を受けたか、が答えな気がするな。。
