DOM
DOMとは
Document Object Modelの略。
プログラムによってHTMLやXMLの文書構造やスタイルなどを変更するための仕組み。
DOMを利用することで文書の特定の部分に対して色をつけたり、大きく表示したりすることが出来る。
ノードとは
ノードはファイルの中の各要素を指す。DOMはノードを特定して文書を操作する。
ノードは階層構造に分かれており、HTMLの場合はタグやエレメント(タグで囲んだ情報)で構成されている。
<body> <!-- 親ノード --> <p> <!-- 基準ノード --> <span> <!-- 子ノード --> </span> </p> <p> <!-- 兄弟姉妹ノード --> </p>
使用例
セクション1
<section id="1"> <h1>セクション1</h1> </section> <script> // sectionタグのノードを変更 document.getElementById(1).style.background = 'red'; </script>
参考
【RSpec】FactoryBotのbuildとcreateの違い
buildメソッドとcreateメソッドの違い
テストデータの保存場所が違う
- buildはテストデータをメモリ上に保存する
- createはテストデータをDB上に保存する
例
userモデル(属性にname,password)があった場合
# build user = build(:user, name: "test", password: "password") #=> #<User id: nil, name: "test", password: "password", created_at: nil, updated_at: nil> # create user = create(:user, name: "test", password: "password") #=> #<User id: 1, name: "test", password: "password", created_at: "2020-03-21 15:59:38", updated_at: "2020-03-21 15:59:38">
buildはDBにデータが保存されていないため、idや作成日時がnilになっており、createはDBに保存されているため値がセットされる
用途別の使い分け
- DBの値を利用するテストが必要な場合にcreateを使う
データの個数計算や一意のデータしか保存できないことなど、DBにアクセスして確認するテストにはcraeteを利用する。
DBにアクセスする必要がないテストの場合は、テストの実行速度を上げるためにbuildを利用する。
参考
【Rails】RSpecによるテストについて
テストについて
- 手動テストだとリリースまでに手間が掛かり、不具合に気づかない可能性がある
- 自動テストによりコードの変更の都度、エラーの有無を確認できる
テストを描くメリット
環境のバージョンアップに対応
適切な粒度のコードになりやすい
- テストを意識するとメソッドやアクションが肥大化しすぎないため
開発効率を上げる
- 開発者もレビューアーも安心できるので開発時間を節約してくれるため
ライブラリ
-
- BDD(振る舞いを先に作り、あとでプロダクトコードを書く)のためのテスティングフレームワーク
- 要求仕様をドキュメントのようにテストをかけるため、動く仕様書と呼ばれる
- テストではなくSpecを書くという
Capybara
FactoryBot
- テスト用データの作成をサポートするgem
- Rails標準のFixtureの代替としてのgem
テストの種類
システムテスト(System Spec, Feature Spec)
- E2Eテスト、ブラウザからwebアプリの挙動を外部的に確認する
結合テスト(Request Spec)
- 複数機能が連続して想定通りに動くかを確認する、システムテストよりも内部的な確認
機能テスト(Contoroller Spec)
- コントローラー単位のテスト(現在は非推奨でRequest Specを推奨)
他に頻度が高いテスト
参考
セッション
セッションとは
webサーバーとwebブラウザでの一連の処理の流れのこと
- 例(ECサイト)
- 商品をカートに追加する
- 注文画面に進む
- 商品を購入する
上記の処理において、webサーバーとwebブラウザの処理は合計3回だが、「ECサイトで商品を購入する」という論理的な意味での処理は1回である
この論理的な意味での処理の流れをセッションという
なぜセッションが必要なのか
- http通信はステートレスなプロトコルのため
webサーバーとwebブラウザはhttpプロトコルによって通信しており、このプロトコルは状態を保存しないステートレスなプロトコルとなっている。
そのため、前回の通信内容を記録しておかなければ、論理的な意味での処理が出来なくなる。
どうやって情報を保存しているのか
CookieにセッションIDを記録して、webサーバーが通信内容を保存している
Cookieはwebサーバーからwebブラウザに識別のために保存された情報。- Cookie発行の流れ
つまり、Cookieによってwebブラウザの情報を保持することができる。
しかし、Cookieの中に個人情報が含まれていた場合、盗聴により通信内容が第三者に見られてしまう危険性がある。セッションIDはCookieの中に保存されるwebサーバーがwebブラウザを識別する番号
セッションIDをCookieに保存することで下記のメリットがある- セッションIDはただの番号なため、通信内容を盗聴出来ない
- Cookieに保存する情報量を気にしなくても良い
つまり、セッションIDをCookieに保存することで、webサーバーがwebブラウザを識別することができ且つ安全に通信を行うことができる
参考
DNS
記事作成の背景
ポートフォリオをherokuにデプロイした際にDNSの設定をしたため。
設定時はQittaやブログの記事をそのまま参考にしたため、どういった仕組みで動作しているか理解しきれていなかった。
そのため、DNSの仕組みを再確認した上で、herokuのデプロイ作業で何をやっていたか自分の理解のために記事をまとめる。
DNSとは
IPアドレスはインターネット上で通信先のコンピュータを特定するための番号。
ex)192.168.10.1
ドメインはIPアドレスを人間が見て理解しやすい名前にしたもの。
ex)google.com
DNSはIPアドレスとドメインの相互変換するサービス。 (この変換を名前解決と呼ぶ)
ブラウザからwebページにアクセスする際は、ドメイン名を元にIPアドレスを特定している。
- クライアントからDNSサーバーに「google.com」のIPアドレスを問い合わせる
- DNSサーバーが「google.com」に紐づくIPアドレスをクライアントに返す
- クライアントは返されたIPアドレスのサーバーにアクセスする
もう少し細かく書くと、クライアントからの問い合わせはDNSサーバーを複数経由している。
(世界中の全てのドメインを1つのDNSサーバーで管理しきれないため、.comのDNSサーバー→google.comのDNSサーバーのように名前解決できるDNSサーバーに問い合わせている)
また直接DNSサーバーにアクセスせず、名前解決のデータを一時保存するDNSキャッシュサーバーが応答していることが多い。 (DNSサーバーの処理負荷軽減・応答速度の向上のため)
デプロイ作業
デプロイまでに行なった作業は以下の通りです。
- ドメインの取得
- herokuの設定
- ドメイン追加
- PointDNSの設定
- ネームサーバーの設定
これらの作業で何をやっていたいのか書いていきます。
ドメインの取得
IPアドレスと紐付けるドメインを取得します。
お名前.comで取得しました。取得が簡単で利用者が多い分、参考となる記事も多いため。herokuの設定
PointDNSの設定
PointDNSとは追加したドメインがDNSサーバーに登録されることで、アプリをデプロイしたherokuのサーバーにリダイレクトされる機能です。Adding PointDNS to your app will properly configure your custom domain for Heroku and gives you the ability to add and customize your DNS with A, AAAA, CNAME, MX, SRV or TXT records. You can setup permanent HTTP redirects directly from the web interface. Replicate your records to your own DNS servers using zone transfers. PointDnsから抜粋
この機能により、追加したドメインがDNSサーバーにより名前解決され、herokuのサーバーにアクセスすることが出来ます。
ネームサーバーの設定
ネームサーバーとはドメイン名をIPアドレスに変換するサーバー、つまりDNSサーバーです。
お名前.comからherokuのDNSサーバーを登録します。
上記設定により取得したドメインの名前解決を行うDNSサーバーからアプリをデプロイしたサーバーにリダイレクトされます。
参照
MVCモデル
記事作成の経緯
Railsでポートフォリオを作成している中で、そもそもMVCモデルを理解してないため、開発するときやエラーがあった際にどこから手をつければいいのか分からないことが多い。
そのため、そもそもMVCモデルが何なのかを理解し、どういった構成でプログラムが作られているのか理解するため、自分なりにまとめてみる。
MVCモデルとは
プログラムをModel,View,Controllerの3つの役割に分けた構成のこと
それぞれの役割は
Model
プログラムで扱われるデータを管理するView
画面の表示、画面からの入力を受け付けるController
ModelとViewを制御する
具体例
ECサイトで商品をカゴに入れる処理をした場合の処理の流れ
View
商品をカゴに入れる入力を受け付けるController
Viewの操作を受け取り、Modelに商品をカゴに入れるよう指示するModel
カゴに商品が追加される
MVCモデルによる利点
プログラムの構成を把握しやすくなる
特定のモデルに基づき開発をすることで、プログラムを初めて見る人がどこに何の役割をもつプログラムがあるか分かりやすくなる分業しやすい
デザイナーはView,プログラマーはControllerなど担当者に合った機能を任せることが出来る仕様変更しやすい
それぞれの機能が独立しているため、仕様変更の際に特定の箇所だけを修正するだけでいい
所感
いざ自分の言葉で説明すると自分の思っていたよりも理解していないことが分かった。
ただまとめると考えが整理されるため、理解が甘いことはまとめてみることを習慣にする。
また、ただその技術のことを理解するのではなく、その技術がある理由まで考えると納得して使うことが出来る。
参考
【Rails】バージョンを指定してプロジェクトを作成する
- インストール済みのrailsのバージョンを確認する
$ gem list -e rails *** LOCAL GEMS *** rails (6.0.1, 6.0.0, 5.2.1)
- インストール済みのバージョンを指定して
rails new
する
# 5.2.1を指定する場合 $ rails _5.2.1_ new app_name
- 指定したバージョンでプロジェクトが作成されていることを確認する
$ cd app_name $ rails -v Rails 5.2.1
なお、バージョン指定がない場合はインストールされている最新バーションでプロジェクトが作成される。 (今回の場合は6.0.1で作成される)
- 補足
railsの指定バージョンをインストールする方法
# 4.1.1をインストールする場合 $ gem i -v 4.1.1 rails