javascriptにはenumという型はありませんので、今まで（ES5）は以下のように擬似的にenum的なものを作っていました

var Sample = {
  One: "one",
  Two: "two"
};

ついでに const 宣言も無かったので後から書き換え可能になっているのも残念なところです。

ES2015になってつい嬉しくて const 宣言を使って以下のようにしていました。

const Sample = {
  One: "one",
  Two: "two"
};

しかしこれも実は残念なところがあって、値が文字列である以上他の由来の文字列でも比較がtrueになってしまうのです。

const Sample = {
  One: "one",
  Two: "two"
};
const Other = {
  One: "one",
  Two: "two"
};

console.log(Sample.One === Other.One); // => true

これはいただけませんね。enumの役割をちゃんと果たしていません。

ES2015ではSymbolが使えるようになったので以下のようにするととってもいい感じだとおもいます。

const Sample = {
  One: Symbol("one"),
  Two: Symbol("two")
};
const Other = {
  One: Symbol("one"),
  Two: Symbol("two")
};

console.log(Sample.One === Other.One); // => false

Symbol() はグローバルにユニークな値を返すので、同じ引数で実行しても結果が異なるためにこのような使い方ができるわけです。

ちなみにグローバルに同一なSymbolを参照したい場合は Symbol.for() を使うといいみたいです。

let one = Symbol.for("one");
console.log(one === Symbol.for("one")); // => true

Symbolのブラウザでの実装状況はこちら http://kangax.github.io/compat-table/es6/#test-Symbol

結論から言うと CSSプロパティ `font-feature-settings` を設定すると特定のChromeバージョンにおいてレンダリング(layout, painting)が非常に遅くなる(レポート報告済)。

font-feature-settingsとは？

OpenType Fontの先進的なタイポグラフィーの機能を使用するためのプロパティ。下記のような機能がある。

• font-kerning (カーニング)
• legature (合字)
• pnum (Proportional figures)

Demoを見つけたので共有: http://clagnut.com/sandbox/css3/

なぜ使っていたのか？

プロジェクト開始時は `normalize.css` と bourbonファミリーを下地にすることが多いのですが、bourbonファミリーの一つであるbittersで生成したbase cssにそれが入っていたようです。

対策

今回この現象が発生したプロジェクトでは `font-feature-settings` を使う意図が無かったので該当コードをCSSより削除しました。

ハレノヒではプロジェクト管理はtrelloかgithubを使っています。これは決まりではありませんがどちらもチームが使い慣れていますので今では当たり前のようにこれらを使っています。
他にもいいプロジェクト管理ツールがあれば使ってみたいですね。

さて、Githubを使っているということは当然gitを使ってバージョンを管理をしているのですが、ブランチを作り作業を始める際の定番手順を紹介したいとおもいます。

Github Flowについてはこちらに日本語翻訳記事がありますので御覧ください
https://gist.github.com/Gab-km/3705015

はじめに

例としてSuper Awesomeなポートフォリオサイトを構築していたとします。
ポートフォリオサイトなので作品紹介ページは作ったのですが、お問い合わせページがまだ無いのでそれを追加する作業を進めていきます。

またGithub社が提供する hub コマンドを使うと便利なのでこれも合わせて紹介します。

1. masterブランチからfeatureブランチを作成する

まずは作業するためのブランチを作成します。この場合新機能の開発なので feature（機能）という名前空間の下に作業内容がわかりやすい名前で作成します。

git checkout -b feature/contact_form

git checkout -bを使うとブランチの作成とチェックアウトを同時に行えるので便利です。

2. 空のコミットをしておく

新しいブランチではcommitが一つもないのでこのままではPull Requestが作成できません。
なので以下のように空のコミットでブランチを作成したという内容だけを記録しておきます。

git commit --allow-empty -m "Create a branch"

3. originにpushする

git push origin feature/contact_form

4. Pull Requestを作成する

ここでhubコマンドの登場です。
https://github.com/github/hub

Mac OS XならHomebrewでインストールできます。

brew install hub

hub コマンドでPull Requestを作成する方法はこちらです

hub pull-request -m "[WIP] お問い合わせフォームを実装"

-m でPull Requestのタイトルを付けられますが、先頭に[WIP]をつけました。
これは Work In Progress の略称です。
つまりまだ作業中ですよという意味ですね。

5. チェックリストを作成する

hubコマンドでPull Requestを作成すると標準出力にWebページのURLが表示されますのでそこにアクセスしましょう。

 hub pull-request -m "[WIP] お問い合わせフォームを実装"
https://github.com/yourname/yourrepo/pull/1

チェックリストは作業を意味のある単位で分割して書くようにしています。
たとえば `GET /conatct_us` と `POST /contact_us` という２つのRouteを追加するのであれば
「contact_usのroutesを追加」という項目にまとめてしまいます。

より詳細に記述したい場合はチェックリストに階層をつけるといいとおもいます。

今回は以下のようにしました

Githubのコメント欄にはMarkdownが書けますが、- [ ]というリストを使うとチェックリストを作成できます

このように

6. 作業をすすめる

ここまでできたら後はガンガンコードを書いて開発をすすめます。
途中で一段落ついたらこまめにoriginへpushすることをオススメします。
そうすると何か間違っていたり、別のブランチで同じ作業をしてしまっていたりしたらお互いにコメントしあえるからです。

紆余曲折があってレビューの際に質問されそうだなと思う部分があるなら自分から先にコメントしてしまうのも手です。

例えば以下のように

7. レビューしてもらう

チェックリストが全部Doneしてマージする準備ができたらチームメンバーにレビューしてもらいます。
先にPull Requestのタイトルから [WIP] を削除しておきましょう。

ほんの小さな変更であればこの手順を省略してもいいとおもいますが、できるだけレビューしてもらうことで自分でも気づかなかった部分が見えてくることがあります。

この時、粗探しだけをするのではなく感心したり勉強になるようなことがあれば伝えてあげるといいとおもいます。

8. マージする

マージは基本Pull Requestを作った本人が行います。
GithubのWebページからマージボタンを使うと、忘れがちなDeleteもすぐに行えてマージ済みブランチがたくさんある状態を防げます。

リモートでマージをしたら忘れずにローカルにも反映しておきます。

git checkout master
git pull origin master
git branch -d feature/contact_form

ローカルの feature/contact_form ブランチも削除しておきましょう。

まとめ

以上がgithubを使った作業の進め方です。
そんなに難しいことはありませんが、気をつけるとことがあるとすれば自分の書いたコードは誰かに読んでもらうということを前提に作業をしていると、レビューしてもらう相手はもちろん未来の自分にも優しくなれるように気がします。