Some publishers (including Cisco Press) have authors work with a development editor during the writing of the book. This is especially important for new writers or engineers who don't have very good writing skills. Cisco Press also has the writer work with technical reviewers as the writing is progressing.
I realize I was critical of Cisco Press copy editing in my previous message, but, in general, their books are much better than the competition because they work in this mode (with development editors and technical reviewers). Some publishers, such as Wiley, won't let an author in the door unless the author has proven writing skills and technical expertise. That method works also. And then there are the publishers that just want to push content out there and start collecting $$$$s as quickly as possible. Their stuff tends to suck. ;-) Priscilla At 04:02 PM 1/17/02, Chuck Larrieu wrote: >It may also be that copy editors think that because it is tech, that what >they see, although it does not make sense grammatically, does make sense to >other techies. For a tech review I am currently working on, I had to >specifically call the editor and tell him that the chapters were very poorly >written, had lots of poor sentence construction, not to mention bad grammar, >and that he should specifically be aware that the text made no sense no >matter who was reading it. Hmmm... come to think of it, I haven't heard from >those people lately. I wonder if they fired me? ;-> > >I suspect that in this mad rush to get tech books out the door, many of the >publishing houses are operating under the assumption that whatever a tech >writer writes is correct. Kinda like the emperor's new clothes? Can't be >understood by a fool? > >Chuck > > >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > At 12:21 PM 1/17/02, R. Benjamin Kessler wrote: > > >I have a couple of "nit-picky" complaints about the book (as I do about > > >almost every book I read). There are some typo's as a previous poster > > >indicated. One of my biggest pet peeves is the use of the term >"continuous" > > >when the author (probably) means "contiguous" - one sees this most often > > >when discussing OSPF. > > > > That says that the author didn't look at the copy-edited material. New > > authors assume that publisher's copy editors have a clue. They don't. They > > apply rules for "fixing" words and sentences without any idea what they >are > > doing. > > > > This means that you will probably find other minor mistakes in the book > > too. Don't blame the author, although the author should have been more > > careful during the final phases of the book project. > > > > Cisco Press copy editors once changed every case of Mbps to MByte in a > > book! In my book, in the index, they changed long fat network (LFN) to >long > > file names. See RFC 1323 for the true meaning of elephant (LFN). > > > > Thanks for your thorough review of the book. > > > > Priscilla > > > > > Note, this book isn't unique in this mis-use of the > > >term; there are many CCO documents that also make this "error." I'm > > >assuming that this is the product of a spell-checker that didn't know the > > >term contiguous, suggested continuous and someone hit "replace all." >Before > > >the flame-war starts, I know that these two words have *similar* meanings > > >but in this case I - my personal opinion - think that contiguous is 'more > > >right' - besides, it's the term used in the RFC. > > > > > >Since I'm picking nits; the author indicates that the OSPF process ID on >a > > >router should be thought of "as an Autonomous System ID. This number >should > > >be the same on all routers within the autonomous system." Per CCO, this >is > > >a locally significant setting used only to distinguish between multiple >OSPF > > >routing process on a particular router. If we were to apply the RFC2119 > > >definition of "should" to this statement one might think that certain > > >problems may occur if this practice wasn't followed. I don't believe >this > > >to be the case but I'm sure someone on the list will correct me if I'm > > >wrong. There's nothing wrong with using the same process ID on all of >your > > >OSPF routers; I would guess that networks are configured that way more >often > > >than not; but isn't a requirement. Given that the lab exam is all about > > >splitting hairs to the most minute detail and knowing the various >protocols > > >in depth, it probably should have been noted (as in other texts) that two > > >adjacent routers can have different process IDs configured. > > > > > >There are some outright mistakes in the book - I just checked the >CiscoPress > > >site for an errata and didn't see one yet. Here one that I recall off >the > > >top of my head: > > > > > >EIGRP - (p.691) at the bottom of the page, the 'distance' command. > > >- this is almost a direct copy/paste from the IGRP chapter; does not >include > > >the required information to change the admin distance of the EIGRP >routing > > >process (which requires both an internal and external distance); it only > > >lists the syntax to change the distance of a specific neighbor's updates. >I > > >find it funny that the EIGRP chapter says "For a specific example and >more > > >practice with the 'distance' command, see" the IGRP chapter. When you >look > > >at the IGRP chapter, it uses the same sentence to point you to the RIP > > >chapter. > > > > > >Anyone who has walked into an EIGRP network with multiple, unfiltered > > >redistribution points into a RIP domain will know first-hand the >importance > > >of knowing how a router handles internal vs. external EIGRP routes. > > > > > >Additionally, I thought the section on PPP authentication could have used > > >some more work on the one-way authentication options (both PAP and CHAP). > > > > > >Bottom-line, this seems to be a well written book; it gives you some good > > >examples and labs to work on your own, etc. It won't replace any of the > > >other "must haves" on the bookshelf (e.g. Doyle, Caslow, Thomas, etc.) >and > > >unfortunately, (as it seems with all of the books published these days) >you > > >have to play 'reporter' and verify the information in the book with some > > >other source (CCO, RFCs, other texts) - this is a topic I could rant on >for > > >quite some time (considering the $thousands - literally - I've spent on > > >training materials which contain errors). > > > > > >-----Original Message----- > > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > >Sent: Wednesday, January 16, 2002 7:18 PM > > >To: [EMAIL PROTECTED] > > >Subject: OT: First Impressions - CCIE Practical Studies [7:32237] > > > > > > > > >Just got my copy. > > > > > >Reading the "About the Authors" section alone is impressive. All those > > >associated with the book are CCIE's. I look forward to discovering if >there > > >are any errors in the book. One would hope not, given the credentials of >the > > >writers and reviewers, one of whom was the Halifax Lab Proctor for >several > > >years. > > > > > >So far I have browsed all of the first chapter "The Key Components for > > >Modeling an Internetwork" > > > > > >This chapter covers in good detail all those basic questions - the config > > >register, configuring a router as a frame switch, password recovery, show > > >and debug ( called "the big show" and "the big d" respectively, >throughout > > >the book. ) building a terminal server, and much much more. This alone >tells > > >me that this book might be a good investment for those just starting out, >as > > >well as those prepping for the CCIE Lab. Sure, all of this information is > > >available elsewhere, but with this book, it is in one place, easily >located, > > >and clearly explained. > > > > > >There is even a section about configuring networking on windoze >computers. > > >Considering the number of raw beginners who are coming into the > > >certification process, this is helpful. > > > > > >I'll have more comments after I have had a chance to look at the "good" > > >stuff. > > > > > >Chuck > > ________________________ > > > > Priscilla Oppenheimer > > http://www.priscilla.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32369&t=32237 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
