論文進度報告(2010/10/10)：幾乎完成工具列

繼上次的進度報告之後又隔了兩個多禮拜，最近也是一直在研究JavaScript的基礎技術，然後一邊在Blog把整理好的東西寫出來，希望能給一同鑽研JavaScript的程式設計師作為參考。評估各種寫作方式並訂定之後，就是繼續兩個禮拜之前停頓的進度，而繼續把工具列的部分完成。現在工具列只差「通知」功能尚未實作，但這是要等標註功能實作之後才會有通知，接著才是繼續完成這部份的功能。接下來就是要整理標註功能的UML了呢，又是一項大工程。在這之前，先來整理目前的論文進度吧。

目前的WebApp端的進度

元件	預估程式數量	已完成	UML類別圖
toolkit	17	17	1
core	15	13	1
kals_window	6	6	1
kals_toolbar	30	24	2
kals_text	38+?	0	3
search	6+?	0	1
統計	112+?	60 (53.5%)	9

整體來看，目前完成了大約一半的程式。由於使用物件導向架構開發，每個細節元件都是取用於toolkit或core中的上層元件，在開發同時也會不斷地改良這些元件，因此系統開發的速度會越寫越快。當然，這只是理論上而已。

也許會有人注意到類別程式的數量跟之前比起來有所減少，從之前的114降低到了112。我嘗試簡化系統的功能跟開發的方式來讓整個專案能更快完成，目前是將「自訂外觀」、「個人相片」的功能取消，暫緩適應小螢幕的功能調整(toolkit設計時有考慮小螢幕，但不一定每個功能都能適用就是)；而開發中也只對關鍵功能設計單元測試，並且緊對Firefox進行測試，Chrome、IE、Android則在未來有機會時再進行統一的檢查。

上圖是kals_toolbar中navigation的UML類別圖，這是工具列上各個視窗的功能設定。其中灰字的類別則是暫停開發的類別。詳細的UML類別圖，請參考KALS Wiki。

至於專案時程仍暫時維持在19天後完成，也就是10月29日。能不能完成我也沒把握，只能說盡力而為而已。

一改再改的JavaScript物件導向繼承寫作方式

一開始我的JavaScript是用最原始的prototype繼承法，但是由於這種方式在使用上會有些問題，而且我需要使用上層類別的方法，所以又花了一段時間回頭找尋相關資料學習。

首先學習到的是call跟apply的用法，但是發現到JavaScript仍有傳址問題存在，所以又把所有的屬性與方法寫在類別的建構子裡面，不過那將會造成系統資源大量消耗的問題，不得不再找尋新的方法。

接著找到的是Dean Edwards的Base繼承類別，他的確是很好用，寫法簡潔明瞭、又有呼叫上層類別方法的this.base()可使用，但是我使用的Aptana Studio看不懂，而我另外又試用了五六種JavaScript IDE，一樣是看不懂。儘管我後來找到讓Aptana Studio能夠理解的Base繼承法，但是最後仍毅然決然地使用最原始的prototype繼承法。

這是因為我在找尋這些方法的期間，學習到了prototype利用call、或是經典的base方法來呼叫上層或甚至是其他類別的方法來繼承並覆寫，讓prototype的寫法有了更多彈性，而能夠滿足系統的需求。儘管寫起來是比Base繼承法繁雜許多，但是由於prototype繼承法容易分析，許多JavaScript IDE都能理解，也是JavaScript程式設計師應該要知道的基本功課，這是我最後選用prototype繼承法來開發的原因。

這段期間不僅是一直翻閱相關資料、測試方法的優劣，還把系統的所有程式改寫了三次之多，著實非常地花時間，但也因此學到了不少東西。

重新檢視單元測試的必要性

在撰寫toolkit跟core的時候，我會要求自己盡量撰寫單元測試，並且最好是能夠測試到所以功能，也就是要求高「測試覆蓋率(Code coverage)」。上圖是core的UML類別圖，其中橘色的小註解標示著這部份的系統有設計單元測試的意思。小小的15個類別裡面，就有7個單元測試，力求核心元件要穩定。

過於繁雜的單元測試

上述在核心的工具時還可以做，到後面設計UI時，設計單元測試就越來越麻煩。我是用setTimeout來設計成機器人的方式，利用jQuery去選擇物件來點選元件或輸入資料，用以測試功能是否正常運作。但是這個機器人也常常做出一般人沒辦法做到的功能，導致測試的水準是比實際上更為高。舉例來說，原本使用者不可能點到某些隱藏起來的按鈕，可是用jQuery去點就可以點到、使用者必須等待視窗關閉並開啟之後才能執行下一個動作，可是jQuery就是無視視窗開閉來進行動作，導致他找不到下一個視窗的功能。也許是我設計單元測試的方法不對，但目前這樣做的確是很累，也顯得不切實際。

總結以上，簡單來說有兩個問題：

1. 設計單元測試比設計元件本身還花時間，頗有本末倒置的情況發生。
2. 單元測試不見得切合真實手動操作的情況。畢竟UI設計不像之前的計算用或存取用的程式這麼單純。

因此有必要重新檢討單元測試的必要性。

選擇重要的功能設計單元測試

仔細想一想，不需要全部功能都進行單元測試，去拼那個「測試覆蓋率」實在是很浪費時間與精力，只需要針對重要的功能設計單元測試即可。具體來說，針對具有以下兩種條件的功能來設計單元測試最為實用：

1. 關鍵功能：千萬不能出錯的功能，當然要用單元測試確保他的正確性。
2. 多道手續：與其說是在意其正確性，不如說是檢查時因為手續太多很麻煩，不如設計成單元測試的機器人讓他自己跑出的目標功能，再看看哪裡有問題，可以省下許多手動操作的時間。

也就是說，即使很重要的功能，但是如果很簡單就可以手動進行測試，或是其他測試中已經會使用到的功能，那麼就不需要刻意地撰寫單元測試。

程式要經過測試才算是完成。我仍然堅持這個最低底線，但現在並不強求一定要設計成自動的單元測試，即使是手動測試也可以算是勉強及格。

缺乏多人合作的遺憾

寫著寫著來講一個額外的小故事。

有天晚上回到宿舍的時候，發現室友學弟的位置旁坐著另一位學生。

學弟是資科所的學生，研究題目是跟雲端相關，當然也是寫程式的工作。看起來他應該是跟他同學兩個人正在趕一個系統，我偷偷地瞄到了phpMyAdmin的介面，兩台Mac筆電外加一個外接螢幕通通擺在桌上，旁邊還有喝到一半的五十嵐珍奶，看來晚上是要熬夜拼進度了。

老實說，我很少與人一起分工合作地寫程式。教人寫程式的經驗很多，但是可以像學弟他們那樣，「那個帳號登入的部份就拜託你了。」「OK！」地將一個系統分成幾個部分、再各自完成的經驗則是相當地少。不過架伺服器的各功能分工倒是有的，教育部計畫的時候，但那畢竟是功能調整，不太像是寫程式的這種「創作」。

我知道這種分工合作經驗的重要性對於程式開發來說並不亞於技術知識，大型的、有價值的系統是無法、也沒有時間讓我自己一個人完成，而我知道這正是我的弱點。至今我仍然是一個人在寫著程式，就像是現在正在做的碩士論文一樣。

儘管如此，我也在學著讓自己的程式「更好讀」、「更容易讓人使用」。像是建立嚴謹的物件導向架構程式讓人方便使用、遵守PHPDoc、JSDoc、cssdoc這種具有標準規範的註解讓人容易閱讀、利用UML跟網站草圖讓人理解整個系統，使用甘特圖與Wiki共筆工具來模擬多人合作時的專案互動。

我希望我能夠有資格與未來的夥伴一起合作開發一個大型的系統，所以我要加油，嗯。

結語

現在最令人擔心的是，19天後到底能不能完成系統呢？即使系統完成，後面還有好多後續的動作要做，多到讓人現在不想要面對的事情。能在這學期畢業嗎？能在明年3月之前如期把論文交給國中圖嗎？問題實在是太多了。現在還會有人問我要不要繼續念書，還是去當兵，還是要去當資訊替代役，但是現在能不能畢業都不知道啊XD

總之，每天都努力地繼續寫程式、寫Blog記錄，努力地向前進吧。

題外話，國慶日當天寫進度報告真是格外值得紀念？

(more...)

論文進度報告(2010/9/26)：進度延後至10/29

9月中meeting時，我跟老師報告了一下系統狀況與現在的進度。當然就如你所知的，系統開發並不是很順利。前端的JavaScript程式完成了估計數量的1/3不到而已，之前說想要在9/21完成的希望，當然也是只能摸摸鼻子地再來重新估算日期。

系統現況與進度報告投影片

這是9/15論文進度報告的投影片(SkyDrive下載)。

前端的View部分，系統目前可以分成六大區塊：Toolkit工具箱、Core核心元件、Window視窗元件、Toolbar工具列、Text標註、Search搜尋。而目前我正在做到Toolbar這一塊，比報告之後又多推了一些進度，但跟上次報告時比起來也不過是多作了7隻程式而已，中間相隔約2個禮拜。

以下是進度的詳細內容：

元件	預估程式數量	已完成	UML類別圖
Toolkit	15	15	1
Core	15	13	1
Window	4	4	1
Toolbar	36	3	2
Text	38+?	0	3
Search	6+?	0	1
統計	114+?	35 (30.7%)	9

專案進度延後，設定10/29作為查核點

系統延後的狀況實在是太嚴重，嚴重到我都快對不起KALS Wiki左上角的倒數計時器。但是正視自己的弱點才能夠前進，所以還是要忍辱地再次調整專案規劃。

如果以兩個禮拜可以增加7隻程式來計算，大概還需要5個月的時間……當然不可能會到這麼久。而且這兩個禮拜中，又是寫書校稿、又是假期回家，所以進度才比慢到這麼誇張。不過都已經9月底的現在，說什麼理由也沒啥意義了。

總之，接下來兩個禮拜應該可以專心在系統上，因此要用這兩個禮拜來預估系統進度，然後設定10/29(五)作為查核點，再給自己一個月，看看情況如何吧。

由於整個進度都往後順延，影響到最後畢業的時程，延遲至3月初。由於我仍欠國中圖一篇論文，所以千萬得在3/24之前完成口試才行。

寫書一校完畢

之前提到的寫書工作，終於完成一校的作業了。

一校作業是由我跟老師分擔負責，我主要是檢查技術部分是否有問題。而不出所料地，我又作了很多修改。讓人有種「校稿怎麼校都校不完」的感覺。後來編輯又來告知說我圖檔dpi不足300，印刷時會讓圖片花掉，讓我又花了好多時間再來重新截圖。儘管現在都做完了，但二校時可能也會再來一次這種大混亂吧。

雖然老師希望該書在9月底能夠出版，但看現在的情況，能在10月底之前出版也許就該偷笑了？

與外國作者討論程式的感想

我在撰寫論文程式時，使用了Max Wheeler的PlaceHeld的外掛，並改進了裡面的一些小bug。這次心血來潮，上github將我的建議寫給作者Max，而他也在數天之後回了我。但他並不知道這樣改的意義，所以我又寫了一些範例回給他，現在在等他的回應。

以往我改了很多人寫的程式(特別是DSpace)，有不少會在這個Blogger中寫出我改過的地方，但卻很少跟原作者交流、互動。我想，如果要成長的話，就一定要積極地與人交流知識才行。光是閉門造車，是很難有所成就的。

嗯，加油！

---

以往我總是將許多主題混在論文進度報告裡面一起寫，讓閒聊的事情與可能比較有教學價值的文章內容混淆。現在我打算把一些具有獨立探討價值的議題從論文進度報告中拆開來，進度報告歸進度報告(還有很多閒聊)、其他議題歸其他議題。也許這樣會對想要一次看完的讀者來說比較辛苦，但我相信將議題獨立探討，應該是更方便讀者找尋資料。

也因此，最近我發了很多篇文章，而談論議題都比較獨立。事實上，也還有好幾篇想寫議題列在待辦事項中，等待我一篇一篇地將他們完成。

(more...)

淺談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裡面就有闡述過了，就目前現在這階段來說，應該只能當做是興趣吧。某些角度來看，不寫程式而專心弄好研究而畢業，說不定他們才是人生的勝組？如果人生的勝敗組是這樣定奪的話，那我寧願選擇作自己開心的人生敗組就好。

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

(more...)

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

程式已完成	11
UML已整理類別	73
UML未整理類別	36
整體進度	11/108 (10%)

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

(more...)

論文進度報告(2010/8/15)：糾結的JavaScript

由於一直想要有點進度再上來報告，但是儘管距離上次報告已經三週了，現在還是沒有什麼很具體的進度出現。

老實說，JavaScript寫起來超乎預想之外的複雜。舉例來說，撰寫AJAX的程式時，要考慮到前端JavaScript、中介Controller、後端Model等多種程式的結合，程式與程式之間相依性非常高，其中一個環節出錯，都會導致整個動作失敗。而且還要考慮到各個環節中出錯時的訊息回報機制，因此非常地複雜。當然，在不熟悉AJAX的情況下總是會有許多過渡期，只是這段過渡期掙扎的比在使用CodeIgniter時還要久，就讓人有點焦急了。

因此我想藉由這篇來整理一下目前到底做了些什麼事情，接下來到底還要做些什麼，依此來整理一下頭緒吧。

熟悉JavaScript IDE：Aptana Studio

Aptana Studio是知名Java IDE Eclipse的一個插件，用來開發PHP、AJAX的網頁應用程式。而Aptana Studio也有獨立的IDE，只是就像是預先調整好Eclipse之後的客製版而已。Aptana並不像Dreamweaver那種所見即得編輯器，而是更注重於程式端的撰寫。

在前一次進度報告裡面我有提到NetBeans對於JavaScript的支援並不太好，相較之下，Aptana有幾點優勢：

• 更聰明的自動完成：不僅僅是物件的方法可以自動完成，連變數名稱(會判斷全域/區域變數)都可以呼叫自動完成。我為了搭配Packer而將區域變數皆以「_」開頭，就讓這個自動完成非常地好用。而搭配JSDoc之後，功能更為強大。
• 較為支援JSDoc：儘管Aptana使用了許多他自定的JSDoc標籤，而且要在註解寫到@時按Alt+J(因為我後來調整過，所以現在我忘了原本的快速鍵是哪個，但他就是得要按快速鍵才會叫出選單)。但是Aptana的確是比較能夠利用JSDoc來補完原本JavaScript難以辨識的物件導向特性，例如繼承(extends)。

其他的像是Outline(程式大綱)、錯誤提示等就還算普通，但也是不錯用的功能。只是他的搜尋跟取代實在是有點不太好用，太過複雜了。結果我要取代時都改貼到EmEditor去操作XD

題外話，在研究Aptana時我發現到了Aptana Jaxer這個AJAX伺服器架構，這可說是非常前瞻性的開發方式，可以讓你在原有的JavaScript程式碼當中，撰寫控制伺服器端Server中資料的AJAX程式，以簡化Client-Server之間的複雜性。這次我並沒有使用到Aptana Jaxer，但下次有機會開發AJAX專案的話，我會考慮由此著手。

有興趣的人，可以來讀讀看「初探Jaxer」來入門喔。

設計模式：觀察者模式

 

(圖片來源：Wikipedia)

觀察者模式 (Obersver Pattern)是經典的軟體設計模式當中的一種，他透過介面統一來讓觀察主題(Subject)與觀察者之間的相依性鬆綁，將通知的任務集中在觀察主題中，而各觀察者自行到主題去訂閱，而通知之後行為也仍讓各觀察者自行決定。

在JavaScript這種大量依賴事件(Event)，且通常是非線性、動態的執行環境中非常地適合使用觀察者模式。JavaScript是使用「EventDispatcher(事件派遣者)」來做為觀察主題，而觀察者通常是輸入function，稱之為「監聽者(Listener)」，這是JavaScript程式語言的特色發展而成一種獨特觀察者模式。

如果你用過JavaScript的addEventListener功能，其實你所用的就是觀察者模式的一種。例如你可以針對window(視窗)改變大小(resize)的事件進行觀察，程式碼通常如下：

window.addEventListener('resize', function (event) {
    //當視窗大小改變時，做一些動作...
});

當學會觀察者模式的作法時，這簡直是JavaScript的神兵利器，許多功能都可以利用觀察者模式來實作。其中，我想到最有趣的功能是語系檔的觀察者模式。

在傳統系統開發中，語系檔通常只是供其他UI(User Interface，使用介面)元件讀取。如果語系檔有所變更時，就要在讓全部UI再來做一次讀取的動作。而這個讀取的動作通常是跟UI的初始化動作綁在一起，也就是要讓整個網頁重新讀取，才能達到語系變更的功能。

利用觀察者模式改良語系檔的話，就是把語系檔當做訂閱主題、讓各個UI的語系設置動作作為觀察者。當語系檔有所變更時，則通知各個UI的語系設置動作，以達到即時的語系變更效果。

舉例來說，在尚未讀取語系檔之前，UI會以各自的預設語系來呈現，如下圖：

再讀取語系檔的內容之後，語系檔就會通知各UI來更新語系，於是就能呈現語系檔中的中文字句，如下圖：

諸如此類的應用還可以用於AJAX接收資料的通知、Data Collection資料變更的通知等等，非常地好用，可以在未來難以預知的變化中提供多種組合的可能性。

觀察者模式可說是我在學習JavaScript中最大的收穫了。

研究Android手機版本

如果問我開發網頁程式最大的魅力在哪裡，我想應該就是HTML、JavaScript那種跨平台都可以執行的泛用性吧。

JavaScript比起Adobe Flash、Microsoft SilverLight更為泛用，甚至各平台許多的Widget也使用了JavaScript作為開發語言。而在現在的智慧型手機如Apple的iPhone、Google的Android (微軟的Windows Mobile 6以下請排除在外，WM真的是沒救了)也總算是支援較完整的JavaSript功能，也就是說，理論上我可以寫一個網頁程式，讓他同時在桌上型電腦跟手機、平板電腦上都可以正常地運作。

上圖是Android SDK中提供的Android模擬器功能，跑的是Android 2.1版本。眼尖的讀者應該可以發現到，這跟上面圖片中讀取的其實是同一個網頁，而他們的UI也幾乎是一模一樣。這就是我想要達到的效果。

由於我比較喜歡開放原始碼的Android，所以在研究手機網頁時，我是以Android為主，而不是iPhone。安裝Android SDK時著實讓我花了點功夫，最後是參考Android 模擬器安裝 (Install Android Emulator)來完成的。在之後的測試中，一開始我安裝最新的Android 2.2，但是速度不知為何很慢，於是我又測試了幾個版本，目前是使用Android 2.1在做測試平台。

我也試著去找了iPhone的測試平台來安裝，免費的只有找MobiOne，但是他的瀏覽器模擬並不是很正確，系統偵測的數字會受到外在環境影響，實在是很難在這上面開發，故放棄。

開發手機網頁的困難

然而在手機上開發網頁卻是需要注意到許多事情。以下是兩個主要碰到的問題：

找不到手機縮放的Sweet Spot

現在有許多鑽研手機網頁程式開發的方法，但大多數網頁所指的「手機(phone、mobile device)」指得都是Apple iPhone，例如Web Development For The iPhone。儘管大部分的功能在Android瀏覽器也是一樣的效果，但是像是viewport(瀏覽畫面縮放)的判斷，只有在較新的版本(似乎是Android 2.1)以上才有支援，Android 1.6並沒有支援，viewport。這種微妙的差異讓開發時遇到了不少困難。

Eric Shangkuan發表了一篇寫作Mobile Web App的準備來討論Viewport的注意事項。大部分的手機網頁開發都是將Viewport網頁縮放鎖死，不允許使用者在手機上放大縮小。而各種framework如jQTouch跟Sencha也都是如此。

（圖片來源：jQTouch Preivew）

舉例來說，這是jQTouch的網頁介面。在這種狀態中，使用者是不能夠縮放畫面大小。雖然實際上也的確是不需要縮放，但這是在把網頁當做純應用程式功能時才能使用。如果你的網頁是文字與應用程式功能混雜的話，那麼就會有些問題。(像是我的標註工具)

（圖片來源：37singals）

Micah在Device-scale user interface elements in iOS Mobile Safari中討論到了功能元素與手機縮放尺寸的影響。一開始讀取網頁時，手機瀏覽器會將尺寸縮放到能夠看到整個網頁寬度的大小，於是你會發現到功能按鈕就會小到讓手指很難按得到。

（圖片來源：37singals）

可是當你把手機畫面放大時，卻又發現這按鈕大到一種礙眼的程度。

（圖片來源：37singals）

這樣子的大小才是一個理想的尺寸(sweet spot)。

因此Micah提出了一個偵測尺寸縮放、並偵測現在尺寸、然後利用CSS3的「webkit-transform: scale()」來調整元素尺寸的解決方案。很遺憾的是，這似乎只能用在iPhone上。儘管我花了很多時間改良讓他能用在Android，但是實際上並不偵測到真正的縮放尺寸。

於是我放棄了，還是鎖死viewport，讓使用者乖乖用固定尺寸瀏覽網頁吧。

事後我發現到原來scale的資料可以從touch事件偵測中來取得，在JavaScript Touch and Gesture Events iPhone and Android這篇有較為詳細的介紹。下次有要研究手機網頁開發時再來研究吧。

捨棄只能在手機跟Google Chrome執行的手機網頁Framework

就如上面提過的，jQTouch跟Sencha都是專門為了手機網頁開發的Framework，其中Sencha則是結合jQTouch、Ext JS等知名JavaScript Framework的一個集大成的Framework。

他們都使用到大量的JavaScript跟CSS3，在iPhone跟Android上也都能正常運作，也可以在Google Chrome上顯示，而且非常地適合手指操作(Finger Friendly)，而我也非常喜歡這種UI。

但很遺憾的是，在Firefox甚至IE當中，他們都無法正常地運作。也就是說，用Sencha或jQTouch所撰寫的網頁，幾乎就只能在手機或Google Chrome上才能開啟。

這是讓我難以接受的限制，於是最後就捨棄他們不用。只有在設計UI時，才會開啟來參考他的外觀而已。

持續改良中的單元測試

由於之前要嘗試各種技術，雖然一直是使用QUnit來建立測試頁面，但那些都不能算是真正的「單元測試」。由於AJAX是非同步的執行方式，這讓單元測試沒辦法很單純第一次做完，當然也就不知道該做的測試到底什麼時候會完成、是否成功。所以我改良了QUnit，加入預測測試數量的功能，以便更能準確地掌握到該測試的完成度。

現在單元測試也大量地使用了setTimeout來做出自動操作的功能。也許這跟實際上用手操控滑鼠來操作還是有點不太一樣，但勉強算是堪用。

此外，也不斷地調整CodeIgniter的Controller跟View架構，讓它更適合開發AJAX環境。

之後還會做一個統一計算單元測試的頁面，就如當初在CodeIgniter裡面做的一樣。這就稍晚再來進行吧。

專案進度整理

類別	應完成	已完成	已完成百分比	程式語言
Model	100	100	100%	PHP
View	73	4	5.4%	JavaScript
Controller	9	0	0%	PHP
總計	182	104	57.1%

進度與上次報告來說幾乎沒有差多少，但是實際上卻已經寫了快40支程式。然而到目前為止都還是像準備作業一樣，還沒有正式進入實際開發的階段，所以感覺上根本沒有做多少事情。

目前可能是比較接近系統核心的，應該只有Selection_manager而已。就是實作了選取區域的功能。

KALS Wiki上面寫著原本預定的8/23要完成……連我自己都覺得不太可能了。還是到那一天再來看看吧。

結語

為了開發手機版介面，我跟實驗室借來了HTC Hero。使用之後果然發現到很多在電腦上用滑鼠操控無法得到的落差，使我改進了不少UI設計。(此外，Hero真好玩，Android真是不錯用)

現階段我仍在進行基礎的準備工作，目前正在撰寫跨網域檔案上傳的功能。檔案上傳很基本，但是加上一個跨網域的限制，就是很少見的技術。然而，對我正在做的標註工具來說，跨網域卻是基本的門檻而已。

因為要做的事情還是很多，多到難以看到完成的終點，所以最近多少有點喪失動力、甚為消極。

於是每天就在陌生的技術中，不斷地挑戰未知的領域，然後浮沈地掙扎吧。

(more...)