裁纸刀下 » 动易

动易SiteFactory目录权限详解

小李刀刀 — Thu, 26 Jun 2008 19:50:00 +0000

官方说明中，指出在2003版本上的目录权限是给Network Service帐户分配写入权限。这是一个理想化的状态，如果要满足分配该帐户写入权限即可正常使用的话，那么要满足以下条件：

你的站点是采用了默认的帐号设置，即站点程序池的运行标识帐户是Network Service(网络服务）；
你给根目录分配了写入权限，而不是按照安装向导页所提示的那几个目录设置；
你从来没有修改过NTFS的默认权限设置，对所有目录和文件都会有“Creator Owner”这个帐户的特殊权限。

满足以上条件的话，你给动易所在的目录分配了Network Service的写入权限后，基本上能够正常安装和使用动易（还会遇到一些问题，但是基本上可以了）。

下面解释一下：由于程序池运行标识帐户是“网络服务”，因此你的动易站点在读写磁盘文件、创建目录、创建文件的时候都是以Network Service帐户身份运行的，于是乎，创建和写入权限就不是问题了，再加上Creator Owner帐户的特殊权限（完全控制），也就对站点自己创建的文件和目录拥有了完全控制权限，因此可以正常运行。可能遇到的问题：由于只拥有写入权限（写入权限只包括创建目录和文件、写入属性、写入扩展属性），在修改站点配置，或者是在后台修改广告目录、JS目录、上传目录的时候，需要对已有的目录，而且创建者、所有者一般是Administrators组或者是Administrator，于是出现“对IAA目录的访问被拒绝”这一类的权限不足的提示。

现在考虑第二种情况，站长拥有一定的服务器安全配置知识，或者是虚拟主机、合租主机，WEB站点有下列任意一种情况：

没有用网络帐户来运行程序池而是用IWAM_机器名用户；
没有用Windows的任意一个默认帐户，而是自己创建了一个用户来运行程序池，比如我自己创建了IWAM_OOPHOME来运行程序池，IUSR_OOPHOME来运行IIS。
在创建站点之后，删除了站点根目录的Creator Owner权限，只保留了Administrators和System的完全控制权限和IWAM_机器名和IUSR_机器名的读写权限。

有上述任意一种情况，将导致安装不能成功，站点也不能正常运行。

动易SF在运行中，到底需要哪些帐户，需要哪些权限呢？下面我结合自己的测试，分析一下：

创建临时文件、静态页面、新增标签……，也就是“创建新目录和新文件”，这要求给程序池标识用户写入权限，具体的目录有config，IAA，JS，UploadFiles，Skin，Temp，Template。实际上还有一个目录，那就是系统根目录（因为要在根目录下创建保存配置的临时文件、创建首页静态文件、创建新增根节点的目录。这是需要“写入”权限的。
修改原有文件、删除临时文件……，也就是“删除目录和文件”，这要求给程序池标识用户权限高级设置里的”删除子目录和文件，删除”两项权限，实际上我们在基本的权限分配界面指定“修改”而不是“写入”权限就完成了这项权限的分配。
修改IAA、JS、UploadFiles的名称。虽然后台提示说要先修改目录，然后再到后台修改，但是经过试验发现，必须是直接在后台修改并保存，系统会自动给这几个目录更名。这要求程序池标识用户对根目录的修改权限。

既然权限分析清楚了，那我们就明白了，动易始终是对根目录有“修改”权限需求的。因此作为一劳永逸的办法，直接给网站根目录加上程序池标识用户的“修改”权限，就OK了。但是这样很多朋友会不满意。那怎么办呢？可以试试按下面的方法：

给站点根目录加上程序池标识帐户的“修改”权限，默认是继承到所有目录的。
打开根目录，对根目录下的图片目录、上传文件目录、纯读取运行的目录等取消“从父级目录继承权限”，提示的时候选择“删除”，这样这些目录就完全没有权限了；
重新给刚才删除了权限的目录给它们分配Administrators和System的完全控制权限；
给静态文件目录（例如上传、你各个节点的生成目录等）加上程序池标识帐户的“写入”权限（最好到高级权限里设置，只给“写入”权限，最多再加上“读取”权限，不需要“运行”和“列目录”的权限；
给非写入的程序文件夹，例如Rss、User等目录，增加IIS匿名用户和程序池标识帐户的“读取和运行”权限。

这样我们的站点就给了动易运行所需要的全部最大权限，同时也把不需要权限的目录统统去除了权限，比如上传目录，只有程序池帐户的写入权限和IIS匿名帐户的读取权限，就算被上传了木马到里面，除非是JavaScript木马，否则是不会被运行的。目前还没听说过JavaScript能对服务器端造成攻击和破坏的。至于ASPX、ASP、VBS一类的木马，传上去了也不能运行。哪怕是代码藏到图片里，也不能运行。

这样就最大程度地保护了站点的安全，又避免了权限分配不够造成的使用问题。

动易SW中的一个严重但不影响使用的bug（二）

小李刀刀 — Sun, 22 Jun 2008 18:24:00 +0000

　　上次分析出来了Bug的问题所在，是因为selectSingleNode(strNodeName)不能取到要取的元素，但是为什么这么大的Bug没有出现500错误呢？否则的话，这么大的一个bug不要说是来到用户手上，在开发人员手里就已经被发现了。

　　这次继续分析这个Bug。在新版本的API_Function.asp这个文件中，selectSingleNode这个函数一共用到了5次，有两次是在SendPost函数里，在很早的版本里那两个地方就用的是selectSingleNode，因为那里传递的参数用的是“//status”和“//message”，是正确的XPath，因此不用考虑那里了。此外的三处，代码如下：

'**************************************************
'函数名：getNodeText
'作  用：获取XML文件中指定节点的文本
'参  数：strNodeName   ----节点名称
'返回值：解析出来的文本值，
'**************************************************
Function getNodeText(strNodeName)
    If IsNull(strNodeName) Or IsEmpty(strNodeName) Or strNodeName = "" Then Exit Function
    If IsNode(strNodeName) Then
        getNodeText = sMyXmlDoc.documentElement.selectSingleNode(strNodeName).Text
    Else
        getNodeText = ""
    End If
End Function  

'**************************************************
'函数名：setNodeText
'作  用：设置XML文件中指定节点的文本
'参  数：strNodeName   ----节点名称
'　　　　strNodeText   ----要设置的文本
'返回值：0 = 设置成功; 否则返回Err.Description
'**************************************************
Function setNodeText(strNodeName, strNodeText)
    If IsNull(strNodeText) Or IsEmpty(strNodeText) Or strNodeText = "" Then Exit Function
    If IsNull(strNodeName) Or IsEmpty(strNodeName) Or strNodeName = "" Then Exit Function
    If IsNode(strNodeName) Then sMyXmlDoc.documentElement.selectSingleNode(strNodeName).Text = strNodeText
End Function  

'**************************************************
'函数名：IsNode
'作  用：检查一个Node是否存在且文本不为空
'参  数：strNodeName   ----节点名称
'返回值：True or False
'**************************************************
Function IsNode(strNodeName)
    IsNode = False
    If strNodeName = "" Then Exit Function
    If sMyXmlDoc.documentElement.selectSingleNode(strNodeName) Is Nothing Then
        IsNode = False
    Else
        IsNode = True
    End If
End Function

　　我们来看，为什么设置message的值不会成功并且不报错呢？原因就在于setNodeText这个函数的最后一句：

ASP/Visual Basic代码

If IsNode(strNodeName) Then sMyXmlDoc.documentElement.selectSingleNode(strNodeName).Text = strNodeText

　　IsNode这个函数，从函数的注释（还好这个没改）可以看出，作用是“检测一个元素是否存在且文本不为空”，这个函数本来的作用是用于检查传递的数据包中的“自定义元素”和“扩展元素”的，因为各个接口对标准的支持程度不同，因此在获取数据的时候，有的元素可能只是穿了空值过来，那我们就没有必要对该元素进行处理了，所以要用IsNode来检查一下。但是在setNodeText这个函数里没有调用过IsNode检查。就算调用了，按照以前的方式，一定会取到“message”元素的默认值，从而返回True。

　　在新版本中，由于采用了selectSingleNode来取“message”已经取不到了，自然，IsNode这个函数在检查到message的时候，必然返回空值，因为 sMyXmlDoc.documentElement.selectSingleNode Is Nothing这个判断为真了，所以会返回False。于是，sMyXmlDoc.documentElement.selectSingleNode("message").Text 这个语句就不会执行，也就不会引发500错误了。

　　做个假设，如果在修改了取元素的方式之后，没有给setNodeText和getNodeText加上IsNode判断，则必然引发500错误。或者，没有修改过IsNode这个函数，则仍然会返回True，然后引发500错误。正好是加上了判断，于是所有对message元素的值的读写都被忽略了，默认值“操作已成功”就这样被原封不动地回发给所有请求，而响应包中的用户数据元素也一样。

　　下面是纠正bug的代码：

ASP/Visual Basic代码

'**************************************************
'函数名：getNodeText
'作用：获取XML文件中指定节点的文本
'参数：strNodeName ----节点名称
'返回值：解析出来的文本值，
'**************************************************
Function getNodeText(strNodeName)
If IsNull(strNodeName) Or IsEmpty(strNodeName) Or strNodeName = "" Then Exit Function
If IsNode(strNodeName) Then
getNodeText = sMyXmlDoc.documentElement.getElementsByTagName(strNodeName).Item(0).Text
Else
getNodeText = ""
End If
End Function
'**************************************************
'函数名：setNodeText
'作用：设置XML文件中指定节点的文本
'参数：strNodeName ----节点名称
'　　　　strNodeText ----要设置的文本
'返回值：0 = 设置成功; 否则返回Err.Description
'**************************************************
Function setNodeText(strNodeName, strNodeText)
If IsNull(strNodeText) Or IsEmpty(strNodeText) Or strNodeText = "" Then Exit Function
If IsNull(strNodeName) Or IsEmpty(strNodeName) Or strNodeName = "" Then Exit Function
If IsNode(strNodeName) Then sMyXmlDoc.documentElement.getElementsByTagName(strNodeName).Item(0).Text = strNodeText
End Function
'**************************************************
'函数名：IsNode
'作用：检查一个Node是否存在且文本不为空
'参数：strNodeName ----节点名称
'返回值：True or False
'**************************************************
Function IsNode(strNodeName)
IsNode = False
If strNodeName = "" Then Exit Function
If sMyXmlDoc.documentElement.getElementsByTagName(strNodeName).Item(0) Is Nothing Or IsEmpty(sMyXmlDoc.documentElement.getElementByTagName(strNodeName).Item(0).Text) Then
IsNode = False
Else
IsNode = True
End If
End Function

第二种改法：用selectSingleNode的方法，代码如下

ASP/Visual Basic代码

'**************************************************
'函数名：getNodeText
'作用：获取XML文件中指定节点的文本
'参数：strNodeName ----节点名称
'返回值：解析出来的文本值，
'**************************************************
Function getNodeText(strNodeName)
If IsNull(strNodeName) Or IsEmpty(strNodeName) Or strNodeName = "" Then Exit Function
If IsNode(strNodeName) Then
getNodeText = sMyXmlDoc.documentElement.selectSingleNode("//"&strNodeName).Text
Else
getNodeText = ""
End If
End Function
'**************************************************
'函数名：setNodeText
'作用：设置XML文件中指定节点的文本
'参数：strNodeName ----节点名称
'　　　　strNodeText ----要设置的文本
'返回值：0 = 设置成功; 否则返回Err.Description
'**************************************************
Function setNodeText(strNodeName, strNodeText)
If IsNull(strNodeText) Or IsEmpty(strNodeText) Or strNodeText = "" Then Exit Function
If IsNull(strNodeName) Or IsEmpty(strNodeName) Or strNodeName = "" Then Exit Function
If IsNode(strNodeName) Then sMyXmlDoc.documentElement.selectSingleNode("//"&strNodeName).Text = strNodeText
End Function
'**************************************************
'函数名：IsNode
'作用：检查一个Node是否存在且文本不为空
'参数：strNodeName ----节点名称
'返回值：True or False
'**************************************************
Function IsNode(strNodeName)
IsNode = False
If strNodeName = "" Then Exit Function
If sMyXmlDoc.documentElement.selectSingleNode("//"&strNodeName) Is Nothing Or IsEmpty(sMyXmlDoc.documentElement.selectSingleNode("//"&strNodeName).Text) Then
IsNode = False
Else
IsNode = True
End If
End Function

　　这样就能充分利用selectSingleNode的简洁了，但是还要注意哦，由于新版本的createXmlDom不再是自动生成支持的最高版本的xmldom对象，而是生成默认版本（系统默认版本一般都是3.0以下），而低于4.0的版本中，selectSingleNode对XPath的支持是有问题的，不支持带函数的XPath，所以还要小心！

SiteFactory面向的是高端，但是应该更高端

小李刀刀 — Sun, 22 Jun 2008 11:19:00 +0000

我们知道SF与SW定位不同，SF的目标是大站，是高端。

以前没有做大站的经验，我一直坚信SW没有做不了的站点，现在我参与到一个大点（只是大点而已）的网站，确实感到了一些吃力。

第一、分布式部署的无力。WEB服务器虽然可以分出动态静态两部分，但是两部分不能分开在两个服务器部署，因此当后台在大规模更新内容或者上传的时候，对前台访问仍有较大影响。（我们高峰时同时有近二十个编辑在大量更新内容），同时还有在线视频新闻在占用带宽。（这个暂时可以想到图片、附件、视频等静态内容全部采用ftp方式传到另一个服务器后调用来减轻压力）；第二、静态文件和动态文件混合，备份麻烦。目前网站目录不包含数据库有近10G文件，打包一次需要近3个半小时（在高配置备用服务器运行，主要是静态文件数量多，所以影响速度），如果不备份静态文件，以后要生成几十万的静态内容可能更花时间和人力。

第三、修改导航栏、模板、静态标签之后，需要重新生成大量的静态页，可以采取shtml服务器端包含来解决部分问题，但是不能彻底解决问题。

以上只是目前已经遇到的问题，我们期待采用采用SF来减轻目前的压力或者解决问题。因此对SF有这样的期待：

1.结合URLRewriter功能，让所有生成的静态文件统一存放在指定的目录比如“Achive”或者“html”文件夹下，但是访问地址允许隐藏这个根路径，也就是静态首页是“/html/index.html”但是访问地址还是“index.html”。这样我们只需要对配置文件夹、上传文件夹和生成文件夹赋予写权限，不用给根目录写权限，从而提高安全性。也方便备份和自定义开发程序文件；

2.允许生成静态xml而不是静态html，在客户端浏览器里通过xslt自动转换成html输出实现网页结构，结合css实现网站表现，从而彻底将网页的内容、结构、表现分离，以减小静态文件尺寸，节约服务器空间、资源和带宽；修改模板时不用重新生成，公共数据可以共享，网页更加符合WEB标准。

3.允许后台程序和静态数据部署到不同服务器（点击数、用户登陆状态等可以通过ajax、webservice等任意方式实现，但是纯静态内容和后台管理可以分开），比如用admin.xxx.com访问管理系统，生成时远程发布到www.xxx.com（可以ftp生成或其它任意方式实现），用户访问静态内容时不受后台管理操作影响，缓存也只占用后台服务器空间，可以将主站速度和性能发挥到最大。

4.专题已经实现了专题分类和专题两级，希望允许专题分类有独立一个页面，可以理解为专题首页，例如“汶川地震”这个大专题，允许有一个专题页，在该页面中灵活调用下属各个专题栏目的内容，比如有“救灾进展”、“专家访谈”、“记者播报”等子栏目，且大专题页可以有“专题描述”、“专题头条”等一些无需设置子专题的内容。目前的专题栏目无法实现任何一家门户网站或者新闻网站的专题需求。必须通过自定义页面或者用一个同级专题来实现大专题功能。SF可以采用节点来实现，但是那样的话专题完全失去了意义。

从SF1.1版本的进步看到了PowerEasy2006随着SP发布逐渐成为经典的影子，期待SF占据70%大中型网站市场的一天！还期待动易的WEB2.0系列套装的出台，讨论区、博客、圈子、SNS、Digg，基于统一的用户中心，一个都不能少。

静态页面生成的思考

小李刀刀 — Sun, 22 Jun 2008 10:24:00 +0000

　　现在的网站管理系统都喜欢采用生成静态网页的方式，以减轻服务器端处理过多动态解析的负担；实际上在asp.net、JSP这类编译执行的系统中，这个负担已经被大大减轻，生成静态文件同样是一大负担。当然，生成文件的慢是管理员体验，而首次访问慢是用户体验，从这个角度来说，服务器端生成静态文件还是有必要的。

　　但是我们不得不考虑到目前流行的html静态页生成的后遗症——后期维护，实际上这也正式目前我们团队在工作中已经遇到的大问题。

　　我们的网站每天更新量大约在2000条信息左右，目前仅新闻频道就已经有几十万条信息，我们每天同时有十多名甚至二十多名编辑同时在线更新。目前我们的网站目录已经有近10G大小，每次把网站文件打包需要三个多小时（不包括数据库，数据库是SQL Server）。因此编辑工作繁忙的时段，上传、生成等工作集中在一起，后台速度严重降低。

　　除此之外，每当我们需要对网站的栏目、页眉、页脚等方面进行一次改动，就不得不重新生成静态文件（现在我们采用生成shtml文件，服务器端包含页眉页脚的方式，已经基本解决这个问题），或者我们的网页模板进行了改动，必须重新生成静态文件。

　　这一切造成网站的规模越大，后期维护难度越大，成本越高。

　　针对这一切，我想到静态生成的另一种方式，当然，会增加模板制作的难度，但是同时却有更多的好处，那就是进一步分离网站的内容和结构。

　　我们知道生成静态文件最大的目的是减少数据库查询。生成静态页只需要一次请求就得到页面内容。那如果我们生成静态xml内容呢？这样一次生成之后，内容页以后基本不用再次生成（这相当于以前用文本数据存储的形式，但是文本数据存储是服务器端脚本通过I/O方式读取文档，而xml静态内容是客户端直接请求xml，完全无需服务器端做任何解析或者运算）。

　　有人说，生成xml了那怎么实现多姿多彩的网页效果啊？我们知道xslt可以把xml格式化成html，而且这种格式化可以在服务器端完成也可以在客户端完成。因此我们完全可以输出的就是指定了xslt的xml文件。内容很少，不需改动，就算改动了，也只需要重新生成当前的xml文件，磁盘读写内容大大减小。

　　基本的实现思路和带来的好处如下：

服务器端生成静态的xml，xslt相当于页面模板，是固定的，css文档是外部的。xml负责内容，xslt负责结构，css负责表现。
如果一个网站需要改变风格，比如颜色、背景和简单的布局变化，只需要写css就可以实现；如果更进一步，需要改变页面结构，只需要修改xslt（千万文章也只是一个或几个xslt）。立即更改立即生效。
不用在每次改版的时候重新生成任何的静态文件；并且，我们可以把公共信息单独输出xml，不和内容页混合在一起，要知道，一个xslt并不是只能单独处理一个xml.如此以来，当我们改变了导航结构等公共信息，依然只需要重新生成一个文件，就像更新了一下缓存。
用户访问的时候，每次只下载内容部分，不需要重新下载xslt和css，等于不用ajax却实现了局部更新。

　　这个思路并不是首创，我上网查找相关资料的时候发现有不少同类思路。动易系统在ASP版本中也实现过栏目导航的xml输出，不过只是为了让flash等非asp的应用便于读取栏目结构罢了。另外还有人成功实现了生成静态xml，采用Ajax方式在客户端实现页面内容的变换。

　　可见这并不是一个不可行的思路，当然具体实现起来需要解决很多问题，而且它也有它的缺点：

　　网页制作从静态html模板+标签变成了css文件和静态html（页面设计师实现）+xslt模板（UI工程师或者程序员实现）+xml标签数据和内容数据（应用开发商实现）；

　　但是这个困难只针对一个环节，就是建站环节，而事实上如果官方提供的xslt能够输出结构优秀的html结构，那么设计师其实不需要修改xslt对最终html文档结构做大的变动就可以对网站样式进行彻底地改变。

　　而且这样以来，程序员的web标准知识欠缺或者不了解xhtml，不能输出优秀的符合大家需要的html也不会影响到高水平站长对web标准的追求。

　　我坚信如果这个方案能够得到完善并实施，对于网站管理者来说，绝对是利大于弊。

动易SW中的一个严重但不影响使用的bug(一)

小李刀刀 — Wed, 18 Jun 2008 12:20:00 +0000

BUG描述：整个动易API接口的响应功能，除了操作状态码正常，其它部分完全失效，不会返回错误提示，也不会返回用户信息。

BUG重现：在启用了整合的站点，直接访问/API/API_Response.asp，将会看到1（表示请求不正确或者操作失败），以及操作已成功完成（操作成功返回的默认值）。就表示该BUG存在。

BUG影响：大部分情况下，各个应用程序并不会向动易请求用户信息，因此除了在登陆失败、注册失败等失败操作会提示用户“操作已成功”的假象以外，暂时不会造成其它影响。

　　动易SW里有这样一个问题，只有启用了整合接口并且曾经在整合的其它系统中遇到过错误提示的朋友才会发现：

　　每当整合出现问题或者是登陆、注册等一系列操作出错的时候，我们知道以前是返回错误的具体提示，包括服务器缺乏相关组件，或者接口配置错误，或者用户信息错误等，都会有不同的提示。到了SW里，这些操作同样也会返回错误，不会让你操作成功。但是错误的提示是什么呢？全部都是“操作已成功完成”，这个搞笑的问题出在哪里呢？

　　以前设计API的时候，考虑到最常见的情况是用户注册、登陆、注销这些日常操作，而这些操作里又是成功的居多，所以我在用于返回信息的Response.xml模板里，设置了默认返回状态为0（表示成功），默认返回信息为“操作已成功完成”。这就是这个bug的缘起了。

　　那么，以前老的版本反而没有这个问题，为什么新版本里出现这个问题呢？第一反应：当出现错误的时候，没有修改message，也就是错误提示信息。好，我们打开API_Response.asp检查一下，发现当操作错误的时候，代码是这样的：

If FoundErr Then
    sPE_Items(conStatus, 1) = "1"
    sPE_Items(conMessage, 1) = ErrMsg
    prepareXML (False)
    WriteXml
Else
    sPE_Items(conStatus, 1) = "0"
    prepareXML (False)
    WriteXml
End If

　　我用黄色背景标记的这行，翻译过来就是“设置提示信息的内容为ErrMsg（具体的错误信息）”，说明不是没有修改，于是我们继续往下查，sPE_Items这是一个API使用的全局数组，二维的，sPE_Items(a, b)，a代表xml里的不同元素，b为0标识我们要访问的是元素名称，1标识我们要访问的是元素里的内容；而conMessage是一个常数，实际上它等于4。在全局数组里sPE_Items(4, 1)代表的就是xml中message这个元素的内容。

　　接下来是prepareXML(False)这个函数。这个函数的作用是加载xml模板，然后用数组里的内容去替换默认值。经检查，在prepareXML这个函数里，当返回出错信息的时候的代码如下：

ASP/Visual Basic代码

If intIndex <> conAction And intIndex <> conSyskey And intIndex <> conUsername Then
setNodeText sPE_Items(intIndex,0),sPE_Items(intIndex,1)
End If

　　这里不会有什么问题，看来问题就出在setNodeText这个函数上了。新版本中的这个函数是：

ASP/Visual Basic代码

'**************************************************
'函数名：setNodeText
'作用：设置XML文件中指定节点的文本
'参数：strNodeName ----节点名称
'　　　　strNodeText ----要设置的文本
'返回值：0 = 设置成功; 否则返回Err.Description
'**************************************************
Function setNodeText(strNodeName, strNodeText)
If IsNull(strNodeText) Or IsEmpty(strNodeText) or strNodeText = "" Then Exit Function
If IsNull(strNodeName) Or IsEmpty(strNodeName) or strNodeName = "" Then Exit Function
If IsNode(strNodeName) Then sMyXmlDoc.selectSingleNode(strNodeName).text = strNodeText
End Function

　　以前的版本中代码是：

ASP/Visual Basic代码

'**************************************************
'函数名：setNodeText
'作用：设置XML文件中指定节点的文本
'参数：strNodeName ----节点名称
'　　　　strNodeText ----要设置的文本
'返回值：0 = 设置成功; 否则返回Err.Description
'**************************************************
Function setNodeText(strNodeName, strNodeText)
If IsNull(strNodeText) Or IsEmpty(strNodeText) or strNodeText = "" Then Exit Function
If IsNull(strNodeName) Or IsEmpty(strNodeName) or strNodeName = "" Then Exit Function
If IsNode(strNodeName) Then sMyXmlDoc.getElementsByTagName(strNodeName).Item(0).text = strNodeText
End Function

　　区别就在于，新版本用selectSingleNode这个方法获取节点，以前版本中我用getElementsByTagName().Item(0)这个方法来获取节点。两个方法都是返回xml文档树中的一个元素对象。新版本的代码简洁，直接从树中读取一个元素，而我的方法是读取文档树中所有标签为strNodeName（本例中指的是message）的元素列表，然后取第一个。

　　我排错的时候看到这里就已经明白问题所在了。因为当初我第一次写到这里的时候就犯过新版中这个错误。selectSingleNode这个方法的参数类型是XPath，而getElementsByTagName这个方法的参数类型是string。我们这里给的“message”，不是一个XPath，如果在我们的文档中用XPath来标识这个元素，正确的应该是“/root/body/message”，但是由于sMyXmlDoc这个对象取得是xml文档树的根元素，也就是root，所以其实也可以用“/body/message”来访问到。文档中只有一个message元素，因此也可以用“//message”来访问。不管用哪一种都行，但是用“message”是不对的。

　　所以这里给xml中所有body的子元素赋值都会失败。这就是问题所在了。

　　同理可知，在新版本的接口中，如果是整合的程序向动易发送请求，那么不管什么请求，返回的xml包中，都只有两个有效数据，一个是告诉对方响应者是动易系统，另一个就是告诉对方操作状态是成功还是失败。至于错误的具体提示，只有默认值，而其它的数据，比如检索用户信息，返回的则全部是空值。还好目前的整合中基本上不会用到这些元素，所以也就成了一个“严重”但不影响使用的bug了。关于这个bug为什么没有引发500错误以及如何修正，下次我再继续说。

　　除此之外，动易的新版本接口还增加了一个新元素（sex），可以理解为符合接口规范的自定义元素，但是这个元素表示的是用户性别。这是在标准中定义的必备扩展元素，元素名称是gendar（英文单词意思是性别）。等于放弃了对标准元素gendar的支持，增加了一个自定义元素sex。

　　不知道三方是否在这个新增元素上做过沟通取得了共识。如果没有的话，那么这里又是一个新bug，就是通用注册的时候，其它程序将不能通知动易记录用户的性别，动易也没法通知其它用户。

　　我第一次看到这个新增元素的时候百思不得其解。如果是gendar命名不恰当，要改的话，那应该会发公告通知PDO接口规范更新到1.1或者2.0，新增sex元素，gendar元素状态变为“不推荐”，这是w3c在xhtml规范里喜欢用的方式。先不推荐但是还兼容，让你有时间慢慢改，以后时机恰当再取消。

　　但是我奇怪的是gendar无论从语意上讲还是从哪方面讲，都不算是命名不规范的元素啊，甚至是比sex更规范的元素。sex只不过是在部分web应用里习惯的用法而已。其英文单词意思是“性”，而不是“性别”。

　　莫非做这个修改的技术员在修改接口的时候不看接口规范？不得而知了。但是对于selectSingleNode不能根据元素名称选择元素这个问题，的确是不应该犯的。

　　发现我写的代码被更改并不是因为我写错了，本来应该是高兴的吧，但是我却高兴不起来。我依然是动易的忠实FANS，我希望它更好。

给UCenter的拥蹩们泼点冷水

小李刀刀 — Fri, 23 May 2008 03:32:00 +0000

康盛创想“七剑合璧”围绕着UCenter同时发布，不仅为站长同时提供了建立各种类型网站的全套解决方案，而且还充分实现了多系统之间的用户数据完美整合，并且解决了跨域条件下单点登录等问题。让很多开发人员都眼前为之一亮。

在康盛创想的论坛上能看到有不少JSP程序、ASP.NET程序员都在咨询或者说抱怨官方的开发文档和示例太难看懂，完全是基于PHP的，如果不把PHP搞懂，很难实现在其它开发平台下的接口开发。而官方的回答只是“以后考虑”。

动易SF 1.1的发布公告中也指出基于UCenter的接口已经列入开发计划中。令广大动易站长欢欣鼓舞。

但是，我却不得不在这里给众多开发人员和站长们泼一盆冷水——基于目前的UCenter，是没办法开发其它平台的接口的。原因很简单，UCenter服务器端默认了客户端的接口路径为“应用URL” + “api/uc.php”，而且这个是不能在配置文件或者后台修改的。

也就是说，不管你在什么平台下，是什么开发语言，你的接口必须为uc.php。那么，只有一个解决方法，就是在你的服务器上映射.php的后缀到你的程序语言的解析器，让.php也变成asp文件或者.net页面的后缀。那你的站点就不可能再同时支持php和asp，或者php和jsp，或者php和asp.net。而如果你是虚拟主机用户，你需要做的事情更多。

我们可以通过简单的方法修改UCenter，使之支持各平台语言的接口（要修改的文件只有4个左右），但是如此一来，等于是第三方开发人员或者说二次开发人员需要对服务器端进行修改，那已经不像是一个“通用平台”的问题了。

其次，在跨平台的信息传递中，UCenter大量使用的是Get/Post方式发送URLEncode编码的数据，而不是在所有平台所有编码语言下都有良好支持的xml格式。这样开发人员不得不继续花费大量时间来处理编码问题。

还有，UCenter由于采用PHP开发，大量使用了PHP的特性的东西，比如UNIX时间戳，比如键值对的数组，而在其它语言平台中，对这些东西的支持是各有不同的。虽然能够处理，但是却非常麻烦。

UCenter目前给我们带来一个最大的启发，就是一个中心，多套应用的模式，以及采用P3P来实现跨域Cookie处理的思路。

我相信，随着UCenter的出现解决了一系列跨站整合中的问题后，完善的跨站用户中心应该会很快出现。而UCenter如果不在下一版本中做大规模的改变，它是不太可能成为最终的通用整合中心的。至少这么久以来，我们可以看到康盛自己的.NET论坛都还没能支持这个UCenter，就能说明一些问题。

PHP渐成合围之势

小李刀刀 — Mon, 28 Apr 2008 12:28:00 +0000

　　康盛创想4月21日宣布同时发布旗下六款WEB应用产品的新版本。这次康盛创想以UCenter为核心，将旗下已经占据巨大市场的Discuz论坛产品与其CMS产品——SupeSite，多用户博客系统——X-Space，多用户商城——EShop，视频共享产品——Supe-V，SNS产品——UCenter Home第一次完整地组成了一个整体，涵盖了门户网站、电子商务、Web2.0社区、Web2.0个人社会化网络、网络视频分享、网站推广（Inzens营销）等WEB应用的技术所有方面。

　　随后，DedeCMS、PHPCMS、Pbdigg等也迅速发布了支持UCenter接口的版本。由此，PHP平台的众多产品开始逐渐形成了以康盛创想领头的大联盟局面。虽然他们之间并没有明确的成立“战略合作伙伴”或者同盟关系，但是至少对于PHP平台的用户来说，这下子可以彻底解决不同产品应用之间的整合问题了。PHP平台上的不同应用产品，拥有了一个统一的用户接口——UCenter。相信在这些主要产品的领头下，其余的PHP开发者没有选择的余地，只能选择对UCenter的内置支持。如此则PHP对ASP、ASP.NET、JSP等平台的合围之势开始渐渐形成。

　　而ASP、ASP.NET平台的各方产品还在各自为战，用户还在为用户整合，单点登陆等问题苦恼不已的时候，面对PHP来势汹汹的攻势，将如何应对呢？

　　当初动易、动网、Oblog的三方联盟推出PDO API接口，受限于多方合作开发的影响，虽然有了统一的接口，但是用户结构、认证模式等的巨大差异却难以解决。三方接口的开放性是面向任何平台和数据库的，却响应者寡。而如今UCenter摆明车马将PHP以外的平台排除在外，不知道各方是何想法。

　　目前ASP平台上似乎没有一家能够同时提供建站所需全部Web应用的产品，而ASP.NET平台上，国内的众多产品中，动易的SiteFactory暂时还面对着用户使用习惯的推广压力；动网的Dvbbs.NET似乎并没有取得太大的成功，Cvb、ASPNET Forum等产品一直都没有能够取得过半的市场。反而是康盛创想的DiscuzNT依托Discuz!的用户群，进展似乎比较顺利。

　　前几年我们还在说PHP在欧洲应用比较广泛，国内受操作系统、服务器环境的限制，应用不够广泛。转眼之间，ASP被微软抛弃，ASP.NET步伐缓慢，PHP步步紧逼。

　　如果国内的ASP/ASP.NET开发者还没有警醒，还依然各自为战，那靠谁来守住阵地？靠用户的忠诚吗？看看如今的雷奥吧，十几个在线用户加上凑数的游客，置顶帖是《还在开发Leobbs的几个论坛地址》……

　　用户只对易用、强大的产品忠诚，不会对某个平台，某个品牌忠诚的……

目的到底是学技术还是建网站？

小李刀刀 — Tue, 15 Apr 2008 11:29:00 +0000

　　前一篇文章说的是建站产品的开发商，而这篇文章，则想对用动易建站的站长们“指手画脚”一番。我曾是动易系统的开发人员，但是相比之下，我做站长的时间更长。从Perl用到ASP以及PHP，我建站、运营网站前后都已经有了6、7年了。当站长的时间越长，越体会到在建网站这件事情上，真正是“无招不破，唯快不破”、“唯稳不破”。

　　其实很容易想，在你因为某种需要而去访问一个网站的时候，你最在意的是它的稳定服务和快速响应还是它后台技术的先进与否？

　　说ASP将被淘汰，这是因为微软的态度问题和ASP本身的一些弱点。但是说了好几年了，放眼望去，今天的互联网上，ASP依然风光。我的这个博客从2004年开始建立，直到今天。我自然也在考虑改换平台，目标是WordPress，站点都已经搭在wukangrui.com上开始运转了，但是我一直没有关闭这个站点，原因没别的：不管ASP有多少弱点，有多不行，像我这样一个小小的网站，它足够强大和足够方便。更重要的是，这个站点经过我多年经营下来，每一个细节都符合我的要求和习惯，也符合我的朋友们和访问者的要求和习惯。

　　大家都说JSP和ASP.NET才是趋势，是前途。但是我宁愿继续用ASP和PHP，也从来没考虑过ASP.NET或者JSP的blog程序，不是我不求上进，也不是玩不转。只不过是因为在够用的前提下，ASP和PHP更轻量化更方便，很方便我随时随地对代码和程序进行调整和改进，而不需要任何额外的条件——毕竟我这个只是个业余的事情，而不是每天坐在电脑前面以维护我的博客为工作。我不需要dotNet平台和MSSQL，也不需要JDK+TOMCAT+Oracle。

　　这就好比我只是想要削个苹果，用个小刀就够了，何必去拿个铡马草的大铡刀来费九牛二虎之力呢？

　　当然，我可以不用小刀，可以用瑞士军刀，虽然暂时只需要它的刀，但是有备无患毕竟不错，说不定待会儿就塞了牙想要把牙签或者想开个汽水瓶呢？这是没错的，有总比没有好，多一点总比少一点好。但是就算用瑞士军刀，我也要买一把组装好的刀。

　　JSP就好比是铡草砍骨头的大刀，力大无穷但是玩小巧未必最强，而ASP.NET好比是一把带着倒刺的军刀，够酷够强但是却要你能用得好。而ASP、PHP就像是小巧的水果刀，针对削皮这样的事情，反而是最佳的选择。

　　就是基于这样的原因，我宁可继续用PJblog这个最后一次更新已经是07年的“老旧产品”。既然各项功能都稳定且满足需要了，何必还要一直折腾呢？

　　动易论坛上现在对SF“深恶痛绝”，非常“恨铁不成钢”的一些朋友，不知道你的站点是不是规模大得SW无法承受，或者是你对ASP.NET已经熟练到可以不需要动易的详尽文档和教程就可以轻松玩转？

　　我相信更多的动易老用户现在都是已经用SW建立了稳定的正在蒸蒸日上的站点，然后一边关注和测试了解SF，一边学习准备着。等到ASP.NET更普及和稳定，等到SF更完善的时候，他们也做好了技术上的准备，那时候又将是一片热火朝天做模板、Show站点的时候了。

　　我也是其中之一，我已经用单独的域名为我管理的SW站点建立了另外一个SF做平台的站点，没有产品详尽文档的时候来探索SF的秘密的确是极具乐趣的。很多新特性新功能，如果不是开发人员在论坛上提及，我甚至根本不曾想到——比如写入标签……

　　论坛上经常嚷着“SF垃圾”、“SF是倒退”、“SF不如SW”的朋友，不知道你装了SF以后，花了多少时间来探索它呢？

　　写本文没别的意思，只是希望曾经信任动易，为SW彻夜不眠的朋友们，花了那么大的时间精力来学习和了解SW，花了那么多的金钱和心血终于用SW建好了一个满意的站点，不要为了追求时髦和一些并非急需的新功能急急忙忙往前走。好好欣赏一下自己的成果，享受一下自己的成果，也让你的用户安稳地享受一下你的劳动成果。

　　研究和学习一定要新，要与时俱进。但是正式运行的东西一定要快，要稳。就算别的，也为了你的Google Rank和Alax统计吧。虽然是做个人网站，也不应该凭站长一个人的好恶而让网站总是处于改版、调试甚至不稳定中。不管做什么，做好准备工作吧。

动易SiteFactory遭遇滑铁卢？

小李刀刀 — Tue, 15 Apr 2008 10:40:00 +0000

最近动易论坛上针对SiteFactory的批评之声此起彼伏。都在嚷SF不如SW，SF不易用，SF功能不强大。

这或许是动易营销策略上的一点点失误，SiteFactory本来定位就与SW大相径庭，SW的目标是让建站技术平民化大众化，因此开发和推广时极尽一切能事让这个产品上手极易，教程不厌其烦地详细和基础，培训课程开了一期又一期，上到公司老总下到前台客服都要到论坛上来为免费用户解答各种层次的问题。

在产品定位与营销策略相配套的情况下，SW系列获得了空前的胜利，30万的站长为动易赢得了赞誉和成功。但是这其中占据绝大部分的是刚刚学做网站入门的新手，或者小型个人站点的站长。商业用户或者是由于有良好的售后服务，或者是有自己的技术团队和人员，因此在论坛上很少听到他们的声音。

在ASP已经呈现颓势和动易的业内地位逐步提高的时候，动易公司选择ASP.NET开发高端产品，这本来是非常英明的决策。但是动易公司的前期宣传让论坛上的绝大部分用户将SiteFactory这款非入门级的产品当成是了SW的升级换代产品，充满期待。

ASP.NET的编译执行特征决定了它用于正式建站的速度要比单机调试的速度快；SiteFactory的高端定位和强大架构决定了它的复杂，无与伦比的开放性决定了它对二次开发技术的高要求。而在巨大的开发压力下，动易开发团队实在没有精力能够在全力投入产品开发和完善的同时再完善产品开发文档和使用手册。

我以前就说过，由于之前的系列产品的特性，动易的用户群整体技术水平相比其它比如discuz、dedecms等的用户群要弱一些。而动易新版产品中包含的大量二次开发技术所要求的xml/xslt、T-SQL、ASP.NET环境配置和调试、错误排查和处理，以及非常创新的“写入标签”等功能，都对开发技术要求较高。

相比以前版本只需要html+css知识甚至连这些知识都不需要就可以使用，新版本的技术要求对比太大了。反之，对于大型商业网站而言，有自己的软件工程师、技术员和设计师，他们恰恰需要的是一套开放性越强越好，软件工程越完善越好的系统。

因此动易SiteFactory目前遭遇的这种情况，实际上最大的原因并不是产品开发周期或者产品功能设计等方面的原因，不是产品开发遭遇滑铁卢。而是产品定位和推广营销策略上没有达到一致导致的。

动易现在面临的一个困难的选择：如果继续按照产品定位发展，目标是大型客户商业客户，那么由于与之前的强力宣传和动易产品一贯的特征有较大差异，很可能继续丢失一些小型网站用户、个人站长用户。而如果此刻改弦易辙走回平民化大众化的路子，则需要对产品从一些核心模块（标签和模板）进行彻底的修改，最后能否达到较好的效果还未可知。

我觉得动易现在应该正视已经面对的问题，调整营销策略，对SiteWeaver和SiteFactory两套产品在定位上、性能上、功能上、适用性上的区别再做大力的宣传。让普通用户搞清楚自己的需要和恰当的选择。否则大量的SiteWeaver用户不知所以盲目转向SiteFactory，最后由于产品不对路用不好而转向竞争对手，将是一个巨大的损失。

动易的SiteWeaver历经5年发展，终于修成正果，正是应该大放异彩的时候，却由于语言平台的原因而在最优秀的时候被当作“过时”而放弃，那只能是动易和广大站长双方的损失。但是动易在近一段时间来对SiteWeaver这个成熟产品、顶梁柱的重视和宣传却不及SiteFactory这个犹如当初动力3.51程度的新宠，恐怕最终会造成两代产品不能顺利交接班。

五年风雨路十万用户情

小李刀刀 — Mon, 07 Jan 2008 12:51:00 +0000

——仅以本文献给佛山动易公司五周年庆典

“动易”这两个字，是从2004年算起的，但是如今大名鼎鼎的动易网站管理系统的历史，却是从2003年开始的（参见http://www.powereasy.net/PowerEasy/2044.html）。当年因一套“动力文章”而扬名立万的webboy，如今已是业界知名的动易老总；当年每更新一个版本都要到各大论坛去发发贴做做广告的动力文章系统，如今已经是一举一动都牵动无数用户的SiteWeaver建站平台。

动易公司的发展速度，的确是快得惊人。2004年成立动易公司的时候，连老总都是“兼职员工”，上下三四个人，到公司第一次在深圳召开大会的时候，十名员工还要分别从全国各地临时聚集在一起。短短四年间，公司已经拥有佛山总部和广州研发中心两大阵地，完整的开发+服务+市场+管理团队。

刀刀是幸运的，有幸见证了动易的艰难创业、快速发展的整个过程并参与其中。

2003年9月29日，我在动力论坛发布第一个帖子《我升级完了》（参见http://bbs.powereasy.net/dispbbs.asp?BoardID=67&ID=7064）。那时我才接手6571.net这个高校论坛一年半的时间，从动力3.0版开始成为动力的用户。从3.5版开始在官方论坛发言。然后一发不可收拾，从3.5版发布当天开始，我从原来的一天潜水12小时变成一天在线16小时也发言16小时。先是看到不少用户升级遇到问题，对新版本议论纷纷，于是出来给大家帮帮忙。那个时候的动力系统功能自然与现在的版本功能上相去甚远，很多需要不可能通过系统提供的功能来完成，需要自己修改，而我的网站在3.0的时候就已经把原系统修改得“遍体鳞伤”，我都升级成功了，别的用户自然也不会有什么大问题。于是我就一直在升级的问题上给大家帮忙。9月30日由于朋友们问题太多，我干脆通宵在线帮忙解决升级的问题（参见http://bbs.powereasy.net/dispbbs.asp?BoardID=67&ID=7371）。那时候“全站系统”还不像现在这样遍地都是，依然是“文章系统”大出风头的时代。而动力系统的文章管理功能当时已经是在文章管理系统里非常强大的了。从那么多用户彻夜不眠地想方设法升级就可见一斑。

升级的问题其实不难，只是很多人多动网论坛的用户结构不熟悉罢了——那时候的动力3.5的用户表其实就是一个动网6.0的用户表加上几个字段。而我恰好之前一直在捣鼓动网插件，所以就比较熟悉。实际上那时候我的水平，也就是写点简单的SQL语句和改改别人的代码，有时候做网页想要个效果还得现去网上抄人家的代码。就这样一天多时间大家基本都升级得差不多了，再遇到问题的也都可以在论坛找到解决方法了。这时候第二个问题开始出现了——整合。

我整合完以后半是炫耀半是多事，在论坛上发了一个《My动力3.5连接动网论坛6.0标准版过程详解》（参见http://bbs.powereasy.net/dispbbs.asp?BoardID=67&ID=7085），结果就从这个帖子开始，我之后的几年就一直没跟“整合”这两个字脱过关系。教大家整合6.0，然后有朋友“强烈要求提供整合6.1”的方法，到“要求积分整合”，要求“文章共享”……

网友的“要求”其实也就是如今动易每每在新版本发布前的“功能建议征集”。

那时候动易公司还没有成立，webboy既要开发，又要解答论坛上的问题，又要处理bug，又要宣传……，而论坛上为数不多的几个版主就成了“技术支持”。

当时自己在做网站，所以几乎可以说不需要网友来测试，我提供的修改和hack版本有什么问题往往是我自己第一个就发现了。大家从来没说，其实我自己最清楚，刀刀的版本更新最频繁——因为发现问题修改完立刻就更新，有时候更新了之后发现问题根本没解决——当时我还没有加入动易，还没有正规得到过编程方面的指导，但是网友们很宽容，尽管程序难免有各种各样的问题，但是因为热心解决，大家依然是赞誉不断。（对于原版程序更是如此，网友们有了问题，第一时间是找“高手”帮忙解决，然后是“等待新版本或者补丁”，webboy本人也经常在论坛上帮大家解决各种问题，有的是程序的bug，有的只是个性化修改需要，动易公司的不少“元老”都是在那个时候冒出来的，刀刀在论坛上搞风搞雨只是小小插曲而已，比如nt2003就是当时为大家写插件的一大高手，只是做事低调，发完就走，不像我这么吵吵嚷嚷的，嘿嘿。参见http://bbs.powereasy.net/dispbbs.asp?BoardID=67&ID=11195）。

我就这样靠着修改和提供webboy的作品在webboy的论坛上混出来了（声明：我可是向webboy申请了修改授权的，嘿嘿），成了版主，成了“高手”——实际上写个判断都经常忘掉写End If。但是从那个时候起，动力的论坛上就一直形成了热心解决问题的气氛，这种气氛，一直到动易公司成立之后也没有改变，并且还对动易的企业文化产生了很大的影响，后来的动易公司成为同行业里服务和支持最好的公司，未必没有这个原因在里面。

2004年动易公司成立，老大webboy是兼职的——广东数学老师，壮志也是兼职的——东北的程序员，雅虎也是兼职的——江苏的美术老师，笑缘大哥也是兼职的——河北的学校领导。在大家的吵吵嚷嚷中开发出了动易系统的第一个版本——4.0。而我也完全没有想到我后来会加入动易。当时还在一心等着官方新版本+动网的新版本出来，我继续我的hack版本开发呢。

有一天，老大找上我，希望我帮忙写动易和动网的整合插件。我当时真是受宠若惊，一惊之下忘了自己几斤几两重，就答应了……

其实当时的整合是很容易的，因为动易4.x版本对用户数据结构没有做什么改动，也就是说还是动网的数据库+新增字段。这样的话我要做的事情其实再简单不过了，就是写一个数据库改变字段的脚本，再照着动力3.51的方法，给4.x版的源代码加上处理论坛cookies的代码就行了。当时我胆子也小，没敢像自己的hack版一样，对动易和动网的cookies判断功能做大手术，老老实实照着webboy在3.5里的思路进行整合，就这么一个简单的东西，我还写了整整三天，而且webboy还亲自给我指导……那确实是难忘的经历，而且从这以后我基本上不敢写完代码自己都还没用就发布了，哈哈……

整合插件由于在3.5版里已经经过了考验和完善，因此到4.x版本照搬后，基本上没有什么问题，用户在升级和整合的时候遇到的问题也比3.5少了很多。没过多久，动易公司招人，我就报名，然后笑缘大哥通过QQ来面试，我就这样成了动易的一员——当时我上大三。

到开发2005版的时候，公司一共10来个人，真可谓是天南地北：广东的webboy，东北的壮志，江苏的雅虎，河北的笑缘，贵州的nt2003，北京的我，还有阿甘和刚刚大学毕业的兔子、必武……

2005版老大把用户模块交给我负责了，这次要重新设计用户数据结构，不再沿用动网的用户表。基本上也不copy动易4.x系列。这是我第一次参与团队开发，也是第一次独立设计完整的用户管理模块。当时由于正在上大学，别的没有，时间有的是。我知道自己基础不行，买了ASP3.0和SQL方面的书，一边写程序，一边从头学。那个时候webboy就像是在带学生一样每天给我指导，从编程本身、从团队合作、从开发技巧……很多方面。我经常是中午到下午和webboy就用户部分的技术做一些讨论和请教，晚上就通宵写代码，到凌晨的时候把代码打包发给webboy然后睡一上午，中午起来之后听webboy的评价和指导，然后继续……

通过这次的开发，我才真正完成了从一个ASP爱好者到一个ASP程序员的变化。写代码也从copy和修改动网的代码，进步到了自己设计和编写——2005版以后的每个新版本的整合程序和同步程序，都是我当时最高水平的体现，可以说，在动易兼职的几年，不如说是在动易学习的几年。而且在动易兼职的经历，也成了我的履历中一笔巨大的财富——webboy带我参加软件博览会，增长见识；webboy让我代表动易和北京国美总店谈生意；webboy让我作为动易的技术支持人员到国防部安装和配置动易系统……没有动易，我的人生里怎么可能会有这些精彩的经历？！

从北京回到云南后，中学的无明确岗位制度的工作让我的时间开始捉襟见肘。我以前一天在线16个小时（包括在二外工作的一年，因为我的工作就是维护二外网站和服务器，开发后台程序），而回到云南后，我大部分时间是抽调到别的单位去帮忙做数据统计、档案核对等……所谓的“本职工作”——建立学校网站，利用强大的动易2006版，我一个人只花了一个星期就搞定了。这时候公司开发团队正在紧张地开发动易asp.net的版本。

我没办法边学习.net边参与新版本的开发，调到培训部工作了一段时间。然后学校这边，新学期开始我要上高一的英语课了，73个学生，同时继续兼办公室的工作——我知道自己不可能再兼职了。要么老老实实当中学老师，要么到动易去专心做开发。我不可能选择后者，作为独子我不可能在父亲全身是病的情况下去闯荡天下——如果那样我何必回云南呢？在北京等着动易北京研发中心成立不是更好吗？于是2007年8月，我正式辞去了动易公司兼职的工作。实际上以我当时的情况，公司早就可以炒我的鱿鱼了——因为我根本不能保证工作时间。辞职的事情，我没在自己的博客上说，公司也没有说，甚至在论坛上一直都保留着我的“管理员”身份。

五年风雨路，动易已经不仅仅是十万网站的后端系统了，但是相信所有曾经和动易一起经历过风风雨雨的人，不论是员工，还是用户，都感受过动易公司的企业文化——用心服务，共创价值。动易公司和她的员工一起共创价值，实现企业的价值和员工的个人价值；动易公司和她的客户一起共创价值，实现企业的发展和客户的成功。有多少付出就有多少回报，动易公司对用户的真诚关注，换来用户的好评和用户，只能用四个字来描述——水到渠成，这是作秀换不来的，这是炒作换不来的，这是投资换不来的。

相信今后的日子，动易公司将和她的员工们和用户们一起，创造更多的价值，孕育更多的感人故事。

首发：http://www.wukangrui.com/20080108/to-powereasy-5th-anniversary.html

裁纸刀下 » 动易

动易SiteFactory目录权限详解

相关日志

动易SW中的一个严重但不影响使用的bug（二）

相关日志

SiteFactory面向的是高端，但是应该更高端

相关日志

静态页面生成的思考

相关日志

动易SW中的一个严重但不影响使用的bug(一)

相关日志

给UCenter的拥蹩们泼点冷水

相关日志

PHP渐成合围之势

相关日志

目的到底是学技术还是建网站？

相关日志

动易SiteFactory遭遇滑铁卢？

相关日志

五年风雨路十万用户情

相关日志

裁纸刀下 » 动易

动易SiteFactory目录权限详解

相关日志

动易SW中的一个严重但不影响使用的bug（二）

相关日志

SiteFactory面向的是高端，但是应该更高端

相关日志

静态页面生成的思考

相关日志

动易SW中的一个严重但不影响使用的bug(一)

相关日志

给UCenter的拥蹩们泼点冷水

相关日志

PHP渐成合围之势

相关日志

目的到底是学技术还是建网站？

相关日志

动易SiteFactory遭遇滑铁卢？

相关日志

五年风雨路 十万用户情

相关日志

五年风雨路十万用户情