我們來看看這支可以打電話的 iPod 問世之前的世界：你從通訊行買來一支手機之後，除了電話功能之外，就是一堆電信商預先幫你裝好的軟體，這些軟體想刪也刪不掉，只要不小心點下去，電信商就從下個月帳單裡頭開始收取額外的電信費用。

一般使用者往往不知道怎麼安裝想要的手機軟體，而有心想要開發手機軟體的廠商，也不知道怎樣將軟體送到使用者的手上，唯一能夠獲利的方式就是讓電信商預裝你的軟體，跟著電信商一起誘導使用者按下會增加電信費用的功能，而你的軟體能不能出現在使用者的手機中，靠的不是你對軟體開發有多少熱誠，對軟體品質多麼吹毛求疵，對市場上的需求觀察多麼敏銳，靠得是你和電信商的關係，靠得是吃了多少飯喝了多少酒。

然後我們終於有了一支手機，裡頭不預裝那些會跟你另外收電信費的軟體，想要什麼額外功能，可以按照意願從線上商店購買世界任何角落開發出的軟體，軟體廠商也可以省下應酬費用用一定的價格將產品販售到全球，蘋果這家公司幫你搞定了全球金流。在 iPhone 之前，Rovio 這樣的公司能做的就是為 EA、Namco 代工，有了 iPhone 之後，Rovio 推出席捲世界的 Angry Birds。

那 iPod 是什麼呢？一支 MP3 播放器？MP3 也不是蘋果的發明，對吧？

iPod 是一支整合 iTunes 與 iTunes Music Store 的 MP3 播放器，讓使用者可以從線上合法購買、下載音樂後再同步到行動裝置上收聽。在 iPod、iTunes 與 iTMS 這整套服務之前，MP3 是盜版的代名詞，提到 MP3 想到的就是 P2P，就是 Napster，是地檢署檢察官搜查成大宿舍，是唱片業者與使用者之間相互恐懼：使用者害怕巨大的唱片公司對單一個人提出版權告訴，唱片公司眼中則是巨大猖獗的盜版，而蘋果這一整套服務的出現，改寫什麼叫做 MP3。

Steve Jobs 創辦了兩家電腦公司，蘋果與 NeXT。1984 年麥金塔電腦推出之前，全錄就已經有了圖形介面工作站的雛形，可是蘋果將圖形介面的個人電腦變成放在家裡的裝置。接著同年有了 PostScript，隔年有了 Apple Laser Writer，我後來才在九零年代從從 PageMaker 4.5 學到用電腦排版是怎麼一回事，雖然那個年代光是字體就還是 ATM、CID、TTF、OTF 格式這樣的一團亂帳。到了 1990 年，又出現了 Photoshop…這年頭設計師會用到的工具，都可說從這裡開始。

NeXT 的主要產品是 NeXTSTEP 作業系統與工作站，從現在的角度來看，NeXT 重要的地方在於發展了日後成為 Mac OS X 與 iOS 系統的程式語言與 framework，至於 NeXT 上面有什麼重要的應用軟體呢？在 1989 到 1990 年之間，Tim Berners-Lee 在 NeXT 工作站上，寫出了第一套網頁瀏覽器與網站伺服器，於是我們有了 Web，有了我們現在所知道的網路產業。

於是我可以在這個地方寫這段文字，於是我們也可以用瀏覽器打開 Facebook 隨便說聲死了一個資本主義的英雄、死了一個剝削勞工的 CEO，電腦、手機、MP3 格式都不是 Steve Jobs 發明的，產品也不是他生產的，他到底有什麼了不起？

是啊，英文也不是莎士比亞發明的，你也應該不會指望只有一個人就能夠演出《哈姆雷特》或是《暴風雨》，那又如何？一件事物的發明是一回事，但是重新賦予定義，改變現狀，變成人們更期待的樣子，這樣不困難嗎？以驚人的創造力產出了可說我們這個時代的最高工藝品，而這樣的作品又啟發了更多人的想像力，解放了更多人的創造力。

這樣還不夠嗎？

把工作機升級到 Mac OS X Lion 之後，在一些應用程式當中，例如系統內建的文字編輯工具（TextEdit.app）以及預覽程式（Preview）中，就遇到無法使用輸入法的問題—點選輸入法選單，我要用的輸入法選項就是灰色的，無法選用。說起來奇怪，應該不是輸入法程式本身有什麼問題，因為在其他應用程式中可以正常使用，而且之前在測試 Beta 版本的 Lion 時，也沒有遇到這個問題，用搜尋引擎找個一輪，也沒有看到其他人遇到這種狀況。

不過，既然是 Mac OS X，遇到什麼錯誤，打開 Console，總是可以撈到些訊息，找到點線索。果然，Console 裡頭看到這樣的記錄：

7/21/11 6:36:45.986 PM sandboxd: ([11590]) TextEdit(11590) deny file-read-data /Users/zonble/Work/MyInputMethod/build/Debug/MyInputMethod.app

從訊息看起來，是被 Lion 的新功能—sandbox 模式—擋住了，另外還有一份完整的 backtrace。而之所以 TextEdit 與 Preview 不能使用，而其他應用程式可以使用，就在於，目前絕大多數程式都還沒有包在 sandbox 裡頭，但是這兩套卻已經使用了 sandbox 模式；在 Lion 上面，現在可以使用 Activity Monitor，查看目前正在執行的程式，到底有沒有使用 sandbox。

講一下 Lion 的 sandbox 模式。

簡單來說，蘋果認為要能夠保障系統安全，目前許多作業系統使用 UI 警告使用者的這種作法是有問題的：目前許多作業系統中，執行新的應用程式的時候，都一直跳出對話框警告這個程式可能有安全性問題，到底要不要執行…這麼做不過是將系統安全的責任推給使用者，只要使用者按下確定，系統就不用負擔責任。但這麼一來，系統安全問題還是會繼續發生，而且這樣的 UI 非常惱人。於是，蘋果認為，不如一開始就限制各種應用程式可以做的事情，在 Lion 中加入 sandbox 設計。

於是，接下來一套應用程式如果想要在 Mac AppStore 上架，就要包含一個 Entitlement 檔案，Entitlement 還要加上 Code Signing，裡頭宣告會用到哪些權限，包括是否可以存取檔案、是否可以使用網路連線…等。而就算有了讀取檔案的權限，除了使用標準的檔案對話框元件（ NSSavePanel 與 NSOpenPanel）外，在使用者可以看到的狀況下存取檔案外，就只能夠讀取一定範圍的檔案，將這套程式能夠讀取資料的範圍，與系統的其他部分隔絕開來。

雖然還有許多程式還沒有使用 sandbox 模式，但蘋果要確保至少在 AppStore 上販賣的軟體沒有問題。而且，也看不出來蘋果打算從什麼時候開始強制要求，畢竟現在 Mac AppStore 還是要繼續支援 Snow Leopard 一陣子。

但這麼說起來，讓人實在看不出來跟輸入法之間有什麼關係—在 Input Method Kit 的架構下，輸入法軟體（Input Server）與正在使用輸入法打字的軟體（Input Client）之間，是使用 Distribuited Object 做 IPC，為什麼 Input Client 會去讀 Input Server 的目錄內容？而且為什麼會無法讀取？

盯著 Backtrace Log，來來回回搞了一陣，終於搞清楚狀況。一套軟體要知道有哪些輸入法可以用，會去呼叫 Text Input Source Services 這部份的 API，TIS API 會透過讀取輸入法程式的 Application Bundle 內的資訊（就是 Info.plist 啦）， 知道這套輸入法叫什麼名字、要用什麼圖示等等。這也就代表，各個應用程式都應該要有讀取輸入法程式 bundle 內容的能力，就算是處在 sandbox 模式，也應該要有讀取輸入法安裝目錄（/Library/Input Methods/、 ~/Library/Input Methods/ 等）的權限。

所以，回頭看看上面的錯誤訊息，有沒有看出什麼？

7/21/11 6:36:45.986 PM sandboxd: ([11590]) TextEdit(11590) deny file-read-data /Users/zonble/Work/MyInputMethod/build/Debug/MyInputMethod.app

沒錯，我的輸入法程式的 Application Bundle，根本就沒放在用來安裝輸入法的目錄裡頭，因為我在用的輸入法是直接從程式碼編譯出來的，而且之前經常改來改去，所以就直接把 build 目錄底下的 debug 版本，透過 symbolic link 的方式，連到 ~/Library/Input Methods/ 底下，這樣每次重新編譯，就只要把輸入法的 process 給 kill 掉就好，不必每次都將新版的程式複製一次。結果呢，就是要使用輸入法的應用程式雖然可以讀取輸入法安裝目錄，但是並沒有讀取 symbolic link 過去的目錄的全縣。

也難怪在網路上也查不到其他人遇到這個狀況，想來也沒有多少人會這樣安裝輸入法嘛。

這幾年工作下來，也陸陸續續遇到一些 API，有的是開放的，有的是文件上面就打上個「極機密」字樣。不管是哪種，其中不少，實在讓人不禁眉頭一皺。

首先，很多的 API 規劃似乎都以為 client 軟體都不會出問題，都不需要測試，於是做出讓 client 端無法做自動測試的規劃。這種問題主要發生在開放 API 上，像有些服務一方面開放 API，一方面又設定了什麼禁止灌水、禁止廣告機器人、禁止濫發沒有意義內容干擾其他使用者…這類管理規則，但，client 軟體做自動測試時，必定需要發送一定數量的測試訊息，不能灌水就等於無法測試，無法測試就等於無法開發。

這樣的問題不難解決：想要不干擾其他使用者，又可以自動測試，就是在服務中提供一塊測試專區；但現實總是開放 API 的服務總是不會想到這點，而結果是，就算 API 公開出來，也不會有什麼人能夠為這套服務寫出什麼應用。

像 OAuth 這種流行的認證機制，也一樣讓 desktop/mobile 軟體無法自動測試。OAuth 的設計是，client 軟體想要使用某套服務時，使用者的帳號密碼不需要經過 client 端的程式，在需要登入時，直接開啟外部瀏覽器、或是 client 軟體中開啟一個瀏覽器元件，使用者在網頁表單中輸入帳號密碼，登入成功之後，server 再透過一組協定好的 callback URL，將 access token 傳回 client，client 之後只要憑這個 access token，就可以取用其他各項服務。

這麼做的好處是，因為 client 端不經手使用者的帳號密碼，可以保障使用者的隱私資料不會被 client 端取得。壞處呢，一方面，從使用者的角度來看，這到流程實在很不直覺—我明明在這套應用程式按下登入，但為什麼接下來出現的，卻是這套程式被切到背景去，另外跳出了瀏覽器畫面出來？

另一方面，就是無法自動測試—以 Mac OS X/iOS 平台來說，如果中間需要跳出網頁，那麼就無法使用 SenTestingKit 做 Unit Test，而非得要寫成一個至少有基本 UI 的應用程式，才能完成登入流程，於是變成略過基本元件的測試，直接進入 UI 階段的測試，這樣就會出現測試的盲點—到底程式有沒有問題，是到了有 UI 之後才開始檢查，但是一個有問題的基本元件，套上一個有問題的 UI，從外觀來看搞不好行為是正確的，而看不到埋在裡頭的問題。

結果就是，為了確保使用者隱私，結果犧牲了介面操作的直覺，以及 client 的測試與程式品質，做出行為又奇怪、基礎又不堅實的軟體。話說回來，後者大概也對系統安全有一定的幫助，因為會造成沒什麼使用者想用，如果是開放的 API，也沒什麼開發者想開發，怎樣的城市治安最好呢？死城。

舉個例子。美國 Yahoo! 有一套 Objective-C 的 Social SDK，看起來就沒有怎麼好好測試過—如前所述，OAuth 在登入完成後，server 會透過一組協定好的 callback URL，將 access token 傳回給 client。開發者可以選擇不要填寫這個 callback URL，在 Yahoo! 的這套 SDK 中，預設填成了「oob」，代表沒有 URL，但，如果你把這串「oob」換掉，換成你想要使用的 callback URL，居然會馬上 crash。Yahoo! 用了 OAuth，Yahoo! 自己實作一套用來通過 OAuth 認證的 SDK，做出來卻是這樣的品質。

其次，就是不但假設 client 不需要測試，甚至假設 client 都不會發生任何錯誤，不會誤解文件，不會傳錯參數。於是，你經常會遇到明明就是一份密密麻麻的 API 手冊，但就是沒告訴你一旦發生錯誤，client 端到底會看到什麼，有些更扯的連回傳資料中每個欄位到底是什麼意思都不解釋，好像只要拿到資料，就什麼人都看得懂。

實際嘗試橋接 API，就會看到各種稀奇古怪的行為。例如：

• 分明問題出在少傳了一個 GET 參數，但是 server 卻回傳 HTTP 404 錯誤，於是你花了三個小時檢查你是不是把 base URL 給打錯了…。
• 分明 API 成功的結果都是回傳 XML 資料，你也期待發生錯誤的時候，應該出現以 XML 呈現的錯誤訊息，但錯誤訊息偏偏是 HTML，裡頭的文字是：「如果您可以看到網頁中的訊息，請跟誰誰誰洽詢」—當你在寫一個處理 XML 的 client 的時候，會去特別打開瀏覽器看這個錯誤訊息網頁，才是怪事。而 XML 裡頭用的是 UTF-8 編碼，網頁偏偏是 Big5 編碼，還是套上了精美 CSS 的那種。
• 發生錯誤的時候直接回傳空字串，什麼線索都沒有。有時候，狀況是 server 沒有符合搜尋條件的資料，你期待的是至少回傳一個 XML 或是 JSON，裡頭是一個空的 array，但是偏偏卻是空字串。

同時，你經常發現，當你拿到一份 API 的時候，API 的作者往往都沒有先測試過，甚至不知道可以拿什麼工具測試自己寫出來的 API，不知道原因究竟是只要 server 可以吐出東西來就算完成工作，還是用 PHP 這類的語言寫一個拿來測試 API 的 HTTP client 真的很困難。結果呢，client 軟體在介面上出現了 XML Parser error，也要先來問 client 端這邊看到什麼訊息，一看，XML 中出現了 PHP 錯誤，或是出現了不是 UTF-8 編碼的文字…。

接下來你可能會收到一串信件，大意是，最近 server 送出的資料常常出現問題，希望 client 端可以協助修改程式，讓 client 軟體在遇到問題時，可以有效協助 server 端找出問題。可是，API 本身就完全沒有規劃錯誤處理，自己也沒有測試工具，client 軟體能夠幫上什麼忙呢？

第三，是 server 端往往沒有考慮到 client 端的連線成本。桌面環境就罷了，在手機等使用行動數據網路的裝置上，也不見得什麼人都是辦吃到飽費率，每個封包都是要花通信費用，軟體從業人員不把如何節省使用者的通信費用放在設計中，實在不怎麼道德；不過，我也不知道是不是為了鼓勵使用者辦吃到飽費率，才故意這樣設計的。

有時候你就可以看到，明明就是一個 HTTP request 可以抓完的資料，偏偏要設計成好幾個 API，分好幾次抓—每次 client 端 POST 一些東西上去，每次 request 的 HTTP header，都是封包，都是新台幣啊。

就 Desktop/Mobile 軟體來說，把可以一次抓完的資料分成好幾次抓，又很容易可以把程式寫成很難懂。Desktop/Mobile 軟體在抓取網路資料的時候，不能夠 block 住 UI，所以勢必要寫成 Async 的方式。

我假設您是一位 REST API 的工程師，之前有過 Web 前端介面的開發經驗，這樣說可能會比較好懂：client 端抓取資料，都像是在 JavaScript 中發送 AJAX request 一樣，要使用 callback function 處理回傳的資料，而因為還要去抓另外一個 API 的資料，所以這個 callback funtion 裡頭還要繼續發送 request，這個 request 又要有 callback，所以 callback 裡頭又有 callback，indent 多到可能 80 個空格都塞不完需要折行，或是拆成好幾個小的 function 相互呼叫來呼叫去，最後讓人搞不清楚程式的進入點在哪裡。況且在 client 端真正可以拿來做正事的語言，要寫 callback 的時候，還不像 JavaScript 那麼好寫。

而如果這幾個 request 之間沒有相依性，不需要一個抓完才抓下一個，規劃 server API 的時候就是期待 client 端一次分送好幾個 request，把不同 endpoint 的資料抓回來，那 client 端大概就需要把這些 request 放在不同的 thread 當中，原本沒必要用到 multithreading 的程式也非得用到 multithreading 不可。如果是不同 thread 中不同 request 回傳的資料，還要合成一筆資料，那又有可能把資料寫爛，甚至程式 crash。

第四。你經常會覺得 server 端與 client 端有些地方實在沒什麼共識，例如，就 client 的角度來說，會覺得 client 寫完、QA 完成測試後，server 就不應該要有改動，因為 client 要把各種取得的資料儲存成平台的 native 格式，如果取得的資料不符合期待，該有資料的記憶體位置沒資料，很容易就會造成 p0 等級的問題—應用程式 crash。

但一些做 server 端的人，似乎是這麼想：因為 client 軟體已經散佈出去到使用者手中，想要讓全部的使用者都換成新版並不容易，但是 server 卻是在自己手裡，有什麼改動都可以立刻生效，所以從 server 下手最便捷、最省事，只要在既有的 server API 動一點手腳，不用改動 client 程式，就可以直接出現一個新功能。

於是，你不希望發生的事情，統統發生了。

你的心中於是經常迴盪這樣一首青春舞曲：

Client 寫完 server 依舊被改爛
Server 修完明天還是一樣地改
我的青春一去無影蹤
我的青春小鳥一樣不回來
我的青春小鳥一樣不回來…。

第五，或許是我個人的問題，我一看到 API 裡頭有錯字就皺眉頭。我一直在納悶，當初某個有名的大站推出 1.0 版本的 Open API 的時候，到底是在什麼狀況下，可以把「videos」拼成「videoes」。

比方說，我不久前在翻閱今年二月二十三日發行的《國際商情》雙週刊，裡頭就有一則讓人瞠目結舌的報導：〈利比亞投資商機面面觀〉，裡頭結論是，台商應該盡早在利比亞佈局。－以二月北非茉莉花滿地開花的動盪局勢來看，光是撤僑都來不及了，甚至現在聯軍都已經開始轟炸利比亞，在發生內戰的國家應該怎麼佈局呢？無論是投資反抗軍，或是投資格達費武裝鎮壓，好像都不叫做投資，應該叫做干涉他國內政？

以國際貿易報導權威自詡的《國際商情》，怎麼會刊出這樣的報導呢？以平面媒體的流程，這篇報導大概幾個月前就規劃好了，而二月初又是農曆年，雜誌社與印刷廠都不開工，所以這一齊稿件大概也要在年前完成，搞不好是在年前就印好了。雜誌社就是倚靠這樣的步調做事，但是世局的變化卻是這個樣子。

也不能因此就說這篇報導沒有價值，仔細一讀，文中倒是清楚點出利比亞為什麼會爆發革命的線索。有段文字特別用黑體字強調：「資訊不足是經營利比亞市場最困難的地方，需要長期融入當地市場，並不斷地與利比亞官方及民間接觸，建立人脈。」《國際商情》的一大特色就是用字遣詞往往相當委婉，上面那句話的意思是，當地政治腐敗貪汙橫行，需要不斷賄絡白道、打點黑道。

※

而在這個實在不怎麼寧靜的世道裡，批判是種難事，反省也是一種難事。

每每是對一件事情都還沒有發揮批判的力道，就冒出一件事情更應該批判；一件事情還沒有什麼深刻反省，就冒出一件事情更值得反省。江國慶冤死案還不知道後續發展如何，還不知道怎樣可以讓冤死不再發生，就傳出了台中夜店大火，還不知道怎樣要怎樣落實消防安全，又發生了東日本大地震，現在我們應該要開始檢討核電廠的存廢，檢討到底有沒有疏散計畫，檢討核能危機，核能電廠搞不好要爆炸了。

以個人的力量可以做些什麼呢？

首先當然是罵政府，司法冤案是國家殺人，沒有確實查核消防設施導致大火斷送青春的生命，當然也是國家殺人，而國家與電力公司和謀隱藏真相，最後出了什麼後果，更是國家殺害了千千萬萬的人。罵政府的同時，順便也修理一下媒體－我們現在有網路，我們可以一個人向世界發聲，我有了管道讓其他人知道我在罵政府，我在罵媒體，政府多該罵，媒體多該罵。

政府與媒體是要罵的，因為實在很該罵。可是每次罵完媒體，媒體也沒有什麼進步，罵完政府，政府也沒有什麼改善。而想想政府實在不怎麼能把事情做好—假如你家裡有人勸你去報考公務員，試想理由到底是因為公務員工作穩定，比較不用擔心競爭與裁員，而且在哪個機關哪個部門裡頭有什麼親戚朋友可以照應，或，當公務員可以服務鄉里，造福社稷，為國家為人民建築一條康莊大道，就可以知道為什麼。

然後呢？我們可以開始呼籲大家平時就應該關心這些問題，平時就該關心司法，平時就該注意生活中的消防設施與自身安全，平時就該規劃逃生路線與應急物資，平時就該關心全球暖化下的能源議題，以及消費文明下人類的未來。有太多事情，平時就該做。

但什麼是「平時」？所謂平時，究竟是什麼時候？是過年之外的時間叫平時？還是選舉造勢催票之外的時間叫平時？是在發生災難，發生火災、颱風、地震、走山、海嘯之外的時間？還是集會動員之外的時間？考試以外的時間？是在為失業所苦、經濟困頓之外的時間？還是台灣傲視世界漫長工時之外的時間？—話說我們也還有個責任制與科技業員工過勞死的問題沒有反省完。直覺說來人總不可能沒有「平時」，但稍微想想，又還真說不出來什麼時候叫做平時。

在台灣似乎真找不到什麼連貫的「平時」，倒是有很多個破碎的「現在」。在這種破碎的許許多多個「現在」中，倒是可以看到台灣人溫情與可愛的一面－現在發生了災難，台灣人現在就集體祝禱祈福，現在就慷慨解囊，現在就舉辦活動募捐，現在就奔赴災區，現在就開始組織動員；接下來就變成現在就攻訐誰捐款只是為了作秀，哪個藝人在募捐活動中表現不得體，誰不是去救災是去作秀，誰又來破壞運動的主體性。台灣人現在聽到災情之後，也現在就去搶購鉀片、搶購食鹽。

※

有個朋友不久前寫了幾篇文章，似乎引起一些波瀾。大意是，他以為日本今天遇到兩個大問題，其一自然是福島核電廠，其二是緊急物資沒有即時送到災區，這兩個問題都可以說是日本人自制、壓抑的民族性格造成的：因為人民壓抑，所以缺少核能議題的集體抗爭，因為媒體壓抑，所以造成資訊不透明，既沒有核電廠的真實狀況，也沒有即時揭露災民的迫切需要，逼迫政府搶運物資。從這兩個點來看，台灣媒體對日本人冷靜反應的讚譽非常荒唐，甚至日本媒體應該要學習台灣媒體。

觀點是不錯，就是脈絡不怎麼對勁。

幾篇文章中，就是舉出了日本人壓抑自制的幾點壞處，與台灣這種毫無章法橫衝直撞的好處，就下了日本反而應該來學台灣這樣的結論。可是反過來說，不自制的災民也不見得就會變成主動向政府要求權利，可能會變成趁火打劫，不自制的媒體也不見得就會變得更有能力發掘真相，反倒是散佈謠言、製造恐慌，日本地震後幾天，在台灣就看到一大串什麼 AV 女優在拍片的時候因為海嘯喪生的謠言，甚至後來還有什麼專家建議要抗輻射與其吃鹽不如吃精液的消息。台灣這種搶新聞的媒體真的可以報導更多災區真相嗎？君不見八八風災的時候，還有電視台刻意隱匿災情，好製作獨家報導。

要這樣只強調誰的好處與誰的壞處，也不是不行，關鍵變成是對誰說。

這種觀點，應該有讓日本人民與媒體更積極的效用，不過，這幾篇文章如果可以用日文寫，會更能發揮這種效果，但是用繁體中文寫，讀者是平常就對台灣媒體滿懷怨懟之情的台灣同胞，說日本媒體應該要學習台灣媒體，我不認為會有多少人接受。

而如果重點是以台灣真的變成像日本那樣會有什麼危害，來告誡台灣人不應該學習日本，又有個前提值得商榷—台灣人學得了日本嗎？恐怕探討台灣人學了一套半調子的東西有什麼危害，還實際一些，因為我看台灣人頂多也只能學個半調子的東西。

如果說台灣人能夠看到日本的一些優點，倒也是一件功德，尤其是學會落實定時做些準備，真的把一些小事情做好，有一些憂患意識，真的找出一些所謂的平時，像是每個月真的找個一天檢查一下家裡的滅火器—你真的知道離你房間最近的滅火器放在哪裡嗎？

比較可能的狀況是，你在網路上面看到一篇文章，裡頭告訴你怎樣準備一個逃難用的背包，你按了網頁上的「讚」這個按鈕，又寫了一篇留言，內容大概是「感謝分享，真是有用的資訊」，整個網頁上出現一大串這樣的留言，但就算內容多有用，最後你還是沒有拿去真的使用，你還是沒有去準備這樣一個背包，反倒是點到了購物網站上，看看有什麼個性新潮時尚郵差包。

※

台灣人真的有什麼平時的話，相信其中不少時間也花在看電視上。平常日本做了這麼多跟災難有關的電視節目，戲劇節目中日本毀滅的次數多不勝數，看個講機師空姐的電影《飛上藍天》也在講飛機故障應該怎麼辦，看個講小柴犬的《心動奇蹟》也來個大颱風大家要一起避難（但是在台灣的引起的效應大概是一堆人一窩蜂開始飼養柴犬、然後棄養），就已經做到這樣了，這次震災還是應付不暇。而台灣呢？你會期待在看《犀利人妻》的時候，看到謝安真與黎薇恩在災難中同舟共濟，展露人性的光輝嗎？

台灣電視劇裡頭所呈現的災難想像，大概就只有這樣：

女：你今天要說清楚。你到底是愛她，還是愛我？

男：…這不一樣。

女：假如，有一天發生了洪水，我跟她都掉進了水裡，我們兩個人都快要溺死了，你會先救她，還是先救我？

男：是的，我會先救她…

女：等你救完她之後，我都已經溺死了。

男：對，我會先救她，但是我會跟妳一起死。

—接著，女方張大眼睛看著男方，露出又驚又喜的神色，鏡頭轉向遠方，背景音樂淡入，D 大調卡農飄揚。而照我來看，發生洪水的時候，其實你們根本沒有必要討論先救誰後救誰的問題，以台灣人的準備來說，應該三個人都一起直接溺死。

※

有時候想想在這個世道裡頭，人與人之間的關係也還真是矛盾。

現在有了什麼議題，有太多管道可以連署、可以動員，或是在 Plurk 上面發一個訊息，或是在 Facebook 上面成立一個粉絲專頁，都可以期待收到一呼百應的回響，甚至是千應萬應。但相反地，想要走出家裡，去按一下隔壁鄰居的門鈴，討論一下大樓安全，或是社區如何因應災難，卻顯得需要更大的勇氣。—誰知道你的鄰居是不是天天在學校霸凌你家的孩子，還是你家的孩子天天霸凌人家？

以前人講修身齊家治國平天下，現在參與治國平天下管道越來越多，而怎麼修身、怎麼齊家，反而好像變得比較難了。

話說用 iPad 版本的 GarageBand 還真會讓人吃到點苦頭－將原始檔案從 iPad 上面匯出到 Mac 之後，GarageBand 2011 居然無法開啟；此外，iPad 版本也沒辦法打開我之前做的檔案。而 iPad 畢竟是一個行動裝置，稍微有一點長度，就經常一直跑出「正在最佳化效能」的畫面，而且因為記憶體不足而導致應用程式直接關閉的狀況也出現很多次。

下載（Mp3 格式）

他總像是鐘擺一般過活
從這頭不斷擺盪到那頭
有時一個人在這裡
有時一個人在那頭
他總像是鐘擺一般過活

他總像是鐘擺一般過活
從這頭不斷擺盪到那頭
有時一顆心在這裡
有時一顆心在那頭
他總像是鐘擺一般過活

一陣風，一股寒流
都能夠沒有理由就將思緒牽動
即使明知，他鄉的誘惑
也不能新奇多久

一陣風，一股寒流
都能夠沒有理由就將思緒牽動
即使明知，回家的喜悅
也不能溫暖多久

在他鄉被別人排擠
在故鄉被自己人壓迫
在他鄉總覺得委屈
在故鄉也一樣沒人懂
在他鄉是一份孤寂
在故鄉是另一種難過
在他鄉總想著回去
在故鄉卻更想逃走

從故鄉到他鄉從他鄉到故鄉從故鄉到他鄉，繼續擺動
從他鄉到故鄉從故鄉到他鄉從他鄉到故鄉，繼續擺動
從故鄉到他鄉從他鄉到故鄉從故鄉到他鄉，繼續擺動
從他鄉到故鄉從故鄉到他鄉從他鄉到故鄉，繼續擺動