jacksontian/diveintonode_site

《深入浅出Node.js》书稿配套网站

Hi there 👋

Here are some ideas to get you started:

• 🔭 I’m currently working on Darabonba.

diveintonode_site's Issues

配套网站挂了 ?

diveintonode.org 无法访问

勘误/疑问(第一印)

p208 请求方法的代码片段中，forEach循环里面的
routers[method]={};
应该是routers[method]=[];吧？

堪误

6页，trunk -> chunk

配套网站只有留言功能？

没找到下载代码段的地方？……

难道要手打？

（我敲键盘声音响，晚上手打代码怕被揍的说……

勘误和疑问

序一

pa. -1 （倒数第一段）

只有你爱好技术，都推荐你阅读它

s/有/要/

第7章 网络编程

p. 150 pa. 2 l. 1 (页150，第2段的第1行

在Web领域，大多数的编程语言需要专门的web服务器作为容器，如ASP、ASP.NET需要IIS作为服务器，PHP需要搭载Apache或Nginx环境等，JSP需要Tomcat服务器等。

现代的web领域，编程语言不自带个web服务器，出门都不好意思和人打招呼：

Python

python -m SimpleHTTPServer

Ruby

rackup -b "run Rack::Directory.new '.'"

PHP也跟风了：（记不清了，好像是5.4加的？）

php -S localhost:8888

Go

package main
import "net/http"
func main() {
        panic(http.ListenAndServe(":8080", http.FileServer(http.Dir("/usr/share/doc"))))
}

第10章 测试

p. 276 pa. 4

1. 工程化

这部分的内容似乎和下一章“产品化”的“11.1 项目工程化”有所重叠。

[软文]不配叫 "深入浅出" 的Node非入门图书!

~ 非业余吐槽专业大妈! ——来自大妈 @ZoomQuiet 的吐槽

众所周知

"深入浅出" 是 O'REILLY 公司 Head First 系列畅销技术入门图书的中译版统一前缀;

参考: The Learner's Journey in Practice - Head First Labs

就可以知道, Head First 系列,是 O'REILLY 公司,运用多年的技术图书编辑经验,精心设计的一款入门图书的撰写风格;

• 完全面向纯小白
• 多图,大图
• 基于学习的心理活动顺序

而 @朴灵 的这本书,完全跟 Head First 系列风格不沾边!

• 行文极其顺畅,没有美国/英国/德国味儿, 就是**程序猿平时说话的腔调, 没有 Head First 里的幼儿园范儿!
• 内容的逻辑是简明的 介绍背景->提出问题->解决问题 的纯粹一线程序猿思路,完全无视了小白的阅读压力 ~ 当然,俺是吞吐无碍的,哈哈哈!
• 作者自个儿也承认,根本不是写书的料,完全是在编辑的淫感威下上了贼船,最后只能用习惯的学习笔记的形式聚集而成

综上! 俺目测这书就如基友们建议的: 九深一浅吼 Node 比较合乎风格.

所以,面对这本注定在** Node.js 发展史上将留下标杆性地位的图书,大妈无法免俗的羡慕嫉妒恨,
决定,坚决的不给任何溢美之辞

就挑错,不说好话!

目测,这书将成为 全端工程师 的最佳解释:

~ 会Node 的前端工程师,才是 全端 的...

图书要有图书样儿

即使可以编辑为电子版, 但是,图书永远是一个相对封闭的内容聚合,
无法简便的通过链接快速跳转到相关的资料/代码/系统...

所以,任何一本图书,要尽可能的完备,不打断读者的阅读,
尽可能的,在连贯的叙述中,吻合绝大多数人的心理进程模式的,
将领域问题讲明白, 帮助读者破迷妄/梳系统/入新知.

所以,任何目测可能超出读者知识范畴的知识点,都应该就地给予简要解释,
同时:

• 不中断行文的排版逻辑
• 不影响读者的翻阅顺序
• 配合当前内容的片面解释,不应该引出更多的问题

所以,旁/边/尾注 是必须的,也是跳出呈体系的知识介绍, 抒发作者自个儿情绪的好地方!

另外,每章之后的参考链接,也要认真对待

• 列的越多,越精当, 是对学习过程中获得重要帮助的贡献者们的尊敬
• 但是,也要考虑到读者的使用, 有心的读者如果想逐一查阅, 印刷出来的大堆字串,输入是异常痛苦的!
• 所以,应该逐一给出简要的介绍,说明是本章什么方面技术的什么性质的资料,以及读者根据自身需要选择查阅哪个
• 选择靠谱的缩址服务,将原始链接,转换为方便输入的短链! 当然,原始链接也应该保留...

千言万语不如一图

Node 因为其特殊的秉性,得以贯通前后端, 但是,具体工程应用中,必须正当理解的领域/概念/知识点/技巧.. 太多了!

作者,已经发现,复杂的技术概念,使用流程图/概念图/思维图谱 等图配合代码来表述要容易理解的多.

那么,对于各个章节, 纷繁的知识点,也应该使用图谱的方式进行总结.

甚至于,可以在各个小节末尾, 用图谱的形式,将当前已经描述过的问题以及对应技术点,表述出来,
这相当于帮助读者理解所有涉及方面的技术问题间的关系, 形成作者长年实践才总结出的知识体系!

为毛没有数据库的内容!

无论互联网怎么发展, 数据库是跑不了的,无论是否 NoSQL...

毕竟, 任何系统归到底,都是对数据的收集/分析/处理/输出.

所以, Node 以全端能力的姿态降临人世, 同数据库打交道,简单是必须的,躲不了的...

但是,通篇,为毛没有 Node 同各种主流数据库的分析/介绍/推荐/分享?!

为毛没有整体的团队协同分享?

Node 再NB ,现代公司,也不可能将一个完备的业务系统交给一个程序猿完成,
必然是团队作战的, 但是,以往 C++/JAVA/PHP 的团队,迁移到 Node 平台后,
应该使用什么样的工具链来完整的重构整个开发协同流程?!

Google 支持的Yeoman 就是结合了 Grunt, Bower, 等等优秀工具的一个工具箱,
试图将 RoR 的约定高于配置等先进的获得成功的**,代入全端开发体验中,

作者特别提及的 Meteor 也是相同的思路,只是试图使用唯一的应用框架来统一所有过程,没有 Yoeman 开放.

Taobao 算是国内最早开始 Node 工程化实践的团体,应该已经摸索出了协同平台的基本原型.

**一向有重产品轻工具的态度, 认为无法让最终用户淘钱的开发活动都是浪费,
而 Yahoo! Google Github 无论公司大小,都是将最NB 的开发者投入到工具/支持系统的开发中.

所以,即使现在 Taobao 没有或是不打算开源准备中的 Node 平台,
也应该及时分享, 在Node 语境中, 团队协同时,必须约定/掌握/尽可能频繁使用的工具,以及为什么,以及能产生的效果...
这是一本书可能为**一个领域技术发展带来改进的最有效内容!