玩物尚誌

Vaadin 來自北歐的 Web Application 開發利器

2012-05-26T00:13:00.001+08:00

對許多 Web-based Application 的開發者來說，要選擇什麼樣的 Web UI Framework，其實並不是那麼好下決定。這裡指的 Application 並不是一般認知的內容網站，而是用網站技術來開發過去用視窗介面打造的應用程式。雖然 Web UI 有很高的彈性，可以在不同作業系統下呈現相同的外觀（幾乎啦），也可以不受作業系統原生操作介面的限制；打開瀏覽器就能啟動應用程式，不用下載安裝，讓應用程式發展的想像可以更豐富。

但 Web UI Framework 的發展還在相當年輕的階段，要用什麼模式（pattern）來開發有著各方不同的意見。像 ExtJS 就讓前端（front-end）的 JavaScript 主宰一切，後端只負責產生資料；而 GWT 則盡可能在後端實作，隱藏前端需要的細節。其實現行的方案，不管選擇什麼都是優劣參半，沒有哪個是絕對好或不好，重點在於框架未來是否得以延續發展。

對專案來說要選擇合適的框架並不容易，因為你需要瞭解每一種框架的利弊得失，才能為不同的需求選擇正確的專案。在 Web UI 大行其道的今日，以及可預期的未來將有大量應用程式會以 Web-based 方式開發，每位開發者都應該多認識各種框架的發展。

最近我愈來愈期待 Vaadin 這個框架的發展，所以整理成這篇筆記方便大家快速認識。

Vaadin 是一家公司名字，同時也是開發框架的名稱，這家公司位於北歐芬蘭（Finland），這個特別的產地賦予它獨特的血統，讓它看起來獨具風格。Vaadin 是採用 Apache V2 授權的開放原始碼專案，開發者可以利用它當做基礎擴充自己需要的元件。

以 GWT（Google Web Toolkit）為基礎發展的 Vaadin，也是 Java-based 的開發框架，程式碼主要是在後端以 Java Class 定義，再由框架產生所需 JavaScript 程式碼。

關於 Vaadin 和其他框架的比較，可以參考這個網址： https://vaadin.com/comparison （同時也能了解還有哪些值得比較的框架）

從 Vaadin 的 Sampler 可以瀏覽提供了哪些元件：

http://demo.vaadin.com/sampler

聽到 GWT 很多人可能會覺得，這大概又是一個其貌不揚的框架。不過來自北歐的 Vaadin 擁有簡約的視覺風格，開發者能用它打造出專屬的外觀。

以下是 Vaadin 的 iTunes 佈景示範：

http://demo.vaadin.com/VaadinTunesLayout/

另一種佈景風格：

http://demo.vaadin.com/chameleon-editor

提供所視即所得的 Visual Designer 也是 Vaadin 的特色之一，這個 Designer 也是用 Vaadin 開發，它附屬在 Vaadin for Eclipse Plugin，可以跟 Eclipse 開發工具整合在一起。

http://demo.vaadin.com/visualdesigner-nightly

目前 Vaadin 的出版品並不多，只找到這本由手腳很快的 PACKT 出版社發行的書籍（有提供付費電子書）。

http://morevaadin.com/

Vaadin 是個值得期待的框架，看起來很適合用於某些功能不是太多太複雜的專案；但它是 Java-based，以筆者來說就相當討厭用 Java 寫 Web 程式，幸好 Vaadin 目前已經有 Grails 的 Plugin 可用，因此可以利用比 Java 簡潔很多很多很多的 Groovy 來開發 Vaadin 應用程式（現階段開發上可能還有不少問題）。

Vaadin Plugin for Grails http://grails.org/plugin/vaadin

也許你不會真的拿 Vaadin 來開發專案，但是多觀摩不同產地來源的框架，仍可以帶來一些啟發。

Node.js NPM 相依模組問題處理，以 connect-mongodb for Windows 為例

2012-05-24T10:58:00.001+08:00

Node.js 使用 NPM 工具管理模組依賴關係（modules dependencies），開發者可以在專案資料夾定義 "package.json" 設定檔，如此一來就能方便建置（build）的自動化。對某些雲端 PaaS 服務來說，這也是必要的設定（例如 Heroku）。

不過當模組愈來愈複雜，dependencies 會是個製造問題的麻煩，例如在 Node.js for Windows 環境下，安裝 connect-mongodb@1.1.3 會發生錯誤。

"dependencies": {
"connect-mongodb": "latest"
}

錯誤訊息如下：

從訊息中可以發現 mongodb@0.9.7（在 connect-mongodb 的 package.json 指定的版本）這個版本無法在 Windows 環境下安裝。但如果使用 npm install mongodb 或是在 package.json 增加 mongodb 的相依（目前最新版本是 1.0.2），會發現最新版本的 mongodb 模組已經相容 Windows。

"dependencies": {
"mongodb": "1.0.2",
"connect-mongodb": "latest"
}

但即使增加了最新版的 mongodb 相依設定到 package.json，NPM 仍會強制幫 connect-mongodb 安裝其指定的 mongodb@0.9.7。

我參考 npm-shrinkwrap 想要設定 sub-dependencies，但最後並沒有成功。

另外一個嘗試結果可以解決問題，就是在 GitHub 上面 fork 一份原始專案，我想這也是一個可行的方案：

許多 Node.js modules 都有 GitHub Repository
NPM 支援從 GIT / HTTP URL 取得 modules（很方便的 feature）

因此我將 masylum/connect-mongodb fork to lyhcode/connect-mongodb，再修改 package.json 的 mongodb 相依版本為 1.0.2。同時也將這個修改 Pull Request 到原始專案。

我不知道原作者什麼時候才會 accept 這個 request，不過在這段期間，可以直接將 GIT URL 作為 package.json 的 dependencies 設定值，如此一來就能自己快速解決某項模組的小問題。

"dependencies": {
"connect-mongodb": "git://github.com/lyhcode/connect-mongodb.git"
}

Mosh（mobile shell）取代 SSH 的遠端終端機連線工具

2012-05-23T19:23:00.001+08:00

畫面來源：Mosh Project Site

Mosh 是終端機連線工具，它不是一種 Shell（如 bash、csh 等），而是一般熟知的 SSH / Telnet 有相同的作用 --- 連線到遠端的文字終端機。

但是 SSH 已經很管用，而且也跨平台，為什麼還需要 Mosh 呢？

Mosh 可以用來改善 SSH 的使用經驗，尤其是你需要透過無線網路、行動上網操作終端機時。相信經常使用 Linux、Mac OS X 的朋友，都會利用 SSH 連線到遠端的 Server / Workstation 工作，雖然文字終端機對頻寬的需求很低，但無線網路有延遲（latency）、斷線問題，會造成終端機在這種不堪使用。

例如筆者生活的南部（天龍國以南）地區，訊號經常只有 GPRS 或不到兩格的 3G，這種情況下使用 SSH 操作終端機真是痛苦無比，經常輸入一串指令後，過幾秒才斷斷續續得到回應。如果遇到斷線，那就更糟糕了，需要重新登入才能繼續。

雖然稍有經驗的 Linux/*nix 玩家都知道可以用 screen 指令來克服，讓工作狀態可以重新恢復到斷線前的樣子；不過，若一小時內重複斷線個幾次，或者網路長短不一的延遲情況嚴重，就會大幅影響工作效率。

如果你想多體驗這種想摔筆電的感覺，只要多搭幾次高鐵來回南北部，中途利用 SSH 遠端連線並用 VIM 完成幾支程式，就知道為什麼需要 Mosh。

在 Ubuntu Linux 12.04 LTS 版本安裝 Mosh，只需要一行指令：

sudo apt-get install mosh

基本的使用方式跟 SSH 類似：

mosh hostname

或（指定登入使用者）

mosh user@hostname

需要注意的是：Server 端也必須安裝 Mosh（連線建立時必須會在 Server 端自動執行 mosh-server）

以下是 Mosh 的官方介紹（中譯摘要）

切換IP仍保持連線 Change IP. Stay connected.
在不同的網路連線之間自動漫遊，例如在火車上使用 WiFi、旅館的區網或海灘的3G行動上網。Mosh 不像一般的網路程式會因為IP改變而斷線。

讓你有個舒服好眠 Makes for sweet dreams.
當你想睡覺的時候，儘管蓋上筆電的螢幕，讓它進入休眠狀態，雖然網路會因此斷線，但是當你重新打開螢幕，網路恢復連線後，原本的終端機可以自動恢復。

解決討厭的網路累格問題 Get rid of network lag.
原本的 SSH 輸入一段訊息後，必須等到伺服器回應才會顯示輸入的資料，但是對於延遲嚴重的網路，看不到即時的回應會使操作變得礙手礙腳，Mosh 可以立即顯示回應，即使是 VIM 或 Emacs 這種全螢幕的編輯器也能支援。

不需要特別的權限或常駐服務 No privileged code. No daemon.
你不需要有系統管理員權限就能執行 Mosh，直到你真正需要連線時 Mosh 才會被執行。

相同的登入方式 Same login method.
Mosh 不會監聽特別的連接埠或者驗證使用者，Mosh 的客戶端可以透過原有 SSH 機制登入到伺服器，帳號密碼及公鑰都是與 SSH 相同的驗證方式。登入後伺服器端會執行 mosh-server 來建立 UDP 連線。

在終端機中執行但效果更好 Runs inside your terminal, but better.
你可以用一般的 xterm、gnome-terminal 等終端機工具來執行 Mosh 程式，但是 Mosh 自行實現的底層的處理，因此諸如一些終端機可能會發生的 UTF-8 問題等，都可以得到解決。

Ctrl+C 正常作用 Control-C works great.
Mosh 使用 UDP 為基礎的協定，並且對封包遺失問題有好的處理，會根據網路條件調整頻率，由於 Mosh 不會將網路的緩衝區填滿，因此 Ctrl+C（中止程序）可以正常作用。

以上是官方說法，歡迎有興趣的朋友發表試用感言！

Google Doodle 紀念：電子合成器之父 Robert Moog 生日

2012-05-23T11:17:00.000+08:00

今天的 Google doodle 又有新玩具，在搜尋首頁上方的這部電子合成器，不只是紀念 Robert Moog（電子合成器之父）生日的插圖，用滑鼠按一下鍵盤還可以彈奏音樂，上方的旋鈕可以調音，而右邊裝置則是錄音功能，可以錄製、重播彈奏的音樂。

你我都是怪咖《We Are All Weird》賽斯．高汀

2012-05-22T20:16:00.000+08:00

We Are All Weird (book cover)

如果你學過行銷，那麼一定會認識 Seth Godin（賽斯．高汀）。高汀的暢銷書包括《紫牛》、《低谷》及《行銷人是大騙子！》。他利用部落格行銷他的觀點，文章也經常被報章雜誌或其他書籍引用。

Seth Godin's Blog

這篇要介紹的是高汀著作的《We Are All Weird》一書，這本書在 2011 年 9 月發行。目前沒有中譯版；但只要 1-click 就能從線上書店取得原文電子書。

在工業時代，全世界都以大眾市場作為主流，如果能製造一樣產品，不管什麼國家、年齡、文化背景的人都愛用，這樣的產品肯定能創造可觀的利潤；「量產」讓你到哪都能看到 Nike 的球鞋、Hollywood 電影或 McDonald's 速食餐廳。

高汀認為「大眾」（normal）時代已經結束，而「怪咖」（weird）時代正崛起。

過去企業賺錢的模式，是將焦點放在族群人口分布的鐘形曲線高峰，因為絕大多數人都集中在那裡，因此努力推出大眾化的品牌，製造大眾化的產品，藉此得到為數最多的消費者。

但是，有四股力量正在改變世界的趨勢：

創作能力被放大

你用手機拍攝的一部短片，可能在幾天甚至數小時就在網路流竄，在數以萬計的人們面前播放。你用論壇、部落格或社群網站發表的一篇文章，只要幾秒鐘，在地球另一面的人們也能夠閱讀。

資訊傳遞的速度太快太廣，人們開始厭倦平凡的事物，能夠吸引更多人注目的創作，必定是「特別」的東西，例如「梗漫（Rage Comic）」要有梗就必須先有怪咖（有別於常人）的獨特想法。

富有

許多國家的經濟條件改善，使得人們有機會「選擇」。舉例來說，即使是每天抱怨萬物皆漲只有薪水不漲的上班族，仍然可以花 50 元買杯 CityCafe 或 100 元的 Starbucks 當下午茶，你不會辛苦省吃儉用幾天後，才從撲滿倒出幾枚硬幣去買罐裝伯朗咖啡或雀巢三合一咖啡。

即使王品已經努力推出不同主題的餐飲，你可能覺得它仍是大眾化路線的飲食，而在需要慶祝的時刻選擇更具特色的餐廳，即使要付出更高的花費。

你已經買了很貴的 iPhone，但就是覺得不想跟別人用一樣的手機，而花費更多錢買配件讓它看起來不太一樣。

富有不代表你的口袋足夠你養一台法拉利，而是你有足夠的財富讓你做出不一樣的選擇。

行銷對怪咖更有效

每個人多少都有怪咖的特質，也因此希望跟別人不一樣。為了跟別人有一點點的不一樣，你可能必須付出更高的金額作為代價。

例如洗衣粉的品牌，若是針對「特別追求健康安全環保」的怪咖族群，那麼就可以推出比一般市價平均高一倍的產品，如此一來就會有一群人願意花更多錢購買，他們就是不想買一般廉價普通的產品。

許多人願意付出更高的價格，只為了符合自己想追求的不一樣。推出不凡的產品，針對這群人做的行銷就會帶來更高的效益。

聚落（tribes）有更好的連結

在現實生活中，同一個生活在一起的群體，通常不會有太多人是同類型的怪咖，因為如果身旁的人都一樣，那在這群人裡面就不能稱作是怪咖了。所以怪咖的存在通常被地理空間分隔，例如有一群人都是科幻迷，但他們不會剛好全部都在同一間辦公室裡。

但是拜網路及科技發展所賜，在虛擬空間中怪咖很容易就形成聚落，即使現實生活中身處不同國家，只要利用社群網站、行動裝置，就能隨時保持聯繫，對同一個類型的怪咖來說，資訊交換流通更容易。前一分鐘發生的事情，可能下一分鐘就在整個怪咖圈子裡傳遍。

我們每個人都存在怪咖的特質，這是一股驅動創新的動能，任何人都有權力選擇不一樣、追求不平凡。每一位被世人視為「成功」的人物，都將他們的怪咖特質發揮徹底，到了可以改變世界的地步。

對企業來說，高汀特別提出建言：「If you cater to the normal, you will disappoint the weird. And as the world gets weirder, that's a dumb strategy.」

這句話的意思是說：「若你想迎合平凡人，就會令怪咖失望，世界追求更不平凡，你迎合平凡將是一項愚蠢的策略。」

＊部分參考自彭蒙惠英語 2012 年 5 月刊。

Tweet-a-Watt 讓全世界知道你的節能減碳行動

2012-05-22T17:24:00.000+08:00

畫面：Tweet-a-Watt 網站

Make 雜誌中文版即將推出第四期，其中一篇名為 Tweet-a-Watt 的標題讓我想先上網瞧瞧。結果找到這個專案的原始網站：

Tweet-a-Watt Build a wireless home-power monitoring system

這是一個 XBee 電子積木的應用，創作者是位 MIT 的學生，這個發揮 DIY 精神的改裝，將用電量計數器 Kill A Watt 加入 XBee 使數據能藉由無線傳送，再經由電腦端接收後上網發佈。作者使用 @tweetawatt 的 Twitter 頁面將每天的用電量公開：

https://twitter.com/#!/tweetawatt

電量計數器是 P3 International 的 P4400 Kill A Watt 產品，在台灣可能需要花點功夫才能找得到。

改裝的重要零件 XBee 只要上拍賣網站就能找到，這是採用 ZigBee 技術的無線傳輸模組，可以被拿來和 Arduino 等當作電子積木，更容易組裝出兼具創意及實用性的電子裝置。

這項生活中的綠色創意，獲選 2009 年由 Core77 舉辦的 Greener Gadgets 成為 Top 13 得獎專案之一。

作者大方將設計、軟體原始碼大方公開，讓喜歡動手、想自己實現綠色生活小創意的人，能夠直接利用這個基礎。

我很喜歡這個 Idea，因為它讓「省電」變得更具體，例如大家都知道隨手關燈關電器可以為地球盡一份微薄之力（或是拯救北極熊？！），但每天養成的省電小習慣到底省下多少，號稱更節能的電器到底用電幾瓦，有了數據就會更具體。

雖然有耗電量計數器可以呈現即時的用量，但實際上不太可能頻繁地觀察數據；透過這項小改裝讓數據透過社群網路記錄起來，你就能清楚今年夏天和去年相比，用電量是否增加了？

如果你懂一點程式設計，就可以利用這個基礎發揮更多的應用，例如讓數據圖形化，用圖表來讓「省電」變得更具體、視覺化。

或許有一天，你的手機主畫面螢幕上，不再只有天氣和時間，還會多了一項「我家的用電量」。

延伸閱讀：

Carol 最新單曲：小音符 Carol's Little Note

2012-05-21T11:59:00.002+08:00

Carol's Little Note 單曲封面

五月最重要的日子就是溫馨的母親節，Carol 最新單曲「Carol's Little Note（小音符）」在這個月發行，因為我自己錯過了 5/12 的台中場，所以把活動訊息貼出來，希望喜歡 Carol 音樂的朋友可以不要錯過月底的幾場。

小音符是 Carol 獻給母親的一首歌，不管是音符旋律或歌詞都帶有濃厚的情感可以穿透你的心。

Carol Music 網站

誠品音樂現場

5/12(六)20:00-21:00 台中園道店3F
5/26(六)1500-1600 台東故事館2F藝文空間
5/27(日)1500-1600 高雄大遠百店17F書區中庭
6/01(五)2200-2300 台南店B1書區舞台

線上音樂

KKBox 試聽

客製化 ExtJS 4.1 佈景主題小筆記 Compass/Sass

2012-05-17T22:05:00.000+08:00

在 ExtJS 2.0-3.0 的時代，搜尋一下就可以找到不少佈景主題（themes），例如：

但是到了 ExtJS 4.x，即使 4.1 已經正式發佈，還是很難找到官方以外的佈景主題。

目前 ExtJS 4.1 可用的佈景選項有：

Default（淡藍色）
Gray（灰色）
Neptune

雖然 ExtJS 4.1 很難找到現成、好看的佈景，但其實 ExtJS 從 4.x 開始加入更現代化的 Sass（ Syntactically Awesome Stylesheets）支援，使得 ExtJS 4.x 的佈景主題更容易依照專案的特殊需求進行客製。

ExtJS 4.x 內建的佈景都是採用 Sass 語法撰寫，並且以 Compass 為基礎，打造樣式定義出可重複利用、易擴充的佈景。

Sass 簡單說就是增強版的 CSS 語法，它可以做到過去 CSS 不可能做的事情：定義變數、宣告函式、巢狀樣式定義、尺寸單位及顏色的計算...等。

ExtJS 本身並沒有附帶 Compass/Sass 工具，需要擴充佈景（Theming）的開發者，需要依循 Ruby 慣用的 RubyGems 安裝方式：

gem install compass

將 Compass/Sass 軟體安裝，之後才能開始客製 ExtJS 的佈景。

這兩篇文章可供佈景開發者參考：

由於 Compass 定義的佈景，有很多擴充方式，但也經常讓初學者摸不著邊際，所以這篇文章稍微整理一下相關說明。

假設專案根路徑是：MyApp

ExtJS 解壓縮後放置的路徑是：MyApp/extjs

所有佈景主題相關的檔案都會放在：MyApp/extjs/resources

客製佈景會需要用到 resources/themes/templates/resources/sass/ 範本資料夾底下的兩個檔案：

config.rb
my-ext-theme.scss

其中 config.rb 是 ExtJS 為佈景開發者準備好的 Compass 設定範本，因此 ExtJS 的佈景並不是從一般的 compass create 開始建立，而是直接套用現成的設定檔（因為佈景產生過程會用到 ExtJS 定義的預設樣式及 Ruby 撰寫的處理程式）。

此時先在 ExtJS 資料夾下建立命名為 custom 的資料夾：MyApp/extjs/custom

再將範本檔案複製：cp extjs/resources/themes/templates/resources/sass/* extjs/custom

新資料夾 custom 的名稱可自訂，但路徑必須在 extjs 下（與 resources 同一層），這是因為 config.rb 裡面用的相對路徑設定；如果放到其他路徑就必須重新調整設定值。

接著切換到新資料夾下：cd extjs/custom

使用 Compass 編譯佈景的方式有兩種：

直接編譯 compass compile
監看異動編譯 compass watch .

如果佈景還在調整的階段，使用 watch 可以免去每次修改都要重新輸入 compile 指令的麻煩。

其中 my-ext-theme.css 的內容就是客製佈景的內容，如果都沒有修改的情況下，就會產生 ExtJS 預設的樣式，也就是淡藍色的佈景。

在 my-ext-theme.css 的內容有一段註解：

// Insert your custom variables here.

在此註解下方就是用來定義新的佈景，但範本檔並沒有提供任何設定可參考。

所以這邊可以先找到 ExtJS 預設佈景的樣式定義： MyApp/extjs/resources/sass/ext-all-gray.scss

把裡面的相關變數宣告複製到 my-ext-theme-css 的定義區。例如：

$theme-name: 'gray';

$base-color: #ccc;

從這個例子中可以看到，預設的 Gray（淺灰）佈景，其實就是利用 $base-color 來定義基礎顏色，#ccc 顏色值就是淺灰色。

如果把 #ccc 改成其他顏色，例如：

$base-color: #ff0000;

上面的修改會讓佈景從灰色變成紅色。

從這邊就能看到 ExtJS 採用 Compass/Sass 佈景的好處，只改了一行，但整個佈景主題會從灰色轉變為紅色，因為利用了 Compass/Sass 的顏色計算功能，在 Ext 各式視窗元件都會依照這個基礎色碼進行深淺度的自動調整。

另一個修改的例子是字型大小，再過去調整 ExtJS 的字型大小相當麻煩，因為不能只改一個或少數幾的地方，若是想加大整體的字型大小，必須把全部字型大小的設定都翻修過，才能維持原有的比例，例如 13px 調到 15px，那麼 11px 就應該調為 13px 等，...

但是在 ExtJS 4.x 的 Compass/Sass 佈景系統中，只要在 .scss 佈景設定中設定一行：

$font-size: 11pt;

其他相關的字型大小，就會以 11pt 為基礎重新計算新的大小，因此能保持佈景原有的字型大小比例。

在 compass compile 動作後，會將 .scss 檔案自動產生對應檔名的 .css，其預設路徑為： MyApp/extjs/css

有了設計好的新佈景之後，在 HTML 的 link 標籤也要替換路徑，將原本使用預設佈景的位址，例如：

/extjs/resources/css/ext-all-gray.css

替換為客製產生的新佈景檔：

/extjs/css/my-ext-theme.css

雖然使用 Compass/Sass 的佈景設計，對仍舊習慣 CSS 的開發者來說，剛開始要上手一點門檻，但其實只要多嘗試一下，就會發現 Compass/Sass 真是網頁開發者的福音，試過就...再也回不去了。

雖然目前還沒有看到太多 ExtJS 4.x 的佈景分享，但是基於 Compass/Sass 設計的 ExtJS 佈景，其實要分享是再方便不過的，因為只要把幾個主要的基礎變數宣告設定分享即可，簡單的修改幾個變數，就能發現整個佈景在視覺上有很大的變化。

IE 不吃餅乾（Cookies）的問題：避免包含底線「_」（underscore）的網址

2012-05-17T11:11:00.000+08:00

包含底線的網址，例如 abc_efg.company.com 雖然也可以用瀏覽器開啟，但是會發生在 Chrome / Firefox 一切正常，但使用 IE 瀏覽器就會無法儲存 Cookie 導致 Session 失效的問題。

從 IEInternals Blog Bugs QA 可以找到以下跟 Cookies 有關的說明：

IE0005: By-design. Setting cookies fails when the hostname of the server contains an underscore.

IE0006: By-design. Setting more than 20 50 cookies per host results in the oldest cookie being lost.

因為底線「_」（underscore）對 DNS 的 Domain Name 規範來說，屬於不合法的符號：

以下清單是 DNS 不允許的符號列表，出自微軟的網頁。

Disallowed characters

comma (,)
tilde (~)
colon (:)
exclamation point (!)
at sign (@)
number sign (#)
dollar sign ($)
percent (%)
caret (^)
ampersand (&)
apostrophe (')
period (.)
parentheses (())
braces ({})
underscore (_)

如果需要在網址中使用分隔符號，可以用「-」（hyphen）。例如 abc-efg.company.com，就能避免 DNS 規則衝突造成的問題發生。

思索下一代程式語言教學系統，利用 Node.js 實作程式碼遠端編譯執行

2012-05-10T22:53:00.000+08:00

長久以來我一直在思考如何實作更好的程式語言的教學系統，目前發展的 PLWeb v2 已經用了五年的時間，而下一個版本會是什麼樣子，怎樣才有更大的躍進，是我每次在夜深人靜時就會不斷在腦海中不停思考的問題，...

PLWeb 程式設計學習網

我對新的程式語言教學系統，有無數個期待：

支援 Eclipse 及 Visual Studio 等各種整合開發環境的教學。
線上編輯教材，以 Markdown 編寫電子書，使用 CodeMirror 或 ACE Editor 提供用瀏覽器撰寫程式碼的功能。
教材自動轉換為電子書。
更好的互動練習環境、支援廣播及即時問答功能的網頁介面。
學習者不必安裝任何軟體（包括編譯器也免安裝），直接透過瀏覽器就能學習（即使是用 iPad 平板電腦也能學）。

最近最有興趣解決的其中一項問題，就是讓程式碼在遠端編譯執行。

這聽起來並沒有什麼困難，因為只要先將程式碼上傳，在 Server Side 只要用 Shell 呼叫編譯程式，就能將執行結果回傳給 Client 端。

但是對於教學來說，許多程式會有 User Input，也就是使用者需要將資料以鍵盤輸入，再交由程式處理回應。

雖然可以將 Input Data 以 STDIN Stream 給執行中的程式，但這樣需要在程式未輸出任何訊息時，就已經將 Input Data 輸入完成，對學習者來說這樣寫好的程式，User Input 就失去意義。

對網頁程式來說，還必須將後端執行中的程式與瀏覽器串接起來，重新導向 STDIN/STDOUT，如此才能讓遠端執行的程式，就像在 Local 端一樣有 Console 的互動操作效果。

近期對 Node.js 的研究，讓我發現 Node.js 是目前最適合用來處理這項需求的方案。

因為 Node.js 有太多好處：

輕量，伺服器負載小，一部機器可承載大量線上使用者。
Socket.io 提供最簡單穩固的 WebSocket 實作，解決瀏覽器和伺服器之間串流執行中程式 STDIN/STDOUT 的需求。
由 chjj 開發的 pty.js 及 tty.js 已經初步完成基本實作的範例。
可以透過 Node.js module 搭配 C/C++ 實作底層所需的程式碼，如此一來 Unix 既有的虛擬終端機介面（Pseudo terminal）就能派上用場。

而多人共用伺服器編寫程式碼、執行程式的安全性問題，則可以透過 Unix 的權限控管，以及搭配虛擬機器來執行（包含網路的隔離等）。

我 fork 了一份 tty.js，並加入一些簡單的修改，大致上完成了程式練習系統的介面雛形，用來驗證這個構想（proof-of-concepts）。專案的網址是：

https://github.com/lyhcode/tty.js

執行畫面如下圖，上方為程式碼編輯區，下方為瀏覽器的 Console 畫面，透過 tty.js 串接在伺服器上執行的終端機畫面；如此一來，即使是包含 User Input 的程式，也可以在遠端編譯、執行，但學習者只要透過瀏覽器就可以完全地控制。

修改自 tty.js 的 proof-of-concepts

雖然 Unix/BSD/Linux 是絕佳的程式開發環境，但是對初學者來說，又要學程式語言又要摸索新的作業系統操作，難免會有太多的阻礙。

但如果透過簡易的 Web UI 介面包裝，讓寫程式變成只要打開瀏覽器，就能立即開始編寫程式碼，按下一個 Run 按鈕後，就自動交由遠端的 Linux 伺服器編譯、執行，同時還能享有跟 Local 端相同的 Console 鍵盤操作、跟程式互動，我想這應該會是更方便的學習環境吧。

Node.js 是有趣的新技術，即使你從未使用過它、未來也不打算用它開發軟體，多瞭解它還是能夠顛覆許多傳統的想法，例如那些過去認為用 Web 做不到或很難做的事情，現在都變得可行而且簡單有趣。

如果你有興趣研究 Node.js，請參考：

Node.js Taiwan Facebook Page http://facebook.com/nodejs.tw
Node.js Taiwan Homepage http://nodejs.tw
Node.js 中文社群電子書 http://book.nodejs.tw

Node.js Rocks!

淺談快速開發網站雛形，從 ContPub 的經驗說起...

2012-05-07T11:18:00.001+08:00

如果使用架站軟體，如 Wordpress、Drupal 或 Joomla，可以找到很多佈景可以套用，例如：

但是自行開發的網站就沒有這麼幸運了，不管是程式或佈景，都必須自己打理。

2011 年 9 月剛開始啟動 ContPub 的專案時，為了讓網站剛開始有個基本堪用的外觀，我從一些網站找來 Free / Open 的佈景。

www.oswd.org
www.openwebdesign.org
www.styleshout.com

套上佈景之後，寫程式會比較快樂，因為網站有基礎的佈景，比較不會像原始文件那樣醜陋；一開始不必花太多時間調整佈景，可以先專注在程式的開發上。

一段時間後問題慢慢浮現，雖然免費的樣板提供 PSD / CSS / HTML 原始檔，可以自行依照需求修改；但是要挑到一個滿意的佈景已經很不容易，更不用說還要講究免費佈景提供的布局和 UI 元件足夠使用。

因此當部分的功能需要用到 Tab、Dialog 時，我用了 jQuery UI 加速開發；這時候網站同時存在基本的佈景與 jQuery UI 的佈景，佈景不一致的問題就浮現了。

接下來為了讓 CSS 的撰寫更容易，我加入了 Compass，剛開始用得很順利，也陸續加入幾個 Compass Plugins；我想 Compass / LESS 對現代網站開發的方便與重要性，就不用在此贅述了，用過的人應該不會想要再用純手工撰寫 CSS 了吧。

由於原本的佈景沒有 Grid System，若要加上 Responsive Web Design 的修改很不容易。

於是我又幫 ContPub 加上 SUSY，但為了讓原本的佈景可以融合 Grid System，花了不少時間做佈景的修改。

在原本的佈景加上 SUSY 並不難，但是要再不同尺寸的螢幕瀏覽都能自動調整布局，就需要加上更多修改，例如 320+Susy 或相似作法等。

這幾天看到由 Even Wu 發佈的 Golden Grid Framework 後，我覺得這才是我想要的 Fluid Grid System + Respinsive Design。

除此之外佈景還有很多問題要解決，例如在使用 Reset CSS 之後，網站的基本樣式（如 Typography）都被清除需要重新定義，...

最後我發現用在調整 Web UI Design 的時間，比真正用來開發網站功能的時間還要多得太多了...

用了一個週末的時間把網站的外觀整個砍掉重練，為了重新開始，我考慮了以下兩種方案：

使用 Compass + Blueprint 可以享受 Compass 的便利，但 Blueprint 若要考慮 Responsive Design 就必須自己多下一些功夫；比較起來 Twitter Bootstrap 是一個更完整的基礎。

雖然 GitHub 可以找到一些 Compass + Twitter Bootstrap 的實作，但考慮到 Bootstrap 本身就已提供 LESS 可以客製外觀，我就不考慮這種混合的作法。

把原本的 CSS / Compass 清除後，大約耗費了10多個小時，才把 ContPub 原有的20多個 View 修改為 Bootstrap 的 conventions。

kippt 這個網站也是使用 Twitter Bootstrap 為基礎，開發者 @karrisaarinen 發表了一篇「Building with Twitter Bootstrap」分享他的經驗談，其中也講到 Bootstrap 的問題：

I think using Bootstrap for prototypes or hackathlons is ok, but if you actually have been using some time and effort to build your app, don’t ruin that by being lazy. Use some time to customize the site for your target users or get a designer to help you a bit.

也就是說使用了 Bootstrap 並不代表網站就不需要 Designer，Bootstrap 雖然預設的外觀相當簡潔也堪用，但是對於正式上線的網站來說，仍要花上許多時間進行客製。

雖然用 Bootstrap 打造的網站，一開始會有相同的外觀，但網站佈景本來就免不了需要請 Designer 特別設計，所以 Bootstrap 的意義就跟它的命名一樣，當網站還處於「bootstrap」階段時，它提供比較周全的基礎設施，讓你的 HTML/CSS/UI Components 有個基本的 conventions 可以參考。

這聽起來是個兼顧現時與未來的作法，讓網站在創立的初期，可以不必太花時間在無意義的外觀調整上（畢竟功能都還沒做完）；等到需要正式上線、有 Designer 支援時，再用比較有系統的方式重新定義客製的外觀。

站在 Twitter Bootstrap Open Source 的基礎上，已經有許多延伸的專案出現，提供 Bootstrap 的佈景主題及客製化工具，例如：

Wrap Bootstrap - Themes for Twitter Bootstrap

Style Bootstrap - Create unique design with Bootstrap v2

網路拍賣的第三方結帳系統不安全請小心下標！

2012-04-26T22:00:00.002+08:00

幾個月前曾在某知名拍賣網站買過一些小東西送人，像是仿 MacBook Air 的化妝鏡；照理說過了幾個月，我應該要忘得一乾二淨才對（年紀到了快三十歲都會出現的小毛病）。

但是，我卻對那次的交易難以忘懷。

這應該開心嗎？不！

那次的購物經驗並沒有令人難忘的經驗，但每隔一個月左右就會有人貼心地打電話來告訴我。

拜託！好心的人吶！別再浪費電話錢打來要我回想這檔小事了。

今天在開會的時候，看到一通 02 開頭的電話，以為又是哪家台北廠商打來、有什麼好康可以挖，所以我就接起電話。

電話那頭：「請問是 XXX 先生嗎？」

ME：「哦！我就是。」

電話那頭：「您記得 X 個月前在我們公司 XXXX 買的商品，...」

ME：「喔喔！我記得啊！」

（還沒等她再開口，我就接下去講。）

ME：「是不是關於分期付款的問題？」

（詐騙集團那麼高利潤的行業，連找個口音聽起來「正」的客服代表打電話有什麼困難嗎？一定要每次打來都是讓人聽了很不酥符的「歐巴桑」聲音就對了。）

電話那頭：「您已經知道啦！那有沒有去 ATM 設定嗎？」

（第一次遇到沒掛我電話還繼續喇嘞下去的詐騙集團。但聽這不酥符的聲音，實在讓我沒什麼興趣再接下去講，...）

ME：「處理好啦！」

（掛斷電話...嘟......）

我一直以為詐騙集團應該都是很聰明的人在經營的行業，照理說應該要隨著科技日新月異，手法層出不窮；但每個月打來騷擾我，至少也找個聲音聽起來賞心悅目，讓人家有一點遐想空間的專業電話客服嘛！聽到沙啞歐巴桑聲音，而且不帶一絲台灣人講話的人情味，更不是打來報明牌，這就叫人火冒三丈！

但我認為詐騙集團只是老鼠屎其中的一沱，這整個問題背後，不是詐騙集團的首腦和歐巴桑聲音的小姐合謀就能搞定；問題的根源還是在於資料外洩。

因為有好心的詐騙集團每月按時提醒，我一直清楚記得當初是怎麼下標、購買網拍商品。

那家店基本上按照著拍賣網站的規定經營，照原金額下標，沒有什麼偷雞摸狗的走偏門行為。

但是在完成下標後，賣家提示必須到 XXX 網站填寫表單，這就是所謂的第三方結帳系統。

我並沒有仔細閱讀「關於我」的習慣，有少數賣家把很多重要的資訊都寫在「關於我」，但是又用了很不明顯、沒有標明重點的字體，然後內容寫得落落長。但我不是下標後發現手續很麻煩就想棄標的買家，雖然賣家強制規定一定要填寫結帳系統才出貨讓我覺得不太方便，最後當然還是得守信用完成交易。

大概在 8~10 年前，即使是最多人用的拍賣網站，功能還是相當不全，下標後必須靠著電子郵件及電話的聯繫，才能完成付款核對、出貨通知。

所以那時候的第三方結帳系統解決很多問題，像是詳細商品內容選項、核對付款資料、訂單處理狀態查詢、物流追蹤、更新狀態訊息通知等等，補足了拍賣網站功能的不足。

但其實第三方結帳系統並不安全，特別是我在接二連三接到疑似不同詐騙集團打來的電話，資料來源都是同一個賣家，而且這個賣家就是必須使用第三方結帳系統才出貨，這讓問題的根源變得相當明顯。

我不覺得目前最大的幾家拍賣網站，已經能做到滴水不漏的100%安全保證，對軟體開發及資訊安全有些興趣，使我瞭解百分之百的安全根本不存在，除非網站不是由人開發的。

不過近幾年來，因為資安問題造成個資外洩的問題太嚴重，因此比較大型的幾個主要拍賣網站，已經用了很多辦法想解決問題。看起來是有些成效，每個月多次使用網拍購物的經驗，近來已經鮮少遇到交易資料外流而接到詐騙電話，除了少數「強迫使用第三方結帳系統」才能完成交易的店家。

如果使用外部的結帳系統，可以讓交易過程更方便，那也就算了。但最近的使用經驗是，這些第三方結帳系統，介面很難用、操作過程很麻煩、已經下標的商品還要手動輸入一次資料。這實在令人費解為何少數賣家，仍堅持要買家在下標後使用其他網站才能結帳。

目前主流的拍賣網站，都已內建了合併結帳、詳細規格選擇、交易付款機制、出貨通知等，也提供相對較好的交易安全保障。

所以，我想請還在堅持使用第三方結帳系統的賣家，請花點時間學習拍賣網站的功能，不要再為了自己方便堅持使用過時的結帳機制。

如果你是買家，在網拍買東西時，請注意賣家是不是一定要用第三方結帳系統才能交易。如果是的話，請考慮一下個人資料、商品交易明細在網路裸奔可能帶來的後遺症。

入圍 2012 全國開放軟體創作競賽 - 雲端網際服務與其他應用產學合作組

2012-04-10T09:53:00.000+08:00

嘿嘿，我們進入決賽了！為了我今年最想要的 Herman Miller Embody Chairs，接下來有得忙碌一整個月啦！

HITACHI RD200-FN 入手，跟霉味說掰掰，除濕機

2012-04-09T17:01:00.000+08:00

前陣子相信不少人家裡都被濕氣侵擾，住在中南部我還是第一次遇到家裡頭濕答答，不管開窗、開冷氣機下去除濕，好像效果都很有限。

這是俗稱的「透南風（吹南風）」現象，氣象站則表示，這是因為鋒面過境，高溫的西南風含的水氣濃度高，接觸低溫地板及牆壁而凝結成水，產生「反潮」。濕度高，急性呼吸道病患就診也增加約二成，醫師提醒民眾開冷氣及除濕機，並要小心滑倒。（自由時報）

我比較擔心發霉的東西，其實只有攝影器材和音樂光碟，因此也買了三個電子防潮箱；除此之外，倒沒有特別想過除濕機的需求，總覺得只要常開窗通風、偶爾開冷氣機除濕就夠了。

但是三月份的時候，經常在家裡嗅到霉味，尤其是在現在這種怪天氣，三不五時下一陣大雨，之後又出大太陽，就會讓家裡濕氣霉味都跑出來。這讓我開始有點擔心滿屋的 3C 產品、書籍，也開始考慮除濕機的需求。

在爬文之後，發現不少人推薦 HITACHI、MITSUBISHI 的除濕機；除濕機的價格至少都要五、六千起跳，日系的售價和便宜品牌比較起來，也不會相差太多，加上個人對品牌的偏好，就決定買 HITACHI。

從廠商型錄網站，就可以清楚知道各種型號。 Y! 拍搜尋一下型號，就可以知道售價範圍（網拍的售價大部分都要打電話過去議價）。

以外型來說，我比較喜歡 RD-16/RD-12 的設計；但是努力搜尋一下台中的家電行，才發現三月買除濕機並不是好時機，因為到處都缺貨。

最後我是在斗六的店家找到 RD-200FN 的現貨，而且僅有一台，完全沒得挑，考慮了一下就搬了台回家。

以 RD-200 來說，FB/FN 是最新上市的機種，屬於能源效率一級。在能源標章網站可以搜尋想買的家電檢測結果，畢竟新舊款價格沒差多少，當然要選比較省電的。

RD-200 的面板看起來有點複雜，但其實功能就那幾個，選擇模式、風速和定時

側面的出風口打開後，會切換成乾衣模式，可以針對小範圍進行快速除濕

RD-200 的水槽是5公升，在房間用大約12小時要倒一次水，背面可以接排水管

下過雨後家中濕度會超過85%，雨停後除濕10小時後可降至60%以下

以中南部來說，我家公寓大約35坪左右，四房二廳只要買一台 RD-200FN 就已足夠應付，因為房間濕度降至50%，只要沒再下雨就可以連續維持幾天，各個房間輪流用就可以維持在舒適的濕度。HITACHI 除濕機底部有滑輪的設計，可以很方便移動。

使用後我發現不管家裡濕氣問題嚴不嚴重，其實買台除濕機都會很管用，例如廚房的櫥櫃、客廳和臥室的鞋櫃、櫥櫃及系統櫃，還有很怕發霉的衣櫃，以及家裡舖設的木地板，只要定期進行除濕，就可以去除討厭的霉味；有時候可能自己覺得霉味不嚴重，但其實只是已經習慣味道了 :XD

解決 Google Chrome 瀏覽器不能正常播放 Flash/SWF 檔案問題，Ubuntu Linux

2012-04-08T20:07:00.003+08:00

這個網址是 Adobe 提供的 Flash Player 測試網頁，如果看到下圖右下方的版本資訊，表示 Flash 播放器正常運作。

http://www.adobe.com/software/flash/about/

在 Chrome 瀏覽器網址列輸入「chrome://plugins/」，並切換「詳細資訊」檢視。

找到 Flash 的設定，將 Adobe 以外的 flash plugin 都停用。

Ubuntu 如果沒有 /usr/lib/adobe-flashplugin/libflashplayer.so 這個檔案，需要用 apt-get 補安裝：

sudo apt-get install adobe-flashplugin

無為草堂人文茶館，台中，食記

2012-04-07T19:33:00.002+08:00

在嚴長壽的「我所看見的未來」書中，對台中的「無為草堂」讚譽有加。利用春假五日連假，帶著家中愛泡茶的兩老尋訪無為。這間茶館很特別，附近是高樓林立的都會叢林，從勤美誠品為起點，公益路是台中特色美食的精華路段，走到大墩路也差不多到了美食商圈的盡頭，而路口瞥見藏在林蔭中的古厝，就是無為草堂。

在這裡我第一次學泡茶，聽著阿爸講著他三十年泡茶經驗的心得。

傳統茶道對青年人來說愈來愈陌生，畢竟，到春水堂點個特大杯冰茶，或是在星巴克點杯熱咖啡，實在比泡茶方便多了，畢竟很難打開 MacBook 一邊寫 Blog 或上 Facebook，又一邊注意著煮熱開水、沖泡茶葉。

如果想要休息、放鬆一下，我認為到無為草堂是個相當不錯的選擇。這裡大多座位區都規劃成塌塌米的小包廂，可以在較不被打擾的空間下喝茶聊天，而窗外的景致就像時空倒退百年，綠蔭、鯉魚池、閣樓、涼亭、屋瓦木身取代水泥建築，就像回到手機、電腦還沒發明的年代，籠罩在充滿閑情逸致的氛圍。

無為草堂位於公益路與大墩路交叉處，特約停車場就在大墩廣場燦坤3C旁邊。

地址：台中市公益路二段106號

電話：04-2329-6707

入門程式設計的好工具 Processing

2012-04-06T23:19:00.004+08:00

Processing 打造一個簡單易用的程式語言，即使不懂程式設計的新手，也能剪剪貼貼、依樣畫葫蘆動手完成有趣的程式。有趣是個重點，使用 Processing 寫程式就是比其他語言更有趣，因為它著重在「繪圖」，讓你天馬行空的創意能夠藉由撰寫程式發揮出來，讓每個人都能發揮與生俱來的創造藝術能力。

Processing 的起源是 Ben Fry 和 Casey Reas 於 2001 年在 MIT 發展，它以視覺化的方式，讓學習者撰寫電腦程式，就像在畫素描一樣，而 Processing 也將程式碼保存在稱為 Sketchbook 的區域。

O'Reilly 最近出版的一本新書「Processing 入門：互動式圖形實作介紹」（中文版），就是由 Ben Fry 及 Casey Reas 親自撰寫，將這套好用的軟體正式介紹給學習者。

這是 Processing 網站的一段介紹：

Processing is an open source programming language and environment for people who want to create images, animations, and interactions. Initially developed to serve as a software sketchbook and to teach fundamentals of computer programming within a visual context, Processing also has evolved into a tool for generating finished professional work. Today, there are tens of thousands of students, artists, designers, researchers, and hobbyists who use Processing for learning, prototyping, and production.

安裝 Processing 超級簡單，以 Mac OS X 版本來說，只要下載解壓縮後，拖曳到 Dock 即可使用。

打開 Processing 的主程式，在畫面的編輯區就可以開始寫程式。

學習 Processing 不必先搞懂艱澀的邏輯或語法，從 Example 開始入門就對了，開啟選單「File / Examples」，隨意選擇喜歡的範例程式，開始執行。舉例來說，範例內建的 ColorWheel 執行後會出現這張圖形。

Processing 常見的指令，都與繪圖相關，例如：打開一個寬高各為200的畫布，繪製一個橢圓形，(x, y)座標是(50, 50)，寬度及高度皆為80。

size(200, 200);
ellipse(50, 50, 80, 80);

當我們想要向教導 for-loop 迴圈的概念時，就可以將程式邏輯與圖形結合起來：

size(200, 200);
for (int i = 0; i <= 50; i+= 10) {
ellipse(50, 50, 80, 80-i);
}

上面的程式執行後，會產生以下的圖形結果。當學習者動手修改常數或變數，或是加上其它的繪圖指令，就會得到不同的結果。這些結果使用我們人類大腦更樂於接收的「視覺化」方式呈現，有更多學習的樂趣，也可幫助思考，畢竟對許多人來說，要把 printf 印出的一大堆文字和程式的邏輯聯想起來，並不是一件容易的事。

別以為 Processing 就只會「繪圖」的語言而已，它最重要的特色就是能打造「互動式圖形程式」，也就是能用視覺化的圖形來回應使用者的操作，例如可以根據滑鼠游標的位置，來產生一連串的動畫效果。

學習 Processing 只要放輕鬆、當做一種玩樂，每寫幾行、修改幾個字，就馬上執行一下看看效果，多觀摩別人寫的有趣程式，充分發揮自己的想像力完成，說不定寫壞、寫錯的程式還能得到意想不到的效果，畢竟學習就是為了好玩（Just for fun）。

利用 Processing 學習電腦程式的風潮遍及全球，也有許多課程將它納入教學大綱、甚至開設專門教導 Processing 的課程。

比起 C、Java... 等大學課程普遍教導的程式語言，其實 Processing 更適合初學者入門；就像過去很多人曾經使用過 LOGO、BASIC 寫程式的經驗，只需要輸入一些指令，按下執行就會立即跑出結果，既簡單又有趣。

雖然學會 Processing 可能沒辦法讓你順利找到一份寫程式的工作，你可能也沒辦法利用 Processing 開發一個網站；但是對於初學者來說，樂趣其實比其他一切都更加重要；如果學習者沒辦法對寫程式一見鍾情，無法發掘自己的潛能及熱誠，而硬生生被填鴨一堆程式語言、資料結構及演算法的科目，最後可能也不會有熱誠想從事程式設計工作。

由於 Processing 是開放源碼的軟體，在很多人的支持下，很快就出現各種教學、範例或應用。我認為有一項相當重要的延伸，也就是 Processing.js，它是將 Processing 移植到瀏覽器中執行。

Processing 的 2D/3D 繪圖需要 PostScript、OpenGL 等相關軟體，原始的 Processing 需要下載安裝到電腦中，利用 Java 才能執行。但是近年 Web 及瀏覽器技術的快速發展，HTML5 帶來的 Canvas 及 WebGL、搭配速度飛快的 JavaScript，在大能的 jQuery 創始者 John Resig 原力催化下，誕生 Processing.js 這個可以在瀏覽器中執行的 Processing 相容版本。

執行 Processing.js 需要瀏覽器支援，除了 IE 以外的大多數新版瀏覽器，幾乎都能順利執行 Processing.js，只要測試一下開啟這個網頁，如果能看到範例執行成功的圖形，就代表瀏覽器可以支援 Processing.js。

雖然 Processing.js 支援大多的 Processing 語法及功能，但畢竟瀏覽器是個相對受限制的環境，並非所有 Processing 程式都能被移植到 Processing.js。但是對於教學來說，它的功能已經相當足夠。

Processing.js 帶來很多新的應用可能性，例如 sketchpad 就是以 Processing.js 為基礎的線上編輯器，用瀏覽器打開網頁就能直接寫程式，而執行結果也會立即顯示在網頁上，包含互動式效果也能支援。

這個連結是我用 sketchpad 產生的頁面（畫面如下），程式碼來自 Processing 的 Arm 範例，使用瀏覽器就可以直接觀看、執行這個程式。

使用瀏覽器就能撰寫、執行 Processing 程式，方便學習者互相交流分享與觀摩，由於 Processing 視覺化的特性，讓程式在分享的同時，除了程式碼還會附帶有趣的圖形。這是其它使用者透過 sketchpad 建立的程式，使用相簿的方式展示。

不久前 codecademy 打造了一個只要瀏覽器就能上網學寫程式的平台，有全球超過百萬位學習者上線使用；若使用 Processing 設計教材將會相當有趣，可以一步步教會初學者自己寫程式，並且動手「玩」自己做出來的程式，還能將成果分享給別人。這種帶有藝術創作性質的成果，讓學程式設計也能做出平易近人的作品。

除了瀏覽器，iPhone / iPad 也有專屬的 Processing App，雖然拿手機或平板電腦寫程式有點累；但 Processing 程式簡單易寫，而且通常都是小片段，搭配藍牙鍵盤，或許就能用等公車或喝咖啡的時間學寫程式。

最後，我想再稍微介紹一下 Processing 的胞兄弟「Arduino」。

Arduino 與 Processing 的理想十分接近，如果說 Processing 讓「設計軟體」變得有趣，那 Arduino 就是讓「設計硬體」變得平易近人。

Arduino 是開放式硬體平台，它就像積木一樣，不懂電子的麻瓜，也可以將價格便宜、組合容易的各種電子零件組裝起來，搭配各種感測器（如：溫度、光線、顏色、距離等）、裝置（如：馬達、伺服機等），創造出有趣的應用。

把 Arduino 與 Processing 結合起來，正是 Casey Reas 與 Ben Fry 在書末介紹給讀者的內容。在過去，如果想要打造一個軟硬體整合的裝置，將環境光源與溫濕度變化繪製成 3D 動態影像，多數人可能會覺得這相當科幻，而理工背景的人雖然覺得做得到、但可能太麻煩，但 Arduino + Processing 激盪出的火花，讓這些將科技帶入生活的創意應用，變成像積木玩具般既容易又有趣。

以下是取自 YouTube 的一段 Arduino + Processing 影片，希望讓你也能有「動手玩科技、解放創造力」的想法。

測試網站是否投入長城懷抱了？

2012-04-05T21:13:00.000+08:00

GFW（長城防火牆，Great Firewall）是中华人民共和国政府為了「和諧」建造的網際網路過濾機制；以本網誌來說，因為使用 Google Blogger 服務架設，長期以來都是處於「被和諧」的狀態，偶爾有少數翻牆過來的訪客，但數量真是稀少 : )

經常有人問我怎麼知道自己的網站是否「被和諧」了，所以特別將用於測試連線的網站整理如下：

http://www.websitepulse.com/help/testtools.china-test.html

http://www.greatfirewallofchina.org/

當然，這種網站是給身於牆外的我們測試，其結果也僅供參考。

但如果對方有人可以幫忙，或者可以遠端連線到對方機器，其實最準確的方式，應該是透過網路除錯工具，例如 nslookup、dig、ping、traceroute/tracert、nmap...等，才能知道哪個節點出錯了。

即使網站目前沒有「被和諧」，也不必高興太早；因為網站經營在中华人民共和国必須有政府許可，稱為ICP（中华人民共和国电信与信息服务业务经营许可证），如果沒有合法的經營管道，就別想賺人民幣啦！就算現在網站可以通，也難保哪天睡一覺醒來，長城就把你的網站包圍了。這就是現實...

筆記：Amazon S3 及 CloudFront 費用計算

2012-04-04T14:45:00.001+08:00

今年開始陸續將一些 Web 搭配 Amazon S3 / Cloud Front 雲端服務，除了先前文章中談過的 CDN（放置 Web Static Assets，如 CSS/JS/ICON...）用途外，我也嘗試使用 S3 + CloudFront 提供以下檔案的儲存與傳輸加速。

PLWeb.org 的程式碼編輯器（單一 USER 的下載量約 9.3MB）
ContPub.org 的電子書（每本電子書的容量約 300KB 至 3MB）

使用 S3 + CloudFront 的好處很多，例如取之不盡用之不竭的傳輸頻寬（實測幾乎都有大於100Mbps）、儲存空間（就算大於10TB也沒問題），也不必擔心負載過量的問題。網站以 Web-based 架構建置，搭配 S3 + CloudFront 處理使用者上下傳檔案的部分，就可以輕鬆享受以下的好處：

網站及資料庫本身仍可架設在自有的伺服器，僅檔案部分交由 S3 + CloudFront 處理。
輕鬆享有與跨國企業同級的頻寬，超過 100Mbps 的上傳頻寬，以種花電信的企業型光世代固定制方案來說，光是 5Mbps 的上傳頻寬就要月付近 2000 元，而且還不是很穩定 : )
輕鬆享有與跨國企業同級的機房，S3 有良好的 HA（高可用性），Amazon 宣稱可達 99.999999999% durability and 99.99% availability。
透過 CloudFront 建置的內容傳遞網路，在世界多個國家都能享有良好的檔案傳輸速度。
S3、CloudFront 沒有分級，不管中小企業或跨國大企業，都是享有同樣的高規格服務，而且是依使用量計費。
S3 比起一般自建的伺服器更可靠，畢竟備用電力、備援網路、防災防震、異地備份這些建置費用太過昂貴；但為了避免極端的意外發生，S3 的使用者，也可以購買一般的高容量硬碟或 NAS，定期將檔案同步備份。
S3 提供足夠的頻寬，可以滿足需求的變化。例如網站可能在某個時期需要極高的頻寬（例如100Mbps），但平時大部分時間只需要很低的頻寬（例如1Mbps），為了保證服務的品質，可能需要為了短時間的需求租用100Mbps，但大部分的時間頻寬都是閒置，雲端的儲存服務則可以解決這種過度投資帶來的浪費，你需要多少頻寬，它就給你多少，依照實際用量計費。

即使這些好處看得到也吃得到，但是，我們更關心的：到底要付出多少錢？Amazon 公告的 Pricing 很詳細，但也讓人看得霧煞煞，心裡冒出不少問號。

這個月我終於收到一筆超過 $10 USD 的帳單，可以檢視 S3 及 CloudFront 的實際收費 : )

這是3月份 PLWeb.org 的造訪人次，因為是會員制網站，實際訪問量並不高，但其中有九成會執行檔案下載動作。

主要的費用是 CloudFront 的傳輸費部份，因為網站的主要使用者來自台灣，所以費用都落在亞太地區（東京或新加坡）。CloudFront 會自動選擇網路距離比較近的機房，其中大部份都來自東京，實測的結果種花電信到東京機房的傳輸確實比較快。從費用說明可以看到，費率高低是：東京 > 新加坡 > 南美 > 歐洲 = 美國。

雖然我的 CloudFront 檔案來源是 S3，但 S3 的部份幾乎沒產生什麼費用，一部分的原因是 AWS 第一年有免費的儲存容量額度，而 Request 的費用則相當低廉。

如果需要傳輸量的明細，AWS 也提供 Usage Report，格式包含 CSV 及 XML。

這是 CSV 版本的明細範例，列表是該月每天的流量狀況。

因為 AWS 目前沒有漂亮的圖形化 Usage Report，用慣 Google Analytics 的網站經營者，可能會想要這種一目了然的簡潔報表，這個畫面是 S3STAT 網站，月付 $5 USD 的價格，就可以得到更 friendly 的報表。

在計算過後，我目前考慮先取消部分的 CloudFront 服務，因為單月 55GB 的傳輸量都落在亞太區，產生的費用是 $10 USD 左右；若是把這個費用加到 Linode，則可以從 Linode 512 升級成 768 方案，傳輸額度就會比原本的 200GB 增加為 300GB，即增加了 100GB 的額度，而 Linode 機房選擇在東京，對亞太地區的傳輸速度也已能夠滿足了。

Ubuntu 12.04 帶來全新 HUD 選單介面設計

2012-04-04T10:12:00.001+08:00

令人期待的 Ubuntu 12.04 採用改良後的 Unity 5.0 桌面，應用程式的捷徑更容易找到，操作方式更貼近使用者的思考。全新的應用程式選單設計也值得注意，新的選單設計被開發團隊稱為 HUD（Heads Up Display），此舉又為 Ubuntu 桌面系統帶來獨具風格的創新設計，先不管使用者是否能接受改變，能夠看到 Linux 桌面系統走出自己的路，就是一件令人欣喜的事。

HUD 的中文通常翻譯為「抬頭顯示器」，也就是航空或汽車駕駛艙，將儀表重要資訊投影在屏幕，讓駕駛者不必低頭觀看儀表板，就能在注視前方專心駕駛的同時也能獲悉重要資訊的回饋。

用於駕駛艙的抬頭顯示器（HUD）

既然應用程式的選單設計也稱為 HUD，顧名思義就是要讓使用者在專心操作應用程式時，不會被傳統選單打擾思緒。傳統的選單設計有什麼問題呢？當應用程式功能愈強大、選單功能愈多時，使用者就只能從分類中尋找需要的選項，有時候選單不會只有一層，如果想要加快操作速度，就必須記憶快捷鍵。回憶一下早期的 Office 2000/2003，應該就很容易瞭解複雜的選單是什麼樣子，而 Office 2007/2010 的全新介面也刻意將傳統選單隱藏起來。

這幾篇文章可以快速瞭解 Ubuntu 帶來的 HUD 設計。

我認為一般使用者應該能逐漸接受這種新的設計，因為「搜尋」已經成為使用電腦的一種基本操作行為，例如，我們通常不會記住網址，即使是常用的網站，通常還是會在瀏覽器的網址列、搜尋列，或者進入 Google/Yahoo 搜尋畫面後，打入部分的關鍵字進行檢索，因為愈來愈聰明的搜尋演算法，通常只需要很少的關鍵字就能找到想要的網站，比起從分類、我的最愛/書籤中找網站，直接打關鍵字找網站通常更迅速，甚至關鍵字還沒打完就能找到需要的網站。

而這個搜尋的行為已經被用在新一代作業系統的應用程式捷徑目錄，例如 GNOME Shell 或 Unity 的應用程式目錄，只要鍵入「term」就能找到「GNOME 終端機」之類的捷徑。

用鍵盤輸入簡短的幾個字母進行搜尋，對大腦來說相當直覺，因為我們需要使用某一項功能時，大腦已經浮現出關鍵字，若直接經過雙手輸入幾個字就能找到功能，效率就會非常高、不太會打斷思考；而傳統的作法則多了很多步驟，我們需要先將手移開鍵盤開始操作滑鼠，大腦此時必須暫停已經專注的思考，開始回想要怎麼找到這個功能，有時還可能要花上一些時間尋找。對許多需要大量操作鍵盤的工作來說，不斷使用滑鼠只為了操作選單，對工作效率確實帶來負面影響。

當然，並不需要將 HUD 定義成「取代」傳統選單的設計，它只是提供使用者另一種快捷的操作方式。有很多時候熟記快捷鍵可以得到更高的效率，有很多功能一時可能也想不到要用什麼關鍵字尋找（特別是對中文使用者來說）。

這是 Ubuntu 發佈的 HUD 介紹影片： Introducing the HUD to Ubuntu

若想要體驗 HUD 的功能，可以先安裝或升級到 Ubuntu 12.04，HUD 是系統已經預設啟用的設定，使用方法是在應用程式畫面操作時，按下鍵盤的 ALT（輕按一下就放開，否則會變成選單出現在系統列），之後就能輸入關鍵字（英文字母）來尋找選項。

在文字終端機模式下，可以用以下指令加裝套件，就能使用 hud-cli 指令啟用文字介面的 HUD 功能。

sudo apt-get install indicator-appmenu-tools

不過有點可惜的是，目前 hud-cli 並無法正確支援中文，會有出現亂碼的情形。

筆記：減少 JSON 資料體積

2012-04-02T22:04:00.002+08:00

將 Database 查詢的 Result Set 完整回傳到 Client/Browser 端，通常會使用 JSON 及 XML 兩種格式，若是用於網頁的 AJAX，比較好的作法是 JSON，體積稍微小一些，接收端的解析速度也快。

若以 API 形式設計資料存取服務，則可以使用路徑來區別回傳格式，例如：

/service/readData.xml
/service/readData.json

利用 MVC 框架提供的 Route 自訂功能，可以讓 Server 端程式自動依照網址指定的格式處理回傳資料。

由於 JSON 是文字型態的資料，且大量資料容易有重複的情況，將產生的資料經過 GZIP 或 DEFLATE 壓縮處理，可以節省不少傳輸時間及頻寬。

Apache 伺服器可以搭配 mod_deflate 模組。
Nginx 可以搭配 HttpGzipModule 模組。

若不透過伺服器，利用 Web App 本身的 GZIP 模組也可以達到壓縮效果。

PHP 可使用 ob_gzhandler。
Node.js 可以搭配 zlib 及 gzippo（靜態檔案），關於 zlib 可參考我提供的範本。

當然，JSON本身的資料格式也有機會壓縮，例如：

[{a: 1, b: 2, c: 3},{a: 2, b: 3, c: 4}]

這個 JSON 範例資料，可以看到在每一筆 row 都重複了 a, b, c 的 field 名稱。HPack 及 CJSON 兩個演算法的目的，就是要壓縮這種形態的資料。

使用 HPack 與 CJSON 演算法來壓縮 JSON

其中 HPack 已經更名為 JSONH（Homogeneous Collection Compressor）。

JSONH 的壓縮效果相當好，搭配 GZIP/DEFLATE 可以達到相當不錯的壓縮率。

JSONH 在 Server 端提供 Ruby / Python / PHP 函式庫，將資料經演算壓縮後，丟給 Browser 端，再使用 JavaScript 的函式庫還原成原始的資料。照理說 JSONH 的 JavaScript 有機會給 CommonJS/Node.js 使用，也就是同時用於 Server/Browser 兩端（這個假設尚未驗證）。

在 ExtJS 的 Data Reader 中，有 XML、Array 及 JSON 三種，先不管 XML，其中 Array 及 JSON 其實都是同樣的 JSON 結構，只是 Array 並不包含 field 名稱（也就是說 JSON Reader 是 Array 裡面裝 Object，而 Array Reader 則是 Array 裡面裝 Array）。

Ext.data.reader.Array
Ext.data.reader.Json

以這兩種 Reader 來說，大部分情況都建議用 JSON Reader，因為回傳的資料可以透過 field 名稱索引出對應的資料，但 Array Reader 就必須依賴陣列中元素的先後次序來映射資料。

但是遇到資料量非常大、卻又需要一次全部讀取到 Client 端（保存到 ExtJS 的 Data Store 中），就可以考慮用 Array Reader，兩者的資料體積可能相差非常多。

快測試升級 ExtJS 4.1 RC1 吧！

2012-03-30T13:47:00.004+08:00

若專案已經升級至 ExtJS 4.0.7 的朋友，可以開始進行 4.1 的測試了。目前 ExtJS 4.1 已經進入 RC1（Release Candidate），也就是即將正式發佈前的最後幾個測試版。

What to Expect in Ext JS 4.1
http://www.sencha.com/blog/what-to-expect-in-ext-js-4-1/
http://blog.csdn.net/tianxiaode/article/details/6683215 （簡體中文）

Ext JS 4.1 Update
http://www.sencha.com/blog/ext-js-4-1-update/

Ext JS 4.1 Performance Preview
http://www.sencha.com/blog/ext-js-4-1-developer-preview/
http://blog.csdn.net/tianxiaode/article/details/6903580 （簡體中文）

ExtJS 4.1 最值得關注的地方在於它對性能的優化；雖然只要改用 Google Chrome 或新版的 Firefox，速度就能得到很的改善，但只要 IE6-7-8 還活著的一天，網站開發者的頭痛問題就難以得醫治。雖然 4.0.x 比起更早的版本，已經在速度方面獲得改善，但 ExtJS 4.1 將會更進一步提昇性能，特別是在 IE 瀏覽器上，以下的圖表可以說明目前的測試結果（ExtJS 4.1 v.s. 4.0.7）。

這使 ExtJS 打造的應用程式，可以用更短的時間完成載入，即使是侏羅紀時代的 IE6 恐龍瀏覽器，也有顯著的效能改善。

除了速度的改善，伴隨 ExtJS 4.1 而來的還有全新 Neptune 佈景主題。

目前 ExtJS 4 除了內建的兩套佈景外，幾乎無法找到其他可用的佈景主題，相較之下早期的版本就有較多佈景可替換。

但 ExtJS 4.x 在佈景的部份其實相當先進，它加入 SASS & Compass 的支援，讓視覺設計師更容易客製佈景。

但問題來了，ExtJS 4.x 預設的 Classic 佈景，是模仿視窗外觀所設計，如果以這種佈景為基礎，其實調整外觀的幅度會受到限制，除非砍掉重練。這一點只要看看過去早期版本的佈景，就會知道各佈景之間的差異有多麼少數。

新的 Neptune 佈景主題可以在 Kitchensink 範例看到：
http://dev.sencha.com/deploy/ext-4.1-pr1/examples/kitchensink/index.html

有了 Neptune 終於讓 ExtJS 看起來比較像 Web App，而不再是仿視窗的外觀設計。

所以，在升級 ExtJS 4.1 之後，外觀就可以改以 Neptune 為基礎，並交由視覺設計師以 CSS3 / SASS / Compass 客製出更獨特的風格，光是字體的調整就比過去更有彈性（ExtJS 官方也開始使用 font-face / woff 字型），減少像 Classic 佈景調整後變得支離破碎的情形。

但是從 ExtJS 4.0.7 升級到 4.1，過程是否能 "無痛" 呢？以目前初步測試的結果發現，並沒有發現太大的問題，但需要再細部調整的小問題仍是不少。趁著正式發行前還有一段時間可以慢慢研究，趕快準備好升級吧！

Blitz 雲端網站壓力測試服務（Load Test）

2012-03-30T12:34:00.003+08:00

Blitz 是針對網站「壓力測試（Load Test）」需求打造的雲端服務，可以協助開發者評估及改善網站的效能。

Blitz
http://blitz.io/

Blitz 依照需求分級收費，但註冊之後可以得到免費的額度，免費方案可以模擬 250 使用者在一分鐘內對網站進行存取。如果要模擬 1000 位以上使用者（目前最高可達5萬）、一小時以上的測試，就必須以信用卡付費。

Blitz 可以用 Google 或 Facebook 帳號登入，接下來就可以開始 Play！

為了測試 Blitz 的功能，我使用 Cloud Foundry 建立一個 Ruby Sinatra 的 Web App，網址是「http://loadtest.cloudfoundry.com/」。開始使用 Blitz 需要先將網址輸入，它會驗證這組網址是否正常回應。

看到 *** MS 的回應及 HTTP/1.1 200OK，表示 Blitz 存取這組網址沒問題，但此時還沒有進行壓力測試，需要點一下「-p 1-250:60 http://loadtest.cloudfoundry.com」這行指令，加上 -p 1-250:60 代表進行最高 250 位使用者的測試，期間為 60 秒。

雖然點選指令以後就會開始執行測試，但第一次測試會回應失敗，因為 Blitz 必須防止壓力測試被濫用，否則壞心人士只要拿 Blitz 就可以惡意攻擊別人的網站。所以需要增加一些網站的設定，證明這個網站是接受 Blitz 進行測試。

相當幸運地，Blitz 預設提供的驗證程式碼，就是 Ruby Sinatra 專用。非 Sinatra 的使用者，只需要以 mu................. 這組驗證碼當做檔案名稱，建立一個包含數字驗證碼的文字檔，放在網站的根目錄下方。以這個例子來說，只要讓 http://loadtest.cloudfoundry.com/mu-2f5eccb1-0338f64d-6d88faad-74d6c823 能夠回傳數字 42 就是可以通過驗證。

get '/mu-2f5eccb1-0338f64d-6d88faad-74d6c823' do
'42'
end

改完程式碼發佈後，再用 Blitz 進行測試；當測試開始進行，Blitz 可以將即時結果以超炫麗的 HTML5 圖表繪製出來。

以這個測試結果來說，網站很順利通過模擬 250 位使用者的壓力測試，測試是從 1 位使用者開始一直增加到 250 位結束，而回應時間都維持在穩定的 250ms 左右；當然，這個結果是可以預期的，因為 Cloud Foundry 是雲端 PaaS 服務，如果連 250 人都撐不住，那就太不可思議了。

最後 Blitz 會產生報表，可以列印出來。

在價格的部份，若要達到一般高負載網站常用的標竿「C10K」測試，每小時收費為 $39 USD，大約是 1200 元台幣。

若不透過 Blitz 的服務，而想要達到相同等級的測試，一般來說單靠開發者自己的電腦及頻寬可能不夠。常見的解決方案也是採用雲端的方式，例如利用 Script 建立 Amazon EC2 虛擬機器，自動建立測試需要的軟體環境及佈署測試端軟體，在利用多部虛擬機器及 Amazon 充沛的頻寬進行壓力測試；但這樣算下來，也需要花費不少虛擬主機租賃費用及開發測試程式的工時，除非經常需要進行壓力測試，否則只有在少數時候才進行網站調校所需的測試，也許使用 Blitz 之類的雲端服務會是相對划算的選擇。

Amazon S3 及 CloudFront Web Hosting 設定說明

2012-03-30T11:46:00.002+08:00

Amazon S3（Simple Storage Service）是雲端儲存服務，它除了可以當做網站上傳檔案、影音媒體的空間外，本身也相當適合靜態網站（Static Web Sites）使用。例如以 Jekyll 或 Dreamweaver 產生的靜態網站，放在 S3 就能以「用多少付多少」的價格架站。

第一次使用需要先註冊、填寫信用卡資料，http://aws.amazon.com/console/

使用個人帳號登入 AWS（Amazon Web Services） Console（線上管理工具）

除了 S3 也能使用其他 AWS 服務，如 EC2、CloudFront

選擇 S3 服務

建立新的 S3 Bucket，名稱可以輸入自己購買的網域名稱（自定域名），已台灣來說目前速度最佳的機房位置是東京。

使用 Upload 或 s3cmd 將檔案上傳至 Bucket

打開「Properties」、點選左邊列表的 Bucket，即可設定屬性。將 Website 的功能 Enabled 打勾，並設定 Index/Error 網頁名稱。記住底下的 Endpoint 網址。這裡要注意網址必須是 .....s3-website-ap..... 才是支援 Website 功能的 S3 網址。

雖然上述的 Endpoint 網址即可用來瀏覽網站，但是預設的 S3 網址很長一點也不美觀，因此可以到網域註冊商提供的設定工具，利用 CNAME 指向 Endpoint 的網址，例如 s3(.yourname.com) -> s3.yourname.com.s3-website-ap-northeast-1.amazonaws.com，每一家域名註冊商提供的介面都不太一樣，但 CNAME 設定是一定能找到的基本功能。

接下來是 CloudFront 的設定，啟用後可以加速瀏覽速度、降低傳輸費用。

切換到 CloudFront 介面，使用 Create Distribution 增加一組設定，使用 S3 Bucket 作為檔案來源。

設定 CNAME，也就是自定網域名稱，例如 cdn.yourname.com

建立 Distribution 後，可以取得 CloudFront 產生的 Domain Name，例如 drtesgfshfg.cloudfront.net，記住這組網域名稱。

再到網域名稱的設定增加一組 CNAME，指向 CloudFront 提供的 Domain Name。

接下來就能用自訂域名瀏覽發佈後的網站，例如 s3.yourname.com（直接存取 S3）或 cdn.yourname.com（透過 CloudFront 存取 S3）；需要注意的是，CloudFront 有快取機制，因此 S3 資料更新後，可能需要24小時才能夠過 CloudFront 取得更新，因此需要經常變動的資料，並不建議使用 CloudFront。

Crunch time on the Enterprise Desktop，Ubuntu 與 Windows 比一比

2012-03-30T11:01:00.002+08:00

Windows 7 已經是絕大多數新購電腦預置的作業系統，也是舊版 Windows 使用者升級的主流選擇；但相信還有數量非常多的舊電腦，還在企業中使用，執行著舊版的 Windows XP，如果要升級成 Windows 7，可能面臨硬體需要升級或必須重新購置的窘況，需要付出龐大的成本。

以 2012 年來說，即使已經用了 3-5 年的舊電腦，處理器仍有 GHz 以上等級，記憶體通常也有 2GB 以上，應付企業常見的文書辦公需求其實已經很足夠；汰換電腦除了花錢也不環保。

如果不想為了 Windows 7 的硬體需求而升級電腦，停留在 Windows XP 也面臨軟體陸續停止支援的情況，例如 Internet Explorer 9 以上版本就開始不支援 XP，而 IE9 又是 IE 功能比較堪用的版本。儘管瀏覽器可用 Google Chrome、Firefox 替代，但是隨著時代演進，超過10年的老舊作業系統也會被許多新版應用程式放棄支援。

Canonical 是 Ubuntu Linux 的發行商，目前 Ubuntu 除了 Desktop 版本廣受電腦玩家、開發者的青睞，其 Server 版本也開始被許多企業用來取代 RedHat Enterprise Linux 及 CentOS；而 Business 應用也是 Canonical 瞄準的目標市場。

Crunch time on the Enterprise Desktop 是 Canonical 針對 Ubuntu 及 Windows 進行比較的電子書，可以在以下的頁面取得。

Crunch time on the Enterprise Desktop
https://pages.canonical.com/enterprise-desktop-ebook

勇於接受改變的企業，在這個時間點評估升級至 Ubuntu，其實是相當不錯的時機，可以賦予舊電腦新的生命，新購置的電腦也不必在付高額作業系統授權費用；新版的 Ubuntu 桌面很容易使用，使用者不必跨越太高的學習門檻，未來也可以持續更新 Ubuntu Linux 版本，而不會有「停止支援」的窘況。

雖然很多企業都有相同的疑慮，轉換到 Ubuntu 之後，原本的 Office、Outlook 怎麼辦？

其實這也是企業開始重新檢視軟體需求的最好時機，以雲端應用取代舊有的套裝軟體，可以帶來更強大的軟體功能，舊電腦可以繼續沿用至硬體壽命結束，新購置的電腦也可以考慮價格便宜的低階規格，同時也免去建置維護機房的麻煩。

例如，只要使用 Ubuntu Linux 桌面環境，加上 Google Chrome 或 Firefox 瀏覽器，採用 Cloud-based 應用軟體（如 Google Apps），就可以帶來開放自由、更有效率的新一代工作環境。

Google Apps for Business
http://www.google.com/apps/intl/zh-TW/business/index.html

當然有更多人會考慮到「使用者習慣」的問題，其實只要老闆、主管自己樂於接受改變，問題就不會太大，畢竟年輕一代的知識工作者，早已習慣這些新時代的改變；他們在公司可能被迫使用老舊不堪的郵件系統、辦公軟體，甚至被禁用 Facebook : ) 該是解放束縛的時候了...