從第一篇到第二篇的說明，加上第三篇我想大家已經對編譯自己的環境稍為熟悉。

為了要可以用 Passenger 作為網站伺服器，我們需要自行編譯 Nginx 讓他可以使用 Passenger 模組。

上週同事突然在公司的聊天群組中討論起區塊鏈到底是不是屬於分散式系統（Distributed System）因為去年年底爆紅的關係，我也稍微了解了一下區塊鏈的運作，就被同事說會不會晚上就有文章出來了。

雖然不是當天晚上就在寫，不過了解區塊鏈的運作倒是很有幫助我們冷靜下來對應這個新名詞。

經過第一篇和第二篇的說明，我想大家現在應該都有辦法順利的透過 SSH 進入自己的伺服器。

在第二篇的最後，我們針對 Ruby 環境預先做了準備，接下來就是安裝 Ruby 環境的時候了！

最近因為在五倍紅寶石配合同事做官網的 SEO 優化，比較常見的行銷工具像是 Google Analytics 之類的就一起拿出來玩。

實驗的對象首選當然是自己的網站，不過在調整的時候卻發現有一些情況有點異常。

上一篇文章已經討論過關於 Ruby 中的類別是怎樣運作的，這篇文章則會來討論如何拓展 Ruby 類別。

大部分的人寫 Ruby 有很大的原因是因為 Rails 但是上面像是 has_many 跟 before_action 這些可以直接在類別上做的事情，很明顯不是 Ruby 內建的，到底是怎麼運作的呢？

延續上一篇文章的內容，我們需要先在伺服器上進行設定，讓伺服器可以正確的安裝 Ruby 環境。如此一來，我們才能夠將 Ruby on Rails 部署到伺服器上面。

為了完成這些前置作業，我們還需要針對伺服器的設定進行完善的準備才行。

最近在公司發現其實不少同事都還沒有實際部署過一台伺服器的經驗，在有人負責 DevOps 的情況下，也許真的不太需要。又或者因為還是初級工程師的關係，沒有那個權限可以去安裝一次伺服器。甚至其實一直都使用著 Heroku 或者 AWS CodeDeploy 等服務的便利性，而沒有嘗試自己安裝一次。

不管是基於甚麼原因，總之先來安裝一次吧！

手邊有一個專案剛好是需要滿足「多網站」並且每個網站都能夠「多語言切換」這兩個條件，在這兩個解決方案中最好處理的就是 Apartment 和 Globalize 這兩個 Ruby Gem 了。

不過，在某些情況卻變成了問題。幸好運氣不錯的是還在開發階段，還有辦法將這個問題透過替換 Gem 進行修正。

在工作的時候經常會需要套用一些佈景主題，主要大多是因為客戶還在 MVP (最小可行產品) 的階段，只需要可以表現其商業價值運作的系統即可。不過，如果我們依照 Ruby on Rails 預設的方式把外部的佈景相關檔案分類後放到 vendor/assets 目錄下，反而會變得難以管理。

前幾天的晚上朋友在 Facebook 上問了一個問題。

1raise HTTPError, 'Not Found'

和

1raise HTTPError.new('Not Found')

哪個比較快？也因為這樣，我們意外的發現 Ruby 對上面兩段程式碼的定義上其實是不太一樣的。