Abstract - On the Criteria To Be Used in Decomposing Systems into Modules

        這篇文章主要在敘述如何透過模組化一個系統，使得其在開發上更有彈性與快速，且在開發階段可以更加容易地理解系統各部分，這篇文章中所謂的『模組化』是在作者所提出的幾項原則下對一個系統做分解，搭配作者提出的例子-KWIC index (Key Word In Context index)的兩種分解方式，來理解非傳統的分化相較於傳統的方式有什麼樣的優點。

        近期(根據文章著作年代，應該是1972年)的模組化程式設計發展，主要著重在程式碼撰寫的技巧和組譯技術的改進，然而對於多數的系統開發而言，最常使用的則是高度模組化程式。

        對於模組化程式設計，我們期望可以達到三個效果：

(1)   分工及縮短開發時程

(2)   彈性的功能調整

(3)   更容易地了解整個系統

Elevator Scheduling (1)

下午去吃飯回來搭電梯時，因為電梯剛好在二樓，我就直接按鈕進去了

當我到了六樓，一出來就發現有人在等電梯，我突發奇想，思考一個可能性，就是會不會他們其實剛好正要按電梯按鈕，但是就只是差那麼個幾秒鐘，導致我先搶到電梯了？

那麼假如今天剛好相反過來，我慢了一點，電梯明明在二樓，我就只能眼睜睜看著它先到六樓再下來載我嗎？

我開始思考延遲電梯反應時間的可能性

讓可能只是誤差非常小的時間範圍內，可以讓慢了一點的我還是可以先搭到電梯，然後到了六樓以後再換六樓的人搭下來，結果光是在Word上邊寫邊想就花了我兩個小時左右的時間，以下是我的思考結果，之前在圖書館搭電梯就曾經對三部電梯的調度提過問題，可惜當時沒有那麼無聊好好思考和紀錄，現在就可以當參考了

有聽過電梯演算法 (Elevator Algorithm)，還有個有名的人物 Theresa Christy，會不會其實這個問題早就克服了呢？

Shell 內建命令 (Shell Built-in Command)

Shell Built-in Command 是指與 shell code 寫在一起編譯成，屬於 shell 這個 program 本身功能的指令，在Windows中稱為 internal command，例如：cd, exit, umask, alias 等等，這種內建在 shell 程式碼內的功能無法在 shell 中使用 execv() 去呼叫外部程式的方式執行

<Shell.c>
int main()
{
    ...
     if( strcmp(cmd, "cd") == 0)
            cd(pathname);
    ...
}

環境變數 Path 的應用

(小兒科篇，單純覺得這樣應用很有趣 !!! ^ω^)

相信大部分的人都寫過 Java，在安裝完 JDK 以後，都一定要做一件事情，也就是到我的電腦去把 javac.exe 和 java.exe 這兩個執行檔所在的目錄 bin 這個相對路徑加入系統的環境變數中，甚至有些系統中會自動幫你加入，所以很多人只知道要這麼做，好讓你在使用命令提是字元編譯和執行 java 程式的時候可以直接輸入 java 和 javac 對原始碼進行處理，不過其實這個 Path 的用途最主要是用來讓系統搜尋 "指令程式" 用的。

一般我們在命令提示字元輸入的指令，大部分都是作業系統自動在所有 Path 變數中指定的目錄下尋找與輸入的指令名稱相同的可執行檔或批次檔，並執行它工作，所以 Java 的環境變數才會要求要把 javac.exe 和 java.exe 所在的目錄 bin (這個名稱的目錄底下一般都存放可執行檔)路徑給加入到 Path 中。

兩岸計算機科學用語對照 (sorted by English)

大陸用字	台港澳用字	英文
算法	演算法	algorithm
匯編	組合	assembly
激活	啟用	activation
數組	陣列	array
字節	位元組	byte
比特	位元	bit
總線	匯流排	bus
二叉	二元	binary
計算機	電腦	computer

截取自-左飛<程式揭秘-從C/C++程式碼探索電腦系統的運作原理>書中一文『卓越的程式設計之道』

社會上也有很多像"XXX電腦"的培訓機構那樣專門開設一些如 "Java軟體工程師"、".NET軟體工程師" 等的課程，其目的就是為了讓受訓者能夠掌握在某些環境下進行軟體發展的技能。軟體發展或者編寫程式碼的確是一項技術，而程式設計則是一門藝術。技術和藝術的區別不言而喻！其結果是這類從業者，即使她們擁有了一定的程式設計經驗，但大多數也只是在 "軟體工廠" 中做些類似 "零件組裝" 的工作。這就是中國和世界的差距！中國沒有微軟(Microsoft)，沒有谷歌(Google)，也沒有甲骨文(Oracle)。當然，或許你也能羅列出幾個你心目中的民族科技龍頭企業，但相對於這些巨頭而言，中國的企業仍然不能與之相提並論。這些公司之所以能夠在世界範圍內呼風喚雨，最重要的是他們有著自己的核心技術和無窮的創新能力！

千萬不要把軟體產業和ＩＴ產業混為一談。正確的說，軟體產業應當是ＩＴ產業的一部分，而且是處在技術"下游"的那部分！中國的 "軟體工廠"也只能用別人的 Visual Studio 或者 Eclipse 進行著大量重複而簡單的生產，即使是C、C++、C#或者是 Java 這些耳熟能詳的程式設計語言也沒有一個是中國人發明的。專科水準再稍加訓練就足以勝任軟體工廠的實際邊也程式碼工作了。

先有雞還是先有蛋？Compiler vs Program

這學期準備要修 編譯器設計，我想到一個之前逢甲資工的老頭問我的一個問題，同時這也是他們編譯器老師問的問題：

先有 Compiler 還是先有程式?

其實同樣的問題也出現在作業系統上面，因為作業系統也是由程式所設計出來的，例如UNIX就是用C語言所編寫出來的。

針對這個問題我找了為基百科和一些網頁資料，我認為應該是先有程式，才有編譯器，因為去看電腦發展的歷史，很早期的電腦(真的是很早期)，或是更精確一點說是計算機，其實是沒有”程式”的，是以純機械原理模擬出運算能力，而晶體管(transistor)發明以後，機械進入的電子的時代，電子電機工程開始興起，也就產生了數位系統。

第一次是聽補教界的名師洪逸在課堂上說的，後來在<Pirate of Silicon Valley>中看到比爾蓋茲和賈伯斯他們真的是這樣寫程式而印象深刻，後來發展出的打洞卡(Punch Card)，電腦先輩們都必須利用打卡的方式控制機器，而這也就是最早的程式語言，也就是為什麼影片中兩位大老會想要說服當時的電腦大廠接受他們開發的作業系統，作業系統本身也是程式，也是由程式語言創作出來的，基於這個概念，因此編譯器也是後來才有的。

另一個可以支持這個說法的還有一點，那就是高階程式語言是在後期才出現的，早期的電腦由打卡控制提升到指令控制時，幾乎都是接近於機器碼的組合語言(Assembly Language)，而高階語言經過編譯器編譯以後都是轉譯成組合語言，再轉譯成機器碼，這也就是為什麼組合語言比較難學，卻也是最直接能與硬體做互動的原因。