讀前言的壞處
家人送我的第一本英漢辭典是 1988 年版、台北大陸書店的《大陸簡明英漢辭典》。我沒有確實的數據，但我相信這應該是台灣某個年代最通行的英語詞典之一，因為我後來不斷在各種台灣需要用到外語的辦公室看到這套印刷精美的小書。
以送小孩第一本英漢辭典來說，這實在是個很糟糕的選擇。我不怪我爸就是了，因為他們那個年代學英文，也沒有人教過他們什麼是一本好辭典。即使中學時代幾位師大畢業的老師所陸續推薦的辭典也都很糟糕。我一直到了自己購入朗文的袖珍本《進階英漢雙解詞典》，才終於覺得詞典是可以拿來查拿來讀的（那本辭典很妙，是為了香港中學生設計的，閱讀體驗跟台灣流行的老辭典很不同）。
我剛拿到家人送我的辭典，先讀了〈前言〉，這一讀就竟然懷抱了一個長達十餘年的疑問，一直到最近才豁然開朗。作為《大陸簡明辭典》 1973 年版原序的〈前言〉是這麼說的，粗體部分是我標的：
因為編辭典是那樣費時間及人力，我們決定走一條特殊的路，要在較短期之內有可用的辭典問世，隨後就進行修訂使其在十年以後完成一本合於我們理想的辭典。辦法就是完全拿一本好的外國的英語辭典為藍本。最後決定的藍本是日本三省堂收錄八萬字的 New Concise English-Japanese Dictionary。[…]
我們借重於「藍本」的，首先是其取材，其次是編輯排列體裁和所用的符號，以及解釋。藍本頁數的維持不變使排版工作減輕了一半以上，更是減輕了編印字典的人最頭痛的校對工作；為了維持原頁形狀使字間稀疏不能均一是我們深以為憾的，改編時一定會改善。
我第一次讀到前言，就很好奇，到底什麼是「為了維持原頁形狀使字間稀疏不能均一」呢？
答案當然在很多年之後就揭曉了，特別是有機會在日本旅遊逛書店的時候，翻到序文提到的那本「英和辞典」。於是終於了然於心。
多年後再和出版界任職的學長還有長輩談起此事，才驚覺編辭典是不折不扣的資本密集的終生志業，幾乎可以斷言，要不就是國力，要不就是要有志業的召喚，才有可能自主編印辭典。有一些屬於某個年代的方便法門，台灣不知道可不可以說漸漸透過了那樣的方便法門來到了彼岸。只是那並不代表從此就無再需努力之事，事實上可能是相反的。
未來的書本
丟了不少工具書，下一輪要丟家裡的青少年百科。
以前羨慕家裡有大套百科全書的人。慢慢的就知道，百科全書根本不可能真正「百科」。
同樣的事情也發生在字典。尤其當你知道大多數（我們念書時的）英漢字典的出處與編輯方式，那實在不是後來採用新方法編輯的字典能比。一用就知道差別在哪裡了。
過往具有「權威」地位的工具書、參考書、字典、百科全書、地圖，也變成了必須時時更新的物品時，你會發現，「知識」的壽命已經遠遠短於西洋印刷術發明以來所承載他們的媒介（紙張事實上是最耐久的媒介之一）。
討論「電子書是否能挽救出版業」是個錯誤的問題。根本的問題是，知識的來源、傳播、更新、汰換的方式在改變。不靠紙張來流通、傳授知識，已經在很多領域慢慢成真了。
關於遠行
楊牧，〈下一次假如你去舊金山〉，19921:
我將自己關在旅館房間裡，因為我想要寫點甚麼 [sic] 才好。
「寫甚麼呢？」
「我心裏有數。」
「問問看不可以嗎？」
「我不喜歡將我的寫作告訴人。」
「你不說也可以。」你說：「迢迢長途來到一個美麗的城市，陽光和花，你竟把自己關起來。那麼，你何不索性留在家裏呢？」
「我一向如此──巴黎，阿姆斯特丹，紐約，京都，我都曾經去了就將自己關在房裏。」
「關在房裏？」
「寫點甚麼。」
「寫遊記？」
「我是不寫遊記的。」
某一個時代許多出版社為了促銷文學書而推出的隨身讀系列，這些尺寸不方便收藏，內容也不算真有價值的系列，這次整理家裡都一併出清掉了。
不過，隨手翻到短文的這一段對話，我想，我們這些每到一個新地方，就把自己關在居所，接著無線網路寫點什麼的宅宅們，應該可以釋懷了吧。
moji:
虎視眈眈 (via 4コマブログ: 漢字ネタ)
link: うごメモはてな - ヨウヘイさんの作品
把「虎視眈眈」四個漢字的上方截掉，就會剩下日文的 “ru ru ru ru”。
「共享辦公空間」的需求確實存在
NPR 的報導：
New Work City is part of a trend that started a handful of years ago on the West Coast. Newly mobile tech workers with laptops liked their freedom but still missed the human interaction they got from going to an office. So they formed meet-up groups: casual, once-a-week deals at different locations — sometimes even people’s living rooms. Today, Bacigalupo says more and more people are working independently — either by choice, a layoff or both.
[…]
New Work City is just breaking even, and that’s OK with its founders. They say for-profit spaces tend to operate like impersonal office suites and miss what co-working’s about — community.
根據他們的價目表，以紐約的消費跟租金水準，應該是還算合理的。倒是台灣有沒有可能也進行這樣的空間共享計畫呢？
母船 in-n-out
zonble:
竊以為，一般來說，在蘋果的平台上，第二好用的應用程式，是蘋果自己寫的；至於最好用的應用程式，則是蘋果前員工離職後開自己的公司寫出來的。
蘋果前員工，例如：
當然也有反方向被「母船」吸收進去的就是了，例如：
講英文 ⇒ 國際觀; 寫火星文 ⇒ 宇宙觀。宇宙觀勝。
— By Pektiong. 大推。
我反對《健康促進法》草案
2009年12月21日台灣版《蘋果日報》：
衛生署國民健康局正規劃《健康促進法》草案，擬針對高熱量、低營養食品如包裝飲料、糖果糕點、速食、酒類等課稅，盼藉此減少不健康產品消費。如進展順利，最快後年起實施，台灣將是全球第一個針對「不健康食品」課稅的國家。有學者質疑執行成效，也有民眾抱怨政府想盡辦法課稅，以後連喝飲料都得省。
國健局長邱淑媞昨說，草案初步構想仿效菸品健康捐，先針對有營養標示的包裝食品，如罐裝和瓶裝飲料、糖果、餅乾、糕點、速食、酒類等，就營養密度（每單位熱量所含營養素成分）或含糖量、含鈉量等，訂出標準值，超標者課稅，未來希望擴及執行上較困難的餐飲業和散裝食品。
據草案構想，課稅所得將補助民間健康促進團體或回饋健保，盼減少民眾購買不健康產品，並鼓勵業者研發健康食品。邱淑媞指出，草案已在衛生署晨會口頭報告，獲衛生署長楊志良大力支持，待召集各界討論、修改得更周延後，明年中送行政院、明年底送立法院，若順利則可望後年實施。
我反對。我認為政府沒有資格、沒有理由、沒有權力認定什麼是「健康」的食品。政府只應該把關食品「安全」。
更何況，「課稅所得將補助民間健康促進團體或回饋健保」，除了財政程序的問題（為什麼健保財政的問題，不由健保費機制來解決？1），更令人狐疑的是為什麼政府的錢要拿去補助納稅人無法監督的「民間健康促進團體」2。
相關討論，有例如 Gary Becker, “A Tax on Sodas?” 以及 Richard Posner, “A Soda or Calorie Tax to Reduce Obesity” 。
我反對我們納稅營運的政府草擬這樣的法案。
意義的源頭
我還蠻常用「意義的源頭」這個詞的。真要考察起來這是個很大的題目，先畫個幾張圖做個筆記。
通常說來我們都是這麼以為的：
通常社會會希望我們認識的是這樣：
實際上則更複雜一點：
學校不教的工作技能之一：使用 IDE 調整 compiler 參數
事實上不要說是學校不教，絕對多數教你寫程式的書，也不會教這個技能。越是低階的語言（例如 C）這問題就越大。
寫程式是解決問題的主體，但是要會調 compiler 參數才能把事情完成。
我第一個會用的 C compiler 及 IDE 是 Turbo C。即使是 16 位元的 PC 上面，這種不算業界級的工具（當時我認識的很多人甚至歧視 Turbo C 的使用者，認為要用 Microsoft C 才是正道），都至少有 10 個主要參數是隨便一個 project 會調整到的。當時經常要做的決定有：要用哪種定址模式 (small, medium, large, huge)、字元要不要當成 unsigned char、要不要調整字串常數的位置安排、要不要做 struct 的 alignment 等等。
雖然來到了 64 位元的時代，那些參數以及背後的基本精神其實改變得不大。當然要決定跟能改變的參數就更多了，例如 exception handling 的作法、記憶體管理策略、要不要提出安全性警告、symbol visibility、最佳化選項等等。任何一個主要平台的 C compiler 連同 toolchain (linker, resource compiler, manifest tool, code signing tool) 大概隨時都有 100 個參數可以調整，而且每個專案仍然大概有機會調整大約一打左右的參數，因此對這些參數有個概括性的掌握，就變得非常重要。
我覺得困難的地方在於，這東西要怎麼教導、傳授給別人。說來調整參數跟使用 IDE 一樣可能都得靠經驗的累積。另一方面好比像 iPhone SDK 這樣的開發工具，本身就以極高的速度在演化，而且開發工具甚至仍然每季都有一點面貌的不同，如果因此而必須花很多時間在解決使用 IDE 與調整參數，對專案的進行可能是很不利的。
目前能想到的粗淺建議是，任何有心投入新平台開發的人，一定要親自建立至少五六個研習用的專案（我稱之為 study project），而且類型或針對的發佈環境要不太一樣，才能夠摸清楚一個梗概。這東西只靠當 code contributor 參與計畫或是跟隨別人已經建立好的 build system 是不行的。好比說，ObjectiveFlickr 論壇上還有我私下就經常收到來信詢問怎麼把 OF 加到他們的軟體專案，幾乎佔了所有問題的 3/4 ，但麻煩的地方就在於這東西如果沒有對 Xcode 以及 gcc 變數有基礎掌握，根本難以用言語指導。
最後是一點個人經驗。2007 年的時候因為一個專案的需要，我開始寫一點 Windows 的程式。在此之前我寫了幾年的 Mac 程式，而且很多年沒再使用過微軟的開發工具。這再一次說明了只會寫程式是不足以成事的──如果沒辦法在 Windows 上使用正確的開發工具，再多的 code 也無法解決專案的問題。我的確用上述的方法，自己設計了一個不太正式也不嚴格的學習計畫，但還是盡可能把所有 Visual Studio C++ 環境中所提供的專案範本給都開來建立一遍，並了解每一個範本建立出來的 solution 以及 project file 的設定差距。當然，我還有一點 Windows 軟體開發的殘餘記憶，憑著記憶大概知道 EXE/DLL 的專案類型和設定有別，Windows 也有像使用靜態連結程式庫或是 CRT DLL 程式庫的選項。有了這些 study project 的幫助，我才得以掌握 Visual Studio 說來並不成功的設定功能（C# 的 IDE 一定程度上改善了不少 C++ IDE 的缺陷，可惜我負責的部份用不上 C#）。只是，我還是不知道要怎麼把這大約 100 多個選項（其中我必須調整的約有 20 多個）確實代表的意義跟工作方式，有系統地傳達給其他人了解。
3.
