//ルートにアクセスされたら/archiveにリダイレクトする

エイリーの備忘録

開発や音楽について書いていこうと思っています。

meteorのプロジェクトをpassengerで1回目のデプロイをする

今回はmeteorのプロジェクトの1位回目のデプロイ方法を書かせていただきます。
日本語の記事って少なすぎて泣けてきますよね・・・
エンジニアなら英語の記事ぐらい読めろって言われますが、まだ苦手です・・・

この記事は、
Deploying a Meteor app on Debian 8 (with APT) on a Linux/Unix production server with Passenger open source in Standalone mode - Passenger + Meteor deployment tutorial - Passenger Library
上記サイトを参考にして筆者が実際に構築をし、必要と思われるものを書き出しています。

passengerのインストー

まだpassenger(webサーバー)をインストールしていなければ、下記の記事を参考にpassengerをインストールしてください。
youmjww.hatenablog.jp

前提環境

ディストリービュージョン:ubuntuまたはdebian
サーバー:passenger
sudo権限が使える
Meteorのバージョンが1.4以上

デプロイ前の準備

meteorをビルドしてサーバーに送信する

まず、ローカル環境でmeteorのパッケージをビルドします。

#ローカル環境
#ビルド
$meteor build --server-only ../new_package && mv ../new_package/*.tar.gz package.tar.gz

#ファイルをアップロード
$scp package.tar.gz adminuser@yourserver:~/

appユーザの作成

ここからは特に指示がない限りサーバー上で作業を行ってください。

#ローカル
#サーバーに接続
$ssh adminuser@yourserver

私、セキュリティの事はよくわからないのですが専用のユーザを作って操作してるのが安全らしいですね。よくわからんけど・・・

#appユーザーの作成
$sudo adduser myappuser

meteorのパッケージを抽出する

$sudo mkdir -p /var/www/myapp

$cd /var/www/myapp
$tar xzf ~/package.tar.gz
$chown -R myappuser: .

アプリ環境を用意する

MongoDBのインストー

#aptのリポジトリを追加
$sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6

$echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

#リポジトリを追加したのでパッケージリストに更新をかける
$sudo apt update

$sudo apt install -y mongodb-org

依存関係のインストー

#myappuserに切り替え
$su myappuser

#依存関係のインストール
$cd /var/www/myapp/bundle/programs/server
$npm install --production

passengerの設定

サーバーの設定を行います。

$cd /var/www/myapp/bundle
$vim Passengerfile.json

Passengerfile.jsonに下記の内容を入力してください。

{
  // Tell Passenger that this is a Meteor app.
  "app_type": "node",
  "startup_file": "main.js",
  "envvars": {
    // Tell your app where MongoDB is
    "MONGO_URL": "mongodb://localhost:27017/myappdb",
    // Tell your app what its root URL is
    "ROOT_URL": "http://yourserver.com",
  },
  // Store log and PID file in parent directory
  "log_file": "../passenger.log",
  "pid_file": "../passenger.pid"
  // Run the app in a production environment. The default value is "development".
  "environment": "production",
  // Run Passenger on port 80, the standard HTTP port.
  "port": 80,
  // Tell Passenger to daemonize into the background.
  "daemonize": true,
  // Tell Passenger to run the app as the given user. Only has effect
  // if Passenger was started with root privileges.
  "user": "myappuser"
}

ROOT_URLはページのルートURLを指定してください。

passengerを起動する

#今はadminuserからmyappuserにスイッチしている状態のはずなのでadminuserに戻る
$exit

#passengerのスタート
$cd /var/www/myapp/bundle
$sudo passenger start

サーバがちゃんと動いているかテストする

#ローカル環境
$curl http://yourserver.com/
#これでちゃんと立っていたらHTMLファイルが帰ってくるはずです。

あとがき

これでpassengerの初期設定などは完了しました。
ただ、私も英語が得意なわけではないので解説などはざっくりしています。
ああ・・・英語できるようになりたい・・・

ubuntuにpassenger standaloneを構築する

英語の記事が多く、自分で使う時もよく迷うので備忘録として書きます

前提環境

ディストリ〜ビュージョンがubuntuまたはdebian
sudoが使える

node.jsのインストー

node.jsのインストー

$sudo apt update
$sudo apt install -y curl apt-transport-https ca-certificates &&
&curl --fail -ssL -o setup-nodejs https://deb.nodesource.com/setup_4.x &&
  sudo bash setup-nodejs &&
  sudo apt-get install -y nodejs build-essential

passengerのインストー

# リポジトリの信用情報を取得
$sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7
$sudo apt install -y apt-transport-https ca-certificates

# リポジトリを追加
$sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger xenial main > /etc/apt/sources.list.d/passenger.list'
$sudo apt update

# passengerのインストール
$sudo apt install -y passenger

正しくインストールされたか確認

$sudo /usr/bin/passenger-config validate-install
# 実行結果
 * Checking whether this Phusion Passenger install is in PATH... ✓
 * Checking whether there are no other Phusion Passenger installations... ✓


以上でパッセンジャー自身のインストールは終了です。
明日の記事でmeteorと連携を行い、デプロイ環境の構築を書きたいと思います。

git コンフリクトの解消法

コンフリクトとは
日本語に訳すと衝突・競合とよく説明されていますがよくわからないですよね。

例えば、masterブランチからAブランチとBブランチを同じコミットのタイミングで作ったとします。
AブランチとBブランチで同じファイルで変更を加えてコミットしたとします。
Aブランチがmasterブランチにマージしました。
その次にBブランチがmasterにマージしようとしました。
するとgitはAブランチの変更を適用しているためBブランチの変更を適用しようと思ってもどちらを優先して変更を加えたらいいのかわからなくなります。
ここでconflict(衝突)が起きるわけです。

では、コンフリクトの解消法を紹介させていただきたいと思います。

コンフリクトの解決

f:id:youmjww:20170512015846p:plain
上記の画像のようにコンフリクトが発生すると、コンフリクトの発生したファイルを表示してくれます。
この例ですと、二行目に書いてあるhoge.txtがコンフリクトを起こしているのがわかります。

このhoge.txtの内容を編集して本来望んでいた形に修正してあげたいと思います。
f:id:youmjww:20170512020738p:plain

このファイルの内容(もっとマシなデータを用意できなかったのかよ)を例に上げますと、2行目がAブランチの変更で4,5行目Bブランチの変更です。
Aブランチの内容が先にマージされているのでBブランチの内容が適用できていないみたいですね。
これをあるべき形・正しい形に修正してあげてください。
今回の場合は変更を全て適用したいので1,3,6行目を削除してあげてファイルを保存します。
あとは、addしてcommitするだけです。
これでコンフリクトの解決は完了です。

ファイルが大きい場合

数行程度の小さいファイルなら何も工夫をしなくても問題は無いのですが、実際に開発をしているとそんなに小さいファイルばかりではなく数百行のファイルから目視でコンフリクトをしている場所を探すのは骨が折れますよね。
そこで有効活用をしたいのがエディタの検索です。
コンフリクトが起きると必ず<<<<<<と======と>>>>>>が挿入されます。
この3つのどれかで検索をかけてあげてください。
するとコンフリクトが起きている箇所がすぐに見つかります。
コンフリクトの発生場所を見つけることができたら、コンフリクトを修正してaddしてcommitしてください。

コンフリクトが複数起きている場合

vscodeを開いて左メニューの上から3個め(ソース管理)を開いてください
f:id:youmjww:20170512024743p:plain
するとコンフリクトが起きているファイルを一覧で見ることが出来ます。
ついでにコードを見るとハイライトまでされるのでコンフリクトの場所をすぐに見つけることができるので効率よくコンフリクトを解消できると思います。

あとがき

コンフリクトが発生すると最初は戸惑いますよね。
でも、コンフリクトの理由さえわかってしまえばすぐに修正することが可能です。
チームで開発をしているとたまにコンフリクトが起きたりしますので落ち着いて解決できるようになりたいですね。

そういえば、この前の記事でlinux,mac,windowsで共通して同じUIで使えるgit cliantはありますかって聞いて無いと答えましたがありましたw
VScodeがgitクライアントの機能が入っているのを忘れていましたw
ただVScodeだとgit initやリセットソフトなどが出来ないからなあ・・・やっぱりCUIがやりやすいですw

第2回目 CUIのみでgit入門!

この記事は前回の続きです。
まだ前回の分をご覧になられていない方は前回の分からご覧ください。

前回記事
youmjww.hatenablog.jp

git関連記事一覧
http://youmjww.hatenablog.jp/archive/category/git

まず、手を動かしてみて後から用語などを簡単に解説していきたいと思います。

準備

gitHubのアカウント作成

まず、git hubへアクセスをしてsign up(アカウントを作成してください)
The world's leading software development platform · GitHub

サイトへアクセスをすると下の画像のような画面が出てくるので赤で囲ってあるところに全ての項目に入力して緑色のボタンをクリックしてください。
f:id:youmjww:20170511055049j:plain

Unlimited public repositories for free.にチェックが入っていることを確認して緑色のボタンをクリックしてください。
f:id:youmjww:20170511055452p:plain

アンケートのようなものが出てきますがスルーして緑色のボタンを押して大丈夫です
f:id:youmjww:20170511055813p:plain


登録したメールアドレスにこんな感じのメールが来ているはずなのでVerify email addressをクリックしてください。
f:id:youmjww:20170511060318p:plain

リポジトリを作りたいので Start a projectをクリックしてください
f:id:youmjww:20170511055923p:plain

Repository nameに好きなリポジトリ名をつけて緑色のボタンをクリックしてください
ローカル環境にすでにリポジトリがあるはずなのでInitialize this repository with a READMEにはチェックを入れないでください。
f:id:youmjww:20170511061105p:plain

これで前準備は完了です。

実際にやってみる

リモートリポジトリを登録する

まず、リモートリポジトリにpushするためにリモートリポジトリを登録しておく必要があります。

cd <リポジトリ>
$git remote add origin https://github.com/<githubのユーザーネーム>/<githubのリポジトリ名>.git

pushしてみる

pushとは
リモートリポジトリにファイルをアップロードすることです。

$git push origin master

上記のコマンドを実行すると、usernameとpasswordが聞かれますので、
usernameにgithubに登録したメールアドレス
passwordにgithubのパスワードを入力してください。

githubからちゃんとpush出来たか確認してみる

ちゃんとpushができているとリポジトリにアクセスをするとこのような画面になっているはずです。 
f:id:youmjww:20170511062347p:plain

cloneしてみる

choneとは
リモートリポジトリからリポジトリをコピーしてくることを言います。
まず、今リポジトリの中にいるはずなので一つ上の階層に移動します。
以下これまで使っていたリポジトリリポジトリ1 新しくcloneしてきたリポジトリリポジトリ2とします。

$cd ../
$git chone https://github.com/<githubのユーザー名>/<リポジトリ名>.git

リポジトリ2の中に移動します
$cd <リポジトリ2>

ファイル構成やファイルの内容を確認してみてください。
リポジトリ1と全く同じ内容になっているはずです。

変更を加えてpushしてみる

現在はリポジトリ2の中にいるはずなので何か適当にファイルに変更を加えてください。
ファイル内の変更でも大丈夫ですし、新規ファイルを作成していただいても構いません。
ファイルに変更ができたら下記のコマンドを実行してコミットをしてpushしてください。
pushするときに先ほどと同じようにユーザーネームとパスワードを聞かれるので入力してください。
ついでに、リポジトリ2のコミット履歴を確認してみるといいでしょう。

$git add .
$git commit -m "コミットメッセージ"
$git push origin master
$git log

pullしてみる

pullとは
リモートリポジトリとローカルリポジトリの差分をリモートリポジトリからダウンロードしてきます。

まず、リポジトリ1のコミットの履歴を確認してみます。

$cd ../<リポジトリ1>
$git log

ここでリポジトリ2の内容に差分があることが解ると思います。

リポジトリ2で変更を加えられた変更をリポジトリ1適用してみたいと思います。

$git pull origin master

これで差分がなくなったはずなので確認してみたいと思います。

$git log

リポジトリ2と差分が無いことが解ると思います。

ブランチ操作

ブランチを切ってみる

ブランチとは
簡単に言えばパラレルワールドです。
詳しい用途については後で解説します。

では早速ブランチを切って移動してみたいと思います。

$git checkout -b testBranch

checkoutは本来はブランチ移動用のコマンドなのですが、-bオプションをつけることによりブランチを作成してついでに移動するという意味になります。

testBranch内で変更を加えてみる
$touch branch.txt
$git add .
$git commit -m "branch test"

今加えた変更を覚えておいてください。

masterブランチでlogを確認してみる

とりあえずmasterに移ります

$git checkout master

さっきtestBranch内で加えた変更はパラレルワールドでの出来事なのでここの世界線では全く影響が無いはずです。
確認してみましょう。

まず、先ほど編集を加えたファイルを見てみてください。
ここの世界戦では変更は無かったことになっているはずです。
コミットの履歴も確認してみましょう。

$git log

さっきの変更はここの世界線では見えないはずです。

testBranchをgithubにpushしてみる
git push origin testBranch

これでtestBranchがpushできました。

masterブランチにtestBranchの変更を適用してみる

testBranchの世界で行った変更をmasterブランチに適用したいと思います。

$git checkout master
$git merge testBranch

これでmasterブランチに適用出来たので確認してみましょう。
testBranchで変更を加えたファイルとgit logを確認してみましょう。
masterに居るのに変更が適用されているはずです。

現在のブランチとブランチ一覧の確認

現在居るブランチとブランチのリストを確認することが出来ます。

$git branch

左側にアスタリスクが付いているブランチが現在のブランチです。

不要になったブランチの削除

gitでは要らなくなったブランチはすぐに削除するべきらしいですので削除したいと思います。

git branch -D testBranch
ブランチを使う利点

ブランチを簡単に説明しますと上記でも述べたとおりパラレルワールドです。
つまりどういうことかと言いますと、masterで上手いこと動いてる状態として、新しい機能を追加したかったとします。動いているものに直接変更を加えるのは危険です。プロジェクトごとバックアップをとってもいいのですがそれだと手間がかかります。
そこで、ブランチを使います。
ブランチを使うとmasterに対してパラレルワールドを作ることを出来るので最悪作業ブランチ内で起こったことを全て無かったことにも出来るしすぐにmasterの状態に戻すことも出来ます。

一番大きい利点は、チームで開発をするときにmasterを中心のブランチとしたとして各自それぞれブランチを持っているとそれぞれで作業をして、機能が完成したらmasterにマージするだけで変更が反映されるのでいちいち誰かを待ったり手作業で変更を適用したりする必要が無くなるのが大きな利点かなと感じます。

今回出てきた用語

リモートリポジトリ

サーバー上(リモート)にあるリポジトリです。

ローカルリポジトリ

手元のPC(ローカル)にあるリポジトリです

push

ローカルリポジトリの変更をリモートリポジトリに反映します

構文
$git push origin <ブランチ名>

pull

リモートリポジトリの変更をローカルリポジトリに反映します

構文
$git pull origin <ブランチ名>

clone

リモートリポジトリからリポジトリをダウンロードしてきます

構文
$git clone リポジトリのURL.git

ブランチ

パラレルワールドです。

第1回目 CUIのみでgit入門!

え?初心者にはGUIを使ってもらったほうがいい?
GUIのほうが理解がしやすい?

では質問です。
linuxwindowsで全く同じ画面で操作ができるgitクライアントは用意されていますか?
せっかくGUIの使い方を覚えてもOSが変わったら通用しますか?
SourceTreeだとwindowsmacしか無いですし、OSが変わるたびにGUIの使い方を覚え直さないといけません。
それなら最初からCUIで覚えたほうが早いですよね?
というわけで、今からgitを覚える皆さん!是非コマンドで覚えて快適なgitライフを!

今回は長くなりますので2回に分けて記事にしたいと思います。

とりあえず、端末・ターミナル・コマンドプロンプト(gitbashのようなgitが使えるやつ)のいずれかを起動しておいてください。

gitとは

git(ギット)は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。

wikiより git - Wikipedia

つまり、ソースコードの変更履歴やバージョンなどを管理することができるツールです。

gitを使うメリット

gitを使うと、日付ごとにファイルのバックアップをとっていた場合はその必要が無くなります。
機能ごとや日付ごとなど自分の好きなタイミングでファイルをセーブ(commit)が出来るのでなにかあった時に戻るのも簡単に出来ます。
しかも、セーブ(commit)するのに必ずコミットメッセージを書かないといけないので、あれ?昨日どんなことをしてたんだっけ?・・・ってなってもコミットコメントを見れば早く思い出すことが出来ます。
チーム開発になっても、誰か他の人がファイルに変更を加えてもコミットメッセージを見ることで変更を加えた人に確認をしなくても変更箇所と変更理由を確認することが出来ます。

gitのインストー

ubuntu

sudo apt install git

CentOS

sudo yum install git

mac

brew install git

windows
リンクを参考にしてインストールおねがいします。
私家版 Git For Windowsのインストール手順 | OPC Diary

実際にgitを使ってみる

初期設定

gitではコミットするためにユーザ名とメールアドレスを設定してあげる必要があります。

$ git config --global user.name "your name"
$ git config --global user.email yourEmail@example.com

とりあえずフォルダを作成して、フォルダの中に移動してください。
ついでに適当なファイルを一つ作っておきます。

$mkdir gitTest
$cd gitTest
$touch textFile.txt

git init

今いるディレクトリをgitのリポジトリにします。

$ git init

git add

commitするファイルを追加します。

git add gitTest.txt

addすることでcommitするための準備が整います。

git commit

では実際にコミット(セーブ)してみましょう!

git commit -m "commit message"

git log

先ほどコミットしたので今度はコミットの履歴を見てみたいと思います。

git log

これでgitのログが確認出来ます。
内容は、
誰がいつコミットしたか。
コミットメッセージ
が時系列順に並んでいます。

簡単な使い方手順

すでにリポジトリはある前提です。
ファイルに変更が加わりました。
そろそろコミットしておきたい。→git add → git commit -m "comitt message"
でコミット出来ます。前の作業から作業を再開するときはgit logを確認してから作業を進めると思い出すのがスムーズになります。

今回出てきた用語集

リポジトリ

ソースコードなどが置いてある貯蔵庫です。

コミット

状態をセーブすることをgitではコミットと言います。


あとがき

本日はここまでにしたいと思います。
次回は、リモートリポジトリとの連携とブランチについて触れていきたいと思います。
よろしくお願いします。

自作のシェルスクリプトでオプションに対応させてみた

youmjww.hatenablog.jp
この記事で制作したスラックに通知を送るスクリプトを使っていて、やっぱり場合によってはbotの名前を変えたり、送信するチャンネルやチームを変えたいと思いオプションで指定できる機能を追加してみました。
やってみると結果としては簡単だったけど結構手間取ったので記事にしたいと思います。
プログラム全体を見たい場合は全体のプログラムまで飛んでください。

下準備

とりあえず、失敗したら今まで使っていた環境に戻せるようにしたいのでファイルをコピーかコミットしておいてください。
コミットの場合は人により管理方法が違うと思いますので適当にお願いします。
ここでは仮にslackPostというスクリプトを編集するとします。

コピー

$cp slackPost slackPost.org

全体のプログラム

#!/bin/bash

# 送信情報の初期値
acssesToken="<yourSlackAcssesToken>"
channelName="random"
txt="EndOfProcessing"
botName="bot"


#引数がある時
if [ $# -ne 0 ]; then
#ヘルプの表示
if [ $1 = "-h" ]; then
		echo "slackPost [option]"
		echo "-t acssesToken"
		echo "-c channelName"
		echo "-b botName"
		echo "-m messeage"
		echo "-h help"
		exit 1
	fi

	#引数の数が正しいか確かめる 正しくなければ処理を終了
	checkArgument=$(($# % 2))
	if [ $checkArgument = 1 ]; then
		echo Syntax error
		exit 0
	fi

	#引数のオプションの処理
	args=("$@")
	for i in `seq 1 $#`; do
		case ${args[i-1]} in
			#acssesToken
			"-t" ) acssesToken=${args[i]};;

			#channel
			"-c" ) channelName=${args[i]};;

			#messeage
			"-m" ) txt=${args[i]};;

			#botName
			"-b" ) botName=${args[i]};;

		esac
	done
fi
#データを作って送信
curl -X POST "https://slack.com/api/chat.postMessage?token=$acssesToken&channel=$channelName&text=$txt&username=$botName"
exit 1

解説と定義

オプションの定義

オプションとは、n個の-hのように-1文字で構成された文字をオプションとします。
オプションは0 〜 n個指定可能で、オプションの数が変わってもちゃんと動くものとします。

解析方法

オプションの解析は至って簡単で、引数を全て配列にしてあげて、配列に入っているオプションになる文字列を識別してオプションの処理をしてあげるだけです。
ただ、getoptsやgetoptといったオプション解析用のコマンドが用意されているのに何故オプション解析を手動で行うかと言いますと、GNU環境とBSD環境で挙動が変わったり使える使えないがあるみたいで、ubuntumacで使いたかったので今回は手動で実装しました。

オプションが指定されていない部分の為に初期値を決めておく

# 送信情報の初期値
acssesToken="<yourSlackAcssesToken>"
channelName="random"
txt="EndOfProcessing"
botName="bot"

ヘルプの表示

-hが入力されたらヘルプを表示して処理を終了しています。

#ヘルプの表示
if [ $1 = "-h" ]; then
	echo "slackPost [option]"
	echo "-t acssesToken"
	echo "-c channelName"
	echo "-b botName"
	echo "-m messeage"
	echo "-h help"
	exit 1
fi

引数の数が正しいか調べる

この処理では引数の数を調べて奇数だったらエラーを出力してスクリプトを終了しています。

#引数の数が正しいか確かめる 正しくなければ処理を終了
checkArgument=$(($# % 2))
if [ $checkArgument = 1 ]; then
	echo Syntax error
	exit 0
fi

実際の解析

オプションの解析はたったこれだけです。
ここのcase文はCやJavaでいうところのswitch文です。
内容は引数を配列にしてオプションの文字を探してオプションにあった処理をしています。

#引数のオプションの処理
args=("$@")
for i in `seq 1 $#`; do
	case ${args[i-1]} in
                # acssesToken
		"-t" ) acssesToken=${args[i]};;
        	# channel
		"-c" ) channelName=${args[i]};;
		# messeage
		"-m" ) txt=${args[i]};;
		# botName
		"-b" ) botName=${args[i]};;
	esac
done

感想

シェルスクリプトが思ったより難しかったです。
アルゴリズムの部分はすぐに出来たのですが、細かい言語仕様でつまづき時間が結構かかりました。
具体的には、if文の書き方でif [条件式]だとエラーが出て、not foundとしか言われず、どこがおかしいのかを調べるのに時間かかりました。if文だとif [ 条件式 ]のように条件式の前後にスペースを入れないといけないんですね。
その他にも、スペースを空けてはいけないところで空けてしまってエラーが出たりバッククォートとシングルクォートを間違えてエラーが出て四苦八苦しましたw
何気にこの規模のシェルスクリプトを書くのは初めてで、すごく時間がかかってしまいましたw

俺選! VScodeおすすめ拡張機能

みなさん、Visal studio codeはどうやって使ってますか?
生でも十分使いやすいエディターですが、プラグインを使うともっと便利になりますよね!
でも、便利そうなプラグインを探してみると、いろいろな記事は出てくるけど実際に使うかどうかわからない・・・ということはありませんか?
というわけで今回は私が実際に使っているプラグインを紹介したいと思います。

拡張機能プラグイン)のインストール方法

まず、vscodeを開き、左メニューの一番下にあるアイコン(拡張機能)をクリックします。
f:id:youmjww:20170508021529p:plain

上にテキストボックスがあるのでそこにパッケージ名を入れると検索できますので、検索して
f:id:youmjww:20170508021752p:plain
目的のプラグインのインストールボタンをクリックします。
あとは、VScodeを読み込み直すだけでプラグインが使えるようになります。

Auto Close Tag

このプラグインはHTMLタグを炊いている最中に重宝するタグで、例えば、

<div>

上のようにHTMLタグを書くと、自動で

<div></div>

閉じタグを挿入してくれます。

Auto Rename Tag

このプラグインは、HTMLを書いている最中に、あれ・・・?ここ、h1じゃなくてh2のほうがよくね?
ってなった時などに役に立ちます。
具体的には、開始タグもしくは、閉じタグの中を変えると、自動的に対になってるタグの内容を更新してくれます。
つまり、タグを変えるのにわざわざ2回も変更をかけなくて済みます。

Trailing Spaces

このプラグインは、入力された最後の文字の後ろにtabや空白が入っていたら強調してくれます。
f:id:youmjww:20170508014149p:plain

Git History

このプラグインは、VScode上でgit logを見ることができます。
使い方は、Ctrl + Shift + pを同時に押して、 git logと入力するだけです。
f:id:youmjww:20170508015810p:plain
上の写真のような感じでコミットを確認することができます。

vscode-icon-rotation

VScodeでは最初はアイコン画像は何も設定されていません。
拡張機能をインストールしてあげることによりファイルのアイコンを設定してあげることができます。
いくつか種類はあるのですが、私はこのプラグインが一番見やすいかなと感じました。
設定方法は、上メニューで、「ファイル」→「基本設定」→「ファイルアイコンのテーマ」と選択し、seti(visual studio code)をクリックするだけです。
f:id:youmjww:20170508020556p:plain

あとがき

以上が私が使っている拡張機能です。
こうやって見てみるとあまり使っていないですねw
ですが、裏を返せば、そもそもVScodeが高機能であまりプラグインを用いなくても十分使用に耐えれるエディタだと言えると思います。
正直ここから先は使うものをその時に応じて入れていけばいいのかなと思います。