關於 #經驗 的內容

之前在查資料時，在 Twitter 上看到 DHH 對 DCI (Data Context Interaction) 的看法同時上週的我對 Domain-Driven Design 的理解（2022 年）這篇文章也提到了 DDD 跟 DCI 不互斥，而且能夠改善某些設計上的問題。

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

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

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

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

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

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

在Ruby on Rails 容器化最佳指南（一）我們已經大致說明了製作容器的目的、用途，這篇文章會跟大家介紹如何去撰寫 Production-ready（正式環境）可用的容器鏡像。

如果不想花太多時間在了解細節的技巧上，可以參考如何在幾分鐘內容器化 Rails 專案這篇文章，裡面有有針對容器化所製作的 Ruby Gem 可以快速解決這方面的問題。

在不該使用 Ruby 的 Class Variable 理由這篇文章中有大概提到 Class Variable 的意義在 Ruby 裡面跟我們在其他語言認知到的 static 關鍵字是不同的，那麼實際上到底差在哪裡呢？

在閱讀 mruby 原始碼之前我也想不通，然而在使用不同的技巧組合驗證特性之後，終於理解了 mruby 實作中對 RClass（Class 物件資料）裡面所定義的 iv_tbl（Instance Varable 對照表）的意義。

前陣子跟卡米聊到一個神奇的 Ruby Class Variable 使用問題，才想起來從使用 Rubocop 之後會自動建議避免使用，就很久沒有使用 Class Variable 這個機制。

在 Ruby on Rails 中依舊還是有一部分實作會使用，因此並不是完全不使用。然而，在大多數的時候我們應該避免使用，除了對這個特性不夠了解之外，也是因為我們通常用不到。

今年 COSCUP 的時候前同事 Cindy 分享了 Rails 容器化最佳實踐 這場演講，裡面提到我們在五倍紅寶石在將 Ruby on Rails 專案轉換為容器的一些技巧。

這系列文章會分享一下這個容器化的過程是怎麼判斷、處理以及在過程中需要注意哪些事情。