今天早上的数字图像处理期末考试完全变成了IQ测试，非常有趣。作为专业选修课，很多人都是上课但不怎么听，书也不怎么看，然后就去考试了。考试是开卷的，说明了题目来自平时作业，不过数据会有所有不同，于是大家就把老师给的作业答案带去了。
这里先说明一件事，就是其实大多数人的作业也不是自己做的，都是参考着一份别人做好的“作业模板”做的，最好的情况下这份模板需要你填的就只剩下姓名和学号了。因此，考试的时候即使仅仅考作业题，也未必是懂的，那么怎么办呢？就只有临场学习咯。
IQ题是怎样的？例如3*3共9个图案，其中缺了一个，要你从4个里面选一个补上去让它最符合规律。这就是今天我们考试所做的事情。我们看着那份作业答案，里面只有题目和答案但没有中间过程，于是我们就要想尽办法去找规律——到底如何从题目推导出答案，然后模仿着这个推导过程去做试卷。整个过程真的和考IQ差不多，不过题目要难度了，因为规律并不简单。
在我制作自己的在线简历以及作品时，就想到是否能设计一种microformat用于描述resume。事实上，相信我们很多人都有过在网上投递简历的经验，每次大多数相同的项目都要重新填写，极之麻烦，所以我就希望这些重复工作能够一次搞定。相对于制作一个客户端的helper来帮忙填写简历，我更希望是一种描述简历用的microformat，因为我自己正在制作在线简历，而且希望这是一个有潜力的市场。
每天都有很多人网投，特别是毕业生，如果制作一个helper确实能够帮上忙的，然而这个工具无论被多少人使用，最终就是一个小软件，别人极容易模仿着做一个更好的。这样的客户端软件没有任何的粘连性，用户觉得另外一个更好的话随时可以换，所以做成服务很有必要。Web2.0时代，SaaS了，这才是真正的发展方向，而microformat能够和这个沾上边。
开头我们当然只有描述resume的一种microformat，制作在线简历的人少之又少，就好像回到了1998年之前，能够拥有一个美观而且有内容的个人网站是非常值得让人羡慕的事情。1999年，Blogger出现了，为当时那些拥有个人网站的精英群体实现了一个梦想——简单易用的日志管理方式。然而一开始确实也就只有高端群体在使用Blogger这样的工具，直到被称之为blogger年的2003年，使用各种blogging工具的人数开始激增。我期望这种描述resume的microformat的发展也如此，在经历了只有少数高端用户使用的阶段后，能够逐步大众化，变得好像blogging一样容易。
这背后潜在的市场也就是在线简历的空间与管理服务了。就如BSP一样，如果提供一定的存储空间，并且有相对简单易用的编辑功能，若干可以选择的模板，相信谁都可以马上制作一份在线简历，然后或许再购买一个域名搭配上。就如同Blogger提供的服务一样，中低端用户或许只会简单地从模板中选择一个合适的，并且将简历放在服务提供商的空间上，就好像Blogger发布到Blog*Spot上一样简单而且免费；高端用户会购买自己的域名和空间，将简历发布到自己的空间，或者关联到自己的域名，设置更加精美的模板，以便和自己原有的个人网站融为一体。
发展这个市场所面对的问题是，假如多遍填写简历已经够麻烦，为什么还要多维护一份简历，这份可是要保持更新的哦。这就是背后microformat所需要去推动的事情，我希望以后那些专门做网投的网站支持这种microformat，如果你有一份在线简历了就可以直接输入其地址，网投网站能够自动抓取你的简历页面并且完成信息提取工作，之后你就仅需要填写一些与当前申请工作有关的特性信息就行了。
令我感到吃惊的事情是，最近一次查阅microformats.org的时候发现已经存在一种基于hCard的hResume格式了，虽然仍然在草案状态，支持的简历栏目也仅包括最基本的，然而却已经得到广泛的应用。已经有一些人在自己的在线简历上使用了hResume，也有专门生成hResume代码的工具，甚至连WordPress插件也已经有了。那么看来高端用户要采用hResume已经很容易了，只要他现在使用的是WordPress，马上就可以通过该插件在自己的个人网站上添加简历。
虽然我前面所说的潜在市场或许已经有充足的供应了，新竞争者要进入市场必须有相当的吸引力，然而我还是觉得能有microformat支持是一件很好的事情。microformat的最大好处是无需丢弃任何已经写好的HTML代码，需要的仅仅是添加新的附加信息上去而已，只要你觉得一种信息有对应的良好组织方式，你就可以提出一种microformat去描述它，以便更多的浏览器、搜索引擎更好的理解这类信息。
我以前一直不喜欢Macromedia的产品，因为觉得它们用起来都太像堆砌积木了。堆砌积木不正是编程的理想模式吗？低耦合度的话就是，然而Macromedia自动生成的代码却不是。
就拿DreamWeaver来说，如果一个页面的源代码一看就发现全是MM开头的JavaScript函数，那么我就不会看下去。使用DreamWeaver生成JavaScript是不对的，至少我认为是不对的。《程序员修炼之道》里面说明了你不应该用一个生成代码的向导，假如你无法理解它生成的代码是干什么的话。而用DreamWeaver的人很多都在干着事情，感谢51js之类的网站，以及非常丰富的DreamWeaver脚本生成扩展，中国有大量的站长在使用那些他自己完全不知道在干什么的JavaScript。
然而堆砌积木也有好处的，特别是对于非专业人员。例如我不是专业的平面设计人员，我无法驾驭Illustrator这样的东西，这时候简单堆砌图形的Fireworks就非常适合我了。我主要使用Fireworks来设计页面的mockup，设计好就slice几下把必要的图片输出，接着就可以在Expression Web Design里面写XHTML+CSS了。Fireworks将矩形、圆形等常用的简单构图元素突出出来，而页面设计需要的正是大量基于矩形的元素，因此使用Fireworks设计mockup的效率真的很高。
人生总有突然为某些事情顿悟的若干次，我不知道这次算不算，但我发现自己更加spiritual了。
关于如何确定人生目标的方法看过一些，不过我觉得没必要试，反正我是一个很清楚自己想要什么的人，不过现在发现那些我很清楚的人生目标都是比较material或者低层次的spiritual的。李开复的那本《做最好的自己》中提到确定人生目标的时候，提到了假如你剩余若干时间的生命的时候会做什么，以及你死了之后别人的评价会是如何。对于前一个问题，我还算清楚，其实我不觉得有什么很急迫的事情必须完成的，所以我会放松地去完成我觉得可以完成的事情，就算完成不了也没什么所谓。至于后面那个问题，在高中的时候我对它的想法是比较material而且tragedy的。
我之前认为，即使我拥有一家庞大的国际化企业，有一个健康的家庭，我死掉之后事情将被很sophisticated地处理掉——幻想一下我有个office，而且至少是在中信那样能称之为tower的建筑物的顶层，然后有一天我就从那个office跳下去了，这一跳纯粹是“好奇心能够杀死一只猫”的结果，也就是我想知道之后会发生什么事，假如我还有能力知道的话。在大型城市中，救护人员会快速赶到现场，我的意思是帮忙确定我的死亡，好让那些记者回去有东西可写。然而在记者把文章发表出来之前，董事会的各位已经在思考自己的下一步棋怎么走了，因为接下来可能有不少的因素会显著影响股价，持住一大堆股票的人当然要先想清楚自己该买还是该卖，然后选择正确的对外立场。与此同时，企业良好的管理机制开始运作，适当的人选自然会被放到适当的位置，用来弥补缺少我的作用力以后所造成的影响，生态环境过一段时间自然能够重新平衡。至于家庭，他们——也就是妻子和孩子——是否好像企业一样找个人来替补我的空缺就是他们的事情了，反正我也没有发言权，然而只要他们有相当的股票在手，并且上面的事情能够按照预期的平稳处理掉，那么他们的生活也能平稳过渡。总之，这些如此sophisticated的事情总有人能负责的，无论我是否希望有人负责。
反正呢，material的东西你是无法带走的，而这个社会现在已经能够非常高效地把你遗留下来的东西瓜分干净，之后也或许就不会有人想要去悼念你。因为说到material了，如果你真的有相当多的股票，即使你的所有器官都捐赠出来，和这些股票的价值相比也就是冰山一角，除非你能在股票上印上你的头像吧，否则这个注重效益最大化的社会真的没什么必要去惦记你。因此，你留下的material价值越多，你的身体或者是贴身物品的价值比例就越低，别人就越没有理由去想着这仅占一点点比例的价值，这就是所谓的tragedy了。
现在，我突然间感觉到spiritual的重要性了，因为这才是你真正能够带走的东西。你死掉后别人没办法从你的大脑里把你的思想挖出来瓜分掉，至少暂时没办法吧，那么人们就会真心地感觉到他们失去了你。如果你的spiritual有相当的价值，例如你是画家或者诗人之类的，那么这个社会就会感觉到它真的失去了巨大的财富了。因此，在考虑人生目标的时候，spiritual是一个很重要的衡量角度，忽视了这个角度就可能导致不那么理想的结局，我的意思是假如你在乎别人对你的评价，又或者你死掉以后还有能力去评价结局是否理想的话。
另外最近看到一篇名为Life After Death的文章，如果你之前有看过我那篇《小睡 / Polyphasic Sleep》的帖子，或者你有关注过“小睡”的概念，就肯定知道其作者Steve Pavlina。这家伙的文章貌似挺注重与生活质量的方面，例如之前介绍过小睡，最近又在写如何能做到早起床；同时也有关注精神领域的题材，例如如何发现你的人生目标。我们把话题回归Life After Death这篇文章上，它的中文翻译版本名为《死后的生活》，主要讲你死掉后可能的精神状态。对于死后的生活来说，最不幸的，或者对某些人来说是最幸运的，也就是你的精神和肉体一起byebye了，那么你也就没办法为死亡做什么准备了，好好享受现有的生活吧；另外一种情况就是你的精神仍然存在，或许被冻结了，或许能继续发展，无论是哪种情况，假如你在死掉之前积累了充分的spiritual，那都肯定是好事情。
因此，我开始感觉到积累自己spiritual方面的感悟是生活中总要的一部分，必须投放相当的时间与精力去修炼，以便将来无论发生什么事情都至少能spiritual的生存下去。最坏的情况下，不是直接死亡，而是被关进纳粹集中营那样肉体上名存实亡，有相当的spiritual生存能力或许还能让你的肉体坚持下去。
我尝试在自己的软件工程项目中使用DDC，希望它能带来一些比较敏捷的特性，虽然在那么正统的软件工程课程上搞敏捷貌似有些不妥，不过其实也没有几个小组是完全按照流程来做的，反正最终所有文档齐全了演示也能让老师觉得效果不错那就行了。事实上很多小组都是随便分析一下就开始写代码，东西做出来了再补文档，哈哈……
新建了一个ASP.NET Futures的网站后，我先尝试使用DynamicDataAuto控件，发现确实如demo显示的那样“功能齐全”——所有字段都能在GridView中列出来，支持图片的直接显示，也支持外键的直接链接，一个页面上集成了所有的CRUD操作。然后我开始想细致定义这个页面，发现这个scaffold不能好像RoR的scaffold那样自动分解为低级代码，于是就尝试手工转换。首先把DyanamicDataAuto删掉，按照我的需要换上特定的Dynamic Data Control，然后发现可定制性不强，继续换……最终，页面上的控件降级到GridView了，Dynamic Data Page的特性完全没有用上，于是干脆换回普通的Page。
实际上现在的Dynamic Data Control一点都不好用，就如同ASP.NET AJAX的拖放支持一样——现成做好的控件限制太多，自定义需要实现的也太多，难以快速开发一个支持拖放特性的自定义控件。如果要使用Dynamic Data Page，那意味着Page本身为你提供了统一的Data Source，所以Page上面的Dynamic Data Control就不用设置Data Source了，然而这个特性并不能为传统Data Control所用，这就意味着一个Page上要么只用Dynamic Data Control要么只用传统Data Control。然而Dynamic Data Control的定制性实在有限，所以面对上述binary choice只能选择传统Data Control了。
暂时来说，我们也不能用Dynamic Data Control做些什么，只能等下一个版本的ASP.NET Futures看看是否有什么改善。现在的Dynamic Data Control就如同Atlas的第一个CTP那样（那时候还有<atlas:TextBox />这玩意儿），或许到最后整个模式都改掉了。
我们都知道XHTML里面的img标记应该这样写：<img alt="" src="" />，这种写法也就是所谓的自关闭，在XML中是完全合法的写法。如果你熟悉XML相关的开发，可能也就习惯于这种写法，想着XML中任何不含子节点的元素都可以这样写，那么XHTML中没有内容的标签也都可以这样写。XHTML中理论上当然允许任何标签以自关闭的方法来书写，然而浏览器兼容性却带来了新问题，那就是IE无法正确识别某些标签的自关闭写法。
请尝试输入以下XHTML代码并在IE中浏览：<p>hello <script type="text/javascript" /> world</p>，你会发现只能看到前面的hello而不见后面的world，这事情让人挺无法解释的吧。可能有不少人都曾经遇到过这个问题，并且花了几个小时在上面都找不到合理的解释。
解释源自另外一段类似的代码：<p>hello <textarea /> world</p>，你在IE中看看其显示效果，能够得到合理的解释了吗？我们能够看到前面的hello正常显示了，而后面的world则显示在textarea里面，这证明IE并没有正确识别textarea标签已经自关闭了，而是当它没有关闭，并将后面的内容识别为textarea内部的内容。
这时候我们就明白前面那段代码为什么看不到后面的world了，因为它被当作script的一部分来识别了。这就说明了，在我们使用XHTML时并不能好像XML那样随意的使用自关闭的写法，只有少数原本不需要关闭的标签可以用自关闭的写法，其他标签即使没有任何内容最好也用成对的关闭写法。
最后需要提醒大家的是，其实弱智的parser不仅仅IE有，很多地方都可能碰到由于parser不严谨而引起的问题，所以我们在书写XHTML的时候还是要迁就一些老HTML继承下来的习惯，不能好像真的XML那样自以为符合标准了就随意写。不信？那么再试一个吧：<p>hello <br></br> world</p>，留意IE与Opera中的显示效果。
Update: 有部分读者认为我举的例子是不符合XHTML规范的，那么请先阅读XHTML规范。Empty Elements一节的中文翻译如下：“空元素必须要么有一个结束标记，要么以/>结束，例如<br/>或<hr></hr>。请参考HTML兼容性标准以获取关于确保向后兼容HTML4浏览器的信息。”可以看得到，规范中也给出了<hr></hr>这样的例子，说明<br></br>的写法是符合XHTML规范的，只是没有兼容HTML4标准。那么到底XHTML是否兼容HTML4呢？我们来看Compatibility Issues一节，中文翻译如下：“虽然并没有要求XHTML1.0文档兼容现有的浏览器，但在实践中这并不难做到。”因此，XHTML是没有规定文档必须向下兼容，我给出的例子都是合法的XHTML文档片断，当出现在完整的XHTML里面时也全部能通过W3C Markup Validation Service的验证。
Update again: 其实我写这篇文章的目的不是为了强调只符合XHTML规范就行了，也不是强调符合XHTML同时兼容HTML4就够了，而是应该考虑更多需要兼容的情况。例如你的CMS中允许用户提交HTML，提交的HTML经过SgmlReader或者其他方法格式化为XHTML，同时或许还做了其它XML处理，这时候就有可能将用户提交的<textarea></textarea>转换为<textarea />，这种情况下你需要通过跟踪调试找出问题并不容易，因为XML处理并没有违反任何规范，每一步的处理都是符合语义的。另外最好不要把<br />写成<br/>，因为确实有些弱智的parser仅仅因为少了一个空格就无法正确识别。
貌似ASP.NET 2.0新增的诊断相关服务没多少人关注，更没多少人用，不过对于正在使用此类服务分析站点的人来说，肯定非常期望ASP.NET AJAX中的客户端代码错误也能记录到诊断日志中，这样就能获取更丰富的数据来分析站点不稳定因素的来源。
ASP.NET Futures中已经引入了客户端诊断服务，在解释此服务之前不妨先思考一下假如你要自己写一个客户端诊断服务会怎么做。如果我来写一个客户端诊断服务，我会设计一个Web Service负责收集错误信息，然后记录到数据库中，然后写一个js负责拦截客户端异常并且发送到该Web Service。ASP.NET Futures (May CTP)中引入的客户端诊断服务也差不多就这样子，只不过设计得更加通用更具扩展性。
使用客户端诊断时你首先要在页面上放置一个Diagnostics控件，它负责的就是向客户段输出一段js以便拦截客户端异常。熟悉ASP.NET AJAX控件设计的人应该能猜到Diagnostics控件肯定是一个ScriptControl，不熟悉ASP.NET AJAX控件设计的话也可以通过这个例子了解到，如果你有一个客户端组件要以控件方式在Page上部署那就应该考虑继承自IScriptControl接口了。
接下来我们要部署接收诊断信息的web service了。新建一个名为DiagnosticsService.asmx的web service，更改其code-behind声明如下：
<%@ WebService Language="C#" Class="Microsoft.Web.Preview.Diagnostics.DiagnosticsService,Microsoft.Web.Preview" %>
这样做的意思是，此web service不是使用你写的code-behind代码，它的code-behind类直接使用上述的DiagnosticsService类，所需的函数都在里面了，你不需要再写任何代码。那么我们到底在哪写代码记录客户段发送来的诊断信息？先别急，接下来我会解释此事。需要说明的是，ASP.NET Futures现在这个做法的风格和原来的ASP.NET AJAX有点格格不入，因为它没有直接采用HttpHandler的方式直接暴露此web service，而必须要开发者自己部属一个asmx文件，将来此做法可能改变，届时将不再需要手动部署asmx文件。
仔细留意DiagnosticsService，你会发现它有一个OnClientException的事件，这才是你真正需要关注的地方。为了确保将所有客户端异常都记录下来，你可以在Global.asax的Application_Start中绑定此事件，在HttpModule中绑定也是可以的。在事件的处理函数中，你将通过EventArgs获取到一个ExceptionServerInfo的类型，在里面将会记录如下一些与客户端异常有关的属性：
你可以直接访问这些属性，以你喜欢的方式进行日志记录，例如记录到你自己的数据库，或者是ASP.NET 2.0的health monitor。
好了，这样就解释完如何使用客户端诊断服务了。嗯……等等……还要一样重要的事情没有说，那就是在web.config中启用此项服务。首先要声明config section：
<configSections>
<sectionGroup name="microsoft.web.preview" type="Microsoft.Web.Preview.Configuration.PreviewSectionGroup, Microsoft.Web.Preview">
<section name="diagnostics" type="Microsoft.Web.Preview.Configuration.DiagnosticsSection, Microsoft.Web.Preview"/>
</sectionGroup>
</configSections>
然后声明启用此服务：
<microsoft.web.preview>
<diagnostics enabled="true"/>
</microsoft.web.preview>
最后，如果你有兴趣继续关注有关ASP.NET Futures新功能的介绍，可以考虑订阅我的博客：
以前一直因为没有Windows平台上的Safari，所以设计CSS Template的时候就没办法测试对Safari的兼容性，或者只能使用browsershots.org这样的服务来查看CSS Template在Safari中的视觉效果。现在Apple最新发布的Safari 3 Public Beta已经有Windows版本了，那就能很方便的测试CSS Template的兼容性了。
Safari的Windows版本有一个重要的战略意义，那就是让你可以测试你的应用是否能在iPhone上面跑起来，包括AJAX应用。由于iPhone暂时还不会有任何第三方软件，所以它上面能够有什么第三方服务就依赖于Web了，而Safari对AJAX的支持则成为了亮点。如果你是服务提供商，并且希望你的应用将来能被iPhone用户所使用，那么使用PC上的Safari将能让你提早进入网站兼容性测试的环节。
在本系列的上一篇文章中，我们探索了ASP.NET Futures (May CTP)的SearchSiteMap功能，说明了如何将ASP.NET的SiteMap影射为符合Sitemaps协议的XML以便搜索引擎更好的抓取我们的站点。然而让搜索引擎更好的抓取我们的站点了，这部分的优化却仅仅对来自于搜索引擎的访客有用，这是否有点浪费？我们是否可以选择站内的搜索也通过Internet搜索引擎（例如Google）来实现，从而避免开发自己的站内搜索引擎？从ASP.NET Futures (May CTP)开始，这也便得可能了，需要使用的仅仅是SearchDataSource控件以及简单的几句配置。
首先说说SearchDataSource是干什么的吧，它其实是一个ObjectDataSource的派生类，只不过设置了基类的TypeName为"Microsoft.Web.Preview.Search.SearchService"，而SelectMethod则是"Search"。事实上你放置一个普通的ObjectDataSource然后设置这两个属性也就可以获得SearchDataSource的效果。之后你就可以像使用普通DataSource控件那样使用搜索返回的数据，绑定到Repeater或者GridView，又或者绑定到你自己的数据控件都是可以的。
SearchDataSource返回的貌似是一个IEnumerable，而事实上是一个List<SearchResult>，通过Reflector阅读SearchService.Search方法的代码就知道了。然后我们来看看SearchResult类型包含什么属性。它拥有3个string属性，分别是：Url、Title、Description。在使用SearchDataSource的时候，数据控件绑定这3个属性就够了。那么之后我们还需要做什么呢？接下来就是配置provider了，因为SearchService.Search方法正是通过轮询各SearchProviderBase派生类来获取搜索结果的。
这听上去很复杂的样子哦，远超过了放置一个SearchDataSource的难度。其实不是的，ASP.NET Futures (May CTP)中已经包含一个SearchProviderBase派生类了，那就是WindowsLiveSearchProvider。此provider的配置方法如下：
<microsoft.web.preview>
<search enabled="true">
<providers>
<add name="WindowsLiveSearchProvider"
type="Microsoft.Web.Preview.Search.WindowsLiveSearchProvider, Microsoft.Web.Preview"
appID=""
siteDomainName="" />
</providers>
</search>
</microsoft.web.preview>
其中的appID是你在Windows Live Search申请的Application ID，还没有Application ID的话可以到Windows Live Search的Developer站点申请一个。siteDomainName就是你的网站的域名，例如我的网站就是CatChen.biz。另外，你还要确认Windows Live Search已经抓取了你的网站的页面，通过大部分搜索引擎都支持的site:指令你就可以知道一个搜索引擎对你的网站的抓取情况，例如我可以通过site:CatChen.biz搜索来了解Windows Live Search对我的网站的抓取情况。完整配置并且确保搜索引擎对你的站点的抓取后，你就可以通过SearchDataSource获得期望的搜索结果了。
如果你不满足于WindowsLiveSearchProvider提供的功能，你可以实现自己的SearchProviderBase派生类。在官方文档中Enabling Search页上，最后一个例子提供了两个自定义的provider，一个是用于Yahoo的，另一个是用于Index Server的。另外不要把目光局限于某个特定的搜索引擎，如果你觉得Google、Yahoo、Windows Live都不够好，那么你可以考虑做一个自己的meta-search（源搜索）引擎。所谓的meta-search是指通过调用若干个不同的搜索引擎，根据它们的返回结果再次进行信息的分析与提取，最后生成自己的搜索结果。
在你实现了自己的SearchProviderBase派生类后，有一点需要注意的，那就是SearchService是不知道返回结果的排名的。一般我们都会认为搜索结果越靠前的，当然应该是越匹配的，这在配置一个provider时是没什么问题的。然而配置多个provider后，SearchService仅仅是将多个provider的结果拼接成一个更大的List<SearchResult>，这时候就毫无排序而言了。因此，如果你需要使用多个provider，我还是建议直接写一个SearchProviderBase派生类，使用meta-search的方式自己去合并以及重排结果。
最后，如果你有兴趣继续关注有关ASP.NET Futures新功能的介绍，可以考虑订阅我的博客：
其实很早的时候我就意识到可能使用中文思考相对于使用英文思考来说，对思考者某些特定领域的思维能力会带来一定的正面或负面影响，不过我不很确定有什么例子能论证这个话题，也不知道哪个领域的思维能力造成的影响可能是最明显的，所以也就没有继续想它。
上个星期新东方有个老师说，使用英语思考能够让人的逻辑思维能力更加严谨，因为没有哪一个在中国的华人能够拿到诺贝尔奖，然而华人在美国改用英语思考就能拿到诺贝尔奖了。或者这根本不是一个有价值的例证，反正新东方老师上课吹水是必须的，然而这却让我重新感到问题本身确实值得思考。
首先我们来看看程序设计语言而不是自然语言之间的区别。我最近阅读到一篇文章讨论了程序设计语言与解决方案之间的关系：On Semantic Distance and Computer Languages。文章中认为，使用的程序设计语言的语义和解决方案的距离越近，实现起来就越容易，因为所谓的实现就是搭桥跨越程序设计语言以及描述解决方案的语言。然而文章最后说道，世界上有5000种语言（包括方言），你是不可能找到一个等价语义集合的，因此也就不存在一种语言总是最贴近任何一个解决方案，那意味着也不可能存在所谓的最好的程序设计语言。
可能这样说比较空泛，那么我们通过一些实际的例子来说明计算机语言与描述解决方案的语言之前的距离为何可以相去甚远，当然后者暂时指代的就是英语为主的描述性语言。假如你需要取一个值，它代表当前时间的20分钟前的时间，用Java写的话代码如下：
new Date(new Date().getTime() - 20 * 60 * 1000)
然而用Ruby写的话代码如下：
20.minutes.ago
上述例子来自Sometimes less is more，阅读该篇文章你可以看到更多这种Java和Ruby的比较。在此我无心说Java与Ruby之间哪个更好，我只是想找一个例子证明不同语言与解决方案语言间的距离是可以有很大差别的。
解释完程序设计语言有关的事情，那么我们可否直接拿上例来推导，并由此得出一个类似的结论，那就是不存在一种自然语言总是最贴近任何一种思维模式。正如如果你想写一段代码获取代表20分钟前的时间值有两种思维方式以分别适应Java与Ruby一样，中文与英文也有描述一件事情的两种不同思维方式，而随着你使用特定一种语言的时间积累，这种方式将反过来对你的某些领域的思维能力造成影响。
然而到底中文与英文训练人的思维能力的结果如何呢？我也不敢乱下什么结论，但从表象上看来，貌似英文适合逻辑推理而中文适合艺术创作。然而到底事实是如何的，我们可否遮盖其他文化因素的影响单纯探讨使用一种特定语言对人的思维能力的影响，这就是我能力范围之外的事情了，应该由社会学家以及语言学家来解决。
继续发展《还有新鲜感吗？》那次的话题……最近真的在考虑MacBook哦，漂亮的MacOS为什么不能成为选择呢，反正Vista也是在模仿它的。
其实在有充足的选项之前，干什么那么早选定一个固定的方向呢，提前缩窄搜索范围，这在遗传算法里面叫做“早熟”哦。这个所谓的“早熟”会导致之后都搜索都限制在这个小范围内，即使让你求得了这个小范围内最优解，在全局范围内也不一定怎么优。所以遗传算法通常要避免“早熟”，在开始的时候要确保搜索解集尽可能在全局里分散。当然，还有一些更高级的方法避免类聚，然而这部在我们的讨论范围之内。
另外一种要防止出现的情况是不收敛，或者叫做“迟熟”，假如你一定要找一个和“早熟”对应的说法的话。不收敛意味着你在一个很广泛的范围内搜索来搜索去，貌似搜索了很多的解，但是你所能得到的最优解看起来总合全局最优解有一定的距离。
不过对我现在的情况而言，应该控制好避免“早熟”，过早收敛是不好的。找mm这事情也一样，如果不想“早熟”或者“迟熟”就应该做好范围控制，不能让它过早收敛，但又要避免不收敛的情况。
Google向来声称广告在右边，明确标出，不会打扰用户看搜索结果，搜索结果放的位置才使人视觉焦点的主要位置。只有相关度本身就非常高的广告能够出现在搜索结果之上，并且也会标明为广告。
这个声明在PC上是成立的，即使把CSS给禁用掉仍然成立。CSS禁用掉不是两栏布局就变成一栏了吗？哦……别就只知道CSS布局，我们还有原始的table布局呢，Google的搜索结果页就通过使用table确保广告再右侧。
那么什么情况下广告会跑到上面了呢？在用Opera Mini的时候，因为Opera的服务器会对页面进行优化后再发送给客户端的Opera Mini进行呈现，这过程中不知道什么优化规则就让广告显示到前面了。不过先说明，这样的结果是必然的，因为在HTML中广告出现在搜索结果之前，Opera对内容按顺序进行分段并且优化时先处理广告自然先输出广告。
我觉得这种特殊情况对于Google来说是非常讽刺的，Google一直大力宣称搜索结果上层的位置你无法买到，然而在Opera Mini上显示时显然就是买的结果先出现。并且因为Opera Mini上面能显示的字体只有一种，所以“赞助商链接”这几个字就不那么明显，不留意看你就以为第一条广告是第一条结果。即使你知道那些使广告，要寻觅哪条才是第一条结果也许要费些时间仔细看。