バックエンド

【Ruby on Rails概念思想】 使い方やコマンド・Gemチートシート

Ruby on Railsまとめ

reisuta

Webエンジニア | 20代中盤 | 大学時代はGmailすら知らないIT音痴でプログラミングとは無縁の生活を送る → 独学でプログラミングを学ぶ → Web系受託開発企業にエンジニアとして就職 → Web系自社サービス企業に転職 | 実務未経験の頃からVimを愛好しており、仕事でもプライベートでも開発はVimとTmuxを使っているので、VSCodeに疎いのが最近の悩み。何だかんだでやっぱりRubyが好き。

Railsの概念思想

Ruby on Railsに限らず、
技術には何らかの思想があることがほとんどです。

特にRailsはその中でも
その傾向が強く、
いわゆるRails wayを遵守しないと、
なかなかRailsのパワーを引き出せません。

以下、Railsの概念思想を解説します。

本記事は、どちらかというと、
Railsまとめのような記事なので、
具体的なRailsの環境構築などは、
こちらの記事 を参照ください。

MVC

Railsの概念でもっとも重要なものといえば、
やはりMVCでしょう。

MVCは、Rails専門の概念というわけではなく、
例えばLaravelとかもたしかMVCだったと思います。

MVCもがちで学ぶと結構複雑で、
奥が深いのですが、とりあえず、
Railsを使うだけなら細かいことは気にしなくても大丈夫かなと思います。

平たく言うと、Model View Controllerの三つがあって、
アプリケーションの責務をこの三つに分割しているのがMVCの概要です。


よくRailsのMVCの説明で、
「モデルを介して、ビューにわたされて」みたいな
それっぽい理屈を聞かされるかもしれませんが、
正直私は初学者のときに、こんなことを言われても
混乱しただけでした。


少なくとも、とりあえず、Railsを使えるようになるレベルであれば、
MVCの深い理解はなくてもいいと思います。

重要な流れは、
Controller → Viewにあるかなと思います。

なぜなら、Controllerで必ずModelの呼び出しをするとは限らないので、
MVCの説明であたかもController層で必ずModelを経由するみたいな説明は混乱を招く気がします。
(私がそうでした)

それにMVCは、責務の分割、保守性の向上のための、
アーキテクチャーであり、流れを教科書的に、
定義するものでもない気がするので、上記のような説明でも
そこまで外れていないかなと思っています。
(MVCガチ勢の人からすると「ちげえよ」って感じかもしれませんが)

Macとマグカップの画像

Railsを使うにあたって、最低限抑えたい事項は、
Routingを張ったエンドポイントに対し、
Controllerのメソッドが呼ばれ、そのメソッドの行き先が、
同じディレクトリのviews配下に進んでいくということだけです。

よくRailsは覚えゲーって言われますが、
確かにこのあたりは割と覚えゲーですかね。

モデルうんたらは、考えなくても、
要は、Controllerでの処理でModelの呼び出しをしているだけで、
上記の流れに、かならずModelの経由が組み込まれるととらえるのは、
どうも逆に素直じゃない気がするなと個人的には感じます。

ちなみに、MVCの詳細は、
下記のドキュメントに記載があります。

https://railsguides.jp/getting_started.html#mvc%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B

モデルは、DBの疎通を担当し、
Viewは、画面の見た目を担当し、
Controllerは、両者の仲介をするという感じです。

つまり、DBのデータをViewにまで
渡す一連の流れみたいな感じですかね。

本来のRailsであれば、
こんな感じですが、
最近は、Rails + ReactみたいなSPA開発が主流なので、
Railsがビューを担当するということは少なくなっています。

ただ、それでもRailsのビューは、
フロント(Reactなど)にわたすJsonを定義するので、
そういう意味では、MVCになってはいると思いますが。

以下、用語について、
詳しくみていきます。

model

MVCのところで、
modelについてちょっと軽視するような説明をしましたが、
model自体は、Railsにおいて重要な概念です。

modelとは何ぞ?って感じだと思いますが、
面倒くさいことは考えなくて大丈夫です。

要は、DBのテーブルです。
(厳密には違うのですが、最低限Railsを使うだけならこの理解でも十分でしょう。)

まあ、Rails特製の、便利なDBテーブルとでも
思ってくれれば大丈夫です。

事実、Controllerとかの処理では、
このModelを使ってDBにアクセスをします。
つまり、面倒くさいSQLを書かなくても、DBと会話してくれる、
便利な通訳みたいな役割をしてるのが、このmodelというわけです。

これが便利すぎて、SQLをかけなくなる、
事象が多発しているので、気をつけたいところですね。

まあ、こういったORMは、
Rails以外にもあるので、
特段Railsの強みというわけではありませんが。
(そうはいっても、Railsのモデルがわかりやすく使いやすいのは事実です)

migration

次によく聞く用語として、
migrationがあります。

migrationは、ほかのフレームワークでも聞くかと思います。

LaravelやPrismaとかでも、
migrationコマンドがあったと思います。

これは平たく言うと、
migrationファイルという、DBの設計書というか、
「こんな感じのテーブルつくりたいんだけど」みたいな、
設計を定義したファイルを実際にDBに反映させることをいいます。

DBにテーブルおを作る方法として、
いきなりSQLでcreate tableとかでも
作れないわけでも有りませんが、
メンテナンス性にかけますし、
いきなり本番実行はtypoなどのリスクも大きいです。

そこでいきなり作る前に、
確認するフェーズみたいなものを挟めたら理想だと思います。

それが、migrationにあたりまして、DBにテーブルとかを作る前に、
設計書を作って、反映させるというワンクッションを置いた感じです。

migrationは、歴史の側面もあります。
というのも、migraitonファイルを生成して積み重ねていけば、
過去にどういうテーブルを作ったり修正したのかということが、
migrationファイルを見ればわかるからです。

Gitの歴史に通ずる部分がありますね。
Git管理下に置けば、メンテナンス性は上がりますが、
管理下から外せば、どのタイミングで編集されたりとか、
過去の設定に戻したいとかがやりづらくなってしまいますよね。

migrationは、このGitのように、
DBテーブルの作成・修正の歴史を積み上げていくような側面もあるというわけです。

それにmigrationのメリットは、ロールバックのように、
migrationを反映する前に戻すこともできるということで、
DBの構造を歴史をさかのぼるようにして変えることができます。

この点も、Gitに似ていますね。

ルーティング

次の用語は、ルーティングです。

ルーティングも、ほかのフレームワークとかでも
普通に登場する言葉で、Railsでの意味も大して変わりません。

基本的に、Railsの場合、config/routes.rbに、
エンドポイントを設定して、呼ばれるControllerの処理を指定します。

イメージとしては、蜘蛛の巣を張り巡らす感じです。

Railsを使いたてのころ、
私はルーティングは、なんとなく、
resourcesで指定して、controllerに行って、
viewに行ってみたいな感じで、
機械的に覚えていました。

まあ、これはこれで間違えでもない気もしますが、
ルーティングは、基本的には結構自由です。
(できればresourcesを使いたいが)

そして、呼ばせるControllerをルーティングで指定し、
Controllerのメソッドで処理を書いていくことは、
あたかも、用意した蜘蛛の巣(メソッド)に、
誘い込む(ルーティングのエンドポイントにアクセスさせる)みたいな
イメージのような気がしています。

私は、ファイルエクスポートとか、インポートの処理を、
ルーティングで指定しているのをみて、
ルーティングの意味が腑に落ちました。

ドキュメントのページは下記ですね。

https://railsguides.jp/routing.html

ただ、ルーティングも好き勝手やっていいということはなく、
やはり適切なapi設計というものがあります。

ただ、これは、Railsというよりは、
API設計の話になると思うので、
割愛します。

余談ですが、私が以前経験したプロジェクトでは、
ルーティングが、config/routes.rbにまとまっておらず、
別ファイルとかに個別に定義されていれ、
DockerのNginx経由でルーティングの上書きのようなことが行われていて、
控えめに言って地獄でした。

Rails wayを軽んじて好き勝手やり始めると、
一気に負債化するので、Railsを採用するからには、
しっかり道をあるきましょう。

RailsのGem

Ruby on Railsにおける、
外部ライブラリをGemと呼びますが、
Railsは、割と何をするにも、
Gemに頼る文化?みたいなものがある気がしています。

その中には、外部ライブラリだけど、
実質標準ライブラリでしょっていうぐらい毎回使うものもあります。

なので、そういったGemなどについてまとめてみようと思います。

ちなみに、Railsもgemです。
Ruby on Railsを使う時点で、
使いますね。

ほどんど毎回使うGem

まずは、スタメンを紹介しましょう。

rucocopLintツール
rspecテストツール。minitest派もいるだろうが、なんだかんだrspecのほうが使われている気がするし使いやすい。
byebugデバッグツール。pry-railsとかでもいい。
factory_bot_railsテスト時のダミーデータを作成してくれる。rspecとハッピーセット
※railsやDBやアプリケーションサーバーのgemみたいにデフォルトで入っているやつは除外してます。

正直、これ以外にもスタメンチックなgemはあるのですが、
明示的にそのGemの機能を使うというよりは、
Railsの仕組みのために使われていて、
Rails wayに乗っかれば、そこは隠蔽されるみたいなGemも多い気がするので、
そういうのは省略しています。

場合によって使う機会が多いおなじみのGem

次にベンチ入りメンバーを紹介しましょう。

ransack検索機能を簡単に作れるGem。検索機能が必要な際は、ransackを入れるかどうかを検討することがほどんど。
kaminariページネーションを簡単に作れるGem。こちらもページネーションと聞いたらまっさきに思い浮かぶGem
jbuilderview層でjsonを返す、主にAPIとして使用するときに必須になるGem。一応jbuiler以外にも、代わりとなるgemはたくさんあるが、知名度はこいつが圧倒的
dotenv-raiils環境変数を使うときは、使うことを検討するgem
capistranoデプロイするときにお世話になるgem。Railsデプロイのデファクトはこいつなので、事実上、毎回使うかもしれない。
whenevercron機能を使いたいときに使うgem
sidekiqこいつは実務だったらスタメン。個人開発ならベンチ入りメンバーというところでしょうか。
redissidekiqと一緒に使われることが多いgem。使っている企業は多そうだが、使っていない企業も多そう
enum_helpenumを使う際は入れることが多いと思う
cancancan権限管理系では、割と有名かと
carrierwaveファイルアップロード系は俺にまかせろっていう感じのgem

これ以外にもあると思いますが、
ぱっと思いつくのはこのあたりですかね。

テストでよく使うgemとか、
Google apiのgemとかも場合によっては、
かなり使用頻度高い気がします。

Railsの場合、ページネーションや検索機能なども
gemで実装したりすることが多いのが印象的ですね。

PHPとかだと、このあたりの機能は、
自分で書いていたような気がします。

基本的にライブラリのコントリビューターの方は、
優秀なエンジニアばかりなので、
その方たちにメンテナンスされているのであれば、
自分で書くよりも絶対に良いですね。

ただ、更新が止まっていたり、
自分で書き換えたりする場合は、
そのライブラリのコードが読めないといけないので、
大変になる場合もありますが。

 

Railsコマンド

Ruby on Railsはフルスタックフレームワークなので、
コマンドなども色々あります。

そして、そのようなコマンドの中でも、
よく使うやつとそうでもないやつなど、
色々あります。

ここでは、よく使うやつをご紹介します。

よく使うコマンド

rails cRailsコンソールに入るコマンド。Railsコンソールは、バックエンドにRailsを採用する一つの理由になるぐらいの便利ツールで、正直Railsを使うならこれを使わないことは考えられないレベル。コンソールといいつつも、サンドバッグモードとかにしない限り、ここでのデータの追加とか削除は、すべて反映される。
rails db:migratemigrationファイルのmigrationを実行する
rails db:migrate:statusmigrationの状況を確認する。upとかdownとかがわかる。railsの場合、migrationがpendingになるとエラーになるので、migrationの状況を確認することは意外とある。
rails routes現在設定されているルーティングを確認できる。パイプでgrepをかけることも多い
rspecrspecのgemがあるときに使うコマンド。事実上のデファクトのテスト実行コマンドであり、ファイル名とかを指定して実行することも多い。
rubocoprubocopのgemがあるときに使うコマンド。RailsのデファクトのLintツール
rails generate modelモデル生成コマンド
rails generate controllerコントローラー作成コマンド
rails generate migrationmigration作成コマンド

これ以外にも、よく使うと感じるコマンドは、
あるかなと思います。(rails db:rollbackとか?)

ここでは、本当によく使うわというやつを
上記に記述しました。

Rails Consoleは本当に便利なので
いつもお世話になっております。

あわせて読みたい【Ruby環境構築】Rubyとは?rbenvインストールから

本記事では、Rubyについて解説します。プログラミング言語の学習をする際は、文法なども勉強する必要がありますが、それ以外にも実行環境を構築する必要があります。 本記事では、Rubyの概要から、環境構築 ...

続きを見る

あわせて読みたい【Redis基礎】Redisとは何か?Redisの基本を解説

本記事では、Redisの概要について解説します。Redisは、最近のモダンなWebシステムでは使われることが増えてきた、NoSQLの一種です。 Redisの知識は、インフラの知識にも、バックエンドの知 ...

続きを見る

  • この記事を書いた人
  • 最新記事

reisuta

Webエンジニア | 20代中盤 | 大学時代はGmailすら知らないIT音痴でプログラミングとは無縁の生活を送る → 独学でプログラミングを学ぶ → Web系受託開発企業にエンジニアとして就職 → Web系自社サービス企業に転職 | 実務未経験の頃からVimを愛好しており、仕事でもプライベートでも開発はVimとTmuxを使っているので、VSCodeに疎いのが最近の悩み。何だかんだでやっぱりRubyが好き。

おすすめ記事はこちら

Vim/Neovimプラグイン 1

プラグインをどれだけ入れるかは、その人の思想なども関係するので、一概にこれがいいというのはないかもしれません。 プラグインを全く入れない人もいれば、100個以上入れる人もいます。 ただそれでも、これだ ...

VimとNeovimの比較 2

本記事では、VimとNeovimの違いについて、解説します。 VimとNeovimの違いについては、普段頻繁にVimなどを使う方でなければ、正直、あまり気にしなくてもいいかなと思います。 ただ、Vim ...

Ruby変数やすべてがオブジェクトについて 3

本記事は、Rubyの基礎文法である、変数や真偽値、論理演算子に触れると同時に、「すべてがオブジェクト」というRubyの特徴的な思想についても解説します。 この思想は、Rubyの文法の根幹になっているの ...

4

エンジニアにおすすめの技術書 書籍学習は、エンジニアの嗜みみたいなところがありますが、 良書というものは、意外とそこまで多くもありません。 そこで本記事では「技術書マニアの筆者が厳選した技術書20選」 ...

5

エンジニアになるには? プログラミングは、専門性が高く自分一人で勉強するのが大変に感じることも多いですよね。 そこで本記事では「おすすめのプログラミングスクール5選」を特徴と、現役エンジニア目線で優れ ...

-バックエンド