Kenmingの鮮思維

Constructing the User Interface with Statecharts ———————————– 作者／Ian Horrocks /著 出版社／Addison-Wesly 出版 ISBN／0-201-34278-2

內容簡介
Behind most non-trivial user interface screens lie complex webs of code that many practitioners in the software industry find difficult to control. Despite the obvious power and sophistication of user interface development tools, the majority of user interface software is difficult to understand because it is coded without an overall design. In this book, Ian Horrocks presents a proven technique for designing event-driven software using the UCM architecture and the statechart notation. The statechart approach to constructing user interface software results in code that can be:

* written quickly and easily,
* tested using white box techniques,
* repeatedly enhanced over the lifetime of a system,
* modified with a minimal risk of introducing unwanted side-effects,
* regression tested without the need for full re-tests.

This book provides a practical guide to constructing real user interfaces for real projects. It is primarily written for practising software engineers, but will also be invaluable to students wishing to gain an insight into user interface construction.

前言

狀態機圖 (state-machine diagram) 是描述系統行為時常見的一種技術。事實上自 1960 年代以來，狀態機圖的設計就已被廣泛運用在即時、嵌入式系統的狀態設計上，而 UML 規格的制訂，更將其納入成為標準重要的設計圖之一。物件導向的技術經常使用狀態機圖來表示系統中的各種行為，如針對單一類別畫出它的狀態機圖，秀出單一物件在生命期中的行為。

我是覺得一般 UML 書籍對狀態機圖的論述，仍是著墨甚少，且焦點還是擺在對單一物件的行為描述，而領域性的物件 (domain object)，如“訂購 (order)”，其狀態的變化可能還是少了些，利用簡單的欄位值描述就可以了。
事實上，利用狀態機圖來捕捉某一個體複雜狀態，威力可是非常強大，它有助於讓我們釐清狀態之間轉移 (transition)的變化情形。最常被運用到的範疇，包括控制器 (controller)，例如十字路口的紅綠燈，或者捷運站閘門、販賣機等，都是內嵌了控制器；以及使用者介面 (UI)，尤以後者，它呈現了因為事件 (event)的觸發，而導致諸多 UI 元件彼此之間的狀態連動，該如何對其作有效的控管，並期能追蹤與測試，以維持 UI 一定的品質。

本期書評的主角，正是運用狀態圖 (statechart)的技術來建構使用者介面。包括傳統的 Windows Form，至現以 Web-based 介面開發的 ASP.NET, JSF, 乃至於最熱門的 AJAX 等 UI 技術，其本質都是一樣的—均為以事件驅動 (event-driven)的介面開發。

本書道盡了狀態設計的精髓與本質

這一本書薄薄的，含附錄也才 250 頁，不過字體實在甚小，閱讀起來實在傷眼，還有，內容也稍微艱澀了一些，可要耐下性子，你才能逐漸理解狀態機用在 UI 設計的觀念與技巧，以及寫出程式碼。

本書共分為四大部分。第一部份是對 UI 建構上的概念引導。從命列列模式的 UI 開始講起，到 windows-based 多樣化的 UI 畫面，以能更提供人性化的操作介面。雖然系統廠商提供了諸多豐富的 UI 元件，並呈現給 developer 直覺式的 UI 開發環境，似乎拉一拉圖形元件 (widget) 就可以就建構出美美的畫面，你也不用再管到這些視窗之間的互動細節。這些工具的確幫助開發者不少，但是，在幫你定義好個別 UI 元件所相對應的事件處理函式之後，在其內的實作程式碼，仍是需要由開發者自行撰寫，並且往往也需要在此寫上關連與其它 UI 元件的狀態操作等。UI 元件彼此之間的狀態連動可能會牽涉到很廣，若沒有一個好的規範，則常會出錯，而這往往也是造成複雜畫面凌亂難以維護的主因。這裡 Horrocks 提出了對 UI 設計極為重要的 UCM (user interface-control-model) 架構 (p.28)，藉以釐清在 UI 元件、事件處理者 (event handler)與控制物件 (control object)三層之間的責任分派，你會發現到層次分明的好處就在於 Event handler 並不直接處理邏輯，而是交給控制物件來統一維護所有 UI 元件的狀態，而讓 UI 元件回歸到最單純的責任—視覺化的呈現。其實 UCM 就是等同於現在 Java Struts 所提出的 MVC 框架 (Model-View-Controller)，只是名稱不一樣而已。 不過切記，這可是僅此在 UI 展示層 (presentation-tier)對 UI 設計的 MVC 而已，而非對企業整體系統的三層式 (3-tier)的 MVC 架構喔，可千萬不要把兩者混淆在一起，而導致 UI 層與企業邏輯層的耦合性 (coupling)太重。本部分最後一個章節則開始介紹狀態機的設計語法，並藉此來比較有限狀態機 (finite-state machine)與本書所揭露出狀態圖 (statecharts)的不一樣之處。其實說真的，有限狀態機仍是與狀態圖本質是一樣的，均是捕捉狀態的轉移，差別主要是在於有限狀態機並沒有層次的觀念，所以會在一張設計圖上表達出太多的細節，這並不妥，我們可以把許多呈現出好像很複雜的狀態轉移，群組起來，再抽象出更上一層，而封裝了內部複雜的狀態轉移，成為超狀態 (super state)與子狀態 (sub state)的層次關係。

第二部分是對 statecharts 基礎技術的建立。包括了構成狀態圖的諸多表達語法，以及也要瞭解到現實上狀態的各種變化情形，包括了上述所提的層次深度、並行、延遲與逾時、瞬變 (transient)狀態、事件的優先、參數化的狀態等。這裡我覺得最有意思的是歷史機制 (在狀態圖上是以 H 加上圓框符號構成的)，在轉移出超狀態、又再次轉移進入後，到底是要進入哪一個子狀態，這就端賴於“H”這個歷史狀態記錄了，是非常實用的一個技巧。本部分後半章節，開始教你 step-by-step，如何從畫出狀態圖開始，並對每一個狀態命名、給予狀態變數，再整理成一張“事件-行動表 (event-action table)”，未來即是可以依據該表格來轉化為程式碼的。第九章則是提供給讀者在設計狀態圖上的提示與原則，未來在實作設計上，可是經常回頭翻閱本章，會帶給設計人員許多的啟發。
第三部分提供了三個案例分析，從計算器、But Reporting 到學生資料庫應用程式等，讓你實際看到這些應用程式的畫面呈現，以及是該如何利用狀態圖來捕捉這些複雜畫面的狀態轉移情形。大致瀏覽一下，也讓你可以知道頂尖的 UI 技術團隊，在設計 UI 畫面時所用到的技巧與其開發程序。

看到四分之三的內容，讓許多讀者會挫折的是，怎麼還是不知道該如何將狀態圖轉移到實作的階段？ 第四部分總算揭露出轉移到實作程式碼的階段與步驟了。不過 Horrocks 僅列出實作狀態圖的程式設計步驟 (p.187)，以及以虛擬程式碼呈現而已 (看起來應該是以 Pascal 語法來表達的)。並沒有列出相當完整的程式碼範例，這讓許多想要“眼見為憑”的讀者會大失所望的。不過真的要堅持，當初我整整花了一個星期以一個“紅綠燈+方向燈”的控制器案例，從狀態圖的塑模，到實作出 Java 程式碼，當在畫面上可以秀出紅綠燈號的狀態轉移，並且是依循狀態圖的設計規格來實作，這也代表者我即使在 C#.NET 實作，設計圖都不用變動，那種成就感真的是相當喜悅。

高品質的 UI 畫面從狀態圖設計開始

我對本書相當著迷，也為此實作狀態機圖的程式開發，並將之整理成教材納入在 我所教授的 UML 的課程教育上。但是在實務上是否有必要利用狀態圖來設計畫面呢？ 我是以為若產品開發是要能呈現在多個平台的畫面上，那真的是有必要，它可以讓可攜性與維護性提高。還有曾有讀者問過我，UI 設計該如何作測試呢？ 當你作好 UI 的狀態圖設計後，也就代表了可以針對 UI controller 撰寫測試程式碼，依據測試案例來作自動化的測試，達成高品質的 UI 設計，無論是對 ASP.NET, JSF, AJAX 等 UI 框架，道理都是一樣的，好處真的是多多。
我發現到本書在 Amazon 評價是四顆星，有趣的是，11 位評論者有 6 位給滿分五顆星，3位給四顆星，另外兩位則只給 1 顆星。給一顆星的理由是因為看不懂，所以無法應用在實務上。這實在可惜，那6位給滿分的可是評價甚高，而事實上，能專注於狀態機圖的設計書籍，實在少之又少，況且又能協助你在 UI 畫面的設計上，並以釐清複雜事件處理的狀態控管，實在了不得。喔，還有，本來我以為眼花了，當初我在「天朧書局」買本書時只有 NT$ 750，但在 Amazon 看到的價錢是 U$ 200 元，二手書也要 US$ 180 呢。看來應該是絕版書籍，物以稀為貴吧，同時也證明本書的價值的確是經得起考驗的。

去年底，我在 IGS 上的 rating 不知不覺升到了四段，也與多位 4d, 5d 的棋友們對局，還不錯，成績都還蠻好的，甚至還砍了多位五段，雖然對局內容還是不甚滿意，但也算聊表欣慰。

上個星期五(1/11)，與一位 4d 的棋友，下了一盤 1-10-25 (基本時限1分鐘、10分鐘內要下完25手，這是網路圍棋最常用的用時方式)。一開局就下得很快，我執黑，在第 13 手開始變化，我準備下厚取外勢。沒想到白第16手連扳 (參考下圖1)，耶！？ 我還愣住，是不是我細算錯誤呢？ 因為連扳是在征子有利的情況下才成立的。雖然白第4手在左下角(D3)，直覺看起來好像征子有利，其實不然。

圖1、白第16手連扳

繼續閱讀 »

其實在去年底我的部落格等系統就已移機了，好像感覺不到吧？ 我是 "悄悄地" 先在目的端設定好系統相關設定，測試沒有問題後就轉移過去了，轉移的過程大概不到兩天就可以完成，不過花最多的時間則是在虛擬主機廠商的尋覓上了。

系統轉移最重要的反而不是檔案，而是資料庫，一定要先把資料庫資料給備份下來！ 可以先利用 phpmyadmin 將整個資料庫給下載儲存回來，當然其實它的原始檔為文字格式的 SQL 敘述，不過即使是壓縮檔，我的資料可真不少，約超過 5MB 之多吧，所以可是無法使用 phpmyadmin 給執行匯入(import)進去的。還好，先前有提及使用了 BigDump 這個如此簡單的 php 小工具，先上傳原始檔(文字格式，最好不要壓縮)至虛擬主機的目錄，再執行該 PHP 程式，就可以輕而易舉完成資料庫匯入的程序了。

我同時利用移機的時機也完成了 Blog 系統的升級，一切程序都挺簡單的。但是為什麼又要移機了？ 喔，我可是最不喜歡作這些工作的了，實在無奈！ 起因就是在原來的虛擬主機廠商 ServerZoo 的 XOOPS 系統變得超級不正常。哪時候開始不正常呢？ 只要 ServerZoo 的主機維修公告後沒多久，我的系統經常也要跟著作某種程度的變動(例如，XOOPS 系統無法寄信)。但這一次，實在太過嚴重了，XOOPS 系統連管理員權限登入後，只要轉移到另一個頁面，又要我重新登入，根本無法進入管理員選單作設定。

這一類的問題，我當然會從 google 爬文來查原因的，相信我，國內外的各類文章我大部分看過了，也算是夠用心了，但就是無法解決此問題。我改了什麼設定才變得這樣嗎？ 沒有，完全沒有！ 就是從 ServerZoo 他們系統維護(升級)後發生的。說實話，ServerZoo 的服務態度其實蠻不錯的，我經常透過 msn 詢問技術人員，口氣上什麼的都蠻好的，也願意協助解決問題。喔，半年多來，我只有與他們最高主管通電話時最不愉快了，我打電話去 "抱怨" 怎麼系統是如此的不穩定，當然，他總是不會認為是他們的錯，而是客戶自己系統設定等等之類的問題。最後的語氣就是："如果你不滿意，我們可以辦理退費！" 喔，我最是不能接受這樣的態度了，雖然沒有馬上辦理退費，不過當然今年一月初期限一到，是不可給它續約的，趕緊給跑到另一個虛擬主機廠商了。

另一個我也相當在乎的問題是，我最怕技術人員意有所指的認為，別人都沒有問題，就是你的才常出問題。本來我還真的以為就是只有我最常出問題了，結果透過我介紹租借 ServerZoo 的朋友，約有三、四位了，其中一半也曾向我抱怨過，尤其是 生魚片，他說他的系統莫名其妙全不見了，至於什麼原因，他也不知道。這麼不穩，讓他嚇到了，所以他也打算到期後也要終止租借了。

我還是蠻肯定 ServerZoo 的技術人員們的協助了，他們的服務態度我也覺得是不錯，這點可不能給人家抹黑的；不過，對客戶最重要的穩定感，則真的作得不夠。還沒說到後來 ServerZoo 是如何幫我解決 XOOPS 系統的，就是在根目錄與每一個模組目錄內，都要擺上 php.ini 設定檔。這… 還真的暫時有解決了管理員無法登入系統，但是，難道不會覺得有夠奇怪嗎？ 我本人無論如何是沒有辦法承受這樣的解決方案的。

起碼花了一個多星期的時間，仔細慎選國內虛擬主機廠商。對於國外主機，我還是對於傳輸效能會怕怕，所以還是不予考慮。其實就是只有兩大重點：穩定與效能。對了，基本的客製化還是需要提供的。這一點，我與 Why3s 的客服技術人員通話後，是覺得挺不錯的 (當然，現在講這個還是太早了點)，包括還先讓我在尚未轉移 Domain 時，先幫我設定一個暫時的虛擬 Domain 讓我作系統測試，這可是相當方便！ 前述也提過，我並不喜歡移機來移機去的，花在系統轉移與設定的時間，真的不是很願意，要的就是穩定與效能。所以呢，這此我與 Why3s 是一次簽了三年，時間也算是長的。

當然還是希望啦，只要夠穩定與效能不錯 (嗯，合理可以接受的價格是前提)，這樣就可以接受了。爾後呢，應該會打算租借真正的 "虛擬主機"，也就是在主機商他們那邊可能是跑 Vmware，一個實體主機切好幾個 "OS"，每一個 OS 由客戶來主控，當然，由主機商那邊協助管理會更好。這當然還是要等價格更便宜後再來考量囉。

幽靈的禮物 ———————————– 作者： 亞瑟‧李‧辛普森 /著 出版社：恆兆 ISBN： 9789868217379

內容簡介：
國期貨雜誌有史以來最超人氣的論壇寫手，至今沒有人確定自稱幽靈的這位投資大資是誰，但他的三個經典規則，卻持續被討論與引用。本書是由幽靈、幽靈的助理與美國期貨雜誌論壇的諸多投資高手激盪、試驗與實證合力完成的經典投資之作。突破傳統一人創作模式，讓投資大眾領略完全新鮮而精彩的投資智慧。本書的三個投資規則規則一:交易是個失敗者的遊戲，在市場沒有證明你是正確之前，必須假定我們是錯的。規則二:沒有例外的、正確的在已獲利的部位加碼。規則三:投資人應該假設市場不總是正確的，因此，對所有的信號都心存懷疑。

本書相當的特別，幽靈是美國期貨交易圈內一位隱姓的大師，是透過與作者的對話而將其智慧語錄等傳授於本書內容內。這一類型的書籍，我一直都很喜歡閱讀研究。本書該歸為心法還是策略呢？ 應該是兩者都有，本書一而再、再而三的揭露出交易的兩大規則 (或稱為原則吧？)；規則一、只持有正確的倉位；規則二、正確加碼才能獲利。 然後再來還有規則一與規則二的實戰示範，看來應該蠻淺顯易懂才對，但是，資質魯鈍如我，卻是很難體會出規則一的說明，到現在我還在持續思考中，濛濛懂懂，還可真是有些悲哀。

規則一是這樣的：「當倉位未被證明是正確的時候，我們就平倉，我們沒有時間等到市場證明自己作錯的時候才去平倉。」

問題是，倉位如何證明是正確的？ 要花多少時間來證明呢？
建立倉位賠錢就是錯的倉位，這我還能理解，但是要花多少時間來證明它是賠錢的？ 這就是我非常非常疑惑的地方。還有喔，它可不是等到點位被觸發時才停損，幽靈大師認為那是屬於被動的，也就是讓市場去證明你是錯的；還要再更積極，要能主動認知到當你的倉位是錯的時候，馬上平倉退出！ 呼，我真的蠻疑惑的，聽起來很有道理，我也挺認同的，但是，嗯，還是搞不清楚耶。 :crazy:

不過，有一句至理名言可是深深的烙印在我的心裡，這可是可以讓我窮究好幾年來思考這個道理：交易是失敗者的遊戲，最善於輸的人最終會贏！

規則二我就比較能理解了。我一直深信，在這個零合遊戲中，策略絕對來得比所謂 "看的正確" 重要太多太多，我會覺得這才是致勝的關鍵所在 (當然，更重要的一點，心態與紀律！！)，而漸進式的加碼策略，才真正是箇中精髓之所在。別想控制市場，控制好自己的資金吧！ 嘿，真的得要打破我們能破解所謂對大盤掌控的迷思，好的資金管理，才會讓交易簡化與單純些。

幽靈的好幾句話，真的充滿智慧，有許多我還是濛濛懂懂，還可得要持續的反思與驗證才能慢慢理解吧。

• 交易是失敗者的遊戲，你必須學會如何去輸。那些每次只輸狠少一點錢的大輸家，卻最終都能在交易中生存下去。
• 在交易中，任何一個條件沒有達到，你就必須相應減少你的倉位，建立一個有效的長期計畫。你所需要的工具越少，你所走的路就越寬。
• 我們建倉的唯一依據就是我們得到了一個信號。我們知道市場的方向正確，只是不知道市場能沿著這個方向走多遠；因為我們的倉位小，所以我們必須有一個可以增大倉位的計畫(規則二)，否則，長期來看我們的贏面就無法超過一半。
• 你在交易中不要總抱著會賺錢這樣的幻想去操作。在交易中你唯一應該經常提醒自己的念頭應該是：我會在交易中損失一大筆錢。
• 建倉、加碼、清倉，以及正確使用規則來保護自己不被從交易場踢出去，作為一個交易員，你的工作就是為上述過程建立一個行之有效的計畫；使你的損失保持在一個相對低的水準，這是一個長期任務！

本書真的太多充滿上述的智慧語錄。我是瀏覽看過一遍了，但我真的看不太懂，我是必然會再重新多看個幾次，畢竟，真的很少有這樣可以透過書籍來指導你交易的真諦。本書真的是 幽靈送的最好禮物！