《Apache源代码全景分析》

上半年好像我写了不少推荐序。《Apache源代码全景分析第1卷》已经面市一段时间了。读过这本书的电子稿，先睹为快之后写下推荐序。

如果说没有 Apache 就没有 Internet 可能有些夸张，但至少可以说没有 Apache ，互联网不会发展这么快。根据互联网研究公司 NetCraft 的统计，多年来 Apache 一直是稳居 Web 服务器市场头把交椅，至今仍占据超过 50% 的市场份额。就整个互联网来说，Apache 仍然是最重要的软件之一。

尽管近几年来涌现出不少以”高性能”为卖点的新的 Web 服务器软件，比如 Lighttpd 、Nginx 等，吸引了不少用户注意力，不过 Apache 因其功能广泛，有些仍具有不可替代性，在技术领域仍然是 Web 服务器风向标。话说回来，”重剑无锋，大巧不工”，有的时候软件性能表现不佳，更多原因可能是对其了解不够、使用不当造成，并非软件自身有多大缺陷。对 Apache 来说，更是如此。所以，通过分析源代码了解 Apache 软件架构体系，熟知其本质，方能更有效的使用 Apache Web 服务器，从而发挥出最大效能。为网站节省资源，为企业节省资金，也能为用户提供更好的访问体验，好处多多。

此外，随着互联网业务的复杂化，很多网站使用 Apache 的过程中也遇到了新的挑战，常常要在业务的驱动下对 Apache 进行扩展性的开发(例如扩展日志模块以便于更复杂的日志统计)。这个时候，源代码分析是绕不过去的一件事儿，尽管源代码获取是轻而易举之事，但 Apache 代码毕竟凝聚了开源软件界的群体智慧，要想高效分析却是并非易事，相信这本书能让有此需求的读者少走弯路，剥丝抽茧，获得更多启发与借鉴。

说起源代码分析，其实几年前市面上出现过一些此类话题的图书，不过基本上是印上大段源代码加上几句注释了事，读者可能会有吃到注水猪肉的感觉。而本书的读者对这一点大可放心，书中代码只是点到即止，相对环保多了。

后记：此书编辑够用心的，这里这个案例可见一斑。

–EOF–

《MySQL性能调优与架构设计》推荐序

阿里巴巴 DBA 团队简朝阳的大作《MySQL性能调优与架构设计》已经开始正式上市。我刚认识朝阳同学的时候，他还刚刚毕业，短短两三年后，已经能够独当一面，应该说阿里 DBA 团队是个很锻炼人的地方，当然重要的是他的刻苦钻研的劲头儿。早早就看过他的初稿，这本书是他倾力之作，有理由大力推荐。下文是我前一段时间写的推荐序。

拥抱MySQL数据库技术

时至今日，恐怕已经没有人再把 MySQL 当成一个玩具性质的软件产品，即使是数据库市场执牛耳者如Oracle公司也不得不正式面对来自MySQL的冲击。如果说几年前，还有人对使用MySQL 有所疑虑么? 经过几年来互联网的高速发展，无数大型网站用其成功案例证明，以MySQL为基础的数据层解决方案已经成为互联网应用不可或缺的一个重要组成部分。

当下也是数据库技术应用处于激烈变革的时期。这并不是说传统的关系数据库技术在这两年有了多大的新突破，而是用户的需求在迅速变化。更多时候，用户不再需要单一的软件产品，而是灵活、高效、可靠、可控、低廉的解决方案。很多大型站点甚至根据自己的需求来改进 MySQL，进而回馈给开源社区，这也是开放的魅力所在，对于传统的商业数据库软件商来说，这是不可想象的事情。

MySQL早已不再是单一的数据库软件，以其为基础发展起来的各种开源组件令人目不暇接，而用这些组件构成的解决方案也是层出不穷。如何能够把以 MySQL为核心的这一系列软件充分运用，构建大型可扩展性网站，正是不少LAMP架构体系的网站开发者乃至架构师一直关心的问题。现在中文图书市场上 MySQL相关的书籍并不在少数，但放眼看去，绝大多数是教程类的内容，这本《MySQL性能调优与架构设计》则主要着眼于性能与架构这两个当下大家更为关注的话题，结合作者几年来的实战经验与研究心得，相信能让不少网站少走弯路。

期待这本书让更多人受益。如果读者朋友们也能把自己的心得分享出来，那是再好不过的事情了。经常有即将毕业的学生以及网络上的朋友给我发来邮件，表示对数据库技术有兴趣，但是不知道如何切入，我的建议是，从学习MySQL开始吧！

–EOF–

比好更好

昨天的”电子商务和产品设计沙龙，暨 BetaCafe开业酒会“非常顺利，非常成功，发自内心的感谢各位朋友的支持! 很欣慰，这半年的又一件事情做完了。

这半年来，做了几件吃力不讨好的事情。不过想想郭靖给我讲的一句话，”你觉得这事情有价值没有? 有的话就去做!” 让我感悟颇深，也坚定了许多。一件事情是否有价值，不能只看别人的评价。

这些天几件事情并发的进行，感觉非常累，无论是工作还是个人生活上的事情，单独一件都能把自己搞得特别疲惫。有的时候要做点决定不是那么容易的事情，总有一些出乎意料的事情发生。

接下来尝试恢复到以前的状态，开始写点东西。这段时间更新并不频繁，好几个朋友都提及过这个事情，”现在写的没有以前好”。但我有什么办法?

–EOF–

关于团队 BLOG 这件事

现在网络上已经可以看到很多公司的团队对外的 BLOG ，关于这个话题，在这里记录一下我的一些个人看法。当然贵团队如果已经开博或者即将开博的话，毋须照搬，这不是什么指导。

明确团队开博目的

首先必须确定要传递哪些信息给读者? 宣传公司团队文化? 技术宣传? 产品宣传? 还是兼而有之? 如果只是为了跟风，那就没必要的。实际上，我相信大部分团队 BLOG 不过是跟风而已，不过跟风跟的好，也能起到不错的作用。如果能认真经营 BLOG ，它就能给你带来价值，超乎你想象的价值。

一般而言，建议对外开博前，可以在内部先试运行一下，给大家熟悉网络环境一个缓冲期。

不与业绩指标挂钩

据说很多团队的 BLOG 居然和 KPI 挂钩的，这是非常不适合的做法。很明显这会导致一个现象：到了接近考核的时候，团队每个成员都流水帐一样连发多篇文章凑数，对读者来说，是一种信息轰炸，起不到什么正面作用，对团队多数成员来说，也觉得这样圆满完成任务也不错嘛，势必影响真正用心写文章的成员。当然我相信很多人看了我这个帖子后会改变 KPI 的设置方式，比如”每月要发布几篇”… 简言之，本末倒置。

控制文章发布频率

团队 BLOG 管理员(没错，应该有个管理员)应该控制文章正式发布的频率。细水长流，尤佳。记住，节奏最有力量。

控制频率的另外一点是要做好长期性准备，不要几天热乎劲儿过去之后就乏于更新。如果潜在读者偶尔访问过来，发现最近一篇更新是一年前，或许就会留下负面印象。

不要强制团队成员

必须要认清的一件事情是，一个团队中，肯定有些人员的确不善于文字表达，如果要他写一篇文章，可能比杀了他还更难受。如果强制性的压着他憋文章，恐怕只能适得其反。好的方式是发起者能够引导团队成员中的那些低调者，使他觉得这事情有意思，可以尝试一下，能够更多锻炼自己。比如针对技术人员来说，写文章过程中如果熟悉一下 HTML 基本语法，在日常工作中也不无裨益。

不要堆砌垃圾文章

这里面的一条铁律是：不要转贴那些网上随处可见的”心得”，”感悟”之类的心灵鸡汤文章，那些文章不能改变外界对你团队的正面看法(当然有可能增加负面看法)。适当的转载关于自己团队或者公司的第三方文章是可以接受的。

记住，垃圾信息和网站质量成反比的。信息不是越多越好。

内容格式非常重要

内容是团队向外展示的载体，固然重要，可如果文章不经过很好的格式化，就好比一块好田地长满了庄稼也同样长满野草一样让人讨厌。这是如此简单的一点，但我们还是能看到有许多团队对此熟视无睹。一篇连段落都不分的技术文章内容再好，也不会有更多技术人喜欢看。

不但 Web 页面要注重格式化，对 RSS 输出也同样也要注意，甚至应该更加以重视。至于输出全文，那是必须的。团队 BLOG 不要在乎什么 PV 之类的事情，那是非常土鳖的做法。内容是否有价值，不在于有多少人看了这篇文章，而是有多少目标读者从中得到收益。

–待续-