Blog.XDite.net

The Startup Owner's Manual 讀書心得（2）: New-product introduction model 致命的九宗罪

2012-05-13T11:39:00+08:00

在上一篇。作者提到了「New-product introduction model」有非常大的機率，會讓一個 Startup 從車站一開始出發，終點就注定是地獄。整理歸納了的九宗罪，多數 Startup 都是因為這九宗罪而死掉的。

1. Assuming “I Know What the Customer Wants”

第一條是創辦人盲目的認為自己：

知道客戶是哪些人
知道客戶要什麼
知道怎麼把產品賣給客戶

任何冷靜的觀察者從 Day 1 就會觀察到一個客觀的事實：一個 Startup 一開始不會有任何客戶。除非這個 Founder 原先就是這個領域的專家。

不然創辦人往往只能用「猜」的去猜測「會有哪些客戶」、「存在哪些問題需要解決」、和「可能的商業模式」。

而使用「New-product introduction model」會讓創辦人將猜測當作是事實，在跟第一個真正的客戶聊過之前，開始設計產品和花大錢。

想要成功，創辦人需要將假設與猜測設法僅快的轉變成「事實」。唯一的途徑就是走出室外真正的與客戶攀談了解需求。當初的假設是否正確，僅快修正自己錯誤的猜想。

2. The “I Know What Features to Build” Flaw

第二條跟第一條有點相關。

創辦人會自以為懂他的用戶，先行假設出一堆他覺得用戶會需要的功能。「閉門」使用傳統的產品開發流程，精心打造一整套完整功能的產品。

但…等等，這是 Startup 應該做的事嗎？

不。這種方法通常是「Company」在已經有客戶的情況下才可以這樣作。

傳統式瀑布開發法，通常一開始起頭，就需要 1-2 年的時間。進度的衡量方式是在推出前究竟寫了多少行 code 以及製造了多少硬體出來。

但問題是，在開發過程中。不跟用戶進行直接且持續的交流，是很難知道哪一項功能才真正的吸引人。

在產品完工之後才再進行修改，代價往往高昂且耗時。巨大的開發能量被浪費，無數小時的工作成果被當成垃圾。

但諷刺的是，很多 startup 常愛用這種傳統的方式去開發產品。

3. Focus on Launch Date

傳統的開發流程會出現：Engineering、Sales 和 Marketing 的時程綁死在一個不能修改的「上線日」。

Engineering 的開發流程中通常會有 alpha / beta / release 三個階段，確保產品能夠有時間空間能被改善到能 deliver 的程度。

好笑的是，往往上線日，真正上線的產品的品質和進度卻往往都是「剛做完」而已。而不是到公司已經知道怎樣去行銷或者販售這個產品的程度。

但幾乎在每一間 startup，不管到底準備好沒有，不能修改的「上線日」卻往往跟「first customer ship」綁在一起。甚至更慘的是，有些投資者的財務計畫甚至跟這個時間也綁在一起。

投資者往往會說：「Why, of course that’s what you do. Getting the product to market is what sales and marketing people do in startups. That’s how a startup make money.」

這是 絕對致命的建議 ，千萬別理他們。（這句話是書上講的，不是我講的）

每一家 startup 或者是 company 當然都想要能夠一開始就順利的販售出新做出來的產品，並且能夠執行極佳的行銷策略。但這個夢只有在公司知道「誰會負責賣」以及「為什麼客戶願意買」的前提下才會達成。

但是多半的情形是，大家一廂情願的只會認為：有著良好的「Engineering Execution」，客戶就會買單…

一次又一次的，只有在上線之後，Startup 才會發現沒有足夠多的用戶會使用他們的網站、轉化成有效的訂單。早期用戶數不夠提升到主流市場。不能解決 high-value 的問題。更或者是配送成本過於昂貴。

發現這些事情已經夠慘了。

更慘的是情況變成騎虎難下的局面，已經花了很多錢卻沒有期待的效益。只好開始找問題在哪裡，看看還有沒有機會修正…

Webvan 的情況是，當初他們更身處在 dot-com 狂燥症熱錢到處是的年代，又加重了這樣的情形。公司在前半年只有 400 人，後半年就補了 500 人進來；在初期只開了一間值 4000 萬美金的配送中心，不久之後，又瞬間開設了 15 間相同等級的配送中心。

你問他們為什麼要這樣作？喔。因為這是 Business Plan 上寫的。不管真實狀況是不是需要。

4.Emphasis on Execution Instead of Hypotheses, Testing, Learning, and Iteration

Startup 的文化通常強調「get it done，and get it done fast」。

所以很自然的：「the heads of engineering, sales and marketing all believe they are hired for what they know to do, not what they can learn 」

這些頭頭們直接假設他們的經驗跟現在的事業有強烈的正相關，而且他們需要做的事就是在這個新事業「重製」他們在前單位所作的事。

問題是，Company 跟 Startup 是不同的。Company 需要的是「執行」business model，它們的客戶、需要解決的問題，和產品需要的功能都處於「已知」。

但 Startup 所需要的運作方式卻是必須開啟「Search」模式，然後測試和證明所有當初的猜想。從每次測試的結果中學習，提煉出猜想，然後再繼續測試一遍。目的就是要找尋出一種可以重製(repeatable)、規模化(scalable)以及能夠獲利(profitable)的 business model。

書上特別 highlight 了一段話，我覺得很棒： 「Relentless execution without knowing what to execute is a crime」。

實務上，startup 是由一連串的原始猜想所組成，它們可能最後都是錯的。所以，如果專注在執行和產出一個全由這些原始猜想組成的產品，絕對是一個自殺策略。

而傳統的「product introduction model」的想法通常是直接假設建立一間 startup，是一個一步一步來、有順序的、執行導向的過程。

每一個階段都可以被 PERT chart （PERT 圖是一個項目管理工具，用於規劃，組織和調整項目內的任務）所描繪。根據里程碑投入相對應的資源。

所以想搞 startup 還用「product introduction model」，難道不是有計畫的自殺嗎！？

5. Traditional Business Plans Presume No Trial and No Errors

傳統的產品開發模式對董事會和創辦人來說有一個很大的好處：它能提供一條看似不模糊的道路和前面還有哪些里程碑需要完成。

在這種模式中，財務進度也是用收入現況、資產負債表和現金流等實際指標來追蹤。

但是在 Startup 真實的狀況中，這些指標沒有一個適合。這些財務指標是用來衡量已有存在客戶、市場的大公司用的。

它們沒有一個可以用來追蹤 Startup 唯一目標的進度：那就是「找到一個可以重複、規模化的 business model」。

6. Confusing Tradition Job Titles with What a Startup Needs to Accomplish

多數的 Startup 會借鏡一般的公司所給的 Job Title。但記得，這些都是從已知生意模式借來的玩意。在這些公司中，所謂的「Sales」指的是重複的銷售一個已知的產品給一些已經理解這個市場運作規則的客戶。

但是 Startup 怎麼可能會有這些「已知」的這些玩意？？

因為目標用戶、產品規格和產品介紹極可能可能每日一變，Startup 的早期成員要是能夠非常能夠適應混沌的人。他們要對學習和發現抱持著極大的開放態度、殷切找到「可以重複、規模化」的 business model」。

Webvan 的執行長和 VP 都是從大公司挖來的一幫人。他們對於這種 startup 的混沌都非常不適應。對於混沌，他們的解決手段就是：趕快讓公司急速長大，以為這樣就能解決問題。

7. Sales and Marketing Execute to a Plan

公司真的缺人的時候經應該補人。要補人當然要開出正確的缺補到適合的人。但，你確定你真的補進了正確的人嗎？

補進一個正確職稱的 VP，但是他卻用了錯誤的技能以及錯誤的經驗在作事，這也是對 Startup 的一場災難。

在一般公司裡，往往走的是依循著傳統的 Business Plan 和「product introduction model」。也就是讓董事會和創辦人對即將展開的這個新生意，設出一個上線日、估算 burn rate、制定獲利計畫和一狗票里程碑。

這對已存在生意模式的公司當然是合理的。但大部分的 Startup 都不適用這樣的情形，

現實生活中 Startup 通常一開始小有成績，接下來就會想補業務拓展團隊。這時候的業務拓展團隊適合的方向往往該是跟 Product Development 部門摸索出可以重製而且可規模化的生意。

但問題是你挖來的 Sales VP 和 Marketing VP 可能往往不管這些，他只懂的做的是接著董事會這些假想計畫，假想一個狀況自顧自的進行舖天蓋地的銷售計畫以及行銷手段。

這是 Startup 所需要的嗎？不，這是大災難…

8. Presumption of Success Leads to Premature Scaling

傳統的 Business Plan 往往將公司發展的每個步驟敘述的完美無暇，天衣無縫。這使得在這樣的模式中，能夠犯錯、從中學習、根據客戶意見回饋修正的空間，被壓得很小。

從沒有人規定說「Stop or slow down hiring until you understand customers」或者是「pause to process customer feedback」。

即便是最有經驗的執行者也會被被迫根據進度一直補人。跟著這就會引起下一場 startup 災難：「premature scaling」

明明網站目前每天只有 5000 訪客。但 Bussiness Plan 上面寫的是，認為下半年每天應該衝到 50 萬訪客。這樣的規模就需要大買機器，大肆雇用人，擴張新 feature，於是就開始花大錢衝刺這些部分。

時間慢慢的過去，這些東西都沒有如預期般的用上，當然也沒達到成績。但是東西、人，都已經到位了。放著閒置也不是辦法，只好再找一些「不是事情」的事情給他們作。或者是拼命假想一些情境製作 feature。賭看看可否衝刺到當初的目標。

聽起來熟悉嗎？

書中很酸的舉了 Google 的 Orkut, Wave, Dodgeball. Microsoft 的 Zune, PocketPC 等等作為例子。這都是用了「on rigid schedules driven by the models and the presumption of success]」搞出來的災難。

雇用人和灑錢應該根據產品銷售狀況和市場反應是否能夠進入「可預測、可重複、可規模化」的狀態，而不是根據「它們應該按照原定計畫被執行」。

9. Management by Crisis Leads to a Death Spiral

通常董事會和創辦人會在事情已經發生了，「該做的都已經做」了卻沒有起色，之後才檢討到底出了什麼問題。

什麼是「該做的都已經做了」？

就是明明都已經請厲害的 PM、程式設計師打造這個產品了。行銷計畫也聘請了好的公關公司舖天蓋地的宣傳了，當中也請了不少 focus group 來對談。但是就是沒有多少用戶想來使用，更別提留下來變成長期用戶了。

他們往往檢討的原因不會在這段時間到底做了什麼錯事，結論往往會導向：當初的某個 VP 是否適任，他的策略有很大的問題。接著董事會會作一件事，就是再從外面挖來一個高手，換掉這個人，「修正」當初的錯誤。

而這個「高手」，一進來也會直接給一個結論：那就是「前一個人有問題，之前的策略通盤皆錯，於是我們必須這樣那樣。」他會說出這樣的話不意外。

因為這就是他被『雇用來的原因：前人有錯，之前策略有問題』。不然你期待他要說什麼？

但事情本質並不是這樣的。Startup 本來就是對『假設』一連串的『試誤』、『驗證』與『頓悟』。而非是一堆被『Bussiness Plan』和『Milestone』驅動的『怪物』。

後記感想

這一章節只有短短的 10 頁。但是卻讓我讀起來冷汗直流，腦海裡一直衝上不少真實場景、真實例子。

一直以來，我對一些實例百思不得其解。有些企業挾著原先的資源優勢和招募優勢，風風火火的搞了一個偽 Startup。最後卻慘敗收場。但是毫無資源的個人或單純只是優秀的程式設計師，卻赤手空拳自己蓋了一座雄偉堡壘。

你說這世界一定是這樣嗎？也有大企業投入資源最後取得有效的成功（美國、德國的大型山寨集團），而個人陣亡的更是不計其數。

每個創業家都在思考這個問題：『成功』到底跟『資源』有沒有正相關，還是只跟『團隊』與『創辦人』有關？

這些年來我也一直在思考這個問題的答案：只是每當以為自己稍微想通一點脈絡，另一個實例就突然打了我一巴掌。最後我也只好這些例子收起來，因素歸諸成『Luck』與『God』。

這本書，最吸引我的就是作者寫的前言和導讀。作者在這本書一開始的部分就寫，這一本書就是一本 step-by-step，教人怎樣建造一間成功、獲利、可規模化 startup 的指南。他認為這樣的公司不是神話而是可重製的。這本書就是答案。

他也不希望讀者一口氣就讀完這本書（而且他也認為讀者一口氣讀不完）。還寫了長達六頁的指南教大家怎麼讀。

還沒正式閱讀本書時，光看到這幾頁，我心中只有一個想法：「這個作者真狂妄」。這本書再厲害，也不可能有你講的這麼誇張吧？我就是要一次讀 200 頁，不可以嗎？

讀了 30 頁以後，我的想法徹底改變了。我開始認為他說的一切都是真的。而在這本書裡面勸告讀者的話，都是真心的。（竟然好心的寫了六頁教你怎樣讀這本書）

我開始對一些懵懂不解的問題有了答案：

至少我開始理解原來一直以來，大家習慣用的作事的方法，就是製造業一來使用的方法。只適合在有確定用戶，確定市場，確定 bussiness model 的情況下才能使用。也只有在這樣的情況下才有機會成功。

這很大程度了解釋了為什麼：個人、大公司要『新創』一個事業很容易失敗。而一些『大公司』要『山寨』一個服務也有機會取得成功。

Webvan 盛大開場，悲慘結束。也是因為盲目 follow business plan，沒有摸索出 customer 的樣貌，也沒有針對 customer 的 feedback 中調整產品，沒有從構築公司裡面學習並修正。錢花光，於是就破產收場了。

第一章通篇在講的是如果你想要『新創』一個事業，你絕對不能掉進這個傳統製造業的公式裡。而且作者認為，在 21 世紀的現在，網路與生活緊密接軌，新創公司、新創服務可以套用傳統製造業的公式的機會越來越小。大家都是往未知前進。於是你必須改用另外一種模式探索、構築你的 Startup 才行。

而這個模式就是作者頓悟出的另一個模式『Customer Development Model』。

Customer Development Model 分為四個階段：

Customer discovery
Customer validation
Customer creation
Company-building

我會在下一篇讀書心得中，整理這四個階段的內容。

====

（待續…一個禮拜，已經讀完了但是寫出來要花很久的時間）

The Startup Owner's Manual 讀書心得（1）: 別再使用製造業思維搞 Startup

2012-05-12T12:34:00+08:00

最近終於有時間坐下閱讀這本親自跑到美國帶回來的這本創業指南：The Startup Owner’s Manual: The Step-By-Step Guide for Building a Great Company。這本書目前才僅僅看了 30 多頁，就讓我迫不及待的先寫下書的部分讀後整理，因為太過值回票價。

短短的 30 頁，卻花了快 3 個小時的時間閱讀，不是因為艱澀難懂，反而是因為這本書遍地都是許多真知洞見的見解與實例。一邊閱讀，眼前一邊湧上過去幾年的成功和失敗，很多時候我必須激動地停下閱讀，仔細反芻，才能繼續往下一章前進。

很多過去讓我百思不解的疑惑，在這數小時激盪下，都一一撥雲見日。

這本書第一章的標題是 The Path to Disaster: A Startup Is Not a Small Version of a Big Company。作者以一間 2000 年網路泡沫時代創立的大公司 Webvan ，從募集巨額資金/ IPO 不久後瞬間破產倒閉，當中所犯的種種錯誤，來解釋大部分的人在創辦企業時所犯的錯的致命程度。再藉機引出第二章：The Path to Epiphany: The Customer Development Model，作者對 Startup 的建立過程整理了自己的一套見解，他認為多數 Startup 必須要經過一段 Customer Development Model（有四個步驟），才能變成一家真正的 Company。

泡沫時代的 PChome 24hr : Webvan

Webvan 做的生意是 online ordering and same-day door-to-door grocery delivery 生意。若你不清楚這是什麼，把它想成 PC home 24hr 就對了。關於 Webvan 的失敗故事，網路上有不少篇的紀錄文。

Webvan 的背景是讓人很羨慕的。在短短的時間內就募集了鉅量的資金，請到了很棒的 CEO。很多客戶也喜愛他們的服務。但是竟然在開業短短不到兩年的時間，就宣告破產倒閉了。到底發生什麼事？

他們的問題不在於低落的執行能力，相反地 Webvan 一開始就打正規戰，使用了最普遍使用的「New-product introduction model」方式擴展執行，並且徹底的往多數投資者所樂見的方向去：「先行者優勢」、「快速變大」。

那為什麼還會失敗呢？而且還是這麼迅速的倒閉呢？因為 Webvan 略掉了一件相當重要的事？直接為這個公司帶來了死亡。

製造業的模式：New-product introduction model

在二十世紀，每個公司要在市場上推出一個新產品，都會使用一種固定的 product management model。這套模式很常被用在製造業上。

New-product introduction mode

Concept/ Seed => Product Development => Alpha/Beta Test => Launch / 1st Ship

從一個簡單的想法作為出發點，然後進入產品開發階段，接著進行使用者測試，然後再推出市場。

「New-product introduction model」很適合目前已經存在的「Company」所運行的模式，知道消費者長什麼樣子，spec 可以被容易的被列出寫下來，市場也被定義出來了，而且你可能也知道對手長什麼樣子。

問題是，一般的「Startup」很少能符合這樣的標準。但是很多人還是堅持使用這種模式去進行產品開發、客戶尋找，甚至是對銷售計畫、上線、營收計畫制定時間表。然後大多數人都這樣掛掉了。

這套模式到底哪裡有問題？又是怎樣讓 Webvan 爆掉的？

一去不回頭的瀑布模式

「New-product introduction model」的問題在於容易引發瀑布模式：

Requirements => Design => Implementation => Verification => Maintenance

整件事會開始變成這樣：從一個點子變成一本 Bussiness Plan。募到錢後開始招人，人都到位以後，作行銷 (Marketing) 的開始根據 Bussiness Plan 定義市場規模和首批客戶樣貌，舉辦幾場 focus group 對談，然後開始製作 MRD (market requirements document)，開始丟給 RD 團隊去作。

Product Development 階段

作行銷 (Marketing) 的繼續準備 sales demo、行銷材料，雇用公關公司。在這個階段，通常公司還會跑去雇用一個業務副總。

同時，RD 團隊會集中火力在制定詳細規格，開發產品。他們的重點會擺在如何在一個定義好的有限集合內，降低工程上的風險。接著就是 18-24 個月的開發期。

在 Webvan 的這個 case 中。就是去蓋自動化倉庫，買各式各樣的輸送設備。開發自己的儲存系統、倉庫、路線管理系統…etc.

而行銷團隊這時候會開始準備圍繞著 Webvan 這個品牌的行銷以及促銷活動，第一批客戶的嘗試體驗，建立客戶忠實度，如何最大化回頭率和單次購買金額。

Alpha/Beta Test 階段

RD 團隊開始測試這套系統運作有沒有問題。行銷團隊忙著制定整套市場溝通策略（建立公司網站、建立業務 sales kit..etc.）。然後公關公司開始聯絡媒體、部落格…

業務團隊開始跟第一批 beta 用戶（當初自願加入嘗試新產品計畫的用戶）簽約。業務主管開始絞盡腦汁的在研究如何達成當初根據 bussiness plan 定的營利計畫。

Launch / 1st Ship 階段

隨著產品開始商轉，公司朝向一個「big-bang」式的花錢模式。舉辦 press event，建花大錢建立全國性的業務組織、業務管道。董事會開始根據銷售執行率來衡量公司績效。

這些都是正規軍作法，但無疑的，都很燒錢。特別是在建立銷售管道和繼續支撐行銷計畫。

花光錢死亡

故事的結局非常不新鮮如同大家當初預料的一樣：

上線之後開始發現當初預先設想的流程不符合實際需求
行銷計畫過於花錢
忙著擴張市場卻一天到晚作賠本生意
客戶群開始逐漸萎縮但公司視若無堵的繼續擴張計畫

最後公司錢花完倒閉了。

The 9 Deadly Sins of New Product Introduction Model

作者從 Webvan 的故事中，整理歸納了九宗罪，點出「New-product introduction model」所隱含的致命風險。點出了一般 Startup 常犯的重大缺失。

他點出了很重要的一點，其實大多數的 Startup，特別是網路業，不應該使用「New-product introduction model」去推出自己的產品。而是必須要用 Customer Development Model 去穩固打下基礎，從 Startup 轉型成 Company。

「New-product introduction model」有非常大的機率，會讓一個 Startup 從車站一開始出發，終點就注定是地獄。

這九宗罪是：

Assuming “I Know What the Customer Wants”
The “I Know What Features to Build” Flaw
Focus on Launch Date
Emphasis on Execution Instead of Hypotheses, Testing, Learning, and Iteration
Traditional Business Plans Presume No Trial and No Errors
Confusing Tradition Job Titles with What a Startup Needs to Accomplish
Sales and Marketing Execute to a Plan
Presumption of Success Leads to Premature Scaling
Management by Crisis Leads to a Death Spiral

我會在下一篇讀書心得中，仔細整理這九宗罪的詳細內容。這九宗罪又是如何搞垮一個 Startup 的。

The Startup Owner’s Manual 讀書心得（1）: 別再使用製造業思維搞 Startup The Startup Owner’s Manual 讀書心得（2）: New-product Introduction Model 致命的九宗罪

如何準備美國自助旅行（行程準備篇）

2012-05-06T20:10:00+08:00

這次去美國旅行接近三個禮拜（去參加研討會 + 旅遊）。這算是我第一次的美國自助旅行，機票、保險、飯店，景點的安排幾乎都是自己弄的，這次玩得非常開心，中間也幾乎沒出什麼大事。

這次旅程橫跨好幾個點，所以就放棄請旅行社代為安排的計畫，因為即便有辦法請旅行社訂，價格也會超過預算。雖然剛開始有點手忙腳亂，但老實說在這過程中還學到不少東西的，

趁記憶猶新，趕快寫下來，也方便其他人參考。

行程準備

護照、美國簽證

去美國當然要先辦護照和美國簽證。這是有相依關係的：如果沒有護照，就辦不了美國簽證。沒有美國簽證，旅行社不會賣任何美國機票給你。

機票建議是在 conf 開賣之後就訂下去（越晚訂，日期、位子、價格會越來越爛），所以最好那時候就要開始跑護照和美簽的事。因為光搞定護照和簽證最少就要大概花掉一週的時間。

我手上的美簽是一年前在公司出差時申請到的 B1/B2 簽證，一般人大概是申請 B2。簽證攻略在 PTT 的 VISA 版上有很多，這邊我就不細述了。

機票

去小城市就拆開訂

我的計畫原本只有打算到奧斯丁參加 Railsconf，去舊金山多玩兩週的行程是之後才決定的。

比較麻煩的是奧斯丁不是直飛點，所以不管是向旅行社洽詢或者是上網到雄獅、燦星詢價，都得到非常爛的價格（大概都五萬多塊）。價格還是其次，比較大的問題是班次很少時間很爛，而且中間的美國轉機點只有洛杉磯可以選。這就跟預定行程完全衝突。

偶然間跟教母 cjin 靠北到這個問題之後，他建議我採取了另一種策略：「拆開訂」。

於是後來我的機票就變成只跟雄獅訂「台灣到舊金山」的來回機票。大概台幣 33000 上下。然後再上 Priceline 上訂「舊金山到奧斯丁」的美國國內線來回機票。大概台幣 7-8000 。

拆開訂好處很多，除了價格很明顯的變得非常便宜。最重要的是一把機票拆開訂，這兩段的時間和機位選擇就變得超級多的…機票瞬間就搞定了。

美國國內線機票價格不含行李托運費

這邊要注意的是台北到美國段，我坐國泰的航班，可以免費托運兩件行李各 23.5 kg。但要轉機到奧斯丁的時候，才發現原先我們買的 UA 國內線機票是不含行李托運的。第一件行李要 25 USD，第二件行李是 35 USD，限重也是各 23.5 kg。

重量的分配和額外的支出在這裡是要特別注意的。

旅館

大會期間住宿

Railsconf 是在 Hilton, Austin 舉辦的。因為大會有談到還蠻兇的 Discount 價（便宜大概 50+ USD) ，而且聽累就可以直接回房間睡很方便。於是在買票的時候，我就順便訂下去了。不過即便有 discount 還是不便宜，打完稅之後還是要 200 USD 出頭一晚。

舊金山旅館

聽說舊金山的旅館大概是全美數一數二便宜的（我聽朋友講的），還算事實。120 USD 左右一晚就可以訂到不錯的旅館。當初是上背包客棧作功課，找了幾家候選，最後排預算選出來的。我們是住 Powell 和 Stratford 這兩間。

這兩家都離 Union Square 很近，靠近各種交通工具的起點，所以我蠻推薦住這一區的。但缺點是 Union Square 晚上超過九點以後，附近會變得比三重還要三重，治安很亂，這是唯一的擔憂。

Powell 能給的房間算比較大，超靠近地鐵，櫃台幾乎什麼票都有在賣，而且櫃台阿伯都很親切，這算優點。缺點是網路 DNS 一天到晚掛掉，很讓人抓狂…

Stratford 的房間比起來就算有點小了。但一樣交通很方便，櫃台也親切。優點是乾淨、整潔、明亮，網路也快。他跟 Powell 差了兩個 block，治安好一點。缺點是靠街的房間晚上很吵…-_-

這兩家旅館我是透過 Hotels.com 訂的，都是信用卡 prepaid。

機場旅館 (過夜班機建議訂)

抵達舊金山的時候大概是晚上 11:00。但是去奧斯丁的班機是隔天早上 8:00 多。剛開始我們傻傻的沒有訂機場旅館，直接睡在機場大廳。沒想到那感覺實在太爛了，不是因為機場不好睡。而是因為連續在機場和飛機上待了二十幾個小時沒洗澡，全身都快發綠光了。

於是從奧斯丁飛往舊金山時，實在不想再當綠人的我就下決心訂下去了。也是上 Hotels.com 找的，大概 100 美金一晚（ two queen beds )。機場旅館會有免費接駁車讓旅客來回機場。神秘的是，機場旅館的網路是我們這趟旅程遇到最快的….orz

機場接駁車

機場到旅館會有很多 option，可以選擇租車、Taxi、Shuttle 或者是鐵路（如果該城市有蓋的話）。奧斯汀段我是在 Priceline 訂國內線機票時，有加錢訂 Shuttle 的選項，就順手訂下去了。到機場時拿著購票證明去 Shuttle 登記處 redeem 就可以了。回程票則是要在 24hr 前打電話去預約回程的時間。

在舊金山段時，到舊金山市區我是搭 BART ( 機場連著 BART )。而離開舊金山時我是請櫃台幫我訂 Shuttle （因為想看回程風景）。Shuttle 一段票大概都是 10 幾塊美金這樣。

如果你是懶人的話我建議訂 Shuttle 會比較好，拖著一個 2-30 kg 重的行李跑來跑去並沒有很好玩 XD

手機門號

有 3G 以上需求請選 AT＆T

手機 Sim 卡我是上 Aerobile 買的。這家服務算不錯，很多 plan 可以選。寄送速度也快，隔天到達。你準備要出發時，可以寫信請他幫你開門號（自己開很囉唆）。

主要有兩家門號可以買：AT&T 與 T-mobile。去年我在西雅圖出差時，用的是 AT&T 的 3G，但是印象沒有很好。主要是因為鎖卡（iPhone)，自己繞路有點麻煩，加上不是吃到飽。

所以這次就選 T-mobile 的 30 天吃到飽方案。沒想到還是 bad choice。原因是 T-mobile 的頻段 iPhone 只能跑到 edge 而已，速度會讓人很難過。但好處是插上去就 active 了。

又會改建議用 AT&T 是因為美國現在開始都在跑 4G 了，用 iPhone4+ 速度可以跑上去，而且現在 hack 也變得比較容易了。所以綜合來說商務族還是建議使用 AT&T 4G。

500 MB 的 plan 大概就夠一個人用大概 10 天了吧。

電話需求

我平常就有存一些 Skype credit。有時候在國外還是有需求打越洋電話，通常我是直接找有 Wifi 的地方上 Skype 打回去。其實若沒有 Wifi，用 Edge 網路其實勉強也能講一下 skype。省錢很多。建議出國前刷一點點數存進去。

保險

基本上現在用信用卡買機票都有含一些保險在裡面。但是險有很多種，基本上我們這種外行人也看不懂，好險網有整理了旅遊險懶人包，可以讓你看完大概知道這些險的種類。但是我實在也太懶得一個一個去找險來保，最後是在網路上找到美商安達保險這個旅遊險懶人包保下去，保了17天，保費大概是 2000 出頭，用信用卡就可以線上申辦了。

旅遊手冊

這次因為是自助旅行的關係，很多訂票訂房訂車的都是我自己在處理。Receipt 超多。所以這次也跟往常不一樣，我特地製作了一本旅遊手冊(一本紙本、iPad 又丟一份 pdf）把這些整理好收進去。裡面主要有放

台灣 <-> 舊金山航班資訊
舊金山 <-> 奧斯丁航班資訊
奧斯丁 Shuttle 接送資訊 (reedem ticket)
奧斯丁旅館訂房資訊
舊金山旅館訂房資訊
同行旅伴旅遊資訊
航空公司、旅館、接駁車聯絡資訊
美國友人會面與聯絡資訊
Railsconf 及其他周邊會議入場卷
Railsconf 議程表
一些旅程注意事項以及 checklist

這次會特別整理這本手冊，是基於過往幾次出差經驗，累積出來的。不得不說，使用經驗實在好極了。因為路上所有遇到的美國海關關員、航空櫃台、旅館櫃台、接駁巴士櫃台，都愛死這本手冊了。因為他們幾乎只要拿著這本手冊照著 key 就可以瞬間完成他們手上的作業。幫他們省不少時間也幫我省時間。

美國海關（拷問程度不下 AIT）

特別要提的是美國海關這一個關卡。之前幾次的出差經驗讓我發現，美國海關是個比 AIT 問話審查還要嚴格的地方。比如說像我就算去出差開會，官員還是會拷問你一大堆，把你當想跳機的犯人。所以過海關時，手上還是要準備一些資料才行。之前去出差時，我就有看到隊伍好一些人，因為英語說不輪轉，身上又沒什麼證明的人。被拒於門外或被請到小房間去…orz。

這次單純只是去參加研討會想玩一玩，結果拿這本入境，老外隨口跟我聊一聊，看看裡面的內容就讓我過關了。

======

這些大致上就是出發前比較特別需要去申請和處理的部分。晚一點會換貼一些我當初寫在手冊裡面的物品 checklist，不少東西都是幾次出國下來累積出來的經驗…。

Railsconf 2012 - 國際性 Conference 是這樣辦的（下）

2012-04-25T14:40:00+08:00

11. 售票 / 大會網站 / Schedule / 贈品

售票

大會是大概半年前公布時間，然後就開始售票，使用的是 Eventribe 這套系統。

行前幾天大會也會透過這個系統寄通知過來。

大會網站

大會網站其實很簡陋。但真正威的是 austinrails 做的這個相關網站。

裡面提供了很多相關資訊，我覺得對旅人和開發者都相當有用：

BOHConf / Ignite Railsconf : 提供大會議程外的選擇
Rails5k : 最後一天的早晨大家一起起床去跑五公里馬拉松
Happyhour: 議程結束後去喝酒
Visiting Usergroups : 提供世界各地來的 Ruby User Group 代表登記，在大會期間可以去找他們聊。（我見到不少當地代表穿著當地 RUG T-shirt 在 Happyhour 期間歡迎大家搭訕）
Stay with a Local : 讓 Austion 本地開發者登記家裡開放借住。預算緊的開發者可以來這裡看有沒有人願意收留。
Talk with A Local : 提供很多本地吃的建議。最神奇的還是有本地熱線。本地熱線是由 Pocket Hotline 提供。本地人可以志願登記接電話，如果有人需要幫助，打這隻電話就可以得到幫助。

至於網站語言當然都是英文的。不只是因為這是美國的 Conf ，也是國際的 Conf。

議程表

大會手冊裡面只有議程介紹。議程時間表是大會前幾天才公布的。使用的是 Busyconf 這個服務。還算不錯用。支援離線瀏覽，iPhone Client。點議程會顯示更多關於議程的以及講者簡介。

贈品

報到時大會會發一個已經印刷好的 badge，一本大會手冊（手冊裡面有贊助商夾頁），還有一件 Railsconf 紀念 T-shirt。

大會手冊裡面基本上印到就是議程簡介和贊助商廣告。看得出來 Cookpad 今年砸了不少錢贊助…不僅贊助商夾頁品是他們的，手冊裡面別人都是小方塊，他們的竟然是跨頁精美廣告。

12. 大會贊助商贈品與交流

大會贊助商有 Engine Yard 、New Relic、Cookpad、Heroku 等等知名大廠商。基本上這些廠商都還蠻夠大氣的。

不僅送的贈品都讓人搶著要，而且就算只想拿贈品，工作人員也幾乎不囉唆，也不會強迫你填什麼問卷或硬是要跟他們聊天。他們反而比較像駐場代表，讓大家問平常沒機會問的問題的。

Hiring 的部分幾乎都是在社群白板上進行。

贈品有哪些？就我有拿到的部分:

(1) Heroku : T-shirt!!!
(2) Engine Yard : 經典 LOGO 貼紙和 Engine Yard 玻璃杯。
(3) Cookpad: 環保袋以及筷子。

(這些部分有空再補圖）

基本上攤位都是一補貨瞬間就空了。贊助廠商也不小氣，一準備幾乎都是幾十一百份。然後兩天都有在補貨…

職員都會穿著公司 T-shirt。而 Heroku 大概是因為贈品都送 T-shirt。為了避免造成誤會。他們 T-shirt 後面還會印著「職員 Staff」兩排字。

13. 大會工作人員

大會工作人員幾乎都是 Ruby Central 的人。老實說其實看到的 Staff 不多。

我不知道是不是真的人很少，還是因為現場其實也便利到其實很少需要真正跑去找大會解決的 issue。

值得挑出來講的是大會經理，是 Leah Silber 。Leah Silber 之前是 Engine Yard 的社群經理，之前在 Engine Yard 就是在做社群經營這一塊。她也策劃幫忙了不少 Rubyconf。Railsconf 這次的不少東西上上下下都是她在張羅的，甚至在報名處負責發名牌的也是她。

不過真正八卦的是，Leah 是 Rails 3 架構師 Yehuda Katz 的老婆…..XD

而大會租用旅館當場地其實也算聰明，很多工作負擔(如準備餐點、收拾餐點、收拾場地、指點方向）就讓 Hotel 的工作人員就擔掉了。這也是我猜測其實沒有需要那麼多人力的關係…

14. Call for Sponser

在宣布售票的時候，大會同時也公布了 Call for sponser 的贊助書

這本贊助書直接是對外公開的。

第一頁的內容是：

會議簡介
預計參加者
過往 speaker
會議時間
去年 sponser list

第二頁的內容是：

各個 Sponser 的牌價以及待遇等級。

這份贊助書是我有史以來看過的贊助書寫的最詳細精美的。很值得想辦 conf 的人參考。

15. 其他感想

最後一天的 keynote，主辦人有上來講話，並宣布明年的 Railsconf 時間、和今年的 Rubyconf 時間。

另外他提到，今年很多人都跑來稱讚，說今年的 Railsconf 是他們參加過有史以來一屆最好的 conf。除了中午食物真的很難吃之外…XD

我在 4 年前寫過一篇文章辦出人人滿意的網路聚會之黃金三點提到過，conf 的三大重點其實就是：「網路、美女、食物」。這次 Railsconf 只有網路達到標準而已。不過同時間，我也發現一件新的事情：「會場有沒有美女根本不重要！！！」這次大會根本沒有提供美女這項「服務」，但是也根本沒有人靠北這件事情。主要也是因為會議真的非常緊湊，而且滿山滿谷的新朋友，大家忙著選主題和交流已經忙不過來了，根本沒人有空管這件事。而且就算食物難吃也幾乎沒被放大…

結論也是回到最基本: conf 最重要的還是內容內容內容。只要內容充實，網路、美女、食物就會顯得一點都不重要了….

近年來真是有很深的感觸啊。有些 event 真是玩到完全本末倒置了。

===

以前我沒參加過選在旅館舉辦這種形式的 conf。這次下來的感想也覺得很棒，是因為這麼有張力的 schedule，聽完整天大概體力就垮了。而中場就已經沒體力的話，電梯一按也是可以直接回房間睡覺。參加這種等級的 event 才深深覺得辦在旅館真好….

明年 Railsconf 2013 會在 Portland, Oregon 舉辦。我想我可能還會再來一次吧，畢竟 Oregon 是免稅州…XD

Railsconf 2012 - 國際性 conference 是這樣辦的（中）

2012-04-25T10:32:00+08:00

7. Keynote

大會準備的 Keynote 都蠻有趣和有意義。

基本上 DHH (Rails creator) 和 Aaron Patterson （Ruby core, Rails core）每年都會給 talk。

Rails core: DHH

DHH 的主題大概會是他會想硬幹什麼（現在進行式），2011 是 Asset Pipeline，今年是… Rails 4 將會讓你的 project 爛一堆東西，但爛什麼他沒說（抖 XD）

Rails core: Aaron Patterson

Aaron 的主題則是他從現在的 Rails stack 中看到什麼爛的東西，他今年會重寫哪一部分的底層（都是 Conf 結束後才會開始）。去年他是靠北 rack 實在太多層了嚴重影響 performance，於是他決定重寫 rack。但今年他坦承工程太大最後他放棄…XD。今年則是靠北每套 Queue 的介面和實作方式不一樣，他想要寫 ActiveQueue 這種東西。

Entrepreneurship

自 2010 起，都有一個 keynote 會講創業。2010 年請到 Gary Vaynerchuk，2011 年請到 Eric Ries。今年則請到 Techstar 的 David Cohen（VC)。

不過今年 David Cohen 的場次真是無聊到爆炸…講的都是老生常談的東西。2010 的 Gary 就熱血許多，大概也許他是創業家的關係。

Ruby Hero Award

每年大會都會頒發 Ruby Hero Award 給對社群有重大貢獻的開發者。有一些人通常你只有在網路上見過 id，能看到作者真的都還蠻有趣的。

Panel Discussion

每年都會有 Rails core team panel discussion。會邀請今年在場的 Rails core team 現場接受提問然後大亂鬥。基本上每年都會有 DHH 在場，不過今年他沒有參加。今年現場的 Panelist 跟往年的成員組成成分都不太一樣。成員有 Aaron Patterson, Yehuda Katz, Santiago Pastorino, Jim Weirich(大師倒楣被抓來充數)。

不過光看 Aaron Patterson 和 Yehuda Katz 吵架就真的超有趣的，值回票價。Yehuda 真人講話跟網路上文章（很有禮貌）差很多，語調都超挑釁的。而且最機車的是他每次都吵贏（看他戰幾個主題感覺他真的很熟 Ruby / Rails，Aaron 還戰輸他）。

現場還有辦著色比賽。發給大家一本著色簿。贏的人可以跟 Railscore team 合照。而且可以指定姿勢。Aaron Patterson 馬上慘叫：「I’m not signup for this」他覺得大家一定會找他拍超過 PG13 的照片。

（左邊是著色簿，右邊是蠟筆）

Ruby Rogues Live

RubyRogues 是這一年來比較新的 Podcast，每週主題都很不錯，主要在深度的討論 Ruby / Rails 周邊的哲學、工具、語言框架特性…etc.

大會這次準備了現場版。有趣程度直逼 panel discussion，主要是現場大戰互酸開玩笑都很 high。

8. After Party

我不是講者，所以不知道大會有沒有講者晚餐。但是參加的這幾天，幾乎每天都有 HappyHour 或者是 After Party。這些都是大會贊助廠商贊助的，如 Engine Yard、New Relic、Bluebox。基本上就是租下超大的一整層 bar，讓 developer hangout。在 conf 後能有地方可以免費喝酒、聽樂團、有地方聊天。

場地真的無敵大。大概可以塞下 500 人左右。我在這裡認識不少新朋友。

9. 現場白板

大會現場準備了三大塊白板。主要用途是公布議程、社群告示板（ hiring , contest, announcement…etc)

這些白板不到一天就被塗的滿滿了。

10. 講者（講題） / 錄影 / Slides / 筆記

講者（講題）

基本上講者和講題都算專業和有深度的，主 track 不小心出現初學 101 等級的 talk 的機率很低。因為已經有一條主要的 track 是專門排給 101 等級的，而且都是平常的職業教學者在講。

不過還是有幾個講者是雷。題目很吸引人，結果在講 101，這一些題目就被開發者在 twitter 上幹很兇。因為都(繳了這麼多錢)參加 conf 了，就是要學新 / 深的東西，竟然還講一些回家在網站上看 Turtorial 就可以知道的東西，浪費大家時間 =_=||||。

不過我後來發現一個鑑定手法，只要是主題還在 Rails / Ruby Ecosystem 本身的，幾乎都有一定水準。但講其他搭配語言或技術的幾乎都是超級大雷…

而大概是 conf 本身等級很高，講者台風都有一定等級，看得出來都有稍微排練過。（雖然還是可以看到他們現場在狂改投影片，我剛好恰巧有幾次坐在講者旁邊看他們一直在改 XD）

複述觀眾問題：觀眾問問題的時候，都會用麥克風重新複述一遍問題，讓全場可以聽到和讓錄影團隊收到音。

錄影

現場有雇用專業的 confreaks 團隊，錄下整場的影片。通常會在大會結束的一個月左右，上傳公布。

投影片網址

講者在 Slides 第一張，或是最後一張，都會放 Slide 網址。

社群共筆筆記

共筆筆記：而這次最誇張的，是竟然有人在 Github 上開 Wiki Repo 讓大家上傳。每天 conf 結束之後，上面就滿滿的更新了！

Railsconf 2012 - 國際性 conference 是這樣辦的（上）

2012-04-24T17:31:00+08:00

Railsconf 2012 今年在 Austin, Texas 舉辦。這是一場超過 1000 人的大型開發者盛會。今年終於存夠了錢，終於能一舉飛到德州參加。這次的旅行讓我看到 / 學到不少遠超過在台灣能摸到的東西，有些部分很值得寫下來。技術的部分我以後會慢慢整理。不過軟性的部分，我倒想可以趁記憶猶新寫下來。光是 Conf 運行的部分，不少地方和細節都讓我覺得十分專業值得學習。

往年(2006-2011) Railsconf 都是由 O’reilly 承辦。今年則由 Ruby 組織 Ruby Central 自己接回來主辦。在開場之前，其實很少人知道為何今年為何要換主辦單位，主辦人 Chad Fowler 開場就直接先招了：之前在籌組第一屆 Railsconf 時，其實他不知道怎樣辦這麼大型的活動（一次舉辦超過 1000 人，來自世界各地）。而 O’reilly 說它們有辦法承接，於是接下來幾年就都是O’reilly 在弄了…

不過隨著世界各地 Rubyconf 舉辦的越成熟，社群靠北 O’reilly 的聲音也就越來越大。多數都是靠北 Conf 地點很鳥，也幾乎沒有議程影片釋出（對比其他 Rubyconf 都有 confreaks 專業錄製）。所以今年乾脆 RubyCentral 就自己接回來辦。Chad Fowler 也說接回來自己也嚇死了，也不知道今年會不會辦到爛掉…

參加過 conf 籌辦的人都知道，一個 conf 的舉辦期間會出現各式各樣超多的鳥意外，很多事情都不是能夠預先料知的。如果會場有更多外國講者和外國參加者，那局面會更混亂。兩天下來，我真的覺得主辦單位真的超屌的，不管是廠商講者和參加者都顧得穩穩的，幾乎沒看到 twitter 上在靠北一般 conf 上面常發生的鳥事…

以下整理一些我覺得弄的不錯的地方：

1. 大會地點

這次舉辦的場地在 Hilton Austin (德州）。之前幾屆都辦在巴爾的摩（這地方幾年來一直被大家狂靠北）。來之前本來也不知道為什麼大會要選在需要轉機過來的 Austin ，而且還是在 Hilton 這個昂貴的旅館。

來了之後才發現這一切都是有考量過的。首先，知名的 SXSW 音樂節每年都辦在 Austin 這個地方。Austin 的第六大街非常有名，大概長達一公里都是酒吧。而 Hilton Austin 就在酒吧街的起點旁邊。

Conf 結束後要去吃飯、續攤、喝酒、打撞球，都非常的方便。連我這個挑嘴外國人來了以後發現幾乎不會在這裡餓死或吃到太難吃的東西（坦白說我覺得德州食物不僅不難吃，而且是非常好吃…）。

Austin 也跟美國其他小鎮不太一樣的地方是，這裡算是不夜城，所以雜貨店也不會像其他地方一樣，七八點就打烊，24 hr 開著的就好幾家。然後餐館也大概都開到 22:00（之前在西雅圖大概 18:00 以後就 Q_Q 了）。

在這裡晚上，不管在街上或者酒吧裡，都可以看到一群一群開發者窩在一起聊天喝酒。

2. 大會場地

大會租下了六樓幾乎整層。總共有 4 個大會議室（ Main Ballroom, Salon H J K )，2 個小的會議室 ( 615,616 )。

四樓租了兩個房間 ( for BOHConf )。

這是詳細的議程表。

演講廳安排

Salon H,J,K 是主要的演講廳。H 很大，是給大 track 用的。J,K 比較小，但也算大。H,J,K 中間有可拆卸的隔間。Keynote 前就會清場拆隔間將 HJK 合併，讓大會所有人可以參加。然後要開始進行 track 時再清場隔開來。

H 有兩個外接投影幕，J,K 就都只有一個。講者講台和螢幕是分很開的。似乎是方便錄影和觀眾方便觀看投影片。

(全場組合照，這是前半場，也就是 H)

(全場組合照，這是後半場，左 J 右 K 。平常用隔板隔起來。隔板隔音也很好，絕對不會聽到隔壁廳聲音)

（隔間拆除中）

贊助廠商與食物

而 Main Ballroom 是讓贊助廠商擺攤的。而休息時間時，所有的點心水果都會放在這一區，只有進來這一區才能吃。我覺得這招實在很聰明，之前在台灣參加 Conf 時，看到廠商其實在走道上都很無奈。休息時間光顧他們的人實在少的可憐。把食物放在廠商展覽區中間其實可以強迫大家一定要逛攤位，同時間社群的人幾乎也會擠在這裡，大家最後都會湧來這裡找人聊天…

( 360 度拍攝 main ballroom)

座位、電源和網路

辦過 conf 的人都知道，這其實是讓人很頭痛的一點。其實一個場地，光擠進超過兩百人，大概電力、網路、3G 通訊就會癱瘓。Railsconf 沒爆炸真的很強。

座位 / 電源

場地的配置就是擺滿椅子這樣而已，大概每兩排座位大概就有橫貫座位的延長線。不過因為地上一律鋪地毯，所以大熱門 track 椅子不夠時，可以看到滿地都是人…

網路

整棟飯店都有無線網路。我是在大會開始前兩天住進旅館的，剛住進來時其實很擔心大會網路會爆炸，因為房間網路實在無比無比的慢（一晚還要花掉我 13.95 美金 ..幹)。沒想到大會開始時，網路超級快…不僅是會議廳，連旅館房間也是。

後來才知道是因為大會贊助商直接贊助三天的高速網路的原因，直接把水管加粗。

不過唯一美中不足的就是旅館 DNS 實在不夠力。網路夠快但是 DNS 老是查到爛掉。但整體來說真的還算可以用。超過千人的會議有這樣的品質真的很強…

現場完全沒禁自己帶 AP、自己開 3G 這種事。

3. 食物

食物這方面就是台灣弄的比較好了。台灣的兩個 conf （OSDC/COSCUP) 都是自助吃到飽。而 Railsconf 的午餐是請大會發餐盒，裡面是烤餅、沙拉和水果，老實說還蠻難吃的。所以一堆人中午都跑去第六大街吃飯。

不過早餐和點心就都還算不錯，基本上就是水果、點心、果汁、紅茶、咖啡無限供應。

4. 報到 / 提早報到

在正式會議前一天的晚上六點，社群有舉辦了一個 Ignite Railsconf，大概是 10 個 5 分鐘 lighting talk，也在旅館裡的同個場地。門票只要 7 元美金。因為參加者幾乎都是同一批人，所以大會就在那個時段也同時開放預先報到，紓解隔天的人潮壓力。

我是前一天就提前報到，大會是用 Eventribe (大會售票系統）的 iphone app 查好姓名，然後直接發名牌。然後只有一個窗口。

正式報到是報到處開三個窗口，將 Last Name 首字母分成 3 等份開放報到。在整個大會期間，櫃台都有人可以問問題。

4. 不想聽 conf 的人的安排

門票三天要價 750 美金，覺得太無聊都找不到題目想聽的人應該是很少。

不過大會還是在 4F 租了兩間房間。一間給想 hack、聊天打屁的人，一間給自己想講 lightling talk 的人用，有很多桌椅和電源可以用。而議程是跟整個大會平行的，所以大會中場休息時間要是有 30 min 以上的話，不少人會跑去那裡休息充電（身上各種裝備），而且在 BOH 區的人都比大廳的人健談。我在 BOH 區打電動時，就被一個對我 MBA 注音鍵盤好奇的哥倫比亞開發者搭訕 XD

5. 都聽不懂議程的人或新手的安排

大會 talk 很多，基本上有三條主要 track 在跑。不過雖然是這種大又貴的 conf，還是有初學者會參加。大會有獨立開了一條線作 workshop，請 codeschool 團隊帶兩天基本的 Rails 開發。休息時間我有跑去看一下，人還真不少，大概 50 的人廳幾乎坐滿。除了教學之外，也有一些是講 Rails 基本工具的 talk 也會排在這個廳。而且講的人其實都算職業等級教學者。

6. 贊助廠商的議程的安排

雖然大會有不少贊助廠商，但是贊助廠商的淺 talk 並不會佔到主要 track。基本上還是獨立一條贊助 track （可以看 4/23 議程）在跑。比如說 New Relic 就是開 Panel Discussion、Cookpad 則是請 CTO 去演講 Cookpad 產品這樣。

說實在不想聽也不會被大會強迫要聽。畢竟沒興趣聽被強迫可能會對這間廠商印象更爛也說不定….

待續…

====

明天補圖還有更多細節（太晚要睡了）。下集寫的部分是網站, 手冊, local 接待, 名牌, 廠商贈品 cfs, 工作人員, 錄影, 講者投影片等等…

Startup : 如何挑選適合的 Hosting Plan?

2012-04-18T22:46:00+08:00

這個議題在今年創業潮之前算是比較冷門，沒看到什麼人在討論。最近大概是大家瘋創業，有實際上的頻寬需求，所以看到網路上又開始吵頻寬的價格，一些討論串看起來讓人都有股張飛打岳飛的錯覺。

這個主題我在三年前其實寫過類似的內容，現在環境當然有點不一樣了，被 Fox 拱出來寫一篇 2012 版的。

Hosting Plan

Simple CMS and Facebook Pages
Shared Hosting
VPS
Cloud Hosting
Dedicated Hosting
Amazon EC2

不少創業者談到開網站，始除了最原始的技術支出之外，一開始最令人覺得恐怖的就是頻寬的支出了。然後談到頻寬這個議題，接下來就會陷入 panic 。

台灣的 IDC 價格是不便宜，但不代表這樣的價格不能讓人做事，主要還是看公司的營運策略。

Bootstrap 期：利用 Tumblr + Facebook

在過去，作內容網站要直接養一批內容觀眾是困難的。創業者必須先架起一個內容網站（也許是 Wordpress 或者是 Customized CMS），探尋適合的 Hosting Plan，接下來每日寫文，做好 SEO…etc.

於是一開始會糾纏於到底要選用那種 Share Hosting 比較便宜（Blehoust? Dreamhost?）…

2009 與 2012 年，創業狀況很不一樣的地方在於，現在我們有了 Tumblr、成熟的 Facebook 行銷工具、完整的 Amazon Web Services 以及地區配套。

現今，一般的內容網站最主要的流量來源龍頭，不再是 Search Engine，而是 Facebook。一個網站若做好 facebook-optimized，成效往往會比投注在 SEO 上更加的驚人。

所以，熟悉網路議題操作者。會改用以下手法：先用 Tumblr (簡單的 CMS) + Facebook 專頁，進行議題操作養出粉絲。確定這一塊主題有一定的市場，才決定是否拓展成「訂製網站」規模。

知名網站「iCook」一開始其實就是用粉絲團的方式先去操作，買出 Application 製作的時間，即使身處在製作期也不至於造成沒有網站就沒有觀眾。而是一開始就把觀眾養在 Facebook，把人養出來之後等到網站上線後再一口氣倒過去。避免掉內容網站一開始上線沒觀眾沒內容，還需要很多時間經營的尷尬。

使用 Tumblr 的原因：Scaling

要養內容的方式有很多種，不一定需要自己弄一個 Wordpress + Shared Hosting。不過這當中最關鍵的點在於，其實一般人付不起需要自己 Host 內容網站的成本。

我並沒有誇飾。

經營不錯的內容網站，一個網站 daily 30000 PV 並不誇張，Wordpress 本身的好處是有很多第三方 plugin，帶來網站修改的靈活性。但壞處也是這些第三方 plugin 本身的效能低落。可以將這些 plugin 比喻成類固醇，短期績效很棒，但長期副作用也很強大。

若網站經營者本身不具備 Performance Tuning 能力，大概到 daily 10000 PV 規模開始，就會開始力不從心。每到當日的尖峰時段（10:00, 15:00, 22:00 ），就會倒站。

像重灌狂人這樣等級的 Blog，都要租到不錯的 Dedicated Hosting 機器才擋得住。一個月要花上一兩百塊美金跑不掉…

而 Tumblr / Wordpress.com 這種 vendor CMS，雖然修改彈性是比較小一點點，但是背後的 scaling 能力卻是完全不用擔心。就算養到數十萬 PV /daily …也不用擔心倒站。

Shared Hosting

Shared Hosting 在幾年前比較流行，主要是因為大多數的 Open source Application 還是以 PHP 為主。上傳了就能開始使用。俗稱的「空間」大部分是指這樣的方案。

Shared Hosting 大概的價錢都在 $10/month 以下。比較好的 Solution 像是 Media Temple 大概會在 $20/month 以上。

不過 Shared Hosting 就如同字面上的意思，是跟人 Shared 的。Hosting 廠商，將一台機器切成幾十份資源，租給大家。如果你有爛鄰居（spam site）或者是胖鄰居(heavy site)，很容易被連帶牽連倒站。

說人胖鄰居其實也不公平，7000/daily 的 content site 基本上就會超過 Shared Hosting 廠商提供的 CPU limit 了（超過也是倒站）。

VPS

VPS 也是這三年來變得比較成熟的 solution，主要是因為虛擬機技術的成熟 (ex. Xen) 和 PHP 以外的 Language Framework 變得很熱門（Ruby on Rails / Python …etc)

會佈署上 VPS 的 Application 共通特徵是，佈署時通常需要自訂客製整塊 stack。也就是開發者自己要搞定 MySQL、HTTP Server、Mail Server 、 Memcached Server 等等。

雖然是小網站，但這些 Server 疊一疊加一加至少也要吃掉 512 MB 的常駐記憶體空間。

VPS 市場在這幾年也有比較大勢底定的走向。一般來說，如果你要人推薦哪一家廠商比較優質？幾乎大多數的人都會推薦 Linode。

Linode 的起步價是 $19.95 USD/month (512 MB)。

除了便宜之外，Linode 的優勢在於最近這一兩年來在東京佈了點。從台灣連過去 Ping 值大概可以壓在 80ms 以下。（美國就算點再好至少要 130ms 起跳，這樣的 ping 值會讓使用者「有感」）

所以在台灣，Linode 會算是一個可以考慮的 Option。

Cloud Hosting (單指 PaaS )

雖然這樣講有點傷害到人。但是這個市場自從 GAE 改變收費模式而 Heroku 開始支援除了 Ruby 以外的其他語言之後。這個市場就變成了….Cloud Hosting = 「Heroku 與其他」。

Heroku 的模式是開發者必須按照 Heroku 規定的架構設計程式，然後把網站上傳即可。而 Heroku 本身也會提供一些基礎措施方便讓開發者銜接而不需要自幹（ex. memchaced, mail, MySQL, DNS, backup…etc.）

缺點當然就是架構在某方面被限制住了，設計修改起來不是那麼靈活。但好處是 Scaling 的問題 Heroku 可以幫你解決。資源不夠用，信用卡只要開下去就可以撐著了。

當然會有一些開發者覺得 Heroku 的收費很貴，覺得不值得。但是在真實的運營狀況中，Scaling 從來不是一個很簡單的課題。一台機器的架構當然很簡單，但是兩台、三台、十台、百台，那就幾乎不是一般純開發者能夠 handle 的狀況。

有一些開發者，如 Facebook Application / iOS 開發者，他們往往只懂設計「遊戲」和專注本業而已，而不是那麼熟 Scaling。於是他們通常會採取這樣的模式：付錢 Scale，讓事業長上去，繼續賺錢。買到時間空間之後再補人改架構。

不過 Heroku 也不是沒有致命缺點，Heroku 幾年來都只有美東的點而已，美東以外的點，從來沒有明確的時間表和承諾。我估計以後也不可能會有….（大工程）

Dedicated Hosting

Dedicated Hosting 就是租整台機器給你用，然後贈送一定 quota 的流量（大概是給個幾 T 的 free 流量，超過另算）。@gslin 在他以前的文章裡面有推薦幾家外國品質比較穩定的廠商：

當然，國內當然是…沒有推薦的廠商 XDD

Dedicated Hosting 的優點當然是整台機器資源是你的，而且換算成「單位成本」C/P 值最高。但缺點通常也是你要自己「管」。包括備份、Monitoring 什麼都要自己來。需要的底子相對功力要跟很多（VPS 多半還提供個簡單的 gui console 可以幫開發者弄備份、監視系統狀態…etc）

台灣的人會跑去租美國的 Dedicated Hosting 多半是拿來作需要高輸出流量但品質不需要那麼好（高 ping 值）的 Service ….如影音之類的 streaming server 。

因為美國頻寬非常便宜，大概是 400TWD - 900 TWD / Mbps 上下（看你的量，遠低於這個數字到非常誇張的地步的都有…）。而「反應」比較慢的這件事在「影音服務」上面相對是可以被接受的。

AWS : EC2

自從 AWS 在亞洲地區佈點之後（新加坡、東京）之後，在台灣幾乎就直接吃掉 VPS 等級這一塊的市場。原因當然就是 C/P 值真的還算夠，價格也能讓人接受。

而在地點的選擇部分，台灣 <-> 東京比台灣 <-> 新加坡來的有優勢許多（routing 和 bandwidth）。

所以很多人創業租機器的首選，就是租東京的 EC2 了。

但別以為 AWS 真的其實很便宜，它只是對一般入門者門檻很低而已（不需要保證 commit 量，「牌價」比較令人有辦法親近）。真要比較起來，東京 AWS 的流量其實比台灣 IDC 的價格還要「貴」。

在 @deduce 這篇 iCook 圖片費用的討論。

提到在 S3+ Cloudfront 上 250GB 的流量只要花費台幣 1500。不知道在台灣要花多少錢？

事實上若把 iCook 放在台灣的機房，光計流量的花費是可以低於 1500/month 的。

==== FB 分隔線 ====

250G 如果算 30 天，平均 1 天 8.3G 左右。一天流 8.3G 出去大概就是 0.83M 的線左右。所以只要租一條 1M 的線就夠擋了。如果你向 IDC （中華 / TFN ) 租一條 1M 的線，拿到的牌價可能會是 2000+ / m 左右。但是如果是一次租到 10M+ 的線，或者是去跟二房東租，絕對可以拿到 1500/m 以下的價格（900-1500 不等）

所以不可能是 40k 或 50k 這個價錢。最多只會花到原先所說的 1.5k 以下的價格。而事實上 amazon 的頻寬還比台灣純租 IDC 的價格貴，也不算什麼便宜的 CDN。只能算是刷卡就有，而且不用保證 commit 的水管….。若真要省錢的話通常會去跟國外專業的 CDN 廠商談地區性 / global CDN，不過這都是量大之後的事了….

==== FB 分隔線 ====

當然事實上也不能這樣比。因為這個價格不是 colocated，而是 CDN 的價格（雖然 AWS 價格兩者是一樣）。但說實話，CDN 比 Cloudfront 便宜而且品質高的選項不是沒有，純優質流量（Hinet/TFN）其實也比 EC2 便宜。這都不是錯覺。

只是你可能都要有一點 connection 或必須要有保證 commit 的使用量才拿得到。

對沒有「背景」的 Startup，EC2 才相對變成了「好」選擇…

IDC : colocation

以上講的都是廠商提供機器與流量，創業者不需要自己出任何設備的狀況。但事實上還有另外一種情形，就是你自己有機器，直接放在 IDC 裡面。

現在什麼年代了，大家都雲來雲去，為什麼還要自己買機器放在 IDC 裡面？

「軟體」「雲」其實不是萬能。

有一些特殊的服務和需求，不買硬體 Solution 丟在 IDC 裡面，用軟體自己幹反而會很昂貴。比如說 F5、NetApp、Bluecoat，這些東西自己幹就會很貴。所以才會有自己買設備放在機房的需求。

再來是 EC2 始終是虛擬機，而且有一些 Web services 因為業務型態，需要訂製的 Server 才能達到需求。

比如說 37 signals 的這兩篇文章

Nuts & Bolts: New Datacenter! 提到 EC2 I/O capacity 不夠
The need for speed: Making Basecamp faster 提到他們因為速度需求，需要把整個站都 run 在記憶體裡，需要那種有 128 GB 記憶體的怪物機器。

又或者是你的客戶有很強的地域性需求，比如說用戶都在台灣或者是用戶都在中國。才適合 colocation。

而租 IDC 作 colocation 並不只是頻寬支出。你要先買機器、然後租機櫃（一個櫃幾千元/月），然後才是談頻寬(2000+/Mbps)。

所以一般 startup 並不建議從這個方向直接開始。因為起步成本實在太高，而且手上沒有一定的 commit 量幾乎價格砍不下來

HiCloud

我個人對 HiCloud 並沒有什麼喜歡和討厭。因為 HiCloud 實際在我的生意模型裡面從來不是個選項。HiCloud 的模型比較像是 Hinet 提供你一個可以用「低於牌價」的機會租到優質頻寬+一小台機器資源的選項。

這是一般 Startup 在沒有向固網業者有議價能力時的其中一個選擇。

你會注意到我在這篇文章中，提到了「優質頻寬」這個字不只一次。很多沒有實際網站運營經驗者，寫文章的攻擊重點往往是擺在價格。而忽略了更重要的一個重點「頻寬品質」。

什麼樣的價格，什麼樣的品質，做什麼樣的服務

如果你平常有觀察國內一些大網站使用的頻寬。你會發現他們幾乎只會租這三家（Hinet , TFN, Seednet）的頻寬，其他的不太考慮。這是因為這三家業者互連或對國外的水管真的就很粗。網站開起來也非常的快。

當然這個現象不是絕對，但是 Web Front Server幾乎都會在這三家的點上面。至於周邊 Service 就不一定了，比如說圖片、相片就會丟在 CDN 上（省去圖床 Server 的 tunning），影片就會丟在外國機器、三流頻寬、次等 CDN 上。

都是處於架構以及 C/P 值的需求。影片可以接受比較高的 latency 所以就會這樣作，節省開銷。

網站開啟的「速度」，攸關著一個網站的 User Experience 和 Conversion Rate 。（註）

====

ref : 亞馬遜執行長貝佐斯　「性價比」最高的CEO

例如，貝佐斯不斷改善亞馬遜網站頁面下載速度，因為分析顧客使用網站習慣後，他們發現，網頁下載速度只要慢○．一秒，顧客在網站的使用時間就會減少一％。

====

「速度」影響的指標也還不僅只這些，SEO 以及 Alexa 的 ranking 甚至也有大幅相關。

所以，也不是說誰誰誰便宜，就應該喊誰誰誰應該降價太誇張。

難道 40 盎司巨無霸牛排只要 900 元，高級鐵板燒店裡面賣的「和牛」就應該比照辦理嗎？

Summary

當然，寫這篇文章的初衷只是把一些過去作網站測過和用過的 solution 寫出來。不同型態的服務，和團隊的人力配置，適用不同的架構和方案。

AWS 對一般 Startup 是友善，也是 pay as you go，只是千萬不要誤以為這是萬靈丹。

只是看到一些張飛打岳飛的討論有感 …

BTW，如果你有興趣談更多這方面的話題的話，歡迎寫信聯絡我。

如果你想研究更多美國的 hosting plan，可以上webhostingtalk.com 這個網站，這裡有很多討論。

新創網站這樣開發才夠快

2012-04-07T19:37:00+08:00

借用新創網站這樣開發才夠快這篇格式，希望不要介意。我主要是想闡述以前在 T客邦的經驗方法。

T客邦在一年半裡面，就從台灣 Alexa 400 名以外，衝進台灣 Alexa 100 名內。這一年半時間技術團隊開發出了四個大網站，十數個子網站，和背後一群深厚的基礎建設（HA, backup, PV stat, advertising system…etc.)。T17 實際開發的工時在 2.5 個月以內。

我是一個軟體工程師，過去六年我都在開發網站。在新創公司裡，速度節省時間、時間就是金錢、金錢就可以再去請更多工程師讓整個開發速度更快。學校並沒有教很多「軟體工程」的方法，或是怎樣才算是一個好的Programmer。這些東西在台灣業界其實不存在的，大家都是邊做邊摸，從經驗中學習。我從書籍上和網路上學了很多能讓團隊更有效率的做事方法，因為我相信我在新創團隊裡我必須先這樣，用業界公認覺得快，且快得有道理的方式。底下是幾點可以和大家分享的。

1. 讓全團隊都用一個成熟的開發框架和環境：

我的專長是 Ruby on Rails。我並沒有偏好推薦別人如果現在是用 PHP 或 .NET 或 JAVA，就要不計成本的導入新框架。就像我其實也沒有很喜歡硬導入 Scala 或 Node.js 一樣。它們可以在它們派得上用途的地方加分，但是絕對不能是主體。道理很簡單，我不認為他們成熟到夠讓所有成員快速上手，不重造輪子。

一般團隊喜歡用 PHP。因為 PHP 工程師好找，Rails 工程師不好找。但在我一路走下來的經驗，我認為這是一個「假命題」。因為在人力市場和公司實際運作的狀況裡面，你會發現這個命題不怎麼牢靠。沒錯，你是找的到 PHP 工程師，但很抱歉，很多人寫的 code 是不能用（更精確的說是 write only ) 的居多。（我沒有冒犯 PHP 開發者的意思）

原因是 PHP 開發並沒有太多一致性的規範，基本上就是愛怎麼寫就怎麼寫。這導致了即使你團隊裡面就算裡面有一個很厲害的開發者，也是沒有多大的用處。因為大家 coding style 不一樣，甚至連網站結構也不一樣。補人幾乎是沒有辦法發揮到加成作用，大家只能各寫各的，就算爆炸了也幾乎只有當初的作者可以修。

這在我眼中是極度浪費團隊戰力的元兇。

Rails 沒有這樣的狀況嗎？這是我覺得 Rails 優勢的地方，它是一個非常熱門的 Framework（只有在台灣你可能沒有感覺到他很熱門）。因為這是一套 Framework，也就是它本身有很強的約束性，至少 MVC 和 routing 規則，一般就算新手也不會亂放的太離譜。寫 code 有一定的潛規則存在。

開發中遇到任何東西發生錯誤了以後，開發者幾乎可以用 Google 找到任何可能發生的原因，修復完畢。而這幾乎不是一般自建 Framework 可以比的上的地方，如果你在公司自建一套 Framework，基本上發生任何問題，最後幾乎都得去煩當初設計的 Architect 才行。（這也是很浪費錢的地方，因為 Architect 的薪水都很貴）。

學習曲線過高，我也不覺得這件事真的存在。Rails 高手是難尋沒有錯，但是 Rails 中低手只要訓練得當，生產力也是非常驚人。因此只要把重心放在如何協助一般想入門者，可以快速克服入門幾大門檻（搞定開發環境，RESTful，Plugin，Debug，Deploy），剩下的部分就可以靠網路教材和實戰訓練出來。這也是我發明Rails 101 的原因。

我設計這一套教材的目的是要讓所有新進的開發者，在最長兩週時間內要學完基本 Linux 指令、Git、Rails 所有基礎的知識、佈署、SCSS 撰寫等等，一個月之內就能上戰場跟我們一起開發功能開發新網站。這樣的進度很誇張嗎？不，不誇張。這裡的每一個開發者都有這樣的程度，他們有些人應徵時是連 Rails 都不會寫的。你能相信連 T 客邦的 PM 和 ART 他們也會寫 Rails 嗎？( no kidding)

寫 Code 規則怎麼規範？同事和我從社群中吸收了很多 Best Practices，我們把這些東西整理出來變成新手指南、最佳實踐，甚至是包裝成 Gem 和 Generator，越後進的開發者能花越少的時間追上前輩，在短時間他們的作品也能跟前輩一樣預先搭載 Best Practices。我最近也開始在撰寫另外一本書 Essential Rails Pattern for Beginners

Rails 本身還有豐富的 Ecosystem，和預設的架構最佳實踐就更不用說了。

新創團隊資源很少，人事預算沒有這麼夠，反而要巧妙的運用天然資源並讓團體戰力*3才行。

2. 功能設計給當下使用，考慮一定程度的擴充性：

我也不相信在新創團隊有人可以預知未來，即使很多東西看起來未來往那個方向擴充很合理。對我來說，我在設計功能時並不會 overthinking，甚至我也禁止同事 overthinking。因為專案中最高的原則是 get things done，not over design。

但這不代表不需要在設計上不需要留一定程度的擴充性，在內部的工作流程通常最後一道是有 refactor 整理空間的。在這時候同事會把雜亂的 code，整理回當初規範中必須寫的樣子。如果這是常見功能，一再出現，就必須整理成 Library，或架構 Pattern。一但是 Pattern，擴充性就留出來了。

在之後新的專案中，就可以拿上一個案子打下來的基礎一再重複利用再利用。甚至最後竟然還有 Event Generator 這種東西…（Authenication , Rails Admin, SEO, …etc.)。

3. 程式本身即註解

一般軟體實踐上本身也不贊成寫註解。而是鼓勵程式本身即要可以表達自己的行為。如果寫的程式亂七八糟讓人看不懂，進 review 時是會被回退的。我們團隊能夠被接受的程式是可以寫得很笨拙，但每個同事都看得懂。因為笨拙但能理解，其他前輩有時間可以去 refactor。但亂寫，之後就沒人動得了了。

4. 盡力寫下所有的 documentation

世界上沒有人能夠寫出一份完整的系統架構書可以詳盡的描述現在系統上真實的狀況。但是一個好的 issue tracking system 和寫的 commit log，可以能夠很好的協助你了解為什麼現在系統會是這樣設計的，為什麼當時會做出這樣的決策，導致程式必須要這樣設計。

在新人訓練期時，我通常會訓練新人要有將任何實作上遇到任何的 detail 和狀況詳細 document 在票上的習慣。而在完成整個專案時或者是技術架構稍具規模雛形時，要把這些 ticket 上的筆記梳理紀錄下來。

這樣會對整個團隊程度的躍升會有非常強大的正面效益。同時在人員流動（新進或離職時，衝擊會非常非常的小。

因為至少很多的 “basic” 的教育成本，在這部分會幾近於 0。一路都在 startup 的歷練，讓我很早就理解到一件事，人員流動幾乎是無可避免的，所以重要的是要怎樣讓人員流動造成的衝擊更小。

在新創事業讓同事投資一項新技術，也是很昂貴的。所以要學的話，大家一定也都全都要會，否則就會一直很貴。

這是 documentation 可以帶來的價值。

5. 要有測試環境和 policy

從昂貴的教訓裡面我學到的就是一定要有測試環境和 policy。在 Rails 中將環境切分成好幾份，並沒有超困難。而且一定要有測試環境（staging），是因為每個人開發的環境不一樣，在當下 focus 在自己電腦前，很多設計並不會考慮那麼多。丟上 remote server 你才會知道炸掉一大片，或者是 performance 極度不好。這都是會傷害商業 credit 或者搞砸交易的（比如說你跟客戶談好明天 on 檔一支幾十萬的廣告，但明天因為人為疏失倒站一天，請問你要去挪誰的 queue 給他，一天到晚發生這樣的事。誰要跟你做生意？）。

至於 policy 就更重要了。

很多加班的狀況其實都是不必要發生的。比如說在頭腦不清醒的時候寫了爛 code commit 上去。導致自己清醒時要去清理這攤爛泥。在吃飯前或下班前 deploy 了最新版的 code，結果中午倒站數小時；原本可以準時下班，十點都走不了。

但寫了好東西不直接 commit master 和不馬上 deploy，會讓 RD 非常癢。這種病連我都不能倖免。

但是商業網站是不能一天到晚失火的，團隊還是有人要去捍衛這種大局。所以最後也只好執行了這樣的規範：

寫功能一律上 feature branch
上線前必須使用 staging server, apply feature branch 測過一輪
絕對不在中午 11 點 - 12:00 deploy，絕對不在 17:00 後 deploy。
deploy 流程必須使用工具自動化，出事要能 rollback。

執行了這樣的 rule 之後，幾乎就沒有人需要餓著肚子修 bug，半夜因為軟體的問題跳起來加班修理了。

因為我深信：長期處在失火/救火的環境下，會快速減低一個團隊的戰力。

熱血的投入通常會讓人有假象，我投入的工時越高，成果會越好。事實上這是一個徹底的偽命題。而創業初期的不穩定，忙碌，失火，更讓你會有只要我努力加班，一切就改善的錯覺。腎上腺素最多只能讓你撐三個月，接下來一切都會破滅的。作一個網站要到可以出場，大家比得是命長，而不是 Startup weekend 冠軍。

6. PM 的話聽聽當參考就好，但要好好溝通

在很多情形下，PM 也許規劃出來的方案 A，需要 10小時。但你知道可以把它改變成方案 B，只需要 3 小時。但前提是，你要好好的去追問出來，為什麼他會做出 A 設計案這樣。不可否認台灣具備專業素養的 PM 極度稀少，能遇到一個就是燒香了。所以很大的程度遇到的可能是一個只會照抄其他網站畫架構圖的人，或者是負責賣廣告的Sales 自己兼，但這都不要緊。要緊的是你要問出為何這樣設計，因為他的外行程度可能會讓他估出一個讓公司嚴重虧本的實作案，你卻沒阻止他。或者是這個案子架構是合理的公司方向，但你卻誤解背後的設計原理擅自修改而失效：

一個設計方案會這樣設計的背後原因有很多個，有可能是：

PM 路上隨便抄
PM 自己喜歡這麼作
ART 要求
客戶要求
這是 key feature, 一定得這樣作, 否則失去此系統意義

所以不能是自己喜歡 B 就 B。開發一個系統一定有「成本」、「預計收益」，而實作的方案必須要去找出這兩者的平衡點。這就是靠溝通溝通溝通…

7. 要寫出一定程度的程式碼

要使用 HTML / CSS 架構設計網頁，不要濫用 ORM，不要重造輪子，不要寫出會被人公幹的 code ，這些都是基本的開發常識。很多新創網站寫出第一版很快，但之後就陷入開發泥淖，無法配合業務模型快速調整，幾乎 90% 的原因以上都是因為第一版 code 爛到當初的開發者自己也改不太動，結果光是後續調整架構作小改版就耗掉超多時間，變成超大致命傷。

8. 要追求一定以上的網頁效能，tune 在刀口上

不追求效能實在是一句非常不可思議的話。

不可否認有些開發者效能和 Fancy 技術實在追求過頭，比如說甚至一開始就用 Backbone 寫整個網站，或者是從頭到尾使用 Node.js 寫網站。這都是一開始就打算寫 mobile 版 web service 給 mobile phone 使用才需要做的事。因為 3G 的 Latency 實在太大，要盡力的壓縮頻寬使用量和追求頁面 response time。

但實作一個 Desktop 版網站完全沒必要。而在 website performance tuning 的時候，優先調整的也是 Frontend Performance，因為 C/P 值高很多，壓縮一下 CSS 也許就可以省 3 秒。db 或程式語言 tune 的要死可能才省 0.1 秒。

而網站的指標和 User Experinece 並不是說打的開就好。比如說網站開的速度會直接影響 Search Engine 和 Alexa 排名，不知道這到底有多少人曉得？還有一般使用者對於 Blog / Album 和 Video 各自能夠忍受的 response time 根本是不同的，Video 大家可以忍個 5 秒還沒打開都能接受，但是相簿和網誌開一頁要 5 秒這大概就沒人要用了吧…

效能調校這件事，過與不及都是不好的事。

9. 少用 Fancy 的東西，實作前先估算成本與效益

身為開發者，世界上每天會冒出很多新的好東西，這些不去玩玩看手實在會手癢。但是其實每引入一項都會有一定的成本存在，而且效益/成本比不見得是你當初想的那樣。

比如說一直追 Rails 新版，換上效能很好的 Ruby 1.9.2，改用 SCSS 去寫 CSS，改用 CoffeeScript 寫 JavaScript。Apply 新發明的 Asset Pipeline 架構。這些都是很新很棒的東西。（T 客邦都有，架構從最早的 2.3.2 一直 upgrade 到 3.1.3，內行人才知道這樣工程有多大）

但跟其他事物的道理其實是一樣的，新的東西就有新風險。而且通常引入這些東西，不是自己一個人爽就好，是大家都要用的東西。

所以通常我是這樣做的：先 branch 一個版本，我自己或是請資深 RD 自己下去把整個實作方法都做出來或者是進行評估，確定可行後整理成可行的 SOP。才大符推行。

如果是新想法，則是在一個 event 或是小版面先行製作嘗試效果。

好的東西是不錯。但不要孤注一擲。

======

綜合以上，我想說的是：在開發初期，任何一點戰力都是相當寶貴的，所以沒有什麼理由把程式碼亂扔，不實行一定的規則而導致到處都失火。永遠都在作重複的白工。

任何舉措，最好都要是能以盡量把成本壓到差不多低，但效益都非常高。

以上我上面所說的這些東西都不是我的創舉，事實上幾乎所有 Rapid Development, Agile Development, 還有很多 Engineering Blog 常常都在聊這樣的話題。

我發現很多工程師朋友常常有自幹且認為自己的東西最好的傾向。認為外界的方法「絕對」不適用在自己的團隊上，美國的常態並不適合在台灣使用。但事實上這世界真的非常大，說實在真的沒什麼理由把自己的成長速度綁在自己的眼界裡面，很多的 principle 在不同產業不同國家都是適用的。多看看別人怎麼作，你會驚訝這些方法的引入，對自己事業加成的幅度是多麼驚人的。

P.S. 貢獻一個不是八卦的八卦：T 客邦從來就不是一間網路公司，這是一支傳統出版社裡面的數位團隊。技術團隊大概永遠只有五個人： 1 Leader, 1 PM, 3RD, 1 ART。兩年以來幾乎都是這樣的狀況…

為什麼必須使用 Issue Tracking System 管理專案？

2012-03-26T03:14:00+08:00

我在網站程式上線前需要準備的事（四）提到了為了順利進行專案，一個好的專案管理系統絕對是必備的。

專案管理系統背後運作的邏輯何在，就是這篇文章主要的重點。

What is issue tracking (project management) system ?

Issue Tracking system ，顧名思義就是紀錄、追蹤 問題的系統。BugZilla、Trac、Redmine、JIRA、lighthoustapp、Basecamp …等等這幾套軟體，都是知名的 Issue Tracking system。

一套合格的 Issue Tracking system 的 Issue 至少要可以紀錄這些內容：

Issue 的主題
Issue 的內容
Issue 現在的狀態 (新建立、已指派、已解決、已回應、已結束、已擱置…etc)
Issue 優先權 (正常、重要、緊急、輕微、會擋路…etc.)
Issue 發生日期
Issue 希望解決日期
Issue 實際解決日期
Issue 被分派給誰
Issue 的附件
Isuue 的觀察者有誰

Project Management Tool

其中 Redmine、JIRA、Basecamp 並不僅止是 Issue Tracking System，更精確的來說，它們應該被稱為「專案管理工具」。

它們多半能夠提供以下作用：

一個地方可以透明的列出所有需要被執行的項目 (Issue List)
一個地方可以列出階段內需要被執行的項目 ( Issue Milestone )
一個可以記載內容，狀態、優先權、日期、分派者、觀察者，且具有「permalink」、「權限控管」，且讓大家可以討論執行項目細節的地方。(Issue Ticket)
可以 cross reference 或具有子票功能
一個地方可以整理統合專案現在所有的相關資訊。( Wiki 功能)
一個地方可以看到自己今天需要 Focus 進行哪些項目（Issue Personal Dashboard)
一個地方能讓 Manager 可以看到自己的 Member 正在進行哪些項目，這些項目目前的狀態是什麼。（Issue Query)

背後運作的原理

網站程式上線前需要準備的事（四）這篇文章刊出後，得到不少的迴響。其中我看到的絕大多數的回應多是多半抱怨 PM 根本不稱職不盡責，只顧著畫規格，然後只按照自己寫出來的無法執行ㄉ的天才（？）規格的催進度。所謂的 M 不是 Management，而是 Magic。即使成員賣了命的加班，專案還是得不到好的結果：超時，品質粗糙，成本過高，scope 過大無法完成。

在我進行開發軟體專案時，也發現所謂的其實絕對多數的 PM，其實職稱與進行的事務完全不合。它們的工作內容往往只有 Project Planning，應該被稱作是 Planner，而不是 Project Manager。

一個軟體開發專案，最重要的變數有四：成本、品質、時間和規模。真正的 Project Management，是能夠準確 Manage 這四項變因，在可以接受的與變動差異下，完成整個專案，產出預期的成果。

我認為 Project management tool 可以協助做到專案中以下幾項的管理：

規模管理

專案會無限膨脹，主要多半是因為規模的掌控不佳。而規模掌控不佳，時間和成本就會隨之膨脹。

規模之所以膨脹，有幾個原因：

沒有人知道，到底「總共」有多少事情需要完成。
離目前的時間表，「還有」多少事情需要完成，還有多少時間可以用。這些事情裡面有沒有可以被「調整縮減」的餘地。

所以，專案需要一個工具能提供以下功能：

一個地方可以透明的列出所有需要被執行的項目 (Issue List)
一個地方可以列出階段內需要被執行的項目 ( Issue Milestone )
一個可以記載內容，狀態、分派者、執行者，且讓大家可以討論執行項目細節的地方。(Issue Ticket)

時間管理

一個專案中，最寶貴的資源是「時間」。什麼東西都可以用「錢」買到，唯獨時間不能。在專案中時間最容易被浪費的地方在：

使用信件往來，交涉的互相等待時間。
沒有被壓定「完成日期」，「詳細需求品質」的工作細項。（陷入不必要的完美，或者是悠哉的怠惰）
不符合期待，修改的來回時間。（沒有達到良好溝通，導致方向錯誤）
類似的事情，重複消耗資源。（沒有 SOP，每次都要花費一定以上的資源去解決）

所以，專案需要一個工具能提供以下功能：

一個可以記載內容，狀態、優先權、預計完成日期、分派者、執行者，且讓大家可以討論執行項目細節的地方。(Issue Ticket)
- 可以平行討論，而不是信件順序往來
- 明確的完成時間
一個地方可以整理統合專案現在所有的相關資訊。( Wiki 功能)
- 提供專案相關的資訊以及 SOP

同時，專案最好能夠搭配舉行每日的 Standup Meeting，確保每個人正在進行的方向是正確的，以及確保專案資源沒有被浪費的跡象。

團隊工作管理

一個專案，成員至少會有兩人以上。兩個人以上，就會有溝通與工作協調安排的問題。專案的工作項目往往是有 related 的，少有獨支。比如說 Planner 沒有把規格寫完，RD 和 Art 就不太容易先動工。沒有把 Database schema 規劃好，後續就很難繼續開發程式。

這也是專案當中最傷資源的狀況：優先權等級為：「block」票。因為 A 方沒有交付，導致 B 方不能交付，連帶導致 C 不能開始。

而專案當中也有很多工作項目分別是「對最終專案目標很重要，但當下不重要」、「對當下 milestone 很重要，對最終目標沒那麼重要」，「只對合作同事很重要」…etc

如果工作項目不能夠按照當下狀況調整正確的優先等級分派給團隊成員。就很容易會造成所有的人雖然很努力，整體工作效益卻非常低的情形。

當然，不只是 Project Manager 需要知道全部的人今天要做什麼。而被分派到項目的成員，也需要能夠知道自己當天所需要執行的項目依序是哪些，按照優先狀況完成。如果優先狀況有錯誤，可以及早告知資源協調者 (Manager) 。

所以，專案需要一個工具能提供以下功能：

一個地方可以列出階段內需要被執行的項目 ( Issue Milestone )
一個可以記載內容，狀態、優先權、日期、分派者、觀察者，且讓大家可以討論執行項目細節的地方。(Issue Ticket)
可以 cross reference 或具有子票功能
一個地方可以看到自己今天需要 Focus 進行哪些項目（Issue Personal Dashboard)
一個地方能讓 Manager 可以看到自己的 Member 正在進行哪些項目，這些項目目前的狀態是什麼。（Issue Query)

資源調配管理

Project Management，並不是在專案的一開始設下「完成時間」，切出所有「工作項目」，列出「完成目標」這麼簡單。隨著專案的進行，開始會有很多變因出現，造成資源不足，需求改變，規模追加，人力減少…等等的挑戰障礙出現。

都在考驗著專案經理對於資源調配的管理能力。能不能在預定的時間、預定的預算、預定的人力資源內，如期完成當初設立的目標以及交付達到品質要求的產品。

如果條件不允許，當下必須作出取捨、做出決定，而非死板的捍衛規則與命令。

所以，專案需要一個工具能提供以下功能：

一個地方可以列出階段內需要被執行的項目，並可以移動改變階段項目。 ( Issue Milestone )
一個可以記載內容，狀態、優先權、日期、分派者、觀察者，且讓大家可以討論執行項目細節的地方。(Issue Ticket)

Agile Method

若讀者對於專案管理有興趣的話，研究過一些「敏捷開發」的 method，不管是 XP、Scrum、Kanban…，你會發現到這些工作方法都在傳達幾件類似的事：

專案必須透明，進行局勢一目了然
專案要能拆分成可執行的階段
溝通、溝通再溝通
不斷的消除浪費
不斷的 deliver

而一個好的 Project Management Tool 能夠輔助專案具備以上的特徵。

小結

還是老話一句：真正的 Project Management，是要能夠準確管理，成本、品質、時間和規模這四項變因，在可以接受的與變動差異下，完成整個專案，產出預期的成果。

「Project Manager」必須要做到的事，也就是要在動態的環境下，利用種種手段盡力讓這件事發生。

所謂的「Project Management」其實可以用很科學的手段達成，因為事實上這本身就是一門科學。

一般所謂的 PM 很常誤以為 Project Management 就是用 mail+excel、口頭分配任務，得到專案成員的口頭回覆，接著只要坐著回去發呆或無時無刻的跑到座位上催專案成員作事，整件事情就會發生。如果你真的一直這樣想，我想可能最後程式設計師可能做的事：就是直接用 shell script 換掉你。

no kidding。

Thinkgeek : Go away or I will replace you with a very small shell script

Essential Rails Pattern 開始 update

2012-03-24T18:33:00+08:00

Essntial Rails Pattern 這本書已經進入排版階段。

各位已經購買的讀者，近期信箱應該會開始一直收到本書的 update。

感謝你們一直以來的耐心等候。

這本書絕對不會讓你們失望。

===

樣章線上預覽。

線上預覽

如果有任何書籍內容錯誤，和 Billing 上的問題，請透過聯絡表單通知我，協助我改善產品。

如果你有任何學習 Rails 上的問題，請不要害羞，直接上 Ruby Taiwan Group 詢問。

網站程式上線前需要準備的事（五）

2012-03-19T02:13:00+08:00

第 5 件事：Close Alpha Test、Close Open Test

終於談到跟這個系列標題比較吻合的內容了！最後一個月上線前該做些什麼事？

在本系列（一），我提到了無論如何最後一個月是測試期。這一個月又分成

close alpha
close beta

Close Alpha 內測 (一週)

close alpha 的對象是開發組以及營運組人員。也就是與核心較為相關的組別。此時針對的測試目標是這個 project 業務上應該被「實作」的 functionalty。比如說是食譜網站，就應該可以

上傳食物照片
新增烹飪步驟
站方精選
有熱門食譜、新進食譜
分享到社群網路 …etc

如果是討論區，要應該可以

可以發表文章
可以回應文章
可以貼圖
可以收藏
可以搜尋
編輯器運作正常 …etc.

另外測試時要擬定使用「未登入會員」、「登入會員」、「營運權限」、「Admin 權限」各測過一次。

因為開發組成員在撰寫功能時，為了方便，幾乎都是以 admin 帳號在開發，如果不制定測試步驟和角色，很容易沒測到死角。

此時的修復重點放在 feature complete ( 或取捨 ) 以及 functionaly 是否正常運作。

請不要在此時進行任何 UI 動線調整 。

Close Beta 半公測 (二週+)

close beta 的對象是全公司所有人，公司員工的親朋好友，可以信賴的死忠會員等等…etc. 此時針對的測試目標是這個 project 的 UI 動線。

如果是討論區：

發表的動線是否順暢
是否 UI 的暗示容易讓使用者 miss 掉上傳照片步驟
回應文章的動線是否流暢
網站新訊息的流動是否不夠快速，容易造成網站看起來一片死城。

此時已經是視同準上線了（所以 Close Alpha 階段的資料會清掉），所有營運組的人必須視同營運狀態一樣運營站務，以避免正式開站遇到狀況時手忙腳亂。

（這一招是從參訪壹電視時學到的。當時壹電視快開台時有受邀去內部參訪，當時聽到他們已經內部試 run 報新聞 run 了一年時，震撼非常…XD）

此時的修復重點放在 UI 動線的調整，以及運營方針、步驟的調整，避免開站之後網站就變成死城。

Performance Tuning 與 Website Optimized （一週）

我在開發階段時，最常向 RD 宣導的事情是：我不想管你這個功能怎麼寫出來，但我要你準時交出來。（但最少要符合內部寫程式規範，有辦法讀懂）

原因是：網站最重要的是 Deliver 上線。而不是站上的 feature 用了多屌的技術，用了多棒的 best practices，沒有用戶會在意這件事。而「貪玩」「遲交」會砸了一切。

直到 Open Beta 期，Optimized 這件事都不會被提到。因為在網站稍微 stable 之前，所有的 optimized 都毫無意義，做了也是白作。因為會發生效能瓶頸的地方，永遠在你設計時意想不到的地方。

Backend Performance Tuning

如何作 Performance Tuning？

抓出最慢的地方 Refactor 掉

幸運的是，我的專案都是 Rails Project，有New Relic 這套軟體可以用。它可以幫你找出你的網站哪一段 Ruby Code 特別沒效率，哪一段 code 製造出來的 SQL query 特別 slow。

其他技巧請看：Rapid development with Rails P.54- P.59

這是其他題目了。有空我會再整理 update 一篇 Rails Performance Tuning 的文章。

找出最常造訪的頁面壓力測試

既然已經進入 Open Beta 期了，這時候手上應該可以拿到這個網站最常造訪和效率最差的頁面。

可以使用 ab 去對網站進行壓力測試。

再決定是要 refactor slow code 或者是先上 cache 檔著先。

Frotend Performance Tuning

影響網站使用者感受最大的其實不是 backend 的效率，而是 Browser side 的效率。上線前我會

按照 Best Practices for Speeding Up Your Web Site 調整

其他技巧請看：

Rapid development with Rails P.42- P.53
Scaling Rais Site by default

Website Optimized

以上說的都只是 Performance。但是這跟實際運營沒有那麼大的正關係。我擅長開發的是「內容網站」以及「社群網站」，這一類的網站重點其實是 SEO 以及社群穿透力。

SEO 以及 Facebook OpenGraph

比如說：這是在 T 客邦累積出來的兩套 gem。

網站的每一個頁面都會確保分享至社群網站是正常的。

Advertising

靠廣告賺錢，所以要調整廣告板位

RSS / Email Subscribe / 粉絲團活動經營操作

跟 user 的互動…etc.

開站

這些都確認沒什麼問題了，然後才是開站。然而開站不是這一切的結束，還有其他事情需要作…

＝＝＝＝

系列文章：

網站程式上線前需要準備的事（四）

2012-03-18T16:12:00+08:00

第 4 件事：架設一套 issue tracking system

你用什麼工具來管理軟體專案的進度呢？我曾經一度認為使用 issue tracking 管理專案進度，是一件天經地義的事。大家都是這麼做的，所以這個題目沒什麼好談的。後來，我才發現這個印象大錯特錯…

絕大多數的人真的只用「mail」和「cc」來管專案，that’s all。(註1)

P.S. issue 真的太多的話，他們會改用 …Excel！！

ZOMG…

What is issue tracking system ?

一套合格的 Issue Tracking system 的 Issue 至少要可以紀錄這些內容：

Issue 的主題
Issue 的內容
Issue 現在的狀態 (新建立、已指派、已解決、已回應、已結束、已擱置…etc)
Issue 優先權 (正常、重要、緊急、輕微、會擋路…etc.)
Issue 發生日期
Issue 希望解決日期
Issue 實際解決日期
Issue 被分派給誰
Issue 的附件
Isuue 的觀察者有誰

為什麼 email 不管用？

常人使用的 email 管理法其實會有幾個很大的缺點：

喪失時間感、無確切完成日期

專案中最珍貴的資源無非是「時間」。僅使用 email 往來，會造成一個嚴重的假象：大家都一直有信件往來，所以整件事其實是有進度的。但其實，專案進行的速度卻是牛步…

後面的原因其實是因為：「回信」是一個「順序」執行動作，當一方回了，下一方才能決定要做什麼、要回什麼。「什麼時候」再回（有空回，做完回？）其實沒有人知道。通常一個來回就要搞掉一個上午，甚至是一個整天。但其實整件事沒什麼進展。

這麼浪費效率，逼得某些 PM 還得自己用 TODO list + email tracking label 才可以勉強控制這種局面。

無確切執行人

有的 email，cc 者一大堆：A 先指派了 B 作這個工作，但 B 做到一半覺得需要 C 的火力支援，於是把 C 加入這個討論串裡面。C 做到一半覺得不妥，請示長官 D 要如何配合這個專案。往往一整個 mail 牽扯了一大堆人進去，大家討論來討論去，好不熱烈。

但是呢…誰需要去執行，哪些事需要被執行，什麼時候這些事需要被執行完畢？在這一整個串裡面完全被模糊掉了。

洩密

cc 者一大堆。怎麼分得清楚誰有權知道、誰無權知道這一串信裡面提到的執行事項？

優先權的分配

一個專案可能同時間有幾十上百條待處理事項需要被執行。請問哪一條需要先被執行？它們的優先權又是用什麼標準決定的呢？

處理事項目前的執行狀態

一個較具規模的專案，可能不只一個人參與（多個 RD 和多個美術）。到底誰正在執行什麼項目，會不會相撞（項目、執行者）？什麼項目其實已經完工了，需要被 archive 起來？資訊有沒有 outdate 問題？

Email + Excel 其實很不夠用…

What you need : Project Management Tool

其實由這一連串的問題整理下來，可以清楚的發現，一個專案需要的是什麼？這也是 Project Management Tool 可以提供給你的東西。

與其說 Redmine、JIRA、Basecamp 是 Issue Tracking System，更精確的來說，它們應該被稱為「專案管理工具」。

要能夠的讓專案項目有計畫且順利的被執行，需要：

一個地方可以透明的列出所有需要被執行的項目 (Issue List)
一個地方可以列出階段內需要被執行的項目 ( Issue Milestone )
一個可以記載內容，狀態、優先權、日期、分派者、觀察者，且具有「permalink」、「權限控管」，且讓大家可以討論執行項目細節的地方。(Issue Ticket)
可以 cross reference 或具有子票功能
一個地方可以整理統合專案現在所有的相關資訊。( Wiki 功能)
一個地方可以看到自己今天需要 Focus 進行哪些項目（Issue Personal Dashboard)
一個地方能讓 Manager 可以看到自己的 Employee 正在進行哪些項目，這些項目目前的狀態是什麼。（Issue Query)

至於我個人一直以來偏好的系統，就是 Redmine。尤其是近一兩年的版本，Issue Query 的加強和子票 / 相關票的功能被開發出來，讓我在專案管理上更加的得心應手(註2)。

簡單歸納

專案往往會搞到失火，或是時間不夠用。問題往往出在整個專案之間的「不透明」。

搞不清楚總共有多少事需要完成
搞不清楚目前這件事的進行狀態
搞不清楚今天要進行哪些事
搞不清楚現在正在做的事，是否跟「目前」的全局有強大的正關聯
搞不清楚哪些事必須在何時就需要「確切」的被完成，否則就會產生重大風險

要讓專案順利上線，一套好的 issue tracking system 是不能少的啊。

註 1: 我一直以為裝個 issue tracking system 是常識。為什麼會寫這種「常識」等級的東西？因為我後來發現這完全不是「常識」，特別對「PM」來說不是「常識」（顛覆了我的認知…orz）！之前在某社服務時，就發現他們竟然沒有這種東西，提議要部門內架設還被當作是異類。接著所有高階主管討論了超過一個月才勉強決定要裝 issue tracking。接著又花了兩個月的時間討論要裝哪一套 issue tracking，再花了一個月才把決定好的 issue tracking 架起來。真是嘆為觀止！…實在受不了種種的低效率，最後早早 say bye。
註 2: 切票示範 (已取得授權)
- Redmine Nested Ticket Sample : http://www.flickr.com/photos/xdite/6469521821/sizes/o/in/photostream/
- Redmine Milestone Sample: http://www.flickr.com/photos/xdite/6469526205/sizes/o/in/photostream/

＝＝＝＝

系列文章：

網站程式上線前需要準備的事（三）

2012-03-18T02:48:00+08:00

第 3 件事：制定 Art / RD 都遵守的開發 convention

在傳統的開發過程中，作法多半都是：規劃 => UI / 畫面設計 => 程式設計。

其實若專案規劃階段結束的早（也就是實作類似最低可行產品產品的概念），並非需要等待 UI / 畫面設計完工，才可以進行到「套版」（程式設計）的階段。

一直以來，我都認為「套版」是一個非常不好的說法，造成了偏差的印象。因為一個網站實際上是「一整套」的「軟體」，並非是「畫面」設計的出來，程式就配合寫的出來。雙方必須都要是可以執行實作的部分才行。

程式一定要實際的「美術畫面」被設計出來才能夠被接著實作嗎？其實不是這樣的：只要有 wireframe，RD 往往就可以先行動工。

但問題來了：若雙方各自進行自己的部分，那最後要怎麼組起來？

這其實還不是最大的問題。

最大的問題，其實是 Art 切出來的「版」，多半是不能夠被「套」的。

畫面不是切得出來就能「套」

這個問題其實不能夠怪 Art，它們有的是藝術細胞，並非邏輯細胞。而：

能夠熟練 Photoshop，並 不代表 能夠寫出良好結構的 HTML 與 CSS code。
- 這需要一定的經驗以及技術實力。
能夠切出 HTML 與 CSS，並 不代表 這一份原始碼，可以被實際使用。
- 有一些 Art 只懂得 PSD to table，整個畫面毫無結構可言，讓人頭痛萬分。
- 有一些 Art 專精製作單頁的活動頁面，但 application 需要整套的 DOM 能夠重複利用，CSS 一旦被重疊使用時大爆炸。

在傳統的專案進行到「套版」階段，程式開發進度會難以掌控的其中一個原因。也是因為：RD 面對著一套爛 HTML，完全不知從何下手「套」進去。不改結構無法讓程式運作，或者程式運作效率會很低；但一改結構，就別肖想 Art 再幫你調整細部 style 和追加細節了。（東西被改的不爽情緒或原始結構被改變）

「套版」這個過程中無端被追加浪費了大量時間，這也是一個上線前的隱藏變因。

解決方法：製作一套 HTML / CSS 設計準則

多數的 application 有固定結構的 DOM。差異在於 <div id="content"> </div> 內的不同。至於

header
sidebar
warning
form
footer
etc…

其實多半是相同的。

與其抱怨 Art 切出來的東西不能被套，不如設計一套 general 的實際準則可以被大家遵守學習。

不僅僅是 HTML 設計規則，其實開發當中會花掉很多時間的，還包含一些常見的 CSS hack / IE hack。這些也可以被整理起來，節省開發時間（當然，現在你只要學 compass 就好）。

平行開發互動：解決多人團隊的偏好歧異問題

剛剛有一個問題我們沒有回答到：就是個人偏好如何「組合」？

比如說美術的版裡面有這樣的 DOM <div class="article"> </div>，class 是 article。

但是 RD 實際的程式碼卻是 post 這樣的物件名稱。

<% @posts.each do |post| %>
  <%= post.title %>
<% end %>

這樣「套」起來不是很有問題嗎？如何實現所謂我說的「平行開發」？

其實 Art / RD 雙軌平行開發，才可以有效的為專案爭取到時間。

其實之前的所謂「套」，因為有完工的時間壓力，DOM 往往不能夠被更改。但是不改 DOM 又不能讓專案繼續被執行下去。

若是雙方平行開發，又有一個 deployable 的 application 讓進度透明，所有的修改和溝通調整，只是一下子的功夫(article 與 post 的不同，可以在很早期就被抓出來修掉），不但不會打亂開發節奏，反而會加速專案的進行。

＝＝＝＝

系列文章：

網站程式上線前需要準備的事（二）

2012-03-18T01:24:00+08:00

第 2 件事：application deployable from day 1

在進入開發階段後，我會做的第一件事： make application deployable

也就是：專案開始第一天，就必須要有個 production 直接可運行（可以鎖密碼，當作測試 server）才行。（我在 Rails 101 這本書最後一章，加入 capistano 與裝機為必練技能，就是這個緣故。）

為什麼專案需要 deployable？

提前控制風險：開發環境與線上環境的不同

在一般的經驗中，往往在在專案進行到尾聲快上線之時，才會注意到一個可能使專案時程大爆炸的事情： 開發端與線上端的環境通通不一樣 。

在開發過程中，所有人只專注在自己的機器上能不能動，這是常態。專注在實現功能，東西有缺就先在 local 上塞假資料。在最短時間內將 feature 盡可能寫完絕對是第一要務。

但很可惜的，寫完並 不等於 放到正式環境上可以動。

網站上其實非常多功能需要實際被「真人」測試，才會知道到底有沒有問題。有一些設定，甚至開發環境與上線完完全全不一樣。（以 Rails 來說，其實就差很多。比如說程式 class 會不會被 cache，asset 有沒有 optimize，上傳路徑以及與第三方接軌的設定等等…）

如果拖到最後一個月才作 deploy 的這件事，因為「到底有多少東西不一樣」，變成了一個完全的未知數。原本夠用的一個月測試期，被這樣一壓縮可能完完全全就不夠用了。而且因為專案截止日已進，隨之而來的壓力更加大了犯錯的可能性。

一個透明的已知進度

Day1 就有一個可以直接實際測試的站台，還有一個很大的好處，能夠確保專案中所有人都知道現在進度，與規格書上的東西到底差多少。如果有重大瑕疵，或者是絕對不可行的功能，就可以早早會提出修改，下架等等。節省大家寶貴的開發精力。

如果專案截止日最後十五天，大家才知道很多東西原來根本是作不出來的，或者是跟原本想像差太多的，這時候鐵定陷入交相指責，一遍慌亂的狀況。

絕對注意：捍衛進度

不過這一招的使用，專案經理或者是 RD 主管要特別注意。因為 Day 1 就有一個直接可以看的站台，不少完全不懂「技術」的專案參與者（通常是企劃或老闆），會對網站的「裸站」狀態感到極度的恐慌，他們會挑剔 UI，會不滿 implement 細節，進而想要實際插手進度修改內容。請務必堅持住，堅持到進入最後一個階段：測試修飾期才可以讓他們修改（通常進入準完工階段，裸站狀態其實也消失了，當初挑剔的東西幾乎在這個階段不復存在，故也沒有修改的必要。）

P.S. 可以架設一個 issue tracking system，把他們提出的修改事項先通通記起來，但通通不實作。等到接近測試期，再來看看這些當初的「建議」到底還有哪些實際需要被執行。

只有「完全不合實際應用」的東西，或者是「變更會讓實作方式更合理」的東西可以在整個開發期，被丟入排程中。

否則，他們的驚慌，會害這個專案完全結不了案。

＝＝＝＝

系列文章：

網站程式上線前需要準備的事（一）

2012-03-17T23:48:00+08:00

很多人知道如何實作網站功能。但是卻不知道如何將網站成功的完工，並且如期上線。往往明明專案開始之初有不少的工期，有不錯結果的卻很少。上線前後總是一團慌亂。

其實「上線」這件事情完全是可以被掌控的。這當中有不少眉角，只是多半被疏於控制，導致風險橫生。

在回答別人幾次這樣的問題之後，我決定把我的經驗分享整理出來：

第 1 件事：界定時程

這是我認為在專案管理過程中，最重要的一件事。累積參與過幾十個專案下來的經驗之後，我發現上線前手忙腳亂的原因，幾乎都是時程的安排不當。時程混亂冒出的很多風險又沒有被妥善的管理，最後才大失火…

傳統瀑布式專案進行法：寶貴的時間被大量的浪費

一般的專案進行方式，雖然都會有確切的完工期，但專案進行的方式往往會形成相當的浪費而最後造成大量的風險。

比如說一個需要 6 個月工期的案子進度通常是這樣的：

花了 3 - 4 個月無盡的訪談需求
花了 1 個月請美術設計視覺與介面，以及反覆修改
最後剩下不到 1 個月請 RD 寫程式

=> 完全來不及寫完程式 => 半成品上線

上線後一個月：

到處都是 Bug
發包方抱怨
使用者抱怨

上線後第二個月：

終於寫完當初規劃的程式
終於修完大部分的 Bug
使用者早已認定這是個未完工的網站，不再來訪

上限後第三個月：

因為網站規劃不良，使用者對這個網站不感興趣
因為網站規劃不良，預計的成效沒有出來
還有資源 => 繼續籌畫下六個月的改版
已無資源 => 死城

「規劃」從來不是最重要的事

「規劃」其實絕對不是開發一個網站的最重頭項目。「施工」和「調整」才是。

傳統的專案進行方式往往會掉進一個陷阱：六個月看似非常長，於是就大膽的將大部分的時間都丟入「規劃」這個一階段，因為沒有時間壓力，於是會議也通常沒有結論，或者是 feature 發散。等到驚覺時間已大幅燃燒殆盡，再不進行開發絕對完蛋，才匆匆結束。

「規劃」畢竟是個空想產物，等到實際請美術設計頁面，又會發現很多畫面以及 UI 實際上不可能完成。

於是在這一個月，團隊又會大幅的來回修改刪除功能：直到一個勉強接受的範圍，等到視覺完工再轉交給程式設計師「套版」。

在上一個階段，粗估的一個月往往是不夠用的。因為還牽扯到往來的修改時間。而這時交出的產品 scope，也僅只限於「UI」部分有辦法被完成。

「UI」部分有辦法被完成 不等於 「功能」有辦法被完成。有時候畫面上一個小小的按鍵功能，背後的基礎開發工時可能要花上三個月。

最終的上線版本，因為不夠時間了，通常最後只有寫完當初規劃出的功能的 10 - 30% 。而且 Bug 還很多。（因為時間關係，只有辦法完成勉強達到 UI 操作的目的，細部細節根本來不及實作）

最後成效不彰，檢討會議上大家互相指責。但無論如何怎麼檢討來檢討去，完全沒有人會把最根本的問題朝向「規劃時間太長」，只會輕描淡寫的用「必要之惡」一筆代過。

我的方法：從後面倒回來推算時程

我的作法完全相反。如果一個工期是六個月。我會這樣分：

什麼時候要上線：上線前 1 個月前要 Feature Complete，留足夠的時間進行各樣測試和修復 bug。(剩下 5 個月可以用)
寫程式要花多久時間：寫程式要花多久時間是不一定的事，但是可以粗估不出包的時間大概是 2 - 3 個月，可以粗抓 2.5 個月。（剩下 2.5 個月）
視覺設計要花多久時間：畫面設計要花多久的時間也是不一定的事，，但是可以粗估不出包的時間大概是 1 - 2 個月，可以粗抓 1.5 個月。（剩下 1 個月）
是的。只剩下 1 個月時間可以開會、規劃、畫草圖。請不要浪費時間。

只有 1 個月，是否不夠時間詳細規劃功能？

完全不會。

我會在以後其他的專案管理文章解釋為什麼。

＝＝＝＝

系列文章：

Rail 101 裝機實務以及改版通知

2012-03-07T17:01:00+08:00

Hi, 各位讀者好。

因為 Apple 一直在改變 XCode 的編譯套件位置，所以 Rails 101 內附的裝機實務已經過期了。

我最近正在籌劃下一次的改版，已經進行的差不多了。將會直接 support 到 Rails 3.2.2。

不過因為裝機實務這個步驟比較會卡到大家，所以我先放這個章節: Rails on Mac 安裝最佳實務出來給大家使用。

若您在裝機上還碰到什麼問題，請至 Ruby Taiwan Group 上面回報。

iPhone 4S 進洗衣機洗還是有救

2012-03-06T22:53:00+08:00

一兩個禮拜之前因為太累，我回家時忘記把 iPhone 4S 從牛仔褲掏出來。洗完澡之後就恍神直接把髒衣服拿去洗衣機直接洗了。

一兩個小時，等我回神過來之後，要幫手機充電，才發現手機已經躺在洗衣機裡面被洗得亮晶晶了。這還不夠，手機還是在開機狀態進去洗的，跟一般只是掉到馬桶進水的狀況不一樣。

Anyway，朋友建議我拿去忠孝新生站 3 號出口的麥克愛愛碰運氣修看看。傳說中這是一間服務非常棒的水果商，他們也「兼修」iPhone 這樣….

賭賭運拿去麥克愛愛修幾天後，幾天店員回電說檢修後發現主機版、螢幕和無線網路模組都炸光光了。維修費用應該會是㊙（遠低於我的預算，反正在一萬以內），不過他想他還是可以幫我修看看。

今天被通知修好了，所以就過去拿了。除了香噴噴（咦？）亮晶晶以外（開玩笑，我都用熊寶貝幫他洗澡了…），手機也跟新的一樣活跳跳的回到我手上了。

感謝麥克愛愛幫我修好手機，所以特此寫這一篇文章推薦他們。如果你有蘋果電腦或者是 iPhone 手機的問題，歡迎找他們。服務真的相當專業到位。

電話與聯絡方式在麥克愛愛的臉書專頁有，出發之前請先電話預約洽詢。

從 Github 被 hack，談 Rails 的安全性（ mass-assignment ）

2012-03-05T10:51:00+08:00

關於 Github 被入侵這件事，目前在國外開發圈傳的沸沸揚揚。看來中文圈還沒有消息，我來報導一下到底發生了什麼事好了。順便宣導一下開發 Rails 程式碼需要注意的其中一個觀念..

到底發生了什麼事

Rails 的 master 被某個 hacker 塞上這一段 commit。以證明 Github 是可以被入侵的。

為什麼會發生這件事（糾紛起源）

有個俄羅斯 Hacker : homakov 到 Rails 的 Github issue 頁，report 了一個 issue。

聲稱他發現很多「中等程度以下的」Rails 開發者開發任何網站，都沒有在 model 內作上任何 attr_accessible 的防護，這樣會引起很多安全性的問題。

Rails 官方應該設計一個機制強迫大家一定得「使用」attr_accessible。

因為寫 code 要塞 attr_accessible 被多數開發者認為是根本是一個「常識」。所以這個 issue 很快就被 Rails core team 關掉了。他的意見是這不是 Rails 的問題，而是開發者的問題。（正常人都會做出這樣的反應）

這個 Hacker 覺得他好心來報告，但是卻被忽視，感到很生氣。

於是！他 Hack 了 Github 證明這件事情是真的。

他不僅利用這個漏洞在 rails/rails 中塞了 commit ，連當初被關掉的 issue ，也用同樣方法打開了。

所以這下就鬧到舉世震驚了！…XDDDDD

為什麼會發生這件事（剖析 Rails ）

從 Rails 表單機制談起

Rails 秉持著 Don’t Repeat Yourself 的精神，將 Form 表單 Helper 直接與 Model 欄位直接結合，節省不少開發者撰寫表單的時間，是一個很聰明的作法。

<%= form_for @post do |f| %>
  <%= f.text_field :title %>
  <%= f.text_area :content %>
  <%= f.sumbit "Submit" %>
<% end %>

當表單送出後，會被壓縮成一個 params[:post] 這樣的 Hash。controller 裡面透過 massive-assignment 的技巧直接 mapping 進 Model 裡。

class PostController < ApplicationController
  def create
     @post = current_user.posts.build(params[:post])
     if @post.save
       # do something
     else
       # do another thing
     end
  end
end

這是一個自 Rails 誕生以來就有的機制了，十分便手。

有些不了解的 Rails 的其他 Developer 批評這是一個不安全設計，並因此拒絕使用 Rails。欄位暴露在外被人知道，讓他們感到非常不自在。

萬一被人猜到 user 權限是用 user.is_admin 作為 boolean 值，這樣豈不是很危險嗎？在修改個人資訊頁時，假造 DOM 就不是可以把自己提升為 admin 了嗎？

Rails 內建的安全防禦措施

Rails 也不是沒有針對這件事設計出防禦措施，有兩組 model API ：attr_accessible 與 attr_protected。其實也就是白名單、黑名單設計。

把 attr_accessible 加在 model 裡，可以擋掉所有 massive assignement 傳進來的值，只開放你想讓使用填寫的欄位。

class Post < ActiveRecord::Base
  attr_accessible :title, :content
end

而 attr_protected 是完全相反地機制。

知名認證 Plugin 皆內建 attr_accessible

也因為 user.is_admin 幾乎是所有懶惰開發者會寫出來的 code。因此長久的歷史演變下來，許多知名認證 plugin，如 devise ，restful-authentication 等等…，在 User model 裡都會加上 attr_accessible（你可能沒有察覺到，因為可能是透過 include Module 塞進來的功能）。

因為是隱藏的內建防禦，很多不夠經驗的開發者，反而會被這道自動防禦整到，在設計修改使用者資訊這個功能時，常常表單明明沒問題，但就是修改不了除了密碼和 email 以外的欄位 XDDD

User model 自動防禦，那其他 model 呢？

好問題！這就是這次 Github 發生的問題。嚴格來說，根本不是 rails/rails 的錯，而是 Github 內某個被罵 mid/junior level 的 developer 的錯。他根本沒有對其他 model 作上保護，才被 hacker 有機可趁。

Hacker 也是想要證明連 Github 都會犯這種錯，才會鬧出這種事件

看到 Github 的事件，我該做什麼？

請回家讀這兩組 model API ：attr_accessible 與 attr_protected 的作用。

並檢查你的 project 內是否有類似問題：一般來說，容易被攻擊的點都跟 relation 比較有關係。也就是 xxxxx_id 的部分都要清查。

Scoped Mass Assignment

這是 Rails 3.1 加入的新 feature : scoped mass assignment， http://enlightsolutions.com/articles/whats-new-in-edge-scoped-mass-assignment-in-rails-3-1。

我也建議你閱讀。

Rails core team 目前的解法

大師 Yahuda Katz (wycats) 目前起草了一份新的 proposal，並且丟在 Hacker News 讓鄉民討論。應該可能近期就會近 Rails core 或以 plugin 的方式釋出。

我個人的感想

其實昨晚睡前看到一堆人說 Github 被 Hacked 掉，然後追了幾篇討論串之後，覺得真的是沒什麼，因為就我來說，的確應該就是這個 hacker 覺得有必要提醒大家，但這對多數的 Rails Developer 來說，根本是超小的小事，不值得這麼大驚小怪。

結果憤怒的 Hacker 攻擊了 Github，Github 真的還因為某個 developer 犯了低級錯誤中招。但我還是覺得沒什麼…

XSS V.S. Massive Assignment

後來睡醒以後才發現不對，其實這東西應該要被拿來跟 auto escape 相比：XSS 是一般設計 Web Application 最容易中招的攻擊。

XSS 的原因肇因是讓開發者開放讓使用者自行輸入內容，然後無保護的讀出來，Hacker 會利用這種漏洞，寫進有害的 JavaScript 讓使用者中招。正確的方式應該是：內容讀出來之後，都要利用 html_escape 濾掉。

問題是，html_escape 濾不勝濾，沒有開發者能夠那麼神，寫任何一段 code 都會自律的加上 h(content)。最後 Rails core 痛定思痛，在 Rails 3.0 後效法 Django 的設計，在讀出 content 時，一律先 escape。除非有必要，才另行設定不需 escape。

我想這次的 massive assignment 問題應該也要比照辦理才對…

延伸閱讀：

國外鄉民懶人包：GitHub and Rails: You have let us all down.

DHH 給出的 37Signals 的作法：https://gist.github.com/1975644

我創業了，我的公司 RocoDev

2012-03-02T01:59:00+08:00

我創業了。從 2012/03/01 開始，我跟我的好友：國內頂尖的視覺設計師 @evenwu 合組了一間新公司 RocoDev。

我們專營：

Ruby on Rails Web Application 設計
HTML5 / Responsive Design 視覺與網頁設計
網站體質優化 ( SEO / HTML5 semantic / Alexa ranking)

有興趣的朋友可以歡迎找我們洽談服務。

至於我創業的原因，寫在這裡：「我為什麼想創業」。

這也是我另外的一個小部落格，我對於人生的感觸和一些沒有那麼硬的短文會放在這裡。

Ruby Podcast / Screencast / Issue 推薦清單

2012-02-19T06:02:00+08:00

有些人問我平常日常怎麼補充知識，所以稍微整理一下我平常看的一些東西分享出來。我平常蠻常到處亂看東西，比例大概是這樣：70% 以上是 Ruby，30 % 是 JavaScript 和其他東西…

Blog.XDite.net

The Startup Owner's Manual 讀書心得（2）: New-product introduction model 致命的九宗罪

1. Assuming “I Know What the Customer Wants”

2. The “I Know What Features to Build” Flaw

3. Focus on Launch Date

4.Emphasis on Execution Instead of Hypotheses, Testing, Learning, and Iteration

5. Traditional Business Plans Presume No Trial and No Errors

6. Confusing Tradition Job Titles with What a Startup Needs to Accomplish

7. Sales and Marketing Execute to a Plan

8. Presumption of Success Leads to Premature Scaling

9. Management by Crisis Leads to a Death Spiral

後記感想

The Startup Owner's Manual 讀書心得（1）: 別再使用製造業思維搞 Startup

泡沫時代的 PChome 24hr : Webvan

製造業的模式：New-product introduction model

New-product introduction mode

一去不回頭的瀑布模式

Product Development 階段

Alpha/Beta Test 階段

Launch / 1st Ship 階段

花光錢死亡

The 9 Deadly Sins of New Product Introduction Model

如何準備美國自助旅行（行程準備篇）

行程準備

護照、美國簽證

機票

去小城市就拆開訂

美國國內線機票價格不含行李托運費

旅館

大會期間住宿

舊金山旅館

機場旅館 (過夜班機建議訂)

機場接駁車

手機門號

有 3G 以上需求請選 AT＆T

電話需求

保險

旅遊手冊

美國海關（拷問程度不下 AIT）

Railsconf 2012 - 國際性 Conference 是這樣辦的 （下）

11. 售票 / 大會網站 / Schedule / 贈品

售票

大會網站

議程表

贈品

12. 大會贊助商贈品與交流

13. 大會工作人員

14. Call for Sponser

15. 其他感想

Railsconf 2012 - 國際性 conference 是這樣辦的 （中）

7. Keynote

Rails core: DHH

Rails core: Aaron Patterson

Entrepreneurship

Ruby Hero Award

Panel Discussion

Ruby Rogues Live

8. After Party

9. 現場白板

10. 講者 （講題） / 錄影 / Slides / 筆記

講者（講題）

錄影

投影片網址

社群共筆筆記

Railsconf 2012 - 國際性 conference 是這樣辦的 （上）

1. 大會地點

2. 大會場地

演講廳安排

贊助廠商與食物

座位、電源和網路

座位 / 電源

網路

3. 食物

4. 報到 / 提早報到

4. 不想聽 conf 的人的安排

5. 都聽不懂議程的人或新手的安排

6. 贊助廠商的議程的安排

Startup : 如何挑選適合的 Hosting Plan?

Hosting Plan

Bootstrap 期：利用 Tumblr + Facebook

Railsconf 2012 - 國際性 Conference 是這樣辦的（下）

Railsconf 2012 - 國際性 conference 是這樣辦的（中）

10. 講者（講題） / 錄影 / Slides / 筆記

Railsconf 2012 - 國際性 conference 是這樣辦的（上）

網站程式上線前需要準備的事（五）

網站程式上線前需要準備的事（四）

網站程式上線前需要準備的事（三）

網站程式上線前需要準備的事（二）

網站程式上線前需要準備的事（一）