隨便打開你 Rails 專案裡的 model 檔案，它可能會長得像這樣：

1
2
3
4

class Post < ActiveRecord::Base
  belongs_to :user
  belongs_to :category
end

第一行後面那個 ActiveRecord::Base 裡面的 2 個冒號 ::，各位知道是什麼意思嗎?

菜市場名

也許你也叫金城武(或自己覺得自己長得像金城武)，然後我也剛好也很巧叫金城武，這樣在大街上大叫一聲帥哥就一堆人回頭了，不太好。

寫程式偶爾也會遇到這樣的狀況，舉例來說，如果大家剛好都有一個叫做 Animal 的類別或是 Flyable 的模組，放在同一個專案裡就會打架了。所以 Ruby 有設計 namespace 來解決這個問題。

在 Ruby 裡，因為 module 或 class 可以有巢狀結構(類別裡可以包模組，模組裡面可以包類別，就是大腸包小腸的概念啦)，剛好可以拿來做 namespace 的包裝，例如：

1
2
3
4
5
6
7

module Utility
  module Flyable
    def fly
      # ....
    end
  end
end

這樣一來，如果要使用 Flyable 這個類別的話：

1
2
3

class Cat
  include Utility::Flyable
end

要 include 那個 Flyable 模組，就必須連名帶姓的 include，也就是「樹林::金城武」、「三重::劉德華」的概念。

除此之外，其實你也可把常數包在 namespace 裡：

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

module Utility
  TaxRate = 10
  module Flyable
    Speed = 20
    def fly
      # ....
    end
  end
end

puts Utility::TaxRate          # => 10
puts Utility::Flyable::Speed   # => 20

要使用這些常數，也是一樣要提供完整的路徑給才行。(如果你知道的話，其實不管是類別或模組，它們的名字基本上也就是常數而已)

所以，原來這段程式範例：

1
2
3
4

class Post < ActiveRecord::Base
  belongs_to :user
  belongs_to :category
end

它的意思就是說有一個叫做 Post 的類別，它是繼承自某個放在 ActiveRecord 的模組(或類別)裡的 Base 類別。如果去 github 上翻 Rails 的原始碼的話(連結)，應該可以看到這段：

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

module ActiveRecord
  # .....
  # 中略
  # .....
  class Base
    extend ActiveModel::Naming
    extend ActiveSupport::Benchmarkable
    extend ActiveSupport::DescendantsTracker

    extend ConnectionHandling
    extend QueryCache::ClassMethods
    # ... 略
  end
end

的確是有一個 ActiveRecord 的模組，裡面包了一個 Base 的類別沒錯 :)

在網路上常看到一些介紹 Ruby 裡類別(class)跟模組(module)的差別，有人說他們兩個差別很大，是完全不同的東西。事實上，類別跟模組是很像的。可能很多人不知道，類別跟模組是有血緣關係的，如果你試著這樣做：

1

puts Class.superclass

你會得到 Module 這個類別。也就是說，在 Ruby 裡，「類別」其實就是「模組」的後代，類別根本就是繼承自模組來的。即然是同一個體系，自然沒有太多的差異。

那差別是什麼?

最明顯的差別，當然就是一個是用 class 來定義，一個是用 module 來定義。至於前、後代功能上的差別，我們只要寫幾行簡單的程式就可以看得出來：

1
2
3
4
5

# 前、後代的類別方法差異：
p Class.methods - Module.methods

# 或直接這樣寫：
p Class.methods(false)

上面這段會得到 [] (空陣列)，表示他們在類別方法上並沒有差別。再來看看實體方法的差別：

1
2
3
4
5

# 前、後代的實體方法差異：
p Class.instance_methods - Module.instance_methods

# 或直接這樣寫：
p Class.instance_methods(false)

會得到以下結果：

1

[:allocate, :new, :superclass]

其中，allocate 跟 new 跟產生實體(instance)有關，superclass 跟繼承有關。

也就是說，類別比模組多了可以產生實體的能力以及繼承能力。

那用途上有什麼差別?

請大家先思考一個問題：「如果我有一個小貓類別，我希望這個小貓會飛，你會怎麼做?」

1. 直接寫一個有飛行功能的小鳥類別，然後再叫小貓類別去繼承它?
2. 直接把飛行功能寫在小貓類別裡?

第 1 種做法的設計有點怪怪的，好好的貓不當，為什麼要去當鳥? 為了想要有飛行功能就去當別人家的小孩…

第 2 種做法看來似乎可行，但如果之後又有個「我希望我的這個小狗類別也會飛!」的需求，那這樣又得在小狗類別裡寫一段飛行功能，程式碼沒辦法共同。

這時候，模組就可以派上用場了。

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

module Flyable
  def fly
    puts "I can fly!"
  end
end

class Cat
  include Flyable
end

kitty = Cat.new
kitty.fly        # => I can fly!

在上面這段範例中，我做了一個飛行模組(Flyable)，然後小貓類別不用特別寫什麼功能，就只要把這個飛行模組掛上去(include)就搞定了。

如果之後小狗類別也想要會飛的話，只要這樣：

1
2
3

class Dog
  include Flyable
end

小狗也會飛了。

要用繼承還是要用模組?

基本上，如果你發現你要做的這個功能，它可能在很多不同體系的類別裡都會用得到，那你可以考慮把功能包在模組裡，然後在必要的時候再 include 進來即可。

如果你還是不知道到底類別跟模組有什麼差別，我再舉二個例子。

不知道大家有沒看過火影忍者這部漫畫，漫畫裡的主人公之一，宇智波佐助，因為他們家族血統的關係，他寫輪眼這個功能是天生就有的，這個功能是從他的家族「繼承」來的。而佐助的老師，旗木卡卡西，他雖然也有寫輪眼功能，但他的寫輪眼並非繼承來的，事實上是他在年輕時候 include 了某個寫輪眼模組，所以才有這個效果。

另一個例子，海賊王漫畫裡，魯夫本來是普通人，但在偶然的機會下，他 include 了橡膠果實之後，他就有了橡膠人的能力了，並不是因為他老爸是橡膠人所以他才是橡膠人。

以上，希望能讓大家在使用類別跟模組時有更進一步的認識 :)

大家在寫 Rails 專案的時候，一定都有用過 link_to 這個 view helper。問大家一個簡單的問題：

1

link_to '刪除', user, method: :delete, data: { confirm: 'sure?' }, class:'btn'

請問，上面這段範例中，link_to 方法共有幾個參數?

如果你的答案是 5 個，那你就需要繼續往下看了 :)

在這篇文章中提到，Ruby 很愛省略東西，像是方法的小括號，所以原來上面的 link_to 語法：

1

link_to '刪除', user, method: :delete, data: { confirm: 'sure?' }, class:'btn'

原本應該長這樣：

1

link_to('刪除', user, method: :delete, data: { confirm: 'sure?' }, class:'btn')

最後一個參數如果是 Hash，大括號可省略

在 Ruby 省略小括號大家都知道，不過逗點分開的參數不是 5 個嗎?

事實上，在 Ruby 中如果最後一個參數是 Hash 的話，它的大括號是可以省略的。舉個例子來說：

1
2
3

def say_hello_to(name, options = {})
  # do something
end

如果要使用這個方法，可以這樣寫：

1

say_hello_to "eddie", {age: 18, favorite: 'ruby'}

又，因為最後一個參數是 Hash，所以 Hash 的大括號也可省略：

1

say_hello_to "eddie", age: 18, favorite: 'ruby'

如果你了解有什麼東西被省略的話，一開始的那段 link_to 的範例：

1

link_to '刪除', user, method: :delete, data: { confirm: 'sure?' }, class:'btn'

還原之後會變成：

1

link_to('刪除', user, {method: :delete, data: { confirm: 'sure?' }, class:'btn'})

所以，其實參數個數只有 3 個，最後一個參數是一個 Hash。

小結

Ruby 的語法可以適時的省略小括號、大括號或 return，程式碼寫起來的確會更像文章，對新手來說可能會容易混淆，不過看久了應該也會慢慢習慣了。

以上，希望對大家有幫助 :)

先說結論：

attr_accessor 會幫你在 Ruby 的類別裡產生一對 getter 以及 setter 方法。

不過我想這結論對新手來說有講跟沒講一樣，讓我們繼續往下看。

跟別的程式語言比起來，Ruby 可以省略很多東西，像是呼叫方法的時候可以不用小括號，回傳資料的時候有時候不用特別加 return。

我們先來看一段範例：

1
2
3
4
5
6
7

class Girl
  def initialize(age)
    @age = age
  end
end

mary = Girl.new(20)

這是一個簡單的 Ruby 類別，我用 Girl 類別建一個名為 mary 的實體(instance)，並且在初始化的時候就設定她的年紀為 20。Girl 類別裡有一個 @age 這個實體變數(instance variable)，也許你會猜說如果要知道 mary 的年紀的話，只要：

1

puts mary.age

就行了，但一執行就會發現錯誤訊息：

undefined method `age' for #<Girl:0x007f93a609fa10 @age=20> (NoMethodError)

怪了，我是想要存取 age 這個屬性，為什麼錯誤訊息卻是 undefined method?

在解釋之前，要先說明幾個 Ruby 這個程式語言跟別家程式語言在設計上的不同：

一、Ruby 的方法呼叫，常常會適時的省略小括號：

舉個例子來說：

1
2
3
4
5

def say_hi_to(name)
  puts "hi, #{name}"
end

say_hi_to("eddie")

但我們通常會寫成：

1

say_hi_to "eddie"

在呼叫方法的時候省略小括號，這在 Ruby 是很常見的寫法。

二、Ruby 並沒有「屬性」(property/attribute)這樣的東西：

雖然 mary 看起來有一個 @age 實體變數，但不表示是可以直接存取的屬性。硬是要用 mary.age 問她年紀，或是要用 mary.age = 18 來設定她的年紀，她都會賞你一巴掌，給你錯誤訊息的。

mary.age 你以為是讀取 mary 上的 age 屬性，但事實上是在執行 mary.age() 方法，只是小括號被省略了。mary.age=18 你以為是設定 mary 的 age 屬性，但事實上是執行 mary.age=(18) 方法，只是小括號被省略了。

在 Ruby 裡，很多東西都跟你看到的不太一樣，例如，你以為 1 + 2 是簡單的數學運算嗎? 其實它是 1.+(2)，它是對數字物件 1 送了一個 + 的訊息，並且把數字物件 2 當做參數傳給它。

好啦，即然知道它們都是方法，那要怎麼定義它們呢?

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

class Girl
  def initialize(age)
    @age = age
  end

  def age
    return @age  # 這個 return 通常會省略
  end

  def age=(new_age)
    @age = new_age
  end
end

上面這段範例中，第 6 ~ 8 行的方法會回傳 @age，又常稱之 getter；第 10 ~ 12 行的方法它會設定 @age 的值，故又常稱之 setter。

不過…等一下! 為什麼方法後面有個等號?

請把等號當做一般的字母看待。在 Ruby 定義方法的時候，等號跟其它字元一樣都可以是方法名字的一部份，只是這個特殊字元必須要放在方法名稱的結尾(其實包括問號跟驚嘆號也都一樣)。

這個方法就叫做 age=，要使用它就是用 age=(18)，沒錯，就是連等號一起呼叫它。所以，其實標準形態應該長這樣：

1

mary.age=(18)

又，因為前面提到，Ruby 可以省略小括號，所以可寫成：

1

mary.age=18

然後，Ruby 又有幫忙加了一些語法糖衣，讓你在中間加一些空白字元也是可以的：

1

mary.age = 18

最後就會讓你看起來像是在設定 age 屬性了。

這…會不會太麻煩了點?

照這樣說，如果每次想要用類似的屬性寫法，就必須要寫一對方法來回傳、設定，會不會有點太麻煩啊。

是的，就是要這麼麻煩。不過請放心，工程師都很懶的，所以有另外設計了幾個方法可以讓你快速的產生前面提到的 getter/setter。

如果你的 getter/setter 很單純，就只是有回傳、設定實體變數的話，那你可用 Ruby 內建的幾個方法：attr_reader、attr_writer 以及 attr_accessor：

1
2
3
4
5
6
7
8
9
10
11

class Girl
  attr_accessor :age
  def initialize(age)
    @age = age
  end
end

mary = Girl.new(20)
puts mary.age    #=> 20
mary.age = 18
puts mary.age    #=> 18

其中，attr_reader 只會幫你產生 getter，attr_writer 只會幫你產生 setter，而 attr_accessor 則會幫你產生 getter 及 setter。如果不相信，可以執行下面這行看一下：

1

p Girl.instance_methods(false)

應該會看到以下結果：

1

[:age, :age=]

的確是產生了兩個方法，分別是 age 以及 age=。

用了 attr_accessor 還能自己寫 getter 或 setter 嗎?

當然是可以的，例如：

1
2
3
4
5
6
7
8
9
10
11

class Girl
  attr_accessor :age

  def age=(new_age)
    @age = (new_age > 18) ? 18 : new_age  # 如果大於 18，就只設定 18..
  end
end

mary = Girl.new
mary.age = 30     # 即使設定為 30 歲...
puts mary.age     # 還是會永保 18 歲 :)

因為你重新定義了 age= 方法，在執行的時候 Ruby 會跳出來跟你碎碎唸說 warning: method redefined; discarding old age=，但程式還是可執行。

所以，如果你只是想要客制化自己的 getter 或 setter 的話，可將 attr_accessor 改為 attr_reader 或 attr_writer，就不會有這個警告訊息了。

以上，希望對大家有幫助 :)

大概兩年前舉辦了一次「徵求 Ruby/Rails 有心人」活動，感謝大家不嫌棄，不過因為人數太多，最後變成了社群活動了 XD

最近再度因為手邊的 iOS 案件在持續增加中(同時也有 Rails 的專案同時在進行)，與其要直接找現成的即戰力，不如趁這個機會自己從頭開始帶，雖然會比較辛苦、花時間，但一些開發的習慣可以從一開始就先養成好像也不錯，剛好順便練一下之前準備的 iOS/Swift 教材。

所以我又厚臉皮的想要來徵看看有沒有人願意來給我當學徒。

你可能會學到什麼

• iOS app 開發
• Objective-C / Swift
• Git
• 還有最重要的，可以一起組隊打 D3.. XD

權利義務

基本上不會有什麼特別的權利義務，也不會有什麼學費或薪水。 其實我個人的私心，是希望學成之後可以有能力幫我消化或維護我手邊的專案。這樣我這樣才有更多時間打 D3。或是最後就直接加入我們的團隊接手客戶的專案，當然，如果開始接手專案的話就是一份正式的工作了，自然就會開始有薪水了，至於待遇會不會超過 22K? 我想應該不會太難 :)

基本條件

• 男女不拘，但基於我已經有兩個小朋友了，所以還是男性佳。女性佳我回家就要跪主機板了 (男性需役畢或免役)
• 最好是從學校畢業畢業不久或是已工作一、二年。
• 對寫程式有熱忱，不需要非常熟悉某種程式語言，但至少需要知道這個世界上不是只有 IE 這種瀏覽器。
• 需要自備 Mac 電腦(iPhone 或 iPad 可能也會需要)。
• 最好人是在北部。

人數限制

最多三位，再多我可能就沒辦法顧到品質了。

地點

五倍紅寶石 (台北車站附近)

時間

預計從三月份開始，每週找兩個晚上或週末的時間來練功(暫定)。

我不敢說自己是什麼大咖，但至少教大家如何寫 iOS app 來混口飯吃沒太大問題。 如果您有興趣，也覺得自己不會來個兩次就不來的，請點選以下的連結，並請簡單的介紹一下你自己。(預計會在農曆年前回覆錄取人選)

報名連結：http://5xruby.kktix.cc/events/ios-apprentice

感謝大家，先預祝大家新年都很快樂!

工商服務

順便偷渡幫忙宣傳一下我們自己最近開的課程資訊：

• Ruby on Rails 從零開始

大家在學習 Ruby 或 Ruby on Rails(以下簡稱 Rails)的時候，難免會有一些看不懂或是有一些不知道怎麼來的神奇語法，希望可以藉由這一系列的短文幫大家更容易的了解到底 Ruby/Rails 是怎麼回事。

預計會有以下的文章(持續更新中)：

Ruby 相關：

1. attr_accessor 是幹嘛的?
2. 類別跟模組有什麼不一樣?
3. 有時候會看到有兩個冒號寫法(例如 ActiveRecord::Base)它是什麼意思?
4. 為什麼 Hash 好像有不同的寫法?
5. 有的變數變前面有一個冒號(例如 :name)，是什麼意思?
6. 有的變數前面有 @ 符號(例如 @users )，這是什麼意思?
7. 你知道 require 這個語法幫你做了什麼事嗎?
8. gem install 之後，那些 gem 安裝到哪裡去了?
9. 想要學 Ruby 該看哪些書?

Rails 相關

1. 為什麼 link_to 這個 view helper 的參數個數可長可短?
2. 在 Rails 專案中，有個檔案叫 schema.rb，它是做什麼的?
3. 有一個 Gemfile 了，為什麼還有個 Gemfile.lock? 這個檔案是幹嘛的?
4. 常有時候會需要在指令面前加上 bundle exec，這有加沒加有什麼分別?
5. 為什麼 2.days.ago 在內建的 irb 會找不到這個方法? 這不是 Ruby 語法嗎?
6. 常在終端機裡下 rake db:migrate 指令，這個 rake 是什麼，後面那個 db:migrate 又是怎麼回事?
7. Strong Parameters 是什麼用途?
8. 自己寫了一些的 view helper，有辦法也在 controller 裡使用嗎?
9. 常在 controller 裡使用 before_action，它是一個方法嗎? 跟一般我們用 def 定義的有何不同?
10. 在 application controller 裡看到的 protect_from_forgery 是什麼?
11. 為什麼 model class 看起來空空的，但怎麼有那麼多好用的方法?
12. 在 Gemfile 裡看到 gem 'sass-rails', '~> 4.0.3' 或是 gem 'uglifier', '>= 1.3.0' 這樣的寫法，那個 ~> 跟 >= 各是代表什麼意思?
13. 想要學 Rails 該看哪些書?

以上，有的是關於 Ruby 的，有的是關於 Rails 的(嚴格說來其實都是 Ruby 的問題) 如果想到還有其它的會再繼續補充，或是大家有什麼想要知道也可以直接來信討論或是在本篇底下留言 :)

之前在 Public, Protected and Private Method in Ruby 這篇文章提到，在 Ruby 裡使用 private 方法的時候，不能明確的指出 receiver，以下面這段範例來說：

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

class Dog
  def hello
    self.gossip
  end

  private
  def gossip
    puts "don't tell anyone!"
  end
end

snoopy = Dog.new
snoopy.hello        # => NoMethodError
snoopy.gossip       # => NoMethodError

在上面這段程式碼的第 13 行，因為它明確的指出 receiver (snoopy)，所以執行這行程式碼會出現會出現 NoMethodError 的錯誤；而在第 3 行，即使 receiver 是 self 也一樣是不行的。

這是在 Ruby 裡面 private 方法的設計。

不過，今天剛好有朋友拿了一段程式碼給我看，才發現原來上面這個規則原來也是有例外的，舉個例子來說：

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

class Dog
  attr_accessor :name
  private :name, :name=

  def hello
    self.gossip
  end

  def greeting1
    self.name
  end

  def greeting2
    self.name = "Snoopy"
  end

  private
  def gossip
    puts "don't tell anyone!"
  end
end

snoopy = Dog.new
snoopy.hello         # => NoMethodError
snoopy.gossip        # => NoMethodError
snoopy.greeting1     # => NoMethodError
snoopy.greeting2     # => It Works!

在上面這段範例中用 attr_accessor 做了一個 name 的 getter 跟 setter，並且把 getter/setter 設定成 private。在第 10 行的地方呼叫了 private 的 getter，並且明確的指出 receiver 是 self，照規則來說會出現錯誤不意外，但第 14 行用類似的方法呼叫了 private 的 setter 卻沒有出錯!

的確 private 方法不能指出明確的 receiver，但 setter 算是這個規則的例外。因為你不在前面加 self 的話，像這樣：

1
2
3

  def greeting
    name = "Snoopy"
  end

這樣這個 name 不就變成區域變數的賦值了嗎?

想想看，如果在這裡呼叫 setter 不加 self 的話，那 Ruby 要怎麼分辨到底你是要呼叫 setter 還是區域變數?

話說回來，通常我們也不會沒事把 getter/setter 設定成 private，因為即然都做了 getter/setter 就是要給別人用的不是嗎? :)

投影片連結：https://speakerdeck.com/eddie/happy-programming-ruby

這並不是什麼新的主題，也不是很艱深的內容，只是發現最近在接手一些別人寫的 Ruby on Rails (以下簡稱 Rails)專案時發現，似乎不少人並不清楚 Ruby 一些特有的寫法，把 Ruby/Rails 當做 PHP 在寫，所以就想來試著介紹這個主題給大家，讓大家可以多認識一些 Ruby。

曾經寫過 Rails 的朋友也許寫過以下的語法來取得兩天前的時間：

1

2.days.ago

很多人以為這是 Ruby 的語法，但如果你打開 irb 這樣寫卻會出現 undefined method 'days' for 2:Fixnum 的錯誤訊息，那是因為其實不管是 days 或是 ago 方法，都不是內建在 Fixnum 類別的方法，而是 Rails(更精準說的話應該是 ActiveSupport 這個 gem) 透過 Open Class 的手法在原本內建的 Fixnum 類別加上了這些便利的方法。

我想大家都不否認 Ruby 的確是被 Rails 給帶紅起來的，不過一位日本的 Ruby 大前輩前田修吾在他的一份簡報「Rails 症候群の研究」提到「Ruby が何かわかっていない」(中譯：不知道 Ruby 是什麼東西)，其實也是有點讓人擔心 XD。

Ruby 是什麼?

Ruby 是一種電腦程式語言，而 Rails 是一種使用 Ruby 建構出來的網站開發框架 (Web Framework)，但 Rails 不是一種電腦程式語言。(當然要說 Rails 這樣的 DSL 也是一種語言也是 ok 的)

Ruby 是一種物件導向的程式語言，在 Ruby 裡的所有東西都是物件(幾乎)，包括數字 5 也是，它是一個數字物件，所以我們在 Ruby 可以寫出像下面這樣的程式碼：

1
2
3

  5.times {
    puts "Hello, Ruby"
  }

聽說…

聽說 Ruby 很慢!

這個嘛，就要看跟誰比了，跟 C 語言比的話當然是一定慢的，但 Ruby 還沒有慢到不能用的地步(而且通常網站慢的地方都不是 Ruby 本身)。慢的地方如果真的很介意，也可改用其它方式來改善(例如改寫成 Extension)

曾經有朋友拿 Twitter 拋棄 Rails 而改用 Scala 為例說「你看看連 Twitter 都嫌 Rails 慢了!」，的確 Rails 並不是執行效率非常好的框架，但是回頭想想，貴單位的網站的用戶或流量做得到 Twitter 的 1% 嗎? 網站還沒做出來就先擔心撐不撐得住大流量可能也擔心得太早了一點 XD

PS:事實上現在 Twitter 的前端也還是用 Rails 在開發。

聽說寫 Ruby 要先買 Mac?

不知道從什麼時候開始開始流傳著「要寫 Ruby/Rails 要先買 Mac」這樣的都市傳說，特別是在 Ruby 相關的聚會活動或研討會，大家擺在桌上的幾乎是清一色的 Mac 筆電。其實開發 Ruby/Rails 專案真正合適的應該是 Linux/Ubuntu 的環境，畢竟最後的專案是佈署在這些平台上，而不是在你的 Mac 筆電裡。

那為什麼越來越多開發者都買了 Mac? 我想主要原因除了看起來比較潮之外，就是 Mac OS 本質上其實是 BSD 系統，它有內建的 terminal(或說是 shell) 可以用，對寫 Ruby/Rails 的開發者來說是很方便的。

Ruby 可以這樣寫

if modifier

以下是個很單純的 if 判斷：

1
2
3
4

age = 18
if age > 18
  puts "OK, I can see this movie"
end

在 Ruby 裡，像這樣單純的 if 判斷，我通常會把 if 放到後面，讓整個句字看起來更像一般的英文口語：

1
2

age = 18
puts "OK, I can see this movie" if age > 18

if..else.., case..when..

如果您曾經寫過其它程式語言，對以下的語法應該不陌生：

1
2
3
4
5
6
7
8
9
10
11

age = 16

if age >= 0 && age < 3 then
  puts "Baby"
elsif age >= 3 && age < 10 then
  puts "Kids"
elsif age >= 10 && age < 18 then
  puts "Teenager"
else
  puts "Oh Yeah!"
end

就是一連串的 if..else.. 啦，這樣的寫法沒有錯，也可以正常執行，但教課書通常會教說如果看到很多的 else if 的話，可考慮用 case..when 來處理：

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

age = 16

case
when age >= 0 && age < 3
  puts "Baby"
when age >= 3 && age < 10
  puts "Kids"
when age >= 10 && age < 18
  puts "Teenager"
else
  puts "Oh Yeah!"
end

但中間那段大於小於的比較，我會喜歡用 Ruby 裡內建的 Range 來比對，看起來會更容易懂：

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

age = 16

case age
when 0...3
  puts "Baby"
when 3...10
  puts "Kids"
when 10...18
  puts "Teenager"
else
  puts "Oh Yeah!"
end

multiple assignment

在 Ruby 可以一口氣指定好幾個變數的值：

1

x, y, z = 1, 2, 3

只要一行就可達到三行的效果。

在其它程式語言，如果想要交換 x 跟 y 兩個變數的值，通常會這樣做：

1
2
3
4
5
6
7

x = 1
y = 2

# 交換 x, y 的值
tmp = x
x = y
y = tmp

但在 Ruby 可以利用上面提到的變數多重指定的特性改寫成這樣：

1
2
3
4
5

x = 1
y = 2

# 交換 x, y 的值
x, y = y, x

相當簡單又容易懂。

unnecessary return

以下是我在之前某個 Rails 專案裡面看到的一段程式碼：

1
2
3
4
5
6
7

def is_even(n)
  if n % 2 == 0
    return true
  else
    return false
  end
end

這樣寫沒問題，只是一看就猜得出來可能是剛從別的程式語言轉過來沒多久。在 Ruby 裡的 return 並不是一定要寫的，所以上式再透過三元運算子的簡化可以變這樣：

1
2
3

def is_even(n)
  (n % 2 == 0) ? true : false
end

或可再精簡一些：

1
2
3

def is_even(n)
  n % 2 == 0
end

事實上，如果再熟悉 Ruby 一點的話就會發現其實數字類別本身就有帶一個判斷偶數或奇數的方法：

1
2

puts 2.even?  # => true
puts 4.odd?   # => false

Open Class

Ruby 的 Open Class 可以讓開發者任意的幫已存在的類別(甚至是內建類別)加功能，例如：

1
2
3
4
5
6
7

class String
  def say_hello
    "Hello, #{self}"
  end
end

puts "Ruby".say_hello   # => Hello, Ruby

事實上 Rails 也是大量的使用了這個手法來擴充 Ruby 的功能，像是 2.days.ago 就是個經典的例子(實作方式請見 ActiveSupport 的原始碼)

前面一開始也提到，在 Ruby 裡什麼東西都是物件，包括數字也是，所以其實連最簡單的 1 + 1，其實它是執行了 1 這個物件的 + 方法：

1

puts 1.+(1)

所以，透過 open class 的手法，甚至也可以去惡搞一下看起來最簡單的加法：

1
2
3
4
5
6
7
8

class Fixnum
  alias :ori_add :+
  def +(n)
    self.ori_add(n).ori_add(1)
  end
end

puts 1 + 1   # => 3

這樣一來就會在數學加法上偷偷的再加 1，像是 1 + 1 = 3, 2 + 2 = 5，以此類推。

不過，Open Class 好用歸好用，風險感覺不小，好像一個不小心就容易被自己或別人改到一些不該改的東西。所以後來 Ruby 有推出了一個叫做 Refinement 的概念：

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

module StringExtension
  refine String do
    def to_md5
      require "digest/md5"
      Digest::MD5.hexdigest(self)
    end
  end
end

using StringExtension

puts "Ruby".to_md5

Block

在 Ruby 裡，Block 可以用 do..end 的方式來寫，也可以用大括號來寫，雖然大部份候兩者是可以互相替換的，但有一些微妙的地方沒注意的話，可能會造成預期外的結果，詳情請見Do..End v.s Braces。

Private method

在 Ruby 裡只要沒有特別聲明，所有的類別方法都是 public 的。如果想要在 Ruby 裡定義 private method 可以這樣做：

1
2
3
4
5
6

class Animal
  private
  def secret_method
    # ...
  end
end

或是這樣也可以：

1
2
3
4
5
6
7

class Animal
  def secret_method
    # ...
  end

  private :secret_method
end

看到第二種 private 的寫法，你應該就會發現其實 public、protected 以及 private 在 Ruby 裡並不是關鍵字或保留字，它只是個方法而已。

在 private 方法的定義上，Ruby 跟其它程式語言的定義有些不太一樣。在 Ruby 的 private 方法，是只要沒有明確的指出 recevier 就可以使用，所以即使是子類別也可使用父類別的 private 方法：

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

class Animal
  private
  def secret_method
    puts "Don't tell anyone!"
  end
end

class Dog < Animal
  def hello
    secret_method
  end
end

Dog.new.hello  # => Don't tell anyone!

但其實 Ruby 的 private 方法也不是真的那麼 private：

1
2
3
4
5
6
7
8
9
10

class Animal
  def secret_method
    # ...
  end

  private :secret_method
end

a = Animal.new
a.send(:secret_method)

更多相關細節可參考 Public, Protected and Private Method in Ruby。

參考資料：Message Passing

Dynamic Method

假設我們有一段程式碼長得像這樣：

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

class ComputerStore
  def get_cpu_info(workstation_id)
    # ...
  end

  def get_cpu_price(workstation_id)
    # ...
  end

  def get_mouse_info(workstation_id)
    # ...
  end

  def get_mouse_price(workstation_id)
    # ...
  end

  def get_keyboard_info(workstation_id)
    # ...
  end

  def get_keyboard_price(workstation_id)
    # ...
  end
end

有個軟體開發的原則叫做 DRY (Don’t Repeat Yourself)，簡單的說就是不要一直寫重複的程式。在開發軟體的時候，如果可以把程式碼寫得 DRY 一點，日後在維護的時候也會輕鬆得多。

所以，如果上面這段程式碼假設每個 get_xxx_info 跟 get_xxx_price 的方法實作內容都差不多，以 DRY 原則來看的話，上面這個看起來感覺就相當的「潮」(WET)啊，潮到出水了 XD

在這個時候就可以利用動態定義方法來整理這些看起來很重複的程式碼。在 Ruby 要動態的定義方法，可以用 define_method：

1
2
3
4
5

define_method :hello do |param|
  puts "Hello, #{param}"
end

hello "Ruby"  # => Hello, Ruby

所以，原來上面那段看起來不太 DRY 的程式碼，可以整理成這樣：

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

class ComputerStore
  def self.set_component(component)
    define_method "get_#{component}_info" do |workstation_id|
      # ...
    end
    define_method "get_#{component}_price" do |workstation_id|
      # ...
    end
  end

  set_component :cpu
  set_component :mouse
  set_component :keyboard
end

還可以再簡化一些：

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

class ComputerStore
  def self.set_components(*components)
    components.each do |component|
      define_method "get_#{component}_info" do |workstation_id|
        # ...
      end
      define_method "get_#{component}_price" do |workstation_id|
        # ...
      end
    end
  end

  set_components :cpu, :mouse, :keyboard
end

這樣一來，以後如果要再加硬體，也只要在 set_components 後面加上去就行了，看起來應該比原來的好維護多了。

Method Missing

如果大家曾經使用過 Rails，也許多少有用過類似 Book.find_by_id 或 Book.find_by_name 的神奇語法。你可能很好奇，為什麼明明你沒有定義這些方法，也一樣可以正常執行不會出錯?

其實，Ruby 在尋找方法的時候，會先往該物件的所屬類別找，找不到會再往它的父類別找(其實真正尋找方法的細節更複雜一些 XD)，如果一直找不到，最後就會呼叫 method_missing 這個方法。

1
2
3
4
5
6

def method_missing(method_name, *args)
  puts "You just called a method #{method_name} with #{args}"
end

some_method_not_exist(1, 2, 3)
# => You just called a method some_method_not_exist with [1, 2, 3]

所以當你在適當的地方覆寫了 method_missing，就可以做出類似的效果：

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

class Book
  class << self
    def method_missing(method_name, *args)
      if method_name.to_s.start_with?("find_by")
        q = method_name.to_s.sub("find_by_", "")
        puts "find something by #{q}"
      else
        super
      end
    end
  end
end

Book.find_by_id    # => find something by id
Book.find_by_name  # => find something by name
Book.wtf           # => ERROR!

看到了嗎? 即使原先沒有定義 Book.find_by_id 或 Book.find_by_name，在執行時候因為 find_by 開頭的方法被我自己寫的 method_missing 給攔了下來而不會出錯，但其它以外的方法則會呼叫內建的 method_missing 而噴出錯誤訊息。

有趣(或奇怪)的 Ruby 語法

寫程式有時候是件很悶的工作，偶爾寫點有趣的程式碼娛樂別人或自己也不錯。像是下面這個在 Trick 2013比賽中是「Most readable」的程式碼：

1
2
3
4
5
6
7
8
9
10

begin with an easy program.
you should be able to write
a program unless for you,
program in ruby language is
too difficult. At the end
of your journey towards the
ultimate program; you must
be a part of a programming
language. You will end if
you != program

寫得感覺像是一篇文章(其實內文無意義)，但其它是一段可以正常執行不會發生錯誤的 Ruby 程式碼。下面這個則是「Best way to return true」：

1

$ruby.is_a?(Object){|oriented| language}

因為在 Ruby 的 global variable 預設值是 nil，又，在 Ruby 什麼東西都是物件，包括 nil 也是，所以 $ruby.is_a?(Object) 會回傳 true。至於後面傳入的 Block 因為不會被呼叫，所以傳什麼進去都無所謂了。

阿宅寫程式也可以很浪漫的：

1

It can be wonderful if "the world".end_with? "you"

或是：

1

I will love you until "the end of the world"

這其實只是透過邏輯短路(Short-circuit)玩的把戲，因為後面的 if 或 until 在經過評估之後都不會成立，所以前面的語法就算有錯也不會被執行到。

另外，其實 Ruby 的類別名稱也就只是個常數而已，所以這樣惡搞你的同事也是 ok 的…

1
2
3
4
5

class BookList < (rand > 0.1) ? Array : Hash
end

b = BookList.new
b << "Ruby"   # => 將有 10% 的機會發生錯誤

因為 Ruby 的方法名字不一定只能用英文字母，所以可以寫出像這樣的程式碼：
看著看著就覺得餓了…

然後如果你知道 attr_accessor 其實也只是個會幫你產生一對 getter/setter 的類別方法的話，對產生的 getter/setter 不滿意或是想要再做些別的事話，也可以自己定義：
這樣你就寫出了一個「可以永保青春的”方法”」了 XD

小結

看到這裡，你可能會覺得在 Ruby 變數不用宣告就可直接用，內建類別可以透過 Open Class 方式來惡搞，private 方法又一點都不 private，整個只像是僅供參考，這樣不會很恐怖嗎?

我想，開發者大多知道自己在做什麼。當初 Ruby 在設計的時候是採取相信開發者的立場，給開發者很大的彈性與自由，這其實也是我最後選擇 Ruby 的原因。

Ruby/Rails 被很多人認為是很魔術的程式語言或工具，但只要瞭解它是怎麼運作的，其實也沒真的非常神奇。技術不用學多，一、二門專精的練起來就已可不愁吃穿了。

最後， 引用一段最近在朋友的 Facebook 上看到的一段話：

“Difference between a master and a beginner? The master has failed more times than the beginner has even tried.”
“大師與新手之間的差別，就是大師失敗過的次數，比新手嘗試過的次數還多”

共勉之 :)

記得在去年年初的時候，因為自己想找幾個一起打拼的伙伴而發起了一個「有心人」的活動，感謝大家的捧場以及社群朋友們的支持，活動順利結束。

然後，一直掛在嘴邊說要辦的「第二梯次」，總因為手邊的雜務而擱置。雖然後來斷斷續續的也有在中研院的自由軟體工作坊開一些 Ruby 的入門課或是在社群活動的分享，但就似乎變成有空才能開。

現在，我們成立了一家叫做五倍紅寶石的公司，在更多朋友的幫忙下，我們有更多的時間及資源可以來做推廣 Ruby 這件事了，畢竟推廣 Ruby 本來也是當初成立這家公司的最主要目的。

所以，在與夥伴們討論後，我們決定要來持續的無料推廣 Ruby，每個月固定至少會有個一天是 Ruby 推廣課程，希望可以讓更多人可以認識這個有趣可愛的程式語言。

詳情請見：http://5xruby.tw/courses/lets-learn-ruby-1

• 上課地點：台北車站附近
• 費用：0 元，惟上課學員需自備筆電，作業系統不限。

歡迎大家都可以開開心心的來認識、學習這個有趣的程式語言 :)

因為我已習慣用終端機 + Vim 工作，所以用 Vim 來練習寫 Swift 也是很正常的(誤)。不過其實真正的原因是之前 beta 版的 Xcode 太容易因為語法錯誤而當掉了。

Vim plugin

Vim 什麼沒有，plugin 最多了。不過因為 Swift 剛出來沒多久，外掛還不太多。我目前只有使用 vim-swift 這個 plugin，有支援語法 highlight。

Swift REPL

寫 Ruby/Rails 時已很習慣有 irb 之類的 REPL(Read–Eval–Print Loop) 可以用，Swift 這回也有提供 REPL。

因為在我電腦裡同時有安裝 Xcode 5 以及 Xcode 6 beta 5，所以在使用前得需先修改一下設定，開啟終端機後輸入：

$ sudo xcode-select -switch /Applications/Xcode6-Beta5.app

上面這個指令路徑設定可能會隨著 Xcode 6 的版本不同而需要做些調整。設定完之後，輸入：

$ xcrun swift

或

$ lldb --repl

即可進入 Swift 的 REPL 環境。

編譯

如果只是要寫個沒有畫面的小工具的程式，其實是不需要開 Xcode 的，只要一個簡單的 .swift 檔就可以了。

// 檔案 hello.swift
println("Hello, Swift!")

然後執行：

$ xcrun swift hello.swift

應該會在畫面上印出 Hello, Swift! 字樣。如果想要進行編譯，可執行：

$ xcrun swiftc hello.swift

這會在該目錄產生一個同名的 hello 執行檔(注意，是 swiftc 而不是 swift)。

註：以上是以 Xcode 6 Beta 5 為示範，在之前的版本的指令稍有不同。

自動執行

如果每次寫完存檔就要再執行一次 xcrun swift 也太辛苦了，工程師都是很懶的。有個不錯用的 gem 叫做 Guard可以幫你監視檔案的狀態，一但檔案有異動就跟著執行某些指令。

安裝 gem 是件輕鬆愉快的事，只要一行：

$ gem install guard-shell

如果安裝順利，下一步是請 guard 幫我們產生一個 Guardfile：

$ guard init shell

你應該可以在該目錄看到 Guardfile 檔案。我稍微做了些小修改如下：

1
2
3
4
5
6

guard :shell do
  watch(/(.*).swift/) do |m|
    puts "-" * 20
    puts `xcrun swift #{m[0]}`
  end
end

這個設定檔沒有很特別的東西，大概就是每次執行前先印出個分隔線，然後再印出 xcrun swift 的執行結果。接著只要在該目錄執行 guard 即可進入監看模式。

小結

因為 Vim 指法已習慣成肌肉記憶(muscle memory)，所以我的 Xcode 也通常會安裝 XVim 讓 Xcode 可支援部份的 Vim 指令，不然完全沒辦法工作了。

是說像這樣用 Vim 寫 Swift，練練語法還 ok，但要靠 Vim 純手工刻出 iOS app 真的不是一般人能做到的事，所以其實我真正開發的時候，還是需要依賴 IDE 幫忙的，不然 method name 那麼長、參數那麼多，不靠 IDE 的自動完成，怎麼可能記得住。

即使如此，我個人還是覺得，可以用 Vim 寫程式，就是莫名的有種阿宅的浪漫啊 :)

這回，您不需要自己斷開鎖鏈或斷開魂結，也不用燒毀什麼東西了 :)

「五倍紅寶石」是我與幾位台灣 Ruby 社群的朋友共同成立的一家公司，希望可以透過藉由教育訓練、企業培訓等課程，將 Ruby 推廣給更多的企業、開發者。

網站：http://5xruby.tw

緣起

我們是一群在台灣的 Ruby 程式語言的愛好者，每天的工作都是跟 Ruby / Rails 相關。

近一、二年來，Ruby / Rails 的人才需求增加，年薪超過百萬的高薪職缺紛紛出現，吸引越來越多人想要進入 Ruby / Rails 的領域。除自行學習以外，也很積極參加社群舉辦的聚會與分享、交流。

我們這幾年來持續的在台灣大專院校（成大、輔大、台北商專..等校) 開授 Ruby 以及 Rails 課程，觀察學生們的學習狀況，大多覺得 Ruby / Rails 其實並不難學，自己看書或是照著官網文件練習就能練到一定的程度。但要進階至可滿足實戰需求，不容易藉由自學可以短期達成，而是需要更多的實戰經驗，或是導師的帶領。也因此，在台灣，較資深或有經驗的 Ruby / Rails 開發者相當難找。

我們也走訪了一些企業的 IT 部門，請教他們為什麼不採用 Ruby / Rails 的原因，大多也是因為資深的 Ruby / Rails 的工程師難找，或是背後沒有商業公司的技術支援，遇到問題的時候不知道該找誰求救。

於是，我們這幾位愛好 Ruby 的朋友便開始討論「也許我們應該來成立一間專門提供 Ruby/Rails 相關的技術諮詢或是教育訓練的公司」。

我們最終的目的，是希望在台灣可以有越來越多的企業能了解或採用 Ruby 這個優雅、有趣，並且極具生產力的程式語言做為主要開發工具，更快速的實現您的想法。

感謝多位業界前輩、先進的支持與鼓勵：

Programmer 最有價值的是經驗值，「五倍紅寶石」的導師都是社群內數一數二的資深 Rubyist，由他們來帶領學員一探 Ruby 世界的神奇之處，實在是最佳選擇。

Eddie and his team are of the most dedicated Ruby evangelists I have ever come across. With their passion and professionalism, Ruby learners will leapfrog in their progress.

還在尋找專業的 Ruby/Rails 師資嗎？別懷疑了，台灣最頂尖的 Rubyist 盡在「五倍紅寶石」！

慕凡和龍哥是業界數一數二的 Ruby 大師，他們不光是底子深厚，也很懂得引導、訓練學習路上遇到挫折的 Ruby/Rails 學子。很慶幸有他們的協助讓我進入紅寶石的美妙世界。

選擇程式語言很重要，但選擇優秀的導師更重要！能跟擁有多年 Ruby/Rails 實戰經驗、活躍於社群的頂尖 Rubyist 學習，將一窺程式開發殿堂之藝術！我堅信：專業事讓專業的來，而專業的「五倍紅寶石」是寶藏，就等大家來挖掘。

「五倍紅寶石」的導師們都是業界經驗豐富的實戰高手，提供的課程及咨詢絕對能讓你大幅省去自行摸索的時間。

曾有幸與徐曦與見龍一起工作，徐曦自我要求與向上進取的態度令人稱佩，見龍對危機處理與當責的責任感也值得稱許。「五倍紅寶石」的其他夥伴也是一時之選，相信這是一個很棒的組合。

公司名字的由來

為什麼公司會取這個看起來有點好笑的名字? 話說某天下午，我們幾個人在討論公司要取什麼名字…

「紅寶石股份有限公司? 聽起來好普通，而且會不會大家以為我們是珠寶商啊」。

就在大家一直想不到個有代表性又好記的名字的時候，突然來了一個「五倍紅寶石」，大家都笑了，但就在一陣狂笑之中，大家一致鼓掌通過決定要用這個聽起來有點 kuso 的名字了 XD

怎麼決定負責人是誰的?

即然是一家 Ruby 公司，Ruby 公司的事當然就是要交給 Ruby 解決。所以我們打開了 irb，輸入一段簡單的程式碼：

1

['A', 'B', 'C', 'D'].sample

嗯，我們的負責人這樣選出來了 XD

說明會

如果您對我們的課程有興趣，或是不知道「五倍紅寶石」到底是在賣什麼藥，歡迎您 6/5（星期四）晚上 19:30 前來參加我們舉辦的說明會，我們在現場將準備一些簡單的點心及飲料。

當然，只是要來閒聊或是找好陣子不見的朋友聚一聚也很歡迎。

• 時間：2014/6/5 星期四 19:30
• 地點：TED x Taipei Space
• 地址：台北市金山南路一段 9 號 4 樓

請按這裡前往報名網站

This is my lightning talk slide on RubyConf Taiwan 2014:
http://www.slideshare.net/aquarianboy/rails-girls-in-taipei

Hi, I’m Eddie, one of the organizers of Rails Girls Taipei. Last year, I went to RubyKaigi in Japan, and visited the Rails Girls event in Ruby Hiroba(広場). I found that the attendees were divided into “beginner” level and the other level which might be a little familiar with programming, and every coach take care 2 or 3 attendees, so they can coaching them one by one.

We thought it might be interesting if we can also have this event in Taiwan. So, Taian, Ryudo, and me, we three decided to host a Rails Girls event in Taiwan, just give it a try.

Our first event is on last September. We recruited about 10 to 15 coaches and discuss the detail, but we totally have no experience about this event.

We thought there won’t be any girl willing to join this kind of nerdy event. But surprisingly, there’re more than 300 girls signed up just in one day.

We eventually didn’t pick neither CS students or web developers, instead, we prefer those who are totally new to programming, we wanna see what will happen if we try to bring Ruby and Rails to them.

Looks like they all have a good time :)

And our second event is on last November. Still, more than 300 girls signed up again, and this time we recruited about 25 coaches and 75 attendees. You might have also noticed that, several coaches are also the speakers in conference this year.

you can visit here to see more photos. It’s awesome for me to see them open a terminal window and run some commands on they computer, it’s really cool.

Last month, we had the third event. Until now, we have more than 150 rails girls already.

Durning RubyConf Taiwan 2014, there are about 20 female volunteers in check-in counter or at the booths are from Rails Girls, they did help a lot in this conference.

Of course, you know, it’s not quite possible to learn Ruby on Rails just in a 2-day workshop, so some girls asked:”is there any other course to learn more?” Well, then we decided to have a weekly event for them, named “Let’s Try Rails Tuesday”, a.k.a “LTRT”. Which is mainly hosted by manic, also the speaker in this conference.

Currently, we’ve already had 16 LTRT events, and about 20 attendees per week, even in the rainy days.

Beside that, we also tried to do some promotions in high school or university, hope more people can understand what we were doing :)

Anyway, I have to thank all our coaches, it won’t work without your help.

We will have more Rails Girls event in the future if possible, so we’ll need more coaches, please let me know if you’re interested in being a coach.

Of course, we need more sponsorship :)

At last, this is our fan page on Facebook, feel free to join us for more information. Please don’t be hesitate to contact me if you have any question, any comment will be appreciated.

台北的 Ruby 社群跟相關活動其實不算少，除了一些個人或學校社團的活動外，人數較多的活動有例如每一、二個月舉辦一次的 Ruby Tuesday，會邀請特定的來賓來分享他們在工作上或個人研究上的專業主題；有年度大型活動 RubyConf Taiwan，會邀請國內外對 Ruby/Rails 有研究的高手來分享他們的心得，甚至連 Ruby 的老爸 Matz 也會來。除此之外，還有女性朋友專屬的 Rails Girls 以及每週進行的 Rails Girls 活動 (每週約二十人左右參加)。

又一個 Ruby 聚會?

不過，上述這些活動不是主題不適合新手，或是主題不容易引起共鳴，不然就是有性別限制，像我這種好像會寫一點點程式的高級新手想要找到同好一起學習反而變得不太容易。

目的/方向

所以，為了能讓更多對 Ruby/Rails 有興趣的朋友可以有個可以固定而且定期的交流管道，幾位 Ruby 圈的朋友(我、慕凡、Manic 以及 大兜)就打算來籌備這樣的一個活動。我們想了好幾個名字，最後大家鼓掌通過的名字是「Taipei.rb」

活動的方向很簡單，就是「讀書」 + 「閒聊」。

不像 Ruby Tuesday 之類的主題式分享，Taipei.rb 初期設定的方向是「讀書會」，會先挑幾本書來跟大家一起讀、一起討論，每次活動開始會有一到二位與會者上台進行導讀，並從參與者中挑選下回活動上台的人。

新手/老鳥不拘，願意讀書就行，來找人閒聊或是來求職、求才也都歡迎。當然，性別不拘 :)

目前暫定書目：

Ruby 相關

• Eloquent Ruby
• Metaprogramming Ruby

Rails 相關：

• Rails 4 Way
• Rails Tutorial

週期

預計每二星期舉辦一次。

費用

每人僅需負擔場地費用(約 NT 200 元)即可，不另外收取費用。

第 0 次兼說明會

如果各位看完還是不知道這個活動要幹嘛，我們在星期二(3/4)晚上七點，在 DeRoot 有個說明會兼第 0 次的導讀示範，有興趣的朋友請按這裡報名。

2013 年幹了哪些事

• 今年有 22 場公開的活動，雖然有點累，但很有趣!
• 第一屆的 WebConf Taiwan 真的非常感謝大家的支持、捧場，活動算是圓滿結束。
• 今年第一次厚臉皮的辦了 Ruby/Rails 有心人活動，感謝大家的支持。
• 今年在日本舉辦的 RubyKaigi 剛好有榮幸投稿上了，所以同時解除了第一次在國外發表演說以及第一次用全英文演講 25 分鐘的成就，也在日本見識到了什麼才叫認真的技術魔人。
• 在台北舉辦了兩次的 Rails Girls 活動，出乎意外的受歡迎。
• 十月份帶了一家四口前往日本遊山玩水一個多星期，勉強算是有個交待了。

希望可以更熟悉的技能

資訊這一行，要學習的東西、想要做的事情太多，但人生有限，所以 2014 年只會把時間集中放在這些地方了：

• iOS app / Cocoa Framework：這是目前幾乎 80% 的工作時間都在這上面了，不再精進一些怎麼行。
• Ruby / Rails：很有趣的而且具生產力的程式語言/網頁框架，但常看到其它高手的寫法就會覺得自己還差得遠。
• Golang：身邊的朋友不少都投入這個新語言，在效能上有很優異的表現，是時候該學習它了 :)

許願

• 希望小朋友們可以平安長大，2014 年也可以再帶他們一起來去旅行。
• 希望 WebConf Taiwan 2014 可以順利進行。
• 希望 Rails Girls 活動可以繼續辦下去。
• 希望「有心人」課程可以繼續辦下去。
• 希望繼續推廣 Ruby 給更多的朋友知道。
• 希望手上正在做的產品可以順利完成。
• 希望公司生意… 順利就好。

許了一堆願望，2014 年也要繼續努力!

1
2
3
4
5
6
7
8

// 檔案：NSObject.h
@interface NSObject <NSObject> {
    Class isa  OBJC_ISA_AVAILABILITY;
}

- (id)init;
+ (id)new;
+ (id)alloc;

會發現 alloc 跟 init 的回傳型態都是 id。而在上一篇提到，在 Objective-C 裡 id 是一個可以指向任何物件的指針，所以如果這樣寫的話：

1

NSArray* myArray = [[NSArray alloc] init];

看起好像沒什麼問題，執行起來也正常，但這裡就有個小小的疑惑了.. 即然 alloc 跟 init 都是回傳 id 型別，Objective-C 是個動態語言，很多資訊是在執行階段(runtime)才會取得，那編譯器(compiler)又是怎麼知道它應該要是個 NSArray?

根據 Clang 的文件說明，原來當我們寫 [NSArray alloc] 的時候，訊息接受者(receiver，也就是 NSArray)收到訊息(message，也就是 alloc)，它並不是真的就乖乖的就只傳回 id 型別，而是回傳 receiver 的型別(a.k.a related result type)，在這個例子就是 NSArray。同理 init 也是一樣，所以 [[NSArray alloc] init] 也會偷偷的回傳 NSArray 型別。在 Objective-C 裡，alloc、new、init 等方法都享有這個特別的服務。

但如果不是這些享有特別服務的方法呢? 例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@interface Animal : NSObject
+ (id) createAnimal;
@end

@implementation Animal
+ (id) createAnimal
{
    return [[self alloc] init];
}
@end

@interface Fox : Animal
- (void) say;
@end

@implementation Fox
- (void) say
{
    NSLog(@"what does the fox say!?");
}
@end

這裡我們建立了兩個類別，一個 Animal 一個 Fox，Fox 繼承自 Animal，並且在 Animal 定義了一個類別方法 createAnimal。看起來很正常，但如果接下來不小心這樣寫的話：

1

[[Animal createAnimal] say];

上面這行在編譯階段沒問題，但執行之後就會 crash 了。我們一般不會這樣寫，因為我們光用肉眼就能發現問題在哪裡，父類別 Animal 根本沒有定義或實作 say 方法所以理所當然的會 crash。但為什麼這麼明顯的錯誤在 Xcode 裡沒被挑出來? 因為 +createAnimal 這個方法回傳的是 id，編譯器沒辦法在編譯階段從 id 推敲出它真正的型別，所以只好先放它過關，然後在執行階段就 crash 了。(關於為什麼是在執行階段才知道型別，可參考這一篇的介紹)

你當然也可以在執行階段再用 respondsToSelector: 之類的方法來檢查，但事實上這個工作可以交給編譯器來做，只要把 id 換成 instancetype，像這樣：

1
2
3
4
5
6
7
8
9
10

@interface Animal : NSObject
+ (instancetype) createAnimal;
@end

@implementation Animal
+ (instancetype) createAnimal
{
    return [[self alloc] init];
}
@end

這樣編譯器就會在原本會 crash 的那行跳出一個紅色的警告：

寫著：

No visible @interface for 'Animal' declares the selector 'say'

在編譯過程就會幫你把這個問題抓出來了。使用 instancetype 的另一個好處，就是在子類別也可以正確的知道子類別的型別，例如你不小心這樣寫：

1

[[Fox createAnimal] addObject:@"hello, fox!"];

如果這邊回傳的是 id 的話，上面這行在編譯階段也不會有錯，但執行就 crash 了(除非你剛好有幫 Fox 類別實作了 addObject: 方法)。如果改用 instancetype 的話，編譯器就會把問題在編譯階段就抓出來了。

什麼是 instancetype?

引用 Clang 文件的一段話：

“instancetype is a contextual keyword that is only permitted in the result type of an Objective-C method”

其實 instancetype 就只是個關鍵字(keyword)，它告訴編譯器回傳型態，讓編譯器可以在編譯階段就有足夠的資訊可以來判斷你寫的程式碼是不是有問題。

用 instancetype 取代 id?

在 WWDC 2013 的影片(404 - Advances in Objective-C)提到在新版的 SDK 加入了 instancetype 這個型別。其實 instancetype 並不是很新的東西，不過 Apple 在最近推出的 SDK 開始把 id 改換成 instancetype，例如我們隨便打開一個內建的類別的 header，例如 NSArray.h 來看看：

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

// 檔案：NSArry.h
+ (instancetype)array;
+ (instancetype)arrayWithObject:(id)anObject;
+ (instancetype)arrayWithObjects:(const id [])objects count:(NSUInteger)cnt;
+ (instancetype)arrayWithObjects:(id)firstObj, ... NS_REQUIRES_NIL_TERMINATION;
+ (instancetype)arrayWithArray:(NSArray *)array;

- (instancetype)init;/* designated initializer */
- (instancetype)initWithObjects:(const id [])objects count:(NSUInteger)cnt;/* designated initializeralizer */

- (instancetype)initWithObjects:(id)firstObj, ... NS_REQUIRES_NIL_TERMINATION;
- (instancetype)initWithArray:(NSArray *)array;
- (instancetype)initWithArray:(NSArray *)array copyItems:(BOOL)flag;

NSArray 的 initializer 以及一些 class method 的回傳型態都也都是改用 instancetype 了。

所以意思是要用 instancetype 來取得 id 的意思嗎? 其實不是的。

Clang 的文件提到 instancetype 是 “only permitted in the result type of an Objective-C method”， 也就是說，instancetype 只能作為回傳值，不能作為參數，像這樣：

1
2

- (void) clickAction:(id) sender;            // 這樣寫沒問題
- (void) clickAction:(instancetype) sender;  // 但這樣寫是不行的

簡單的說，instancetype 主要的目的是為了幫助編譯器更了解你的程式碼，提早在編譯階段就發現問題。

至於之前已經寫好的程式碼需要整個用 instancetype 再重新改寫嗎? 其實也沒必要，不改也不會怎麼樣，因為編譯器本來就會幫 alloc、new、init 之類的方法傳回適當的型別，不過如果是新的專案，倒是建議可以試著在適當的地方開始使用 instancetype。

話說，研究這種有點冷門的東西對 iOS app 的開發雖然不會有直接明顯的幫助，但對整個 Objective-C / Cocoa Framework 可以有更進一步的認識，可以更知道我寫的程式碼到底實際上是怎麼運作的，我個人覺得這樣挺有趣的。

什麼是 id?

在 Objective-C 裡，變數宣告通常得告知編譯器這個變數的型別，例如這樣：

1

NSArray* myArray = @[@"eddie", @"kao"];

而在 Objective-C 裡有個特別的型別叫做 id，它可以指向任何物件，像這樣：

1

id myObject = @[@"eddie", @"kao"];

那這個 id 是什麼? 我們直接來從原始程式碼來找這個 id 的定義。大家可以打開 XCode，然後選擇「File」→「Open Quickly..」，應該可以找到 objc.h 這個檔案，往下捲一點，應該可以找到像下面的這幾行程式碼：

1
2
3

/// 檔案名稱：objc.h
/// A pointer to an instance of a class.
typedef struct objc_object *id;

就照上面這段註解說的，所謂的 id 就是一個「指向一個實例 (instance) 的指針」，而且 id 這個 Struct 的定義本身就有帶一個 *，這也是為什麼你在宣告其它一般物件型別的變數需要加註一個 * 來表示這是一個指標變數，而使用 id 卻不需要的原因。

什麼是一個物件 (Object)?

讓我們再從剛剛那個檔案，順蔓摸瓜的繼續看下去..

1
2
3
4
5

/// 檔案名稱：objc.h
/// Represents an instance of a class.
struct objc_object {
    Class isa;
};

從這段程式碼可以知道，其實所謂的「物件」，說穿了就只是一個 C 的結構 (C Struct)，而在這個 Struct 裡面只有一個 isa 的指針，指向自己所屬的類別。

再來我們來看看在 Objective-C 裡，到底什麼是一個類別(Class)

什麼是類別 (Class)?

繼續來看剛剛的那個檔案：

1
2
3

/// 檔案：objc.h
/// An opaque type that represents an Objective-C class.
typedef struct objc_class *Class;

看得出來其實 Class 本身也是一個 C Struct，再往下看一下這個 objc_class 的定義 (runtime.h)：

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

/// 檔案：runtime.h
struct objc_class {
    Class isa;

#if !__OBJC2__
    Class super_class;
    const char *name;
    long version;
    long info;
    long instance_size;
    struct objc_ivar_list *ivars;
    struct objc_method_list **methodLists;
    struct objc_cache *cache;
    struct objc_protocol_list *protocols;
#endif
};

從上面這段程式碼可以看到，所謂的類別也是一個 C Struct，裡面第一個指針 isa 指向它的所屬類別，第二個指針 super_class 則是指向它的父類別。除此之外還有一些其它的指針，指向例如 instance variables、method list、cache、protocol 等 Struct。

訊息傳遞 (Message Passing)

大家在其它 Objective-C 的書上應該常看到，在 Objective-C 的世界裡，方法不像其它程式語言一樣的被直接呼叫，而是透過「訊息傳遞(Message Passing)」方式，像是這樣：

1

[someObject saySomething:@"hello"]

這裡的 someObject 稱作 receiver，就是接收「訊息」的傢伙，而 saySomething: 就是「訊息」，@"hello" 則是參數。

事實上，在訊息傳遞的過程，當 someObject 這傢伙收到訊息之後，會順著這個物件的 isa 指針找到自己的類別，然後再依照收到的「訊息」去類別的 method list 找出對應的方法。如果在這個類別裡面找到了，就會直接執行它，如果找不到，會再往上一層父類別(super class)找。以上這個流程都是在程式執行過程中(Rumtime)才動態決定的，而不是在編譯(Compile)時期就決定好的。

而這個訊息傳遞的過程畢竟是多做了幾件事，相對感覺會比較耗時，但實際上在程式的執行過程中，一但執行過的方法就會被暫存(cache)下來，下次再收到一樣的訊息的時候就會快得多了。

其實，在 Objective-C 的世界裡，類別本身也是物件，所以你也可以對它「發送訊息」，像是這樣：

1

[NSArray arrayWithObjects:@"eddie", @"kao", nil];

看起來就跟在其它程式語言的「類別方法」差不多，但事實上它就是對 NSArray 這個類別發送了 arrayWithObjects: 這個訊息。

接下來我們直接寫一小段程式會比較容易想像：

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

// Animal Class
@interface Animal : NSObject
@end

@implementation Animal
@end

// Fox Class
@interface Fox : Animal
- (void) say;
@end

@implementation Fox
- (void) say
{
    NSLog(@"What does the fox say!?");
}
@end

上面這段程式碼建立了兩個類別，分別是 Animal 及 Fox ，而且 Fox 繼承自 Animal，而 Animal 類別則是繼承自 NSObject 類別。

不管是「物件」或是「類別」，因為一樣都是物件，所以他們在收到訊息時的反應流程也是一樣的：

• 當對「物件」發送訊息的時候，它會順著這個物件的 isa 指針找到它的所屬類別，然後翻看看這個類別的 method list 有沒有符合的方法可以執行；
• 當對「類別」發送訊息的時候，它會順著這個類別的 isa 指針找到它的所屬類別(也就是我們待會要說明的 Meta Class)，然後翻看看這個類別的 method list 有沒有符合的方法可以執行。

什麼是 Meta Class?

Meta 這個字我不太懂中文該怎麼翻譯比較好，有人翻譯成「元」，有人翻譯成「後設」，但我個人還是喜歡直接使用 Meta 這個詞就好。

剛剛在看類別的 objc_class 的定義的時候有提到類別的 Struct 裡也有一個 isa 指針，指向它所屬的類別，你可以想像成是它是「類別的類別」，也就是所謂的 Meta Class。

而 Meta Class 其實也是一種類別，所以也跟一般的類別一樣有 isa 跟 super_class 指針… 所以就可以把這整個的關係用一張圖表來解釋：

看圖說故事：

1. 每個 Class (Fox, Animal, NSObject) 的 isa 指針都指向一個唯一的 Class，這個 Class 稱之為 Meta Class。
2. 每個 Meta Class 的 isa 指針都是指向最上層的 Meta Class (在我們上面那段範例裡，就是 NSObject 的 Meta Class)，而最上層的 Meta Class 的 isa 則是指向自己，形成一個迴路。
3. 每個 Meta Class 的 super_class 指針都是指向它原本類別的 Super Class 的 Meta Class，但最上層的 Meta Class 的 super_class 則是指向 NSObject 類別本身。
4. 最上層的 Class (NSObject)，它的 Super Class 指向 nil。

PS: 在 Objective-C 裡有兩種 Root Class(NSObject 跟 NSProxy)，但因為在 Objective-C 裡「大部份」的類別都是 NSObject 的子類別，所以舉例常會說最上層的類別就是 NSObject。

一堆 Class、Super Class、Meta Class 的，有種快打結的感覺了嗎? 其實只要理解上面那張圖片，基本上就不用記這些繞舌的規則了。

但口說無憑，讓我們來寫幾行程式碼驗證一下：

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

Fox* lucky = [[Fox alloc] init];
[lucky say];

// about fox instance
NSLog(@"the class of lucky is %@, address = %p", [lucky class], [lucky class]);

// about Fox class
NSLog(@"Fox = %@, address = %p", [Fox class], [Fox class]);
NSLog(@"Fox's Super Class = %@, address = %p", [Fox superclass], [Fox superclass]);
Class metaClassOfFox = object_getClass([Fox class]);
NSLog(@"Fox's Meta Class = %p", metaClassOfFox);
NSLog(@"Fox's Meta Class's Super Class = %p", [metaClassOfFox superclass]);
Class metaMetaClassOfFox = object_getClass(metaClassOfFox);
NSLog(@"Fox's Meta Class's Meta Class = %p", metaMetaClassOfFox);

// about Animal class
NSLog(@"Animal = %@, address = %p", [Animal class], [Animal class]);
NSLog(@"Animal's Super Class = %@, address = %p", [Animal superclass], [Animal superclass]);
Class metaClassOfAnimal = object_getClass([Animal class]);
NSLog(@"Animal's Meta Class = %p", metaClassOfAnimal);
NSLog(@"Animal's Meta Class's Super Class = %p", [metaClassOfAnimal superclass]);
Class metaMetaClassOfAnimal = object_getClass(metaClassOfAnimal);
NSLog(@"Animal's Meta Class's Meta Class = %p", metaMetaClassOfAnimal);

// about NSObject class
NSLog(@"NSObject = %@, address = %p", [NSObject class], [NSObject class]);
NSLog(@"NSObject's Super Class = %@, address = %p", [NSObject superclass], [NSObject superclass]);
Class metaClassOfNSObject = object_getClass([NSObject class]);
NSLog(@"NSObject's Meta Class = %p", metaClassOfNSObject);
NSLog(@"NSObject's Meta Class's Super Class = %p", [metaClassOfNSObject superclass]);
Class metaMetaClassOfNSObject = object_getClass(metaClassOfNSObject);
NSLog(@"NSObject's Meta Class's Meta Class = %p", metaMetaClassOfNSObject);

輸出結果如下：

What does the fox say!?

the class of lucky is Fox, address = 0x100002260

Fox = Fox, address = 0x100002260
Fox's Super Class = Animal, address = 0x100002210
Fox's Meta Class = 0x100002238
Fox's Meta Class's Super Class = 0x1000021e8
Fox's Meta Class's Meta Class = 0x7fff77cce838

Animal = Animal, address = 0x100002210
Animal's Super Class = NSObject, address = 0x7fff77cce810
Animal's Meta Class = 0x1000021e8
Animal's Meta Class's Super Class = 0x7fff77cce838
Animal's Meta Class's Meta Class = 0x7fff77cce838

NSObject = NSObject, address = 0x7fff77cce810
NSObject's Super Class = (null), address = 0x0
NSObject's Meta Class = 0x7fff77cce838
NSObject's Meta Class's Super Class = 0x7fff77cce810
NSObject's Meta Class's Meta Class = 0x7fff77cce838

輸出結果可能在每個人的電腦上都不一樣，但從輸出的結果就能證明上面那張圖片的每個類別之間的關係。

要特別注意的是，你可能會覺得直接對類別發送 class 訊息就可以得到該類別的 Meta Class，事實上直接對類別發送 class 訊息只會得到該類別自己。要取得類別的 Meta Class，可以透過 object_getClass 來取得。

以上，希望這篇文章能讓大家對 Objective-C 基本的物件跟類別有更進一步的了解。

個人認為，雖然了解這些知識不見得對 iOS app 的開發有直接的幫助，但至少當在寫一個類別或使用一個物件的時候，會更清楚到底是怎麼一回事。如果有哪邊寫錯，還請前輩先進不吝指點。

今年二月份剛好有機會到朋友的公司幫忙開發 iOS app：「分心 FanXin」。顧名思義，就是一個可以讓你一邊看電視，一邊分心地跟朋友聊劇情的 app。

下載網址：https://itunes.apple.com/tw/app/fanxin-fen-xin/id545965153?mt=8

但近期因為覺得我家的那兩隻小朋友在長大的速度變好快，覺得好像再這樣忙下去就會錯過小朋友的成長過程了(像今天才看到我家三歲的小男生拿媽媽的化妝品在畫自己的臉)。所以把專案進度做個段落之後，就要回家來養小孩了(沒錯，我就是要從小開始訓練小朋友寫 code 了!)。

做玩具與做產品的差別

這回幾乎把一些常見的 iOS app 常用的東西都再磨過一輪。UI customization 當然是免不了的，另外，從 Facebook SDK 到 remote & local notification，從 HTTP API 的串接到 streaming messaging protocol 的訊息處理，從 Core Data 到 NoSQL 等等，甚至也很幸運的遇到了 iOS 7 的 migration，完全體會到做玩具跟做產品的差別。

這個 app 雖然不是全新打造的，但由於舊版的 app 架構有些不適合新改版的功能需求，所以最後幾乎是整個砍掉重練，從無到有手刻了超過三萬五千多行的程式碼(不包含3rd party library)： 雖然跟一些大型專案比起來還差很遠，但對我個人來說已是個里程碑，除了提昇了不少寫 code 的手感外，也更了解 Objective-C 跟 Cocoa framework 是怎麼回事。

分心團隊雖然是個新創團隊，但裡面的成員都不會太新手，有眼光犀利的UI、UX designer 讓整個 app 看起來很精緻，使用起來也更直覺；有優秀的工程師負責處理 API，也有專門負責行銷及想點子的同事，讓開發人員可以 專心的開發 app；除此之外，還有 Web 平台的開發人員，讓 Web 跟 Mobile 都有一樣的功能。在這短短的八個多月的時間跟大家學到不少。

徵人啟事

分心團隊目前仍持續有在徵人，有興趣的朋友歡迎來試試看囉!

• 徵才頁面

我每天的工作是敲打鍵盤之類的文書工作，所以幫自己找一隻順手的鍵盤也是剛剛好的藉口。

對於 HHKB 鍵盤的傳說，很早之前就有所聽聞了。最知名的應該就是 Richard Stallman 用 HHKB 鍵盤搭配百元電腦的那張照片(鍵盤本身比電腦本體還貴!)。我知道它是神器，但我等凡人即使拿了神器還是凡人，不會變成大神。 而且當初看到鍵盤上沒有方向鍵、沒有 CTRL 鍵跟 F1 ~ F12 鍵，在台灣也沒什麼機會試打看看手感，最重要的是，它的價錢不便宜，所以大多只是看看而已。

直到前不久去日本參加活動，有在電腦賣場試打了一下，心一橫的也敗了一隻回來，我挑的是白色無刻的版本。

鍵盤設計

HHKB 鍵盤實在是非常的小一隻，裡面也沒有我另外兩隻 Filco 一樣有加重的鐵板，而且它的 USB 線是可以拆卸的，所以攜帶相當方便。

在鍵盤的配置上，一般鍵盤的 ESC 鍵是在最左上角，但 HHKB 的 ESC 鍵就在數字 1 的旁邊，對 Vim 使用者來說可能算是個福音，因為左手小指頭稍微伸長一下就按得到了。不過對我來說影響不大，因為我很早就習慣用 CTRL + [ 做為替代方案了。

第二個不習慣的點，是 DELETE 鍵的位置在 ENTER 鍵上方，一開始常常會打錯。為什麼這樣設計呢? 其實我也不清楚，反正我現在也都是儘量使用 CTRL + h 來替代 DELETE 鍵。

最後，就是它的 ~ 跟 | 鍵的位置也跟一般鍵盤不一樣，附上一張 HHKB 的鍵盤配置圖：

HHKB 鍵盤最讓人卻步的，應該就是它沒有方向鍵。雖然沒有直接的方向鍵，但透過 fn 鍵的組合也是可以打得出來。一開始我也會覺得每次要上下左右之前還得再按一下 fn 很麻煩，但其實習慣之後也還好，而且對我自己的工作習慣來說，方向鍵使用的機會其實並沒想像中的多。

另外，鍵盤後面另外還有兩個 USB 插槽，剛好解決 MBP 的 USB 接孔不足的問題，像我就是拿來接無線滑鼠：

為什麼選無刻?

因為我想強迫自己在工作的時候把眼睛的視線停留在螢幕上就好，腦袋一邊想，然後手指頭跟著敲打。不過對我來說比較難習慣的還是數字鍵，特別是 6、7、8、9 這種在鍵盤比中間的數字，只要手指頭擺放鍵位的習慣不好，常常就會打錯，我到現在還沒辦法每次都能正確的打對我的電話號碼。

替代組合鍵

雖然 HHKB 為了縮小體積而拿掉了一些比較方便的鍵帽，不過還好在我平常工作的 Mac OS 有一些方便的替代組合鍵可以用：

• CTRL + h 刪除游標所在的前一個字元
• CTRL + d 刪除游標所在的後一個字元
• CTRL + k 刪除游標之後該行的所有字元
• CTRL + n 移到游標到下一行
• CTRL + p 移到游標到上一行
• CTRL + a 移到游標到行頭
• CTRL + e 移到游標到行尾

有這些組合鍵，可以減低不少沒有方向鍵以及 DELETE 鍵位置不同的的不適感。

手感

我不太會描述這種「感覺」的東西，感覺這回事只得靠自己來感覺了。HHKB Pro2 是無接點靜電容量式鍵盤，我只能大概形容它打起來有點像紅軸但又少了機械鍵盤的那麼明顯的清脆感，鍵盤打起來手感是真的不錯，特別是空白鍵打起來很穩。空白鍵對我來說很重要，因為空白鍵打的機會很高，之前打過一隻空白鍵會晃而且有雜音的機械鍵盤，整個感覺就差很多。

使用

平常使用鍵盤大多是就放在桌上，或是大腿上，如果空間不夠，我也會學 Richard Stallman 一樣把鍵盤架在筆電上： 可惜沒辦法架在原本的鍵盤上(會壓到筆電本身的鍵盤，據說 MBA 11” 的可以，不過我沒試過)

另外，我也很騷包的從友人那邊取得了一條會發光的 mini USB 線：

小結：

MBP 的鍵盤還好，但 MBA / MBPR 的鍵盤也許因為設計的關係，鍵盤比 MBP 要再淺個零點幾公分，打起來的手感我不太習慣，外接鍵盤之後就比較沒這個困擾了。 雖然一開始不太習慣 HHKB 的鍵盤配置，不過一切真的都是習慣就好了。

我差不多一個多禮拜就習慣它了，只是，HHKB 鍵盤跟 Vim 一樣，都是那種只要習慣它之後就沒辦法習慣別人的東西。雖說是差不多習慣了，但還是得多練習更熟練一些，才不會愧對這隻特別而且有趣的鍵盤 :)

今年日本的 RubyKaigi 2013 在 5/29(四)、5/30(五)、6/1(六)舉辦，議程是雙軌同時進行，共計有超過五十場演講及十場 Lightning Talk，並包括三場主題演講 (Keynote)，跟上一屆一樣也是三天。這次有超過 500 位 Ruby 開發者參加，其中有超過 100 位是從國外來的，這樣的規模短期內在台灣可能還是沒辦法達到(全台灣真的有在用 Ruby 工作的開發者加起來總數說不定都還不到 500 人)。 photo by @eddiekao

門票的部份比往年貴不少，上一屆的門票是 6,000 日幣，而今年沒有折扣的票種是 35,000 日幣(報名網站)。我運氣很好，因為演講投稿有被大會接受，所以省下了門票錢。

要特別一提的是，RubyKaigi 的門票票種除了一般票、學生票以及早鳥票之外，還有給地區 RubyKaigi 的主辦單位的優待票，還有曾經來參加 Rails Girls 的朋友及主辦單位。另外，即使投稿沒上的，也有部份的優惠。最有趣的是 Ruby Committer 票種，並不是成為 Committer 就可以理所當然的免費參加，要有超過 200 次 commit 數的才是免費，低於這個數字的還是得乖乖買票進場。

Pre-event

在 RubyKaigi 正式開始前一天晚上，Asakusa.rb 主辦了一個暖身活動(報名網站)，地點在日本相當知名的食譜網站公司 Cookpad。 photo by @eddiekao

現場來了許多只能在網路上才能見到的高手，而且連 Ruby 的老爸 Matz 也來了。 photo by @eddiekao

現場氣氛十分熱絡，Cookpad 的廚師還親自動手作飯給大家吃，真的是太切題了。 photo by @eddiekao

RubyKaigi

地點

RubyKaigi 的舉辦地點是在日本東京的國際交流館： photo by @eddiekao

主會議廳有上下兩層樓： photo by @eddiekao

本次大會主席角谷信太郎(@kakutoni)開場就說到：「那些平常只有在教課書裡才會出現的人物，現在很可能就坐在你身邊」。高手、大神們出沒的密度，遠超過我的想像。

T-shirt

大會發給每位會眾一人一件 T-shirt，擺放在報到處，會眾自己報到的時候就自己拿一件，而我因為講者的身份，我又多賺到一件。 photo by @eddiekao

可惜大會只提供 M 跟 L 尺寸，我太胖了，L 號的穿不太下..

名牌

往年聽說就是用名信片大小的空白名牌讓大家自己手寫，不但可以省下印刷的時間跟成本，而且還可讓大家發揮自己的創意。另外，裝名牌的袋子背後的有個拉鏈，裡面可以放一些名片，這樣要跟現場的朋友交換名片的時候就方便多了。 photo by @eddiekao

行動應用

大會有提供手機版的 App 供大家下載 (iRubyKaigi13)。App 的作者是位資深但非常客氣的前輩，為了應景特地採用 RubyMotion 製作，有這個 App 在現場要查詢議程或講師個人資料的時候相當方便。

訊息牆

在演講廳講台旁邊，設立了兩道訊息牆，一邊是來自 Twitter 的資料，另一邊則是來自 IRC。當沒有同步翻譯的的時候，訊息牆會貼心的出現善心人士的即時文字翻譯。 photo by @eddiekao

RubyFriends

網址：http://rubyfriends.com/

Ruby 開發者(通常又稱 Rubyist)大多有使用 twitter 的習慣，只要 twitter 發文的內容裡有標記 #rubyfriends 這個 tag 就會被拉進來，並且在現場播放。 photo by @eddiekao

我本來以為播放的是超薄的電視機，後來才知道原來用投影機加上 Android Smart TV 的組合就能做出這樣的效果，效果很不錯，而且成本比想像中的便宜 (參考資料來源)。

Ruby 時計

網址：http://rubyistokei.herokuapp.com/

參考 uniqlo 的 “UNIQLOCK” 概念製作的時鐘，目的是希望讓每位前來參加的 Rubyist 都有出現在螢幕上的機會，讓大家更有參與感。加照片的方式也很簡單，就自己直接 fork 一份指定的 github repository，加完照片資訊後發 pull request 就行了，這對習慣使用 git 做為版控工具的 Rubyist 們來說相當方便，也很切題。

世界 Rubyist Sticker

RubyKaigi 的會眾來自世界各地，這個設計也可以讓與會者更有參與感。台灣雖然不大，但我們這回可是來了五、六個人，當然一定要去衝一下人氣： photo by @eddiekao

塌塌米

如果你不想聽議程，或是想到外面透透氣，又或是在會場見到許久不見的好友想好好聊一下，在會議廳外面亦備有塌塌米可以隨時坐下來休息或工作，再走過去幾步就有 Microsoft 提供的免費飲料： photo by @eddiekao

中午用餐時間塌塌米則轉變成野餐型式： photo by @eddiekao

講師

講者名單裡面就有 16 位 Ruby Core Committer，陣容相當豪華，小弟有幸能跟這些講師排在一起，真的是有些心虛。

議程

三天共計有三場主題演講(Keynote)，四十餘場一般演講以及十場 Lightning Talk，二軌議程同時進行。身為地主國而且又是 Ruby 之父的 Matz 當然是免不了一定要來一場 Keynote 的： photo by @eddiekao

至於其它精彩內容也不需要多做介紹，直接參考 RubyKaigi 議程頁面會得到更多的資訊。順便厚臉皮的來偷偷廣告一下我自己的主題。

演講

在 RubyKaigi 沒有司儀、沒有議程主持人，也沒有講者或主題的簡介或開場，直接自己上台，接上投影機自己喊開始，全部採「自助式」的方式進行。講者自己控制時間，時間到就自己下台換下一位準備上台，相當有趣。

演講內容只有日文跟英文兩種選擇。日文演講的議程，現場有提供日翻英同步口譯，但英文演講則沒有提供，因為大會期望與會者都應該聽得懂英文。

Lightning Talk

每個人只有五分鐘的時間，而且必須用英文演講。時間一到旁邊的「ドラ娘」會敲鑼，並將強制中斷投影機訊號： photo by @eddiekao

常參加國內技術研討會的朋友對 LT 應該不陌生，很可惜大家時間都控制得很好，十個 LT 裡只有一個被拔線。

Ruby Committer v.s. the World

Ruby 不愧是發源自日本的程式語言，平常要有機會可以跟 Ruby Committer 近距離接觸可能沒那麼容易，這次活動議程裡有一場叫做「Ruby Committers vs. the World」，就是請這些 Committer 們全部一起上台跟大家互動，或是討論 Ruby 之後的方向。一口氣看到台上大概二、三十位的 Ruby Core Committer 排排坐，雖然他們討論的內容是日文我沒能全部聽懂(這個時段沒有同步翻譯)，但依舊感到十分熱血。 photo by @eddiekao

TRICK 2013

網址：https://sites.google.com/site/trickcontest2013/

這一個小時的議程我印象非常深刻，因為這是一場我覺得非常「變態」的議程。

請不要誤會，這裡的「變態」是稱讚意味。TRICK 這個比賽並不是要寫出什麼偉大的程式，而是希望參賽者在限定的檔案大小內，儘可能使用 Ruby 神奇或鮮為人知的技巧來寫程式。每個得獎作品，真的都非常變態，讓現場的大家驚嘆怎麼會有人想得出來把 Ruby 寫成這樣。

評審陣容同樣也是非常豪華： photo by @eddiekao

Official Party

Official Party 是在第二天的晚上舉行，地點就在會場附近，活動由 Github 贊助，每個人都可以自由參加。加上因為我自己的演講結束了，輕鬆很多，可以放心大膽的吃吃喝喝，也在現場用我破破的英文認識不少日本朋友。 photo by @eddiekao

書商

近年國內的技術研討會也都有書商的出現，RubyKaigi 則是請淳久堂在現場賣書。 photo by @eddiekao

有趣的是，淳久堂帶來的這些書，書的作者本人幾乎都有在現場，買完書可以馬上厚臉皮的找作者簽名，相當方便。

贊助商

打開 RubyKaigi 網站的贊助商列表，據長期待在日本的友人說，這個贊助商列表幾乎都是目前日本一線的軟體公司，在不太重視軟體產業的台灣，這大概是很難看到的畫面了。

除了現金贊助之外，也有一些其它的物資贊助，例如，Heroku 贊助大會三天活動的便當、Microsoft 讓大家在會場有免費的飲料可以喝，:DeNA 贊助現場的 WiFi，Ricoh 贊助現場的投影相關設備，Github 則是贊助 Official Party。

不得不提一下，這回大會的便當不錯吃，而且還挺高級的(據說是日本知名的燒肉便當)： photo by @eddiekao

RubyHiroba (Hiroba日文為”廣場”意思)

這個活動是接在 RubyKaigi 的隔天，需要報名，但免費參加的活動。活動在日本 Microsoft 舉辦： photo by @eddiekao

令我有些意外，原來日本 Microsoft 對 Ruby 有這麼多的贊助，除了前面提到贊助 RubyKaigi 的免費飲料外，也提供 RubyHiroba 的場地使用，這在台灣可能比較少見。

不愧是大公司，雖然這只是一個角落的照片，還是可以看得出來工作環境相當不錯： photo by @eddiekao

照片右下角不小心入鏡的正是 Ruby 的核心成員之一，Rubygems 跟 RDoc 的維護者 Eric Hodel。

上網回答問題的話(Ruby 程式相關的問題，網址：https://codeiq.jp/ace/ramen_burger/q330)，中餐可以得到一份”拉麵漢堡”。

另外，活動也有製作很可愛的貼紙： photo by @eddiekao

基本上 RubyHiroba 並沒有任何即定的議程，跟 RubyKaigi 比起來相對比較輕鬆。除了很多的 Lightning Talk 之外，在這個「廣場」的各個角落有一些同好會的聚集(例如 dRuby 或是地區 Ruby 社群)，，如果不想參與，也可以自己找個角落坐下來寫寫程式，或是去跟偶像們搭訕、請益。我在現場還跟著一位前輩學著折了紙做的紅寶石： photo by @eddiekao

可惜我的日文能力太差，不然應該還可以認識更多的新朋友。

Rails Girls

網址：http://railsgirls.com/

Rails Girls 在全世界好幾個地方都有分支，成立的目的是希望可以給女性提供一個技術交流、學習的管道，而且並不一定限定只學習 Rails。

Rails Girls Tokyo 在 RubyHiroba 也有一個角落，一開始我本來以為這會是台上講師講課，然後其它人坐在台下聽的方式進行，後來經由 organizer Yuki Torii 的說明才知道，原來她們並不一定每次都會像在學校”上課”的形式，反而是由一個教練(Coach)帶一到兩位學員進行小班制教學，以維持較好的學習品質。

photo by @eddiekao photo by @eddiekao photo by @eddiekao photo by @eddiekao photo by @eddiekao

心得

日本不愧是 Ruby 的發源地，不僅與會的 Ruby Committer 數量多，而且有一種整個日本 Ruby 圈在這個星期都動起來的感覺。除了地區社群的人也出現在這邊宣傳之外，整個星期除了 RubyKaigi 本身三天的行程之外，前後或晚上都有活動，幾乎可以說是「Ruby 週」了。

除了 RubyKaigi 這種年度大型的聚會外，日本地區性的 Ruby 社群也相當活躍，例如 Asakusa.rb、okinawa.rb 等社群，各有各的活動跟當地特色。

在 RubyKaigi，資深前輩或高手出現的密度，真的可以用滿地都是來形容。我沒誇張，除了 Ruby Core Committer 之外，我大概書架上所有的日文 Ruby 相關書籍的作者我都遇到本人了(我還跟 Ruby Hacking Guide 一書的作者青木峰郎握到手了)，而且這些高手們都十分的客氣。我在會場看到我的偶像 Aaron Patterson，就馬上厚臉皮的衝上前去拍照： photo by @eddiekao

可以跟這麼一大群來自各地而且喜歡 Ruby 而且厲害的朋友聚在一起，雖然彼此說著不同國家的語言，但仍有著 Ruby 這個共同的語言，溝通起來並沒想像中的困難。

話說回來，以我自己曾經參加過的幾個程式語言相關的技術研討會來說，Ruby 相關的技術研討會似乎算是相對比較國際化的。就以台灣在 2012 年底舉辦的 RubyConf Taiwan 來說，就有共計 10 個國家的人前來參加。

另外，關於活動贊助這件事，我自己曾主辦過一些中、小型活動，知道贊助一向都是活動最麻煩的事。以 RubyKaigi 的贊助來說，即使是最大贊助商，也只有在 Keynote 之前上台的幾分鐘的致詞(sponsor appeal)，或者是換得一場五分鐘的 Lightning Talk。將贊助跟議程分開，我個人覺得這是很棒的事。我認為 Keynote (主題演講，日文稱做”基調講演”) 是整場活動的主軸，如果因為贊助而出售給贊助商，贊助商很可能會因為為了推廣自家產品而讓主題演講的主軸有所偏差，我想這是主辦單位跟會眾們所不願樂見的。

雖然這回 RubyKaigi 的門票不算太便宜，但我覺得這樣三天的活動非常值得，2014 年再舉辦的話，我一定會再報名參加。 photo by @eddiekao

最後，感謝 RubyKaigi 的籌辦團隊，給我們這群喜愛 Ruby 的人帶來了一個這麼好的活動，辛苦了。 At last, thank you RubyKaigi team, you gave us a AWESOME conference, お疲れ様です!

因為我英文不好，日文也不會，所以如果有善心人士願意幫忙將本文翻譯成英文或日文，歡迎在底下留言，或是直接與我聯繫亦可 :) I’m not good at English nor Japanese, if anyone would like to translate this post into English or Japanese version, feel free to comment here or just contact with me :)

在進入主題之前，我問大家有多少人曾經來過台灣，結果在場有十來個人舉手，就以現場人數的比例來說不算少。
Before I jump into my topic, I asked everyone how many of you have been to Taiwan before, to my surprise, there’re more than 15 people raised their hand, which is about 20% of the attendees in this hall(I think).

View on Speaker Deck | Download PDF

雖然之前有一些些上台演講的經驗，但這是第一次出國演講，而且還是全程用英文演講，我知道有很多的大神甚至 Ruby Committer 就坐在台下，所以我相當緊張。我那個「上台的前一天不會睡」的魔咒果然還是依舊存在，所以演講當天凌晨四點，我拿著筆電到飯店的大廳練習對著空氣講，練到早上七點，但還是覺得不夠穩。
Although I have a some experience about having public speech, but it’s my first time to have a presentation abroad and do my speech in English, and I also know there might be lots of awesome rubyists sitting there, including some Ruby core committer, so I really feel nervous. And I have a curse that “I won’t sleep if I have a public presentation on the next day”, so I practiced in the lobby of the hotel from 4 A.M. to 7 A.M., but still not stable enough.

我的演講廳是小間的，所以壓力有稍微小一點點。
My presentation hall is the smaller one, so my pressure is also slightly smaller, too.

為了怕現場出包，所以在 code review 展示的部份我是用預錄的，不過事後想想好像直接現場操作比較容易掌控時間
I think I might make some mistakes while presenting, so I recorded the code review demo in advance, but I think the real live demo might be easier for me to control time.

上午的演講結束後，下午發生的小插曲讓我抖了好大一下。我在演講內容裡有提到一些在 Ruby 的原始碼裡面有一些小地方的命名不太優，當下大家笑得很開心，雖然娛樂效果達到了，但我其實也有點擔心會不會有什麼不好的副作用。結果上午的講場結束，下午就看到這則：
After finishing my talk, there’s something surprised me. In my speech, I mentioned some interesting naming in the Ruby source code just for fun. I know it might be entertaining but still a little worried about if there would be any bad consequence. Then in the afternoon, I saw this tweet:

哇!! 我有嚇到的感覺了，不過因為我個人覺得這樣好像有些失禮，所以當晚的 Official Party，我就親自去跟 @nobu 說聲不好意思，希望沒有造成他的困擾。其實我也是想趁這個機會認識一下只有在網路上才能看得到的傳說大神，而且他好像一點也不在意。
Wow! That’s really really surprised me!! and I don’t know if this would cause any trouble for committer, so I went to @nobu and said sorry to him on the official party in the night, and hope didn’t cause extra trouble for him. In fact, I went to him also want to know him by this chance, and actually he didn’t mind at all.

第三天的議程，我本來就打算要來聽 Jim Gay 的主題(他是 Clean Ruby 一書的作者 )，沒想到坐下來沒多久竟然看到自己的名字跟前一天講的東西出現在投影片上：
In the last day, I was planning to attend Jim Gay’s talk, whihc is the author of the book ”Clean Ruby”. After sitting in the hall, I suddenly found my name was quoted in the slide:

再度有被嚇到的感覺。
Yes, Supprised me again.

活動結束後，RubyKaigi 2013 的頭目角谷也推了一篇：
the Organizing Director of RubyKaigi 2013 Shintaro Kakutani also tweeted this:

再次看到自己的名字被提到，有些驚訝也有些不好意思，不過這個”Conference-Driven Development(CDD)” 聽起來好像不錯，而且我喜歡 “RubyKaigi made Ruby Better”，如果有朝一日我有能力，我也希望可以多貢獻一些心力。
I feel surprised again and also little embarrassing, but the “Conference-Driven Development(CDD)” sounds workable, and I love the “RubyKaigi made Ruby Better”, I hope I can do more contributions to Ruby and this community someday if possible.

感謝高井さん(@takai)幫我拍的照片，讓我在 Rubyist 時計上也可以有一張漂亮的照片。
Thanks to Naoto Takai(@takai) to take a photo for me so that I can have a nice picture on the Rubyist Tokei.

photoed by @takai

這趟日本之行有學習到不少東西，收獲很多，會在接下來的幾篇文章介紹。最後，有講的不好的地方，還請多多指教。
Anyway, I learned a lot on this trip to Japan, and I’ll write them down in next blog posts. At last, if there’s any bad or something wrong about my speech, please feel free to comment.

Thank you all, RubyKaigi team, you’re all AWESOME!