Brian Topping (22) [Avatar] Offline
#1
Guys, this is absolutely excellent book that you have coming together!

I've already sent the first chapter to a few technical stakeholders so they can get a better understanding of why I have been pressing this particular architecture. These folks can kill a project with a single email, and it would be spectacular if the content of the chapter remained as accessible to people like them as it is today, all the way through.

Thanks! Brian
roland.kuhn (39) [Avatar] Offline
#2
Re: Kudos and chapter 1 thoughts
Thanks for confirming that the plan behind the first chapter is working smilie Making it less accessible is definitely not on the agenda!
joostdevries (1) [Avatar] Offline
#3
Re: Kudos and chapter 1 thoughts
I've been reading chapter 1 as well. Here are some thoughts:

Buying a book with 'patterns' in the title I was expecting/hoping for something that describes 'reactive' solutions from a perspective of 'what are you trying to solve', 'when is it appropriate', 'when is it not appropriate', 'what are alternatives'. Something that you get rather automatically when you follow the traditional template for describing a pattern http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Documentation
I think Martin Fowler is pretty good at writing up that kind of thing in a tech independent readable format.

And I expected that some patterns would transcend actors-only. F.i. I'm guessing that some parts of reacting to events was already used in solutions that use reliable messaging.
But so far it strikes me as rather Manifesto like and actors-are-the-answer-to-everything. I'm exagerating a bit. But you get my point.
Similarly while reading I started to contrast for myself the strengths and weaknesses of call-response/callstack development vs async development. Personally I think that call-response still has its strengths and often is still a valid choice. F.i. because the call stack makes it easier to analyse the context within which something is happening. And communicating failure to the client is easier.

For me the principles of reactive programming felt a bit coming-out-of-thin-air. It made me wonder: why these principles and not others?

Here's an article by Gregor Hohpe on TPC vs async processing. I think real world processes can make implications and trade offs of async processing more intuitive. http://www.eaipatterns.com/ramblings/18_starbucks.html
Maglic (6) [Avatar] Offline
#4
Re: Kudos and chapter 1 thoughts
I just started reading Chapter 1 of Reactive Design Patterns.
I have never done reactive programming before, but I bought the book since I want to learn more about it and how to design applications in such a manner. Basically, I like the idea.

While reading chapter 1 I stumbled upon a few things that I had a hard time of understanding. One particular sentence which I am unable to wrap my head around is at the top of page 15, where it states:
"here it suffices to say that when faced with a choice of different
algorithms you should not trade performance in the case of heavy service use for
achieving lower latency in the case of a lightly used service."

Am I right to presume that the ideas developed in chapter 1 will be backed up by code examples in the following chapters?
roland.kuhn (39) [Avatar] Offline
#5
Re: Kudos and chapter 1 thoughts
Yes, chapters 4–9 will describe all the patterns with code samples etc.

The sentence you quote is indeed a little hard to grasp, I’ll take note to improve it in the next revision, thanks for pointing this out!
Maglic (6) [Avatar] Offline
#6
Re: Kudos and chapter 1 thoughts
I don't know if this has been reported or not, but there is a parameter symbol missing on pages 27 and 28 when discussing Little's Law.

The formula on page 27 is displayed as L = * W

Message was edited by:
Maglic
roland.kuhn (39) [Avatar] Offline
#7
Re: Kudos and chapter 1 thoughts
Yes, someone already noticed that (not sure whether in the forum). But thanks anyway!
Phil Derome (40) [Avatar] Offline
#8
Regarding joostdevries' comments, I sympathize with them, but at the same time I don't see any problem here.

The value of this book is to embrace architecture and programming together and giving enough programming details so that we see well what is being discussed (though I suppose sometimes pseudo-code such Art of Computer Programming has merits). We understand the authors have a relationship with Actors and Akka project and at some point they choose to make things concrete and go with technical solution they believe in, has proven to work in industry, etc. The Design Patterns book was written with C++ and SmallTalk examples and people understand that the patterns exist in part because of the selection of the programming language (Scala supports singletons, making singleton pattern irrelevant to Scala developers).

And yes, it reads in parallel well with The Reactive Manifesto, which is a good thing; it's also normal given that Roland Kuhn is co-author of the Manifesto and so naturally stands by what it states. I actually read the Manifesto with some skepticism (the word itself conjures suspicion to me as it evokes ideology, religion and so on) because I wanted to see some hard evidence that the ideas have merit with more concrete code and real-life examples, and that is what I find in the book so far.

I think it's perfectly fine to read this book, learn the most from it, and be open to other alternatives in a similar space. Similarly, a good developer can read competitive views from .NET and Java communities and grow from ideas in either community and make his own choices as appropriate. I actually find that the ideas presented in the book are highly credible when I reflect on my past experience as developer and solutions for resiliency and scalability of complex problems resonate well, I simply cannot find logic fault in the arguments being made, so I trust them as being an effective way of writing software.

At least the authors don't disrespect other technologies and choices like Java evangelists did in the early years (vis-a-vis C++).