敝社正在徵工程師，公司環境跟獲利情形很不錯、做事精實、待遇優渥。職缺請參考: Rails Developer、Front-End Developer、Front-End Designer、QA Tester。
Faria Systems 是一家以 IB(International Baccalaureate) 國際學校為客戶的 Software as a Service 軟體公司，全球超過九十個不同國家、一千兩百所國際學校使用我們的產品。
附上一張公司同事正在進行 pair programming 的照片:
最近意識到 Github 上的 pull requests 其實也是 branches 參照，所以你也可以根據 pull request 編號在本地端直接取出。對於常用 pull request 功能來作 code review 的團隊來說，是蠻方便的小技巧。
首先編輯專案下的 .git/config，加上 fetch = +refs/pull/*/head:refs/remotes/origin/pr/* 這一行，例如：
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:ihower/sandbox.git
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
接著打 git fetch origin 就會抓下來這些 remote branches：
From github.com:eduvo/keybridge * [new ref] refs/pull/1/head -> origin/pr/1 * [new ref] refs/pull/2/head -> origin/pr/2 * [new ref] refs/pull/3/head -> origin/pr/3
接著用 checkout 取出，例如 git checkout pr/3 即可。
喜歡的話，也可以設成 git 全域設定，直接套用所有專案：
git config --global --add remote.origin.fetch "+refs/pull/*/head:refs/remotes/origin/pr/*"
參考資料: Checkout Pull Requests Locally
舉一反三，那要怎麼在本地端送 Github 的 Pull Request? 參考 HSATAC 的這篇：用 Commandline 發 Github Pull Request：
首先安裝 github 的 hub 工具：
brew install hub # 或 gem install hub
編輯 ~/.bash_profile：
# https://gist.github.com/hSATAC/5591270#file-gistfile1-sh
# Usage: pr (pull request current branch into develop)
# Usage 2: pr stable (pull request current branch into stable)
# Notice: replace "team" with your github team account.
function pr() {
base=$1;
if [ "$1" == "" ]; then
base="develop"
fi
hub pull-request -b team:"$base" -h team:`git rev-parse --abbrev-ref HEAD`;
}
前一陣子念「笑談軟體工程：敏捷開發法的逆襲」這本書，其中有幾篇文章的說法和比喻常被引用，所以我按圖索驥，也把原文章拿出來念一念，包括：
「原始碼就是設計」「 Source code is the design」，避免花費太多時間在分析設計上，原始碼本身就是是軟體設計的產生，而 compile, link 等才是軟體的生產活動。因此，寫程式是「設計」的活動，而不是「生產」的活動，因此傳統設計文件的重要性就大大降低了。
程式設計不是 “building software”，而是 “designing software”。
軟體系統的設計是演進來的，不能一步到位，而是要藉由憑繁與使用者互動得到的回饋來修改系統設計。
與其把程式設計比喻成蓋房子，實際上更像是園藝。
所有程式設計活動其實都是維護，因為絕大部分的時間都在改code，寫一點改一點。即使是新專案，也很快需要回頭作修改。
後兩篇是 A Conversation with Andy Hunt and Dave Thomas 訪談。Andy Hunt 和 Dave Thomas 是 The Pragmatic Programmer 這本經典的作者，他們後來共同創辦了 Pragmatic Bookshelf 這家出版社。其他五篇訪談也值得一看，都是關於軟體開發的真知灼見：
這篇拖稿超久，堆在草稿大半年了，真是不好意思。跟往年 2010, 2011 一樣，還是要留個籌辦心得紀錄。聽眾版心得文可以看會後記錄。
該怎麼描述這次的 RubyConf Taiwan 2012 呢，應該是超乎預期的成功吧。大體來說，除了 wifi 搞砸了之外，其他似乎都讓大家還蠻滿意的，特別是議程和食物 :)
這是今年在 COSCUP 演講的投影片，Git 應該是近幾年最流行的版本控制系統，也有非常多的入門和教學資料。這次我則是從底層的原理和操作來介紹，探討 如何不用 git add 和 git commit 指令進行 commit 動作?
了解 Git 的資料結構之後，就會發現其實內部原理並沒有很複雜。對照發明人 Linus 的話，就會讚嘆版本控制系統就該這樣設計啊！
I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers
his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. by Linus Torvalds
p.s. 會後有會眾問我關於 workflow 和 rebase 的問題，可以參考我之前的課程投影片。
很奇怪，ruby-debug 或是 ruby-debug19 常常有版本問題，甚至還有 fork 版本 debugger。都不知道哪個沒問題。
最近發現其實 pry gem 就可以作為 debugger 之用，本來還以為只是漂亮的 irb 取代品，沒想到功能這麼強大。作為 debugger 使用的方法很簡單，只要在程式裡加上：
binding.pry
這樣就會設下中斷點。例如在 rails console 或 rails server 中，就會停下來讓你可以進行檢查和除錯。
可是如果你有用 Rails 伺服器，例如 pow 或 passenger 的話，因為不在同一個 process，所以必須加裝 pry-remote gem。它利用 DRb 技巧讓另一個 process 可以亂入進行除錯，用法改成：
binging.remote_pry
接著在 command line 輸入 pry-remote 就可以進行除錯了。非常簡單好用。
其他 pry plugins 也可以裝一下，包括：1. pry-stack_explorer 輸入 show-stack 的話可以看到 call stack 2. pry-debugger 可以加上 step, next, finish 和 continue 的控制
這是今年在 OSDC.TW 演講的投影片。這次的內容相對簡單，就分享一個好用的工具給大家。會挑這個題目並不是因為自己對 Vagrant/Chef 非常熟很有研究(我們公司的 DevOps 當然比我厲害)。而是從一個 Rubyist 的角度想說 Ruby 社群裡有什麼好東西可以介紹給大家。畢竟 OSDC.TW 並不是以特定技術為主的研討會，來聽的人四面八方，所以從去年開始我就盡量考慮聽眾適合聽的程度，以後大概也會抱持這樣的想法吧。