（縮略圖，點擊圖片鏈接看原圖）
（縮略圖，點擊圖片鏈接看原圖）
這個月，應該是最悶的盤了，盤整大約不到 100 點的上下，很折磨人。不過為了練習看盤、培養實戰能力，我仍是持續操作好幾次的小台期指交易。
交易已有約 10 數次了，很有趣的是，除了生平第一次買期指作多是獲利以外，至目前為止，凡是作空，都有獲利；但只要作多，都會賠錢。好像還真印證我具有 『看衰』 本領的天賦。:|
損益來說，勝負算是各半，不過重點是我從每次操作失敗的教訓中汲於獲取經驗。例如，我前天莫名其妙的在一開盤約 6130 點附近買多，不到半小時，跌至 6110 左右。我竟然假設 6130 是低點，離底部很近了。理由根本不充分，假設沒有根據，越想越不對勁，所以約 6114 市價停損賣出。算是運氣好，終盤還跌至 6080，少賠很多。
一直在思考這次不成功的交易，說真的，即時往上揚也是被我 『矇』 到而已，反而還得不到這次莫大的教訓。最重要的原因，只憑感覺或假設買賣風險太高了。從八月份 6400 以來，短、中期大盤就是空頭走勢，在空頭走勢中搶短多，逆勢而為，風險高高，不太算是正當作法。更何況，我竟然漠視了這個趨勢，天真的以為現在已經離底部不遠了，若是，我知道這次的交易是為了搶反彈，結果沒有反彈上升，反而持續下降，此時就是執行停損，減少損少，若是這樣的假設，我覺得理由就還算是可以，卻不能無知到現在是在作反彈，而不是另一個趨勢上升的開始。
趨勢、時機(Timing)、執行(買/賣、停損/利)，這三點，缺一不可。
與大盤當朋友，不要與它為敵，這樣在股票投資的市場裡，會生存得比較愉快～ 
|
股票作手回憶錄 Reminiscences of a stock operator ———————————– 作者： Edwin Lefevre /著 譯者： 真如 /譯 出版社：寰宇 ISBN： 9578457111 |
內容簡介：
本書為有史以來，記述1900年代初期最偉大股票和期貨投機客Jesse Livermore 生平事蹟的經典作品。數十年來，一代又一代的金融專業人士和交易員都閱讀過這本書，從中學習金融操作應秉持的態度、反應及感受。作者以Larry Livingston的假名，描寫Livermore 操作生涯成敗起起，以及他如何在金融市場上進，行壟斷、軋空和面對市場崩盤及繁榮的經驗。
建議所有股資人詳讀這本歷史傳記，相信您從事金融商品操作多年的經驗，勢必不如一窺本書所能吸收者。
上個月到我好朋友 Weddy 任職的證券公司，向他請教股票與期指投資相關的知識。Weddy 沈浸在此行已經有 10 餘年了，算是獨行俠，所有相關操盤的策略與技巧，都是他一個人，並未與其他人討論。年紀輕輕，我是不知道他有沒有賺到錢，不過，前兩年他用現金，毫不手軟，買了數百萬位於重慶南路的 Office 當作他個人休息的地方。 
我投入至某個領域，絕對是會買一堆與此領域相關的書籍，以及會請教在此行的佼佼者。算來，我在股票、期指等技術性書籍，買來有超過 20 餘本了。還嫌不足，所以會請教 Weddy 推薦他認為不錯的書籍。
Weddy 告訴我，股票投資相關的書籍分為三大類：心路、策略、技術。技術性的書籍，他覺得國內出的技術性書籍，閱讀個兩、三本就足夠了，最重要的在於心路歷程與策略相關的書籍。尤其以這本：「股票作手回憶錄」，更是投資(或是投機)者人手必備該閱讀的一本書籍。書中敘及的是約一百年前，美國最偉大的投機客 Livermore 終其一生，在股票與期貨市場，大起大落的傳奇事蹟。
傑西‧李佛摩（Jesse Livermore）──獨行其是的曠世奇才，他的革命性操作策略，直到今天，仍為人們所用。Livermore 曾經賺得巨額財富，腰纏萬貫，卻也好幾次落到一文不名的地步，最後為個人問題和嚴重的抑鬱症所苦。1940年5月，他在紐約的一家酒店，喝了兩瓶威斯忌后，開槍自殺，沒有留下任何遺書。
原本我還想，100 年前的股票期貨投資市場，有啥好談的？與現今複雜多變的投資(機)市場，如何能從其中借鏡學到箇中道理呢？
不過 Weddy 可是不會亂介紹書籍給別人的，我想他推薦的書籍，應該仍有閱讀的參考價值，於是乎在博客來書店訂購了這本書。昨天拿到，今天不經意一番，馬上就被書本的內容給深深吸引住了。
即使是與股票投資無關的，也都可以閱讀本書，它根本就是一本口述的回憶錄，文字敘述很平時、口語化。我真的很難描述，這本書把它當作小說、故事來閱讀，是多麼、多麼地精彩！
透過書中的內容，我發現到， 100 年前的投資與投機的本質，100 年後還是沒什麼變，只是現在再多上一層包裝而已。如同第三章開頭，Livermore 所說的：股市只有一面，不是多頭或空頭的一面，而是正確的一面。這條通則，要能深烙在投資者的腦海裡，絕對是遠超過股票投機遊戲中大多數比較技術層次的東西。在這個遊戲當中，你必須要能學會操作，否則你只能退出(如 Weeddy 講的，太多 Loser 是被抬出去或架出去的，呵呵～)，而且遊戲在教導你的時候，是會毫不吝惜的鞭打你。
光是第一章，就有幾句股市投資的「智慧雋語」。其中兩句，我特別收錄下來：
這麼精彩的口述自傳，主角的一生又是如此的傳奇、大起大落，最後晚年的抑鬱而終，應該是最適合被拍成電影了。真是希望未來國外的導演能注意到這本書精彩的內容。拍成電影，鐵定可以賣座。
目前我只閱讀到第三章，可以肯定的是，這幾天我一定隨時手裡拿著該本書，逐字慢慢地享受閱讀，最偉大投機客 Livermore 精彩、傳奇的口述事蹟。
現在許多網路銀行均提供 WebATM 的功能，利用晶片金融卡為交易媒介，透過網際網路進行交易，而得以讓顧客於任何時刻使用 WebATM 所提供的銀行服務。
由於金融機構在發卡時，將可供金融機構辨識的安全資料放入卡片中，經由卡片的作業系統控管，無法透過任何方法將該部分的安全資料讀出，用任何設備均不能複製一張一模一樣的卡片，所以利用晶片金融卡作為交易媒介的WebATM具有很高的安全性。
上上個星期，有位學員，是實際撰寫某家銀行的 WebATM 系統。他希望能透過使用案例來紀錄需求。
在建立使用案例的模型時，系統範圍(System Boundary)很容易界定，即為 『WebATM』 系統。使用案例(Use Case)也挺容易捕捉的，只要觀察一般銀行 ATM 所提供的服務諸如 『轉帳』、』查詢餘額』、』變更密碼』、』查詢交易記錄』…等。
主要的參與者(Actor)，』顧客(Customer)』，這也沒問題，支援性參與者(Supporting Actor)，其中必然有一個 『Banking System』，因為 WebATM 系統必然會連至 Banking 系統以作轉帳服務。比較令人 Confuse 的是，晶片金融卡插入讀卡機後到底是否為 Actor？
讀卡機必然是輸、出入的裝置(Device)，是屬於使用者介面。使用案例的敘述(Description)一般並不把特定的輸、出入裝置寫在敘述內容裡。例如，去租漫畫或影片時，店員利用 BarCode Reader 讀入條碼，但是，未來若有更佳的輸入裝置而取代現在的，那麼，使用案例的敘述就必須要隨之變動了。
但，學員挺堅持，幾年內輸入裝置是不會變的(其實，這也是許多實際案例中所碰到的)，難道一定要堅持不把讀卡機寫入敘述內嗎？
我個人還是比較傾向不要寫在一般的使用案例敘述內，不過，解決方式事實上也非常簡單，只要在使用案例的 『參考資料』 欄位內，或是利用如 EA UML 工具，在 『Constraint』 欄位內，填入 『Key-Value』，如 『Input Device-USB2.0 晶片卡讀卡機』 就可以了。
使用者介面敘述的問題，這也還算好解決，不過，真正的問題是，晶片金融卡到底算不算是外部的系統而成為 WebATM 的 『Actor』 呢？
答案是 『Yes』，它確定是 Actor，是屬於支援性的參與者。
Why？思考 『支援性參與者』 的定義：它會提供服務給設計中的系統。
晶片金融卡具備記憶與運算功能，WebATM 可以透過呼叫晶片金融卡所提供的 APIs 來讀取或寫入資訊。例如，可以查詢晶片金融卡內所儲存的交易記錄；可以將欲變更的密碼寫入卡內；執行交易時由讀卡機將交易資料傳入晶片卡並取得唯一的一組交易驗證碼﹙Mac﹚或簽章﹙digital signature﹚，此交易驗證碼取代密碼傳回發卡銀行而取得此交易的授權，因此，密碼不會在網際網路上傳輸，也不會被破解。
結論是，要把讀卡機與晶片金融卡分開。讀卡機是輸、出入裝置(Device)，並不能視為是外部系統；晶片金融卡因為有提供服務給 WebATM 系統，所以是屬於支援性參與者。
參考一個基本 WebATM 的使用案例圖如下。
晚上大陸某網友 msn 與我對話，討論一些對軟體設計的看法。
他自己有個不錯的 Blog，專門在研究 Middleware and Software Architecture 設計。
網址： http://webscope.blogdriver.com/webscope/index.html
我最喜歡一開始問一個問題了：
「軟體設計的開發會是往 『Top-down』 or 『Bottom-up』 的模式呢？」
嘿嘿，他沒有被我給騙到，甚至，回文的內容相當地有水平，值得收錄！
『software design more likes 『open a black box』,this process can help us to get more hints about the complex of this system,I think 『top-down』 or 『bottom-up』 isn’t a way.』
事實上，我回應的是，設計的開發會是 『回饋環路(Feedback Loop)』，他也非常認同，Process 最重要的即在於 『反饋』 與 『溝通』。
他又提問了一個問題，關於如何對架構作 『POC(Proof Of Concept)』。呵呵，我馬上反問：請問架構如何作測試？ 他的回答是：不好意思，我常心測、目測。
所以，真正的問題是，到底架構(Architecture) 是什麼？若不清楚到底那個 『架構』 如何 『拿』 出來，又如何測試架構呢？
對 『架構』 這一詞實在非常難之解釋，若是聽到有人是以 RUP 的 4+1 View 來解釋架構，那我大概知道，那對架構的認知應該是太狹隘了。
至少，我個人認為，要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語，包括了：
整體、觀點(View)，包括巨(Macro)觀與微(Micro)觀、焦點(Focus)、層次(Layer)、廣度(Boundary)，才有可能對架構有進一步的認知與體悟。
架構不會是純有形、也不會是純無形；看來很抽象，但有時卻可以很明確地具像化。
架構為 『無』 時，以觀其妙，架構為 『有』 時，以觀其徼。此兩者﹐同出而異名﹐同謂之玄。玄之又玄﹐眾妙之門。
Kenming's 軟體設計
Kenming's .NET 實作
since 2004.05.11
關於本站授權聲明
