關於 #Rails 的內容

在我們學習 Rails 的過程中，從安裝環境、設計系統到撰寫程式在市面上都已經有非常詳細的教學，然而到了部署階段受限於篇幅大多只有 Heroku 這個選項，很少有人針對 Rails 的部署深入討論。

這會是一系列的文章，你可以選擇訂閱弦而時習之來收到最新的文章更新，同時在未來如果有額外的內容，也會透過訂閱列表發送給有訂閱的讀者。

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

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

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

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

Ruby on Rails 至今為止一直都是快速開發網站的首選框架之一，雖然我們可以利用 Rails 快速的製作網站，然而在部署上依舊還是要 DevOps 透過手動的方式部署伺服器、更新才能夠進行測試或者發布。

那麼，我們是否有更好的方式來解決這樣的問題呢？

今年 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 專案。

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