在关闭了个人博客http://www.fluidea.cn后，我又有了写博客的冲动。这回就不打算再去折腾自建网站了，直接用别家的服务省事。
一个技术人员，学习一门新的技术时，必须要看文档和教程。在网络上，充斥着各种各样的教程，微博也好，论坛也好，到处都是信息资源，但要找到一个优秀的教程并不是件容易的事。要深入掌握一门编程语言，或者一个技术点，必然要经过系统的学习，仅仅依靠看几篇零散的技术文章，没有可能构成自己的知识体系。
写书的体验让我构建了系统的知识体系
在写第一本书《Flex第一步》时，对"教程应该怎么写"这个问题并没有什么想法，只是下意识地凭借着阅读经验和个人的工作经验完成了这本教程。现在回过头去看，觉得这本书的结构凑合，内容也还算合乎逻辑，但仅此而已。如果有用更高的标准去衡量，就会发现这本书非常浅薄，自己的东西很少，完全是硬技术点的堆积，典型的短平快教程。
三年后，写《AIR Android应用开发实战》时，应该说对写书有了更深入的认识。在前期设计目录、准备素材的过程中，一直想着在书中怎么体现更多的内容，特别是自己的开发体验。安排内容时，考虑到AIR移动开发主要以游戏为主，因此有意识地添加了游戏的元素，去除了新浪微博客户端这类应用例子；另外，为了让书不那么平庸，也尝试加入了更多的知识点，扩充宽度。总的来说，这本书和我的最初的计划差不多，个人比较满意。
在书即将审稿结束时，Stage 3D开始支持AIR Android，这让我一度很是纠结。如果要补上这块，书店印刷时间又要往后拖，当时已经比计划出版时间晚了几个月。时下Flash业内寒流涌动，Adobe更是昏招频出，让我实在鼓不起勇气继续写下去。也算是一个遗憾。
这两本给我带来了很大的收获，不是经济上的（收入少的可怜，特别是第二本），而是让我建立了一套知识体系。明白一个问题和向其他人讲清楚这个问题，这其实是两回事。清楚地阐述一个问题的前提是理解这个问题的前因后果，为什么要这样做？有没有其他方法？这个方法的优点在哪里？
写书必须有严谨求实的态度，对一个技术点如果自己也是模棱两可，就轻率地告诉读者，这是不负责任的表现。
重构经验，形成系统
像我这样，从事编程快十年了（说起来惭愧，到现在一事无成），各种项目，各种技术都有接触，但都是些很零散的知识点，没有系统。知识的系统化非常重要，如何去系统化？那就是写出来。写的过程中，自然会去思考，重温，归纳，总结，最后化繁为简，循序渐进地倒出来。
一般我们了解一个事物，习惯按照：是什么-为什么用它-怎么用，这条路去学习。但现实是，技术人员似乎越来越浮躁了，总是想走捷径，直接从“怎么用”这步开始。其实这没有不好，但经过一段时间后，一定要回头把前面两步走一遍。一件事物的本质，看似简单，却代表这它最根本的意义。如果我们不清楚自己行为的含义，又怎么能把握前进的方向？