Update(2009/2/21): Textmate 只有內建 Ctrl+Shift+A 的 SVN 功能，要支援 Git 請裝 Git Textmate Bundle，按 Ctrl+Shift+G 就可以有快捷功能。

Update(2009/2/22): 另外推薦一個不是 TextMate 的 Plugin，但是搭配起來非常好用的 Visor，只要使用快捷鍵就可以在螢幕上方下拉出 Terminal 畫面。

第一名是 AckMate， ack 是一套專門用來搜尋大型程式碼的工具，效能真是超級好。裝了這個套件之後，內建的 Find in Project 就別再用了吧。

第二名是 TextMate Plug-in: ProjectPlus，可以在顯示 SCM 的檔案狀態（例如有本地異動或有新增檔案等等），支援 SVN, Git, Mercurial, Svk 跟 Bazaar。

第三名是 CJK-Input.tmplugin，讓你可以正常輸入中文。如果有需要正常顯示，就必須換字型為 TextMateJ2 (see 解決 Textmate 中文問題)。

跟 Ruby on Rails 相關的有 Ruby on Rails TextMate bundle、Ruby TextMate bundle 和 Rails footnotes（會在例外錯誤畫面放有 Textmate 的連結，點下去就開出來該檔案，十分方便）。

Theme 方面，我自己用的是 Rails Envy Theme。

另外就是官方 wiki 上的 Plugins 可以試試看。

• Growl 好玩的自動提示，可以吃其他應用軟體的訊息。
• Parallels Desktop *: 可跑 Windows 的厲害軟體
  • Office 2007 : Mac 版的 Microsoft Office 用不習慣
• NetNewsWire *: RSS Reader, 用這個就不想用 Web 版的 Reader 了。
• OmniWeb * : Webkit based Browser，喜歡他的 Tab 在左邊 改用 Safari 4 了
• iWork * : 主要要用 Keynote 做投影片，08新版的 Number 也還不錯用適合簡單的試算表。
• Koolclip: 紀錄下你每次的複製文字 或 Jumpcut 更輕量
• Onyx: System/Disk 整理工具
• Colloquy: IRC client，當 server 上的 irssi 不能用的時候的替代軟體
• Panic Transmit*: Mac 上超棒的FTP軟體
  
• Panic CODA*: 可以遠端操作的多功能網頁編輯器
• PEMDAS: 超棒的 dashboard 的計算機，本來內建的難用死了。
• Screenshop Plus : 螢幕抓圖的 dashboard 工具，簡單又好用
• Nally: 終於可以在 Mac 上好好打 BBS 了… m_m
• Navicat* : 專業的 MySQL 軟體，如果你有舊版本MySQL的編碼問題無法順利dump出來，可以試試。

另外 MacOS 10.5 Leopard 也在用了，雖然大體上跟 Tiger 差別不大。不過我覺得最讚的是搭配 Spaces 虛擬桌面功能，可以把整個 Windows XP 開全螢幕到一個 Space，非常方便切換。而 Finder 超強預覽功能跟 Dock 支援文件夾也不錯用。Time Machine 也推薦使用，我本來都一直懶得備份，現在只要把外接硬碟接上一切就自動了。

工欲善其事，必先利其器，花了點時間研究 TextMate Editor 有那些好用的快捷鍵跟功能:

• 按 ESC 會有 autocomplete 的功能，他會搜尋該文件已經有的詞彙。
• F1 收合程式區塊
• Command+ option + [ 整塊自動縮排
• Command + / 整塊加註解
• Command + ` 切換不同Textmate視窗
• snippets 功能，只要輸入特定關鍵字之後按 tab 就會出現整塊程式碼

走訪檔案

• Command + T : 跳到特定檔案
• Command + option + 右: 切換Tab
• Command+ shift + T 跳到特定的method
• Command + W 關閉 tab

走訪文件

• Command + 右 到行尾
• Command + 上 到頁頭
• option + 上 跳段落
• option + 下 跳頁
• Command + F2 加註記點
• F2 跳到註記點
• Command + option + 1 或 2 或 3，會收合縮排層次

在 terminal 中也有支援 command-line 指令:

• mate -h
• mate . 打開整個目錄
• mate app config lib test 打開特定目錄

另外讓我嚇到的是 subversion 的強力支援，只要按 ctrl+shift+A 就會出現快捷選單。本來以為只有簡單的功能，但其實還蠻強大的，commit/update都不成問題，而且可以很方便查到該檔案的log，看來可以減少使用 svnX 了…:p

• OpenVanilla 必備的中文輸入法
• Firefox  Web Developer 必用的瀏覽器
• Textmate * 鐵道員都會有的一套編輯器
• SubEthaEdit * 協同編輯器
• WriteRoom * 讓你專心思考文字的編輯器
• Subversion&SVK: 程式設計師一定用的工具
• svnX : Subversion 的 GUI，不過老實說還是 windows 上的 TortoiseSVN 好用穩定
• Locomotive : Rails 火車頭
• MySQL
• cocoaMySQL Sequel Pro: MySQL的GUI
• iTerm: 把內建的 terminal 換掉吧
• Cyberduck : FTP/SFTP client
• MacFusion/MacFUSE: 可將FTP/SFTP等網路資源掛載成磁碟
• Adium: 整合msn/gtalk等的IM
• Skype: 喂喂
• MPlayer 放影片
• VLC 放影片
• smcFanControl 控制風扇
• chicken of the VNC : 就 VNC 的 client，名字怪怪的
• yep *瀏覽一堆PDF的好物
• MacPorts: command line 愛好者必備，和 FreeBSD 的 Ports 系統類似。MacPorts 還需要裝 Apple 的 Xcode。
• iStat menus: 換掉內建的日期顯示
• quicksilver: 鍵盤快速啟動應用程式的好物

感謝 hlb,gugod 長輩的推薦跟燈哥的這篇軟體清單，讓我沒幾天就裝了這麼多套….XD

Update(2007/5/12): 裝 Mongrel 也沒問題喔，比Webrick好用多了。記得選 ruby 版而不是 win32版。

主要是參考這篇 A Mac-esque Rails Development Environment on Windows，在 Windows上打造類似 Mac上的 Rails 開發環境。

1.裝 E-TextEditor

2.裝 cygwin，記得 Package 要有 Ruby、gcc跟make。之後忘了裝什麼沒關係，再跑一遍setup.exe就可以了。

3.裝 Console，一套有 tabs 可以切換不同視窗的 command prompt，除了可以跑 windows的cmd，當然也可以跑 cygwin的bash shell，還可以設定背景半透明喔。不知道為什麼版本很多，我是裝 Console-2.00b123-Beta 最沒問題。

裝好後在 Settings 新增一個 tab shell 執行 C:\cygwin\cygwin.bat 即可。

4. 裝 Ruby Gems，下載 http://rubyforge.org/frs/?group_id=126&release_id=9501，解壓縮後執行 ruby setup.rb。 (注意這是給 cygwin 的，會裝在 /usr/下，跟你裝windows版Ruby在 C:/Ruby/是兩回事)

5.裝 Rails，gem install rails –include-dependencies

5.裝資料庫，complie 噩夢的開始…:p 我參考了 RailsonWindowsCygwin  跟 RailsOnWindowsCygwinWithSQLite3，把 source code 下載到 cygwin 上，然後 configure 跟 make，這可讓我小小的NB跑了好幾個鐘頭。

Sqlite3 比較沒問題(照著做即可)。MySQL的話非常神奇，雖然你真正是要用 MySQL windows 版(常駐成服務)，但是為了在 Cygwin 上可以 work，你在 Cygwin 上也必須裝 (但不用啟動 mysql.server)。我碰到的問題是在 cygwin 中連 localhost 會連到 cygwin 的 MySQL 而不是 windows 的 MySQL，拜過G社大神後，找到的解法非常簡單，只要改連 127.0.0.1即可 (rails 的 database.yaml 把 localhost 改成 127.0.0.1 )。

至此大功告成，成功在 cygwin上執行 ruby script/server。最後乾脆把 Ruby for win32 版也 uninstall了，聽說也許會有衝突(?)。

終於有顏色漂亮又有 auto-complete 的 unix shell ，再也不需要用難用的 windows cmd 啦…:)

最近開始要認真寫程式了，一直在找適合 Ruby on Rails 的 editor for windows，畢竟 notepad++ 實在是陽春了點，我又不喜歡肥大的IDE (aptana? Netbeans+JRuby?)。

本來年初很期待 intype，沒想竟然從年初到現在都沒什麼開發進度，連搜尋功能都沒有實在沒有辦法使用，真是等不及了呀。

前幾天hlb的提醒我才又重新試用 E-TextEditor。記得去年就有看過，不過那時候並沒有留下深刻印象，可能版本還太早…:p

anyway… 回到正題，裝起來之後發現還蠻不錯的，功能成熟多了(畢竟都開始賣錢了) : 有 Tab可以切換文件、可以開啟成 Project 有檔案列表、少不了的搜尋，當然還有重頭戲移植自TextMate 的 Bundles。

首頁的 screencast 介紹了一個蠻實用的功能: 按住 Ctrl 用滑鼠拉出好幾個區域，接著就可以同步修改這幾個地方(例如同時修改好幾處同樣名稱的變數超方便的)，或是用 Alt 拉好幾列可以做同步輸入。

中文有點小問題，看是可以看，不過包中文的引號會小錯置，應該不成大礙。輸入也沒問題。

另外在裝好 E-TextEditor 後，有一些進階功能說要裝 cygwin (也可以不裝)，anyway… 我就想試裝玩玩看吧，沒想到安裝噩夢(?)從此展開，又裝了好多東西，最後整個 Rails 都跑在 cygwin 了，真是棒極了，哈哈。(請待續集 Rails on cygwin)

最後，我也換了 Coding 的字型，一般預設是用 Courier New ，不過經由 ericsk 的介紹，我改裝 Consolas Font Pack for Microsoft Visual Studio 2005 這套試試，接著再把 E-TextEditor 的 theme 換成黑底的 blackboard。嘿嘿，質感好多了… :)

23 透明化信條 Tenets of Transparaency

不同的產品有不同要求的 trust 程度，例如買車會要求高度信心跟信任才會買，買小文具就不會。而買 software 則偏向 “high-trust” 的那端，客戶要相信你的軟體可以解決他們的問題，他們才會掏錢出來買。然而若沒有互信的條件，這樣的關係就無法建立，透明化政策是ISV信任客戶的方式，讓客戶看到更多內部的資訊。當然這會有風險沒錯，但沒有信任，這層關係就無法建立。

就像有餐廳會讓你可以看到廚師做菜，這樣你就可以知道是怎麼煮出來的。又如微軟等公司，產品weblog越來越多，時而堆出beta試用版，讓客戶在軟體開發階段就可以feedback意見……等等

參考的作法有哪些呢?作者提出以下

1. 產品(公司)部落格
2. 提供討論區 Web-Based Discussion Forums
3. 不要隱藏你的產品問題，一個會隱藏bug的公司，通常最後都不會修正那個bug。會fix bug的公司才是值得信任。已經在使用的客戶會希望產品成長跟成熟，希望功能越來越深(works better for the users it already has)，而不是越來越廣(appeal to new users)，一個常見的ISV錯誤就是產品只會變廣(例如模組越做越多)，而不是變深(例如加強現有模組的功能跟使用性，修正現有模組的bug等)。
4. 不要擾人，軟體的 license認證程序不要太複雜。一來沒有不能破解的軟體，二來會讓守法的使用者變難用。我們都很討厭 product activation 程序，雖然微軟是做的不錯(但他們是有本錢做啊)，但作者自己公司的經驗是非常費事，會增加很多技術支援負擔(例如客戶打電話來說有問題不能啟動云云)。
5. 提供無痛線上Demo下載版本，建議用時間限制(例如一個月試用版)，而不要用功能限制。要下載不需要先註冊。
6. 提供不滿意保證退費機制 (例如三十天保證退費)，因為只有極少數會退費，但大多數人會感受更好。
7. 公開一點點財務概況，尤其是你經營良好的話，讓客戶多了解可以增加信任感。
8. 談談未來計畫，客戶會想要知道下一版什麼時候推出?會有什麼功能等等，小心不要講大話即可。

當然，以上建議不是每個都適用，也不是事事都要透明，relationships不能沒有互信，也不能沒有適當的界線。

24 產品定價

Revenue = Quantity * Price，而 Quantity 跟 Price 成反比。

要思考定價，就必須跟產品定位一起思考，然後試著決定你產品價格的 range。

• 誰是你的競爭者，如果你真的認為沒有，那麻你很大大成功要麻大大失敗。
• 什麼是你的產品跟競爭者的差異? 你應該有很簡短的答案。這個差異不該是價格。
• 你的產品定位是什麼?市場如何看待你。
• 競爭者的產品售價是? 客戶一定會拿來比較。

一個重點是你的產品售價應該跟產品定位傳達一致的訊息，例如你要賣一套比 access 更棒的 desktop database application，那你的售價就不應該比 access 還便宜。

思考你的花費，雖然我們不應看成本來定價，但是也要知道成本才能了解價格下限。主要的成本有開發成本(人月)、技術支援成本、通路銷售成本(若有業務則有佣金、代理商、信用卡手續費、團購折價等)、管銷成本(網路費、電費等)。

思考你的產品可以帶給你的客戶多少價值(value)。試著估計產品替代方案的價格，例如你發明電波傳輸器可以把人傳到地球另一端，每次傳送只要100元成本。而替代方案是坐飛機跟住宿要3300元，那你的價格至少應收3300元以上(因為有同樣的價值)。

應該客戶多/價格低? 還是客戶少/價格高? 這要看你的產品定位。不過傳統上如果報酬相同，當然是客戶少點較好，因為成本會較低，事情較少。不過作者偏好客戶多點價格一點的方式，因為客戶多較有力量，規模經濟下也可能降低平均每位客戶的成本。反之高單價的產品常常比較需要業務員來推銷，產生業務成本。

你的產品價格太低了嗎? 價格不應該是產品的主要差異，如果便宜是唯一可以講的東西，就會淪落到 便宜 == 低品質 的刻板印象。

其它的因素還有如果你的產品是 add-on 類型，那應該不會比 base product 還貴。如果你的客戶是大企業環境，有固定的預算上限，那你就可以定出讓客戶不需再往上呈報的價格。(例如以台灣的環境來說，公家機關買東西如果超過10萬就會受到公開招標法限制，會比較麻煩，所以如果可以低於10萬元就會比較省事)

請思考差別訂價，不要死定一個價格而已。你可以有各種優惠價格(例如學術優惠)，找各種方法讓客戶願意付更多錢。最常見的方式有分版(標準版、專業版、企業版)，最常又分三種，最便宜的給那些買不起貴的客戶，最貴的給不想失去任何功能的客戶。但小心定價太複雜不好看懂就是了。

總是會有客戶會報怨嫌貴，別太在意。反而是若都沒有人抱怨貴，那就是你賣太便宜囉。

小心促銷價格的方案，短期可以刺激銷價，但長期來看一定不划算(人們會期待你下次的促銷而停止購買)。

25 Closing the Gap 1

你需要業務(sales guy)嗎? 其實你可以不必要有。

Product—————–Customer

這樣說好了，預期的客戶和你的產品中間有一道 gap，有著各種讓購買行為不會發生的理由，客戶可能沒聽過你的產品或不了解、覺得太貴、產品缺少某種功能或不夠成熟等等。因此ISV必須想辦法越過gap，方法有二，一是將你的產品往右移，告訴大家你的產品是什麼，讓你的產品更好。二是將客戶往左移，找到客戶並說服他購買。

讓我們來定義一下傳統 Proactive Sales 好了，sales 是一種找到目標客戶，然後個別說服他們購買的過程，而做這種事情的人，作者稱呼 sales guy。注意而 marketing 不是 sales，行銷包含更多層面，從策略到廣告。行銷是 1 to many，而業務總是1 to 1。另外在辦公室處理客戶訂單(不是來自sales的客戶)的人不是sales guy，他們是 customer service… :)

另一種定義業務的點是，他們收佣金，拿成交金額的%數。當然這個%數算法有很多因素，但是在很多組織，有最高所得的人常常是業務員!! 即使如此，每次 sales guy跟developer出去喝酒，常常還是developer買單(?)

作者提醒一個重點是，不要讓你的developer花太多時間在幫忙 sales guy，一個極端是業務員帶著developer去拜訪客戶(由developer回答技術問題??)。一種常見的解法是乾脆不同地點辦公室。

 sales guy的一個特質就是一定要愛錢，由錢所驅動，只做有利益的事情。因此再發佣金錢，可以考慮先等在客戶滿意沒問題了才發佣金。sales guy也一定要厚臉皮。

為什麼我們得有 sales guy? 作者列了三個理由 :p

1.因為沒有人會買我們的產品

沒錯，有些產品不太有趣，例如沒有人會非常想去買保險，所以需要業務。重點是你的目標客戶對你的產品要解決問題沒感知。如果你的產品對客戶不是真的非常需要，那你可能需要業務來讓你的客戶了解他們其實有多麼需要，這叫做創造客戶的不滿足(dissatisfaction)，好來買我們的產品。

 如果你才要開始新的 small ISV，作者建議你做一些客戶真的想要而且會感到興奮的東西吧。

2.你的產品非常貴

越貴的東西，越需要業務來幫助客戶下決定，例如車子跟房子。錢越多的產品需要下越大的決心，因此大多數的組織都會用手控(hand-holding)的方式跟客戶完成交易。

3.你的產品不會再有任何改進

隨著產品週期末期，會傾向越來越多業務，然後更少developers，因為你的產品已經不打算進步了，不會再往右跨過gap。所以需要更多的業務來拉攏客戶。

總之，作者根本是建議，大部分的small ISVs最好是不需要任何sales guys… :) 當然也許有例外，但很多公司往往在需要有業務前，就已經找了業務 ，預設了要有業務的立場。

要移動客戶往左跨過gap是費力的，特別是 small ISVs。較好的方式其實是將心力放在gay的左邊，也就是你的產品上。改善你的產品，將你的產品往右移跨過gap，聆聽你的客戶，給他們想要的，讓你的客戶Happy (他們會告訴他們的朋友你有多棒)

專注在你的產品上也會建立出你的核心競爭力，你知道如何將你的產品變得更好。如果你不知道，那你就算有 sales guy，最後也會輸。另一個好處是槓桿作用，當你努力針對某一位客戶改善產品，其實也是對所有的客戶都有幫助。

26 Closing the Gap 2

相對於上一章的 Proactive Sales，這一章作者大力提倡不需業務的 Responsive Sales方式。前者需要業務主動接觸客戶，說服客戶購買。後者由客戶在需要的時候，透過可能是從朋友那邊或從blog看到，查了所有可以查到的資料，然後來跟公司詢問，最後購買。

這章也可以算是這本書的總整理精華。

聽起來 Responsive Sales有點天真，如何相信客戶會自己上門? 是的，我們可以辦到。而且好處多多，實情是客戶喜歡被信任，喜歡自己下決定而不是被業務說服。Responsive Sales不表示我們沒事做，為了達到成功的 Responsive Sales，作者建議以下動作:

1.確定你的客戶知道你的產品

如果客戶連你的產品都沒聽過，當然也就不會發生交易。這部分的工作屬於 Marketing行銷(不是 sales)，更精確的說是指 marketing communications，作者有以下建議:

• 要小心花錢打廣告，尤其是錢多又難以衡量效益的。
• 試著參加展覽。
• 開發過程開放(Develop “in the Open”)，建立產品blog,公開討論區，preview 下載，讓你的客戶們討論。既然開發產品需要時間，何不在開發的時候就吸引注意。

2.確定你的產品有東西是客戶要的

一個好的 proactive sales 可以克服這個問題。但你沒有業務，所以你得更專心在產品吸引力上，你得說服自己你所做的東西是客戶渴望的。這個議題也是行銷的範疇:

• 選擇產品定位，你希望你的產品如何被認識?
• 選擇競爭對手，你需要競爭對手。沒有競爭對手的市場，要嘛你大賺只有你看到商機，要嘛其實根本沒有客戶需求。
• Develop “in the Open”，承第一點不只有廣告的效果，你還可以觀察到哪些東西是客戶真正關心的，可以早點知道市場反應，趁機調整你的產品功能。

3.確定客戶可以承受你的產品價格

流行的說法是你應該主張(claim)價格高點，當你把價格設高一點，也表示你告訴大家你認為你的產品比較有價值。但低價格也有好處，小心客戶預算。

4.提供完整功能的產品 Demo Download

記得下載要非常容易，功能是完整版本，要容易安裝，不需要註冊就能使用。

5.回答客戶問題

作者認為能夠回答深入的技術問題非常重要，在作者的公司，developer也必須幫助客戶。當然作者有建立第一層的客戶支援人員，full-time幫助客戶，但是如果有不能解決的問題，每個 developer 都有責任去做第二層支援。客戶會喜歡可以直接真正寫程式的人聯繫。

6.提供討論社群

潛在的預期客戶會希望可以跟已經購買的客戶做討論 (例如詢問這個產品好不好啊?)，在 Responsive sales 中你應該提供這種機會，你應該對自己的產品有信心，沒有什麼好隱藏的。

當然也許可能會有不好玩的地方(例如現有客戶跟預期客戶抱怨?)，但是這是一個很棒的feedback機制，將迫使你不斷改進產品，讓你的客戶滿意。你的客戶會看到你的努力的。

7.讓產品在Web上就可以容易購買

• 別讓你的客戶一定要註冊才可以購買
• 你不需要購物車，你才幾樣產品啊(perhaps only one)，東西少不需要購物車。
• 實體的東西要寄送就算了，不然最好是下單後，馬上就可以使用!!

最後，你還是覺得 Responsive Sales 行不通嗎?請自身處地想想，以上這些建議，不就是你自己當客戶的時候，所希望的對待嗎?

書末，作者再次提醒真正執行的重要(Just do it)。

作者把行銷跟程式設計類比在一起，程式設計的第一階段是 deisign，第二階段 implementation。行銷同樣也是兩個階段，第一是 strategy，第二才是 maketing communications(如打廣告)。奇妙的是大家都喜歡忽略第一階段的重要性…:p

14. 找產品點子

行銷第一步，就是要找到 product ideas。請先 brainstrming 先想好一堆，暫時還不要去評估。請 focus 在要解決的問題，而不是技術應用。多思考 vertical marketing，特定產業所使用的軟體(當然，最大的問題是你必須知道很多那個領域的知識)。去翻翻電話簿黃頁，看看其他公司可能會使用哪些軟體。問問別人希望有怎樣的軟體。最後是加值產品(add-on product)的可能性，記得要在大的 host application上做外掛。有了一堆點子之後，才開始評估 pick one，記得問問跟你事業無關的人的意見。

幾個重點，最好不要做 game，賣一個解決問題的軟體比較容易。一定要有競爭對手，請多search，沒競爭對手表示很有可能根本沒有這個市場需求。你的產品的差異化是什麼，要有清楚的產品定位。你可以賣的 1.0 產品最好在半年內推出，最好可以直接在線上用信用卡購買。小心目標客戶的預算問題，你的產品價格最好不要高到購買程序變複雜，最好低於$500美金。小心產品技術支援的負擔。

15. 行銷不是後來的步驟

產品定位，作者用一句範例來說明STP的概念。這句話  ”The most popular operating system for desktop PCs”，其中 “The most popular”描述位置(或常說 No.1)，為何要選擇這個產品? “operating system”描述市場分類，這個產品是什麼? “for desktop PCs”則精準描述出哪些族群，誰應該買這個產品? 另一種思考產品定位的方式是，哪一種市場區隔可以讓你的產品是第一名… :p 請注意市場事實，不要自欺欺人，例如不要定位你的繪圖軟體功能最完整(大家都知道是photoshop)。

有了產品定位，你才能決定你的產品要有哪些功能。行銷不只是宣傳你的產品，同時也決定了你要開發什麼樣的產品。

16. 選擇你的競爭對手 

在選產品點子的時候，不要因為有競爭對手就太快放棄點子。因為有競爭對手表示有這個市場，完全避開競爭對手也意謂著完全避開了顧客。全新的點子並沒有想像中的重要，較好的方式是找已經有人做但沒做好，而你可以做更好的。建立一個全新的產品區隔是非常困難的。

因此如何選擇你的競爭對手呢? 那種又大又笨的對手最好了，例如 FedEX 對 U.S.Postal Service。還有 partners 也要選擇一下，第3或第4都可以。至於位於2的公司是活不久的。

競爭者會不斷加入，要如何防禦你的產品市場呢? 別擔心，只要你的產品區隔夠 fragmentation，即你的市場由很多公司所共享，例如不要去加入有90%市佔率的desktop os市場，反之 embedded os 就足夠分散。還有你的產品要夠 differentiation。分散的市場會讓有差異化的產品能夠生存。

17. Act Your Age

跨越鴻溝。產品生命週期可以分成 Early Adopters / Pragmatists / Conservatives / Laggards 四個階段，並可以畫成一個鐘型圖 (以下圖片從網路上抓的)。 其中 Early Adopter 只是喜新厭舊的人，你不能只靠這些人長久生存下去，因此 Pragmatists 才是成功產品最重要的關鍵 (他會引導更多 Pragmatists 跟 Conservatives 購買)，但是請注意這中間有個巨大鴻溝，為了跨越鴻溝，你必須不惜代價要對 Pragmatists 特別好，想辦法去滿足 Pragmatists 的需求。

最大的重點就是不同階段要做不同的事情。一開始針對 Early Adopters，你的產品要又cool又new，且不需要提供 conservative 才需要的boring功能(?)。針對 conservative 則要穩定實用。Early Adopters很有可能也是聰明的geek，對技術多有涉獵，你可以得到一些很棒的想法。而 Pragmatists 跟 Conservatives 並不是 geeks，並不懂技術，你需要更小心的聆聽，記住要解決他們的問題而不是提供很炫的功能。到了 Conservatives 階段則動作要慢，更改任何功能都要慢慢來。

18. Geek Gauntlets 

小心geeks的科技偏見，Early Adopter的feedback也要小心 (也是geeks)。例如喜好用最新技術等等。重點還是 users。

19. Be Careful where you build 

小心平台 platform 的選擇 (這裡廣義包括 Hardware,OS,Programming language,Class libraries,Components,Runtimes,Other Applications等)，畢竟若把房子蓋在沙灘上，大雨一來馬上就垮了。

平台的功能越多越大開發時間可以越短，但是可能 1.效能變慢 2.整合測試變難 3.使用者安裝變冗長 4.透過平台的做法跟一般不同，例如 Java Swing的GUI跟windows native的不同。因此還是要回歸到 users 第一。因此 .NET 雖好，但作者仍建議用C++&MFC。舊技術並不可恥，只要對使用者最好。著重使用者友善跟喜好是第一考量，開發的生產力才是第二。

例如作業系統的選擇，當然支援windows是一定要的，MacOS其實可以考量，市場並沒有想像中的小，只是你產品要做的 really pretty，至於 Linux 就不要考慮了，尤其是桌面應用程式，使用 Linux 的人不但少而且顯然不喜歡花錢。

20. The Game is Afoot 

作者用遊戲來比喻一些競爭策略跟現象:

• 一個自然現象: 產品越老，開發時間越久。Version 4.0 的開發時間比 1.0長，因為你必須處理向下相容/處理現有客戶想要的功能/不要把之前的功能弄壞了… etc
• 產品第一次就要成功比較困難，看到別人的經驗才做叫做 second-mover 優勢。例如 C# 之於 Java。(當然，若 first-mover就能成功，報酬更大)
• 方法論不等於 talent 跟人才，不能用方法論打敗競爭對手。當然這兩種不是互斥，例如 agile 跟 XP 就是讓 smart 開發者更 smart。

21. 參加 Trade Show 

作者這章分享參展經驗。參加展覽不只是為了銷售，而是最好的機會與顧客直接溝通，甚至可以把展覽日期當作你產品的milestones的deadline!

22. 雜誌廣告指南 

作者分享在雜誌登廣告的經驗。登雜誌廣告既貴又難以估計效果，如果不確定要不要登，就是不要。另外無論如何請先用google做 online ad.

(待續，Part 4 Sales)

Part 2 談人 People，讓我想起另一本軟體管理名著: Peopleware。我想兩本書拿來一起比較的話，應該有非常有趣的觀點差異，有機會再來分享那本書的內容。

第八章 Small ISVs 需要 Developers 不要 Programmers

你應該找多才多藝的 developer，而不要找只寫 code 的 programmer。何謂作者定義的 developers，就是除了 coding 跟 fix bugs(幸運的話) 之外，還需要做以下事情 :

• Spec documents
• Configuration management
• Code reviews
• Testing
• Automated tests
• Documentation
• Solving tough customer problems

大公司適用的 programming ，不見得適用小公司。Context is critical。不要把 programming 隔離起來，請教會他! 調整心態不要有 code-only 的想法。

延伸閱讀: Simply Patrick 的 developer vs. programmer 跟 developer vs. programmer, part II

第九章 Geeks 跟 MBAs

這章真是令人興奮，看完一整個爽… XD 一直以來好像創業應該有人負責程式有人負責business(至少眾多創業活動跟競賽都是這麼規定)，不過經過作者這們一說，一個 software company 創立根本不需要找個 businessman 來幫忙。看看這些成功的大公司(microsoft,yahoo，每家的兩個 founder都是技術出身)，其實不止軟體業，科技業的CEO也多是技術出身(這個議題想必商業週刊應該做過研究吧)。

當然，作者不是要說 developer 最偉大，畢竟你還是要跟 “會把HTML當成程式語言” 的人一起互動，但是 developer 也可以去做客服人員、銷售人員、行銷人員，公司不應害怕讓 developer 去做除了軟體開發的事情。公司在討論決策時，也一定要有非技術導向的思維，developer 要讓自己的意見被重視，就應該去學習其他非技術的東西(如行銷)來平衡。

重點是因為初期所有的決策幾乎都跟技術有關(例如一個經典問題，要自己 build 還是 buy?) ，developer 帶來的價值勝過其他人 (正確的說是隨著公司大小而定，公司越小相對價值較高，公司越大相對價值才會降低)，的確是有很多工作是 non-coding，不過那些只是 part-time job(自己或developer來做即可)，你不需要 full-time的人力，創業初期你不需要 MBA，更不需要所謂 businessman 的 co-founder。

延伸閱讀: Simply Patrick 的 developer-centric or not 和 找出 IT 產業的蠢事 末段的 joel 認為一家管理階層缺乏工程技術背景的技術公司不會有太多成功機會。我也非常同意有沒有 developer-centric 的文化是判斷一家軟體公司是否會成功的關鍵。

第十章 雇人

四個做 hire 決策的 guideline :

1. 直到有非常明確且持續性的職位需求時才雇用 (after)，而不是預備性的僱用(before)。這裡提到如果你有接受創投資金，往往會雇用過多的人，因為創投希望你快快成長而不是把錢放銀行。
2. 要了解 Hiring 全關乎機率啊~ 有可能即使看起來條件都很好，進來之後也可能不適用。你只能盡量挑機率大的。
3. 多了解法律合約，可詢問律師。
4. 多聽聽不同觀點的意見，作者建議一定要有女性的意見(畢竟軟體公司有9成的員工是男生)。

要怎麼挑人呢? 首先是寧缺勿濫啊，公司這麼小若請到不適任的人相對損失非常大。

• 請找至少在某一層面上比你優秀的人，有 something 這個團隊沒有的。不要怕員工比你厲害。
• 最好的人就是不會停止學習的人! 這個人會學習嗎?? 會持續學習的人表示知道自己有所不知。
• 了解自己的弱點，不怕討論的人。 (當然，你問的時候要小心面試書籍給他的答案)
• 是否多才多藝願意去做任何能讓產品更成功的事情，而不只是 coding。
• 僱用 Developers，不要 programmers。大公司找 best coder，小公司要找 best developer。
• 教育程度則建議大學程度，Computer Science 領域。作者認為大學學歷最剛好，因為學校是教你成為 computer scientists 而不是 programmer或developer，還有很多學校沒教的東西。但也小心學歷太多，例如 Ph.D，除非有實作經驗。
• 請實際看看來面試的人寫的 code，請問他實際寫過多少程式，coding經驗越多越好，有open source經驗最好(表示對coding有passion)。

第十一章 好 Hacker不等於好 Hire

偉大的Hacker不一定好，因為難搞。hacker常有技術偏見(例如討厭微軟)，因此雖然 productivity 高，卻可能不符合客戶需求。不了解 工作(job) 跟興趣(hobby) 差別，畢竟還是有很多東西並不是有趣的。不關心與使用者的互動，不願意幫助客戶去使用軟體(覺得客戶笨?)……etc

第十二章

偉大的 developers 不只能讓產品更好，也能讓其他人因為跟他共事而更優秀。因此在 hiring developers 的時候，請考慮以下兩個問題:

•  high-notes 能力，這個 developer 能讓產品更優秀嗎? 有創造力嗎?
•  choir 能力，這個 developer 能讓團隊更好嗎? 能促進團隊合作嗎?

第十三章 生涯打算

C = G + LT ，持續學習才是重點。最好的機會就是思考面對所犯的 mistakes，而不是逃避掩蓋。自己的職涯掌握在自己手裡。

(待續，Part 3 Marketing, Part 4 Sales)

就如同Joel所說的，一間非技術背景管理階級的軟體公司，沒有太多機會。要創立軟體公司，還是給搞技術的人來吧… :p

by the way… 如果你對這樣的獨立創業模式(員工人數少、所需資金少，以正現金流量為導向)有興趣，我建議還可以看看這本書 Go It Alone。

回到 Eric Sink 這本書分成四個部份，Entrepreneurship 企業家精神/People 人/ Marketing行銷/Sales 銷售 

Part 1 : Entrepreneurship

第一章 定義 ISV 跟本書預設讀者

 independent software vendor，自行創造/行銷/銷售軟體產品。某個有技術背景的人管理小型 ISV，稱作 a geek founder。

第二章 在有大岩石的桶子中找商機

軟體工業已逐漸成熟，大公司軟體帝國已然建立，所以除非你有革命性的點子或大把資金，否則成熟的市場不歡迎新的大公司。但是較小的市場區隔還是有很好的利基點，即 small ISV。不過在大廠環伺下，機會點有那些呢? 利基在於 1.透過 internet，市場已經是 global 2. relatively safe，大公司沒興趣的小市場，但對小公司來說已非常足夠。

就像一個桶子已經裝滿由大公司擁有的大岩石，但還是有很多空間可以放小石頭。有三個理由我們看不到其中的機會:

1. 我們不想看到，眼界狹小只看到大岩石，而不關心小利基市場。但是一個有 $3M (三百萬美金)年獲利的小ISV(如15~30個員工)，其薪水是非常好的。而且小公司專注在服務基本客戶而不用被創投或季財務預期所干擾。
2. 沒有人頌揚小公司，人們總是關心大公司的新聞，小公司似乎不太酷。但是小公司跟客戶很親密，大公司的政治跟呆伯特問題不存在。
3. 我們看事情非黑即白，學理工的的人看事情常陷入二元思考(Binary thinking)，尤其是思考 business opportunities 的時候，忘了很多事情是灰色的，例如”使用者會買這個產品嗎?”，我們應該改問 “有多少人會買這個產品?”，這很重要。

Size does matter. 找尋小一點的空間，才有很多的酷機會。

第三章 開始你自己的公司，你適合做 software entrepreneur 嗎?

注意這本書講的是 “bootstrapped” 而非 “funded”，即不是拿創投的錢，而是只靠自己，這兩種又有很大的不同。創業前要了解自己，反省及面對自己的弱點，因為需要通才，要學習做很多雜事以及溝通能力。也要想好風險，你有多少失敗空間，克服失敗的恐懼不代表你可以去賭(例如拿房子去抵押太risk了)。

一定要做好行銷作業，市場夠大可以生存嗎?市場夠小可以避開大公司嗎? 作者建議你的市場大小不要超過 $50M USD per year。要做 vertical 而不是 horizontal，即利基市場 (niche market)，當然要進入 vertical maarket 就需要了解特定產業 (domain know-how) ，因此作者特別建議最好別做 tools company (雖然作者自己是)，就是給程式設計師用的工具軟體，因為這個市場暨不大而且大公司因為策略推廣因素又會去做(例如微軟的各式軟體開發工具)。

作者推薦 矽谷之道 這本書來幫助你評估新事業 (雖然作者不喜歡這個書名就是了)，書我買了，不是很厚的MBA書，主要是四十四個非常實務的問題，你可以不用寫完整 bussiness plan (除非要找創投)，但你一定要想過 how to make money，寫下你的財務預測(每個月的收支)，盡量壓低初期花費，小心產品 1.0 release 前就花太多錢。需要seed captial的話，除了借錢之外，作者建議創業一開始也許用接外包案來生存。

第四章 給Geeks的財務

財務之必要，財務之boring。這章簡單介紹三種財務報表(Income statement,Balance sheet,Cash flow statement)跟一些財務名詞(profit margins,revenue,cost of goods,gross profit 等)，為何 open source 營運模式困難，從財務觀點來看因為它傾向低毛利率。你需要外部資金嗎? 如果是用自己的盈餘慢慢成長，只要cash不花完就ok，但如果拿了外部資金，創投會要你快快花大錢快速成長，而且若只是 breakeven (損益平衡)還是算失敗 (投資報酬率太低)。

看完這章讓我第一次認識到 應計制會計 這個名詞… :p 接著又啃了一本會計入門書。

第五章 探索 Micro-ISVs

何謂 Micro-ISV，就是比 smail ISV 還小，只有一人負責所有事情… XDXD 話說有本書就叫 Micro-ISV ，不過那本書定義的應該不限一人。

第六章 第一份我的 Micro-ISV 報告

作者親自實驗一個 Micro-ISV 計畫，他實作一個簡單的game來賣… 不過最後失敗沒幾個人買… XD 他檢討有幾個原因，如產品不夠區隔化、不應做遊戲、需要更持續的投入… etc

第七章 犯更多錯

這章還蠻有趣的，提到幾個作者犯的錯誤。每個CEO都會犯很多錯。例如小心簽約時就固定金額的 project (後來的開發成本超出預估)、小心太新的技術、不要買房地產(隨著員工變多就不實用)、小心沒有競爭者的市場(因為根本沒有人需要那個產品)、小心 middleman (掮客)、所有合約應該要給律師看過、多用現成的技術跟標準等等故事。

延伸閱讀: Simply Patrick 的 Start a Startup

(續集，Part 2 People, Part 3 Marketing, Part 4 Sales )

就是今天，終於發布第一個公開版本啦，實際裝起來用超興奮的。

Apollo 是一套由 Adobe 所開發的跨作業系統執行平台(runtime)，它讓開發者可以使用現有的網站開發技術來建立跟部署桌面軟體 rich Internet applications (RIAs)。它同時結合了 Web 應用程式跟桌面軟體的優點，讓 Web 應用程式也可以享受到本地端儲存跟執行的能力。

Apollo 已經公開的 API 有:

• 檔案的輸入與輸出 (File I/O) 
• 即時線上與離線狀態 (Online/Offline)
• 視窗 (Windowing)
• 複製到剪貼簿 (Clipboard)
• 使用系統上的拖曳與放開 (System Drag and Drop)
• 完整的網路 API 支援 (Full Network API support)
• 本地的儲存與設定 (Local Storage/Settings)

Apollo 的 Web 引擎使用 WebKit，也就是 Mac OS X 的 Safari 跟 KDE 的 KHTML 所使用的引擎。WebKit 之所以雀屏中選，根據 Apollo FAQ 有幾個原因:

• 開源項目 Open Source
• 被開發者和終端用戶所熟悉
• 小巧
• 在移動設備上能運行良好

對 Web 開發者來說，Apollo 應該是很有吸引力的技術 (也是Apollo的主要目標對象)，我們可以用已經熟悉的技術 HTML,CSS,JavaScript,Ajax 或 Flash,Flex,ActionScript (也可以兩種混用) 來開發桌面應用軟體。

台灣 Adobe 有翻譯了 Apollo 開發 FAQ。

蔡學鏞也有幾篇文章可以參考，專訪Adobe資深副總裁暨軟體架構長Kevin Lynch 跟 另一個阿波羅冒險故事的開始…從市場面介紹Adobe Apollo。

RIS – Rich Internet Solutions 這個站則收集不少中文資源。