GitHub PullRequestReviewCommentEvent at 2014-12-23 08:09:25
Repository: reactivemanifesto
Actor: xuwei-k
Payload: {"action":"created","comment":{"url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/comments/22206416","id":22206416,"diff_hunk":"@@ -1,93 +1,92 @@\n-# Reactive Manifesto Glossary\n+# リアクティブ宣言 用語集\n \n-* [Asynchronous](#Asynchronous)\n-* [Back-Pressure](#Back-Pressure)\n-* [Batching](#Batching)\n-* [Delegation](#Delegation)\n-* [Component](#Component)\n-* [Elasticity (in contrast to Scalability)](#Elasticity)\n-* [Failure (in contrast to Error)](#Failure)\n-* [Isolation (and Containment)](#Isolation)\n-* [Location Transparency](#Location-Transparency)\n-* [Message-Driven (in contrast to Event-Driven)](#Message-Driven)\n-* [Non-Blocking](#Non-Blocking)\n-* [Protocol](#Protocol)\n-* [Replication](#Replication)\n-* [Resource](#Resource)\n-* [Scalability](#Scalability)\n-* [System](#System)\n-* [User](#User)\n+* [非同期](#Asynchronous)\n+* [バックプレッシャ](#Back-Pressure)\n+* [バッチ処理](#Batching)\n+* [委譲](#Delegation)\n+* [コンポーネント](#Component)\n+* [弾力性（拡張性と対比して）](#Elasticity)\n+* [障害（エラーと対比して）](#Failure)\n+* [隔離（と閉じ込め）](#Isolation)\n+* [位置透過性](#Location-Transparency)\n+* [メッセージ駆動（イベント駆動と対比して）](#Message-Driven)\n+* [ノンブロッキング](#Non-Blocking)\n+* [プロトコル](#Protocol)\n+* [レプリケーション](#Replication)\n+* [リソース](#Resource)\n+* [拡張性](#Scalability)\n+* [システム](#System)\n+* [ユーザ](#User)\n \n-## <a name=\"Asynchronous\"></a>Asynchronous\n-The Oxford Dictionary defines asynchronous as _“not existing or occurring at the same time”_. In the context of this manifesto we mean that the processing of a request occurs at an arbitrary point in time, sometime after it has been transmitted from client to service. The client cannot directly observe, or synchronize with, the execution that occurs within the service. This is the antonym of synchronous processing which implies that the client only resumes its own execution once the service has processed the request.\n+## <a name=\"Asynchronous\"></a>非同期 (Asynchronous)\n+オックスフォード辞典は、非同期を _”同時に存在したり起きたりしないこと”_ と定義している。リアクティブ宣言の文脈では、クライアントからサービスへ送信されたリクエストの処理が任意の時点で起きることを意味する。クライアントは、送信先のサービス内で起きる処理の実行を直接観察したり同期したりできない。同期処理では反対に、サービスがリクエストを処理するまでクライアントは自身の実行を再開できない。\n \n-## <a name=\"Back-Pressure\"></a>Back-Pressure\n-When one [component](#Component) is struggling to keep-up, the [system](#System) as a whole needs to respond in a sensible way. It is unacceptable for the component under stress to fail catastrophically or to drop messages in an uncontrolled fashion. Since it can’t cope and it can’t fail it should communicate the fact that it is under stress to upstream components and so get them to reduce the load. This back-pressure is an important feedback mechanism that allows systems to gracefully respond to load rather than collapse under it. The back-pressure may cascade all the way up to the user, at which point responsiveness may degrade, but this mechanism will ensure that the system is resilient under load, and will provide information that may allow the system itself to apply other resources to help distribute the load, see [Elasticity](#Elasticity).\n+## <a name=\"Back-Pressure\"></a>バックプレッシャ (Back-Pressure)\n+ある[コンポーネント](#Component)が懸命に稼働し続けようとしているとき、[システム](#System)全体は賢明なやり方で対処する必要がある。ストレスに晒されたコンポーネントが破滅的な障害を起こしたり、メッセージを制御不能なやり方で失うことは許容できない。うまく対処することも障害を起こすこともできないなら、コンポーネントは上流のコンポーネントに、自身がストレスを受けていることを伝えて負荷を減らしてもらうべきだ。こうしたバックプレッシャは重要なフィードバック機構であり、システムが破綻しないように負荷に対して優雅に対処できる。バックプレッシャをユーザまで転送してもよく、その場合は即応性が低下するが、負荷の下でのシステムの耐障害性を実現できる。また、システムがその情報を使って自身に他のリソースを振り向け、負荷分散を促すこともできる。[弾力性](#Elasticity)を参照。\n \n-## <a name=\"Batching\"></a>Batching\n-Current computers are optimized for the repeated execution of the same task: instruction caches and branch prediction increase the number of instructions that can be processed per second while keeping the clock frequency unchanged. This means that giving different tasks to the same CPU core in rapid succession will not benefit from the full performance that could otherwise be achieved: if possible we should structure the program such that its execution alternates less frequently between different tasks. This can mean processing a set of data elements in batches, or it can mean performing different processing steps on dedicated hardware threads.\n+## <a name=\"Batching\"></a>バッチ処理 (Batching)\n+現在のコンピュータは同じタスクを繰り返し実行することに最適化されており、命令キャッシュや分岐予測によって、クロック周波数が変わらない場合に一秒間に処理できる命令数が増加する。つまり、同じ CPU コアへ異なるタスクを立て続けに与えると性能をフルに活かせないので、異なるタスクを交互に実行する頻度を可能な限り少なくするようにプログラムを構築すべきだ。つまり、データ要素を集めてバッチで処理したり、異なる処理ステップを専用のハードウェアスレッドで実行したりすればよい。\n \n-The same reasoning applies to the use of external [resources](#Resource) that need synchronization and coordination. The I/O bandwidth offered by persistent storage devices can improve dramatically when issuing commands from a single thread (and thereby CPU core) instead of contending for bandwidth from all cores. Using a single entry point has the added advantage that operations can be reordered to better suit the optimal access patterns of the device (current storage devices perform better for linear than random access).\n+同期や協調を必要とする外部の[リソース](#Resource)を使うときにも、同様の推論が当てはまる。永続的ストレージ機器が提供する I/O 帯域幅は、単一のスレッド（と CPU コア）がコマンドを発行することで、全てのコアに帯域幅を争わせる場合よりも劇的に改善する。この方法のさらなる利点は、エントリポイントが単一なので、機器にとって最適なアクセスパターンへより適合するように、操作の順序を入れ替えられることだ。\n \n-Additionally, batching provides the opportunity to share out the cost of expensive operations such as I/O or expensive computations. For example, packing multiple data items into the same network packet or disk block to increase efficiency and reduce utilisation.\n+さらに、バッチ処理により I/O のような高価な操作や高価な計算のコストを分配できることがある。例えば、複数のデータ要素を同じネットワークパケットやディスクブロックにまとめることで、効率の向上と利用の削減ができる。\n \n-## <a name=\"Delegation\"></a>Delegation\n-Delegating a task [asynchronously](#Asynchronous) to another [component](#Component) means that the execution of the task will take place in the context of that other component. This delegated context could entail running in a different error handling context, on a different thread, in a different process, or on a different network node, to name a few possibilities. The purpose of delegation is to hand over the processing responsibility of a task to another component so that the delegating component can perform other processing or optionally observe the progress of the delegated task in case additional action is required such as handling failure or reporting progress.\n+## <a name=\"Delegation\"></a>委譲 (Delegation)\n+タスクを[非同期](#Asynchronous)に他の[コンポーネント](#Component)に委譲すると、そのタスクの実行は移譲先のコンポーネントのコンテキストで行われる。つまり、委譲されたタスクの実行は異なるエラー処理コンテキスト上や、異なるスレッド内、異なるプロセス内、異なるネットワークノード上で行われることがある。コンポーネントは、タスクを処理する責任をその他のコンポーネントへ委譲して他の処理を実行できるし、あるいは障害処理や進捗報告といった動作が必要な場合に、委譲したタスクの進捗を観察することもできる。\n \n-## <a name=\"Component\"></a>Component\n-What we are describing is a modular software architecture, which is a very old idea, see for example [Parnas (1972)](https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf). We are using the term “component” due to its proximity with compartment, which implies that each component is self-contained, encapsulated and [isolated](#Isolation) from other components. This notion applies foremost to the runtime characteristics of the system, but it will typically also be reflected in the source code’s module structure as well. While different components might make use of the same software modules to perform common tasks, the program code that defines the top-level behavior of each component is then a module of its own. Component boundaries are often closely aligned with [Bounded Contexts](http://martinfowler.com/bliki/BoundedContext.html) in the problem domain. This means that the system design tends to reflect the problem domain and so is easy to evolve, while retaining isolation. Message [protocols](#Protocol) provide a natural mapping and communications layer between Bounded Contexts (components).\n+## <a name=\"Component\"></a>コンポーネント (Component)\n+ここで述べるのはモジュール化されたソフトウェアアーキテクチャという、とても古くからあるアイデアだ。例えば [Parnas (1972)](https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf) を見てほしい。我々が”コンポーネント”という用語を使うのは、それが”仕切られた区画”に近いからだ。つまり、コンポーネントはそれぞれ自立しており、カプセル化されると共に他のコンポーネントから[隔離](#Isolation)される。この概念が最も当てはまるのはシステムの実行時特性に対してだが、一般的に同様にソースコードのモジュール構造にも反映される。異なるコンポーネントは、同じソフトウェアモジュールを用いて共通のタスクを実行するかもしれないが、そのとき、それぞれコンポーネントの最上位の動作を定義するプログラムコードはコンポーネント自身のモジュールだ。コンポーネント境界は、問題領域の[コンテキスト境界](http://martinfowler.com/bliki/BoundedContext.html)と密接なつながりがある。つまり、隔離が保たれていると、システム設計は問題領域を反映しやすいので容易に進化できる。メッセージ[プロトコル](#Protocol)は、コンテキスト（コンポーネント）境界の間の自然なマッピングと通信レイヤを提供する。\n \n-## <a name=\"Elasticity\"></a>Elasticity (in contrast to Scalability)\n-Elasticity means that the throughput of a system scales up or down automatically to meet varying demand as resource is proportionally added or removed. The system needs to be scalable (see [Scalability](#Scalability)) to allow it to benefit from the dynamic addition, or removal, of resources at runtime. Elasticity therefore builds upon scalability and expands on it by adding the notion of automatic [resource](#Resource) management.\n+## <a name=\"Elasticity\"></a>弾力性 (Elasticity)（拡張性と対比して）\n+弾力性とは、変化する要求を満たすために、リソースを比例的に追加または除去して、システムのスループットを自動的にスケールアップまたはスケールダウンすることだ。実行時におけるリソースの動的な追加や除去の恩恵を受けるには、システムはスケーラブル（[拡張性](#Scalability)を参照）である必要がある。弾力性は、つまり、拡張性に対して自動的な[リソース](#Resource)管理の概念を加えて拡張したものだ。\n \n-## <a name=\"Failure\"></a>Failure (in contrast to Error)\n-A failure is an unexpected event within a service that prevents it from continuing to function normally. A failure will generally prevent responses to the current, and possibly all following, client requests. This is in contrast with an error, which is an expected and coded-for condition—for example an error discovered during input validation, that will be communicated to the client as part of the normal processing of the message. Failures are unexpected and will require intervention before the [system](#System) can resume at the same level of operation. This does not mean that failures are always fatal, rather that some capacity of the system will be reduced following a failure. Errors are an expected part of normal operations, are dealt with immediately and the system will continue to operate at the same capacity following an error.\n+## <a name=\"Failure\"></a>障害 (Failure)（エラーと対比して）\n+障害はサービス内での予期しないイベントであり、サービスが正常に動作を続けられなくなる。障害が起きるとたいてい、現在の（場合によっては後に続く全ての）クライアントリクエストに応答できなくなる。これは、予期され状況に合わせてコード化されるエラーとは対照的だ。例えば、入力の検証中にエラーが見つかれば、それはメッセージの通常の処理の一部としてクライアントへ伝えられるだろう。障害は予期できないので、[システム](#System)が同等の動作レベルへ復旧しようとする前に介入する必要がある。これは、障害が致命的ではない場合でも、障害の後ではシステムのいくつかの能力が減少しているからだ。エラーは正常な動作の一部として予期されており、即座に対処されるので、システムはエラーの後でも同等の能力で動作を維持できる。\n \n-Examples of failures are hardware malfunction, processes terminating due to fatal resource exhaustion, program defects that result in corrupted internal state.\n+障害の例として、ハードウェアの誤動作や、リソースの枯渇によるプロセスの終了、内部状態を破損させるようなプログラムの欠陥が挙げられる。\n \n-## <a name=\"Isolation\"></a>Isolation (and Containment)\n-Isolation can be defined in terms of decoupling, both in time and space. Decoupling in time means that the sender and receiver can have independent life-cycles—they do not need to be present at the same time for communication to be possible. It is enabled by adding [asynchronous](#Asynchronous) boundaries between the [components](#Component), communicating through [message-passing](#Message-Driven). Decoupling in space (defined as [Location Transparency](#Location-Transparency)) means that the sender and receiver do not have to run in the same process, but wherever the operations division or the runtime itself decides is most efficient—which might change during an application's lifetime. \n+## <a name=\"Isolation\"></a>隔離（と閉じ込め） (Isolation (and Containment))\n+隔離は（時間と空間の双方における）疎結合によって定義できる。時間的疎結合とは、送信者と受信者がそれぞれ独立したライフサイクルを持てるという意味で、通信を可能とするために同時に存在している必要がない。これは、[コンポーネント](#Component)間に[非同期](#Asynchronous)境界を追加して[メッセージパッシング](#Message-Driven)で通信することで可能になる。（[位置透過性](#Location-Transparency)として定義される）空間的疎結合とは、送信者と受信者を同じプロセス内で実行する必要がないという意味だ。しかし、運用部門やランタイム自身が決めた場所が最も効率的だったとしても、それはアプリケーションの生存期間中に変わりうる。\n \n-True isolation goes beyond the notion of encapsulation found in most object-oriented languages and gives us compartmentalization and containment of:\n-* State and behavior: it enables share-nothing designs and minimizes contention and coherence cost (as defined in the [Universal Scalability Law](http://www.perfdynamics.com/Manifesto/USLscalability.html); \n-* Failures: it allows [errors](#Failure) to be captured, signalled and managed at a fine-grained level instead of letting them cascade to other components.\n+真の隔離は、オブジェクト指向言語において最も見られるカプセル化の概念を超えたところにあり、これらのものを区切って閉じ込めることができる:\n+* 状態と動作: シェアード・ナッシングな設計が可能になると共に、（[普遍的拡張性の法則](http://www.perfdynamics.com/Manifesto/USLscalability.html) が定義するような）競合および一貫性のコストを最小化する。\n+* 故障: [エラー](#Failure)を他のコンポーネントへ転送することなく、細粒度のレベルで捕捉し、シグナルし、管理できる。\n \n-Strong isolation between components is built on communication over well-defined [protocols](#Protocol) and enables loose coupling, leading to systems that are easier to understand, extend, test and evolve.\n+よく定義された[プロトコル](#Protocol)を介した通信はコンポーネント間の強い隔離を実現し、それにより疎結合になるので、システムの理解、拡張、テスト、進化がより容易になる。\n \n-## <a name=\"Location-Transparency\"></a>Location Transparency\n-[Elastic](#Elasticity) systems needs to be adaptive and continuously react to changes in demand, they need to gracefully and efficiently increase and decrease scale. One key insight that simplifies this problem immensely is to realize that we are all doing distributed computing. This is true whether we are running our systems on a single node (with multiple independent CPUs communicating over the QPI link) or on a cluster of nodes (with independent machines communicating over the network). Embracing this fact means that there is no conceptual difference between scaling vertically on multicore or horizontally on the cluster.\n+## <a name=\"Location-Transparency\"></a>位置透過性 (Location Transparency)\n+[弾力性](#Elasticity)のあるシステムは、適応的でかつ要求の変化に対して継続的に対応し、優雅かつ効率的にスケールを増減できる必要がある。一つの鍵となる洞察は、我々が行っている全ては分散コンピューティングであるということだ。そのことに気付くと、この問題は非常に簡潔になる。このことは、我々のシステムが実行されているのがシングルノード(QPI リンクを介して通信する複数の独立した CPU を備える)上であろうと、複数ノードのクラスタ（ネットワークを介して通信する独立したマシンを備える）上であろうと、同様に当てはまる。この事実から言えるのは、マルチコア上での垂直方向のスケーリングと、クラスタ上での水平方向のスケーリングとの間にコンセプトの違いはないということだ。\n \n-If all of our [components](#Component) support mobility, and local communication is just an optimization, then we do not have to define a static system topology and deployment model upfront. We can leave this decision to the operations personnel and the runtime, which can adapt and optimize the system depending on how it is used.\n+もし我々の[コンポーネント](#Component)が全て移動性をサポートしているなら、ローカルでの通信は単なる最適化であり、あらかじめシステムの静的なトポロジや配備モデルを定義しておく必要がなくなる。こうした決定を運用の人員やランタイムに任せることで、システムの適応化や最適化をそれがどのように使われるか次第で行うことができる。\n \n-This decoupling in space (see the the definition for [Isolation](#Isolation)), enabled through [asynchronous](#Asynchronous) [message-passing](#Message-Driven), and decoupling of the runtime instances from their references is what we call Location Transparency. Location Transparency is often mistaken for 'transparent distributed computing', while it is actually the opposite: we embrace the network and all its constraints—like partial failure, network splits, dropped messages, and its asynchronous and message-based nature—by making them first class in the programming model, instead of trying to emulate in-process method dispatch on the network (ala RPC, XA etc.). Our view of Location Transparency is in perfect agreement with [A Note On Distributed Computing](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7628) by Waldo et al.\n+この[非同期性](#Asynchronous)と[メッセージパッシング](#Message-Driven)により可能になる空間的疎結合（[隔離](#Isolation)の項での定義を見よ）と、ランタイムインスタンスをその参照から分離する疎結合を、我々は位置透過性と呼ぶ。位置透過性は”透過的な分散コンピューティング”としばしば誤解されるが、実際にはその反対だ。我々は、プロセス内のメソッド呼び出しを（RPC や XA のように）ネットワーク上でエミュレートするのではなく、ネットワークとその制約の全て（部分障害、ネットワーク分断、メッセージの喪失、そして非同期かつメッセージに基づくことによる性質）を受け入れて、プログラミングモデルの第一級市民として扱う。我々の位置透過性に対する見方は、Waldo らによる [A Note On Distributed Computing](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7628) と完全に一致する。\n \n-## <a name=\"Message-Driven\"></a>Message-Driven (in contrast to Event-Driven)\n-A message is an item of data that is sent to a specific destination. An event is a signal emitted by a [component](#Component) upon reaching a given state. In a message-driven system addressable recipients await the arrival of messages and react to them, otherwise lying dormant. In an event-driven system notification listeners are attached to the sources of events such that they are invoked when the event is emitted. This means that an event-driven system focuses on addressable event sources while a message-driven system concentrates on addressable recipients. A message can contain an encoded event as its payload.\n+## <a name=\"Message-Driven\"></a>メッセージ駆動 (Message-Driven)（イベント駆動と対比して）\n+メッセージは特定の宛先へと送られるデータ項目である。イベントは既定の状態に到達した[コンポーネント](#Component)から発生するシグナルである。メッセージ駆動のシステムでは、アドレス可能な受信者はメッセージの到着を待ってそれに反応するか、さもなくば休止状態になる。イベント駆動のシステムでは、通知のリスナーはイベントの発生源に取り付けられ、イベントが発生した時に呼び出される。つまり、イベント駆動システムがアドレス可能なイベントの発生源に焦点を当てるのに対して、メッセージ駆動システムはアドレス可能な受信者に専心している。メッセージは、自身のペイロードに符号化されたイベントを持つことができる。\n \n-Resilience is more difficult to achieve in an event-driven system due to the short-lived nature of event consumption chains: when processing is set in motion and listeners are attached in order to react to and transform the result, these listeners typically handle success or [failure](#Failure) directly and in the sense of reporting back to the original client. Responding to the failure of a component in order to restore its proper function, on the other hand, requires a treatment of these failures that is not tied to ephemeral client requests, but that responds to the overall component health state.\n+イベント駆動システムではイベント消費チェインの短命な性質故に、耐障害性の達成はより難しい。処理が開始されると共に取り付けられたリスナーはイベントに反応して結果へと変換する。このとき、リスナーは一般的に成功や[障害](#Failure)を直接に処理して元のクライアントへ報告を返す。一方で、コンポーネントの障害に反応してその機能を正常に回復させるには、これらの障害が短命なクライアントリクエストと結びつかないようにし、しかしあらゆるコンポーネントの健康状態に反応するように扱う必要がある。\n \n-## <a name=\"Non-Blocking\"></a>Non-Blocking\n-In concurrent programming an algorithm is considered non-blocking if threads competing for a resource do not have their execution indefinitely postponed by mutual exclusion protecting that resource. In practice this usually manifests as an API that allows access to the [resource](#Resource) if it is available otherwise it immediately returns informing the caller that the resource is not currently available or that the operation has been initiated and not yet completed. A non-blocking API to a resource allows the caller the option to do other work rather than be blocked waiting on the resource to become available. This may be complemented by allowing the client of the resource to register for getting notified when the resource is available or the operation has completed.\n+## <a name=\"Non-Blocking\"></a>ノンブロッキング (Non-Blocking)\n+並行プログラミングにおいて、一つのリソースを巡って競争する複数のスレッドが、それらのリソースを相互に排他的に保護することで無期限に実行が延期されるとき、あるアルゴリズムはノンブロッキングとみなされる。このことは、実際には API として明示される。API は、[リソース](#Resource)が利用可能ならアクセスさせ、そうでなければ直ちに返って、リソースが現時点では利用できなかったり、操作が開始されて未だ完了していないことを呼び出し元へ伝える。リソースに対するノンブロッキング API では、呼び出し元は、リソースが利用可能になるまでブロックして待つ代わりに他の仕事をすることができる。加えて、リソースのクライアントはリソースが利用可能になるか操作が完了したときに自身へ通知するよう登録することができる。\n \n-## <a name=\"Protocol\"></a>Protocol\n-A protocol defines the treatment and etiquette for the exchange or transmission of messages between [components](#Component). Protocols are formulated as relations between the participants to the exchange, the accumulated state of the protocol and the allowed set of messages to be sent. This means that a protocol describes which messages a participant may send to another participant at any given point in time. Protocols can be classified by the shape of the exchange, some common classes are request–reply, repeated request–reply (as in HTTP), publish–subscribe, and stream (both push and pull).\n+## <a name=\"Protocol\"></a>プロトコル (Protocol)\n+プロトコルは、[コンポーネント](#Component)間でのメッセージの交換や転送に対する取り扱いと作法を定義する。プロトコルの策定は、メッセージ交換に参加する者同士の関係、プロトコルの累積的な状態、そして送信可能なメッセージの集合によってなされる。つまりプロトコルは、参加者が任意の時点で他の参加者へ送信できるメッセージを定義する。プロトコルは、交換におけるいくつかの共通の形体（要求-応答型、（HTTP におけるような）繰り返される要求-応答型、出版-購読型、プッシュ型やプル型のストリーム）に分類できる。\n \n-In comparison to local programming interfaces a protocol is more generic since it can include more than two participants and it foresees a progression of the state of the message exchange; an interface only specifies one interaction at a time between the caller and the receiver.\n+ローカルなプログラミングインタフェースと比べて、プロトコルはより一般的だ。なぜなら、インタフェースは呼び出し元と受信者の間の相互作用を一つずつしか指定できないのに対して、プロトコルは二人以上の参加者を含むことができ、またメッセージ交換の状態の進行を予見するからだ。\n \n-It should be noted that a protocol as defined here just specifies which messages may be sent, but not how they are sent: encoding, decoding (i.e. codecs), and transport mechanisms are implementation details that are transparent to the components’ use of the protocol.\n+注目すべきは、ここで定義したプロトコルはどんなメッセージを送ることができるかのみを指定しており、どうやって送るかは指定していないということだ。符号化や復号を行うコーデックや転送メカニズムといった実装の詳細は、プロトコルを使用するプロトコルにとって透過的だ。","path":"glossary.ja.md","position":131,"original_position":131,"commit_id":"946e3054397ae6487a92b090a090a8ef741a4676","original_commit_id":"946e3054397ae6487a92b090a090a8ef741a4676","user":{"login":"xuwei-k","id":389787,"avatar_url":"https://avatars.githubusercontent.com/u/389787?v=3","gravatar_id":"","url":"https://api.github.com/users/xuwei-k","html_url":"https://github.com/xuwei-k","followers_url":"https://api.github.com/users/xuwei-k/followers","following_url":"https://api.github.com/users/xuwei-k/following{/other_user}","gists_url":"https://api.github.com/users/xuwei-k/gists{/gist_id}","starred_url":"https://api.github.com/users/xuwei-k/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xuwei-k/subscriptions","organizations_url":"https://api.github.com/users/xuwei-k/orgs","repos_url":"https://api.github.com/users/xuwei-k/repos","events_url":"https://api.github.com/users/xuwei-k/events{/privacy}","received_events_url":"https://api.github.com/users/xuwei-k/received_events","type":"User","site_admin":false},"body":"> プロトコルを使用するプロトコル\r\n\r\nとは？ `components` の単語がなくなってる？","created_at":"2014-12-23T08:09:25Z","updated_at":"2014-12-23T08:09:25Z","html_url":"https://github.com/reactivemanifesto/reactivemanifesto/pull/39#discussion_r22206416","pull_request_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/39","_links":{"self":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/comments/22206416"},"html":{"href":"https://github.com/reactivemanifesto/reactivemanifesto/pull/39#discussion_r22206416"},"pull_request":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/39"}}},"pull_request":{"url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/39","id":26498864,"html_url":"https://github.com/reactivemanifesto/reactivemanifesto/pull/39","diff_url":"https://github.com/reactivemanifesto/reactivemanifesto/pull/39.diff","patch_url":"https://github.com/reactivemanifesto/reactivemanifesto/pull/39.patch","issue_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/issues/39","number":39,"state":"open","locked":false,"title":"Japanese version of the glossary","user":{"login":"okapies","id":657642,"avatar_url":"https://avatars.githubusercontent.com/u/657642?v=3","gravatar_id":"","url":"https://api.github.com/users/okapies","html_url":"https://github.com/okapies","followers_url":"https://api.github.com/users/okapies/followers","following_url":"https://api.github.com/users/okapies/following{/other_user}","gists_url":"https://api.github.com/users/okapies/gists{/gist_id}","starred_url":"https://api.github.com/users/okapies/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/okapies/subscriptions","organizations_url":"https://api.github.com/users/okapies/orgs","repos_url":"https://api.github.com/users/okapies/repos","events_url":"https://api.github.com/users/okapies/events{/privacy}","received_events_url":"https://api.github.com/users/okapies/received_events","type":"User","site_admin":false},"body":"Translates the glossary page into Japanese, and fix a word selection of \"containment\" in the manifesto. I'm very sorry it took me so long.\r\n\r\n@eed3si9n さん、毎度で恐縮ですがレビューをお願いします。\r\n","created_at":"2014-12-23T07:54:40Z","updated_at":"2014-12-23T08:09:25Z","closed_at":null,"merged_at":null,"merge_commit_sha":"d5086bdf9a606a96639ffebd32e0607c5ceb9679","assignee":null,"milestone":null,"commits_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/39/commits","review_comments_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/39/comments","review_comment_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/comments/{number}","comments_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/issues/39/comments","statuses_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/statuses/946e3054397ae6487a92b090a090a8ef741a4676","head":{"label":"okapies:trans_ja_terms","ref":"trans_ja_terms","sha":"946e3054397ae6487a92b090a090a8ef741a4676","user":{"login":"okapies","id":657642,"avatar_url":"https://avatars.githubusercontent.com/u/657642?v=3","gravatar_id":"","url":"https://api.github.com/users/okapies","html_url":"https://github.com/okapies","followers_url":"https://api.github.com/users/okapies/followers","following_url":"https://api.github.com/users/okapies/following{/other_user}","gists_url":"https://api.github.com/users/okapies/gists{/gist_id}","starred_url":"https://api.github.com/users/okapies/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/okapies/subscriptions","organizations_url":"https://api.github.com/users/okapies/orgs","repos_url":"https://api.github.com/users/okapies/repos","events_url":"https://api.github.com/users/okapies/events{/privacy}","received_events_url":"https://api.github.com/users/okapies/received_events","type":"User","site_admin":false},"repo":{"id":27487994,"name":"reactivemanifesto","full_name":"okapies/reactivemanifesto","owner":{"login":"okapies","id":657642,"avatar_url":"https://avatars.githubusercontent.com/u/657642?v=3","gravatar_id":"","url":"https://api.github.com/users/okapies","html_url":"https://github.com/okapies","followers_url":"https://api.github.com/users/okapies/followers","following_url":"https://api.github.com/users/okapies/following{/other_user}","gists_url":"https://api.github.com/users/okapies/gists{/gist_id}","starred_url":"https://api.github.com/users/okapies/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/okapies/subscriptions","organizations_url":"https://api.github.com/users/okapies/orgs","repos_url":"https://api.github.com/users/okapies/repos","events_url":"https://api.github.com/users/okapies/events{/privacy}","received_events_url":"https://api.github.com/users/okapies/received_events","type":"User","site_admin":false},"private":false,"html_url":"https://github.com/okapies/reactivemanifesto","description":"The Reactive Manifesto","fork":true,"url":"https://api.github.com/repos/okapies/reactivemanifesto","forks_url":"https://api.github.com/repos/okapies/reactivemanifesto/forks","keys_url":"https://api.github.com/repos/okapies/reactivemanifesto/keys{/key_id}","collaborators_url":"https://api.github.com/repos/okapies/reactivemanifesto/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/okapies/reactivemanifesto/teams","hooks_url":"https://api.github.com/repos/okapies/reactivemanifesto/hooks","issue_events_url":"https://api.github.com/repos/okapies/reactivemanifesto/issues/events{/number}","events_url":"https://api.github.com/repos/okapies/reactivemanifesto/events","assignees_url":"https://api.github.com/repos/okapies/reactivemanifesto/assignees{/user}","branches_url":"https://api.github.com/repos/okapies/reactivemanifesto/branches{/branch}","tags_url":"https://api.github.com/repos/okapies/reactivemanifesto/tags","blobs_url":"https://api.github.com/repos/okapies/reactivemanifesto/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/okapies/reactivemanifesto/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/okapies/reactivemanifesto/git/refs{/sha}","trees_url":"https://api.github.com/repos/okapies/reactivemanifesto/git/trees{/sha}","statuses_url":"https://api.github.com/repos/okapies/reactivemanifesto/statuses/{sha}","languages_url":"https://api.github.com/repos/okapies/reactivemanifesto/languages","stargazers_url":"https://api.github.com/repos/okapies/reactivemanifesto/stargazers","contributors_url":"https://api.github.com/repos/okapies/reactivemanifesto/contributors","subscribers_url":"https://api.github.com/repos/okapies/reactivemanifesto/subscribers","subscription_url":"https://api.github.com/repos/okapies/reactivemanifesto/subscription","commits_url":"https://api.github.com/repos/okapies/reactivemanifesto/commits{/sha}","git_commits_url":"https://api.github.com/repos/okapies/reactivemanifesto/git/commits{/sha}","comments_url":"https://api.github.com/repos/okapies/reactivemanifesto/comments{/number}","issue_comment_url":"https://api.github.com/repos/okapies/reactivemanifesto/issues/comments/{number}","contents_url":"https://api.github.com/repos/okapies/reactivemanifesto/contents/{+path}","compare_url":"https://api.github.com/repos/okapies/reactivemanifesto/compare/{base}...{head}","merges_url":"https://api.github.com/repos/okapies/reactivemanifesto/merges","archive_url":"https://api.github.com/repos/okapies/reactivemanifesto/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/okapies/reactivemanifesto/downloads","issues_url":"https://api.github.com/repos/okapies/reactivemanifesto/issues{/number}","pulls_url":"https://api.github.com/repos/okapies/reactivemanifesto/pulls{/number}","milestones_url":"https://api.github.com/repos/okapies/reactivemanifesto/milestones{/number}","notifications_url":"https://api.github.com/repos/okapies/reactivemanifesto/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/okapies/reactivemanifesto/labels{/name}","releases_url":"https://api.github.com/repos/okapies/reactivemanifesto/releases{/id}","created_at":"2014-12-03T13:18:00Z","updated_at":"2014-11-07T10:52:17Z","pushed_at":"2014-12-23T07:40:28Z","git_url":"git://github.com/okapies/reactivemanifesto.git","ssh_url":"git@github.com:okapies/reactivemanifesto.git","clone_url":"https://github.com/okapies/reactivemanifesto.git","svn_url":"https://github.com/okapies/reactivemanifesto","homepage":"reactivemanifesto.org","size":428,"stargazers_count":0,"watchers_count":0,"language":null,"has_issues":false,"has_downloads":true,"has_wiki":false,"has_pages":false,"forks_count":0,"mirror_url":null,"open_issues_count":0,"forks":0,"open_issues":0,"watchers":0,"default_branch":"master"}},"base":{"label":"reactivemanifesto:master","ref":"master","sha":"961371db74dd9d45ab7f67c60eafaf4cf88a66d9","user":{"login":"reactivemanifesto","id":5033365,"avatar_url":"https://avatars.githubusercontent.com/u/5033365?v=3","gravatar_id":"","url":"https://api.github.com/users/reactivemanifesto","html_url":"https://github.com/reactivemanifesto","followers_url":"https://api.github.com/users/reactivemanifesto/followers","following_url":"https://api.github.com/users/reactivemanifesto/following{/other_user}","gists_url":"https://api.github.com/users/reactivemanifesto/gists{/gist_id}","starred_url":"https://api.github.com/users/reactivemanifesto/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/reactivemanifesto/subscriptions","organizations_url":"https://api.github.com/users/reactivemanifesto/orgs","repos_url":"https://api.github.com/users/reactivemanifesto/repos","events_url":"https://api.github.com/users/reactivemanifesto/events{/privacy}","received_events_url":"https://api.github.com/users/reactivemanifesto/received_events","type":"Organization","site_admin":false},"repo":{"id":11484011,"name":"reactivemanifesto","full_name":"reactivemanifesto/reactivemanifesto","owner":{"login":"reactivemanifesto","id":5033365,"avatar_url":"https://avatars.githubusercontent.com/u/5033365?v=3","gravatar_id":"","url":"https://api.github.com/users/reactivemanifesto","html_url":"https://github.com/reactivemanifesto","followers_url":"https://api.github.com/users/reactivemanifesto/followers","following_url":"https://api.github.com/users/reactivemanifesto/following{/other_user}","gists_url":"https://api.github.com/users/reactivemanifesto/gists{/gist_id}","starred_url":"https://api.github.com/users/reactivemanifesto/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/reactivemanifesto/subscriptions","organizations_url":"https://api.github.com/users/reactivemanifesto/orgs","repos_url":"https://api.github.com/users/reactivemanifesto/repos","events_url":"https://api.github.com/users/reactivemanifesto/events{/privacy}","received_events_url":"https://api.github.com/users/reactivemanifesto/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/reactivemanifesto/reactivemanifesto","description":"The Reactive Manifesto","fork":false,"url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto","forks_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/forks","keys_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/keys{/key_id}","collaborators_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/teams","hooks_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/hooks","issue_events_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/issues/events{/number}","events_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/events","assignees_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/assignees{/user}","branches_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/branches{/branch}","tags_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/tags","blobs_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/git/refs{/sha}","trees_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/git/trees{/sha}","statuses_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/statuses/{sha}","languages_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/languages","stargazers_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/stargazers","contributors_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/contributors","subscribers_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/subscribers","subscription_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/subscription","commits_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/commits{/sha}","git_commits_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/git/commits{/sha}","comments_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/comments{/number}","issue_comment_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/issues/comments/{number}","contents_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/contents/{+path}","compare_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/compare/{base}...{head}","merges_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/merges","archive_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/downloads","issues_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/issues{/number}","pulls_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls{/number}","milestones_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/milestones{/number}","notifications_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/labels{/name}","releases_url":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/releases{/id}","created_at":"2013-07-17T18:29:33Z","updated_at":"2014-12-17T15:08:46Z","pushed_at":"2014-12-21T16:37:07Z","git_url":"git://github.com/reactivemanifesto/reactivemanifesto.git","ssh_url":"git@github.com:reactivemanifesto/reactivemanifesto.git","clone_url":"https://github.com/reactivemanifesto/reactivemanifesto.git","svn_url":"https://github.com/reactivemanifesto/reactivemanifesto","homepage":"reactivemanifesto.org","size":624,"stargazers_count":139,"watchers_count":139,"language":null,"has_issues":true,"has_downloads":true,"has_wiki":false,"has_pages":false,"forks_count":37,"mirror_url":null,"open_issues_count":2,"forks":37,"open_issues":2,"watchers":139,"default_branch":"master"}},"_links":{"self":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/39"},"html":{"href":"https://github.com/reactivemanifesto/reactivemanifesto/pull/39"},"issue":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/issues/39"},"comments":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/issues/39/comments"},"review_comments":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/39/comments"},"review_comment":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/comments/{number}"},"commits":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/pulls/39/commits"},"statuses":{"href":"https://api.github.com/repos/reactivemanifesto/reactivemanifesto/statuses/946e3054397ae6487a92b090a090a8ef741a4676"}}}}