2009 年 10 月

由于自己也遇到过类似问题，所以，看到这篇文章的时候 就更为观注，其实文章也没写什么，只是把自己的遇到的问题列了一下，但，能够引起共鸣的就是好文章 。

先贴原文，然后再把我的事情说一下：

项目已经进入数据割接测试一轮尾声，记得刚刚进入数据割接测试的阶段，大家都很茫然，让我们想起了当时数据准备阶段，这一幕又重现了，数据准备是因为数据 及其复杂，业务复杂，大家对其他人负责的业务不熟悉，导致数据准备成为一块绊脚石，然而开发人员都很忙，没有时间一起配合准备。而数据割接测试也同样面临 着类似问题，一方面业务及其复杂，新老系统的设计逻辑和数据结构有很大的差异。而我们大部分人对老系统不熟悉，参与割接的开发人员对新系统不熟悉，导致割 接测试困难重重。

刚开始我们采用的是把老系统线上的数据割接到新系统，然后我们选择几种典型业务按一定条件准备了一些用户，在新老系统中对比这些用户的数据。发现这这些用 户的记录不熟悉，用户的数据又比较乱，不是登录不了，就是密码不对，要不就是没有用户信息，要不就是不能发布宝贝，还要去修改相应的用户信息等等，这样准 备数据一天都快过去了进度很慢。后来大家提出用自己平时用的用户计划好场景，到日常中去构造一些数据，造好后再把这些用户给割接的人，让他们把相应的用户 数据增量割接过来。然后再用这些用户在新系统中做交易，看数据是否正确。另外备用一两个用户，在新系统中做同样的数据，进行比较。有些没办法构造的场景才 选用哪些已有的用户数据去查看。即自己构造的数据和上线上的数据互相弥补

这样做有几点好处：

首先自己构造的数据自己清楚，不用再去找这些用户数据。

其次自己平时用的用户，用户信息都是全的，能登录，能发宝贝，能做交易，能订购，不用再去修修补补，那怕是要修改，修改的地方也少点。

虽然这样一来有点进展，但是还是遇到了很大的麻烦，有很多数据割接过来完全错误，因为新老系统的数据结构很大的差异的问题，很多逻辑不对。而项目中的开发 忙于项目，完全不重视数据割接，后来我们建议新老系统开发人员和测试人员一起配合测试数据割接测试，保证数据的正确性。

针对以上出现的问题，个人觉得首先要保证迁移脚本的正确性，那最好是新老系统的开发人员配合编写脚本。万一项目中开发人员没时间，审核的时候要新老系统的开发人员要一起慎重审核脚本的逻辑。否则不能保证脚本的正确性，那更谈不上保证数据的正确性。

----以上为转贴，来源于：http://rdc.taobao.com/blog/qa/?p=4515

以前在XX公司的时候也遇到过，或者说，任何一个公司在新旧系统更换的时候，估计都会遇到吧？一般在这种情况下，最重要的是保留用户数据，毕竟如果没有用户，那网站也就没有存在的必要了。其次就是用户相关的数据，比如资料信息、历史、或者各种各样的操作。或许你会认为没有什么必要，但有的用户就喜欢翻旧事。前段时间在某群内看到有人把01、02年的贴子翻出来炫耀，以证明自己在某网站的年代长远。所以说，用户是奇怪的。

如果是电子商务的话，还得保证以前的订单和订单相关资料需要完全正确，否则，对谁来说都是一个损失。就象文章最后一段话，其实很多时候都是开发新系统的人在写迁移脚本，而这些人对于老系统并不熟悉，到最后，数据其实是模凌两可的，看上去正常就是皆大欢喜的事情了。其实也不是原始开发人员不做这些事，要知道，IT公司，跳槽情况非常常见，原始开发人员说不定几年前就跳槽了，越是老的公司，在初期的代码就越乱，越往后越感觉无法整合。迷惘中的新开发人员也只能跟着感觉走了。

HOHO

一些小的琐碎。
烧掉的电源线今天拿到了，虽然晚了点，但还是拿到了。毕竟别人也是要上班的，不可能由着我们的时间来

小朋友昨天摔了一跤，嘴唇破了点皮，直到今天还是红红的。

小朋友不肯在这边睡觉，非要到外婆家去，哭着累了才睡着。可怜啊。。。。

老婆的同事邀请她去家里玩，欣欣然去，不知道晚上什么样子回来。HOHO

vampire终于回去了，是上海不适应他还是他不适应上海？又或者其实本来就很勉强？不过，人活着开心就好，无论在任何地方都应该这样。

明天就是11月了，下个月有两人结婚，其一为老婆同事，其二为我的哥们。回家是肯定要回家的喽。

最后，发现自己写代码的速度和效率越来越低下了。怎么回事呢？唉。。。

爱别摸终于咔嚓了。还好，不是电脑，是电源

先是前两天说电池需要召回，去了维修点，他说俺的电脑不属保修范围之内，郁闷，然后我告诉他，我通过软件检查下来是属于召回范围的呀。

他很潇洒说，我这块电池不是在国内经销的机器上的，所以不予保修和召回。我说我在淘宝上买的，他说，那你有保修卡没？一下子傻掉了。。。

看来，以后在淘宝买所谓的行货一定要备保修卡。否则，和买水货没区别啊

以上是一，第二呢，是我的电源线。

可怜的电源线，终于又坏了，为什么要说又呢？那是因为在今年3月份左右，电源线烧了一次，如今刚过半年又烧了。每半年一次啊。

可能是因为我电源线经常折叠弯曲导致的吧，但是，笔记本电源线总要是折叠弯曲的吧，如果这样都不行，那还叫个毛笔记本啊。

等候换线+电源

Nio在http://www.nioxiao.com/archives/949里说到，php的CURL库生成cookie文件时，应当及时清除，否则会发生意料不到的事情

对于php的curl，我想，在我的博客上有一篇介绍校内狗狗的文章，是yhustc写的。他就用到了这个cookie文件。主要是phpcurl在访问时，会把当前的cookie全部写到这个文件里。如果是个人使用，当然是没问题。如果要提供服务给别人，估计就会发现cookie文件不停的写，而且内容都不一样【估计这就是nio遇到的问题吧】

bopo则改进了yhustc的http类，他用的是tmpnam函数，生成一个唯一的，不同的文件。只要在进程内。文件都不会变啦。呵呵

我当初是判断用户登录，每个用户分配一个cookie文件，保证不会和其他人产生冲突。。。HOHO

但看看Nio说的最后一句话，又不太像，他说：

特别需要注意的是，在完成抓取之后，需要把 cookie 文件删除，否则下次抓取时会自动使用原有的 cookie 数据，从而导致一些预想不到的错误（我们今天就被这个问题折腾了很久 :( ）。

但，好象每次访问都会生成新的cookie内容的吧？除非确实需要清空？这个问题，我是没有遇到过，暂时先记录一下。。

有些东西是我们在做网页的时候需要注意的，虽然，不太常用到，但稍注意一下，可能会减轻服务器很多压力 ，以下就是一篇小技巧的文章，了解了这些知识，会给你的WEB网站减轻一些IO的消耗吧。

内容如下：
网页的缓存是由HTTP消息头中的“Cache-control”来控制的，常见的取值有private、no-cache、max-age、must-revalidate等，默认为private。其作用根据不同的重新浏览方式分为以下几种情况：
（1） 打开新窗口
如果指定cache-control的值为private、no-cache、must-revalidate，那么打开新窗口访问时都会重新访问服务器。而如果指定了max-age值，那么在此值内的时间里就不会重新访问服务器，例如：
Cache-control: max-age=5
表示当访问此网页后的5秒内再次访问不会去服务器
（2） 在地址栏回车
如果值为private或must-revalidate（和网上说的不一样），则只有第一次访问时会访问服务器，以后就不再访问。如果值为no-cache，那么每次都会访问。如果值为max-age，则在过期之前不会重复访问。
（3） 按后退按扭
如果值为private、must-revalidate、max-age，则不会重访问，而如果为no-cache，则每次都重复访问
（4） 按刷新按扭
无论为何值，都会重复访问

当指定Cache-control值为“no-cache”时，访问此页面不会在Internet临时文章夹留下页面备份。
另外，通过指定“Expires”值也会影响到缓存。例如，指定Expires值为一个早已过去的时间，那么访问此网时若重复在地址栏按回车，那么每次都会重复访问：
Expires: Fri, 31 Dec 1999 16:00:00 GMT

在ASP中，可以通过Response对象的Expires、ExpiresAbsolute属性控制Expires值；通过Response对象的CacheControl属性控制Cache-control的值，例如：
Response.ExpiresAbsolute = #2000-1-1# ' 指定绝对的过期时间，这个时间用的是服务器当地时间，会被自动转换为GMT时间
Response.Expires = 20 ' 指定相对的过期时间，以分钟为单位，表示从当前时间起过多少分钟过期。
Response.CacheControl = "no-cache"
Expires值是可以通过在Internet临时文件夹中查看临时文件的属性看到的，如：

• 出处：http://kaima.cnblogs.com
• 作者：kai.ma

韩寒一直很风骚，从最初的特招到出书，然后成为赛车手，再然后，继小徐之后成为新浪知名博客之一。独领风骚一阵子。。

他还挺会复制，他说，这是陈毅写的诗，题目是《七古·手莫伸》，内容为：

手莫伸，伸手必被捉。党和人民在监督，万目睽睽难逃脱。汝言惧捉手不伸，他道不伸能自觉，其实想伸不敢伸，人民咫尺手自缩。岂不爱权位，权位高高耸山岳。岂不爱粉黛，爱河饮尽犹饥渴。岂不爱推戴，颂歌盈耳神仙乐。第一想到不忘本，来自人民莫作恶。第二想到党培养，无党岂能有所作？第三想到衣食住，若无人民岂能活？第四想到虽有功，岂无过失应惭怍。吁嗟乎，九牛一毫莫自夸，骄傲自满必翻车。历览古今多少事，成由谦逊败由奢。

这是什么？还是看：http://blog.sina.com.cn/s/blog_4701280b0100fk2m.html

对了，听说孙中界同学已经在新浪进驻了。估计又是一知名博客的候选分子。。。刚发表的感谢信，已经阅读将近10万了。啥感谢信，那得看：http://blog.sina.com.cn/s/blog_62bbbcbd0100fmgq.html?tj=1

这是一篇05年的文章，当然更不可能是我写的。我没有这么深的内涵，但，偶尔我也可以发发牢骚，在转贴完后，我也会写上一点自己的理解。
原文：

文章链接：http://www.dbanotes.net/review/post_6.html，作者为Fenng，看文章的地址链接，就知道这篇文章对于该博客来说是多么早了。

对于站点有没有吸引力，其实我也想说说，很早以前，自己也做过一些论坛、资讯之类的网站，但很快【一年或两年】自己的目标就转移到新的方向去了，原来的东西就几乎全部被放弃，论坛也不太维护了，资讯也不更新了。慢慢的人也就越来越少了。是啊，你站长都不专心，别人怎么会在意呢？论坛也就这样的被关掉，资讯嘛。。看http://phpoo.com就知道了。。。再往 下，估计phpoo.com就成了我收集资料的网站了，呵呵

突然想起老毛说的一句话：做一件好事并不难，难的是一辈子做好事。做网站也一样啊，做一个好网站其实并不难，难的是，你把它坚持下去。。。

还好，我的博客还活着，我总不会放弃它的。。52cd.net的关闭只是因为备案的关系，会开通的。我有很多东西等着发布呢。。

一直以来，我都以为是我的电脑出了问题，事实上，我的电脑最近也出了点问题。
我以为我不能同步我的书签是因为DNS出问题了，确实，最近一段时间，服务器的DNS不能打开一些网站，出了点小问题

然而让我伤心、彷徨的是，xmarks，真的出事了。随着一个又一个的网站的被墙，一个又一个新的站点的被打开，我不知道这样的一个书签站点怎么了。

唉。或许，这次被墙之后，国内也会出现一个大型书签站点吧？就和当年的谷哥被墙一样。

默哀一下

看看与我同样命苦的朋友们：http://www.google.com/search?q=xmarks+%E8%A2%AB%E5%A2%99%E4%BA%86&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

再后来，在某篇文章中发现了mozilla实验室的weave sync软件，好象也能实现这个功能，安装了一下，回家就可以测试了。。。

下载地址：https://addons.mozilla.org/zh-CN/firefox/addon/10868

【本文已经被我编辑了N次了，再来编辑一次】

其实，说白了，同步很方便，由于mozilla的配置、信息，基本上都是用sqlite来储存的，所以。。。其实本地的sqlite上传到服务器，然后把线上的数据库同步到本地，当然需要对比一下数据，黑黑

以下是老王梳理的内容，bootstrap对于ZF来说非常重要，很大一部分人的程序损耗，都在这里。。。。

原文地址：http://hi.baidu.com/thinkinginlamp/blog/item/419f36d34b68c40a3af3cfc9.html

说点题外话，单就框架而言，对我而言使用CakePHP要比使用Zend Framework顺手得多，不过最近CakePHP陷入了多事之秋，Phpnut，Gwoo，Nate彻底闹僵，Gwoo和Nate选择离开，据坊间传闻他们已经开始另立门户，稍后会释出一个CakePHP的衍生框架：Lithium。虽然CakePHP官方已经表态会一如既往的继续前进，但毫无疑问在众多开发者眼中，CakePHP的前景已经不再明朗，其是否能继续保证PHP框架领头羊的地位也越发充满疑问。

之所以说了这么多题外话，就是为了说明一点，对于广大PHPer而言，过多局限于一种框架之上本身就是一种强耦合，未来是不可预期的。所以我打算在继续使 用CakePHP的同时，适当向Zend Framework倾斜，如果Lithium不错的话，也会在我未来学习计划之中占有一席之地。

言归正传，新版的Zend Framework引入了Zend_Application，把Bootstrap进行的规范化的封装，一个典型的Application的Bootstrap文件大致如下：

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initAutoloader()
{
$autoloader = new Zend_Application_Module_Autoloader(array(
'namespace' => 'Application',
'basePath' => APPLICATION_PATH,
));

return $autoloader;
}
}

在Bootstrap中，所有以_init开头的方法被当做资源方法自动运行，如果方法有返回值的话，还会被作为资源保存。资源方法不是唯一配置资源的方 式，为了避免重复编码，框架包含了若干现成的资源插件，可以在配置文件里通过简单设置就可以达到相应的功能，一个典型的配置文件如下所示：

return array(
'bootstrap' => array(
'path' => APPLICATION_PATH . '/Bootstrap.php',
),
'resources' => array(
'modules' => array(),
'frontController' => array(
'controllerDirectory' => APPLICATION_PATH . '/controllers',
'moduledirectory' => APPLICATION_PATH . '/modules',
),
),
);

resources部分的modules和frontController就是资源插件。其中modules资源开启了系统的模块功能。比如说你有一个admin模块的话，那么对应的也可以有一个它自己的Bootstrap类：

class Admin_Bootstrap extends Zend_Application_Module_Bootstrap
{
}

需要说明的一点是Modules的Bootstrap里一般不再需要类似前面的_initAutoloader资源方法，这是因为从父类 Zend_Application_Module_Bootstrap里已经通过继承自动执行了以模块名为命名空间的Autoloader操作。

在使用Modules的Bootstrap时，有一点需要注意的是系统会把所有模块的所有资源方法统统初始化一遍，打个比方来说，如果你有一个Blog模 块，还有一个Forum模块，每个模块使用各自独立的数据库配置，都有一个自己的_initDb方法，那么即便是我们单独访问Blog或者Forum中一 个模块，系统还是会把两个数据库都连接一遍，这无疑是低效的。但也不能就此认为这是Zend Framework的设计错误，问题的根源在于我们划分模块的粒度大小，如上所示，Blog和Forum不应该以Module的形式存在，而应该以 Application的形式存在。如此一来仅需要在Application层次的Bootstrap中执行一次数据库连接即可。

Zend Framework的文档虽然看似详细，但很多细节都没有说明，比如说View助手缺省就会加载，这一点可以在 Zend_Controller_Front中看到对Zend_Controller_Action_Helper_ViewRenderer的调用，所 以最好在使用时自己扎到源代码里查阅。