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.全局。所有 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分鐘 一次以保證儘可能與官方服務同步。

1. 當前 registry.npm.taobao.org 是從 registry.npmjs.org 進行全量同步的.
2. 當前 npm.taobao.org 運行版本是: cnpmjs.org@0.4.1
3. 系統運行在 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/.cnpmrc"
#Or alias it in .bashrc or .zshrc
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)