Blog.XDite.net

這是剛剛在社群頻道上閒聊的結論。

因為我最近在教 Rails 進階班，都用 Github Pull Request 在收學生作業。

作業進度無所遁形

這個方法非常有效率，因為：

1. 有效掌握學生何時交作業，避免理由伯。
2. 可以讓助教線上共同批改。
3. 學生可在 pull-request 直接發問。
4. 可互相參考解答。

容易檢驗抄襲

所以我想大學資工系其實應該也可以比照辦理才是？比起之前用 FTP 上傳，這個方法實在有效率太多了，而且也可以驗證學生是不是自己寫的。

• 如果是自己寫的必有 commit log
• 就算參考其他人的解法也沒關係，起碼 (1) 他有辦法學到怎寫作業 (2) 抄襲者還是可以用 CI Server 做批改魔挑出來打 0 分。
• 容易設定死線

逼迫大家共同作業

更進一步的用法我還想到，可以用 Gitbook 寫課程共筆或共同寫期末報告。

這樣同組誰偷懶就一目了然。而且還可以訓練用 git co-work 的能力。

培養未來競爭力

而且 Git 現在幾乎是軟體開發界、寫作電子書界、參與開源專案必備的技能。

讓學生直接贏在起跑點上，應該是可以稍微扭轉一下台灣軟實力的劣勢。

學習資源：

至於哪裡可以學使用 Git？教 Git 會很難嗎？

Code School 已經寫了一份免費的 Git 教材 Try Git 。老師連準備教材的時間都省下來了...XD

update: 密西根大學有老師今年也這樣收作業：http://ivory.idyll.org/blog/2014-teaching-undergrads-with-github.html

因為在編教材，覺得這很基本也很重要。所以特別來出來寫。

helper_method

在 controller 裡面的 method 不能在 view 裡面用。

也就是在

class ProductsController
  def find_cart
    @cart = Cart.find(session[:cart_id])
  end
end

View 裡面不能用

   <%= find_cart.items %>

拉這個 cart 出來直接用。

如果你要在 controller 和 view 都能拉現在的購物車，必須要用 helper_method 宣告這是一個 controller 級的 helper。

class ApplicationController
  helper_method :current_cart
  def current_cart
    cart = Cart.find(session[:cart_id])
    return cart
  end
end

這樣你就能在 View 裡面用 current_cart。

   <%= current_cart.items %>

或者是 Controller 裡面也能用 current_cart。

class ProductsController
  def add_to_cart
    find_cart.items << @product
  end
end

view_context

在 helper 裡面的 method 不能在 controller 裡面用。
也就是在

class ProductsController
  def show
    @page_description = truncate(@product.desc, :lenght => 50 )
  end
end

是不會動的。

如果要在 controller 裡面取用系統內建的 Rails View Helper，或自定義的 View Helper。
必須要用 view_context 去調用。

class ProductsController
  def show
    @page_description =  view_context.truncate(@product.desc, :lenght => 50 )
  end
end

小結

但基本上還是建議在 View Helper 與 Controller 的 code 不要互相混來呼叫來呼叫去。讓 View 歸 View，Controller 歸 Controller。若真有業務上的需求需要「到處都可以用」。建議寫 Module 掛在 lib 用 mixin 技巧混入。

Intro to Rails Workshop X COSCUP BOF ( Taipei #02)

首先，我要先宣布 Intro to Rails Workshop Taipei #2 會將在 7/19（六）舉辦！

報名網址在：http://tw-rails.kktix.cc/events/rails-outreach-taipei-02-coscup

時間地點在 7/19 (六）COSCUP 的 BOF 時段與場地 ( 18:30-22:00)，這次我們開放名額為 60 人。

因為上次 #1 的 workshop 有人抱怨說臨時宣布結果名額報不到，因此這次報名時間是從 6/4 （三）10:30 開始，請大家明天早上準備好開始搶票...。這次也一樣需要地方的教練支援，教練報名網址在此。

Building Rails Workshop ( COSCUP 演講）

另外不管你是 Ruby on Rails 社群的朋友，或者是別的語言社群想辦 Workshop 的朋友，我在 COSCUP 7/20 （日）14:10 - 14:50 會有一場 Talk，分享辦 Rails Workshop 與推廣 Ruby on Rails 的經驗與技巧，歡迎各位參加！

RailsP2P program

第二件事就是這個令人興奮的 RailsP2P program： http://railsp2p.tw 。（學習機會與教練媒合平台）

在籌辦過三場 Workshop （北中南）之後，我們發現 Ruby on Rails 在台灣教學的需求非常非常的猛烈。從社群幾次 Workshop 報名的速度以及我的著作 Rails101 的銷售數字。我們估出了大概全台灣現在有興趣入門學習轉職成 Rails Developer 的人大概有 1000-2000 人左右。

學習 Rails 並順利轉職目前有三個階段：

1. Intro to Rails （了解 Rails 基本架構與環境）
2. Basic Rails Development ( Rails 基礎開發技巧與結合 Gem 開發功能、簡單的 deploy, see Rails101 as example )
3. Intermediate Rails （ Rails 程式實戰開發 / 軟體規劃能力 ）← 求職標準

我們發現一個殘酷的現實：即便再怎麼努力辦免費的入門 Workshop，一場以 40 人為計。我們就算一年辦 20 場，都消化不完這個需求（且每辦一次 workshop ，主辦單位都要至少招募 10 個以上的助教）。

如果要能有效地推廣 Rails，那我們應該要做的不是把開 Rails Workshop 的責任攬在主辦單位身上，而是把機會開放給每一個社群開發者：

最後，我們想出了一個遍地開花計劃：

RailsP2P： http://railsp2p.tw 。（學習機會媒合平台）

教練資格

如果要讓大家能夠更快更容易的得到學習 Ruby on Rails 的學習機會，社群不應該把 Rails 的教學資格壟斷在某些人手上，取而代之的應該是的創造點對點遍地開花的教學架構。

經過評估測試過，目前的 Workshop 教練需求條件：

1. 學習 Rails 超過三個月的時間有能力教 Intro to Rails
2. 學習 Rails 超過一年的時間有能力 Rails101

透過 RailsP2P，人人可以上網找 Rails 教練，不管你住在台灣的哪裡，都有辦法得到 Ruby on Rails 的現場指導機會。

讓想學 Rails 的開發者，指定想學習的教材與時段，刊登需求聘請私人 Rails 教練一對一的教你（各地都可以）。

刊登學習步驟：

1. 上網填寫你的學習需求
2. 登記所在地 （在台灣的哪裡）及有空的時段
3. 有興趣的教練實際聯絡進行教學

目前我們建議課程所學習的時間以及學費是 Intro to Rails : 4 hr (NTD 2000-4000)。Rails 101 : 8-10hr ( NTD 5000-9000 )

教練聯絡學員步驟：

1. 上網看到有興趣的 case，進行應徵
2. 登入 Github 帳號填寫簡單自我介紹以及背景
3. 學員若對您感到興趣會寄信聯絡
4. 雙方交換聯絡方式以及教學模式 / 地點 / 時段

人人都可以加入 Rails 教學的行列

這個需求刊登平台，從一開始就是為了解決各地的學習與教學需求而生，現在不會收仲介費，未來也不會收費。而且我們社群希望利用這個平台創作出新的職業契機：

很多 Rails 開發者在抱怨想回鄉工作，但家鄉卻沒有好的工作機會。有了這個平台，在家鄉教 Rails 也可以是一種職業機會。我們的台南社群朋友就開玩笑說：太爽了，這樣台南區的教學機會就都是他的了，藍海市場，幾乎沒人跟他搶 XDDDDD

想賺外快嗎？你可以嘗試一個月晚上教幾場 Rails，一個月下來的學費也有幾萬塊，不無小補。

希望 RailsP2P 可以創造一個人人有功練，人人有錢賺的正向學習環境，歡迎各位加入 Rails 學習 / 教學的行列。

首先，感謝各位三年以來的支持。

為了讓更多人能夠學習 Ruby on Rails，加速 Ruby on Rails 推廣教育地進行。我決定將 Rails 101 的價格調降到 0。

購買連結還是以下這兩個網址

• http://leanpub.com/rails-101
• https://readmoo.com/book/210010467000101

但從今天開始，你可以在 leanpub 上把價格調為 0 元，免費取得這本書。

當然，練習完畢如果你覺得這本書有用，可以再重新付費給我。

Github Repo 在此：https://github.com/xdite/rails-101

眼尖的朋友看到，最近我開的兩堂課： Deliver Project on Time 敏捷專案管理實務 - 六月班 與 Intermediate Rails - Rails 實戰就業班（六月)，都加入了 User Story 撰寫的教學部分。紛紛偷問我為什麼要加這個東西進去？

Rails Meetup 三年多來，在輔導培訓過非常多 Rails Developer 之後，我開始發現當今的網站開發教育中漏掉了很重要的一環，就是「規劃 Application 開發的技術」。

線上教育什麼技術都有教：基本的 Ruby on Rails，基本的 jQuery，基本的 CSS。看起來好像你上了這些基礎班，就可以開始寫一個網站，找到一份工作。但這卻跟現實有一段相當大的差距。我訪問過很多徵才廠商和初級開發者，開始了解到問題出在哪裡。

具備網站簡單的開發能力只是必備的基礎，僱主最看重且會決定錄取的能力，卻是「把 Idea 變成實際 Application 的能力」。就是今天老闆開一個需求，員工要能做出規劃，並且在時間內執行完畢。

很多成長為 Senior Developer 的前輩沒有意識到這也是一門技術，所以面對「如何培養規劃實做能力」的問題，因此往往會覺得，你多寫習題就可以練成了，或找到一份工作被多操一下就會了。但這又回到雞生蛋、蛋生雞的問題，沒有能力寫出中小型 Application，又怎麼容易找到可以成長的工作。

打破雞生蛋、蛋生雞的循環：User Story as Architecure

我後來一直思考如何解決這個問題。才發現其實很久以前我已經解決了這個問題，只是我一直沒有意識到..，就是：「透過撰寫 User Story 的訓練，練習出如何設計架構的能力。」(這個技術四年來也一直在我部門/公司中施行訓練）

什麼是 User Story

User Story，是 Scrum 這個敏捷框架會用到的一個開發方法。具體解釋可以看ihower 曾經寫個的這份整理，寫的很棒。

傳統開發流程是 PM 花上很多的時間進行訪談寫成規格，RD 再轉成 Application。不過往往這個轉換過程中，卻容易出現相當大的風險。

當中的問題出在於 PM 的「規格」有很大的機會天馬行空，即使不天馬行空，也有可能不貼近使用情境，或者是根本脫離真實使用情境。RD 自然拿到規格和畫面 Workflow 進行「轉換」時，萬分痛苦。

當然，更多時候， RD 根本不知道要怎麼「轉換」。這就是為什麼每個專案都花了很多時間進行了需求訪談，也可能寫了詳細的規格，專案卻始終容易出包，都是在「轉換過程」中出現了問題。

User Story 強調透過一份簡單的情境規格，具體的描述出軟體在「使用者」的手上，是怎麼樣被「操作」的。能夠讓 RD 在開發時，能夠盡可能地貼近真實被需要的 Application。而不需要的功能，或者無法被實作的功能，將在一個一個循環之中，被捨棄。

初學的範本是：作為一個 (某個角色) 使用者，我可以做 (某個功能) 事情，如此可以有 (某個商業價值) 的好處。

幾個 User Stories 的範例如下：

• 使用者可以在網站上張貼履歷
• 使用者可以搜尋有哪些工作
• 公司可以張貼新工作
• 使用者可以限制誰可以看到他的履歷

為什麼 User Story 可以幫助培養開發能力

透過把冰冷的規格轉成具體的小情境，RD 可以更知道要怎麼將架構切分成較小且可以單次就開發完畢的小元件。利用一個一個小的故事，開發出一個一個的小功能，再堆疊成一個完成的網站。同時透過 User Story 的內容對比，RD 能夠開始有辦法排出輕重緩急，甚至估算出正確時程。

我發現很多入門的 Rails 開發者，在學完基礎的 Rails（ 比如說學完 Intro to Rails 、Rails turtorial。這些從 CRUD run 到 deploy 到 Heroku 的簡單一日課程之後。就無法再進行下去了....

根本原因是初學者不知道下一步如何進行自己點子的實作。

許多的書籍都有具體給定步驟與架構，因此在自行練習的時候沒有問題，但在自己自由設計題目時，卻不知道如何開展。或者是自己有了一點基礎想法，拍了某些網站的 screenshot & workflow。拿回家時卻不知道怎麼 breakdown。

這就是為什麼我在

• Deliver Project on Time 敏捷專案管理實務 - 六月班
• Intermediate Rails - Rails 實戰就業班（六月)

都加入了 User Story 的教學部分。因為 breakdown to application, simple project management 就是新手進階成職業的一大瓶頸門檻。

為什麼非程式設計師也需要學習撰寫 User Story

在 Deliver Project on Time 敏捷專案管理實務 的五月班，有一位很有意思的報名者，他報名是因為長期參與 NGO 的活動，但卻覺得 NGO 的專案規劃以及執行專案能力不佳。因此想要透過上這個班，實際學習專案管理能力。

其實不只是 NGO，通常非程式設計師出寫出的規格通常都較脫離現實，是因為誤以為了軟體開發只要提供了「欄位」「畫面」「流程」「仿照知名網站的 Workflow），這樣就是完成專案的規劃。

事實不然，程式設計師往往希望你提供的是軟體使用「需求」，以及軟體「使用情境」，這樣他們才容易設計出好的軟體。很多規格書滿滿的 screenshot，或者是標注模仿某知名網站 Workflow。其實都不是程式設計師想要且需要的東西，他們希望你有辦法簡單敘述你要什麼，你想要的流程是什麼，你背後的生意邏輯是什麼。（a.k.a. 你真的知道自己在幹什麼）

好方便「程式設計師」後續「規劃」「軟體架構」。

User Story 可以很容易的協助雙方達成一致性的目標，因為User Story的書寫語言並不是什麼技術文字，而是一個又一個的情境。可以作為一個相當好，雙方又容易接受的橋樑。同時透過撰寫 User Story，自己也可以越來越釐清這個網站真正需要的東西是什麼，不需要真的實際寫程式，不懂程式也可以設計出合理的網站架構。

這就是我建議為什麼非程式設計師也需要學習撰寫 User Story 的原因。

學習資源

要學習撰寫 User Story 以及學習進行簡單的小專案管理。你可以購買 Scrum 系列的書，或者是以下幾本我覺得不錯的書：

• User Stories Applied: For Agile Software Development
• Extreme Programming Explained: Embrace Change
• Extreme Programming Installed

當然，如果你想偷懶，最快的方式，還是報名我以下的這兩個講座 / Workshop。我有直接整理好的講義以及結合 Project Management 的實戰技巧。

• Deliver Project on Time 敏捷專案管理實務 - 六月班
• Intermediate Rails - Rails 實戰就業班（六月)

希望以上這些學習資源能夠幫助到你。

( 如果你有相關的疑問，歡迎透過這個表單 聯絡我）

新課公告：這個班是為了想快速進階 Rails 實戰並且有意轉職 Rails 網站開發的的開發者所開設的。

上課時間/ 報名網址：

課程網址：http://learn-rails.today/workshops/intermediate
報名網址：http://rocodev.kktix.cc/events/intermediate-rails-2014-06

共四次 12 小時，另加回家大量實作。

• 6/9 (一）19:00 - 22:00
• 6/16 (一）19:00 - 22:00
• 6/23 (一）19:00 - 22:00
• 6/30 (一）19:00 - 22:00

Railsconf 2014，跟我一起參加的還有 T 客邦的工程師 Bruce Li。大會的第二天他參加 Novice 的 Theme Track，我則是跑去 Growing Talent 的 Track。

晚上在飯店我們交流心得時，他提到大會有一個 Talk 不錯。叫 Reading Code Good。

Talk 大意是這個講者才學 Ruby on Rails 一兩年而已，他當初為了成長，所以在當地號召了一些朋友，一起組一個 CodeClub。這場 Talk 是他分享他辦 CodeClub 的經驗。

為什麼讀書會容易失敗？

這個 CodeClub 不是一個讀「書」會。

傳統 CodeClub 多半是「讀書會」，像拿一本經典的書再念，學習裡面的技巧。但這種會超容易失敗，因為書上多半不是真實的案例，而且離實際應用都還有點距離，Junior 硬要跟上每章進度會非常痛苦。

How CodeClub works?

他們的 CodeClub 玩法是上網找一段長度適中的 code （ 100 行）的 code。大家一起來讀 code，從中學習：

• 這一段 code 值得學習的地方
• 這一段 code 哪裡寫的爛
• 我們可以如何改進這一段 code

講者從這樣的過程中吸收到很多知識。

＊＊＊

聽完這個 Talk，Bruce 很羨慕，很希望在台灣有一個。不過要籌辦這種 CodeClub，找人不是問題，找題目比較是問題。比較大的麻煩就是找到可以拿來讀的 Code，然後有人可以帶解答。我們後來想起 RailsConf 有開一個 Refactoring Workshop

這個 Workshop 裡面有四題：

1. extract method 的使用時機
2. NullObject 的使用
3. 結合上述兩招的綜合應用
4. ServiceObject 的抽取

相當適合拿來辦 CodeClub。預計 CodeClub 會雙週辦一次。第一次解 (1) (2)。第二次解 (3) 第三次解 (4)。第四次以後解新的題目。

這個活動會在 5/20 辦第一場。6/3 辦第二場。6/17 辦第三場。歡迎大家共襄盛舉。

報名連結在：http://www.meetup.com/taipei-rails-meetup/events/182794352/ 5/20 （二）晚 Deroot休閒空間

（BTW，這個活動主辦人是 Bruce Li。他的部落格是 Bruce的玩具間。

在 Rails 2014 裡面，有幾個精彩的 Talk，Advanced Arel: When ActiveRecord Just Isn't Enough 就是其一。

這個 Talk 的內容是在講如何使用 Arel 搭配 ActiveRecord 產生更複雜的 SQL Query。

Arel : Relational Algebra

背景介紹：

• ActiveRecord 是 Ruby on Rails 的 ORM。是世界上最強最智能的 ORM。
• Arel 是 ActiveRecord 的底層。

四年前 Ruby on Rails 突破了所有 ORM 只能用排列組合設計的盲點：

• 各種 SQL statement 排列組合
• 各種 RDMBS query 排列組合

試圖去突破：發明了一套強大的 SQL AST 引擎，用 Relational Algebra 去組 SQL Query。而這套引擎就是 Arel。

智能產生優化過的 SQL statement

有了 Arel，開發者可以輕易的用 ActiveRecord 組出 Query，而且是經過優化的 Query。

（比如說以前有一些條件是開發者必須要先撈資料先塞進記憶體，再塞進 ORM 的，在 Arel 時代只要下正確的 ActiveRecord 語法，ActiveRecord 會自動知道要用 subqury 去解決這件事 ）。

讓 SQL statement 回到 Business Logic 層次

用 ActiveRecord 產生 SQL query，不僅可以讓原先的邏輯回到 Ruby 層次，容易維護之外。多數時候 ActiveRecord 甚至生出來的 query 比開發者自己想出來的還要高效許多。

（ Arel 跟著 Rails 3.0 釋出，2010/8 ）

但是，雖然有了智能的 ActiveRecord ，在許多的實戰領域裡面，開發者還是被逼著要用許多 handwriting 的 SQL statement。因為我們認為這些東西無法用 ActiveRecord 下出來。例如複雜的 join 或 Group。甚至以前的許多 NOT case。

ActiveRecord with Arel

這篇 Talk 就是要打破開發者原先的思維，許多人以為下 SQL Query 必須只能透過 ActiveRecord，事實上 ActiveRecord 「可以」吃 Arel 本身的語法 combine 在一起用。這場 Talk 就是教大家怎麼這樣用。展示了非常多寫法。

不過，雖然看了這麼多炫技，開發者可能還是會覺得哪裡不對勁！

多數的複雜 SQL statement 是從 Stackoverflow 上抄來的

如果我知道 SQL query 要怎下，毋庸置疑我就會用這些技巧去組啊。但很多時候問題是我根本不知道怎麼下出這些條件。都是到 Stackoverflow 神出來的，然後只會拿到一組 "it works" 的 SQL syntax。這些神解法我連邏輯都不知道怎組出來的，要怎麼 reverse 回來。

Scuttle.io

Well，這個 Talk 的作者說，他知道這件事，所以這場 Talk 其實只是為了要展示了他最近寫的一個工具 http://scuttle.io。

Scuttle.io 只有一個功能，「你貼 SQL statment，它幫你還原成 Arel 語法」。

當作者 Live Demo 展示完這個工具，全場幾百個 Developer 起立鼓掌了十幾秒。

先貼解法：

1. 在 Gemfile 裡加上 ransack。
2. 把 lib/search.rb 的內容換成 https://github.com/xdite/discourse/blob/ransack/lib/search.rb

解釋

這是在上週我為 g0v 架設論壇 時，遇到的問題。discourse 上的搜尋基本上碰到中文和日文漢字不會動。（這裡有 討論串)

https://github.com/xdite/discourse/blob/ransack/lib/search.rb

( 具體 commit 請看 https://github.com/xdite/discourse/commits/ransack 可見所有我的詳細解法）

簡單來講是 CJK 以及非 latin 文雖然在 postgre SQL 上搜尋不好，但還沒到 unsearchable 這麼差。discourse 會搜不到中文，是因為他不用 gem ，自幹 full-text search，結果把切字系統整個搞爛了。我把他拆開，然後適度的導入 ransack 就修好了。

雖然是這樣也花了我 3hr，然後這三個小時我的 FB 牆上寫了滿滿的髒話....

我每次修 Discourse 程式碼或改他們的架構都會覺得他們腦袋是裝屎。

（很抱歉，貢獻程式碼的人都很偉大，照理說我不應批評貢獻者，甚至不應批評人家腦袋裝屎，但實在是大多數的 Rails Developer 去改他們程式碼，半個小時候就會想罵這句話....）

什麼都自幹，login 也自幹，權限系統也自幹，deploy 架構也自幹，search backend 也自幹。自幹就算了，全部都是用錯的想法在想解法，連帶解法也是大便。然後就蓋起一座大便之塔 -_-

Discourse 是目前 Opensource 界相當受歡迎的一套論壇軟體。通常用來架設技術社群專屬討論區。

Discourse 官方目前的推薦部署模式目前是採 Docker，直接在 Digital Ocean 部署。這個方案可以少去很多不熟 Rails 的人安裝上的求助需求。

但也大大限制了社群未來想 patch 功能的自由性。（社群貢獻代碼和功能的方式，通常是透過 Github Fork 原始碼，拉 pull request 回去，而用 Docker deploy 的架構，很難讓想幫忙的人直接插手）。

而 Discourse 的設計與架構，也與傳統在設計 Rails Application 的做法大大不同（其 Anti-Pattern 真是多到令人髮指）。一般的 Rails Application 都是會設計成使用 capistrano deploy，然後 config 拆開另外放。這樣的好處是 source code 可公開，可讓人自由 fork，config 的敏感資訊又不會被泄露。

這篇文章就是一個引子，讓有心想使用 Capistrano 架設 Discourse 的人可以找到線索架設。