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

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

越畫越複雜的Sequence Diagram

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

其中，第三張登入的複雜度，甚至已經分割成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 (框架)

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

撰寫網頁程式的工具很多，有些人推崇使用具有所見即得功能的編輯器來快速設計網頁介面，包括Dreamweaver、NVU (這是開放原始碼的工具喔)，但這是屬於前端介面的設計；有人也會用純文字編輯器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為基礎的PDT跟Apatana，雖然他們都是很強大的IDE工具，但很遺憾的卻跟CodeIgniter不太和。如前面所述，我猜想這可能是歸咎於CI的物件導向沒這麼正規的緣故。不過還好，另一個知名的IDE NetBeans，則可以透過PHP Documentor來提供CI的支援！

IDE for PHP: NetBeans

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

上圖就是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內建的單元測試類別來撰寫對應的測試工具。

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

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

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

專案進度與報告投影片

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

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

(SkyDrive下載)

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

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

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

(more...)

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

距離上次進度報告大概10天的時間，現在就開始這次的進度報告。

上次將Webpage Application的網站草圖(Website Wireframe)畫完之後，陸陸續續地也把Controller做完了，詳情請看KALS Wiki的資料。在畫Controller時，其實我並沒有很仔細地去構思到底該怎麼運作。在AJAX的架構中，View所在的JavaScript同時扮演了View跟Controller的角色，伺服器端的Controller反而像是提供資料的角色而已。

原本計畫完成Controller之後，我就開始進行程式撰寫的作業。目前把ERD (關聯式資料庫的實體關聯圖)畫得差不多，還再次複習了CodeIgniter使用手冊。但基於對Controller太過潦草的不安，我決定還是插入Sequence Diagram(循序圖)的任務，打算好好地檢視資料在物件之間流動的情況。特別是以下這四種情況：

1. 建立新增標註的過程（包含計算分數、推薦標註與提示等細節）
2. 接受建議並修改標註位置
3. 自動登入
4. 手動登入

由上而下的規劃方式

由於對於Sequence Diagram的不熟悉，我花了很多時間在畫建立新增標註的過程。由於StarUML跟書上寫的功能有些許不同，書上對Sequence Diagram的介紹也不是很清楚，於是我只好自己試著建立起屬於自己的表示方式。除了將上面的這張主要流程切割成其他7個小部份，對於參數傳遞與回傳值等也稍微跟標準的劃法不太一樣。目前已經完成了建立新增標註的過程的八張圖請看KALS Wiki。

經過Sequence Diagram的檢視，赫然發現標註在模糊分數計算、推薦與提示上出現了很大的問題。這讓我回頭去修改了Model的Annotation、Fuzzy跟Recommend等Class。

在之前的進度報告中，我在繪製View、網站草圖時，也常常提到回頭修改這件事情。每次回頭修改的感覺都頗令人絕望，但值得慶幸的是，我回頭只是改圖，而不是修改那數千行的程式碼。我想，這就是一種由上而下的規劃方式吧。儘管目前仍沒有實際可以把玩的程式給大家看，但這些分析與規劃的確是一步一步地讓這個系統更為穩健。

專案進度：加入Sequence Diagram

如上圖所示，跟上週比起來，加入了Sequence Diagram的工作，並將之規劃為9天的工作天，因此排擠到後面程式撰寫與可展示系統的查核點。很不幸的，如果專案如期進行，大概七月初才能將系統展示給大家看吧。詳細的專案進度，請到KALS Wiki下載。

老實說，一直畫圖，太久沒寫程式，實在是讓我覺得有點無聊。所以這次中間有幾天都跑去修改布丁布丁吃？的版面(遮臉)。那時的自己並不會使用JavaScript的callback技巧，我還蠻驚訝的。在不知不覺時，自己的程設等級似乎又無形中上升了，而這在修改以前寫的程式中也有所映證。

除此之外，老師對我在畫UML這件事情也覺得還不錯。儘管UML分析的過程枯燥乏味又無法立竿見影，急於完成論文的學生大多時候並不會選擇採用這種方式。但對於大型系統與多人合作團隊的情境之下，UML仍是一項很有力的工具。

反正我已經多留了很多時間了，也不差讓我再多用一些時間繼續繞繞遠路，學些新的玩意兒。

我也不知道這究竟是好事還是壞事。從好的角度看來像是求知欲強烈，從壞的角度來看則是拖台錢(找理由延畢)。不管怎樣，我只知道我還挺無聊的就是XD

(more...)

布丁布丁吃？ 速度優化改版

由於昨晚在幫朋友修改自動摘要功能，一時興起，就一起把整個Blog的功能都整理了一下。「布丁布丁吃？」的讀取速度緩慢，一直是為朋友所詬病的問題。連我自己都不太常直接開啟「布丁布丁吃？」，而是用Google閱讀器來找之前的文章。

這次整理有幾項改變：

• 為JavaScript加入了callback的程式設計技巧，讓網頁中的元件依序處理、顯示，而不是一口氣擠在一起處理、導致瀏覽器看起來就像當掉一樣。
• 修正自動摘要、側欄列、最新回應的一些小問題。 自動摘要變很多……但效率一樣低落XD 所以遇到讀很多篇的頁面，我會把右側導覽列的部份功能關掉。
• 修正已經被轉移的Google Page Creator網址，改用hostes網站空間，以為JavaScript跟CSS提供快取(cache)功能。
• 將相關文章改成LinkWithin的「您或許對這些文章有興趣:」：原本相關文章是抓取同樣Label隨機選取的，作法簡單。現在越來越多人用LinkWithin了，我也跟著潮流用用看。
• 加入Facebook的「讚」跟addThis的share按鈕：因為我也開始用Facebook啦。雖然只是上去玩玩遊戲、把噗浪轉過去而已。

最後使用GTmetrix來分析網站的效能(電腦玩物有詳細的介紹)，發現布丁布丁吃？的效能卡在Google Friends Connect (簡稱GFC)的顯示上。然而到目前為止，我實際使用GFC的機會微乎其微，因此我在考慮是否要改成Facebook的社群外掛元件？稍微摸了一下，好像很複雜orz 所以暫時還是保持原樣吧。

下次整裡的時候，預定會把Cbox換掉，改成由Blogger的回應來實作。概念上就是把其中一篇Blog當作訪客留言板，利用張貼意見的RSS來顯示留言，輔以張貼意見的按鈕，然後模仿Cbox的留言板介面，感覺就會像是一個小型聊天室。這樣的好處是留言板的資料會保留，而且讀取速度也會比外來的Cbox還快。但是開發這種外掛似乎也是一件大工程，等我哪天想不開時，再來使用吧。

雖然篇名寫說是速度優化改版，但其實好像也沒多快…… OTL

(more...)

把可攜式瀏覽器作為您的預設瀏覽器：Default Portable Browser

• 軟體名稱：DefaultPortableBrowser.exe 1.0
• SkyDrive下載 AutoIT Script
• 適用作業系統：Windows XP經過測試
• 適用可攜式瀏覽器：IE(特例)、Mozilla Firefox Portable Edition、Google Chrome Portable、ChromePlus

發展緣由

網頁瀏覽器的種類百百種，其中我最常碰觸的是IE、Firefox跟Google瀏覽器(Google Chrome)。但是基於硬碟備份策略，我不喜歡把瀏覽器以及瀏覽器的各種資料裝在C分割區，而是喜歡用Portable可攜式綠色軟體的瀏覽器，將之擺在其他的分割區中。除了IE沒有可攜式版本之外，Firefox跟Google瀏覽器都有不少人致力於此，諸如：

• PortableApps.com的Mozilla Firefox Portable Edition跟Google Chrome Portable
• 阿榮福利味的Google Chrome Portable
• Google Chrome的強化版ChromePlus

儘管可攜式瀏覽器讓您可以將資料帶著走，但它們的問題在於，要將它作為「預設瀏覽器」的動作卻十分麻煩。以往我是使用DefaultBrowser，但不知為何，我的Windows XP現在並不允許我使用這個套件，我推測是跟.NET Framework的更新有關係。

於是我只好參考How can I configure the default Internet Browser?跟Using Firefox Portable as your default browser!這兩篇文章，直接去修改登錄檔。修改登錄檔的手續較為複雜，所以我又用AutoIT來簡化這個程序，而撰寫成了Default Portable Browser這隻小程式，以方便有相同需求的人使用。

由於我目前只使用Firefox、Google瀏覽器跟IE，所以Default Portable Browser也只支援這三種。IE雖然不是可攜式瀏覽器，但是既然文章寫了方法，那我也就順勢地加入了這個功能。

(more...)

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

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

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

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

畫圖畫到大翻修

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

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

專案進度確認

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

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

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

(more...)

網站藍圖繪製工具：Pencil

身為一個網頁設計者，您一定有許多時候需要跟人討論網頁呈現樣貌的情況。也許強者們可以用短短的時間很快寫完一個網站，但您也可以考慮利用像Pencil這種專門用來繪製網站藍圖(Website Wireframe)的工具，讓您輕鬆、快速地「畫」出一個網站的樣貌，以便跟大家進行討論！

Website Wireframe 網站藍圖

設計網站或各種電腦軟體使用者介面(User Interface)的設計者，應該都對Wireframe不陌生。Wireframe可以簡單地翻譯成「藍圖」，或著說是「介面的草稿」。在繪製網站時，利用Wireframe來作為溝通用的工具更是常見的方法。上圖是利用MockFlow繪製的網站藍圖，單純的線條與配色讓他看起來很像是設計者手中筆記本裡會出現的草圖。

Wikiedia中對此有更詳細的解釋：

Wireframe，或著說「web ware frame」、「web wireframing」，是一種用於介面設計的簡易視覺化指引工具，可對於網站結構與頁面之間的關聯提供具體的參考。網站藍圖是用以呈現使用介面中網頁排版元件的類似圖畫。一般來說，在任何介面設計之前，都會先完成藍圖。

儘管您用紙筆、用任意的繪圖工具，都能製作出網頁藍圖。但是一般的繪圖工具要畫個按鈕、畫個捲軸，其實都不太方便。把網頁元件畫得太過抽象，畫出來的網頁藍圖也很難有具體的感覺。所以您需要的應該是更專業、更方便的網頁藍圖繪製工具，也就是本篇介紹的Pencil。

Pencil

市面上繪製網頁藍圖的工具非常多，Pencil是其中少數開放原始碼的網頁藍圖專門繪製工具。該工具具有以下特色：

• 開放原始碼就是可以免費使用！
• 可內建多種網頁排版元件，例如表單按鈕、捲軸、視窗、圖示。
  
• 常見繪圖功能：可微調元件的長寬、位置、對齊、前後、顏色、 旋轉等等。
• 背景功能：一張頁面可以疊在背景頁面上繪製，讓整個風格統一。
• 連結功能：可以指定某個元件連結到指定的頁面。
• 可作為Firefox的Add-on(這Add-on也太過複雜了！)，也可以安裝成獨立程式。
• 可匯出成為HTML、PNG、Openoffice.org文件、Word文件以及PDF。
• 跨平台：支援Windows、Linux。
• 可自行安裝Stencils(Pencil的擴充元件)以及輸出樣板。

下載與安裝Pencil

Pencil是一個跨平台的工具，他可以作為Firefox的Add-on安裝(Pencil 1.1支援Firefox3.5以上版本)，但是使用時必須開啟Firefox；也可以以獨立程式運作，而不必依賴Firefox。不管哪種，操作的介面都幾乎沒什麼不同。

• Pencil下載頁面
• Skydrive備份：Pencil-1.1.1.win32.installer.exe

安裝Stencils

除了Pencil主程式之外，請務必下載各種Stencils，讓您的Pencil擁有更多元件。

• Stencils下載頁面：各Stencils是以ZIP打包，不必解壓縮即可直接安裝。

舉例來說，如果您在Pencil中安裝了Dojo UI Widgets，就可以繪製以上的圖案。

安裝Stencils的方式也很簡單，開啟Pencil主程式之後，選擇「Tools > Install New Collection…」，並選擇您下載的Stencils的ZIP檔案，即完成安裝。

安裝完成之後，左側「Shape Collections」就會出現安裝好的Stencils囉！

Pencil操作介面介紹

Pencil的介面不算複雜，我將之拆成10個部份來講解，請對照上圖來參考：

1. 檔案管理：開新檔案、開啟舊檔、儲存、另存新檔
2. 檢視比例：放大、恢復1:1、縮小

以下是操控元件的設定：

1. 對齊
2. 移至上層、下層
3. X軸、Y軸的位置，寬(W)與高(H)，角度(A)
4. 字體顏色、框線顏色、背景顏色：各個元件皆有所不同，有時此處的顏色設定並無法生效，要直接到元件的Properties(屬性)中去設定才行。
5. 文字排版：包括類別(段落、標題)、尺寸、字型、大小等等。

以下是主要編輯區：

1. 元件區：分成安裝而來的Shape Collections與您自行設定的My Collections。使用時只要把元件區的元件拖曳到10編輯區中即可。
2. 頁面導覽列與新增頁面(New Page)：您可以在一份檔案中建立多個頁面，並在各頁面中進行連結。
3. 編輯區：主要編輯的區域。

基本上，您可以把他當作是一個預先有很多網頁元件的繪圖軟體即可。可惜他的對齊功能並沒有很強，無法像Office能夠按著Shift就以固定方向移動物件，也沒有按著Ctrl拖曳物件就能複製物件的作法，但因為工具列可以直接指定位置，所以比起慢慢拖曳，還是輸入數值會快得多。

此外，Pencil還有背景功能、匯出跟連結功能，但連結功能可能是輸出成HTML時才會用到，我並沒有實際用過。所以以下只介紹背景功能跟匯出功能囉！

背景功能

Pencil可以為某一個頁面指定背景，這背景則是另一個頁面。

舉例來說，上圖我先畫好的背景頁面。

 

接著我就可以在畫其他頁面時，將該頁面設為背景。您可以注意到上面兩張圖中的背景工具列是相同的，只是個別多了不同的訊息與表單而已。

設定頁面背景

在頁面導覽列的該頁面上方按右鍵，開啟「Properties…」對話視窗。

就能夠設定下方的Background了！

匯出成PNG

Pencil基本上可以匯出成多種格式，其中我最常用的就是匯出成PNG圖檔。以下簡單介紹他的匯出作法。

編輯完各頁面之後，選擇左上角的「Document > Expoert Document…」或按Ctrl+Shift+E快速鍵。

選擇「Rasterized graphics (PNG files)」，再按「Next >」下一步按鈕。

選擇「All pages in the document」，再按「Next >」下一步按鈕。

指定輸出資料夾之後，按下「Finish」按鈕。

等待他慢慢處理。

有時候不知為何地會出現錯誤，不過可以忽視。作完之後按下「OK」鍵就完成了。

一張一張的頁面圖就匯出到您指定的資料夾囉。

這一張就是用Pencil畫出來的網頁藍圖喔！

結語

Pencil只是一個基本的工具，但他也比起您用PowerPoint的繪圖工具慢慢地畫個捲軸、畫個按鈕，還來得美觀且快速得多。

在使用Pencil之前，我還用過MockFlow這個同樣是繪製藍圖的工具。現在許多繪製工具都是以Flash寫成，可以利用網頁瀏覽器開啟、直接線上編輯。MockFlow除了繪製網頁藍圖之外，還提供了各式各樣的藍圖範本，從Facebook的應用程式介面設計到Android手機的使用介面都可以支援，而且提供的元件又更加豐富、對齊功能又好用。但是這個專業軟體只免費提供4張頁面的繪製，超過就要付錢了。我這貧窮小民買不起，才只好摸摸鼻子來使用免費的Pencil。

總之，正所謂「工欲善其事，必先利其器」，Pencil的確為網頁設計的流程帶來不少方便。我可以用一兩天的時間把想像中的網站畫出來，以方便跟其他人討論、尋求建議，而之後也可以作為實際架設時的參考文件。如果您也常常需要繪製網頁藍圖，那麼Pencil應該是一個不錯的選擇喔！

(more...)

Plurk備份與搜尋策略：PlurkBackup + GoogleDocs

身為一個噗浪(或稱Plurk)的使用者，把生活中的大小事情都記在噗浪中，是很理所當然的事情。我早已習慣把各種資訊都丟到噗浪，不僅自己作個備份，也能分享給週遭的朋友們。然而，噗浪的使用者都知道，要搜尋早期的噗浪內文，實在是一件非常痛苦的事情。儘管每天都會寫一些資訊記錄在噗浪中，但是卻找不到自己以前寫的資料，那是多麼地不方便。

我以前使用Google Reader來記錄我噗浪的RSS，但是這種方案並沒辦法記錄到回應的內容(為了避免吵到大家，我習慣把相同的資訊用回應集中在同一串噗文中)，而且Google Reader的搜尋功能真是差到一種境界，很難想像他居然是掛著Google名號的工具。

最近找尋可行方案時，發現到了Sean製作的噗浪備份工具PlurkBackup，他可以將指定日期範圍內自己的噗文連帶回應地下載到本機端，並以HTML網頁的形式呈現。

除了備份之外，我還需要全文檢索的功能以找尋我寫過的噗文。於是我利用此工具將噗浪以月份分隔下載之後，上傳到Google Docs中，便可在Google Docs裡搜尋我備份的噗浪內容了。

以下就以圖文並茂的方式，一一來說明我的噗浪備份與搜尋策略吧！

1. 下載PlurkBackup

• 原作者Sean網頁下載
• SkyDrive備份：噗浪備份工具 v1.1

PlurkBackup是綠色軟體，下載解壓縮後便可直接執行。

2. 備份噗浪

PlurkBackup的功能介面非常簡單。請輸入帳號、密碼、日期開始與結束的範圍、選擇是否要分離私噗(私密的噗浪文)、指定輸出的資料夾位置。最後按下「開始下載」按鈕，就可以運作了。

上圖就是備份完成的網頁檔案。

使用時有幾點需要注意：

1. 日期範圍前後可對調：「2010年6月1日 至 2010年6月2日」或「2010年6月2日 至 2010年6月1日」，下載之後都會是這兩天的噗文。
2. 備份下來的檔案名稱會註明日期，以上述例子來說，檔案名稱將會是20100602-20100601.html
3. 備份時會由時間越晚越先備份。如上圖備份檔案所顯示的，7月21日會比7月20日還在網頁上方。
4. 開始下載時，該視窗將無法移動、放大縮小，甚至看起來會像當掉一樣。
5. 有時候噗浪備份工具真的會當掉！請利用工作管理員把他關掉吧。

此外，由於之後我打算上傳到Google Docs以獲得全文檢索功能，而Google Docs對於文件的大小有所限制(要轉換成Google Docs格式才能檢索到內文喔)，單一文件檔案大小必須低於500KB，所以我日期範圍是以1個月(例如：2010年5月1日 至 2010年5月31日)或是半個月(例如：2010年5月1日 至 2010年5月15日)為主，以免單一檔案大小過大。

如果您擔心自己噗浪的密碼會外洩，建議您可以先到噗浪上把自己的密碼暫時修改成暫時用的密碼(例如123456789)，然後用暫時用密碼來備份噗浪。待備份完成之後，再將密碼改回來即可。

3. 上傳到Google Docs

Google Docs提供了免費1G的空間，可讓您上傳各種資料，把他當作一個免費的網路硬碟使用。如果您還沒有Google帳號，何不申請一個來用用看呢？

Google Docs在日前的改版中，已經可以建立Folder(資料夾)了。於是我建立了一個名為「Plurk」的資料夾，專門擺放我備份的噗浪資料。

點下首頁左上角的「Upload」按鈕之後，就可以進入Upload Files(上傳檔案)的畫面。您可以在此選擇要上傳的檔案、打勾「Convert documents…」(將各種文件轉換成Google Docs格式)的選項以讓Google Docs可以搜尋他的內文、並於左下角選擇上傳目的的資料夾「Plurk」。最後按下「Start upload」，很快就可以上傳完成囉！

上傳完成，在Google Docs裡面顯示的格式就如上圖！

以後您就可以在Google Docs中隨時調出噗浪的記錄囉！

4. 搜尋噗浪記錄

將噗浪上傳並轉換成Google Docs之後，您就可以利用Google Docs的搜尋功能來找尋備份的噗浪記錄！

Google Docs的搜尋框就在上方，您可以單純輸入關鍵字搜尋全部Google Docs的資料，也可以點開「Show search options」以進入進階搜尋。

在進階搜尋中，除了指定關鍵字之外，還可以在左下角指定Search folders(資料夾)為「Plurk」，讓搜尋範圍更為明確。

搜尋的結果會列出來，表示我在這些期間皆有在噗浪中提及「詐騙」這個字眼。然而在這個搜尋結果中，是沒有辦法像一般Google搜尋一樣，能同時顯示被搜尋文字的上下文。

打開文件內文，並利用Ctrl + F開啟搜尋功能，就可以知道這篇備份中要搜尋的關鍵字的位置了。

利用這個噗浪備份策略，我得以方便地回溯之前在噗浪上零星記載的詐騙資料，並整理出昨天寫得三篇詐騙文(檢察官偵訊與法院判決書、新竹法院的調解不成立、主嫌上訴)，也相當符合我使用Plurk作為筆記、Blog作為匯整的想法。因此在此也推薦各個噗浪使用者利用這個策略來備份噗浪！

(more...)

[詐欺案件] 主嫌上訴

收到調解傳票後幾天，我又收到另一封來自於臺灣高等法院的傳票，詢問書記官之後，得知這次是詐欺案件主嫌數人提出上訴，因此這次不是地方法院而是高等法院的審理。書記官跟我說，被害人可到可不到、也沒有旅費，能做的事情頂多就是跟法官說說話而已。實際上今早的開庭也的確是如此，許多被害人怒氣沖沖也只能呆作門外，直到審判結束之後才能進去法庭跟法官抱怨抱怨。

這次開庭地點是在臺灣高等法院刑事大廈，他位於台北地方法院的隔壁，外觀內部似乎也跟台北地方法院沒差多少，但是進入時就要經過X光檢查包包是否有危險物品，可以感受到一種慎重的氣氛。

抵達法庭報到時，不意外地看到門外大概超過50多個人待在走廊等待開庭，法警面對大排長龍的受害者，一一確認報到資料。報到完之後就只能附近找個板凳空位坐下，許多青少年受害者身旁有父母陪著，大家聊天的內容不外乎都是受騙過程、金額、以及悔恨的心情。

不久，戴著手銬腳銬的犯人們鋃鐺入庭，他們都剃了個光頭，表情平靜。似乎並沒有把這一群受害者擺在眼裡——所以他們才覺得自己被判得太重了，要求上訴減輕刑罰吧？

開庭之時，法警傳喚了幾個人的名字，但大部分沒被叫到的人仍然作在外面。有些受害者擠在門外，從法庭開啟的大門間觀看，可以看到法官、被告等人，但是完全聽不清楚他們談論的內容，也就無法得知審判的過程，更不用會有在審判中講幾句話的機會。

一個小時左右，審判結束，犯人又是鋃鐺離庭，法警開始一一發回身份證、受理附帶民事訴訟，並指示有任何意見的受害者，此時可以跟法官提出。

儘管我事前問過書記官，早就知道這場差不多也是這種感覺。但是許多受害者對於自己無法觀看審查經過、也無法介入審查過程、又拿不到旅費等感到不滿，甚至有人激動地快要跟法警吵了起來的感覺。

一些受害者排隊等著進入法庭跟法官訴苦，法庭內傳來震震的怒斥聲，被害者無以宣洩的怒氣，此時只有法官等人聆聽，還是無法傳達到那些詐欺犯身上。

回來之後我查了一下司法院的開庭進度查詢，得知此案月底還有另一場審判程序。如果我們被害人仍然只是在外面坐板凳的話，那下次可能就不去了吧。

(more...)

[詐欺案件] 新竹法院的調解不成立

五月初，我收到了來自新竹地方法院的傳票，才知道原來詐欺案件還沒有結束。

傳票上面註明我是去參加調解，但是我並不知道到底要調解些什麼。那時也沒有先打電話去問書記官(傳票上面都會註明電話喔)。就傻傻地在報到日期坐車去了新竹法院，本來以為可以經由調解從被告拿回三萬元，但是調解經過讓人一肚子火，最後憤而回來寫了附帶民事訴訟寄了出去。這調解簡直浪費時間，直接告了比較快。

被告遲到，調解過程沒誠意

我在報告時間前十幾分鐘抵達了新竹法院，並完成報到手續。雖然被告還沒來，但那位看起來像是調解委員的人信誓旦旦地向我保證一定會拿回這三萬塊，讓我安心了不少。

一邊與傻殿聊天、一邊等待被告，可是被告卻遲遲不來。我們等了半個多小時之後，最後也無奈地準備離開。沒想到還好在報到處時與姍姍來遲的被告碰頭，於是又回到了調解室，開始了遲到半個多小時的調解。

到那時我才大概知道為什麼我要來調解、調解的內容是什麼。

被告是我當初被詐騙時匯入的帳戶擁有者，而被告被檢察官認為是詐欺主嫌的同夥，也就是提供帳戶的共犯，所以認定被告有罪，處有期徒刑快三個月。但由於被告的帳戶中受騙金額都是小額，法院認為他可先調解以減輕刑罰。打聽之後，發現除了我之外，還有另一位也是被騙三萬多，只是當天調解時另一位並沒有出現。

調解室裡面只有調解委員、受害者也就是我、被告三人，我跟調解委員皆認為三萬塊錢是小錢，被告應該可以輕易地拿出來。沒想到被告堅持自己無罪，也不願意花錢消災，絲毫沒有付錢讓調解成立的意願。

事實上，這種調解的確對被告不利。要嘛就是給被害者錢、減輕刑罰；要嘛就是不給錢，三個月照罰；要嘛就是三個月照罰，再加上我提出附帶民事訴訟，由法院強制被告掏錢。不管從哪種方向來看，被告都是虧。儘管這點很也很多人在抱怨，但不管他是共犯或是帳本被偷走，都是他自己理虧在先，實在是很難說無罪又沒有責任。

但問題來啦，被告就是堅持自己無罪，又不想扛任何責任。一個消息是我被詐騙的錢並沒有被領走，而是存在被告的帳戶中。由於該帳戶被結凍，被告也無法領取。因此被告提出的條件是：「法院解凍我的帳戶，把錢還我，然後我再把錢給你。」但是這種條件基本上是不可能成立的，被告在調解的過程中也很清楚這個事實。換句話說，被告真正的目的是想要靠調解來減輕罪行，又不想賠我錢。

調解過程非常糟糕，被告態度強硬、沒有協調的空間、甚至想強行曲解我的意見。我提出分期付款的調解條件，但被告顯然不接受。最後乾脆今天調解先延後，我希望被告回去想一想能不能接受分期付款的條件，但被告表示他要去找找讓法官判他無罪並賠他錢的方法。

到最後他的態度仍然令我嘆氣，因此從新竹回來之後，乾脆憤而提起附帶民事訴訟比較快。

附帶一提，調解並沒有旅費，只有證人身份才有旅費，這也讓我碰了一鼻子灰。

附帶民事訴訟

與錢相關的問題，都是民事的範圍。附帶民事訴訟是跟著被告的刑事訴訟一起跑，可以節省訴訟費，許多事情湊在一起解決，對法院來說也比較方便。

回來之後我與家人討論討論，仔細想想，如果被告堅持要法院提出錢，那我就給法院一個提出錢的理由——附帶民事訴訟。對被告來說最好的情況是法院從他被凍結的帳戶中提錢來還我，不好的情況就是被告要自己想辦法。

我從司法院的網站上下載了附帶民事訴訟的起訴狀範本，並打電話詢問書記官以獲得需要填寫的資料內容，最後事實及理由的部份則是請法扶會的律師免費諮詢來確認，然後寄到新竹法院以完成提告的動作。詳細的過程請看此串。

提出附帶民事訴訟同時，我也取消了調解，也就是以調解不成立收場。未來可能此案還會在民事訴訟時傳喚我，到時候就走著瞧吧。

浪費時間的調解

收到傳票時，一定要先去詢問書記官，看看自己被叫去幹麼？可不可以不去？不去的話會損失什麼權益？去的話能不能申請旅費？

這次調解案，如果早知道被告的態度如此之差、調解條件又這麼沒誠意，我就不會花了三百多交通費千里迢迢地跑到新竹去開庭，然後一肚子大便地無功而返。如果知道被告打算這樣，那我就直接調解請假，提出附帶民事訴訟就好。又快又省事，連書記官都認為我直接提告、不用再繼續調解拖下去比較實在。

收到傳票時請跟書記官聯絡一下，問清楚了再去法院。希望這個教訓能跟大家共勉之。

(more...)