我寫著寫著突然想到，日本輕小說市場曾經一段時間有新作品的書名一個比一個更長的趨勢。過去我總認為文字，特別是章節標題，當然是愈短愈好啊，我喜歡精簡有力的名字。不過現在，我覺得在屬於我自己的這個空間寫文章分享，偶爾刻意使用幾個、長度有夠誇張、誰會認真看完、我自己都傻眼的文章標題，其實也蠻有意思的。畢竟這裡是我的個人網站，誰管得著呢？或許更重要的是在精神層面，標題這概念本來就是自由的、本來就沒有任何一個人或組織有資格定義「合適」的標題長度限制，不是嗎？
哎呀！怎麼一開場就扯了這麼遠，這篇文章真正的主題與標題長度無關啦！
這篇文章我真正想分享的是，我「從零開始」架設此網站的個人心路歷程，或者也可以說是我從零開始架站的那幾天、心中飄出來的、結構邏輯可能很不嚴謹的自言自語的碎碎念吧——而我在這篇文章只是把那些碎碎念轉換成文字罷了。
我寫這篇文章的動機有兩大方面。
動機其一是，我真的就是想抒發與分享我的個人觀點和思路——不是因為我覺得這是正確、更好、更高級的諸如此類荒謬的念頭，而僅僅只是我想記錄與表達我自己、我想要碎碎念。
動機其二是，我猜這世界存在其他擁有類似想法的人（或許就是路過此處的讀者你）曾經也考慮想做類似的「從零開始」的事情、但仍然因為什麼而猶豫不決或裹足不前⋯⋯那個已經親身實踐後的我在此想跟你說「這當然完全可行！」請勇敢行動吧；又或者你早就這麼做了，那麼我們有機會能交流分享心得，也很好玩。
鐵定已經有非常多人分享推坑那些現成的、已經很方便的、上手很省時間的那幾款靜態網站生成器、那幾款內容管理系統、甚至是一些已經幫你搞定幾乎所有瑣事的完整的雲端服務。若使用那些方便的工具架設個人網站，你只要專注於內容寫作就好⋯⋯這方面的詳細資訊，在網路上已經多到，至少是不用再多我一人的唇舌去贅述了。於是我心想，那我乾脆來為「非主流」的架設網站路線——不依賴現成工具「從零開始」——寫些我個人的想法吧！希望非主流少數派也可以穩定地在社群慢慢地茁壯成長。
除了構思、彙整打算寫文章分享的題材、並開始動手寫內容這個必要步驟以外⋯⋯
除了決定網站（或自己）的名字，除了檢查網域名可註冊與否，除了草稿設計網站排版的視覺呈現，除了想像自己個人網站的標誌圖案，除了所有的這些關於資訊內容之包裝與呈現的事情以外⋯⋯
我認為，所有打算架設新網站的人，直接會面臨、必須做出決策、更務實的大問題是：「我已經有想分享的東西了，接下來在技術上要怎麼去做呢？」
我想，這個問題當然是沒有標準答案，同時完美滿足所有人的萬能解方不存在。
想回答「怎麼做？」這個問題，我得先釐清網站架設的需求者——也就是我自己——究竟透過這個網站想要做些什麼？我究竟想要從結果感受到什麼？我究竟想傳達、表達些什麼？我究竟想要怎麼和這個網站互動？我究竟想要怎麼營運、維護、更新這個網站呢？為了我的動機（或具體目的，如果有的話）我願意付出多少時間、體力與心力、甚至是經濟資源呢？以及最後，我本人能夠熟練使用掌握的相關工具技能有哪些？我對於各種工具是否有不同程度的偏好？
在選擇過多、方向不明確的時候，就先回歸初衷、回顧自己究竟在意什麼、捫心自問到底我想要什麼。我想表達蠻多、很個人的、關於網路與數位科技的主觀見解、價值判斷、信念。我希望當我想怎麼修改網站就能怎麼修改，我不想受到任何限制。我希望我有整個網站（盡可能）完整的控制權——不只是內容，而是這個網站上線運行的所有技術細節。像是這些都是我在意的。
而現在我已經知道：因為我想透過文字連結我和讀者你，我想開始架設這個、和我的核心價值主張保持一致的、滿足我心中那個設計原則的個人網站。為了這個目標，我需要從手邊的工具包組合出解決方案。
很肯定地，我會說「不」。
那些純雲端SaaS平台形式的CMS滿足了許多人的網站架設需求。通常不需要什麼技術專業知識就能掌握、有很多現成堪用的功能、往往可以使用自訂網域、有的甚至還免費⋯⋯雖然它們好處這麼多，但是我不能只是因為這區區的方便而捨棄我追求的高掌控性與自主權。各種CMS的SaaS平台對我而言，就是巨大的、僵化的、不透明的、黑箱的系統，很多眉眉角角不受我控制、完全不能隨心所欲修改，當它們出了問題時我很難靠自己就輕鬆解決。因此這個選項直接就被我本人排除、不在我的考慮範圍。
至於自行架設CMS這條路線呢？我認為也不恰當。大部分CMS開源專案的軟體架構明顯太複雜、並非我能完全掌握的。就算是少數幾個、我掌握度較高的CMS開源專案，我個人對於軟體系統架構的美學與品味（或說偏執）也不允許我就這樣使用它們。而我也完全不打算自己從零開始打造CMS系統——僅僅只為這只有我本人在維護管理的個人網站，這樣大費周章對我來說完全不合理。
題外話，有些CMS提供蠻方便易用的web app甚至是native mobile app讓使用者即使出門在外，只要有一隻連網的手機，隨時都可以撰寫、發表、編輯、更新文章。我很清楚我不需要這種方便性：我沒有那麼著急。我沒有什麼資訊是非得要在還沒回到電腦前就立刻發表到網站的。當我出門在外靈光閃現時，我完全可以把想法寫進隨身筆記本，我完全可以讓那些文字與概念慢慢沉澱，等到成熟了我再用電腦發布。
嗯，這問題也有點「複雜」⋯⋯
比起CMS我明顯更喜歡SSG的做法。我很喜歡它們核心精神的「靜態網站」概念——簡單、直接、有效。
可是，那些很流行、很多人用、很「方便」的SSG開源專案，無論是免費或付費，無論是已整合好的雲端託管平台、抑或是要自行部署搭建，我覺得還是太複雜了。
我是認真的。像是Astro、Docusaurus、Hexo、Hugo、Jekyll等，我千真萬確真心覺得它們所謂的「稍微調整幾個模板，改幾個設定檔案，之後用Markdown語法寫文章即可。每當文章寫好，只要跑一個短短的指令，就可以一鍵編譯、甚至把網站部署這件事情也自動化⋯⋯」那種解決方案本身的系統複雜性還是太高了！
不知道有沒有人發現我這段開頭說的「複雜」是雙關。
我覺得，或許這是web開發者社群中蔓延已久的大規模流行病吧——
根據我很業餘的觀察與研究，今天的這些SSG工具（儘管比CMS好點）普遍程式模組架構沒必要地複雜、第三方套件依賴過多、軟體堆疊有（對我而言）太多冗餘不必要的元件、維護團隊常常開發並更新我認為完全沒必要的功能。當我想親力親為審查原始碼時，我總是看得很累。我不只眼睛累、心也很累：將某一個發布版本的整包原始碼的第三方依賴dependency graph所有節點展開，常常有很多我還沒完全掌握的、我看了總是想罵「你這樣無意義的垃圾為何存在？你在這裡究竟是幹麻？」的名不見經傳的小元件。
『在網路搜尋，找到現成的軟體、或開發套件函式庫、甚至是有免費API的雲端服務。發現功能好像符合需求並且很多人都在用，就直接把它們整坨引入到自己的軟體架構。尚未深入研究、理解、掌握，就把它作為一個黑盒子獨立模組來使用』——這種實踐嚴重違反了我的反脆弱、依賴最少化、信任最少化等價值主張。
幾乎在所有情況下，很少有例外，一位設計師或工程師若在沒有搞清楚並且掌握代價的情況下就增加任何的外部依賴——無論依賴的是開發過程中的工具或框架、編譯過程會引入連結的函式庫、抑或是在開發的任何階段必須有網路連線才能使用（天哪這實在太慘了）的任何雲端API功能——他就犯下了最嚴重的系統設計與工程的原罪。
天底下所有資訊系統，遭遇的困難幾乎都是在於「複雜性」管理。沒有徹底掌握一個依賴所伴隨的代價、沒有真正搞清楚自己做了什麼取捨，貿然增加依賴，必定會增加系統複雜性，也必定是在給自己增加麻煩。如果非得要犯下「增加依賴」這個原罪，那麼就必須嚴格地審問自己、要求自己提出非常明確的理由，說明這個外部依賴是那「可以帶來遠遠超過負面代價的優點、有非常大好處」的必要之惡。
順帶一提，問題的關鍵在於是否理解並「掌握」該依賴，而與該依賴（軟體）是否有開放原始碼無關。僅僅是開源、僅僅是有原始碼，並非「可依賴」的充分條件。
（就算是開源軟體，常常也有很多包含資訊安全與隱私以及其它方面的問題，而且今天的軟體世界有很多可執行檔仍然尚未採用可溯源的deterministic & reproducible方法編譯⋯⋯在這縱錯複雜、層層交疊、複雜的軟體供應鏈中，有人偷偷安插了一段惡意的修改、放了一個安全漏洞，往往很難察覺。哎，怎麼又跑題了呢！這個方面的話題還是改天再聊吧。）
「怎麼做？」這問題在我的心中沉澱、發酵了很久。
我清楚知道，未來我在這個網站上做的分享，大部分將是以文字為主要形式的文章。並且我心中（至少目前）打算分享的那種文章、打算建立的那種知識庫頁面，就算要在站內互相連結，所需要的索引資料結構也不用多麼複雜。就算是很簡單的、線性的一些文字列表、搭配手動標記的超連結，也已經綽綽有餘。
對於我這樣簡單的需求來說，我真的不需要那麼多功能，我真的不需要使用那麼多複雜花俏的技術，我真的不需要依賴那麼多第三方軟體套件。
甚至，除了ＨＴＭＬ以外，我其實也完全不需要另外一個文件標記語言耶！
對，其實我根本不需要Markdown、AsciiDoc、Wikitext等文件標記語言⋯⋯畢竟，針對我的使用情境來看，使用HTML已經綽綽有餘。其實在很多情況下，我直接寫HTML甚至會更方便、更好控制、更好達成目的，省力又省心：
我再也不用花心神去跟「另外一套文件『標記語言』的某個根本沒有完備語言規格的『變種方言』的某款設計不良的『實作』」在一些很瞎的小細節上彆扭地搏鬥。更加重要地，我不需要再花力氣手工打造新的我滿意的文字處理工具，我也不需要委屈自己去使用任何一款原始碼我看了非常不順眼的「現成」開源工具。
因此我需要的，在形式上，仍然是一款SSG。只是，它必須是我自製的、以HTML為主的、樣板結構非常單純精簡、不用考慮其他架站者需求的、只需要考慮我自己一個人的、只需要為我提供極少自動化功能的、原始碼百分百出自於我手的、我完全了解它運作的所有細節的、遇到任何問題我都可以親自解決的、系統架構很單純的、只需要類Unix作業系統的、不依賴任何第三方軟體套件的、不依賴任何第三方雲端服務的、就算沒有網路也可以完美運作的⋯⋯這樣的可以自給自足獨立運作的一款「真正為我服務」的好用工具。
要用什麼程式語言實作這工具？使用Bash腳本搭配GNU coreutils那些類Unix系統都有的CLI指令（甚至限制自己只使用POSIX compatible subset指令集）做這種簡單純文字處理已經綽綽有餘啦！倘若未來這個網站真的想要做太多事情（機率應該蠻低）導致系統複雜性必須提升到一定程度：那時候我再把系統邏輯移植（或從零開始重寫）到更高階的程式語言也完全不遲，因為目前這個架構真的就是如此地簡單！
現在這個網站已經順利運行了。你在這個網站會看到的任何畫面，不只內容、還包含所有HTML原始碼都百分之百源自於我親自用鍵盤將每個字元逐字敲出來——要嘛是我純手工直接編輯撰寫的內容，要嘛就是我純手工編寫的程式在執行時產出的結果。稍微具體一點點地說：
/、/contact、/now等。
<article>元素裡」的文章：
<h1>標籤標記這個文章的標題，接著用HTML語法直接寫那篇文章的詳細內文。我最常用的HTML標籤包含<p>、<h2>、<ul>、<li>等。
<!doctype>、<html>、<head>、<meta>、<body>等重要標籤。
<header>、<nav>頁首導覽區塊。
src/做所有必要的處理，將整個網站所有靜態檔案輸出到一個out/目錄底下。
src/是否符合預期格式。
.html檔案。
out/是否符合預期格式。
out/目錄裡的所有內容，把它們變成一個獨立的檔案，並於檔案名稱標註發布時間戳記。這一個獨立的檔案就包含整個網站的全部，可以部署於任何web server軟體系統。
git push就觸發的CI/CD pipeline，我不需要串接一堆API，我不需要自動化的網站更新。我很享受這個不用急著發布更新、可以慢慢來的過程。
以上，這就是我目前能掌握的，對我個人而言，我認為系統架構最單純、幾乎所有軟體元件我都完全掌握、我想要怎麼修改就可以怎麼修改、對我而言幾乎沒有黑箱元件、非常透明的、免除盲目外部信任（信任最少化）、免除外部元件依賴（依賴最少化）的網站架設方式。
那些方便、看似簡單的東西（如常見的CMS和SSG方案）本質卻很複雜、一點也不簡單；反而那些麻煩、看似困難的東西（像是我主張的從零開始打造剛好滿足自己需求的網站）本質卻很單純、容易理解掌握。這樣的現象在生活上可能還有千千萬萬種例子。
寫到最後，我覺得我好像都在講廢話⋯⋯畢竟個人網站是自由的，想怎麼做當然完全看網站製作者的意見。而且我整篇文章提及的做法，也更不是什麼「值得抄答案或臨摹」的典範，畢竟我的主張就是：你真的可以從零開始打造屬於你的全部、無答案可抄、無具體之模範可複製、無絕對恆定之路徑可循。
很可能，你也想要架設自己的個人網站，但是你真的只是想要專注於分享內容而已：你沒有興趣仔細專研開源專案原始碼（包含那些第三方函式庫依賴），你對軟體工程技術、個人數位主權、自主暫時沒有沒興趣⋯⋯那麼，你直接採用現成那些免費的CRM平台快速上手、或直接拿現成的SSG架站，都很棒。你有「選擇屬於你的方式」進行創作的自由。
我不打算開放原始碼分享我的具體做法和那些shell scripts。一方面，我覺得那會剝奪想要親自動手的架站者的樂趣，更重要的另一方面是：
對於真的對原始碼有興趣、會去下載並研究原始碼的人，我猜或許你想要找回這些數位工具的主導權、你想要反脆弱⋯⋯面對這樣的讀者你，我認為你必須親手打造屬於你的工具，而不是參考臨摹。我認為你必須全程參與可能有點不舒服的那個「靠自己摸索、結果撞各種牆、自己獨立思考、探索找出合理的最簡的解方、親自解決自己的問題」的這整個過程。親自參與全程才能達到最高的系統掌控度與真正的自主。
雖然我沒開源用shell scripts做到這一切的極簡實作細節，若你有任何想法想聊聊或你有任何相關的問題，仍然歡迎你來信分享或討論。
話說回來，我還沒寫好我想弄的RSS/Atom feed XML樣板。但我有點累了，請允許我先把它們擱置在一邊。