經過了四年，這個框架一路發展到現在。能夠自在的使用 Rails 的 Developer 在台灣卻也都還不算多。其中有很多原因，除了本地語言的文件不夠多之外，文件和 API 更迭過速導致開發環境破碎，也對後進者造成很大程度的學習障礙。

這一行可以說大家都是邊做專案，邊熬夜翻網路文件，跌跌撞撞把網站「拼」出來的。

維護擴充性的重要性

有些人，幸運的只是接案維生的 Developer，在練功「拼」完專案之後，就不需要再維護這些急就章的程式碼。

但在這個世界上，絕大多數的人，還是屬於服務於企業中，需要持久維護一個專案的 Developer。

這兩種人，我都當過。

因為浸淫在 Rails 的開發世界夠長，本身培育過 Developer，也開發過不少專案。在經歷維護專案，並持續升級 Rails 版本後，我漸漸能體悟到寫出好維護的程式碼是多麼重要的一件事。

如果程式碼亂七八糟：

• 你根本無法進行網站下一次的改版擴充動作，即便是功能上的小改版
• 你根本無法進行 Rails 版本升級的動作，因為你會被過去造成的錯誤（不管是自己或者是夥伴）不斷懲罰，導致寸步難行。

接著業務拓展和工作進度就會開始被這些程式碼開始扯到後腿…

寫程式變成了一件不快樂的事。

沒有書教你怎麼寫出好的（ Rails ）程式碼

但話說回來，寫出這些亂七八糟的程式碼，也不是開發者本身故意的。

畢竟 Rails 是一個進化很快的 Framework，要能跟上這個 Framework API 與架構的最新進度，已經很吃力了。很難奢求一般的 Developer 去追求所謂的 Rails Best Practices。

而大多數的狀況是，坊間的書籍與網站往往只教你：

• 如何快速把開發環境建置起來，開發一個示範站台，利用 plugins 建構出簡單的 feature。 — 看完了這本書只學會 CRUD。

• 另外一個極端，將所有 API 全數羅列出來， — 翻的時候只想睡，翻完之後不知如何應用在自己 project 之內

其他時候，只能全憑自己經驗或碰運氣看網路上找來的文件。功能可以勉強在時程內湊出來就萬幸，更別提寫出「好」的程式碼了。

This book is for you

網路上不乏許多關於 Rails 的 Best Practices，Antipattern 的演講。比如 ihower 的 [Rails Best Practices] 就是一篇對於寫出高品質 Rails code 很棒的指南。

但在實戰和平日社群交流中，我發覺大家需要的卻不是 Best Practices。Best Practices 離大家的生活太遙遠。大家所需要的是 「Practices」：

• 如何寫出容易維護的程式碼
• 如何避免寫出的糟糕程式碼
• 如何遵循 Rails 架構，寫出標準好維護的程式碼
• 如何透過 Rails 內建機制整理，經過專案積累而日益肥大的 Code Base
• 如何搭配 RubyGems 讓自己的程式碼更乾淨、整潔，更易讀。

在開發功能，專案更迭中，自然持續的維持著專案的整潔。保持著可以繼續高速前進的心情與步調，愉快的工作。

這才是寫 Ruby / Rails 的初衷不是嗎？

本書架構

在接觸過無數的專案之後，我發現許多讓人無法繼續維護的 Rails code。除去開發者偷懶的因素，剩下的原因幾乎都是肇因對於 Ruby / Rails 基礎 API 以及架構不了解，所寫出的問題代碼。

所以這本書的順序將會是這樣的：

1. 介紹 Ruby 通用的的基本 Coding Style，包含程式碼的寫作慣例
2. 介紹 Rails 容易被誤用，但在開發中相當重要的基本工具。
3. Application 的 AntiPattern，什麼是絕對錯誤的架構設計
4. 利用 Rails 原生架構實現的程式碼整理術
5. 利用 3rd Party Gem 實現的程式整理術

Collection & Member

Member

宣告這個動作是屬於單個資源的 URI。可以透過 /photos/1/preview 進行 GET。有 preview_photo_path(photo) 或 preview_photo_url(photo) 這樣的 Url Helper 可以用。

1
2
3
4
5

resources :photos do
  member do
    get 'preview'
  end
end

也可以使用這種寫法：

1
2
3

resources :photos do
  get 'preview', :on => :member
end

Collection

宣告這個動作是屬於一組資源的 URI。可以透過 /photos/search 進行 GET。有 search_photos_path 或 search_photos_url 這樣的 Url Helper 可以用。

1
2
3
4
5

resources :photos do
  collection do
    get 'search'
  end
end

也可以使用這種寫法：

1
2
3

resources :photos do
  get 'search', :on => :collection
end

Nested Resources

有時候我們會需要使用雙重 resources 來表示一組資源。比如說 Post 與 Comment ：

1
2
3

resources :posts do
  resources :comments
end

可以透過 /posts/123/comments 進行 GET。有 post_comments_path(post) 或 post_comments_url(post) 這樣的 Url Helper 可以用。

而這樣的 URL 也很清楚的表明，這組資源就是用來存取 編號 123 的 post 下所有的 comments。

而要拿取 Post 的 id 可以透過這樣的方式取得：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class CommentsController < ApplicationController

  before_filter :find_post

  def index
    @comments = @post.comments
  end

  protected

  def find_post
    @post = Post.find(params[:post_id])
  end
end

Namespace Resources

但是像 /admin/posts/1/edit 這種 URL，用 Nested Resources 應該造不出來吧？沒錯，這樣的 URL 應該要使用 Namespace 去建構：

1
2
3
4
5

 namespace :admin do
   # Directs /admin/products/* to Admin::PostsController
   # (app/controllers/admin/posts_controller.rb)
   resources :posts
 end

可以透過 /admin/posts/123/edit 進行 GET。有 edit_admin_post_path(post) 或 edit_admin_post_url(post) 這樣的 Url Helper 可以用。

延伸閱讀

• Rails Guide: Rails Routing from the Outside In

What is REST?

REST 提出了一些設計概念和準則：

1. 網路上的所有事物都被將被抽象成資源 (resource)
2. 每個資源對應一個唯一的 resource identifier
3. 通過通用的介面 (generic connector interface) 對資源進行操作
4. 對資源的各種操作不會改變 resource idetifier
5. 所有的操作都是無態 (stateless) 的

對照到 web services 上來說：

• resource indentifier 是 URI
• generic connector interface 是 HTTP

RESTful Web Services

RESTful Web Services 是使用 HTTP 並遵循 REST 設計原則的 Web Services。它從以下三個方面資源進行定義：

• URI，比如：http://example.com/resources/。
• Web Services accept 與 return 的 media type，如：JSON，XML ，YAML 等。
• Web Services 在該 resources 所支援的一系列 request methid : 如：POST，GET，PUT 或 DELETE。

以下列出在實現 RESTful Web 服務時HTTP請求方法的典型用途。

制約即解放

DHH 在 Discovering a world of Resources on Rails 提到一個核心概念：Constraints are liberating 。

很多剛踏入 Rails 這個生態圈的開發者，對於 REST 總有股強烈的反抗心態，認為 REST 是一個討厭的限制。但事實上，DHH 卻認為引入 REST 的制約卻反為 Rais 開發帶來了更大的解放，而這也是他引入這個設計的初衷。

維護性：解決了程式碼上的風格不一

在傳統的開發方式中，對於有效組織網頁應用中的程式碼，大家並沒有什麼共識。所以很可能在專案中會出現這種風格不一致的程式碼：

1
2
3
4
5
6
7
8
9
10
11

def add_friend
end

def remove_friend
end

def create_post
end

def delete_post
end

透過 REST 的包裝（對於 resource 的操作），可以變得更簡潔直觀，且具有統一的寫法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class FriendShipController
   def create
   end

   def destroy
   end
end

class PostController
  def create
  end

  def destroy
  end
end

介面統一：Action as Resource

大眾最常對 REST 產生的一個誤解，就是以為 resource 只有指的是 data。其實 resource 指的是：data + representation (表現形式，如 html, xml, json 等)。

在網頁開發中，網站所需要的表現格式，不只有 HTML 而已，有時候也需要提供 json 或者 xml。Rails 透過 responder 實現了

在 Resource Oriented Architecture (ROA，一組 REST 架構實現 guideline) 中有一條： A resource can use file extension in the URI, instead of Content-Type negotiation。

Rails 透過 responder 的設計，讓一個 action 可以以 file extension ( .json, .xml, .csv …etc.) 的形式，提供不同類型的 representation。

1
2
3
4
5
6
7
8
9
10
11

class PostsController < ApplicationController
  # GET /posts
  # GET /posts.xml
  def index
    @posts = Post.all

    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render :xml => @posts }
    end
  end

開發速度：透過 CRUD 七個 action + HTTP 四個 verb + 表單 Helper 與 URL Helper 達到高速開發

REST 之所以能簡化開發，是因為其所引入的架構約束。Rails 中的 REST implementation 將 controller 的 method 限制在七個：

• index
• show
• new
• edit
• create
• update
• destroy

實際上就是整個 CRUD。而在實務上，web services 的需要的操作行為，其實也不脫這七種。Rails 透過 HTTP 作為 generic connector interface，使用 HTTP 的四種 verb ： GET、POST、PUT、DELETE 對資源進行操作。

GET

1
2
3
4

<%= link_to("List", posts_path) %>
<%= link_to("Show", post_path(post)) %>
<%= link_to("New", new_post_path) %>
<%= link_to("Edit", edit_post_path(post)) %>

POST

1

  <%= form_for @post , :url => posts_path , :html => {:method => :post} do |f| %>

PUT

1

  <%= form_for @post , :url => post_path(@post) , :html => {:method => :put} do |f| %>

Destroy

1

  <%= link_to("Destroy", post_path(@post), :method => :delete )

Form 綁定 Model Attribute 的設計

Rails 的表單欄位，是對應 Model Attribute 的：

1
2
3
4
5
6
7
8
9
10
11

<h1>New post</h1>

<%= form_for @post , :url => posts_path do |f| %>
    <%= f.error_messages %>
    <div><label>subject</label><%= f.text_field :subject %></div>
    <div><label>content</label><%= f.text_area :content %> </div>
    <%= f.submit "Submit", :disable_with => 'Submiting...' %>
<% end -%>


<%= link_to 'Back', posts_path %>

透過 form_for 傳送出來的表單，會被壓縮包裝成一個 parameter: params[:post]，

1
2
3
4
5
6
7
8
9

def create
  @post = Post.new(params[:post])
  if @post.save
    flash[:notice] = 'Post was successfully created.'
    redirect_to post_path(@post)
  else
    render :action => "new"
  end
end

如此一來，原本創造新資源的一連串繁複動作就可以大幅的被簡化，開發速度達到令人驚艷的地步。

參考資料：

• 百度百科：REST
• Wikipedia: REST
• Wikipedia: ROA
• DHH: Discovering a world of Resource on Rails
• ihower: Rails RESTful 制約即解放
• ihower: 什麼是 REST 與 RESTful

說到 RESTful，幾乎每個剛踏進 Rails 框架中的開發者都皺起眉頭。幾乎沒有人能夠在初學階段搞的懂這是什麼玩意。偏偏初學者往往有一個「死扣細節」的壞習慣：沒「弄懂」就「不敢用」，結果在第一個關卡挫折感就堆的如山高，把玩 RESTful 後打退堂鼓，回頭大罵爛設計的人比比皆是。

想學 Rails 就先把 RESTful 背起來

RESTful 是 Rails 裡面使用的最基礎最頻繁的一個設計手法，偏偏它也是最難一次講解清楚讓剛入門者理解的一個主題。因為在傳統 web 應用程式開發流程中，根本沒有這樣的概念。更別提在市面上這麼多網頁框架，只有 Rails 將之視為預設值。

別說是初學者，就連筆者和一些 Rails 界的前輩，在 Rails 剛納入 RESTful 為預設風格時，也沒能通透其中原理。

但是不熟練 RESTful 的開發架構，在開發 Rails 時幾乎會寸步難行。在訓練新 Developer 時如何讓他短時間就熟練便上手呢？

我的方法很簡單：強迫他背起來，然後重複寫十遍。

聽起來很唬爛，但練過十遍以後。這時候再重新講解一次 RESTful 的概念，原本模糊的概念一下就變得豁然開朗了。

初步熟悉使用 Rails RESTful

在 config/routes.rb 內加入 resources

在 config/routes.rb 加入 resources :posts，就是具體在 rails 對一個 controller 實作 RESTful 的方式（對一個 controller 宣告成為 resources)。

1
2
3

Demo::Application.routes.draw do
  resources :posts
end

這樣的宣告將在自動對應 URL路徑跟 Controller 的 action ，而有以下的結果：

• GET: /posts => [:action => ‘index’]
• GET: /posts.xml => [:action => ‘index’, :format => ‘xml’]
• GET: /posts/1 => [:action => ‘show’, :id => 1]
• GET: /posts/1/edit => [:action => ‘edit’, :id => 1]
• GET: /posts/1.xml => [:action => ‘show’, :id => 1, :format => ‘xml’]
• POST: /posts => [:action => ‘create’]
• PUT: /posts/1 => [:action => ‘update’, :id => 1]
• DELETE: /posts/1 => [:action => ‘destroy’, :id => 1]

並產生了一套 url helpers 給 View 使用。

各 action 內部的動作以及對應 path

以下透過專案中使用 RESTful 應該會出現的程式碼作講解。讀者可以透過 rails generate scaffold Post subject:string content:text 看到這些程式碼。

index

通常會放置列表。因此 Post.all 是拉出 Post 這個 model 所有的資料。

1
2
3

  def index
    @posts = Post.all
  end

show

秀出單筆資料。 Post.find(123) 是指找 Post model 裡 id 為 123 的資料。http://demosite.com/posts/show/123 的 posts 是 controller、show 是 action；如果在 route 裡面沒有特別指定，則 123 通常就是 params[:id] 。

1
2
3

  def show
    @post = Post.find(params[:id])
  end

new

initial 一個新的 Post object。

1
2
3

  def new
    @post = Post.new
  end

edit

query 出指定的 Post model object，然後進行編輯。

1
2
3

  def edit
    @post = Post.find(params[:id])
  end

create

這邊要搭配 app/views/posts/new.html.erb 這個 view 並列一起看。

1
2
3
4
5
6
7
8
9

def create
  @post = Post.new(params[:post])
  if @post.save
    flash[:notice] = 'Post was successfully created.'
    redirect_to post_path(@post)
  else
    render :action => "new"
  end
end

1
2
3
4
5
6
7
8
9
10
11

<h1>New post</h1>

<%= form_for @post , :url => posts_path do |f| %>
    <%= f.error_messages %>
    <div><label>subject</label><%= f.text_field :subject %></div>
    <div><label>content</label><%= f.text_area :content %> </div>
    <%= f.submit "Submit", :disable_with => 'Submiting...' %>
<% end -%>


<%= link_to 'Back', posts_path %>

在 RESTful Rails 的寫法中，對 posts_path 丟 POST 就是對應到 create 的動作。而 Rails 在設計上，form 是綁 model 的，因此整個 form 的內容會被包成一個 hash，在這裡就是 params[:post]。create action 初始一個 object ，並把 params[:post] 整包塞進這個 object 裡。如果 @post 能夠成功的儲存，就「重導」到 index action ，失敗則「退回」到 new action 。

update

這邊也要翻回 app/views/posts/edit.html.erb 這個 view 一起來看。

1
2
3
4
5
6
7
8
9

def update
    @post = Post.find(params[:id])
    if @post.update_attributes(params[:post])
     flash[:notice] = 'Post was successfully updated.'
     redirect_to post_path(@post)
    else
      format.html { render :action => "edit" }
    end
  end

1
2
3
4
5
6
7
8
9
10

<h1>Editing post</h1>
<%= form_for @post , :url => post_path(@post) , :html => {:method => :put} do |f| %>
    <%= f.error_messages %>
    <div><%= f.text_field :subject %>
    <div><%= f.text_area :content %></div>
    <%= f.submit "Submit", :disable_with => 'Submiting...' %>
<% end -%>

<%= link_to 'Show', post_path(post) %> |
<%= link_to 'Back', posts_path %>

在 RESTful Rails 的寫法中，對 post_path 丟 PUT 就是對應到 update 的動作。form 會背包成一個 hash，如果 @post 能夠吃進 params[:post] 進行更新且成功儲存，就會「重導」到 show action，失敗則「退回」到 edit action。

delete

找到該筆資料並刪除之。在 RESTful Rails 的寫法中，對 post_path 丟一個 DELETE，就會對應到 destroy 的動作。可看一下 link_to "Destroy"那一行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<h1>My post</h1>
<h2><%= link_to 'New post', new_post_path %></h2>
<table>
  <tr>
  </tr>

<% @posts.each do |post| %>
  <tr>
    <td><%= post.subject %> </td>
    <td><%= link_to 'Show', post_path(post) %></td>
    <td><%= link_to 'Edit', edit_post_path(post) %></td>
    <td><%= link_to 'Destroy',  post_path(post), :method => :delete %></td>
  </tr>
<% end %>
</table>

還是不理解為什麼要這樣寫？沒關係，先練習十遍。練到不需要思考就能夠手寫這些程式碼再說。

1
2

-<h1>Listing posts</h1>
+<h1>Listing posts - Total <%= @board.posts.size %> posts </h1>

使用 @board.posts.size 機制直接算出 boards 下有幾篇文章，產生的 SQL query 是使用 SELECT COUNT(*)

1

SQL (0.1ms)  SELECT COUNT(*) FROM "posts" WHERE ("posts".board_id = 1)

若在 posts 數量相當大時，存取 boards#index 將會造成沈重的負擔。我們應該找個方法把這個數值 cache 起來。

Solution 1

• 應該在 board model 新增一個 integer 欄位紀錄有多少篇文章
• 每當文章被 新增 / 刪除之際，在 controller +1/-1 文章數量

Solution 2

這樣要寫太多行 code 了，事實上 Rails 內建了一個 counter_cache 的機制。當文章建立或刪除時，會自動進行 +1/-1 功能。

修改 app/models/post.rb

1
2

-  belongs_to :board
+  belongs_to :board, :counter_cache => true

1

$ rails g migration add_posts_count_to_board

修改 db/migrate/20110529014114_add_posts_count_to_board.rb

1
2
3
4
5
6
7
8
9

class AddPostsCountToBoard < ActiveRecord::Migration
  def self.up
    add_column :boards, :posts_count , :integer, :default => 0
  end

  def self.down
    remove_column :boards, :posts_count
  end
end

之後 @board.posts.size 就是直接去撈 posts_count 欄位的數字了。

注意事項

若 boards 內早已有文章，直接加上 counter_cache => true 會導致抓到的 size 是初始值 0。建議先開設 posts_count 欄位，手動跑個計算，先將正確統計數字加總後回存 posts_count，再宣告 counter_cache => true

如果今天需要下一段 query 做出 recent 效果，我們會手寫一段 method

1
2
3

def recent
   find(:all, :order => “created_at DESC”)
end

需要 popular

1
2
3

def popular
   find(:all, :order => “visitors_count DESC”)
end

但如果，我們需要 Post.recent.popular 呢？

Rails 的 method 好像不能這樣串。 腦袋當機….

也許我們可以寫個 recent_and_popular

但是，在別一段 code 我們需要的是 Post.popular.recent 呢？

兩個條件已經夠讓你頭大了，但真實世界會有無窮的條件等著排列組合。你不可能永遠定義 method 去暴力解決串接的問題。

has_finder 就是設計來滿足串接的需求，自動產生需要產生的 query。而 has_finder 在 Rails 2 時被納為內建 feature named_scope，在 Rails 3 時強化原先的 feature，再次更名為 scope。

Default Scope

#TODO

Other Scope

#TODO

它的面世，推動了新的 Asset 整理概念，也向世界的開發者，介紹了 SCSS / Compass，引爆在 CSS 開發上無限的可能。

使用 Sass / SCSS 撰寫 CSS

Asset Pipeline 提供了內建直接使用 Sass 撰寫 CSS 的功能。

Sass 是 Haml 這個 project 中的一部分 feature。 Haml 能讓開發者能夠使用縮排的方式撰寫 HTML，輕鬆做到永不忘記關 Tag 的效果。

Haml

1

%h1= "Hello World"

產生出來的 HTML 就會長這樣

1

 <h1>Hello World</h1>

Haml 是需要使用縮排撰寫，再行 compile 的 markup language。它可以讓你：

• 阻絕撰寫出錯誤結構的 HTML TAG 的機會

只要 syntax 一錯誤，編譯就無法成功。利用這樣的特性，很容易阻絕寫出會在瀏覽器因為 TAG 結構錯誤而難以 debug 出的 HTML。

在網頁設計開發階段，若要大幅調整 HTML 結構，對網頁設計師也是很傷腦筋的一件事。因為大幅的搬動 HTML，通常有時候會造成：「少剪到一個 TAG」或 「改了開頭 TAG ，卻忘了改關閉 TAG 」的憾事。

在 Haml 中，這些狀況都不會發生。因為 Haml 本身就屬於「塊狀結構」、「自我 close」。因此不論怎樣搬動和調整，只要符合縮排，幾乎都不會爆炸。

• 輕鬆調整排版

然而 Haml 並沒有如預期中風行？反倒是原先屬於副功能的 Sass 大紅特紅。原因就在於 Haml 的特性：不只需要被機器 compile，它也需要被人腦 compile。HTML 本身就是一門相當直觀的 markup language。在撰寫 Haml 時，排版雖然相當輕鬆。但接手維護 Haml 版面的人，卻通常痛苦不堪。因為「非常不直觀」。

Sass / SCSS

回頭談 Sass，Sass 原先是附屬在 Haml 裡面的一個副功能。這也是 sass-convert 這個指令必須要安裝 haml 這個 gem 才能使用的原因。Sass 的原理，是讓開發者可以透過「縮排」的方式去撰寫維護 CSS，同樣可以避免忘記關 TAG 而大爆炸的糗事。而因為 CSS 的結構特性，造成了 Sass 與 Haml 截然不同的命運。多數人反對 Haml，是因為 Haml 反而造成了 HTML 在閱讀上的不直觀。

而 Sass 的語法

1
2
3
4

  .content
    margin: 2em 0
    h1
      font-size: 2em

1
2
3
4
5
6

   .content{
    margin: 2em 0;
   }
   .content h1{
      font-size: 2em;
   }

反倒讓 CSS 的維護變得直觀了。

接觸 Sass / SCSS 後的不少開發者甚至認為：縮排 block 的撰寫方式才是 CSS 在被發明時應該被設計出來的樣子。現在撰寫 CSS 的方式，有一個絕大缺點：只要在結構上涉及巢狀或多個 class，維護者就必須複製貼上 style。不少人認為這真是愚蠢至極且煩人透頂的設計。

內建 Killer features 讓維護 CSS 變得更簡單

Sass 也提供了其他便利功能，如變數、函數、數學、繼承、mixin …等等功能。

在進行網頁 protyping 時，更改全站配色或者是直接提供兩個以上的設計，對設計師來說是家常便飯的事。

但更改全站配色卻是相當麻煩的一件事，因為「尋找 + 全數取代」，並不能保證最後會有正確的結果。很有可能：你更改了所有 CSS 中涉及連結的顏色，卻發現在全數取代的過程中，不小心也改到邊框的顏色。

若能使用變數去指定特定 style 的顏色，該有多好。

• 變數 ( Variables )

1
2
3
4
5
6

   $border-color: #3bbfce
   $link-color: #3bbfcf
   .content
      border-color: $border-color
      a
        color: $link-color

1
2

   .content{ border-color: #3bbfce; }
   .content a{color: #3bbfcf; }

• 數學

在調整區塊寬度時，你也希望：每次調整寬度時，可不可以不要每次都按計算機，再全數手動修改…

1
2

   .content
      width: (500px/2);

1

   .content{ width: 250px; }

• 內建函式

在調整顏色亮度時，你希望可否無需再開調色盤，直接改 CSS 就讓 style 暗一點？

1
2
3

   $color = darken(#800, 20%)
   .content
      background-color: $color

1

   .content{ background-color: #200; }

這都還只是 Sass 所提供的當中一小部分基礎功能而已，卻足以讓網頁設計師驚艷十足了。加上撰寫維護時十分直觀，這也難怪為何 Sass 只是 Haml 中的副功能，後繼的聲勢浪頭卻遠高於 Haml 本身。

SCSS

那 SCSS 又與 Sass 有什麼差別，他們看起來好像是類似的東西？

是這樣的，Sass 原先使用的縮排，對於網頁設計師來說，還是相當不直觀。而且實務上也不能直接將舊有的 CSS 直接貼進 Sass 中。其實還是存在一定的不方便度。也因此 Sass 進行了進化，改良了 syntax，而 Sass 3 後來就被稱為 SCSS ( Sassy CSS)。

它的 syntax 與 CSS 原有的 syntax 完全 compatible，使用了 { } 去取代原先的縮排方式。

比如說原有的

1
2
3
4

  .content
    margin: 2em 0
    h1
      font-size: 2em

在 SCSS 中變成了

1
2
3
4

  .content{
    margin: 2em 0;
    h1 {font-size: 2em }
  }

在撰寫上，更加無比的直觀，同時也能將舊有的 CSS 直接貼進去，完全沒問題！SCSS 更新增了不少關於 CSS3 的 feature 函式。

就拿我最愛的背景漸變色來說好了，原先要做漸變色，CSS 必須要這樣寫：

1
2
3
4
5
6
7
8

 #linear-gradient {
   background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #ffffff), color-stop(100%, #dddddd));
   background-image: -webkit-linear-gradient(left top, #ffffff, #dddddd);
   background-image: -moz-linear-gradient(left top, #ffffff, #dddddd);
   background-image: -o-linear-gradient(left top, #ffffff, #dddddd);
   background-image: -ms-linear-gradient(left top, #ffffff, #dddddd);
   background-image: linear-gradient(left top, #ffffff, #dddddd);
 }

因為你必須支援所有的 Browser。

但在 SCSS 中，一行就搞定了！

1

 #linear-gradient { @include background-image(linear-gradient(left top, white, #dddddd)); }

什麼是 Compass

Sass : extend / mixin / import

在 Sass 一章，我們只提到了一些基礎的部分。更強大的其實是這些功能

• extend
• mixin
• include

extend

extend 可以讓你將某些已經寫好的樣式，直接套入另外一組樣式中重複使用。

CSS 的原始內容：

1
2
3
4
5
6
7
8
9

   .warning{
      border: 1px;
      color: red;
   }
   .serious-warning{
       border: 1px;
       color: red;
       font-weight: bold;
   }

而使用 extend，只需這樣寫，就可生成上述 CSS 了：

1
2
3
4
5
6
7
8

   .warning{
      border: 1px;
      color: red;
   }
   .serious-warning{
       @extend .warning;
       font-weight: bold;
   }

mixin

可以預先寫好自定要被 mixin 的 function ，需要用時 include 進來

1
2
3
4
5
6
7

 @mixin rounded-top {
   $side: top;
   $radius: 10px;
   border-#{$side}-radius: $radius;
   -moz-border-radius-#{$side}: $radius;
   -webkit-border-#{$side}-radius: $radius;
 }

要用時 include 進來

1
2

   #navbar li { @include rounded-top; }
   #footer { @include rounded-top; }

import

可以把太長的 SCSS 拆開成一個一個的 partial，要用時 import 進來。

1
2

   //需要被 import 的檔案必須以 _開頭命名，如 _rounded.scss
   @import "rounded";

有了 extend / mixin / import，加上 variable，加上支援部分 Ruby syntax。

聰明的你，應該想到這些元素集合起來可以作什麼？

沒錯，就是造 CSS Framework！

Compass = Sass framework powered by community

Sass 提供了一堆基本武器可以讓許多開發者造出自己的最佳實踐，再讓其他人可以重複利用。而 Compass 就是這些實踐產物的集合體。

例如 Compass 實際就提供以下這些熱門 CSS framework 的 mixin：

• Blueprint
• 960
• Susy
• YUI

開發者也能夠利用 Sass + Compass 自己造出很多超棒的小工具，如： Fancy Buttons。

而 Compass 自己的 core 更是充滿 killer features，比如說：

• CSS3 helpers http://compass-style.org/reference/compass/css3/

撰寫漸層色與圓角框不再是令人頭大的難事。

漸層色 Background Gradients : http://compass-style.org/examples/compass/css3/gradient/

1
2

#linear-gradient {
  @include background-image(linear-gradient(left top, white, #dddddd)); }

1
2
3
4
5
6
7
8

#linear-gradient {
  background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #ffffff), color-stop(100%, #dddddd));
  background-image: -webkit-linear-gradient(left top, #ffffff, #dddddd);
  background-image: -moz-linear-gradient(left top, #ffffff, #dddddd);
  background-image: -o-linear-gradient(left top, #ffffff, #dddddd);
  background-image: -ms-linear-gradient(left top, #ffffff, #dddddd);
  background-image: linear-gradient(left top, #ffffff, #dddddd);
}

圓角框 Border radius: http://compass-style.org/examples/compass/css3/border_radius/

1
2

#border-radius {
  @include border-radius(25px); }

1
2
3
4
5
6
7
8

#border-radius {
  -moz-border-radius: 25px;
  -webkit-border-radius: 25px;
  -o-border-radius: 25px;
  -ms-border-radius: 25px;
  -khtml-border-radius: 25px;
  border-radius: 25px;
}

• CSS3 Pie : http://compass-style.org/reference/compass/css3/pie/

擔心使用 CSS3 ，IE 無法支援？Compass 內建支援 CSS3 Pie。

• 輕鬆造出多欄設計 http://compass-style.org/examples/blueprint/grid/two_cols/

討厭在 HTML 上寫 CSS grid system require 的 class name 嗎？配合 Blueprint 做 mixin，輕鬆造出多欄版面！

1
2
3
4
5
6
7
8
9
10
11
12

$blueprint_grid_columns: 8;
$blueprint_grid_width: 40px;
@import "blueprint";
.two-col {
  @include container;
  background-color: #cccccc;
  #header, #footer {
    @include column(8); }
  #sidebar {
    @include column(3); }
  #content {
    @include column(5, true); } }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<div class='two-col'>
  <div id='header'>
    <h1>This is the Header</h1>
  </div>
  <div id='sidebar'>
    <ul>
      <li>
        <a href='#'>Nav #1</a>
      </li>
      <li>
        <a href='#'>Nav #2</a>
      </li>
      <li>
        <a href='#'>Nav #3</a>
      </li>
    </ul>
  </div>
  <div id='content'>
    <p>
      Lorem ipsum dolor sit amet,
      consectetur adipisicing elit, sed do
      eiusmod tempor incididunt ut labore et
      dolore magna aliqua.
    </p>
  </div>
  <div id='footer'>
    This is the footer.
  </div>
</div>

• 不費吹灰之力實作 CSS Sprites

知道什麼是 CSS Sprites 技巧嗎？

CSS Sprites 是 Minimize HTTP Requests 中的一招，實作方式是將 CSS 中的小圖合併成較大的一張，再透過 CSS 定位的方式呼叫。比如說這個 CSS 中原先需要用到十張小圖，合併到只剩一張，就變得非常節省 HTTP requests（ 因為光是發出 requests 也相當耗時）。

問題是，負責 Scaling 的 server guy 很喜歡這招，但網頁設計師卻對這件事相當感冒。因為太麻煩了！

試想，url(‘xxx.gif’) 到處貼多方便呀，誰喜歡合併成一張，然後仔細精算定位？後續維護又怎麼辦呢？

Well，Compass 幫你「自動解決了問題」！http://compass-style.org/help/tutorials/spriting/

你可以把原先所有要用的小圖，通通丟進同一個資料夾。讓 Compass 幫你自動合併並算出位置！

1
2

@import "icon/*.png";
@include all-icon-sprites;

Compass 會幫你自動合併並算出位置：

1
2
3
4
5
6
7
8
9

.icon-sprite,
.icon-delete,
.icon-edit,
.icon-new,
.icon-save   { background: url('/images/icon-s34fe0604ab.png') no-repeat; }
.icon-delete { background-position: 0 0; }
.icon-edit   { background-position: 0 -32px; }
.icon-new    { background-position: 0 -64px; }
.icon-save   { background-position: 0 -96px; }

毛骨悚然的強大呀！

如何整理 SCSS

在實務演變中，Sass 的通用規則大致上是朝往這幾個方向拆：

• by feature
• by special block
• by default block ( header / footer / sidebar )
• by (Rails) controller
• by page specific

Examples

#TODO

你也許會問，Ruby 是直譯語言，不需要 compile，為何還需要 Build Tool。

與其說 Rake 是一套 Build Tool，還不如說是一套 task 管理工具。我們通常會使用 Ruby based 的 Rake 在 Rails 專案裡編寫 task。

Rails 內的 rake tasks

rake -T 會秀出一大串這個 Rails project 可用的 rake tasks (包含 plugin 內建的 task 也會秀出來)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

rake about              # List versions of all Rails frameworks and the environment
rake assets:clean       # Remove compiled assets
rake assets:precompile  # Compile all the assets named in config.assets.precompile
rake db:create          # Create the database from config/database.yml for the current Rails.env (use db:create:all to create all dbs in the config)
rake db:drop            # Drops the database for the current Rails.env (use db:drop:all to drop all databases)
rake db:fixtures:load   # Load fixtures into the current environment's database.
rake db:migrate         # Migrate the database (options: VERSION=x, VERBOSE=false).
rake db:migrate:status  # Display status of migrations
rake db:rollback        # Rolls the schema back to the previous version (specify steps w/ STEP=n).
rake db:schema:dump     # Create a db/schema.rb file that can be portably used against any DB supported by AR
rake db:schema:load     # Load a schema.rb file into the database
rake db:seed            # Load the seed data from db/seeds.rb
rake db:setup           # Create the database, load the schema, and initialize with the seed data (use db:reset to also drop the db first)
rake db:structure:dump  # Dump the database structure to an SQL file
rake db:version         # Retrieves the current schema version number
rake doc:app            # Generate docs for the app -- also available doc:rails, doc:guides, doc:plugins (options: TEMPLATE=/rdoc-template.rb, TITLE="Custom Title")
rake log:clear          # Truncates all *.log files in log/ to zero bytes
rake middleware         # Prints out your Rack middleware stack
rake notes              # Enumerate all annotations (use notes:optimize, :fixme, :todo for focus)
rake notes:custom       # Enumerate a custom annotation, specify with ANNOTATION=CUSTOM
rake rails:template     # Applies the template supplied by LOCATION=(/path/to/template) or URL
rake rails:update       # Update configs and some other initially generated files (or use just update:configs, update:scripts, or update:application_controller)
rake routes             # Print out all defined routes in match order, with names.
rake secret             # Generate a cryptographically secure secret key (this is typically used to generate a secret for cookie sessions).
rake stats              # Report code statistics (KLOCs, etc) from the application
rake test               # Runs test:units, test:functionals, test:integration together (also available: test:benchmark, test:profile, test:plugins)
rake test:recent        # Run tests for recenttest:prepare / Test recent changes
rake test:single        # Run tests for singletest:prepare
rake test:uncommitted   # Run tests for uncommittedtest:prepare / Test changes since last checkin (only Subversion and Git)
rake time:zones:all     # Displays all time zones, also available: time:zones:us, time:zones:local -- filter with OFFSET parameter, e.g., OFFSET=-6
rake tmp:clear          # Clear session, cache, and socket files from tmp/ (narrow w/ tmp:sessions:clear, tmp:cache:clear, tmp:sockets:clear)
rake tmp:create         # Creates tmp directories for sessions, cache, sockets, and pids

批次動作

在專案開發中，我們不免需要寫一些 script 批次執行動作。開發者可以用 runner 或者 Rake。

runner

#TODO

Rake

但多半我們會使用 Rake 而非 runner，這是因為 Rake 可以載入整個環境( Rails environment)，對 ORM 或者是 Rails 專案的內部做存取。而使用 Rake 撰寫的程式也較有組織性。

自己撰寫的 rake 的程式位置應該放在 lib/tasks 下。

lib/tasks/dev.rake

筆者在專案開發中尚未上線之際，還蠻常需要清掉整個資料庫重新跑一次的。這時候一次一次重打 rake db:drop、rake db:create、 rake db:migrate。實在是很煩的事。這樣的連鎖動作我通常會包裝成一支 rake。

• dev:build

1
2
3
4
5

namespace :dev do
  desc "Rebuild system"
  task :build => ["tmp:clear", "log:clear", "db:drop", "db:create", "db:migrate"]
  task :rebuild => [ "dev:build", "db:seed" ]
end

• dev:fake

#TODO

package dependency 一直是相當麻煩的問題。解不開，就無法將程式 boot 起來。

原先大家也只有拿 Bundler 搭配 Rails 使用。

而後來 Bundler 也逐漸變成一般 Ruby 程式中預設的套件 dependency 管理程式。

Bundler 中的 Gemfile 設計，不只能讓開發者能夠輕易的解決套件相依問題，並且可以直接引入「開發中」套件，解決 3rd gem 版本更新過慢，卡住自己開發進度的問題。

Gemfile 範例

1
2
3
4

gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git'
gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git',:branch => 'stable-2'
gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git',:tag => 'tag-2'
gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git',:ref => '23456'

1. 不知道有 Rails 提供了許多好用的 Helper 可以用
2. 不知道 Helper 與 Partial 他們各自的使用時機。
3. 擔心使用 Helper 會造成效能下降。
4. 以不好的方式使用 Helper 反而使維護性降低。

Helper 與 Partial 的不同

Partial

Partial 指的是局部樣板。而 Helper 指的卻是在樣板中的一些輔助方法（Ruby Method）。這兩種都是整理又臭又長的 HTML 版面時的好工具。

一般而言，我們會使用 Partial 去處理大段且重複的程式碼。或者是經常使用到的局部程式碼。

• 大段程式碼：（如 new / edit 會複用到的表單）

1
2
3

<%= form_for @post do |f| %>
    <%= render :partial => "form", :locals => { :f => f} %>
<% end %>

• 經常使用到的局部程式碼：（如 sidebar 內的區塊）

1
2
3
4

<div id="sidebar">
  <%= render :partial => "recent_posts" %>
  <%= render :partial => "recent_comments" %>
</div>

…etc.

Partial 的優點

• Don’t repeat yourself（DRY）程式碼不重複
• 程式修改會比較清楚
• Partial 樣板比較容易被重複使用

Helper

Partial 的定位多半是被用來處理「大片 HTML 」的工具，而 Helper 卻是比較屬於需要邏輯性輸出 HTML 時用的整理工具。

一般我們學 Rails 常見的

• stylsheet_link_tag
• link_to
• image_tag
• form_for 中的 f.text_field…etc

都屬於 Helper 的範疇。

在專案中使用 Rails 內建 Helper 開發的原因

其一：為了省力

Rails 最令其他 Ruby Web Framework 羨慕的，就是內建的很多方便 Helper。

舉幾個其實很方便，但大家其實不太知道它們存在的 Helper 好了。

• simple_format : 可以處理使用者的內容中 \r\n 自動轉 br 和 p 的工作
• auto_link :可以處理使用者的內容中，若有連結，就自動 link 的工作。
• truncate: 使用者輸入的內容，若過長，可以指定多少字後就自動砍掉，並加入 “….”
• html_escape: 使用者輸入的內容，若有 html tag，為了怕使用者輸入惡意 tag 進行 hack。自動過濾。（以前要手動加 h 過濾，現在 Rails 預設 escape，不想被 escape 才手動指定 raw 閃掉 escape）

這些東西若自己寫 parser 處理，不知道要花費多少精力，還不一定濾的徹底。卻都是 Rails 預設內建 Helper。

其二：為了跟 Rails 內建的其他更棒的基礎建設整合

• stylesheet_link_tag 與 image_tag

有些人也覺得，這東西還要用 Helper 嗎？直接貼 HTML 不是也一樣會動嗎？有什麼差別。差別可大了。

1

 <%= stylesheet_link_tag "abc", "def", :cache => true %>

這一個 Helper，可以在 production 環境時，自動幫你將兩支 CSS 自動壓縮成一支 all.css 。直接實現了 Yahoo Best Practices for Speeding Up Your Web Site中，minify HTTP reqesut 的建議。而在 Rails 3.1 之後，甚至還會自動幫你 trim 與 gzip。

完全不需要去在 deploy process 中 hook 另外的 compressor 就可以達到。

至於 image_tag 有什麼特別的地方？

1

 <%= image_tag("xxx.jpg") %>

Rails 可以幫你的 asset 自動在後面上 query string，如：xxx.jpg?12345

這樣在網站若有整合 CDN 架構時，可以自動處理 invalid cache 的問題。

而 Rails 也有選項可以實作 asset parallel download 的機制，一旦打開，站上的 asset 也會配合你的設定，亂數吐不同來源的 asset host 實做平行下載。

輕鬆就可以把網站 Scale 上去。

• form_for

這也是 Rails 相當為人稱讚的一個利器。Rails 的表單欄位是綁 model (db 欄位的)，除了開發方便（ Post.new(params[:post]) 直接收參數做 mapping）之外，也內建了防 CSRF (protect_from_forgery)的防禦措施。

開發者可以在一眨眼的工夫，借助框架的力量，實作出業界（performace /security）最佳實踐。而卻不需要先修煉成架構大師。

為什麼在專案中我們要撰寫「自用」 Helper？

其一：在 View 裡面實作 LOGIC 是不好的。

造成效能低落

在 View 裡面實作 LOGIC 的影響，最主要導致的後遺症就是：「效能低落」（此部份詳細來龍去賣在其他章節會進行解釋 #TODO）。簡單版本的原因是 ERB 是用 eval 實作 執行 Ruby code 的，在 View 裡面穿插大量的 LOGIC 會造成 render 的效率低落。

造成程式碼混亂難讀

View 在 MVC 的模式中，原本就是只為了做 UI 輸出的功用的。如果有程式邏輯，或者是資料查詢，應該挪到 Controller 或 Model 去做。

這通常在 PHP 轉檯轉過來的 developer 身上，比較能找到這樣的問題。原因是在 PHP 程式寫作開發中，這是很天經地義的作法。但眾所週知的，PHP 的 project 也特別容易藏汙納垢。

如果你手上的 Project，View 打開來都 7-8 頁以上，別懷疑，肯定都是 LOGIC in View 造成的。

而根據過往經驗：有冗長 View 的 project，往往比有冗長 controller 的 project 還要難纏。

一個 View 裡面若有著很多 if / else / elsif , query_some_data。或者有著 if / else / elsif , change some css class ？

人的大腦不是 Ruby Interpreter，很難腦內想像這麼複雜的 code 會長什麼樣子，沒多久就會當機的….

其二：讓 View 更加直觀好維護。

在沒有注釋的情況下，你看得懂這段 code 的意圖嗎？

1
2
3

  <% if current_user && (post.user == current_user || current.user.is_forum_admin? || current.user_is_admin? ) %>
  <%= link_to("Edit", edit_post_path(post) ) %>
  <% end %>

這行範例程式碼，我想邏輯還算簡單，應該不難讓人讀懂。不過若再經過兩三輪的維護，應該就會變得超難維護了。

正確的整理法

正確的整理法其實應該要把邏輯拆出來，放在 Helper 裡。就像這樣：

1
2
3

  <% if can_edit?(post) %>
     <%= link_to("Edit", edit_post_path(post) ) %>
  <% end %>

這樣就能讓後續維護者知道，這一段程式碼就是在表示：如果當前使用者有權限編輯，就應該顯示編輯頁面的連結。

其三：給 Code 取名字，容易尋找並複用成果。

前段程式碼寫得不算太優，因為到目前為止它只表明了：如果當前使用者有權限編輯，就應該顯示編輯頁面的連結。。並沒達到正確闡述自己存在的的意義。

而這一塊原始碼的意圖是：若有編輯權限，就應該顯示一塊 toolbar。

1

<%= render_tool_bar %>

包裝成 toolbar 後，這一塊程式碼就變得有名字了。下次開發者在某個頁面要寫到類似的功能時，就只要呼叫 render_tool_bar 就可以了。

而最重要的，是以後再維護這一塊程式碼時，完全不必再猜測程式意圖，也很容易找當初亂丟在哪裡了。

其四： 不會被以前寫的 Code 害死。

1
2
3

  <% if current_user && (post.user == current_user || current.user.is_forum_admin? || current.user_is_admin? ) %>
  <%= link_to("Edit", edit_post_path(post) ) %>
  <% end %>

這種 code 在網站初期建設需要高速開發時沒有什麼不好。其實也還算讓人看得懂…

但我個人的建議是：一旦接近完工狀態，就要儘快抽空 refactor 掉它。

沒有組織結構的 code 一旦越來越多，專案就會越來越難維護。累積到一個程度，就會轉變成 unmaintainable 的狀態，到時候就算呼叫神仙也難回天。

像是我個人參與的專案，在開發中都有一個慣例：一旦專案開發快到尾聲，大家就會開始整理程式碼，把重複的部分重新翻修包成有名字的 Helper。

這樣作有什麼好處？

1. 網站以後要進行結構重整時，只要調整已定義好的 Helper 內部架構就好了。如果還是東一個西一個到處亂放，同樣的東西重複貼 10 個地方，將來想要調整就要改 10 遍。相信我，你不喜歡在「改版時期」改 code 改 10 遍。就算是可以使用 git grep 抓漏還是會失手…

2. 無痛升級 Rails 版本。有很多人好奇筆者手上的每個專案，為何可以一路從 2.3.x 一路升升升到 3.1.x 去。卻還算輕鬆愉快？

印象當中這中間的改版：不是有令人抓狂的 html_escape API 行為改變問題？asset_pipeline 架構調整？這些都是很令人抓狂的過程。不少開發者都在升級過程中放棄了。為什麼我們辦得到。

我想，當中最關鍵的原因，不在於「有沒有寫 test」，而是在於「有沒有擁有定期整理 code 的習慣」。

若定時整理 helper / partial / controller / model 的程式碼。只要是發現重複 code，馬上進行封裝整理。將來就算有東西爆炸，多半也只要調整一下 helper 或者是 model 的輸出，馬上就解決問題了。

所以就算是遇到 Rails 升級的問題，開發者也可以專注把精力集中在處理幾個 deprecated method 或 incompatible API 的調整。就算 view 爆掉了，修一個地方，十個地方隨之生效。自然寫意無比。

其五：容易複用並開創專案打下來的 best practices

在進行專案過程中，也會漸漸的養出自己的一套 HTML 架構 與 CSS (SCSS)。很多元件在不同專案中都是共通的，比如說自己用來 bootstrap （非 twitter）專案的 view 和 helper。

navgation_bar, user_bar, breadcrumb, menu list, table, button,gravator 這些都是專案必備。

這是台灣知名的 Rails 網站設計公司 Handlino 設計的一套 helper https://github.com/handlino/handicraft_helper

可以很方便就寫出 menu, table, body class with browser type, breadcrumb…etc.

而筆者在自己作網站還會多裝上幾套自己養出來的標準 Helper

• SEO 最佳化實踐
• Social Media Share-Friendly
• Content Site 常用功能最佳實踐

專案越寫越多，後期越來越輕鬆，但不管之後再寫什麼新網站，依舊是幾乎都預設含有以前維護舊網站時打下的 Best Practices.

這就是越資深的 Rails Developer 開發新專案能夠越來越快速的原因之一。

1
2
3

<% Post.limit(10).each do |post| %>
<%= post.categories.map{ |c| "<span>#{c.name}</span>"} =%>
<% end %>

• Some operation is very EXPENSIVE

Solution

• cache expensive operation
  • counter_cache, memorize, cache
• includes
• find_in_batch

1

 # match ':controller(/:action(/:id(.:format)))'

• 程式碼失去組織性
• 嚴重的 security issue

免跨站偽造請求 Cross-site request forgery

• 所有讀取、查詢性質操作，都應該用GET
• 修改或刪除到資料的，則要用POST、PUT或DELETE
• 所有的POST請求，都必須加上一個安全驗證碼

內建機制

app/controllers/application_controller.rb

1
2
3

class ApplicationController < ActionController::Base
  protect_from_forgery
end

app/views/layout/application.html.erb

1

<%= csrf_meta_tag %>

1

 # match ':controller(/:action(/:id(.:format)))'

• 硬幹就失去天然屏障了，任何 action 都可以 get

1

   <img src="/posts/delete_all">

安全性：透過對資源操作的限制，可以阻擋不安全的操作。

需要安全性的操作行為，需要透過表單的 POST，才能執行。

然而開發者可能只會記得在 .htaccess 加入對 /question/1/delete 的 URL mapping，卻忘記這個動作需要關閉 GET，否則 hacker 就可以透過製造惡意的連結，誘騙管理者誤開連結，砍除大量的資料。

1
2

<form accept-charset="UTF-8" action="/post/delete_all" method="post" novalidate="novalidate">
</form>

而在 Rails 中，因為採用 REST，對於一個資源送 GET / POST / PUT / DELETE 都會對應到不同的 action，所以不會有這樣的情形發生。

修改文章的表單

1
2
3
4
5
6
7
8
9
10

<h1>Editing post</h1>
<%= form_for @post , :url => post_path(@post) , :html => {:method => :put} do |f| %>
    <%= f.error_messages %>
    <div><%= f.text_field :subject %>
    <div><%= f.text_area :content %></div>
    <%= f.submit "Submit", :disable_with => 'Submiting...' %>
<% end -%>

<%= link_to 'Show', post_path(post) %> |
<%= link_to 'Back', posts_path %>

1

 post.aa.bb.cc.dd.ee.ff.gg.hh.ii.jj.kk.ll.mm.nn.oo.pp

後果

• Create A LOT OF objects
• Complex JOIN & SLOW query

Solution

• 使用 scope 整理 code
• 使用 method 整理 code
• 使用 query_reviewer 檢查 query
• 減少 join 的機會，使用多個 select 造出 query

Helper （輔助方法）的存在目的是用來輔助整理 View 中內嵌的複雜 Ruby 程式碼。設計得當的 Helper 可以加速專案的開發，以及增進程式的可讀性。然而，設計不好的 Helper 卻可能造成嚴重的反效果。

以下列舉常見的幾種糟糕的 Helper 設計模式：

1. 矯往過正：用 Helper 作 partial 該做的事

開發者以為 partial 效率是低下的，刻意不使用 partial，而改用 Helper 完成所有的動作：將需要重複使用的 HTML 通通寫成了 Ruby code，串接成 HTML：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

def show_index_block(block_name, post, is_show_game)

  block_title = content_tag(:h3, block_name)
  section_header = content_tag(:div, block_title, :class => "section-header")

  game_name = is_show_game ? "【 #{post.games.first.name} 】" : ""
  title = content_tag(:h4, link_to("#{game_name} #{post.title}", post_path(post)))
  image = content_tag(:div, render_post_image(post), :class => "thumbnail")
  content = content_tag(:p, truncate( post.content, :length => 100))
  section_content = content_tag(:div, "#{title}#{image}#{content}", :class => "section-content")

  section_footer = content_tag(:div, link_to("閱讀全文", post_path(post)), :class => "section-footer")

  return content_tag(:div, "#{section_header}#{section_content}#{section_footer}" , :class => "article-teaser")
end

Helper 的作用只是協助整理 HTML 中的邏輯程式碼。若有大片 HTML 需要重複使用，應當需要利用 partial 機制進行 HTML 的重複利用。這樣的寫法，非但效率低下（可以用 HTML 產生，卻使用 Ruby 呼叫 Tag Helper，且製造大量 Ruby Object），且嚴重降低程式的可讀性，其他維護者將難以對這樣的 DOM 進行後續的維護翻修。

2. 容易混淆：在 Helper 裡面穿插 HTML tag

這也是另外一個矯枉過正的例子，不過方向剛好相反：「因為覺得使用 Ruby code 產生 HTML tag 可能浪費效能，而直接插入 HTML 在 Helper 裡面與 Ruby Code 混雜。」也造成了專案維護上的困難：因為 Ruby 中的字串是使用雙引號"，而 HTML 也是使用雙引號"，，所以就必須特別加入 \" 跳脫，否則就可能造成 syntax error。

錯誤

1
2
3
4

def post_tags_tag(post, opts = {})
  # ....
   raw tags.collect { |tag|  "<a href=\"#{posts_path(:tag => tag)}\" class=\"tag\">#{tag}</a>" }.join(", ")
end

大量的 " 混雜在程式碼裡面，嚴重造成程式的可閱讀性，而且發生 syntax error 時難以 debug。

錯誤

1
2
3
4

def post_tags_tag(post, opts = {})
  # ....
  raw tags.collect { |tag| "<a href='#{posts_path(:tag => tag)}' class='tag'>#{tag}</a>" }.join(", ")
end

即便換成 ' 單引號，狀況並沒有好上多少。

正確

1
2
3
4

def post_tags_tag(post, opts = {})
# ...
  raw tags.collect { |tag| link_to(tag,posts_path(:tag => tag)) }.join(", ")
end

正確的作法應該是妥善使用 Rails 內建的 Helper，使 Helper 裡面維持著都是 Ruby code 的狀態，並且具有高可讀性。

3. 強耦合：把 CSS 應該做的事綁在 Ruby Helper 上。

錯誤

1
2
3
4
5
6
7

def red_alert(message)
  return content_tag(:span,message, :style => "font-color: red;")
end

def green_notice(message)
  return content_tag(:span,message, :style => "font-color: green;")
end

開發者不熟悉 unobtrusive 的設計手法，直接就把 design 就綁上了 Ruby Helper。將來設計上若需要變更時，難以修改或擴充。

正確

1
2
3
4
5

def stickies(message, message_type)
  content_tag(:span,message, :class => message_type.to_sym)
end

<span class="alert"> Please Login!! </span>

樣式應該由 CSS 決定，使用 CSS class 控制，而非強行綁在 Helper 上。

4. 重複發明輪子

Rails 已內建許多實用 Helper，開發者卻以較糟的方式重造輪子。在此舉幾個比較經典的案例：

• cycle

如何設計 table 的雙色列效果？

劣

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<% count = 0 >
<table>
<% @items.each do |item| %>
  <% if count % 2 == 0 %>
    <% css_class = "even "%>
  <% else %>
    <% css_class = "odd" %>
  <% end %>
  <tr class="<%= css_class %>">
    <td>item</td>
  </tr>
  <% count += 1%>
<% end %>
</table>

一般的想法會是使用兩種不同 CSS class : even 與 odd，著上不同的顏色。

劣

1
2
3
4
5
6
7
8
9
10
11
12
13

<table>
<% @items.each_with_index do |item, count| %>
  <% if count % 2 == 0 %>
    <% css_class = "even "%>
  <% else %>
    <% css_class = "odd" %>
  <% end %>
  <tr class="<%= css_class %>">
    <td>item</td>
  </tr>
  <% count += 1%>
<% end %>
</table>

這是一般初心者會犯的錯誤。實際上 Ruby 的 Array 內建 each_with_index，不需另外宣告一個 count。

優

1
2
3
4
5
6
7

<table>
<% @items.each do |item| %>
  <tr class="<%= cycle("odd", "even") %>">
    <td>item</td>
  </tr>
<% end %>
</table>

但其實還有更簡便的方法：Rails 內建了 cycle 這個 Helper。所以只要這樣寫就好了…

常用你可能不知道的 Helper

限於篇幅，直接介紹幾個因為使用機率高，所以很容易被重造輪子的 Helper。開發者會寫出的相關 AntiPattern 部分就跳過了。

• truncate
• auto_link
• div_for & dom_id
• simple_format

#TODO: examples

5. Ask, Not Tell

這也是在 View 中會常出現的問題，直接違反了 Law of Demeter 原則，而造成了效能問題。十之八九某個 View 緩慢無比，最後抓出來背後幾乎都是這樣的原因。

不少開發者會設計出這樣的 helper：

劣

1
2
3
4

def post_tags_tag(post, opts = {})
  tags = post.tags
  tags.collect { |tag| link_to(tag,posts_path(:tag => tag)) }.join(", ")
end

1
2
3

<% @posts.each do |post| %>
  <%= post_tags_tag(post) %>
<% end %>

這種寫法會造成在 View 中，執行迴圈時，造成不必要的大量 query (n+1)，以及在 View 中製造不確定數量的大量物件。View 不僅效率低落也無法被 optimized。

優

1
2
3

def post_tags_tag(post, tags, opts = {})
  tags.collect { |tag| link_to(tag,posts_path(:tag => tag)) }.join(", ")
end

1
2
3

<% @posts.each do |post| %>
  <%= post_tags_tag(post, post.tags) %>
<% end %>

1
2
3

  def index
    @posts = Post.recent.includes(:tags)
  end

正確的方法是使用 Tell, dont ask 原則，主動告知會使用的物件，而非讓 Helper 去猜。並配合 ActiveRecord 的 includes 減少不必要的 query（ includes 可以製造 join query ，一次把需要的 posts 和 tags 撈出來）。

且在 controller query 有 object cache 效果，在 view 中則無。

小結

Helper 是 Rails Developer 時常在接觸的工具。但可惜的是，多數開發者卻無法將此利器使得稱手，反而造成了更多問題。在我所曾經參與的幾十個 Rails 專案中，很多設計和效能問題幾乎都是因為寫的不好的 View / Helper 中的 slow query 或伴隨產生的大量 object 所造成的 memory bloat 導致的。但參與專案的開發者並沒有那麼多的經驗，能夠抓出確切的病因，卻都將矛頭直接是 Rails 的效能問題，或者是沒打上 Cache 的關係。這樣的說法只是把問題掩蓋起來治標，而非治本。

下次若有遇到 performance issue，請先往 View 中瞧看看是不是裡面出現了問題。也許你很快就可以找到解答。

#TODO

Wrong

app/models/post.rb

1
2
3

def tag_list_for_welcome_page
   tags.maps {|tag| "<span> tag.name </span>" }.join(" / ")
end

Correct

app/helpers/post_helper.rb

1
2
3

def tag_list(tags)
  tags.map { |tag| content_tag(:span, tag.name ) }.join(" / ")
end

#TODO

Wrong

1
2
3
4
5
6

def checkout
  book = Book.find(params[:id])
  current_user.balance -= book.price
  curremt_user.save!
  redirect_to account_path
end

### Correct

1
2
3
4
5

def checkout
  book = Book.find(params[:id])
  current_user.purchase(book)
  redirect_to account_path
end

#TODO

Wrong

1
2
3

<% if current_user && current_user == post.user %>
  <%= link_to("Edit", edit_post_path(post))%>
<% end %>

Correct

1
2
3

<% if editable?(post) %>
  <%= link_to("Edit", edit_post_path(post))%>
<% end %>