[googleIO] 2018 年 Google IO 講題分類統計

2018 Google IO 已經開始，從講題分類統計，看今年 Google 的重點方向。

今年的分類跟去年差不多，統計如下：

AR & VR: 13
Accessibility: 8
Ads: 8
Android & Play: 122
Assistant: 24
Cloud: 33
Design: 28
Firebase: 26
Flutter: 11
Identity: 13
IoT: 18
Keynote: 13
Location & Map: 6
Machine Learning & AI: 26
MISC: 38
Nest: 1
OpenSource: 2
Payment: 6
Web: 53

今年很強調 Android，Web。


去年的重點統計：
Firebase 場數有 24 場
Mobile Web 場數有 20 場
Cloud 為 12，Android 為 11。

[gae]很久沒寫 GAE 程式了，很多東西變了

很久沒寫 GAE 程式來，看來這世界有改變。

1. 現在採用 webapp2 來當 web framework。
2. 以前的 master / slave 的 data storage 已經要廢除。要改用 High Replication Datastore (HRD)。不過，使用者應該沒什麼感覺。程式幾乎還是一樣。https://developers.google.com/appengine/docs/python/datastore/usingmasterslave
3. python runtime 支援到 2.7 ！
4. 在旁邊的連結有看到 GAE for PHP ！

真的，久沒寫，真的會忘光光…。

突然想到，會不會哪天發現 GAE for Node.js ？

[windows]程式更新機制自動化的考量(3)-各角色工作描述

在 google 的 Omaha 中，主要分成三個部份，也就是三個角色，這三個角色在整個流程的工作大致已經描述過(前文一、前文二)。接下來，則是再詳細說明，各個角色的工作項目的內容。

Client

Omaha client 是 windows 應用程式，經由客製化的 windows 安裝程式 安裝至 windows 環境中。Omaha client 有以下的功能：

• 在所在的主機上，安裝及更新 google 應用程式。
• 定期與 update server 交談，決定是否有需要做更新。
• 提供簡單的進度條畫面，可通知使用者，「 omaha client 的初始安裝」已經發生。
• omaha client 具有提升權限的功能。就算應用程式執行在低權限的等級時，依然可以讓應用程式更新自己。
• 提供一個程式當機回報機制，讓應用程式使用。

client 可以平行處理多個下載，多個循序的安裝，也可以續傳或重新下載檔案。

client 不是一個獨立的應用程式，所以它不能單獨被移除。它應視為是應用程式的一部份，當最後一個 google 應用程式被移除時，它會自行移除。

為了要回報安裝及更新的報告，omaha 包含了一個通用的程式當機報告的機制給 google 應用程式使用。其中使用了 Breakpad 專案的 network library，而 client，會處理 local minidump 的儲存，報告的佇列動作。

Omaha client 由兩大部份組成：

• Runtime，處理所有的更新及安裝 service。

• Web browser control (Active X for IE，NPAPI for others)，這允許 google 網頁及 google 應用程式可以要求 runtime 做一些事情。

Client Runtime

Client runtime 擁有下列的功能：

• 自動啟動，如此才能為所有的應用程式服務。
• 依需求，提升權限，以執行安裝及自動更新。
• 自動更新的輪詢(polling)。
• 從 google download server 下載安裝檔。
• 執行 google 安裝檔。
• 一個持久的工作佇列，以達成平行處理可重開始的下載工作及安裝工作。
• 進度條及狀態畫面的掛勾(hook)，UI 程式可以從這知道狀況。
• 自我解安裝，當最後一個註冊的應用程式被解安裝的時候。
• 報告安裝成功或失敗。
• 使用狀況收集
• google 應用程式的當機報告的回報機制。
• 認證及驗證安裝檔。

 

執行模型

Runtime 的功能，被分成數個行程 (process)。最明顯的是核心行程及許多的工作者行程 (worker process)。設計成如此有一些理由：強固性、以最小權限執行、儘量以登入者的身份執行 google 安裝檔、避免長生命行程的資源消耗或佔用。

Runtime 核心的執行模型有兩種，端看 Omaha 是如何被安裝的。

1. Omaha 安裝給整台電腦。這需要使用者有管理者權限。在這個情況下，有一個 Windows service 是使用 SYSTEM 身份執行。它會分配許多工作給工作者行程。在更新整機安裝的應用程式(per-machine applications)時，工作者行程也是用 SYSTEM 身份執行。當工作都結束時，工作者行程會自己關閉。
2. Omaha 只安裝給現在使用者。這個情況就不會有 service 安裝其中，也沒有更新整機安裝應用程式的時機。所以執行模型只有 goopdate 工作者行程，會在登入使用者的 interactive session 中。

在不同的作業系統(Windows 2000, XP, and Vista)執行的行為要一樣，這一點的要求是非常重要的。同時，核心行程在「整機安裝」、「使用者安裝」的執行模型也幾乎一樣。在大部份情況中，整機安裝與使用者安裝的安裝資訊是隔離的。

有一種情況，Omaha 為了整機安裝，使用 local system 身份執行了一個核心行程，為了使用者安裝，也使用目前登入使用者的身份執行一個核心行程。這種狀況就會執行兩個核心行程。這裡可以有個增加效律的作法，就是以local system 身份執行一個核心行程，然後以需求啟動使用者身份的核心行程。

整機安裝的 Omaha 核心行程，在開機時，以系統服務(system service)呼叫的方式啟動。不把 Omaha 本身作成 service 的理由是：在 Windows XP 有個 bug，如果這 service crash，會讓這個 service 無法更新。在使用者安裝模式，核心行程是用登入使用者的 shell 執行的。這避免了單點失敗，在核心行程沒有執行的情況下(不管任何理由)，我們另外使用 Windows system scheduler 來啟動核心行程。我們期望 Omaha 的 available 的時間就跟 Windows OS 的 uptime 一樣長。

Omaha 核心要非常可靠及輕量：

• 做越少事越好，而且保證做到：安裝工作者行程，完成無聲更新、權限提升，支援 breakpad crashes。
• 移除對某些 Windows 模組的依頼：不要 msxml，不要 shell，不要 network，不要 UI，不要 crypto，不要 wintrust 等等。
• 降低資源的消耗
• 較少的程式碼，且儘量使用 OS 層底層的程式，只求穩固、穩固、穩固。

Omaha 工作者行程則是做大部份的工作：

• 統一的 IPC 溝通機制是必要的。
• 工作者行程之間的溝通與同步，保持在最低限度。因為 isolation 與 share-nothing 是設計的概念。
• 工作者行程，使用新的網路堆疊及新的 CUP ( client update protocol, which uses HMACs over plain HTTP instead of HTTPS)
• To facilitate firewall traversals, a constant shell is used

 

應用程式註冊

為了讓應用程式收到更新，應用程式必須要在 Omaha 註冊。應用程式註冊機制建立在 windows registry。Omaha 有兩個主要的更新規範，這會影響 Omaha 如何得知應用程式的註冊。

1. 整機更新 (per-machine updates)
2. 使用者更新 (per-user udpates)

在整機更新的情況，每一個整機安裝的應用程式會建立一個 key HKLM/Software/Google/Update/Clients/{GUID}。在這個 key 底下，應用程式建立下列的值：

• pv (現在產品版本，例 1.0.20.0)
• name (這個值忽略，但 debug 時很好用)

在使用者更新的情況，key 所在的位置是 HKCU/Software/Google/Update/Clients/{GUID}。其他與整機更新相同。

當更新動作開始，Omaha 使用 SYSTEM 身份執行整機更新，使用登入的使用者執行使用者更新。這是假設使用者有一個 active session。也就是說，當使用者沒登入時，使用者更新是不執行的。只要，那些 key 底下有任何東西，Omaha 會不停偵測是否有更新，並執行應用程式的更新。有可能發生一個狀況，應用程式當掉且應用程式的 Omaha 註冊是啟用的，例如，使用者剛殺掉應用程式檔案。 不幸的是，Omaha 不會知道這種情況的發生，它仍會下載程式，執行更新，直到應用程式的註冊被清除。

把註冊的 key 及底層實作細節讓應用程式知道是有缺點的。這會破壞 Omaha 的封裝。有討論認為，目前這種實作細節從應用程式連結的 code library 抽離出來會比較好。然而，現在的註冊機制有個很大的好處，註冊 key 可以容易地從應用程式的安裝腳本(任何現有的 installer 的技術)產生，於是與 Omaha 整合變得容易。

自動啟動

整機安裝時的 Omaha service，是設定成自動執行的。如果 service 當機，會使用 SCM failover 機制重啟 service。當 Omaha 是使用者安裝的方式安裝，goopdate 工作者行程會由 windows shell 從HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 啟動。

排程器

client runtime 要定時執行一些工作，像是發出更新檢查要求給伺服器，確認是否有更新。這工作是分配給排程器。排程器的程式是在 Omaha 核心行程中。排程器的需求是一段時間執行一個工作者行程。

很多建議我們使用 windows 內建的排程器而不要用自己寫的。windows vista 的排程器有很大的改良。但在 XP 及 windows 2003 有一些限制：

1. 在排程器有個認證上的問題。因為排程器的使用者認證是使用 cache 的認證。如果使用者後來改密碼，排程器之後會認為認證失敗。這在 vista 有修正。
2. 在 2003 的任務排程器只能允許 administrators 使用。
3. 如果機器在 sleep state，有些硬體上的任務就不會排入。有些排入的任務會在某些情況下失敗，因為 suspected ACPI interactions。其中一個極端的情況是網路線被拔掉時，機器不會做排程。

資源與時機的條件

runtime 在考量資源消耗及更新時機，有一些條件。

在資源限制上：

• 確保不會用光使用者的硬碟空間
• 使用少量的記憶體，延遲載入不需要的模組。(This is very important for resident core)
• 如果沒有網路連線，就不要執行自動更新(避免撥接用戶自動撥號)
• 限制背景下載的頻寬
• 嘗試當使用者機器在 idle 時，更新應用程式

在更新時機上：

• 至少一天一次的更新檢查
• 循序的下載及安裝

 

Web Browser Control

Web Browser Control 提供介面給 google web page 及 client application，給予 one-click 網頁安裝及 rich update client as Pack 的特色。這需要限制存取，所以只有認證的 google 網頁及應用程式能存取 client runtime 提供的 service。The interface is defined by very coarse-granularity functions。不使用 "download file X from server Y" 這種方式，而是使用 "download application id X from Google" 這種方式。當 client 有安全漏洞時，這種 interface 的限制可降低傷害。

Crash Reporting

有兩個主要的部份是 crash reporting 在 windows 上要做的，產生 minidump 及回報給伺服器。每個應用程式仍然需要負責捕捉例外及通知 Omaha，以產生及傳送 minidump 給 google 伺服器。minidump 是放在一個安全的目錄，是 Omaha 可以寫入的地方。Omaha 有程式試著降低意外的「自我-阻斷攻擊」(self-DDoS)，防範在回報重要資料時過於頻繁的當機，或許是發現重覆的 minidump 產生或一定次數的當機的報告產生時就不回報。

Meta-Installer

The Omaha meta-installer 是一個簡單的 wrapper，包含了 client 及安裝一個或數個 google 應用程式的資訊。它擁有以下的功能：

• 安裝 client，如果本來沒有安裝
• 更新 client，如果有更新的 client。
• 啟動 client，如果本來有安裝，但沒有啟動。
• 佇列應用程式的安裝要求到 client。

我們的目標是最小化安裝程式，小於 172KB (在現今最慢的 modem  的速度 28.8kbps 的 10 wire bits per data bits，在一分鐘內可下載完畢)。目前的 meta-installer 超過這個大小。我們仍在尋找降低檔案大小的方法。

Server

The google update server 不是 omaha open source project 的一部份。應用程式的更新需要一個實作 Omaha Server Protocol 的伺服器。

Omaha 有兩個伺服器組成，autoupdate 及 download。將伺服器責任的分離，是故意的，因為兩個事情的要求不同。下載檔案需要大頻寬，且可容忍高延遲。更新時的要求則是頻率高且低延遲但頻寬要求低。這兩個的不同，使得 google 採取兩個伺服器來滿足需求。

autoupdate 伺服器提供以下功能：

• 回應來自不同的 Omaha client 的 update ping，告訴它們，是否有更新及如何更新機器上的一批 client 產品。
• 提供足夠的 configuration schema，讓不同的產品團隊不用實作自己的伺服器。Client 產品應該可提供任意的旗標，讓伺服器在 update ping 傳送時使用，同時讓伺服器根據旗標的出現或不出現做不同的行為反應。
• 讓 google 在某群穩定的使用者執行實驗測試。例如，某個團隊希望佈署新版產品到 0.01% 的使用者電腦，為期一星期，在全面佈署前可以確認有無不預期的問題。

download 伺服器主要工作是提供位元檔下載。為了提供非公開 beta 及其他有限制軟體的更新，download 伺服器可以限制某些下載的存取。

Rollout Process

為了最大的可擴展性，團隊可以重新設定 update server 的範圍而不會影響到其他團隊。

 

參考：http://omaha.googlecode.com/svn/wiki/OmahaOverview.html

[windows]程式更新機制自動化的考量(2)-流程概念

Omaha 流程說明

Omaha 主要由三個部份組成：

• 一個client run time(client-side)，
• 一個 meta-installer，
• 一個 server。

client 及 server 之間，使用 http 或 https 溝通。

當使用者希望安裝新的 google應用程式，實際上，使用者只是下載了一個 meta-installer。該檔包裝了一個client run time 安裝檔，以及使用者所選的應用程式安裝檔。

這個 meta-installer 會依情況做事：

• 如果使用者的環境裡沒有 client run time，meta-installer 會安裝一個 client run time。(一台電腦只裝一個)，
• 如果使用者環境有一個 client run time，但不是最新的，meta-installer 會更新 client run time。

之後，meta-installer 會要求 client run time，安裝使用者要的 google應用程式。如果，google應用程式不曾被安裝過，client run time 會使用 meta-installer 裡所附帶的 google應用程式安裝檔來安裝，或依 meta-installer 所指示的位置，下載安裝檔來裝裝google應用程式。client run time 會定時跟 server 要資料，檢查安裝在電腦上的 google應用程式，如果有新版本，就會更新google應用程式。

Omaha 也提供了提升權限的功能，讓系統中權限較低的使用者也能安裝google應用程式，不需系統管理員登入來安裝。

新安裝(omaha 沒安裝在系統中)

使用者從 google 網站，下載 meta-install。當使用者啟動 meta-installer 時，它就會安裝並執行 omaha client。在 windows 平台上，像 Vista 的版本，會啟用 UAC 防護，若為所有使用者安裝應用程式(applications per-machine)，執行時需要提高至系統管理員權限。接下來 omaha client 會下載應用程式並執行其安裝檔。

二次安裝(omaha 已安裝在系統中)

當 google 網站偵測到，使用者的電腦已經有安裝 omaha client，瀏覽器會利用 ActiveX 或類似物件，開始執行安裝程序，不用下載 meta-installer 的 EXE 或 MSI。

移除 omaha

當系統中，沒有應用程式需要 Omaha 時做為更新機制時，Omaha 會將自己移除。

 

以下是安裝的流程圖：

1. 使用者下載安裝程式，AppNameSetup.exe，裡面包含了 Omaha 的安裝程式及 tag 資料
2. 執行 AppNameSetup.exe 的過程，會安裝 Omaha client。Omaha client 讀取 tag 資料，與 Update Server 溝通，得到最新版本的 AppName 安裝檔位置。Omaha client 下載且執行其安裝檔，它本身不參與安裝過程。
3. Omaha client 定時(預設 5 小時) 會檢查 Update Server，每一個應用程式是否有更新版的安裝檔，若有就下載並執行它。

參考：http://omaha.googlecode.com/svn/wiki/OmahaOverview.html

[windows]程式更新機制自動化的考量

現在的使用者，應該已經非常習慣程式一打開，就跳出自動更新的視窗。也有一大部份的程式，是在背景自動更新完畢，完全不打擾使用者。在一個自動化的工廠裡，當然是需要在背景自動更新完畢的流程，因為這個環境裡，沒有使用者。

google 在更新 chrome 的時候，為了要在 windows 上完成自動更新，設計了一套更新的機制，它把這個機制變成了一個開源專案，叫做 omaha。目前，在 windows 上，除了 chrome 之外，google earth 也是採用這個機制。當初，google 許多的專案在 windows 上都有自動更新的需要，然而，每個專案都自己寫了自動更新，許多程式碼都重覆寫，以致於有人就跳出來開了這個專案，讓大家都有方便、穩定的程式碼用，不用每次都自己做輪子。他們也很順手地，把 client 端的程式分享出來，讓大家都可以使用，真的是佛心來著。我認為，從這裡學習，也是獲益良多。

Omaha 的設計，考量到幾個目標：

• 更新及安裝的系統需要在 windows 的各個不同平台可以共用。
• 自動更新機制與產品之間沒有相依性，所以不同的產品可以使用同一套的伺服端及客戶端程式邏輯。
  • 一個自動更新伺服器，能夠接受每個不同產品的自動更新需求。不同的團隊不用各自佈署自己的伺服器。
  • 一個自動更新客戶端程式，讓所有的產品共用。避免不同的應用程式自己跑自己的更新程式。
• 一個小的 meta-installer，它包含一個「客戶端更新程式」以及產品的安裝程式的參考。meta-installer 會知道如何安裝「客戶端更新程式」以及如何下載產品、安裝產品。
• 當「客戶端更新程式」安裝好，可一鍵執行網路安裝。
• 支援、控制多種版本更新，例如：不同的公開版本的釋出，beta 版釋出，開發版釋出，或是實驗版釋出。
• 支援權限受限制的安裝環境，例如：使用者不具備管理者權限的安裝。
• 提供共用的功能給所有的產品程式(客戶端程式)，例如：程式當機報告。

參考：http://omaha.googlecode.com/svn/wiki/OmahaOverview.html

[Android]Market 進不去

送修的 HTC Desire 回來了，要開始安裝 App，於是點了 Market 按鈕，居然發生 404

訊息顯示：

The requested URL /intl/%locale%/mobile/android/market-tos.html was not found on this server. That’s all we know.

嗯。你不知道，我也不知道，然後呢？

花了一、兩個小時爬 google。找到以下連結。

http://forum.xda-developers.com/showthread.php?t=767992

做法很簡單，(1)先把語系切到英文。(2)按一下 Market。讓它跑過去。(3)再切回原來的語系。

好了。要怪誰呢？

[google]Google Web Font

我在今年的 Google io 2011，看到一件很開心的事。
他們居然要做字型這一塊！

字型這件事，在 2002 年附近我用 gentoo 的時候，遇到很多問題。
當時支援 unicode, UTF-8, big5 的中文字型大多是 windows 的字型。
要使用好看一點的中文只能去找 windows 的 ttf 來用。
這要合法使用，得要你有 windows 作業系統才行。
後來，有王漢宗教授的自由字型，真是很大的福音。
不能說華康做字型就讓他們餓肚子，但是沒有好看的中文字型，
要用 linux 印報告真的是很難看。
其中，令我最不能理解的是字型牽扯到的商業行為，
使用字型的部份我比較沒有意見，
但是誰可以做字型卻有得讓我不能理解。

假設說，我看著AA少女體，做一個BB少女體，說我侵權，侵犯AA公司的權利，
我可以接受。
要是我看著AA柳公權，做一個BB柳公權，也要說我侵權，我就不能接受。
而這一塊，當年是有爭議的。
我當時不能理解的是，柳公權的字，怎麼會被一家公司做成字型檔之後，
後面的人就不能再自行做成字體？又不是檔案直接copy！
當然當時我不是做字型的人，我無法理解，
但是我後來也可以自己解釋為字型這一塊難生存的原因就是如此。

現在 Google web font 的專案，說是所有字型都是自由使用，
也提供機制讓人可以隨喜捐！
對於製作字型的人來說，就好像畫家有一個免費的藝廊可以展示，
甚至獲得金錢上的幫助。
我建議王教授可以將字型給他們 hosting，中文字型現在他們還沒有，
我們自己用的中文字型怎能缺席呢？

[google]Accessibility

Google I_O 2011- Accessibility- Building Products that Everyone Can Use

1. accessibility 指的是一種能力，讓別人方便使用的能力。
   一般舉例會用讓眼睛不好，也能使用你的產品，
   但更廣義的說，也包含沒滑鼠的情況，也能使用你的產品。
   所以更考量人機介面讓人好操作。
2. 因為一般人不會覺得有什麼差別，所以 demo 的時候就是設定一個極端的情況。讓 chrome 可以讀出聲音，把字放很大，只用鍵盤控制。
3. google介紹Chrome integration with screen readers，ChromeVox，ChromeShades
4. 有關 android 的部份，則是介紹使用一個 reader，只使用 touch pad 來操作上一頁，下一頁，字放大，選擇，讀出聲音。
5. 關於讓你的應用程式具有 accessibility 他們建議，使用標準 toolkit，讓所有的工作都可用鍵盤完成，注意tab順序及焦點，以及在 screen reader 上試一下效果如何。

[gae]appcfg.py 如何輸入密碼？

在文件上有說明，當你要用 script 執行上傳的工作，
appcfg.py 可以加上 –passin 這個參數，
讓 appcfg.py 接受來自 stdin 的密碼。
如此就可以自動更新你的 GAE application。

但，到底那個 script 要怎麼寫呢？
有人說：
echo “你的密碼" | appcfg.py update 目錄 --mail=你的帳號 --passin
我試了不行。
有人說：
appcfg.py update 目錄 --mail=你的帳號 –passin < 你的密碼檔
也一堆人試了不行。

後來有人提出來他的觀察(http://groups.google.com/group/google-appengine/browse_thread/thread/86457b3a95e30a5a)
他認為在 windows 的環境下，出現了appcfg.py stdin 的 redirection 的問題。
要解決這個問題，就是使用 python.exe 來執行 appcfg.py。
也就是：

C:\Python26\python "C:\Program Files (x86)\Google\google_appengine\appcfg.py" update 目錄 --email=你的帳號 --passin < 你的密碼檔

我試了之後成功。希望大家也成功。

keyword：google app engine

[閒聊]為什麼會這樣，Google Chrome 不正常

放在 blogspot.com 的東西，為什麼 google chrome 會不正常，跟別人不一樣？！

[google]google I/O

以前只看名字，以為這是 google 對於 I/O 的一些軟體。
我大錯特錯。
原來這是 google 舉辦的 conference 的名字。
在這個 conference 裡，介紹 google 的成果，推廣他們開發工具，推廣他們的應用產品，推廣他們對於網路的理念。
我仍然很佩服他們能把商業做得這麼不露痕跡。
尤其我經歷過搜尋網站把網站排名秤斤論兩的販賣的年代，我因為它總是給我大家所認為對的資料，而不是花錢買曝光率的網站而一直用到現在。
他們維持著給與使用者想要的資料的原則，並且努力著提供好用的平台，降低門檻讓每個人都能成為內容的提供者，而不惜花大錢投資研究或買下其他公司。
是的，當然有可能這樣的公司會做壞事。希望他們能堅持下去。
離題了。
這個 conference 的影片我正在消化中，最讓我印象深刻的是 2009 送與會者手機，2010 也送與會者手機。好想參加啊，不曉得要不要錢？