Fred's blog

已非常熟悉 Node.js 的人都知道，crypto 模組是一個無中生有的神器。我們可以用它的 API 加工加密資料，也可以解開加密後的包裹。既然和密碼處理相關，當然也有亂數產生器，可供開發者產生一大堆的亂數資料。 如果你需要一個 32Bytes 長度的亂數資料，可以直接呼叫 crypto.randomBytes() 並帶入長度後生成： var crypto = require('crypto'); var buf = crypto.randomBytes(32); 註：回傳的結果 buf ，是一個 binary buffer，而每一個 Bytes 都會是範圍在 0 ~ 255 （0x00 ~ 0xff）的數字。 不過，在多數應用中，我們更常需要一個亂數字串，而非二進位的亂數資料，這時就需要做一些進一步的加工處理。方法其實不只一種，如建表、取代不可見字元碼等方式都可以，沒有標準做法。但懶惰的開發者們，多半是直接利用 Buffer 內建的 API 來將資料轉換成字串，並指定編碼方式來達成。 下面兩種方法都可行： buf.toString('hex'); buf.toString('base64'); 只是，使用十六進位（hex），會讓你的最後的字串單純只有 0-9 和 a-f 的字元存在，所以使用 base64 是比較好的選擇，讓字串多變並複雜些。 註：base64 編碼是以 6 bits 為單位來進行處理，而 1 Byte 有 8bits。如果你的資料長度非 6 bits 的整數倍長度，base64 會在結尾補上『=』。有些人覺得多了一些『=』符號很醜，就會用 replace() 替代掉或者是一開始就取 6 bits 整數倍長度的亂數資料（如：3 bytes、6 bytes 等等）。 有些情況，我們需要特定長度的亂數字串，也可以搭配使用 substr()，只是要確定生成的字串長度，比我們想要的字串長度還要長。下面的範例，就是取八個字元長度的字串： buf.toString('base64').substr(0, 8); 當然，若你想要一次搞定，也可以將之前所說的，全部串在一起寫： var randomString = crypto.randomBytes(32).toSt

義大利咖啡館－科技和人文的結合 看到時不時有新聞在報 POS，一時興起，就去把舊照片翻出來，沒想到癮科技還保留了快十年前的照片和報導『 義大利咖啡館－科技和人文的結合 』。 這套 POS，是在當時在經營 Coffee Shop （以現在的角度來看，其實是半個 Working Space）時所開發的，店在板橋江子翠捷運站旁（建築物前還有一座三層樓高的羅馬柱），共三層樓約四五百坪左右，店裡沒有對外掛招牌並擺滿了各種收藏品和古董家具，不知道的人看起來像間古董家俱店，不太敢進來，所以來的都是慕名或是口耳相傳，以及喜歡我們咖啡的人，因此也有人以『神秘咖啡廳』稱呼。 不過，Coffee Shop 其實一直不是主業，只是公司的招待、展示中心和團隊休閒區，而應用、工程、軟體開發和軟硬體整合的產品開發才是我們主要的工作。所以我永遠窩在店裡的某一角，寫著我喜歡寫的程式，周遭來來去去的客人並不真的清楚我是誰。 還記得，點餐系統軟體、平板硬體和後面印單系統整套做出來並實際上線，大概是在 2004 年（大概是高二時），報導則是 2006 年的事了。而且因為這套系統和管理流程設計，讓幾百坪的店面，只需要一兩個人就可以完全掌控、經營和服務，讓我們著實省下不少功夫。雖然很懷念當時的日子，但一想到惡房東後來給我帶來的多年痛苦，以及官司上的問題，至今我仍然還是恨的牙癢癢，因而有很長很長一段時間，我絕口不提這段往事。 所以這也是為什麼，多年後看到這標題，感觸極深，當時『科技與人文的結合』和『科技與藝術的結合』這個標語，一直都掛在店裡的展示大螢幕上，因為這是我們自己對設計的最高期許，也是一直身體力行的方向。許多進進出出拜訪我們的人和國內外大佬們，應該多少都看過。只是後來大多數人再次使用這段話時，是在多年後 Apple 的產品身上，這也算是種台灣的悲哀吧。 很多人不知道，我其實非常喜歡喝咖啡，甚至會燒，只不過後來若不是真的跟我很熟的人，可能從來都沒看過我喝。當時店裡的紀念款 La Marzocco 機器，現在還好好保存著，期盼哪一天能夠在我比較穩定的時候，再次拿出來使用或是與朋友分享。 不曉得還有多少人記得我們這家店？但無論如何，總有一天，我會讓他復業。不為別的，就為了從小所抱著的夢，這是我一頭栽進創業和改變世界的原點。

還記得前陣子，就在書將出版之際，半路殺出來最新的 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，是因為多年以來，一直為了重覆開發所苦，很多相同的東西一直不停重覆做了又做，總覺得自己一直在浪費時間，所以想試著尋找個方法來改善眼前的窘境。最麻煩的問題在於，雖然早就應用了許多模組化方法，我們也能把很多功能事先做好打包好，但仍然像個有數不清節點的連連看遊戲，讓人花不少時間在上面編織程式軟體。重點是，當其中有絕大多數的過程是一樣的時候，總讓人做得很無力。 你可以想一想，當你想要寫一個新的專案時，你通常最大的阻力是什麼？又有多少繁雜的事，每次開新專案時都重覆在做？而最令人煩燥的是，因為專案類型的不同，有些微的差異，所以難以用一個標準自動化的方式去完成。 這也是一般人和工程師最大的差別，甚至是造成溝通不良。一般人總是想著是我要什麼功能、再增加哪些功能；工程師則是一直在想著，我要挑選使用哪些功能模組，又該怎麼從數不清的可能中，選一個可行的方法組裝他們？如果想成捏黏土來比喻，一般人會捏個大概形狀，再往上慢慢堆想要的東西，慢慢趨近成果，而工程師會捏好各個部位，再把他一一拼湊起來。 我想，當你能回憶起客戶或老闆跟你說：『這功能很簡單，你應該能馬上做好』，你應該就能更明白我所說的，一般人與工程師的思維差異。不過，事實上，工程師思維和一般人沒兩樣，也是把東西堆起來，只是，工程師所設計出來的各種部位的元件，總是很難拼湊在一起，必需要花些功夫。 到底，有沒有什麼辦法，可以減少各種元件和功能模組的拼湊困難呢？讓我們可以更專心的做一個有更多