部落格的自動釋出流程
從 2014 年年初寫部落格至今，四年多過去了。折騰了好些部落格系統，也折騰了好些編輯器，發現部落格的釋出流程長短，嚴重影響著部落格更新的頻率與質量。鑑於此，談談我目前部落格的釋出流程是怎樣的，歡迎討論。
環境資訊
node v9.8.0
ruby 2.5.0
在程式員的圈子裡，不僅用什麼語言要吵，用什麼框架要吵，用什麼編輯器要吵，用什麼部落格系統也要吵。眾說紛紜當中，如果能找到適合自己的，也不枉摸魚一天。
就拿寫部落格和 Markdown 編輯器（或者是筆記這類 App）來說，我用過以下幾款：
- Wordpress，OneThink，Jekyll，Octopress，Hexo 等
- EverNote，AlterNote，Mou，MacDown，MWeb，Quiver，SnippetsLab，Bear，SublimeText，Atom，VSCode，Typora 等
其實，每換一次這些工具也好，系統也好，成本都非常高。這些應用或多或少會有些不滿足需求，要不然就多個套用，互相彌補，要不然就砍掉自己的需求，適應某一個，當然，作為開發者，也可以選擇自己寫一個。
問題分析
從工具的過渡不難看出，部落格系統再從「富文字 + 動態網站」逐漸變為「Markdown + 靜態網站」。而編輯器也在從「零散 + App 自帶雲端儲存 + 編輯與預覽雙屏」到「純文字編輯 + 獨立儲存 + 單屏」轉變。目前我在用的幾款應用如下：
- Hexo
- Bear，VSCode，Typora
部落格不用多談，編輯器之所以有三種，是因為他們的用途不同，並不是一款無法滿足要求。
- Bear：主力摘抄
- VSCode：主力寫程式碼，偶爾檢視 Markdown 原格式
- Typora：主力 Markdown 編輯器
而備份，清一色的 Git。Bear 在出來的很長一段時間，我都不太喜歡。雖然介面讓人眼前一亮，但是備份只能是 Bear 自己的格式，而且它的 tag 是用#
，這和 Markdown 原有標籤衝突，匯出就會很醜，無法平滑遷移。但是它的同步、UI，以及 tag 的歸類方式，真的挺好用，所以用來做摘抄了。
當我習慣 Markdown，但仍在用 Wordpress 釋出的時候，發現 WP 對 Markdown 支援並不好，解析也會出現亂碼。所以，我當時釋出一篇部落格，流程很長：
- 用 Typora 完成部落格編寫
- 匯出為不帶樣式的 HTML
- 登入 Wordpress 後臺，複製貼上富文字
- 設定文章描述、分類、關鍵字等，點擊發布
經過在各種系統上的遷移後，發現部落格萬變不離其宗的幾個特點，這也是在遷移過程中遇到的問題：
- 富文字 or Markdown？（富文字需要依賴渲染，而 Markdown 可讀性更高）
- 動態 or 靜態？（動態對站內檢索支援更方便，如果實在需要，靜態也不是不能實現）
- 自己搭 or 三方部落格系統？（三方部落格…基本上資料就被綁架了，以後別想換）
- 部落格系統特定格式 or Markdown 原生格式？（如果用一種部落格就改一種格式，多痛苦）
需求確定
對於以上問題，我更傾向於用純 Markdown，並且就用原生的格式，當然，這其中還需要考慮資訊的融合。舉個 :chestnut:。
從 Wordpress 中，可以匯出的資訊是最完整的，出以下資訊外，還有釋出時間、分類、標籤、作者、固定連結等等。
<title>標題<title> <meta name="description" content="描述"> <meta name="keywords" content="關鍵字">
而 Hexo 支援的格式為：
title: 標題 categories: 分類 tags: 標籤 description: 描述 keywords: 關鍵字 date: 釋出時間 permalink: 固定連結 ---
原生 Markdown 的資訊最少：
# 標題 描述 <!--more-->
這就非常尷尬了，原生也太不友好了。那麼還要用原生的嗎？要！原生是對各個平臺支援最好的，以後要遷移起來，也很方便。哪怕最後選擇直接 push GitHub，顯示起來也沒問題。對此，可以對檔案目錄以及內容做些改動（比如當前這篇部落格）：
- 2018-09-05-design-a-singleton-block-callbak - 2018-09-07-efforts-will-not-be-wasted - 2018-10-15-publish-blog-automatically - index.md - publish-blog-automatically-1.png - publish-blog-automatically-2.png - other-source.key
這樣，日期與固定連結，就放到了資料夾名稱當中，而且文章當中，可以以相對路徑的形式引用圖片，基本上可以沉浸式的寫作，不用關心圖片的壓縮和上傳這些問題。
而其他的資訊，都放在了文章內部：
# 標題 <cate hidden>分類</cate> <tags hidden>標籤</tags> <keys hidden>關鍵字</keys> 描述。 <!--more-->
文章中，採用hidden
的方式，將附加資訊補充上去，並不影響檢視。而描述，則是在 more 標籤之前。講道理，more 之前本來也代表著表述。至此，原生的 Markdown 已經可以基本滿足日常書寫需求了。想要縮短髮布的流程，還需要一些指令碼的支援。
當然，大家寫部落格的時候，可能沒這麼複雜。我的之所以會比較麻煩，是因為最初是富文字，然後用七牛做的圖床（辣雞七牛，別用），私有 Repo，也不想用 GitHub Pages。除了釋出部落格以外，還會匯出一下其他資料。整體來看，對原始資料的處理很多，乾脆就自己寫個流程了。