#科技島讀 #留下Email看全文 #Salesforce併購Slack
#1元訂閱島讀 https://bit.ly/3myOL0D
⠀
Salesforce 開創了「軟體即服務」等多種創新，卻看到了未來成長的極限。於是 Salesforce 砸重本併購 Slack 以補足產品線，爭奪成為企業的資訊骨幹。
⠀
什麼是 Salesforce？

所有成功的企業，不論再小，都會有顧客名單。名單上會記錄顧客的身份、聯絡方式、交易頻率、金額，以及是否需要定期問候、送禮等。在電腦普及以前，許多人用 Rolodex 管理顧客關係。

有了電腦後，大家改用 Excel 紀錄客戶資料。只是隨著交易增加、顧客增加，Excel 檔案的數量也隨之膨脹。常常每一個員工手中的報表版本不同，報表資料有時還相互衝突。

到了網路時代，Excel 的缺點更加明顯。除了資料分散、版本衝突之外，更大的問題是 Excel 檔案是靜態僵固的。例如假設我做了一張全家的支出表，老婆說想看一下。但我想要隱藏某一類的支出不讓她看到，例如「結婚週年紀念驚喜禮物」（你在想什麼），我無法單獨針對老婆隱藏。如果我隱藏了欄位，自己也看不到。

Excel 表格之間也無法聯動。如果我要調整一項資料，需要一筆筆修改每一個包含該資料的表格。我也無法察看修改紀錄，或是設定提醒通知（「有人剛增添一筆「奢侈品」消費」）。資料存在檔案之中，而檔案依附在裝置內。最後大家手中都一堆 Excel 檔，但彼此之間沒有關系，也無法及時更新。

Salesforce 革新了表格的概念。其創辦人 Marc Benioff 在 1999 年眼見網路服務如亞馬遜起飛，想在企業軟體中引入網路的作法。於是他離開 Oracle 創業，成立了 Salesforce，將表格移到雲上。

表格移到雲上，所有人就能瀏覽、修改同一個表格。這代表資料集中在「一個」地方。這有許多好處。首先是更方便管理表格的版本、紀錄修改歷程，以及控制使用權限。同時，每一格資料在雲上都有一個「固定」位置 — 「同一個」資料可以出現在不同的表格中。於是表格之間可以聯動，資料與資料之間也可以聯動。表格的基本單位不再是檔案，而是資料。

Salesforce 成為資料處理軟體，同時也革新了商業模式。由於 Salesforce 必須維護與管理軟體，與客戶形成更持續的關係，於是 Salesforce 捨棄傳統軟體的一次賣斷模式，改採以用量計價。Bernioff 稱之為：「以前的企業軟體是一夜情，Salesforce 希望跟顧客結婚」。這是「軟體即服務」（ SaaS）的濫觴。

今天 Salesforce 已經成為顧客關係管理（ CRM）軟體的代表。業務可以透過 Salesforce 記錄客戶的窗口（contact）、組織（account）、過往交易（opportunities）與潛在機會（lead）等資料欄位。
⠀
📧 留下 email ，馬上看 Salesforce 如何用 Slack 補足產品線： http://bit.ly/2sooQl5
💰用一元，收看所有島讀關於 Slack 的分析：https://bit.ly/3myOL0D

現在大家使用 Funliday-旅遊規劃 在「景點瀏覽」輸入城市，或者是移動地圖出現的推薦景點，應該都是即時出現，也是最近花了一些時間的成果。下面先筆記一下推薦景點開發的歷程，之後如果有機會應該可以到 PostgreSQL.TW 分享一下完整的內容。

簡單來說，就是一個從 70000ms 的 response time，提升到 200ms 的 response time 過程。

---

## 2019/02 推薦景點第一版

https://www.facebook.com/kewang.information/posts/2268138753462486

## 2019/09 late 加上使用者查詢的 poi history 到推薦景點

1. 如果該 city 最近 30 天的 poi history 景點超過 10 個，則直接使用
2. 如果該 city 最近 30 天的 poi history 景點小於等於 10 個，則加上 KNN+rating 算法所取出的 poi 一起回傳給使用者
3. 使用網路上找到的 uniq，將 poi history 的景點及 KNN+rating 算法的景點去除重覆資料
4. 會將計算後取出的 poi id 存入 Redis，TTL 為 1 天

## 2020/06 late 加快查詢速度

1. 將原本要從 poi_data (超過 2500 萬筆的 POI) 取得 city 的 bbox，改從 city_data (約 200 萬筆的 city) 取得，加快查詢速度

## 2020/07 late 刪除不正確的 poi

1. 刪除該 city 經過 poi history 計算後 count 為 0 的 poi
2. 刪除部分不該出現在推薦景點上的景點類型，如：飲水機、球場、停車場...等
3. 將 KNN+rating 的景點 TTL 設定為 14 天，而從 poi history 計算出來的景點 TTL 一樣為 1 天

## 2020/09 late 重構推薦景點功能，並加上 L2, L3 cache

### 2020/09/22 late 重構推薦景點功能

1. 先從 Redis 取出確認該 city 是否有 cache，有的話就直接回傳，沒有的話寫入 refresh = true 的 flag 到 city_data table，表示該 city 資料必須更新
2. 從 DB 取出確認該 city 是否有 cache，有的話就直接回傳，沒有的話就必須即時計算該 city 的推薦景點
3. 推薦景點的算法與之前相同，包括了 poi history 及 KNN+rating，但移除 uniq，改用 Set 的寫法去除重覆資料
4. 計算完該 city 的推薦景點之後，直接將資料存回 Redis 及 DB，並且回傳計算完的推薦景點
5. 期望這樣跑下來後，之後使用者就算在 Redis 找不到 cache (因為過期)，也可以從 DB 找到 cache (因為不會消失)
6. 每天固定跑 scheduler，掃出 refresh flag 為 true 的 city，在 background job 將最新的推薦景點寫回 Redis 及 DB，並將 refresh flag 設定為 false

### 2020/09/23 early 加快預熱 cache 到 DB 的速度

1. 因為目前在 Redis 還有部分 city 的 cache，如果要等一天 (TTL) 之後這些 cache 失效後才能啟動 L2 cache 機制會有點浪費
2. 所以增加若在 Redis 確認該 city 有 cache 且 DB 沒 cache 的話，就將該 cache 寫回 DB，並且回傳

### 2020/09/23 middle 確認是否有最佳化空間

1. 延長 city Redis cache 的 TTL 從 1 天增加到 14 天，避免部分活動過於熱門，導致該區域的推薦景點都被該活動洗掉

### 2020/09/24 early 加上 new relic

1. 加上 new relic 的 custom attributes，記錄該 city 的 IO 相關讀取時間

### 2020/09/24 middle 加上 local cache

1. 因為從 Redis 或 DB 取回來的 id 要再經過一次 DB 查詢，才能組合完整的 response 回傳
2. 所以加上 city id 及使用者語言做為 local cache key，加快同 city id 且同語言的資料回傳速度
3. 如果 city id 或使用者語言在該 cache 找不到，再回 DB 查詢
4. 加上 new relic 的 custom segment，方便判讀 request 的瓶頸是在哪一段

### 2020/09/24 late 調整 poi history 的執行速度

1. 將原本使用 where + group 取得最近 30 的 poi history 語法，改為先做 where，再做 group，將原本放在同一個 CTE 的 query 拆成兩個 CTE 執行
2. 速度從原本的 40 ~ 50 秒，甚至到 70 秒，下降到約 10 秒左右

### 2020/09/25 early 移除不必要的 middleware

1. 在整整一年前將 poi recommend 及 search 拆開成不同檔案的時候，沒有仔細確認，所以每次 request 都要到 Redis 做兩次的 auth check
2. 所以將其中一個 auth check 拿掉，加快約 1ms

### 2020/09/27 early 再次檢視 poi history 計算方式是否有最佳化空間

1. 原本在使用經緯度計算是哪個 city 時，查詢速度大約都 400ms 左右，加上 GiST index 之後，查詢速度提升 1000x，變成只要 0.4ms 就能算出來
2. 整整一年前導入 poi history 到推薦景點時，資料量還沒這麼大，所以在計算時速度都蠻快的
3. 但 poi history 現在資料筆數已經超過 2500 萬筆，都變成 Seq Scan，雖然 planner 會判斷成 Parallel Seq Scan，但速度還是很慢
4. 因為是使用近 30 天的資料做計算，所以將 created_at 加入 index，速度從 10 秒左右降到 1 秒左右

#postgresql #newrelic #redis

【日本語学習】
如何加強日語聽力及口說能力呢？

🌏無論是在日語或英語等外語學習上，“跟述練習” 「シャドーイング(shadowing)」被認為是可以增強聽力及口說能力的有效的學習方法，更被廣泛地使用在口譯訓練方式上。

🌏介紹一個輔助日語跟述練習的手機應用程式軟體「アプリ(app)」，由日本國際大學「国際大学(こくさいだいがく）International University of Japan」所研發設計的「GanbatteShadowing (がんばってシャドーイング)」，可以讓學習者隨時隨地使用手機進行跟述練習。在進行練習的同時，可錄下自己練習時的音檔，除了以語音的方式用聽的確認，還能將聲波圖形以視覺化的方式，清楚地看出自己所發音、語調、重音是否正確。

🌏這個應用程式有三大部份「セクション(セクション)」
Ⅰ．導引介紹「導入(Introduction)」
Ⅱ．練習題目「課題練習(Tasks)」
Ⅲ．個人資料夾「ポートフォリオ(My portfolio)」

1️⃣可依照各人程度選擇初級「初級（しょきゅう）」、中級「中級（ちゅうきゅう）」、高級「上級（じょうきゅう）」的三種不同內容練習題目進行，練習過的題目會變成紅色的「Start」，有錄下的音檔會顯示「Task submitted」，還沒練習過的則是藍色「Download」，還沒有音檔資料的「No data」，如圖一。
2️⃣跟述練習後所錄下的音檔會自動顯示聲波形狀以及重音的高低，就能與範例音檔的圖形差異來進行視覺上的比較，如圖二。
3️⃣可根據所要進行的跟述練習的不同方式，選擇下列三種設定：
(a) 選擇是否顯示音檔的文字テキスト，顯示「する」不顯示「しない」
(b) 選擇撥放音檔「音声再生（おんせいさいせい）」的速度。
(c) 選擇音檔播放模式「再生方式（さいせいほうしき）」有單句段落區分「句読点ごと（くとうてんごと）」，或是無段落區分的不停頓「区切りなし（くぎりなし）」模式，如圖三。

🌏「GanbatteShadowing (がんばってシャドーイング)」不僅可以隨時隨地練習，還能記錄所練習的音檔及練習歷程檔案，透過以往自己錄下的練習音檔進行比較，看出自己進步了多少。