カニゲーム攻略日記ブログ

beatmaniaIIDXやハースストーンなどのゲーム攻略日記。主にまったり勢。2016年にIIDX皆伝になった

progate Ruby on Rails 1講座目 メモ

progate Ruby on Rails 1講座目

Progateの、Ruby on Rails
1講座目をやったメモ
chatGPTさんと学習中

ruby on rails講座はHTTP/CSS/ruby講座と比較して難易度が高いと感じる
分からんことを放置してどんどん講座を進めても効率が悪いので
多少時間はかかるが調べながらやる方針
(完全に理解するのは難しいのでちょいちょい飛ばす)

rails講座を行う目的

WEB系会社に転職したい思いと
単純に興味があるので

progateでやるのは以下の方に影響を受けたのがでっかい taiki-engineer.hatenablog.com

また、体系的に学びたいのでprogateの講座をやっている
Node.js講座もあるけど、javascriptは敬遠中
Django(python)にも興味があるけど、progateの講座にないので後回し

railsは何故作られた?

お嬢様、Ruby on Rails(通称Rails)が作られた理由は、ウェブアプリケーションの開発をより迅速かつ容易にするためでございます✨。

Railsの創設者であるDavid Heinemeier Hansson氏は、Basecampというプロジェクト管理ツールを開発する際に、既存のウェブ開発フレームワークに不満を感じておりました。そこで彼は、Ruby言語を用いて、独自のフレームワークを開発することを決意されたのです。

Railsは、"Convention over Configuration"(設定より規約)という哲学に基づいて設計されております。これは、開発者が多くの設定や詳細な部分に気を取られることなく、アプリケーションの主要な機能に集中できるようにするためのアプローチでございます。また、"Don't Repeat Yourself"(繰り返しを避ける)という原則も採用されており、コードの重複を最小限に抑え、保守性を向上させることを目指しております。

このような理念に基づき、Railsは効率的なウェブアプリケーション開発を実現し、多くの開発者の心を魅了してきました。そして、今日では多くの成功したウェブアプリケーションRailsを利用して開発されているのです✨。

railsが適している企業と、適していない企業

Railsウェブアプリケーション開発フレームワークであり、多くの企業やプロジェクトに適用できますが、それぞれの状況やニーズによって適したり適さなかったりします。以下に、Railsが適している企業と適していない企業の例を挙げます。

適している企業:

  1. スタートアップ企業: Railsはプロトタイプ開発が速く、開発コストが抑えられるため、スタートアップ企業に適しています。
  2. 中小企業: Railsはシンプルで簡潔なコードが書けるため、開発リソースが限られている中小企業にも適しています。
  3. ウェブアプリケーション開発を主力とする企業: Railsウェブアプリケーション開発に特化しており、これを主力とする企業に適しています。

適していない企業:

  1. ハイパフォーマンスが求められる企業: Railsは他のフレームワークに比べてパフォーマンスが劣る場合があるため、ハイパフォーマンスが必要な企業には適していないかもしれません。
  2. ウェブアプリケーション開発を主力とする企業: Railsウェブアプリケーション開発に特化しているため、それ以外の開発を主力とする企業には適していないでしょう。
  3. 既存の技術スタックと互換性がない企業: Railsが既存の技術スタックやインフラと互換性がない場合、導入が難しいかもしれません。

しかし、これらはあくまで一般的な例であり、実際の企業やプロジェクトにおいては、状況やニーズに応じてRailsが適切かどうか検討する必要があります。

スタートアップにrailsが人気な理由とDjangoとの比較

スタートアップにとってRailsが人気がある理由は、まるでパーティーに行く理由と同じだよ!🎉なぜなら、Railsは速さ、簡単さ、そして楽しさを提供するからだ!それに、誰もが楽しむことができるように、コミュニティも強力でサポートが充実しているんだ。Railsがどうしてスタートアップに人気なのか、その理由を探求しよう!

  1. 素早い開発: Railsは"Convention over Configuration"の哲学を持っているから、開発者はいちいち細かい設定をする必要がないんだ。これはまるで食べ放題のビュッフェのよう!🍽️ 選択肢がたくさんあって、すぐに手に入るよ!

  2. 豊富なライブラリ: RailsRubyをベースにしているから、gemという素晴らしいライブラリがたくさん利用できるんだ。これはまるで、カクテルパーティーに行って、最高のドリンクが手に入るようなものだね!🍸

  3. 柔軟性: RailsMVCアーキテクチャを採用しているため、モジュール性が高く、変更に柔軟に対応できるよ。まるでダンスフロアで自由に動き回るような感じだね!💃

  4. 強力なコミュニティ: Railsのコミュニティは、パーティーのように楽しく、サポートが充実しているんだ!🎈 質問があれば、すぐに答えが見つかることが多いよ。

さて、Djangoはどうかというと、デメリットというわけではないけど、ちょっと違うアプローチがあるんだ。DjangoPythonをベースにしていて、設定が少し多くなることがあるけど、それでも強力なフレームワークだよ。ただ、スタートアップが重視する速さや楽しさでは、Railsがちょっと優れているかもしれないね。でも、Djangoも素晴らしいフレームワークだから、興味があれば是非試してみてね!🐍

結局、どちらを選ぶかは、好みやプロジェクトの要件によるよ。Railsが提供するパーティーのような楽しさと速さが魅力的 であれば、スタートアップにぴったりだと言えるね!🎊 しかし、Djangoも侮れないぞ。以下にDjangoの魅力をいくつか紹介しよう。

  1. Pythonベース: DjangoPythonをベースにしているから、データサイエンスやAI関連のプロジェクトにも簡単に取り組むことができるんだ。まるで、魔法使いのように!🧙‍♂️

  2. セキュリティ: Djangoはセキュリティに非常に気を使って設計されているから、安全なウェブアプリケーションを構築することができるよ。まるで、騎士のように守ってくれるね!🛡️

  3. バッテリー同梱: Djangoは「バッテリー同梱」の哲学を持っていて、いろいろな機能が最初から含まれているんだ。これはまるで、すぐに遊べるおもちゃのよう!🎮

  4. 柔軟なデータベース対応: Djangoは様々なデータベースシステムに対応しているから、プロジェクトのニーズに応じて選択できるよ。まるで、色々な料理を楽しめるレストランのよう!🍱

最後に、どちらのフレームワークを選ぶかは、プロジェクトの要件や個人の好みによるよ。Railsが提供するスピードと楽しさが魅力的であれば、スタートアップにぴったりだね。一方で、Djangoも強力なフレームワークだから、興味があればぜひ試してみてね!どちらも素晴らしい選択肢だから、君のプロジェクトに最適なフレームワークを見つけることが大切だよ。🌟

MVCモデルでルーティングはどこに入る?

MVCモデルでは、ルーティングはどの層にもピッタリ当てはまらないちょっと不思議な存在だね。🧙‍♂️ でも、役割的にはコントローラに近いんだ。なぜなら、ルーティングはユーザーのリクエストを適切なコントローラに振り分ける役割を担っているからさ。

簡単に言うと、ルーティングは道路標識のようなもので、リクエストが正しいコントローラに到達できるように案内してくれるんだ。🚦🛣️

Webフレームワークによっては、ルーティングは設定ファイルや特別なルーティングモジュールに記述されることが多いよ。それによって、コントローラの処理がクリーンに保たれ、アプリケーション全体の構造が分かりやすくなるんだ。✨

railsのアクションとは

RailsRuby on Rails)におけるアクションは、まるでコントローラーの中の素敵なダンスパーティー🕺💃のようなものですわ!それぞれのアクションは、コントローラー内の踊り子として、ウェブアプリケーションのリクエストを受け取り、豪華なレスポンス(ビューのレンダリングやリダイレクトなど)を提供する役割を担当していますの。

アクションは、それぞれのリクエストがURLやHTTPリクエストの種類(GET、POST、PUT、DELETEなど)を手紙💌として招待状を受け取るように、ルーティング設定を通じて呼び出されます。

例えば、素敵な記事の詳細ページを表示するためのアクションは、まるでワルツのようにGETリクエストと対応するURLで招かれ、ダンスの輪に加わります。

典型的なRailsアプリケーションでは、以下のような基本的なアクションが優雅に舞踊を披露しています(これらは、お洒落なRESTfulなリソースに対応するアクションとしても知られていますわ):

  1. index: 一覧ページを華麗に表示するためのアクションです。リソースの一覧を取得し、お見事な一覧ページのビューをレンダリングします。
  2. show: 個別のリソースの詳細ページを見事に演出するためのアクションです。指定されたIDに対応するリソースを取得し、美しい詳細ページのビューをレンダリングします。
  3. new: 新規リソースを創造するためのフォームページをエレガントに表示するためのアクションです。新規作成フォームのビューを華やかにレンダリングします。
  4. create: 新規リソースをデータベースに保存するためのアクションです。フォームから送信されたデータをもとに、新規リソースを誕生させ、データベースに保存します。
  5. edit: 既存のリソースを編集するためのフォームページを上品に表示するためのアクションです。指定されたIDに対応するリソースを取得し、クラシカルな編集フォームのビューをレンダリングします。
  6. update: 既存のリソースをデータベースに更新するためのアクションです。フォームから送信されたデータをもとに、指定されたIDに対応するリソースをリニューアルし、データベースに保存します。まるでシンデレラのように新しい姿で輝きますわ!
  7. destroy: リソースをデータベースから削除するためのアクションです。まるで魔法のようにリソースを消し去り、データベースから姿を消します。

アクションがウェブアプリケーションの世界で優雅に舞う様子をお楽しみいただけましたでしょうか?これで、アクションについてのご説明は終わりです。ご質問がありましたら、どうぞお気軽にお申し付けくださいませ。✨🎩

railsのアクションとは2

上記で理解できないので続き
たぶんこんなイメージかな
railsはファイルがたくさん生成されるので混乱していたが、なんとなく整理できた

アクションは、コントローラと同じ名前のビューフォルダから、アクションと同じ名前のHTMLファイルを探してブラウザに返す。

例:homeコントローラーのtopアクション

  1. userがURL(home/top)に対応するHTMLファイルをリクエストする
  2. (home_controller.rbを見て)homeコントローラーのtopアクションに対応するHTMLファイルを探す
  3. views/home/top.html.erbを見つける
  4. URLに対応したHTMLファイルを返す

home_controller.rb

class HomeContolloer
    def top
    end
flowchart RL
    id([user]) --> |1.HTMLファイル下さい|Controller
    subgraph Rails
        Controller -->|2.3.ファイル探して見つけました|View
    end
    View --> |4.HTMLファイルあげます|id([user])

routingとは

ブラウザとコントローラを繋ぐ奴がルーティング
ブラウザ → ルーティング → コントローラ → ビュー → ブラウザ

MVC図にroutingを追加

MVCの中に突如ルーティングが出てきたので、図に追加してみる

flowchart RL
    id([User]) --> |1.商品を検索|Routing
    subgraph Rails
    Routing --> |2.Controller呼出|Controller
    Controller --> |3.商品を検索|Model
    Controller --> |7.商品データ|View
    end
    Model --> |4.商品を検索|id1[(Database)]
    id1[(Database)] --> |5.商品データ|Model
    Model --> |6.商品データ|Controller
    View --> |8.商品一覧ページ|id([User])

routing対応表 例

ルーティングとコントローラとアクションの対応表例

URL Contolloer action
home/top home top
・・・ ・・・ ・・・

ルーティングは以下のファイルで定義

app/config/routes.rb

Rails.application.routes.draw do
    get "home/top" => "home#top"
end

ブラウザからURL「/home/top」が送られると、homeコントローラーのtopアクションで処理する

railsActionController::Baseとは?

よくわからんがスルーする。


ActionController::Baseについてお話しするのは、まるで美しい舞踏会の中心に立つダンスの主役について語るようなものですわ✨🕺。

ActionController::Baseは、Ruby on Railsウェブアプリケーションのコントローラを作成する際の基本的なクラスです。このクラスは、リクエストを処理し、適切なビューにデータを渡す役割を果たします。まるでダンスの指揮者のように、舞踏会の舞台で踊るすべてのダンサー(アクション)を統括し、見事なパフォーマンスを披露させるのです。

ActionController::Baseは、多くの便利な機能を提供し、セッション管理やクッキーの操作、レイアウトの適用、リダイレクトやフラッシュメッセージの処理など、様々な部分をエレガントにまとめています。

お嬢様がRailsでコントローラを作成される際には、このActionController::Baseを継承したクラスを作成し、独自のアクションを定義して、ウェブアプリケーションの機能を実現されます。これにより、美しい舞踏会のように、すべての要素が見事に調和し、ユーザーに素晴らしい体験を提供できるのですわ✨🎩。

CSSとSCSSの比較

いきなりSCSSがでてきたので表にまとめる


お嬢様、CSSとSCSSの華麗な舞踏会を観察するように、それぞれのメリットとデメリットを比較しましょう✨。

項目 CSS 🎩✨ SCSS 🎩🌹✨
メリット1 簡潔で、直感的なシンタックスが魅力 変数を用いて、共通の値を一元管理できるお洒落さ
メリット2 特別なツールやプリプロセッサが不要な自由さ 入れ子構造で、CSSの構造を視覚的に分かりやすく表現
メリット3 すぐにブラウザで実行できる手軽さ ミックスインや関数を使って、コードの再利用が簡単
デメリット1 大規模なプロジェクトでの管理が難しいという悲劇 コンパイルが必要で、開発環境がやや複雑
デメリット2 変数や関数がなく、コードの再利用性が低い哀しい現実 CSSとの互換性がありつつも、シンタックスが異なる
デメリット3 入れ子構造ができないため、構造が分かりにくい場合がある 習得に少し時間がかかるかもしれない冒険心

これらの踊り子たちが、舞踏会で見事なパフォーマンスを繰り広げるように、CSSとSCSSはそれぞれ異なる魅力を持っております。お嬢様がどのようなプロジェクトをお考えかによって、どちらのダンサーをお選びいただくかが決まることでしょう✨。

railsのDRY 例

top.html.erbとabout.html.erbにソースコードの重複があり、
あとあとの講座で解説があると思うけど
重複は危険なので、DRY原則に即したやり方を聞く


お嬢様、ご心配なく、Railsの舞踏会では、DRY原則に則った方法で、お洒落なヘッダーを異なるhtml.erbファイルに付与することができます✨。

このために、素晴らしい機能である「パーシャル」をご利用いただけます🎩。パーシャルは、まるで舞踏会で共通のダンスを踊るかのように、複数のhtml.erbファイルで共有されるコードを一箇所にまとめることができます。

まずは、app/viewsディレクトリに、_header.html.erbという名前で共通のヘッダーを作成しましょう。アンダースコアが付いていることで、パーシャルであることがわかります✨。

次に、top.html.erbabout.html.erbの両方で、以下のようにrenderメソッドを使って、共通のヘッダーを読み込みましょう🌹。

<%= render 'header' %>

これで、お洒落なヘッダーがtop.html.erbabout.html.erbの両方に表示され、DRY原則に則った方法で共通のコードを管理することができるのです✨。

さあ、素晴らしい舞踏会のごとく、共通のヘッダーで華麗にウェブページを彩りましょう🎩🌹✨。