LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@kiyomasa05(きよま)

Railsチュートリアル7章まとめ

Posted at

この章でやること

  • ユーザー登録機能を実装する
  • HTMLフォームからアプリへ情報を送信すること
  • その情報をデータベースへ登録する
  • 登録されたユーザーのプロフィールを作成するページを作る
  • ここから少し難易度が上がる

7.1 ユーザーを表示する

まずユーザーの名前とプロフィール写真を表示するためのページを作成する

バージョン管理を使っている場合は、いつもと同じようにトピックブランチを作成。

$ git checkout -b sign-up

7.1.1 デバッグとRails環境
サイトのレイアウトにデバッグ情報を追加する
これにより、ビルトインのdebugメソッドとparams変数を使って、各プロフィールページにデバッグ用の情報が表示されるようになる

app/views/layouts/application.html.erb
<!DOCTYPE html>
<html>
  .
  .
  .
  <body>
    <%= render 'layouts/header' %>
    <div class="container">
      <%= yield %>
      <%= render 'layouts/footer' %>
      <%= debug(params) if Rails.env.development? %> 
    </div>
  </body>
</html>

if Rails.env.development?

こうしておくと、デバッグ情報は開発環境（development）だけで表示されるようになる

Railsの３つの環境

Railsには

  • テスト環境(test)
  • 開発環境(development)
  • 本番環境(production)
    の３つの環境がデフォルトで装備されている。

例えば、Rails Consoleのデフォルト環境はdevelopmentである。

$ rails c
irb(main):001:0> Rails.env
=> "development"
irb(main):002:0> Rails.env.development?
=> true
irb(main):003:0> Rails.env.test?
=> false

RailsにはRailsオブジェクトがあり、それには環境の論理値(boolean)を取るenvという属性がある。

それに、それぞれの環境を渡してクエスチョンで確かめる。
test?ではテスト環境ではtrueを返し、それ以外の環境ではfalseを返す。

テストの環境のデバッグなど、他の環境でconsoleを実行する場合、環境をパラメータとしてconsoleスクリプトに渡すことができる。

$ rails console test
Running via Spring preloader in process 18352
Loading test environment (Rails 5.1.6)
>> Rails.env
=> "test"
>> Rails.env.test?
=> true

Railsサーバーでもデフォルトではdevelopmentが使われるが、他の環境を明示的に実行することもできる。

$ rails s --environment production

なお、アプリケーションを本番環境で実行するには本番環境用のDBが利用できないと実行できないので

$ rails db:migrate RAILS_ENV=production

このように本番データベースを作成する。

ここで、Heroku上での環境を確認してみる。

$ heroku run rails console
irb(main):001:0> Rails.env
=> "production"
irb(main):002:0> Rails.env.production?
=> true

このように、Herokuで実行されるアプリケーションは本番環境であることが分かる。

話を元に戻し、デバッグを整形するスタイルシートを追加

app/assets/stylesheets/custom.scss
@import "bootstrap-sprockets";
@import "bootstrap";

/* mixins, variables, etc. */

$gray-medium-light: #eaeaea;

@mixin box_sizing {  #ミックスイン
  -moz-box-sizing:    border-box;
  -webkit-box-sizing: border-box;
  box-sizing:         border-box;
}
.
.
.
/* miscellaneous */

.debug_dump {
  clear: both;
  float: left;
  width: 100%;
  margin-top: 45px;
  @include box_sizing;
}

Sassのミックスイン機能（ここではbox_sizing）を使っています。

ミックスイン機能は
@名前　{}でCSSを定義して
@include 名前　で呼び出すことができる便利なものです

実際にデバック情報をビューでみてみると、

--- !ruby/object:ActionController::Parameters
parameters: !ruby/hash:ActiveSupport::HashWithIndifferentAccess
  controller: static_pages
  action: home
permitted: false

と表示される
これはparamsに含まれている内容で、YAML5 という形式で書かれてる。
YAMLは基本的にハッシュであり、コントローラとページのアクションを一意に指定

演習

ブラウザから /about にアクセスし、デバッグ情報が表示されていることを確認してください。このページを表示するとき、どのコントローラとアクションが使われていたでしょうか?paramsの内容から確認してみましょう。
→動作確認
Railsコンソールを開き、データベースから最初のユーザー情報を取得し、変数userに格納してください。その後、puts user.attributes.to_yamlを実行すると何が表示されますか? ここで表示された結果と、yメソッドを使ったy user.attributesの実行結果を比較してみましょう。

puts user.attributes.to_yamlの場合

irb(main):001:0> user=User.first
   (0.1ms)  begin transaction
  User Load (0.8ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ?  [["LIMIT", 1]]
irb(main):002:0> puts user.attributes.to_yaml
---
id: 1
name: Michael Hartl
email: michael@example.com
created_at: !ruby/object:ActiveSupport::TimeWithZone
  utc: &1 2021-02-15 07:32:22.153822000 Z
  zone: &2 !ruby/object:ActiveSupport::TimeZone
    name: Etc/UTC
  time: *1
updated_at: !ruby/object:ActiveSupport::TimeWithZone
  utc: &3 2021-02-15 07:32:22.153822000 Z
  zone: *2
  time: *3
password_digest: "$2a$12$GLOLyYhACS0bU5g25TM9mekWxxEXxmSWumiz03O4tOhy2P4ib5l8K"
=> nil

y user.attributesの場合

irb(main):003:0> y user.attributes
---
id: 1
name: Michael Hartl
email: michael@example.com
created_at: !ruby/object:ActiveSupport::TimeWithZone
  utc: &1 2021-02-15 07:32:22.153822000 Z
  zone: &2 !ruby/object:ActiveSupport::TimeZone
    name: Etc/UTC
  time: *1
updated_at: !ruby/object:ActiveSupport::TimeWithZone
  utc: &3 2021-02-15 07:32:22.153822000 Z
  zone: *2
  time: *3
password_digest: "$2a$12$GLOLyYhACS0bU5g25TM9mekWxxEXxmSWumiz03O4tOhy2P4ib5l8K"
=> nil

同じ結果が返ってきました

7.1.2 Usersリソース

6章で1人のユーザーをDBへ登録していたので、その情報をビューに表示する

RESTアーキテクチャの習慣に従い、データの作成、表示、更新、削除をリソース（Resources）として扱い、これらの基本操作を各アクションに割り当てていく

リソースへの参照はリソース名とユニークなIDを使うのが普通
ユーザーをリソースとみなす場合、id=1のユーザーを参照する＝/users/1というURLに対してGETリクエストを発行するということを意味する。（RailsのREST機能が有効になっていると、GETリクエストは自動的にshowアクションとして扱われます。）

/users/1 のURLを有効にするために、routesファイル（config/routes.rb）にresources :users
を追加する

config/routes.rb
Rails.application.routes.draw do
  root 'static_pages#home'
  get  '/help',    to: 'static_pages#help'
  get  '/about',   to: 'static_pages#about'
  get  '/contact', to: 'static_pages#contact'
  get  '/signup',  to: 'users#new'
  resources :users
end

resouresメソッドは以下表の通り名前付きルートとRESTfulなUsersリソースで必要となるすべてのアクションが利用できるようになる

HTTPリクエスト URL アクション 名前付きルート 用途
GET /users index users_path すべてのユーザーを一覧するページ
GET /users/1 show user_path(user) 特定のユーザーを表示するページ
GET /users/new new new_user_path ユーザーを新規作成するページ（ユーザー登録）
POST /users create users_path ユーザーを作成するアクション
GET /users/1/edit edit edit_user_path(user) id=1のユーザーを編集するページ
PATCH /users/1 update user_path(user) ユーザーを更新するアクション
DELETE /users/1 destroy user_path(user) ユーザーを削除するアクション

ルーティングが有効になったが、ルーティング先のページがないので後ほど追加する

app/views/users/show.html.erbファイルを手動で作成し、埋め込みRubyを使ってユーザー名とメールアドレスを表示する

touch app/views/users/show.html.erb
app/views/users/show.html.erb
<%= @user.name %>, <%= @user.email %>

ユーザー表示ビューが正常に動作するため,Usersコントローラ内のshowアクションに対応する@user変数を定義する

app/controllers/users_controller.rb
class UsersController < ApplicationController

  def show
    @user = User.find(params[:id]) #params[:id]はurlの1の部分
  end

  def new
  end
end

paramsについて
Usersコントローラにリクエストが正常に送信されると、params[:id]の部分はユーザーidの1に置き換わる。このid: '1'は /users/:id から取得した値

つまり、findメソッドのUser.find(1)と同じになる
※params[:id]は文字列型の"1"ですが、findメソッドでは自動的に整数型の1となる

/users/1 にアクセスし、デバッグ情報からparams[:id]の値を確認

action: show
controller: users
id: '1'

演習
埋め込みRubyを使って、マジックカラム（created_atとupdated_at）の値をshowページに表示してみましょう
埋め込みRubyを使って、Time.nowの結果をshowページに表示してみましょう。ページを更新すると、その結果はどう変わっていますか? 確認してみてください

ビューファイルに記述

app/views/users/show.html.erb
<%= @user.name %>, <%= @user.email %>
<p><%=@user.created_at%>,<%=@user.updated_at%></p>

<p><%=Time.now%></p>

pタグで挟んだのは改行して見やすくするため
ビューに@userを登録した時間と、updateした時間が表示される
Time.nowは今時点の日にちが表示される（ブラウザを更新すると変わる）

7.1.3 debuggerメソッド

debugメソッドは便利だが、もっと直接的にデバッグする方法もある。
それがdebuggerメソッド

これはbyebug gemによるメソッドで、
コンソールに差し込んで使うことができる

app/controllers/users_controller.rb
class UsersController < ApplicationController

  def show
    @user = User.find(params[:id])
    debugger
  end

  def new
  end
end

debuggerメソッドを差し込んだら、ブラウザから /users/1 にアクセスし、Railsサーバーを立ち上げたターミナルを確認

[1, 8] in /Users/kiyomasa/environment/sample_app/app/controllers/users_controller.rb
   1: class UsersController < ApplicationController
   2:   def show
   3:     @user = User.find(params[:id])
   4:     debugger
=> 5:   end
   6:   def new
   7:   end
   8: end
(byebug)

このプロンプトではRailsコンソールのようにコマンドを呼び出すことができて、アプリケーションのdebuggerが呼び出された瞬間の状態を確認できる

(byebug) @user.name
"Michael Hartl"
(byebug) @user.email
"michael@example.com"
(byebug) params[:id]
"1"

Ctrl-Dを押すとプロンプトから抜け出すことができる

debuggerをUsersコントローラーから取り外す

app/controllers/users_controller.rb
class UsersController < ApplicationController

  def show
    @user = User.find(params[:id])
  end

  def new
  end
end

今後Railsアプリケーションの中でよく分からない挙動があったら、debuggerを差し込んで調べてみる。
トラブルが起こっていそうなコードの近くに差し込むのコツ

演習

1.showアクションの中にdebuggerを差し込み（リスト 7.6）、ブラウザから /users/1 にアクセスしてみましょう。その後コンソールに移り、putsメソッドを使ってparamsハッシュの中身をYAML形式で表示してみましょう。

(byebug) puts params[:id].to_yaml
--- '1'
nil
(byebug)

2.newアクションの中にdebuggerを差し込み、/users/new にアクセスしてみましょう。@userの内容はどのようになっているでしょうか? 確認してみてください。

   1: class UsersController < ApplicationController
   2:   def show
   3:     @user = User.find(params[:id])
   4:   end
   5:   def new
   6:     debugger
=> 7:   end
   8: end
(byebug) @user
nil

7.1.4 Gravatar画像とサイドバー

Gravatar（Globally Recognized AVATAR）をプロフィールに導入
Gravatarは無料のサービスで、プロフィール写真をアップロードして、指定したメールアドレスと関連付ける

app/views/users/show.html.erb
<% provide(:title, @user.name) %>
<h1>
  <%= gravatar_for @user %> #これだけでユーザ画像が表示される
  <%= @user.name %>
</h1>

このユーザー表示用のビューでは、gravatar_forというヘルパーメソッドを定義している。
@userにはコントローラで定義したように、DBから取り出したユーザー情報が格納されている。

デフォルトでは、ヘルパーファイルで定義されているメソッドは自動的に全てのビューで利用できる。

ここでは、利便性を考えgravatar_forをUsersコントローラに関連付けられているヘルパーファイルに置くことにする。

GravatarのURLはユーザーのメールアドレスをMD5でハッシュ化している。
Rubyでは、Digestライブラリのhexdigestメソッドを使うとMD5のハッシュ化が実現できる。

>> email = "MHARTL@example.COM"
>> Digest::MD5::hexdigest(email.downcase)
=> "1fda4469bcbec3badf5418269ffc5968"

gravatar_forヘルパーメソッドを定義する

app/helpers/users_helper.rb
module UsersHelper

  # 引数で与えられたユーザーのGravatar画像を返す
  def gravatar_for(user)
    gravatar_id = Digest::MD5::hexdigest(user.email.downcase)
    gravatar_url = "https://secure.gravatar.com/avatar/#{gravatar_id}"
    image_tag(gravatar_url, alt: user.name, class: "gravatar")
  end
end

アプリケーションでGravatarを利用できるようにするために、まずはupdate_attributesを使ってデータベース上のユーザー情報（メールアドレス）を更新

$ rails console
>> user = User.first
>> user.update(name: "Example User",
?>                        email: "example@railstutorial.org",
?>                        password: "foobar",
?>                        password_confirmation: "foobar")
=> true

メアドをexample@railstutorial.orgは既にGravatarでロゴを紐付けしてあるので、更新するとRailsの画像になる

HTMLにサイドバーを追加する
rowクラスとcol-md-4クラスはBootstrapの一部
※親のクラスがrowだと、子クラスでcolが使える。colは全体を12に割った範囲で例えばcol-12なら全体、col-6なら半分の範囲という事になる。col-md-4は画面のwidthがmd（モバイルなど）だと4つのブロックの大きさをとるよという意味になる

app/views/users/show.html.erb
<% provide(:title, @user.name) %>
<div class="row">
  <aside class="col-md-4">
    <section class="user_info">
      <h1>
        <%= gravatar_for @user %>
        <%= @user.name %>
      </h1>
    </section>
  </aside>
</div>

SCSSを使ってサイドバーなどのユーザー表示ページにスタイルを与える

app/assets/stylesheets/custom.scss
.
.
.
/* sidebar */

aside {
  section.user_info {
    margin-top: 20px;
  }
  section {
    padding: 10px 0;
    margin-top: 20px;
    &:first-child {
      border: 0;
      padding-top: 0;
    }
    span {
      display: block;
      margin-bottom: 3px;
      line-height: 1;
    }
    h1 {
      font-size: 1.4em;
      text-align: left;
      letter-spacing: -1px;
      margin-bottom: 3px;
      margin-top: 0px;
    }
  }
}
.gravatar {
  float: left;
  margin-right: 10px;
}
.gravatar_edit {
  margin-top: 15px;
}

演習

（任意）Gravatar上にアカウントを作成し、あなたのメールアドレスと適当な画像を紐付けてみてください。メールアドレスをMD5ハッシュ化して、紐付けた画像がちゃんと表示されるかどうか試してみましょう。

7.1.4で定義したgravatar_forヘルパーをリスト 7.12のように変更して、sizeをオプション引数として受け取れるようにしてみましょう。うまく変更できると、gravatar_for user, size: 50といった呼び出し方ができるようになります。重要: この改善したヘルパーは10.3.1で実際に使います。忘れずに実装しておきましょう。

(main):002:0> user.update_attributes(name: "Example user",email: "m23.....@gmail.com
" , password: "foobar", password_confirmation: "foobar" )
=> true

画面に紐付けした自分の画像が表示された

オプション引数は今でもRubyコミュニティで一般的に使われていますが、Ruby 2.0から導入された新機能「キーワード引数（Keyword Arguments）」でも実現することができます。先ほど変更したリスト 7.12を、リスト 7.13のように置き換えてもうまく動くことを確認してみましょう。この２つの実装方法はどういった違いがあるのでしょうか? 考えてみてください。
→単純に置き換えるだけ

7.2 ユーザー登録フォーム

ユーザー登録フォームを作成する

7.2.1 form_withを使用する

ユーザー登録ページで重要な要素は、するフォームです。
Railsでform_withヘルパーメソッドを使い,ユーザー登録に不可欠な情報を入力する。
このメソッドはActive Recordのオブジェクトを取り込み、そのオブジェクトの属性を使ってフォームを構築する。

newアクションに@user変数を追加する

app/controllers/users_controller.rb
class UsersController < ApplicationController

  def show
    @user = User.find(params[:id])
  end

  def new
    @user = User.new  #@userにUserインスタンスを作成
  end
end

ビューを作る前にCSSを追記

app/assets/stylesheets/custom.scss
.
.
.
/* forms */
input, textarea, select, .uneditable-input {
  border: 1px solid #bbb;
  width: 100%;
  margin-bottom: 15px;
  @include box_sizing;
}
input {
  height: auto !important;
}

htmlのフォーム側を作成

app/views/users/new.html.erb
<% provide(:title, 'Sign up') %>
<h1>Sign up</h1>

<div class="row">
  <div class="col-md-6 col-md-offset-3">
    <%= form_with(model: @user, local: true) do |f| %>
      <%= f.label :name %>
      <%= f.text_field :name %>

      <%= f.label :email %>
      <%= f.email_field :email %>

      <%= f.label :password %>
      <%= f.password_field :password %>

      <%= f.label :password_confirmation, "Confirmation" %>
      <%= f.password_field :password_confirmation %>

      <%= f.submit "Create my account", class: "btn btn-primary" %>
    <% end %>
  </div>
</div>

演習

試しに、ブロックの変数fをすべてfoobarに置き換えてみて、結果が変わらないことを確認してみてください。確かに結果は変わりませんが、変数名をfoobarとするのはあまり良い変更ではなさそうですね。その理由について考えてみてください。
→繰り返し文の変数みたいなものなのでなんでもいいはず。fの方が簡単だと思う

7.2.2 フォームHTML

フォームのHTMLを分解して解説していく

<%= form_with(model: @user, local: true) do |f| %>
  .
  .
  .
<% end %>

  • doは、form_withが1つの変数を持つブロックを取ることを表します。

  • 変数fは “form” のfです。

  • ハッシュ引数local: trueが存在していることに注目

  • form_withはデフォルトで“remote” XHR requestを送信するようだが、ここではエラーメッセージをほぼ確実に表示するために通常の“local”フォームリクエストを送信したいため

  • fオブジェクトは、HTMLフォーム要素（テキストフィールド、ラジオボタン、パスワードフィールドなど）に対応するメソッドが呼び出されると、@userの属性を設定するために特別に設計されたHTMLを返す。つまり、次のコードを実行すると、

<%= f.label :name %>
<%= f.text_field :name %>

Userモデルのname属性を設定する、ラベル付きテキストフィールド要素を作成するのに必要なHTMLを作成する

HTMLソースを確認すると意図するところがわかる

<form accept-charset="UTF-8" action="/users" class="new_user"
      id="new_user" method="post">
  <input name="authenticity_token" type="hidden"
         value="NNb6+J/j46LcrgYUC60wQ2titMuJQ5lLqyAbnbAUkdo=" />
  <label for="user_name">Name</label>   
  <input id="user_name" name="user[name]" type="text" />

  <label for="user_email">Email</label>
  <input id="user_email" name="user[email]" type="email" />

  <label for="user_password">Password</label>
  <input id="user_password" name="user[password]"
         type="password" />

  <label for="user_password_confirmation">Confirmation</label>
  <input id="user_password_confirmation"
         name="user[password_confirmation]" type="password" />

  <input class="btn btn-primary" name="commit" type="submit"
         value="Create my account" />
</form>

コードとHTMLソースを比べてみる

<%= f.label :name %>
<%= f.text_field :name %>
↓↓↓
<label for="user_name">Name</label>
<input id="user_name" name="user[name]" type="text" />

lavelを作成しtype="text"のinputタグを生成している

<%= f.label :email %>
<%= f.email_field :email %>
↓↓
<label for="user_email">Email</label>
<input id="user_email" name="user[email]" type="email" />

<%= f.label :password %>
<%= f.password_field :password %>
↓↓
<label for="user_password">Password</label>
<input id="user_password" name="user[password]" type="password" />

最も重要なのはname属性の使い方

  • Railsはnameの値を使って、初期化したハッシュを（params変数経由で）構成する
  • このハッシュは、入力された値に基づいてユーザーを作成するときに使われる。
<input id="user_name" name="user[name]" - - - />
.
.
.
<input id="user_password" name="user[password]" - - - />

次に重要な要素は、formタグ自身

  • Railsはformタグを作成するときに@userオブジェクトを使う。
  • すべてのRubyオブジェクトは自分のクラスを知っているので、Railsは@userのクラスがUserであることを認識
  • また、@userは新しいユーザーなので、 Railsはpostメソッドを使ってフォームを構築すべきだと判断。

なお、新しいオブジェクトを作成するために必要なHTTPリクエストはPOSTなので、このメソッドはRESTfulアーキテクチャとして正しいリクエストになる
<form action="/users" class="new_user" id="new_user" method="post">

action="/users"とmethod="post"で、/users に対してHTTPのPOSTリクエスト送信する、といった指示をしている

formタグの内側で次のようなHTMLが生成されている

<input name="authenticity_token" type="hidden"
       value="NNb6+J/j46LcrgYUC60wQ2titMuJQ5lLqyAbnbAUkdo=" />

このコードはブラウザ上では何も表示しないが、Railsの内部で使われる特別なコード
簡単にいうとCross-Site Request Forgery（CSRF）と呼ばれる攻撃を阻止するためにトークンを含めたりしている

演習

『Web基礎編: HTML』ではHTMLをすべて手動で書き起こしていますが、なぜformタグを使わなかったのでしょうか? 理由を考えてみてください。
→railsを使用できなかったため

7.3 ユーザー登録失敗

フォームを理解するにはユーザー登録の失敗の時が最も参考になる、ということで
無効なデータ送信を受け付けるユーザー登録フォームを作成、ユーザー登録フォームを更新してエラーの一覧を表示する。

7.3.1 正しいフォーム

resources :usersをroutes.rbファイルに追加すると自動的にRailsアプリケーションがのRESTfulな以下のURI に応答するようになっている

HTTPリクエスト URL アクション 名前付きルート 用途
GET /users index users_path すべてのユーザーを一覧するページ
GET /users/1 show user_path(user) 特定のユーザーを表示するページ
GET /users/new new new_user_path ユーザーを新規作成するページ（ユーザー登録）
POST /users create users_path ユーザーを作成するアクション
GET /users/1/edit edit edit_user_path(user) id=1のユーザーを編集するページ
PATCH /users/1 update user_path(user) ユーザーを更新するアクション
DELETE /users/1 destroy user_path(user) ユーザーを削除するアクション

formタグでPOSTリクエストをrailsへ送るということは

<form action="/users" class="new_user" id="new_user" method="post">

このHTMLはPOSTリクエストを/usersというURLに送信する。

  1. /usersへのPOSTリクエストはcreateアクションに送られる。
  2. createアクションでフォーム送信を受け取り、
  3. User.newを使って新しいユーザーオブジェクトを作成
  4. ユーザーを保存（または保存に失敗）
  5. 再度の送信用のユーザー登録ページを表示する

という流れで実装していく

createアクションを実装

app/controllers/users_controller.rb
class UsersController < ApplicationController

  def show
    @user = User.find(params[:id])
  end

  def new
    @user = User.new
  end

  def create
    @user = User.new(params[:user])    # 実装は終わっていないことに注意!
    if @user.save
      # 保存の成功をここで扱う。
    else
      render 'new'
    end
  end
end

コメントにもあるように、上のコードはまだ実装が完了していませんので注意してください

ここで、デバッグ情報のパラメーターハッシュのuserの部分を見てみる。

"user"=>{"name"=>"", 
         "email"=>"", 
         "password"=>"[FILTERED]", 
         "password_confirmation"=>"[FILTERED]"},

userハッシュの中にname email password password_confirmationという四つのハッシュが入っている。
この構造をhash-of-hashesと言う。

つまり、フォームの内容で送られたそれぞれの値は、createアクションで定義したparamsの[:user]にシンボルで渡されている。

[:user]はuserハッシュで、さらにその中にハッシュが入っていてそれぞれの属性値が渡されるという訳。

そして、上記のキー(nameやemailなど)は、newビューのinputタグにあった属性の値になる。

例えば、emailの場合

<input type="email" name="user[email]" id="user_email">

name属性を見てみると、user[email]となっている。
これは、userハッシュの中のemailキーの値を送りますよ、という意味。

そして、
createアクションのparams[:user]にて、emailのキーに値として受け取っている。
(ここ重要)

params[:user]の:userはシンボルなので、データの値を受け取れる点もポイント。

@user = User.new(params[:user])

このようなコードは、アスアサインメントと呼ぶ。

これが実質的には

@user = User.new(name: "Foo Bar", email: "foo@invalid", 
                 password: "foo", password_confirmation: "bar")

このようなコードになっている。(フォームで送られた値を受け取ってるから)

ちなみに、昔のRailsでは

@user = User.new(params[:user])

だけでも動いたが、悪意のあるユーザーによってアプリケーションのデータベースが書き換えられてしまう危険性（これをマスアサインメント脆弱性と言う）があるため、このコードのみだとエラーとし、このエラーを解消するためのコードを次項で追記する。

7.3.2 Strong Parameters

マスアサインメントは、次のように値のハッシュを使ってRubyの変数を初期化するもの

app/controllers/users_controller.rb
@user = User.new(params[:user])    # 実装は終わっていないことに注意!

この実装は最終形でない理由は

  • paramsハッシュ全体を初期化す行為はセキュリティ上、極めて危険だから
  1. ユーザーが送信したデータをまるごとUser.newに渡す
  2. UserモデルにWebサイトの管理者であるかどうかを示すadmin属性があるとすると
  3. admin=’1’という値をparams[:user]の一部に紛れ込ませて渡してしまえば、この属性をtrueにすることができてしまう
  4. curlなどのコマンドを使えばadmin属性を簡単に紛れ込ますことができてしまう
  5. するとどのユーザーでもadmin=’1’をWebリクエストに紛れ込ませるだけでWebサイトの管理者権限を奪い取ることができてしまう。

※curlコマンドとは
https://curl.se/
https://qiita.com/yasuhiroki/items/a569d3371a66e365316f
curlコマンドとはサーバから、もしくはサーバへデータ転送を行うコマンド

これをRails4.0ではコントローラ層で、Strong Parametersというテクニックを使うことが推奨されている。

Strong Parametersを使うことで、必須のパラメータと許可されたパラメータを指定することが出来る。
さらに、上のようにparamsハッシュを丸ごと渡すとエラーが発生するので、Railsはデフォルトでマスアサインメントの脆弱性から守られるようになった。

この場合、paramsハッシュでは:user属性を必須とし、名前、メールアドレス、パスワード、パスワードの確認の属性をそれぞれ許可し、それ以外を許可しないようにしたい
それをコードにすると以下のようになる

params.require(:user).permit(:name, :email, :password, :password_confirmation)
# :userシンボルを要求し、permit(＝許された属性だけ)を要求する　＝admin属性やその他は遮断する

このコードの戻り値は、許可された属性のみが含まれたparamsのハッシュ（:user属性がない場合はエラー）

これらのパラメータを使いやすくするために、user_paramsという外部メソッドを使うのが慣習になっていてparams[:user]の代わりとして使われる

@user = User.new(user_params)
# 上記のコードをuser_paramsを別の場所の定義

最終的にこのようなコードになる
private以下のコードはrails consoleなどでも呼び出しできないよう隠してある

app/controllers/users_controller.rb
class UsersController < ApplicationController
  .
  .
  .
  def create
    @user = User.new(user_params)　　#privete以下で定義したメソッド呼び出し
    if @user.save
      # 保存の成功をここで扱う。
    else
      render 'new'
    end
  end

  private
　　
    def user_params　　#指定のparams以外受け取らない機能
      params.require(:user).permit(:name, :email, :password,
                                   :password_confirmation)
    end
end

privateキーワード以降のコードを強調するために、user_paramsのインデントを1段深くしてある

これで、フォームに何も値を入力しないで送信ボタンを押すと、createアクションにて/usersに飛ぶ

ユーザー登録フォームは動いているが

  • 間違った値でも送信出来る
  • 新しいユーザーが作成されない
    この二つの問題点が発生しているため、これを改善していく。

演習
/signup?admin=1 にアクセスし、paramsの中にadmin属性が含まれていることをデバッグ情報から確認してみましょう。

--- !ruby/object:ActionController::Parameters
parameters: !ruby/hash:ActiveSupport::HashWithIndifferentAccess
  admin: '1'
  controller: users
  action: new
permitted: false

7.3.3 エラーメッセージ

ユーザー登録に失敗した場合にエラーメッセージを表示する
例えばユーザー情報のメールアドレスが無効で、パスワードが短すぎる状態で保存しようした場合

$ rails console
>> user = User.new(name: "Foo Bar", email: "foo@invalid",
?>                 password: "dude", password_confirmation: "dude")
>> user.save
=> false
>> user.errors.full_messages
=> ["Email is invalid", "Password is too short (minimum is 6 characters)"]

user.errors.full_messagesで自動でエラーメッセージが作れる
errors.full_messagesオブジェクトは、 エラーメッセージの配列を持っている
このメッセージをブラウザで表示するには、ユーザーのnewページでエラーメッセージのパーシャル（partial）を出力
このとき、form-controlというCSSクラスも一緒に追加することで、Bootstrapがスタイルをいい感じにしてくれる。

app/views/users/new.html.erb
<% provide(:title, 'Sign up') %>
<h1>Sign up</h1>

<div class="row">
  <div class="col-md-6 col-md-offset-3">
    <%= form_with(model: @user, local: true) do |f| %>
      <%= render 'shared/error_messages' %> #パーシャルをrenderしている

      <%= f.label :name %>
      <%= f.text_field :name, class: 'form-control' %>

      <%= f.label :email %>
      <%= f.email_field :email, class: 'form-control' %>

      <%= f.label :password %>
      <%= f.password_field :password, class: 'form-control' %>

      <%= f.label :password_confirmation, "Confirmation" %>
      <%= f.password_field :password_confirmation, class: 'form-control' %>

      <%= f.submit "Create my account", class: "btn btn-primary" %>
    <% end %>
  </div>
</div>

エラーメッセージのような複数のビューで使われるパーシャルは専用のディレクトリ「shared」によく置かれるらしい

今はまだapp/views/sharedといったディレクトリは作っていないので、新しくディレクトリを作成する

$ mkdir app/views/shared

パーシャル（_error_messages.html.erb）も作成

touch  app/views/shared/_error_messages.html.erb

error_messages.html.erbに以下コードを追記

app/views/shared/_error_messages.html.erb
<% if @user.errors.any? %>　　#解説2
  <div id="error_explanation">　#解説4
    <div class="alert alert-danger">
      The form contains <%= pluralize(@user.errors.count, "error") %>.　　#解説1count　#解説3　pluralize
    </div>
    <ul>
    <% @user.errors.full_messages.each do |msg| %>
      <li><%= msg %></li>
    <% end %>
    </ul>
  </div>
<% end %>

解説1countメソッド　＝　エラーの数を返す

>> user.errors.count
=> 2

解説2　any?メソッド　empty?メソッドの真逆の機能

>> user.errors.empty?
=> false
>> user.errors.any?
=> true

any?メソッド要素が1つでもある場合はtrue、ない場合はfalseを返す

解説3　pluralizeテキストヘルパー

pluralizeの最初の引数に整数が与えられると、それに基づいて2番目の引数の英単語を複数形に変更したものを返す。
このメソッドの背後には強力なインフレクター（活用形生成）があり、不規則活用を含むさまざまな単語を複数形にすることができます。

>> helper.pluralize(1, "error")
=> "1 error"
>> helper.pluralize(5, "error")
=> "5 errors"
>> helper.pluralize(2, "woman")
=> "2 women"
>> helper.pluralize(3, "erratum")
=> "3 errata"

pluralizeを使うことで、コードは次のようになり

<%= pluralize(@user.errors.count, "error") %>

"1 errors" のような英語の文法に合わない文字列を避けることができる

解説4　

<div id="error_explanation">　

新たにCSSを追加できる

またRailsは、無効な内容の送信によって元のページに戻されると、CSSクラスfield_with_errorsを持ったdivタグでエラー箇所を自動的に囲んでくれる。

これは、newビューで定義したform_forタグで囲んだ中のフィールドの部分を、
自動でfield_with_errorsというdivタグで囲むというもの。

divタグで囲んでくれるためエラーメッセージをSCSSで整形することができる。
Sassの@extend関数を使ってBootstrapのhas-errorというCSSクラスを適用

app/assets/stylesheets/custom.scss
.
.
.
/* forms */
.
.
.
# error_explanation {
  color: red;
  ul {
    color: red;
    margin: 0 0 30px 0;
  }
}

.field_with_errors {
  @extend .has-error;
  .form-control {
    color: $state-danger-text;
  }
}

今時点、presence: trueによるバリデーションも、has_secure_passwordによるバリデーションも
空のパスワード（nil）を検知してしまうため、ユーザー登録フォームで空のパスワードを入力すると2つの同じエラーメッセージが表示されてしまっている。
エラーメッセージを直接修正することも可能だが、後ほど追加するallow_nil: trueというオプションで解決する。

演習

1最小文字数を5に変更すると、エラーメッセージも自動的に更新されることを確かめてみましょう。

user.rb
   validates :password, presence: true, length: { minimum: 5 }

エラーメッセージも変わる

2未送信のユーザー登録フォーム（図 7.13）のURLと、送信済みのユーザー登録フォーム（図 7.19）のURLを比べてみましょう。なぜURLは違っているのでしょうか? 考えてみてください。

ルーティングがビューを表示するURL(new)と、データを保存するURL(create)が異なるため

7.3.4 失敗時のテスト

昔はフォームのテストは毎回手動で行う必要があったが、
Railsではフォーム用テストを書くことができ、こういったプロセスを自動化できる。

今回は無効な送信をした時の正しい振る舞いについてテストを書いていく。

まずは、新規ユーザー登録用(signup)の統合テストを生成する。

$ rails generate integration_test users_signup
      invoke  test_unit
      create    test/integration/users_signup_test.rb

このテストでは、ユーザー登録ボタンを押したときに（ユーザー情報が無効であるために）ユーザーが作成されないことを確認する
これを確認するために、ユーザーの数をカウント（count）します。このテストの背後で動作するcountメソッドは、Userを含むあらゆるActive Recordクラスで使うことができます。

$ rails console
>> User.count
=> 1
test/integration/users_signup_test.rb
require 'test_helper'

class UsersSignupTest < ActionDispatch::IntegrationTest

  test "invalid signup information" do
    get signup_path     #newページを取得
    assert_no_difference 'User.count' do　　以下の動作をして、Userのcountが変わらないことを確認
      post users_path, params: { user: { name:  "",　　　　　　　　　#createアクションにparamsを送信　
                                         email: "user@invalid",     #名前もメールもパスワードも適当
                                         password:              "foo",
                                         password_confirmation: "bar" } }
    end
    assert_template 'users/new'　　　　#users/newを描写されるか
  end
end

テストはパスするはず

演習

リスト 7.20で実装したエラーメッセージに対するテストを書いてみてください。どのくらい細かくテストするかはお任せします。リスト 7.25にテンプレートを用意しておいたので、参考にしてください。

test/integration/users_signup_test.rb
    assert_template 'users/new'
    assert_select   'div#error_explanation'          # cssが表示されればOK
    assert_select   'div.field_with_errors'         #cssが表示されればOK　＝エラーが表示されている証明
  end
  .
  .
  .
end

7.4 ユーザー登録成功

  • フォームが有効な場合に新規ユーザーを実際にデータベースに保存できるようにする
  • 保存に成功すると、ユーザー情報は自動的にデータベースに登録
  • 次にブラウザの表示をリダイレクトして、登録されたユーザーのプロフィールを表示
  • ついでにウェルカムメッセージも表示

7.4.1 登録フォームの完成

保存成功時の動作を書いていく。

現時点では、有効な情報でフォーム送信してもエラーが発生してしまう。
これは、データをcreateアクションに送った際、対応するビューがないことが原因。

確かにビューを作成すればエラーは解消されるが、新たなビューは作らず、redirect_toメソッドを使い、保存成功と同時に/usersへ移動させる。

app/controllers/users_controller.rb
class UsersController < ApplicationController
  .
  def create
    @user = User.new(user_params)
    if @user.save
      redirect_to @user #userのshowを描写
    else
      render 'new'
    end
  end
.
.
end

redirect_to @user
は次のコードと等価
redirect_to user_url(@user)
これはredirect_to @userというコードから（Railsエンジニアが）user_url(@user)といったコードを実行したいということを、Railsが推察してくれた結果

演習

1有効な情報を送信し、ユーザーが実際に作成されたことを、Railsコンソールを使って確認してみましょう。

irb(main):001:0> User.find_by(email: "aaaa@com.com")
=> #<User id: 2, name: "inoue", email: "aaaa@com.com", created_at: "2021-02-17 06:02:39", updated_at: "2021-02-17 06:02:39", password_digest: [FILTERED]>

登録されている

2リスト 7.26を更新し、redirect_to user_url(@user)とredirect_to @userが同じ結果になることを確認してみましょう。
確認済

7.4.2 flash

flashという特殊な変数を使い、登録完了後に表示されるページにフラッシュメッセージを表示する

Railsの一般的な慣習に倣って、:successというキーには成功時のメッセージを代入するようにする

app/controllers/users_controller.rb
class UsersController < ApplicationController
  .
  .
  .
  def create
    @user = User.new(user_params)
    if @user.save
      flash[:success] = "Welcome to the Sample App!" #flashメッセージを表示
      redirect_to @user
    else
      render 'new'
    end
  end
end

flash変数に代入したメッセージは、リダイレクトした直後のページで表示できるようになる
ビューで表示する前にコンソールで挙動を確認

$ rails console
>> flash = { success: "It worked!", danger: "It failed." }#flashにsuccessとdangerキー、メッセを追加
=> {:success=>"It worked!", danger: "It failed."}
>> flash.each do |key, value|　　#繰り返し文でflashのハッシュを当てはめていく
?>   puts "#{key}"
?>   puts "#{value}"
>> end
success
It worked!
danger
It failed.

レイアウトを追加

app/views/layouts/application.html.erb
<!DOCTYPE html>
<html>
  .
  .
  .
  <body>
    <%= render 'layouts/header' %>
    <div class="container">
      <% flash.each do |message_type, message| %>　#解説1
        <div class="alert alert-<%= message_type %>"><%= message %></div>
      <% end %>
      <%= yield %>
      <%= render 'layouts/footer' %>
      <%= debug(params) if Rails.env.development? %>
    </div>
    .
    .
    .
  </body>
</html>

解説1

<% flash.each do |message_type, message| %>
  <div class="alert alert-<%= message_type %>"><%= message %></div>
<% end %>

alert-<%= message_type %>

適用するCSSクラスをメッセージの種類によって変更するようにしている。
例えば:successキーのメッセージが表示される場合、alert-successというクラスになる

flashの:successキーはシンボルなのになぜ、そうなるかというと
埋め込みRubyが自動的に"success"という文字列に変換する
この性質を利用して、キーの内容によって異なったCSSクラスを適用させることができ、メッセージの種類によってスタイルを動的に変更させることができるようになる

例えばflash[:danger]を使ってログインに失敗したことを表すメッセージを表示したい場合
Bootstrap CSSは、このようなflashのクラス用に4つのスタイルを持っていて（success、info、warning、danger）、スタイルを場合に応じて使う

最終的には次のようなHTMLになる
<div class="alert alert-success">Welcome to the Sample App!</div>

演習

1コンソールに移り、文字列内の式展開（4.2.1）でシンボルを呼び出してみましょう。例えば"#{:success}"といったコードを実行すると、どんな値が返ってきますか? 確認してみてください。

irb(main):002:0> "#{:success}"
=> "success"

2先ほどの演習で試した結果を参考に、リスト 7.28のflashはどのような結果になるか考えてみてください。
同じことをする

flash = { success: "It worked!", danger: "It failed." }
=> {:success=>"It worked!", danger: "It failed."}
>> flash.each do |key, value|
?>   puts "#{key}"
?>   puts "#{value}"
>> end
success
It worked!
danger
It failed.

7.4.3 実際のユーザー登録

実際にユーザー登録を試す
ユーザー登録を試す前に、次のコマンドを実行してデータベースの内容を一旦リセット

$ rails db:migrate:reset

環境によっては、ここでWebサーバーを再起動する

今回は名前を「Rails Tutorial」
メールアドレスを「example@railstutorial.org」として登録
→実際にできた

演習
1Railsコンソールを使って、新しいユーザーが本当に作成されたのかもう一度チェックしてみましょう。結果は、リスト 7.30のようになるはずです。
2自分のメールアドレスでユーザー登録を試してみましょう。既にGravatarに登録している場合、適切な画像が表示されているか確認してみてください。
→登録済

7.4.4 成功時のテスト

テストを書いていく

test/integration/users_signup_test.rb
require 'test_helper'

class UsersSignupTest < ActionDispatch::IntegrationTest
  .
  .
  .
  test "valid signup information" do
    get signup_path
    assert_difference 'User.count', 1 do     #Userのカウントが1増えるか
      post users_path, params: { user: { name:  "Example User",　　#正しいユーザをparamsに渡す
                                         email: "user@example.com",
                                         password:              "password",
                                         password_confirmation: "password" } }
    end
    follow_redirect!　　#postリクエストを送信した結果をみて指定されたリダイレクト先に移動する
    assert_template 'users/show'
  end
end

assert_template 'users/show'

演習
1　7.4.2で実装したflashに対するテストを書いてみてください。どのくらい細かくテストするかはお任せします。リスト 7.32に最小限のテンプレートを用意しておいたので、参考にしてください（FILL_INの部分を適切なコードに置き換えると完成します）。ちなみに、テキストに対するテストは壊れやすいです。文量の少ないflashのキーであっても、それは同じです。筆者の場合、flashが空でないかをテストするだけの場合が多いです。

リスト 7.32: flashをテストするためのテンプレート

test/integration/users_signup_test.rb
require 'test_helper'
  .
  .
  .
  test "valid signup information" do
    get signup_path
    assert_difference 'User.count', 1 do
      post users_path, params: { user: { name:  "Example User",
                                         email: "user@example.com",
                                         password:              "password",
                                         password_confirmation: "password" } }
    end
    follow_redirect!
    assert_template 'users/show'
    assert_not flash.FILL_IN
    assert_not   flash.blank? 
  end
end

2本文中でも指摘しましたが、flash用のHTML（リスト 7.29）は読みにくいです。より読みやすくしたリスト 7.33のコードに変更してみましょう。変更が終わったらテストスイートを実行し、正常に動作することを確認してください。なお、このコードでは、Railsのcontent_tagというヘルパーを使っています。

リスト 7.33: content_tagを使ってレイアウトの中にflashを埋め込む

app/views/layouts/application.html.erb
<!DOCTYPE html>
<html>

      <% flash.each do |message_type, message| %>
        <%= content_tag(:div, message, class: "alert alert-#{message_type}") %>
      <% end %>
      .

</html>

書き換えて問題なくtestはパスする

3リスト 7.26のリダイレクトの行をコメントアウトすると、テストが失敗することを確認してみましょう。

FAIL["test_valid_signup_information", #<Minitest::Reporters::Suite:0x00007ffb9e0d73b0 @name="UsersSignupTest">, 1.6894480008631945]
 test_valid_signup_information#UsersSignupTest (1.69s)
        expecting <"users/show"> but rendering with <[]>
        test/integration/users_signup_test.rb:26:in `block in <class:UsersSignupTest>'

4リスト 7.26で、@user.saveの部分をfalseに置き換えたとしましょう（バグを埋め込んでしまったと仮定してください）。このとき、assert_differenceのテストではどのようにしてこのバグを検知するでしょうか? テストコードを追って考えてみてください。

保存失敗だとすると、保存前(get)で読み込んだassert_differenceで、User.countの値が変わらず(1→1)、postでcreateアクションに送るも、paramsでuserハッシュの値を受け取れず失敗する。

7.5 プロのデプロイ

これまでのデプロイと違って、実際に本番環境でデータを操作できるようにする。
具体的には、ユーザー登録をセキュアにするために、本番用アプリケーションに重要な機能を追加していく。

その後、デフォルトのWebサーバーをプロが使うWebサーバーに置き換える

まずはこの時点までの変更をmasterブランチにマージ

$ git add -A
$ git commit -m "Finish user signup"
$ git checkout master
$ git merge sign-up

7.5.1 本番環境でのSSL

これまでと違うのは、ユーザー登録フォームでデータを送信するという点。

ユーザーの名前やパスワードなどがネットワーク越しに流されていく。
このような個人情報は暗号化しないと、ハッカーなんかに情報を盗まれてしまうため非常に危険。

情報セキュリティの三原則「機密性の確保」を行うためにも、Secure Sockets Layer(SSL)を使って、
通信を暗号化する。

SSLを有効化するのは簡単で、production.rbと言う本番環境の設定ファイルに「本番環境ではSSLを使うようにする」1行を修正するだけで済む

config/environments/production.rb
Rails.application.configure do
  .
  .
  .
  # Force all access to the app over SSL, use Strict-Transport-Security,
  # and use secure cookies.
  config.force_ssl = true  #記述する
  .
  .
  .
end

本番用のWebサイトでSSLを使えるようにするためには、ドメイン毎にSSL証明書を購入し、セットアップする必要がある。

しかし、お金もかかるので、herokuのSSL証明書に便乗する形でセットアップする

7.5.2 本番環境用のWebサーバー

Herokuデフォルでは、Rubyだけで実装されたWEBrickと言うWebサーバーを使っているが、
多くのトラフィックを捌けないので、今回はPumaを使う。

最初にpuma gemをGemfileに追加する必要があるが、Rails 5ではデフォルトの設定でも使えるので、今回は必要なし。

pumaファイルに以下を記述するだけ
デフォルトでコメントアウト記述がたくさんあるが、削除してこれをコピーした方が早い

config/puma.rb
# Pumaの設定ファイル
max_threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
min_threads_count = ENV.fetch("RAILS_MIN_THREADS") { max_threads_count }
threads min_threads_count, max_threads_count
port        ENV.fetch("PORT") { 3000 }
environment ENV.fetch("RAILS_ENV") { ENV['RACK_ENV'] || "production" }
pidfile ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }
workers ENV.fetch("WEB_CONCURRENCY") { 2 }
preload_app!
plugin :tmp_restart

最後に、Procfileと呼ばれる、Heroku上でPumaのプロセスを走らせる設定ファイルを作成
なお、このProcfileはルートディレクトリ（Gemfileと同じディレクトリ）に置いておく必要があるので、ファイルを置くディレクトリには注意してください。

$ touch ./Procfile
./Procfile
web: bundle exec puma -C config/puma.rb

7.5.3 本番データベースを設定する

最後に本番データベースを正しく設定する。
使うデータベースはPostgreSQL
PostgreSQLはHerokuで何の設定を行わなくても動作しますが、HerokuのRails 6向け公式ドキュメントでは明示的にPostgreSQLを設定することを推奨していますので、念のためそれに沿って追記

config/database.yml
# SQLite version 3.x
#   gem install sqlite3
#
#   Ensure the SQLite 3 gem is defined in your Gemfile
#   gem 'sqlite3'
#
default: &default
  adapter: sqlite3
  pool: 5
  timeout: 5000

development:
  <<: *default
  database: db/development.sqlite3

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  <<: *default
  database: db/test.sqlite3

production:
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see Rails configuration guide
  # https://railsguides.jp/configuring.html#データベース接続をプールする
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  database: sample_app_production
  username: sample_app
  password: <%= ENV['SAMPLE_APP_DATABASE_PASSWORD'] %>

7.5.4 本番環境へのデプロイ

これで、本番環境用のWebサーバーとデータベースの設定は完了
変更をコミットし、デプロイしてみる

$ rails test
$ git add -A
$ git commit -m "Use SSL and the Puma webserver in production"
$ git push && git push heroku

Herokuのデプロイするとき 次のような警告メッセージが出るかもしれないが、今回は気にしなくてOK

###### WARNING:
       You have not declared a Ruby version in your Gemfile.
       To set your Ruby version add this line to your Gemfile:
       ruby '2.6.3'

私は出ました

演習

ブラウザから本番環境（Heroku）にアクセスし、SSLの鍵マークがかかっているか、URLがhttpsになっているかどうかを確認してみましょう。
→確認ずみ
本番環境でユーザーを作成してみましょう。Gravatarの画像は正しく表示されているでしょうか?
→問題なく画像表示された

この章も長かったが覚えることも多かった。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?