HTTP レスポンスステータスコードについて調べてみた

こんばんは、有村です。
今日はHTTP レスポンスステータスコードについて学んだので、メモとして残します!

そもそもHTTP レスポンスステータスコードとは。

HTTP レスポンスステータスコードは、特定の HTTP リクエストが正常に完了したかを示します。
レスポンスは情報レスポンス、成功レスポンス、リダイレクト、クライアントエラー、サーバーエラーの 5 つのクラスに分類されます。

だそうです。
引用元:https://developer.mozilla.org/ja/docs/Web/HTTP/Status

それぞれ、
100番台 … 情報レスポンス
200番台 … 成功レスポンス
300番台 … リダイレクト
400番台 … クライアントエラー
500番台 … サーバーエラー

その中から、よく見るな〜というものを簡単にかいつまんでみました。

200(OK)
リクエストが成功した。

301(Moved Permanently)
リクエストされたリソースのURIが変更された。

302(Found)
リクエストされたリソースのURIが一時的に変更された。

403(Forbidden)
クライアントにコンテンツのアクセス権がない。

404(Not Found)
リクエストされたリソースを発見できない。

500(Internal Server Error)
サーバ側で処理方法が分からない事態が発生した。

503(Service Unavailable)
サーバがメンテナンスや過負荷でダウンしているなど。

504(Gateway Timeout)
ゲートウェイとして動作するサーバが時間内にレスポンスを得られない。

番号と内容だけではなく、名前も覚えたほうがいいよ〜とのアドバイスをいただいたので、
それも含めて頭に叩き込みたいと思います!

それでは、きょうはこのへんで。

sessionStorage使ってみた

こんばんは、有村です。
今日のテーマは、sessionStorage使ってみたです!

sessionStrageってなに?という疑問については、
我らがMDN様のリンクを。

さっそくサンプルコード!

一度ボタンを押すと、リロードしても「メッセージ切り替え済み」に表示が切り替わるようになっています!
バナー表示などの切り替えに応用できそうですね!

ただsessionStrageは、タブやブラウザを閉じると消去されるのが注意点です。
「ユーザが非表示ボタンをクリックしたら、未来永劫ずーっとバナーを非表示にしておきたいな…」という実装には向きません><

それでは、きょうはこのへんで。

mouseoverとmouseenterの違いって?

こんばんは、有村です!
あけましておめでとうございます。
2018年も、実装にて気付いたことや引っかかったこと、備忘録としてゆる〜く更新していこうと思うので、よろしくお願いします。

さて、今回はmouseoverとmouseenterの違いって?です!
癖でmouseenterって書くようにはしているんですけど、この両者の違いって明確にはなんだっけ…と分からなくなったので、
調べることにしました!

こんなコードがあったとします。
mouseoverもmouseenterも、どちらもdivに対して設定されていますね!

私はこう思いました…
ログが出力されるタイミングは、どっちも同じじゃないか?と。

しかし、実際にやってみると…
divエリアにマウスが入る → mouseover、mouseenterが反応する
aエリアにマウスが入る → mouseoverが反応する
aエリアを離れる(見た目としてはdivエリアに入る) → mouseoverが反応する
という全然違う結果になりました。

でも考えてみるとおかしい…自分はdivエリアに対してイベントを設定しているのに、なぜaに関するイベントを拾っているのか?
彼らは親と子の関係ではあるけれど、なぜ………………はっ。
バブリングか!?
なるほど、aの要素にマウスが乗ると、そのイベントがdivにも伝搬している…いうことですね。

ではmouseenterの場合はそうではないということでしょうか…
と思って調べました。
https://developer.mozilla.org/ja/docs/Web/Events/mouseenter
我らが守護神のひとり、MDN様はこうおっしゃっています。

Similar to mouseover, it differs in that it doesn’t bubble and that it isn’t sent when the pointer is moved from one of its descendants’ physical space to its own physical space.

残念ながら日本語訳がなかったのですが、なんとなくmouseenterはバブリングしないということが読み取れます。
また、子孫から自身にポインタが移動したときにはイベントが発生しない、という点もmouseoverとの違いですね!
(訳間違ってたらすみません;)
だから「aエリアを離れる(見た目としてはdivエリアに入る)」の場合、mouseoverしか反応しなかったんですね。
納得。

活用シーンを考えると、mouseenter一択じゃないか!?と思ったのですが、

With deep hierarchies, the amount of mouseenter events sent can be quite huge and cause significant performance problems. In such cases, it is better to listen for mouseover events.

とあるので、これまた使い所は考えたほうがいいということですね!

それでは、きょうはこのへんで。

return falseの罠

こんばんは、有村です。
2017年ももう終わりますね。早いものです。

さてさて、今日のテーマはreturn falseの罠です!
さっそくコードサンプルを。。。

hogeとfuga両方とも、クリックでalertが出るというコード。
fugaをクリックした時は、バブリングによって「fuga → hoge」とアラートが出るようになっています。

ん?なって…います……?

実際にはこのコードだと、fugaクリック時には「fugaしかalertが出ない」となってしまいます!

ここで私はひっかかりました。。
このfuga、a要素本来の動き(リンク)を殺したくてreturn false;をつけているのですが、
return false;によってバブリングまで死んでしまって、
本来「fuga → hoge」とクリックイベントが伝搬するはずが、fugaで止まってしまったんですね…。

おさらい。
return false;って何をしているのか。
preventDefault(要素のイベント、つまりaだったらリンクのイベントをキャンセル)
stopPropagation(バブリングをキャンセル)
この2つが行われる。

なので、もしa要素本来の動きを殺したいだけであれば、

と書くべきだったのですね;;

return false;は便利なんですけど、たまにこのようなひっかけがあるので、
「何をキャンセルしたいのか」を常に意識することが大事だな〜と思いました!

それでは、きょうはこのへんで。

thisを出力してみた

こんばんは、有村です!
今回はふと気になったのでこれを実践してみました!!

thisを出力してみた

です!
よくJSerの先輩から、「thisがそいつ自身を指すのはjQueryだから」と聞いていましたが、
じゃあjQueryではない生のJavaScriptだと何を指すんだろう…と疑問に思った次第です。

ただ、「どういう仕組みなん?」というところまでは理解が追いつかなかったので、
そこに関しては全く意味をなさない記事だと思います…。あくまで備忘録で。

さっそく実践。

その結果はというと…

わー!Windowって出た!
window…グローバルオブジェクトですね。
「これ」を指すのだから、「hoge」自身が返ってくると予想したのですが…(jQuery信者)

じゃあこういったケースはどうなるんでしょうか…

実行すると、なんと!!

と出ます!
thisの向き先が変わりました!!

なんとな〜く、こういうこと?と感覚で掴んでいることとしては、
hogeはグローバル(window)に属していて、fugaはインスタンスとして作成された時点でhogeに属しているのかな?
thisはその属しているものを向き先として設定されているのかな?という。

調べてみると、プロトタイプあたりとも密接に関係してそうなので、それはそれで後日ちゃんと理解したいです。

なんだか感覚値が高い記事になってしまいましたが、備忘録ということで(2回目)
それでは、きょうはこのへんで。

クロージャって何ができるの?

こんばんは、有村です!
前口上が思いつかないのでそのまま本題に入ります!

今回のテーマは、
クロージャって何ができるの?
です!!

なんとな〜く言葉は知っていても、「こう使う!」「ここで使う!」という実践方法が分からなかったので、
今回まとめてみることにしました。

まず例を。

(分かりやすいようにscriptタグを分割しています)
ほげ2を実行すると、何度押しても2・2・2・2……とアラートが出るのですが、
ほげ1を実行すると、押すたびに2・3・4・5……と1つずつ数字が進んでいくんです!

ぱっと見では「hogeを呼んでるけど、結果としてfugaを実行している」という点は変わらないですよね…。
ただ、前者は
関数fugaをreturnで返している
関数hogeを変数に格納している
関数hogeを格納した変数を実行している
という点に違いがあります!

なんでそうなるねんは置いておいて、この記述をすることによって、
通常の記述では保持しないはずのローカル変数「no」の状態(=数)を閉じ込めておくことができるのです!

どのような場面で使うか考えると、カウンタ系とかでしょうか。
「いま◯回クリックしましたよ」とか。
もっと見る機能など、クリック回数をキーとするものに対して有効に使えそうです。

しかし、ローカル変数をそのまま閉じ込めておけるということは、その分変数を保持するためのメモリを割いているということになります。
(通常であればガベージコレクションで破棄される)
昨今の環境では使えるメモリも増えているので大した問題にはならないと思うのですが、
「メモリ領域を食ってるんだぞ〜」という点は覚えておくに越したことはないかなと!

それでは、きょうはこのへんで。

expectって便利だね!

こんにちは、有村です!
寒くなりましたね、冬ですね!!

さて今日は、「expectって便利だね!」がテーマです!
翻訳すると「期待」になりますが…いったい何を期待するんだ……

私の場合、会社のサーバに自宅から繋ごうとする際にシェルを実行するんですけど、それは

みたいな内容で書いていたんですよね。
そうすると、

と毎回パスワードを聞かれる。そして打つ。そう、毎回。

このパスワードはその度に異なるのかというとそうではなく、固定。
つまり、変化するのはIPだけなので、自分で入力するのもIPだけにしたかったんです。

何が起こっているのかと流れを追うと、
1. シェルで接続しようとする
2. 相手が「パスワードはなに?」と聞いてくる
3. パスワードを答える
4. 繋がる
ですね。
2と3は、「聞かれて答える」ということから対話形式と言うそうです。

毎回パスワード打つの面倒やんな〜と愚痴ってたら、「じゃあこれあげる」と素敵なシェルをいただきました!
それは…

というもの!

先ほどのシェルとの違いは、
・パスワードが定数になってる
expectっていうのが出てきた!
が大きいと思います!

spawnは、expect内で使える「プロセスの生成」です。
SSH接続のプロセスを開始するよ〜と言ってるんですね!

で、上に出てきたexpectが今回のポイントで、こいつは「マシンからの応答(対話)を読み取ってくれるやつ」です!

は、ダブルクォートで囲まれた部分を自動対話処理するよということ。
また、

では、「passwordを聞かれる」という対話の読み取りが期待されているんですね!

sendは、文字列を送信するコマンド。
つまり、「パスワードくれくれ」に対して、「これやで〜」と自動的に答えを返してくれているんです!

interactは、対話の終了。もうおしまいということ。

ほぉ〜!聞かれることが既に分かっているなら、expectを活用したほうが断然便利ですね!
私の場合はパスワードだけだからよかったものの、もっと複雑なことをやろうとすると、
「何回対話させんねん」ってくらい打ち込む項目が増えたりしそうですし…

それでは、きょうはこのへんで。

ハードの用語について調べてみた

こんにちは!有村です!
最近よく色んな人に、「ほんっとにハードのこと何も知らないんだな…」という顔をされます!

メモリは多い方がよさそう、SSDって速そう、Core iなんちゃらって数字が大きければ優秀?
そんな前知識でIT従事者と話してたら、そりゃ呆れ顔されますよね!

というわけで、今回のテーマはハードの用語について調べてみたです!
プログラムは書けてもハードは良く知らない…そんな同志がいたら、お役に立つと嬉しいです!!

CPUってなに?
central processing unitの略。中央演算処理装置。
こいつが優秀であればあるほど、ユーザからの命令処理の能力が上がるらしい。

何をもって優秀と呼ぶかは、
・クロック数(GHz)、数字が大きいほうが優秀
・コア数、多ければ多いほど同時に処理速度が上がる
これらの数字も関わってくるみたい。

また、クロック数においては、
Turbo Boost
というブースト数値も見ておいたほうが良さそう。

Turbo Boostは、超簡潔に言えば「もしまだCPU全体の発熱に余裕があるなら、負荷が高いコアの性能を上げる(ブーストする)わ」
ということらしい。
Turbo Boostに書かれている数値は、ブースト時に最大ここまでクロック数が上がるよ、というもの。

いつもブーストしとけばいいじゃんと一瞬思ったけれど、「発熱」というワードが大事。
全員が常にブーストしてしまうと、熱で即死亡ですもんね…。

GPUってなに?
Graphics Processing Unitの略。画像演算処理装置。
CPUと名前似とるやんとずっと思ってたのですが、こちらは画像処理に特化した演算装置のようです。

PCでゲームする人にはかなり重要かも知れません!
グラフィックの描画性能が低ければ、もちろんゲームの動きももっさり、カクカクしますよね…(実体験)
GPUはCPUと同じくらい大事な装置だと理解!

SSDってなに?
solid state driveの略。半導体素子メモリのことらしいけど…正直それだけ聞いても分からん。
データの読み書きをするやつ。HDDの仲間のようなもの。

色々読んでいて分かりやすかった説明は、USBメモリと同じ仕組みだということ。
HDDは円盤がくるくる回って、物理的に情報を読み書きしているけれど、SSDはメモリチップでそれを行うため、
HDDと比べて読み書きが非常に速い!

なら全部SSDでいいじゃんと思ったのですが、PC売り場を見ていても分かるように、SSDってそれ自体が高いんですよね…。
なので、システムやエディタなど高速なやりとりが必要になるものはSSDに、音楽や画像など頻繁にアクセスしないものは外付けHDDに、という
住み分けも大事そうです。

これで、PC売り場のスペック表を見ても、なんとな〜く理解できそうですね!
まだまだハード用語あると思いますが、ひとまずきょうはこのへんで。

小ネタ2つ!transitionendと暗黙のsubmit

こんばんは、有村です。2ヶ月なにも書いてなかった。
MacBook Proを破格で譲ってもらったので、せめてMacを使って何かをせねば…とブログ書くことにしました(?)

今回は小ネタ2つ。

小ネタ1・transitionendってバブリングするんだ!?
親もアニメーションするし、子もアニメーションする、というコードを書いていました。
(だいぶ略してますが)

さらに、animation1には、アニメーションが終わったタイミングで発火するnanikasuruを仕込んでいます。

で、動かしてみると、なぜか意図しないタイミングでnanikasuruが実行されるんですよね。
なんでだ?どこだ?と調べると、ちょうどanimation2のアニメーションが終わった後でした。

animation2には何も仕込んでないのにな……と思ったものの、それがよくなかった!
なぜなら、transitionendはバブリングするから…!

つまり、animation2のtransitionendがバブリングしてanimation1まで伝わり、
animation1のtransitionendが発火してしまったということですね!

これを仕込まないといけなかった。ここにだいぶやられた。

小ネタ2・暗黙のsubmitってあったんだね!?
業務中、こんな相談を受けました。
「テキストボックスにフォーカスしたままEnterを押すと、なぜか戻る動作が発動してしまうんだけど…」
と。

こんな感じのコードでした。

name=”return”っていかにも。どうやらこれがsubmitされて、画面遷移が行われているらしい。
しかしJS周りで特にそこをいじっている様子もなく、なんでだろうと首をひねっていたところ、
「あれ、このページ以外でも、テキストボックスでEnter押したら勝手にsubmitしたことになってないか?」
と気付きました。

まさか…と思い、W3C周りを調べてみたところ、なんとこんな項目が。
暗黙のsubmit。

hitting the “enter” key while a text field

まさにこれじゃないか。

ユーザがテキストボックスに入力して、その後すぐEnterを押してsubmitが実行されれば、
ユーザビリティとして便利やん!ってお話だったのですね…。

なお、複数のsubmitボタンがあった場合、一番はじめに出てくるsubmitが実行されるらしい。
だからreturnが送られていたのか…。

私が最初からバグだと決めつけてしまっていたので、「それって仕様じゃないのか?」「他でもそうなのか?」と多角的に考える気持ちを忘れていました。
それに、それなりに長いことフロントエンドに携わっていても、「こういう仕様だったの!?」と気付かされることが多いです。

日々勉強!って感じで、ほんとおもしろいですね、フロントエンド!
それでは、きょうはこのへんで。

attrでcheckedが動かせない!?

こんばんは、有村です!
また期間…が……ま、まあゆっくりペースで更新ってことで!!

本日のテーマは、「attrでcheckedが動かせない!?」です!
jQuery使う方であれば、attrは属性をいじいじするのに馴染み深いメソッドですよね…。
であるからこそ、謎の挙動に翻弄された事件があったのです。

チェックボックスをオンにするという、いたって単純な挙動です。
「prop使えや」というネタバレは置いておいて……だいぶ昔に実装されたコードだったので、こういうやり方もアリだったんですね。
普通に動いていたんです。

それが、別のjQueryのバージョン(1.11.X でしたかね…)で↑を使ったところ……う、動かない〜〜〜!?

同じ使い方、同じHTML構造なのに、なんでだろう!?となりました。
サイトの都合で異なるjQueryバージョンが混在しており、どちらのバージョンでも使用するものなので、困りました…。

そこで調べてみたところ、jQueryのあるバージョン(他の方の記事だと1.9以降…?)を起点に、attrにおけるcheckedの挙動が変わったみたいですね…。

それまでは、「checkedを属性かつプロパティとして設定する」だったものが、
「checkedという属性をつけようとする(しかも実際には動かない)」
に変わったようです。

…でふと浮かんだのは、
プロパティってなんなのさ?
という疑問。

調べてみたら、プロパティ == 属性、だという。
じゃあ何故、attrとpropが存在するのでしょうか…

自分なりに噛み砕くと、どうやら
属性 → HTMLに現れている属性
プロパティ → JavaScriptとして扱う属性
と、微妙な違いがあるそうで…
ん〜、表に見えるものと、表には出ないけどその実態、みたいな感じでしょうか?

「チェックされている状態」と言われたら、確かに見た目だけ「チェックしたでー!」となっても、
実態が「いやいや、見た目だけで結局は未チェックやねん…」となっていたら、意味がないですよね。

かつてのjQueryはそこらへんを上手く補ってくれていたけれど、属性は属性、プロパティはプロパティで分けようや、と方針が変わったんでしょうね。
使う側としては混乱しますが、そう考えると納得のアップデートです。

…というわけで…冒頭で述べた問題については、propを使用することで、旧・新バージョンどちらでも動くようになりました!!

バージョン毎の違いって難しいですね〜…でもいい気付きになりました!
それでは、きょうはこのへんで。