有一天在 Facebook 的社團看到有人提到，朋友推薦他多嘗試看看不同的語言，卻不知道該怎麼下手去嘗試。剛好我自己蠻喜歡嘗試各種程式語言，這篇文章會簡單分享該怎麼選擇程式語言。

最近看到朋友分享【35格時間管理】給裝忙的上班族：其實你擁有很多時間這篇文章，覺得跟自己從大學開始就習慣使用的時間規劃方式類似，不過還有蠻多細節可以仔細討論，因此決定來講一下目前的生活方式。

最近剛好在跟以前一起工作過的朋友聊到薪資的問題，提到產品設計師的薪資水準比軟體工程師的最高薪資，大概差了一倍左右，這讓我覺得非常疑惑。

以一間做產品為主的公司來說，產品的設計會嚴重的影響公司收入，但拿到的待遇卻沒有比工程師還高，是不是哪裡出了問題？

前幾天在 Facebook 社團 Ruby on Rails 新手村看到有人提問關於 Mock 和 Stub 的問題，其實問題本身很簡單，不過也讓我發現雖然我們都知道該寫「測試」但很多時候是不清楚怎麼撰寫的，這篇文章會先來分享一下我對 Mock 的看法，更詳細的 RSpec 測試系列請期待明年的「優雅的 RSpec 測試」連載。

當我們完成部署後是一個更大的任務開始，我們仍然還有許多的任務需要處理。舉例來說，我們還需要對網站加入各種類型的監控，並且持續的追蹤各項指標（Metrics）的變化，持續的改進。

Review Apps 是 GitLab 所提供的一個機制，可以用於針對某個 Merge Request（合併請求）來自動部署給用來進行 QA（Quality Assurance）驗證或者專案經理檢查功能的機制。因為我們已經可以進行自動化的部署，也因此可以用來產生 Review Apps 進行驗證。

Heroku 也有提供 Review Apps 的方案可以跟 GitHub 搭配，可以根據需求調整。

當我們從 Docker Compose 轉換到 Docker Swarm 之後，仍然還是面臨需要人工進行部署操作的狀況，因此我們還需要更近一步的利用 GitLab CI 來幫助我們解決部署的人工操作。

部署的環境已經準備好後，我們就可以來將之前所撰寫的 Docker Compose 設定檔轉換為 Docker Swarm 支援的格式，以及調整我們的架構來讓專案可以被部署到 Docker Swarm 上面。

要使用 Docker Swarm 還是需要進行一些設定，相比過去的 Docker Swarm 這幾年使用上容易許多，基本上只需要兩個命令就可以完成安裝。

雖然我們可以用 Watchtowner 來實現自動的部署，然而這樣的方式還有許多問題存在。首先是我們基本上無法控制版本，只能抓取 latest 的版本，除此之外也無法控制部署的時機以及退回的機制。

這個時候我們就可以導入 Docker Swarm 來作為替代方案，作為轉換到像是 AWS ECS 或者 Kubernetes 的過度方案。