Posts

⚠️這篇文章的目的是提醒自己為什麼 Emacs 不再值得我花時間了。 我從 2015 年開始使用 Emacs。我已經開發了 150 多個 elisp 包，並維護了 200 多個包（包括我的包）。 留在 Emacs 社區是一段漫長的旅程，我認為放慢自己的腳步，退一步思考這些年來我所取得的成就對我來說是有好處的。 💫 我是如何進入 Emacs 的？ 很多人問我這個問題，所以我決定在這裡回答一下。 我第一次看到 Emacs 是在 2015 年，當時看到的是 Casey Muratori 的 Handmade Hero 系列。 他在 Emacs 中編碼的速度讓我震驚。他如何跳到其他窗口並且永遠不離開鍵盤對我來說都是新的。 但現在看他的配置，其實並不是那麼好。他不使用任何第三方軟件包，因此他在自己的配置文件（~/.emacs 文件） 中定義了所有內容。如果不使用那些第三方軟件包，配置仍然可以很好，但它只會限制你並重新製作可能其他人已經為你完成的輪子。 除此之外，Casey 仍然是我一生所認識的頂級程序員。 ❤️ 💫 我在 Emacs 上投入了多少時間？ 就像我上面提到的，相信我。我投入了大量時間來完成我為 Emacs 社區所做的事情。如果你搜索我所有的包裹， 我在 MELPA 擁有最多的包裹。這次我已經證明了我有多喜歡 Emacs，但也證明了我對 Emacs 有多麼失望。 😥 💫 為什麼 Emacs 不再值得我花時間了？ 首先，Emacs的開發沒有任何問題。他們在保持 Emacs 的活力方面做得非常出色，我喜歡他們的心態和大部分技術決策。 對我來說，問題在於 Elisp 開發生態系統（而不是 Emacs 社區本身；考慮 Elisp 開發生態系統是 Emacs 社區的子集）。 我很欣賞那些願意為 Emacs 做出貢獻的人，但我討厭他們不考慮他們的軟件包的跨平台功能。是的，我是 Windows 用戶；實際上， 我使用所有最常用的系統（Linux、macOS 和 Windows）。我討厭當我嘗試一個軟件包時，它只適用於特定係統（不包括僅 依賴於某些系統的軟件包），但它應該適用於所有系統。我感到可怕和沮喪，因為大多數 Elisp 開發人員不關心或不夠關心少數用戶 （Windows 用戶）。甚至一些著名的軟件包在 Windows 上也不能很好地工作，magit 很慢，straight.el 很慢，helm 很慢，ivy 很慢， projectile 壞了，eping 壞了，EAF 經常壞了等等。我使用了超過 500 個軟件包在我的配置中。我可以列出大量跨平台能力很差的軟件包。 ...

我開發了 50 多個 Emacs 插件, 並且維護了將近 100 多個. 對初學者來說, 開發 Emacs 插件是一件不容易的事情, 特別是對那些想把自己的插件發行到其他的 ELPA 的人來說更不容易. 哪些 ELPA? (GNU Elpa, NonGNU Elpa, MELPA, 等等.) 這是為什麼我使用 Eask 來幫助我完成這些插件的開發和維護的工作. 所以我將 在這則文章教大家如何使用這個工具來幫助你完成插件的開發! 🗨️ 善用 --help 現今的 Eask 已經有超過 50 種以上的指令集 (包含隱藏的). 這個工具已經是個有 點複雜, 所以當你遇到問題的時候請善用 --help 這個旗幟. $ eask --help 📦 建構插件 我們這裡直接切入正題, 我會默認你已經會初始化 Eask 專案, 並且只想知道如何 有效的使用這工具! 為了方便展示, 我直接使用了自己現存已開發完成的專案 [openal.el][openal]. # Clone 專案 $ git clone https://github.com/emacs-openai/openai.git # 進入到專案裡面 cd sideline # (非必要) 印出專案結構 tree /f 我們的專案結構是長這樣的: ...

所以什麼是最快的 ELPA? 讓我們來定義一下! ELPA 最能跑? 不對, 這一點都不合邏 輯. ELPA 最快服務你? 或許, 但我不知道! 在這裡我們定義"最快的 ELPA"為建構插件的速度. 也就是多久以後我們的插件會 被更新在服務器上. 就算更新了我們的插件, 也不用等上一段時間. 你可能會想說 “怎麼可能?” 還有 “怎麼做到的?”, 讓我一一解釋! 一般的 ELPA, 像是 MELPA, 他們會從 recipes 資料夾裡取得需要建構的插件目標. 這裡的時間為 O(n), 越多插件則會花越多時間. 通常簡單的解決方法就是直接提升 硬體硬件, 來促使減少建構時間. 這裡 JCS-ELPA 使用了不同的策略. 這個 ELPA 使用了一個插件 github-elpa 來使其建構我們的插件然後上傳到 GitHub Pages. 所以到底為什麼會是最快? 主要有兩個因素: 微軟擁有 GitHub. 技術上來說, 我們的 ELPA 是直接跑在微軟的服務器上 我們使用 GitHub Actions 建構插件, 定且使用了多個 jobs (如果你不熟悉 GHA, 就想說有很多台電腦在幫你做事即可) JCS-ELPA 使用這技術來達成很多 worker 幫你同時建構插件. 公式如下: 新的建構總時長 = 原本建構總時長 / 工作者 如果工作者為 1, 建構時長則保持不變 (建構時長沒有任何改善). 舉例, 如果原本建構總時長是 10 分鐘, 開 5 個工作者 則會減少為 2 分鐘. ...

這是一篇又來記錄我生活上問到難題的文章. 不想接收負能量請離開! 事件 前幾天我跟我姊發生了一些爭執, 姊弟吵架很正常, 但這次吵得很兇, 我們彼此都哭了. 此事情 將以我的個人為出發點去敘述始末! 衝突的開端 那天2023, 美國舊金山時間1月10號晚上, 我們剛抵達舊金山, 抵達當地的飯店後, 一起出去買晚餐, 這之前 我不知道發生什麼事情, 我姊佳欣貌似與我媽相處的並不愉快, 並抱有不滿. 屆時, 我並不知道發生什麼事. 只知道到了外帶去(我們去買晚餐), 姐姐佳欣不願意幫忙拿自己的晚餐餐盒 (共三人份). 當下我很不滿, 我和我媽的手已經沒有手付帳, 她沒有選擇幫忙. 回到飯店後, 我撈刀並出言說她是"CryBaby". 沒過一會兒, 她暴怒吼叫並出手攻擊推擠我. 我當下反應不及, 差點把他的晚餐打翻 (對, 我拿他的晚餐). 她吼道: 我脖子痛,部能夠體諒我嗎? 不要以為你是躁鬱症, 大家都要忍讓你 這飯店是我訂的, 你不要住! 滾出去! 諸如此類的發言. 當下我是驚訝的, 我沒想到一句"CryBaby"會到她如此憤怒. 我認為"自己的便當自己拿, 不是寶寶是什麼?" 感受 理性陳述事實後, 我想感性表達我的感覺, 當下我也很生氣, 我也試圖攻擊她. 但當然沒有成功, 因為她還躲在 她媽媽的保護傘下. 反倒是我被我媽抓傷, 腳也受了傷. 明明我是被攻擊者,卻被我媽說"因為我是男生"這種 性別歧視的話給制止! 我是生氣的, 我是男生難道被女生打就不還手嗎? 男生都該死嗎? 我很生氣, 當下我直接打我自己兩巴掌 (很響亮的那種) 並吼道 “那我去死好了?” 蹦痛哭覺得受委屈, 出發點為: 希望姊姊佳欣能幫忙拿晚餐 覺得自己是她弟弟, 時常拿自己憂鬱為理由, 卻不管有躁鬱症的弟弟? 我被攻擊, 她沒事, 我媽和我都受了傷, 事後假好心關心媽媽, 我很委屈 我心情很複雜, 不是因為覺得自己做錯了什麼, 而是對整體事情覺得很無奈. 我對外人, 我可以選擇不再往來. 對我姊, 我沒辦法因為我媽希望我跟她好好相處. ...

我一直以來的的 web hosting, 一直是使用aws. 但最近總覺得價錢太貴, 而且很多資金的使用 並不是這麼貼心. 總是莫名其妙多了一些費用. 當然, 這些並不是說aws有問題. 不過它們這方 面的機制, 我本身並不是很喜歡. 所以我決定在這個月, 換一個web hosting的公司. 更換的 理由如下: AWS收費機制不討人喜歡 價格對於小型用戶太過昂貴, 而且不是這麼需要 UI介面有夠醜, UX很糟糕 它們大量的制定他們aws服務的專有名詞, 這部分技能是無法轉移的 (EC2? Route 53? 等等) 接著, 進入細節. 📋 遷移網域名 這次遷移的目標是 jcs-profile.com 這個網域. 查一下 who.is, 註冊商是 amazon.com. 我之前是使用 AWS 裡面的網域 註冊服務 Route 53 來註冊這個網域. 不過 我想把它移置到 Namecheap. 這家並不是最便宜的, 不過他的優點大概是老牌, 介面也算乾淨好整理. 不會有些雜七雜八的東西. 不過我自己 也沒有用過很多家, 所以我也不班門弄斧了. 等我有足夠的經驗再來補充. 選擇網域註冊商, 我是參考了下面這支影片. 我原本是想選 Google Domains 的, 不過當我選擇國家的時候, 竟然沒有支援台灣!? (還在拓展中) 所以後來索性選擇了 Namecheap. 不過依然是個很棒著選擇! 😁 Craylor Made 講解得非常棒! 給個讚! 👍 ...

時間為2022的夏季, 在7月中旬, 我一位大學朋友 (@henrykuh) 邀請我一同參與他所主辦的 Game Jam, 在其活動的主題為驚喜 Surprise. 同時他也邀請我回 火柴共作坊 擔任程式區塊的負責人. 所以實質上, 這個 Game Jam 是用來讓我與其他在同個社群裡面的指導員 互相熟識, 以及交流的一個媒介. 這時候的我, 剛好完成了我上一份專案的開發計畫, 在沒有其他特別安排的 時期, 所以也沒有推辭, 就此決定參加很久沒參加的 Game Jam. ❓ 關於Game Jam 這個 Game Jam 的全名為 第五屆 DIY Game Jam: 驚喜 Surprise. 主辦單位為 自製遊戲公會. 時間是一個月, 比一般的 COVID-19 前的 Game Jam 的時間來的長上許多. 以往 Game Jam 時間都是 24 - 48 小時, 也就是一到兩天的時間 限制. 這是這個 Game Jam 相對比較特別的地方. 主題很明顯的, 名稱已經洩漏了, 是驚喜. 🔰 加入! 認識團隊 雖然以前我也曾短暫的待過在這 火柴共作坊 社群, 但對於其成員並不熟識. 所以這對我是個好時機 來建立一下人派. 並且可以順便訓練溝通/協作的能力. 團隊為5人成員, 1名企劃, 3名美術, 1名程序. 列表如下: ...

🔰 介紹 Eask的名字源自於Emacs Cask; 如果你已經有使 用過Cask的經驗, 那基本上你可以跳過這階段. 對於不了解或沒使用過的人, 在此我還是加減 介紹一下: (NOTE: 原則上這裡的Eask和Cask是可以互相替換的) Eask是個Emacs Lisp的套件管理工具, 有點類似於Node.js的npm, 但不全然是. 畢竟工具還不夠齊全, 而且Emacs生態也不適合npm那樣的模式. 所以簡單來說, Eask 可以是個劣化版的npm. 下面連結的 Why Cask? 有著更好的解釋 Why Cask? ❓ 那為什麼用要Eask, 而不是Cask? 以下是簡單的優劣展示表格: Behind technology Cross-Platform Emacs Version Size Cask Bash, Batch, and Python (Windows) ❌ Good on Linux and macOS, but it’s particularly bad on Windows 24.5+ 3,000+ lines makem.sh Shellscript ❌ Doesn’t work on Windows by default 26.1+ 1 file, 1200+ lines Eldev Bash, Batch, and Powershel, etc ✔ Good, but qutie slow on Windows 24.4+ 4,000+ lines Eask Node or Native Executables ✔ Good, and it can be compiled to native executables 26.1+ 3,000+ lines (這是我直接複製貼上的, 原文可以參考這.) ...

這是一篇又來記錄我生活上問到難題的文章. 不想接收負能量請離開! 進入正題, 這種情況已經不只一次了, 這是一個平時工作日的下午, 陰天沒有陽光, 濕氣非常沉重. “我升降桌大後天要來了, 要把舊的書桌撤掉!”. 這是已經預定好了行程. 我已經跟我 媽商量好, 要一起把原先的舊桌子給移除. 然後把新的升降桌移入. 這是一項大工程, 原先的桌子也不是便於攜帶的款式. 一開始也是透過組裝才能移進我的 房間. 問題來了, 我媽淡淡地說道: “那桌子我不幫忙, 自己搞定!” 這時我是錯愕的, 一開始講好一起弄, 然後又突然撒下一句我不弄. 我不懂她幫忙的定義. 我可以接受別人不幫忙, 但不能接受要幫又不幫, 這種模糊的答案. 不要那我就要自己 安排清理家具的公司. 那些都要時間, 突然不要, 直接把我打到牆上. 這都讓我的心情 起伏很大. 相處起來很累人. 如果不想幫忙, 請早點說, 不然就什麼都不要說. 😕 然後我不需要妳, 妳也不需要我, 我也長這麼大了. 那就不用互相往來, 各過各的或許是種不錯的生活方式? 那種要幫不幫 的生活態度, 對我這人好像太過困難了… 所以最後是怎樣? 妳想幫就幫到底, 不然就閉嘴? 🙄

最近迷上的網頁生產器, 所以我決定為我自己造一個網頁生產器, 何不? 其中較大的原因是因為我可以運行我的 網站到免費的 GitHub 網頁運行服務. 不過我上一個2018的專案 API-Reference-Template. 的核心是服務器取向, 而不是生產器取向… 😨 製作一個靜態網頁生產器並不是很困難, 我認為一個靜態網頁的價值來自原前端和整體的使用體驗. 然而, 我已經有一個令我自己滿意的前端網頁. 所以我就沿用我之前寫的專案, 並直接提取其中的前端部分. 然後直接把服務器取向的核心改成生產器取向! 🎉🎉🎉 我直接把這個工具重新取名為 SiraDoc, 這樣一來我也能夠給其他的網頁當作模板使用! 🥳 🔗 Link https://github.com/SiraDoc/SiraDoc

追蹤了這篇 My disappointing experience using Unity in a CI pipeline, 我也認為這是我目前遇到的最大問題. 個人版本(免費)的授權系統是部分衝突到CI/CD的概念的, 原因是, 我們還是得手動更新授權至 UNITY_LICENSE 這個 GitHub secret (環境變數)裡面. 也導致了 我們全部的CI/CD並不是全部自動化的流程, 非常麻煩! 至於Plus/Pro使用者則沒有影響, 因為他們分 別使用了不同的授權系統! 😖 我們直接切至問題點, 我們應該要怎麼做? 要怎麼讓這流程更順暢? 我的方法就是自動化整個授權的驗證過程! 長話短說, 我開發了一個 node 包 unity-license-activate, 原開發者是 Mizo Take. 這個包使用了 Puppeteer 來完成整個驗證步驟, 讓我可以使用JavaScript操控瀏覽器, 非常方便且正是我們需要的解決方法! 😁 下一步, 我們只剩下要更新我們的 secret 至 UNITY_LICENSE 這個環境變數就好! 這些任務非常簡單, 我 們只需要下列的 GitHub actions 即可辦到. read-file-action, by Julian Gruber actions-set-secret, by Habid Enrique Manzur Restrepo 我們可以使用 read-file-action 來讀取下載好的 .ulf 檔案, 然後使用這個檔案的值給 actions-set-secrets. 記得要設置 ACCESS_TOKEN 到你的GitHub secret裡面. 這是用來從你的 workflow 更新和製造 GitHub secret 的. ...