Thursday, July 13, 2000

《教堂與市集》的格言

[格言 1] 好軟體都是起源於程式發展者要解決切身之痛。

1. Every good work of software starts by scratching a developer's personal itch.

[格言 2] 優秀的程式師知道要寫程式,偉大的程式師知道要改寫(和重覆利用)程式。

2. Good programmers know what to write. Great ones know what to rewrite (and reuse).

[格言 3] “計畫好如何捨棄一條路吧,你遲早會想盡辦法這麼做的。”
-- 引自 Fred Brooks 《人月迷思》 一書的第十一章

3. "Plan to throw one away; you will, anyhow."
-- Fred Brooks, "The Mythical Man-Month", Chapter 11

[格言 4] 抱持正確的態度,就會發現有趣的問題。

4. If you have the right attitude, interesting problems will find you.

[格言 5] 當你對一個問題不再感興趣時,你最後的責任就是找位能勝任的接棒人。

5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

[格言 6] 把你的使用者視為協同發展人,可以讓你傷最少的腦筋,但做到原始碼的 快速改善,程式的除錯有績效。

6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

[格言 7] 儘早,經常發表新版本,並且傾聽使用者的意見。

7. Release early. Release often. And listen to your customers.

[格言 8] 以足夠多的“beta 版”測試者和協同發展者做基礎,幾乎程式中的每一個問題都可以很快地找出來,並且對某些人而言,針對發現的問題的解決方法是顯而易見的。

8. Given a large enough beta-tester and co-developer base, almost everyproblem will be characterized quickly and the fix obvious to someone.

[格言 9] 聰明的資料結構配上笨拙的程式碼要比相反的組合好。

9. Smart data structures and dumb code works a lot better than the other way around.

[格言 10] 如果你視 beta 版測試者如同你最珍貴的資源,那麼他們會以此做為回報。

10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

[格言 11] 體認你使用者提供的巧思,以獲取好點子,有時候越後到的越好。

11. The next best thing to having good ideas is recognizing good ideasfrom your users. Sometimes the latter is better.

[格言 12] 通常,最適切和最有創意的解題法來自發覺自己對問題原先的觀念是錯誤的。

12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

[格言 13] 設計上完美,不是“沒有東西能再被加入”,而是 “沒有東西能再被移出”。

13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."

[格言 14] 任何的工具以我們所知道的方法來使用都會有用,但一個真正了不起的工具會以你從未想過的使用方法來發揮它的功能。

14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

[格言 15] 寫作任何的通信閘軟體時,要盡可能地不去擾動到通訊的資料流,-- 並且絕對不要丟掉其中任何的資訊,除非接收方強迫你這麼做。

15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible -- and *never* throw away information unless the recipient forces you to!

[格言 16] 當你設計的語言不是嚴謹到“完全 Turing”,你可以採用比較平易的語法。

16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

[格言 17] 一個保密系統是否安全依存於它隱藏的秘密,注意不要有“虛擬秘密”。

17. A security system is only as secure as its secret. Beware of pseudo-secrets.

[譯注] 以 fetchmail 為例,隱藏的秘密是指“通行密碼”,“虛擬秘密”是指把通行密碼編碼後存於設定檔中。

[格言 18] 為了要解有趣的問題,開始找你感興趣的問題吧!

18. To solve an interesting problem, start by finding a problem that is interesting to you.

[格言 19] 假如專案發展協調者擁有至少跟網際網路一樣好的媒體,而他也不靠強制力來領導,那麼一群人必定勝過一個人。

19. Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

詳細的內容,請參考《教堂與市集》(The Cathedral and the Bazaar

Tags: [] [] []

Tuesday, July 04, 2000

The Thread Class Library for Linux

在設計應用程式時,一些需要並行處理(concurrent processing)的功能,已經很少人使用中斷(interrupt)的方法解決,也不必再自行利用一個輪詢迴圈(Round-robin loop)來達到並行的效果──因為現在作業系統的設計,都已經支援執行緒(thread)了。一個程式可以透過許多執行緒達到並行處理的作用。

一個執行緒的產生,是在應用程式開始執行之後,而執行緒所能運用的系統資源是應用程式可用資源的子集;在應用程式結束前,執行緒就要被銷毀。因為執行緒是應用程式執行時的一個子功能,程式結束後,執行緒就沒有存在的必要。

Linux 作業系統核心提供了 clone() 這個 system call 來支援 thread 的功能。此外, Linux 的共用函式庫中,也利用了 clone() 來實作了 POSIX thread, PThread 標準的 C 語言 thread 應用程式介面。不過在現在到處充斥著物件的後 OO 時代裡,一個傳統 functional 的 C Language API 似乎顯得有些礙手。

這個類別庫(classes' library)主要目的是利用一個 C++ Thread Classes Library ,來提供一個容易使用的物件式介面(object interface),以方便日後在 Linux 系統下開發多執行緒的程式。

“一個具體的問題描述是與一千個尚未運用的抽象觀念等值的”,所以接下來,就先描述一下我們要的 Thread 是長成怎麼樣的:

一個多執行緒類別庫要考量的功能最基本的當然就是要能做好執行緒的內部管理,舉凡執行緒的識別、出生、狀態、行為和死亡等都要照料妥當。

如果執行緒之間要作通訊(communication),當然也要提供一個通訊的管道(channel);此外,還要考慮到執行緒共用資源時所可能引發的同步(synchronization)問題和避免因互相等待而產生的死鎖(dead-lock)問題。

為了方便多個執行緒的管理,還可以提供執行緒分組的功能,分成一個個的 Thread Group,以方便整組一起操作。

當然,在更完備的功能設計下,每個執行緒和執行緒群組還可以設定個別的執行優先權(priority)。並納入凍結(blocked)後的執行排班(scheduling)設計。

※完整的說明請參閱:

  1. Linux 系統 MultiThread 類別庫設計
  2. Linux 系統 MultiThread MMS 類別庫設計
Tags: [] [] [] [] [] []

Monday, July 03, 2000

Ant Simulation

大學(1997)的程式設計課要求學生在網路上找一個 JAVA Applet 的程式,研究後寫一篇報告上來。我在網路上找到 Mark Miller 所撰寫的“Manna Mouse”JAVA Applet,檢閱了原始碼後,覺得它的程式架構太雜亂了。於是決定自己利用物件導向分析與設計的方法,將整個程式重新設計過。

如此,一方面可以加深自己對物件導向分析與設計方法的熟練程度;另一方面我對於這個Applet 所使用的遺傳演算法也有很大的興趣,想藉此有更深的探究…

Grady Booch 一向在物件導向(Object Oriented, OO)的方法論上執領導的地位,他在1986年率先提出OO開發方法,開啟物件導向分析與設計的研究。

Booch方法在進行分析時,不只是針對問題本身作分析,也針對問題的領域進行分析。因為在同一領域的問題,有很多非常類似。實在不需要對這些類似的問題,每次都一一地重新作類似的分析。

對於問題的整個領域作一徹底的分析,雖然在一開始的時候需要耗費相當的心力,可是隨著分析的進行,我們對於整個領域就會有更深入的瞭解,最後不但累積了領域相關的知識,也完成了富彈性、高度可重複使用的軟體元件,對於將來開發新的系統將帶來非常大的助益。

Booch 的開發方法非常強調領域內的可重用性(Reuseability),其將軟體開發分成以下三個階段:

  1. 需求分析(Requirement Analysis)
  2. 領域分析(Domain Analysis)
  3. 系統設計(System Design)

上面三個步驟並不是像傳統瀑布式的分析設計方法般僵硬地要求一定要一步步地執行;而是允許在步驟間回溯(backtrack),進行反覆地修改與調整,直到系統符合需求為止。

根據生物學的說法,曾經在地球上出現過或現存的所有生物都是由構造簡單的、原始的生物,經由長期的演化而逐漸產生的。

生物演化的理論,在早期可分成:相信後天獲得的性狀可遺傳給後代的拉馬克(Lamarck)學說,及相信後天性狀不可遺傳給後代的達爾文(Darwin)學說兩大派。

由於後來新證據不斷地出現,及這幾十年來分子生物學的快速發展,生物學上已經知道自然界生物的演化機制是採用達爾文式的。雖然有學者提出人類文化的演進可以看成是採用拉馬克式的演進方式,不過這不是這裡所要討論的重點。

達爾文的生物演化論可分成以下幾個步驟:

  1. 遺傳變異(genetic diversify):個體間因遺傳基因型(genotype)的差異而顯現出各式多樣的表現型態(phenotype)。
  2. 自然選擇(natural selection):自然界對於不能夠於所在環境中適應良好的個體發生淘汰的現象。
  3. 繁殖複製(reproduction):未被淘汰的個體經由繁殖,產生許許多多的後代。這其實是一種選擇放大(selection amplify)的情形。

新產生的後代間又稍有不同而產生了遺傳變異,因此不斷地變異-選擇-複製,變異-選擇-複製,變異-選擇-複製......一直反覆循環下去即發生了生物的演化。

遺傳演算法在電腦科學上屬於演化式計算(Evolutionary Computation)的一環。遺傳演算法其實是以電腦來模擬生物演化的過程。通常用來解一些對問題解法沒有很充分瞭解的例子,或在用傳統的解法成本過高的時候使用。

※請進一步參閱《模擬螞蟻──以物件導向分析遺傳演算法

Tags: [] [] [] [] []

Sunday, July 02, 2000

The Puzzle Game

大學時(1996)選修的“專家系統”課,任課老師要我們以 CLIPS 實作智慧拼盤程式。當初對這的專家系統的 CLIPS 感到滿新鮮的,所以就把這個問題的核心往自己身上攬,而將使用者介面讓其他組員去發揮。CLIPS 是 C Language Integrated Production System 的縮寫,由美國 NASA 太空中心的一個人工智慧部門所發展,就發展專家系統而言,是個很有用的工具。

“智慧拼盤”(puzzle),是一個n×n的格狀棋盤(grid board)遊戲。棋盤上的每一格都有一個正方形的積木(block),每個積木都有自己正確順序(order)的位置,為了區別,依序編上1到n×n的 編號。遊戲啟始時先將其中一格積木取走,造成的空缺(blank),使相鄰的積木可以移動至空缺上,並編上“0”。如此,利用這個空缺,可以將棋盤上原先 就定位的積木之順序打散(disorder)。玩遊戲的一方(player)所要完成的目標(goal)就是要將積木利用空格 (編號為0),排回(reorder)原先的位置。

這個題目的目的是要設計一個會玩智慧拼盤的專家系統,所以一開始由人將積木的順序 打散,再要求電腦將其排回正確的位置。為了達成更好的展示效果,於是選定了圖形化的使用者介面。又為了簡化問題,於是先從3個階層著手,也就是3×3的智 慧拼盤遊戲,作為測試規則的用途。不過,為了將來能夠將系統套用於任何階層,所以規則制定時都很一般化,原則上這些規則要能在任何階層的智慧拼盤下運轉, 至於能否在任何階層都求出解答,不是目前所要求的。

這個軟體的開發平台是在 MS-DOS 下的 CLIPS v6.0 上建立 puzzle 規則,並利用 MS Windows 3.1 下的 MS Visual Basic 設計使用者介面。

※請參閱《智慧拼盤

Saturday, July 01, 2000

Graphing for the Pattern of Antenna Field

專四下學期至專五上學期延續一年(1994-1995)的專題課。我選了任教工程數學及電磁學的柯盟卿老師開授的“天線場型電腦繪圖”作為畢業專題。
原先的動機是想藉此磨練自己程式設計能力,又可藉由專題對電腦繪圖有一定的探究,再加上柯教授對於學生的要求:只要學生照規定行事、得到成果,其餘的細節絕不過問;當然啦!有任何疑問時,也可以隨時得到他耐心的解說。

當時我選擇了 Borland C++ v3.1 作為軟體開發的整合發展環境,並將內定的語法語意檢查功能全開,以期保障軟體最基本的強固性。此外,於程式撰寫的過程也力求完全利用 C++ 對物件導向程式設計的擴充功能,以達到最佳的學習效果。
這個專題最主要的內涵是要將天線電磁場強度的空間樣式(pattern)以電腦繪圖的型式呈現出來。
其用途除了可用作電磁學課堂上的教學展示外,還可以對於有心研發天線產品的人員建立方便的觀測模型,以減少反覆試作成品而造成不必要的浪費。
最基本的功能要能在給定了軟體關於天線的參數後,把天線四周的電磁波強度顯示出來。
經由分析,在工程實務上,只注重天線電磁場的場型(field pattern)。所以在圖形繪出前要先經過正規化(normalization)的處理。
又天線場型強度,其電場和磁場僅相差一個常數,故我們只選定了電場的部分著手。
最後,也決定了讓程式的執行平台最基本的要求在當時最普遍的 286AT 配合 DOS v3.3 的作業系統版本。不過為了繪圖的效果,程式被設計成必須在 640*480 VGA 模式下執行。
※請參閱《天線場型電腦繪圖