書名：挖開兔子洞──深入解讀愛麗絲漫遊奇境
書名：愛麗絲鏡中棋緣──深入解讀愛麗絲走進鏡子裡
原著：路易斯‧卡洛爾(Lewis Carroll)
原插圖：約翰‧田尼爾(John Tenniel)
譯註：張華
出版社：遠流
這兩本書，一言以蔽之，就是愛麗絲漫遊奇境(Alice's Adventures in Wonderland)與愛麗絲走進鏡子裡(Through The Looking-Glass And What Alice Found There)的註釋版，以中英對照的方式呈現，並且加上非常詳實的注釋。
為什麼要看漫遊奇境與走進鏡子裡，簡單講，這兩本是經典，你可以享受書中幻化無方天馬行空的想像力，你可以研究書中的詩詞、雙關語、玩弄語文的技巧、邏輯道理與謬論，另外，因為是經典，很多其他作品常會引用借用這兩本長青不朽著作裡的梗；更有與其直接相關的作品，譬如電影魔境夢遊，為原著故事的延續，講述19歲的愛麗絲重返魔境後的經歷，如果不知道兩本書的內容就去看電影，雖然不能說一定會看不懂，但電影中的很多梗、笑點、典故，你就會錯過、甚至一頭霧水。
不知為何，我以前常常要求一部作品應該要"自成一套完整體系"，不要要求讀者事先知道太多背景與設定，不過有些電影譬如驚聲尖笑，該影片明顯地以「惡搞、戲弄」為宗旨，將90年代的電影全部拙劣地愚弄一番，所以，如果沒看過那些被模仿惡搞的電影情節，就會看不懂。現在我改變想法了，正如教你讀懂文學的27堂課裡面說的一個理論，這個世界只有一個故事，所有事物都是有關係的，我現在認為，應該要極盡所能，找出其中相似的點、象徵性的共通表象，加以聯想並觸類旁通，自己要"主動"地去閱讀，而不要只是被動地接受。就算想錯了也沒關係，就算作者其實原本沒有那個意思也沒關係，因為能夠在抽絲剝繭串連關係時享受其中，不是會讓閱讀更有趣嗎。
愛麗絲的故事，喜愛並研究的人不計其數，譯本多如牛毛；想當初我翻閱時，只能說完完全全看不懂，不過就是一些瘋言瘋語的童話故事罷了。我曾經看過一本科普書愛麗絲漫遊量子奇境，也是完全看不懂裡面的梗。而這兩本注釋本，就是要幫你了解其中的奧祕，書中有些背景知識，是維多利亞時代那時的一般常識，與現在不同；有些梗，是英文的語文笑點；有些故事情結，牽扯到原作者與愛麗絲之間的默契，光只看原文，是很難了解這些的，而這兩本注釋本，搜羅中外各家的註釋與研究成果，細細地展現給你，這不單單只是被動地閱讀一本書了，而是主動地去了解原作者的背景，查詢書中創作的源頭，譬如赤霞貓的原型在哪兒，變成跟原作者在玩遊戲，看看讀者能不能破解書中的隱密與機關。
英文翻譯（語言翻譯），是很難的，譬如原著裡，用了某一首外國知名童謠，配上新歌詞，置入改編的樂趣與笑點，那麼，你該怎麼翻譯呢？若直接翻譯歌詞，但讀者並不知道原曲啊；選一首讀者熟悉的歌曲，將翻譯後的歌詞放進去，這樣能譯的傳神嗎；Tweeddle Dun與Tweeddle Dee的譯法至少有十餘種，有把精神譯出來嗎？諸如種種，實在太多了，像這兩本書以中英對照的方式呈現，或許是最好的辦法了吧。
總而言之，愛麗絲是西方的重要經典，不可不知不可不讀，但光讀原文理解有限，就好好看看這兩本注釋書裡研究搜羅的詳實解說罷。
PS 小小抱怨一下排版，英文中文沒有頁頁對齊，註釋跟註釋號碼上標，也沒有一定在同一頁。我知道要做到很難，這兩本書的編排算很不錯了，所以我只是"小小"抱怨一下。
2011/11/22
2011/11/21
讀後想法：秘本三國志（陳舜臣）
書名：秘本三國志
作者：(日)陳舜臣
出版社：中華書局(香港)
作者為日本著名作家，1924年生於日本神戶，祖籍台灣。這部故事，以三國志、後漢書和資治通鑑等史料為藍本，佐以三國演義、華陽國志、典略、洛陽伽藍記與世說新語等文史著作為輔助材料，加入自己的構思創作的歷史小說。
本作品不尊劉，也不捧曹，以五斗米教的教母少容（張魯之母）、以及其養子陳潛為主角，從黃巾起義開始，直到孔明星落五丈原，小說裡，此兩者為檯面下的人物，但對於三國情勢與事件走向有重大影響。書裡以大致的手法概略寫出三國時期的情節演進，加強重點描寫各人物的性格，當然啦，礙於篇幅，不可能每個角色都得到充分的對待。
我本來以為這是部新作品，後來才發現早在30多年前就出版了，只不過最近才翻譯成中文罷了。如果你搜尋本書名，就會看到"日本人究竟懂不懂三國志"的字 樣，大體而言，我也都認同網路上寫的評論，日本人熟悉的是吉川英治筆下的三國，一般人熟悉的是羅貫中的柴堆三國，每個人心中都有一部屬於自己的三國故事， 所以，看到改編的地方，免不了要大肆批評一番。我對這本書的評價，平心而論，如果是在十幾年前讀到這本書，會認為是很不錯的好作品，但現在，已經看過各式各樣的三國改編作品，現在來看這部作品，就只能給出普通的好作品這種評價，這部小說寫的是很不錯的，但其中很多情節的安排，我就不太能接受了。如果從稍微嚴謹一點歷史研究的角度來看，這部作品有很多奇怪的歷史事件的看法與解釋（不過我要再次強調，這本書是30多年前的作品了），如果以輕鬆一點看小說的角度說來，這部作品可以算得上有趣的消遣讀物。
書裡有提到關於預言、匈奴單于、月氏、佛教、白馬寺、蔡琰、等等，都是我比較不熟悉的、覺得比較新鮮的，不錯，有長知識；至於我接下來講的，呃，可能會讓你覺得這是部爛作品，其實不是，我只是把我認為怪怪講不通的地方、我不能理解的地方列出來：
＊少容跟陳潛，這兩人對三國局勢發展似乎影響太多太大了吧，真有那麼神？影響黃巾起義、影響劉焉佔蜀、張魯據漢中等等，這兩人還跟曹操、劉備、孫權、諸葛亮都有交情，太厲害了吧。
＊五斗米教，影響力真有那麼大嗎？
＊少容說服三十萬青州軍，交給曹操使用，認定曹操有資格能統一霸業。
＊呂布喪命時，關羽奪走貂蟬，曹操卻誤會，反而奪走秦宜祿之妻。
＊劉備跟曹操有秘密協議，去袁紹那裏臥底，袁紹敗後又去劉表那裏臥底。這個我覺得太誇張了，劉備幫助曹操去臥底，有撈到什麼好處嗎？書中對於此事有鋪陳解釋，但我還是覺得很牽強。
＊因為顏良被劉備騙了，以為關羽會陣前倒戈，所以被關羽斬了。
＊七擒孟獲這齣戲碼，是孟獲跟孔明兩個好朋友事先套好招的。哇哩咧，有沒有這麼麻吉啊。
＊五丈原的對峙，是司馬懿與孔明私下說好雙方保持不進不退的態勢。書中的解釋我還是覺得很勉強。
＊荀彧自願假裝自己是反對曹操稱王的反對黨，藉以找出異議份子。
＊書中把曹丕描寫成是個非常冷酷的角色，敢廢漢自立，所以被曹操選為繼承人。曹丕居然讓曹植跟甄妃偷情，造成謠言，進而塑造出曹家長子被冷落的假象，藉以找出藏在暗處反曹的勢力。
總而言之，我覺得作者置入太多異想天開的陰謀論，讓人無法接受。
一些鮮為人知（我不知道）的情節：
＊孫吳因為人口外流，所以孫權派人去日本抓人當兵，也有可能是指台灣、琉球。
＊南匈奴為了進行漢化，搶奪宮女，包括蔡邕之女蔡琰，後來被曹操贖回，作胡笳十八拍。書中有詳細描寫。
＊三國演義中，陳宮因曹操殺呂伯奢而轉投呂布，在本書中，曹操因喪父之痛而屠城，違反陳宮的理念，另外，書中描寫陳宮夢想成為張良一樣的人物，而曹操自己就有智謀了，所以背叛投呂布、攻擊曹操。
另外我有個不爽的地方是，這些人都是前知一千年後知五百年的智者啊，隨隨便便就能看出將來是誰會勝誰會敗，哼，相命的說曹操是能臣奸雄也就罷了，你還能知道將來一定就是三強鼎立，誰必成大器誰會日暮西山，根本毫無根據嘛，說大話不負責。感覺就像是作者透過這些角色說話，可是作者是全知全能的上帝啊，不應該 隨便跳進書中亂說話啊。這就是我很不爽的地方，作者知道後段誰誰誰會崛起（我也知道啊），就在前段透過某人很漂亮地說出"誰誰誰將成龍飛天"，哇哩咧。
總而言之，以今日看來，可以把這部作品當做有趣的消遣讀物，至於裡面的歷史解釋觀點，我就敬謝不敏了。
延伸閱讀：
1. 小說，三國殤，李民發。如果我們把三國分成3個段落，從黃巾起義到孔明出山，再到孔明病逝五丈原，再到晉國滅吳，其時間分別是34年、27年、46年，而三國演義分別用了34回、71回、15回的篇幅，其中諸葛亮活躍的時期居然有71回的巨大篇幅，不能不說羅貫中是個孔明崇拜者，但也造成一個問題，讀到越後面，越覺得沒有趣味。作者李民發補續三國演義，寫出蜀殤、吳殤、魏殤，詳述後三國時期，補足這個缺憾。
2. 小說，反三國演義，周大荒。蜀漢統一天下，帥吧。
3. 漫畫，火鳳燎原，陳某。這部作品讓故事符合歷史史實，譬如董卓火燒洛陽、劉備失徐州等等，但情節內容與過程卻被翻天覆地徹頭徹尾地改編了，趙雲是司馬家的暗殺集團首領，呂布不僅有勇且有謀，貂蟬是宦官，士氣論、暗黑兵法，各種名言，譬如"殺一個高手總比殺一百個嘍囉來得方便"，等等等等，值得一看。
4. 漫畫，天地吞食，本宮宏志。龍王之女為保青春，每隔一段時間就會下凡擷取童精，並答應對方一個願望，曹操想當天下之王，孔明獲得洞悉森羅萬象的智慧，而劉備得到了"膽"，因為我非常喜愛這部漫畫改編的大型電玩，所以找出這部相當誇張的作品來看，不過畫到劉備封禪就停了，不知道在作者腦袋中，要怎麼安排接下來的情節啊？
5. 漫畫，龍狼傳，山原義人。剛開始似乎是想讓兩個穿越時空的學生走覽三國時期，但後來就變成天地志狼的武術之道了。
6. 漫畫，超三國志霸，武論尊原作、池上遼一作畫。劉備是日本人？趙雲是女人？老實說，我看不懂，所以就沒有繼續追了，如果只是找個大家熟悉（有市場能賣錢）的歷史朝代，然後異想天開地惡搞改編，嗯，我看不下去。
7. 漫畫，蒼天航路，李學仁編劇、王欣太作畫。沒看過，聽說是以曹操為主角。
8. 電視劇，三國，2010年，導演高希希、編劇朱蘇進。雖然網路罵聲不斷，雖然曹操在劇中時不時出現太現代太雷人的台詞，不過我覺得還不錯，對於劉備曹操之間關於平天下的論述，對於孫權周瑜魯肅之間的描寫，對於曹操曹丕司馬懿之間的描寫，我覺得都很棒，另外，張飛在古城審案很好笑、貂蟬很漂亮、戰爭場面也不錯，武將單挑也不錯。看到喜歡的歷史小說變成電視劇，總是有欣喜之情，編劇幾乎都遵從著小說三國演義的路子，加入一些讓人物更深刻的設定，但又不會打亂原著的精神，我認為很不錯。
9. 電視劇，三國演義，1994，導演王扶林等，編劇杜家福等。全套三國演義變成真人連續劇，連對白也都照抄小說，想當初，真是非常感動啊。
作者：(日)陳舜臣
出版社：中華書局(香港)
作者為日本著名作家，1924年生於日本神戶，祖籍台灣。這部故事，以三國志、後漢書和資治通鑑等史料為藍本，佐以三國演義、華陽國志、典略、洛陽伽藍記與世說新語等文史著作為輔助材料，加入自己的構思創作的歷史小說。
本作品不尊劉，也不捧曹，以五斗米教的教母少容（張魯之母）、以及其養子陳潛為主角，從黃巾起義開始，直到孔明星落五丈原，小說裡，此兩者為檯面下的人物，但對於三國情勢與事件走向有重大影響。書裡以大致的手法概略寫出三國時期的情節演進，加強重點描寫各人物的性格，當然啦，礙於篇幅，不可能每個角色都得到充分的對待。
我本來以為這是部新作品，後來才發現早在30多年前就出版了，只不過最近才翻譯成中文罷了。如果你搜尋本書名，就會看到"日本人究竟懂不懂三國志"的字 樣，大體而言，我也都認同網路上寫的評論，日本人熟悉的是吉川英治筆下的三國，一般人熟悉的是羅貫中的柴堆三國，每個人心中都有一部屬於自己的三國故事， 所以，看到改編的地方，免不了要大肆批評一番。我對這本書的評價，平心而論，如果是在十幾年前讀到這本書，會認為是很不錯的好作品，但現在，已經看過各式各樣的三國改編作品，現在來看這部作品，就只能給出普通的好作品這種評價，這部小說寫的是很不錯的，但其中很多情節的安排，我就不太能接受了。如果從稍微嚴謹一點歷史研究的角度來看，這部作品有很多奇怪的歷史事件的看法與解釋（不過我要再次強調，這本書是30多年前的作品了），如果以輕鬆一點看小說的角度說來，這部作品可以算得上有趣的消遣讀物。
書裡有提到關於預言、匈奴單于、月氏、佛教、白馬寺、蔡琰、等等，都是我比較不熟悉的、覺得比較新鮮的，不錯，有長知識；至於我接下來講的，呃，可能會讓你覺得這是部爛作品，其實不是，我只是把我認為怪怪講不通的地方、我不能理解的地方列出來：
＊少容跟陳潛，這兩人對三國局勢發展似乎影響太多太大了吧，真有那麼神？影響黃巾起義、影響劉焉佔蜀、張魯據漢中等等，這兩人還跟曹操、劉備、孫權、諸葛亮都有交情，太厲害了吧。
＊五斗米教，影響力真有那麼大嗎？
＊少容說服三十萬青州軍，交給曹操使用，認定曹操有資格能統一霸業。
＊呂布喪命時，關羽奪走貂蟬，曹操卻誤會，反而奪走秦宜祿之妻。
＊劉備跟曹操有秘密協議，去袁紹那裏臥底，袁紹敗後又去劉表那裏臥底。這個我覺得太誇張了，劉備幫助曹操去臥底，有撈到什麼好處嗎？書中對於此事有鋪陳解釋，但我還是覺得很牽強。
＊因為顏良被劉備騙了，以為關羽會陣前倒戈，所以被關羽斬了。
＊七擒孟獲這齣戲碼，是孟獲跟孔明兩個好朋友事先套好招的。哇哩咧，有沒有這麼麻吉啊。
＊五丈原的對峙，是司馬懿與孔明私下說好雙方保持不進不退的態勢。書中的解釋我還是覺得很勉強。
＊荀彧自願假裝自己是反對曹操稱王的反對黨，藉以找出異議份子。
＊書中把曹丕描寫成是個非常冷酷的角色，敢廢漢自立，所以被曹操選為繼承人。曹丕居然讓曹植跟甄妃偷情，造成謠言，進而塑造出曹家長子被冷落的假象，藉以找出藏在暗處反曹的勢力。
總而言之，我覺得作者置入太多異想天開的陰謀論，讓人無法接受。
一些鮮為人知（我不知道）的情節：
＊孫吳因為人口外流，所以孫權派人去日本抓人當兵，也有可能是指台灣、琉球。
＊南匈奴為了進行漢化，搶奪宮女，包括蔡邕之女蔡琰，後來被曹操贖回，作胡笳十八拍。書中有詳細描寫。
＊三國演義中，陳宮因曹操殺呂伯奢而轉投呂布，在本書中，曹操因喪父之痛而屠城，違反陳宮的理念，另外，書中描寫陳宮夢想成為張良一樣的人物，而曹操自己就有智謀了，所以背叛投呂布、攻擊曹操。
另外我有個不爽的地方是，這些人都是前知一千年後知五百年的智者啊，隨隨便便就能看出將來是誰會勝誰會敗，哼，相命的說曹操是能臣奸雄也就罷了，你還能知道將來一定就是三強鼎立，誰必成大器誰會日暮西山，根本毫無根據嘛，說大話不負責。感覺就像是作者透過這些角色說話，可是作者是全知全能的上帝啊，不應該 隨便跳進書中亂說話啊。這就是我很不爽的地方，作者知道後段誰誰誰會崛起（我也知道啊），就在前段透過某人很漂亮地說出"誰誰誰將成龍飛天"，哇哩咧。
總而言之，以今日看來，可以把這部作品當做有趣的消遣讀物，至於裡面的歷史解釋觀點，我就敬謝不敏了。
延伸閱讀：
1. 小說，三國殤，李民發。如果我們把三國分成3個段落，從黃巾起義到孔明出山，再到孔明病逝五丈原，再到晉國滅吳，其時間分別是34年、27年、46年，而三國演義分別用了34回、71回、15回的篇幅，其中諸葛亮活躍的時期居然有71回的巨大篇幅，不能不說羅貫中是個孔明崇拜者，但也造成一個問題，讀到越後面，越覺得沒有趣味。作者李民發補續三國演義，寫出蜀殤、吳殤、魏殤，詳述後三國時期，補足這個缺憾。
2. 小說，反三國演義，周大荒。蜀漢統一天下，帥吧。
3. 漫畫，火鳳燎原，陳某。這部作品讓故事符合歷史史實，譬如董卓火燒洛陽、劉備失徐州等等，但情節內容與過程卻被翻天覆地徹頭徹尾地改編了，趙雲是司馬家的暗殺集團首領，呂布不僅有勇且有謀，貂蟬是宦官，士氣論、暗黑兵法，各種名言，譬如"殺一個高手總比殺一百個嘍囉來得方便"，等等等等，值得一看。
4. 漫畫，天地吞食，本宮宏志。龍王之女為保青春，每隔一段時間就會下凡擷取童精，並答應對方一個願望，曹操想當天下之王，孔明獲得洞悉森羅萬象的智慧，而劉備得到了"膽"，因為我非常喜愛這部漫畫改編的大型電玩，所以找出這部相當誇張的作品來看，不過畫到劉備封禪就停了，不知道在作者腦袋中，要怎麼安排接下來的情節啊？
5. 漫畫，龍狼傳，山原義人。剛開始似乎是想讓兩個穿越時空的學生走覽三國時期，但後來就變成天地志狼的武術之道了。
6. 漫畫，超三國志霸，武論尊原作、池上遼一作畫。劉備是日本人？趙雲是女人？老實說，我看不懂，所以就沒有繼續追了，如果只是找個大家熟悉（有市場能賣錢）的歷史朝代，然後異想天開地惡搞改編，嗯，我看不下去。
7. 漫畫，蒼天航路，李學仁編劇、王欣太作畫。沒看過，聽說是以曹操為主角。
8. 電視劇，三國，2010年，導演高希希、編劇朱蘇進。雖然網路罵聲不斷，雖然曹操在劇中時不時出現太現代太雷人的台詞，不過我覺得還不錯，對於劉備曹操之間關於平天下的論述，對於孫權周瑜魯肅之間的描寫，對於曹操曹丕司馬懿之間的描寫，我覺得都很棒，另外，張飛在古城審案很好笑、貂蟬很漂亮、戰爭場面也不錯，武將單挑也不錯。看到喜歡的歷史小說變成電視劇，總是有欣喜之情，編劇幾乎都遵從著小說三國演義的路子，加入一些讓人物更深刻的設定，但又不會打亂原著的精神，我認為很不錯。
9. 電視劇，三國演義，1994，導演王扶林等，編劇杜家福等。全套三國演義變成真人連續劇，連對白也都照抄小說，想當初，真是非常感動啊。
2011/11/09
讀後感想：教你讀懂文學的27堂課(How to Read Literature Like a Professor) by Thomas C. Foster
書名：教你讀懂文學的27堂課(How to Read Literature Like a Professor)
作者：Thomas C. Foster
譯者：張思婷
出版社：木馬文化
不知曾幾何時，我越來越沒有耐心，電影、書籍、文章、部落格、動畫、漫畫、文件、等等，如果一開始覺得無趣就會隨手丟開，如果看完後抓不到內涵就會直言爛斃了，失去細細品嚐的閑情逸致，失去推敲琢磨後豁然開朗的那種欣喜，就某方面而言，在這個資訊爆炸的時代，快速過濾資料並切中核心擷取重點是不可或缺的能力，為了避免成為巨大訊息怪獸的奴隸，不得不功利、現實，有用才花時間、沒用即丟，就另一方面而言，我欣賞、解析、品味的能力長久以來都沒有提昇，很多需要好好閱讀的作品，打從一開始便被我揚棄了，許多需要細細思索的作品，看一點便被我束之高閣，這實在是個可悲可憐的現象，我可悲，作品可憐。
這本書的主題是文學，大體上指的是小說、長篇文章、短文、詩歌、等等，教導你如何看懂讀懂，雖然書中所說也可應用到其他領域，譬如戲劇、電影、電視廣告，不過書中的例子大都是文學出版品，對了，這本是講西方文學的，作者的專長是英國、愛爾蘭、美國文學。
文學作品並不是單獨存在的，互相引用、互相模仿抄襲、諷刺，有些流傳已久的典故、象徵、形象、情節，會一再地被使用、再創作。哈利波特第一集，哈利三人小隊前往阻止佛地魔竊取魔法之石的第一道關卡，是隻長著三顆頭的大狗，若不知典故，這就是道關卡罷了，知道演奏音樂能使其沈睡這個訣竅後就能過關，若是知道地獄守門犬這個典故，便感受到作者營造出冥府、地獄的用心，哈利小隊接下來將走進危險地帶，邁向未知的冒險。老人與海的最後，從海港回家的路上（耶穌前往刑場），一路上都把船桅扛在肩上（背著十字架），到家後老人躺在床上雙臂攤開露出皮開肉綻的手掌（釘在十字架上），隔天，對村民來說，老人就如同死後復生一般（復活），看到那巨大的魚骨，原本懷疑他的人又充滿信心，老漁夫為這個墮落的世界贖罪，替這個沈淪的社會帶來希望，哇，如果不知道聖經、耶穌，怎麼會聯想到這些呢，一個不知道聖經典故的人讀了老人與海，當然他會有所獲得、感動，但顯然地，他無法看出耶穌受難記這個典故。這是讀經典的必要之處，書中強調：聖經、莎士比亞、童話故事、神話，這些是必須的。當然，有些人聽到說要讀經典，就覺得暮氣沉沉，能讀當然最好，不想要的話也可以多多閱讀其他好作品，重點是，能夠在作品與作品之間，建立起連結，觸類旁通，找出相似處；意思是說，教授看到某情節可能會聯想到亞瑟王或唐吉柯德，我不認識那些傢伙啊，但我還是可以聯想，我看到某情節、某人物，可能會聯想到悟空與達爾、令狐沖、曹操啊；前人創作會引用聖經、莎士比亞、希臘神話，但我們可以引用海賊王、周星馳、還有"殺很大"啊，只不過，採用流行一時的話語也就只能在一時一地引起共識而已，那就是另外一個問題了。
我常常用自己的觀點來閱讀、用現代的視角來看作品，太執著要求虛擬世界應該要符合真實世界，這是很要不得的，不僅沒有樂趣，也妨礙對於創作的理解。不同文化、不同時空、不同背景，各有其價值觀、理想、流行指標、束縛與共識，嘗試了解多元的觀點，進而欣賞作者創造出來的世界，比較對方與自己的不同，感受其中的相同處與不同處，這樣才算盡到一個讀者的本分。
小說的一頁，你只需要花3分鐘，但卻可能耗去作者3天的時間。作品裡，每個安排都是精心設計過的（也有可能不是），為什麼在此安排飯局，雨水、河流有何意義，暴力就只是暴力嗎，為什麼要賜死這個角色，為什麼死於心臟病，翅膀與飛行的形象為何，等等等等，場景的描述，細節的刻劃，在在都有其意義，多花點心思聯想，多多觸類旁通舉一反三，在心理建立起一張網，將所有作品連結起來，作品不是從天下掉下來的，是人創作的，創作給你我看的，試著更深入了解其中的象徵與譬喻，才能挖掘出更大的樂趣。
作者：Thomas C. Foster
譯者：張思婷
出版社：木馬文化
不知曾幾何時，我越來越沒有耐心，電影、書籍、文章、部落格、動畫、漫畫、文件、等等，如果一開始覺得無趣就會隨手丟開，如果看完後抓不到內涵就會直言爛斃了，失去細細品嚐的閑情逸致，失去推敲琢磨後豁然開朗的那種欣喜，就某方面而言，在這個資訊爆炸的時代，快速過濾資料並切中核心擷取重點是不可或缺的能力，為了避免成為巨大訊息怪獸的奴隸，不得不功利、現實，有用才花時間、沒用即丟，就另一方面而言，我欣賞、解析、品味的能力長久以來都沒有提昇，很多需要好好閱讀的作品，打從一開始便被我揚棄了，許多需要細細思索的作品，看一點便被我束之高閣，這實在是個可悲可憐的現象，我可悲，作品可憐。
這本書的主題是文學，大體上指的是小說、長篇文章、短文、詩歌、等等，教導你如何看懂讀懂，雖然書中所說也可應用到其他領域，譬如戲劇、電影、電視廣告，不過書中的例子大都是文學出版品，對了，這本是講西方文學的，作者的專長是英國、愛爾蘭、美國文學。
文學作品並不是單獨存在的，互相引用、互相模仿抄襲、諷刺，有些流傳已久的典故、象徵、形象、情節，會一再地被使用、再創作。哈利波特第一集，哈利三人小隊前往阻止佛地魔竊取魔法之石的第一道關卡，是隻長著三顆頭的大狗，若不知典故，這就是道關卡罷了，知道演奏音樂能使其沈睡這個訣竅後就能過關，若是知道地獄守門犬這個典故，便感受到作者營造出冥府、地獄的用心，哈利小隊接下來將走進危險地帶，邁向未知的冒險。老人與海的最後，從海港回家的路上（耶穌前往刑場），一路上都把船桅扛在肩上（背著十字架），到家後老人躺在床上雙臂攤開露出皮開肉綻的手掌（釘在十字架上），隔天，對村民來說，老人就如同死後復生一般（復活），看到那巨大的魚骨，原本懷疑他的人又充滿信心，老漁夫為這個墮落的世界贖罪，替這個沈淪的社會帶來希望，哇，如果不知道聖經、耶穌，怎麼會聯想到這些呢，一個不知道聖經典故的人讀了老人與海，當然他會有所獲得、感動，但顯然地，他無法看出耶穌受難記這個典故。這是讀經典的必要之處，書中強調：聖經、莎士比亞、童話故事、神話，這些是必須的。當然，有些人聽到說要讀經典，就覺得暮氣沉沉，能讀當然最好，不想要的話也可以多多閱讀其他好作品，重點是，能夠在作品與作品之間，建立起連結，觸類旁通，找出相似處；意思是說，教授看到某情節可能會聯想到亞瑟王或唐吉柯德，我不認識那些傢伙啊，但我還是可以聯想，我看到某情節、某人物，可能會聯想到悟空與達爾、令狐沖、曹操啊；前人創作會引用聖經、莎士比亞、希臘神話，但我們可以引用海賊王、周星馳、還有"殺很大"啊，只不過，採用流行一時的話語也就只能在一時一地引起共識而已，那就是另外一個問題了。
我常常用自己的觀點來閱讀、用現代的視角來看作品，太執著要求虛擬世界應該要符合真實世界，這是很要不得的，不僅沒有樂趣，也妨礙對於創作的理解。不同文化、不同時空、不同背景，各有其價值觀、理想、流行指標、束縛與共識，嘗試了解多元的觀點，進而欣賞作者創造出來的世界，比較對方與自己的不同，感受其中的相同處與不同處，這樣才算盡到一個讀者的本分。
小說的一頁，你只需要花3分鐘，但卻可能耗去作者3天的時間。作品裡，每個安排都是精心設計過的（也有可能不是），為什麼在此安排飯局，雨水、河流有何意義，暴力就只是暴力嗎，為什麼要賜死這個角色，為什麼死於心臟病，翅膀與飛行的形象為何，等等等等，場景的描述，細節的刻劃，在在都有其意義，多花點心思聯想，多多觸類旁通舉一反三，在心理建立起一張網，將所有作品連結起來，作品不是從天下掉下來的，是人創作的，創作給你我看的，試著更深入了解其中的象徵與譬喻，才能挖掘出更大的樂趣。
2011/11/08
讀後推薦：了解「人」，你才知道怎麼設計！(100 Things Every Designer Needs To Know About People) by Susan M. Weinschenk
書名：了解「人」，你才知道怎麼設計！(100 Things Every Designer Needs To Know About People)
作者：Susan M. Weinschenk
譯者：謝靜玫
出版社：旗標
很久以前，當我需要報告在做投影片時，我只會使用預設的、黑白的、醜醜的樣式，還自以為很酷，自以為像我這種沒有美感的人，不需要搞"設計"這回事，現在我知道錯了。之前看了給非設計人員閱讀的設計書，了解雖然不是人人都可以成為藝術大師、設計鬼才，但只要花一點點時間學習基本的設計原則，就能讓你的投影片、海報、網頁版面、名片、傳單、各式各樣的作品，從不及格提升到80分的程度，而這本書，了解「人」，你才知道怎麼設計！，裡面提出的要點，都是以科學實驗為基礎，對照前人累積下來的經驗，關於設計不可不知的100條規則。
譬如流行的社群網站，有些人擁有幾百個甚至上千個朋友，相當驚人，但是，其中到底有多少是有聯絡、有互動的的呢？一個人最多能夠跟多少人維持緊密聯繫呢？如果說通電話、見面吃飯是種"強"連結，那麼email與社群網站這種"弱"連結是不是會越來越重要呢？寫程式的往往只註記三個數字，0、1、無限大，如果某軟體有某項"20"個的限制，寫程式的一看就會感到不妥，為什麼是20、為什麼不是40，為什麼要限制20個，然後就會著手修改。但是實際上，譬如說"最近開啟的檔案"列表，從來就沒有人需要100個或200個，大概就是10或20個，以20個當做限制來設計、來撰寫程式，跟以沒有限制為前提來進行，這兩者可是天差地遠。
人的視覺是最重要的感知器官，所以，人類是如何看、如何閱讀，有必要研究一番，以致於如何處理看到的東西、如何知道該把注意力放在哪部分、如何思考，在在都影響了你該怎麼設計產品。假若你知道9%的男性與0.5%的女性是色盲，會不會影響你畫地圖時該採用哪些顏色標示；假若你知道人們瀏覽螢幕時，會根據過去經驗與期望，以閱讀越少"字"越好為前提，你還會在網站上放上一堆有跟沒有差不多的廢話嗎；你在設計時，腦袋裡想的那一套，跟使用者實際操作時的心智模式，不知道其中的差異就不能設計出方便易用的產品了。
書中分為10個類別：人們如何看、人們如何閱讀、人們如何記憶、人們如何思考、人們如何集中注意力、人們的動機來源、人類是社群動物、人們如何感覺、犯錯乃人之常情、人們如何做決策。以各種學問與科學實驗為基礎，包括認知心理學、腦神經學、文化差異、神經與神經元、組織行為、視覺理論、等等，小小一本卻含有豐富的內容，值得一看，每一篇最後都以短短數語重點整理，非常實用。
你的設計是自我感覺良好呢？還是因為你真正了解「人」呢？
作者：Susan M. Weinschenk
譯者：謝靜玫
出版社：旗標
很久以前，當我需要報告在做投影片時，我只會使用預設的、黑白的、醜醜的樣式，還自以為很酷，自以為像我這種沒有美感的人，不需要搞"設計"這回事，現在我知道錯了。之前看了給非設計人員閱讀的設計書，了解雖然不是人人都可以成為藝術大師、設計鬼才，但只要花一點點時間學習基本的設計原則，就能讓你的投影片、海報、網頁版面、名片、傳單、各式各樣的作品，從不及格提升到80分的程度，而這本書，了解「人」，你才知道怎麼設計！，裡面提出的要點，都是以科學實驗為基礎，對照前人累積下來的經驗，關於設計不可不知的100條規則。
譬如流行的社群網站，有些人擁有幾百個甚至上千個朋友，相當驚人，但是，其中到底有多少是有聯絡、有互動的的呢？一個人最多能夠跟多少人維持緊密聯繫呢？如果說通電話、見面吃飯是種"強"連結，那麼email與社群網站這種"弱"連結是不是會越來越重要呢？寫程式的往往只註記三個數字，0、1、無限大，如果某軟體有某項"20"個的限制，寫程式的一看就會感到不妥，為什麼是20、為什麼不是40，為什麼要限制20個，然後就會著手修改。但是實際上，譬如說"最近開啟的檔案"列表，從來就沒有人需要100個或200個，大概就是10或20個，以20個當做限制來設計、來撰寫程式，跟以沒有限制為前提來進行，這兩者可是天差地遠。
人的視覺是最重要的感知器官，所以，人類是如何看、如何閱讀，有必要研究一番，以致於如何處理看到的東西、如何知道該把注意力放在哪部分、如何思考，在在都影響了你該怎麼設計產品。假若你知道9%的男性與0.5%的女性是色盲，會不會影響你畫地圖時該採用哪些顏色標示；假若你知道人們瀏覽螢幕時，會根據過去經驗與期望，以閱讀越少"字"越好為前提，你還會在網站上放上一堆有跟沒有差不多的廢話嗎；你在設計時，腦袋裡想的那一套，跟使用者實際操作時的心智模式，不知道其中的差異就不能設計出方便易用的產品了。
書中分為10個類別：人們如何看、人們如何閱讀、人們如何記憶、人們如何思考、人們如何集中注意力、人們的動機來源、人類是社群動物、人們如何感覺、犯錯乃人之常情、人們如何做決策。以各種學問與科學實驗為基礎，包括認知心理學、腦神經學、文化差異、神經與神經元、組織行為、視覺理論、等等，小小一本卻含有豐富的內容，值得一看，每一篇最後都以短短數語重點整理，非常實用。
你的設計是自我感覺良好呢？還是因為你真正了解「人」呢？
2011/10/18
翻譯：話說平台（Stevey's Google Platforms Rant）by Steve Yegge
文章：Stevey's Google Platforms Rant 話說平台
日期：2011.10.13
作者：Steve Yegge
作者的部落格（2006至今）：Stevey's Blog Rants
作者舊的文章（2004與2005）：Stevey's Drunken Blog Rants
作者簡介：
目前任職於Google，之前任職於Geoworks與Amazon。程式語言生涯中有過兩次非常關鍵性的轉換，一次是組合語言，一次是Java 跟Perl，因為發現解決語言本身設計帶來的問題所花的時間，竟然比真正用在開發軟體系統的時間還多。其文章以長度聞名，長到應該稱為論文而非部落格，兼帶詼諧筆風，發表頻率大約一個月一到兩篇，作者總是說這些是在凌晨三罐啤酒下肚後的誇誇其談，但每一篇都是經過長時間醞釀，內容充實有見地的傑作。
獨立以Java/JPyton開發多人線上遊戲Wyvern，可讓玩家自行創建擴充遊戲內容。其工作團隊將Rails移植到Rhino上，Rhino是運作於JVM平台上的JavaScript引擎，Rails(Ruby on Rails)為一套受到廣泛喜愛使用的網站開發模組；為Emacs撰寫完整的JavaScript環境，期望在Emacs上可以有一套 JavaScript IDE，以及將來可用JavaScript而非elisp來開發Emacs extensions。
注意：作者已經刪除原文，因為原本應在公司內部流傳跟同事間互相討論的文章內容，卻意外地發佈到公開網路上。希望你能夠站在不同立場來閱讀，而不是斷章取義只看自己想看的部份。
這邊有原文的備份以及留言。
Steve的Google+頁面。
話說平台（Stevey's Google Platforms Rant）
我曾在Amazon工作了六年半，現在算一算，我在Google的日子也差不多那麼長了。關於這兩家公司，有個衝擊性的差異──在我的腦袋裡這樣的印象幾乎每天都在加深中──那就是，Amazon每件事都做錯了、而Google每件事都做對了。當然啦，這是很籠統的概括評論，但卻出乎意料的是個精確說法，很瘋狂吧。你可以舉出大概一百甚至兩百種不同的項目來比較兩家公司，而Google每一項都能勝出，除了其中3項以外。如果我記的沒錯，我確實曾用試算表列出來加以比較一番，不過法律部門不會允許我秀給任何人看，即使人事招募部門會愛的不得了。
讓我給你個例子稍微體會一下：Amazon的人事雇用流程存在著根本上的缺陷，每個團隊獨自為自己招募新人，以至於，各團隊之間的雇用標準，有著天差地別的不一致性，即使他們通過各種努力來撫平差異，仍然相去甚遠，而且，他們的操作方法一團糟，沒有真正的SREs，工程師們什麼事都要做、幾乎沒時間撰寫程式碼──當然啦，各部門情況不同，取決於你的運氣。他們不碰慈善、不幫助需要幫助的人、不鳥社群集體貢獻、或是任何類似的活動，相關話題從來沒有浮現過，或許只有在閒談說笑時才會提到，他們的辦公室是個滿佈灰塵的農場隔間，連一分錢都不會花在裝潢或是公共場地與會議室，他們的薪資與紅利遜斃了，最近因為來自Google與Facebook的競爭才好多了，不過，我們有津貼或額外獎金，他們都沒有──他們只是想要讓薪資帳面上的數字好看一點，就這樣子而已。他們的程式碼就像是災難過後滿目瘡痍，沒有工程標準或撰碼規則，除了團隊各自選擇性地、局部性地自己搞自己的以外。
話說回來，公道一點，他們的確有套不錯的程式庫版本控管系統，這是我們真的應該要盡力趕上的地方，以及發佈/訂閱系統，我們也沒有相對應的東西，不過，就大體而言，他們有的不過是一堆低劣的工具，藉以將狀態機裡的資訊，讀取或寫入到關聯式資料庫中罷了。我們不該模傚或借鏡，就算可以免費取得也要棄之不理。
我認為，他們的發佈/訂閱系統、程式庫版本控管系統，是Amazon比Google強的那3個項目之中的2點。
我猜你或許可以為他們辯護，"早早推出服務並不斷反覆地改進"，他們對於此作法有著近乎偏執的狂熱，你可以說他們這點做的很好，不過，關於這點，我們也可以從另一角度來爭辯，他們把"早早推出"這點，擴及應用到所有其他事項上，譬如說軟體工程守則與戒律跟其他一票的事項與流程，而這些都是會造成長期性的影響，所以說，即使這點讓他們在市場上有了某種程度的競爭優勢，但也造成其他許許多多的問題，總結而言，這不能算得上是個漂亮灌籃得分的項目。
但～是～，他們有一件事做的非常非常好，好到把其他政略上、理念上、技術上的缺失通通彌補回來。
Jeff Bezos是位惡名昭彰的微控經理人，他對Amazon零售網站頁面上的每一點像素都要微控管理，他雇用Larry Tesler，Apple的領頭科學家，可說是全世界中最有名且最受尊敬的人機介面專家，然後，Jeff不理會Larry提出的每一項建言，整整三年，直到Larry最後──明智地──終於離開了公司。Larry應會實踐大型的可用性測試，然後憑著研究報告、不存著一絲絲疑惑地證明出，根本就沒有人能夠搞懂、使用那該死的網站，可是，對於頁面上幾百萬個都包含著意義的像素，Bezos就是不能放手，就好像是對待寶貝兒子般呵護著，所以結果是，像素通通還留著，而Larry走人。
喔，對了，微控管理不是第三項Amazon做的比我們好的地方，我的意思是，沒錯，他們微控管理做的很好，但我可不會把這項列在強項或優勢清單上，以上所言只是為了下文鋪陳，幫助你了解背景。我們現在討論的人，是個在很多公開場合說過，而且是很認真地說，人們想進Amazon工作應該付他錢才對呀，當有人跟他意見不同時，他會遞出黃色便利貼有著Jeff的名字在上頭，提醒人們"誰才是公司的老大"，這傢伙可說是一個較守規矩的，嗯，Steve Jobs，我想應該可以這麼說，除了他沒有流行品味或是關於設計的理解力以外；可別誤解我了，Bezos可是超級聰明的仁兄，只不過呢，他的所作所為，讓那些一般般的控制狂看起來只不過像是抽大麻的嬉皮罷了。
有一天，Jeff Bezos發布一份命令書，當然啦，他總是不斷地在下命令，而如螞蟻般忙碌爬行的員工就會像被橡皮槌敲擊般地受到震撼，不過，有一次的情況是──大概是2002年吧，我想，誤差1年內──他發布一份命令書，發布範圍非常廣，內容龐大且沈重，讓你的眼珠子都快掉下來了，跟這份命令書相比，其他的就好像突然收到來自同儕的獎勵。
這份大大的命令書，其內涵大致如下幾點：
1) 從今以後，每個團隊要以透過服務介面(service interfaces)的存取方式，將資料與功能開放出來，。
2) 團隊間的溝通，都要透過這些介面。
3) 行程間的溝通(interprocess communication)，其他形式一概不允許：不能直接鏈結、不能直接讀取其他團隊的資料、不能使用共享記憶體模式、不能走後門、等等，唯一的溝通管道就是在網路之上的服務介面呼叫。
4) 任何技術皆可使用，HTTP、Corba、發佈/訂閱系統、客製的網路協定、等等，都可以，Bezos不管這些。
5) 所有的服務介面，毫無例外，都必須從骨子裡設計好，能夠對外界開放，也就是說，團隊必須做好規劃與設計，能夠把介面開放給外界的開發人緣使用，沒有例外。
6) 不做的人會被炒魷魚。
7) 謝謝，祝你有個愉快的一天！
哈哈！你們這群150位前Amazon員工，一眼就看出第7點是我加上的，純為搏君一笑，因為Bezos才不會去關心你今天過的好不好咧。
不過第6點就是認真的了，所以人們紛紛埋頭苦幹，Bezos指派了幾位上級牛頭犬來監督並確保進度，由超高級跟熊一樣大的牛頭犬Rick Dalzell領軍，Rick是前陸軍突擊隊員、西點軍校畢業生、前拳擊手、前Wal*Mart的首席虐刑官 斜線 首席技術長，而且也是個高大、和藹、令人敬畏的男人，經常使用"硬化介面(hardened interface)"字眼的男人，Rick本身就是個會走路會說話的硬化介面，所以不消多說，每個人都做出重大的進展並確保讓Rick知悉一切。
在接下來的幾年內，Amazon的內部轉變成服務導向架構(service-oriented architecture)，在這蛻變的過程中，他們學到了一拖拉庫的知識，在當時，是有著關於SOA的文件，但跟Amazon那種超大規模比起來，那些技巧就跟告訴印第安那瓊斯過馬路前要先看看兩旁有無來車一樣沒用，Amazon的研發團隊在這過程中學到了不少、發現了不少，其中的極少極小的抽樣範例如下：
- pager escalation變得異常困難，因為ticket可能會送過來送過去，過程中會超過20個服務呼叫，然後才能找到真正的擁有者，如果每一個呼叫都花去團隊的15分鐘的反應時間，那在找到真正的團隊之前幾小時就過去了，除非，你建構出很多很多的scaffolding、metrics、reporting。
- 你的同儕團隊，每一個，突然間都變成潛在性的DOS攻擊者，你沒辦法有進展，直到在每一個服務裡放上配額限制(quota)與節流閥(throttling)的機制。
- 監控(monitoring)與品質控管(QA)是同一回事。你過去不會這麼想，直到試著進行大規模的SOA才會有此體悟。但是，等到你的服務說"喔沒錯，我很好"的時候，到那時的情況可能是，伺服器裡唯一正常運作的功能就只是那一小塊懂得用愉快機器人的聲音說"我很好，收到了，收到了，停止通話"的部份而已，為了要確認整個服務是否真正運作無虞，你必須對每一個部分都發出呼叫要求，同樣的情況會遞迴式地出現，直到你的監控系統能夠全面性地對整個服務與資料做出各種面相的檢查，到那時，就跟自動化QA沒什麼兩樣了，所以這兩者皆位於同一連續帶上。
- 如果你有上百個服務，而且你的程式只能經由這些服務來跟其他團隊的程式做溝通，那麼，沒有一套服務探索機制(service-discovery mechanism)的話，你就不能找到想要的服務，而且在那之前，你得先有一套服務註冊機制(service registration mechanism)，而這本身也是一項服務，所以，Amazon有一套全體適用的服務註冊機制，以反射可程式化(reflectively, programmatically)的方式找出服務，得知API為何、目前狀態是否可用、在哪裡。
- 跟他人程式有關的除錯，這問題變得更難了，基本上是不可能的，直到有一套全面性的標準方式，能夠在可除錯的沙盒環境內執行服務。
上面這些只是少數幾個例子，Amazon在蛻變得過程中，逐漸發現、學習了數十個、甚至數百個像這樣子的知識，關於把服務開放出去，會有幾個想都想不到的冷僻知識，不過不會像你想的那麼多，將功能重新加以組織劃分成服務後，團隊學會了不該信任彼此，就如同他們也不該相信外部的開發人員一樣。
當我在2005年中離開Amazon加入Google時，這轉變過程還處於進行式，但已經相當先進了，從Bezos頒佈法令的時間點到我離開之時，Amazon已經從文化心態上轉變成一家凡事以服務架構為優先考量的公司，到如今，已經成為他們進行所有設計時的基本原則，即使是那些僅在內部絕不會被外部世界使用的功能。
現在，他們不是怕被解雇才朝這個方向進行，我是說，他們仍然怕被炒魷魚，這點佔了在那兒生存的一大部分，在可怕海賊王Bezos的底下工作。不過，他們朝"服務"的方向前進，因為他們已經相信這就是正確的方向，關於SOA這種作法，不用說當然有優點也有缺點，某些缺點還很大，但是整體而言，這是正確的，因為，以SOA來進行設計，會產生出平台(platform)。
沒錯，這就是Bezos他的法令想要達成的目標，他以前（現在也是）對各團隊過的好不好一點都不在乎，不關心他們使用的技術為何，事實上也不去管他們怎麼進行他們的工作，除非他們有搞砸的跡象，但是，Bezos很早很早以前就領悟到，在絕大部分的Amazon居民都不知道以前，Amazon必須成為一個平台。
你應該不會想到線上賣書的網站需要成為一個有擴充性、可程式化的平台吧，你會嗎？
嗯，Bezos領悟到的第一件大事是，為了販賣銷售書籍與各種商品所打造出來的架構，可以轉變成為用途可再定義的絕佳運算平台，所以，現在他們有了Amazon Elastic Compute Cloud(亞馬遜彈性運算雲端)、Amazon Elastic MapReduce、亞馬遜關聯式資料庫服務(Amazon Relational Database Service)，以及其他可在aws.amazon.com查得到的一狗票服務，這些服務是某些相當成功的公司的後端架構，我喜歡舉的例子之一是reddit。
另一個大領悟是，他知道，他們不可能永遠都打造出對的東西，我認為，當Larry Tesler說他媽媽完全搞不懂怎麼使用那個見鬼的網站時，Bezos的某條心弦被撥動了，也不清楚說的到底是誰家媽媽，但無關緊要，因為沒有人的媽媽能夠使用那個天殺的網站，事實上，我自己都覺得Amazon網站的介面令人膽寒、卻步，那時我已經在那裡工作超過五年了，我後來終於學會，如何控制眼睛的焦點、關注在那接近頁面中間的幾百萬個像素。
我不是很確定Bezos是如何體悟到這點的──洞察到他不可能打造出一套適用於所有人的產品，不過這不重要，重要的是他領悟了，其實，這玩意有個正式的名稱，叫做可存取性(accessibility)，這是運算世界中最重要的事情。
最 重 要 的 事 情。
如果你在心理嘀咕著，"啥？你是說，盲人聾人那種可存取性嗎？"，你不是唯一一個這麼想的人，我已經知道有很多很多像你這樣的人：上述那玩意對你們來說沒有可存取性，所以這觀念還沒能進入到你的腦袋裡，不了解也不是你的錯，就好像有人眼盲、耳聾、行動不便、或有其他殘疾也不是他們的錯一樣，當軟體──或可稱為概念體──不管是什麼理由，如果不能被某人存取、使用，那麼，就是軟體的錯、或是那概念的傳遞出錯了，這就是失敗的可存取性。
就如同生命中任何重要的大事，可存取性有個邪惡的雙胞胎哥哥，在幼年期享有父母的偏愛溺愛，已經成長為同等強大的復仇邪神第一名（是的，對可存取性來說，復仇邪神有好幾個），其名為安全性(security)，但是，乖乖隆個咚，這兩個從來沒被公平對待過。
不過，我主張可存取性比安全性來的重要多了，因為，可存取性若為零，你根本沒有產品，而若安全性為零，你仍然能夠得到在相當程度上算是成功的產品，譬如說Playstation Network。
所以說，對了，假使你還沒注意到，我其實可以寫出一整本書來討論這個主題，厚厚一本，填滿了那家我曾工作過的公司裡關於螞蟻與橡皮槌的有趣軼事，但那樣一來，我就永遠不可能發表這篇短短的夸夸其談了，而你也就無法讀到，除非我現在開始收尾做總結。
Google做的不太好的最後一點是平台，我們不了解平台，我們沒抓到它的意涵，你們其中一些人領悟了，但你們是少數民族，過去六年來，越清楚這一點就越讓我痛苦，我曾有一度希望，從Microsoft與Amazon來的競爭壓力，以及近來的Facebook，會讓我們集體清醒過來，並且開始動手打造泛用型的服務，不是半生不熟、特製的那種，而是，大致上類似Amazon的那種方式，一次全部到位，真正的，沒有作弊抄捷徑，並且從現在起把這點放在優先順序的第1位。
但是實際上沒有，它好像被我們放在第10還是第11位，或是第15位，我不清楚，只知道相當低；有少數幾個團隊很認真地看待這個觀念，但大部分的團隊，不是從來沒有思索過，就是只有一小搓人以小尺度的心態想過這個議題。
對大多數的團隊來說，若要求他們提供讓其他人以可程式化的方式存取他們的資料與運算資源，就算只是提供簡單粗略的服務，也是翻天覆地的大動作；他們大部分人都認為他們在打造產品，而且提供粗略服務是可悲的，回頭看看Amazon那串學習到的知識，然後告訴我，哪一點是粗略服務可以達成的，就我所知，沒有。僅提供粗略服務就好像需要汽車時卻只有零件。
沒有平台的產品是沒用的，說的更明白更正確一點，無平台的產品總有一天會被另一套平台化的產品所取代。
關於我們沒能了解平台的重要性，Google+是個超明顯的例子，從最最上層的管理領導人（嗨，Larry、Sergey、Eric、Vic，哈囉，您好），一直到最最底層的員工（嘿，就是你），都沒能了解，我們全部通通沒能體悟，平台的黃金守則是吃你自己的狗食，Google+這個平台是個可悲的後見之明，在啟動之日完全沒有API，最近我查了一下，目前也只有極少數可用的API。團隊成員之一在發佈API之時走進來通知我，我問道："所以，這是個跟蹤者API嗎？"，她臉現怒容說"對啦"，我的意思是，我那時是在開玩笑啊，但是，喔不，我們提供的唯一的API就是取得某人的訊息串流，所以，我想我把玩笑開到自己身上了。
Microsoft知道狗食守則已經有至少20年了，這已經是他們文化的一部分，已有一整個世代之久，你不能吃人類食物而給你的開發人員們狗食吃，那麼做只是為了短期的成功果實而劫掠了平台具有的長期價值。所謂平台，就是要考慮到長遠以後。
Google+就像膝蓋猛然一動的反射動作，就像是短期思考後的研究報告，根據錯誤的想法做出的結論，以為Facebook會成功其原因是他們打造出偉大的產品，但那可不是他們成功的理由，Facebook能夠成功是因為，藉由允許外界在其上開發，進而建立起一整群的產品，所以對每個人來說Facebook都不一樣，有些人把全部時間花在Mafia Wars上，有些人只玩Farmville，另外還有上百個甚至上千個不同的高品質的時間消耗機可用可玩，所以，所有人都可以在其上找到他們想要的某種玩法、用法。
我們的Google+團隊，看了看現況後說："天啊，看來似乎我們需要有遊戲，找一些人承包，嗯，為我們寫些遊戲吧"，現在，你是否開始能看出這樣的思考模式錯的多麼嚴重嗎？癥結在於，我們試圖預測使用者想要的，然後推出產品給他們。
你沒辦法做到，真的不能，沒有可靠的方法，在這個世界上，在整個電腦運算歷史上，從過去到現在，只有少數幾個人能夠穩穩地做到這點，Steve Jobs是其中一位，可是我們沒有Steve Jobs，我很抱歉，我們真的沒有。
Larry Tesler可能說服過Bezos相信他不是Steve Jobs，但Bezos明白他不需要成為Steve Jobs才能提供給所有人對的產品：大家喜歡的介面與覺得容易使用的操作流程，Bezos明白他只需要提供出平台，讓第三方開發人員來做，自然而然就會有了。
我要向某些（很多）人道歉，這些人會覺得我以上所說的不是再明顯不過了嗎，沒錯，的確是超超明顯到不行，但是我們並沒有朝那個方向前進，我們沒有領會平台這玩意，而且我們沒有體悟到可存取性的重要，這兩者基本上是同一件事，因為平台會解決可存取性的問題，擁有一套平台就是擁有可存取性。
嗯沒錯，Microsoft有平台的概念，你知道我也知道這多麼令人震驚啊，因為就其他事情來說他們通常"領會"到的程度多半不深，他們能夠了解平台完全是意外性的副產品，因為他們一開始的生意與業務就是提供平台，所以他們在這個領域有著三十多年的學習經驗，如果你去逛逛msdn.com花點時間瀏覽，假設你從沒去看過，等著被嚇到吧，那裡面的東西可是多如牛毛啊，他們擁有幾千、幾萬、幾十萬個API呼叫啊，他們擁有一套巨大的平台，其實話說回來，太巨大了，因為他們要面面俱到，不過至少他們朝著平台的方向在作事。
Amazon也領會了平台的概念，Amazon的AWS(aws.amazon.com)很棒，去看看吧，瀏覽一下，令人感到羞愧啊，我們可沒有那些東西。
很明顯的，Apple也體悟了，環繞在他們的行動平台上，基本上是非開放的形式，不過他們了解可存取性的重要，他們明白善用第三方開發團體的力量，而且他們吃自己的狗食，你知道嗎，他們做的狗食不錯吃喔，他們的APIs跟Microsoft比起來又乾淨又清爽，不能放在一起比較，而且是從很久很久以前就是如此了。
Facebook也體悟了平台這玩意，這點是真正讓我擔憂的，使得我抬起懶惰的大屁股寫下這篇，我恨寫部落格文章，我恨...加一下（譯註：指到Google+上發表），不管怎麼稱呼，反正就是在Google+上發表長篇大論，就算這是個糟糕的發表園地，但你還是這麼做了，因為說到底你真的希望Google能夠成功，我真的這麼希望！我的意思是，Facebook想找我去，其實說去就去滿容易的，但Google是我的家，所以我堅持我們要展開這場小小的家庭爭論，就算你感到不舒服也要做。
等到你被Microsoft與Amazon提供的平台嚇到後，嗯，我想也會被Facebook嚇到（我沒仔細看，因為我不想變得太沮喪），回頭到developers.google.com瀏覽一下，有很大的差別，對吧？看起來就好像你五年級的侄子搞出來的東西，當他被指派功課，試著描述一家大而有力的平台公司可能會打造出來的東西，前提是他們擁有的資源，僅是一個五年級生而已。
請不要誤解我──我知道，其實呢，dev-rel團隊可是經過一番"搏鬥"後才能把那些API向外公開，就我所知他們是很棒的，因為，他們真的領會了平台這玩意，而且如同英雄般努力掙扎地要創建出一套出來，可是，他們所處的四周環境卻是，講好聽一點是對平台冷感，難聽一點是對平台這觀念抱持著敵意。
我只是直白地描述出在一個外人眼裡developers.google.com長什麼樣子，看起來很幼稚。拜託，老天爺啊，Maps APIs在哪呢？其中有些東西還是實驗性質的專案，我有點進去看過的APIs都很瑣碎無用，很明顯地都是些狗食，甚至稱不上是好的有機食品，跟我們內部APIs比起來，簡直就是豬鼻跟馬蹄。
還有，也不要誤解我對Google+團隊的看法，他們可不是唯一的例子，現今，我們在內部進行的是一場戰爭，一邊是受壓迫、少數的平台推廣者，打一場或多或少逐漸敗退的戰鬥，而對手是勢力強大、信心堅定的產品家。
應該打造出外界以可程式化的方式存取的平台，若有任何人成功地將這觀念消化吸收、從頭到腳內化，這種團隊都是受壓迫者──我立刻想到Maps跟Docs，而且我知道GMail是往這個方向踏出第一步的團隊，但是他們很難得到資金挹注，因為這觀念不屬於我們文化的一部分，Maestro獲得的資金跟龐大的Microsoft Office開發平台相比有如九牛一毛：就好像小毛兔跟暴龍相比，Docs團隊心知肚明，除非他們能趕上Office的腳本語言功能，不然無法跟它競爭，但是，他們得不到任何關愛啊，我在此假定如此，根據Apps Script只能在Spreadsheet裡運作這點來看，而且API裡甚至沒有鍵盤快捷鍵的功能，就我來看，Docs團隊並沒有受到重視。
諷刺的是，Wave是個絕妙的平台，願他們在地底長眠，但搞出平台並不會帶給你立即的成功果實，平台需要殺手級應用軟體，Facebook──在這裡指的是，那一堆他們提供的服務，包括塗鴉牆、朋友、其他等等──就是Facebook平台的殺手級應用軟體。若你得出結論說，沒有Facebook平台，光有Facebook應用軟體也能像如今這麼成功，這可是個非常明顯的誤解。
你知道，外面的人總是不斷地說Google好自大傲慢喔，我是個Google員工，跟你一樣，每次我聽到那些話都覺得很煩躁憤怒，大體上而言，我們並不傲慢，大約99%不自大，我在文章開頭寫道──如果你回首看看久遠前的記憶──Google"每件事都做對了"，當有人說我們很自大，大部分的情況是因為我們沒有雇用他們，或是因為他們對我們的政策感到不爽，或是那一類的事情，他們推斷出傲慢這回事，因為這樣會讓他們覺得好過些。
但是，當我們擺出姿態，說我們知道如何為全部的使用者設計出完美的產品，那麼我們就是笨蛋，相信我，我可常常聽到有人這麼說，你可以用傲慢自大、天真浪漫、或其他字眼來形容──不重要，重要的是這就是愚蠢，不可能有這麼一個完美產品適用於所有人。
照這樣的思路下來，我們的瀏覽器居然不能讓人設定預設的字型大小，這不就是公然對可存取性(accessibility)的冒犯嗎，當我年紀越長，總有一天會失明，講的實在一點，我一輩子都在近視下過活，一旦當你到了40歲，你就沒辦法看清近距離的東西了，所以，字型選擇變成是生與死的問題了：可能把某使用者完全排除在產品之外，但是Chrome團隊就是這麼傲慢自大：他們希望打造出零組態的產品，而且相當自豪，誰理你是瞎子或聾子啊，誰管你，去你的吧，用你的餘生在每一個頁面按下Ctrl-+吧。
不僅是他們，我說的是所有人，問題癥結是，我們是家"產品"公司，一直都是，我們打造出成功的產品，擁有廣泛的吸引力──搜尋引擎──而那樣巨大的成功使得我們心有成見、視野偏了。
Amazon過去也是家產品公司，因為有道異常的力量， 才使得Bezos領悟到他們需要平台，那道力量是他們的市值逐漸蒸發，他被逼到牆角了，不得不想方設法突圍，但他擁有的不就是一群工程師跟一堆電腦嗎...要怎麼樣才能變成印鈔機呢...你可以看出他是如何達到AWS這個結論，不過這是放馬後砲。
Microsoft從一開始就是個平台，所以他們有很多經驗與知識。
Facebook，嗯：他們讓我感到憂慮，我不是專家，不過我很肯定他們一開始也是產品，並且取得很長久的成功，所以我不知道他們何時轉變成為平台，應該是很久以前，因為他們要成為平台後那些像Mafia Wars（這些東西已有一定年紀了）才會出現。
或許，他們做的僅是將我們檢視一番後問道："我們如何擊敗Google？他們缺少了什麼？"
我們面臨一堵巨大的問題高牆，需要經過一番有如腥風血雨般的文化心態轉變後，才能開始迎頭趕上，我們對外沒有在做服務導向的平台，同樣的，內部也沒有，這表示說，整個公司都"沒有領悟"：PMs沒有、工程師沒有、產品團隊沒有、沒人有，即使單獨個人有、即使你有，那也無關緊要，除非我們把目前情況當做生死存亡之秋來處理，我們不能不斷推出產品，然後假裝之後會把產品轉變成又美又迷人的可擴充式平台，我們試過了，沒成功。
平台的黃金守則，"吃自己的狗食"，可以換句話說"先打造出平台，然後用它打造任何東西"，你沒辦法事後才把平台放進去，再怎麼說事後才想要做太困難了──去問問那些動手把MS Office平台化、或是把Amazon平台化的人，如果你放在後面才動手，事情會比從一開始就做好難上十倍，你沒辦法作弊、沒有捷徑的，你不能讓內部軟體走秘密後門擁有特殊的優先存取權限，不管理由為何都不能這麼做，難題必須從一開始就起手解決。
我並沒有說現在動手已經太遲了，但我們等的越久，就越接近"太遲了"的那一天。
老實說，我不知道怎麼收尾，我已經把今天想說的都寫下來了，這篇文章醞釀了6年之久，如果言詞間有冒犯之處，或是我誤解了某產品、某團隊、某位同僚，還請包涵，或是其實我們真的有在進行打造平台，卻剛好我以及跟我討論過的人從未聽說過，我在此說聲抱歉。
不論如何，我們必須開始把它做對。
日期：2011.10.13
作者：Steve Yegge
作者的部落格（2006至今）：Stevey's Blog Rants
作者舊的文章（2004與2005）：Stevey's Drunken Blog Rants
作者簡介：
目前任職於Google，之前任職於Geoworks與Amazon。程式語言生涯中有過兩次非常關鍵性的轉換，一次是組合語言，一次是Java 跟Perl，因為發現解決語言本身設計帶來的問題所花的時間，竟然比真正用在開發軟體系統的時間還多。其文章以長度聞名，長到應該稱為論文而非部落格，兼帶詼諧筆風，發表頻率大約一個月一到兩篇，作者總是說這些是在凌晨三罐啤酒下肚後的誇誇其談，但每一篇都是經過長時間醞釀，內容充實有見地的傑作。
獨立以Java/JPyton開發多人線上遊戲Wyvern，可讓玩家自行創建擴充遊戲內容。其工作團隊將Rails移植到Rhino上，Rhino是運作於JVM平台上的JavaScript引擎，Rails(Ruby on Rails)為一套受到廣泛喜愛使用的網站開發模組；為Emacs撰寫完整的JavaScript環境，期望在Emacs上可以有一套 JavaScript IDE，以及將來可用JavaScript而非elisp來開發Emacs extensions。
注意：作者已經刪除原文，因為原本應在公司內部流傳跟同事間互相討論的文章內容，卻意外地發佈到公開網路上。希望你能夠站在不同立場來閱讀，而不是斷章取義只看自己想看的部份。
這邊有原文的備份以及留言。
Steve的Google+頁面。
話說平台（Stevey's Google Platforms Rant）
我曾在Amazon工作了六年半，現在算一算，我在Google的日子也差不多那麼長了。關於這兩家公司，有個衝擊性的差異──在我的腦袋裡這樣的印象幾乎每天都在加深中──那就是，Amazon每件事都做錯了、而Google每件事都做對了。當然啦，這是很籠統的概括評論，但卻出乎意料的是個精確說法，很瘋狂吧。你可以舉出大概一百甚至兩百種不同的項目來比較兩家公司，而Google每一項都能勝出，除了其中3項以外。如果我記的沒錯，我確實曾用試算表列出來加以比較一番，不過法律部門不會允許我秀給任何人看，即使人事招募部門會愛的不得了。
讓我給你個例子稍微體會一下：Amazon的人事雇用流程存在著根本上的缺陷，每個團隊獨自為自己招募新人，以至於，各團隊之間的雇用標準，有著天差地別的不一致性，即使他們通過各種努力來撫平差異，仍然相去甚遠，而且，他們的操作方法一團糟，沒有真正的SREs，工程師們什麼事都要做、幾乎沒時間撰寫程式碼──當然啦，各部門情況不同，取決於你的運氣。他們不碰慈善、不幫助需要幫助的人、不鳥社群集體貢獻、或是任何類似的活動，相關話題從來沒有浮現過，或許只有在閒談說笑時才會提到，他們的辦公室是個滿佈灰塵的農場隔間，連一分錢都不會花在裝潢或是公共場地與會議室，他們的薪資與紅利遜斃了，最近因為來自Google與Facebook的競爭才好多了，不過，我們有津貼或額外獎金，他們都沒有──他們只是想要讓薪資帳面上的數字好看一點，就這樣子而已。他們的程式碼就像是災難過後滿目瘡痍，沒有工程標準或撰碼規則，除了團隊各自選擇性地、局部性地自己搞自己的以外。
話說回來，公道一點，他們的確有套不錯的程式庫版本控管系統，這是我們真的應該要盡力趕上的地方，以及發佈/訂閱系統，我們也沒有相對應的東西，不過，就大體而言，他們有的不過是一堆低劣的工具，藉以將狀態機裡的資訊，讀取或寫入到關聯式資料庫中罷了。我們不該模傚或借鏡，就算可以免費取得也要棄之不理。
我認為，他們的發佈/訂閱系統、程式庫版本控管系統，是Amazon比Google強的那3個項目之中的2點。
我猜你或許可以為他們辯護，"早早推出服務並不斷反覆地改進"，他們對於此作法有著近乎偏執的狂熱，你可以說他們這點做的很好，不過，關於這點，我們也可以從另一角度來爭辯，他們把"早早推出"這點，擴及應用到所有其他事項上，譬如說軟體工程守則與戒律跟其他一票的事項與流程，而這些都是會造成長期性的影響，所以說，即使這點讓他們在市場上有了某種程度的競爭優勢，但也造成其他許許多多的問題，總結而言，這不能算得上是個漂亮灌籃得分的項目。
但～是～，他們有一件事做的非常非常好，好到把其他政略上、理念上、技術上的缺失通通彌補回來。
Jeff Bezos是位惡名昭彰的微控經理人，他對Amazon零售網站頁面上的每一點像素都要微控管理，他雇用Larry Tesler，Apple的領頭科學家，可說是全世界中最有名且最受尊敬的人機介面專家，然後，Jeff不理會Larry提出的每一項建言，整整三年，直到Larry最後──明智地──終於離開了公司。Larry應會實踐大型的可用性測試，然後憑著研究報告、不存著一絲絲疑惑地證明出，根本就沒有人能夠搞懂、使用那該死的網站，可是，對於頁面上幾百萬個都包含著意義的像素，Bezos就是不能放手，就好像是對待寶貝兒子般呵護著，所以結果是，像素通通還留著，而Larry走人。
喔，對了，微控管理不是第三項Amazon做的比我們好的地方，我的意思是，沒錯，他們微控管理做的很好，但我可不會把這項列在強項或優勢清單上，以上所言只是為了下文鋪陳，幫助你了解背景。我們現在討論的人，是個在很多公開場合說過，而且是很認真地說，人們想進Amazon工作應該付他錢才對呀，當有人跟他意見不同時，他會遞出黃色便利貼有著Jeff的名字在上頭，提醒人們"誰才是公司的老大"，這傢伙可說是一個較守規矩的，嗯，Steve Jobs，我想應該可以這麼說，除了他沒有流行品味或是關於設計的理解力以外；可別誤解我了，Bezos可是超級聰明的仁兄，只不過呢，他的所作所為，讓那些一般般的控制狂看起來只不過像是抽大麻的嬉皮罷了。
有一天，Jeff Bezos發布一份命令書，當然啦，他總是不斷地在下命令，而如螞蟻般忙碌爬行的員工就會像被橡皮槌敲擊般地受到震撼，不過，有一次的情況是──大概是2002年吧，我想，誤差1年內──他發布一份命令書，發布範圍非常廣，內容龐大且沈重，讓你的眼珠子都快掉下來了，跟這份命令書相比，其他的就好像突然收到來自同儕的獎勵。
這份大大的命令書，其內涵大致如下幾點：
1) 從今以後，每個團隊要以透過服務介面(service interfaces)的存取方式，將資料與功能開放出來，。
2) 團隊間的溝通，都要透過這些介面。
3) 行程間的溝通(interprocess communication)，其他形式一概不允許：不能直接鏈結、不能直接讀取其他團隊的資料、不能使用共享記憶體模式、不能走後門、等等，唯一的溝通管道就是在網路之上的服務介面呼叫。
4) 任何技術皆可使用，HTTP、Corba、發佈/訂閱系統、客製的網路協定、等等，都可以，Bezos不管這些。
5) 所有的服務介面，毫無例外，都必須從骨子裡設計好，能夠對外界開放，也就是說，團隊必須做好規劃與設計，能夠把介面開放給外界的開發人緣使用，沒有例外。
6) 不做的人會被炒魷魚。
7) 謝謝，祝你有個愉快的一天！
哈哈！你們這群150位前Amazon員工，一眼就看出第7點是我加上的，純為搏君一笑，因為Bezos才不會去關心你今天過的好不好咧。
不過第6點就是認真的了，所以人們紛紛埋頭苦幹，Bezos指派了幾位上級牛頭犬來監督並確保進度，由超高級跟熊一樣大的牛頭犬Rick Dalzell領軍，Rick是前陸軍突擊隊員、西點軍校畢業生、前拳擊手、前Wal*Mart的首席虐刑官 斜線 首席技術長，而且也是個高大、和藹、令人敬畏的男人，經常使用"硬化介面(hardened interface)"字眼的男人，Rick本身就是個會走路會說話的硬化介面，所以不消多說，每個人都做出重大的進展並確保讓Rick知悉一切。
在接下來的幾年內，Amazon的內部轉變成服務導向架構(service-oriented architecture)，在這蛻變的過程中，他們學到了一拖拉庫的知識，在當時，是有著關於SOA的文件，但跟Amazon那種超大規模比起來，那些技巧就跟告訴印第安那瓊斯過馬路前要先看看兩旁有無來車一樣沒用，Amazon的研發團隊在這過程中學到了不少、發現了不少，其中的極少極小的抽樣範例如下：
- pager escalation變得異常困難，因為ticket可能會送過來送過去，過程中會超過20個服務呼叫，然後才能找到真正的擁有者，如果每一個呼叫都花去團隊的15分鐘的反應時間，那在找到真正的團隊之前幾小時就過去了，除非，你建構出很多很多的scaffolding、metrics、reporting。
- 你的同儕團隊，每一個，突然間都變成潛在性的DOS攻擊者，你沒辦法有進展，直到在每一個服務裡放上配額限制(quota)與節流閥(throttling)的機制。
- 監控(monitoring)與品質控管(QA)是同一回事。你過去不會這麼想，直到試著進行大規模的SOA才會有此體悟。但是，等到你的服務說"喔沒錯，我很好"的時候，到那時的情況可能是，伺服器裡唯一正常運作的功能就只是那一小塊懂得用愉快機器人的聲音說"我很好，收到了，收到了，停止通話"的部份而已，為了要確認整個服務是否真正運作無虞，你必須對每一個部分都發出呼叫要求，同樣的情況會遞迴式地出現，直到你的監控系統能夠全面性地對整個服務與資料做出各種面相的檢查，到那時，就跟自動化QA沒什麼兩樣了，所以這兩者皆位於同一連續帶上。
- 如果你有上百個服務，而且你的程式只能經由這些服務來跟其他團隊的程式做溝通，那麼，沒有一套服務探索機制(service-discovery mechanism)的話，你就不能找到想要的服務，而且在那之前，你得先有一套服務註冊機制(service registration mechanism)，而這本身也是一項服務，所以，Amazon有一套全體適用的服務註冊機制，以反射可程式化(reflectively, programmatically)的方式找出服務，得知API為何、目前狀態是否可用、在哪裡。
- 跟他人程式有關的除錯，這問題變得更難了，基本上是不可能的，直到有一套全面性的標準方式，能夠在可除錯的沙盒環境內執行服務。
上面這些只是少數幾個例子，Amazon在蛻變得過程中，逐漸發現、學習了數十個、甚至數百個像這樣子的知識，關於把服務開放出去，會有幾個想都想不到的冷僻知識，不過不會像你想的那麼多，將功能重新加以組織劃分成服務後，團隊學會了不該信任彼此，就如同他們也不該相信外部的開發人員一樣。
當我在2005年中離開Amazon加入Google時，這轉變過程還處於進行式，但已經相當先進了，從Bezos頒佈法令的時間點到我離開之時，Amazon已經從文化心態上轉變成一家凡事以服務架構為優先考量的公司，到如今，已經成為他們進行所有設計時的基本原則，即使是那些僅在內部絕不會被外部世界使用的功能。
現在，他們不是怕被解雇才朝這個方向進行，我是說，他們仍然怕被炒魷魚，這點佔了在那兒生存的一大部分，在可怕海賊王Bezos的底下工作。不過，他們朝"服務"的方向前進，因為他們已經相信這就是正確的方向，關於SOA這種作法，不用說當然有優點也有缺點，某些缺點還很大，但是整體而言，這是正確的，因為，以SOA來進行設計，會產生出平台(platform)。
沒錯，這就是Bezos他的法令想要達成的目標，他以前（現在也是）對各團隊過的好不好一點都不在乎，不關心他們使用的技術為何，事實上也不去管他們怎麼進行他們的工作，除非他們有搞砸的跡象，但是，Bezos很早很早以前就領悟到，在絕大部分的Amazon居民都不知道以前，Amazon必須成為一個平台。
你應該不會想到線上賣書的網站需要成為一個有擴充性、可程式化的平台吧，你會嗎？
嗯，Bezos領悟到的第一件大事是，為了販賣銷售書籍與各種商品所打造出來的架構，可以轉變成為用途可再定義的絕佳運算平台，所以，現在他們有了Amazon Elastic Compute Cloud(亞馬遜彈性運算雲端)、Amazon Elastic MapReduce、亞馬遜關聯式資料庫服務(Amazon Relational Database Service)，以及其他可在aws.amazon.com查得到的一狗票服務，這些服務是某些相當成功的公司的後端架構，我喜歡舉的例子之一是reddit。
另一個大領悟是，他知道，他們不可能永遠都打造出對的東西，我認為，當Larry Tesler說他媽媽完全搞不懂怎麼使用那個見鬼的網站時，Bezos的某條心弦被撥動了，也不清楚說的到底是誰家媽媽，但無關緊要，因為沒有人的媽媽能夠使用那個天殺的網站，事實上，我自己都覺得Amazon網站的介面令人膽寒、卻步，那時我已經在那裡工作超過五年了，我後來終於學會，如何控制眼睛的焦點、關注在那接近頁面中間的幾百萬個像素。
我不是很確定Bezos是如何體悟到這點的──洞察到他不可能打造出一套適用於所有人的產品，不過這不重要，重要的是他領悟了，其實，這玩意有個正式的名稱，叫做可存取性(accessibility)，這是運算世界中最重要的事情。
最 重 要 的 事 情。
如果你在心理嘀咕著，"啥？你是說，盲人聾人那種可存取性嗎？"，你不是唯一一個這麼想的人，我已經知道有很多很多像你這樣的人：上述那玩意對你們來說沒有可存取性，所以這觀念還沒能進入到你的腦袋裡，不了解也不是你的錯，就好像有人眼盲、耳聾、行動不便、或有其他殘疾也不是他們的錯一樣，當軟體──或可稱為概念體──不管是什麼理由，如果不能被某人存取、使用，那麼，就是軟體的錯、或是那概念的傳遞出錯了，這就是失敗的可存取性。
就如同生命中任何重要的大事，可存取性有個邪惡的雙胞胎哥哥，在幼年期享有父母的偏愛溺愛，已經成長為同等強大的復仇邪神第一名（是的，對可存取性來說，復仇邪神有好幾個），其名為安全性(security)，但是，乖乖隆個咚，這兩個從來沒被公平對待過。
不過，我主張可存取性比安全性來的重要多了，因為，可存取性若為零，你根本沒有產品，而若安全性為零，你仍然能夠得到在相當程度上算是成功的產品，譬如說Playstation Network。
所以說，對了，假使你還沒注意到，我其實可以寫出一整本書來討論這個主題，厚厚一本，填滿了那家我曾工作過的公司裡關於螞蟻與橡皮槌的有趣軼事，但那樣一來，我就永遠不可能發表這篇短短的夸夸其談了，而你也就無法讀到，除非我現在開始收尾做總結。
Google做的不太好的最後一點是平台，我們不了解平台，我們沒抓到它的意涵，你們其中一些人領悟了，但你們是少數民族，過去六年來，越清楚這一點就越讓我痛苦，我曾有一度希望，從Microsoft與Amazon來的競爭壓力，以及近來的Facebook，會讓我們集體清醒過來，並且開始動手打造泛用型的服務，不是半生不熟、特製的那種，而是，大致上類似Amazon的那種方式，一次全部到位，真正的，沒有作弊抄捷徑，並且從現在起把這點放在優先順序的第1位。
但是實際上沒有，它好像被我們放在第10還是第11位，或是第15位，我不清楚，只知道相當低；有少數幾個團隊很認真地看待這個觀念，但大部分的團隊，不是從來沒有思索過，就是只有一小搓人以小尺度的心態想過這個議題。
對大多數的團隊來說，若要求他們提供讓其他人以可程式化的方式存取他們的資料與運算資源，就算只是提供簡單粗略的服務，也是翻天覆地的大動作；他們大部分人都認為他們在打造產品，而且提供粗略服務是可悲的，回頭看看Amazon那串學習到的知識，然後告訴我，哪一點是粗略服務可以達成的，就我所知，沒有。僅提供粗略服務就好像需要汽車時卻只有零件。
沒有平台的產品是沒用的，說的更明白更正確一點，無平台的產品總有一天會被另一套平台化的產品所取代。
關於我們沒能了解平台的重要性，Google+是個超明顯的例子，從最最上層的管理領導人（嗨，Larry、Sergey、Eric、Vic，哈囉，您好），一直到最最底層的員工（嘿，就是你），都沒能了解，我們全部通通沒能體悟，平台的黃金守則是吃你自己的狗食，Google+這個平台是個可悲的後見之明，在啟動之日完全沒有API，最近我查了一下，目前也只有極少數可用的API。團隊成員之一在發佈API之時走進來通知我，我問道："所以，這是個跟蹤者API嗎？"，她臉現怒容說"對啦"，我的意思是，我那時是在開玩笑啊，但是，喔不，我們提供的唯一的API就是取得某人的訊息串流，所以，我想我把玩笑開到自己身上了。
Microsoft知道狗食守則已經有至少20年了，這已經是他們文化的一部分，已有一整個世代之久，你不能吃人類食物而給你的開發人員們狗食吃，那麼做只是為了短期的成功果實而劫掠了平台具有的長期價值。所謂平台，就是要考慮到長遠以後。
Google+就像膝蓋猛然一動的反射動作，就像是短期思考後的研究報告，根據錯誤的想法做出的結論，以為Facebook會成功其原因是他們打造出偉大的產品，但那可不是他們成功的理由，Facebook能夠成功是因為，藉由允許外界在其上開發，進而建立起一整群的產品，所以對每個人來說Facebook都不一樣，有些人把全部時間花在Mafia Wars上，有些人只玩Farmville，另外還有上百個甚至上千個不同的高品質的時間消耗機可用可玩，所以，所有人都可以在其上找到他們想要的某種玩法、用法。
我們的Google+團隊，看了看現況後說："天啊，看來似乎我們需要有遊戲，找一些人承包，嗯，為我們寫些遊戲吧"，現在，你是否開始能看出這樣的思考模式錯的多麼嚴重嗎？癥結在於，我們試圖預測使用者想要的，然後推出產品給他們。
你沒辦法做到，真的不能，沒有可靠的方法，在這個世界上，在整個電腦運算歷史上，從過去到現在，只有少數幾個人能夠穩穩地做到這點，Steve Jobs是其中一位，可是我們沒有Steve Jobs，我很抱歉，我們真的沒有。
Larry Tesler可能說服過Bezos相信他不是Steve Jobs，但Bezos明白他不需要成為Steve Jobs才能提供給所有人對的產品：大家喜歡的介面與覺得容易使用的操作流程，Bezos明白他只需要提供出平台，讓第三方開發人員來做，自然而然就會有了。
我要向某些（很多）人道歉，這些人會覺得我以上所說的不是再明顯不過了嗎，沒錯，的確是超超明顯到不行，但是我們並沒有朝那個方向前進，我們沒有領會平台這玩意，而且我們沒有體悟到可存取性的重要，這兩者基本上是同一件事，因為平台會解決可存取性的問題，擁有一套平台就是擁有可存取性。
嗯沒錯，Microsoft有平台的概念，你知道我也知道這多麼令人震驚啊，因為就其他事情來說他們通常"領會"到的程度多半不深，他們能夠了解平台完全是意外性的副產品，因為他們一開始的生意與業務就是提供平台，所以他們在這個領域有著三十多年的學習經驗，如果你去逛逛msdn.com花點時間瀏覽，假設你從沒去看過，等著被嚇到吧，那裡面的東西可是多如牛毛啊，他們擁有幾千、幾萬、幾十萬個API呼叫啊，他們擁有一套巨大的平台，其實話說回來，太巨大了，因為他們要面面俱到，不過至少他們朝著平台的方向在作事。
Amazon也領會了平台的概念，Amazon的AWS(aws.amazon.com)很棒，去看看吧，瀏覽一下，令人感到羞愧啊，我們可沒有那些東西。
很明顯的，Apple也體悟了，環繞在他們的行動平台上，基本上是非開放的形式，不過他們了解可存取性的重要，他們明白善用第三方開發團體的力量，而且他們吃自己的狗食，你知道嗎，他們做的狗食不錯吃喔，他們的APIs跟Microsoft比起來又乾淨又清爽，不能放在一起比較，而且是從很久很久以前就是如此了。
Facebook也體悟了平台這玩意，這點是真正讓我擔憂的，使得我抬起懶惰的大屁股寫下這篇，我恨寫部落格文章，我恨...加一下（譯註：指到Google+上發表），不管怎麼稱呼，反正就是在Google+上發表長篇大論，就算這是個糟糕的發表園地，但你還是這麼做了，因為說到底你真的希望Google能夠成功，我真的這麼希望！我的意思是，Facebook想找我去，其實說去就去滿容易的，但Google是我的家，所以我堅持我們要展開這場小小的家庭爭論，就算你感到不舒服也要做。
等到你被Microsoft與Amazon提供的平台嚇到後，嗯，我想也會被Facebook嚇到（我沒仔細看，因為我不想變得太沮喪），回頭到developers.google.com瀏覽一下，有很大的差別，對吧？看起來就好像你五年級的侄子搞出來的東西，當他被指派功課，試著描述一家大而有力的平台公司可能會打造出來的東西，前提是他們擁有的資源，僅是一個五年級生而已。
請不要誤解我──我知道，其實呢，dev-rel團隊可是經過一番"搏鬥"後才能把那些API向外公開，就我所知他們是很棒的，因為，他們真的領會了平台這玩意，而且如同英雄般努力掙扎地要創建出一套出來，可是，他們所處的四周環境卻是，講好聽一點是對平台冷感，難聽一點是對平台這觀念抱持著敵意。
我只是直白地描述出在一個外人眼裡developers.google.com長什麼樣子，看起來很幼稚。拜託，老天爺啊，Maps APIs在哪呢？其中有些東西還是實驗性質的專案，我有點進去看過的APIs都很瑣碎無用，很明顯地都是些狗食，甚至稱不上是好的有機食品，跟我們內部APIs比起來，簡直就是豬鼻跟馬蹄。
還有，也不要誤解我對Google+團隊的看法，他們可不是唯一的例子，現今，我們在內部進行的是一場戰爭，一邊是受壓迫、少數的平台推廣者，打一場或多或少逐漸敗退的戰鬥，而對手是勢力強大、信心堅定的產品家。
應該打造出外界以可程式化的方式存取的平台，若有任何人成功地將這觀念消化吸收、從頭到腳內化，這種團隊都是受壓迫者──我立刻想到Maps跟Docs，而且我知道GMail是往這個方向踏出第一步的團隊，但是他們很難得到資金挹注，因為這觀念不屬於我們文化的一部分，Maestro獲得的資金跟龐大的Microsoft Office開發平台相比有如九牛一毛：就好像小毛兔跟暴龍相比，Docs團隊心知肚明，除非他們能趕上Office的腳本語言功能，不然無法跟它競爭，但是，他們得不到任何關愛啊，我在此假定如此，根據Apps Script只能在Spreadsheet裡運作這點來看，而且API裡甚至沒有鍵盤快捷鍵的功能，就我來看，Docs團隊並沒有受到重視。
諷刺的是，Wave是個絕妙的平台，願他們在地底長眠，但搞出平台並不會帶給你立即的成功果實，平台需要殺手級應用軟體，Facebook──在這裡指的是，那一堆他們提供的服務，包括塗鴉牆、朋友、其他等等──就是Facebook平台的殺手級應用軟體。若你得出結論說，沒有Facebook平台，光有Facebook應用軟體也能像如今這麼成功，這可是個非常明顯的誤解。
你知道，外面的人總是不斷地說Google好自大傲慢喔，我是個Google員工，跟你一樣，每次我聽到那些話都覺得很煩躁憤怒，大體上而言，我們並不傲慢，大約99%不自大，我在文章開頭寫道──如果你回首看看久遠前的記憶──Google"每件事都做對了"，當有人說我們很自大，大部分的情況是因為我們沒有雇用他們，或是因為他們對我們的政策感到不爽，或是那一類的事情，他們推斷出傲慢這回事，因為這樣會讓他們覺得好過些。
但是，當我們擺出姿態，說我們知道如何為全部的使用者設計出完美的產品，那麼我們就是笨蛋，相信我，我可常常聽到有人這麼說，你可以用傲慢自大、天真浪漫、或其他字眼來形容──不重要，重要的是這就是愚蠢，不可能有這麼一個完美產品適用於所有人。
照這樣的思路下來，我們的瀏覽器居然不能讓人設定預設的字型大小，這不就是公然對可存取性(accessibility)的冒犯嗎，當我年紀越長，總有一天會失明，講的實在一點，我一輩子都在近視下過活，一旦當你到了40歲，你就沒辦法看清近距離的東西了，所以，字型選擇變成是生與死的問題了：可能把某使用者完全排除在產品之外，但是Chrome團隊就是這麼傲慢自大：他們希望打造出零組態的產品，而且相當自豪，誰理你是瞎子或聾子啊，誰管你，去你的吧，用你的餘生在每一個頁面按下Ctrl-+吧。
不僅是他們，我說的是所有人，問題癥結是，我們是家"產品"公司，一直都是，我們打造出成功的產品，擁有廣泛的吸引力──搜尋引擎──而那樣巨大的成功使得我們心有成見、視野偏了。
Amazon過去也是家產品公司，因為有道異常的力量， 才使得Bezos領悟到他們需要平台，那道力量是他們的市值逐漸蒸發，他被逼到牆角了，不得不想方設法突圍，但他擁有的不就是一群工程師跟一堆電腦嗎...要怎麼樣才能變成印鈔機呢...你可以看出他是如何達到AWS這個結論，不過這是放馬後砲。
Microsoft從一開始就是個平台，所以他們有很多經驗與知識。
Facebook，嗯：他們讓我感到憂慮，我不是專家，不過我很肯定他們一開始也是產品，並且取得很長久的成功，所以我不知道他們何時轉變成為平台，應該是很久以前，因為他們要成為平台後那些像Mafia Wars（這些東西已有一定年紀了）才會出現。
或許，他們做的僅是將我們檢視一番後問道："我們如何擊敗Google？他們缺少了什麼？"
我們面臨一堵巨大的問題高牆，需要經過一番有如腥風血雨般的文化心態轉變後，才能開始迎頭趕上，我們對外沒有在做服務導向的平台，同樣的，內部也沒有，這表示說，整個公司都"沒有領悟"：PMs沒有、工程師沒有、產品團隊沒有、沒人有，即使單獨個人有、即使你有，那也無關緊要，除非我們把目前情況當做生死存亡之秋來處理，我們不能不斷推出產品，然後假裝之後會把產品轉變成又美又迷人的可擴充式平台，我們試過了，沒成功。
平台的黃金守則，"吃自己的狗食"，可以換句話說"先打造出平台，然後用它打造任何東西"，你沒辦法事後才把平台放進去，再怎麼說事後才想要做太困難了──去問問那些動手把MS Office平台化、或是把Amazon平台化的人，如果你放在後面才動手，事情會比從一開始就做好難上十倍，你沒辦法作弊、沒有捷徑的，你不能讓內部軟體走秘密後門擁有特殊的優先存取權限，不管理由為何都不能這麼做，難題必須從一開始就起手解決。
我並沒有說現在動手已經太遲了，但我們等的越久，就越接近"太遲了"的那一天。
老實說，我不知道怎麼收尾，我已經把今天想說的都寫下來了，這篇文章醞釀了6年之久，如果言詞間有冒犯之處，或是我誤解了某產品、某團隊、某位同僚，還請包涵，或是其實我們真的有在進行打造平台，卻剛好我以及跟我討論過的人從未聽說過，我在此說聲抱歉。
不論如何，我們必須開始把它做對。
2011/09/14
翻譯：Xcode的建置設定Build Active Architecture Only（Xcode Build Active Architecture Only ）by Keith Harrison
文章：Xcode Build Active Architecture Only（Xcode的建置設定Build Active Architecture Only）
日期：2010.04.21，
作者：Keith Harrison
作者的部落格：Use Your Loaf
作者簡介：
任職某IT公司，下班後在iPhone上開發，以及在mac上使用Ruby on Rails。
Xcode的建置設定Build Active Architecture Only
今天在Stackoverflow上看到某個問題，讓我想起在Xcode 3.2.2裡，有些新加入的建置設定，值得在這裡說明一下。隨著iPhone/iPod Touch新型機種推出，以及iPad的加入，你可以決定要將軟體編譯成哪一種處理器架構的格式，下面的設定，都放在target info的標籤Build之下（在target上按滑鼠右鍵然後選Get Info）。
Standard (armv6)
原先的armv6架構，現在以"Standard"字樣出現，產出的二進位檔案，可在所有機種上運行，如果你的軟體還需要在iPhone OS 2.x上跑的話，你應該選擇此設定，因為，根據一些報告指出，2.x的機子跟universal binary二進位檔有點不對頭。
Optimized (armv6 armv7)
若是選"Optimized"的話，這會建置出universal或稱為"fat"的二進位檔，裡面含有armv6與armv7兩套二進位檔，顧名思義，這樣的軟體檔會比較肥大，不過，當放到armv7機種上運作時，就能充分完整地利用處理器的能力。在實務上，使用者到底能不能感受到效能的提升，取決於應用軟體需要處理的事情與運算。如果你的目標對象是OS 3.x或之後的版本，一般來說，你應該選這個項目。
Other (armv7)
如果你的對象只有iPad的話（iPhone OS 3.2），你可以手動把架構設定為armv7，這樣就不會去建置armv6的部份。
Build Active Architecture Only
到目前為止，都很容易理解，但是，有件事要注意。在target的建置設定中，在Architectures那一部分裡有個叫"Build Active Architecture Only"的設定，這會影響二進位檔的建置方式，其預設值是，若是Debug組態，此設定值會被勾選，如下：
Xcode現在會偵測你有連接的機子，根據機型來設定此項目，所以，如果你插入iPod Touch二代的話，Xcode會將active architecture設定為armv6，此時，若你用上面的Debug組態來建置，那麼只會建置出armv6的二進位檔，以節省時間（除非你的專案很大，大到感覺不到，不過，我想你多多少少都能察覺出建置所需的秒數）。
當你新增Distribution組態來發佈軟體到App Store上時，你應該要確認一下，這個選項應該是"不勾選"的狀態，這樣才會建置出肥大的universal binary，如下：
每當蘋果公司推出新機型，建置流程就變得更加複雜，花時間留意一下Xcode裡出現的新選項設定是值得的，即使大家都有共識，Xcode在隱藏細節與複雜設定這一方面，做的還不錯。
日期：2010.04.21，
作者：Keith Harrison
作者的部落格：Use Your Loaf
作者簡介：
任職某IT公司，下班後在iPhone上開發，以及在mac上使用Ruby on Rails。
Xcode的建置設定Build Active Architecture Only
今天在Stackoverflow上看到某個問題，讓我想起在Xcode 3.2.2裡，有些新加入的建置設定，值得在這裡說明一下。隨著iPhone/iPod Touch新型機種推出，以及iPad的加入，你可以決定要將軟體編譯成哪一種處理器架構的格式，下面的設定，都放在target info的標籤Build之下（在target上按滑鼠右鍵然後選Get Info）。
Standard (armv6)
原先的armv6架構，現在以"Standard"字樣出現，產出的二進位檔案，可在所有機種上運行，如果你的軟體還需要在iPhone OS 2.x上跑的話，你應該選擇此設定，因為，根據一些報告指出，2.x的機子跟universal binary二進位檔有點不對頭。
Optimized (armv6 armv7)
若是選"Optimized"的話，這會建置出universal或稱為"fat"的二進位檔，裡面含有armv6與armv7兩套二進位檔，顧名思義，這樣的軟體檔會比較肥大，不過，當放到armv7機種上運作時，就能充分完整地利用處理器的能力。在實務上，使用者到底能不能感受到效能的提升，取決於應用軟體需要處理的事情與運算。如果你的目標對象是OS 3.x或之後的版本，一般來說，你應該選這個項目。
Other (armv7)
如果你的對象只有iPad的話（iPhone OS 3.2），你可以手動把架構設定為armv7，這樣就不會去建置armv6的部份。
Build Active Architecture Only
到目前為止，都很容易理解，但是，有件事要注意。在target的建置設定中，在Architectures那一部分裡有個叫"Build Active Architecture Only"的設定，這會影響二進位檔的建置方式，其預設值是，若是Debug組態，此設定值會被勾選，如下：
Xcode現在會偵測你有連接的機子，根據機型來設定此項目，所以，如果你插入iPod Touch二代的話，Xcode會將active architecture設定為armv6，此時，若你用上面的Debug組態來建置，那麼只會建置出armv6的二進位檔，以節省時間（除非你的專案很大，大到感覺不到，不過，我想你多多少少都能察覺出建置所需的秒數）。
當你新增Distribution組態來發佈軟體到App Store上時，你應該要確認一下，這個選項應該是"不勾選"的狀態，這樣才會建置出肥大的universal binary，如下：
每當蘋果公司推出新機型，建置流程就變得更加複雜，花時間留意一下Xcode裡出現的新選項設定是值得的，即使大家都有共識，Xcode在隱藏細節與複雜設定這一方面，做的還不錯。
2011/09/13
cocos2d-iphone的安裝、移除與Hello World
這篇是cocos2d-iphone的安裝與移除，我的環境是Mac OS X Snow Leopard(10.6.8)、Xcode 4.2 for Snow Leopard(Build: 4C199)。
安裝非常容易，先到這裡下載打包壓縮後的檔案，目前1.x版的最新穩定釋出版本是cocos2d-iphone-1.0.1.tar.gz，大小約32 MB；2.x版則為cocos2d-iphone-2.0.tar.gz版，大小約39 MB，不過cocos2d 1.x與2.x有所差異，可看這裡判斷。
（如果你想追求最新版本的話，cocos2d的最新原始碼放在GitHub上，其中分支develop是1.x版，分支develop-v2是2.x版。）
底下以cocos2d-iphone-2.0.tar.gz為例。
先解壓縮
$ tar zxvf cocos2d-iphone-2.0.tar.gz
解壓縮後會有一個目錄cocos2d-iphone-2.0，基本上，這是cocos2d開發人員的工作區，我們並不直接在裡面開發遊戲，不過你可以用Xcode開啟cocos2d.xcworkspace，裡面有非常多的範例與測試，請執行看看。
開啟此workspace後，在左欄看到三個project，cocos2d-mac（cocos2d-iphone也開始支援mac平台）、cocos2d-ios（顧名思義）、cocos2d-ios-PerformanceTests（測試效能）。
裡頭有很多建置目標，請隨便選、測試看看。
這是LabelTest。
這是ParallaxTest。
這是RotateWorldTest。
當然，這些是供測試用的範例，你可以到這裡看看以cocos2d開發出來的遊戲的畫面，大概了解一下cocos2d的能力。
接下來要安裝cocos2d的Xcode專案範本，先cd進之前解壓縮後的目錄，然後：
$ ./install-templates.sh
（可能要用 sudo ./install-templates.sh 以root權限安裝）
這支script會把cocos2d的專案範本安裝在/Users//Library/Developer/Xcode/Templates/cocos2d v2.x/之下，把檔案範本安裝在/Users//Library/Developer/Xcode/Templates/File Templates/cocos2d v2.x/之下。
如果你之前有安裝過舊版，可加上參數-f強制覆蓋。
接下來，讓我們用安裝後的專案範本弄出一個基本的Hello World。
執行xcode-File-New-New Project...，選擇cocos2d這個專案範本，
取個名字、選個目錄存放後，你可以看到：
不多說，將執行對象改為模擬器後，直接按Run執行：
哇，已經出現Hello World啦。你可以試試看其他兩個專案範本，那是跟物理引擎有關的。
接下來，就請你看看這篇cocos2d-iphone的學習資料，動手開發你的遊戲吧。
如果你想移除的話，很簡單：
1. 刪除目錄cocos2d-iphone-2.0，這是解壓縮cocos2d-iphone-1.0.1.tar.gz後得到的。
2. 刪除專案範本與檔案範本，路徑是 /Users//Library/Developer/Xcode/Templates/cocos2d v2.x/與/Users//Library/Developer/Xcode/Templates/File Templates/cocos2d v2.x/。
3. 刪除你自己建立的Xcode專案。
安裝非常容易，先到這裡下載打包壓縮後的檔案，目前1.x版的最新穩定釋出版本是cocos2d-iphone-1.0.1.tar.gz，大小約32 MB；2.x版則為cocos2d-iphone-2.0.tar.gz版，大小約39 MB，不過cocos2d 1.x與2.x有所差異，可看這裡判斷。
（如果你想追求最新版本的話，cocos2d的最新原始碼放在GitHub上，其中分支develop是1.x版，分支develop-v2是2.x版。）
底下以cocos2d-iphone-2.0.tar.gz為例。
先解壓縮
$ tar zxvf cocos2d-iphone-2.0.tar.gz
解壓縮後會有一個目錄cocos2d-iphone-2.0，基本上，這是cocos2d開發人員的工作區，我們並不直接在裡面開發遊戲，不過你可以用Xcode開啟cocos2d.xcworkspace，裡面有非常多的範例與測試，請執行看看。
開啟此workspace後，在左欄看到三個project，cocos2d-mac（cocos2d-iphone也開始支援mac平台）、cocos2d-ios（顧名思義）、cocos2d-ios-PerformanceTests（測試效能）。
裡頭有很多建置目標，請隨便選、測試看看。
這是LabelTest。
這是ParallaxTest。
這是RotateWorldTest。
當然，這些是供測試用的範例，你可以到這裡看看以cocos2d開發出來的遊戲的畫面，大概了解一下cocos2d的能力。
接下來要安裝cocos2d的Xcode專案範本，先cd進之前解壓縮後的目錄，然後：
$ ./install-templates.sh
（可能要用 sudo ./install-templates.sh 以root權限安裝）
這支script會把cocos2d的專案範本安裝在/Users/
如果你之前有安裝過舊版，可加上參數-f強制覆蓋。
接下來，讓我們用安裝後的專案範本弄出一個基本的Hello World。
執行xcode-File-New-New Project...，選擇cocos2d這個專案範本，
取個名字、選個目錄存放後，你可以看到：
不多說，將執行對象改為模擬器後，直接按Run執行：
哇，已經出現Hello World啦。你可以試試看其他兩個專案範本，那是跟物理引擎有關的。
接下來，就請你看看這篇cocos2d-iphone的學習資料，動手開發你的遊戲吧。
如果你想移除的話，很簡單：
1. 刪除目錄cocos2d-iphone-2.0，這是解壓縮cocos2d-iphone-1.0.1.tar.gz後得到的。
2. 刪除專案範本與檔案範本，路徑是 /Users//Library/Developer/Xcode/Templates/cocos2d v2.x/與/Users//Library/Developer/Xcode/Templates/File Templates/cocos2d v2.x/。
3. 刪除你自己建立的Xcode專案。
2011/09/12
cocos2d-iphone的學習資料
cocos2d這套開放原始碼的遊戲引擎，最初是以Python寫的，後來有了各平台和程式語言的移植版本，有Java的Android版、有C++跨平台版、有JavaScript的瀏覽器版、cocos2d-html5，以及Objective-C的iPhone版，也就是這裡要講的cocos2d-iphone，以Objective-C寫的，目標平台是iOS（現在也開始支援Mac OS X）。所以，底下提到cocos2d時，指的都是這一套。
這是cocos2d-iphone的logo，快樂的圖案給iOS用，生氣的給Mac用。
cocos2d-iphone的學習資料：
1. cocos2d-iphone的官方網站、原始碼在GitHub上、文件（API、常見問答集、等等）、論壇、開發出來的遊戲列表。
2. 討論遊戲開發的論壇：iPhone Dev SDK討論遊戲的板面、Stack Exchange的遊戲開發QA論壇、等等。
3. 書，Learn iPhone and iPad Cocos2D Game Development，Apress 2010年12月出版，作者Steffen Itterheim。書中用的版本應該是cocos2d 0.99.3。作者不是只出本書就算了，出書前就有專門發表cocos2d遊戲開發的網站、還架設了論壇、錄製教學影片，另外，還把cocos2d與Wax(Lua on Objective-C)、iSimulate、cocos2d-iphone-extensions、cocos3d、SneakyInput、Chipmunk SpaceManager等等整合起來，名為Kobold2D，用起來就更方便了。
更新：這本書的第二版，Learn cocos2d Game Development with iOS 5，2011年11月出版，更新為cocos2d 1.0.1、iOS 5、Xcode 4。
更新：這本書的第三版，Learn cocos2d 2: Game Development for iOS，2012年9月出版，更新為cocos2d 2.0、iOS 5與6、Xcode 4.3與4.4、ARC。似乎會有中文翻譯本。
4. 書，Learning Cocos2D: A Hands-On Guide to Building iOS Games with Cocos2D, Box2D, and Chipmunk，Addison-Wesley 2011年7月出版，作者Rod Strougo與Ray Wenderlich。書中用的版本似乎是cocos2d 0.99.5。作者Ray的部落格在此，上面有很多iOS軟體開發與cocos2d遊戲開發的文章。這本書的官方網站。
中文翻譯本：Cocos2D 遊戲程式開發攻略－動手撰寫你的第一支 iOS 遊戲。
5. 書，Cocos2d for iPhone 0.99 Beginner's Guide，Packt 2011年1月出版，作者Pablo Ruiz。書中用的版本應該是0.99.5之前的。
以上書籍裡所使用的cocos2d版本，多少會跟目前最新的穩定釋出版本不同。請注意，cocos2d有些類別與方法的名稱會改變，譬如在0.99.5裡，CCLabel改名為CCLabelTTF、CCBitmapFontAtlas被CCLabelBMFont取代，所以如果你使用的cocos2d版本與書中不同的話，會遇到這些煩人的差異，詳情請看各版本的release note。不過，1.x已經進入維護狀態，應該不會再有大改變。
6. 書，Cocos2d for iPhone 1 Game Development Cookbook，Packt 2011年11月出版，作者Nathan Burba。
這本稍微進階一點，好書。
7. 書，Learning iOS Game Programming: A Hands-On Guide to Building Your First iPhone Game，Addison-Wesley 2010年9月出版，作者Michael Daley。
這本不是講cocos2d，而是在iOS SDK與OpenGL ES之上開發遊戲，舉個例子，在cocos2d裡，我們有CCLabelBMFont可用來繪製點陣字型，而這本書則是自己寫出程式碼來繪製文字。概略來說，這本書的內容是介紹遊戲開發時的各種概念（sprite sheet、tile map），開發出一套遊戲引擎（書中的程式碼），並實際寫一支遊戲做範例（寫出來的遊戲Sir Lamorak's Quest有放在App Store上）。
有中文翻譯本：學會 iOS 遊戲程式設計的 16 堂課─動手撰寫你的第一隻 iPhone 遊戲。
8. 書，Beginning iOS 5 Games Development: Using the iOS SDK for iPad, iPhone and iPod touch，APress 2011年11月出版，作者Lucas Jordan。
這本不是講cocos2d，而是在iOS之上寫遊戲。
9. iPhone Game Tutorials上有非常多介紹cocos2d寫遊戲的文章，有入門的也有進階的。
10. Cocos2D Podcast，主持人為Mohammad Azam與Steffen Itterheim。
11. 到YouTube上找找cocos2d教學影片。
12. 其他，請留言告訴我。
除了cocos2d外，還有其他遊戲引擎可選，譬如Unity3D、Corona、SIO2、Oolong、Torque、Bork3D、ShiVa 3D、Galaxy、Sparrow、Irrlicht、Game Salad、Unreal Development Kit、Pixelwave、等等，令人眼花撩亂，有2d的有3d的，有免費的有要錢的，有些只支援單一平台、有些支援多重平台。
挑選iOS遊戲引擎時，可以參考以下資料：
1. iPhone Game Engine Comparison – Open Source
2. The Commercial iPhone Game Engine Comparison (3D and 2D)
3. Review of 3D Engines for the iPhone
4. Thoughts on Unity3D
5. Best iPhone Game Frameworks
6. Cocos2d Podcast的Game Engines and Frameworks as Alternatives to Cocos2d
7. Mobile Game Engines，根據你設定的需求找出合適的遊戲引擎。
8. Steffen Itterheim的文章，The Game Engine Dating Guide: How to Pick up an Engine for Single Developers，講解如何挑選遊戲引擎。
9. Battle of the Lua Game Engines: Corona vs. Gideros vs. LÖVE vs. Moai。
10. 其他。
以上資料僅供參考，請注意文章的時效性，某些遊戲引擎可能已經有了長足的進展，某些遊戲引擎可能逐漸式微。
這是cocos2d-iphone的logo，快樂的圖案給iOS用，生氣的給Mac用。
cocos2d-iphone的學習資料：
1. cocos2d-iphone的官方網站、原始碼在GitHub上、文件（API、常見問答集、等等）、論壇、開發出來的遊戲列表。
2. 討論遊戲開發的論壇：iPhone Dev SDK討論遊戲的板面、Stack Exchange的遊戲開發QA論壇、等等。
3. 書，Learn iPhone and iPad Cocos2D Game Development，Apress 2010年12月出版，作者Steffen Itterheim。書中用的版本應該是cocos2d 0.99.3。作者不是只出本書就算了，出書前就有專門發表cocos2d遊戲開發的網站、還架設了論壇、錄製教學影片，另外，還把cocos2d與Wax(Lua on Objective-C)、iSimulate、cocos2d-iphone-extensions、cocos3d、SneakyInput、Chipmunk SpaceManager等等整合起來，名為Kobold2D，用起來就更方便了。
更新：這本書的第二版，Learn cocos2d Game Development with iOS 5，2011年11月出版，更新為cocos2d 1.0.1、iOS 5、Xcode 4。
更新：這本書的第三版，Learn cocos2d 2: Game Development for iOS，2012年9月出版，更新為cocos2d 2.0、iOS 5與6、Xcode 4.3與4.4、ARC。似乎會有中文翻譯本。
4. 書，Learning Cocos2D: A Hands-On Guide to Building iOS Games with Cocos2D, Box2D, and Chipmunk，Addison-Wesley 2011年7月出版，作者Rod Strougo與Ray Wenderlich。書中用的版本似乎是cocos2d 0.99.5。作者Ray的部落格在此，上面有很多iOS軟體開發與cocos2d遊戲開發的文章。這本書的官方網站。
中文翻譯本：Cocos2D 遊戲程式開發攻略－動手撰寫你的第一支 iOS 遊戲。
5. 書，Cocos2d for iPhone 0.99 Beginner's Guide，Packt 2011年1月出版，作者Pablo Ruiz。書中用的版本應該是0.99.5之前的。
以上書籍裡所使用的cocos2d版本，多少會跟目前最新的穩定釋出版本不同。請注意，cocos2d有些類別與方法的名稱會改變，譬如在0.99.5裡，CCLabel改名為CCLabelTTF、CCBitmapFontAtlas被CCLabelBMFont取代，所以如果你使用的cocos2d版本與書中不同的話，會遇到這些煩人的差異，詳情請看各版本的release note。不過，1.x已經進入維護狀態，應該不會再有大改變。
6. 書，Cocos2d for iPhone 1 Game Development Cookbook，Packt 2011年11月出版，作者Nathan Burba。
這本稍微進階一點，好書。
7. 書，Learning iOS Game Programming: A Hands-On Guide to Building Your First iPhone Game，Addison-Wesley 2010年9月出版，作者Michael Daley。
這本不是講cocos2d，而是在iOS SDK與OpenGL ES之上開發遊戲，舉個例子，在cocos2d裡，我們有CCLabelBMFont可用來繪製點陣字型，而這本書則是自己寫出程式碼來繪製文字。概略來說，這本書的內容是介紹遊戲開發時的各種概念（sprite sheet、tile map），開發出一套遊戲引擎（書中的程式碼），並實際寫一支遊戲做範例（寫出來的遊戲Sir Lamorak's Quest有放在App Store上）。
有中文翻譯本：學會 iOS 遊戲程式設計的 16 堂課─動手撰寫你的第一隻 iPhone 遊戲。
8. 書，Beginning iOS 5 Games Development: Using the iOS SDK for iPad, iPhone and iPod touch，APress 2011年11月出版，作者Lucas Jordan。
這本不是講cocos2d，而是在iOS之上寫遊戲。
9. iPhone Game Tutorials上有非常多介紹cocos2d寫遊戲的文章，有入門的也有進階的。
10. Cocos2D Podcast，主持人為Mohammad Azam與Steffen Itterheim。
11. 到YouTube上找找cocos2d教學影片。
12. 其他，請留言告訴我。
除了cocos2d外，還有其他遊戲引擎可選，譬如Unity3D、Corona、SIO2、Oolong、Torque、Bork3D、ShiVa 3D、Galaxy、Sparrow、Irrlicht、Game Salad、Unreal Development Kit、Pixelwave、等等，令人眼花撩亂，有2d的有3d的，有免費的有要錢的，有些只支援單一平台、有些支援多重平台。
挑選iOS遊戲引擎時，可以參考以下資料：
1. iPhone Game Engine Comparison – Open Source
2. The Commercial iPhone Game Engine Comparison (3D and 2D)
3. Review of 3D Engines for the iPhone
4. Thoughts on Unity3D
5. Best iPhone Game Frameworks
6. Cocos2d Podcast的Game Engines and Frameworks as Alternatives to Cocos2d
7. Mobile Game Engines，根據你設定的需求找出合適的遊戲引擎。
8. Steffen Itterheim的文章，The Game Engine Dating Guide: How to Pick up an Engine for Single Developers，講解如何挑選遊戲引擎。
9. Battle of the Lua Game Engines: Corona vs. Gideros vs. LÖVE vs. Moai。
10. 其他。
以上資料僅供參考，請注意文章的時效性，某些遊戲引擎可能已經有了長足的進展，某些遊戲引擎可能逐漸式微。
2011/09/07
寫程式用的字型
2019.11.14更新：我在寫這篇文章時，並沒有考慮字型的授權問題，如商業使用是否要錢，可否在公司內使用。感謝熱心網友Karen Ferrer提供另一篇分享文70+ Best Free Fonts for Designers – Free for Commercial Use in 2019，可找到能用於商業的免費字型，等寬字型在第9節。
這裡列出一些等寬字型（fixed-width or monospaced fonts），主要用於撰寫程式時，以及終端機命令列模式下使用。喜歡與否，見仁見智，大家試試看，自己看的順眼最重要。
挑選時，有些注意事項：
Courier、Courier New
由IBM根據打字機的字型所設計的，因為沒有維護其專利，所以流傳廣泛。
我的感覺：Courier太難看。Courier New中規中矩，筆劃有點細。
下載：各系統上應該都有安裝此字型；Courier New可到這裡找找。
Andale Mono
很多系統預設安裝的字型。
我的感覺：比Courier New好，但有更棒的。
下載：請到這裡。
Monaco、Menlo
Monaco是Apple的Mac作業系統內建的終端機預設字型，在Mac OS X 10.6被Menlo取代。Menlo是由Bitstream Vera Sans Mono改過來的。
我的感覺：不錯，在Mac上嫌麻煩的話就直接用這兩個字型吧。
下載：據我所知，只能在Mac OS上合法使用。
Source Code Pro
Adobe釋出的等寬字型，很不錯。
我的感覺：很不錯。
下載：請到這裡。
ProFont
我的感覺：不錯，推薦。
下載：請到這裡：
Bitstream Vera Sans Mono
我的感覺：整體看起來筆劃夠黑，我喜歡，但是符號*的位置偏上，我不喜歡。
下載：請到這裡。
Deja Vu Sans Mono
由Bitstream Vera Sans Mono改過來的，免費。
我的感覺：很不錯，推薦。整體看起來筆劃夠黑，我喜歡，但是符號*的位置偏上，我不喜歡。
下載：請到這裡。
Monofur
我的感覺：有點古老的味道。
下載：請到這裡。
Inconsolata
我的感覺：很不錯，推薦。單引號與雙引號有點卷曲歪斜，有人不喜歡所以繼續修改，變成Inconsolata-g。
下載：請到這裡。
Anonymous Pro
Mark Simonson設計，免費。
我的感覺：很不錯，推薦。
下載：請到這裡。
參考資料：
這裡列出一些等寬字型（fixed-width or monospaced fonts），主要用於撰寫程式時，以及終端機命令列模式下使用。喜歡與否，見仁見智，大家試試看，自己看的順眼最重要。
挑選時，有些注意事項：
- 英文字母大寫O、小寫o、數字0，必須能夠清楚辨識。
- 英文字母小寫l，大寫I、小寫i，數字1、符號|，必須能夠清楚辨識。
- 符號`與'，必須能夠清楚辨識。
- 字型的筆劃粗細適中。
- 有些字型，設定在某種大小下時，非常漂亮，但可能在放大或縮小後，卻變差了。
Courier、Courier New
由IBM根據打字機的字型所設計的，因為沒有維護其專利，所以流傳廣泛。
我的感覺：Courier太難看。Courier New中規中矩，筆劃有點細。
下載：各系統上應該都有安裝此字型；Courier New可到這裡找找。
Andale Mono
很多系統預設安裝的字型。
我的感覺：比Courier New好，但有更棒的。
下載：請到這裡。
Monaco、Menlo
Monaco是Apple的Mac作業系統內建的終端機預設字型，在Mac OS X 10.6被Menlo取代。Menlo是由Bitstream Vera Sans Mono改過來的。
我的感覺：不錯，在Mac上嫌麻煩的話就直接用這兩個字型吧。
下載：據我所知，只能在Mac OS上合法使用。
Source Code Pro
Adobe釋出的等寬字型，很不錯。
我的感覺：很不錯。
下載：請到這裡。
ProFont
我的感覺：不錯，推薦。
下載：請到這裡：
Bitstream Vera Sans Mono
我的感覺：整體看起來筆劃夠黑，我喜歡，但是符號*的位置偏上，我不喜歡。
下載：請到這裡。
Deja Vu Sans Mono
由Bitstream Vera Sans Mono改過來的，免費。
我的感覺：很不錯，推薦。整體看起來筆劃夠黑，我喜歡，但是符號*的位置偏上，我不喜歡。
下載：請到這裡。
Monofur
我的感覺：有點古老的味道。
下載：請到這裡。
Inconsolata
我的感覺：很不錯，推薦。單引號與雙引號有點卷曲歪斜，有人不喜歡所以繼續修改，變成Inconsolata-g。
下載：請到這裡。
Anonymous Pro
Mark Simonson設計，免費。
我的感覺：很不錯，推薦。
下載：請到這裡。
參考資料：
2011/08/23
MoonScript幾支小程式
這篇要寫幾支MoonScript程式。
關於MoonScript的概觀介紹請看這篇，如何安裝看這篇，完整的MoonScript語言參考手冊在這裡（英文）。
注意：我假設你已經會Lua了。
首先，向世界說聲哈囉吧。
寫一支沒有參數的函式並呼叫它。
輸出：
用->（箭頭）來產生函式，用=（等號）把產生出來的函式指派給func_hello，無參數的函式，除了可以用一般的()括號來呼叫，也可以用!（驚嘆號）來呼叫。而且這支函式的內容只有一個述句(statement)，所以直接寫在->的後面即可。
如果函式內容多於一個述句，要縮排後一行一行放在->之下。
接下來，有參數的函式，要把參數宣告在->之前，以,（逗號）分開，以()括號包起來。
輸出：
func_add有return，func_add2沒有，但兩者是一樣的，這叫做implicit return，函式執行時最後的運算式，會回傳給呼叫者。
函式可以回傳多個值。
輸出：
函式呼叫可省略掉括號。
輸出：
省略括號後，參數會被傳進離它最近的函式，所以上面的7跟8會被傳進func_add。
當情況比較複雜會搞混時，當你想控制誰是誰的參數時，就用()括號來區分。
可以讓參數有預設值。
輸出：
參數預設值的運算式，會一個跟著一個被執行，所以，後面參數可以使用前面參數。
輸出：
接下來，介紹非常好用的table comprehension。過去，第一次看到Python的list comprehension時， 就覺得這玩意兒怎麼這麼強啊，真是太好用了，程式碼會變得更簡短，光一行就能完成超多事情。comprehension就好像把資料結構、迴圈、條件判斷 式通通攪和在一起，是個高階的程式概念，底下，就讓我用MoonScript來練習寫幾支table comprehension的程式吧。
若scores裡面是學生的成績，考的太差了，只好開根號乘以10，調整一下成績，以免當太多人，下次開課會教室不夠大。
首先，宣告變數scores，用{}大括號產生出table，裡面放了五個人的分數，在這裡，我們把table當做array或list來用，也就是說，裡面的項目是逐一排列的。然後，我們要把這個table裡面的項目，一個一個拿出來，也就是for i, s in ipairs scores這段所做的事情，i會是index，從1到5，在這裡沒有用到，s會是那五個成績，拿到成績後，開根號乘以10，算出調整後的成績，然後用[]方括號包起來，這就是comprehension，結果會是一個table，指派給scores_modified。
然後，用迴圈輸出成績，其中s - s%1是取出整數的部分，小數我們就不要了。
讓我們算一算調整前後各有幾個人被當。
同樣使用comprehension，因為逐一取出項目這個動作很常見，所以MoonScript加入一個語法，請看for s in *scores_modified，這個*星號，會等於for i, s in ipairs scores_modified，還有，我們用when來篩選出想要的項目，在這裡是小於60的成績，也就是不及格的，然後把結果放進table stemp裡。
#井號接table，表示table的大小，不過，這只有在我們把table當做array來用時，這個運算子#才會得到正確的結果。
執行看看吧，調整成績後，還有多少人會被當呢？
接下來，MoonScript與Lua有個不一樣的地方，就是if與for不僅是statement，也是expression，意思是說，它們都能回傳值。先看看if。
寫一個函式，給定一個成績參數，判斷是否過關或被當，第二個參數可有可無，若有，表示過關的最低成績，預設值是60。
如果if只是statement，不是expression的話，我們就必須要用上半部那種寫法；但MoonScript是expression，所以就能用下半部那種寫法。這兩種寫法的結果result會是相同的。
接下來看看for可以怎麼用。假設從1到10，奇數就保留，偶數就乘以2，怎麼寫呢？
如果for只是statement，那就要用上半部的寫法，但MoonScript的for也是expression，所以可以用下半部的寫法，for每次迴圈的值，會被收集起來，放進table裡，最後被指配給doubled_evens。所以，這兩種寫法的結果相同。
另外，雖然Lua也可以寫OOP，但沒有直接的語法支援，總是會有礙手礙腳的地方，MoonScript加入了class、inheritance等支援，請你自己看看吧。
關於MoonScript的概觀介紹請看這篇，如何安裝看這篇，完整的MoonScript語言參考手冊在這裡（英文）。
注意：我假設你已經會Lua了。
首先，向世界說聲哈囉吧。
寫一支沒有參數的函式並呼叫它。
func_hello = -> print "hello world"
func_hello!
func_hello()
輸出：
hello world
hello world
用->（箭頭）來產生函式，用=（等號）把產生出來的函式指派給func_hello，無參數的函式，除了可以用一般的()括號來呼叫，也可以用!（驚嘆號）來呼叫。而且這支函式的內容只有一個述句(statement)，所以直接寫在->的後面即可。
如果函式內容多於一個述句，要縮排後一行一行放在->之下。
func_hi = ->
name = "John Smith"
print "Hi, I am " .. name
接下來，有參數的函式，要把參數宣告在->之前，以,（逗號）分開，以()括號包起來。
func_add = (x, y) -> return x + y
func_add2 = (x, y) -> x + y
print(func_add(1, 2))
print(func_add2(3, 4))
輸出：
3
7
func_add有return，func_add2沒有，但兩者是一樣的，這叫做implicit return，函式執行時最後的運算式，會回傳給呼叫者。
函式可以回傳多個值。
power_of_2_3 = (x) -> x*x, x*x*x
a, b = power_of_2_3 5
print a
print b
輸出：
25
125
函式呼叫可省略掉括號。
print(func_add(7, 8))
print func_add 7, 8
輸出：
15
15
省略括號後，參數會被傳進離它最近的函式，所以上面的7跟8會被傳進func_add。
當情況比較複雜會搞混時，當你想控制誰是誰的參數時，就用()括號來區分。
print "9 + 10 =", func_add(9, 10), "11 + 12 =", func_add(11, 12)
可以讓參數有預設值。
func_inc = (a, b=1) -> a + b
print func_inc 10, 5
print func_inc 10
輸出：
15
11
參數預設值的運算式，會一個跟著一個被執行，所以，後面參數可以使用前面參數。
foo = (x=100, y=x+5) -> x + y
print foo!
print foo 95
輸出：
205
195
接下來，介紹非常好用的table comprehension。過去，第一次看到Python的list comprehension時， 就覺得這玩意兒怎麼這麼強啊，真是太好用了，程式碼會變得更簡短，光一行就能完成超多事情。comprehension就好像把資料結構、迴圈、條件判斷 式通通攪和在一起，是個高階的程式概念，底下，就讓我用MoonScript來練習寫幾支table comprehension的程式吧。
若scores裡面是學生的成績，考的太差了，只好開根號乘以10，調整一下成績，以免當太多人，下次開課會教室不夠大。
scores = {64, 33, 25, 38, 48}
scores_modified = [math.sqrt(s) * 10 for i, s in ipairs scores]
print s - s%1 for i, s in ipairs scores_modified
首先，宣告變數scores，用{}大括號產生出table，裡面放了五個人的分數，在這裡，我們把table當做array或list來用，也就是說，裡面的項目是逐一排列的。然後，我們要把這個table裡面的項目，一個一個拿出來，也就是for i, s in ipairs scores這段所做的事情，i會是index，從1到5，在這裡沒有用到，s會是那五個成績，拿到成績後，開根號乘以10，算出調整後的成績，然後用[]方括號包起來，這就是comprehension，結果會是一個table，指派給scores_modified。
然後，用迴圈輸出成績，其中s - s%1是取出整數的部分，小數我們就不要了。
讓我們算一算調整前後各有幾個人被當。
stemp = [s for s in *scores_modified when s < 60]
print #stemp
同樣使用comprehension，因為逐一取出項目這個動作很常見，所以MoonScript加入一個語法，請看for s in *scores_modified，這個*星號，會等於for i, s in ipairs scores_modified，還有，我們用when來篩選出想要的項目，在這裡是小於60的成績，也就是不及格的，然後把結果放進table stemp裡。
#井號接table，表示table的大小，不過，這只有在我們把table當做array來用時，這個運算子#才會得到正確的結果。
執行看看吧，調整成績後，還有多少人會被當呢？
接下來，MoonScript與Lua有個不一樣的地方，就是if與for不僅是statement，也是expression，意思是說，它們都能回傳值。先看看if。
寫一個函式，給定一個成績參數，判斷是否過關或被當，第二個參數可有可無，若有，表示過關的最低成績，預設值是60。
pass_or_fail = (score, score_to_pass = 60) -> score >= score_to_pass
result = ""
if pass_or_fail 60
result = "Pass"
else
result = "Fail"
result = if pass_or_fail 60
"Pass"
else
"Fail"
如果if只是statement，不是expression的話，我們就必須要用上半部那種寫法；但MoonScript是expression，所以就能用下半部那種寫法。這兩種寫法的結果result會是相同的。
接下來看看for可以怎麼用。假設從1到10，奇數就保留，偶數就乘以2，怎麼寫呢？
doubled_evens = {}
for i=1, 10
if i % 2 == 0
doubled_evens[i] = i * 2
else
doubled_evens[i] = i
doubled_evens = for i=1, 10
if i % 2 == 0
i * 2
else
i
如果for只是statement，那就要用上半部的寫法，但MoonScript的for也是expression，所以可以用下半部的寫法，for每次迴圈的值，會被收集起來，放進table裡，最後被指配給doubled_evens。所以，這兩種寫法的結果相同。
另外，雖然Lua也可以寫OOP，但沒有直接的語法支援，總是會有礙手礙腳的地方，MoonScript加入了class、inheritance等支援，請你自己看看吧。
2011/08/22
MoonScript概觀介紹
這一篇把MoonScript的首頁，概略翻譯出來。
MoonScript是個動態腳本語言，以CoffeeScript的語法為基礎，不過，編譯後的語言是Lua。
成功安裝MoonScript後，你會得到：兩支執行檔moon與moonc，以及Lua模組moonscript。使用moon可以直接執行一支MoonScript程式檔；使用moonc可以把MoonScript程式檔編譯轉成Lua程式檔，之後再執行；在Lua程式裡加上require "moonscript"，就能看懂、載入、執行MoonScript檔案了。
因為編譯後的結果是Lua程式碼，所以相容於各種Lua實作，包括LuaJIT，也相容於所有已經寫好的的Lua程式庫。
完整語言的介紹，請見MoonScript語言參考手冊（英文），我也寫了幾支小小的程式。接下來要概略介紹一下，因為我們可把MoonScript想像成為Lua披上並擴充較好看的語法外衣，所以你需要對Lua具有一定程度的了解。
概觀
MoonScript提供簡潔的語法，利用縮排來判斷並分割程式碼的各部分，而不是像Lua一樣使用囉嗦的關鍵字，也不是像C語言一樣使用大括號，利用縮排來定義語法的程式語言，有名的有Python。底下是MoonScript的一些述句構成。
其了較簡潔的語法外，還加入了其他特色，包括table comprehensions、函式裡的implicit return、類別(class)、繼承(inheritance)、scope的管理述句import與export、以及很便利的物件建構述句with。
當有錯誤發生時，它還能指出是在原先檔案裡的哪一行出錯，而不僅是編譯後的檔案。
安裝
最容易的方式是利用LuaRocks，以底下提供的rockspec來安裝：
> luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec
詳細安裝過程，我寫在另外一篇。
選用功能
如果你使用Linux，並且想用watch模式，此模式會監視.moon檔，當有變動時就自動編譯成.lua檔。你需要安裝linotify。
原始碼
專案原始碼放在GitHub上：https://github.com/leafo/moonscript
有任何問題，請到這裡回報：https://github.com/leafo/moonscript/issues
最新的開發版本（或許不能動喔）可以用底下的rockspec安裝：
> luarocks build http://moonscript.org/rocks/moonscript-dev-1.rockspec
相依於其他軟體套件
除了Lua 5.1外，MoonScript還需要底下的Lua模組：
若你使用LuaRocks來安裝MoonScript，這些套件都會被自動取回並安裝。
學習
完整的語言參考手冊（英文）在此。
其他外掛
差異處的概略介紹
關於
MoonScript的語法，有很大程度是被CoffeeScript激發而來的。
沒有LPeg這個超棒超強的語法解析工具，MoonScript是不可能誕生的。
MoonScript是個動態腳本語言，以CoffeeScript的語法為基礎，不過，編譯後的語言是Lua。
成功安裝MoonScript後，你會得到：兩支執行檔moon與moonc，以及Lua模組moonscript。使用moon可以直接執行一支MoonScript程式檔；使用moonc可以把MoonScript程式檔編譯轉成Lua程式檔，之後再執行；在Lua程式裡加上require "moonscript"，就能看懂、載入、執行MoonScript檔案了。
因為編譯後的結果是Lua程式碼，所以相容於各種Lua實作，包括LuaJIT，也相容於所有已經寫好的的Lua程式庫。
完整語言的介紹，請見MoonScript語言參考手冊（英文），我也寫了幾支小小的程式。接下來要概略介紹一下，因為我們可把MoonScript想像成為Lua披上並擴充較好看的語法外衣，所以你需要對Lua具有一定程度的了解。
概觀
MoonScript提供簡潔的語法，利用縮排來判斷並分割程式碼的各部分，而不是像Lua一樣使用囉嗦的關鍵字，也不是像C語言一樣使用大括號，利用縮排來定義語法的程式語言，有名的有Python。底下是MoonScript的一些述句構成。
export my_func
x = 2323
collection =
height: 32434
hats: {"tophat", "bball", "bowler"}
my_func = (a) -> x + a
print my_func 100
其了較簡潔的語法外，還加入了其他特色，包括table comprehensions、函式裡的implicit return、類別(class)、繼承(inheritance)、scope的管理述句import與export、以及很便利的物件建構述句with。
import concat, insert from table
double_args = (...) ->
[x * 2 for x in *{...}]
tuples = [{k, v} for k,v in ipairs my_table]
當有錯誤發生時，它還能指出是在原先檔案裡的哪一行出錯，而不僅是編譯後的檔案。
安裝
最容易的方式是利用LuaRocks，以底下提供的rockspec來安裝：
> luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec
詳細安裝過程，我寫在另外一篇。
選用功能
如果你使用Linux，並且想用watch模式，此模式會監視.moon檔，當有變動時就自動編譯成.lua檔。你需要安裝linotify。
原始碼
專案原始碼放在GitHub上：https://github.com/leafo/moonscript
有任何問題，請到這裡回報：https://github.com/leafo/moonscript/issues
最新的開發版本（或許不能動喔）可以用底下的rockspec安裝：
> luarocks build http://moonscript.org/rocks/moonscript-dev-1.rockspec
相依於其他軟體套件
除了Lua 5.1外，MoonScript還需要底下的Lua模組：
- linotify（在Linux上的選用功能）
若你使用LuaRocks來安裝MoonScript，這些套件都會被自動取回並安裝。
學習
完整的語言參考手冊（英文）在此。
其他外掛
差異處的概略介紹
- 利用縮排與空白字元來定義出程式區塊
- 所有變數宣告，預設為區域變數。
- 用export關鍵字來宣告全域變數，用import關鍵字來匯入table裡的東西，也就是取得一份區域性的拷貝。
- 函式呼叫時，括號是可有可無的，類似於Ruby。
- 胖箭頭，=>，用來產生具有self參數的函式。
- 在名稱之前加上@（小老鼠），用來指稱它是個self裡的東西。
- 運算子!（驚嘆號），可用來呼叫無參數的函式。
- 根據函式裡最後一個述句的型別，自動加上implicit return。
- 使用:（冒號）來分開table裡的鍵與值，而不是用=（等號）。
- 換行(newline)可用來區分開table裡的每一項目，逗號(,)也可以。
- 用\（反斜線）來呼叫物件的方法，而不是用:（冒號）。
- 支援+=、-=、/=、*=、%=運算子。
- !=是~=的別名。
- table comprehension，很便利的slicing與iterator語法。
- 程式碼若一行，可以在後面加上迴圈與if述句。
- if述句，可當做運算式使用。
- 具有繼承的類別系統，建構在metatable __index屬性之上。
- 建構子的參數，若以@開頭，會自動指定給物件。
- 魔法般的super函式，將同名的類別方法對應到父類別的方法。
- with述句，讓你以較短的語法存取無名的物件。
關於
MoonScript的語法，有很大程度是被CoffeeScript激發而來的。
沒有LPeg這個超棒超強的語法解析工具，MoonScript是不可能誕生的。
2011/08/21
MoonScript安裝
這一篇要講如何安裝MoonScript，至於概觀介紹可看這一篇。
我先試著在Windows XP與Cygwin上安裝，但都沒有成功，MoonScript作者也說他主要的開發平台是Linux，所以我才在我的小白Mac OS X 10.6.8上安裝，滿順利的，後來又在Windows XP裡的VirtualBox裝Ubuntu 11.04，也滿順利的。
概略步驟如下：
1. 安裝Lua
2. 安裝LuaRocks
3. 安裝MoonScript（其中某部分需要安裝git）
在Windows上的安裝過程：
我沒有成功，你可以參考這一篇，看看眾多複雜的過程，以及最後出現的問題。
在Ubuntu上的安裝過程：
因為軟體都以套件打包好了，所以安裝很順利。
1. 安裝Lua
sudo apt-get install lua5.1
2. 安裝LuaRocks
sudo apt-get install luarocks
3. 安裝MoonScript（其中某部分需要安裝git）
sudo apt-get install git（若你沒有安裝過git的話）
然後以LuaRocks安裝MoonScript（底下這行指令是MoonScript官方網站寫的）：
luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec
MoonScript需要LPeg、LuaFileSystem、alt-getopt這三個套件，所以會先安裝它們。
安裝成功後，moon跟moonc這兩個執行檔會在~/.luarocks/bin/下。
在Mac OS X上的安裝過程：
1. 安裝Lua
到官方網站的下載區下載原始碼，我下載安裝的版本是lua-5.1.4.tar.gz。
tar zxvf lua-5.1.4.tar.gz，解壓縮。
cd lua-5.1.4，進解壓縮後的目錄裡。
make macosx，建構。
make install (sudo make install)，安裝。
預設值會安裝到/usr/local下，執行檔（lua與luac）在bin底下，其他檔案散佈在include、lib、man、share底下。
2. 安裝LuaRocks
到官方網站下載，我下載的是luarocks-2.0.5.tar.gz，
tar zxvf luarocks-2.0.5.tar.gz，解壓縮。
cd luarocks-2.0.5，進解壓縮後的目錄裡。
./configure
make
sudo make install
預設值會安裝到/usr/local下，執行檔（luarocks與luarocks-admin）在bin底下。
3. 安裝MoonScript（其中某部分需要安裝git）
到這裡抓取Mac OS X的git安裝程式，按照下載後的dmg檔裡面的README.txt的指示安裝。
然後以LuaRocks安裝MoonScript（底下這行指令是MoonScript官方網站寫的）：
luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec
MoonScript相依於LPeg、LuaFileSystem、alt-getopt這三個套件，所以會先安裝它們。
安裝成功的話，最後應該會出現如下的訊息：
moonscript 0.1.0-1 is now built and installed in /usr/local/ (license: MIT)
moon a.moon to run moonscript script file
moonc a.moon to compile it to lua code
moon跟moonc這兩個執行檔會在/usr/local/bin/下。
接下來就是寫MoonScript的程式，附檔名用.moon，以"moon xyz.moon"來直接執行，或是以"moonc xyz.moon"把MoonScript程式轉成Lua程式。請確定moon與moonc這兩支執行檔有在你的執行路徑PATH下。
完整的語言參考手冊在這裡（英文）。
我先試著在Windows XP與Cygwin上安裝，但都沒有成功，MoonScript作者也說他主要的開發平台是Linux，所以我才在我的小白Mac OS X 10.6.8上安裝，滿順利的，後來又在Windows XP裡的VirtualBox裝Ubuntu 11.04，也滿順利的。
概略步驟如下：
1. 安裝Lua
2. 安裝LuaRocks
3. 安裝MoonScript（其中某部分需要安裝git）
在Windows上的安裝過程：
我沒有成功，你可以參考這一篇，看看眾多複雜的過程，以及最後出現的問題。
在Ubuntu上的安裝過程：
因為軟體都以套件打包好了，所以安裝很順利。
1. 安裝Lua
sudo apt-get install lua5.1
2. 安裝LuaRocks
sudo apt-get install luarocks
3. 安裝MoonScript（其中某部分需要安裝git）
sudo apt-get install git（若你沒有安裝過git的話）
然後以LuaRocks安裝MoonScript（底下這行指令是MoonScript官方網站寫的）：
luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec
MoonScript需要LPeg、LuaFileSystem、alt-getopt這三個套件，所以會先安裝它們。
安裝成功後，moon跟moonc這兩個執行檔會在~/.luarocks/bin/下。
在Mac OS X上的安裝過程：
1. 安裝Lua
到官方網站的下載區下載原始碼，我下載安裝的版本是lua-5.1.4.tar.gz。
tar zxvf lua-5.1.4.tar.gz，解壓縮。
cd lua-5.1.4，進解壓縮後的目錄裡。
make macosx，建構。
make install (sudo make install)，安裝。
預設值會安裝到/usr/local下，執行檔（lua與luac）在bin底下，其他檔案散佈在include、lib、man、share底下。
2. 安裝LuaRocks
到官方網站下載，我下載的是luarocks-2.0.5.tar.gz，
tar zxvf luarocks-2.0.5.tar.gz，解壓縮。
cd luarocks-2.0.5，進解壓縮後的目錄裡。
./configure
make
sudo make install
預設值會安裝到/usr/local下，執行檔（luarocks與luarocks-admin）在bin底下。
3. 安裝MoonScript（其中某部分需要安裝git）
到這裡抓取Mac OS X的git安裝程式，按照下載後的dmg檔裡面的README.txt的指示安裝。
然後以LuaRocks安裝MoonScript（底下這行指令是MoonScript官方網站寫的）：
luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec
MoonScript相依於LPeg、LuaFileSystem、alt-getopt這三個套件，所以會先安裝它們。
安裝成功的話，最後應該會出現如下的訊息：
moonscript 0.1.0-1 is now built and installed in /usr/local/ (license: MIT)
moon a.moon to run moonscript script file
moonc a.moon to compile it to lua code
moon跟moonc這兩個執行檔會在/usr/local/bin/下。
接下來就是寫MoonScript的程式，附檔名用.moon，以"moon xyz.moon"來直接執行，或是以"moonc xyz.moon"把MoonScript程式轉成Lua程式。請確定moon與moonc這兩支執行檔有在你的執行路徑PATH下。
完整的語言參考手冊在這裡（英文）。
2011/08/01
神偷天下（by 鄭丰）讀後感
注意：內有惡犬（劇情），請慎入。
注意：基本上這是一篇寫給自己的讀後感，拜讀鄭丰三部作品後把想法記錄下來；但這不是為了推薦此小說所寫的介紹文章，所以，如果你還沒看過此書，我想，還是不要往下看這篇文章比較好。
書名：神偷天下（共三卷）
作者：鄭丰
出版社：奇幻基地
昨日到書局走走逛逛，要啟程回家之時，才突然瞥見這套鄭丰的新作，心中覺得奇怪，怎麼沒在其他家書店發現呢，一看書後的出版日期，7月28日初版一刷，這可是熱騰騰的新書啊，或許其他書店尚未到貨上架吧，話不多說，立刻帶走（喂，小子，要先付錢啊）。
主角是個小偷，不過從書名可知，必定不會單純是個雞鳴狗盜之輩，內文一開始也引用了莊子的“竊鉤者誅，竊國者侯”詞句，隱隱指出主角會扮演影響整個國家舉足輕重的角色。
本書的年代設定在靈劍之前，所以間或提及在天觀雙俠與靈劍中出現的前輩人物，諸如醫仙、文風流、神卜子、虎俠、雪豔、胡兒、百花仙子、丐幫趙漫、青幫成傲理等等，譬如醫仙為主角治傷、百花仙子取走萬蟲噬心蠱等情結，但出現篇幅不算多，情節描寫概略敘述帶過，說到底，主角其實不算個武林人物，共三本的頁數裡，第一本前半花在主角的出身，以偷盜為業的三家村，後半開始，主角便在東廠、皇宮、錦衣衛四處周旋，第二本作者讓主角遠離京城，跑到了邊蠻之地，瑤族、苗族、蛇族、大越國（交趾）等地，第三本再回到京城，主角打交道的角色，都是皇宮朝廷的人物，太監、貴妃、皇帝、太子、將軍、錦衣衛等等，雖然有虎俠這個武林中人對主角與情節發展有重要的影響，但畢竟不是重點所在，主角的所作所為，最終將會盜取天下，但又不是給自己，而是幫賢明的太子在爾虞我詐危機四伏的處境裡登上皇位，最後還犧牲自己的性命換取太子的壽命。老實說，我覺得，這真的是個很奇怪很奇怪的設定。
主角的能力，就是超高明的飛技與取技，也就是輕功與盜竊的技巧，不過武功就很普普通通了，書中主角最常做的事情，就是潛伏在他人宅邸，竊聽情報，不論是皇宮禁城還是監牢，來去自如無影無蹤，但這麼一來，就有別於一般武俠小說主角的行事與情節發展的過程了，譬如尋秦記的項少龍，作者會“偶爾”讓他偷聽到敵人的陰謀，以便扭轉情勢反將一軍，但本書卻是以竊聽為主軸，生於黑夜行跡隱密，倒掛屋樑絕無聲息，花上時間就能聽到敵方的詭計，一切都在主角的掌握之中，這會不會太方便了啊？段獨聖與凌霄有特異功能，那是種能顛覆整個世界的能力，所以靈劍要花上篇幅來介紹、處理（後來也把靈能毀去），本書主角有此超隱密的能力，而且無往不利，每每都能竊取到需要的情報，但到了最後的最後，卻沒能竊聽找出敵人的陰謀，以致於，主角要賠上自己的性命換取太子的壽命，這會不會太奇怪了啊，怎麼偏偏到了最後會竊聽不到呢？“偷聽”這回事，似乎在武俠小說裡在情節安排上免不了要出現，但如果要讓它常常出現，如我所說的，那就會跟一般武俠小說的基本設定不一樣，需要好好安排啊，不然會讓人（我）覺得不合理。
我看了尋秦記小說好幾遍，也看了電視劇，古天樂演的真不錯。
在天觀雙俠裡，有對於使毒精采的描寫，讓我眼睛一亮。本書中雖有對於偷盜的描寫，開鎖、陷阱、暗格、密室等等，但我沒有覺得太特別，難道是因為我看過鬼吹燈盜墓的小說嗎，所以，雖然本書有描寫了一些特殊練功的法門、各種寶物的來歷與介紹、竊取時的情境與過程、盜之有道的敘述，不過，或許是因為已經看過盜墓小說裡誇張有趣、天馬行空、荒誕不經的描寫，以致於看這本書時但並沒有讓我感到太特別。
另外，在第二本裡，主角跑進了邊荒之地，到一望無盡的靛海（叢林）裡去冒險了，有拜蜘蛛的瑤族與操控蛇群的蛇族、有天下奇物血翠杉，與老虎搏鬥、中了蜈蚣毒，還到了大越國（越南），幫國王黎灝攻下占城，還中了蠱毒，作了苗族苦力，參與了苗族巫王的爭鬥，雖然過程描寫的不錯，但我總有一種感覺：為什麼要有這些情節呢？為了要描寫主角與百里緞的情感糾結嗎，為了要詳細描寫主角的個性嗎，為了鋪下後文所以要介紹苗族的蠱毒嗎，為了除了描寫中原也寫寫邊疆地帶的風土民情嗎，種種問題在我腦里盤旋不休，對了，同前，因為看過了鬼吹燈到雲南、湘西、西域各地異想天開的冒險故事，以至於，這第二本並沒有讓我感到新奇有趣。
覺得神偷天下第二本裡的歷險故事很有趣嗎？可以看看鬼吹燈系列與其他相似的作品喔。
第三本，要開始進入結局了，主角得知他的身世卻又帶來給他甩脫不去的煩惱，亂七八糟的皇宮、東廠西廠權力傾軋勾心鬥角，主角為保太子不得不做盡壞事，差點被被虎俠所殺，不過，都不算是一般武俠小說的情結（啊，對了，是我搞錯了，這部作品不是武俠類的），愚昧的皇帝、擅權的貴妃、互別苗頭的太監們，我讀這些劇情，並沒有什麼感覺，讀著主角的發展，倒是總有一股很怪異的感覺，主角的個性，作者應該算是有描寫出來了，但我又覺得怪怪的，抓不住他到底是個怎麼樣的人啊，極度壓抑嗎，捨己為人嗎，因為備嘗艱辛所以一心要助太子登基讓這個世界更美好嗎，他的所做所有最後終於偷到了天下，但最後自己也死了，這是怎麼樣的一個人物啊，雖然作者從一開始就極細心地描寫，劇情人物與心境轉折都有寫出來，不過我卻不太能領略，或者是因為主角是個我不能代入的角色吧，不能將自己想像成主角，也就不能想像出那是個怎麼樣的情形，也就不能了解主角是作者所說的，是個活在無可奈何的情境下、身不由己的人物。
作者在後記中寫著，天觀雙俠是歡快的，靈劍是悲壯的，神偷天下是沉鬱的，我深有所感，神偷裡的人物，似乎沒有一個是能讓人高興快樂起來的，看著看著心情會變得很糟糕，作者又說，心境變了、作品也不斷轉型，以前，大家說金庸的鹿鼎記不是武俠小說，現在，我也認為神偷天下不像是武俠小說了。
注意：基本上這是一篇寫給自己的讀後感，拜讀鄭丰三部作品後把想法記錄下來；但這不是為了推薦此小說所寫的介紹文章，所以，如果你還沒看過此書，我想，還是不要往下看這篇文章比較好。
書名：神偷天下（共三卷）
作者：鄭丰
出版社：奇幻基地
昨日到書局走走逛逛，要啟程回家之時，才突然瞥見這套鄭丰的新作，心中覺得奇怪，怎麼沒在其他家書店發現呢，一看書後的出版日期，7月28日初版一刷，這可是熱騰騰的新書啊，或許其他書店尚未到貨上架吧，話不多說，立刻帶走（喂，小子，要先付錢啊）。
主角是個小偷，不過從書名可知，必定不會單純是個雞鳴狗盜之輩，內文一開始也引用了莊子的“竊鉤者誅，竊國者侯”詞句，隱隱指出主角會扮演影響整個國家舉足輕重的角色。
本書的年代設定在靈劍之前，所以間或提及在天觀雙俠與靈劍中出現的前輩人物，諸如醫仙、文風流、神卜子、虎俠、雪豔、胡兒、百花仙子、丐幫趙漫、青幫成傲理等等，譬如醫仙為主角治傷、百花仙子取走萬蟲噬心蠱等情結，但出現篇幅不算多，情節描寫概略敘述帶過，說到底，主角其實不算個武林人物，共三本的頁數裡，第一本前半花在主角的出身，以偷盜為業的三家村，後半開始，主角便在東廠、皇宮、錦衣衛四處周旋，第二本作者讓主角遠離京城，跑到了邊蠻之地，瑤族、苗族、蛇族、大越國（交趾）等地，第三本再回到京城，主角打交道的角色，都是皇宮朝廷的人物，太監、貴妃、皇帝、太子、將軍、錦衣衛等等，雖然有虎俠這個武林中人對主角與情節發展有重要的影響，但畢竟不是重點所在，主角的所作所為，最終將會盜取天下，但又不是給自己，而是幫賢明的太子在爾虞我詐危機四伏的處境裡登上皇位，最後還犧牲自己的性命換取太子的壽命。老實說，我覺得，這真的是個很奇怪很奇怪的設定。
主角的能力，就是超高明的飛技與取技，也就是輕功與盜竊的技巧，不過武功就很普普通通了，書中主角最常做的事情，就是潛伏在他人宅邸，竊聽情報，不論是皇宮禁城還是監牢，來去自如無影無蹤，但這麼一來，就有別於一般武俠小說主角的行事與情節發展的過程了，譬如尋秦記的項少龍，作者會“偶爾”讓他偷聽到敵人的陰謀，以便扭轉情勢反將一軍，但本書卻是以竊聽為主軸，生於黑夜行跡隱密，倒掛屋樑絕無聲息，花上時間就能聽到敵方的詭計，一切都在主角的掌握之中，這會不會太方便了啊？段獨聖與凌霄有特異功能，那是種能顛覆整個世界的能力，所以靈劍要花上篇幅來介紹、處理（後來也把靈能毀去），本書主角有此超隱密的能力，而且無往不利，每每都能竊取到需要的情報，但到了最後的最後，卻沒能竊聽找出敵人的陰謀，以致於，主角要賠上自己的性命換取太子的壽命，這會不會太奇怪了啊，怎麼偏偏到了最後會竊聽不到呢？“偷聽”這回事，似乎在武俠小說裡在情節安排上免不了要出現，但如果要讓它常常出現，如我所說的，那就會跟一般武俠小說的基本設定不一樣，需要好好安排啊，不然會讓人（我）覺得不合理。
我看了尋秦記小說好幾遍，也看了電視劇，古天樂演的真不錯。
在天觀雙俠裡，有對於使毒精采的描寫，讓我眼睛一亮。本書中雖有對於偷盜的描寫，開鎖、陷阱、暗格、密室等等，但我沒有覺得太特別，難道是因為我看過鬼吹燈盜墓的小說嗎，所以，雖然本書有描寫了一些特殊練功的法門、各種寶物的來歷與介紹、竊取時的情境與過程、盜之有道的敘述，不過，或許是因為已經看過盜墓小說裡誇張有趣、天馬行空、荒誕不經的描寫，以致於看這本書時但並沒有讓我感到太特別。
另外，在第二本裡，主角跑進了邊荒之地，到一望無盡的靛海（叢林）裡去冒險了，有拜蜘蛛的瑤族與操控蛇群的蛇族、有天下奇物血翠杉，與老虎搏鬥、中了蜈蚣毒，還到了大越國（越南），幫國王黎灝攻下占城，還中了蠱毒，作了苗族苦力，參與了苗族巫王的爭鬥，雖然過程描寫的不錯，但我總有一種感覺：為什麼要有這些情節呢？為了要描寫主角與百里緞的情感糾結嗎，為了要詳細描寫主角的個性嗎，為了鋪下後文所以要介紹苗族的蠱毒嗎，為了除了描寫中原也寫寫邊疆地帶的風土民情嗎，種種問題在我腦里盤旋不休，對了，同前，因為看過了鬼吹燈到雲南、湘西、西域各地異想天開的冒險故事，以至於，這第二本並沒有讓我感到新奇有趣。
覺得神偷天下第二本裡的歷險故事很有趣嗎？可以看看鬼吹燈系列與其他相似的作品喔。
第三本，要開始進入結局了，主角得知他的身世卻又帶來給他甩脫不去的煩惱，亂七八糟的皇宮、東廠西廠權力傾軋勾心鬥角，主角為保太子不得不做盡壞事，差點被被虎俠所殺，不過，都不算是一般武俠小說的情結（啊，對了，是我搞錯了，這部作品不是武俠類的），愚昧的皇帝、擅權的貴妃、互別苗頭的太監們，我讀這些劇情，並沒有什麼感覺，讀著主角的發展，倒是總有一股很怪異的感覺，主角的個性，作者應該算是有描寫出來了，但我又覺得怪怪的，抓不住他到底是個怎麼樣的人啊，極度壓抑嗎，捨己為人嗎，因為備嘗艱辛所以一心要助太子登基讓這個世界更美好嗎，他的所做所有最後終於偷到了天下，但最後自己也死了，這是怎麼樣的一個人物啊，雖然作者從一開始就極細心地描寫，劇情人物與心境轉折都有寫出來，不過我卻不太能領略，或者是因為主角是個我不能代入的角色吧，不能將自己想像成主角，也就不能想像出那是個怎麼樣的情形，也就不能了解主角是作者所說的，是個活在無可奈何的情境下、身不由己的人物。
作者在後記中寫著，天觀雙俠是歡快的，靈劍是悲壯的，神偷天下是沉鬱的，我深有所感，神偷裡的人物，似乎沒有一個是能讓人高興快樂起來的，看著看著心情會變得很糟糕，作者又說，心境變了、作品也不斷轉型，以前，大家說金庸的鹿鼎記不是武俠小說，現在，我也認為神偷天下不像是武俠小說了。
2011/07/30
[廣告] Embedded Linux 嵌入式系統開發實務 第二版
嗨，我翻譯了一本書，在這裡打打廣告。
書名：Embedded Linux 嵌入式系統開發實務 第二版
原書名： Embedded Linux Primer: A Practical Real-World Approach 2/E
作者：Christopher Hallinan
譯者：我
出版社：旗標
這是一本嵌入式 Linux 系統的入門實務手冊，作者憑藉著極為豐富的經驗，廣泛且詳盡地介紹嵌入式 Linux 系統裡各個需要研習的主題，包括：處理器、Linux 核心、初始化的過程、bootloader 開機載入程式、驅動程式、檔案系統、BusyBox、開發環境與工具、除錯技巧、建構系統、即時作業、udev等等，手上擁有這麼一本書，就能一窺嵌入式系統的堂奧，進而繼續深入研究。
本書從下到上、從硬體到軟體，都能深入淺出地加以著墨解釋，書中使用了各種範例，譬如Beagleboard、ARM XScale 平台，讓你了解眾多平台其相同與不同處，作者將多年業界戰績提煉出來，在書裡各個角落常常有一字千金的寶貴經驗談，可千萬小心不要錯過了。
書中每一章的最後一小節，作者都盡責地附上延伸閱讀與參考資料，這是非常重要的，因為以一本書的篇幅，不可能把嵌入式 Linux 系統的所有細節通通涵蓋，有了作者細心挑選出來的著作，讀者可以進一步鑽研某主題。
本書原文書是本非常棒的好書，銷售量據說是市場上數一數二的，翻譯時我盡量秉持著技術正確且語句通順的原則，讓大家看到的是一本中文書而不是英式中文，還希望我的翻譯能夠讓大家滿意。
最後在此感謝能有這個機會來翻譯這本好書，也感謝翻譯過程中前後兩位編輯（黃先生、張先生）的細心與付出。
相關連結：
1. 旗標網站關於此書的介紹。
2. 天瓏書局。
3. 博客來、金石堂。
4. 原文書的網站。
勘誤表：
2-17，2.3.4小節上面那一段的最後一句。少了中文翻譯。
把"(MTD)"改成"(記憶體技術設備, MTD)"
2-28，最下面。參考書籍的書名與作者名弄混了
把"Bruce Perens Prentice"改成"Bruce Perens"
把"Hall"改成"Prentice Hall"
4-22，表格4-6
仍然有些地方因為太長而被強迫斷行，有些地方沒有對齊。
7-42，7.6.3第一段。標點符號錯了
"Micromonitor："的冒號改成分號"；"
"：LinuxBIOS"的冒號改成分號"；"
9-5，列表9-2最後面
"180"跟"days,..."應該在同一行
9-11，最下面的命令列
提示符號跟指令之間應該有個空白
把"$tune2fs"改成"$ tune2fs"
10-2，第一段。打字錯誤。
把"底階"改成"低階"
10-7，最上面第四行。文句不順。
把"跟 loopback 裝置不同的, 是被複製"改成"跟 loopback 裝置不同的是, 被複製"
書名：Embedded Linux 嵌入式系統開發實務 第二版
原書名： Embedded Linux Primer: A Practical Real-World Approach 2/E
作者：Christopher Hallinan
譯者：我
出版社：旗標
這是一本嵌入式 Linux 系統的入門實務手冊，作者憑藉著極為豐富的經驗，廣泛且詳盡地介紹嵌入式 Linux 系統裡各個需要研習的主題，包括：處理器、Linux 核心、初始化的過程、bootloader 開機載入程式、驅動程式、檔案系統、BusyBox、開發環境與工具、除錯技巧、建構系統、即時作業、udev等等，手上擁有這麼一本書，就能一窺嵌入式系統的堂奧，進而繼續深入研究。
本書從下到上、從硬體到軟體，都能深入淺出地加以著墨解釋，書中使用了各種範例，譬如Beagleboard、ARM XScale 平台，讓你了解眾多平台其相同與不同處，作者將多年業界戰績提煉出來，在書裡各個角落常常有一字千金的寶貴經驗談，可千萬小心不要錯過了。
書中每一章的最後一小節，作者都盡責地附上延伸閱讀與參考資料，這是非常重要的，因為以一本書的篇幅，不可能把嵌入式 Linux 系統的所有細節通通涵蓋，有了作者細心挑選出來的著作，讀者可以進一步鑽研某主題。
本書原文書是本非常棒的好書，銷售量據說是市場上數一數二的，翻譯時我盡量秉持著技術正確且語句通順的原則，讓大家看到的是一本中文書而不是英式中文，還希望我的翻譯能夠讓大家滿意。
最後在此感謝能有這個機會來翻譯這本好書，也感謝翻譯過程中前後兩位編輯（黃先生、張先生）的細心與付出。
相關連結：
1. 旗標網站關於此書的介紹。
2. 天瓏書局。
3. 博客來、金石堂。
4. 原文書的網站。
勘誤表：
2-17，2.3.4小節上面那一段的最後一句。少了中文翻譯。
把"(MTD)"改成"(記憶體技術設備, MTD)"
2-28，最下面。參考書籍的書名與作者名弄混了
把"Bruce Perens Prentice"改成"Bruce Perens"
把"Hall"改成"Prentice Hall"
4-22，表格4-6
仍然有些地方因為太長而被強迫斷行，有些地方沒有對齊。
7-42，7.6.3第一段。標點符號錯了
"Micromonitor："的冒號改成分號"；"
"：LinuxBIOS"的冒號改成分號"；"
9-5，列表9-2最後面
"180"跟"days,..."應該在同一行
9-11，最下面的命令列
提示符號跟指令之間應該有個空白
把"$tune2fs"改成"$ tune2fs"
10-2，第一段。打字錯誤。
把"底階"改成"低階"
10-7，最上面第四行。文句不順。
把"跟 loopback 裝置不同的, 是被複製"改成"跟 loopback 裝置不同的是, 被複製"
2011/07/29
[廣告] 馬上就能用! iPhone SDK 程式碼即可貼
嗨，我朋友翻譯了一本書，在這裡打打廣告。
書名：馬上就能用! iPhone SDK 程式碼即可貼
作者：高山恭介、広部一弥、松浦晃洋
譯者：我朋友負責翻譯，我負責審校程式碼的部份。
出版社：旗標
這是一本iPhone開發超好用的工具書，因為你需要的功能十之八九已經有人寫過了！書中有113招，都是寫好的程式碼，直接用，又快又省時！
市面上有很多 iPhone SDK 程式開發的入門書，這些書都教我們從無到有的學習寫程式，然而，一旦實際開發程式，卻碰到很多需要自己解決的問題──例如「該怎麼鎖住畫面不讓他旋轉」等等...這類問題接連地發生，難道得花時間一一從頭寫起？
本書是以開發過程中常需要的小功能為主題，像是Xcode專案管理的小技巧、Objective-C程式撰寫的訣竅、UIKit使用介面的過場效果與動畫效果、如何處理圖片、音效音樂播放與錄音、硬體版本與功能的判別、網路連線的小訣竅、資料庫SQLite的注意事項、各種外部函式庫的使用等等，這些功能其實已經有人寫過了！你可以隨時拿這些程式碼兜在自己的程式中，而不必自己再花時間找資料研究如何撰寫，大大節省程式開發的時間！
書中內容皆為常見的問題，作者一一整理加以介紹解說，可以省下你大把的寶貴開發時間，這是一本非常有用的好書。
相關連結：
1. 旗標網站關於此書的介紹。
2. 天瓏書局。
3. 博客來、金石堂。
書名：馬上就能用! iPhone SDK 程式碼即可貼
作者：高山恭介、広部一弥、松浦晃洋
譯者：我朋友負責翻譯，我負責審校程式碼的部份。
出版社：旗標
這是一本iPhone開發超好用的工具書，因為你需要的功能十之八九已經有人寫過了！書中有113招，都是寫好的程式碼，直接用，又快又省時！
市面上有很多 iPhone SDK 程式開發的入門書，這些書都教我們從無到有的學習寫程式，然而，一旦實際開發程式，卻碰到很多需要自己解決的問題──例如「該怎麼鎖住畫面不讓他旋轉」等等...這類問題接連地發生，難道得花時間一一從頭寫起？
本書是以開發過程中常需要的小功能為主題，像是Xcode專案管理的小技巧、Objective-C程式撰寫的訣竅、UIKit使用介面的過場效果與動畫效果、如何處理圖片、音效音樂播放與錄音、硬體版本與功能的判別、網路連線的小訣竅、資料庫SQLite的注意事項、各種外部函式庫的使用等等，這些功能其實已經有人寫過了！你可以隨時拿這些程式碼兜在自己的程式中，而不必自己再花時間找資料研究如何撰寫，大大節省程式開發的時間！
書中內容皆為常見的問題，作者一一整理加以介紹解說，可以省下你大把的寶貴開發時間，這是一本非常有用的好書。
相關連結：
1. 旗標網站關於此書的介紹。
2. 天瓏書局。
3. 博客來、金石堂。
2011/07/23
翻譯：Xcode裡要用哪支編譯器─GCC還是LLVM？（Compiler Options in Xcode - GCC or LLVM? ）by Keith Harrison
文章：Compiler Options in Xcode - GCC or LLVM?（Xcode裡要用哪支編譯器─GCC還是LLVM？）
日期：2011.03.21，
作者：Keith Harrison
作者的部落格：Use Your Loaf
作者簡介：
任職某IT公司，下班後在iPhone上開發，以及在mac上使用Ruby on Rails。
Xcode裡要用哪支編譯器─GCC還是LLVM？（Compiler Options in Xcode - GCC or LLVM?）
如果你用的Xcode是3.x版，而且還沒摸過改過專案裡的建置設定，那麼，你用的編譯器大概還是GNU Compiler Collection(GCC)。蘋果公司對GCC所投注的維護人力正緩慢地抽離減少，而且逐步轉移到一套嶄新的編譯器技術上，Low Level Virtual Machine(LLVM)，這是一個開放原始碼的專案。築基LLVM之上的開發工具，Xcode 3跟4都有（有些許差異），所以，不必等你過渡到Xcode 4，在那之前就可以開始享受LLVM帶來的好處。
LLVM計畫
所謂的LLVM計畫，是一套開放原始碼的工具組（完整列表請見LLVM.org），建構在一組核心函式庫之上，這組函式庫提供了optimizer（程式碼優化器）與code generator（機械碼產生器），LLVM計畫裡的其他工具還包括，Clang frontend parser（前端語法解析器）與LLDB debugger（除錯器）。Xcode利用了這一套模組化的作法來提供新功能，譬如，加強syntax highlighting（語法加亮、上色）、提供撰碼時常見錯誤的修正建議。
當我寫這篇時，GCC還是Xcode 3裡預設的編譯器，但Xcode 4釋出後，新建專案預設的編譯器改為LLVM-GCC。在這篇裡，我要來檢視一下Xcode 3、4可用的選項。
Xcode裡的編譯器選項(Compiler Options)
在Xcode裡，透過建置設定(build settings)來更改專案(project)或目標(target)的編譯器選項，版本3跟版本4的編譯器選項，有著些許差異，請看：
實務上，我們有三個選擇，看你要繼續用GCC、改用LLVM、或是混著用以取得向後相容性，GCC 4.0就不提了，因為已被揚棄不用了，在Xcode 4裡也看不見了，底下這張圖秀出三種選項的不同處：
各選項背後所代表的意涵有些許差異，看你的Xcode是3還是4，還有，看你是以iOS還是Mac OS X為開發對象。
繼續用GCC老古董(GCC 4.2)
如果你需要，是可以繼續用GCC 4.2，但是，蘋果公司已經發出聲明，他們不會繼續維護修正GCC裡的臭蟲，所以，這不是個長遠的可靠選項。GCC 4.2是Xcode 3裡的預設編譯器，Xcode 4裡還看得見。
LLVM-GCC 4.2
這個選項將兩者混著用，以GCC當frontend parser，把LLVM當後端的optimizer和code generator，這是Xcode 4新建專案的預設編譯器選項，在Xcode 3裡你要自己手動選用。改用LLVM-GCC的主要理由是，它同時具有效能提昇與更快的建置(build)速度，不過，建置時間僅為有限程度的縮短，因為，這個選項仍然以GCC為前端解析器，而且，若你建置的是除錯版（這是你花上大部分時間的地方），它不會啟用optimizer。
LLVM編譯器
這個選項完整使用LLVM的工具組，使用Clang為前端，LLVM為後端的optimizer與code generator，蘋果聲稱，除錯建置時，Clang parser的運行速度是GCC的三倍快，而且還維持著與GCC的相容性，另外，Clang的優點，不僅是速度較快，如果你已經使用過Xcode的Build and Analyze（建置並分析），那你已經見過Clang的威力了，它能夠提供更準確的錯誤與警告訊息，並提供如何修正程式碼的建議。
譬如說，如果你要使用某個之前宣告過的變數，卻打錯字，Clang很聰明，可以找出你真正想要的變數名，並且提出修正建議，然後，在處理後面的程式碼時，它會假設該錯誤已經修正過，這樣一來，會減少無意義的錯誤訊息，你就能輕易地找把心力放在真正發生錯誤的地方，Xcode利用這點，提供Fix-it功能，你會在程式碼裡看到修正建議，點一下就能接受並訂正程式碼：
所以，如果我這麼寫：
NSString *myText;
myTest = [[NSString alloc] init];
Xcode會利用Clang作出如下的訂正提示：
iOS與Mac OS X的差別
較早版本的Xcode僅支援OS X，但從Xcode 3.2.3之後，LLVM編譯器就開始支援iOS與Mac OS X兩個平台；之前Xcode+LLVM不支援C++，不過這項限制我相信已經不存在了，所以，不論你要在iOS或Mac OS X上開發，都可以使用LLVM。
需要注意的限制是，LLDB除錯器僅在Xcode 4上有，目前只支援Mac OS X，如果你開發的是iOS軟體，就沒辦法選擇LLDB除錯器，目前，你只能用GDB。
要選哪個？
那麼，三選項你該選哪個呢？目前我絕對不會用的是，老舊的GCC 4.2，除非你有很強的理由堅持要用，蘋果已經不再維護它了，而且LLVM-GCC看起來更好。在專案中途更改編譯器選項，這可是個大變動，所以，如果你要改，當然要經過審慎完整的測試。
對新的軟體專案而言，LLVM-GCC看起來應該是個安全的選項，蘋果公司認為它夠穩定夠成熟，所以才把它當做Xcode 4的預設選項（你或許不會把穩定成熟這兩個字眼跟Xcode 4本身畫上等號），而且，既然這選項使用的是GCC parser，向後相容性應該沒問題。
我說LLVM-GCC是個安全的選項，但我並不是指Clang/LLVM比較不安全，只是成熟度還沒那麼高罷了，我將一些以前的程式碼拿到Xcode 4上，使用LLVM 2.0編譯器重新編譯，到目前為止還沒發現任何問題，如果你也試過卻問題，我很有興趣聽聽詳細的細節，請留言告知。
日期：2011.03.21，
作者：Keith Harrison
作者的部落格：Use Your Loaf
作者簡介：
任職某IT公司，下班後在iPhone上開發，以及在mac上使用Ruby on Rails。
Xcode裡要用哪支編譯器─GCC還是LLVM？（Compiler Options in Xcode - GCC or LLVM?）
如果你用的Xcode是3.x版，而且還沒摸過改過專案裡的建置設定，那麼，你用的編譯器大概還是GNU Compiler Collection(GCC)。蘋果公司對GCC所投注的維護人力正緩慢地抽離減少，而且逐步轉移到一套嶄新的編譯器技術上，Low Level Virtual Machine(LLVM)，這是一個開放原始碼的專案。築基LLVM之上的開發工具，Xcode 3跟4都有（有些許差異），所以，不必等你過渡到Xcode 4，在那之前就可以開始享受LLVM帶來的好處。
LLVM計畫
所謂的LLVM計畫，是一套開放原始碼的工具組（完整列表請見LLVM.org），建構在一組核心函式庫之上，這組函式庫提供了optimizer（程式碼優化器）與code generator（機械碼產生器），LLVM計畫裡的其他工具還包括，Clang frontend parser（前端語法解析器）與LLDB debugger（除錯器）。Xcode利用了這一套模組化的作法來提供新功能，譬如，加強syntax highlighting（語法加亮、上色）、提供撰碼時常見錯誤的修正建議。
當我寫這篇時，GCC還是Xcode 3裡預設的編譯器，但Xcode 4釋出後，新建專案預設的編譯器改為LLVM-GCC。在這篇裡，我要來檢視一下Xcode 3、4可用的選項。
Xcode裡的編譯器選項(Compiler Options)
在Xcode裡，透過建置設定(build settings)來更改專案(project)或目標(target)的編譯器選項，版本3跟版本4的編譯器選項，有著些許差異，請看：
- Xcode 3可用的編譯器版本
- Xcode 4可用的編譯器版本
實務上，我們有三個選擇，看你要繼續用GCC、改用LLVM、或是混著用以取得向後相容性，GCC 4.0就不提了，因為已被揚棄不用了，在Xcode 4裡也看不見了，底下這張圖秀出三種選項的不同處：
各選項背後所代表的意涵有些許差異，看你的Xcode是3還是4，還有，看你是以iOS還是Mac OS X為開發對象。
繼續用GCC老古董(GCC 4.2)
如果你需要，是可以繼續用GCC 4.2，但是，蘋果公司已經發出聲明，他們不會繼續維護修正GCC裡的臭蟲，所以，這不是個長遠的可靠選項。GCC 4.2是Xcode 3裡的預設編譯器，Xcode 4裡還看得見。
LLVM-GCC 4.2
這個選項將兩者混著用，以GCC當frontend parser，把LLVM當後端的optimizer和code generator，這是Xcode 4新建專案的預設編譯器選項，在Xcode 3裡你要自己手動選用。改用LLVM-GCC的主要理由是，它同時具有效能提昇與更快的建置(build)速度，不過，建置時間僅為有限程度的縮短，因為，這個選項仍然以GCC為前端解析器，而且，若你建置的是除錯版（這是你花上大部分時間的地方），它不會啟用optimizer。
LLVM編譯器
這個選項完整使用LLVM的工具組，使用Clang為前端，LLVM為後端的optimizer與code generator，蘋果聲稱，除錯建置時，Clang parser的運行速度是GCC的三倍快，而且還維持著與GCC的相容性，另外，Clang的優點，不僅是速度較快，如果你已經使用過Xcode的Build and Analyze（建置並分析），那你已經見過Clang的威力了，它能夠提供更準確的錯誤與警告訊息，並提供如何修正程式碼的建議。
譬如說，如果你要使用某個之前宣告過的變數，卻打錯字，Clang很聰明，可以找出你真正想要的變數名，並且提出修正建議，然後，在處理後面的程式碼時，它會假設該錯誤已經修正過，這樣一來，會減少無意義的錯誤訊息，你就能輕易地找把心力放在真正發生錯誤的地方，Xcode利用這點，提供Fix-it功能，你會在程式碼裡看到修正建議，點一下就能接受並訂正程式碼：
所以，如果我這麼寫：
NSString *myText;
myTest = [[NSString alloc] init];
Xcode會利用Clang作出如下的訂正提示：
iOS與Mac OS X的差別
較早版本的Xcode僅支援OS X，但從Xcode 3.2.3之後，LLVM編譯器就開始支援iOS與Mac OS X兩個平台；之前Xcode+LLVM不支援C++，不過這項限制我相信已經不存在了，所以，不論你要在iOS或Mac OS X上開發，都可以使用LLVM。
需要注意的限制是，LLDB除錯器僅在Xcode 4上有，目前只支援Mac OS X，如果你開發的是iOS軟體，就沒辦法選擇LLDB除錯器，目前，你只能用GDB。
要選哪個？
那麼，三選項你該選哪個呢？目前我絕對不會用的是，老舊的GCC 4.2，除非你有很強的理由堅持要用，蘋果已經不再維護它了，而且LLVM-GCC看起來更好。在專案中途更改編譯器選項，這可是個大變動，所以，如果你要改，當然要經過審慎完整的測試。
對新的軟體專案而言，LLVM-GCC看起來應該是個安全的選項，蘋果公司認為它夠穩定夠成熟，所以才把它當做Xcode 4的預設選項（你或許不會把穩定成熟這兩個字眼跟Xcode 4本身畫上等號），而且，既然這選項使用的是GCC parser，向後相容性應該沒問題。
我說LLVM-GCC是個安全的選項，但我並不是指Clang/LLVM比較不安全，只是成熟度還沒那麼高罷了，我將一些以前的程式碼拿到Xcode 4上，使用LLVM 2.0編譯器重新編譯，到目前為止還沒發現任何問題，如果你也試過卻問題，我很有興趣聽聽詳細的細節，請留言告知。
2011/05/22
一致性
在很久很久以前，看完一本書，通常是指某程式語言的書，就可動手開發軟體了，現在可不同了（早就不同了），就算你能在24小時內學會某語言，你還要學會成堆成山的函式庫與類別庫，許許多多約定俗成的慣用法與程式片段，多少的青春歲月就花在這些層層疊疊的架構中，多少的辛酸血淚就灑在這些有臭蟲又不更新、不想用又不得不用的醜陋框架(framework)裡，唉，怎一聲長嘆了得。
寫程式時，需要一種天份，能夠在短時間內記住很多小細節的天份，變數名稱、函式名稱、回傳值、上下繼承關係、這段程式碼應該要寫在哪裡才好、等等，久了之後，自然而然熟極而流，越寫越順，當你能夠控制環境，這裡指的是掌握開發軟體時的環境，就會感到快樂，對每一行都確實知道在幹嘛，不用寫一寫就要停下來查文件，能夠處於那種優遊自在的狀態，真是美妙地不可言喻啊，所以，如果很不幸地要你換一種語言、換一套開發環境，那將會是極端苦痛、痛不可言、言語無法形容地不幸啊，光程式語言本身就會有很多的差異，有大有小，大的也就算了，畢竟是不同的語言，如果沒有一定程度以上的差別，那幹嘛存在多一種的語言了，至於小的，就很惱人了，有些一樣、有些差不多一樣、有些不太一樣、有些不一樣又有相似處，煩死啦。
請看一下底下這兩張圖，這一張是Perl的布林比較，當我在Perl書裡讀到其比較的判斷法則時，心理只有一種想法，瘋啦瘋啦，誰能記住這玩意兒啊？這什麼規則啊？（當然，我記不住不代表別人記不住。）
這一張是JavaScript的，好像好一點，但也處處是陷阱，一不小心程式的結果就會跟你想的不一樣。
顯然地，各程式語言的創作者對於這麼一個小小地方都能夠有眾多分歧的意見，什麼是true、什麼是false，nil又能代表什麼，nil能代表空串列嗎、nil等同於false嗎，等等等等。
當某語言有太多細微細節要花心思記得的話，用起來就很礙手礙腳，我認為Perl就是其中之一，Perl還標榜著"There's more than one way to do it"，聽起來是不錯，不過怎麼能記住這種種不同的用法呢？通常是選出一兩種好的，然後一直用吧。C++比較好一點但也差不多，當開始使用C++各種較進階的功能時，例如exception或template或operator overloading，哇賽，各種眉眉角角就出現了，要記住的地方就變多了。
很佩服那些跨平台的框架或軟體，光要搞定windows、mac、linux就快死人了，其中的差異可不是隨便就能講完列出來的，若是說到手持式裝置上，那就更加分歧了，再加上封閉、保護公司資產、追求與眾不同市場區隔、刻意與別人不一樣，嘿，真是混亂的世界啊。
在這裡有個小小的希望，至少、至少在語言層級，能夠有一致性，不是每個人都能像翻譯機精通八國語言聽說讀寫樣樣行，我知道，語言設計者是大師們，他們有思想有文化有所堅持，但是還是請你們至少把布林比較這麼基本的地方設計出一致性吧。
如果你對程式語言的歷史以及各種語言特性有興趣的話，看看這段影片吧。這根本是大師級的火力展示，裡面一堆聽都沒聽過的語言，例如KRL、COMIT、等等。
寫程式時，需要一種天份，能夠在短時間內記住很多小細節的天份，變數名稱、函式名稱、回傳值、上下繼承關係、這段程式碼應該要寫在哪裡才好、等等，久了之後，自然而然熟極而流，越寫越順，當你能夠控制環境，這裡指的是掌握開發軟體時的環境，就會感到快樂，對每一行都確實知道在幹嘛，不用寫一寫就要停下來查文件，能夠處於那種優遊自在的狀態，真是美妙地不可言喻啊，所以，如果很不幸地要你換一種語言、換一套開發環境，那將會是極端苦痛、痛不可言、言語無法形容地不幸啊，光程式語言本身就會有很多的差異，有大有小，大的也就算了，畢竟是不同的語言，如果沒有一定程度以上的差別，那幹嘛存在多一種的語言了，至於小的，就很惱人了，有些一樣、有些差不多一樣、有些不太一樣、有些不一樣又有相似處，煩死啦。
請看一下底下這兩張圖，這一張是Perl的布林比較，當我在Perl書裡讀到其比較的判斷法則時，心理只有一種想法，瘋啦瘋啦，誰能記住這玩意兒啊？這什麼規則啊？（當然，我記不住不代表別人記不住。）
這一張是JavaScript的，好像好一點，但也處處是陷阱，一不小心程式的結果就會跟你想的不一樣。
顯然地，各程式語言的創作者對於這麼一個小小地方都能夠有眾多分歧的意見，什麼是true、什麼是false，nil又能代表什麼，nil能代表空串列嗎、nil等同於false嗎，等等等等。
當某語言有太多細微細節要花心思記得的話，用起來就很礙手礙腳，我認為Perl就是其中之一，Perl還標榜著"There's more than one way to do it"，聽起來是不錯，不過怎麼能記住這種種不同的用法呢？通常是選出一兩種好的，然後一直用吧。C++比較好一點但也差不多，當開始使用C++各種較進階的功能時，例如exception或template或operator overloading，哇賽，各種眉眉角角就出現了，要記住的地方就變多了。
很佩服那些跨平台的框架或軟體，光要搞定windows、mac、linux就快死人了，其中的差異可不是隨便就能講完列出來的，若是說到手持式裝置上，那就更加分歧了，再加上封閉、保護公司資產、追求與眾不同市場區隔、刻意與別人不一樣，嘿，真是混亂的世界啊。
在這裡有個小小的希望，至少、至少在語言層級，能夠有一致性，不是每個人都能像翻譯機精通八國語言聽說讀寫樣樣行，我知道，語言設計者是大師們，他們有思想有文化有所堅持，但是還是請你們至少把布林比較這麼基本的地方設計出一致性吧。
如果你對程式語言的歷史以及各種語言特性有興趣的話，看看這段影片吧。這根本是大師級的火力展示，裡面一堆聽都沒聽過的語言，例如KRL、COMIT、等等。
2011/05/21
別再遜了 Don't suck
看完了Mike Lee的演講Making Apps That Don’t Suck，隨手寫寫。
先簡介一下Mike，他長久在mac圈打滾，曾在蘋果公司工作，曾在Delicious Monster工作，這是一套得到Apple設計獎的軟體，是Taplous的創辦人之一，這家公司的Tap Tap Revenge是在iPhone上超紅的遊戲，或許你沒聽過，請想像一下，在幾年前，這遊戲就像現在的Angry Birds一樣紅。
演講的主題，就是怎麼生產出好東西，特立獨行如Mike，自然會給出跟一般認知不同的見解。一般我們常聽見的，有好的團隊、好的點子、好的技術，既然這麼好，所打造出來的自然而然地會是偉大的產品， 接下來就會有個疑問，為什麼我們沒賺錢呢？想啊想，想啊想，想辦法獲利啊。
Mike的三步驟可不是這樣，開宗明義就要假定我們遜斃了，要誠實，然後找出原因，接下來，想辦法不要那麼遜。這就是打造偉大產品的三步驟。
抱歉，其他細節就不多說了（我很懶），大家自己看看演講影片吧，對我而言，看完後得到的一個整體映像就是，要追求品質，不要想錢的事情。嗯，好像太老生常談了。影片中有舉Trism為例，這是支賣很好的iPhone遊戲，可是沒想到，在Mike眼裡，其介面如此不堪啊。
在很久很久以前，讀到了Joel Spolsky的邊開火邊移動，我大笑，節錄一段如下：
當你進入狀況後, 要繼續維持並不算太難. 我的一天通常都是這樣子的: (1) 上班 (2) 看信看網頁等等 (3) 決定應該吃過午飯後再做事 (4) 吃完午飯回來 (5) 看信看網頁等等 (6) 終於決心該開始幹活 (7) 看信看網頁等等 (8) 再度下定決心真的該開始做事 (9) 把該死的編輯器叫出來然後 (10) 不斷地寫程式直到突然發現已經下午7點半了.
哈哈，相信每個人都曾經歷過這樣的循環。我最近寫了支在iPhone上打逼逼的軟體，有時也會發生提不起勁、整天打混的情況，所以，我想，要生產好產品，要成功，就目前而言，我的三步驟是：
１．打開那該死的編輯器。
２．進入那無以名的狀態、忘記時間、忘記全世界。
３．保持士氣高昂。
PS 寫完這篇，發現內容實在很跳脫，嗯，真糟糕啊。
先簡介一下Mike，他長久在mac圈打滾，曾在蘋果公司工作，曾在Delicious Monster工作，這是一套得到Apple設計獎的軟體，是Taplous的創辦人之一，這家公司的Tap Tap Revenge是在iPhone上超紅的遊戲，或許你沒聽過，請想像一下，在幾年前，這遊戲就像現在的Angry Birds一樣紅。
演講的主題，就是怎麼生產出好東西，特立獨行如Mike，自然會給出跟一般認知不同的見解。一般我們常聽見的，有好的團隊、好的點子、好的技術，既然這麼好，所打造出來的自然而然地會是偉大的產品， 接下來就會有個疑問，為什麼我們沒賺錢呢？想啊想，想啊想，想辦法獲利啊。
Mike的三步驟可不是這樣，開宗明義就要假定我們遜斃了，要誠實，然後找出原因，接下來，想辦法不要那麼遜。這就是打造偉大產品的三步驟。
抱歉，其他細節就不多說了（我很懶），大家自己看看演講影片吧，對我而言，看完後得到的一個整體映像就是，要追求品質，不要想錢的事情。嗯，好像太老生常談了。影片中有舉Trism為例，這是支賣很好的iPhone遊戲，可是沒想到，在Mike眼裡，其介面如此不堪啊。
在很久很久以前，讀到了Joel Spolsky的邊開火邊移動，我大笑，節錄一段如下：
當你進入狀況後, 要繼續維持並不算太難. 我的一天通常都是這樣子的: (1) 上班 (2) 看信看網頁等等 (3) 決定應該吃過午飯後再做事 (4) 吃完午飯回來 (5) 看信看網頁等等 (6) 終於決心該開始幹活 (7) 看信看網頁等等 (8) 再度下定決心真的該開始做事 (9) 把該死的編輯器叫出來然後 (10) 不斷地寫程式直到突然發現已經下午7點半了.
哈哈，相信每個人都曾經歷過這樣的循環。我最近寫了支在iPhone上打逼逼的軟體，有時也會發生提不起勁、整天打混的情況，所以，我想，要生產好產品，要成功，就目前而言，我的三步驟是：
１．打開那該死的編輯器。
２．進入那無以名的狀態、忘記時間、忘記全世界。
３．保持士氣高昂。
PS 寫完這篇，發現內容實在很跳脫，嗯，真糟糕啊。
2011/05/11
[廣告] Hit BBS，在iPhone上打bbs的軟體
嗨，我寫了一支在iPhone上打bbs的軟體，在這裡打打廣告。
希望大家多多支持。
想知道更詳細的說明，請到Hit BBS的官方網站。
Hit BBS是支iPhone軟體，讓你瘋狂打逼戰鄉民。
Hit BBS大體上會有四種畫面。
1. 站台列表，可以一次上好幾個bbs站台。
2. 站台編輯，輸入網址與帳號密碼，登入時自動送出。
3. bbs畫面，有放大縮小功能，看的清楚。
4. 若bbs畫面上有網址，可以開啟瀏覽器，哇，瀏覽PTT的表特版真方便啊。
希望大家多多支持。
想知道更詳細的說明，請到Hit BBS的官方網站。
Hit BBS是支iPhone軟體，讓你瘋狂打逼戰鄉民。Hit BBS大體上會有四種畫面。
1. 站台列表，可以一次上好幾個bbs站台。
2. 站台編輯，輸入網址與帳號密碼，登入時自動送出。
3. bbs畫面，有放大縮小功能，看的清楚。
4. 若bbs畫面上有網址，可以開啟瀏覽器，哇，瀏覽PTT的表特版真方便啊。
2011/04/15
如何取得iPhone的UDID（識別碼）
每部iPhone都有一個獨一無二的UDID（Unique Device IDentifier，識別碼），由40個字母及數字所組成。
譬如說像這樣：2b6f0cc904d137be2e1721536f5664094b000000。
可用以下步驟取得：
將iPhone連結至電腦後，打開iTunes，會出現底下這個畫面：
此時，在序號(serial number)上用滑鼠點一下，就會變成UDID（識別碼）。
利用編輯-拷貝(Edit-Copy)， 即可把這串UDID複製下來。
譬如說像這樣：2b6f0cc904d137be2e1721536f5664094b000000。
可用以下步驟取得：
將iPhone連結至電腦後，打開iTunes，會出現底下這個畫面：
此時，在序號(serial number)上用滑鼠點一下，就會變成UDID（識別碼）。
利用編輯-拷貝(Edit-Copy)， 即可把這串UDID複製下來。
2011/04/10
時間是什麼？Rethinking Time in Distributed Systems by Paul Borrill
主題：Rethinking Time in Distributed Systems: Can We Build Complex Systems Simply?
演講者：Paul Borrill
放在YouTube上的演講錄影，投影片在此。
在史丹佛大學演講的錄影，探討“時間”到底是什麼玩意兒。
我們有分散系統、雲端運算、多核心處理器、多行程多緒程、平行處理等等，就算是單一支程式裡也會有好多個物件在交互作用，軟體規模越來越大，系統越來越複雜，我們要怎麼建造呢，能夠控制得宜嗎，有好方法嗎？硬體部分，處理器的核心越來越多，但是軟體方面呢，有誰思考過了嗎；網路儲存部分，數量這麼多的資料中心，其軟體呢，有誰思考過了嗎？
在科學界，時間已經不斷地被檢驗不斷地被思考，愛因斯坦說：時間不過是幻覺而已。馬赫(Ernst Mach)說：我們根本沒有能力以時間來測量事物的變化，相反的，我們是透過事物的變化因而產生時間流動的抽象概念。可是在電腦科學界，我們對於時間概念的認知，遠遠落後於物理學家跟哲學家。電腦科學家的時間概念，大概是從涂林機來的，在一條一維的帶子上面打洞，我們也接受了牛頓的絕對時間觀，但這已經在一百多年前就被證明是錯誤的啊。
演講中提到的延伸閱讀：Leslie Lamport關於分散式系統的論文，譬如Time, Clocks, and the Ordering of Events in a Distributed System以及The Byzantine Generals' Problem。
時間沒有方向性，時間不會流動，時間不是連續的，因果律是個迷思，“現在”這個概念，如果不加上“這裡”是沒有意義的。哇嗚，好慘喔，講到這裡我已經迷迷糊糊了，境界太高囉，還是請大家看看演講錄影，自行體會吧。
演講者：Paul Borrill
放在YouTube上的演講錄影，投影片在此。
在史丹佛大學演講的錄影，探討“時間”到底是什麼玩意兒。
我們有分散系統、雲端運算、多核心處理器、多行程多緒程、平行處理等等，就算是單一支程式裡也會有好多個物件在交互作用，軟體規模越來越大，系統越來越複雜，我們要怎麼建造呢，能夠控制得宜嗎，有好方法嗎？硬體部分，處理器的核心越來越多，但是軟體方面呢，有誰思考過了嗎；網路儲存部分，數量這麼多的資料中心，其軟體呢，有誰思考過了嗎？
在科學界，時間已經不斷地被檢驗不斷地被思考，愛因斯坦說：時間不過是幻覺而已。馬赫(Ernst Mach)說：我們根本沒有能力以時間來測量事物的變化，相反的，我們是透過事物的變化因而產生時間流動的抽象概念。可是在電腦科學界，我們對於時間概念的認知，遠遠落後於物理學家跟哲學家。電腦科學家的時間概念，大概是從涂林機來的，在一條一維的帶子上面打洞，我們也接受了牛頓的絕對時間觀，但這已經在一百多年前就被證明是錯誤的啊。
演講中提到的延伸閱讀：Leslie Lamport關於分散式系統的論文，譬如Time, Clocks, and the Ordering of Events in a Distributed System以及The Byzantine Generals' Problem。
時間沒有方向性，時間不會流動，時間不是連續的，因果律是個迷思，“現在”這個概念，如果不加上“這裡”是沒有意義的。哇嗚，好慘喔，講到這裡我已經迷迷糊糊了，境界太高囉，還是請大家看看演講錄影，自行體會吧。
2011/04/03
什麼都沒讀
去台北逛了一圈圖書街（重慶南路從衡陽路到忠孝西路），四處晃晃，到處看看，很多書想看，卻又提不起勁閱讀，這是怎麼回事呢？真是糟糕啊。
之前看了萬城目 學的《鹿男》原著小說與日劇，雖然有些故事情節有破綻、有點說不通，不過看著看著還滿有趣的；《鹿男》（奈良）、《鴨川荷爾摩》（京都）與《豐臣公主》（大阪），被稱為關西奇幻三部曲，本想求個完整通通看完，就字數上來講這也不是什麼難事，但卻又一拖再拖，感覺一旦錯過了時機、錯過了心情、錯過了奇蒙子之後，就不太想碰了。去書店看到新作出爐──《鹿乃子與瑪德蓮夫人》，似乎又燃起一點點的上進心，但一想到理應先把缺看的補回來比較好，就又開始懶懶的，怠惰之心一起，便無計可施徒呼負負也。
九把刀新作《殺手，價值連城的幸運》，因為之前看了九把刀對直銷的打臉文，所以對這本有興趣，沒想到，居然包膜封起來了，有這麼貴重嗎？
看到《新文化苦旅 》，裡面有新作、有把之前的《文化苦旅》與《山居筆記》整理精選，文章依舊是好的，想當初學生時代看到余秋雨的《文化苦旅》時，大驚失色下巴都快掉了，怎麼文章這麼好，怎麼文化底子這麼深厚這麼廣博啊，現在似乎少了那麼點激情，下手買是不成問題的，但又怕放上書架後積灰塵，忘記是誰說過：書是越看越少的，這句話似乎可以成為我惰性的開脫之詞。
發現台北地下街（新光三越一帶），那裡跟台鐵高鐵捷運以及市民大道的地下街都打通了，在那裡，新開了誠品，我駐足了一會重讀了幾頁的《傷心咖啡店之歌》（朱少麟），很喜歡這本書，現在還是很喜歡，我好像把這本跟《燕子》送給某朋友了，不過還好，最喜歡的《地底三萬呎》還在我書架上，能夠有幾本這種過段時間重新閱讀會有不同感受的書，真的非常幸福。
中午到市民大道地下街的美食區吃午飯，發現那裡有女僕服務茶飲店耶，呵呵。 這裡還有電玩、轉蛋、模型、日文書雜誌等等，哇賽，海賊女帝蛇姬的模型耶，好讚啊。
看到一本《彩繪山海經》，生動地彩繪了山海經裡的奇人異獸，而且旁徵博引了其他文化裡同類型的神話與傳說，譬如中國有女媧，那其他神話裡類似的存在呢？相當不錯，不過我書架上已經有一本《圖說山海經》，所以也沒下手買，哈哈。
看到一本《戰國武將家紋軍旗事典》，介紹各種家紋的緣起，軍旗的形式等等，這些家紋是一大特色，相較之下，在電玩三國志裡，都是用面旗子繡上君主的姓氏就完啦。
到天瓏晃晃，發現中文書排行榜的前幾名都是Android的，厲害。發現一本新書《Objective-C Phrasebook》，滿不錯的，作者很熟悉各種Objective-C runtime的歷史與現況，先看完第一本學Objective-C的書後再看這本，會有很大的幫助，釐清很多觀念。很久很久以前，到天瓏只會看到男的，現在偶爾會看到女的了。看到有位爸爸帶著小孩，大概國中吧，在挑選C++、C#之類的書，居然還打算買VB的書， 嗯。好多我想要的書都好貴啊，嗚嗚。另外，《Orange's 一個作業系統的實現》與《30 天打造 OS！作業系統自作入門》，很想買，但是，買了又覺得沒時間細看，不細看的話其實就不需要買了，唉。
喜愛的圖文書作者高木直子的新作《一個人吃太飽：高木直子的美味地圖》，不錯不錯，在書店站著看了一半，應該會買吧。
《誰在地球的另一邊：從古代海圖看世界》，這本書我很感興趣，以前人是怎麼畫出地圖的呢，就算是現代人，也常常不知道哪裡是哪裡。
翻了翻金庸最新修訂版，老實說很不喜歡，何必呢，不想多說了。
有些書店的員工要穿制服，拜託拜託，花點錢嘛，制服都那麼難看，那不是選舉背心嗎？搞什麼鬼啊。
PS 沒看到什麼正妹，殘念。
之前看了萬城目 學的《鹿男》原著小說與日劇，雖然有些故事情節有破綻、有點說不通，不過看著看著還滿有趣的；《鹿男》（奈良）、《鴨川荷爾摩》（京都）與《豐臣公主》（大阪），被稱為關西奇幻三部曲，本想求個完整通通看完，就字數上來講這也不是什麼難事，但卻又一拖再拖，感覺一旦錯過了時機、錯過了心情、錯過了奇蒙子之後，就不太想碰了。去書店看到新作出爐──《鹿乃子與瑪德蓮夫人》，似乎又燃起一點點的上進心，但一想到理應先把缺看的補回來比較好，就又開始懶懶的，怠惰之心一起，便無計可施徒呼負負也。
九把刀新作《殺手，價值連城的幸運》，因為之前看了九把刀對直銷的打臉文，所以對這本有興趣，沒想到，居然包膜封起來了，有這麼貴重嗎？
看到《新文化苦旅 》，裡面有新作、有把之前的《文化苦旅》與《山居筆記》整理精選，文章依舊是好的，想當初學生時代看到余秋雨的《文化苦旅》時，大驚失色下巴都快掉了，怎麼文章這麼好，怎麼文化底子這麼深厚這麼廣博啊，現在似乎少了那麼點激情，下手買是不成問題的，但又怕放上書架後積灰塵，忘記是誰說過：書是越看越少的，這句話似乎可以成為我惰性的開脫之詞。
發現台北地下街（新光三越一帶），那裡跟台鐵高鐵捷運以及市民大道的地下街都打通了，在那裡，新開了誠品，我駐足了一會重讀了幾頁的《傷心咖啡店之歌》（朱少麟），很喜歡這本書，現在還是很喜歡，我好像把這本跟《燕子》送給某朋友了，不過還好，最喜歡的《地底三萬呎》還在我書架上，能夠有幾本這種過段時間重新閱讀會有不同感受的書，真的非常幸福。
中午到市民大道地下街的美食區吃午飯，發現那裡有女僕服務茶飲店耶，呵呵。 這裡還有電玩、轉蛋、模型、日文書雜誌等等，哇賽，海賊女帝蛇姬的模型耶，好讚啊。
看到一本《彩繪山海經》，生動地彩繪了山海經裡的奇人異獸，而且旁徵博引了其他文化裡同類型的神話與傳說，譬如中國有女媧，那其他神話裡類似的存在呢？相當不錯，不過我書架上已經有一本《圖說山海經》，所以也沒下手買，哈哈。
看到一本《戰國武將家紋軍旗事典》，介紹各種家紋的緣起，軍旗的形式等等，這些家紋是一大特色，相較之下，在電玩三國志裡，都是用面旗子繡上君主的姓氏就完啦。
到天瓏晃晃，發現中文書排行榜的前幾名都是Android的，厲害。發現一本新書《Objective-C Phrasebook》，滿不錯的，作者很熟悉各種Objective-C runtime的歷史與現況，先看完第一本學Objective-C的書後再看這本，會有很大的幫助，釐清很多觀念。很久很久以前，到天瓏只會看到男的，現在偶爾會看到女的了。看到有位爸爸帶著小孩，大概國中吧，在挑選C++、C#之類的書，居然還打算買VB的書， 嗯。好多我想要的書都好貴啊，嗚嗚。另外，《Orange's 一個作業系統的實現》與《30 天打造 OS！作業系統自作入門》，很想買，但是，買了又覺得沒時間細看，不細看的話其實就不需要買了，唉。
喜愛的圖文書作者高木直子的新作《一個人吃太飽：高木直子的美味地圖》，不錯不錯，在書店站著看了一半，應該會買吧。
《誰在地球的另一邊：從古代海圖看世界》，這本書我很感興趣，以前人是怎麼畫出地圖的呢，就算是現代人，也常常不知道哪裡是哪裡。
翻了翻金庸最新修訂版，老實說很不喜歡，何必呢，不想多說了。
有些書店的員工要穿制服，拜託拜託，花點錢嘛，制服都那麼難看，那不是選舉背心嗎？搞什麼鬼啊。
PS 沒看到什麼正妹，殘念。
2011/04/01
讀後推薦：老貓學出版
我看了這篇部落格，「書渴望自由」出版實驗：老貓學出版 EPUB 版無保護上市，讀了老貓實驗性地免費散佈出來的新書〈老貓學出版〉。你可以到這篇部落格裡的連結下載epub格式的電子書，然後去找適合你平台的電子書閱讀器，譬如這裡，就可以閱讀這本電子書了。
書裡內容非常豐富，有關於出版的基本知識與名詞解釋，有探討排版、封面設計、書籍的頁數與定價，有述說編輯的辛酸血淚，有翻譯外文書的種種內幕，有出版社的經營手法與成長故事，網路與數位化對發行書籍的衝擊，有回憶有話當年，等等，非常值得一看。
「電子書」到底是什麼？要怎麼推廣？可否完全取代紙本書？國外情況如何？台灣情況又如何？如何向音樂產業取經？書店、經銷商、出版社、作家等角色，將來又會如何？作者不僅身處這道浪流之中，也時時在思考將來的走向，書中很多篇文章以及作者的部落格都在對這個議題不斷地提出看法與思索，這次作者實驗性地把一本新書免費以電子書形式散佈出來，不知道結果會如何，總之，有實驗有數據，才能依此制定下一步吧。
你猜，我有沒有實際拿錢出來贊助作者呢？
書裡內容非常豐富，有關於出版的基本知識與名詞解釋，有探討排版、封面設計、書籍的頁數與定價，有述說編輯的辛酸血淚，有翻譯外文書的種種內幕，有出版社的經營手法與成長故事，網路與數位化對發行書籍的衝擊，有回憶有話當年，等等，非常值得一看。
「電子書」到底是什麼？要怎麼推廣？可否完全取代紙本書？國外情況如何？台灣情況又如何？如何向音樂產業取經？書店、經銷商、出版社、作家等角色，將來又會如何？作者不僅身處這道浪流之中，也時時在思考將來的走向，書中很多篇文章以及作者的部落格都在對這個議題不斷地提出看法與思索，這次作者實驗性地把一本新書免費以電子書形式散佈出來，不知道結果會如何，總之，有實驗有數據，才能依此制定下一步吧。
你猜，我有沒有實際拿錢出來贊助作者呢？
2011/03/31
讀後想法：孤劍不折（柴田鍊三郎）與祕劍．柳生連也齋（五味康祐）
這類小說被稱為「時代小說」或「劍豪小說」，時間通常設定在戰國、江戶幕府，在那樣子的大時代背景底下，故事圍繞在擊劍的藝術打轉，主角通常是劍豪，追求劍的極詣。
我看了下面兩本，很少，寫寫這篇感想。其實已經看完很久了，居然拖到現在。也不想再看其他同類型的小說了，又是三分鐘熱度的表現，哈哈。
孤劍不折（柴田鍊三郎）
祕劍．柳生連也齋（五味康祐）
因為設定在歷史朝代中，書中多半有真實歷史的根據，幾分實幾分虛就看作者的需求了，或許弄出個國家滅亡殘存的公主由主角來保護，或者在有實際考證之中插入想像的外傳，譬如說，孤劍不折的主角，神子上源四郎，其受業師傅正是小野忠明，生存年代為1569-1628。
下圖在信長之野望-革新裡，小野忠明的能力值。這類劍豪角色多半被設定為統率很低（帶低打仗能力差），武勇很高（使出絕招時很厲害），同類型的角色還包括：宮本武藏、佐佐木小次郎、上泉信綱、柳生宗嚴、丸目長惠等。
書中最吸引我注意的，大概就是劍術（刀術）與戰鬥的描寫，譬如說：
柳生流有一招奧義叫「月陰」，那是從日月陰陽中，選定月與陰的劍法奧義。月有形，照明暗夜；陰無形，代表黑暗。正因為有月光，才看得見陰。例如在暗夜決戰時，看不見敵人的身影，也看不見自己的影子。這樣要以什麼作為對象呢？敵我雙方都像在黑暗中探物般，揮刀掃動地面。看出對手以長劍探尋時的光影，展開攻擊。
當然了，招式是劍尖朝下的下段招式，當敵人看準我方小腿出劍時，配合其劍身的光芒，接連使出反照出我方劍光的快劍，此稱之為「月陰」。
月陰又轉化出 「山陰」這項奧義。這是陰陽表裡，對敵人的變化能應付自如的一種變化。山陰又轉化出宛如烈風吹襲海面，激起波濤的「浦波」這招秘技。
當我初看時，有一種新鮮感，跟熟知的金庸古龍等武俠小說的描寫不太一樣，讓我眼睛一亮，書中還有很多這類劍術招式奧義的描寫，當然，老梗不能一直用，作者也會竭盡腦汁想出天馬行空的招式，配合日落、配合心氣神等等，最後往往達到劍人合一的境界，劍招就代表使劍的人，劍手是什麼樣的人才能使出那樣的劍招。
書中也會有描寫時代背景、人物故事、情節鋪陳等，雖也不錯，但我看過便罷，或許是沒興趣吧，也許是無法領略其筆法吧，總之，並不會特別記得些什麼。
我是先看孤劍不折，這是一本四百多頁的故事，覺得很不錯，所以又買了祕劍．柳生連也齋，這裡面是11個短篇故事集結成書的，有喜歡的也有看的昏昏沉沉的。後來就提不興趣看其他本了，感覺興致已盡，況且，書架上還有好幾本小說沒看咧，orz。
我對這種日本劍道會產生些許的興趣想多了解一點，大概是來自玩太閣立志傳跟看日劇鹿男吧。
日劇鹿男，堀田取得大和杯優勝時的場景。
太閣立志傳是個靈活度很高、遊樂性很強的遊戲，從早期你只能當武將，到後來你可以當劍豪、忍者、商人等等。下圖為比劍的畫面，以卡片來戰鬥，修煉後可取得秘技奧義等強力卡片使出招式。
我看了下面兩本，很少，寫寫這篇感想。其實已經看完很久了，居然拖到現在。也不想再看其他同類型的小說了，又是三分鐘熱度的表現，哈哈。
孤劍不折（柴田鍊三郎）
祕劍．柳生連也齋（五味康祐）
因為設定在歷史朝代中，書中多半有真實歷史的根據，幾分實幾分虛就看作者的需求了，或許弄出個國家滅亡殘存的公主由主角來保護，或者在有實際考證之中插入想像的外傳，譬如說，孤劍不折的主角，神子上源四郎，其受業師傅正是小野忠明，生存年代為1569-1628。
下圖在信長之野望-革新裡，小野忠明的能力值。這類劍豪角色多半被設定為統率很低（帶低打仗能力差），武勇很高（使出絕招時很厲害），同類型的角色還包括：宮本武藏、佐佐木小次郎、上泉信綱、柳生宗嚴、丸目長惠等。
書中最吸引我注意的，大概就是劍術（刀術）與戰鬥的描寫，譬如說：
當然了，招式是劍尖朝下的下段招式，當敵人看準我方小腿出劍時，配合其劍身的光芒，接連使出反照出我方劍光的快劍，此稱之為「月陰」。
月陰又轉化出 「山陰」這項奧義。這是陰陽表裡，對敵人的變化能應付自如的一種變化。山陰又轉化出宛如烈風吹襲海面，激起波濤的「浦波」這招秘技。
當我初看時，有一種新鮮感，跟熟知的金庸古龍等武俠小說的描寫不太一樣，讓我眼睛一亮，書中還有很多這類劍術招式奧義的描寫，當然，老梗不能一直用，作者也會竭盡腦汁想出天馬行空的招式，配合日落、配合心氣神等等，最後往往達到劍人合一的境界，劍招就代表使劍的人，劍手是什麼樣的人才能使出那樣的劍招。
書中也會有描寫時代背景、人物故事、情節鋪陳等，雖也不錯，但我看過便罷，或許是沒興趣吧，也許是無法領略其筆法吧，總之，並不會特別記得些什麼。
我是先看孤劍不折，這是一本四百多頁的故事，覺得很不錯，所以又買了祕劍．柳生連也齋，這裡面是11個短篇故事集結成書的，有喜歡的也有看的昏昏沉沉的。後來就提不興趣看其他本了，感覺興致已盡，況且，書架上還有好幾本小說沒看咧，orz。
我對這種日本劍道會產生些許的興趣想多了解一點，大概是來自玩太閣立志傳跟看日劇鹿男吧。
日劇鹿男，堀田取得大和杯優勝時的場景。
太閣立志傳是個靈活度很高、遊樂性很強的遊戲，從早期你只能當武將，到後來你可以當劍豪、忍者、商人等等。下圖為比劍的畫面，以卡片來戰鬥，修煉後可取得秘技奧義等強力卡片使出招式。
