每到新年之初，往往會覺得熱血沸騰，想著一定要把過去一年想學但是卻還沒付諸實現的技能或興趣加入到計劃清單內，但我通常在安排的 10 件事裡面有 1 件能夠真的去做，並且維持一段時間就已經可以偷笑了。
為什麼會這麼困難？又要怎麼制定一個能夠「執行」的學習目標，以下便整理我閱讀「脫不花」的「怎樣制訂更有價值的學習目標」文章心得。
在撰寫 Dockerfile 時，經常需要設定容器執行後的指令，例如，一個 Node.js 的 App 可能透過 npm run start 來啟動，又或是執行某個 shell script。
這些指令都是需要在環境準備好之後，在容器「運行」時執行，而非在 Docker build 的建置階段時執行。此時，我們便能在 Dockerfile 中使用 CMD 或 ENTRYPOINT 來指定容器運行時要執行的指令或程序。
上一講透過 Google Analytics 加上 AWS Lambda，我們完成了透過 Page Path 來取得 View Count 的 API，接下來便是將瀏覽量顯示在 Hexo Icarus 主題中的預覽及內文了。
由於 Icarus 本身提供的設定檔支援的是不蒜子，和我使用 Google Analytics 作為瀏覽量資料庫的方式不同，只能另尋他法。
在瀏覽一些其他的實作方法後，發現有些方式能夠透過修改 Icarus 的模板來加上自訂內容，然而在當下專案我所使用的 hexo 5.4 和 icarus 4.3 並沒有發現類似的模板可供修改，直接進入 node_modules 修改 Icarus 產出的頁面顯然會在重新安裝時被覆蓋，不是個太好的辦法。
因為我想加入的自訂內容僅僅是「瀏覽數」而已，所以在不變更 Hexo、Icarus 的版本前提下，我選擇了一個可能也不太「乾淨」的方法來達成目的，Hack Hexo Icarus 的頁面的 HTML 來插入內容。
既然都選用 Hexo 作為部落格的框架了，除了因為全部皆為靜態網頁能達到的 High Performance 外，最大的優點想必就是價格了。
當然這是針對維護一個中小型部落格的「價格量級」來做比較的，實際上架設一座小型的 Word Press 部落格，可能最多也就每月幾百元新台幣的價格，和接下來要提到趨近免費的 Solution 來說，在成本上的差異主要就只是每個月能少噴幾百元，個人感受比較好罷了。
接下來便來聊聊這個 Solution：透過 Google Analytics 來儲存瀏覽量、AWS Lambda 提供 API 獲取瀏覽量。
我目前的部落格所使用的 Hexo，是一個產生靜態網頁的框架，優點在於你可以將產生出來的網頁放在任何一台網頁伺服器來供人瀏覽。
但相較於如 WordPress 這類動態網站的服務，如果我們想要顯示每篇文章被瀏覽的數量，Hexo 就比較難達到這個目的。
聊到建立監控機制來維護上線的服務，我們可以收集系統的指標如 CPU、RAM 的使用率來確認某一時間內的系統狀態，也可以定期儲存 API Request 的 Response Time、QPS 來觀察系統的效能有沒有被影響。
那麼，這些 Metrics 都是怎麼被我們所收集的呢？又有哪些 Monitoring 的工具及服務可以使用？我們今天就來聊聊這個話題。
你是否有想過，一個長度只有 32 位元的 IPv4 位置，計算下來約莫只能提供 42 億個位置，早已經少於世界人口總數，無法讓人人皆有了。
但是每個連上網際網路的裝置，都需要一個 IP 位置怎麼辦？這一系列的文章將由簡入深，聊聊這個問題是怎麼被 NAT 所解決的、帶來了什麼額外的問題、什麼是穿透、什麼是 STUN 等等，讓我們接著聊下去。
當我們在做軟體的架構設計時，資料庫的 Non-Functional Requirements 絕對是必要考慮的一環。例如 Performance（如回應時間）、Data Integrity（如資料一致性）、Availability（每年的 Uptime 比例） 等等。
如果要將資料庫設計成 HA（High Availability，高可用）的話，可能至少要讓每年的 Uptime 大於 4 個 9，也就是 99.99% 的時間都能正常使用（大約每年小於 50 分鐘的 Downtime）。
而單機的資料庫一旦發生什麼故障，由於需要人工介入修復，停機的時間超過 50 分鐘基本上是不可避免的。因此增加冗餘、增加機器的數量基本上是要達成高可用的唯一途徑。
這篇文章來看看如果要達成高可用的儲存架構，如何用雙機，也就是多一台機器的冗餘要增加資料庫的可用性。
本篇為 Linux 指令的筆記。
