没瞧出来，您还是个青皮

 

薛海滨

 

 

用户篇

第1条、对你本人没用的，对用户也一样。

第2条、没有用户愿意接受“教育”或“引导”。

第3条、用户永远选择最懒的方式。

第4条、用户虽然懒，但并不笨，甚至远比你高明。网站只是舞台，用户才是主角。

 

内容篇

第5条、每个页面上的字符数量不要超过3000个，用户有生理带宽的极限！

第6条、只有放错位置的广告，没有写错内容的广告。广告放在合适的位置，是对内容有益的补充。

第7条、“怎么告诉用户”永远比“告诉用户什么”更重要。

第8条、不要轻易娱乐化。娱乐可提高流量，但没有广告客户买单——谁会喜欢在“不正经”的网站上做广告呢

！

第9条、“正经”和“严肃”比访问量更值钱。对电子商务网站而言，交易的质量和信用则比交易的数量和广度

更值钱。

第10条、新闻就是旧闻，新闻就是档案。

 

市场篇

第11条、群发邮件非常有效。但每发100万封，就会招来一个黑客。

第12条、论坛灌水也非常有效，也会招来更多黑客。

第13条、“3秒钟定律”同样适用于网站——用户在3秒钟内决定是否继续留在你的网站，然后在17秒内决定是否

收藏你的网址。

第14条、传统广告基本不会带来太多访问量，但会提升你的资信度——你能购买效果这么差的广告，说明你烧得

起钱，你有实力！

第15条、网络广告也不会比传统广告更有效，而且还面临各种作弊的挑战。当然，如果你想卖产品，则另当别论

，以后按广告效果付费的网络广告会大行其道。

第16条、如果地球上能存在100万个电子商务类网站，那么，最多只能存在10万个新闻信息类网站——“上层建

筑”的数量永远不可能超过“经济基础”的数量。

 

技术篇

第17条、技术不是万能的，没有技术也是万万不能的。

第18条、不要作弊。今天作弊的成本等于明天解决“作弊后遗症”的成本。

第19条、所有网站都能被黑客攻破，不要相信例外。

第20条、已上线的链接，永远不要废弃，用户可能已将它放进了收藏夹。

第21条、“可以扩大市场的技术”远比“可以做出完美产品的技术”有价值。

第22条、不要轻信任何规则（包括上述21条）。
 

觉得讲北京话的人越来越少了，没劲。搞的我老觉得自个跟到了外地似的。

 

 

转个小文吧

我们一家子都是标准的老北京，我从小就是吃着爷爷奶奶做的肉丁炸酱面、羊油麻豆腐长大的。上大学那会儿，同宿舍的几个外地哥们儿都特爱上我家蹭饭，一来是我家的饭菜可口，二来边吃饭边听我爷爷奶奶用纯正的京片子扳杠，实乃人生一大乐趣。

　　有一次，我爷爷催促一个福建同学趁热吃面，说道：“别渗着了，快撮吧，这面筋道儿，呆会儿糟叽了就没嚼头了，把面码儿多往碗里改搂点儿。”我那同学听完连筷子都没敢动，因为没闹明白我爷爷说什么呢。还有一次，我奶奶在屋里呵斥我爷爷，让哥儿几个听见了：“裹什么乱啊，没事别这儿逗咳嗽，老了老了成个碎嘴子了，一天到晚瞎白活，别找我犯牛脖子啊。”大家扭过脸异口同声地问我：“你奶奶说的这是哪国话？”

　　在北京学习、生活了几年后，大概是受我的耳濡目染，我这几个外地哥们儿的北京话都有了长足进步。问他们多大了，已经有人可以用“三张儿”来准确形容自己的年龄了；遇到什么意见不合的情况时，也会有人冲着我大声嚷嚷一句：“姥姥！”不过，仍然有不少人单纯地以为，加了“儿话音”的方言就是标准的北京话，这观点不能说全错，但肯定也不完全正确。“儿话音”用在果汁儿、小汽车儿、小树林儿这些词语上，肯定是没问题的，但如果用在公共汽车、防护林、天安门、西直门上，那就不太对路了，因为北京人对一些相对比较大的概念、比较宏伟的景物很少使用“儿话音”。我有一个东北同学，每句话里必带“儿话音”，比如他那天跟我们说他刚刚从“地安门儿”搬到了“东直门儿”，再比如说他准备这个周末去“香山儿”锻炼锻炼身体。最有意思的一次是，和他一起在饭馆吃饭，看见窗外开过来一辆崭新的“奔驰600”，这位同学不禁羡慕起来：“真气派！什么时候我也能开辆‘大奔儿’啊？”我一听，口中的啤酒险些从鼻子里蹿出来……

　　如今的北京城正以海纳百川的姿态迈向国际大都市的行列，北京方言也就不可避免地会受到外来方言的强烈冲击，而这种南腔北调的新式北京话也许才更能显示这座城市的包容与大气，就像当年那句风靡一时的“白白了您呐”，不正是北京话和英语的完美融合吗？还有如今广为流传的“飒蜜”一词，其实说白了，不就是 “英姿飒爽的Miss”吗？

　　上个月，住在爷爷奶奶家对门的一对湖南夫妇新婚，婚礼第二天特意送来一包喜糖。我奶奶耳背，没听见有人进屋，我爷爷一边请人家落座，一边喊我奶奶： “老太太，老太太！来客人了！”新娘子疑惑地问我：“这是叫谁呢？”我跟她解释，我们北京的老人喜欢老头子、老太太地互相叫，表示亲切。到了下个周末，我去看爷爷奶奶，在楼门口碰见这对夫妇正往电梯间里走，男人柔声细气地叫着女人“老太太”，女人则娇羞无限地往男人肩膀上一靠，嗲嗲地回应一句“老头子”，酸得我在后面腿肚子一发颤，差点滚下楼梯去
 
 

道可道，非常道—PHP模板技术

道可道，非常道。

当我第一次见到php模板的时候，简直被迷上了。原来php世界里还有这么好的东西。我疯狂地学习。
好在当时的php模板还不是很庞大，很快我了解了它的原理，并也能自己写一些了。
后来，smarty横空出世，更是拥有了许多为它着迷的fans.许多人开始写模板引擎，将smarty或其他模板

加以改造，使之符合自己的需要。
纵观当今模板世界，php模板引擎主要分为两种：
一种是替换特定字串型的。美工做出来的页面，中间会嵌入一些什么{block.title}这样的字符串，然后

程序读入这个模板文件，将中间的{block.title}的字样替换成实际从数据库中读取的内容。
还有一种符杂一些，是一种编译型的。以smarty为代表，模板文件中实际上包含了一些简化的php代码，

比如有的写的是<{=$site_name}>,<{if $counts>0 }>这样的语句，实际是一种自行定义的语言格式。

web开发久的人一眼能看出它们指的是什么。这一类往往会在第一次访问时被预编译，转换成一个php文

件何存起来。比如 <{=$site_name}>就变成了,<{if $count>0 }> 就变成了0) {?>。从第二次起，就直

接包含已经编译出来的php文件。当然，各种模板的处理的具体细节不一样。

但是，我们为什么要用模板？
这个问题我也不能很好的回答。但是有很多人这么说：要让美工和程序员的工作分开。要让代码层和表

现层分开。
那么我们看这两种方式实现了吗?
让您的美工人员打开一个smarty文件，让他按他的思路去改一下视图设计。他会告诉您，天哪，你怎么

把我的设计变成这样一幅样子了？这些foreach,if都是什么意思？噢，天哪，我的表格怎么撑得这么大

了？….
原来编译型的模板技术让美工更没法子做美工了。
那么替换字符串型的呢?看起来是轻松多了。不过您可以测测您的程序速度，看看他是否已经慢了一倍以

上。很容易，您用了太多的有preg_match,或是str_ireplace之类的语句来替换。程序重复一次又一次在

您那几万个甚至更多字节的模板文件中查找某个字串，来替换内容。
不仅如此，你还发现您哪天想在视层面插一点东西时，处处受制于模板。您肯定很想直接在模板中写一

段之类的语句，但是，很抱歉，您不能这么写。如果只是想echo 一个什么东西，您可以在模板中加一个

{{var}}的串，然后在php程序中写
$var=”这一个串”;
$template->assign(”var”,$var);
但是如果您不是想输出呢，想做其他操作？抱歉，您还是得改php代码。这些模板都支持规矩矩的表格状

的输出，但是，如果我想输出20条记录，我要弄一个第一行2列记录的，第二行3列的，第三行又是2行的

之类的，或者是其他类似找码，您打算怎么办?
难道再让您的模板引擎也升级成为编译性的，好让您往您的模板中加入php语句?

您错了。其实，我们看一看，我们的模板引擎充当了什么样的角色呢?我们把一段特定的按一定规则编写

的html代码进行一定的数据处理后输出成了另外一段，输出过程中某些字符发生了改变。那我们的伟大

的php干了什么呢?它帮我们把我们按规则写好的php代码也按一定规则输出成了一段html。两者本质是一

样的。只是，php本身比我们那些蹩脚的模板引擎更快，更漂亮。
再说细一点，现在用的最多的Smarty.看一看它的结构:

<{if $article.rates}>
<span class="title"><{php}>echo art_constant("MD_RATE");<{/php}>:</span>
<span class="item"><{$article.rating}>/<{$article.rates}></span>
<{/if}>
你觉得它是一个美工能看清的html文件么?
看看编译后的结果,它看起来应该是这样的:

<?php
if($articles.rates){
?>
<span class="title"><?php echo art_constant("MD_RATE");?>:</span>
<span class="item"><?php echo $article.rating;?>/<?php echo article.rates;?></span>
<?php
}?>
哈。我们伟大的smarty把这html也变成了php了。然后在以后的工作中，这些php代码会直接被运行。
有必要吗?本来是apache承载php,php直接编译php 源代码，现在变成了apache承载php,php编译smarty引

擎，smarty引擎又去编译html文件。反而多了一层，smarty自个儿把本来php要做的工作拿了做了。
而且糟糕的是，smarty的模板打开来以后，比php文件更让人难以看清。
所以我说，放弃您的模板系统吧。但记住我们开发模板系统的初衷。

您会说：那要是放弃模板系统了，我怎么分开程序逻辑和视图层面？
这个也太好办了。您可以这样写：
第一个文件这样写:

<?php
/**
file :logic.php
@author renlu xu<helloasp@hotmail.com>
@link http://www.162cm.com
*/
$rs=mysql_query("select id,title,body from articles order by id desc limit 30");
while($row=$mysql_fetch_assoc($rs))
{
    $rows[]=$row;
}
?>
第二个文件作为您的视层面的文件。您可以让您的平面设计师在mac上设计漂亮绝顶的图片，然后切成

html文件，交给您的页面整合工程师。这个工程不需要懂太多php，他基本上只需要会用print就行了。

他把这个html文件改名为view.php,然后在里面加上相应代码:

<?php
/**
file:view.php
@author renlu xu<helloasp@hotmail.com>
@link http://www.162cm.com
*/
foreach($rows as $row)
{
    echo "<tr>";
    echo "<td>";
    echo $row["id"];
    echo "</td>";
    echo "<td>";
    echo $row["title"];
    echo "</td>";
    echo "</tr>";
}
?>
ok.这就视层面文件。这个文件用织梦者(dreamweaver）打开后，应该跟美工做出来的图是一样的,就仅

仅多了用那个黄色的问号代表的php代码。写得好时，dreamweaver还能列出您的php代码中输出了什么内

容，效果更佳。
这两个文件，就是一个是逻辑层，一个是视层面。
然后用index.php将他们包含起来。

<?php
/**
file:index.php
@author renlu xu<helloasp@hotmail.com>
@link http://www.162cm.com
*/
include "databaseConnect.php";//连接数据库的代码，我就不写了
include "logic.php";
include "view.php";
include "cache.php";
?>
这样逻辑和视，就分开了。那有人会说，如果我用模板，可以将要输出的内容写入到静态文件中，现在

没了模板我该怎么办？
这个不是问题。我们用的是php,超酷的php.
看看，我们加了cache.php.这就是用来实现您说的缓存效果的。
我们的cache文件:

<?php
/**
file:cache.php
@author renlu xu<helloasp@hotmail.com>
@link http://www.162cm.com
*/
$content=ob_get_contents();
$fp=fopen("index.html","w");
fwrite($fp,$content);
fclose($fp);
?>
当然，index.php也改成:

<?php
/**
file:index.php
@author renlu xu<helloasp@hotmail.com>
@link http://www.162cm.com
*/
if(file_exists("index.html"))
{
    include "index.html";
    exit();
}
include "databaseConnect.php";//连接数据库的代码，我就不写了
include "logic.php";
include "view.php";
incldue "cache.php";
 
?>
这样您看这缓存效果是不是就出来了？

有人说：我用模板还有一个好处啊,就是模板写错了还不会影响到程序的运行。是的。咳，怎么说呢？您

在模板中将<{=$site_name}>写成了<{=$sie_name}>是没啥，您的php程序还是很”健壮”地运行着。不

过您没觉得，当您期望的那一个将由<{=$site_name}>来打出来的网站名称没有出现的时候，您排起错来

会很难找吗?对于一个程序师来说，您不觉得，光只视层面的那些echo语句，只应该是您工作中极微不足

道的一部分吗？在这个主要是echo语句构成的视层面文件view.php，您还出现编译期错误，是不是该拉

出去打屁屁？

另外，在php程序正式上线运行时，您也可以将它的报错功能关闭啊。

常道，亦非常之道。
无为，无所不为。  

    怎么说，做web项目也有比较长一段时间了，很多人会觉得web项目的技术难度不是很大，我觉得吧：

    一个是目前的程序员是从事web项目的（包扩.net,php,j2ee)人比较多，而从事其他方面的人员相对要少一些，所以搁行如搁山，大多程序员有个很优秀的品质，对于不了解的东西回比较谨慎，所以会认为其它方面的技术比较难（实 际上当你去了解其他的方面就会看到技术都是可以很快的运用和掌握的，担任到精通的地步就需要化费很多的时间和个人的努力了）；
   
    另一个比较重要的原因在于web项目的入门门槛确实不高，但实际要想真正做到一个好的web项目的程序员或是能够真正达到一个更高层次的架构师的水准，其所要掌握的技术列表还是相当长的，需要学习很多的技术方面和积累很多的实际经验，所以你如果仅仅挺留在入门阶段你会觉得比较简单，实际上你学要做的功课还有很多；还有一个方面就是在web项目中还有一个比较复杂的地方在于对实际业务的转化，说白了就是用户的需求分析，这一点是很麻烦的（不像一些通用项目是一开发人员的想法为中心）。

    上面2段基本是抄的，我想表达的意思是，现阶段，起码在中关村，真正的web程序员的职位基本是很少的，一个web程序员往往身兼数职：策划、需求分析、页面制作、测试和评估、服务器搭建和维护、DBA，什么都得能来一点，但什么都不精。

   

    这就是显示情况了，也每什么办法～～

昨天，要不就是前天，最早是大前天，末末问我，现在怎么不喜欢上山了。

 

我琢磨了着啊，上山这个事吧，我现在已经不是喜欢不喜欢的事了。就像骑自行车，如果从家出来去什么地方，坐车太挤，大车有不值当，哪就骑自行车了，跟喜不喜欢骑车没关系。

上山也是一样，谈不上喜欢不喜欢，如果周末没事情，而且觉得自己该出去了，哪就抗上包就去了，可能到了苹果园还没想好要去那里呢。

 

另：下礼拜打算去斋堂水库露营：）

 

曾经有一只771放在我面前，我没有珍惜，直到现在涨价了，才后悔末及。

如果ice－poss再有什么苗子台子想出手，我一定会说：还能再刀一下吗？

没了

第一张，我最近的EDC

第二张，新收的balisong：

上到下：bm42 440C，这把不是新收的

中：bm32

下：bm42 154cm版

 

新的balisong很快就要到手了

 

php高手之路之—返樸归真

 

武侠小说里常写,无招胜有招.大师们最终都要精通十八门武艺,然后最后学通一门,再融会贯通,突破前人,练就一招独门绝技.
我曾经折腾着要自己整文本数据库系统,自己整模板系统,自己整MVC框架.自己封装一堆操作,乐此不疲.
有一天我仔细地研究了Smarty模板的机制,突然良心发现,把我自己折腾的模板系统扔了.因为我发现,模板引擎的引入,初衷是简化表现层的操作,但最终Smarty的语法,已经越来越像一个php,越来越像一个新的WEB脚本了.本来是两层,php引擎解释PHP文件,现在多了一层,php引擎解释smarty引擎,smarty引擎又解释smarty模板.现在smarty的语法还在不断增加,扩展,他们正在努力在php语言的圣殿下,用smarty造一个小房子.
于是我在做某个网站的两会专题时,文件架构是这样的:
/view.php
/model.php
/index.php
/config.php
view.php文件的第一行就声明了:global
$data;$data是一个多维数组,它的内容已经由index.php来产生.view.php中除开这一句之外,就只包含echo语句和foreach语句了.它们就负责一行行地输出data数组的内容。
index.php则是入口文件,它包含了config.php,model.php
,view.php.虽然不长,我还是给它实现了一个缓存功能.就是如果writable/cache.php文件存在且创建时间在10分钟以内,就直接包含cache.php并退出,否则调用wget将最新的网站显示内容读一份存到writable/cache.php中存起来.index.php是主要的执行文件.
config.php 则是几行配置信息,比如数据库信息啦之类.
model.php则是定义的函数的声明。其实这里也就三个函数.
现在我的工作完成了,余下的工作,就是告诉美工,要改的话,只需要修改view.php文件就行了.这个文件,随便改一下也没啥问题.
所谓的MVC,其实归根结底,就是可以做到如此简单.
所以,为什么要用smarty呢.如果要将logic和view分开,很简单,把文件一分为二,其中一个只管显示就行了。如果非要用if else 或是foreach,在smarty中也是要用的,我干吗要再去学smarty的关于if else 和foreach的语法呢,我直接在view.php中使用php标签就行了.
学透了以后,太多东西其实都可以这样来解决.cookie被认为是不安全的,所以往往一些系统设计了非常复杂的SESSION机制,还写大段大段的代码自行设计了加密算法.首先,加密算法有现成的可用的,没必要自己搞定.再者,看看wordpress,人家也直接在cookie存了用户名和密码.但普通人如果要在cookie中存,往往就存用户名和md5后的密码.但wordpress不这么干,人家把密码md5加密了一次,再用md5加密了一次.你不是说用户可能设置少于6位的密码吗?你不是说少于6位的密码几分钟就可以暴力破解吗?我现在两次md5加密.不就成千上万倍地增加了破解难度了吗?多简单的做法!
类.我不得不说一下这个.不知道为什么,人们在学会php5下的类操作后,就觉得不管什么,哪怕是写一个文件什么的,一定要封装一下.需知,OOP不是仙药,(原话应该人月神话中的:没有银弹.),OOP仍然不能解决一切,甚至不见得比Function式的编辑解决得更好.如果您决定了要写一堆Class,那么事先告诉我,您保证您写成Class的初衷不是为了好看,不是为了让老板知道您会用class了.
还有一些仁兄们,喜欢把程序弄得非常好看,优雅.当然如果可能,好看一点的代码谁都喜欢.但是有很多时候,好看是以数倍的性能牺牲为代价的.我在一个短短的php文件中,看到有十个以上的地方使用了eval($variable)类似的语句.(之前看到霍炬的文章我不信,后来见到这份文件我信了).我能想出来的本来可以直接运行的代码非要放进eval中去执行的理由只有:可能这样好看一些.兄弟,如果您对好看与非很在乎的话,我建议您真的应该与您的美工换一换,这样也许能做出来一个很好看的网站!
有些东西,真不是越复杂越好.把php弄精,两点:多看手册,多问baidu/Google(为了避免卷入google还是baidu之争,我特意两个都写上,并在注意了排序).有时间骂Zend framework太庞杂,Xoops太老套,不如坐下来看看php手册.

 

主要学习一下几点：
1.在如此环境下不惜伤亡，坚持完成穿越！
2.在若干体力好装备全经验丰富的队员掩护下及时下撤，保全了自己的性命！
3.将体力差的队员抛下，以免影响自身行动，保全了自己的性命！
4.隐瞒落叶谷下撤信息及线路，以防落后队员下撤后与自己抢宿营地，保全了自己的性命！

综上所述，此次事件中英明的领队不顾他人安危，成功的保全了自己的性命。子曾经曰过，死个把新人不算什么，死一个如上经验丰富的领队才是对户外界最大的损失。

事件：新京报的报道：

 

　　很多队员装备不全

　　根据警方掌握的情况，这支队伍没有带急救药品，也没有配备医生。

　　发起人“海”曾特别提出要求队员备齐装备，并特别强调如果不戴头灯或手电将不准上车。

　　而意外发生后，另一名发起人“玛瑞亚”承认，很多队员装备不全，但知道情况时队伍已经出发，“装备上的问题导致山中行进很不顺利。”

　　■伤者回忆

“风太大只能改变路线”

受伤队员称“夏子”先说胡话后停止呼吸

　　受伤的小段（网名为“装甲老鼠”），和“夏子”在同一组，由于虚脱和视力受损，他被送到了斋堂医院。

　　按照原定计划，小段他们在前日上午10点左右出发，下午5点就能下山，小段说，他们并没料到山上的雪会那么厚，11人的队伍也由于行进速度不一样，分成了两队。他们这一组，队伍行进速度很慢。到下午5点时，6人依然滞留在山顶上。

　　小段回忆，危险在下午4点多的时候就开始出现，由于没戴雪镜，他的视力因雪光反射，已经开始模糊，再加上体力不支，他走在了队伍的最后边。

　　“我在一定程度上拉了队伍的后腿，我是第一个出现异常的。”小段说，祸不单行，他又突然掉进了一个雪坑，雪埋到了他的胸口，1米80的他拼命往上挣扎，在队友的帮助下终于爬了出来，但这又花费了好长时间。

　　“如果沿着山脊走，我们是能找到下山的路。”小段说，但是那时风太大了，估计山脊上瞬间风力能达到9到10级，导致队伍根本不可能继续沿着山脊走，只能再次改变路线，但他们依然没有找到下山的路。

　　夜幕降临后，风太大不能生火，导致队员们无法取暖，并且“夏子”开始出现异常。

　　“那个女孩开始哭，后来就说胡话，”小段说“夏子”是在他们翻过两座不知道名字的山后出现异常，并且无力走路。当时，几名队员沿着大约45度的斜坡拼命把“夏子”拖到一个没有积雪的地方，让其躺下。

　　当晚10点多时，队员们正通过电台进行呼救，突然发现“夏子”不再说胡话，并停止呼吸。队员马上对“夏子”做人工呼吸，以及猛搓手心脚心，希望能把“夏子”救过来，可是忙了半天依然不见她好转。到了晚上11点多，“夏子”一头栽到了雪地里，呕吐并流鼻血，大家喊她，也没有反应了。

　　到3月11日“凌晨”两点多时，队员再翻看其瞳孔，发现已经放大，大家觉得那女孩没有希望生还了。

　　早晨8点，找到他们的医务人员确认“夏子”已经死亡。

 

 

 

 绿野org上的讨论：