研修という勉強するのにもってこいの機会なので，研修期間中に勉強した内容についてアウトプットの場として使用することにする．
ここでは主に，HTTP通信の仕組みについて記載している．
Details
- URLを解読する
- キャッシュにIPアドレスがないか確認する
- DNSでIPアドレスを取得する
- IPアドレスでWebサーバーにリクエストする
- ポート番号を割り当てる
- HTTPリクエストを送信する
- ロードバランサーでアクセスを調整する
- HTTPレスポンスを送信する
- レンダリングする
以上のような流れでクライアント側でWebページが表示される．
ここからは詳細を見ていく
URLは，以下のような形で構成される
https://railsdoc.com/rails_base
これらのそれぞれの意味は，プロトコル ドメイン名 パス名である．
キャッシュとは，一時的にデータを保存しておく場所．メモリともいう．
IPアドレスとは，サバーの住所．
つまり，キャッシュ内に今からアクセスしたいIPアドレスがあればそこから引っ張ってこよう！ということ．
DNSとは，Domain Name Systemの略で，名前解決をしてくれるサーバーのこと．
https://railsdoc.com/rails_baseのようなURLを123.456.789.0のようなIPアドレスに紐づけているシステムのこと．
コンピュータは数値しか読み取ることしかできないが，人間は文字を読む方が理解しやすい．なので，それを対応付けしているところ．
ドメインというのは，人間が理解しやすいように作られたもので，実際のコンピュータはIPアドレスを介してやりとりしている．
ここではリクエストの詳細な説明を割愛して，6番目で説明する．
ポート番号とは，TCP/IP通信においてコンピュータが通信に使用するプログラムを識別するための番号．
ポート番号は16ビットの整数であり，0~65535番まである．
IPアドレスがあればネットワーク上のコンピュータを一意に識別することができるが，該当コンピュータのどのプログラムに通信パケットを届けるかは決定できない．
どのプログラムに通信パケットを渡すのかを決定するためにポート番号を使用する．
ポート番号には以下の3つの識別がある．
- WELL KNOWN PORT NUMBERS(ウェルノウンポート番号): 0番～1023番
- REGISTERED PORT NUMBERS(登録ポート番号): 1024番～49151番
- DYNAMIC AND/OR PRIVATE PORTS(ダイナミック/プライベートポート番号): 49152番～65535番
クライアントがサーバに対してデータを送信し要求すること HTTPリクエストは以下のような形式になっている
curl -v google.com ↓
> GET / HTTP/2 # HTTPメソッド
> Host: google.com # メッセージヘッダ
> user-agent: curl/7.77.0
> accept: */*
> # 空白行
- リクエスト行
GET http://123.4.5.6/index.htmlのような形- HTTPメソッド
- GET: 指定したターゲットをサーバから取り出す
- HEAD: 指定したターゲットに関連するヘッダー情報を取り出す
- POST: 指定したターゲット(プログラム)にデータを送る
- PUT: サーバ内のファイルを書き込む
- DELETE: サーバ内のファイルを削除する
- CONNECT: プロキシサーバ経由で通信を行う
- メッセージヘッダ
- ヘッダフィールド
- クライアントやサーバがHTTPリクエストやレスポンスで追加情報を渡すことができる
- この中に認証方法やキャッシュ，クッキーなどが入る
- 空白行
- エンティティボディ
- メッセージ本体が入る
ロードバランサーとは，負荷分散装置と呼ばれ，通信を複数のサーバーに分散する仕組みを提供する装置．
クライアントから送信されたデータをサーバが処理をしてクライアントに返信する応答のこと HTTPレスポンスは以下のような形式になっている
- レスポンス行
- ステータスコード
- メッセージヘッダ
- ヘッダフィールド
- 空白行
- エンティティボディ
- メッセージ本体
ここでは以下のように処理が進む．
- サーバーからHTMLファイルがクライアントに送られる
- クライアントがHTMLファイルをローディングする
- HTMLファイルにCSSの記述があればもう一度サーバーからダウンロードする
- スクリプティングする
- JavaScriptを読み込む
- レンダリングする
Webの基本プロトコルのこと!
- webサーバとwebブラウザの間でweb情報をやりとりするためのプロトコル(通信規則)
- 動作がとてもシンプル
- クライアントが要求を出し，サーバーが応答を返す
- 1つの要求に対しては1つの応答を返すルール
- HTTP通信を受けるポート番号は80番ポート
クッキーはWebサーバアプリケーションがWebブラウザに対して特定の情報を保持させておく仕組みのこと．
HTTPはステートレスな仕組みであるが，クッキーを使うことでステートフルに使用できる．
通信が暗号化されているかされていないか!
- HTTPSはSSL/TLSプロトコルが作り出す安全な接続を使って通信を行う
- ポート番号は443番ポート
- SSLサーバ証明書が必要
クライアントマシンをサーバのように扱って通信を行える
プロキシサーバとは，代理のサーバのこと
クライアントとサーバの間にプロキシサーバを置くことで．通信内容のチェックを行い，外部からの不正アクセスや不正侵入を防止することができる．
HTTPステータスコードとは，レスポンス行で表示される3桁の番号のこと．
以下に代表的なHTTPステータスコードを示す．
- HTTP 100番台(information)
- 100 Continue: リクエスト継続可能
- 101 Switching Protocol: プロトコルの切り替え
- 102 Processing: 処理中
- ...
- HTTP 200番台(Success)
- 200 OK: リクエストが正常に処理できた
- 201 Created: リクエストが成功してリソースの作成が完了
- ...
- HTTP 300番台(Redirection)
- 300 Multiple Choice: リクエストに対して複数のレスポンスがあることを示す
- 301 Moved Permanently: 恒久的に移動する
- ...
- HTTP 400番台(Client Error)
- 400 Bad Request: 一般的なクライアントエラー
- 403 Forbidden: 閲覧権限がないファイルやフォルダ
- 404 Not Found: Webページが見つからない
- HTTP 500番台(Server Error)
- 500 Internal Server Error: 何らかのサーバ内で起きたエラー
- 501 Not Implemented: サーバーがリクエストに満たすのに必要な機能をサポートしていない
ここではRESTアーキテクチャについて記載している．
Details
シンプルなWebシステムの設計思想のこと
RESTにはRESTの4原則がある．これを満たすものをRESTfulなシステムと呼ぶ．
RESTの4原則は，HTTPを設計した中心人物のRoy Fielding氏が2000年に提唱したもので，以下の4つである．
- 統一インターフェース(Uniform Interface)
- アドレス可読性(Addressability)
- 接続性(Connectability)
- ステートレス性(Stateless) 以下に詳細を説明する．
情報をやり取りする方法を統一する． あらかじめインターフェースを決めておくことで設計をシンプルにする．
Webの場合の例) GET, POST, PUT, DELETEのメソッド
それぞれの情報ごとに場所や名前を識別できるURIで実現する．
Webの場合は通常URLで与えられる．
やり取りされる情報の中にハイパーリンクを含めることができる．
これにより，1つのリンクから別の情報に接続することができ，円滑に情報連携を行うことができる．
サーバーが過去の状態を持たず，純粋にその都度受け取った内容だけでやり取りする．
前のやり取りの結果に影響を受けないため，シンプルな設計にできる．(セッション管理が不要など)
- RESTはWebのシステムを設計するときの考え方の一つ
- RESTは，カリフォルニア大学の大学院生だったRoy Fieldingが2000年に修士論文で発表した
- RESTは(Representational State Transfer)の略で，直訳すると「具体的な状態の転送」という意味
- REST以外のアーキテクチャスタイルに，MVC, パイプ&フィルタ，イベントシステム，P2Pなどがある
- RESTにおけるリソースは，Web上のURI(URL・URN)を持ったすべての情報のこと
- RESTを構成する6つのアーキテクチャスタイル
- クライアント/サーバ
- ユーザインタフェースと処理を分離する
- クライアントがリクエストをサーバに出して，サーバがクライアントにレスポンスを返す
- 利点
- クライアントのマルチプラットフォーム化ができる
- サーバはストレージとしての機能だけを提供すれば良い
- ステートレスサーバ
- クライアントのアプリケーションの状態をサーバで管理しない
- Cookieを使ったセッション管理などでステートフルにすることが可能
- 利点
- クライアントからのリクエストに応じた後すぐに計算機リソースを解放できる -> サーバ側の実装を簡略化できる
- キャッシュ
- 一度取得したリソースをクライアント側で使い回す
- 利点
- クライアントとサーバの通信回数と量を減らすことができる
- 統一インターフェース
- URIで示したリソースに対する操作を統一した限定的なインターフェースで行う
- 利点
- 全体のアーキテクチャがシンプルになる
- クライアントとサーバ実装の独立性が向上する
- システム全体が階層化しやすくなる
- 階層化システム
- システムを改装に分離する
- HTTPで統一されていることによって．．．
- サーバとクライアントの間にロードバランサを設置して負荷分散できる
- プロキシを設置してアクセスを制限する
- 利点
- 分散化や冗長化が容易になる
- 既存の接続の間に新しいコンポーネントを追加することが可能
- コードオンデマンド
- プログラムをクライアントにダウンロードして実行する
- JavascriptやJavaアプレットなど
- 利点
- クライアントにない機能を後から追加できる
- プログラムをクライアントにダウンロードして実行する
- クライアント/サーバ
- 「統一/階層化/コードオンデマンド/クライアント/キャッシュ/ステートレスサーバ」(Uniform Layered Code on Demand Client Cache Stateless Server)略して「ULCODC$SS」と呼ぶ
- わかりやすいようにRESTと名前をつけた
RESTの原則に則って構築されたWebシステムのHTTPでの呼び出しインターフェースのこと
RESTful APIを使うメリット
- URIに規律が生まれることで，APIの開発者が楽になる
- ブラウザのアドレスバーにURIを入力すればリソースが参照できる
- サーバ/クライアント間で何も共有しないので，負荷に応じたスケーラビリティが向上する(ステートレス)
- HTTP標準メソッドを使うことでシンプルで一貫性のあるリクエスト標準化が円滑に行える(統一インターフェース)
ここでは，Railsで覚えておいた方が良いコマンドについて記載している
Details
コントローラーを作成
$ rails g controller Sample
コントローラーの作成を取り消し
$ rails destroy controller sample
モデルの作成
$ rails g model Sample
モデルの作成を取り消し
$ rails destroy model Sample
マイグレーション
$ rails db:migrate
マイグレーションの取り消し
$ rails db:rollback
ここではRailsのモデルを表現するActive Recordについて記載している．
Details
Active RecordはORM(オブジェクト/リレーショナルマッピング)システムに記述されているActive Recordパターンを実装したもの
- データベースとやりとりをするデフォルトのRailsライブラリ
- データオブジェクトの作成/保存/検索のためのメソッドを持つ
- SQLを意識する必要がない
RailsのORMを使った例:
SQLの場合
SELECT * FROM users;railsの場合
users = User.all
以下がActive Recordパターンで実現できる
- 一つのデータベースのテーブルと一つのクラスを対応づける
- そのクラスのインスタンスをテーブルの一つのレコードに紐付ける
要するに，SQLを直接書くことなくオブジェクトのメソッドでDB操作(CRUD)ができるということ！
Active Recordの重要機能
- モデルおよびモデル内のデータを表現する
- モデル同士の関連付けを表現する
- 関連づけられているモデルかんの継承階層を表現する
- データをデータベースで永続化する前にバリデーションを行う
- データベースをオブジェクト指向スタイルで操作する
マイグレーションとは，マイグレーションファイルをもとにテーブル操作を行う仕組みのこと
マイグレーションファイルは，Rubyで書かれたテーブルの設計図のこと
DBの生成手順
rails g modelでmodelファイルとmigrationファイルを作成- migrationファイル: DBに変更を加える内容を書く役割
- modelファイル: DBとRailsのアプリケーションをつなぐ役割
- モデルは全て
ApplicationRecordクラスを継承している ApplicationRecordクラスはActiveRecord::Baseクラスを継承しているActiveRecordクラスがSQL構文をRubyに翻訳する機能を持っている
- モデルは全て
rails db:mifrateを実行する- migrationファイルを元にDBに変更を加える
- ActiveRecordによって作成されたテーブルは以下のような特徴を持つ
- テーブル名はmodelの複数形
id,created_atが自動で生成される
オブジェクトがDBに保存される前にそのデータが正しいかどうかを検証する仕組み
バリデーションを定義すると，以下のメソッドが動く前に必ず検証される．
- save/save!
- create/create!
- update/update!
!をつけると保存されなかった場合(検証で失敗した場合)に例外処理を返す．つまり，falseやインスタンスが帰ってくるのではなく，エラー文が表示される．
以下によく使われるバリデーションヘルパーを示す
- presence
- 「空でないか」を検証する
validates :email, presence: truevalidates_presence_of :nameでも同じ意味
- uniqueness
- 値が重複していないかを検証する
validates :email, uniqueness: truevalidates_uniqueness_of :emailでも同じ意味
- まだいっぱいあるけどこの辺りは実装していく中で覚えていく
コールバックとは，オブジェクトのライフサイクル期間における特定の瞬間に呼び出されるメソッドのこと
コールバックを利用することでActive Recordオブジェクトがのイベント発生時に常に実行されるコードを書けるようになる．
イメージ的にはクラスのinitメソッドと同じようなもん，？
以下のようなコールバックが存在する
before_validationcreate,updateの前に発生する
around_savecreate,updateの前後に発生する
after_updatecreate,updateの後に発生する
ここのサイトがめっちゃ見やすい
**2つのActive Recordモデル同士のつながりを指す
- 主キー
- データベースにおけるレコードを一意に識別するためのカラム
- 外部キー
- 他のテーブルとの関連付けに使うキー
関連付けの種類を以下に示す
belongs_to- １方向1 : 1の関係
- 宣言を行ったモデルの各インスタンスは，他方のモデルのインスタンスに「従属」する
- 参照元テーブル → 参照先テーブル
- 外部キー(foreign key)が生成される
has_one- １方向1 : 1の関係
- 相手側の1つのモデルが自身のモデルへの山椒を持っている
has_many- 1 : 多の関係
- 多くの場合，
belongs_toの反対側で使われる
has_many :through- 多 : 多の関係
- ユーザーと商品とレビューの関係を例にする
- item → reviews(1:多)
- review → user(1:1), review → item(1:1)
- user → reviews(1:多)
- この時
item→review→userのようなアクセスをしなくても，has_many throughでitemから直接userにアクセスできる
has_one :through- 1 : 1の関係
has_many :throughと同じような感じ
has_and_belongs_to_many- 多 : 多の関係
:throughを指定した時と異なり，仲介モデルが存在しない
ここではRailsのテンプレートを表現するAction Viewについて記載している．
Details
Action ViewのテンプレートはHTMLファイルにRubyを埋め込むERB(Embedded Ruby)を用いる．
Railsがレンダリングする最終的なHTMLはテンプレート，パーシャル，レイアウトの3つの要素から構成される．
- ERB
<% %>タグや<%= %>タグの中にRubyのコードを書ける
- Builder
- ERBの代わりに利用できる，よりプログラミング向きな記法
- Jbuilder
- Railsチームによってメンテナンスされているgemの一つ
- Gemfileにデフォルトで含まれる
パーシャルはレンダリング処理を扱いやすく分割する仕組み
パーシャルを使うことでビュー内のコードをいくつものファイルに分割して書き出し，他のテンプレートでも使いまわせるようになる
RailsのDRY原則に従うために有効的に使う！
- 命名ルール
- パーシャルをレンダリングするには
renderメソッドを使う<%= render "header" %>のように使う- パーシャルのファイル名の冒頭にはアンダースコア
_をつける
- パーシャルをレンダリングするには
コントローラ側から見たHTTPレスポンスの作成方法は以下の3通り
render- 完全なレスポンスを作成してブラウザに送信する
redirect_to- HTTPリダイレクトステータスコードをブラウザに送信する
head- HTTPヘッダーのみのレスポンスを作成してブラウザに送信する
以下にそれぞれのレスポンスの詳細を記載していく
ほとんどの場合，アプリケーションがブラウザで表示するコンテンツのレンダリングにはコントローラのrenderメソッドが使われる
別のURLにリクエストを再送信するようブラウザに指示する
本文のないヘッダのみのレスポンスをブラウザに送信できる
ここではReilsのコントローラを表現するAction Controllerについて記載している
Details
コントローラはモデルとビューの間を仲介する
RailsのコントローラはApplicatioinControllerを継承したクラス．
Application ControllerはActionController::Baseを継承していて，便利なメソッドが多数定義されている．詳しくはここ参照．
コントローラのアクションでは，ユーザーから送信されたデータやその他のパラメータにアクセスすることになる．
パラメータには以下の2種類がある
- クエリ文字列パラメータ
- URLの一部として送信される
- URLの
?文字の後に追加される
- POSTデータ
- ユーザーが記入したHTMLフォームから受け取ることができる
いずれのパラメータもparamsという名前のハッシュでアクセスできる
Web上から受け付けたパラメータが本当に安全なデータかどうかを検証した上で取得するための仕組み．
- なぜ必要なのか
- 意図しないデータの登録・更新を防いでくれる
- セッションとは，アクセスの開始から終了までの一連の通信のこと
- Railsアプリケーションでは，ユーザごとにセッションを設定する
- セッションはコントローラとビューのみで利用できる
- サイトにアクセスしてから一定時間経過することで通信が終了し，これを「1セッション」としてカウントする
- Railsでは以下のようにさまざまなストレージを選べる
- ActionDispatch::Session::CookieStore : 全てをクライアント側に保存する
- ActionDispatch::Session::CacheStore : データをRailsのキャッシュに保存する
- ActionDispatch::Session::ActiveRecordStore Active Recordデータベースに保存する(gemが必要)
- Railsで推奨されているのはデフォルトのCookieStore Railsでセッションを実装する方法として最も一般的なのは，cookiesを使う方法．
- cookies
- ユーザーのブラウザに保存される小さなテキストデータ
- あるページから別のページに移動した時にも破棄されない
- ユーザーIDなどの情報を保存できる
- 攻撃者があるユーザーのセッションIDのコピーを手に入れてそのユーザーとしてログインする
- この手順はセッションリプレイ攻撃と呼ばれる
- 攻撃者が既にもっているセッションIDをユーザーに使わせるように仕向ける
- 攻撃者がユーザーとセッションを共有する
- ユーザーがログインする直前にセッションを必ず即座にリセットすることで対策可能
reset_sessionメソッドで可能
-
記憶トークン
- 記憶ダイジェストによるトークン認証に使用する
- パスワードとトークンの違い
- パスワード: ユーザーが作成・管理
- トークン: コンピュータが作成・管理
-
cookiesを盗み出す有名な方法
- 管理の甘いネットワークを通過するネットワークパケットからパケットスニッファというソフトウェアで直接cookiesを取り出す
- **TLS(Transport Layer Security)**を適用して保護する
- データベースに保存されている記憶トークンを盗み出す
- 記憶トークンをハッシュ値に変換して保存する
- *クロスサイトスクリプティング(XSS)*を使う
- Railsによって自動的に対策が行われる
- ユーザーがログインしているパソコンやスマホを直接操作してアクセスを奪う
- デジタル署名という暗号技術を使う
- 管理の甘いネットワークを通過するネットワークパケットからパケットスニッファというソフトウェアで直接cookiesを取り出す
フィルタはコントローラにあるアクションが実行される前後に実行されるメソッド
モデルのバリデーションと似てる
before_action :~- アクションを実行する前に処理する
after_action :~- アクションを実行した後に処理する
around_action :~- アクションを実行する前後に処理する
Railsには以下の3種類のHTTP認証機構が組み込まれている
- BASIC認証
- ダイジェスト認証
- トークン認証
認証スキームの一種で，主要なブラウザおよびHTTPクライアントでサポートされている
http_basic_authenticate_withメソッドを使うだけでこの認証メカニズムを利用できる
BASIC認証よりも高度な認証システム
暗号化されていない平文パスワードをネットワークに送信しなくて済む
authenticate_or_request_with_http_digestメソッドを使うだけで利用できる
HTTPの
Authorizationヘッダー内でBearerトークンを利用可能にするスキーム
authenticate_or_request_with_http_tokenメソッドで利用できる
ここでは，Railsで用いられる重要そうな概念(主観)について記載している．
Details
RubyにはDRYという原則がある．
重複してしまっている分はERBによって取り除く．
パーシャルとは，ビュー画面を共通化するために用いられる．
ビュー内のコードを各機能に分割して書き出し，他のテンプレートでも使い回すことができる機能．
- 使用方法
_header.html.erbのように先頭に_をつけたファイルを使う<%= render 'layouts/header' %>のように呼び出す
Railsでは，以下のような名前付きルーティングを使用するのが慣例
<a href="about_path">About</a>
<%= link_to "About", about_path %>上のコードは意味的には同じであるが，Railsでは下のコードを用いる．
これを用いることで，about_pathやabout_urlといった名前付きルーティングを使えるようになる．
詳細についてはRailsガイドを参照．
RailsのAsset Pipelineはデフォルトでは，LESSとよく似たSass言語をサポートする．
以下の3つの主要な機能が理解の対象になる．
- アセットディレクトリ
静的ファイルを目的に分類する標準的な3つのディレクトリが使われている．app/assets: 現在のアプリケーション固有のアセットlib/assets: 開発チームによって作成されたライブラリ用アセットvendor/assets: サードパーティのアセット
- マニフェストファイル
- Railsではアセットパイプラインの中で読み込み時間を減らすためにCSSやJSを連結している
- マニフェストファイルを使うことで，アセットをフォのように1つのファイルにまとめるのかをRailsに指示することができる
- 実際にアセットをまとめる処理を行うのはSprocketsというgem
- プリプロセッサエンジン
- 必要なアセットをディレクトリに配置してまとめた後，様々なプリプロセッサエンジンを実行して結合する
アセットパイプラインの最大のメリット
本番のアプリケーションで効率的になるように最適化されたアセットを自動的に生成できる!
- アセットパイプラインが全てのスタイルシートを結合して1つのcssファイルにまとめる
- それらのファイルに対して不要な空白やインデントを取り除く処理をする
- ファイルを最小化する
→ 開発環境と本番環境のどちらにもベストな環境を提供できる
Sassはスタイルシートを記述するための言語で，CSSよりも多くの点が強化されている．
Sassは.scssという拡張子が採用される．
Sassが提供する2つの重要な機能
- データの定義をRubyで記述することができる
- SQLのDDL(Data Definition Language)が必要ない
- DDL: データ定義言語と呼ばれ，SQLの命令(CREATE, DROP, ALTER...)などのこと
モデルのレコードを.destroyしても削除されたオブジェクトはメモリ上にまだ残っている
モデルのバリデーション機能はテスト駆動開発(TDD)の方が相性が良い 検証のよく使われるケースを以下に示す
- 存在性(presence)
validates :(変数名), presence: true
- 長さ(length)
validates :(変数名), length: { maximum: 50 }
- フォーマット(format)
validates :(変数名), format: { with: (正規表現) }
- 一意性(uniqueness)
- 確認(confirmation)
RailsのWebサイトでは，トラフィックが多い時に一意性の検証を行なっているのにも関わらず重複するレコードが作成されてしまうことがある．
このような問題に対してデータベース上のカラムにインデックスを追加し，そのインデックスが一意であるようにする．
- 検索(find)したい時インデックスがないとそのデータを上から全探索する必要がある
- このような方法を全表スキャンと呼ぶ
- インデックスがあると効率的に検索可能になる
インデックスを追加するには，マイグレーションする必要がある．
rails g migrate ~でマイグレーションを作成する．
ユーザー認証を行うときに必須なのがパスワード．
ユーザーの認証は以下のように進む．
- パスワードの送信
- ハッシュ化
- データベース内のハッシュ化された値との比較
セキュアなパスワードの実装は簡単で，モデルクラス内でhas_secure_passwordを呼び出すだけで良い．
呼び出すと以下の機能が使えるようになる．
- セキュアにハッシュ化したパスワードをデータベース内の
password_diget属性に保存可能 - 仮想的な属性(
passwordとpassword_confirmation)が使える - 存在性と値が一致するかのバリデーションも追加される
authenticateメソッドが使える(引数の文字列がパスワードと一致すればUserオブジェクトを返し，一致しなければfalseを返す)
ただし，has_secure_passwordを使えるようにするには，モデル内にpassword_digestという属性が含まれていなければならない
また，最先端のハッシュ関数であるbcryptライブラリが必要
- ログインの基本的な仕組み
- ブラウザがログインしている状態を保持
- ユーザーによってブラウザが閉じられたら状態を破棄する
このような制限や制御の仕組みを**認可モデル(Authorization Model)**という．
- テスト時に登録済みユーザーとしてログインしておく必要がある場合がある
- データベースにそのためのユーザーが登録されていなければならない
- Railsではこのようなテスト用のデータを**fixture(フィクスチャ)**で作成できる
- fixtureを使ってテストに必要なデータをtestデータベースに読み込んでおくことができる
test/fixtures/~.ymlに記載する．erbも使える．
- クラスメソッド: クラスオブジェクトから実行可能
def self.method_nameでクラスメソッドを定義def method_nameでインスタンスメソッドを定義
プログラムでプログラムを作成する
Rubyの極めて強力な機能．
-
そもそも_pathと_urlとは
- ヘルパーの一種
-
_path
- 相対パス
- redirect_to以外で使用する
- link_toでよく使用される
-
_url
- 絶対パス
- redirect_toの時にセットで使用する
- 第三者がSQLコマンドを悪用してデータベースの情報へ不正にアクセスし，情報を搾取や改ざん，削除する攻撃手法
-
アプリケーションのデータベース
-
以下の3つのテーブルを使う
active_storage_blobsactive_storage_variant_recordsactive_storage_attachments
-
Active Storage APIの中で知っておくべきもの
has_one_attachedメソッド- 指定のモデルとアップロードされたファイルを関連づけるのに使う
has_many_attachedメソッドもある
- referencesとは，カラムに保存できる型の一つで，外部キー(foreign_key)を作成する際に使用する
- 簡単に言うと，外部キーとは，主キーを参照するためのカラムのこと
hidden_field_tagについて
Turbo Streamsと呼ばれる部分を介して動作する
-
概要
- N件のデータ行を持つテーブルを全部読み出す -> 1回
- 別のテーブルから，上記のテーブルの各行に紐づくデータを読み出す -> 計N回
- よって合計でN+1回のクエリを実行する必要がある
-
解決策
- eager loading: あらかじめデータを取得しておく
- スタイルシート内に共通なパターンがあるときは要素をネストできる
例)
.center {
text-align: center;
}
.center h1 {
margin-bottom: 10px;
}
/* 上記をSassを使って書き換える */
.center {
text-align: center;
h1 {
margin-bottom: 10px;
}
}#logo {
...
}
#logo:hover {
...
}
/* 上記をScssを使って書き換える */
#logo {
...
&:hover {
...
}
}変数
- 冗長なコードを削除しより自由な表現を可能にするために定義できる
h2 {
color: #777;
}
footer {
color: #777;
}このように同じカラーコードが出てくる場合などは冗長的であるため，変数を用いて以下のように書き直すことができる．
$light-gray: #777
h2 {
color: $light-gray;
}
footer {
color: $light-gray;
}現代のアプリ開発では，データ設計は最も重要であると言える
一昔前まではプロセス中心アプローチ(POA:Process Oriented Approach)，つまりアプリの処理を中心に開発していくようにしていた．
現代の開発では，データ中心アプローチ(DOA:Data Oriented Approach)，つまりデータ設計を中心に開発を進めていく手法．
以下の3つのスキーマが存在する
- 外部スキーマ
- ユーザーから見たデータベース
- 概念スキーマ
- 開発者から見たデータベース
- 内部スキーマ
- DBMSから見たデータベース
概念スキーマはデータ独立性を保証するために存在するためにある
データベースの設計は論理設計 → 物理設計と進む．
概念スキーマを定義する設計を論理設計と呼ぶ
論理設計は以下のステップで進められる
- エンティティの抽出
- エンティティの定義
- 正規化
- ER図の作成
物理設計は，論理設計の結果を受けて，データを格納するための物理的な領域や格納方法を決める工程 物理設計は以下のステップで進められる
- テーブル定義
- インデックスの定義
- インデックスがなくてもDBは正常に動作する
- インデックスはDBのパフォーマンスを良くするためにある
- ハードウェアのサイジング
- データのサイズとハードウェアの性能の2種類考える必要がある
- ストレージの冗長構成決定
- 高い耐障害性を持つ必要がある
- RAIDという技術が用いられる
RAIDについて詳しく見る
Details
代表的なRAIDには以下のようなものがある
- RAID 0(ストライピング)
- データを複数のドライブに分散させて書き込む
- 単純に1本のデータを複数のドライブに分散させるだけ
- 1本でもドライブが壊れたら終わり
- 冗長性なし！
- RAID 1(ミラーリング)
- 同じデータを2本のドライブに並列に書き込む
- 単純に冗長性が2倍に上がる
- RAID 5(パリティレイド)
- RAID 0と同様にデータを複数のドライブに分散させて書き込む
- RAID 0との違いはパリティデータ(誤り訂正補正)も同時に書き込む
- 1本のドライブに障害が発生しても復元可能
- 同時に2本の障害が起こった場合は修復不可
- RAID 10(1+0)
- RAID 0とRAID 1の良いとこ取り
- 余裕があればこれが一番良い
- 必要なドライブの本数が多いためお金がかかる
バックアップには以下のような方式がある
- フルバックアップ
- 保存するデータ全てバックアップする方式
- バックアップに時間がかかる
- 差分バックアップ
- フルバックアップからの差分データをバックアップする方式
- 増分バックアップ
- 前回のバックアップからの差分データのみをバックアップする方式
一般的に使われるバックアップ方式は，
- フルバックアップ + 差分バックアップ
- フルバックアップ + 増分バックアップ
リカバリ設計はバックアップ設計とセットで実施されるもの
リストアとリカバリ
- リストア
- バックアップファイルに戻す作業
- リカバリ
- トランザクションログを適用して変更分を反映する作業