Posts

代碼庫連結: https://github.com/emacs-eask/cli 在 2023 年的時候, 我寫了一篇關於 Elisp Language Server 的文章. 那是其中一個把 Elisp 用作一個執行環境的一個實驗性質的專案. 在開發 Eask 的開發過程中, 我無意間發現他是個可以輕鬆把 Emacs 包裝成一個運行時的有趣程序. 為什麼這麼說? 我們接下來看看: 🔰 執行 Elisp 程序 一般執行 Elisp, 不能像是 Python 或 Node.js 那樣直接執行一個代碼文件. python hello.py 或者 Node.js : node hello.js 就可以直接運行一段代碼. 這對 Elisp 並不困難, 只是多了一些旗子: emacs -batch -l hello.el ❓ 問題 既然可以直接執行, 那為何需要 Eask 呢? 實際上 Eask 就如同 Python 的 pip 和 Node.js 的 npm 一樣, 它們都有著管理包的重大責任. 但唯一不同的是, Emacs 的環境是共有的, 所以沒辦法像是 npm 一樣擁有一個 node_modules. 也就是說, 任何獨立專案改變都會影響到你的 Emacs 的使用. 這對如果不使用 Emacs 的用戶可能不是個問題, 但這樣包管理上就會非常繁瑣. 於是 Eask 的重要性就顯現出來了, 他負責解決這幾個痛點: 沒有專案依賴, 只有共有依賴 沒辦法下載和管理包 依賴會互相污染的問題 Emacs 的版本間的問題 📝 範例 接下來我們看如果在使用包的情況下, 需要寫的 Elisp 就相當不輕鬆了. ...

這裡我想記錄下我對 TDD 的看法. 這個文章並不打算對 TDD 多做解釋, 這並不是個教學文章. 🌐 網路解釋 我們先看看網路解釋: TDD 簡單來說是要先寫測試, 然後在實作. 其實這對於很多程序員來說是非常不容易的. 主要原因是因為過於瑣碎, 導致開發過程不順暢. 這點我其實是認同的, 我剛開始看的時候只覺得這也太蠢了吧? 接著看其他人對 TDD 的看法: 看來很相當多人的認為 TDD 本身真的很不友好. 🤔 ...

前幾個禮拜突然突發奇想, 想知道自己大概花了多少時間在寫程式身上 (包括學習). 於是有了些感慨. 計算公式如下. 一天平均時數 x 一年天數 x 總年分 我是從2013年的春季開始寫程序的, 然後 2014 年開始決定全力投入在寫程序身上. 而我平均一天花費的時數為 5 到 16 小時之間, 不間段的寫, 包括假日. 我的時間非常好算, 因為我除了特定會出遊的時間以外, 平時除了吃喝拉撒睡以外, 就是只會寫程序. 我從小一直有不易睡覺的問題, 導致我一天不怎麼睡覺, 很多時候甚至是不睡覺的. 所以我很常是會寫超過 16 小時的 (最長應該寫超過 36 小時). 🤔 這其實對我來說是很痛苦的, 不過這篇不打算多做解釋, 就單純想記錄我花費了多少時間. 開始計算, 上限: 365 * 12 * 16 = 70,080 (小時) 平均: 365 * 12 * ((16 + 5) / 2) = 45,990 (小時) 下限: 365 * 12 * 5 = 21,900 (小時) 上下限平均: (21,900 + 70,080) / 2 = 46,350 (小時) 雖然我平均數大概投入了 4 萬多個小時, 不過我感覺應該位在 5 萬到 6 萬之間. 主要是因為我一天 5 小時真的是最少情況下, 通常情況應該是 10 小時為最常見的花費時數. ...

在更早之前我就有想打一篇關於遊戲設計師的溝通問題. 這個問題已經在遊戲業界內已經蘊藏的一段時間, 並且也困擾著我. 身為一個程序員, 到底應該如何更順暢地和企劃們更順暢的溝通呢? 這篇就單純的想記錄下我所觀察到的情況, 並希望在這篇的結尾能夠更好的解答出我自身的疑惑. 🗯️ 前言 我是個專業遊戲程序員, 已經在遊戲業待了超過 6 年的時間, 實際參與遊戲開發的時間已經超過 10 年 (包含大學時期的經驗). 由此可知, 我應該算是擁有相當豐富的開發經驗的開發者, 但在和企劃們的溝通一直是有問題的. 以下我想要提出幾個大方向, 是我認為為什麼會造成這個問題的根本原因. 🗑️ 企劃的門檻太低, 沒有專業的領域知識 我想這標題會讓許多企劃們不開心, 但我認為這是個事實. 相比美術和程序, 企劃所需要的門檻遠低於其他兩類. 或許有人會說, 企劃也有許多需要知道並且了解的事情. 這我不否認, 但你認為精通更多能力的其他兩類工作職人 會懂得比你更少嗎? 連程序或美術都做不出來的人, 真得更有熱情? 真的只需要一張嘴去做事情就可以了? 接著我們可以談論溝通能力, 大多的企劃只懂得表達與自身的經驗的相關的東西. 這句話可能有點不清楚, 我們這裡舉個例子. 例如我們在設計一個遊戲系統, 這個系統將與另一個系統做特殊處理. 大多的企劃只會形容他所看到的, 並無法解析一個系統的底層邏輯和他的運行方式 (reverse engineering 的過程). 但問題是, 誰不會這樣做? 只要稍微有點概念的玩家都可以擁有的能力真的能叫做專業能力嗎? 🤔 充其量只是個玩家並在遊戲業工作, 並時常被戲稱叫做 idea generator. 難道企劃真的完全沒有專業領域的知識嗎? 實則不然, 我認為企劃應該是需要最多知識的一個領域. 但出問題的是這個業界, 具體原因需要從歷史的角度去看待. 📜 歷史角度去看待 這裡只是猜想, 但沒有根據. 實際上在很多的過往訪談中確實有透露出這類資訊. 企劃這個工作是怎麼形成的? 過往的企劃是從程序和美術 (大多是程序) 從中去分擔企劃這個責任, 大多數溝通的問題會比較少, 主要原因是領域的知識水平較相近. 久而久之, 程式和美術的分擔太大, 於是企劃這個職位就開始誕生了. 大多數認為企劃這個工作可以交由別人去做, 簡單來說就是個打雜的. ...

這是一篇關於軟體工程面試和 LeetCode 的怒罵。 🗯️ 序言 2024 年，全球數十萬人都在努力學習 LeetCode，目標是在高薪的吸引下打入科技產業。 🤔 What does LeetCode actually bring? LeetCode 提供的好處不外乎這些： 演算法 練習與 資料結構 知識 在壓力下編碼（為什麼呢？ 我們現在是在戰區嗎？） 通過編碼面試 然而，完成 LeetCode 並不能證明您是一位優秀的軟體工程師。 它只顯示您可以編寫基本演算法和解決程式設計難題。 它並不能測試基本技能，例如協作、溝通、文件、設計模式、系統架構、低階程式設計或核心電腦科學知識。 如果LeetCode只測試這些基本技能，那麼雇主要聘請的是什麼？入門級的程式設計師？ 這就像雇用一名醫生，但只測試他們的基本化學知識 - 而這些知識在現實世界的情況下很少會用到。 ⁉️ 真正的問題是什麼？ LeetCode練習與學習無關。您不會獲得對電腦科學或系統設計的深入瞭解；相反地，您只會學習如何通過編碼面試。 如果問題還不太明顯，我們可以從另一個角度來看：這就像在學校裡，學習並不是重點，通過考試並取得好成績才是重點。 這種心態也許可以解釋，為什麼有些人儘管被標籤為「受過教育」，但行為或想法仍然不佳。 現在，我們在科技面試中也在做同樣的事情。 LeetCode 不是軟體工程。 😕 💡 有哪些更好的解決方案？ 有許多更有成效的事情可以做。 貢獻 Nix/NixOS、改善 Emacs 的生態系統、強化 Java 套件管理、研究 C 與 CMake 工作流程、改善 Godot Assets 商店，或是練習撰寫解析器與語言伺服器。 有這麼多東西仍未完善，但人們卻在 LeetCode 上浪費時間。 😢 研究其他人的程式碼、與他們交談、學習他們如何解決現實世界中的程式設計問題，才是更好的方法。 這個產業之所以受苦，就是因為我們採取了懶惰的方式，只使用軟體來篩選候選人，而不評估真正的人才。 😞 😤 我並不孤單 只要在 Google 上快速搜尋，就會發現無數的怒罵： LeetCode Ruined Software Engineering… LeetCode: The Worst Thing to Happen to Software Engineering 💬 總結 我們無法逃避這個趨勢。歷史已經證明，就目前而言，這是社會所遵循的道路。也許軟體工程目前不適合我… 🧐 ...

前幾天在 LinkedIn 看到一則標題聳動的貼文 “我想我遇到了 10x 工程師”; 不過貼文內容卻讓我覺得匪夷所思. 貼文內容是這樣的, 一位工程師 (他的同事) 能夠在短時間內解決很多深度的 bug, 讓他覺得非常驚艷! 🤔 真的是這樣嗎? 這讓我想到我曾經被當作 10x 工程師的經驗過往經驗, 這事情發生在我的第一份工作上! 🗯️ 前言 這份工作是在 imi technology (應該已經倒閉) 擔任 Unity 軟體工程師. 主要工作為開發棋牌遊戲 (就是博弈). 當初選擇這間公司單純是因為離家很近, 薪水可以接受, 也就沒有想太多了. 有些人可能會對博弈的工作感到反感或有興趣. 但這次的主題跟這個產業沒有掛鉤, 只單純講軟體業的一些親身經歷. 🤔 ✏️ 概況 這個團隊總共為 8 人團隊, 有 5 名超過 10 年經驗的資深工程師, 1 名初級, 剩下 2 名入門級. 我們的分工為下: 3 名資深 + 1 名初級使用 Java 開發服務端 1 名資深使用 Phaser 開發 Web 遊戲客戶端 1 名資深 + 1 名入門級 (我) 開發 Unity 遊戲客戶端 1 名入門級學習 (不太知道他是做什麼的) 如上所示, 我負責的和另一名資深的工程師共同開發 Unity 遊戲客戶端.說來好笑, 我們這個團隊已經面臨瀕死邊緣了. 好像是老闆對我們的成績不滿意, 開發時程過長, 所以準備要裁掉整個部門 (當時我並不知道). 😒 ...

代碼庫連結: https://github.com/elisp-lsp/ellsp 我最近為 Emacs Lisp 創建了一個語言伺服器。這很有趣，因為人們認為 Emacs Lisp 的語言伺服器不會提供任何價值。這個說法是正確的，我也是如此。Emacs Lisp 僅在 Emacs 編輯器內使用，Emacs 本身是一個 Emacs Lisp 解釋器。因此，Emacs Lisp 的語言伺服器很難為 Emacs 用戶帶來任何好處。 但想像一下您可以在 Emacs 之外編寫 elisp（Emacs Lisp 的縮寫）。聽起來很有趣，對吧？ 🤔 🔰 重頭開始建立 好吧，我並不是完全從頭開始。我確實使用了一些庫來幫助我更快地設定東西。以下是重要的一點： lsp-mode elsa - 我用過他們的一些程式碼 我從頭開始的是 stdio 解決方案。令人難以置信的是，stdio 在 Emacs 的 batch 模式中是如此簡單。 💫 問題 1: read-from-minibuffer 和 \r/\n read-from-minibuffer 函數是在 Emacs batch 模式下接收標準輸入的一種方法。 這種方法有一個問題。它不會接收輸入，直到末尾有 \r 或 \n 字元。 這很煩人，因為語言伺服器永遠不會收到完整的資料包。這是我從語言客戶端收到的內容： Content-Length: 8203\r\n \r\n {json} 而，這是我希望看到的： Content-Length: 8203\r\n \r\n {json}\r\n 我花了幾個小時尋找解決方案。不幸的是，我找不到一個。然後，我決定使用 node.js 和 JavaScript 創建一個代理 stdio 應用程序，在資料包末尾轉發額外的 \r\n 。 ...

ELPA 是 Emacs Lisp Package Archive 的縮寫。它供 Emacs 用戶下載軟件包， 也是 Emacs Lisp 開發人員託管軟件包的地方。以下是著名 ELPA 的列表，請訪問他們的網站了解更多信息！ GNU Elpa (official) NonGNU Elpa (official) MELPA ❓ 為什麼? 那麼我們為什麼要舉辦自己的 ELPA？這些 ELPA 還不夠嗎？ 是的，一般來說，您不需要自己託管 ELPA，因為您需要的大多數軟件包都可以在這些 ELPA 之一中獲得（軟件包可以在 ELPA 之間共存）。 以下是您可能想要構建自己的 ELPA 的幾個原因： 您喜歡的包(尚未)出現在任何 ELPA 上 ELPA 的包裹審核需要幾天或幾個月的時間來審核（MELPA 可能是最快的） 不再維護的軟件包，您可以鏈接到新維護的分支 類似於第 3 點、你喜歡的包有bug，你可以創建一個新的fork來替換它！ 用於 elisp 包開發目的。有時構建工具就是不夠用。 📝 事前準備 關於 Emacs Lisp 的一些知識 安裝 Eask CLI 🔍 步驟1.創建 ELPA 項目 使用 Eask 輕鬆構建您自己的 ELPA。您只需要幾個命令，它就會運行。 首先，我們需要創建 ELPA 項目： $ eask create elpa <project_name> 在示例中，我將使用 “my-elpa” 作為我的項目名稱： ...

代碼庫連結: https://github.com/shader-ls/vscode-shader 2023 年 8 月 23 日。我創建了我的第一個 VSCode 插件 – vscode-shader。 我的意圖很簡單：在 VSCode 中為我幾個月前創建的 shader-language-server 創建一個語言服務器客戶端。🤔 🔰 簡單且良好的用戶體驗 首先，開發一個 VSCode 插件非常簡單。特別是為 VSCode 開發語言服務器的客戶端。 他們的網站上有許多示例和良好的文檔，使開發人員非常容易。我使用 uniteai 和 grammarly-language-server 作為參考。 📦 發布到 VSCode Marketplace 發佈到 VSCode 可能是最具挑戰性的步驟，因為您需要導航到 Azure DevOps， 這似乎與 VSCode Marketplace 完全無關！ 🤔 然後獲取 Personal Access Token， 以便將您的包發佈到市場。它仍然很簡單，但在 Azure DevOps 部分卻相當令人困惑。 然後你只需要 npm install -g @vscode/vsce、vsce package 和 vsce publish。 發佈時，系統會要求您輸入 PAT！ 您可以訪問 VSCode 的 Publishing Extensions 網站了解更多信息！ 🎖️ 成就 創建了語言服務器的客戶端, vscode-shader。 我的第一個發布的 VSCode 插件包，請參閱 https://marketplace.visualstudio.com/items?itemName=shader-ls.vscode-shader.

代碼庫連結: https://github.com/shader-ls/shader-language-server 2023 年 4 月 30 日。我創建了我的第一個語言服務器，它對某人確實有用。 我不久前嘗試過一個語言服務器，但它只是一個示例服務器，所以它不是很有用， 而且僅用於教育目的。 我選擇編寫的目標語言是 ShaderLab 語言。 ShaderLab 用於 Unity 引擎， 因此您可以編寫自定義著色器來風格化您的遊戲。與常規編程語言不同，ShaderLab 分析起來要簡單得多，因此語言服務器可以響應客戶端。 ❓ 為什麼選擇C#作為實現語言？ 由於 Unity Engine 最受歡迎的腳本語言是 C#，因此我認為選擇 C# 是最佳選擇。 💀 C# Language Server Protocal 地獄 在開始用 C# 編寫語言服務器之前，我就已經有一種不好的預感，因為我對作者 Omnisharp 的插件一直沒有好印象。我在 VSCode Marketplace 上嘗試過他們的官方 C# 插件，但說實話， 我不會說我喜歡它。以下是一些原因： 很慢 不斷的突破性變化。下次更新就沒啥作用了！ 維護者不是很活躍（但社區很友好） 儘管如此，我還是堅持嘗試一下 csharp-language-server-protocol，因為沒有其他合理的選擇。 經過幾天的挖掘，我面臨以下問題： 官方存儲庫中的示例要么損壞，要么不完整（有點無用） 過時或缺乏文檔 他們並不真正關心其他編輯。 （許多編輯器兼容問題和 PR 尚未解決） 幸運的是，我找到了 @gulbanana 創建的 thousand 語言服務器和 @tgjones 創建的 HlslTools。因此，我能夠通過看到他們的實現來完成這個項目！ 😅😇 附註: 我花了很長時間才弄清楚事情！！！💀 ⚙️ 插入 ShaderlabVS 另一個挑戰是語言服務器的引擎。什麼解析文本文檔並向客戶提供合理的響應？然後我找到了一個已 經為我做到這一點的項目—— ShaderlabVS。這是一個理想的解決方案，因為也是用 C# 實現的。 感謝作者 @wudixiaop 這個令人驚嘆的項目！ ❤️ ...