很謝謝各位的支持，
讓這趟連續30天的教學旅程能告一段落。
在參考官方文件整理內容的過程中，
讓我學習到，開發Action的前置步驟原來遠比自己實作的流程複雜許多。
希望在這幾天的文章後，你也可以學到開發Action的標準流程並加以實踐!

最後，你可以參考Google官方在Google I/O的教學!

到這裡，你已經建立一個具備完整對話體驗的Action
也已經藉由GCP建構符合使用情境的架構了
接下來，你可以嘗試精進你的Action

在正式上線後，你可能會發現當初所設計的對話流/對白不符實際使用情形。
在這個情形下你可以透過以下的方式進行修正：

修正對話流：需要額外提交新版本進行審查

這項操作需要在DialogFlow上進行,
依據你所修正的對話流來更正Intent。
更正完成後，
你需要前往Actions On Google Console提交新的版本來更新Actions上的對話流

修正對白

根據欲修正之對白的所在位置，我們需要進行不同的操作

• 在DialogFlow上進行：你需要前往Actions On Google Console提交新的版本
• 在DialogFlow Fullfiment上進行：直接更新部屬即可，現有的Action之應對內容會直接被更正

新增支援語系

現在，你有個支援中文語系的Action了!
當你的對話流設計能充分應對你的受眾後，你可以試著擴展Action的適用範圍!
來自不同地區的使用者不僅可以擴展你的Action的曝光度，也能得修正更細微的對話流問題!

範例：數字精靈

• 中文
• 廣東話(香港)
• 英文
• 日文
• 韓文
• 泰文
• 德文

參考資料

• Languages and locales | Actions console | Google Developers
• Release localized Actions | Actions console | Google Developers

最後…

在鐵人賽的最後一天，將會分享自己在向各位介紹對話流設計流程中得到的收穫，
以及我如何運用這些技巧改進現有的Action。

基於昨日文章的說明，
我們已經建立了一個資料庫協助我們暫存資料資料
但缺乏驅動負責拉取與上傳資料的Function之機制，
在本日的文章，會簡單講述你可以如何借助GCP的服務來完成這個需求

架構圖

Cloud Pub/Sub

這是一項Google的資訊傳遞服務，
我們可以透過它，向負責抓取資料並上傳資料到資料庫的Cloud Function傳遞資訊並為我們工作!

運作方式

1. Publisher 首先在 Cloud Pub/Sub 建立傳訊息用的 Topic，然後開始向該 Topic 傳送訊息
2. 當訊息被接收前或尚未收到 Acknowledge(Ack) 時，會被保存起來並等待在次傳送出去
3. Subscriber 向服務註冊訂閱(Subscription)後，所有發送到 Topic 的訊息會轉發給該 Topic 下的所有 Subscriber
4. Subscriber 收到訊息後會回傳 Ack 訊息給 Cloud Pub/Sub，以確認訊息已經收到
5. 當 Ack 被 Cloud Pub/Sub 收到後，將該訊息自 Message Storage 刪除

Cloud Scheduler

這是一項Google推出的全代管的企業級 Cron 工作排程器。
我們可以透過它替我們的Function執行進行排程，
藉由這項操作，Function將會在我們指定的時間點被喚醒並執行我們事先撰寫好的程式碼!

Cloud Pub/Sub 與 Cloud Scheduler 如何被運用在我們的專案中?

從最上方的架構圖中，我們可以略知一二。
為了達成自動定時觸發Function的效果，我們需要：

1. 在Pub/Sub建立一個主題
2. 在目標的Cloud Function訂閱甫建立的主題(Topic)
3. 藉由Cloud Scheduler定時向Pub/Sub觸發這個主題(Topic)
4. Function接收到Pub/Sub傳遞過來的訊息，開始執行事先撰寫好的程式碼

詳細教學可以參閱下方的官方文件：

• Using Pub/Sub to trigger a Cloud Function

例如

使用來自環保署提供之OPEN API獲取空氣品質資訊，
並篩選所需資料備份到Firebase RealTime Database
以索引空氣品質資訊為主要功能的Action

• 空汙查詢精靈|Google 助理

下一步…

現在，Cloud Function會依據你設定的時間進行資料拉取及上傳至資料庫的動作了
到這裡，GCP的架構設計到此告一段落!
接下來將會提供一點建議，
進而精進及擴大你的Action之使用者範圍!

參考資料

• Cloud Pub/Sub Tutorial
• Pub/Sub - Google Cloud
• Cloud Scheduler
• 初探 Google Cloud Pub/Sub
• Google Cloud Scheduler - Calling Cloud Function

從昨天所提及的架構，讓你在爬蟲獲取資料的情境下使Cloud Function能各司所職。
並使維護專案的難度下降。
今天的文章會簡單帶各位了解RealTime Database可以如何被運用到你的專案上。
而 Cloud Function 傳遞資料的流程會發生什麼變化

架構圖

基於昨天的基礎架構，現在我們的Cloud Functions依舊執行類似的任務，
但在兩者資料傳遞間多了一個資料庫來協助暫存資料。
因此兩個Cloud Functions現在推送或拉取資料的對象變成我們的資料庫。

使用Firebase RealTime Database

它是一種NoSQL型態的資料庫，使用鍵與值來儲存與索引資料。
透過它我們可以輕易地建立可以即時同步數據的小型資料庫!

在我們的專案中，他可以協助我們解決以下情境的問題：

• 爬蟲抓取的資料需要不斷被存取，但過於頻繁讀取原始網頁爬蟲機器人可能會被封鎖權限無法讀取資料。
• 你使用的Open API是更新頻繁的資料，而且你建立的Action之主要功能需要頻繁讀取資料。
  但Open API設有每日讀取資料之上限。因此需要有第二方案來存取資料。

參考資料與延伸閱讀

• Firebase 實時數據庫
• Firebase 教學 - RealTime Database 安裝與使用

下一步…

現在你已經建立起一組 Cloud Function 以及介於兩者間的資料庫了
看似很美好，但Cloud Function本身是事件驅動(event driven)的服務。
無法自行協助我們進行資料拉取以及上傳的動作，這導致你的Action去資料庫會拉不到所需的資料。
因此，在明日的文章中將會簡述如何透過GCP服務的幫助解決這個燙手山芋!

在昨日的文章中，簡單地向各位展示直接藉由Function抓取API
所能得到的架構會是何者
而今天要向各位簡單說明如何藉由Function達成前後端分離

架構圖

在這裡，我們將Function依據他們的任務切割。
如果你要拉取的資料並未提供API，你可以嘗試使用這個架構。
在這個架構下：

• 前端Function：擔任DialogFlow Fullfiment的角色，
• 後端Function：負責爬蟲拉取資料並以JSON格式傳遞資料。

此種架構可以幫助你輕易地維護你的專案，
避免冗餘的程式碼阻礙你進行除錯。

例如

基於台灣電力公司提供之電力資訊的Action

• 電力精靈|Google 助理

  參考資料

• 簡易後端實作 ( Google Cloud Functions )
• Using Fetch
• Request - Simplified HTTP client

接下來這幾天，將會帶領各位以GCP的架構的視角。
向各位闡述我們先前進行的DialogFLow Fulliment操作實際上的架構圖是什麼
而你可以在這個基礎上進行怎樣的設計來建構更好的流程。

先前實作所建構的架構

在數天前的實作教學中：

• [Day17] 藉由DialogFlow Fulfillment 實踐對話流設計

我們藉由內建在DialogFlow的Inline Editor，
在Cloud Function上建立DialogFlow Fullfiment。
從GCP的架構來看，我們可以得到下方這張圖：

從這張示意圖，我們可以理解Google助理與我們的Action是如何互動的，

當使用者透過Google助理與我們的Action互動後，
Google助理會辨識用戶輸入的語音，並將辨識後得到的文字轉傳給DialogFlow。
執行自然語言處理的DialogFlow會尋找對應的Intent，並設法給予相對應的回應。
如果指定的Intent被設定以Fullfiment來處理回應，則DialogFlow會將擷取到的參數送往Fullfiment。
並由Fullfiment的程式碼進行邏輯盼判斷來產生回應。
上述的說明也可以透過這張圖來表示：

透過Cloud Function直接拉取資料

假定你所使用的資料是Open API。
那麼，你可以透過處理DialogFLow Fullfiment的Cloud Function直接拉取資料。
從GCP的角度，現在你的專案架構會變成以下形式：

例如

介接《萌典》的 OPEN API 所建構的Action

• 臺灣國語辭典|Google 助理

  下一步…

  在明天的文章中，將會說明如何進行前後端分離。
  使兩個不同的Cloud Function分別專注於不同的任務上，
  而這麼做可以為我們帶來甚麼好處。

在今天的文章中，向不知從何開始建立一個Action的新手。
提供幾個可以嘗試發揮的方向，從而建立相對應的對話流!

參考其他語系現成的Action並仿造

若你對於要進行什麼類型的專案沒有頭緒，可以往其他語系的Action尋找可能的靈感。
像是開放第三方平台已有一段時間的英語或日文語系：

• Google Assistant
• Google アシスタント

例如下列這個Action即仿造美國區的同類型Action而來!

• 中文語系：國際太空站 | Google 助理
• 英文語系: ISS Info | Google Assistant

  從無到有打造…

  如果你想自行發想一個新的專案，可以試著往以下的方向出發!

Interactive Canvas

這是一個建立在Google助理之上的框架，它允許開發人員為對話式Actions增添視覺、身臨其境的體驗。
這類視覺體驗是一種交互式網絡應用，Google助理在對話中會將視覺體驗作為回應向用戶發送。
與Google助理預設的回應方式不同，Interactive Canvas網絡應用呈現為全螢幕的網路介面。

詳細資料可以參考：Interactive Canvas | Conversational Actions | Google Developers

Open API

• 政府開放資料平台
• 氣象資料開放平台
• 環保署環境資料開放平臺
• 公共運輸整合資訊流通服務平台

藉由爬蟲獲取資料

若你有興趣的資料沒有提供API，可以試著藉由爬蟲獲取資訊

接下來…

現在，你有個資料來源以及假想的對話流!
在明日開始的一系列文章中，將會簡述如何透過GCP幫助我們建構這類型的架構!

現在你的Action已經具備完善的對話流，能針對各式裝置進行支援。
測試者們回報的用戶體驗均十分良好，是時候讓你的Action接觸真實用戶了!

撰寫Action頁面內容與使用範例

範例Action:詞語接龍

在填寫Action頁面內容時，主要需要注意的項目有以下幾個：

1. Action 名稱
2. 內容描述
3. Action使用類別
4. 使用範例
5. 適用裝置

Action 名稱

它定義用戶如何藉由顯式調用來呼叫你的Action。
此名稱亦會被展示在Assistant目錄當中。

設定Action適用的裝置

控制用戶是否可以根據他們使用的裝置調用你的Action。

如果用戶嘗試在不支援的裝置上調用Action，
他們會收到一條錯誤消息，告訴他們他們的設備不受支援。

實際範例

在支援的裝置上開啟	於不支援的裝置上開啟

審核流程是怎麼進行的?

簡單來說，Google官方的審核小組在收到你的Action部屬申請後，
會檢視你是否違反任何《Google助理的開發者政策》，以下列出幾點主要的項目：

• Action的主要功能不得包含賭博、酒精、煙草和毒品等內容
• Action頁面的功能說明應該與實際運行的內容相符
• Action的使用範例應該能正確執行
• Action本身是否能正確執行 (例如：應當進入歡迎畫面卻顯示獲取資料錯誤)

基本上，在檢視你的Action沒有發生問題後。
你會收到一封電子郵件，通知你的Action已經被核准部署到Production Channel!
一旦部屬完成，你的Action將能夠被使用者找到且能與之互動。

部屬頻道之選擇

根據你的開發階段，你在部署時可以發布到不同的渠道：

• Alpha：應用於開發階段的早期版本，將Action部屬給少部分用戶以進行對話流迭代。
• Beta：通過完整的Google審核後，將Action分發給一組有限的用戶進行測試。
• Production：通過完整的Google審核後，發布Action給所有用戶使用

參考資料

• Pre-launch checklists | Conversational Actions | Google Developers
• Policies for Actions on Google
• Prepare to release your Action | Actions console | Google Developers
• Release your Action | Actions console | Google Developers

接下來…

現在，你已經充分了解到建立一個Action背後會經歷的開發流程!
如果你是個不曾開發過一個Action新手又該從何開始呢?
在明日的文章中將會給予一些方向供你參考!

現在，你有個能針對不同裝置進行適當對白的Action了。
但要評量一個Action是否成功，用戶的回頭率是一個很重要的因素。
因此，我們今天將會簡單介紹一些官方提供的小工具。
妥善運用它們，你就能讓使用者與Action之間的距離更進一步!

你可以使用的工具

每日更新

如果你的Action提供每日變化的有用資訊或能幫助用戶完成日常任務的小技巧，
可以在Action中啟用每日更新訂閱來協助用戶更快獲取資訊。
例如：每天向用戶發送今日的歷史事件或即時的空氣品質資訊。

加入日常安排

目前這項功能只適用於en-US語系的Action
取而代之地，你可以在Action中加入導引用戶進行加入日常安排的對話

讓您的Action成為用戶日常活動的一部分是讓他們保持參與的好方法。
提供日常安排訂閱功能，以便用戶可以將您的Action添加到他們的助理的日常安排中。
例如，創建一個出色的Action來提供創造性的早餐創意，並讓用戶將你的Action添加到他們的「早安」日常安排中。

推送通知

使用 Actions API 向用戶的手機或智慧音箱等裝置發送Google助理通知，例如提醒或事件的最新動態。
發送有用的通知能讓你的Action成為用戶數位生活的一部分!

Action鏈接

當有關你的Action的消息開始傳播時，新用戶和回訪用戶應該要能夠快速地與Action互動。
生成一個Action鏈接，能將用戶從他們的瀏覽器直接發送請求到他們的Google助理裝置上並直接與Action互動。

實際範例：使用「每日更新」功能的Action

• 每日天文圖(中文)/ 朝朝天文圖(廣東話)
  

相關實作教學

• Engage users with your Action for Google Assistant

參考資料

• Actions on Google | User engagement | Google Developers
• 設定與管理日常安排

接下來…

看起來我們的Action已經一切就緒了!
是時候提交你的Action給官方進行審查，讓世人來使用你的Action了!
在明日的文章，將會快速帶領各位了解這個審查機制是如何被進行的，
而你又該如何撰寫Action頁面的說明與使用範例來避免可能的違規情形。

從手機到智慧音箱，在不同裝置上要考量到的情形皆有差異。
這篇文章中將先介紹Google助理可回應的裝置有哪些
而你應該如何依據不同的裝置修改回應方式來增進對話體驗

按照Google助理支援的設備進行分組：

裝置	說明
	對於智慧音箱或耳機上的對話，語音回應會承載整個對話並傳達核心資訊。
	對於車內顯示器或智慧螢幕上的對話，用戶可能無法時常使用屏幕進行互動。因此，語音提示必須承載大部分對話並傳達核心資訊。屏幕可用於視覺元件補充詳細資訊並提供繼續或轉換對話的建議。
	電視、筆記本電腦、手機或手錶上的對話同樣適用於語音輸入/輸出和基於屏幕的互動模式。用戶可以選擇以口頭或視覺互動的方式繼續對話。因此，所有用於回應的元件可以協同來承載每一輪對話並傳達核心資訊。

從口語回應到多種模式並行

從針對語音回應(智慧音箱)所設計的對話流開始,逐步拓展你的設計到不同的裝置上。
使你的設計能很好地適應不同的情形並給予最佳體驗。

從示例對話框中的原始語音提示開始。為減少認知負荷，在此官方範例中在口頭上提供的選項只有隨機挑出的六個選項。

大多數情況下，您可以簡單地在智慧螢幕等設備上重複使用相同的語音提示，因為傳達對話核心的需求保持不變。 在對話的這一點上，沒有任何內容適合在卡片或輪播等視覺組件中使用，因此不包含任何內容。但最基本的要求是一定要加建議卡片。來提供用戶任何可能的選項並以便用戶可以快速點擊它們來進行響應。

由於原本必須包含在語音對白中的內容能以視覺化形式展現了。因此，在這裡重新使用了視覺組件是OK的。 文本對白理論上是語音提示的精簡版本，讓用戶可以快速掃描內容獲取資訊。若口頭或文本對白中有對用戶提出任何問題，在建議卡片的內容中應包含可能的選項供用戶使用。 因此，在這裡可以重複使用您剛剛創建的建議卡片。

參考資料

• Conversation Design | Google Developers
• Overview of conversational components

  下一步…

  讓用戶擁有良好的對話體驗是至關重要的!
  但我們必須設法吸引他們不斷回來使用，這才是終極目標。
  接下來將會簡單介紹你可以透過哪些工具讓用戶不斷回來使用你的Action。

現在，你應該有了一個能妥善處理各種意外情形。
且能妥善引導使用者滿足他們主要需求的對話流了。
在今天的文章中，我們要拓展對話流應用的視野。
這篇文章中將先粗略介紹可使用的回應元件有哪些，
善加利用它們你將能增進使用者體驗。

剖析回應的種類

根據呈現方式，可以將Action能使用的反應粗略分類為兩種

會話元件：每次回應都應包含的基本要素

會話元件由語音回應、文字回應和建議卡片中的內容組合而成。
其中，每個對話回合都應該包含會話組件（回應和建議卡片）。

視覺化元件：可依據情境選用

視覺化元件由卡片、旋轉木馬選單和其他視覺化元素所組成。
如果您要呈現詳細信息或需要陳列或比較需要進行比較的選項可以使用它們，但並非每次對話都需要被使用到。
|組成要件|詳細說明|
|–|–|
|基本卡片|以文字形式向用戶傳達的內容，需要時可以增加一按鈕供用戶前往網站查看詳細內容|
||Browsing carousel|當這些項目是來自網絡的內容時，為允許用戶選擇許多項目之一進行了優化。|
|旋轉木馬選單|允許用戶選擇許多項目中的一個，當這些項目能輕易透過圖片來區分時可以使用。|
|清單|當這些項目可以輕易透過其標題區分時，允許用戶選擇眾多項目中的一個。|
|Media response|用於播放和控制音訊檔案（如音樂或有聲書等)|
|表格卡片|以用戶能輕於快速瀏覽的格式展示靜態數據|

相關影片

參考資料

• Conversation Design | Google Developers

下一步…

我們將了解到，
這些如何屬性不同的元件，在各式型態的裝置上能夠如何被運用。

從昨天的文章中，我們能知道長尾問題在分析用戶體驗是十分重要的。
在今天，我們將會從現正運行的Action的角度。
了解長尾問題能如何完善對話流並增加使用者體驗!

案例：1A2B猜數

Google Assistant Developer Community

在2019年6月3日獲得”Keeping Users Engaged”徽章

從長尾問題來看使用者體驗設計

關於這些分析的詳細內容，可以參考Google官方撰寫的說明。
以下是結合我自己的開發經驗並以長尾問題的角度來分類對話流。

The head:1A2B遊戲基本機制

在這個Action中，主要目的是滿足使用者進行1A2B遊戲的需求。
因此在最初上線時，僅包含最基本的遊戲機制。
毫無疑問地，這就是最重要且最多人會接觸到的對話流。

The body:教學模式

在正式上線一段時間後，
我發現對於某些使用者來說，他們可能從未聽過1A2B這款經典遊戲，
更不可能知道這款遊戲的機制是甚麼。
這個情形下，直接開始遊戲會讓他們陷入混亂無法進入狀況。
因此在後續的更新上，為這些曾未接觸過這種遊戲的用戶提供「教學模式」。
讓他們有機會可以先理解遊戲的基本機制與玩法後，再進入遊戲。
在座標上這是相對次要的對話流，但是部分使用者可能必經的對話流。
使用者在充分了解規則後，能帶動他們後續再回來進行遊戲的可能性。

The long tail:非數字的輸入

由於這款遊戲是由數字為輸入為主的遊戲，
因此應對這些罕見的情形相當簡單：
提示這是不被接受的輸入並給予一些可能的選項即可。

參考資料

• Conversation Design | Google Developers

下一步…

到這裡，
你應該已經擁有一個能應對多數使用者需求，
且可以妥善針對不同意外情況進行應對的對話流範本了。
接下來，我們要進一步依據對話發生的裝置。
對Action的回應進行修改並完善它，讓整體的使用者體驗更上一層樓！

到現在為止，您的設計應該涵蓋大多數用戶將遵循的對話流。
現在是時候關注對話流的長尾問題了。
想想您的對話中可能出現的所有問題，以及用戶可能採取的所有意料之外的對話。

進行分析與設計

• 在需求階段，您定義了一組清晰的關鍵用例。 請記住這些優先事項，並避免在此列表中添加可能的特殊情況。
• 當您深入了解設計細節時，會出現您不曾考慮過的新場景。
• 在擴大對話流設計範圍以處理這些新場景之前，請仔細考慮對整體對話體驗所可能帶來的影響。
  

The head:關鍵對話

這些對話路徑是用戶透過您的Action滿足需求所採用的最重要和最常見的路徑。
您應該將大部分精力放在這裡使其成為出色的用戶體驗的關鍵!

The body:少走彎路

這些出現頻率不太高的對話流。僅需花少部分時間來建構。

The long tail:特殊情況

這些出現機率相對較低且不在Action主要功能上的對話。
可以考慮像「對不起，我不知道如何提供幫助」這樣的通用提示來滿足需求。

參考資料

• Conversation Design | Google Developers

接下來…

我們將從長尾問題的角度檢視一款運行中的Action，
看它如何滿足不同用戶的可能的需求以達到更好的使用體驗。

藉由Google Cloud Function建構DialogFlow Fulfillment

透過GCP上的Cloud Function這項SaaS (Software as a Service) 服務，
我們能輕鬆快速地建構DialogFlow Fulfillment來達成我們今日的需求。
你也能參見官方撰寫於Qwiklabs的實作範例。
Google Assistant: Build an Application with Dialogflow and Cloud Functions

開啟內建編輯器

如果各位尚未進行任何設定，可以先完成下列文章的教學再接續下方的步驟
[Day12] 於DialogFlow中實踐對話流設計

1. 首先，前往「Fulfillment」分頁。
   開啟Inline Editor的功能，我們將透過他於GCP上建立雲端函式。
   並以此撰寫程式來客製化回應。
   

2. 開啟該功能後，系統會提示需要啟用GCP的付費功能。
   請點擊「OPEN CLOUD CONSOLE」繼續操作。
   

3. 跟著系統的導引建立帳單帳戶，並將其綁訂到這個專案上
   

4. 現在，你已經成功開啟我們所需要的雲端編輯器啦!
   

透過Fulfillment修改Intent的回應

依照我們先前所提及的架構。
來客製化我們先前要設計的對話。

1. 複製貼上以下程式片段到「index.js」，取代原有的程式碼

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

'use strict';

// Import the Dialogflow module from the Actions on Google client library.
const {dialogflow} = require('actions-on-google');

// Import the firebase-functions package for deployment.
const functions = require('firebase-functions');

// Instantiate the Dialogflow client.
const app = dialogflow({debug: true});

// Handle the Dialogflow intent named 'favorite color'.
// The intent collects a parameter named 'color'.
app.intent('用戶輸入的顏色', (conv, {color}) => {
    
	// Respond with the specific response and end the conversation.
	if(color==="綠色"){conv.close('綠光戰警?');}
	else if(color==="紅色"){conv.close('感覺充滿喜氣');}
	else if(color==="藍色"){conv.close('藍色是最溫暖的顏色');}
	else {conv.close('真巧，我也喜歡'+color);}
    
});

// Set the DialogflowApp object to handle the HTTPS POST request.
exports.dialogflowFirebaseFulfillment = functions.https.onRequest(app);

2. 複製貼上以下程式片段到「package.json」，取代原有的程式碼

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  "name": "dialogflowFirebaseFulfillment",
  "description": "This is the default fulfillment for a Dialogflow agents using Cloud Functions for Firebase",
  "version": "0.0.1",
  "private": true,
  "license": "Apache Version 2.0",
  "author": "Google Inc.",
  "engines": {
    "node": "10"
  },
  "scripts": {
    "start": "firebase serve --only functions:dialogflowFirebaseFulfillment",
    "deploy": "firebase deploy --only functions:dialogflowFirebaseFulfillment"
  },
  "dependencies": {
    "actions-on-google": "^2.2.0",
    "firebase-admin": "^5.13.1",
    "firebase-functions": "^2.0.2",
    "dialogflow": "^0.6.0",
    "dialogflow-fulfillment": "^0.5.0"
  }
}

額外補充

在Fulfillment之中，我們能擷取來自Dialogflow的資料進行判斷並據此回覆。
在我們的範例中，擷取的資料是「用戶輸入的顏色」這個Intent所擷取的參數(Entities)「color」。
而上述的「index.js」所做的事是判斷參數「color」的數值來給予回應。

後續步驟

前往「用戶輸入的顏色」這個Intent的設定頁面。
至頁面最底部的「Fulfillment」，
開啟「Enable webhook call for this intent」

在Google助理上試用

請參照以下教學的詳細步驟
[Day13] 前往Actions On Google平台試用

現在，你可以前往 Actions on Google Developer Console進行測試了，
看看你的Action是否有照著Fulfillment設定的邏輯進行回應!

參考資料

在這裡所使用的Fulfillment是在DialogFlow上透過Google Cloud Function所建構的。
你也能夠在Google Cloud Platform或Firebase上進行編輯。
詳情請參考下列的網址：

• Cloud Functions | Google Developers
• Cloud Functions for Firebase

接下來…

我們將會從語音使用者介面設計的角度，
探討與對話流設計息息相關的**長尾問題 (long tail problem)**。
並了解如何應用它使Action能專注在主要的目的上並增進使用體驗。

從昨天的文章中，我們獲得了數種進行綠野仙蹤實驗的方法
在今日的文章，假定我們已經獲取用戶的反饋。並將要加以改進。

初始對話流與用戶反饋

到目前為止，我們所實踐的對話流如下圖所示：

假定我們在昨日進行用戶測試的反饋中，
得知他們對於輸入理想回應(即表達自己所喜歡的顏色)後的到的回應感覺太過單一。
因此我們挑出幾個在測試過程中出現頻率最高的顏色(如：綠色、紅色、藍色)進行回應的客製化。
而其他顏色的回應則保持原先設定。

修改後的對話流可以以下方這張圖所示：

透過Fulfillment實踐於DialogFlow之中

在Dialogflow上，我們能做的對話流設計被侷限在單純的回應。
無法進行更進一步的互動，像是：

1. 執行輸入的邏輯判斷
2. 抓取API
3. 存取Database

因此，我們將需要額外接入Fulfillment。
能使回應之設計更具多樣性，達到更貼近一般生活上的對話互動。

參考資料

• Fulfillment | Dialogflow ES | Google Cloud

接下來…

在明天的文章中，
將透過實際操作闡述我們如何藉由Fulfillment在DialogFlow實踐修正後的對話流。

在昨天的文章中，快速而簡潔地向各位介紹語音對話設計中「測試與迭代」的相關名詞
在今天的文章中我們將簡單介紹一下你可以如何實踐「綠野仙蹤實驗」來精進你的對話流

※注意事項

不管你使用什麼方式進行實驗，一定要做到以下幾點：

您可以採用 3 種不同的方法來測試您的語音應用程序：

1.快速而簡易的WOZ實驗

您所需要的只是您撰寫的對話流。
接下來，只需找到不熟悉您項目的人（例如：家人、朋友、同事）並讓他們與您進行角色扮演對話——
您將朗讀角色的台詞並觀察他們作為用戶的反應。
如果不幸地用戶「脫稿演出」，請隨意即興創作您的角色會說的話。

2.標準WOZ實驗

為了獲得最真實的體驗，請使用 Actions on Google Developer Console 上的 TTS 模擬器輸入角色的對話來模擬角色的真實對白。
並下載音訊檔案以準備好按所需播放。
在標準版本的實驗中，將需要四件事來達成：

• 一個對話流劇本，提供有關角色在每個用戶響應後應該說什麼的說明。
• 下載了所有角色的語音提示的音頻。使用可幫助您快速識別要播放的正確文件的文件名。
• 有人來扮演「用戶」。這應該是不熟悉您的 Action 的人。
• 有人扮演「巫師」。這應該是對你的 Action 非常熟悉的人。
  讓「巫師」透過播放 Action 問候語的音訊檔案並開始對話，例如：「歡迎，你喜歡什麼顏色？」
  然後「巫師」將等待用戶響應。
  一旦用戶做出響應，「巫師」將必須快速查詢對話流劇本以確定接下來該播放什麼提示並播放正確的音訊檔案。

3. 標準可用性實驗

一旦開始構建 Action，您應該經常使用 Actions on Google Developer Console 上的 Actions Simulator 對其進行測試。
如此一來你便能邀請您的朋友、家人或同事直接來測試一下！

實際進行測試與迭代對話流!

我們在幾天前的文章中，已經完成建構Action的流程。

• [Day10] 設定 Actions On Google 專案
• [Day11] 設定 DialogFlow 專案
• [Day12] 於DialogFlow中實踐對話流設計

因此，
你可以直接實行上述「標準可用性實驗」的流程，
讓您的朋友、家人或同事也來測試一下！

參考資料

• Conversation Design | Google Developers

接下來…

有了一個初始的對話流是個很好的開始，
接下來我們將試圖讓它變得更好。
在明日的文章中我們將會改造初始的對話流，並闡述如何將之實踐在DialogFlow之中!

現在，基於我們現有的初始對話流與打造完成的語音應用程式。
來試著讓它變得更好!
現在我們進入設計對話流中，「測試和迭代」階段

測試和迭代

用戶研究在設計過程中的任何時候都會有所幫助。
沒有什麼可以替代從實際用戶那裡獲得反饋，以找出哪些有效，哪些無效。你越早這樣做越好。
當你沉浸在設計中時，發現問題是很困難的——需要一個局外人的意見。

好消息是，在編寫一行代碼之前，您可以快速而輕鬆地洞察您的設計是否適合用戶。
找一個不熟悉你的項目的人來嘗試你的對話可以獲取反饋以查看您的對話是否有效 。

在設計過程中獲得反饋能找出可能的問題，並有機會儘早自我修正。
在編寫一行代碼之前，對您的對話體驗進行可用性測試很重要。
我們建議進行快速而簡陋的綠野仙踪 (WOZ) 實驗，以幫助您確定自己是否走在正確的道路上。

使用綠野仙踪實驗

為什麼這麼叫它？

綠野仙踪 (WOZ) 實驗得名於電影《綠野仙踪》；
它是一種實驗心理學實驗方法，測試人員模擬計算機應用程序來與用戶進行通訊交互，這個時候用戶會覺得自己在與真正的機器對話而表現出最真實的行為反饋。

什麼是綠野仙踪原型設計？

簡而言之，這是一種無需實際開發軟件即可測試原型的方法。
WOZ 原型設計用於評估設計的功能、
滿足用戶目標的能力以及整體改善用戶體驗 (UX)**。
WOZ 實驗旨在看起來和感覺像真實的體驗，但不是軟件，而是一個人模擬角色（“嚮導”）在實際應用程式中的行為。
參與者可能知道也可能不知道他們正在與幕後的「巫師**」互動。

[例如] 亞馬遜基於該方法做語音交互驗證實驗
利用Amazon Echo將幕後的測試人員實時輸入的話轉化為機器語音，並通過機器語音與用戶進行測試交流，此時用戶會認為自己正在與真正的機器對話。透過這個方法能得到最真實的行為反饋。

為何你應該這樣做？

WOZ 原型設計的最大優勢之一是您無需構建即可測試您的設計。
WOZ 實驗是語音測試原型的最小可行產品（MVP）。它們相對容易運行且幾乎不需要額外的努力。
原型可能非常簡單，或者它可能是一個能夠執行一些但不是所有任務的一個對話模型。
當然，你的原始模型越逼真，你的反饋就會越好。但要明智地選擇：您可以為此分配多少時間？執著於將原始模型真實化是值得嗎？

從這項實驗中我們能獲得什麼?

運行 WOZ 實驗可以讓您了解人們將如何參與您的設計。
您可能會發現用戶所做的事情與您的預期非常不同(如下方這張圖)，為此需要您更改設計以更好地滿足他們的需求和期望。

基本底線：專注於設計的可用性（而非用戶的意見）並根據用戶行為進行迭代，並在時間允許的情況下再次測試。

參考資料

• Conversation Design | Google Developers
• [CUI 101] 語音設計的原形測試方法
• 转变设计思维，智能化语境下的语音交互

接下來…

我們將介紹幾種綠野仙踪實驗的實踐方法

接續昨日的DialogFlow對話流設計後，
現在你已經擁有了一個能執行的語音應用程式!
接下來，我們將前往Actions On Google平台體驗在實際裝置上的互動效果!

1. 點擊左側選單面板「Intergrations」，
   
2. 接著點選畫面上方的 Continue with the「Intergration」
   
3. 開啟頁面後，點選裡面的「TEST」按鈕
   
4. 接著系統會把你在Dialogflow上建立的模型上傳到 Actions On Google
   
5. 載入完成後，映入眼簾的是 Actions On Google 測試頁面。
   請點選畫面左側的「我要跟我的測試應用程式說話」的按鈕啟用測試!
   
6. 接著，就能看到剛剛撰寫的對話在Google助理的裝置上出現了!
   
   ※你也可以在手機上開啟Google助理，在上頭進行測試
   

接下來…

現在，我們已經有了一個能實際運行的語音應用程式。
但還尚需更多調整才能真正問世。
接下來將進入語音介面設計中，「測試與迭代」的流程!

範例：詢問用戶喜歡的顏色

在這個範例裡，我們假設一個要蒐集使用者偏好顏色的資料集。
並透過語音助理來協助我們進行資料蒐集。
為此我們需要先假想使用者與之互動時可能的對話流，並加以進行改進。

你可以透過上傳我預先做好的angent.zip 到你的DialogFlow專案，
搭配這篇文章服用能更快理解以下內容的操作!
專案頁面

踏出第一步：修改對話內容

首先，點擊進入Default Welcome Intent，並更改系統預設的回應

刪除多餘的回應，最後只留下一個回應，並將其更改為：
「歡迎，你喜歡的顏色是什麼?」

建立顏色的數據集(Entities)

1. 首先，透過左側的「Entities」選項切換到數據集頁面。
   
2. 接著，點選右上角的「Create Entities」建立我們所需要的資料集
   
3. 將這個資料集命名為「color」，
   

建立蒐集顏色的Intent(意圖)

1. 切換回「Intents」頁面，建立一個新的Intent來客製化新的對話流程。
   點選畫面右上角的「Create Intent」。
   
2. 將Intent名稱設定為「用戶輸入的顏色」，在「Training pharse」輸入一些用戶可能會說的話來訓練模型。 例如：我喜歡綠色
   

3. 接著向下滾動頁面，我們要進一步設計這個Intent所給予的回應。

• 設計「Response」，輸入「真巧，我也喜歡$color」
• 根據我們先前的對話流設計，在取得用戶偏好的顏色後就會結束對話。
  因此「Set this intent as end of conversation」的開關要打開。
  如此一來，當用戶說出他喜歡的顏色後就會自動離開對話。
  

4. 在上述操作完成後，點擊「Save」來儲存剛剛的設定。

修改不明回應的Intent(意圖)

1. 回到展示所有Intent的頁面，現在會看到「用戶輸入的顏色」已經出現在列表中了!
   接著，請點選「Default Fallback Intent」修改模型在碰到無關輸入時要進行的回應。
   
2. 首先，把原本被填寫的回應清除。
   
3. 接著，填上我們在對話流設計的範本中所預想的回應：「**不好意思，請問你喜歡的顏色是甚麼?**」
   

   接下來…

   我們將前往Action On Google平台上實際體驗一下我們甫建立的對話流!

在昨日我們已經完成Actions On Google的專案設定
接下來，我們將接續設定Dialogflow!

Dialogflow

是一項屬於Google的開發工具，提供基於 自然語言對話(NLU) 的人機互動技術。

如何偕同Google助理運作的?

您可能想知道Google助理如何解析用戶輸入的語義（如語音）。
這是通過自然語言理解（NLU）來完成的，它使Google的軟體能夠識別語音中的單詞。

對於開發者自己的Action來說，
Dialogflow簡化了理解用戶輸入，從輸入中提取關鍵詞和短語以用來回應請求的意圖。
開發者可以在Dialogflow定義這一切的運作方式。

建立DialogFlow專案

1. 前往DialgoFlow主控台
   點擊位於左側選單上方的 [Create Agent],
   
2. 填寫Agent名稱以及要使用的Google Project
   ※ 請選擇昨日於Actions On Google設定的專案，以此為例是「actions_colabs」
3. 接著，點擊位於畫面右上方的[Create]
   
4. 待上述步驟完成後，你就已經完成專案設定了!
   

   接下來…

   在明天，
   我們將踏出第一步，實際創建我們的對話流!

延伸閱讀相關文件

• Dialogflow ES documentation
• Google Assistant: Qwik Start - Dialogflow

接續昨日的對話流設計，
現在我們要進入實作的部分讓各位能更了解設計流程。
首先從設定 Actions On Google 專案開始!

概述Action專案

它被用來專載你的Action，
無論是建構對話式Action或智慧家庭的介接都需要經過這一步驟。

建立前提：檢查你的Google權限設定

1. 前往「活動控制項」頁面
2. 登入你的Google帳號
3. 請確認以下權限都已經啟用：
   網路和應用程式活動
   ☑ 包括 Chrome 歷史記錄以及採用 Google 服務的網站、應用程式和裝置中的活動記錄
   ☑ 包括音訊記錄

若你未完成上述設定，可能會在後續的開發中碰到錯誤。
請確認你已經完成這些設定後再繼續操作喲!

登入Actions On Google 控制台

1. 點擊這個連結進入Actions On Google 控制台

2. 點擊[New Project]按鈕
   

3. 在跳出選單中輸入以下資訊：

   • Project Name
   • 選取 Action與用戶互動預設的使用語言
   • 選取 你所在的國家/地區
     待上述資訊都設定完畢後，按右下方的[Create Project]
     

4. 進入初始化選單，在這裡請選擇「Custom」
   

5. 進入進階選單，在這裡請選擇位在選單最下方的「build your Action with Dialogflow」
   

6. 恭喜你，大功告成啦!
   請待明天，繼續進行下一個DialogFlow專案的設定吧!
   

基於昨天所闡述的簡易對話流，我們今天來快速實作一個看看!
為求各位能迅速上手，我們將打造一個蒐集用戶顏色偏好的簡易語音應用程式。
經過我們這幾天所闡述的語音用戶介面設計，我們可以依據上述需求設計出一個初始的對話流。

整體來說，
我們將要實作的對話流可以用下方的圖片表示：

參考資料

• Write sample dialogs | Google Developers
• SSML | Dialogflow and legacy Actions SDK

接續前天所闡述的，我們有了假定使用者與一個賦予系統扮演的角色。
現在是時候讓它「動」起來了!
跟著下方的表格練習寫出一個初始的對話流吧!

進行方式

上述流程的第2步可以參考這部影片

開始編寫對話的最簡單方法是將您自己的專業知識作為第一個對話流的主題。
如此一來，你通常可以輕易判斷某件事聽起來是對還是錯，
即使他們無法以基本語言原則闡明為什麼聽起來會這樣；
因此，角色扮演對話是創建初始草稿和往後迭代後續草稿的最簡單方法。

參考資料

• Write sample dialogs | Google Developers
• SSML | Dialogflow and legacy Actions SDK
• Text-to-Speech：自然流暢的語音合成服務 | Google Cloud

在Google助理平台上
呼叫Google助理調用Action的方式，
依據用戶是否明白指出調用的Action而分為兩種調用方式：

顯式調用(Explicit Invocation)

使用者清楚地向Google助理表達欲使用的Action為何者

未指定特定動作

一般情況下，若使用者未向Action指定想進行的操作為何。
Google會將使用者導入開發者預定的預設歡迎畫面(Default Welcome Intent)

指定特定動作 ：語音版捷徑

用戶也可以選擇在調用同時添加一個調用短語，
這方式得以將使用者直接帶到他們所請求的意圖。
其語言架構如下所示：

用戶能指示Google助理存取您的操作的示例短語：

• 叫 $name $request_action
• 跟 $name 說 $request_action
• 問 $name $request_action
• 和 $name 說 $request_action

實際系統運作時的架構圖

隱式調用(Implicit invocation)

調用短語描述了Action的特定功能。
用戶調用Action時，可能會包含一個可以深度鏈接到特定功能之一的調用短語。
舉例來說，如果使用者想玩1A2B。
可能會直接向Google助理詢問。
而Google助理就會自Actions On Google平台尋找最類似的Action推薦使用者。
不過這項功能在中文版尚未啟用，只能在draft(草案)模式下試用。

下一步

在我們了解到與設計對話流息息相關的隱式調用與顯式調用後，
我們將繼續昨日設計對話流的旅程!

自前兩天範例中，我們看到受眾目標與假想使用者之重要性。
現在，我們能設身處地的以使用者的角度來設計對話。
為了避免對話不自然的尷尬情形發生，因此蒐集對話經驗就是個很重要的環節!

收集對話體驗不僅僅是定義Action的主要功能，而是一個必經的道路。
從這過程中，可以更了解用戶的需求和達成該需求所需的技術能力。
從明確的、經過充分研究的需求開始，是避免在設計途中發生重大更正的最佳方法。

撰寫對話

現在你對於對話的角色有個相當清晰的概念(你的Action與你的使用者)，以及他們所談論的主題。
那麼現在該是撰寫對話的時候了!

為何要撰寫簡易對話?

簡易對話流是在Google助理平台上創建出色 Actions 的關鍵：
這會讓你快速且稍微貼近真實地感受到你正在設計一個帶有「聲音」和隨之而來的互動應用。
它們傳達用戶實際體驗的流程，沒有任何程式符號、複雜的對話流程圖、或語音識別問題等技術干擾。

通過編寫簡易對話流，您可以非正式地試驗和評估不同的設計策略，例如：

• 如何提高新功能的發現可能性
• 該以何種方式確認用戶的請求來展開對話（例如：您應該使用隱式調用還是顯式調用）。

下一步…

我們將先了解上頭所提及的隱式調用、顯式調用在Google助理平台所指的各是甚麼。
再繼續前往我們設計對話流程的旅程。

參考資料

• Conversation Design | Google Developers

接續我們在昨天所闡述的設計流程，
接著來看看這些設計流程是如何在實際運作的Action上被實踐的。

參考案例：空汙查詢精靈

各位可以參考這個正在運行中的Action，
它的主要目的是協助使用者獲取所在地的AQI指數。
空汙查詢精靈 | Google 助理

如果想參考官方提供的範例，可以參閱以下的連結的說明

參考資料

• Identify your users | Google Developers

首先，在開始一個好的設計之前，
如同廣告投放一般，
我們需要找出目標受眾來設計出更符合他們的對話流程。

有以下幾點是我們需要留意的：

• 誰將是你的使用者?
• 他們的需求將會是甚麼?
• 他們現在是如何完成這些需求的?
• 他們會使用甚麼詞彙來描述這些需要被完成的需求?
• 什麼情況或事件下會觸發這些需求?

容納所有用戶

雖然針對最常使用的用戶進行優化很重要，但不要以犧牲其他用戶的體驗為代價。
精心設計的產品具有包容性和普遍性。
為不同人群設計意味著利用包容性設計或通用設計策略。
通常，您被迫為一個人群做出的調整最終會惠及所有人。

假想使用者

• 誰將是你的使用者?

假想使用者是一個特定的個別用戶且具備清晰的描述，
請試著想像：
你預期哪種類型的使用者將會使用你的Action，並寫下一些可能的用戶特質來代表他們。
這些用戶特質將會協助你避免建構出一個只完成你個人目標的Action。

用戶流程 (user journeys)

• 使用者希望達到的目標是什麼?
• 他們會使用怎樣的詞彙來代表這個目標?

用戶在給定情境中透過你的Action完成目標的途徑。

關鍵用戶流程 (Critical user journeys)

• 描述對話流程中的每個相關時刻

關鍵用戶流程是那些 經常發生 或 對用戶至關重要 的對話流程。
旨在幫助用戶從頭到尾完成其中一個流程。
專注於這些將幫助您構建能夠覆蓋大量和或專門受眾的行動。

接下來…

我們將會來看看一個實際運作中的Action，
看它是如何依照我們今日所提及的設計指引建構Action!

參考資料

• Identify your users | Google Developers

對話設計的核心是對話的流程及其底層邏輯。
因此，在將界面重新設計為對話式時，需要從下往上開始。
適用於圖形界面的邏輯幾乎永遠不會適用於對話界面。

語音介面設計簡易入手指南

設計對話流程前，需要考慮到所有可能的情形。
並給予適當的回應
避免單純把圖形化介面轉用在語音對話介面上，使人們能以習以為常的方式進行互動

1. 建立一個人物形象
   在正式開發前，選擇要代表這個語音應用的角色。
   需建立在它所要面對的主要使用群眾與他們的所需。
   用戶與之互動時，透過連續性的對話讓使用者對之建立一個一致性的形象
   也就是該品牌與使用者之間的品牌大使!

   傳遞形象的要點：

   • 聲調
   • 詞組選擇
   • 風格
   • 技能
   • 語音

2. 跳出固有的邏輯思維
   跳脫思維，將設計的對話想像成劇本或是日常對話中的片段。
   或是在紙上雜記的一個靈感，這些都有助你設計出一個優異的對話流程!

3. 謹記：在對話中沒有「錯誤」存在
   當你的Action在對話中無法了解使用者的意圖時，對使用者說「我不清楚你想說什麼」將使你的對話陷入厭惡與沮喪。
   遇到這類情形時，與其要他們從中選擇。你要做的是引導他們做出正確的回應。

   例如：

   假設你想要使用者在A或B選項之中擇一，
   你不應該在他們沒有回答出相應的對話時回應「無法瞭解意思」。
   反而應該直白的問「**我這裡有A跟B兩個選項，你想選哪一個?**」

後記

希望各位在看完這篇文章後，能對「語音介面設計」有更深一層的了解!
那麼接下來，進入設計語音應用程式「由下而上」的實作流程!

參考影片

參考資料

• What is conversation design? | Google Developers

在進入正式的開發流程前，
先來簡單快速地了解語音對話介面的一些關鍵詞。

語音對話介面 (Voice User Interface,VUI)

依據對話量多寡，可以粗略分為以下兩種對話的分類。
傳統上的對話都是單輪對話，而近日因機器學習的發展使多輪對話漸成主流。

• 單輪對話：一問一答就結束對話 Ex: 單純的一段問答對話
• 多輪對話：一問一答的同時衍生出新的問題和新的回答，從而無限接近用戶的真實訴求 Ex:LaMda

設計工具

示例對話：爲VUI挑選最常見的使用場景，爲這些場景寫一系列最優路徑的示例對話以及異常情況的示例對話。

• 視覺原型圖：視覺原型圖可將用戶體驗可視化，結合VUI，讓用戶產生更完整的視聽體驗。
• 流程圖：設計使用者在與其互動時的操作的可能流程

設計概念

• 確定策略：控制式還是對話式。

1. 對話不如預期時的反應會是什麼？
2. 系統將以什麼形式進行反饋？
3. 以什麼形式來確認用戶的意圖？

命令

• 控制模式：透過特定按鍵呼叫語音助理
• 對話模式：使用更自然的對話技巧進行話語權轉換

置信度閾值

VUI主要通過語音來反饋結果，確認訊息對於對話體驗非常重要，要做到這一點需要使用置信度閾值。
使用三級置信度時，系統將一定的閾值內以明確的形式確認訊息，若是訊息置信度小於45％，則系統會通過顯性確認訊息。若是訊息置信度大於80％，則系統將以隱性置信度來確認。

確認方式

• 顯性確認：需要強制用戶確認訊息
• 隱性確認：用戶只需要接受訊息，但無需強制確認
• 非語言式確認：僅需行動反饋，無需口頭響應。例如：「打開窗簾」
• 通用確認：通用確認並不需要用戶確認具體項目，而是開放式的聊天，從中我們可以瞭解用戶的心情和狀態等。這類反饋需要一些通用性的回答。
• 視覺確認：使用螢幕展示選項，讓用戶快速確認某件事情

異常處理

因環境噪聲或用戶聲音的輕重，導致系統出錯。
出錯的情況有：

• 未檢測到語音訊息；檢測到了語音，但未識別出結果
• 語音被正確識別了，但系統不能處理這些訊息的反饋
• 部分語音訊息識別出錯。

內容出處

淺談語音交互界面設計

大家好，我是Hank。
目前就讀於台科大資工所的研究生。
很高興有機會向大家分享我在開發Google Assistant語音應用程式的相關經驗。

那麼首先，
我先簡單介紹一下Google Assistant語音應用程式究竟是什麼?

開頭

簡介

它是一個介接於Google助理的一個基於語音設計界面的新型態應用程式。
使用者在向Google助理表明想使用某個特定的Action(動作)後，
Google會在Actions On Google平台上搜尋是否有對應名稱的Action。
接著使用者會被Google助理導引至Action的使用介面。
從此刻開始，Google助理的角色轉變為協助進行語音辨識與傳遞資訊的角色。
辨識使用者輸入的意圖與給予對應回應的工作則轉由開發者所設計的Action所執行。

Virtualized data centers

• IaaS (基礎架構作為服務) ：類似於資料中心
• Hybrid
• PaaS(platform as a service)：將程式代碼運算邏輯雲端化
• Serverless logic
• Automated elastic resources

GCP regions and zones

層級

1. Multi-Region
2. Region
3. Zone

Zone定義

• zone doesn’t always correspond to a single physical building.
• All the zones within a region have fast network connectivity among them.
• Zones are grouped into regions, independent geographic areas

Virtual Private Cloud (VPC) Network

• have region and global scale
• If you increase the size of a subnet in a custom VPC network, the IP addresses of virtual machines already on that subnet might be affected.

Compute Engine

• virtual machine type
• standard
• SSD
• OS
• Preemptible VM:可以依據需求暫停虛擬機來節省花費

Cloud Load Balancing

is a fully distributed, software-defined managed service for all your traffic.

Google VPC networks and subnets

• networks : global scope
• subnets : regional scope

You can dynamically increase the size of a subnet in a custom network by expanding the range of IP addresses allocated to it. Doing that doesn’t affect already configured VMs.

consistent

• routing tables : forward traffic from one instance to another instance within the same network
• global distributed firewall : You can control to restrict access to instances, both incoming and outgoing traffic

Cloud Load Balancing options

a fully distributed, software-defined managed service for all your traffic.

• Global HTTP : can routr different URLs to different back ends
• GLobal SSL Proxy : Suppoerted on specific port numbers
• Global TCP Proxy : Supported on specific port numbers
• Regional : Supported on any port number
• Regional internal

VPC selection

• VPC Peering : establish a peering relationship between two VPCs so that they can exchange traffic

• Shared VPC : full power of IAM to control who and what in one project can interact with a VPC in another

Interconnection options

Peering traffic (traffic flowing between peered networks)

• VPN
• Direct Peering : 一對多的共用線路的連線，共享頻寬
• Carrier Peering
• Dedirected Interconnect : 建立與Google的加密直接連線,一對一

Cloud Storage: 一種object storage

Different applications and workloads required different storage database solutions

• 上傳後會被系統賦予一個唯一的索引值，並以buckets的形式儲存
• 用系統給予的唯一鍵值(key)來索引資料，url形式索引
• 不被歸類為File Syetem ★
• 檔案被上傳後是不可編輯的，但可以透過上傳功能來更新檔案
  [x] 開啟版本管理：可以切換上傳的檔案版本
  [ ] 沒打開版本管理：舊版會無條件被新版替代
• 在伺服器端會被自動加密且無須花費
• Access Control Lists : 提供尋找檔案權限管理
• Life cycle management policy :
• 排程檔案將被刪除的時間
• 篩選並刪除某一時間點上傳的檔案
• 篩選並留下最近上傳的檔案版本

Storage type

Cloud SQL & Cloud Spanner

Cloud DataStore & Google BigTable : NoSQL database

in classficatio of relational database

comparision

APP Engine

Google Cloud Endpoints and Apigee Edge

• Cloud Endpoints

  • have a single coherent way for it to know which end user is making the call
  • the backend services need be in GCP,

• Apigee Edge

  • focus on business problems like rate limiting, quotas, and analytics.
  • the backend services need not be in GCP,

Reference

[1]GCP 儲存空間(一)： Cloud Storage/ Datastore / Bigtable / SQL 介紹與比較

藉由 Colab
大幅簡化Python初學者在設定環境以及安裝相關編譯器的時間。
藉由實作書本上的範例程式碼來學習撰寫Python。

關於書籍

書本採用Jerry老師推薦的
DATA SCIENCE FROM SCRATCH中文版：用PYTHON學資料科學

作者： Joel Grus
譯者： 藍子軒
出版社：歐萊禮
出版日期：2016-10-30
語言：繁體中文

章節

• 第3章 數據視覺化
• 第4章 線性代數
• 第5章 統計學
• 第6章 機率
• 第7章 假設與推論
• 第8章 梯度遞減
• 第9章 取得數據資料
• 第10章 處理數據資料
• 第11章 機器學習
• 第12章 k最近鄰
• 第13章 單純貝氏
• 第14章 簡單線性迴歸
• 第15章 多元迴歸
• 第16章 邏輯迴歸
• 第17章 決策樹
• 第18章 神經網路
• 第19章 深度學習
• 第20章 集群
• 第21章 自然語言處理
• 第22章 網路分析
• 第23章 推薦系統

參與讀書會

時間：2021/3/2 ~ 2021/6/22

藉由 Colab
大幅簡化Python初學者在設定環境以及安裝相關編譯器的時間。
藉由實作書本上的範例程式碼來學習撰寫Python。

關於書籍

書本採用Jerry老師推薦的
《精通 Python：運用簡單的套件進行現代運算》（第二版）
Introducing Python, 2nd Edition

作者： Bill Lubanovic
譯者： 賴屹民
出版社：歐萊禮
出版日期：2020/06/02
語言：繁體中文

章節

• 第一章 初嘗py
• 第二章 資料：型態、值、變數與名稱
• 第三章 數字
• 第四章 用if來選擇
• 第五章 文字字串
• 第六章 用while與for來執行迴圈
• 第七章 tuple與串列
• 第八章 字典與集合
• 第九章 函式
• 第十章 喔喔：物件與類別

參與讀書會

時間：11/10 ~ 1/5
如果希望參與線上讀書會，歡迎點擊Meetup的報名頁面