スワップファイルシステム

　アプリを作って本番環境にデプロイしながら制作をしていたら、ある日デプロイができなくなっていた。エラーコードを見ても初めて見るものばかり。しかし、そこには日本語で「メモリ不足」と書かれている箇所があった。

　このわずかな手がかりを基に「メモリ」という秘宝を探すため、隊員たちはネットの海に調査へ向かったのである…

　と言う感じで、このメモリ不足のエラーを解決するにはスワップファイルシステムを導入すればいいと言うことがわかりました。

●スワップファイルシステム

https://begi.net/read/base/09.html

　要約すると、メモリ不足を補うために、ハードディスクに仮想メモリを作って活用するシステムということ。HDではメモリの素早い処理はできないので、メモリが演算に使わないデータ容量の物置を作る。そして、メモリさんが手に抱えている荷物の一部を物置で預かって、仕事が捗るように手助けするっていうこと。

　これを以下のQiitaの記事を参考に実装したらエラーが解決できた。●CapistranoでEC2へデプロイ：EC2仮想メモリ不足トラブルシュート

https://qiita.com/HrsUed/items/c156ed69e927b6165717

ありがとうございました。

CSSとSassの違い

●CSS…Cascading Style Sheet。Cascadeは滝。滝のように上から順に読み込んでスタイルプロパティを適用していくってことかな。

　Require_Treeで同一ディレクトリ内を参照している。アセットパイプラインを使ってCSSファイルを一つにまとめて、HTMLに適用している。

●Sass…CSSの進化版。セレクタのクラス名を階層的に入れ子構造で指定できる。また、プロパティを変数化できるので、プログラミング的にCSSプロパティを当てられる。

　メソッドとして@importを用意していて、これをapplication.scss で読み込んでHTMLに適用している。（パーシャル化）

※　@importは上から順番に見込んでいくので、Reset.cssとか、カラー指定をするscss、clearfixなど変数化を定義しているファイルは上部に記述していないと、適用されずに読み込まれてundefined_method とエラーになって困ることがある。注意。

＜入れ子構造＞

 .parent.child { color: white; }
 .parent.child.grandchild { color: blue; }

                 ⬇︎
 .parent {
    .child { color: white;
       .grandchild { color: blue;
       }
    }
 }

 　このように書けるので、プロパティの継承が簡単になる。記述量が減る。流れでCSSを見やすくなる。

＜変数化＞

 $section-color: rgb(255,255,255);
 @mix-in clearfix() { 
             clear:both;
             content:"";
             display: block;  }

 　このように変数化すれば、section-colorを新たなプロパティとして利用できる。clearfixをHTMLで利用できる。

こんな感じかな。まとめました。Sassのapplication.scss内の記述順は大事だから覚えておこう。

備忘備忘。

正規表現とは

正規表現とは…異なる形式の文字列を統一した形式で表現するための方法である。

例えば…　090(1126)1515　→　09011261515

                  090-1126-1515   →    09011261515

このように二つの書き方で表された電話番号を統一した書式で表現し直す。これが正規表現である。種類をまとめると

①　文字列の一部を置き換え（"ー"を空文字に置き換えるなど）

②　文字列に制約をもたせる（電話番号のように3-4-4の文字数以外の文字列は受け取らないように制約をつけるなど）

③　文字列の抽出（メアドからドメイン名のみを抽出するなど）

＜使い方＞

パターン表現（メタ文字「. / ^ / [a-z] / \d 」など）で文字列を抽象化して、条件に当てはまる文字列を抽出し、取得・更新していく

＜正規表現のメリット＞

●　文字列の検索・置き換え・抽出する際に便利である

●　他言語でも共通する運用ができて汎用性が高い

●　他言語で書かれたプログラムも転用できる

以上、正規表現の知識をまとめました。備忘備忘。

非同期通信とは

　まず、同期通信とは全てのHTML・CSSを読み込んでページを更新する処理のことを言う。だから時間もメモリもかかる。

　対して、非同期通信とは全て更新するのではなく、HTMLの一部分のみをJavaScriptで抽出し、変更をサーバーに送って、返ってきたHTMLをJavaScriptで更新する処理のことを言う。だから短時間で軽く行える。

　また、一部分のみをサーバー通信するので、それ以外の機能を動かすことができる。ということで、同時並行で機能を実行できると言う点でも意味がある機能である。

＜流れ＞

①ブラウザでJavaScriptが発火

②ajaxで指定した、URLのアクションを動かすリクエストを、データTYPEに合わせて非同期にサーバーへ送る

③サーバーに送られた情報を使って、jbuilderでjson形式のデータを作る

④コントローラでjsonの情報をViewへ送る

⑤データを受けたらブラウザで、DOM機能※(DocumentObjectModel)を基にして、部分的にHTMLを更新する

※DOMとは…JavaScriptがHTMLの読み込み、セレクタとして利用できるようにするための仕組み。HTMLをタグやクラス名など毎に区切って場所を特定できるようにしている。

以上。非同期通信とは何か、端的に言えるようにしたもの。備忘備忘。

Webサーバとアプリケーションサーバーの違い

本番環境のサーバーは二つに分かれる。静的なレスポンスを担当するWebサーバーと動的なレスポンスを担当するアプリケーションサーバーである。

●Webサーバー

　ユーザーから来るリクエストには、演算処理が伴わない静的な処理がある。例えば、自己紹介ページの表示など、固定された内容で変動がなくページの表示がされるものなどである。

　こういったレスポンスは簡単に処理ができるのでアプリケーションサーバーを起動するまでもない。即座に返す。それを担当するのがWebサーバーである。アプリケーションサーバーの手前にあって、簡単な処理をチャチャッとやってくれるのがWebサーバーだと思えばいい。

「NginX」とかね。

●アプリケーションサーバー

　ユーザーから来るリクエストには、演算処理が伴う動的な処理がある。パラメータのやり取りをする処理を主に言う。例えば、ユーザーが入力した身長や体重や年齢などの情報を計算してBMIや健康アドバイスを毎回変動して表示するアプリとか。ツイートを投稿してDBサーバーにアクセスして保存するアプリとか。

　そういう複数の機能を連動させてパラメータのやり取りをする処理は、アプリケーションをきちんと動かして処理する。だからこれを担当するのがアプリケーションサーバーという。

「Unicorn」とかね。

以上。本番環境の二つのサーバーの意味の違いでした。

問 . テストはなぜ書くのか説明せよ

＜テスト＞

　プログラムが意図した動きになるか確認するために作るもの。事前にバグがないか確かめることができる

＜メリット＞

●仕様漏れを防ぐ（テストで動作の洗い出しをする）

●リファクタリングしやすい（テストを書いておけば、リファクタリングして挙動がおかしくなってもすぐに気づける）

＜テストを書く原則＞

①各exampleで期待の値は一つだけ

②期待値ははっきりとわかりやすく

③起きて（ほしい／ほしくない）の両方をテストする

④境界値をテストする（６字バリデーションなら5字と６字の両方をテストして確認する）

⑤可読性を意識して適度にDRYに書く（※わかりやすさ優先）

＜種類＞

●単体テスト…一つのプログラムに対するテスト（ex:コントローラの投稿機能一つにつきテスト・商品購入機能一つにつきテストなど）

□Rspecのテストとか、Factory_botのダミーインスタンス作りとか

●統合テスト…複数の連動するプログラムに対するテスト（ex:ユーザー新規登録テストだと「入力」→「送信」→「保存」→「ログインして投稿できる」という一連の流れができるかをテストする。）

□Capybaraとかでこの一連のサンプルを試してくれる

以上。テストの意義でした。備忘備忘。

DB設計の正規化 メリットとデメリット

DBを作成する際には、データの関連性や重複保存などで問題が起きて後から構成のやり直しにならないよう、事前にきちんと設計する必要がある。そこで出てくるのが「正規化」の考え。これをきちんと自分の知識にするためにまとめよう。

●なぜ正規化が必要か

　「データが壊れないようなDB設計にするため」

　DBに保存したデータがDBの構成のせいで壊れてしまうことがありうる。DBの外部化をしていなかったせいで、一つしかないカテゴリのデータを削除したために、それ以降そのカテゴリはなかったものとなってしまう。これはデータが壊れると表現できる。これを防ぐためにきちんと設計を行う。

①第一正規形

　重複する情報をなくす。

　レシート情報のように一つの会計の中に複数の取引がある時、行の中に細分化された行が必要になる。この重複した形はDBでは再現できないので、横一列に表現できるようにしないといけない。レシート番号などの重複する情報は分割したり、合計金額などの算出できる情報は無くしてしまう。

 　また、ある生徒の履修データで、class1,class2,class3.......と一人の生徒情報の行に対してClassのカラムを延々と追加していく構成のDBはよくない。Classテーブルを別に作って、意味合いの重複するカラムをなくす。

②第三正規形（第二も含む） 

　複数の行で重複するレコードは、それが更新されたら全ての行のレコードを書き直さなければいけない。下の例で言えば、Mathを正しくMathmaticsに直す必要が出た時、たろうと三郎のレコードを一個ずつ直す必要がある。それは面倒。複数の行でダブっているレコードは別テーブルにまとめて、アソシエーションで呼び出せるようにする。そうすれば、変更も一度で済む。

　また、ジローが退学したとすると、Englishの授業もなくなる。強化としてなくなることはないのに、ジローに連動してデータが壊れてしまうことになる。これを防ぐためにもClassは独立したテーブルでデータ管理をしなくてはいけない。

 

　はじめに使ったレシートのDBを第三正規形に直すなら

　このようにテーブルを３つにわけて考える。

●正規化のデメリット

　第三正規形のようにテーブルを分割していくと問題もある。テーブル数が増えるとそれだけSQL（データベース言語）への実行アクセスが増えるので処理が重くなる。

　例えば、上記の会計データのDBでは、商品の在庫数とかの管理はしていない。が、もし作るとしたら、入荷数の値さえあれば、販売数をひいて算出できるので、わざわざ在庫数のカラムを作る必要はない。（第一正規形の考え）でも計算処理があるので、そこで処理が重くなる。もし在庫数カラムを作っておけば、そこからデータを取るだけなので処理は軽い。

　処理速度以外にも、テーブル数が増えればそれだけ管理は見辛くなる。

　これらのデメリットがある。この側面を踏まえつつ、ちょうど良いデータベースの設計をしていくのである。