故事的背景設定還算蠻特別的，一位對魔法免疫的女生，進入了魔法製造有限公司工作，原因是因為她的所有感官沒辦法被魔法影響，反而法師與一般人類，都是會被魔法攻擊或是影響的。魔法製造公司要讓這些免疫者來幫忙看出，物品有沒有被幻象影響，銷售魔法的商店有沒有違背銷售的合約。
魔法製造公司因為一位離職員工愛德瑞斯開發了新產品，來爭奪魔法公司獨占的魔法銷售市場，而這位員工離職的原因，就是因為深入研究了黑魔法，製造出一些副作用強烈的商品在市面上銷售。為了這個問題，魔法製造公司還特地請出一千年前就誕生的梅林，重新職掌公司的運作。
凱蒂以他免疫者的態度與想法，透過行銷的方式，又找來瞭解智慧財產權的律師，來幫助魔法製造公司渡過難關。
雖然故事背景設定蠻厲害的，但是在故事的後面，原本我一直以為凱蒂一直在做的盲目約會，會遇上愛德瑞斯，不過顯然作者沒有想要讓故事更複雜。故事最後的那一場魔法的火拼，發生的原因只是因為伊森發了一張存證信函，這更令人驚訝，既然是個壞蛋，怎麼會在意這樣一張警告信函，既然是對手，就算是上法院也沒關係阿。火拼的過程篇幅非常短很快就草草結束了，更令人失望。
律師伊森、法師歐文跟凱蒂的關係，到了故事結束的時候，都沒有交待清楚。不過搜尋過後才知道，這是一系列的故事，原文已經推出到第四集了，但中文翻譯只有第一集。
書評：魔法製造有限公司—我的總裁是魔法師梅林
魔法製造有限公司 讀後心得
2011/12/25
2011/12/24
艾比斯之夢 by 山本弘
在閱讀前並沒有對這本書的名字有多少印象，根本也忘了為甚麼會買，原本沒有期待太多，不過讀完之後，有種不虛此讀的感覺。
一般的短篇故事集，都是各自獨立的，而這本書的每一個小故事，都像是一千零一夜一樣，是一個大故事中的多個小故事。就像是奇幻基地部落格介紹的一樣，這是一本AI版一千零一夜的故事集。
另一個重點，就如同科幻國協毒瘤在臺病灶所說的，雖然android是以人類為範本而發展出來的，但是機器人AI的演化終點，並不是人類，而是超越人類的全新物種。人類滿心覺得，既然是機器「人」就應該跟人類完全一樣，如果發展成另一種生物，那不就完全違背了開發的初衷。
機器人為了求得自己的生存，而選擇犧牲了某一小部份人類的利益，並隱藏了自己的能力，最終還在Layer 1中建立自己的王國，既沒有反撲人類的情節，也沒有被人類消滅，這個新物種找到了安全生存下去的方法。
如夢似幻，如詩如歌的科幻奇想異作－《艾比斯之夢》，AI版一千零一夜的故事，好評登 場！
《艾比斯之夢》（《アイの物語》，2006 c.）by 山本弘
一般的短篇故事集，都是各自獨立的，而這本書的每一個小故事，都像是一千零一夜一樣，是一個大故事中的多個小故事。就像是奇幻基地部落格介紹的一樣，這是一本AI版一千零一夜的故事集。
另一個重點，就如同科幻國協毒瘤在臺病灶所說的，雖然android是以人類為範本而發展出來的，但是機器人AI的演化終點，並不是人類，而是超越人類的全新物種。人類滿心覺得，既然是機器「人」就應該跟人類完全一樣，如果發展成另一種生物，那不就完全違背了開發的初衷。
機器人為了求得自己的生存，而選擇犧牲了某一小部份人類的利益，並隱藏了自己的能力，最終還在Layer 1中建立自己的王國，既沒有反撲人類的情節，也沒有被人類消滅，這個新物種找到了安全生存下去的方法。
如夢似幻，如詩如歌的科幻奇想異作－《艾比斯之夢》，AI版一千零一夜的故事，好評登 場！
《艾比斯之夢》（《アイの物語》，2006 c.）by 山本弘
2011/12/20
ReWork 工作大解放 by 福萊德．漢森
37 Signals從創業開始，就沒有打算要藉由創投取得創業基金，而是採取穩紮穩打的方式，透過自己產品的獲利養活自己。雖然客戶不多，而且又多是提供給企業用戶使用，現在證明了這種方式也可以讓一家公司自給自足好好地活著。
書本裡的內容就不提了，這邊要記錄的是37 Signals所發布的一個iPad白板應用，以及一個白板網頁。37 Signals的差別訂價心法：利潤最大化，而非市占率最大這篇文章有詳細的說明。
http://chalk.37signals.com/ 這個網頁白板或許應該稱為網頁黑板，因為他只有三個畫圖工具，一隻白色粉筆，一隻紅色，還有一個板擦，分享的按鈕按下去卻不知道發生什麼狀況，畫面就卡住了。就inside介紹的文章內容得知，Draft也是個非常簡單的工具，但37 Signals就硬是把他標成9.99USD，功能只有簡單的白板跟分享。
企業首要該追求的是獲利，免費或低價是一種定價策略，但並不是為了什麼追求自由Open的理想才定價為Free，如果想要定價為免費，一定有其他的原因或理由，才要這樣做。舉例來說，硬體Server擁抱免費的Linux，原因就是希望藉由Linux提振Server的銷售量。
有了企業版Redhat，卻又提供了免費的CentOS，原因就在於藉由免費，吸引廣大的商業客戶，習慣了CentOS之後，在需要授權時，可以直接購買Redhat，無痛直接由CentOS轉移到Redhat。
Free是一種定價策略，不是一種要追求的信仰或精神，免費或是自由之前，必須要自給自足養活自己。
客座文：網路名書Rework (工作大解放) 讀後感
「工作大解放 Rework」團隊37 Signal的新辦公室
簡練而雋永的工作守則--《Rework! 工作大解放》讀書筆記
閱讀「工作大解放」Rework Part-1
閱讀「工作大解放」Rework Part-2
書本裡的內容就不提了，這邊要記錄的是37 Signals所發布的一個iPad白板應用，以及一個白板網頁。37 Signals的差別訂價心法：利潤最大化，而非市占率最大這篇文章有詳細的說明。
http://chalk.37signals.com/ 這個網頁白板或許應該稱為網頁黑板，因為他只有三個畫圖工具，一隻白色粉筆，一隻紅色，還有一個板擦，分享的按鈕按下去卻不知道發生什麼狀況，畫面就卡住了。就inside介紹的文章內容得知，Draft也是個非常簡單的工具，但37 Signals就硬是把他標成9.99USD，功能只有簡單的白板跟分享。
企業首要該追求的是獲利，免費或低價是一種定價策略，但並不是為了什麼追求自由Open的理想才定價為Free，如果想要定價為免費，一定有其他的原因或理由，才要這樣做。舉例來說，硬體Server擁抱免費的Linux，原因就是希望藉由Linux提振Server的銷售量。
有了企業版Redhat，卻又提供了免費的CentOS，原因就在於藉由免費，吸引廣大的商業客戶，習慣了CentOS之後，在需要授權時，可以直接購買Redhat，無痛直接由CentOS轉移到Redhat。
Free是一種定價策略，不是一種要追求的信仰或精神，免費或是自由之前，必須要自給自足養活自己。
客座文：網路名書Rework (工作大解放) 讀後感
「工作大解放 Rework」團隊37 Signal的新辦公室
簡練而雋永的工作守則--《Rework! 工作大解放》讀書筆記
閱讀「工作大解放」Rework Part-1
閱讀「工作大解放」Rework Part-2
2011/12/19
第 13 個小時 by 理查．道許
時光倒流了，主角尼克得到了一個可以回到過去的禮物，每一次倒退一個小時，而他回去的理由，就是要救回茱莉亞的生命。
作者在 《第13個小時》 講述這本書的內容時，有提到這本書的十個角色，其中有七個是從時光旅行相關的故事中取出來使用的，還做了有獎徵答。不過讀翻譯的我們可能永遠都猜不到答案，在網頁上好像也沒有公佈解答。
正如作者所說的，這本書的故事結構很簡單，就十三個小時的時間，每一個小時一個章節，整本書讀起來就已經有點像是在看電影一樣，未來在電影上市後，應該會是一個劇情緊湊的懸疑片。
故事結束時，原本的一隻金錶變成了兩隻，原本時光旅行就會造成這樣的問題，帶著未來的東西回到過去，就像是回到未來那部電影一樣，主角駕著時光車穿梭時空，人跟車子都同時移動了時空。
仔細想想，如果成真的話就不得了了，不管任何東西都可以透過時光旅行複製並得到一個全新的，這樣的話，整個世界不就被塞滿了一堆完全一樣的東西了嗎？而且也可以透過重複回到前一分鐘的方法，把自己複製一份，真的就亂了套。
也因此，多數的時光旅行故事，都會強調，同一個人在不同的時空當中，是不能撞擊在一起的，否則將會造成時光錯亂的災難。但這本書並沒有這樣處理，不過也沒關係，因為這不是重點。
一次倒退一小時，有點像是警察審問犯人，要犯人慢慢回想事發當時發生的事情一樣，有些人就會用倒推的方法，回想自己在那時候去了哪裡，做了什麼事情。
另外一個例子是，有時候會突然發現自己把錢包忘在某一個地方了，通常就會用倒推的方式，先想想自己剛剛在哪裡，然後回到那個地方找找看，找不到的時候，再往回推一步，回想再之前，自己在什麼地方，就這樣一步一步反推回去，直到找到那個錢包。
重來的機會──《第13個小時》
讀《第十三個小時》
《第十三個小時》博客來 嗜‧讀本 活動
作者在 《第13個小時》 講述這本書的內容時，有提到這本書的十個角色，其中有七個是從時光旅行相關的故事中取出來使用的，還做了有獎徵答。不過讀翻譯的我們可能永遠都猜不到答案，在網頁上好像也沒有公佈解答。
正如作者所說的，這本書的故事結構很簡單，就十三個小時的時間，每一個小時一個章節，整本書讀起來就已經有點像是在看電影一樣，未來在電影上市後，應該會是一個劇情緊湊的懸疑片。
故事結束時，原本的一隻金錶變成了兩隻，原本時光旅行就會造成這樣的問題，帶著未來的東西回到過去，就像是回到未來那部電影一樣，主角駕著時光車穿梭時空，人跟車子都同時移動了時空。
仔細想想，如果成真的話就不得了了，不管任何東西都可以透過時光旅行複製並得到一個全新的，這樣的話，整個世界不就被塞滿了一堆完全一樣的東西了嗎？而且也可以透過重複回到前一分鐘的方法，把自己複製一份，真的就亂了套。
也因此，多數的時光旅行故事，都會強調，同一個人在不同的時空當中，是不能撞擊在一起的，否則將會造成時光錯亂的災難。但這本書並沒有這樣處理，不過也沒關係，因為這不是重點。
一次倒退一小時，有點像是警察審問犯人，要犯人慢慢回想事發當時發生的事情一樣，有些人就會用倒推的方法，回想自己在那時候去了哪裡，做了什麼事情。
另外一個例子是，有時候會突然發現自己把錢包忘在某一個地方了，通常就會用倒推的方式，先想想自己剛剛在哪裡，然後回到那個地方找找看，找不到的時候，再往回推一步，回想再之前，自己在什麼地方，就這樣一步一步反推回去，直到找到那個錢包。
重來的機會──《第13個小時》
讀《第十三個小時》
《第十三個小時》博客來 嗜‧讀本 活動
2011/12/10
編程的頂尖對話 Coders At Work by Peter Seibel
作者 Peter Seibel 訪問了15位軟體大師，當然 Peter Seibel 要能訪問這些人，就必須要先瞭解所有人的基本背景，而且要知道他們擅長的軟體技術，這才能問出一些像樣的問題，也才能勾勒出這些大師最深層的想法。
問題的項目大致上就是以下這些：
1. 什麼時候開始做程式設計
2. 最喜歡、熟悉那一個語言
3. 如何除錯、設計程式
4. 印象最深的程式
5. 規模最大的程式
6. 有沒有嘗試過 Pair Programming
7. 有沒有做過Literate Programming，有沒有讀過TAOCP
8. 對 Java 的看法
9. 有沒有推薦的書籍
10. 是否會閱讀程式碼
11. 如何學習，並增進自己的程式功力
12. 如何定義自己：工程師、工匠、科學家或是藝術家
13. 喜歡什麼工作，排斥什麼工作，喜歡什麼語言，排斥什麼語言
15位大師分別為
Jamie Zawinski: 早期接觸LISP與AI，Netscape UNIX版, Netscape Mail Reader早期開發者之一，開發了 XEmacs
Brad Fitzpartrick: LiveJournal網站創辦者，開發了memcached, Perlbal, MogileFS
Douglas Crockford: Yahoo!資深Javascript架構師，開發了JSON，提案ECMASscript 3.1，反對ECMAScript 4
Brendan Eich: Mozallia 的 CTO，Javascipt發明者，1998年跟 Jamie Zawinski勸說Netscape將瀏覽器open source
Joshua Bloch: Goole首席Java架構師，實現了 Java Collection Framework，因 Effective Java獲得 2001年Jolt大獎
Joe Armstrong: 發明了 Erlang，建立了Open Telecom Platform(OTP)
Simon Peyon Jones: 定義 Haskell，名言「不惜一切代價避免成功」，著迷於函數式程式設計
Peter Norvig: Google 研究總監，2001年獲得NASA傑出成就獎，AAAI與ACM的成員
Guy Steele: 參與了Common Lisp與Scheme的建立，也在 Common Lisp, Fortran, C, ECMAScript, Scheme的標準化組織中工作，是ACM會員，美國藝術與科學院院士
Dan Ingalls: 參與了一至七代Smalltalk的實作，直到現在的Squeak，發明了用於點陣圖的BitBlt
L Peter Deutsch: 11歲開始coding，發明了Just-In-Time Compiler，發表著名論文「分散式運算的七個謬論」，Ghostscript開發者
Ken Thompson: UNIX 發明者，發明了B語言，設計了UTF-8 Unicode
Fran Allen: 以「最佳化編譯器技術的理論和實作領域中的開拓性貢獻」獲得圖靈獎，40年來第一位獲此殊榮的女性，IBM第一位女院士，IEEE院士...
Bernie Cosell: ARPANET 早期實現者之一
Donald Knuth: Tex花了十年，寫了TAOCP，提倡Literate Programming
閱讀每一個人清楚地談論自己是有趣的，但我也在讀完後，就忘得差不多了，畢竟那些都不是我自己的人生，就算是我自己的經歷，也常因為記憶破碎的關係，而模糊不清。
這些大師都是早期處理電腦軟體科學的人，普遍認為要從到電腦語言深入到任何可能的核心去追查問題。對目前我們都習慣使用很多被包裝好的函式庫的Programmer來說，要掌握追查所有核心線索的背景知識，是一件非常困難的事。說困難倒不如說，我們很懶，懶得去追問更多核心的問題，而是一直等待別人解決。
問題的項目大致上就是以下這些：
1. 什麼時候開始做程式設計
2. 最喜歡、熟悉那一個語言
3. 如何除錯、設計程式
4. 印象最深的程式
5. 規模最大的程式
6. 有沒有嘗試過 Pair Programming
7. 有沒有做過Literate Programming，有沒有讀過TAOCP
8. 對 Java 的看法
9. 有沒有推薦的書籍
10. 是否會閱讀程式碼
11. 如何學習，並增進自己的程式功力
12. 如何定義自己：工程師、工匠、科學家或是藝術家
13. 喜歡什麼工作，排斥什麼工作，喜歡什麼語言，排斥什麼語言
15位大師分別為
Jamie Zawinski: 早期接觸LISP與AI，Netscape UNIX版, Netscape Mail Reader早期開發者之一，開發了 XEmacs
Brad Fitzpartrick: LiveJournal網站創辦者，開發了memcached, Perlbal, MogileFS
Douglas Crockford: Yahoo!資深Javascript架構師，開發了JSON，提案ECMASscript 3.1，反對ECMAScript 4
Brendan Eich: Mozallia 的 CTO，Javascipt發明者，1998年跟 Jamie Zawinski勸說Netscape將瀏覽器open source
Joshua Bloch: Goole首席Java架構師，實現了 Java Collection Framework，因 Effective Java獲得 2001年Jolt大獎
Joe Armstrong: 發明了 Erlang，建立了Open Telecom Platform(OTP)
Simon Peyon Jones: 定義 Haskell，名言「不惜一切代價避免成功」，著迷於函數式程式設計
Peter Norvig: Google 研究總監，2001年獲得NASA傑出成就獎，AAAI與ACM的成員
Guy Steele: 參與了Common Lisp與Scheme的建立，也在 Common Lisp, Fortran, C, ECMAScript, Scheme的標準化組織中工作，是ACM會員，美國藝術與科學院院士
Dan Ingalls: 參與了一至七代Smalltalk的實作，直到現在的Squeak，發明了用於點陣圖的BitBlt
L Peter Deutsch: 11歲開始coding，發明了Just-In-Time Compiler，發表著名論文「分散式運算的七個謬論」，Ghostscript開發者
Ken Thompson: UNIX 發明者，發明了B語言，設計了UTF-8 Unicode
Fran Allen: 以「最佳化編譯器技術的理論和實作領域中的開拓性貢獻」獲得圖靈獎，40年來第一位獲此殊榮的女性，IBM第一位女院士，IEEE院士...
Bernie Cosell: ARPANET 早期實現者之一
Donald Knuth: Tex花了十年，寫了TAOCP，提倡Literate Programming
閱讀每一個人清楚地談論自己是有趣的，但我也在讀完後，就忘得差不多了，畢竟那些都不是我自己的人生，就算是我自己的經歷，也常因為記憶破碎的關係，而模糊不清。
這些大師都是早期處理電腦軟體科學的人，普遍認為要從到電腦語言深入到任何可能的核心去追查問題。對目前我們都習慣使用很多被包裝好的函式庫的Programmer來說，要掌握追查所有核心線索的背景知識，是一件非常困難的事。說困難倒不如說，我們很懶，懶得去追問更多核心的問題，而是一直等待別人解決。
2011/12/5
約耳趣談軟體 by Joel Spolsky
Part 1 是一個開發人員要知道的基本知識。chap3 他提到了12點應該要作到的事情，作到了才會得到一個高品質的軟體。我們並不是完全都符合這些條件，但也不是全部都沒作到，例如規格這個部份，我們的產品並沒有一份正式的完整的規格文件，但是在每一次要修改的時候，我們都會確認一次修改的內容，至於規格就是討論出來，比較明確的是UI上要長出來的東西，至於後端的改進，就只能用文字來描述。
我們有用 BugZilla+SVN，搭配著Eclipse的MyLyn使用，整合起來很方便，當產品或專案在發展的過程中，有著BugZilla搭配著問題跟解決狀況，對專案管理來說可以很輕鬆地掌握目前開發的進度跟狀況，也知道每一個PG的生產力與進度，但在產品發展到比較穩定的狀態，沒有很多項目要修改的時候，我們就比較少用到這個東西了。
我們沒有固定的測試人員，通常會讓新進人員充當測試者，既可以讓他熟悉整個產品的功能，也可以因為他還不是開發人員的身份，而更客觀地以使用者的角度來使用跟測試這個軟體。不過當這個開發人員進入專案作為一個開發者的時候，就不能把他當測試者了。這時候，我們會讓公司裡面的美工或其他非此專案的開發人員來充當測試者。總和來說，我們沒有固定的測試人員，但我們在某些特定的時刻，會配置臨時的測試人員。
每日編譯沒有做，但我會每天checkout大家commit進去的東西，並確認隨時都可以編譯，出 Error時就會去問問看，是不是有什麼檔案忘了commit，人總是會掉芝麻粒的。
其他幾個項目，我們沒有作到完美，但都是有的，例如一個步驟建構專案，用SVN，修正問題後再繼續新的程式，安靜的工作環境，但這一點講得有點心虛，因為常常會因為我講電話太大聲，而破壞這個寧靜，不過開發人員通常會用耳機+音樂這種白噪音來解決這個問題。
邊開火邊射擊，這是一個小公司所能擁有的特色，因為小，所以反應要快，轉換要快，內部溝通要順利，人都已經這麼少了，還在內耗，這樣的公司最好盡早離開。軟體技術有一定的更迭週期，隨著大環境的變動，我們就是得要一邊轉換跑道，一邊跟著市場的腳步轉變方向，還得要配合客戶的需求變動，每天都有新的挑戰要做。
因為 Joel 是做套裝軟體的，因此他們必須面對各種使用者的 Windows 環境，也可能會遇到很多當機的狀況，他們就必須要自動化收集當機狀況。我還蠻羨慕可以這樣的，我們的產品都是網頁的App，我不曉得有什麼方法，可以直接收集在使用者的瀏覽器中crash的狀況，通常我們都是到server裡面去看錯誤log，至於網頁上出現的錯誤訊息，都是讓回報人員剪貼畫面，並詢問使用的狀況，來判斷發生錯誤的問題點。
這樣的錯誤收集方法，在有限客戶的狀況還可以處理，但未來如果客戶變多了，或是做了網頁服務，可能就得考慮要有個錯誤收集器，並自動將錯誤回報給Server，但這個方法還是沒有辦法知道，客戶的錯誤畫面出現了什麼東西，應該找個時間研究一下這個問題（Can you take a 「screenshot」 of the page using Canvas?、Take a screenshot of a webpage with javascript?，看來做得到，但for IE only）。
Part 2 提到如何管理開發人員。就一個軟體公司來說，硬體成本非常地低，公司資本額也不需要太多，唯一最需要耗費的，就是人力成本，而且人力是最難被估計跟測量的一個工具，當然也是最難被管理的一項工具。
從 chap 20 提到怎麼面試一個開發人員，對尋找熱情這一點我非常同意，壞人選在面試時跟本部會在意什麼事情，也沒有什麼情緒起伏，因為他們只是要找一份工作而已，沒有其他更深層的想法。至於在面試時直接要求他寫一個function，我曾經想過要套用這個作法，讓面試者可以用電腦查資料，然後利用一段時間寫一隻程式，但目前還沒有這樣試過。
尋找一個有熱情的人，這一點，我們是思考一種方法，要求應徵者做一個15分鐘的短簡報，藉此來判斷這個人有沒有辦法清楚地整理自己的資料，並透過簡報的方式講出來，而不是簡單地用一問一答的方式來處理，其實問答的互動方式，常常會遇到一個狀況，就是應徵者只講了幾句話就講不下去了，短短地回答讓人不知道該如何是好，話越少當然就越難分辨與判斷這個人的優缺點。
關於測試人員的狀況，似乎是個無解的問題，因為軟體開發人員不一定會是一個好的測試人員，測試人員得不厭其煩重複測試的內容與動作，也必須像是雞蛋挑骨頭一樣，找很多特殊的使用狀況來測試一個軟體，而好的測試人員也不一定會一直甘心做QA的工作，公司還得替他們規劃如何轉進到開發單位，要不然這樣一個人才，可能會在一段時間後，滿腔熱血就被消磨殆盡。
而軟體又不是一個可以完全被自動化測試的產品，總會有很多地方，需要用非常原始的人工方法，去做測試，甚至要當一個天真的使用者，去使用這個軟體，才會發現很多問題。軟體的品質對產品來說又是個非常重要的議題，這個無解的難題，相信還會一直困擾著我，揮之不去。
chap 25提到了身為一個軟體開發人員或是公司的生存法則，當展示使用者介面給非開發人員看時，如果畫面不好看，就算內部設計再好也都等於是白做的，因為User一看到這樣的介面就不想用了，怎麼會知道你的產品好或壞。但相反地，如果展示的時候，畫面很好看，他會認為你已經把所有功能都完成了，在這些畫面裡面填上程式碼是非常簡單的工作。
產品demo的時候一定要炫，就Steve Jobs最了這件事情，這樣才能吸引大家的目光。如果畫面還沒完成，就讓他這樣，不要一開始就全部做完，但每一個功能都有缺陷。由非技術人員啟動的專案，在提報資料的時候，必須要提供幾種美術設計讓他選，原因有兩個，第一要讓他們有參與的感覺，並做出決策，第二是不要讓他們深入到設計的細節，甚至更動軟體的內部邏輯，因為這樣的更動可能會變成大災難。
作者的軟體公司以販賣Windows軟體維生，在chap30這個國家的狗做些什麼工作？這一章裡面，他提到一件非常重要的事情，就是要吃自己的狗食，換句話說，就是要使用自己開發的
軟體。當公司裡面的人真正去使用軟體時，才會發現很多使用上設計不良的問題。自己生產的東西，如果連自己用起來都不順利，那麼怎麼能說服客戶花錢去買一個這樣的軟體！
開發人員必須也要是這個軟體的使用者，用了之後，才知道好不好用，才能針對軟體提出更好的設計。用了之後，如果用得很高興，也會對自己的工作更有認同感，做起事情才會更起勁。
在 chap36 Ben and Jerry 模式與 Amazon 模式，Joel 提到了兩種截然不同的商業模式，兩種都有可能會成功，也有可能會失敗，但他提醒大家，要認清自己的定位，而且要堅持下去從一而終，搖擺不定的作法只會虛耗資源。
在 chap 40 開放源碼的經濟學中，他提到為甚麼一些商業公司要支援開放源碼，甚至大力推銷這樣的軟體開發策略，不管如何，開發一個軟體需要耗費成本，一個能讓很多開發者注意甚至無嘗貢獻自己的資源的軟體專案是非常幸運的，多數的開放源碼產品背後都有個商業公司協助支撐整個專案的開發。
這樣的策略就像是一家讓客戶喝啤酒免費的餐廳一樣，客人會因為免費的啤酒，上門消費，因為喝酒而點很多菜，而餐廳就可以靠這些菜餚賺錢。因此，撇開開放源碼藉以推動軟體世界的良性循環來說，單就商業利益的角度來看，在開放源碼的同時，除非有著連帶的附加價值，要不然就沒有必要耗費自己的資源做這些事情。
作者 Joel 的公司是採用 MS 的技術，雖然在 Part4 裡面，對 MS .NET 有著深深地怨念，但似乎也只能摸摸鼻子，就這樣接受 MS 打破過去一直以來的往下相容的策略，而是採用全新的軟體架構。這似乎是一個無解的問題，因為往下相容，導致公司要一直為了舊的錯誤設計多寫很多程式，多做很多例外處理。但是身為作業系統的平台，當 MS 無法以嶄新功能吸引使用者付費升級的同時，只好大破大立地將舊的系統破壞掉，期待以新的架構，吸引使用者的目光，進而付費升級。
雖然 Joel 認為 MS 現在的 .NET 策略錯了，但他也設下伏筆，告訴讀者，因為 MS 本身的現金足夠，可以花好幾年的時間大破大立，就算策略錯誤，因為公司龐大，還是有可能會再將策略轉彎，換句話說，Joel 希望 MS 注意到他對 .NET 所下的註解，而重新檢視公司的發展策略。
《約耳談軟體(Joel on Software)》翻譯計畫
約耳趣談軟體：來自專案管理的現場實錄
約耳趣談軟體 讀後心得
[約耳趣談軟體] 心得筆記：如何決定是否要雇用某人？
我們有用 BugZilla+SVN，搭配著Eclipse的MyLyn使用，整合起來很方便，當產品或專案在發展的過程中，有著BugZilla搭配著問題跟解決狀況，對專案管理來說可以很輕鬆地掌握目前開發的進度跟狀況，也知道每一個PG的生產力與進度，但在產品發展到比較穩定的狀態，沒有很多項目要修改的時候，我們就比較少用到這個東西了。
我們沒有固定的測試人員，通常會讓新進人員充當測試者，既可以讓他熟悉整個產品的功能，也可以因為他還不是開發人員的身份，而更客觀地以使用者的角度來使用跟測試這個軟體。不過當這個開發人員進入專案作為一個開發者的時候，就不能把他當測試者了。這時候，我們會讓公司裡面的美工或其他非此專案的開發人員來充當測試者。總和來說，我們沒有固定的測試人員，但我們在某些特定的時刻，會配置臨時的測試人員。
每日編譯沒有做，但我會每天checkout大家commit進去的東西，並確認隨時都可以編譯，出 Error時就會去問問看，是不是有什麼檔案忘了commit，人總是會掉芝麻粒的。
其他幾個項目，我們沒有作到完美，但都是有的，例如一個步驟建構專案，用SVN，修正問題後再繼續新的程式，安靜的工作環境，但這一點講得有點心虛，因為常常會因為我講電話太大聲，而破壞這個寧靜，不過開發人員通常會用耳機+音樂這種白噪音來解決這個問題。
邊開火邊射擊，這是一個小公司所能擁有的特色，因為小，所以反應要快，轉換要快，內部溝通要順利，人都已經這麼少了，還在內耗，這樣的公司最好盡早離開。軟體技術有一定的更迭週期，隨著大環境的變動，我們就是得要一邊轉換跑道，一邊跟著市場的腳步轉變方向，還得要配合客戶的需求變動，每天都有新的挑戰要做。
因為 Joel 是做套裝軟體的，因此他們必須面對各種使用者的 Windows 環境，也可能會遇到很多當機的狀況，他們就必須要自動化收集當機狀況。我還蠻羨慕可以這樣的，我們的產品都是網頁的App，我不曉得有什麼方法，可以直接收集在使用者的瀏覽器中crash的狀況，通常我們都是到server裡面去看錯誤log，至於網頁上出現的錯誤訊息，都是讓回報人員剪貼畫面，並詢問使用的狀況，來判斷發生錯誤的問題點。
這樣的錯誤收集方法，在有限客戶的狀況還可以處理，但未來如果客戶變多了，或是做了網頁服務，可能就得考慮要有個錯誤收集器，並自動將錯誤回報給Server，但這個方法還是沒有辦法知道，客戶的錯誤畫面出現了什麼東西，應該找個時間研究一下這個問題（Can you take a 「screenshot」 of the page using Canvas?、Take a screenshot of a webpage with javascript?，看來做得到，但for IE only）。
Part 2 提到如何管理開發人員。就一個軟體公司來說，硬體成本非常地低，公司資本額也不需要太多，唯一最需要耗費的，就是人力成本，而且人力是最難被估計跟測量的一個工具，當然也是最難被管理的一項工具。
從 chap 20 提到怎麼面試一個開發人員，對尋找熱情這一點我非常同意，壞人選在面試時跟本部會在意什麼事情，也沒有什麼情緒起伏，因為他們只是要找一份工作而已，沒有其他更深層的想法。至於在面試時直接要求他寫一個function，我曾經想過要套用這個作法，讓面試者可以用電腦查資料，然後利用一段時間寫一隻程式，但目前還沒有這樣試過。
尋找一個有熱情的人，這一點，我們是思考一種方法，要求應徵者做一個15分鐘的短簡報，藉此來判斷這個人有沒有辦法清楚地整理自己的資料，並透過簡報的方式講出來，而不是簡單地用一問一答的方式來處理，其實問答的互動方式，常常會遇到一個狀況，就是應徵者只講了幾句話就講不下去了，短短地回答讓人不知道該如何是好，話越少當然就越難分辨與判斷這個人的優缺點。
關於測試人員的狀況，似乎是個無解的問題，因為軟體開發人員不一定會是一個好的測試人員，測試人員得不厭其煩重複測試的內容與動作，也必須像是雞蛋挑骨頭一樣，找很多特殊的使用狀況來測試一個軟體，而好的測試人員也不一定會一直甘心做QA的工作，公司還得替他們規劃如何轉進到開發單位，要不然這樣一個人才，可能會在一段時間後，滿腔熱血就被消磨殆盡。
而軟體又不是一個可以完全被自動化測試的產品，總會有很多地方，需要用非常原始的人工方法，去做測試，甚至要當一個天真的使用者，去使用這個軟體，才會發現很多問題。軟體的品質對產品來說又是個非常重要的議題，這個無解的難題，相信還會一直困擾著我，揮之不去。
chap 25提到了身為一個軟體開發人員或是公司的生存法則，當展示使用者介面給非開發人員看時，如果畫面不好看，就算內部設計再好也都等於是白做的，因為User一看到這樣的介面就不想用了，怎麼會知道你的產品好或壞。但相反地，如果展示的時候，畫面很好看，他會認為你已經把所有功能都完成了，在這些畫面裡面填上程式碼是非常簡單的工作。
產品demo的時候一定要炫，就Steve Jobs最了這件事情，這樣才能吸引大家的目光。如果畫面還沒完成，就讓他這樣，不要一開始就全部做完，但每一個功能都有缺陷。由非技術人員啟動的專案，在提報資料的時候，必須要提供幾種美術設計讓他選，原因有兩個，第一要讓他們有參與的感覺，並做出決策，第二是不要讓他們深入到設計的細節，甚至更動軟體的內部邏輯，因為這樣的更動可能會變成大災難。
作者的軟體公司以販賣Windows軟體維生，在chap30這個國家的狗做些什麼工作？這一章裡面，他提到一件非常重要的事情，就是要吃自己的狗食，換句話說，就是要使用自己開發的
軟體。當公司裡面的人真正去使用軟體時，才會發現很多使用上設計不良的問題。自己生產的東西，如果連自己用起來都不順利，那麼怎麼能說服客戶花錢去買一個這樣的軟體！
開發人員必須也要是這個軟體的使用者，用了之後，才知道好不好用，才能針對軟體提出更好的設計。用了之後，如果用得很高興，也會對自己的工作更有認同感，做起事情才會更起勁。
在 chap36 Ben and Jerry 模式與 Amazon 模式，Joel 提到了兩種截然不同的商業模式，兩種都有可能會成功，也有可能會失敗，但他提醒大家，要認清自己的定位，而且要堅持下去從一而終，搖擺不定的作法只會虛耗資源。
在 chap 40 開放源碼的經濟學中，他提到為甚麼一些商業公司要支援開放源碼，甚至大力推銷這樣的軟體開發策略，不管如何，開發一個軟體需要耗費成本，一個能讓很多開發者注意甚至無嘗貢獻自己的資源的軟體專案是非常幸運的，多數的開放源碼產品背後都有個商業公司協助支撐整個專案的開發。
這樣的策略就像是一家讓客戶喝啤酒免費的餐廳一樣，客人會因為免費的啤酒，上門消費，因為喝酒而點很多菜，而餐廳就可以靠這些菜餚賺錢。因此，撇開開放源碼藉以推動軟體世界的良性循環來說，單就商業利益的角度來看，在開放源碼的同時，除非有著連帶的附加價值，要不然就沒有必要耗費自己的資源做這些事情。
作者 Joel 的公司是採用 MS 的技術，雖然在 Part4 裡面，對 MS .NET 有著深深地怨念，但似乎也只能摸摸鼻子，就這樣接受 MS 打破過去一直以來的往下相容的策略，而是採用全新的軟體架構。這似乎是一個無解的問題，因為往下相容，導致公司要一直為了舊的錯誤設計多寫很多程式，多做很多例外處理。但是身為作業系統的平台，當 MS 無法以嶄新功能吸引使用者付費升級的同時，只好大破大立地將舊的系統破壞掉，期待以新的架構，吸引使用者的目光，進而付費升級。
雖然 Joel 認為 MS 現在的 .NET 策略錯了，但他也設下伏筆，告訴讀者，因為 MS 本身的現金足夠，可以花好幾年的時間大破大立，就算策略錯誤，因為公司龐大，還是有可能會再將策略轉彎，換句話說，Joel 希望 MS 注意到他對 .NET 所下的註解，而重新檢視公司的發展策略。
《約耳談軟體(Joel on Software)》翻譯計畫
約耳趣談軟體：來自專案管理的現場實錄
約耳趣談軟體 讀後心得
[約耳趣談軟體] 心得筆記：如何決定是否要雇用某人？
2011/12/2
最後期限：專案管理101個成功法則 by 湯姆‧狄馬克
作者講了一個 PM 的故事，並巧妙地將管理的謬誤與方法融入到故事的情節中。主角湯普今斯雖然是一個中年失業的中階管理人員，但是他確實非常瞭解一些基本的專案管理工具，也知道人月神話，懂得什麼叫CMMI，因此這本書並不是一個初階的管理教科書，而是針對進入管理階層後，略懂管理的狀況下，卻又不知道為甚麼總是力不從心的管理者，讓我們跟著主角接受各種領域的專家提供的建議，學習最有效，能達成目標的最佳方法。
湯普今斯進入了一個軟體王國，帶了一個超大的軟體開發團隊，而且是要從無到有建立一個全新的軟體產品，老大給他的任務，就是要在時間期限內，完成三個產品。湯普今斯陸續都掌握了許多重要的資源，能幹的好幫手，但很明顯地除了時間緊迫之外，成本跟人力完全不虞匱乏。
更令人嫉妒的是，湯普今斯要做的產品的規格，就是直接複製已經成功的軟體產品，重新製作一份出來，在第十六章，他們才發現直接拿這些成功軟體的使用者手冊，來當作現在要開發的產品規格書，這個簡便的方法。他們真的很幸運，不需要跟使用者打交道，產品的規格又是自己決定的，也不會一直改來改去。但換句話說，也是作者沒有把使用者介入的這個部份，考慮在專案管理的範疇當中。
一開始他們決定要花很多時間先設計軟體的架構，分析整個系統，這一個階段也不需要太多人介入，專案的開始不需要一堆系統實作的人員，等到架構確定了，又突然發現A團隊的人員，可以直接拿來使用，又不需要domain訓練的時間，又是一件非常幸運的事情。
人員加班反而會造成生產力低落，這是眾所皆知的狀況，因為要很晚下班，所以早上會晚一點到公司，上班的時候，又會花很多時間做自己的事情，這些都是因為大家心裡面都知道，就算自己的工作做很快又很好，帶來的反而是更多的工作，又不能提早下班。因為這是一個團隊，怎麼能先離開，不幫助其他的夥伴呢？長時間的加班，會讓人完全沒有個人的空間，沒有自己的生活，這是多恐怖的一件事情。
開會是個非常沒效率的工作，但是卻又不得不利用開會來溝通與協調事情，有時候，開會時會發現只有兩個人在互相問答，其他人在發呆，這樣完全沒有效率的會議，是有必要減少。但要減少多少才算是合理的範圍呢？公司裡面如果沒有一起開會，就會造成部門之間的壁壘分明，這對跨部門溝通來說，反而會造成阻礙。所以作者對會議的建議很棒，告訴大家要有效率地開會，但又有些過於理想化了。
【好書分享】The Deadline — 最後期限：專案管理101個成功法則
最後期限：專案管理101個成功法則
【最後期限：專案管理101個成功法則】讀後感
湯普今斯進入了一個軟體王國，帶了一個超大的軟體開發團隊，而且是要從無到有建立一個全新的軟體產品，老大給他的任務，就是要在時間期限內，完成三個產品。湯普今斯陸續都掌握了許多重要的資源，能幹的好幫手，但很明顯地除了時間緊迫之外，成本跟人力完全不虞匱乏。
更令人嫉妒的是，湯普今斯要做的產品的規格，就是直接複製已經成功的軟體產品，重新製作一份出來，在第十六章，他們才發現直接拿這些成功軟體的使用者手冊，來當作現在要開發的產品規格書，這個簡便的方法。他們真的很幸運，不需要跟使用者打交道，產品的規格又是自己決定的，也不會一直改來改去。但換句話說，也是作者沒有把使用者介入的這個部份，考慮在專案管理的範疇當中。
一開始他們決定要花很多時間先設計軟體的架構，分析整個系統，這一個階段也不需要太多人介入，專案的開始不需要一堆系統實作的人員，等到架構確定了，又突然發現A團隊的人員，可以直接拿來使用，又不需要domain訓練的時間，又是一件非常幸運的事情。
人員加班反而會造成生產力低落，這是眾所皆知的狀況，因為要很晚下班，所以早上會晚一點到公司，上班的時候，又會花很多時間做自己的事情，這些都是因為大家心裡面都知道，就算自己的工作做很快又很好，帶來的反而是更多的工作，又不能提早下班。因為這是一個團隊，怎麼能先離開，不幫助其他的夥伴呢？長時間的加班，會讓人完全沒有個人的空間，沒有自己的生活，這是多恐怖的一件事情。
開會是個非常沒效率的工作，但是卻又不得不利用開會來溝通與協調事情，有時候，開會時會發現只有兩個人在互相問答，其他人在發呆，這樣完全沒有效率的會議，是有必要減少。但要減少多少才算是合理的範圍呢？公司裡面如果沒有一起開會，就會造成部門之間的壁壘分明，這對跨部門溝通來說，反而會造成阻礙。所以作者對會議的建議很棒，告訴大家要有效率地開會，但又有些過於理想化了。
【好書分享】The Deadline — 最後期限：專案管理101個成功法則
最後期限：專案管理101個成功法則
【最後期限：專案管理101個成功法則】讀後感
訂閱：
文章 (Atom)