anchor.diff:  == 文章のレビュー
   
   物理的な書籍と違っていつでも更新出来るとはいえ、
  -最低限おかしなところは直さないと行けないので、文章をひと通り書き終わってから誤字などチェックを始めました。
  +最低限おかしなところは直さないと行けないため、文章をひと通り書き終わってから誤字などチェックを始めました。
   
  -また、最初に好き勝手書いてた影響もあってセクションの順番を変えたほうが良い箇所もあるなど、
  -全体的な流れを直す作業を最後の方にやっていました。
  +また、最初に好き勝手書いてた影響もあり、セクションの順番を変えたほうが良い箇所もあるなど、
  +全体的な流れを直す作業もレビューと一緒にやっていました。
   
  -全体的な流れを見るために、あるセクションがどのセクションに依存してるかや、
  -逆にどのセクションから参照されてるかを見るためのツールを書いたりして、依存関係がおかしくないかを確認していきました。
  +全体的な流れを見るために、あるセクションがどのセクションに依存してるか、
  +逆にどのセクションから参照されてるかを見るためのツールを書いて、依存関係がおかしくないかを確認していきました。
   
  -この影響で第二章のセクションの一部が第四章に移動したものもあって、
  +この影響で第二章のセクションの一部が第四章に移動したものもあり、
   第二章はPromiseのメソッドの解説に集中した感じに変わったと思います。
   
   誤字脱字などは https://github.com/vzvu3k6k[@vzvu3k6k] さんにたくさんのpull-requestを送ってもらったり、
   自分もiPhone等のモバイル端末から直接Github Issueを立てられるようにして一文字のtypoのIssue等を大量に立ててチェックしていきました。
   
   HTMLで見られるようにするとモバイルでも十分文章のレビューは出来るので、
  -作って置いたIssueをTiDD(チケット駆動開発)の要領で処理していくと文章の修正もテンポよく進められました。
  +作っておいたIssueをTiDD(チケット駆動開発)の要領で処理していくと文章の修正もテンポよく進められました。
   
   ここでもGithub Issueを活用していましたが、typoのような小さな修正と新規セクションを書くような大きな変更では、
   使い方の違いがでてきた気がします。
   
   どちらもブランチを切ってコミットする所までは同じですが、
   小さな修正はコミットメッセージに `fix #108` というように書いてマージするだけで、わざわざpull-requestはしてませんでした。
  +
  +[NOTE]
  +コミットメッセージのルールは Angular.jsで使われている https://github.com/ajoslin/conventional-changelog/blob/master/CONVENTIONS.md[Git Commit Guidelines] をベースにしています
   
   逆に大きな修正はpull-requestを使って進めることで、
   マージする前にもう一度確認しやすかったりやTravis CIによる自動テストが走るため、
  
positive.code: 
  空いてる時間として一番ありそうなのは移動中の時間でした。
  
  MacBook Proの上にThinkPad Bluetooth keyboardを載せて使えば、
  普段とあまり変わらないレベルで書けることがわかったので、移動中にコーディングや文章を書き進めていきました。
  
  もちろん、この文章も移動中に書いてます。
  
negative.code: 
  拡張したMarkdownフォーマットを利用するのも良いですが、その時にAsciiDocというOreillyも使っているフォーマットがあることを思い出しました。
  また、Asciidocのモダンな処理エンジンとして http://asciidoctor.org/[Asciidoctor] という実装があることを知り、
  これを使ってみようと思いました。
  
  まとめると、主目的は電子書籍を書いてみたいという欲求で、サブ目的がES6 Promisesについて扱いきれなかったものを書く
  というのがこの書籍を書き始めた理由です。
  
  == 書き始めのワークフロー
  