remove hr from patterns

rkuhn · rkuhn · commit f70995daeaeb · 2017-01-07T12:27:22.000+01:00
diff --git a/patterns/active–active.html b/patterns/active–active.html
@@ -19,7 +19,6 @@
 need a different strategy, but because there is no magic bullet, you must
 expect different restrictions.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/active–passive.html b/patterns/active–passive.html
@@ -17,7 +17,6 @@
 will forget all of its previous state and start from scratch. Imagine your web
 shop forgetting about all registered users—that would be a catastrophe!
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/aggregator.html b/patterns/aggregator.html
@@ -14,7 +14,6 @@
 means prolonging the time until the overall response can be sent back to the
 client, thus leaving an opportunity for latency reduction unused.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/ask-pattern.html b/patterns/ask-pattern.html
@@ -14,7 +14,6 @@
 
 * Traditional RPC systems are exclusively based on the premise of request-response calls, pretending the same semantics as a local procedure call. Their synchronous presentation results in distributed systems coupled in undesirable ways, as discussed throughout the first part of this book. In order to decouple caller and callee, the locally returned type is changed from a strict result value to a Future—a container for a result value that may arrive later. The continuation of the caller’s business process then needs to be lifted into the Future as well, using transformation combinators to perform the successive steps. This Future is an ephemeral component whose purpose is the reception of the eventual response and the initiation of follow-up actions, exactly like the child Actor in the previous bullet point.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/business-handshake.html b/patterns/business-handshake.html
@@ -22,7 +22,6 @@
 overshadowed by some other event. This second level is what the Business
 Handshake pattern is all about.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/circuit-breaker.html b/patterns/circuit-breaker.html
@@ -22,7 +22,6 @@
 failures; and second, the sender decides that requests will fail instead of
 wasting time with waiting for negative replies.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/complex-command.html b/patterns/complex-command.html
@@ -21,7 +21,6 @@
 loquacious interchanges between resource and users; the user of the resource is
 only interested in the comparatively small result.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/conflict-detection-and-resolution.html b/patterns/conflict-detection-and-resolution.html
@@ -12,7 +12,6 @@
 communication, so if all cluster nodes are to make progress in accepting and
 processing requests at all times, conflicting actions may be performed.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/conflict-free-replicated-data-types.html b/patterns/conflict-free-replicated-data-types.html
@@ -14,7 +14,6 @@
 possible to avoid conflicts while maintaining perfect availability without
 restricting the data types that can be expressed.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/consensus-based.html b/patterns/consensus-based.html
@@ -14,7 +14,6 @@
 words, if initially there are multiple competing proposals, and the group must
 decide which single one to support.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/domain-object.html b/patterns/domain-object.html
@@ -27,7 +27,6 @@
 and the ubiquitous language is the natural language in which domain experts
 describe the business function of the component.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/drop.html b/patterns/drop.html
@@ -21,7 +21,6 @@
 of Reactive systems need to be comfortable with the notion of sometimes
 deliberately losing messages.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/error-kernel.html b/patterns/error-kernel.html
@@ -18,7 +18,6 @@
 the JVM. The name Akka was originally conceived as a palindrome of Actor
 Kernel, referring to this core design pattern.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/event-sourcing.html b/patterns/event-sourcing.html
@@ -15,7 +15,6 @@
 described in 2005 by Martin Fowler  and picked up by Microsoft Research,  and
 it has shaped the design of the Akka Persistence module.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/event-stream.html b/patterns/event-stream.html
@@ -19,7 +19,6 @@
 also violate the Simple Component pattern by introducing a second
 responsibility.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/forward-flow.html b/patterns/forward-flow.html
@@ -15,7 +15,6 @@
 and increased response latency; thinking about forward flow lets you recognize
 these cases and improve your service quality.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/let-it-crash.html b/patterns/let-it-crash.html
@@ -22,7 +22,6 @@
 failure model and at the same time leads to a more robust system that even has
 a chance to survive failures that were entirely unforeseen.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/managed-blocking.html b/patterns/managed-blocking.html
@@ -17,7 +17,6 @@
 resources that are implicitly seized, most notably the threads required for
 their execution.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/managed-queue.html b/patterns/managed-queue.html
@@ -26,7 +26,6 @@
 cannot be slowed down, you need to mediate between the bounded internal
 capacity and the potentially unbounded influx.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/pull.html b/patterns/pull.html
@@ -19,7 +19,6 @@
 is also characterized as dynamic push-pull, an aspect that we will discuss
 later.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/request-response.html b/patterns/request-response.html
@@ -25,7 +25,6 @@
 B; when receiving requests, B will need to learn or deduce how to address A in
 order to send back a response.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/resource-encapsulation.html b/patterns/resource-encapsulation.html
@@ -22,7 +22,6 @@
 will lead you to identify the management of an external resource as a notable
 responsibility that needs to be broken out into its own simple component.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/resource-loan.html b/patterns/resource-loan.html
@@ -27,7 +27,6 @@
 drives the connection pool abstraction is useful in Reactive system design as
 well.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/resource-pool.html b/patterns/resource-pool.html
@@ -22,7 +22,6 @@
 reasoning presented in chapters 4 and 5, it relies heavily on asynchronous
 message passing and location transparency to achieve scalability.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/saga.html b/patterns/saga.html
@@ -22,7 +22,6 @@
 components? It turns out the research topic of sagas provides an effective,
 robust solution for many use cases.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/self-contained-message.html b/patterns/self-contained-message.html
@@ -20,7 +20,6 @@
 information should be considered a premature optimization until proven
 otherwise.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/sharding.html b/patterns/sharding.html
@@ -22,7 +22,6 @@
 by a fixed formula that can be evaluated whenever an object needs to be
 located.
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/simple-component.html b/patterns/simple-component.html
@@ -20,7 +20,6 @@
 object-oriented software design, it is usually stated as follows: “A class
 should have only one reason to change.”
 
----
 
 [back to the list](../categories.html)
 
diff --git a/patterns/throttling.html b/patterns/throttling.html
@@ -18,7 +18,6 @@
 to a request rate that is too high.  With the Pull pattern, you can turn this
 around and not generate requests more quickly than they are allowed to be sent.
 
----
 
 [back to the list](../categories.html)
 

Original file line number	Diff line number	Diff line change
`@@ -14,7 +14,6 @@`
`14`	`14`
`15`	`15`	* Traditional RPC systems are exclusively based on the premise of request-response calls, pretending the same semantics as a local procedure call. Their synchronous presentation results in distributed systems coupled in undesirable ways, as discussed throughout the first part of this book. In order to decouple caller and callee, the locally returned type is changed from a strict result value to a Future—a container for a result value that may arrive later. The continuation of the caller’s business process then needs to be lifted into the Future as well, using transformation combinators to perform the successive steps. This Future is an ephemeral component whose purpose is the reception of the eventual response and the initiation of follow-up actions, exactly like the child Actor in the previous bullet point.
`16`	`16`
`17`		`----`
`18`	`17`
`19`	`18`	`[back to the list](../categories.html)`
`20`	`19`