10. 大會其他細節
售票
大會這次在會議前舉辦前四個月前 CFP，還是使用 Eventbrite 這個售票網站。
不過值得一提的是 2012 是使用 Eventbrite App 進行報到，今年則是用紙本。顯然紙本反而速度快太多。
CFP
這次的 CFP 選拔過程極度的的專業，關於 CFP 方法，我前一兩個月寫了另外一篇文章記載方法與過程：由 RailsConf CFP 2014 談客觀的海選辦法。
大會網站 / 議程表 / 大會 App
這次大會網站比較沒有什麼亮點，就是蠻精緻的官方頁面。但是值得一提的是大會這次採用了 Guidebook 作為大會指南 App。找議程排自己喜歡的議程非常方便，而且整合了 Twitter，方便追大會公告以及場上動態。
Guidebook 介紹請見我另一篇文章：GuideBook - 製作大會電子手冊的利器
贊助廠商和食物
今年食物區和贊助廠商 （Exhibit Hall）是分開的區域。不過大會用了領 T-shirt 和 HappyHour 這兩個招數逼大家一定要進到 Exhibit Hall 才能領。所以也是會被逼迫逛一下。
不過贊助廠商區還蠻好逛的。因為今年擺攤的都不是無聊的攤位。Code Climate 和 Code School 都有來。大會也有開放 NGO 擺攤，如 Woman Who Code。
不過這裡要小小抱怨的是，贊助商的最小 package 竟然是 15000 美金。真是有錢的公司才玩得起。
11. 贊助廠商觀察
廠商分佈
今年與贊助商的互動與 2012 年就顯得相當薄弱。
(1) 贊助商比較像是義氣來挺的，其實都是社群人創業公司比較多。所以擺攤位來聊天的比較多。連 EngineYard 有擺攤但就沒像之前一樣送東西。
(2) Hosting 贊助出奇多，這次贊助廠商有 RackSpace、EngineYard、Heroku、Digital Ocean、Linode、Ninefold，而且而且竟然有 Godaddy !!!(BTW，他們竟然也徵 Rails Developer)
(3) 做量測工具的公司顯然很賺錢：New Relic、Tilde、Code Climate。（我會這麼說是因為能夠擺攤的最低門檻的贊助金額是 15,000 美金啊...）
(4) 最有錢的是一艱新的獵頭公司：Hired。他們包下整個展場最中心一大塊，搬來四台 60 吋電視讓大家打電動...。Hired 是做人才競標的。
之前這種展覽都是招人比較多，今年就是聊天比較多而已。
12. 大會工作人員
這麼強的大會工作人員幾個人呢？讓人驚訝的是...六個。
(你要想想這是1500人的世界級 event，所以真的超屌的。而且專業程度要求很高，要知道會來這種大會的幾乎都是世界各地 Ruby Group 領導人，社群大神，等等....)
組成成員據說都是大神們的老婆團XD。RubyCentral 主席的老婆，Yehudaz Katz 的老婆.....
老婆團真的很強悍。我去過幾個外國 Conf，幫忙弄住宿和回問題的都是主辦人老婆 ＸＤＤＤ
綜合感想
我實在覺得 RubyCentral 實在太強了。2012 年是 RubyCentral 接回來自己辦的第一屆，這次是第三屆。第三屆的充實程度和豐富程度，遠遠在第一屆之上。
像我最在意的「大會議程內容」方面，就完完全全沒有讓我失望。少了許多社群大拜拜味道，地雷 track 少非常非常多（就算有也容易避開，起碼大 room 的沒有一次是雷），場場都是十分前沿和紮實的 Talk。
再來是 workshop，我也翹了一些議程跑去 workshop，之所以會做這樣的決定是因為大會有僱用 Confreaks 團隊對每場 Talk 進行錄製（每場 Talk 都有三台錄影機在錄以防出包）。但是 Workshop 只有一台，而且多半也不會會後釋出，在幾經考慮下就決定去參加 Workshop 了。
2012 年我不去 Workshop 的原因是因為 Workshop 拜拜性質居多，都是給新手去的場。比如說 CodeSchool 教 Rails 基礎，一些講師教非常基礎的 Rspec 語法和 TDD 入門。
這次的 WorkShop 內容的等級至少都是要有 Rails 2-3 年以上從業經驗的人才適合參加。
而且這些 Workshop，外面自費參加一場（講師多半有自己辦工作坊），價格大概就不止大會票價 750 USD。所以非常非常的值得。
2014 Rails Conf 要說這是我進社群以來參加過最棒的 Conf 也不為過了。
我在這個大會實在學到非常非常多東西。這三篇系列文只是一個綜述，我會再開幾篇寫 Keynote 的心得綜述和 Workshop 的筆記。可能要寫十篇都不為過。
RailsConf 2014 - 十週年紀念版系列文目錄
前幾天 DHH 又補了一篇 Test-induced design damage 和一篇 Slow database test fallacy 。
這場世界大筆戰想追的人，可以看好心人整理放在 Evernote 上的 DHH：TDD is dead. Long live testing. 系列懶人包。
我個人再補充一些為什麼會有 Test-induced design damage 這篇文章的背景導讀。（很多人沒有追 Rails 生態圈追那麼緊不知道這篇的時空背景）。
所以這場世界大筆戰有時會看到張飛打岳飛的狀況(特別是根本一直狀況外在跳針的 Uncle Bob）。
張飛打岳飛？
DHH 其實很清楚的抓幾件重點：
- TDD 不能幫助你「創造」 Software
- TDD 有可能害你不小心沈迷於設計 unit 細節
- 過於設計 Unit 細節，接下來就會不小心執著於 Test 要跑得非常快
- 想要跑得非常快，所造成的 by pass 手法，會把系統搞得更複雜，傷害原始設計。到了該步田地，也無需再使用 Rails。
（我之所以講 Uncle Bob 張飛打岳飛的原因是，Rails 生態圈是演化非常快的 opensource comunnity。因為這個生態圈和工具太健全，所以軟工演化的速度和失控程度，不是其他社群可以想像的。）
DHH 會抱怨這一些事，是過去這一兩年來，他已經被捲入無數次的戰爭裡，現在爆發只是剛好而已。
Rails 社群對於 TDD 的著迷以及病態發展
Rails 在過去兩年，針對這個議題，比較著名的總共有三篇教學論述
- Object on Rails 主打你應該從 Object 設計起。把整個邏輯封裝在外，再掛進 Rails 。
- Rails is Not Your Application 主打你應該採用 DCI 設計手法，掛進 Rails。
- Implementing the Repository Pattern in Ruby 主張你應該將整個程式用 Repository 模式設計，再掛進 Rails。(本次 Railsconf 有開 Workshop，我剛好有去聽，但是這場 workshop 是一場災難...）
這三種方法主要目的都在解成幾件事：
- 更好的用 Ruby 、物件、Pattern 敘述業務
- 將主要邏輯層抽離 persistent 層，可以巨幅提升 test 運行的速度。
當然這幾種寫作方法，設計出來的 code 都非常優美，像藝術品一樣。一般開發者一見就會傾心，但實務上它們徹底不實用。
因為：
- 很多 application 在需求一開始開出時，是無法用這種模式開始設計的（需求不清不楚）。這就造成了困難一。
- 能夠適用這三種開發手法的 application 通常是中央 bussiness 已經接近固定，才好抽。果一直要變動，用這樣的手法設計再一直疊加邏輯上去，會反而造成太多不需要的抽象 layer 夾在中間，造成設計上的困擾。
- 太多不需要的抽象 layer 反而造成效能下降。
- 有把設計變簡單嗎？恐怕變得更複雜。
- 搞成這樣你還寫 Rails 幹嘛? Rails 的優勢（開發速度以及架構調整能力）都不見了
這是為什麼 DHH 後面補那兩篇文章的原因。因為 Rails 社群玩 TDD 和玩架構設計玩到失控了....
因為國內學習 Rails 始終有很高的需求。最近我決定跟幾個台灣 Rails 的社群朋友，近日開始舉辦一系列的新手推廣 Workshop。
- 課本教材：新手教學 Workshop 將會採用 RailsBridge 的官方教材 Intro to Rails
- 助教：多數助教皆是國內資深 Rails Developer
時間場次：
5/17（六）台北場：http://tw-rails.kktix.cc/events/rails-outreach-taipei-01
5/31（六）台南場：http://tw-rails.kktix.cc/events/rails-outreach-tainan-01
歡迎報名。高雄場正在研擬細節中，也將於近日開設。
若有社群同好想應徵台北場助教，請透過此連結報名：http://tw-rails.kktix.cc/events/rails-outreach-taipei-01-coach
FAQ
- Q1 : 這個活動要收費嗎？
- A1 : 此活動免費。但開放「晚報名的人」購買個人贊助票，贊助活動開銷（一人2000）。
- Q2 : 你們多久會辦下一次？
- A2 : 我們希望每 2-3 個月可以循環辦一次，視人力與當地助教時間而定。（下一次台北場時間為 7/19 ) 。如果你真的等不了那麼久的話，可以自己先嘗試 Railsbridge 教材，再到 Taipie Rails Meetup 找前輩請教，我相信他們都會很樂意回答問題。
- Q3 : 你們未來會推出付費的課程嗎？
- A3: 我個人會開始籌備一系列付費的課程（程度可至獨立開發網站以及求職水準），請密切注意本 blog。
DHH 在 RailsConf 上面對到底要不要 TDD 開了第一槍。雖然引來很多爭議，我認為這是一個非常好的開始。
因為以 DHH 的地位，我認為他是說「我不 TDD」受到的砲火（大家會認為不TDD＝不會寫程式）最小的人。當然，他說這句話，引到的其他砲火更猛裂。
但這真的是很好的出發點，讓其他人開始敢說真話以及思考其他可能性。
設計軟體的重點：好讀、易維護、以全局觀點思考。
很多人都是被以「我不 TDD」的爭議點吸來看這篇文章的的。但要繼續讀下去之前，我希望你先做兩件事：
- 上 Justin TV 把 DHH 整場 Talk 看完，在看的時候請把「這場 Talk 是講 TDD」預設觀點拿掉（我們聽現場的人，在進行到一半之前是完全不知道他會扯到這件事的）。
- 看完 DHH 對於 TDD 的論述。（有人翻譯了這篇文章 ）
DHH 的這場 Talk 要傳達是「設計軟體的重點：好讀、易維護、以全局觀點思考」。
而不是「我不 TDD」。
而之所以他會選擇「我不 TDD」為出發點，是因為開發者被許多開發上衍生出來的技巧和觀念所綁架了。而且衍生出很多似是而非的偏見。
在軟體界你應該聽過很多指控，如：
- 「不 TDD」 = 「寫 Code 很遜」
- 「不會寫 Test」= 「寫 Code 很遜」
- 「不使用 Design Pattern」 = 「寫 Code 很遜」
- 「不 TDD」 = 「假 Agile」
- 「不想用 Scrum」 = 「不 Agile」
- 「覺得 Scrum 沒有用」 = 「你一定沒有受過 Scrum 完整教育，沒被好的 mentor 帶過」
當然，最大條的當然是「不TDD」，只要哪個 Developer 說他開發時不 TDD，別人一定會質疑他根本不會寫 code，功力是假的。
所以這樣的 false claim 由神人 DHH 出來坦強力反對，當然是最好的。
Developer 的聖杯：功力完霸所有名詞
上面寫的這麼多條指控是真的嗎？
在某些人某些狀況是真的，但是「絕大多數時候」 *不成立*。
這樣講，大多數人可能很難接受。
我想以這樣的角度去切入，一個 Developer 從入門到資深，由產品實作到產品架構設計必須要學習的技能以及標準：
＊＊＊
（以用 Rails 開發產品為例）
- （前）入門者：學習必備的工具，如 Git, Command Line, CSS / HTML 。
- 入門者：學習 Rails 基本的 API、工具、第三方套件，設計出「可以動的程式」。
- 入門者（後）：學會 Ruby 比較進階的議題，學習寫出改得動的程式碼，以及如何寫出佈 Abusing Ruby / Rauls 的 code。能夠自己獨立做完一個小型 project。
- 一般 Developer：學會封裝（method/Class），ORM 優化，效能優化，前端優化，基礎 Testing 技巧，基本 Security。
- 進階 Developer：TDD，基本 Design Pattern 技巧，Gem 封裝，Rails advanced API 使用。能夠自己獨立做完一個中型 project。
- 資深 Developer：TDD with Testing Pattern、PORO Design with Rails、SOA、大型站台 Scaling、大型 Gem 設計。
（完成所有的課題大概需要 5 年以上時間，因為很多東西是需要「大量」「實作」才能得到經驗值。）
其他還需要學習的有：如何跟其他人協作（設計 API 以及最不阻擾大家的工作 Pattern 與 Pattern），專案管理（如何控管進度，學會切票以及抓大放小），基本 Agile 技巧，溝通技巧（如何以有效的方式說服同事、老闆、Stackholder 採取方案）。
＊＊＊
所以「不 TDD」 = 「寫 Code 很遜」。「不使用 Design Pattern」 = 「寫 Code 很遜」。在對資歷淺的 Developer 是成立的。因為這跟 Developer 程度與開發技巧層面有關係。
而 Developer 的終極浪漫往往是練完這些名詞，並且在一個 Project 裡全部用上這些字。誰擋在自己面前，就一定幹掉對方。
到達終點才知道夢破碎
但是最殘酷的現實是，當爬到最終點時，Developer 才會意識到一件事，這件事情是不可能辦到的。
因為學完所有名詞時，幾乎也會站到 Architect 這個角色去。才會發現幾件事：
- 除非專案有無窮的預算，否則你不可能無止盡的砸時間在軟體工程上。
- 如果專案有無窮的預算，你的產品也不可能成功。太多的官僚 PM 會湧入，太多的「想做到更好的念頭」「太多的產品決策樹」，會把上線的時間無窮往後延。無法上線的產品遠比沒有好 code 的產品糟糕太多。
- 身為一個 Senior / Architect 更重要的事情是「在有限的時間做出『相對好』的決策」，這些決策可能意外著可能要逼著自己或手下寫出 work-around、no-test、not-tdd、ugly code、slow-query，許多會被 developer 鄙視的 anti-pattern。
這就是所謂的抓大放小。
Architect 的兩難
而抓大放小，還會造成更多的麻煩。因為 Senior 平常會逼著 junior developer 學他們應該要的技術。但是你卻無法跟他解釋為何你「現在」要用這些 anti-pattern。因為他們無法連什麼是大，什麼是小都不知道。如何理解什麼是「抓大放小」？
Senior 希望 Junior 不要用 anti-pattern，但必要時又必須自己用 anti-pattern 解決這些問題。用久了這些 junior 還會以為自己老闆根本不會寫 code。一天到晚互相矛盾在打自己臉。
這就是 DHH 所說的「被名詞綁架」。你要做事和討論，雖然用正確的手段。但卻完全無法被放入場景，而且整個氣氛氛圍還會變成：一講出這些話，還會變瞬間貶低為「Amature」（完完全全的政治不正確）。之後相關議題完全無法展開。
所以他選擇開這個第一槍。
Testing / Design Pattern / TDD
Testing
回到 Testing，為何我們要學 Testing，是因為 Testing 可以帶給我們更 Solid 的程式。這在需要長久維護、或者是需要多人協作、牽扯外部第三方元件的程式中至關重要。
可以有效降低開發及維護成本。
Design Pattern
為何我們要學 Design Pattern，是因為使用 Design Pattern 技巧，可以讓我們的程式在某些情況下，相對的更好維護。只要修改小部分的程式碼，就能利用界面擴充出出更大型的程式。
TDD
為何我們要學 TDD，是因為 TDD 可以逼一個 Developer 以開端解 Fail Test 的方式，去「設計」出一支不容易 Fail 的程式（多數情況下，不容易 Fail 等於設計出正確的功能，也正常作用）。
同時，採取 TDD 的方式，且想要寫出品質好且「好測」的 Test，會逼一個 Developer 去思考如何做出好的物件、界面、封裝的設計。可以更深層的了解 Design Pattern、PORO 技巧的美。
所以 TDD 是一個非常好「學習寫進階程式技巧」的方式。
But why not TDD / Design Pattern ?
但為什麼很多 Senior 開發者 TDD 到最後卻選擇性放棄 TDD。是因為 TDD 會造成過於注重 unit 形式的設計，而忽略整體系統架構的設計。（這也是 DHH 所談到的主要 issue，每次他回去認真 TDD，寫一寫又覺得不對勁。但 TDD 不對勁這個議題又幾乎被氣氛綁架到幾乎形同禁止討論）
而且 Senior 對於 TDD 的看法多半是：TDD 適合用來作為「已知解決手法，但有可能過程複雜容易出包」的程式。使用 TDD 可以有效降低爆炸機率，提升開發效率。
但對於「未知解決手法」的程式，使用 TDD 反而會造成效率下降。因為反而會花太多時間在處理 unit 本身，而不是專注於 system 本身的設計。
＊＊＊
Design Pattern 其實也面臨到相同的狀況。太早 Design Pattern 開下去，當系統要快速迭代變更設計時，原先的 Pattern 甚至或當場「絕對不適用」。
結論 : 好讀、易維護、以全局觀點思考
既然這些高階技巧不適用。那麼我們又該何去何從？
我個人的觀點是，這又掉進了同一個思考誤區。把所有人的所有狀況，看成一種人一種情況：
- DHH 說不是每次都要 TDD。不代表你應該不 TDD。
- DHH 說希望更專注 System Design Test。不代表你應該以後只做 System Design Test。
- Kent Back 說不是每次都需要寫 Test，因為人家付錢給我們是要買程式。而不是買 Test。如果你怕你程式容易爆的話，應該下班偷偷補 Test。
（因為你不是 DHH，你也不是 Kent Back，你現在不是面對他們所面對的問題。更見鬼的是，你也不是他們那層神級開發者的程度。）
他不希望大家聽他講一講，又跳進只專注 system design 的另一個聖杯去。
DHH 整個演講穿插的幾張綠色主題投影片，我想就是一個非常好的 Geneanal 準則（適用各種 Level）。其實你不應該被任何名詞綁架，而應該以這三點：「好讀、易維護、以全局觀點思考，為基準點」去設計你的程式。
（RailsConf 另一個講者的 Sandi Matz 的 Talk 也很精彩，他也提到了用錯誤的抽象封裝比正確的複製貼上 code 還要來的糟。）
不學 TDD 不知道要放棄 TDD
另外就是別因為誰講什麼不用做。就放棄去學什麼。
每一個 Level 都有自己應該要學的課題。
不學 TDD，也不可能一直領悟進化到（可以）放棄 TDD 這件事。
他也鼓勵大家「多寫 Software」，只抱著 Pattern 的書是無法幫助你成為一個厲害的 Developer 的。
＊＊＊
這真是近年來罕見的一個精彩 Talk （雖然看不懂的可能就是看不懂..還會覺得是垃圾）。
我真的推薦大家「多看幾遍」。
6. Keynote
DHH: 戰 寫 code 太多規矩，跟減肥一樣，是大謊言。還有不 TDD 無罪。
今年的第一天 Keynote 照例一樣是 DHH。不過今年跟往年不一樣（每年他都繞著彎宣布 Rails 下一年的方向）。今年不是，今年他整場 Talk 可以以一句話貫之:「我叫 DHH，我不 TDD」。
影片網址：http://www.justin.tv/confreaks/b/522089408
（超級戰的 Talk ....XDDDDDDDDD）
演講結束的隔天，他也寫了一篇文章： TDD is dead. Long live testing. 更加詳細解釋的想法。
有人也抓住機會，在他演講後馬上抓到他對他做訪問：http://www.ugtastic.com/david-heinemeier-hansson/
（之後我也會寫一篇文章關於這個主題，請期待）
＊＊＊ 當時筆記的重點
翻譯摘要一下今天 DHH 的重點（其實也是一個蠻引戰的 summary，如果你沒有想透很多 context）：
簡單的說，DHH 希望大家回歸本質。重點是寫的 code 需要「發揮作用」，寫得清楚易懂好維護。不要為測而測。TDD 反而是破壞系統 Design 的元凶。會使人們更 focus unit design，而不是整體的 system design。
Test 的 ratio, coverage, speed 能夠被很容易的量測，但並不代表他們重要（相對全局來說）
但這並不代表是你不應該放棄測試，只是應該放棄 TDD。剛好的測試是重要的。清晰透徹的整體想法設計是最重要的，而且這只能透過 讀 / 寫 軟體做到。而不是背和練 pattern。
＊＊＊
這個 Talk 連續講了一個小時多。講到大家都快崩潰了。結果下午就有人在 Twitter 上貼了一張神圖。說明 @wycats 和 @tenderlove 同時間對此 Talk 的感想。快讓人笑死.....XD
Yehuda Katz : 「限制」可以讓大家寫 Code 更開心
Yehuda Katz 這次的 Talk 是用很長的篇幅敘述了為何 Rails 能讓開發者開心。以前所謂的 Convention over Configuration 被講爛了，而且不是重點。重點是 Rails 的 Default 設置其實是一個心理學的關鍵，減少人腦做決定的機會，讓人腦運算續航力下降的速度變得非常慢。這就是為什麼 Rails Developer 生產力很高的緣故。
Aaron Patterson:
（待補，因為大會還沒結束）
非技術 Keynote:
從以前到現在都是垃圾，不用聽。
Ruby Hero Award
今年以獎勵無名英雄為主。比如做很多 Gem 的開發者。Rails Contributor 神人。Kids Ruby 的主辦人等等...
7. Lignting Talk
今年Lightning Talk 有被放進官方議程中。而且水準超高的。
第一場就是一個女生改編 Let It Go 變成 Let me Code。超級屌。可稱是本屆 RailsConf 最神表演，大家起立鼓掌長達一分鐘。
其他我比較喜歡的還有：
- Rspec Formater : https://github.com/CodingZeal/super-star-formatters/blob/master/dhh_formatter.rb (跑 Rspec 可以跑出名人對話確認，DHH 的害我笑到快死了）
- Tokaidoapp 做了兩年終於 Release 了 https://github.com/tokaido/tokaidoapp/tree/1.0 蠻屌的可以自己蓋一個 Ruby 環境還自帶類似 Pow 的東西
- 自幹魂 ifttt https://github.com/cantino/huginn 非常神的作品
- Demo 如何 25 行用 Rails API 實作 Rails
After Party
今年有四天 Conf，但卻沒有官方的 Offical After Party，而是大家要辦 Party 的自己去辦。所以同時間會有很多不同廠商的 Party 散在各處。
所以我當然是去參加最潮的 Basecamp 的 OpenHouse Party。
還不要臉的去跟 DHH 索了一張合照 XDD。
值得一提的是我在他們辦公室拍到一張超屌的海報。
＊＊＊ （笑點解釋）
37 Signals 的 Founder 是 Jason Fried，Partner 是 DHH。他們出了一本書叫 REWORK。
這張海報是大惡搞。首先是標題被改成了 REVOLT，副標是講兩個特立獨行的人主宰了矽谷。右邊的男生是 Grey's Anatomy 的男主角 Patrick Dempsey，曾經是 200X 年好萊塢最性感男人。（Jason Fried 長得有點像)。
左邊是 201X 年好萊塢最性感男人，True Blood 的 Alexander Skarsgard，瑞典人。(DHH 是丹麥人）
所以看到這張惡搞海報被掛在 37signals 辦公室我就笑到快死掉了。
＊＊＊
（改天專文再寫 Basecamp 遊記）
9. 大會白板
大會現場這次只有準備一塊白板。當社群告示板（ hiring , contest, announcement…etc)
RailsConf 2014 - 十週年紀念版系列文目錄
Rails 2014 今年回到 Rails 的發源地 Chicago ( 37Signals 所在地) 舉辦，參與者高達 1500 位 Developer（票全部賣光）。跟以往不同的是，這是一次長達四天的 Conf，因為是 Rails 10 週年紀念版，機會難得，所以一定要參加。
兩年前我有寫過 2012 年一系列的 RailsConf 心得：
- http://blog.xdite.net/posts/2012/04/25/railsconf-2012
- http://blog.xdite.net/posts/2012/04/25/railsconf-2012-2
- http://blog.xdite.net/posts/2012/04/25/railsconf-2012-3
這次也會參考類似的格式寫作。
1. 大會地點
這次大會舉辦的地點在芝加哥的 Sheraton Chicago Hotel & Towers。跟往年大會一樣，都是直接租大型飯店和內設會議廳。
這幾年我去過非常多國外 Conference，發現這樣做有很大的好處。
- RailsConf 這樣大型的 Conf 會有很多外籍旅客，辦在旅館可以省下很多接待人員。
- RailsConf 的議程非常多軌，強度非常高。一天聽下來幾乎就趴了，還要走回其他的旅館很容易讓人崩潰，位置放在一起是最好的 Solution。
- 飯店通常在鬧區，走出去就可以有很多地方可以逛。
- 飯店很常承辦大型會議，所以會場 Wifi 不需自備網路組出動架線。像這次大會的網路就超級變態的，1500 人同時連，網速都沒垮。
- 飯店大廳有酒吧和交誼廳，所以有 endless 的 after party 到處可以開花。
2. 大會場地
跟 2012 年一樣，大會租了一個大 Ballroom（真的可塞1500人），幾間中型會議室。大的 Ballroom 在 Keynote 時會合併使用，其他 Session 就會用隔板切開使用（飯店工作人員會幫忙弄）。
講台跟往年一樣是標配，講者站中間，兩旁有螢幕方便看投影片。聽講最輕鬆的方式其實是在兩排螢幕前的座位大約第五排左右的位置。
座位、電源和網路
網路超強。幾乎都沒有爆炸。就算人太多也都還算勉強能動。至於中小會議室是幾乎每條走道都會有插座。不過大型場地就反而沒有鋪線。
不過這年頭幾乎每個人的電腦都是可以 12 小時的 MBA，背包裡面隨時放兩顆行動電源，所以也幾乎沒在怕。
Wifi
旅館 Lobby 的網路很快，房間的網路很鳥，而且還要 13.95 美金 :/
因為這種畸形的狀況，所以很多大神都會被逼到在 Lobby 遊蕩喇賽 (因為大廳 Wifi上網很快），反而容易找人。
3. 食物
美式食物真的不太合亞洲人胃口。不過這次在芝加哥，大會食物比在 Austion 的時候好很多。多半都是準備義大利類型的食物。熱狗，漢堡，沙拉之類的。算蠻能吃飽的。
在芝加哥基本上就是一直肉肉肉肉肉肉肉肉（雞肉之類的）。算能夠吃飽。
不過第三天時出現了神秘的高級牛排吃到飽。
4. 報到
今年沒有 Conf 前一天的活動。大概是因為有四天 Conf 的關係吧。所以 Lighting Talk 就變成正式議程了。很多人都是前一天晚上放心的在芝加哥大玩特玩。
報到跟 2012 不一樣，基本上是用紙本查 XDDDDD
速度比之前用 Eventbrite App 快太多了。
手冊一樣很精美。而吊牌跟上次不一樣的是多了一個 QR Code，方便大家交朋友和廠商收集個資用的（逃）（Happy Hour 的 Sponsor 要掃描 Code 才讓人進去）。
背袋裡面還有送一整包 Tilde 自家的貼紙。（Tilde 就是 Yehuda Katz 的公司，他們公司的貼紙都很值得收藏，因為都是他的 OpenSource 作品貼紙 wwww）
至於 T-shirt 是到第二天下午才在「贊助商展覽場地」發，目的是強迫大家去參觀贊助商攤位 wwww。
5. 議程安排
今年議程有高達 5 軌這麼多！！！
Theme Track
今年新加入的特點，就是有 Theme Track，比如說會有 Big Rails Track（一整個 Room 整天都是談 Big data Rails)、Designer Track（整個時段都是 Designer Track），還有 Crafting Code、Team Development、Teaching 之類的。蠻好玩的。
Sponsor Track
Sponsor 一樣會被關到自己一間 Room 自己去講。不過 RailsConf 的 Sponsor Talk 基本上會跟其他 Conf 的 Sponsor Talk 不一樣。Rails Conf 的 Sponsor 通常都很強，也都會找大神出來演講或直接做 Panel Discussion。
Workshop
這次我最喜歡的就是 Workshop 了。因為 Workshop 是最不可能錄影釋出的 session。所以我甚至翹了某些 Session 去 Workshop ...XD ( 反正 Confreak 會有錄影）
有一場 Refactoring 和有一場 Elxir 的都超精彩。
這次跟往常不一樣的是，都不是「初學者」等級的 Workshop，會教 Refactoring、Elxir、Rspec Pattern、Javascript Game Testing 這種高級技巧的課。
所以我覺得大會實在超賤的啊，每天都讓人糾結。
BOFConf
都不喜歡的講題還有 BOFConf 可以參加，基本上交流方式就是大會開幾間房間讓大家自己填主題亂聚。結果 TenderLove 開了一間房間揪人打桌遊...orz
RailsConf 2014 - 十週年紀念版系列文目錄
這篇是遲來的遊記。
上個月（學運期間）我跑去菲律賓參加 RubyConf PH。參加這個 Conf 原本今年是不在我的計劃中的。但是過年後在排本年參加 Conf 計劃表的時候，不小心逛到（菲律賓今年是第一次舉辦）。考慮了一下，就決定跑去參加。
（主要還是因為機票 6500，非常便宜。就決定去看看）
在去之前，其實我邀了不少朋友一起去。不過每個人都委婉的拒絕了我。（大概是覺得菲律賓可能技術遠後於台灣之類的，幹嘛去浪費錢...）
在到達菲律賓之前，其實我對當地的印象也是如此（逃），所以只是想趁週末去了解一下菲律賓當地是怎麼回事。但是兩天大會下來，簡直是跌破我的眼鏡...
1. 大會地點與票價
這次舉辦的場地在馬尼拉市的達義市的 SM Aura，大會推薦的旅館是在會場附近的 Soda Hotel(一晚 PHP 5500)。兩天門票是 PHP 9000 ( 折合台幣約 6300)
在去之前，我的感想只有好貴好貴好貴....XDD （覺得菲律賓應該要比較便宜啊...）
一到了當地我才知道為什麼。
首先馬尼拉市的達義市，可以想像大概是相等於台北市的信義區，SM Aura 可以想像成是豪華和闊氣三倍的（信義威秀 + 微風廣場）。
大會會場 SM Aura
大會推薦住宿 Seda Hotel
Seda Hotel Level 大概可以直追寒舍艾美。
達義市網路上可以找到一堆照片，完爆台北市信義區好幾倍。每個地方都有超美的天際線，規劃整齊的商場和市容，林立豪華的商業大廈、兩層樓商場、以及公園。美的不竟勝收。我都不知道台灣有哪一塊地方可以這麼威...（不過美中不足的是大眾交通不怎樣）
SM Aura 是一個超大綜合商場，3F 與 4F 有 1/3 是會議型專用場地。大會租下一半的空間舉辦會議。
.jpg)
SM Aura 頂樓則是很多高級 Bar 以及餐廳，中餐和晚餐就直接可以上樓去吃（如果不喜歡大會食物的話）。
2. 大會場地與參加者
大會租了 3F 一個大會議廳，和 4F 兩個小會議廳。
大會是單軌 Conf，所有的議程都是在此進行。今年參加者目測大概是有 ~200 人。（網站上原先是保守的宣稱想賣120張票..）
兩個小會議廳是給晚上的 BOF 和 Workshop 所使用。
座位
超級長的演講聽排滿了桌子，一張桌子大概可以坐 6 人左右。每個桌子下都有延長線可以用。
網路
值得一提的是目前我去過的其他國家 Rubyconf，大多都是租商業場地，而且這些商業場地的 Wifi 都非常給力，非常非常順暢。（不需自幹）
贊助廠商
RubyConf PH 的贊助商很神秘的都是外國大廠，Engine Yard，Github...等等
食物
這點跟多數的 Conf 一樣，都是叫外燴在場地自助餐。
精美 Badge
這大概是我拿過做得最棒的大會 badge 了...
3. 講者和講題
講者幾乎都是國際和亞洲的一時之選，日本的 @_ko1，德國的 @aptonick，新加坡的 @winstonteo，Enginyard 、Github、Percona的講者...
我在這個 Conf 學到不少東西，包括
- 菲律賓的講者談他在菲律賓各地 build workshop 教入門者的經驗。他在菲律賓辦 Workshop 和教新手的心得。講的非常精彩。
- Engineyard 的講者談他在美國和英國建當地社群的經驗，而且還分享了他女兒的少年程式俱樂部...XD（他女兒是美國 Rubyconf 的講者，他說他嫉妒死了）
- Nick 分享了非常互動式的 Code Refactor 的技巧和過程，令人歎為觀止
- Percona （MySQL 社群大廠）的講者分享 MySQL 在 Rails 上的 Tuning
其他講者背景有
- travis CI 作者
- bundler 維護者
- Ruby core maintainer
- Reddot Ruby Conf Organizer
4.參加者與講題之外的 Workshop
講者部分等級其實與 Reddot Ruby Conf 差不多。不過讓我驚訝的是參加者。
- 不少參加者都是從外國飛來的，不少白人面孔。我有聊到的：印度人、義大利人、新加坡人、日本人。
- 女性參加者至少有 1/6 以上。很多女 Developer。而且都不是湊熱鬧的新手。（我的 lignting talk 完之後，有女 developer 竟然很感興趣，跑來問我可以去哪裡 contribute ）
- 菲律賓的 Rails Developer 工資平均在台幣 30,000-60,000 左右。一張票 6,300 台幣竟然還有這麼多人報名。
Workshop
Conf 前有兩場 Workshop：
- AWS with Rails
- Rails Bridge Workshop
我就被分配到教一個女 Developer 寫 Rails。旁邊的男 Developer 感到很幹...XD
來報名的女 Developer 至少都有基本的 HTML / CSS 開發程度。
第一天的晚上也有 Hackday Workshop。這場的主題就比較讓我吃驚，因為主題是：
- 如何 Contribute to Rails。
這個 Workshop 就至少有 20-30 人以上參加...
After Party
前一天的晚上有 Welcome Party，第二天晚上有 After Party。不過我都有事沒有參加到，內容就不知道了。
感想：別人已經上太空，我們還在殺豬公
那幾天剛好馬卡茸還在扯「不簽服貿，我們已經輸韓國十年」。我內心就浮現很深沈的悲哀：什麼輸韓國，我們已經輸菲律賓了你還不知道。
去過亞洲的大都會（新加坡、北京、上海、馬尼拉、東京），我都還在想，如果有一天在臺北辦國際等級的 Conf 交流，別國、特別是東南亞 Developer 來臺北會不會嫌我們都市破舊和到處亂蓋。
菲律賓 Conf 的內容和安排水準，更是一流，是目前我參加過的亞洲 Conf 內容數一數二的。
在馬尼拉讓我更震撼的一點是：正當我們自以為台灣人力便宜，歐美矽谷會選擇來台灣蓋第二開發基地時，事實上他們都已經紛紛跳過台灣，直接在菲律賓設據點了。
原因很簡單，人家菲律賓的美語是 Native 等級，而且工資還比台灣低。（不過菲律賓和越南的開發者工資也快接近台灣了）。歐美的開發 Culture 還可以直接平行輸入無障礙。
Engine Yard 的 Operation / Support Team 其中之一就設在菲律賓。
幾個標準：國家建設、社群平均水準、講題深度與廣度、Conf 內容安排、英語水準。
我們真的要好好思考，我們的競爭力在哪裡。
＊＊＊
前陣子我在翻馬尼拉的資料。意外發現連政府網站他們都比較高級...orz
- 馬尼拉市官網 http://manila.gov.ph/
- 達義市官網 http://www.taguig.gov.ph/
＊＊＊
剛剛收到消息，Rubyconf PH 2015 在長灘島舉辦，真是太帥了。https://twitter.com/rubyconfph/status/459344833509736450
這次到 RailsConf，@huacnlee 介紹了我用了這個神奇的玩意 Guidebook。
真的非常非常的方便。像這次 RailsConf 的議程在 Guidebook 上也可以下載。
整合多項會議資料
大會或者是有心人只要上他們的網站，編排會議資訊，其他人下載會議資料之後，就可以很快的掌握大會所有資訊了。這個 App 整合了議程資料、Twitter、最愛議程、地圖，等等。
支援多種 Device
而且還支援不同 Device。iPhone, iPad, Android ...等等當然都是在支援列表內。
以前都不知道有這種東西，這東西看起來這麼方便。
看起來以後 Conf 就不用費心找人做大會 App 了....
原文摘自我的 FB。很多人問要怎樣「正確」跟工程師相處，以下是我的回答：
====
1. 不要把工程師當「得來速」，隨便點餐。
工程師正確的用法要這樣用：
今天如果你有一個問題，你就直接跟他講你有什麼問題，有沒有辦法設計一個方案解決。工程師強的不是你以為的寫程式能力（這個另外討論）。而是他比你強的「工程角度」解決問題的能力。
你跟他講你有什麼問題，有一定能力以上的人可以很快就幫你想想出正確的 workround。甚至還親手幫你做好。
切忌逼他寫你心目中想要的程式，他只會覺得你智障然後繼續回去打 diablo。
2. 不要沒把解決手段想清楚就把問題扔給他
有的時候，那個問題不是純工程角度 workround 可以解的。而是必須從實體角度去切入，程式去輔助自動化。你必須先想清楚，實體你打算怎麼做。
「我想上網開店賺大錢」這種 request 你丟給他。他會直接永久靜音你的 FB 對話。
不要以為他是蠢。工程師在問題出現前 8 個小時前就可以看到問題，三秒鐘就可以判斷到底要不要做。人家聰明的很。後知後覺的是你。
3. 不要跟他講什麼「應該很簡單」
「應該很簡單」只有「Senior Developer」才可以跟 「Developer」講的。其他人沒資格講。
你應該要跟 Developer 說，這個問題有一點挑戰，你不知道找誰。
你跟他講「應該很簡單」，他內心會直接跟你這個人絕交。
4. 請他吃高級燒肉
我還沒遇過工程師不喜歡吃燒肉的。吃燒肉友誼點數大概可以灌 3 倍速度。
＊＊＊
以上是工程師相處指南。
我要回去打 diablo 了。
開辦 Taipei Rails Meetup 兩年多以來。除了在 前文 提到有招募過程 「鑑定」/「被鑑定」的困擾外。
另外一個我也常常被要求幫忙，但始終想不到有效解決方法的兩個問題是：
- Xdite，你知道哪裡有「好的」（甚至不用好的..），現在正在找工作的開發者，可以介紹嗎？
- Xdite，你知道哪裡有「好的」（甚至不用好的..）Rails 公司在找人，可以介紹嗎？
很難幫上忙因為：
- 「我個人保證」這間公司 / 這個開發者很好，風險是很高的。所以發生次數也不高。
- 即使不需要我個人保證，參與 Meetup 的個人與雇主（不一定雙方會同時參與同一次），很難有效的牽上線。
傳統招募流程的問題（費時）
根據我與朋友過去的招募經驗，招募其實是很痛苦的一件事。因為需要招募往往表示著現在就有補人壓力，但是你卻不知道哪裡有可以「嘗試」的「新鮮面孔」可以招募（可以談的其實多半都先談完了，然後才會公開招）。而面試的流程往往是這樣的：
- 寫招聘啟示。並在社交媒體或社群內散布。
- 等待求職者投遞履歷，並視「Dev Lead 有空的時間」安排面試。
- （幸運的話一次就錄取）（不幸的話繼續重複循環）
一個月內就有補人壓力。但是卻因為種種原因，卻只能排到五場面試，三場面試裡面可能又會有一兩場是坐下來五分鐘，就知道不用繼續下去。但為了保持禮貌還要寒暄 30 分鐘。
面試者也有相同的壓力。因為要遷就「Dev Lead 有空的時間」。可能一個月內也排不到幾場面試，卻坐下來聊不到五分鐘，就覺得這不是自己想要的公司...
參與社群也不見得當次就有會現身要招募的雇主。
解決方案：Speed Dating
我也一直在思索到底要怎麼解決這樣的困境。最近因為要邀朋友一起參加外國 Conference，跟朋友分享參加的好處。才突然想起來，在前幾年兩次參與 Conf 路過舊金山 Ruby / Rails Meetup 時，就看到他們發明解決方案了。這個解決方案就是：Speed Dating，快速約會。
快速交往源於外國聯誼，為了「快速挑選可以交往的對象」，這樣的聯誼通常會是約 10 個男生，10 個 女生。雙方簡單交流 5-10 分鐘。換下一桌。如果不喜歡，時間到就可以逃到下一桌。如果看對眼，當場就交換資訊，會後聯絡..。
Employer-Developer Speed Dating 也是相同的原理。很多時候，雙方差不多聊 5 分鐘就可以知道要不要繼續談下去。不喜歡就換下一桌不失尷尬。雙方交談甚歡的話也可以馬上約時間安排面試。
一場下來。雙方交換到八個十個以上不錯的機會也是很有可能的事。將這個想法跟社群內幾家 Rails 公司交流了一下，也很快獲得了認同。
所以我們決定舉辦第一次這樣的招募快速約會 http://tp-rails-meetup.kktix.cc/events/speed-dating-01
活動詳情：（招募者付費，開發者免費）
報名網址：http://tp-rails-meetup.kktix.cc/events/speed-dating-01
時間：3/30 （日）下午 14:00 - 17:00
地點：CLBC (台北市復興南路一段293號4樓)
票價：
- 開發者：免費
- 招募者：5000 新台幣
- 招募者尊榮方案：8000 新台幣
- 現場備有無限酒水暢飲
活動辦法：
- 募集 10 - 15 位左右的招募者，以及 50-75 位左右的開發者
- 以 5 分鐘為計時單位，快速交換寒暄，簡單自我介紹公司以及開發者背景。決定要不要後續聯絡。
- 開發者可以自由決定是否要留下資訊給招募者（主辦方會給予開發者紙卡，留下自己簡單聯絡資訊），進行後續面試。
- 主辦單位在一開始活動簽到時，會發給參與者一張所有招募單位的資訊（每間公司500字，主辦方會聯絡招募者繳交）。
- 主辦單位在一開始會有簡短的開場時間介紹招募單位，也會留給大家 social 的時間
- 報名尊榮方案的招募單位，可以請主辦單位夾帶發放一張單張的公司招募文宣
其他：
- 歡迎透過 KKTIX 的 聯絡主辦單位 [https://kktix.com/organizations/tp-rails-meetup/contact/new] 發問。
- 早點報名可以早點獲得 Speed Dating 的面試順序（因為開發者眾多，故可能安排三個時段進行）
- 有其他更好的想法也可以跟我們聯絡。
- 如果成效不錯的話，我們可能會發展成 per month 活動