發表 App Engine 的 High Replication Datastore

原文網址：http://googleappengine.blogspot.com/2011/01/announcing-high-replication-datastore.html

當 App Engine 問世兩年後，我們提供設計成快速、strongly consistent 讀取的 Datastore。它是架構在 Master/Slave 式的 replication 拓樸，設計為快速寫入、同時允許 application 可以馬上看到寫入後的資料。你可能有聽說，過去六個月我們一直在設法解決一些 App Engine 上 Datastore 的可靠性問題在過去幾個月，我們在修復這些問題方面有了重大進展。然後，處理這些問題的經驗讓我們重新思考一些設計上的假設。正如我們在年初時在 outage report 當中承諾的，我們想要更徹底地解決這個問題。

今天，我們很自豪地發表一個新的 Datastore 設定選項：High Replication Datastore。因應寫入及變更資料時 API 保證一致性所增加的延遲成本，High Replication Datastore 提供最高等級的讀寫能力。High Replication Datastore 增加了維護資料副本的 data center 數量，並使用 Paxos 演算法來讓 data center 之間的資料能立即保持一致性。其中最顯著的優點，就是在預期內的維護期間、以及大多數預期外的 infrastructure 問題上，你的 application 都會保有完整的功能。我們的文件中將更仔細的比較這兩個選項。

從現在開始，當建立一個新的 application 時，你可以選擇 Datastore 的設定。雖然目前的 Datastore 設定預設值為 Master/Slave，以後可能會改變。

建立 application 時的 Datastore 設定

Datastore 的設定選項在 applcation 建立後就不能更改，而所有已經存在的 application 都是用 Master/Slave 設定。我們提供了一些遷移工具來幫助既有 application 上的資料改使用 High Replication Datastore。首先，我們在 Admin Console 增加了一個選項，讓 application 變成唯讀模式，這樣一來資料就可以確實地在 application 之間複製。其次，我們用 Python SDK 提供了一個遷移工具，讓你將一個 application 複製到另一個去。Python 與 Java 的 application 要如何使用這個工具的文件在這裡。

現在提一下關於價格的事情：因為 High Replication 會明顯地增加資料複製量，所以價格也就會不一樣。不過，我們相信這個新的設定對於一些 application 來說會顯著改良，所以我們希望儘快的提供這個功能——即使我們還沒有決定價格的細節。因此，在 2011.07 之前，我們把 High Replication Datastore 的價格定為 Master/Slave Datastore 的三倍。七月以後，我們預計會改變這個價格。我們將會儘快讓你知道價格的詳細內容，也請記得當價格變動時，你始終被服務條款所保護。由於成本較高，我們建議 High Replication Datastore 主要是用在要有最高等級可用性的特定 application 上。

（譯註：原文最後一段懶得翻譯... [逃]）

App Engine SDK 1.4.2 更新版

原文網址：http://googleappengine.blogspot.com/2011/02/app-engine-142-sdk-api-updates-and.html

現在才二月，我們就已經發表今年第二次更新啦！請到這裡下載。1.4.2 版著重於改善和更新現有的幾個 App Engine API。

加強 XMPP API 讓 application 與使用者之間有更好的互動。當使用者登入、登出或作其他狀態的改變時會發出通知，且 application 可以立刻設定 presence 細節然後回傳給使用者。Subscription 跟 Presence 的通知啟用方式就像 application 設定中的 inbound 服務。

Task Queue 效能提昇與 Task Queue API 改良。首先，我們把每秒可以執行的 task 加大到 100 個。 application 也可以針對目前的 request 在個別的 queue 的設定檔當中指定最大值。這讓你可以更輕鬆地掌控 task queue 消耗了多少資源。我們還添加了一個 API，讓你以程式的方式刪除 task，而不用到 Admin Console 裡頭手動管理。

一如往常，有許多功能與議題也做了修正，例如 JAX-WS 的支援（可參見如何在 App Engine application 中建立 SOAP），當然也支援了 Django 1.2，所以請你一定要讀一下 Java 與 Python 的更新說明。我們還更新了 App Engine 的展望圖，加了一些新的專案，所以去看看吧！。如果您有任何意見想反應，歡迎到 App Engine 社群。

回函照登 1

> hi PT2 團長：
> 在網路上看到你的文章，有關於GWT
> 冒昧相問，事實上對於 client 的 widget & object boundle 一直有很大的問題

我不太確定你的文法到底是想要表達啥
為甚麼 widget 跟 object 要 b"u"ndle 在一起

如果你要講的是某個你無法控制的（例如 3rd party library） class
要透過 GWT RPC 給 gwt 寫的 client 使用
那麼，是要透過轉換的沒錯（我書念得不多，不知道 helper 的意思）
Google 的說法是把這種 class 叫做 DTO

> 目前我們是要寫一個helper 來轉換
> 請問團長 有什麼建議的方法嗎？

如果你（也）是用 AppEngine，那可以考慮用 Objectify
另外，GWT 2.0 之後 RequestFactory 我不確定用途（是說也不太想用）
跟這個議題也許有點關係，你可以到「長草的筆記本」那裡找資料當課外讀物玩玩看

我只知道這些

> 另 1.6.4 想升到2.2 ，能不能呢 ？

為甚麼不能？

> 我自己試過從1.6 升1.7就掛光光了，頭燒到最後，只好放棄
> 感謝團長

請描述解釋闡明你的「掛光光」
不然你可能去龍山寺拜拜或是隔壁地下街找算命師會比較快

http://blog.psmonkey.org/2008/09/blog-post.html

Eclipse 的 Google Plugin 及 GWT 2.2 版問世

原文網址：http://googlewebtoolkit.blogspot.com/2011/02/google-plugin-for-eclipse-and-gwt-22.html

我們很高興在這裡分享 Eclipse 的 Google Plugin（以下簡稱 GPE）和 GWT 2.2 版 提供的幾個新功能。首先，GPE 把 GWT Designer 這個強大的 WYSISYG Ajax UI 設計工具整合進來。這可以讓你更簡單快速地建立 UI。其二，GWT SDK 支援初步的 HTML5 規格，讓開發者獲得現代 web 的優勢。此外，GWT 的 CellTable widget 現在提供了新的功能，可以設定預設的排序欄位、設定欄位寬度等。這些新的特性可以讓你用 Java 工具與 Eclipse 更簡單地做出超優的 web application。雖然這些 application 可以在任何平台上運作，不過 GPE 對於 Google App Engine 上的 deploy 與執行更為方便。

安裝 Eclipse 的 Google Plugin 以及 GWT SDK 的介紹可以在 GPE 入門裡頭找到。

如果只是單純想找 GWT 2.2 SDK，就在這裡頭。

GWT Designer
將 GWT Designer 直接整合進 Eclipse 的 Google Plugin 中，是過去幾個月的首要工作。我們從社群中得到很積極的意見回饋，在這個版本當中，我們不只要提供 GWT Designer 的最佳開發經驗，也要讓 GWT Designer 與 GPE 整合地天衣無縫。


HTML5 的功能
GWT 2.2 版支援特定的 HTML5 功能，例如 Canvas 可以讓你用 script 動態繪製 2D 圖形或 bitmap 圖，以及嵌入影音的 tag。這些 API 仍在實驗中，有可能在接下來的幾個版本中會有所改變，但我們覺得已經穩定到可以提供一些實質好處。下面式一個 GWT 團隊成員做的一個 demo，展示 GWT SDK 中對 Canvas 的支援。你可以在這裡找到這個 demo 的程式碼： http://code.google.com/p/gwtcanvasdemo/ 。

新的 CellTable API
在 GWT 2.1 版時，我們發現很多開發者常常在案子裡使用了 CellTable 這個 widget，然後馬上就貼上同樣的程式碼好加上 sort 功能，接著就不辭辛苦地設定欄位的寬度。到了 GWT 2.2 版，這些功能已經變成 CellTable 本身的一部分啦。我們可以、也想要加強原生的 GWT widget，增添功能以盡可能減少開發者必須自己撰寫的程式碼。
如果你想實際看這些更新的話，GWT Showcase 的 CellTable 範例裡頭有。

關於 Java 1.5
GWT 2.2 版將（僅）廢止 Java 1.5 的支援，這會導致 build application 時會出現警告訊息。 雖然 Java 1.5 仍然可以搭配這個版本的 GWT，開發者還是應該升級 Java 來消除這些警告、並確保未來 GWT 版本的相容性。

我們很樂意聽到你所提出的問題或是意見回饋，可以的話就到 Google Web Toolkit Group 來暢所欲言吧！

GWT 不適合開發 HTML5 上的遊戲

原文網址：http://my2iu.blogspot.com/2011/01/gwt-isnt-good-environment-for-html5.html

譯者註：這篇並沒有寫的很好，甚至後兩段已經脫離主題，變成是在思考 JavaScript 的 coding style 與 IDE 協助開發的問題。不過頭幾段倒是給我們一些關於 GWT  browser plugin 的運作原理與問題，故潦草一翻，順便當成是腦力復健 [慘笑]


去年我在 XNA 上頭寫了一個小遊戲，因為沒人玩，所以我開始把它轉換成使用 HTML5 特性的網頁遊戲。最初遊戲是用 C# 寫的，若要將它網頁化，我覺得最簡單的方法是用 Java 改寫，然後用 GWT 轉成 JavaScript。GWT 是一組 Google 提供的工具，讓你可以用 Java 寫網頁，然後它會把程式碼轉換成跨 browser 的 JavaScript 碼。

在快速看過 GWT UI frame，我發現這遠比預期的好上很多。不過很可惜的是，我發現目前 GWT 2.0 版在開發 HTML5 的遊戲方面，並沒辦法運作的很好。問題在於 development mode 中，GWT 並沒有實際將程式碼轉成 JavaScript。它會以 Java 的方式執行，然後使用一個中介層來轉換成 JavaScript ojbect 或是 browser 的 DOM，並將結果轉換回 Java 裡。起初我以為這沒啥影響，因為只有在呼叫一卡車 DOM API 或是因為某些原因要儲存一堆東西在 JavaScript object 當中，這才會是個問題。偏偏在我的 HTML5 遊戲當中就都遇到了 Orz。我在 HTML5 的 canvas 上畫了一堆東西，需要呼叫一堆 API。我也使用 JSON 來儲存遊戲資料，也就是說要用 JavaScript object 的形式存一堆東西。

結果就是，在 development mode 當中，我的遊戲執行速度慢到爆炸。這在 Chrome 上特別嚴重，因為 sandbox 的設計讓 Chrome 的 GWT development plugin 在 browser 跟 Java code 之間轉換特別慢。如果換到 Firefox 上頭就還能忍受，不過我發現我最佳化的方向有誤。看起來似乎在 development mode 才會跑的很慢（像是用 JSON 作遊戲存檔超慢讓 browser 噴了 timeout），如果實際 compile 成 JavaScript 就會很跑的很快。將 Java 碼轉換到 browser JavaScript 引擎上運作的負擔，讓開發人員很難確定遊戲實際跑起來會是啥樣子。

我明白為甚麼 GWT 會設計成這樣。JavaScript debugger API 可以讓 GWT 這類的工具將 JavaScript 碼的行數跟變數與程式設計師寫的 Java 碼作對應，但是大多數的 browser 並沒有公開這類 API。好在像 Firefox 這類的 browser 變得越來越成熟而有這類的 API，所以我期待未來有人可以重寫 GWT，可以在 development mode 時實際轉換 Java 碼變成 JavaScript，而且還是可以作 debug。

在這段期間，我會用 GWT 完成我的遊戲，然後回頭寫純 JavaScript 遊戲。我發現 JavaScript 的自由格式、非結構化性質是沒啥生產力的，但我也疑惑 Java 的 static type 會是解決這問題的最好方法嗎？當我在寫 Smalltalk 時，所有東西都可以是 dynamic type，但寫起來還是相當有效率。Smalltalk 把程式碼用很結構化的方式組織起來，所以讀程式碼或是在裡頭找東西都很容易。到目前為止，我寫的 JavaScript 程式碼風格太自由了，導致即使搭配 JDST 的 Eclipse 也無法分析的很好，只能用簡單的方法瀏覽程式碼。也許我該嘗試用比較結構的方法來寫程式，然後找看看是否有合適的編輯器可以建立出有用的架構，從而讓我讀寫 JavaScript 碼時更有效率。