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手上抢占到份额。
2005年8月24日星期三
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）！哈哈，好开心啊，这样就可以把这个域名继续发展下去了。
今天去Windows Update的时候发现要正版验证了
以前就的那个正版验证控件是很容易通过的，VLK版也没问题。现在它要你装个新的，然后就通不过了，以后就只能通过Automatic Update来更新而不能够通过Web来更新，真是麻烦。希望快点有人有办法解决这个。（MS还不至于敢说不允许盗版用户更新，因为那样的话一旦发生新的病毒风波Windows就更惨了。）
2005年7月27日星期三
Blogger不懂超时，但坚持不懈……
原来给足够的时间Blogger.com它帮你上传完整个Blog还是没有问题的，它虽然不懂得什么超时自动重试，但在每到达它那个超长的超时限制之前它会坚持不懈的帮你上传，呵呵……
ASP.NET 是如何让 aspx 完全编译的呢？
我以前对这个问题一直持怀疑态度，因为.NET Framework里面就有很多TemplateControl处理类和方法挂上了Parse（或Parser）的字样，不过也有挂上Compile字样的。最近我确实测试了一次它是否完全编译：
我做了一个简单的纯asp页面：
<html>
<head>
<title>Now!</title>
</head>
<body>
<div><%=DateTime.Now%></div>
</body>
</html>
然后查看它的.dll，发现它自动生成了一个Page派生类，IRequiresSessionState也自动加上了，比普通的Page类多了一些双下划线开头的东西，例如两个双下划线开头的函数：
private void __BuildControlTree(Control __ctrl)
{
__ctrl.SetRenderMethodDelegate(new RenderMethod(this.__Render__control1));
}
private void __Render__control1(HtmlTextWriter __output, Control parameterContainer)
{
__output.Write("\r\n\r\n\r\n\r\n\r\n ");
__output.Write(DateTime.Now);
__output.Write("\r\n");
}
看来编译器会把html直接放到write的部分，中的逻辑再另外处理，例如Response.Write等效于等效于直接输出。至于它是怎么生成的，我还要研究研究才知道。另外这个功能不一定完全由CodeDom提供，可能CodeDom仅仅提供编译部分。Page类理论上是通过Parse来获取aspx里面的内容，然后把它们作为控件或者纯粹write出来的html添加到自己的内部，然而这时候得到的是一个对象的实例，不是一个类。假如由我设计ASP.NET，我会考虑是否存在可能性把一个实例转化为该类的派生类，或许ASP.NET真的是这样做的。
假如要把一个实例转化为一个类，这在Java或者.NET看来都并不难。例如在.NET里面，只需要把一个实例所包含的数据全部变为初始化数据放在类的初始化代码里面就行了，至于相关信息就放到meta-data里面，这个非常容易。如果.NET真的内置实现这种功能的东西，就一定要挖掘它出来。这意味着一种把逻辑缓存到dll的可能性，它拥有比缓存到内存更长久的保存性，同时因为它再次调用时无需再次编译所以这种缓存方式的效率也是绝对一流的。
我做了一个简单的纯asp页面：
<html>
<head>
<title>Now!</title>
</head>
<body>
<div><%=DateTime.Now%></div>
</body>
</html>
然后查看它的.dll，发现它自动生成了一个Page派生类，IRequiresSessionState也自动加上了，比普通的Page类多了一些双下划线开头的东西，例如两个双下划线开头的函数：
private void __BuildControlTree(Control __ctrl)
{
__ctrl.SetRenderMethodDelegate(new RenderMethod(this.__Render__control1));
}
private void __Render__control1(HtmlTextWriter __output, Control parameterContainer)
{
__output.Write("\r\n\r\n\r\n\r\n\r\n ");
__output.Write(DateTime.Now);
__output.Write("\r\n");
}
看来编译器会把html直接放到write的部分，中的逻辑再另外处理，例如Response.Write等效于等效于直接输出。至于它是怎么生成的，我还要研究研究才知道。另外这个功能不一定完全由CodeDom提供，可能CodeDom仅仅提供编译部分。Page类理论上是通过Parse来获取aspx里面的内容，然后把它们作为控件或者纯粹write出来的html添加到自己的内部，然而这时候得到的是一个对象的实例，不是一个类。假如由我设计ASP.NET，我会考虑是否存在可能性把一个实例转化为该类的派生类，或许ASP.NET真的是这样做的。
假如要把一个实例转化为一个类，这在Java或者.NET看来都并不难。例如在.NET里面，只需要把一个实例所包含的数据全部变为初始化数据放在类的初始化代码里面就行了，至于相关信息就放到meta-data里面，这个非常容易。如果.NET真的内置实现这种功能的东西，就一定要挖掘它出来。这意味着一种把逻辑缓存到dll的可能性，它拥有比缓存到内存更长久的保存性，同时因为它再次调用时无需再次编译所以这种缓存方式的效率也是绝对一流的。
2005年7月26日星期二
Community Server 进驻 hsfz.net
已经部署好了Community Server了，暂时部署在w3.hsfz.net。因为Benny将很多我不用的站点在ISA那里封了，所以要访问必须从校内访问（其实大家都是有办法访问校内网站的吧）。
看起来这个东西很不错（在使用上），集合了Blog、论坛、图片集，而且都有本来非常有名的组件。它强调的Collaboration（协作），所以不像很多过去的同类型产品一样都是鼓励大家多注册、多发表、多回复，而是引入了比较多的Restrict（限制），例如新注册用户默认状态是在管制下的（也就是发帖要通过审核贴子才显示，我已经更改为“50贴通过审核后自动脱离管制”），Blog也不是人人都自动有一个的而是只有管理员能开Blog并指定Owner的（这非常类似现在很多IT专项Blog，必须写申请给管理员证明你是该专项爱好者才能获取Blog）。至于图片集，我还没有测试过，好像允许匿名上传。
这个东西看起来对于“大学城网上通”的一期工程或许也有些用，它有论坛也有Blog和图片集。论坛适合于普通交流，Blog则是给通过审核的专栏作家发表的地方，图片集可以用来保存上传的图片。不过这样做也有一定的风险，因为不知道做扩展和数据迁移是否容易，如果我们的二期工程需要做大规模扩展或者开发一个全新的服务系统那就不一定容易了。
另外Community Server的分层设计上也很好。它不至于走Sharepoint那种纯dll设计（我承认，做纯dll设计的话开发和调试都比较辛苦，每次都要手动重新编译，需要改动UI也是很难的），它保留了aspx（其实Sharepoint也保留了，不过是存放在数据库里面，它自己有ISAPI Filter负责虚拟路径到数据库内文件的影射），然后把UI部分留在aspx/ascx里面。然而aspx/ascx并没有任何的详细代码，只有WebControl的引用，所有WebControl都封装在dll里，至于事务逻辑就都在背后了，很符合分层要求哦。
看起来这个东西很不错（在使用上），集合了Blog、论坛、图片集，而且都有本来非常有名的组件。它强调的Collaboration（协作），所以不像很多过去的同类型产品一样都是鼓励大家多注册、多发表、多回复，而是引入了比较多的Restrict（限制），例如新注册用户默认状态是在管制下的（也就是发帖要通过审核贴子才显示，我已经更改为“50贴通过审核后自动脱离管制”），Blog也不是人人都自动有一个的而是只有管理员能开Blog并指定Owner的（这非常类似现在很多IT专项Blog，必须写申请给管理员证明你是该专项爱好者才能获取Blog）。至于图片集，我还没有测试过，好像允许匿名上传。
这个东西看起来对于“大学城网上通”的一期工程或许也有些用，它有论坛也有Blog和图片集。论坛适合于普通交流，Blog则是给通过审核的专栏作家发表的地方，图片集可以用来保存上传的图片。不过这样做也有一定的风险，因为不知道做扩展和数据迁移是否容易，如果我们的二期工程需要做大规模扩展或者开发一个全新的服务系统那就不一定容易了。
另外Community Server的分层设计上也很好。它不至于走Sharepoint那种纯dll设计（我承认，做纯dll设计的话开发和调试都比较辛苦，每次都要手动重新编译，需要改动UI也是很难的），它保留了aspx（其实Sharepoint也保留了，不过是存放在数据库里面，它自己有ISAPI Filter负责虚拟路径到数据库内文件的影射），然后把UI部分留在aspx/ascx里面。然而aspx/ascx并没有任何的详细代码，只有WebControl的引用，所有WebControl都封装在dll里，至于事务逻辑就都在背后了，很符合分层要求哦。
今天把Google AdSense装上了
在Blogger.com的控制面板见到大大个注册AdSense的标记，于是过去注册玩下，反正就算没钱也没所谓，我的Blog都是.NET有关的东西，出现的应该多数是.NET WinForm/WebForm控件广告（这是观测其它网站所得的），如果我见到好的控件我就会跑去看看，看看有没有什么优秀的地方值得我学习，或者干脆找找有没有“免费下载”，哈哈！
现在AdSense出来的还都是公益广告，可能Google还没有对我的网站做内容索引吧，那迟一点再回来看广告吧（很奇怪为什么是英文公益广告，难道我设置有问题）。
现在AdSense出来的还都是公益广告，可能Google还没有对我的网站做内容索引吧，那迟一点再回来看广告吧（很奇怪为什么是英文公益广告，难道我设置有问题）。
终于又成功发布Blog了
昨天晚上网络速度超慢，不知道干什么，发布时总是上传了一两个文件就停在那里了（Blogger.com的bot不懂得超时重试之类的东西）。今天下午尝试重新发布，估计网速没问题就没问题了吧，结果Blogger.com一直显示0%而我的ftp监视根本没显示有人登录！
这个问题我弄了一个多小时都解决不了（SFTP又总是不行，不知道为什么），于是跑去睡觉了。睡觉起来，怀疑是不是blogger.com会缓存一些有问题的目标ftp然后就根本不肯连上去，于是就断线重连。还是不行，那么难道是缓存域名？我把ftp由maxcellftp.3322.org改为maxcellblog.3322.org（暂时这两个域名IP一致而且我的ftp都接受），终于可以了。真不知道是Blogger.com太聪明懂得封ftp域名了还是它缓存一个ftp域名的IP太久了。
这个问题我弄了一个多小时都解决不了（SFTP又总是不行，不知道为什么），于是跑去睡觉了。睡觉起来，怀疑是不是blogger.com会缓存一些有问题的目标ftp然后就根本不肯连上去，于是就断线重连。还是不行，那么难道是缓存域名？我把ftp由maxcellftp.3322.org改为maxcellblog.3322.org（暂时这两个域名IP一致而且我的ftp都接受），终于可以了。真不知道是Blogger.com太聪明懂得封ftp域名了还是它缓存一个ftp域名的IP太久了。
2005年7月25日星期一
改版改版~
现在总算弄到自己的ftp了，也就能够稳定维护这个blog了，而且还有hello+picasa这样轻松的发布信息和图片的组合，真的很爽。
现在我决定把这里改版了，改为我主要的blog，而wallop则主要是继续和别人message来来往往（我觉得wallop就是这点好，是一个能够自动适应投递宽度的mail-list）。以后我会把我在其它mail-list发表的东东（机密除外）也发表一份过来这里，让更多的人能够看到我的东西：）
现在我决定把这里改版了，改为我主要的blog，而wallop则主要是继续和别人message来来往往（我觉得wallop就是这点好，是一个能够自动适应投递宽度的mail-list）。以后我会把我在其它mail-list发表的东东（机密除外）也发表一份过来这里，让更多的人能够看到我的东西：）
2005年7月22日星期五
Windows Vista!
The next version of Windows, until now referred to by its code name Longhorn, finally has an official name: Windows Vista. 1个小时之前的新闻，刚刚碰巧进入news.google.com的美国版看到的。Vista是个好名字，强调View的意思，而且是Beautiful的，并且也是长远的或者广阔的View，并且这和Longhorn花费那么多功夫在Vision上也非常相配，不知道这个词是否能够迅速飙升为常用词（现在搜索vista还是一些都不相关的信息）。
2005年7月15日星期五
2005年7月14日星期四
ExileBoy
Exile，我希望用黑色加适当的高光作为主色调，好像Windows Server Family那样（见过Windows 2003的安装界面吗？就是Windows XP的变成黑色为主调，但保留高光），同时用活跃的成色作为突出色调。我也比较喜欢"葡萄式"广告里面那个成色的小人，所以决定捏一个差不多的做为Exile的公仔，然后就叫做Exile Boy。
其实我一直很想画四格漫画，不过又没什么机会。我喜欢很久很久以前Windows 95/98配的那个Microsoft Chat自动生成漫画的功能，因为仅仅Windows NT 4能够在IIS上加载Chat Server，所以应该很多人都没用过Microsoft Chat。我解释一下他的漫画功能吧，输入时还是像那个年代的普通聊天室一样输入文字，或则选择一些文字描述的动作。如果是文字形式查看，那就和普通Web聊天室没什么不同。如果选择漫画版式，然后你从8个主角中选一个代表你，那么现时的将是4格漫画。大概每两三条对话就集中到一格吧，这一格中出现了说话的角色，然后头上有说话的冒泡，如果你选择了动作，那就是对应动作，不选择动作的话也有些各种各样的小动作吧，反正那个年代的程序已经懂得避免出现张张差不多的图片已经算不错的了。
我现在就是想试一下用.NET所谓的GDI+，做一个ExileBoy的漫画制作工具：
1.这个工具能够轻松制作不同高难度动作的ExileBoy，我希望好像3D软件那样我确定ExileBoy的关节点的位置，然后软件就能够做出它的外形，当然ExileBoy仅仅是2D外形。
2.这个工具内置若干绘图模块，而且不是简单的把某一个东西贴出来，而是能够由创作者定义一些东西而工具本身又随机创作一些东西，反正就是要有一定的随机性。
3.这个工具要支持插件。
还有很多其它的想法，例如要支持图层，而ExileBoy要能够跨图层存在等（这要视觉效果才更好），不过要慢慢做。看看吧......我要先完成现在Quickling为主的Web项目，才有时间来做这个，要慢慢等咯。不过之后我会把ExileBoy加到Web上面去：）
其实我一直很想画四格漫画，不过又没什么机会。我喜欢很久很久以前Windows 95/98配的那个Microsoft Chat自动生成漫画的功能，因为仅仅Windows NT 4能够在IIS上加载Chat Server，所以应该很多人都没用过Microsoft Chat。我解释一下他的漫画功能吧，输入时还是像那个年代的普通聊天室一样输入文字，或则选择一些文字描述的动作。如果是文字形式查看，那就和普通Web聊天室没什么不同。如果选择漫画版式，然后你从8个主角中选一个代表你，那么现时的将是4格漫画。大概每两三条对话就集中到一格吧，这一格中出现了说话的角色，然后头上有说话的冒泡，如果你选择了动作，那就是对应动作，不选择动作的话也有些各种各样的小动作吧，反正那个年代的程序已经懂得避免出现张张差不多的图片已经算不错的了。
我现在就是想试一下用.NET所谓的GDI+，做一个ExileBoy的漫画制作工具：
1.这个工具能够轻松制作不同高难度动作的ExileBoy，我希望好像3D软件那样我确定ExileBoy的关节点的位置，然后软件就能够做出它的外形，当然ExileBoy仅仅是2D外形。
2.这个工具内置若干绘图模块，而且不是简单的把某一个东西贴出来，而是能够由创作者定义一些东西而工具本身又随机创作一些东西，反正就是要有一定的随机性。
3.这个工具要支持插件。
还有很多其它的想法，例如要支持图层，而ExileBoy要能够跨图层存在等（这要视觉效果才更好），不过要慢慢做。看看吧......我要先完成现在Quickling为主的Web项目，才有时间来做这个，要慢慢等咯。不过之后我会把ExileBoy加到Web上面去：）
2005年7月2日星期六
Tag with Map
能够好像flickr那样使用Tag，但Tag上去的不仅仅可以是一个关键字，而可以是一个范围，或许是Map上的一个范围，那样会怎样？想象一个支持Tag的Google Maps，呵呵......
最近喜欢模糊运算，所以有点拒绝不是0就是1的东西。如果你有时间去看看模糊运算的有关法则，你就会发现它是我们现在学习的离散数学运算的广义定义。例如x AND y就是max{x, y}，那么对于0.5 AND 0.8来说结果就是0.8了。所以对于Tag，我也不喜欢它Tag死一样东西，而是最好说明一样东西对这个Tag的属于程度，取值范围是[0,1]。
而Tag with Map就肯定会是这样--不可能有两个Tag准确的放到同一个Lat/Long(经度/纬度)上，那么一个Tag就应该是附设一个范围。或者是若干个Tag就连成一个二维的曲线，至于曲线的高度则由插值决定......嗯......看起来好像很复杂，我只是觉得一个好的算法会运算得很好，让人在模糊集合中很快地找到他要找的东西，并且是排好序的。（模糊集合的意思是，一个元素不一定100%属于或者不属于这个集合，而可能是0.6属于这个集合。）
最近喜欢模糊运算，所以有点拒绝不是0就是1的东西。如果你有时间去看看模糊运算的有关法则，你就会发现它是我们现在学习的离散数学运算的广义定义。例如x AND y就是max{x, y}，那么对于0.5 AND 0.8来说结果就是0.8了。所以对于Tag，我也不喜欢它Tag死一样东西，而是最好说明一样东西对这个Tag的属于程度，取值范围是[0,1]。
而Tag with Map就肯定会是这样--不可能有两个Tag准确的放到同一个Lat/Long(经度/纬度)上，那么一个Tag就应该是附设一个范围。或者是若干个Tag就连成一个二维的曲线，至于曲线的高度则由插值决定......嗯......看起来好像很复杂，我只是觉得一个好的算法会运算得很好，让人在模糊集合中很快地找到他要找的东西，并且是排好序的。（模糊集合的意思是，一个元素不一定100%属于或者不属于这个集合，而可能是0.6属于这个集合。）
2005年7月1日星期五
2 Ways Thinking In Ajax
至今来看，ajax的模式有两种，就是Google模式和.NET模式。
Google模式就是服务器仅仅接收xml和返回xml，其他一切工作都是客户端做。开发的重点在于客户端，然后xmlhttp仅仅用于发送和接收数据，服务器端则是仅处理数据的逻辑，如果把xmlhttp看作"透明代理"的话，那么这个设计就是属于客户端设计了。
.NET模式则刚刚好相反，虽然.NET说是把WebForm当作WinForm开发，但它不是透明掉服务器端而是透明掉客户端，为什么这样说呢？在你不需要JS的时候，你也可以当它是透明掉服务器端，当你需要JS的时候，你就会觉得它是透明掉客户端了--它没有考虑过你要大量运用JS的情况。
Google模式看上去很容易实现，但当你实际操作的时候你就会发现debug的痛苦程度！我甚至用js封装过专门的ajax库了，这个库包括自动创建一个layer浮在最顶动态更新调试信息（或者说是trace），但还是觉得非常痛苦！
.NET模式的痛处则在于JS--用到ajax怎么可能不是大量JS，而这是.NET要避免的问题--.NET希望页面内的所有元素都不是全局存在而是局部存在的，这样的设计才是正交的，如果所有的逻辑都是拥有全局影响的权利，那么.NET建立的一切稳定基础都会被打破，然而JS正是这样做着。.NET成功把HTTP和HTML都对象化了，这依赖于以前ASP就有的Request/Response模型和XHTML DOM模型。然而JS它无法对象化，除非我们能够创造一个JS CodeDOM。
现在Ajax的未来落在了Avalon的身上，Avalon本身就是允许开发者用XAML描述界面并且用.NET描述逻辑，这对于习惯XHTML+JS的Web开发者来说是件好事。然后它也做到了客户端和服务器端语言的统一，而且是统一的CodeDOM。而且MS可以采取一种很好的做法来让.NET开发者适应，就是开发的时候服务器端代码和客户端代码还是混边，还是当作没有B/S之分，然后把你希望在客户端执行的函数前面加一个例如[ClientScript]标记那么该段代码就会在客户端运行，那时不是很美妙的事情？而且这也符合MS的SmartClient战略哦！
Google模式就是服务器仅仅接收xml和返回xml，其他一切工作都是客户端做。开发的重点在于客户端，然后xmlhttp仅仅用于发送和接收数据，服务器端则是仅处理数据的逻辑，如果把xmlhttp看作"透明代理"的话，那么这个设计就是属于客户端设计了。
.NET模式则刚刚好相反，虽然.NET说是把WebForm当作WinForm开发，但它不是透明掉服务器端而是透明掉客户端，为什么这样说呢？在你不需要JS的时候，你也可以当它是透明掉服务器端，当你需要JS的时候，你就会觉得它是透明掉客户端了--它没有考虑过你要大量运用JS的情况。
Google模式看上去很容易实现，但当你实际操作的时候你就会发现debug的痛苦程度！我甚至用js封装过专门的ajax库了，这个库包括自动创建一个layer浮在最顶动态更新调试信息（或者说是trace），但还是觉得非常痛苦！
.NET模式的痛处则在于JS--用到ajax怎么可能不是大量JS，而这是.NET要避免的问题--.NET希望页面内的所有元素都不是全局存在而是局部存在的，这样的设计才是正交的，如果所有的逻辑都是拥有全局影响的权利，那么.NET建立的一切稳定基础都会被打破，然而JS正是这样做着。.NET成功把HTTP和HTML都对象化了，这依赖于以前ASP就有的Request/Response模型和XHTML DOM模型。然而JS它无法对象化，除非我们能够创造一个JS CodeDOM。
现在Ajax的未来落在了Avalon的身上，Avalon本身就是允许开发者用XAML描述界面并且用.NET描述逻辑，这对于习惯XHTML+JS的Web开发者来说是件好事。然后它也做到了客户端和服务器端语言的统一，而且是统一的CodeDOM。而且MS可以采取一种很好的做法来让.NET开发者适应，就是开发的时候服务器端代码和客户端代码还是混边，还是当作没有B/S之分，然后把你希望在客户端执行的函数前面加一个例如[ClientScript]标记那么该段代码就会在客户端运行，那时不是很美妙的事情？而且这也符合MS的SmartClient战略哦！
2005年6月6日星期一
Wiki-spam 与 Google AdWords
在开放提交数据的系统，例如wiki，总是无法拒绝别人用bot提交大量无用、无关或者误导性数据，这是最头痛的一个问题。不要觉得Google懂得对作弊网站使用PageRank Zero惩罚或者wiki自身有一定anti-spam技术就行了，当spam发展到有一定智能??像Google AdWords那样的"针对性投放"的智能，那wiki就会麻烦了！
暂时来说，Google AdWords允许你买一个词，然后在用户搜索这个词的时候就投放你的链接广告，同时按照投放收费，例如Nike就可以买下shoe这个词作为AdWords（不过Nike买下竞争对手的名字作为AdWords是否合法这个问题就很有争议性）。那么我们可以按照同样的原则作一个spam-bot，例如就去Wikipedia等大型wiki上面直接进入[[shoe]]这个WikiName，然后在最后直接tag上Nike的广告，然后开一个[[Nike]]的WikiName也可以，如果竞争对手的名称也是WikiName那就也过去tag上Nike的名称（介绍为竞争对手的竞争对手），这样的内容就算肉眼看起来也绝对不spam啊你觉得在[[shoe]]里面介绍Nike或者在竞争对手的WikiPage里面说它的主要竞争对手是Nike算是spam吗？
暂时来说，Google AdWords允许你买一个词，然后在用户搜索这个词的时候就投放你的链接广告，同时按照投放收费，例如Nike就可以买下shoe这个词作为AdWords（不过Nike买下竞争对手的名字作为AdWords是否合法这个问题就很有争议性）。那么我们可以按照同样的原则作一个spam-bot，例如就去Wikipedia等大型wiki上面直接进入[[shoe]]这个WikiName，然后在最后直接tag上Nike的广告，然后开一个[[Nike]]的WikiName也可以，如果竞争对手的名称也是WikiName那就也过去tag上Nike的名称（介绍为竞争对手的竞争对手），这样的内容就算肉眼看起来也绝对不spam啊你觉得在[[shoe]]里面介绍Nike或者在竞争对手的WikiPage里面说它的主要竞争对手是Nike算是spam吗？
订阅：
博文 (Atom)