使用 Google AdSense 西聯匯款，取款心得小記

準備領取 Google AdSense 的廣告收益嗎？選擇匯款超快速又節省手續費的西聯快匯就對了！

在「帳戶設定」的「付款設定」中，確認付款方式已設定為「西聯快匯」。

廣告收益累計超過 100 美元，在「付款」記錄中，就可以查看匯款資料。

以下的畫面，就是取款需要準備的所有資訊。

找到附近有提供「西聯匯款」服務的銀行，使用西聯提供的據點搜尋服務。先備妥：

1. 個人身分證（必須跟 AdSense 帳戶設定的名字一致，中文姓名只要拼音一樣即可）
2. MTCN（重要）
3. 金額（重要）
4. 匯款人：Google Inc.（填在 First Name 的欄位，「Inc.」不能省略）
5. 匯款人國家及城市：1600 Amphitheatre Parkway Mountain View CA 94043 USA

推薦經常取款的朋友，可以辦理「國泰世華銀行」的外幣存摺（外匯綜合存款），在西聯快匯取款時，可以指定將款項以美金直接存入指定帳戶（有些西聯匯款銀行只能領現金）。領取現金會以當日匯率轉換成新台幣，存到外幣存摺就可以在日後匯率划算時（美元升值），再整筆轉換，達到賺廣告佣金兼賺匯差。

國泰世華銀行 2012 年 5 月之後以停止辦理西聯匯款！請找京城、台新等銀行辦理。

經常領取 Google AdSense 匯款的朋友，可以考慮到京城開戶，並同時申請網路銀行及開通西聯線上匯款功能，以後取款就不必再出門排隊。（京城目前不提供直接以美元存入外匯帳戶！）

更新：

• 京城銀行網路西聯匯款
• Google AdSense 西聯匯款-台南京城總行
• [教學] 利用京城銀行的網路西聯匯款服務，直接收取Google Adsense款項，免跑銀行囉！
• 京城銀行推出「網路西聯匯款」
• 京城銀行推出「網路西聯匯款」 （免出門的新選擇）

Java 專案自動化建置之 Gradle 與 Eclipse 整合篇

Gradle 提供 Eclipse Plugin，讓熟悉 Eclipse IDE 的開發者，能夠方便進行整合。

使用這個 plugin 只需要在 build.gradle 增加一行宣告：

apply plugin: 'eclipse'

接著就可以執行以下任務（tasks）：

#Cleans all Eclipse files.
gradle cleanEclipse

#Generates all Eclipse files.
gradle eclipse

如果要查看 plugin 提供哪些任務名稱，只要執行：

gradle tasks

當執行「gradle eclipse」成功後，專案目錄下會多出 3 個項目：

.classpath
.project
.settings

也就是 Eclipse Plugins 幫專案自動產生 Eclipse 專案所需的配置檔。

其中值得注意的是 .classpath 的部份，它會將 build.gradle 的「dependencies」所指定的相依套件（*.jar）引入，把這些套件實際的 jar 檔案路徑寫到 .classpath。

例如，以下是 commons-lang 的套件依賴宣告。

dependencies {
    compile 'org.apache.commons:commons-lang3:3.1'
}

實際的路徑可能存在於：

~/.gradle/caches/artifacts-4/org.apache.commons/commons-lang3/    c12498cf18507aa6433a94eb7d3e77d5/sources/commons-lang3-3.1-sources.jar

通常 Gradle 會把 Jar 檔案下載到 User Home 的 .gradle 隱藏資料夾，以方便不同專案共用相同的 Jar 檔案。

因為 .classpath 必須加入這些 dependencies 的 Jar 檔案路徑，對 Eclipse 來說才能正確找到 classpath，所以每次修改完 dependencies 之後，建議先將 Eclipse 的專案關閉（close project），再重新執行「gradle cleanEclipse」及「gradle eclipse」讓專案設定重新寫入；之後再重新用 Eclipse 開啟專案（open project）、並重新整理（refresh、按F5）。

只要 .classpath 正確產生，在 Eclipse 就可以對這些相依套件提供的類別，得到 auto-build、auto-completion 等編輯器輔助功能。

我在 GitHub 提供一組 Gradle + Eclipse 的簡單範例，僅供參考： https://github.com/lyhcode/gradle-examples/tree/master/eclipse

歡迎對 Groovy / Gradle / Grails 有興趣的朋友，加入 Groovy Taiwan 的粉絲專頁，將不定期提供相關的技術發展訊息。

Wijmo - jQuery UI Widgets 網站前端開發的新利器

jQuery 讓網頁前端 JavaScript 的開發更容易，造福不少網站開發者，它在今年（2011）還獲選年度十大最重要的開源專案（Open source projects）。

但是對於 RIA（Rich Internet Application）的開發者來說，僅使用 jQuery 的核心無法解決打造圖形介面的需求，必須自己擴充或使用 3rd party 的套件。

jQuery UI 幫助開發者滿足一部分的需求，例如下拉式日曆、手風琴式選單（accordion）、對話盒（dialog）、美化按鈕等。

但是 jQuery + jQuery UI 仍不易滿足一些打造管理平台介面需求，例如需要資料方格（DataGrid）或圖表（Chart）等，jQuery UI 並沒有提供這類元件。

通常這類較複雜的需求，我會建議開發者考慮如 ExtJS 或 Echo 等解決方案。

不過介於簡單（使用 jQuery UI）與複雜（使用 ExtJS）之間，存在一個麻煩的地帶。有些專案只要使用 jQuery UI 就能滿足 80% 以上需求，但剩下不到 20% 需要如 DataGrid 等進階元件，如果為了這少部分的需求，就要捨棄輕薄短小的 jQuery，似乎有點 over ...

以 DataGrid 來說，有許多以 jQuery 為基礎的 DataGrid 元件，它們通常不會有什麼問題，但不建議的原因是：不易與 jQuery UI 使用相同的佈景（theme）。

jQuery UI 本身定義了多種佈景主題，只要載入不同的 CSS 定義檔就可以切換。

但是多數 jQuery 的 DataGrid 並不會產生和 jQuery UI 佈景一致的外觀。

jQuery UI 主要提供兩類功能：1. 圖形介面互動行為（Interactions）及 2. 圖形介面元件（Widgets）。其中 Widgets 是比較缺乏的部份。

Wijmo 的出現，可以補足 jQuery UI 在 Widgets 方面的不足，它目前提供超過 30 種元件，並且以 jQuery UI 為基礎，對於佈景的一致性有相當好的支援。

這些在 jQuery UI 基礎上增加的功能包括：

樹狀選單

圖表

工具提示

資料方格

這些元件都是 ThemeRoller-ready，也就是可以依照 jQuery UI 定義的不同佈景切換顯示外觀，而有一致性的網頁元件風格。

這麼棒的元件要多少錢呢？

Wijmo 分成兩個版本，有 Open 及 Complete 兩種。

Open 版本提供比較多元的 MIT 及 GPL 兩種授權，如果你的專案本來就用 jQuery 也依循 jQuery 的 MIT 授權方式，那就可以繼續以 MIT 授權方式使用 Wijmo Open。可是 Open 版本並不包含如 Grid 等進階元件，目前僅提供 18 個（完整版 Complete 為 30 個）。

但是完整版本 Complete 就沒有提供 MIT 授權，僅有 GPLv3 及商業授權；採用 GPLv3 授權的專案，必須接受比較嚴謹的「開放原始碼」要求。而商業授權則需要支付 $299 美元（或包含支援服務的 $499），而取得授權的一方可以將它用於不限數量的專案開方上。

Plupload 支援網頁多檔同時上傳的開發利器

Plupload 是由 TinyMCE 開發者分享的上傳元件，它混合使用多種網頁開發技術，如 HTML5 Gears, Silverlight, Flash, BrowserPlus，如果瀏覽器支援這些功能的其中一項，就可以提供完整豐富的多檔同時上傳機制；如果很不幸瀏覽器什麼都不支援，它仍會使用最原始陽春的 HTML 表單進行檔案上傳。

官方網站： http://www.plupload.com/

Plupload 是開放原始碼專案，位於 GitHub： https://github.com/moxiecode/plupload

實際執行的畫面如下：

多個檔案可以同時上傳，並且顯示容量、個別與整體的進度百分比。

Drush 安裝設定以 Ubuntu 為例

Drush 是 Drupal 內容管理系統的命令列工具（command line shell and scripting interface for Drupal），它讓熟悉以指令操作 Server 的進階管理者，可以直接用指令進行一些網站維護工作，解決網站後台介面複雜且緩慢的缺點。

這篇文章以 Ubuntu Linux 10.04 （及以上版本）為例。

由於 Ubuntu 官方提供的 drush 套件版本比較舊，所以需要先增加 ppa 套件來源。

sudo apt-get install python-software-properties
sudo apt-add-repository ppa:brianmercer/drush
sudo apt-get update
sudo apt-get install drush

安裝完成後，可以從以下網站取得參考文件。

http://www.drush.org/
http://drupal.org/project/drush

Drush 可以用 Script 方式執行，如此一來就可以配合 Crontab 等 Unix 工具自動化維護。

#!/usr/bin/env drush
drush_print("Hello world!");
drush_print();
drush_print("The arguments to this command were:");

也可以直接用 command 方式操作。

drush dl corolla

如果 Drupal 包含多個站台（multi-sites），可以用 -l 參數指定 URL。

drush -l http://hostname pml corolla

OpenChurch 教會網站架設套件（以 Drupal 6 為基礎）

http://www.openchurchsite.com/

OpenChurch 是針對教會網站需求特別設計的架站軟體，它具有以下的特色：

• 事工專頁（Ministry Pages）：
  讓各事工組織及小組可以自己維護管理發佈的訊息及活動，包含報名、文件資料下載、相簿、影片等。
• 多媒體（Media）：
  包含影音串流、相簿等。
• 佈景（Theming）：
  只要修改幾張照片，就可以成為教會專屬的網站版面。對於擁有資訊技術人員的教會來說，還可以完全將外觀客製成獨特的樣貌。
• 內容管理（CMS）：
  教會成員不需要熟悉網頁語法（如HTML），就可以輕鬆編寫網頁內容，非常省時又省力。

這麼強大的架站軟體，它的背後就是採用知名的 Drupal 內容管理平台，它由世界各地數以千計的開發者共同創作，因此不斷以飛快的速度發展前進。

可惜，OpenChurch 並沒有友善的中文支援，也沒有針對華人教會的需求客製處理，這一點對於想試用它架設網站的教會來說，可能是一個相當大的困擾。

好消息是，我們的事工組織，將針對華人教會的需求，打造一個中文版的 OpenChurch，如果您有興趣加入這項事工，或您的教會有興趣採用新的方式架設功能豐富的專屬網站，請與我聯繫。

聖誕節網頁應景的 JavaScript 雪花紛飛效果

想讓網頁有點聖誕節的氣氛嗎？

只要在 HTML 的 </head> 前面加入一行：
就可以讓網頁開始飄雪。

JavaScript 程式來源： http://www.schillmania.com/projects/snowstorm/

Google 聖誕節主題：搜尋 let it snow 讓瀏覽器下雪

在 Google 搜尋「let it snow」，搜尋結果的網頁會開始飄雪

瀏覽器開始被積雪覆蓋

使用滑鼠左鍵可以擦拭乾淨

開放源碼、功能強大的 Cloud9 IDE

Cloud9 IDE 是基於 NodeJS 開發的線上整合開發環境（Online IDE），由 ajax.org 團隊製作。只要使用現代瀏覽器（Modern Browsers），就可以直接在線上開發軟體。

C9 在今年（2011）獲得 550 萬美元的資金，讓這個專案的發展更加快速，它的前景十分值得注意。

C9 提供 SaaS 的雲端服務，只要註冊一組個人帳號，開放源碼的專案可以不必支付任何費用。而每月支付 15 美元的進階使用者，則可以用它開發原始碼不公開的商業軟體。

Cloud9 IDE http://c9.io/

C9 支援 Git 版本控制系統，讓多人協同開發變得很容易。它的編輯器支援多種程式語言的 Syntax Highlight，可以切換多種佈景，並支援許多 Programmer 喜愛的 VIM 操作模式。

目前最適合採用 C9 的專案類型，主要是以前端 JavaScript（如 jQuery、ExtJS 擴充套件）或後端 NodeJS 為主。

Ace（editor component for c9）是 C9 的開放源碼專案之一，可以期待它將友善地支援各種主流程式語言，並提供許多進階的程式碼編輯輔助功能（例如：refactoring、auto-complete、code-analysis等）。這些 Programmer 的盼望正在發生，相關的資訊可以關注 Cloud9 IDE Blog。

在我正思考著下一代程式語言教學軟體，要如何打造類似 Cloud9 的 IDE 介面時，非常興奮地發現 Cloud9 本身也是一項開放源碼專案。

Cloud9 Open Source Project @GitHub https://github.com/ajaxorg/cloud9

在 Ubuntu Linux 只需要幾個指令，就可以從 Cloud9 的原始碼啟動一個測試伺服器。

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:chris-lea/node.js
sudo apt-get update
sudo apt-get install git nodejs nodejs-dev
git clone git://github.com/ajaxorg/cloud9.git
cd cloud9
./bin/cloud9.sh

最後一道指令，除了啟動 Cloud9 Server，也會自動打開瀏覽器，執行畫面如下。

這個預設畫面相當有趣，它預設開啟專案就是「cloud9」，也就是可以使用 Cloud9 開發 Cloud9。

Cloud9 讓我們看到：

• NodeJS 確實、十分肯定可以用來開發相當強大的 Web 應用。
• 未來不僅 Office 可以雲端，許多開發軟體的工作也可以僅僅透過瀏覽器完成。
• 軟體公司只要挑選合適的架構，組合、擴展這些開源專案，有機會發展量身打造的專屬雲端開發平台。

Linode 傳輸速度測試

昨晚在 Linode 租一個入門款的虛擬主機，看到機房位置的選項又猶豫一下，

目前可以選擇的地點有：

1. Tokyo, JP
2. London, UK
3. Newark, NJ
4. Atlanta, GA
5. Dallas, TX
6. Fremont, CA

在亞洲似乎只有東京（Tokyo）可選，但我對台灣和日本之間的連線速度，還停留在過去頻寬不足的印象。本來想選擇北美，但最後在送出確認之前，做了一下簡易的測試。

使用 Linode 提供的速度測試檔案下載：

http://www.linode.com/speedtest/

以 CHT 50M 光世代測試的結果：

1. Tokyo, JP (5.09 MB/s)
2. Fremont, CA (4.12 MB/s)
3. London, UK (2.00 MB/s)
4. Dallas, TX (1.18MB/s)
5. Newark, NJ (1.16 MB/s)
6. Atlanta, GA (551 KB/s)

從這個結果看來，東京似乎是最佳選擇。

使用學網再測試一次：

Tokyo, JP (7.82 MB/s)

最後我選擇東京，同時也把 Amazon S3 的 bucket 也搬遷到東京。用 Linode + Amazon S3 的搭配，滿足網頁伺服器（Linode）及大量檔案儲存（S3）。

jQuery CodeMirror Plugin

這個 Plugin 主要提供 2 個功能，讓開發者能以 jQuery 風格的寫法，使用 CodeMirror 2。

1. 將 textarea 轉換成編輯器，提供 CodeMirror 原生參數及方法。
2. 將 textarea 的內容（程式碼）高亮顯示（syntax highlight），並支援行號顯示，使用 CodeMirror 提供的 Mode Runner。

Project Homepage

http://lyhdev.com/project:jquery-codemirror

jQuery CodeMirror Plugin @ GitHub

https://github.com/lyhcode/jquery-codemirror

Sample @ jsFiddle (results)

http://jsfiddle.net/lyhcode/nDz5F/1/

CodeMirror 2 runmode (highlight only) with gutter

CodeMirror 是一款支援 Syntax Highlight 及多種特性的「網頁版程式碼編輯器」，它可以應用在線上開發工具，方便使用者編輯原始碼，例如 Google Code Playground 等。

我們在「ContPub自助出版服務」，也使用 CodeMirror 作為電子書原始碼的編輯器。它補強 HTML 的原生 TextArea 不支援 Tab 鍵、無法自動對齊等問題，也提供漂亮的語法高亮顯示（Syntax Highlighting）。

編輯的需求，用 CodeMirror 很輕鬆就能滿足。

不過，如果需要顯示原始碼，並且具有 Syntax Highlight 的效果，就需要再尋找一個解決方案。

再談電子書原始碼製作：程式設計教學篇

過去我們在製作程式設計書籍時，總是遇到兩個困難：

1. 程式碼
2. 示意圖（流程、類別、...）

使用一般的 WYSIWYG 工具編輯內容時，程式碼經常帶來麻煩：(1)不易保留原有的對齊（indent）；(2)不易顯示固定寬度（mono）文字；(3)不易呈現語法著色（syntax highlight）。

編輯器提供一些格式化的功能，我們可以花點時間將程式碼排版變成理想的樣子。可是，有許多問題會重複浪費時間：(1)程式碼的修改，必須在外部經過編譯及測試，沒問題才能放到書裡面，因此必須維護外部程式碼檔案及書籍內容的同步；(2)書籍提供的程式碼愈多，浪費在編排的時間也就愈多。

我們對程式設計書籍製作的理想，是希望可以自動處理這些程式碼，用程式碼的方式來處理。

舉例來說，以原始碼製作電子書時，我們只需要加入一段代碼：

[code-include: "ex01/Main.java"]

就可以將 Main.java 的原始內容嵌入，並顯示成最佳化的 Java 程式碼編排。

如此一來，Main.java 程式碼就可以利用其它開發工具進行修改、編譯及測試，並將最終結果自動呈現到書裡面。（程式碼還沒完成之前，就可以開始寫書的內容。）

若此種語法加以擴充，也可以「只顯示」其中的某幾行，以減少篇幅的浪費。

[code-include: "ex02/Main.java 15-20]

另一種我們實際碰到的問題，是程式教學有許多「概念」不易用文字說明，例如物件導向類別之間的關係、程式處理的流程。

過去的作法，通常是以圖形繪製的工具，完成 SVG（向量）或 PNG（去背的點陣圖）格式，再貼（嵌）到書籍內容中。

但程式教學需要的圖形，除了螢幕擷圖外，大多都是不需要華麗外觀的簡單圖形。螢幕截圖只要配合適當的工具，就可以很方便地處理（例如 Mac OS X 的 Shift + Command + 4 快速鍵）。用於「概念」說明的圖形，我們則需要一種更簡單、易修改的方式來處理。

這種簡便、快速，容易嵌在電子書的原始碼，也容易修改的「圖形」製作方式，就是透過「圖形的原始碼」。

以原始碼來呈現圖形，並不是什麼新個概念。這種做法行之有年，例如 yUML 就是一種可以利用原始碼描述、產生 UML 圖形的線上服務。

Graphviz 是這類工具的傑出之作，它最早由 AT&T 實驗室開發，後來也被廣泛運用在許多軟體，例如 ArgoUML 等。它從簡易的流程圖、到複雜的網路圖或 UML 圖形，都能夠以純文字代碼描述。

安裝 Graphviz 很簡單，在 Ubuntu Linux 只需要使用：「sudo apt-get install graphviz」指令；而 Mac 也可以用 MacPorts 安裝：「sudo port install graphviz」。

以下是一段 Graphviz 的簡單範例，可以儲存成「job.dot」檔案。這段代碼用於描述 Job、Fulltime、Parttime 三個節點（node）的關係。

digraph G {

  node [ shape = "box" ]

  edge [ arrowtail = "empty", dir = "back" ]

  Job -> Fulltime

  Job -> Parttime

}

利用 Graphviz 提供的 dot 指令，可以將這個「圖形原始碼」轉換成 PNG 格式。

dot -Tpng -ojob.png job.dot

當日後書籍內容有所改變，需要修改內容、程式碼，以致這些圖形也需要修改，我們就不必大費周章找出圖形檔、用外部繪圖工具修改、再重新貼回書籍。

如此一來，程式設計教學書籍的主要組成元素：(1)書籍內容、(2)程式碼及(3)簡易圖形，就可以各自用純文字的「原始碼」描述。

我們採用以下的格式來分別撰寫書籍內容。

1. 書籍內容：Markdown
2. 程式碼：Java（或其他語言）
3. 簡易圖形：Graphviz

透過自動化建置工具，如 Make（Makefile），這些書的元素可以分別被處理、測試。

1. 將程式碼編譯成執行檔 make binary
2. 測試程式碼 make test
3. 產生圖形檔案 make graphviz
4. 產生電子書 make ebook

由於大部分的書籍內容，都以原始碼描述，因此得到許多好處：

1. 多位作者（程式設計師、測試工程師、編輯、校稿、助理、工讀生）可以線上協同工作。
2. 書的「風格」可以用 Template 定義，只需要改一次宣告，就可以改變整本書，例如圖形外觀的微調、程式碼的色彩等。
3. 很容易建立標準作業程序，並簡單地客製量化生產書籍的工具程式（僅需要以簡易的表單提供文字內容輸入，並將結果組合成電子書原始碼）。

我們嘗試使用 ContPub 製作一本程式設計教學書籍的範本，其 PDF 版本的檢視結果如下圖。

電子書的原始碼如下，程式碼及類別繼承示意圖皆以原始碼方式撰寫。

我們使用 ContPub 實驗電子書原始碼的概念，利用原始碼自動產生(1)電子書及(2)電子題庫，未來也會將產出透過新版 PLWeb（程式設計練習系統）。

這種作法大幅提高程式設計教材製作的效率，可以協助作者（及教師）輕鬆製作 Learning by Doing 的數位教材。歡迎有興趣製作教材，或有意願體驗、參與我們研習活動的教師（及作者），利用回應功能留言或 E-Mail（lyhcode 小老鼠 gmail.com）給我。

下載電子書範例檔（PDF及EPUB）：http://contpub.org/read/demo2

使用 Gradle 快速建立 Tomcat 開發測試環境

使用 Gradle 可以方常方便以 Tomcat 建立 Java EE 的開發測試環境，所需要的步驟就是建立一個符合 Gradle convention（慣例）的資料夾、檔案結構。

• /project1
• /project1/build.gradle
• /project1/src/main/webapp/hello.jsp

過去被放置在 WebContents 如 WEB-INF、*.jsp 等，都搬到 src/main/webapp 即可。

這裡的 hello.jsp 只需要一行「hello」文字，即可用於測試。

其中最重要的設定檔，就是 build.gradle，它類似 Apache Ant 的設定檔 build.xml，但是以 Groovy 語言撰寫，設定更簡單、功能更強大。

一個最基本的 Gradle（build.gradle）設定範例如下：

JSP只要正確放在 webapp 即可，不需要其它設定。以此例而言，即使沒有 WEB-INF/web.xml 仍然可以執行、測試。

打開終端機輸入指令，啟動 Tomcat 的指令為：

gradle tomcatRun

執行成功後，會看到「:tomcatRun」的訊息，用瀏覽器打開以下網址，就可以測試結果（顯示 hello 文字）。

http://localhost:8080/tomcat/hello.jsp

回到終端機畫面，以「Ctrl+C」停止 Tomcat。

下一步，我們加入 HelloServlet.java。


以及 web.xml 的設定。


包含 Servlet、Filter、Listener 等等，以 Java 撰寫的 Class 原始碼，都放在 src/main/java 底下。

• /project1/src/main/java/test/HelloServlet.java
• /project1/src/main/webapp/WEB-INF/web.xml

在執行一次 Tomcat 伺服器：

gradle tomcatRunWar

執行這個指令，會自動進行 compileJava（以 javac 編譯 *.java 程式碼）的任務。

將 tomcatRun 改為 tomcatRunWar 的原因，主要是 tomcatRun 不會將編譯好的 class 放到 WEB-INF/classes，造成 Servlet 的 class 找不到。

用瀏覽器再測試一次結果：

http://localhost:8080/tomcat/hello


如果你的專案需要加入其它函式庫套件（*.jar），例如 MySQL Connector/J，只需要在 dependencies 加入一行宣告。

dependencies {
        compile 'net.sourceforge.nekohtml:nekohtml:1.9.15'
        runtime 'mysql:mysql-connector-java:5.1.18'

        ...

compile 或 runtime 指明套件的依賴是在編譯階段，或執行期才需要。以 JDBC 存取 MySQL 來說，我們在 Servlet 的 import 通常會以 JDBC 的類別為主，不會直接使用 MySQL Connector/J 提供的類別，所以就可以用 runtime 宣告。而專案的 Java 程式碼有直接 import 的相關類別，就必須用 compile 宣告，才能通過 compileJava 的編譯。

由於 Gradle 會從 Maven 的 repository 尋找相依的套件，可以到 Maven Repository 網站搜尋套件。

以 MySQL 為例，找到 mysql-connector-java 5.1.8 這個版本，就可以從網頁取得 Gradle 需要的宣告：

使用宣告的方式管理專案相依的套件，可以得到許多好處：

1. 不必把 *.jar 檔案放到專案的 WEB-INF/lib 資料夾下，所以不會被送到版本控制系統。因為這些外來的函式庫本來就不屬於專案的一部分，沒必要浪費儲存空間和拖慢其它成員存取專案的時間。
2. Gradle 會幫忙處理「相依性」的問題，節省開發者的生命時間。例如使用某個套件，它又依賴 commons-lang，手動方式處理就必須另外再去下載一份，當專案依賴的套件數量變多，WEB-INF/lib 底下的檔案就會讓人眼花撩亂，根本無法維護。
3. 未來需要更新套件的版本，只要從 build.gradle 修改版本編號即可。

有許多 Java 的 Open Source 函式庫，都會提供一段 Maven 設定訊息：

• groupId: org.apache.commons
• artifactId: commons-lang3
• version: 3.1

組合成 groupId:artifactId:version 格式，就可以交給 Gradle 處理。

雖然這篇文章說明 Tomcat，但是在實務上，舊專案從傳統的 Tomcat 使用方式，改以 Gradle 自動建置後，可以用 Jetty 取代 Tomcat 作為開發期間的測試伺服器。

Jetty 具有精簡、輕巧、速度快的優點，而且 Gradle 內建 Jetty Plugin，使用上非常方便。

在一般企業環境，可能還是選擇 Tomcat 或其它 Java EE Container 做為正式的伺服器方案。所以，專案改用 Gradle 建置後，可以同時啟用 Tomcat 及 Jetty 兩個 Plugin，讓開發階段用更輕巧的 Jetty 進行測試，等到完成一個段落，要正式佈署前，在用 Tomcat 測試一次。

一般來說，我們可以搭配 Gradle 的 War Plugin 使用，在專案經過 Jetty 及 Tomcat 測試沒問題後，就可以打包成 .war 檔，以方便佈署到（一或多部）伺服器。

舊專案只需要花少許的時間，將 build.gradle 設定檔完成，日後在開發時，就可以用簡單的 Gradle 指令進行專案自動化作業，例如：

# 自動化測試（搭配 JUnit、Spock 等）
gradle test

# 自動檢查程式碼品質（搭配 CheckStyle 及 CodeNarc）
gradle check

# 執行 Jetty 網頁伺服器
gradle jettyRun

# 執行 Tomcat 網頁伺服器
gradle tomcatRunWar

# 打包成 WAR 檔
gradle war

# 可以自訂一個自動發佈到遠端伺服器的任務
gradle deployToServer

以上適合舊專案，或是簡單的小型拋棄式專案，改用 Gradle 將許多開發階段的瑣事自動化。至於新的 Java EE 專案，則可以選擇 Grails 或 Play! 幫助開發人員節約生命時間。

使用 iPad 製作 PDF 及 EPUB 電子書，作者輕盈零負擔！

我不賣健康食品，但是我想分享「多螢幕強迫症」的一種醫治方法。

長久以來，我的桌面只要少於 3 個螢幕，就會開始出現工作效率低落；感覺被放逐在 Cyberspace 的邊境，一種絕望的失落感莫名升起。

還好螢幕這種東西愈來愈便宜，我可以輕鬆地買入半打來減輕這種痛楚。

但是，當我開始製作電子書，開始用閱讀器檢視書的內容。我發現商人真是奸詐無比病情開始加劇；因為螢幕小小小小的一台閱讀器，不僅價格不便宜，而且規格種類五花八門，不斷考驗你的口袋有多深！

你不能只買一台閱讀器，必須買好幾台，持續的買；才能測試你做好的電子書，在不同尺寸、不同形狀、不同作業系統、不同閱讀軟體、不同版本、...的條件下，是不是有足夠的相容性。

我原來的大尺寸桌上型螢幕，開始一台一台離我而去，取而代之的是大小不一的閱讀器。儘管我有多部 Mac、Windows、Linux 電腦，也有 Android、iOS、... 閱讀器，儘管我試了許多套電子書編輯軟體；但是卻沒有一種軟體提供：「你給我內容、我幫你做書、而且不收你一毛錢」的友善流程，一種我渴望的簡單服務。

我懂你好心想介紹給我的編輯軟體，功能很強大；但是，我買不起。我也瞭解有免費又好用的編輯軟體；可是，我不想學。

曾經，我超級喜歡學習各種電腦文書編輯軟體，從 PE2、HE5、漢書2000、莎士比亞、WORD 6.0...到最近的 Office 2011 for Mac、Pages。直到我發現自己年紀大了，沒辦法再像年輕小夥子那樣無止盡地瘋狂學習。

我是一名上了年紀的 programmer，年輕的時候也熱愛很潮的開發工具，喜歡學習很多很多軟體。隨著時代變遷，我發現自己碩果僅存的電腦技能，就只剩下「中英文打字」這一項，其它都成了嘴砲。

既然如此，只好以僅有的打字技能繼續騙吃騙喝。

返樸歸真的過程中，我發現打字這項技能很管用；只要願意仔細思考，如何只靠著打字獲得最大化的生產力，而不再迷信或眷戀那華麗介面的「企業級軟體工具」。

旁門左道的軟體開發方法論：

舉例來說，當我放棄舊的 Java EE 專案開發方式，而學習 Ruby on Rails 啟發的思維，開始重新設計軟體架構；我發現其實只要一套 vim（歷久彌新的老牌文字編輯器），搭配正確的工具，就足以應付每天的工作所需，讓更多瑣事自動化，而且效率更高、不再依賴更強大的電腦（但是也因此失去換電腦的理由）。

軟體開發要能事半功倍（用更少時間工作、得到更多的產出），秘訣在於讓電腦幫你工作，方法則是每位軟體開發者都應該熟悉的「Source Code」。寫好一段 Source Code，電腦就能幫你工作；相反地，學會一套介面華麗、功能強大的新軟體，換你幫電腦工作。

我認為做電子書也存在類似的法則，身為一名作者，只要把內容（電子書的原始碼）完成就好，所需要的技能也僅有「打字」而已。

可是，現在的大多編輯軟體不是這樣設計；若你是一名作者，如果你不夠紅，在你把書做出來之前，沒什麼人會幫你服務，你可以選擇花錢解決，或者，自己動手做。

若你選擇自己動手，你將發現電子書的製作，並不比紙書簡單到哪去。其中一個問題是，你不會知道你的讀者看到書的時候，書會長什麼樣子。

紙書，除非淋雨泡水被火燒到；否則在你手上的樣子，跟在其它一百位讀者看到的樣子，應該相去不遠。

電子書卻可能在你自己下載到手機上打開，就長得不太一樣。

如果你也想自己解決各種電子書相容問題，你的桌面可能會跟我的類似（或更多螢幕）。相信我，更多的螢幕不會讓你感到舒服些，反而只會使頭痛加劇。

Paul Graham 的「Hackers & Painters」書中提到：「除非真心熱愛，否則無法將事情做得很好，如果你喜歡自己動手（hack），你將無可避免的開始進行自己的專案。」

為了自己做電子書，並且不必學習任何編輯軟體，同時也讓研究成果更方便別人一起使用。我們開始進行一項 open source side project，也就是後來上線的「ContPub（Continuous Publishing）」。

如果你也想寫書，唯一需要做的事情，就是在 ContPub 註冊一組個人帳號，並了解自己的書，會用到哪些「標記語法」；接下來，只要把「書的原始碼」靠著打字技能完成。

下一步，我們想要分享如何用 iPad 製作電子書，也就是利用 iPad 打字，完成書的原始碼，就可以由 ContPub 自動產生電子書（提供 EPUB 及 PDF 兩種格式），並使用 iPad 的 iBooks 檢視完成的電子書。

為何要用 iPad 寫書？我的動機是...

有次在 Malaysia 搭 KTM 的旅途中，在臥舖待了十多小時，手邊的 3C 產品只有 iPad 和 Desire，卻開始幻想著可以把每天拍的照片、文字整理成書，可惜那時候的 iPad 做不到，等我回到台灣，寫書的念頭也陸續被工作瑣事淹沒。

你唯一需要的硬體，就是一台 iPad，為了方便打字，可以選配藍芽無線鍵盤。

選擇一套你最滿意的文字編輯 App，例如：Nebulous Notes，它可以搭配 DropBox 儲存服務，即時幫你的電子書原始碼備份到雲端，如此一來，你的平板、筆電和其它行動裝置都可以共用這些檔案。只要認識幾個基本「標記」語法，就可以開始編寫內容，請參考「無痛製作電子書」。

前面提到 App 最好要支援 DropBox，最主要的原因是，ContPub 目前也開始支援 DropBox（測試階段）模式。你可以選擇使用 ContPub 內建的原始碼編輯器，或是將原始碼放在 DropBox 的共享資料夾。你的原始碼，可以被 ContPub 讀取、製作成電子書。

製作好的電子書，直接下載到 iBooks 即可開啟閱讀，當然也可以立即透過 E-Mail 傳給你的朋友。下圖是 EPUB 格式的閱讀效果，可以享受 iBooks 閱讀器的註記、書籤功能。

除了適合電子書閱讀器的 EPUB 格式，ContPub 也提供 PDF 格式，具有更好的中文字體呈現，使用不同軟體開啟也能保持一致的格式。但如果你想要將部分內容列印出來，或是少量印刷、裝訂成冊，PDF 仍是目前最佳的選擇。

問：為什麼把原始碼交給 ContPub（或類似的服務），就可能解決不同裝置的相容性問題呢？
答：其實 ContPub 目前並沒有真的能解決所有相容問題；但 ContPub 未來會陸續解決。所以，當你的內容是用原始碼撰寫，等 ContPub 成功解決 XXX 平台閱讀問題的時候，你唯一需要做的，只是重新按一次發佈按鈕。

終於，我不再需要為製作電子書而增加螢幕的數量，這是我成功克服「多螢幕強迫症」的心路歷程。

再思考自助出版電子書該如何「設計封面」 與行銷？

最近我試著用「原始碼」製作電子書，幾本書的完成度大概有七成左右。接下來面臨的問題之一，就是「封面」的設計。

身為出版麻瓜（完全不懂出版魔法的平凡老百姓），唯一能跟出版沾上邊的技能大概只有「中英文打字」而已。

我們用號稱無痛的源碼方式，解決自身（孤苦無依的獨立出版作者）不懂排版的問題，靠著打字硬是把電子書生出來。

可是對麻瓜來說，出版可不是只有排版是個問題，「封面」設計也是問題啊！

從前，只要用錢就能解決封面的問題：

1. 把錢交給出版社，封面搞定。
2. 把錢交給平面設計師，封面搞定。

可是對於想要克難學出版的麻瓜來說，連第一本書都還沒賣掉，就要先自掏腰包花錢做封面，似乎一點也說不過去；更何況這筆費用，成本還是要轉嫁給讀者負擔。

專家設計的書籍封面確實很漂亮！很美觀！也可能很養眼！

可是，我希望讀者付的錢有 99% 是買內容、買服務。

假使漂亮的封面設計，要價 $3,000 元（真是破壞行情的假設！），但是書只賣了 100 本，每一本書平均有 $30 元的「封面設計成本」。

如果讀者想看美美的設計，我會希望他拿這 $30 元去看展，美術館的展覽或ＸＸ設計大展都好；總之，有很多地方可以看到更棒的設計。

紙書時代，封面設計很重要。走進書店，琳琅滿目的圖書，封面設計攸關這本書能不能吸引潛在讀者目光。當你只看幾眼，就要從新書區陳列的數十本書中，隨手挑選一本翻閱，封面有一定的影響力。

封面設計在書店陳列的吸睛效果（R.I.P. Style）

開放源碼電子書與 EPUB 幕後排版

在 2011 年「數位出版金鼎獎分享會暨媒合會」，我分享的 Talk 主題是「開放源碼電子書與EPUB幕後排版」。

我們沒有電子書產品可以分享，談論這個議題，目的是希望數位出版業界的朋友們，可以看到 Markdown 這種的標記語法，適合用於「排版相對簡單」、「以文字為主」的電子書製作。因為有許多書籍重點在內容，而不必要求像雜誌一樣漂亮的圖文編排，也不必要求媒體聲光效果。

有許多概念和技術細節，沒機會在 Talk 中講述，所以只好用網誌慢慢寫 : -)

故事從程式設計教學這門「慈善事業」開始說起。

我們想要尋找一種方式，讓個人（素人作家）也可以很容易出版。動機是我們已經發展多年的程式設計練習系統，已經有累積一些數位教材，可以變成教科書販售。

程式設計的數位教材