2005年12月31日星期六

ASP.NET 2.0 实在太强了!

.NET Framework 1.x设计很优秀,但是很多东西都还没有,只能借用.NET Framework写自己的Framework然后再用。好象.NET Framework给你不少东西,但实际上你自己不开发自己的Framework那么.NET Framework根本做不了大项目。例如Sharepoint的WebPart架构是套很好的东西,但是只有MS自己用得爽,不装Sharepoint你就不能用。

不过ASP.NET 2.0则好很多,它吸收了不少1.x上面MS或者第三方Framework的东西,然后都放到2.0里面去了。例如WebPart现在可以直接用了,虽然背后的东西和Sharepoint的是不同的,但在现实效果上已经和Sharepoint的无异;DNN的Provider的设计思想也用上了,所有后台的东西都通过相关的Provider进行连接。

现在用ASP.NET 2.0开发,真的是基本上不用设计者花时间在设计用户数据库与用户类的封装、门户页面的可拖动元素Script之类的事情上,这些麻烦的事情都能够用系统的来完成(除非你有很特殊的要求,系统功能已经有比较良好的扩展性)。那么用ASP.NET 2.0开发就真的进入了比创意的阶段了——你不能再说别人懂做可拖放门户页或者别人的用户数据库设计得好,然后你做不到,所以你的好创意无法吸引客户。这也让进入Web 2.0的竞争更加激烈,因为技术已经变得简单,只有好的创意才能够吸引更多用户,否则再有技术也无法在ASP.NET 2.0中给你那么大一堆服务器中突围而出。

2005年12月25日星期日

只许邀请不许注册——确保用户是你忠实Fans的有效方法

Orkut是这种方法的首先探索者,当然它后来遇到了所有SNS现在都遇到的问题,那就是一个人进入SNS必然经历的三个流程:被邀请、邀请别人、不再使用。这让SNS的用户使用量看起来有点像只有一个波峰的机械波,不断向外扩散,但是所有人经历了一次波峰后就不再活跃了。对于这种现象我暂时无法解释,我的建议只是绝对不要做单纯的SNS,一定要配合上用户会长期使用的功能。

Gmail是第二个这样的产品,不过它很成功。对于想要Gmail的人来说,开头能够弄到一个Gmail实在不容易,所以会把它看作很有价值的东西。到现在Gmail泛滥了,但是如果你是被邀请用Gmail的,你肯定会经历被邀请者极力说服你用Gmail这一过程(例如你会说“我现在的163.com也有2G而且用起来不错”),而且如果最终你接受了邀请,那种明在例如Gmail好还是163.com好的这场论战中你的朋友(极可能是一位GFans)赢了,然后你使用上了Gmail,还被慢慢同化为一位GFans。

总的来说,邀请机制虽然风险很大(如果用过的人都不觉得很好而不愿意努力推广),但是一旦成功的话,任何邀请者都变成了你的义务推广者,免费为你推广你的服务。至于如何控制邀请的数量(是好像Orkut那样的无限邀请,还是Gmail这样的有限邀请,或者Wallop那样的需要申请的邀请),这个我还在研究。

2005年12月22日星期四

Office 12, menu byebye?

在Goowy听一个名为TWiT(this WEEK in TECH)的Podcast,听到某位podcaster说他的Palm LifeDrive已经Crash了,另外一位podcaster则说他的是TX,狠狠的打击了我买LD的信心而让我决心买TX + 1G SD,呵呵……

好,说正题,TWiT说道Office 12将没有菜单,取而代之的上下文项目,现给大家一个感性认识,有关的PCMagazine.com的文章在这里:
http://www.pcmag.com/article2/0,1895,1888081,00.asp
或者可以仅看截图你就明白新的上下文项目是怎么回事:(留意原本菜单栏的地方,不再是固定的菜单,每张截图上那个地方出现的项目都不同,是上下文相关的)http://www.pcmag.com/slideshow/0,1206,l=165570&pg=0&s=1739&a=165566,00.asp

大概就是这样的:原本菜单栏的地方不再有固定的菜单栏,而是上下文相关的菜单项目,如果你当前选中的是文本,出现的就是文本格式啊、缩进啊、对齐啊之类的玄想;如果你当前选中的是表格,出现的则是自动套用格式;如果当前在画布上,则可能出现插入文本框、插入直线等。

实际上我觉得这是一个从Computer Operator到Service Comsumer的转变。真正的Service就应该是这样的:持久稳定的,随传随到的,但又绝对不影响消费者的享用,本来需要亲自做的东西你只需要想一下或者说一下那就完成了。正如一个好的Waiter,首先必须随传随到啦,在觉得你需要服务的时候主动出现(例如你不小心把杯子摔到地上了),在你需要主意或者行为的时候出现上下文选项甚至是向导式对话(例如你说“我们再点一个青菜吧”,他会告诉你什么青菜好吃,接着你会问“一个例有多少,够12个人吃吗”,他要比划给你看或者告诉你够不够),最后就是在你不需要他的时候他最好不要出现更不要打扰(不要跑上来问我是否参加“参观体验改进计划”)。这就是Service??我不需要主动理解Service的规则,或者是Workflow这样严格的东西,我只需要按照普通的思维或者以后的其他Service使用习惯来做,然后Service应该为我提供良好的体验,在我不是Service Provider的时候我完全不需要了解Service的细节,必要的时候就在Service开头提供Agreement来确认双方法律责任就是了。

未来的UI,应该逐渐趋向Smart和Rich。Smart不是任何一个Programmer能够做到的,除非出现一个那样的引擎(类似Text to Speech那样的转换引擎),能够让用户输入他的指示,然后自动寻找软件中能够匹配的操作。Rich则主要通过类似Flash这样的东西来解决,特别是对于现在还很Thin的WebClient来说。

2005年12月21日星期三

谁说Google首页页面简介不搞门户的?!

今天打开Google首页,发现原本在www.google.com/ig的"I Google"已经迁移到首页并且整合了原本的搜索输入框。(不一定每一个人都能够看到,可能需要Google Account的登录,甚至以前关注过ig的用户才能直接看到。点击“常规主页”能够回到原版Google。)

以前一直说Google不搞门户,完全靠搜索。对比门户堆满内容的首页,Google的首页只有简介,只有一个输入框和几个按钮。但是现在Google也跑去搞门户了,不过当然是所谓的Web 2.0门户??不通过编辑而通过聚集微内容来组织内容。看来这是未来发展的方向,至少Live.com和ig都代表着这个方向。现在校园内都是老式门户和论坛,少数地方提供Blog,更少数地方提供SNS式的交友与联谊网站,如果现在开始做Feed Portal投放校园肯定有出路!

Feed Portal之后是什么?然后又从Portal回归Search?那个已经出现了??现在已经出现基于Feed的搜索,Feed Portal本身就已经整合了搜索Feed的功能,虽然暂时搜索Feed的结果好像比较让人郁闷,因为几个关键字得到的一个Feed往往是因为里面的一篇或者几篇东西符合搜索条件,这和你愿意长期订阅一个Feed根本没有任何关系,况且现在Feed的独立性也太强,唯一的关联性就是多个Entry在一个Feed内。可能要等TrackBack或者类似技术推广开来,能够建立类似PageRank那样的基于Feed之间关系的Feed价值评估,才能够建立完善的Feed搜索。

之后会是什么?Web最大的问题我觉得就是不能Push只能等用户来Pull,要能够Push又一定要装客户端,这是让人最不爽的地方。Email或者SMS算是一种Push的手段,但是未来是整合到Web,还是Web发展一种专用的Push方式,这个就难说了。别以为Web不能Push,就好像我们以前不懂得将XmlHttpRequest用于AJAX一样,现在我们也能在用户的浏览器上开一个隐藏Window/Frame来Push啊,不过要求用户不关浏览器,将来这方面可能能够获得突破,特别是XAML和XUL等的发展。Live.com加上Longhorn的Sidebar理论上就能够实现Push了,不过以来的就是MS。

2005年11月11日星期五

Google Desktop Search Enterprise 需要 Google Search Appliance?

在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月9日星期三

百万网站

不知道这算不算病毒广告,不过应该挺有效,起码我都参与传达了(不过地址不使用链接):
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.usflickr,到Coo介绍我看的那个类似wiki的可以用于Collaberate的网站,再到最近发现的writely.comnumsum.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首先要做的核心,它不会像制作一般论坛那样,受到表情符号、用户头像等一系列琐碎麻烦问题的困扰,因为这一切都属于应用而不属于核心,但核心的设计就是要兼容这一切将来可能要添加的应用,所以需要花比较长的时间去做设计。

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,很快他们就都主动把对方加为自己的好友了,于是就能够直接通信了。

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肯定不会为它当前领域及纵向相关的潜在领域提供开发工具。这句话看起来也不假,呵呵……

2005年10月22日星期六

发现了一个很好的Wiki:MoinMoin!

http://moinmoin.wikiwikiweb.de

看起来很不错的东西,自动根据客户端语言来显示,用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度空间的理论,只要信息足够的多,计算机可以通过组合信息得出任何人类已知甚至人类未知的事情。这个如果在那个Googl­e在2014年垄断传媒界的例子里,会是很好的事情,因为每个人贡献的信息可以选择Private还是Public,而Google的EPIC能够根据Publ­ic信息自动组合出或者说是写作新闻。然而实际上,正如在6度空间理论中你永远不可能知道你是否出于某条关键链上,你现在所贡献出来的一点点信息也可能存在于某­条非常重要的推导链上,然后一旦这个推导完成,到底你做了什么你也不知道。正如《Google成功的7堂课》里面提到的一个案例,某人失踪了10年(至少他的家人如此认为),一直都找不到他的下落,最后是在Google间接搜索到他出现在10年前某一个州的车祸伤亡名单上,这才确认他已经死了。我们根本不知道随随便便­说的一两句话,可能导致什么,呵呵……

2005年9月10日星期六

可编程样式表

Coo曾经跟我说过,如果CSS里面能够自定义颜色常量(例如Red=#FF0000就是一个颜色常量),那就好了(那意味着你可以定义一个ContentBo­rderColor和一个HeadBorderColor,可能当初它们的值一样,当你需要修改其中一个的时候你就不需要小心的查找和替换以免替换多了或者替换­少了)。Coo的这个想法暂时只有通过xslt实现,MSN Messenger的聊天记录就是通过xml+xslt成仙的,而其中就有很多样式是通过自定义常数一次声明的(通过声明自定义参­数)。

我最近在弄一个东西,也发现如果样式表支持可编程那会好很多。例如我在一个地方使用了font-family列表,但是如果浏览器在采用font-family­上的后备字体显示时,我就希望padding等属性有一定的修正,但这个暂时做不到。再举一个例子,例如我设计一个ASP.NET控件,而它内部包含一个子元素­,我希望这个子元素的padding是整个控件的padding加上1px(也就是"继承"且"运算"),但这也是无法通过样式表编程做到的,暂时只能够在AS­P.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,又能够自动组织和提供用户感兴趣的信息。

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的,看来以后地图也越来越廉价了。

2005年9月1日星期四

游戏年龄与实际年龄

根据我多年的观察,一个人的游戏年龄基本上是与实际年龄无关的,并不会因为实际年龄大而游戏年龄增长得快。无论是像我这样从小学开始玩PC Game还是好像我的一些同学那样高中甚至大学才有比较多时间接触PC Game,实际上开头的玩法都总是单调和追求表层刺激的,而需要等游戏年龄增长才能够理解游戏的更深层次玩法和艺术价值的一面。

举一个最简单的例子,例如赛车游戏:(这个实例不包括在现实生活中熟悉车辆的人士)

对于一个游戏年龄低的人来说,他追求的就是最表层的刺激,例如视觉效果和速度感,无论是当年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的霸道型转变,这是否暗示着这时企业壮大和不断增加垄断领域的必经之路?

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手上抢占到份额。

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获得了不少订单,足够受欢迎了。

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为“提交”或者“登录”,我的意思就是在编译代码中这个已经指定好了,这个指定好可能是指代码中为属性指定了默认值,甚至可能是那已经是一个派生类该派生类已经被指定了属性默认值。

2005年7月28日星期四

向导性搜索

所谓向导性搜索,就是在搜索过程中不断给用户Suggestion以及提供更多的有界输入(选项、范围)或者无界输入(文字)以不断所在范围。例如我们最常见的就是搜索结果通常会伴随着几个相关关键字,搜索引擎应该加上建议的操作让用户加上某个相关字或排除某个相关字,这样比起高级用户自己看相关字然后自己排除掉一部分(往往是排除,但你搜索目标比较偏的时候)要显得更加用户友善。

当然,我期望的向导不仅仅是这样。这里要提到我以前提出过的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的可能性,它拥有比缓存到内存更长久的保存性,同时因为它再次调用时无需再次编译所以这种缓存方式的效率也是绝对一流的。

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里,至于事务逻辑就都在背后了,很符合分层要求哦。

今天把Google AdSense装上了

在Blogger.com的控制面板见到大大个注册AdSense的标记,于是过去注册玩下,反正就算没钱也没所谓,我的Blog都是.NET有关的东西,出现的应该多数是.NET WinForm/WebForm控件广告(这是观测其它网站所得的),如果我见到好的控件我就会跑去看看,看看有没有什么优秀的地方值得我学习,或者干脆找找有没有“免费下载”,哈哈!

现在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太久了。

2005年7月25日星期一

改版改版~

现在总算弄到自己的ftp了,也就能够稳定维护这个blog了,而且还有hello+picasa这样轻松的发布信息和图片的组合,真的很爽。

现在我决定把这里改版了,改为我主要的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,我希望用黑色加适当的高光作为主色调,好像Wind­ows 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+,做一个Exile­Boy的漫画制作工具:
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,我也不喜欢它Ta­g死一样东西,而是最好说明一样东西对这个Tag的属于程度,取­值范围是[0,1]。

而Tag with Map就肯定会是这样--不可能有两个Tag准确的放到同一个L­at/Long(经度/纬度)上,那么一个Tag就应该是附设一­个范围。或者是若干个Tag就连成一个二维的曲线,至于曲线的高­度则由插值决定......嗯......看起来好像很复杂,我­只是觉得一个好的算法会运算得很好,让人在模糊集合中很快地找到­他要找的东西,并且是排好序的。(模糊集合的意思是,一个元素不­一定100%属于或者不属于这个集合,而可能是0.6属于这个集­合。)

2005年7月1日星期五

2 Ways Thinking In Ajax

至今来看,ajax的模式有两种,就是Google模式和.NE­T模式。

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­之分,然后把你希望在客户端执行的函数前面加一个例如[Clie­ntScript]标记那么该段代码就会在客户端运行,那时不是­很美妙的事情?而且这也符合MS的SmartClient战略哦­!

2005年6月6日星期一

Wiki-spam 与 Google AdWords

在开放提交数据的系统,例如wiki,总是无法拒绝别人用bot­提交大量无用、无关或者误导性数据,这是最头痛的一个问题。不要­觉得Google懂得对作弊网站使用PageRank Zero惩罚或者wiki自身有一定anti-spam技术就行了­,当spam发展到有一定智能??像Google AdWords那样的"针对性投放"的智能,那wiki就会麻烦­了!

暂时来说,Google AdWords允许你买一个词,然后在用户搜索这个词的时候就投­放你的链接广告,同时按照投放收费,例如Nike就可以买下sh­oe这个词作为AdWords(不过Nike买下竞争对手的名字­作为AdWords是否合法这个问题就很有争议性)。那么我们可­以按照同样的原则作一个spam-bot,例如就去Wikiped­ia等大型wiki上面直接进入[[shoe]]这个WikiN­ame,然后在最后直接tag上Nike的广告,然后开一个[[­Nike]]的WikiName也可以,如果竞争对手的名称也是WikiName那就也过去tag上Nike的名称(介绍为竞争­对手的竞争对手),这样的内容就算肉眼看起来也绝对不spam啊­你觉得在[[shoe]]里面介绍Nike或者在竞争对手的­WikiPage里面说它的主要竞争对手是Nike算是spam­吗?

2005年6月3日星期五

Search Inside!

人类对太空的探索比对地球内部的探索还要多,因而对太空的了解也­比地球内部多,可能是因为了解外部比了解内部要更容易。

在MyWallop上面见到wm说雨伞不见了竟然还有用Goog­le Desktop Search来搜索一下的冲动,我觉得这也挺有意思。我们天天用­Google搜索外界的信息--我们要的技术资料、新闻、图片,­还用Gmail搜索邮件,但是我们对内部信息却常常已往并且无法­搜索——你还记得两三年前看过的一份技术资料是在哪本技术书上面­吗?你还记得这本技术书现在在你的哪个书柜的哪层吗?

从暂时的技术含量来看,内部搜索基本上是不可能实现的,因为要对­内部的物理存在的事物进行Index是非常困难的(之前提到的D­VD Indexer则已经是最容易实现的一个方面),而这暂时只能靠­人手录入,或者录入的自动化程度很低(DVD Indexer能够完全实现自动化,仅仅是你再刻碟后运行一下就­完成索引,那已经是最好的事情了),这可能是在此领域一直无法发­展的原因。

2005年5月16日星期一

DVD Indexer

由于WM和Piggest这样的eMuler & DVD Burner经常大量下载又经常进行"硬盘解放运动",所以我想­做一个DVD Indexer。

所谓DVD Indexer,就是能够帮你刻录的DVD进行文件索引的一个软­件,索引放在硬盘上或者发布到网站上,数据量尽量少,但又要保证­搜索文件时的方便。这个DVD Indexer进行的索引包括3个方面:
1.目录和文件名索引:对所有目录名和文件名进行索引,这是最近­本的工作。
2.原数据或全文索引:对于txt、doc、pdf等可以转换为­纯文本的文件进行全文索引,对于mp3、avi、doc等有原数­据(meta-data)好像P2P软件那样作原数据索引。
3.用户备注索引:用户可以针对目录和文件再写备注自行作索引。

现在最关键的问题是,数据量的大小。理论上好像P2P软件那样,­仅作meta-data和hash索引是很小的,所以我们对部分­文件加上全文索引也应该不会太大。不过对于发布到网站的事情(这­可能会让一些warez的网站感兴趣),就不一定足够小了。(详­细索引数据怎么分布式或集中式存放,详细要参考P2P软件。)

2005年5月7日星期六

关于模拟游戏和Spore

Will Wright,也就是Maxis的设计师、sims之父,提出了­个代号Spore的模拟游戏。关于这个游戏的资料,GameSp­y的可以看看这里:
http://www.gamespy.com/articles/595/595975p1.html
中文方面,有TLF的一些文章:
http://webtlf88.eastgame.net/read.php?tid=650329
http://webtlf88.eastgame.net/read.php?tid=648131
http://webtlf88.eastgame.net/read.php?tid=648025

反正游戏的大意就是,你从一个刨子(Spore)开始创造生命,­可以定义它的各种生物特性,然后随着它从海洋攀上陆地,从部落形­成城市,每一次你都可以为它添加更高级/复杂的生物特性。与此同­时,你的生物的进化也需要不断的击败其他的生物,直到发展太空技­术侵略其他星球侵略其他星系。

这个游戏听起来非常有趣,因为模拟游戏现在最需要突破的一个地方­就是模拟的随机性,因为以前的模拟游戏中Player往往很容易­从游戏中归纳出游戏的规律,例如Simcity中如何布局公共设­施才能充分利用,或者Sims中如何保持一个人的各种状态尽量高­,然后就按照这样玩,甚至大家交流经验。这样下去,Player­对游戏内部计算的了解就很快趋向于Designer,游戏的可玩­性就降低了。解决方案最好就是,增加游戏的复杂度,增加随机情况­,复杂到就算Designer知道计算方法但是人脑本身无法对如­此复杂的情况进行推算,于是这个游戏便得更耐玩。(当然,随机度­不是可以随意增加的,整个游戏必须有一种内部的逻辑体系,就好像­科幻/奇幻小说一样,虽然有些地方和现实不同,但是内部逻辑不相­互矛盾,内部特点的逻辑严密,相互推理成立。)

虽然不知道Spore什么时候出现,但是我在想一个更坏的主意?­?如果有一个游戏不断给Player希望但是又把Player向­另外一个方向拉,这就更爽了(站在Designer的角度看),­哈哈!例如现在号称很自由的一些D&D和RTS,或者我们就说B­lack & White(善与恶),我们就讨论这个游戏中很多事情Playe­r都可以选择善与恶两种做法??对于别的神属下的村子无论你是用­你的神力去帮助他们还是破坏他们都会让他们减少对原来的神的信仰­增加对你的信仰,但无论如何,你在游戏中实行一个操作的时候你对­游戏内部的逻辑推理很明确、你对你的目标很明确,所以你的操作的­方向性也很明确,结果只存在成效大小之分。然而我的理念就是,例­如在Spore中,你努力创建一个热爱和平的种族,努力让他们和­其他种族和谐共处,但讽刺的是游戏中你按这个思路去发展你的种族­的结果是你的种族最后变得像蝗虫一样,他们必须不停地从一颗星转­移到另一颗星,然后消耗尽上面的资源,然而最重要的是这一切均符­合这个游戏的“内部逻辑推理”(千万别忘记我上面说的内部符合逻­辑的重要性)。

总而言之,我有个真正的Game Plays Man的想法,而不仅仅是NFS(极品飞车)里面的Catch-­up机制(你的车越快对手就越快,反之亦然,总之你很快很快了只­要稍慢就给对手超,你很慢很慢了对手也只是在你前面给你追上去的­希望)。就好像一个很坏的DM(GM)一样,总是给希望给机会P­layer向他希望的方向引导游戏,然后告诉Player实际上­你所做的一切刚刚好让你背离了你的目标,哈哈!

2005年5月1日星期日

做个Stealth Meter以敌对搜索引擎怎样?

CooFisher看起来不错,不过我想做个相反的东西——S­tealth Meter——输入你的个人信息,又或者其它你想保密的信息(集­合),然后看看能否躲过搜索引擎。

首先需要强调的是,输入的信息必须是关于目标的多个方面的。如果­你只输入Cat,就算网上没有任何关于关于我的这个用户名的信息­,还是会返回很多结果。必须在输入Cat,以及我的生日、城市等­更多信息后,如果仍然能够躲过搜索引擎,那才叫做Stealth­。

其实关于逃避搜索引擎的事情,我注意了很久了。Benny曾经说­过,很佩服师大计算机系的一个教授,网上无论如何搜索,都找不到­他的电话甚至是email。这事情让我觉得在网上隐身也是一种能­力。

今时今日的搜索引擎之能够搜索文本记载的东西,但已经顶得上以前­的任何国家图书馆/档案馆了,谁也不知道以后还会有什么现在军用­的技术变成民用,例如指纹和声纹的搜索——或许你以后能够通过一­段叫床声搜索AV添,who knows...

所以我觉得如果可能的话,就利用meta-search(源搜索­)引擎的技术,只不过把它反过来用,制作一个stealth meter。原本meta-search是将搜索内容提交给各大­搜索引擎搜索,然后根据各大搜索引擎的结果进行综合处理返回自己­的搜索结果以及排名的。而反过来用的话,那就是我们不再关注如何­正向排名,而关注反向排名,排得越后越好,最好就根本不在结果上­。以后随着搜索技术的发展,这个Stealth Meter也要与时俱进,不多更新新的搜索功能。当然,Stea­lth Meter不应该仅仅告诉用户你在哪里泄密了,最好还能建议用户­,你在哪些方面比较容易泄密,你需要注意哪些地方填写/发布的资­料。