今天發現一個只有在 Passenger 上才會遇到的問題。
原本在 config/environment.rb 裡的程式碼:
原本在 config/environment.rb 裡的程式碼:
- 1月 25 週二 201111:04
[phusion-passenger] RailsEnv failed in VirtualHost Block(Apache)
使用 Phusion Passenger + Apache 跑 Rails App 時，RAILS_ENV 的設定也一併要在 Apache 設定檔裡處理。
官方文件寫的是使用 RailsEnv，但在實際上使用後失效，還是跑在 default 的 production 上。
找了一下發現也有其他人有同樣狀況，參考這篇文章使用 SetEnv RAILS_ENV staging 後，終於可以正常運作了。
官方文件寫的是使用 RailsEnv，但在實際上使用後失效，還是跑在 default 的 production 上。
找了一下發現也有其他人有同樣狀況，參考這篇文章使用 SetEnv RAILS_ENV staging 後，終於可以正常運作了。
- 9月 16 週四 201018:55
在 Debian 上安裝 ruby-ldap
想要讓公司內的 rails 網站吃 ldap 認證，在安裝上遇到一些小麻煩。
在經過同事 stephon 的幫忙和自己整理後如下：
#sudo apt-get install libldap2-dev libsasl2-dev
都要裝 dev 版本
在經過同事 stephon 的幫忙和自己整理後如下：
#sudo apt-get install libldap2-dev libsasl2-dev
都要裝 dev 版本
- 5月 25 週二 201016:31
[Rails] Cap deploy with thinking_sphinx
專案用到的 thinking_sphinx 沒有正常執行 crontab index，於是下去 trace，
發現是在 cap deploy 時造成的錯誤。
在 contab 裡的設定如下：
而我的 cap deploy 是這樣跑的
#cap deploy -n
* 以上略
* executing `deploy:after_update_code'
* executing `thinking_sphinx:start'
* executing `thinking_sphinx:configure'
* executing "cd /myapp/current; rake RAILS_ENV=production thinking_sphinx:configure"
* executing "cd /myapp/current; rake RAILS_ENV=production thinking_sphinx:start"
* executing `deploy:symlink'
* executing "rm -f /myapp/current && ln -s /myapp/releases/20100525083656 /myapp/current"
因為在執行 thinking_sphinx:configure thinking_sphinx:start 後才做 symlink，
結果生出來的 production.sphinx.conf 就這樣被砍掉，
而 crontab 執行時就會找不到 production.sphinx.conf 檔。
因為很明顯的是 thinking_sphinx 的 bug，於是看了一下版號，是個有夠舊(1.2.12, 現在[2010/05/25]是 1.3.16)
跑去找最新的版本來測試，果然。
* executing `deploy:after_update_code'
* executing `thinking_sphinx:start'
* executing `thinking_sphinx:configure'
* executing "if [ -d /myapp/releases/20100525085056 ]; then cd /myapp/releases/20100525085056; else cd /myapp/current; fi; rake RAILS_ENV=production thinking_sphinx:configure"
* executing "if [ -d /myapp/releases/20100525085056 ]; then cd /myapp/releases/20100525085056; else cd /myapp/current; fi; rake RAILS_ENV=production thinking_sphinx:start"
* executing `deploy:symlink'
* executing "rm -f /myapp/current && ln -s /myapp/releases/20100525085056 /myapp/current"
production.sphinx.conf 就不會因為 deploy:symlink 的關係消失了。
算是一個有趣的 trace bug 經驗，還趁機熟悉了一些事。
發現是在 cap deploy 時造成的錯誤。
在 contab 裡的設定如下：
而我的 cap deploy 是這樣跑的
#cap deploy -n
* 以上略
* executing `deploy:after_update_code'
* executing `thinking_sphinx:start'
* executing `thinking_sphinx:configure'
* executing "cd /myapp/current; rake RAILS_ENV=production thinking_sphinx:configure"
* executing "cd /myapp/current; rake RAILS_ENV=production thinking_sphinx:start"
* executing `deploy:symlink'
* executing "rm -f /myapp/current && ln -s /myapp/releases/20100525083656 /myapp/current"
因為在執行 thinking_sphinx:configure thinking_sphinx:start 後才做 symlink，
結果生出來的 production.sphinx.conf 就這樣被砍掉，
而 crontab 執行時就會找不到 production.sphinx.conf 檔。
因為很明顯的是 thinking_sphinx 的 bug，於是看了一下版號，是個有夠舊(1.2.12, 現在[2010/05/25]是 1.3.16)
跑去找最新的版本來測試，果然。
* executing `deploy:after_update_code'
* executing `thinking_sphinx:start'
* executing `thinking_sphinx:configure'
* executing "if [ -d /myapp/releases/20100525085056 ]; then cd /myapp/releases/20100525085056; else cd /myapp/current; fi; rake RAILS_ENV=production thinking_sphinx:configure"
* executing "if [ -d /myapp/releases/20100525085056 ]; then cd /myapp/releases/20100525085056; else cd /myapp/current; fi; rake RAILS_ENV=production thinking_sphinx:start"
* executing `deploy:symlink'
* executing "rm -f /myapp/current && ln -s /myapp/releases/20100525085056 /myapp/current"
production.sphinx.conf 就不會因為 deploy:symlink 的關係消失了。
算是一個有趣的 trace bug 經驗，還趁機熟悉了一些事。
- 5月 16 週日 201012:44
[Rails] Custom Exception:WebException
因為需要使用一個 Exception 可以指定 status 以處理各種不同的狀況，所以試著寫寫看。
Custom Exception: WebException
:lib/web_exception.rb
Custom Exception: WebException
:lib/web_exception.rb
- 4月 24 週六 201023:13
[Rails]當用 Cucumber 測試 user story 時假造 OpenID login (使用 open_id_authentication plugin)
當網站採用 OpenID 登入時，在測試碼上遇到的問題：
因為 OpenID 認證部分是跟自己網站沒有關係的，在測試時無需“真實”使用 OpenID 來認證。
所以我們便假造之。
作法如下：
因為 OpenID 認證部分是跟自己網站沒有關係的，在測試時無需“真實”使用 OpenID 來認證。
所以我們便假造之。
作法如下：
- 12月 04 週五 200917:57
[Tips][Rails][Active::Record] save 與 save! 的差別
save 可以接收一個參數 :perform_validation => true/false，預設為 true。
當 perform_validation 被設為 false 時不會過 validation.
save! 沒有任何額外參數，一定會過 validation.
在執行 save 時，如果有任一個 before_* validation 失敗，整個 save 會回傳 false。
當 perform_validation 被設為 false 時不會過 validation.
save! 沒有任何額外參數，一定會過 validation.
在執行 save 時，如果有任一個 before_* validation 失敗，整個 save 會回傳 false。
- 10月 26 週一 200912:31
[Rails][Model] 使用 attributes= 強行指定被 attr_protected 的 column
這篇文章講的很清楚：attributes= (ActiveRecord::Base) - APIdock
這樣要繞過 attr_protected 的 column 時就不用一個一個手動指定了。
這樣要繞過 attr_protected 的 column 時就不用一個一個手動指定了。
- 10月 26 週一 200912:17
[Rails][Model]counter increment(decrement)
1. 使用 Model.increment_counter(counter_name, id):
003:0> User.increment_counter(:hit_counter, 1)
User Update (0.8ms) UPDATE `users` SET `hit_counter` = COALESCE(`hit_counter`, 0) + 1 WHERE (`id` = 1)
003:0> User.increment_counter(:hit_counter, 1)
User Update (0.8ms) UPDATE `users` SET `hit_counter` = COALESCE(`hit_counter`, 0) + 1 WHERE (`id` = 1)
- 10月 26 週一 200911:53
[Rails][Migration]指定 column type: medium text 的方法
這裡主要是講 database 使用 mysql 的狀況。
在 Rails 裡，對於 text 的指定只有一種。
而有時我們需要更大的欄位，比方說 medium text, big text。因為有時候，大一點還是比較好。
這時候在 migration 裡的作法有兩種個方式:
在 Rails 裡，對於 text 的指定只有一種。
而有時我們需要更大的欄位，比方說 medium text, big text。因為有時候，大一點還是比較好。
這時候在 migration 裡的作法有兩種個方式:
糟糕物 (2)