├── PDF ├── 00_前言.pdf ├── 01_第一章.pdf ├── 02_第二章.pdf ├── 03_第三章.pdf ├── 04_第四章.pdf ├── 05_第五章.pdf ├── 06_第六章.pdf ├── A1_附录A.pdf ├── A2_附录B.pdf └── 作者简介.pdf ├── README.md ├── review └── PDF │ ├── 00_by_kongjian.pdf │ ├── 01_by_kongjian.pdf │ ├── 02_by_kongjian.pdf │ ├── 03_by_kongjian.pdf │ ├── 04_by_kongjian.pdf │ ├── 05_by_kongjian.pdf │ ├── 06_by_kongjian.pdf │ ├── A1_by_kongjian.pdf │ └── A2_by_kongjian.pdf └── src ├── 00_前言.md ├── 01_第一章.md ├── 02_第二章.md ├── 03_第三章.md ├── 04_第四章.md ├── 05_第五章.md ├── 06_第六章.md ├── A1_附录A.md ├── A2_附录B.md ├── img ├── 0-0.jpg ├── 1-1.jpg ├── 2-1.png ├── 2-10.png ├── 2-11.png ├── 2-12.png ├── 2-13.png ├── 2-14.png ├── 2-15.png ├── 2-16.png ├── 2-17.png ├── 2-18.png ├── 2-19.png ├── 2-2.png ├── 2-20.png ├── 2-3.png ├── 2-4.png ├── 2-5.png ├── 2-6.png ├── 2-7.png ├── 2-8.png ├── 2-9.png ├── 3-1.png ├── 3-10.png ├── 3-11.png ├── 3-12.png ├── 3-13.png ├── 3-14.png ├── 3-15.png ├── 3-16.png ├── 3-17.png ├── 3-18.png ├── 3-19.png ├── 3-2.png ├── 3-20.png ├── 3-21.png ├── 3-22.png ├── 3-23.png ├── 3-3.png ├── 3-4.png ├── 3-5.png ├── 3-6.png ├── 3-7.png ├── 3-8.png ├── 3-9.png ├── 4-1.png ├── 4-2.png ├── 4-3.png ├── 4-4.png ├── 4-5.png ├── 4-6.png ├── 5-1.png ├── 5-10.png ├── 5-11.jpg ├── 5-12.jpg ├── 5-13.jpg ├── 5-14.png ├── 5-15.png ├── 5-16.png ├── 5-17.png ├── 5-18.png ├── 5-19.png ├── 5-2.png ├── 5-20.png ├── 5-21.png ├── 5-22.png ├── 5-23.png ├── 5-24.png ├── 5-25.png ├── 5-26.png ├── 5-27.png ├── 5-28.png ├── 5-29.png ├── 5-3.png ├── 5-4.png ├── 5-6.png ├── 5-7.png ├── 5-9.png ├── 6-1.png ├── 6-10.png ├── 6-11.png ├── 6-12.png ├── 6-13.png ├── 6-14.png ├── 6-15.png ├── 6-16.png ├── 6-17.png ├── 6-18.png ├── 6-19.png ├── 6-2.png ├── 6-20.png ├── 6-21.png ├── 6-22.png ├── 6-23.png ├── 6-24.png ├── 6-25.png ├── 6-3.png ├── 6-4.png ├── 6-5.png ├── 6-6.png ├── 6-7.png ├── 6-8.png ├── 6-9.png ├── AB-1.png ├── AB-2.png ├── AB-3.png ├── AB-4.png └── lingjie_photo.jpg ├── makefile ├── styles └── styles.docx └── 作者简介.md /PDF/00_前言.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/00_前言.pdf -------------------------------------------------------------------------------- /PDF/01_第一章.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/01_第一章.pdf -------------------------------------------------------------------------------- /PDF/02_第二章.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/02_第二章.pdf -------------------------------------------------------------------------------- /PDF/03_第三章.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/03_第三章.pdf -------------------------------------------------------------------------------- /PDF/04_第四章.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/04_第四章.pdf -------------------------------------------------------------------------------- /PDF/05_第五章.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/05_第五章.pdf -------------------------------------------------------------------------------- /PDF/06_第六章.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/06_第六章.pdf -------------------------------------------------------------------------------- /PDF/A1_附录A.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/A1_附录A.pdf -------------------------------------------------------------------------------- /PDF/A2_附录B.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/A2_附录B.pdf -------------------------------------------------------------------------------- /PDF/作者简介.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/PDF/作者简介.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 《Markdown 写作指南》项目简介 2 | 3 | ![《Markdown 写作指南》封面图](src/img/0-0.jpg) 4 | 5 | ## 为何而写 6 | 7 | 我希望通过这本小书来介绍一下个人对 Markdown 这种写作方式的看法和使用经验，以此来抛砖引玉，引起大家对 Markdown 更多的关注，进而将软件开源的精神推广至写作领域。毕竟，文字作品才是我们人类开发时间最长，数量最多的一种“软件”。 8 | 9 | 具体说来，写这本书的最初念头源自于一次在 Facebook 上的抱怨。由于我自己是一个 Markdown 的重度使用者，在日常做笔记、写文章、创作或翻译书稿时，经常需要搜寻各种使用 Markdown 写作的解决方案。而与此同时，市面上的各种博客、论坛、云端笔记服务也都纷纷加入了对 Markdown 的支持，这说明使用这门标志语言的用户并不在少数，但我却惊讶地发现自己市场上竟然找不到一本介绍 Markdown 的专著。于是就在 Facebook 上分享了下面这个想法： 10 | 11 | > 我是觉得使用 Markdown 写作可以延伸出很多东西啊，写论文涉及 LaTeX、Mermaid 等，制作电子书涉及 gitbook ，建构博客涉及 Hexo，居然没人写本书介绍这些议题！可惜了…… 12 | 13 | 很自然地，这条想法分享的下面就有朋友留言建议我“不如你来写吧”。虽然当时我只是在表达自己需要这样一本书，期待相关出版方能请某位专业人士来写一本，但与朋友的讨论让我重新审视了自己所分享的这个想法。这个想法实际上说明了我为什么喜欢用 Markdown 来写作的原因： 14 | 15 | 1. Markdown 是开源软件，符合开放、自由、专注于任务，便于同行协作的工作哲学。 16 | 2. Markdown 符合“数据与呈现样式、用户界面分离”程序设计思维。 17 | 3. Markdown 的纯文本特性使我们可以像管理程序员源代码一样管理自己的文字作品。 18 | 19 | 总结一下，就是 Markdown 可以让人们“像写程序一样写作”，这让我意识到写这样一本书的意义已经不仅仅是介绍一门轻量级的标记语言，而是在推广一种强调自由、开放、合作的价值观和方法论了。而这种价值观和方法论原本就是我多年以来一直在坚持的，如今既然看到没有人写一本关于 Markdown 的专著，不如就自己来为它的推广做点事吧。 20 | 21 | ## 写了什么 22 | 23 | 在这本书中，我以一篇本科毕业论文的写作过程为导引，介绍了 Markdown 在完成论文的规划、撰写、修改、发布这些不同任务阶段中的应用。全书被分成了六个章节和两个附录： 24 | 25 | - **第 1 章 使用 Markdown 写作**：在这一章中，我们介绍了 Markdown 是什么、它有什么优势和劣势以及它所倡导的写作理念。需要说明的是，这一章的内容是为对 Markdown 一无所知的朋友准备的。如果读者自认为已经对 Markdown 有所了解，或者不想纠缠于技术概念，想快点进入“如何使用 Markdown ”的议题，也可以选择跳过这一章。 26 | 27 | - **第 2 章 写作的前期准备**：在这一章中，我们首先介绍了几款值得一试的 Markdown 编辑器。然后，我们以论文的前期规划为导引，带大家学习了使用 Markdown 的标记来拟定论文大纲、表列论文的参考资料、并通过设定待办事项来安排写作的进度。 28 | 29 | - **第 3 章 撰写一篇论文**：在这一章中，我们继续以论文的正式写作过程为导引，逐步深入地介绍了其余主要的 Markdown 标记，以及它们的具体使用。这其中既会包含用来表示段落、强调、引用、代码这些基本元素的原生 Markdown 标记，也会涉及到与表格、图形相关的扩展标记，以及它们的基本用法。 30 | 31 | - **第 4 章 谈谈数学问题**：在这一章中，我们首先介绍了如何在 Markdown 文档中插入 LaTeX 标记，以呈现数学公式。然后，我们会具体介绍如何用 LaTeX 标记来描述基本四则运算、二项式方程、矩阵运算以及集合运算等数学问题。 32 | 33 | - **第 5 章 作品的审阅与维护**：在这一章中，我们围绕着如何”像维护程序项目一样维护 Markdown 项目“的议题展开了一系列的讨论。首先，我们介绍了一款可以让人们更专注于文字内容审阅和修改的 Markdown 编辑器。然后，考虑到 Markdown 的应用目前尚不够普及的现实问题，为了让更多的人参与作品的审阅，我们为大家介绍了一款专用于转换标记语言格式的工具。最后，为了从时间维度上对项目的修改进行管理，我们也对如何用 Git 版本控制系统对 Markdown 项目进行管理和维护，做了一个基本介绍。 34 | 35 | - **第 6 章 Markdown的其他应用**：在这一章中，我们为大家介绍了如何用 Markdown 制作演示文稿、线上电子书以及撰写博客。集中展示了 Markdown 作为一种写作方式的广泛适用性。 36 | 37 | - **附录 A Makefile 简易教程**：在这篇附录中，我们为大家介绍了 Makefile 文件的基本写法，以便搭配第 5 章中介绍的格式转换工具批量地将 Markdown 文档转换成其他格式的文档。 38 | 39 | - **附录 B 了解一下 Node.js**：考虑到本书介绍的 gitbook 和 Hexo 都要基于 Node.js 运行环境来部署，而这个运行环境如今已经形成了如此庞大的软件生态系统，我认为有必要用一篇附录专门介绍一下 Node.js 以及它的安装和配置。 40 | 41 | ## 项目结构 42 | 43 | 如前所述，本项目是一个基于 Markdown 实现的开源书籍，其目录结构如下： 44 | 45 | - `src`目录：用于存储书稿的 Markdown 源码。 46 | - `PDF`目录：用于存储书稿源码输出的 PDF 文档。 47 | - `review`目录：用于存储审阅者对书稿提出的批注文档。 48 | 49 | ## 审阅规则 50 | 51 | 本书审阅者需先在 GitHub 上 fork 本项目，并修改`src`目录中的Markdown源码文件，然后向本项目发送 Pull 请求以提交你的修改。或者也可以使用 Microsoft Word 的审阅工具对`PDF`目录中的书稿进行审阅，并将结果保存在`review`目录中，再发送 Pull 请求。在后一种方式中，你保存的文件名应为`[源文件名]_by_[yourID].pdf`，具体可参考该目录下已有的范例。 52 | 53 | ## 版权声明 54 | 55 | 此书的版权由作者本人与人民邮电出版社技术分社共同所有，本项目的用户可阅读、讨论本项目的所有内容。但不可转载并用于商业用处。如果发现侵权行为，人民邮电出版社将视具体情况追究法律责任。另外，希望各位看官体谅创作不易，如觉得本作品值得一读，还请前往人民邮电出版社异步社区[个人专栏销售处](https://www.epubit.com/columnDetails?id=CL6c695f34d7aec)，支付一些费用，鼓励一下原创。 56 | -------------------------------------------------------------------------------- /review/PDF/00_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/00_by_kongjian.pdf -------------------------------------------------------------------------------- /review/PDF/01_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/01_by_kongjian.pdf -------------------------------------------------------------------------------- /review/PDF/02_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/02_by_kongjian.pdf -------------------------------------------------------------------------------- /review/PDF/03_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/03_by_kongjian.pdf -------------------------------------------------------------------------------- /review/PDF/04_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/04_by_kongjian.pdf -------------------------------------------------------------------------------- /review/PDF/05_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/05_by_kongjian.pdf -------------------------------------------------------------------------------- /review/PDF/06_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/06_by_kongjian.pdf -------------------------------------------------------------------------------- /review/PDF/A1_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/A1_by_kongjian.pdf -------------------------------------------------------------------------------- /review/PDF/A2_by_kongjian.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/owlman/markdown_guide/3620ca94a05f7b4f1cf2d2ae940ffa33206aed6c/review/PDF/A2_by_kongjian.pdf -------------------------------------------------------------------------------- /src/00_前言.md: -------------------------------------------------------------------------------- 1 | # 第0章 前言 2 | 3 | 经过了整整三个月的努力，我终于将这本已在心中酝酿了很久的小书写完了。写书真是一种很奇特的经历，整个过程既让人觉得很纠结，很惶恐，也令人感到很兴奋，很快乐。我个人认为，在如今的互联网上，人们只要能善用搜索引擎，基本上就可以找到自己想要了解的任何信息了。因而在这个时代，写书的目的已不应该只是单纯地普及知识了，它应该更多地表现作者自己的一些观点和经验。因为只有这种个性化的东西才是任何人工智能的产物所无法替代的，这些东西当然未必正确，但它能刺激思考，引发讨论，使人沉淀，而这些恰恰是如今互联网上所缺少的。所以，我希望通过这本小书来介绍一下个人对Markdown这种写作方式的看法和使用经验，以此来抛砖引玉，引起大家对Markdown更多的关注，进而将软件开源的精神推广至写作领域。毕竟，文字作品才是我们人类开发时间最长，数量最多的一种“软件”。 4 | 5 | ## 为什么要写这本书 6 | 7 | 写这本书的最初念头源自于一次在Facebook上的抱怨。由于我自己是一个Markdown的重度使用者，在日常做笔记、写文章、创作或翻译书籍时，经常需要搜寻各种使用Markdown写作的解决方案。而与此同时，市面上的各种博客、论坛、云端笔记服务也都纷纷加入了对Markdown的支持，这说明使用这门标志语言的用户并不在少数，但我却惊讶地发现自己市场上竟然找不到一本介绍Markdown的专著。于是就在Facebook上分享了下面这个想法： 8 | 9 | > 我是觉得使用Markdown写作可以延伸出很多东西啊，写论文涉及LaTeX、Mermaid等，制作电子书涉及gitbook ，建构博客涉及Hexo，居然没人写本书介绍这些议题！可惜了…… 10 | 11 | 很自然地，这条想法分享的下面就有朋友留言建议我“不如你来写吧”。虽然当时我只是在表达自己需要这样一本书，期待相关出版方能请某位专业人士来写一本，但与朋友的讨论让我重新审视了自己所分享的这个想法。这个想法实际上说明了我为什么喜欢用Markdown来写作的原因： 12 | 13 | - 第一，Markdown是开源软件，符合开放、自由、专注于任务，便于同行协作的工作哲学。 14 | - 第二，Markdown符合“数据与呈现样式、用户界面分离”程序设计思维。 15 | - 第三，Markdown的纯文本特性使我们可以像管理程序员源代码一样管理自己的文字作品。 16 | 17 | 总结一下，就是Markdown可以让人们“像写程序一样写作”，这让我意识到写这样一本书的意义已经不仅仅是介绍一门轻量级的标记语言，而是在推广一种强调自由、开放、合作的价值观和方法论了。而这种价值观和方法论原本就是我多年以来一直在坚持的，如今既然看到没有人写一本关于Markdown的专著，不如就自己来为它的推广做点事吧。 18 | 19 | ## 这本书写了些什么 20 | 21 | 在这本书中，我以一篇本科毕业论文的写作过程为导引，介绍了Markdown在完成论文的规划、撰写、修改、发布这些不同任务阶段中的应用。全书被分成了六个章节和两个附录： 22 | 23 | - **第1章 使用Markdown写作**：在这一章中，我们介绍了Markdown是什么、它有什么优势和劣势以及它所倡导的写作理念。需要说明的是，这一章的内容是为对Markdown一无所知的朋友准备的。如果读者自认为已经对Markdown有所了解，或者不想纠缠于技术概念，想快点进入“如何使用Markdown”的议题，也可以选择跳过这一章。 24 | 25 | - **第2章 写作的前期准备**：在这一章中，我们首先介绍了几款值得一试的Markdown编辑器。然后，我们以论文的前期规划为导引，带大家学习了使用Markdown的标记来拟定论文大纲、表列论文的参考资料、并通过设定待办事项来安排写作的进度。 26 | 27 | - **第3章 撰写一篇论文**：在这一章中，我们继续以论文的正式写作过程为导引，逐步深入地介绍了其余主要的Markdown标记，以及它们的具体使用。这其中既会包含用来表示段落、强调、引用、代码这些基本元素的原生Markdown标记，也会涉及到与表格、图形相关的扩展标记，以及它们的基本用法。 28 | 29 | - **第4章 谈谈数学问题**：在这一章中，我们首先介绍了如何在Markdown文档中插入$\LaTeX$标记，以呈现数学公式。然后，我们会具体介绍如何用$\LaTeX$标记来描述基本四则运算、二项式方程、矩阵运算以及集合运算等数学问题。 30 | 31 | - **第5章 作品的审阅与维护**：在这一章中，我们围绕着如何”像维护程序项目一样维护Markdown项目“的议题展开了一系列的讨论。首先，我们介绍了一款可以让人们更专注于文字内容审阅和修改的Markdown编辑器。然后，考虑到Markdown的应用目前尚不够普及的现实问题，为了让更多的人参与作品的审阅，我们为大家介绍了一款专用于转换标记语言格式的工具。最后，为了从时间维度上对项目的修改进行管理，我们也对如何用git版本控制系统对Markdown项目进行管理和维护，做了一个基本介绍。 32 | 33 | - **第6章 Markdown的其他应用**：在这一章中，我们为大家介绍了如何用Markdown制作演示文稿、线上电子书以及撰写博客。集中展示了Markdown作为一种写作方式的广泛适用性。 34 | 35 | - **附录A Makefile简易教程**：在这篇附录中，我们为大家介绍了Makefile文件的基本写法，以便搭配第5章中介绍的格式转换工具批量地将Markdown文档转换成其他格式的文档。 36 | 37 | - **附录B 了解一下Node.js**：考虑到本书介绍的gitbook和Hexo都要基于Node.js运行环境来部署，而这个运行环境如今已经形成了如此庞大的软件生态系统，我认为有必要用一篇附录专门介绍一下Node.js以及它的安装和配置。 38 | 39 | ## 开源运动简介 40 | 41 | 在读者正式开始阅读本书之前，我还希望对开源运动做一个简单的介绍。从本质上来说，软件的开源事实上是针对软件工程问题提出的一个解决方案。而说起软件工程这档事，我相信计算机和软件工程专业的学生应该都不陌生，我们早年间都背下来过一些流水线式的项目开发流程。首先是在项目定义阶段要做可行性分析、需求分析这些事，再来进入到开发阶段要做概要设计、详细设计、设计实现等步骤，最后是维护阶段的运行与维护。仿佛软件开发就像《摩登时代》里的工厂流水线，分工明确、井然有序。目的是让程序员成为流水线上的工人，使他们成为生产机器中的一个螺丝钉，无需创意、无需个性，只要够熟练就行。很多大型企业的开发项目也确实是按照这个路数走的，很多程序员被戏称“码农”也正是这个原因。 42 | 43 | 但是，等我工作了若干年之后再来看这套工程管理模型，感觉这基本上就是个“计划经济”。首先，绝大部分软件在开发初期根本不会有那么多人参与，通常是两三个人要做所有的事情。分那么多阶段，那么多工序是没有意义的。再来，就算是有了一定规模的公司，他们会让很多人参与一个项目，往往都是为了维护已有的软件，程序员的主要任务是维护该软件的版本，并在此基础上开发新的版本，在这种情况下，他们其实已经有了现成的开发框架，这些人只需要根据特定的需求将该框架填充成具体的专用软件即可。对于原框架来说，这更像是增加了一个特性分支。例如说，JetBrain团队开发了一款名为IntelliJ IDEA的通用IDE，而Android Studio则又是专用于Android开发的IDE，它就是基于IntelliJ IDEA开发出来的。我们可以将它视为IntelliJ IDEA项目的一个分支。这更像是某种意义上的维护工作，它的可行性，需求是一目了然的，也不需要概要设计，只需要按照其原有的插件体系把功能实现即可。然后，bug修复才是这个项目的主要工作。所以，如何让那么多人一块有效地，有序地发现bug、报告bug、解决bug成为了主要问题。 44 | 45 | 上世纪的七十年代和八十年代爆发了两次所谓的软件危机[^1]，那时候的许多软件项目都出现了预算超支、发布时间严重拖延、质量管理缺失等问题。大量的项目因此而失败，问题很严重，以致于北约这样的组织都要专门开会来讨论这个问题。但这些高高在上的人物讨论出来的东西就是我们上面所说的软件工程理论。按照《人月神话》作者佛瑞德·布鲁克斯（Frederick P. Brooks）的说法，这需要大量的银弹、人员来支撑，只有大型企业，科研机构才能做到。当然对于这些机构来说，这套理论确实能解决一些问题。尤其在互联网时代来临之前，这似乎也是我们唯一的选择。 46 | 47 | 但大型机构都存在官僚主义的问题，组织繁杂、沟通成本高昂、开发效率低下，随着时间的推移它们往往都会离人们的实际需求越来越远，就像是那些中世纪大教堂，高高在上、脱离现实地定期发布信息，内容庞杂而滞后，对于其周边的、下游的开发者和中小软件开发是毫无帮助。于是Linux之父林纳斯·托瓦兹（Linus Torvalds）在独自开发Linux内核的过程中走出了一条新的道路：开放源码、社区协作。简单来说，就是由软件项目的创始人开发出一个不成熟的初始版本，然后将其丢到一个开发者社区中，让其在开发者自发性的修改和分享中自然生长。最后，项目创始人会根据其生长情况将自己认可的部分纳入到项目的主分支中。这种乱中有序的组织形式让Linux项目获得了巨大的成功，给软件开发的工程管理提供了一种新的**实践经验**。 48 | 49 | 无独有偶，上世纪九十年代末期，网景公司[^2]在与微软公司的浏览器大战中败下阵来，面临着公司的生存危机。他们决定试试开源的方式。埃里克·雷蒙（Eric Raymond）就是网景公司当时的策略顾问，他在帮助网景公司的过程中根据自己的新的写出了他那本闻名天下的代表作：《大教堂与集市》。这本书为开源运动奠定了**理论基础**，它系统阐述了互联网条件下的协作模式，同行审评的优势，回答了《人月神话》中提出的银弹问题，人员管理成本问题。如今，微软、苹果这些曾经的大教堂都纷纷加入了开源领域。开源作为软件工程的另一种组织形式已经毋庸置疑。 50 | 51 | 最后需要提醒的是，开源运动和理查德·斯托曼（Richard Stallman）领导的自由软件运动[^3]不是一回事。开源运动更多的是一种软件工程的管理方式，虽然也强调开放源码、免费分享的自由精神，但并没有太强烈的道德要求。而自由软件运动则更像是一种宗教性的意识形态运动，他们对于“确保用户使用软件的自由”有着一种近乎苛刻的道德要求，譬如，他们会要求所有基于自由软件开发的产品都不仅要开放源码，还必须要允许用户修改该产品软件的源码，或变更其硬件的使用方式，让用户真正地享有“自由”，这难免让人觉得有一些乌托邦式的理想主义。而在我个人看来，如此激烈的主张在客观上反而会给源代码的分享带来了不少的阻力。 52 | 53 | ## 致谢与勘误 54 | 55 | 这本书能够成型，离不开很多人的鼓励和帮助。如果没有卷积传媒的CEO高博先生的鼓励，我不会下决心写这本书。另外，我的好朋友，在香港的朱磊也对本书的初稿进行了认真的审阅，提供了不少宝贵的建议。最后感谢人民邮电出版社，愿意出版这本题材较为冷门的小书，希望不会辜负了他们信任。还有，我的女友蔓儿，谢谢你甜蜜的爱，它是我在这个世界上奋斗的动力。 56 | 57 | 当然，无论如何，这本书中都会存在一些不够周全，表达不清甚至错误的地方。如果读者有任何意见，我都希望你致信`lingjiexyz@hotmail.com`，或者在异步社区中本书的勘误页面中提出，以帮助我们在本书的后续修订中进一步完善它。 58 | 59 | 60 | 61 | [^1]:注释：请参考https://zh.wikipedia.org/wiki/软件危机 62 | [^2]:注释：请参考https://zh.wikipedia.org/wiki/网景 63 | [^3]:注释：请参考https://zh.wikipedia.org/wiki/自由软件 64 | -------------------------------------------------------------------------------- /src/01_第一章.md: -------------------------------------------------------------------------------- 1 | # 第1章 使用Markdown写作 2 | 3 | ## 本章提要 4 | 5 | 在这一章中，我们将会对Markdown做一个概念性的简单介绍。具体来说，我们会讨论Markdown是什么、它有什么优势和劣势以及它所倡导的写作理念。需要说明的是，本章是为对Markdown一无所知的朋友准备的。如果你自认为已经对Markdown有所了解，或者不想纠缠于技术概念，想快点进入“如何使用Markdown”的议题，也可以选择跳过本章内容，直接从下一章开始阅读。但是，如果你想更完整地了解我对这门技术的观点，还请你稍微花点耐心读一下这一章的内容，毕竟正如一千个人的心中有一千个哈莫雷特，对于同一门技术，每个人的理解也都略有不同。 6 | 7 | ## 1.1 Markdown是什么？ 8 | 9 | Markdown是约翰·格鲁伯（John Gruber）[^1]与亚伦·斯沃茨（Aaron Swartz）[^2]于2004年共同开发的一门轻量级标记语言（Lightweight Markup Language，简称LML）。也就是说：首先，Markdown是一种标记语言，可以用任意的文本编辑器来进行输入和修改，并以纯文本的格式保存在计算机中。其次，这是一种“轻量级”的语言，这意味着相对于`RTF`、`HTML`、`TeX`这些格式更丰富的标记语言来说，Markdown的格式更为简单易用，也更接近于自然语言。这让它更适合用来写作和分享。格鲁伯们开发这门语言的目的就是为了鼓励人们先使用一种易读易用的纯文本格式来编辑并存储文档，然后再根据实际需要将文档转换成`(X)HTML`、`docx`和`PDF`等格式。Markdown在设计上非常重视可读性。换句话说，Markdown的设计目标之一是要让人类能直接从字面上对其进行阅读，不需要太多精力学习一些格式化指令标记（譬如`RTF`与`HTML`）。 10 | 11 | ![markdown图表](img/1-1.jpg) 12 | 13 | 事实上，Markdown最初的实现只不过是格鲁伯参考现行电子邮件的标记格式和一些早期的标记语言（譬如Setext、Texile等），编写出的一个可将用Markdown语法编写的文档转换成有效的、结构良好的`(X)HTML`格式的`Perl`脚本程序：`Markdown.pl`。该脚本既可以单独使用，也可以被用作`Blosxom`这类博客系统的插件，或者`BBEdit`这类编辑器的文本过滤器。但随着时间的推移，Markdown已经被许多人用`Perl`或其他编程语言重新实现，市面上陆续出现了许多不同版本的Markdown实现。同时，人们也在Markdown基本语法的基础上开发出了许多额外的功能，例如表格、脚注、列表以及代码块等。这其中有些功能已经偏离了这门语言最初的实现，带来了语法规范上的含糊不清，这些问题促使Markdown的标准化问题被提上了议程。当然，值得一提的是，作为Markdown的创立者，格鲁伯并不赞成完全标准化，他认为：“不同的网站（和人们）有不同的需求。没有一种语法可以让所有人满意。” 14 | 15 | 以我写这本书时[^3]所查到的资料，Markdown标准化的最新进展是，2016年3月发布的*RFC 7763*和*RFC 7764*这两份文件。其中，*RFC 7763*文件从原始变体引入了MIME类型`text/markdown`。而*RFC 7764*文件则讨论并注册了`MultiMarkdown`、`GitHub Flavored Markdown(GFM)`、`Pandoc`、`CommonMark`和`Markdown`等不同的实现版本。 16 | 17 | ## 1.2 Markdown的优势与劣势 18 | 19 | 如今，Markdown的使用者早已不只是写程序文档的程序员，它在国际上已经受到越来越多编辑和写作者的青睐。用Markdown来写作和编辑文章在网络时代有着超乎想象的优势。下面，我们就来具体讨论一下这些优势： 20 | 21 | - **语法简单易读**：由于Markdown的语法简洁明了，且在写过程中基本不需要键盘以外的其他设备操作，让人们可以更专注于写作本身，这将带来很大的效率提升。关于这一点，我稍后会在下一节介绍Markdown的基本写作理念时做更进一步的讨论。 22 | 23 | - **文本格式存取**：在我个人看来，*能以纯文本格式来处理并存储文档*是Markdown最大的优势。我们后续介绍的大部分优势都与这一特性有着或多或少的联系。简而言之，Markdown的纯文本特性给它带来了极强大的兼容性，我们可以用任何文本编辑器来处理Markdown文档，不用担心不同编辑软件之间的横向兼容问题（譬如微软的Word和苹果的Pages之间的兼容），以及这些软件自身升级所带来的纵向兼容问题（譬如旧版Word就打不开新版Word的默认格式`docx`）。 24 | 25 | 另外，如果你使用的操作系统是Linux/Unix或MacOS的话，还有大量针对文本的系统工具可以用（譬如diff、sed等），这些工具都会给文档的存取、搜索与传输带来极大的方便。 26 | 27 | - **便于格式转换**：由于Markdown是以纯文本的形式存储在计算机中的，这也赋予了它很强的可编程性，人们可以轻松地为其编写各种格式转换工具。经过了许多人的共同努力，到目前为止，我们已经可以轻松地将其转换成`(X)HTML`、`PDF`、`epub`、`mobi`、`docx`等格式了。关于这方面的内容，我们将会在第四章中详细讨论。 28 | 29 | - **利于网络协作**：有过远程办公经验的人都知道，我们在网络协作过程中首先会遇到的通常是平台相关性问题，譬如你用的是Windows上的Word。我用的是MacOS上的Pages，他用的是Ubuntu Linux上的WPS，经常会彼此打不开对方的文件，或者打开了对方的文件，却由于各自操作系统上支持的中英文字体不同而导致排版惨不忍睹，甚至完全乱码。这一切都会由于上面提到的Markdown的纯文本特性而得到解决。 30 | 31 | 再来就是网络协作中会遇到的另一个问题，那就是协作成员可能会同时对同一份文件做出不同的修改，这就需要用到版本控制。市面上似乎所有的版本控制系统，无论是CVS、SVN还是Git，优先支持的都是纯文本格式的文档，我们完全可以像管理程序项目一样对Markdown文档进行各种版本操作。关于这方面的内容，我们将会在第五章中进行更为详细的讨论。 32 | 33 | 除此之外，由于Markdown本身就是个开源项目，任何人都可以对其实现进行修改、重构和扩展，所以有人用它写程序项目的文档，有人用它构建博客平台（譬如Hexo等），有人用它制作电子书（譬如gitbook等）。总而言之，在使用了Markdown之后，我们可以将程序设计领域中的开源思想完全应用于写作领域，实现在互联网范围内的同行审阅、分享与讨论，以改善作品质量、促进整体进步。 34 | 35 | 当然，任何人、事、物都会在展现其优势的同时呈现出一些劣势。而且优势和劣势通常都来自于同一个特性，是优势还是劣势完全看这个特性所发挥的面向。下面我们就来看看Markdown具有那些劣势，或者说它不适合被用来做哪些事： 36 | 37 | - **国内使用尚不普及**：虽然这些年Markdown在国内受到了越来越多的重视，但在一些关键领域，比如大部分出版社还是会要求你提供`Word`版本的稿件，哪怕是一些出版计算机书籍的出版社也是如此，这就说明这种写作方式的普及远未达到理想的程度。 38 | 39 | - **不适合用来做排版**：Markdown的语法设计是为了让人们专注于写作内容，所以并不适合用来做复杂的排版，比如各种印刷字体的设置、复杂的表格、图片的文字环绕等。这些需要我们去学习一些专用于排版的工具，譬如LaTeX，用它们搭配Markdown使用。 40 | 41 | - **周边工具学习成本较高**：Markdown的周边工具非常多，譬如用于格式转换的pandoc、用于排版设计的LaTeX、用于发布`HTML`格式电子书的gitbook、用于构建博客的框架Hexo等。每一项工具都可以被视为一门独立的技术，如果全都要掌握，面面俱到，那么学习成本将是非常高昂的。所以，我们要根据自己的需要有选择地进行学习。 42 | 43 | 所以说，所有的机制、框架和工具最终都要落实到具体的使用上，而“如何使用”基本上是使用者根据应用场景所做的判断。一件工具是发挥它的优势，还是呈现出它的劣势，就全凭使用者如何做出判断了。 44 | 45 | ## 1.3 基于Markdown的基本写作理念 46 | 47 | 在介绍完Markdown的优势和劣势之后，我们再来进一步讨论“为什么应选择使用Markdown来写作”这个问题。首先，我想请大家先一起来回顾一下：在使用纸和笔为主的时代，我们是怎么写作的。相信那个时代还并不遥远。大家应该都还记得我们的写作大致上是按照以下步骤来进行的： 48 | 49 | - 在脑海中构思作品的整体方向和大致内容。 50 | - 在一张纸上列出作品的大纲，以确定各章节的标题。 51 | - 以大纲确定的各章节标题来编写作品内容，写出初稿。 52 | - 然后将初稿的复印件送给相关人士审阅，收集反馈。 53 | - 根据审阅者的反馈修改作品，写出最终稿。 54 | - 将最终稿交给出版社进行排版设计，并出版作品。 55 | 56 | 在上述过程中，我们在每个步骤中都不需要去考虑其他步骤的事。譬如，在写大纲的时候，我们只需要是思考各章节的标题是什么？不需要考虑各章节的标题应该是什么字体、字号和颜色。在送给老师和编辑审阅的时候也不需要考虑他们用什么电脑，电脑里装了什么系统。排版编辑也不会在排版设计阶段抱怨我们那些既自以为是，又混乱不堪的排版增加了他太多额外的工作量。但这些问题在我们使用了Word或Pages这样的文字处理软件之后却都一一成了常见问题，这是为什么呢？ 57 | 58 | 原因就在于这些文字处理软件的功能太强大了。是的，软件功能太强大也会带来问题。因为这些软件功能会诱惑我们在写作的同时兼顾很多事，这些事会对写作的步骤形成干扰。譬如，这些功能会诱惑我们在编写章节标题的时候去考虑它们的字体、字号和颜色。在写各章节内容的时候就会去考虑段间距、行间距、文字对齐或表格样式等。但是，写作是一个需要保持思维连续专注的工作，如果你总是同时在思考好几件事，写作思维就会被打得支离破碎，这是非常影响写作质量的。当然，我们确实可以运用自控力让自己先专注于当前的写作步骤。但会让我们*有意识地用到自控力*这件事本身就证明了这些功能的干扰。毕竟我们在用笔和纸写作的时候，连想都不会去想到这些，除非你是在用一套水彩笔写作。Markdown的简单易用就是让写作回归于纸和笔的状态，尽量排除一切工具的干扰，*让我们专注于写作本身*。 59 | 60 | 除了能让写作回归其本真，提高我们对写作的专注力之外，使用Markdown写作的另一个基本理念是：*像写程序一样写作*。Markdown的设计完全符合我们在编写程序时所要遵守的一些原则： 61 | 62 | - **每次只做好一件事**：如前所述，Markdown只专注于与写作相关的事情。 63 | - **避免平台依赖，确保可移植性**：Markdown以纯文本格式存储，不依赖于任何操作系统和编辑平台。 64 | - **不重复发明轮子**：使用Markdown编写的文本文件可以作为其他程序的输入数据，这确保了我们可以使用现有的工具对Markdown文件执行进一步的处理，譬如用LaTeX排版，用Hexo发布博客等。避免安装一些巨大而臃肿，却百分之八十功能永远都不会用到的昂贵软件。 65 | 66 | 基于这些原则，我们就可以将所有可用于程序开发的软件设计和工程经验运用到文字创作上，更好地发挥计算机赋予我们的优势，让我们的写作过程更为规范，更符合互联网时代的工作形态。 67 | 68 | ## 本章小结 69 | 70 | 在这一章中，我们首先介绍了Markdown的概念、设计理念和标准化的过程。然后，我们罗列了这门标记语言的优势和劣势。最后，我们基于这些优势和劣势阐述了基于Markdown的基本写作理念。 71 | 72 | 简而言之，Markdown是一门专为写作而设计的、自由开源的轻量级标记语言。它的语法简单明了，非常接近于人类的自然语言，有助于我们将注意力集中于写作本身。另外，由于它的纯文本特性，使它具备了非常好的开放性和可编程性，这让我们可以像使用编程语言一样用它来进行写作，即先写完内容，再用其他各种工具来对其进行处理。而且在整个写作过程中，我们都可以运用之前作用于程序开发的软件工程思想来管理写作进度，执行版本控制以及处理作品的发布问题。 73 | 74 | 从下一章开始，我将会以一篇专业论文的产生过程为例来具体介绍Markdown的使用，看看像编程一样写作的过程究竟是怎样的一种体验。 75 | 76 | 77 | 78 | [^1]:注释：约翰·格鲁伯是一位来自美国宾夕凡尼亚州的作家、博客编者、用户界面设计师及Markdown发布格式的发明者。 79 | [^2]:注释：亚伦·希勒尔·斯沃茨是一位著名的美国计算机程序员、企业家、作家、政治活动者和互联网黑客主义者。他参与开发了RSS网上信息源发布格式、Markdown文本发布格式、知识共享组织、web.py网站开发框架，同时是社交媒体Reddit的联合创始人。 80 | [^3]:注释：即2019年03月 81 | -------------------------------------------------------------------------------- /src/02_第二章.md: -------------------------------------------------------------------------------- 1 | # 第2章 写作的前期准备 2 | 3 | ## 本章提要 4 | 5 | 在接下来的几章中，我将以自己当年撰写大学毕业论文的过程为导引，逐步深入地介绍Markdown的标记语法与使用技巧。本章将介绍的是论文的一些前期准备工作。首先，我会介绍几款值得一试的Markdown编辑器。然后就进入基本语法的教学，我们将会学习如何通过标题标记来拟定论文大纲、通过列表标记来表列论文的参考资料、通过设定待办事项来安排写作的进度。当然，这里需要特别说明的是，用来做例子的是我2006年时的本科生毕业论文。这篇论文无论在内容的新鲜度还是在技术的深度上都是不值一提的，使用它完全是因为配合Markdown的教学需要，充当一个应用场景，所以我也不会完全显示论文的全部内容。 6 | 7 | ## 2.1 选择编辑器 8 | 9 | 所谓“工欲善其事必先利其器”，毕竟Markdown只是一门用于写作的标记语言，它本身是无需安装任何软件来支持的，任何一款文本编辑器都可以用来编写Markdown文档。但是，如果我们想要用它来创作论文这样的工程级项目的话，为写作效率和体验着想，还是应该要为自己选择一款能称心如意的编辑器。但这说起来容易，做起来却没有那么简单。由于Markdown一门开放性的语言，开源社区为它开发了五花八门的扩展功能，有些得到了某种程度的标准化，有些则完全没有被标准化，这导致支持Markdown的编辑器虽然很多，并且在基本用法上大同小异，但在扩展支持上就很不一致了，有些不支持$\LaTeX$数学公式，有些不支持`Mermaid`等JS图库，我们只能根据自己所做的项目来选择这些编辑器。所以，接下来我会分三个应用场景来介绍几款Markdown编辑器。 10 | 11 | ### 2.1.1 笔记类编辑器 12 | 13 | 在做笔记的时候，我们需要的是随时可以创建、编辑、搜索、整理自己的笔记。在这种情况下，我们只需要编辑器支持最基本的Markdown语法，不需要它支持太多扩展，但应该要支持多种平台（MacOS、Windows、Android、iOS），多种设备（PC、平板、手机），多种访问方式（Web浏览器、客户端、API），然后还应该要能进行云端同步，并且提供强大的分类管理和搜索功能。在这里，我会为大家介绍两款笔记类软件： 14 | 15 | - **有道云笔记**[^1]：这是一款国内知名的中文笔记类软件，几乎支持所有的主流平台。更重要的是，它支持所有的访问方式，无论是Web方式还是客户端方式，并都提供了对Markdown的支持。 16 | 17 | 在有道云笔记中创建Markdown笔记更简单，只需像下图一样找到新建文档的按钮，然后在其中选择「新建 Markdown 笔记」即可： 18 | 19 | ![在有道云笔记中新建Markdown文档](img/2-1.png) 20 | 21 | - **马克飞象**[^2]：这是一款专为印象笔记（英文版名为Evernote，这一款国际知名的笔记类软件）量身定做的Markdown编辑器，支持印象笔记的笔记本和标签管理，使我们可以轻松管理笔记。它支持高亮代码块、$\LaTeX$公式、流程图，本地图片以及附件上传，甚至截图粘贴等工作学习中时常会用到的功能。同时这也是一款跨平台的编辑器，提供有PC桌面客户端以及离线Chrome App，也支持我们用Web方式进行访问。下面是它的Web界面： 22 | 23 | ![马克飞象的Web界面](img/2-2.png) 24 | 25 | ### 2.1.2 本地文件编辑器 26 | 27 | 在如今这个时代，当我们需要在本地计算机上对文件进行编辑时，往往就意味着要做一些较为复杂的事，这就需要编辑器具有完善的编辑功能，就Markdown来说，用来编辑本地文件的编辑器如果只支持基本语法，显然就不够用了。我们得根据自己的编辑需要来选择支持某部分扩展特性的Markdown编辑器。例如，接下来我们要撰写的是计算机专业的大学论文，预估少不了会编辑数学公式、流程图、UML图以及代码高亮显示，那么选择的编辑器就必须要能支持Markdown的$\LaTeX$扩展、`Mermaid`等图库以及文件预览功能。当然，符合这些要求的软件也不少，但考虑到本章的整体谋篇，我在这里同样只介绍两款具有代表性的Markdown编辑器。 28 | 29 | - **Typora**[^3]：​ Typora是一款轻便简洁的Markdown编辑器。由于使用了即时渲染技术，所以它可以和Word、Pages一样提供”所见即所得“的写作体验。这也是它与其他Markdown编辑器最显著的区别，不再需要分栏显示编写区和预览区了。除此之外，Typora也是一款支持多平台的Markdown编辑器，我们在Linux、MacOS和Windows中都可以使用这款软件，这可比只能在Windows下使用的MarkdownPad，或者只能在MacOS/iOS下使用的Ulysses要好多了。 30 | 31 | 关于这款编辑器的具体使用，我们将会在第五章中详细介绍。 32 | 33 | - **VSCode**[^4]：VSCode是Visual Studio Code的缩写，这是一款通用的代码编辑器，它同样在Linux、MacOS和Windows下都可以使用。正是由于这是一款通用的代码编辑器，主要的作用是编写程序代码，因此其自身集成了强大的文件管理和版本控制模块，这些模块可以帮助我们轻松地实现工程级的项目管理。 34 | 35 | 更为重要的是，VSCode具有非常强大的插件体系，以便它可以胜任几乎所有编程语言和标记语言的编辑。譬如对于Markdown，我们只需要在VSCode的插件管理系统中搜索Markdown Extension Pack，然后安装该插件即可，如下图所示： 36 | 37 | ![Markdown Extension Pack插件](img/2-3.png) 38 | 39 | 关于该编辑器的具体使用，我们将会在第三章中详细介绍。 40 | 41 | ### 2.1.3 其他Markdown编辑器 42 | 43 | 当然，大家也可以根据自己的喜欢和具体情况来选择一些别的编辑器。下列，我们罗列了一些目前市面上比较常见的Markdown编辑器，以供大家参考。 44 | 45 | | 编辑器 | 具体说明 | 46 | |------------|-----------------------| 47 | | 简书 | 一个很不错的博客平台，每几秒钟便会自动存入一个备份。可以直接从本地拖入照片生成链接，一直在不断优化。当然，作为一个博客平台，需要注册账号后方能进行写作。| 48 | | Ulysses | 一款MacOS/iOS平台上的Markdown编辑器，支持将Markdown文档转换成PDF、docx、ePub等各种格式。| 49 | | Mou | 这是MacOS平台下一款杰出的Markdown编辑器，提供语法高亮、在线预览、同步滚动、全屏模式等功能，允许自定义主题，支持将Markdown文档转换成CSS、HTML、PDF等各种格式。| 50 | | Miu | 一款在Windows平台下模仿Mou的Markdown编辑器。| 51 | | MarkdownPad | 一款Windows平台上的Markdown编辑器，具有良好的即时预览功能。| 52 | | Atom | 一款由github专门为程序员推出的跨平台代码编辑器，有着与VSCode类似的插件系统，安装相关插件之后即可编辑Markdown文档。| 53 | | Sublime Text | 一款跨平台的代码编辑器，有着与VSCode类似的插件系统，安装相关插件之后即可编辑Markdown文档。| 54 | 55 | 在某些应用场景中，我们可能会需要透过Web或SSH的方式直接编辑服务器端的文件。这时候就需要用到浏览器和vim的Markdown插件，下面我们就来介绍一下这些插件。 56 | 57 | - **Markdown Here**[^5]：这是除微软的IE浏览器之外，几乎所有的主流浏览器，包括Google Chrome、Mozilla Firefox和Apple Safari都支持的一款Markdown编辑插件。有了这款插件，我们就可以在浏览器中用Markdown编写电子邮件和微信公众号，然后用该插件将所编写的内容一键转换成相应的`HTML`渲染效果，当然，在这之前我们还是要对该插件做一些基本的样式设定，下面是该插件的设置界面： 58 | 59 | ![Markdown Here插件的设置界面](img/2-4.png) 60 | 61 | 该插件的使用也非常简单，下面我们就以在浏览器中编写电子邮件为例来做个简单的示范： 62 | 63 | 1. 先在浏览器中新建一封电子邮件，并输入以下用Markdown标记的内容，当然，我们现在可暂时不用去管这些标记的具体含义： 64 | 65 | ![用Markdown编写电子邮件](img/2-5.png) 66 | 67 | 2. 然后只需单击一下浏览器工具栏中的Markdown Here插件图标，上述内容就自动转换成了相应的`HTML`渲染效果： 68 | 69 | ![Markdown Here插件的转换效果](img/2-6.png) 70 | 71 | - **vim**：这是一款由vi扩展而来的、闻名于世界的*命令行编辑器*。当我们要将用Markdown编码的内容以Web服务的形式来发布（譬如用Hexo发布的博客，或用gitbook发布的电子书等）的时候，通常会遇到一些需要对某段文本进行小幅修改的情况。对于这种需求，我们往往会选择通过SSH方式直接登陆到服务器上用vim来修改，而不是在本地修改完再重新整体发布一次到服务器上，这不仅操作太繁琐，而且也太小题大做。 72 | 73 | 虽然vim本身就可以对Markdown文件进行编辑，但如果我们想提高编辑的效率和体验，就应该安装一下相应的插件。vim的插件通常是通过一个叫vundle的插件管理器来安装的。关于vundle的安装、配置与基本使用，建议读者去自行查阅一下相关文档资料，这里就不展开这一话题了，以免喧宾夺主。在安装和配置完vundle之后，我们就可以用它来安装插件了。具体来说，与Markdown的编辑相关的主要有以下三个插件： 74 | 75 | 1. **vim-markdown**：这是一款针对Markdown语法高亮的插件。 76 | 2. **previm**： 这是一款用于预览Markdown渲染效果的插件。 77 | 3. **vim-colorschemes**：这是一款用于配置各种颜色主题的插件。 78 | 79 | 当然，如果大家觉得手动安装这些插件太麻烦，也可以使用一些定制版的vim，譬如，SpaceVim[^6]就是一个不错的vim定制版本，下面是我用该版本vim编辑本书第1章时的截图： 80 | 81 | ![SpaceVim](img/2-7.png) 82 | 83 | ## 2.2 作品的前期规划 84 | 85 | 在挑选完写作工具之后，我们就可以开始正式对论文进行规划了。在进入具体的写作之前，先做一些规划工作是一个不错的选择，这样做的主要目的是将整个论文的创作过程纳入工程化管理，让它有一个清晰的框架，明确整体的写作方向，并做好创作的进度管理。具体来说就是，我们接下来要拟定论文的大纲，然后再根据大纲来表列可能会用到的参考文献，最后我们会对论文的整个写作进度做出一个计划性的时间安排。显然，这些内容应该都属于笔记性质的内容，所以我们会用有道云笔记来完成这部分的工作。 86 | 87 | 首先，我们要在有道云笔记中新建一个文件夹，将其命名为「毕业论文规划」，如下图所示： 88 | 89 | ![在有道云笔记中创建一个文件夹](img/2-8.png) 90 | 91 | 本章接下来所有的工作都会在这个文件夹中进行，下面先来拟定论文的大纲。 92 | 93 | ### 2.2.1 拟定论文大纲 94 | 95 | 有过写作经验的人大概都知道，一篇文章的大纲通常同时就是它各章节的分级标题，所以我们会用Markdown的标题元素来撰写论文的大纲。在Markdown中，标题的语法有`atx`和`setext`两种风格。在本书中，我们主要采用的是`atx`风格，在这种风格中，标题的级别是由其标题文本之前的井号（`#`）数量来指定的，譬如我这篇论文的标题是「网上书籍销售系统的设计」，那么在Markdown中，我们就应该这样写： 96 | 97 | ```Markdown 98 | # 网上书籍销售系统的设计 99 | ``` 100 | 101 | 这就被视为整篇文章的一级标题，请注意，“`#`”与标题文本之间要用一个空格符隔开。同样的，二级标题就是在标题文本前面加两个“`#`”，三级标题则是加三个“`#`”，譬如在我的这篇论文中，如果第一章的标题是「第1章：系统概述」，第一章第一节的标题是「1.1 系统的设计目的和意义」，那么我们就应该这样写： 102 | 103 | ```Markdown 104 | # 网上书籍销售系统的设计 105 | ## 第1章：系统概述 106 | ### 1.1 系统的设计目的和意义 107 | ``` 108 | 109 | 由于最初设计目的的原因，Markdown中的标题与`HTML`是一一对应的，所以它最多应该可以支持到六个级别的标题（即`HTML`中的`

`到`

`），也就是说，在`atx`语法风格中，标题文本之前的“`#`”最多可以设置六个： 110 | 111 | ```Markdown 112 | # 一级标题 113 | 114 | ## 二级标题 115 | 116 | ### 三级标题 117 | 118 | #### 四级标题 119 | 120 | ##### 五级标题 121 | 122 | ###### 六级标题 123 | 124 | ####### 这不是标题了！ 125 | ``` 126 | 127 | 渲染效果如下图所示： 128 | 129 | ![Markdown最多可以有六级标题](img/2-9.png) 130 | 131 | 在通常情况下，我们都会建议一篇论文的标题层级最好都不要超过四级，否则论文可能会因为被分得太细而显得支离破碎，这既会影响作者写作的流畅感，也会影响读者阅读的整体感。具体到眼下这篇论文中，我们只需要设置三级标题即可，具体如下： 132 | 133 | ```Markdown 134 | # 网上书籍销售系统的设计 135 | ## 第1章：系统概述 136 | ### 1.1 系统的设计目的和意义 137 | ### 1.2 系统的可行性分析 138 | ## 第2章：系统数据库的设计 139 | ### 2.1 数据库中的表关系 140 | ### 2.2 数据库中各表的设计 141 | ### 2.3 数据库设计的优化 142 | ## 第3章：功能模块的划分 143 | ### 3.1 业务逻辑分析 144 | ### 3.2 划分功能模块 145 | ## 第4章：开发环境与工具的选择 146 | ### 4.1 服务器端 147 | ### 4.2 浏览器端 148 | ## 第5章：各功能模块的实现 149 | ### 5.1 全局作用的函数和变量 150 | ### 5.2 用户模块 151 | ### 5.3 公告模块 152 | ### 5.4 书籍模块 153 | ### 5.5 导航模块 154 | ### 5.6 交易模块 155 | ## 第6章：系统程序的发布 156 | ### 6.1 前期准备 157 | ### 6.2 发布工具 158 | ### 6.3 发布过程 159 | ### 6.4 后续维护 160 | ## 第7章：设计总结 161 | ### 7.1 本系统的优点 162 | ### 7.2 本系统存在的问题 163 | ### 7.3 分析并提出观点 164 | ``` 165 | 166 | 下面，就让我们将上述大纲录入到有道云笔记中，看看它们的渲染效果吧。 167 | 168 | ![论文大纲在有道云笔记中的渲染效果](img/2-10.png) 169 | 170 | 在默认情况下，有道云笔记的Markdown编辑区被分成了两个部分：左边是编码区，用于输入Markdown的原始编码，右边是预览区，用于显示Markdown编码所对应的`HTML`渲染效果。这也是大部分Markdown编辑器会呈现的布局，当然也有例外，譬如在Typora这种强调”所见即所得“的编辑器中，编码区与预览区合二为一了： 171 | 172 | ![论文大纲在Typora中的渲染效果](img/2-11.png) 173 | 174 | 正如你所见，Typora这款编辑器不仅能即时地根据我们输入的Markdown编码显示出了相应的`HTML`渲染效果，还直接将我们设置的标题同步显示在了左侧的大纲视图中，这对提升写作体验是非常有帮助的。 175 | 176 | 另外，如果某些文章只需用到两级标题，那么我们也可以使用`setext`风格的标题语法，即分别用若干个“`=`”和“`-`”来表示一二级标题： 177 | 178 | ```Markdown 179 | 一级标题 180 | ======= 181 | 182 | 二级标题 183 | ------- 184 | ``` 185 | 186 | 渲染效果如下图所示： 187 | 188 | ![setext风格的标题](img/2-17.png) 189 | 190 | ### 2.2.2 表列参考文献 191 | 192 | 论文的写作归根结底是对某些科学技术或理论的论证或再处理，所以能否充分地收集并利用好现有的文献资料，事实上将决定着论文的质量。因此，我们在开始正式撰写论文之前，应该尽可能多地收集可用于论证选题的文献资料，将其表列出来，以便作为论文的附录。 193 | 194 | 就目前来说，论文的参考文献主要有两个来源：第一个来源是学术专著、学术期刊等正式出版物；第二个来源是相关机构在互联网上公布的权威数据。当然，我们在这里要处理的只是一篇普通的大学毕业论文，它所需要的参考文献并没有那么高的专业要求，因此收集文献的这部分工作不需要花费多少时间，也不是我们要讨论的内容。下面，我们就来看看如何用Markdown来表列这些文献资料。在Markdown中，用于表示列表的标记有两种： 195 | 196 | - **无序列表**：这种列表对应的是`HTML`中的`