論文進度報告(2010/9/26)：進度延後至10/29

9月中meeting時，我跟老師報告了一下系統狀況與現在的進度。當然就如你所知的，系統開發並不是很順利。前端的JavaScript程式完成了估計數量的1/3不到而已，之前說想要在9/21完成的希望，當然也是只能摸摸鼻子地再來重新估算日期。

系統現況與進度報告投影片

這是9/15論文進度報告的投影片(SkyDrive下載)。

前端的View部分，系統目前可以分成六大區塊：Toolkit工具箱、Core核心元件、Window視窗元件、Toolbar工具列、Text標註、Search搜尋。而目前我正在做到Toolbar這一塊，比報告之後又多推了一些進度，但跟上次報告時比起來也不過是多作了7隻程式而已，中間相隔約2個禮拜。

以下是進度的詳細內容：

元件	預估程式數量	已完成	UML類別圖
Toolkit	15	15	1
Core	15	13	1
Window	4	4	1
Toolbar	36	3	2
Text	38+?	0	3
Search	6+?	0	1
統計	114+?	35 (30.7%)	9

專案進度延後，設定10/29作為查核點

系統延後的狀況實在是太嚴重，嚴重到我都快對不起KALS Wiki左上角的倒數計時器。但是正視自己的弱點才能夠前進，所以還是要忍辱地再次調整專案規劃。

如果以兩個禮拜可以增加7隻程式來計算，大概還需要5個月的時間……當然不可能會到這麼久。而且這兩個禮拜中，又是寫書校稿、又是假期回家，所以進度才比慢到這麼誇張。不過都已經9月底的現在，說什麼理由也沒啥意義了。

總之，接下來兩個禮拜應該可以專心在系統上，因此要用這兩個禮拜來預估系統進度，然後設定10/29(五)作為查核點，再給自己一個月，看看情況如何吧。

由於整個進度都往後順延，影響到最後畢業的時程，延遲至3月初。由於我仍欠國中圖一篇論文，所以千萬得在3/24之前完成口試才行。

寫書一校完畢

之前提到的寫書工作，終於完成一校的作業了。

一校作業是由我跟老師分擔負責，我主要是檢查技術部分是否有問題。而不出所料地，我又作了很多修改。讓人有種「校稿怎麼校都校不完」的感覺。後來編輯又來告知說我圖檔dpi不足300，印刷時會讓圖片花掉，讓我又花了好多時間再來重新截圖。儘管現在都做完了，但二校時可能也會再來一次這種大混亂吧。

雖然老師希望該書在9月底能夠出版，但看現在的情況，能在10月底之前出版也許就該偷笑了？

與外國作者討論程式的感想

我在撰寫論文程式時，使用了Max Wheeler的PlaceHeld的外掛，並改進了裡面的一些小bug。這次心血來潮，上github將我的建議寫給作者Max，而他也在數天之後回了我。但他並不知道這樣改的意義，所以我又寫了一些範例回給他，現在在等他的回應。

以往我改了很多人寫的程式(特別是DSpace)，有不少會在這個Blogger中寫出我改過的地方，但卻很少跟原作者交流、互動。我想，如果要成長的話，就一定要積極地與人交流知識才行。光是閉門造車，是很難有所成就的。

嗯，加油！

---

以往我總是將許多主題混在論文進度報告裡面一起寫，讓閒聊的事情與可能比較有教學價值的文章內容混淆。現在我打算把一些具有獨立探討價值的議題從論文進度報告中拆開來，進度報告歸進度報告(還有很多閒聊)、其他議題歸其他議題。也許這樣會對想要一次看完的讀者來說比較辛苦，但我相信將議題獨立探討，應該是更方便讀者找尋資料。

也因此，最近我發了很多篇文章，而談論議題都比較獨立。事實上，也還有好幾篇想寫議題列在待辦事項中，等待我一篇一篇地將他們完成。

(more...)

作為一位實驗室的博士班學長 / As a Lab's Doctoral Student

這篇想要聊一聊作為一位博士生的一些感想，只是隨意寫寫而已，請抱著輕鬆的心態來看就好。

This is a diary about my doctoral student life. Take it easy to read it.

全職的博士生 / A Full-Time Doctoral Student

我在所上是少數的全職博士生之一。

大部分來考博士班的同學都是在職居多，有人在圖書館上班、有人在檔案館上班、有人在學校教書、有更多人忙著照顧家庭。即使跟我一樣一畢業就來考博士班的同學，現在也是一位堂堂國家公務員。

我們所上的另一個特色就是公務員居多，這是從碩士班就有的景象。到了博士班之後，博士班研究生室更是只有上課時才比較見得到有人出沒。大多數時候都是只有全職學生在，之前是一位博士班班花，現在則是由一位文青小帥哥坐鎮（附帶一提，即使是假日如今天，他也依舊鎮守崗位）。

博士班修業時間長，而且單一課程的份量重，通常大家不會修很多門課。現在所上博士班普遍修課學分為6到10之間，也就是一週大概只有兩到三個半天上課。跟高中以前那種週一到週五從早自習修到晚上去補習的課程份量相比，博士班真正待在課堂上的時間並不多，大家其他時間會忙於自身職位的工作，並且抽空準備上課時要報告的內容。

在職學生平常有自己的工作業務，大家大多會覺得在職學生比較忙，而通常都不知道全職學生每天在所上晃來晃去的到底是在幹嘛。雖然每年招生時老師們好像都會為了全職與在職學生的分配爭論一番，但這倒不是我今天想要聊的主題。

在職學生常偶爾會問我平時到底在幹嘛，我想想，雖然沒有一個很亮眼的頭銜，但我覺得我的主要工作之一，叫做「博士班學長」。

今天就來跟大家聊聊我這份工作吧。

Group Meeting與聊天 / Group Meeting and Chat

雖然我是在隸屬文學院的圖書資訊與檔案學研究所，但是我的指導老師陳志銘教授本身則是比較偏向用工科的方式在帶學生。因此陳老師的學生跟其他老師帶學生最大的差異在於，我們每週都有一個Group Meeting (團體會議)。在Meeting中，學生可以定期跟老師報告論文進度、討論研究的問題，而其他學生則是聆聽別人的報告，或是適時跟台上報告的人一起參與討論。

為了配合修課與在職專班學生，我們通常都是在晚上舉行Meeting，每次約三到五位同學上台報告，而討論時間常常超過三個多小時，可說是我們實驗室的一個特色。

這對於一開始進來的學弟妹來說，這種Group Nmeeting其實常常會讓大家感到不知所措。因為台上學長姐跟老師如火如荼地討論著嚴肅的話題，臺下學弟妹則是個個鴨子聽雷。有同學抱怨過這種方式浪費時間，後來放棄而去找其他老師指導，這樣的例子也是有的。

以往meeting時大家為了不要打擾台上報告者，大多是默默地在底下呆呆地聆聽，聽不懂也不知道從何問起。可是對我來說，我反而比較喜歡跟大家在meeting時私下聊天，一邊打屁哈拉，一邊講解台上報告的內容。

一開始的時候我只是私底下跟旁邊的人聊，後來想說乾脆開個聊天室來聊，索性自己架一個，可是架的不太好，乾脆還是在FB開社團來聊。

大多時候不是每個學弟妹都會陪我聊天，不過做研究的問題又來不及跟老師討論時，倒是常常用聊天的方式來問我。弄到最後變得是台上老師在主持報告進度，我在台下忙著回答大家的問題，meeting有時候還蠻手腳慌亂的。

不過，跟大家一起聊天的感覺很不錯，我喜歡有說有聊的實驗室氣氛。

事實上，很多人的研究題目都是在meeting聊天中決定的，我也常常提一些實驗室可能的發展方向，促使學弟妹多多思考未來的研究題目。自己一個人悶頭苦幹，論文也不會憑空而降，我是這樣覺得的。

Group meeting的主持 / Host Group Meeting

剛剛有提到meeting時間長達三個多小時，往往讓學生感到苦不堪言。但裡面最辛苦的人，其實是負責主持的那一位，也就是我們的指導老師。不過在我當上博士生之後，老師有時候會把這工作交到我頭上，自已變成底下聆聽的聽眾，而就輪到我坐在前面主持Group Meeting。

主持meeting跟底下聆聽做的事情不太一樣。主持meeting的工作包括開始meeting的開場、報告實驗室的現況、專心聆聽負責報告學弟妹的報告內容、對於報告內容提出建議、在大家報告完成之後結束會議。

其中比較困難的是對報告內容提出建議的部分。陳老師實驗室成員的組成很多元，有圖資的學生，也有工程的學生。我的領域是在圖資這邊，對於程式寫作很有把握。不過對於工科學弟妹的報告來說，我可以給予的建議有限，特別是這學期有強者學弟在鑽研演算法，一堆公式我看下來也還真沒把握全然理解。

然而大家研究的主題雖然很發散，但終究是在做的是「研究」這件事。因此我通常可以在文獻找尋、讀學術文獻的方法、研究架構設計、實驗設計、論文寫作上提出比較實用的建議。

跟老師主持meeting時不太一樣。學弟妹對於老師的態度大多是直接接受、回去再想，而我只是個比他們大幾屆的學長，大家通常都比較常在我回覆完之後跟我進行一些討論。meeting中我也比較喜歡點人提出一些看法，或是跟台下講解剛剛報告的內容。

不過最終決定論文方向的人仍然是老師，我的角色還是僅止於提供建議而已。因此比較重要的問題最後還是會問台下老師的意見啦XD

MIS Group Meeting

雖然有時候group meeting會輪到我主持，但是我真正比較常主持的meeting則是以研究助理與部分學弟妹為主的MIS Group Meeting。

陳老師常常進行眾多的研究計畫，而研究計畫就會聘請研究助理來執行。研究計畫大多是基於實驗室研究成果的進一步發展，而這些研究成果大多都跟我相關，之前是DSpace，現在是KALS。因此一開始的時候，我的角色有點像是系統開發的技術指導，當時還會開課教授怎麼寫DSpace呢。

在考上博士班之後稍微比較不用全心投入論文之後，我開始想要帶著助理與學弟妹一起來為實驗室做些整頓。同時也在老師的要求之下，我開始每週舉行以實驗室研究助理與對網管有興趣的學弟妹為主的MIS Group Meeting。MIS雖然是Management Information System的簡稱，但這裡是取臺灣對於網路、伺服器管理特有的職稱：MIS人員。

在MIS Group Meeting中，我希望主要討論的內容偏向工作細節，最好是技術實作的分享。因為在MIS meeting的成員大多具有共同的領域背景，因此多吸收彼此在網路管理、程式開發與伺服器建置上的知識，對大家來說具有研究論文額外的專業技術加值。因此我想營造的是有別於每週Group Meeting以論文為主的不同討論內容。

有時候我也會帶大家一同建構實驗室內部使用的服務，或是在MIS Group Meeting中分配與安排老師交代下來的工作。現在實驗室發展的DLLL-CIAS雲端平臺，以及意外實用的EMAIL-KM與ownCloud，都是在MIS Group Meeting討論下發展的結果。

現在MIS Group Meeting最主要的任務是研究助理的進度報告。有部分研究助理是為了其它計畫進行開發，有些助理則負責協助研究生一同開發系統。而我大多時候是提供大家開發上的建議，像是寫程式上的問題，或是指導系統開發的方向，以免大家像無頭蒼蠅隨意亂竄。

後來MIS Group Meeting也加入了想以系統開發作為畢業論文的學弟妹們，讓學弟妹有機會每週都在meeting中跟我討論如何開發系統。此外我也會在meeting中提供論文撰寫的指導，並老師分擔一些指導的工作。

雖然我研究功力當然比不過老師，但是在程式開發與網管方面，我覺得我可以給學弟妹更多的幫助。至今為止也順利地送走了兩位學弟妹，而新的兩位學弟也加入了MIS Group Meeitng的行列，希望我能多多加油，幫助學弟們順利畢業啊。

規劃論文架構與批改論文 / Advise and Revise Thesis

除了在Group Meeting跟MIS Group Meeting之外，我有時候也幫學弟妹跟研究助理討論論文架構與批改論文。

論文是一種長篇寫作，不太可能一口氣把論文全部寫完。因此我會教導學弟妹先將章節架構制訂出來，甚至利用心智圖來整理論文寫作的材料，並據此作為討論論文進度的工具。可惜這方法目前還沒有成功實施XD

然後當論文完成部分章節之後，我也會幫忙修改論文，作為指導論文寫作的一份工作。

這種論文指導方式是繼承自老師的風格。我們的論文交給老師之後，過不久就會退回來一個像是上圖一樣的滿江紅到批改後的論文。我也跟老師一樣，會幫學弟妹的論文上給予大量的批改，並指出不足需要補充的地方。

我不見得會對學弟妹的研究內容這麼瞭解，但是我知道論文應該有的邏輯、語氣與句法。學術寫作的用詞跟一般聊天不太一樣，會有幾種「慣用語」，我之前也在meeting中跟大家分享過，有機會再來在這邊分享。通常學弟妹無法一開始就能夠掌握論文的邏輯與使用合適的語句，引導他們寫一篇像是論文的文章是我主要可以著力的地方。

即使我對於批改的論文內容沒能這麼瞭解，我也可以在批改的過程中強迫自己閱讀、學習那些自己不懂的領域，並且站在一個讀者的角度要求作者提供更完整的資訊，這可以彌補單方面自己撰寫論文時常常一頭熱大量地使用專有名詞或是省略描述系統功能而造成難以閱讀的問題。我是一位讀者，而我跟作者一起成長，論文批改的過程往往讓我學到很多。

儘管如此，論文批改這是一件相當費工的工作，但是我覺得這是很棒的傳統可惜的是我還是沒能像老師那麼會寫就是了。

博士班學長在做什麼？ / What’s Doctoral Student Doing?

常常會在ptt之類的發文中看到大學生或碩士生認為博士生也沒有比較厲害。我覺得某方面來說，的確是如此。

畢竟到研究所開始撰寫論文之後，大家都會往更專門的領域埋頭鑽研。我鑽研的領域有限，很多時候真的覺得學弟妹比我厲害很多。儘管如此，我還是希望能夠幫上學弟妹一些忙。希望大家不要像我一樣，東摸西摸地唸了三年多才畢業。

另外一方面，當我在做這些事情的時候，我也有種越來越像是在做老師在做的事情的感覺。不過跟老師相比，我還是遠遠地不夠格就是了。

總之，這種介於學生與老師間的「博士班學長」的身份，就是我目前的一部分工作了。

 

題外話：開頭那張照片是用Google+的相片編輯功能來做的，還蠻有意思的啊。

(more...)

論文進度報告(2011/1/19)：變更的研究架構 Progress report: modified research

現在論文的進度來到了「分析資料」的步驟。很多人會問我：「論文寫得怎樣了？」我都會回答：「一個字都還沒寫。」是的，論文還沒正式動筆寫，因為我現在還在數字之間打轉。

為什麼很久都沒報告進度？

距離上次論文進度報告居然隔了快要兩個月的時間，這段時間我到底在幹嘛呢？其實是因為12月底的時候我就在進行論文的實驗。由於擔心受試者會有霍桑效應的影響，也就是他們發現到自己原來就是實驗的對象，而改變了原本自然的行為，所以我想應該是要隱瞞「這是一個實驗、我正在觀察你們」的這個訊息。

實驗的過程中其實有很多想跟大家分享的資料，可是礙於這個限制，我自己也悶了好久。現在實驗已經結束，進入分析資料的階段，也跟老師確認了一下，就算公開應該也是不受影響，所以接下來我會陸陸續續地在這邊敘述目前論文的進度。

變動的實驗進行、變動的研究架構

由於實驗進行方式與當初計劃書規劃的有很大的不同，所以連研究目的、研究問題、研究架構等設計都要全部重寫。會變動我覺得很正常，跟人扯上關係的計畫通常都無法如願地進行，這並不是任何人的錯。如果真要怪是誰的責任，那我會認為是自己需要去承擔這種變更帶來的風險與額外工作。

簡單來說，整個研究架構都要做調整。從上週與老師討論時講的研究架構投影片 (SkyDrive下載) 讓老師直呼：「你的研究怎麼會變成這樣？」就可以知道我的論文變動的程度大到令應該是很熟悉的老師都覺得很驚訝。

總而言之，現在就是要改研究架構。我希望整個研究架構能寫到簡單、直覺、易懂，所以不斷地翻修，並嘗試跟別人說明、邊講邊反省看看自己是否寫得好或壞。

基於標註行為之知識萃取研究與應用

目前的論文的標題我擅自將之修改成「基於標註行為之知識萃取研究與應用」，而研究目的主要有三項：

1. 發展基於閱讀標註行為之知識萃取機制。
2. 驗證知識萃取機制有效性。
3. 找尋改善知識萃取機制的方向。

根據以上研究目的，我需要探討以下研究問題才能達到這些目的。其中「發展」目的是要仰賴文獻探討與系統發展，因此只需要針對「驗證」與「改善」來設計研究問題：

「驗證」目的

1. 閱讀理解能力高低是否與知識萃取機制結果相關？
2. 知識萃取機制與整體的標註行為有何差異？

「改善」目的

3. 哪些標註行為與閱讀理解能力高低相關？
4. 哪些標註行為與背景因素相關？
5. 受試者對於改善知識萃取機制的建議是？

上述研究問題中主要需要定義的有四個名詞：

1. 知識萃取機制：本研究根據文獻探討與專家意見發展而成，考慮六種標註行為之後以模糊綜合評判來判斷標註好壞的「標註分數」、並且給予使用者提示改善的「標註建議」。知識萃取機制包含六項因素的模糊隸屬度函數制定(判斷各行為的好壞)、因素權重設定這些細項。
2. 知識萃取機制結果：受試者透過本研究的知識萃取機制所得到的結果，包含「標註分數」與「標註建議」接受程度。
3. 標註行為：受試者利用本研究標註系統的原始行為資料。與知識萃取機制結果不同，不受知識萃取機制設計的影響。
4. 閱讀理解能力：閱讀本研究指定文章之後，以「閱讀理解測驗」跟「心得報告」來評定受試者的閱讀理解分數，能夠反映出受試者閱讀理解能力的高低。
5. 背景因素：包含閱讀習慣(閱讀報紙、雜誌、書本、網路文章的頻率)、內外控性格、科技接受度模型

基於以上五個研究問題，就可以整理成下面的研究架構圖：

而這五個研究問題又必須蒐集不同的資料、做不同的統計與分析方法來處理，才能回答這些問題。詳細的內容就請看投影片吧：(SkyDrive下載)

結語

由於分析方式與實驗室中常見的準實驗研究法有很大的不同，各種因素之間要如何配對比較都需要構思，再繼續分析的這段日子裡，研究架構還會持續地被修正吧。

另一方面，不熟高級統計的我實在是無法貿然地使用單因子變異數等統計工具，就算統計軟體跑得出來，但我也不會解釋或是確認各種數字。儘管目前我只是使用初統的獨立樣本T檢定與Pearson相關係數，一方面我想這已經足以解釋之外，另一方面是我預期這些因素相關都不太能達到統計上的顯著性，因此到最後還是需要參雜許多質性的個案觀察來解釋吧。

(more...)

2009年的論文進度報告

 

說來慚愧，2009年我只有兩篇報告跟論文有關。其餘他都在教育部計畫跟寫書。

• 20090218 論文進度報告 (Google Doc瀏覽)

一篇是在講知識萃取的方式。我打算採用「關鍵字筆記」這種讀書方法。根據東方人學習革命的說法，把書中的關鍵字當作重點標註之後，便能很快地記憶整篇文章的內容。我也找了一些劃重點的書本來輔助，整理了一些規則出來。儘管報告完老師沒說什麼，但因為還很草、不具體，所以仍算不上有什麼突破。

裡面本來預期2009年7月能畢業，結果那時候只能看別人畢業，想來不禁唏噓。

• 20090828 標註在閱讀中的定位 (Google Doc瀏覽)

另一篇則是以如何閱讀一本書為主，看看大師教導人閱讀的過程中，標註屬於何種地位。作者Adler將閱讀分成四種層次：基礎閱讀、檢視閱讀、分析閱讀與主題閱讀，並探討了各種領域書本的閱讀方式。其中，在檢視閱讀時，標註能夠幫助讀者快速抓到重點；分析閱讀時，則能夠協助讀者去詮釋、評論書中的內容。因此，我的論文中能以「提昇閱讀層次」這個面向來詮釋學習成效的提昇。不過也一樣是很理論的概念，勉強只算讀書心得吧。

年末時，我想到以模糊理論來實作關鍵字筆記的系統。但因為種種原因來不及整理報告內容，所以就變成報告拖過年了。

2010年繼續努力吧！

(more...)

合作式閱讀標註之知識萃取機制研究 A Study on Developing Knowledge Extraction Mechanisms from Cooperative Reading Annotation

這是我在國立政治大學圖書資訊與檔案學研究所撰寫的碩士畢業論文，指導教授為陳志銘博士。撰寫完成時間為99學年度下學期，實際上是民國2011年（民國100年）3月。

作為一份記錄，這一篇將會簡單地回顧一下整個論文的撰寫過程、論文的摘要，以及附上論文的相關檔案。

論文撰寫過程回顧

計劃書

圖資系所在碩士生撰寫畢業論文之前，通常都需要先撰寫論文的計劃書，陳述為何要做這個題目、要怎麼做這個題目、需要什麼步驟，並請口試委員幫學生審核是否可行，然後才開始進行碩士的畢業論文。

跟其他在政大圖檔所的學生差不多，我也是在碩二上的時候進行計劃書口試，日期是2008年12月，之前有寫一篇計劃書口試通過的記事，裡面包含了計劃書口試時使用的簡報。通過之後再依照口試委員的建議進行修改，這一篇則是在講修改後的計劃書檔案。

我的論文計劃書拿去參加國立臺中圖書館（簡稱國中圖）博碩士論文獎助並有幸獲獎，約定要於畢業時呈繳論文，才算是完成獎助契約。

論文聚焦與系統開發

之後有非常長的一段時間，我都在處理DSpace跟其他的外務，是個不務正業、玩物(?)喪志的學生。大概到2010年4月又回到論文的工作上，不定其地在此blog撰寫meeting時的論文進度報告，督促自己要積極撰寫論文、儘快畢業。論文相關的文章請看碩士畢業論文的分類標籤。經過一些文獻探討之後，毅然決然調整了論文進行的方向。

在聚焦研究問題的同時，我也開始學習以專案管理與UML的方式規劃論文系統的專案，並且閱讀極致軟體製程（eXtreme Programming explanined）、測試導向開發、PHP專業程式設計、物件導向設計模式等程式設計的書籍，努力提昇自己的程設能力。系統規劃大概是從2010年5月左右開始進行，實際上大約是2010年6月才開始撰寫系統。不過就算是到現在，我也不覺得系統算得上是完成品。關於系統的內容與功能請看KALS!標註工具說明一篇。

實驗進行與數據分析

2010年下學期學期中，由於論文系統撰寫時程大幅度地延長，導致論文的實驗並沒有按照預期希望的進行。老師建議我改以老師正在上課的同學來進行實驗，而我因此以目前系統的完成狀況、更改觀察的變項，大幅度地修改了整個實驗的設計。由於當時並不想告訴同學這是一個實驗，因此並沒有在此blog提到這些事情。變更的過程與細節請看論文進度報告(2011/1/19)：變更的研究架構一篇。實驗的設計與內容都鉅細靡遺地寫在論文之中，稍後請參考論文的內容。

實驗完成之後接著是數據的分析。這段期間學習了內外控量表、序列分析與循序樣式探勘等研究工具，不過論文最後並沒有派上用場，單純成為了學好玩的知識。當時在分析時到處找了相當多的方法，甚至自創演算法來加權數值。後來是在聆聽學弟妹的計劃書口試中找到靈感，並以統計的方式完成了現在的論文。

最後分析主要還是用統計的獨立樣本t檢定、單因子變異數分析、相關分析以及無母數分析等方法進行。在此推薦一下吳明隆的「SPSS操作與應用：變異數分析實務」（ISBN：9789571145754）一書，不僅可以讓人依樣畫葫蘆操作SPSS，理論說明也相當清楚。即使原本沒有學過單因子變異數與無母數分析的我，照這本書所講的內容，也只要一天就能夠輕易上手、完成論文分析。

分析完成的時間點大概是2011年1月過年之前，並與老師報告分析結果，讓老師確認沒有問題之後，才是撰寫論文內容。

論文撰寫與口試

有了分析結果之後，就能夠開始推論結論、撰寫論文。撰寫過程請看我的論文寫作工具：XMind心智圖一篇。之間與老師多次來回討論、修正，經過各章節二次以上的校對之後，終於完成了論文的初稿，可以準備舉辦碩士畢業論文的口試。

口試的邀約相當地匆促，大概是二月底的時候開始邀請老師。有的老師沒問題，有的老師時間橋不攏，有的老師工作事務繁忙而推辭，前前後後共問了六位老師。最後碩士論文口試邀請的口委為卜小蝶老師、林巧敏老師、侯惠澤老師，以及我的指導教授陳志銘老師，以上共四位口試委員。口試時間排定在2011年3月4日。

老師們給了我很多建議，因為現有的論文分析方式不太像是社會科學的角度，而是相當工程的分析，因此老師建議應該更往社會科學的方式來分析會比較好。此外，老師們讚賞系統開發，認為其本身就已經是一種研究貢獻。然而除了論文寫作細節挑些毛病之外，論文內複雜的實作與分析過程居然沒有人提出質疑，讓我個人挺訝異。口試時的簡報將於本文後面附上。

畢業論文送繳

口試之後即動手撰寫論文的修改版，再來進行論文的印製，之前我也有寫了篇印製過程的心得。

畢業前將論文呈繳到政大圖書館，圖書館會在轉送到國家圖書館，因此我的畢業論文現在也在臺灣博碩士論文知識加值系統中出現了。

在畢業事務處理期間，我也完成了與國中圖的契約、呈繳了十本畢業論文。之後回去國中圖找論文的時候，發現我的論文也已經編目上架了。

以上就是整個論文的大致撰寫過程。

論文摘要

• 題目：合作式閱讀標註之知識萃取機制研究
• 關鍵詞：合作式閱讀標註；知識標註學習系統；知識萃取機制；模糊綜合評判；閱讀學習。

本研究在合作式數位閱讀環境中發展了一套「知識標註學習系統」，可以支援多人同時針對一篇數位文本進行閱讀標註與互動討論，以提升讀者閱讀的深度與廣度。此外，本研究更進一步地以專家評估法設計「知識萃取機制」，用於判斷讀者閱讀標註的重要度。

「知識萃取機制」是基於讀者閱讀標註中所蘊含的閱讀理解策略與閱讀技巧，以及合作式閱讀社群中產生的標註共識，考量了「標註範圍長度」、「標註範圍詞性」、「標註範圍位置」、「標註策略類型」、「標註範圍共識」與「標註喜愛共識」等六項因素，以專家評估法制定的標註重要度模糊隸屬函數來評定各因素的重要度並量化為「標註因素分數」指標，最後將六項因素以模糊綜合評判進行推論，再將推論結果解模糊化而成為代表標註重要度的量化指標「標註分數」。基於「知識萃取機制」所計算代表標註重要度的「標註分數」，可作為讀者進行閱讀標註是否不佳的判斷，並據此提供標註技巧建議與優質標註內容推薦的「標註建議」，以幫助讀者提昇閱讀理解能力。

為了驗證「知識萃取機制」計算「標註分數」的有效性，以及探討未來改善「知識萃取機制」和可加入的考量因素與適性化設計的可能方向，本研究以單組後測設計規劃實驗，並以國立政治大學圖書資訊數位碩士在職專班19位學生作為實驗對象，進行一份數位學習論文的合作式閱讀標註學習，並於實驗後評估實驗對象閱讀文章之後的閱讀理解能力，作為評鑑「知識萃取機制」計算方式是否有效的指標。最後再以問卷蒐集實驗對象對於「知識萃取機制」的意見，歸納成為未來研究改善的參考依據。

研究結果發現，本研究所提出「知識萃取機制」中計算標註重要度的「標註分數」與實驗對象的閱讀理解能力呈現低度正相關，一定程度地證實了「知識萃取機制」計算方式的有效性。而「知識萃取機制」六項考量因素中，「標註範圍長度」與「標註喜愛共識」為分辨實驗對象閱讀理解能力的關鍵因素；「標註策略類型」與「標註範圍詞性」的標註重要度模糊隸屬函數有待修正；「標註範圍共識」與「標註範圍位置」為無效因素，但這可能是受到計算方式錯誤與閱讀文章類型的影響，未來仍有待進一步評估。在未來發展方面，系統操作標註行為頻率越高，實驗對象的閱讀理解能力也有較高的跡象，未來可以將其納入「知識萃取機制」作為考量因素之一；而閱讀理解能力較差的實驗對象，呈現出比較不願意回應「標註建議」與較常使用社群互動的現象。本研究歸納可能原因為實驗對象自身的閱讀素養不成熟，以至於無法判斷「標註建議」的正確性，而需要參考他人閱讀標註。

未來研究可針對本研究的實驗對象與閱讀標註資料進行更深入的分析，並且將改良後的「知識萃取機制」擴大至探討其他類型的數位文本閱讀標註與實驗對象。也可以搭配認知策略教學法建構閱讀教學鷹架，或是將「知識標註學習系統」用於支援數位典藏與數位圖書館閱讀學習，以激發更多不同領域的應用研究。

論文檔案

正文內容

裡面有很多工程技術與計算過程，因此相當地枯燥乏味。有需要的人再打開來看吧。

• 正文 docx (2,459KB)
• 正文 pdf (2.640KB)
• 書背 doc (32KB)：供學弟妹參考用的檔案

畢業口試投影片

• 投影片 ppt (2,230KB)
• 投影片 Google Doc
• 投影片主題樣板 thmx (120KB)
• 投影片列印 pdf (1,111KB)

結語：論文未完成

論文即使寫完了，卻仍有許多資料並沒有善加利用。例如上圖的標註範圍次數分配表中，可以看到標註範圍為4個字的次數佔了最多。不過這數據究竟能怎麼解釋，我還沒有什麼頭緒。總之，這份論文的資料還有很多利用價值，也許可以再分析出些什麼關連，也許也可以從不同角度進行不同的分析。

這個論文，總覺得只能說是「做到告了一段落」，還不能說是「完成了論文」的感覺。很多未探究的地方都還沒好好釐清，我就這樣子被趕著畢業了。

至於論文中的KALS系統，儘管我希望他以開放原始碼的形式公開（請看KALS的Wiki），不過至今仍尚未動手進行。日後我可能會先將原始碼公開，並在實驗室架設一個公開使用的系統，屆時會再告知大家。

最後我應該會放棄KALS開發。因為我想要用其他技術來撰寫，嘗試更效率更好、更容易開發、更具有可維護性的方式來開發系統。

這份論文並不是寫的很好，有任何看不懂、發現有問題、覺得不太可行的地方，歡迎大家提出來討論。也祝往後接手的學弟妹能夠順利畢業，大家加油。

(more...)

論文進度報告(2010/6/13)

距離上次進度報告大概10天的時間，現在就開始這次的進度報告。

上次將Webpage Application的網站草圖(Website Wireframe)畫完之後，陸陸續續地也把Controller做完了，詳情請看KALS Wiki的資料。在畫Controller時，其實我並沒有很仔細地去構思到底該怎麼運作。在AJAX的架構中，View所在的JavaScript同時扮演了View跟Controller的角色，伺服器端的Controller反而像是提供資料的角色而已。

原本計畫完成Controller之後，我就開始進行程式撰寫的作業。目前把ERD (關聯式資料庫的實體關聯圖)畫得差不多，還再次複習了CodeIgniter使用手冊。但基於對Controller太過潦草的不安，我決定還是插入Sequence Diagram(循序圖)的任務，打算好好地檢視資料在物件之間流動的情況。特別是以下這四種情況：

1. 建立新增標註的過程（包含計算分數、推薦標註與提示等細節）
2. 接受建議並修改標註位置
3. 自動登入
4. 手動登入

由上而下的規劃方式

由於對於Sequence Diagram的不熟悉，我花了很多時間在畫建立新增標註的過程。由於StarUML跟書上寫的功能有些許不同，書上對Sequence Diagram的介紹也不是很清楚，於是我只好自己試著建立起屬於自己的表示方式。除了將上面的這張主要流程切割成其他7個小部份，對於參數傳遞與回傳值等也稍微跟標準的劃法不太一樣。目前已經完成了建立新增標註的過程的八張圖請看KALS Wiki。

經過Sequence Diagram的檢視，赫然發現標註在模糊分數計算、推薦與提示上出現了很大的問題。這讓我回頭去修改了Model的Annotation、Fuzzy跟Recommend等Class。

在之前的進度報告中，我在繪製View、網站草圖時，也常常提到回頭修改這件事情。每次回頭修改的感覺都頗令人絕望，但值得慶幸的是，我回頭只是改圖，而不是修改那數千行的程式碼。我想，這就是一種由上而下的規劃方式吧。儘管目前仍沒有實際可以把玩的程式給大家看，但這些分析與規劃的確是一步一步地讓這個系統更為穩健。

專案進度：加入Sequence Diagram

如上圖所示，跟上週比起來，加入了Sequence Diagram的工作，並將之規劃為9天的工作天，因此排擠到後面程式撰寫與可展示系統的查核點。很不幸的，如果專案如期進行，大概七月初才能將系統展示給大家看吧。詳細的專案進度，請到KALS Wiki下載。

老實說，一直畫圖，太久沒寫程式，實在是讓我覺得有點無聊。所以這次中間有幾天都跑去修改布丁布丁吃？的版面(遮臉)。那時的自己並不會使用JavaScript的callback技巧，我還蠻驚訝的。在不知不覺時，自己的程設等級似乎又無形中上升了，而這在修改以前寫的程式中也有所映證。

除此之外，老師對我在畫UML這件事情也覺得還不錯。儘管UML分析的過程枯燥乏味又無法立竿見影，急於完成論文的學生大多時候並不會選擇採用這種方式。但對於大型系統與多人合作團隊的情境之下，UML仍是一項很有力的工具。

反正我已經多留了很多時間了，也不差讓我再多用一些時間繼續繞繞遠路，學些新的玩意兒。

我也不知道這究竟是好事還是壞事。從好的角度看來像是求知欲強烈，從壞的角度來看則是拖台錢(找理由延畢)。不管怎樣，我只知道我還挺無聊的就是XD

(more...)

第一次的計畫書口試旁聽

「這是我第一次口試耶，好緊張喔。」穿著全身套裝的學姊如此說的。

對於我來說，這是我第一次參加計畫書口試的旁聽，也是一樣地緊張。

---

計畫書、口試與畢業

上週是我們所上的計畫書口試期。根據所上的規定，必須要通過計畫書口試之後六個月，才能作畢業論文口試。往前推算六個月，差不多就是這段期間。

所謂的計畫書，就是畢業論文的前面部份，包括了研究目的、研究問題、相關文獻探討、研究方法說明。如果完成整個畢業論文的話，後面還會有研究結果、結論。這大概是一般論文的架構。

提計畫書的時候，通常尚未開始正式進行實驗(實作研究理論)。也就是說，實際進行實驗的期間只有數個月。

只要通過碩一暑假的資格考、或是擁有投登期刊論文的資歷，那麼就可以提出計畫書口試的申請。修完學分並通過口試之後，碩二就畢業是很正常的事情。這是政大圖檔所的特色，許多研究所，特別是文學院的，都必須要修完學分才能開始研究，因此最快也只能到碩三才能畢業。

開始進行研究，也就是提計畫書的方法，通常都是要與論文指導教授配合。每個老師的習慣都不太一樣，陳老師很早就會找學生進他的研究團隊，然後在每週一次的團體開會(通常是說meeting)中，逐漸找到論文題目的方向。

印象中，似乎是碩一下的時候開始找老師，然後碩二開始的時候決定指導教授的樣子，我忘有點了，大概是因為我在入學之前就已經跟了陳老師，所以我也不太在意。偶爾聽說了其他同學的狀況，通常頂多是只有幫老師做研究，也還不到談論論文題目的程度。

接著來聊聊決定論文題目方向的話題。之前有聽說「研究生抱怨老闆(指導教授)不給論文題目，害他不能畢業」這種事情，雖然你也可以想說是他研究能力不足，不過實際上的確很多學生的論文題目是指導教授決定的。以陳老師的說法是：「與其讓學生自行決定不成熟的題目，不如由老師來把持、決定。」

另一方面是教授很常拿學生的研究題目去提研究計畫，例如常聽到的國科會、什麼什麼計畫的。因此會統一研究團隊的題目朝幾個方向進行，屆與屆學生之間的題目會有繼承、延伸的關係。舉例來說，陳老師之前的學生在做無線網路定位的技術，之後的幾位學生也是將這技術做其他方面的研究。「你去study一下某學姊的東西」這種話，也常常可以在meeting的時候聽到。

有些研究生不太喜歡老師幫他指定題目，覺得沒有自由發揮的感覺。但唯一可以確定的是，這樣做研究時通常比較能有足夠的資源與支援，最後比較快畢業。

Group Meeting

既然聊到這邊了，那接下來就講一下meeting。陳老師的meeting風格很特殊，至少我身邊的朋友還沒有這樣子的meeting方式。我們是每週一次的group meeting，陳老師的學生們，包括政大資科、政大圖檔、花師的學長、師大工教所與大學部的專題生等大約十來人，全都齊聚一堂，來做團體的開會。

meeting的流程大致上是，老師先報告他最近的事情與研究的方向，然後接下來有要報告的學生上去報告，正在進行研究或計畫的通常會報告進度，沒有的話則挑個最近在研究、閱讀的文獻上去報告(就是paper study啦)。報告的頻率大概是每隔週一次，也就是說每次大概都有四、五個人上去報告。每次meeting的時間短則三小時、長則甚至到五個多小時都有。

一開始我也很不適應這種meeting方式，不過後來就習慣了，當作一門自由的課堂上課。group meeting的好處常常可以聽到其他人的研究進度，這也是學姊計畫書口試的時候，大部分內容都是我聽過的原因。

其他老師的meeting風格不至相同。大部分是會分成單獨meeting與團體meeting，與老師一對一的時候是討論畢業論文，團體的時候則是paper study。可以的話，以後也想多多接觸不同的meeting風格，看看不同教授指導學生的風貌，似乎也是不錯的。

計畫書口試

好，講了這麼久，終於回到計畫書口試上了。

上週我去旁聽同樣是陳老師指導的學姊的計畫書口試。大概從上個月開始，老師每週都要讓他們提計畫書的人上去報告，一路撰寫、修改。撰寫完計畫書之後會送至計劃書審核委員的手上，通常是要在一週之前送到，然後到計畫書口試當天正式審核。

圖檔所計畫書口試時會找三位口試審核委員(簡稱口委)，一位是論文指導教授、一位是所上教授、另一位則是相關領域的校外教授，規定中寫到至少要一位是校外的。除了報告的學生、口委之外，還要有至少一位學生負責記錄、錄音，輔大圖資的學長姐還會動用攝影機，以便之後修改計畫書時不會忘記。(在這邊我要說聲抱歉，我那時候真的以為是去旁聽的，結果什麼都沒帶，也都亂記一通orz)

計畫書口試過程大概兩個小時左右，學生報告時間約20分鐘，接下來由口委對計畫書內容提問。報告的內容就如之前提到的計畫書內容，以投影片的方式做介紹。口委對計畫書的提問，英文叫做challenge，比較接近質問、懷疑、要求的意思，而不是單純的不懂發問。

提問的過程是整個審核的重點，老師們提問的要點有很多，從研究題目是否明確、研究方法的可行性、資料分析方式是否能夠驗證研究假設、對於模稜兩可的名詞要求清楚的解釋、到計畫書的書面格式都會一一檢視。

學生能不能提出令口委滿意的回答，則是審核是否能夠通過的關鍵。如果是一些明顯的缺失、未補足的資料，只要事後補完即可的話，那是比較好的狀況。棘手的問題，我覺得是針對研究目的、研究方法等核心的質問，這意思就好像口委認為你「這個研究從根本上出了問題」的感覺。

能夠給提問一個清楚的解釋、或是臨時加上補足的方式，當然是最好的。不過再怎麼充足的準備，我想還是很難避免被問到啞口無言的時候。這也是老師跟學生層級上面的差距，老師考慮的程度與細節往往是學生沒有注意到的，這時候就可以看出老師的厲害之處。

有時候口委會提供修改的建議，另外也可能是因為學姊的論文題目是指導教授給了很多意見的緣故，老師也會幫忙回答(英文稱為cover，掩護的感覺)、總結提問，老師緊張的程度我看應該不輸給被質問的研究生吧。

不過那時候指導老師到沒提出什麼問題，我想應該是在meeting的時候也問的夠多的原因。

旁聽的學生同時也擔任紀錄，紀錄也就是修改計畫書的重點筆記，所以口委提問的內容、建議、當時決定的修改方式，都是需要紀錄的。(別像我這樣兩手空空的過去聽啊orz)

在討論了一段時間之後，最後要決定計畫書是否通過。圖檔所的方式只有三種：未通過、通過但需要修改、通過不需要修改。圖檔所除了在職生沒辦法這麼快決定題目之外，幾乎所有的碩二學生幾乎都在這時候提出了計畫書口試申請，而似乎很少在計畫書階段不通過的案例。但這不代表審核過程並不嚴謹，應該是歸功於用功的學生跟認真的指導教授們吧。

最後提到當天的場佈跟餐點。口試時除了正式的服裝、完整的書面資料及筆記用空白紙以及報告用的電腦設備之外，通常還會有餐點與飲料。

每個研究生準備的餐點都不太一樣，有的是水果、有的是麵包餐盒(很多種麵包的那種)，遇到正餐的時刻，還會有便當。我聽過有人準備了沒剝的荔枝，好像不是很方便吃的感覺。實際上，好像口委們都不會在當場吃這些餐點，大部分會在口試之後帶走。我想這可能是所辦常常有食物可以吃的原因之一。

飲料是必備的，因為講話講這麼久口會渴。一般是泡茶，楊老師常提醒學生有外賓來要泡咖啡，能準備的多周全就盡量準備吧。

儘管計畫書口試的過程著重的是研究的內容，但這些服裝與場佈就像是誠意的展現一樣，我覺得也是很重要的。

---

過程中就算是旁聽的我常常為學姊捏一把冷汗。最後結果，當然也是過啦。

學姊在口試之後放鬆地說了一句話：「我大概接下來一個月之內都不會碰這些東西了。」不過我想，實際上應該很難吧(笑)。

參與口試計畫書的經驗相當有趣且珍貴，今天是學姊口試，明年可就換我們這屆的人在台上了。

同時我也再次體驗到了自己程度上的不足。聽到口委們提出那些切入核心的問題，我會同時思考自己要怎樣才能跟他們一樣看得這麼深、表達的這麼清楚。當然，很多是我未能達到境界，只能繼續加油囉。

題外話，平常穿著樸素的學長姐們，在這段期間都變身成為西裝帥哥跟套裝美女，真讓人耳目一新呢。

(more...)

論文進度報告(2010/7/2)

.

這次進度報告又隔了兩個禮拜，由於到最近才有比較明顯的成果出來，是也就沒有急於每週定期報告。

實際進度一張表就可以講完了：

類別	應完成	已完成	已完成百分比
Model	100	19	19%
View	73	0	0%
Controller	9	0	0%
總計	183	19	10.3%

這是到Coding D13的今天為止的進度。

以下是其他話題閒聊XD

完整的物件導向？還是兼容PHP 4.3？

我使用CodeIgniter 1.7.2這個PHP Framework來建置系統，而CodeIgniter是兼容於PHP 4.3為目的來設計，在CodeIgniter的PHP寫作風格指南裡面也提到說，除非特別說明，否則程式應該能夠相容於PHP 4.3版以上。

PHP 4跟PHP 5的物件導向寫作有很大的不同。PHP 5比較像是Java這種嚴謹的物件導向，有public private abstract final等好用的功能可以使用，而PHP 4則比較像是單純的變數跟函數綁在一起的物件。

在繪製UML時，物件中成員變數與方法的開放程度都會是考量的範圍內，但是PHP4並不支援，而CodeIgniter只有在Controller中有提供此方法，那就是private(私有)方法的名稱前加入「_」，例如「_filter_id($id)」。

本來我也是想用這種方法去兼容PHP 4.3，但是寫一寫忽然發現這還是有些問題。這樣作法會無法善用完整的物件導向概念，儘管實作上PHP是很自由的，但是從學習的角度來說，還是盡量地嚴謹一點會比較好。因此我中途決定改以較完整的方法來撰寫PHP程式碼，不僅讓物件導向較為漂亮，NetBeans的導覽視窗(Naigator)跟自動完成功能也能提供比較完善的支援。

這是我在撰寫Generic Object時，NetBeans的導覽視窗，有上鎖的表示private私有方法，而黃色菱形的則是PHP 5的魔術方法__construct()建構子。看到NetBeans能夠更正確地解讀我的程式，也就覺得用完整的物件導向也挺不錯的感覺。

也許以後實務工作時我會從簡來做，但現在我仍在學習中，就好好地確實地寫好每一支程式吧。

很好上手，卻也很難抉擇的PHP

儘管PHP有提供物件導向功能，但原本他是程序導向的程式。而CodeIgniter雖然是物件導向程序，但是他卻有自己的一套作法。雖然高度自由的PHP讓我可以選擇各種作法，但這也是頗難抉擇的一件事情。

CodeIgniter會希望程式設計師以CI_Base物件為主體，在Contoller、Model裡面已經先預載了CI_Base，而Library或其他地方則是要呼叫「CI =& get_instance()」。如果要使用CodeIgniter豐富的Library或Helper的話，就非得使用CI_Base才行。

然而CodeIgniter裡面的如果要用繼承、介面等物件導向功能，就不應該使用它的Model，而是用Library才是。這也跟原本我在UML中規劃的方式有所不同。Library並不會預先載入CI_Base，都必須另外呼叫才行，

因為CodeIgniter寫作方式與我預先認知有所差異，所以實作時遇到了很多難以抉擇的困擾。到底要用物件導向的繼承？還是要用Helper的function？以前寫PHP時，很依賴function來提供模組化的作法。但現在程式開發的技術進步了，是否能夠改用物件導向的繼承來實作呢？

這些問題並不只會在一開始困擾著我，在系統持續發展的時候，也會不斷地修正我的作法，以求得更好、更佳的程式開發方法吧。

迷上了Unit Test 單元測試

自從之前看了極致軟體製程(eXtreme Programming，簡稱XP)的介紹之後，我就把單元測試這個概念深深地記在腦海當中。而在開發系統時，我也開始學著依賴單元測試，並且到最後迷上了它。也許有人會在噗浪上看不懂我在念著測試測試到底是什麼，其實就是指單元測試(Unit Test)。

相符或不相符的檢查

單元測試是軟體測試的小型版本。軟體測試的概念很簡單，就是看看系統產出的實際輸出與我們希望的預期輸出是否吻合。我製作了meeting時報告用的投影片，不過我認為節圖出來用文字來說明應該會更好懂：

這是單元測試的一個示意圖。程式設計師撰寫出程式給電腦，然後要求電腦執行該程式，而程式設計師也自己想一個預期成果，並把它們相互比對。這支程式輸入兩個整數參數，並把它們彼此相加再輸出。輸入test(1, 2)的話，輸出結果應該是3。如果正確地符合程式設計師的預期，那麼測試就算通過(Passed)。

反過來說，當程式跑出來的結果並不是3的時候，可能就是該程式出現問題了。上面示意圖中則是測試沒通過的樣子，因為程式裡漏掉了參數，導致結果輸出不如預期，這時候就是要回頭去debug了。

單元測試與程式開發

單元測試本身是一種黑盒測試，它只注重輸出結果，並不看程式內部的細節。但由於他檢測的程式通常都是非常小的一塊，而不是整個系統的運作，所以用來檢查錯誤非常方便。

單元測試提供了一個模擬環境供程式運作，它可以讓程式重複地進行測試，並輸出一張簡單明確的報告，讓你知道哪些測試通過、哪些沒通過。由於單元測試執行速度快、簡單，因此只要程式有任何修改，都可以馬上回頭以單元測試進行檢查。久而久之程式設計的動作就會變得很單純：寫完、測試、通過就繼續寫，沒通過就回頭修改。

在極致軟體製程中，單元測試也是相當重要的一環。當系統分析做完之後、要開始撰寫程式之時，程式設計師應該先只寫程式的大綱，像是成員變數的宣告、私有公有方法的宣告(但是裡面都是空空如也)，很快地把整個程式的大綱寫出來即可，內容細節或是能不能運作，稍後再說。

有了程式大綱之後，就開始製作單元測試檔案。這個測試檔模擬該程式使用的情境，包括輸入的參數、預期輸出的結果。在嚴謹的單元測試當中，會將程式裡每一個方法一一去測試，但我在實作上只有測試幾個重要的項目而已。其實這也不是什麼大問題，只要後續想到什麼情境還可以拿來測試，隨時都可以加入單元測試檔，這也是XP告訴我們的方法。

測試檔完成之後，就拿程式大綱來測試。理所當然地，測試會失敗。接著程式設計師再繼續把程式細節一一地補上，並隨時利用單元測試檔來檢測自己的進度。直到所有測試都通過，那麼這支程式就算完成了。

單元測試Framework：PHPUnit

就像Java的單元測試框架JUnit一樣，PHP也有單元測試的框架：PHPUint。它是由純PHP程式碼寫成的輕量級測試框架，具有自動產生規範好的測試檔格式功能，能提供嚴謹的單元測試。除此之外，它也可以結合Xdebug分析程式碼覆蓋率，或是支援Phing部屬測試與Selenium做大型自動化集合測試。

在IDE中也會提供PHPUnit的支援，像是上圖就是NetBeans的測試功能。

但由於CodeIgniter框架運作方式與單純的PHP不同，難以使用PHPUnit來做測試，所以我並沒有使用這個強大的工具來進行單元測試，而是使用CodeIgniter提供的簡易版單元測試功能而已。

通過測試的程式令人安心

我現在也學著以測試導向作為程式建置的方法。儘管有人會覺得這個測試檔的製作很多餘，但習慣時候，看到測試通過的程式反而更令人安心。

程式設計最大的樂趣，我認為莫過於看到程式順利運作的時候。但在大型系統中，我們不得不將程式分割成細小的部分，就像MVC中切割成三大責任一樣。系統運作缺一不可，但是要等到全部做完才看到成果，也未免太令人不安。就像我現在在開發Model這一塊，正常情況下它是沒辦法獨立運作，而更不知道它到底能不能順利地運作。這時候使用單元測試，就可以簡單、迅速地知道這支程式在預期的情況下正不正常，並依此來修改程式。

雖然看到測試沒通過時，會覺得有點難過，但也總比系統寫得超複雜時還要回頭偵錯好的多。反過來說，看到每個單元測試都通過時，那種感覺真是非常地快樂。於是不知不覺，人心就變得單純了XD

我在這次報告中還有敘述Generic Object跟Lazy Loading的概念。Generic Object我還要再作一些修改，而它也實作了Lazy Loading這個程式設計的小技巧(儘管它很重要XD)，所以留待之後有機會再一起講吧。

本週的論文進度報告就到此為止。因為有雜務丟下來了，所以又得一段時間沒辦法寫論文。就認命吧。

(more...)

論文進度報告：評估閱讀理解能力 Progress report: Measure Reading Comprehension

要評估一個人的閱讀理解能力並不是很容易的事情。除了閱讀理解的程度會隨著文章不同而有所變動之外，閱讀理解能力還涉及多方面的概念，根據Cromley等人(2010)提出的DIME Model，認為閱讀理解涵蓋了「先備主題知識」、「推論」、「閱讀策略」、「閱讀詞彙」與「閱讀流暢度」這五個構面；而Keshav(2007)、Bogucka & Wood(2009)、John & Roy (2010)等人又針對學術論文提出了閱讀指導，他們認為學術論文的重點通常落於「研究問題」、「研究貢獻」、「研究結果」的證據、「結論」等部分。

為了使閱讀理解能力的評估更為客觀，我採用了兩種方式來評估：問答題形式的心得報告以及四選一選擇題的測驗。並規劃為期兩週的閱讀文章作業流程來取得這些資料，而這也就是我論文中最主要的實驗設計。

實驗規劃

這是實驗是在數位學習碩士課程中作為一個課堂報告進行。在課堂報告目的中融入了我的實驗目的，我希望能在這次的作業中讓受試者使用KALS標註系統、並取得受試者閱讀理解能力資料。

在實驗開始之前，我會課堂中說明閱讀文章與標註系統操作，並告知受試者要在閱讀過程中填寫閱讀心得報告，以及閱讀文章完畢之後要進行閱讀理解測驗的訊息。說明結束之後，我請受試者先進行閱讀文章、確認閱讀心得報告的問題，並即時回答受試者的疑惑。

課堂結束之後，受試者會有兩週的時間閱讀文章並撰寫閱讀心得報告。在這段期間中，受試者可以利用課堂討論區進行非同步的提問，我也會在最短時間為受試者排解操作上的困難。受試者可在這段期間內任意時候利用數位學習平台繳交閱讀心得報告，在兩週期限結束之前，我也會確認尚未繳交的受試者，並催促受試者完成撰寫。

兩週報告結束後，我會要求受試者利用數位學習平台填寫閱讀理解測驗，並限時30分鐘內完成。除了填寫測驗時發生了操作上的問題之外，所有受試者都能在時限內完成。

另一方面，原本應該在兩週內完成的閱讀心得報告，卻仍有部分受試者無法在期限內繳交。所以我只好延後繳交時間，讓實驗過程從14天延長到16天才能回收所有的閱讀心得報告。然而閱讀心得報告在設計上並沒有嚴格要求時間限制，因此延後繳交並不會造成太大的影響。

閱讀文章選擇

在本次實驗中，閱讀文章是要給數位學習碩士課程「資訊科技融入教學」作為課堂作業來閱讀，因此文章的選擇與主題會受限於實驗情境，必須要搭配課程以及授課內容大綱，課程的涵蓋主題包括了數位學習理論、教案設計、研究方法、學習風格與適性化、遊戲式學習等。另一方面，由於我的系統需要辨識「詞性」的特徵，所以選用文章必須使用中文語言。

基於以上理由，我選擇使用黃桂芝、曾憲雄、翁瑞鋒與何筱婷於2008在數位學習科技期刊發表的「採遊戲式學習教育平台之科學教育活動設計」作為指定的閱讀文章。該文章是描述如何使用e-GBL遊戲式學習平台，並應用知識螺旋理論，讓遊戲式學習導入教學過程中，採用的研究方法是數位學習常見準實驗研究法，並利用了思考風格之學習分析。其探討議題多能與實驗情境配合，因此我選擇他作為本研究實驗中的指定閱讀文章。

關於這篇文章的原文可以到開放進用期刊「數位學習科技期刊」中下載，下載位置連結在此。我也做了這篇文章的介紹投影片如下：(SkyDrive下載)

閱讀心得報告設計

心得報告的規劃是參考Keshav(2007)、Bogucka & Wood(2009)、John & Roy (2010)等人認為閱讀學術論文的重點，並根據指定閱讀文章、實驗的情境來設計。閱讀心得報告是五題問答題，請受試者自由作答。不限字數，但在說明時提示受試者不用寫太多文字。每個題目配分皆為20分，滿分為100分。受試者必須在兩週的閱讀文章過程中繳交，但是實際上最後是延期到16天才收齊所有受試者的閱讀心得報告。

由於問答題的題目設計在評分上容易偏於主觀、難以取得公平。所以我安排兩位評分者為受試者的閱讀心得報告評分。這兩位評分者熟悉指定閱讀文章，能夠勝任評判閱讀理解能力的工作。每個題目皆有設計好的評分準則，依據題目複雜度的不同，評分準則有2到5條不等，皆有各自的配分。評分時則是請評分者依照此準則，評定受試者回答內容與此準則的符合程度來給分，以確保評分具備信度。

閱讀心得報告的題目與評分準則在評分者之間有多次討論與修正。最早設計時是6題(SkyDrive下載)，後來擬定評分準則 (SkyDrive下載)，最後的題目與評分準則如下：

1. 這篇論文提出了哪些研究問題？你覺得是否清楚合適？
   • 受試者是否能從研究問題取得資料？(10分)
     受試者是否能對研究問題提出自己的看法，且能夠解釋支持或反對的理由。(10分)
2. 請簡單地敘述該論文的主要貢獻。
   • 受試者是否能找到文中「研究貢獻」一節的敘述？(7分)
   • 受試者是否能夠結合論文研究的結果結合到研究貢獻之中？(7分)
   • 受試者是否能用自己的言語來合理地詮釋、說明研究貢獻？(6分)
3. 哪些證據支持這篇文章的研究結論？論文中的研究數據是怎樣解釋結論？你是否有其他看法？
   • 受試者是否能在研究結果與分析的段落找尋資料？(5分)
   • 受試者是否能夠用自己的話撰寫簡潔的摘要？(5分)
   • 受試者是否能夠連結研究資料與結論之間的關係？(3分)
   • 受試者是否能夠質疑對這些證據，或是嘗試評估結論的正確性？(3分)
   • 受試者是否能夠以這份研究數據提出不同解釋？(4分)
4. 請提出這篇論文在研究方法上可以改善的地方。
   • 受試者是否能發現樣本數量不足的問題？(3分)
   • 受試者是否能發現單組前後測設計的缺點？(4分)
   • 受試者是否能夠發現學習成效問卷的嚴謹性不足？(3分)
   • 受試者是否能針對研究方法提出其他的建議？(5分)
   • 受試者是否能夠以研究方法的缺點來檢討結論的合理性？(5分)
5. 這篇論文能對你在實施教學上的啟發是什麼？
   • 受試者是否能從敘述他從這份論文中學習到的知識 (10分)
   • 受試者是否能夠能將論文內容與自身教學經驗結合提出看法 (5分)
   • 受試者是否能夠在教學實施上提出舉例應用、或是新的研究看法或研究方向 (5分)

在回收受試者的閱讀心得報告之後，我擷取受試者針對各五個題目回答的答案，並重新組合成五份評分表格。以第四題的評分表格(SkyDrive下載)來說，表格中包含了題目、評分準則、受試者回答內容、評分欄位。評分表格除了可以方便評分者進行評分之外，還可以讓評分者容易比較所有受試者的回答狀況，以確保評分能夠客觀、公正。

評分者信度的評估方法

在回收受試者的閱讀心得報告之後，兩位評分者即依照評分準則給分。良好的評量工具需要具備效度與信度。閱讀心得報告的效度可從文獻探討中確定，而信度的計算方式，則讓我花了好一段時間研究。

根據余敏賢(2003)的教育測驗與統計重點整理所述，依照評分者人數與評分方法的不同，求評分者信度可用的評分方法有四種，引用表格如下：

		評分者人數
		二名	二名以上
評分方式	名次法 (等級資料)	Spearman等級相關係數	Kandall和諧係數
	分數法 (等距資料)	Pearson相關係數	變異數分析 (Hoyt分析法)

根據我的情況，應該採用Pearson相關係數。但是卻也有許多學者認為這是錯誤的作法。

大陸學者徐曉鋒與劉勇(2007)講解James(1993)的組內評分者間一致性評估的方式，他們指出信度與一致性的不同，此外也有組間與組內的差別。柴惠敏(2007)認為評分者信度評估不應該用Pearson相關係數，因為Pearson相關係數的前提是兩個變項應該是獨立，而我目前資料狀況中，兩位評分者評定出來的分數卻是相依的。他建議應該使用Shrout與Fleiss提出的組內相關係數分析 (intraclass correlation coefficient, ICC)來進行分析。但是ICC需要確認許多前提，竹家庄blog中有專家回答讀者問題中可以得知，這的確不是簡單、隨便就可以使用的一種工具。最後讓我打退堂鼓、回來使用Pearson的是庄主最後的一段話：

定量分析与其它绝大多数知识不同，只能循序渐进、一个台阶一个台阶往上爬。如果对进阶的方法不甚了了，与其大胆试用（大部分情况下会用错，而且错了还不知道原因何在），我强烈建议使用熟悉的经典方法，如回归、方差、crosstabs等等。经典方法也许用到你的数据上会有些问题、但那是已知的问题，而新方法可能带来的风险是无法预知。如果医生不了解某一新药，绝不敢乱用，而会使用已知作用有限并有副作用的旧药。我们是给数据看病的Data Doctor，也要有如此的基本医德。共勉。

閱讀心得報告結果分析

回收受試者的閱讀心得報告之後，兩位評分者即依照評分準則進行評分。評分結果再以Pearson相關係數進行分析，取得Pearson相關係數r = 0.832，雙尾的顯著性p = 0.000 < 0.001，顯示兩位評分者的評分具有顯著的相關性。據吳明隆(2009)的相關係數評判準則來看，r = 0.832屬於高度正相關，也就是評分者A認為高分的受試者、評分者B也認為高分，反之亦然。

相關係數評判標準

相關係數	相關程度
0.7以上	高度相關
0.4-0.69	中度相關
0.1-0.39	低度相關
0.1以下	弱或無相關

由於每個領域的評量工具都有不同的信度準則，r=0.832作為評分者信度來使用是否達到理想的信度水準，這點我還沒有找到足夠的文獻來支持。然而我的研究並不是專注於發展一個評量工具，所以分析到這邊我自認應該足矣。

基於以上信度水準，我可以有信心地將兩位評分者的分數取平均結合，成為最後的報告分數。簡單來說就是下圖：

閱讀理解測驗規劃

除了閱讀心得報告之外，我也根據Cromley等人(2010)提出的DIME Model來設計四選一的閱讀理解測驗。

 

DIME Model (Direct and Inferential MEdiation Model，直接與推論調解模型)是一個閱讀理解測驗設計的模型，Cromley等人認為「閱讀理解能力」(Comp. = comprehension)是由「先備主題知識」(Background)、「推論」(Inference)、「閱讀策略」(Strategies)、「閱讀詞彙」(Vocabulary)與「閱讀流暢度」(Word)這五個構面組成。並在2010的實驗中以生物學專業領域的學術文本作為指定閱讀文章，探討是否DIME Model也適用於特定領域的文章上。研究結果發現，先備主題知識、閱讀詞彙、閱讀策略與推論跟閱讀理解有顯著的影響。而沒有顯著影響的閱讀流暢度，可能是由於學術文章的重點與閱讀快慢並沒有太大影響的關係。

我採用DIME Model的架構來設計閱讀理解測驗，並依據Cromley等人的發現而捨棄閱讀流暢度的構面，僅以先備主題知識、推論、閱讀策略與閱讀詞彙這四個構面來設計題目。依照DIME Model的設計概念來看，只要檢測這四個構面即可推測出綜合的閱讀理解能力。

根據DIME Model題目設計的說明，配合我在實驗中的指定閱讀文章等實驗情境之後，四個構面的設計理念如下：

先備主題知識 (Prior topic knowledge)

• 測試受試者是否對於「遊戲式學習」、「科學教育」等該篇文章談論的主題概念有所誤解。
• 必須避免跟「詞彙閱讀」的題目相衝突。

推論 (Inference)

• 基於Hannon與Daneman (2001)發展出來的方法。
• 題目由固定形式組成：「A句」並且「B句」因此。再請受試者選擇A句到B句推論的正確答案。
• 每個答案都是正確的，但只有一個跟推論結果相關。

閱讀理解策略使用 (Reading comprehension strategy use)

• 測試受試者是否能夠使用閱讀理解策略，例如「摘要」、「預測」、「自我測試」、「先備主題知識活化」、「做筆記(例如圖表繪製)」、「圖文批配」。
• 設計題目時，需以另一篇類似的文章作為閱讀題目。另一篇文章為「黃國豪, 李玲梅, 王皓瑀, 洪珮菁, 吳佳茹, & 賴煖菱. (2010). 無所不在學習之系統建置與成效分析─以小學生認識校園植物為例. 數位學習科技期刊, Volume2(Number3). Retrieved from http://ijdlt.org/paper_info.php?pid=52043」，這是與實驗指定閱讀文章屬於同樣的期刊，表示審核門檻雷同。儘管摘要敘述方式與實驗閱讀論文不同，但是與大部分論文的摘要相同，足以作為代表。

閱讀詞彙 (Reading vocabulary)

• 測試受試者是否能理解「專有詞彙」跟「非專有詞彙」的意義。
• 題目設計為：列出一段敘述，在要測試的詞彙下畫底線，並要求受試者選擇跟這個詞彙最符合的敘述。
• 詞彙是選擇自重要的關鍵概念，但並不會在題目的段落中解釋。
• 必須避免跟「先備主題知識」的題目相衝突。

依照以上四個構面與設計理念，最後我設計出15題的閱讀理解測驗 (SkyDrive下載)。並在為期兩週的閱讀文章期間結束之後，於數位學習平台上進行限時30分鐘的測驗，測驗完成之後即進行統計分析。

測驗的評估方法

比起問答題的心得報告，選擇題的測驗較容易評估，不僅方法客觀、爭議性也較少。在此我主要參考了鄭湧涇(1998)的評量結果統計分析步驟：

1. 將試卷依得分的高低排列。
2. 由最高分向下取全部試卷數的27% 或三分之一，稱為「高分組」。
3. 再由最低分向上取與高分組相同份數的試卷，做為「低分組」。
4. 分別計數高、低分組，選答各試題每一選目的人數，記錄在「試題卡」(Test item card)上。
5. 計算各試題之「難度指數」，以百分比表示，其計算方法如下:

難度指數(P) = {[T-(R_U+R_L)]／T}x100

R_U :高分組答對該題人數

R_L :低分組答對該題人數

T :全部取樣人數，即高、低分組試卷份數之和

6. 求取各試題之「鑑別指數」，其計算方式如下:

鑑別指數(D) =（R_U-R_L）／(1/2)T

7. 評鑑每一試題的「擾亂答案」(選目)之有效性。
8. 將所有試題依其難度指數與鑑別指數值製作綜合分析表，並求出其平均值;綜合分析。

最後我再用庫李法(Kuder-Richardson method，1937)中的KR₂₀來評估內部一致性信度。但是必須說明的是，許多評估測驗評量的指導中並沒有說明他們是使用哪些數值作為計算KR₂₀的數據，到底是要用全部受試者的答題狀況、還是應該要像難度指數與鑑別指數一樣只取用高分組、低分組的答題狀況來計算，似乎較難以有所定論。可以確定的是，僅使用高分組與低分組來計算KR₂₀信度係數的結果會比採用全部受試者的結果還要高，也就是數字看起來會比較漂亮的意思。所以以下KR₂₀內部一致性信度係數我只有使用高低分組的受試者來計算。

閱讀理解測驗分析結果

19位受試者完成測驗之後，我就可以依據測驗結果來進行分析。

初步分析結果顯示整體難度指數為36%，比正常情況下的50%還要簡單很多，也不到理想的37.5%；整體鑑別指數為0.29，屬於不佳的試題，必須加以改進或棄卻(Ebel, 1972)；整體無效選目高達36.8%，也就是完全不會有人去選、一看就知道是錯誤的選目數量。而最後的KR₂₀內部一致性信度為0.56，在10到15題的小型題庫中算是可接受的範圍(林朝順等，2005)，但不算理想。

試題鑑別指數(D)的評鑑標準

D值	評鑑
0.40以上	極佳的試題
0.30-0.39	尚可的試題，可能需要稍加改進
0.20-0.29	不佳的試題，必須加以改進或棄卻
0.19以下	極差的試題，應棄卻

為了提高這份測驗的信度，參考Ebel (1972)的建議，將題目中鑑別指數等於或低於0.2的題目刪除，修正整份測驗。刪減之後題目數量從15題降至8題，整體難度指數提高到47.5%，屬於理想的程度；整體鑑別指數提高到0.6，屬於極佳的程度；無效選目降低到28.3%，KR₂₀內部一致性信度更是提高到0.77。

整體而言，修正後的測驗都顯示出較理想的狀況，因此我將之作為「測驗分數」來採用。修正過程簡單來說就是下圖：

閱讀理解測驗的詳細結果請看投影片：(SkyDrive下載)

閱讀理解分數處理

在實驗中利用兩種評量工具可以取得兩項數值：「報告分數」與「測驗分數」。我以Pearson相關係數再做分析，計算出r = 0.616，雙尾顯著性p = 0.005 < 0.01，屬於顯著的中度正相關，顯示這兩項數值都可以測量出同一種概念，也就是閱讀理解能力。接著我將兩項數值以比例的方式標準化，並取平均結合，得到最後的閱讀理解分數。處理方式如下圖：

整個處理過程的分數列於下表：

受試者 編號	修正前 測驗分數	測驗分數	評分者A 報告分數	評分者B 報告分數	報告分數	閱讀理解 分數
1	12	6	48	50	49	0.84
2	12	6	53	75	64	1
3	12	5	46	65	55.5	0.81
4	9	4	40	31	35.5	0.49
5	10	3	46	52	49	0.54
6	10	4	39	52	45.5	0.6
7	8	4	26	14	20	0.32
8	8	2	34	41	37.5	0.31
9	11	4	37	48	42.5	0.56
10	8	2	47	47	47	0.41
11	10	5	59	61	60	0.86
12	8	1	40	42	41	0.25
13	9	4	32	46	39	0.53
14	10	5	57	63	60	0.86
15	10	6	54	63	58.5	0.94
16	9	4	48	60	54	0.69
17	12	6	51	56	53.5	0.88
18	6	2	17	20	18.5	0.1
19	7	2	40	30	35	0.28

我將以上所有過程以投影片方式說明，投影片如下：(SkyDrive下載)

小結

這些資料都是我論文的一部分，但是在寫這篇文章的時候，我並不是抱著我在寫論文的心態而寫，而只是單純地記錄我是如何處理這些資料以及這之中遇到的困惑。實際上論文時可能會將一些無法解答的疑惑刪除、修飾，讓論文寫起來漂亮一點。

儘管為了我花了許多精力在蒐集文獻、規劃如何評估閱讀理解能力，但是平心而論，這並不能非常準確地說這樣子就能評估閱讀理解能力，只能說是盡可能地去得到受試者在閱讀理解能力上高低的量化數值而已。就如我內文所說的，這個研究並不是發展閱讀理解能力評估量表或是心得報告規範工具，在撰寫這份論文之中，我最多就做到這邊而已。

被迫採用這種不穩定的評估方式，最大的原因還是受限於實驗情境中，必須要配合課堂內容而選定文章。碩士生閱讀的文章不會是一般常見的泛用讀本，自然也難以有客觀、公正的評量工具。迫於這種情況下只能自己規劃，但這不管怎麼做都很難讓人真的信服。

最理想的解決方式還是換一個實驗情境、採用經過公開評量的工具，例如PIRLS(Progress in International Reading Literacy Study，促進國際閱讀素養研究)或是全民英檢使用的閱讀文章與評量工具，就能夠避免陷入這種窘境。

事實上，在之前的規劃中，我的確是打算採用PIRLS的文章作為實驗的工具。但是人算不如天算，在種種無奈與時間限制之下，我只能採用目前這種作法。然而換個角度想想，很多時候我們很難去創造一切盡如己願的環境來評估資料，像現在這樣能夠配合場域、情境即時地設計一個評估方式，說不定這才是比較貼近現實的狀況。變化並沒有錯，錯的是無法因應變化的人，我是這樣子認為的。

即使如此，我想我在評估閱讀理解能力的過程中，應該還是有些地方值得別人參考、使用，所以才將資料彙整、撰寫成這篇文章。希望能夠幫到大家的忙。

---

參考文獻

• Cromley, J. G., Snyder-Hogan, L. E., & Luciw-Dubas, U. A. (2010). Reading Comprehension of Scientific Text: A Domain-Specific Test of the Direct and Inferential Mediation Model of Reading Comprehension. Journal of Educational Psychology, 102(3), 687-700. 
• Keshav, S. (2007). How to read a paper. ACM SIGCOMM Computer Communication Review, 37(3), 83–84. 
• Bogucka, R., & Wood, E. (2009). How to Read Scientific Research Articles: A Hands-On Classroom Exercise. Issues in Science & Technology Librarianship, (59), 4. 
• John W. Little, & Roy Parker. (2010, Fall). How to Read a Scientific Paper. Retrieved November 23, 2010, from http://www.biochem.arizona.edu/classes/bioc568/papers.htm#evaluate 
• 黃桂芝, 曾憲雄, 翁瑞鋒, & 何筱婷. (2008). 採遊戲式學習教育平台之科學教育活動設計. 數位學習科技期刊, 1(1). Retrieved from http://ijdlt.org/paper_info.php?pid=27
• 余敏賢. (2003). 教育測驗與統計：重點整理. 高點致勝叢書系列 (五版.). 臺北市: 高點文化. Retrieved from http://library.yfms.tyc.edu.tw/webopac/detdata.php?pagerows=15&orderby=BRN&qrow=1&brn=1031623
• James, L. R., Demaree, R. G., & Wolf, G. (1993). rwg: An assessment of within-group interrater agreement. Journal of Applied Psychology, 78(2), 306–309.
• 徐晓锋, & 刘勇. (2007). 評分者內部一致性的研究和應用. 心理科学, 30(5), 1175-1178. Retrieved from http://cnki50.csis.com.tw/kns50/detail.aspx?QueryID=3&CurRec=1
• Statistics and SAS Package, School of Physical Therapy, National Taiwan University. Retrieved January 20, 2011, from http://www.pt.ntu.edu.tw/hmchai/PTcomputer/hSAS/SAScontinuous/SASicc.htm
• Shrout, P. E., & Fleiss, J. L. (1979). Intraclass correlations: uses in assessing rater reliability. Psychol Bull, 86(2), 420–428.
• 庄主. (2009, May 17). 如何选择Intraclass correlation coefficient (组内相关系数) 的模型？ - Windows Live. Retrieved January 20, 2011, from http://zjz06.spaces.live.com/blog/cns!3F49BBFB6C5A1D86!1228.entry?wa=wsignin1.0&sa=753480086
• 吳明隆. (2009). SPSS 操作與應用-問卷統計分析實務 (二版三刷). 台北: 五南.
• 鄭湧涇. (1998, September 18). 科學學習成就評量：II.評量結果的統計分析. Retrieved December 27, 2010, from http://140.122.143.143/doc/evaluate3.htm
• Kuder, G. F., & Richardson, M. W. (1937). The theory of the estimation of test reliability. Psychometrika, 2(3), 151–160.
• 林朝順, 鄒國英, 劉正耀, 胡彼得, & 楊育純. (2005). 醫學系筆試多項選擇題品質分析. 輔仁醫學期刊, 3(4), 213–220.
• Ebel, R. L. (1972). Essentials of educational measurement.

(more...)

論文進度報告(2010/7/11)

先來講一下進度報告好了。一樣地用一張表講完目前進度：

類別	應完成	已完成	已完成百分比
Model	100	54	54%
View	73	0	0%
Controller	9	0	0%
總計	182	54	29.7%

這是程式寫作到第21天的進度，已經完成了1/4，而核心的Model部分也做完了一半，可喜可賀。

不過現實層面是預定的專案進度是做不到了，所以日期必須往後順延。程式寫作的時間從15天延長到45天，可能到8/24才能有展示可以看了。詳細的資料就請上KALS Wiki去看囉。

強大的Collection

最近又學到Collection跟Iterator的技巧，跟上次的進度報告中提及到的Generic Object(其實也沒講到多少) 搭配使用之後，便可以應用到一般Model中許多常用的類別。

Collection(集合)是一種陣列的強化版本，不僅可以做到原本陣列大部分可以做的事情，還可以控制集合成員(members)的變更，並且實作延遲實體化(lazy initialization)的技巧。搭配Iterator之後，Collection還可以放進foreach去跑。只能說是好用到一種令人感動的境界，而且其實許多類別都是一種Collection，當初我太小看Collection這種工具了。

除了參考原本書中介紹的Collection來撰寫，並讓他擁有Iterator的功能之外，我又將之進化成一些特色類別，並組成我自己的toolkit。以下隨便介紹，看不懂很正常，反正一般只要知道有八成的類別都可以拿來套用這些toolkit就對了。

Generic Collection

 

將Generic Object作為成員，並設定預設載入的資料表與成員類別，可以對集合的成員進行Update的動作。

Generic Attribute Collection

 

繼承Generic Collection，並將Generic Attribute Object作為成員。叫做Attribute的原因是通常這種集合是附屬於某個主物件底下，作為額外的屬性。例如Annotation會有很多額外的feature(特徵)，而這種屬性都會附帶有「type_id」，然後還有一些特性。

Generic Association Collection

繼承Generic Collection，並預先載入指定資料表中關連的資料表的資料，並且能夠修改指定資料表的關聯內容。

Benchmark Fever!

如果眼睛很尖的人，應該發現到開頭那張Unit Test的擷圖中多了一個項「Benchmark Time」。Benchmark是測試速度或是評分時常用的技術，CodeIgniter有著強大的Benchmark功能，可以記錄任何程式執行時所耗費的時間。因此我把它結合到CodeIgniter的Unit Testing當中，以便分析每一項測試所需要耗費的時間。當耗費時間過久時，該項測試可能就有些問題囉。

再搭配CodeIgniter的Application效能分析，就可以自動捕捉到多項細節資訊。包括URI字串、使用類別/方法、記憶體使用狀況、基準測試(benchmarks)、GET資料、POST資料、以及資料庫查詢的各種語法。特別是資料庫查詢的細節，光靠這個就能找到許多無效或錯誤的查詢，而修改許多錯誤。

由於之前寫到Annotation_scope_collection時，發現效能異常地慢，於是試著把Benchmark加入Unit Test，並從中找出最有問題的測試點來改善，最後才抓到不能一直依賴CI->load->library()來當做include_once讀取類別這個問題。改善之後我可以看到執行速度大幅縮短，然後我又試著加入Cache的機制，結果速度又縮短了0.x秒，實在讓人很開心。於是一不小心就會沉迷在改進程式以縮短執行速度這個挑戰極限的樂趣中。

現在幾乎每種測試都能在1秒之內跑完，其實不要慢得太誇張，差個0.x秒也就沒什麼大礙了。

本來想草草地寫，結果也寫了好一段時間。那這次就這樣啦，詳細進度可以追蹤我的噗浪，來繼續寫下一階段。

(more...)

論文壓力很大嗎？快來問我論文進度到哪邊吧

研究所念到二年級，最近很流行的話題是：「你的論文寫到哪邊了？」

政大圖檔所要畢業需要有兩個條件：學分修滿、畢業論文。要寫畢業論文也沒這麼簡單，首先要通過資格考或投稿發表才能夠進行論文計劃書，計劃書要找三位評審委員(包括自己的指導老師)進行口試，通過之後才能繼續進行研究。計劃書通過在六個月之後，才能進行畢業論文口試，一樣要找三位評審委員，審查之後再進行修改、繳交，這樣才算完成畢業論文。

在兩年畢業的時程上，現在我們同學已經在準備10月底申請計劃書口試，估計大概11月到12月就能口試完畢。因此，在同學間最常聽到的就會是「你的論文進度到哪邊？」「終於要開始寫第三章了。」「找文獻好難喔，又沒有時間看。」「每次meeting時壓力都好大，老師都改好多。」

為了各位同學著想，我想如果把我的現狀列一下、讓你們比較比較，也許可以減輕你們一些壓力。

---

「我這學期修11學分」

在圖檔所每學期限制13學分的狀況下，我修11學分已經是跟學弟妹差不多的狀況。修的課程為：「檔案學研討」、「知識組織與資訊取用」、「研究方法」、「資料探勘」，其中前三科是必修，而大部分都是有很多報告、課業壓力跟剛入學的學弟妹相比是差不多的程度。

對於有先修的同學來說，他們大概修三到四門課。對於跟我一樣是圖資相關科系直升的同學來說，他們只要修一門課。

圖檔所修課課程規劃真是太偉大了。

「我還在做教育部計畫」

聽說之前楊老師以為我論文都已經寫完了，而王老師也以為我在拼論文。秉持著以誠待人的精神，我在暑假時我帶教育部計畫助理、整理實驗室跟所上電腦設備，直到最近還是在寫DSpace的擴充功能 (最近幾天應該會把這個功能寫上來)。

如果你想問「教育部計畫不是有專任助理嗎？」那這之間錯綜複雜的程度，我想坐下來喝咖啡喝一整天應該都講不完，而且我寧願把時間放在解決問題上。

「我在meeting時，也一直都是報告計畫進度」

跟著陳老師meeting也快要兩年了。

第一年時作頂尖大學計畫，下學期稍微有讀幾篇paper，也快樂地唸了點書。

第二年的現在，我還在教育部計畫裡面，作瑣碎事情。

是的，就跟Blog標題一樣，我正在朝著不是畢業的方向無奈地急速狂奔中。最近連聽課的時候都還在寫程式，頁首那幾張就是程式的memo。

大家都覺得自己壓力很大的情況下而不淌這種混水，那就我來淌吧。儘管不被老師們、助教們認同，不被同學、朋友們理解，這也是我在目前的現況中所能找到最好的解決方案了。

「老師，我想作研究，我非常想作研究。」

來到研究所最大的樂趣，就是感受到了研究的魅力。我開始認識到別人是如何從原有的狀態當中找出新的知識、創造各種可能性，然後讓這個世界更有趣。

作為一個程式設計師，我只是寫出別人想要的系統、程式；作為一個圖書館員，我只是處理著例行事務，或是編著編不完的書。但只有作為研究員，才能到處去尋找、開發可能性，並用自己的雙手去實現這個可能性。

我不甘心讓自己在還沒體驗到作研究、投稿發表的樂趣之前就離開這個環境。

我為在課堂或實作中發現的有趣研究議題，卻因為作不完的計畫、所務而沒有時間去做感到遺憾。

我對於這個不能正視資訊設備與系統管理的重要性、以及對資訊人才不重視的環境感到失望。

我已經聽膩了「這能提昇你電腦的功力」、「coding等級會提高」、「出去之後會比較好找工作」的這種無關痛癢的安慰詞。把學生拿去作電腦維修員、程式設計師或是系統管理者這種出去業界也會做的事情，對讓他能夠成為研究者的幫助，到底有多少？

能夠專心投入在論文上，老師也在指導你們寫論文(而不是作計畫)的同學們啊，你們不覺得很幸福嗎？

---

最後一個是：

「同學，作研究真的很快樂、很幸福的。」

蔡老師常說讀書很幸福，但我覺得作研究也很快樂。

當很多人因為經濟因素、家庭因素而不得不出社會討飯吃、在職場中奮鬥的時候，我們不僅可以讀書、吸收新知，而且可以只為了找尋那可能不賺錢、大家都不重視的一種發現，而投入所有時間精力去作研究、作實驗。

看著同年齡的同學已經在職場中奮鬥，自己卻能夠在課堂、報告、程式中徜徉而不事生產，我常為此感到羞愧，到現在都還沒能準備回饋父母。

但能成為研究生，能在這種不為利益、只為知識的環境中學習、作研究、寫論文，是非常幸福的！

一起快樂地作研究吧，共勉之！

(more...)

論文進度報告(2010/10/10)：幾乎完成工具列

繼上次的進度報告之後又隔了兩個多禮拜，最近也是一直在研究JavaScript的基礎技術，然後一邊在Blog把整理好的東西寫出來，希望能給一同鑽研JavaScript的程式設計師作為參考。評估各種寫作方式並訂定之後，就是繼續兩個禮拜之前停頓的進度，而繼續把工具列的部分完成。現在工具列只差「通知」功能尚未實作，但這是要等標註功能實作之後才會有通知，接著才是繼續完成這部份的功能。接下來就是要整理標註功能的UML了呢，又是一項大工程。在這之前，先來整理目前的論文進度吧。

目前的WebApp端的進度

元件	預估程式數量	已完成	UML類別圖
toolkit	17	17	1
core	15	13	1
kals_window	6	6	1
kals_toolbar	30	24	2
kals_text	38+?	0	3
search	6+?	0	1
統計	112+?	60 (53.5%)	9

整體來看，目前完成了大約一半的程式。由於使用物件導向架構開發，每個細節元件都是取用於toolkit或core中的上層元件，在開發同時也會不斷地改良這些元件，因此系統開發的速度會越寫越快。當然，這只是理論上而已。

也許會有人注意到類別程式的數量跟之前比起來有所減少，從之前的114降低到了112。我嘗試簡化系統的功能跟開發的方式來讓整個專案能更快完成，目前是將「自訂外觀」、「個人相片」的功能取消，暫緩適應小螢幕的功能調整(toolkit設計時有考慮小螢幕，但不一定每個功能都能適用就是)；而開發中也只對關鍵功能設計單元測試，並且緊對Firefox進行測試，Chrome、IE、Android則在未來有機會時再進行統一的檢查。

上圖是kals_toolbar中navigation的UML類別圖，這是工具列上各個視窗的功能設定。其中灰字的類別則是暫停開發的類別。詳細的UML類別圖，請參考KALS Wiki。

至於專案時程仍暫時維持在19天後完成，也就是10月29日。能不能完成我也沒把握，只能說盡力而為而已。

一改再改的JavaScript物件導向繼承寫作方式

一開始我的JavaScript是用最原始的prototype繼承法，但是由於這種方式在使用上會有些問題，而且我需要使用上層類別的方法，所以又花了一段時間回頭找尋相關資料學習。

首先學習到的是call跟apply的用法，但是發現到JavaScript仍有傳址問題存在，所以又把所有的屬性與方法寫在類別的建構子裡面，不過那將會造成系統資源大量消耗的問題，不得不再找尋新的方法。

接著找到的是Dean Edwards的Base繼承類別，他的確是很好用，寫法簡潔明瞭、又有呼叫上層類別方法的this.base()可使用，但是我使用的Aptana Studio看不懂，而我另外又試用了五六種JavaScript IDE，一樣是看不懂。儘管我後來找到讓Aptana Studio能夠理解的Base繼承法，但是最後仍毅然決然地使用最原始的prototype繼承法。

這是因為我在找尋這些方法的期間，學習到了prototype利用call、或是經典的base方法來呼叫上層或甚至是其他類別的方法來繼承並覆寫，讓prototype的寫法有了更多彈性，而能夠滿足系統的需求。儘管寫起來是比Base繼承法繁雜許多，但是由於prototype繼承法容易分析，許多JavaScript IDE都能理解，也是JavaScript程式設計師應該要知道的基本功課，這是我最後選用prototype繼承法來開發的原因。

這段期間不僅是一直翻閱相關資料、測試方法的優劣，還把系統的所有程式改寫了三次之多，著實非常地花時間，但也因此學到了不少東西。

重新檢視單元測試的必要性

在撰寫toolkit跟core的時候，我會要求自己盡量撰寫單元測試，並且最好是能夠測試到所以功能，也就是要求高「測試覆蓋率(Code coverage)」。上圖是core的UML類別圖，其中橘色的小註解標示著這部份的系統有設計單元測試的意思。小小的15個類別裡面，就有7個單元測試，力求核心元件要穩定。

過於繁雜的單元測試

上述在核心的工具時還可以做，到後面設計UI時，設計單元測試就越來越麻煩。我是用setTimeout來設計成機器人的方式，利用jQuery去選擇物件來點選元件或輸入資料，用以測試功能是否正常運作。但是這個機器人也常常做出一般人沒辦法做到的功能，導致測試的水準是比實際上更為高。舉例來說，原本使用者不可能點到某些隱藏起來的按鈕，可是用jQuery去點就可以點到、使用者必須等待視窗關閉並開啟之後才能執行下一個動作，可是jQuery就是無視視窗開閉來進行動作，導致他找不到下一個視窗的功能。也許是我設計單元測試的方法不對，但目前這樣做的確是很累，也顯得不切實際。

總結以上，簡單來說有兩個問題：

1. 設計單元測試比設計元件本身還花時間，頗有本末倒置的情況發生。
2. 單元測試不見得切合真實手動操作的情況。畢竟UI設計不像之前的計算用或存取用的程式這麼單純。

因此有必要重新檢討單元測試的必要性。

選擇重要的功能設計單元測試

仔細想一想，不需要全部功能都進行單元測試，去拼那個「測試覆蓋率」實在是很浪費時間與精力，只需要針對重要的功能設計單元測試即可。具體來說，針對具有以下兩種條件的功能來設計單元測試最為實用：

1. 關鍵功能：千萬不能出錯的功能，當然要用單元測試確保他的正確性。
2. 多道手續：與其說是在意其正確性，不如說是檢查時因為手續太多很麻煩，不如設計成單元測試的機器人讓他自己跑出的目標功能，再看看哪裡有問題，可以省下許多手動操作的時間。

也就是說，即使很重要的功能，但是如果很簡單就可以手動進行測試，或是其他測試中已經會使用到的功能，那麼就不需要刻意地撰寫單元測試。

程式要經過測試才算是完成。我仍然堅持這個最低底線，但現在並不強求一定要設計成自動的單元測試，即使是手動測試也可以算是勉強及格。

缺乏多人合作的遺憾

寫著寫著來講一個額外的小故事。

有天晚上回到宿舍的時候，發現室友學弟的位置旁坐著另一位學生。

學弟是資科所的學生，研究題目是跟雲端相關，當然也是寫程式的工作。看起來他應該是跟他同學兩個人正在趕一個系統，我偷偷地瞄到了phpMyAdmin的介面，兩台Mac筆電外加一個外接螢幕通通擺在桌上，旁邊還有喝到一半的五十嵐珍奶，看來晚上是要熬夜拼進度了。

老實說，我很少與人一起分工合作地寫程式。教人寫程式的經驗很多，但是可以像學弟他們那樣，「那個帳號登入的部份就拜託你了。」「OK！」地將一個系統分成幾個部分、再各自完成的經驗則是相當地少。不過架伺服器的各功能分工倒是有的，教育部計畫的時候，但那畢竟是功能調整，不太像是寫程式的這種「創作」。

我知道這種分工合作經驗的重要性對於程式開發來說並不亞於技術知識，大型的、有價值的系統是無法、也沒有時間讓我自己一個人完成，而我知道這正是我的弱點。至今我仍然是一個人在寫著程式，就像是現在正在做的碩士論文一樣。

儘管如此，我也在學著讓自己的程式「更好讀」、「更容易讓人使用」。像是建立嚴謹的物件導向架構程式讓人方便使用、遵守PHPDoc、JSDoc、cssdoc這種具有標準規範的註解讓人容易閱讀、利用UML跟網站草圖讓人理解整個系統，使用甘特圖與Wiki共筆工具來模擬多人合作時的專案互動。

我希望我能夠有資格與未來的夥伴一起合作開發一個大型的系統，所以我要加油，嗯。

結語

現在最令人擔心的是，19天後到底能不能完成系統呢？即使系統完成，後面還有好多後續的動作要做，多到讓人現在不想要面對的事情。能在這學期畢業嗎？能在明年3月之前如期把論文交給國中圖嗎？問題實在是太多了。現在還會有人問我要不要繼續念書，還是去當兵，還是要去當資訊替代役，但是現在能不能畢業都不知道啊XD

總之，每天都努力地繼續寫程式、寫Blog記錄，努力地向前進吧。

題外話，國慶日當天寫進度報告真是格外值得紀念？

(more...)

論文進度報告(2010/8/29)：UML再開

兵荒馬亂的過了兩個禮拜，現在繼續進行進度報告。

UML也可以用來寫JavaScript，而且意外地好用

上一次的進度報告中提到我寫JavaScript寫到打結，一不小心就把一個物件的責任切割到三個程式裡面，讓整個程式非常地複雜。回頭去看原本做的UML，卻與實作的方法有很大的差別，於是毅然決然地捲起袖子，停止程式撰寫的工程。又回來重畫UML。

加入Toolkit

這次最主要的是加入了許多Toolkit。把撰寫PHP時學到的Generic Object應用到現在撰寫JavaScript上，就可以歸納出KALS_user_interface跟Event_listener等常用且重要的工具。

整理core、toolbar跟window

有了Toolkit的這些類別之後，我就能將之套用到其他類別上。

 

首先是整理core圖片，原本的UML如上圖，這是包含了KALS_context跟KALS_util的部份。

經過修改過後，你可以看到UML變得複雜很多。不僅利用了框線的顏色、背景的顏色來辨識各類別的特性，也使用紅色(未完成、處理中)、藍色(完成)來區別工作的進度。

這次也把屬性與方法做了權限的區分。公用權限(public)沒有標示，私用權限(private)前面加入「_」，保護權限(protected)前面加入「_$」。其中保護權限是特別為了指名是給繼承物件使用，或是請它覆寫的指示。這樣子在何時要使用哪種方法，即使沒有JSDoc標示也可以非常地清楚。

接著又整理了Toolbar跟Window的部份，這樣子大概可以算是一個大階段。然後先進行程式的撰寫，以檢視這樣子的UML是否合宜。

由於目前UML整體變動的非常快，KALS Wiki中我只會上傳UML規劃的檔案，並沒有將每張圖片一一上傳。

釐清類別之間的關係

由於JavaScritp的類別之間關係複雜，不釐清的話，對於後續開發會有很大的問題。

繼承關係應該是最容易釐清的一種，本身沒什麼問題。

問題最大的是上圖的「組成」(Composition)，以及「聚合」(Aggregation)的差別。

在閱讀UML書籍時，就有提到組成是比聚合更為強烈的關係。但是書中並沒有寫上程式碼，到底有多強烈我也不知道。後來參考了(原創) association,aggregation,composition有什麼差別? (OO) (UML) (C/C++) 這一篇的說明，我才知道組成強調「同生共死」，上層物件建立時，被組成的下層物件也是跟著建立，上層物件結束時下層物件也跟著結束；而聚合則是「同日生，不一定同日死」，上層物件建立時跟著建立下層物件，但是上層物件結束時，下層物件還是可以活著。

儘管JavaScript依據瀏覽器的記憶體回收機制(garbage collection)，在物件結束時似乎都不需要手動去做變數的移除等動作，但是強調各物件之間的「組成」關係，仍可以讓JavaScript的結構看起來完整許多。

這是kals_toolbar，也就是工具列部分的類別圖。可以看到各個類別一層一層地組成複雜的結構……而且還會繼續調整！

嘗試建立UML輸出成JavaScritp的程式，但失敗了

我使用的UML塑模工具StarUML有提供程式碼產生器(StarUML Generator)的功能。除了C++、C#、Java能產生較完整的程式碼之外，還可以安裝範本(Template)來產生PHP程式。

儘管當時撰寫PHP的時候，由於實作時與UML有不小的差距，不能直接從UML來產生。但這次畫JavaScript的時候，我就比較仔細地規劃、加入各種說明，甚至到了看UML就可以想像JavaScript程式碼會是怎樣的程度。

因此，這讓我興起了想要使用程式碼產生器來產生JavaScript程式碼的念頭。如果這可以完成的話，就能夠省下至少1/3的程式撰寫功夫。而且維護UML比維護整個JavaScript容易得多，也對未來的程式開發有莫大的幫助。

StarUML建立的UML檔案其實是純文字的XML格式檔案，也就是說，只要懂得XML Parsing的技術，要剖析UML並轉換成程式碼是可行的。於是我參考PHP的Template撰寫方法，以及「利用 StarUML 產生一個簡易的PHP類別」的說明，挑戰將PHP的Template修改成JavaScript的版本，並自動加上完整的JSDoc。

原本我以為StarUML的Template寫法只是使用單純的JavaScript程式語言(沒錯，Template就是用JavaScript為主體來寫的)，但挑戰的過程中，發現他使用到了許多StarUML自定的物件。儘管StarUML提供了API文件，但是摸索中卻四處碰壁，網路上也沒有什麼相關的教學。

而要用剖析XML的方式來輸出UML，又發現工程浩大。光是理解UML檔案的組成格式都要花很多時間的，更別說剖析、轉換、輸出這之間的過程不知道要花多久來做測試。

最後只好作罷。乖乖地看著UML的圖片，一字一字地Coding吧。

這讓我學到一個教訓，下次要找一個輸出功能比較強大的UML塑模工具才是。下次吧。

由UML觀看專案進度

由於這次好好地整理了UML，於是開發進度就有了比較明確的依據。大致上可以整理如下表：

程式已完成	11
UML已整理類別	73
UML未整理類別	36
整體進度	11/108 (10%)

其中，UML裡未整理的類別表示整理之後可能會有更多的類別出現，因此整體的分母數字肯定會再增加。

而整體的專案進度也可以分成四個階段：

1. 核心 core

包含工具庫toolkit、

核心core，這兩張類別圖。

他們是全部系統都會使用到的重要類別，所以撰寫時格外地用心。不僅JSDoc寫得特別仔細，也時常需要回頭修改此處的類別。

2. 標註工具列 Toolbar

包含工具列kals_toolbar、

視窗kals_window、

工具列導覽視窗 navigation等三個類別圖。

上述的UML是已經整理過後的，所以目前是照著這些UML類別圖一步一步地撰寫程式碼中。

3. 標註 Annotation

包含kals_text、

annotation_editor、

annotation_list這三個類別圖。

這是標註工具的實作部分，可說是本系統最大的賣點。但是房屋必須要從根基開始做起，這個較為末端的工具，到目前仍還沒有好好地整理。但是如果吸收上述兩個階段的經驗再來修改此處的UML的話，我想應該會學習到更有效率的作法吧。

4. 搜尋 Search

包含search這張類別圖。

搜尋功能大部分應用到了上面各階段使用到的功能；或著反過來說，在各階段時都會用到搜尋功能，只是在此階段中特別會把使用者介面UI做出來而已。

這階段算是收尾，可有可無。

Dropbox建立版本備份

Dropbox是一個知名的雲端線上檔案同步服務，不僅跨平台(Windows、Mac、Linux，甚至各種手機都支援)，免費帳號就提供2GB的空間，還可以透過邀請來增加到最多8GB的空間。

(備註：如果有好心人士想要玩一玩Dropbox，請幫我點此邀請連結吧，感謝！)

在閱讀電腦玩物的「Dropbox Folder Sync 打破Dropbox限制，同步任意位置多資料夾」跟「Dropbox 今天救了我一命：已刪除檔案救援與舊版本資料還原」之後，我又再度拾起Dropbox來使用。

原本的Dropbox是不錯用，可是限制只能同步一個資料夾這點，就讓他受限很多。這是由於我電腦上需要同步備份的資料夾分散各處，網頁系統要擺在XAMPP的資料夾下、文件會擺在文件的資料夾、Blog資料則是放在Windows Live Writer資料夾底下。如果要用原始的Dropbox備份方式，就得一個一個移至Dropbox資料夾才能備份。

但是現在有了Dropbox Folder Sync，他可以透過軟連結(symbolic link)的方式來將您需要的資料夾加入Dropbox中。詳細的運作還是請參考電腦玩物的介紹吧，再此就不再複述。

因此我就可以利用Dropbox備份位於各個不同位置的資料夾，包括kals標註系統的主要網頁資料、Windows Live Writer Portable、以及各種文件等等。

更重要的是，Dropbox在備份的同時，也做了各備份時間的版本控制。對我這種常常在修改系統的狀態來說，哪天一不小心改錯了、刪掉了某支程式時，就可以利用Dropbox的版本控制來還原！

其實我原本是使用Google 協作平台(也就是KALS Wiki)來做版本控制。但是KALS Wiki只提供100MB的空間，而且版本也要自己上傳，使用上還是諸多不便，不如Dropbox設置好之後就自動同步備份來得好用多。

如果看到這邊時，你也想要申請一個Dropbox來玩玩，請別忘了點我的邀請，幫我增加一點空間吧QQ 感激不盡！

捨棄RTM，改用Google Task

在之前，我使用Remember The Milk(簡稱RTM)來做為待辦事項的記錄工具。RTM有著清爽、好用的管理介面，工作的事項可以設定標籤、延期、多個筆記、網址、優先程度等多種彈性的資料。

RTM什麼都好，缺點就是要使用同步功能，必須升級成付費的pro會員，一年25美金。免費會員只能試用15天，而我也已經把這額度用完了。

最近開始使用Android，跟以往一樣底與Gmail相處愉快，就興起了改RTM用Google Task的念頭。Google Task推出到現在已經好一段時間了，但是他的功能還是非常基本。設定工作事項標題、詳細記事、加個到期日、完成/未完成，頂多可以跟Gmail與Google日曆搭配使用，此外就沒了。最讓我詬病的是，我覺得Google Task的介面又小又難用啊！

儘管試著裝了Google Chrome的Google Task相關套件，但也沒多好用。倒是讓我發現了Google Task的另一種全螢幕介面：Canvas View (就像上圖一樣)。看起來介面是好些，再學著Google Task的鍵盤快速鍵操作方式，修改待辦事項倒也是挺方便的。

至於Android上就是使用GTasks這套件。操作上挺方便的，按鈕又大又舒適，缺點是有點廣告，還有沒有自動同步的工作。還有很多東西我還需要研究一下就是。

為什麼同步很重要？

可能有人會好奇，為什麼同步功能很重要？這是因為我工作的場所不只一台電腦，甚至連手機也是我工作的地方。在路上走路、晚上睡覺時，我常常腦袋裡面都會想著論文相關的事情。像是程式寫一寫，走回去的路上才想到什麼東西沒有寫到，於是就會需要記錄的地方。

手機是我最常用來記錄的工具，這也是我選用智慧型手機最重要的理由。在以前使用RTM時無法同步，我是會將待辦事項記錄在日曆中，然後讓日曆跟Google日曆去作同步，再到電腦上手抄到RTM。當然，這樣的作法是很麻煩的。所以這也是我捨棄RTM的主要原因。

現在手機使用GTasks跟Google Task同步，雖然需要手動去按同步這點也是挺麻煩的、而且常常會忘記，但是操作上是比以前順手多，可以更有效率地使用「待辦事項」這種工具。

不在電腦前的時候，想著有什麼事情還沒做完，然後加入待辦事項；在電腦前的時候，依照待辦事項把它一件一件地完成。這樣子的工作模式也蠻令人安心的，不用一直擔心有什麼忘記了、或是沒做到。

專案進度再調整

……是的，距離原本預定可展示標註系統的日子，已經經過7天了。就如上面的報告所知，實際上系統到完成還有很長一段距離。很遺憾的是，又要再度延後專案進度了。

不過這次因為更熟悉UML規劃，所以進度拿捏應該是更為準確才是。

總之，Coding的時間延長到9/21(二)，也就是中秋節前一天為止，大概還有22天。詳細的專案進度，請看KALS Wiki。光看甘特圖上的時間，Coding就用掉了66天，而且噗浪上面的CODING日記還已經計到64日了。時間過得還真是快啊，永遠都覺得時間不夠用orz

結語

由於這次畫UML的時候是比兩個月之前隨便畫還要用心許多，開始照著UML來撰寫程式的時候，也相對地安心了許多。我不用再記著三個不同的程式是如何運作、他們到底是怎麼相依的，這些問題都在構思UML的時候已經釐清，這可以讓我更專心於把一支程式寫好，而不需要煩惱太多事情。

我認為這種安定感是很重要的。這讓寫程式壓力不會很大，寫程式的風格也會依據UML而統一。甚至誇張一點的來說，就算不同人、只要有點程度的程式設計師，就能夠照著UML寫出統一風格的程式。這對於多人合作的專案尤其重要，儘管這次我是自己一個人來進行，但是不同時期的我其實都算是不一樣風格的程式設計師，因此仍是獲益不少。

缺點大概就是偶爾會把自己當做是打字機一樣，只是把UML畫的圖打成JavaScript程式，因此感覺到有點無聊這樣而已吧XD

這次的論文進度報告其實還有很多議題沒有講，因為有些議題感覺獨立開一篇，對需要的人來說會比較有用，所以這篇就差不多到此為止了。儘管是這樣說，但洋洋灑灑也寫了三千多字，用了一個晚上與一個上午的時間來寫，也是很花時間的啊orz

(more...)