在Google Desktop Search Enterprise的截图里面，能够看到多了一个"内部网"的搜索标签。下载来看，原来是普通的GDS加上一个组策略文件，在组策略中可以定制该标签指向一个??Google Search Appliance??哦？什么来的呢？Google一下先……
原来就是Google卖的刀片服务器，价格：$30,000起，Faint...
现在我有个小小的Intranet，不过连$2,995的Google Mini都买不起，我只是想提供个小小的Search服务。不过我继续看GDS Enterprise的Document，发现它本是也不是直接支持GSA，它需要用XSLT来把从GSA获取到的搜索结果转换为它能够识别的XML然后再使用。哦……如果是这样就舒服啦，只要有一个Intranet搜索引擎就行了，不用管它是否是GSA，关键就在于它的搜索结果能够输出为GDS支持的某一种XML格式，然后GDS就能够把搜索结果整合进去。 嗯……这样设计确实不错，继续研究下如何实现……
2005年11月11日星期五
2005年11月9日星期三
百万网站
不知道这算不算病毒广告，不过应该挺有效，起码我都参与传达了（不过地址不使用链接）：
http://www.1baiwan.com
这里是简介：
http://www.1baiwan.com/Introduction.html
其实我看到那个用象素画风格做出来的全球最高虚拟大厦的时候，就想着为什么"楼主"不考虑未来的层用来卖呢？或者整个网站卖出去，肯定也能赚不少钱。现在这个"百万网站"终于这样做了，呵呵……大家或许不明白，那还是点击上面的网站去看看如何百万法吧，其实就是首页有一百万个13px*13px的个子，每个的售价为￥100（出售的为永久使用权），网站承诺至少维持5年。
http://www.1baiwan.com
这里是简介：
http://www.1baiwan.com/Introduction.html
其实我看到那个用象素画风格做出来的全球最高虚拟大厦的时候，就想着为什么"楼主"不考虑未来的层用来卖呢？或者整个网站卖出去，肯定也能赚不少钱。现在这个"百万网站"终于这样做了，呵呵……大家或许不明白，那还是点击上面的网站去看看如何百万法吧，其实就是首页有一百万个13px*13px的个子，每个的售价为￥100（出售的为永久使用权），网站承诺至少维持5年。
2005年11月5日星期六
大家应该去看看现在通过网站提供服务这一领域的变化
最近Google vs Microsoft的事情越来越多人关注，Google不依赖于脱离网络的软件让MS在软件方面的优势完全表现不出来，而且Google也找到了它的广告形式，这足够让MS不爽的了。
不过MS现在已经逐步改变战略，开始学Google了——不需要太多创新，以足够的资金作为优势，模仿和跟进也就足够了。（顺便所以下，Tencent在国内也是这个策略，不过它模仿的是国内其他厂商如何流氓的做法，例如据说最新的QQ2005正式版就内嵌了Tencent的搜索/实名插件，这个东西会自动把系统中已经安装的其它同类插件Disable掉，并且也胆敢在Agreement上直接说因为QQ和这些插件存在冲突可能导致这些插件不能正常运行。）
MS最近就推出了称之为Windows Live的Beta服务，大家可以去Live.com看看，其中包括可以申请的Windows Live Mail Beta（Hotmail升级项）和即将开放的Windows Live Messenger Beta。最近几天的Google News科技版中都有有关的新闻，昨天说Live.com收购了提供网络硬盘服务的FolderShare.com，今天说MS当年不重视"软件既是服务"放弃收购SalesForce.com（一个在线CRM服务网站）现在才来重视此事已经太晚了。
暂时来说，我们都能看出Live.com其实是希望通过一个整合的平台应付Google众多分散式的服务。Google的服务以前总是先来Beta，可能还基于Invitation机制，过一段时间了才进行Localize，虽然后来Google Account出现后所有服务都依次为登录标准，但是通用登录和Portal之间还是有差别的，IGoogle虽然在推进此事（最近有了中文版），不过说到做Portal方面应该还是MS有经验，就算是个性化Portal方面MS起码也有my.msn.com这个基础，所以Live.com依靠MS的资金是有可能赶上IGoogle的。
然而MS真正的竞争对手不是Google一个，我们现在这些在做小软件或者还在做网站不过是给别人拿去部署的也面对这些竞争。那就是一些直接提供服务而不是提供下载的网站。由最不像提供软件的del.icio.us和flickr，到Coo介绍我看的那个类似wiki的可以用于Collaberate的网站，再到最近发现的writely.com和numsum.com。第一个虽然是服务，不过是完全面向大众的；第二个开始转向面向个人和组织，因为你不能够下载它并在自己的站点上部署一个，所以必须用它的；第三个则已经由"此站点不能下载并部署"变成了"此软件不能下载并使用"，writely.com和numsum.com分别针对文字处理工具和表格处理工具，然而完全基于Web确保证了不可能盗版。
虽然这些网站暂时还没什么盈利之道，最多放一下Google AdSense，因为暂时他们都是处于探索性的，特别是针对零售版软件领域暂时还无法追上零售软件的功能。不过一旦这种做法找到了盈利之道，可能就真的能够大大减少零售软件。但是可能到时候可能私服也将出现，正如中国从前有人不知道正版只买盗版现在有人不知道官服只玩私服一样，零售市场收缩是否就确保了利润的收入，这个暂时还很难说。
另外，MS可能又在背后偷偷乐了，为什么？大家慢慢忙DHTML和所谓的AJAX吧，它的Avalon随后就到。Google花钱把DHTML的发明者从MS挖过去了又怎样？总的来说你还是得按照MS当初制定下来的标准做Web和玩这场游戏。即使你的Web再好，Avalon一发布可能就都成为历史??可能别人仅仅需要打开一个XAML写的页面，后台下载一个.NET DLL，那就是一个程序，点以下Install那个.NET DLL就会从Cache迁移到永久保存的目录，那个XAML页面的地址就被添加到"程序"里面，普通Web还有什么意义？可能有人说，Avalon仅仅适用于Longhorn，即使推出兼容低版本的Windows兼容软件，或者类似mono那样提供Linux上的对应开源项目，适用范围还是在PC上，而支持Web的设备则周街都是。唉……以后可能支持Web和Web Service的设备确实周街都是，你随手捡个MP3都说支持，但是它们可能支持AJAX吗？或者是基本的DHTML？现在PPC和Palm都还不能完全支持呢。所以未来不一定属于HTML，而可能属于XAML或其它后来的类似开源项目，这个是很难说的。如今PC的架构是已经确定了，它不是NC就不是NC，除非有一天主板加上了XML处理芯片或者CPU/GPU提供了对XML呈现的直接支持（这里的XML指未来的某种支持动态的基于XML的语言），否则通过一种标准的网络形式售卖服务即售卖软件的日子还很远呢。
不过MS现在已经逐步改变战略，开始学Google了——不需要太多创新，以足够的资金作为优势，模仿和跟进也就足够了。（顺便所以下，Tencent在国内也是这个策略，不过它模仿的是国内其他厂商如何流氓的做法，例如据说最新的QQ2005正式版就内嵌了Tencent的搜索/实名插件，这个东西会自动把系统中已经安装的其它同类插件Disable掉，并且也胆敢在Agreement上直接说因为QQ和这些插件存在冲突可能导致这些插件不能正常运行。）
MS最近就推出了称之为Windows Live的Beta服务，大家可以去Live.com看看，其中包括可以申请的Windows Live Mail Beta（Hotmail升级项）和即将开放的Windows Live Messenger Beta。最近几天的Google News科技版中都有有关的新闻，昨天说Live.com收购了提供网络硬盘服务的FolderShare.com，今天说MS当年不重视"软件既是服务"放弃收购SalesForce.com（一个在线CRM服务网站）现在才来重视此事已经太晚了。
暂时来说，我们都能看出Live.com其实是希望通过一个整合的平台应付Google众多分散式的服务。Google的服务以前总是先来Beta，可能还基于Invitation机制，过一段时间了才进行Localize，虽然后来Google Account出现后所有服务都依次为登录标准，但是通用登录和Portal之间还是有差别的，IGoogle虽然在推进此事（最近有了中文版），不过说到做Portal方面应该还是MS有经验，就算是个性化Portal方面MS起码也有my.msn.com这个基础，所以Live.com依靠MS的资金是有可能赶上IGoogle的。
然而MS真正的竞争对手不是Google一个，我们现在这些在做小软件或者还在做网站不过是给别人拿去部署的也面对这些竞争。那就是一些直接提供服务而不是提供下载的网站。由最不像提供软件的del.icio.us和flickr，到Coo介绍我看的那个类似wiki的可以用于Collaberate的网站，再到最近发现的writely.com和numsum.com。第一个虽然是服务，不过是完全面向大众的；第二个开始转向面向个人和组织，因为你不能够下载它并在自己的站点上部署一个，所以必须用它的；第三个则已经由"此站点不能下载并部署"变成了"此软件不能下载并使用"，writely.com和numsum.com分别针对文字处理工具和表格处理工具，然而完全基于Web确保证了不可能盗版。
虽然这些网站暂时还没什么盈利之道，最多放一下Google AdSense，因为暂时他们都是处于探索性的，特别是针对零售版软件领域暂时还无法追上零售软件的功能。不过一旦这种做法找到了盈利之道，可能就真的能够大大减少零售软件。但是可能到时候可能私服也将出现，正如中国从前有人不知道正版只买盗版现在有人不知道官服只玩私服一样，零售市场收缩是否就确保了利润的收入，这个暂时还很难说。
另外，MS可能又在背后偷偷乐了，为什么？大家慢慢忙DHTML和所谓的AJAX吧，它的Avalon随后就到。Google花钱把DHTML的发明者从MS挖过去了又怎样？总的来说你还是得按照MS当初制定下来的标准做Web和玩这场游戏。即使你的Web再好，Avalon一发布可能就都成为历史??可能别人仅仅需要打开一个XAML写的页面，后台下载一个.NET DLL，那就是一个程序，点以下Install那个.NET DLL就会从Cache迁移到永久保存的目录，那个XAML页面的地址就被添加到"程序"里面，普通Web还有什么意义？可能有人说，Avalon仅仅适用于Longhorn，即使推出兼容低版本的Windows兼容软件，或者类似mono那样提供Linux上的对应开源项目，适用范围还是在PC上，而支持Web的设备则周街都是。唉……以后可能支持Web和Web Service的设备确实周街都是，你随手捡个MP3都说支持，但是它们可能支持AJAX吗？或者是基本的DHTML？现在PPC和Palm都还不能完全支持呢。所以未来不一定属于HTML，而可能属于XAML或其它后来的类似开源项目，这个是很难说的。如今PC的架构是已经确定了，它不是NC就不是NC，除非有一天主板加上了XML处理芯片或者CPU/GPU提供了对XML呈现的直接支持（这里的XML指未来的某种支持动态的基于XML的语言），否则通过一种标准的网络形式售卖服务即售卖软件的日子还很远呢。
TextGem v2 - 基于类似Sharepoint技术的CMS
TextGem在开发的时候，本来仅仅考虑用来做wiki。wiki做完了，我就开始考虑把它用于blog和forum??因为大家的ContentData格式都是一致的，不过UI不同，于是TextGem Pro出现。TextGemPro中应用了很多新奇好玩的构思，例如实现了HTML编辑器，添加了支持RollBack的Config，支持Key的映射……虽然都是没什么用的东西，而且把TextGemPro变成四不像，不过挺好玩。可惜它现在实在是太过四不像啦，所以我就算要把它重新做成单一目标的产品，也不知道"单一目标"定为什么好。
然后，最近遇到了一些问题，就是我见到好像TLF或者一些其他论坛，通过规定一些发帖规范把某些板块的帖子格式限制到符合一个标准，然后就可以自己写一些小软件来分析数据库，按照帖子格式来进行数据分析，作统计工作量等的一些工作。我在想，其实很多论坛，它有特色就在仅仅在于它的数据表多了一两个字段和多了一些相关的数据逻辑，仅此而已，我希望提供一种论坛能够轻松的自定义增加的数据字段和自定义逻辑。
开头的时候，我在做有关ASP.NET的事情，所以我的设计思路是很OO的，也是完全面对开发者的。那时候考虑的是，例如好像CSDN那样的记分系统，完全就是可以当作一个插件来看。首先要严格定义一个IBoardExtension的接口，类似ASP.NET有一个OnInit->OnLoad->OnPrerender->OnRender这样的一个过程，IBoardExtension应该支持一系列的事件，例如OnPreinstall和OnInstaller将在论坛发现新的IBoardExtension时调用而让这个插件有机会去检查是否已存在低版本需要删除、是否需要建立/升级此插件需要的数据表；然后OnThreadListPageRender、OnThreadPageRender等事件则在呈现对应页面时发生，插件此时就有机会去读取Threads、Posts等有关对象然后在Page上做有关的改动；OnNewThreadPageRender将在呈现"发新贴"页面调用，如果插件需要用户填写"点数"这项属性可以在此时操作Page，而OnNewThreadPagePostBack则是用户提交了"发新贴"页面，此时Extension要检查数据是否合法，以及是否对数据库做什么读写操作等。
现在发觉，当时的想法把页面限死了，因为所有IBoardExtension有关的事件，都是和某一个页面某一个事件绑死在一起的，如果仅仅是考虑论坛和插件的功能，那已经相当足够，因为一个论坛的页面大概也就那么多，无非是主题列表、主题里面的贴子/回复列表、发新主题、发新贴等等，UI的大体是固定的，仅仅是Extension在这上面能够对Render和PostBack做一定的操作。但是如果要支持wiki和blog这些和forum拥有类似数据表结构的东西就不行了，这需要一个更加flexible的设计。
这个更加flexible的设计，就是学习Sharepoint引入WebPart的概念??一个WebPart自身就包括显示部分与逻辑部分。实际上，我非常认同一个拥有良好flexibility的东西，必须遵守MVC分离的设计，至于它是否使用某个设计模式那倒不重要。应用MVC分离，这意味着每一个WebPart本身都要拥有MVC三者，而且这三者之间要松耦合然后他们都去和系统自身的MVC耦合。也就是说，IBoardExtension那样完全不区分MVC的提供一队事件是不行的，必须提供一种更加好的方式，让Extension继承/支持某个东西，然后就可以分别对MVC三个部分扩展编程。
详细的TextGem v2设计还在思考中，不过这并没有脱离原来的TextGem.NET开发三部曲路线??首先制作核心，然后制作应用，最后提供用于制作应用的开发工具。TextGemv2首先要做的核心，它不会像制作一般论坛那样，受到表情符号、用户头像等一系列琐碎麻烦问题的困扰，因为这一切都属于应用而不属于核心，但核心的设计就是要兼容这一切将来可能要添加的应用，所以需要花比较长的时间去做设计。
然后，最近遇到了一些问题，就是我见到好像TLF或者一些其他论坛，通过规定一些发帖规范把某些板块的帖子格式限制到符合一个标准，然后就可以自己写一些小软件来分析数据库，按照帖子格式来进行数据分析，作统计工作量等的一些工作。我在想，其实很多论坛，它有特色就在仅仅在于它的数据表多了一两个字段和多了一些相关的数据逻辑，仅此而已，我希望提供一种论坛能够轻松的自定义增加的数据字段和自定义逻辑。
开头的时候，我在做有关ASP.NET的事情，所以我的设计思路是很OO的，也是完全面对开发者的。那时候考虑的是，例如好像CSDN那样的记分系统，完全就是可以当作一个插件来看。首先要严格定义一个IBoardExtension的接口，类似ASP.NET有一个OnInit->OnLoad->OnPrerender->OnRender这样的一个过程，IBoardExtension应该支持一系列的事件，例如OnPreinstall和OnInstaller将在论坛发现新的IBoardExtension时调用而让这个插件有机会去检查是否已存在低版本需要删除、是否需要建立/升级此插件需要的数据表；然后OnThreadListPageRender、OnThreadPageRender等事件则在呈现对应页面时发生，插件此时就有机会去读取Threads、Posts等有关对象然后在Page上做有关的改动；OnNewThreadPageRender将在呈现"发新贴"页面调用，如果插件需要用户填写"点数"这项属性可以在此时操作Page，而OnNewThreadPagePostBack则是用户提交了"发新贴"页面，此时Extension要检查数据是否合法，以及是否对数据库做什么读写操作等。
现在发觉，当时的想法把页面限死了，因为所有IBoardExtension有关的事件，都是和某一个页面某一个事件绑死在一起的，如果仅仅是考虑论坛和插件的功能，那已经相当足够，因为一个论坛的页面大概也就那么多，无非是主题列表、主题里面的贴子/回复列表、发新主题、发新贴等等，UI的大体是固定的，仅仅是Extension在这上面能够对Render和PostBack做一定的操作。但是如果要支持wiki和blog这些和forum拥有类似数据表结构的东西就不行了，这需要一个更加flexible的设计。
这个更加flexible的设计，就是学习Sharepoint引入WebPart的概念??一个WebPart自身就包括显示部分与逻辑部分。实际上，我非常认同一个拥有良好flexibility的东西，必须遵守MVC分离的设计，至于它是否使用某个设计模式那倒不重要。应用MVC分离，这意味着每一个WebPart本身都要拥有MVC三者，而且这三者之间要松耦合然后他们都去和系统自身的MVC耦合。也就是说，IBoardExtension那样完全不区分MVC的提供一队事件是不行的，必须提供一种更加好的方式，让Extension继承/支持某个东西，然后就可以分别对MVC三个部分扩展编程。
详细的TextGem v2设计还在思考中，不过这并没有脱离原来的TextGem.NET开发三部曲路线??首先制作核心，然后制作应用，最后提供用于制作应用的开发工具。TextGemv2首先要做的核心，它不会像制作一般论坛那样，受到表情符号、用户头像等一系列琐碎麻烦问题的困扰，因为这一切都属于应用而不属于核心，但核心的设计就是要兼容这一切将来可能要添加的应用，所以需要花比较长的时间去做设计。
2005年10月30日星期日
基于发送者的贝叶斯~
现在在这个荒岛上，好像大家很习惯一种发布Announcement和Ads的方法，就是群传群??通常一个人参加了近十个Q群甚至近二十个Q群，如果他在一个群看到一个Announcement或者Ads，并且他觉得这个Announcement应该转告给其他人或者他觉得这个Ads的发起人值得他帮忙，那么他就会把信息贴到其他所有群。这种方法不能说"有效"，因为你永远不知道信息传到多远了，有多少人接受了，但是他在信息流的控制方面看起来也有一定的根据??你觉得值得你转发的东西你就转发吧，而这又影响着你的信誉度，因为如果你转发垃圾太多别人就干脆把这个群屏蔽掉了。
现在我想干脆就做一个基于这个原理和SNS的通讯系统，只支持近邻的发送而不支持DirectMail。其实我很早就觉得Orkut应该禁止DirectMessage，因为我收到的Spam实在太多了，过了一段时间才得到改善。后来看到Linkist有这项功能（你可以设置不接收DirectMessage仅接受来自好友后通过好友传递的Message），觉得这样东西确实值得做。
好了，到说主题了，我想做的这个东西就是基于发送者和传递者的贝叶斯信息过滤系统，允许发送的信息有两种??点对点和广播，这样设计有点类似TCP和UDP。无论是哪一种，信息都只能通过好友传好友，虽然这个过程是全自动的，但是你也可以要求启动过滤。全自动的意思是，如果你的两个好友是陌生人，他们通过你传递信息，你就好像网关一样，你可以选择不阅读这些信息就让他们自动转发；而允许过滤的意思是，作为网关，你其实也有权查看流经你的信息，即使加密了你还是可以大概看出信息类型（或者你干脆不允许加密信息经过），你有权自动（基于规则或基于贝叶斯）或手动的过滤掉一些信息。
情景1：A知道陈扬星期天来东校区做讲座，于是希望身边的好友都知道，于是他用广播模式发送了这条信息。B是A的直接好友，接受到了这条信息，觉得确实应该让大家都知道这条消息，于是点击了消息阅读框下面的"自动转发"按钮，于是B的好友也看到了这条消息，同时基于贝叶斯的统计，B对A发送的信息的信任度增加了。然而很不幸，B的好友C对这些活动毫无兴趣，觉得B整天发这些东西给他很烦，于是他点击了消息对话框下面的"垃圾"按钮，这个按钮拥有"关闭"按钮更多的更能??C对B的信任度下降了，同时C把这条消息的MessageID自动转发给他的好友并告知为Spam，这个Spam提示对于越是信任C的好友效果越明显甚至还会自动转发给下一级好友。
过了一段时间，这个消息又传回到B那里了，不过由于MessageID相同，B的客户端没有提示有新消息更加不会自动转发此条消息，而仅仅是在这则消息上面增加了Hit的数值。
情景2：K下载了这个软件，想用来群发广告——通过P2P的方式发送广告确实是个不错的主意。K加了一些好友，然后开始发送广告，开头他的这些好友还是愿意帮他转发的，不过很快发现他们的好友开始不怎么理睬他们（因为Spam多信任度降低更多的信息被过滤），他们也不再愿意帮K转发广告了，主动把K发过来的广告当作Spam来统计，结果K变成了信息孤岛，他说的话不再有人信了。（这里是基于大家都只加现实中认识的人这一原则。如果是网友的话，先通过中间人的自动转发功能联系一段时间，然后再加为好友。）
主动发送或者转发广告的人都是不受欢迎的，而且这个不需要大家开口来声讨，我们的系统知道如何去处理。
情景3：Z最近认识了好友Y的好友X。可惜Y经常不上线，他们要经过Y进行消息转发的这条Route的Ping值太高了。幸好Z和X之间还有另外一条Route，虽然中间隔着的人比较多，但是Ping值低，他们两个觉得发送的信息又不是什么大秘密，于是选择了走这条虽然可能有几个比较陌生的人，但是Ping值低的Route，很快他们就都主动把对方加为自己的好友了，于是就能够直接通信了。
现在我想干脆就做一个基于这个原理和SNS的通讯系统，只支持近邻的发送而不支持DirectMail。其实我很早就觉得Orkut应该禁止DirectMessage，因为我收到的Spam实在太多了，过了一段时间才得到改善。后来看到Linkist有这项功能（你可以设置不接收DirectMessage仅接受来自好友后通过好友传递的Message），觉得这样东西确实值得做。
好了，到说主题了，我想做的这个东西就是基于发送者和传递者的贝叶斯信息过滤系统，允许发送的信息有两种??点对点和广播，这样设计有点类似TCP和UDP。无论是哪一种，信息都只能通过好友传好友，虽然这个过程是全自动的，但是你也可以要求启动过滤。全自动的意思是，如果你的两个好友是陌生人，他们通过你传递信息，你就好像网关一样，你可以选择不阅读这些信息就让他们自动转发；而允许过滤的意思是，作为网关，你其实也有权查看流经你的信息，即使加密了你还是可以大概看出信息类型（或者你干脆不允许加密信息经过），你有权自动（基于规则或基于贝叶斯）或手动的过滤掉一些信息。
情景1：A知道陈扬星期天来东校区做讲座，于是希望身边的好友都知道，于是他用广播模式发送了这条信息。B是A的直接好友，接受到了这条信息，觉得确实应该让大家都知道这条消息，于是点击了消息阅读框下面的"自动转发"按钮，于是B的好友也看到了这条消息，同时基于贝叶斯的统计，B对A发送的信息的信任度增加了。然而很不幸，B的好友C对这些活动毫无兴趣，觉得B整天发这些东西给他很烦，于是他点击了消息对话框下面的"垃圾"按钮，这个按钮拥有"关闭"按钮更多的更能??C对B的信任度下降了，同时C把这条消息的MessageID自动转发给他的好友并告知为Spam，这个Spam提示对于越是信任C的好友效果越明显甚至还会自动转发给下一级好友。
过了一段时间，这个消息又传回到B那里了，不过由于MessageID相同，B的客户端没有提示有新消息更加不会自动转发此条消息，而仅仅是在这则消息上面增加了Hit的数值。
情景2：K下载了这个软件，想用来群发广告——通过P2P的方式发送广告确实是个不错的主意。K加了一些好友，然后开始发送广告，开头他的这些好友还是愿意帮他转发的，不过很快发现他们的好友开始不怎么理睬他们（因为Spam多信任度降低更多的信息被过滤），他们也不再愿意帮K转发广告了，主动把K发过来的广告当作Spam来统计，结果K变成了信息孤岛，他说的话不再有人信了。（这里是基于大家都只加现实中认识的人这一原则。如果是网友的话，先通过中间人的自动转发功能联系一段时间，然后再加为好友。）
主动发送或者转发广告的人都是不受欢迎的，而且这个不需要大家开口来声讨，我们的系统知道如何去处理。
情景3：Z最近认识了好友Y的好友X。可惜Y经常不上线，他们要经过Y进行消息转发的这条Route的Ping值太高了。幸好Z和X之间还有另外一条Route，虽然中间隔着的人比较多，但是Ping值低，他们两个觉得发送的信息又不是什么大秘密，于是选择了走这条虽然可能有几个比较陌生的人，但是Ping值低的Route，很快他们就都主动把对方加为自己的好友了，于是就能够直接通信了。
2005年10月28日星期五
在做“作业提交系统”的那位来看看，你会faint死的~
Windows SharePoint Services 中文网站模板：
http://office.microsoft.com/zh-cn/assistance/HA011929182052.aspx
这个是微软的增值计划的一部分，你去看看下面那个"学校班级网站模板"，什么课件上传下载、作业提交，都有了，很faint吧。所以说，如果你有一台足够好的域服务器，给你一个Sharepoint，就算不作为WebFarm，自己做一下二次开发弄一些WebPart就很好用，剩下的就是要有一个好的ADSI程序用于账号管理。现在MS连给中国学校用的WebPart都做埋了，那么我们能够做的东西就更少了。
《Joel说软件》中说到，如果我是偏执狂，那么我会说MS肯定不会为它当前领域及纵向相关的潜在领域提供开发工具。这句话看起来也不假，呵呵……
http://office.microsoft.com/zh-cn/assistance/HA011929182052.aspx
这个是微软的增值计划的一部分，你去看看下面那个"学校班级网站模板"，什么课件上传下载、作业提交，都有了，很faint吧。所以说，如果你有一台足够好的域服务器，给你一个Sharepoint，就算不作为WebFarm，自己做一下二次开发弄一些WebPart就很好用，剩下的就是要有一个好的ADSI程序用于账号管理。现在MS连给中国学校用的WebPart都做埋了，那么我们能够做的东西就更少了。
《Joel说软件》中说到，如果我是偏执狂，那么我会说MS肯定不会为它当前领域及纵向相关的潜在领域提供开发工具。这句话看起来也不假，呵呵……
2005年10月22日星期六
发现了一个很好的Wiki：MoinMoin！
http://moinmoin.wikiwikiweb.de
看起来很不错的东西，自动根据客户端语言来显示，用Python写的。不知道在Windows Server 2003上面要支持Python是否麻烦，如果不麻烦，我也想装个来玩一下。
现在我喜欢做的是，像verycd那样用已有的引擎作为后台，然后自己写一个前台的只读门户，那样会很轻松。因为门户不会进行写操作，所以不用担心改乱了数据，只要后台那个引擎是足够稳定的，那就可以放心了。
看起来很不错的东西，自动根据客户端语言来显示，用Python写的。不知道在Windows Server 2003上面要支持Python是否麻烦，如果不麻烦，我也想装个来玩一下。
现在我喜欢做的是，像verycd那样用已有的引擎作为后台，然后自己写一个前台的只读门户，那样会很轻松。因为门户不会进行写操作，所以不用担心改乱了数据，只要后台那个引擎是足够稳定的，那就可以放心了。
2005年10月1日星期六
Google、SNS、Web2.0……这一切意味着专家继续创，但新平庸的人就不要创新了
我的论点只有一个：我们期望有效的控制信息爆炸，特别是通过网络来克服这个网络自身带来的问题时，最"有效"的办法自然是减少信息的创造。
Web farm? Who's farming? Human. Who's harvesting? Machine. Quite like the Matrix, doesn't it?
这真的是一个很奇怪的问题，我们每天在写Blog，上豆瓣列举自己所读所看所听并且还附上评论，还有在Groups上交流，我们到底贡献了多少，其中造成了多少的成本和收益？或者说不应该用成本/收益计算方法，而有新的计量单位和计算方法？或许现在等着某一个在信息学领域提出一个伟大的计算公式，能够和马克思提出商品交换的实质以及引申到资本主义剥削实质一样震撼。
反正在当前，没有任何公式可以利用，我们只是凭兴趣去贡献自己的信息，有时候至少保证贡献了感觉没有吃亏，例如上论坛赚精华贴然后升等级换取更多的好处。有些时候，我们根本没办法判断贡献信息到底对自己是利是弊，对别人也会不会是弊大于利。这听起来很好笑，但是难道有人能够证明你贡献信息就不会对别人造成坏处吗？
Friendster起源于6度空间理论，也就是说世界上任何两个人之间只隔着6个人（以前Coo告诉我的是20个人），也就是任何人都必然在你的朋友的朋友的朋友的朋友的朋友的朋友（6次"朋友"）的圈子之内，不过英文中采用Degree这个词表达经过了多少次"朋友"运算所以叫做6"度"空间。如果Friendster仅仅用在结交朋友的朋友，因为朋友的朋友更加容易成为朋友，那还算是一件好事，不过其应用也仅仅在于交友。如果Friendster，加上Google搜索模式，那么理想的事情就是当我想办一件事的时候，我会考虑我需要什么人际关系，然后可以搜索，然后Google根据HumanRank排序提供结果给我看，我通过它给出的"连接"联系上了排在搜索结果前几位的人，然后托其中一位帮我把事情完成了。
然后让我们回到贡献信息的例子，类似6度空间的理论，只要信息足够的多，计算机可以通过组合信息得出任何人类已知甚至人类未知的事情。这个如果在那个Google在2014年垄断传媒界的例子里，会是很好的事情，因为每个人贡献的信息可以选择Private还是Public，而Google的EPIC能够根据Public信息自动组合出或者说是写作新闻。然而实际上，正如在6度空间理论中你永远不可能知道你是否出于某条关键链上，你现在所贡献出来的一点点信息也可能存在于某条非常重要的推导链上，然后一旦这个推导完成，到底你做了什么你也不知道。正如《Google成功的7堂课》里面提到的一个案例，某人失踪了10年（至少他的家人如此认为），一直都找不到他的下落，最后是在Google间接搜索到他出现在10年前某一个州的车祸伤亡名单上，这才确认他已经死了。我们根本不知道随随便便说的一两句话，可能导致什么，呵呵……
Web farm? Who's farming? Human. Who's harvesting? Machine. Quite like the Matrix, doesn't it?
这真的是一个很奇怪的问题，我们每天在写Blog，上豆瓣列举自己所读所看所听并且还附上评论，还有在Groups上交流，我们到底贡献了多少，其中造成了多少的成本和收益？或者说不应该用成本/收益计算方法，而有新的计量单位和计算方法？或许现在等着某一个在信息学领域提出一个伟大的计算公式，能够和马克思提出商品交换的实质以及引申到资本主义剥削实质一样震撼。
反正在当前，没有任何公式可以利用，我们只是凭兴趣去贡献自己的信息，有时候至少保证贡献了感觉没有吃亏，例如上论坛赚精华贴然后升等级换取更多的好处。有些时候，我们根本没办法判断贡献信息到底对自己是利是弊，对别人也会不会是弊大于利。这听起来很好笑，但是难道有人能够证明你贡献信息就不会对别人造成坏处吗？
Friendster起源于6度空间理论，也就是说世界上任何两个人之间只隔着6个人（以前Coo告诉我的是20个人），也就是任何人都必然在你的朋友的朋友的朋友的朋友的朋友的朋友（6次"朋友"）的圈子之内，不过英文中采用Degree这个词表达经过了多少次"朋友"运算所以叫做6"度"空间。如果Friendster仅仅用在结交朋友的朋友，因为朋友的朋友更加容易成为朋友，那还算是一件好事，不过其应用也仅仅在于交友。如果Friendster，加上Google搜索模式，那么理想的事情就是当我想办一件事的时候，我会考虑我需要什么人际关系，然后可以搜索，然后Google根据HumanRank排序提供结果给我看，我通过它给出的"连接"联系上了排在搜索结果前几位的人，然后托其中一位帮我把事情完成了。
然后让我们回到贡献信息的例子，类似6度空间的理论，只要信息足够的多，计算机可以通过组合信息得出任何人类已知甚至人类未知的事情。这个如果在那个Google在2014年垄断传媒界的例子里，会是很好的事情，因为每个人贡献的信息可以选择Private还是Public，而Google的EPIC能够根据Public信息自动组合出或者说是写作新闻。然而实际上，正如在6度空间理论中你永远不可能知道你是否出于某条关键链上，你现在所贡献出来的一点点信息也可能存在于某条非常重要的推导链上，然后一旦这个推导完成，到底你做了什么你也不知道。正如《Google成功的7堂课》里面提到的一个案例，某人失踪了10年（至少他的家人如此认为），一直都找不到他的下落，最后是在Google间接搜索到他出现在10年前某一个州的车祸伤亡名单上，这才确认他已经死了。我们根本不知道随随便便说的一两句话，可能导致什么，呵呵……
2005年9月10日星期六
可编程样式表
Coo曾经跟我说过，如果CSS里面能够自定义颜色常量（例如Red=#FF0000就是一个颜色常量），那就好了（那意味着你可以定义一个ContentBorderColor和一个HeadBorderColor，可能当初它们的值一样，当你需要修改其中一个的时候你就不需要小心的查找和替换以免替换多了或者替换少了）。Coo的这个想法暂时只有通过xslt实现，MSN Messenger的聊天记录就是通过xml+xslt成仙的，而其中就有很多样式是通过自定义常数一次声明的（通过声明自定义参数）。
我最近在弄一个东西，也发现如果样式表支持可编程那会好很多。例如我在一个地方使用了font-family列表，但是如果浏览器在采用font-family上的后备字体显示时，我就希望padding等属性有一定的修正，但这个暂时做不到。再举一个例子，例如我设计一个ASP.NET控件，而它内部包含一个子元素，我希望这个子元素的padding是整个控件的padding加上1px（也就是"继承"且"运算"），但这也是无法通过样式表编程做到的，暂时只能够在ASP.NET里面主动去运算出这个元素的padding然后显示输出这个padding，而我想做到的效果是例如：
<div id="parent" class="parentLayer">
<div id="child" style="padding: +1px">
</div>
</div>
这时候，无论parentLayer这个样式怎么样，child的padding总是比它多一个pixel。
不知道W3C什么时候才开始重视样式有关的东西，可以让样式更加结构化和可编程。继续这样下去，Web将完全被Web Service取代，变成所有Web都是给机器读取和分析，然后再提供给人看。
我最近在弄一个东西，也发现如果样式表支持可编程那会好很多。例如我在一个地方使用了font-family列表，但是如果浏览器在采用font-family上的后备字体显示时，我就希望padding等属性有一定的修正，但这个暂时做不到。再举一个例子，例如我设计一个ASP.NET控件，而它内部包含一个子元素，我希望这个子元素的padding是整个控件的padding加上1px（也就是"继承"且"运算"），但这也是无法通过样式表编程做到的，暂时只能够在ASP.NET里面主动去运算出这个元素的padding然后显示输出这个padding，而我想做到的效果是例如：
<div id="parent" class="parentLayer">
<div id="child" style="padding: +1px">
</div>
</div>
这时候，无论parentLayer这个样式怎么样，child的padding总是比它多一个pixel。
不知道W3C什么时候才开始重视样式有关的东西，可以让样式更加结构化和可编程。继续这样下去，Web将完全被Web Service取代，变成所有Web都是给机器读取和分析，然后再提供给人看。
2005年9月4日星期日
多层网络SNS及泛信息发布系统
自从高二暑假完成TextGem之后，我就没做过完整的项目（高三升级TextGem到TextGem Pro），CommentMe、Xilite等项目都在概念设计后放弃，这两个项目都是ajax气息太浓，我暂时无法掌握一种良好的ajax开发和调试方法，完成概念设计后一旦进入需要服务器端和客户端代码同步设计的阶段就让我无法进行下去。至于Quickling，也是出过一版Quickling Lite for Acess，不过因为硬盘问题现在代码都不知道哪里还能找回来了，而且此原型的安全性还是存在一些我能够发现的漏洞（当然，作为守方认为的高级漏洞，对于攻方来说就是超高级漏洞了，很难找到的）。
现在我准备重新回归完善的先Design后Coding过程，做一个SNS核心的Web平台。
首先解释一下多层网络SNS的概念，之前friendster和orkut只能用于链接朋友网，用户信息真实性稍低，甚至有些朋友仅仅是网友；而linkist等商务SNS则采用真实姓名和真实信息（只要别人都用真实信息，一般新人都会愿意填写真实信息），主要用于商业上的联系，就是把“朋友的朋友更容易成为朋友”的理论拓展为“合作方的合作方更容易签到合同”。我现在所谓的多层网络SNS就是允许用户以不同程度的真实信息生存在不同的关系层中，例如用户进入后就会发现页面有3个Tab：工作、生活、家庭。工作方面是像linkist那样的实名商务连接方式，学习orkut那样能够单方面匿名对对方做出评价，例如能够设置年交易额1万、10万、100万，或者可以设置可信任度；生活方面是像orkut那样的匿名朋友圈，你能够通过Email、真实姓名等方式查找现实生活中你认识的朋友是否也在SNS上面；家庭则是实名的家庭关系网，可以选择关系类型，然后自动生成族谱（玩过Sims2的都知道这有多方便）。关系在不同层之间切换会受到一定的阻碍，也就是说切换层相当于一个距离加权比较大的关系，在搜索最短关系链接的时候优先考虑尽量少层切换的。
另一种关于多层SNS的想法就是，我不直接细分层，而是提供“连接方式”，然后任何一个人都可以匿名的指定他和另外一个人存在的若干链接方式，而更多的选项则是基于“链接方式”的选择的。例如你选择“同事”，那就填写有关上下级组织结构图的属性；选择“亲戚”，就填写亲戚关系；选择“朋友”，就填写熟悉程度等。
另外就是泛消息发布系统，在linkist我看到一种设置，就是不允许非好友直接发信息给自己，所有信息必须经过人际链转发。虽然我没用过，但应该就是发送的信息必须先经过好友审阅，如果好后不通过就不能够传递，当然这也就是发送的不再是私人信息，因为有第三方人员能看到。另外发布和传递spam一经Report将会受到惩罚，这也是个很好的做法，因为orkut上面的spam就不少。而我现在则选择一种直邮和传递邮之间的方法，就是在发送信息的时候信息会自由在朋友圈内扩散，用户收到信息后将可以选择觉得有意义或者没有意义，如果选择有意义则促进该信息在此接受用户的朋友圈中扩善，否则将是抑制。这样就能够将SNS里面的“关系”发挥到信息传递上面来，既能够抑制spam，又能够自动组织和提供用户感兴趣的信息。
现在我准备重新回归完善的先Design后Coding过程，做一个SNS核心的Web平台。
首先解释一下多层网络SNS的概念，之前friendster和orkut只能用于链接朋友网，用户信息真实性稍低，甚至有些朋友仅仅是网友；而linkist等商务SNS则采用真实姓名和真实信息（只要别人都用真实信息，一般新人都会愿意填写真实信息），主要用于商业上的联系，就是把“朋友的朋友更容易成为朋友”的理论拓展为“合作方的合作方更容易签到合同”。我现在所谓的多层网络SNS就是允许用户以不同程度的真实信息生存在不同的关系层中，例如用户进入后就会发现页面有3个Tab：工作、生活、家庭。工作方面是像linkist那样的实名商务连接方式，学习orkut那样能够单方面匿名对对方做出评价，例如能够设置年交易额1万、10万、100万，或者可以设置可信任度；生活方面是像orkut那样的匿名朋友圈，你能够通过Email、真实姓名等方式查找现实生活中你认识的朋友是否也在SNS上面；家庭则是实名的家庭关系网，可以选择关系类型，然后自动生成族谱（玩过Sims2的都知道这有多方便）。关系在不同层之间切换会受到一定的阻碍，也就是说切换层相当于一个距离加权比较大的关系，在搜索最短关系链接的时候优先考虑尽量少层切换的。
另一种关于多层SNS的想法就是，我不直接细分层，而是提供“连接方式”，然后任何一个人都可以匿名的指定他和另外一个人存在的若干链接方式，而更多的选项则是基于“链接方式”的选择的。例如你选择“同事”，那就填写有关上下级组织结构图的属性；选择“亲戚”，就填写亲戚关系；选择“朋友”，就填写熟悉程度等。
另外就是泛消息发布系统，在linkist我看到一种设置，就是不允许非好友直接发信息给自己，所有信息必须经过人际链转发。虽然我没用过，但应该就是发送的信息必须先经过好友审阅，如果好后不通过就不能够传递，当然这也就是发送的不再是私人信息，因为有第三方人员能看到。另外发布和传递spam一经Report将会受到惩罚，这也是个很好的做法，因为orkut上面的spam就不少。而我现在则选择一种直邮和传递邮之间的方法，就是在发送信息的时候信息会自由在朋友圈内扩散，用户收到信息后将可以选择觉得有意义或者没有意义，如果选择有意义则促进该信息在此接受用户的朋友圈中扩善，否则将是抑制。这样就能够将SNS里面的“关系”发挥到信息传递上面来，既能够抑制spam，又能够自动组织和提供用户感兴趣的信息。
2005年9月2日星期五
Google Local中文版可用啦！
中文版叫做"Google本地搜索"，地址为bendi.google.com。大家不要去local.google.com，因为那里仅仅是汉化的界面，地区无论你输入什么都返回"不可识别"。
我刚刚试用了一下，搜索"中山大学"@"广州"，发现结果还很好，而且有maps.google.com的那种详细的街道图，可能maps.google.com也将会有中国的街道图了。另外地图上写着地图服务供应商是mapabc，我搜索到的信息是"Mapabc.com成立于2003年4月，是从事地理信息系统（GIS）研究与应用推广的高新技术企业"，现在做地图的服务上越来越多，而且也有开放API的，看来以后地图也越来越廉价了。
我刚刚试用了一下，搜索"中山大学"@"广州"，发现结果还很好，而且有maps.google.com的那种详细的街道图，可能maps.google.com也将会有中国的街道图了。另外地图上写着地图服务供应商是mapabc，我搜索到的信息是"Mapabc.com成立于2003年4月，是从事地理信息系统（GIS）研究与应用推广的高新技术企业"，现在做地图的服务上越来越多，而且也有开放API的，看来以后地图也越来越廉价了。
2005年9月1日星期四
游戏年龄与实际年龄
根据我多年的观察，一个人的游戏年龄基本上是与实际年龄无关的，并不会因为实际年龄大而游戏年龄增长得快。无论是像我这样从小学开始玩PC Game还是好像我的一些同学那样高中甚至大学才有比较多时间接触PC Game，实际上开头的玩法都总是单调和追求表层刺激的，而需要等游戏年龄增长才能够理解游戏的更深层次玩法和艺术价值的一面。
举一个最简单的例子，例如赛车游戏：（这个实例不包括在现实生活中熟悉车辆的人士）
对于一个游戏年龄低的人来说，他追求的就是最表层的刺激，例如视觉效果和速度感，无论是当年NFS2作为第一个3D赛车游戏推出还是后来的NFSUG模仿《速度与激情2》的光影之夜，这都能非常好的满足初级玩家的需求。初级玩家不会懂侧滑（现在《头文字D》宣传Drift过后是另外一回事），甚至不擅长使用刹车，他们喜欢一直按着加速键的那种感觉，弯转不过就撞上，然后速度降为零，低速出弯后又再下一次的加速。这听起来就好像我妈说我小时候还不会走的时候，就喜欢高速的向前爬，直到撞上墙，然后我会咔咔笑，然后又转过来加速撞另一堵墙。
然后，虽则游戏经验的增加，或者看一些游戏技巧的文章或者贴子，玩家的游戏年龄会增加，它开始知道赛车是存在所谓的“最优路线”，入弯的时候应该减速和内切，出弯的时候应该加速和外切。但是，这时候他只是觉得，只有在必要的路段跟随一定的规律减速和入弯，在其他地方仍然可以追求速度最大化，无论是追求刺激还是他直觉认为一段路程内速度最大化肯定让他在整场比赛中获得优势。这时候他往往会选择在入弯前还是不停的加速，到需要入玩的时候就死按减速，任何时候加速和减速必然有一个键按着，因为在不需要减速的时候没有任何理由不加速。
之后，可能他开始对赛车游戏有Feel了，他可能能够明白到油门和刹车大多数时候都不是踩死的，正如现实中的车辆使用一样。最优路线上并非速度非加即减，而是很多地方都是保持速度或者稍微加减。同时，他还可能开始掌握侧滑等技巧，甚至尝试在游戏中玩花式。
为什么我要讲游戏年龄？因为这意味着中国玩家的趋向是会发展的。张朝阳最近嘲笑陈天桥，说他是赚快钱的，而事实上很可能就是这样。现在主流玩家确实水平很低，但这不意味着是“劣根性”所造成的长期影响，而更可能是现在很多人的游戏年龄很低，他们只能追求最表面的刺激感，然而如果想面向这个去做长期投资，那就不适合了，因为玩家的游戏年龄一旦增长，他们就会开始挑有深度的游戏，而中国和韩国的游戏制作者能否满足这种需求暂时还很难说，很肯能东方网游只是一个能够撑的更大的泡沫。
举一个最简单的例子，例如赛车游戏：（这个实例不包括在现实生活中熟悉车辆的人士）
对于一个游戏年龄低的人来说，他追求的就是最表层的刺激，例如视觉效果和速度感，无论是当年NFS2作为第一个3D赛车游戏推出还是后来的NFSUG模仿《速度与激情2》的光影之夜，这都能非常好的满足初级玩家的需求。初级玩家不会懂侧滑（现在《头文字D》宣传Drift过后是另外一回事），甚至不擅长使用刹车，他们喜欢一直按着加速键的那种感觉，弯转不过就撞上，然后速度降为零，低速出弯后又再下一次的加速。这听起来就好像我妈说我小时候还不会走的时候，就喜欢高速的向前爬，直到撞上墙，然后我会咔咔笑，然后又转过来加速撞另一堵墙。
然后，虽则游戏经验的增加，或者看一些游戏技巧的文章或者贴子，玩家的游戏年龄会增加，它开始知道赛车是存在所谓的“最优路线”，入弯的时候应该减速和内切，出弯的时候应该加速和外切。但是，这时候他只是觉得，只有在必要的路段跟随一定的规律减速和入弯，在其他地方仍然可以追求速度最大化，无论是追求刺激还是他直觉认为一段路程内速度最大化肯定让他在整场比赛中获得优势。这时候他往往会选择在入弯前还是不停的加速，到需要入玩的时候就死按减速，任何时候加速和减速必然有一个键按着，因为在不需要减速的时候没有任何理由不加速。
之后，可能他开始对赛车游戏有Feel了，他可能能够明白到油门和刹车大多数时候都不是踩死的，正如现实中的车辆使用一样。最优路线上并非速度非加即减，而是很多地方都是保持速度或者稍微加减。同时，他还可能开始掌握侧滑等技巧，甚至尝试在游戏中玩花式。
为什么我要讲游戏年龄？因为这意味着中国玩家的趋向是会发展的。张朝阳最近嘲笑陈天桥，说他是赚快钱的，而事实上很可能就是这样。现在主流玩家确实水平很低，但这不意味着是“劣根性”所造成的长期影响，而更可能是现在很多人的游戏年龄很低，他们只能追求最表面的刺激感，然而如果想面向这个去做长期投资，那就不适合了，因为玩家的游戏年龄一旦增长，他们就会开始挑有深度的游戏，而中国和韩国的游戏制作者能否满足这种需求暂时还很难说，很肯能东方网游只是一个能够撑的更大的泡沫。
Sense for AdSense
我在论坛发了一帖关于AdSense的帖，开头广告都是Google AdSense的广告，后来竟然出来一条链接到以下站点的广告：
http://keywordcountry.com/
这个站点是做什么的呢？就是收集和更新AdWords的价值，例如它知道的大于$50的AdWords有150个，假如你的网页什么时候放上一个而AdSense又正好提供了那么广告了，只需要有用户轻轻一点你就有$50了，两次点击你就能够收到$100的支票了。
Sense for AdSense，就好像我之前说过做到AdSense级别的Wiki-Spam那么Google就很难判别了。Google总是以为能够通过优化算法把自己调整到一个完全旁观者的角色来服务，然而实际上“黄雀在后”的情况一直都会出现，除非Google改用量子计算，遵守“测不准原理”，那别人就真的很难应对。
Google啊，现在已经开始有人觉得它变得高傲和自大了，本来的Silicon Valley新兴和希望现在却变成了威胁，因为它把其他小企业的人才都抢走了。有人说，MS终于开始向IBM的温纯型转变了，而Google则在向MS的霸道型转变，这是否暗示着这时企业壮大和不断增加垄断领域的必经之路？
http://keywordcountry.com/
这个站点是做什么的呢？就是收集和更新AdWords的价值，例如它知道的大于$50的AdWords有150个，假如你的网页什么时候放上一个而AdSense又正好提供了那么广告了，只需要有用户轻轻一点你就有$50了，两次点击你就能够收到$100的支票了。
Sense for AdSense，就好像我之前说过做到AdSense级别的Wiki-Spam那么Google就很难判别了。Google总是以为能够通过优化算法把自己调整到一个完全旁观者的角色来服务，然而实际上“黄雀在后”的情况一直都会出现，除非Google改用量子计算，遵守“测不准原理”，那别人就真的很难应对。
Google啊，现在已经开始有人觉得它变得高傲和自大了，本来的Silicon Valley新兴和希望现在却变成了威胁，因为它把其他小企业的人才都抢走了。有人说，MS终于开始向IBM的温纯型转变了，而Google则在向MS的霸道型转变，这是否暗示着这时企业壮大和不断增加垄断领域的必经之路？
2005年8月24日星期三
Google Talk
http://www.google.com/talk
Google又找到了一样成本很低的投资，那就是基于Jabber的Google Talk。我觉得这样的投资方法很聪明，它不需要研发什么新技术，不用好像MS为了摆脱竞争对手那样建立标准外的标准，需要的仅仅是用自己的名字去包装一项老技术，同时整合一些自己擅长的其他东西（暂时它只整合了Gmail Notifier，连任何一项搜索功能都没有整合进去）。
虽然Add Friends的时候默认提示someone@gmail.com，不过可能所有的Google Account都可添加。另外它还可以语音，当然也是基于Jabber的。
如果你用Google Talk发Invitation给别人，那么自动同时也发送了G?mail Invitation，当然对方可以选择要Gmail或者说我已经有一个Gmail Account。
另外我发现Google Talk在Gmail用户范围内传播得很快，可能因为Gmail?用户早就习惯了这种“人传人”的方式。无论是碰巧还是策划，Google在这件事情上是很成功的，习惯MSN式大幅宣传才取用的人就是只能接受大牌子大宣传的产品；而Google从来节省宣传?费用，靠人传人的口碑，而他所有产品都靠这样推广，它的用户群也?非常习惯这种方式，Google在自己的用户群中推广新服务非常容易。
这说明了，当你按照一定的方式招揽了一定的用户，以后最好都用同样的方式推广新的服务和产品。
另外Google Talk和新的Google Desktop Search 2 Beta（仅英文页面可见）的SideBar也能够组合起来。Google Desktop Search 2的SideBar可以说是把Windows Vista的SideBar的功能都做上了，而且都是Google服务，这招够狠！这个SideBar能够整合Gmail、Talk等功能，内嵌快速搜索（而且还能够搜索“开始菜单”里面的项目，这和Vista隐藏掉开始菜单里的“搜索程序”然后提供快速搜索是一样的）。Google这种利用轻量级软件以快打慢真的很绝，Vista既要给用户预览它的新功能，但是它的开发缓慢又必然给Google用轻量级等效软件去抢占市场份额，当年MS想用MSN Game整合到Windows来抢占联众等桌面网络游戏市场都不怎么成功，反而Google这种敏捷的方法可能能够从MS手上抢占到份额。
Google又找到了一样成本很低的投资，那就是基于Jabber的Google Talk。我觉得这样的投资方法很聪明，它不需要研发什么新技术，不用好像MS为了摆脱竞争对手那样建立标准外的标准，需要的仅仅是用自己的名字去包装一项老技术，同时整合一些自己擅长的其他东西（暂时它只整合了Gmail Notifier，连任何一项搜索功能都没有整合进去）。
虽然Add Friends的时候默认提示someone@gmail.com，不过可能所有的Google Account都可添加。另外它还可以语音，当然也是基于Jabber的。
如果你用Google Talk发Invitation给别人，那么自动同时也发送了G?mail Invitation，当然对方可以选择要Gmail或者说我已经有一个Gmail Account。
另外我发现Google Talk在Gmail用户范围内传播得很快，可能因为Gmail?用户早就习惯了这种“人传人”的方式。无论是碰巧还是策划，Google在这件事情上是很成功的，习惯MSN式大幅宣传才取用的人就是只能接受大牌子大宣传的产品；而Google从来节省宣传?费用，靠人传人的口碑，而他所有产品都靠这样推广，它的用户群也?非常习惯这种方式，Google在自己的用户群中推广新服务非常容易。
这说明了，当你按照一定的方式招揽了一定的用户，以后最好都用同样的方式推广新的服务和产品。
另外Google Talk和新的Google Desktop Search 2 Beta（仅英文页面可见）的SideBar也能够组合起来。Google Desktop Search 2的SideBar可以说是把Windows Vista的SideBar的功能都做上了，而且都是Google服务，这招够狠！这个SideBar能够整合Gmail、Talk等功能，内嵌快速搜索（而且还能够搜索“开始菜单”里面的项目，这和Vista隐藏掉开始菜单里的“搜索程序”然后提供快速搜索是一样的）。Google这种利用轻量级软件以快打慢真的很绝，Vista既要给用户预览它的新功能，但是它的开发缓慢又必然给Google用轻量级等效软件去抢占市场份额，当年MS想用MSN Game整合到Windows来抢占联众等桌面网络游戏市场都不怎么成功，反而Google这种敏捷的方法可能能够从MS手上抢占到份额。
2005年8月19日星期五
继续说说窄告和户外广告
我总结出来的规律是，"用户在浏览正文时越是不太确定他想要什么或者他想要的是否在此时，那么窄告的成功机率就越大"（这和我上次的说法不矛盾，目标明确的用户停留时间通常也长一些，在用户目标不明确的时候用户必然是不想停留太久的）。简而言之，窄告投放在用户"直奔目标"式的阅读区域是没有任何效用的，因为用户根本不会看；而窄告投放在搜索结果是最有效的，因为搜索本来就表明用户目的不明确。暂时来说，我对窄告持保留态度，对于针对性投放这个我支持，这是提升成功率的一种办法，但是对于AdSense这种周围都可以放置的方法我反对，这样做太过"散弹枪"式了。
说会上次提到的地铁广告，地铁自己说是"不受风雨影响的户外广告"，我就挺喜欢这样。我说过，户外广告往往属于你不得不看的，因为你不需经过或停留在某一个地方，你的眼睛也需要地方停留（除了你的脚尖）。
现在很多论坛在登录和发帖后都会出现一个"3秒后自动转跳"的页面，我怀疑是因为如果使用Access等低级数据库Insert数据后马上Select是读去不出所以要给时间达到延时吧（这个延时实际上不需要3秒，即使用户马上点击转跳也可以），大多数论坛这个转跳页都是很空白的，不过CSDN登录后2秒转跳那个就不是，那个是有广告，虽然广告不是刻意的而是因为模板而带有的。这让我想起来网络也可以发布"户外广告"，这些户外广告就是AdSense最好的补充，特别是那些"当用户直奔目标时"的场合。
在网络上的户外广告其实一早就有，例如GameSpot和IGN的，它们就完全符合我上面所说的，当你直奔目标时中间也得停留一下看看广告，而且不是在浏览正文时用眼角看一下，而是在没有正文时停下来好好看看广告。这些游戏网站的做法就是，在你每看若干个页面（或许只有特定的页面才计数）后你点击下一个页面就会进入广告页，整个页面就是中间一个大大的广告（通常是Flash），下面还附带一个"Next"按钮让你继续去看你刚才点击的目标链接。这样做是非常有效的，因为在这些游戏网站上，玩家通常是逐张浏览未发布的游戏新的公开截图（看原图，每张一页），或者看长长的Preview、Review、Interview（网站把这些文章剪开为n页），无论看什么你总要点若干下"Next"，而且中就有几次是碰到广告的，不过这也很正常嘛，你不是付费会员自然看广告。
如果把窄告的定点投放和户外广告结合起来，那就会非常好了。例如在看一篇文章的很多段中，插入一个很有针对性的广告页，那比单纯的AdSense会有效得多（因为AdSense很明显，你可以直接跳过不看）。如果有一天Google也发现了这个东西的好处，并提供有关的支持技术（就是检索多个相关页的内容并且把广告提供在桥页），那它就更加发达了。不过Google现在也很好，起码它这种"我自己好也分享出来让大家好"的做法也让不少小型企业通过AdSense获得了不少订单，足够受欢迎了。
说会上次提到的地铁广告，地铁自己说是"不受风雨影响的户外广告"，我就挺喜欢这样。我说过，户外广告往往属于你不得不看的，因为你不需经过或停留在某一个地方，你的眼睛也需要地方停留（除了你的脚尖）。
现在很多论坛在登录和发帖后都会出现一个"3秒后自动转跳"的页面，我怀疑是因为如果使用Access等低级数据库Insert数据后马上Select是读去不出所以要给时间达到延时吧（这个延时实际上不需要3秒，即使用户马上点击转跳也可以），大多数论坛这个转跳页都是很空白的，不过CSDN登录后2秒转跳那个就不是，那个是有广告，虽然广告不是刻意的而是因为模板而带有的。这让我想起来网络也可以发布"户外广告"，这些户外广告就是AdSense最好的补充，特别是那些"当用户直奔目标时"的场合。
在网络上的户外广告其实一早就有，例如GameSpot和IGN的，它们就完全符合我上面所说的，当你直奔目标时中间也得停留一下看看广告，而且不是在浏览正文时用眼角看一下，而是在没有正文时停下来好好看看广告。这些游戏网站的做法就是，在你每看若干个页面（或许只有特定的页面才计数）后你点击下一个页面就会进入广告页，整个页面就是中间一个大大的广告（通常是Flash），下面还附带一个"Next"按钮让你继续去看你刚才点击的目标链接。这样做是非常有效的，因为在这些游戏网站上，玩家通常是逐张浏览未发布的游戏新的公开截图（看原图，每张一页），或者看长长的Preview、Review、Interview（网站把这些文章剪开为n页），无论看什么你总要点若干下"Next"，而且中就有几次是碰到广告的，不过这也很正常嘛，你不是付费会员自然看广告。
如果把窄告的定点投放和户外广告结合起来，那就会非常好了。例如在看一篇文章的很多段中，插入一个很有针对性的广告页，那比单纯的AdSense会有效得多（因为AdSense很明显，你可以直接跳过不看）。如果有一天Google也发现了这个东西的好处，并提供有关的支持技术（就是检索多个相关页的内容并且把广告提供在桥页），那它就更加发达了。不过Google现在也很好，起码它这种"我自己好也分享出来让大家好"的做法也让不少小型企业通过AdSense获得了不少订单，足够受欢迎了。
2005年8月13日星期六
Google News竟然能够迁就我的Palm用gb2312输出
在PC上看，Google News是utf-8的，这是Palm所不支持的（好像PPC对unicode支持也不怎么行），但是我还是尝试了用Palm去打开，竟然能够看到，那就是gb2312啦，哈哈！Google News真够人性化哦。
2005年8月7日星期日
使用Google快照的方法
如果你想看某个页面的Google缓存，仅仅需要在你的Google搜索栏里输入cache:{URL}，虽然我不知道这样看到的结果会不会和直接点击搜索结果旁边的"Google快照"有什么不同，但是在Google快照长期用不了的情况下，用cache:倒没什么问题。至于为什么这样，我也不知道，或许仅仅是地址上有些差别所以没有封到吧。
2005年8月4日星期四
我不懂 ASP.NET
这真是个严重的问题，而且我越来越发觉其严重性。要懂得ASP.NET语法非常容易，要学习MS提供给你那种RAD开发方法也很容易，但是你无法做大东西，或者说你只能够按照ASP的老路去做大东西，并不能“享受”ASP.NET带来的“优越性”。
要做到“优秀”的Web应用，最重要的就是“分离”（“正交设计”就是老生常谈的问题了）。首先就是Web Standards里面鼓催的内容(Content)与布局(Layout)分离，暂且不说“终极目标”是HTML只容纳内容CSS只容纳布局对于现在的浏览器来说有多么过分（特别是你要兼容多个浏览器的话），我们就现把这几下来作为“第一分离”。然后，就是ASP.NET里面3层式设计，对于ASP.NET来说就应该划分为“编译部分”和“不编译/动态编译部分”，这个算是“第二分层”。这样2*2就已经组合出4个部分，在编写代码的时候某一段代码应该属于哪个部分，一个部分如何引用另一个部分，这就是个非常头痛的问题。
要说明这个事情，我们需要从以前的做法说起。
在“古老”的时代，我们存在一些“古老的假设”。首先，当时没有很明确的布局、内容、行为分离理论，其次当时假设所有这些都属于不编译部分，编译部分都是相对固定的逻辑层和数据层代码（相对小型的系统当然就什么都不编译，因为ASP引用COM组件还是要一定的权限的）。那个时候HTML是个大杂烩，我们控制了HTML就控制了天下，而不编译部分就是控制天下的最重要部分，你写的ASP代码已经完全决定了用户看到的布局、内容、行为。不过即使在不编译代码中，我们也分离出了相对固定代码，这就是我们的include技术欣欣向荣的原因了。一个良好设计的ASP系统里面有良好的include体系，固定的代码都是通过include重复使用。如果你对于为什么要include有疑问的话，那就真应该看看《程序员修炼之道》里面的DRY(Don't Repeat Yourself)规则，任何事情在程序代码中都应该仅仅被描述一次，一旦被两次描述那么你就必须保持两边的同步更新了，一旦出现同步失败你的代码就可能出现不可预料的问题。
然后ASP.NET出现了，它带来了“立体化”的Web模型，最重要的是它提出了Code-Behind和WebControl这两种编译代码的存在方式。Code-Behind代码和WebControl代码都是必须先显式编译后使用的（其实不编译的Code-Behind是可以的，就是<%@Page Src=""%>方式，但是这不是我现在要讨论的东西）。Code-Behind的页面或者UserControl实际上是被编译了两次的，第一次是编译后台代码，生成的类就是<%@Page Inherit=""%>中Inherit指向的Page/UserControl派生类，第二次是在页面被访问的时候即时编译出来的Page/UserControl派生类的派生类，这其中第一次编译就属于上面所说的“编译部分”。至于WebControl则是必须先编译再用<%@Register%>指令引用的，整个都属于“编译部分”。为什么MS要在.NET Framework里面设置编译部分？我想它是相信有一些UI部分的逻辑能够在很高的层次存在一定的共性，这些共性就应该被编译。例如WebControl中最突出的DataGrid，就是一种数据载体需要列表、需要分页甚至对于有些数据字段需要特殊显示（例如一个“真/假”字段需要显示为一个CheckBox是否被选中）的共性。我们也可以归纳自己网站中的一些显示共性的逻辑，自己制作WebControl（甚至TemplateControl或者Control，HtmlControl当然也行不过意义不大），或者继承现有的各种Control（继承HtmlControl是有意义的）。至于Page的后台代码编译有什么意思，这个我就不清楚了。诚然，你可以把Page看作一种Control，但是这种编译是不可复用的，编译来干什么呢？我唯一的解释就是这仅仅属于一种RAD(Rapid
Application Development：快速应用程序开发）开发方式，程序员可以随便拖放控件让后写后台代码并且编译，美工之后再来处理aspx页面，只要美工不毁坏控件tag那么他可以任意添加新tag或者移动现有tag。
然而这种编译方式并没有解决我们原来用include带来的各种问题（至少要考虑什么颗粒度的代码应该include，什么颗粒度的就让它在各处重复），我们变成了考虑什么层次的UI逻辑应该“统一起来”把它们变成编译好的WebControl。关于这个事情我暂时还在摸索之中，我喜欢的做法是把每个页面的核心固定内容封装成为WebControl（其实我早在TextGem的时候，就已经是每个页面的主要内容封装到一个function里面），例如一个登录表单的两个TextBox和一个Button就封装起来。同时一些公共元素例如Header这种以前习惯include的东西有时候也封装为WebControl（不过我现在更加喜欢封装为ascx，因为这部分应该属于容易编辑的UI代码，不应该被编译死）。封装为WebControl的东西大多数是样式无关（仅使用全局样式）的，样式有关的或者我考虑到以后要修改HTML的东西我都仅仅封装为ascx，或者封装为TemplateControl以后必要时能够通过改Template部分修改输出的HTML。这就是我们现在能够做到的事情。
至于未来，ASP.NET 2.0会为我们提供WebPart和MasterPage等优秀功能。WebPart能够让我们轻松实现Sharepoint才拥有的门户页面效果，每一个信息栏都是一个WebPart，能够被所以拖动和缩放。至于MasterPage则能够制作一个固定的模板页，制定其中几个地方为ContentContainer，然后在aspx里面引用这个MasterPage并且用同ID的Content控件对应填充ContentContainer（Content控件里面可以放置任何东西），这对于使用少数模板覆盖全站的设计非常有用。不过其实我非常需要一样东西，暂时看起来没有的。我希望有一种松散型复合控件，例如我订一个登录表单控件，派生自HtmlForm，然后必须包含用户名和密码两个输入框（HtmlInputText的派生类，或者是实例）以及一个提交按钮，然后我可以按任意方式布局它们，例如：
<LoginForm:Form runat="server">
<span class="inputSubject">UserName:</span>
<LoginForm:UserName class="inputText" runat="server" />
<br />
<span class="inputSubject">Password:</span>
<LoginForm:Password class="inputText" runat="server" />
<br />
<LoginForm:Submit class="inputButton" runat="server" />
</LoginForm:Form>
这会是一种很好的控件结构，因为我定义了一个<LoginForm:Form>必须包含<LoginForm:UserName>、<LoginForm:Password>、<LoginForm:Submit>各一个，然后选择上述布局或者Table布局或者其他布局方式就在aspx中定义，那就有效实现了布局代码不编译逻辑代码编译的分离。布局代码方面，既然是融入在aspx文件中，那么我不喜欢的话可以随意改，可以放心地交给美工改，至于逻辑代码则是编译好的我不用担心以后会被自己不小心改动了。或许这种设计与Page的Code-Behind编译有什么不同，关键就在于它强制规定了什么包含什么，包含多少个，而且这些被包含的控件的一些属性的默认值可能也在编译代码中，你看我上面的代码就没有指定<LoginForm:Submit>的value为“提交”或者“登录”，我的意思就是在编译代码中这个已经指定好了，这个指定好可能是指代码中为属性指定了默认值，甚至可能是那已经是一个派生类该派生类已经被指定了属性默认值。
要做到“优秀”的Web应用，最重要的就是“分离”（“正交设计”就是老生常谈的问题了）。首先就是Web Standards里面鼓催的内容(Content)与布局(Layout)分离，暂且不说“终极目标”是HTML只容纳内容CSS只容纳布局对于现在的浏览器来说有多么过分（特别是你要兼容多个浏览器的话），我们就现把这几下来作为“第一分离”。然后，就是ASP.NET里面3层式设计，对于ASP.NET来说就应该划分为“编译部分”和“不编译/动态编译部分”，这个算是“第二分层”。这样2*2就已经组合出4个部分，在编写代码的时候某一段代码应该属于哪个部分，一个部分如何引用另一个部分，这就是个非常头痛的问题。
要说明这个事情，我们需要从以前的做法说起。
在“古老”的时代，我们存在一些“古老的假设”。首先，当时没有很明确的布局、内容、行为分离理论，其次当时假设所有这些都属于不编译部分，编译部分都是相对固定的逻辑层和数据层代码（相对小型的系统当然就什么都不编译，因为ASP引用COM组件还是要一定的权限的）。那个时候HTML是个大杂烩，我们控制了HTML就控制了天下，而不编译部分就是控制天下的最重要部分，你写的ASP代码已经完全决定了用户看到的布局、内容、行为。不过即使在不编译代码中，我们也分离出了相对固定代码，这就是我们的include技术欣欣向荣的原因了。一个良好设计的ASP系统里面有良好的include体系，固定的代码都是通过include重复使用。如果你对于为什么要include有疑问的话，那就真应该看看《程序员修炼之道》里面的DRY(Don't Repeat Yourself)规则，任何事情在程序代码中都应该仅仅被描述一次，一旦被两次描述那么你就必须保持两边的同步更新了，一旦出现同步失败你的代码就可能出现不可预料的问题。
然后ASP.NET出现了，它带来了“立体化”的Web模型，最重要的是它提出了Code-Behind和WebControl这两种编译代码的存在方式。Code-Behind代码和WebControl代码都是必须先显式编译后使用的（其实不编译的Code-Behind是可以的，就是<%@Page Src=""%>方式，但是这不是我现在要讨论的东西）。Code-Behind的页面或者UserControl实际上是被编译了两次的，第一次是编译后台代码，生成的类就是<%@Page Inherit=""%>中Inherit指向的Page/UserControl派生类，第二次是在页面被访问的时候即时编译出来的Page/UserControl派生类的派生类，这其中第一次编译就属于上面所说的“编译部分”。至于WebControl则是必须先编译再用<%@Register%>指令引用的，整个都属于“编译部分”。为什么MS要在.NET Framework里面设置编译部分？我想它是相信有一些UI部分的逻辑能够在很高的层次存在一定的共性，这些共性就应该被编译。例如WebControl中最突出的DataGrid，就是一种数据载体需要列表、需要分页甚至对于有些数据字段需要特殊显示（例如一个“真/假”字段需要显示为一个CheckBox是否被选中）的共性。我们也可以归纳自己网站中的一些显示共性的逻辑，自己制作WebControl（甚至TemplateControl或者Control，HtmlControl当然也行不过意义不大），或者继承现有的各种Control（继承HtmlControl是有意义的）。至于Page的后台代码编译有什么意思，这个我就不清楚了。诚然，你可以把Page看作一种Control，但是这种编译是不可复用的，编译来干什么呢？我唯一的解释就是这仅仅属于一种RAD(Rapid
Application Development：快速应用程序开发）开发方式，程序员可以随便拖放控件让后写后台代码并且编译，美工之后再来处理aspx页面，只要美工不毁坏控件tag那么他可以任意添加新tag或者移动现有tag。
然而这种编译方式并没有解决我们原来用include带来的各种问题（至少要考虑什么颗粒度的代码应该include，什么颗粒度的就让它在各处重复），我们变成了考虑什么层次的UI逻辑应该“统一起来”把它们变成编译好的WebControl。关于这个事情我暂时还在摸索之中，我喜欢的做法是把每个页面的核心固定内容封装成为WebControl（其实我早在TextGem的时候，就已经是每个页面的主要内容封装到一个function里面），例如一个登录表单的两个TextBox和一个Button就封装起来。同时一些公共元素例如Header这种以前习惯include的东西有时候也封装为WebControl（不过我现在更加喜欢封装为ascx，因为这部分应该属于容易编辑的UI代码，不应该被编译死）。封装为WebControl的东西大多数是样式无关（仅使用全局样式）的，样式有关的或者我考虑到以后要修改HTML的东西我都仅仅封装为ascx，或者封装为TemplateControl以后必要时能够通过改Template部分修改输出的HTML。这就是我们现在能够做到的事情。
至于未来，ASP.NET 2.0会为我们提供WebPart和MasterPage等优秀功能。WebPart能够让我们轻松实现Sharepoint才拥有的门户页面效果，每一个信息栏都是一个WebPart，能够被所以拖动和缩放。至于MasterPage则能够制作一个固定的模板页，制定其中几个地方为ContentContainer，然后在aspx里面引用这个MasterPage并且用同ID的Content控件对应填充ContentContainer（Content控件里面可以放置任何东西），这对于使用少数模板覆盖全站的设计非常有用。不过其实我非常需要一样东西，暂时看起来没有的。我希望有一种松散型复合控件，例如我订一个登录表单控件，派生自HtmlForm，然后必须包含用户名和密码两个输入框（HtmlInputText的派生类，或者是实例）以及一个提交按钮，然后我可以按任意方式布局它们，例如：
<LoginForm:Form runat="server">
<span class="inputSubject">UserName:</span>
<LoginForm:UserName class="inputText" runat="server" />
<br />
<span class="inputSubject">Password:</span>
<LoginForm:Password class="inputText" runat="server" />
<br />
<LoginForm:Submit class="inputButton" runat="server" />
</LoginForm:Form>
这会是一种很好的控件结构，因为我定义了一个<LoginForm:Form>必须包含<LoginForm:UserName>、<LoginForm:Password>、<LoginForm:Submit>各一个，然后选择上述布局或者Table布局或者其他布局方式就在aspx中定义，那就有效实现了布局代码不编译逻辑代码编译的分离。布局代码方面，既然是融入在aspx文件中，那么我不喜欢的话可以随意改，可以放心地交给美工改，至于逻辑代码则是编译好的我不用担心以后会被自己不小心改动了。或许这种设计与Page的Code-Behind编译有什么不同，关键就在于它强制规定了什么包含什么，包含多少个，而且这些被包含的控件的一些属性的默认值可能也在编译代码中，你看我上面的代码就没有指定<LoginForm:Submit>的value为“提交”或者“登录”，我的意思就是在编译代码中这个已经指定好了，这个指定好可能是指代码中为属性指定了默认值，甚至可能是那已经是一个派生类该派生类已经被指定了属性默认值。
2005年7月28日星期四
向导性搜索
所谓向导性搜索，就是在搜索过程中不断给用户Suggestion以及提供更多的有界输入（选项、范围）或者无界输入（文字）以不断所在范围。例如我们最常见的就是搜索结果通常会伴随着几个相关关键字，搜索引擎应该加上建议的操作让用户加上某个相关字或排除某个相关字，这样比起高级用户自己看相关字然后自己排除掉一部分（往往是排除，但你搜索目标比较偏的时候）要显得更加用户友善。
当然，我期望的向导不仅仅是这样。这里要提到我以前提出过的OO结构关字键理论，也就是对于任何一个关键字，它都有一个或者多个"基类"和非常非常多的"派生类"，至于这里"派生"的关系和变成上的is_a关系是完全一致的。例如在你搜索StarWar的时候，首先搜索引擎会尝试识别基类然后提供给你作为选择，例如让你选择Movie还是Novel，然后你选择了Movie。这时候结果还是太多，于是搜索引擎提供主要的派生类，例如那么多集StarWar的名称，然后你再做选择。
不过我也很担心向导会存在一个陷阱，就是它的没完没了，最后可能陷入一个让用户觉得我提供了那么多信息让你进行过滤和重排，结果在搜索结果第一页还是没有我要的信息。这里我仅仅说是搜索结果第一页没有需要信息而不说没有结果，因为这个问题我也考虑过，所以在我认为的向导选择中，过滤的只是占少数，更多的是重排，然和向导中输入信息相关的浮上来无关的沉下去。
当然，我期望的向导不仅仅是这样。这里要提到我以前提出过的OO结构关字键理论，也就是对于任何一个关键字，它都有一个或者多个"基类"和非常非常多的"派生类"，至于这里"派生"的关系和变成上的is_a关系是完全一致的。例如在你搜索StarWar的时候，首先搜索引擎会尝试识别基类然后提供给你作为选择，例如让你选择Movie还是Novel，然后你选择了Movie。这时候结果还是太多，于是搜索引擎提供主要的派生类，例如那么多集StarWar的名称，然后你再做选择。
不过我也很担心向导会存在一个陷阱，就是它的没完没了，最后可能陷入一个让用户觉得我提供了那么多信息让你进行过滤和重排，结果在搜索结果第一页还是没有我要的信息。这里我仅仅说是搜索结果第一页没有需要信息而不说没有结果，因为这个问题我也考虑过，所以在我认为的向导选择中，过滤的只是占少数，更多的是重排，然和向导中输入信息相关的浮上来无关的沉下去。
原来Google的PageRank Zero惩罚也是有终结的！
以前我一直想摆脱bbs.hsfz.net这个已经种了PageRank Zero惩罚的域名（我无非是在CooCooWakka留多了三个链接而已），不过今天突然发现它的PageRank竟然有5那么高哦（被惩罚之前是3）！哈哈，好开心啊，这样就可以把这个域名继续发展下去了。
订阅：
博文 (Atom)