TF-IDF

假設要測試的文件為 {Ｄ} = {ｄ1, ｄ2, ..., ｄn}、全部關鍵詞的集合為 {Ｋ} = {ｋ1, ｋ2, ..., ｋm}。則：

• ｋx1 表示 ｄx 中 ｋ1 出現的次數
• TSum(ｄx) = ｋx1 + ｋx2 + ... + ｋxm
• TF(ｄx) = (ｗx1, ｗx2, ..., ｗxm) ，ｗxi = ｋxi / TSum(ｄx)
• DF(Ｄ, ｋi) = Ｄ 中含有 ｋi 的文件數量
• IDF(Ｄ, ｋi) = log(2, p/DF(Ｄ, ｋi))
• TF-IDF(Ｄ, ｄx) = (ｗ1, ｗ2, ..., ｗq)，ｗi = TF(ｄx) * IDF(Ｄ, ｋi)
  

Ruby + Eclipse 初體驗？

因為要去 interview 一個工作室的暑期實習生，這個工作室都是用 Perl 跟 Ruby，為了生計、也為了能碰點新東西（已經有好長一段時間只是純粹 coding，完全沒有新技術的進步 Orz），所以就來碰一下 Ruby 吧。

Ruby 的 Interpreter 我是用剛出 1.0 的 JRuby（反正我手上的電腦不可能沒有 JDK）。開發環境，當然是找 Eclipse 啦... 於是，這種 survey 的惡夢就開始了.... [暈]。

一開始找到的是 RDT，矇著頭找到 remote site 的 url... ㄜ... 失敗？ 後來檢查了一下 remote site 的 home page... 怪怪，已經納入 Aptana 的 Project 下，但是 RDT 兩個月前又有出 0.9.0 的 release... #$%&*@!! 不想自己動手弄 plug-in，所以，放棄...... \囧/

後來 google 到 Javaworld@tw 的這篇（什 麼時候 Javaworld@tw 也專心搞 Ruby 了），於是就找了 DLTK 來用，等等，還得先下載 Eclipse 3.3 版才能順利 plug-in。好吧... 3.3 版也弄了、DLTK 也裝了... 來寫只有三行的 Hello Ruby... 什麼？ 執行錯誤？ 不知道為啥 DLTK 會下一堆參數，其中出現「(」，就掛了... Orz。以我有限的知識...... 放棄...... \囧/

最後又找了一個 RedRails 的套件，ㄜ... 什麼... 還是 Aptana 的勢力範圍？好吧，乖乖按照這篇文章弄好了 RedRails，然後也可以執行 Ruby（好像是廢話），用 JRuby 也沒有問題... \囧/

好了，就是這樣啦...

雖然也買了一本 Ruby，一本 RoR 的書，翻了一翻...
唉... 不要說我熱愛 Java，這聽起來就很鳥。應該說我的智商還是沒辦法處理這種 script language... [遠目]

2007.06.14 補刀一下：
我拿人生當中第一個程式題目：終極密碼戰，來 try 一下 Ruby。發現如果用 RedRails + JRuby，如果強制關掉執行中的 rb，雖然 Eclipse 上是停止了，但是實際上會有一個 javaw.exe 跑個不停... Orz。如果乖乖讓程式跑完就沒有問題 [遠目]

哀號「上台報告」

其實我對上台報告這件事情很感冒。倒不是怕自己上台說話（以前比較「斃俗」的時候，平常根本不多話，但是站在講台上就話很多），而是怕別人上台說話。為了 得罪多一點人 \囧/，這裡的「別人」包括了 80% 的老師、99% 的同學，尤其是擺著投影片、看著投影片說話的講者。

坦白說，如果說是要 show 公式、虛擬碼、流程圖、圖片、表格，那也就算了。但是，現在普遍的觀感是，講者懶得記得（或是記不得）這些東西，然後丟在投影片上，可以看著講，還可以美其名說「一圖解千言萬語」。也就更不用講把台詞幾乎都放在投影片上頭的人了。

說真的，投影片到底是用來幹麼的呢？上課還發投影片紙本檔簡直就是嫌地球樹木太多。

我目前遇到能留下深刻印象的講者（其實不太多 [嘆]），一個是東海的陳以愛教授，另外一個是Friedman 在 MIT 的演講（也許還有其他人，不過暫時忘了 lol），統統都沒有用投影片 [怒吼]。

另外一個好玩的事情是，Friedman 在 MIT 的演講，開場提詞的 MIT 的校長 Charles Vest，他短短一兩分鐘的開場，也是魅力四射、印象深刻。後來看到他在亞太區域研討會的演講，看著講稿，就實在... 我看了三分鐘就睡著了 Zzzz.....

反過來說，現在很多時候的報告都是趕鴨子上架，即使想要準備好也沒時間準備 [嘆氣]。

下面是之前看到的一個講投影片的文章，順便轉貼上來，除了充篇幅之外，也算是給那些有準備好、也想講好的人一個... 嗯... 另外的觀點。

學術的演講也可以（本來就要！！）很有吸引力！


========
使用簡報軟體的九大錯誤

　　常運用簡報軟體進行演講或報告嗎？就算是一些知名的企業主管
，也常常變成糟糕的演講者，因為他們錯以為科技可以幫他們化腐朽
為神奇。

　　美國溝通訓練顧問布赫（Dianna Booher），日前於CEO
Refresher 雜誌指出，很多人在使用簡報軟體時，常犯以下九大錯誤：

1.用簡報軟體掩飾所有問題。
　　主講者把簡報軟體視為報告內容的提示卡、填補報告多餘的時間
，或者讓雙手有事可忙，避免不知所措。簡報軟體成為掩飾問題的盾
牌，沒有發揮應有的功能。

2.簡報軟體成為主角。
　　簡報軟體的重要性超越了主講者，報告主軸不應該是主講者引導
聽眾，從一張投影片到下一張投影片。主講者才是主角，簡報軟體只
是發揮助功效果的配角。不要有「既然要使用簡報軟體，不如就多做
幾張投影片」的心態，平均而言，報告時每分鐘最多使用一張投影片
。

3.使用冗長的條列內容。
　　使用簡報軟體時，最糟的情況是，投影片上只有密密麻麻的文字
，其次是，投影片上點列出一長串只有一、二個字的內容，看起來有
如家庭主婦的購物清單。應該思考如何以純文字以外的方式表達，增
加照片或圖表等視覺元素。

4.選擇不適合的視覺輔助工具。
　　實物或模型適合說明，圖表適合顯示趨勢或比較，照片和卡通則
適合表達概念。了解報告的目的，選擇最適合報告的視覺輔助工具。

5.對著簡報軟體報告。
　　主講者對報告內容應該熟悉到可以看著聽眾，而不是一直看著簡
報軟體，尤其忌諱把簡報軟體上的內容逐字照著唸。

6.把簡報軟體工具擺放在舞台中央。
　　在聽眾正前方的應該是主講人，而不是簡報軟體工具，如果主講
者站在一旁，會成為唸旁白的角色。在大部份的演講報告場所中，把
播放簡報軟體的螢幕，斜置於舞台的一角，主講者站在舞台的中央，
是較佳的選擇。

7.製造混亂。
　　投影片避免添加無關的圖文，也避免丟給聽眾一大堆的數字，這
兩種情況都會造成模糊焦點的效果。在版面方面，統一字型和大小，
二者都以適合聽眾閱讀為考量標準，不要製造視覺上的混亂。善用留
白，幫助聽眾看出哪些是主要概念，哪些則是次要概念。在數字方面
，只給予聽眾關鍵的數字，例如，公司的支出增加了四0％，如果必
要，其他的次要數字可以印成講義，供聽眾在報告後參考。

8.充斥過多的訊息。
　　一張投影片應該只有一個主要概念，使用簡報軟體的一個主要目
的，是簡化複雜的資訊，如果聽眾必須仔細研究才能了解軟體上的內
容，便失去了原來的意義。

9.投影片轉換過於花俏。
　　投影片轉換的方式會影響簡報的速度感，如果投影片是以逐漸淡
出和淡入的方式轉換，報告的步調會顯得比較慢；如果是以快速飛出
和飛入的方式處理，步調則會顯得比較快。設法統一轉換的風格。

資料來源：EMBA 電子報 2003.11.10

Social Network 速寫

講兩面手法有啥意義啊....

一個社交網路大小介於 0~150，avg = 124 （Hill and Dunbar, 2002）
Stanley Milgram (1967) 發表 Six Degrees of Separation

Social Network 的 Tool
UCINET6（分析一個矩陣內容的值）
NetDraw 2.055（對矩陣內容作視覺化）
Mage、Pajek、Inflow、KrackPlot
知道這些分析軟體，可能是今天最大的收穫 [毆飛]

閒談 Open Book

上大學之後，跟高中之前的學校生活，差異還蠻多的。就考試這點來閒扯的話，最大的差別大概就是大學考試有 open book 這檔子事情。

我在高中的時候曾經很幻想 open book 的考試。國文英文也就算了，至少數學物理化學的公式不用在想盡辦法刻在桌面 or 寫在手掌心，然後偷偷摸摸怕被發現。

上了大學之後才發現，也不是每個老師都來 open book 這招（當然，還有更多老師連考試都懶得考），偏偏討厭 & 不會過的課都不 open book [無奈地攤手]。

系 上有個老師，他說他的課從不管是幼稚園還是研究所都 open book，除了打電話跟背人進去（那時候無線網路還有起來），其他要帶啥都可以。第一次考試，我就真的扛了台 NB 進去 lol。後來發現大家都拿著厚厚一疊筆記（而且有一大半都是我寫在系站上的），覺得沒啥意思。之後就啥都不帶，兩手空空（有時候還故意遲到）大搖大擺進考 場，然後想辦法搶第一個交卷 \囧/。

偏偏我們這屆被他教到的必修課又有點多，從大一計算機概論（一年），到大三 OS, DB 加起來又一年。忘記是哪一次考試了，就爆了個囧點。拿到考卷一看... ㄜ... 什麼...

請翻開課本 p.xx 看圖 x，說明為何......

我：[舉手] 老師，我沒有課本沒辦法作答 \囧/
老師：....... 怎麼會沒帶咧......
我：open book 又沒說 need book \囧/

下一次考試依然有「參見課本」這招，老師還準備一本借我，不過我看到題目就直接硬上回答了 \囧/。

我 前後修了那老師三年的課，DB 跟 OS 都重修，DB 真的是個性不合，搞那些瑣碎的細節跟理論實在沒轍，也沒怎麼去上課 Orz。OS 則是第一次玩太大，作業都不交考試又粗心炸掉 lol。老師上課其實有點隨性所至天馬行空，偏偏內容又硬底子扎實；據說很多人都聽得懵懵懂懂，所以常常是我負責接他的梗 、回答問題、提出問題（然後據說我開口之後，同學就從聽得懵懵懂懂進階成完全聽不懂... [無奈地攤手]）。到後來有冒出一句「這一班點潘先生有沒有來就好」。據說我修完 OS 的隔年，老師某一次 OS 上課中突然問「怎麼潘先生都沒來。」

回顧從國中開始的 Computer Science 生涯，從 QB 到 Java、從進位轉換到 OS 原理，腦袋中那些斷垣殘壁 [慘笑] 幾乎都是自修來的。若中間有些還沒忘掉、扯到 OS 時候可以拿出來檢視的舶來品，那大概都是這個老師塞進腦袋裡的。

今天分散式系統考試前，看到同學們人手一張精緻小字的 A4 紙，想起這些零零碎碎的往事，就順手寫下。

20070420 DistSys 速寫

Jitter is the variability of packet delays within the same packet stream

RTSP：stream 的 HTTP?

IGMP：
Internet Group Management Protocol
歐規 router 必須要 support 這個 protocol

IPTV 用 IGMP
VOD 用 RTSP

Hub, Switch, Bridge, Router 比較

大概三四年前，在系站上轉錄這篇文章（還不就為了吵架 \囧/）；前幾天又在 ptt 上頭看到類似的問題，所以挖出來重貼。今天胡亂翻到分散式系統課本的 network 章節，就想說那也順便把這篇給 web 化吧。

念 網路的東西很麻煩，因為東西很多很雜又很亂，當年看到 P 結尾的名詞就頭大，不是說用 TCP/IP 嗎？那為甚麼還有啥 ARP、ICMP、SMTP、SNMP、HTTP，萬一碰個 router 或是高階 switch，又是一堆 xxP....... [暈]，這些還不夠，還會扯到一堆 802.x 的東西...... [倒地]。單靠自己囫圇吞棗 + 週期性懶散，結論就是：還是寫程式好 \囧/。不過當網路的東西念通了、能把那些 P 分層別類安頓好，事情就會變得美妙。從 y2k 到現在，似乎也只有 RG-58 消失，RJ-45 的接頭依舊是「白橙橙白綠藍白藍綠白綜綜」，TCP/IP 還在、而且 IPV6 離一般人很遙遠。是多了一些東西，但是跟寫程式比起來，可少得多了.......

喔喔喔... 回歸主題 [毆飛]

----------------
資料來源：《Cisco 路由器設定 (Managing IP Network witch Cisco Routers)》 p.36-39，O'Reilly 1998.12 初版，ISBN：957-98213-7-2。

集線器、橋接器、Switch 與路由器
在討論路由器的放置地點之前，先確定你是否需要一台路由器。能不能用 Switch（交換器）或 Bridge（橋接器）之類的設備代替？通常網路公司的業務員不會回答這類的問題，但每種設備在網路中都有獨特的地位。你必須了解它們各自的特性，尤其是他們的弱點。

最 簡單的網路設備就是集線器（Hub），應該也是網路上最常見的機器。一般網路如 Ethernet，Token Ring，或 FDDI 都會有 Hub，選購安裝都沒有什麼學問。我們就略過不談。Hub 的等級和價格沒太大差別，主要是有沒有操作界面。但 Switch，Bridge，和路由器就完全不是這麼回事了。

幾年之前，還有人在爭論網路是該透過 Bridge 還是該透過路由器連接。Bridge 陣營堅持路由器太複雜，速度太慢，設定維護太困難；路由器陣營則預測網路會大幅成長，Bridge 將無法應付。當然，路由器最後佔了上風，網路成長的規模出乎每個人的意外。路由器的可擴充性（Scalability）是 Internet 成長的動力。

為什麼 Bridge 的擴充性不夠？這牽涉到 Bridge 本身的運作原理。當一台Bridge 收到來自網路的框包（frame），會檢查框包內的目的地位址，和自己知道的地址比對；找到符合的位址之後，它會決定是否傳送這個框包到目的地所屬的網路 區段，或是轉送到目前目的地中途的區段。如果 Bridge 知道框包是來自和目的地同樣的區段，它會忽略這個封包，因為目的地自己會接收。

如果 Bridge 不知道目的地位址，它會假定目的地可能在任何地點，直接傳送框包。如果目的地傳回一個回應訊息，Bridge 會根據訊息中的位址加在自己的位址紀錄中。所以 Bridge 是根據收到的框包位址來判斷網路組成的架構。

這個程序就是 Bridge 運作的核心。但某些框包是 Bridge 必須送到每個地方的，就是 Multicast（多址傳送）與 Broadcast（廣播）框包。由於網路上每台機器都必須收到這些框包，意思是網路上會充斥（flooded）這些框包。

Broadcast 和 Multicast 類型的框包限制了 Bridge 網路的擴充規模。當網路上的機器數量增加時，需要廣播的框包也隨之增加。平均來說，一台機器每十秒送出一個廣播，如果網路上有 1000 台電腦，平均每秒就有 100個廣播在流竄。如果有十萬台機器，情況將難以想像！

佔據頻寬並非廣播的唯一問題。因為每台機器必須時時檢查廣播框包的內容，所以會透過中斷處理。如果一直造成中斷，機器效率會慢下來，網路協定堆疊也會難以運作。

難 道機器每十秒一定要送出廣播嗎？想想廣播與多址傳送的應用情況。在IP 協定裡面，廣播是應用在位址解析（ARP，Address Resolution Protocol），路由更新，以及 rwho 之類的服務。Multicast 的應用功能大致差不多，但相對 Bridge 構成的網路來說，Multicast 和 Broadcast 沒什麼差別，反正都是要充斥整個網路。有些 Multicast 和 Broadcast 封包是定時傳送的，以 rwho 和一些路由協定資訊來說，大約每 30 秒會送出一次。

但 rwho 在這個週期之下只能送出一個封包，某些路由協定如 RIP 可以送出許多封包。對一個大型網路來說，可能一次有 10 個封包。

其 他協定對 Broadcast 和 Multicast 傳輸也有一些影響。AppleTalk 這種協定在進行資源搜尋，位址指定，或路由等動作時，會大量使用 Multicast 和 Broadcast。Novell 的 IPX 協定在服務宣告與資源搜尋時也有類似的傾向。

看以上的敘述，你不得不相信，每台機器十秒一個框包算是相當保守的估算，如果加上其他稀奇古怪的協定，產生的框包傳輸絕對不只此數。

難道路由器就能擺脫這些問題嗎？路由器的擴充性是否比 Bridge 來得好？要回答這個問題，首先讓我們看看路由器的原理。

路由器採取的做法
Bridge 在決定是否轉送框包時，是根據目的地的硬體位址。如果不知道目的地位址，或是確定框包前往的區段不在來源區段，就進行轉送。路由器傳送封包時的決定過程很類似，差別在於路由器根據的是網路層位址，而非硬體位址。但這不是唯一的差別。

真 正的差別在於網路位址是由人來指定的。原則上，具有共同 prefix 的位址都屬於同一個網路。相對上，硬體位址是製造廠商決定的，不管網路的實際配置。考慮實際的網路配置，可以增進資訊聚集（aggregation）的能 力。一個 1000 台主機的網路上的 Bridge 可能要追蹤 1000 個地點才能做出決定，但一台路由器只須追蹤 10 個以下的位址就夠了。這就是路由器高效率的主因。

資訊聚集的能力，使得路由器比 Bridge 具有更強的擴充性，但還有其他因素。Bridge 必須隨時注意網路區段的每個封包，因為它必須確定封包的目的地位址來決定是否傳送。路由器不需要隨時注意每個封包，因為封包傳送者已經決定了封包是否要轉送。如果傳送者知道目的地不在本身的區段，就利用路由器本身的硬體位址當作目的地位址，直接傳送給路由器。所以路由器只需要注意直接傳給它的封包，大大降低了路由器處理的流量。

Routing 的可擴充性還有更重要的因素。Bridge 必須傳送所有的Broadcast 和 Multicast 封包，但路由器採取不同的做法。因為路由器知道網路的實際配置，它會建立廣播網域（Broadcast domain），這只是網路的一部分，但網路上所有的機器都可以看到廣播封包。除非特別設定，否則路由器不會隨便傳送廣播封包。例如，你可以設定一台路由 器轉送 BOOTP 或 DHCP 的廣播給遠端伺服器，傳送 IP Multicast 封包給已登錄的主機。除了節省 Broadcast 和 Multicast 的傳輸之外，路由器在其他方面也可以減低頻寬的使用量。

除此之外，如果路由器收到一個無法傳送目的地的封包，它會丟棄（drop）這個封包，並回應一個訊息給寄出封包的主機，表示傳送失敗。

總結來說，路由器的擴充性是由於下列幾個因素：

• 由於網路位址是配合實際配置來指定的，它具有高度的資訊聚集能力。
• 它不必隨時注意區段上的每個封包。
• 它會建立廣播網域，減少不必要的 Broadcast 和 Multicast 封包傳送。
• 它會丟棄不明位址的封包，減少頻寬的浪費。

路由器與 Switch
路由器顯然比 Bridge 優越，只是 Bridge 不需要複雜的設定程序，也沒有人會為 Bridge 設定特別寫一本書。由於電腦硬體的速度越來越快，反而網路的頻寬成為新的問題，這就是 Switch 出現的背景。

Switch 絕大部分都是應用在 Ethernet 上（目前 Token Ring 與 FDDI switch 也日漸普遍），它透過分散頻寬的方式增加頻寬的使用效率。你可以更換硬體增加頻寬，例如將 10Mbps Ethernet 換成 100Mbps Fast Ethernet，但你得同時需要更換新的集線器，網路纜線與網路卡，這是一筆不小的花費。

Switch 扮演了一個特殊的角色。在一個分享的網路區段上，每台主機都是碰撞網域（Collision Domain）的一部分，因為 Ethernet 的傳輸會互相爭奪頻寬導致碰撞。路由器有能力縮減碰撞網域的範圍，但成本太高，而且設定複雜。以一個連接 24 個 Ethernet 區段的高速路由器來說，大概需要 10 萬美金。但一台 24-Port 的同級 Switch 只需要 8 千美金左右。那為什麼不乾脆把路由器甩在一邊，全部都用 Switch 就好了？一旦你明瞭Switch 運作的原理，答案就很明顯了。讓我們先看看 Switch 工作的方式。

當 Switch 收到一個框包，它必須判斷目的地在網路上的位置。Switch 檢視框包內的目的地硬體位址，檢查轉送表，如果找到符合的資料，就將框包送往表上指定的埠。如果找不到，它就將框包送往除了來源之外的每一個埠，希望收到 的目的地會送出一個回應，讓 Switch 更新本身的轉送表。廣播與 Multicast 都送往每個埠。

----------------
另外 p.40 頁說，switch 說穿了，就是一個多 port 的 Bridge
其他的沒啥好提的，所以就省略不 post 了

分散式系統上課方式將有重大變革

據可靠消息指出，梅老大的上課方式將有重大改變。除了增加課堂抽問次數、抽問回答不出來會導致成績趨近 69 分外，也會增加隨堂隨機小考，以檢測出同學們課前預習的細讀程度以及上課的認真度。期中考後的 presentation 也會邀請熟悉該領域的前輩在台下開砲，修理報告準備不夠充分的組別。

據傳梅老大有此大幅度的變化，是起因於上課丟問題都沒人認領回答；提到課本內容，台下亦一片默然，顯示 pre-class 的 blog 仍然沒有起預期的效果。思索教學方式後所作的決定。

另外，梅老大打算於下門課，增加幾項規則：

1. Office Time 不變，但是地點改在 Second Life 上，meeting 亦同。syllabus, 上課投影片亦在 Second Life 上公佈。
   
2. 修課同學需有速讀的能力。如果沒有，可於課程開始前向梅老大申請速讀速成班的學費補助款，以習得速讀能力，方能跟得上梅老大抽投影片的速度。
3. 對 Second Life protocol 熟悉，或是有 hack 經驗的，可得到成績 bonus。

也有消息來源指出，梅老大正在跟中研院的 CKIP 小組討論技術交流的可能。若能雙方能順利合作，則對「中英文錯字自動校正」領域會有顯著的貢獻。

撰文：于仁傑 \囧/

廢言廢言廢言廢言

我在 ptt 的 Prob_Solve 版看到這句話：

popcorn5368:這個結構是有cycle的DAG(directed acyclic graph)

看他問的問題，應該是個研究生，是不是 computer science 領域的就很難講。anyway... 能寫出這種句子，有時候不禁懷疑，台灣的教育到底教出了什麼東西？

Java Browser Project 調查報告

→http://html.xamjwg.org/index.jsp
測試了幾個自己的網站，網頁 support 奇慘無比。我實在看不出來他哪裡支援 JavaScript 跟 CSS =.=（難道 JSPWiki 裡頭的 CSS 不是 2.0 版？）、編碼支援也很糟糕。重點是，連我的首頁（只有基本到不行的 html 碼）都顯示的很糟糕....

→http://browserlaunch2.sourceforge.net/
這是一個有點莫名其妙的 library，他不是寫一個瀏覽器，而是讓 Java 去呼叫外部的 browser 然後開啟你要的網頁（路人：人家明明 project 名稱就這樣寫了，幹麼說人家莫名其妙 [踹]）。雖然跟要找的東西無關，不過還是順便 memo 一下。

→http://www.icesoft.com
這個測了一下，還不錯，不過他的 open source 很奇怪。有給某些 source，不過和新的部份好像都沒有附... 不過倒是在他的 Developer Guide 當中找到應該更貼近目前需要的名詞「HTML Rendering」

就先到這裡 hold 住吧...

檔案系統？

這一篇速寫提到了檔案系統，然後包括梅老大跟路人（這位大大到底是誰 @_@??）都有回應。

我覺得，雙方的重點好像有點交錯。關鍵點似乎是「檔案系統」的定義問題。於是，讓我們翻開恐龍書第 6 版第 11 章 p.371，裡頭說：

The file system consists of two distinct parts: a collection of files, each storing related data, and a directory structure, which organizes and provides information about all the files in the system. Some file systems have a third part, partitions, which ar used to separate physically or logically large collections of directories.

再來跳到 p.383，有這段字：

First, disks are split into one or more partitions...... Second, each partition contains information about files within it. This information is kept in entries in a device directory or volume table of contents. The device directory (more commonly known simply as a directory) records information - such as name, location, size, and type - for all files on that partition.

在這樣的定義下，我會覺得不管是梅老大講的內容 or Cheng-Yen 講的內容，始終還是落在 file system 的範圍當中，是把功能縮減到只剩下必要的部份、刪去像樹狀結構、權限管理等等的顧慮。我的疑問也可以說由此而來。

好了，說完了，還請各位大師賜招... [擺茶點]

碼的問題

咪的，我不是要故意罵髒話，而是真的是碼的問題。

這周上主題分析的時候，移師到社圖八樓上課，由圖書館負責編目的大姐大們實際操作 Millennium 來講解。由於這家公司完全沒有作 L&F，所以很快的就懷疑這套系統是 Java 寫的，事實上，也的確是 \囧/。（嗯... 發現有 Java 寫的 application 還是蠻值得高興的 \囧/）

講到日文書的編目的時候，大姐大們特別吐苦水，就是沒辦法用國圖的資料作抄編。原因是國圖的資料是用 Big5 來顯示日文，複製貼上到 Java 上頭會掛點。

於是研究了一下這件事情，於是好玩的事情來了。用 IE6.0 開國圖的資料，的確日文會出不來，複製到筆記本會掛掉；但是用 FireFox 0.9.2 看，資料都是好好的，複製到筆記本也 ok。

我在現場有 try 過，如果用 ZTerm 把 BBS 上的日文複製到 Millennium 上頭，又沒有問題。於是考察了一下 ZTerm 的處理方式... 看不太懂 T__T，Convertor.java 提供的 method 拿來亂測了一下，也都失敗。「可是 ZTerm 複製貼上沒有問題阿阿阿阿～～～」我心中如此吶喊著。

好了，爆笑的點來了 \囧/。

只要把字串這樣子處理：

String output = new String(context.getByte(), "Big5");

就沒問題了。（之前還懷疑是系統的剪貼簿有神秘的功能... lol）

這樣說來... 咪的... IE 是在幹什麼吃的... [飛踢]

20070323 DistSys 速寫

lifetime 跟 scope，是各種議題始終不變的關注點。

安全性的部份... 帶過去的很快，我也昏沉的很徹底... \囧/

開始扯到 NFS 了，梅老大提到有些嵌入式系統沒有 File System。這點我提出問題「如果沒有 Fily System，那上層的 system 怎麼知道檔案從哪裡開始從哪裡結束？」梅老大回答的內容比較偏向「沒有 File System 會有什麼好處」，主要的論調是 File System 其實是個 overhead。但是... 嗯... 好像沒有回答到這個問題？（還是我曲解 File System 的涵蓋範圍跟功用？ =.=?）

NFS 是 stateless server。

解決多個 cache 之間的資料同步，用 timestamp 作解決方法的起點。

====
咪的，講得多還不如講得深吧.... 都研究所了耶....

快快樂樂學 RMI － Start!

身為一個只會寫 Java 的人而言，遇到分散式系統，好像不能不實際來 try 一下 RMI。不過對於用 Eclipse 習慣的人而言... 寫 RMI 實在好麻煩啊... [泣]，google 找到的 plug-in 似乎只有這個，但是看到他要收費，馬上就軟掉（？）了。Ant 又完全沒有用的習慣，還是回憶一下 bat 檔怎麼寫吧... Orz

好了，言歸正傳。

因 為種種點點點我不知道的原因（理論上是因為 Java 沒有多重繼承，然後 RMI 又希望溝通的物件是 parent class 是 java.rmi.server.UnicastRemoteObject，不過這純屬猜測... API 懶得看 XD），所以真正要讓 client 可以遠端呼叫的物件，必須讓它 implement 自己訂做的 interface，而且這個 interface 還得 extend java.rmi.Remote。所以，就先來定義一下 interface 吧：

FooInterface.java

package test.remoteInterface;

import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.Date;

public interface FooInterface extends Remote {
  public Date getServerDate() throws RemoteException;

  public String getServerMessage() throws RemoteException;

  public void setServerMessage(String s) throws RemoteException;
}

這 裡留了幾個惡搞的空間。只要 Server 跟 client 不同機器，且時間調的不一樣，那麼 getServerDate() 就可以顯現出差異。而 serverMessage 的 setter 跟 getter 是用來測試 server 端的物件如果被改變，能不能 keep 住。下面這個實做就變得沒啥好講了... [茶]

FooObject.java

package test.remoteObject;

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
import java.util.Date;
import test.remoteInterface.FooInterface;

public class FooObject extends UnicastRemoteObject implements FooInterface {
  /**
   * 為了減少 warning 而加的
   */
  private static final long serialVersionUID = 1L;

  private String message;

  public FooObject() throws RemoteException {
      super();
      message = "Default Message";
  }

  public Date getServerDate() throws RemoteException {
      return new Date();
  }

  public String getServerMessage() throws RemoteException {
      return message;
  }

  public void setServerMessage(String s) throws RemoteException {
      message = s;
  }
}

然後追加一個 server，執行這個就可以讓他接客了 \囧/
FooServer.java

package test;

import java.net.MalformedURLException;
import java.rmi.Naming;
import java.rmi.RemoteException;
import test.remoteObject.FooObject;

public class FooServer {
  public static void main(String[] args) {
      FooObject foo;
      try {
          foo = new FooObject();
          Naming.rebind("rmi://127.0.0.1/FooServer", foo);
      } catch (RemoteException e) {
          e.printStackTrace();
      } catch (MalformedURLException e) {
          e.printStackTrace();
      }
      System.out.println("Foo Server is ready");
  }
}

最後，當然是來寫 client 端啊：
FooClient.java

package test;

import java.net.MalformedURLException;
import java.rmi.Naming;
import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.util.Date;
import test.remoteInterface.FooInterface;

public class FooClient {
  /**
   * 1: ip 位址
   * 2: 設定字串
   * @param args  參數
   */
  public static void main(String[] args) {
      try {
          FooInterface foo = (FooInterface) Naming.lookup("rmi://" + args[0]
                  + "/FooServer");
          System.out.println("Server Date : " + foo.getServerDate());
          System.out.println("Client Date : " + new Date());
          System.out
                  .println("Before set message : " + foo.getServerMessage());
          foo.setServerMessage(args[1]);
          System.out.println("After set message : " + foo.getServerMessage());
      } catch (MalformedURLException e) {
          e.printStackTrace();
      } catch (RemoteException e) {
          e.printStackTrace();
      } catch (NotBoundException e) {
          e.printStackTrace();
      }
  }
}

給 我等一下！[指]，並不是這樣子 compile 完，分別執行 FooServer 跟 FooClient 就能用。你還得針對 FooObject 另外作 rmi compile 的處理。在這個 foo 的例子當中，就要下（classpath 等問題請自己搞定）

rmic test.remoteObject.FooObject

這會另外產生 FooObject_Stub.class，在包 client 的執行環境，這個檔也要加進去。

另外，在執行 FooServer 之前，得先執行一個程式 rmiregistry（在 {JDK}/bin/）。如果你也不幸是用 Windows，那在 command line 的環境下打「start rmiregistry」，會另外自動開個黑窗。

一切都順利的話，就可以來真正來玩玩看了。[茶]

錯誤排除區：
java.net.ConnectException→咪的，rmiregistry 啟動了沒？

備註區：
網路上的範例幾乎都有在 client/server 端的程式碼來這行：

System.setSecurityManager(newRMISecurityManager())

但是... 我用了反而問題一大堆（有設定 java.policy 了），還搞出一堆靈異現象。拿掉那行反而一點事情也沒有 [爆]。

20070316 DistSys 速寫

JMS 跟 RPC 有什麼差別呢？目前好像在課堂上沒有看到 JMS 這個名詞，於是 google 了一下，發現這個 javaworld@tw 的這個連結（Blogger 版）。好像就解決這個疑惑了... 不過瞄了一下其他 search 結果... ㄟ都... 那 JMS 跟 SOAP 呢？ [抓頭]

idempotent：arbitrary failure will not occur
idempotent op：repeated execution is same as exact one execution（例如讀取資料）
有點雞肋的兩個詞... ＝.＝

JINI v.s upnp，光聽 upnp 指定用 http 跟 XML，好像比較帥，不過聽到 M$ support，恩... 掰掰... [揮手] \囧/。我是不覺得 JINI 會被 upnp 幹掉... 不過這樣子的想法似乎只是空想，沒啥根據 [毆飛]

RMI 只支援 client polling，要作 callback，讓 client 也變成 server 就行啦 \囧/

分散式作業系統，用使用者的角度來說，就是使用者不用管程式在哪台機器上頭跑。

OS 當中....
Monolithic kernel：全部都塞在一起
Micro Kernel：分拆成不太小的小部份，組合在一起

Distributed System Challenges

（晚上被案主以及老友騷擾，原本想閒散的晚上就這樣沒了。睡覺前於心不安（尤其是看到 blog 的 comment... [炸]），於是打開課本隨手翻翻。看到第一章的這個環節，覺得有必要寫個籠統的亂譯 + 筆記。

那就來開打吧... \囧/

分散式系統的挑戰：

• 異質性（Heterogeneity）
• 公開性（Openness）
• 安全性（Security）
• 拓展性（Scalability）
• 錯誤控制（Failure handling）
• 同步（Concurrency）
• （Transparency）

異質性的環節在於：要允許不同規格的硬體規格、OS、網路結構（當然，如果舉 Internet 為例子，最終還是得靠 TCP/IP 家族的 protocol 來溝通。這指的是比 IP 更低層的網路），甚至不同的 PL 以及不一致的 pr 實做，都能夠一起運作的很快樂。解決之道應該還是 Layer, Liar 的方式，然後要大家在某一層一致的遵守某個 spec，或是轉換成某個 spec。

開放性，其實對我來說，就是異質性的反向講法。所以跳過。

安全性... 應該不是這本書的重點（都可以另外寫好幾本書了 XD），只是觀念的話，也跳過。

拓展性，這裡提到了幾個關於這點的挑戰：

• 控制實體資源的成本：「表面上添機器就能解決問題，實際上不然」說得好，不過實情還是等到第八章再說 \囧/
• 控制效能的流失：最後一句說「如果一個系統要有拓展性，那麼效能的流失必須小於 O(log(n))」，這... 好像怪怪的...
  
• 防止軟體資源用盡：舉 IPv4，實在是很好卻也很對不起當年 designer 的例子。以前江老師說：「要是當年 IP 是台灣人設計的，那大概五年之後就把 ip address 用光得改版了，2^32 次方已經算是天文數字了啊......」
• 避免效能瓶頸
  

錯誤控制，好像沒啥值得特別一提的：錯誤的偵測、掩飾、容忍、修復... 幾乎跟 deadlock 一樣（廢話，deadlock 也算是一種在 OS 上出現的錯誤啊...），真希望看到一些新的招數 XD。另外 Masking Failures 的第二項不就是 Redundancy 嗎？是作者畫蛇添足 or 是我理解錯誤？

同步問題... 跳過。

我放棄把 Transparency 翻譯成中文。對我來說，transparency 也還是 Layer, Liar 的另一種講法（啊不就是用的人不用真正知道些什麼，還是可以用得很快樂 \囧/）。而這本書似乎是想要以此作為前頭六項的終極目標 or 總結。嗯... 這樣子是也還不錯啦... 不過當看完異質性的部份，應該就能了解 transparency 了，不是嗎？ [抓頭ing]

好了，終於看完第一章了，從 03.12 寫到現在，還真 xx 的沒效率。

下面是縮寫區：
CORBA = Common Object Request Broker Architecture（課本 p.17 少了 A 的全文）
RMI = Remote Method Invocation
RFC = Requests For Comments

weco.net 的 blog 又掛了 lol

昨天上分散式系統的時候問了一下關於 trackback 的問題，結果梅老大的回答很妙：

沒有 trackback 那你就不應該用那個系統，你就該用我們提供的 blog。trackback 是 blog 當中很重要的功能。

當然啦，我是不太喜歡 blog 這種傳播載體啦，現在會搞 blog，不是因為想靠 AdSense 賺錢，就是因為上課需要。trackback 重不重要... 我倒是沒資格講什麼，我又不是資深的 blogger。

不過，好笑的是：

1. 梅老大壓根沒聽過 Blogger、BlogSpot。
2. Blogger 其實有跟 trackback 一樣的功能，但只能對 Blogger 上的文章。[聳肩]

稍微關心一下 blog 發展的，很難不知道 Blogger 吧？尤其是他後來的東家變成 Google [無奈的攤手。至於 Blogger 沒有 trackback 的功能... 我只能說... 這是我討厭 blog 的原因之一，畢竟 blog 還是沒有正式的標準，像 RSS 這種文章訂閱的功能，LifeType（weco.net 用的 blog system）上頭就提供了四種規格 RSS 0.9, RSS 1.0, RSS2.0, Atom 0.3，我是沒研究這幾種規格上面到底差別在哪，但是重點是... 咪的，有沒有這麼多種啊... [飛踢]

好了，這些其實都是小事情... 最爆笑的一點是...

weco.net 的 blog service 又掛了... lol

說「又」，是因為在上個禮拜上完課就發現分散式系統的官方 blog 掛了，後來寫信給梅老大提過這件事情（還有 del.icio.us url 的錯誤），後來 fix 了。然後今天又炸了...

當 個 service provider，就要有 7*24 的覺悟、還包括資料備份等等的問題（哎呀... 關公面前耍大刀... 我修的可是分散式系統... [炸]）。在一個禮拜內就發現 service 炸掉兩次，我想，會「自願」去用 weco.net 的 blog service 才是傻瓜。

好 啦... 我不想當傻瓜，所以繼續用我的 Blogger。反正除了 trackback 之外，文章該寫的都寫了，張貼時間也有 Google Analytics 可以幫忙證明，期末真的不行再惡性轉到 weco.net 上頭去吧... 哈哈哈哈 [逃]

20070309 DistSys 速寫

Overview 似乎跟廢話很容易扯上關係....

講到 Transparencies 的時候，居然還扯到《世界是平的》的演講內容：UPS 現在 support 很多廠商的維修工作。這... 比喻是不錯啦... 但是，能講點實際 IT 領域的例子嗎？ [嘆氣]

好了，第一章（花了一個小時）只留下這個印象...（這應該歸功於《世界是平的》 lol）喔對... 最好用 Java 寫 Web Server 兩行就可以寫完啦... [翻桌]

「Thin-Client 的觀念一直在變」這句話講的真是好... 不過 Fat Network 大概不會變... （Terminal 年代好像沒這個問題 XD）

TCP 跟 UDP 最大的差別：TCP 有建立 connection、有 flow control、有 congestion control。（謎之聲：離讀 network 的日子太遠了，居然回答不出來... [遠目]）

Interconnection Network：指平行電腦當中眾多 CPU module 與 Memory Module 之間的 network。其他還有像電信的 switch 等等。（重點會在拓樸的問題）

中間其他的... 沒啥能留下印象... 畢竟太 overview 了... [炸]

然後又談了 20 分鐘的 second life... 重點是，講技術面的部份也沒有講的很深入啊....

好了，下課！

無奈....

搞資訊的人，其實不見得怕寫系統，而是怕寫了系統卻沒有人用。同理可以推廣到「自己在用的系統別人沒有在用」。大概是搞資訊的人天生都沒啥號招力，然後不 搞資訊的人卻常常用一些很鳥的系統.... [笑]，偏偏大部分的系統都會牽扯到使用族群大小的問題（想想當年的 ICQ 跟現在的 MSN 吧...）

最近修了輔大資工所的分散式系統，到目前為止，分散式系統長啥樣子還不知道，倒是聽了一堆 second life 的事情（喔～老師買了一塊有無敵海景的地）、要用 del.icio.us、要建立 blog、要在「官方課程 blog」有 comment、自己的 blog 上頭還要有 10 個 trackback post....... 我是不是要慶幸還好不用到 second life 上課...... lol

為了隱藏身份，所以用 pt2club 來開另外一個 blog，系統當然還是繼續用 blogger（這樣子這堂課修完，資料 copy 回本尊的 blog 不會有太大問題 \囧/）。

好了，就在「明天要上分散式系統了，今天來稍微準備一下」，於是爬上官方課程 blog、大概掃了一下有修課同學的 blog，恩... 怎麼大家 po 文的時間都差不多 [炸]，看到這篇〈如何成功 "引用" 文章〉，嗯... 來研究一下 trackback 好了...（雖然說我壓根找不到那篇說的「真實引用網址」是啥）... 嗯？ 嗯嗯嗯？？

咪的！blogger 沒有 trackback 的功能？？？

說實在的，blogger 的中文 help 訊息也有夠「眼球博士」的（雖然說轉成英文語系也好像差不多意思），有些莫名其妙的功能實在是看不懂... Orz，只不過很肯定的查到... 是的... 沒有 trackback 功能...

不管了... 反正梅老大的規矩這麼多，我大概也沒那個腦袋可以全部遵守到底，萬一這點起紛爭然後被當，就在說吧... 哈哈哈哈... 反正我是 trouble maker... [挺]

測試