這個“偽需求”是最近才想到的。

關于文章管理的想法，說來話長。我最初是在 CSDN 寫技術文章，就用網頁上的編輯器。后來在 CppBlog 寫，用上了 Windows Live Write，一般在 Word 里面寫好，再貼到 WLW 發布。再后來由于太忙了，一直停到現在。其中除了我懶，有兩個客觀原因，第一是中間好幾年不搞 C++，那么在 CppBlog 上寫非 C++ 的東西好像有點奇怪；第二是，服務端的東西真的沒法每天下班自己玩呀，每天下班提心吊膽地看短信報警，也沒哪個心情和時間再去重新開辟一個和白天工作內容迥異的學習場景維持下去。（佩服自己找借口的能力~）

前些年，Markdown 興起，GitHub Pages 興起，一眾靜態博客工具也蓬勃發展。Markdown 真的太適合用來寫技術博客了，唯一不足是圖片的處理。盡管如此，我還是花了很大的精力把以前所有的文章都轉成了 Markdown。然后曾經一度也玩上了 GitHub Pages，用 Huge 生成靜態博客。然而，博客的這東西我認為價值點和動力還是在于交流、碰撞，自己寫自己看，跟存本地沒啥區別——我的 GitHub Pages 幾乎沒人看……那時候也沒寫幾篇，大概是 2018 年末到 2019 年初的時間。

半年前，我想到了近年來第一個“偽需求”。我嫌 Hugo 這種形態操作太羅嗦：先寫 Markdown，再放到 source repo 的 post 里，提交一把；再生成靜態頁面，把 public 提交到 public repo。如果折騰模版啥的，就更復雜。我就想寫 Markdown，寫完提交一次 .md，能不能就看到呢？甚至干脆不提交，直接同步到服務端。這樣，就得做一套動態系統（相對于 Hogo 的靜態頁面）去做這件事，而生成被瀏覽的數據的邏輯理論上跟 Hugo 之類的沒本質區別。而一般個人博客這種文章量，根本不用納入性能上的考量，因此做成動態是完全可操作的。看了下市面上沒有此類的工具，于是就開搞了。我把它叫“NoteIsSite”，GitHub 地址 https://github.com/Streamlet/NoteIsSite，Demo 地址 https://note-is-site.streamlet.org/，然后把我所有的文章也用這個工具掛在主頁下的一個子分類，見 https://www.streamlet.org/note/。關于這個，以后再開一篇文章細說。

到這里為止，寫的過程代價很小了。但是剛才說了，博客這東西，對于我的動力很大一部分來自于評論、碰撞，還是需要發到公共平臺上去的好。最近看到一個去年離職的前同事的博客 https://gclxry.com/，我驚嘆于人家一直在堅持寫。我想我是不是也要撿起來了，還是回歸 CppBlog 吧。于是問題就來了。最近覺得最好用的 Markdown 編輯器是 typora，然后它沒法發博客；以前的 WLW 雖然還能用，但畢竟不基于 Markdown。然而 typora 不開源，沒法給他加一個“發布”功能了事。所以自己做做看？順便入一下 Electron 的坑，以及前端的坑。

花了這么大篇幅把需求來源說完了。至于為什么選 Electron 呢？就是為了快點搞定……

上周學習了下 Electron 的 demo 以及打包流程：https://github.com/StreamletStudy/ElectronHelloWorld

然后正式用這個 repo：https://github.com/Streamlet/MarkdownBlog 現在功能就兩個：編輯、發布。編輯不是所見即所得的，左邊 Markdown，右邊 HTML。發布要每次填 API 地址、賬號，沒做管理。整個流程通了，于是停下來寫了這篇文章，用剛寫的工具發布上來。

發現了 Electron 的一個坑，只要在頁面里調用了 alert，頁面上的焦點就有問題，輸入框再也無法輸入內容了。目前用 remote.dialog.* 替代。不知道有沒有正解？

后面的規劃:

1. 搞清楚前端的語言體系，然后選擇用原生 JS 還是它的衍生語言，把工程組織進一步完善
2. 搞清楚 UI 復雜度，看要不要選擇一個虛擬 DOM 方案
3. 擼功能，賬號管理等
4. 擼功能，做成所見即所得
5. 擼功能，支持圖片粘貼、上傳

再后面，先不規劃，做完了再看。當前版本 Release：https://github.com/Streamlet/MarkdownBlog/releases/tag/publish_to_metaweblog_api