Vimの基本操作
Vimとは
テキストエディタの一種です。ファイルを編集できます。
Macでは初めからインストールされています。
Windowsで使用するためにはインストールが必要です。
Vimの起動
次のようにvimの後に開きたいファイル名を付けてコマンドを実行します。
vim ファイル名 例: vim example.txt
Vimの操作
モード
| コマンド | 動作 |
|---|---|
| esc | ノーマルモード |
| i | インサートモード（文字の入力が可能になる） |
| : | コマンドモード（コマンドの実行ができる） |
ノーマルモード
移動系
| コマンド | 動作 |
|---|---|
| h | ←（左に移動） |
| j | ↓（下に移動） |
| k | ↑（上に移動） |
| l | →（右に移動） |
| 0 | 行の先頭に移動 |
| $ | 行末に移動 |
| gg | ファイルの先頭に移動 |
| G | ファイルの末尾に移動 |
| control + o | 移動前の位置に戻る |
削除系
| コマンド | 動作 |
|---|---|
| x | １文字削除 |
| dd | １行削除 |
| dw | １単語削除 |
コピー&ペースト系
| コマンド | 動作 |
|---|---|
| yy | １行コピー |
| p | カーソルの下の行にペースト |
| P | カーソルの行にペースト |
操作の取り消し・繰り返し
| コマンド | 動作 |
|---|---|
| u | 直前の操作を取り消す |
| control + r | uで取り消した操作を戻す（取り消しの取り消し） |
| . | 直前の操作を繰り返す |
| {number}{command} | numberの回数commandを実行する 例：2dd（２行削除）, 5yy（５行コピー） |
検索
| コマンド | 動作 |
|---|---|
| /{pattern} | 検索 例：/test |
| n | 次の検索結果へ移動 |
| N | 前の検索結果へ移動 |
コマンドモード
| コマンド | 動作 |
|---|---|
| w | 上書き保存 |
| wq | 上書き保存してファイルを閉じる |
| q | ファイルを閉じる |
| q! | 変更を保存しないでファイルを閉じる |
| !{外部コマンド} | 外部コマンドを実行する 例：!ls -a |
| !! | 直前のコマンドを実行 |
| set number | 行番号を表示する |
| 行番号 | 入力した行番号へカーソルを移動する 例：10 |
| %s/{search}/{replace}/g | searchをreplaceに一括置換 例：%s/apple/orange/g |
まとめ
Vimの魅力はマウスやトラックパッドを使わずにキーボード操作だけで色々できちゃうところかなと思います。 エディタでも拡張機能を入れればVimの機能を使えるようなので試してみたいです。 下はVSCodeの拡張機能（「Neovim」とありますが操作性はVimと同じです）。
オブジェクト指向とは
オブジェクト指向
次のように表現すると理解しやすいと思っています。
オブジェクト指向 = モノ指向、モノ中心
モノとは漢字で書くと「物」です。 オブジェクト指向とは、モノを中心とした考え方です。 つまり、ITの世界でのオブジェクト指向とはモノを中心としてソフトウェアを作ることということになります。
「モノ中心」とは別の考え方だと、「機能中心」で考えることもできます。 ソフトウェアはいろいろな機能が組み合わさったものなので、それぞれの機能ごとにソフトウェアを作る（= 機能中心の考え方）ということもできます。 でも、機能中心でソフトウェアを作ると仕様変更などに対応しづらい、修正範囲が広範になる等の問題があります。
一方、モノ中心とすることはソフトウェアの保守や再利用がしやすくなるというメリットがあります。 だから、ソフトウェア開発ではオブジェクト指向が広く採用されています。
参考
平澤 章(2021)『オブジェクト指向でなぜつくるのか 第3版 知っておきたいOOP、設計、アジャイル開発の基礎知識』日経BP
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
余談
ちなみにRubyでは中身の形を比較します。Rubyの後にJavaScriptを学習していたので意外でした。
a = {}
b = {}
a == b # => true
参考
azu、Suguru Inatomi(2020) 『JavaScript Primer 迷わないための入門書』KADOKAWA
共通鍵暗号方式と公開鍵暗号方式
はじめに
今回はセキュリティの話です。データを通信でやりとりする際、漏洩を避けるため、データを暗号化して受け渡しされることがあります。その暗号化技術に共通鍵暗号方式と公開鍵暗号方式があります。これら両方の暗号方式ついて書いていきます。
共通鍵暗号方式
共通鍵暗号方式は、名前の通り共通の鍵を使って暗号化する方法です。下のようなイメージです。
BさんがAさんにデータを渡す例
- Aさんは鍵aを作り、Bさんに渡す（鍵aを共有する）
- Bさんはデータを暗号化して鍵aでロックする
- BさんはデータをAさんに渡す
- Aさんは鍵aを使ってデータのロックを解除して復号する
公開鍵暗号方式
公開鍵暗号方式は、公開鍵と秘密鍵というペアの鍵を用意して、公開鍵を使って暗号化し秘密鍵を使って復号する方法です。共通鍵暗号方式よりもなんだかややこしいです。南京錠のようなもので公開鍵が「鍵穴」で秘密鍵が「その鍵」だと考えるとわかりやすいと思います。共通鍵暗号方式と同じく、下に例を書きました。
BさんがAさんにデータを渡す例
どちらが安全か？
共通鍵暗号方式の場合、鍵が盗まれてデータが漏洩するリスクがあります。鍵を共有するためには、まず初めに一方が他方に鍵を渡す必要があり（上の例だとAさんがBさんに渡していました）、この時に盗まれる可能性があります。鍵が盗まれると暗号化されたデータが復号されてしまいます。
公開鍵暗号方式でも、公開鍵を渡す時に盗まれるリスクがあります。しかし公開鍵は盗まれても問題はないです。公開鍵は暗号化することはできますが、復号することができないからです。復号するためには秘密鍵が必要であり、秘密鍵は受け渡ししないので盗まれる心配はありません。
ですので公開鍵暗号方式のほうが安全性が高いと言われています。
まとめ
共通鍵暗号方式は、共通の鍵を使って暗号化する方法。
公開鍵暗号方式は、公開鍵を使って暗号化し、秘密鍵を使って復号する方法。こちらのほうが安全性が高い。
参考
他の人の作成したブランチを引き継ぐ方法
方法
具体的には、他の人が作成したリモートリポジトリにあるブランチを自分のローカルリポジトリに持ってくる方法です。 他の人の作成したブランチがリモートリポジトリに存在する必要があるので、そうでないならpushしてもらう必要があります。
下記の３つのコマンドを実行すればできます。
※ 他の人の作成したブランチを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）に自分のコミットが上書きされているのが確認できるはずです。
まとめ
冒頭の「方法」で書いた３つのコマンドを実行すれば、他の人の作成したブランチを引き継げる。
参考
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技術入門』技術評論社
