[圖資]西文編目日誌 之一

這是為了方便日後整理心得用的。

我背後的室友高高興興地在三點多回來寢室，宣佈他已經把圖書館實習全部作完的時候，我的技術服務部份卻連一次都還沒開始。雖然這時候怪罪給推甄之類的事情是很沒意義的，但我的確是為自己的無能及無力感到羞愧：推個甄而已，居然已經累到沒辦法做其他事情去了。

在期中考之後，我總算是鼓起勇氣去找李明老師談圖書館實習的事情，而之後一頭栽入老師的程式修改大工程中，確確實實地把中文編目的實習課程拋到九霄雲外去。

「你很麻煩耶。」老師在電話一端無奈地說到，因為原本要跟著那一組因為臨時改了時間，所以我只好打電話詢問老師該怎麼辦，現在也只能苦笑地回一聲：「我也是這麼覺得。」

不管怎麼說，第一天的實習拖到11/29(三)才開始西編的我，應該已經成為館員們的眼中釘了吧。

第一天的西編工作內容主要是原始編目，館員陳小姐拿出一張張空白的題目表，要我們從書車上任選一本進行編目。AACR II已經忘的差不多的我們，整個下午都處於手忙腳亂中。儘管有個研究生的學姊，不過畢竟大家都是學生，「這樣做真的對嗎」這種揮之不去的疑慮實在是讓人感到十分無力。

我直接請小外(筆記型電腦)問問看學校的館藏目錄，雖然是很順利地找到已經編好的各項款目，但這依然無法解決「這到底是怎麼來的？」的困惑。

就在這種混亂的狀況下，一個下午就過去了，我只編了兩本書，而且還不知道對還是不對。

在說第二天之前，先說一下原本應該是第二天的那天──我因為準備輔大推甄的文件搞到精疲力盡，本來還想硬撐著去實習，不過後來還是請假後直接倒在床上。

所以12/1(五)的實習，我就請假請掉了，十分爛的理由。

所以本來12/6(三)應該是第三天的實習，變成我實際上的第二天。

今天的西編改做Main Entry、Added Entry、Subject Added Entry (name-title)判斷的作業單。這在大學一年級資料組織的課堂上有教過，雖然因為時間久遠記憶有點模糊，不過規則判斷上並不困難：

1. Main Entry：主要款目，用來做科特號的依據。如果有原作者，則記原作者。如果沒有原作者，則記標題第一次(非冠詞)。如果是傳記，則記被傳者。
2. Added Entry：附加款目。如果原作者有兩位，則此處記第二位。如果Main Entry記標題，則此處記編者、傳記者。Added Entry可以重複，允許紀錄一個以上的款目。
3. Suject Added Entry (name-title)：記錄標題中的人名。

在實作的過程中，我發現規則上的問題還不算麻煩，麻煩的是英文人名的辨識，以及是否為傳記的判斷。這些過程實在是很打擊自信心啊...

最後在大家通力合作下，總算把實習的作業單寫完了，也提早半小時離開。

接下來...希望明天下午可以順利實習啊...

附錄：常用西編工具

1. http://www.ubka.uni-karlsruhe.de/hylib/en/kvk.html
2. http://connexion.oclc.org
3. http://www.itsmarc.com.sg
4. http://dictionary.reference.com/translate/text.html
5. http://babelfish.altavista.com/tr
6. AACR II
7. Cutter Table
8. Converision Tables
9. DDC

[圖資] 政大圖檔所面試細節準備

在檢討今天跟林老師和隆基助教前測時所遇到的問題之前，我先講一下打電話給政大圖檔所詢問助教以及從學姐那邊所獲得的情報吧。

12/8(五)週五的面試，一個人約十幾分鐘。如果要用Power Point，必須自行準備筆記型電腦。也可以到時候另外印大綱、面試資料給面試官看。政大圖檔所的位置在政大後半部的山坡上，聽說政大入口處有小巴士，可以讓你不用在面試前就爬山爬得氣喘吁吁。學姊的建議是坐到文學院的後一站會比較近，可是似乎並不是很好找，請提早過去以免到時後找不到試場吧。

順便把政大的校內地圖貼過來吧，圖檔所的位置在山上校區的百年樓，別搞錯囉： (點擊圖片連結可以放大)

山下校區	山上校區

另外附上政大的交通資訊，看不懂得也可以查查網路地圖，我習慣用Yam蕃薯藤-活地圖 (政大地圖連結)。另外也提醒大家要記得攜帶准考證，再要不然要記得帶身分證做補辦(泣)。

這篇已經變得很長了，那面試草稿就另外開一篇講吧。

[圖資] 政大圖檔所面試草稿

以下是我試著擬出在政大圖檔所面試時可能的問題與預設好的回答。也許可以作為其他要參加面試的同學的參考，不過因為我個人的經歷還算不少，所以講的東西就比較不普遍、不泛用。另外，在接下來的元智資傳、輔大圖資丙組的面試中，要回答的內容也會有細節上的差異，因此到時候會再另外撰稿。

明天就要跟林老師做前測，晚上花了好長時間訓練的結果，總算是有點自信。明天就以正式打扮，好好地出擊吧！

以下就是我擬的面試草稿，請大家多多指教！

Q: 請簡短地自我介紹一下。

A:

• 我的名字叫做陳布丁，目前就讀輔仁大學圖書資訊系。
• 專長是電腦程式設計，主要是在於網站資料庫的架設上，有許多實作的經驗。
• 在大學的時候，我參與林麗娟老師的國科會計畫團隊，歷經三個研究計畫，主要負責老師研究所需電腦方面的支援，包括伺服器架設與網站的撰寫。
• 另外我也參與過李素貞老師的輔仁大學英文卓越教學計畫的英文導讀部份，負責的是網站重整與架設。
• 我也擔任系上電腦助教李隆基助教的助理，輔助助教管理電腦教室的六十幾台電腦，並且維護夜間電腦教室的秩序。
• 現在我則是正在進行國科會大專生專題參與計畫，研究名稱是「網路非同步互動引言機制之建置與學習」，這是在網路非同步教學環境中，以引言機制提供學生與學生互動，分析其對主題延續性、深入性影響的研究。
• 以上是我簡短的自我介紹。

Q: 你說你的專長是電腦程式，可是本系在這方面恐怕難以給予你支援，可否請你說明一下你選擇本系的理由。

A:

• 在剛剛的自介當中我提到我的專長是電腦程式，對我來說，電腦程式是一種幫助我解決問題的工具，但是我所欠缺的，卻是如何應用的能力。
• 貴系的研究風氣在學術界中頗負盛名，我希望在貴系中學習、訓練我在圖書資訊理論上面的能力，輔以我在電腦程式方面的能力，發揮出更為廣泛、深入的應用，讓自己的知識能力更上一層樓。

Q: 可否更詳細說明一下你的國科會計畫？

A:

• 這個研究的名稱是「網路非同度互動引言機制」。
• 研究對象是以網路非同步討論區進行授課的課程，教師指定學生要在課後上網討論、蒐集資料，以完成期末的報告。
• 而我在這個討論環境中，加入「引言機制」。這是一個可以幫助同學網路上討論時，明確地指出他是在對誰說話的一種溝通功能。
• 我認為這種互動，可以滿足學生個人化互動的需求，就像我們討論的時候也是習慣面對面一樣。引言機制可以幫助討論主題的衍伸、持續，而達到更好的互動效果。
• 目前研究完成資料蒐集，接著要進行資料分析的步驟。
• 以上是我的國科會計畫的介紹。

Q: 請問你在這個計畫當中學習到了什麼？

A:

• 在文獻分析方面，我實際地運用在大學課程中教授的資料搜尋方法，包括實體期刊文獻與線上資料庫的使用。
• 研究方法方面，我則是深深地感覺到自己能力的不足，尤其是在於引言機制的評鑑分析所需要用到的質性研究方法，我發覺難以讀書自修，因此目前我也在自己系上的研究所旁聽質性研究課程，將學習內容應用到正在進行的研究中。
• 其他還有很多事情，以上這些是我認為值得一提的事情。

Q: 說說看在這計劃當中，讓你印象最深刻的事情。

A:

• 主要是體會到研究能力之不足的部份。
• 我常對於理論的組織感到困難，例如在撰寫文獻分析的時候，常常因為無法找齊足夠、充實的理論架構，而時常需要求助於老師們的指導。
• 為解決的方面的問題，一方面我認為要更加充實自己的學識，另一方面，我需要更多的訓練。這也是我希望進入研究所深造的原因。

Q: 請問你在林老師的國科會計劃當中學習到什麼？

A:

• 在林麗娟老師的國科會計畫團隊中，我對於老師進行學術研究嚴謹的態度與豐富的學識感到佩服。
• 這個團隊中除了我之外，都是研究生的學長姐們。在與研究生的互動中，讓我對於研究所的學習方式有了一定的認識。
• 這些因素讓我對於學術研究環境有所嚮往，所以希望進入貴系，繼續深造。

Q: 請問卓越教學計畫是什麼？你這個計畫當中學習到什麼？

A:

• 卓越教學計畫是以教材上網作為輔助教學的方法。學生可以在這網站中閱讀教師指定的教材，並且提供學生撰寫筆記、心得的功能。
• 卓越計畫的主體是一個原型網站，為了讓這網站符合李老師的授課內容，我的任務便是將網站解讀、與老師溝通分析老師的需求，再進行網站的重整與建置。
• 這個計畫的原型網站是由外面專業公司設計的大型系統，在解讀的過程中讓我學習到不少程式上的技巧。而另一方面，由於李老師對於電腦並不是十分熟悉，為此我與老師花了很多時間在溝通上，藉此培養我在實務溝通的能力。
• 以上便是我在卓越教學計畫中的概況。

Q: 請問你在擔任助教助理管理系上電腦教室的過程中學習到什麼？

A:

• 管理系上六十幾台電腦是相當難得的經驗。這與以往我只管好自己的兩三台電腦不同，大量管理電腦需要更多的技巧與耐心。
• 在隆基助教的教導之下，我學習到不少電腦軟硬體方面的知識。對於基本的電腦維護、建置，我有著相當的自信。

Q: 請說說看你在大學時候參與過的社團活動？

A:

• 我在大學的時候參與輔大圖資的圖書館服務隊。這是一個自願性質的團隊，任務是將偏遠國小機關的圖書館進行自動化的重整工作。我出隊過兩次，擔任過生活與資管的職位。
• 另外我也參加輔大動漫電玩研習社，與動漫畫、電玩的同好們一起舉辦過不少活動，努力在校園中推廣動漫電玩的正面意義。

Q: 請問你在參與圖書館服務隊的過程中學習到了什麼？

A:

• 圖書館服務隊的出隊經驗中，我深刻地將課堂所學的知識應用在於實務經驗中。
• 此外，也學習到許多課本上難以傳授的實務技巧，對於圖書館員的工作有著更深一層的認識。
• 我在圖書館服務隊中學習到的，主要就是這兩點。

Q: 請問你所參加的動漫電玩研習社，對於你的學業有何幫助？

A:

• 動畫、漫畫、電玩在本質上算是一種藝術性創作，對我來說就跟書本一樣。
• 當初大學選擇圖書資訊系的原因，便在於自己對於動漫畫資料整理上的喜好，才想要進入這個領域。
• 此外，動漫畫的故事內容開拓了我在人生方面的見識，培養我對於藝術的美感。電玩更是我學習電腦程式的契機。
• 這些都是動漫電玩對於我學業上的幫助。

Q: 請說明一下你進入本系的研究計畫。

A:

• 我想探討現在學位論文當中引用Wikipedia維基百科的行為。
• 維基百科，就如他的副標題：「自由的百科全書」一樣，具有容易近用、人人可編輯、維護資料的特色。然而也因為如此，維基百科在權威性上，一直備受爭議。
• 然而在博碩士論文網中，卻可以找到七百多筆的學位論文，都有參考維基百科的內容。
• 在學位論文如此嚴謹的審查過程中，是否意味著維基百科在學術地位上已經具有一定程度的認可。換個角度來看，維基百科這種以多人協力創作知識的運作模式，是否有著足夠權威性的參考價值。
• 我計劃透過問卷與訪談的方式，了解這些學位論文的撰寫者對於引用維基百科的看法，並歸結出維基百科的優勢，作為未來在發展多人協力知識創作運作模式的參考。

Q: 這個研究計畫與你的專長似乎不太相關，你有什麼理由嗎？

A:

• 這是因為我時常碰觸電腦程式的資訊，對於網路上熱門的Web 2.0應用，也是我十分感興趣的主題。
• 而維基百科在Web 2.0當中可說是一個典範，他以簡單的程式技術，發揮出無限可能的應用，這正是我嚮往、想要學習的目標。
• 因此我以維基百科作為我研究計畫的對象，研究其相關的價值。

Q: 你進入本系之後，想要研究的方向是？你認為本系可以提供你哪方面的支援？

A:

• 我想研究的部份，分成兩個方向。
• 一個是繼續我在電腦資訊方面的深造，而貴系的陳志銘老師對於資料探勘及檢索的專業，希望可以給予我在資訊相關技術上的指導。
• 另一個則是延續我的研究計畫，研究維基百科的使用情況。這部份牽涉到書目計量學的領域，而這正是貴系蔡明月老師的專長，希望我能在蔡老師的指導中繼續深造。
• 以上便是我計畫未來的研究方向。

Q: 可否說說影響你最大的三位老師？他們是怎麼影響你的呢？

A:

• 第一位是現在擔任輔大圖資系系主任的林麗娟老師，我從大二開始便參與了老師的國科會計畫團隊，老師注重我在做中學習的過程，給予我許多發揮所長的機會。
• 第二位是資深教師高錦雪老師，老師十分關心學生，並常講述她豐富的教學經驗，讓我對於學業及人生態度上有著相當大的影響。
• 第三位是我的大學導師陳順德老師，老師以對於業界的豐富經驗，常常教導我在資訊實務上的新知，讓我在校園內所學跟得上外界的腳步。

Q: 貴系輔大圖資也有研究所，可否簡述你選擇本系而非輔大圖資研究所的理由？

A:

• 一方面是嚮往著政大在學術研究上的風氣，我們系上也有不少學長姐就讀貴系、學有所成。
• 另一方面則是希望改變自己的跑道，將自己從電腦資訊的技巧轉移到應用的理論，以此期許自己能夠具備理論與實務上的能力，更加充實自我。
• (可能會有人說：「明明輔大圖資也可以啊！」的這種話，因此我在回答上並不是以否定輔大圖資的價值，而是將重點放在自己希望到更好的環境中，以表示就讀的決心。)

[圖資]輔大推甄繳件完畢，接著準備政大口試

儘管風波不斷，但總算是繳完了...

我說...到目前為止，每一次的推甄都是在跟死線搏鬥，並不會因為輔大的推甄可以沿用之前寫好的資料，而準備會更輕鬆。我想這主要還是因為老師說的：「你這小子居然每所學校都準備一個題目(大笑)」。說來無奈，政大圖檔所跟輔大圖資丙組的取向有差，不能共用題目，而老實說我是比較喜歡後來想到的「推薦式互動機制」，雖然跟圖書館有點差距，不過可以的話，未來論文我也希望走這一塊，往技術領域更加精進。這次的研究計畫跟很多人討論過，雖然也因為如此，花了相當多的時間在這上面。不管怎麼說，總算是繳出去了，鬆了一口氣。

接下來是口試呢，下週二請林老師幫忙測試口試，在這之前要準備好衣著、題目問答、Power Point等。口試的題目我跟sealing討論了不少，甚至連睡覺的時候都還夢到我怎樣回答老師的問題。

先來講一下Power Point的重點好了，根據助教、學長的經驗，口試約10分鐘左右，而Power Point簡報的時間最好拿捏在7分鐘，頁數約7~8頁、一分鐘講一頁即可。口試的重點在於推銷自己，因此要講重點，把你最有價值的部份在這7分鐘裏面報告完畢。剩下的3分鐘則是給老師提問。老師會針對你的自傳、研究計畫提出疑問，尤其是在書面資料上描述不夠完整的部份，則有可能會被老師拿出來問，也就是說，口試的時候也是可以彌補書面資料之不足，甚至也會有誘導老師發問的策略性技巧可以使用。

除此之外，如果書面資料寫讓老師不知道要問什麼的話，則有可能會出現泛用型問題。我覺得這方面的問題就比較枯燥了，因為大家回答起來應該都會大同小異，老師應該都已經聽到耳躲長繭，可是想標新立異回答其他內容又顯得沒誠意。自傳書面資料的部份我是自信滿滿，畢竟那都是用自己的血與肝換來的紀錄表現。研究計畫的內容倒也不是這麼難回答，甚至我覺得我寫的蠻淺的，得想些更深入的理論來應付問題。讀書計畫比較容易被泛用型的問題問到，因為讀書計畫也寫的很泛用(汗)。

學長也說了，面試是看誠意與應變能力，就快樂的給他犯錯吧！

最後再把行事曆拿出來看看吧...可以發現一些端倪：

1. 口試順序：政大→元智→輔大
2. 政大放榜隔天是輔大口試
3. 輔大到明年1月放榜
4. 國科會計畫死線將致

呃...

[日記]雨季←→換季←→面試

隨著雨季的來臨，季節也越來越有冬季的感覺。本來在一個月之前就打算換季了，不過因為懶得去打開衣箱，拖到要面試之前才硬著頭皮來找衣服。

面試？是的，下週五12/8我就要去政大圖檔所參加口試，看准考證號碼我還在最前面，實在是很棒的安排，早上出完糗就可以回家了XD。面試要穿著很正式，大家都這樣說。我平常的衣服實在是很拉塌，居家型的Frontier 星華 T-Shirt加上彈性運動休閒長褲，不論是顏色或款式都沒有在考慮的，只要可以穿就好，不過現在可不能這樣了啊。

要挑衣服其實也不難啦，對於常常在看動漫畫之類作品的人，對於好看的人物自然會留意一二。除了二次元美少女之外，美少年或是成熟的帥哥我也是會很欣賞的。

嘴砲歸嘴砲，實際上我還真的是很少在考慮衣著的。就連麻痺裡面的女兒也是素色長袍of the year(見右圖)。理由不外乎跟現實狀況一樣：沒錢空間少。而且下意識的認為外表不重要的緣故，不管是自己或是女兒都沒什麼在打扮的...嗯...總之這樣是不行的啊。

話說回來，翻了翻自己的衣箱，可以用的裝備只有黑色長褲、純白襯衫、布製皮帶，搭起來十分之奇怪。主要問題出在襯衫，買個藍色或什麼的也好，純白就是不太搭(而且很容易髒)。外套在口試會場不會穿進去，所以穿平常的應該是ok啦。鞋子只有登山布鞋，可以的話還是要有皮鞋等級會比較好。

趁這個時機是該換裝備的時候了，不過自己去挑不太穩，其實還是要找人一起去會比較好，要找誰好呢....

[圖資]探討互動因素對與多人使用者資訊尋求行為之影響

呼...隨著推甄的進行，在反省上次的失敗之後，得要表現得更好才行。

輔大的推甄是從11/28(二) 10:00~12/1(五) 15:00，網路報名的位置在輔大招生網站。系上跟政大一樣，要求考生繳交一份研究計畫。

上一份政大圖檔所推甄的研究計畫，我是想從以博碩士論文引用Wikipedia 維基百科的情況，來看看學術界對於維基百科、以及用眾人集體創作知識的價值所在，可作為用集體創作發展數位典藏方案的理論基礎架構。這篇研究計畫的詳細的目的我還得想一想，怎樣都覺得寫啊寫的就矛盾起來了。

輔大的推甄，我想把研究重心放在自己熟悉的領域上，所以興起了改題目的念頭。題目就如標題所寫的：「探討互動因素對與多人使用者資訊尋求行為之影響」。以往的使用者資訊尋求行為之研究，往往把使用者視為單一對象的個案來分析。然而在現今通訊發達的時代中，有著多人共同的資訊尋求行為的情況是十分常見的。因為你研究的東西、想知道的東西通常很多人也會會想知道。而這些人可以透過種種管道進行交流、互動，不論是詢問他人以求幫助、或是協助他人解答疑惑，我覺得以群體的角度來看資訊尋求行為是有必要的研究的。在使用者個人對於資訊的尋求行為研究，已經是圖書資訊界常見的菜單，只是不斷地把使用者與資訊套用在不同情況做延伸。我想換個角度，試著以使用者之間的互動如何影響資訊尋求行為這點進行探討。這個研究必須釐清幾個方面的主題：

1. 什麼情況叫做團體知識的創造？ 也就是上述中，很多人追求共同目標的資訊尋求行為
2. 什麼情況叫做互動？ 互動的方式有很多種，在這邊我想以我自己熟悉的文字交流的互動方式。可以從文獻中探討出在以文字為主的溝通有什麼互動方式。
3. 要怎樣去判斷使用者間的互動對於資訊尋求行為之影響 要從量化的方式看統計數據呢？還是要用質性的焦點團體訪談法呢？當然，也可以先從文獻探討中找到起點。

先由從文獻探討中定義好以上的主題面，然後便可以找尋研究的對象、觀察其行為是否能夠表現出互動對於資訊尋求行為之影響。研究對象必須符合：(1)群組有著共同的資訊尋求需求，通常是有著共同的目標；(2)以文字為主的互動方式，如網路討論區；這呼應到我之前所說的熟悉領域，因為林老師拿手的Program-Based Learning問題導向學習正好很符合我想要觀察的研究對象，而研究方法也應該與我目前在做的研究相去不大，只是著眼點不同。

嗯...大致上是這樣子的。這個研究主題的靈感其實來自於網路遊戲，為了解任務、提升自己的等級，大家都有共同的目標，然後常常會有協助別人找尋攻略數據等行為發生，或是從協助者告知他人資訊位置的身分改變成資訊的產生者，而這也是巴哈姆特電玩資訊站遊戲版面裡面常見的行為。

將研究回歸於自己熟悉的領域，要講這個的話，我面試的時候就很有把握了。不管怎麼說，得趕快寫成研究計畫，不要趕不上報名時間了喔。

2006.11.29 (三) 問題出現了...

如果我要推丙組的話，那麼就得把重心涉入技術層面的問題。剛剛跟宏偉討論的結果，上面這個題目我可以從兩個切入點作系統的設計：

1. 互動因素的系統設計：如果要研究的是互動對於資料尋求行為的影響，那麼就要建置出這樣子的環境。互動的方式可以從文獻分析中找到，然後想辦法把它實作出來，這部份就是需要技術實作的地方。這個部份的重點是要先釐清有什麼互動的方式、理論來源，再來進行實作。我現在腦袋裏面只有想到用AJAX提升討論區使用體驗的這種事情...

2. 事後分析的作法：在討論區使用過後必定會有紀錄檔，那麼要如何從這個記錄檔當中找出規律呢？我收到的關鍵字是「事後分析法」、「不介入觀察法」，可是實際上要怎麼操作，似乎還是很模糊...

不管怎麼說，先試著寫一份給老師看看吧。

[圖資] 專業倫理期末報告題目規劃

我想朝圖書管理面電腦讓使用者自己玩的問題。

常常會看到，有人會用圖書館的公用電腦來玩遊戲、爬BBS。自己也遇過想查個館藏目錄，卻因為別人在寫信寫太久而沒電腦用的窘境。館員到底該不該趕呢？館員要怎麼判斷使用者是在正常地使用電腦呢？那些規範是怎麼定出來的呢？這些都是我想去探討的因素。

其實是因為在5A管電腦遇到的經驗，把它套到圖書館理面這樣。

就這樣決定囉 OwO

[日記]數獨消去猜測法

開新視窗連結 以JavaScript撰寫，用消去法與猜測法搭配回溯法進行運算數獨解答計算程式，是以前用n-Queen演算法的程式進階版本。

請幫忙找找可以考倒他的題目吧，SUDOKU 數獨 Online 這個網站的hard++可是非常的難喔！

虛擬碼：

1. 初始化：
   1. 畫好表格，從[0][0]到[8][8]，第一維為x軸，第二維為y軸，每格都有已檢查標籤，預設值為false
   2. 宣告紀錄堆疊
   3. 填好題目
   4. 將空格的值填入123456789
   5. 如果全部都是空格，表示沒有題目，把[0][0]設為1表示題目
2. 消去法：
   找到可能數字最少的一格，而且不能為9個全滿
   1. 如果有，設該格可能數字數量為n
      1. 檢查同x軸、同y軸、同九宮格的數值當中，是否有n個與該格的值同樣的格子(已確定數字)
         1. 如果有，那其他格就刪去那些值
         2. 如果被刪去值的格子可能數字的數量有受到影響，則取消已檢查標籤
         3. 在進行刪去動作中，如果有格子被刪掉沒有可能數字了，則進行回溯法(4)
      2. 該格設定已檢查標籤
      3. 進行消去法(2)
   2. 如果沒有
      1. 進行猜測法(3)
3. 猜測法：
   1. 找到
      1. 沒有已檢查標籤，且可能數字數量為1的一格
      2. 可能數字最少且大於2的一格
   2. 將目前的陣列儲存進記錄堆疊中，也記錄找到的那格的座標
   3. 猜這格的第一個數字為該格的答案
   4. 取消該格的已檢查標籤
   5. 進行消去法(2)
4. 回溯法：
   1. 用紀錄堆疊將陣列恢復到上一個儲存時的狀況
   2. 將當時儲存時的該格的第一個數字刪去
      1. 如果刪完還有可能數字
         1. 取消該格的已檢查標籤
         2. 進行消去法(2)
      2. 如果刪完沒有可能數字了
         1. 進行回溯法(4)，再回溯到前一個陣列的狀況

講完了，這並不是很標準的虛擬碼，只是概要說明而已。

就如你所看到的，基本的作法就是用已確定的數字把其他可能數字刪掉。如果已經沒有已確定數字了，再來猜測。如果猜錯了，那就回溯，就這麼單純。

這個程式我加了很多額外花俏的東西，包括你在網頁上看到的所有視覺效果。雖然可以直接從網頁上看到JavaScript的原始碼，不過應該會被這些花俏的功能弄很混亂。

接下來說說心得吧...

今天花了一整天的時間寫這個程式，很難得地寫到想吐。JavaScript在程式語言裡面算是結構很鬆散、非常自由的一種，所以只要一把程式寫大，就會有很多問題發生。今天最常遇到的是：

1. 陣列前面不可以用變數宣告 var
2. 要使用陣列前，必須要先new Array
3. 函式裡面的變數要加var，以免變成全域變數影響其他函式進行
4. split()切割時，會保留原本的切割字元

光是這些問題，要一一設檢查點alert()來檢查，就做到想吐。不過最後還是給我做出來了，JavaScript的程式能力又升了一級。

這個程式會隨著計算時間增加，程式給電腦的負擔也會越來越重，看你電腦等級到什麼程度。那個時間設定擺著很心酸，因為這程式額外的動作很多，所以很難10毫秒就可以計算一次。我的筆電算到500次計算以上，速度就會降到1秒計算一次，算到1000次以上更是讓人看了想睡覺，連打字都很吃力。不過還好，可以把停止執行打勾，電腦就會恢復正常。

這個程式目前解過最高的計算次數為1349次，題目為SUDOKU 數獨Online的#5264。雖然會為程式連這麼難的計算都算得出來而感到開心，可是就如朋友所說的，一個數獨要猜就不好玩了，這種要猜超過50次才猜得到正解的數獨根本就是給電腦算的，真不有趣，看來這是題目設計上的問題啦。老實說，我用手算過的數獨才只有三題，這是典型的遇到問題就用電腦解決的逃避行為啊。

這個解答演算法的猜測法還有待改進，可以先從影響其他格可能數字最多的那格開始猜起，不過這個計算不像人可以用眼睛看的那樣輕鬆，尤其是在JavaScript這個低效率程式上更是如此。如果能搭配資料庫強大的運算能力，那麼實作上就比較有可能了。

完成了這個程式，不過其實並沒有什麼成就感，大概是因為debug的挫折太讓人吐血了，所以一點也開心不起來。另外一個晚上都看著那個數字一直跑，越看越頭昏，使用的時候請小心啊。

對了，有人可能會問我說，為什麼要寫這個程式？其實這個演算法是很早以前就想好的，只是一直沒有時間實作。趁今天空檔，趕快把腦海中的想法寫出來。既不是作業，也不是賺錢的CASE，也沒有要幫誰作，只是單純地想寫出來。後來才想到既然我要推甄的話，那麼這個作品應該也可以幫點忙吧。

今天是寫數獨的解答程式，改天來等數獨題目看多了之後，抓到出題的訣竅之後，我也來做做看數獨的出題程式好了。

[圖資]瓶頸...

我覺得我必須開始面對瓶頸...一個不得不去跨過的瓶頸...

今天質性研究要講期末報告的研究方法，大約10分鐘的時間，把你的研究動機、目的、問題、研究方法設計以及你研究參考的文獻列出來即可。

我要研究的東西很明確：把國科會的研究再拿來做，重新好好地設計內容分析與訪談方法即可。看著我在半年前懵懵懂懂地寫完十大面的研究計畫書，覺得半年前的我為何可以把這東西寫得這麼漂亮，但是現在的我卻不知道該怎麼著手報告研究內容。

你可能可以看出端倪了，有明確的東西，但我卻不知道該怎麼做。

在研究計畫書當中，不論是問題範疇定義、文獻分析探討、訪談主題都已經寫得明明白白的，但是我卻不知道該如何去報告出來。連學長都說：「那不是已經很清楚了嗎？」可是我就是不知道該怎麼做。

很矛盾是吧，有明確的東西，卻不知道該怎麼做。

不知道是不是時間壓力還是最近程式寫太多造成邏輯脫離研究的思考模式，從小學我在老師的評語中便是「做得不錯，可是起步很慢」，我覺得我現在遇到的問題已經不只是慢，是少了根名為「研究者」的螺絲。

我拿以前在程式課程的學習經驗來比較，演算法課程老師上到n-Queen，我就可以寫出數獨；可是質性研究的課程，教得我懂，什麼訪談時利用關鍵事件讓受訪者回憶、分層立意抽樣、信度與效度用的三角檢定的我都可以理解，而且多少有過經驗，但我卻很難把它套用到今天要報告的，我想要改進之後的研究內容裡面。

今天的報告我自己覺得不太滿意，並不是什麼時間不夠之類的，而是我覺得我的思考模式一整個就是問題。我常常會想要先把這東西「理解」之後再開始動作，程式語言因為單純、好理解，所以應用起來很快。可是牽扯到高層次的方式、技巧，我就很難去理解，或著是說，自己內心就會覺得這種方法「太過深奧」、「不能理解」，進而下意識地排斥進行這方面的研究。

可是這樣不行啊...如果不克服這個弱點的話，那麼人生可以玩的東西又會少了很多...我不想一輩子都只會說低階的程式語言，也希望自己會打打嘴砲、唱唱高調，說些騙人的理論之類的...

唉...我太不會打嘴砲了...

[日記]寫程式是會讓人廢寢忘食的...

我在打電動的時候，常常會有這種情況發生：「再等一下，我把這關打過就好了。」同樣的，寫程式的時候也會出現這種情況：「再等一下，我把這個BUG修正就好了」。

上上週開始我著手修正林老師的大家e起來記分系統，把舊資料庫設計造成的種種沒有彈性與錯誤計算的部份改過來，在資料處理這個部份做全部的重寫。

因為主要修改的是要處理的資料，所以特別重視資料的輸入與輸出規格。作法很固定：

1. 理解這個網頁所需要顯示的變數
2. 理解這個網頁所需變數的來源方式
3. 將這個來源改成新資料表使用的模式

問題是在於，學長的程式墜碼及排版上常常讓人不好解讀，也時常缺乏重複使用的概念，有些太過複雜的網頁我就乾脆捲起袖子重寫。

基於方便後來的維護和修改，我開始養成一些習慣：

1. 將程式用分隔線------切割成各個區塊：這算是很久以前就養成的習慣吧。當程式很大塊的時候，光靠{ }是很難辨認出誰是誰的。除了用分隔線區分區塊之外，在各個小步驟前也都用行註解(//)來說明這部份的標題。不過大多時候會覺得自己寫這類的說明都很奇怪，程式語言寫多了，反而不太會用人類語言表達，就像我現在寫東西就怎樣都覺得哪裡怪怪的。
2. 在程式前宣告使用變數，表示輸入；程式最後則是輸出。如果什麼都不說，直接就在程式中間使用變數，會造成很多混亂。PHP雖然給予程式寫作者很大的自由，可以不宣告就直接使用，但這還是對閱讀、理解、維護上造成許多困擾，養成正式寫作的習慣是很重要的喲。

不得不說的是，這個討論區到最後會變得這麼亂，多少自己也有維護不周的責任啊...

就社會價值觀來說，寫程式可是比單純的打電動來得正當多了，你想想，「昨天熬夜寫程式」跟「昨天熬夜打電動」，這感覺上就是有次元等級的差別......隨便啦XD

「不管做什麼都要注意身體」，好像哪個人會在那邊碎碎念一樣的提醒浮現在腦海裡。是啊，不管是什麼事情，熬夜就是不對(點頭) 不過明天又有一個大報告...(昏)