這幾天看了一本幾年前買的書：「資訊革命了什麼？」
這本書的年代，應該還是在 Internet Bubble 的時期。大致上，作者是想強調，那些說「資訊萬能」、「新技術會終結報紙、媒體、中介者、公司與政府機構...」等等的論調，其實是很狹隘的直線式推論。
經過了泡沫的破滅，現在應該也沒有人會再說「資訊萬能」了吧。但是，在網路資訊當紅的時期，能夠提出異於主流的看法，並且加以論證（看了幾本書後，我發現這些作者都很會寫各式各樣的論述 --- 即使有時會覺得他們太囉唆）。
現在可以用比較平靜的心情，來看這本書。我覺得，自己最大的收穫，其實是來自於書中提到的「實務造就流程」(Practice Makes Process) 這個章節。作者們強調，流程對結合組織的各部門固然重要，可是終究要靠在組織工作的個人，來實現流程、並賦予流程意義。所謂實務，則是指為完成工作所進行的活動。
這類抽象的論述，在公司裡似乎常常可以聽到，感覺起來也沒什麼特別，那我的收穫在哪兒呢？
原來，要能夠合作，必須建立大家公認的詮釋架構。「每個人都有自己的想法，但觀念可以溝通」。而實務，就是建立順暢溝通的管道。例如，為什麼同樣的資訊，在不同的人身上，會產生相異的知識呢？從事的工作性質不同，所受的專業訓練有異，對資訊的反應就不一樣。是實務左右了如何消化知識。
所以，為什麼我總覺得系統設計與實作，在溝通上那麼辛苦呢？可能就是因為要溝通的人們，彼此並沒有相同、或者類似的實務經驗啊。「學習得到」(learn about) 與「學做、從做中學」(learn to be) 之間，差異竟是如此之大，以致於許多知識，只能乘著實務的翅膀來有效溝通呢。
也因此，我要將 prototype 或者 pre-β 轉交給學弟妹們，就不能只是強調理論與模型，而必須注意到實務的重要性。或許，必須讓承接的人員，經歷一些設計與實作上的磨練，才能夠經由「實務」，順利地溝通與移轉我在這部分的經驗與想法（知識）。
星期日, 1月 29, 2006
星期三, 1月 25, 2006
談古契書資料處理：之五
時間過得快，似乎也該繼續「古契書資料處理」的一些討論了。
原本在「之五」的討論裡，想談談檢索系統的。但是之前將全文檢索的資料庫，從 MySQL 轉到 M$SQL 的過程，遇到了許多不甚常見的問題（參考之前的 posts: MySQL 的全文搜尋效率、MySQL 到 SQL Server 的轉換、與 SQL Server 的全文檢索），因此就耽擱了。
將古籍數位化後，接下來就會想提供檢索系統。
然而，需要提供怎樣的檢索功能呢？一個很基本的要求，就是支援全文檢索。所謂「全文檢索」，就是系統對整篇文章（而不是只對某些特定的詞彙）都做索引，因此只要使用者輸入文章中出現的字詞，系統就能夠找到這篇文章。
但是，全文檢索在許多狀況下，似乎還不夠「好用」。許多詞彙（尤其是一般性用途的字詞）在大量的文章中都會出現，因此若僅僅輸入那些字詞當作 query string，系統就會「找到」一大堆文件，每個文件雖然都有出現指定的詞彙，但是卻不見得是使用者想找的。
這下子怎麼辦呢？
一般來說，有兩種方式或許可以改善檢索的有效性：一種是，對使用者提供合適的 query-refinement 建議；另外一種，則是對文件提供「分類」或「分群」的功能。有許多古籍資料有 metadata（詮釋文件的資料），因此可利用來提供 post-query classification 的功能。此外，clustering 也是一種常見的技術，通常是利用文件中的關鍵字，自動將文件分為數個群組。
我的 prototype 只考慮加上「相當有限」的 metadata，與一些（半自動化）特殊地名擷取的機制。但即使如此，整合起來，也不是「一片蛋糕」(a piece of cake) 般地容易。更何況，現在的 prototype 已經「升級」為 pre-β 了，要做的事情，可是排了很長的隊呢。
原本在「之五」的討論裡，想談談檢索系統的。但是之前將全文檢索的資料庫，從 MySQL 轉到 M$SQL 的過程，遇到了許多不甚常見的問題（參考之前的 posts: MySQL 的全文搜尋效率、MySQL 到 SQL Server 的轉換、與 SQL Server 的全文檢索），因此就耽擱了。
將古籍數位化後，接下來就會想提供檢索系統。
然而，需要提供怎樣的檢索功能呢？一個很基本的要求，就是支援全文檢索。所謂「全文檢索」，就是系統對整篇文章（而不是只對某些特定的詞彙）都做索引，因此只要使用者輸入文章中出現的字詞，系統就能夠找到這篇文章。
但是，全文檢索在許多狀況下，似乎還不夠「好用」。許多詞彙（尤其是一般性用途的字詞）在大量的文章中都會出現，因此若僅僅輸入那些字詞當作 query string，系統就會「找到」一大堆文件，每個文件雖然都有出現指定的詞彙，但是卻不見得是使用者想找的。
這下子怎麼辦呢？
一般來說，有兩種方式或許可以改善檢索的有效性：一種是，對使用者提供合適的 query-refinement 建議；另外一種，則是對文件提供「分類」或「分群」的功能。有許多古籍資料有 metadata（詮釋文件的資料），因此可利用來提供 post-query classification 的功能。此外，clustering 也是一種常見的技術，通常是利用文件中的關鍵字，自動將文件分為數個群組。
我的 prototype 只考慮加上「相當有限」的 metadata，與一些（半自動化）特殊地名擷取的機制。但即使如此，整合起來，也不是「一片蛋糕」(a piece of cake) 般地容易。更何況，現在的 prototype 已經「升級」為 pre-β 了，要做的事情，可是排了很長的隊呢。
星期日, 1月 22, 2006
工作與日常生活間的平衡
前兩天和貓談了談，他說我也是屬於「工作狂」的類型。
我不知道如何判斷一個人是否是工作狂。從某個角度看，我是有這樣的傾向。雖然，我幾乎都是回家吃晚餐（或許，有許多工作人士，會很羨慕吧）；但是，我經常在家裡、週末、甚至夜半，想起一些「工作上或許可以改進的地方」，而在電腦前敲敲打打、修修改改。
或許，就是對於許多事情「放不下」的關係，所以會顯現出「工作狂熱」的現象吧。但是，我總不願把工作就只當成「為了賺錢」而工作，總希望還能得到些「成就感」、還能對其他人有一些貢獻。
有時，我會對無法陪寶寶玩上一段時間而感到愧疚。她可是真心誠意地邀請我和她一起玩「茶犬」的呢（她現在擁有五隻麥當勞茶犬、五隻扭蛋得來的小茶犬、還有一隻更小的麥茶犬 --- 小傢伙說是另外一隻的弟弟）。可是，陪著她玩著類似辦家家酒的茶犬遊戲，約莫二十分鐘後，我就感到坐立難安（覺得做工作相關的事情似乎更重要些）。
有時，當太太忙碌，而自己有些空閒時，也會感到有些歉意，而想幫忙做些家事。但是，自己有空的時間通常很短（尤其是，需要做些工作相關事情的時候）、處理家事的技巧也差。更糟的是，做了一陣子後，經常容易感到疲累。
有時，則是對父母、兄弟姊妹、還有其他家人感到虧欠。自己似乎總是顯得「沒有時間好好地陪伴家人」。是真的因為工作的關係，還是自己一直下意識地在逃避呢？
因此，歲月經常是在愧疚中，日復一日地度過。我不曉得，是否大家都能在工作與日常生活間，取得良好的平衡點；但我確實希望，自己能夠做好份內的工作（表現得突出些，當然更好，但這樣或許就算是奢望吧）、並陪伴家人度過溫馨的每一天。
我不知道如何判斷一個人是否是工作狂。從某個角度看，我是有這樣的傾向。雖然，我幾乎都是回家吃晚餐（或許，有許多工作人士，會很羨慕吧）；但是，我經常在家裡、週末、甚至夜半，想起一些「工作上或許可以改進的地方」，而在電腦前敲敲打打、修修改改。
或許，就是對於許多事情「放不下」的關係，所以會顯現出「工作狂熱」的現象吧。但是，我總不願把工作就只當成「為了賺錢」而工作，總希望還能得到些「成就感」、還能對其他人有一些貢獻。
有時，我會對無法陪寶寶玩上一段時間而感到愧疚。她可是真心誠意地邀請我和她一起玩「茶犬」的呢（她現在擁有五隻麥當勞茶犬、五隻扭蛋得來的小茶犬、還有一隻更小的麥茶犬 --- 小傢伙說是另外一隻的弟弟）。可是，陪著她玩著類似辦家家酒的茶犬遊戲，約莫二十分鐘後，我就感到坐立難安（覺得做工作相關的事情似乎更重要些）。
有時，當太太忙碌，而自己有些空閒時，也會感到有些歉意，而想幫忙做些家事。但是，自己有空的時間通常很短（尤其是，需要做些工作相關事情的時候）、處理家事的技巧也差。更糟的是，做了一陣子後，經常容易感到疲累。
有時，則是對父母、兄弟姊妹、還有其他家人感到虧欠。自己似乎總是顯得「沒有時間好好地陪伴家人」。是真的因為工作的關係，還是自己一直下意識地在逃避呢？
因此，歲月經常是在愧疚中，日復一日地度過。我不曉得，是否大家都能在工作與日常生活間，取得良好的平衡點；但我確實希望，自己能夠做好份內的工作（表現得突出些，當然更好，但這樣或許就算是奢望吧）、並陪伴家人度過溫馨的每一天。
星期五, 1月 20, 2006
prototype 與 pre-β 的差異
這幾天頗為忙碌，但卻總覺得在實質上沒有取得什麼進展。
上週五實驗室 meeting。項老師說，希望以我目前的 prototype 為基礎，弄個「系統」讓歷史系的一些人試用看看。聽到這樣的「需求」，我的臉一下子就綠了。哎，prototype 與 pre-β 差異是「很大」的耶！
對我而言，prototype 的幾項主要功能是：提供團隊成員研究討論的基底、素材、與系統概貌，並在原型開發中，辨識出系統開發前期可能產生的風險。pre-β 版本，目的則在於提供真實的使用者試用，取得良好的回饋，並提供對正式系統的建議。要給他人試用，需要考慮相當多不同的層面。例如，安全性的控管，要做到什麼程度？是否要建立個人的 profiles？連線是否採取 session-oriented 的機制？系統可以提供多少人同時上線？還有，資料的品質，必須處理到什麼地步？
因而，這幾天幾乎又都是在重複做資料處理、資料轉換的工作。要給真實的使用者試用，資料就必須有相當的品質，不能含有「難以忍受」的錯誤。之前不是花了很多錢，建立了 metadata 來詮釋文件嗎？應用這些人工處理過的 metadata，應該比自動擷取的方法，有較好的資訊的品質吧。
但事情沒有這麼簡單。Metadata 既然是人工處理，就會有人為的疏失。舉個例子好了，「光緒十一年」竟然可以對應到西元 1866、1885、1886 年（1866 年應該是錯誤的）？還有，依日期欄位的規定，資料應該至少有「年份」的資訊，但為什麼可以看到「七日」、「五月二十三日」、甚至「署福建巡撫閩浙總督崔應階」這樣的資料呢？
在資訊處理的流程中，上游的資訊一旦品質不夠好，下游的處理就會事倍而功半。這時，就彰顯出傳統的 Waterfall（瀑布式）開發流程的缺點了。在瀑布式開發流程裡，每個開發階段都是明確的，上游必須經過嚴格的品質控管，才能將資料（或程式）轉給下一步的開發者。因此，下游不應該收到品質不夠好的東西。但實務上，我們也都知道，要保證上游資訊的品質，成本非常高；下游的處理者，就是會收到品質不夠好的半成品。
那麼，我們該怎麼辦呢？把責任推給撰寫 metadata 的人員，責怪她們不夠用心，並且等到她們將資料都修改好，才進行下一個開發步驟；還是把不夠好的系統丟給使用者，讓使用者自己去過濾篩選資料，並說明「自己只是中介者、只負責程式開發」呢？
因為兩邊都無法接受，我就只能在中間階段的處理中，盡量加上錯誤篩檢的機制。這樣一來，當然就會消耗許多寶貴的時間了。
我想，在方向上，項老師是對的：系統終究必須讓 real users 測試。然而，沒有經過良好的規劃，以為 prototype 與 pre-β「感覺起來差不多」，其實是很大的失誤。系統開發人員，還真是「苦命」啊！
而這下子，自己事情也變多了。至少，已經超過我原先的預期了（我原本只想做個 prototype，之後就由其他人接手）。我必須花時間思考一下，自己想將這個 pre-β 版本定位在何處。即使這個版本的使用說明是由別人負責的，即使這個版本只需做非常陽春的安全控管、連線控制、profile 管理、使用者介面調整、效能調校、或者系統品管與程式除錯，要考慮的事情都比單純的 prototype 複雜許多。
上週五實驗室 meeting。項老師說，希望以我目前的 prototype 為基礎，弄個「系統」讓歷史系的一些人試用看看。聽到這樣的「需求」，我的臉一下子就綠了。哎，prototype 與 pre-β 差異是「很大」的耶！
對我而言，prototype 的幾項主要功能是：提供團隊成員研究討論的基底、素材、與系統概貌，並在原型開發中，辨識出系統開發前期可能產生的風險。pre-β 版本，目的則在於提供真實的使用者試用，取得良好的回饋，並提供對正式系統的建議。要給他人試用，需要考慮相當多不同的層面。例如，安全性的控管，要做到什麼程度？是否要建立個人的 profiles？連線是否採取 session-oriented 的機制？系統可以提供多少人同時上線？還有，資料的品質，必須處理到什麼地步？
因而，這幾天幾乎又都是在重複做資料處理、資料轉換的工作。要給真實的使用者試用，資料就必須有相當的品質，不能含有「難以忍受」的錯誤。之前不是花了很多錢，建立了 metadata 來詮釋文件嗎？應用這些人工處理過的 metadata，應該比自動擷取的方法，有較好的資訊的品質吧。
但事情沒有這麼簡單。Metadata 既然是人工處理，就會有人為的疏失。舉個例子好了，「光緒十一年」竟然可以對應到西元 1866、1885、1886 年（1866 年應該是錯誤的）？還有，依日期欄位的規定，資料應該至少有「年份」的資訊，但為什麼可以看到「七日」、「五月二十三日」、甚至「署福建巡撫閩浙總督崔應階」這樣的資料呢？
在資訊處理的流程中，上游的資訊一旦品質不夠好，下游的處理就會事倍而功半。這時，就彰顯出傳統的 Waterfall（瀑布式）開發流程的缺點了。在瀑布式開發流程裡，每個開發階段都是明確的，上游必須經過嚴格的品質控管，才能將資料（或程式）轉給下一步的開發者。因此，下游不應該收到品質不夠好的東西。但實務上，我們也都知道，要保證上游資訊的品質，成本非常高；下游的處理者，就是會收到品質不夠好的半成品。
那麼，我們該怎麼辦呢？把責任推給撰寫 metadata 的人員，責怪她們不夠用心，並且等到她們將資料都修改好，才進行下一個開發步驟；還是把不夠好的系統丟給使用者，讓使用者自己去過濾篩選資料，並說明「自己只是中介者、只負責程式開發」呢？
因為兩邊都無法接受，我就只能在中間階段的處理中，盡量加上錯誤篩檢的機制。這樣一來，當然就會消耗許多寶貴的時間了。
我想，在方向上，項老師是對的：系統終究必須讓 real users 測試。然而，沒有經過良好的規劃，以為 prototype 與 pre-β「感覺起來差不多」，其實是很大的失誤。系統開發人員，還真是「苦命」啊！
而這下子，自己事情也變多了。至少，已經超過我原先的預期了（我原本只想做個 prototype，之後就由其他人接手）。我必須花時間思考一下，自己想將這個 pre-β 版本定位在何處。即使這個版本的使用說明是由別人負責的，即使這個版本只需做非常陽春的安全控管、連線控制、profile 管理、使用者介面調整、效能調校、或者系統品管與程式除錯，要考慮的事情都比單純的 prototype 複雜許多。
星期一, 1月 16, 2006
寶寶感冒過敏記
寶寶感冒後，又發現有過敏的症狀。為此忙碌了許久。
先是去看國泰的醫師。開了感冒、支氣管擴張的藥，吃了兩天，卻發現有過敏的症狀。
這下子怎麼辦呢？在去看同一位醫師，還是換一位對過敏比較有專長的？上網找了找，決定到馬偕醫院看小兒過敏科。醫師說，這是「長期累積」的結果，要我們把家裡的布沙發之類家俱「通通換掉」、然後開了一些藥、還要寶寶抽血檢查。扎了兩針，寶寶哭了許久。
但是幾天下來，情況好像沒有太大的好轉。於是，我們又再回頭看國泰的醫師。她說，馬偕醫院開的藥，含有類固醇，對小孩子不好。於是，又換用這個醫師開的藥。
馬偕的醫師還開了回診條，所以我們過了一週後，再去看診一次。這回，馬偕的醫師護士甚至說，過了十天咳嗽沒有康復，就是有氣喘的徵兆，還開了氣喘的噴劑呢。
為了該不該給寶寶服用噴劑，我們掙扎了許久。最後，我們決定再去找台大的小兒過敏科醫生看診。這位醫生聽了聽寶寶胸腔的聲音，說她的肺部很健康，應該沒有氣喘。然後，她看了看馬偕開的藥，說這些藥都開得太重了，不適合年紀小的孩童。
我覺得，馬偕醫院的醫師，實在太沒有醫德了。他怎麼可以未詳細問診、聽診、看診，就開了份量頗重、甚至含有類固醇的藥呢？太太說，她再也不要帶寶寶去馬偕看這位醫生了。
可是，病患就是這麼無助呢。醫師開了藥，我們竟需在「是不是該給寶寶服用」下掙扎。因此，找到值得信賴的醫生，就顯得相當重要。
是的，我們需要的是「信賴」。在這個講求快速的社會中，信賴已經逐漸變得稀少而珍貴了。
先是去看國泰的醫師。開了感冒、支氣管擴張的藥，吃了兩天，卻發現有過敏的症狀。
這下子怎麼辦呢？在去看同一位醫師，還是換一位對過敏比較有專長的？上網找了找，決定到馬偕醫院看小兒過敏科。醫師說，這是「長期累積」的結果，要我們把家裡的布沙發之類家俱「通通換掉」、然後開了一些藥、還要寶寶抽血檢查。扎了兩針，寶寶哭了許久。
但是幾天下來，情況好像沒有太大的好轉。於是，我們又再回頭看國泰的醫師。她說，馬偕醫院開的藥，含有類固醇，對小孩子不好。於是，又換用這個醫師開的藥。
馬偕的醫師還開了回診條，所以我們過了一週後，再去看診一次。這回，馬偕的醫師護士甚至說，過了十天咳嗽沒有康復，就是有氣喘的徵兆，還開了氣喘的噴劑呢。
為了該不該給寶寶服用噴劑，我們掙扎了許久。最後，我們決定再去找台大的小兒過敏科醫生看診。這位醫生聽了聽寶寶胸腔的聲音，說她的肺部很健康，應該沒有氣喘。然後，她看了看馬偕開的藥，說這些藥都開得太重了，不適合年紀小的孩童。
我覺得，馬偕醫院的醫師，實在太沒有醫德了。他怎麼可以未詳細問診、聽診、看診，就開了份量頗重、甚至含有類固醇的藥呢？太太說，她再也不要帶寶寶去馬偕看這位醫生了。
可是，病患就是這麼無助呢。醫師開了藥，我們竟需在「是不是該給寶寶服用」下掙扎。因此，找到值得信賴的醫生，就顯得相當重要。
是的，我們需要的是「信賴」。在這個講求快速的社會中，信賴已經逐漸變得稀少而珍貴了。
星期三, 1月 11, 2006
畫蛇添足
前些日子把「從前未完成論文」修改後的前半段先拿給項老師看，昨天中午取得回應。
坦白說，一時之間是有些傷心。怎麼回事呢？原來，自己多日來，輾轉反側、挖空心思寫的許多論述，本來奢想可以得到比較多的正面回饋；但實際上這是做白日夢。論文依然問題重重：
其實我一直都有畫蛇添足的毛病。主要是，覺得自己花了心力去思考許多層面，下意識裡捨不得割愛。昨晚想了想，老師說的冗餘、定義（引用）不清、「不知道想表達些什麼」部分，還真的不是那麼需要。畫蛇添足，不但多餘，連蛇的應有樣貌也失去了。
坦白說，一時之間是有些傷心。怎麼回事呢？原來，自己多日來，輾轉反側、挖空心思寫的許多論述，本來奢想可以得到比較多的正面回饋；但實際上這是做白日夢。論文依然問題重重：
- 單字拼錯、文法錯誤：通常是單複數弄錯了（許多地方是很明顯的錯誤；我猜是自己多次修改後，沒有好好地再校對一遍的關係。）
- 描述的方式笨拙（通常是因為英文程度不夠好吧。）
- 敘述不清、不知所云（除了英文程度不好，論述的條理性也不夠。因此有些地方會說著說著 miss the point，脫離了應強調的主題。）
- 引用失當（這應該是我自己的問題。許多假設引用久了，就以為別人也理所當然該知道；有時，甚至自己會延伸出一些新的意涵而不自知。）
- 畫蛇添足（有些論述不需重覆說明、有些假設與此論文無甚關係。無甚關係的論述應當勇於割捨。）
其實我一直都有畫蛇添足的毛病。主要是，覺得自己花了心力去思考許多層面，下意識裡捨不得割愛。昨晚想了想，老師說的冗餘、定義（引用）不清、「不知道想表達些什麼」部分，還真的不是那麼需要。畫蛇添足，不但多餘，連蛇的應有樣貌也失去了。
星期一, 1月 09, 2006
選擇的弔詭
終於把「選擇的弔詭」這本書看完了。
大致上，一開始看還頗有感觸，但書看到後來就漸漸麻木了。導論寫得好，結論也想看，但中間的許多鋪陳就顯得稍冗贅了些（這本書，有一半的篇幅是在說明：為什麼選擇這麼痛苦）。
有選擇，比沒有選擇好。但現代人比從前的人選擇多，卻似乎沒有比較快樂？
原來，選擇也是一項負擔。有時，甚至會因「不確定是否選錯」而苦惱。尤其是，選擇有機會成本，選了一項，就表示捨棄了其他所有的選項。此外，人有「寧為雞首、不為牛後」的傾向：滿足感並是不建立於客觀的基礎（例如，實際上賺比較多錢），而經常在於主觀的比較（例如，雖然實際上賺得少，但比身旁的人都要多）。
人還有「適應性」的特質：一件美好的事物，帶來的愉悅都是短暫的。隨著時間的流逝，愉悅的感覺就會漸漸褪去，剩下的只有舒適感而已。而每個人，應該都可以舉出一長串適應性的例子。例如，小時候我覺得蝦味先很好吃，但漸漸地就「適應」了，覺得它不再那麼美味；剛買筆記型電腦時，帶著它四處遊走，覺得好棒，但習慣後，也就只感覺到方便而已。
於是，書末的建議「竟」也類似於老生常談：
大致上，一開始看還頗有感觸，但書看到後來就漸漸麻木了。導論寫得好，結論也想看，但中間的許多鋪陳就顯得稍冗贅了些（這本書，有一半的篇幅是在說明：為什麼選擇這麼痛苦）。
有選擇，比沒有選擇好。但現代人比從前的人選擇多，卻似乎沒有比較快樂？
原來，選擇也是一項負擔。有時，甚至會因「不確定是否選錯」而苦惱。尤其是，選擇有機會成本，選了一項，就表示捨棄了其他所有的選項。此外，人有「寧為雞首、不為牛後」的傾向：滿足感並是不建立於客觀的基礎（例如，實際上賺比較多錢），而經常在於主觀的比較（例如，雖然實際上賺得少，但比身旁的人都要多）。
人還有「適應性」的特質：一件美好的事物，帶來的愉悅都是短暫的。隨著時間的流逝，愉悅的感覺就會漸漸褪去，剩下的只有舒適感而已。而每個人，應該都可以舉出一長串適應性的例子。例如，小時候我覺得蝦味先很好吃，但漸漸地就「適應」了，覺得它不再那麼美味；剛買筆記型電腦時，帶著它四處遊走，覺得好棒，但習慣後，也就只感覺到方便而已。
於是，書末的建議「竟」也類似於老生常談：
- 如果能學著滿意於舒適的感覺，當適應現象發生時，就不會那麼失望；
- 若能有意識地對美好經驗或抉擇心存感恩，對不好的經驗淡然處之，就可以大大改善主觀經驗；
- 在這個複雜多變、充斥各種選擇的世界裡，學會滿足，才可能得到內心的寧靜。
星期四, 1月 05, 2006
星期二, 1月 03, 2006
關於人的適應現象
「選擇的弔詭」提到，我們會逐漸習慣新事物，然後把一切視為理所當然。
而當你習慣、適應了各種樂趣的來源，這些就不再是樂趣的來源了。更糟的是，新的經驗也可能會改變參考點，使得原本已經夠好或甚至更好的事物，在經歷過新奇的經驗後，顯得不夠美好。
書中提到一個相當著名的實驗，比較了兩種際遇的快樂程度。其中部分參與者在過去一年中，贏得五萬到一百萬美元不等的彩金；其他參與者則因為意外事故導致半身癱瘓。當然啦，若實驗結果是「彩券得主比癱瘓病人快樂」，那就一點也不奇怪；但令人驚訝的是，經過數年，彩券得主並沒有比其他人快樂！（如果在彩券公布的第一時間詢問，得主的快樂程度都接近滿分；但經過一段時間後，就會逐漸習慣新情況。）
於是，為了得到樂趣，人必須不斷追尋更新鮮的愉悅感。但適應現象，卻說明了這種「樂趣不斷歸零」的苦果：就如同在跑步機上，不論跑得多快，只不過一直在原地打轉。
書中也提到，
而當你習慣、適應了各種樂趣的來源，這些就不再是樂趣的來源了。更糟的是，新的經驗也可能會改變參考點，使得原本已經夠好或甚至更好的事物，在經歷過新奇的經驗後，顯得不夠美好。
書中提到一個相當著名的實驗，比較了兩種際遇的快樂程度。其中部分參與者在過去一年中，贏得五萬到一百萬美元不等的彩金；其他參與者則因為意外事故導致半身癱瘓。當然啦，若實驗結果是「彩券得主比癱瘓病人快樂」，那就一點也不奇怪；但令人驚訝的是，經過數年，彩券得主並沒有比其他人快樂！（如果在彩券公布的第一時間詢問，得主的快樂程度都接近滿分；但經過一段時間後，就會逐漸習慣新情況。）
於是，為了得到樂趣，人必須不斷追尋更新鮮的愉悅感。但適應現象，卻說明了這種「樂趣不斷歸零」的苦果：就如同在跑步機上，不論跑得多快，只不過一直在原地打轉。
書中也提到，
- 「人顯然無法準確預測各種經驗將會帶來的感覺」（高估喜樂的影響）
- 「不管是多麼珍貴的抉擇，都不會對生活造成太大的轉變，但我們有時仍以為抉擇會大大地改變生活」（哦，真的是這樣嗎？有時，我還真以為抉擇可以大大影響生活呢。早個幾年取得學位、選擇到一份好工作、甚至中個樂透頭彩，經過數年後，影響真的如此微不足道？）
- 「許多對人生的失望，固然是事後覺醒，其實也經常是對適應現象的錯估」
訂閱：
文章 (Atom)