メンタリングも10回となりました。
自分のオリジナルWEBサービスの作成に向けて日々イライラしながら頑張っております。
今日は10回目のメンタリングということで、プログラミングに入る（というかすでに入ってるけど）ための、設計書のレビューをお願いしました。
というのもプログラミングをしていく中で自分が書いた設計が怪しい箇所が出てきたのと、
どうもうまく動かないなと思う部分があったりして設計書を書き直したりしています。
初心者だと設計書どおりにプログラミングが進みません。プログラミングをしては設計書を修正し‥の繰り返しなので大変です。
テックアカデミーの講師にレビューをお願いした内容
今回レビューをお願いした内容は画面の遷移と、ルーティングについてです。
画面数と遷移
僕が作ろうとしているのは飲食店の口コミサイトなので画面の数はそう多くありません。
①ショップ検索画面
②ショップ一覧画面
③ショップ詳細画面
④ショップ口コミ投稿画面
この4つです。また検索して出てきたショップを全てDBに入れるわけにはいかないので初めて口コミを投稿したタイミングでショップ情報も口コミもDBに保存する‥という動きにする予定です。
なので
⑤ショップ初めての口コミ投稿画面
を追加して主な画面はこの5つで遷移していきます。
ルーティング
僕が当初想定したルーティングはこのように考えました。
| Prefix Verb | URI Pattern | Controller#Action |
|---|---|---|
| root GET | / | toppages#index |
| kuchikomi_shop GET | /shops/:id/kuchikomi(.:format) | shops#kuchikomi |
| shops GET | /shops(.:format) | shops#index |
| new_shop GET | /shops/new(.:format) | shops#new |
| shop GET | /shops/:id(.:format) | shops#show |
| kuchikomis POST | /kuchikomis(.:format) | kuchikomis#create |
上から、ドメインのルートを表示するにはtoppages#indexアクションに任せる。これが①の検索画面でもあります。
②のショップ一覧画面は/shopsで、shops#indexアクションで行います。
③のショップ詳細画面は/shops/:idで、shops#showアクションで行います。このへんまでは普通のRailsの構成かと思います。
問題は④と⑤です。
④のショップ口コミ投稿画面は、/shops/:id/kuchikomiにやらせようと思い、shopsコントローラーにわざわざkuchikomiというメソッドを作って行おうと思いました。
で⑤ですがショップの初めての口コミ投稿時点ではショップがDBにまだ保存されていないので、つまりショップの新規保存でもあるわけで、shops#newアクション経由で/shops/newの画面で入力させようと思っています。この画面で口コミを投稿してもらうので、formタグのPOST先は、kuchikomis#createにしています。
私の想定としてはこんな感じでした。
テックアカデミーでのレビューの結果がこちら
それから親子関係があるModel（この場合はショップに複数の口コミがぶら下がるので、親がショップで子が口コミ）の場合は、accepts_nested_attributes_forというメソッドを使うとスマートにDBに保存を行ってくれますよ。
こういうメソッドの存在をそもそも知らなかったので調べて取り入れてみます。Railsて簡単にやれる方法を探せばあるんですよねぇ。探すのが難しい訳ですが。
あと、途中で気づいたのが④のショップ口コミ投稿画面/shops/:id/kuchikomiから、口コミが投稿（POST）された後の送信先を作ってませんでした。
これは後で付け足しました。
POST /shops/:id/kuchikomi(.:format) shops#kuchikomi
これで行けるかなと思ったのですが、これでは無理。Modelについてる標準的なnew→投稿画面POST→createメソッドならできるけど、今回のこの処理は自作したので
kuchikomi_post_shop POST /shops/:id/kuchikomi_post(.:format) shops#kuchikomi_post
このようにPOSTの送信先を変えました。これでショップModelの中にわざわざkuchikomi_postメソッドを書いて処理させる事にしました。
普通なら口コミModelなんだから、kuchikomi#createでやりそうですが、上記のレビューの流れから紆余曲折を経てここで着地しました。
結果ルーティングは
| Prefix Verb | URI Pattern | Controller#Action |
|---|---|---|
| root GET | / | toppages#index |
| kuchikomi_shop GET | /shops/:id/kuchikomi(.:format) | shops#kuchikomi |
| kkuchikomi_post_shop POST | /shops/:id/kuchikomi_post(.:format) | shops#kuchikomi_post |
| shops GET | /shops(.:format) | shops#index |
| shop GET | POST /shops(.:format) | shops#create |
| new_shop GET | /shops/new(.:format) | shops#new |
| shop GET | /shops/:id(.:format) | shops#show |
としました。kuchikomiというコントローラーが無いのがなんともムズムズしますね。。
その他の相談事
テックアカデミーでRailsの学習レッスンを進めてる時は覚えも早くレッスンをこなすたびに理解も深まっていったのですが、ひとたび日にちがあくとすっかり学習した事を忘れてしまいます。
自分が学習したことは一覧性があるノートにメモをとり絵を交えて理解を深めていったほうが良いと今更ながら気づきました。今までエクセルにまとめていた訳ですが思い出すのに苦労しています。
中間テーブルって何だっけ？
今回、User → Kuchikomi ← Shop この3つの関係Modelで進めているのですが、Kuchikomiって中間テーブルだっけ？なんて思ったり。講師に確認したところ外部キーだけのテーブルを中間テーブルと言いますね、という話で。今回のkuchikmoiテーブルは中間テーブルではないことが発覚しました（笑
他社APIを利用するときの注意点Validation
それから他社APIを利用してデータを受け取る時ですが、Railsでは一般的にDBに保存するときにValidationでデータのチェックを行いますが、他社APIからの受取時には空の場合も想定してValidationではカラNGの処理はやらないでアプリの中で考慮してプログラミングする事が重要だと教えてもらいました。
今回のメンタリングの内容は以上です。
テックアカデミーの契約終了まであと40日！頑張ってWEBアプリ作るぞぉ～～！！
最後に初めてのチャレンジでイライラしてる方にこの言葉を送ります。
本田宗一郎
自分も腹が立ちながらプログラミング学習していますがより理解を深めるために覚え直すために何度もやり直ししています。
てことで皆さんもプログラミング頑張ってください！
