Markdown写作指南

作者: 凌杰
译者:
编辑: 曹修山

图书目录:

详情

markdown写作可以延伸出很多东西啊,写论文涉及LaTeX、Mermaid等,制作电子书涉及gitbook ,建构博客涉及Hexo,居然没人写本书!可惜了…… 
【订阅须知】  
1.本专栏为订阅专栏,订阅成功后,即可通过异步社区PC端和移动端观看。 
2.本专栏更新时间,每周一更新,形式为图文。
2019年7月31日 专题一加前缀 
2019年8月7日 专题二  
2019年8月14日 专题三 
2019年8月21日 专题四 
2019年8月28日 专题五 
2019年9月4日 专题六 
2019年9月11日 附录A\B 
3.本专栏为虚拟商品,一经订阅,概不退款。


图书摘要

版权信息

书名:Markdown写作指南

本书由人民邮电出版社发行数字版。版权所有,侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用,未经授权,不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟,与我们共同保护知识产权。

如果购买者有侵权行为,我们可能对该用户实施包括但不限于关闭该帐号等维权措施,并可能追究法律责任。

凌杰:浙江大学远程教育学院“荣誉学员”、2012年度“十大远程骄子”。目前为自由软件开发者。精通C/C++、Python、JavaScript等多门编程语言,拥有丰富的软件开发及测试经验。个人崇尚黑客文化,支持开源运动,时常出没于国内外各种技术社区,曾担任上海交通大学饮水思源BBS的技术区区长,并兼任该区C/C++板板主多年。近些年来还参与了多本计算机技术类外文书籍的翻译工作,译作包括《Python算法教程》、《JavaScript面向对象编程指南》、《元素模式》等。

内容提要

本专栏将以一篇本科毕业论文的写作过程为导引,介绍了Markdown分别在完成论文的规划、撰写、修改、发布这些不同任务阶段中的应用。希望通过这本小书来介绍一下个人对Markdown这种写作方式的看法和使用经验,以此来抛砖引玉,引起大家对Markdown更多的关注,进而将软件开源的精神推广至写作领域。毕竟,文字作品才是我们人类开发时间最长,数量最多的一种“软件”。

经过了整整三个月的努力,我终于将这本已在心中酝酿了很久的小书写完了。写书真是一种很奇特的经历,整个过程既让人觉得很纠结,很惶恐,也令人感到很兴奋,很快乐。我个人认为,在如今的互联网上,人们只要能善用搜索引擎,基本上就可以找到自己想要了解的任何信息了。因而在这个时代,写书的目的已不应该只是单纯地普及知识了,它应该更多地表现作者自己的一些观点和经验。因为只有这种个性化的东西才是任何人工智能的产物所无法替代的,这些东西当然未必正确,但它能刺激思考,引发讨论,使人沉淀,而这些恰恰是如今互联网上所缺少的。所以,我希望通过这本小书来介绍一下个人对Markdown这种写作方式的看法和使用经验,以此来抛砖引玉,引起大家对Markdown更多的关注,进而将软件开源的精神推广至写作领域。毕竟,文字作品才是我们人类开发时间最长,数量最多的一种“软件”。

写这本书的最初念头源自于一次在Facebook上的抱怨。由于我自己是一个Markdown的重度使用者,在日常做笔记、写文章、翻译书籍时,经常需要搜寻各种使用Markdown写作的解决方案。而与此同时,市面上的各种博客、论坛、云端笔记服务也都纷纷加入了对Markdown的支持,这说明使用这门标志语言的用户并不在少数,但我却惊讶地发现自己市场上竟然找不到一本介绍Markdown的专著。于是就在Facebook上分享了下面这个想法:

我是觉得markdown写作可以延伸出很多东西啊,写论文涉及LaTeX、Mermaid等,制作电子书涉及gitbook ,建构博客涉及Hexo,居然没人写本书!可惜了……

很自然地,这条想法分享的下面就有朋友留言建议我“不如你来写吧”。虽然当时我只是在表达自己需要这样一本书,最好请某位专业人士来写一本,但与朋友的讨论让我重新审视了自己所分享的这个想法。这个想法实际上说明了我为什么喜欢用Markdown来写作的原因:

总结一下,就是Markdown可以让人们“像写程序一样写作”,这让我意识到写这样一本书的意义已经不仅仅是介绍一门轻量级的标记语言,而是在推广一种强调自由、开放、合作的价值观和方法论了。而这种价值观和方法论原本就是我多年以来一直在坚持的,如今既然看到没有人写一本关于Markdown的专著,不如就自己来为它的推广做点事吧。

在这本书中,我以一篇本科毕业论文的写作过程为导引,介绍了Markdown在完成论文的规划、撰写、修改、发布这些不同任务阶段中的应用。全书被分成了六个章节和两个附录:

在读者正式开始阅读本书之前,我还希望对开源运动做一个简单的介绍。从本质上来说,软件的开源事实上是针对软件工程问题提出的一个解决方案。而说起软件工程这档事,我相信计算机和软件工程专业的学生应该都不陌生,我们早年间都背下来过一些流水线式的项目开发流程。首先是在项目定义阶段要做可行性分析、需求分析这些事,再来进入到开发阶段要做概要设计、详细设计、设计实现等步骤,最后是维护阶段的运行与维护。仿佛软件开发就像《摩登时代》里的工厂流水线,分工明确、井然有序。目的是让程序员成为流水线上的工人,使他们成为生产机器中的一个螺丝钉,无需创意、无需个性,只要够熟练就行。很多大型企业的开发项目也确实是按照这个路数走的,很多程序员被戏称“码农”也正是这个原因。

但是,等我工作了若干年之后再来看这套工程管理模型,感觉这基本上就是个“计划经济”。首先,绝大部分软件在开发初期根本不会有那么多人参与,通常是两三个人要做所有的事情。分那么多阶段,那么多工序是没有意义的。再来,就算是有了一定规模的公司,他们会让很多人参与一个项目,往往都是为了维护已有的软件,程序员的主要任务是维护该软件的版本,并在此基础上开发新的版本,在这种情况下,他们其实已经有了现成的开发框架,这些人只需要根据特定的需求将该框架填充成具体的专用软件即可。对于原框架来说,这更像是增加了一个特性分支。例如说,JetBrain团队开发了一款名为IntelliJ IDEA的通用IDE,而Android Studio则又是专用于Android开发的IDE,它就是基于IntelliJ IDEA开发出来的。我们可以将它视为IntelliJ IDEA项目的一个分支。这更像是某种意义上的维护工作,它的可行性,需求是一目了然的,也不需要概要设计,只需要按照其原有的插件体系把功能实现即可。然后,bug修复才是这个项目的主要工作。所以,如何让那么多人一块有效地,有序地发现bug、报告bug、解决bug成为了主要问题。

上世纪的七十年代和八十年代爆发了两次所谓的软件危机[1],那时候的许多软件项目都出现了预算超支、发布时间严重拖延、质量管理缺失等问题。大量的项目因此而失败,问题很严重,以致于北约这样的组织都要专门开会来讨论这个问题。但这些高高在上的人物讨论出来的东西就是我们上面所说的软件工程理论。按照《人月神话》作者佛瑞德·布鲁克斯(Frederick P. Brooks)的说法,这需要大量的银弹、人员来支撑,只有大型企业,科研机构才能做到。当然对于这些机构来说,这套理论确实能解决一些问题。尤其在互联网时代来临之前,这似乎也是我们唯一的选择。

但大型机构都存在官僚主义的问题,组织繁杂、沟通成本高昂、开发效率低下,随着时间的推移它们往往都会离人们的实际需求越来越远,就像是那些中世纪大教堂,高高在上、脱离现实地定期发布信息,内容庞杂而滞后,对于其周边的、下游的开发者和中小软件开发是毫无帮助。于是Linux之父林纳斯·托瓦兹(Linus Torvalds)在独自开发Linux内核的过程中走出了一条新的道路:开放源码、社区协作。简单来说,就是由软件项目的创始人开发出一个不成熟的初始版本,然后将其丢到一个开发者社区中,让其在开发者自发性的修改和分享中自然生长。最后,项目创始人会根据其生长情况将自己认可的部分纳入到项目的主分支中。这种乱中有序的组织形式让Linux项目获得了巨大的成功,给软件开发的工程管理提供了一种新的实践经验

无独有偶,上世纪九十年代末期,网景公司[2]在与微软公司的浏览器大战中败下阵来,面临着公司的生存危机。他们决定试试开源的方式。埃里克·雷蒙(Eric Raymond)就是网景公司当时的策略顾问,他在帮助网景公司的过程中根据自己的新的写出了他那本闻名天下的代表作:《大教堂与集市》。这本书为开源运动奠定了理论基础,它系统阐述了互联网条件下的协作模式,同行审评的优势,回答了《人月神话》中提出的银弹问题,人员管理成本问题。如今,微软、苹果这些曾经的大教堂都纷纷加入了开源领域。开源作为软件工程的另一种组织形式已经毋庸置疑。

最后需要提醒的是,开源运动和理查德·斯托曼(Richard Stallman)领导的自由软件运动[3]不是一回事。开源运动更多的是一种软件工程的管理方式,虽然也强调开放源码、免费分享的自由精神,但并没有太强烈的道德要求。而自由软件运动则更像是一种宗教性的意识形态运动,他们对于“确保用户使用软件的自由”有着一种近乎苛刻的道德要求,譬如,他们会要求所有基于自由软件开发的产品都不仅要开放源码,还必须要允许用户修改该产品软件的源码,或变更其硬件的使用方式,让用户真正地享有“自由”,这难免让人觉得有一些乌托邦式的理想主义。而在我个人看来,如此激烈的主张在客观上反而会给源代码的分享带来了不少的阻力。

这本书能够成型,离不开很多人的鼓励和帮助。如果没有卷积传媒的CEO高博先生的鼓励,我不会下决心写这本书。另外,我的好朋友,在香港的朱磊也对本书的初稿进行了认真的审阅,提供了不少宝贵的建议。最后感谢人民邮电出版社,愿意出版这本题材较为冷门的小书,希望不会辜负了他们信任。还有,我的女友蔓儿,谢谢你甜蜜的爱,它是我在这个世界上奋斗的动力。

当然,无论如何,这本书中都会存在一些不够周全,表达不清甚至错误的地方。如果读者有任何意见,我都希望你致信lingjiexyz@hotmail.com,或者在异步社区中本书的勘误页面中提出,以帮助我们在本书的后续修订中进一步完善它。

[1] 请参考`https://zh.wikipedia.org/wiki/`软件危机

[2] 请参考`https://zh.wikipedia.org/wiki/`网景

[3] 请参考`https://zh.wikipedia.org/wiki/`自由软件


本章提要

在这一章中,我们将会对Markdown做一个概念性的简单介绍。具体来说,我们会讨论Markdown是什么、它有什么优势和劣势以及它所倡导的写作理念。需要说明的是,本章是为对Markdown一无所知的朋友准备的。如果你自认为已经对Markdown有所了解,或者不想纠缠于技术概念,想快点进入“如何使用Markdown”的议题,也可以选择跳过本章内容,直接从下一章开始阅读。但是,如果你想更完整地了解我对这门技术的观点,还请你稍微花点耐心读一下这一章的内容,毕竟正如一千个人的心中有一千个哈莫雷特,对于同一门技术,每个人的理解也都略有不同。

Markdown是约翰·格鲁伯(John Gruber)1与亚伦·斯沃茨(Aaron Swartz)2于2004年共同开发的一门轻量级标记语言(Lightweight Markup Language,简称LML)。也就是说:首先,Markdown是一种标记语言,可以用任意的文本编辑器来进行输入和修改,并以纯文本的格式保存在计算机中。其次,这是一种“轻量级”的语言,这意味着相对于RTFHTMLTeX这些格式更丰富的标记语言来说,Markdown的格式更为简单易用,也更接近于自然语言。这让它更适合用来写作和分享。格鲁伯们开发这门语言的目的就是为了鼓励人们先使用一种易读易用的纯文本格式来编辑并存储文档,然后再根据实际需要将文档转换成(X)HTMLdocxPDF等格式。Markdown在设计上非常重视可读性。换句话说,Markdown的设计目标之一是要让人类能直接从字面上对其进行阅读,不需要太多精力学习一些格式化指令标记(譬如RTFHTML)。

1约翰·格鲁伯是一位来自美国宾夕凡尼亚州的作家、博客编者、用户界面设计师及Markdown发布格式的发明者。

2亚伦·希勒尔·斯沃茨是一位著名的美国计算机程序员、企业家、作家、政治活动者和互联网黑客主义者。他参与开发了RSS网上信息源发布格式、Markdown文本发布格式、知识共享组织、web.py网站开发框架,同时是社交媒体Reddit的联合创始人。

事实上,Markdown最初的实现只不过是格鲁伯参考现行电子邮件的标记格式和一些早期的标记语言(譬如SetextTexile等),编写出的一个可将用Markdown语法编写的文档转换成有效的、结构良好的(X)HTML格式的Perl脚本程序:Markdown.pl。该脚本既可以单独使用,也可以被用作Blosxom这类博客系统的插件,或者BBEdit这类编辑器的文本过滤器。但随着时间的推移,Markdown已经被许多人用Perl或其他编程语言重新实现,市面上陆续出现了许多不同版本的Markdown实现。同时,人们也在Markdown基本语法的基础上开发出了许多额外的功能,例如表格、脚注、列表以及代码块等。这其中有些功能已经偏离了这门语言最初的实现,带来了语法规范上的含糊不清,这些问题促使Markdown的标准化问题被提上了议程。当然,值得一提的是,作为Markdown的创立者,格鲁伯并不赞成完全标准化,他认为:“不同的网站(和人们)有不同的需求。没有一种语法可以让所有人满意。”

以我写这本书时3所查到的资料,Markdown标准化的最新进展是,2016年3月发布的RFC 7763RFC 7764这两份文件。其中,RFC 7763文件从原始变体引入了MIME类型text/markdown。而RFC 7764文件则讨论并注册了MultiMarkdownGitHub Flavored Markdown(GFM)PandocCommonMarkMarkdown等不同的实现版本。

3即2019年03月。

如今,Markdown的使用者早已不只是写程序文档的程序员,它在国际上已经受到越来越多编辑和写作者的青睐。用Markdown来写作和编辑文章在网络时代有着超乎想象的优势。下面,我们就来具体讨论一下这些优势:

当然,任何人、事、物都会在展现其优势的同时呈现出一些劣势。而且优势和劣势通常都来自于同一个特性,是优势还是劣势完全看这个特性所发挥的面向。下面我们就来看看Markdown具有那些劣势,或者说它不适合被用来做哪些事:

所以说,所有的机制、框架和工具最终都要落实到具体的使用上,而“如何使用”基本上是使用者根据应用场景所做的判断。一件工具是发挥它的优势,还是呈现出它的劣势,就全凭使用者如何做出判断了。

在介绍完Markdown的优势和劣势之后,我们再来进一步讨论“为什么应选择使用Markdown来写作”这个问题。首先,我想请大家先一起来回顾一下:在使用纸和笔为主的时代,我们是怎么写作的。相信那个时代还并不遥远。大家应该都还记得我们的写作大致上是按照以下步骤来进行的:

在上述过程中,我们在每个步骤中都不需要去考虑其他步骤的事。譬如,在写大纲的时候,我们只需要是思考各章节的标题是什么?不需要考虑各章节的标题应该是什么字体、字号和颜色。在送给老师和编辑审阅的时候也不需要考虑他们用什么电脑,电脑里装了什么系统。排版编辑也不会在排版设计阶段抱怨我们那些既自以为是,又混乱不堪的排版增加了他太多额外的工作量。但这些问题在我们使用了Word或Pages这样的文字处理软件之后却都一一成了常见问题,这是为什么呢?

原因就在于这些文字处理软件的功能太强大了。是的,软件功能太强大也会带来问题。因为这些软件功能会诱惑我们在写作的同时兼顾很多事,这些事会对写作的步骤形成干扰。譬如,这些功能会诱惑我们在编写章节标题的时候去考虑它们的字体、字号和颜色。在写各章节内容的时候就会去考虑段间距、行间距、文字对齐或表格样式等。但是,写作是一个需要保持思维连续专注的工作,如果你总是同时在思考好几件事,写作思维就会被打得支离破碎,这是非常影响写作质量的。当然,我们确实可以运用自控力让自己先专注于当前的写作步骤。但会让我们有意识地用到自控力这件事本身就证明了这些功能的干扰。毕竟我们在用笔和纸写作的时候,连想都不会去想到这些,除非你是在用一套水彩笔写作。Markdown的简单易用就是让写作回归于纸和笔的状态,尽量排除一切工具的干扰,让我们专注于写作本身

除了能让写作回归其本真,提高我们对写作的专注力之外,使用Markdown写作的另一个基本理念是:像写程序一样写作Markdown的设计完全符合我们在编写程序时所要遵守的一些原则:

基于这些原则,我们就可以将所有可用于程序开发的软件设计和工程经验运用到文字创作上,更好地发挥计算机赋予我们的优势,让我们的写作过程更为规范,更符合互联网时代的工作形态。

在这一章中,我们首先介绍了Markdown的概念、设计理念和标准化的过程。然后,我们罗列了这门标记语言的优势和劣势。最后,我们基于这些优势和劣势阐述了基于Markdown的基本写作理念。

简而言之,Markdown是一门专为写作而设计的、自由开源的轻量级标记语言。它的语法简单明了,非常接近于人类的自然语言,有助于我们将注意力集中于写作本身。另外,由于它的纯文本特性,使它具备了非常好的开放性和可编程性,这让我们可以像使用编程语言一样用它来进行写作,即先写完内容,再用其他各种工具来对其进行处理。而且在整个写作过程中,我们都可以运用之前作用于程序开发的软件工程思想来管理写作进度,执行版本控制以及处理作品的发布问题。

从下一章开始,我将会以一篇专业论文的产生过程为例来具体介绍Markdown的使用,看看像编程一样写作的过程究竟是怎样的一种体验。


相关图书

专利写作:从创意到变现
专利写作:从创意到变现
程序员的README
程序员的README
开发者关系实践指南
开发者关系实践指南
科研论文配图绘制指南——基于Python
科研论文配图绘制指南——基于Python
走好学术路 科研萌新的自我修养
走好学术路 科研萌新的自我修养
学术文献阅读技巧与实战
学术文献阅读技巧与实战

相关文章

相关课程