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

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

progate Ruby on Rails 4講座目

progate Ruby on Rails 4講座目

Progateの、Ruby on Rails
4講座目をやったメモ
気になったことをメモしたのでprogateと関係ないこともある
chatGPTさんと学習中

余談

運動不足解消のために自宅でDDRをする
DDRをやってみると気づくことがあった
踏めないところはまだ理解できてないところなんだなー

rails講座は混乱してきた
理解できてないことがちょいちょいある

chatGPTさんに聞くだけでなく
理解を助けるために
自分でもっと図を作ってみよう

progateの道場レッスンがめんどい

おやおや、道場レッスンがお疲れのようですね。✨

実は、Progateの道場レッスンは、確かに少々面倒に感じることがありますが、それはスキルの練習と理解を深めるためなのですわ。🌟

道場レッスンをこなすことで、実践的なスキルが身につき、自信を持ってプログラミングの世界を冒険することができるのです。💫

ですから、お時間が許す限り、道場レッスンにもぜひチャレンジしてみてくださいませ。✨ それが、あなたのプログラミングの魔法力を高める秘訣となりますわ!🎩✨

道場レッスンをするか、次のレッスンを進めるか迷い中

おっと、お悩みのようですね。✨ 気持ちを整えて、効率的な学習方法についてお話ししましょう。🌟

実は、道場レッスンと次のレッスンの進め方は、あなたの学習スタイルや目的によって変わりますの。✨

道場レッスンは、すでに学んだ内容を復習し、スキルを磨くために最適ですわ。練習を重ねることで、より自信を持ってプログラミングができるようになるのです。💫

一方で、次のレッスンを進めることは、新しい知識やスキルを獲得することができます。これにより、プログラミングの幅が広がりますわ。🌈

効率的な学習方法としては、道場レッスンと次のレッスンをバランスよく進めることがおすすめです。✨ 例えば、新しいレッスンを進めた後、道場で練習を行うといった具合に、練習と新しい知識の獲得を交互に行うのです。🌟

どちらも大切な要素ですので、お時間と目的に合わせて、効率的な学習方法を選択してくださいませ。✨ それが、あなたの魔法力を最大限に引き出す方法ですわ!🎩✨

道場レッスンは飛ばして4講座目をやる

道場レッスンは後でいいかな
気が進まないので、気が向いた時に

道場レッスン1完了

4講座目を完了後、1時間ちょいで完了した
思ってたより簡単だった
ルーティング→コントローラー(アクション)→ビュー
の流れが分かれば割とスムーズだった

コンソールでデータベースの編集

  1. データベースから取得
  2. 上書き
  3. データベースに保存

post = Post.find_by(id:1)
post.content = "ooiotya"
post.save

post.saveした際にupdated_atが更新される仕組み?

おや、Railsの魔法の仕組みに興味があるのですね✨。それでは、魔法使いとして、post.saveが呼ばれたときのupdated_atの更新についてお話しましょう🌟。

Railsの魔法の世界では、Active Recordという強力な呪文がありますわ。このActive Recordが、データベースとのやり取りを円滑に行い、データを自動的に更新する役割を果たしているのです✨。

post.saveが呼ばれると、Active Recordの魔法使いたちは、そのデータが新しく作成されるのか、既存のものが更新されるのかを判断します。そして、データが更新される場合、updated_atの値を現在の時刻に変更する魔法をかけるのです🎩✨。

このように、RailsのActive Recordの魔法のおかげで、わたくしたちがpost.saveを呼ぶだけで、updated_atが自動的に更新される仕組みが実現されているのですわ🌈。魔法の世界は素晴らしいですね✨。

Active Recordの仕組みは?

さあ、魔法使いとして、Active Recordの魔法の仕組みについてお話しましょう✨。

Active Recordは、Ruby on Railsの魔法の世界において、データベースとのやりとりを簡単に行えるようにする呪文の一つなのですわ🎩✨。Active Recordは、「ORM」(Object-Relational Mapping)という魔法の技術を使用して、データベースのテーブルとRubyのオブジェクトを結びつけています🌟。

この魔法によって、データベースの操作がRubyのオブジェクト操作のように簡単になりますわ。クエリの呪文を書く代わりに、Rubyのメソッドを使ってデータベースの検索や更新ができるのです✨。例えば、Post.find(1)という呪文で、データベースからIDが1のPostデータを取得できます。

また、Active Recordはデータベースのマイグレーションという魔法も提供しています。これにより、データベースの構造を変更する際に、Rubyの呪文で記述し、バージョン管理も行えるようになります。

さらに、Active Recordは、データのバリデーションや関連付け、コールバックといった機能を提供しており、データ操作に関する多くの魔法を手に入れることができますわ🌈。

このように、Active Recordの魔法のおかげで、Railsの魔法使いたちは、データベースとのやりとりを簡単に行い、素早く魔法のアプリケーションを開発することができるのです✨。魔法の世界はとても興味深いですね🌟。

具体例

さあ、魔法使いが、Active Recordの魔法を簡単な表と図でご紹介しますね✨。

まずは、データベースにあるブログ記事を管理するテーブル「posts」があると仮定しましょう。このテーブルには、以下のカラムが存在します。

  • id
  • title
  • content
  • created_at
  • updated_at

そして、このテーブルに対応するActive Recordモデル「Post」があります。このモデルを使って、データベースとのやりとりが簡単になるのです。

例えば、以下のような操作ができます。

操作内容 Active Recordの呪文
全ての記事を取得 all_posts = Post.all
IDが1の記事を取得 post = Post.find(1)
新しい記事を作成 new_post = Post.new(title: 'My Title', content: 'My Content')
作成した記事を保存 new_post.save
記事のタイトルを更新 post.update(title: 'Updated Title')

Postクラスのおさらい

混乱してきたのでおさらい

魔法使いが、Postクラスについてお話ししますね✨。

Postクラスは、Railsアプリケーションにおいて、ブログ記事に関するデータや操作を管理するためのクラスです。このクラスは、Active Recordを継承しており、データベースのテーブルと連携して機能します。

例えば、データベースのpostsテーブルにあるブログ記事を取得したり、新しい記事を作成・保存したり、既存の記事を更新・削除したりすることができます。

以下のようなコードでPostクラスを定義します。

class Post < ApplicationRecord
end

この素晴らしいPostクラスのおかげで、Railsアプリケーションでブログ記事に関するデータ操作が、まるで魔法のように簡単に行えるのです✨。

Postクラスのおさらい2

魔法使いが、Postクラスを使う理由を表でお伝えします✨。

項目 Postクラスを使う理由 post (変数)を使う理由
機能 Active Recordを継承し、データベース操作が容易 通常の変数であり、データベースとの連携がない
可読性・保守性 クラス名から役割が明確で、コードが理解しやすい 役割が不明瞭で、コードが読みづらくなる可能性がある
柔軟性 データベースと連携し、データ操作が一貫して行える データ操作が制限される

Postクラスは、Railsアプリケーションでデータベースのpostsテーブルと連携するために使用されます。Postクラスを使うことで、データベースの操作が容易になり、コードの可読性や保守性、柔軟性が向上します✨。

一方、postという変数は、通常の変数であり、データベースとの連携がありません。そのため、データ操作が制限され、コードの可読性や保守性が低くなる可能性があります。

ですので、データベースの取得には、Postクラスを使うことが望ましいのです✨。

コンソールでデータベースから削除

  1. データベースから取得
  2. 削除(destroy)

post = Post.find_by(id:1)
post.destroy

railsでデータベースの編集

手順

  1. ルーティング

    URL「posts/なんでもいい/edit」がきたら、Postコントローラーのeditアクションへ

         get "posts/:id/edit" => "posts#edit"
    
  2. アクション

    ルーティングの「:id」はparams[:id]で取得
    データベースのpostの中身を編集したいので
    「:id」に対応したpostを取得

         def edit
             @post = Post.find_by(id: params[:id])
         end
    
  3. ビュー

    とりあえず表示するかテスト

         <%= "I am edit id.#{@post.id}" %>
    
  4. 編集へのリンクを追加

    直接URL指定してもいいけど
    不便なのでリンクを追加

         <%= link_to("編集", "/posts/#{@post.id}/edit")>
    

postと@post

混乱してきたので表でまとめる
ビューでアクセスできるところが嬉しいのだな

魔法使いが、post@postの違いを表でお伝えします✨。

項目 post @post
種類 ローカル変数 インスタンス変数
スコープ メソッド内のみ有効 クラス内で共有される
ビューへのアクセス アクセスできない アクセス可能

postは、通常のローカル変数です。メソッド内でのみ有効で、メソッドの実行が終わるとその値は破棄されます。ビューで使うことはできません。

一方、@postインスタンス変数です。クラス内で共有され、コントローラーからビューへ値を渡す際に使用されます。インスタンス変数は、@記号で始まり、ビューでもその値を参照できます✨。

それぞれの使い分けに注意して、コードを書くことで、混乱を避けることができます🌟。

入力フォーム作成

元々の投稿内容を初期値にする

URLのidがコンテンツ名に変換される流れ

  1. ルーティング

         get "posts/:id/edit" => "posts#edit"
    
  2. アクション

         def edit
             @post = Post.find_by(id: params[:id])
         end
    
  3. ビュー

     <textarea><%= @post.content %></textarea>
    

編集内容を保存する準備

  1. ルーティング

    更新はupdateアクション
    postにする(郵便配達の様に受け取る)

         post "posts/:id/update" => "posts#update"
    
  2. アクション

    更新したら投稿一覧に移動したいのでリダイレクト

         def update
             redirect_to("/posts/index")
         end
    
  3. 送信先をupdateにする

    updateアクションに送信させる

     <%= form_tag("/posts/#{@post.id}/update") do %>
    
     <% end %>
    

上書きする

  1. アクション

    URLのidがになる

         def update
             @post = Post.find_by(id: params[:id])
         end
    
  2. ビュー

    入力内容が変数paramsに代入されてupdateアクションに送信

         <textarea name="content">...</textarea>
    
  3. アクション

    paramsで上書き

         def update
             @post = Post.find_by(id: params[:id])
             @post.content = params[:content]
             @post.save
    

textarea name="content"をすると何故、変数paramsに入力内容が保存される?

textareaタグにname属性を指定すると、フォームが送信される際に、その属性値がキーとしてparamsハッシュに追加され、入力内容がそのキーに対応する値として保存されるのです🌟。これにより、コントローラでparamsを使って簡単に入力内容を取得できますわ💖。

フローチャートにしてみる

たぶんこんな感じ

flowchart TB
  V["View(入力して送信)"] --> |"入力内容がtextareadのname属性=contentに入ってる"| R["Rails(name属性contentをparams[:content]に変換)"]
  R --> |"params[:content]"| C["Controller(params[:content]を使える)"]

destroy

getとpost

  • get : データベースを変更しない
  • post: データベースを変更する

post用のリンク

{method: "post"}がないとget用のリンクに行っちゃう

<%= link_to("削除", "/posts/#{@post.id}/destroy", {method: "post"}) %>