Fred's blog

熟悉並學習實作 Node.js Stream，在 Node.js 開發者生涯裡是一件很重要的事，尤其在資料處理的工作上更是需要運用 Stream。在這些應該用的情境下，若不懂得使用 Stream，我們所開發出來的程式其執行效能及穩定性會相當令人擔心。 而如果你從未自己實作過 Stream，從 Transform Stream 開始入手是一個好選擇，也是一個非常實用的開發技巧。 更多關於 Stream 的說明，可以參閱 Node.js 官網上的文件： https://nodejs.org/api/stream.html 什麼是 Transform Stream？ 你可能知道 Node.js 裡有多種 Stream 的機制，但其實主要是 ReadableStream 和 WritableStream 兩種基本 Stream 的組成和變化。而對一般開發者來說，最常自己實作的是 Transform Stream，你可以想像這是一個產品生產線上的加工器，進入 Transform Stream 的資料會被加工後輸出。 而以一個 Stream 而言，Transform Stream 同時具有 ReadableStream（讀入）和 WritableStream（輸出）的特性，俗話說「左耳進右耳出」就是其最佳的寫照。 舉一個 Node.js 官方的例子，利用 Gzip 的 Transform Stream 將通過的資料流進行壓縮： const zlib = require('zlib'); const gzip = zlib.createGzip(); const fs = require('fs'); const inp = fs.createReadStream('input.txt'); const out = fs.createWriteStream('input.txt.gz'); inp.pipe(gzip).pipe(out); 實作第一個 Transform Stream 先不必暸解太多 Stream 的專有名詞和機制，若想要實作一個標準的「耳邊風」Stream，程式碼如下： const Transform = require('stream...

雖然有些概念類似甚至可以相通，但這裡並不是指常聽到的「MapReduce」，本文目的不是要討論如何運用 MapReduce 這樣的架構去處理大資料庫。這裡真正要討論的是，如何使用 JavaScript 裡陣列（Array）中的 .map() 和 .reduce() 方法，並把一些常見的使用方法和情境描述出來大家進行參考。 很多人對這兩個方法不習慣，原因不外乎是這兩種方法本來就不是一個非常直覺的東西，在大多數 JavaScript 語言的開發情境中，其實也沒有非得使用的理由。但不得不說，習慣了這兩個對陣列操作的方法，程式碼會變得簡潔，也更容易能處理一整批的資料。有時也能順便學習到一些「Functional Programming」會用到的概念，無論是在改善程式品質，還是投資自己的角度上，都有相當好處。 從最簡單的遍歷陣列開始 面對一個陣列裡的一堆資料，我們一定是從遍歷開始，一一處理裡面的每一筆資料。你也許已經非常熟悉如何遍歷陣列，最常見的不外乎就是兩種做法。 使用 for-loop： var myArr = [ 1, 2, 3 ]; for (var index in myArr) { console.log(myArr[index]); } 使用陣列內建的 forEach 方法： var myArr = [ 1, 2, 3 ]; myArr.forEach(function(element) { console.log(element); }); 使用 .map() 對每個陣列元素加工 有些時候，我們想對每個陣列元素（Element）進行加工處理，於是最土法煉鋼的方法大概就是這樣： 幫每個元素加一： var myArr = [ 1, 2, 3 ]; for (var index in myArr) { myArr[index] = myArr[index] + 1; } // [ 2, 3, 4 ] console.log(myArr); 這時你可以使用 .map() 方法來達成同樣目的： var myArr = [ 1, 2, 3 ]; var newArr = myArr.map(function(element) { return element + 1; }); // [...

身為 Node.js 使用者的你，還在使用 Express 嗎？快來使用下一代的 Web Framework 吧！Koa 是由 Express 的開發者們出來所開發的新網站框架，嘗試採用了最新的 ECMAScript 6 語法，讓開發者可以用更簡約的方式，開發網站應用程式，讓程式碼更好維護之外，也能受益於最新的語言特性。 穩定版與不穩定版 現在的 Koa 分為 1.0 和 2.0 兩個版本，1.0 使用 ES6 的 Generator 特性，也是目前的 stable 版本，而 2.0 採用 ES7+ 的 async/await，據 Koa 官方說法，2.0 穩定度可以用於實際產品，只是在 ECMAScript 7 規格正式敲定，且 JavaScript V8 Engine 推出原生的實作之前，將無限期處於 unstable 的狀態。也就是說，若你想要在你自己的專案上使用 2.0，你必須使用 babel 這一類的編譯器，因為裡面用到了 ES7 的語法。 本篇文章的重點將放在 Koa 1.0 之上，畢竟在 ECMAScript 7 還處於草案階段的現在，很難說未來會不會有什麼改變。 安裝 Koa 由於 Koa 需要用到 ECMAScript 6 的語言特性，請先檢查你的 Node.js 版本，最少為 0.12 以上，如果你已經使用了 Node.js 4.0 或更高版本，請不用擔心這個問題。 然後透過 NPM 即可安裝模組： npm install koa 開發第一個應用程式 開發 Koa 應用程式非常容易，下面是程式碼範例： var koa = require('koa'); var app = koa(); app.use(function *() { this.body = 'Hello World'; }); app.listen(3001); 跑起來後，用瀏覽器連入 3001 埠即可看到「Hello World」的字樣，因為 this.body 的內容，將會被輸出到前端瀏覽器上。 使用 Generator 打造的 Middleware koa.use() 將用來載入 Middleware，所有連線工作都會經過 Middleware 處理。所以前一個例子裡，我們...

話說，Isomorphic 一直是 Node.js 開發者的夢想，期望同一套程式碼前後端都可以使用，大幅簡化程式碼和加速開發。此外，動態網頁的 SEO 問題也可以同時獲得解決，許多效能問題也可以得到改善。但是，要實現 Isomorphic 的架構，有很多的問題得先解決，會花大量時間在前期工作上，往往讓許多開發者頭痛。 儘管頭痛，仍然阻止不了大家往 Isomorphic 的世界前進，我也因此建立了一個專案「 Lantern 」，希望能讓更多人能以 Isomorphic 架構，快速建構出自己的網站服務，省去許多前期工作的時間。該專案是一個網站服務的樣板，實作了會員系統、權限管理、第三方登入、多國語系和送信機制等功能，在使用者介面上也做了一個還算美觀的介面。基本上，開發者只要 clone 下來，然後修改設定檔或改改介面、增加點功能，就可以快速完成一個屬於自己的全新網站服務。 最特別的是，「 Lantern 」整合了現今所有最新的技術和概念，包括了 Koa、React、FLUX、ES6/7+、Webpack 以及 Semantic UI，大量運用了 Generator、class 及 decorator 等最新 JavaScript 語言特性來簡化設計。所以，如果你想要接觸最新的技術，完全可以透過修改「 Lantern 」專案來學習和熟悉。 目前「 Lantern 」支援 Facebook 剛發佈的最新 React v0.14+ 和 react-router 1.0.0+，也避免使用像 redux 這類反 FLUX 原始設計的框架，讓原本熟悉 React 和 FLUX 架構的開發者，可以快速上手。也提供一些常見的 Extension，方便開發者寫出前後端通用的程式碼，大多數情況下，開發者不需思考程式碼運行在前端還是後端。 快速安裝使用 若想要使用「Lantern」，方式很簡單，先從 Github 取得程式碼： git clone git@github.com:cfsghost/lantern.git 安裝必要之 NPM 模組： npm install 使用 webpack 編譯專案（若要正式上線，可加上 -p 選項來編譯）： webpack 運行網站服務： node app.js 最後可以使用瀏覽器開啟網址，確認是否成功： http://...

自從 Node.js 0.12 版和 io.js 之後，大量的開發者開始了各自的 ECMAScript 6 大冒險，許多人對 Generator 的使用仍跌跌撞撞，對於這種看似「同步（Synchronous）」的「異步（Asynchronous）」機制，有許多人腦袋遲遲無法轉過來。雖然在小弟的書（參閱連結： 新書報到！Node.js 模組參考手冊！ ）已經有清楚的說明 Generator 使用方法，但就許多讀者回函來看，對於 JavaScript 越是熟悉的人，越無法直觀理解 Generator 的思維，甚至是老是抓不准使用的時機點。 尤其是過去我們已經有 Promise、async、Q 和 bluebird 等處理非同步程式流程的模組和工具，很多人就是覺得沒有使用 Generator 的必要。不過，如果你會使用 co 模組，你會突然發現若是將過去的流程機制與 Generator 相搭配，程式開發將變得更為流暢。 若想要安裝 co 模組，可以直接以 NPM 下載： npm install co 本文接下來會說明一些 co 的基本使用，破除一些 Generator 難以使用的地方，讓開發者們更容易開始 Generator 的旅程。 讓原生 Generator 更好用 這是很多人不喜歡使用 Generator 的主因，以往為了使用 Generator，我們還要先建立一個 Generator 的函數，然後不時的去處理 Generator 所返回的資訊，一遍又一遍進入 Generator 之中。因此，無論 Generator 再好用，這些麻煩的動作也完全抵銷他的優勢，大多數人還不如回到舊的流程控制方法，以免徒增自己的麻煩。 而如果使用 co，可以直接將 Generator 函數當作「立即函數使用」，其餘的部份我們可以不需要擔心： var co = require('co'); co(function *() {     console.log('Inside'); }) 再也不用煩惱 yield！ 以前光是 Promise，就已經讓很多人詬病，覺得每次使用 Promise 都要花許多時間對函數進行包裝，而 Generator 也有類似的問題，若是要使用 yield，更是一件大工程。於是，co ...

 『是不是要很厲害才能參加黑客松呢？』這是一個永遠都會有人問的問題。 事實上，黑客松從一開始的出發點，就是三五好友聚在一起進行研究及開發的活動，帶有很純粹的動機。參加這樣的活動，你不必真的很厲害到極點，而最重要的是動手和夥伴合作，過程中可以順便認識朋友與他人交流，讓投入的過程中更加豐富有趣。 從這樣的角度來看，『黑客松式的學習』是不是有可能的呢？如今看來是肯定的，5/23 於台北剛結束的 NodeSchool 聚會就是一場黑客松式學習活動，吸引了近兩百位參加者，共同參與了這場具有黑客精神的學習活動！ 順帶一提，這此使用的場地，也是 黑客松台灣（Hackathon Taiwan） 每個月辦活動的主場地，無論如何，也記得來報名下次 6/13 - 6/14 （六、日）的黑客松活動！ 什麼是 NodeSchool？ NodeSchool 是一個線上學校，目標是運用線上工作坊課程，讓所有人都可以在這學到各種技術。而恰逢 NodeSchool International Day 國際日活動，全球各地都紛紛各自舉行一場 NodeSchool 盛會，因此身在台灣的我們也理所當然響應了這樣的活動。  這個活動的形式相當特別，沒有講師在台上講課，而是採用線上工作坊教材與題目的形式，讓參加者在自己的電腦上挑戰通關。NodeScool 擁有許多工作坊教材，從基礎課程到進階的選修課程都有，除了 JavaScript、Node.js 之外，也有 ES6、WebGL、Three.js、Functional Programing 和 React.js 等課程。詳細的課程資訊，可以參考 NodeSchool 官方網站 。 由於每一份教材都是經過設計，而且每一個主題和關卡都擁有提示和說明，參加者在一題題解答的過程中，可以靠自己慢慢學會一門技術。如果真的遭遇到了自己難以突破的困難，可以跟左右鄰居討論研究，若真的也沒有辦法了，可以找在現場自願的指導員（Mentor）幫忙排解問題。 黑客松式的學習活動 回想起過去從小到大，我們的學習模式，總是有個老師在台上教學，枯燥而乏味，而為了保證教學進度，不免伴隨著填鴨式的教學方法。這樣的模式我們早就習慣，雖不見得喜歡，但也無可奈何，逐漸的，我們的思考和學習，慢慢僵化了。 具有一定寫程式經驗的人都知道，...

經過幾個月努力，新書『 Node.js 模組參考手冊 』終於誕生。這本新書與前一本『不一樣的 Node.js』稍稍不同，主要訴求不是初學者入門，而是參考用書，無論是新手還是已經很熟練 Node.js 的專家好手，都可以拿來參考，還希望各界多多支持！ 有鑑於 Node.js 發展迅速，其應用已經不只是被侷限在 Web 之上，甚至適合各種不同的領域與場景。所以，許多的功能及模組被大量開發出來，從網路應用、桌面應用甚至到嵌入式應用都可以使用 Node.js 來開發。 可以應用在各種場景，代表就會有不少人面對 Node.js 數不清的模組時，總是不知道該怎麼辦，除了很難抉擇之外，更是有很多超出原本常識的模組存在。有些時候，更是需要將許多模組拼湊起來，才能完成一個特殊的功能。 然而，大量的應用範例，也需要花大量時間才能一一摸索，若不是有人事先整理好，對於大多數人來說，無疑是永遠無緣觸碰。因此，這本書為此而生，希望透過大量整理各種應用範例，以減少 Node.js 開發者摸索的時間，加速學習或研究的速度，更甚至縮短產品開發的週期。 如果你是初學者，你可以從中找到一些基本模組的完整範例參考，或是學習模組選擇的方法。如果你已經是很熟悉 Node.js 開發的專家，你可以從本書看到許多使用 Node.js 所開發的特異功能的應用範例，如：Bittorrent、SSH Server、演算法、加密、文件格式、多媒體支援等。此外，本書也將提及 C/C++ 原生模組和 V8 JavaScript 引擎的原理和範例，還有各種資料庫、Message Queue（訊息佇列）等常用的完整使用範例，當然也有今年最新的 io.js 相關內容。 雖然說本書名為模組參考手冊，但整本書卻是以應用範例為導向，並非完全是一個個模組的介紹，有很多是多個模組整合而成的範例，許多部份都是網路上連原文文件都缺少的資訊或文獻，可以說是花大量時間和經驗的結晶。 我只能說，希望讀者們會喜歡！希望能幫上大家工作開發上的忙！請大家多多支持！ 後記 前一本『不一樣的 Node.js』，因為一些模組更新太快，所以有些章節已經有些老舊，如果你是前一本書的讀者，可以和新書『 Node.js 模組參考手冊 』做比對參考，因為裡面有雷同的章節，可以使用新書的方法來取代舊書老舊的部份。 至於舊書翻版，我們已...

這陣子，最怕的就是有人問：『書什麼時候要發行？』，參加社群聚會或活動時，有人會問我，平常周圍朋友也會問我，工作上隊友和客戶都會問我，只有一些親人根本不知道不知道我在寫書，所以不會問我。如果你問我，寫書這件事上，你最怕的是什麼？我會跟你說，出版社截稿日期的死線（Deadline）並不是最可怕的，最可怕的是，它是一種詛咒，讓周圍人都會特別關心你的一種魔法。而這個關心的壓力，讓人喘不過氣來。 還好，書總算從初稿、校稿到排版完成，直到出版社編輯傳來最後的封面設計，才讓人鬆了一口氣。可以告訴大家，書總算要真正出來了！ 事實上，國內 Node.js 的書其實並不多，其中幾乎多為翻譯書，或是從簡體直接翻成繁體中文的書。這讓這幾年一直在到處推廣 Node.js 的我，相當困擾。每當有人問起 Node.js 有什麼書可以看時，我總是無法推薦出很多本給大家參考。所以，當出版社的編輯跟我說，希望寫一本 Node.js 的中文書時，我其實相當開心。 還記得當時接下這個任務後，我便開始思考和回想，在推廣和使用 Node.js 時，所遭遇到的困難是什麼？我能否藉這本書來幫助讀者排除這些困難？甚至給讀者一個更大的視野，一個 Node.js 可以發揮在各種領域的可能性。 此外，網路時代來臨後，有太多的新資料都可以從網路上取得，這本書要提供什麼內容，更是需要被探討的問題。尤其是 Node.js 這樣版本號快速上升的新技術，可能書還沒寫完，內容就已經過時。在種種思索下，期望本書的定位，將帶給大家的不是絕對的技術新知，而是一本學習 Node.js 的參考書和技術指南，讓想入門的讀者可以學會怎麼使用 Node.js，讓已經懂的人可以知道 Node.js 還能做些什麼不一樣的事，更進一步知道從哪裡去得到更多 Node.js 的新知。如果這本書在幾年後，仍有六成的資料值得參考，那就算完美達成我賦予它的任務了。 從引領初學者的角度來看，並參考了一些市上的 Node.js 書籍，也從過去教育訓練和推廣的場合發現一個現象。Node.js 不是什麼很難的新東西，如果有人已經很熟悉 JavaScript 語言，而且能寫的很好，Node.js 根本是小菜一碟。所以，多半不得其門而入的人，是對 JavaScript 不這麼熟悉，或是想使用 Node.js 技術進行第一次接觸程式開發的人。只不過，...

很久沒更新了，自從十二月底退伍之後，一直忙著將書完稿給出版社，沒空坐下來好好在 Blog 上寫點東西。沒辦法，在當兵時閒不下來，就答應了出版社的邀約開始寫 Node.js 的書，因此欠下了書的債。還好，如預期的寫完了，預計這一兩個月應該就會上市，還請各界多多捧場！ 會寫這篇文章的原故，是因為在 Facebook 的社群上，有人問起了關於 Session 和 Cookie 相關性的問題。其實，社群的人都很好，有許多熱心的網友願意幫助別人。不過，為了幫忙回答問題，大家七嘴八舌的東說一句西說一句，甚至引起莫明的論戰，實在不是一個好的現象。況且，使用不同語言、有不同技術背景的人，都各自用自己的角度去描述和解說，讓原本就已經不懂的人更有如瞎子摸象，見不到全貌，搞更糊塗了。對發問的人來說，也不知該聽誰的好。 說來湊巧，筆者剛好在剛截稿的 Node.js 書籍中，對 Session 概念也有許多著墨。所以之前稍微在網路上查過，發現鮮少有人提出對 Session 技術的完整說明，而多半是討論 ASP、.Net、Java、PHP 等語言或框架中如何使用 Session，以及一些延伸的特性，以致很多人對 Session 的概念相當片面。因此這次的事件後，一些網友也建議我把在 Facebook 上回應的完整內容，在 Blog 發表記錄下來，讓更多人對 Session 有個比較完整且正確的認識。 本文目標 在 Web 的世界裡，Session 已經是被廣泛使用的一種技術，大多數的 Web 開發者，肯定都能運用自如。在現今的各類 Web 應用程式的開發框架和工具中，Session 也已經被包裝成容易使用的模式，所以本文也就不再多討論 Session 怎麼去使用，而是著重在 Session 的原理和實現上。要知道，無論是使用哪一種語言，這 Session 概念上都是通用的，沒有什麼不一樣。 Session 是什麼？ Session 之所以會存在，是因為 HTTP 為 stateless 的設計，Server 和 Client 不會一直保持連線狀態，也不會有雙方狀態的即時更新，所以，Server 並不知道 Client 的狀態（像是是否已經登入）。因此，後來的網站開發者，採用 Session 這樣的設計來解決這問題。有趣的是，Se...

今年 COSCUP 很有錢、很盛大，整個活動從中研院移師到了台北國際會議廳，議程多達八軌。很難想像三四年前，自己幫忙 COSCUP 辦活動時的情景，和今天相較之下，當年的活動實在迷你，大家都希望哪一天能殺入台北國際會議廳。沒想到，COSCUP 靠後起之秀多年來的努力，真的在今年達成所有人的願望！我們真的要為這些工作人員和總召柏強喝采！謝謝他們每年不辭辛勞的貢獻！ 慚愧的是，COSCUP 長越大，更顯得我小小的講者的微不足道，如今我唯一能貢獻的，大概就只剩對 Open Source 的熱情。因此，自去年在 COSCUP 2012 的國際舞台『發表退學宣言』後，這個大學讀了七年還是沒畢業的我，今年仍厚著臉皮投了稿，稿也被入取。這邊非常感謝議程審核人員的親睞，讓我贏得今年的一段宣言時間，還有開賣一分鐘內就沒有的入場門票。 :-) 至於我這次要講的主題是：『我用 Node.js 開發自己的 Web 瀏覽器？』 時間地點是：COSCUP 2013 第二天(8/4) 10:00，101CD 場。 其實，正當投稿截止之際，當時熱映的『鋼鐵人3』給我了很大的啟示。不禁思考，身為工程師的我們，是否已經被工具和自己曾經所創造的東西所束縛了？如果我們今天把眼前的電腦給砸了，是否全身上下功力全失？無法有任何作為？ 這樣的概念，套在 JavaScript 這個近年來很夯的語言上，更是貼切不過。對很多人而言，失去瀏覽器為依靠的 JavaScript，令人感到不安、充滿焦慮，好像就不知道能用 JavaScript 做什麼事了。所以，為了破除迷思，就面對他吧！這是一個小小的實驗，讓我們嘗試用 JavaScript(Node.js) 打造自己的網頁瀏覽器，支援 HTML5/CSS3/WebGL 等最新標準的瀏覽器！ 如果你至今還是無法完全明白 Node.js 的能耐，期待與你見面交流。

最近比較忙，一直拖到現在，才有點時間上傳我在今年 JSDC 的簡報。這次，給的講題是『我編譯故我在：誰說 Node.js 程式不能編成 Binary』，主要探討怎麼使用 NPK 打包你寫的 Node.js 程式，以及把 JavaScript 程式碼編譯成二進位(Binary)檔，甚至是進一步的加密設計。NPK 雖然還只是初版，目前支援了三種博君一笑的封裝等級：卸妝(Remove mock-up)、媽媽不認識(Mom doesn't recognize)、爸爸不認識(Dad doesn't recognize)，有興趣了解這三種等級不同的人，可以參考我的簡報： 當然，參加這種活動需要的是熱血，不在 Lightening Talk 閃電秀登場一下怎麼可以呢？於是當天毫不考慮的搶了一個名額，用短短的五分鐘介紹 Mandice 團隊最近在做的 JavaScript OS - 『 Stem 』。在 Stem 的平台之下，無論你是否為嵌入式系統或作業系統的高手，只需要懂 JavaScript 和純粹的 Web 相關技術，你就可以開發自己的嵌入式應用，或讓你的舊電腦或開發板有全新的用途。 後記 大家都知道，做外包工作，一向很難累積東西，唯一能累積的，就是設計工具以加速自己做案子的速度。因此，Stem OS 就是我們經歷過許多的案子後，自己設計的平台，讓我們可以盡可能完全用 JavaScript 快速開發嵌入式系統，然後結合硬體開發設計各式應用。在 Stem 裡，只需要懂 JavaScript 和 Web 相關技術，就能勝任開發工作，實現你心中的 Idea。如果說 3D Printer 是可以讓你快速打造模型實體，那 Stem OS，就是能將你心中的 Idea，化為空硬體的靈魂，Idea 的 3D Printer。 這對創業者、創新者和非資訊產業的公司來說，都是一個可以快速切入設計產品和自家工具的機會，不妨嘗試看看。:-) 如果有任何需求，無論是顧問、教育訓練還是合作開發，都歡迎與我們 Mandice 聯絡，或來信到 fred@mandice.com。

OSDC.TW 2013 順利在中央研究院國際會議廳閉幕，但一如往年，失落感接踵而來。為了這次的 Talk，可說是花了不少工夫，除了研究 Webkit 的內部實作，以及 V8 JavaScript Engine 之外，最後也發表了一個新的 JavaScript 作業系統『 Stem 』，一個可以完全用 JavaScript 和 Web 技術去開發應用程式的嵌入式作業系統。Stem 落實了用 JavaScript 語言開發嵌入式系統的理想，並簡化嵌入式應用開發，讓人人都能輕鬆躍過以往嵌入式系統開發的艱澀門檻。 這邊釋出當天的簡報檔，有興趣者可自行參閱： 此外，對 Stem 有興趣的人，可以拜訪專案網站： http://stem.mandice.org/ 也可以在 IRC 上交流： 英文頻道：irc.freenode.net #stemos 中文頻道：irc.freenode.net #stemos-zh 註：目前 Stem 已釋出 x86 版本的安裝鏡像檔，近期內將會釋出 ARM 的版本，敬請期待。有興趣參與開發者，歡迎來信一同交流。

由於一些因素，被徵招去救火，在 JSDC.tw 2012 (JavaScript Developer Conference 2012) 給與了一場 Talk，由於準備時間相當緊迫，就把最近在研究和試驗的半成品匆匆拿上場展示和說明，題目是『Non-MVC Web Framework』。你可能在議程上沒有看到這場 Talk，實際上是因為主辦單位的一些小疏忽，議程上仍是寫著之前的舊題目『Build Node.js Module』，而且小弟的名字也打錯了，從 Fred 變成了 Frend，差一點就變成二十世紀少年的友民黨教主。:-) 本次議程其實和前幾天發的舊文『 前端工程師也可以淡定的開發網站應用！RedTea Web Framework！ 』息息相關，探討的是改善 MVC 的開發流程，和引入 JavaScript/Node.js 後的大膽嘗試，而且進一步討論實作細節。此外，因為 RedTea 本身只是一個實驗性的專案，目的只在於驗證可行性，還不到實際使用程度，所以藉著這次機會，公開並宣布新專案『 Kamalan Web Framework（葛瑪蘭） 』，Kamalan 引入了 Express Web Framework 為基礎，然後將結合 RedTea 的成果，並更進一步簡化其中細節和使用方法，讓前端工程師能真正無痛上手。 雖然還沒完全將 RedTea 的機制完全整合進 Kamalan，但目前 Kamalan 最少可以和 Express 一樣使用，你如果有用 Express 寫的程式，直接將 require() 引入的模組名改成 Kamalan 即可。由於 Kamalan 在根本上就是 Express，甚至是可以使用 Express 的所有 Middleware。 後記 這場 Talk 後，引起了一些 JavaScript Developer 趕的迴響，一些建議和聽眾的期待相當令人開心，討論過程也非常愉快。感謝大家的參與。:-)

還記得，尚未投入 Node.js 前，一直覺得 Node.js 帶來了未來，讓我們可以用 JavaScript 同時開發 Web 前端(Front-end)和後端(Back-end)，等到真的投入 Node.js 後，發現雖然事實的確是如此，但由於前端和後端應用所需要的背景知識不盡相同，開發模式和概念更是大異其趣，所以，雖然同樣是使用大家熟悉的 JavaScript 語言，但前端開發者仍然不見得能夠如願地來開發後端應用。 這樣的情況讓我想起有位來台灣工作的外國朋友，曾告訴過我一個多年前發生在他身上的笑話。故事是： 他原本是個美術方面的設計師，然後，但有一天老闆對他說：『你從現在起，去做開發程式的工作吧。』 他問：『為什麼？』 老闆回答：『寫程式是用英文寫，而你又會英文，不就可以寫嗎？』 是的，同樣道理，雖然對前端工程師而言，JavaScript 是最熟悉的程式語言，而 Node.js 又可以讓你使用 JavaScript 寫整個 Web 應用，但這不代表對這些人而言，就可以輕易上手 Web service 的後端開發。要真正讓前後端開發合而為一，不只是語言要統一，開發經驗也要相同才是，這才是所有 Web 開發者最期盼的事。 於是筆者基於 Node.js，開發了『 紅茶(RedTea) 』，這是一個和現有的網站框架(Web Framework)所不一樣的全新的嘗試。以前端開發者視角和經驗為出發點，專門設計給前端工程師上手使用的網站框架，讓前端工程師也可以『淡定』的開發網站應用。由於 RedTea 不是傳統 MVC 模型的 Framework（至於 RedTea 採用的是哪種開發模型，筆者一時也說不上來。），所以，如果你是一個已經被 MVC 涂毒已深的開發者，可能要先花點時間重新理解一下。:-) 此外，RedTea 有一個最大的特點，就是支援了在瀏覽器環境下，呼叫後端 JavaScript Class/Function 的功能，就像在使用本地端的 JavaScript 物件般。因此，前後台交換資料，不用再以 GET/POST、URL Path Routing 或 Ajax 相關的方法實作，只要學會怎麼使用 JavaScript Class 即可。重點是，即使你沒有任何 HTTP 通訊協定的知識，或後前後端資料處理的經驗，依然可以開發出網站程式。 ...

感謝各位捧場，上周六在『 OSDC.TW 2012 』所分享的『Let's Enjoy Node.js - All Development in JavaScript』，旨在介紹『 Node.js 』這新興的 Open Source 專案，我們可以預見，其將帶來軟體業相當重大的變革，並為 JavaScript 程式語言開拓了嶄新的局面。目前簡報檔釋出，歡迎各界取用和參閱。 自 2009 年 Node.js 公開發表以來，備受世界各地開發者囑目，在 2011 年 12 月更一度榮登 github 關注排行的第一位，超越了 Ruby on rails。Node.js 的出現意味著 JavaScript 語言從前端應用走進了 Server 的殿堂，除了效能表現不俗之外，使用其開發應用也相當迅速，未來 Web 開發者可以完全使用 JavaScript 語言打造網站服務，甚至是可大規模括展的雲端應用，堪稱 Web 開發者的夢想。 值得一提的是，Node.js 其實不僅限於 Web 應用，甚至可以用於各類系統程式開發，比較廣為人知的例子是 HP WebOS（前身是 Palm WebOS）。其採用了 Node.js ，做為系統服務的開發途徑之一。此外，Node.js 有模組化的設計，讓開發人員可以輕易使用各類其他語言(C/C++/Python... etc)為其擴充功能，彈性相當高，更讓 Node.js 不受限於任何開發領域。

我們在做 JavaScript 開發時，常會使用到類別(Class) 的設計方法，但事實上，JavaScript 根本沒有所謂的類別(Class) 概念，此功能完全是靠動態物件(Object) 所模擬出來。因此，在 JavaScript 中，有數種方法可以定義和設計我們自己的類別(Class) 。可是哪一種方法的效能比較好呢？這便是本文的主題。 為免空口白話，筆者在 jsperf.com 建立了一個 Test Case『 Prototype Operator Performance 』以便實驗，並邀請各方網友使用瀏覽器前來測試，比較使用和未使用 Prototype 兩種情況，以及不同寫法的速度。（若你有興趣幫忙做實驗，進入該網站後， 請點選 Run Tests 開始測試） 註：在測試過程中，請確定你的瀏覽器，沒去跑其他的吃重的網頁，以確保實驗結果的準確性。 你可以在該網站上，觀察其他網友們的測試結果。但是，由於本次目的，主要測試的是同一種 JavaScript 引擎，處理不同建構方法的速度，所以，大家只要專注於在同一個瀏覽器下，其測試結果就可以。不同電腦，不同系統和不同瀏覽器的速度，並不是我們這次比較的重點。此外，因為 Node.js 使用的是 V8 JavaScript Engine，在本文中主要會拿 Chrome （因為 Chrome 使用的是 V8 JavaScript Engine）的結果討論。 這個測試有兩組實驗，第一組是測試呼叫類別(Class) 中方法(Method) 的速度，我們分別測試三種，用不同方法建構出來的類別(Class)： 未使用原型(Prototype)，直接在 Constructor 內定義 方法(Method) A = function() { this.message = function(s) { var msg = s + ''; }; this.addition = function(i, j) { return (i * 2 + j * 2) / 2; }; }; A_instance = new A(); A_instance.message('Hi'); A_instance.addition(i, 2); 使用原型(Prototype...

Node.js 實作了一個內建的模組『cluster』，目的在於提供開發者一個容易的方式，針對多核心機器進行支援。可惜的是，截至今天 Node.js v0.6.14 版本，『cluster』功能還是不夠完整，從官方文件上可以得知，其 API 仍處於實驗(Experimental)階段，在日後會有極大的變動(Drastic changes in future versions)。 而就 git repository 上最新的 Node.js 開發版本來看，『cluster』模組已經大幅度更改，也從簡單的 function call 變成了物件的設計。所以，目前非常不建議在自家產品中大量使用 『cluster』，至少短期內，他都不是穩定可用的，會有很大的改動空間。 不過，你如果是要實作 Web Service，會想要使用『cluster』的目的就顯而易見：『透過多個 Process 分擔流量和工作量』。若只是單單要做到這一點，我們可以自己來實作。 通常我們有兩種方式達成這個需求： 反向代理(Reverse Proxy) 技術 使用多個程序(Process) 監聽並處理同一個 Port 前者的做法，是建立一個常駐程式或機器，統一處理所有連線的需求，然後將這些連線做流量平衡(Load Balance)，轉送並分配給後端多個程序或機器處理，待處理完成後，再將後端的回應送回給使用者。這樣的 Proxy 機制，你可以用已經相當成熟的解決方案達成，像是 Nginx 或 Apache。亦或是自己使用 Node.js 撰寫，但由於這不是本文的重點，日後再來討論這個實作的細節。 而後者，使用多個程序(Process) 監聽並處理同一個 Port，是本文的主題，也是『cluster』模組正在做的事。如果你有看過『cluster』的程式碼，就會發現它其實主要運用了兩個技術：『取得 net._handle』和『利用 process.send() 傳送 Handle 給子行程(child process)』。 知道了關鍵後，實作上就不是什麼大問題，主要流程是： 運用『net』建立一個 Server，目的在於監聽(listen) 80 Port 建立多個子行程(child process) 準備處理連線 將『net』的內建 Handle 傳給子行...

繼前文『 不靠別人！親手佈建自家的雲端服務平台 AppHouse 』所提到，我們以當今主流的雲端平台的佈建習慣為參考，開發了一個自己的 Hosting Platform，做為投入雲端產業的基礎建設。雖然與許多雲端業界的老前輩（如：Google、Amazon 等等）比起來，仍然不夠看，但研發仍逐步朝完整的解決方案前進。 在使用『 AppHouse 』時發現，網站應用程式的佈建雖然相當快速，但若是要直接在 AppHouse 上開發應用程式，會有相當多的麻煩，也不夠便捷。於是，撰寫並釋出了一套圖型化的管理程式『 AppHouse-Manager 』，用來管理 AppHouse 上所有的應用程式(Application)。 目前提供了功能，可以重啟特定的應用程式，讓開發者可以在撰寫和測試服務時，依自己的需要重新啟動自己的程式。 也實作了即時監控 Console ，我們可以透過瀏覽器即時偵錯(Debug)。 目前 AppHouse-Manager 還相當不足，只能說堪用而已，並還有許多欠缺改進的地方。不過，已經足夠讓工程師在 AppHouse 上進行開發工作。

和我比較熟的人，最近應該都知道，目前我專注於 JavaScript 和 Google V8 engine 的相關研究上，甚至決定從今年開始，公司營運以及技術團隊的方向，是企圖提供『最專業的 Node.js 和 JavaScript 相關服務』。（所以，如果您有需要，請聯絡我們 :-) ）我非常清楚知道，有些人聽到 JavaScript 就歡天喜地，而有些人則不將他當一回事。更有多到數不清的技術人員，熟悉並使用 JavaScript 非常多年，聽到我說要提供『最專業的 JavaScript 相關服務』，會不屑一顧甚至以為我在瘋言瘋語。不過，如果你願意聽，接下來我會說明這是怎麼樣的瘋狂服務。 我不能阻止你對 JavaScript 有預設立場，因為這是無奈的歷史包袱，但請暫時放下過去成見，聽我靡靡道來。 我所遭遇的矛盾 過去，絕大多數人都只將 JavaScript 視為 Web 開發的一環，在大家的印象和認知中，JavaScript 充其量只是一個在瀏覽器中控制著 HTML DOM 的腳本語言。雖然近年來出現了 Node.js，過去微軟也支援使用者使用 JavaScript 撰寫 ASP 和系統腳本程式，但也不改這樣的看法：『JavaScript 是身處於末端的語言，與網頁、網站密不可分的東西』。所以，對許多硬底子的企業和研發人員來說，JavaScript 象徵了 Web/HTML 與不彰的效能，一種幻想的存在；而對很多 Web 開發者和前端工程師來說，JavaScript 卻是一種當今資訊產業的萬靈丹。如此天差地遠的矛盾，一直存在於這個產業界。 曾經當過 Web 開發者一段不少的時間，我承認也理解，使用 Web 技術來實作各類使用者界面(User Interface)和資料庫應用，非常容易和快速，不用考慮到太多的事。這一切要歸功於 JavaScript 和 HTML 的合作無間。所以，不時能聽到一些 Web 開發者，嘲笑作業系統程式開發者和嵌入式裝置的技術人員的辛苦，認為許多功能和特效，使用 Web 技術一下就達成了。 由於我過去也是『慣C』一族，做過很多包羅萬象的硬碰硬開發，小從一般電腦到嵌入式裝置、桌面系統到手機平版，大到各類特殊需求的系統研發，都有所涉獵。所以，對於系統資源和效能，一直有著莫明...

這是創業者的心聲，我們永遠為了為數不多的錢，拼老命和客戶周旋。在客戶面前包到好包到腳，扛的責任何其多，回來後又當業務又當 PM 還要當 R&D，最後還得當會計，數不盡的心酸誰知道。沒辦法，對我們來說，現金流（CashFlow）比什麼都還重要，能不能挺過這個月或下個月，維持周轉才是首要任務，為此，任何苦我們也得吃下。 筆者做了幾年的 Outsourcing，雖然不是當初創業的核心目標，但為了養家活口，接案卻成了主要業務。不過，筆者確實也因接案而活了下來並壯大團隊，能夠有機會持續朝理想發展。接案的過程中，風風雨雨自然不在話下，但慶幸受到前輩和朋友間的提攜，近來也總算是開始有個根基，剛好穩住腳。 接案就是這樣，有一頓沒一頓，如果要穩定收入，案子的價與量就必需相應提高，這是所有以接案當食糧的創業者，所都要經歷的過程。但是，往往在提升價和量後，案子開始會吃掉團隊的全部時間，漸漸失去當初創業的核心目標。然後，進入了『招人力』後『招案子』再『招更多人力』後『招更多案子』的惡性輪迴中，最終你會想：『辛苦到快暴斃，工時責任換算下來，賺得比去上班來得少，那我何必創業？』。如果你有同感，不用灰心，因為現在有無數的創業團隊和創業者， 也都正面對著同樣問題，甚至面臨崩潰。 有鑑於此，筆者尋思，何不與大家分享自己的經營成果，讓大家各自都能得到更多時間經營自己的核心目標？創業者、SOHO族和個人接案者所需要的源源不絕的食糧，不必各自重新發展重新耕耘，只需要從筆者這接手過去即可。由於舊有團隊原本已經有業務和PM的佈署，大家也可專注於技術性的工作，並提供如自來水般的技術供應即可。 對筆者來說，自己的核心技術團隊得以鬆口氣， 能慢慢以階段性放下養活自己的短期目標，有更多時間朝自己原本創業的核心目標前進。另一方面，也能給予其他創業者、SOHO族和個人接案者穩定的收入支持，不必重蹈覆徹筆者同樣的道路。如此雙贏的局面，樂見其成。 所以，如果你們是有技術的創業者或創業團隊，SOHO族或個人接案者，趕緊來報到吧！ 後記 無論你是專精或有經驗於哪一領域（Web、Linux、Android System（Integration/Porting）、Android App、iOS App 或 Embedded System... etc），都歡迎來信，最少先交個朋友也是不錯的。:-)