Nayuta_ichinoの日記

はじめまして、市野那由他です。このブログでは、プログラミング学習で学んだことを発信していきます。誰が読んでも理解しやすい、を念頭に執筆していきますので、よろしくお願いいたします。

bundler について

 今回は、自分が bundler の扱いを把握するまでに苦労したので、それを分かりやすくまとめていこうと思います。

 まず、bunder について説明をする前に以下の周辺知識について軽く説明をします。

 

1 : Gem

2 : Gemfile

3 : Gemfile.lock

 

1 : Gem

 Gem とは、ライブラリの1つ。複雑な機能でもGemを導入することによって簡単に実装ができるようになるといったもの。

2 : Gemfile

 アプリケーションで用いる Gem の「名前」と「バージョン」を記載・管理するファイル。

3 : Gemfile.lock

 Gemfile を参照してインストールされたGemの「名前」と「バージョン」を記録してくれるファイル。

 

 

 ここで、Gem について補足説明があり、これがbundlerを理解する上でもっとも大切になることです。それは、

 

  Gem は単体では動かず、他のGemと組み合わさって初めて機能する

 

 ということ。

 加えて、Gem 同時が正常に機能するバージョンはそれぞれが異なっています。下の画像を見るとイメージがしやすいと思います。

 

bundler の説明画像

 

 Gem を正常に動かすため、必要なGem を1つずつ調べ、バージョンも揃えてインストールをする。この作業は不可能ではないにしろ、とても大変です。それに人力ですのでミスタイピングによる思わぬエラーも出てくるはず。

 そこで登場するのが、bundler です。

 bundler を経由してGem をインストールすることによって、必要なGem を、適応するバージョンでそれぞれインストール・アップデートしてくれます。しかもとても簡単です。

 

1、Gemfile を開き、使用したいGem の名前(バージョン指定があればバージョンも)を記入する。

2、ターミナルからbundle install(update) コマンドを実行するだけ。

 

 以上で、bunlder についての説明は終わりです。拙い説明でしたので、まだ少しイメージが掴めないという方がいらっしゃいましたら、下記のイメージ図をご覧ください。自分なりにではありますが、分かりやすくまとめさせていただきました。

 

 

 

 最後までご覧いただきありがとうございました。

 次回の更新は10月3日を予定しています。

MVCモデルの構造について

 基礎カリキュラムに登場したMVCモデルについて、疑問に思うところがあったため深掘りをしたことがありました。それについてアウトプットをしていきます。

 深掘りをした内容としては、

 ルーティングとコントローラーは、コントローラー名とアクション名をコードに書いたのに、なぜビューではディレクトリ名、ファイル名にそれぞれ記述されるのだろう、という部分。

 _____________________________________

 <例>

ルーティング get 'post',to: '(コントローラー名)#(アクション名)'

コントローラー class (コントローラー名)_controller < App...

                                  def (アクション名)

                               end

 

ビュー app/views/(コントローラー名)/(アクション名)

  ______________________________________

 

 カンニングペーパーとして配布された画像を見ていただいた方がイメージがしやすいかもしれませんが、とにかく、コントローラー名とアクション名がビューではディレクトリ、ファイル名として扱われることを疑問に思いました。

 

 自分は物覚えが悪いので、MVCで(コントローラー名とアクション名の)扱いを統一にして欲しかったです。最初は、扱い辛そうだと思っていましたが、よくよく考えてみると、

 app/views/(コントローラー名)/(アクション名)

 という形の方がユーザー(エンジニア)にとって都合がいいのでは? と思い直しました。

 

 今までは、1つのコントローラーに対して、1つのビューを扱ってイメージをしていましたが、実際は、

 

 A(コントローラー) >  B(アクション)

              C(アクション)

              D(アクション)

 

 B(コントローラー) >  E(アクション)

              F(アクション)

              G(アクション)

 

 というふうな形で扱われます。

 そして、それぞれのアクションによって返す見た目、すなわちビューが異なります。もしも、ビューが今のような構造でなければ、1つのファイルに複数個のアクション用の見た目を記述しないといけないことになります。

 _____________________________________

 <例>

 

ビュー app/views/見た目を決めるぞ

 〜コントローラーAのアクションBの見た目〜

 <html css>

<% ruby %>

<%= ruby %>

 

 〜コントローラーAのアクションCの見た目〜

 <html css>

<% ruby %>

<%= ruby %>

 

 〜コントローラーAのアクションCの見た目〜

 <html css>

<% ruby %>

<%= ruby %>

 

  ______________________________________

 

 個人的な意見ではありますが、とても分かり辛いです。ぱっと見、どのコードがどのアクションの見た目を作っているのかも判断できないと思います。

 それよりも、コントローラー名のディレクトリに格納されている、アクション名のフォルダの中に、それぞれの見た目を記述して行った方が遥かにわかりやすいですよね。

 

 こういった背景もあり(おそらく)、ビューの、コントローラー名とアクション名の扱い方は、ルーティングとコントローラーとは異なっているのでしょう。

 

 

 

 このような内容のブログを、これからもつらつらと書き連ねていきます。

 時間があれば読んでいただけると幸いです。