我們在以容器部署 Rails 的方案介紹了以容器化的方式部署 Rails 專案的方案，然而在部署之前我們還有不少前置準備需要處理。

如果你已經有部署過網站，很可能已經有大部分需要的條件，那麼可以考慮跳過這篇文章。如果是第一次準備部署，那麼可以先來看看這些需要預先準備的東西有哪些。

過去幾年，使用容器技術（Container）來部署 Ruby on Rails 專案已經變成我個人最喜歡的方式之一。除了生態系完整之外，也有著容易安裝、部署環境，並且可以很好的維持部署環境乾淨的優點存在。

基於這樣的理由，在 Rails 部署實踐這一系列，我們會由 Rails 的容器部署方案最為起點開始討論可以使用的部署方案。

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

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

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

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

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

前幾天同事根據客戶的需求在實作功能時請我幫忙檢查設計上是否有問題，因為是一段遺留代碼（Legacy Code）因此調整起來也不是那麼輕鬆。

其實同事的修改方式讓我不太滿意所以給了建議去調整，這是很多新手工程師會遇到的狀況，工作很少有機會去看到高品質的程式碼，最後就只能依照有問題的遺留代碼繼續修改跟當作學習參考。

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

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

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

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