剛剛跟 @ihower 討論過，我們預計這幾天也要搬到 ruby.tw 去了。

@fredwu 我倒覺得他是想法超前，很多他現在講的，一年之後都實現了...

舊版是自己寫 class, override 它。

最近則是有看到一個使用新版 API 的例子，整合 bootstrap。寫 config.wrapper 去搞定 https://github.com/rafaelfranca/simple_form-bootstrap/blob/master/config/initializers/simple_form.rb

wiki backend 我們這邊正在整理了...

對...我們本來也有想要作需要 fetch rubygems.org 訊息這樣的站，結果 發現有十幾萬個 gem ...

會不會是被牆了？

http://ruby-taiwan.org 跑在 nginx + passenger 上....

只適合 1 層。第二層就是 bad smell 了

https://gist.github.com/1391980 this is the ranking lib

我之前是用 stackoverflow 的演算法去算熱門。這也在 http://t17.techbang.com.tw 上面有實際運用

我剛剛看了很多代碼，測了一下，發現其實很多地方都是 LOGIC IN VIEW，這也可能是緩慢的元兇，因為 View 都是 eval 出來的....

我會慢慢把這一些抽的比較好維護，順便看能不能加速....

開發環境，我刻意關掉 memecached。就看得到速度低落了。

而且其實我還是相當吃驚的。因為我這台是 iMac 8 核 i5 8G，全新安裝.... 蠻確定不是我環境的問題。因為公司的 project 一樣都還是很快...

Rendered home/index.html.erb within layouts/application (15.2ms) Completed 200 OK in 365ms (Views: 19.9ms | Mongo: 0.0ms)

把 application.html.erb 整塊內容砍掉還是超過 300 ms。感覺 initial 就有東西慢了，不是裡面 code 的問題.....

我不知道是不是 MongoDB 設置可能本身沒有被優化的關係 (?) 之前下載 zheye.org 這個 project 也是巨慢。

慢到最後我懶得找原因，把所有 db backend 都換成 mysql ....快速無比 T_T

我覺得這裡面一些設定是去撈 db(MongoDB) 的，本身就會比較慢。作 cache 不是正解，而是在設計時就要找出容易 slow 的地方做成類似 constant 的方式才會快

找不回來的。因為 heat cache 還是有成本，就看誰倒楣剛好碰上當那個去 heat 的人。

而 query in view 一次的代價是幾百 ms，同樣的 query 在 controller 可能只要幾 ms。詳見我的 http://wp.xdite.net/?p=3063

會換上 cells 就是因為當初我們也是用 cache 去解 heavy view 的問題。但是 heat cache 實在太沈重，於是就轉變成想要 background heat cache 的方式。

但 Rails 原始的 cache 架構很難實做 background heat cache，於是我們找阿找的，找到 cells，這一套就能讓我們實作 background heat cache。

本來我們用 cells 也是這個原因而已。後來我找到時間仔細讀 Cells 的架構，才發覺他其實就是 MiniController + View 的實作。本來我最痛的就是無法把 View 裡面的 query 拆出去，尤其是三層邏輯 View，拆無可拆，只好 cache。

我把三層邏輯 View 拆成三層 MiniController 後，速度從 500ms 變成了 15ms...。連 Cache 都不必上了。

我是這樣整理 code 的。

1. 避免 logic in view，即便要趕功能，寫完之後會記在 issue tracking，提醒自己有幹了一件骯髒的事。

比如說

<% if current_user || current_user.is_admin ? %>
  <%= link_to("EDIT", edit_post_path(@post) %>
<% end 

1. 接著我會做下一步的 refactor

<% if editable_by?(current_user) %>
  <%= render :partial => "post_toolbar" %>
<% end 

而 editable_by? 會抽去放在 posts_helper。 為什麼要抽出成 editable? 。因為可以管理者也許權限需要擴增。 到處都是硬寫死的邏輯，將來就要去把整個 project 到處挖來看

1. 在

def editable?(user)
  user && user.is_admin?
end

中間這一段又可以拆成 cancan 的 method 去做....。因為 Rule Engine 式清晰很多。

• 主要思路是別把 View 如 html tag、提示訊息，沾到 controller 或 model 層去
• Controller 只處理 去 call Model 的 method 和 routing
• Model 只負責資料的邏輯加工運算
• View 的邏輯由 helper 控制，View 的表現由 HTML 控制。程式的邏輯由 Model 處理，路徑的落及由 Controller 處理。

只要你不要在 partial 裡 query something，其實就不會慢。

真的得要 query something，我就會用 cell 再起一個 mini controller 去解這件事。

因為 partial 速度其實都算蠻快的，大家在抱怨慢是慢在 query in view 這一段。而 Draper 根本沒有「解決」這件事...反而把事情弄的更糟了。

之前曾經寫過的 MVP 與 Cells 的文章 http://wp.xdite.net/?p=3063

其實就是 MiniController 與 Partial View 的組合

老實說我反對 Decorator 的觀念（尤其是 Draper 的實作）。

在 台灣 Rubyconf 時，我有跟 Cell 的作者討論到 view 的寫作方式。 其實 Controller 和 View 本來就要切的很開，所以我們都討厭 Presenter 這樣的東西。

何況是把 Model 和 View 混的更深的 Decorator。

我們 team 的標準 practice 是

• 「描述」寫在 helper 的 method 裡。或者是 Translation 檔的裡的一個 value
• 而 Model 只負責吐 true / false，或是屬於 model 內應該做的純物質 do_some_logic

Hi, 我當時是這樣 refactor zheye 的 code 的

https://github.com/techbang/q17/blob/master/app/views/logs/_log.html.erb https://github.com/techbang/q17/blob/master/app/views/logs/_asklog.erb

當然還沒有接下去拆的太乾淨。因為光拆到這樣就很費力了 XD

光 model 裡的 Type 就花了一些時間切....