今年算是調整腳步的一年，有了許多進修的時間，可以去補足自己不足的知識點。 此篇為筆者閱讀本書後，吸收資訊結合本身從業經驗，並搜尋網路資源去撰寫，如有任何錯誤請告知，謝謝。 本篇收入該書前三章讀書心得。 AWS 常見名詞/服務 先把這些英文字在腦海中對應到相對應的服務，以後別人說這些縮寫，就可以快速理解。 Route 53：DNS 服務 EC2(Elastic Compute Clou …

2023 嶄新的一年，回顧一下 2022，針對我做過一系列會員相關的功能，並重新思考一次今年學到的知識與系統設計的想法，感謝主管與同事的建議與幫忙讓這一系列的專案能順利完成，達成人生新的里程碑。 以下影片是 demo 畫面，主要會員功能集中於會員等級、歸戶折價券、會員權益這三個功能，筆者是負責後端部分的系統設計與開發。 會員歸戶折價券 前情提要，此 …

此篇為筆者閱讀本書後，吸收資訊結合本身從業經驗，並搜尋網路資源去撰寫，如有任何錯誤請告知，謝謝。 書中提到，在面試中考到如何設計系統，你拿到題目後，第一件要做的事情就是釐清問題，做最有效率的溝通，這一點我十分認同。你有在再強的技術，如何不能切合真正需求方的需求，也是枉然。 步驟一：瞭解問題，確認系統設計的範圍 與學生時代考試不同，系統設計你需要先讓大腦理解這個需求情境，提出正確的問題、正確的假設、確認設計範圍的邊界。 針對系統使用者相關詢問考官，以利瞭解使用者與系統負載量： 誰會使用這個系統？那系統會有多少使用者？離峰時候有多少使用者？尖峰時候有多少使用者？ DAU (活躍用戶)有多少？ 針對功能面詢問考官，以利瞭解功能設計： 使用者使用系統會使用哪些功能？該系統哪些為必要功能？哪些為非必要功能？ 使用者如何使用它？預期的輸入？預期的輸出為何？ 針對架構面設計，多詢問一些問題： 預期希望處理多大量的資料？希望此系統能 handle 多少 QPS ？

接續上篇閱讀，邊看書邊延伸閱讀，轉化為文字作為學習輸出… 有錯再請指正，感謝諸位大大，好人上廁所都有衛生紙XD 粗略的估算 當你設計系統時，你需要具對數字有敏感程度，才可以估算系統穩定程度，這部分感覺也是經驗談，需要時間累積。 書中舉例情境： 先介紹一些後端負載名詞，衡量負載量的指標。 QPS (Queries Per Second)：每秒查詢次數，可以想成每秒有多少請求數 併發：時常聽到高併發，併發指某個時間點，有多少訪問同時到來 PV(Page Views)：廣義來說，頁面瀏覽數 SLA(Service Level Agreement)：服務供應商和客戶進行協議，定義服務所提供的正常運行時間等級 DAU(Daily Active Users)：每天活躍用戶 情境一：每個月有三億活躍用戶，每天約有 50% 的用戶經常使用服務，這 50% 的用戶每天平均進站兩次。 DAU：3 億 * 0.5 = 1.5 億

這是我的一小步，卻是人類的一大步，這句話出自於 Neil Armstrong，當然結果沒這麼偉大，但文件化的確是開發者邁向 Happy Coding 的一大步。 近期，自己在研究 Api 文件化，剛好我們電商這個團隊，還沒有人導入， 成了我第一次自動請纓去研究一套工具的契機，經研究後，發現導入並不困難，來看看我怎麼做的吧！ 文件化的必要性 好端端的，為什麼需要導入一 …

很久沒在 Medium 寫文章了，一方面是前同事 Win 推坑創建自己 Hugo Blog 後，想把文章重點轉移到自架的 Blog，但通車隨筆時，聽著 Spotify 感覺上還是可以記錄個簡單的知識或概念，因此，目前把這邊當作讀書心得、工作、生活經驗類別方式做書寫，在自己 Blog 會紀錄偏向技術文的程式碼，詳細的比較，紀錄於前一篇 自架網站 H …

自架網站 Hugo V.S. Medium 的選擇與優缺點紀錄 很久沒在 Medium 寫文章了！其實一直都有在紀錄學習心得，有時候用 Notion ，有時候是放在 Hugo Blog 內。 Medium 寫作一直都蠻紓壓的，但在技術文方面還是有一些限制，萌生了出走 Medium 的想法，但不至於放推 Medium，畢竟火車上隨筆或是有感而發可以在 …

此篇為實作練習理解 use 系列概念，學習課程來源 Lidemy React hooks 版本，如有觀念不清楚，再請指正，謝謝。 Table of Contents 1. useEffect 2. useLayoutEffect 3. Custom Hooks useEffect 每次渲染都有自己的 effect，發生於畫面 render 完成後執行 因 useState 是非同步，不是即時更新，useEffect 可以在 state 改變前後，去做事，更精確說法為清除上次 effect 前做事，執行渲染完成後，此時 為新的state，執行新 effect 總結：每次渲染都會清除上次 effect 後，此過程稱為 clean up function，接下來瀏覽器進行渲染畫面，執行新 effect useLayoutEffect 先看個圖 在 Browser paints screen 之前會先執行 Run LayoutEffects

每一年我們站上都會有許多活動，主要的目的不外乎是增加顧客與站上的黏著度，一但黏著度建立後，顧客才會在你的媒體渠道願意接收站上的行銷與促銷的內容，顧客再選擇進站轉換成訂單。 這次的 Line Liff 活動也是建立在公司同事的架構下，開發新的活動機制，這篇會紀錄我學習到的知識與問題解決過程。 接到工作到開發前 我是於 2020/12/10 接到需求，上線日為 2021/1/11，活動時間 1/12 至 1/19。先前的開發摸到顧客的部分，經驗沒其他資深工程師多，沒有活動開發的經驗，跟一般開發時程比較不一樣的點，活動的上線時間是 hard deadline，比較難以變動，對我是一大挑戰，於是我列了一些開發時程如下。 當拿到這個需求的時候，當然是把前人的程式碼看過一次，然後理解一下架構，知道哪些功能已經有強者幫我做完了，我不用操心，以免不必要的重工。因為整個活動檔案分成三個 repo ， line_liff 是前端與後端(顧客登入 line liff 活動頁等邏輯)、還有一個 repo 處理 api 部分(點數是否發完、參與活動細節包含使用者是否參與活動等等狀態)、剩下一個 repo 處理 cronjob (定時配發點數、紀錄活動資料統整、發送推播訊息給使用者)，上述這些也是問公司們強者再整理出來的，心裡 OS: 光是啃完強者巨人的肩膀，我還不確定我是不是能成為艾蓮葉卡呢！