230967 (10) [Avatar] Offline
#1
New guy here, just got the book. I know a bit about Akka from other reading other books for learning Scala, but haven't used it to write any apps yet other than learning stuff. (Lots of Java experience in my background).

Mostly I just wanted to provide feedback that I find the illustration app description thrilling and I think it was a very good choice. I have another book where the app is just a loan processing app and it doesn't capture the broader scope of a full reactive app the same. Plus it is boring. Just thought you guys did a good job on that because I am still engaged and excited for the rest of the book.

So my minor feedback (completely take it or leave it) is on page 8 I think it might take less cognitive load if you inserted the word "do":
At this point the big question is: where [do] these map view front-end nodes get their data from?
230967 (10) [Avatar] Offline
#2
Also 1.3.7 A network link between map tiles fails

We need network monitoring [in] place so that the operations crew is notified
230967 (10) [Avatar] Offline
#3
Secfion 1.4 What have we learnt from this example?

This sentence:

The most important characteristic was that data flow always forward

feels like awkward english to me. Maybe:

data updates always flow forward
230967 (10) [Avatar] Offline
#4
Why Reactive?

Enigma chiffre

did you mean:

Enigma cipher

that word is very foreign and new to me
230967 (10) [Avatar] Offline
#5
Following "In this introduction we started out from" there is an awkward sentence that I wonder might be better as follows:

Adding the fundamental requirement for distribution is what makes us recognize the need for new (or as so often is the case rediscovered) architecture patterns. <new sentence>
In the past we developed band-aid solutions which allowed us to retain the illusion of single-threaded local processing while having it magically executed on multiple cores or network nodes, but the gap between that illusion and reality is becoming prohibitively large. Instead of masking the problem behind frameworks the solution instead is to make the distributed, concurrent nature of our .....

I apologize if this stuff seems nit picky and everything is cheerfully offered as take it or leave it feedback. Enjoying the book and I love these concepts.
roland.kuhn (39) [Avatar] Offline
#6
Thanks a lot for this feedback! I appreciate that you take the time to write up these issues and will incorporate them when revising the chapter. My plan is to first finish the full draft of the book and then come back to address review comments.
230967 (10) [Avatar] Offline
#7
Sure, sounds great. I'll just keep plowing ahead and logging anything I find. I am on section 2.2 and still enjoying the book and its' layout.
230967 (10) [Avatar] Offline
#8
Under The Vending Machine

caffein looked strange to me because I think it has an e on the end.

http://www.merriam-webster.com/dictionary/caffeine
230967 (10) [Avatar] Offline
#9
I am not sure what academically is right to use (persons vs people) in every context.

but on p48 2.5.1 Loose Coupling this reads more the way I would speak.

If you take a step back and think about objects as if they were [people], each with their
right to privacy, then it becomes very obvious how they should interact. [People] talk with
each other, they exchange messages at a very high level.
230967 (10) [Avatar] Offline
#10
2.5.2 Better Resource Utilization

Modern hardware does not advance any more primarily by increasing the computing power of a single sequential execution core, physical limits 17 have started impeding our progress on this front around the year 2006 so our processors host more and more cores instead

instead maybe:

While hardware used to advance primary by increasing the computing power of a single sequential execution core, physical limits [17] began impeding progress on this front around 2006. Modern processors now advance by adding more and more cores instead.
230967 (10) [Avatar] Offline
#11
3.2.1 Immutability

I think the first two sentences here need to be reworked. All of the thoughts are great, but the way they are expressed feels awkward to me. This is my main problem:

In a purely functional program, mutable state is impure and considered dangerous -- the same name for a variable can refer to something different at different points in time. Mutable state is any variable that is not stable or final, and an be changed or updated inside of an application. ...

Maybe:

Any time the same name for a variable can refer to something different at different points in time there is mutable state. In a purely functional program, mutable state is considered impure and dangerous. Mutable state makes concurrent programming more difficult. In contrast, using final, immutable values in an application ...

?
Roland Kuhn (15) [Avatar] Offline
#12
Thanks, I have incorporated your suggestions and they will be part of the next MEAP update!