--- a/slides/index.html	Mon Feb 03 09:43:16 2014 +0900
+++ b/slides/index.html	Mon Feb 03 10:38:28 2014 +0900
@@ -207,73 +207,20 @@
       </article>
 
       <article>
-        <h3>
-	    Jungleの分散設計:分散版管理システム
-	</h3>
-	<p>Jungleは分散設計を行うにあたってGitやMercurialといった分散版管理システムを意識している</p>
-	<p style="margin-top:-10px;">分散版管理システムとは多人数によるソフトウェア開発において変更履歴を管理するシステム</p>
-	<p style="margin-top:-10px;">分散版管理システムは次の特徴とAPIを持つ</p>
-	<ul>
-	    <li>開発者それぞれがリポジトリのクローンしてローカルに持ち、開発はローカルのリポジトリを通すことで行われる</li>
-	    <li>ローカルのリポジトリは独立に存在し、サーバ上にある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる</li>
-	    <li>データ更新時に先に別の更新が入っていた(衝突)場合はMergeによりデータの整合性をとる</li>
-	</ul>
-      </article>
-
-      <article>
-        <h3>
-	    Jungleの分散設計:分散版管理システム	    
-	</h3>
-	<p>分散版管理システムAPI</p>
-	<ul style="margin-top:-20px;">
-	    <li>commit:データに変更を加えたことをリポジトリに登録</li>
-	    <li>push:ローカルのリポジトリで行った変更履歴を他のリポジトリへまとめて送る</li>
-	    <li>pull:他のリポジトリからの変更履歴をまとめて受け取る</li>
-	</ul>
-	<p style="text-align:center;">
-	<img style="height:200px;" src="./images/distributed_repository.png">
-	</p>
-	<small>
-	<p>分版版管理システムはリポジトリが壊れても別のリポジトリよりデータを復旧できることと、push/pullそれとMergeによる整合性
-	    の確保で、高いスケーラビリティを持っている</p>
-	</small>
+	  <h3>
+	      Jungleの分散設計
+	  </h3>
+	  <p>ここまでJungleに実装されている非破壊的木構造の利点について述べた。</p>
+	  <p>次に、Jungleにおける分散設計について述べる。</p>
+	  <p>データ分散を行うにあたり、まず考えることはトポロジーの形成と他のノードからデータの伝搬の仕方である。</p>
+	  <p>Jungleはこの問題に対し、ツリートポロジーを形成し、データ編集の際に発生するcommit logを他のノードに流すことで解決する。</p>
       </article>
 
       <article>
         <h3>
-	    Jungleの分散設計:分散版管理システム
-	</h3>
-	<p>Jungleと分散版管理システムには似通った点がある</p>
-	<li>どちらもデータのコピーが自由</li>
-	<li>データ更新しても過去のデータに影響を与えない</li>
-	<br/>
-	<p><font color="red">同じAPIを実装することで、分散版管理システムと同じく高いスケーラビリティが期待できる</font></p>
-	<p>具体的には</p>
-	<ul>
-	    <li>pushやpullによる定期的なデータの更新</li>
-	    <li>Mergeによる更新データ衝突の解決</li>
-	</ul>
-      </article>
-
-
-      <article>
-        <h3>
-	    Jungleの分散実装
-	</h3>
-	<p>ここまでJungleの分散設計について説明した。</p>
-	<br/>
-	<p>これらのシステムを実装する為にまずはJungleのノード同士でネットワークトポロジーを
-	組み、その上でデータをやりとりする機構が必要になる。</p>
-	<p>そこで、ネットワートポロジーを組みログによるデータの分散を行う仕組みをJungleに実装した。</p>
-	<p>また、Mergeの例として掲示板プログラムにおけるMergeの実装も行った。</p>
-      </article>
-
-      <article>
-        <h3>
-	    Jungleの分散実装：ログによるデータ分散
+	    Jungleの分散設計：トポロジー形成とログによるデータ分散
 	</h3>
 	<small>
-	<p>今回Jungleの分散実装は以下のように行った</p>
 	<table>
 	    <tr>
 		<th>ツリートポロジーを形成</th>
@@ -293,8 +240,32 @@
       </article>
 
       <article>
+	  <h3>
+	      データ更新衝突の解決
+	  </h3>
+	  <p>トポロジー形成とデータ伝搬手段については述べた。</p>
+	  <p>次に問題になることはデータの整合性をどのようにとるかである。</p>
+	  <p>例えば、ノードの持つデータが全て同じ値にしなければならない場合は、データを持つノード全てにロックを掛けて
+	      変更を加える必要がある。この方法はスケールしない。</p>
+	  <p>多少古い値を読んでも問題無く、結果整合性でよいというのなら幾つかのノードに書き込むだけで良い。こちらの方法はスケールする。</p>
+      </article>
+
+      <article>
+	  <h3>
+	      非破壊的木構造の利点を活かした分散設計	      
+	  </h3>
+	  <p>Jungleで扱うつもりのデータは結果整合性でもよいCMSを想定していることを始めに説明した。</p>
+	  <p>そこでJungleはMergeを使うことでデータの整合性をとることにした。</p>
+	  <p>Mergeとは、2つ以上の変更を1つの変更にまとめることである。</p>
+	  <p>分散システムにおいては、2つ以上のデータの更新が同じデータに対して行われていた場合、
+	  更新を受け取って新しいデータを作ることを指す。</p>
+	  <p>Mergeは自動で解決出来る場合とそうでない場合がある。</p>
+      </article>
+
+
+      <article>
         <h3>
-	    Mergeによる更新の衝突の解決
+	    Mergeによる更新の衝突を自然に解決
 	</h3>
 	<small>
 	<table style="font-size: 0.7em; width:100%;" >
@@ -310,9 +281,11 @@
 	</small>
       </article>
 
+
+
       <article>
         <h3>
-	    Mergeによる更新の衝突の解決ができない場合
+	    Mergeによる更新の衝突が自然に解決できない場合
 	</h3>
 	<table style="font-size: 0.7em; width:100%;" >
 	    <tr>
@@ -327,6 +300,31 @@
 
       <article>
         <h3>
+	    JungleとMergeの相性
+	</h3>
+	<p>Jungleは非破壊で過去のデータも保持しているため、更新時に過去のデータを参照して自然なMergeを行うことが可能。</p>
+	<p>自然にMergeできない場合においても、アプリケーション毎にMergeアルゴリズムを設計することで対応する。</p>
+	<p>Mergeが自動で行われるようになれば、Jungleで扱う木構造データは編集を自由に行うことができる。</p>
+	<p>木構造データが自由に行えるようになれば、Jungleはデータのリクエストに対して手元のデータを返すことができる。</p>
+	<p>古いデータを編集されたものが更新されても、いずれはMergeにより最新のデータと合わせられるから。</p>
+	<p></p>
+      </article>
+
+
+      <article>
+        <h3>
+	    Jungleの分散実装
+	</h3>
+	<p>以上がJungleにおける分散設計になる。</p>
+	<br/>
+	<p>この分散設計を元にJungleのサーバノード同士でツリトポロジーを構成し、ログによるデータ分散を実装した。</p>
+	<p>また、Mergeの例として掲示板プログラムにおけるMergeの実装も行った。</p>
+      </article>
+
+
+
+      <article>
+        <h3>
 	    Jungleの分散実装:掲示板システムにおけるMerge
 	</h3>
 	<p>Jungleではアプリケーション毎にMergeアルゴリズムを設計</p>
@@ -688,6 +686,55 @@
       </article>
 
 
+      <article>
+        <h3>
+	    Jungleの分散設計:分散版管理システム
+	</h3>
+	<p>Jungleは分散設計を行うにあたってGitやMercurialといった分散版管理システムを意識している</p>
+	<p style="margin-top:-10px;">分散版管理システムとは多人数によるソフトウェア開発において変更履歴を管理するシステム</p>
+	<p style="margin-top:-10px;">分散版管理システムは次の特徴とAPIを持つ</p>
+	<ul>
+	    <li>開発者それぞれがリポジトリのクローンしてローカルに持ち、開発はローカルのリポジトリを通すことで行われる</li>
+	    <li>ローカルのリポジトリは独立に存在し、サーバ上にある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる</li>
+	    <li>データ更新時に先に別の更新が入っていた(衝突)場合はMergeによりデータの整合性をとる</li>
+	</ul>
+      </article>
+
+      <article>
+        <h3>
+	    Jungleの分散設計:分散版管理システム	    
+	</h3>
+	<p>分散版管理システムAPI</p>
+	<ul style="margin-top:-20px;">
+	    <li>commit:データに変更を加えたことをリポジトリに登録</li>
+	    <li>push:ローカルのリポジトリで行った変更履歴を他のリポジトリへまとめて送る</li>
+	    <li>pull:他のリポジトリからの変更履歴をまとめて受け取る</li>
+	</ul>
+	<p style="text-align:center;">
+	<img style="height:200px;" src="./images/distributed_repository.png">
+	</p>
+	<small>
+	<p>分版版管理システムはリポジトリが壊れても別のリポジトリよりデータを復旧できることと、push/pullそれとMergeによる整合性
+	    の確保で、高いスケーラビリティを持っている</p>
+	</small>
+      </article>
+
+      <article>
+        <h3>
+	    Jungleの分散設計:分散版管理システム
+	</h3>
+	<p>Jungleと分散版管理システムには似通った点がある</p>
+	<li>どちらもデータのコピーが自由</li>
+	<li>データ更新しても過去のデータに影響を与えない</li>
+	<br/>
+	<p><font color="red">同じAPIを実装することで、分散版管理システムと同じく高いスケーラビリティが期待できる</font></p>
+	<p>具体的には</p>
+	<ul>
+	    <li>pushやpullによる定期的なデータの更新</li>
+	    <li>Mergeによる更新データ衝突の解決</li>
+	</ul>
+      </article>
+
 
     </section>