When trying to build the first docker as described on chapter 1, I get a error from git:

fatal: unable to access 'https://github.com/docker-in-practice/todo.git/': Could not resolve host: github.com

As a complete noob on Docker I was shocked and completely discouraged right from the beginning.

I had to go on google to try to understand the problem (corporate firewall and so on) and maybe find a solution.
I found many resources, none of them understandable for a complete noob!


I would have liked the book to talk about the possibility of this problem occurrence and the corresponding solution.

Closed the book, and pass my way.

In section 2.1.1 Layered Architecture", you end up the discussion about the Business Layer in saying:
<<In some systems, this layer has its own internal representation of the business domain entities. Alternatively, it relies on a Domain Model implementation, shared with the other layers of the application. We'll have much more to say about this aspect later in this chapter. >>

I have read the whole chapter but couldn't find the promised dissertation about sharing Domain Model Object across application layer.

I am inclined to let the Entities objects bubble up the layers up to the Presentation layer. But I have seen many projects where Entities get replicated from layer to layer either by hand or by using Dozer, pretending that it shield the copy in the current layer from implementation changes in the source object pertaining to the below layer.

Entity Replication vs. Bubble-up is a topic that I would very much like see analyzed by you as specialists. Could you include a few sections on this topic, which state precisely what we can do with Entity objects?

Thanks in advance.

This is not really an error, but don't you think that the illustrations are a bit gigantic. We would certainly suffer no loss in comprehension if the illustrations were more modest in size. On the contrary, having more illustrations on the same page would reduce the dispersion and would help comparing them together.
Thank you for pointing that out.
So, only the property: function() {...} form is valid in both situations. Maybe that explain why the book is using that form so much.
That call for an explanation anyway, because the other form is more natural (for people coming from java)

whoa, apparently there is much to discover about javascript function (declaration forms, usage patterns, etc).

I duno if what JohnMick wrote in its previous post is in the book (I've only read 1/4 of the book so far) but sure it could find its place there.

I can't wait for the next MEAP...

Thank you all for sharing your knowledge.

could you add a few sentences clarifying the differences or similarities of defining methods as a) named functions or b) anonymous functions affected to properties.

var myObject = {
function method1() { ... };
method2: function() { ... };

Does it make any differences? What is the arguments for and against each form of method definition?

Same questions when defining inner functions:

function outer() {
function method1() { ... };
method2: function() { ... };

I have noticed that the polices used in the last MEAP have changed to a Sans-Serif police (I think it is Arial). This is realy unfortunate because it render the book really difficult to read.
Please could you switch back to a Serif font, like TimesNewRoman or Garamond ?
I have sent an email to Manning to express my concern about that new font used in the book.

In the meanwhile, can everybody who is unsatisfied with the new font, send a email to maba@manning.com to let them know.

IMHO, by the time your code reach the controller, the persistance session will be closed and it will be too late to load lazy objects in the returned object.