StackExchange和它的游戏规则

我们都明白一个道理:没有规矩,不成方圆。这句话是在讲规则的重要性,规则定好了,怎么玩也玩不脱,规则没定好或者干脆没有规则,那大家就没法再愉快地玩耍了。问题就在于好的游戏规则不好制定。这很像编程,一个程序只有在合理的逻辑关系下才能跑通,跑起来还不够,如果写代码的时候没有考虑周全,迟早会碰到bug;当事关人类行为之时,潜在的bug就更多了,比如自私、虚荣、懒惰……如何能找到一套解决方案,即使不能消除这些bug,至少也要将之压到最低,是每一个人类社区的管理者都要考虑的问题,这个社区往大了说,可以是一个国家,往小了说,可能仅仅是一家问答网站。

数量与质量

问答类网站是近年来发展势头很猛的一类在线社区,这类网站的崛起是伴随着互联网整体信息量的冗余而愈发显著的。用亚伦·斯沃茨的话说,就是互联网的当下问题不是大众能否发出声音,而是发声的源头太多,人们想要从这些庞杂的信息中提取出有用的东西出来是一件极其困难的事情。搜索引擎的出现为找到正确信息提供了有力支持,另一类寻找信息的工具就是问答网站,一问一答,从来都是人类交流的最有效手段,相比搜索引擎查找出来的近似结果,一个精准问题所引出的有针对性的回答势必更有帮助。

目前问答网站已经有很多,国内最大的当属百度知道,可是用过百度知道的人都不免发现,这个网站的回答质量不是一般的良莠不齐,而且普遍水准不高。国内比较靠谱的问答网站可能是近年来兴起的知乎1,这个网站上线以来给人的感觉是干货比较多,原创也不少,与国内网络社区普遍的浮躁氛围迥异,因此被寄予厚望。我也是这个网站开放注册后的首批用户之一,可是两年多用下来,我也和网站的其他老用户一样,明显感到知乎的问答质量在逐渐降低。

有人说是因为随着知乎注册用户的增多,大量低水平用户涌入导致。一开始我也觉得是这样,那些问问题不经过大脑思考,回答问题只知道复制粘贴的人,说句不好听的,正如夏洛克所言,「拉低了整条街的智商」。可是当我后来发现了Stackoverflow这个网站后,我才明白关键原因并不在于用户水平,国外也有大量的低端用户,同样也是神棍伴民科齐飞,大忽悠与脑残粉横行。而Stackoverflow自2008年成立以来,始终保持超高问答水准的原因,在于它在上线之时,就制定了一套用心良苦的游戏规则。

制度的力量

Stackoverflow是一个编程领域的问答社区,在其之上还有一个母站,叫做StackExchange,管理着几十个大大小小的问答社区(参见这里),Stackoverflow是其中成立最早、规模最大的一个子站,其他的所有子站在形式上都与Stackoverflow保持一致,它们的主题各异,但社区制度是同一的,是一种基于声誉值(reputation)的激励制度,这里简述如下:

  • 新注册用户只有1声誉,此时你除了提问啥也干不了;
  • 当你提出来的问题被人顶起一次,可以获得5声誉;
  • 积累够15声誉时,你才能去顶别人的问题及回答;
  • 当你的回答被顶一次时,可以获得10声誉;
  • 如果你的回答被提问者采纳为答案,则可获得15声誉,同时提问者也可获得2声誉;
  • 如果你的回答被反对,则声誉-2,同时反对你的人声誉也跟着-1;
  • 如果你的问题被反对,则声誉-2;
  • 如果你的问答被至少六个人标记为垃圾,则一次性减去100声誉。

此外还有一些额外的奖惩制度,比如我刚刚使用Stackoverflow时,问了一些没有认真准备的问题,结果很快就被人踩了,我心想这不行啊,本来就不多的声誉值再踩几下就没了……于是我立即删除了自己的问题,令我没有想到的是,不仅之前被扣的声誉值又返还给我,网站还额外奖励了2声誉,奖励的理由是我接纳了本社区的「同行评审」意见,主动删除低质量问题。当时我就惊呆了,「同行评审」这个词我以前仅仅在涉及到学术出版时才会遇见啊。

你可能会问,那么利用它这个漏洞不就可以无限刷声誉了吗,严谨的设计者当然不会犯这样的错误,当我问下一个问题时,网站在最醒目的地方告诫我,由于我问了过多的低水平问题(- -III),这个帐号正处于危险状态,我的下一个问题必须内容翔实有针对性,否则如果再被人反对,将永久失去提问资格。这个警告确实让我认真了起来,我于是拿出写论文的诚意,写了一个既有代码片段又有若干示意图的问题。果然,我的诚意也换来了别人的诚意,这个问题在很短时间内就获得了多人的回复,完美解决了我的疑问,同时也解除了我的帐户危机。

那么,我如果很讨厌某个用户,能否通过不断踩他的问题和答案让他的账户变成危险状态呢,这在其他的网络社区可是屡见不鲜的事情。然而在StackExchange则没有可能,它有一整套防止私人攻击的规则,比如你要是反对了某人的答案,则除了扣他2声誉,你自己也要扣去1声誉,这样你在踩别人的时候,必然会三思而后行;如果你真的对某人怀恨在心,只要是他的问题你就反对,那怎么办?StackExchange不允许这种情况发生,你根本无法完成这样的操作。甚至不仅是持续反对某人,你也无法持续赞同某人,这样的行为被称为「投票欺诈」(voting fraud),系统会严格禁止此类行为,以保证问答的客观性。

自治、自制

由于StackExchange是一个知识型社区,它最关心的必然是网站内容的质量,所以如何规避低端问答一定是网站设计者首要考虑的问题。很多同类社区在发展初期由于比较小众,用户水平较高,即使出现低质量内容,管理员也能及时控制;然而一旦用户增多,内容覆盖范围扩大,这个问题就没法解决了。首先管理员根本来不及控制不断涌现的内容,其次他们也未必有那个水平去做判断。

StackExchange采用基于声誉值的管理制度则比较完善地解决了这个问题。初级用户不能点赞的设定,表明了网站对普通网民的不信任,这种不信任是合理的,毕竟有那么多曾经优秀的社区都被网络水军们给糟蹋了;你如果仅仅是来寻找答案的,那没问题,网站的一切内容全部公开,甚至做了SEO,你用Google就能搜到StackExchange的任何一个问答。但你如果想对StackExchange有所贡献,就不那么简单了,你必须证明自己具备这个资格,如何证明?提出好问题。只有好问题才会吸引人来作答,才会被人顶起,才能获得最初的声誉。

StackExchange对问问题有着严格的规定,比如提问前必须搜索已有问答,避免问重复问题,避免问与社区主题无关的问题,避免问范围模糊的问题;此外问题描述要详实具体,给出例证,要具有可重现性;语言方面还要过关,不能词不达意,也不能啰啰嗦嗦……这么多规定简直像是对学术论文的要求,规则制定者一定笃信只有好的问题才能引出好的答案。那么这么严苛的规定不怕把用户吓跑吗?不怕,因为吓跑的本来就不是StackExchange的目标用户群,这毕竟是个知识型社区,不是普通的社交网络,用户数量从来都不是它关心的,高质量用户数量才是它关心的。事实上,StackExchange的游戏规则非但没有吓跑用户,反而正在吸引越来越多的人参与其中。

在我看来,这种用户自治的游戏规则是最高明的管理策略,社区建设者只用把平台搭建好2,剩下的工作就交给广大用户,而真正愿意参与这个社区的用户都必然是认真对待的,声誉值越高的用户,责任感也越强,想要获得高的声誉值,就得懂得自制,按着游戏规则玩,慢慢积累。

你可能会奇怪,既然问个问题都如此麻烦,为何我还要在上面花费时间?原因有二。

首先,对于这种业界公认的知识型社区,由于它的干货比重远远超出同类网站,其用户的声誉值便也有了独特的含金量,就好比一个项目被fork的次数之于GitHub,声誉值在这里可以说明一切。你若能在自己的简历中写上Stackoverflow声誉值过万,任何一家用人单位都不会视而不见。

其次,并非所有人做什么事都要有所回报,这有点类似去问那些编辑维基百科的志愿者为何要花自己时间去做这种费力不讨好的事情。现在互联网上各种社区层出不穷,质量也是参差不齐,好不容易出现一个用户都那么认真对待的社区,当然倍受欢迎,因为这上面的讨论氛围是无可比拟的,一个问题问出去,可能几分钟内就有人回复,有的是指出你提问的不足之处,有的是给出可能有帮助的参考资料,甚至还有帮你纠正英语语法错误的……在这样的社区中,可能要比平时多花几倍时间才能完成一次提问,但你所收获的将更多。

这,才是真正的「人人为我,我为人人。」


  1. 其实这里拿知乎和StackExchange相比并不合适,因为知乎是模仿另一个问答社区——Quora——而建立的,这类问答社区本质上是互联网媒体,而非知识分享平台。 
  2. StackExchange的在线编辑器也是充满极客范,不仅全面支持Markdown,还有一些自定义的方便功能(参见这里),代码高亮、LaTeX公式插入一应俱全,让你提问和回答时不会有任何违和感。 

喜欢纯文本,就用Markdown

抛弃一切格式的羁绊,你才能自由地记录。

纯文本的好处

我虽然不是一个文字工作者,但也写过不少乱七八糟的东西,其中有一部分挂在了博客上,更多的则是写给自己看,我有一种独自叙述的欲望,至今依然保持着每天写日记的习惯。因此,许久以来,我也用过相当多的写作工具,一开始用的还是Word,可是很快就发觉了它的缺陷,除了在上一篇介绍LyX的文章中(参见这里)提到的Word的格式问题,还有一个不方便的地方就是通用性,当年云计算的概念还没有形成气候,Office系列依然固守桌面,这就导致在PC上写好的文档拿到别的平台难免会出现各种问题,譬如当年我就花了很大功夫在塞班系统里安装各种可以编辑doc文档的软件,最终使用效果也很糟糕。虽然现在Office云平台也整起来了,一个账号走天下,只要连上网,电脑里不安装Word也能对doc进行编辑,第三方工具的支持力度也越来越强,可是早年的使用经历还是给我留下了阴影,简单来说,就是对富文本格式的不放心。

所谓「富文本」,就是类似doc、rtf这样的文档格式,这种文档是高度封装的,你只能用专有工具(如Word、WPS)才能打得开,即使现在能访问它们的工具已经唾手可得,由于这种格式本身的商业属性,不能访问它们的工具还是占绝大多数;此外,由于这类文档的格式均由某个公司制定,当软件升级时,新旧版本迭代,兼容性问题便不可避免(应该有不少同学因为doc、docx的兼容问题而吃过苦头吧)。鉴于此,我将目光转向了纯文本,所谓「纯文本」,顾名思义,就是不带任何封装的文档格式,比如最为常见的txt格式,你用任何文本编辑器,比如Windows自带的记事本,就可以轻易打开这类文档进行编辑;而且最重要的是,纯文本的兼容性是最高的,你在任何操作系统上均能访问,使用任何编辑器均能改写,绝不会发生格式冲突1

于是我开始尝试用txt记东西,可是时间长了我就发现,txt的局限性还是蛮大的,如果仅仅是日记还好对付,但若想要插个链接做个列表之类的就麻烦了,那有没有既能用纯文本方式编辑又可以支持复杂格式的工具呢?有,比如LaTeX,它确实强大,简直无所不能,可是它更适合写大型文档,例如科研报告、学术论文什么的,日常记录如果用它,就显得太繁琐了,我可不想在一个文档里导言区整得比正文还长。

后来上GitHub时,注意到几乎每一个项目都有一个后缀为.md的readme文档,呈现在主页的下方,链接图片、分级标题一应俱全。我去查了一下这个.md到底是什么来头,于是第一次知道了Markdown的存在。这是一种轻量级文本标记语言,类似HTML,但要简易得多,我大概用了不到两小时就学会使用它了——这可能是世界上最简单的语言了吧。掌握了Markdown,我的纯文本写作才算步入正轨,即使在文本编辑器里写一些比较复杂的东西也不觉得难办了。后来用的熟练了,甚至在给别人发短信的时候也会不由自主地加上某个Markdown的标记语法。

Markdown入门

标记语言挺多的,能做到Markdown这样容易上手的不多见。其实Markdown的语法规定也不少(参见这里),但是基础语法就那么几条,而且非常直观,一看就懂,正如Markdown语法帮助中说的那样:

Markdown 的语法全由一些符号所组成,这些符号经过精挑细选,其作用一目了然。比如:在文字两旁加上星号,看起来就像*强调*。Markdown 的列表看起来,嗯,就是列表。Markdown 的区块引用看起来就真的像是引用一段文字,就像你曾在电子邮件中见过的那样。

下面给出具体说明:

  • 文档的标题分级通过标题前加不同数量的井号#来表示,一级标题就是一个井号,二级标题就是两个,以此类推,最多到六级标题(一般人用不到这么深吧喂);
  • 字符的斜体(正式说法叫「强调」)通过前后加单个星号*或下划线_完成,比如斜体表现;需要注意的是,无论是用星号还是下划线,前后都应保持一致;
  • 字符的粗体通过前后加两个星号*或下划线_完成,比如粗体表现
  • 如果是行内代码,可以用一对反引号(Tab上面那个键`)完成,比如code;如果是区块代码,则可以通过每行缩进四个空格或一个制表符(Tab)完成;
  • 插入链接,用这种语法:[链接名](链接地址)
  • 插入图片,用这种语法:![链接名](链接地址),仅比插入链接多了个叹号;
  • 无序列表需要在每一行前加星号*、加号+或者减号-,后面必须跟一个空格或制表符;
  • 有序列表(数字顺序)仅需在每一行前加数字和句点即可(任何数字均可,神奇吧,不过我还是建议你从1开始编号,省得把自己给绕晕了),同样后面要记得跟空格或制表符;
  • 区块引用通过在段落首行前加大于号>完成,而且支持嵌套(由>的数量控制嵌套层次);
  • 一行中有且仅有三个或三个以上的星号、减号或下划线时,这一行就是分隔线。

以上就是Markdown的基础语法,是不是已经涵盖了日常写作的一切要素了呢?

一些补充

对于编辑器的选择,其实如前文所述,只要是支持纯文本的都可,不过还是不太推荐Windows的记事本,主要是因为它不能方便保存为UTF-8编码,现在这年头各种文本编码出没,还是Unicode让人感到安心。这里推荐一个小软件——Notepad++,从名字就能看出来,是用来代替记事本的。这个免费软件非常好用,支持各种语法高亮,我平时查看Matlab代码就用它,打开大型文本文件的速度也是杠杠的。

如果想即时查看Markdown的排版效果,可以在Chrome中尝试这个应用,或者按这个教程配置一下。其实我觉得Markdown的语法已经足够清晰明了,通常用不到这些查看工具。

最后再推荐一个与Markdown无缝对接的写作平台——FarBox。我的博客目前就托管在这里。这个网站的运行机制很独特,有点类似GitHub,你只需在本地写你自己的东西,网站会通过网盘2定时更新并生成页面。你写的时候是纯文本形式,网页则根据你文档中的Markdown标记自动显示各种元素。修改也很方便,无需登录网站,仅仅在本地打开文本,改好后保存即可;数据备份就更方便了,你的所有文章就是一个个纯文本文档,都在本地保存着,你想放在哪就放在哪。其次,令人称道的是,FarBox原生支持MathJax,这样你就可以在文中直接敲LaTeX公式了(比如$E=mc^2$),而后网页呈现出来的就是矢量图形的数学公式,这种使用方式使得文本的复用性大大增强,同时又不失优雅。

这就是纯文本+Markdown的魅力,快捷、安全、省心,你值得拥有。


  1. 纯文本其实也未必不存在冲突问题,比如UNIX和Windows的换行符就不一致,只不过日常使用很难遇到这类问题。 
  2. FarBox所用的网盘是Dropbox,这就意味着,在GFW的干扰下,你除非挂上代理否则无法更新自己的文章。想想看,网站本身没被墙,内容同步服务器却在墙外……这是一件多么觳觫的事情。 

LyX——为学术写作而生

使用LyX的次数越多,我就越能察觉到用Word写论文是一项多么事倍功半的差事。

学习曲线的问题

我们在自学一个新工具时,总是不由自主地去衡量学习的成本与收益。所谓收益,自然是掌握这个工具后所能带来的好处,譬如做事效率的提升或者技能树上独一无二的新分支等等;而成本往往就是投入的时间。有些工具,不可否认,掌握它需要投入不菲的时间成本,而大多数被我们放弃的工具,则是被高估了学习成本。LaTeX就是一个典型。

我相信每一个接触过学术写作的同学肯定都听说过LaTeX这个专为学术排版而设计的语言,对其感兴趣的应该也大有人在,可是最终花时间学它的大概只是少数。为什么呢?因为LaTeX的学习曲线太「陡」了。拿使用人数最多的Word与之相比,在LaTeX中要想得到一份最简单的文档,也得先把文档类(class)指定好,需要调用的宏包(package)设定妥,然后\begin{document}才能开始正文,遇到次级标题了还得插入\section,文档结束了也不能忘记\end{document},颇为繁琐;而Word呢,开箱即用,上手就写,毫无障碍。

如此看来,那应该Word更佳啊,为何主流学术界那么不待见Word呢?因为Word的设计初衷就不是用来写学术文档的,它有些过于「自由」了。在Word的常规操作中,标题、段落、插图、间距等一切的排版规格都能轻易改变,而且往往还是在用户不明所以的情况下。有过撰写学位论文经验的同学应该都深有体会,在Word中调整格式简直牵一发而动全身,你按照学校的论文规范,把某一部分给改好了,结果另一部分乱了;好,现在你把乱了的部分纠正过来,其他地方又不对了;就这么改来改去,投入的时间都快赶上写正文的时间了,最后终于改完,送到学院形审,不幸发现了一点小纰漏,没办法,又是一通调整……最后,在deadline之前终于搞定,一切格式上的要求都满足了——可你已经被排版虐得死去活来,完全不清楚是如何摆平的。

以上这些问题,LaTeX几乎不存在,因为你在书写LaTeX文档时,无需关心格式问题。只要调用的文档类和宏包正确无误,那么最终的排版完全由程序接管,可以确保无误,你无法干预也无需干预。这种严格符合文档规范的特性使得它在学术界这个天生要求严谨的地方毫无争议地成为了事实上的标准文本格式。

可是,LaTeX真的不适合新手,对于那种近乎编程的文档书写方式,常年被Word惯坏的中国学生妥妥的接受不能。拿我自己来说,五年前,在我刚上研的时候,第一次听说LaTeX这种神奇的东西,就下决心要学会它,强迫自己用LaTeX写报告,结果一段时间后不得不放弃,当时我觉得是因为课程太紧而学习使用LaTeX又太花时间,现在看来,还是因为懒,因为我在那一年里貌似也悠哉悠哉地去了好些个地方游山玩水。这就是说,我并不是没时间学LaTeX,而是懒得学。

邂逅LyX

直到研二夏天,我参与编写一本专业教材,毫无悬念地,所用的编辑器是Word。结果这次编书算是把我给整郁闷了,我没有想到在与他人协作编辑一份学术文档时,Word是如此难用。你明明调好的格式,传给其他人后居然就全乱了,你插入的参考文献,格式、链接均工整无误,结果在另一台电脑打开,居然大相径庭……类似的种种莫名其妙的问题每天都会遇到,我们几乎每周的工作都要花大把的时间来处理格式和兼容方面的琐事,到最后也没有完全解决这类问题,只能勉强合并出一份排版糟糕的书稿。我对这本书的看法是,无论内容如何,任何人在图书馆若翻到这样一本格式混乱的书,大概都不会再看第二眼了。

这件事深深地触动了我,让我坚定了远离Word的决心,于是,我又重新捡起了LaTeX。这一次,我幸运地在CTeX论坛上看到了LyX这款神奇工具的介绍帖,仔细了解后,惊为天人——这货集中了LaTeX和Word的特长,既有「所见即所得」的使用界面,也有LaTeX内核的严谨排版基因——它几乎满足了我心目中完美写作工具的要求。

接下来,就一发而不可收拾了,LyX的设计者同时也一定是一位科研工作者,这款软件是开源的,已经有近二十年的发展史,在n多细节方面都是为学术写作量身定做的。仅举一例,LyX具有批量替换数学公式中字符的功能。什么意思呢?假设你正在写一篇paper,其中包含了上百个数学公式,独行公式和行内公式都有,快写完时,你发现其中有个变量A应该是B,文章中有大量公式都含有这个变量,这该如何是好……如果是Word,那就麻烦大了,你得一个个点开公式去改,没个把小时完成不了,太费劲了;如果是LaTeX的纯文本方式呢,也不行,因为除了公式环境,正文中的字母A也不少,替换的时候你还得一个个去确认,也够麻烦的;现在LyX来了,直接点开「高级查找替换」,勾选「Search only in math」,然后查找A替换为B,秒秒钟搞定。

类似的功能还有不少,我用LyX的次数越多,就越能体会到LyX设计者的良苦用心,有时候甚至会有一些感动,如此优秀的工具居然是免费和开源的。LyX让我对开源社区的好感和尊敬提升了一个等级。

上面唠叨了相当大篇幅的背景介绍,迟迟没有涉及到LyX的具体操作,其实这也是我的本意,我并未打算将这个系列文章写成「step by step」一样的说明书体,而是想将我所体会到的这些优秀工具的优秀之处讲出来,这其中当然避免不了会涉及到具体功能的实现,但那不是目的,因为你大可以去查help,那里面有更详细的解释。身为一个折腾过各式科研工具的「过来人」,我写这些软文一样的东西,目的——还真就是软文,我希望好工具能被更多的人用上。特别是这些优秀的自由软件,因为没有任何商业活动赞助,其受众非常有限,而我作为有幸接触到它们的一员,虽不能为完善工具本身做出什么贡献,至少可以尽己之力向别人推荐。我觉得既然我从这些分文不取的软件中得到了那么多的助益,就自然有义务为之推广。我小时候爱听单田芳的评书,里面常常提到一句话,叫做「无功不受禄。」

开始写吧

LyX是跨平台的,所以无论你是什么操作系统,都可以用。安装包可以从这个页面下载。

Windows下的首次安装可以选择Bundle版,也可以单独安装MiKTeX后再安装Installer版(其实LyX的Bundle版就是比Installer版多了一个MiKTeX,LyX需要调用LaTeX引擎编译,在Windows下,推荐用MiKTeX)。安装后往往MiKTeX会自动更新一些宏包,此时可以选择国内的镜像服务器(如中科大的)加快更新速度,完毕后在LyX的「工具」菜单中选择「重配置」,然后重启即可。

LyX安装后的设置可以参考我以前写的一篇文章:LyX中文配置 Tips

我总结的一些具体的使用技巧请参见这篇长期更新的经验贴:LyX Tips

如果你想生成漂亮工整的Beamer幻灯片,可以参考这篇配置:LyX Beamer配置 Tips

最简单的上手方式就是开写,英文文档直接写,中文文档按我上面给出的LyX中文配置进行设置即可。写完后点击LyX菜单栏下的那一双大眼睛图标(也可按快捷键Ctrl+R)编译一份预览PDF,你会发现这样的一份PDF从排版到数学公式的效果都堪称完美,不知比Word那蹩脚的样式好到哪里去了。

学术论文

LyX的主要受众群体就是学术工作者,虽然它也可以完成其他写作任务,并且完成得很棒,但由于它在学术写作上的优势实在太突出了,我这里就不再涉及其他领域。

以我比较熟悉的理工科来说,我觉得在学术写作中最重要的几个要素分别是结构层次、交叉引用、数学公式、专业图表以及参考文献。

其中文档结构控制和交叉引用功能在传统的字处理系统如Word中已经做得不错,LyX提供的也是类似的功能,相较而言,LyX的标签管理系统我个人觉得使用起来更高效一些。

参考文献方面,Word和LyX采取的解决途径截然不同,效果却大同小异,Word通常需要安装一个插件,比如收费的Endnote或者免费的Zotero,然后事先在软件中添加好文献,之后再通过运行在Word中的插件将需要的参考文献题录信息插入到文档中;LyX则是基于BiBTeX,也需要事先收集好文献题录,然后才能在文档中插入题录信息。我个人更喜欢BiBTeX的方式,因为它是纯文本的形式,无论是什么操作系统,是否有BiBTeX引擎,只要有个文本编辑器,你就能查看和修改,这种灵活性是无可比拟的。

而数学公式和专业图表方面,LyX具有压倒性的优势。这种优势是由两方面促成的,首先是质量,无论是无缝贴合正文的公式渲染还是多种数学环境的支持,LyX都能提供近乎完美的效果,当然这是由基于LaTeX内核的前提保证的。

其次是便捷,在我比较熟悉的几类可以拿来书写学术文档的工具来说,Word看似便捷,实则不然,你匆匆写就的doc文档,通常只能得到糟糕的排版,而若想得到靠谱的排版,又不得不投入大量时间细调。第二种是另一个极端,直接写LaTeX代码,这种方式的确可以保证排版水准,却只适合编程高手;天天和代码打交道,轻车熟路,没有问题;可惜大部分人还做不到看着代码脑海中就能想象出二维的数学公式而毫无违和感,所以往往直接面对LaTeX代码的后果就是常常要面对编译的bug,过于底层的操作,用户就不可避免要承担更多的任务。LyX恰好位于这二者中间,规避了各自的不足,借鉴了各自的优势,在使用LyX时,你的直观感受仿佛是在用Word,然而基于LaTeX的特性又使得它严格遵循着一定的排版规则,比如不能有两个空格,不能出现多余的空行,等等。这一切使得你在写文章时完全不必考虑格式,只需关心内容就好,格式排版这类机械工作由LyX替你完成,真正做到了「所见即所想」(What you see is what you mean, WYSIWYM)。

LyX就是这么一款近乎完美的学术写作工具,甚至用它来撰写完整的学位论文也毫无问题(参见我之前总结的基于LyX的论文写作,唯一遗憾的就是用的人太少,导致模板数量不足)。可能我对文档排版工整的要求有点近乎偏执吧,多数人可以接受Word的糟糕排版,我则完全无法忍受。然而LyX的特性却深得我心,现在,我日常的科研笔记、学术报告都是用LyX完成,几乎没再为文档排版问题烦过心。

最后再补充一下论文投稿方面的注意事项,对于有些期刊规定的TeX文档类,譬如Elsevier的elsarticle.cls,你可以在LyX中选择相应模版直接编译,也可以从LyX中导出为TeX源码后,再稍做修改,复制到期刊的模板中去。我推荐采用后一种方式,因为并不是所有的期刊模板都有LyX的对应版本,而且导出为TeX源码后,投稿什么的也会方便很多。

用Git管理你的代码

寒假回到家里,生活节奏一下子慢下来,我也仿佛突然多了一些回顾、总结的机会,过去几年的时间里,我陆续接触到一些很好的科研助力工具,这些工具有的是学术软件,有的是在线社区……无一不令我有相见恨晚之感。我打算利用空闲的时间,将这些得力工具一一介绍出来,供感兴趣的朋友参考。
作为系列文章的第一篇,我决定从Git开始。

背景介绍

对于一个经常和代码打交道的人来说,版本管理应该不是个陌生的概念,版本管理的最大作用在于它可以记录下代码的一切修改历史,从而一旦出现问题,可以快速找到出错的源头;当然对于多人协作的项目,版本管理更是必不可少的工具。

在众多版本管理工具中,目前最流行的应该是Git,它其实是Linux的创始人Linus为了更好地进行Linux内核开发而设计的版本管理工具,一经问世,便在开源界广受推崇,甚至著名的开源项目托管平台Github就是以此命名的。

我接触Git也是从Github开始,这个网站的设计简洁明了,很好上手,干货很多,而且常常透露出一股幽默劲儿。这是个不可多得的自学宝库,我在这上面长了不少见识,其中之一便是Git版本管理工具。虽然Github时不时会被GFW墙一下(对于GFW封锁一个技术网站的行为我完全无法理解),但我依然会借助各种翻墙工具去那里get一些新技能。

后来,由于有代码托管的需要,我不得不放弃Github的客户端(在GFW的干扰下其同步速度有时候简直慢得令人抓狂),很是无奈。一番寻觅后,一个堪称完美的替代品居然出现了:Bitbucket。后者在设计理念上与Github有着很大的不同,但是作为代码托管平台,它的功能已经非常完善,而且Bitbucket还支持免费的私有仓库(repository),这一点为它加分不少。Bitbucket有一个配套的本地版本管理软件,SourceTree,同时支持Git和Mercurial,本文即以SourceTree为例,简单介绍下如何用Git管理代码。

简单操作

SourceTree很好上手,它提供了Git一系列命令的GUI界面。

首先,「克隆/新建」(clone/new)按钮可以快速建立一个代码仓库,或者克隆一个已有的仓库;所谓仓库,就是一个授权Git监视的代码项目,Git会在对应根目录下建立一个名为「.git」的隐藏文件夹,尔后这个目录下的一切代码变动都会被Git记录下来。在Git的概念中,仓库有两种,一种是本地仓库,一种是远程仓库,像Bitbucket这样的网站就提供了远程仓库的托管;当然如果你仅仅管理自己硬盘上的代码,只用本地仓库也可。

创建好仓库后,就可以提交代码了。具体的提交流程是这样的:你用任意的代码编辑器修改代码后,返回SourceTree,此时SourceTree的「日志/历史」页面的Git图谱会自动出现「未提交的更改」字样,表明新的代码变动被检测到了,然后你点击「提交」(commit)按钮,页面转向「文件状态」,然后选中待定的文件,并在提交评论区输入相应的说明,接着点击页面右下角的「提交」,大功告成。

这就是Git的最简单应用,每次阶段性的代码调试完成后,都可以这么提交一下,Git会自动帮你将这些历史修改都完善地记录下来(精确到代码的行),日后需要查询的话就可以根据时间和提交说明来按图索骥。

假设第二天你想回到之前的代码版本,只需使用「检出」(checkout)功能,就可以返回之前记录的任何一个节点。

建立分支

以上仅仅是Git的单线程用法,Git的强大之处其实在于分支管理,不过由于我用的不多,只能略讲一二:假设我们现在已经搭建好主程序,然后需要若干子程序供调用。直接的想法是挨个写子程序,写好一个就提交一次,直到最终写完,但是这样的话,一旦子程序过多,我们便有可能自己搞糊涂先提交了哪个后提交了哪个,因为它们在单线程的逻辑上并无先后次序。一个更合理的方式是将这若干子程序的开发并列处理,大家谁也不比谁优先,同时进行开发,怎么做?用Git的「分支」(branch)功能。

Git建立仓库后有一个默认分支,叫做「master」,这是主分支,严格的程序开发者通常不会轻易变动主分支,而是划分出一系列子分支来进行具体的代码管理。对于我自己来说,由于平时也涉及不到大型程序开发,所以master也会经常变动,我并不觉得危险,但在进行子程序开发时,为了自己保持逻辑清晰,我还是会果断采用Git的分支功能。

这里需要注意一点,建立分支后,这个分支的一切操作都应该是与其他分支无关的,这一点非常关键。比如你就不能在A分支中随随便便就把B分支必需的文件给删了,否则如果B分支没有及时更新这个文件的话,那么合并到主分支后,B中的那个重要的文件就不存在了。我头一次犯这样的错误还腹诽了一下Git的设计,认为它不够智能——其实不是工具不智能,而是用工具的人思路不清晰罢了。分支功能本来就是为了提供一个并行不悖的开发环境而设定的,各个分支内的修改提交本就应该独立无关,你非要在这个分支里修改另一个分支的内容,不乱套才怪。所以有空要多写写程序,可以让你的思维变得更有条理。

说完了分支,接下来就是「合并」(merge)了,这个功能很好理解,指的是子分支开发完了,现在需要合并到主分支去。这里,我建议勾选SourceTree的「选项」菜单里「Git」选项卡中的「合并时不要使用快进方式,总是创建提交」候选项,如此,每次合并后,就会新建一个新的节点,便于日后查看。与「合并」类似的,还有「变基」功能,不过我用得不多,等以后更熟悉了再补充。

远程仓库

以上都是本地仓库的操作,在大多数时候就够用了,然而,如果你经常要在两个地方工作,比如宿舍和实验室,那么远程仓库就很有必要了,它可以保证你的代码永远处于最新状态;并且所有修改都存在云端,不用怕硬盘坏掉(顺带一提,我这人是个典型的同步控,喜欢搜集研究各种同步、备份工具,如果不是考虑到隐私问题,我可能已经把我所有的文件资料都放在云端了)。建立远程仓库可用Github平台或者Bitbucket平台,前者是全开源的,后者则提供私有仓库。

有关远程仓库的命令主要有两个:「拉取」(pull)和「推送」(push),前者是从远程仓库将代码更改同步到本地仓库,后者反之。具体使用时,最好遵循先拉后推的原则,以免出现冲突;这个习惯养好了,以后跟别人协作也不会出岔子。

关于代码版本冲突的问题,一开始遇到可能会不知所措。不必担心,Git有着比较完善的代码分析工具,可以明白标示出不同版本的差异之处,只是需要你花时间去比对罢了。或者用方便的「使用我的版本」和「使用他人版本」来快速解决(前提是你清楚哪个版本是你想要的);当然出现版本冲突问题,往往还是你写程序时逻辑没理顺导致的。所以,再好的工具,也只能帮你提高做事的效率,而无法代替你做本份内的事情。

关于Git,就先说这么多,我人懒,就不截图手把手地教了,这篇文字主要是介绍一个基于Git的版本管理概念和基本操作流程,你若有兴趣,去下载SourceTree,建立一个仓库花上两小时试一试,一切就都明白了。

关注

每发布一篇新博文的同时向您的邮箱发送备份。

加入另外 78 位粉丝