在全球金融危机的大背景下，应该提出全新观点。IT不再需要“更多”，而是花钱少，做的也少——停止做那些价值低而消耗多的工作。让你的企业选出重点，而不是把所有的事都推给你;明智地让用户凭自己的技能处理他们自己能处理的那部分事情，让你能腾出手来做真正重要的工作。这样，在为自己减负的同时也帮助企业降低了成本。当遇到不可能完成的需求、不现实的交货期限要求时，要学会大声说“不”。从长远来看，这对所有人都有实实在在的好处。

这个世界充满“垃圾食品”和为此苦恼的家庭，我们看到快餐国度的数量在不断增加，它们正在为快餐带来的便利付出高昂的代价。由此诞生了致力于倡导健康的“慢食“运动。与之相呼应的“慢IT”正在寻求它在技术管理方面的运用。

国际金融危机为我们实现“慢IT”提供了绝佳机会!全球的企业高管们正在拿经济下滑为借口进行裁员、减产、关门、延期、谈判……你也可以这么干!毕竟你是为了公司的利益着想。如果有人说受到伤害，那只是暂时的。毕竟这是非常时期!

在逆境中寻求机遇，“慢IT”的十个原则：

1 别再试图成为超级英雄

不现实的最后期限要求、过大的工作量只会带来资源耗尽和质量低下。你被要求处理一堆不可能完成的任务?把它们丢回原来的地方吧。你要明确每个项目在时间和费用方面的要求，让企业去决定这些任务的优先级。新项目上马意味着其他老项目的优先级被降低。做这个决定不是你的工作职责——实际上，让企业自己承担这个职责反而能减少这种无用要求。但前提是你要与企业进行实时交流，这样企业才会相信你并不是想偷懒。

2 尽可能让用户自己管理自己

很多用户能自己安装软件并实施软件升级，那就让他们自己做这些，让注册企业通过自助服务做这些事情。别再给用户做保姆了，除非有具体规定不允许这样做。让客户自己去安装iTunes、Gmail以及诸如此类的东西，让他们明白如果把自己的电脑搞砸了，你只会推倒重来，恢复到缺省状态，而不会为他们自己造成的损坏负责。你可以制定出这样的政策：如果他们用私人邮件、iPhone或者其他私人软件产品，他们要自己为自己的错误负责。确保每个用户都了解所有这些风险，以及你这么做的原因。毕竟，享受自由就要承担责任，你还有更重要的工作要做。

3 不做无用功

评估一下你的日常工作，看看他们都带来什么价值。很可能你正在发生概率很低的风险上浪费时间和精力。这听起来像是异端邪说，但相对于花费相当大的精力在防范措施上，可能让有些事偶尔出错然后修复会更有效。有了这个评估，你就能压缩繁琐的无用功，给企业带来他们真正想要的技术好处。

4 尽可能地让所有事情自动化

让公司知道自动化能给公司节省人力成本。确保你的监控程序了解所有情况，从你的路由器CPU的运用情况到入站传真线路的随机测试。确保大家明白只有一切尽在掌握，才能顺利实施自动化。

5 外包繁琐工作

SaaS和云计算不仅仅是最近的技术流行词，也是替你管理和维护服务器、存储和程序的方法。谷歌运用软件、Live工作空间以及诸如此类的东西能够很好地替代部门或者分支机构文件管理人员的工作。并且，它们的服务面向所有人。托管整个程序需要迈出很大一步，但原则同样适用。如果你正在为数量众多的工作组处理复杂的市场、销售、支持、预算、记账或者项目程序，那就该将环境合理化了。开始拔掉这些服务器的电源，让云计算整理这些应用吧。记得，最先考虑外包那些麻烦最多的程序和用户。

6 破除成规

实施IT分类可以适度缓解公司管理层的头疼。但别止于此，寻找任何机会去掉“最好要有”的功能以腾出手做真正重要的事。是时候重新评估以前的价值体系并清除成年规章了。这个老掉牙的法律流程真的是企业必需的吗?还是已经成为企业难以承受的奢侈品?用户真的需要在建筑物的每个角落都装上Wi-Fi吗?除非管理层视而不见，新项目和采购计划早就被重新检查过了。现在，你该用“显微镜”仔细检查一遍现有资产的成本和收益状况，尤其是管理员们欣赏的那些。

7 休息时间就是休息时间

回家后不要打开笔记本电脑，也关掉手机。周末就让垃圾邮件堆在那里好了。最快失去理智的方法是从未学习如何放松。从现在开始培养一些爱好吧，比如品品茶、打打球。平时工作时间的各种麻烦已经够多了，让它们在晚上和周末时间离开你的世界——除非你真的是别无选择。

8 没有什么事是你必须做的

硬件、软件、住宅、办公室、电脑、路由器，不管是什么，你修过它们一次并不意味着你就有责任要修它们一辈子。事实上，你可能从来就不该修它们。下次如果有人拿他自己的电脑过来让你“帮着看看”，你就反过来要他做一些他在工作中不可接受的事情。比如，“你是财务是吧，你能帮我把过去三年的报税做一下吗?我毫无头绪。”是啊，己所不欲，勿施于人。

9 永恒保持工作乐趣

是的，每件事都说很急，但你不能让技术的乐趣和创新被这些“急”事挤没了。事实上，保持工作乐趣是你工作的动力。如果你像行尸走肉，怎么能服务好公司呢?了解最新的科技能让你更好地解决工作中发生的问题。每天至少花费一小时在IT类的网站上，而不要日复一日像被关在笼子里面发电的老鼠一样。

10 让你的公司听到你的声音

跟你的公司交朋友。你已经听腻了这个“技术要服务于公司”的陈词滥调。现在，公司也需要了解你。跟业务部门开个会，去了解对他们来说什么是真正重要的，也让他们了解对你来说什么是真正重要的。一旦你意识到他们不都是冷血的机器，同事也发现你并不是脾气暴燥，那么，你会在早茶时间重新建立起重要的人际信任关系。

版本号：Mac OS X version 10.5.5

CPU: Processor 1 GHz PowerPC G4

iPhone SDK:iPhone_sdk_for_iPhone_os_2.2.19m2621afinal.dmg

说明：每个IPhone SDK可能兼容的Mac OS都不同，该SDK支持10.5.3以后的版本。还有，Intel 和 PowerPC 不同的CPU设置文件也不同，同一种CPU不同型号，设置也不同（注意PowerPC G3/G4/G5不同型号），详细请看下文。

重点的是：官方的iPhone SDK只支持Intel Mac with OSX 10.5.

二、 安装IPhone SDK

1. iPhone sdk 的后缀名为.dmg,只要双击该文件，弹出一个对话框，点“skip”,这就看到里面有3个文件，分别是About iPhone SDK.pdf 、iphone sdk.mpkg 、 Packages.如下图：

2. 双击iPhone sdk.mpkg,按引导到Custom Install on”Macintosh HD”那步，如图：

这是会看到iPhone SDK不可选，不知道是什么问题，不用害怕，下面有解决方案，我们是把可选的都选了，让所有的包都安装到默认的路径下。

注意： Developer Tools Essentials那个包的安装路径（默认为/Developer），等下安装iPhone SDK 时需要安装到同一路径下。

其实这一步已经安装好了Xcode3.1 了。

3. 安装iPhone SDK.

进入到刚才的前面.mdg包里面的Packages文件夹，即第一张图中的Packages文件夹,选择如下5个包逐个安装。各个包名均以iphone*开头。

注意：

要安装到和Developer Tools Essentials同一目录，即/Developer

如果已经安装到其他目录，可以不用重装。进入到安装目录，默认是/Platforms，然后复制 iPhone.platform 和iPhoneSimulator.platform 到 /Developer/Platform，注意不要把整个/Platforms复制。

现在还不能建立iphone 项目，就算建好也编译不过。出现如下错误：

No architectures to compile for (ONLY_ACTIVE_ARCH = YES, active arch = ppc, i386 VALID_ARCHS =)

所以需要进一步配置文件

4. 配置Architectures.xcspec文件

因为官方的iPhone SDK只支持Intel Mac with OSX 10.5.。所以要更改所有intel的配置。

进入到  /Developer/Platforms/iPhoneSimulator.platform/Developer/

Library/Xcode/Specifications/，你会看到3个文件，修改其中的Architectures.xcspec文件

注意：不要用copy内页代码来改，要用手动输入，因为网页编码不一致问题。

具体修改如下：

(

// 32-Bit

{ Type = Architecture;

Identifier = Standard;

Name = ”Standard (iPhone Simulator: i386, ppc)”;

Description = ”32-bit iPhone Simulator architectures”;

ListInEnum = YES;

SortNumber = 1;

RealArchitectures = ( i386, ppc );

ArchitectureSetting = ”ARCHS_STANDARD_32_BIT”;

},

// Old-style Debug

{ Type = Architecture;

Identifier = Native;

Name = ”Native Architecture of Build Machine”;

Description = ”32-bit for build machine”;

ListInEnum = YES;

SortNumber = 101;

ArchitectureSetting = ”NATIVE_ARCH”;

},

// G3

{ Type = Architecture;

Identifier = ppc;

Name = ”Minimal (32-bit PowerPC only)”;

Description = ”32-bit PowerPC ”;

PerArchBuildSettingName = ”PowerPC”;

ByteOrder = big;

ListInEnum = No;

SortNumber = 201;

},

// G4  这个是我台机的型号

{ Type = Architecture;

Identifier = ppc7400;

Name = ”PowerPC G4″;

Description = ”32-bit PowerPC for G4 processor”;

ByteOrder = big;

ListInEnum = NO;

SortNumber = 202;

},

// G5 32-bit

{ Type = Architecture;

Identifier = ppc970;

Name = ”PowerPC G5 32-bit”;

Description = ”32-bit PowerPC for G5 processor”;

ByteOrder = big;

ListInEnum = NO;

SortNumber = 203;

},

// Intel

{ Type = Architecture;

Identifier = i386;

Name = ”Intel”;

Description = ”32-bit Intel”;

PerArchBuildSettingName = ”Intel”;

ByteOrder = little;

ListInEnum = NO;

SortNumber = 105;

},

)

注意：不要copy，只能手输入以上代码，否则出错！！

这样就完成设置了。

=====================================================================

打开/Developer/Applications/选择Xcode,程序并不会马上运行,而是要你到快捷方式里再次点击打开.

打开File->new project选择View-Based Application

输入项目名称.

接下来看到的就是常见的文档视图,在Groups&Files下Resources里双击MainWindws.xib,紧接着将看到有新窗口的打开;

这时你可以拖动LIbery里的控件,像VS.net里一样使用就可以啦,运行行先保存,File->Save,运行Build and run.

这么一来,一个简单的HelloWorld就完成啦,兴喜.

另外还发现,IPhone的模拟器启动很快,基本不用时间哦,这点比其它强吧!展开Groups&Files 下的 Resources目录，选择双击MainWindow.xib,就会弹出xib主窗口和libery窗口，如果没有，可以通过Tools来调出窗口。Libery里有不同的控件，可以拖放到View窗口里，单击选中控件，选择Tools->inspetor打开属性窗口修改控件属性。

然后File->Save，Build->build and run.

大功告成！！

参考网站：

http://www.devdiv.net/thread-11230-1-1.html

http://jsc0754.blog.163.com/blog/static/1038922452009281156410/

AI  有太多的精彩瞬间值得纪念，无乱是自杀式的上篮，抛投，令人无能为力的加速，急停，他的身世，他的传闻，和他的坎坷道路。

新秀赛季和乔丹对决的瞬间

近两天，传闻湖人向刚刚退役的艾弗森抛出了橄榄枝，希望他能成为科比的队友。

现在的 AI 已经不是当年独挑大梁的球队老大，少了几分传奇色彩

无论如何，在我印象里的“答案”还是骁勇善战的强大战士，the tiger of eye~

了解自己电脑的配置，和硬件的型号可以用 everest 等软件很快的获取到：

IBM T61 配置：

操作系统      Microsoft Windows XP Professional 5.1.2600 (WinXP Retail)
处理器名称 Mobile DualCore Intel Core 2 Duo T7500, 2183 MHz (11 x 198)
主板名称      Lenovo ThinkPad T61
主板芯片组 Intel Crestline-PM PM965
系统内存     3072 MB  (DDR2 SDRAM)
显示卡         NVIDIA Quadro NVS 140M  (512 MB)
显示器         Lenovo LTN141W1-L05  [14.1" LCD]
声卡             Analog Devices AD1984 @ Intel 82801HBM ICH8M – High Definition Audio Controller

网卡:           Intel(R) 82566MM Gigabit Network Connection
无线网卡: Intel(R) Wireless WiFi Link 4965AGN

开始安装

1、将安装光盘放到到光驱中，以光驱起动机器到安装界面。

2、选择简体中文作为主要语言，然后点一下…>按钮。起动到准备安装界面，稍等一会儿后，到正式的安装欢迎界面。此时点屏上方的实用工具，调出“磁盘工具”，对你的硬盘进行初始化的操作。一般我们将把MAC OS安装在C分区，所以对原C分区进行“抹掉”操作（原C盘数据将全部丢失！）。

3、点抹掉并确认后，关闭窗口，回到欢迎界面。点“继续”钮。点“同意”Pass过许可协议页。到达选择目的宗卷页。选择你将要安装到的盘，点继续。

4、到达安装摘要页，在这里进入最最关键的部分，此时，不要直接点安装（直接点安装99%以上要失败，你的机器真的是APPLE机器的话也许会成功）。点“自定”按钮，进入驱动及附加包的选择安装页面。

5、选择如下：
本地化语言：
你爱怎么选怎么选，不过一般我们选两个中文够了。你要是不选中文，那就是不想用中文的MAC OS了，我也没得说。反正不会失败。

附加字体：
选上的好。

X11：请选上吧，以后用得着的，不选应该也没关系，是一个功能包。

iDeneb Essential System：选上吧，不选的话估计等于没装。

Patches 10.5.6 Ready：这个玩意是关键里的关键，是驱动，里面的东西选错了那就是失败！
Alternative Essential Patch 展开它
ACPI K10.5.6  电源管理驱动.(本人选上了).
PS2Fix for ACPI kext 10.5.6 (展开有两项) 如果你使用的是PS的键盘鼠标,请考虑选上,否则就不要选了.
AMD Patch 如果你使用的是AMD的CPU,请考虑选上.
Audio 展开它,并根据你的机器的声卡硬件进行选择.
Analog Devices 展开它，因为我的机器是 AD1984
Chipset 展开它,并根据你的机器的主板芯片进行选择.里面有好多,就不一一列出.
ICHx Fixed 本人机器使用的是ICH8,这项需要选择.其它不选.
Kernel 系统核心选择.展开它.
Kernel 9.5.0 Voodoo,本人选它,看编号最新.其它不选.
Network 网络,展开它.
Ethernet 以太网,展开它.根据你的网卡型号选择.
Intel 82566 本人选择它.E520的网卡为Intel 82562这个网卡仅兼容，驱动得不完美，一般情况下正常，一但睡眠醒来，网卡将无法正常工作！.当前本人没找到解决办法！
Wireless 无线网.请根据你自已的无线网卡型号选择.本人台机,华丽地飘过.
Fix 修正包集合,展开它,仅列出少量.
Cpus=1-Fix 单核CPU请考虑选它.本人不选
AppleSMBIOS 内存相关展开
AppleSMBIOS 667 本人667主频的内存,选择它.(经本人测试,可以不选,是否影响系统速度本人不知).
FireWire Remove 这个不能选，选的话，你的IEEE 1394卡就没用了.仅在不打算使用摄像机及其它IEEE 1394总线的朋友在无法安装时用。
Seatbel Fix 传说中的MAC四国补丁,不选它你就能看见四国了.没看见过四国的我很希望有一天有空看看.本项对我来说必选.
PowerOff_Fix 我选了这个。（E520机器不选这个的话，每回关机、重起，你就记得拔市电吧，否则就是黑苹果）。
PowerOff_OpenHaltRestart (这个在E520上不要装，装了睡眠后就没法恢复).这两项修正zwbshadow的说法
System Utilties   展开后里面就一个CPU控制,估计是CPU省电控制的,本人没选.
Video 显卡驱动. 估计一定要选一个,反正我如果没选,重起动就是黑屏,键盘能正常响应,就是什么也看不到了.
NVdarwin 512MB 本人外接了一个 NVIDIA Quadro NVS 140M  (512 MB)的显卡,为(512M显存的,所以选它了.请根据你的实际选，一般GF的显卡你只要设对了显存就OK了.
Intel GMA X3100 如果是Dell E520集成显卡的,应该要选它.
Applications 软件包,随你的高兴去选择.我是不懂的,所以,我全选了.宁全勿失的原则.
Netbook 笔记本专用 台式机再次飘过.

6、选完了就点“完成”吧。点完成后回到安装摘要界面，点“安装”。

7、漫长的安装过程开始了，最开始是检测光盘的完整，点跳过，到下面的界面：

参考网站，感谢他们的指导：

http://bbs.pcbeta.com/thread-618714-1-1.html
http://bbs.weiphone.com/read-htm-tid-358709.html
http://bbs.pcbeta.com/viewthread.php?tid=523231&highlight=%2B%B0%A5%D1%BD%A1%AD%A1%AD
IBM X61安装iDENEB10.5.6成功经验
IBM X61安装iDENEB10.5.6成功经验

find /fse/ | xargs grep  “感冒”                       (在 fse 文件夹中搜索 “感冒”)

xargs – build and execute command lines from standard input
This manual page documents the GNU version of xargs.  xargs reads items from
       the standard input, delimited by blanks (which can be protected with  double
       or  single  quotes  or  a  backslash)  or newlines, and executes the command
       (default is /bin/echo) one or more times with any initial-arguments followed
       by  items  read  from standard input.  Blank lines on the standard input are
       ignored.     默认情况下：xargs是忽略了空格和线这些文件名。让查找跟准确。 Because Unix  filenames  can  contain  blanks  and  newlines,  this  default
       behaviour  is often problematic; filenames containing blanks and/or newlines
       are incorrectly processed by xargs.  In these situations it is better to use
       the  `-0′ option, which prevents such problems.   When using this option you
       will need to ensure that the program which produces the input for xargs also
       uses a null character as a separator.  If that program is GNU find for exam-
       ple, the `-print0′ option does this for you.        If any invocation of the command exits with a status of 255, xargs will stop
       immediately  without  reading any further input.  An error message is issued
       on stderr when this happens.  

也就是说查找的文件中如果含有空格和线，者xargs会出现报错。当加上-o后，他就可以识别。

find /tmp -name core -type f -print | xargs /bin/rm -f

       Find files named core in or below the directory /tmp and delete them.  Note that this will work incorrectly if there  are
       any filenames containing newlines or spaces.

       find /tmp -name core -type f -print0 | xargs -0 /bin/rm -f

       Find  files  named  core  in or below the directory /tmp and delete them, processing filenames in such a way that file or
       directory names containing spaces or newlines are correctly handled.

注意，向find /tmp -name core -type f -print | xargs /bin/rm –f如果改成：

xargs 的作用是输入重定向。

Find /tmp –name core –type f –print |rm –f 则不会起作用。

cut -d: -f1 < /etc/passwd | sort | xargs echo
 Debian-exim backup bin cjl daemon games gnats  irc  list lp mail man news nobody proxy root snmp sshd sync sys uucp www-data xiaowang

从这个命令更可以看出他的输入重定向功能。 

sudo find /home/liangyin/mrtgbackup/ -type f  -print|xargs grep -rl “10.163.28.3.*”

/home/liangyin/mrtgbackup/b/mrtg/10.163.28.3_146800777.html

/home/liangyin/mrtgbackup/b/mrtg/10.163.28.3_146800785.html

/home/liangyin/mrtgbackup/b/mrtg/10.163.28.3_146800793.html

/home/liangyin/mrtgbackup/b/mrtg/10.163.28.3_146800801.html

/home/liangyin/mrtgbackup/b/mrtg/10.163.28.3_146800809.html

/home/liangyin/mrtgbackup/b/mrtg/10.163.28.3_146800817.html

-R, -r, –recursive

              Read all files under each directory, recursively; this is equivalent  to  the  -d  recurse

              option.

-l, –files-with-matches

              Suppress normal output; instead print the name of each input file from which output  would

              normally have been printed.  The scanning will stop on the first match.

-l 的意思找到内容后输出的是文件的形式，不是文件的内容。

而grep 默认情况下：输出的是文件的内容。

find -type f -name ‘*.png’ | xargs -n1  | while read ABC; do echo $ABC && mv $ABC ${ABC%.png}.gif ; done

这里-n 意思是一个传N个选项给命令。这样查找更准确。

find -type f -name ‘*.png’ |while read ABC; do mv  $ABC ${ABC%.png}.gif;done

可以用这个命令来实现。注意：%

豆瓣从今年开始也加入 Google Analytics 的统计阵营。让我们通过它加载的 Google Analytics 源码，简单分析一下它都是怎么应用的。

我们先从豆瓣的源码来看看它的Google Analytics统计代码

豆瓣 Google Analytics 代码

我们知道一般默认的 Google Analytics代码如下：

默认 Google Analytics 统计代码

两相对比，我们就会发现豆瓣加载 ga.js 的方式与默认的方式有些不太一样，由于豆瓣并没有采用 https 加密访问，所以撇弃了默认的ga.js加载方式。

默认的统计函数，pageTracker 也被豆瓣改成了 _ga ，这个只是名称定义上的区别，并没有什么实质的改变。豆瓣的主要应用是下面两个函数：

使用 _ga._addOrganic 识别非主流搜索引擎

再来看豆瓣比默认 Google Analytics 代码增加的部分，那就是多了数个 _ga._addOrganic ，这是 Google Analytics 添加自定义搜索引擎的代码。尽管 Google Analytics 对于主流的搜索引擎都能自动识别，但毕竟能识别的是国外的主流搜索引擎，在国内，像搜狐的 Sogou，QQ 的 soso，网易的有道等搜索引擎，都不能被 Google Analytics 正确识别，而被当作推荐来源。这时候我们就可以利用_addOrganic 参数来识别这些非主流搜索引擎，如豆瓣的做法。

使用 _addIgnoredOrganic 忽略关键字

除了添加自定义搜索引擎，豆瓣在最后还添加了如下这些代码:

_ga._addIgnoredOrganic("豆瓣");
_ga._addIgnoredOrganic("douban");
_ga._addIgnoredOrganic("豆瓣网");
_ga._addIgnoredOrganic("www.douban.com");

这些代码用来把引号中的关键词从搜索引擎的关键词报告中排除，而当成直接点击量来源。

为什么要这么做？因为一个知名的大网站，来自这些品牌词的搜索流量都非常大，常常是排在前几位的搜索关键词来源，而这通常是因为搜索引擎养成现在的人都懒得记网址，直接搜索品牌名来记住域名。这些品牌词对于网站的关键词来源分析并没有很直接的帮助，所以在来自品牌词的流量很大的情况下，可以直接把这些关键词识别成直接点击量来源。

关于自定义 Google Analytics 搜索引擎和排除特定关键词为直接点击量来源的语法，可以参考 Google Code 上关于这方面的详细介绍。

通过 _setVar 识别用户

当我们登录豆瓣后，再来分析豆瓣的源码，会发现多了一个ga._setVar(”xxxx”)的 Google Analytics 参数。

豆瓣使用 Google Analytics 的._setVar参数来跟踪登录用户行为

_setVar() 函数是 Google Analytics 的用户定义函数，主要用于对特定来源的用户行为进行分类，例如可以对登录浏览的用户设置一个数值，然后在 Google Analytics 后台的访问者/用户定义 中查看其浏览属性。

Google Analytics 访问者/用户定义报告

分析豆瓣的源码可以知道，豆瓣对每一个登录后的用户，都赋以一个专门的 id 值，这样可以在用户定义报告里，看到整体的登录用户访问行为，乃至每个登录用户的浏览行为。通过这样设定后，豆瓣便可以轻易获取高忠诚度访问用户的访问行为。关于_setVar()的更多说明，请参阅 Google Analytics的技术文档

如何根据访问者在我的网站上访问的页面或在表单上做出的响应对其进行分类？在 Google Analytics 官方的帮助文件，也给出了另外一个应用案例

值得注意的是，原来在设置 _setVar() 函数的时候，整个网站的跳出率会出现重大的偏差，不过在最近的google analytics官方博客，指出该bug已经修正，客户在进行这方面设置的时候，还是要注意对比前后数据是否有重大偏差。

通过 _trackPageview 区分不同类型的评论

豆瓣上的书评，影评和乐评可以说是豆瓣网站的核心价值所在。一般评论的URL格式如下：

豆瓣上单条评论的URL

当我们查看该页面的网页源代码时，会发现有趣的现象:

豆瓣单条评论页的 Google Analytics 代码

我们知道，一般 Google Analytics 的_trackPageview() 括弧中的参数是留空的， Google Analytics 会自动捕获网址的 URL 参数，如果在 _trackPageview()括弧中输入特定的数值，那么在 Google Analytics 的报表中，URL 将是我们指定的参数，而不再是我们在地址栏看到的 URL。

如上面的例子，我们在 Google Analytics 中看到的URL将是/book/review/1946018/，而不再是我们在浏览器地址栏看到的/review/1946018/

当所在频道是电影或者音乐时，_trackPageview() 中的参数将根据所在频道的属性，变为/movie/xxxxx 或者 /music/xxxxx的数值。

豆瓣通过对的参数进行重新指定，主要有以下的好处：

保证了用户和搜索引擎看到的 URL 比较简短，达到 URL 对用户友好和对搜索引擎友好的目的；而在 Google Analytics 报告中，通过 内容/内容细目/ 报告，又能了解到各个频道总的浏览情况。

在GA的内容细目报告中，将会多出 /book/ /music/ /movie/ 这样的文件夹来，总而获得各个频道的合计浏览数据。

而如果只是使用默认 _trackPageview()，你将只能得到所有评论页面的浏览数据，而无法得到细分的各个频道的浏览数据。

关于_trackPageview()的具体的使用方法可参照 Google Code 的说明

注意事项:使用 _trackPageview() 参数重新指定 URL 之后，网站覆盖图的数据将受到影响。可参阅 Google Analytics 的官方帮助文件

除了豆瓣使用 _trackPageview() 来对URL进行重写，大众点评网也采用了类似的做法（应该是比豆瓣更早采用。。。因为是我在点评网任职时候实验的做法;那时候豆瓣还没有使用 Google Analytis 统计代码，呵呵），有兴趣的同学可以自己去研究点评的 Google Analytis 代码。

1、关心你的技艺
Care About Your Craft
除非你在乎能否漂亮地开发出软件，否则其它事情都是没有意义的。

2、思考！你的工作
Think!About Your Work
在你做某件事情的时候思考你在做什么。不间断地思考，实时地批判你的工作。这将占据你的一些宝贵时间，酬劳则是更为活跃地参与你喜爱的工作、感觉到自己在掌握范围日增的各种主题以及因感受到持续的进步而欢愉。从长远来说，你在时间上的投入将会随着你和你的团队变得更为高效、编写出更易于维护的代码以及开会时间的减少而得到回报。

3、提供各种选择，不要找蹩脚的借口
Provide Options,Don’t Make Lame Excuses
不要说事情做不到；要说明能够做什么来挽回局面。不要害怕提出要求，也不要害怕承认你需要帮助。

4、不要容忍破窗户
Don’t Live With Broken Windows
不要留着“破窗户”（低劣的设计、错误的决策、或者糟糕的代码）不修。发现一个就修一个。如果没有足够的时间进行适当的修理，采取某种行动防止进一步的破坏，并说明情势处在你的控制之下。
如果你发现你所在团队和项目的代码十分漂亮——编写整洁、设计良好，并且很优雅，你不会想成为第一个弄脏东西的人。

5、做变化的催化剂
Be a Catalyst for Change
你不能强迫人们改变。相反，要向他们展示未来可能会怎样，并帮助他们参与对未来的创造。
设计出你可以合理要求的东西，好好开发它。一旦完成，就拿给大家看，让他们大吃一惊。然后说：“要是我们增加…可能就会更好。”假装那并不重要。坐回椅子上，等着他们开始要你增加你本来就想要的功能。人们发现，参与正在发生的成功要更容易。让他们瞥见未来，你就能让他们聚集在你周围。

6、记住大图景
Remember the Big Picture
如果你抓一只青蛙放进沸水里，它会一下子跳出来。但是，如果你把青蛙放进冷水里，然后慢慢加热，青蛙不会注意到温度的缓慢变化，会呆在锅里，直到被煮熟。
不要像青蛙一样。留心大图景。要持续不断地观察周围发生的事情，而不只是你自己在做的事情。

7、使质量成为需求问题
Make Quality a Requirements Issue
你所制作的系统的范围和质量应该作为系统需求的一部分规定下来。让你的用户参与权衡，知道何时止步，提供足够好的软件。

8、定期为你的知识资产投资
Invest Regularly in Your Knowledge Portfolio

• 让学习成为习惯。
• 持续投入十分重要。一旦你熟悉了某种新语言或新技术，继续前进，学习另一种。
• 是否在某个项目中使用这些技术，或者是否把它们放入你的简历，这并不重要。学习的过程将扩展你的思维，使你向着新的可能性和新的做事方式拓展。思维的“异花授粉”十分重要；设法把你学到的东西应用到你当前的项目中。即使你的项目没有使用该技术，你或许也能借鉴一些想法。例如，熟悉了面向对象，你就会用不同的方式编写纯C程序。
• 如果你自己找不到答案，就去找出能找到答案的人。不要把问题搁在那里。

9、批判地分析你读到的和听到的
Critically Analyze What You Read and Hear
不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。

10、你说什么和你怎么说同样重要
It’s Both What You Say and the Way You Say It

• 作为开发者，我们必须在许多层面上进行交流。我们的时间有很大部分都花在交流上，所以我们需要把它做好。
• 如果你不能有效地向他人传达你的了不起的想法，这些想法就毫无用处。
• 知道你想要说什么；了解你的听众；选择时机；选择风格；让文档美观；让听众参与；做倾听者；回复他人。
• 交流越有效，你就越有影响力。

11、DRY原则——不要重复你自己
DRY – Don’t Repeat Yourself
系统中的每一项知识都必须具有单一、无歧义、权威的表示。与此不同的做法是在两个或更多地方表达同一事物。如果你改变其中一处，你必须记得改变其它各处。这不是你能否记住的问题，而是你何时忘记的问题。

12、让复用变得容易
Make it Easy to Reuse
你要做的是营造一种环境，在其中要找到并复用已有的东西，比自己编写更容易。如果复用很容易，人们就会去复用。而如果不复用，你们就会有重复知识的风险。

13、消除无关事物之间的影响
Eliminate Effects Between Unrelated Things
我们想要设计自足（self-contained）的组件：独立，具有单一、良好定义的目的。如果组件是相互隔离的，你就知道你能够改变其中一个，而不用担心其余组件。只要你不改变组件的外部接口，你就可以放心：你不会造成波及整个系统的问题。
你得到两个主要好处：提高生产率与降低风险。

14、不存在最终决策
There Are No Final Decisions
没有什么永远不变——而如果你严重依赖某一事实，你几乎可以确定它将会变化。与我们开发软件的速度相比，需求、用以及硬件变得更快。通过DRY原则、解耦以及元数据的使用，我们不必做出许多关键的、不可逆转的决策。有许多人会设法保持代码的灵活性，而你还需要考虑维持架、部署及供应商集成等领域的灵活性。

15、用曳光弹找到目标
Use Tracer Bullets to Find the Target
曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。
曳光弹代码含有任何一段产品代码都拥有的完整的错误检查、结构、文档、以及自查。它只不过功能不全而已。但是，一旦你在系统的各组件之间实现了端到端（end-to-end）的连接，你就可以检查你离目标还有多远，并在必要的情况下进行调整。一旦你完全瞄准，增加功能将是一件容易的事情。

16、为了学习而制作原型
Prototype to Learn
任何带有风险的事物。以前没有试过的事物，或是对于最终系统极其关键的事物。任何未被证明的、试验性的、或有疑问的事物。任何让你觉得不舒服的东西。都可以通过制作原型来研究。比如：架构；已有系统中的新功能；外部数据的结构或内容；第三方工具或组件；性能问题；用户界面设计等等。
原型制作是一种学习经验，其价值并不在于所产生的代码，而在于所学到的经验教训。

17、靠近问题领域编程
Program Close to The Problem domain
计算机语言会影响你思考问题的方式，以及你看待交流的方式。用你的用户的语言进行设计和编码。

18、估算，以避免发生意外
Estimate to Avoid Surprises
在着手之前先进行估算。你将提前发现潜在的问题。
1）要选择能反映你想要传达的精确度的单位；
2）基本的估算诀窍：去问已经做过这件事情的人；
3）理解提问内容；
4）根据对问题的理解，建立粗略、就绪的思维模型骨架；
5）把模型分解为组件，找出描述这些组件怎样交互的数学规则，确定每个组件的参数；
6）给每个参数指定值，找出哪些参数对结果的影响最大，并致力于让它们大致正确；
7）进行多次计算，改变关键参数的值，然后根据那些参数表达你的答案；
8）在被要求进行估算时说的话：“我等会回答你”。

19、通过代码对进度表进行迭代
Iterate the Schedule with the Code
实行增量开发。追踪你的估算能力，提炼对迭代次数、以及在每次迭代中可以包含的内容的猜想。提炼会变得一次比一次好，对进度表的信心也将随之增长。你将给予管理部门你所能给予的最精确的进度估算。

20、用纯文本保存知识
Keep Knowledge in Plain Text

• 保证不过时；
• 杠杆作用：每一样工具，都能够在纯文本上进行操作；
• 更易于测试；
• 你需要确保所有各方能够使用公共标准进行通信。纯文本就是那个标准。

21、利用命令shell的力量
Use the Power of Command Shells
GUI环境通常受限于它们的设计者想要提供的能力。当你想要快速地组合一些命令，以完成一次查询或某种其他的任务时，命令行要更为适宜。多使用你的命令shell，你会惊讶它能使你的生产率得到怎样的提高。

22、用好一种编辑器
Use a Single Editor Well
选一种编辑器，彻底了解它，并将其用于所有的编辑任务。如果你用一种编辑器进行所有的文本编辑活动，你就不必停下来思考怎样完成文本操纵：必需的键击将成为本能反应。编辑器将成为你双手的延伸；键会在滑过文本和思想时歌唱起来。这就是我们的目标。

23、总是使用源码控制
Always Use Source Code Control

• 总是。即使你的团队只有你一个人，你的项目只有一周时间；确保每样东西都处在源码控制之下。
• 源码控制是你的工作的时间机器——你能够回到过去。
• 把整个项目置于源码控制系统的保护之下具有一项很大的、隐蔽的好处：你可以进行自动的和可重复的产品构建。

24、要修正问题，而不是发出指责
Fix the Problem,Not the Blame
要接受事实：调试就是解决问题，要据此发起进攻。Bug是你的过错还是别人的过错，并不是真的很有关系。它仍然是你的问题。

25、不要恐慌
Don’t Panic
做一次深呼吸，思考什么可能是bug的原因。

• 要总是设法找出问题的根源，而不只是问题的特定表现；
• 搜集所有的相关数据；
• 开始修正bug的最佳途径是让其可再现；
• 使你的数据可视化；
• 跟踪：观察程序或数据结构随时间变化的状态；
• 找到问题的原因的一种非常简单、却又特别有用的技术是向别人解释它。你只是一步步解释代码要做什么，常常就能让问题从屏幕上跳出来，宣布自己的存在。

26、“Select”没有问题
“Select” Isn’t Broken
Bug有可能存在于OS、编译器、或是第三方产品中——但这不应该是你的第一想法。有大得多的可能性的是，bug存在于正在开发的应用代码中。与假定库本身出了问题相比，假定应用代码对库的调用不正确通常更有好处。即使问题确实应归于第三方，在提交bug报告之前，你也必须先消除你的代码中的bug。

27、不要假定，要证明
Don’t Assume it – Prove It
不要因为你“知道”它能工作而轻易放过与bug有牵连的例程或代码。证明它。在实际环境中——使用真正的数据和边界条件——证明你的假定。

28、学习一种文本操作语言
Learn a Text Manipulation Language
你用每天的很大一部分时间处理文本，为什么不让计算机替你完成部分工作呢？
应用示例：

• 数据库schema维护;
• Java、C#属性(Property)访问;
• 测试数据生成。

29、编写能编写代码的代码
Write Code That Writes Code
代码生成器能提高你的生产率，并有助于避免重复。

30、你不可能写出完美的软件
You Can’t Write Perfect Software
这刺痛了你？不应该。把它视为生活的公理，接受它，拥抱它，庆祝它。因为完美的软件不存在。在计算机简短的历史中，没有一个人曾经写出过一个完美的软件。你也不大可能成为第一个。除非你把这作为事实接受下来，否则你最终会把时间和精力浪费在追逐不可能实现的梦想上。

31、通过合约进行设计
Design with Contracts
什么是正确的程序？不多不少，做它声明要做的事情的程序。用文档记载这样的声明，并进行校验，是按合约设计（简称DBC）的核心所在。
这里，强调的重点是在“懒惰”的代码上：对在开始之前接受的东西要严格，而允诺返回的东西要尽可能少。
使用DBC的最大好处也许是它迫使需求与保证的问题走到前台来。在设计时简单地列举输入域的范围是什么、边界条件是什么、例程允诺交付什么——或者，更重要的，它不允诺交付什么——是向着编写更好的软件的一次飞跃。不对这些事项作出陈述，你就回到了靠巧合编程，那是许多项目开始、结束、失败的地方。

32、早崩溃
Crash Early
死程序不说谎。
当你的代码发现，某件被认为不可能发生的事情已经发生时，你的程序就不再有存活能力。从此时开始，它所做的任何事情都会变得可疑，所以要尽快终止它。死程序带来的危害通常比有问题的程序要小得多。

33、如果它不可能发生，用断言确保它不会发生
If It Can’t Happen,Use Assertions to Ensure That It Won’t
断言验证你的各种假定。在一个不确定的世界里，用断言保护你的代码。
不要用断言代替真正的错误处理。断言检查的是决不应该发生的事情。

34、将异常用于异常的问题
Use Exceptions for Exceptional Problems
异常表示即使的、非局部的控制转移——这是一种级联的（cascading）goto。异常应保留给意外事件。那些把异常用作其正常处理的一部分的程序，将遭受所有可读性和可维护性问题的折磨。这些程序破坏了封装：通过异常处理，例程和它们的调用者被更紧密地耦合在一起。

35、要有始有终
Finish What You Start
只要可能，分配某资源的例程或对象也应该负责解除其分配。

36、使模块之间的耦合减至最少
Minimize Coupling Between Modules

• 编写“羞怯”的代码；
• 函数的得墨忒耳(Demeter)法则规定，某个对象的任何方法都应该只调用属于以下情形的方法：
  1）它自身；
  2）传入该方法的任何参数；
  3）它创建的任何对象；
  4）任何直接持有的组件对象。
• 物理解耦。

37、要配置，不要集成
Configure,Don’t Integrate
细节会弄乱我们整洁的代码——特别是如果它们经常变化。把它们赶出代码。当我们在与它作斗争时，我们可以让我们的代码变得高度可配置和“软和”——也就是，容易适应变化。
要用元数据（metadata）描述应用的配置选项：调谐参数、用户偏好（user preference）、安装目录，等等。

38、将抽象放进代码，细节放进元数据
Put Abstractions in Code,Details in Metadata
但我们不只是想把元数据用于简单的偏好。我们想要尽可能多地通过元数据配置和驱动应用。我们的目标是以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活和可适应的应用。我们通过采用一条一般准则来做到这一点：为一般情况编写程序，把具体情况放在别处——在编译的代码库之外。
也许你在编写一个具有可怕的工作流需求的系统。动作会根据复杂的（和变化的）商业规则启动和停止。考虑在某种基于规则的系统（即专家系统）中对它们进行编码，并嵌入到你的应用中。这样，你将通过编写规则、而不是修改代码来配置它。

39、分析工作流，以改善并发性
Analyze Workflow to Improve Concurrency
时间是软件架构的一个常常被忽视的方面。时间有两个方面对我们很重要：并发（事情在同一时间发生）和次序（事情在时间中的相对位置）。
我们在编写程序时，通常并没有把这两个方面放在心上。当人们最初坐下来开始设计架构，或是编写代码时，事情往往是线性的。那是大多数人的思考方式——总是先做这个，然后再做那个。但这样思考会带来时间耦合：方法A必须总是在方法B之前调用；同时只能运行一个报告；在接收到按钮点击之前，你必须等待屏幕重画。“嘀”必须在“嗒”之前发生。
这样的方法不那么灵活，也不那么符合实际。
我们需要容许并发，并考虑解除任何时间或者次序上的依赖。

40、用服务进行设计
Design Using Services
实际上我们创建的并不是组件，而是服务——位于定义良好的、一致的接口之后的独立、并发的对象。
通过把你的系统架构成多个独立的服务，你可以让配置成为动态的。

41、总是为并发进行设计
Always Design for Concurrency
首先，必须对任何全局或静态变量加以保护，使其免于并发访问，现在也许是问问你自己、你最初为何需要全局变量的好时候。此外，不管调用的次序是什么，你都需要确保你给出的是一致的状态信息。
在被调用时，对象必须总是处在有效的状态中，而且它们可能会在最尴尬的时候被调用。你必须确保，在任何可能被调用的时刻，对象都处在有效的状态中。这一问题常常出现在构造器与初始化例程分开定义的类中（构造器没有使对象进入已初始化状态）。
一旦你设计了具有并发要素的架构，你可以灵活地处理应用的部署方式：单机、客户-服务器、或是n层。

42、使视图与模型分离
Separate Views from Models
也就是常说的MVC模式（Model-View-Controller）。

• 模型。表示目标对象的抽象数据模型。模型对任何视图或控制器都没有直接的了解。
• 视图。解释模型的方式。它订阅模型中的变化和来自控制器的逻辑事件。
• 控制器。控制视图、并向模型提供新数据的途径。
  通过松解模型与视图/控制器之间的耦合，你用低廉的代价为自己换来了许多灵活性。

43、用黑板协调工作流
Use Blackboards to Coordinate Workflow
用黑板协调完全不同的事实和因素，同时又使各参与方保持独立和隔离。
现代的分布式类黑板（blackboard-like）系统，比如JavaSpaces和T Spaces。

44、不要靠巧合编程
Don’t Program by Coincidence

• 总是意识到你在做什么。
• 不要盲目地编程。试图构建你不完全理解的应用，或是使用你不熟悉的技术，就是希望自己被巧合误导。
• 按照计划行事。
• 依靠可靠的事物。如果你无法说出各种特定情形的区别，就假定是最坏的。
• 为你的假定建立文档。“按合约编程”有助于澄清你头脑中的假定，并且有助于把它们传达给别人。
• 不要只是测试你的代码，还要测试你的假定。
• 为你的工作划分优先级。
• 不要做历史的奴隶。不要让已有的代码支配将来的代码。
  所以下次有什么东西看起来能工作，而你却不知道为什么，要确定它不是巧合。

45、估算你的算法的阶
Estimate the Order of Your Algorithms
在你编写代码之前，先大致估算事情需要多长时间。

46、测试你的估算
Test Your Estimates
对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定它的速度。

47、早重构，常重构
Refactor Early,Refactor Often
在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。不要容忍破窗户。
关于重构，详见Martin Fowler的《重构》一书。

48、为测试而设计
Design to Test
在你还没有编写代码时就开始思考测试问题。测试驱动开发？

49、测试你的软件，否则你的用户就得测试
Test Your Software,or Your Users Will
测试是技术，但更是文化。一点预先的准备可以大大降低维护费用、减少客户服务电话。

50、不要使用你不理解的向导代码
Don’t Use Wizard Code You Don’t Understand
向导很了不起。只需要点击一个按钮，回答一些简单的问题，向导就会自动为你生成骨架代码（skeleton code）。但如果你使用向导，却不理解它制作出的所有代码，你就无法控制你自己的应用。你没有能力维护它，而且在调试时会遇到很大的困难。

51、不要搜集需求——挖掘它们
Don’t Gather Requirements – Dig for Them
需求很少存在于表面上。它们深深地埋藏在层层假定、误解和政治手段的下面。

52、与用户一同工作，以像用户一样思考
Work with a User to Think Like a User
要了解系统实际上将如何被使用，这是最好的方法。开采需求的过程也是开始与用户群建立和谐的关系、了解他们对你正在构建的系统的期许和希望的时候。

53、抽象比细节活得更长久
Abstractions Live Longer than Details
“投资”于抽象，而不是实现。抽象能在来自不同的实现和新技术的变化的“攻击”之下存活下去。

54、使用项目词汇表
Use a Project Glossary
如果用户和开发者用不同的名称指称同一事物，或是更糟，用同一名称指称不同事物，这样的项目很难取得成功。

55、不要在盒子外面思考——要找到盒子
Don’t Think Outside the Box – Find the Box
在遇到不可能解决的问题时，问问自己以下问题：

• 有更容易的方法吗？
• 你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
• 这件事情为什么是一个问题？
• 是什么使它如此难以解决？
• 它必须以这种方式完成吗？
• 它真的必须完成吗？
  很多时候，当你设法回答这些问题时，你会有让自己吃惊的发现。很多时候，对需求的重新诠释能让整个问题全部消失。
  你所需要的只是真正的约束、令人误解的约束、还有区分它们的智慧。

56、倾听反复出现的疑虑——等你准备好再开始
Listen to Nagging Doubts – Start When You’re Ready
你的一生都在积累经验与智慧。当你面对一件任务时，如果你反复感觉到疑虑，或是体验到某种勉强，要注意它。你可能无法准确地指出问题所在，但给它时间，你的疑虑很可能就会结晶成某种更坚实的东西，某种你可以处理的东西。软件开发仍然不是科学。让你的直觉为你的表演做出贡献。

57、对有些事情“做”胜于“描述”
Some Things Are Better Done Than Described
你应该倾向于把需求搜集、设计、以及实现视为同一个过程——交付高质量的系统——的不同方面。不要掉进规范的螺旋，在某个时刻，你需要开始编码。

58、不要做形式方法的奴隶
Don’t Be a Slave to Formal Methods
如果你没有把某项技术放进你的开发实践和能力的语境中，不要盲目地采用它。

59、昂贵的工具不一定能制作出更好的设计
Expensive Tools Do Not Produce Better Designs
小心供应商的炒作、行业教条、以及价格标签的诱惑。在考察工具的产出时，试着不要考虑它值多少钱。

60、围绕功能、而不是工作职务进行组织
Organize Around Functionality,Not Job Functions
把你的人划分成小团队，分别负责最终系统的特定方面的功能。让团队按照个人的能力，在内部自行进行组织。
但是，只有在项目拥有负责的开发者、以及强有力的项目管理时，这种途径才有效。创立一组自行其是的团队并放任自流，是一种灾难性的处方。
要记住，团队是由个体组成的。让每个成员都能以他们自己的方式闪亮。

61、不要使用手工流程
Don’t Use Manual Procedures
shell脚本或批处理文件会一次次地以同一顺序执行同样的指令。我们可以自动安排备份、夜间构建、网站维护、以及其他任何可以无人照管地完成的事情。让计算机去做重复、庸常的事情——它会做得比我们更好。我们有更重要、更困难的事情要做。

62、早测试，常测试，自动测试。
Test Early.Test Often.Test Automatically.
与呆在书架上的测试计划相比，每次构建时运行的测试要有效得多。

63、要等到通过全部测试，编码才算完成
Coding Ain’t Done ‘Til All the Tests Run
就是这样。

64、通过“蓄意破坏”测试你的测试
Use Saboteurs to Test Your Testing
在单独的软件副本上故意引人bug，以检验测试能够抓住它们。

65、测试状态覆盖，而不是代码覆盖
Test State Coverage,Not Code Coverage
确定并测试重要的程序状态。只是测试代码行是不够的。即时具有良好的代码覆盖，你用于测试的数据仍然会有巨大的影响，而且，更为重要的是，你遍历代码的次序的影响可能是最大的。

66、一个bug只抓一次
Find Bugs Once
一旦测试员找到一个bug，这应该是测试员最后一次找到它。此后自动测试应该对其进行检查。

67、把英语当作又一种编程语言
Treat English as Just Another Programming Language
像你编写代码一样编写文档：遵守DRY原则、使用元数据、MVC、自动生成，等等。

68、把文档建在里面，不要拴在外面
Build Documentation In,Don’t Bolt It On
与代码分离的文档不太可能被修正和更新。使用像JavaDoc和NDoc这样的工具，我们可以根据源码生成API级的文档。
文档和代码是同一底层模型的不同视图，但视图是唯一应该不同的东西。

69、温和地超出用户的期望
Gently Exceed Your Users’ Expectations
要设法让你的用户惊讶。请注意，不是惊吓他们，而是要让他们高兴。要理解用户的期望，然后给他们的东西要多那么一点。给系统增加某种面向用户的特性所需的一点额外努力将一次又一次在商誉上带来回报。

70、在你的作品上签名
Sign Your Work
我们想要看到对所有权的自豪。“这是我编写的，我对自己的工作负责。”你的签名应该被视为质量的保证。当人们在一段代码上看到你的名字时，应该期望它是可靠的、用心编写的、测试过的和有文档的，一个真正的专业作品，由真正的专业人员编写。
一个注重实效的程序员。

Google亦很小心,不会把Chrome OS定位为Windows对手。Eric在记者会中还笑说,欢迎微软把Internet Explorer 植入Chrome OS,那是否有机会发生,相信应该不会了。