NimoLife

markdown Today is my Plank workout day 3, I can hold in `02:01` second, I will continue do it. I starting to make probiotics live in my body, so I take `NOW Foods` 's Probiotic-9 50Billion. I hope I can overcome the milk digestion issue. I refactor my company code with follow: ```ts // old export const LinkTypes = ['facebook', 'youtube', 'instagram', 'linkedin', 'x'] as const; export type LinkType = typeof LinkTypes[number]; ``` ```ts // new export const LinkType = {   Facebook: 'facebook',   Youtube: 'youtube',   Instagram: 'instagram',   Linkedin: 'linkedin',   X: 'x', } as const; export type LinkType = typeof LinkType[keyof typeof LinkType]; export const LinkTypes = Object.values(LinkType) as readonly LinkType[]; ``` It can compatible with old usage like `const link: LinkType = 'facebook'`. Also can use readable and no typing string like `const link: LinkType = ...

markdown Today I make an decision that I will write something every day. cuz I want to imporve my English output skills. I want writting journal to be a habbit. I make some rule to let this things easy to execute. Here is my rules. ```markdown Try to use English to write something. - Consistantly to do this. - Don't correct any syntax or gramma or words until I used to write this journal. - Don't care how the essay length I should write, just consistant write. - Upload to the blog. Whatever. ``` This rule may change after I write every day and I wil not feel terrible to write. I don't know whether I can continue to do it, but at least this is a good start. Today I go jogging with my friends, tired but we achive our goal. Ibit is fall down to 44.40, Oh my god that is horrible.

markdown # 關於RCA * RCA : 根本原因分析 ## 結論 * RCA是一種通用報告的格式，提供了一些通用的方法與計巧，讓問題可以從根本上被解決，可以參考[Here](https://asq.org/quality-resources/root-cause-analysis#resources) ## 我們小組上使用的簡易格式 * I. Problem Statement -> 定義/描述問題 * II. Cause & Effect -> 分析原因/造成影響 * III. Solution & Evaluation -> 提出解決方案/評估可行性 * IV. Topics behind the scenario -> 延伸討論 (如果還有的話) ### 節錄部份壓測的RCA報告 ```markdown ## I. Problem Statement * 接入平台需要能承受較大量的用戶。 * 壓測試後發現承載人數低下。 * 測試行為，登入 + 打訊息 + 圖片上傳 & 只打訊息，以不同的人數成增長與訊息數量測試。 ## II. Cause & Effect ### 登入導至OOM * 登入API 密碼加密每次使用64MB空間加密 -> 過多記憶體導至系統崩潰。 ### 併發下物件過多導至GC壓力 * 部份API在高併發下產生大量的物件建立與釋放 -> 使CPU 70%以上的時間花費在GC回收上 ### 編解碼使用的方式不適合高併發場景 * 通訊server的編解碼使用`map[string]interface` -> CPU效能 + GC壓力 ... ... ## III. Solution & Evaluation ### 登入導至OOM * 將密碼加密使用的空間降低 * 需注意玩家的token失效問題 * 要編寫過渡的程式才能無感更換 ### 併發下物件過多導至GC壓力 * 對於重覆使用的物件，在高併發下應使用sync.Pool池來減少GC壓力 ### 編解碼使用的方式不適合高併發場景 * 通訊server的CPU壓力可以透過多台機器分擔壓力(目前的做法) * 或調整編解碼方式減少物件壓力 * 由於MQ訊息沒分離，解決...

markdown ## 結論 在使用make初始化slice的時候，要考慮初始的長度，若是只用兩個參數會使長度等於容量，也就是已經初始化過了，這時再用append的話就不會如想像那樣從頭開始新增資料了！ ## 環境 go v1.19.6 ```go type Card struct { Word string Explain string } ``` ## 預期的對照組 * 這是正常運行的 ```go stackB := []Card{ { Word: "test", Explain: "test", }, { Word: "test2", Explain: "test2", }, { Word: "test3", Explain: "test3", }, } fmt.Println(stackB) // worked stackB = stackB[:2] fmt.Println(stackB) // worked ``` ## 非預期的狀況 ```go stack, _ := GetCardMap() fmt.Println(stack) // worked stack = stack[:2] fmt.Println(stack) // only 2 empty element func GetCardMap() (m []Card, err error) { file, err := os.Open("frequecydic.txt") if err != nil { return nil, err } defer file.Close() totalCount, err := VerifyDic(file) if err != nil { return nil, err } // move file pointer to the beginning of file _, err = file.Seek(0, io.SeekStart) if err != nil { return nil, err...

markdown # 睡覺使你更有效率 ## 自我對話 我們都知道，所以我有個想法，因為我總是讓自己睡的很少，我想是因為我認為我的時間變少了，我要讓自己知道充足的睡眠->更有效率的做事->更多的時間。 我要讓自己認為睡覺是很重要的，其實我原本就知道睡覺是很重要的，但我還是睡的很少。 我要讓這個想法更具體一點，我覺的睡滿八小時是很重要的，所以我要在`起床前九小時入睡，睡到自然醒即可`，這件事情很重很重要！ ## 助眠的建議 * 低溫 * 規律的起床時間與睡眠時間 * 冥想 * 起床之後馬上接觸太陽光或任何足夠強的光線 5~10 分鐘 * 在睡覺前都做一樣的事情 (儀式)

markdown # 非同步資料落地對於IM的重要性 ## 結論 今天我在將建立訊息的API，從先在MySQL落地，改由直接送給Client並另外起一個Cron做異步落資料落地之後，效能從`每秒20人送訊息200人收訊息(4000封/s)`提升至`每秒60人發訊息600人收(36000封/s)`，實屬相當大的進步。 ## 原因 我想是MySQL對於多次連接+小資料的更新與新增很不拿手，因為MySQL每次都是要碰Disk的，而且資料不是連續的導致I/O的時間會很長。 在調整成異步落地之後資料不會經過Disk，而是從API->MQ->Websockt->Client，所以快很多。 並且在異步的資料落地時，採用的是批次插入資料，這可以讓MySQL只需要少量I/O就可以完成大筆資料插入。 ## 應注意的部分 ### 不適合的場景 * 100%訊息都無法遺失，只要預到停電，OOM等事故，Mem是會消失的。 * 資料有立即提取的需求，既然是異步，就無法保證在加入一筆資料之後馬上查詢可以查到資料。 ## 適合的部份 * 資料不是那麼重要的，可以接收遺失，策略可以是幾分鐘內的可能會遺失，