码字,第一篇博客
个人学习笔记,学习的总结,肯定是采用文字的形式记录。是以纸笔墨砚的形式,还是以更现代的码字的形式?上学的时候还固执于前者,写写画画了好几个本子,每个上面都有些文字,却也都不成系统,而且基本上全是个人日记,记录心情,发泄情绪。工作后渐渐放弃了纸笔间的习惯,喜欢在键盘上码字,整理的内容也由日记全部过渡成了技术帖。一开始在印象笔记中零零散散保存,后来同时使用为知笔记并逐渐过渡了日记使用前者,技术帖使用后者。因为基本不再写日记,印象笔记也就变成了存储记忆的空间,还是不翻书的那种。
后来迷上 markdown,有半个月打算放弃为知笔记,后来发现 markdown 只能替代为知笔记默认编辑器的位置,而个人知识管理的体系、框架的建立与维护还是得靠为知笔记。但两者的结合并不完美,核心问题在于技术人员(指我自己)使用 GFM,而为知笔记的 markdown 解释器并不能完全支持 GFM,尤其是语法高亮方面(主要使用 shell、vimL、console 的支持),GFM 不支持 [TOC]
标签。
使用 MarkdownPad 2 编辑文字很爽,但保存的 .md
文档在查阅时并不直接。将其拷贝到为知笔记中在首部添加 [TOC]
标签后发布,阅读时直观,查找时无论是根据多层级文件级树形查找还是直接使用内建的搜索框直接搜索都是很方便的,不足之处在于:
- 一方面即便其支持 markdown 编辑,但并不友好,尤其是在使用 MarkdownPad 2 之后;
- 另一方面,使用 markdown 语法的前提下,无法实现在笔记中插入对另一篇笔记的引用(链接),这在整理系列笔记时尤其不能容忍。
想通过搭建个人的博客网站来解决上述矛盾:保留使用 MarkdownPad 2 编辑文字的习惯,放弃为知笔记,将文字直接发布到外网上就可以解决无法链接、笔记之间相互跳转的问题。此种情况下带来一点点不便,如果帖子中涉及个人隐私、公司商业机密(我笑),需要仔细筛选。
在搭建个人博客的摸索阶段,从为知笔记到博客网站的过渡阶段,依然会使用为知笔记,并不在时间轴上一刀切,一下子将为知笔记中的内容全部拷贝到网站中,然后清空、销户。
使用 GitHub Pages 和 Hexo 搭建个人博客,静态网页会在 Github 中保留有版本记录,但源 .md
文件的存储(乃至版本控制)尚需考虑:
对编辑的过程(版本控制)要求高,考虑在~\hexo\source
创建版本库;2020/12/25,折腾一遭还是选择此方案只要求结果(对版本控制要求低),有.md
文件的备份即可,考虑整体迁移到 Dropbox 中;因为hexo\blog\source\_posts
目录(.md
源)只能在 hexo 树形目录的固定节点,所以想将其备份到 dropbox 中,需要 trick / workaround,Windows下硬链接、软链接和快捷方式的区别图片库的问题,考虑使用图床;2020/12/25,PicGo+GitHub,谁用谁知道
对目录有需求,使用哪种实现呢?
[TOC]
不解析,使用支持目录的主题。
搭建博客
阮一峰老师说喜欢写 Blog 的人,会经历三个阶段:
第一阶段,刚接触 Blog,觉得很新鲜,试着选择一个免费空间来写。
第二阶段,发现免费空间限制太多,就自己购买域名和空间,搭建独立博客。
第三阶段,觉得独立博客的管理太麻烦,最好在保留控制权的前提下,让别人来管,自己只负责写文章。
在网上查找两篇教程,按部就班的操作就能得到结果。目前对于博客没有任何复杂的要求,对评论、对布局、主题都没有挑选的欲望。博客只是用来将自己的整理的笔记、学习总结放到互联网上存储,查阅时不用再打开为知笔记,不用打开 MarkdownPad2 实时生成,带来查阅时的便利即可。
对于评论,教程中多提及中文用户推荐“多说”,起步阶段没有需求,加上暂时不想再多花时间在这些“边缘”上,所以未开启评论功能。总的来说,博客还是处于自我查阅阶段。
参考 hexo 官方站点 的介绍,在 下载安装 Node.js 之后,执行以下命令即可完成搭建。
- 下载 Node.js 时,不使用代理时下载飞快;
- 安装 Node.js 的过程会自动配置 Path,安装完毕使用 powershell 输入
node
验证
1 | npm install hexo-cli -g |
拉取笔记仓库,并替换 source 目录:
- 进入
blog\
目录, - 执行
git clone git@github.com:tnie/notes.git
, - 然后
rm source -rf && mv notes source
- 安装 Next 主题
npm install hexo-theme-next
- 使用仓库中的配置文件,更新 blog 的配置项目。
注意:绑定本地 hexo 和个人的 Github Pages 后(修改全局配置文件),执行 hexo deploy
命令部署时需要先 npm install hexo-deployer-git -S
发布博客
整理完笔记之后,怎么发布到 github.io 上?在这里针对具体的步骤做一份备忘录,防止因为懒惰或其他原因较长时间不发博客,“回归”时还要再次花费时间查阅 Hexo + GitHub Pages 技术帖子。而且,技术相通,但每个人都会培养出属于自己的习惯,不想“回归”时再摸索。
在 Git Shell 中打开至 hexo 目录。
cd hexo
敲入
hexo new "filename"
命令。此命令会在 source/_posts 目录下创建 filename.md 文件- filename 建议使用英文,且不要存在空白字符。可以使用下划线 _ 连接两个单词。
- 用翻译工具查一查,起个好名字。
打开 source/_posts 目录,使用 MarkdownPad2 编辑文字,修改 title tags categories 属性,保存。
- 一般来说,都是将写好的笔记全文粘贴过来。记得删除源文件,在过一段时间之后维护多个相似文件是很痛苦的。
- title 使用中文;tags categories 原则上一律小写。
- tags 属性存在多个时,可以这样写
tags: [make,makefile]
,但注意每一个 tag 中不能有空格,比如tags: design pattern
这是错的
敲入
hexo generate
生成静态网页。敲入
hexo server
启动本地服务器,查看效果。敲入
hexo deploy
发布到互联网。迁移为知笔记中的内容。“迁移”顾名思义,要从为知笔记中删除。
参考链接
有讲述整体流程的,有着眼于模块的——描述主题的、强调分类和标签的、添加站内搜索、添加评论的……
- 其中,在 Debian8 上安装 Node.js 使用 其官方 的 Linux Binaries (.tar.xz) 版本。解压之后直接配置系统 PATH 路径即可。
tar xJvf node-v4.4.7-linux-x64.tar.xz
- 如果有更换域名的需求,可以参考 简明Github Pages与Hexo教程,而且作者是在 win7 环境下搭建的,同时文末给出了大量的参考资料。
主题
官方是有 辣么多的主题 让我们选,挑花了眼。
2017/4/13,使用新的主题 NexT。原因有二:
- Jacman 的搜索不能用。网上有很多其搭配 swiftype,但其他的第三方(比如谷歌)却怎么都调试不成功。
- Jacman 作者自己貌似都放弃了,作者自己的博客 使用 NexT 主题是其一,不再维护 Jacman 是关键。
使用 NexT 主题,碰到的问题 —— 其 404 页面的配置在使用 https 协议时有问题:
Hexo NexT 主题给出的腾讯 404 公益页面的教程仅适用于非 HTTPS 站点,对于严格限制混合内容的 HTTPS 站点来说,腾讯 404 公益页面使用的 JS 文件是无法引入的。
解决方案:关于 Hexo 上传 404 页面的问题
目录和标签
目录和标签有什么区别?关键词:一个目录,多个标签;树状结构,网状结构;
- 怎么给文章添加合适的标签呢?
- 在目录上尽可能的粗放,再用标签进行管理
- 使用树状目录尽量不要超过3级。
- 树状目录应该是和标签系统互补的;
- 标签起一种聚合作用,将相关性很强的东西联系到一起;分类目录则是相当于存放同类文章的容器,里面的文章虽属同类,相关性却可能不太强。
- 多参考大牛们的网站
不建议你“未雨绸缪”的打上标签。而是在有一定数量的笔记有大量相同性时,再打上标签,目录也是如此。
遵循这么一个原则:想一下读者看了这篇文章后,还会对哪些其他的文章感兴趣,然后这些文章就都添加上同一个标签。这样标签就可以实现目录交叉
其他
swiftype 试用结束后,只能付费。免费试用期到期后,官网登录之后无论点击哪里都是“Your Swiftype free trial has come to an end” 页面,猜测 swiftype 不再提供免费版本,佐证。需要寻找备案了……
使用本地搜索,安装插件(需要相应的配置项)。
1 | npm install hexo-generator-searchdb --save |
过程也是结果
在整理笔记的时候肯定会从网上查找资料,每个知识点肯定都会碰到一篇帖子让自己感慨“哇,总结得好好,娓娓道来,该讲的都讲到了,却也不多一句废话”,每每到此刻都觉得自己整理的笔记就是一坨垃圾,用词不当,表述不清晰,上下文转接不流畅,有的重点落下没讲,废话说太多……可这就是成长必经的过程,如果不是整理这个知识点,就不会一板一眼、较真地去查阅好多资料,线上的博客、线下的书,随手 google 来的终究只是编码过程中的 code demo,而非知识,只有当你读了很多篇笔记,看过了很多风景,才能有足够的理解,才能通过已经掌握的,通过对比,认识到某一篇是够精彩的。
如果因为总结的笔记太烂而气馁,放弃整理,那么就不会查阅足够的资料,就不会见到那篇“哇,精彩”的帖子!整理出来的笔记是结果,整理过程中见到的风景也是结果!
ps:在 2017/4/28 10:13:43 之前的文章大多是从 为知笔记 中手动迁移出来的。
- 源于为知笔记不支持账号销户,所以也就没有清空其中的内容,暂时保留一段时间还可以校正迁移过程中的失误;
- 但在文章全部迁移完毕之后也就不再使用为知笔记了,因为它 变更服务策略 太激进了。