不要站在巨人的肩上耍人

本文是对《NoSQL数据库入门》一书的评论，原文载于豆瓣。

差不多2个半小时翻完了这本书，这本书算是入门中的入门，没有涉及具体的技术细节，加之有一些代码示例占了篇幅，所以读起来比较快。

读完本书最大的收获有两点：

1. 原来 NoSQL 的意思是“不只有 SQL”，之前一直以为是 No SQL；
2. 被耍了。

至于第一点没什么好展开细说的，我不是专家，对 NoSQL 技术没有更深入的见解；那么就说一说第二点。

在说之前还要申明一点：我不是出版行业业内人员，对这一行了解也不多，以下言论完全基于个人“臆测”。

为什么被耍了？因为这本书不是把你当读者的，而是把你当成 QA（质量保证）人员。

1. 拿到书的第一眼我就发现，书脊下方严重变形。这是在考验我的质检能力啊，不过这个考察太简单了。这本书的印刷量 1-4000 册，技术类书籍大都如此。这个数量级，如果交给印刷厂的话，半天应该没问题（猜测），印刷厂应该会有质检人员（不会没有吧），我理解这位质检人员疲于工作，没有发现这种扫一眼就能发现的质量问题；那么出版社应该有监管人员吧，如果这位监管也没有发现，最终导致这本次品流入了我的手，我就忍了吧，毕竟这是外表，不能以貌取书；

2. 看了外面看内容吧。怀揣着对 NoSQL 的好奇心，我立马忘记了书脊的变形，开始翻看内页。因为 1.1 节在豆瓣看过试读，大概的扫了一眼就翻过去了。到现在，心情一直不错。但是在 P12 时我愣了一下，“http://nosql-databse”？这是什么类型的 URL，再看下面的附图，我明白了，少了“.org”。至此之后我的心情算是被完全破坏了：

P17 最后一行，“那就更不起了”是什么意思？
P19 第一段第三行，“Reds” 是什么？
P22 的注释1在穿越了吧？
P27 第二行，“⋯⋯ SQL 文”是什么意思？
P28 倒数第三行，“CACHESIAZE”?
P34 注释1，“https: //….”，你确定 // 之前需要空格？
P36 表 2-4，你确定有种编程语言叫“Pert”？
P40 第二个代码片段，“# {}”（# 后有空格），你确定 Ruby 中的字符串插值是这个句法？（类似错误很多）
P45 注释2，“…/blog? p=31”，你确定“p=31”之前有空格？（类似错误很多）
P47 注释3，“…./nosqltokoy tyrantnetvibes…”，你确定“”之前需要空格？（类似错误很多）
P62 注释1，“….wikipedia.0org/…”，原来维基百科的 URL 是e这样的

然后基本上都是示例，读的比较快，没发现什么错误。终于翻到最后一夜了，但是：

P199 倒数第二行，“….开始正式使用 HandlerSocke 了 t”，“了”明显做了第三者，非要插足“e”和“t”之间。

然后是扉页，硕大的几个字“站在巨人的肩上”。

又免费做了一次校订。

还有一个国内技术书籍的一个通病，中英文混排时英文字体的使用，咱能不使用系统自带的宋体来渲染英语好吗？咱在写代码的时候使用 monospace 字体族好吗？这是做技术人员的基本素质，您老这样不把下一代码农教坏了吗？

看完整本书最大的感受是被耍了，作为一个读者没有被尊重，这完全是一个“草稿”，为什么却已经推向了市场？

这些错误，作为一个完全的初学者都能发现，难道出版社专业的图书编辑没有发现？

如果一个出版社不能尊重读者、不重视图书的质量，站在巨人的肩上不是看得远，而是摔得更疼。

致出版社：

1. 重视读者，关注细节
2. 招个懂技术的图书编辑吧
3. 译者一定要靠谱

这是在逼我学日语看原版书吗？