課表

Design Thinking: Design Bots
Class 1
1. What are bots
2. Bot types
3. Major Platforms
4. Major Use Cases
Class 2
5. Anatomy, Branding, Personality
6. AI
7. Dialog
Class 3
8. Context
Class 4
9. Rich Interaction
10. Transaction
Class 5
11. Design Process
12. Use Case Define
Class 6
13. Conversation Script/Flow
14. Testing / Deploying
Class 7
15. The future of bots

改成雙軌制
Track 1 實作
7. Dialog
8. Context
11. Design Process
12. Use Case Define
13. Conversation Script/Flow
14. Testing / Deploying
備用
9. Rich Interaction
10. Transaction

Track 2 背景知識
1. What are bots
2. Bot types
3. Major Platforms
4. Major Use Cases
15. The future of bots
5. Anatomy, Branding, Personality
6. AI

chatbot as service for enterprise

chatbot前端:建立line/FB messenger/webpage通用前端閘道,同時支援各種多媒體與複合按鈕與卡片格式。

NLP引擎:使用api.ai,但是api.ai的中文處理還在弱智階段,需要不少力氣來訓練或補充,所以可以使用關鍵字搜尋補充。

關鍵字搜尋:使用結巴斷字,斷字後往使用apache lucene引擎建立的搜尋資料庫來搜尋(當然直接把中文斷字模組放進Lunene也行,但就無法先行過濾無關的字)

以上是與業務流程無關的問答

與業務流程有關的文字對話介面,會變成
chatbot前端:與前面一樣

NLP引擎與前面一樣,但會多出intent的多重應用

Decision Engine: 使用Node-Red這系列工具做為前端,需要自己建立一個能執行node-red json格式的Process Engine。用這個Process engine來做個流程的核心,其實跟傳統的EAI/BPM是一樣的,只是這種新的流程引擎我們可以設計一套以語意為核心的API介面來作業。這樣對後台的資料查詢與存取都可以用一套規格來作業。這部分API的規格已經統一,可以使用Swagger(OAI 2.0)或是OAI 3.0的規格來規劃。

後台閘道:提供OAI與傳統後台資料的轉換,控制模組數量、處理模組授權、模組登錄等作業,也就是現在API Management(API Gateway)的工作範疇,這一塊可以使用最新的istio、中生代的kong或是更早有名的IBM APIM, RedHat 3Scale等等API Gateway模組作為管理。

後台交易模組:以服務設計的概念來看,每個模組就可以設計為單一作業、多模組平行處理是API Gateway的事情,後台交易模組開發的人就只需要專注在開發他每一個單一模組,可以用任何他喜歡的程式語言,只要進出符合規格,其他API Management平台會處理,這樣其實就是Backend as a Service的作法。

誰執政?

本週新鮮事,被朋友找去聊天,原本業主的顧問以為業主要做支付寶,結果業主要做的是淘寶,這是主軸。
旁線比較有趣,今時今日大家都說是民進黨政府,但實際上政府是誰運作呢?還是文官體系,簡稱官僚。這些官僚是誰培養的?什麼黨呢?國民黨。
故事來了,這案子的起源,是國民黨某大老跟北京市某大老想在兩岸都做一個淘寶。中國端先按下不談。
台灣這邊,他們已經拿到XX黨、N個產業公會、某梗王連鎖超市跟XX禮品中心的合約。梗王還負責給貨、物流跟吃掉所有返物流。也就是說,理論上客人跟貨源都有了。
那錢呢?做淘寶的錢?元大欽品附近的XX部給的。

聽說兩岸關係很不好,聽說執政的是民進黨。阿扁當年就死在人不夠洗官僚體系,孤鳥的蔡英文更沒人,看看林全怎麼洗。

茶葉訂閱網

設定你喜歡的口味,固定每個月寄出類似風味的茶葉,應該有不少人作了,再查查。

coffee selective

15 Best Tea Subscription Boxes


https://www.teabox.com/subscription?utm_source=affiliates&utm_medium=sas

http://www.mountaintea.com/

看來弟想走價低量大利不少這條路,可是我原本想走價高量少利不多這條,這下衝突了,等他Fuji Rock回來吧。

IVR as API

Nexmo 的方向不錯,IVR原本控制語音的部分本來就不複雜,複雜的是通訊接口。但現在通訊接口已經被統一簡化了。
GUI一定會是個活的好的流派,但IVR as a Service也會是一個活的好的流派。

Amazon Go的腦洞

展示影片如此美好,明年第一季就要上線。
沒有洞的無聊猜測,每個商品都貼上RFID,完全不需要高科技,現在一個標籤在阿里巴巴是美元一分,完全可以在每個商品上貼。
另一種沒有洞的猜測,推車,也就接近現在美國的自助結帳,把條碼掃描功能放在推車上或是在推車放個可以讓手機站立的地方,讓手機的APP當掃描器,也是可以。
但都不美麗。

所以,腦子要開個沒有RFID的洞
假設貨架跟走道有多個攝影機跟感測設備,可以正確的知道貨物是否離開貨架。
但是沒有人臉攝影追蹤,就算用BLE的偵測,人一多,這商品到底是誰拿走的?
商品A從貨架拿走,塞到商品B的位置,系統要怎麼正確判定?
更別說現在最大的麻煩是只要人一多,你連客戶是誰都很難判定,畢竟現在的人臉辨識系統,只要角度不對,就差不多掛了。
這樣要能正確的辨識人跟貨,需要有很多攝影機佈在2公尺左右的高度,還要在低角度補光,這樣應該可以勉強的抓的住人。
但要怎麼在同時三隻手往同一排貨品揚去,正確的抓住其中某隻手拿了商品來把商品掛到他的帳上這問題呢?不在貨品上放個感測,我的腦洞不夠大,想不出解。貨品上有個感測,一切好辦。
所以最後最大的洞就是,Amazon應用他多年成熟的RFID庫存管理系統,在客人走出閘門時做即時結帳就好,你在賣場愛怎麼搞,才不理你了。

Install and test go_oauth2_server

It was design to work with etcd2 which is outdated. So I rewrite it for etcd3.

There is a major trick that did not mentioned at README.md.

You have to load default data make 4 scenarios work.

base data

go-oauth2-server loaddata oauth/fixtures/roles.yml
go-oauth2-server loaddata oauth/fixtures/scopes.yml

test users (default password: test_password)

go-oauth2-server loaddata oauth/fixtures/test_users.yml

test clients

go-oauth2-server loaddata oauth/fixtures/test_clients.yml

test access tokens

go-oauth2-server loaddata oauth/fixtures/test_access_tokens.yml

With these, it works.

If you are not running at source directory, make sure you have copy the web directory to your working directory. (Of course, you don’t need *.go within web directory).