Software Cinema

我必須承認, 儘管之前略聞 OLPC 帶來的爭議, 在今天看到這篇 One Laptop Per Child Foundation No Longer a Disruptive Force 之前, 我沒有好好想過 OLPC 本身可能的負面影響.

Walter Bender : I would challenge that as being the critical dependency. I think doing it was critical, because it’s not real until you do it. We’ve demonstrated that this can be done. We’ve gotten the world to be interested in doing it. Now we have to let more people participate in the doing and not try to control it and own it.

在此篇文章中訪問了 Walter Bender, 前 OLPC 軟體與內容管理主要決策者, 提到他所離開 OLPC 開發的一些主要原因, 包含與其他人對於 OLPC 未來方向的意見不合, 以及他的擔憂. 不過這當然是一方之詞, 姑且聽聽即可. 重要的是在這篇文章說提到許多 OLPC 可能帶來的強迫性文化衝擊, 特別是在文章的後半段.

如果以造成的影響來計量, OLPC 硬體本身鄉對於軟體以及內容來說其實是很小的. 然而誰會是軟體以及內容的主要供應商 ? 此供應商將有機會直接面對世界的未來 -- 小孩子們. 你說內容可以透過成立公正的第三方教育審核進行檢驗, 但是有些東西是你無法塞檢的. 比方說 Operating System & Desktop System. 這就好比我們提供給小孩子的文化基礎教育, 有些東西一旦根深, 就很難拔除.

OLPC 究竟會帶來自由, 還是帶走自由 ? 這將是需要被深思的問題.

在癮科技看到的秤重湯匙, 理所當然是一個 Embedded System. 不過不知道它如何解決清洗的問題. 其他像是 Wearable Devices, 或是內建播放器的衣服之類的, 也是會面臨怎樣清洗的問題....... 不過這跟 Software 關係就不大了....... 吧 ?


倒是, 要不要也作個碗, 上面會顯示碗內東西的預估熱量, 營養成份表呢 ? 像是國內外都有學者在研發的電子餐盤之類的, 可以比較準確的控制自己的飲食. 然後廚房裡的東西大大小小都給他 Embedded System 一下, 以後什麼東西都沒辦法偷吃了, 電影裡胖女孩晚上偷偷下樓吃火腿的橋段也將不復存在了 = =

未來我們的生活跟文化會怎樣真是難以想像阿. 最近的日劇潘朵拉, 男主角在發明了完全抗癌藥物後, 他的老師第一個就跟他說, 東西不是發明了就急著詔告世人, 要想想他對於整個世界未來的影響, 跟這是一模一樣的阿.

查到兩個作法, 第一個是直接把 Analytics Code 嵌入的作法, 底下以新版的 Google Analytics 嵌入碼為例 (注意嵌入程式碼是用前後各三個雙引號包起來), 把嵌入程式碼指定給 page_footer2 這個變數 :

<br /># Google Analytics<br /> page_footer2 = """<script type="text/javascript"><br /> var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");<br /> document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));<br /> </script><br /> <script type="text/javascript"><br /> var pageTracker = _gat._getTracker("UA-XXXXXXX-X");<br /> pageTracker._initData();<br /> pageTracker._trackPageview();<br /> </script>"""<br />
把以上的 code 寫在 wikiconfig.py 內即可. 當然需要重新跑 moin.py

page_footer2 是頁面 Theme 調整可以使用的變數值, 其他可以使用的變數值可以在 HelpOnConfiguration 看到相關的說明.

另外一個作法是直接利用 MoinMoin 內建的 Google Analytics 支援, 這個比較簡單, 只要直接在 wikiconfig,py 中寫下你的 Google Analytics code numbers (連結內請搜尋 Google Analytics, 約在頁面 3/4 的地方) 就好 :

<br />google_analytics_account_number = u'1234-5'<br />
MoinMoin 會接手其他部份的 Google Analytics 程式碼產生. 不過新舊版就要看你的 MoinMoin 版本而定.

因為想投, 所以想說找之前的會議論文看看寫作風格是否適合, 沒想到 ICSOC 的論文電子檔實在有點難找, 自 2003 年以來的論文, 除了 2004 以外, 都在 SpringerLink 上提供下載, 但是成大圖書館似乎只有買了 SpringerLink 的 Journal Paper 下載權利, 對於 Proceedings 好像沒買 ( 去函詢問中 ), 所以抓不到. 好在 2004 年的在 ACM 上有發佈, 至少有一年的可以看看. 不過話說回來為什麼只有 2004 的在 ACM 上發佈 ?

• ICSOC 2003 , papers,
  
• ICSOC 2004 , papers, accept rate 20%~22%
  
• ICSOC 2005 , papers,
  
• ICSOC 2006 , papers, accept rate 15%~17%
  
• ICSOC 2007 ( CMU 移掉了) , papers, accept rate 18%
• ICSOC 2008 , papers

沒辦法看的 Papers 可以嘗試在 Google 上用 +"paper title" +pdf 作搜尋, 有些作者會把初稿版本或是未排版版本放在網頁上, 就可以看得到全文, 內容通常不會差太多.

上面的 Accept Rate 都是在 Google 上找的, 有的數據有點差異, 可能是算法的問題, 所以就當作一個區間吧. 重點是第二屆之後看得出來 Accept Rate 都壓在 20% 以下, 雖然不及 CS 領域的一些頂級期刊 ( 10% ~ 15% ), 但是以 Accept Rate 來看也不算是隨便可以上得了. 即便如此, 還是要挑戰看看 :)

瀏覽過 2004 全部加上抽樣調查 2005~2007 的 Papers, ICSOC 的 Papers 不偏好注重大量的數據, 足夠證明想法跟理論即可. 講述 Architecture, Design, 以及 Modeling 的文章居多, 其他 Requirement 方面, 以及 Service Adoption 相關議題, 如 Licenses 等等次之. 基本上還是以說明清楚架構, 以及提供適切的 Case Study 以資驗證為主.

最近開始改用短小的 TexMaker 取代 Kile 作為我主要的 LaTex 編輯工具. Kile 的介面實在太雜了, 以我使用特殊語法跟符號的頻率來說, 還是介面簡潔的 TexMaker 比較適合.

不過剛剛才發現在 Mandriva 2008 下, 利用 Package Manager 裝的 TexMaker, 其 Spelling Check ( 使用 Aspell ) 預設居然是採用 zh 語系, 所以用英文寫 paper 時怎樣檢查都不會發現拼字錯誤. 無怪乎我上一篇 research proposal 打完居然都沒發現錯字, 還以為自己變神了 ^^b, 高高興興地就寄給 Advisor. ( 慘了下次 Meeting 要被 Advisor 鞭了 )

要把 TexMaker 的 Spelling Check 語系改回到 en 才能夠正確地對於英文拼字作檢查. 下次重設系統千萬要記得 @@

可以把 Staged View 看成是 Level by Level, 每個 Level 含有多個 Process Area, 包含在四個大類別 ( Process Management, Project Management, Engineering, Support ) 中.


同時在各個 Level 之間, 也可以四個類別為導向, 垂直地 ( Vertically ) 串起 Process Area, 也就是 Continuous View.

這篇 paper [1] 主要提供了一個對於目前在 Software Engineering Experiments 中, 對於 Theory 使用的檢討之外, 其用來進行的方法, 同時也提供往後 Software Engineer 進行 Software Engineering Experiments 可以利用來判斷該選用什麼樣的 Theory 的方法.

如下圖所示意, 整體概念為自 Software Engineering Experiments 的範疇內, 定出一個 Factors 集合, 藉由串聯這些 Factors 集合, 對於所有目標的 Papers 作討論與分類, 最終結合將這些 Factors 串聯的方式, 以及利用 Papers 所作的驗證, 得到一個 Theory Use Model.


其中有價值的分為三部分. (1) 此 Process 本身, (2) 對於 Factors 進行串連的方法, 以及 (3) 一個呈現出具體成果的 Factors 集合.

此 Process 本身並非創新的提出, 而是一個 Common 的 Process, 但是這篇成功的 Paper 在討論 Software Engineering Experiments 的 Theory 使用上, 展示了此 Process 的合理使用. 自此可預見此 Process 會是往後相關延伸研究的基本 Process 之一.

對於 Factors 進行串聯的方法我認為是最有價值的部分. 往往我們可以列出許多的 Factors, 但是卻不知道怎樣對於 Factors 作取捨以及相互搭配, 主要原因我認為是所立足的基準點 ( Base ) 認識不清楚所致. 而這篇 paper 在整個過程中, 逐步穩固地解釋選擇 Factors 的合理理由, 同時以兩個軸去分析最重要的 Factors. 兩個軸分別是 (1) 對於 Theory Type 以及 Theory Components 的分析, (2) 對於 Theory Role 的分析, 這兩個軸事實上源自於同樣基準點 : 提供往後 Software Engineer 進行 Software Engineering Experiments 可以利用來判斷該選用什麼樣的 Theory 的方法, 換句話說, 跟如何選擇以及如何使用有很大的關係.

最終的部分, 一個呈現出具體成果的 Factors 集合, 我認為比較算是副產品. 除了可以驗證這樣的進行方式之外, 同時也是站在 Theory 於 Software Engineering Experiments 內, 以偏向 Empirical Study 的角度選擇了 Materials 以及相對的 Factors, 同時隨後進行的討論內容進一步證實了此 Factors 集合可以發揮的作用.

About Paper Writing

在 Paper 撰寫上我認為此篇 Paper 採用較為平鋪直敘的寫法. 首先在 Introduction 就說明問題, 以及本篇 Paper 所謹守的研究範圍. 接著承接研究目的及範圍, 說明上述的兩個主軸. 兩個主軸剛好對應到 Theory 本身的特性分析 ( Theory Type ) , 以及使用上的分析 ( Theory Role ), 因此分析立論一開始的空間感就很充足, 為之後的 Findings 解釋立下很說服人的基礎.

Section 3 說明此次 Review 的 Data 來源, 以及 Extract Data 的方法及原則. Section 4 則反向說明 Findings. 這裡的反向是指, 先從看完第三段後, 讀者可能會比較直覺想到的 Articles 與 Theories 之間的關係說明起, 再往回接到 Theory Roles 以及 Theory Types, Theory Components.我認為這樣寫的好處是不容易有文章閱讀上的斷點產生. 而後 Subsection 4.4, Subsection 4.5 則回歸到對於 Theory 出處以及所列為觀察的 Paper 之 Authors 之間, 對於 Theory 使用的分析, 我認為這邊事實上是回映到 Background 一開始的敘述. 回頭來稍微探討以 Theory 使用的觀點, Software Engineering 是否算是一個 Mature Science. Section 5 就以 Theory Use 為中心, 探討各項 Issues, 但是這邊我還看不出什麼 Regulation, 例如怎樣列出這些 Issues 之類的.

Remained Questions

• Paper 中提到, 對於所觀察的 Papers 選擇是自 1993 到 2002, 是否有特殊的理由 ? 或僅僅是因為 Time 以及 Effort 的考量而作此決定 ? 是否與 Empirical Study 的數量歷年增加比率有關 ?
• 本篇 Paper 本身是否也算是利用了 Role Theory ?
• Figure 1. 中, 左右的順序之意義為何 ?
• Figure 1. 中, Experiment 與 explain 所涵蓋的範圍是一樣嗎 ? 又所涵蓋的範圍應該怎樣解釋其意義. 同時 Theory 所涵蓋的範圍以及意義又是如何 ?
• 最後的 Section 5. Discussion 是否有任何的 Regulation 存在 ? 往後進行相似的 Researches 時, 應該怎樣進行 Discussion ?
  

References

[1] Jo E. Hannay, Dag I.K. Sjøberg, and Tore Dyba°, "A Systematic Review of Theory Use in Software Engineering Experiments," IEEE Transactions on Software Engineering, vol.33, no.2, pp.87-107, Feb. 2007

此篇文章以台大本身所建立的 CEIBA 數位課程管理平台 為例, 藉由使用統計數據, 說明 Learning Management System 在教師使用情況上, 成功關鍵在於系統設計之初, 是否針對校內教師的需求進行設計, 而非系統平台本身的技術性問題.

Before investing time and money to develop technically advanced tools, it is necessary to investigate the needs of the faculty [1].

這在軟體開法方法論中, 其實並不是甚麼新的結論, 但是如果我們以國內的情況來說, 卻很少有學校的管理階層體認到這一點.

在文章中也特別提到 CEIBA 建構團隊針對台大人文相關系所的教師需求, 在 CEIBA 上提供建立多媒體互動教學資料的輔助工具, 使得不懂 PC 操作的人文科系教師也很容易可以利用該系統建立所需要的教學資料. 這點聽起來似乎不簡單, 好像似乎要提供很強大的使用者介面的感覺. 但是我覺得如果真的有實地去蒐集教師的需求, 在 CEIBA 內可能只需要很簡單的功能就可以達成相當好的效果. Software 只是解決問題的 Solutions 其中一種, 而選擇 Software 的理想目的應該是為了使用者省下許多麻煩, 在幾乎不用改變正常工作流程下享受 Software 的好處.

從下圖可以看到, 自 2000 年到 2007 年, 人文相關科系的教師使用情況, 遠比理工科系的來的理想. 除了上述的原因, 可能也跟理工科系的老師習慣自己或請學生準備教學資料, 再放到網路上, 而非使用統一的教學平台有關. 不過文章並沒有針對此一部份進行說明.


另外在文章中也針對 CEIBA 上各項功能在 95 年第二學期的使用情況做了統計. 其中 Interaction 部份的使用情況都偏低, 相對來說 Knowledge 部份則比較高. 可以看出學生還是不習慣使用網路平台進行互動式學習. 這可能也跟台灣學生習慣在講堂上單方面接受來自於教師的知識傳授, 但是較少藉由團體合作進行課程學習有關.

另外我覺得值得一提的, 但是文章中可能因為與重點無關所以沒有說明的是, 看起來 CEIBA 自 1995 開始歷經了數年幾代的發展, 目前是CEIBA 4, 其中自 CEIBA, CEIBA 2, CEIBA 3, 到 CEIBA 4 每一代的發展維護人員幾乎都不相同. 很好奇 CEIBA 本身的 Quality 如何, 畢竟在 1995 到 2000 年, 對於 Web-based System 的 Quality 觀念應該還不成熟, 同時許多功能應該是最近幾年才加上去的. 很想看看是否有 CEIBA 對照 New Features 與 Quality 變化的相對數據圖表.


References

[1] Hsiu-Ping Yueh and Shihkuan Hsu, "Designing A Learning Management System to Support Instruction," Communications of the ACM, vol.51, no.4, pp.59-63, April 2008