Fred's blog

最近因為一些專案，所以需要實做一些撲克牌的洗牌機制。雖然這個動作看起來簡單，但其實對於開發者來說相當有趣，因為真的除了做這種牌類遊戲之外，平常很少用到這樣演算法，也由於有太多種做法，不免著迷於其中。 洗牌目的就是讓結果隨機、不能預期，只不過雖然很多遊戲同樣都是圍繞在亂數產生上面，但撲克牌遊戲（或麻將遊戲）最大的不同，就是同一排組每次發出來的牌，一但發過了就不會再出現一次。這一點，和每次都可以出一到六點數的骰子遊戲，就完全不一樣，不是隨機出一個亂數就可以搞定。 準備工作：先準備個牌組 開始前，先準備四種花色、A 到 K 的牌組，使我們可以以 0 至 51 的號碼去取得任意一張牌。 const suits = [ 'S', 'H', 'D', 'C' ]; const points = [ 'A', 2, 3, 4, 5, 6, 7, 8, 9, 10, 'J', 'Q', 'K' ]; const cards = []; for (let i = 0; i < 4; i++) { for (let j = 0; j < 13; j++) { cards.push(points[j] + suits[i]); } } console.log(cards[10]); // 10S（黑桃10） 方法一：硬幹 最直覺的方法，不外乎就是不斷產生 52 張牌的亂數（0 ~ 51），然後檢查這張牌發過沒，如果牌發過了就重新產生一個新的亂數，持續這個步驟。 let shuffledCards = []; while(shuffledCards.length != 52) { // 取得 0 ~ 51 的亂數 let idx = Math.floor(Math.random() * 51); let card = cards[idx]; // 檢查這張牌是否已經出現過 if (shuffledCards.indexOf(card) !== -1) continue; // 沒出現過則放入陣列 sh...

熟悉並學習實作 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...

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。 只能使用在純函數 你可能會聽一些人說，只有「純函數」才能引入快取機制，然後開始討論數學上所謂函數的定義，然後你就聽到昏了，後面在講什麼你就都聽不進去了。 但如果撇除函數的數學定義，若白話來說，能被快取的東西，就是能被預測的東西，這代表函數的執行結果也要能被預測，也就是一樣的輸入值，就會有一樣的輸出結果。 所以，如果一個函數每次執行，代入的輸入值一樣，但回傳結果卻是可能不一樣，這...

在 Node.js 的世界裡，說到今天最潮的 Web Framework，肯定就是 Koa！其用了最新的 JavaScript 語法和特性，來改善 Web Framework 的設計。只不過，Koa 雖然相對於其他舊的 Web Framework 來說有相當多的進步，但很多人卻相當討厭 Koa 的 Generator 設計，尤其是那些「*」符號，那不知所謂的 yield 也讓很多人不舒服。所以至今仍然有許多人在使用 express 來當作自己的 Web Framework，寧可繼續使用那老派的 callback 設計，而不肯嘗試 Koa。 隨著 ECMAScript 標準的進步，Koa 才剛被開發出來沒多久，原本的開發團隊就立即著手打造 Koa 2 ，開始更進一步採用更新的 JavaScript 特性，以 async/await 語法重新打造了全新且更簡潔的框架。可惜的是，由於 async/await 語法一直遲遲沒有被 JavaScript 引擎原生支援，因此總需要靠 babel 編譯打包程式碼後，才能正常跑在 Node.js 之上。這讓 Koa 2 一直無限期處於非穩定版，讓原開發者從開發的一開始，就打算等到 V8 和 Node.js 開始原生支援 async/await 後，才會被以穩定版（stable）的姿態釋出。 所以，即使 Koa 2 到了今天已經相當穩定，也開始有不少人使用在自己的線上服務，卻一直無限期處於非穩定版的狀態。 另外，由於 Koa 2 大量使用 Async/Await，如果你還對 Async/Await 的使用還不熟悉，建議在閱讀本文之前，先閱讀舊文「 JavaScript 好用的 async 異步函數！ 」來學習如何使用。 學習 Koa 的好時機來囉 總算，日前 Node.js v7.6.0 釋出後已經正式宣布原生支援了 async/await 語法，而且不需要額外的參數選項。伴隨著這個消息，Koa 2.0 也隨即正式釋出了！ Node.js 內建支援 ES7 的 async/await 真的是非常棒的消息！過去我們使用 async/await，都還需要 babel 的協助才能正常跑在舊版的 Node.js，不但開發上相當麻煩，非原生的各種 ES7 特性也浪費不少額外的記憶體和效能，這樣的問題在斤斤計較效...

「 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 的模組「...

雖然有些概念類似甚至可以相通，但這裡並不是指常聽到的「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; }); // [...

最近參與了一些關於資料處理的專案，處理了很多各式各樣的原始資料（Raw Data）或各種不同格式的資料，於是使用到了 Node.js 上的一些小技巧。像是一行行讀取檔案內容這件事，就隱藏了一些技巧。 對很多人來說，處理的檔案內容都不大，如果用 Node.js 來一行行讀取檔案內容，不外乎就是將整個檔案讀出後再進行切割，做法大致上如下： var fs = require('fs'); fs.readFile('example.txt', function(err, data) { // 以換行字元作為切割點，將內容切成一個大陣列 var lines = data.split('\n'); lines.forEach(function(line) { // 一行行處理 }); }); 但有些時候，由於檔案並不小，若又牽涉到運算，不可能整個檔案都讀出到記憶體上才進行切割，這時就得用到 Stream（資料流）機制，將檔案一段段讀出來進行處理。然後，為了進行一行行的切割，我們會自己做這樣的機制，先將一段段讀取出來的檔案內容放到緩衝區（Buffer），然後找到換行字元進行切斷取出，然後再繼續讀取檔案，重複這樣的過程直到檔案結尾。 的確，實做這樣的機制有點麻煩，所以其實能利用 Node.js 現成內建的核心模組 Readline 來做到切割資料流中一行字串的工作。因為常見的 Readline 用法都是拿來做終端機字元模式下的命令列操作，所以許多人沒有想到可以這樣使用 Readline。作法其實很簡單，就把 Readline 的 input 從標準輸入（Standard Input）換成我們的檔案讀取資料流就可以。 完整做法如下： var fs = require('fs'); var readline = require('readline'); // 建立檔案讀取資料流 var inputStream = fs.createReadStream('example.txt'); // 將讀取資料流導入 Readline 進行處理 var lineReader = readline.createInterfac...

先聲明，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...

使用 MTK LinkIt Smart 7688 這類開發板時，總是很痛苦，由於儲存空間不大，記憶體也不大，常常在開發的過程中飽受折磨。於是我們開始思考如何可以在自己的電腦上，模擬一個 MT7688 的環境，在有充沛資源的機器上進行開發。就這樣，前陣子開發了一個小小的 Open Source 工具專案「MakerBoard」，並在 MakerCup 的共筆網站發表「 沒有板子也可以玩的 7688 模擬器！ 」。 雖然這樣一個小小的模擬器運用了 VM 和 Container 相關技術。但其實主要概念並不難，這次 5/10 在台大的開放原始碼課程中，就簡單從 MakerBoard 這專案出發，然後說明了一下怎麼樣自己打造一個簡單的 Container，並利用 QEMU 來進行 Binary Translation 的工作。 簡報釋出，請自行服用：

話說，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 這樣單執行緒（Single Thread）的設計，到底有什麼優點？為什麼總是有人說，它比傳統多執行緒的設計來得有效率？以往，一旦開始討論這個問題，總是會有人開始提到 Context Switch、Asynchronous 等機制，越講越玄也越講越複雜化。 其實我們可以用簡單的餐廳比喻，就能理解 Single Thread 加上事件驅動（Event-driven）的機制，如何與傳統設計不一樣。 場景想像 試想一個場景：一間餐廳有 100 個座位，然後來了100個客人。 處理方法 身為老闆的你，你會選擇哪種方式服務這些客人： 請100個服務生一對一服務這些客人。 請 25 個服務生，看當下狀況服務這些客人。 一般來說，傳統的多 Multi-thread 的設計就類似方法 1，而 Single-thread 且 Event-driven 的設計就是方法 2。 通常大多數情況我們會選擇方法 2，因為客人通常都是處於等待（看菜單、等上菜、吃自己）的情況，並不需要服務生貼身服務。所以即便請 100 個服務生，這些服務生大多數時間也只是等在那也佔地方，而服務生眾多也導致服務生之間的溝通和互動其實不易，更不容易交換資源，回報和協同工作難以進行。反而安排一個小型的外場班，讓裡面的人合作見機行事，會比派出 100 個各自獨立的人來得好。 併發數高的原因 併發數（concurrent request）指的是單位時間內可以處理的要求量，一般用來評估一個網路應用程式的效能。而通常在網路服務裡，併發數也相當於單一時間內能服務的連線數量。 所以，以前面餐廳外場班的模型來說，如果你有 100 個服務生，就可以服務 400 個客人。換句話說，同樣的資源，能處理的併發數（concurrent requests）也就比較高。 後記 不過如果你開的是酒店或按摩店，那可能就要請一百位服務生了。:-)

自從 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）幫忙排解問題。 黑客松式的學習活動 回想起過去從小到大，我們的學習模式，總是有個老師在台上教學，枯燥而乏味，而為了保證教學進度，不免伴隨著填鴨式的教學方法。這樣的模式我們早就習慣，雖不見得喜歡，但也無可奈何，逐漸的，我們的思考和學習，慢慢僵化了。 具有一定寫程式經驗的人都知道，...

 在 Facebook 看到很多人都在整理自己的程式筆記，我也整理關於 JavaScript 語言常被誤解部份的筆記，然後分享出來供各位同好參考。 講實話，從 1995 年開始的 JavaScript，直到前幾年，都讓我恨的牙癢癢，甚至覺得他是個垃圾，因為當時的他太沒有規範，效能極差。直到近年來才逐步改善，我也才慢慢擺脫對他的排斥及恨意。 但就算已經有標準規範，JavaScript 語言對很多人來說依然很頭痛，除了其 Asynchronous 非同步的機制外，更要面對其極為動態（Dynamic）的特性，而從 OOP 的角度來看，其 classless 的設計更讓人不知所措（ES6 之後開始支援 Class），與傳統的 OOP 相去甚遠。所以，JavaScript 處處與其他語言完全不一樣的概念及思維，讓很多人在裡面處處誤解。 所以若是想學習 JavaScript 深入的概念，最好的方式就是放下其他語言的既有概念，直接了解 JavaScript 的核心機制，雖然會讓人手足無措，但卻是最好的手段。否則，很容易練就或死背很多怪招，寫出難以除錯或過於複雜的程式碼，當然，更嚴重的是誤導他人。 要深入或精通 JavaScript，務必了解並思考其執行程式時發生什麼事，每一行程式碼當下被執行時的狀態，遠遠比程式碼排列來得重要。只要掌握每一行程式碼的『執 行當下』，所有 JavaScript 的疑難雜症，都能迎刃而解。關於這一點，有興趣閱讀硬梆梆定義文件的，可以參考 ECMA-626 的『10.3 Execution Contexts』一節。（參考網址： http://www.ecma-international.org/ecma-262/5.1/#sec-10.3 ） 關於 this 關鍵字的機制 很多人會搞糊塗 this 關鍵字，就因為他是一個會被 Execution Contexts 大量影響的東西。JavaScript 在 Function 或 Context 被執行時，才會依當下情況去決定 this 為何。這代表，使用 this 時在哪一個 function 或地方不重要，而是當進入這個使用 this 的 context 時（如：Function 被執行時）才會決定 this 是什麼，this 是什麼只跟你如...

經過幾個月努力，新書『 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!