zmcx16's Blog: 12月 2020

2020年12月26日星期六

2020年投資績效報告

今年因為肺炎大流行的關係, 整個投資市場震盪的超可怕, 不過因為後期美國政府無限QE大撒幣, 所以即便經濟沒回來, 股市卻也因為這些熱錢狂漲, 然後這波行情大多反應在科技股上面, 這次疫情重壓金融股的我反而沒撿到什麼甜頭, 雖然當初撿金融股的時候就有長抱兩年以上的打算, 不過內心還是有點小不是滋味QQ

下圖是今年年初到12/25的績效表現, 首先是MWR (金錢加權回報率)

以MWR來計算今年績效有11.52%, 不過會有這數字主要是今年有解了一張美金定存保單, 以及把台幣存款拿來加碼才有這數字, 如果看TWR (時間加權回報率), 績效就低的可憐 (2%):

雖然今年的績效這樣看很差, 不過該說幸好去年績效超好, 再加上有把定存拿來加碼的關係, 所以雖然看%數不怎樣, 可是只看收益金額的話其實有賺到去年的一半, 實際看到報表時有嚇了一跳, 深刻的感受到滾雪球的威力是如此的美妙~。

今年的美股大盤指數相比, 道瓊工業表現最差只有5.82%, 標準普爾500則是14.62%, 而科技股指數的那斯達克指數以及費城半導體則是超可怕, 分別有42.71%以及48.69%的漲幅, 以疫情來說雖然帶動了不少科技產業的成長, 不過個人來說還是覺得這漲幅太嚇人了, 尤其是某些科技股漲到本益比幾百甚至破千的, 用常識就覺得這已經不理性到一個極致, 畢竟一家公司到底要成長多快才有辦法趕上那極高的本益比阿... 比起靠營收成長去追上本益比, 股價之後回檔到合理價位可能性還比較大, 不過說是這麼說, 其實是自己不敢買這種高本益比的個股, 所以也就賺不到這種飆股行情了...。

再來直接看今年跟大盤的績效比較圖(TWR), 可以看到今年最慘時績效甚至到-40%:

績效會這麼差主要有幾個原因:

1. 3月股災來的時候, 有近9成的持股全部跌破停損, 而跌破停損後沒幾天因為大盤又飛快漲回去, 就很樂觀的覺得會V型反轉, 然後那時候跌最慘的就屬金融股, 就撿了一堆便宜的金融股, 結果沒想到那時覺得撿到便宜的金融股股價連半山腰都算不上, 雖然撿了便宜10%~20%的金融股, 然而那堆金融股最後有些卻跌了超過50%以上, 這代表至少要漲100%以上才會持平, 導致我的整個投資部位績效虧損一度達到40%。

2. 因為自己的投資方式一直以來都是找好公司撿便宜, 而且都是有閒錢就買好買滿, 今年這波疫情下我也還是一樣完全不留任何現金, 還分別在2、3、 5、 9月從台灣匯錢加碼, 結果加碼的時間點有一半都在最糟的地方(不過實際上我也不會預知未來, 不知道哪個時間點才是好的加碼點, 就像現在明明疫情還是很嚴重, 美股卻依然創新高...)。

不過說實在的, 就算加碼在糟糕的地方, 唯一的欣慰就是我沒有被反覆割韭菜, 因為我相信自己買的公司體質很好, 雖然會因為疫情跟政府政策減少收益 & 虧損一陣子, 可是只要疫情結束, 公司轉虧為盈時, 股價會有很高的機率回到疫情前的水準。

另外雖然看起來今年是賺錢的, 可是實際上因為美國大撒幣, 導致美金對台幣狂跌, 今年的匯率跌了快7%, 所以賺的美金還要算上這些匯損, 不過以我來說其實算還好, 因為我本來就打算只有退休的那天才會把美金匯回台幣, 不如說現在美金便宜更是好機會, 讓我有更多加碼的空間!!

最後原本想貼上這一整年的交易清單, 可是發現清單太長了..., 以過去來說, 我只會持有4~6檔個股做分散風險, 可是今年因為疫情的關係市場波動超大, 今年為了分散風險我改持有了10~15檔個股, 雖然因為這樣可以讓非系統性風險降低, 可是金融股大跌那時屬於系統性風險, 所以有分散跟沒分散根本差不多, 不過那時就是金融股最便宜也只想買金融股, 只能說沒辦法嗎...XD

另外因為持有的標的變多了, 所以要關注自己的投資部位就得花更多時間, 為了省這些時間今年反而做了不少幫助自己快速檢視持有跟關注個股的網站, 因為這樣做了不少有用的工具, 算是因禍得福吧~。有興趣的話也可以參考一下, 雖然個人網站那塊的部分都是只做給我自己看的就是了~

個人持有 & 關注清單: https://project.zmcx16.moe/?page=investment-stocks

凱利公式 & 個股績效: https://project.zmcx16.moe/?page=investment-formula

美股搜尋過濾網站: https://norn-stockscreener.zmcx16.moe/

希望這次的疫情可以早日平息。

2020年12月25日星期五

[網站開發] 美股搜尋網站 Norn-StockScreener 加入Cache改善查詢效能

上次的開發心得:

[網站開發] 美股搜尋網站 Norn-StockScreener Ver1.0 Release

這次主要是幫後端程式加上cache, 這樣就不用每次查詢都要跑去DB問一次, 查詢時就直接從cache做條件過濾就好。而cache的更新則是透過background thread每30分鐘去query DB更新cache, 雖然跟之前的查詢結果相比會有最多30分鐘的資料更新落差, 可是我的爬蟲跑完所有美股資料本來就要花上半天左右, 多個30分鐘的落差去換取使用者體驗還有DB查詢的負擔, 個人覺得是非常划算的! (畢竟以常理來說, 後端伺服器程式本來就不應該頻繁去DB查詢, 而是資料能存到cache就盡可能存cache, cache沒有或是資料庫有更新時在更新cache就好。)

決定好要加Cache之後, 再來就是想該怎麼實作了, 說到Cache第一個想到的就是火紅的Redis, 原本想說終於有機會可以開始玩Redis了, 可是研究下後發現, 覺得Redis並不適合用在我這個網站上, 原因有以下:

1. Redis本質上就是個cache server, 以cache的需求來說是非常強大的, 而且還支援簡單的query查詢, 可是他本質上依然不是DB, 不能做到NoSQL的各種查詢功能, 當然要做成類SQL查詢的cache table還是做得到的, 可是基本上就是做一堆reverse mapping table, 下面這篇就有教學怎麼設計Redis的cache table來做到SQL查詢:

How to get SQL-like Experience with Redis?

以上面的例子來說, 等於一個where條件我就要多做一個reverse mapping table, 而以stock screener來說幾乎是滿滿的過濾條件, 要做這麼大堆的reverse mapping table根本不划算, 除非今天我需要存到cache的物件很大, 用這種方式才划算, 以stock screener來說整個物件大小幾乎就等於過濾參數, 做這個感覺就撿不到便宜。

2. Redis基本上有需要用到的地方是可以水平擴展跨機器的程式, 讓所有程式都能共用 & 修改cache資料, 可是我的後端程式只放在一台VM上, 應該也沒有水平擴展的需求(畢竟要+機器就要要多花錢...), 如果是都在同一台機器上的process / thread需要共用cache的話, 那做shared memory就好, 根本沒有Redis出馬的必要阿...。

綜上所述, 就決定Cache直接用shared memory了, 而做法也很簡單, 後端伺服程式起來後就去跟Cosmos DB要資料, 然後存成JSON Array到記憶體裡, 之後有個background thread會每三十分鐘去跟DB更新cache, 而網頁前端打來的query資料則是直接用記憶體內的JSON Array做Linq查詢, 在吐回結果就好。

下面是有用cache跟每次去DB query的unit test比較結果, 48筆unit test沒有用cache要花1分53秒才跑完, 而有用cache則只要3秒就跑完了, 跟預期的一樣不用每次去query DB果然改善很多。

Cache的部分做完後, 還有些地方是需要設定的:

1. IIS的web application是會idle timeout以及regular recycling, idle timeout預設是20分鐘, 等於20分鐘沒有request那process就會直接停掉, 下次第一筆request就得等process起來 + 從DB讀資料, recycling的問題也一樣。

為了解決這問題, 這邊將設定改成6小時, 這樣至少process可以活6小時, 不改太大是怕IIS一直不recycling怕會有什麼奇怪的問題發生。至於6小時後該怎麼辦, 這邊我是直接搭配freshping網站服務, 這個網站可以讓你設定50個網站, 然後他會每5分鐘幫你打一次request幫你檢驗網站是否正常工作, 搭配這服務我可以讓我的IIS網站就算idle太久而睡著, 也會在5分鐘以內被喚醒並更新cache。

2. 另外測試了一下, 從DB取得所有的個股資料大概要花1.7秒左右, 而這段更新cache的資料是得被lock保護的, 這代表使用者在query時如果撞到每30分鐘更新cache的時機的話, 會被那1.7秒卡住, 雖然1.7秒也不會說很長, 不過還是想解決這問題。

至於想到的解決辦法也很簡單, 我就直接做兩份cache就好, 然後用一個flag去切換, 這樣cache更新跟使用者查詢用到的cache就不相同, 我只要lock保護那個flag就好, 這樣使用者就不用去花時間等待cache更新的時間, 畢竟切flag連1ms都不需要XD

這次更新就做到這邊, 下次更新應該是Google Play Store上架APP的部分, 目前網站的TWA App已經做好並提交到Google Play Store了, 就等審核結果如何~。

2020年12月20日星期日

[網站開發] 美股搜尋網站 Norn-StockScreener Ver1.0 Release

上次的開發心得:

[網站開發] 美股搜尋網站 (1) 後端程式開發 - 使用Azure Cosmos DB & Azure Function

在上次的開發心得提到美股資料取得&每天更新資料庫的部分, 今天這篇則是把接Cosmos DB的後端程式 & 前端第一版做完了, 完成的成果如下:

Dark mode:

Mobile:

Norn-StockScreener網站位址:

https://norn-stockscreener.zmcx16.moe/

Github (Front-End):

https://github.com/zmcx16/Norn-StockScreener

搜尋功能主要包含了45個基本參數的過濾條件, 還有串接之前做的Norn-Minehunter美股健診網站, 畢竟這網站的開發初衷就是要滿足我的個人需求, 如果只有基本參數的過濾那我用現成的Stock Screener就好, 當初會想做這網站就是每次都要分開比對搜尋結果很麻煩, 才會想做一個滿足自己所有需求的網站!

在來會分別介紹後端跟前端的開發心得:

* 後端Server程式 *

基本上就是個簡單的資料庫查詢功能, 前端把UI的setting帶下來, 後端Server做Input檢查後就動態組成SQL搜尋條件, 再直接Query Azure Cosmos DB, 第一版就是先簡單實作有滿足功能就好。至於測試方面則是只有針對每個過濾條件寫UT, 複合條件只有靠手測測個幾條, 畢竟這種搭配組合根本不可能靠UT或手測測得完...。

另外跟以往不同的是, 原本Server程式是想照慣例放到自己的Azure VM上, 可是那個VM只是一個月500塊的Azure B1S, 記憶體只有1G, 而且上面已經塞了5個web應用程式了..., 目前測試如果直接從DB拉所有股票資料, 程式的記憶體大概會耗到幾百MB, 這樣那台VM應該很容易就廢了, 還會連帶影響其他的應用程式...。

考慮到上述原因, 決定測試一下裝在Azure Function上, 畢竟Azure Function有每個月一百萬次呼叫以及40萬GB-s記憶體用量的免費額度, 應該是不至於超標, 缺點就是變成前端直連後端的Azure Function, 這樣要是遇到惡意的DDOS或爬蟲就沒辦法處理, 這部分就決定先觀察看看, 如果真的遇到了, 就再搬到自己的Server或開個新的Azure web service上了。

[後來簡單測試了一下, 發現Azure Function第一次觸發的暖機時間太長了(大概5s~15s), 決定還是先裝在自己VM的web server上, 在視情況看要不要調整spec...。]

* 前端UI *

UI的部分是用React寫的, 這已經是第三個用React寫的side project了, 不過每次寫都還是覺得自己會踩到不少雷, 而且因為寫的都是小的side project, 所以感覺自己的技術都不太有長進, 也沒有享受到React在大型應用程式上的好處, 最大享受到的好處大概就是像Material-UI這類的UI元件庫超豐富, 讓我幾乎不會有想要手刻UI元件的想法XD

說到Material-UI, 讓我最驚豔的是Material-UI的theme直接就有支援dark mode, 如果你的UI style都是用Material-UI的調色盤跟theme, 那只要直接切換theme type從light->dark就可以直接幫你底下的元件都轉成dark mode配色, 可是如果你有元件是自己寫死css的color以及background, 因為沒有Material-UI調色盤的對比跟增強色, 他當然就沒辦法幫你轉換dark mode適用的顏色, 你就得針對這些元件處理dark mode配色。

因為我大多數都是用Material-UI的調色盤, 而少數自訂義的css部分, 因為我對色彩學不熟, 我是乾脆直接用最簡單的做法, 直接在設定顏色時就調透明度, 這樣就算轉成dark mode原本設定的顏色違和感也不會太重, 算是一種取巧的做法~。

* 接下來的計畫 *

目前還有想到不少feature是想要做的, 條列如下:

1. 將網站直接做成手機App

直接把網站搬到手機App簡單來說就是PWA, 不知道PWA的可以參考以下這篇:

30 天 Progressive Web App 學習筆記 - 為什麼需要 PWA?

基本上PWA就是網站+基本預安裝讓手機瀏覽該網站有類App的使用體驗, 而近兩年微軟跟Google則是合作推出了TWA, 讓你的網站能真正包裝成app, 並上架到Google Store上! 不過要上架得滿足不少條件, 首先就是至少你的網站要先滿足PWA的規範才行。

要確定網站是否滿足PWA規範, 可以用Lighthouse這個工具, 可以直接幫你體檢你的網站的效能跟使用者體驗, 以及是否滿足PWA的基本需求, 下面是Norn-StockScreener測試的結果:

效能的評分結果不太好, 主要原因是我的React元件太多, 畢竟光是基本過濾參數就有45組了, 這邊要改善的話, 可以把讓網站不要一口氣讀取所有元件, 把過濾參數做成Basic跟Advanced兩種, 網頁讀取時只先render basic的元件就好。而除了效能指標之外, 再來就是PWA的需求有沒有滿足:

從上述來看, 缺的都是以在mobile app上運作需要的功能, 像是網站離線連不到時offline可運行的模式, 還有可遮罩式icon等等, 值得高興的是, 像是CreateReact的樣板或是gastby都已經有現成的套件可用, 如果沒有特殊的客製化需求, 只要安裝對應的套件在設定一下config就行了, 如果要不靠套件從頭自己搞八成又得花大把時間了, 真是萬萬歲XD 設定好以後再跑一次Lighthouse, 順利取得了PWA徽章, 完成上架Google Store的第一步了! 剩下的步驟就之後慢慢搞定吧~。

2. 增加Tag功能

目前的網站功能只有基本參數過濾以及Norn-Minehunter掃雷過濾, 再來會想做些Popular Tag的功能, 像是有產業別的tag可以選, 點擊後就能導到該產業別的美股基本&比較資料; 還有像是各大基金持股Tag這類特殊功能, 每種Tag都會導到對應功能的summary頁面, 這塊算是一個超級大的feature, 之後打算針對自己的需求慢慢implement (最近有點太操, 步調要緩一緩XD)

3. 後端Server效能改善

目前只要網頁按Query按紐, 後端Server都會去DB查詢, 可是大多數的Stock Screener網站的搜尋結果都超快, 我在想應該是他們都有做cache, 然後query等過濾條件都在memory裡做掉了, 後端Server只要大概每15分~30分鐘去跟DB拿更新的所有個股資料到記憶體就好, Query本身不需要去問DB, 這塊想之後有空就實作進去(想暫時耍廢一陣子先~)。

這次的開發經驗就分享到這, 再來工作應該會很忙, 希望有餘力能繼續完成上面的future tasks~。