論文進度報告(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...)

循序樣式探勘工具 Sequential Pattern Mining Tool

(more...)

輸出陣列元素所有不重複組合 print all unique combination of an array

(more...)

DSpace清理已刪除Bitstream的cleanup時出現java.lang.OutOfMemoryError: Java heap space的處理方法

DSpace中刪除的Bitstream(檔案)只會在資料庫中標示為deleted = 1，並不會從檔案系統中移除。換句話說，檔案還留在伺服器上，佔據硬碟空間。如果要真正地刪除檔案，必須使用[dspace]/bin/cleanup指令，關於Bistream Store(檔案儲存)知識在DSpace的說明書中已經有提及，在此只是稍微回顧一下。

Bistream的清理主要是使用BitstreamStorageManager.cleanup()，他會從資料庫中取出所有被標示為deleted = 1的Bitstream，並一一地從檔案系統中刪除。但是deleted = 1的Bitstream數量太多時，就會出現「java.lang.OutOfMemoryError: Java heap space」錯誤。

簡單來說，這是由於記憶體不足，DSpace無法處理從資料庫取出來的超多資料的錯誤。處理的這個問題的方法有兩種，一種是加大Java可用的記憶體，另一種是變更資料庫查詢的方式。我認為加大Java可用記憶體的方法是治標不治本，因為總是會有挑戰記憶體上限的資料量出現。我建議的是修改查詢資料庫的方法，設定offset跟limit，一次查詢部分資料，然後分多次查詢進行。

因此我修改了BitstreamStorageManager.java，在此也順便提供給有遇到類似問題的人使用：

1. 下載BitstreamStorageManager.java (注意，這是DSpace 1.5.1的版本，如果你使用不同版本的話，並不建議直接下載覆蓋，而是請參考下面的說明)
2. 放至[dspace-src]/dspace-api/src/main/java/org/dspace/storage/bitstore/BitstreamStorageManager.java

這個檔案主要是修改了cleanup方法，方法如上述。詳細的程式碼如下：

    /**
     * Clean up the bitstream storage area. This method deletes any bitstreams
     * which are more than 1 hour old and marked deleted. The deletions cannot
     * be undone.
     * 
     * @param deleteDbRecords if true deletes the database records otherwise it
     *                only deletes the files and directories in the assetstore  
     * @exception IOException
     *                If a problem occurs while cleaning up
     * @exception SQLException
     *                If a problem occurs accessing the RDBMS
     */
    public static void cleanup(boolean deleteDbRecords) throws SQLException, IOException
    {
        Context context = null;
        BitstreamInfoDAO bitstreamInfoDAO = new BitstreamInfoDAO();
        int commit_counter = 0;

        try
        {
            context = new Context();        
            
            int queryBitstreamNumber = 10;
            int queryBitstreamIndex = 0;
            int queryBitstreamInterval = 10;
            
            while (queryBitstreamNumber > 0)
            {
                String myQuery = "select * from Bitstream where deleted = '1' offset " + queryBitstreamIndex + " limit " + queryBitstreamInterval;
                
                List storage = DatabaseManager.queryTable(context, "Bitstream", myQuery)
                        .toList();
                queryBitstreamNumber = storage.size();
                if (queryBitstreamNumber == 0)
                    break;

                for (Iterator iterator = storage.iterator(); iterator.hasNext();)
                {
                    TableRow row = (TableRow) iterator.next();
                    int bid = row.getIntColumn("bitstream_id");
                    
                    System.out.println("Ready to Bitsteam (" + bid + ")...");

                    GeneralFile file = getFile(row);

                    // Make sure entries which do not exist are removed
                    if (file == null || !file.exists())
                    {
                        log.debug("file is null");
                        if (deleteDbRecords)
                        {
                            log.debug("deleting record");
                            bitstreamInfoDAO.deleteBitstreamInfoWithHistory(bid);
                            DatabaseManager.delete(context, "Bitstream", bid);
                        }
                        System.out.println("File not exists, continue.");
                        continue;
                    }

                    // This is a small chance that this is a file which is
                    // being stored -- get it next time.
                    if (isRecent(file))
                    {
                        log.debug("file is recent");
                        System.out.println("File is recent.");
                        continue;
                    }

                    if (deleteDbRecords)
                    {
                        log.debug("deleting db record");
                        bitstreamInfoDAO.deleteBitstreamInfoWithHistory(bid);
                        DatabaseManager.delete(context, "Bitstream", bid);
                        System.out.println("Deleting db record.");
                    }

                    if (isRegisteredBitstream(row.getStringColumn("internal_id"))) {
                        System.out.println("do not delete registered bitstreams");
                        continue;            // do not delete registered bitstreams
                    }

                    boolean success = file.delete();

                    if (log.isDebugEnabled())
                    {
                        log.debug("Deleted bitstream " + bid + " (file "
                                + file.getAbsolutePath() + ") with result "
                                + success);
                        System.out.println("Deleted bitstream " + bid + " (file "
                                + file.getAbsolutePath() + ") with result "
                                + success);
                    }

                    // if the file was deleted then
                    // try deleting the parents
                    // Otherwise the cleanup script is set to 
                    // leave the db records then the file
                    // and directories have already been deleted
                    // if this is turned off then it still looks like the
                    // file exists
                    if( success )
                    {
                        deleteParents(file);
                    }
                    
                    // Make sure to commit our outstanding work every 100
                    // iterations. Otherwise you risk losing the entire transaction
                    // if we hit an exception, which isn't useful at all for large
                    // amounts of bitstreams.
                    commit_counter++;
                    if (commit_counter % 100 == 0)
                    {
                        context.commit();
                        System.out.println("commit");
                    }
                }
                
                queryBitstreamIndex = queryBitstreamIndex + queryBitstreamInterval;
                
                
            }    //while (queryBitstreamNumber > 0)

            context.complete();
        }
        // Aborting will leave the DB objects around, even if the
        // bitstreams are deleted. This is OK; deleting them next
        // time around will be a no-op.
        catch (SQLException sqle)
        {
            context.abort();
            throw sqle;
        }
        catch (IOException ioe)
        {
            context.abort();
            throw ioe;
        }
    }

(more...)

「布丁吃布丁？」文章的分類

從這一問開始，就來談談「布丁布丁吃？」裡面大概都是什麼樣的文章吧。文章在blog裡稱之為「post」，但內容不一定是供人直接閱讀的文字，有時候也是會有讓人當做應用程式一樣使用的JavaScript程式(像是序列分析工具)，但在這裡我就用「文章」作為blog中每一篇內容的統稱吧。

雜亂無章的初期

一開始建立blog的時候，我對於要放些什麼在這邊並沒有太多概念。當時社交網站的種類並不多，blog算是少數「供人在網路上發聲」的平台之一。因此我就嘗試地把一些雜七雜八的東西放上來。

稍微回顧了一下，我發現當時寫的文章可以大概地分成三類：

1. 日記：記錄心情或是生活點滴的文章，一方面是為了整理、記錄當時的想法，另一方面是供未來的自己觀看。
2. 創作：課堂的報告、備考筆記跟考古題的答案(雖然大家比較在意的應該是考古題的題目)、面試準備或演講心得等，在各種活動時建立、撰寫的文件資料。主要的用意是供別人參考，但其實並不是這麼好閱讀。
3. 備忘：轉載自其他網站的資料、沒有答案的考古題、圖片備份等等。這是為了給自己備忘用。

這時候並沒有特定的目標讀者，這時期的文章還是相當私人，在公開的地方發佈私人用或是私人做完之後順手放出來的文章的確很奇怪。而且跟著別人有樣學樣的結果就是不少資料都是網路上重複的垃圾文章，甚至還有違反版權的疑慮。

大學時期的備考筆記與考古題

值得一提的是，在大學時期最受歡迎的文章是考古題。

願意公開考古題題目的人不多，而我是很不怕死地在blog公開考古題的人之一。大學系所的考古題有個習慣，都是學長姊一脈相傳下來，我還記得當時學姊拿給我的考古題厚厚一疊，有些還是附有前人解答的影印答案卷。我覺得這樣子的知識傳承蠻不錯的，可是又很懶得印這麼多資料傳給後面的人，就乾脆將之數位化之後放在blog，這樣子只要跟來要考古題的學弟妹說「去看我的blog就好，網址是pulipuli.blogspot.com」就可以輕鬆打發！

當然，這種舉動也會被人當做眼中釘。有些同學並不喜歡我公開考古題，他們覺得這是用功或是善於班級交際的人才能擁有的資源。搞到後來老師也知道我在網路上公開考古題，只是並沒有明確地阻止我這樣做而已。

從一開始考古題只有題目的轉載，到接下來我逐漸地將考古題加入答案，或是在blog發表對某些考試的準備資料。然而，我並不是很會讀書的人，這些文章或多或少都有錯誤。有時候我在考前發佈了該考試的準備筆記，而之後繼續讀書時發現我有些認知錯誤，然後在考試時進行更正，似乎有些同學就因為這樣子被我誤導了。

即使是到現在，似乎也是有些輔大圖資的學弟妹會上來使用當時發表的考古題。雖然這些並不是非常原創的文章，但是能幫上很多人這點，讓我感到非常欣慰。

現在的分類

隨著時間推移，原本會在blog的備忘資料卻隨著社交網站服務變多，大家在網路上發佈的訊息也越來越多樣化。加上受到電腦玩物等blog的影響，blog的文章會偏向介紹的方向，開始有了「模擬的讀者群」這樣的概念，而不是盡放一些只是供自己閱讀的文章。

現在的分類大致上可以作為四種：

1. 日記：一樣是記錄心情的日記，但是語氣用詞會有意識到「這是給別人看的、而不是給自己看的內容」，所以少了肆無忌憚地心情隨筆，多了更講究架構脈絡的記事風格。不過最近越來越少在blog寫心情日記，而轉移到較為私密的Plurk上來撰寫。比起老是一堆看不懂文章的blog來說，說不定追蹤我的Plurk還比較有趣？
2. 記事：比起日記的心情記事，我也開始針對特定事情描述來龍去脈，像是詐騙事件、論文進度報告。希望比起心情隨筆的日記來說，記事是更容易閱讀、更有參考價值的文章。
3. 創作：自己做任何活動之後所產生的產物，這時期最多的就是每次meeting報告的投影片。然而這些內容也都是目標要給同學或老師看，所以至少也不會太個人。但是一些自己撰寫給自己用的JavaScript小程式還是沒有很多說明，有時候也多少讓人難以理解。
4. 介紹：如果說創作的部份是在其他活動中產生的文章，「介紹」就是專以blog這個媒體來介紹的文章。我會預設讀者是對這方面有興趣、並具有一定程度的能力，撰寫的文章基本上都是圖文並茂，而且還幫程式碼加上顏色區別。

我認為網路上到處轉載的垃圾資料已經夠多了，我希望能夠在這個blog的文章能多一點獨特性、減少無意義的重複。私人的備忘資料也改用其他工具來保存，像是Evernote、SkyDrive，因此逐漸減少在blog上發佈純粹是備忘相關的資料。

電腦技巧與技術的介紹

我在大學跟研究所時皆管理大量的電腦跟伺服器，也受到電腦玩物等blog的影響，我也開始寫些自己使用電腦跟管理伺服器的技巧，像是隨身碟防毒軟體的心得、SPICEWORKS—IT管理工具簡易操作教學。而實際上「布丁布丁吃？」瀏覽率最高的都是這類型的文章。之前聽老師說有人統計出blog最受歡迎的文章類別是「電腦3C資訊」之類的，雖然從我的blog瀏覽統計裡也得到了映證。

然而，電腦技巧的資料也是有熱門跟冷門的區別。娛樂性較高的電腦技巧文章很受歡迎，但是因為網路上介紹電腦技巧相關的文章實在是很多，有時候自己花了很多時間寫完了卻發現其實不少人已經寫過之後，就會覺得有點讓人喪氣。

相較之下，「布丁布丁吃？」有許多很少人在介紹、而自己覺得像是挖到寶物來跟大家炫耀的電腦技術文章，像是DSpace系列。儘管對大部分的人來說看不太懂，但對有需要的人來說是非常地有用，也是讓我覺得這些都是「布丁布丁吃？」的核心價值所在。

布丁的研究之路(是的，我正在繞遠路)

不知道有多少人有發現到「布丁布丁吃？」的說明是「布丁的研究之路(是的，我正在繞遠路)」。

在講講這說明跟內容的關係之前，我先介紹一下這個說明的由來。在我要考研究所時跟大學學長討論未來的方向，學長認為我不考資工資管而堅持要考圖資相關研究所的這種行為就像是在繞遠路一樣，我覺得學長說的很是，所以就把原本的「布丁的研究之路」加上了「是的，我正在繞遠路」的輔助說明。而在念研究所時，不知道是受到了「我正在繞遠路」的影響還是我真的打算繞遠路，我的確在做許多看似跟論文相關又好像不太相關的事情，結果就如學長所說的真的一直在繞遠路。

一開始我並不知道「研究之路」到底是什麼，也許是念研究所相關的事物吧？於是「布丁布丁吃？」中有著許多我在念大學、研究所時所做過的大小事情記事，而這些就是「布丁的研究之路」上所經歷過的事情。可是唸書唸到現在，我對於「研究」的概念逐漸具體，也知道真正的研究結果通常是發表在學術期刊，而不是像我現在這樣在blog裡發表的一些自己以為覺得不錯的文章。

儘管如此，我還是覺得在blog裡發表一些別人很少談、但是很重要的資料來說，是很有價值的事情。對我來說，這可能真的就是屬於自己的「布丁的研究之路」了。

小結

反思了一下自己往年的文章分類之後，才發現右邊那些「標籤」分類其實有很多不是很正確。不過這篇文章從開始寫到現在也不過三天，而且實際上主要在寫的只有一天不到，如果花更多時間在回顧文章上，也許對內容分類會有更深入的看法。

另一方面來說，其實我也不是很在意分類究竟如何啦。就如我第一問所說的，「布丁布丁吃？」的用法並不是從分類架構來找到你需要的資料，請使用網路搜尋引擎用你的關鍵字來找資料即可。儘管我自己是圖資領域的，但對於blog這種沒有特定主題的資料集合來說，勉強給予個分類架構倒也是很奇怪。就看要什麼角度來看、進行怎樣的分析就是了吧。不過我這人沒沒無聞又無聊，我想應該也不會有人在意才是。

下一問：

「布丁布丁吃？」與讀者的互動：布丁與讀者互動的管道為何？回應讀者留言的過程與感想為何？與讀者在blog之外的互動經驗為何？甚至是實體互動？

(more...)

45巷殺人魔王燒臘店

• 店名：沒有名字（這家店真的不叫做殺人魔王，只是很多人都這樣叫他，所以以下都用「殺人魔王」來稱呼這家店）
• 位置：指南路二段45巷內
  
• 菜單：燒臘飯、麵
• 價位：60NTD~80NTD
• 座位：普通容易坐到座位

殺人魔王

這家店在政大已經很久了，甚至有新聞報導。這家店被人戲稱為殺人魔王的原因是因為剁燒臘老闆看起來就很像殺人魔王，但我覺得其實還好，一般燒臘店的廚師也都是帶著那樣的氣勢來剁燒臘的啦。

一開始到這家店的人一定會覺得很奇怪，究竟門在哪裡？事實上殺人魔王不僅沒有招牌，連門把都沒有！而其中一扇就是就是可以從旁推開的門，必須要將沒有門把的門直接推開才能進入。光是從開門的動作就可以判斷是否是殺人魔王的常客了。

殺人魔王燒臘店的環境就如燒臘店一樣地油膩、黏稠，不管做哪邊都覺得髒髒黏黏的，這只能說是燒臘店處理食物時無法擺脫的困擾，而殺人魔王也不例外。儘管店內位置不少，也有提供電視，但是並不適合久坐。

殺人魔王燒臘店的菜單也是很有燒臘店的風格：以幾種固定的燒臘肉類來排列組合成為餐點。請仔細一看，大致上都是叉燒、烤鴨、油雞、排骨、豬排等組合。再搭配飯、飯、炒飯、燴飯、蓋飯，就成了各式各樣的餐點。但是其實吃起來味道都差不多啦，非常地重鹹。

殺人魔王不僅價位是學生等級的便宜(附近知名的陽城燒臘都是80元起跳)，而份量也是學生等級多。店內提供自取的綠豆湯，可以解解燒臘的油膩。天氣熱時是冰的綠豆湯，天氣冷時則是熱的綠豆湯，綠豆湯還真是萬用。

芙蓉蛋蓋飯(60NTD)

殺人魔王的特色餐點之一是這道芙蓉蛋蓋飯60元，蓋滿了整盤飯的是蛋、切碎叉燒、豬排等肉類，淋上燒臘醬汁，下面則是超多的白飯。雖然說不上美味，但是光看覺得很華麗，而且飽足感十足。

結語

殺人魔王最大的問題是餐點都很鹹、非常重口味。雖然有綠豆湯可以配，但是綠豆容易卡在牙縫裡，喝完也不覺得特別舒爽。因此我也較少光顧殺人魔王就是。比起美味來說，這家店從店名、門口等故事應該是更令人覺得有趣的地方吧。

(more...)

政大越南小吃

• 店名：越南小吃
• 位置：政大正門萬壽路上，熊威超市對面
  
• 菜單：便當飯類、小吃麵食
• 價位：40NTD~80NTD
• 座位：就算不是高峰期也不容易找到座位

越南小吃

越南小吃雖然並不是直接貼著萬壽路，但至少比起在小巷子的店面來說醒目許多。越南小吃的店面非常狹小，座位很少，可是來客卻很多，導致常常一位難求。雖然是這樣說，但因為店內廚房與座位並沒有區隔、而且排煙沒有處理好，油炸餐點時會讓店內四處都是油煙，坐起來並不是很舒服。此外衛生也不太乾淨，也是小巷子的程度。不過店內卻提供了一台超大的電視，讓不論是內用還是外帶的客人都能看看新聞、緩解等待的無聊。

越南小吃的餐點大致上是一般小吃店都會出現的東西，像是排骨飯、榨菜肉絲麵等等，等級也都是小吃店的程度。雖然作為招牌的赤肉羹跟魯肉飯並不難吃，但也沒說到令人驚艷的地步。要說特色的話，反而是偶爾店內自取飲料會提供檸檬汁，酸酸甜甜非常開胃，而且在夏天喝到的時候可說是爽到不行。只是大部分時候都是提供超甜的紅茶，對於不太喜歡過甜飲料的我來說就完全不行了。

越南春捲米線(70NTD)

越南小吃店中被我當做心中招牌的是這道越南春捲米線，75元。春捲米線是以涼麵的形式做成，有細嫩的米線、大量生菜、酸甜醬汁以及滿滿的越南春捲。

上圖是米線的近照。跟一般用來作為涼麵的油麵不同，米線更Q、更容易咬斷，而且容易吸收他特製的酸甜醬汁，讓米線也很有味道。

越南春捲與我國的春捲有些許不同。他的內餡非常飽滿、薄薄的外皮則是炸得酥脆，有著從外表看不出來的美味。

越南春捲米線的醬汁也十分開胃，雖然他的份量並不算少，但是吃完整碗麵之後還會覺得想吃點什麼的感覺，而嘴巴內那酸酸甜甜的味道也讓人回味無窮。如果剛好那天的飲料是提供檸檬汁，那糟了，你可能要考慮一下吃完餐之後還要買什麼東西來解饞。

結語

雖然很少聽人在說，但我必須要在這邊強調一下，越南小吃的老闆娘真的很漂亮。

當然，審美觀人人不同，但是在這種與廚房、油煙為伍的環境中，大部分的廚師光是跟「熱」對抗就足以讓他蓬頭垢面。但是越南小吃中，總是能看到老闆娘化妝化得漂漂亮亮地做菜，而且老闆娘本人也長得秀麗，讓這擁擠的小店裡多了一個可看的景點(？)。

(more...)