从下定决心要开始写书到今天，已经二周有余。在这段时间里，除了工作，剩下的时间基本上全部都是和这本书有关：写书、看书、查资料、思考......,几乎每天都是挑灯夜战到半夜1点。谁让我这么矫情，非要为了那份情怀和感情呢？
拟定目录和大纲的时候一共拟定了4个部分，大概有9-10章。开始我着手的并不是前言、也不是第一章、更不是最后一章或者后记，而是中间的章节：C语言特殊性与解决方案。这一章主要讲解C语言中比较特殊的、具有和别的语言不一样的特性语法、使用注意事项和解决方案，更有很多从坑中爬出来的经验分享。之所以要首先写这一章，主要还是因为以下几点：
- 我对C语言比较熟悉，其中几个经常用的特性都比较的清楚，经常会掉进坑里的陷阱也比较熟悉，我想用最快的速度看看在最短的时间内能写多少；
- 计算机语言写成的程序之所以能运行，和操作系统、编译器、连接器等基础设施密切相关，我也想粗略的估计一下经常使用的特性中，需要注意的特性有多少是和基础设施相关的，以好用最短的篇幅来写第一章关于基础知识的内容；
- 这一章在整本书的位置上比较重要，也是基础的章节，后面所有的内容都建立在这一章的基础上。虽然不是C语言的基础知识介绍，但这一章不过关，后面的章节也很难过关；
从申请内存开始，到释放内存，然后写stack溢出，再到c语言中的字符串。目前已经花了2周有余，但这一章还没写完。时间已经大大的超出了我的预估。按照我的预计，速度应该在一天写一节。这样，整章基本上也只需要一个星期，最多10天就能搞定。这完全是一种非常乐观的，没有写技术书经验的预估方法导致的（PS：以前写过口水书，类小说。）。和实际差的太远了。虽然一章还没写完，但是写到现在，总结如下：
- 难。虽然我对写技术书的难度在思想上有所准备，但真的开始写了，还是觉得有很多的准备不足。写技术书最大的难点在于：你怎么把你所知道的知识和信息有条理的、清清楚楚的、由易到难的晨晨展现给大家，并且可以让大家相对简单和容易的在短时间接受并且消化，如果知识点有相关的重点，如何向读者表述你所要表述的重点也是一个很重要的技巧，也是相当有难度；
- 多。技术书的工作量明显多于非技术书。IT技术书的工作量多就主要多在了有很多的示例上。示例的工作量简直就是要了人命了。特别是当示例有好几种可能性结果时，需要把这些可能性通过代码和环境的联合作用运行出不同的结果，n份代码和n个环境设置，想想这个工作量......,简直就是让人抓狂；
- 烦。一图胜千言，这句话在代码界中绝对是一顶一的真理。但是因为载体的限制，静态的载体并不能很好的表达出程序运行的整个过程，特别是一些细微的变化，比如指针的指向改变等等。只能把整个过程通过步骤化的方式，将步骤一步一步的静态化处理成图，然后尽可能完整的画出来变化额蛛丝马迹。整个静态化的过程和画图的过程相当的繁琐不说，静态化后很容易丢失一些关键信息。很多时候画了擦，擦了画，画了再擦......周而复始；
- 累。写书真的很累。没有自己的业余时间、没有休息时间、没有双休日，甚至连自己洗澡的时候都会去想下面的知识点要怎么写？这本书是不是还缺些什么特性或者功能没有？我这样写是不是能表达我的意思？是不是有更好的表达方式？然而当你的实际工作量大大超过你的预估的时候，你又想精益求精而准备返工的时候，你就会觉得更累了；
情怀和感情，人生中最大的乐趣。所以坚持，坚持下去......