CMS漂流

是的，大宋的外包公司大多是不负责任的，比如我们找到的这一家，在即将做第一轮DEMO的时候，任务才完成了20%——我们一般希望是90%，即所有功能已经合理完成并且Walk through 没有问题！
DRUPAL 天然敏捷，因为我们永远可以认为网站项目差不多快完了。所以，延期严重的项目粗看不会发现问题——看起来一切都运转了——除了某些小位置和需求不合以外。但吃这碗饭，似乎主要对付的就是无穷尽的小位置。可惜的是，这个外包公司声称的小位置多得所有耐心超强的PM也会愤怒。
最终我们决定自己来控制。Damn it！春节，他们人跑回家过年，我们的也差不多。
于是，责无旁贷，作为老大，俺只好退了往返回家机票自己来过——还包括让Team中的队员在家中工作，甚至包括让我的老大协助检查功能——老外不需要过春节让我们手忙脚乱，当然也让我们能直接拉到干活儿的人。
 
最终演示定在2月17号。
也就是说，从一月末到今天凌晨四点，包括大年三十到初三每天超十二小时的持续工作，结果是我们总算重新获得了对一切的控制，并且，似乎重新赢回了客户的信任。
期间经历的，是细节，细节，和细节。比如用sIFR实现全标题特别字体还对间距有精确到一个像素的要求和用它来实现下拉菜单（这个主意很疯狂），比如反复check每一处在七种浏览器中的表现的不同——精确至捕屏后半透明与PSD对比，比如要求页面上所有位置的文字都可被后台控制导致要重写几乎所有block……
 
曾经说，看了三次阿凡达，每看一次，自觉对网站这档子事了解就深入一层。每看一次，就被幸福感充溢因为重新发现有这么多认真考虑观众感受并对每一个细节要求严苛的人们。
 
二十一天中，有几次察觉似乎有要崩溃的苗头（和某几年前做某个大型会议项目时差不多的感觉），于是，某几个晚上，去看了电影，还有血拼。
包括新的一场阿凡达，然后大兵小将。
然后，1527大宋币的户外装备——上衣。
1030大宋币的两双鞋——五折后的实际码洋。
然后，今天意外地没有晚起，九点准时去星巴克躺沙发上晒太阳。赞美完美、难得的sunshine day.
 
这就是一个郁闷IT人痛并快乐着的一个月。

这次是一篇旧帖：
[转帖]北大“关机山”事件
http://cul.qidian.com/#Show.aspx?mid=12&rid=151403
奇人异士何其多。
每一篇都超强，尤赞其中的“加州州版”和“程序员版”。

WEB服务器当然很多。
张宴同学对nginx的研究让我领悟了应该抓住好机会来出名上位。
但是，这个会不会是一个机会？
——G-wan，直接使用原始C脚本来处理请求响应的WEB应用系统（当然，系统会自动预编译它，一如Java虚拟机和.NET所做的那样）。 http://www.g-wan.com
并发连接数可达10几万的系统。
速度据称可与静态页媲美，简单页面生成所耗时间可以用100还是200CPU循环来计算的系统。
小至200K，一个下载包里同时有window/linux平台执行文件，免费的系统。
 
我下载下来，安装，试了它们的demo。也试着vi了一个C文件放进去，果然很好很强大。
C脚本不用编译，看起来，似乎比PHP脚本快得多，特别地，受限于PHP和服务器间，及PHP本身的模型。普通server单机每秒500-1500请求似乎是极限。
 
那么，这么棒的一套系统，为什么它没有流行？出来也有好几个月了，竟然没有张宴2号同学来介绍它，试用它。
如果我们忘了CGI是怎样没落的话，看起来 G-wan声称已经解决了这个问题。
唔，C，这看起来不是个问题，大量人使用C。
 
但是，kolidon发现，函数原来好少，库原来也很少（虽然官方说放dll进去就能被使用，但我放了个pdflite进去，呼呼，使用不了）。
这个平台上的C，比PHP快400倍，比C#快5倍，比Java快8倍，我强烈相信。——但是，没有常用函数怎么办？怎么做快速开发？没有包和面向对象怎么办？怎么做企业级开发？
我不想每天25-30行代码地去写。我想每天200行代友。
我不想错过wordpress还有joomla还有drupal还有jeecms还有dotnetnuke。
 
不过，转回来，很多公司发现nginx/php/membercache/mysql的链条中，PHP才是最弱的一环，因为它在请求处理能图上差了一个数量级。
于是他们构建了自己的方案，来替代php做脚本处理。有更多，有了自己的memcache变体。
那么，如果用G-wan，会怎样？专用来处理切割困难、逻辑相对简单但耗时的大请求代码代码？
听起来，似乎是个好主意。
但是，就如某些人在PHP里掺Python还有scala/java一样。把我们的服务器平台搞得这么复杂有什么好处？我们来看看这样一个系统：它混合了NetScale, F5一类的硬件平台，squid，nginx，还有apache，现在我们加上上G-wan。当然，有PHP，还有JAVA，还有Mysql，还有Oracle，我们的逻辑也有一部分在Oracle和Mysql里面，触发器，存储过程等等，SQL也是一种灰常重要的语言哦——虽然它们在不同的平台上有大不一样的面貌。当然，有时候，还有一些Python和Scala。
多么美好，从此所有人都有了饭碗。
多么恐怖，从此我们需要让更多不同经验的家伙在一个项目里面和谐相处并且进度上齐头并进。
不过，其实我一直疑心，不同的位置用不同的解决方案或许正是复杂系统所需要的。有时候技术人员需要把架构搞得更复杂一点因为技术已经成为商业模型中的重要组成部分了。外面太多人有了金钢钻准备复制商业模式，我们就整复杂点拼拼人品拼拼细节吧。
杯具啊杯具。泪奔呀泪奔。
ps: G-wan不是开源，这里的free是免费，不是自由，当然，更没有公开源代码。如果开源，这个东西确实会，很好玩。

某友，在某大型组织的国内总部做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功能，没有将平日的采编制度内化为规则和界面，他们更多依靠会议和领导的不断重复强调——这意味着，在这个运行中的软件系统内，没有针对不同业务模型的对应处理机制，没有建立横向或纵向的分工或控制体系，没有与核心系统关联的完整的报表系统和基于软件的绩效考核界面。他们把所有这些统统放到了非常不精确的会议，口口相传和随机命令上。

最后，科学地规划、创造和管理。
考虑另一种情况，继续加毫不相关的功能吧：横向铺得越开，也永远就是一矮小茅屋构成的山区村落而不是一个经过集中规划统一管理的现代化度假村。
没有人愿意长期住在原始村落中——偶尔去吃吃农家菜除外，当然，村民们往往满足于挣农家乐的那份钱。