Fred's blog

從電腦、資訊科技開始普及後，每過一段時間，企業界就會開始出現新的 IT 轉型計畫，以整頓整個資訊系統、商業運行模式，然後試圖找出下一個世代的新方向。每一個具規模的企業，都生怕與新世代的技術和商業模式脫鉤，於是砸重金、拚人力，說什麼也要追上世界的腳步。當然，中間的技術供應鏈也不斷在改變，上一世代的王者或是贏家，在下一個世代可能不一定跟得上，因此身為終端用戶的企業，每當面臨新的 IT 轉型計畫，往往也跟無頭蒼蠅般， 不知所措甚至不小心會做錯了決定。 回到十幾二十年前，你也許可以有機會一次性把一個大系統整個替換掉。但在今天資訊系統高度介入管理的時代，版本更迭無數次的平台，沒有一個系統能在一夕之間被整個換掉，哪怕你的品管和測試做得非常足夠，甚至是超標達成，也哪怕你事先的需求訪談談到祖宗十八代都瞭然於心。 這常常是系統設計者和規劃者的誤區，看見許多表面問題，於是設計了一套全新、看起來完美的解決方案。而剩下沒照顧到的部分，都覺得只要能配合測試就可以邊走邊補足。事實上，現代資訊系統的維度和複雜度，已經超出人類的想像，太多的例外、不可控、溝通執行問題，遠遠超過理論上的執行方法。 所以從系統規劃設計的角度來看，我們總是要慢慢來，一段段改善、替換，最終達成全面換血。而且越是龐大複雜且重要的系統，越要切割得越細，透過降維度的方法，來慢慢替換。所以我們在討論IT轉型，從一個肥大的系統換到另一個肥大的系統，已經不會是選項，系統架構的去耦合、高擴展性甚至是服務不中斷才是考量的重點。 這也是為什麼「微服務架構」在近年來特別熱門，微服務真正在討論的不是容器化，而是在討論的是怎麼讓一個龐大的系統，更容易受到管控、維護和擴充，除了可以更容易實現災難隔離、例外狀況、整體高可用性，也可以更有彈性做各種變化。 更重要的是，微服務架構下，其系統風險管理上，從在開發階段開始，每個部分就已經受到隔離和管控。也由於每個被拆解後的系統都非常小，遵循 SRP 原則，在開發維護上相對容易，也可以保證每個單元有更低的問題發生率。至少，你不會因為一顆螺絲或換一顆螺絲，導致整個塔倒塌。 不過微服務架構卻也不是說要做就能做，對於規劃設計者來說，他必須很了解各種新舊技術議題、有能力做實務執行面的評估，也需要耐心做各種服務拆解梳理和引入正確的 Pattern 及技術，甚至很多時候要有走一步是一步且可以快速反應...

JavaScript async/await 的奇淫技巧 話說，最新的 ECMAScript 已經引入了 async/await 語法，讓開發者可以更容易控制非同步的程式邏輯，換言之，我們可以減少許多 callback 的使用，讓 JavaScript 這種單線程、事件驅動的程式語言更易讀、好寫。 關於 async/await 的基礎使用，有興趣的人可以參考舊文「 JavaScript 好用的 async 異步函數！ 」，而本文將探討更多實際使用上的小技巧。 另外，瀏覽器不一定有支援 async/await，你可以在新版的 Node.js 上面測試本文的內容。 呼叫 async 函數與一般的函數沒有差別 想像一下，async 函數就是一個在執行後會回傳 Promise 物件的「普通函數」，和一般常見的函數的使用差異，僅僅只是 async 函數在執行後「不是回傳函數執行結果」。這代表我們可以把 async 函數當作一般函數來呼叫使用，用法一模一樣。 async/await 與 Promise 是可以共通的 非常有趣，async 函數與 Promise 其實能夠共通，這代表我們可以玩一些特別的組合技。所以，若要把 async/await 玩得通透，建議你盡量熟悉 Promise 的各種用法。 實現 delay 函數 過去因為單線程和事件驅動的關係，JavaScript 不可能實現一個沒有嚴重副作用的 delay 函數，所以取而代之的是使用 setTimeout() 加上 callback 來實現「一定時間後執行什麼工作」的需要。 不過來到 async/await 的世界後，我們可以一行行描述程式邏輯，無論是不是同步（Synchronous）的程式碼，所以我們可以用 Promise 來包裝 setTimeout() ，以實現一個在 async 函數裡可以跑的 delay 函數： // 實現一個等待函數 const delay = (interval) => { return new Promise((resolve) => { setTimeout(resolve, interval); }); }; const main = async () => { ...

ECMAScript 6 開始，規範中出現了一項被稱為「尾呼叫優化（Tail Call Optimization, TCO）」的優化技術，這讓開發者可以在函數的執行過程中，減少 Stack Frame 的數量，進而提升效能。TCO 尤其是在遞迴這種不停呼叫自己或新函數的工作上，能得到最大的優化效益，能提升遞迴的執行效能如同迴圈一樣。 只不過很可惜的是，截至本文發稿前，大多數瀏覽器及 JavaScript 引擎尚未支援這項技術。但我們還是可以自幹並模擬一個 TCO 的行為，雖然比起語言本身、編譯器（Compiler）及虛擬機（VM）層面的實現，效果差了些，但仍然可以減少 Stack Frame 的數量避免達到 Stack Frame 的數量上限。 什麼時候會啟用尾呼叫優化機制？ 如果 JavaScript 引擎有支援，通常一個函數執行到最後一行 return 時，是回傳另一個函數的執行結果，就會啟用 TCO 機制，如： const f = () => { return 999; }; const g = () => { // 執行並直接回傳 f 函數的執行結果：會啟用尾呼叫優化機制 return f(); }; g(); 但要注意的是，回傳的「必定為函數的直接回傳值」，所以下面這些寫法不會啟用 TCO 機制： // 不會啟用 TCO 機制的設計 const g = () => { return f() + 1; }; // 不會啟用 TCO 機制的設計 const g = () => { let ret = f(); return ret; }; 創造一個跑不完的函數 首先我們先創造一個肯定跑不完的遞迴，然後改善它： const func = (x) => { // 讓他跑 10000000 次 if (x === 10000000) return x; return func(x + 1); }; let ret = func(0); 理論上，如果你直接執行上述程式碼，會得到 stack size 超過上限的錯誤訊息： RangeError: Maximum call stack size exce...

函數式程式設計（Functional Programming）是近年來越來越被軟體開發者常提及的話題，許多人討論它時，不外乎說其就是在程式設計中引入了數學方法，彷彿有神奇又高深的理論加持一般。事實上，對於一般開發者而言，函數式程式設計比較通俗且直接的好處，就是讓開發者可以在「函數」的層面和維度，進行邏輯或是效能上的優化。所以說，比起命令化的執行程式、管理物件，怎麼去設計和管理函數這件事，就是函數式程式設計所關心的重點。 JavaScript 這語言在設計上，天生就支援 first-class function，這代表函數在 JavaScript 是一種資料型態，可以被當成普通物件傳遞、處理，這讓開發者在使用 JavaScript 時可以時不時引入 Functional Programming 的技巧和概念。 本文將介紹 Functional Programming 中大量被使用的 Memoization 機制，然後我們如何在 JavaScript 中引入並實地使用它，無論你會不會 Functional Programming，這都是一個可以常用於日常開發中的優化技巧。 Memoization 是什麼？ 用一般程式開發的說法就是快取（Cache）機制，只不過 Memoization 是針對「函數」進行快取。快取的好處在於我們只要執行過一次工作後，之後在執行相同工作前，就能提前知道執行結果為何，所以我們可以不用「真正的」去執行工作，而直接取用執行結果就好，可大量提升程式執行的效能。 同樣快取概念套用在函數上，若我們給予特定「輸入（Input）」到一個函數中，而該函數會回傳一個特定的「輸出（Output）」，理論上函數執行一次後，下次再使用這個函數時，只要「輸入」和過去一樣，我們就能提前知道結果。 而這樣對函數進行的快取機制，就是所謂的 Memoization。 只能使用在純函數 你可能會聽一些人說，只有「純函數」才能引入快取機制，然後開始討論數學上所謂函數的定義，然後你就聽到昏了，後面在講什麼你就都聽不進去了。 但如果撇除函數的數學定義，若白話來說，能被快取的東西，就是能被預測的東西，這代表函數的執行結果也要能被預測，也就是一樣的輸入值，就會有一樣的輸出結果。 所以，如果一個函數每次執行，代入的輸入值一樣，但回傳結果卻是可能不一樣，這...

「 Protocol Buffers (protobuf) 」是一套 Google 所提出的結構化資料的包裝技術，讓資料便於網路傳輸或交換，如同常見的 JSON 和 XML 等技術一般。但相對於其他常見技術，protobuf 設計上更易於用來包裝二進位資料，應用在串流（Streaming）技術上，在資料包裝上也更為節省空間，在包裝或解析上也更有效率。 註一：若採用 JSON，由於原本的設計上並無法處理二進位資料，所以如果要包裝二進位資料，傳統做法會將資料轉換成 base64 的格式，再以字串（String）的格式儲存。因為這等於二次包裝資料，導致處理上非常沒有效率。 註二：與 Google Protocol Buffers 類似的技術還有 MessagePack 及 Facebook 採用的 Apache Thrift，有興趣的人可以自行參考比較。 跨語言的優點 另外，Protocol Buffers 最大的優點，就是擁有跨程式語言的設計，提供了一個標準通用的 .proto 定義方法，讓我們定義資料結構和格式。只需要載入這些我們事先準備好的資料定義，就可以輕易生成給不同語言（如：C++、C#、Go、Java、Objective-C 或 Python）用的資料解析器、包裝方法，讓我們可以在不同的語言之間，解析或包裝相同的結構資料。 Protocol Buffers 的使用場景？ 若在純粹的 Web 應用下，大多數情況，我們不需要處理二進位資料，或是需要非常精準的資料格式，也不會進行單筆高流量的資料交換，所以使用 JSON 或 XML 已經足以。但若你的應用有串流、二進位資料的需求，Protocol Buffers 就是你可以考慮的選擇。 像是筆者在一些公司專案中，會運用 Message Queuing 進行各種訊息資料傳遞，以達成各種資料處理需求。但由於訊息資料內可能有大大小小等各種資料形式和資料型態需求，導致 JSON 包裝已經完全不敷使用，甚至有效能上的疑慮，這時就會採用 Prorocol Buffers 來打包資料。 安裝 ProtoBuf.js Google 官方其實並沒有實作 JavaScript 版本的 Protocol Buffers 支援，但還好廣大的社群已經有高手開發出 JavaScript 的模組「...

先聲明，async 異步函數是 ECMAScript 第七版（ES7）才被支援的語法和特性，目前 ES7 還沒有被大多數的 JavaScript Engine 所實作，如果你要使用，需要用到 babel 這類工具，先把此程式編譯轉換，讓其可在舊版本 JavaScript Engine 上執行。 如果你覺得以 co 模組來操作 Generator 很好用，你可以想像 async 異步函數就是原生的 co，幾乎是同樣的使用方式，同樣的使用概念，只不過不再需要使用 generator 和 yield 這類語法。如果你是個過不了在函數上有個醜陋「*」符號這一關的人，async 異步函數的使用方式應該會讓你感覺到舒服許多。 什麼是 async 異步函數（async functions）？ 異步函數使用方式其實和一般的函數一樣，只不過在這函數之內的程式，可以用 await 的語法去執行並等待異步工作（如：Promise）而不需要使用到骯髒的 callback function。宣告並使用一個 async 異步函數，就是在定義函數時加上「async」，然後直接執行這個函數即可，簡單的範例如下： async function myAsyncFunc() { console.log('Hello async functions!'); } myAsyncFunc(); 搭配 Promise 的使用 Promise 通常被大量用來管理非同步的工作，並讓開發者容易管理錯誤拋出等機制，一個典型的 Promise 使用如下： var task = new Promise(function(resolve, reject) { // 執行一個非同步的工作，完成後呼叫帶入的 callback doAsyncTask(function(err) { // 有問題呼叫 reject，並帶入錯誤值 if (err) return reject(err); // 成功呼叫 resolve 並帶入回傳值 resolve('VALUE'); }); }); // 使用 then 去執行並等待工作完成，成功會呼叫 callba...

身為 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 ...

經過幾個月努力，新書『 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 模組參考手冊 』做比對參考，因為裡面有雷同的章節，可以使用新書的方法來取代舊書老舊的部份。 至於舊書翻版，我們已...

自從 Node.js v0.11 版之後，內建的 V8 引擎被更新了，於是 JavaScript 引擎的原生 API 大幅度改變，導致很多以 C/C++ 所撰寫的原生模組紛紛出現相容性問題。影響範圍包括了前陣子發佈的 Node.js v0.12 以及 io.js 1.0+，因為都使用了新版的 V8 JavaScript Engine，而有同樣的問題。 其實這樣的問題已經不是新鮮事，自從 Node.js v0.8 到 v0.10 就開始有些許不相容的問題，只是到了 v0.12 和 io.js 之後，出現了更多狀況。因此 Node.js 圈子內的知名開發者 Rod Vagg  建立了 NAN 專案，用來解決這樣 Native API 不相容的問題。 NAN 全名為 Native Abstractions for Node.js，目標是設計一系列通用 API 供 Native Add-on 開發者所使用，讓開發者可以使用這通用的 API，一次性開發出支援 v0.8、v0.10、v0.12 和 io.js 1.0+ 的原生模組，不必再為 V8 原生 API 相容性所苦。 若想要使用 NAN，可以直接以 NPM 下載： $ npm install nan 然後在 binding.gyp 中加入 include_dirs 的屬性設定，讓 Node.js 或 io.js 引入 NAN 模組： 'include_dirs': [     "<!(node -e \"require('nan')\")" ] 經過這樣的設定配置後，我們就可以在 C/C++ 程式裡面引入 NAN 的標頭檔，開始使用 NAN 的 API： #include <nan.h> NAN_METHOD(Hello) {     NanScope();     NanReturnUndefined();     // 或是這樣寫 NanReturnValue(Undefined()); } 上面的程式碼，代換成舊的版本（v0.8、v0.10），就等同於： Handle<Value> Hello(const Arguments& args) {...

io.js 不做任何設定下，預設支援了一些 ECMAScript 6 的語法，其中包括一系列的 Collection 支援，這讓 JavaScript 在資料操作上多了一些方便之處。本文將討論到的 Set 物件，就是其中一個 Collection 類別。 簡單來說，Set 是一個類似 Array 的物件型態，可以用於處理有序的資料，而且內建迭代器（Iterator：在某些應用上同樣功能也會稱之游標 Cursor），讓開發者可以很容易對資料進行一筆筆的處理。 基本操作 基本的 Set 物件使用很簡單，如下所示： // 建立一個新的 Set var items = new Set(); // 依序加入資料 items.add('Fred'); items.add('Stacy'); items.add('Wesley'); items.add('Rance'); items.add('Kevin'); items.add('Alex'); // 依序印出 Set 物件內的所有資料 for (var item of items) {     console.log(item); } 比較特別的是，如果要依序印出 Set 物件內的所有資料，需要使用『of』這個關鍵字。原因是 Set 物件本身是一個 Generator 實作所致，如果我們想要一次把 Generator 內的工作跑完，需要運用 for-loop 加上 of 關鍵字來達成。 註：關於 Generator 與 of 關鍵字，日後有空再撰文說明其細節。總之，只要記得必須使用 of 關鍵字才能一一讀取 Set 物件內的資料，就像 Array 的 for-loop 加上 in 關鍵字。 刪除資料 刪除特定資料可以使用 remove() 方法來達成，如下所示： items.remove('Wesley'); 若是要清空資料，可以使用 clear() 方法： items.clear(); 檢查資料是否存在 我們可以直接利用 has() 方法檢查特定資料是否存在： items.has('Rance'); 迭代器（Iterator）的使用 Set 的迭代器是圍繞著 Generato...

io.js 最大的特色，就是採用了最新的 V8 ，而且直接支援了 ECMAScript 6 的語法和特性，其中一項就是文字範本（Template Literals）的支援。這代表我們可以很容易在字串中代入其他的變數內容，就像一般的 Shell Script 一般，不必再像從前的方式，使用串接字串的方式達成。 如果想要使用這樣的文字範本（Template Literals），可以直接使用 ${} 來代入其他變數，然後以『`』字元將字串包起來，然後就可以將指定的變數內容代入到字串中： var name = 'Fred'; var stringTemplate = `Hi, I am ${name}!`; console.log(stringTemplate); 接著，如果你使用 io.js 來執行，就可以得到下列結果： Hi, I am Fred!

如果你有關注這兩個月 Node.js 的發展，就會發現一些大變動，尤其在最近半路殺出了一個名為 io.js 的 Application Framework，其來勢洶洶朝著 Node.js 而來。於是，很多人看糊塗了，開始搞不清楚兩者的關係，甚至以為他是一個全新的技術。事實上，一切緣由皆由 Node.js 而起，這是起圈內的八卦事件，當然，我們也可以將其看作是社群對把持開放原始碼專案的商業團體，進行的抗議行動。 io.js 的官方網站： https://iojs.org 由於 Node.js 的發展日益興旺，掌握著 Node.js 的發展進度就代表掌握著利益，所以 Joyent 開始掌控著 Node.js 的開發進度。縱使 Node.js 有著開放原始碼社群，也有著許多貢獻者，但新版本的釋出一直受到 Joyent 的掌控，最讓社群不滿的是 v0.10 版之後，已經快兩年沒有發佈新的穩定版本。這意味著，無論社群絞盡腦汁去協助開發 Node.js，成果永遠無法面市，也意味著大家所期待的 ECMAScript 6，遲遲無法在 Node.js 上被支援。 終於，社群等不下去了，在 2014 年底發起新的計劃 io.js ，試圖 fork 原本的 Node.js 專案，目標是如果 Joyent 遲遲不發佈 v0.12 版的 Node.js，就打算自己動手。這個 io.js 的新專案，緊鑼密鼓的展開，吸引了許多開發者的關注及加入，不到兩個月的時間，在 2015 年 1 月中推出了 io.js v1.0.0 的版本，並且打算加緊步調，讓開發與發布週期更為密集。 其實，我們可以將 io.js 的 v1.0 版視為 Node.js v0.12 版，它們本質上是一樣的東西，所以 io.js 也可以支援 NPM，有著一樣的使用方式、API 和架構設計，更相容於 Node.js v0.11 及未來的 v0.12。這代表，原本以 Node.js 所開發的應用程式，理論上都可以正常以 io.js 執行。 至於未來 io.js 是否會將 Node.js 取代呢？我們拭目以待。

寫書寫到通訊協定一章，就想起今年來台灣 JSDC 的 Mathias，在台上展示以 Node.js 開發的 Bittorrent 影片下載工具『peerflix』，該工具可以結合 vlc、mplayer 這類的播放器進行 BT 種子的影片播放，相當有趣。此外，他亦展示了使用 VirtualBox 直接開 BT 上的 Ubuntu 安裝ISO 檔的實作。 很多人都說很神、很有趣，但看完後不見得會去了解實作細節。有些人更覺得這是他們無法碰觸的領域，只是當一個神在展示他的神力而已。這樣的情況，讓我感到難過，因為很多這樣的技術細節並不難，除了 bittorrent 本身的演算法本身的實作，或是開發其 Binding 是有困難度之外，其餘的東西根本上都是相當簡單的概念。 我想，這樣並不困難的東西，如果不去解析或了解它，實在是可惜了 JavaScript 至今的發展。 事實上， bittorrent client 的 binding 早有人開發出來並寫成模組。我們只需要使用種子檔案或是 magnet link，就可以透過 binding 去取得檔案資料，甚至是特定段落的資料，就像我們實作 HTTP 續傳那樣簡單，只需指定資料的開始處而已，全都有現成的 API 可使用。 若要播放這些影片內容，只需要建立一個 HTTP Server，再將從 bittorrent 下載完成的影片資料檔，運用 Stream 的技巧導向 HTTP 輸出即可。實作到此，我們就可以透過支援 HTML5 Video 的瀏覽器或是其他支援串流的多媒體播放器，以 HTTP URL 打開影片觀看。 至於 VirtualBox 怎麼去開啟 bittorrent 上的 ISO 檔，然後讀到哪載到哪的技術，其實也不是非常難，運用 Linux/BSD(Mac OS) 上的 FUSE（Filesystem in Userspace）的技術即可達成。雖然這是熟悉系統開發才會知道的技術，但概念與開發上其實並不難，尤其是也有人寫了 Node.js binding，我們可以完全使用 JavaScript 輕易實作。 簡單來說，使用 FUSE，可以讓我們不必觸碰到作業系統核心的驅動程式技術，就可以開發一個自己的檔案系統。然後，我們可以把自己實作的檔案系統掛載到一個本機目錄上。這代表...

很開心，這次十二月的『 Hackathon Taiwan 』相當多人參與，百人的報到數讓所有工作人員都感到興奮。最重要的，多虧了活動夥伴的遊戲設計，這次讓很多隻身而來的人，化解尷尬、相互認識並熱絡起來，最後順利組成隊伍，這算是種格外特別的創舉，過去很少有黑客松能做到這樣的地步。 有趣的是，這次活動找來了重量級的神秘講師 Jeremy Lu （對，就是那位最近紅極一時的 React.js 講者）開課，讓聽眾大飽耳福，絕對不枉來這一趟。有很多人也衝著 Qt 的課程而來，學習 QML 這樣先進的 UI 技術，這次的 QML 遊戲開發課程，相信讓很多人也開心地學會很多技術。 小弟在第二天的結尾，也給了篇一小時的分享『Koa 正在等一個人』，其內容在探討並帶領上手 Koa 這個下一代的網站框架、ECMAScript 6 Generator，以及 Node.js 和 io.js 的最新動態。（事實上是把最近將要出的書，擷取片段內容出來分享） 後記 對於我而言，活動內容再豐富，都比不上找到了好隊友可以一起創作。這次活動，得到了一個硬體工程師加入我們的團隊，所以可以開始進行硬體設計及控制等工作，而且大家相約了下次一起再來。下次，我們將會開始進行各種智慧家電的控制，以及 IoT 的相關應用。看來，我們只差一個設計師的加入了！如果你有興趣，快來加入我們！:-D 下次黑客松活動預計將於 2015 年 1/31、2/1（六、日）兩天，無論你是軟體開發者、硬體開發者、設計師還是學生，都歡迎來參加！而且，一樣會有神秘講師！

在國內，很多人或許對 Qt 很陌生，但這一直是筆者近年來想要推廣的技術，尤其是 QML 這個自 Qt Project 衍生出來的新 UI 技術，更讓人著迷。具有原生效能和擁有炫麗效果的 QML ，確實是一個打造產品的好東西，如大家近來所聽到的 Tesla 汽車、Jolla 手機等，其 UI 就是使用 QML 所開發。當然，之前舊文章中所展示的 UI 和介面，以及能跑在 Android 手機上的 OwaNEXT，也有不少是結合 QML 技術所開發。 推廣過程中總有人質疑，覺得 QML 不是一個設計師能學會的東西。事實上，它的語法相當簡單且模組化，所以也聽聞一些國外的設計公司，其設計師都直接用 QML 做出 UI ，再交給工程師去接上功能。這也是為什麼 HanGee 國民機在開發手機和各種裝置的 UI 時，要選用 QML 為底層的原因了。 因此，筆者自己的公司最近也在籌備許多課程和分享，也與許多朋友成立了一些社群（你可以在 Facebook 加入我們的 Qt @ Taiwan 社群），並設計開發一些相關的工具，以協助更多人能更快速進入到 QML 的世界。不過，因為 UI 與設計師更密切相關，近期應該會針對不懂技術的設計師，推出許多相關的 UI 開發課程。（如果你對這樣的技術有興趣，歡迎與我們聯絡） 其實，這次的黑客松活動與 HanGee 社群合作開設 QML 課程就是一個嘗試，也想收集一些 Qt/QML 初入門者狀況和資料。其中發現一個最大的問題是，無論是技術還非技術人員（如設計師），在安裝 Qt 時就會碰到各種狀況，而且 Qt 開發環境因為功能繁複且龐大，安裝一整套下來要花上不少時間，在學習上也就是一個阻礙。這對技術人員來說，可能不是什麼大問題，但這對設計師來說，就是一個極大的挫折。 因此，我們、講師和 HanGee 社群合作，開發了一個新的工具『OwaViewer』。原本這個工具只是被設計來開發 HanGee 手機介面，但現在可以用來讀取和執行一般的 QML 檔案。這意味著，你再也不需要安裝 Qt 和學習一堆知識，就可以使用 QML 開發使用者介面了，也可以很容易提供一個成果給客戶直接操作，這對許多設計師來說應該是個好消息。 OwaViewer 是個 Open Source Proje...

熱血的開發馬拉松活動（Hackathon）來囉！讓我們吃吃喝喝、不眠不休地設計應用吧！一群素不相識的設計人，無論是程式設計師、視覺設計師、UI/UX設計師，還是任何一種從事『設計』和『開發』工作的人們，在短短有限的時間內組隊並相互合作，一起投入設計同一個專案，與不同隊伍相互較勁！ 這次萌點、DOITT 和 HanGee 合作，將於 9/20 - 9/21 兩天，聯合舉辦 80 人不中斷黑客松活動，熱血的朋友們，快來報名並幫忙宣傳吧！如果你願意贊助，也歡迎聯絡！ 報名網址： http://han-gee.kktix.cc/events/hangeehackathon201409 讓我們回歸原點，什麼是黑客松呢？ 由於這幾年國內舉辦過很多大大小小的黑客松活動，大多數人對於黑客松早就耳熟能詳。不過，除了由技術背景的單位和社群自發性舉辦的活動外，許多黑客松活動，比較像是純粹的比賽，讓許多團隊來展示自己研發已久的專案或產品，慢慢脫離了開發馬拉松的原意。所以，因此不免也有許多人對黑客松產生誤解，覺得就只是個普通的比賽活動。 事實上，和時下流行的路跑活動一樣，黑客松並也不是個普通的比賽活動，而是一個讓設計人在閒暇時間，參與的開發運動。解放自己，做自己想做的設計和開發，挑戰自己，在有限時間內做出東西來，才是黑客松活動的原始目的。 我能參加嗎？ 對開放社群的朋友們來說，『黑客松』已經是一個再熟悉不過的名詞了，但對普通人來說，只要看到『黑客』兩個字，就覺得是一個敬而遠之的東西。不只如此，很多技術人員和設計師也對這活動有所誤解，覺得一定要非常有實力才能參加黑客松活動。 其實，黑客松和路跑活動一樣，並非只有專業選手才能參加。只要你有興趣、想實際參與多人設計和開發，無論你是學生、普通程式人員、還是新手設計師、初級自造者，都歡迎帶著學習、共樂的心前來參加！ 你可以來找人一起完成自己天馬行空的想法，也可以和別人一起完成其他人的鬼點子，亦或是在這找到同伴共同想出新點子！ 我能得到什麼？ 在這活動中，參加者將帶著愉快的心情前來，一邊吃吃喝喝交朋友，一邊與從未合作過的朋友和高手們組隊，做出作品！然後你會發現，因為只有短短的一兩天，大家將使出混身解數，在短時間內做出出乎意料的驚人成果。最重要的是，也能從其他高手身上學會不少東西！兩天所獲得的東西，絕對物超所值！ ...

還記得前陣子，就在書將出版之際，半路殺出來最新的 Express 4，使得筆者手忙腳亂，緊急通知出版社修改書的內容。將所有使用到 Express 的範例，都特別加上版本號的指定，讓讀者在照著範例做時，能夠使用舊的 Express 3.0，而不會發生任何問題。最新的 Express 4 雖然效能提升不少，也有一些好用的新東西，但和舊版有些微 API 的不相容，此外，也因為是新東西，可能很多東西的支援會發生問題，如果舊版本在上線的產品中運行相當穩定，建議先不要急著升級。 Express 4 做了一些改進，有不少新東西，其中相當值得提的一項就是路由機制（Router）的翻新。如果你以前在使用 Node.js + Express 開發網站服務時，因為 Router 很難管理而痛苦不已，這將是一個你會愛上的功能改進。 傳統的使用方法 傳統的 Router 設定方法依然可以運作，我們可以放心使用。 var express = require('express'); // Create express application var app = express(); // Apply this router on (/apis/user) app.get('/', function(req, res) {     // Home }); app.listen(8000); 新 Router 物件的使用方法範例 除了舊的方法之外，你可以用 Router() 去建立一個 Express 的 Router 物件，然後管理你一系列的路由規則。 var express = require('express'); // Create express application var app = express(); // Create a router to handle routes for a set of  user API var userAPI = express.Router(); // Sign in (/apis/user/signin) userAPI.post('/signin', function(req, res) {     // ... }); // Sign out (...

Feature-oriented Programming（FOP）這個名詞對很多人來說應該相當陌生，這是一個鮮少人討論的開發模式，尋找了一下，也找不太到中文的說明和翻譯，所以我就暫時稱它為『特色導向程式開發』。如果你有興趣，可以去搜尋它，或使用關鍵字『Feature-oriented Software Development』找到更多資源。也有一個以 FOP 概念所改良的 C++ 語言『FeatureC++』，可以參考。 因為筆者眼前專注於 Node.js 的發展，所以也用 Node.js 實作了一非常個簡單的 Framework 『wag.js』，讓我們可以在 JavaScript 語言的環境下，引用 FOP 的開發概念來設計軟體。你可以用 npm 直接安裝他： npm install wag.js 之所以會一時興起研究 FOP，是因為多年以來，一直為了重覆開發所苦，很多相同的東西一直不停重覆做了又做，總覺得自己一直在浪費時間，所以想試著尋找個方法來改善眼前的窘境。最麻煩的問題在於，雖然早就應用了許多模組化方法，我們也能把很多功能事先做好打包好，但仍然像個有數不清節點的連連看遊戲，讓人花不少時間在上面編織程式軟體。重點是，當其中有絕大多數的過程是一樣的時候，總讓人做得很無力。 你可以想一想，當你想要寫一個新的專案時，你通常最大的阻力是什麼？又有多少繁雜的事，每次開新專案時都重覆在做？而最令人煩燥的是，因為專案類型的不同，有些微的差異，所以難以用一個標準自動化的方式去完成。 這也是一般人和工程師最大的差別，甚至是造成溝通不良。一般人總是想著是我要什麼功能、再增加哪些功能；工程師則是一直在想著，我要挑選使用哪些功能模組，又該怎麼從數不清的可能中，選一個可行的方法組裝他們？如果想成捏黏土來比喻，一般人會捏個大概形狀，再往上慢慢堆想要的東西，慢慢趨近成果，而工程師會捏好各個部位，再把他一一拼湊起來。 我想，當你能回憶起客戶或老闆跟你說：『這功能很簡單，你應該能馬上做好』，你應該就能更明白我所說的，一般人與工程師的思維差異。不過，事實上，工程師思維和一般人沒兩樣，也是把東西堆起來，只是，工程師所設計出來的各種部位的元件，總是很難拼湊在一起，必需要花些功夫。 到底，有沒有什麼辦法，可以減少各種元件和功能模組的拼湊困難呢？讓我們可以更專心的做一個有更多...