WingDing Fall iteration is Reactive Manifesto and Akka

[Robert Kuhar]

The votes are in and our fall iteration will be The Reactive Manifesto and
Akka.

The Reactive Manifesto itself is short: *http://www.reactivemanifesto.org/*


For the Akka framework we are going to try to see how far we can get using
just the documentation at *http://akka.io/docs/* . The PDF is 11 chapters
and 300 some odd pages. The plan is to explore Akka in both Java and Scala
leaving it up to the individual to select which language they would like to
use. The belief is that the concepts are the same. If this doesn't work
out, we will favor the Java implementation.

The tentative schedule is

Sep 24: The Reactive Manifesto http://www.reactivemanifesto.org/
Sep 24: Chapter 1: Introduction - 9 pages
Oct 08: Chapter 2: General - 55 pages
Oct 22: Chapter 3: Actors - 78 pages
Nov 12: Chapter 4: Futures and Agents - 15 pages
Nov 26: Chapter 5: Networking - 110 pages
Dec 10: Chapter 5: Networking - 110 pages
Jan 14: Chapter 6: Utilities - 25 pages
Jan 14: Chapter 7: HowTo: Common Patterns - 5 pages
Jan 28: Chapter 8: Experimental Modules - 21 pages
Chapter 9: Information for Akka Developers - 12 pages
Chapter 10: Project Information - 10 pages
Chapter 11: Additional Information - 2 pages

This schedule is, of course, subject to change as there are some long
chapters in there. Also, Chapters 9, 10, and 11 seem more informational
than instructional. When we get to them, we'll decide as a group whether
to skip them or cover them.

We are in search of a real-world problem that we could model and solve in
Akka. Something we could record requirements for, write some test cases
up, and check some code in somewhere that meets the requirements and passes
the tests. Any ideas?

We kick off on Tuesday September 24 with The Reactive Manifesto and Chapter
1: Introduction of the Akka docs. Bob will lead the discussion.

Bob

[Dennis Sosnoski]

Hi Bob,

I'm doing some Akka presentations in October/November, so also needed to
come up with a good example. The one I chose is adapting existing linear
Java code to the actor model for concurrency. The basic processing looks
like this:

+-------------+
v |
Web <--> A <--> B ---> C
^
\
-----> D

So a "need document" message comes in to actor A, basically for
processing of an XML document. A sends a "load document" message to B,
which uses the new akka.io (used to be spray.io) API to retrieve the
document and unmarshall the XML. During unmarshalling B may come across
references to other documents, in which case it sends a "need document"
message to A. If A already knows about that document it just tracks the
dependency; otherwise it sends another "load document" message for the
new document to another (or the same) B. When the document has been
fully unmarshalled, B passes the document data on to C with a "check
document" message. C performs initial checking of the document, and when
it's done sends a response back to A with the document data and either
good or bad status, where the latter includes details of the problem(s)
found.

When A finds that a document with no dependencies has been loaded and
checked with good status it passes it on to D in a "validate" message,
and D responds with either good or bad status when done, again with the
latter including details. A holds documents with dependencies until
their dependencies have been validated, and if that's successful they
can also be validated. Once A has completed all possible validations it
returns a result to the original requester.

Akka Actor code is much more concise and readable in Scala than in Java,
so I'm implementing this with Scala at the upper level calling Java to
do the actual work.

My application is actually pretty similar to a web crawler in some ways,
which is one of the standard Akka examples. I like it because it's
actually a useful tool that I'd started writing (single threaded) some
time ago, and with Akka I'm able to easily restructure it to be fully
concurrent. I expect to see some major performance improvements, both
through concurrent processing and through the akka.io usage for
non-blocking reads.

Perhaps something similar would be a good model for the group? So a
specialized variety of web crawler, or comparison shopping engine, or...?

- Dennis

Post by Robert Kuhar
The votes are in and our fall iteration will be The Reactive Manifesto
and Akka.
_http://www.reactivemanifesto.org/_
For the Akka framework we are going to try to see how far we can get
using just the documentation at _http://akka.io/docs/_ . The PDF is
11 chapters and 300 some odd pages. The plan is to explore Akka in
both Java and Scala leaving it up to the individual to select which
language they would like to use. The belief is that the concepts are
the same. If this doesn't work out, we will favor the Java
implementation.
The tentative schedule is
Sep 24: The Reactive Manifesto http://www.reactivemanifesto.org/
Sep 24: Chapter 1: Introduction - 9 pages
Oct 08: Chapter 2: General - 55 pages
Oct 22: Chapter 3: Actors - 78 pages
Nov 12: Chapter 4: Futures and Agents - 15 pages
Nov 26: Chapter 5: Networking - 110 pages
Dec 10: Chapter 5: Networking - 110 pages
Jan 14: Chapter 6: Utilities - 25 pages
Jan 14: Chapter 7: HowTo: Common Patterns - 5 pages
Jan 28: Chapter 8: Experimental Modules - 21 pages
Chapter 9: Information for Akka Developers - 12 pages
Chapter 10: Project Information - 10 pages
Chapter 11: Additional Information - 2 pages
This schedule is, of course, subject to change as there are some long
chapters in there. Also, Chapters 9, 10, and 11 seem more
informational than instructional. When we get to them, we'll decide
as a group whether to skip them or cover them.
We are in search of a real-world problem that we could model and solve
in Akka. Something we could record requirements for, write some test
cases up, and check some code in somewhere that meets the requirements
and passes the tests. Any ideas?
We kick off on Tuesday September 24 with The Reactive Manifesto and
Chapter 1: Introduction of the Akka docs. Bob will lead the discussion.
Bob

[Jason Osgood]

The votes are in and our fall iteration will be The Reactive Manifesto and Akka.

A wise choice. Relevant:

Principles of Reactive Programming
https://www.coursera.org/course/reactive

Enthusiasm for above course
https://news.ycombinator.com/item?id=6285149




------------------------------------

[Robert Kuhar]

Thanks for the idea, Dennis. That'll get us thinking. I'm really looking
forward to this iteration. I hope we can get far with just the Akka
documentation. It looks to be pretty thorough.

Bob

Post by Dennis Sosnoski
Hi Bob,
I'm doing some Akka presentations in October/November, so also needed to
come up with a good example. The one I chose is adapting existing linear
Java code to the actor model for concurrency. The basic processing looks
+-------------+
v |
Web <--> A <--> B ---> C
^
\
-----> D
So a "need document" message comes in to actor A, basically for processing
of an XML document. A sends a "load document" message to B, which uses the
new akka.io (used to be spray.io) API to retrieve the document and
unmarshall the XML. During unmarshalling B may come across references to
other documents, in which case it sends a "need document" message to A. If
A already knows about that document it just tracks the dependency;
otherwise it sends another "load document" message for the new document to
another (or the same) B. When the document has been fully unmarshalled, B
passes the document data on to C with a "check document" message. C
performs initial checking of the document, and when it's done sends a
response back to A with the document data and either good or bad status,
where the latter includes details of the problem(s) found.
When A finds that a document with no dependencies has been loaded and
checked with good status it passes it on to D in a "validate" message, and
D responds with either good or bad status when done, again with the latter
including details. A holds documents with dependencies until their
dependencies have been validated, and if that's successful they can also be
validated. Once A has completed all possible validations it returns a
result to the original requester.
Akka Actor code is much more concise and readable in Scala than in Java,
so I'm implementing this with Scala at the upper level calling Java to do
the actual work.
My application is actually pretty similar to a web crawler in some ways,
which is one of the standard Akka examples. I like it because it's actually
a useful tool that I'd started writing (single threaded) some time ago, and
with Akka I'm able to easily restructure it to be fully concurrent. I
expect to see some major performance improvements, both through concurrent
processing and through the akka.io usage for non-blocking reads.
Perhaps something similar would be a good model for the group? So a
specialized variety of web crawler, or comparison shopping engine, or...?
- Dennis
The votes are in and our fall iteration will be The Reactive Manifesto and
Akka.
The Reactive Manifesto itself is short: *
http://www.reactivemanifesto.org/*
For the Akka framework we are going to try to see how far we can get
using just the documentation at *http://akka.io/docs/* . The PDF is 11
chapters and 300 some odd pages. The plan is to explore Akka in both Java
and Scala leaving it up to the individual to select which language they
would like to use. The belief is that the concepts are the same. If this
doesn't work out, we will favor the Java implementation.
The tentative schedule is
Sep 24: The Reactive Manifesto http://www.reactivemanifesto.org/
Sep 24: Chapter 1: Introduction - 9 pages
Oct 08: Chapter 2: General - 55 pages
Oct 22: Chapter 3: Actors - 78 pages
Nov 12: Chapter 4: Futures and Agents - 15 pages
Nov 26: Chapter 5: Networking - 110 pages
Dec 10: Chapter 5: Networking - 110 pages
Jan 14: Chapter 6: Utilities - 25 pages
Jan 14: Chapter 7: HowTo: Common Patterns - 5 pages
Jan 28: Chapter 8: Experimental Modules - 21 pages
Chapter 9: Information for Akka Developers - 12 pages
Chapter 10: Project Information - 10 pages
Chapter 11: Additional Information - 2 pages
This schedule is, of course, subject to change as there are some long
chapters in there. Also, Chapters 9, 10, and 11 seem more informational
than instructional. When we get to them, we'll decide as a group whether
to skip them or cover them.
We are in search of a real-world problem that we could model and solve
in Akka. Something we could record requirements for, write some test cases
up, and check some code in somewhere that meets the requirements and passes
the tests. Any ideas?
We kick off on Tuesday September 24 with The Reactive Manifesto and
Chapter 1: Introduction of the Akka docs. Bob will lead the discussion.
Bob