關於 #Rails 的內容

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

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

中秋連假的時候想到老爸的客戶大多是稍微有年紀的長輩，過去都是慢慢教會怎麼使用 Email 來註冊系統的，但在台灣 LINE 的普及率其實非常的高，如果能用 LIFF 並且免去註冊流程的話似乎是個不錯的選擇。

目前 LINE 的 Mini App 還沒開放，因此不知道是否能獲得比 LIFF 更好的開發體驗。

當我們的 Rails 專案邊複雜的時候，Form Object 算是一個常見的方法。不過網路上的教學似乎大多都沒有能夠相容 Rails 的 Form Helper 的版本。

所以我就開始思考，有沒有辦法法在比較少的修改下去支援 Form Helper 呢？

在幾年前我有一篇文章討論 Autoloading 的問題，這幾天剛好有同事在 Autoloading 和 Reloading 上也有類似的問題。

所以我決定寫一篇文章來複習 Rails 5 和 6 的 Autoloading 的機制。

大概一年前左右，我開始製作一個 Ansible 的 Playbook 來幫五倍紅寶石的客戶安裝環境。

不過當我們的客戶增加之後，其實開始有點變的很難透過 Fork 的機制來管理不同客戶的 Playbook。

這表示我必須先更新主要的 Playbook 然後再同步到每一個客戶的版本上，也因此我決定去把這些通用的部分拆成單獨的 Role 專案。

包括我自己在內，寫測試有時候是一個非常不想面對的工作。也有很多剛入門的工程師覺得很難去分辨該怎麼去寫測試，在今天跟同事說明完一些技巧後就決定來寫一下這篇分享一下我自己的經驗。

前陣子在 Review 新專案中同事的程式碼時，發現同事對像是 Service Object / Form Object 這類物件不太有概念。不過這個新專案因為是接手其他公司的專案，所以有不少地方要微調。至少那個值得吐槽的「因為 Controller 程式碼太長不知道放哪裡，就都丟去 Service Object 好了！」的神奇用法，完全沒有幫助改善程式碼。

也因為這個機會，我用了一點時間跟專案的同事分享了一下我對這些物件的看法。畢竟當出我也是搞不太懂，不過隨著了解物件導向和 Ruby 的語言特性，從這些角度切入後，就比較能理解該怎麼使用。

前陣子看到 Throughbot 這間在 Ruby 圈 算是蠻有名的公司做了一個叫做 Suspenders 的 Gem 主要是對 Rails 擴充，簡單說就是基於原本的 rails new 做了一個替代品，而這個替代品會自動幫你先做好一些原本要手動做的事情。

像是安裝好常用的 Gem、套版之類的，想了一下覺得五倍其實也很需要，不少新專案也都是從我這邊經手初始化的，有一個這樣的工具會省下不少時間。

所以 Bankai （卍解） 這個 Gem 就樣做出來了，裡面基本上就是設置好在五倍大多數時候用的標配 Ex. GitLab CI 設定、RSpec 等等

但是又發現好像不太夠用，有些時候有 Docker 會方便很多，但是 Bankai 現在做不到！

之前有一段時間因為用 KVM 手動管理五倍的虛擬機花上不少時間，評估之後我們就調整成 ProxmoxVE 來管理，至少在大多數的情況有 GUI 是很方便的。

不過使用的權限還是限制在有權限管理機器的人身上，最近剛好有不少新同事加入，想讓他們練習部署伺服器。

所以就有了這樣的問題：

可以讓同事自己申請虛擬機來練習嗎？

上週五在處理網址續費的時候，發現幫老爸公司管理的網址已經多到一個程度。所以就決定把手邊可以轉移的服務都往 Gandi 丟過去。畢竟粗略估算可以達到 Grid B 的費率（實際上只有九五折）不過考量到有 API 能夠管理，以及一些自動化的手段，雖然相對還是稍微貴了一點，但是省去後續不少麻煩確實是有利的。

也因為這樣，就打算以串 Gandi 的 API 來練手一下，原本是想做完管理 Domain 的部分，不過沒想到在實作一些技術面上的東西花了不少時間，只做完簡單的價格查詢。