How Matplotlib and NetworkX Work Together : A Case Study on Figure Instances
最初是因為以下的 Code 讓我對這個問題有興趣. 這段簡單的程式碼 Matplotlib 以及 NetworkX 來合作畫圖. 其中 NetworkX 負責 Graph Model 的建立, 而 Matplotlib 則負責 Figure 繪圖的部份.
最後繪出的圖, 如同程式碼所指定的位置, 畫出三個圓點.
而我覺得程式碼有趣的地方在於, 細看程式碼, matplotlib.pyplot 只有在 line 6, 以及 line 20 被使用, 期間 line 9 到 line 18 都是 networkx 的運作.
而, 在此 Script 中, networkx 跟 matplotlib.pyplot 表面上是沒有任何互動的, 沒有任何 Message Passing 或是 Object Communication 出現. 如果單單依照此 Script 中的 Program Logic 作 Program Slicing, 或許就會被乾脆地切成兩個 Program Slices 了.
不過想當然爾, 既然最後可以順利地畫出圖來, 這兩部份的程式碼肯定在背後有進行某種 Communication, 否則不可能在 networkx 中建好 Graph Model, 在 matplotlib.pyplot 中就知道要畫出甚麼樣的 Figure.
經過漫長的 Code Tracing, 大致上可以把 Dependency Graph 整理如下圖 :
其中比較關鍵的是 Matplotlib 在 Figure Management 上, 允許同時間有數個 Figure Instances 存在, 而目前要畫在哪個 Figure Instance 上, 則視乎目前哪個 Figure 被設定為 Activated.
在 plt.figure() 中 ( 事實上為 matplotlib.pyplot.figure() ), 可以透過參數 num ( 可參考 Online Document, 即 Figure Instance Identity ) 指定要 activate 那一個 Figure Instance, 如果 Instance 不存在, 則會產生一個新的 Instance.
而在綠色的流程中 ( 即程式碼 line 9 到 line 18 ), networkx 在 nx.draw_networkx_nodes 進行中會透過 matplotlib.pylab.gca 取得目前為 Activated 的 Figure Instance 其 ax object ( 座標軸物件 ), 之後透過 ax 把要畫出來的 nodes 加進去.
最後 plt.show() 透過 matplotlib.backend_gtk 把圖畫出來.
這 Matplotlib 中的 Figure Instance 取用機制大體上是為什麼原本的 Code Script 中, 在乍看之下 networkx 跟 matplotlib.pyplot 沒有 Communication, 但是還是可以把圖畫出來的主要原因.
中央氣象局什時會整合 Google Earth ?
颱風夜寫這篇真是應景阿 ^^
長久以來中央氣象局都只有提供俯瞰的衛星雲圖, 但是 Abstraction Level 太高, 也沒辦法任意變更 Granularity, 說穿了只是往往在颱風來時, 只是看到台灣整個被淹沒而已, 沒辦法調整 Granularity 來看自己居住地區的最近幾小時情況. 雖然也有提供即時影像, 但是一來都是定點, 同時一下子又把視野調到太小, 參考度其實也不高.
我相信中央氣象局手上握有的資料一定比利用衛星雲圖給一般民眾看到的更多, 只是受限於經費以及技術限制, 沒辦法在網頁上提供更先進, 更詳細且好用的 Visualization 介面給訪客.
既然如此, 是否中央氣象局應該考慮採用整合既有的技術, 例如 Google Earth, 作為平台, 附加屬於中央氣象局的有用資訊呢 ?
目前 Google Earth 已經可以讓使用者即時觀察颱風以及颶風等天氣狀態, 並且上面可以看到許多有用的天氣資訊, 如果中央氣象局可以讓資訊部門成立一個小組負責把中文化的資訊整合上去, 我相信只有初期會花比較多心力, 之後就會很輕鬆.
甚至當 Google Earth 的 3D 化成熟之後, 將可以進一步把颱風的面貌用 3D 的圖像顯示, 這樣應該有助於一般民眾對於颱風強度以及危害的認識與警覺性, 而不是僅透過一些聽不懂的數據去了解颱風. ( 以下圖片引用自 Google Earth Community )
 |  |
Tool Support for the Navigation in Graphical Models
這篇 Short Paper [1] 以及所建立的 Tool ADORA, 包含重點大致可以歸納為兩點.
首先是使用 Fisheye View 的概念改進目前大部分 Tools 在協助使用者瀏覽整張 Software Design Diagram 時的問題. 既有的 Tool 在面對相當複雜且巨大的 Diagram 時大多無能為力, 往往需要使用者自行將 Design Diagram 從 Object Analysis ( 如果是在 OO Paradigm 中 ) 以後, 分為 Class Level 0, Class Level 1, ...... 等詳細程度不同的數張 Design Diagrams, 方便在不同的 Abstraction Level 間切換. 少部份 Tools 可以自動隱藏 Details, 但是當進行 Zoom In / Zoom Out 時卻是會對於整張圖作變化, 無法自由地只 Zoom In 想要進一步觀察的部份. Fisheye View 則讓此操作方式成為可能. ( 以下 ADORA 圖片皆取用自 [1] 並稍加編輯, 且無修改圖片本身內容 )
關於第一點在去年底我們實驗室有一位同仁在進行實驗室會議報告 Paper 時也有提到類似的概念, 當時他是用 StarCraft 當作例子, 在 StarCraft 中同時有主操作畫面 ( Local ), 以及左下方的微縮地圖全圖 ( Global ), 來說明如果 Design Tool 有類似的支援好像不錯. 當時大家討論都集中在使用方式上, 看了 [1] 的實做, 好像在 Layout 計算位置上也不是那麼容易實現, 畢竟要兼顧到整張圖的 Re-arrangement, 不能因為 Fisheye 使得整張圖亂掉. 我想這也是 [1] 裡面要強調可恢復性 (Stability) 的原因. ( 以下 StarCraft 插圖引用自 http://spyhunter007.com/game_over.htm )
第二是對於 Single Integrated Model 的理想. 在 Paper 尾段嘗試性的把不同時間點的一些 Diagrams 疊合在一起, 包含 User & Context, Use Case Diagram, 以及 Class Diagram. 可以想見的, 這樣一來就可以透過 ADORA, 在 Software Development Phases 之間快速自由的移動, 瀏覽相關的 Analysis Diagrams, Design Diagrams.
不過我認為 Single Integrated Model 的需求, 使用時機及模式, 以及呈現方式都還有很多探討的空間, 在本篇 Paper 中也沒有再著墨太多. 像是上圖左, Use Cases 跟 Classes / Components 混在一起的感覺就很奇怪, 也沒有因此曝露更多 Information. 如果改用 Use Case Map [2] 來作整理可能會好點. ( 話說 Use Case Map 是怎樣, 不紅到原本的介紹網頁都消失了, 現在只依附在 jUCMNav 底下了 XD )
或許之後在 Software Design Tools 中會出現更多這種 Visualization Information Mash-Up 的應用.
References
[1] T. Reinhard, S. Meier, R. Stoiber, C. Cramer, and M. Glinz, "Tool Support for the Navigation in Graphical Models," Proceedings of the International Conference on Software Engineering, pp.823-826, 2008
[2] R. J. A. Buhr and R. S. Casselman, Use Case Maps for Object-Oriented Systems, Prentice-Hall, 1995
My Activity, My Life Calendar, My Swurl: Operating the Lifestream
跟隨著 RWW 文章 Swurl: Your Lifestream, Made Beautiful 的腳步去試用了Swurl -- another Lifestreaming Service.
基本功能上其實沒有甚麼好說的, 跟 FriendFeed-like 的 Services 雷同, 甚至可以說現階段功能上不如 FriendFeed 來的好. 但是我喜歡他的 Visualization, 雖然概念簡單, 但是很強大.
Swurl 並非像 FriendFeed 一樣只是把蒐集來的資訊依新舊排列, 而是再多提供了一個類似 Calendar 的整理方式, 以時間軸, 只紀錄有活動天數, 形成一個 Life Calendar Matrix. ( 以下借用 RWW 文章的圖, 我的只有文字不太好看 :p )
Visualization 的目的一般是為了把 Invisible Information 變成 Visible.
在 Swurl 的 Life Calendar 上, 提供了一個介於統計式每日每週文章照片數量, 到 Blog 式落落長文章串之間, 折衷的摘要總覽介面. 輔以 Calendar 的 Metaphor, 我們會很自然地把相近日期的事件連結起來, 於是過去一天, 一週, 一月, 一年, 很快地就可以在你的腦海中流逝而過. 在每天每天每週每週 Blog 文章跟照片, 多媒體資料之間, 其實我們都遺漏 / 篩選掉了很多細節, 心情的轉換...... 這些東西我們沒辦法, 也不可能一一記錄下來, 但是透過 Life Calendar, 就像整理舊相簿一樣, 時間可以在手上流過, 本來一點一點的文章照片, 就可以銜接變成一整串記憶之流.
我想 Swurl, 以及他的相似 / 後繼者,會逐漸揭露一個方向 : 把Lifestream 的焦點從紀錄, 開始轉移到操作上. 就像編輯家庭錄影帶, 透過不同的操作, 我們可以再次提供不同的觀點, 不同的交集, 不同的思考, 以及不同的懷念 -- 為什麼我又會想到羅賓威廉斯的迴光報告 ( The Final Cut, 2004 ) 呢 ?
btw, My Swurl : http://selain.swurl.com/
WebST : visualizing the Website STructure
WebST 是一個會根據你給定的 webpage 自動進行連結頁面 retrieval, 建立 star structure visualization 的 Java-based tool, 但很可惜地在 1.0 出現之後就沒有繼續發展了. 前一陣子有在 SourceForge.net 上作過 survey, 好像這類的 open source tools 並不多, 或是可能因為我不知道該用什麼關鍵字去找的關係 ?
WebST 執行的方式很簡單, 就是一般的 .jar 執行方式. 首先會出現輸入目標網頁的對話視窗, 但是這裡要注意前面不用加 http:// , 另外結尾要指定特定的網頁, 例如 index.htm , 而不能夠只有網域名稱. 舉例來說要看成大電機中文網站的結構, 要輸入 www.ee.ncku.edu.tw/chinese/index.htm , 而不能夠只輸入 www.ee.ncku.edu.tw/
輸入後就會進入主視窗. WebST 的 retrieval 動作還蠻快的, 這可能跟他不是一次抓完整個網站有關. 主視窗左邊是網頁預覽, 右邊是 star structure visualization. 上方有幾個不同的選項可以調整. 底下說明的 nodes, edges, radius 都是 Graph Theory 內的東西, 當然 Google 上很容易找到 definition.
- Show E# : 除了目前所選擇為 focus 的網頁 node 之外, 其他具有大於 E# 個 edges 的 nodes 不會呈現出來
- Expand E# : 除了目前所選擇為 focus 的網頁 node 之外, 其他具有大於 E# 個 edges 的 nodes 不會被展開
- Radius : 目前所選擇為 focus 的網頁在 radius 個 edges 內, 所以可連結到的所有頁面 nodes 都會被呈現出來. 簡單地說, 從目前 focus 的網頁出發, 經過 radius 次的網頁超連結切換, 所可以到達的網頁都會被列出來到 star structure visualization 中.
- Show BlackLinks : 把與目前選擇為 focus 的網頁之間有 backlink 關係 (其他網頁連結回目前的選擇網頁) 的網頁列出, 但是我有點懷疑這個功能有點小 bug.
- Zoom : 調整視野大小, 達到放大縮小的功能
可以看到上面的圖雖然跑出來了, 但是似乎不太正確, 成大電機系網站不會只有這兩個頁面吧, 就算再調其他參數也是一樣的結果.這是因為 WebST 的 MyParserCallback class 只有對 Frame Tag 作處理, 而電機系網頁用了 Map Tag 而非 Frame Tag 去連結其他頁面, 因此 WebST 就無法解讀相關的 links. 同時對於 links 的路徑判斷很單純, 沒有考慮原始網頁開發人員將絕對及相對路徑混用的情況.
剛好 WebST 有把 source 提供, 因此我就去作了一點 hacking, 讓 WebST 可以處理 Map Tag, 同時可以在一開始指定要 retrieval 的 level 深度. 我改過的 WebST 可以在這裡下載 (要處理 Map Tag 才需要, 正常的網站應該是可以用原版的就好). 除了 MyParserCallback class 之外其實還要改其他地方, 有興趣的人就自己利用 decompiler 比較差異摟.
執行的方式相同, 只是一開始輸入的除了網頁 URL 之外, 還多了 level 的指定. 同時就這樣就可以正常地看到成大電機系中文網頁的星狀結構了.
雖然說 WebST 的介面設計實在有點陽春, 同時功能也只有 visualization, 不過因為我還蠻喜歡串聯小 tool 使用的, 同時 free software 中也找不到相似的 tools 了 (另外一個類似的 WebLoupe 對於過大網站的 visualization 會有問題), 所以基本上 WebST 還是算堪用. 再不然就需要自己 parse 再接 graph library 了, 這樣可用的 library 倒是很多.不負責任的推測, WebST 應該是大學生的修課作業之類的. 因為在 WebST 網站上有一個 Business Plan 的 pdf 檔案, 雖然內容看不懂, 但是有點像是大學部或研究所的 project document, 加上 WebST 本身也像是一個 project 作業, 然後完成後就沒有繼續 maintain 了, 一整個很像是課程 final project ^^b
Thumbnailing the Design
About a month ago, I found that several refactoring patterns are expressed with thumbnails [1]. The following figure is Evolving to the Strategy Pattern thumbnail, expressed by several refactoring thumbnails, referred from [1].
And yesterday, when I was checking the differences between JUnit 3.x and JUnit 4.x, I found it again in the document of JUnit 4.x [2] release. The following figure is referred from JUnit 4.x document.
This figure contains rich information, and clearly shows the global picture of how and the order design patterns were composed in the design of JUnit 4.x, without revealing the details.
I myself usually do the similar thing when sketching the initial design idea, however there is no patterns or fixed forms of my sketch. The lack of regulation in the sketches makes the design granularity and leveling hard to control.
It would be wonderful if there exists a design tool that can hold the design granularity and leveling control for me...maybe by the design thumbnailing support ?
References
[1] Refactoring Thumbnails, URL : http://refactoring.be/thumbnails.html
[2] JUnit, URL : http://www.junit.org/
Author Net based on DBLP and NetworkX
這幾天花了點時間寫了兩支程式, 作為實驗室內部失敗 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 管理不是比較直覺嗎 ? 恩...持續使用後再看看是怎麼一回事吧.