「GET、POST、キャッシュ、クッキー、セッションとは？」という人（自分）のためのメモ

表題の件、調べて理解できるものの、しばらくすると忘れてしまうのでメモとして残しておきます。 と言っても、他ブログからの引用（コピペ）オンリーです。 ブログ主様には感謝です。

キャッシュ、クッキー、セッション

Webブラウザ（パソコン）に保存されるもの

キャッシュ（ Cache ）⇒

何度も見るWebページがある場合に、2回目以降の閲覧時の表示スピードを上げるため、ページ内の画像やアイコンといったデータをパソコン内に保存する仕組み（またはその保存されたデータ自体）。

Webページまるごとの情報。

2回目以降はファイルのダウンロードをせずに、パソコン内にキャッシュ（貯蔵）されたデータでWebページを再現するため、表示スピードが早くなります。

クッキー（ Cookie ）⇒

Webブラウザ利用者の情報記録のこと。

記録される履歴情報は、ユーザーが入力したID、パスワード、そのWebページを訪れた日時、訪問回数など。

クッキーを使用しているサイトにアクセスすると、サイトの情報と一緒にクッキーファイルも利用者のパソコンにサイトから送信され、特定のフォルダに保存されます。

セッションクッキー（ Session Cookie ）⇒

Webブラウザのメモリーに保存されるもの。

Webブラウザを閉じれば破棄するようにできます。

履歴 ⇒

自分が閲覧したWebページのURL。

Webサーバーに保存されるもの

セッション（ Session ）⇒

パソコンに保存させておきたくない情報（ Session ）で、サーバーに保存されるもの。

Sessionの流れ

ユーザーが、Webページにアクセス（ WebサーバーにHTTPリクエストを送る。）。

⇩

Webサーバーは、

『セッションID』と 『セッション・オブジェクト（ セッションを管理するデータを書き込むためのもの ）』 を作り、Webページの情報（データファイル）と共にセッションIDをユーザーに返す。（ HTTPレスポンス ）。

⇩

この時にセッションIDをユーザーに渡す方法は３つあります。

Cookieに書き込んで リンクのURLに埋め込む Webページのフォーム・データに埋め込む ⇩

パソコンにセッションIDという値が保存され、これを基に次からのアクセス（ HTTPリクエスト ）はサーバー側に保存された情報（ セッション・オブジェクト ）を参照したやりとりを可能にします。

・「セッション管理」のすべて-ステップ1 ［基本のしくみ］　Webブラウザに情報を預けて，アクセス時に送信させる:ITpro

HTTPの仕組みとセッション

HTTPはステートレスなプロトコル（ 通信手順 ）です。

・セッション管理の周辺知識まとめ | PAYFORWARD

・yohei-y:weblog:ステートレスとは何か

ステートレス（ stateless ）

サーバーはクライアントのセッション情報を保持しません。

◯ メリット

クライアントのリクエストは状態に依存せず、常にリソースに対する操作に必要十分な情報となります よってサーバーが増えてもそのままのリクエストでいつも同じリソースに対する操作ができます このためスケールアウトに向いています また処理がクライアントの状態に依らないので処理がシンプルになります

☓ デメリット

やり取りが冗長になりがちです またリソースへの操作が必要になる度にそのやり取りを繰り返す必要があります これによりネットワークの帯域を消費し、処理も遅くなります サーバーが状態を保持していないのでエラーが起きたときのハンドリングが複雑になりがちです

ステートフル（ stateful ）

サーバーはクライアントのセッション状態を保持しています。

◯ メリット

やり取りが完結に済みます それによりネットワークの帯域を節約できます

☓ デメリット

クライアントの状態を都度把握しておかなければいけないのでクライアントが増えると負荷も増えます サーバーを複数台設置する場合にはそれぞれのサーバー間でクライアントの状態を同期しなければいけません これらの理由によりスケールアウトには向いてません

参考文献: キャッシュ（Cache）とクッキー（Cookie）とセッション（Session）など ~愛しさと切なさと心強さと~とは全く関係ない - ts0818のブログ

GET、POST

GETもPOSTも、サーバへのリクエスト方法という共通点はありますが、、、

GETとは

URLにパラメータが付加される。
文字数制限がある。
パラメータつきのURLを保存・共有できる。
→これによりブックマークも共有できる

POSTとは

パラメータが見えづらい。
文字数制限がない

どう使い分ける？？？

GETは情報を取得するとき、POSTは情報を登録するときの利用が適しています
例：
GET→検索フォーム
POST→ログインフォーム

参考文献: GETとPOSTの使い分け方法 | PHP Junkie

入社して2週間で参考にしたWebページまとめ

今の会社に入社して2週間

こんにちは、ヒロアキです。
今の会社に入社して2週間たちました。
自分の実力の低さを痛感した2週間でした。
今回は、業務中に参考にしたサイトなどを残していきたいと思います。
自身の記録という意味での記事なので、バリバリのキャリアの人には役立ちませんが、エンジニアを目指す人には参考になるかも……しれません。

業務中にメモした事まとめ

MySQL

・mysqldump
そもそもdumpとは　→　 https://wa3.i-3-i.info/word1569.html
mysqldumpコマンド　→　 mysqldumpまとめ

・GRANTコマンド
権限の設定(GRANT文) - ユーザーの作成 - MySQLの使い方

・SQLモード（SQLの動作指定）
MySQLのSQLモードをstrictモードで設定する。

Linuxコマンドなど

・PATHを通す
PATHを通すとは？ (Mac OS X)

・デーモン
https://wa3.i-3-i.info/word11000.html

・lnコマンド
【 ln 】コマンド――ファイルのハードリンクとシンボリックリンクを作る：Linux基本コマンドTips（16） - ＠IT

・wgetコマンド
【 wget 】コマンド――URLを指定してファイルをダウンロードする：Linux基本コマンドTips（24） - ＠IT

・pemファイル
[OpenSSL] pem ファイルとは？SSL証明書の中身を確認する方法|てくめも@ecoop.net

・scpコマンド
scpコマンド チートシート

Apache

・基本事項
WEB系の新人が困らないように基本を復習〜Apacheのインストール - 爬虫類嫌いのPython日記

便利な操作

・macを使う人はmacの、windowsを使う人はwindowsのショートカットキーを調べて使えるようにしておく
　→マウスを使うと生産性が落ちる場合があります。特にコピペ関連。

・ターミナルで履歴を調べたい時は「history | grep 調べたいコト」
　→だいたいの見当がついていれば「ctl+r」の方がそのまま実行できて楽

・/etc以下のファイルをいじくる時は、不安であれば、cpコマンドでバックアップをとる
　→最後に「.org」をつけるなど

gitコマンドのまとめ

メモ git

個人的な話

こちらのブログを更新するのは、超久々です。笑

色々とありまして、業界完全未経験ですが、2018年10月から自社サービス系の企業様のもとで働くことになりました。 （このブログは、自分のメモを残しておくために使うことにしたので、一番最初の記事以外削除しました。）

一般的には(？)、未経験から自社サービス系の企業に転職するのは所謂「成功」なのですが、もし試用期間で切られたら恥ずかしいので(笑)、「どういう風に転職活動をしたか」みたいな講釈を垂れるつもりはまだありません。

（そういう話はtwitterのDMで承ります→　ヒロアキ@twitter）

本題

今回は、タイトルにもあるように、gitコマンドを自分なりにまとめようと思います。　　 理由は、「入社前に復習しといて」と言われたのと、未だにググりながら使うことが多いからです。
一応、udemyで講座を修了したのですが、やはりアウトプットしないと覚えませんね(^^;)
という訳で以下にコマンドと、gitの注意点がつらつらと続きます。
完全に自分用のメモなので、qiitaの記事とか見た方が分かりやすいと思います。笑

git init  //空のgit repositoryが作成される

git remote add <remote name> <repository URL>  //<remote name>というショートカットで、URLのリモートリポジトリを登録する
git remote show <remote name>  //リモートリポジトリの確認 
git remote rename <old name> <new name>  //リモートリポジトリの名前を変更する

git push --delete <remote name> <branch name>  //リモートブランチを削除する
git remote rm <remote name>  //リモートリポジトリを削除する

git clone <repository URL>  //URLのリモートリポジトリのコピーを作成する

git add <change file>  //変更をステージに追加する

git commit -m "<message>"   //変更を記録する（メッセージを書く）
git commit -v  //変更を記録する（エディタで記録）

git status  //変更されたファイルを確認する  
git status -sb  //上記の簡易表示版  

git diff  //変更差分を確認する（git addする前のファイルのみ。)  
　　　     //後ろにファイル名を付ければ、そのファイルのみの差分を確認できる）  
git diff --color-words  //変更差分を確認する（より細かい単位で）  
git diff --staged  //変更差分を確認する（git addした後のファイル）


git log --oneline  //一行で、変更履歴（コミットメッセージ）を確認する  
git log --graph  //ツリー状（？）にコミットログを表示する  
git log --stat  //変更ファイルの表示
git log <commit ID> -p <file>  //ファイルの変更履歴を確認する  
git log -n <number>  //表示する履歴数を指定する  
git log <remote>/<branch>  //remoteのbranchのコミットログを確認する

git rm <file>  //ファイルの削除を記録する
git rm --cached <file>  //リポジトリにあるもののみ削除（ワークツリーは削除されない）

git mv <file>  //ファイルの移動を記録する

git push <remote name> <branch name>  //ローカルリポジトリの内容をリモートリポジトリに送信する、ローカルブランチをリモートリポジトリのブランチとして追加する

git pull <remote name> <branch name>  //リモートリポジトリの内容をローカルリポジトリとワークツリーにコピーする

git checkout -- <file>  //ファイルの変更を取り消す。git addする前におこなう。  
git checkout <commitID> <file>  //特定のコミットまでファイルの状態を戻す。  

git clean -n  //Untracked filesを削除するのに使う。-nオプションは、ファイルの確認のみで実際には削除しない。  
git clean -f  //Untracked filesを削除する。ディレクトリも削除する場合は、-fdとする。  

git reset HEAD <file>  //git addしたファイルをステージから消す。ワークツリーになされた変更はそのまま。
git reset --soft HEAD^  //直前のコミットを取り消す
git reset --hard <commit ID>  //特定のコミットに戻す  

git commit --amend  //直前のコミットを修正する。  
　　　　　　　　　　　//viで編集します。
git commit --amend -m "<commit message>"  //上記と同じ意味

git rebase -i HEAD~数字  //2つ以上前のコミットメッセージを修正する時に使用。  
　　　　　　　　　　　　　  //viが立ち上がるので、修正したいコメントのpickをeditに変更後、  
　　　　　　　　　　　　  　//git commit --amendで修正　→　git rebase --continue（複数修正する場合は、都度git rebase --continueする）  

git branch  //ブランチの表示
git branch <branch name>  //新しいブランチを作る

git branch -m <new branch name>  //自分が作業しているブランチの名前を変更する。
git branch -d <branch name>  //ブランチを削除する。

git checkout <branch name>  //ブランチの切り替え
git checkout -b <branch name>  //ブランチの新規作成と、そのブランチに切り替え

git fetch <remote name> <branch name>  //リモートリポジトリのbranch nameの内容をローカルリポジトリにコピーする

git merge <branch name>  //branch nameの内容を現在のブランチに合流させる
git merge <remote name>/<branch name>  //git fetchしてきたブランチを現在のブランチに合流させる

git rebase <branch name>  //現在のブランチの基点となるコミットをbranch nameに変更する  

git cherry-pick <commit ID>  //commit IDのコミット分の変更のみ現在のブランチに取り込む  

git tag  //タグの一覧を表示する
git tag -a -m "<message>"  //現在のブランチの最新のコミットに、署名などの情報付与型のタグの作成
git tag <tag name>  //現在のブランチの最新のコミットに、タグの作成
git tag <tag name> <commit name>  //コミットにタグを後付けする

git show <tag name>  //タグの詳細内容を表示

git push <branch name> <tag name>  //タグをリモートリポジトリに送信する
git push <branch name> --tags  //全てのタグを送信する

git stash  //現在、変更しているファイルを一時的にステージ・ワークツリー上から避難させる
git stash save <message>  //コメント付きで避難させる
git stash -u  //追跡していないファイルも避難させる  
git stash list  //避難した作業を確認する

git stash apply <stash name>  //避難させた作業を復元する。EX-git stash apply stash@{0}

git stash drop <stash name>  //避難させた作業を削除する
git stash clear  //全作業を削除する

git revert <commit ID>  //git pushした後のコミットを打ち消すコミットの生成。これの後にpushし直す。  
git revert -n <commit ID>  //コミットを伴わないgit revert（通常ではgit revertした直後にコミットが生成される。注意点として、この後コミットするファイル群が打ち消される。コミットしないのはそのままリポジトリに残る）

※注意点
・git pullは基本的に使わない。
　→取得するリモートリポジトリのブランチがローカルリポジトリの異なるブランチを上書きしてしまう場合がある。

・コンフリクトしたらファイルの中身を書き換えるか、「>>>」「===」「<<<」を消去する。
　→git add
　→git commitで解決

・そもそもコンフリクトが起きないようにするには、、、
　→複数人で同じファイルを編集しない。
　→pull , mergeの前にcommit , stashをしておく。
　→pullする時は必ずgit branchする

・git pushしたコミットをgit rebaseしない
　→やってしまうと、push出来なくなる
　→pushする前はrebaseを使い、した後はmergeするとコンフリクトを防ぎ易い

・基本的な開発手順
　・git cloneをする
　→branchを確認する（git branch）
　→開発用に新しいbranchを切って、移動する（git checkout -b branch name）
　→不安だったら移動先のbranchにいるか確認（git branch）
　→リモートリポジトリにbranchを追加（git push remote name branch name）
　→その状態のままコードを書く
　→addしてcommitする（git add, git commit）
　→自分の担当部分が終わったらpushする（git push remote name branch name）
　→Pull Requestを出す
　→mergeされたのを確認したら初めのbranchに戻る（git checkout branch name）
　→localでいままで作業していたbranchを削除する（git branch -d branch name）
　→他の人の開発分を取り込む
（git fetch remote name branch name, git merge remote name/branch name）

・以前のコミットに戻るやり方

　$ git log --oneline //戻りたい位置のコミットIDの探査
　$ git show <commit ID> //コミットIDの確認
　$ git reset --hard <commit ID> //指定したコミットIDまでバックする

・エイリアス

che = checkout
bra = branch
sta = status
glog = log --graph
log5 = log -n5 --oneline --graph
log10 = log -n10 --oneline --graph
cb="git rev-parse --abbrev-ref HEAD"

cb="git rev-parse --abbrev-ref HEAD"の詳細は 退屈なgit commitの定型文はGitフックにやらせよう - Qiitaを参照してください