程序员如何写一本书?
2015-11-20 00:00
381 查看
我在过去的几年中,写了 4 本书。有传统意义上的两本实体书:《JavaScript 核心概念及实践》和《轻量级 Web 应用开发》,还有两本电子书《3 周 3 页面》和《函数式编程乐趣》。当然对我而言,主职工作是软件开发,写作是个副业。
在写作的过程中,有一些有趣的心得。
写作本身是一个很好的学习过程(至少是一个驱动你学习的动力)
写书非常枯燥,特别是校对的时候
写作不会让你变得富有,但是有时候会让你开心(不总是)
写文章 vs 写书
写博客/文章和写书还是有很大差别的,一个明显的差异是写文章会比较随意,而且应该尽量保持精简。一篇文章提供一些信息即可,应该尽量远离细节(如果写一篇教程,则另当别论)。而写书则应该尽可能的深入细节,尽可能可以让读者依书自修。
投入与回报
首先要明白的一点是,不要指望用写书来赚钱,至少前 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
keynote/sketch
用 Graphviz 画图的好处就是可以将图像代码一样放入版本库来管理。
除此之外,我还学习了一些设计软件的基本用法,事实上只需要用一些简单的元素就可以做出非常专业的配图:
字形/字体(大小,粗细的变化)
颜色(基本的配色理论就可以做出很舒服的配色)
层次(尺寸,位置,颜色的深浅)
阴影
代码格式
书中实例需要很多代码来说明,如果是***电子书的话,可以使用 Markdown 预处理器自带的功能来高亮。另外如果需要 RTF 格式,可以使用这些工具:
highlight 工具
intelij 中的插件copy on steriod
这里有一篇博客来说明如何将你的代码带着格式拷贝到剪贴板中,拷贝之后,就可以将这些内容粘贴到 Word 或者 Keynote 中了。
一些潜在的坑
在写作的过程中,会有一些潜在的坑。这些所谓的坑是新人可能无法想到的。相对于言之无物,不知如何下笔,最痛苦的其实在于平淡。大部分时候,你可能很容易就能写出开头,但是很难坚持到最后。即使好不容易写完了第一版,后续的重读和修改,会让你苦不堪言。
内容写好之后,样式是下一个重要的问题,好的内容需要有与之匹配的排版。在中国,作者不但要负责内容,还要负责一些排版的事情。这一点非常奇葩,但是又是实情。这也是我更推荐电子版的原因(排版更加美观,选择更加多样,而且一旦有问题可以更容易的修改)。
另外一个问题是错别字检查!检查错别字对于作者来说,是一件非常困难的实情。而对于读者来说,则是一件很容易的事情。这跟知识的诅咒的道理一样。
发布方式
实体书
传统的出版方式有一些明显的问题,这些问题已经和现代的知识传递方式产生了冲突:
时滞性(新技术的更新速度远远超过审批,印刷等流程的时间)
排版(如何低成本做到语法高亮,或者彩图)
更新频率(当技术更新之后,如何更新,是传统纸质书无法解决的问题)
传统的出版方式有点像传统的软件开发,一本书从开始写作到最终出版,要经过很多环节。忽略掉写作过程,从交稿到出版会经历很多次审核和校对,可能会历时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。而且没有任何的审核流程,也没有排版的时间浪费,我只需要关注内容即可。
via:insights.thoughtworkers.org
在写作的过程中,有一些有趣的心得。
写作本身是一个很好的学习过程(至少是一个驱动你学习的动力)
写书非常枯燥,特别是校对的时候
写作不会让你变得富有,但是有时候会让你开心(不总是)
写文章 vs 写书
写博客/文章和写书还是有很大差别的,一个明显的差异是写文章会比较随意,而且应该尽量保持精简。一篇文章提供一些信息即可,应该尽量远离细节(如果写一篇教程,则另当别论)。而写书则应该尽可能的深入细节,尽可能可以让读者依书自修。
投入与回报
首先要明白的一点是,不要指望用写书来赚钱,至少前 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
keynote/sketch
用 Graphviz 画图的好处就是可以将图像代码一样放入版本库来管理。
除此之外,我还学习了一些设计软件的基本用法,事实上只需要用一些简单的元素就可以做出非常专业的配图:
字形/字体(大小,粗细的变化)
颜色(基本的配色理论就可以做出很舒服的配色)
层次(尺寸,位置,颜色的深浅)
阴影
代码格式
书中实例需要很多代码来说明,如果是***电子书的话,可以使用 Markdown 预处理器自带的功能来高亮。另外如果需要 RTF 格式,可以使用这些工具:
highlight 工具
intelij 中的插件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。而且没有任何的审核流程,也没有排版的时间浪费,我只需要关注内容即可。
via:insights.thoughtworkers.org
相关文章推荐
- 黑马程序员-Java基础
- [.Net码农]MVC——入门+最简单的小实例
- 二十道前端面试题
- 黑马程序员——单例设计模式
- 如何做好一个面试官——之学习篇
- 求职者和面试官如何做好电话面试
- 一个老程序员PHP程序员说的话(看完后醍醐灌顶啊,醒醒吧程序猿们)
- 毕业典礼—一个程序员的成长史(4)
- 10+年程序员总结的20+条经验教训
- 面试时最常被问到的65个问题和技巧性回答(第一篇)
- 中级Java软件开发面试题以及答案(二)
- 10+年程序员总结的20+条经验教训
- 面试题47:不用加减乘除做加法
- 面试题45:圆圈中最后剩下的数字
- 面试题44:扑克牌的顺子
- 面试题42-2:左旋转字符串
- 拉低程序员工作效率的编程习惯
- 面试题42-1:翻转单词顺序
- 面试题41-2:和为s的连续正数序列
- 面试题41-1:和为s的两个数字