最近在推特上剛好朋友提到「用開源貢獻取代刷題」這樣的職涯規劃，不過這個方法其實並不輕鬆。從這個話題延伸，我發現自己能夠明確區分出「目標」跟「目的」的差異，而這個確實會影響非常多職涯上的選擇。

在八月份的開發者對話主題是「Domain-Driven Design（領域驅動開發，以下簡稱 DDD）」算是最近很常被提到的關鍵字，雖然還在學習相關的知識，不過我們還是藉由活動一貫的問答方式跟大家一步步深入討論不少相關的問題。

有一天在 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 上面。