這個(gè)“偽需求”是最近才想到的。

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

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

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

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

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

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

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

發(fā)現(xiàn)了 Electron 的一個(gè)坑，只要在頁面里調(diào)用了 alert，頁面上的焦點(diǎn)就有問題，輸入框再也無法輸入內(nèi)容了。目前用 remote.dialog.* 替代。不知道有沒有正解？

后面的規(guī)劃:

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

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