看板
[ Ruby ]
討論串Ruby on Rails 的速度議題
共 19 篇文章
內容預覽:
出自我的Blog. http://lightyror.blogspot.com/2006/10/ruby-on-rails.html. 剛剛看了 JavaEye 裡面的 從JavaEye2.0網站看ruby on rails性能討論串，裡面 Robbin 有提到. 單純比較JVM，PHP解析器，ru
(還有2170個字)
內容預覽:
先說，我壓根沒用過回血戒，也不知道怎麼用 C 寫 CGI. 更重要的是，我不是打著捧 Java solution 反 Ruby solution 來回這篇. 只是覺得其中幾個議題很怪異. 根據上面這段很多問號的文章. 基本上，Ruby 處理比較漫，這是公認的（至少，不是我說得 XDXD）. 我對 T
(還有1259個字)
內容預覽:
[束刪]沒問題，我還有一個更更更怪異的論點，只是還沒談而已問號很多是因為那是簡體字BBS先天的缺陷 XD沒錯 XD是的，不過考慮那些東西已經太複雜了. 所以一切的數據比例，我以 " 經驗 " 來推測. 本來就是相當見仁見智的東西你不覺得＠＠！，那我也沒辦法說有啥問題. 單純以我這個頁面來說（就我這個
(還有1860個字)
內容預覽:
原文我就全刪除了.... 直接挑著講比較白刀子進紅刀子出一點 \囧/. 基本上，我們都同意. a. 如果在小型網站、需要快速回應需求變更. 那麼開發效率的確比語言的處理速度還要重要的多. b. 如果提供較佳的環境（較充裕的 resource）. 那麼語言處理的速度，差異量就較小. c. 運算部份的主
(還有1591個字)
內容預覽:
恩，第一個我沒有辦法做出這個時間比例. 因為我根本沒有相關的資源去作推（懶得作也是實情啦）. 所以我只好信任我的經驗. 你要問我有沒有根據. 我只能跟你講沒有作過所謂的精確的實驗. 說實在話，我已經預設使用 Rails 是來開發網站. 所以，我直接預設以開發網站來當作這個論點的環境. 今天這個論點會
(還有595個字)