难得成为世界名人的债主啊

如何成为艾未未的债主
1）邮政汇款（2－3天）：北京朝阳区崔各庄乡草场地村258号 100015 路青收 （国外可选择西联汇款）

2）（首选方式，即时到账）中国建设银行北京市分行前门支行幸福大街储蓄所 6222 8000 1013 1006 244 刘艳萍（国际转账SWIFT代码: PCBCCNBJBJX）

3）支付宝：fakesheji@gmail.com（即时到帐，每天取出15万限制）

4）paypal：fakesheji@gmail.com （因为资金进入频繁目前被paypal冻结）

信息来源：http://loveaiww.blogspot.com/2011/11/ai1001_6999.html

其实，现在的软件开发也是这个现状，所以我们需要更强的代码生成工具

本来，我一直用 grep 进行辅助，后来看到gedit有个插件classbrowser还不错，在python程序下完全没有问题，但是在编辑php程序文件时却怎么都列不出类和函数来

经过2天对 classbrowser 代码的跟踪，最后发现问题所在。

classbrowser对php文件的解析使用的ctags工具，我本机的ctags是 ctags.emacs23的符号链接，在ubuntu的安装包里还有另外一个 ctags-exuberant, 这个包则是原生ctags的扩展版本。安装这个ctags包之后，
gedit的classbrowser插件就可以正确解析 php 文件了。

—————————
PS: 列表虽然出来了，但是效果没有那么理想。没有层级，没有折叠，类/变量/函数只是颜色和图标的不同

–EOF–

小公司好调头首先是受制于团队能力。小公司之小，首先必然是人少，而且不够专业。小公司里，一专多能的人会更受欢迎，如果太专，则在小公司里往往无法做事, 因为你上下游配合的环节都做不到足够专业。也正是这样的用人概念，也就造成了小公司需要频繁掉头的事实: 很多过于专业的事情做不了，只能寻找另外一个适合公司当前人力配置的事情来做。

小公司好调头的另一个原因，人力财力有限，一个方向上遇到障碍，不可能拼尽全力去死磕，只能掉头。绝大多数选择创业的老板都是有一点背景并且看到一些希望，所以往往并不缺乏机会，尤其是一战成名的机会。但这种机会也往往需要投入公司的全部人力物力之后都不够，这对创业公司就形成了一个无形的壁垒:慢慢熬; 或者用尽各种手段整合到足够的资源; 或者等下一次更合适一点的机会。 但只要想抓住一次机会，这次机会就绝对不是为你量身定做的，你就一定要对整个公司的业务、流程、甚至团队进行调整。

就这么简单的2个原因，就导致了小公司会频繁的掉头，尤其典型的就是经常可以听到在小公司工作的人在抱怨: “老板一点准主意都没有，今天做个东，明天做个西的, … 。 ” 其实，他只是不了解老板的无奈，谁不想踏踏实实把一件事情做好阿, 可是太多的时候由不得他阿。

绝大多数的人会认为确定盈利模式，建立公司制度是老板的事情，我的看法是不全是老板的事情。公司老板的首要任务是如何让公司活下来，做到这一点只需要不断找到盈利点就可以了，然后才是如何让公司更规范化的运行和找到所谓的盈利模式。我们都知道，大公司和小公司的一个显著的区别就是制度明确和流程的清晰，但如果我们仔细的想一下: 谁能记得住一个大公司全部的制度文本和流程要求？ 我相信很少有人能, 能做的这些人估计也都是职业的行政和人力人员。那大公司的制度到底是什么？我也想了很多，突然顿悟了: 是习惯。

继续深挖我这个结论，就不难得出: 一个公司做事的习惯，不是老板说了算的，是靠整个团队不断磨合来养成的，最终形成文字的变成了制度, 形不成文字的就是文化。小公司既然面临不得不变来变去的困境，又要养成良好的做事习惯，这真是雪上加霜，要不为什么会有绝大多数的小公司会在几年内死掉呢。

有了这个结论，就不难看明白另外一个现象了: 绝大多数能从小成长起来的公司，都会在快速发展的阶段进行大换血，甚至有些情况下老板都会被换掉，比如老板自己把公司卖掉了, 或者被投资方炒掉了。其实这些现象都有一个共同的结果: 引入空降兵的做事习惯，让公司的制度建立起来。这样做的坏处大家也都看过无数次了：公司不是家；公司已经不是当初我喜欢的那个公司了；公司越来越没有人情味了；当初的和睦快乐的团队消失了。但这些都不是公司的错，错在管理者。

几个简单的问题就可以想明白: 换血的目的是什么？因为要建立更好的做事的习惯。为什么现有的部门/团队没有建立起良好的做事习惯？因为他们没有做，或者没有意识去做。大换血就一定会成吗？不一定，必然还存在部门与部门之间的合作问题。大换血除了流失了老员工之外，还有什么损失呢？ 损失的公司原有的氛围和文化。所以，现有的团队没有跟上公司的进步，被换掉是自然淘汰的结果，但随着换血流失掉的老员工和原有的公司文化，也没有哪个老板是不心疼的。员工的牢骚我们反倒是见的更多一点，见不到老板的牢骚，也无非是2个原因:太多的事情要做，顾不上；我确实有责任，也没什么好牢骚的。

困境，又是困境。该怎么办，我想了很久。

起初，我认识到，我也许是我们团队中最先发现这个问题的，那么唤醒团队其他成员的责任自然在我身上，为我的部门建立良好的做事习惯的责任也自然在我。然后，我迅速又认识到，部门不是孤立存在的，只有一个部门能在公司的成长的过程中存活下来并不是成功，也并不能真正的保住公司的氛围，反而更容易形成所谓的小圈子。我必须让团队的人和我一起为这个目标努力。

首先，我看到了公司的问题所在，别人可能没看到或者没有精力去处理，更有可能很多人会想那不是我的事情，但那些事情又没有达到需要老板去关注的程度，该怎么办？ 我认为，我看到了就应该我解决。但我的时间和精力也是有限的，我需要解放自己的手和脑，要么换自己部门的人，要么给他们做培训，或者兼有。解决了自己的问题，放开了自己的手，才有机会抬起自己的眼，看看部门合作上有什么问题，有没有可以帮助其他部门共同进步的地方。各个部门的事情都能顺利进展了，我们这些管理层的成员才能让老板的意图更快的达成，才有机会帮老板分担更多的压力，老板才会有时间和精力考虑更多的所谓公司的方向和模式的问题。而所谓模式，往往也是源自各个团队能做的最好的事情。

每次部门的技术交流会我都会讲, 公司的进步取决于公司每个团队的进步，团队的进步又取决于团队的每一位成员，我必须不断的教育我的团队成员，让他们能更专业的胜任工作，唯有如此，我才能有时间和精力去为合作团队分担更多的压力，为我的老板考虑更多的事情。自然，老板仍然只需要考虑如何保证公司的生存就好，管理层更多的要考虑如何发展，只有各个部门的响应不断变得规范速度不断变快的时候，老板才有空余的精力考虑更为远大的目标，公司才能迈向下一个台阶。在规范化不断推进的过程中，缺失的环节和岗位会被自然发现，当这个环节变得足够重要的时候，合适的人自然会加入进来。

对于我，一个部门的管理者来说，我的成就不是我写了某某软件某某系统，也不是做了多好的服务多大的销售业绩，我的成就是我是一家创业成功的公司的中的一员，公司的每一次进步都有我的努力，我的部门顺利的配合了老板和其他部门并取得了成功，并成功建立了部门内和部门间的流程。我想这就是创业的态度吧。

–EOF–

然后，右键点任务栏网络连接的图标->编辑链接->无线宽带，然后按照向导执行下来就行了。

—-eof—-

前几天，白鸦的文章 絮叨”产品” 也在讨论这个问题。

在我看来，无所谓这个人到底应该是什么工种什么特长，只需要他尽量专职，必须专注的为一个产品的生命周期负责。这个产品的生命周期应该包括:需求调研，可行性分析，UI/UE的设计，实现方案的确定，运营方向及方案的确定，效果的统计和分析，项目的后续发展(扩大，持续或终止)。

以上这些阶段，看起来很像软件工程里系统分析师要干的活儿。其实本来就是，因为互联网产品没有明确的需求方，只有潜在的用户。而国内CS专业里，软件工程都是针对客户项目进行教学和实践的。而且，互联网产品和客户项目的还有一个本质的区别就在于:客户项目只需要取悦客户，客户满意就一切OK;互联网项目却要为后续的投入负责。

按照上述的产品生命周期划分，公司领导和项目经理的职责应该是:公司领导定好方向，产品经理负责分析可行性和制定运营计划，然后由产品经理推动整个项目或终止这个项目。

但因为要对项目的后续投入负责，而一般的互联网公司里，产品经理往往不可能有这么大权力决定一个项目的生死(另一个真相是，没有几个项目经理懂得如何做市场调研和分析)，从而拍板项目要做的是公司领导，甚至连带着把工期也拍板了。因为产品经理的项目前期的不作为，自然，他也不必为后续的投入负责，更不需要为运营的方向和方案伤脑筋了。结果，一个产品经理就被定位成了UI/UE 设计师 兼 设计技术和前端之间的沟通协调人了。

这一点，白鸦的 絮叨”产品” 一文里就对baidu产品的成功做了一个描述，其中白鸦最欣赏也正是产品经理的全职全责。

———————-
现在说回绿人，既然我认为自己想的挺明白了，那为什么绿人也在这个困境之中呢？
原因其实很简单:人力不足。

一个好的旅游产品线，涉及的内容是相当多的，每一个点都可以深入下去做出花来。但哪一个点会是能让绿人开花的点没有人能打包票，同时作为一个经济体，生存并盈利始终是最应该优先考虑的问题。所以，就成就了现在的状态: 哪一个点能让绿人多活一段时间或者说多盈利一点，哪一个点就应该做一些投入。

如何解开这个困局呢？ 我还在苦苦寻找

节假日可能会因为有外出而例外。

今日: 2010.08.31。

—————————————

真要命，上面这个计划的强度太大，完不成阿，尝试降低到2-3天一篇。

今日: 2010-09-02。

–eof–

简单思考一下就可以知道，重构的目标其实就是把静态的虚拟主机转到这个管理后台的虚拟主机上来，把发布静态页的流程，变成正常的浏览。

考虑清楚这一点之后，就明确了寻找切入点的方法: 搞清楚管理后台的程序流程，重点是用于发布的分类方法，数据管理方法和发布过程的控制。

——— 下午茶时间的分割线 ———-

在本机开发环境下迅速就出现了问题: 登录不进去，看看代码涉及到了2个库，一个是用来存数据的，另一个使用存用户及登录日志等相关信息的。按照重构原则，我第一反应是保持数据库结构不变，理清代码之后再考虑如何重构数据，但是我迅速就发现，这个用户库结构非常简单，就直接把相关表合并到了产品数据的库中。修改数据库连接参数，顺利通过。

——— 洗茶杯的分割线 ———-

登录成功之后，直接就面对了左右2帧的错误页。打开代码，首先看到的是2个define:

define("SERVER_ROOT", "/home/xxx/projects...."); // 我该过了内容
define("HTTP_ROOT", 'http://'.$_SERVER['HTTP_HOST']."");

没二话，改为统一包含项目根下的 config.php, 并把这两个define移过去并合并就是了。

继续顺着把这套系统在本机跑起来的指导思想继续挖掘，很快，又看到了极度让人无语的代码(最前面2行注释不是我写的):

# 某某添加 false &&  原来的这个权限控制真是恶心到家了
# 我想抽死他
if(false && (!function_exists("admin_confirm"))){
}else{
	define("ALLOW_IP",'124.193.148.2');
	$S_uid=$_COOKIE['S_uid'];
	$S_checkcode=$_COOKIE['S_checkcode'];
	$S_power_limit=$_COOKIE['S_power_limit'];
	function admin_confirm(){
	global $DB_Power,$admin_confirm_setup;
        //...  省略若干代码
 
	$HTTP_HOST=$_SERVER['HTTP_HOST'];
	$HTTP_HOST=str_replace('210.192.120.8:8089','xxx.xxxx.com.cn',$HTTP_HOST);
	$baseurl="http://".$HTTP_HOST.$_SERVER['PHP_SELF'];
	$url="http://".$HTTP_HOST.$_SERVER['REQUEST_URI'];
	$sql="select oppower.op_id from oppower,op where user_id='$S_uid' and url='$baseurl' and op.id=oppower.op_id";
 
        //...  省略若干代码
 
	}
 
        // 省略若干代码
	admin_confirm();
}

真无语了。短短的80行代码，犯了很多种错误:

1. 被废弃的函数，应该拿掉，即使当时为了安全注释掉了，也要在后续的修改中去掉，可以大大减轻持续修改的负担。
2. define怎么也不该放到条件分支里面来写，很容易看不到的，而且这种看起来是做IP限定的代码，更要提出来，放到全局的配置文件中。否则一旦代码迁移，服务器搬迁，公司搬家等，后果不堪设想。
3. 函数的定义不因该写到这样的一个if的分支内
4. 中间一段，用str_replace的代码，明显是把一些配置写成了代码，这种问题，一旦遇到切换频道或者任何一种改变，估计程序都不知道上哪找毛病去

解决办法: define提出到全局配置文件，确认去掉那个老版本的的函数，然后去掉if判断，确认str_replace的目的，确定简化逻辑或者直接去掉这段逻辑代码。

与实际情况的差别: 这个文件中只保留的这个函数的定义，相关的调用挪到了包含这个函数的入口页面里，这样入口页面的逻辑就跟着变得清晰了一点。

– 待续 –

–一个古老的php项目的重构

名字起的挺大，其实可能没啥。说可能是因为刚着手做这个事情，完全不知道前路会有什么凶险。

先说马上就要面对的问题:

第一，这个系统可有些年头了，看代码中层层叠叠的补丁上，有不少标注着 2002.01.xx 的，估计这个系统最晚也是在2001年上线的。

第二，这套系统用的很杂。凭心而论，最开始架构这套系统的思想还是相当好的，也非常前卫: 用数据库的二维表来模拟对象的从属层级关系及属性信息。只有一个系列的对象还有，但实际上，数据库里存了大概4-5类的对象: 产品，新闻，景点，动植物分类，机票。

第三，这套代码打过太多的补丁了。每次一个新项目，差不能能用这套系统的，基本都会套用进来，然后是不可避免的塞入一系列的新代码和补丁，以使新旧项目可以和平共处。

第四，这套代码里还有很多很硬的编码，比如直接写了服务器的ip, 而不是统一写到配置文件里。

第五，这一点就是我迟迟不肯动手改这套代码的根本原因: 全部生成的静态页，而后来，为了能简单的替换页面中的广告或者改变页面的结构等， 把静态页切开按片生成，然后再用SSI的方式包含进行，从而形成最终的html文件。

好了，我们的主角该出场了: http://product.lvren.cn, 绿人户外装备频道
重构目标:

阶段1. 废除静态页，完全实现动态页面(伪静态)

后续阶段等完成本阶段后再考虑

为了实现阶段1的目标，我们还需要先做一些准备工作: 环境的搭建

1.下载数据库，并在本地重建。 这个过程涉及到mysql4向mysql5的迁移，导出sql就是了，顺利完成。

2. 下载源代码. 这个过程比较复杂，原因如下:

原因1: 服务器上几个频道的代码之间互相包含，而且很多include和require都是写死的服务器路径，直接放到本地来肯定会跑不通四处报错。

原因2：生成的静态页里，也都写死的网站的域名和链接，如果要在重构环境测试，就必须修改本地的Hosts, 结果就会没法看到运行服务器上的页面，无法进行对比。

原因3： 生成的静态文件目录下，文件超多，总大小为6.xG, 干脆就不往回下载了。

最后的解决方案: 为服务器上的全部源代码建立一个svn仓库，再为准备重构装备频道建立一个空的svn仓库。在本地建立一个新的域名 product.localhost 用来重构装备频道，同时可以把整套代码构造为不再依赖特定域名。