上星期大家都有來聽小編在 COSCUP 分享的「模糊也是一種美 - 從 BlurHash 探討前後端上傳圖片架構」嗎？這個技術已經有實作在 Funliday-旅遊規劃 的 Web 跟 Android 囉。這個議題結束後，有朋友問了一些問題，這裡順便來統整回答一下：

1. client side upload 方式從 server 產出的 signed URL 是個什麼樣的東西？

signed URL 是為了讓沒有 access key 及 secret key 的 sender 也能在有權限管理的保護下做 S3 的檔案處理，而 Funliday 在這裡的實作是不用原檔名做 key，改用 UUID 產生避免檔名衝突。

2. client BlurHash decode 的效率如何？

在做 BlurHash decode 的時候因為用到的是 CPU 運算，而且 JavaScript 又是 single thread 的關係，所以在 decode 同時移動畫面的話，可能會造成 CPU 不夠力的 client 會有極短暫的延遲時間。這時候可以考慮把 decode 丟到 web worker 處理，避免卡到 UI thread 的順暢度。用 Android 的術語來說就是開 AsyncTask 啦！

3. 你們後來是使用哪種方式做上傳呢？

原先是使用 server side (2) 的方式，但在處理 MQ 上傳後的 notify 花了不少時間，而且上傳到 S3 也沒這麼快，所以後來改用 client side 的方式做上傳功能，運作上也比原先的方式順暢。

4. 為什麼不用 medium 的方式處理 blur？

因為 medium 檔案比 BlurHash 的字串大很多，而且要多發一次 request，成本比 BlurHash 高出不少，所以我們認為用 BlurHash 會是比較好的。

---

當然也是要感謝 gslin 大大，他在 4/26 (日) 簡單介紹了 BlurHash。小編下午看到這篇文章，馬上丟去 slack 問我們的設計師大大，看她覺得這效果如何？她過沒多久回覺得不錯，小編就在星期日的下午開始處理 server side 的實作。隔天星期一有了初步的成果，然後給我們的安卓五星上將看，星期二就完成 Android 實作並上線了！

也是因為 CDN 那塊後來把原先的 lambda 改用自己寫的 server 處理，所以實作 BlurHash 才能這麼快。lambda 這塊也是血淚史，下略 10000 字，之後有機會再跟大家分享。

---

歡迎大家對這塊有興趣的也來交流一下喔！

#blurhash #coscup

[軟體工程] 設計一個大系統應該遵循什麼步驟？有哪些要注意的地方？

「系統設計備忘錄（System Design Cheatsheet）」
https://goo.gl/FcuIqo
#SoftwareEngeineering #SystemDesign #Cheatsheet

常有「突然」當上小主管、或者被要求「帶 Team」的朋友問：「設計一個大系統，有沒有步驟可以遵循？」或者「設計大系統時，有沒有哪些一定要考量的地方？」您需要的是「軟體工程」相關的知識。可是軟體工程的書厚達上千頁，我們家的「慣老闆」（笑）要求我下週提個計畫給他耶！怎麼辦？有沒有速成的方法？今天介紹的網頁，可以稍稍解決您這部份的痛苦。

我簡單不負責任翻譯一下騙讚...不是，方便英文苦手的朋友參考好了 XD：

一、系統設計基本五步驟
1. 明訂系統目標（System Scope），並取得客戶同意。設計內容包含：
(1) 收集客戶使用案例（User Cases）/ 使用情境
(2) 明訂系統承載上限（網路流量、同時登入人數、記憶體限制...）

2. 系統概念設計（High Level Design）
(1) 一般會設計到包含哪些系統元件。
(2) 至於系統元件在此步驟就當成黑盒子，直到下一步才做細部設計。

3. 系統元件細部設計（Component Design）
(1) 特定軟體元件內部設計
(2) 供外部呼叫用的 API 設計
(3) 設計該包含哪些物件，並指定每個物件的功能。
(4) 資料庫架構設計

4. 了解瓶頸所在
(1) 根據「需求」與「架構」，預先猜測壓力最大的元件（如：CPU 速度、資料庫速度...）
(2) 如何修改架構、紓緩瓶頸，以求達到客戶需求，則交由下一步驟來做。

5. 增刪系統架構與設計（Scaling）
(1) 是否應該增加硬體速度與規格（Vertical Scaling）？或者該多買幾台，平行運作（Horizontal Scaling）？
(2) 快取（Cache）是否足夠？
(3) 是否要「平衡負載（Load Balancing）」機制？
(4) 資料庫切分、抄寫、備份考量
(5) 是否應該用「多重軟體層（Multi-layers）」來分散負重、加快效能？

二、系統設計考量關鍵
1. 並行處理（Concurrency）
2. 網路（Networking）
3. 各軟體層職責分明（Clarify each Abstraction Layer）
4. 實際效能優劣（Real-world Performance）
5. 估算（Estimation）
6. 在線率（Availability，如：保證 99.99% 的在線時間）與可靠度

三、網頁系統設計考量關鍵
1. 資訊安全考量（Security）
2. 如何受益於全球各地的快取伺服器（CDN），將客戶等待時間降至最低
3. 全文檢索機制
4. 有沒有離線支援
5. 是否需要背景執行的程式（Web Worker）
6. 後台語言的選用（Server Side Rendering，如：PHP？ASP.NET？）
7. 非同步載入（在你不用網頁資源時，偷偷預先載入待會可能用得上的東西）
8. 如何最小化網路負載
9. 開發工具選用
10. 是否針對聽障、視障人士，提供友善存取網頁內容的方法（Accessibility）
11. 是否提供多國語系（Internationalization）？
12. 是否在不同寬度的螢幕（電腦、平板、手機），提供不同的版型，以便舒適閱讀（響應式設計，Responsive design）？
13. 是否能相容於不同的瀏覽器（IE、Firefox、Chrome、Safari、Opera...）

四、網頁前台架構開發相關元素
1. 原始碼（Code）本身
2. 文件（Documentation）
3. 測試機制的設計（Testing）
4. 開發流程（Process）注意事項
(1) 版本控制（如：使用 Git 工具）
(2) 元件相依管理（如：npm, Bundler, Bower）
(3) 自動化建構工具（如：Grunt/Gulp）
(4) 系統建置與導入流程（如：Docker）
(5) 持續整合工具（如：Travis CI, Jenkins）

（喘...）哈哈！有不少名詞礙於篇幅限制，我沒在這裡解釋得很清楚。如果您有什麼問題，不用客氣留言在下面給我喔！今天的分享希望各位喜歡，也祝福大家有個美好的週末！還請大家多多按讚鼓勵，或者分享給您臉書上的好友喔！

[JavaScript] Web Worker 簡介

這篇簡介了 Web Worker 到底是什麼。Web Worker 是 JavaScript 多工（Multitasking）的基礎。有了 Web Worker，我們就能把 JavaScript 內某段程式碼，放到背景去跑。然後前景還可以跑其它程式碼，以達「多工」的效果。

如果您也對 Web Worker 有興趣，可以參考這篇文章：
https://zapier.com/engineering/intro-to-web-workers/