我在过去的几年中,写了 4 本书。有传统意义上的两本实体书:《JavaScript 核心概念及实践》和《轻量级 Web 应用开发》,还有两本电子书《3 周 3 页面》和《函数式编程乐趣》。当然对我而言,主职工作是软件开发,写作是个副业。
在写作的过程中,有一些 有趣的
心得。
学习过程
(至少是一个驱动你学习的动力) 写博客/文章和写书还是有很大差别的,一个明显的差异是写文章会比较随意,而且应该尽量保持精简。一篇文章提供一些信息即可,应该尽量远离细节(如果写一篇教程,则另当别论)。而写书则应该尽可能的深入细节,尽可能可以让读者依书自修。
首先要明白的一点是, 不要指望用写书来赚钱 ,至少前 4 本是这样的。粗略的算一下:我的第一本书卖了 3000 册,每卖一本我可以得到 4 元 RMB,一共就是 12,000 元 RMB。而这本书我断断续续写了三年。那是很多个周末,很多个假期,很多个夜晚的付出换来的,如果真正要计算投入产出比的话(纯粹金钱上),这显然是一个毫不合算的事情。
作为一个参考,IBM developerWorks 的投稿,千字 200 元,一般写5,000 字以内,也就是 800 元 RMB 左右。而要写一篇这样的文章,我只需要一天(当然需要数周/数月的积累)。12,000 元 RMB 需要写 15 篇文章,如果每周写一篇,不到 4 个月就可以写完,而且写文章比写书容易多了,毕竟篇幅比较短小,易于校对。而且对于大部分开发者来说,固定在一个主题上的难度要比 15 个独立的主题简单的多,因为无需特别深入。
所以根据经验,要抱着 公益
的情怀来写书。也就是说为了让知识更好的分享,让你学习到的先进科学技术来帮助更多的开发者,提高他们的开发效率,让他们可以在周末多休息一天。而至于翻译技术书籍,那基本上就是免费的了,完全是一个公益活动(耗时数月,斟酌字句,推敲表达方式,但是价格极为低廉:千字 60 元 RMB),所以下次见了技术书籍的译者,就多少给他捐点吧,他们才是在 为人民服务 。
“知识的诅咒”是指人们在获得了某种知识 之后 ,就无法想象 没有这种知识 的情况了。这种现象随处可见,比如一个你到了一个从未去过的陌生城市,遇到以为当地人,然后向他问路。当地人觉得已经说的很清楚了,但是你还是不知道该怎么走。另一个例子是:假设你不认识泰文,然后你打开任何一本 泰文
写的小说,你只能依稀感觉到这是一种文字,除此之外你并不能从中获取任何的信息。但是当你学习了一段时间 泰文
之后,再来看这本小说,之前的那种感受就再也没有了。
写书的时候,你首先需要具备某种知识。但是写书的目的是将这些知识传递给那些不具备此知识的人,而根据“知识的诅咒”,你又无法确知那些初学者会遇到哪些问题!解决这个问题的方法就是找初学者来试读。而且为了保险起见,还应该找尽可能多的人来试读。
一种方式是自下而上的,写一些独立的文章,最后发现可以串起来,然后形成一本书,另一种方式是自上而下,但是又会逐步调整。根据经验,不论是写一篇简单的博客,还是写一本书,都需要按照自上而下的方式。随心所欲的写下去,基本上都收不住,而且整个文章支离破碎,貌似有很多内容,但是不成章法,读者也无法轻松的获取知识。
先列出大的章节,然后逐步细化,但是未必是按照顺序来写。先编写自己最熟悉的部分,然后逐步完善。例子的选取需要精妙而恰当,最好有图例来说明。
一般而言,我在书中会使用两种图:流程图和一些截屏。截屏通常使用 Mac OSX 自身的功能就已经足够,而流程图我会采用一些额外的工具如:
用 Graphviz 画图的好处就是可以将图像代码一样放入版本库来管理。
除此之外,我还学习了一些设计软件的基本用法,事实上只需要用一些简单的元素就可以做出非常专业的配图:
书中实例需要很多代码来说明,如果是制作电子书的话,可以使用 Markdown 预处理器自带的功能来高亮。另外如果需要 RTF 格式,可以使用这些工具:
copy on steriod
这里有一篇博客来说明如何将你的代码带着格式拷贝到剪贴板中,拷贝之后,就可以将这些内容粘贴到 Word 或者 Keynote 中了。
jest.dontMock ('../components/headline.jsx'); describe ('Headline', function() { var React = require ('react/addons'); var Headline = require ('../components/headline.jsx'); var TestUtils = React.addons.TestUtils; it ('#render', function() { var text = "this is a title"; var headline = TestUtils.renderIntoDocument (<Headline title={text} />); var title = TestUtils.findRenderedDOMComponentWithTag (headline, 'h4'); expect (headline.getDOMNode ()) .toBeDefined (); expect (headline.getDOMNode () .textContent) .toEqual (text); }); });
坑
在写作的过程中,会有一些潜在的坑。这些所谓的坑是新人可能无法想到的。相对于言之无物,不知如何下笔,最痛苦的其实在于 平淡
。大部分时候,你可能很容易就能写出开头,但是很难坚持到最后。即使好不容易写完了第一版,后续的重读和修改,会让你苦不堪言。
内容写好之后,样式是下一个重要的问题,好的内容需要有与之匹配的排版。在中国,作者不但要负责内容,还要负责一些排版的事情。这一点非常奇葩,但是又是实情。这也是我更推荐电子版的原因(排版更加美观,选择更加多样,而且一旦有问题可以更容易的修改)。
另外一个问题是错别字检查!检查错别字对于作者来说,是一件非常困难的实情。而对于读者来说,则是一件很容易的事情。这跟 知识的诅咒
的道理一样。
传统的出版方式有一些明显的问题,这些问题已经和现代的知识传递方式产生了冲突:
传统的出版方式有点像传统的软件开发,一本书从开始写作到最终出版,要经过很多环节。忽略掉写作过程,从交稿到出版会经历很多次审核和校对,可能会历时4-8 个月,着这个过程中,很多东西都可能发生了变化,一个典型的例子是《用 AngularJS 开发下一代 Web 应用》,原版为英文版,翻译成中文版再到出版之后,书中的很大一部分内容已经过时。读者拿到书之后,会发现书中的内容已经和当前的版本/文档不匹配了。这种现状随着技术的更新速度和频率还会再加剧。
第二点是排版。我听说国内有些出版社已经开始接受 Markdown 作为稿件的格式,但是大部分还采用 Word 或者 WPS 等格式,这样排版就变成了一个大问题。以我自己为例,我的原稿用 Markdown 写,但是写了几章之后不得不切换到 Microsoft word 上,而我自己的 Mac OSX 下的排版到编辑的 Windows 下就会变样,而且还会涉及字符集,字体,Word 版本等等问题的影响,最后导致印刷出来和原始稿件出入很大。
最后一点是更新频率,如果发现了错别字或者错误的地方(即使之前检查过多次,仍然会有漏网之鱼),由于实体书的特殊性,一般需要等到再次印刷才能解决。这意味着先购买的读者会承担一些风险,更新后的版本又如何让读者看到呢?总不能又买一本吧。
但是这些问题都可以通过电子书来很好的解决。首先,电子书可以随时更新,最低限度的降低时滞性。排版上来说,作者可以使用 Markdown 来编写,而展现则可以应用一些预定义的模板来完成。最后,更新频率完全可以控制,对读者来说风险更低,因为电子版书籍的可以很容易的追踪交易记录,从而得到免费的更新过的版本。
目前已经有很多的渠道可以发布电子书,比如 gitbhook,知笔墨。这些应用的出现,大大降低了发布 书籍
的成本,我的《函数式编程乐趣》,用了 3 天就完成了草稿,而发布只需要数秒。
另外一个问题是书籍的价格和作者的收入。一本书定价 50 元 RMB,出版社给作者的版税是8%,也就是说,没卖出一本,作者可以得到 4 元,如果你的书非常畅销,这还是一个不错的价格。但是可能 90% 的书籍都不会是畅销书(就好比每个班级都会有优等生,但是他们仅占全班人数的 10% 一样)。这对作者是一种浪费:你需要耗时数月甚至数年来写一本书,然后市场的反馈又非常慢(毕竟你无法出版一本未完成的书)。
我在 selfstore.io 上有两本电子书:《3 周 3 页面》和《函数式编程乐趣》,《3 周 3 页面》定价为 16 元,每卖出一本,扣除掉交易费之后,我可以得到 14.7 元。
对我来说,这样可以得到更多的回报,对于读者则可以更加快速的得到更新,而且由于有预览版和一系列的其他信息,还可以在很大程度上降低读者的风险(更不用说快递费,等待时间等问题)。我在 gitbook 上的统计显示,《3 周 3 页面》已经被累计下载了 28,861 次,实际的读者也将近5,000。而且没有任何的审核流程,也没有排版的时间浪费,我只需要关注内容即可。