在工作的時候經常會需要套用一些佈景主題，主要大多是因為客戶還在 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 機制所產生的問題。

這週的 CSS Weekly 以及幾個前端相關的電子報都提到了叫做 Maintainable CSS 的專案，乍看之下還以為是討論可維護 CSS 專案的文章，沒想到是一種 CSS 框架。

幾年前 Responsive Web Design 和 Single Web Application 開始熱門起來的時候，大家也注意到網站使用的 CSS 逐漸複雜。所以開始有像是 OOCSS、SMACSS、BEM 等等理論出現，綜合來看這些技巧對於維護網站的樣式上都是很有幫助的。

會寫這篇文章是因為 Maintainable CSS 在很多地方上跟我自己使用的方式類似，而我目前採用的則是 SMACSS 跟 BEM 的混合版本，所以就打算來分享一下自己的經驗和技巧。

PHPConf 是退伍後參加的第三個研討會。雖然現在已經沒有什麼在寫 PHP 了，不過寫了好幾年的語言還是會想關注一下最近的狀況。

今年其實沒有聽到很多議程，只聽了三場議程而已。 大部分的時間都用在跟講師聊天，不過另一方面也感受到這幾年很多活動都已經不是以前認識的人去參加。這大概就是對我們這群人來說，一個研討會的內容能帶給我們的東西已經不夠了。

雖然以前會覺得自己還能夠一直參加，不過實際上當研討會分享的東西大多能靠自己學會跟吸收的時候，就沒有那麼重要。有機會的話，去做分享也是繼續參與的一個階段，能力可及的話我也會盡可能多做分享。