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 上的聯絡人清單。

2014年4月25日 星期五

死法無法預測

原文網址:https://plumbr.eu/blog/you-cannot-predict-the-way-you-die


在花了一天對付另一個 Heisenbug:每當我快抓到原因,它就會變了樣;我想我在這個 case 中學到的東西應該有分享的價值。

我寫了一個簡單的範例來展示這個狀況。在這個例子中,我建立一個 Map 然後用無窮迴圈往裡頭狂塞 key-value:

class Wrapper {
  public static void main(String args[]) throws Exception {
    Map map = System.getProperties();
    Random r = new Random();
    while (true) {
      map.put(r.nextInt(), "value");
    }
  }
}

2014年4月24日 星期四

外部 JS 呼叫 Java static method

內容有點無腦,先把結論寫在前面:

外部 JS(官方文件稱為「handwritten JS」,其實不同 GWT Module 就滿足這個條件)要呼叫 Java 的 static method,必須先透過 JSNI 設定 $wnd.methodName = @fooPackage.FooClass::javaMethodName(*),後續使用 $wnd.methodName() 來達到目的。

關鍵在於 JSNI 中:

  • javaMethodName() 後頭不需再加 ()
  • javaMethodName() 的參數某些情況下可以省略 field descriptor,直接用 * 代替。

update:感謝 darkk6(ptt.cc)提醒,讓我發現我不但死腦筋,而且還少測了一種寫法… 所以文章就要重新翻修了 (艸

2014年4月5日 星期六

NIO.2 的檔案操作

前言

以往 Java 要操作檔案時,總得自己去面對 XXStream、XXReader、XXWriter,一不小心就迷失在 class hierarchy 迷宮中而搞不清楚到底該怎麼寫才好 [淚目]。NIO.2 的出現,提供了簡單好用的 method 來解決這些困擾。

這篇都還在 Java 7 的範圍。已經出的 Java 8 也對 NIO.2 做了一些改善,中文資料可先參考 Ingram Chen blog 的 File operation 章節。

2014年4月1日 星期二

GWT RPC 的 deserialize 行為與 IE8

原文網址:http://blog.oio.de/2014/03/28/gwt-rpc-deserialization-vs-ie8/


幾乎每個 web 開發人員都知道,當 JS 執行時間過久 browser 就會跳出討厭的對話框問你要不要取消。在 IE 上頭會顯示「這個網頁的指令碼造成 Internet Explorer 執行速度緩慢」。

這篇文章將說明 IE8 的特殊行為、它如何影響 GWT RPC 的 deserialize 機制、以及如何解決這些問題。

2014年3月27日 星期四

GC 對 throughput 與延遲時間的影響

原文網址:https://plumbr.eu/blog/gc-impact-on-throughput-and-latency


有一類問題是每一個 Java application 都會遇到的,那就是 GC。當 GC 正常運作時,它是一個美妙的發明;當它沒有運作、或是 GC 用出乎意料的方式運作,那你的朋友就會翻臉變成仇人。

這篇文章是關於 GC 造成的暫停時間。或著更精確地說:為什麼你要在意這些暫停時間?

2014年3月23日 星期日

如何估算記憶體需求?

原文網址:https://plumbr.eu/blog/how-to-estimate-memory-consumption

這個故事得從十年前開始說起,那時我第一次接觸到一個尖頭老闆的問題:「我們的產品要佈署的時候,需要買多好的 server?」在產品發表之後,我們花了九個月的時間打造了一個金光閃閃的新系統,顯然公司已經承諾要提供整個解決方案,包含硬體的部份。

囧… 我麻煩大了。我只有短短幾年的經驗,回答這問題跟丟骰子沒啥兩樣。雖然我看起來整個就是缺乏信心,不過我仍然得生出一個答案。在 google 了四個小時後,眼花撩亂的腦袋裡仍然是相同的問題:

「如何估算所需的運算能力?」