作為 Sencha GXT 的團隊代表，我很高興宣佈 Sencha GXT 3.1 發布。在公開測試後只有一兩個月的時間，我們收到一卡車的回饋意見。我們已經解決幾個來自公開測試討論區的問題。感謝所有前期測試人員，你們的回饋意見始終是非常寶貴的。
GXT 3.1 導入了新的 Theme Builder（妝點 GXT 程式的新工具）、Neptune 這個佈景主題就是用 Theme Builder 做出來的；另外 GXT 3.1 也增加了對 GWT 2.6 的支援度。
（譯註：省略兩段純粹提供 3.1 各式連結的部份）
我大概是當完兵之後才開始用 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 阿？
原文網址：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 上的聯絡人清單。
原文網址：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");
}
}
}
內容有點無腦，先把結論寫在前面：
外部 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）提醒，讓我發現我不但死腦筋，而且還少測了一種寫法… 所以文章就要重新翻修了 (艸
以往 Java 要操作檔案時，總得自己去面對 XXStream、XXReader、XXWriter，一不小心就迷失在 class hierarchy 迷宮中而搞不清楚到底該怎麼寫才好 [淚目]。NIO.2 的出現，提供了簡單好用的 method 來解決這些困擾。
這篇都還在 Java 7 的範圍。已經出的 Java 8 也對 NIO.2 做了一些改善，中文資料可先參考 Ingram Chen blog 的 File operation 章節。
原文網址：http://blog.oio.de/2014/03/28/gwt-rpc-deserialization-vs-ie8/
幾乎每個 web 開發人員都知道，當 JS 執行時間過久 browser 就會跳出討厭的對話框問你要不要取消。在 IE 上頭會顯示「這個網頁的指令碼造成 Internet Explorer 執行速度緩慢」。
這篇文章將說明 IE8 的特殊行為、它如何影響 GWT RPC 的 deserialize 機制、以及如何解決這些問題。
原文網址：https://plumbr.eu/blog/gc-impact-on-throughput-and-latency
有一類問題是每一個 Java application 都會遇到的，那就是 GC。當 GC 正常運作時，它是一個美妙的發明；當它沒有運作、或是 GC 用出乎意料的方式運作，那你的朋友就會翻臉變成仇人。
這篇文章是關於 GC 造成的暫停時間。或著更精確地說：為什麼你要在意這些暫停時間？
原文網址：https://plumbr.eu/blog/how-to-estimate-memory-consumption
這個故事得從十年前開始說起，那時我第一次接觸到一個尖頭老闆的問題：「我們的產品要佈署的時候，需要買多好的 server？」在產品發表之後，我們花了九個月的時間打造了一個金光閃閃的新系統，顯然公司已經承諾要提供整個解決方案，包含硬體的部份。
囧… 我麻煩大了。我只有短短幾年的經驗，回答這問題跟丟骰子沒啥兩樣。雖然我看起來整個就是缺乏信心，不過我仍然得生出一個答案。在 google 了四個小時後，眼花撩亂的腦袋裡仍然是相同的問題：
「如何估算所需的運算能力？」
原文網址：http://googlecloudplatform.blogspot.tw/2014/02/app-engine-190-now-available.html
今天我們宣佈 App Engine 1.9.0 發布，包含 Modules API general availability（GA）、新版 Java MapReduce library、以及加強 PHP runtime。