布丁的自我簡介(2010年版)

自我期許

研究所已經唸到第四年了，回首過往種種，還真是做了一堆其他人難以理解的事情。

我一直不是以「畢業」為目標在念書，「學習」的成就才是驅動我的動力。而學習之後連帶的就是「分享」的行為，不僅是在「布丁布丁吃？」、在其他的期刊上，甚至我也跟老師一起寫書，將我所學得、自己覺得有價值的事物，不斷地與大家分享，回饋給這個世界。

我很感激這個世界能讓我學習到各種知識，而今後我也會抱持著感激的心情，努力地將畢業論文做好而畢業。

學歷：該不會這輩子都是社會科系圖資人吧？

著作目錄

政大圖檔

• Chih-Ming Chen;Yong-Ting Chen, 2010.09, "Developing a Taiwan Library History Digital Library with Reader Knowledge Archiving and Sharing Mechanisms Based on the DSpace Platform," The Electronic Library,.(SSCI) (本論著未刊登但已被接受)
• 陳志銘;陳勇汀;林筱芳, 2010.07, "通識教育開放式課程數位典藏建置之研究," 大學圖書館,.(THCI)(本論著未刊登但已被接受)
• Chih-Ming Chen and Yong-Ting Chen, "Digital Library with Reading Annotation Tool for Supporting Effective Reading Learning," the 9th IEEE International Conference on Advanced Learning Technologies (ICALT 2009). (研討會論文)
• 王梅玲, 蔡明月, 陳志銘, 柯雲娥, 蔡佳縈, 陳勇汀, 林怡甄, "台灣圖書館史數位圖書館建構之研究," 圖書館學與資訊科學, 34卷1期, 頁15-38, 2008.
• 陳勇汀, "基於閱讀標註策略之知識萃取在支援數位學習上的應用研究", 第一屆圖資系所論文聯合發表暨觀摩研討會, 頁155-165, 2009.

輔大圖資

• ChanLin, Lih-Juan., Chen, Y. & Chan, K. (2008). The use of labeled postings for promoting asynchronous interaction. In Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2008 (pp. 988-997). Chesapeake, VA: AACE. (感謝林麗娟老師)
• 國科會95年大專生參與專題研究計畫「網路非同步互動引言機制之建置與分析」

參與活動、計畫與成果

從最近發生的到最早發生的順序來撰寫。

「DSpace開放源碼數位典藏系統建置理論與實務」專書撰寫(民國98年到99年)

這是我與陳志銘老師將在研究所鑽研DSpace，以及老師們教授數位典藏的課堂內容結合而成的一本結合理論與實務的DSpace專書。由陳志銘老師實驗室中老師、學生、助理們共同撰寫的努力成果。本書從理論、實務到案例研討，深入淺出完整介紹數位典藏系統建置所需的相關觀念與技術，為一本適合於數位典藏實作教學與有志於建置數位典藏系統之單位或個人專業用書。

值得一提的是，書中內附一功能強大的開放源碼數位典藏系統DSpace-DLLL，可以利用虛擬機器方式架設於Microsoft Windows的作業系統環境中，安裝程序快速而簡單。DSpace-DLLL除了具備一般數位典藏系統所具有的典藏、搜尋功能外，主要功能特色在於可以依據典藏需求彈性的設計後設資料與規劃後設資料遞交工作流程；也具有支援高達四十幾種數位媒體格式的展示介面，可以針對目前常用的不同型態數位典藏內容進行線上展示，為建置數位典藏系統之絕佳利器。本書也針對如何修改DSpace-DLLL的使用者介面進行介紹，俾利讀者依據典藏內容展示需求，設計美觀之使用者介面。

本書預定民國99年9月底或10月初出版，希望能對有興趣學習數位典藏、DSpace系統的人有所幫助。撰寫本書的經過與心得我寫在「寫書初稿完成！」這一篇中，書中內容不斷校改之後，刪去部分章節與文章內容，是為小小的遺憾。

圖書館事業服務2009青年論壇與談人(民國98年)

2009年6月6日國圖服務年，一群年輕有為的圖資部落客、圖資學生、圖書館相關領域的工作人員齊聚一堂，為各校輪流舉辦的圖資青年論壇畫下句點。而我則是跟洪先生、陳老師、謝學長等人一同上台，以「技術新浪潮──傳統再感動」這個主題進行報告。我報告的題目是「標註應用於數位典藏」，簡短的投影片介紹各種標註相關應用，希望帶給圖書館一些新的應用面向。

國中圖獎助博碩士班學生研撰圖書資訊學位論文獲選(民國98年)

我在2008年底完成論文計劃書口試之後，馬上將計劃書修正，並寄去申請獎助國中圖博碩士論文，沒想到居然獲選了。評審的意見給了我的論文很大的信心，例如：「論文題目新穎、前衛，未來的研究成果對數位圖書資訊的應用將呈現新風貌。」在2009年三月時我前往國中圖簽訂獎助契約並接受採訪，期限是一年之內要完成學位論文，但可再多延期一年。而現今撰寫這段介紹的我已經經過當時的一年半以上了，真的能夠如期完成嗎？

教育部全國通識教育資源平台建構與永續發展計畫 (民國97年到99年)

此為開發通識教材與教師資料的典藏計畫，陳志銘老師負責此計畫中技術部份的子計畫4，底下聘有多位助理，而身為兼任助理的我則是負責以DSpace為主的技術指導兼部分程式開發。

民國98年時我進入碩三時期，教育部計畫人事大為變更，走了舊人來了新人，與其他子計畫之間的合作也有許多變化。因為眼看當時的助理無法完成DSpace平台的計畫開發，我乾脆捲起袖子來撐起計畫的系統，並讓後半年的期中報告安然過關。

而後至民國99年，我決定開始專心於之前與老師決定的DSpace技術專書，指導助理們與實驗室的學弟妹一起來參與書本的各章節撰寫。撰寫專書的同時，我也將DSpace的相關技術回饋到教育部計畫當中，同時偶爾也作為DSpace技術顧問，回答DSpace的技術問題。

在我的Blog上發佈了數篇關於DSpace的教學與開發的功能供人參考 (http://0rz.tw/5a4Uj)，這些技術不僅與陳志銘老師、林筱芳助理一同發表在大學圖書館、民國99年底也要匯集成為DSpace的專書，請各位不吝指教。

政大圖檔所：數位圖書館暨數位學習實驗室管理員 (民國96年到97年)

陳志銘老師所領導的實驗室在今年教育部計畫3台伺服器加入之前，伺服器數量多達9台。當時我跟學長負責維護這些伺服器及本所的電腦，除了實驗室佈線、器材管理、IP分配、電腦安裝重灌之外，對於Windows、Linux也略有心得，熟悉操作Apache、IIS、Apache Tomcat、MySQL、PostgreSQL(還不敢說熟)等網頁與資料庫伺服器，安裝並修改過XOOPS、MediaWiki、DSpace等系統，後來更將部份伺服器規劃虛擬化運作。實驗室的伺服器就跟我的玩具一樣親密。

政大圖檔所中華民國圖書館學會九十七學年度「數位典藏實務與加值服務研習班」 (民國97年)

由於台灣百年圖書館史計畫的公開，DSpace的操作遂成為本所教學內容。不僅在王梅玲老師的技術服務課堂中讓學生們操作、上傳，更在暑假期間的研習班中開班授課，我在數位典藏系統與平台設計裡面擔任DSpace的操作與設定說明，授課內容請看數位典藏系統與平台設計—以DSPACE為例 (http://0rz.tw/1e4Sd)。

政大圖檔所台灣百年圖書館史暨數位圖書館先導計畫 (民國96年)

• 計畫網站：http://top.lias.nccu.edu.tw/
• 成果系統網站：http://tlh.lias.nccu.edu.tw

第一次參加具有數十人規模團隊的數位典藏計畫，我在陳志銘老師帶領之下從學長接手DSpace系統開發，對於初學Java&JSP的我來說修改得仍不是很成熟，但大部分功能修改已經不成問題。

台灣百年圖書館史在作為數位圖書館的功能有張敦媛學姐的標註功能(http://0rz.tw/e34Xs)跟SRU(Search and Retrieve via URL) (http://0rz.tw/5f4V2)開放查詢檢索的結果。技術服務期末報告就探討SRU對於數位典藏開放的議題。

之後陳志銘老師與我將此系統加入了張敦媛學姊標註功能，並發表了「Digital Library with Reading Annotation Tool for Supporting Effective Reading Learning」跟「Developing a Taiwan Library History Digital Library with Reader Knowledge Archiving and Sharing Mechanisms Based on the DSpace Platform」兩篇期刊論文。書目請見上方的著作目錄。

輔大圖資林麗娟老師的國科會計畫 (民國92年到95年)

• 民國92及93年，「資訊科技應用與創意教學專案 」(NSC 93-2511-S-030-001)
• 民國93年，「資訊融入自然領域專題式學習」 (NSC 93-2520-S-030-001)
• 民國94年，「由動機談討電腦人因網路互動學習」 (NSC 94-2520-S-030-002)
• 民國95年，「網路學習知討論表現與不同個人特質分析」(NSC 95-2520-S-030-001)

大學二年級時林麗娟老師招攬我進實驗室，主要負責伺服器維護、系統架設與開發以及分析研究內容。這是我接觸網頁伺服器的開始，在此打下對於Linux、Apache、PHP等技術的基礎。在這些計畫當中，我投注心力最多的是大家e起來互動式計分討論區，除了繼承學長的系統之外，還開發了網路線上問卷功能。

輔大圖資國科會95年大專生參與專題研究計畫「網路非同步互動引言機制之建置與分析」(民國95年)

林麗娟老師建議我對於自己加上去的「互動引言功能」去探討其對學生非同步討論學習的影響，這是我第一次獨立進行研究。本研究使用了內容分析法、訪談法來得知此系統對於學生的影響，一邊做研究一邊跑去上研究所中邱子恆老師的質性研究課程，最後從質性與量化分析驗證互動引言機制的成效。

然而對於當時學術研究能力不足的我來說，本研究不盡如人意，但卻也成為我後來的苦膽，時時提醒我不可再犯當時的研究失誤。

相隔兩年以來的自我簡介更新，這次加入了一些著作目錄與參與計畫的經驗，也算是作為自己這幾年來的一個回顧。2008年舊版的自我簡介請看這篇。那麼就請大家多多指教囉。

布丁式Blogger訪客留言板

訪客留言板的必要性

訪客留言板只是一個單純簡單的留言功能。儘管Blog中已經提供很多地方給讀者提出他們的看法，讀者可以對每一篇文章發表意見，但是我也發現到很多讀者並不是想針對某個主題來發表留言，而只是單純地想「對Blog的管理者講話」而已。因此我認為訪客留言板仍是有其必要性，所以在我的Blog右邊一直有著一塊訪客留言板的功能。

在以往我一直使用Cbox作為訪客留言板，但是Cbox本身是第三方服務，而留言的資料也無法保留、管理，讀取速度也頗慢。在六月我為「布丁布丁吃？」改版時，就已經提出了這個弱點，而打算改用Blogger內建的留言功能來製作訪客留言板。

日前我已經小試身手地在右邊導覽列加入了「布丁布丁來聊天」的留言板，很遺憾地到目前為止並沒有人願意來留言。不過這也是預料內的狀況就是，畢竟使用訪客留言板的人的確不多。有需要跟我講講話的話，就請使用訪客留言板吧。

布丁式Blogger訪客留言板安裝教學

今天我將這功能改進成為可以讓人安裝的功能。如果您也想要利用Blogger文章意見作為訪客留言板，而不想要再另外申請其他服務，那麼布丁式Blogger訪客留言板應該可以達成您的需求。

接下來，就請一步一步地照著設定吧：

1. 發表一篇「訪客留言板」專用文章

請建立一篇專門為了作為訪客留言板專用的文章。附帶一提，「布丁布丁吃？」的第一篇文章就是訪客留言板，有人有注意到嗎？

2. 取得blogID跟postID

接著請再利用Blogger的「修改文章」功能，找出該篇文章，並記下這時候的網址。上圖中網址被遮住了，此例中的完整網址如下：

http://www.blogger.com/post-edit.g?blogID=8505579180942752344&postID=5270991376408850312

您可以由此得知blogID為「8505579180942752344」、postID為「5270991376408850312」。這兩個編號在稍候設置時會使用，請牢記。

3. 新增小工具「訪客留言板」

請到Blogger「設計」中「網頁元素」的頁面去新增小工具「HTML/JavaScript」。

標題您可以設定為「訪客留言板」或其他名稱，內容請在「修改Html」的模式中輸入以下內容：

<script src='http://www.google.com/jsapi' type='text/javascript'></script>
<script type='text/javascript'>google.load('jquery','1.2.6');</script>
<script type="text/javascript" src="https://sites.google.com/site/puddingchen35/Home/puliguestbook/puliGuestBook.js"></script>
<script type type="text/javascript">
// 布丁式Blogger留言板
// @param {Object} config 設定
$.puliGuestBook({
    blogID: "8505579180942752344",    //blog的ID
    postID: "5270991376408850312",    //post的ID
    url: "http://pulipuli.blogspot.com/feeds/6921201361608060798/comments/default",    //訂閱張貼意見的網址，或是文章ID:115667103250300740
    css: "https://sites.google.com/site/puddingchen35/Home/puliguestbook/puliGuestBook.css",    //CSS樣式表
    container: "#puliGuestBook",    //顯示留言的元素
    listNumber: 20,    //顯示留言數量。超過此數量時，會顯示「閱讀全部留言」的連結。
    adminName: '布丁布丁吃布丁',    //Blog主人的名字
    adminPhoto: 'https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjV6vw1VIdeIzh1wkVnCWL3HYGj09ht_WvkgNBkcHjr_jC2pX8BKCEOEAGMymBMOFhKOPeVSn85EXbt08qdW7ZTWjWHCGKUpJfh_oi2qlHrtMh1xk12qlWNKQyXPwPZhqRZXGN88g/s45/',    //部落格主人的照片
    anonymous: '匿名',    //匿名者的名字
    readMore: '閱讀全部留言',    //閱讀全部留言連結的名稱
    write: '撰寫留言',    //撰寫留言連結的名稱
    reload: '重新讀取'    //重新讀取連結的名稱
});
</script>

其中有幾項設定是建議您修改的：

• blogID：就是上一小節提到的blogID，請確實輸入。
• postID：就是上一小節提到的postID，請確實輸入。
• adminName：請填入您留言時會顯示的稱呼。可以將此行刪除不寫。
• adminPhoto：請填入您照片的網址連結，最好是正方形的圖片。這是因為本功能無法偵測使用者的頭像，只好自行輸入。

其他的設定請參考程式碼中的說明。除了blogID跟postID是必須填寫之外，其他的資料都是選填。舉例說，如果你要

4. 儲存並完成

請依序儲存整個設定，再回頭開啟您的首頁，應該就可以看到訪客留言板正常運作了。

結語

基於將所學所得分享出來的自我要求而整理了這一篇，事實上也花上不少時間來改良訪客留言板。此處使用的訪客留言板功能跟「布丁布丁吃？」使用的訪客留言板是分開發展的兩個程式，這是由於「布丁布丁吃？」很常被我亂改導致系統不穩定，請大家使用此文章教學的穩定版本即可。

好，終於把這功能寫完了，心中的石頭又放下了一塊。接著下一篇繼續努力。

• 2011/4/1：補充，您的Blogger讀取權限必須設定為「任何人」才能使用此功能
• 2013/5/27：加入了更新CSS的說明

RSS全文輸出工具介紹：まるごとRSS與FeedEx.net

RSS訂閱對我來說就像是看報紙一樣，吃飯沒事想要休息一下的時候就打開Google Reader瀏覽最近發生的新聞、看看朋友的Blog更新，隨時更新一下資訊情報，這是我每天必做的小小習慣。

如果你還不知道什麼是RSS訂閱網址(RSS Feed URL)、RSS閱讀器(像是Google Reader)，那我建議你先閱讀一下電腦玩物的介紹入門，而這篇可能就暫時等你熟悉RSS訂閱之後再來閱讀吧。

摘要輸出的限制

使用RSS訂閱的讀者都知道，RSS訂閱最麻煩的就是「摘要輸出」。大部分提供RSS訂閱功能的網站都不會顯示完整的全文，通常都是文章前100個字、最後再加上一個「(繼續閱讀)」標籤，讓人非得點開他的網頁才能看到完整的文章。

會這樣做的原因，不外乎是為了原本網站的點閱次數、希望讀者去點一下他們網站上的廣告，如果讀者都在RSS閱讀器上觀看訂閱文章，那麼原始網站就會少了這些收益。

儘管如此，我們仍希望讓我們訂閱環境單純一點、簡單一點，我們就是希望RSS閱讀器中點開文章看到的就是完整的內容，而不是半殘的片段。特別是當我用手機離線閱讀RSS訂閱時，看到那種需要繼續閱讀的文章就一整個無力。在那種情境下，就是沒有網路、沒有辦法開啟你的網站，讀者也是很無奈的。

從閱讀器改善全文輸出

有些人會使用Google Reader的功能套件，讓讀者在Google Reader閱讀器當中再嵌入一個小視窗以顯示文章連結中的完整內容，例如alicekey介紹的Google Reader Preview Enhanced。但這種作法只適用於Google Reader，不適用於其他的RSS瀏覽器，對手機閱讀RSS訂閱就愛莫能助。

之前使用Windows Mobile手機時，我是安裝了Spb Insight這個RSS閱讀器，它除了許多離線瀏覽功能之外，還強調支援「RSS全文輸出」，但實際上卻是要自己設計下載RSS全文的「樣板」，才能達到正確的「全文輸出」。手續上蠻複雜的，下載下來的全文也不見得好閱讀。

RSS全文輸出工具服務

事實上，還有更根本的作法，那就是從訂閱時就直接訂閱全文輸出的RSS訂閱，那麼不管在哪一個RSS閱讀器上，都可以看到完整的文章內容。

儘管很多RSS訂閱網址提供者就是不提供全文，才會有這篇現在這種問題，但是網路上卻有很多工具服務作為「第三者」來幫你解決這個問題。透過工具服務轉換過的RSS訂閱網址，看到的就會是完整的全文，再也不是片段的摘要了。

RSS訂閱全文輸出工具服務中，我使用過最棒的兩個就是まるごとRSS跟FeedEx.net。他們的使用方法都很簡單，也都是免費、無限制的服務。但是跟原始的RSS訂閱比起來，工具服務提供的全文RSS訂閱的更新速度就不會這麼即時。

以下就來簡單地介紹一下吧。

まるごとRSS

這是從日本提供的服務，介面是日文的。他擷取的全文內容較接近原始文章的版面，因此我個人偏好使用まるごとRSS。但是他的缺點是「中文編碼處理能力不佳」，許多中文的RSS訂閱被まるごとRSS轉換之後就變成亂碼，在使用上必須特別注意。

我使用まるごとRSS來轉換的全文輸出網站通常都是使用FeedBurner燒成摘要的RSS訂閱，包括：

• 不來恩 - 重灌狂人 (轉換網址)
• Mr. 6 - 趨勢．創業．網路．生活 (轉換網址)
• 傳說中的挨踢部門 (轉換網址)

まるごとRSS使用方法介紹如下：

1. 開啟まるごとRSS網頁，在「フィ－ドのURL」下面的欄位中輸出RSS訂閱網址，再按下又長又大的「GO」按鈕。

2. 轉換完畢，下面欄位中那一串就是全文輸出的RSS訂閱網址了。

至於まるごとRSS的標題為何如此地像火影忍者(NARUTO)，我也不是很清楚就是，有人可以幫忙解答一下嗎？

FeedEx.net

FeedEx.net跟まるごとRSS一樣是RSS訂閱全文輸出工具。他的副標題挺有意思的：我們將(小小的)RSS訂閱轉換成(大大的)RSS訂閱，讓人看了有種會心一笑的感覺。

FeedEx.net的優點在於編碼正確，不會像まるごとRSS老是轉換成亂碼。而轉換之後的版面也較為精簡，對手機這種小螢幕閱讀器來說應該是比較好的選擇。

FeedEx.net不像まるごとRSS一樣有編碼的問題，因此幾乎可以適用於任何非全文輸出的RSS訂閱上。我使用FeedEx.net的RSS訂閱包括：

• 網路資訊雜誌 (轉換網址)
• ZDNet Taiwan: 新聞 - 當日最新 (轉換網址)
• 巴哈姆特 GNN 新聞網 (轉換網址)

以下介紹FeedEx.net的操作方法：

1. 開啟FeedEx.net網頁，在「Just enter the feed url to the form below:」 底下的欄位中輸入RSS訂閱網址，然後按下右方的「Go!」

2. 請等待FeedEx.net轉換(大概10秒鐘)，待會網頁會顯示輸出成果，如下圖。而「The feed has been expanded. You may subscribe to full-text version by the following url:」底下的連結「http://feedex.net/feed/gnn.gamer.com.tw/rss.xml」就是全文輸出的RSS訂閱網址囉。

結語

這篇是有感於電腦玩家的「強制 RSS 全文輸出的三個有效工具，讓你在 Google Reader 閱讀部落格全文」介紹，異塵行者除了上述兩個工具之外，還介紹了FiveFilters.org。但是我使用一陣子才發現到，原來FiveFilters.org還真的只有「Five」，他一天內只會轉換1到4筆全文的RSS訂閱，要更多筆的話就得付費(8 €/month)，因此我並不推薦用FiveFilters.org，免費的FeedEx.net跟まるごとRSS就很好用囉。

附帶一提，此Blog「布丁布丁吃？」的RSS訂閱直接就是全文輸出，不需要任何轉換也可以閱讀到完整的文章內容……儘管可能有點無聊XD

有任何好用的RSS全文輸出轉換服務，也請大家多多推薦囉！

YouTube與ニコニコ動画作業用BGM下載並抽取音軌教學

我跟很多人一樣喜歡在工作時聽些音樂(在ニコニコ動画中會將之歸類為「作業用BGM」的標籤)，有人聽廣播、有人聽自己買的CD，現在網路影音分享平台發達的環境中，我特別喜歡在YouTube或ニコニコ動画(以下簡稱niconico)聆聽別人編輯好的曲目。

在有網路的環境下使用YouTube或niconico倒還沒什麼問題，可是在沒有網路、想放在手機或隨身聽上來聽時，可就需要一些小技巧來把這些作業用BGM下載且「抽取」成為真正的「作業用BGM」音樂檔案囉！

下載影片

YouTube跟nico下載影片的方式不同，以下各別介紹：

YouTube下載：YouTube Downloader

YouTube因為太過熱門，下載器多到族繁不及備載；加上YouTube更新頻繁，更新之後舊版下載器不能使用，而不久之後又會出現有心人士製作下載器。總而言之，YouTube下載器真的是挑自己方便即可。

我使用的是Google Chrome瀏覽器的擴充功能「YouTube Downloader」，他會幫你在YouTube觀賞影片下面加上「Download」按鈕，讓你選擇要下載的影片等級，例如「360p (FLV)」、「360p (MP4)」、「240p (FLV)」。此處的「360p」與「240p」是指影片橫向的解析度，解析度越高表示畫質越好，音質通常也會比較好。括弧中的「FLV」與「MP4」是影片的格式，其中MP4可在大部分的裝置上播放，像是Android手機、iPod系列，是近來相當受歡迎的格式，我也推薦下載MP4格式的檔案。

YouTube因為有影片時間的限制(近期似乎是解禁了)，下載單曲來聽是不錯，可是要找長時間播放的作業用BGM，那麼就非日本人最流行的nico莫屬了。

ニコニコ動画下載：NicoFox

ニコニコ動画(nico nico動畫，簡稱niconico)是日本盛行的影片分享平台。他允許使用者上傳超長時間的影片，影片的類型也以原創、剪輯的創意形影片居多，主題也多以日本文化為主，特愛日本的動畫、漫畫、遊戲等相關主題的我總是能在nico挖到許多寶物。

niconico最大的特色在於「字幕留言」，使用者可在影片播放中加入自己撰寫的留言，留言就會像字幕一樣跟影片一起顯示。他是完全的會員制，不僅是上傳影片，就連觀看影片都需要註冊才能使用。註冊niconico帳號的方法請看wini的「Nico Video 申請帳號及登入使用的方法」教學，我就先省略不講了。

說到niconico下載影片，Firefox瀏覽器的NicoFox絕對是最佳神器，而且作者還是臺灣人喔！以下引用來自此擴充套件的介紹：

NicoFox是對NICONICO動畫中上傳的影片進行儲存、管理、播放的閱覽支援擴充套件。這個擴充套件可以讓你下載NICONICO動畫上的影片，並使用各種的播放器來回味其中的內容。對於NICOSOUND之類的工具網站只要輕輕在工具列點一下就可以使用！一定要試試看！

關於NicoFox的安裝與使用方式請參考CHCOOBOOのBlog的「[Nico] NicoFox - FireFox專用的Nico影片下載套件」，安裝與使用需要一些手續，但並不複雜就是。

抽取音軌

現在YouTube或niconico下載下來的影片不外乎兩種格式：早期使用的FLV跟後期使用的MP4。如果想要把這些影片檔案轉換成聲音檔案(或稱為「音訊」，聲音訊號)，大部分的人都是使用如Format Factory格式工廠這種多媒體轉換器來做。我以前也是這樣做，但是這種轉換會損壞原本影片的音質(儘管上傳到YouTube或niconico的時候，影片的音質就不一定很好了)，而且轉換時間又久，長時間的作業用BGM就讓人懶得轉換。

因此在這裡我並不是教大家怎麼將影片「轉換」(convert)成音樂，而是要教將影片「抽取」(extract)出聲音檔案的方法。影片本身就是影片檔案與聲音檔案結合的多媒體檔案格式，所以要從這種複合格式中抽取出聲音檔案，的確是可以做到的。

FLV跟MP4抽取方法不同，以下各別介紹：

FLV抽取音訊：FLV Extract

• 下載：官方網站Moitah.net (SkyDrive備份)
• 使用介紹：Jackbin的懶人筆記的「快速解出 FLV 檔案中的 video 和 audio - FLV Extract」、CHCOOBOOのBlog「[軟體] FLV Extract - FLV檔分解器」
• 使用前必須先安裝.NET Framework 2.0
  

FLV Extract是一個免安裝的小工具，下載後直接開啟，選取要抽取的資料類型Audio(聲音檔案)。然後從「我的電腦」或任意資料夾中拖曳FLV檔案到FLV Extract視窗，他就會立刻從FLV影片中抽取出聲音檔案。

又快又方便，一下子AAC格式的聲音檔案就出現在跟FLV檔案相同的資料夾底下了。

MP4抽取音訊：YAMB + MP4 Box

• 下載：官方網站YAMB Website，建議下載Yamb-2.1.0.0 beta 2 with installer (SkyDrive備份、FLASHMIRRORS多免空備份)
• 使用介紹：CHCOOBOOのBlog「[軟體] YAMB + MP4 Box --MP4影音分離好幫手」

Yamb是透過MP4 Box來編輯MP4格式的工具。功能繁雜，在此主要是介紹抽取聲音檔案的方法。

安裝完之後請打開Yamb程式，會看到以下畫面，此時進入左方的「Editing」。

請對第三個功能「Click to extract streams from AVI/MP4/MOV/TS files. (從AVI/MP4/MOV/TS檔案中抽取串流)」雙擊滑鼠，以開啟此功能。

接著請選擇要抽取的檔案，請按右上角的資料夾畫面，開啟檔案選取視窗。注意，檔案名稱只能包含英文或數字之外的字，不可以使用日文或中文。由於NicoFox下載影片時會自動以影片標題命名，因此檔案名稱通常會用到日文。建議您在抽取之前先更改檔案名稱，以免抽取動作失敗。

選擇完檔案之後，Yamb會提示你要抽取的項目。你可以看到內容中有以H.264格式壓縮的影片以及AAC音樂格式檔案，請選擇AAC格式並點選下面的「Extract to Raw Format.」(抽取出原始格式)選項，再按下面的Next(下一步)

抽取的速度很快，馬上就抽取完了，AAC檔案會出現在跟影片檔案同樣的資料夾底下。然後記得要將檔名還原，就大功告成了。

AAC音樂格式

上述的影片中很湊巧地都使用了AAC音樂格式，而不是一般人所知的MP3格式，所以我在此也簡單地介紹一下AAC格式。

根據wiki的說法，AAC具有比MP3更高的壓縮比，也就是在相同音質底下，AAC的檔案大小更小，而且採用多聲道(支援5.1聲道)、低複雜性的描述方式，因此音質方面也相當不錯。事實上，網路上使用串流影片搭配聲音的壓縮技術中，AAC的確是相當主流的格式。

現今的Android手機、Apple的QuickTime / iTunes也都可以支援，有朝一日應該會取代MP3的地位吧。

結語

本來是想整理一下從下載到抽取的相關介紹，結果發現wini跟CHCOOBOO等人就已經有了很多不錯的介紹文章，寫完之後有種失落感XD 因此加入了一些細節操作與感想，希望能夠讓有需要的人更有幫助。

最後必須強調的是，這些下載與抽取的方法僅供練習、試用，請勿進行造成影片、音樂原作者權益受損的違法行為！一定要注意喔！

淺談AJAX、JavaScript與JSONP

這是在2010年8月18日meeting時報告的投影片。講述了AJAX的概念，舉了一些例子、介紹JavaScript程式語言，以及AJAX跨網域的運作方式：JSONP。

網路上介紹AJAX、JavaScript與JSONP的教學文章很多，我也是參考了許多人的說法，最後整理出這個投影片。在很多前輩面前，這種小兒科的圖說投影片只能說是班門弄斧而已，請多多指教。

(SkyDrive備份)

現在很多人都享受著AJAX的技術，但真正懂得JavaScript的人卻沒有幾個。

我深愛著JavaScript這個程式語言，從高中開始就與他為伍，至今論文也依然用它來實作。然而即使網路世界AJAX盛行，我只聽說學校有教ASP、PHP等伺服器端程式語言，教Flash應用，卻從來沒聽說有人在教JavaScript。

我承認JavaScritp不是一門很好學習的程式語言。作為對於程式語言的認識，他也沒有C或Java來得合適。JavaScript要使用可以很簡單，但是如果複雜起來，就會變得相當難以維護。(就像我現在論文所面對的議題) 儘管它缺點也是不少，但是我還是喜歡JavaScript，喜歡他的開放性，喜歡他在各種瀏覽器都可以執行的跨平台性。

我也希望能藉由這個投影片，再跟大家宣傳一下JavaScript的美好。

而我所在的實驗室以往也有許多以網頁技術為主的論文成果。有些學長姊作的成品，至今仍受惠於學弟妹、繼續進行深入的研究。但是近幾年來，網頁技術在實驗室當中越來越淡薄。深怕「寫程式」的學弟妹越來越多，即使是較偏工科出身的學生，也不太願意面對「程式」這種龐大的壓力。

說來實在也有點可惜。我一直覺得寫程式是很快樂的一件事情。就像是小時候組合樂高積木一樣，可以透過它讓自己幻想中的東西真實地呈現出來。我為之樂此不疲，也希望能將這種喜悅傳達給學弟妹(雖然老師看起來是聽到睡著了)。

不過，我很清楚寫程式跟作研究並沒有很大的直接關係。程式寫得好，不見得論文寫得好。這個想法在之前的blog裡面就有闡述過了，就目前現在這階段來說，應該只能當做是興趣吧。某些角度來看，不寫程式而專心弄好研究而畢業，說不定他們才是人生的勝組？如果人生的勝敗組是這樣定奪的話，那我寧願選擇作自己開心的人生敗組就好。

一些感想隨筆而已，就這樣。

論文進度報告(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，於是開發進度就有了比較明確的依據。大致上可以整理如下表：

其中，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