在强大的程序背后，往往意味着更多的精力和时间去配置它， Vim 编辑器就是一个这样的程序。而我本人比较的懒惰，所以配置好就懒得再去修改了。

这是我目前的 Vim 配置（2007 年 12 月 20 日），我个人已经非常习惯使用它了。英文字体使用 Raize （ 详细见这里 ），中文字体使用 文泉驿 。

下载包里面还有一些语言文件和主题包，由于它们不是很大，就懒得精简了。其他的一些插件我没有包含进去，因为我想使用 Vim 的朋友已经有自己习惯的插件了。

另外，还不熟悉 Vim 编辑器，但是对它有兴趣的朋友可以看看 这里 和 这里 。另外，还有一个我找到的 Vim 的冷笑话 ，跑题了。

就这些，有兴趣的朋友可以从 这里下载 。

这是从 大脚社区 获得的一张令我深思的图片。

优秀的团队到底该拥有什么样的属性？也许很多人一时难以回答。但是至少有一点可以确定，团队如果都拥有了图中所列举的特点，那么，他们的前方还有什么问题能难倒这帮人呢？

我期待加入这样的团队。

上次对于 MySQL 方面已经有的 一些总结 ，但是昨晚 wiLdGoose 兄 说他也碰到同样的问题，但是无法解决。结果经过种种的假设和判断以后，到最后发现原来是 Zend Studio 的时区配置问题（我狂汗ing）。而在和他讨论期间也谈到了很多关于 MySQL 的细节问题，还是记录一下当作备忘比较好。这篇文章同时也做说服 wiLdGoose 兄用。

由于曾经和他是同一个团队的，所以对于其我很熟悉他那「洁癖」的做法，对于他的很多的观点我也非常的赞同；但是有一件非常不理解的地方就是设计数据库的时候总是会回避使用 Date/Time 类型。他的做法是将时间相关的字段设置为 INT(10) 类型，然后用 UNIX 时间戳来存储。而我本人对于这点做法非常的不赞同：

首先，是类型操作的不同，类似于 wiLdGoose 这样做法的「时间计算」实质上是整形之间的操作（而且这个整形非常大，长度为 10）。更有甚者，将时间戳设置为 VARCHAR(10) ，由此引发的效率问题不言而喻。

至于时间计算和整形计算乃至字符串的计算的效率问题， 这篇文章 非常能说明问题。

其次，是逻辑方面的操作问题。这是使用时间类型的优势，尤其是在需要高精度的项目上。比如需要「前一个星期的数据」和「获得从数据库建立以来每个星期一的数据」，这样的操作如用 wiLdGoose 兄的做法复杂度可想而知。

最后，就是直观不直观的问题，可以理解的是我们的大脑是不会直接将这一大串的时间戳转换成日期格式的。相比而言，直接使用时间类型明显就直观得多（它本身就是时间格式）。

而我目前的团队也还是在使用类似的方法。本人对于类似技术细节也 争执了良久 ，但由于岗位和决定权的问题，团队还是无法采纳本人的意见，甚为遗憾。

MySQL 定位为简单快速的 DBM 自然能迅速的驾驭，但是另一方面很容易造成不会深入下去的局面。对于此，我们更应该注意每一项的数据库设计细节，一项产品不断添加新的功能到最后都是面向应用的。

最后，附 MySQL 官方的 时间和日期函数的手册 。