JSONPマダマダツヅキマスヨ。
前回、XSS攻撃を避けるためにも、クライアント側でパースしよう書きましたが、まだまだ謎が多いので書きます。
jsonの場合、
application/jsonです。text/javascriptではない！
jsonpの場合、
実体はcallback関数でJSONを包んだJavaScriptなので、MIMEタイプはJavaScriptと同じでapplication/javascript
text/javascript → application/javascript (2006年4月RFC4329)
text/htmlとかtext/javascriptとかにしてるとhtmlと解釈してしまい、悪意あるスクリプトが仕込まれている場合、実行されていまします。→XSSの攻撃を受ける
content-typeを正しく記述することは重要！！
しかし、IE6だと、application/jsonとしていてもhtmlとして解釈してしまうようです。
jsonpの仕組みって、コールバック関数を使ってサーバから受け取るデータにscriptとしての役割を持たす。
callback関数と同じ名前の関数の引数にJSONが入ったスクリプトを返すようクロスドメインのサーバーにリクエストし、
動的にそのスクリプトを読み込んだ瞬間にcallback関数が引数にJSONをつっこんだ状態で呼び出される。
ajax(つまりはXMLHttpRequest)って便利ですよね。
異なるドメインにアクセスはできない=クロスドメイン制約
を除いては・・・・。
しかし、JSONPを使うと、なぜ異なるドメインのデータを取得できるのでしょうか？
そんな疑問からのJSONとJSONPの違いを調べました。
参考：ここ
JSON = JavaScript Object Notation
JSONP = JSON with Padding (Padding=不要なもん)
→つまりJSONPはJSONではない！！！
JSONPの仕組み
<script src=”https://google.com/test.js”></script>
//変数data に “グーグルからのメッセージ”;が挿入されるとする。
<script>
alert(data); //「グーグルからのメッセージ」がアラートされる。
</script>
スタイルシートやjQueryライブラリーを呼ぶのもクロスドメインじゃん！そうじゃん！と気付いた次第です。
クロスドメイン制約って簡単に回避できるやーんって、楽勝って感じですよね！
これって、データ取得先(上記例で言うとgoogle.com)に
自サイトでの実行権を与えっちゃってるんです！
もしも、dataと言う変数に無限アラートが仕込まれてたらどうしょうか？自分は何も実装していないのに、観覧者に不快な思いをさせてしまう可能性があるのです。
こういったXXS攻撃を避けるために、
１.JSON.parse()をしましょう！
JSON.parse()
※JSON,JSONPはオブジェクトのためJSON.stringfy()で文字列にしたのち、JSON.parseしましょうね！
２.JSONP使うのやめましょう！
じゃあ何使えばいいんや！教えてください。
viewport
ってスマホ対応の時使うレスポンシブル対応のやつだな、
っということしかわからなかっための勉強します！
参考：http://ichimaruni-design.com/2015/01/viewport/
結論
<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0">
width=device-width ： 幅をデバイスごとにサイズを切り替えてくれる！
initial-scale：初期のズーム倍率
※device-width ⇄ 初期のズーム倍率が 1 になる。(initial-scale=1.0)
minimum-scale=1.0とすることで最小倍率を指定しているが、初期ズーム倍率と等しいため、縮小できない状態。
なぜ、縮小できなくするのか謎・・・。
Yahoo!の天気サイトもしてた・・。これ↓
<meta name=”viewport” content=”width=device-width,initial-scale=1.0,maximum-scale=1.0,minimum-scale=1.0,user-scalable=no”>
user-scalable=noってしてるのに、拡大できるやん？なんで？
と、思ったらいろんなサイト比較してるとこ発見！
しかし、よくわからない。
maximum-scale=1.0,minimum-scale=1.0,user-scalable=no
ってどうなれば正しい挙動なの？
<meta name="viewport" content="width=960(コンテンツの大きさ)">
これすれば、横の余白がなくなる。
シーケンスって便利ですよね。
SQLでもできるし、phppgadminを使えばGUIでも操作できる！
しかし、シーケンス設定っていまいちよくわからないのでまとめます。
phppgadminでシーケンスを作成しようとするとこんな画面がでます。
名前：シーケンスの名前をつけます。
よく見るのは「 テーブル名_カラム名_seq」ですね。
増加数：直前の数値からいくつ増加するか。
最小値：デフォルトは1。
最大値：MAX値
開始値：デフォルトは最小値と同じ。
キャッシュ値：メモリに格納しておくシーケンス番号の量を指定します。
これによりアクセスを高速にすることができます。
最小値は１(デフォルト)
Can cycle?：番号が最大値を超えた場合に最小値に戻るかどうか。
「いいえ」(デフォルト)が指定された場合、シーケンスの限界値に達した後の
nextval呼び出しは全てエラーになる。
ログカウント：わからん！誰か教えてください。
Will increment last value before returning next value (is_called)?：
訳）次の値を返す前に最終値を増加しますか？
例えば、
増加数：1
最小値：1
開始値：1
Will increment last value before returning next value (is_called)?：いいえ
このシーケンスは１から始まり、2,3,4,….と１ずつ増加します。
１.「リセット」をクリック。//最終値が１となる
２.「Restart」をクリック。//Will increment last value before returning next value (is_called)?が「いいえ」となる
SELECT setval (‘シーケンス名’, 1, false);
第２引数：最終値
第３引数：値を返す前に増加させるか<</Will increment last value before returning next value (is_called)?>> true(増加する)/false(増加させない)
タイトル通りです！
ネストのルールって難しいです。
ulにネストしていいのはliだけなのに、liの中はなんでもネストしていいとか・・・。
HTML5以前では、ブロック要素やインライン要素を使ってのルールがありました。
HTML5からブロック要素インライン要素といった分類がなくなりました。
そのかわり(？)としてコンテンツモデル
という概念ができました。
コンテンツモデル：各要素が内包できるコンテンツ
HTML要素は、0個以上の以下カテゴリーに属しています。
これにより
今まで「インライン要素」と呼んでいた要素が
フレージングコンテンツとなったようです。
本題に戻ると・・・
a(アンカー)要素の仕様を見ると、
コンテンツモデル…..transparent(透過)
↑親要素のコンテンツモデルがそのまま継承されるという意味
例えば、
<p>
<a href=”#”>リンク</a>
</p>
・a要素の親はp要素である。
・p要素のコンテンツモデルはフレージングコンテンツである。
→a要素にネストできる要素は
<span>,<a>,<img>といった、フレージングコンテンツとなる。
また、
<div>
<a href=”#”>リンク</a>
</div>
・a要素の親はdiv要素である。
・div要素のコンテンツモデルはフローコンテンツである。
→a要素にネストできる要素は
メタデータコンテンツの一部を除いたほぼすべての要素となる。
タイトルの通りです。
Gitが苦手なもので、とりあえず、stashしちゃうんです。
んで、必要な時にstash popしてます。便利ですよね〜\(^^)/
超便利と感じつつ、stashをどんどん貯めていくのですが、
結局、使わず、溜まってくばかりなのですが。
git stashってインデックスにあるもの(git addしたやつ)をstashします。
作業ツリーのものはstashしてないのです！
「だからたまに、"stashしたはずなのに、あのファイルがない！"とかなってたんだ・・・。」
作業ツリーからインデックス(git add)にあがることにより、
追跡(tracking)が開始されるのです。
よって、git addしなければ、バージョン管理外なのです！
作業ツリーがダーティ(クリーンではない状態)の時は、
stashしたいものをaddして追跡を開始させたのちに、
git stashを実行すること！
Webに携わってもう直ぐ1年。
Webサイトをいじる中、スペルミスや設定ミスでエラーをよく見てきたのですが、
ヘッダーのstatus codeを見て、404の場合はパスが間違ってんのかな〜、
500番台に場合はPHPのコードスペルミスでのしたのかな〜とか確認してます。
しかし、このくらいしか分かりません。
この前、406エラーがでて、なにこれ！？ってなったので覚書します。
406 Not Acceptable 受理不可 Webサーバからクライアントへのレスポンスに、クライアントが受理できないデータが含まれている場合に発生する。
だそうです。
例）サーバはapplication/jsonを送信したかったが、リクエストのAccept:ヘッダにapplication/jsonが含まれていなかった。
まとめ
リクエストは受け入れられ、処理は継続
リクエストは正常に受け取られ、受理された。
リクエストを完了するためには、他のURL等を参照する必要がある。
クライアント側のエラー
サーバー側のエラー
参考：ここ
DRY
＝Don’t Repeat Yourself
直訳すると「繰り返すな。」という意味です。
同じような内容のコードが重複していると、
変更際、重複の数だけ変更しなければなりません。
また、いざそのコードを使う時に、どれを使えば良いのかわからなくなります。
同じようなコードは一箇所にまとめとけ！同じようなコードは何度も書くな！
→再利用性の高いコードを書く必要がある。
この原則を守ると、シンプルで保守しやすいコードが書きやすくなるとのことです。
「シンプルなコードを書きたい！！」
関連している原則：
・Once and Only Once（OAOO）一度、ただ一度
・OCP 開放閉鎖の原則
・SRP 単一責務の原則