The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

In the section describing maps, the 2 sentences dont exactly go together. Are there such things as "key types" when any thing (am I correct here?) can work as a key?
This is what I have for MEAP v7 and it is wrong:
iex(1)> %{:status => 200, "content" => "Hello world!"}
%{"content" => "Hello world!", :status => 200}

iex(3)> Map.fetch(map, [1, "world"])
{:ok, :hello}

If this were to work, it would have to be more like the following:

iex(1)> map = %{:status => 200, [1, "world"] => :hello}
%{[1, "world"] => :hello, :status => 200}

iex(3)> Map.fetch(map, [1, "world"])
{:ok, :hello}
iex(2)> Enum.fetch([1, 2, 3, 4], 1)
{:ok, 2}

iex(3)> Enum.fetch([1, 2, 3, 4], 14)

This pattern will be often-repeated in Elixir.

vs 3 pages after:

As discussed in the section regarding functions, we will see the {:ok, value}/{:error, reason} pattern all over Elixir and Phoenix. Get used to it and learn to love it.
as per subject
answering for myself smilie

answered here ->
Does anybody know when Phoenix 1.4 will be released, and if the book will be updated to cover 1.4 before the final release?

I have to say that the following is strange:
- the book cover (, says "Covers Phoenix 1.3"
- pragprog's book covering Phoenix, however, ( already mentions 1.4
- going over to to verify the latest version, I only see 1.3 though (, which was released July 28 2017, just slightly over a year ago
- "Programming Phoenix"'s page says "The Paper Book will ship on 2018-11-10 (roughly)." If the book is going to cover 1.4, this means that 1.4 should, theoretically, be released before then
I know this doesnt directly address the problem of mobi and kindles... but your best bet through the MEAP would be to stick to the pdf as your main format for reading. I suspect that most (all?) authors will write with the pdf format in mind... and then a separate team will take care of the translation to epub and mobi
The last line of code before "QC 31.3 answer" on page 315 should have the callback function parameters as "(error, comments)", rather than "(error, author)". After all, this is the callback function to loading the comments!
QC 31.2 does not seem right. When comparing the question, vs the answer, either the question is wrong (the line
calculateRoute(destination => {
needs to be removed) or the answer is wrong, and needs to consider the 'calculateRoute' function call.
MickeyP wrote:QC 31.1 In the answer the Promise constructor is given two separate functions of resolve and reject .

new Promise (res, rej) {...}

The Promise constructors needs a single function param which takes the res, rej parameters.

So it needs to be new Promise(function(res, rej){....})

good catch! I think what was meant was
new Promise((res, rej) => {

(continuing with the convention of using arrow functions)
On page 150:

The <fixed-width>double</fixed-width> function we just saw is such an example. It’s functionally equivalent to the function expression defined just before it.

I'm looking and searching, but I dont see any "double" function that's just been mentioned. Where is it?
There is TypeScript support in Electron (since June 1 2017): see
1.5.2 "Exploring the console" says

After you’ve signed up, you’ll be automatically taken to the Cloud Console, and a new project will be automatically created for you. You can think of a project like a container for your work, where the resources in a single project are isolated from the rest of the world. In other words, you should think of each project much like you would if you were a freelance developer working on a contract. Each contract would get it’s own project, so that when you’re done, you could hand the project over to your client.

This is all there is in the book to what a project means. The analogy isn't very helpful (freelance dev working on a contract), and we're lacking real practical details. I would have questions like how much isolation does a project provide? is each project isolated from each other? does that mean a different vlan for the instances in each project?
According to listing 1.4, I'm expecting to see "Saved Application Default Credentials" after logging in in the browser, but now I see the following instead:

WARNING: `gcloud auth login` no longer writes application default credentials.
If you need to use ADC, see:
  gcloud auth application-default --help
If I may add one other point: in section 1.4.5 the example of "file formats" is used as an example of systems programming. I'm not entirely convinced. You could talk about interpreters of, or programs that use, those file formats... but file formats by themselves? Not an example of systems programming imo.
TS McNamara wrote:
267849 wrote:"Rust is likely to have helped" - shouldn't there be a "would" somewhere in there?

Perhaps this is a New Zealand-ism? It sounds natural to my ears, but perhaps a more conventional sentence structure would be more appropriate.

267849: I believe the point is to make the point that it is *likely* that using Rust would have helped; rather than to say emphatically that it definitely "would" have helped.

EDIT: ok, perhaps you were thinking of something along the lines of "Using Rust would likely have helped ..."?

Not a NZer here (nor an Australian), btw. I see no real problem with the sentence, although I would agree that "Using Rust would likely have helped ..." to be a much better rewrite.
TS McNamara wrote:
I certainly want to improve chapter 1. Its a bit of a Frankenstein at the moment. Quite a lot has been pulled together from other writing. Will work hard to smooth things out.

Indeed pls do. Going through it, I see a lot of technical (these matter, obviously) and non-technical typos; incomplete sentences; sentences that are just awkward and place the burden on the reader to try to make sense of; ....
as per subject, what is the dependency of Java for?
265494 wrote:Maybe trivial, but please write "Voilà". Literacy goes further then technology. Or do I miss some understated humor? (I am an ESL)

I don't understand "Wallah" either, seriously. But now I get it. So it's "Voilà"!
re-posting a question from earlier: wrote:
So here's a follow-up question for Roy: which chapters in the list at will be new, and which are effectively the same from "Notes"?
p.4 1st paragraph (underlining for emphasis):

If there is no data architecture but there is an API that needs to be interacted with, a request is made, and when the response comes back it will be manipulated in the data architecture layer and then passed on to the main state of the app.

It looks like this should be for the case of data architecture layer + API ?

And the next paragraph seems wrong too:

If there is no data architecture layer and no API, then the data will be either passed on to the main state of the app.

"Either"? It looks like this entire description of the application flow needs to be rewritten.
I did a search of my manuscript for the incorrect spelling of Experiment and didn't find it, so perhaps I caught it too at some point. The next update to Learn Go should be out tomorrow or later this week.

Thank you, Nathan. I've been looking at the downloadable chapters, and the most recent version (v7) still has this (see, for example, on the last page ('Experiement: playground.go'))

This step is really just preparation for the next task to "Decipher the quote from Julius Caesar". I made a note that I should try to clarify the wording before the September update of Learn Go.

I see. Thanks for clarifying!
It seems that, just going through chapter 1 and 6 so far (but given that it appears in 2 chapters, I'd be sure to make sure it doesn't repeat in other chapters as well) "Experiment" is misspelt as "Experiement". It's a minor thing, but... thought to point it out.

About the logical error: "Experiment: caesar.go" in chapter 6 says
Handle negative shifts when c < 'a' by adding 26. Do the same for upper case characters.

That was a bit of a surprise to me, given that we've been talking about adding 13 so far. So why should we be expecting a negative shift? If your point is to "try using -13 instead of +13", then you should make that point clear. Otherwise, this is an error and you should ask the reader to handle overflows (should you call it that or use that term though? hm... Admittedly, "positive shift" doesn't cut it).
Listing 2.3 needs to be updated to show the current format of the output. Under 'ACTIVE', and 'SUB', it should say 'inactive' under 'ACTIVE', and 'dead' under 'SUB'.
Is there a better way to say this or word this? I mean when I read this, I think of Mesos, where (correct me if I'm wrong) the aim is to abstract away individual machines into one single, big machine or pool. But I don't see this as true of a CoreOS cluster, where we do see and are aware of individual machines? wrote:so as per subject. I think it should be v7 by now? I already downloaded v6 in April...

ok, guess I might have read through that update email a bit too fast. The update was simply that "Kim's working on making it easier to set up Django", not that that update is out already!
so as per subject. I think it should be v7 by now? I already downloaded v6 in April...
I'd like to check with other possibly more informed readers than myself about this. It seems from my brief research is that it is only possible to use C for Android if you use the NDK ( Is that correct, and if so, could you really write an entire app in C? wrote:
rcoe67 wrote:I'm curious what the overlap is between the capabilities of ULP using Kafka and the ELK stack (Elasticsearch, Logstash, Kibana)? Considering that Nagios Log Server is built on the ELK stack, I'm not sure of the value-add in choosing ULP, especially considering that the book mentions how difficult it is to manage Zookeeper in a multi-node production environment (p. 37).

Not sure this is the right question for this forum but perhaps the book should cover the disparities, if any exist, that would help in the decision making process. In fact, I am in that situation right now, so would love some insight.


I would be curious as well, and would like to see a comparison. I see the ELK stack as pretty much tackling the same issue here. Reading the description of the book (, it seems like it means to help you (?) build your own equivalent ELK stack? Is that true? (And even if were so, it would be good to talk about ELK, and why or why not; ie. the pros and cons....)

Coming back to this now after some time and correcting myself after discovering Kafka serendipitously, and then also after having read the book: ELK is but a specific stack (and not a ULP setup at that!), and is not a processing methodology or architecture; and it only serves a very narrow and specific purpose. ElasticSearch (loosely calling it the "log" of the stack) is also not a unified log and for these reasons, it would not fit to discuss ELK in the book.
Just to reproduce things here for quicker reference (but always verify with the source! smilie):

I'm happy to announce that I am re-publishing the "Notes to a Software Team Leader" as a new book under Manning publishing, re-titled "Elastic Leadership".

The new book will contain a couple of new chapters, regrouping the "notes" chapters under common themes, and extra annotations from me on the external notes, to add where I think they fit into the elastic leadership framework.

The new chapters I will be adding:

  • Line Manager's leadership manifesto

  • Bus Factors

  • So here's a follow-up question for Roy: which chapters in the list at will be new, and which are effectively the same from "Notes"?
    (FYI this won't be an exhaustive list. I just happened to read through a couple of pages and found these problems)

    pdf p.121, 2nd last paragraph: should that be "added *flexibility*", instead of "stability"?

    pdf p.122: is it really necessary to have the "index" key? Just seems like more typing when I've been able to simply put the analysis map directly under "settings".

    pdf p.123: "You can specify multiple analyzers with different names and combine them into custom analyzers to give you flexible analysis options ...": my first reading of this sentence didn't seem right. Now I get that you're probably talking about combining different "analysis parts" (instead of "multiple analyzers") "into custom analyzers". How about calling these "analysis parts" (sounds funny) "analyzer components" instead? And then the sentence could be rewritten as such:
    You can specify multiple analyzers with different names and combine these analyzer components into different custom analyzers to give you flexible analysis options …

    pdf p.130: "Tokenizer" is spelt wrongly in Figure 5.2.

    pdf p.133: error in text. Explanation says "if you wanted to split text on any two-digit number", but the pattern is for something else.
    it's not very clear to me, but as per the subject, reading the description of this book, I am reminded of Software Development Metrics ( How is this book positioned vs Software Development Metrics, and what would make me get this book over SDM, or vice versa?
    Dunno how active this post will be, but... thought I'd start a thread on this (I usually catch quite a bit of stuff). I will only (I hope!) attempt to point out more serious errors. Spelling and minor grammatical errors I'll leave alone.

    on pdf page 104: "Until you don't hit the enter key your servers runs." should be "Until you hit the enter key ..."
    Thanks, Andreas! That makes sense.

    Could a different type of arrow (and one-way too, which I imagine would be better than the 2-way one used right now) be used? This would apply for both arrows from the DNS (going to the LB, and to the CDN). I imagine just this change would help, even if the arrows are not labelled. (So the idea is that the one-way would indicate "points to", or "resolves to", and would definitely avoid giving the impression of traffic going back and forth)
    Thanks, Andrea. I really really appreciate your prompt reply as well as the thought you've put into explaining things; I can't ever remember a time an author has gotten back to me so fast...

    On 1 and 3: thanks for the clarification.

    On 2: I dont know if i'm reading too much into the point of the diagram (let me know if so. This is from a detail-oriented system administrator's point of view), but:
    1. the LB could also be created in parallel. It's only the config of the LB that needs to happen after the web + db servers.
    2. the operation of the web servers depend on the db servers, but we've parallelized them and yet still enforced this "sequence" by making all 3 dependencies of the LB. That's most interesting. I was almost tempted to say that this parallelization could be pushed further up the chain... until I realized that you DO most certainly need to have info about the web servers in order to configure the LB! But then what about the web servers (more accurately the config of the web app) needing to know info about the DB?
    1. The explanation for the diagram contains the following sentence: "Finally the DNS (6) node depends on the LB node.". Is this a typo? The DNS node depending on the LB node is only indirect, and through the CDN according to the diagram.

    2. How does the LB "wait for" the DB exactly? Why would access to a DB have to go through a load-balancer?

    3. How does the CDN reference the LB exactly?
    In a few diagrams (eg. 1.3, 4.1), there are arrows (presumably traffic) between the load balancer, and the DNS. Is that really the case? Are the DNSs load-balanced? And even if so, shouldn't there be multiple icons for the DNS (reference the "web servers" in each diagram), as opposed to just one?
    david.nicolette wrote:I see what you mean. Yes, that does sound inconsistent. The book has gone to press now so I guess we'll have to live with it. For what it's worth, WIP is a buzz-term and "steering work in progress" is just an English phrase. I'm not trying to dodge the inconsistency, just clarifying. Sorry about the confusion! I hope you'll be able to read past that sort of thing and get to the substance.

    smilie I'm trying to, and I appreciate your continued participation and help even after the book has gone to press.
    david.nicolette wrote:Your reading of the process models is correct. I wonder if the confusion is this: The models are descriptions of how things are meant to be, and what I would like people to do is assess how things actually happen against those models. The problem I observe in the field is that people assume that just because they are using (or believe they are using) a given model, that things are actually happening according to that model. That's where they go astray in choosing metrics appropriate to their situation. Not sure if that's clear.

    It's very common that people use a time-boxed or iterative process in conjunction with a traditional approach to budget, scope, and timeline. They use metrics that are recommended by the process they're using - say, Scrum, XP, or Kanban - but in fact they are just driving out a set of predefined requirements. IMO they ought to measure what they're really doing and not necessarily what they think they're doing.

    I see. Well that definitely clears things up big time for me! That was precisely why I was confused. Your explanation is beautiful, but also highlights yet another layer of subtlety that may be hard to get in the subject matter. I needed that. Thanks! I've been approaching and reading this material like a geek; it's becoming clear that I will have to take another approach....

    Re "project" vs. "ongoing work", consider these two ways of building and supporting a software product:

    (a) The company defines a project to develop a new software product (could be for internal use or for sale, doesn't matter). They may form a new team to carry out the project, or they may assign the work to a longstanding team. The work is capitalized so the company can amortize the initial development cost over the planned lifetime of the product. When the initial version of the product is complete, the project is formally ended. For the remainder of the production lifetime of the product, any support issues and enhancements are handled by a different team - a support team that is funded on an expense basis. There is no "project" for the support work.

    (b) The company decides they need a new product. They may form a new team to support the product, or they may assign the work to a longstanding team. There is no separation between the initial development work and ongoing support and enhancement. Initially the team spends proportionally more time doing "pure" development than support simply because there isn't any code yet. As time goes on, they spend proportionally more time on enhancements and support issues, because the product is in use. There may be numerous or frequent or continuous delivery of changes. Usually, all the work is expensed.

    I'm not sure I'm getting this yet. Could it be that the major distinction between "ongoing" and "project" could be in terms of how the capital put into it is viewed, whether as a fixed capital expenditure/investment, or possibly (but not necessary!) unbound operating expense? Is that it? Would that be a better way to see the 2 different modes? I'm seeing that "ongoing" does not necessarily have to mean that there is no end date, so it's not possible to distinguish the 2 in terms of that. Thanks for your patience!
    david.nicolette wrote:Process improvement - any change to the way in which the work is carried out that results in better outcomes. The definition of "better outcomes" depends on what problems the team or organization is facing and what goals they may have for delivery performance or software quality. You are right to think that it may involve changes in any of the three key factors mentioned in the chapter. It may also involve changes in technical practices, reduction of process waste, and anything else that results in an improvement.


    I think approach and process model are distinct considerations. It's possible to apply any process model with the traditional approach. People won't achieve the same benefits from moving to an iterative or time-boxed process model if they retain traditional assumptions about fixed budget, up-front design, and big-bang delivery, but they may realize some benefit just from chunking up the work and keeping closer track of progress so they can identify delivery risks earlier.

    That's fine. My problem is my reading of the various different process models. Does it not read like the requirements, and definitely the scope / solution, are not fixed and might change in the iterative and time-boxed process models?

    Iterative — Based on the assumption that a single pass through the requirements is unlikely to result in a good solution. With an iterative process, the requirements are revisited time and again, and the solution is built up through a series of iterations. This may involve progressive refinement of the solution, gradual addition of specific features, or a combination.
    Time-boxed — The same as the iterative model, with the addition of two defining characteristics: (1) each iteration is the same length, and (2) a potentially shippable increment (or vertical slice) of the solution is delivered by the end of each time-boxed iteration.

    Maybe it is my bias; but it's hard to read it otherwise given the language (especially the phrase "progressive refinement of the solution"). I think you have some nailing down / clarification (the very point of this thread) of some terms to do if you want to have the book to have real practical value. I assure you, I wont be the only one coming to the book with questions like these.

    And note the traditional approach is defined/described thus:

    The traditional approach involves a thorough analysis of stakeholder needs, a comprehensive solution design, a careful assessment of risks, and a fixed budget allocation in advance.


    With the traditional approach, the scope, schedule, and budget are all fully defined in advance.

    A discrete project is not (only) "bound by specific time." Projects are usually capitalized and have a fixed budget allocation. They have a distinct starting and ending date. Often, teams are formed to carry out a project and then disbanded when the project is finished. It's certainly possible to use a continuous development approach when there is a firm target date for delivery, but that single factor doesn't necessarily make it a "project."

    This seems to be a tangential question that you're answering, and not my actual question. Perhaps one question will help to clarify things. How would you define "ongoing"? Is it possible for an ongoing delivery mode to have a planned ending date, and if so, how is that different from a "project"?
    david.nicolette wrote:I've seen WIP defined in both ways, as "work in process" and as "work in progress" in different sources. I've seen "work in process" far more often and I think it's the more generally-accepted term. But there's really no difference. For the book I picked the one that seemed to be more commonly used, for consistency.

    I see. I guess it wasn't clear from my post, but if consistency's what you're striving for, you'll need to fix the text. I keep seeing "steer(ing) work in progress" throughout the chapter.... And "work in process" is really the only one time when I've seen "work in process" used instead!
    Just a few minor points after reading the chapter. Overall, I feel like this chapter really needs some love, but here are some specifics:

    1.1 "Who Should Read this Book" seems a bit too long for my liking. One sentence really stood out for me, and really irritated me, because it just stinks (sorry) of filler: "I think your parents would enjoy reading this text, probably after you give it to them as a gift.". Pls kill that sentence. It's frustrating to read a sentence that really smells of filler.

    1.5 "Principles in this book" says that you've broken up the theories "into two sections", but then goes on to list down 9 points?
    Please note: this is from the perspective of somebody who only has access to chapter 1 (not a buyer yet! still deciding).

    I'm having a bit of a hard time trying to come to terms with some of the vagueness that I'm getting from what I've read. While I understand that some of this might be cleared up as I work through the later chapters, I'd rather have this all be cleared up front, especially in a book that aims to be practical, and in the introductory chapter of just such a book.

    So here are a few clarifying questions.

    1. How exactly would you define "process improvement"? Could you define it as, say, a change in one or more of the 3 factors (approach, process model, delivery mode) aimed at making improvements to software development? I understand that when any or all of these 3 factors change that all 3 will probably be affected; but given how the word "process" features prominently in one of the factors ("process model"), it might be good to define "process improvement" clearly. What "process" are you talking about?

    2. "Approach" vs "process model": it seems to me like these 2 factors are so closely linked they could be collapsed together into one. If you're using the traditional approach, your process model would necessarily be the linear process model, right? Is there any reason then why "approach" has to be kept separate from "process model" as a separate factor?

    3. When you talk about "delivery mode", you talk about software being built in only one of two ways: either bound by specific time, or else ongoing and continuous. But is it really only one of two? What about when something is simply defined as when the owner says it is "done"? or when you're using the adaptive approach, and the schedule is flexible (but maybe not the other parts of the iron triangle)? So a software development effort could possibly not have a specific end date/time... and yet be designed to eventually terminate?
    is the "work in process (WIP)" in section 1.2.1 ("Process model") actually "work in progress (WIP)"?
    Rows and statements (and dbs!) should indeed be closed, although the Close() should only happen after you check that there has been no error (so doing "defer rows.Close()" on line 2 before you check for the error on line 3 is incorrect).

    Btw, there are a couple of other things/subtleties with database/sql that need to be taken into consideration. As an example, db.Close() really shouldnt be called where it is right now in the code. It should be deferred until the end of the program ( explains it very nicely). Check you that video for great good....
    52599 wrote:
    // the latter fails to connect, from I understanding, but I don't see where authentication is configured?
    And it seems to use the OS user running ./chitchat process!

    yup, same thing here as well. Never really thought about it... but I guess that's a sane default if the user isn't provided in the setup?

    To configure authentication, simply provide "user=", and "password=" to the setup string. So eg.
    database, err := sql.Open("postgres", "dbname=chitchat sslmode=disable user=pgsql password=YOUR_PASS") 

    Great work on the chapter, btw!
    rcoe67 wrote:I'm curious what the overlap is between the capabilities of ULP using Kafka and the ELK stack (Elasticsearch, Logstash, Kibana)? Considering that Nagios Log Server is built on the ELK stack, I'm not sure of the value-add in choosing ULP, especially considering that the book mentions how difficult it is to manage Zookeeper in a multi-node production environment (p. 37).

    Not sure this is the right question for this forum but perhaps the book should cover the disparities, if any exist, that would help in the decision making process. In fact, I am in that situation right now, so would love some insight.


    I would be curious as well, and would like to see a comparison. I see the ELK stack as pretty much tackling the same issue here. Reading the description of the book (, it seems like it means to help you (?) build your own equivalent ELK stack? Is that true? (And even if were so, it would be good to talk about ELK, and why or why not; ie. the pros and cons....)
    EDIT: sorry, meant to edit this, but in my haste created a new message instead when I clicked on the quote button. There isn't any way for me to delete my own post (duh), so... am leaving this note here.
    353525 wrote:This is my 2nd book on Elixir, btw. Really learning a lot more from this one, thank you.

    Just out of curiosity (because I am looking at possibly getting this book), what was your first one, and how is this different or better?
    Just to give an update here: support has resolved the matter to my satisfaction, so I'm happy now. I'm also glad that (as per Rebecca's post) from now on, Manning will do better about letting their customers know when major changes happen to the TOC for their books; so everybody's a winner here. Thanks, all.
    reri wrote:Dear jfs. works,

    Rebecca, I don't really care so much about identifying with this nick, but... for the sake of accuracy, you should get it right. I'll be more inclined to believe you're really putting in effort here.

    We apologize for how this was handled. We contacted support and you will be contacted soon to get this matter resolved to your satisfaction.

    Really? I'm going to remain skeptical about how genuinely apologetic you guys really are. I know how hard it is to say sorry.

    And fyi, please continue all correspondence regarding questions specific to me privately, so we don't end up taking over this thread, relevant as our discussion may be. Except my question below. That, you should reply publicly to.

    It is our policy to honor exchange or refund requests on MEAPs any time up until the last chapter is released.

    Perhaps you could clear this up for all of us while we're on this topic. What do you mean when you say "until the last chapter is released"? Would that include the first draft of this last chapter? So as long as it is out, all bets are off, even if the chapter is not finalized? We're just coming to the last chapter now, so I'm sure a lot of folks will probably want to know.

    Also, moving forward, we will do a better job letting customers know when major revisions have been made to the Table of Contents of our books.

    Thank you and please do. It is your business, to do so.

    Thank you for bringing these issues to our attention.

    Again, our apologies

    Rebecca Rinehart
    Manning Publications
    This is how dealt with me when I raised this issue, fyi.

    First I get what seems to be a reply that shrugs off the issue:

    I am sorry that you are not pleased by this decision. I will pass this along to management.

    hmmm... You know, I actually did ask you what I should do? now that the very content for which I wanted the book is now gone, and you're saying what, you will "pass this along to management"? What does that even mean? Ok. Maaybe that means I'll see some sort of action and get some sort of reply? I hope?

    I wait two days (more than 48 hours) with no further replies before clarifying what support means by "pass this along to management". Support then comes back with the following reply:

    I passed your feedback along. If you are not happy with the state of this amended meap I can exchange this out for an alternate title if you like.

    Wait. So you're only now just offering any sort of redress? Not during your initial reply? Gee thanks!

    Oh and of course, I'll accept a swop-no-refund! (even though "You can cancel a MEAP subscription for a refund or a one-time exchange anytime before the final chapter has been released."). But that option of a refund has not been allowed for me! Oh dear, I'll have to go hunt for a title that I can accept now in exchange for this. But I already know (I've seen the other books) that the content I really want is missing from Manning. I really don't know what to do.

    I wait a few days, peck around a bit on Manning, see what titles they have, investigate some books... go hunt for and see what reviews are out there.... Do I really have to do this? I feel like I'm doing Manning a favour here, taking time out from my life to do this for them (time that I'm very, very aware I can never get back; there are so many other things I'd rather be doing).

    So I finally settle on a book which, while on a totally, totally different topic (and which I wouldn't have otherwise bought, btw) I can accept. And I reply to support to let them know of my choice.

    This was 7 days ago. I have neither heard since from support.... nor seen any action (I know; I've checked my account!) taken on account of my reply. I must assure you, on top of what's happened with this book, it feels good how I've been treated.
    Bill Kennedy wrote:Please understand this was not Manning's decision or fault. This was a decision made by the authors. If you want to be upset with anyone, you can be upset with me. Manning has been incredible to work with. If anyone is interested in writing a book, Manning is a great choice.

    I know I appreciate your work and effort on the book, Bill, so no worries there. I think we all just wished that this change could have been better communicated to us; and Manning come clean with alternatives if we so decide because of the change that the book is not for us. I'm in the same camp as 342405; I'm looking for the more advanced stuff.
    342405 wrote:I'm suprised by this decision as well since I was especially interested in some of the more in-depth themes like Reflection, Performance and the Devops stuff. It feels like Manning wanted to sweep the cut of the more in-depth / advanced topics under the rug which makes the book way less appealing for more seasoned devs.

    indeed. Ditto...
    Ok, Bill. I will email you from another email (this is the one I use to talk to Manning).
    Btw, is this a decision that has been made already and wont be gone back on? Is the reason the time... the other book... or both?
    Point of feedback (more so for Manning than for the authors): any time anything like this ever happens, the readers should be properly informed*. I certainly didnt catch this. Thanks to the OP for pointing this out!

    *The latest MEAP update email only said:

    What's new?
    Chapters 1-8 have been revised.

    The authors have made extensive changes to chapters 1-8, in particular to chapter 5, which is now called "Go's Type System." Please be sure to stop by the Author Online forum to let us know if you like the changes that have been made to the manuscript. As always, we appreciate your feedback!

    What's next?
    Chapter 9, "Writing Network Applications in Go"
    Right. My point is that I "copy to current dir, and then edit and run", but if everybody else cds into the directory (which will still involve that extra typing, btw) before editing, or simply just runs from that directory ('go build'? 'go build path/to/file.go'? 'go run path/to/file.go'?) without an edit, that's fine. Just wanted to know what everybody else was doing.

    I think the only case where the extra separation is necessary is when folks do a pure 'go build' (ie. just type 'go build' at the command line; not 'go build path/to/file.go'). If they do a 'go run', you can have several files declaring 'package main' without a problem.
    I'm currently using the source code over at github how I would your standard source code download. So ie. download, copy the relevant source files somewhere (say the current directory), and then experiment/learn by doing a view/'go run'/modify loop. This causes me to not like the unnecessary nesting (translates into extra typing that I have to do when copying) that I see.

    Is it possible to flatten the structure where possible?

    Case in point: chapter6.

    $ find chapter6 -type f

    All of these files could be flattened into the main 'chapter6' directory. If each subdirectory only has 1 file, I'd rather have them under the main `chapter6` directory for easier access. Where each listing necessarily has more than 1 file, then it makes sense to create an actual directory for the listing (eg. chapter5/listing72).

    Having said that, I recognize that it could also be that somehow others are not using the source code that way (although I have my doubts). So I'm here to ask: would flattening the source code like I suggest be better for you?
    Also p.137: "In listing 1.6, we are using two runtime functions to ...". It should be listing *6*.6 instead.

    And p.150: "In Figure 6.5" should be "In Figure 6.6"
    Right now it does. 'outer' should start with 2 instead to fix the problem.
    Bill Kennedy wrote:That assignment is not a copy operation. I do a much better job describing this in chapter 5 (coming soon). The value of the concrete type is "embedded" in the interface value. If there is a pointer receiver, the value will be shared.

    thanks, Bill. Do you mean a new version of chapter 5?

    About the copy operation, that's how I think of it, coming from a C background. That's how I see

    var matcher Matcher = dm

    as being different from

    var matcher Matcher = &dm

    and why the latter works but not the former, because in the latter, the address is copied to 'matcher' (and 'matcher' thus becomes a pointer). If the first assignment is not a copy ("copy by value" to be more exact), I don't see why you shouldn't be able to get access to the original 'dm' struct through 'matcher'. Or are we maybe talking about the same thing, but using different terminology?

    Short demo program to illustrate how the first assignment only produces a copy that's different from the original struct:
    2.37: s/defaultMatch/defaultMatcher

    2.38: it's not so much the listing that's a problem, but the explanation that's the problem. It's not because you're calling the method via an interface type that's the problem, it's because of the assignment, because the assignment ("var matcher Matcher = something") is a copy operation, and if you have a pointer-receiver method, there's no way to modify the original "dm" if "var matcher Matcher = dm"....
    Overriding 'toString' does make for friendlier output from the REPL. If you want to see what the standard (I think the better way to think of it would be as a "provided skeleton function", instead of a "standard function" in this case) toString does, you can define another similar class, but without the overridden 'toString', and then compare the two outputs:

    class PlainBook(t:String, p:Price) {
        val title = t
        val price = p
    val book2 = new PlainBook("Some book", 10)
    book2: StrBook = StrBook@9556cd94

    I dont think toString is that crucial a method that overriding it will cause any issues. Scala certainly doesnt rely on it to do its own memory tracking! It has its own internal mechanisms which I doubt you'll be able to override by merely redefining a function....
    Hang on. I'm a bit confused. Are you agreeing? or disagreeing?

    In chapter 2, "PAUSE: Where are we?", I see
    3 A function is referentially transparent
    A function outputs the same value for the same inputs
    Thanks, Cody!

    About the unzipping, yes, there is an error, but insidiously, only if you 'unzip' from the command line?!! My bad; but I never expected for there to be this sort of discrepancy... If you open the zip file using Finder, it'll be fine. But I'm a command line sorta guy. If you attempt to run 'unzip' on it from the command line, that's where the problem happens. Bah!
    about the unzip problem: thanks, but I think i'll just put this down to Apple's fault (which it should be). I've run and lived on Linux for pretty much the longest time ever; and this sort of ridiculousness would be unforgivable. But oh well, that's Apple for you....
    One question about "" with this VM: should the tests be passing?
    Indeed, I would echo a request to put the bare minimum somewhere (so ie. "not an entire image").

    On a separate note, did anybody happen to have a problem with the login? I solved it myself by eventually going to root (cos the VM wouldnt accept the password despite several tries and re-verifying) and changing 'sysop's password myself - not getting through with "sysop", and password "u$osuser".

    Another point to note: if you're having problems unzipping on a mac, try using a linux machine (doh!) instead.
    re restarting services: I would agree with just using the 'service' command. It's more "portable".

    'service' has actually been around long before upstart, btw; it's just a convenience command that apparently the folks decided to stick to when moving to upstart, so if you're not being so hardcore (ie. running scripts directly yourself by typing the path directly a la "/etc/init.d/..."), what you've learnt will still work...
    I'm just going through chapter 1 now, and found some typos. (Note that the pages that I will be referring to are not the page numbers as labelled on the pdf, but the "pdf page").

    Here's a list (non-comprehensive):

    p.7 last paragraph - 'other wise' should be 'otherwise'
    p.8 2nd paragraph last sentence - 'on you newly constructed private cloud' should be 'on *your* newly ...'
    p.8 last line - 'virtualization' is spelt wrongly ('virtualziation')
    p.11 last sentence of 2nd last paragraph - 'visualization' should be 'virtualization'

    p.20 last line - 'launch' should be in the past tense
    ok, you know after observing the pattern of the replies here, I do have to ask: am I being ignored here? should I carry on contributing / participating here or?
    First up, I know the note about the comments at the bottom of each page. If any of these cross into that territory, do let me know. I'm just a finicky reader, both out of obsession, and partially out of occupation...

    In a perfect world, all the books I read would be perfect. But of course, that's not always the case, is it? But at least the books that I care about should be as near perfect as they can be if I can help it.

    I havent looked at the rest of the chapters yet, but if chapter 1 is anything to go by, I am looking at a potentially really great book! And I'd like for it to be as free of errors as possible before it gets into my hands... smilie

    So here goes the list:

    1. I dont know why nobody's noticed this (maybe they dont really bother to read this bit?), but I found the "Welcome" section a bit disorienting.

    Here's the section in question:

    Chapter 2 is about getting your hands dirty with Elasticsearch's functionality. You will understand how data is organized, both logically and physically. By the end, you'll know how to index and search for documents, as well as how to configure Elasticsearch.
    Chapter 3 talks about scaling horizontally. Elasticsearch is, as the name suggests, elastic, so spreading to more machines or shrinking to less is what it does best. This is where you'll learn about this fundamental feature.
    Looking ahead, in part 2, we'll cover Elasticsearch's core functionality when it comes to dealing with data: indexing, searching, analysis, and faceting. In part 3, we'll cover the advanced functionality that will let you take your search application to the next level, such as geo-spatial searches and relationships between documents.
    Finally, part 4 is all about making Elasticsearch perform to your production standards. We'll talk about tuning indexing and search performance, as well as administering your cluster .

    I can see how the description of chp 2 might be correct, but surely chapter 3 is not about scaling? And then that bit that talks about part 2 also seems off... Seems to apply more to chapters 3-5 (3 Indexing, updating and deleting data; 4 Searching your data; 5 Analyzing your data )?

    So anyway, a rework of this section would be great.

    2. I'd suggest changing the font for the chapters in the TOC on page 4. Serif + italic... it's making the chapter headings slower to read / make sense of!

    3. page 6, last sentence (crossing over into page 7): I'd suggest a rewrite. Got 3 alternatives for you:

    - "... it's worth checking out if it's worth including another data store in your design *for search*."

    - "... it's worth checking out if it's worth the added complexity of including another data store in your design for search."

    - "... it's worth checking out if your search needs are worth the added complexity of including another data store in your design."

    My contention is that the *3rd* "it", without qualification or more context, can be a bit confusing, and can really slow u down a bit in your thinking (the first two "it"s get you accustomed to linking "it" to "Elasticsearch" in your mind... and then if you keep thinking like that into the third "if", the bit following that will throw you off).

    As a reader new to the text, I'm not anticipating what the next bit will be, so I will be confused after reading to see that the 3rd "it" has changed (if u get what i mean).

    4. First sentence of section 1.2.3 ("Use it with existing tools"):

    I suggest adding an 'already' to break up the possible reading of "built to work with ... what?": maybe something like "... you dont have to write a single line of code to get the job done with Elasticsearch, because there are lots of tools *already* built to work with; ..."

    5. (minor; feel free to say "no, thanks!") Suggested revision of last sentence of the intro of section 1.3 (sentence before 1.3.1): "We'll talk more about plugins in chapter 10; for now, we'll just look at the core functionality."

    6. 1.3.2: technical error. 4th paragraph: shouldnt it be "query time *increases* dramatically" "when data starts going back and forth between many nodes"?
    Thanks, Radu, for answering this - and for being an active and intelligent participant here! (and that's a rarity!) Based on this, I will be leaning towards getting this book.... smilie
    what is 'sloppy'? Some software u plan *to* introduce?

    I can understand that English may not be ur first language - but pls edit ur subject so that ur post/s can get more attention...

    It's not "Introduction *to* sloppy". But "Introduction *too* sloppy"?

    NOTE for the authors/editors: I will be *occasionally* editting my posts in place, so... do check back occasionally! It does not mean that i havent added anything new to this list of errors and corrections, just because i havent added any new posts to this thread....
    I wont detail all of the errors. Some of them should be obvious; but where not, I have elaborated:

    Chapter 1:

    1.4.2 - "... when programmers at MIT implemented the these functions ..."


    - "As a functional programming, language, XQuery ..."

    - "We will review more about the relationship between NoSQL and functional programming in Chapter 12. ."

    Double period (with space in between?).

    Can be better written as "We will review in more detail the relationship between NoSQL and functional programming in Chapter 12." OR "We will review the relationship between NoSQL and functional programming in more detail in Chapter 12."

    1.4.5 - "Amazon found however, that because key-value stores had a simple interface it was easier to replicate the data and more reliable."

    A few well-placed commas would definitely make this flow much more easily: "Amazon found however, that because key-value stores had a simple interface, it was easier to replicate the data, and more reliable.

    1.4.6 - "Although there we many different databases being used ..."

    1.4.7 - "Not only did we sense a feeling of liberation from RDBMS systems, and excitement around new technologies and methods but shock in the difficulties they faced in explaining the business benefits of NoSQL to their own colleagues."

    Please rewrite to flow better. Maybe something like

    "Not only did we sense a feeling of liberation from RDBMS systems, and excitement around new technologies and methods, we also experienced shock over the difficulties we faced in explaining the business benefits of NoSQL to our own colleagues."


    - "We now know that once tried and true, traditional systems using SQL databases that require shreding and joins to manipulate the data may no longer meet the business needs of todays market."

    "tried and true" should be hyphenized (see Without grammatical errors:

    "We now know that once tried-and-true, traditional systems using SQL databases that require shredding and joins to manipulate the data may no longer meet the business needs of today's market."

    - "As we've seen these changes impacted more than early technology adopters, engineers around the world realize there are options to the RDBMS-as-our-only-option mantra." Needs a rewrite.

    - "As organizations continue emerge and move into global economies this trend will continue to expand." Needs a rewrite.

    Message was edited by:
    joshblair has done his part to highlight several - and there are several more that u can see, even in just the free chapter ("What is NoSQL?"). I wont point all of them out - but I wish to highlight that despite this being a MEAP, and a "work-in-progress", it would really be nice to get some editors onto the MEAPs... and weed out some of these errors.

    Or is Manning actually ok with foisting these errors onto your early supporters (MEAP buyers!)? I dont believe so. So let's see some action!

    Grammatical errors can be tolerated, but what of statements that dont make sense? For eg. in 1.3.8, there is this sentence: "New systems, designed around a central fact able with a star-shaped set of dimensions, extended beyond the table, column, and row design." Huh? "central fact able"? Do u mean "central table"? And then what are "cubes, dimensions, measures and categories" (next sentence)?
    "On the server side, there is node.js, Connect, and Express." -> huh? perhaps that sentence should be revised? Both Connect and Express build on top of node.js!

    Btw, where did you find this sentence?
    hi, first of all let me prefix my question by saying that i havent bought the MEAP yet (I'm sitting on the fence!). I'd like to take this chance to be able to interact with the authors to find out more, and ask some questions before i decide.

    1. I've done my fair share of AJAX-heavy apps, but... server-side javascript? and what connection does it have, really, with SPAs? MUST we cover server-side js? It may be a "trend", but hey, i am coming to a book on the topic on SPAs, and if it has to waste some of its space to talk about server-side js... it had better be well-justified!

    So i'm hoping the authors can enlighten me here. Thanks.

    2: mentions "new frameworks that make JavaScript more manageable and testable as a first-class language": what frameworks are u planning to cover, and how much space are u planning to devote to them?
    thanks, Josh! you replied earlier than I expected. smilie

    Your point about marshalling overhead: ok. Unless we're writing super high throughput applications, and/or applications that require a very low latency though, i'm not so concerned about that. And node can really be a pain to program in with that evented mode (I know - i've done an app in node before). I know there are workarounds that dont require u to go into nesting hell.. but oh wait. Are we sidetracking too much now? (heh)

    I didnt know chapter 1 covers these topics. I'll download it and take a look (later)!

    Frameworks: jQuery? great! I have no problems with just that - but I was hoping for something at a higher level of abstraction. You know, like angular.js, for example. These higher-level frameworks would appear to be built more for SPAs?

    (btw - your sentence "It's important in static strongly types languages like JavaScript to have coding standards, in a dynamic weakly typed language like JavaScript it is ..." probably needs to be corrected. You mention javascript twice!)
    hm. I was of the impression that using one of these higher-level frameworks would make the development of an SPA far easier, as well as make it easy to maintain - but yes, i admit that only picking one would present a problem (and even the very act of evaluating which one to use!!!). I hope u do make it easy to develop an SPA using just jQuery! I just dont know whether that's going to be easy. But point taken about going to other books instead IF we know which framework to use already!

    How about including a short section (or even chapter!) in the book to help us evaluate (or even give ur thoughts / opinions!) these frameworks?
    thanks, Michael. I can understand if u dont want to cover a project that has a characteristic of constant flux. I wouldnt want to use it! And as for using custom code (so to speak)... i'm ok with it if it's the better solution!

    Do u think there will ever be a "best" higher-level framework, though? (or perhaps what u've built over the years could be it!). I know "best" is a very relative term - but let's just say "generally recommended", in the way that u've chosen to use jQuery over the other javascript libraries...

    Message was edited by:
    > The point is you can swap out any of these solutions as the project demands, and the architecture - the true framework remains.

    haha. Very nice! I cant help but draw a parallel to the martial art of Jeet Kune Do for this philosophy... Gotcha! thanks for elaborating, and for all the answers. I hope you put the gist of this down as well in the book! I reckon it'd be good to!
    I'm finding it hard to follow along with the text when it comes to "prefixed" versions.

    Eg. in the last version of the MEAP (v11), when it starts talking about CSS gradients (and i'm sure elsewhere as well!) in section 10.5. The book is written as if the "prefixed" version is as simple as using the browser-specific prefix (otherwise special attention would have been made to give us the exact rules?)

    I have a number of problems with this.

    1. are the prefixes specifically made clear in the book? not exactly. They are mentioned on page 317 of the pdf - but not in a place where you'd expect it. And then this mention makes reference to the "browser support section".. which really doesnt mention the prefixes at all?

    2. (And this is what is causing a big problem for me right now) "Prefixing" is not as simple as merely adding the browser-specific prefix!

    Try the following:

    background: -webkit-linear-gradient(left 315deg, #000, #fff);

    (Just adding the '-webkit-' prefix to the example given on page 373)

    Doesnt work, unfortunately....
    precisely as mentioned in - the zip is only until chapter 4
    hi, I'm not so sure that setting letter-spacing and word-spacing to "-0.4em" is the answer to the problem raised ("You can see that despite the margin being set to zero there is still a gap between the elements on each row.").

    1. Are you sure that every browser will be using 0.4em as the spacing? is this the standard?

    2. You should be using html properly, instead of using something like negative spacing. The fact is that when u introduce a space (including a "
    ") in the source html between inline elements, the browser necessarily inserts a gap between them. So dont insert the space!

    <section>blah this is inline-block</section><aside>this too</aside>

    Instead of:

    <section>blah this is inline-block</section>
    <aside>this too</aside>
    thanks, Robert

    1. Perhaps... but I would at least have preferred the font size 0 solution.

    2. ah well, HTML is what it is... We are fixing it as per HTML! (This is the "perfect" solution?) Who edits raw html nowadays, anyway? I'm expecting most of us probably deal with a templating language (haml, erb, etc.)... than with raw html. We can drop down to it... but we have other solutions as well.

    Thanks for the link to css-tricks. Good to find out about the font size 0 solution!
    thanks. Let us know when it's updated!

    Oh, and uh... no Mac OS X cruft, pls! (see also

    Message was edited by:
    as per title. Where are the rest?
    as the title says - could we have a clean zip? I dont want to have to remove the mac os x cruft (or to even download it) from a zip after downloading. Thanks.
    I do notice. And i'm on mac os x! I unzip from the command line, and see all that stuff coming out... :-\r

    As for your editor forgetting... u mean u're not the one generating it? Couldnt u simply do so?
    In the latest version of the MEAP, why does the width of the section and aside change from 54% / 25% to 70% / 30%? See book page 264, vs book page 265. (This is section 8.2.1 - "Mixing different length units with calc")
    any chance of getting these corrected in the pdf? (Anyway - book page 14, pdf page 47)
    thanks, rdthrush. As a note (I want to document this for myself too), as of the latest pdf (current as of today), it should be

    - "book page" 134 (pdf page = 167), "trigger the hander", and
    - "book page" 170 (pdf page 203), "Enables or disabled effects"
    guys - I would suggest you air your grievances to Manning., (203) 626-1510, or

    To be sure, i'm not saying that it's Yehuda's fault (he's been kept busy doing all this coding) - but somebody in Manning has got to be held accountable for the way we've all been treated.
    jmb-d, you *might* have better luck posting in the old forum. Perhaps most people havent moved over to this new forum yet...
    thanks, guys. I actually enquired about this with support@manning - and I got back a very lackadaisical reply that absolutely disgusted me... "The version might be wrong but it should be the most current version of the ebook."

    At least a little bit more action, acknowledgement - and even explanation if the content had not changed - would have been great? This isnt the way to treat your customers! And then, similar to fedeghe, I decided to look a bit more into the details of the 2 pdfs - and saw that their creation dates are the SAME... Something's wrong here. I need the actual update... or else a proper explanation. Not a brush off.
    thanks, Bear. Appreciate ur responsiveness and attention to this thread.