2007-11-15

TF-IDF

假設要測試的文件為 {D} = {d1, d2, ..., dn}、全部關鍵詞的集合為 {K} = {k1, k2, ..., km}。則:
  • kx1 表示 dx 中 k1 出現的次數
  • TSum(dx) = kx1 + kx2 + ... + kxm
  • TF(dx) = (wx1, wx2, ..., wxm) ,wxi = kxi / TSum(dx)
  • DF(D, ki) = D 中含有 ki 的文件數量
  • IDF(D, ki) = log(2, p/DF(D, ki))
  • TF-IDF(D, dx) = (w1, w2, ..., wq),wi = TF(dx) * IDF(D, ki)

2007-06-10

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。如果乖乖讓程式跑完就沒有問題 [遠目]

2007-05-11

哀號「上台報告」

其實我對上台報告這件事情很感冒。倒不是怕自己上台說話(以前比較「斃俗」的時候,平常根本不多話,但是站在講台上就話很多),而是怕別人上台說話。為了 得罪多一點人 \囧/,這裡的「別人」包括了 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

2007-05-04

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
知道這些分析軟體,可能是今天最大的收穫 [毆飛]

2007-04-27

閒談 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 紙,想起這些零零碎碎的往事,就順手寫下。

2007-04-20

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

2007-04-08

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 了

2007-04-01

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

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

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

另外,梅老大打算於下門課,增加幾項規則:
  1. Office Time 不變,但是地點改在 Second Life 上,meeting 亦同。syllabus, 上課投影片亦在 Second Life 上公佈。
  2. 修課同學需有速讀的能力。如果沒有,可於課程開始前向梅老大申請速讀速成班的學費補助款,以習得速讀能力,方能跟得上梅老大抽投影片的速度。
  3. 對 Second Life protocol 熟悉,或是有 hack 經驗的,可得到成績 bonus。
也有消息來源指出,梅老大正在跟中研院的 CKIP 小組討論技術交流的可能。若能雙方能順利合作,則對「中英文錯字自動校正」領域會有顯著的貢獻。

撰文:于仁傑 \囧/

2007-03-31

廢言廢言廢言廢言

我在 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 住吧...

2007-03-30

檔案系統?

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

我覺得,雙方的重點好像有點交錯。關鍵點似乎是「檔案系統」的定義問題。於是,讓我們翻開恐龍書第 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 的範圍當中,是把功能縮減到只剩下必要的部份、刪去像樹狀結構、權限管理等等的顧慮。我的疑問也可以說由此而來。

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

2007-03-29

碼的問題

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

這周上主題分析的時候,移師到社圖八樓上課,由圖書館負責編目的大姐大們實際操作 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 是在幹什麼吃的... [飛踢]

2007-03-23

20070323 DistSys 速寫

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

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

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

NFS 是 stateless server。

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

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

2007-03-18

快快樂樂學 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 了),還搞出一堆靈異現象。拿掉那行反而一點事情也沒有 [爆]。

2007-03-16

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

2007-03-11

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 上頭去吧... 哈哈哈哈 [逃]

2007-03-09

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... 重點是,講技術面的部份也沒有講的很深入啊....

好了,下課!

2007-03-08

無奈....

搞資訊的人,其實不見得怕寫系統,而是怕寫了系統卻沒有人用。同理可以推廣到「自己在用的系統別人沒有在用」。大概是搞資訊的人天生都沒啥號招力,然後不 搞資訊的人卻常常用一些很鳥的系統.... [笑],偏偏大部分的系統都會牽扯到使用族群大小的問題(想想當年的 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... [挺]

測試