關於 #Rails 的內容

當我們有了關鍵案例（Key Examples）後，規格已經相對的明確，如果還能夠被自動化測試的話，是不是一件更好的事情呢？我們可以利用 Cucumber 來實踐 E2E Testing（端對端測試）讓我們模擬使用者實際操作來驗證規格的完善。

我們在工作的過程中大多是以需求（Requirement）當基準來進行開發的，然而要盡可能的接近規格（Specification）就需要多花一些力氣。大多數人其實下意識的都有實行這個動作，因為透過大量的溝通還是可以取得足夠的資訊，然而這樣做的效率跟成功率不一定足夠。

我們想要去「實踐」一個想法，大多數情況都是「做看看」來驗證是否可以成功，然而在這個過程中，我們需要有多少次的失敗呢？同時，為什麼有些人總是很容易的就成功，而自己卻總是沒辦法順利前進呢？

2021 年底，我開始思考什麼是「開心地寫程式」這件事情，如果單純是興趣也不跟其他人合作，那麼是很容易的。然而，如果想要將寫程式作為工作，就一定會面臨到跟其他人協力的問題，很多時候會是我們抱怨「寫這段程式的人在想什麼」的原因。

也就是說，如果能讓眾多的初階開發者（Junior Developer）寫出更好的程式，那麼對所有人來說都能夠更加專注在享受寫程式的過程。

有段時間沒有寫 Domain-Driven Design（以下簡稱 DDD）的主題，最近剛好跟一些朋友討論以及做了不少實驗，覺得可以針對這些題目再一次討論在 Ruby on Rails 中導入會遇到的問題。

大多數使用過 Ruby 的工程師都知道 Ruby 有一個特別的語言特性叫做 Mixin（混合）可以透過定義一個 Module（模組）然後被其他類別引用，如果從 DCI（Data Context Interaction）的角度來看，其實是一種脈絡的表現。

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

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

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

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

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