Sunday, November 27, 2005

曇花一現


在王鼎鈞先生《作文七巧》中〈描寫〉這一巧看到幾個短句,是有關曇花的,套用作者的說法,文句很樸素很直接的描出一個輪廓來,簡直就是在「描花」:


院子裡的燈打開了,枝枝葉葉的顏色深得發黑,那新放的曇花卻白得耀眼。近前細看,花瓣薄得出奇,瓣那麼大,只有一丁點兒連在蒂上,在夜晚濕涼的空氣裡暗暗顫抖,怪不得開了就謝,不能持久。正想著,已有一個花瓣悄悄然跌下來,被葉叢托住了。

曇花又稱瓊花,台灣的花市也普遍可以看到,從前書桌旁的陽台上也養了一盆,如今讀來,更是有感覺。所謂曇花一現,就是說明這種景象。

行文至此,鼻間還真聞到曇花陣陣的幽香,那種感覺是如此熟悉、深刻。

Thursday, November 24, 2005

我的 Blog 換膚了!


昨天在 Aman果園發現鮮艷可口的草莓,忍不住摘來為自己的 Blog 裝扮裝扮。 blog 穿起一身草莓裝,再騎上火狐,果然耳目一新。誰知道 IE 跟草莓不搭,還好 Aman 鼎力幫忙,手術成功,可喜!可喜ㄚ!


疑,不是說手術成功嗎?怎麼看起來跟之前一樣?
Hmm..
照過來,照過來...
仔細看了,Forwarded News , 現在變成 News Berry 了 :)
這麼嬌艷欲滴的新聞,真想咬一口!

Tags: [] []

Wednesday, November 09, 2005

Life is Random

Steve 重回 Apple 後,推出了一系列切合消費者喜好的玩意兒。其推出的每一項產品,都有著又酷又貼切的廣告詞。以 iPod shuffle 為例,在該產品首頁寫著:

Time to mix things up. Meet iPod shuffle, the unpredictable new iPod. What will it play next? Can it read your mind? Can it read your moods? Load it up. Put it on. See where it takes you. Choose from pocket-size 512MB or 1G models starting at $99(1) and surprise yourself.

以 mp3 player 所該具有的功能來看, iPod shuffle 簡單得連選曲的功能都沒有。那該怎麼換曲?唯一的方式就是 Random 換曲。該廣告中還寫著:
Random is the New Order
Welcome to a life less orderly. As official soundtrack to the random revolution, the iPod Shuffle Songs setting takes you on a unique journey through your music collection — you never know what’s around the next tune. ...

shuffle 本身就有洗牌的意思,iPod shuffle 再搭配 Give chance a chance 這句,於是 Life is Random 幾乎脫口而出,產生不可抗拒的魔力,在年輕人間行成一陣「炫」風。

據稱 Apple 最初有深刻研究過多數人對 mp3 player 的使用習慣,大膽砍掉一切多餘的功能,連選曲功能都取消掉了,將餘力放在其他更關鍵的特性,如省電上面。

~~

撇開量子力學這門讓人目眩的理論不談,確實有人確信世事沒有一件是真的隨機的,重點是我們用甚麼角度來看待事物,及我們是否有足夠的耐心,來找出潛藏在隨機這個表象之下的規則。

一個讓我至今還印象深刻的例子:

天文學家根據長期的觀測資料,一直以為星星的分佈大體上是均勻的;直到上個世紀有位女天文學家,竟然想到把原本星星的二維平面分佈資料加上深度後,然後再視覺化地描繪出來,才會發現宇宙的巨結構--肥皂泡泡(the big soap bubbles)。大部分的星星分佈在這些肥皂泡沫的薄膜上,每個單一泡沫的中央只有零星分佈少數星星,由於許多大氣泡重疊後投影到二維的天幕上,才讓人誤以為星星是平均分佈的。
Tags: [] [] [] []

Tuesday, November 08, 2005

A Good Solution is Hard to Find

--

國中生就能理解的畢氏定理,古希臘學者竟將它當作祭品獻給上天;數百萬人都能哼唱第九交響曲,卻少有人渴望成為貝多芬那樣的音樂天才。這就是基本的非對稱性——辨識遠比發現來得容易。
-- 摘譯自《Out of Their Minds》〈A Good Solution is Hard to Find〉

--

我想,需要並非發明唯一的母親。一個人必須對問題的背景資訊有正確的瞭解。我並不是對所有遇到的問題都加以研究。而是對那些我所解決的問題,心中覺得真巧,剛好我有獨特的背景知識,可以用來解決此問題!就像命中註定,也是我責無旁貸的。
-- 高德納

--

人們心裡想要的東西,很少是他們真正需要的。他們想要的和需要的,往往是南轅北轍。而在科學技術的發明中,最重要的事便是能符合人們的慾念與需求。
-- Alan C. Kay

--

Monday, November 07, 2005

The Main Sequence

在好天氣的夜裡,選擇無光害的海濱或深山中或乾脆到天文台去也行,我們可以看到滿天的星斗,除了絕少數的例外,我們看到的大都是恆星。遠古以來,人們就為這些恆星編織許多故事,企圖讓這些星星顯得有組織些,也為了方便我們記憶。不過這些綺麗的故事,大多只出自人們豐富的想像,和一連串浪漫的巧合。直到近兩百年來,事情才慢慢有所改觀。


科學家發現,以恆星的亮度對它們的表面溫度在相空間上作圖,大部分的恆星會簇集在劃過這相空間的反斜線上,這條反斜線因而被稱為主序列(The main sequence)。

Agile Software Development》一書告訴我們,在設計優良的軟體系統中,只要把恆星亮度以套件的抽象度(Abstration)取代,並將恆星的表面溫度代之以套件的不穩定度(Instable),我們也會發現類似這樣的一簇主序列。這不但讓我印象深刻,更使我佩服 Martin 巧思。

Tags: [] []

Friday, November 04, 2005

Improving The Design of Existing Code

標題都這樣下了,當然要祭出《Refactoring》這部經典囉!

這本書問世到現在,重構已經是成熟的軟體技術了,對程式員來說,裡面的東西就如同空氣和水般,融入每天的編程中。

我只是手癢,上來把這部經典裡面的名句摘錄一番,日後也好隨時端詳端詳:

  • 如果你發現自己需要為程式添加一個特性,而程式碼結構使你無法很方便地那麼做,那就先重構那個程式,使特性的添加比較容易進行,然後再添加特性。
  • 重構之前,首先檢查自己是否有一套可靠的測試機制。這些測試必須有自我檢驗(self-checking)能力。
  • 重構技術係以微小的步伐修改程式。如果你犯下錯誤,很容易便可發現它。
  • 任何一個傻瓜都能寫出計算機可以理解的程式碼。唯有寫出人類容易理解的程式碼,才是優秀的程式員。
  • 重構(Refactoring)(名詞):對軟體內部結構的一種調整,目的是在不改變「軟體之可察行為」前提下,提高其可理解性,降低其修改成本。
  • 重構(Refactor)(動詞):使用一系列重構手法,在不改變「軟體之可察行為」前提下,調整其結構。
  • 事不過三,三則重構。(Three strikes and you refactor)
  • 不要過早發佈(published)介面。請修改你的程式碼擁有權政策,使重構更順暢。
  • 程式碼的壞味道。(Bad smells in Code)
    1. Duplicated Code
    2. Long Method
    3. Large Class
    4. Long Parameter List
    5. Divergent Change
    6. Shotgun Surgery
    7. Feature Envy
    8. Data Clumps
    9. Primitive Obsession
    10. Switch Statements
    11. Parallel Inheritance Hierarchies
    12. Lazy Class
    13. Speculative Generality
    14. Temporary Field
    15. Message Chains
    16. Middle Man
    17. Inappropriate Intimacy
    18. Alternative Class with Different Interfaces
    19. Incomplete Library Class
    20. Data Class
    21. Refused Bequest
    22. Comments
  • 當你感覺需要撰寫註釋,請先嘗試重構,試著讓所有註釋都變得多餘。
  • 確保所有測試都完全自動化,讓它們檢查自己的測試結果。
  • 一整組(a suit of)測試就是一個強大的臭蟲偵測器,能夠大大縮減搜尋臭蟲所需要的時間。
  • 頻繁地執行測試。每次編譯請把測試也考慮進去,每天至少執行每個測試一次。
  • 每當你接獲臭蟲提報(bug report),請先撰寫一個單元測試來揭發這隻臭蟲。
  • 編寫未臻完善的測試並實際執行,好過對完美測試的無盡等待。
  • 考慮可能出錯的邊界條件,把測試集中火力在那兒。
  • 當事情被大家認為應該出錯時,別忘了檢查彼時是否有異常如預期般地被拋出。
  • 不要因為「測試無法捕捉所有臭蟲」,就不撰寫測試碼,因為測試的確可以捕捉到大多數臭蟲。