2015年2月27日 星期五

啥時找 library?啥時自幹?

原文網址:http://games.greggman.com/game/when-to-find-a-library-vs-when-to-write-code/

譯註:我幾乎完全不認同這篇的說法,更不用說 HappyFunTimes 也是一個 library [大笑]。只是拿來恢復一下翻譯的感覺…


身為一個 C / C++ 碼農,除非是很大的 project,不然我很少找 library。舉例來說,如果我需要讀 BMP / TGA 檔,帳面上要寫的程式碼不到 100 行。看一下資料格式、寫一些程式、打完收工。要是我需要載入 JPG / PNG 這些格式異常複雜的檔案,我終究會去找一個 library。

我現在寫 JavaScript 就不太一樣,在 JavaScript 的世界中有數以萬計針對各種狀況的小型 library,讓我不知道該自幹程式還是找找看有沒有 library。這常常讓我覺得很浪費時間。

例如我要有一個非常簡單的功能:把字串裡頭的關鍵字換掉:

replaceParams("Hello %(name)s", {name: "World"});

// produces:
// Hello World

後來為了可以這樣搞,所以拓展到 20 行:

replaceParams(
    "Hello %(name)s from %(user.country)s",
    {
      name: "Joe",
      user: {
        country:"USA",
      },
    });

// produces:
// Hello Joe from USA

最近我希望可以用路徑插入其他檔案,像這樣:

replaceParams("->%(insertfile: foo/bar/moo.txt)s<-");

如果 moo.txt 裡頭是 this-and-that,結果會是:

-->this-and-that<--

只需要幾分鐘的時間就可以加這個功能,但是… JavaScript 中的 template 系統超級多,我建一個 template 很快。也許我應該去用那些 template 系統而不是重新再造輪。

那麼,第一個問題是:要用哪一個?我聽過 mustache、handlebars、jade、ejs…… 為什麼要選 A 而不選 B?我花了大概 20 分鐘搜尋、試圖比較… 來讓我知道哪一個比較優秀。我看到「ejs = 嵌入 JS」看起來很像 PHP;我看到 handlebars 是以 mustache 為基礎但是快了很多。我決定用 handlebars、花了大概 20 分鐘來改程式碼,它輸出相同的結果,一切看起來很棒。

然後我試著加上我那個 insertfile 指令,靠夭,炸了 AFAICT,除了關鍵字以外都沒辦法傳進 template 中。現在已經過了一小時了,誰能告訴我為什麼我要再作一次這件事情?

這就是為什麼寫這篇文章《啥時找 library?啥時自幹?》。當然,在這個例子中,如果我不去找 library 就可能只會花掉我 5~10 分鐘。我選用的 library 有一些功能,像是可以擴展功能… 自幹版當然也可以加功能。另外它可以選擇要不要轉換跳脫字元,自幹版當然也可以有這個功能。我其實沒有答案……

我知道的是… 找 library 讓我覺得分心、浪費時間。前頭我很誇張地描述許多我下載的熱門 library 證實是爛掉的,時間都花在找尋、設定跟測試。相對地,也有人告訴我應該使用更多 library。像最近在 HappyFunTimes 就有人說我應該用 body-parser 來自動分析 JSON 而不是自己處理。我的程式有 5… 也許 10 行,但是 body-parser 有 2000 行。好啦好啦,它能處理一堆 case,但是這些 case 在 HappyFunTimes 幾乎都不會遇到。我試了 body-parser 結果發現它也沒有處理我沒法處理的錯誤。如果我能解決這些錯誤,在網路上找答案是不會解決的,只會找到誰也遇到這個問題而且一樣沒辦法解決。

我想用 library,因為我會假設他們處理一些我不知道的特殊狀況。不過它們搞出來的麻煩往往多過它們的價值。

2015年1月24日 星期六

2014 年 GWT 調查報告中文摘要

原始報告請到 https://vaadin.com/documents/10187/4238532/GWT_report_2015.pdf 下載。 這個連結是在某個 G+ 上頭看到的, 目前 https:/vaadin.com/gwt 的連結還是指向 2013 的版本, 但是 https://vaadin.com/gwt/report-2015 的東西似乎 ready 了?

這是在 2014 年作的調查,所以雖然 vaadin 是標注 2015 年, 我還是以 2014 為篇名。

基本上都只翻譯數據跟(個人認定的)重點,非逐句翻譯。


1. 評價

4.47 分(滿分 5 分)。

這是 1101 份投票的平均分數。有 82% 的人投了 4 分以上。

2014年5月18日 星期日

Sencha GXT 3.1 發布

作為 Sencha GXT 的團隊代表,我很高興宣佈 Sencha GXT 3.1 發布。在公開測試後只有一兩個月的時間,我們收到一卡車的回饋意見。我們已經解決幾個來自公開測試討論區的問題。感謝所有前期測試人員,你們的回饋意見始終是非常寶貴的。

GXT 3.1 導入了新的 Theme Builder(妝點 GXT 程式的新工具)、Neptune 這個佈景主題就是用 Theme Builder 做出來的;另外 GXT 3.1 也增加了對 GWT 2.6 的支援度。

(譯註:省略兩段純粹提供 3.1 各式連結的部份)

2014年5月16日 星期五

HandlerManager 與兩個 event package

我大概是當完兵之後才開始用 HandlerManager 作 event bus,目的當然是降低耦合度。起手 reference 是 tkcn 的這篇《利用 HandlerManager 實作共用的 Event Bus》,然後一直以來就爽爽用,沒出啥問題、也沒想過會出問題。今天在 review 別人的 code 才知道有 SimpleEventBus,然後想知道這兩個到底有什麼差別、該用哪一個比較好?沒想到才剛打開 HandlerManager 的 source code,一開頭的 javadoc 就開始噴血:

application developers are strongly discouraged from using a HandlerManager instance as a global event dispatch mechanism.

WTF?不但不建議,而且是強烈不建議?GWT MVP 的文件都還是教用 HandlerManager 阿?

2014年5月11日 星期日

GWT MVP part1

原文網址:http://www.gwtproject.org/articles/mvp-architecture.html

建立大型 application 都有其障礙,GWT application 也不例外。多個開發人員同時在一份程式碼上作業、維護既有功能,可能短時間內就會讓程式碼一團混亂。為了解決這個問題,我們導入 design pattern 來將 project 劃分出不同的責任區。

有很多 design pattern 可以選擇,例如 Presentation-Abstraction-Control、Model-View-Controller、Model-View-Presenter…… 等等。雖然每個 pattern 有其優點,不過我們發現 Model-View-Presenter(以下簡稱 MVP)架構在開發 GWT application 的效果最好。有兩個主要的原因:首先,就像其他 design pattern,MVP 會降低開發行為的耦合度,這讓多個開發人員可以同時工作。再者,MVP 會盡可能降低 GWTTestCase 的使用度。GWTTestCase 會需要 browser,但是大多數程式碼只要輕量、快速、不需要 browser 的 JRE 測試。

這個 pattern 的核心是把功能分散到各個元件,這在邏輯上是有意義的。但在 GWT 中還有一個明確的重點,是讓 View 的部份盡可能簡單,以減輕對 GWTTestCase 的依賴、降低整體的測試時間。

一旦你瞭解這個 design pattern 的原理,那麼建立以 MVP 為基礎的 application 就會直覺又簡單。我們將用一個簡單的通訊錄系統為例子,協助你聊解這些概念。這個系統可以讓使用者增加、編輯、檢視存放在 server 上的聯絡人清單。