Personal

《最高學以致用法》、《最高學習法》這兩本書是我在 2023 年上半年讀了覺得挺有意思的書，核心概念就是「產出」，例如唸書時能夠回答同學問題的，肯定都已經精通該知識點了。 加入 KryptoGO 後，因為團隊的成長，Leader 開始嘗試舉行兩週一次的 Backend Sharing，不僅是分享工作上遇到的疑難雜症，更可以交流不同的知識點。 起初，我可以我分享了一些過去用過的工具與知識點，隨著時間的流逝，開始感受到黔驢技窮，於是我也仿效了《刻意練習》，不斷的為了能有更好的分享品質而學習。 以下是這半年來我在 Backend Sharing 中或多或少提及或是討論到的，又分為解決方案、小工具、方法論。 小工具 由於喜歡折騰 Homelab，時不時會到 r/selfhosted、r/opensource/ 尋找一些開源的自架方案或小工具，有一些大幅度的改善了我的開發流程，而有一些則漸漸的不再使用 exa & eza & bat eza、exa、bat 都是基於 rust 寫成的 cli 替代品，exa、eza 對標 cd，而 bat 對標 cat，我會在 .zshrc 中寫上 alias。 if command -v bat &> /dev/null; then alias cat=bat; fi if command -v eza &> /dev/null; then alias ls="eza --icons" alias ll="eza --icons -lh" alias tree="eza --icons --tree" fi 還有其他性質相同的 rust 寫的小工具諸如： zoxide、topgrade、alacritty、bottom...

由於最近讀原文書讀得挺辛苦，邊用電子閱讀器看書，騰不出手用手機查字典，內建的辭典又只有英文翻譯簡體中文，在網上衝浪也找不到繁體中文的 mdx 英漢辭典可以直接使用。 所需依賴 任何英漢辭典 文內以 BOOX 內下載的英漢辭典，參考教學。 python 環境，用以安裝 mdict-utils 經測試後 windows 與 wsl 中均能完成，文內 python 環境以 wsl 為主。 任何繁簡轉換軟體 文內以新發現的 ConvertZZ 最為 GUI 簡轉繁示例。 文末有使用 OpenCC 作為 CLI 示例。 主要流程 將 mdx 拆成 txt 簡轉繁 將 txt 包成 mdx 安裝 安裝 mdict-utils ❯ pip install mdict-utils Defaulting to user installation because normal site-packages is not writeable Collecting mdict-utils Downloading mdict_utils-1.3.12-py3-none-any.whl (36 kB) Collecting xxhash Downloading xxhash-3.2.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (212 kB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 212....

TL;DR 今年還沒躺平。 你不是喜歡寫程式的人，是用程式吃飯的。 年前 CEO 這麼對我說，後面接著一段話: 像我跟他(指主管)是喜歡寫程式的，沒人打擾的話我們可以在家一直玩這些。 跟主管借了《Clean Architecture》來看，每次在看軟體「工程」的書時，都備感挫折。《程式設計師的自我修養－連結、載入、程式庫》 中提到的編譯器、連結器，我壓根就沒學過，這種滿滿的挫折感，在 Clean Architecture 中得到了解答。 台灣的資訊系在國外的最正統名稱是 Computer Science a.k.a. C.S.，而我的學士學位是資訊管理 Department of Information Management，我們接受的教育是怎麼去快速理解 domain，並在運用該領域的領域知識開發輔助用的資訊系統，課程著重在 ERP、CRM、KMS 等等資訊管理系統(MIS)。作業系統課程不會教你減少分支預測帶來的好處，資料庫管理課程不會教 Lock Level 把整張表鎖起來會被罵，資料結構課程不會教你怎麼用程式實作 linked list、tree，程式設計課程更不會去看你的時間/空間複雜度。 或許也只能怪自己在念書時得過且過，讓現在的自己需要花時間去補其他人早就知道的知識。 似乎也是因為這種挫折感給了自己莫大的動力，不想輸給「本科系」的學生，雖然已經 25 歲了，但及早發現及早治療吧?過去總是喜歡把不理解的部分都弄懂才往下一步走，也是慢慢地改變自己且戰且走、以戰養戰。 舉例來說，如果要把整個公司專案的程式碼、技術債的原因、神秘數字的由來、歷史共業等等，全部都摸熟才能開始寫 code，那可能就會失去許多成長的機會。 工作不像在學校，不會要求你每次都要一百分，應該是先做出 60 分，甚至 40 分，再慢慢迭代成 100 分。 CEO 如此說著，也符合軟體開發流程迭代機制，先拿 prototype 去撈錢再來修(?)。 除了有些設計原則是需要最初就先講好比較好(e.g. Cloud Native, API First)，似乎沒有甚麼是「非這麼做不可」，更多的是「不要這麼做比較好」。 言歸正傳，對 2023 年的展望呢，希望身體健康，也希望能拉近與同儕間的距離，多少不想輸給碩畢的同學XD。