Session在Railss中扮演非常重要的角色，例如購物車及帳號登入，這都是非常基本的東西，又因為在Rails上處理Session實在是簡單到不行，常常會有許多觀念錯誤之處。
有一種用法是在ApplicationController裡面預先寫好處理Session的程式碼，這樣在其他Controller裡頭就可以透過before_filter直接拿來用。
例如: http://pastie.textmate.org/58217
理論上不應該把整台購物車存到Session，但我暫時用#3，因為能夠1行完成的，就不弄成3, 4行。
處理Session要有幾個基本的觀念:
開發團隊用Subversion或CVS常會checkin一堆垃圾，什麼是垃圾呢？就是沒經過測試的程式，可能是下班前checkin或一段時間checkin。這些垃圾很有可能被別人checkout出去，時間一久，程式碼鐵定一團混亂。
Continuous Integration軟體做些什麼事呢？設定一定的時間間隔自動從Subversion/ CVS把程式拉出來測試(當然要先寫好test case)、自動build、自動通知相關人等。
這就是像是一台精密的儀器隨時監控程式碼的心跳(heartbeat)，一但程式碼沒心跳就掛了。
在Rails底下寫程式很容易不知不覺把時間花在測試上頭。
第一個原因是因為以Agile方式進行時，會先寫測試程式，再寫程式；只要通過測試程式這關，程式就差不多寫好了；在這種方式之下，測試程式很像是實際程式的導航系統，先把路線定好，照著走就對了。
第二個原因是Ruby/Rails的程式真的很好寫，很快就可以寫完一個功能，在沒事可做的情況下，就會想去加強測試項目，讓程式更加嚴謹。
請問您怎麼看RoR？
RoR根本是個笑話，用過DBase III，你就會用RoR。
RoR基本教義派常常告訴你，軟體該怎麼做才是對的；如果不這樣做，那一定是你有問題，不是RoR有問題。
如果你只是想在10分鐘內用RoR寫記帳2.0、部落格或網路相本之類的小程式，那麼RoR正是你的選擇；RoR根本不夠格拿來做企業級架構的東西。
請問什麼是企業級架構？
Sun已經雇用了兩名原本兼職開發JRuby的核心團隊人員，跟他們說從今以後不要去上班了，趕快把JRuby推向1.0版吧。老實說，這種工作聽起來還真不錯。
透過JRuby，可以在JVM底下執行Ruby程式，並號稱與Rails達到98%的相容度；可以讓Ruby直接運用Java強大的函式庫及應用伺服器；可以把Rails程式包一包丟到Tomcat去跑。
從Twitter Trouble的議題被拋出來後，Rails的後端擴充性再度成為焦點。
整個Twitter系統因為網路流量實在太大，所以總共擴充為180個Mongrel Server，非常驚人！！
最後造成資料庫問題愈來愈嚴重，而整個問題的根源是Rails先天只能連一個資料庫。
在Mac OS X上安裝Instiki，請使用MySQL；下載版隨附的設定是無法正常跑在Mac OS X上頭的SQLite；不然請愛用給Mac OS X用的傻瓜版。
請切換到Instiki目錄，修改config/database.yml成為連結MySQL的設定(注意要用Production):
因為Rails實在太方便了，很多東西可以不經宣告直接拿來用，他的Model幾近簡化到看不到物件屬性！！這種方便性換來的代價就是操作Model時根本不知道這個Model/ Table裡面有哪些欄位，這時候就必須自己到資料庫裡面去查。
當然了，採用Agile開發方式是一邊設計資料庫，一邊寫Code的，這其實也不是太大的困擾。萬一資料庫大起來的話，有沒有更懶惰的方式可以直接看到物件屬性欄位而不需要到資料庫去查呢？當然有。
如果Model長這樣如何呢？這是我的User Model:
Rails雖然可以把HTML, Ruby分開，其實寫法也是跟PHP, JSP類似，是把程式語法嵌在HTML語法之中，而Rails跟其他平台不一樣的地方就是整個系統的檔案架構是規定好的，程式員只要比照辦理便是。
採用Rails是可以很快完成物件或程式開發沒錯，不過一但進行前端的網頁設計，就發覺好像陷在蜘蛛網裡頭一樣，整包黏在一起。
看看這一段RHTML代碼:
很多人常常會問Ruby/Rails在執行效能、速度、反應時間等等方面的各種問題，特別是當我提到Ruby是Scripting Language的時候。
某程度來說，縱使PHP/Python/Ruby比起C/C++/Java慢上一百倍，我也不認為那是問題，我完全同意DHH對於Ruby/Rails效能問題的回應，並且最欣賞他跟Linus Torvalds一樣，都是一副I’m God的屌樣。
無論使用哪種程式語言，Web App執行效能的最大瓶頸絕對不會卡在程式語言、編譯器本身，而是會出現在Web Server或者資料庫，而這兩者的效能有賴硬體配備的提升。
有沒有想過為什麼Rails是建構在Ruby上，而不是其他的程式語言？
Ruby是由日本人松本幸弘在1995年所設計的物件導向程式語言。有人說Ruby介於SmallTalk跟Perl之間，但我不這麼認為，我認為Ruby在讓程式員快樂以及寫出漂亮程式碼這兩方面上遠遠超越其他的程式語言。
Rails企圖將Ruby的快樂以及生產力融合成頗具威力的網際網路應用架構。
這兩年PHP被Rails震暈之後，上頭也出現許多類似Rails的架構，最後只證明了一點: 這些架構還是比不上以Ruby為基礎的Rails那般快樂及具有生產力，更遑論其他專門給程式員找麻煩的程式語言了。
Rails很徹底地將Ruby的精神”讓程式員快樂(Make the programmer happy)”完完全全移植到Rails上。因為有快樂的程式員才有快樂的程式碼，最終才會產生最大的生產力。
