使 xterm 可以顯示 256 色

如果沒有設定的話，使用 SecureCRT, Xshell, PuTTY 等工具連入 Ubuntu 時，都只有 16 色可以使用，想要可以顯示 256 色的話，要先：

sudo aptitude install ncurses-term

然後在 .bashrc 中加入

# hack for remote sessions
if [ "$TERM" == "xterm" ]; then
export TERM=xterm-256color
fi

Palm Calendar Data 2 Android

Finally, the data on my old Palm Treo 680 are sync'd to Google Calendar!

I had tried to send them through Bluetooth, but the new Android phone, Moto Defy, does not like to accept it. The tranfer is done by installing Outlook 2003 first. Install the original Palm Desktop from Treo 680 and let it sync with Outlook. Finally, use the tool kindly provided by Google to sync Outlook to Google Calendar. Boom! The data are copying to the Cloud.

[轉貼] 二顆小石頭與太陽能熱水器的故事

http://blog.udn.com/kerrier/4774755

二顆小石頭與太陽能熱水器的故事_20110108

2011/01/10 15:49:46　瀏覽325｜回應1｜推薦3

這是一個討論「什麼是專業」，與「判斷什麼是專業」的故事。

這是一個顯示消費者弱勢與無奈的故事。

[事情不是花了錢就一定能解決的]

如果二顆指甲大小、路邊就可撿到的小石頭叫你花二千元買下，你願不願意？

承上，如果你能事先預知這二顆小石頭的存在會導致你因此要額外破費五萬大洋時，那你願不願意先花二千元把它們買下以避免後面更大的損失？

悲慘的是，當你以為你花了二千元可以解決問題的同時，卻眼睜睜地看著來處理的人將問題惡化，讓你不得不額外再花五萬元來彌補這個錯。那會是什麼樣的心情？

[生活中聽聞的實例]

故事發生的背景與經過大致是這樣的：

一、某戶人家的一樓安裝了馬達抽水到頂樓的水塔，該水塔出水管線同時連接同樣位於頂樓的太陽能熱水器(此熱水器本身含有太陽能真空管與電熱棒二種供熱系統)。

二、因為從一樓馬達抽到頂樓水塔的進水量很弱，供水速度太慢以致太能陽熱水器所需的水量不足，便找來水電工處理。

三、水電工調整了水塔內的浮球裝置但未改善一樓馬達至水塔進水量的問題，卻建議該戶人家要在水塔至太陽能熱水器的供水管線之間加裝抽水馬達以解決熱水器進水量過小的問題。

四、水電工來安裝馬達修改熱水器管路並封閉熱水器原有的透氣孔，完裝完畢馬達啟動進水加壓的結果造成太能陽熱水器的結構受損，儲水桶爆桶，真空管與儲水系統間的接觸面皆漏水。

五、該水電工將新裝設的馬達管路拆掉，把太陽能加熱相關管線拔除，改成只單用電熱棒供熱的狀態(i.e. 水塔管線直接注水儲水桶，並未通過太陽能真空管加熱)。

六、該戶人家見情形不妙，質問水電工。結果該水電工僅回答這樣也有熱水可用，並匆匆走人。

七、該戶人家找了其他廠商來看，紛紛回答該太陽能熱水器的結構已受損無法維修，換同等級新品的話要五萬元左右。

八、事後，該水電工僅賠付數千元，該戶人家大事化小，認賠不追究。

故事交待完了，如果是各位的家裡遇到這等鳥事，會怪在誰的頭上？水電工？還是自己？

以日常新聞裡看到美國人將對方告上法院的案例，該戶人家必須告得水電工付出「整副全新的太陽能熱水器 + 精神賠償 + …」的高額代價才能罷休。因為這太過份了，找來專業人員的代價竟然是如此的不堪，不好好懲罰對方怎麼吞得下這口氣？是吧！

也許，有人真的是佛心來的，覺得水電工是自己找來的，做壞了也不敢責備對方，打算摸摸鼻子認裁。

[什麼是專業？]

照我的認知，專業是解決特定問題的能力。水電工的專業就是解決水電相關的能力，而這必須花上許多時間才能學到足夠的知識與經驗。一般人對 DIY 不行的，面對水電管路的問題，自然得求助於水電專業人士。消費者花了錢卻解決不了事，那就是該水電工不夠專業。

以該故事裡的情節來看，該水電工沒有釐清並解決從一樓抽水到頂樓水塔進水量太小的問題，反而建議加裝熱水器進水馬達，我覺得這是一種便宜行事的心態，而且再加一顆馬達對他又是一筆進帳。他會這麼建議很正常。

糟糕的是，該水電工專業不足，不知道這類有通氣孔裝置的太陽能熱水器的結構是無法承受馬達進水加壓的。以他想當然爾的做法裡，加壓進水時，為了不讓水外洩，便施工將通氣孔封死，但卻反而造成整個熱水器結構受損漏水這種不可收拾的結果。

(這裡附帶一提的，消費者由於相關專業不足，找來解決問題的若非親朋好友便是客戶舊識，一旦出包的時候，礙於人情不便追究，如同上述故事一般。我覺得這是消費者本身應該更改的習慣 -- 不是把事情交待給認識的人就完全不管他怎麼做，適時的瞭解是必要的。)

沒人喜歡找自己麻煩，消費者哪會料到遇人不淑，水電維修能力這種東西又不是像基金一樣有長期評比，只能靠口耳相傳，不確定性很高。這種東西想避開地雷的話，消費者只能學著「判斷什麼是專業」。

[判斷什麼是專業]

「判斷什麼是專業」的方法、管道很多，在此案例要判斷水電工專不專業，最直接的一種就是去學習水電維修的知識，比如去瞭解抽水馬達的種類特性、瞭解出水量不足的可能原因、瞭解如何故障排除……。當消費者懂的愈多，愈容易判斷水電工所做所言是不是在唬弄消費者。

該水電工並沒有解決一樓抽水到頂樓水塔的水量過小的問題，可消費者也沒覺察到，反而聽信了加裝馬達的建議，這就犯了一個無法「判斷什麼是專業」的缺失。

為什麼無法去判斷呢？因為消費者對一樓抽水馬達的規格不瞭解，他們只知道水太小，但卻無法判定正常馬達抽水量為何(其實馬達上面都清楚載明其規格，也包含每分鐘抽水量)。

[當不夠專業的消費者遇上不夠專業的水電工]

最倒楣的，消費者接受水電工建議，以為花二千元在水塔與太陽能熱水器之間的管線加裝另一顆進水加壓馬達，希望可以改善熱水器進水量不足的問題，結果專業知識不足的水電工卻使得整個太陽能熱水器結構受損。

這一受損可不得了，原有的就毀了，要換新的得花五萬元才能買到同等級的產品。

[你會不會遇到？]

這類無妄之災，相信每個人多少都碰過。消費者不禁要想：「如果我懂、我會修的話，那又何必有水電工存在的必要呢？」

處於資訊不對等的狀態下，是消費者相對弱勢不得不然的結果。

[小石頭大關鍵]

前面提過，路邊隨處可拾、指甲大小的二顆小石頭，你願不願意花二千元去買？這樣的問法籠統了些，我再形容細一點：

「若你是該戶擁有太陽能熱水器的主人，當你發現從一樓馬達抽到頂樓水塔的進水量太小而找來水電工，水電工檢查過後拿出二顆小石頭跟你收二千元，你會覺得被水電工坑了嗎？」

還太籠統？那我再解釋多一點：

「該水電工檢查水管，發現進水量太小的原因是因為管路被塞住，所以他根據判斷找出塞住的位置，進而發現是那二顆小石頭是肇事者。取出後，一樓抽水馬達可正常發揮功能，到頂樓水塔的進水量充足了，太陽能熱水器缺水的問題也一併解決了。」

現在再重問一次：

「以該戶人家欲求得正常熱水供應的狀況下，你覺得花二千元換二顆小石頭划算呢？還是等機器被弄壞了再花五萬元重新買一組太陽能熱水器划算？」

「水電工的專業知識與技術，你打算用多少錢去換？」

[行行出狀元]

下次做出「看輕某行某業、視之無足輕重」的判斷前，先想想我們自己有多少能力去取代人家的專業。否則我們都可能去遇到同樣的事。

個人看法，謹供參考。

[轉載] 21 天教你學會 C++

下面是一個《Teach Yourself C++ in 21 Days》的流程圖, 請各位程式設計師同仁認真領會。如果有必要,你可以查看這個圖書以作參照:

看完上面這個圖片, 我在想, 我學習 C++ 有 12 年了, 好像 C++ 也沒有學得特別懂, 看到 STL 和泛型, 還是很頭大。不過, 我應該去考慮研究量子物理和生物化學, 這樣, 我才能重返 98 年殺掉還在大學的我, 然後達到 21 天搞定 C++ 的目標。另外, 得要特別提醒剛剛開始學習 C++ 的朋友, 第 21 天的時候, 小心被人殺害。呵呵。

當然, 上面只是一個惡搞此類圖片, 學習一門技術, 需要你很長的時間, 正如圖片中的第三圖和第四圖所示, 你需要用十年的時間去不斷在嘗試, 並在錯誤中總結經驗教訓, 以及在專案開發中通過與別人相互溝通互相學習來歷練自己。你才能算得上是真正學會。

這裡有篇文章叫《Teach Yourself Programming in Ten Years》, 網上有人翻譯了一下, 不過原文已被更新了, 我把網上的譯文轉載並更新如下:

用十年來學程式設計 Peter Norvig
為什麼每個人都急不可耐？
走進任何一家書店, 你會看見《Teach Yourself Java in 7 Days》 (7 天 Java 無師自通) 的旁邊是一長排看不到盡頭的類似書籍, 它們要教會你 Visual Basic、Windows、Internet 等等, 而只需要幾天甚至幾小時。我在 Amazon.com 上進行了如下搜索:

pubdate: after 1992 and title: days and (title: learn or title: teach yourself)
(出版日期: 1992年後 and 書名: 天 and (書名: 學會 or 書名: 無師自通) )

我一共得到了 248 個搜索結果。前面的 78 個是電腦書籍 (第 79 個是《Learn Bengali in 30 days》, 30 天學會孟加拉語)。我把關鍵詞「days」換成「hours」, 得到了非常相似的結果: 這次有 253 本書, 頭 77 本是電腦書籍, 第 78 本是《Teach Yourself Grammar and Style in 24 Hours》 (24 小時學會文法和文體)。頭 200 本書中, 有 96% 是電腦書籍。
結論是, 要麼是人們非常急於學會電腦, 要麼就是不知道為什麼電腦驚人地簡單, 比任何東西都容易學會。沒有一本書是要在幾天裡教會人們欣賞貝多芬或者量子物理學, 甚至怎樣給狗打扮。在《How to Design Programs》這本書裡說「Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.」 (壞的程式是很容易的, 就算他們是笨蛋白痴都可以在 21 天內學會。)
讓我們來分析一下像《Learn C++ in Three Days》(3 天學會 C++) 這樣的題目到底是什麼意思:

• 學會: 在 3 天時間裡, 你不夠時間寫一些有意義的程式, 並從它們的失敗與成功中學習。你不夠時間跟一些有經驗的程式設計師一起工作, 你不會知道在 C++ 那樣的環境中是什麼滋味。簡而言之, 沒有足夠的時間讓你學到很多東西。所以這些書談論的只是表面上的精通, 而非深入的理解。如 Alexander Pope (英國詩人、作家, 1688-1744) 所言, 一知半解是危險的 (a little learning is a dangerous thing)
• C++: 在3天時間裡你可以學會 C++ 的語法 (如果你已經會一門類似的語言), 但你無法學到多少如何運用這些語法。簡而言之, 如果你是, 比如說一個 Basic 程式設計師, 你可以學會用 C++ 語法寫出 Basic 風格的程式, 但你學不到 C++ 真正的優點 (和缺點)。那關鍵在哪裡？Alan Perlis (ACM 第一任主席, 圖靈獎得主, 1922-1990) 曾經說過:
  「如果一門語言不能影響你對寫程式的想法, 那它就不值得去學」。另一種觀點是, 有時候你不得不學一點 C++ (更可能是 Javascript 和 FlashFlex 之類) 的皮毛, 因為你需要接觸現有的工具, 用來完成特定的任務。但此時你不是在學習如何寫程式, 你是在學習如何完成任務。
• 3 天: 不幸的是, 這是不夠的, 正如下一節所言。

10 年學程式設計
一些研究者 (Bloom(1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) 的研究表明, 在許多領域, 都需要大約 10 年時間才能培養出專業技能, 包括西洋棋、作曲、繪畫、鋼琴、游泳、網球, 以及神經心理學和拓撲學的研究。似乎並不存在真正的捷徑: 即使是莫扎特, 他 4 歲就顯露出音樂天才, 在他寫出世界級的音樂之前仍然用了超過 13 年時間。再看另一種音樂類型的披頭四, 他們似乎是在 1964 年的 EdSullivan 節目中突然冒頭的。但其實他們從 1957 年就開始表演了, 即使他們很早就顯示出了巨大的吸引力, 他們第一次真正的成功 - Sgt.Peppers – 也要到 1967 年才發行。Malcolm Gladwell 研究報告稱, 把在伯林音樂學院學生一個班的學生按水準分成高中低, 然後問他們對音樂練習花了多少工夫:

在這三個小組中的每一個人基本上都是從相同的時間開始練習的 (在五歲的時候)。在開始的幾年裡, 每個人都是每週練習 2-3 個小時。但是在八歲的時候, 練習的強度開始顯現差異。在這個班中水準最牛的人開始比別人練習得更多 – 在九歲的時候每週練習 6 個小時, 十二歲的時候, 每週 8 個小時, 十四歲的時候每週 16 個小時, 並在成長過程中練習得越來越多, 到 20 歲的時候, 其每週練習可超過 30 個小時。到了 20 歲, 這些優秀者在其生命中練習音樂總共超過 10,000 小時。與之對比, 其它人只平均有 8,000 小時, 而未來只能留校當老師的人僅僅是 4,000 小時。

所以, 這也許需要 10,000 小時, 並不是十年, 但這是一個 magic number。Samuel Johnson (英國詩人) 認為 10 年還是不夠的: 「任何領域的卓越成就都只能通過一生的努力來獲得; 稍低一點的代價也換不來。」 (Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price.) 喬叟 (Chaucer, 英國詩人, 1340-1400) 也抱怨說: 「生命如此短暫, 掌握技藝卻要如此長久。」 (the lyf so short, the craft so long to lerne.)
下面是我在程式設計這個行業裡獲得成功的處方:

• 對程式設計感興趣, 因為樂趣而去寫程式。確定始終都能保持足夠的樂趣, 以致你能夠將 10 年時間投入其中。
• 跟其他程式設計師交談; 閱讀其他程式。這比任何書籍或訓練課程都更重要。
• 程式設計最好的學習是從實踐中學習。用更加技術性的語言來講, 「個人在特定領域最高水準的表現不是作為長期的經驗的結果而自動獲得的, 但即使是非常富有經驗的個人也可以通過刻意的努力而提高其表現水準。」 (p.366), 而且「最有效的學習要求為特定個人制訂適當難度的任務, 有意義的反饋, 以及重複及改正錯誤的機會。」 (p.20-21) 《Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life》 (在實踐中認知: 心智、數學和日常生活的文化) 是關於這個觀點的一本有趣的參考書。
• 如果你願意, 在大學裡花上 4 年時間 (或者再花幾年讀研究生)。這能讓你獲得一些工作的入門資格, 還能讓你對此領域有更深入的理解, 但如果你不喜歡進學校, (作出一點犧牲) 你在工作中也同樣能獲得類似的經驗。在任何情況下, 單從書本上學習都是不夠的。「電腦科學的教育不會讓任何人成為內行的程式設計師, 正如研究畫筆和顏料不會讓任何人成為內行的畫家」, Eric Raymond, 《The New Hacker's Dictionary》 (新黑客字典) 的作者如是說。我曾經僱用過的最優秀的程式設計師之一僅有高中學歷; 但他創造出了許多偉大的軟體 (XEmacs, Mozilla), 甚至有討論他本人的新聞組, 而且股票期權讓他達到我無法企及的富有程度 (譯註: 指 Jamie Zawinski, Xemacs 和 Netscape 的作者)。
• 跟別的程式設計師一起完成專案。在一些專案中成為最好的程式設計師; 在其他一些專案中當最差的一個。當你是最好的程式設計師時, 你要測試自己領導專案的能力, 並通過你的洞見鼓舞其他人。當你是最差的時候, 你學習高手們在做些什麼, 以及他們不喜歡做什麼 (因為他們讓你幫他們做那些事)。
• 接手別的程式設計師完成專案。用心理解別人編寫的程式。看看在沒有最初的程式設計師在場的時候理解和修改程式需要些什麼。想一想怎樣設計你的程式才能讓別人接手維護你的程式時更容易一些。
• 學會至少半打程式語言。包括一門支援類抽象 (class abstraction) 的語言 (如 Java 或 C++), 一門支援函數抽象 (functional abstraction) 的語言 (如 Lisp 或 ML), 一門支援語法抽象 (syntactic abstraction) 的語言 (如 Lisp), 一門支援說明性規約 (declarative specification) 的語言 (如 Prolog 或 C++ 模版), 一門支援協程 (coroutine) 的語言 (如 Icon 或 Scheme), 以及一門支援併行處理 (parallelism) 的語言 (如 Sisal)。
• 記住在「電腦科學」這個名詞裡包含「電腦」這個詞。瞭解你的電腦執行一條指令要多長時間, 從記憶體中取一個 word 要多長時間 (包括暫存命中和未命中的情況), 從磁碟上讀取連續的數據要多長時間, 定位到磁碟上的新位置又要多長時間。 (答案在這裡)
• 嘗試參與到一項語言標準化工作中。可以是 ANSI C++ 委員會, 也可以是決定自己團隊的程式風格到底採用 2 個空格的縮進還是 4 個。不論是哪一種, 你都可以學到在這門語言中到底人們喜歡些什麼, 他們有多喜歡, 甚至有可能稍微瞭解為什麼他們會有這樣的感覺。
• 擁有盡快從語言標準化工作中抽身的良好判斷力。

抱著這些想法, 我很懷疑從書上到底能學到多少東西。在我第一個孩子出生前, 我讀完了所有「怎樣……」的書, 卻仍然感到自己是個毫無頭緒的新手。30 個月後, 我第二個孩子出生的時候, 我重新拿起那些書來複習了嗎？不。相反, 我依靠我自己的經驗, 結果比專家寫的幾千頁東西更有用更靠得住。

Fred Brooks 在他的短文《No Silver Bullets》 (沒有銀彈) 中確立了如何發現傑出的軟體設計師的三步規劃:

• 儘早系統地識別出最好的設計師群體。
• 指派一個事業上的導師負責有潛質的對象的發展, 小心地幫他保持職業生涯的履歷。
• 讓成長中的設計師們有機會互相影響, 互相激勵。

這實際上是假定了有些人本身就具有成為傑出設計師的必要潛質; 要做的只是引導他們前進。Alan Perlis 說得更簡潔: 「每個人都可以被教授如何雕塑; 而對米開朗基羅來說, 能教給他的倒是怎樣能夠不去雕塑。傑出的程式設計師也一樣」。

所以儘管去買那些 Java 書; 你很可能會從中找到些用處。但你的生活, 或者你作為程式設計師的真正的專業技術, 並不會因此在 24 小時、24 天甚至 24 個月內發生真正的變化。

中國人說英語為什麼聽起來沒有禮貌？

http://www.ibtsat.com/archives/2208

中國人說英語為什麼聽起來沒有禮貌？【無老師力薦】

無老師題：做人，長期看的是品質，短期看的是禮儀，但是中國留學生在剛出鍋（國）的時候，往往給西人一種十分沒有禮貌的感覺，但是我們的留學生並不知道這一點，這到底是為什麼呢？是我們的留學生很粗魯麼？一個兩個也許會有，但是如果很多留學生都給人類似的感覺的話，那麼這就不是一個禮儀問題，而是一個能力問題，那麼到底哪裡出問題了呢？希望無老師今天找來的這篇文章能給大家一點啟示。^_^

中國人的英語以 Chinglish 或 Chenglish 聞名於世；中國人最大的英語發音問題就是沒有連讀，但這都不是最主要的語言問題。老外們時常議論，很多中國人在說英語時，聽起來沒有禮貌；並不是這些中國人本身沒禮貌，而是他們還沒有習慣英語的禮貌表達方式。

比如，中國人在餐廳或咖啡廳，會說：「我想要一個漢堡包。」或者「我想要一杯咖啡。」但是，如果直接把這些話翻譯成英語 "I want to have a hamburger." 或 "I want to have a coffee." 老外們會覺得這樣說話很沒有禮貌，當然他們也不會直接告訴你。而在西方國家，老外們一般會說："Could I have a hamburger, please?" 或 "Can I have a coffee, please?"

再比如，中國人在拒絕別人邀請的午宴或晚宴時，會說：「抱歉，我不能去，我還有別的安排。」翻譯成英文就是 "Sorry, I can't. I have another appointment." 如果這樣說，那別人第二次也許不會再邀請你了。老外們一般會這樣說："That is a good idea! I would like to join in but I have another appointment today."（無老師題：原來托福聽力考的就是這個呀！）

我們可以從中總結一些「有禮貌」的技巧：

1. 西方人（主要指有一定修養的歐美人）在與他人交流時，比較多地使用情態動詞：can、could、may、might、would 等等；情態動詞（Model Verbs）又稱為情態助動詞（Model Auxiliaries），表示說話人的語氣，可表達建議、要求、可能和意願等，使得說話的語氣比較有禮貌；

2. 比較多地使用虛擬語氣，比如 would (had) rather、would (had) sooner、would (just) as soon 等等，或者在陳述句中使用過去式表示虛擬語氣，或者使用 if 等引導的從句表示「可能性」。這樣說話可以使人感覺表達者是在考慮達到最佳的結果或方式，儘量避免不好的結果或方式，或者推測可能出現的問題，並找出可能解決的辦法；

3. 往往在句尾加 please，而不是在句首加 please。當 please 用在句首的時候，語氣聽起來就比較強，聽起來像命令。比如請求別人做某事的時候，我們中國人會說「請在週一前給我回覆。謝謝。」但是如果你直接用英語說 "Please reply to me by Monday. Thank you." 聽者會覺得你是在命令他，一點禮貌也沒有。而如果這樣說："Could you please reply to me by Monday? Thank you." 就顯得有禮貌了；

4. 在陳述句的表達可能顯得生硬、沒禮貌時，儘量使用疑問句、否定句或從句，儘量避免自己的主觀判斷或武斷，以積極的、建議的、比較的、人性的語氣，代替消極的、命令的、直接的、武斷的語氣；

5. 說話要以他人為中心，以肯定他人、贊同他人為前提，讓自己顯得謙卑、渺小。說完之後，還要附帶一句 "Thank you" 或 "Thanks"。其實，這種禮貌的表達方式是來自古老的中國。這是東西方文化的共同點，也是為人處世的基本原則。瞭解英語中禮貌的表達方式，儘量讓自己的英語表達更有禮貌，融入社會。

改用 Emacs

在 VIM 使用到這種程度之後，覺得有點頂到 VIM 的 glass ceiling 了：

學習 emacs

在這裡看到 http://blog.liuw.name/95 從 VIM 向 EMACS 倒戈

VIM 是編輯器的神。
EMACS 是神的編輯器。
——anonymous