以 Google Visualization API 取得資料

在 Google Visualization API 中定義了一套 Query Language，用來規範一種資料查詢、輸出的協定，使得 Visualization API 中的各種圖表元件，在讀取資料這塊有個固定的格式，只要任何「資料來源」按照這套 Query Language 來實作，都可以輕易地利用 Visualization API 畫出各種圖表。而在 Google 的服務中，Google 試算表（Spreadsheet）已經實作了這個協定，所以你也可以把資料放在 Google Spreadsheet 中，再使用 JavaScript 利用 Visualization API（其它語言當然也可以）來取得資料。

假設我在 Google 文件中建立了一個試算表，並且輸入了像這樣的表格資料：

接著我將這個試算表的權限設定為「Public on the web」（如下圖所示），於是你可以得到一個公開存取的 URL，裡面就有這份試算表的 key，將它記錄下來，稍後便會利用這個 key 來存取資料。

接著，你便可以在某個網頁裡這樣讀取這份資料：

[HTML 部份]
<!-- 載入 Google AJAX API Loader -->
<script src="http://www.google.com/jsapi"></script>

...
[JavaScript 部份]
// 載入 Visualization API
var URL = 'http://spreadsheets.google.com/tq?key=<你試算表的 key>';
google.load('visualization', '1');
var query = new google.visualization.Query(URL);
// 使用 query language 查詢資料
query.setQuery('select B, C where C > 50');
query.send(function(resp){
  if (!resp.isError()) {
    var dataTable = resp.getDataTable();
    var jsonData = JSON.parse(dataTable.toJSON());
    ....
  }
});

透過這樣的方式，你就可以利用 Query Language 來篩選要讀取的資料，在這個例子中則是會回傳兩筆資料（因為 C column 的值大於 50 的只有兩筆），而回傳之後也可以轉成 JSON 格式的資料來使用（上面的 JSON 物件並不是所有瀏覽器都有內建，如果要確保所有瀏覽器都能用，請使用 json2.js），十分方便，而資料的攞放的欄位也有一點點特別，像是這樣：

....
// 讀取資料每一個 row 的資料
var len = jsonData.rows.length;
for (var i = 0; i < len; ++i) {
  var row = jsonData.rows[i];
  // row.c[0].v 這是 B column 的值
  // row.c[1].v 這是 C column 的值
}

因為我們在上述的查詢語法中，只有 select 出 B 及 C 兩個 columns，所以它會將資料放在 row.c[0] 及 row.c[1] 之中，不過這個資料結構還有儲存像是資料型態的資訊，所以要存取它的值，就要讀取它的 v 成員變數。這樣就可以利用 Google 試算表做一個簡單的資料來源，在建立資料時可以上 Google 試算表用它的介面輸入，而網頁呈現則可以另外製作。

COSCUP 2010 的 Mobile Web App 在 Sessions/Schedule 頁面的資料就是利用這個方式存取遠端 Spreadsheet 的資料，這樣工作人員只需要利用 Google 文件的頁面修改資料，web app 的部份完全不需要修改。

至於 Query Language 可以怎麼使用，或是要怎麼讓自己的資料來源符合輸出規範，這部份就參考官方文件吧！

以 JSON 方式取得資料

當然，如果你不想使用 Visualization API 也沒關係，只要在你「發佈」（右上角的 Share 按鈕，有個 Publish as a web page）了這份文件時，就可以選擇以各種格式輸出，如下圖所示：

如果你要 json 格式的資料，雖然這個介面上目前沒有 JSON 格式可以選擇，但是你可以先選擇 RSS，再將網址中的 alt=rss 改成 alt=json 就能透過該 URL 輸出 json 格式的資料囉。

今年五月時我飛到美國舊金山參加了 Google I/O 2010 這個年度盛會（當時的速記），出發前 Google 不但一人送了一臺 Nexus One（或是 Droid），同時官方也弄了一個專屬 Google I/O 這個研討會的 Android App，這個軟體讓你可以在手機上瀏覽會場資訊，包括會場平面圖、議程資訊、寫筆記等等，如果你有興趣的話，Google 的工程師也有將它 open source 出來，你可以感受一下它的用途。

後來我決定參加台灣開源界一年一度盛事－－COSCUP 2010 之後，聽聞這次 HTML5 是個很大的主題，我就突然興趣想用 HTML5 來仿製那個 Google I/O App，除了提供參加者一個方便的途逕即時利用手機（其實只支援 iPhone/Android）查詢資料之外，也暗自呼應 HTML5 這個主題，如果你有興趣嚐試，可以拿出你的 iPhone/Android，用（內建的）瀏覽器開啟：http://bit.ly/coscup-mobile 這一頁（或是使用下方的 QR-code）

雖然做得沒有像 Google I/O 那個軟體那麼完整，而且我也因為自己能力有限、時間不足的情況下擠出了這個野人所獻的曝，還請大家多多包含。不過為了補償我這不專業的成果，我會陸續將我開發這個 webapp 的過程、心得及手法找時間寫出心得分享的文章，讓大家一起討論、一起學習 HTML5。目前我有用到的相關技術大致上如下：（好像很多 Google API/service….沒辦法，誰教我現在是 Taipei GTUG organizer 呢 XD）

• Google AppEngine
• Google Storage
• Google Visualization API Query Language
• Google Maps API
• HTML5
  • Web Storage
  • Web Database
  • Application Cache
• CSS3 Box Layout
• 其它（？）

目前從這則噗浪中好像還有一些朋友發現了幾個問題，吃燒餅難免掉芝麻，寫程式一定會有 bugs 的，如果看到這篇文章的朋友還發現了什麼問題，歡迎提出您的看法，我會努力想辦法去解決它的！還請大家多多指教囉～

前情提要

因為義務幫忙今年的 COSCUP 製作了一個 webapp 供參加者來使用，目前已經接近完成（因為有別的事在忙，所以拖了有點久）的階段，過幾天會正式放出來給大家使用，不過我先寫一些製作的心得分享文。

什麼是 ImageMapType

在 COSCUP Mobile WebApp 中的「Maps」部份，為了顯示出活動地點的室內平面圖，這個東西是我參考 Google I/O 2010 提供的會場地圖的方式而製作出來，使用自己繪製的平面圖疊加在原本的衛星圖資之上，它的顯示效果如下所示：

如果你曾經有注意過 Google 與電影「赤壁」合作過的活動網頁，你會發現其中有一個呈現赤壁古戰場風貌的地圖小工具（Mapplet），而它也是利用了 ImageMapType 的方式將古地圖貼上去。若是你也有類似的開發需求，不必抓破頭煩惱怎麼把自己的圖片疊上去而寫出複雜的 JavaScript 程式碼，只需要利用 Google Maps JavaScript API v3 中的 ImageMapType 部份的 API 就可以完成，只不過在實務上該怎麼進行，以及要注意的事項在目前的官方文件並沒有寫得很清楚，這篇文章將會介紹我是如何完成這個效果，以及開發時的心得。

Google地圖圖資規格

Google 地圖的圖資是以一堆正方形的 tiles 所組成，每一個 tile 的大小是 256px * 256px（不論縮放，不同縮放大小就是不同的 tile，但大小都是 256px * 256px），而每個 tile 有 z, x, y 三個屬性，z 是表示縮放大小，而 x, y 則是 tile 在全球圖資中的 x, y 座標（與經緯度的值相關，但座標系統不一樣）。以中研院人文資訊大樓為例，若在縮放等級18時，圖資的 tiles 是這樣排列的：

這個示意圖我以紅線作為 tiles 的分界（只是畫個大概，不用真的去量是不是 256px * 256px），而淺藍色的座標數字則表示該 tile 的z, x 及 y 值。如果你要利用 Google Maps API 中的 ImageMap Overlay 來疊上自己的圖片，你必須「做出覆蓋原先 tiles 的 tiles」才能蓋上去，也就是在這個縮放等級之下，我至少要自行製作兩個 tiles 才能把目標物給覆蓋住，最後的成果便是這兩張圖（僅3樓的部份，注意空白的部份其實是透明的）：

為了方便起見，我將這兩張圖的檔案名稱根據 Google Maps 圖資的座標來命名為「t_18_219626_112227.png」及「t_18_219626_112228.png」，數字分別對應到 z, x, 及 y，至於為什麼要這樣做，接下來就要介紹 ImageMap Overlay 的使用作法。

使用ImageMapType API

API的詳細使用方法可以參考 Google Maps API 的文件，我這裡大概說明一下程式碼大概需要怎麼寫。在你建立好一個 mapInstance 後，使用 ImageMap 的程式嗎如下：

// ImageMap Overlay 的選項
var imgMapTypeOpt = {
 ‘getTileUrl’: function(coord, zoom) {
   var url = [‘http://tiles.example.com/t_’, 
              zoom, ‘_’, coord.x, ‘_’, coord.y, ‘.png’].join(‘’);
   return url;
 },
 ‘isPng’: true
};
// 建立 ImageMap Overlay type
var imgOverlay = new google.maps.ImageMapType(imgMapTypeOpt);
// 疊在 Map 上，mapInst 是前面建立地圖時 new google.maps.Map 的物件
mapInst.overlayMapTypes.insertAt(0, imgOverlay);

一旦在 map 上加上 ImageMapType 之後，當 Google Maps API 把原本的該顯示的圖資（也就是你看得到的範圍）顯示完畢後，接著會根據每一塊顯示出來的 tile（注意這段話，等一下會發生問題），藉著你提供的 getTileUrl 這個 callback function 來找出期望疊加在原有 tile 上的圖片，也就是說，當 Google Maps API 在顯示 (18, 219626, 112227) 這塊 tile 時，根據這段程式碼的設計，它會試著去讀取 http://tiles.example.com/t_18_219626_112227.png 這張圖片，因為它在呼叫 getTileUrl 這個 callback function 時就得到了這個回傳值，這就是上面提到，為什麼把圖片的檔名對應到座標，如此一來才方便你寫 callback function。這樣一來，Google Maps API 只要讀取到對應座標的圖片，就會自動疊加上去了。

產生的問題以及解決方案

假設你已讀懂上一段的敘述，接下來就會產生幾個問題：

1. Maps API 會依照「可視範圍」來尋找 image overlay 的位置，這在大多數的狀況是完全沒有必要的。因為以我做中研院大樓的例子而言，在縮放等級18時我只需要疊加兩張 tiles ，但是我的可視範圍可能是好多塊 tiles，這就多花了很多時間在讀取空的資料（例如從檔案伺服器那裡要到了一堆 404 的回應），除了發出了沒必要的 http requests 之外（也暴力地打你的檔案伺服器），因為這個 API 是在 client 端執行的，也會拖慢 client 端瀏覽器的效能。

   所幸當 getTileUrl 的回傳值若為空字串時，Maps API 就會判斷該座標不需要去抓圖，所以只要輕鬆設定一個座標範圍的檢查就可以解決發出過多 requests 的問題，像是這樣：

   
   getTileUrl: function(coord, zoom) {
    ....
    if (coord.x < BOUND.west || coord.x > BOUND.east ||
        coord.y < BOUND.north || coord.y > BOUND.south) {
       return “”;
     } else {
       return url;
     }
   }
   

   這樣的簡單的判斷法雖然不保證 100% 避免浪費的 requests，但至少已經縮減了很多 trivial 的不必要，若是你的 image 分佈得不是很均勻，可就要好好複習一下幾何演算法，有效地判斷什麼時候才該回傳圖檔、什麼時候回傳空字串。

2. 在上面的例子中，我只示範了在縮放等級18的顯示效果，事實上我做了縮放等級17, 18及19的效果，所以我必須依照不同縮放等級而準備不同的 tiles（實際數據是，單以3樓為例，z=17 有2張，z=18有2張，z=19有5張，所以兩層樓都做下去就要準備18張圖），既然我已經確定我只做這三個縮放層級，那我可以在 imageMapTypeOpt 選項中加入兩個屬性，用來限制 maps api 不要在其它縮放層級還去呼叫 getTileUrl：
   

   var imgMapTypeOpt = {
    ....
     minZoom: 17,
     maxZoom: 19
   };

3. 另外就是我雖然切換了兩層樓，但在地球上這兩層樓是同一個經緯度座標呀（廢話！）！所以對應到的 Google Maps 圖資 tiles 也是一樣，這裡就要在另外從檔名及 JavaScript 來下手，細節我就不贅述了，不過重點是：如果要更換 ImageMapType 的話，記得要先將原本的疊加層先移除，然後再加入新的才行（產生過的 imageMapType 記得存下來，不要每次都 new 新的）：
   

   
   if (mapInst.overlayMapTypes.length != 0) {
    mapInst.overlayMapTypes.removeAt(0);
   }
   // 這裡再加另一個 imageMapType
   

4. 到現在我們都瞭解 Google 圖資的 tiles 有座標了，那我要怎麼知道它的座標到底是啥啊！而且又要怎麼知道到底 Google 圖資的 tiles 是怎麼切割的？身為一個網頁前端工程師，我不相信你不會使用 Firefox + firebug 或是 Chrome + devtools 來「分析」一個頁面在載入的過程中到底讀取了什麼東西……..嗯，剩下的就看你是不是一個合格的前端工程師囉 :P

結論

經過我這樣隨意地解釋之後，想必你也瞭解使用 ImageMapType 並不會要寫多麼複雜的程式，因為所有的苦工都是在處理圖片、對準 tiles 啊！ XD 如果你本身就很熟悉影像工具的話應該會減輕這方面的負擔。

最後希望大家若是有使用 Google Maps API 介接圖資的用途時，不妨考慮做出更多具有自己風格的 ImageMap Overlay 吧！

前幾天 Google 發表了 Android App Inventor 這樣的 web application，旨在讓想開發 Android app 的人可以有這樣的工具來達到目的，而且未來 Google 也打算與學校合作，以此工具做為開發 android app 的入門。

目前這個 web application 還需要等候邀請才能使用，不過筆者有幸在今日得到使用的機會，所以簡單地向各位介紹一下 app inventor 是怎樣的東西。

在使用前，必須先到這裡學習怎麼使用，並且安裝軟體讓這個 webapp 能夠連接到你的手機。在進入 app inventor 後，首先進入的第一個畫面如下所示－－一個很簡單的 project list，你可以在這裡新增 projects：

App Inventor 的 Project List view

而建立 project 之後，開發畫面就如同大家在各報導中看到的一樣，是一個很標準的 visual design 工具－－左側欄是 widgets 列表，可以拖拉到中間的手機畫面，而右側則是調整 widget 屬性的區域：

App Inventor 的 project 主畫面

比方像是這樣：拉了一個 button 到畫面之後，在右側去修改它的屬性：

設計 app 中的 widget

而拉出一個按鈕後，自然會想要去設計它被按下後的動作，此時可以按下右上角的「Open Block Editor」的按鈕，接著會提示你要透過 Java Web Start 啟動一個 java app（當然就是這個 block editor）：

Block Editor 是一個 Java app

在 Block Editor 中就可以針對 widget 來處理各種事件所要觸發的動作：

處理 Button1 的各種事件

就像是拼拼圖一樣地作設計，我這裡示範的是：在按鈕被按下後，將下面的文字框中設定「Clicked」的字樣，你只需要設計 app 的運作邏輯，在寫這樣簡單的程式時，幾乎不用寫到一行程式碼：

拼拼圖

接下來當然是可以將這樣的 app 下載到電腦上，或是已經連結好的手機上。

感想

App Inventor 是還蠻有趣的東西，設計出來的 app 也真的可以裝到手機上，不過當然它還不容易寫出高品質、很複雜的 app，但這樣的概念至少有機會讓很多人躍躍欲試，體驗一下開發手機應用程式的感覺。而在使用上來看，目前還必須連結一個 Java App 是有點麻煩，使用上就少了流暢感。畢竟目前還是放在 Google Labs 下，說不定之後「畢業」時有更順暢的使用體驗，只好再慢慢期待它的改進囉。

HTML5 中有一個「Offline Web Application」的規格，簡單來說，就是你可以告訴瀏覽器

「哪些東西請 cache 在你那裡，哪些東西一定得上網路抓，在沒有網路連線時應該使用哪一個 html 檔案來開啟」。

而你需要做的，只是準備一個檔案提供這些資料，當（支援這個規格的）瀏覽器讀取時便會自動 cache 住該 cache 的檔案。

假設有一個這樣的 html 檔案（sample.html）：

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>測試</title>
    <link rel="stylesheet" type="text/css" href="sample.css">
  </head>
  <body>
    <img src="http://example.com/path/to/file.jpg" alt="">
    <script src="sample.js"></script>
  </body>
</html>

這個網頁（或者說是 web application）需要 sample.html、 sample.css、sample.js 檔案以及 http://example.com/path/to/file.jpg 這個圖檔才能運作，那麼可以利用 HTML5 application cache 的機制將前三個檔案 cache 在 local 端，只有圖檔是上網抓，這樣可以大大減少瀏覽器的 request 數目。

所以根據規格，你可以準備一個 sample.manifest 檔案，內容如下：

CACHE MANIFEST
sample.html
sample.css
sample.js
NETWORK:
*

這個檔案在 server 上必須要以 text/cache-manifest 的 MIME type 送出，而為了讓瀏覽器知道有這個檔案，則加在 <html> 標籤中：

<!DOCTYPE html>
<html manifest="sample.manifest">
...

如此一來（支援此規格的）瀏覽器便知道要去下載 sample.manifest 來看看要 cache 什麼檔案，所以之後瀏覽器就知道遇到這些檔案可以直接從 local 端拿，不必再到 server 端讀取，除了離線支援之外，就有是有連線的狀況也可以省下不少網路傳輸（讀取）的時間。

關於 manifest 檔案中的語法，建議參考規格書的內容（因為都還在 draft）。

當然，有 cache 就會有 cache invalidate 的問題，也就是當被 cache 住的檔案有更新的時候，要怎麼讓瀏覽器知道呢？你可以利用 JavaScript 操作 window.applicationCache 這個物件來瞭解 cache 的狀況，除了可以利用 applicationCache.status 取得 cache 的狀態之外，也可以手動透過 applicationCache.update() 來進行更新的動作。此外，在操作 cache 時可以檢查 navigator.onLine 的值來確定瀏覽器目前是否有網路連線。

實例參考

如果你有使用 iPhone/Android 手機連上 Google 的行動版網站，你可以發現只要你曾經連過那些網站，下一次在瀏覽器開啟時，畫面很快就出現了，其餘可能需要網路連線（檢查你的位置、讀取遠端資料庫等等）的部份是稍候才會開始動作。這就是利用 application cache 讓你的手機先將畫面的部份 cache 起來，所以不但開啟時很快就可以讀出畫面，就算手機在沒有網路連線的狀態下，還是可以看到畫面。試想一下，手機的連線、傳輸都較有線網路慢上許多，有這樣的 cache 機制可以讓你的 (mobile) web application 更加 responsive，而若是搭配 local storage 或是 local database 那就有更完整的離線支援（如：Gmail 行動版）了。

References

• Offline Web applications
• Creating mobile Web applications with HTML 5, Part 3: Make mobile Web applications work offline with HTML 5
• Gmail for mobile HTML5 Series: Using AppCache to Launch Offline – Part 1

要在 HTML 中做排版（layout）一直是前端工程中的一件苦差事，最初人們都是使用 <table> 元素作為排版的輔助工具，甚至許多 WYSIWYG 編輯器、GWT 等工具也都是這麼做，可是利用這種方式作排版，除了彈性不高之外，也容易堆疊出過份冗長的 HTML 碼，後來前端工程師、設計師們開始瞭解可以利用 CSS 中的 float, inline-block 等屬性來完成排版的需要。然而，伴隨而來的卻是更不直覺的程式碼，而且還要處理更多對齊、水平垂直置中的問題。

CSS3 中的 Flexible Box Layout module 試著制定出更有彈性、更簡單的 layout 方法。直接以一個例子來看，很多網站會做出像這樣的三欄式版面：

當然，就算不使用任何 CSS3 的功能也可以做出像這樣的版面，只是你可能會絞盡腦汁去想到底要怎麼完美搭配 float、position:absolute、margin、clear 以及 <div> 的排列來達到你的效果。但要是我用 CSS3 來做這樣的版面，code 大概會像是這樣（以 WebKit 系的瀏覽器作示範）：

[HTML部份]

<div id=”container”>
  <div id=”left” class=”sidebar”> ... </div>
  <div id=”mid”> ... </div>
  <div id=”right” class=”sidebar”> ... </div>
</div>

[CSS 部份]

#container {
  ...
  display: -webkit-box;
  -webkit-box-align: stretch;
  -webkit-box-orient: horizontal;
}
#mid {
  -webkit-box-flex: 1;
}
.sidebar {
  ...
  width: 180px;
}

如此一來便能輕鬆、直覺地做出三欄式的版面，可以到這裡看一下顯示的效果（記得用 Safari/Chrome 這類 WebKit 系的瀏覽器開啟）。

簡單地解釋一下這個例子，我們在 #container 中設定了 -webkit-box-orient 的屬性，瀏覽器便會依照設定的值來排版 #container 的子元素（也就是 #left, #mid 及 #right），在此例中由於 #left, #mid 及 #right 是以水平方式排列，所以將值設定為 horizontal；而 -webkit-box-align 的屬性則是指定子元素在排列時如何對齊母元素，可以設定 start|end|center|baseline|stretch 等值，這裡設定成 stretch 是為了讓子元素的高度變成與母元素相同（因為 box-orient 是 horinzontal，所以 stretch 會往垂直的方向延伸）。

（思考一下：所以水平、垂直置中就簡單多了吧～）

至於左右兩個 sidebar 沒就沒什麼特別，只是單純地用 width: 180px 來指定大小而已，有趣的是 #mid 中 -webkit-box-flex 屬性，它可以設定該元素在剩餘空間中的佔有比例，預設為0.0（可用浮點數）。在這個例子中，#left 及 #right 都已經設定了 width: 180px，那若是 #mid 設定了 -webkit-box-flex: 1，則表示 #mid 會佔有 #container 剩餘的空間。如果你覺得這樣的說明很難懂，那下面有個簡單的例子：

[HTML]

<div id=”container”>
  <div id=”left”>Left</div>
  <div id=”right”>Right</div>
</div>

[CSS]

#container 與上述同
#left { -webkit-box-flex: 1 }
#right { -webkit-box-flex: 1}

這樣一來，#left 及 #right 會在 #container 下佔有 1 : 1 的比例，也就是說這兩個元素會平分 #container 的空間。若是將 CSS 的部份改為：

[CSS]

#left { -webkit-box-flex: 1 }
#right { -webkit-box-flex: 2}

那佔有比例就會成為 1:2，#left 佔有 1/3 的空間，而 #right 則佔有 2/3。-webkit-box-flex 的值預設為 0.0，所以若是該 box 沒有指定大小的話，則會依照內容的大小動態決定。

當然，CSS3 的 Flexible Box 還有其它調整排版的屬性及效果，如果有興趣的話則可以參考 W3C 的規格書草案：[Ref] CSS3: Flexible Box Layout Module。瞭解之後，你是不是能夠利用這個模組隨心所欲地做出你想要的排版呢？

而在這樣的平台之下，使用者便可以在 Chrome （泛指 Google Chrome, Chromium, 以及 Chrome OS）上面安裝「應用程式」，當然，這個應用程式的運作平台就是 Chrome 這個瀏覽器，於是你也可以猜想得到－－應用程式是以 HTML/CSS/JavaScript 所開發的，而隨著 Google 一直宣傳著 HTML5 Rocks ，對於有志於開發「Chrome App」的人來說，當然是選擇 HTML5 再加上 CSS3 作為開發技術囉。（平衡報導一下：只要是目前能在 Chrome 上使用的網頁技術都可以啦，如 Flash、Native Client 都可以，不然怎麼會有植物大戰殭屍、樂高星際大戰呢 :P）

Chrome 裝了 Chrome Apps 的開始畫面

在目前的 Chrome dev channel 版本或是 Chromium nightly build 都已經開始支援 Chrome App 這個功能，不過還沒有預設開啟，不過可以透過在啟動 Chrome 之前傳入 --enable-apps 的參數來開啟 Chrome App 的支援，以 Mac 版為例，簡單的方法可以在終端機下以這樣的指令來啟動：

open '/Applications/Google Chrome.app' --args --enable-apps

在 Windows 上則可以去修改桌面捷徑的內容。

要開發 Chrome App 可以參考這個官方文件，但由於目前還算是早期測試，所以文件規格會突然變動，當你哪一天發現自己寫的 Chrome App 不會動的時候，可以來這裡看看，或是到討論區看看有沒有新消息。

至於 Chrome App 的結構，與 Chrome Extensions 的結構幾乎一模一樣（參考：開發文件）－－用一個資料夾將一個 app 裝起來，而裡面至少有一個 manifest.json 檔案，用來描述 app。Chrome 官方以 Google Maps App 為例，示範了如何將一個原本就是 web application 的網站包裝成一個 Chrome App。

而當你將 Chrome App 寫好了之後，可以就像開發 Chrome extension 那樣，在 chrome://extensions 這一頁，打開「開發人員模式」，再「載入未封裝擴充功能」將這個 app 載入即可。

安裝 chrome app 的方式與 chrome ext 一模一樣

而 Maps App 安裝好就會像是這樣：

如果你想將原本的 webapp 包裝成 chrome app 是非常簡單的事，但若是你要開發一個單獨執行（standalone）的 webapp（非網站），那也可以將 manifest.json 中的 app 部份修改像是這樣：

...
"app": {
  "launch": {
    "local_path": "main.html"
  }
}
...

以 local_path 來指定 app 啟動的 html 檔案，作為 app 的進入點。這裡有一個從 Chromium 討論區上網友分享的作品－－Ajax Animator（需先開啟 chrome app 功能再下載安裝），還蠻有模有樣的（以 ExtJS 所開發的一個 app），也許你可以由這個 app 來發現究竟可以在 chrome 這樣一個應用程式平台玩出什麼樣的可能性。

如果你覺得學習 HTML5, CSS3 （可能為了得支援過時的瀏覽器等等的原因）無法應用在現有的網站產品上，那麼，相信在 Chrome 這個「平台」上，會有很多發揮的空間。

之前在 tossug 的 HTML5 讀書會中負責關於 CSS3 一些視覺效果的部份，以下是我整理一些重點的投影片：

在這則 google wave 中可以看到一些 demo sites。

Google 在今年的 Google I/O 中公佈了 Google Storage，它是一個類似 Amazon S3 的網路檔案儲存的服務，目前還只有 Developer Preview 版本，有參加今年 Google I/O 的人應該申請都通過且能試用了，所以這裡稍微跟各位讀者介紹一下這個服務的概貌。

Google Storage Manager

Google Storage 提供了一個網頁的操作介面讓你可以建立 Bucket，然後在 Bucket 中放置目錄、檔案等，Bucket 的命名空間是全球使用者共用的（不是依帳號區別）。每個檔案也可以設定存取權限，讓你可以用來做任何用途。比方說，要與朋友分享檔案，或是用來作為網站、應用程式的「圖床」（透過一個公開的 URL）等。下面這張圖就是我放在 Google Storage 的 png 檔。

如果你是個開發者，也可以使用 GSUtil 這個 command line 工具來操作 Bucket 的建立刪除、檔案的上傳、下載、更改權限等等，或者是利用 GSUtil 中的 boto 這個 python 模組來整合到程式中來使用。真是一般使用者或 geeks 兩相宜。

未來 Google Storage 會依照容量、流量、request 次數等來計費，如果有雲端儲存需求的人，可以自行評估自己的需求來看是否划算。

約莫在去年底，Google 放出 Google I/O 2010 的消息，由於是 Taipei GTUG 的 organizer，消息一出來後，就一直被負責 GTUG 事務的 Googlers 「勸進」，而且又有一點門票票價的優惠，就在一股「Try It!」的熱血之下報了名，與 Taipei GTUG 的朋友 gasolin 及 htchien 一同前往 Google I/O 2010。

事實上，這是我第一次去美國、第一次坐那麼長途的飛機、第一次參與全英文的研討會、第一次參加 Google I/O，不知道是不是這麼多第一次所帶來的興奮，讓我完全不受時差的困擾，可以在抵達 San Francisco 的隔天就能到處 sightseeing；可以在回台灣不到12小時內再完成 Google CodeJam 2010 的第一回合參賽。

值得一提的是，San Francisco 感覺很漂亮，差點就要唱首 I Left My Heart in San Francisco 了。

參觀藝術宮

當然要去金門大橋

搭乘 Cable Car 亂晃舊金山

至於 Google I/O 的 keynote，想看的朋友可以在 YouTube 上觀賞，雖然兩天開場的 keynotes 都可以在 YouTube 上找到，但是第一時間就聽到發表（還有 Google Nexus One 及 HTC Evo 4G 的禮物）、能更深入瞭解 Google 技術的議程（這就沒有 YouTube Live 轉播了）、現場的廠商成果（火力）展示區、認識了一些朋友、以及逛逛一部份美麗的 California（加州），這些都是讓此次旅程值回票價的因素。

搭建中的廠商展示區

聽議程中，圖中的講者為 Python 之父：Guido van Rossum

拜見負責全球 GTUGs 事務的 Stephanie

Taipei GTUG被標示在 GTUG Lounge 的大地圖上

雖然現在還不知道我會不會參加 Google I/O 2011，但是如果你也對於 Google 技術感興趣，又想進行更深入的瞭解，我推薦讀者可以認真考慮參加看看，一定會很有收穫的（但我不知道會不會又那麼大手筆送禮物了 XD）。