CMS漂流

某友，在某大型组织的国内总部做manager，周五晚十一点四十忽然电话我，让我跑他办公室去帮忙搞定内部系统的收发邮件问题，因为他们的邮件系统近几天切换到了EXchange2007，导致现有的WEB系统平台亦需升级。他已经为此事折腾了十多小时了，情况没有任何改善。这个内部办公和信息化平台以邮件聚合为信息的核心，他确实需要整个系统在下周一恢复以便中国办公室数百员工能够在下周一正常使用此系统。

打车赶到他们大院，朋友在大院门口高兴地等待他想像中的救星。这次没有像以前一样被登记。在办公室坐定，没有理会以zend framework为框架开发的一大坨文件，按错误提示Google之，发现是zf的 bug，mail/protolcol/pop3.php，此文件中某处换行符写列为\n。而针对exchange这种windows系统，\n可能不能在任何时候都顶用。当然，一分钟后，系统从服务器自动抓取和分析邮件的功能就恢复了。

这时朋友的MSN中有家伙在欢呼——是他们系统承包商的工程师，也是最初此系统的开发者，他已经帮着折腾了一整天，这时仍蹲在MSN上保持热线联系试图解决问题——可惜的是，他们都没有试着把一个德语的站用google译成英文，当然也没有看到这种小众问题。我试了，于是成功了。

如此easy呀，终于有闲暇看看他新换的合用办公室了，大屋子里还从着另一位实习生美眉在加夜班，唔，忙碌着往欧洲打电话，年轻、漂亮，让人惊艳。

且慢，因为有些文件中的smtp配置是单独的，也需要修改。那么，问题出现了，系统以前收邮件用的是ZF的mail，发邮件用的是Swift，很奇怪的选择。

更奇怪的是，我竟然搞不定它。

1. 改配置后仍不能再发，内网电脑outlook测试帐号没问题，远程到我的某台windows服务器，oe测试亦无问题

2. telnet建立smtp服务器初始连接，starttls然后提示验证方式gssapi ntlm，这表明是可以正常到这一步的，当然没有继续试因为swift应该能搞定接下来的步骤

3. 继续折腾swift，有意义的google结论几乎没有

4.决定换成PHPMailer，仍然无法连接，这下主要是两种错误：

Unable to authenticate SMTP/Failed to connect to server/unable to relay

不用说，第三种故障可以很快解决，一般需验证才能向域外发信，测试果然是无ssl、无用户名密码时只能向域内发信。

5. 开始和前两种情况博斗但已经很累了，因为认识事情很简单但偏偏无法搞定，故费了大量的时间在日常检查上。也跑了swift和phpMailer的官方DEMO和自制demo，试过所有配置方式，均告失败。

6. 天色近亮，朋友还要上法语课。于是安慰他说当然还可以让邮件服务器管理员将此服务器ip设为不需验证。但我们都知道这种方式很愚蠢。

7. 回家睡了半天，下午参加了个活动。

8.晚上忙完例行的背单词任务，继续奋战。这次在自己机器上远程搞，因此可以利用机器上的十八般武器了——当然主要还是SmartSniff，在自己的outlook上配置然后试发，然后看抓到的包里的那一大坨smtp会话。

9.暂时不管抓到的东东，继续折腾配置，检查和确认几个测试服务器上的OpenSSL扩展都是开着的。

9.折腾一小时，老路看来是走不通了。可能是睡足了的缘故，忽然灵光一现，重新留意到STARTTLS和接下来的GSAPI还有NLTM，等等，为什么没有LOGIN？

9.妈的，Swift以前能发的原因是不是因为其默认验证方式是符合旧邮件系统的LOGIN?

10.好吧，仍然不行，虽然看起来似乎是解决了整个问题中最愚蠢的部分。虽然事实证明前面的一晚上其实是在更愚蠢的基本配置和代码检查、环境检查上转圈。

11.等等，telnet中的IP为什么和ping的IP不一致？妈的，我很清楚他们有很严密的防火墙，并且内外网解析成不同的IP，但我昨天在内网关了测试WEB服务器的防火墙也一样搞不定呀。并且嗅探到的dns解析过程也很他妈正常，也非常能确定这是一个被验证过的邮件服务器主机名。

12.死马当活马医，将配置文件中的domain name换成IP，结束了。

于是扔邮件给朋友，告诉他不用紧张了，现在是周日凌晨4点但我们已经把事情搞定了，早上当然可以多睡一会儿白天当然可以继续安心学法语。

那么，这就是一个从一分钟变成十小时的故事。这样的奇遇和巧合，不论在我还是菜鸟时，还是现在自以为是WEB及周边问题解决专家时，一直上演。

得承认，很多时候，除了使用基本功、我引以为自豪的想像力、无穷无尽的工具，还有他妈的——运气。

好运的是，如果想要解决一个问题，无论花了多少时间，我总能得到一个让同事/客户满意的解决方案——因为，如果从理论上可行，我会去找一解决这个问题的google记录档，或者，自己开始，如果从理论上不可行，那么，在最早回复他们。

Google不能告诉你一切，唔，至少，不能告诉你基于基本功的直觉，也不能告诉你分析、研究和解决问题的思路。

kolidon

半年前给zhbo同学讲过两小时。

今天和Bruce同学聊，又就他所在的网站的工作流程发表了一通意见，这个意见，自然可以解释为什么有些非技术人员一样能认识到技术的重要性。自然可以解释为什么这些垂直门户，在拥有同样、甚至更强力量的前线记者、本应更强力量的编辑的情况下，却拼不过搜狐新浪腾讯的对应频道。

首先，软件超越了规则和制度。

软件是代码。

软件是环境、流程和规范。

软件是规则和制度。

软件是系统和核心，系统是软件、人、机器和管理。

所以，同样的功能，会有不同的软件。

同样是操作系统，iPhone和Android可以用起来感觉完全不一样。

同样是在线词典，谷歌金山词霸和网易有道也全不相同。

相比而言，大家现在谈用户体验，这看起来就是一个细节了——基本约定和假设不一样，设定的规则不一样，对用户操作步骤的理解和约束不一样，出来的东西就是两样。

那么，如果对功能的理解没有内化为规则，功能就永远只能是单独的功能。

kolidon以为，将功能翻译成流程和规则，规则再翻译成代码，是产品经理、技术经理、程序员、UI设计师等诸多人共同协力的过程。

因为技术知识的开放性，越来越多的编程人员能够实现功能，功能在软件系统中占的比重将越来越少。

这也能部分解释，为什么简单的俄罗斯游戏，能够经久不衰。

对应的，规范、规则的理解和设定占的比重越来越多。也就是说，管理所占的比重将越来越大。

将项目经理与技术经理放在同等位置的公司，往往能获得更大的成功。

就Bruce同学所在的那个在国内Alexa排名前200的网站来说，他们是新闻媒体，是社区。但仍然离拥有一个成功的内部生态系统差得很远。

对于门户来说，一个集成化的采编发系统的重要性胜过一切。一间大报业集团放下的网站，没有意识到这一点，这让人惊讶。

这个采编发系统，以及以此为中心的辅助系统，本应是他们百多号人工作的基本平台。但让人惊讶的是，此系统真的只实现了基本的CMS功能，没有将平日的采编制度内化为规则和界面，他们更多依靠会议和领导的不断重复强调——这意味着，在这个运行中的软件系统内，没有针对不同业务模型的对应处理机制，没有建立横向或纵向的分工或控制体系，没有与核心系统关联的完整的报表系统和基于软件的绩效考核界面。他们把所有这些统统放到了非常不精确的会议，口口相传和随机命令上。

最后，科学地规划、创造和管理。

考虑另一种情况，继续加毫不相关的功能吧：横向铺得越开，也永远就是一矮小茅屋构成的山区村落而不是一个经过集中规划统一管理的现代化度假村。

没有人愿意长期住在原始村落中——偶尔去吃吃农家菜除外，当然，村民们往往满足于挣农家乐的那份钱。

大家可以在以下文件中下载，同样，参照这篇文章，看看哪些文件需要被修改。

[完成]Comsenz应用扩展系列之一：Ucenter/Discuz与Joomla深度整合完全解决方案：版本2安装说明（入门新手完全版）

注意:

1.请在安装后修改数据库名/密码为实际数据库名/密码，要改的地方至少四处（在我的文件中密码均为dsfadfa321）：

./configuration.php

./configuration_uc.php

./bbs/config.inc.php,

./ucenter/data/config.inc.php

2.以下几个路径/bbs, /ucenter分别对应论坛和ucenter，ucenter的超管密码为admin, joomla及bbs的超管用户名密码均为admin/admin

热爱，很热很热的爱是什么呢？

http://blog.linkshop.cn/u/pangxiaowei/archives/2005/299.html

原来是爱朋友，爱伙伴，爱团队，爱公司。

————

但是，愿望永远只是愿望。

最终，我们还是必须依靠好的制度设计，包括招聘过程控制，项目流程，公司制度等一系列的规范或契约来使事情变得更美好。

此过程中，只需相信：创新/活力的无序和管理的有序并不总是火焰和冰的关系——好老的命题。

新手应能从中学习良多。

http://drupalchina.org/node/8045

而对于有多年PHP开发经验的家伙来说，也可以顺便回顾和了解一下其他开发者的状况——毕竟，日常的项目管理中Senior和Team Leader们也需要和新手们打交道，不是么？