fix issue #3 from patch

editions/1/ja/recipes.html

@@ -38,10 +38,10 @@ <h4 id="erasers">経理部は消しゴムを使わない</h4>
 <p>最近では銀行はすべて電子化されています(そしてそれはしばらくは変わらないでしょう)。すぐに送られることを望んでいる送金でも、失敗した時には、一日のうちに返金されるような動きを期待しています。自分の口座からお金を取り出し、ポールの口座に追加し、そしてもし何か良くないことが起きたら、自分の口座に戻るような動作です。これは起きたことへの論理的な理解で、裏でどのようなことが行われているのか全く分かりません。コンピュータが銀行で使われる前からもそうです。
 
 <p>When you go to your bank and ask it to send money to Paul, the accountant will <em>start a transaction</em> by noting down that you ordered the sending of the money. The transaction will include the date, amount, and recipient. Remember that banks always need to be in balance. The money taken from your account cannot vanish. The accountant will move the money into an <em>in-transit</em> account that the bank maintains for you. Your account balance at this point is an aggregation of your current balance and the transactions in the in-transit account. Now the bank checks whether Paul’s account is what you say it is and whether the money could arrive there safely. If that’s the case, the money is moved in another single transaction from the in-transit account to Paul’s account. Everything is in balance. Notice how there are multiple independent transactions, not one big transaction that combines a number of actions.
-<p>あなたが銀行へ行き、ポールにお金を送ることを伝えたとき、銀行員はあなたから送金を依頼されたことを書き留めて、トランザクションを開始します。トランザクションには、日付や金額、領収書が含まれます。銀行は常に調和を必要としていることを思い出してください。あなたの口座から取り出されたお金は消えてはいけません。銀行員はあなたの情報を管理しつつ、<em>転送中</em>口座にお金を移動させます。この時点でのあなたの口座の額は、現在の口座の金額と転送中口座のトランザクションの金額の合計です。このとき、銀行はポールの口座が存在しているかどうか、お金が安全にそこへ到着したかどうあかを確認します。もし問題なければ、別のトランザクションでお金を転送中口座からポールの口座へ移動させます。すべては調和の中にいます。多くの複数の独立したトランザクションが存在していることに注意してください、たくさんの処理をまとめた一つの大きなトランザクションがあるわけではありません。
+<p>あなたが銀行へ行き、ポールにお金を送ることを伝えたとき、銀行員はあなたから送金を依頼されたことを書き留めて、トランザクションを開始します。トランザクションには、日付や金額、領収書が含まれます。銀行は常に調和を必要としていることを思い出してください。あなたの口座から取り出されたお金は消えてはいけません。銀行員はあなたの情報を管理しつつ、<em>転送中</em>口座にお金を移動させます。この時点でのあなたの口座の額は、現在の口座の金額と転送中口座のトランザクションの金額の合計です。このとき、銀行はポールの口座が存在しているかどうか、お金が安全にそこへ到着したかどうかを確認します。もし問題なければ、別のトランザクションでお金を転送中口座からポールの口座へ移動させます。すべては調和の中にいます。多くの複数の独立したトランザクションが存在していることに注意してください、たくさんの処理をまとめた一つの大きなトランザクションがあるわけではありません。
 
 <p>Now let’s consider an error case: say Paul’s account no longer exists. The bank finds this out while performing the batch operation of all the in-transit transactions that need to be performed. A second transaction is generated that moves the money back from the in-transit account to your bank account. Note that the transaction that moved the money out of your account is <em>not</em> undone. Rather, a second transaction that does the reverse action is created.
-<p>別のエラーの場合を考えてみましょう。あなたがポールへ$100送金しようとして、十分な金額が無かったとします。これは、銀行がお金を減らすトランザクションを生成する前に、銀行員(もしくはソフトウェア)によってチェックされます。説明すると、銀行は処理が発生しなかったふりをすることはできません。それは全ての処理がログに記録されなければならないからです。返金処理のために、明確に取り消し処理が実行され、すでに存在するトランザクションを取り消したり、削除することはできません。"銀行員は消しゴムを使わない"はMicrosoftとAmazonで働いていたトランザクションシステムのシニアアーキテクトであるPat Hellandの言葉です。
+<p>別のエラーの場合を考えてみましょう。あなたがポールへ$100送金しようとして、十分な金額が無かったとします。これは、銀行がお金を減らすトランザクションを生成する前に、銀行員(もしくはソフトウェア)によってチェックされます。説明すると、銀行は処理が発生しなかったふりをすることはできません。それは全ての処理がログに記録されなければならないからです。返金処理のために、明確に取り消し処理が実行され、すでに存在するトランザクションを取り消したり、削除することはできません。
 
 <p>Here’s another error case: say you don’t have sufficient funds to send $100 to Paul. This will be checked by the accountant (or software) before the bank creates any money-deducting transaction. For accountability, a bank cannot pretend an action didn’t happen; it has to record every action minutely in a log. Undoing is done explicitly by performing a reverse action, not by reverting or removing an existing transaction. “Accountants don’t use erasers” is a quote from Pat Helland, a senior architect of transactional systems who worked at Microsoft and Amazon.
 <p>別のエラーの場合を考えてみましょう。あなたがポールへ$100送金しようとして、十分な金額が無かったとします。これは、銀行がお金を減らすトランザクションを生成する前に、銀行員(もしくはソフトウェア)によってチェックされます。説明すると、銀行は処理が発生しなかったふりをすることはできません。それは全ての処理がログに記録されなければならないからです。返金処理のために、明確に取り消し処理が実行され、すでに存在するトランザクションを取り消したり、削除することはできません。"銀行員は消しゴムを使わない"はMicrosoftとAmazonで働いていたトランザクションシステムのシニアアーキテクトであるPat Hellandの言葉です。
@@ -64,7 +64,7 @@ <h4 id="erasers">経理部は消しゴムを使わない</h4>
 </pre>
 
 <p>Single document writes in CouchDB are atomic. Querying a view forces an update to the view index with all changes to all documents. The view result is always consistent with the data in our documents. This guarantees that our bank is always in balance. There are many more transactions, of course, but these will do for illustration purposes.
-<p>CouchDBでの一つのドキュメントの書き込みはアトミックです。ビューを要求すると、すゔぇてのドキュメントに対して、すべての変更のビューインデックスの更新を強制的に行います。ビューの結果はドキュメントのデータと共に常に一貫性があります。これは、銀行が常に調和が取れていることを保証しています。たくさんのトランザクションがあっても、もちろん、これらは意図したとおりに動きます。
+<p>CouchDBでの一つのドキュメントの書き込みはアトミックです。ビューを要求すると、すべてのドキュメントに対して、すべての変更のビューインデックスの更新を強制的に行います。ビューの結果はドキュメントのデータと共に常に一貫性があります。これは、銀行が常に調和が取れていることを保証しています。たくさんのトランザクションがあっても、もちろん、これらは意図したとおりに動きます。
 
 <p>How do we read the current account balance? Easy—create a MapReduce view:
 <p>どのように現在の口座の金額を読めばよいでしょうか？簡単です、MapReduceビューを作ります。
@@ -220,13 +220,13 @@ <h4 id="integers">数値のリスト</h4>
 </ol>
 
 <p>Under the hood, this is a lot of work. With CouchDB you’d have to load every document, increment the <code>sort_order</code>, and save it back. If you have a lot of to-do items (I do), then this is some significant work. Maybe there’s a better approach.
-<p>内部的には、たくさんのやることがあります。CouchDBで全てのドキュメント読み込まなくてはならず、<code>sort_order</code>をインクリメントし、保存して戻します。もし、大量の(やろうとしている)ToDoがある場合、いくつかの重要な動作があり、おそらくより良い方法があります。
+<p>内部的には、たくさんのやることがあります。CouchDBで全てのドキュメントを読み込まなくてはならず、<code>sort_order</code>をインクリメントし、保存して戻します。もし、大量の(やろうとしている)ToDoがある場合、いくつかの重要な動作があり、おそらくより良い方法があります。
 
 <h4 id="floats">A List of Floats</h4>
 <h4 id="floats">小数点数のリスト </h4>
 
 <p>The fix is simple: instead of using an integer to specify the sort order, we use a float:
-<p>修正は簡単です。並び順を指定する為に整数を使う代わりに 、小数点数使います。
+<p>修正は簡単です。並び順を指定する為に整数を使う代わりに 、小数点数を使います。
 
 <pre>
 {
@@ -505,7 +505,7 @@ <h4 id="fast">Fast Paging (Do Use)</h4>
 <h4 id="fast">１ページ (使って)</h4>
 
 <p>The correct solution is not much harder. Instead of slicing the result set into equally sized pages, we look at 10 rows at a time and use <code>startkey</code> to jump to the next 10 rows. We even use <code>skip</code>, but only with the value <code>1</code>.
-<p>正しい解決方法は、すごく難しいものではありません。結果全体を同じサイズのページに分割する変わりに、一回で10行を検索し、<code>startkey</code>を次の10行を得るために使います。私たちは<code>skip</code>を使いますが、値は常に<code>1</code>です。
+<p>正しい解決方法は、すごく難しいものではありません。結果全体を同じサイズのページに分割する代わりに、一回で10行を検索し、<code>startkey</code>を次の10行を得るために使います。私たちは<code>skip</code>を使いますが、値は常に<code>1</code>です。
 
 <p>Here is how it works:
 <p>どのように動作するかを示します。
@@ -527,7 +527,7 @@ <h4 id="fast">１ページ (使って)</h4>
 </ul>
 
 <p>The trick to finding the next page is pretty simple. Instead of requesting 10 rows for a page, you request 11 rows, but display only 10 and use the values in the 11th row as the <code>startkey</code> for the next page. Populating the link to the previous page is as simple as carrying the current <code>startkey</code> over to the next page. If there’s no previous <code>startkey</code>, we are on the first page. We stop displaying the link to the next page if we get <code>rows_per_page</code> or less rows back. This is called <em>linked list pagination</em>, as we go from page to page, or list item to list item, instead of jumping directly to a pre-computed page. There is one caveat, though. Can you spot it?
-<p>次のページを探す種はとても簡単です。１ページ用に１０行リクエストする変わりに、１１行リクエストします。しかし、１０行だけを表示し、１１行目の値は次のページのための<code>startkey</code>として利用します。前のページへのリンクを作成するには、次のページへ行くための現在の<code>startkey</code>を持ち運ぶぐらい簡単です。もし前の<code>startkey</code>が無いなら、そこは最初のページです。もし<code>rows_per_page</code>が得られるか戻る行が無い場合は、次のページへのリンクを表示することを行いません。これは<em>Linked Listページネーション</em>と呼ばれます。ページからページへの移動やリストからリストへの移動を、事前計算したページへ直接移動する代わりに行います。ですが、覚え書きがあります。検討はつきますか？
+<p>次のページを探す種はとても簡単です。１ページ用に１０行リクエストする代わりに、１１行リクエストします。しかし、１０行だけを表示し、１１行目の値は次のページのための<code>startkey</code>として利用します。前のページへのリンクを作成するには、次のページへ行くための現在の<code>startkey</code>を持ち運ぶぐらい簡単です。もし前の<code>startkey</code>が無いなら、そこは最初のページです。もし<code>rows_per_page</code>が得られるか戻る行が無い場合は、次のページへのリンクを表示することを行いません。これは<em>Linked Listページネーション</em>と呼ばれます。ページからページへの移動やリストからリストへの移動を、事前計算したページへ直接移動する代わりに行います。ですが、覚え書きがあります。検討はつきますか？
 
 <p>CouchDB view keys do not have to be unique; you can have multiple index entries <em>read</em>. What if you have more index entries for a key than rows that should be on a page? <code>startkey</code> jumps to the first row, and you’d be screwed if CouchDB didn’t have an additional parameter for you to use. All view keys with the same value are internally sorted by <code>docid</code>, that is, the ID of the document that created that view row. You can use the <code>startkey_docid</code> and <code>endkey_docid</code> parameters to get subsets of these rows. For pagination, we still don’t need <code>endkey_docid</code>, but <code>startkey_docid</code> is very handy. In addition to <code>startkey</code> and <code>limit</code>, you also use <code>startkey_docid</code> for pagination if, and only if, the extra row you fetch to find the next page has the same key as the current <code>startkey</code>.
 <P>CouchDBのビューのキーはユニークでなくても構いません。複数の<em>read</em>インデックスを持つことも可能です。もし今の行よりもインデックスを持つなら、何をページにするべきでしょうか？<code>startkey</code>は始めの行に移動します。そして、もし利用する追加のパラメータをCouchDBが持っていなければ、きっと困惑するでしょう。同じ値のキーを持つビューは、<code>docid</code>で並べられます。<code>docid</code>はビューとして作られたドキュメントのIDです。得られるビューの中から、<code>startkey_docid</code>と<code>endkey_docid</code>を使い、部分的に得ることができます。ページ構造を作るなら、まだ<code>endkey_docid</code>は必要ではありませんが、<code>startkey_docid</code>はとても有効です。<code>startkey</code>と<code>limit</code>に加えて、<code>startkey_docid</code>をページ構成に利用し、次のページを見つけるための特別な行が現在の<code>startkey</code>のような同じキーを持ちます。