路途志

路途志 的博客有时会包含大量代码，如果能在文章中高亮显示代码文章的可读性肯定会好很多。为了实现代码高亮，之前找了很多插件，但是效果都不是很理想。经过研究终于找到一个完美的解决方案，这个解决方案具有如下优点：

1. 代码简洁，用<pre>标签实现代码高亮，不会生成太多Html标签。
2. 支持多种语言，包括c#,c++,php,python等10多种语言。
3. 扩充方便，可以通过简单二次开发实现对其它语言的支持。
4. 使用方便，把代码复制到代码高亮转换窗口即可。

下面一步步介绍如何配置WLW+wordpress的代码高亮解决方案：

1.准备工作：

下载 precode code snippet manager

下载成功后得到一个名为PreCodePlugin_4.0.2.msi的文件

下载 SyntaxHighlighter2.0

下载成功后得到一个名为syntaxhighlighter_2.0.296.zip文件。

2.安装：

关闭Windows Live Writer,安装PreCodePlugin_4.0.2.msi。安装成功后启动WLW，此时在插件列表里应该出现一项名为PreCode Snippet的插件。

将syntaxhighlighter_2.0.296.zip解压缩至wordpress的活动主题目录，例如：\www\wp\wp-content\themes\lutuzhi\syntaxhighlighter

3.在header.php 中，在<meta http-equiv="Content-Type" content="<?php bloginfo(‘html_type’); ?>; charset=<?php bloginfo(‘charset’); ?>" />下方添加：

<script type="text/javascript" src="scripts/shCore.js"></script>
<script type="text/javascript" src="scripts/shBrushBash.js"></script>
<script type="text/javascript" src="scripts/shBrushCpp.js"></script>
<script type="text/javascript" src="scripts/shBrushCSharp.js"></script>
<script type="text/javascript" src="scripts/shBrushCss.js"></script>
<script type="text/javascript" src="scripts/shBrushDelphi.js"></script>
<script type="text/javascript" src="scripts/shBrushDiff.js"></script>
<script type="text/javascript" src="scripts/shBrushGroovy.js"></script>
<script type="text/javascript" src="scripts/shBrushJava.js"></script>
<script type="text/javascript" src="scripts/shBrushJScript.js"></script>
<script type="text/javascript" src="scripts/shBrushPhp.js"></script>
<script type="text/javascript" src="scripts/shBrushPlain.js"></script>
<script type="text/javascript" src="scripts/shBrushPython.js"></script>
<script type="text/javascript" src="scripts/shBrushRuby.js"></script>
<script type="text/javascript" src="scripts/shBrushScala.js"></script>
<script type="text/javascript" src="scripts/shBrushSql.js"></script>
<script type="text/javascript" src="scripts/shBrushVb.js"></script>
<script type="text/javascript" src="scripts/shBrushXml.js"></script>
<link href="styles/shCore.css" type="text/css" rel="stylesheet" />
<link href="styles/shThemeEmacs.css" type="text/css" rel="stylesheet" />
<script type="text/javascript">SyntaxHighlighter.config.clipboardSwf = 'scripts/clipboard.swf';SyntaxHighlighter.all();</script>

如此配置之后,通过Windows Live Writer插入的代码，在wordpress中可以十分优雅的显示出来。本文的代码高亮效果即时通过这种方式实现。

问题描述

今天博客做了些改动，在本地调试时没注意看版式，上传到服务器后发现在所有页面的顶部出现了一块空白区域，如下图：

注意，上图顶部有大概10px的空白，看起来非常难看。

问题分析

一开始我以为不小心改了css文件，在body顶部加了margin，仔细检查代码和css文件之后排除了这种可能性。通过将更新后的代码和老版本的代码比较后，彻底排除了因为编码引起这种问题的可能，主要因为代码改的很少，用代码比较的方式可以分析出来，如果代码量比较大的话，不建议用这种方式。（注意：代码更改前做备份非常重要，如果能用svn来管理就更完美了)。这个问题至此很难再分析下去了，只能google一把和百度一下，但是依然没有找到任何解决方案（后来知道查询时没选准关键字）。

这个问题至此已经陷入死局，只能前前后后仔细的回忆到底改了哪些东西，在代码的改动之外在操作方面有没有做过改动。后来想起，因为wordpress默认的编码时utf-8的，输入中文经常被转换成乱码，为了避免输入的中文变成乱码，我把所有的PHP文件都特地另存为utf-8了，用的是windows自带的记事本。此时基本确定，网页出现空白的问题又是编码惹的祸。

解决方案

用ultraedit打开header.php文件，再次另存为utf-8格式，不过这时一定要选择 “utf-8 无 BOM”。在ultraedit中，有一个选项可以控制保存utf-8文件时是否写入 BOM，如下图：将图中标记选项清除，可以避免在保存utf-8文件时写入BOM文件头标记。

 

在另存文件时，也要选择合适的格式，如下图： 保存文件时，选择标记的格式

通过ultraedit再次转换后，路途志 顶部出现空白的问题得到圆满解决。在用wordpress搭建博客的时候，编码引起的问题非常多，以后再出现乱码、页面空白或者其它乱七八糟的问题首页要考虑的就是是否编码出了问题。

3月29日写过一篇关于UCHOME邮件配置的详细说明：11步配置UCHOME邮件。路遇交友网就是按照该说明文档配置的，配置成功后邮件功能一切正常，但是最近遇到了些问题。

问题描述：出差交友网是用Gmail作为邮件发送服务器的，平时一直运转正常。今天有网友反映，发送好友邀请邮件后虽然提示发送成功，可是对方始终收不到邮件。

问题分析：检查日志文件，发现在200904_SMTP.php文件有错误信息：(smtp.gmail.com:465) PASSWORD – 535-5.7.1 Username and Password not accepted. Learn more at…。根据提示信息来判断，是用户名或密码错了导致uchome无法连接到邮件服务器，从而导致邮件发送功能失效。可是经过确认，后台的邮件配置完全正确，不存在用户名和密码错误的问题。

问题解决：通过google登录界面，用出差交友网中配置的账号和密码登录gmail，成功登录后再次uchome中做发送邮件的操作。此时邮件发送功能正常运转。

原因分析:问题根源肯定是google对于第三方发送邮件行为做了限制：长期没有登录的账户发送邮件时除了要求提供用户名和密码之外还要验证码，我通过goolge网站登陆邮箱时居然遇到了罕见的验证码，这是很新鲜的体验，自信满满的google很少让用户输入验证码。

如果需要用gmail做邮件发送服务器的话，一定要注意定期检查uchome的邮件发送日志，一旦发现问题及时处理。最稳妥的办法是每天通过gmail网站登陆一次。

Comsenz推出UCHOME，让所有向往SNS的站长像打了鸡血一样一窝蜂的扑了上去。Comsenz想的很周到，不光替站长考虑，替自己考虑的也很周全。为了避免站长们空虚寂寞之余自己脑袋发热胡乱开发各种插件，Comsenz十分体贴提供了一个有趣的平台，它就是漫游。第一次看到漫游的设计思想，我很佩服Comsenz的深谋远虑。

所有的第三方插件都通过漫游平台来提供，最后的唯一的赢家是Comsenz,康盛将拥有互联网上最为庞大的SNS用户群体。数十万个使用uchome的站长们和无数的应用开发人员将把数以亿计的用户乖乖的送到Comsenz的手心。站长们辛辛苦苦做得工作，等于替康盛做了嫁衣。但是，这些都不是最关键的，最要命的是漫游的运营机制有致命的缺陷，这个缺陷会把通过漫游使用了各种小应用的站长们拖向不归路。

SNS站能否取得成功，取决与四个环节。

1.初期推广，获取初次流量。

2.内容改进，吸引用户回头。

3.提高网站可玩性，吸引用户参与。

4.提升网站内在价值，实现盈利。

对于第一个环节，漫游完全帮不上忙，uchome本身在网站宣传推广方面也没有独到之处。

第二个环节正是漫游的用武之地，林林总总的小应用充分满足了用户的各种需要，有些用户甚至专门玩某个应用才会光顾网站。

在第三个环节上,漫游确实起了很大的作用，很多用户很愿意去参与一些趣味性的游戏，比如“开心农场”、“抢车位”等。但是这也恰恰是一个隐患。如果一个SNS站点里的用户活动都是集中在这些通用的小应用上，那么这个网站绝不具备长期生存能力，非常容易被用户抛弃。一个网站的可玩性应该是独一无二的，一个网站的可玩性应该是无法替代的，一个网站的可玩性应该是由自己独立提供的，并且完全独立掌控的。从这个意义上来说，漫游是裹着糖衣的毒药，尝起来甜，吃起来害死人。

在第四个环节上，漫游起到的是完全相反的作用。前篇一律的应用，数十万家网站都具有的功能，对于网站内在价值的提升没有任何帮助。

有的SNS站，同时启用了数十个漫游应用。网站里所有的动态信息都是由小应用产生的，看起来网站很繁荣，很活跃。但是这些信息都是无效的信息；这些用户活动都是无效的用户活动；这些应用都不是网站价值的真实体现。我认为抛弃漫游对于广大站长来说，是早晚必须要做的事。这件事与其晚做，不如早做，最好现在就做。不要沉迷于漫游应用带来的虚假繁荣，不要依赖漫游应用吸引用户的参与，它会害死你的站。

刚才看了一下今天的统计报告,刚发表的Google PR更新啦，兼谈sogou指数就有6个访问量了，而且关键字都是PR更新。看来大家都很关心PR这个话题。Google PR的更新牵动着每一个站长的心。Google PR每季度更新一次，在这三个月的时间里对于大家来说是个煎熬。苦熬三个月后每个人都关心自己网站的PR会不会增加，增则喜不自禁，减则黯然神伤。Google PR就是拴在驴头上的那根胡萝卜，激励着站长朋友们不断地往前跑。如果有一天能够将PR视如粪土，那么网站或许就修成正果了，当然也可能是Google真的把自己的品牌给搞成大粪了。

写这篇文章另一个目的是感叹google的收录速度，几乎是在发表的同时google就收录了Google PR更新啦，兼谈sogou指数这篇文章，并且给了很高的权重。同样是自称搜索引擎的百度、有道、搜狗、雅虎、soso们怎么就那么懒呢，有的对路途志视而不见，有的半个月才来一次。看来以后专门做google的优化的推广就能活了，没必要和其余几个半桶水纠缠了。

顺便说一下，几个流量都是从：blogsearch.google.cn过来的，好像google对于原创文章是非常非常的偏爱。

今天在做UCHOME开发时,遇到一个新问题，在有些情况下在页面顶部会出现下列错误信息：

Warning: array_keys() [function.array-keys]: The first argument should be an array in /www/uch/source/function_common.php on line 1356

Warning: Invalid argument supplied for foreach() in /www/uch/source/function_common.php on line 1356

这个错误提示，在下列情况下会出现：

1.所有用户在非登录状态下访问首页都会遇到这个错误。

这种情况可以通过后台更新缓存解决

2.部分用户在登录状态下，访问首页时会遇到这个问题。

每个用户登录时都会遇到，而且登录之后经过一些操作错误信息会自动消失，经过分析，找到如下规律:

新注册的用户、有消息未查看的老用户会遇到这个问题。没有未查看的通知、消息、留言的用户则不会遇到这个问题。

这是警告信息，不会给网站运行带来太大影响。但在顶部出现这个错误提示，对于用户来说是个很差的体验，可以将common.php中的：

define(‘D_BUG’, ‘1′);

改为

define(‘D_BUG’, ‘1′);

这样就可以避免在用户面前呈现这些代码了。

今天早上发现Google PR更新了，路遇交友网PR从0升到1了，路途志从0到了2。论起流量，路遇交友网远高于路途志。从推广的角度来说，路途志推广力度也远远小于路遇交友。相对于路遇交友网而言路途志唯一的优势其内容都是原创的，并且每日更新。这再次佐证了搜索引擎尤其偏爱原创站这个说法。

和Google的PR比起来，sogou指数显得很无厘头。一贯没什么创意的sogou弄得指数评估，既没有站长的关注和支持，在搜索领域也没有得到认可，它更像是一个学步的孩子在自娱自乐。如果sogou能好好专注于内容搜索，可能对自己的市场份额有更大的帮助。Google PR的推广靠的是google强大的品牌影响力，在广大站长眼里，google PR是衡量网站价值的重要指标之一。相比而言，sogou指数无异于鸡肋。既无站长支持，又没有品牌庇佑的sogou指数何去何从是个疑问。在这无趣的年代，也许每天考量这个问题能带来一点乐趣。

摘要：

这是Nginx的基础模块，它提供了最基本的http处理功能。

指令：

指令：daemon

语法: daemon on | off

默认值: on

例：daemon off;

在正式环境下不要使用daemon和master_process指令，这些选项只能用于开发环境。不过你可以放心的在正式环境下将daemon off和runit/daemontools一起使用，不过这种用法会在以后的升级中给给你带来麻烦，你将无法

平滑的升级到新版本。master_process off则绝对不能使用在正式环境中。

指令：env

语法: env VAR|VAR=VALUE

默认值: TZ

上下文: main

这个指令用来定义环境变量集合，如下场合需要创建新的变量或者更改变量值：

1. 在实时环境下升级Nginx的时候
2. 启用内置Perl 模块的时候

如果没有明确的定义TZ的值,默认情况下它集成老版本的值，默认情况下，内置的Perl模块总是可以使用TZ的值。

例：

env  MALLOC_OPTIONS;
env  PERL5LIB=/data/site/modules;
env  OPENSSL_ALLOW_PROXY_CERTS=1;

指令：debug_points

语法: debug_points [stop | abort]

默认值: none

例：

debug_points stop;

在Nginx内部有很多断言，如果debug_points的值设为stop时，那么触发断言时将停止Nginx并附加调试器。如果debug_point的值设为abort,那么触发断言时将创建内核文件。

指令：error_log

语法: error_log file [ debug | info | notice | warn | error | crit ]

默认值: ${prefix}/logs/error.log

指定服务器错误日志存储的位置。

日志中默认的错误级别：

main部分：error

HTTP部分：crit

server部分：crit

Nginx支持将不同虚拟主机的日志存储在不同位置，这是个很有特色的功能。在lighttpd中，他们一直拒绝提供类似的功能。下面两个链接，提供了针对不同虚拟主机提供不同日志的例子：

SeparateErrorLoggingPerVirtualHost

mailing list thread on separating error logging per virtual host.

如果你在编译Nginx的时候，使用了—with-debug指令，你还可以使用：

error_log LOGFILE [debug_core | debug_alloc | debug_mutex | debug_event | debug_http | debug_imap];

注意：error_log off 无法禁用日志，这个写法将会创建一个名为off的日志文件。如果要禁用日志，请用下面的写法：

error_log /dev/null crit;

指令：log_not_found

语法: log_not_found on | off

默认值: on

上下文: location

启用或者禁用404错误日志，这个指令可以用来禁止Nginx记录找不到robots.txt和favicon.ico这类文件的错误信息。

例如：

location = /robots.txt {

  log_not_found  off;

}

指令：include

语法: include file | *

默认: none

用这个指令，你可以包含任何你想要包含的配置文件。从0.4.4开始，include 指令开始支持文件名匹配，

例如：

include vhosts/*.conf;

注意：直到0.6.7版本为止，include 文件的路径是相对于configure时由–prefix=<PATH>指令指定的的路径而言，默认情况下是/usr/local/nginx.如果在编译compiledNginx时你没有指定这个值，请使用绝对路径。

从0.6.7开始，include文件的路径实现归于Nginx配置文件nginx.conf的所在目录而言，不再是nginx编译时指定的路径。这个改进大大增加了include的灵活性。

指令：lock_file

语法: lock_file file

默认值: compile-time option

例如：

lock_file  /var/log/lock_file; 

如果Nginx是由gcc、Intel C++或者SunPro C++ 在 i386、amd64平台上编译的,Nginx将采用异步互斥进行访问控制。

路途志从开博到今天，已经走过了月余。在这一个多月的时间，参考前辈们的经验，对博客进行了大量的定制。其中比较重要的一个工作就是页面静态化—永久链接静态化。在做这个工作的时候，遇到了很大的问题，路途志的服务器是centos5.2+nginx，而公开的资料无一例外都是基于apache的。参考了Nginx wiki和apache的案例，经过多次试验终于在Nginx下实现了Wordpress永久链接静态化，Nginx配置文件的server部分加入下列四行：

 

#下面四行斜体字实现链接rewrite,http://www.lutuzhi.com中的所有页面实现了静态化 

rewrite ^/(index|atom|rsd)\.xml$ http://www.lutuzhi.com last;

rewrite ^([_0-9a-zA-Z-]+)?(/wp-.*) $2 last;

rewrite ^([_0-9a-zA-Z-]+)?(/.*\.php)$ $2 last;

  rewrite ^ /index.php last;

完整的server配置如下：

server
{
  listen       80;
  server_name www.lutuzhi.com lutuzhi.com *.lutuzhi.com;
  index index.html index.htm index.php;
  root  /yuluyu/wp;

  #limit_conn   crawler  20;   

  if (!-e $request_filename) {

#下面四行斜体字实现链接rewrite,http://www.lutuzhi.com中的所有页面实现了静态化 

rewrite ^/(index|atom|rsd)\.xml$ http://www.lutuzhi.com last;

rewrite ^([_0-9a-zA-Z-]+)?(/wp-.*) $2 last;

rewrite ^([_0-9a-zA-Z-]+)?(/.*\.php)$ $2 last;

rewrite ^ /index.php last;

  }
  location ~ .*\.(php|php5)?$
  {     
    #fastcgi_pass  unix:/tmp/php-cgi.sock;
    fastcgi_pass  127.0.0.1:9000;
    fastcgi_index index.php;
    include fcgi.conf;
  }
  location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
  {
    expires      30d;
  }

  location ~ .*\.(js|css)?$
  {
    expires      1h;
  }   

  log_format  lutuzhi  ‘$remote_addr – $remote_user [$time_local] "$request" ‘
            ‘$status $body_bytes_sent "$http_referer" ‘
            ‘"$http_user_agent" $http_x_forwarded_for’;
  access_log  /yuluyu/logs/lutuzhi.log  lutuzhi;
    }

 

Nginx配置文件更改后，用下列命令更新立即生效：

检查配置文件是否正确：/yuluyu/nginx/sbin/nginx –t
使新配置文件立即生效：kill -HUP `cat /yuluyu/nginx/nginx.pid`

Gateway 在美国是个赫赫有名的公司，但是它的品牌影响力在中国是那么的微不足道。以至于很多人看到我的笔记本，第一反应是：你用的是长城电脑啊，他们把Gateway想当然的认为是Greatwall了。另一部分人看清了Gateway的logo,不过他们对Gateway的也没有更多的认识，当他们看清Gateway的牌子之后，往往会小心的问：是深圳产的吧，山寨本！在使用这个笔记本之前，我也从没听过这个牌子，尽管早在1993年Gateway已经贵为财富500强的一员。

Gateway在中国

Gateway早在1997年和2002年曾试图进去中国市场，因为市场策略不当，两次都铩羽而归。2007年8月再次高调宣布进入中国市场，此次Gateway没有选择单打独斗，而是携手神州数码共同在中国市场冲杀。目前Gateway在中国市场面向个人推出了笔记本、台式机和显示器三大类消费类电子产品。

其笔记本和台式机因为漂亮大方的外观深受中国区用户的欢迎，目前Gateway在中国去推出了下列笔记本：

LT系列-LT series

C 系列-C series

MX 系列-MX series

UC 系列-UC series

TC 系列-TC series

T 系列-T series

P 系列-P series

但是Gateway在中国去只推出了一款台式机：GT系列-GT series。

目前在中国市场Gateway主打产品还是笔记本，短短一年多的时间里Gateway已经积累的大量的忠实用户，它的粉丝称其为“奶牛”(因为其商标酷似奶牛花斑)。

虽然Gateway在中国市场的销售取得了不俗的业绩，但是关于其售后服务的负面消息时现报端。根据我的个人体验，Gateway的售后服务可以用“令人发指”来形容。我最近一次维修笔记本的经历，是一场噩梦，以至于现在电脑出现了更严重的问题我也不愿意去维修。

3月初的时候，我的笔记本显卡坏了，显示器不亮，开机报错一长两短。当时我人尚在乌鲁木齐，打400-811-7118咨询，被告知乌鲁木齐有特约维修点，到了现场一看是神州数码维修站，该维修站同时负责索尼、Gateway等品牌电脑的维修。对方表示需要留机测试，大概要7天，因为着急赶回上海，就没在当地修理。

回到上海之后，联系上海当地维修站，被告知需要携带维修卡和发票至维修站才可以维修。这是一个很特殊的经历，所谓的维修卡就是一张空白卡片，第一次遇到要求必需提供一张空白卡片才提供服务的厂商。当然，不是原厂商，是神州数码。当然，维修卡找不到了。我不会把一张空白卡片保存1一年之久的，所以对方有了充足的理由不提供维修服务。后来是购买了所谓的续保服务，对方才提供所谓维修服务。

维修站承诺3~7天内可以修好，接下来就是漫长的等待，在此期间打了多次电话询问维修进展，而对方从没主动打电话通知维修进展。在第六天，对方说修好了，给换了块主板。现场测试，一切正常，电脑可以正常启动，能够正常进入系统，可是噩梦就从这时候开始了。电脑拿回后，使用两个小时候就热的发烫，底部和上部面板均很烫。电源使用时间从维修前的2个小时降到1个小时。检查发现，电脑主板型号是T6830c，而我电脑的型号是T6823c。原来他们所谓的维修就是给电脑换了块老主板。打电话和维修站沟通，对方要求我再把电脑送过去检测。至此我彻底失望，在上海从一个地方到另一个地方是何等麻烦，何况电脑送过去之后还不知道会修成什么样。我真怕他们最后把电脑给修成算盘了。维修过程既没完全解决问题，也没让我省事，没体会到任何服务的存在。

Gateway这个牌子在中国，将会第三次失败，我期待着那一天的到来，不拿消费者当回事的公司，肯定会被市场淘汰，如果它能活下去，那肯定是市场搞错了。Gateway的即将到来的第三次失败，败在他选择了一个错误的合作伙伴-神州数码。

小知识：

2007年8月宏碁收购Gateway在亚太地区的业务

Gateway在中国地区的市场宣传和售后服务由神州数码承包

Gateway驱动下载