2007年9月21日星期五

Binary Choice & reCAPTCHA

有些时候我们面临binary choice,也就是二元选择,的时候我们会认定只能选一个,因此必须牺牲另外一个,如果无法明确区分两者轻重,这将是一个极为痛苦的选择。不过我最近在读李中莹的《重塑心灵》时发现,原来我们应该积极去考虑如何能够两全其美,而不是被迫接受binary choice。

举个例子,为了防止有人使用bot连续请求某些web资源,我们可能引入CAPTCHA,也就是通常所见的验证码,以确认请求是真实的。通常我们也就默认了,越高级别的安全要求,就必须付出越多的代价,然而一个叫做reCAPTCHA的服务却不这样认为,至少它认为为提高安全性所付出的性能代价能做点别的有益的事情。

如果一般的验证码一样,reCAPTCHA也是提供一组处理过的英文字母,要求用户识别并输入。不过reCAPTCHA并不直接以零售模块形式嵌入你的站点,而以web2.0流行的API方式免费提供,你可以使用它的API为你的站点中需要的位置加入验证码。可能你会问,reCAPTCHA这样做有什么好处,因为它提高了你的站点安全性,却自己付出了性能代价,难道它在验证码下面显示一段广告?嗯……这是常人的思维,确实有很多web2.0服务通过附带广告盈利,不过reCAPTCHA可是Carnegie Mellon University的项目,所以不可能有广告的。一所大学完全出于计算机安全的研究提供免费的CAPTCHA服务?也不是,其实Carnegie Mellon University在大量扫描书籍,同时利用CAPTCHA提交者做人肉OCR。这时候就想通了吧,CAPTCHA虽然占用了计算机资源的同时,也占用了人的大脑资源,然而reCAPTCHA这个项目成功的让CAPTCHA提交过程中的资源浪费变成有效的资源消费。

根据reCAPTCHA的介绍,每天有六千万个CAPTCHA被人们识别,其中每一个大概消耗10秒钟时间,然而将这些工作时间聚集起来就非常多了。那么reCAPTCHA到底是如何工作的呢?当后台的扫描服务遇到一个无法识别的单词时,它就会和一个真正的CAPTCHA单词并列提供给用户输入,用户输入之后就仅对比真正的CAPTCHA单词,如果对了就当他输入对了,同时认为他输入的另外一个单词就是识别结果。对于一个无法识别的单词进行多次这样的操作,就能得到一个具备高确信度的结果。

如果你希望帮助该项目识别更多的信息,你可以在自己的网站上放置reCAPTCHA。对于WordPress和MediaWiki都有现成的reCAPTCHA插件,对于PHP、Python、Perl、Ruby等动态语言也能轻松找到reCAPTCHA库。另外reCAPTCHA还有一个MailHide的子项目,能够让你隐藏你的email,用户必须点击链接并输入CAPTCHA后才能看到完整的email地址。没错,就和Google Groups上面的效果一样,不过CAPTCHA用的是reCAPTCHA,并且也提供一堆现成的插件与库,有兴趣的可以去官方网站看看API文档。

2007年9月10日星期一

Minimal Blogging and Micro-Blogging

最近大家都在说micro-blogging,所以我也来说几句。为什么国内开始多人讨论micro-blogging了呢?估计是因为饭否在国内已经热了,能够有所谓的“现象(phenomenon)”了,同时国内其他Twitter的copy cat之间的竞争也越来越激烈了。然而我却一直用Twitter,无论身边都少人用饭否都不转过去。首先因为我比较无视copy cat,对我这样觉得原创很重要的人来说,copy cat服务通常看都不看一眼,知道是那么一回事就是了。每天有什么新的web2.0 startup出现,订阅TechCrunchRead/WriteWeb这样的web2.0观察日志就够了,基本上各种古怪的创意尽收眼底,一个copy cat根本不值得我花时间去看。一个新服务对比其参考服务至少要有自己的创意以及更好的市场定位,我才觉得有必要去了解,否则每天新增的web2.0 startup那么多我怎么可能了解得来。

回到micro-blogging的话题来,事实上我觉得Twitter这样的可以叫做minimal blogging了。minimal blogging这个想法来自minimal design,因为当你第一眼看到Twitter的时候,你肯定会说那是一个minimal design的。所谓的minimal design,也就是最小化设计,历史上曾经有一些人指责CSS仅能实现最小化设计,也就是只能由一些矩形的区域组成整个页面(参考Minimalism),更复杂的设计css就处理不好。而Twitter则被我称之为minimal blogging,因为它只能处理最小的最有限的信息,一篇最多就140个字符,不允许链接,不能是HTML或者别的markup language(例如ubb code)。虽然我一直在用Twitter,甚至还测试过从中国电信发一条短信给Twitter的英国接收号码要¥1,然而其实我并不觉得Twitter对我很有吸引力。一方面,我并不喜欢被flooding的感觉;另一方面,我想要的是micro-blogging不是这么minimal的。

对我而言,micro-blogging意味着我不需要想太多的就能发表,而且发表过程操作简单,然而同时要能够分享我能接触的各种信息。Twitter符合了前面两点,但是不符合最后一点,因为它无法发链接和图片,视频或者音频就更不要说了,不过因为我不是视频和音频爱好者所以这两项就免了。暂时而言,我使用Opera Community进行mobile blogging,也就是Cat in Mobile。它允许我在手机上即拍即发布,文字和照片都有了,对我而言就差一个链接了,不过mobile blogging不需要链接,要链接就通过feed和我的del.icio.us聚合一下好了。至于不需要照片的场合,Twitter也就将就着用了,因为无论如何同样是手机上的Opera Mini,Twitter操作起来还是比Opera Community要方便的,要知道手机上多填写一个表单就增加不少操作复杂度。

我真正向往的是Tumblr,一个tumblelog服务,然而我却从来都不使用它,最近也就仅仅导入了几个feed进去。其实这是很正常的事情,就好像除去Macbook之后VAIO真的异常吸引,然而即使我有钱都不会买VAIO,首先因为它确实烧钱,其次是日本产品的保修服务根本就不和欧美的同一个等级,意味着它的维护成本超高。日本产品,大至汽车小至PDA,停产之后都不会留充足的备件,如果你买的产品在保但是已经没备件了,那就无法修,因此我非常不喜欢购买日本产品,不用考虑保修直接吃进肚子里的除外。Tumblr看起来拥有我想要的功能,同时又保持micro,然而对我而言迁移成本实在高。在使用Twitter之前,我没有micro-blogging的需求,所以当时也没思考我能在我的Tumblr上发什么,然而在写这篇文章的同时,我在极力挖掘Tumblr的潜力,以及思考低成本的迁移方法,或者有一天我就迁移到Tumblr了。

最后一句话,为什么我向往Tumblr?因为国外的web2.0达人们有不少在都在用,例如Digg的共创人之一Kevin Ross

2007年9月9日星期日

深入理解 ASP.NET 动态控件 (Part 4 - 解决问题)

前言

在开始写这个系列的文章之时,我想着必须深入介绍背后的原理,然后将所有需要的背景知识呈现到读者眼前,不过我现在发觉这并不是好的写作方法,要写下去对我自己来说难度也不少。最近受到Infinities Loop发布TRULY Understanding Dynamic Controls (Part 4)的刺激,我决定继续写这个系列的文章,并且领悟到了更多读者需要的是对问题的一种较为易于理解的解释,而非一种严谨的解释,因为前者更有助于读者解决当前问题并在再次遇到类似问题时自行推导解决。

其实我在本系列的第一篇文章就已经明确了怎样的文章才让读者容易接受,现在是我自己误入歧途了,所以必须纠正过来。第一篇文章的结尾建议读者自己阅读控件开发有关的书籍,之后就能完整理解和解决这个问题。实际上这是一个比较不合理的建议,大多数人并不可能花时间看完一本厚厚的控件开发书籍(ASP.NET 2.0的比ASP.NET 1.x的要厚了不少)。我需要做的不是复述书上的观点,那也不是我想要做的事情,真正需要做的事情是将书里面的观点浓缩为一篇文章,要让读者能解决问题的,推理看起来符合常识以至于容易接受,然而又比严密推理省下一大多文字。好吧,就让我们按照这种思路去看看如何解决一些常见的动态控件问题。

问题分类

这是受到Infinities Loop启发的,我们首先要将问题分类,然后逐个击破。这里的分类将最常见也最容易解决的排到上面来,然后逐步深入讨论。在开发过程中,使ASP.NET程序员想到要用动态控件的情景通常有如下几种:

  1. 你需要呈现不确定数量的控件,但这些控件是同一类型的
  2. 你需要呈现不确定类型的控件
  3. 上述两个问题的综合或嵌套
  4. 你需要开发自己的Web控件

在对问题进行分类之后,我们就容易逐个去分析解决办法了。由于分类是按照难度逐步递增的,所以这对读者来说应该是较容易理解的。

不确定数量的同类型控件

如果你要在页面上显示一个调查问卷,问卷的题目来自数据库,而任何问题都只有“是”与“否”两个选项,你决定使用RadioButton提供选项。这时候动态创建控件的念头应该仅仅是一闪而过的,然后你就决定使用Repeater。

如果你在这时候没有想到Repeater,或者任何的TemplateControl,那么你就需要重新熟悉ASP.NET的内置控件了。很多时候我们用多了GridView,特别是一直都用BoundField的话,就很容易忘记世界上还有TemplateField这么一回事。

那么为什么Repeater在此会是一个好的选择呢?首先,连最近基本的foreach迭代循环它也帮我们做了,我们仅需要指定DataSource,然后执行一下DataBind(),它就帮我们动态为每一个数据项按照模板创建控件。其次,对于PostBack之后数据发生更新的情况它能应付自如。为了说明PostBack更新数据造成的影响,让我们再来看一个例子。

首先,我们直接在Session里存放一个string[],内容为{"apple", "boy", "cat", "dog"},然后我们需要将它们显示出来,每一个项目显示为一个LinkButton,点击之后就在数组中将它删除。我们都知道使用Repeater或者GridView搭配ObjectDataSource做这样简单的事情是绝对没问题的,但如果我们手动编写动态创建控件的过程呢?

按照大多数人所理解的ASP.NET逻辑,首先应该在Load这一阶段遍历数组,然后为每一个数据项创建一个LinkButton,最后把这一切都附加到页面上唯一的那个HtmlForm上面去。删除怎么做呢?LinkButton实现了IButtonControl,所以可以添加CommandArgument属性,我们就把字符串保存进去好了。在OnCommand的时候就通过此属性识别当前需要删除的字符串,然后从数组中删除,并且还要在HtmlForm中搜索对应的LinkButton然后把它移除。

这时候你应该看看OnLoad中的代码是否记得为每一个控件的ID属性赋值,否则就会出问题了。页面一开始生成的结构应该是这样的:(左侧的是控件的ID,右侧是控件显示的字符串)

ctl01 ("apple")
ctl02 ("boy")
ctl03 ("cat")
ctl04 ("dog")

我们点击"boy",页面进行PostBack,然后Load生成同样的控件树,之后OnDelete删除ctl02,所以输出的控件树应该是这样的:

ctl01 ("apple")
ctl03 ("cat")
ctl04 ("dog")

我们这次点击"cat",页面又在PostBack,但接着Load生成的控件树就不同了:

ctl01 ("apple")
ctl02 ("cat")
ctl03 ("dog")

必须留意到控件的ID属性重新编号了,然而ASP.NET仅仅知道我们点击了ctl03,所以触发的ctl03的OnCommand,根据现在的ctl03的CommandArgument属性,删除了"dog"字符串。这就是所谓的问题了,无指定ID的控件会自动按顺序分配ID,因此ID具有了不确定性。

如果在OnCommand的时候,调用HtmlForm的Controls.Clear(),是否就能移除所有控件并且让ID重头开始编号呢?实验结果表明上述删除过程中第一次PostBack后会生成这样的控件树:

ctl05 ("apple")
ctl06 ("cat")
ctl07 ("dog")

也就是说,移除确实是移除了,然而ID编号没有重置,而是继续编号。那么Repeater是怎么做到的呢?为什么直接使用Repeater就没有任何问题呢?这个下一篇文章再说,我们现在专心来把问题逐个击破,现在你记住这种情况选择Repeater或者其他更高级的数据控件就是了。

不确定类型的控件

在面对此类问题的时候,首先问问自己控件的数量,如果数量不多,直接通过设置控件的Visible属性解决问题就是了。这也就是说,把可能要显示的控件都声明为Visible="false",然后在代码中判断当前应该将哪个显示出来。

如果控件比较多,然而还是能分组的,同一时间仅仅显示其中的一组,那么你应该考虑使用MultiView,这样你的工作将会轻松不少。事实上,能够使用MultiView解决的,都应该优先考虑使用MultiView解决,这比起自己控制哪一个控件显示哪一个控件隐藏要方便多了。其实MultiView所做的,也就是帮你控制控件的显示与隐藏。

这样做的性能如何呢?我们关注两方面的问题,一方面是服务器端执行的资源消耗,另一方面是传输的带宽消耗。我们先来看看服务器端执行的资源消耗吧,我们最常见的消耗应该就是数据控件操作数据库时的消耗了。在ASP.NET 1.x时代,我们没有数据源控件,所以必须手动进行DataBind(),这也就是说如果不手动执行DataBind()的话就不会进行任何数据操作,因此只要我们记得在数据控件不显示的时候也不要让它执行DataBind()就是了,那样就不会有性能损失。在ASP.NET 2.0当中,使用数据源控件的话数据控件是会自动DataBind()的,这时候会造成控件隐藏时的资源消耗呢?事实上是不会的,数据控件即使已经定义了DataSourceID属性,它也仅仅在自己第一次可见时才进行自动DataBind()。如果数据控件的状态是隐藏的(包括使用MultiView隐藏),它就不会自动进行DataBind()。因此,在ASP.NET 2.0中使用数据源控件以及MultiView之后其底层过程还是和ASP.NET 1.x手动操作的一样,就是少写一些代码而已。

我们接着来看看带宽消耗如何,因为隐藏的控件不输出任何的HTML,因此带宽消耗就是指ViewState了。控件隐藏后,ViewState是不变的,因此隐藏控件确实比完全不加载控件造成了更多的资源消耗,换取的是该控件的状态得以保存。一般来说,简单控件隐藏后多出来几十字节的ViewState是可以忽略不计的,整个页面中HTML缩进所需的空格也都几十上百字节了;但如果是复杂控件,拥有大量的ViewState,这时候你真的应该考虑动态加载了。

总的来说,面对这类问题时首先判断显示隐藏控件的逻辑是否复杂,控件本身是否复杂。如果是比较简单的情况,则直接使用MultiView解决就是了。如果是复杂的情况,那就应该考虑自己使用控件将此逻辑封装在内,而不是直接在页面上暴露这些复杂性。关于封装控件的问题,在下一篇文章中再讨论,因此我们继续看下一类问题。

既不确定类型也不确定数量的控件

有时候我们面对前面两类问题都有清晰的思路,但是面对复合问题就感觉很混乱了。例如还是一个调查问卷的显示,数据来自XML,问题类型包括单选和多选,每一道问题的选项个数也不确定,这时候怎么办呢?foreach嵌套foreach,外层迭代问题内层迭代选项,逐个CheckBox/RadioButton来生成?

这时候我们需要的是把问题分而治之逐个击破的思想。既然是上述两类问题的嵌套,我们就应该能够通过嵌套对应的解决方案来实现。对于这个调查问卷的例子,我们可以用Repeater来迭代问题,先把这个定下来,再考虑模板里面怎么做。模板里面需要显示的是一个不确定类型的问题,因此模板里面放一个MutliView,把问题类型的表达式绑定到其ActiveViewIndex属性上,例如单选题就是0多选题就是1。然后MultiView里面的两个View各自嵌套一个Repeater,第0个Repeater迭代选项并显示为RadioButton,第1个Repeater迭代选项并显示为CheckBox。就这样就完成了,我们没写任何一行后台代码,也没有动态创建任何控件。

然后我们来分析一下这个解决方案的性能。对比起动态创建控件,它所使用的控件确实是多了一倍,因为一道问题同时创建了两组选项,一组单选一组多选,只不过其中一组被隐藏了。然而隐藏掉的那一组唯一的服务器端资源消耗就是创建以及绑定,它们不输出任何的HTML,因为它们的值不会被改变所以也不会输出任何的ViewState,并且它们也不会触发任何事件,因此在对性能没有特别要求的情况下这样的性能损失还是可以接受的。至少,这比起你自己去研究ASP.NET页面生命周期然后自己写一大段代码来实现动态加载控件要好多了。

问题与实验

本系列上一篇文章的问题与实验一直没有解答,现在给出参考答案如下:

  1. 为Page增加一个ShowCheckBox的属性:
    bool ShowCheckBox {
      get { return (ViewState["ShowCheckBox"] == null) ? false : (bool)ViewState["ShowCheckBox"]; }
      set { ViewState["ShowCheckBox"] = value; }
    }
    在OnLoad的时候检测ShowCheckBox属性,如果为true则添加上该CheckBox控件。在Button的OnClick事件中,设置ShowCheckBox为true,并添加上CheckBox。记得这两处创建的CheckBox必须拥有一致的ID属性。
  2. 这是为了让ICallbackEventHandler的处理模型符合页面生命周期的模型。虽然Callback发生的时候,页面生命周期已经与PostBack不同,然而ICallbackEventHandler还是让Callback模仿了PostBack的页面生命周期。RaiseCallbackEvent相当于PostBack的Raise PostBackEvent阶段,GetCallbackResult相当于PostBack的PreRender阶段。前者负责事件响应,后者负责生成返回客户端的HTML代码。

这次想和大家讨论的问题是,你觉得你是完美主义者吗?面对上面的调查问卷需求,你会选择我所说的Repeater套MultiView再套Repeater的做法,从而避免写任何一行后台代码,还是会选择自己封装一个控件动态创建所有控件,避免任何不必要的性能损失?

最后,如果你喜欢本系列文章,并且不希望错过下一篇关于控件开发的文章,欢迎订阅我的blog:

在下一篇文章中,我将会介绍Repeater等数据控件是如何工作的,为什么它们能够轻松应对动态创建控件的各种情况,我们如何学习这些控件的设计模式并运用到我们的开发当中。

2007年9月6日星期四

Is this cheating?

终于把《The Game》看完了。不知道是不是因为它的写作风格比较pop culture,好像Hollywood大片的台词风格,所以读起来感觉非常好,也让人非常addicted,这点与读英文的技术书不同。这本书对我来说属于少数,我的意思是能够随之而来影响我现实生活的书,那当然是少数了。

首先当然是通过这本书发现了一条self improve的途径,因为the game本身不仅仅是围绕pick up这一个game,而是关于你的self-confidence。有些人天生就很有自信,能够随便地对别人说出自己想要的,或者仅仅是想法,而不怕遭受别人拒绝;另外还有一些人则相反,他们会害怕遭受拒绝,拒绝后也就接受了,而且心里还会不舒服上一会儿,以后再次提出的胆量也就少了。当然,人不是两极分化的,所以大部分的人分布在这两种极端之间,但总的来说还是有不少人对遭受拒绝感到恐惧。

读完这本书之后,就明白了PUA都想获得的一种本能反应——“我才不在乎呢”,反正被拒绝又如何,我又没有损失的。其实很多很理性的人都能够理解到没有损失这一点,但就是心理上不愿意接受被拒绝的可能性。对我而言,要去掉这种恐惧并不难,看完这本书之后我能够很快切换到那种心态,这正的麻烦在于——要降低被拒绝的概率,心态不是主要问题,技术才是主要问题。然而要练习技术就不再是那么容易,你需要花大量时间投入到实践当中,不断摸索,然而暂时对我来说我不觉得我有必要投入那么多的时间到与不同的人交流当中去。我还有书要翻译,我还有TOEFL要准备。

这本书引发的后继事件,包括我推荐了JimRobert来看这本书,然后我又在豆瓣上发现了ePIK也在看这本书。其中Robert和ePIK都和我一样是沉迷型的——这本书正是我想要的,我缺乏的东西里面有说,我渴望这种改变。而且我们这三个人还有一个共同点——technically a virgin。我想这正是我们渴望去改变的原因,因为我们都看到了前面有路可走,我们需要看清楚这条路,以及它能够怎么走下去。然而对于我身边的大多数朋友来说,他们对此都毫无兴趣,他们不是没有这个需求,而是忽视这个需求的存在,认为这不是能够通过一本书所展开的一组技能就能解决的。我们之所以相信这本书是有效的,是因为读过之后很快就开始分析身边亲眼目睹的一些这方面的成功人士的做法,并且发现这些天生拥有此项技能的人正好符合书中的描述。

有一件巧合的事见,我们在读这本书的时候,VH1的真人秀The Pick Up Artist开播了。书中有一些事情的描述,单纯看文本是怎么都看不明白的,但如果看到真人实践那就好理解很多了。另外网上有关的资料也不少,我们都搜集回来看看。有很多的技巧,其实不仅仅适用于pick up,还适用于日常沟通,能够让对方更乐于听你说,被你所吸引。

好了,有人看到这里肯定要说我文不对题了,起了一个完全无关的标题来吸引眼球。其实不是的,题目正是我接下来要讨论的内容。首先我要说明一点,现在我是支持life is all about experience的,你必须有所体验了才能更好地作出选择。就好像我希望能到不同的国家旅游一下,这样我才能更好地决定我到底想去哪里发展,随大流挤去美国并不一定是最好的。女人也一样,你要有充分的经验你才能够更好的选择,一开始就盲目相信one-itis是不行的,必须有重复的依据说明那真的是你的one-itis才值得你去追,然而依据来源于经验,而不是无端端的感觉。

好了,这时候问题就来了,就好像我只能告诉Singzy,"you are part of my experience, but you might not be the one"。这时候就违反了常人对relationship的理解。一般的理解是,因为我喜欢你,所以我喜欢和你在一起。然而我的逻辑是,我不确认我对你的态度,然而我需要和你在一起,因为这样才有助于我确定对你的态度。这就是题目所要问的,"is this cheating?"。

当然,其实我不认识这是cheating,这对我来说不是一个问题。因为我首先要有这样的看法了,我才能继续我的experience,否则认知失调带来的麻烦将更大,至少比选择女人的麻烦要大。The Game里面提到一件事情,就是假如你认为隐瞒着一个情人去发展或维持另外一个或者一些情人的关系是不道德的,那么你就不要这样做了,因为你自己都认为是错误的事情,无论如何都是错的。但是如果你好像穆斯林那样,认为这是对的,直接告诉对方我是一个穆斯林,在穆斯林的信仰当中一个男人要有三四个老婆才好,你是爱我的话就必须接受我的一切,包括我的信仰,这样才可能有出路。因此,我也就选择了把我所知道的以及我的逻辑告诉了Singzy。