這是最壞的年代，也是最好的年代
我的長輩常跟我講一件事：這是最好的年代，也是最壞的年代。
過去二十年間，世界起了巨大的變化：我國小的時候，台灣才剛引進家用電腦，電話還是轉盤。國中的時候，學校有了網際網路，路上的有錢人開始拿起了大哥大。高中的時候，我有了自己的手機，雖然只能打給自己的爸媽。大學的時候 Netbook 正「準備」要流行。畢業後一兩年後 iPhone 與 iPad 席捲了世界，改變了全人類的生活。
我小學的志願是當個歷史學家（因為我愛看書）。但是現在的職業卻是軟體開發者，精熟的技術 Ruby on Rails 是一個 2004 才誕生的 Project。長輩們從來沒有預見過我會是一個程式開發者，他們的理想是讓我繼承父志當一個醫藥從業人員。
我的小學志願甚至不是「軟體開發者」（當時身處的世界沒有這個名詞）。當長大後跟家族長輩說我「好像開始覺得」對寫程式有興趣時，他們每一個都說靠這吃飯會餓死。
他們沒有惡意。
沒有太多人預見我們正在進入一個近兩百年史上最大的革命演進：「五年」、「三年」甚至「一年」之後，整個世界就變得完全不一樣。沒人知道：明，天，會，發，生，什，麼。
過去父輩能夠給我們的職場建議，學校的教科書，社會的觀念，在應付這麼大的浪潮時，通通失效。
現代科技的演革，為生活帶來前所未有的便利。但糟糕的是，我們不知道如何應對於這樣的衝擊。大學是一個四年的制度，能想像嗎？當你按照學長前輩的建議選填志願，修習課程，甚至準備理想的出口：上市公司科技替代役。到大二大三大四，卻發現這條路似乎看起來卻不是那麼正確了。你卻不知如何是好。
這是一個最壞的年代。你知道時代在變，你知道要跳上浪潮才能得救。但你卻無能為力。
這是一個最好的時代。因為既有的規則在崩解，新的機會在產生。只要有能力，站上世界舞台並不是一個遙不可及的夢想。
關鍵是：How？
產業與教學傳承的斷裂
從近代的演變趨勢，不難察覺能夠誕生高附加價值的產業逐漸趨向於軟體與服務。但身為科技矽島的台灣卻在這個競技舞台上缺席。我們的軟體產業在過去十數年斷裂，我們的教育甚至在傳授過時的觀念與流程。身處於一個「不知有漢，無論魏晉」的桃花源。
這一兩年，我在部落格寫下過這幾篇文章：
它們都造成非常大的迴響。
因為我們的年輕國民知道時代在變，我們知道我們在桃花源裡面。但是我們卻無力逃脫。我們的教育體系以及既有觀念無法給我們的滿意解答。我們需要出路。
Vitor 的這本最新作品：「台灣軟體產業的失落十年」，書名雖為失落十年。意旨卻非在批判這個產業，而是在指出一條逃出桃花源的生路。這是一本我看過市面上最好的關於現代軟體開發流程與趨勢的中文（既是技術/又非技術）書籍。裡面的內容廣泛的談論摩登軟體開發、技術、人才、市場等議題。
我相信讀者閱讀完後會有相當大的收穫，在此推薦。
販售平台：Leanpub 連結 / Readmoo 連結
售價：9.99 USD / 299 TWD
昨天跑去 StartupWeekend #9 當 Judge。席間結識了一位 Mentor: Roger。在評審前說明會閒聊時，Roger 介紹了我們一款遊戲 Hipster CEO，說是一款創業模擬遊戲。
不過這款遊戲因為需求是 iOS 7+ 以上才能執行，身為 iOS 6 死硬派的我，現場糾結了很久到底要不要因為一款遊戲升級到巨醜的 iOS7。後來回家還是抵抗不了誘惑，升級並購買安裝了這個遊戲。
根據另外一篇評測文 Too lazy to start a real startup? Play “Hipster CEO” instead 的資訊。作者說他開發這個 app 其實不是想模擬 Startup 生態。而是想讓人們知道「由一個 idea 發想，到上線，到讓人願意付費是一間非常艱鉅的事」...
（我在網路上找到這篇評測時，遊戲裡面的公司已經被我玩倒了三次）。不過四個小時後，我賣了四間公司賺了七億多 ...XDD從攻克這款遊戲裡面，還學到不少有趣的事。讓我覺得直逼當年的創業桌遊 Burn Rate。所以上來寫這篇攻略文。
遊戲的一開始的設定是：你在自己的宿舍裡面創業，主角可以
- 自由選擇題材：如 Microblogging Service, Music Streaming Service, SocialNetwork, Todlist, Message App ..等等
- 起始資金約 15K
- 具備中上以上的水準，開發 app，Marketing，Sales 各樣都「略懂」
- 願意的話可以 boostrap 自己什麼都動手作。
我玩的題材是 "MicroBlogging"，公司叫 Logdown，CEO 是 Xdite Cheng...XD
剛開始的一個小時，我按著遊戲裡面的 Guide。但是玩倒了自己公司三次，第四次才開始賺錢。
第一次創業
原因是這款遊戲一開始也蠻艱鉅的，雖然一開始有起始資金 15K，如果只有自己一個人的話，現金流約可以撐公司 500 多天。但獨自一人光把 App 做到可以上線（要有10個feature才能上線），就要花上 150 天上下。發現了這一點之後，我決定雇用一個員工幫我開發，縮短時程。但雇用員工真的很貴，雇用一個非常非常初級的員工，就會讓我的 Cashflow 馬上降低到只有 100 多 天可以活。
App 要上線，要搞一些宣傳。所以我決定雇一個行銷專員幫我行銷。但是發現條件不允許。因為宿舍房間只能窩兩個人，雇用了一個員工加上我自己就滿了，所以無法雇用第二個員工。最後我決定開除程式設計師（反正都寫到可以上線了），雇用行銷專員。但後來發現這是一個大錯誤，因為開除程式設計師要給遣散費，所以公司瞬間就少了很多錢。而且我本來以為雇用行銷專員，每天灑個 NT$2 的網頁廣告，和作一點 Social Network 宣傳，東西就會有人用。但是一點作用都沒有。公司三十天後就倒了。
第二次創業
所以我只好捲土重來。我決定還是乖乖自己花 150 天寫 app。上線後再請一個初級行銷專員，幫我行銷。但還是發現不行，根本沒有人來用。雖然這次比較省錢，公司可以多撐 100 天。但是沒有 income 公司最後還是 GG。（中間雖然有 Seed Fund，但是根本沒啥用，都是 2K 然後要 56% 股份，2K 根本燒不了幾天啊，開我玩笑嗎大哥）
第三次創業
我想上次會倒應該是我請的人不夠厲害的關係，於是我這次還是自己寫 app，然後請一個超級厲害的行銷專員（很貴），幫我投放廣告：「一樣放 NT$2 的網頁廣告，和作一點 Social Network 宣傳」。然後....這次死更快，因為還是一樣沒屁用，行銷專員的薪水太貴，十幾天我就倒了...
第四次創業
==== 劇透密技分隔線 ==== （如果你想要自己繼續玩的話以下是攻略）
Read on →昨天去參加 HappyDeisgner Mini #5 聽到 Caesar Chi 在講他跑校園傳道 (提倡 OpenSource)的故事，Caesar Chi 說他會這麼做是受到 Jserv 南下傳道的啟發。
為什麼要深入校園傳道。我想其中最大的問題是:大家都已經深刻發現了「校園的資訊教育」與「現行職場」、甚至與「國際技術圈」上的巨大差距。已經大到一個相當難以扭轉的狀態。其實，任何技術，在寫下來製成紙本教材並且搬到課堂的那一刻，就過時了。只是現在速度更快到，當你今年寫下來準備開課，明年這套技藝就已經有可能過時了。真的很難期待，從傳統學校傳授知識的過程中去介入什麼。
所以唯有提倡學生儘量跳脫只能在學校學習的思考框架。在線上學習（ Online School )。多多參與接觸開源社群。
But, How?
在線上學習（ Online School )。多多參與接觸開源社群。 對我們已經在工作的職業程式設計師，這個概念再簡單不過。但是我發現這對初學者來說，是一個很空泛的概念。他們其實更需需要的是一份 Guideline，有一個具體的方向去「自學」去把目標具體化。
（這份 Guideline 也是我回想若當初我剛出社會時，希望有人能給我的一份清單）
=== 分隔線 ===
Source Control
- 理解什麼是「版本控制」，為什麼我們要使用「版本控制」
- 學習 Git : http://try.github.io
- git commit
- git push
- git pull
- git branch
- git checkout
- git merge
- 註冊 Github 帳號
- 把自己的作業推上 Github
- Fork 同學的作業，幫他修錯字，然後拉 pull-request
- 卡關就上 Google 找 Stackoverflow 的答案
Do a "real" project
讀書跟做事不一樣。你不應該去「讀完」Ruby 再去用「Ruby on Rails」寫一個網站。
- 找一本可以教你作一個 project 的書(不知道去哪找可以上網問），從頭到尾貼 code 跟著作一遍搞懂架構以及學習 debug。
- 扔開書後的第一次：作一個比書裡面的 demo 還小的 project，如果裡面 demo 一個論壇，那麼就做一個留言板。
- 扔開書後的第二次：重新作一個簡單的論壇，不看書。
- 扔開書後的第三次：重新作一個有你想要的功能的論壇，可以貼圖，可以分享到 FB。
- 去找可以幫助你重新把程式技巧提煉的更好的書，重新補基本功（這時候你可以好好的看 Ruby 書了）。
- 去 Meetup 找職業的前輩，問他們怎麼樣可以更好的翻修你的 project
學習協作
獨自開發一個小東西，和實際上與多人一起開發一個中型結構的專案是完全不一樣的世界。而學校幾乎不可能有這樣的環境。
- 註冊 Trello 帳號（這是一個簡單協作、看板式的專案系統）
- 試著與同學或同事「合作」。但用 Trello 管理所有待辦事項。
- 重點是
- 把一件龐大的目標拆分成數十個可以執行的小事項
- 每一樣事項有各自的狀況。現在做到哪裡，還缺什麼，需要交付的材料，多久才會做完，遇到什麼困難
- 不要用 Off-book （phone/email) 的管道溝通
- 有問題就提出，不要藏在台面下。
- 每一件事都應該要有一個可以指派的人
分享(程式碼以及文章）
不斷的貼 code 以及練習在網路上發表文章，可以強化你的表達能力與邏輯組織能力。知名軟體公司 37Signals 甚至表示，他們不太注重程式底子，只雇用「寫作能力」良好的人。因為寫作能力強大代表著：組織能力與邏輯能力強。
這不是什麼可以速成可以偽裝的東西。同時不斷發表東西，連帶的效應就是可以幫你建立 reputation，和讓別人發現你的存在
- 把學到的東西發表到 Blog 上面。（不要怕害羞）
- 即便是小小的程式片斷也貼到 Blog 上。
- 不斷的貼 code 以及練習在網路上發表文章，
- 把自己作品放到 Github 上
Learn English
這裡說的學習英文不是說去背單字，上補習班，考 TOEIC。而是：
- 練習幫自己在 Github 的 Project 上寫 README
- 有辦法在在 Github 上用英文 open issue / reply issue
- 在 Stackoverflow 上用英文問問題
- 訂閱社群電子報。（尤其讀社群電子報，如 Ruby Weekly，是個學習 Ruby 非常快的方式）
- 聆聽社群 Podcast。（社群都會有一些 Podcast，短的 5 分鐘如 Ruby5，長的 30-45min，可以很快的讓你抓到這個禮拜世界上最新的重點是什麼）
- 購買線上教材。（現在網上學習的教材都比大學教科書便宜非常多，有些甚至不要錢。不過他們都是「英文」影片以及作業）
=== 分隔線 ===
小結：
這是由我過去的實戰經驗總結出來的 CheatSheet。當然，這些事我並沒有說都是非常「輕鬆」做到的事。但我可以向你保證這些方向，如果練成都是「非常值錢非常具有競爭力」的技能。認真執行三個月，你「馬上」可以見到與台灣完全不一樣的那個世界。
最近幾年，興起 Lean Startup 的風潮。主要的訴求是創業者應該先把重點放在打造一個 Minimum Viable Product (MVP)，觀察市場的需求，再行調整變化商業主軸成長。
說起來簡單，但沒人敢篤定的說，這個 Minimum 的 M 到底要做到什麼程度才足夠。討論一個點子，快速製造出一個原型，然後讓使用者快速反餽調整？這樣做的人很多，但卻不是人人 work。
更普遍的是你見到一個「草率」的產品上線，然後從此就快速沉寂消聲匿跡。
M 不代表草率
很多創業者在製作產品的過程中，常常不自覺得把「MVP」這三個字拆開來看，亦即只完成了「M」，以為實作了「Mininum」的產品規格，就可推出觀看市場反應。事實上，市場上有人會要的東西是 MV （Minimum Viable）。如果你的產品並沒有解決了任何有價值有意義的問題，只是一堆精美的介面功能，那麼是沒有人會買單的。只是浪費了時間浪費了金錢，生出一堆沒有用的程式碼。
相反地，若提供的解決辦法對某些人很重要，那麼就算產品介面再怎麼 crappy，他們還是有興趣停下來試用，甚至付錢給你希望開發者將把它做得更加完善。
M 的 scope
回到正題。我們終歸要討論 M 的 scope 到底在哪裡。
我的建議是：
不會寫程式的作法
如果你不會寫程式的話。先去找一個「會用」的工具湊出一個勉強能夠動的流程，解決問題，然後開始找人試用。
如果你找不到現成的工具可以兜，那麼還有一個方式。你可以拿非常仿真的 Mockup 工具，如 Axure XP、Balsamiq，把「可以解決問題」的流程和出現的畫面畫出來。
不要覺得這樣的步驟很麻煩，因為到這裡為止，還是只有梳理工作流程而已。
你可以從這樣的流程，粗略的知道後面將要面臨多麻煩的事。以想要開一個商店來說，你就會知道商店：
- 需要一個上架介面
- 需要傳圖介面
- 需要結帳介面
- 提供哪些結帳選項
- 提供哪些寄送方式，如何選擇
- 要用哪種條列方式管理使用者訂單
會覺得製作這些畫面很花時間對吧？這些都只是畫面而已。要寫出後面的程式可能是畫一張畫面「五倍」甚至是「十倍」的時間。
透過把畫面與流程畫出來的方式，可以讓你(很清楚的）知道要製作這個東西要花多久的「成本」（不管是時間上還是金錢上）。
不要因為覺得很麻煩，就使用「功能列表條列」、或者「單張畫面，列出滿滿按鈕與分頁去表示所需功能」的方式去估算工作時間。
因為事實上，在列表上，一個功能你都只會以為需要一小時或一天就能完成。而真實會發生的情形是，一條功能至少要開發 7 天。
當你一旦理解到要執行這個計畫所需成本可能是多麼巨大的時候，自然就會毫不猶豫的把不需要的功能砍掉，只專注在「必要的解決手段」。就這個例子，甚至最可能的情形，是上去 Shopify 上面開一個網路商店，或者是註冊一個 Wufoo (線上表單服務） payment integration Plan。
會寫程式的作法
會寫程式的作法反而相反。我相信各位開發者都很威，開發軟體的成本對你們來說都超低。但，請千萬千萬忍住，只做一個功能就好。思考哪個功能是「解決問題手段裡面絕對不可以沒有的」，只做這一個就好了。以 Logdown 這種部落格平台來說，標準就是只做一個編輯器，以及簡單的文章系統就好了。
（真的不要擔心作太少，一上線你就會知道就算只有「一個」也是會操掛你。相信我，實際試一次就知道了）
因為技術創業者都是「很會寫程式」才會出來創業的人。所以往往的毛病就是不打 idea 草稿，邊寫邊想。又以 Ruby on Rails 開發者（哈，在說我自己）最容易有這壞毛病，因為開發程式太快。所以 generate model, generate controller, 套個版，就覺得這東西可以上線，上線就等於可以開始收錢發財了。
然後，就沒有然後了。
作產品跟上班、接案做的東西驗收標準完全是不一樣的。上班、接案，你只要按照 issue tracking 上的「指示」完成工作就可以了。但是「產品」的「完成」標準，是「順利」的「幫 End User 解決他的問題」。而要做到這件事，產品需要花上大量的時間打磨：介面要做到讓用戶可以理解不會迷路。程式不會出現詭異的錯誤。按照 End User 的需求調整加強，甚至打掉重練。
一開始就作太多功能的問題是：開發者以為這些功能都已經「完成」了。但事實上，他們每一個對使用者來說幾乎都是「未完成」的。也許使用者可以從這麼多的功能列表「猜」出開發者想要提供什麼服務，但是實際上他們不會繼續用下去。因為這個網站爛透了，每一個功能都是「未完成」。沒有解決到任何一丁點問題的網站，沒有人有興趣繼續用下去。
那麼你說，沒關係，我可以之後照使用者的反饋調整網站。但是問題又來了，做了那麼多功能「都有問題」，使用者的回報意見，自然涵蓋了所有板塊。那麼你該如何判斷出什麼問題沒做好才是最嚴重的呢？優先權該放在哪個模組呢？有些厲害的模組甚至是當初花了很多心血做的。結果使用者劣評如潮，你思考了下徘徊在投入心血改進和不如砍掉兩個選項。但狠的下心嗎？
然後，就沒有然後了。被第一次進來的 Customer Feedback 打爆，就沒有然後了。
所以，只做一個能夠解決問題的功能。只做這樣就好了。
Recap
- Minimal "Viable" Product
- 不會寫程式：Write down User Story
- 不會寫程式：用手邊可以兜出的方案實作
- 會寫程式：只寫一個「可以解決問題」的功能就上線。
Lean SaaS
這是我的新書 Lean SaaS 的第一章。若你對接下來的內容有興趣的話，我將會在這本書繼續連載後面的內容（保證每週連載，約十期）。
連載期間價格 30 USD。連載結束後 45 USD。
本書最後附贈 SaaS 上線 checklist，我會在書中的逐章解釋 CheckList 的每一條意義。
歡迎各位讀者來信交流，我的 email 是 xdite@rocodev.com
Lean SaaS : Build SaaS From Small Ideas
這是我最新的一本書。書的內容是綜合我過去幾年開發以及營運中型網站, 以及在過去六個月內,實際運營一個 SaaS 網站所得到的寶貴經驗。
( 可以省下技術創業者非常多的冤枉路）
本書將會以連載的方式進行。以每週一篇的方式進行內容發行。
連載期間價格為 $30 USD。連載結束後的價格會是 $45 USD。
目前的（暫定）內容有：
- MVP 的 M 最低尺度
- 寄信，大量的寄信給你的用戶
- 作產品應不應該寫測試
- 如何決定要不要實現一個功能
- 該聽用戶的還是聽自己的聲音
- 如何拓展用戶
- 何時找外包 （外部資源篇）
- 產品定價策略
- B2C 與 B2B
- 產品的包裝
- 行銷包裝自己的團隊
- SaaS 產品 checklist
- SaaS Podcast 及資源
其他
我在這期 TeaHour 與 @knwang 與 @yedingding 做了一期節目：SaaS 血淚史
http://teahour.fm/2013/11/18/lessons-learned-from-running-saas-products.html
如果你聽完對於 SaaS 的拓展擁有強烈的興趣。我將會在這本書內逐一深入各式的主題。
最近閱讀很多 SaaS ( Software as a Service ) 相關的 newsletter, blog, 書，閱讀的蠻上癮的。有一個影片看完以後我蠻想分享其中重點，這個故事也許可以給台灣的創業家一點激勵。
這個主題就叫「從世界的邊緣創業」。這是我當初在 Bussiness on Software Conference 翻歷史影片，看到的一隻主題蠻吸引人的 Talk :Going global from the edge of the world 。
講者是來自「南非」開普敦的創業家 Adii Pienaar。他的公司就是赫赫有名的 Wordpress Theme 公司 : WooThemes
「從世界的邊緣創業」這個主題真的非常吸引人，一般人對於要作 Global 生意的印象都是網站創辦人非得是美國人，否則這生意怎麼做的起來。這也是吸引大家來參加這個 talk 的原因。
WooThemes 的背景
- 2008 年創業。花了 13 個月，賺到第一個一百萬美元
- 總部一直在南非開普敦。其他人在英國和挪威。
- 員工 25 人
- 用戶 30 萬人
- 平常都是 remote
- 沒有收過任何 Funding, 100% Boostrapper
- 開 WooThemes 之前，是一間三人的 Design 工作室
第一件事：公司在哪個國家並沒有太大關係
要比慘的話。Adii Pienaar 說南非開普敦作為一個科技創業的地方，其實不是什麼太優的位置。
開普敦一如非技術城市的一樣。沒有這些東西:
- Networking 關係圈
- Mentors 導師們
- Advisros 顧問們
- Investors 投資者
當地沒有 Startup Culture，公司更很難請開發者，因為他們都寧願去當地的銀行上班。而且物資還缺乏....XDDD ( 什麼東西寄到南非都要拖三四個月）。
這是他們公司為什麼以雇用 Remote worker 為策略的關係。
從哪裡出發並不重要。Adii 賭他們公司的客戶應該 99% 以上都不知道他們公司其實在南非。客戶根本不會關心這間公司真實的地址在哪裡。
第二件事：不要因為潮所以去創業，不要因為潮所以去募資。決定必須基於生意決策
Adii 在演講裡面談到他在該 talk 前幾個禮拜寫的一篇文章：Startups Shouldn't Follow Trends
最重要的原則是：Stop doing things just because they're trendy and mainstream media seems to reward it with publicity 不要因為趨勢以及主流媒體激賞這些行為，你就去追逐。
- 可以 bootstrap 就不用去募資
- 不要因為 Eric Ries 講 Lean Startup，你就跑去用。如果你的生意這樣幹才適合才這麼用。
- 大方的用 .NET 技術作網站，只要你認為這是對你生意上最合適的決定。
第三件事：從技術社群和客戶裡面挑員工
現場有人問 Woothemes 的員工幾乎都是 Remote 的。雇用 Remote worker 似乎是一件嚇人的事。他們去哪裡找到值得信任的人可以雇用。
Adii 的回答是從社群和客戶裡面挑選。因為他們公司是在賣 Themes 的。所以客戶蠻多都是開發者，所以最後就問其中幾個能不能來上班。也因為打過交道彼此認同也熟悉產品了，這件事來得容易一點。
第四件事：比任何人努力工作
Adii 深信的兩件事是
- "The more In practice, the luckier I’ll get."。（雖然它們可能不會同時發生）
- There’s no way to exceed unless you actually work harder than anybody else.
他很羨慕 Ryan Carson 推行 4days a weeek 運動。不過那福利是給員工的，Bussiness Owner 可能永遠不會有這種機會 XD
第五件事：用國際級的水準建立國際產品
從開普敦打造國際級產品，不是不可能的。只要你拿國際級的實力，上台競技。網際網路允許你這麼做，而且沒有理由你不去奪取這個機會。
第六件事：作 B2B 生意
Adii 會創業的原因是，是他在開 Woothemes 時前是作 Design Consultancy 的。他幫客戶作一個案子是收大概 $3000 美金（from design to deployment)。他意識到可以把 Theme 做成產品。當然，做成一個變成只收 70 塊。但是你可以省下客戶很多時間和金錢，讓客戶原先的本業做得更好。而且你可以創造一個「Bussiness Model」，而不是只「僅」得到一個「Bussiness Customer」。
<題外話>
我在另外一篇 SaaS 文章，也看到勸 Founder 作 B2B 的產品。因為 B2B 的產品顧客，更願意付錢。他們願意付錢讓 Things Get Done。付這樣的小錢，目的是為了賺更多的錢。 B2B 收費模式會比較容易擴展且穩定。
第七件事：到世界各地去旅遊參加研討會
這是他的 Talk 裡面分享的最後一個 Lesson。到世界去旅遊，去見不同的人。到世界去旅遊見不同的人，可以為你充電。帶給你不同的靈感，得到不同的機會。甚至可以有機會在不同的城市認識到厲害的導師。
特別是如果你不住在科技重鎮，或者是一個熱鬧的城市。旅遊是你要找到 mind-liked 的人的唯一的機會。
而要找到 mind-liked 的人最容易的方法就是參加研討會。
小結
這個 Talk 是一個 60 分鐘的 Talk。Adii 的演講當然不只以上內容，但最重要的是，他想展示的是，不住在矽谷，也是可以打造一個國際企業的。而這是他個人的親身經驗。
我也是到昨天看完這個 Talk，才發現 WooThemes 竟然是從南非的公司。而且那些 37signals 分享的部份經驗，也不是傳說。Woothemes 的經歷也蠻多相似的地方。
Adii 還有一個部落格 http://adii.me/ 。如果你是創業者的話，我強烈建議你訂閱 Adii 的部落格與電子報。他在裡面分享了很多關於 Startup 與 SaaS 的 esay。
過幾期，我們將在 Tearhour 作一期關於 SaaS 的節目，屆時也歡迎各位指教。
https://twitter.com/bottico/status/400397602522279936
https://twitter.com/dhh/status/400397737763434496
https://twitter.com/dhh/status/400397858173485057
https://twitter.com/dhh/status/400397926158983168
相當有意思。
前陣子我在 RubyConfChina 2013 的 Talk：Maintainable Rails View 。
現在已經重新整理成一本書 Maintainable Rails View https://leanpub.com/rails-view-book
當初會整理這個 Talk 和書的原因是是因為長久以來：相對於 View，在一個 Project 裡面，設計出乾淨的 Model 與 Controller，是相對簡單的。但事情一跑到 View，就會變得相當複雜。很難有一個基礎簡單的思路去整理這些糾結的線條。
所以我最後決定釋出一份這樣的整理指南。
這其實也是我們 Rocodev 目前在用的 Rails View 整理技巧。
這本書包含以下幾個主題：
- Helper 使用時機
- Helper Best Pratices
- Partial 使用時機
- Partial Best Pratices
- Helper 與 Partial 之外的整理武器
- Object-Oriented View
共有十八個技巧。定價是 20 USD。
新書上架，提供折價卷：rubyconfchina2013 (折價 5USD 至 2013/12/01)
其他
曾經購買 Essential Rails Pattern 的舊讀者，我後來考慮這本書的架構太龐大。之後應該會分拆成幾本書。原書則不再更新。我會寄一個 Maintainable Rails View 完全免費的 coupon 給你們。(屆時請查看你們的電子信箱）
有讀者問到與之前的文章系列的不同。這本書部分內容是重新寫過並且編排的。有關於 Object Oriented View 的部份本月底也會翻新（新增更多 code example）。
Summary
總結以上 18 個設計手法，看似複雜，其實原則不外乎：
- Always assume things need to be decorated (永遠假設東西必須要被裝飾)
- Extract logic into methods / classes ( 將邏輯封裝成 method 或者 class )
- Avoid perform query in view/helper ( 盡量避免在 view/helper 裡面進行資料查詢 )
- When things get complicated, build a new control center （當事情變得複雜，不要拘泥於舊的手段，找一個新的中心重新整理控制）
掌握這些原則，就可以儘量把 View 整理的乾乾淨淨。
Read on →這一篇的重點也是 Object-Oriented View。因為篇幅太長所以再拆一篇。
16. Form Builder
有時候我們為了排版 Form，不得不在 Form 裡面也穿插一些 HTML 作 styling。
<%= form_for @user do |form| %>
<div class="field">
<%= form.label :name %>
<%= form.text_field :name %>
</div>
<div class="field">
<%= form.label :email %>
<%= form.text_field :email %>
</div>
<% end %>
但要寫十幾遍 <div class="field"> 是一件很煩人的事。我們最希望的是，其實 View 裡面只要這樣寫就 OK 了：
<%= form_for @user, :builder => HandcraftBuilder do |form| %>
<%= form.custom_text_field :name %>
<%= form.custom_text_field :email %>
<% end %>
這樣的煩惱可以透過客製 Form Builder 解決：
Read on →