:::
針對查詢「論文進度報告」依關聯性排序顯示文章。依日期排序 顯示所有文章

我的論文寫作工具:XMind心智圖

布丁布丁吃布丁

我的論文寫作工具:XMind心智圖

10. 核心架構圖

心智圖是一種將概念、想法以連線組織起來的筆記法。比起用手繪的心智圖,電腦的數位心智圖更具備容易組織、關連與整理的特色。這次碩士畢業論文我就是利用XMind心智圖繪製工具來撰寫論文草稿,然後再將草稿上的概念撰寫在Word中,成為長篇大論的碩士論文。

以下就跟大家分享我利用XMind來寫作論文的過程吧。


心智圖繪製相關工具

這邊要先介紹三種工具,第一個是桌上型電腦用的XMind,第二個是Android手機用的Thinking Space,第三個則是對桌上型電腦與手機檔案同步的SugarSync。

桌上型電腦的心智圖工具:XMind

image

XMind是繪製心智圖的一項工具,他是基於Eclipse的框架,以開放原始碼的形式開發,可以在各種Windows、Linux、Mac等各種平台上運作。個人使用的時候是免費的,而付費購買的Pro版本則有甘特圖、腦力激盪、簡報等各種功能,但是個人版本其實就已經很足夠使用了。

跟另一項知名的開放原始碼心智圖繪製工具FreeMind比起來,XMind介面更美觀、容易使用。但相對的,XMind也比較佔記憶體資源,使用過久的話也可能會當掉。對我現在用的電腦來說,XMind運作起來還蠻順利的就是。

Android手機上的心智圖工具:Thinking Space

image

有些時候就算不在電腦前,也可以拿起Android手機來規劃論文的草稿。我每天吃飯時走路上下山、通勤時坐公車,很多時候並沒有電腦使用。在電腦前面時,我容易專心作一件預定要做的事情;但是離開電腦,在外面走路、等待時,我反而比較容易思考「要做些什麼」的規劃。

其實手機特別適合用心智圖來記錄事情。因為手機難以長篇大論地打字,小螢幕也難以顯示複雜、大量的資訊,心智圖以關鍵字、概念、可開關的結構來呈現,特別用來記錄事情可說是格外地合適。

Android手機上可以使用的心智圖工具很多,其中Thinking Space是我用起來最好用的一款。他不僅能夠整合XMind格式的檔案,操作起來也與桌上型電腦版的XMind大同小異。Thinking Space跟XMind部分圖示有點差異,但是常用的數字、進度、驚嘆號、問號等圖示都是共通的。

必須注意的是,在手機上操作Thinking Space時卻異常地耗電,使用上需要非常地謹慎,不然可能寫一寫手機就沒電了。

Thinking Space免費版的限制中,除了比較沒啥影響的廣告之外,最麻煩的就是不能使用「超連結」功能將節點指定連到網站或某個檔案位置。即使開啟了擁有「超連結」的XMind檔案,Thinking Space也會把「超連結」刪掉。而付費版的Thinking Space Pro則沒有上述限制。

由於我寫論文到中後期會在XMind心智圖上加上超連結,以方面快速參照到某個檔案,因此我後來也改用了Thinking Space Pro作為寫作的工具。

電腦與手機的同步工具:SugarSync

image

手機改完的檔案要傳到電腦上,而電腦中寫一寫也想要放到手機中繼續寫。以前我們會用隨身碟、FTP來傳輸資料,但現在我們可以用檔案同步工具、透過網路來進行異機(電腦與手機)的同步!

SugarSync是類似Dropbox的檔案同步工具,提供跨平台資料同步功能,各檔案最近五個版本的差異記錄,也可指定要同步的資料夾,免費使用就有 5GB的空間,可以藉由推薦與付費來加大空間。

SugarSync並沒有Dropbox知名,版本差異備份的功能較弱,但是不像Dropbox只能限定在My Dropbox資料夾中同步資料,SugarSync除了類似My Dropbox的Magic Briefcase資料夾外,還可以直接指定要同步的資料夾。

此外,由於我在Dropbox中保存了許多東西,我不想要把手機的空間弄亂,所以我決定另外使用其他的檔案同步工具,就是這個SugarSync。免費使用有 5GB的大小,對我的手機8GB記憶卡來說也差不多。

每次修改過電腦或手機的心智圖檔案之後,我只要連上網路,執行SugarSync的同步,SugarSync就會確認檔案的更新日期,自動進行上傳、下載、覆蓋的動作。因此我可以確保這些檔案是維持最新版的狀態,以避免遺失寫過的內容。


使用XMind寫論文

我用XMind來輔助論文寫作上可以概分為五個階段。首先是主要利用XMind心智圖來撰寫草稿,然後在XMind中整理草稿,接著參考心智圖來撰寫論文的文章、了解文章撰寫的進度,再以心智圖追蹤論文的改版與最後的統整。

1. 概念研擬階段
  • 安裝電腦與手機的心智圖與同步工具,配置檔案同步環境
  • 以Thinking Space為主,電腦為輔

話說,當我要開始寫論文的時候,剛好碰上了春假前夕。這時候我大部分時間是在外面行動,並沒有電腦可以操作,所以我決定利用Android智慧型手機的功能,在手機上開始撰寫我的論文。

首先我先在電腦上安裝了XMind Portable,在手機上找到了相容於XMind的Thinking Space軟體。試用過多個檔案同步服務之後,最後我決定選用SugarSync,並在電腦端與手機端都各別安裝SugarSync並以相同帳號登入,以便連上網路時就能夠進行同步。

20110421220637

首先我將論文各章拆成各個部分,建立多個XMind檔案,包括論文的架構、格式、論文正文以外的其他資料之外,就是緒論、文獻探討、研究方法、系統、研究結果與分析、結論等章節。這除了因為單獨檔案過大會造成難以編輯的困擾之外,手機因為記憶體不足,也不能開啟過大的XMind檔案。

各章節的分類也只是個大概而已,其實原本只打算寫六章的我,後來因為系統太大,所以也拆開成為二個獨立的章節來撰寫。

20110205 1 緒論

這時候的心智圖只是個概念的列表。儘管各節的順序通常是已經明定而不需要猶豫的,但各節裡面要寫些什麼,此時則是以關鍵字或簡短的敘述來記錄。例如「研究目的」的部份,我只寫了「發展」、「驗證」、「探索」三個關鍵字而已。

20110407182739

在手機上操作Thinking Space的時候就如上圖。在這個階段就是盡可能地把想要寫的概念記錄起來。由於手機打字並不順,所以我也不想在手機上寫上太多字,反正之後回到電腦上會再進行重整。

20110407183138

我也會同時搭配「圖示」的功能,幫每個節點加上順序、進度、驚嘆號或問號等圖示,就能夠以簡單的形式來記錄我想要的概念。

2. 概念重整階段
  • 以電腦工作為主
  • 輔以手機修改

當前面概念研擬階段中把每章要寫的內容都擬定出一個大概之後,接下來我就要把這些概念重整,作為撰寫文章前的準備。

論文的章節寫作順序

附帶一提,我是以每一章為單位來撰寫,而章節與撰寫順序各別是:

  1. 第一章 緒論
  2. 第三章 研究方法
  3. 第五章 研究結果與分析
  4. 第六章 結論
  5. 第四章 系統介紹
  6. 第二章 文獻探討

最後才是將每一章統整。

這個順序並沒有一定,不同領域跟不同老師的指導方式也許會有所不同,但我覺得一章一章地寫應該是還蠻合理的作法。其中,大部分的人都會把系統介紹放在研究方法之前,可是我的研究目的之一在於發展系統,所以把系統挪到研究方法之後。寫到最後稍有修改,第四章 系統介紹被拆成二章來撰寫。

重整的詳細程度

這個階段到底要整理到多詳細呢?讓我們先看看「第二章 文獻探討」初期的心智圖:

20110216 文獻探討

我整理的時候,根節點是「章」標題,底下的子節點則是「節」標題,並標上順序數字。節底下如果有分成小節,則再標上順序數字以表示這是一個標題。然後將節點加上「電燈泡」與「驚嘆號!」等圖示以區分用意,並重整順序。這張心智圖裡面有些「問號?」圖示,表示這是上一階段中想到需要補充的資料。

在重整順序、加上圖示、順序數字之後,我就會試著將模糊的草稿寫得更具體一點。

20110216-6文獻探討

這張圖則是整理之後的文獻探討。每個節點要細到能夠具體地想到每一個段落要怎麼寫,以方便我可以重複檢查這一章的邏輯是否流暢、正確,這樣才能安心下筆寫作。

圖示

表示需要搜集或不確定的圖示

在這個階段我大量地使用圖示來標示心智圖的節點。在XMind中文版中翻譯成「圖標」,但我覺得還是「圖示」比較適合。我常用的圖示包括:

  1. 順序數字:用來標示「節」或「小節」的寫作順序
    image
  2. 「燈泡」寫作概念:抽象的一個概念,這是要寫入文章中的一個想法。
    image
  3. 「驚嘆號」寫作注意事項:寫作時可以參考其他來源,或是其他特別要注意的事情。
    image
  4. 「問號」需要補充:目前手邊資料不足,需要再補充的部份。
    image
  5. 「附件」圖表資料:在這邊要加入圖表。
    image
  6. 「刪除」不採用:這個節點及之下的節點都不採用,平時保持關閉,等有需要時再來開來查看。
    image
超連結的節點

參考檔案加入超連結

同時,我也在心智圖中加入了參考資料。參考資料中的節點通常附有超連結,指定到電腦中的實體檔案。必須注意的是,如果用免費版的Thinking Space來修改加上超連結的心智圖時,心智圖中的超連結就會消失喔。如果使用Thinking Space Pro版本就沒這個問題了。

3.0不能相對連結

原本超連結只能以「絕對式」指定硬碟中的位置,如果檔案位置更改的話,那超連結很容易就會失效。在XMind 3.2.1版本中已經可以將超連結指定為「相對式」,只要XMind心智圖檔案跟被連結的檔案相對位置不變,超連結就不會失效。這也是後來我升級到3.2.1版本之後才發現的功能,當時我只是呆呆地指定絕對連結就是了。

不採用的想法

不採用的想法

在重整的過程中,往往會捨棄部分寫得不好的概念。比起直接刪去這個節點,我通常會額外建立一個類似資源回收桶的節點,命名為「不採用的想法」,並加上「X」image 表示不使用,平時讓他保持關閉的狀態。

當我有要刪掉的節點時,我就會直接把它挪到這個「不採用的想法」裡面。如果未來我發現我又要這個想法時,這時候就能把它從「不採用的想法」裡拉出來了。反正一個節點也佔不了多少檔案空間,保持關閉的狀態也不會妨礙版面,對我來說這是一個很有用的小技巧。

3. 文章撰寫階段
  • 以Word撰寫為主
  • 參考XMind心智圖

前一個階段將XMind心智圖整理得差不多之後,接下來就是要把它寫成論文的文章。

這個階段就是參考XMind心智圖來撰寫文章。如果心智圖夠詳細的話,文章寫起來會很順、很快,還會加入許多當初心智圖沒有納入的資料。但如果寫一寫覺得很卡、轉得很硬,那可能就是當初心智圖沒有整理得很好,我會再回去重整心智圖。

寫完之後,我就會將該章的檔案寄給老師,請老師幫忙檢查。

任務完成比例

圖示各節進度 整張心智圖

我通常會用「任務完成比例」圖示來標示目前做到的進度。「任務完成比例」圖示是一個方形的餅圖,有Start (0%)、25%、50%、75%、100%、暫停等六種圖示的差別。

專案管理裡面會建議我們把專案事項以具體的視覺化方式呈現出來,讓執行者知道已經完成了多少、還有多少沒有完成,這有助於專案的控管。我把這種想法應用到論文上,用「任務完成比例」了解自己撰寫論文的進度。

制定撰寫規則與格式

制定規則跟格式

因為我是打算分章撰寫多個檔案,最後再統合,所以有必要制定撰寫規則與格式,以求得整篇文章的統一。基本規則都是參考張保隆、謝寶煖(2006)的「學術論文寫作: APA規範」來制定,不過在撰寫文章的時候,我還會一邊以心智圖寫下額外的規則,包括檔名、存檔方式、章節範本之類的注意事項。

4. 改版追蹤階段
  • 以Word修改為主
  • XMind心智圖記錄版本
  • 以RTM輔助記錄零星修改

老師檢查完的文章通常會有很多建議,而我必須參考老師的建議來改善論文的內容。

老師的修改

Word修改圖片

我跟老師之間的論文校對全部都以Word檔案進行。老師會將他認為應該要修改的地方以紅字標示、或用刪除線表示要刪掉的部份。不過很遺憾的是,老師已經忘記Word的修訂功能如何使用,所以這些標示都是手工加上去、需要手工去檢查的。

image

修改時,我並不是完全接受老師的意見,而是把老師的修改當做是一種改進的參考,很多時候都是看完老師改過的地方,然後我再整個重寫。當然,重寫時也是納入了老師的建議。

各章版本記錄

統合版本記錄

我通常把老師寄回來的檔案另存一個校對完成新檔,然後把上一版修改前的資料也存成一個新版本檔案,參考老師的校對完成檔案,來修改新版本檔案。而這之間來來回回建立多個版本的檔案,我會以心智圖的超連結來記錄,以方便查閱。

以RTM輔助記錄要修改的地方

搭配RTM

有些章節改了一些規則、用詞之後,就必須回頭去修改其他章節。這些細微變更的待辦事項,我使用RTM+Astrid的待辦事項來處理。再撰寫文章時,有要修改的地方就記錄在RTM中,稍晚再處理;待要處理其他章節時,就參考RTM的列表進行修改。

RTM待辦事項較沒有心智圖這麼有組織,只是零星的記錄,適合輔助像是修改細節這種瑣碎的工作上。

我一直想等有空時好好介紹RTM+Astrid的待辦事項組合,請等待下次吧。

5. 論文統整階段
  • 以Word統整為主
  • 以RTM輔助零星修改

校對通常是到二校就差不多。而各章都會重複步驟2到步驟4的內容,直到所有章節都撰寫完成,就進入最後的論文統整階段。

雖然理論上只是把各章的Word檔複製貼上到同一個檔案去,但因為各檔案的樣式有所不同,還要把標號進行重整,並且避免表格被分頁切斷,所以調整起來也費了一番功夫。

image

在統整時,也會參考之前規劃的論文格式部分的心智圖,把主要章節內文之外的其他資料補充進去,像是摘要、目次、表次、圖次。其中公式目次後來發現大家都沒人使用,所以我之後把公式目次刪掉了。

統整之後,我會再請老師檢查看看。這樣才算是完成整個論文。


論文草稿心智圖

這份論文寫到最後我總共建立了11張心智圖。

我在撰寫論文的時候就常常將心智圖輸出成PNG、記錄在Plruk上當成日記,所以上面介紹中有許多都是來自於當初在撰寫時的心智圖。

接著我想把心智圖最後的樣子在下面作個記錄。這心智圖與論文內文並不是完全相同,有些錯誤也在論文中直接更正。心智圖大概在4. 改版追蹤階段之後就沒有再修改過了。

以下全部的心智圖可以點選此連結下載,僅供參考。必須注意的是,心智圖中有許多部分加上超連結連到特定的檔案,而這其實是指我電腦中的資料,如果你把心智圖下載到你的電腦去的話,應該是找不到對應的資料才是。

1. 論文架構

1. 論文架構

這是整個論文的核心心智圖,連結其他心智圖之用。

2. 論文格式

2. 論文格式

記錄論文主要文章之外的其他資料。

3. 第一章 緒論

3. 第一章 緒論

4. 第二章 文獻探討

4. 第二章 文獻探討

5. 第三章 研究方法

5. 第三章 研究方法

6. 第四章 知識標註學習系統

6. 第四章 知識標註學習系統

7. 第五章 知識萃取機制

7. 第五章 知識萃取機制

8. 第六章 研究結果與分析

8. 第六章 研究結果與分析

9. 第七章 結論

9. 第七章 結論

10. 核心架構圖

10. 核心架構圖

這是與老師討論論文最後結果的架構圖。

11. 論文摘要&投影片

11. 論文摘要&投影片

最後論文完成,要撰寫摘要與規劃口試時要報告的投影片內容。


結語

註解功能

當初用心智圖的時候,其實沒有使用到「註解」的功能。「註解」可以在一個節點裡面放入長篇、有格式的文字,用在蒐集文字資料上非常方便。我後來才發現這個功能,不然有些論文資料就不需要以超連結連到外面去,而是直接就能夠用心智圖來整理。

我的論文寫作草稿工具:XMind心智圖

自從利用心智圖撰寫論文之後,我也開始用心智圖來規劃Blog要寫的內容。這一篇就是這樣子規劃出來的。一開始,這個心智圖也一樣是在手機上以Thinking Space繪製,然後在電腦上補充需要的資料,最後再用Windows Live Writer把它寫完。

感覺上這樣寫Blog會比較踏實,結構也比較完整,比較不會想到什麼寫什麼、亂無章法。但是實際上在寫的時候,還是不會像寫論文一樣咬文嚼字,寫起來還是挺隨便的XD

總之,就當做寫日記一樣,總算是把用心智圖寫論文的過程作個交待了!

(more...)

meeting就是要上台報告

布丁布丁吃布丁

meeting就是要上台報告

這次meeting有學長姐上台報告。

在大學時代同學們視之洪水猛獸的報告,在這邊是很平常的功課。我也覺得應當如此,雖然我自己到目前為止還沒做過令人滿意的報告,排除掉推甄時用背的上台做自我介紹之外。

學長花了十分鐘左右講述他在網頁標注學習的進度以及survey了Greenstone跟Dspace的感想,大概就是跟老師報告一下。雖然並不是很嚴謹的報告,不過要讓沒有用過這系統的我們來看,已經是獲益良多。

下一位學長則是報告了老師交待他做peer-review(同儕評閱)的期刊投稿論文,他把paper一頁一頁地解釋這是在幹麻,然後提出他認為適合跟不適合的想法,最後在整理成結論。那篇paper被批評的狗血淋頭,雖然說經學長這樣說明之後就連我也看得出這哪裡不恰當,但是事實上我現在的實力還是停留在比那篇paper還差的程度...

接著另一位學長報告他讀的paper,總覺得用wifi做讀者定位、協助書單搜尋與查找這個領域應該是有不少人玩過了,上次聽老師說去大陸那邊看他們圖書館直接用書車做RFID定位,自動算出最短路徑做上架的動作,這個不是完全把這篇paper比過去了嗎?

然後學姊報告了一下百年圖書館史的工作進度,學姊整理的個人工作計畫書看起來還蠻完整的,比我在那邊空想要怎麼寫的來得漂亮得多,現在正在等學姊寄給我。另一個沈寶環教授圖書館的報告我就沒有力氣繼續聽了,於是出來透透氣。

每次報告結束之後,老師都會針對報告的內容做說明。陳老師還以資訊領域為著眼點,這次幾次聽下來,也大概能知道老師會想看什麼東西,而連帶的學長在報告的時候,也是把paper的重點著重在技術、實驗等層面上。我大學時期聽的報告主要是在邱老師的質性研究上,邱老師注重質性研究方法上的嚴謹性,陳老師則是很在意實作技術的內容,這些都是研究者應有的概念吧。

總覺得學長姐的報告,是把他們所知道的事物,用投影片排個順序及標注重點,然後就可以在台上侃侃而談。在短短的時間內,把自己所知所學告訴大家,讓大家一同成長。我期許自己也應該要有這種能力。而且這樣聽報告的過程中,也的確對自己有不小的刺激,花上兩個小時來政大meeting算是很有收穫的。

不過,這次報告的內容很多深入技術層面的名詞。即使經過解釋,大概會對這名詞有個概念,但是那種陌生感所帶來的挫折還是很強烈。會後跟學長聊天中,因為知識與認知上的落差,在溝通時也不是這麼順利,頗有鴨子聽雷、孤立在大家之外的落寞。

就算很明白這是環境轉換過程當中的不適應感,也知道其實不用勉強自己要懂他們純資訊領域的知識 (雖然用PDA的WIFI做定位再搭配情境學習的確很有意思,但是我還是比較想學習web basing的技術) ,不過還是無法擺脫壓力帶來的迷惑與失落感。這十足地影響了自己結案報告的撰寫動力,雖然聽報告的刺激也為結案報告的形體有了不少貢獻,這到底是好還是不好呢......

總之,這3個多小時的meeting實在是非常累人,尤其是投影影像畫面過小,眼睛盯著小小的字,看久了會容易疲憊與頭痛,再這樣下去說不定我也要戴眼鏡了。

今天本來打算早點睡,心得重點稍為提一下就帶過去,到最後還是寫了這麼多。算了,來睡。

(more...)

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

布丁布丁吃布丁

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

image

距離上次的進度報告,已經間隔了半個月。這半個月之間去了兩次法院、提出了附帶民事訴訟、帶朋友在台北繞啊繞、整理備份電腦,所以其實也沒推進多少進度。

這次的進度主要是完成了Model的Class Diagram,以及Webpage Application(簡稱WebApp)中大概50%的View的Class Diagram(關於專有名詞的定義,請參考KALS wiki詞彙表)。在規劃View之前,我也利用Pencil先畫了幾張網頁藍圖,像是這篇開頭的那張圖就是利用Pencil畫得,很像以假亂真的程式吧?XD 目前WebApp的藍圖皆存放在wiki當中,請點此進入觀賞

以上進度的投影片如下:(SkyDrive備份)


畫圖畫到大翻修

image

畫到View的時候,會發現很多需要再修改的地方。舉例來說,上圖Annotation View Window就是後來跑出來的想法。這是為了讓標註可以寫很多,又不限制於一定要在小小的Annotation Box,而能夠顯示在獨立視窗中的折衷方案。這個改變足以讓整個View跟Model都要大翻修,所以目前進度又得延後了。

此外,像是權限設定的規則也多了不少限制,讓流程簡化,但一些功能又得再改過。


專案進度確認

image

也就是說,View的製作過程又要往後延期。事實上他已經延期了一次,這是第二次的延期。整個工作時間擴大到兩個禮拜,也就是大概還要一個禮拜、6/9才能完成。

image

這次專案管理的甘特圖中,我把系統實作的部份又區分得更為詳細。大致上可分為Webpage Application、Administration Application與作業系統實作這三個部份,而當Webpage Application作完之後,就可以開始邀約實驗參與者的動作。這樣排下來,專案還是會在1/25左右畢業。反正就認了吧XD

那麼接下來就是修改網頁藍圖,然後繼續修改View的Class Diagram吧。加油!

(more...)

寫書初稿完成!

布丁布丁吃布丁

寫書初稿完成!

 

image 我現在是研究所三年級下學期,很多人會問我什麼時候畢業,我都這樣回答:「先寫完書,再來寫論文。」而到今天為止,總算是把寫書初稿跟附件光碟全部完成了!

寫書至今已經一年了,可是我好像沒有在這裡好好談談寫書這件事情。所以在寫書初稿完成的今晚,我就好好地來報告一下寫書的由來與經過吧!


關於本書

這本書的書名定為「DSpace開放原始碼數位典藏系統建置技術彙編」,是由陳老師訂定的,雖然我覺得有點饒舌,但也不失學術風味,似乎也不錯。這本書是由陳老師帶領的實驗室底下的助理、學生約12人共同撰寫,其中我規劃了本書內容、製作附件光碟的DSpace-DLLL'、並撰寫了部份章節。

本書是為了讓需要建置數位典藏系統或是數位典藏教學需求而撰寫,讀者可以從本書第一部份學習數位典藏的相關理論,接著第二部份是附件光碟DSpace-DLLL的操作介紹,而第三部份則介紹三個由DSpace建置而成的數位典藏。DSpace是一個開放原始碼的數位典藏系統,而我將之重整規劃之後,成為一個容易安裝、操作的附件光碟,而且一樣以BSD條款發行供大家使用。

本書從2009年4月初制定架構到2010年4月中初稿完成,目前已經交由陳老師審查、校稿,老師正在尋求出版商,並希望能在這學期結束之前出版,以便趕在下學期上課時使用。

本書全部共15章,初稿Word檔案的頁數總共380頁。最後出版時可能會採用比A4更小的紙張,因此頁數會更多。各章概要請見下表:

本書章節標題 內容摘要
第一部分 數位典藏導論
第一章 數位典藏概論 介紹數位典藏的各種定義,釐清讀者對數位典藏的概念,並引領讀者認識數位典藏的相關計畫。
第二章 數位典藏專案規劃 介紹數位典藏小組需要的成員構成,並從後設資料與系統分析一步一步地規劃數位典藏專案的步驟與細節。
第三章 網站資訊架構 介紹數位典藏資訊系統網站的組織架構原則。包括組織系統、標籤命名系統、導覽系統、搜尋系統、後設資料與控制詞彙等支援元件等。
第四章 後設資料Metadata 說明後設資料的原理以及重要性,並介紹數位典藏常用的後設資料規格與其他參考資源。
第五章 數位資源格式 介紹典藏品數位化與原生數位資源的差異,並解說圖像、聲音、視訊、文件等各種類型的數位資源格式。
第六章 電子資源授權與權限控管 介紹電子資源的授權方式、各種不同的授權條款、以及數位典藏系統的權限控管的規劃建議。
第二部分 數位典藏系統DSpace實作
第七章 DSpace介紹 介紹DSpace的背景,並帶領讀者瀏覽DSpace各種特色功能與網頁使用介面,並介紹以DSpace進行的相關數位典藏應用。
第八章 系統安裝與設定 詳細介紹DSpace安裝與設定手續,讓讀者能夠利用自己的電腦架設DSpace。
第九章 資料內容組織架構 介紹DSpcae的資料內容組織架構架構。從社群、類別、文件、檔案集到檔案各層級與管理的介紹,讓讀者能夠學習如何制訂典藏的數位內容。
第十章 使用者、群組與權限設定 介紹如何建立DSpace的使用者、群組,以及權限控管的設定。
第十一章 遞交作業與工作流程 介紹DSpace中設計與建立數位典藏獨特的遞交作業與工作流程,其中遞交作業還涉及後設資料規範的設定。
第十二章 系統架構與版面修改 剖析DSpace的系統架構,並說明如何閱讀DSpace使用的Java程式碼,然後教導讀者修改網頁使用介面。
第三部分 DSpace數位典藏建置案例
第十三章 臺灣大學數位典藏 介紹臺灣大學數位典藏計畫發展歷程,包括以DSpace修改而成的臺灣大學典藏數位化計畫入口網站以及各種加值應用。
第十四章 臺灣百年圖書館史暨數位圖書館先導計畫 介紹由政治大學圖書資訊與檔案學研究所策劃的「台灣百年圖書館史」。詳細地描述數位典藏專案的各個程序,以供讀者作為規劃的參考。
第十五章 教育部全國通識網課程資料庫 介紹由教育部全國通識網底下的子計畫「課程資料庫」的建置成果。全國通識網課程資料庫含括典藏完整數位課程資料的優質課程資料庫與集合國內各大專院校通識課程資訊的通識課程基本資料庫。

寫書的由來

認識我的朋友們都知道,我這個學生最不像學生,老是接了一堆很奇怪又不賺錢的工作在在身上。從進研究所之前我就接了「臺灣百年圖書館史暨數位圖書館先導計畫」,作到碩一下告一段落,這就是我開始碰DSpace的起源。當時對DSpace不懂,嚴格來說,我對撰寫DSpace的Java語言也不熟。而且DSpace用了很多進階程式技巧的設計模式、將物件導向的優點發揮得淋漓盡致,也很靈活地運用MVC架構、讓程式各司其職,但這些對於當時完全不懂的我來說,要控制DSpace著實讓我花了不少時間與精力。在自我摸索、讀書、不斷地嘗試錯誤之後,我也逐漸能夠掌握DSpace系統。

然後政大圖檔所在2008年暑假舉辦了數位典藏實務與加值服務研習班,這個研習班中也用了DSpace作為教材。當時不僅先幫各個學員預先用虛擬機器安裝好DSpace就已經讓我在實驗室待了好幾個晚上,到教DSpace內容資料架構與metadata遞交表單的設計時,太過複雜的操作方式幾乎讓所有學員都舉了白旗投降。

除了研習班的學員之外,王梅玲老師與陳老師也會在上課時使用DSpace來授課,尤其是王老師會要求學生利用臺灣百年圖書館史暨數位圖書館網站來上傳資料。由於DSpace原始的操作介面實在是很難讓人使用,學生們用起來也是不少怨言。

碩二時陳老師接了教育部「教育部通識教育資源平臺建構與永續發展計畫」,這也是用DSpace來架設課程資料庫與教師資料庫這兩個系統。當時我撰寫了許多教學用投影片教導專任助理們DSpace,並配合計畫需求大幅度地開始改造DSpace的功能。這段期間我在Blog中寫了很多DSpace相關的文章,主要都是給助理們用於計畫中。而作到最後乾脆我自己下海操刀,多媒體轉檔、瀏覽搜尋、管理介面的操作工具等許多功能陸續開發出來。

大概是在碩二下學期時,陳老師提議撰寫本書,而我也覺得這是一個不錯的構想。在歷經各個計畫、授課等經驗之後,我看到了許多需要數位典藏系統的人們。有人需要一個可以用來架設用於機構、計畫使用的數位典藏,有人需要一個可以用來教課、讓學生邊玩邊操作的系統,而我則是有能力將這些需求匯整成一個實際可以用的系統、而且我也希望能將這些年來的成果以一個詳細且實用的方式發佈供人使用,於是就開始了整個寫書的工作。


寫書的經過(前期)

從2009年4月初老師提起這個想法之後,就由我來負責實現。以下聊聊一些令我印象比較深刻的經過:

一開始是制訂整本書的規劃與架構時,還有考慮文學院機構典藏的介紹。但由於文學院機構典藏本身到最後不了了之,最後則刪去不做。

寫書初期時,理論部份有找老師的一位研究助理幫忙。但是該助理對於此主題不甚熟悉,工作效率低落也讓老師看不下去,最後放棄了。

寫書前期規劃好大綱之後,其實實際上並沒有什麼進度,大家都在忙著教育部計畫與課業。直到暑假時(約2009年8月後)學弟妹較為空閒,也有新的學弟陸續加入實驗室,於是正式地分配寫書章節給學弟妹與各個助理。

最先交稿的是第二章數位典藏專案規劃。但由於這個主題其實是相當模糊的概念,與學弟來來往往修改多次之後,在寫書後期才定稿。

原本第三章是談主題分析與檢索系統,負責學妹很快地整理好之後交給我。但是後來我才知道應該擺資訊架構較為合適,最後一整個改頭換面。

第四章後設資料匯整的速度很快,而且架構很清楚,即使寫書完檢查時也覺得很漂亮。負責此章的學妹非常厲害。

第十三章臺灣大學數位典藏也是很快就整理好了。負責此章的研究助理功力一流,資料豐富到讓我覺得擺在這本書裡面似乎有點小廟容不下大佛(?)。

第一章數位典藏概論也是很快就完成了。

至此本書進度仍十分緩慢,特別是第二部份幾乎沒有令人滿意的成果。在2009年末時我大學室友進來擔任計畫助理,這時我也逐漸推掉計畫的工作而專心在寫書上,寫書的進度開始推進。


寫書的經過(中期)

首先是第九章資料內容組織架構,儘管章節內容規劃得很好,但是我卻大幅度地修改了作者的撰寫內容。能熬過我整章全紅且註解一堆(而且寫得很直接orz)的專任助理,實在是非常辛苦,真是抱歉。最後第九章由其他人接手之後,修改多次才完成,算是第二部份最早完成的章節。

第十五章的撰寫也被我改了相當多,但由於負責的專任助理本身就有很不錯的文筆,熟悉我的敘述方式之後,一整章寫下來也非常易讀、好懂。

第十四章原本是由某位專任助理負責,但她整理的方式與效率較低,第一次交稿之後就沒有多大進度。後來交給另一位專任助理完成。至此第三部份大致上完工。

接著該助理著手撰寫學弟無法完成的第五章電子資源授權與權限控管,也很快地把零散地材料重新組織成具有可讀性的章節,組織資料的能力也相當地厲害。

再來是我自己負責的第八章系統安裝與設定。本章內容很好撰寫,但這是我大幅改善DSpace操作工具所帶來的成果。這期間強化了語系檔編輯器、遞交表單編輯、重新啟動Tomcat、電子郵件編輯。還經過陳老師學程上課的實驗,讓整個系統趨於完善。而同時附件光碟的內容也漸趨成型。

接著我進行第十一章遞交作業與工作流程的撰寫,一樣是基於發展了遞交表單編輯器的功能,才能簡單又清楚地把操作方式介紹給讀者。

至此為止,寫書的進度表中,完成的章節甚至不到一半而已。而此時卻面臨另一個難關:2009年年底兩位專任助理即將離職。不過這兩位離職之後仍被我纏著寫稿,真是夠辛苦的了XD


寫書的經過(後期)

第十二章系統架構與版面修改一開始由專任助理負責,但進度十分緩慢。直到2009年底新任教育部助理進來後,我重新制訂了該章大綱,並安排兩人完成。最後再由我統一修整之後完成。

第十章使用者、群組與權限設定在專任助理離職之後努力完成。這次不像第九章那樣修改很多次,而很快地進入完稿階段。

第七章DSpace也是在轉成助教的專任助理努力翻譯之後,交由我修整過後才完成。

這段期間另一位離職的專任助理被我纏著校稿校了好幾章,真是辛苦了。

在這個時間我毅然地決定將第三章改成資訊架構學,而捨棄原本完成的主題分析。原本請離職的專任助理撰寫,但因為他事務繁忙而放棄,最後我將之完成。

第二章數位典藏專案規劃中間隔一段時間沒有進度,然後也是在這段期間完成。

第五章數位資源格式,負責學弟由於事務繁忙,到最後才完稿。

而在初稿完成之後我就著手將附件光碟完工。在撰寫第八章時我就已經把附件光碟的大部分完成,最後則是修正許多安裝上的Bug、重新清理系統,然後燒錄成光碟。

這段期間我的工作就是寫書寫書再寫書,我的噗浪三不五時就是[寫書]文,然後每週或隔週就跟老師通信報告寫書進度。而到今天總算完成整本書的初稿與附件光碟了!

整理與老師寫書進度報告中,從2009年9月14日正式進度報告開始到今天2010年4月17日為止,總共報告了19次。每一次報告由於都會有大量附件,所以得分成多封寄出,Gmail的信件對話串已經長到讓人難以點閱的程度。不過還好有這個進度報告,讓我整理上述的經過時方便許多,也算是一個寶貴的日記吧。


為什麼要寫書?

很多人會問我,其他的研究生都在寫論文,為什麼我在寫書?就算都已經碩三下學期了,都已經延畢一年了,為什麼我還是在寫書?為什麼不要先畢業再來寫?

又有人會問,寫書出版可以賺很多錢吧?版費多少錢啊?做出來的系統可以賣啊,賺大錢。

一開始我會回答說,因為要趁著專任助理還沒離職之前趕快把書寫完。不過在他們離職之後,他們還是被我纏著繼續寫,可見這個理由不太合理(XD)。

我也不會贊成畢業之後再來寫,因為畢業之後要當兵,不碰觸這些東西之後,我一定再也無法把他完成。

書或系統能賣多少錢?這也不是我在乎的問題。事實上,只要這些初稿完成,再怎樣也能找到出版商將之出版成書,所以我不太去煩惱這種問題。

此外,這本書會以多作者的方式出版。老師的名字應該掛第一個,而我的名字也會掛在上面,但其實第幾順位我也不太在意。畢竟如果這本書能夠幫助老師升等,那對實驗室的學弟妹也會有莫大的幫助。

 

我只要能夠出書就好了。

 

以一個還是學生的身份,能夠出一本能在書店裡買得到的書,甚至還能提供給其他學生當教材,或是讓相關領域的專業人員作為參考工具的書,我覺得這是一種自我滿足的成就。

有些人抱有「用機車、腳踏車或甚至走路環島」之類的目標,他們不太在意這到底能不能賺錢、能不能對自己未來有所幫助,只是單純地想要完成這項成就,而我也是如此。他們在畢業後、就業前的空檔進行這個計畫,而我則是在畢業之前、手上握有大量資源與人力的時候進行。

 

當然,我很清楚這個選擇是基於夢想的任性,而不是一種對於現實的理智。

在寫書這段期間,我不計利益得失、也不在乎花費的時間長短,只是努力地讓這本書更豐富、更好閱讀、更容易使用。也許在旁人的眼中這是很笨的行為,而我也很清楚這是事實。這段期間我沒有像其他畢業的同學一樣去工作賺錢,父母還要支付學費給學校。而實驗室內被我佔據的這個角落也一直沒有讓給新進來的學弟妹(雖然我覺得應該也沒人想要坐這邊XD)。老師等著我的標註系統,好多人都在等著我畢業,而我一直辜負著他們的期望。

換個角度來看,這可說是身為學生的一種任性的特權吧。能夠任性地單純作一件自己想做的事情,我想除了現在之外,往後就不會有這種機會了。


寫完書之後

所以寫書告一段落之後,接下來就不會耍任性,好好地努力畢業了嗎?

這個答案可說是,也可說不是。

接下來的確會開始著手規劃論文的標註系統,進度也會在這邊報告。雖然最近可能還會用幾天的時間把寫書的資料整理收拾一下就是。但是由於我論文要寫的也是一個讓人使用的系統,而且這次是重頭開始做起,而在我對於系統相當要求的標準之下,也是需要花很長一段時間來讓論文趨於完善。

與其他趕著畢業而草草完成論文的學生不同,我將會繼續耍任性,任性地寫好論文再畢業。

就如這個Blog的副標題一樣:是的,我正在繞遠路。反正人生繞的路已經夠遠了,似乎也沒差這段距離。就讓我繼續耍任性吧。


很久沒有寫這種日記文了,本篇寫完耗時三個多小時,寫到手有點痠。

在待辦事項裡面還有好多篇Blog要寫,我可能在整理寫書資料的同時,一併把他們寫一寫。

這篇就這樣告一段落啦。呼~~有點累XD

(more...)

論文進度報告(2010/5/16)

布丁布丁吃布丁

論文進度報告(2010/5/16)

image

一週的時間飛倏地過去了,很快又到了本週報告進度的時間。

一如上週所說的預定事項,本週則是進行類別圖(Class Diagram)的作業。我在畫圖的過程中也逐漸修正自己對於類別圖的認識,並越畫越得心應手。根據擔任系統分析師的強者我朋友所言,我似乎已經進入到了強化分析的階段。詳細的細節請看KALS WIKI囉!

以下是本週報告時的投影片:(SkyDrive下載)


為什麼要用UML?這樣做系統會比較快嗎?

UML是一種統一塑模語言,簡單來說,就是一種描述系統的文件。透過UML,我可以描述整個系統的架構,並從中思考系統要怎麼運作。

老師在Meeting時有問我說,這樣做系統會比較快嗎?老實說,這通常不會比較快,特別是像我對UML不熟的這種半吊子。

系統開發的方法有很多,比較快速的敏捷開發法通常都是以發展雛型、改進雛型的方式進行。以往我習慣直接先開始寫程式,而不去作系統分析,或著是只有腦中作個粗略的分析而已。接著再從程式雛型不斷地去修改,直到完善。但那並不是一種好的開發方式,或著是說,那是開發方式難以讓人成長。

在繪製UML類別圖的時候,可以很明確地看到類別與類別之間的關係,進而讓我發現此時應該使用何種設計模式。而不會像以往埋頭苦幹許久之後,才想到當初應該使用設計模式的慘狀。能在UML時用上MVC、Factory、Collection、Iterator等設計模式,其實還蠻讓我覺得的確有些許成長的。

不過會採用UML的作法還有另一個理由,就是下面所說的。


實驗積極進行中!不過不是我……

本實驗室的學生很微妙地都變成了教育研究,也就是要找學生作實驗才能進行下一步。由於學校大概都是六月底放暑假,而在之前則是期末考,在這段期間中都不太方便進行實驗。換句話說,實驗通常是五月底或六月初之前就要做完,否則就要等到下學期初。

不知道是否是這個原因,近來兩位學弟都在差不多時期開始了他們的實驗。儘管準備過程中似乎困難重重,但還是祝他們能夠順利完成。

反觀我,即使系統完成了,實驗要進行還需要一段時間的前置作業。也因此很明顯地趕不上五月底、六月初這個時程。既然趕不上,那麼就好好作、仔細作,一邊繼續學些新的東西。這就是我用UML慢慢畫的另外一個理由了。


出書進度

本週meeting時,老師也有談到一下出書的進度。(註:由於現在書的工作進度已經交給老師去處理了,所以現在不是「寫書」,而是「出書」。) 老師提到了幾個需要修改的地方,包括數位格式的匯整表格、metadata的繪製方法(其實被我移到第二章數位典藏專案規劃那邊去了XD)、另外加入數位化作業一章之類的。大致上我之前也有考慮過那些問題,只是礙於時間、人力不足,最後捨棄不加。老師指出這些點,也就是老師有仔細檢查的一點證明。老師也辛苦了。現在出書時間似乎延後到暑假中再來進行,就隨意吧。


image

本週專案管理時程沒有什麼改變,所以不更新。

下週預定事項是繼續完成Class Diagram,加油囉!(喔!)

(more...)

看著前人的表演──group meeting

布丁布丁吃布丁

看著前人的表演──group meeting

今天有感而發,所以來寫一下我們group meeting的情況。

我們的meeting是每週一次固定行程,由於陳老師的學生一半是師大那邊的,所以我們是在政大、師大兩邊每週輪流舉行meeting。就如我之前敘述的,我們meeting的內容沒有很特別,只是大家要報告的都一起上就是。

雖然今天我跑去買晚餐而遲到了,不過我想今天老師應該還是報告12月的計畫狀況,並且敘述1月要幹些什麼。除了要申請計劃之外,還要舉辦一個尾牙聚餐活動,由於group meeting的時候大家都會在,所以像這種群體計畫的事情都會在這時候討論。

接著是學長姊們報告論文進度。大家都快要準備申請計畫書了,所以一打開畫面上都是好多頁的Word檔。學長姊們講述著自己的研究,然後老師會提出問題詢問。當他們在報告的時候,我試著把自己當做老師,找找看他們報告的內容是否有什麼問題點可以問的。當然,很多時候因為我不是很能了解他們的研究,所以就看不到問題在哪裡。同樣的,當老師質問他們的時候,我也會試著扮演他們的角度,去想說要怎麼回答、修改自己的論文。

接著是學姊的paper study,意外的是一篇實驗室內大家都耳熟能詳的paper,也是我進來之前老師實驗室對於英語數位學習所做的第一篇研究。學姊很認真地去研讀,然後提出了不少建議,也跟老師討論了許久。

因為有事情,所以中途就離開了。很遺憾沒辦法繼續聽到討論的內容。


在宴會、表演場合,人人都不想當第一位上台的人,而希望排在後面,然後照著第一位上台的人去作。

今天meeting的老師與報告的學長姊們,他們就是排在我前面表演者。所以我要專心地看著他們怎麼演,了解他們演出可以改進的地方,然後準備下一個自己的表演。

比起書上講的研究方法,meeting中討論的研究方法不是更為活生生、更實際的例子嗎?

所以,我敬佩在meeting時專心聽著台上報告的學長姊們,並期許自己能為台上報告的人提出建議、貢獻出一份力量。

嗯,不加油不行呢。

(more...)

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

布丁布丁吃布丁

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

2010-06-20_211446 進度報告

本週的進度報告很準時,這可能是最近大有進展、多到值得拿出來一說的樣子,那就一件一件地慢慢來聊聊吧。


越畫越複雜的Sequence Diagram

繼上週說的Sequence Diagram (循序圖),這次已經把該階段的作業完成。原本規劃是要畫4個流程,但後來畫到內嵌登入時,發現許多傳送參數與執行程序都可以重複使用,於是就把兩者和一。目前完成了「建立新增標註的過程」、「接受建議並修改標註」、「內嵌&手動登入」三種Sequence Diagram,詳細請看KALS Wiki

image

其中,第三張登入的複雜度,甚至已經分割成14張圖來表示,而且我還已經省略了View元件的初始化細節。這是由於KALS在初始化時需要經過很多步驟,登入取得參數、建立Domain與Webpage物件等工作都會在此時完成。換句話說,畫完此圖之後,大致上程式最根本的問題就差不多釐清,接下來就是程式寫作上的問題了。

多虧了Sequence Diagram的大整理,讓我回頭把Model跟Controller修了不少東西。一想到之後程式實作時,這些項目可能還會再改,我就沒有急著將之更新到KALS Wiki。事後也的確陸陸續續地修改了很多次。


KALS的程式實作計畫

完成了Sequence Diagram之後,接下來就可以開始進行程式實作了。但這次我也遵循著「工欲善其事、必先利其器」的態度,先來摸熟撰寫程式的各種工具。

KALS系統本身是採用PHP+PostgreSQL,使用CodeIgniter框架來撰寫。

PHP是大家耳熟能詳的網頁伺服器端程式語言,就普及性及開放性來說,我認為是時下首選。

PostgreSQL則是開放原始碼當中性能最強大的資料庫。儘管不如MySQL知名,但同樣能夠跨平台、更靈活的授權條款,而效能上也更為強大,其中全文檢索也是我垂涎已久的功能之一。儘管後來研究他全文檢索功能時,發現MySQL也有提供類似的功能。但我不喜歡MySQL編碼與無法商業用途的限制,所以仍堅持以PostgreSQL來實作KALS系統。

以上兩個其實都是很基本的程式語言與資料庫而已,但如果要讓自己的程式設計等級更上一層,就必須熟悉「框架」與「IDE」才行。

CodeIgniter Framework (框架)

image

CodeIgniter (簡稱CI)可能對學校剛出來的程式初學者來說比較陌生,但Ruby on Rails這名字沒聽過的話,你對網頁程式設計業界的了解程度可能不太夠喔。CodeIgniter是類似Ruby on Rails的框架,基於MVC架構,強調簡單、具有邏輯的結構、並提供豐富的函式庫。此外,CI背後有著EllisLab公司的支援,以確保這個開放原始碼計畫跟得上時代,而各種語言(包括正體中文喔!)的使用手冊也十分完備,在各種PHP Framework的效能評比中,CI也是數一數二的強喔!

雖然我沒有用過Ruby來寫程式,但看一看介紹,感覺上CodeIgniter就像是PHP版的Ruby on Rails差不多。事實上,CodeIgniter並不是學起來很「簡單」,而是撰寫程式時會讓它看起來很「簡潔」的一種框架。由於他有著許多固有的系統邏輯,除了MVC主要概念之外,還有libraray、helper、config等等各種細節需要去熟悉。就算是強大的資料庫控管功能Active Record Class,也跟PHP單純的mysql_query()有著不小的距離。要使用Framework,就必須先學習如何使用Framework,而這總是比純PHP還要複雜的一項額外作業。

另一個問題就是程式寫作的習慣。傳統的PHP是程序導向(procedure-oriented),到PHP4時逐漸有物件導向(Object-oriented)的功能,而PHP5時物件導向才大致完備。CodeIgniter則是用於PHP 4.3以上,相容PHP5的物件導向概念,這讓寫了兩年Java的我感到非常地不適應(還包括前一段講得那些架構,也都不太是單純的物件導向)。儘管CI這種方法是講求簡潔、快速,而我也承認Java純物件導向太過消磨程式設計師的耐性,但習慣這東西仍然不是一時能改得回來的。

更何況我學PHP時也是停留在程序導向的時代。當時function寫一堆,但遇到class裡面要用「$this」跟「->」就一整個不習慣。Java是使用「.」作為屬性或是方法的連接符號,而PHP是使用「->」;Java不太用「this」(儘管this有用處,但大多時候會省略),而PHP則是強制使用「$this」。而CI為了支援PHP 4.3,建構子仍然使用Class的名字,而非PHP的__constructor()之類的用法,這又跟我之前從書中所學有些不同。

請原諒我上面用了些程式設計師才看得懂的敘述來描述這些挫折,但我想這種無奈的感覺,大概也真的只有這個領域的人才能體會吧。總而言之,這一切的一切,都註定了我在實作前期必須要做好四處碰壁的心理準備。換句話說,不管怎麼寫,應該有八成都是錯誤的。

進階程式人員的利器:IDE

撰寫網頁程式的工具很多,有些人推崇使用具有所見即得功能的編輯器來快速設計網頁介面,包括DreamweaverNVU (這是開放原始碼的工具喔),但這是屬於前端介面的設計;有人也會用純文字編輯器Notepad++EmEditor (雖然對我來說,Dreamweaver也同樣是純文字編輯器就是),但是面對高度複雜的大型專案來說,使用單純的純文字編輯器可能就難以發揮良好效益了。

為什麼純文字編輯器效益不足呢?我簡單地舉出幾個理由:

  1. 沒有自動完成(auto-complete)的辭典:如果你寫程式時需要努力地翻找許多函式庫的使用手冊,你才能知道各種功能的參數及輸出型態的話,那你應該試著找尋具備自動完成的工具。儘管努力是件好事,但效率也太低了。沒有辭典的配合,也很難避免手殘寫錯函式名稱的情況發生。
  2. 沒有DOM或程式架構的導覽器HTML的Document Object Model或物件導向架構都是很有邏輯且方便的架構,但是在純文字編輯器當中是很難一目了然。我作過追蹤壓縮過的JavaScript程式碼的事情,那真是場惡夢,到最後也沒有什麼收穫。
  3. 追蹤專案中的程式:我以前使用EmEditor或是Dreamweaver的全文搜尋來找尋專案當中某個程式的方法,但我後來才知道,原來IDE早就能夠幫你把所有程式作連結、比較,這絕對比你搜尋字串還來得方便許多!

上述的功能都是現代整合開發環境IDE(Integrated Development Environment)中常見的基本功能。目前最知名的IDE應該是以Java為主要對象的Eclipse或是VB專用的Virtual Basic。其中,開放原始碼Eclipse具備的靈活架構,讓它可以整合PHP作為編輯對象,而具體呈現就是PHP開發工具計畫PDT。知名的PHP專用IDE商業軟體的Zend Studio也在5.5版本後推出了基於PDT的平台,可惜這是要付費的軟體,所以我並沒有使用。

一開始我安裝以Eclipse為基礎的PDTApatana,雖然他們都是很強大的IDE工具,但很遺憾的卻跟CodeIgniter不太和。如前面所述,我猜想這可能是歸咎於CI的物件導向沒這麼正規的緣故。不過還好,另一個知名的IDE NetBeans,則可以透過PHP Documentor來提供CI的支援!

IDE for PHP: NetBeans

image

感謝昇陽公司,原本商業發行的NerBeans現在也成為開放原始碼IDE的選擇。NetBeans主要用於Java,但跟Eclipse一樣地可以擴充支援PHP。另外它還支援以PHP Documentor撰寫的註解,讓我們只需要增加幾行註解,就能夠讓NetBeans解讀CodeIgniter的架構!

image

上圖就是NetBeans在能夠剖析CI架構之後所提供的自動完成功能。當你輸入方法名稱開頭幾個字時,NetBeans已經幫你帶出了CI相關的方法,並且基於PHP Documentor的註解格式,提供了包涵用途、參數、資料型態、回傳資料等說明。

由於NetBeans與PHP Documentor搭配是如此良好,撰寫專業風格的註解不再只是讓人看了自我感覺良好的工具,而是真的可以派得上用場的實用資訊!因此我現在也是一邊參考PHP Documentor的寫法,一邊為複雜的程式加上註解。

當然,NetBeans的自動完成提示不僅包括PHP,連JavaScript(包括jQuery,只要NetBeans看得懂)、CSS、還有PHP Documentor的格式都能夠聰明地告訴你喔!在此讓我誇張地來形容一下從純文字編輯器跳到NetBeans的差異,就像是從費力地騎腳踏車變成開賓士輕鬆出遊的爽快啊!


滿頭包的程式實作

在畫完Sequence Diagram之後,我稍微地統計了一下Model、WebApp部份的View跟Controller,看看它總共需要幾支類別。答案是總共182支。而從三天前開始程式實作到現在,我確實地完成的程式,只有2支。

除了上述提到的理由之外,我也嘗試熟悉PHP Doucmentor並製作NetBeans的樣板,以加速後面的開發作業。這次我也試著應用從極致軟體開發eXtreme Programming學到的「單元測試」精神,利用CI內建的單元測試類別來撰寫對應的測試工具。

2010-06-19_114940 unit test

上圖是單元測試的結果畫面。單元測試是一種最簡單的測試方法,輸入程式運算出來的結果,以及你預期應該要有的結果,如果兩者相符(甚至是資料類型相符),那麼測試就Passed,否則就是Failed。而我把每支程式比較難以確定正確性的功能都設計對應的單元測試,只要單元測試All Passed,那麼我也就可以差不多確定這支程式沒有問題了!

儘管一開始困難重重,許多的不熟悉帶來了巨大的挫折感,但同時「學習新事物」的新鮮感卻也讓我對這種挫敗甘之如飴。與之前程式寫作的經驗比起來,我感覺到自己明顯地逐步成長中,而這種成長的體驗也是讓我擁有在這個世界上活著的依據。

就讓我繼續在困境中狼狽地掙扎、跟絕望快樂地相處、然後繼續走到走不動為止吧。


專案進度與報告投影片

image

這次的專案進度中,我加入了幾個查核點,包括「可展示系統完成」、「可開始配置實驗資料」、還有「預官入伍(1/17)」(汗)等。預定本階段系統實作(coding)的時間會到7/12(一)。那時候好像是有些學弟妹的口試時間,我想我還是會去聽聽他們口試的。詳細的專案進度,請看KALS Wiki吧!

而本週報告的投影片也非常精簡,這是顧及了學弟妹需要報告實驗分析結果所作的取捨,所以只是簡單地報告我大概作什麼事情,以及進度規劃而已。


(SkyDrive下載)

自從昨天寫程式寫到整個Windows XP終於壞到無法正常進入Explorer之後,我毅然決然地改用學校提供的Windows 7。在經過一整天的兵荒馬亂,到了今天晚上才把整個Windows 7設定大致抵定。儘管Windows 7的使用體驗也是有很多值得聊的,但我赫然發現這篇寫到現在已經破三千字了。想看一看我在用Windows 7時發生什麼事情的朋友,只好請你們去看看噗浪這一篇吧。

經過一個月枯燥乏味地畫圖,能開始撰寫程式之後,從上面這一長串就可以看得到我到底有多麼地為此感到開心。

本篇從昨天九點半寫到現在也四個多小時了,也差不多到此為止吧。下次有些進度再來跟大家聊聊囉!

(more...)