:::

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

布丁布丁吃布丁

1 Comments

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

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

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

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

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

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

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

(more...)

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

布丁布丁吃布丁

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

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

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

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

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

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

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

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

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


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

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

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

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

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

(more...)

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

布丁布丁吃布丁

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

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

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

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

就這樣決定囉 OwO

(more...)

[日記]數獨消去猜測法

布丁布丁吃布丁

0 Comments

[日記]數獨消去猜測法

開新視窗連結 以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,也沒有要幫誰作,只是單純地想寫出來。後來才想到既然我要推甄的話,那麼這個作品應該也可以幫點忙吧。

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

(more...)

[圖資]瓶頸...

布丁布丁吃布丁

[圖資]瓶頸...

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


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

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

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

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

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

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

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

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

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

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

(more...)

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

布丁布丁吃布丁

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

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

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

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

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

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

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

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

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


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

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

(more...)

[圖資]圖書館專業倫理期末報告消息

布丁布丁吃布丁

[圖資]圖書館專業倫理期末報告消息

簡單來說,就是要寫一篇探討圖書館相關倫理的報告。

選擇一個問題為中心,從生活或你看到的文章中找三五個足夠說明你這個問題的實例狀況,把要探討的問題描述。然後說明你想怎麼處理這種情況的方法。可能會牽扯到法律,不過寫的時候不要太專注在法律條文上,畢竟這不是我們的領域。

寫作方法要正式,A4、12pt、1.5行距,註釋清晰。

期限:期末考那天(1/15),請交給布丁(就是我)。

(more...)