作者: Cash

奇異果與蜜蜂

這次去紐西蘭, 聽導遊講了一個有趣的故事.

經過授粉的奇異果, 長得就是現在大家看到的樣子. 不過如果奇異果沒有經過授粉, 長出來就會是瘦瘦得像一根熱狗.

不幸地, 奇異果雖然有花粉, 但是沒有花蜜. 因此負責授粉大業的蜜蜂, 寧可去採其他花的花蜜, 也不會去幫奇異果做白工. 據說奇異果的原產地在四川 (???), 就是因為沒有蜜蜂幫忙授粉, 所以長得其貌不揚. 等到它偶然地被引進到紐西蘭, 當地的人才發現偶而也可以讓奇異果長得很大顆.

那麼怎麼去騙蜜蜂幫奇異果傳播花粉呢? 最早的做法是把蜂蜜抹在奇異果的花朵上. 蜜蜂看到有蜜可以吃, 就會順便幫忙傳播花粉. 不過抹蜂蜜這件事一聽就知道不敷成本, 只能算是實驗室的做法, 無法大量生產. 後來的人乾脆就直接把蜂蜜倒到蜂巢裡去了.

蜜蜂真的像工程師一樣好騙! 當他們每天去奇異果園採蜜都摃龜以後, 卻發現蜂巢裡竟然有蜂蜜可以吃. 不免在牠們小小的頭腦產生了不正確的聯想: 我一定是不夠努力, 不然為什有些同事那麼厲害, 我卻這麼笨呢? 於是這些有蜂蜜可以吃的蜜蜂就會持續不停地去採蜜. 雖然每天加班也不知道在忙甚麼? 不過吃飽倒是沒問題, 看似大善人的農夫成了最大的贏家. 農夫貴貴地賣出奇異果, 賺錢了後, 再買一些蜂蜜給蜜蜂吃. 如此循環不已, 農夫大賺其錢, 奇異果得以順利繁衍, 蜜蜂呢? 其實牠只要打混就好了, 只是牠沒有這種領悟. 不過如果每隻蜜蜂都打混, 農夫一定也會把他們掃地出門就是了 (我在紐西蘭倒是一隻蝴蝶都沒見過, 所以不知道可以替代成甚麼) !

人有人格, 蜂有風格, 我們也管不著蜜蜂. 他們採到蜜才有蜜吃是自然法則, 但沒採到蜜也有蜜吃, 是因為牠們有附加價值. 人, 也可以找一找自己的附加價值吧?! 一路上我還想了很多聯想, 不過還沒有結論出來.

洗水塔者言

有一本書叫做"買桔者言", 是張五常先生講經濟的小書. 我這個禮拜洗了水塔, 所以也想寫下洗水塔者言.

洗水塔的啟示是甚麼呢? 我覺得就算是有一個強大的推力在運作某件事, 事情仍然不會馬上動起來, 在經過一陣混沌, 不知不覺的過程之後, 那個力量才會顯示它的作用, 漸漸變成顯而易見, 一股強大的力量.

我們知道洗水塔之前一定要先把裡面的水放掉, 而在放水的過程中, 水會形成漩渦. 據說漩渦旋轉的方向和地球自轉是有關係的, 北半球會是逆時針方向轉. 我假設這個學說成立 (有另外的說法不同意地球自轉會影響這種小尺寸的物理現象), 那麼地球自轉力就是哪個強大, 但是很難感受到的力量.

在放水的過程當中發現, 漩渦並不會一開始就出現, 總是要醞釀好一段時間, 比方說一開始, 水平面只是在不規則地晃來晃去. 好不容易水面平靜了, 水也在大量地流出, 但是水的表面上可是一點也看不出來. 過了數十秒鐘, 一個小漩渦才出現在我眼前, 然後愈來愈大.

我的腦海中, 閃過幾個聯想: 文化對人類的作用, 聯準會降息對美股的作用, 公司政策對員工的作用….好像都可以套用這個模式. 畢竟, 在等水放完的空檔是沒甚麼事可以做的, 上半身趴在白鐵的水塔上,傻傻地看著水往外流,手臂都曬黑了….

排檔線又斷了~~~

昨天開車出門看醫生時, 我的福特 Escape 突然給我罷工了…

當時我的車已經接近十字路口, 因為交通號誌轉為紅燈, 於是我就準備要排到 N 檔停車. 誰知一換檔就發現排檔桿空空的, 完全沒有入檔的感覺. 再稍微搖一搖, 從此就卡進了 P 檔, 再也動不了了….Orz

難道, 我終於要用到信用卡的道路救援了嗎? 真是一則以喜, 一則以憂. 憂的是運氣真不好, 阿Q 喜的是終於可以撈本了. 興沖沖地撥了我最愛用的聯邦銀行的電話, “先生, 您沒有登記車號喔?"…"喔, 這樣啊!" 還好我還有中國信託, 總算中國信託派了輛拖吊車來, 把我整輛車高高地搬上了他的拖車去. 其間推車, 指揮交通的辛苦, 被注目的尷尬就略過不提了.

可憐啊! 我已經是第二次遇到排檔線的問題了. 不過比起上一次經驗, 這次已經是不幸中的大幸了….

第一次慘痛經驗是以前開喜悅的 Malaga 的時候發生的, 它直接選在高速公路給我罷工! 幸好, 雖然理論上排檔線 (就是一條直徑 1~2 mm 的不銹鋼線) 斷了之後, 就不能再換檔了. 不過這兩次都有 “最後一次入檔的機會"…那次我是入了二檔. 於是我就用二檔, 在引擎一路嘶吼聲中下了高速公路, 直接進到維修廠.

我的疑問是, 難道只有我有遇到過這種問題嗎? 我開過兩台裕隆的車倒是都沒遇到過耶. 以後還是開電子換檔的車好了.

AJAX 小檔案

AJAX 就是 asynchronous Javascript + XML 的縮寫. 其中有時候會牽涉到 DOM (Document Object Model), 因為無論是 XML 或是 HTML, 都會需要一個文件的介面.

Javascript 的歷史悠久, 十幾年前就相當風行, 應該無庸贅述. XML 也行之有年, 為什麼會和 asynchronous Java script 扯在一起呢? 大家可以想像, 如果只是一個靜態的 XML, 可以做的事情畢竟是有限的. 反之, 如果可以和使用者互動, 依據使用者的指令來產生動態的 XML 介面, Javascript 正好可以做這件事. 但此處的 Java 為何會強調 asynchronous 呢? 它主要是指在 client 端和 server 端的 XML 可以是不一樣的, client 端看到的 XML, 並不是 server 端所 generate 出來的, 而是依據 Javascript 所動態生成的. 它最直接的好處就是節省了 server 的計算量以及網路頻寬. 從 client 端透過 SOAP 和 server 端做必要的溝通, 可以使得網路流量只剩 5% (參考 Wiki).

現在很多網路的應用都使用了 AJAX 的技術, 以至於各位所看到的網路頁面, 真正是獨一無二的, 因為連 server 上的那一份都和我們所維護的這個版本不同. 一旦我們想回到上一頁, 重新整理, 或是 IE 突然當掉…, 那個珍貴的畫面就再也回不來了. 比方說我寫 Blog 就會偶爾遇到這款代誌. 後來有很多人寫一些撇步來解決回到上一頁的問題, 不過問題總是比較多, 有利就有弊. 如果肯犧牲 client 端硬碟空間的話, 我想大概甚麼問題都可以解決.

AJAX 一個先天上的難題在於 client 端的狀況百百種, 不一定會使用哪一種瀏覽器, 外掛也不一定會全部都開得好好的, 比方說 Javascript 被關掉了, 很多東西就不對了. 在真實的狀況下, 網路應用可能大部分的功\能都留在 server 上, 把 client 端只當作一個顯示的介面. 這樣可以減少 client 端相容性的問題, 但是 client 端連邏輯判斷的能力都沒有的話, 可以做出來的功\能也就沒甚麼看頭了 (thin client 的 case).

另外值得一提的是, AJAX 的 server 要應付 multi-thread, muti-user, 如果兩個 user 用同一個帳號存取同一個郵箱, server 勢必要做 error handling. 凡此種種都要靠開發套件來幫忙簡化問題, 不然只靠苦工做一套出來 demo 還簡單, 要能夠全面商品話就困難了.

以上是一點點了解, 以後再更正與補充之.

我女兒今天晚餐鬧的笑話

我的女兒, 今天說了一句很白癡的話, 我老婆還特別把它寫下來以免忘記.

事情是這樣的, 我女兒很喜歡吃蝦. 只要餐\桌上有蝦, 她就會狂吃, 還會偷挾別人碗裡的…

結果我老婆今晚做的蝦仁炒麵, 一人一盤, 卻不見女兒動筷子吃蝦.

老婆說: 奇怪, 妳今天怎麼一隻蝦都沒有吃?

女兒說: 蝦子的殼都軟掉了, 好口惡心~~~

老婆和我: ……

“今天吃的是蝦仁耶, 那來的殼!"

女兒: 對厚…, (平常吃的都有殼 )

我唯一可以感到安慰的是: 還好她不是每天吃蝦仁, 然後看到有殼的蝦說: 這是什麼怪蟲…