<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.7.1" -->
<rss version="0.92">
<channel>
	<title>CMS漂流</title>
	<link>http://blog.treeber.com</link>
	<description>WEB应用系统架构观察——需求、架构、编程及工具</description>
	<lastBuildDate>Thu, 18 Feb 2010 11:02:45 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>结束连续21天每天超时工作的生活</title>
		<description><![CDATA[是的，大宋的外包公司大多是不负责任的，比如我们找到的这一家，在即将做第一轮DEMO的时候，任务才完成了20%——我们一般希望是90%，即所有功能已经合理完成并且Walk through 没有问题！
DRUPAL 天然敏捷，因为我们永远可以认为网站项目差不多快完了。所以，延期严重的项目粗看不会发现问题——看起来一切都运转了——除了某些小位置和需求不合以外。但吃这碗饭，似乎主要对付的就是无穷尽的小位置。可惜的是，这个外包公司声称的小位置多得所有耐心超强的PM也会愤怒。
最终我们决定自己来控制。Damn it！春节，他们人跑回家过年，我们的也差不多。
于是，责无旁贷，作为老大，俺只好退了往返回家机票自己来过——还包括让Team中的队员在家中工作，甚至包括让我的老大协助检查功能——老外不需要过春节让我们手忙脚乱，当然也让我们能直接拉到干活儿的人。
&#160;
最终演示定在2月17号。
也就是说，从一月末到今天凌晨四点，包括大年三十到初三每天超十二小时的持续工作，结果是我们总算重新获得了对一切的控制，并且，似乎重新赢回了客户的信任。
期间经历的，是细节，细节，和细节。比如用sIFR实现全标题特别字体还对间距有精确到一个像素的要求和用它来实现下拉菜单（这个主意很疯狂），比如反复check每一处在七种浏览器中的表现的不同——精确至捕屏后半透明与PSD对比，比如要求页面上所有位置的文字都可被后台控制导致要重写几乎所有block……
&#160;
曾经说，看了三次阿凡达，每看一次，自觉对网站这档子事了解就深入一层。每看一次，就被幸福感充溢因为重新发现有这么多认真考虑观众感受并对每一个细节要求严苛的人们。
&#160;
二十一天中，有几次察觉似乎有要崩溃的苗头（和某几年前做某个大型会议项目时差不多的感觉），于是，某几个晚上，去看了电影，还有血拼。
包括新的一场阿凡达，然后大兵小将。
然后，1527大宋币的户外装备——上衣。
1030大宋币的两双鞋——五折后的实际码洋。
然后，今天意外地没有晚起，九点准时去星巴克躺沙发上晒太阳。赞美完美、难得的sunshine day.
&#160;
这就是一个郁闷IT人痛并快乐着的一个月。
]]></description>
		<link>http://blog.treeber.com/20100218/643.html</link>
			</item>
	<item>
		<title>常常被天才的人们感动</title>
		<description><![CDATA[这次是一篇旧帖：
[转帖]北大“关机山”事件
http://cul.qidian.com/#Show.aspx?mid=12&#38;rid=151403
奇人异士何其多。
每一篇都超强，尤赞其中的“加州州版”和“程序员版”。
  
]]></description>
		<link>http://blog.treeber.com/20091229/639.html</link>
			</item>
	<item>
		<title>研究GO两天了</title>
		<description><![CDATA[编译。与C相类的速度。   非托管但指针安全。    极佳的多线程支持。    极度简洁，引入了动态语言的主要优点，让编程不再是和语言的斗争。    开源。
既然它看起来和动态语言差不多。如果可能，企盼有一些将其放在web领域的尝试--就象Gwan对C所做的那样。
谢天谢地。
&#160;
09-12-27 0:59，补充
看到这个位置，有人评论说：
Now Google will create a dominance not only by its acquisition of Admob, and the success of Droid phone but now hitting a sixer the GO language could shape the web 3.0
]]></description>
		<link>http://blog.treeber.com/20091227/635.html</link>
			</item>
	<item>
		<title></title>
		<description><![CDATA[一个冬日下午。从书架上抽出躺书架上月余的书塞包里。步行到附近星巴克。
一口气读完。这是一个关于探索，学习和发现的故事。
经验成为原则，原则成为理论，理论果然就能有效解决问题。
问题和我们遇到的何其相似。这里有聪明勤奋的人们。
这里有智慧和人性的光芒闪耀。
这是我所痴迷的技术。
十三日 十一月 零九年 。于solana星巴克咖啡。
ipod
]]></description>
		<link>http://blog.treeber.com/20091213/633.html</link>
			</item>
	<item>
		<title>玩玩G-Wan：kolidon的人生悲喜剧</title>
		<description><![CDATA[WEB服务器当然很多。
张宴同学对nginx的研究让我领悟了应该抓住好机会来出名上位。
但是，这个会不会是一个机会？
——G-wan，直接使用原始C脚本来处理请求响应的WEB应用系统（当然，系统会自动预编译它，一如Java虚拟机和.NET所做的那样）。 http://www.g-wan.com
并发连接数可达10几万的系统。
速度据称可与静态页媲美，简单页面生成所耗时间可以用100还是200CPU循环来计算的系统。
小至200K，一个下载包里同时有window/linux平台执行文件，免费的系统。
&#160;
我下载下来，安装，试了它们的demo。也试着vi了一个C文件放进去，果然很好很强大。
C脚本不用编译，看起来，似乎比PHP脚本快得多，特别地，受限于PHP和服务器间，及PHP本身的模型。普通server单机每秒500-1500请求似乎是极限。
&#160;
那么，这么棒的一套系统，为什么它没有流行？出来也有好几个月了，竟然没有张宴2号同学来介绍它，试用它。
如果我们忘了CGI是怎样没落的话，看起来 G-wan声称已经解决了这个问题。
唔，C，这看起来不是个问题，大量人使用C。
&#160;
但是，kolidon发现，函数原来好少，库原来也很少（虽然官方说放dll进去就能被使用，但我放了个pdflite进去，呼呼，使用不了）。
这个平台上的C，比PHP快400倍，比C#快5倍，比Java快8倍，我强烈相信。——但是，没有常用函数怎么办？怎么做快速开发？没有包和面向对象怎么办？怎么做企业级开发？
我不想每天25-30行代码地去写。我想每天200行代友。
我不想错过wordpress还有joomla还有drupal还有jeecms还有dotnetnuke。
&#160;
不过，转回来，很多公司发现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是免费，不是自由，当然，更没有公开源代码。如果开源，这个东西确实会，很好玩。
]]></description>
		<link>http://blog.treeber.com/20091206/631.html</link>
			</item>
	<item>
		<title>将一个遗留系统的Swift换成PHPMailer：从一分钟到十小时</title>
		<description><![CDATA[某友，在某大型组织的国内总部做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
]]></description>
		<link>http://blog.treeber.com/20091206/629.html</link>
			</item>
	<item>
		<title>什么是软件？为什么应该更多使用软件来进行门户站点的日常管理</title>
		<description><![CDATA[半年前给zhbo同学讲过两小时。
今天和Bruce同学聊，又就他所在的网站的工作流程发表了一通意见，这个意见，自然可以解释为什么有些非技术人员一样能认识到技术的重要性。自然可以解释为什么这些垂直门户，在拥有同样、甚至更强力量的前线记者、本应更强力量的编辑的情况下，却拼不过搜狐新浪腾讯的对应频道。
首先，软件超越了规则和制度。
软件是代码。
软件是环境、流程和规范。
软件是规则和制度。
软件是系统和核心，系统是软件、人、机器和管理。
所以，同样的功能，会有不同的软件。
同样是操作系统，iPhone和Android可以用起来感觉完全不一样。
同样是在线词典，谷歌金山词霸和网易有道也全不相同。
相比而言，大家现在谈用户体验，这看起来就是一个细节了——基本约定和假设不一样，设定的规则不一样，对用户操作步骤的理解和约束不一样，出来的东西就是两样。
那么，如果对功能的理解没有内化为规则，功能就永远只能是单独的功能。
kolidon以为，将功能翻译成流程和规则，规则再翻译成代码，是产品经理、技术经理、程序员、UI设计师等诸多人共同协力的过程。
因为技术知识的开放性，越来越多的编程人员能够实现功能，功能在软件系统中占的比重将越来越少。
这也能部分解释，为什么简单的俄罗斯游戏，能够经久不衰。
对应的，规范、规则的理解和设定占的比重越来越多。也就是说，管理所占的比重将越来越大。
将项目经理与技术经理放在同等位置的公司，往往能获得更大的成功。
就Bruce同学所在的那个在国内Alexa排名前200的网站来说，他们是新闻媒体，是社区。但仍然离拥有一个成功的内部生态系统差得很远。
对于门户来说，一个集成化的采编发系统的重要性胜过一切。一间大报业集团放下的网站，没有意识到这一点，这让人惊讶。
这个采编发系统，以及以此为中心的辅助系统，本应是他们百多号人工作的基本平台。但让人惊讶的是，此系统真的只实现了基本的CMS功能，没有将平日的采编制度内化为规则和界面，他们更多依靠会议和领导的不断重复强调——这意味着，在这个运行中的软件系统内，没有针对不同业务模型的对应处理机制，没有建立横向或纵向的分工或控制体系，没有与核心系统关联的完整的报表系统和基于软件的绩效考核界面。他们把所有这些统统放到了非常不精确的会议，口口相传和随机命令上。

最后，科学地规划、创造和管理。
考虑另一种情况，继续加毫不相关的功能吧：横向铺得越开，也永远就是一矮小茅屋构成的山区村落而不是一个经过集中规划统一管理的现代化度假村。
没有人愿意长期住在原始村落中——偶尔去吃吃农家菜除外，当然，村民们往往满足于挣农家乐的那份钱。
]]></description>
		<link>http://blog.treeber.com/20091129/621.html</link>
			</item>
	<item>
		<title>提供Joomla1.5.x + Ucenter 桥接Demo站整站打包下载</title>
		<description><![CDATA[大家可以在以下文件中下载，同样，参照这篇文章，看看哪些文件需要被修改。
[完成]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
]]></description>
		<link>http://blog.treeber.com/20091124/614.html</link>
			</item>
	<item>
		<title>所有团队和公司的美好梦想</title>
		<description><![CDATA[热爱，很热很热的爱是什么呢？
http://blog.linkshop.cn/u/pangxiaowei/archives/2005/299.html
原来是爱朋友，爱伙伴，爱团队，爱公司。
————
但是，愿望永远只是愿望。
最终，我们还是必须依靠好的制度设计，包括招聘过程控制，项目流程，公司制度等一系列的规范或契约来使事情变得更美好。
此过程中，只需相信：创新/活力的无序和管理的有序并不总是火焰和冰的关系——好老的命题。
]]></description>
		<link>http://blog.treeber.com/20091112/610.html</link>
			</item>
	<item>
		<title>某帖：关于Drupal开发模式和Drupal思维方式的争论</title>
		<description><![CDATA[新手应能从中学习良多。
http://drupalchina.org/node/8045
而对于有多年PHP开发经验的家伙来说，也可以顺便回顾和了解一下其他开发者的状况——毕竟，日常的项目管理中Senior和Team Leader们也需要和新手们打交道，不是么？
]]></description>
		<link>http://blog.treeber.com/20091110/609.html</link>
			</item>
	<item>
		<title>呵呵，推个好玩的</title>
		<description><![CDATA[被SD2.0大会折腾了几天，云计算总算作为一个包罗万有的概念深入俺的脑海了。
这儿有冯神的风计算，很好很强大——不许笑：
http://www.dbanotes.net/Keynotes/WindComputing.pdf
]]></description>
		<link>http://blog.treeber.com/20091024/608.html</link>
			</item>
	<item>
		<title>091024书单</title>
		<description><![CDATA[SD大会赠送了180块的书劵，但跑到博文视点的摊位时，选好了书，然后被告知劵能选的只是批定范围的。然后看到所谓的指定范围，和网站上预先公布的可选书单完全不同，几乎，全是，垃圾。
无奈之下选了微软出版社的两本说明书，一本Windows Server 2008 Administrator’s Pocket Consultant，647P，$34.99，一本Internet Information Services (IIS) 7.0 Resource Kit，779P，$49.99，均折价RMB 80，算是把劵花掉了。
然后刚从SD2.0大会回到家，即把选好的书在China-pub下了订单：
一线架构师实践指南（China-pub上竟然尚需预订，大会现场已经有了，郁闷没在会场买签售版） 温昱 电子工业出版社 RMB 35
敏捷无敌
观止--微软创建NT和未来的夺命狂奔 (SHOW STOPPER!中文版)(揭示微软鲜为人知的秘密)
软件开发沉思录--THOUGHTWORKS文集(CHINA-PUB首发)（来自软件界思想领袖们的经验心得）
程序员修炼之道--从小工到专家(十周年纪念版)
MYSQL性能调优与架构设计(CHINA-PUB首发)
还看到这本：
深入理解MYSQL核心技术 (UNDERSTANDING MYSQL INTERNALS)&#160; 原版似乎是2007年的，Amazon上评价很高，但评价者很少，中文版2009年9月才出，很便宜，但最近不打算读，等一阵再说
&#160;
现在，最最期待的是，CSDN尽快发布各讲座的PPT，太多内容需要对着PPT逐页复习了。
]]></description>
		<link>http://blog.treeber.com/20091024/604.html</link>
			</item>
	<item>
		<title>将参加SD2.0 2009年大会</title>
		<description><![CDATA[感觉今年SD大会官网好破，英文版就一页，弄得跟老板报告都不好意思。所谓的在线支付更是个笑话，弄得俺下来还是得换招行支付，然后支付完了确认总要自己打电话，折腾了一天半才终于被确认给他们汇了钱。
云计算，移动开发，大型架构，然后再是某厂商推的下一代语言。邀了几个知名博客作者。当然，还有挺多项目管理与敏捷的话题。
没有开源趋势，没有产业研究，没有文化和互动。
反正前一个项目刚差不多快结束。去观赏一下其他技术人员的脸也好。
不管怎样，10月22-24，在温都水城。
]]></description>
		<link>http://blog.treeber.com/20091020/601.html</link>
			</item>
	<item>
		<title>成功从来不是偶然</title>
		<description><![CDATA[有朋友公差匈牙利，回国，在北京转机逗留几个小时，正是中午，于是到三元桥来看我，吃饭，谈到他们的daily report，再比照我们公司的每月自主回顾估测项目耗时。才知道严肃的管理和欧洲式的放松真是天差地别的。
做软件，公司靠管理，个人靠钻研。这也是欧洲的好软件公司不多的原因。
不过，中国人狡诈，欧洲人诚实，这也是欧洲公司管理里面框框少的原因。
软件需要发明创造，但将发明创造整合起来，非得有大量的规矩不可。
这兄弟木讷，智商从初中到高中一向被我们认为是75，但在HW某关键产品线某小组，是绝对主力。
兄弟送我一盒巧克力，8.5欧，礼轻情意重。
]]></description>
		<link>http://blog.treeber.com/20091020/600.html</link>
			</item>
	<item>
		<title>Drupal开发中的技术热点</title>
		<description><![CDATA[kolidon原作于2009年9月24日
1. 模板一致性    此问题并不是指模板风格和CSS一致，虽然这也很重要但是并不困难。Drupal中模板的问题在于因为系统模板的灵活，模板很难集中控制。即，模块中代码未模板化，或模板置于多个目录位置。
习惯以自有框架特别是某一种特定模板方案比如smarty一类，并且对模板进行集中处理的团队，转入Drupal后往往会对此迷惑。
实际上，这个问题是一个技术问题。
实施中解决办法是：制定出团队自己的模板命名，控制规范并不断修订完善。在每个项目中，对模板、自定义模板函数、自定模块中的模板以表格视图进行跟踪。
虽然Drupal系统提供了大量可能的模板化实施可能性，但对此系统了解越多，越能发现最简单的往往是最可靠的：仅使用模块内模板结构+模板目录内统一控制。
2. CCK及Views的使用
我们发现，基本上所有情况下Views殾能满足我们的需求——如果善用其Api文档的话，kolidon所在团队亦在学习如何将更多block也Views化——当然是不是一些其他页面也Panel化就有待考虑了（因为莫须有的性能问题）。
但我们偶尔会需要添加自定义的扩展模块来对其功能进行更改或扩展。
3. 权限问题
我们有时会需要在term页列出所有文章及其teaser但一个常用模块Content Access可能阻止那些无权限的文章出现在此页面，而此模块可能在其他页面会能用到（当然若不使用此模块此处不会用问题但会对项目其他需求造成不便）。
此时我们常做的时完全放开此content type的权限改由自定义模块来控制其全文存取。
4. Input format
输入格式对不同roles的授权也是需要较长时间试验才能获得满意结果的位置。
5. 开源模块质量
开源模块并非拿来就能用，最好看看其是否对性能造带来多大问题：比如某个模块og content admin就可能是一场华丽的性能灾难。
6. Menu及Breadcrumb系统
这个不用说，在任何系统中都是重中之重。若你使用了大量的第三方模块，然后又使用了大量的自定义模块，然后又企盼能将它们无缝组合起来：指的是在外部表现、菜单和Breadcrumb上的完全按业务需求而非模块的目录和自命名结构，那么，多考查几种相关模块，再多花点时间反复试验以便最终熟练吧。
7. 请尊重garland模板
这套模板，实际上，已经帮助我们完成了任何自定义模板工作的80%。所剩的唯有考查是否需要新增area，对原style.css作何种重规划和改进了。但对其整体结构的改变，试过后才会知道，意义不大。
8. locale问题
多语言在任何系统中都会是一个问题，kolidon并不认为Drupal在解决此问题上就已经完美了。
如果你仅仅是需要开发一种特定语言的系统，那么事情不会特别复杂（虽然也会出现一些莫名其妙的问题需要耗费大量时间去调试，比如关闭原生的English时你会发现部分页面会变成blank）。若需要开发多语言而且需要它们能正常切换，那么，诸天神佛保佑，但愿你的团队中有人研究过所有源代码，对这一部分的系统实际有深入了解并随时愿意解决各第三方模块中可能出现的语言问题。
9. Messaging和Notification
这部分也很好玩，如果你花了很多精力玩转了的话，另外，当然Cron不会是一个大问题但同样需要我们保持关注。但是当Messaging、Notification与Locale问题纠缠在一起，特别是不同的用户需要不同的Messaging的时候，我不知道它们是不是仍然让人喜欢。:-)
10. JS问题
如果团队中没有人精通JS，那么至少需要了解Jquery的用法和Drupal的JS框架。上天保佑，这么多Js不会产生冲突。
11. 性能问题
这个实际上如果没有太变态的第三方块的话，不会有什么问题，但若对性能要求较高的话，在登录状态，会需要所有人来贡献智慧以便解决周边的性能问题比如数据库、Gzip压缩、图片大小、背景图片或装饰图片数字，Js性能等等。最后，你会发现，转了一圈，回来了——我们终将面对的是登录状态下的Drupal核心的性能问题。若到了这一步，基本上，团队就开始专业起来了。
]]></description>
		<link>http://blog.treeber.com/20090924/597.html</link>
			</item>
	<item>
		<title>Drupal项目管理中的QC</title>
		<description><![CDATA[kolidon中项目实施过程中发现，Drupal项目应用中有如下问题值得关注：
在中等规模项目中，对核心代码及各开源模块源代码的尊重及版本控制与跟踪。
在华的外企和外包企业，对Drupal开发认识不足，因此常常招聘新手来进行“组装”，这些新手无PHP编程基础（可能拥有其他程序开发经验），无充分项目经验，这可能带来的问题是实施计划与项目进度不可控，代码质量与可靠性不可控，维护计划混乱。
实际上，更大的问题在于，即使稍有经验的Drupal开发人员，亦可能无法形成自己的开发规范/契约。自行开发的模块命名、功能分工、模板等均无法控制。
解决方向：
1. 减少对无PHP编程经验的开发人员的招募。应注意开发过程中的标准化文档的生成（即，所有解决方案均应经过讨论和一致许可并形成可供回顾的标准文档）。
2. 每周一次的集中学习，实施质量评估（点评）必不可少，在此过程中，重点讲述不周密的实施方案可能给后期开发，需求变更及维护带来的影响。
3. 在对人员的培训过程中，尤应注意对Drupal核心源码的集中学习，和对Drupal文化的讨论。
4. 若有可能，组织团队成员协同开发和维护某个开源模块。
kolidon识于2009年8月
]]></description>
		<link>http://blog.treeber.com/20090822/596.html</link>
			</item>
	<item>
		<title>正在学习有始有终，更新Joomla1.5与Ucenter1.5桥接</title>
		<description><![CDATA[在转场了新光天地的地下一层，两间上岛咖啡店，最后跑到24小时的永和大王用我可怜的移动3G上网卡撑了八小时，喝掉上百块人民币的咖啡和豆浆后，我终于成功地将桥接器的测试站点放到了网上。并且，重新整理了所有已经发布的代码，进行了尚算精细的测试。
请点击链接看这篇不断更新中的文章：
http://blog.treeber.com/20090104/500.html
目前我止，QQ上向我问询这个桥接器开发情况的朋友已经很多，但愿这篇文章能让一些不怕麻烦的朋友先跑起来，我仍然在完善它，以便能解决掉目前所有的不完美。
因Ucenter本身似乎不那么完美，很多地方得追进源码才能发现文档的错误，或者，它蛮横地不向其他应用提供新用户注册成功的消息，一个细节是：用户若在DZ一类ucenter应用中注册了，则在Joomla中注册时只能先探测username和email是否在ucenter中存在再给出提示，而不是注册时自动进入joomla系统——虽然已经做到了joomla中成注册完自动进入Ucenter。
估计再用一个小时左右就可以直接将其改成在任何用户在joomla注册时，直接将Ucenter中存在但joomla中不存在的用户同步过来，这样就不用看到丑陋的冲突提示了（见内文中的详细说明），或者，Jianer同学提到的jfusion也可以进入我们的视线——虽然，对jfusion我比较持怀疑态度。
若有开发者愿意合作，我们应该弄几个饭局讨论下如何将其做成组件，如何不用修改核心代码（目前已经有思路了但还得试）。
有点迟，主要是这半年工作有点千头万绪，另外，最近在新单位主要用Drupal。
祝大家顺利。
]]></description>
		<link>http://blog.treeber.com/20090719/589.html</link>
			</item>
	<item>
		<title>My Travel to Guangzhou &amp; Shenzhen</title>
		<description><![CDATA[Last Thursday I went to Guangzhou,&#160; From Beijing, by China Eastern, MU 2124, MU 2301(connecting flight in Xi'An).
It's pretty firm when you leave from your daily affairs then have a travel.
Had have a talk with Tim Lee in Guangzhou about his company and in Shenzhen, a friend working in HuaWei NGN core product line taught [...]]]></description>
		<link>http://blog.treeber.com/20090714/575.html</link>
			</item>
	<item>
		<title>DedeCMS也美丽</title>
		<description><![CDATA[最近和朋友合作做了dedecms的一项目，颇有感触。    国内有想法的家伙其实是蛮多的。
一套好的CMS，特别是一套要在国内流行的CMS，几个因素非常重要：
1. 规则简单的，可扩展的模板系统，既支持模板单独定义，亦支持模板通用化（首页、频道首页、栏目清单页、文章页、专题页五个即够）   2. 静态页面生成、未生成静态页面时的预览功能    3. 动态建立内容模型(model)，如产品、软件、视频、图片等需要的信息有所不同    4. 其他如多级分类、对文章的不同标记（推荐、加粗、头条、图片、跳转等）    5. 配套的其他功能如广告、会员、图片水印、附件管理、数据库管理等。
我们分两次，每次半天，挂完了一个四屏长的页面加六七个三屏长的频道页，加栏目清单页和文章页。这在以前是无法想像的（JEECMS除外）。
另外，我们还对专题功能加装了一个插件，实以现对专题的各个节点分别列出文章清单。只需要taglib文件夹中放置一个myspecnote.lib.php的文件即可实现myspecnote的新标签。
{dede:myspecnote notei=somenote&#160; }-----[field:arcurl/]------{/dedea:myspecnote}
]]></description>
		<link>http://blog.treeber.com/20090713/572.html</link>
			</item>
	<item>
		<title>服务器端验证、Jquery的Validation验证插件及其他</title>
		<description><![CDATA[在JAVA中这从来不是什么大问题，特别是主流ORM组件如Hibernate的使用，加Struts的validator，不太严格的服务器端验证就差不多O了。
在PHP中，我们一样也面临这个问题，ORM当然也不再是问题，目前有些CMS中也已可见轻量级的model自动生成（根据数据表），生成无外键的单表对象模型，另一些知名的开源ORM当然已经和Hibernate一样实现了复杂的ORM。
我们这儿先说数据格式验证。
&#160;
kolidon倒是见过其他公司自有的商业框架中的复杂的验证模型，他们试图以java开发者的视角观察一切，巧合的是，这帮家伙几年前就在 joomla1.0上实现了自已的1.5…:-)。不管怎样，这样的框架已基本堪用了，甚至，有时能感觉到，只要这帮家伙再努把力，甚至能自动生成前端js验证代码。
但实际使用时，仍然面临太多问题，如代码复杂度倍数级增长，代码量狂增导致的性能损失。若一个代码框架语法和逻辑过于复杂，这些后果似乎是必然的。
难于分解的复杂系统最终将被抛弃，因为维护成本、学习成本还有，随着应用的市场系统，构建相对简单的系统是如此方便，而将相对简单的系统组合后，仍然会有无限的可能。
&#160;
一个事实“我们接触的绝大多数项目，都是需求变化极大的网站平台，离“WEB应用”这个词其实仍然有那么些距离。也就是说，无论在价值及使用方式上，对数据验证一致性的要求非常低。另外，虽然我们一直在努力，但事情似乎永远没完没了。
典型的例子是wordpress个人博客的反垃圾评论的战争。见这儿、这儿、还有这儿。
道高一尺、魔高一丈。如果无法可想，那就换一种思路。 
&#160;
考虑一下，只要安全性能过关，那么一个电话号码位数多或者少个一两位，恐怕并没有太严重的后果，因为，我们不可能知道用户填了个虚构的电话号码或者邮件地址——能连到银行去验证信用卡真伪的除外，那个当然也不保险，最万无一失的的是扣掉你一块钱，然后再打给你——这就是我们在当今体验到的极端验证法。
若一个varchar字段超长，mysql数据更可能是自动截断，而整型数据超出范围，能遇上的用户也基本上不可能是合法用户——这种可能性我们在这么多网站项目中基本上就没怎么遇上过。能手工制作URL传入自定义值的非法用户，若还能识别传统的验证码，最终实现了批量向站点中写入数据，只要数据是需要验证才能显示的，那么这些动作能产生的价值就几乎为零（kolidon博客后台中的数万条垃圾评论为证）。
不要害怕垃圾评论，只需要让垃圾永远没有机会露头污染到大家。不完美并不是什么难堪的事情。
&#160;
我们将注意力更多转到了前台。几年前，我们试用了一些集成式解决方案，更多的是自己写JS。而jquery大行其道后，我们使用Tootip和Validation，事情正变得越来越简单。
&#160;
同时，我们也在寻找PHP的ORM组件，当前google给出的结论是Doctrine and Propel，满心期待这些组件除了提供基本的OR映射外，还能有后端验证功能，若还能在前端验证上做一些工作就更完美了。
不过，若能有后端验证，从此出发，生成供Validation插件使用的js代码仅一步之遥。
]]></description>
		<link>http://blog.treeber.com/20090705/563.html</link>
			</item>
	<item>
		<title>ucenter 与 wordpress桥接</title>
		<description><![CDATA[重新发布了当时的草稿并作了修订。
若有问题，请评论或QQ我。
http://blog.treeber.com/20080722/352.html
]]></description>
		<link>http://blog.treeber.com/20090626/560.html</link>
			</item>
	<item>
		<title>kolidon旧文：何为大牛</title>
		<description><![CDATA[什么样的家伙可称大牛？   大牛吃什么？大牛干什么？大牛玩什么？    怎么成大牛？    先澄清一个问题：大牛是人，大牛是更加人性化的人。    人生就是解决问题，大牛也一样。    因此，只有两个问题有意义：    什么样的家伙可称大牛？     大牛能发现或提出好问题    大牛能解决相对重要一点的问题    大牛能比较系统地解决某一领域的问题    大牛对这个事情有一套完整的理论，当然实际操作上也可以厉害，更多是假他人之手    大牛永远知道自己的领域——虽然，用一点点时间，他们也可以迅速在相关领域变成准大牛    大牛往往从小牛成长而来，他们不会拒绝解决小问题，但不会沉迷于自己断定不会变大的小问题，这里面，往往有运气    大牛不闭门造车，拼经验更拼眼光   [...]]]></description>
		<link>http://blog.treeber.com/20090623/554.html</link>
			</item>
	<item>
		<title>开始处理千万量级数据库</title>
		<description><![CDATA[虽然总和一般规模的站点打交道，但需求总是千变万化的，当前某个客户的数据库已经达到数千万条记录（10M条规模），虽然离大规模数据处理（G条记录）还差了老远，但已经可以勉强在实际项目中看到点这样的感觉了。
前台访问量没有上来，因此当前的索引状况应付前端访问并无问题，所谓分表、分库现在也完全没用上。
主要的问题在于数据插入，客户需要每次提交一个csv文本，约一万至数万条记录，而.NET组的同事在处理这些记录时，采用的方案是按某字段验证是否存在，若不存在则插入。此字段当然已经有了索引。
但最后的结果是过万条记录至少需要一刻钟时间来处理这些数据，客户认为这个时长不可接受。
因为以前有处理过数百万条记录的经验，因此被抓去给方案。
三种方案：
1. 用户提交数据后，数据进入任务队列，即用户不用盯着浏览器观查页面刷新什么的，关闭浏览器亦可行，这是最基本的。
2.提交的数据先行去重，然后一并放到库里查重，然后使用单一事务一次性插入。
3.若库里面仅以单一字段验证是否重复的话，直接在库里面将此字段设为唯一索引，然后insert插入，返回错误值的则为重复，不重复的则能正常插入。
最后结果，同时采用2和3，在远低于服务器配置的普通PC测试环境下，一万条数据插入可以在1XX秒搞定。
]]></description>
		<link>http://blog.treeber.com/20090623/553.html</link>
			</item>
	<item>
		<title>Joomla 1.6</title>
		<description><![CDATA[若J1.6真如官方所言的达成其中大部分目标，同时在性能上有所提升，则用户和开发者或会重拾对其的信心。
或者说，从1.6开始，核心功能即开始有向理想中的快速建站CMS靠近的趋势。
见：Feature patches for 1.6

Implement a new JForm library package [complete]. 
Implement a simple way of providing translation in JavaScript [complete]. 
Implement new controller dispatchers for more robust request routing [complete]. 
Implement a new access control system that needs to at least emulate what is in 1.5, allow adding of new groups and access levels, and [...]]]></description>
		<link>http://blog.treeber.com/20090619/552.html</link>
			</item>
	<item>
		<title>向大牛学方向，向同行学方法</title>
		<description><![CDATA[大牛提供思想，指明方向。
同行分享未曾经历的各种可能性——或者是你水曾体验的好方法。
——09年6月13下午，中图上岛咖啡，博文视点OpenParty有感。
ps.有同学分享了我所关心的数据库、性能优化和新的开发框架。
]]></description>
		<link>http://blog.treeber.com/20090613/551.html</link>
			</item>
	<item>
		<title>kolidon思绪：一个WEB从业人员应该了解的基本词汇</title>
		<description><![CDATA[这是前一阵在我在公司中对商务人员做的一个案例分析PPT中的几页，现在似乎是可以分享了。当然，作为一个WEB架构人员或者程序员，若不能对这些词汇详细论述和举一反三，是不合适的。
平台与环境
ASP.NET、JAVA EE、JAVA、C#、VB.NET、PHP、Python    FLEX     Redhat、CentOs、BSD     Windows2003/Windows2008     Apache（Resin、Tomcat）、IIS     Oracle9i/10g、Mysql4/5、MSSql Server
数据库
表、索引、触发器、存储过程、CRUD    多表联合查询     数据库镜像、主从结构、自动备份、同步     分库、分表     数据库调优、索引优化、查询优化……
前台表现（UI）
Smarty，freemarker，velocity，Jsp    FLASH，XML，FFmpeg、FLv、WMV     Javascript，Ajax，jquery, [...]]]></description>
		<link>http://blog.treeber.com/20090611/549.html</link>
			</item>
	<item>
		<title>Drupal 是第二种武器</title>
		<description><![CDATA[Drupal 是top1的php开源CMS（当然投票的应该大多是技术人员）。
好处在：
1. 比zend framework或cake php一类的纯框架多前后台；
2. 比Joomla这样的庞杂系统的代码基要简单。
问题在：
更适合程序员做CMS的主结构，做社区或做中等规模系统比较好。不适合普通用户的快速建站。
美国政府最新的救市计划，recovery.com，就是用drupal，而似乎美国总统的官方网站，也是用的这个。
如果开发框架是程序员的刀枪匕首的话，那么对PHP程序员来说，Drupal可以是第二种武器。
第一种武器，仍然是语言本身及各机构自己积累的各种开源组件，代码片断——对大型应用来说，架构本身将产生相当的价值，那么这个架构肯定是有特色的、与系统本身完全匹配的，一个词：自己的。
更重要的是：性能。
]]></description>
		<link>http://blog.treeber.com/20090531/542.html</link>
			</item>
	<item>
		<title>Joomla 不是万灵丹</title>
		<description><![CDATA[我们开发的心得是：    1. joomla1.0从mambo过来，当时算是不错，轻便，扩展丰富；     2. 升级到1.5后，有一套完整的仿java的框架（或者，搞一套完整的语言层级之上的框架是所有程序员的梦想），但这个框架太过庞大，已经失去了php的敏捷开发的天然优势，画虎不成反类犬；     3. 1.5性能奇差（1.5.1时默认首页，经过优化后时间大概在80ms，1.5.10时，已经需要花1000ms甚至更多了）——做了完整的优化，比如eacc等全开等等，     4. 模板系统不直观，1.5有所好转，但实际上事情更复杂了。 
优势在：    1. 扩展众多，大概有3000+组件、模块、插件等，虽然大量的扩展代码混乱，但还是有些好东西的；     2. 如果用户仅仅要求一个能自主管理的网站，对色系和风格有点要求，这个最快，但一旦涉及到模板制作就慢了。 
我们在其中做了较多的工作，并与目前国内的社群有所接触。
但我们已经逐步放弃以joomla为基础的深层次二次开发——仍然可能做一些模板、组件或者是模块或者直接全部使用既有组件来构建。
]]></description>
		<link>http://blog.treeber.com/20090531/541.html</link>
			</item>
	<item>
		<title>终于又有一位兄弟跟我说他的dz+joomla1.5的桥接成功了</title>
		<description><![CDATA[虽然现在他仍然没有搞顺修改密码的事儿。
感谢immer兄。
他搭了一个测试站点，DZ7 + joomla1.5.10，http://djtest.treeber.com （空间用的是他的服务器，域名是我弄了个子域名指过去的），大家可以试试。
我也正在这个站点上研究密码不能同步修改的原因，应该今天会有时间搞定。
以后有什么问题immer兄也可以为大家帮忙了。
]]></description>
		<link>http://blog.treeber.com/20090529/540.html</link>
			</item>
	<item>
		<title>今天邮储结西联竟得了个手握发电小手电</title>
		<description><![CDATA[去取这个月的谷歌汇款。这次是直接到单位附近的水碓子邮电所（水碓子南口的东区邮电局），虽然仍然很慢（全部走下来也得七八分钟），但办完后竟然给俺送了张积分外汇业务卡，同时送了个手握发电的小手电（超有爱的小玩意儿）。
这几次都是在邮储，他们比农行服务态度要好太多，农行除了一次在家门口办的比较顺以外，其余的都乱七八糟一堆事儿，有一次甚至用姓和名顺序不一致的超搞笑理由把俺给撅了。
09-05-29 09:21记于东区邮电局。
]]></description>
		<link>http://blog.treeber.com/20090529/537.html</link>
			</item>
</channel>
</rss>
