Dec
12今天升级 Discuz，从 Discuz 6.1升级到 Discuz 7.0。
按照官方的升级文档，先把 UCenter 升级到 1.5，然后才能升级 Discuz。
为了稳妥起见，我把服务器上的程序和数据库都备份到本地，升级一下试试。
果然遇到问题，在升级 Discuz 的时候，运行 upgrade11.php ，结果得到下面的提示：
“您目前 UCenter 的程序文件还没有上传”
后来 Google 了一下，官方有人发帖询问了。
受到启发，可能是 UCenter 的 IP 设置不对。
打开 Discuz 目录下的 config.inc.php，找到 “UC_IP” 的宏定义，把它改成本地 IP：127.0.0.1。
问题解决，成功升级。
顺便说个问题，我在 Google 搜索 “您目前 UCenter 的程序文件还没有上传”，第一条就是结果，显示的是 2 小时前最新抓取的，同样的字符串，在 百度 却没有搜到……
Nov
29今天刚发现一个问题，PHP连接MySQL的时候，不同环境的localhost会有不同的结果。
我的服务器装了2套PHP，其中有一个是用源码编译的，另一个是xampp集成包。
编译的php用于生产环境，xampp用来建立测试环境。
把线上的代码放到测试环境下，居然报告无法连接MySQL！
刚开始以为是端口的问题，可是我在命令行下怎么连接都没问题。最后抱着试试看的想法，把localhost改成了127.0.0.1，这回居然成功了。
我不能理解，线上代码运行的好好的，配置文件就是localhost呀，怎么到测试环境就必须改成127.0.0.1才行？
两套环境，主要的区别就是PHP，虽然版本都一样，不过xampp是编译好的，我估计问题出在这里。
然后立刻写了一个测试程序：
$connA = mysql_connect(’127.0.0.1:3306′, ‘leakon’, ‘pass’);
$connB = mysql_connect(’localhost:3306′, ‘leakon’, ‘pass’);
var_dump($connA);
var_dump($connB);
在命令行下分别用编译和xampp的php执行上述代码，果然发现两项结果不一样。
后来分析了一下，按照这种方式理解：编译PHP的时候需要指定MySQL的安装路径，这个时候localhost就指向对应的MySQL。与编译版的PHP不一样，xampp指向的是随包附带的二进制版MySQL，因此他发现这个MySQL的root密码不对，拒绝连接。
但用127.0.0.1作为主机地址时，PHP就不会按照编译的localhost找MySQL服务器，而是根据端口来找，这回就没问题了。
同时也发现了一个问题，当用localhost:port作为主机地址时，PHP会忽略端口号！
不信你试试上面的代码，那个port写成什么都无所谓，只要是localhost，就会链接特定的MySQL。
不知道为什么，就当经验，记住这个事实吧！
本文主要讨论的就是导航tab的底部灰线如何用CSS实现，而不是用背景图片实现。用CSS实现的好处是可以避免浏览器发起一次图片请求，另一个是可以方便地改变颜色、尺寸。
做法是用ul和li标签生成tab，在ul的外部用p标签包围，导航底部的那条细线，就是p标签的bottom-border。
过程中遇到的一个难题是，高亮的tab，是白色背景，该tab底部没有border，应该也是白色的。但用普通的方法没法做到，如上面第2个图，“首页”那个tab的出现了底部border。因为p标签是ul和li的外层容器，内部的所有元素默认都在p标签的范围内，无法跨越p的边界。
通常这种导航的底部实现都是用背景图片代替，这样的理由是：1、背景图片的位置可调，可以不用紧紧挨着边框，比如离bottom有4px的距离；2、背景图片显示在最低层，p容器内的任何元素都可以覆盖住背景图片。高亮tab的底部没有border的效果就是靠白色背景挡住了p的背景图片做到的。
基于这种思想，我考虑可以用什么方式让内部元素挡住外层元素呢？
ul元素的position属性设置为absolute，p标签的position设置为relative。这样ul就定义在p标签内浮动，默认top和left都是0，即p的左上角。同时，ul会覆盖住p。只要p的height刚好比ul的height小1px就可以，也就是让ul中li的bottom-border刚好和p的bottom-border在同一个垂直高度上。注意，p标签的overflow属性必须是visible（默认值），也就是说只要你不把overflow设置成其他值就没问题。
经过上面的步骤，可以总结出几个关键点，按重要顺序排列：
通过这几个关键点，你就可以基本实现图1的效果，不过还要针对不同浏览器做小小的css hack。
hack的关键点就是p的height值，在我这里，Firefox2/3、Chrome、Opera适合27px，IE7、Safari适合26px，IE6适合25px。
现在我唯一的问题是不知道怎么写出专门适用于Safari的CSS定义，所以在Safari下是图3的效果，其实就差1px，回头找到方法再补充吧。
Nov
22百度公关
因为没给某个电视台交保护费，就遭到连续2天的恶意报道，说百度为了利益而改变搜索引擎的排序结果，误导网民，甚至还说什么会影响互联网产业。不管说的对不对，我看那个电视台想说的意思是：百度收了钱才办事儿，不给钱不仅不办事儿，甚至给你屏蔽了。那么我反过来看看那个电视台的行为：给了广告费就帮你忽悠，不给广告费，不仅不给你忽悠，还给你栽赃陷害。如果说百度会影响互联网产业，不知道那个电视台会影响什么？我估计会影响中国的持续发展。不如把这个电视台新盖的楼送给百度，呵呵……
Gmail 主题
Gmail 可真是个好东西，我现在真不敢想象，如果没有 Gmail，我的生活将会受到什么样的影响。现在可以换主题了，我觉得可以吸引很多普通用户，让他们从其他邮箱转移到 Gmail。不要小看换皮肤这个功能。如果你是一个实用主义者，似乎对这类功能不感兴趣。确实，Gmail 最开始是以实用为主的，面向的也都是有经验的互联网用户。当 Google 满足了这部分高端用户的需要后，就开始向更大范围的普通用户下手。看看百度空间，提供了用户自定义CSS的功能。再看看有多少用户创建的模板，数以万计。有人说百度空间有点娱乐型的感觉，比较适合普通用户，尤其是年龄较低的用户。也许 Gmail 的这次开发主题选择，也是为了这部分用户吧。
用户研究
最近又讨论到用户，又说起创业公司的第一步应该怎么走。当我们几个人坐下来讨论，各自为了证明自己观点的正确性而引经据典时，突然发现，这些前人总结的真理，都是正确的。说起如何选择方向的时候，我提出了一个观点，就是创业的初期应该是2条路：1、创业者选定一条自己最擅长的领域或方向，在这个领域潜心钻研，深入探索，然后做一些针对性和目的性很强的用户调研，来为自己设定的目标提供修正或参考；2、创业者有一个“万能”的团队，就想 Jeff 引用的一句话 “创业成功的三要素：Team、Team、Team！”，不管他们选择什么方向，有这个 Team 就保证了成功，至于方向，可以从用户调研中选择一个可行性最高的。
讨论方式
我们在吃饭的时候总会有很多讨论，最有意思的是，本来很激烈的辩论，到最后，突然发现彼此的观点是一致的，呵呵，都不知道之前在争论什么。昨天总结一个方法：在讨论问题时，不要说“对与不对”或“正确与否”，只叙述自己的观点，力求让对方完全理解你自己的本意。其实大家好多的分歧都存在于没有理解彼此的本意，或者说理解不够完全。这也导致会议总是没有休止。
做事深潜
在尝试性地开发一个新功能的时候，应该把这个功能做到尽善尽美，然后再去尝试另一个功能。这里不是说孤注一掷地死死盯住一个方向。我的意思是即便这个功能只能帮助用户完成一件事，那也应该把这一件事彻底解决好，不要有遗留的bug，不要有用户体验上的不友好。功能可以简单，可已单一，但绝不可以不能用、不好用、不易用。本来尝试着开发这个功能就是为了从用户那里得到反馈，让用户帮忙，从用户那里挖掘出更深层次的需求。如果只是浅尝辄止，那从用户那里得到的信息就没有什么实际的意义和价值了。这个时候急于投入下一个功能的开发，等于又是一次轮回。当你浅浅地尝试过N种选择后，得到的结论很可能就是这N种功能都没有用，没有用户喜欢。
我始终坚持我的看法：没有冷门的领域，没有冷门的方向，没有冷门的功能，只有不够深入、没有创新意识的设计者。
如果长时间地专注在某个你比较擅长的方向上，你对这个领域的感悟和理解就会比别人深得多，你能挖掘出来的用户需求也会比别人多得多。就像中国的一句古话：样样稀松不如一门精通。
期待下周……
Nov
21做 rsync 远程同步文件的时候，总要输入密码，没法做自动运行。查 rsync 的使用方式，用 –password-file=/home/leakon/secret/rsync.pass 这个参数也还是不行，有人说改文件权限为 600，有人说文件里面只写密码，不要写成 user:pass 的格式。反正怎么试都是不行。
只能寻求建立 SSH 信任关系跳过密码的方式来同步文件了。
本来以前查资料，搞定过用 SecureCRT 不要密码登录 FreeBSD 的，详情见：http://www.leakon.com/archives/55
但到了服务器之间，我还没成功过。
查了好多资料，让人难以理解的表达能力和我自己笨到不行的理解能力，实在看不太明白。
现在我还是说清楚一点吧，我的目标是，在 home 服务器 ssh 远程登录 office 服务器时不必输入密码（帐户名都是 leakon）。
那么，我要在 home 服务器上用 ssh-keygen 生成密钥，rsa 或 dsa：
leakon@home shell> ssh-keygen -t rsa
一路回车，会在 ~/.ssh/下生成 id_rsa 和 id_rsa.pub ，分别是私钥和公钥。
然后，要把 id_rsa.pub 的内容追加到 office 服务器 ~/.ssh/authorized_keys 的尾部：
leakon@home shell> scp ~/.ssh/id_rsa.pub leakon@office:~/leakon_random_rsa.pub
这里改名公钥文件是为了避免覆盖 office 端的同名文件。
登录 office 服务器，把新的公钥文件加入到授权文件中：
leakon@office shell> cat ~/leakon_random_rsa.pub >> ~/.ssh/authorized_keys
注意，请检查这个 authorized_keys 的权限，应该是 600，如果之前不存在，那么创建文件默认的权限是 644，这样是不行的，很多情况下加完授权文件后登录还需要密码，就是因为这里权限不对。
注意，公钥文件添加到了 office ，私钥文件也应该添加到 home 的身份文件中。实际上，只要 id_rsa 这个文件存在于 home 的 ~/.ssh/ 下就没问题，但容易被不小心覆盖，所以应该添加到 ~/.ssh/identity 中，这是与 office 端的 authorized_keys 对应的私钥文件：
leakon@home shell> cat ~/.ssh/id_rsa >> ~/.ssh/identity
注意文件权限也应是 600。
通常这个时候就搞定了，在 home 登录 office 不需要输入密码了。
如果还是不行，下述方法可能有帮助：
Nov
20简要提纲
Part 1
在支持 DOM2 事件模型的浏览器上，给元素绑定事件要用 addEventListener 这个方法，他有第 3 个参数：capturePhase。手册上的说明没太看懂，就自己做了个测试（在 http://leakon.googlecode.com/svn/trunk/leakon/javascript/event_phase 可以看到代码），明白了 true 与 false 的区别：当已注册的事件在某个节点上发生时，会按照某个顺序传递下去。true 指定由根节点向叶子节点传递，false 指定由叶子节点向根节点传递。
举个例子，有个 div，内部有个 img，2 个元素都注册了 onclick 事件，分别调用不同的处理函数。当你在图片上点击鼠标时，div 和 img 哪个先触发，就靠这个 capturePhase 来决定。div 是 img 的 parent，如果设置为 true，就是 div 先触发，然后才是 img。
不过一般来说都是设置为 false，即由叶子向根传递，因为 IE 就是这样做的，而且貌似不能改变顺序。
Part 2
还是父子节点事件处理的问题，这回讨论 onMouseOver 和 onMouseOut 事件。借用上面的例子，div 内部是 img。我们只给 div 注册一对 onMouseOver/Out ，当光标从 div 部分（这里假设 div 很大，而 img 只占 div 较少一部分面积）经过 img 的边框进入 img 面积内时，会先后触发 div 的 2 个事件：onMouseOut -> onMouseOver。也就是，div 认为鼠标是先离开 div 然后又立刻进入。
换到一个实际的应用场景，比如我们添加 Over 和 Out 事件就是为了给 div 添加一个高亮的样式表，div 背景默认是白色，鼠标划过变成红色，出去后恢复成白色。
要是你在 Over 和 Out 处理函数内部仅仅是 addClass 和 removeClass 这么一下，那你会看到跳动的感觉，也就是鼠标按如下路线行进：inDiv -> inImg -> OutOfImg -> inDiv ，别看鼠标一直在 div 内部，你以为不会有 onMouseOut 事件，事实不是这样，光标进入 img 的那一瞬间，就先后执行了 Out 和 Over 函数。而且，有些情况下，后续的 Over 函数没能得到成功执行，现实是 div 的样式表移除后就没能再添加上。
Part 3
这个问题大家应该早就知道，只是我今天才发现。我以为 document.getElementById() 跟 DOM 节点当前的样式无关。今天给一个 Element 注册事件的时候发现找不到该节点，原因是那个节点的 display 样式设置为 none。
按说不应该是这样，可能跟当时运行的环境有关，也可能是我绑定事件的函数有问题，总之看到的现象是跟样式定义有关。总结在这里，以备日后回忆，参考。
我现在觉得 Javascript 最难的就是事件处理这部分了。这里的事件不是简单地给某个 div 绑定一个函数来响应鼠标点击，而是一整套的处理流程和逻辑。
事件发生源、事件类型、传递方向、再哪个节点上应该停止传递，等等。
当页面中元素很多，关系错综复杂时，就需要一个事件处理框架来帮忙。我们需要的是结构清晰逻辑合理的代码，而不是满篇重复地 if else 判断。
举个简单的例子，如果你做一个邮件系统，类似 Gmail 那样的，你每点一封未读邮件，或者给某些邮件加上 tag，都会触发一系列的关联事件，例如要把未读邮件总数减少，给 tag 列表里添加新项目，同时用突出的颜色高亮选中的邮件标题，还要在页面顶部给出处理成功的提示，甚至还要问用户是否要撤销刚才的一系列动作。
天啊，看这 2 行文字描述我就觉得很晕了，把他用代码实现出来，并处理各种异常，还要保证代码的可读性，我只能说我自己能力还差得太远太远。
前两天听说 MooTools 这个 Javascript 框架在面向对象方面做的不错，当项目越来越复杂时，按照 MooTools 方式来组织代码可以有很好的可维护性。
找到了电子书，已经放到 blog 中可以下载了。
Nov
12Jeff刚刚仔细读过《赢在用户》-WEB人物角色创建和应用实践指南，书评可以到豆瓣看看：
http://www.douban.com/subject/2157554/
他说，我们现在缺乏一套用户角色模型。这本书里面提到一个网站首先要建立起一套对应的用户角色模型，知道自己要给哪些用户提供服务，然后再根据不同类型用户的需求制定项目优先级。如果没有这套模型，那么我们会总是遇到这样那样的产品问题，针对这些具体问题的讨论将会永无休止。因为这样的讨论不是基于一套被每个人都认同的概念标准的。
比如，Jeff用1天时间搞了几个单机版的Flash小游戏，作为一个“游戏”模块挂到“应用”分类下面。我觉得，这项功能跟我们的网站毫无关系，没必要在这上面浪费时间，哪怕是1分钟都不应该。而Jeff说他确实听到了用户有这方面的需求。
这就是问题的根源，我们的网站要做什么？要给谁提供服务？想玩游戏的用户是不是我们的“重要”用户？
如果我们确定好了用户角色模型，统一了意见，知道我们主要为谁提供服务，那么这个问题就好解决了。
他还提到，当网站增加了一项新功能时，会给四类用户带来不同的反应（我记得大概是这几种）：
这本书我没看过，我今天要说的也不是书里的内容，我是有另一种感觉，需要我用插叙的方式引入我对“规律”二字的看法。
写这类书的作者，大部分都是对书中内容所属的行业有很长时间的工作经验。他们应该是把这个行业的规律都看透了，已一种“过来人”的角度来总结自己的经验。
我举个例子，Yoyo总爱看跟星座有关的内容，她认为说的都特别准。以前我看的时候，也觉得似乎很准。现在我却发现了这类内容的一个规律：一个星座的人，所谓的性格特点，都是说那些优秀的性格，比如说你这个星座的人做事很细心，很谨慎，很有风度，很会为他人着想，有时候比较任性……。其实他说的这些性格，是每个人都会有的性格。我们可以做一个测试，找一个不是经常看星座的人，我们给他看一套特殊的星座性格特点，还是分12个部分，只是每个部分只有性格说明，没有所述星座说明。然后让他说哪个部分说的是他所处的星座。估计没有人能答对。
这只是一个浅显的规律，我觉得还有一个更深层次的规律。
就算你描述的那些性格，确实是跟一个人的出生季节有关。那我想问个问题，全世界60亿人，相当于每个星座有5亿人。难道这5亿人的性格都是一模一样的吗？
好像中国传统的教育方式，就是教学生把所有看到的、听到的东西都划分到某个已知的范围内。比如就像本文开始的那个引子一样，一个非常有经验的人，把他最为熟悉的行业划分成了4个类别，然后告诉人们，这个行业内的每个个体，都应当属于这4个类别之一。
07年有本书比较流行：《长尾理论》。
我也只是粗略地看过，肤浅地理解了这本书所要阐述的一个核心思想：需求是非常个性化的，绝不是简单的几个大热门可以涵盖的。
互联网正是可以满足这一需求的最好的载体。
就好像，世界上最大的图书馆，也不能保证每个人都能从中得到所需的内容。
如果一个人总要给一个行业进行有限种类的划分，那么他的这种做法就是“反长尾”的，说严重一点可以用“反人类”来形容。
有兴趣的朋友可以算算，2的128次方是一个什么样的数字，用一个形象的比喻，可以帮你理解：
假如一个小方块的体积是1立方厘米（长、宽、高都是1cm）， 那么2的128次方个小方块的体积，可以塞满半个银河系，顺便说一句，太阳系只是银河系中可以忽略的一个小点点。
人的DNA序列呢？我不太懂，不过我知道2的128次方，对应于DNA序列的可能的组合数，可以用九牛一毛，沧海一粟来形容吧。
因此你也大概能推算出，地球上任意的2个人的性格特点是否有可能完全一致。
这就是有点跟书本理论相违背了，书里讲究的是“万变不离其宗”，而事实似乎是一个“无穷阶的发散的矩阵”。
所以，我有点不太爱看这类“下定义”或“总结归纳”之类的书，尽管有可能它是外国人写的。
这次的讨论和感触发生的时间，跟昨天写的那个讨论挨得很近，所以我的观点也是一致的。
我们决不可能满足所有人的需求，甚至是满足1个人的所有需求都是不可能的。
但有一点却是一定的（你可以用概率去计算），某一个事实存在的需求，一定有不少人都同时拥有。我们就把这一个需求做到极致，就是我们第一步需要做的唯一的事。
《与互联网产品设计有关的讨论》系列的内容，都是我想到哪写到哪儿，不是像连载小说那样都策划好了然后逐一发表。
思想总是在变，因此需要真实记录我过去的某个时刻的思想是一个什么样的状况。如果人脑也能像MySQL一样可以随时DUMP成文件作为备份就好了……
Nov
12
上述5个配图，分别是IE6、Firefox3、Opera9、Safari3和Chrome浏览器下的不同效果。
应用场景是，图片有链接，HTML片段是：
<a href=”…”><img src=”…” alt=”…” /></a>
img 标签有样式表定义，为了使图片与周围的内容有一些间距，我加入了 margin 定义。
加入之后，在现代浏览器中，会出现上图中显示的蓝色 hover 块与图片不匹配的情况，在这点上，IE6、IE7都能正常显示。
定位问题用了很久，最后发现是 margin 或 padding 的问题。
现在不知道是为什么，只知道解决的办法是去掉这2个样式定义。
如果需要图片有边距，可以在外层套上 p 标签，给 p 标签应用 margin 或 padding 可以达到同样的效果。
Nov
12以前只是搞程序开发，不太关注产品设计，现在要开发一个产品，就要转换一下自身的角色，从用户的角度考虑问题。
随着讨论时间的增加，我对一个产品的理解，对用户定位的理解，都有了很大变化。
今天是这么看待问题，十天后，观点可能完全相反了。
所以有必要把每天对某个问题的看法、思路落实到字面上，保存下来，以备日后的反思、参考。
先说说一个月以前，我觉得，一个SNS网站，就应该像开心、海内和校内一样，只做18-30岁这个年龄段的网民需要的产品，因为这部分用户是中国互联网的中坚力量，占了绝大部分比例。
作为一个刚起步的网站，用户从零开始积累的时候，应该放下自己的特色，放下自己的品味，把热门网站的热门功能，抄袭过来，说句俗话，先“圈人”，等有了一定数量的用户后，再推出自己有特色的产品。
看似挺有道理的一个观点，当时我还挺坚持的，认为这个就是真理。
一个月后的今天，我觉得这种做法是错误的。
随波逐流，是不会被用户认可的。先不谈那些热门网站已经先入为主，就说当SNS这股风潮一下子涌现到人们面前的时候，大家会产生一种SNS疲劳，这么多网站，都是一样的模式，一样的界面，一样的游戏，唯独不一样的是在每个网站都有各自的朋友圈，经常性的是一个朋友，要在三个网站都加一次好友，而另一些朋友，都在不同的网站注册，我想跟某个人联系之前，先要努力回忆一下这个朋友是在哪个网站加为好友的。甚至是当我收到过某个朋友的消息，过了几天再想看看时，实在是想不起来在哪个网站看过的。
渐渐地，我怕了，看到一个网站注册时填那么多信息我就烦，总是重复地做着相同的事，也没有从中得到什么有用的帮助。
现在的情况是，中文名叫开心的网站有4、5个，中国人就擅长搞“山寨版”，这东西搭起来也容易，UCenterHome就可以直接用，换个图片和皮肤，一个SNS就搭出来了。
就好像06年大家都玩儿视频一样，看看现在这些网站都什么状况？几家加一起估计有几个亿的资金，都投入到服务器和带宽上面了，是他们扶持了中国IDC的发展！
据说六间房要换办公地点了，优酷的情况也不是很乐观。记得北京台有个CEO访谈的节目，邀请李善友，我印象最深的一句话：在中国做视频，没有一个亿就别玩儿了。
相比，SNS的成本应该还低廉的多，所以跟风的就数不过来了。一个行业里，赚钱的就是带头的那几家，优胜劣汰的自然定律是地球上永恒的真理，没有创新的跟风者，遭到淘汰是必然的，剩下的就是根据你忽悠VC的能力决定着你烧完资金的时间问题了。
我也是受到Jeff的启发，他提到了宝宝树，这个专注于母婴的网站，让我认识到跟风是个错误的方式。
举个例子，西单的客流量很大，按理说在那里开个火锅店肯定赚钱。这句话是没错，可是现在西单已经有20家火锅店了，你再进去已经晚了，而且你的火锅店又毫无特色，甚至于还比不上现存的那20家，那你这家店必然会被淘汰掉。
如果你选择在东单开一家烤鱼店，尽管客流量远远比不上西单，但烤鱼是你的特色，而且这一带鲜有烤鱼店，那你的赚钱的机会就大得多。
这就意味着，不是非得满足大比例用户群的大比例需求，才能做得好，才能得到认可。只要你有特色，能切实满足一小部分用户的迫切需求，一样可以得到认可，得到用户的依赖。注意词组：切实满足，迫切需求。
按说，初为父母的人，大部分在26到30岁之间，这部分人比18到25岁之间的学生和公司职员的数量少得多，而且前提是刚有了孩子，数量就更少了。
但这部分人都有一些很明确的需求，就是：
需求也不多，就简单的几项，但这些需求我认为都是刚当上爸爸妈妈的人们非常盼望得到满足的。
因此只要你把这2项功能做深入，做精彩，让这一小部分用户满意，那你这第一步就算成功地走了出去。
宝宝树算这第一步走得好的，用户数和VC的支持就充分说明了这一点。
我只是简单用了用，体验了一下。他不是靠玲琅满目的小功能堆积出来的，而是把社区网站都有的几个基本功能根据宝宝这个主题关联到了一起，说的通俗点就是宝宝树教你一套新玩法，功能还是那些，但玩法变了，变得能让你接受，让你记住，让你知道这是他们的特色。
我自己也在设想做一个网站，列了不少功能点，我认为比较好的一个特点是这些功能都是围绕着一个核心功能展开的。这些小功能，哪个单独拿出去都毫无意义，但都跟一个核心绑定起来后，却能发挥很大作用。
Jeff问我，你的这个单一的功能点，有多少人愿意用呢？
我的回答是，当我自己是一个用户的时候，是我提出了这个需求，所以我相信也有很多用户跟我有同样的需求。尽管有这样需求的用户并不多，但我的第一步是把这有限的小部分用户“伺候”好了，其他的都是水到渠成的事儿了。
相反，那些是个人就有的需求，大部分人也知道怎么去满足，做这件事的网站也已经不在少数，如果我没有特色，没有创新，肯定搞不过已经存在的领头羊们了。
总结一下现在的观点：一开始，心不要太大，把目标定位在一小部分人，明确1、2个这部分人最迫切的需求，把它做深，做精，同时还需要创新的内容，把这第一步走好，才是现在应该做的唯一的事。
Nov
10Book: PHP Data Objects Layer (PDO)
Author: Ilia Alshanetsky
Download: http://down.leakon.com/software/2008/11/quebec_PDO.pdf
其实这不能算是一本书，只是一个用于演示的文档，算是一个大纲。
这个简明扼要的大纲告诉你什么是PDO，为什么推荐你在PHP5中使用PDO作为数据库操作层的封装接口。
不仅更安全，而且有更好的性能，用起来更简单。
我在做一个数据库ORM接口，参考了Propel和Doctrine的设计思想，并只针对MySQL5，不做任何框架性或通用数据库的考虑，完全是为了简单、易用和高性能。底层数据库操作依靠PDO完成。
敬请关注~~
