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

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

最近參與了一些關於資料處理的專案，處理了很多各式各樣的原始資料（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...

由於最近在開發自己的產品，又開始重操舊業，開發起 Linux 系統的相關應用和嵌入式技術。為了這個產品，精心開發了一個使用者介面，除了動手把驅動程式搞定、圖形化介面搞定，也調教效能、改善系統架構。 開發自己的產品很過癮，愛怎麼搞就怎麼搞！於是，看到死板的背景覺得很不舒服，就在思考是否可以跑個動畫背景呢？ 因為使用的是 QML 技術來開發 UI，最直接的想法，就是用 QtMultimedia 的 MediaPlayer 無限循環播放一個影片，當作動畫背景： MediaPlayer { id: bg; source: 'bg.mov'; loops: MediaPlayer.Infinite; autoPlay: true; } VideoOutput { anchors.fill: parent; source: bg; } 當然，我們選擇的背景影片，是一個開頭跟結尾一樣的影片，如果正確循環播放，會無縫接軌的變成一個順暢的動畫背景。 然而，結果不如預期，碰到了一個問題，那就是每當背景影片播放到最後時，會畫面變成全黑，然後才再一次重新開始播放，沒辦法「無縫接軌」。仔細暸解以後，發現 MediaPlayer 元件是 QMediaPlayer 的 QML Type 實作，所有秘密都藏在 QMediaPlayer 之中。因為 QMediaPlayer 預設所有的通知事件，都是固定以 1000ms（1秒）的頻率來觸發，這代表，當 QML 元件發現影片播完時，通常已經是播完以後的事了，所以畫面一定會因為影片結束而變黑，然後 QML 元件才發現影片結束，重新進行播放。 知道緣由後，我們可以從事件更新頻率下手，讓 QML 元件發現影片播完的時間更接近實際影片結束的時間，但這必須動用到 C/C++ 的實作，因為 QMediaPlayer 的事件更新頻率無法以純 QML 的方法修改。 C/C++ 完整應用程式的實作如下，我們把更新頻率調高為每 100ms 一次： #include <QGuiApplication> #include <QQmlApplicationEngine> #include <QQuickWindow> #include ...

身為 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 處理。所以前一個例子裡，我們...

使用 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://...

搭配使用 Git 進行開發工作，時常會碰到一個狀況，就是我們 fork 一個專案出來修改，但在我們在修改的同時上游有了更新，這時我們會想要把上游的更新同步下來。這是一個常見的問題，許多人不時會提出來詢問，事實上如果你去 Google ，多半能找到這樣一篇名為「 Syncing a fork 」的 Github 文件。雖然這篇文章已經把程序詳細列出來了，但還是有人看不太懂，原因是要搭配「 Configuring a remote for a fork 」這一篇文件一起看才知道來龍去脈。 簡單來說，我們要先把「上游（upstream）」的 repository 加入我們眼前正在修改的專案，然後把上游更新拉回來，最後再與我們現有程式碼合併。 首先，加入上游的 repository 並命名為「upstream」： git remote add upstream https://github.com/YOUR_USERNAME/YOUR_FORK.git 未來想要更新前，可以使用 fetch 去拉上游的更新回來： git fetch upstream 最後再把 upstream 的內容，與現有的正在修改的進行「合併」： git merge upstream/master

自從 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 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) {...

話說 如果你之前就有參加過我們的 Hackathon 活動，就會對從第一屆黑客松就有的倒數計時器有所記憶。這是我們特別為 Hackathon 活動所開發的倒數計時器，其著漂亮粒子特效，讓許多人印象深刻，尤其是投影在夜晚的牆壁和玻璃上，伴隨著台北 101 和夜空為背景，可說是非常炫麗又有氣氛。 但經歷過了四次活動，這個計時器也該功成身退了，隨著活動人數成長，活動內容及場地規劃，舊的計時器已經慢慢不敷使用，除了一身漂亮的動畫外，沒有太多的功能。而且，縱使有著一個看起來炫酷的特效，對工作人員和很多參加者來說，也慢慢膩了。 於是，我們又提起筆開始設計一個全新的倒數計時器系統，想設計一個更具科技、科幻感及現代感的介面，除此之外，更希望可以在未來可以引入更多的功能和互動機制，如導引、會場資訊查詢、甚至是直播等。就這樣，一個新的計時器誕生，並在 3/7 - 3/8 第五次的黑客松活動被使用。 因為我們期望這個計時器，不只是用來倒數計時，未來能變成一個多用途的活動系統，所以在設計上有更多的規劃及保留。也採用更多色塊來進行設計，讓畫面上有更多可利用的空間。 互動功能 在這次活動中，我們觀察到了一個現象，那就是對正在專心進行創作及 Hack 的人，手上的工作雖樂趣無窮，但對於旁觀者來說，卻是無聊透頂，這讓黑客松（Hackathon）活動的現場，時不時會呈現一種沈悶的氛圍。此外，參加者的工作效率往往呈現著週期性，或是專心時間總有一個極限，適當的放鬆和中斷也是常見的情況。但是如果放鬆或中斷手上工作時，沒別的事可以舒展身心，這會感到相當無聊了，於是會看到有些人會選擇用吃東西來打發中間的時間。 其實，來黑客松除了動手做之外，人際關係經營及交流也是很重要的一環，但別人正在專心工作時，你不便打攪，尤其是當同隊的人都正在專注做事實，你剛好想要換個氣的時候，更不可能去煩自己的隊友。不過，雖然你的周圍可能沒人可以跟你互動，但你可以去找同樣想換氣的人產生互動，畢竟全場人這麼多，跟你處於同一個狀態的人總是有不少。 那麼，如何找到人可以跟自己互動或交流呢？ 這次活動，我們建立了 IRC Channel ，讓參加者可以上來 IRC 聊天室來說說話。所以，如果你有興趣，除了活動時間之外，平時也可以加入我們的 IR...

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!

Koa 採用了 Generator 來控制非同步流程，所以在採用 Koa 的程式碼上，我們會看到很多 yield 關鍵字的出現。某程度來說，Generator 讓程式碼變得乾淨許多，也平坦許多，比較少出現太複雜的 Callback 高山。這對 JavaScript 來說是件不錯的事，只是，對很多開發者來說，需要點時間熟悉其概念。 總而言之，所有 yield 的關鍵字，一定只會出現在 Generator 當中，而一個 Generator 長得會是一個以『*』符號開頭的函數模樣： function *() {     // 工作流程 } 所以若是你仔細觀察，就會發現 Koa 的路由處理，採用的不是 callback 來處理客戶端要求，而是 Generator： router.get('/test', function *() {     // 處理客戶端要求的工作 }); 其實不久前，舊文『 如何於 KOA 實作長輪詢（LONG-POLLING）機制 』已提及怎麼來掌控 Koa 的流程，雖然只是簡單提及，但已經大略展示其使用方法。簡單來說，你可以當作這個 Generator 結束後，與客戶端的連線就會結束，所以我們如果要處理非同步的工作，也必須避免和阻止這個 Generator 執行完。 使用 yield 控制 Generator 的流程 為了阻止 Generator 一下就跑完，我們會使用 yield 方法來暫停 Generator 的執行，並等待一個需要花時間的非同步工作完成。如果你對舊文的內容有印象就會知道，想要使用 yield 在 Koa 中去呼叫一個非同步機制，就需要設計一個特別的函數，其函數有一個 callback，當這個 callback 被呼叫時，代表工作完成。 如下面範例就是想要執行一個非同步函數 setTimeout()，並等待其執行完成。在這範例中，我們加上了 console.log() 印出 START 和 END 字串，便於觀察其行為： router.get('/test', function *() {     console.log('START');     // 暫停 Generator 並等待工作完成     y...

如果你有關注這兩個月 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，可以讓我們不必觸碰到作業系統核心的驅動程式技術，就可以開發一個自己的檔案系統。然後，我們可以把自己實作的檔案系統掛載到一個本機目錄上。這代表...

在國內，很多人或許對 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...

不用覺得奇怪，Hankathon 沒有拼錯，這是取自 HanGee + Hackathon 的命名。是這次為了 9/20 - 9/21 兩天的 HanGee Hackathon 活動，設計的一個騷包倒數計時器，也是我在邊辦活動邊做的成果之一，用來提醒眾參加者們，時間正在毫不留情的流逝！ Source Code:  https://github.com/HanGee/Hankathon 如果你的黑客松、活動需要用到這個倒數計時器，歡迎取用！也歡迎修改成你想要的功能！只是，如果可以的話，麻煩留下蕃薯的小圖，協助讓 HanGee 亮點像吧！:-) 後記 這次的黑客松活動，就在經歷過兩天美好的夜景、日出景色，最後經歷颱風大雨的情境下落幕。雖然中間出了一些烏龍，仍有一些朋友們沒有被好好照顧到，但都在歡樂的氣氛下和滿滿的產出中結束。下我們肯定會再次舉辦，讓更多無論有沒有資身技術背景的朋友，都能夠共同參與並學到東西和經驗回家。:-D 此外，如果有社群或企業想要一同舉行下次的 Hackathon，歡迎連絡我們！

台灣的電玩機臺一直是一個很少人探討的遊戲產業，他們外銷機台到國際各大賭場，除了一直在設計讓人願意掏錢的有趣遊戲機外，也真真實實用到很多資訊科技。在多年前一次南部的經驗，有幸接觸到這樣神秘的產業，也幫他們開發過一些東西。而其中一項專案，就是一個加密檔案系統，讓他們可以保護他們的遊戲程式，避免被對手輕易偷走自家的程式。 於是就有了這個 MDS 檔案系統（Middle Stone Filesystem），採用 blowfish 演算法加密，支援 384-bit key 和同時多組 key 的存取。由於作業系統本身會很容易破解修改，要保留可以將解密工作和 key 放在額外的硬體鎖或晶片上，甚至是多組 key 可跨多個硬體晶片存放，增加破解的難度。所以因此也設計了一些單獨的讀取工具範例，讓硬體鎖的開發人員，可以參考做法，寫在其硬體韌體（Firmware）中。不過，更近一步和硬體整合的版本，礙於敏感，這次就沒有釋出了。 專案網址： https://github.com/cfsghost/mdsfs 其實，這專案多年來一直對周圍的朋友嘴炮說要開放出來，可是一直沒負諸行動（當然也是因為懶惰）。而今天看到 iCloud 被破解的新聞，受到一點資料安全問題的刺激，於是想起這個專案，所以就花點時間挖出來整理一下文件並往 Github 上丟。由於，這個基礎版本很久沒維護了，安全性如何我不能保證，但拿來做學習 FUSE 和加密演算法應用，倒是有點參考價值。如果有人想要接著開發，也非常歡迎！ 另外，有些人反應不知道能拿來幹麻。關於這件事，其實把 MDS 當做一個簡單的加密打包工具，也是可以的。 後記 看到 iCloud 被破解的新聞，不由得讓人重新思考雲端和未來物聯網時代，資料安全的重要性。稍為瞭解真象的人通常都會跟你說，千萬不要相信任何人，將東西和隱私放在雲端。而通常你第一個要害怕的是雲端系統管理人員和系統設計人員的操守，他們是不需要經過任何破解手段，即可全權存取你資料的人。再來，我們要擔心的是系統的安全性，設計者和管理者能否真有能力去保護使用這的資料？這從使用者手上的 App、作業系統、瀏覽器，一直到雲端上的一切系統，都是必需要考量的範圍。也因為這樣種種的複雜情境，使用者實在難以得到真正安全的保護。 原因其實很簡單，當檔案自你手邊的機器準...