最近在公司發現其實不少同事都還沒有實際部署過一台伺服器的經驗，在有人負責 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 對上面兩段程式碼的定義上其實是不太一樣的。

週末看到一篇 Stripe 工程師所寫的文章，是一篇關於 Idempotency Key （幂等鍵）的設計機制。因為是一篇非常棒的文章，而且裡面的概念除了可以應用在 API 設計之外，很多程式設計上需要解決的問題都可以透過這個概念來處理。

原文非常的長而且很詳細，這篇文章只會做簡單的重點整理。

有興趣的話可以打開原文來讀，是一篇很有用的文章。

作者是很厲害的工程師，部落格上的文章都是非常精實的技術文。

老爸的公司在去年設計了一個紅利積點的消費回饋機制，裡面採用了樹狀的結構。用來改善傳統多層次傳銷造成的下線提供好處給上線，而下線卻需要去找更多下線來獲取回饋的異常機制。

不過這個設計有一個問題，就是他比傳統的樹成長的速度還會再更快些。也就表示在 Rails 裡面現有用來解決樹狀結構的一些套件並不適合使用。

以前還在讀書的時候，常常會思考所謂的「自由」是什麼，想著以後一定要過著自由的生活。不過現實就是到了社會，依舊還是有許多限制讓你無法自由自在。

不過，在 Ruby 中的類別卻是非常自由的。

有稍微接觸過 Ruby 的人應該都知道幾個特性：

• 物件導向語言
• 一切都是物件

在這幾個月，感覺到自己好像快要突破這一階段的瓶頸，所以做了一些調整試試看能不能順利的突破，同時也到了每年公司參與 RubyKaigi 的時期。

要說的話，今年的 RubyKaigi 整體的方向對我來說很不一樣，因為有不少關於 RubyKaigi 底層的議程被提出來，這在台灣舉辦研討會需要照顧到不同客群的人總會需要有一些取捨。

不過，對日本——Ruby 的發源地來說，因為有不同類型的研討會互補，反而可以在不同的研討會上，著重不同的情境來討論。

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

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

最近公司的專案使用到了 ActiveType 這套 Gem 用來輔助在專案逐漸複雜下 Model 會出現的問題。這是由 Growing Rails Application in Practice 這本書的作者在書中介紹中的技巧，不過卻意外的讓我們遇到了關於 Auto Reload 機制所產生的問題。