hato_blog

IT・プログラミングに関して書いています。

falseになる値

JavaScriptの場合、下記の7つの値がfalseになる。(これらはfalsyな値とも呼ばれる)

false
undefined
null
0
0n
NaN
""

下のようにfalsyな値の0の条件だと処理が実行されない。逆に、falsyな値以外の値だと処理が実行される。

if (0) {
  // 実行されない
}

if (1) {
  // 実行される
}

ちなみにRubyだと0はtrueになる。このtrueになる値、falseになる値というのは、言語によっても異なってくるみたいなので、気をつけねば・・

参考

azu、Suguru Inatomi(2020) 『JavaScript Primer 迷わないための入門書』KADOKAWA

JavaScriptではオブジェクトの参照を比較する

JavaScriptでオブジェクトの比較をしたときの挙動が意外だったので、備忘録としてこれについて書きます。

本題

JavaScriptではオブジェクトを比較する際、オブジェクトの参照を比較するようです。

上の例ではaとbがそれぞれ別々に宣言されています。だから、別々のオブジェクトを参照している。それで比較するとfalseとなる。

cとdの場合は、dにcを格納しているので、同じオブジェクトを参照することになり、trueとなる。

オブジェクトの中身の形(下の例では{})が同じがどうかを比較するわけではないんですね!

const a = {} 
const b = {}
a === b  // => false

const c = {}
const d = c
c === d   // => true
余談

なぜJavaScriptのこの動きが意外に思ったのかというと、Rubyでは中身の形を比較するんですよね。Rubyではオブジェクトと呼ばずにハッシュと呼びますが。 (筆者はRubyをある程度習得した後、JavaScriptの学習をしています。)

a = {} 
b = {}  
a == b   # => true
参考

azu、Suguru Inatomi(2020) 『JavaScript Primer 迷わないための入門書』KADOKAWA

1つのフォームに複数のsubmitボタンを配置して、submitボタンごとに表示名とは別のvalueを持たせる

1つのフォームに複数のsubmitボタンを配置して、submitボタンごとにボタン名(画面に表示されるボタンの名前)とは別のvalueを持たせる方法です。

押されたボタンごとに処理を分けたいときがたまにあるのですが、おそらくf.submitではできないです。(ボタン名とvalueを同じにすればできますが・・)

f.button_tagを使えばできました。

f.button_tag '登録して一覧ページへ', type: 'submit', name: 'redirect_to', value: 'index', class: 'xxx'
f.button_tag '登録してトップページへ', type: 'submit', name: 'redirect_to', value: 'top', class: 'xxx'

params[:redirect_to]で'index'または'top'が取得できます。

HTTPSとは

はじめに

URLでよく見かける、https:// の"s"は何を示しているのかという話です。

調べてみると、HTTPSとはHTTP over SSL のことのよう。ではSSLとは何か?ということで SSLについて書いていきます。

SSL

簡単に言うと、HTTP通信でやり取りするデータを暗号化する仕組みのようです。HTTP通信でやり取りするデータをパケットと呼ぶので、パケットを暗号化する仕組みと言うとより正確かなと思います。

ちなみにSSLはSecure Socket Layerの略。

ではSSLの仕組みはというと・・

  1. 通信相手と1つの鍵を共有する(この時、公開鍵暗号方式で鍵を渡す)

  2. データを暗号化して送り合う。暗号化されたデータは共有した鍵で復号する。鍵を持たない第三者は復号できない。

公開鍵暗号方式共通鍵暗号方式の技術が使われているんですね。

まとめ

HTTPSのSはSSLを指す。

SSLはHTTP通信の際のデータを暗号化する仕組み。

参考

小森裕介(2010) 『プロになるためのWeb技術入門』技術評論社

共通鍵暗号方式と公開鍵暗号方式

はじめに

今回はセキュリティの話です。データを通信でやりとりする際、漏洩を避けるため、データを暗号化して受け渡しされることがあります。その暗号化技術に共通鍵暗号方式公開鍵暗号方式があります。これら両方の暗号方式ついて書いていきます。

共通鍵暗号方式

共通鍵暗号方式は、名前の通り共通の鍵を使って暗号化する方法です。下のようなイメージです。

BさんがAさんにデータを渡す例
  1. Aさんは鍵aを作り、Bさんに渡す(鍵aを共有する)
  2. Bさんはデータを暗号化して鍵aでロックする
  3. BさんはデータをAさんに渡す
  4. Aさんは鍵aを使ってデータのロックを解除して復号する

公開鍵暗号方式

公開鍵暗号方式は、公開鍵と秘密鍵というペアの鍵を用意して、公開鍵を使って暗号化し秘密鍵を使って復号する方法です。共通鍵暗号方式よりもなんだかややこしいです。南京錠のようなもので公開鍵が「鍵穴」で秘密鍵が「その鍵」だと考えるとわかりやすいと思います。共通鍵暗号方式と同じく、下に例を書きました。

BさんがAさんにデータを渡す例
  1. Aさんは公開鍵aと秘密鍵aを作り、Bさんに公開鍵aを渡す
  2. Bさんはデータを暗号化して公開鍵aでロックする
  3. BさんはデータをAさんに渡す
  4. Aさんは秘密鍵aを使ってデータのロックを解除して復号する

どちらが安全か?

共通鍵暗号方式の場合、鍵が盗まれてデータが漏洩するリスクがあります。鍵を共有するためには、まず初めに一方が他方に鍵を渡す必要があり(上の例だとAさんがBさんに渡していました)、この時に盗まれる可能性があります。鍵が盗まれると暗号化されたデータが復号されてしまいます。

公開鍵暗号方式でも、公開鍵を渡す時に盗まれるリスクがあります。しかし公開鍵は盗まれても問題はないです。公開鍵は暗号化することはできますが、復号することができないからです。復号するためには秘密鍵が必要であり、秘密鍵は受け渡ししないので盗まれる心配はありません。

ですので公開鍵暗号方式のほうが安全性が高いと言われています。

まとめ

共通鍵暗号方式は、共通の鍵を使って暗号化する方法。

公開鍵暗号方式は、公開鍵を使って暗号化し、秘密鍵を使って復号する方法。こちらのほうが安全性が高い。

参考

きたみりゅうじ(2011) 『キタミ式イラストIT塾 基本情報技術者 令和02年』技術評論社

他の人の作成したブランチを引き継ぐ方法

方法

具体的には、他の人が作成したリモートリポジトリにあるブランチを自分のローカルリポジトリに持ってくる方法です。 他の人の作成したブランチがリモートリポジトリに存在する必要があるので、そうでないならpushしてもらう必要があります。

下記の3つのコマンドを実行すればできます。

※ 他の人の作成したブランチをa_branchとしています。

$ git fetch
$ git branch a_branch origin/a_branch
$ git checkout a_branch

それぞれのコマンドの説明

$ git fetch

リモートリポジトリのブランチをすべてローカルに持ってきます。

$ git branch a_branch origin/a_branch

引き継ぎたいブランチと同じ名前のブランチをローカル上につくります。

$ git checkout a_branch

作成したブランチにチェックアウトします。作業をこなった後は、いつも通りにコミット、プッシュが行えます。プッシュしたら、リモートリポジトリ上の他の人が作成したブランチ(a_branch)に自分のコミットが上書きされているのが確認できるはずです。

まとめ

冒頭の「方法」で書いた3つのコマンドを実行すれば、他の人の作成したブランチを引き継げる。

参考

git fetch の使い方と、主要オプション | WWWクリエイターズ

git-branch – Git コマンドリファレンス(日本語版)

Cookie(クッキー)とセッション

はじめに

Cookieってなに?と聞かれても具体的に説明できないな・・と思ったので自分の理解を深めるためにも、Cookieについて書いてみます。ついでにCookieと関連の深いセッションについても書きます。

Cookie

Cookieとは、サーバとクライアント間で情報をやり取りする仕組み、またはそのやり取りする情報を指すようです。

ここまではなんとなく分かっていました。ではどういう仕組みかというと...

クライアントがサーバにリクエストを送ったら、サーバはクライアントに対してレスポンスと同時にCookieを渡す。クライアントはサーバに次のリクエストをするときに渡されたCookieをサーバに返す。そして、サーバはクライアントに対してレスポンス時にまたCookieを渡す。このようにサーバとクライアントはCookieを渡して返して...とやり取りするみたいです。

ではなぜCookieをやり取りするのかと言うと、サーバ側がクライアントを識別するのに役立つからのようです。Cookieにはクライアント独自の情報を入れることができるため、渡されたCookieを見ればクライアントを特定できるんですね。Cookieは箱のようなもので、その中にパスワードなどを入れるイメージですね。CookieにユーザAのパスワードが入っていたらユーザAからのリクエスト、ユーザBのパスワードが入っていたらユーザBからのリクエストというように、サーバ側は誰からリクエストが来たか特定できると言うわけです。

セッション

セッションは、セッションIDと呼ばれる情報をCookieとしてやり取りすることで、サーバがクライアントを識別する仕組みです。

Cookieの説明でパスワードをやり取りする話をしましたが、パスワードではなくセッションIDをやり取りするのがセッションってことですね。一般的には、このセッションの仕組みがユーザを特定するために利用されているようです。

パスワードをやり取りすると、通信の途中で盗聴されてしまうかもしれないので、セキュリティ上よろしくない。なので、パスワードのような個人情報ではなく、セッションIDと呼ばれるそれ自体は意味を持たない文字列をやり取りしているってわけです。

まとめ

Cookieは、サーバとクライアント間で情報をやり取りする仕組み。またはそのやり取りする情報のこと。

セッションは、サーバとクライアント間でCookieの仕組みを利用してセッションIDと呼ばれる情報をやり取りすること。この仕組みによりサーバがユーザを識別している。

参考

小森裕介(2010) 『プロになるためのWeb技術入門』技術評論社