Software Cinema

百萬企鵝是一個嘗試由網路使用者共寫的小說撰寫計畫, 概念顯然地是基於 Wikipedia, 當初看到這個新聞 (Knews) 時, 除了覺得很有趣之外, 其實還對新聞中的一段敘述感到有意思與不解 :

企鵝出版集團強調，這項計畫並非在發掘新作家，所以每位「作者」以 250 字為限，他們呼籲網友要有雅量，尊重別人的國籍、文化及性別，因為每個人的創作都可能會被改動，受不了自己的文章被隨意刪改的人也許不參加為妙。(引用自 Knews )

這是被討論很久的問題, 特別是當初 Wikipedia 計畫開始推廣後, 相對的問題就不曾停止過, 例如 中文 Wikipedia 上針對中華民國的 頁面, 因為爭議太多, 持相異意見的會彼此胡亂刪減修改對方內容, 一直以來都是處於 Semi-Protection 模式下, 幾乎沒辦法對內容做修改, 只能等待討論區有共識之後再說, 換而言之, 在 Wikipedia 上針對此問題的解決是利用 Locking. 真跟上面百萬企鵝新聞稿中的敘述其實很像.

然而, 百萬企鵝何苦要遵循此種模式 ?

回到百萬企鵝計畫的目的, 在他們的 About 中, 首先出現的是粗體字的

Crowdsourcing. The Wisdom of the crowds. Social networking. Collaborative enterprise.

可見百萬企鵝與 Wikipedia 的共同特點, 但是他們決定性的不同卻在於企望達到的目標上. 再參考 About 內的另一段話 :

But what about the novel? Can a collective create a believable fictional voice? How does a plot find any sort of coherent trajectory when different people have a different idea about how a story should end – or even begin? And, perhaps most importantly, can writers really leave their egos at the door?

小 說往往並非事實, 它是 fictional voice 的, 不若 Wikipedia 是以共同建構知識庫為目標. 在 Wikipedia 中, 因為有事實存在, 因此難以容許參雜個人觀感推斷的敘述在內, 然而許多事實卻無法被證明, 只能靠著佐證的史料進行推斷, 由此矛盾就生. 這是短時間內不可能解的問題, 除非我們再度回到過去的獨裁帝制. 百萬企鵝卻不是這樣, 它的計畫要產出的成果是小說, 小說是不是跟事實相關其實根本不重要, 甚至許多地方的邏輯不通其實也不甚重要, 如果我們不期待名家大作, 那麼能有條有理, 有頭有尾地說完一個故事, 其實才是最重要的.

同時, 我覺得這段話裡重新說明了一個重要的事實 : 不同的人本來就會有不同的想法, 只要說的通, 要怎麼想是每個人的自由. 或許小說作者有他想要表達的意念在他的作品中, 但是究竟閱讀者會怎樣解讀, 那其實不是作者能夠控制的事情, 某個角度來說, 作者也只是一個讀者而已. 過去受限於人類所能做到的能力, 小說都是關起門來寫的. 百萬企鵝如果成功, 象徵的其實是打破這個藩籬, 並可以進一步尋求有效 ( efficient ) 的 process 出現. 類似的現象已經在 software domain 出現過了, Eric S. Raymond 著名的 The Cathedral and the Bazaar 十分清楚地說明了此一現象的轉移, 而現在, OSS community 已經在尋找與嘗試 efficient development process 了 ( 但這將會是條非常漫長的路 ) .

百萬企鵝其實應該回到最基本想證明的問題上, 在這樣的環境下, 幾百萬人是不是能夠合作共寫出一部小說其實並不是一個真正需要被解決的問題. 幾百萬人如何能夠合作共同寫出幾萬部小說才是真正應該要被解決的問題. 而百萬企鵝最後產出的那部小說, 其實就是這幾萬部小說中, 最受所有人喜愛的那一本.

雖 然我還不知道這個問題要怎樣解( 要是知道就去寫 paper 開公司了 XD ), 但是可以想見的或許把 content 跟 logic 分開會是必要的, 同時不同版本的 content, logic 是可以同時存在的. 以下圖來說明, 一部小說的內容可以分成數段的 content piece, 靠著 logic 將其連結起來. 如此一來, 每個人可以貢獻自己的想法, 撰寫其中一個 content piece 就好, 不必寫出一整部, 或是較大的區段, 同時結合自己的, 別人的 content pieces, 可以用自己特定的 logic 將其串起來, 但不需要串起全部的 content pieces, 只需要串起說的通的就可以. 從而網路貢獻者又可以分為 context piece contributor 以及 logic contributor 兩類.



同時 content piece 在一定的授權下是可以進一步被拿去修改擴充的, 因此不必有所謂修改刪除別人的文章之情形出現, 而是多重版本可以同時存在, 例如下圖中的 context piece B'' 就是由 content piece B' 修改來, 而 content piece B' 又是由 content piece B 而來. 另外 logic 本身也可以是被重新利用修改的, 例如 Logic One' 就是由 Logic One 修改而來, 替換了最前面的兩個 context piece 連結.


而 logic 與 context pieces 間的關係, 藉由 logic 與 content piece 的分離, 他們之間的關係是 flexible 的, 這樣的想法主要來自於 In-Code Modeling .


如 此一來就不會有百萬企鵝或是 Wikipedia 中, 因為彼此不滿意內容而刪減, 造成爭執的情況出現, 而且各種可能的串聯邏輯可以出現, context pieces 以及 logic 可以很方便地被 reuse / re-use, 整體的 productivity 因而可以提升, 多線劇情小說 (例如 MLNR, 此計劃似乎停擺很久了 ) 的想法也將可以被實現, 這基本上也是 component-based software development (CBSD) 的理想. 當然, 適當的配套措施是要有的, 例如怎樣比對相似的內容, 減少 context pieces 的數量, 避免因為大量的 content pieces 造成 logic contributor 反而需要花費大量時間閱讀可用的 content piece material. 或是適當的 search mechanism 可以被支援, 自動依照 logic contributor 提供的一些線索, 找出適用的 content pieces. 這其實都相似於 CBSE 對於 component 的處理.

或許我之前那邊 Paper Writing Process 也可以朝此方向去解決.

之前看到 runtime@ptt.cc 發布的連連看服務 ( Wretch Relation Map, 不確定此連結會活多久), 其實跟我之前的 Author Net 是一樣的東西. 其實之前也有想過對無名做這種事情, 只是對我實在沒什用處, 加上還要提供 Server 實在太麻煩了, 如果是我應該會寫 client 端程式, 然後發佈出去. 但是這個要考量的就多了, 例如會不會因此變相形成對於無名的 DDOS 攻擊, 到時候帳算到我頭上就不好了.

不過這樣的 DDOS 攻擊蠻弱的就是了, 只要無名改一下 friends link 的呈現馬上就無效了. 但是他也很難就改成無法直接取得的方式, 否則要不就是 usability 降低, 要不就是 perfomance 降低.

真 好奇像是這種 popular site, 怎樣面對合理服務要求的大量 requests, 即便 request 量幾乎等同於 DDOS attack. 當然利用各種 queue algorithm 是一種解法, 但是對於付費者來說, 要跟一般使用者等待相同的時間嗎 ? 提供 service 的 site 怎樣區別一般使用者跟付費使用者 ( 在可以進行 login 動作之前 ), 有可能在 socket connection 建立時就辨認嗎 ? 利用 cookie 是否可靠 ? 但是 cookie 的使用僅在使用者經常使用固定電腦實際較為有效而已.

什麼樣的 services 應該是 open (例如 friends list 察看), 什麼樣的應該是 protected, 這之間跟 site usability 的 trade-off 又是如何, 真是個有趣的問題.

之前在趕 TSE special issue on SESS 的 paper, 跟兩位學長合作寫, 感覺寫的好累.
一方面是時間很趕, 一方面是不久前才完成 ESEM 2007 的 conference paper, 緊接著就是 TSE, 感覺有點疲累, 加上 Lab. 內部的其他小計畫, 還有我的 group meeting presentation 題目未定, 事情好多阿.

寫 Paper 真的需要這麼累嗎 ? 怎樣可以較容易達成 paper writing 的分工 ?

照 現在的運作, 大概是在 paper 的架構訂出來之後就分下去寫了, 對比到 software development 中大概是 architecture 大致確立的階段就分了, 換句話說在 design phase 事實上還有相當大的 variation 存在, 每個人的想法跟理解未必相同, 寫出來的東西在做 integration testing 時需要花的功夫相當大.

寫 paper 究竟能不能像寫 software 一樣, 可以有一個較為嚴謹的 process ?

針對這個問題, 有幾個其實較為明顯可以去思考的點 :

1. Clear responsibility. 在 規劃 software architecture 時, 利用 CRC card 之類的去確認每個 object (under OO paradigm) 的 responsibility 是常見的作法, 對於 architecture 中的各部份之 responsibility 都必須確定, 才知道後續的 design 需要滿足什麼需求, 也不需要多做不必要的事情. 因此是否 paper 的各段落也可以用類似的方法, 確定各段落的 responsibility, 甚至是 non-functional 的條件
2. Regular review. 有 點像 iterative 的開發方式, 在分工撰寫時, 利用 regular 的 meeting, 彼此 reivew 寫好的部份, 確認彼此所寫的仍然忠於原先的 responsibility 規劃, 同時 writing style 可以適度做修改. 關於 writing style, 畢竟 natural language 不像 programming language, 可以制定非常準確的 writing style, 但是以 academic writing 的 context 來說, 應該還是可以訂出一些 style, 這可能要參考一些 academic writing 的書
3. Version control. 如果把 paper 視為 software, 用 version control system 去管理 changes 應該是沒有問題的事情, 只是過去習慣用一個 latex file 紀錄全部文字的作法就要改, 但是基本上這不是什麼大問題. 借由 version control system, 所有的 changes 都更容易進行, 也未必必須要負責該部分的人才能修改. 老師也比較容易看到所有的修改紀錄. 唯一的缺點可能是 security 的問題, 最好該 version control system 架設在實驗室內部網域應該就可以了.

未來半年我自己應該也會有一些 paper 要寫, 有些可能要跟別人合作, 在此之前, 寒假嘗試擬一些 process 出來跟老師討論看看, 然後拿自己做實驗驗證看看好了.

Recently, I am working on a small Lab. project about a novel approach for component storage and retrieval to assist component reuse in CBSD. In the domain analysis phase, some component modeling approaches were surveyed and compared. They were organized (ordered by publication year) in following table for anyone interested.

Works	Modeling Approach	Modeling Target	Classification Base	Retrieval Base
[Ostertag1992]	Graph-based	Functional Property / Component Feature	AI-based / Component Feature ( Feature Distance )
[Frakes1994] ( Survey Paper )	Keyword Indexing	Component Characteristics	Controlled Vocabulary / Uncontrolled Vocabulary	Keyword/ Hypertext
[Zaremski1995]	Signature-based	Function Types / User-defined Types	Signature Matching	Signature(Function Types/ User-defined Types)
[Zaremski1997]	Specification-based	Component Behavior	Specification Matching
[Mili1997]	Specification-based	Functional Property / Component Feature	Functional Property / Component Feature	Specification
[Henninger1997]	Text-based / Keyword Indexing	Component Characteristics	Predefined Categories / User-defined Categories	Keyword
[Seacord1998]	Text-based	Component Interface	Component Interface	Content-based Keyword
[Damiani1999]	Context-based Description	Component Characteristics	Component Behavioral Characteristics
[Inverardi2000]	Context-based	Component Behavior / Component Assumption	Component Behavior
[Plasil2002]	Text-based	Component Interface	Component Behavior/ Component Interface
[Chatzigeorgiou2003]	Graph-based	Message Exchange ( Component Function Call )	Component Quality
[Vitharana2003]	Knowledge-based	Component Structural Characteristics / Component Functionality / Business Rules/ Component Role in Use	Abstraction Hierarchy / Component Role in Use	The Use of Component
[Inoue2005]	Graph-based / Text-based	Component Association	Component Ranking / Content-based Similarity	Content-based Keyword

It amazed me that the graph-based approach had been applied since 1992, although the approach in [Ostertag1992] was far from similar with recent researches.Most of them are functionality-based classification, only very few associated with non-funcitionall qualities. The knowledge-based approach seems to be an interesting direction based on these previous influential functionality-based approaches.

References

1. [Seacord1998] R. C. Seacord, S. A. Hissam, and K. C. Wallnau, "Agora : A Search Engine for Software Components," IEEE Internet Computing, vol.6, no.2, pp.62-70, 1998
2. [Chatzigeorgiou2003] A. Chatzigeorgiou, "Mathematical Assessment of Object-Oriented Design Quality," IEEE Transactions on Software Engineering, vol.29, No.11, pp.1050-1053, Nov. 2003
3. [Plasil2002] F. Plasil and S. Visnovsky, "Behavior Protocols for Software Components," IEEE Transactions on Software Engineering, vol.28, No.11, pp.1056-1076, Nov. 2002
4. [Inverardi2000] P. Inverardi, A. L. Wolf, and D. Yankelevich, "Static Checking of System Behaviors Using Derived Component Assumptions," ACM Transactions on Software Engineering and Methodology, vol.9, no.3, pp.239-272, July 2000
5. [Zaremski1997] A. M. Zaremski and J. M. Wing, "Specification Matching of Software Components," ACM Transactions on Software Engineering and Methodology, vol.6, no.4, pp.333-369, Oct. 1997
6. [Zaremski1995] A. M. Zaremski and J. M. Wing, "Signature Matching: A Tool for Using Software Libraries," ACM Transactions on Software Engineering and Methodology, vol.4, no.2, pp.146-170, April 1995
7. [Mili1997] R. Mili, A. Mili, and R. T. Mittermeir, "Storing and Retrieving Software Components: A Refinement Based System," IEEE Transactions on Software Engineering, vol.23, No.7, pp.445-460, July 1997
8. [Inoue2005] K. Inoue, R. Yokomori, T. Yamamoto, M. Matsushita, and S. Kusumoto, "Ranking Significance of Software Components based on Use Relations," IEEE Transactions on Software Engineering, vol.31, No.3, pp.213-225, March 2005
9. [Damiani1999] E. Damiani, M. G. Fugini, and C. Bellettini, "Corrigenda: A Hierarchy-Aware Approach to Faceted Classification of Object-Oriented Components," ACM Transactions on Software Engineering and Methodology, vol.8, no.4, pp.425-472, Oct. 1999
10. [Ostertag1992] E. Ostertag, J. Hendler, R. P. Díaz, and C. Braun, "Computing Similarity in a Reuse Library System: An AI-Based Approach," ACM Transactions on Software Engineering and Methodology, vol.1, no.3, pp.205-228, July 1992
11. [Henninger1997] S. Henninger, "An Evolutionary Approach to Constructing Effective Software Reuse Repository," ACM Transactions on Software Engineering and Methodology, vol.6, no.2, pp.111-140, April 1997
12. [Frakes1994] W. B. Frakes and T. P. Pole, "An Empirical Study of Representation Models for Reusable Software Components," IEEE Transactions on Software Engineering, vol.20, no.8, pp.617-630, August 1994
13. [Vitharana2003] P. Vitharana, F. M. Zahedi, and H. Jain, "Knowledge-Based Repository Scheme for Storing and Retrieving Business Components: A Theoretical Design and Empirical Analysis," IEEE Transactions on Software Engineering, vol.29, no.7, pp.649-664, July 2003
    
    
    

之前在觀看 局內人(Inside Man, 2006) 時, 腦子其實在想, Russell 真正的目標其實是 Plummer 那見不得人的過去之秘密, 因此對他來說, 比起容易引起追蹤的銀行鈔票, 他要的是容易攜帶, 容易隱藏的秘密資訊.

資訊這種東西與實體財產最大的差別在於, 他沒有實體, 因此可大可小, 但是大小通常與其價值相關性不高, 然後可以作為價值載體的 media 很多. 在各企業機密越來越多, 資訊科技越來越發達的情況下, 不知道以後會不會出現 Information Robbery 或是 Information Kidnapping 的情況. 也就是被鎖定的目標不會直接是有價值的實體物, 而是利用盜取關鍵的機密資訊, 換取有價值的東西, 也可能是資訊交易資訊.

這種 Robbery / Kidnapping 就不受距離的限制, 同時犯人要隱藏身份變的比較容易, 甚而分散式的 Robbery 是可能的. 現實生活中應該看不到三四隊搶匪進同一下銀行的 case 吧 ? 但是 Information Robbery 就有可能, 因此整體安全防守上的難度其實相當高, 特別是往後的世界中, 透過 network 的可能漏洞只會越來越多.

看來人類變成大頭外星人的可能性越來越高了, 就連基本的搶人都要靠頭腦而不是身體了 XD

百加資通是一家專門作 Open Source 導入的公司, 旗下除了自身軟體產品之外, 還有三個主要的網站 : 開放原始碼動畫教學, 開放原始碼教育訓練, 以及開放原始碼顧問服務. 不過看起來都是 non-free 的.

雖然不知道他們的營收跟實際服務怎樣, 但是我覺得這公司是站在正確的位置上作 Open Source 跟 Customer 的媒介. 特別是製作動畫教學這一項目, 是很有意思的想法. 如果我們把一部教學動畫當作一個 software, 每當 open source software 有新的 stable release 時, 或許就需要對動畫作修改, 此時其實就是對於 software 的 maintenance. 從這個角度來看, 其實百加資通賣的也是 software, 只是他們把如何使用 open source software 的過程 ( know-how ) , 變成了 commercial software 來賣錢.

不知道賺到的錢有沒有回饋各 OSS project ?

不過這個模式感覺很容易被 copy, 因為 copy 難度並不高, 學習 open source software 的難度也不高, 如果這個方向真的可以有很大的 profit 的話, 這種公司會不會變多呢 ? 到時候是不是會反變成服務與低價之戰呢 ?

我想這種公司如果要有很難被 copy 的企業機密部分, 應該要朝著如何結合適當的 open source softwares 成為 stable working space 作努力. 這樣一來, open source softwares 的 combination 方式就會是屬於公司自身的企業機密. 當然, 這還要做到 combine 後的 solution 在 release 給 customer 時, 要避免曝光 combination, 並不是件容易的事. 同時目前好像也還沒有看到對於有效率整合 open source softwares 成為 stable working space 的 paper 出現, 還是說已經有公司藏起來偷偷在賺了呢 XD

剛剛看到一個不錯的 CFP 資訊分享網站 : http://call4paper.info/ , 作者似乎是大同資工所的博士班學生 ( 不是很確定 ), 雖然說現在上面的 CFP 資訊還有點少, 跟我的 domain 直接相關也少, 不過它整合 Google Map 等技術, 還是值得參考看看, 或是利用它幫自己整理 conference bookmark list.

我剛剛加了幾個 conference, 沒想到我加完不久下一個就是 CCY 學長 XD


還有些不是很直覺的地方存在 :

1. "Address" 直接寫成 Web Address 或是 URL 是不是比較直覺 ?
   
2. "Final" 指的是舉行日期嗎 ?
3. Tags 的輸入欄位如果可以有像 blogger 上的自動完成, 或是使用者邊輸入會出現既有 tag 的提示, 會方便許多, 不然像我剛剛就要邊輸入邊回去找所有的 tag 列表, 以免創造了同義的 tag
   
4. 另外 search 的結果是怎樣比對出來的呢 ? 是否可以在 search 的 button 旁加一個 help 的連結, 稍作說明 ?
5. 申請的 mail 是否只能用 gmail 之類的 ? 因為我用 lab 的 mail 不被接受, 但是 gmail 我並不常用, 如果有消息通知可能不容易馬上看到
   

如果這個網站繼續發展成 paper writing, submisson, presentation 的心得討論分享網站就更有趣了.

RK Launcher 是一個 Windows Desktop 的美化軟體, 可以產生類似 MacOS 的 Dock bar 效果 :

Google 上隨便找應該都有很多介紹文章, 不過好像都沒有講到說怎樣在 RK Launcher 左邊的 default docklet 上加上多的 item 數量, 大部分的文章都只有說怎樣去找到別人做好的 docklet, 然後拿進來用而已, 而 default docklet 上也沒有選項可以直接新增 item.

結果我自己去看了 RK Launcher 的 configuration, 發現其實要新增很簡單.

1. 先找到 RK Launcher 安裝資料夾裡的 itemlist.conf 檔案, 打開來看, 裡面其實就是每個 item 的設定
2. 先關掉 RK Launcher
   
3. 隨便複製一個 item 到你想要的位置, 向下面就複製一個 FileZilla 的 item 到原來的 FileZilla item 底下, 然後存檔
   

4. 重新開啟 Rk Launcher, 就會看到有兩個 FileZilla 出現

5. 把其中一個利用 右鍵 -> Dock Item Properties 改成你要的程式名稱, 啟動位置, 以及圖示就 ok 了

注意上面的 2. 一定要在 3. 之前先作, 因為 RK Launcher 有一個有點奇怪的設計, 每次 itemlist.conf 裡 default docklet 部分被更新的時間為, 當 RK Launcher 被關閉時, 而不是每當有改變就會更新, 因此如果先作了 3. 才作 2. , 則 RK Launcher 會把目前的運行設定寫回 itemlist.conf , 所以在 3. 所作的更改就會被覆寫而沒有作用了. 因此一定要先作 2. 才能做 3. , 換句話說任何對 itemlist.conf 的更改都需要在 RK Laucher 關閉的時候進行, 不然都會被覆寫過去.

前一陣子由於 Lab. 的一些小計畫要用到, 所以做了一點 Google API 的 survey, 剛好前一篇也提到, 趁機整理一下好了.

1. Google SOPA Search API
• 已停止申請, 但我申請 Google AJAX Search API 時有另外寄過來一份 Google DOAP Search API, 後面說明
  
• 敗了 : maxResults : Number of results desired per query. The maximum value per query is 10. Note: If you do a query that doesn't have many matches, the actual number of results you get may be smaller than what you request.
• SOAP API project is no-active
  
2. Google Ajax Search API
• 取代了之前的 Google SOAP Search API (取代意指不再發展, 而非取消服務)
  
• 
  
3. GSA-JAPI: Java API for interacting with the Google Search Appliance™
• 失敗, Google Search Appliance 是 google 的 product, 屬於企業級應用, 用於在企業內部架設一個 專屬 Google, 包含有專用的硬體, 以及 Access Key, 因此此 API 適用於此情況下, 而無法直接存取 Google, 缺乏 Access Key.
4. Eclipse-GSearch
• 沒試
  
5. PyGoogle
• SF.net 上的最後一次 release 已經是 2004 的事情了, 但是今年的 Google Hacks 3rd edition 還是有介紹這個 tool
• 利用 SOAP 以 XML format 作 data exchange
• 詳細測試參考後面說明
  

Google SOAP API 申請

最初會覺得可以利用 Google API 進行查詢是 task 進行初期, 也就是 11 月中以前的事情, 當初看過 example, Goole SOAP Search API 是以 SOAP 以及 XML 為基礎, 以 Java API 的形式存在, 應該是可以在一般的 Java application 中使用沒有問題.

誰知道 2006-12-05, Google 發表了 Google AJAX Search API, 用來取代 Google SOAP Search API. 現在申請 Google SOAP Search API usage key 的網頁好像已經被移除了(至少我沒找到), 只留下 documents. 問題是, Google AJAX Search API 雖然對於 Web Application Development 感覺比較方便, 但是對於取得的 searching result 要丟給其他 langauge, 例如 Java 作進一步處理卻相對麻煩, 光想到 build 一般的 application 要怎樣使用這 AJAX Search API 就頭大.

後來想說申請 Google AJAX Search API 的 license key 來試試看, 卻忘了我的 Google account 密碼, 因此申請回復(10:47 收到相關信件並回復成功), 再取得 AJAX Search API 的 license key 之後(大約是 10:50), 收到一封 Google 來的信, 說是為了方便重新把之前申請過的 Google SOAP Search API license key 再寄一次給我(大約是 11:48). 看起來好像很正常, 我卻覺得很恐怖, 是因為我申請了 AJAX 所以把 SOAP 的也重新寄給我嗎 ? 為什麼會這樣作 ? 我又沒有說我忘了 SOAP 的. 而且為什麼是隔了一個小時才寄, 而不是在申請 AJAX 成功後就寄 ?

雖然說是可以解釋為, Google 有建立這之間的關聯, 有申請 AJAX 的人都會被比對是否有申請過 SOAP, 有的話就重寄, 而檢查是每隔一小時批次處理. 但是我還是不禁會想, 是如上述的正常原因, 或者是因為, 我在這一小時內, 看了 Google SOAP Search API 的 forum 內有人對於 AJAX API 取代 SOAP API 的質疑 reply 內容好幾次, 加上我利用 Google 不斷地在搜尋 SOAP API 與 AJAX API 的關係 ? 如果是後者就太恐怖了 = =


PyGoogle 測試

這個可以用, 出來結果基本上就是 Google Search API Code Examples 裡面的結果, 應該也跟直接用 SOAP API 是差不多的, 只是數字"有點"不準. (Search Date: 2006-12-09)

Term	PyGoogle	FireFox-Google	precision
python	5,100,000	77,700,000	terrible
java	262,000,000	310,000,000	acceptable
UML	1,450,000	22,700,000	terrible
Software Quality	23,600,000	627,000,000	terrible
Chin-Feng Chen	4060	58,500	terrible

不過不知道查詢的細部設定是否有所不同.

Alexa Search 是一個也蠻多人使用的 Search Engine, 在台灣感覺名氣沒有 Google 大, 但是台灣雖然是高度資訊化社會, 但是資訊更新度很低, 除非媒體有大幅報導, 或是學生間開始流傳使用, 否則沒人在用也是正常的.

Alexa Search 基本上也是 keyword-based search, search once mode, 跟大部分 search engine 一樣是以 list 的方式呈現結果, 不過他在每一個結果左側會出現網頁首頁的縮圖, 我覺得這蠻特別的. 不過處理繁體中文部分好像不是做的很完善.


右側有 related search, 也蠻方便的.

另外他左側的 Developer's Corner 似乎提供了不少功能跟 services, 對這個很有興趣, 改天應該來利用一下. 之前想利用 Google 作 search, 但是由於 Google 取消了 SOAP API 支援, 改為 Ajax API, 要直接在 non-Web-based programming 使用變的不容易. (SOAP API 還可使用, 但是查到的結果會不準確, 懷疑是去找舊的 data repository). 如果 Alexa Search 的可以用就好了.


有些 Blog Supply Site 已經朝著 connection blogs, blog community 方向移動了, 我想 search engine 應該也快了吧. 如何形成 website community, 以及快速拉近 people 與 website community 之間的距離, 應該會是新一代 search engine 的重要能力之一.

PyDev 是一個可以用來做 Python 以及 Jython programming 的 Eclipse-based Plugin. 之前有試用過(還不到 1.0 版的時候), 當時還很陽春, 但已經算是好用了. 昨天猛然發現已經到 1.2.9 版了, 而且在 1.2.8 版就加入了 code-completion, auto-edit, 以及 refactoring 的功能. 對於我來說這三個都還蠻重要的, 可以很有效地加速開發. 不過我很好奇他的 code-completion 是怎做到的, 畢竟 Python 不同於 Java, 要在 programming 時很快地推論出 type 似乎不是很容易的事情. 可能是在做 programming 時, PyDev 在背後不斷地進行 interpretation, 保留 code information 吧, 之前稍微嘗試寫過 Eclipse Plugin, 大概知道怎樣做到.

試了一下, build-in string 的 code-completion :

撰寫新的 class 時也會自動補上 self argument :

自己撰寫的 class 也馬上就會在 code-completion 的支援裡了 :

上面是我稍微試了的結果, 其它更多能力可以參考 PyDev 的 ScreenShot, 以及 Release Log

這幾天花了點時間寫了兩支程式, 作為實驗室內部失敗 task 的小小結案用, 至少還留下一點有趣的東西. 其中一支是會自動以某個 author 為中心 (root author), 到 DBLP, 依據該 root author 的 co-authors 往外延伸抓取 authors 的資料, 以 papers 為主, 會自動遞迴式 ( recursively ) 地進行分析, 換句話說, 會從 root author 到 co-author, 再從 co-author 到 co-author 的 co-author 一直抓下去, 直到形成一個 closure.

很令人驚訝地, 我以 G. C. Murphy 為中心, 居然抓了超過 48 hours 無法得到一個 closure (其中每一個 author page 隔一秒才抓, 避免我的 IP 被 DBLP 給 ban 了), 最後等不完就停掉了, 結果得到超過 20000 個 authors 的資料 XD ( 附帶一提, 中間很無聊地順便抓了所有的 author URLs, 發現 DBLP 到 2007/01/27 為止, 共有 50 萬多的 authors )

資料是利用 SQLite 存起來, 再用 NetworkX 作 visualization, 最後畫了一個比較簡單的圖做實驗. 綠色圓的大小是每個 author 自己的 paper 數量, 黃色的寬度是合作的 paper 數量, 黑色的線就只是表示有合作關係而已. 因為對 NetworkX 還不是很熟析, 所以不知道怎樣把點弄的分布均勻點, 直接改 nodes position 太麻煩了, 應該可以用特定的 layout library 處理.

NetworkX 花了我很多時間, 主要是他 project 內的 pygraphviz 的安裝, 在 Windows 上有很大的問題, 不過後來發現其實 pygraphviz 不一定會用到, 只是少了它很多 library 都不能用就是了. pygraphviz 的安裝需要 compile 它的一個 python extension, 但是因為我用 python 2.4.3, 是用 VC++ 7.1 (VS.net 2003) 去 compile 的, 因此需要準備 VC++ 7.1, 這就已經很麻煩了(因為 MS 現在不提供下載了, VC++ express 2005 在此不能取代使用), 加上即便有 VC++ 7.1 後, Graphviz 的 agraph.lib 還是會出現 symbols 找不到的情況, 在 NetworkX 的論壇上也是有人有一樣的問題, 但是無解. 我在猜想可能跟編譯 Graphviz 的 VC++ 版本有關, 所以或許在 Windows 上用 VC++ 7.1 重新編譯 Graphviz 可以解決此問題, 不過因為我已花了超過三個小時在此問題, 同時後來發現其實不用 pygraphviz 也大略可以達到我想要的效果, 所以就不管這問題了. 對於還是想 try 的人, 建議不要了, 改用 linux 比較實際.

除去以上的麻煩不談, NetworkX 還蠻好用的, 但是他把 node 的 position 與 node 分開管理的作法讓我有點不解, 雖然說利用 dictionary key 可以輕鬆取得 mapping, 但是把 position 作為 node 的 data 讓 node 管理不是比較直覺嗎 ? 恩...持續使用後再看看是怎麼一回事吧.

在 SourceForge.net 上看到的 software (official site), 還蠻容易用的, 可輸出不錯的 ascii 轉圖, 可惜彩色部份只支援 XHTML 輸出, 看 developer 的 id 感覺是 UK 的, 沒有為 BBS ascii 著想也是正常 :p , 不過 vt100 的 terminal 應該都支援 coloring 顯示, 還是他的目的就是只有給 web 用的 ?

找了幾張圖試了一下, 感覺還不錯. 不過就跟其他的 ascii tool 一樣, 近看還是會有差, 要在小範圍內顯示高解析度, 實在還是會受限於可用的字元數太少, 某些圖不可能直譯就會清楚, 自動化的 tool 還是難以取代手工的 BBS ascii art.