快來點我 👉👉👉 https://hahow.in/cr/kewang-backend 👈👈👈

大家好，小編這次籌備的新課「專為前端工程師準備的 Node.js 後端實戰課程」開始在 Hahow 好學校 上架募資啦！

在 2021/7/14 之前，在這篇文章按讚，並且公開分享這篇文章，及 tag 一位你的好朋友，除了可以用超優惠價格購買這門課程外，還有機會獲得 8 折的 coupon 喔！

---

這門課主要是從小編在這六七年來對於後端開發的集大成，以 Node.js+VS Code 做為開發環境。

會開這門課程的原因，主要是因為後端運用廣泛，但是門檻高、人才難找。而前端工程師經過了 MVVM 框架及 JavaScript 的洗禮後，再加上 Node.js 的流行，轉職到後端會比其他語言多了一層優勢。所以這門課程希望能讓已經有 JavaScript 基礎的前端工程師，也能輕鬆進入後端開發的大門。

課程內容主要是從 Express.js 開始著手，以 TODO list 做為貫穿整門課程的專案，其中可以學到許多內容，像是：

🔥 如何活用 package.json 及 dotenv 讓你快速開發
🔥 express.js 最重要的 middleware 開發及如何擴充 req/res
🔥 如何使用 Heroku 讓你快速部署網站上雲
🔥 如何使用 New Relic 來觀測網站運作狀況

其中也會教大家如何撰寫 API 文件及 RESTful API 的串接實戰，像是：

🔥 request 失敗到底要用 200 還是 400 回應
🔥 使用 mock server 快速串接 API
🔥 使用 Markdown 快速撰寫 API 文件

而資料庫則會搭配 MongoDB 及 Redis 做為快速開發使用：

🔥 MongoDB 的 schema 設計、CRUD 及最重要的 aggregate 使用方式
🔥 Redis 的 set/get 及 expire 功能簡易使用

---

這門課也有兩個募資解鎖單元，分別是「如何使用 Redis 開發 autocomplete 功能」、「如何使用 BullMQ 縮短 API 的回應時間」，歡迎大家踴躍報名這門課程，對課程有任何疑問都可以在課程網頁留言喔！

#nodejs #expressjs #javascript

現在大家使用 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

#嵌入式系統 #微處理器MPU #微控制器MCU #專用晶片ASIC #數位訊號處理器DSP #現場可編程邏輯閘陣列FPGA #工業物聯網IIoT

【嵌入式系統＝智能互聯】

什麼是嵌入式系統？市調機構看好汽車行業將成為嵌入式運算市場的主要動能——混合動力電動汽車 (HEV) 和純電動車 (EV) 興起，帶領智能系統控制不斷擴張，全自動駕駛尤需運行多個複雜的人工智慧 (AI) 軟體和系統。隨著物聯網 (IoT) 和工業物聯網 (IIoT) 出現，嵌入式技術已成智能生態迅速拓展的推動者。

嵌入式設備通常由系統單晶片 (SoC) 與現場可編程邏輯閘陣列 (FPGA) 等「與硬體集成的軟體」提供動力，以便開發人員針對特定功能進行編程積體電路 (IC) 和其他韌體版本，意謂軟體和硬體已然密不可分。簡單、大批量消費市場的嵌入式系統多由 99% 硬體＋ 1% 軟體所組成，但飛機、汽車或高度可靠的工控應用，則以高度專業化、小批量為主；若測試及應用程式繁複，軟體所佔嵌入式系統成本的比例甚或可高達 95%！

嵌入式系統雖是非常成熟的技術，但新一代功能強大的處理器不斷發展，使嵌入式系統幾與「智能互聯」畫上等號，而「智能邊緣設備」(Edge AI) 將促使整個嵌入式系統顯著增長。在分眾市場分面，數十年來，消費電子一直是嵌入式系統的主要市場，但物聯網的出現將賦予它們全新意義——新型感測器和軟體等嵌入式智能已成為主要元素。醫療保健則是嵌入式系統開發最快的應用之一，例如，手持式／可攜式治療設備及用於監測生命體徵的設備。

此外，智能建築和智慧城市的來臨，將使嵌入式系統擴展預測性和規範性，基於 AI 和機器學習 (ML) 實現完全自主和自我修復，前三大 Edge AI 產品分別為：智慧手機、智慧音箱與 AR/VR/MR 等抬頭顯示設備 (HUD)。其中，成長最快速的產品是消費型與企業用機器人及安全監控攝影機。技術挑戰在於：發展低能耗、高準確率的認知計算，包括新型運算架構電路設計、演算法等。預期未來 IoT 裝置所使用的控制晶片，皆將內含 AI 加速晶片。

AI 創新能量蓬勃，演算法每幾個月就有大躍進，如何讓電子器件的開發環境與其無縫接軌，成為影響採用意願的要素之一。於是，各家處理器供應商無不絞盡腦汁在整合開發環境 (IDE)、打包軟體套件、創造韌體差異、各式開發板，乃至與雲端服務供應商 (CSP) 的合作上，目標是為各有專長的工程師形塑「工具鏈」、鋪設一條康莊大道，讓底層基本核心、韌體、中介軟體 (Middleware) 和最上層的應用軟體毫無隔閡。我們日前所介紹的「Microchip MPLAB」系列就是一例。

另為擴大應用，近年 FPGA 在本質上也有了變化：一是整合應特定用途的處理器做異構運算，二是軟核 (軟體為基礎的 IP 內核) 崛起，三是完善開發環境，四是與雲端平台結盟……。

延伸閱讀：
《智能邊緣引領「嵌入式系統」騰飛》
http://compotechasia.com/a/feature/2019/1111/43273.html
(點擊內文標題即可閱讀全文)

#工研院產科國際所 #台灣AI晶片聯盟AITA #微芯科技Microchip #MPLAB #CryptoAuthentication #PolarFire #美高森美Microsemi #賽靈思Xilinx #Zynq UltraScale+RFSoC #芯科科技SiliconLabs #ThunderboardSense 2