2015第40周二Node学习

node历史

今天看cnode开源项目用了io.js，在查这个项目时发现这篇文章node历史，node.js和io.js关系
谈到Node.js的由来，不可避免要聊到它的创始人Ryan Dahl。在2009年时，服务端JavaScript迎来了它的拐点，因为Ryan Dahl带来了Node.js，在那之后Node.js将服务端JavaScript带入了新的境地，大量的JavaScript在GitHub上被贡献出来，大量的JavaScript模块出现，出现了真正的繁荣。Node.js创始人Ryan Dahl。
Ryan Dahl的经历比较奇特，他并非科班出身的开发者，在2004年的时候他还在纽约的罗彻斯特大学数学系读博士，期间有研究一些分形、分类以及p-adic分析，这些都跟开源和编程没啥关系。2006年，也许是厌倦了读博的无聊，他产生了『世界那么大，我想去看看』的念头，做出了退学的决定，然后一个人来到智利的Valparaiso小镇。那时候他尚不知道找一个什么样的工作来糊口，期间他曾熬夜做了一些不切实际的研究，如如何通过云进行通信。从那起，Ryan Dahl不知道是否因为生活的关系，他开始学习网站开发了，走上了码农的道路。那时候Ruby on Rails很火，他也不例外的学习了它。从那时候开始，Ryan Dahl的生活方式就是接项目，然后去客户的地方工作，在他眼中，拿工资和上班其实就是去那里旅行。此后他去过很多地方，如阿根廷的布宜诺斯艾利斯、德国的科隆、奥地利的维也纳。Ryan Dahl经过两年的工作后，成为了高性能Web服务器的专家，从接开发应用到变成专门帮客户解决性能问题的专家。期间他开始写一些开源项目帮助客户解决Web服务器的高并发性能问题，尝试过的语言有Ruby、C、Lua。当然这些尝试都最终失败了，只有其中通过C写的HTTP服务库libebb项目略有起色，基本上算作libuv的前身。这些失败各有各的原因，Ruby因为虚拟机性能太烂而无法解决根本问题，C代码的性能高，但是让业务通过C进行开发显然是不太现实的事情，Lua则是已有的同步I/O导致无法发挥性能优势。虽然经历了失败，但Ryan Dahl大致的感觉到了解决问题的关键是要通过事件驱动和异步I/O来达成目的。
在他快绝望的时候，V8引擎来了。V8满足他关于高性能Web服务器的想象：
1.没有历史包袱，没有同步I/O。不会出现一个同步I/O导致事件循环性能急剧降低的情况。
2.V8性能足够好，远远比Python、Ruby等其他脚本语言的引擎快。
3.JavaScript语言的闭包特性非常方便，比C中的回调函数好用。

于是在2009年的2月，按新的想法他提交了项目的第一行代码，这个项目的名字最终被定名为“node”。Node.js随着JSConf EU会议等形式的宣传下，一家位于硅谷的创业公司注意到了该项目。这家公司就是Joyent，主要从事云计算和数据分析等。Joyent意识到Node.js项目的价值，决定赞助这个项目。Ryan Dahl于2010年加入该公司，全职负责Node.js项目的开发。此时Node.js项目进入了它生命历程里的第二个阶段：从个人项目变成一个公司组织下的项目。
这个时期可以的组织架构和管理模式可以总结为“Gatekeeper ＋ Joyent”模式。
Gatekeeper的身份类似于项目的技术负责人，对技术方向的把握是有绝对权威。历任的Gatekeeper为：Ryan Dahl、Isaac Z. Schlueter、Timothy J Fontaine，均是在Node.js社区具有很高威望的贡献者。项目的法律方面则由Joyent负责，Joyent注册了“Node.js”这个商标，使用其相关内容需要得到法律授权。
技术方面除了Gatekeeper外，还有部分core contributor。core contributor除了贡献重要feature外，帮助项目进行日常的patch提交处理，协助review代码和合并代码。项目中知名的core contributor有Ben Noordhuis，Bert Belder、Fedor Indutny、Trevor Norris、Nathan Rajlich等，这些人大多来自Joyent公司之外，他们有各自负责的重要模块。Gatekeeper除了要做core contributor的事情外，还要决定版本的发布等日常事情。

Mikeal Rogers的威望不是建立在他对Node.js项目代码的贡献上，他的威望主要来自于request模块和JSConf会议。其中JSConf是JavaScript社区最顶级的会议，他是主要发起人。
在2014年8月，以Mikeal Rogers为首，几个重要core contributor一起发起了一个叫做“Node forword”的组织。该组织致力于发起一个由社区自己驱动来提升Node、JavaScript和整个生态的项目。“Node forword”可以视作是io.js的前身。这些core contributor们在“Node forword”上工作了一段时间，后来因为可能涉及到Node这个商标问题，Fedor Indutny愤而fork了Node.js，改名为io.js，宣告了Node.js社区的正式分裂。
简单点来说这件事情主要在于社区贡献者们对于Joyent公司的不满，导致这些主要贡献者们想通过一个更开放的模式进行协作。复杂点来说这是公司开源项目管理模式的问题所在，当社区方向和公司方向一致时，必然对大家都有好处，形同蜜月期，但当两者步骤不一致时，分歧则会暴露出来。这点在Node.js项目的后期表现得极为明显，社区觉得项目进展缓慢，而Joyent公司的管理层则认为他稳定可靠。

io.js的开放管理模式主要体现在以下方面：

不再有Gatekeeper。取而代之的是TC（Technical Committee），也就是技术委员会。技术委员会基本上是由那些有很多代码贡献的core contributor组成，他们来决定技术的方向、项目管理和流程、贡献的原则、管理附加的合作者等。当有分歧产生时（如引入feature），采用投票的方式来决定，遵循少数服从多数的简单原则。基本上原来由一个人担任的Gatekeeper现在由一个技术委员会来执行。如果要添加一个新成员为TC成员，需要由一位现任的TC成员提议。每个公司在TC中的成员不能超过总成员的1/3。
引入Collaborators。代码仓库的维护不仅仅局限在几个core contributor手中，而是引入Collaborators，也就是合作者。可以理解为有了更多的core contributor。
TC会议。之前的的沟通方式主要是分布式的，大家通过GitHub的issue列表进行沟通。这种模式容易堆积问题，社区的意见被接受和得到处理取决于core contributor的情况。io.js会每周举行TC会议，会议的内容主要就issue讨论、解决问题、工作进展等。会议通过Google Hangout远程进行，由TC赞同的委任主席主持。会议视频会发布在YouTube上，会议记录会提交为文档放在代码仓库中。
成立工作组。在项目中成立一些细分的工作组，工作组负责细分方向上的工作推进。
io.js项目从fork之后，于2015-01-14发布了v1.0.0版本。自此io.js一发不可收拾，以周为单位发布新的版本，目前已经发布到2.0.2。io.js项目与Node.js的不同在行为上主要体现在以下方面：
新功能的激进。io.js尽管在架构层面依然保持着Node.js的样子（由Ryan Dahl时确立），但是对于ECMAScript 6持拥抱态度。过去在Node.js中需要通过flag来启用的新功能，io.js中不再需要这些flag。当然不用flag的前提是V8觉得这个feature已经稳定的情况下。一旦最新的Chrome采用了新版本的V8，io.js保持很快的跟进速度。
版本迭代。io.js保持了较高频率的迭代，以底层API改变作为大版本的划分，但对于小的改进，保持每周一个版本的频率。只要是改进，io.js项目的TC和Collaborators都非常欢迎，大到具体feature或bug，小到文档改进都可以被接受，并很快放出版本。
issue反馈。Node.js的重要的贡献者们都在io.js上工作，Node.js和io.js项目的问题反馈速度几乎一致，但是问题处理速度上面io.js以迅捷著称，基本在2-3天内必然有响应，而Node.js则需要1个礼拜才有回复。

最终的结论是Node.js项目和io.js项目都将加入Node.js基金会。Node.js基金会的模式与io.js较为相似，但是更为健全。Mikeal Rogers在他的一篇名为《Growing Up》的文章中提到io.js项目需要一个基金会的原因。io.js项目在技术方面的成熟度显然要比最初的Gatekeeper时代要更为先进，给予贡献者更多的管理权利。然而在市场和法律方面，还略显幼稚。最终无论是顾问委员会，还是io.js都选定以基金会的形式存在。这个基金会参考Linux基金会的形式，由董事会和技术委员会组成，董事会负责市场和法律方面的事务，技术委员会负责技术方向。

从io.js的分裂到Node.js基金会，从外人看起来似乎如一场闹剧一般，然而这个过程中可以看到一个开源项目自身的成长。尽管io.js将归于Node.js基金会，像一个离家出走的孩子又回家一般，它的出走可能要被人忘记，但从当初的出发点来说，这场战役，io.js其实是赢家。穷则思变、不破不立是对Joyent较为恰当的形容。如果Joyent能提前想到这些，则不会有社区分裂的事情发生。Node.js处于停滞状态的开发和io.js的活跃情况之间，目前免不了大量的Merge工作。作为和解的条件之一，Node.js基金会之后Node版本的发布将基于目前io.js的进展来进行。后续的合并工作示意如下：
now
(io.js) v2.0 : v2.x
| | : |
v0.10.x /--------------:-----------------\ Node.js 2.0
|/ : __|_
\ : /
--------------:-----------------/
| | : | |
(node.js) v0.12.x : v0.13.x v0.14.x

在未完成合并之前，io.js会继续保持发布。Node.js的下个大版本跨过1.0，直接到2.0。
io.js项目的TC将被邀请加入Node.js基金会的TC，毕竟两者在技术管理方面达成了一致。基金会将在黄金和白银会员中选举出董事、技术委员会成员中选举出技术委员主席。
对于成为Node.js基金会成员方面，企业可以通过赞助的方式注册成为会员。

npm

npm管理项目依赖

package.json

npm命令运行时会读取当前目录的 package.json 文件和解释这个文件，这个文件基于 Packages/1.1 规范。在这个文件里你可以定义你的应用名称( name )、应用描述( description )、关键字( keywords )、版本号( version )、应用的配置项( config )、主页( homepage )、作者( author )、资源仓库地址( repository )、bug的提交地址( bugs )，授权方式( licenses )、目录( directories )、应用入口文件( main )、命令行文件( bin )、应用依赖模块( dependencies )、开发环境依赖模块( devDependencies )、运行引擎( engines )和脚本( scripts )等。

npm配置

npm 拥有很多默认配置。你可以使用这些默认的配置，也可以修改这些默认的配置，甚至可以在环境变量或命令行下修改这些配置。配置的权重是如下顺序定义的：
1.命令行，使用—为前缀的参数。比如 —foo bar，设定变量 foo 的值为" bar “。—foo 后不带值的参数，设定 foo 的值为 true 。
2.环境变量，所有 npmconfig 为前缀的环境变量。比如 npm_config_foo = bar ，设定变量 foo 为 “ bar "。
3.用户定义。所有的变量存储在 HOME/.npmrc文件里的变量。4.全局。所有HOME/.npmrc 文件里的变量。
4.全局。所有 PREFIX/etc/npmrc 文件里的变量。$PREFIX 变量可通过 npm prefix -g 获取，一般默认是 /usr/local。
5.内置的配置。通过安装时运行 ./configure 所定义的变量。可通过命令curl http://npmjs.org/install.sh | env npm_config_foo=bar sh 设置。

使用配置能给我们带来很大的灵活性。比如我们使用 npm install 时，对默认的资源库地址 https://registry.npmjs.org/ 不是很满意，我们可以使用下面的命令来更改资源库地址。

npm --registry "an other registry" install express
#或者下面的命令
env npm_config_registry="an other registry" npm install express

npm link

可以很方便的使用安装在全局下面的模块依赖；

在当前目录下npm link 将当前模块链接到全局模块库
在当前目录下npm link [moduleName] 可以依赖全局模块，然后项目中代码就可以用require()调用了。

对公共依赖的处理方式如下：

npm install coffee-script -g # 全局模式下安装coffee-script
cd ~/work/node/test # 进入开发目录
npm link coffee-script # 把全局模式的coffee-script模块链接到本地的node_modules下
cd ../test-example # 进入另外的一个开发目录
npm link coffee-script # 把全局模式的coffee-script模块链接到本地
npm update coffee-script -g # 更新全局模式的coffee-script，所有link过去的项目同时更新了

cnpm

npm默认仓库在国外，下载比较忙，国内可采用淘宝的npm镜像。淘宝的 NPM 镜像是一个完整的npmjs.org镜像。你可以用此代替官方版本(只读)，同步频率目前为 15分钟一次以保证尽量与官方服务同步。

当前 registry.npm.taobao.org 是从 registry.npmjs.org 进行全量同步的.
当前 npm.taobao.org 运行版本是: cnpmjs.org@0.4.1
系统运行在 Node.js@v0.11.12 上.

可以通过定制的 cnpm (gzip 压缩支持) 命令行工具代替默认的 npm，支持 npm 除了 publish 之外的所有命令。
通过下面命令安装

npm install -g cnpm --registry=http://registry.npm.taobao.org

或者添加alias如下：

alias cnpm="npm --registry=http://registry.npm.taobao.org \
--cache=HOME/.npm/.cache/cnpm −−disturl=http://dist.cnpmjs.org −−userconfig=HOME/.npm/.cache/cnpm \
--disturl=http://dist.cnpmjs.org \
--userconfig=HOME/.cnpmrc"
#Or alias it in .bashrc or .zshrc
echo '\n#alias for cnpm\nalias cnpm="npm --registry=registry.npm.taobao.org \
--cache= echo '\n#alias for cnpm\nalias cnpm="npm --registry=registry.npm.taobao.org \
--cache=HOME/.npm/.cache/cnpm \
--disturl=http://dist.cnpmjs.org \
--userconfig=$HOME/.cnpmrc"' >> ~/.zshrc && source ~/.zshrc

来自为知笔记(Wiz)