作者: Cash

我讀 «走進我的交易室» – 中

前一篇讀書心得被我變造成 “權證與期貨" 專題, 這次正經地來看這本書. 本書的首部曲叫做 “初生之犢", 主要是講投資人和交易人差異, 以及每個市場 (股票, 期貨, 選擇權) 的不同.

基本上, 首部曲裡面沒有太特別的東西. 但是作者以心理醫生的角度, 把盲目的投資人比喻酗酒成癮的病患倒是非常傳神.

第二部曲所提到的 “交易成功三要素 – 心、法、錢", 確實讓我體會到賠錢的外行人只懂得用一維思考, 而專家的想法有好多個維度. 外行人遇到專家, 雖然也有微小的勝算, 但是最後的結果可想而知.

作者說到, 一個成熟的交易人要有紀律. 除了對交易作紀錄, 什麼時候該買? 什麼時候該賣? 都應該在前一天計算出來, 並且在開盤中適時依據行情作出買賣的動作.

作者認為在開盤前下單買賣的人不夠謹慎. 因為他們根據的是開盤前訊息, 並不能反映真實的情況. 我記得某個人曾經提過從開盤開始就要觀察 5 分鐘箱型有沒有突破? 作者的想法也是這樣, 他的買賣判斷都是即時反應的.

那麼, 他如何根據即時行情判斷買賣點呢? 首先要看懂指標. 指標分為 3 種, (1) 趨勢指標. (2) 擺盪指標, 和 (3) 其他指標. 趨勢指標用來判斷大方向, 大方向決定該買或是該賣. 擺盪指標用來決定交易點. 大方向往上, 短期指標向下, 造成擺盪的話, 作者認為這就是買點. 反之就是賣點.

那麼什麼是作者喜歡的指標呢? 他認為一個彈匣裝 5 顆子彈就夠了, 所以主要推薦五個指標. 但如果大家去看這本書, 就會發現作者提供的子彈根本滿出來裝不進彈匣了~~~

趨勢指標 移動平均線 SMA, EMA
MACD 包括柱狀圖
擺盪指標 力度指數 這是作者的發明
通道 包絡線, 布林格通道 = 標準差通道
隨機指標 KD
混合指標 艾爾德射線  這也是作者的發明 

對了! 作者不喜歡當日沖銷. 所以他總是以長期的觀察來選擇交易時機. 為了避免自己衝動, 它還發明了三螢幕法. 第一個螢幕用來看喜歡的交易時間單位的上一個單位 (例如週線), 第二個螢幕則是看自己喜歡的交易單位 (例如日線), 而第三個螢幕則是用來交易. 很辛苦吧!

作者特別為每一個指標背後的意義作註解, 所以這部分就厚達 60 頁.  雖然技術指標能夠幫助作者有一定的勝算, 那麼萬一看錯方向怎麼辦呢?

在這本書的第七章說到: 只能拿 6% 的資金可以承受風險. 每個投資標的只能損失 2%. 只要達到 2% 的損失就表示失誤了 – 例如被主力騙線, 他會立刻斷尾求生, 把機會留到下一次! 所謂的承受風險或損失, 意思是說他已經預設買價和停損點, 所以最大損失是可以預先知道的.

假設本金有 50K USD, 2% 是 1K USD. 那麼買價設在 20 USD, 而停損點在 18 USD 時, 風險就是 2USD. 1K/2 = 500, 表示作者最多買 500 股, 扣掉手續費和滑價 (就是買賣不到設定的價錢) 之後, 頂多只能買 400 股. 事實上, 400 X 20 USD = 8 K USD, 佔他所有資金的 16%.

我讀 «走進我的交易室» – 上

這本書的作者是 Dr. Alexander Elder, 他原本是一位心理醫師, 後來成為專業的投資人. 而這本書是他的第二部作品, 前一本書 “操作生涯不是夢" 似乎也很有名. 至於這本書裡面講甚麼呢? 我想大概要分好幾次才能整理完.

首先, 我介紹最近曾經提到過的 “權證"! 作者認為, 權證不是一個好的投資標的. 因為權證比股票還要複雜, 連專業交易人都不太想去碰, 反倒是很多交易新手對它有興趣.

附帶一提, 作者把長期投資者稱為投資人, 而以炒股為生的則稱為交易人. 作者自認是交易人, 所以他很少談基本面. 他認為基本面是必要的, 搞清基本面之後, 就應該用技術面等等來操作.

專業的交易人只有在行情大反轉的時候才會買權證, 當他們認為行情即將大跌, 交易人會考慮買入賣權. 為什麼呢? 因為行情即將轉折之時, 難免出現震盪. 此時不論把停損點設在哪裡都不保險! 不如先買入賣權", 等到真正大跌之後, 再高價賣出此一賣權.

假如交易人果真看錯方向, 行情並沒有大跌, 購買權證的損失比較少, 而且他們會設停損點, 而不是等權證失效. 另外, 作者認為不應該買入快要到期的賣權 (權證), 至少離到期日要有兩個月的時間, 才能發揮避險的效果.

另一方面, 由於股票下跌的速度是上漲時期的兩倍左右, 如果握有買權, 往往在權證的有效期間都等不到理想的價格而它變成廢紙! 所以作者認為看漲的時候應該買入的是股票, 而不是權證. 只有看到大跌在望才會買入賣權.

如果交易人沒有把握判斷股價會上漲或是下跌? 唯一的投資機會在於 “非常便宜的遠價外賣權" (far out of the money). 這是什麼東西呢? 首先它是賣權, 再來它非常便宜, 就像彩券一樣. 它能夠變得非常便宜的關鍵在於: 它的履約價低到似乎不可能兌現, 所以乏人問津.

比方說股價 100 元, 但是賣權在 50 元, 這個賣權看來沒有多少價值, 只能以最低面額 0.01 元交易. 不過當股票已經大跌到 75 元, 那麼半年一年後再跌到 50 元也不無可能, 此時原本的遠價外賣權就突然變得有交易 (避險) 價值了.

除了看壞買權證這項投機事業, 作者也認為賣權證有一定的風險. 如果賣方出售的是有抵押的認購權證, 那麼最差的情況下不外乎是賣方把手上既有的股票賣給權證的認購人.

至於沒有抵押品的權證賣方 (裸發售人) 風險基本上無上限, 因為他們發售認購權證時, 自己手上也沒有股票. 萬一認購權證的標的股票大漲, 賣方勢必承受巨大的虧損. 不過發生這種衰事的機會很低, 使得賣方往往都是最後贏家. 畢竟連賣方都賺不到錢的話, 這個產業早就消失了. 

從機率上來看, 股價在短期內大起大落的機會有限, 故買方可能會發現快到期的選擇權始終賣不到好價錢 – 每個買方都在求售買權, 而沒有人會買. 最後擁有買權的人只能按比例換成股票.

作者也提醒權證的賣方若已經獲利, 可以直接買回權證而平安出場, 無須面對未來的風險. 看來美國人好像很容易就可以當權證的買方, 不需要是法人才能發行. 

作者對於期貨也很悲觀. 他認為絕大多數的期貨玩家都是輸家. 真正的贏家是那些消耗大量原物料或是商品的買方或賣方, 期貨減少了他們的風險, 而企圖從期貨交易發跡的交易人則不然.

為什麼這樣說呢? 主要是期貨的起伏比股票還要大, 雖然理論上看對期貨的方向可以發財, 但是只要中間發生了逆向的雜音, 玩家的保證金就被斷頭了, 遑論能夠享受看對方向的暴利.

書上很有趣的一段話說: 農民和工程師是期貨市場上的兩大投機客群體. 農民理應對於商品的價格掌握有優勢, 但是他們可能跑去投機 S&P 500. 相對地, 比較懂得科技的工程師, 卻自認可以掌握黃小玉 (黃豆小麥玉米) 的價格趨勢. 這些都是讓他們賺不到錢的原因.

對沖基金喜歡做空, 投機客許歡做多. 但真正賺錢的期貨交易人往往以 “價差交易" 為主. 也就是說, 他們買入一個月份期貨, 又賣出一個月的期貨, 靠著兩個月份的價差來討生活. 這個方法據說獲利不錯, 保證金的要求又更低, 所以您買不到任何與此有關的好書. 圈內人並不想把它和門外漢分享.

以上大致涵蓋了本書的第六章 “交易" 的一小半, 其他的部分我有空再慢慢補上.

宏碁認購權證小整理

昨天報紙說, 宏碁沒有傳出任何利多卻大漲, 這可引起了我的好奇心. 據說權證的槓桿比較大, 如果外資真的對宏碁這麼有興趣, 幹嘛不去買權證?

剛剛數了一下, 宏碁的認購權證竟然多達 71 檔, 認購價格從 25~52 NTD 都有. 認售權證只有 24 檔, 讓大家可以在 22.91~40 NTD 賣掉宏碁. 至於買到這些認購權證會不會賺錢呢? 我看真是有點困難喔.

我關心的數字有兩個: 1. 如果股價從此不漲, 那麼這張權證值多少錢? 2. 如果權證值得現在的成交價, 那麼股價在到期日應該是幾元? 

很不幸地, 如果宏碁天長地久保持在昨天的成交價 27.05 元, 那麼買這 71 檔權證的投資人全都是受災戶! 權證的 "真實價值" 從 -11.46 NTD (49252) 到 0.41 NTD (54529) 不等. 幾乎是有買有套! 大多數的權證就算是用 0.01 NTD 買進的人都虧錢了. 當然這是計算出來的價值, 他們真正的虧損是購買權證的所有開銷, 只要不履約就不會虧這麼多. [2012/8/3, 原貼有誤, 已更正]

54529, ER 元大宏碁, 履約價 25 元, 到期日 2013/1/28, 行使比例 0.2. 元大有可能在這個產品上虧錢喔!

49252, 寶來 98 (宏碁), 履約價  50 元, 到期日 2012/8/15, 行使比例 0.5. 恭喜寶來的老闆賺翻了! 設計此檔權證的人應該分紅啊!

公式:   權證價值 =  (到期日股價 – 履約價 ) * 行使比例 / (1.001 * (1+定存利率 * 持有時間))

我假設可以用現金結算, 這樣可以省下 0.1425% 的手續費和 0.3% 的證交稅,  但當初買入時 0.1% 的權證 "證交稅" 免不掉, 另外證所稅還沒算進去!

另外一個數字呢? 就是每張證購權證如果物有所值 – 剛好是成交價的話, 最後股價應該來到多少錢可以解套? 在這個項目奪冠的還是 54529, 花 0.97 元買權證, 若是宏碁在 2013/1/28 之前漲到 29.88 元它就獲利了! 墊底的是 50813, 真有人花了 0.02 元買它, 而宏碁於 2012/12/10 之前要能來到 52.1 元的時候才可能解套! 

50813, 寶來 BN (宏碁), 履約價 52 元, 到期日 2012/12/10, 行使比例 0.2.

公式: 預期股價 = 履約價 + 權證價格 / 行使比例 * 1.001 * (1 + 定存利率 * 持有時間)

如果願意賭宏碁在半年之內可以重回 30 元大關, 那麼 54529 值得用 0.99 NTD 去買! 此帖適合輕度樂觀者人士服用. 

經過這次的分析, 我覺得權證還是太危險啦! 權證畢竟是業內人士設計出來的商品, 他們用個行使比例把每一個單位的價格弄得好像很便宜, 又告訴大家可以小博大. 好像花小錢就可以賺到大錢! 不過實際計算一番之後, 發現根本買不到合理的價位. 如果我買進現貨, 雖然槓桿比例只有 1:1, 但是漲了 0.585% (= 0.3%  + 0.1425 * 2) 以上就賺 (不含證所稅), 不是比較簡單嗎? 除非有人昏頭賤賣權證, 不然我看要靠它賺錢可不容易!

[Note] 以上公式如有錯誤, 還請專家告知, 謝謝!

我讀 «敏捷開發法的逆襲»

在蘇拉颱風的侵襲之下, 全島幾乎都放了個颱風假. 在此難得的假期, 當然要好好地研究一下宏碁的認購權證工作中需要用到的知識與技能. 認真再花了 2 個小時, 總算把這本書讀完. 

本書的作者是知名部落客 Teddy (陳建村), 他的筆風相當搞笑. 一般人認為硬梆梆的 “軟體工程", 被他寫得像極短篇那篇好玩. 不然這厚達 400 頁的工程書還真不知道要看多久? 以全書的架構而言, 大概可以分成幾各部分:

Part 1: 軟體工程的現況

這部分在於吐槽一般人對於軟體工程的輕視. 一開場就像看 BBS 八卦, 當然就比較願意往下翻書了. 老闆們可能認為加人, 加壓, 加班, 加薪 (?) 就可以搞出軟體. 不過對於軟體開發人員而言, 最重要的可能是環境: 足夠的軟硬體設備, 高品質的測試與開發人員, 標準開發流程, 自動化測試與持續改進的心態.

Part 2: 什麼是 Scrum?

Scrum 先前我概略介紹過了, 更有幸得到朋友的補充. 基本上 Scrum 是敏捷開發  (Agile Development) 方法的一種. 作者認為 Scrum + Lean + XP (eXtreme Programming) 才是正解. Scrum 基本上定義了如何定目標? 如何 review? 的基本架構. 按照台廠的慣例, 服用後副作用不至於太大.

而  XP  正如其名, 它完全顛覆系統廠或是 SOC 廠對於軟體開發的認知. N 年前 Mr. Right 讀了 XP 後, 跟我說要把大家的座位圍成一個圈圈, 我看了看方方正正的 cubic 後, 只能答應讓大家儘量坐在一起… (OS: 同一個 team 確實坐在一起, 只是每個人都有三面牆.)

XP 當然不是要大家圍成一圈那麼簡單, 這僅僅是 XP 五大價值中 “溝通" 的某種展現方式. 溝通不良是造成 bug 的主要原因之一, 打破個人的 cubic 後, 想要躲回自己的角落也就不可能了.  我們更進一步可以要求 pair programming, 讓兩個人同寫一份 code. 一個人寫, 另外一個人看著他寫; 然後再定期交換角色.

第二項價值叫做簡單. 工程師為了要應付進度的壓力, 往往會畫地自限, 告訴自己我在這種時程要求下, 就頂多只能做到這樣. 這種苦同行的人應該都吃過, 所以必然能夠諒解最快的 solution  不是最好的 solution. 不過只要有空, 工程師最好再回頭重構 (refactoring) 自己的代碼, 務必使它在功能不變的情況之下做到優化.

第三項價值是反饋. 反饋愈早, 錯誤愈少. 因此自動化測試的需求就應運而生. 當然, XP 的要求不只是如此, 它甚至希望客戶就坐在旁邊提供立即的反饋, 以及團隊成員迅速給予 review 意見. 為了早日見到設計有無偏差, 持續整合可以提供早期的診斷. 比方說 UI 先畫個框框就被 review, 總比每個 component 都畫好再 review 有用. 到了木已成舟的時候, 根本就改不動了.

第四和第五項價值是尊重與勇氣. XP 講求早提早發現, 儘快治療. 不可諱言, 早期的東西當然很遜, 因此要給予尊重. 我才寫 for  三個字後面的 pair programmer 就鬼叫為什麼不先 do 再 while, 我想誰都寫不下去了是吧! 所以一方面要尊重, 另外一方面要有勇氣. 看著同伴擺爛而照單全收, 那麼 XP 就沒有意義了.

至於 Lean 是甚麼碗糕呢? WIKI 有寫. 作者看中的是它的看板管理. 如果大家去過大陸的系統廠, 應該很容易看到這種看板.

[截圖自 http://www.infoq.com/cn/articles/hl-kanban-task-management/]

有了看板輔助之後, 我們就可以避免每個  sprint 都各顧各的的困擾. 因為 Scrum 的焦點在於 story 的完成, 有沒有達到目標. 但是缺少 Lean 看全部 (see the whole) 的宏觀. 到底多少工作已經完成, 那些還在 queue 裡面, 有沒有互卡的情況, 我們用 Lean 就可以補足  Scrum 的缺點.

Part 3: 精實生產, 減少不必要的浪費

這部分前幾天已經整理過了.

Part 4: 開發軟體一定要加班, 有沒有聽錯?

這部分可以視為作者對於加班的抱怨. 不過他自己已經升格做老闆了, 哈!

Part 5: 換顆腦袋 – 軟體工程的全新思維

此一單元內容比較雜亂, 很難歸納出一個中心思想. 我就引用其中引用洪蘭老師的一句話吧!

停留在港口的船是最安全的, 但那不是造船的目的.

Part 6: 軟體架構

基本上, 這裡引用 Eclipse 來說明什麼是好的軟體架構.

Part 7: 人機介面

在此一單元中介紹了 GOMS (goal, operator, method, and selection rule). 首先要明白設計此 UI 的目的 (goal) , 然後決定怎操作 (operators) 來達到此一目的. 而 method 是 operator 組成的, 重點在於達到目的可能有多個方法 (method). 最後 selection rule 則是提供選擇權給 user, 讓他決定要用哪一種方法. 就拿PC 的輸入操作來說好了, 可以選鍵盤組合, 可以換 hot key, 也可以用滑鼠點工具列.

Part 8: 測試與整合

策是真的是一門學問, 而自動化測試是一門更大的學問. 看來 nightly build 還是不夠的, 我們應該要有系統地導入單元測試的方法. 雖然整合測試比較容易做, 任何一個不懂細節的人都可以寫整合測試 – 像是影片快轉之類的. 但是要把單元驗證好, 非得要作者認同並親自下海才有可能做到. 因此這部分的困難度更高.

作者還提到 10 分鐘建構 (build) 的概念, 並且希望在 build 的過程中就把單元測試也順便做完. 我想這件事對於 SOC 基本上是不可能的. 因為我們採用太多的 open source, 代碼的數量也過於龐大. 如果要加一條測試規範, 我想假設 “沒改過的東西都是對的" – 例如 Android 那包 10GB 的東西, make 完還變成 24GB.

昨天富士通的同事興沖沖地拿一支夠大的大拇哥給我 copy Android, 還建議我壓好再 copy 比較快. 但是我看到裡面已經有幾個小檔案, 又是 FAT32 檔案系統, 單一壓縮檔還是放不進去. 那就整個目錄 copy 吧! 反正, 明天鐵定放假~~~ 

軟體開發中的七種浪費

Teddy 大的 "敏捷開發法的逆襲" 我還沒有看完, 不過裡面提到的七種浪費行為已經可以整理出來了. 所謂的 "七宗罪", 本來是針對豐田汽車生產過程中的品管. 但是拿來套用在軟體上確實也並無不可.

1. 半成品 (Partially Done Work)

很多功能我們做到一半, 說打通了嗎? 還沒有. 不過可以 demo 喔, 看著都會動, 要圖有圖, 要數據有數據. 這些半成品其實是不能量產的! 如果不能一口氣把半成品推向成品, 久了就會變成廢物. 後來不是規格改了, 就是人改了, 公司投進去的資本就在無形中被浪費掉.

2. 多餘功能 (Extra Feature)

基本上, 沒有主管的要求, 很少人會寫出多餘的功能. 具有要五毛給一塊性格的工程師非常罕見, 雖然他們有時候會被批評為想太多, 進度太慢. 但是比起想太少, bug 很多的人, 我還是比較喜歡前者.

如果說是多餘的或是無效率的代碼倒是很常見, 可以很精簡做完的一件事, 有些時候也會被很囉嗦的方法來達成. 像是我以前 trace GPS 的組合語言時, 就發現這邊的 sin(x) 代碼用泰勒展開式與查表法強化計算速度, 順便把泰勒展開式很接近的 atan(x) 也寫在同一函式節省 code size ; 那邊的 cos(x) 卻是用 sqrt(1-sinx(x)2) 暴力達成, 大吃 sin(x) 的豆腐. 可見不同的工程師自我要求也不相同, 主管的功能在這個地方也可以有所發揮.

[註] 講到豆腐, 我不得不推薦一下中華豆腐 (4205 的恆義), 它不錯.

3.  重複學習 (Relearning / Rework)

所謂的重複學習重點在於重複是個浪費, 但學習不是. 大家各寫各的 code, 為何會重複呢? Teddy 大比較著眼於測試的部分, 因為測試的人要學習如何測試. 如果把 test 做成自動化, 就可以減少測試人員學習的時間.

不過我感觸比較深的部分在於系統整合的階段. 如果我需要一個與使用者互動的功能, 上面包括 UI 的呈現, 中間牽涉 framework 的實施, 底層要把資訊 parsing 出來. 那麼誰要負責 study? 如果大家都去看 spec., 絕對是一種浪費. 若是指定某人去 study, 而他沒辦法把架構從上到下講清楚 (這也點有強人所難), 導致其他人必須在更短的時間內自行搞懂, 這也是重複學習. 雖然此時連一行 code 都還沒開始, 浪費在其中矣.

如何消除這種浪費呢? 我們想想今年的紐約尼克隊. 它需要一個能兼顧得分和助攻, 兩者都還不錯的後衛. 如果沒有這樣的人才, 教練只好要求得分主力偶而也幫忙助攻, …接著就會一團亂. 所以我覺得重點在於人才, 甚至是板凳深度.

4. 交接 (Handoff)

不用說, 交接一定是浪費. 大家都不希望有交接, 不管是主管或是工程師都一樣. 交接的接收人通常想完全沿用舊 code 不要去動它, 或是全部砍掉重練. 很少聽到接收人稱讚他收到的 code 完美無比, 通常將它評價為 "能用" 就很偷笑了. 畢竟就算是被接收人吐槽為很爛, 不能用, 主管也只好買單這種說法, 不然難道要找一個懂得欣賞的人來交接?

5. 工作切換 (Task Switching)

如果 assign 太多工作給同一個人, 對方幾乎都會抱怨的. 就算是努力做事不抱怨的人, 也很難在許多八竿子打不著的工作中迅速切換. 這就像是把許多工作同時丟給電腦, 最好的作業系統也只能保證優先級最高的工作先完成, 其他的…再說啦.

Scrum 的每日站立會議就用來確保大家所做的是都是最優先的.

6. 延遲 (Delay)

延遲的浪費在於導致下游的工作無法展開. 後手的人不得不撥一點心思來 polling 上游的狀況, 並且導致他/她的下游也跟著延遲.

7. 缺陷 (Defect / Bug)

有嚴重缺陷的成品或是半成品都會對下游造成不遜於延遲的傷害. 一個有問題的 commit 導致全 team 的人都編不出新版, 這個代價真是不小. 更不用說 bug 流落到客戶那邊後, 甚至可能造成退貨的危機. 據說某名牌 IC 設計公司的產品就是因為連續開機一萬小時後會自動關機而導致全部退貨. 追究其原因, 也不過就是設計者的觀念瑕疵而已 – 把測試休眠的時間參數寫成一萬小時, 反正客戶也不可能用那麼久不關機, code 就留著以後還可以回收 – 後來真的整個產品都回收了.

我個人也遇到過一個好笑的 bug. 當年做翻譯機的時候, 我自認已經交接完了, 大陸的同事忽然慌慌張張地打電話給我, 說這個 bug 他們解不了, 一定要我去現場看一下. 據說我們的翻譯機很怕遇到快譯通和女生, 只要是女生去試用或是和快譯通放在一起 demo 就會當機, 但是和它牌的同時 demo 倒是沒事.

我過去看了 code 之後, 發現 silence detection 的 zero crossing 寫在 share memory, 但用完後沒有清掉. Co-processer 以為這是 main chip 的 command code, 一執行當然就瘋掉了. 至於為何最怕快譯通呢? 原來快譯通為了聲音好聽, 特別提高輸出的 pitch. Pitch 高, zero crossing 就大到和 command code 剛好值一樣, 才會發生這個 bug. 這兩個故事告訴我們, QA 要找女生. 測試用的 code 一定要用 define 包起來, 這樣就不會導致把測試 code 變成量產版本的問題.