2008年12月30日星期二

GMP Party EP2

Geeky meets Pretty的第2场大party终于来了(平时的小聚会不计算场次)。自从我在网志年会上见识到了Punch Party后,我就一直想在GMP内搞这样一个活动,在小组内进行过若干讨论后我们最终决定要搞一个2008年年度“大”party,形式当然就是Punch Party了。

这次party,要感谢Chloe和Piggest帮忙组织,是她们帮忙确定了整个活动的rundown和预订到了场地(奇遇花园)。然后要感谢所有的speakers,是他们带来了如此丰富的speech:

Jinghua和Chloe的session做成了series,让大家非常期待下一个episode。其中Jinghua说到清华校园不适合搭讪美女时,方军立即表示反对并解释了清华哪里适合寻找美女。Leo因为是在看过广州Punch Party的视频后做的准备,所以他的session风格也更接近之前广州Punch Party的,据说他之前按照7分钟的时间安排排练了好几次哦。龚纹的星座解释好复杂哦,听着听着就让我感觉在上高中的政治课,可惜现场没有人主动出来让龚纹做一下分析,否则会好玩很多。

作为一个party,少不了的当然是回答问题抢奖品的环节,我的geeky问题加上Chloe的fashion问题还有龚纹的星座问题,确保了大家不仅仅要有实力还要有运气才能拿到奖品。对我来说,最好玩的就是问Office 2007下一版本号的问题了,竟然那么多人不知道Office 13这个版本号被跳过了。

这次的party虽然并没有Carol组织的Punch Party那么紧凑和快节奏,不过我觉得作为第一次已经做得不错了,相对来说不够2.0(主要是单向交流,听众互动少),而且也没有sponsor。方军建议我们可以和Beijing Open Party合作,做成他们的一个track,因为我们在某些方面正好和他们互补哦——他们缺少美女,而我们性别比例极力保持在1:1;他们缺乏非技术话题因而显得范围比较窄,而我们追求多样性有各式各样的话题;我们没有sponsor所以要收场地费用,而他们拥有不少的sponsor;我们还没有固定的流程,而他们已经有相当的活动经验。

anyway,接下来我们GMP也要建立一个对外发布信息及接受投票和留言的blog,然后逐步把GMP Party的筹办过程流程化,让GMP Party成为一个相对稳定的活动。

2008年12月12日星期五

假如你愿意以原版或影印版价格购买翻译书籍的话

这篇文章是接着Tony Qu的《批“觉得有必要记一下的东西——关于翻译”一文》写的,就讨论一个问题——你原意以原版或影印版的价格购买翻译书籍吗?

为什么问这个问题?这源自Tony Qu批判的原文中的一句话:
很多国内程序员看书就只看英文原版,开发就只用原版VS,就是这个原因。


我承认,在英语能力相当的程序员当中,这句话说的是事实。能够看原版书的尽量看原版书,不仅仅因为看起来舒服,更因为容易在P2P网络上找到OCR后完美排版的PDF(甚至是官方PDF)。但这部分人当中,又有多少是真真正正是去买原版书的(原价格按汇率算),或者至少去买影印版的(价格是翻译版的一倍以上,原版的一半以下)?我想就很少了,我仅仅知道Jeffrey Zhao会从国外买二手原版书。很老实说,假如读者原意为翻译版支付引进版的价格,那么翻译版能够做得比现在的要好得多。但有多少人是连翻译版的价格也不愿意支付的,宁愿上网找极度难看的未OCR扫描版?此时,结论已经很明确,翻译版质量差不完全是出版社或者译者的问题,是经济利益驱使,这有电影工业与唱片工业在大陆的做法为证!

虽然现在DVD的分区对购买者来说已经毫无意义,但当初就把大陆分作一个6区是有理由的。话说刚刚有DVD的时候,大陆的DVD市场跟国际市场同一个运作方法,电影上映后至少3个月才发行DVD,以免影响票房。但DVD就是卖不出去,不仅仅是因为太贵,还因为国内的购买者不愿意等那3个月,当然也不愿意买票进电影院看。他们买什么?买盗版DVD。因为DVD必须有正版片源出来后,才可能有正版片源的盗版DVD,所以3个月未到,所有的盗版都只可能是枪版DVD。然而大陆消费者就是不在乎画质和音质,他们就是想以最低的价格抢先看到电影,看完就算。当这种需求被中国电影工业从业人员知道以后,一种新的商业模式发展出来了,以满足这部分消费者的需求——大陆的引进版DVD的发行和电影的上映几乎同步进行,价格仅仅比盗版略高,并且最重要的是,人为地把画质和音质降低到枪版的水平。就这样,电影工业能够在大陆盗版市场上分到一杯羹,我的意思是他们算是卖官方枪版的了,同时也不影响他们的国际市场价格——即使存在购买渠道,港台消费者也不会接受这样廉价的劣质DVD,仍然会等上映3个月后买原版DVD。

唱片工业做的事情是类似的,大陆所谓的引进版虽然价格更容易被消费者接受,但音质是经过人为降低的。这就是价格歧视,因为大陆消费者只愿意支付一个更低的价格,也只需要购买质量更低的商品,所以供应商就可以把这划分为一个独立的价格歧视区域市场。我不知道图书行业是否存在这样人为控制的“阴谋”,但只要大陆消费者的需求还是这样的“另类”,价格歧视原则就会一直适用,这样的事情就会无意识的继续存在,以远低于影印版价格售卖的翻译版质量就肯定还是那么低。对了,顺带说一句,港台翻译版的价格是和大陆影印版差不多的。

总结一下,我也是译者,翻译工作低廉的价格以及编辑工作的效率低下Tony Qu说过我就不再说了。如果大陆翻译版最终按照港台翻译版的价格去销售也能获得同样的销量的话,我相信译者可能愿意为这份价钱做全职的翻译工作,我相信出版社愿意聘请更多专业编辑并且合理安排他们的工作量。

P.S.如果要认真学习和研究中国的传统语言文化,我个人还是建议去台湾。

2008年12月7日星期日

SD2C 2008

这几天参加了SD2C,也就是“软件开发2.0技术大会”。规矩当然是照旧的,social第一,session第二。

Day 1

第一天想着12:00开始签到,于是慢吞吞地准备出发,去到九华山庄已经是11:00。这是我第一次在没有车接送的前提下一个人跑来九华山庄,路上浪费了不少时间。签到后开始乱逛,然后陆续找到了公司不同部门来的同事,发现大家都没吃午餐。虽然我自己从McDonald's带了一个汉堡来,不过还是跟大家一起打车到小汤山街口的镇上吃饭。吃完饭就13:00了,应该开场了,可是打车回九华山庄实在太难,最后无奈打了黑车回去。我个人认为,把开场放在13:00但又不提供午餐是十分不体贴的。在市区的话也就算了,在九华山庄这样一个三流装一流的地方,选择不多又不怎么好吃的自助餐竟然要¥68一位,方便面也要¥20一盒,不提供午餐这样的做法实在是不人道。

下午的议程看起来全是keynote级别,听过后才发现那完全是赞助商专场——逐个赞助商轮流上去宣传自己的技术或者观点,而且还不提供任何课程反馈的机会,它讲得再烂我也不能表达一下我的不满。赞助商专场分为上下两个半场,上半场的人都是来吹水的,就吹嘘自己公司的东西,泛泛而谈,听了也没什么收获;下半场讲的东西稍微实在一些,雷军和戴志康上来讲的话都很真诚,也很有感染力。总之,要是早知道第一天下午是赞助商专场的话,我就去WinHEC玩到15:00再过来好了,然后18:00吃饭,接着参加晚上的活动。这只能怪我参加会议的经验还是太少了,没有把这么明显的安排给看出来。

下午听了那么多个小时,最让我感到震撼观点来自于雷军。他在说他投资的UCWeb时提到了这样一个观点:我们曾经都是互联网用户中的领头羊,有什么新鲜的东西出来我们都先去尝试,然后慢慢普及到大众用户。但在移动互联网就不是这样,移动互联网的主要用户是那些比较少机会通过计算机接入互联网的人,例如学生、民工和军人。也就是说,我们这些每天使用计算机连接着互联网做开发的人,其实是不可能知道移动互联网的真实需求的,我们无法体会使用不到计算机接入互联网会使怎样的。过往我一直认为移动互联网用户就是高端移动用户和高端互联网用户的交集,现在我终于明白到不是这么一回事了。

晚上去各个沙龙看了一下,没有什么印象特别深刻的。只记得在“职业规划与成长论坛”上听到这样一句搞笑的话——“我们的HR自裁了,也就没有HR了”。晚会后有班车把我们送回到地铁站,然后回到家也就是23:00了。

Day 2

第二天早上9:00出发,去到就是11:00了。我觉得把第一个session放在9:00开始是很不合理的,九华山庄这么偏僻的地方外加不包住宿,谁原意那么早起床赶7:00从市区开出的班车啊,结果当然是大家都很晚才到啊。对于speaker来说,如果自己的session被放在早上,可能也会觉得大会不重视他的session,因为早上能赶来参加session的人就是少一些,这个大家都明白的。我去到时已经是11:00,然后去听了一下郭安定的课,中午和郭安定、老孟、莫依等MVP一起吃饭,还是挺好玩的。

从郭安定讲的内容来看,他很注重企业生态圈。也就是说,只要你能够帮助别人解决实际问题,赚钱的机会总是有的,但也没必要自己把什么都做了,也要留机会让别人帮你,赚你的钱。把这个道理传播出去,让更多人赚得到钱,让更多人受惠。这种思想我是十分认同的,如果帮助别人的同时又帮助了你自己,这有什么不好呢?

下午我去听了一下周爱民的JavaScript+Delphi+ErLang,语言层面的东西不用怎么在乎,他也没做很应用性的展示,我觉得最重要的一个思想还是分层——只要实现了分层,层与层之间是针对接口设计的,那么随时换掉一个层都是可以的,只要接口保持不便,什么语言并不重要,不同层的需求不同实现语言自然也可以不同。另外还听了李建忠的.NET设计模式,讲的是一些老生常谈的内容,没什么非常特别的。其实讲什么技术并不重要,最重要是把那种思想说清楚,让听众都能领悟到,那就算是成功了。

晚上是CSDN专家沙龙,本来说是让各位专家说说对CSDN服务的不满与建议的,结果大家的自我介绍都拖得很长,介绍完也就完了,赠送给各位专家一人一本绝影签名的《疯狂的程序员》,然后就赶班车去了。其中最有趣的一幕,就是莫依问老孟说,“是什么让你多年坚持在论坛上帮助别人解答问题”,旁边的郭安定小小声说了两个字,“伟哥”。

Day 3

最后一天,依旧是9:00出发11:00到。原本计划去听听iPhone开发的,发现基础部分都讲完了,开始讲OpenGL的使用,我又完全听不懂,听了三分钟就睡着了。

下午听的是使用YSlow2.0优化网络性能,主要是了解一下YSlow2.0的新特性,也就是如何自己设计符合自身网络特性的网络性能评分规则。接着去听了Amazon运计算服务的架构分析介绍,确实比较介绍性,让你知道就是有那么多的服务在运行着,并且能为企业省钱,就这么简单。最后听的一个session是面向对象的JavaScript,这是作为当今JavaScript开发人员必须知道的基础知识啦,听他说一遍只是为了好玩。

SD2C结束后,马宁准备把我和莫依还是陈敏送到地铁站,最后大发慈悲把我们都送回家了,超级好人,在这里需要感谢一下。建议明年真的不要选择九华山庄这样的地方了,交通实在是不方便。

P.S.发现自己最近参加的会议不少啊,整个blog塞满了关于各个会议的文章,如China MVP Open Day 2008、TechED 2008 China、Chinese Blogger Conference 2008WinHEC 2008 China

2008年12月6日星期六

大陆技术书越来越台湾化了

这次SD2C我总共搬了4本书回家,2本买的2本送的。我发现现在大陆出版的技术书越来越台湾化了,也就是“更多搞笑,更少大道理”,而这正好符合我近期的读书倾向。

在CSDN专家沙龙上,每位专家都拿到了一本绝影的《疯狂的程序员》,听说是绝影自己经历的写照。虽然我还没仔细看,不过相信这本书会是本十分轻松的小说,这正是我喜欢的。之前看《梦断代码》也是足够轻松的,不过轻松背后也发人深思,让你不得不去思考很多软件工程和组织架构的问题。

在SD2C的签售会上,我还买了一本《悟透JavaScript》。我已经不需要看任何对JavaScript泛泛而谈的书,但我仍然买了这本书,就是想看看其娱乐性的一面,如果确实写得好,包括插图画得好,那也是十分值得我学习得。什么时候我也要在我的blog上加上专业插图,否则就太没有竞争力了。

另外我最近还买了一本《大话设计模式》,同样也是因为它搞笑的一面。虽然读起来会觉得某些剧情比较牵强,但至少这是一种写作风格,可能在大陆还不成熟,不过将来会被越来越多的作者采纳,自然会成熟起来。

总的来说,我现在也看纯技术书看得有点累了,况且很多东西看了不用等于没看,过一段时间还真变成没用的了。轻松娱乐的东西,至少保证了阅读的过程是愉快的,即使将来用不着,用得着也就算是赚了。

2008年12月3日星期三

WinHEC 2008 China

今天是WinHEC第一天。WinHEC就是Windows Hardware Engineering Conference,中文名是做Windows硬件工程大会。昨晚紫柔告诉我9:00到场签到就可以了,因为9:30正式开始,但我早上还是忍不住多睡了一会儿,所以10:00才到场。当时还是张亚勤的演讲,我进入主会场后迅速找到剩余的几个空位坐下来了。

张亚勤的演讲当然紧接着若干个demo,其中Surface的demo在MVP Open Day已经看过了,这次还是同一个人来做。还有那个health care的video,也是MVP Open Day上面放过的,看来这两个月没什么变化嘛。整体而言,张亚勤演讲后的中文demo都是做一些我们已经知道的东西,没什么值得看的。

原本张亚勤的演讲只有1个小时,结果延长了很多,然后Dennis Flanagan才上来讲Windows 7。Windows 7的demo就非常有冲击力了,特别是device stage这样的特性。

在Windows 7里面,每个外设(包括网络外设)都有自己的图标,厂商可以设计一个和外设外观一样的图标,使得用户更容易在Windows 7中识别这一设备。例如你有黑白两个USB drive,都插入到电脑后,你会发现不知道哪个盘符是哪个USB drive的,要看看里面的内容才知道。在Windows 7里面,只要厂商制作了对应的图标,用户就能在图形界面上看到有区别的两个图片,也就可以在不了解何谓盘符的前提下正确操作这两个USB drive了。

此外,每一个外设都可以有自己的device stage,例如连接一部Zune后可以显示容量、电量,还可以显示为你推荐的MP3销售信息;又例如连接一部Nokia手机后可以显示有关的内部信息,以及Nokia网站上为这部手机推荐的新游戏。简单来说,硬件设备销售后不再是与硬件厂商脱离关系了,只要它连接到安装了Windows 7的PC,并且这台PC还连接着网络,硬件厂商就能得知这台设备的使用情况,并且为你推介更多的商品和服务,当然也可能包括免费的服务与技术支持。肯定有人会说这会导致隐私问题之类之类的,我相信最终Windows 7和硬件厂商会引入访问控制机制,让用户选择一台设备连接到Windows 7后是否允许相关信息通过网络传输,这个大家不用担心。

两个keynote结束后,就是抽奖环节。早上每一个人进来时都拍了一张照片用于抽奖,然后用这些照片拼成了一个巨大的奥运五环徽标,最终用Silverlight Deep Zoom来随机zoom in到某一个人的照片之上。这样的抽奖形式还是挺有创意的,不过有些照片实在太不清晰了,最后拿到了大奖的人到底是不是照片上的人,我们都不知道。

午餐是跟紫柔以及其它MVP一起吃的,紫柔带来了一个90后的实习生,是一个拿了国家奖学金去新加坡读高中的女生。她应该是紫柔的助手吧,不过我们说的东西她都听不懂,应该会觉得十分无聊。

随后,让我最不满的事情就发生了!今年的WinHEC和TechED一样,通过盖章来增加互动,总共有1200份Windows 7光盘和1000只2G USB drive可以通过盖全10个章后获得,并且日程表写着下午2:00开始换领的。但我们2:00回到会场发现今天的400只2G USB drive已经换领完毕了,虽然Windows 7光盘还是有的,但因为必须同时换领,所以也就相当于不能换领。既然日程表写着下午2:00开始就应该下午2:00开始啊,怎么能够提前开始发呢?!

下午的课程我们都没有去听,一群MVP聚在一起聊天。最有趣的一幕就是,竟然有人来主动搭讪那位90后女生。是不是非80后的人就分不清什么人是90后的呢?又或者是IT人士太闭塞了?反正我觉得90后的化妆和穿衣风格挺容易辨别的。我们分散地坐在媒体展示区的长沙发上,那个人直接无视我们问她还有没有盖章的那张纸。她说没有,那个人就问她是哪里的以及有没有名片。这时候作为大版主的紫柔自然冲出来说——我们都是微软中文技术论坛的!我相信那个人已经很无语了,但又不知道我们是干什么的,还是问我们有没有名片。紫柔就告诉他,你上微软中文论坛技术就知道啦。他估计还是不知道微软中文技术论坛是什么,不过很无奈地走了。真是难得见到有人如此直接搭讪的,而且还是在硬件工程大会上哦!

最后一个session解释时,会根据收回的反馈表抽奖,于是我们就找了一个讲用VHD(虚拟硬盘)引导启动的session去听听。最后提问阶段,有人问了能否引导启动一个装有Linux的VHD,speaker说VHD的技术都是开放的,虽然Microsoft没有实现的意向,但开源社区可以去做这样的事情。其实我有个问题,不过一直懒得问,那就是Microsoft能否和Apple合作,做一个Mac上从VHD引导启动的东东,那么将来我就可以在MacBook装Windows 7并且仅仅装到VHD里。

会议结束后,MVP在讨论是否组织一起吃饭,因为我约了人,要去拿张CF卡,所以就先走了。明天我要去参加SD2C,也就无法参加WinHEC了。

P.S.这篇文章不是因为MVP换取赠票而必须写的,而是因为换领礼品这件事实在搞得太不合理了,当时我就决定要写WinHEC的负面。

2008年11月23日星期日

Chinese Blogger Conference 2008

上个周末请了两天年假,回广州参加网志年会顺便回家。

第一天去到会场,就见到了LEMONedhidecloud,然后拿到了我的fail whale tee。接下来的session……其实我不知道session讲什么,我想大多数人都跟我一样不关心session讲什么,大家只是找个机会来聚会而已。中午跟Elliot Ng一起吃了午餐,并且拿了一件CNReviews的tee。下午的session也是不知道讲了什么,然后就是自助晚餐了和Punch Party了。

自助晚餐吃的是点心,虾饺和牛肉丸都不错,但是鸡翅就很难吃。接着Punch Party正是开始,第一位上台的是Carol,介绍什么是Punch Party。所谓的Punch Party,就是每位speaker有7分钟的时间,大概就是20个slide每个slide讲20秒的时间再多一点。当晚的Punch Party做得非常perfect,每一个人讲的话题都十分之吸引人,做到了Punch Party所强调的punch效果——让人感觉耳目一新。Carol作为第一个speaker,把全场的气氛都调动起来了。中间有介绍大陆吃喝玩乐之行有多艰险的工头坚,还有介绍胖卡如何把宅男配送到乡下的。最后一位导演先生,表演了7分钟的无声演讲——开头只说了一句,“由于接下来的内容都很晦涩,所以自动进行静音处理”,接着做了7分钟演讲的动作与口型,幻灯片翻了几页,但是没说过一个字。对于所有参加Punch Party的人来说,这样的结尾实在是太impressive了!

Punch Party的好处显而易见,能够在最短的时间内让你了解到一些你可能永远都接触不到的知识,同时给你无限的震撼感。不过我觉得Punch Party对speaker的要求也挺高,否则也不容易做好。而且作为organizer,一场Punch Party必须组合不同类型的speaker。

第二天的session稍微有趣一些,不过依然没怎么听,莫非年会的习俗就是把重点放在晚上?下午年会结束后大家就跟着Issac Mao到“友鸡会”吃了火锅,然后到北风的凸凹酒吧去聊天。我也不知道最后大家是什么时候才回家的,我快到凌晨时已经想睡觉了,于是就回家了。

2008年11月13日星期四

Live Mesh vs MobileMe

最近在用Live Mesh在多台计算机上同步文件,而之前一直用MobileMe同步联系人、日程等信息外加系统备份,真希望把这两个服务的好处叠加起来。

Live Mesh的好处是可以指定任何一个目录进行同步,而非指定一个同步目录然后要同步的东西必须放在里面,这方面就比MobileMe要好。而且Live Mesh的自动同步客户端同时兼容Windows和Mac,而MobileMe仅仅支持Mac同步。Live Mesh唯一不足就是没有版本控制,不过我想要是有版本控制占用的网络空间和流量开销就成倍增加了。

MobileMe给我印象最深刻的是,我重装了我的MacBook后一登录MobileMe帐号就帮我把整个System Preferences给恢复了。当然,联系人和日程信息也都恢复了,这是现在Live Mesh完全没覆盖到的功能。另外对iPhone的push服务也做得很好,更新什么信息都在Mac上进行就可以了,根本不用管它什么时候同步到iPhone上。

我觉得最好就是把这两种服务结合到一起,一个帐号一个服务就把这些都覆盖了,当然我不介意付费。在TechED MVP Dinner上,我和一位做Azure的Microsoft员工聊了一下,说最好Windows上的程序都遵守Vista的规范,把代码和数据分开存放,也就是数据都放到C:\ProgramData下面,这样Windows也就如同Linux一样能够轻松备份纯数据了。接着只要把数据同步到cloud上面,例如说是Azure上层的Live Mesh,重装机器后就能够把数据重新同步回来了,只要再装上应用程序就一切恢复原装了。

2008年11月10日星期一

开始翻译 Adobe AIR in Action

Prototype and Scriptaculous的翻译已经是一年前的事情了,翻译了半年,休息了大半年,现在继续接受翻译的工作。仍然是图灵引进的书,仍然是Manning的In Action系列,这次的是Adobe AIR in Action

其实AIR出来之前我就想去学习,很多很多技术都如此,不过翻译算是一个很好的学习过程,因为它逼着你认认真真把一本书读懂。这次着手翻译Adobe AIR in Action,我想半年后我也会熟悉AIR相关的技术。虽然我一直以来都对Flash和Flex没什么深入了解,但我希望这些知识反过来也能用到Silverlight开发上,结合两派的模式从而进化出一种更好的实践方法。

另外我还介绍了身边的朋友去翻译Practical Prototype and Script.aculolus。Manning即将发布Silverlight 2 in Action,如果图灵引进这本书的话,我也去看看是否能够参与翻译。

2008年11月5日星期三

以服务器端为中心的 ASP.NET AJAX 模式 (Part 2 - Control)

在上一篇文章当中,也就是《以服务器端为中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)》,我们探讨了较为易用的Behavior模式。之所以说它较为易用,是因为它不涉及和原有Page处理流程的交互,即使访问网络也是访问独立的Web Service(包括Page上的[WebMethod]),因此和Page处理流程的设计绝对是正交的。但有时候我们需要的就是与Page处理流程的交互,这时我们不得不使用与服务器端逻辑紧耦合的Control了,这正是本次文章要讨论的内容。

在基本的 ASP.NET AJAX框架下,我们有三种方法来做基于Control的Ajax操作,它们分别是UpdatePanel、ICallbackEventHandler 和IScriptControl,下面我们就分别看看它们的特点和使用场景。

UpdatePanel

UpdatePanel 是与服务器端逻辑进行交互的多种方案中最易用的一个,甚至就不能称之为交互——你根本就不需要触及任何客户端逻辑。一个服务器端操作,经过 UpdatePanel的“劫持”,变成了一个客户端操作,而这个客户端操作又直接调用对应的服务器端操作,就这么简单。

如果用UpdatePanel来做一个带分支的选择对话框,那应该如何设计?思路可别跑到客户端的confirm方法上去,那可太绕了,或者说太不 ASP.NET AJAX了。用UpdatePanel,就应该坚持它的理念,一切客户端操作都是幻象,所有操作其实都是在服务器端进行的,包括选择对话框。要按 ASP.NET的思路来做,我会做一个选择对话框控件,它的实质可能是一个浮动层模拟的对话框,这属于实现细节,我们不用太关注。重点是,这个选择对话框的分支逻辑是完全在服务器端进行的,Async PostBack之后服务器端根据提交回来的数据决定如何触发事件。这样做整个分支选择的逻辑就是内嵌在Page处理流程当中的,不需要通过 Cookies或者Session来做数据的中转媒介,避免了Page处理流程与更大作用域中的数据的紧耦合。

UpdatePanel 适用于逻辑完全在服务器端的开发,并且我建议使用UpdatePanel时也就把所有逻辑放在服务器端,不要去写一些混合服务器端逻辑与客户端逻辑的代码。有人会说,你看老赵就很喜欢去动那个 Sys.Net.WebRequestExecutor来改变UpdatePanel的行为啊,但其实这属于分层设计思想中的一部分,他去动那个东西改变的也就是一个分层内的逻辑,只要层与层之间的接口不变,具体实现是可以按需设计的。但如果你用了UpdatePanel,同时又用Cookies或者 Session来传值,这就跨越了n个层,增加了不少耦合度。

ICallbackEventHandler

关于ICallbackEventHandler,我已经说过无数次了,重点还是你必须用Page处理流程来思考,只要你理解了Page处理流程,你就明白为什么ICallbackEventHandler在.NET Framework 2.0 Beta2中只有一个方法,而到了RTM要分拆成两个方法。具体可以参考《ASP.NET 2.0 ClientScript Callback》,我就不再重复了。

如果用 ICallbackEventHandler实现一个带分支的选择对话框,又如何做?和使用UpdatePanel的做法类似,我还是会做一个选择对话框控件,并且这个控件继承自ICallbackEventHandler。为这个控件编写JavaScript并实现 ICallbackEventHandler接口时,我会确保JavaScript对Callback给出正确的调用参数,并在接口方法的实现中接收这些参数然后触发正确的事件,就这么简单。和UpdatePanel一样,不要偏离了ICallbackEventHandler的设计思想,它的处理流程必须是合并到Page处理流程中的,你的控件也就必须这样设计。

至于在什么情况下选择 ICallbackEventHandler?如果你有一个轻量级的Ajax操作,但使用UpdatePanel更新整个区域的HTML开销很大的话,那么你可以考虑使用ICallbackEventHandler。当然,前提是你懂得控件开发和JavaScript。

IScriptControl

这是最复杂的解决方案了,你需要实现一个Control的两个副本——一个服务器端的,一个客户端的。有一部分逻辑,是要在客户端和服务器端重复实现两次的,而另外一部分逻辑,只需要在客户端或服务器端之中的一个实现一次。IScriptControl的经典例子,当然是ASP.NET AJAX自带的Timer控件。它的计时器是纯粹的客户端逻辑,然而Tick事件却在服务器端触发,Async PostBack成为了两者之间的桥梁。当然,就Control本身而言,它并不在乎PostBack是不是异步的,Tick事件只因PostBack而触发。

如果用IScriptControl来实现带分支的选择对话框,那将会和 ICallbackEventHandler的版本十分相似,唯一不同的地方就是它在客户端的逻辑会被封装为一个Sys.UI.Control的派生类,而ICallbackEventHandler的客户端逻辑往往是不封装的。这样的好处显而易见,那就是代码更容易维护了,并且客户端的Control可以同样可以加入事件支持,并提供和服务器端一样的代码分支事件。要知道在CTP阶段的Timer控件,其客户端版本Sys.Timer(而非RTM的 Sys.UI._Timer)是拥有tick事件的,和服务器端的Tick事件对应,只不过RTM取消了此项功能,因为ASP.NET AJAX 1.0的侧重点完全就是服务器端功能,客户端功能都被砍掉了。

什么情况下选用IScriptControl?如果你认为你的客户端逻辑应该封装为Sys.UI.Control的派生类,那就选择IScriptControl吧。

小结

我们分别讨论了三种通过Control实现Ajax调用的方案,并且一再强调了设计必须基于Page处理流程,不要在此流程之外增加不必要的复杂度和耦合度。值得一提的是,有很多人质疑为什么要在Web上提供这样一个支持分支的选择对话框功能,我的看法是这样的:既然客户端软件的流程会有此功能,那么 Web应用也有此功能就实在是太正常了,你删除blog post的时候问你一下是否确认删除,难道会有人觉得这个功能是设计错误?可能不同的只是表现形式而已,到底是confirm还是弹出层,甚至是一个专用的过渡页面。然而从用户体验的角度来说,这其实并不是最优的方案,多数时候用户删除就是确认删除,并不需要再问一次是否确认之类的愚蠢问题,但开发人员觉得用户错手删除的后果应当由用户自己承担,所以就做了这样一个对话框来推卸责任。真正好的用户体验是不需要确认的删除,但用户一定能够恢复,最好是按一下 Ctrl+Z就可以了,然而对于开发人员来说还是有很多操作是无法做到可恢复的,这时候除了显示对话框也没有更好的解决方案了。

最后,如果你喜欢我的文章,可以通过订阅feed来及时获得更新:

2008年11月4日星期二

软件安装时到底是否应该让用户选择路径

周末和Google UX Team的Junyu聊天,说到Google现在统一使用Google Installer安装软件了,点一下Web上面的链接就自动开始下载安装并运行,开头我还以为是Microsoft的ClickOnce呢。由于安装过程是全自动的,就如同Microsoft的ClickOnce和Adobe的AIR一样,所以是不允许用户选择安装路径的。

到底不让用户选择安装目标好不好?我们认为用户分为三个层次:
  1. 入门用户 - 购买的是品牌机,可能就一个C:和一个用于一键恢复的D:。这时候有什么好选择的呢?当然是不选择最好了。
  2. 熟练用户 - 经受过文件难以搜索或者忘记及时备份误删文件的种种磨难,学会了分门别类存放文件,自己有计划地把硬盘分成C:, D:, E:, F:四个盘。这时候你不满足他分类存放文件的习惯,他就会觉得很不爽了。
  3. 高级用户 - 经过无数次备份与重装后又在返璞归真,只用一个C:,安装时多数选项都直接next,不选择安装路径。
当然,这个分类主要是针对Windows用户,因为Windows的成长过程就是典型的“问题少年”——不停地向用户抛出各种问题,这个你选什么啊,那个你选什么啊。对于Linux和Mac用户来说,大家早已习惯了安装时一路next到底。Linux命令行安装甚至不用next,只是本地编译的话有时候需要yes一下。

事实上,我认为给用户那么多选择是没必要的,文件的搜索与备份应该通过其它手段来改进,而不是让用户手动归档。要求用户理解文件系统,就如同要求调用者理解API实现方式一样,其实是很不合理的。

对于现在的品牌机而言,只有一个C:,培养Windows用户好像Mac用户那样,什么都装到一个盘里面,这才是正确的发展道路。Mac有Spotlight,Windows Vista现在也有不错的磁盘索引与搜索系统,将来实现了WinFS或许能做得更好。

现在Windows缺的是一套好用的备份与迁移方案,问题来源于Windows软件都没有规范地把可执行代码与数据分离存放,所以没有一种统一的模式来备份软件数据。如果Windows上面的软件能够按照Vista的指引,把数据都存储到C:\ProgramData,那么接下来的事情就容易多了。况且我之前也说过了,这也是UAC的意义所在,有助于提高Windows的安全性。

2008年10月27日星期一

以服务器端为中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)

早在ASP.NET AJAX从CTP转向Beta再转向RTM时,看着客户端的Control被逐步放弃,与此同时ASP.NET AJAX Control Toolkit越来越多地使用Behavior,我就想深入说说ASP.NET AJAX的模式。不过由于我比较懒,所以这个话题只在《理想的 ASP.NET AJAX (Part 2 - Server Centric)》中一笔带过,没有深入讨论。今天看到volnet的《我们究竟是否有在“Asp.net中模仿Winform的MessageBox ”的必要?》,决定写一个文章系列来说说ASP.NET AJAX的模式。

什么是Behavior?

什么是Behavior?Behavior与Control有什么不同?这是首先需要回答的问题。

在Windows开发当中,Behavior的概念是不存在的,有的只是Control。ASP开发连Control都没有的,到了ASP.NET才引入了Control的概念。为什么Ajax开发要引入Behavior这样的概念呢?因为Behavior意味着不需要改变原有的组件逻辑,而改变原有组件的逻辑在客户端往往是不可行的,至少是难以实现的。

举个最简单的例子,一个<input type=”text” />就是一个浏览器内部的对象,你无法扩展这个对象的类型,也无法为它加上新的属性与方法,至少并非所有浏览器都允许你在JavaScript中这样做。然而如果你想要让它加上auto-complete(或曰suggest)的功能,这是可以做到的,并且很多人都做过了,例如ASP.NET AJAX Control Toolkit的AutoComplete,或者是script.aculo.us的autocompleter。这些实现都基于同一种方式,就是尝试基于input已有的接口在它之外添加新功能,而非尝试继承input并在它之内添加功能。

类似的做法在Ajax开发中普遍存在。例如说拖放吧,现在离HTML5拖放的全面普及不知道还有多远,所以大家都只能基于现有的鼠标事件来开发拖放功能。又或者说带有验证功能的输入框,无论是input还是select,无论是客户端验证还是服务器端验证,也都是基于现有HTML元素的事件来完成的。这一切都是Behavior。

什么情况下使用Behavior?

简单归纳,就两个条件:

  1. 需要基于特定的一个组建进行扩展
  2. 组建本身所处的环境缺乏可扩展性

单看第1个条件,我们有丰富的选择。很多人的第一反应就是继承自该组件,把扩展功能做到子类里面。熟悉设计模式的话,可能还会想到decorator pattern。然而在浏览器的环境当中,受到第2个条件的限制,继承或者decorator pattern都是不可行的。这时候,我们就需要使用Behavior了。

在一定程度上,我们可以把Behavior看作一种折衷了的decorator pattern。在decorator pattern中,decorator也继承自组件,因此当一个组件使用decorator pattern后,我们就把decorator放在原组件所处的位置上,而原组件就成了decorator的一个子节点(基于树的角度来看的话)。如果再加一个decorator,原decorator就会如同一个普通组件那样再被封装一次。在多个decorator的情况下,decorator之间是串联的关系。Behavior本身不是一个浏览器内部的组件,它无法继承自input的基类,因此Behavior也不能串联。Behavior本身本也不会取代input在树中的位置,这使得Behavior可以并联起来——一个input可以有多个Behavior,例如一个是自动完成,另外一个是输入验证。

总之,如果你原来的工作就是和UI打交道,并且熟练使用decorator pattern,那么在进行Ajax开发时把decorator pattern换成Behavior就可以了。

小结

回过头来看文章开头所说的MessageBox(或曰confirm)的问题,如果这个功能不需要对服务器端进行反馈,完全可以使用Behavior实现。ASP.NET AJAX Control Toolkit就有ConfirmButton这样一个东西,在客户端叫Behavior,在服务器端叫Extender,其实Extender就是对Behavior在服务器端做一下封装而已。当然,ConfirmButton不能完全实现MessageBox的功能,它只能在用户选择“取消”时取消整个提交操作,但不能够执行另外一个服务器端的代码分支。这算是Behavior的一个限制,就是它只能在客户端添加额外的功能,但是它不能影响到与服务器端的交互。但很多时候,正是这种限制确保了我们开发的组件是与服务器端解耦的。

如果我真的需要一个与服务器端交互的客户端组件,例如支持调用服务器端代码分支的confirm,怎么办?这时候你就真的需要一个与服务器端Control对应的客户端Control了。请关注本系列的下一篇文章,《以服务器端为中心的 ASP.NET AJAX 模式 (Part 2 – Control)》。通过订阅feed,你可以及时获得文章更新:

P.S.既然提到了Behavior和Extender的一一对应关系,就不得不说一下,服务器端的Extender就是真正的decorator pattern。

2008年10月26日星期日

远离国内的 SNS

最近我一直在想是否要把海内的帐号终止掉,原因只有一个——我很久不上海内了。既然我不用它,我就没必要把我的个人信息放在上面,让更多不认识的人有机会获取到这些信息。

如果要详细解释这件事,就要从很久很久以前说起,就是海内刚刚开放注册的时候。在改为邀请注册之前,海内曾经开放注册过几天,让及时获得消息的geek们第一时间获得了帐号,那时候我还没有多少好友在上面,已有的好友没有多少活动,news feed自然不值得一看。

后来,海内上的好友逐渐多起来了,大家也更活跃了,这是我认为海内最好的一段时候了。虽然,这时候的news feed算法也不怎么样,例如不会把同类项合并了,也不会对信息按照重要程度进行过滤。我之前也说过,Facebook的真正价值就在于它的news feed,news feed的算法不行也就以为着海内能为用户带来的价值优先。

随后,海内开始把重心转移到游戏开发上来。买卖好友可以说是为了刺激用户数量的扩张,但越来越多的游戏上线让我觉得整个海内都变得以娱乐白领为首要目标了。我的个人观点是跟BeanAwflasher差不多,虽然中国人口众多必然导致劳动力过剩,但让每个人都把自己过剩的劳动时间投入到游戏当中并不是好事情。当海内的news feed充斥着各类游戏相关的信息时,我就不再去看海内了。

说完了海内,国内的其他SNS我想也没必要一一列举了。海内曾经是国内最用心用力想称为白领SNS的一个了,国内其他成功SNS的目标从一开始就定为娱乐性SNS,短期内不可能得到比海内更有价值的结果。在这里我所说的价值不是指SNS本身的商业价值,而是指推动国内SNS用户素质提升的价值,是指创造SNS之外的商业价值的可能性。

2008年10月24日星期五

China MVP Open Day 2008

一年又过去了,去年的MVP Open Day在三亚,今年改成了在北京,我甚至连飞机也不用搭了,只需要打的参加(也要¥99)。

我是17号晚上和飞飞一起从中关村打的去汤山的。Bean则是当晚深夜飞过来,很可惜Bean不知道联合航空到北京的飞机是停南苑机场的,结果从南苑机场打的到汤山还费了他不少时间和金钱。Dflying早些时候就飞来北京了,不过不知道去哪里玩了,竟然18号晚上不到酒店让我一人独占房间。18号晚上去到后,人都散了,只是见到了Sisley、Eddie等人在筹备第二天的晚会,当然还有排舞的老葛等人。

由于晚上看Wanted看到凌晨两点,18号一起来就赶去吃早餐,接着就见到了Mango和Bean。由于我第一天晚上没有签到,吃完就马上赶去签到领衣服——没办法,早上的keynote规定大家要穿统一的衣服。keynote上讲了很多东西,还颁了奖——就是MVP每年一块的水晶座,今年是奥运年所以是火炬造型的水晶座——不过整个早上最让大家兴奋的应该就是那台Surface了。据说中国只有一台Surface,放在MSRA,估计就是那一台了,现在拿来向我们展示WPF如何开发Surface应用程序,keynote之间我们就都冲上台玩这台Surface顺便拍照。

中午的午餐组织得有点混乱,实际上整个MVP Open Day都组织得比较混乱,不知道是不是因为会务外包了给CSDN。据说因为会务很赚钱所以CSDN现在热衷于做这个,不过确实不太专业。

接着就是下午的一对breakout session了,不过没有哪个我特别感兴趣的——完全没有ASP.NET或者Silverlight的session嘛……我和Bean在户外找了个地方坐下来上上网聊聊天,后来俞晖也加入进来了,包包跑过来和我们照相,Dflying说公司有事要立即赶回上海(他还真没在酒店住过一晚)……整个下午我就没有专心听过一个session,都是周围跑去见别的MVP。

午餐按照技术特长来分组,晚餐就是按照地区来分组,俞晖和紫柔跑来我们广东桌装广东人,俞晖还是忘记不了说他喜欢吃螃蟹并且对于没有螃蟹感到可惜。我则一再要求紫柔把我从Web版主调回ASP.NET版主,因为当初无拉拉被分到Web版主实在让人郁闷,大部分IIS、IE之类的问题我都无法回答上来,也不确认其他人的回答是否正确。

晚餐之后就是晚会了,一个半小时其实不算长,不过留下更多时间给MVP交流也是对的,随后就是博客园的MVP聚会。在博客园上的大部分MVP都来了,没来的据包包统计大多都是上海的,例如Jeffery Zhao——我很好奇他所谓的减肥成功到底是什么效果,可写他就是不出现。博客园的聚会,就是大家各自自我介绍,然后分组讨论,晚上黎波来了——他虽然没有MVP连任成功,不过刚好也在北京为Microsoft的客户部署项目——我就和他聊了一下Sharepoint。回到房间之后,我叫了Bean过来聊天,不过没聊到什么他就回去睡觉了。

19号早上是拓展训练,就是盲人方阵和毕业墙两个项目,我们组做得还不错。中午吃饭后就是期待依旧的参观鸟巢了——其实我一直不认为鸟巢如何如何特别,不过倒还是个很值得拍照的地方。一群MVP搭大巴来到鸟巢,被告知水立方和玲珑塔都不对外开放了,于是只能进入鸟巢参观。整个广场确实很大,不过设计确实不怎么样,很多地方都很不人性化——鸟巢很多长长的楼梯,出去少数电梯后竟然没有扶梯,这叫来自发达国家习惯走到哪都是扶梯的人怎么适应呢?整个广场那么大,座位放了很多但就是不见洗手间,垃圾分类就不要期望了因为连垃圾桶都是那种很丑陋带轮子的。简单来说,看看鸟巢就知道典型的北京本地价值观了——很追求体积上的庞大,或者说是“排场”,但是不注重细节,也不懂得什么叫人性化。

参观完鸟巢后,拍了几张集体照就解散了,去机场的、去火车站的、直接回家的……基本上都涌进了地铁站,然后各自超自己的方向走。

2008年10月20日星期一

有空要做个 Theme Software Corp 的游戏

当年Theme Hospital的搞怪实在让人怀念。各种奇特而富有创意的病症,与之配合的神奇治疗方法,还有行为略显怪异的医生和护士,组合起来是那么的有趣。现在在IT公司中的生活,感觉也很有趣,虽然有些事情也挺烦人,不过却是不错的谈资。

将来如果有时间做游戏,就做一款Theme Software Corp。市场是有各种奇怪的需求,然后要请PM来做研究并得出产品开发计划,再要请SDE来开发,之后还要请SDET来提高质量。为了保证这群人的满意度,和招聘到更加高级别的人员,必须购买各种设备来满足他们奇怪的生活需求,从咖啡机到按摩椅,还有Wii、XBox360或者PS3,甚至自己建移动大厦加一个游泳池。结果发现这些人每天来到就去拿咖啡或者可乐,然后开始看看feed,最后工作一会儿又闪出吃饭了。你想尽办法利用他们的才能,但是innovation的发挥却是很不稳定的,项目不停delay士气下降,你又要投资点什么来补救。

总之,这个游戏应该继承Theme Hospital的一些关键特性,游戏中的各种事件都是很无厘头的,同时你又要努力balance游戏中不同的指标——正如Dreaming in Code中说到的质量三角,时间、金钱、特性三者不可能都得到,在追求其中一个的时候必然削弱另外的两个。这样在有相当游戏难度的同时,又有娱乐性可言。

2008年10月10日星期五

最糟糕的一次飞行经历

星期天晚上从广州飞北京,登机和下机的安排都极差!

在广州白云机场的B区登机,又是一层登机口,意味着肯定是搭摆渡车的。开头以为好像上次那样,飞机是国际航班转飞国内,所以停在A区空地了,结果还真是这样,而且还不是停在A区空地——是泊在A区登机桥边了!那天广州暴雨,如果飞机停在空地,登机专用车是有遮顶的,这样登机还不至于淋湿。但飞机泊在登机桥边了,就要从地面爬上登机桥(我终于知道登机桥边的楼梯有什么用了),楼梯是没有遮顶的,所有人都是淋雨之后才走进飞机的。

到了北京首都机场后,被告知地面在调整停机位,要重新分配机位后才能下机,然后飞机就停在了机场空地上足足等了30分钟!不知道乘客与空姐吵起来是否有推进作用,最后停机位并没有怎么“分配”法,飞机就在原地把我们放下,然后让摆渡车接我们走。浪费那么多时间才出摆渡车,一早这样做不就好咯,机场的调度真是差。

2008年10月4日星期六

什么时候才能在网上收到广州和香港的节目呢

Sean O'Driscoll的一条tweet,说能够在网上听到Seattle的电台感觉离家里近了,让我再次想起如何能够在北京接受粤语节目的问题。

在北京最郁闷的事情,暂时来说,就是无法接收到任何广州或者是香港的节目,无论是电视还是广播。试用过很多P2P的网络电视平台,暂时来说最满意的就是TVU收看凤凰卫视了,至于TVB——虽然有人转发到网络上,但是peers太少,从来没有成功看到过,就是见到list上面有TVB的名字。

关于接收TVB,Catfish总是建议我接收卫星信号,因为他以前在北大就是负责把信号送上卫星的。但是这个方案对我来说也太不现实了——我连电视机都没有呢!我从来只有电脑,电视对我来说是多余的,所以在北京租的房子自然不会买电视。

除此之外,还有别的办法吗?我不停地问身边的人这个问题,但一直没有找到有效的解决方案。

2008年9月21日星期日

Vista 为什么要引入 UAC

UAC的目标就是:干扰用户!这其实不是我独创的,而是从TWiT上听到的一种见解。

UNIX的命令行有sudo,Mac在GUI上也能够在需要sudo调用时弹出对话框要求输入密码,然而这两者的出现频率比Vista的UAC要低得多。为什么UAC的出现频率那么高呢,难道是Vista的用户体验设计得有问题?显然不是这样,Vista的UAC就是设计来不停地干扰用户的。

干扰用户随之而来的是什么?就是用户觉得这个软件很烦,然后逐步放弃使用这个软件,转而使用同类软件中不那么烦人的。这个过程会逐步把经常进行UAC调用的软件从是场中淘汰掉,如果你的软件不希望被市场淘汰,你就必须尽量减少UAC调用,也就是减少系统调用。

最终,市面上大量滥用系统调用的软件会逐步消失,要么自身改进,要么自然淘汰,从而提高了Windows的安全性。等一下,这跟Windows的安全性有什么关系?假若你的代码要执行系统调用,同时你的代码是有漏洞的,就可能由于你的程序漏洞而导致系统受到攻击。但如果你的软件本来就不需要做任何系统调用,就算有漏洞也不会连累Windows,Windows也就显得安全多了。

P.S.当然,还有一些非系统调用也需要UAC,例如对C:\Program Files的写入操作。这是因为Vista认为这也是个危险操作,而程序应该将数据存放到C:\ProgramData来实现可执行代码与数据的分离。

2008年9月18日星期四

强烈推荐 Spore 这个游戏

由Spore发布到现在,一直在玩这个游戏,觉得挺有趣的。虽然有人说创意没利用好,操作具有重复性,不过这个游戏享受的正式创造的乐趣,而非好像RPG或者RTS那样,要通过竞技赢取什么。如果你以竞技的心态去玩,那么这个游戏就很无聊了,因为你赢了一次之后,就发现再玩也是走类似的路线,不值得重玩。但是如果你享受创造不同的生物,利用他们不同的特性来进行游戏,那就很好玩。

Spore有趣的地方在于,你在里面总能够碰到各种各样奇怪的事情。在cell stage,你会发现合理组合装备的重要性,刚刚开始有针刺的时候就可以把针刺装在前侧,然后刺体积比你大多了的生物。如果你发现不够灵敏,总是没把对方刺死就被吃掉了,那么你可以加高性能的运动器官,但前提是你又要先杀死一只有该器官的生物来获取它。到了creature stage,你可以看到举行的epic creature,这其实是其它space stage文明通过supersize工具制造的。在tribal stage,你可能会看到UFO──也就是其它文明在space stage的飞船,他们可能把地上的生物吸走。总之,在整个游戏过程中,你都会感觉到银河系中充满了各式各样的文明,在你还没觉醒的时候他们就来造访你所在的行星了,而且还会制造各种奇怪的事件,例如麦田怪圈。

暂时Spore只有英文版和繁体中文版,不知道什么时候才在内地上市,或许我会去买一套简体中文版,把它的cd-key用到英文版上,然后连上EA的服务器玩。Spore是我认为挺值得收藏的一个游戏。

第一次开 OT 开到 1:30AM

终于体会到软件工程嘅焦油坑,唔单止需求唔明确成日变,而且相关人员太多──我啲嘅项目相当于通用型项目,同各个已有嘅产品线都有合作,项目嘅任何改动都要通知各个有关产品线嘅PM,等佢哋嚟确认新嘅行为係合理嘅,同时又要各个产品线个QA嚟重新测试,确保哩啲改动唔会影响到原有嘅协同功能。

2008年9月15日星期一

如果浏览器 geek 到能够随意换 kernel

Google Chrome是开源的,所以只要你有兴趣你都可以去Google Chrome的SVN把源代码check out下来看看,然后你会发现它用到了大量第三方的开源组件。

在过去,浏览器总让人觉得是一个monolith般的东西,一个大整体,内部耦合度高,很难在一个浏览器中复用另外一个浏览器的组件。准确来说,浏览器按照内核分成了几族,族内的组件倒是通用的,但族外的就不通用了。但是在看到Google Chrome如此组装开源组件后,才发现其实浏览器也有可能发展到能够跨族相互融合的程度。例如Google Chrome是基于Webkit的,然而JavaScript引擎换了V8,所以执行效率比Safari高多了,而渲染引擎换了Skia,因此暂时看起来没Safari那么精致,支持的CSS3也没有Safari那么全面。

将来的浏览器,或许会像Linux一样按照distro(distribution)来划分。安装插件已经不能满足geek的需求,所以选用什么组件变得可以自定义。浏览器与浏览器之间的组件复用壁垒不会好像现在那么高,programmer已经可以轻易地从一个浏览器借用代码复用到另一个浏览器上,然后制作自己的distro。

2008年9月2日星期二

Firefox Ubiquity

对于喜欢命令行(command-line)或者喜欢Mac上的QuickSilver的人来说,Ubiquity实在是太好用了。如果你的Firefox还没装上Ubiquity,那就快掉去装一个吧,虽然现在的只是0.1.1 alpha。

装完之后,可以体验一下Ubiquity内置的command,地图搜索或者翻译之类的其实还是挺好用的,但我觉得重点还是在于可以自己写新的command。官方的Author Tutorial简单介绍了一些开发command的基础知识,如果要深入学习的话就要看看别人的command是怎么写的,以及看看Ubiquity的源代码。

由于我觉得Ubiquity实在太符合QuickSilver的用户习惯了,所以我以后做Web应用程序都会考虑加上Ubiquity的支持。

2008年8月30日星期六

如何动态加载 JavaScript 与 CSS

Omar AL Zabir这位MVP总是喜欢搞些稀奇古怪同时又很实用的小东西,并且还十分值得参考。最近他就做了一个叫做ensure的小工具用于动态加载JavaScript、CSS与HTML,而且IE、Firefox、Opera、Safari都支持了,那么我们就来看看ensure是如何做到动态加载JavaScript与CSS的。

在介绍ensure内部的实现之前,让我们先来看看其功能:

ensure({
    html: "popup.html",
    javascript: "popup.js",
    css: "popup.css"
  }, function() {
    Popup.show("hello world");
  }
);

在这段代码中,ensure首先会确保popup.html、popup.js、popup.css这3个文件的加载,如果都没加载过ensure就会动态加载它们;如果已经加载过了,ensure不会再次加载。在确保这3个文件都加载后,ensure会调用后面的匿名函数,也就是执行Popup.show("hello world");。

接下来,就让我们看看ensure是如何动态加载JavaScript与CSS的。

加载JavaScript

在ensure当中,加载JavaScript分两种情况来执行,也就是Safari与非Safari这两种情况。

在IE、Firefox、Opera中加载JavaScript

在这三款浏览器中加载JavaScript,其实只需要创建一个script元素,把src指向要加载的URL,最后把script元素追加到head元素上,那就搞掂了。此项工作是在HttpLibrary.createScriptTag()中完成的。不过我们不仅仅要加载JavaScript,同时还需要知道它什么时候完成加载,这可以通过script元素的onload事件或onreadystatechange事件来实现。

在Safari中加载JavaScript

因为Safari 2不支持onload或者onreadystatechange,所以只能手动通过XHR把URL读去过来,然后再手动eval这段代码,这就带来了一个限制──只能加载本域的JavaScript文件。在ensure当中,eval的工作是通过HttpLibrary.globalEval()来完成的。为了让JavaScript代码在全局(global)上下文中eval,ensure还是使用了创建script元素的方法,并将要eval的JavaScript置于其内,最后把script元素追加到head元素内。

细心的人肯定要问,为什么HttpLibrary.globalEval()要如此设计,而非直接window.eval或者eval.call。这是因为,window.evaleval.call都无法在IE6中实现和script标签加载JavaScript代码一模一样的效果,这两种做法的eval在IE6下仍然不是在全局上下文中执行的。搜索一下你就会发现一些相关的讨论,例如jQuery就曾经使用window.execScript()来完成此项任务。不过最终大家都发现添加script元素才是最好的跨浏览器解决方案,所以现在的jQuery和ensure都是如此实现的了。

加载CSS

相对于加载JavaScript而言,加载CSS就简单多了,而且方法也是类似的:在head元素内直接加入link元素就可以了。这也正是loadCSS()所完成的工作。

实际上,ensure没有确保CSS完成加载后再执行下去。这估计是因为浏览器都能够在CSS加载完成后自动应用到页面上,因此Omar AL Zabir就认为CSS的加载顺序是无关紧要的,不过假如CSS加载速度实在太慢,其实还是会影响显示效果的。

在IE6中加载CSS

这次需要特别照顾的是IE6,而非Safari。IE6在往head元素添加link元素时,必须在window的上下文中完成,因此添加link的函数通过call调用切换了上下文。

总结

实际上动态加载JavaScript与CSS都并不难,在大多数情况下只需要向head元素追加对应的子元素就可以了,只有Safari2和IE6这两款古老的浏览器是需要特殊照顾的。

开始使用 MarsEdit 写 blog

缺少一个客户端,我就总是懒得打开Blogger来写blog。当然,Blogger还算好的,我可以写着写着就按一下save按钮,然后继续写。博客园还不能就地保存,保存一下必须离开编辑页,然后还要重新打开编辑页。我实在无法忍受从PC切换到Mac之后没有客户端的情况……其实是有过一段时间用客户端的,那就是MarsEdit

在MarsEdit的试用期过后,我又懒得写blog了。在忍受不写blog与购买MarsEdit之间,最终我选择了购买MarsEdit,这个价值$29.95还周围都找不到coupon的东西。作为一个shareware,它真的做得不错,但$29.95又实在太贵了,Speed Download那么强大的下载软件也就$25嘛。

在买MarsEdit时,发现可以用PayPal,想起之前注册PayPal时验证信用卡后有$1.95存在PayPal上面了,决定就用PayPal支付,把那$1.95余额花掉。接着在PayPal的页面看到,原来通过PayPal来购买外汇超级是超级贵的。根据今天Yahoo Finance公布的汇率,1CNY能够买入0.1459USD,但是PayPal说1CNY只能买入0.141154USD,实在相差太远了。幸好,PayPal允许你选择不用它来做购汇,用回VISA的购汇功能,只不过支付时无法确定最终购汇汇率。如果VISA的购汇汇率不至于那么离谱,还是VISA比较省钱。不过到底VISA购汇价格如何,我还真的没有留意过,以后要仔细研究一下帐单。

2008年8月21日星期四

MobileMe 真应该免费 beta 一年

服务上线两个星期,就因为服务质量问题表示道歉,每人送30天试用期。然后因为港币用户的验证费用扣错了(应该扣1USD,实际扣了100HK$),又再送30天试用期。现在又因为近期服务不稳定,再给大家60天试用期。加上注册时的60天试用期,这已经是180天了。

对比起这样不断道歉和延长试用期的做法,Apple还不如学习一下Google,让服务免费beta,让更多用户来发现bug和汇报bug,等服务成熟了再开始收费。当然,这样做的坏处是Apple必须保留免费用户,否则全面转为收费的话,很多beta阶段的免费用户都会流失掉。

2008年7月29日星期二

北京地铁比广州地铁落后多少年?

星期六跑去三里屯看了一下“中国第一家Apple Store(非Apple Authorized Reseller)”,是搭最近开通的10号线过去的,感受了一下10号线的整体装修,觉得能够比得上广州3号线、4号线的水平,对北京地铁略微有改观。非常可惜的是,10号线全线没有手机信号覆盖,我觉得这实在是太落后了。

据说以前北京1号线和2号线也是没有信号覆盖的,但是后来改进了。10号线作为全新开通的线路,应该在设计阶段就考虑到这个问题,然而现实却是正好相反。想想10年前广州1号线开通,就已经解决了这个问题,而北京现在开一条10号线,还要是迎奥运了,都解决不了这样一个问题,只能说北京地铁比广州地铁要落后10年。

北京地铁还有一个搞笑的地方,就是所谓的“自觉安检”,安检不是放在必经通道上,必经通道旁边,人少的时候安检人员还能认出谁的包包经过机检了,人多的时候根本分不清,只听到安检人员说“请自觉打开包包接受检查”,很多人根本就不理,直接走过去了。还有一个搞笑的地方是,Singzy说她早上赶去机场时,本来想坐机场线,结果地铁安检说他们的行李体积过大,不能带进地铁──竟然航空公司能够接受的行李体积,地铁安检不能接受,那么北京赶在奥运之前开通机场线又是为什么呢?貌似机场线还有一列迎宾专列,估计就是专门用来迎宾的吧。

2008年7月5日星期六

去给韶关移动做讲座

Bean之前一直说去给移动做讲座的事情,说要讲讲互联网的新玩法新思维,最终在这个星期五去给韶关移动做了第一讲。

玩转互联网信息沙龙

这次我们讲的是购物和SNS这两块,Bean负责讲购物,而我负责讲SNS。我看了一眼听众名单,发现来的都是韶关移动的老总,至少都是部门经理级别的,第一次做这样界别的讲座,我当然紧张。Bean说,要讲得简单一点,避免涉及技术,让他们明白怎样好玩就行了。所以我准备的内容,更多是介绍性的,而不涉及更深层次的问题。最终讲完,得到的反馈还算不错,不过我想他们还是希望多听听关于商业模式的东西。移动很有野心,想要做自己的互联网平台,从而避免自己最重成为纯粹的互联网访问介质,因此移动的老总们都很关心现在的互联网思维模式。

另外,这是我第二次尝试用Apple的Keynote做演示,当然想要做得比第一次好,让画面和动画效果更加深入人心。感觉无论是PowerPoint还是Keynote,其实质都是差不多的,最重要还是表现手法,软件只是工具而已。

2008年6月30日星期一

Non-Catonese Speaker 取个 Cantonese 的名字干什么呢

时不时就能在网上认识到一些non-Cantonese speaker,却发现他们用的英文id取个港式音标,例如姓杨的取Young,姓蔡的取Choi,实在搞笑。

事实上,港式音标是威妥瑪拼音,并且是按照粤语发音来注的威妥瑪拼音。如果是non-Cantonese speaker,那么你可以用国语或者任何你所说的汉语口语方言来注威妥瑪拼音,但没必要用基于粤语的威妥瑪拼音。举个实际的例子,蔡依林的英文名是Jolin Tsai,就是按照国语发音来取姓氏的威妥瑪拼音,如果她按照粤语发音来取Jolin Choi,那就显得很不伦不类了。

因此,如果你不想用汉语拼音来给自己的中文名字取个拉丁形态,那么你可以选择威妥瑪拼音,但不要盲目选用基于粤语的威妥瑪拼音,假如你是non-Cantonese speaker的话。

2008年6月27日星期五

Purpose and Reality of Test

测试的目的是为了挑选,例如挑选高质量的人,然而这可能会成为一种反向激励──应试。这会导致候选人偏离测试所期望达到的质量,甚至出现劣币驱逐良币的景象。

还记得和状元同学开过的一个玩笑。由于某些琐碎事情,我讽刺他说,“做人怎么能如此不求甚解呢?”他说,“有什么不可以的,我就跟着老师说是正确的去做,我也不知道为什么这样做是对的,不求甚解当然是可以的。”当时我就把这当作一个玩笑,现在我明白这是十分正确的一件事,而且这就是反向激励的实现形式──为了应试,你必须牺牲测试所期望达到的质量,以换取应试能力。

因此,现实中的测试不一定真正能够挑选到高质量的人,而且还把人赶往了一个相反的方向。

2008年5月31日星期六

Social Software Configuration

social software满街都是,连一个最普通的论坛也算一个social software,但是social software最难的部分在于social而不在于software。

一个software可以有完备的需求分析,在很清楚我们要解决怎样的问题以及如何解决之后,再去实现这个software。然而social则是动态的,当一个social software投入运行后,social的部分才开始“实现”。举个例子来说,你想从零开始做一个博客园,software方面你可以从任何一个blog platform开始修改,甚至是从零开始编写,但是social方面呢?你明白你要实现的效果是一个有人气的技术博客社区,但随后没有OOAD这样的理论模型让你把这变成一组描述social模型的规则。虽然你知道要去吸引潜在用户、激励用户多写好的文章……但是这一切都仅仅是经验列成的规则。

随后,软件平台做好了,意味着software的编码与测试阶段都完成了,但是对social部分的实现才刚刚开始──用户逐步进驻,他们之间开始交互,而你则通过设置各种各样的规则来刺激整个social氛围朝你期望的方向发展。这个过程不像是开发,反而更像是测试于调试──首先,你测试现在的social氛围是否符合你的要求了,例如用户数量够不够,他们发文质量高不高;然后你找到表面上不满意的地方,对底层的规则进行修改,这些规则有可能是显而易见的,也可能是需要深度挖掘才能弄清楚的;如果要深度挖掘,那就成了调试了,在密密麻麻的规则当中尝试修改一下,然后看看效果,不行再改回来然后再做下一个尝试。

总之,social software拥有比一般software长得多的研发周期,假如把social部分也算上的话。并且最重要的是,每一次social开发的迭代都没有严格的方法论可言,大部分人都是通过经验来进行控制的。那么到底现在有哪些经验可以参考,这个以后再说。

2008年5月24日星期六

原来并非人人能习惯中英混杂

在Microsoft 2008 Launch广州站的会议结束后,我和Bean、黎波、张亮去了中酒旁边的McDonald's聊天。我说到“这是100%确定的”,读出来是“这是一百percent确定的”,然后黎波马上就问“你说一百什么”,Bean解释道“一百percent啊,就是百分之一白”。随后Bean又补了一句,“和Cat聊天聊多了你就能习惯这种中英混杂的说法了”。这时候我才突然发现,原来不是所有人都天生能适应中英混杂的说法的,即使他中文和英文水平都没问题。

随后,我又在豆瓣的搭讪小组碰到了一些更加negative的反馈,我才开始仔细分析这个问题。这应该属于文化背景的差异,港台文化都是习惯中英混杂的,geek自然也常常用英文,因为我属于上述两个圈子,自然我很习惯这样说话。但是对另外一些人来说,他们从小长大的文化背景中不包含英语这一元素,甚至在英语学习中遇到了种种障碍导致厌恶情绪的产生,这时候他们不仅仅不适应中英混杂的内容,甚至就认定你使用英文就是在炫耀你的英文能力。

廣東話俗語——雞髀打人牙骱軟

本文由Piggest授权转发

“雞髀”——鸡腿;“牙骱”——牙关(jaw, jawbone)。


整句合起来的“繁→简”机翻是:鸡腿打人牙关软。

在文字MUD年代,每每看见“鸡腿”这件武器/补给品,可以吃又可以打人,不由得想起“雞髀打人牙骱軟”这句俗语。用鸡腿打人到底可以达到什么效果呢?

“雞髀打人牙骱軟”的意思是,予之以小利,使对方对自己透露消息。有时亦指,予之以小利,使对方为自己美言几句或者在言语上偏袒自己。

例句:咁着数,唔通想“雞髀打人牙骱軟”?

“雞髀打人”实在太生动,所以这句话又广泛应用于以下情境:

为了获取利益或求人帮忙而请人吃饭;政府派利市拢人心;甚至在办公室派零食讨好同事亦算有“雞髀打人”的嫌疑。

可见得“雞髀打人”是中国人常用的社交手段,不含褒贬,是大家都能会心一笑了然于心的潜规则。

引申:“髀”即小腿,“大髀”即大腿。“打牙骱”——chip chat。

以上粤语发音,请见“粤语会馆”:http://www.yueyu.net/

2008年4月17日星期四

飞到美国了

离境的时候,觉得北京首都机场的国际安检很弱智。首先,在明明没有人排队的情况下,就把长蛇阵拉起来了,这证明排队从来没被很好地管理过。国外的长蛇阵,甚至是广州的各大银行里的,都是先放好若干横排,但是留两边的直行通道,随着排队人数增加,再把通道逐步封闭,这样排队就转到横排里了。在北京机场,根本没有直行通道这回事,再少人也要绕啊绕啊绕,太过弱智了。

过安检门的时候,首先要看登机牌,我们是自助打印登机牌的,一开始安检人员又看不懂这是否是合法通行证,又要确认一下。因为我们是去美国的,特意要求我们要脱鞋,也就是去其它国家可能不用脱鞋检查啦?那就是要根据机票来决定安检严谨程度啦?这样效率不低才怪呢。现在在登机之前,还有一个液体物品的检查,也就相当于两次安检了。我们到得很早,见到第二次检查的人由队长带着来打登机口前,然后一轮训话,说今天开始严查,所以大家不能随便开包看看问问就行,一定要认真查。结果呢?开包之后,还是很随便看看就行了。

在美国入境时,又是长蛇阵的排队,接着是入境面谈,问了一下来干什么的和要停留多久。开头我在海关申报单选了非business,结果入境官员说,别人付钱让你来的就是business,我说那就business吧。我可从来没想过,作为一个学生,有人出钱让我来开会,这也叫做business。在领到托运行李后,又被人“随机”扔去了过X光检查,真是不幸,不过X光检查的黑人倒好人,看到我是到Microsoft的,就很欢迎的样子,可能最近几天到Microsoft的人太多了,而Microsoft又是Seattle的支柱吧。我的箱子有北京托运来的标记,他就问我北京是不是在紧张准备奥运。

之后就出去了,就这么简单。当然,也有朋友被拦下来的,估计因为他在日本买了个新相机,然后未出关就在那里狂拍照,哈哈。

2008年4月12日星期六

黄金周

记得某几个学期,课非常少,一个星期就上两三天课,于是我们说“周周都是黄金周”。其实怎样才算是黄金周呢?我觉得你要是数着日子过,每一天都是回忆的,那才是黄金周。在大学里天天睡觉,又不记得梦见什么,上网太多导致时空感错落,这显然不是黄金周。

明天就飞西雅图了,非常向往,但也非常留恋在北京的不到5天。为什么呢?因为这5天很早就计划好了,从第1天开始你就是倒数着过,每天很清楚记得自己干过什么,因此印象特别深刻。举个例子,同样是在北京,我在百度实习3个月,印象就要浅一些,大概只记得第几周做过什么。这不是因为上班的问题,而是因为我站在第1天向前看就是12周,按周来倒数。如果我在百度的实习是5天,那么我也会清晰记住每天干了什么。

因此,黄金周在于日子倒数着过,而最好的方式就是去旅行。在北京这5天没有怎么出去玩,明天飞到西雅图一定要抓住唯一大家都有空外出的一天,去爽一下!另外期待暑假的德国之旅,如果能去成的话。

广州地铁三号线的算术陷阱

三号线作了一个奇怪的设计,就是一开始的列车只有三节,然后说将来要扩容了再加车厢。加车厢的问题在于,一旦要加一节车厢,现有的列车都必须同时加一节,这样才能确保开闭的屏蔽门是统一的。否则一列短车一列长车的话,乘客在长车车厢位置候车,发现来的是短车,他正对着的那个屏蔽门不开,那就很郁闷了。

这种设计,鼓励的是加独立的列车,而不是加车厢。然而,列车加得越多,加一节车厢的成本也就越高,因为同时要加一节车厢的列车数多了。这就变成了,列车越多,越不鼓励加车厢,越倾向于再加独立的列车。最终,整条线路已经无法再加新的列车时,列出数肯定已经相当多了,这时候加一节车厢的成本就会很大,因此加车厢的可能性反而很低。

我觉得唯一的可能就是,在列车很多的时候选择把短列车重新分组为长列车,多余的机车没所谓,反正机车肯定有冗余的,这样子才能避开这个算术陷阱。

2008年4月3日星期四

救救 Web Developers ,拒绝 IE6 !

这是最近的一场于web developers相关的campaign,官方站点是SaveTheDevelopes.org。在上面你可以下载一段脚本和对应的图片,放到你自己的网站上,然后只要有用户使用IE6访问你的网站,他就会看到一个小小的提示框,建议他升级到IE7或选用其它非IE浏览器。当然,你也可以直接引用SaveTheDevelopers.org上面的脚本文件,但大家都知道潜在的风险,因此最好不要这样做,如果你有自己的空间的话最好还是下载下来放到自己的空间上。

为了支持这个campaign,我特意为他们做了一个中文翻译。我本来是想和aw一起做的,不过他们把内容发给我的那个晚上找不到aw,于是有翻译问题就直接找Junyu问了,最后在Junyu的帮忙下把翻译搞定了。我在想是不是应该多做一个粤语翻译,这样会比较好玩,反正也就一个晚上的事情而已。

2008年3月24日星期一

深入理解 ASP.NET 动态控件 (Part 6 - 模板控件)

在之前的文章中,我极力推荐大家使用Repeater和MultiView这类TemplateControl,为什么呢?因为只有这样做,才算是符合MVP或MVC模式。(到底是MVP还是MVC,这视乎你选用什么呈现引擎了。)

虽然我们要动态创建控件,但实际上这部分控件仍然属于View的部分,我们应该尽量采用ASPX的声明性名义来描述这些控件,避免用C#代码来创建控件、设置属性并添加为子控件。就拿最简单的例子来说,创建一个LinkButton,通常我们都需要设置它的ID、Text、OnClick属性/事件,甚至还要设置OnCommand、CommandName、CommandArgument等属性/事件,那就是大概3到5个属性了,用ASPX来声明只需要1~2行代码,而用C#代码则需要写至少5行(把new和Add()也算上的话),由此可见在定义控件这类声明上ASPX比C#代码的可读性要高。

接下来,我们来研究一下TemplateControl是如何工作的,这自然要从如何编写一个TemplateControl讲起。

编写模板控件

在这里,我们假设要编写一个SimpleRepeater控件,自身不支持数据绑定,只有唯一一个名为ItemTemplate的模板,并且就按照Count属性指定的次数重复出现该模板。首先,让我们来定义这两个属性:
public ITemplate ItemTemplate { get; set; }
public int Count { get; set; }

因为ItemTemplate属性不是以键值对的形式在SimpleRepeater的声明中给出的,而是以内嵌一对标签的方式定义的,因此我们需要让解释器去把<ItemTemplate>...</ItemTemplate>中间的内容读取出来,并把解释结果作为ItemTemplate属性的值处理。这时候,我们就需要为SimpleRepeater类加上ParseChildrenAttribute,也就是这样子:
[ParseChildren(true)] public class SimpleRepeater {...}

最后,我们需要重载一下CreateChildControl()方法,把ItemTemplate的内容作为子控件添加到SimpleRepeater之内:
protected override void CreateChildControls()
{
if (ItemTemplate != null)
{
Controls.Clear();
for (int i = 0; i < Count; i++)
{
Control control = new Control();
ItemTemplate.InstantiateIn(control);
Controls.Add(control);
}
}
}

这段代码的用意应该是相当清晰的了,就是循环Count指定那么多次,每次循环创建一个空白的Control,用ItemTemplate.InstantiateIn()方法填充它,最后把它添加到SimpleRepeater.Controls里面,就那么简单。那么这个神秘的InstantiateIn()方法到底是干什么的呢?后面来解释。

编译模板控件

在之前的《深入理解 ASP.NET 动态控件 (Part 2 - 编译过程)》里面,我详细地解释了ASP.NET 2.0的编译模型。在《深入理解 ASP.NET 动态控件 (Part 5 - 编译实验)》中,我们又做了一个动手实验,亲眼看到了ASPX和C#代码是如何编译到一起的。现在让我们来看看当碰上模板控件时,代码会被如何编译吧。我们把上面编写的SimpleRepeater注册到页面上,前缀为ctrl,并且编写如下一段代码:
<ctrl:SimpleRepeater ID="SimpleRepeater1" Count="10" runat="server">
<ItemTemplate>
<asp:Button ID="Button1" Text="Button" runat="server" />
</ItemTemplate>
</ctrl:SimpleRepeater>

然后还是用aspnet_compiler编译一下,并且用Reflector打开编译出来的dll看看。我们可以看到构造SimpleRepeater实例是通过这样一个语句完成的:
return new SimpleRepeater { ItemTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control1)), Count = 10 };

这个语句其实就是一个普通的new语句,并且给ItemTemplate和Count两个属性赋值了,唯一值得关注的就是ItemTemplate的值。ItemTemplate的类型是ITemplate,因此任何实现了ITemplate接口的类都可以复制给它,然而我们却从来没指定过到底要赋值什么类型的实例给它,因为这已经由ASP.NET帮我们想好了,假若我们不指定的话,那就是CompiledTemplateBuilder类型。还是熟悉的Builder模式,它只需要已委托的形式接受一个实例化ITemplate的函数,然后就能返回实例化好的ITemplate控件子树。可能你会问,既然我已经有实例化ITemplate的函数,干什么要先传给你CompiledTemplateBuilder,让你来调用一下,再把实例化好的给我?我自己实例化不好吗?在此,ASP.NET引擎的做法只是为了保持Builder模式的一致性,处处用Builder模式来分离逻辑而已。

那么这个用于实例化ITemplate的函数从哪来呢?在解释器进入到<ItemTemplate>...</ItemTemplate>内部时,它会继续层层构建Builder模式,就如同在整个页面内执行的一样。因此,整个<ItemTemplate>...</ItemTemplate>会被解释器转化为一个函数,它也是通过层层调用内部函数完成自身的控件子树的构建,传递给BuilderTemplateBuilder构造函数的委托正是指向此函数。

因此,模板控件里面的内容将如同模板外的内容一样,被无缝地解释和构建到一起来。

INamingContainer

如果你查看SimpleRepeater输出的HTML代码,你会发现里面有10个<input id="Button1" name="Button1" type="button" value="Button" />。我们都知道,重复的id是不符合标准的,因此我们需要通过INamingContainer把这个问题解决掉。因为重复的控件是ITemplate,所以应该对它加上INamingContainer,然而它的实例编译时自动使用了CompiledTemplateBuilder,我们如何把INamingContainer加上去呢?我们就只能把INamingContainer加到它的父控件上面去。此时,我们需要一个实现了INamingContainer的简单控件:
public class SimpleRepeaterItem : System.Web.UI.Control, System.Web.UI.INamingContainer {}

然后我们把SimpleRepeater.CreateChildControls()方法的这个语句:Control control = new Control(),替换为:SimpleRepeaterItem control = new SimpleRepeaterItem()。这样,ITemplate的容器就变成了一个具有INamingContainer接口的控件,这时候各个Button的客户端id就会自动加上其容器的id作为前缀,因为容器的服务器端ID是自动变好的,所以必然是各不相同的,这样就解决了Button客户端id相同的问题。

通过这个例子,我们了解到了编写模板控件时必须为模板的容器加上INamingContainer,因为模板内的控件ID命名是可能重复的,加上INamingContainer就可以避免它们的客户端id重复。

小结

这次的文章解释了为什么我们应该尽量使用模板控件来实现动态控件,并且也说明了如何编写自己的模板控件,以及模板控件最终是被如何编译为Builder模式的代码的。

2008年3月22日星期六

每个 blog 都会有一堆 draft posts

lulu说她有个blog post选题的文件夹,我也有一堆blog post都draft存放于各处,可能是邮箱中,可能是Blogger的草稿中,也可能是Windows Live Writer等软件的草稿中。通常,一篇写得好的长文章都不是即兴而作的,而是用draft慢慢写出来的。有点点feel的时候,要逼着自己写成一篇完整的文章很难,反而当有几个draft都是同一个相近的题目时,可以合并在一起写成一篇好文章。

这估计是因为,如果只是有一点灵感,这是不全面的,很难自圆其说。当几个灵感合并在一起,就能看到概貌了,前因后果清晰了,正方反方都出场了,自然写出来的文章就会显得内容丰富一些。

2008年3月21日星期五

深入理解 ASP.NET 动态控件 (Part 5 - 编译实验)

这次的文章是一个小小的动手实验,你需要准备好Visual Studio 2005或者Visual Studio 2008,以及最新版本的Reflector。通过这次的实验,你将对ASPX与C#代码如何合并编译为一个dll代码有所理解。

在实验开始之前,首先来一个小问题:如果不允许你使用ASPX,要你完全使用C#代码写一个具备复杂控件树的页面你会怎么写?把声明控件的代码都放在Page_Load里面吗?或者有更好的代码编写方法?先想想这个问题,然后继续往下看。

实验的第一步,也就是在Visual Studio里面创建一个ASP.NET项目,并编写一个简单的ASPX页面。例如下面这个例子:(以下代码仅包括HtmlForm内的主体部分)
<asp:MultiView ID="MultiView1" runat="server">
  <asp:View ID="View1" runat="server">
    <div>Please choose either of the followings:</div>
    <asp:RadioButton ID="RadioButton1" runat="server" />
    <asp:RadioButton ID="RadioButton2" runat="server" />
  </asp:View>
  <asp:View ID="View2" runat="server">
    <div>Please choose any of the following:</div>
    <asp:CheckBox ID="CheckBox1" runat="server" />
    <asp:CheckBox ID="CheckBox2" runat="server" />
  </asp:View>
</asp:MultiView>

在这个例子中,我们构建了一个简单的控件树,同时又不至于过于复杂,确保了编译出来的代码相对简单一些。接下来我们就需要将它编译了,最简单的手动编译方法就是用ASP.NET 2.0自带的aspnet_compiler.exe,这个文件默认会在这个目录中:C:\Windows\Microsoft.NET\Framework\v2.0.50727。你可以使用aspnet_compiler -h来查看完整的帮助,例如编译一个IIS默认站点中的ASP.NET子站点可以使用这样的代码:
aspnet_compiler  -v / -p C:\inetpub\wwwroot\site C:\output\site

接下来,我们到输出目录的bin子目录里把dll抓到Reflector里面看看吧。你会看到这个dll里面有三个namespace,分别是-(在Reflector中代表没有namespace)、__ASP、ASP。假设你编译的站点有一个Default.aspx,那么在无namespace的类当中就会有一个_Default的类,对应的就是Default.aspx.cs编译出来的类。大家应该还记得《深入理解 ASP.NET 动态控件 (Part 2 - 编译过程)》里面提到的,直接继承自Page的类是用后台代码编译出来的,_Default类就是这样一个具体例子了。我们打开_Default类来看看,就会发现MultiView1已经是其成员了,为什么呢?MultiView1仅仅在ASPX中声明,没有在C#中声明啊。回头看看《深入理解 ASP.NET 动态控件 (Part 2 - 编译过程)》就能解释了这种现象——Default.aspx.cs是标记为partial的,而在你手动编辑的文件中,这是唯一一个partial,另外一个partial由编译器根据Default.aspx自动生成,编译器解释完Default.aspx后在自动生成的partial中定义了MultiView1,因此两个partial合并编译后,_Default类自然就有了MultiView1这个成员了。

接下来,我们再看看ASP这个namespace下的default_aspx类,这个是ASPX文件继承自上述_Default类后编译的结果,它完整表述了ASPX文件中整个控件树的逻辑,而不仅仅是一个包含一堆成员控件定义的Page派生类。这个类的执行入口是FrameworkInitialize()方法,它通过调用__BuildControlTree()方法来构建控件树。在这个方法里面,你可以看到<!DOCTYPE ...>这样的字符串是被解释为LiteralControl的,LiteralControl在Render()时就会把这段文本原样输出。同时你还可以看到,它调用了另外两个方法,分别用来构建HtmlHead和HtmlForm,这两个方法通过类似的形式继续调用其他方法来构建更深层次的控件。

通过阅读default_aspx类的代码,你已经能够理解ASPX的控件树是如何转化为C#代码的了——采用的正是Builder模式。了解到这一点,这次动手试验的目的也就达到了。如果你看到文章开头的那个问题时,你已经想到了使用Builder模式,那么此时也就验证了你的想法是完全正确的。

下一次的文章将是与TemplateControl相关的,我们将继续动手做一些小实验,敬请期待。欢迎订阅我的blog:

2008年3月14日星期五

在校学生找实习、找工作、了解企业情况等等等等

因为时不时就有低年级的同学跑来问我这类问题,所以我干脆写篇文章好了。

信息获取

最先想到的,也是最重要的,是你想干什么,而不是你父母想你去干什么,或者哪个赚钱之类的。在计算机系里面,你总能碰到一些对这个行业没什么感觉的人,他们会说当年填报志愿的时候根本没什么喜欢不喜欢可言,于是在父母驱使下或者金钱诱惑下就报了计算机系。显然你不想犯这类错误,因此第一步是弄清楚你想要什么,或者说,有什么是你可以选择不要的。世界上没有十全十美的事情,所以一切都是权衡取舍(trade off),这个思想贯穿着计算机体系设计的方方面面,缺乏这种思想肯定会导致你在这个行业里发展受到限制,所以首先你要想好的就是你将来的职业发展取什么而舍什么。

在你先清晰了解自己之后,才有如何了解企业实际情况的问题。如果说第一个问题严重依赖于你个人悟性的话,那么第二个问题就依赖于你的人脉了,至少是你的外向程度和活跃程度。

一个企业,其自身对外的公关肯定只会说好话,就算没有任何夸张成分,也不会让你看到这个企业内部任何的不足。因此,如果你需要知道一些细节,看看这企业是否如你想象中那么好,你就必须认识在这家企业里面的员工,通过他们好好了解一下。如果你是一个在学校里已经很活跃的学生,整天在BBS上板聊,或者参加各种学生社团的活动,那么你肯定有机会认识到不少比你高一两个年级的同学,看看他们里面有没有一些正好在你想去的企业工作的,联系他们了解一下企业的情况,例如工资和各种福利怎么算啊,工作与学习的氛围如何啊,以及他们是否也认为你适合这个企业。

如果有机会多问几个人的话,最好都问问,并且以人生经历和价值取向与你相近的人的说法为主要参考。这是因为,在同一家企业里面,不同的员工看到它不同的方面,并且都带有自己的主观想法,因此得出的评价可能截然不同。这就好像假如你问我北京是否好住,我肯定说不好住,因为我看重的是商业环境,我觉得北京的服务业经常让我失望,因此就这样说。但肯定也有人很喜欢住北京的,他看重其他一些因素,并且觉得我看重的那些因素可以忽略不计。如果你确实很想去一家企业,就应该多找几个员工了解情况,特别是头脑清晰能看清楚自己所在企业优劣势的人。如果你碰到一个已经被洗脑的员工,那么问什么也没用,反正他就只能帮你洗脑……

联系途径

根据往年的经验,现在正是2009年毕业的学生找实习的时候,甚至有2010年毕业的学生也提前开始找实习了。积极的人肯定早已开始四处打听消息,包括各大公司招聘什么实习职位,往年难度如何,转正比例多少,等等。在这里,我就要“曝光”我身边的一些朋友了,大家不要怪我“出卖”朋友了哦,因为谁都知道成功把有才华的人推荐给自己公司的意义所在。

在这里,我主要说的是BGM(Baidu、Google、Microsoft的意思,不是background music),如果你对其他IT企业有兴趣的话,也可以找我帮忙,只要我认识该企业的人,我会充当一下“路由”的角色为你“尽力服务”的。

Baidu

如果分别把BGM比作人的话,Baidu是一个典型的中国年轻人,一点都不张扬。就如同在中国随手抓一个ASP.NET MVP问他,“你是不是很熟悉页面生命周期”,他可能回答道,“懂一点吧,有什么问题你先说说看。”虽然从资源(resources)的级别来说,Baidu是很难和Google、Microsoft去比的,但是开放程度(openness)还是是相当高的,你可以做自己喜欢做的项目,可以获取到项目所需的资源。

想去Baidu的可以找我,或者布丁,先了解一下。当然,如果你来找我的话,最好你也能说服我为什么值得推荐你。我主要做Web前端开发的,而布丁则是做后端开发的,所以如果你想申请这两个方面的职位,可以直接找我们了解Baidu现在所采用的技术或者流程。如果是其他职位,也可以帮你联系其他同事问问。完整的实习职位列表,请看这里

Google

Google是一个典型的美国年轻人,你不问他也会很主动地把他的优势展示给你看。在我看来,Google最大的诱惑不在于公司内的“饮食娱乐”项目(虽然这些也很吸引),而是作为一般的中国员工也可以随便跑到美国总部去,顺道参加美国举行的一些会议或者讲座。看看Junyu同学就跑到Austin去开SXSW了。

如果想去Google的话,去找Junyu问问吧。别告诉我找不到他的联系方式,我通常只链接别人的blog,因为该URL就是个人的标识(即使抛开OpenID不谈),拿着这个URL你手上就已经掌握了搜索他联系方式的一切资料。Junyu喜欢把人拐卖进Google里,想了解招聘职位什么的,找他就好了。

Microsoft

Microsoft是个稳重的美国中年男人,Google所晒的东西,Microsoft会暗自想着“我当年又不是没晒过,现在我已经不屑于晒了”。很成熟的流程,健全的管理体制,都很好地说明了这一点。

貌似我没有很熟的朋友在Microsoft,不算太熟那些又不敢晒出来,所以想找人推荐的话还是联系我,然后我再帮你联系吧。想了解的话,可以找Jeffrey或者Dflying这两位老员工加现任MVP,他们现在不再是员工了,可能观点会更加客观一些。

其他事情

据我所知,很多人也是准备找实习了,才想到要写简历的。这是一项需要创意的工作,在此我提供我的简历Junyu的简历给大家作为参考。虽然我们的网站下方都写着Creative Commons License,不过不建议你直接使用别人设计好的模板。特别是,假如你想申请Web Developer/Designer类别的职位的话,你可不能够错过这个机会好好展示你的设计风格和编码艺术。

最后,祝大家在08年里都能找到自己喜欢的工作学习环境,好好享受生活。

2008年3月8日星期六

使用 .NET 实现 Ajax 长连接 (Part 2 - Mutex Wait & Signal)

在上一次的文章中,我们说到了如何设计一个ASP.NET Web Service来处理长连接请求。很多人对此就提出了问题,如何hold住请求让它30秒不断开了?这其实很简单,只需要Sleep()一下就可以了:

Thread.Sleep(30 * 1000);

然而问题是,我们不是要等30秒然后看看是否有事件需要返回,而是在这30秒内随时有事件随时返回。因此,我们需要一套机制来在等待的过程中检查是否有事件发生了。

Monitor模型

在.NET里面,大家最熟悉的线程同步模型应该就是Monitor模型了。没听说过?就是C#的那个lock关键字,实际上它编译出来就是一对Monitor.Enter()和Monitor.Exit()。

通过lock命令,我们可以针对一个对象创建一个临界区,代码执行到临界区入口时必须获取到该对象的锁才能执行下去,并且在临界区的出口释放该锁。然而这种模型不太适用于解决我们的问题,因为我们需要等待一个事件,如果使用lock来等待的话,那就是说要先在Web Service外部把对象锁上,然后等事件触发了就解锁,这时候Web Service才顺利进入临界区域。

事实上,要进行这类型的阻塞,还有一个更好的选择,那就是Mutex。

Mutex模型

Mutex,也就是mutual exclusive的缩写,“互斥”的意思。Mutex是如何运作的?这有点像是银行的排队叫号系统,所有等待服务的人都坐在大厅里等候(wait)被叫,当一个服务窗口空闲时它就会发出一个信号(signal)来通知下一位等候服务的人。总之,所有执行wait指令的线程都在等候,而每一个signal能够让一个线程结束等候继续执行。

在.NET里面,wait和signal这两个操作分别对应Mutex.WaitOne()和Mutex.ReleaseMutex()这两个方法。我们可以让Web Service的线程使用Mutex.WaitOne()进入等候状态,而在事件发生时使用Mutex.ReleaseMutex()来通知Web Service线程。因为必须在Mutex.ReleaseMutex()发生后Mutex.WaitOne()才可能继续执行下去,因此能够执行下去就证明必然有事件发生了并且调用了Mutex.ReleaseMutext(),这时候就可以放心地去读取事件消息了。

简单示例

在选定使用Mutex模型后,我们来编写一个简单的示例。首先,我们要在WebService派生类内定义一个Mutex,还有一个代表消息的字符串。

Mutex mutex = new Mutex();
string message;

然后,我们定义两个WebMethod。为了把问题简单化,我们选用上一篇文章中开头所说的两个函数签名,也就说只能在一个Web Service内自己发自己收,没有发送目标的概念,也没有超时的概念,还没有可靠性设计。同时,我们将Message类型替换为普通字符串,以便于我们测试。

我们先编写发送消息的函数:

public void Send(string message) {
  this.message = message;
  this.mutex.ReleaseMutex();
}

在这个发送函数里,首先我们把消息放进了类内全局的变量中,然后让全局的Mutex类释放一个signal。这时候,如果有线程在等待,它可以马上执行下去。如果此时没有线程在等待,那么下一个wait的线程执行到该阻塞的地方就能够不受阻塞继续执行下去。

现在我们来编写接收消息的函数:

public string Wait() {
  this.mutex.WaitOne();
  return this.message;
}

接收函数一开始就进入wait状态。在得到signal后,需要做的事情就是把全局的消息返回给客户端。

亲身体验

最后,我们可以通过ASP.NET Web Service本身支持的Web测试界面来测试一下我们的代码。我们开两个浏览器窗口,一个进入Send()调用,一个进入Wait()调用。然后我们按照如下方法来测试:

  1. 首先执行Send("Hello"),然后执行Wait()。这时候你可以马上看到"Hello"。
  2. 首先执行Wait(),让它等待返回,这时候执行Send("Hello")。随后你可以看到Wait()那段返回"Hello"了。
  3. 按如下顺序执行:Send("Hello");Wait();Send("World");Wait();
  4. 按如下顺序执行:Send("Hello");Send("World");Wait();Wait();
  5. 按如下顺序执行:Wait();Wait();Send("Hello");Send("World");
  6. 按如下顺序执行:Wait();Send("Hello");Wait();Send("World");

你会发现这样一些奇怪的结果:第3个测试返回的是"World"和"World"。第5个测试先返回"Hello"的并不一定是先执行的那个Wait()线程。后者在某些情况下不是什么问题,特别是长连接中一般之后一个Wait()线程在等待中,所以我们可以不管。而前者,则是因为没有消息队列所造成的,我们只有长度为1的消息窗口,所以只能缓存最后一个消息。这个问题我们将在下一篇文章中解决。

小结

在本文中,我们看到了不同的线程同步模型的差异。Monitor模型的lock本质上是一个Semaphore,也就是一个不能连续signal的Mutex,一个signal发出去后必须被一个wait接收了才能进行下一次的signal。同时,Semaphore也限制了signal和wait必须在同一个线程内成对执行,而Mutex则没有此限制。虽然.NET是针对Monitor模型优化的,但在我们的需求当中,只能通过Mutex模型来解决。

接着,我们便写了一个小小的消协发送与接收函数,实现了我们想要的阻塞式Web Service。同时我们也看到了没有消息队列造成的问题,因此确定接下来我们要做一个消息队列。如果你想知道消息队列如何编写,欢迎订阅我的blog:

2008年3月4日星期二

拿到了美国签证

准备了一大堆的材料,包括在校证明和百度的工资证明,结果签证官只看了我的邀请函,问了几个问题就搞定了,真爽快。他问的问题包括,我现在在什么学校(企业),去美国干什么,MVP是什么,大概就这样了,超级简单,还弄得我之前紧张了那么久。

最有趣的地方是,原来驻广州的是美国总领馆,而驻北京北京的只是大使馆,移民业务都在广州处理。整个广州大使馆都是说广东话的,除非看到你的签证签发地是非广东话地区,那就会说普通话或者英语。在移民大厅内,新移民在广东话的带读下进行宣誓,非常好玩。

2008年2月27日星期三

Imagine Cup 2008 - IT Challenge 晋级 Round 2

今年的Imagine Cup已经为没有Web Development了,估计因为往年Software Design太多人做Web了,所以干脆合并这两项了。今年新增项目为Game Development,用的工具是XNA Game Studio,看起来容易,但要做一个完整的游戏并不容易。总之,我们去年的团队今年没有再团队参赛,所以我自己挑了两个个人项目来玩玩。

第一个是Algorithm,因为我从来不知道Algorithm是怎么玩的,本年也仅仅参加了最后一场Round 1的比赛,所以在我知道怎么比赛时,已经在比赛了。我只能想尽办法拿分,没有任何经验和技巧而言,然后就挂了。

第二个是IT Challenge,同样是等到Round 1最后一场才参赛。这是考察MSIT技术知识的吗?还是考察Google的使用能力?不管了,反正30道选择题,我一看就懂做的大概只有两题,所以整个比赛就是靠Google。一个小时里面,每道题可以分配两分钟的查找时间,并行处理的话,打开页面的事件可以忽略不算。

比赛完,看我答对的题数,觉得自己不怎么样,结果竟然进入Round 2了。有趣的是,Round 2的资料一直没发出,甚至没有邮件通知,我是主动到ImagineCup.com看才知道自己进入Round 2了的。不过因为Round 2至今为止还没有发布任何资料,我也没办法做什么,只有等邮件通知了,或者天天上去刷新。

2008年2月26日星期二

使用 .NET 实现 Ajax 长连接 (Part 1 - Comet Web Service)

Ajax的长连接,或者有些人所说的Comet,就是指以XMLHttpRequest的方式连接服务器,连接后服务器并非即时写入相应并返回。服务器会保持连接并等待一个需要通知客户端的事件,该事件发生后马上将数据写入响应,这时候客户端就以相当“实时”的方式接收到事件通知。具体的通信模型,请参考这篇文章:《Comet:基于 HTTP 长连接的“服务器推”技术》,里面已经说得非常详细了,我就不再复述了。

我们接着开始讨论如何使用.NET实现这个模型。首先我们能想到的是,我们需要一个Web Service,可以是ASP.NET Web Service,也可以是WCF Web Service,ASP.NET AJAX Library两者都支持。在这里,为了简单起见,就选择大家更熟悉的ASP.NET Web Service举例。然后,我们写下以下两个函数签名:

public void Send(Message message);
public Message Wait();

其中,Send函数用来发送一个Message对象,而Wait函数用来等待一个Message对象。然后,让我们来讨论一些细节问题。

无事件导致超时

首先,长期保持连接时不行的。对于服务器和客户端来说,这不是个问题,但我们永远都要记住中间可能存在各式各样配置怪异的网关和代理,它们上面可能有各式各样的超时规则,因此Comet最好设计为定期重连。一般情况下,如果30秒没有任何事件发生,服务器端就应该通知客户端确实没有事件发生,结束掉本次请求,然后重新开始一次新的请求以便继续等待。

那么上述函数签名可否用来返回一个无事件的消息呢?这是显然可以的,我们可以选择返回null表示无事件,或者返回一个EmptyMessage常量,这视乎我们使用class还是struct来定义Message。(甚至,我们还可以做一个名为NoMessageMessage的Message派生类来做这个事情。)

定义发送目标

上述函数签名确实能用来收发消息,但是没指名发给谁。可能有人会说,发送给谁可以在Message类里面通过一个属性来定义啊。但是Wait()方法没有说明接受方是谁,服务器端依然不知道哪些消息应该让你接收。

因此,我们引入Channel的概念,Channel使用其名称来标识,相同名称的就必然是同一个Channel。在发送与接受时,通过名称指定要发送到哪个Channel,这样问题就解决了。此时,函数签名修改如下:

public void Send(string channelName, Message message);
public Message Wait(string channelName);

可靠的消息队列

想象一个可能发生的情况,服务器端向你发送一个消息,你没有成功接收,但是服务器端认为发送了就成功了,消息从队列删除了,然后这个消息就永久丢失掉了。可能有人会强调TCP多么可靠,服务器端发送的消息如果在TCP的层面发生问题了,肯定会引发Socket级别的Exception,这个Exception冒泡上来,服务器端就能截获,从而得知发送失败,然后先不删除队首消息。可是别忘了,中间是可能存在代理的,如果代理成功把消息收回去了,可是代理发送到客户端这一步失败了,服务器端就不一定会发生异常了。

因此,我们需要制定一种策略,来确保下行消息总能发送到客户端。在这里,我们选择了引入逐个ACK的机制,来确认消息的接收。也就是说,服务器端发送给客户端的消息带有一个序号,在客户端收到消息后就将该序号发回给服务器端,已确认它受到了该消息。这时候,函数签名更改如下:

public int Send(string channelName, Message message);
public Message Wait(string channelName, int sequence);

我们使用Wait()接收到的Message中,应该有一个Sequence的属性,标记它的序号。然后,再我们执行下一次Wait()时就将该序号加1的值通过sequence参数传递回去,让服务器知道我们期望下一条消息的编号是这个。例如我们收到Message,其Sequence属性为836,那么下一次调用Wait()的时候就传给服务器837。服务器端此时应该保留了编号为836的Message在对首,如果客户端继续请求836号消息,证明它上次没收到,这次仍然发送836号消息给它;如果客户端请求837号消息,证明它成功收到836号消息的,这次就发送837号消息给它。

如果都不是,那该怎么办?那意味着,这是一个错误的请求,甚至可能是攻击请求,因为正常情况下不应该出现这样的请求的,服务器端可以考虑抛个无关紧要的Exception(不要告诉攻击者你知道他在攻击了),甚至直接给个400 (bad request)的响应代号。

与Wait()类似的,Send()也可以加入ACK机制,只需要将返回类型从void改为int就可以了,这个值就专门用于传递消息编号,实现方式和Wait()是一样的,不过Send()是由客户端保存待发送消息的队列。

小结

到此为止。我们的Web Service就写好了。这就写好了?只有签名没有函数体?是的,复杂的工作留给model去做,Web Service在这里只是相当于一个view,用于将model的接口暴露出来。

在下一次的文章中,我们将开始讨论如何实现服务器端的消息传递机制。如果你对本文章系列感兴趣的话,欢迎订阅我的blog:

2008年2月20日星期三

(Twitter++ == Blogger--)

不知道这个推论是否成立,Junyu曾经说过,“忙碌导致没时间把文字整理为blog,所以把思维碎片发不到Twitter”,现在我也差不多这个样子了。

首先,Twitter上的圈子不错,不用说我发了文章后,还要等各位订阅的来看,然后我写得有深度,大家也要想想如何有深度地回答;我写得没深度,大家想也不想就不留言了。Twitter上不用想,凭直觉,你觉得可以回的tweet可以直接回,重度Twitter用户都如此。在我的Twitter上,有Flypig这样的flooding狂人,有和他一唱一和的Junyu,最近我也开始和他们一起flooding别人了,还把awflasher也拉上来了。至于Yuancheng,他是饭否的人,我拉不动。

其次,如果一些思维的碎片,你在Twitter上发泄出来了,你就不想再整理成文了,因此也有人选择了自动把近期的tweet自动发布到blog的做法,例如hidecloud。不过我暂时还不想让tweet打乱我维护那么久的有深度的Blogger,所以还是不要这样做了。不过无论如何,发到Twitter,自然导致Blogger的减产。但是Twitter一旦变成重度用户就难以回头,所以这对我来说已经很难改变,除非好像Kevin Mitnick那样被判下半辈子不得接触互联网吧。

数不尽的 blog 与 podcast

我发现未看的blog和podcast都太多了,已经到了无法处理的阶段了,该怎么办呢?最近大家都在自己的Twitter写到,“我终于把Google Reader给清了”,我不知道自己的什么时候能清掉,哈哈。

2008年2月19日星期二

为什么如此之多英中字典对同一词条的解释与英英字典不同

随便找一个懂一些英语中国人,或者就说一个英语学习中规中矩的高中生,问问他affair是什么意思,他多半会告诉你“暧昧关系”,或者直接一点,说是“婚外情”。然而实际上,affair通常就用作一般的“事务”,例如“外交事务”之类的,在英英字典中“婚外情”的解释被排到很后的位置。

这里有一个问题,就是英中字典多数不是解释单词,而是翻译单词。通常,把英语单词放在一个常见的上下文中,然后整句翻译为中文,再把上下文剥离,这就得到了与该英文单词对应的中文短语,而这正是英中字典中所给出的结果。然而无论该上下文如何常见,这样得到的都不叫做解释,因为它没有解释原来英文单词的含义,只是把它翻译过来了。

由于大多数中国学生都习惯了这样的字典翻译,习惯了一个英文单词记忆一个对应的中文短语作为解释,从来不知道单词的真实含义,才造成了开头所说的问题。如果大家不要仅限于背一个解释,而真正理解单词的含义,那么问题也就解决了。

2008年2月10日星期日

需要针对平台编译的 Web App

很久之前,我提到过了CSS需要常量的问题。最简单的,定义若干调色板常量,整个CSS就用这些常量去标记颜色,以后要更换调色板也就容易了,只需要更改常量,无需更改逐个CSS属性更新。现在看来,可编程的CSS已经不足够了,在HTML + CSS + JavaScript中,我们都大量地存在信息冗余,而这些冗余的信息不符合DRY原则,手动维护的成本高,所以我们需要一种更高级的语言来自动生成这些冗余信息。

我现在使用Ruby on Rails,不过不是很熟悉。我有同事比较熟悉Ruby on Rails,非Rails的Web布局,他也有自己一套HTML + CSS模板,定制一下然后执行一段Ruby脚本,就build好一个output了。我觉得这是很好的一种做法,因为如果定制的工作是修改HTML与CSS的话,这就涉及大量的手工改动了,那就有可能改漏了或者改错了。

既然已经做到这一步了,不妨想象一下将来自动化操作是否能够更进一步,就是自动生成针对平台的HTML代码。我们用一种真正浏览器无关的语言编写行为与样式,然后服务器端自动根据user-agent来生成对应的JavaScript与CSS。这些JavaScript与CSS都是针对特定的user-agent生成的,所以不会有用于兼容浏览器的冗余信息。同时,因为它们是自动生成的,也就不需要人手维护这些冗余信息,生成它们的源代码也就能够保持DRY原则了。

我的 iPhone 终于能当电话用啦!

花了一整晚的时间,从晚上9点开始,搞到凌晨5点,终于把iPhone软破了。

今年过年确实比较爽,Windows Server 2008发布了,然后iPhone原生1.1.2的纯软件破解方式也有人研究出来了。天天就在研究这些,过一个很geek的年,哈哈……

详细说一下破解的过程吧。我的iPhone买回来后,我自己懒得研究激活方法,所以让同事教我jailbreak,jailbreak之后就是1.1.1,我也懒得升级到1.1.2再jailbreak一次了,所以就当一个1.1.1的Touch先用了两个月。不过因为同事是用PC的,所以降级并进入恢复模式后,他不知道Mac上用什么软件把机器踢回正常模式,于是就在PC上用iBrickr完成了此操作。这次我亲自操作,开头在Mac上用jailbreak.jar总是不能成功,后来换到PC上用AppTappInstaller.exe才成功了。

我第一次升级1.1.2,按照iphone.unlock.no的教程,它没有写要装OktoPrep,我也就忘记装了,结果升级到1.1.2才发现不能jailbreak。这时候就降级再来。第二次升级到1.1.2,成功jailbreak,但是机器停留在恢复模式,我以为是jailbreak时没有关掉iTunes的缘故,于是再次降级……其实后来想一下,因为jailbreak.jar重来不能成过把我的iPhone从恢复模式踢出来,这次应该也一样吧。第三次升到1.1.2,jailbreak,然后换到PC把它从恢复模式踢出来,终于成功了,能用而且有信号!

做过一次后,才发现也不是那么难。开头想着破解后就在1.1.1用,懒得升级到1.1.2,结果发现破解后必须升级到1.1.2,否则没有信号,换上移动的SIM卡后还是相当于一只Touch。无奈之下升级1.1.2,结果一晚就做了三次升级,也终于知道升级怎么做。

2008年2月9日星期六

Windows Server 2008 发布了

过年之前就看到x64的版本出现在MSDN Subscription上面了,可惜我准备拿一台x86的机器来试试,所以就选择了继续等。今天终于看到了x86的版本了,现在看时下载,之后就装到服务器上看看效果如何。

我现在比较关注的是,它是否能在安装初始化时成功加载RAID驱动。因为Windows 2003最开始的版本是没有RAID驱动的,如果有RAID设备就必须在安装开始时把驱动软盘插进去,让安装程序从软盘加载驱动。这年头还有软盘?没错!而且是依赖于软盘。到SP出来之后,貌似是补上了RAID驱动,才省去了软盘这一步。如果Windows 2008又变成要软盘的,我就晕倒了……希望不是吧。

2008年2月7日星期四

原来 Vista 对 FAT32 的支持比 XP 要差

自从我开始使用MacBook,我的移动硬盘就从NTFS改为了FAT32。说实在的,对于FAT32这种这么老的格式,我实在没什么信心,但是在PC与Mac之间搬数据也没有第二个选择了。况且,FAT32还不支持4G以上的文件,要把一个DVD镜像搬到另外一台机器就必须分割。

之前我已经试过几次了,硬盘经过OSX写入数据后,在Windows就无法再识别出来。打开磁盘管理器一看,竟然格式成为RAW,连修复的机会也不给我了。这时候我能怎样做?只能在OSX中把几十G数据转存,然后把移动硬盘重新格式化一遍,然后再把数据传存回去。这时候,Windows中又能读了。

于是,我在网上搜索OSX和Windows经移动硬盘交换数据的方案,结果大家都说FAT32就行了,而且兼容得很好。我就很郁闷了,为什么就我遇到问题,从此我也尽量避免硬盘在两个系统之间转来转去,特别是避免从OSX写入数据,因为我觉得是OSX写入了一些数据,导致Windows不能识别该硬盘。

直到最近,我才发现问题的来源。我将移动硬盘从XP的机器上拔下来后插入到Vista的机器中,这次Vista又将它识别为RAW格式了。这时候我就明白了,不是OSX写入的数据有问题,而是Vista对FAT32的支持有问题,竟然XP写入后Vista也会读不出来。

这就真是没办法了,看来保留一个XP还是很有必要的,Vista的兼容性不错,但对一些老设备的支持还是有问题(FAT32算是老设备格式了吧),况且我也不知道对FAT32的支持是否能在SP1修正。

2008年2月6日星期三

Google Social Graph API 体验

Google推出了Social Graph API,允许大家更加便捷地搜索Google抓取到的XFNFOAF数据。

XFN是一种基于XHTML的Microformat,在<a />标签的rel属性中加上各种各样的值来指示目标URL(的拥有者)与本URL(的拥有者)的关系。例如me是指代自己,friend是指代朋友,met是指代见过面,等等。

FOAF则是基于RDF的一个扩展,原本RDF用于描述资源,FOAF则把侧重点放到了描述资源拥有者上来。

Google对Social Graph API的使用方法范例是这样的:假如你新加入到Twitter,没有任何好友给你follow,那么Twitter就可以考虑引入Social Graph API来为你寻找已有的好友。因为你在Twitter注册时输入了自己的URL,Twitter仅需要将该URL题交给Social Graph API查询就好了。或许你提供的URL正是你的blog,上面链接到你好友的blog了,并且也用XFN标记了,那么Social Graph API就能将这些好友的blog返回给Twitter,Twitter发现原来这正是另外一个用户的URL,那就是说该用户就是你blog上链接到的那位朋友了。

这到底是否真的那么有效呢?我马上用自己的Twitter地址测试了一下:

http://socialgraph.apis.google.com/lookup?q=twitter.com/catchen&pretty=true&fme=true&edi=true&edo=true

Social Graph API在我的Twitter页面上,找到了我设置的URL属性,知道那是指向我的另一个页面。那个页面就是我的claimID页了,上面当然不乏XFN标记了的链接,于是它又找到了我的一堆blog。可惜的是,新的Blogger模板中的链接widget无法假如XFN格式,除非你放弃widget改回用全手动编写的HTML,因此Social Graph API无法通过我的那堆blog找到到我的好友。

Update: Twitter把following加上XFN信息了,所以你的following和follower都会被Social Graph API认为是contact关系。不过这又引入了另一个问题,就是Social Graph API总是认为关系是自动双向的,但其实我的一部分follower我并不认识,我也不认为我和他们存在contact关系。

步出感觉安全的区域

这是The Game里面提到的,意思是人总会选择在一个自己觉得安全的区域内徘徊,而拒绝离开这个区域。举个例子,内向的人,或者说不擅长与女性打交道的男人,可能就觉得只有和同类打交道才是安全的,出了这个范围就不知道怎样打交道,关键在于怕被别人拒绝,或者更严重的是遭受羞辱。

事实上,不仅仅社交方面如此,很多方面都会由于这种现象的存在,而限制了个人发展。技术上的依赖,会导致个人的技术跟不上潮流。我是在ASP.NET 2.0发布后才算是真正开始使用ASP.NET的,所以没有什么ASP.NET 1.1的包袱,然而有不少人却因为习惯了ASP.NET 1.1而不太热衷于升级到ASP.NET 2.0来,因为他们已经熟悉了ASP.NET 1.1,那是个感觉相对安稳的环境。现在,ASP.NET MVC出来了,而我手头又没有多少ASP.NET项目要做,我也变得不急于迁移到ASP.NET MVC了,顶多看看别人写的文章,自己没时间动手去实践。

生活上,也差不多,习惯了和谁住,习惯了住在某个城市某个城区,也就觉得只有这样的环境才叫做安稳。而如果真的要获得更多的机会,必须敢于放弃这些让你感觉安全的区域,大胆地走出去,面对可能迎面而来的总总风险甚至是危机,之后才可能获得安全区域内得不到的收获。

MacBook 突然充不进电了!

昨晚回到家,把充电器插到拖板上,打开拖板的开关,就开始用电脑了,后来才发现一直处于使用电池的状态。尝试插拔了充电器几次,也没有解决问题,MagSafe上面的灯是不亮的,电池的硬件指示等也没显示在充电,我怀疑充电器坏了,然后感到非常郁闷──怎么早不坏迟不坏,偏要过年前坏!过年啊,有保修的话也没有人帮你修,如果充电器不在保修范围内,想买或许也难买。上网查了一下充电器的价格,80USD,或是600HK$,吓死了,大陆的价格肯定还要贵。

因为已经很晚了,所以就郁闷地睡觉去了。第二天跟布丁抱怨这件事时,他说可以把电池拆下来再装回去试试,他的HP曾经因为电池冻到不能识别而出现类似情况。我就试着拆一下电池,发现果然能充了!原来在北方还有那么多的保养问题需要注意的,不知道MacBook拿到南极是否还能用……

2008年2月4日星期一

退订 blogbus 所有 feed

身边有部分高中同学,就是从高中开始写blog的那种,当时国内最大的BSP是blogbus,所以用的就是blogbus。然而blogbus最近“出了点问题”,也不是最近了,持续了很多个月了,我今天忍无可忍,决定无论是多么熟的朋友,只要是blogbus的,一律退订,在我得知blogbus修正此问题之前也不再订阅任何blogbus的blog。

首先说说这个问题给我造成的麻烦,我在FeedDemon或NetNewsWire中对一篇blogbus的文章标记为已读,然而第二天这篇文章又变成未读,每天我都要手动将所有blogbus的feed手动标记为全部已读。一开始我认识只是blogbus升级过程中造成的小问题,就好像之前Live Space也会时不时这样,所以手动标记一下就好了,结果这样的事情一直持续到今天。最终我确认了一下问题的来源,因为blogbus把文章输出到feed时要在最后追加“相关文章”,而且这些“相关文章”还不停变化,因此Newsgator只能把变更后的文章当作新文章来处理。

在其他的blog平台中,作者有时候也会修改文章,为什么不会导致Newsgator把这当作一篇新的文章?这关键之处就在于blogbus不对文章输出guid,因此变更后的文章无法确认它是不是由一篇已经抓取过的文章更新而来的,就只能当作新文章处理。如果输出了guid,Newsgator一看这个guid已经被抓去过,也就不管了。另外一些feed reader,处理方式可能略有不同,而将同guid不同内容的文章重新标记为未读或标记为已更新,但至少不会把这当作一篇全新的文章。

不标准的feed总是让人很头痛,虽然现在feed的使用越来越普遍了,但是还有很多feed提供者自己没有完全理解feed相关的标准就发布feed了,导致使用该信息源时需要加入各种兼容性设计。

2008年2月2日星期六

怪异的国内 iPhone App 市场

环视国内最大的iPhone社区weiphone,你会发现没有多少人讨论Web App,大多数人关注的都是破解以及客户端应用,然而实际上Apple官方就收录了一大堆第三方Web App,按分类整理好了,其中有些热门的非常好用,另外一些也不错。

在这样一个环境里,国内开发Web App没有任何优势可言,还不如去研究那个还不完整的API然后开发客户端应用呢。况且,Apple这个月就要发布客户端SDK了,API文档就能够得到补全,原本的客户端应用总能修改一下就变得符合官方指引。不过,听说只有官方私钥签名后的应用程序,才能够从iTunes下载安装,估计这还是少数,因此Installer将依然有用,老的应用开发模型也不会消亡。

回到Web App的话题上来,如果要在国内做一个Web App并获得成功,必须很注意iPhone用户的构成。现在有一些iPhone用户,还没有把iPhone破解掉,而把iPhone当作iPod Touch用,那么这些用户就只能当作iPod Touch用户算了。有什么区别?iPod Touch只能在wifi覆盖区域内享用网络服务,而iPhone则能够使用EDGE(或者说至少是GPRS吧),享受网络服务的连续性要更好,总计时长也多得多。开发一个Web App,就必须很注重可访问性,目标用户虽然有设备,可惜根本没有网络覆盖,访问不了,那有什么意义。

我现在在公司和在家里都有wifi覆盖,迟一些回广州肯定也要马上买一个无线路由回家以确保我的设备都能无线使用。然而,有多少人能够有这么好的网络覆盖条件呢,根据我从weiphone观察而来的,其实还有很多人是只有有线网络连接的,要安装软件到iPhone就只能通过iBrickr从数据线传。例如Jim,他就觉得要wifi安装的东西是很不方便的,因为学校的wifi环境不好,家里也没有无线路由。然而我正好相反,我没有装iBrickr,因为我用Mac,又懒得在Mac上装类似解决方案,所以我就严重依赖于wifi。

总之,因为Apple的门槛设置,以及破解的流行,导致了iPhone用户数量虽多,可是他们所处的环境异常复杂,一设计一个Web App成功的捕获不同环境中的用户是非常困难的。

2008年1月27日星期日

Geeky meets Pretty

因为我在北京的圈子里认识不少geek,同时我又想认识靓女,所以就采取了这样一种策略──估计那么多geek都想认识靓女,所以就搞一个party吧,各自把自己认识的靓女都带过来,那就可以大家都可以认识到更多靓女了。也因此,party被命名为Geeky meets Pretty。

这次的party星期四早上第一次讨论,然后就确定星期天晚上搞了,效率异常高。我其实是担心准备不充分的,不过快过年了,也就没办法拖了,既然星期天晚上没问题,那就星期天晚上吧。开头我们预计5位geeky至少各自带以为靓女来,有10个人,搞一个小规模的party,不过最后来了15个人,证明人数并不是一个需要担心的问题。

对于这次party,从geeky到pretty,按1到10打分的话,我会给2或者3。在讨论的话题上,其实不算geek,只有一点点IT而已,因为在场的男士都是IT圈子里的,说到PR女士就郁闷了──在说Public Relation吗?不是,是Page Rank。然而,整个party的娱乐性不算高,一群高智商的人聚会,娱乐项目自然是杀人。杀人游戏要求思维运转,不过娱乐性就一般般了。这次的party没有任何的酒精,也没有什么很刺激的游戏,这是我觉得娱乐性低的一些原因,就是现场很文明,一点都没有high的感觉。看起来更像是IT界的聚会,可惜大家又不讲IT,所以有时候也会冷场。

因此,如何搞好一次party,其实是非常有学问可言的,我的意思是对于我们这些geek来说,有些人天生是party animal,那是我们无法比的。就好像都是MVP,是否擅长交际是人人不同的。Bean在三亚时跟我说,你看哪个MVP是不怎么social的,你就知道他主要是做线上活动的了,因为做线下活动的MVP都是很活跃的人,而作为职业讲师就更加需要懂得如何调动听众的氛围了。暂时我自觉觉得能够条理清晰地讲好一场讲座,但是不能做到新东方讲师那样15分钟一个笑话,如果我要获取那样的技能,前期我必须主动的去做准备,例如每场讲座之前先精心挑选若干适合插播的笑话。讲着讲着就能自然插一个笑话,这种境界对我来说是难以直接通过不主动背笑话而获得的。

这看起来和我向来坚持的英语学习方法所不同。学英语我不觉得有必要刻意背单词,反正用的频率越高,说明那个单词对你也就越有用,你也就越容易记住它。然而问题是,英语你平时可以不停地用,如果你平时不怎么使用英语,然后考试机会就那么稀有,你就只能通过背来准备。对于演讲和party,我乐意不停地花时间去参与,然后潜移默化地把一些技巧记忆下来,然而这样的机会不存在啊,我不能每天都去演讲,我也不能每天都去party,就算我时间上能够负担得起,也没有这样多的机会。演讲没有听众可以找镜子,party呢?因为party的机会实在太有限了,所以我要组织一次party,我就必须提前做好准备。这次准备不充分,娱乐性不足,下次我就要做足功课再来。

最后,我要感谢awyuanchengyou xujunyu布丁等人,感谢大家参与到组织一个party的工作上来,帮忙选定了party的场所,预定了包间,拉拢了靓女,以及埋了单。

2008年1月25日星期五

Zhuantie 与 Jinghua - 中国互联网文化的重要元素

既然有人研究GuanxiGanqing,那么我就来研究Zhuantie与Jinghua。

首先来说说Zhuantie(转帖)。上次和王兴等人的讨论中,说到为什么百度贴吧只允许吧主上传视频的做法比大众型视频站更有效利用资源。这是跟中国的文化背景有关,中国人中乐于创作内容的或者乐于贡献内容的暂时还非常有限。曾经在Wikipedia上见到有人说,下一代人叫做P代,P指Participate,大家都参与到Wikipedia贡献内容了。然而在中国,还要多少年才能把一代人称之为P代这很难说,现在大多数人还是缺乏创意,缺少闲暇时间去创作,大多数人对着摄像头连装cool的创意也缺乏,高质量的原创视频当然就少。在这个前提下,一个YouTube类的网站就难以通过UGC发展起来了,因为根本就没有UGC,变成了纯粹的转载站,所有人都是将他自己觉得还的视频再发布过来,而非发布自己的内容。而这就是所谓的Zhuantie文化──在中国,由于UGC的缺乏,变成少数内容被不断的复制粘贴,导致整个中国互联网上的内容缺乏多样性。

而被Zhuantie的内容是什么呢?这就是所谓的Jinghua(精华)了。国外的论坛系统是没有所谓的“精华帖”这一设置的,只有sticky用于发布公告。为什么需要精华呢?因为国内论坛的水化问题太严重了,没有哪个帖子不跑题的,而国外论坛很明确规定off topic就一律砍,你有新话题一律开新thread,不要再原来的thread上追加。这样一来,国内的论坛就难得有一个帖子是真正专注于一个话题,能够有所深入探讨的,因此一旦能够出一个这样的帖子,就变成精华了。

2008年1月24日星期四

请不要在 taxi 上使用谷歌地图

谷歌地图(而非Google Maps)的数据源Mapabc非常不精确,已经试过两次了,在北京去一个陌生的地方,在的士上打开J2ME版的谷歌地图,搜索出一个地点来,然后指示司机开过去,而结果表明那是一个错误的地点。虽然北京的士司机很不靠谱(停在红等前拿本地图出来看的都有),但是谷歌地图更不靠谱。

有人说,百度的数据源Mapbar同样不精确,因为中国的一切地理数据都属于“国家机密”,因此需要经过扭曲后才能发布。什么叫做扭曲?这样说吧,用过PDA的人都知道如何校正触控笔的,因为PDA屏幕的显示与触感两个层都是线性的,一般三到五个点就能校正。然而中国公开到网上的地理数据,例如一个城市的地图,你把这张地图叠加到Google Earth的同一个城市之上,然后采用类似的方法来校正,你会发现极难对齐。理论上,如果两张地图都是正确的,只要比例和位置校正了,叠放在一起应该是每一个点都对齐的。我们暂且假设Google Earth拍出来的照片比例误差不会太大,那就说明Mapabc的数据源是有问题的。当然,上述都是听说会来的,我还没亲自做过Mapabc的地图校正。

这就是安全与便捷之间的trade off,你要增加一样就必须削减另外一样。如果你询问普通市民,他们肯定都优先选择增加便捷性的,因为安全问题暂时不觉得有多严重。这和企业内的信息安全问题一样,所有员工都会觉得企业的安全策略(例如每3个月改一次密码)是一种负担,从而想尽办法绕过去。

2008年1月23日星期三

大忽悠争霸战 Round 1 - DING!

aw在一篇关于学习英语的好处的文章里说到,有很多细小的题材只有英文文章才有所涉及,而在中文领域不一定有人研究过,甚至不一定有相关文章。而且,aw说中文文章经常有些是没有科学依据或者缺乏引用出处的,我将此理解为“忽悠”,那么我们现在就来看看谁更忽悠。

aw的后一篇文章的标题是:好消息 - IE6将退出历史舞台。世界上竟然有这样的好事,而我不知道?我一定要过去看看,然后我看了aw的文章,也看了他引用的中英文原文(英文来自InfoWorld,中文来自Solidot,Solidot到底和Slashdot是什么关系我并不清楚),结论就一个:要么aw被Solidot忽悠了,要么aw在忽悠别人,到底是哪个呢?

InfoWorld的标题是Microsoft warns businesses of impending autoupdate to IE7,意思是“Microsoft警告,商业用户即将自动升级到IE7”。然而,Solidot的标题却是“微软将在2月12日把浏览器强制升级到IE7”。这种翻译方法叫做什么?提示:不叫“翻译错误”。没错,那就叫做“忽悠”。“自动升级”就相当于“强制升级”吗?即使你不理解前面的“商业用户”是指什么,这两者的差别也显而易见。

接下来,我就InfoWorld的文章解释一下所谓的“商业用户”。所谓的商业用户,就是指文章中提到的WSUS用户,而什么是WSUS到Microsoft的官方网站看一下就知道。简单来说,你的企业中有一万个Windows客户端,它们都要做Windows Update,然而如果它们都从官方站点进行Windows Update,这浪费多少企业对外的流量,于是你可以选择使用WSUS──一个企业内部专用的Windows Update服务器平台。作为企业的IT管理人员,你首先在企业内部署一台WSUS,让它从Microsoft的官方网站自动下载Windows Update,同时用WSUS生成一个小小的安装包派发给每一个客户端安装一下。在所有的Windows客户端运行该安装包后,它们的注册表都会加上一个标记,告诉它们以后Windows Update不要从Microsoft官方网站下载,而从企业内部的WSUS获取。

这样做有什么好处?记住,在高度IT化的企业内,IT部门就是克隆人军队的指挥官,而所有客户端机器都是克隆人。举个例子,如果你企业内部的ERP平台依赖于IE6,在没有WSUS的情况下员工可能就会无意地通过Windows Update升级到IE7了,然后发现ERP平台用不了,这时IT部门就要被“打扰”了。这类情况一旦增多,“打扰”就升级为“骚扰”了。所以,作为指挥官的IT部门,有权选择“我知道IE7的存在,但不允许任何克隆人升级到IE7,它们也看不到IE7这个升级的存在”,然后所有“升级到IE7并与ERP平台不兼容”这一问题就不会发生了。如果员工自己下载一个IE7的安装包来安装呢?不要以为Microsoft和企业的IT部门是吃饭不干活的,Windows中复杂的组策略设置就是干这个的,IT部门可以定制一个组策略不允许员工装软件,或者不允许员工装IE7。记住,客户端机器就是克隆人,要么清一色IE6,要么清一色IE7,异类统统枪毙!

现在,大家理解什么是WSUS了吧,那也就应该理解那个“警告”的用意了──如果你是企业的IT管理人员,现在最好马上做调研以决定你的企业是否适合升级到IE7,如果不适合你需要提前设置WSUS以避免这个“自动升级”的过程。

当然,国内的企业,包括大型IT企业,其自身的IT化程度还不高,所以没有人理解WSUS以及类似的自动化流程,以为一切就应该是手动的操作,Microsoft的设计一切都是那么“蠢蛋”的,然而事实上谁才是真正的“蠢蛋”?我看是国内某些习惯手动操作并且不怎么理解“国外先进的科学管理流程”的译者吧。Solidot把InfoWorld和Slashdot都引用了,人家两篇文章都说明了这是Microsoft对企业IT管理人员提出的一个“警告”,它自己却在那里坚持说“强行升级”,这真是绝顶的忽悠,你看这带着6点PageRank的aw也中招了。

我在这里可以对Microsoft的客户划分再补充一下。MVP分为三个大类:第一类人的工作是,决定企业购买Windows服务器还是Linux服务器,研究哪个的使用成本更低;第二类人的工作是,在第一类人选择了Windows之后,判断企业内部管理平台到底是否基于Web,是否要引入RSS支持,以最低成本实现效率最大化;第三类人的工作是,在第二类人作出判断后,开始设计、编码、测试、维护那个可能支持RSS的Web平台。在中国,第三类人是最被人广泛了解的,第一类人如果挂个CXO的头衔也为人广泛了解了,而第二类人通常就被无视了。

2008年1月21日星期一

最 Geeky 的企业内部首页

首页嘛,有很多中方案,例如iGoogle式的,足够大众化。PageFlakes或者Netvibes也差不多。但是说到geeky,我有个不错的注意。

Opera提供一个Speed Dial,将1~9对应9个链接,而非将一大堆常用功能扔出来,这不错。根据2/8原则,就算我收藏的链接再多,就算我放在iGoogle首页的模块再多,我要用的就那么几个。因此,我设计的geeky首页就一个speed dial。就这样?当然不是,我希望首页不仅仅能做speed dial,还能做普通的dial。

好像普通的手机键盘那样,长按才是speed dail。例如长按4(ghi),那就打开Google;按4(ghi)6(mno)就打开GMail。然后,如果自定义首页只能打开URL,那就太无聊了。现在整天都要打开内部通讯录,查某个人的电话,然后拿起电话来拨号。我觉得我直接在Web界面上拨号就好了,然后自动转为Skype拨号。每人拿一个Skype手机……算!手机太大了,每人拿一个Skype耳机,假如wi-fi模块能够做到耳机里面的话。只要在首页输入电话,就自动转为Skype拨号,并且转接(或回拨)到我的Skype耳机上,那就够好了。反正公司内部wi-fi覆盖,走到哪里都一样,不会再出现打电话给某人发现他不在固话附近的情况。如果已经有了wi-fi覆盖这样的好事情,再搞一个固话网络或者3G接入,那就多余啦。

当然,有时候还是要查找某个人的电话号码,或者某个文档的信息,这时候不要输入数字,而先输入英文字幕(或者先输入数字0),然后就开始进行企业内部的全文检索。例如有人想找我的分机号码……还什么分机号码呢,我是说Skype号码,那就输入“Cat Chen”,然后就查到了,接着点一下就转到他的Skype耳机上拨号了。

2008年1月18日星期五

MacBook Air 如果可以这样子用就很 cool 了

大家都在谈论MacBook Air,我也来评论下这个东西。大家肯定对那个从大信封里拿出MacBook Air的情景印象深刻吧,我来提供一个理想的用例。

香港的黑帮电影中,你可以看到两方boss会面时,各方boss都会没收所有跟班的手机,然后装到一个大信封里,并且从另外一个大信封倒一堆手机出来,让大家个人拿一个,以确保没有人泄密。

如果MacBook Air足够便宜,boss会面前跟大家说,谁还没有电脑的,然后叫秘书搬一堆大信封进来,一人扔一个(“扔”这个动作很重要,这样才够cool),然后大家打开后发现里面装的是一个MacBook Air,那就爽了!

2008年1月16日星期三

原来我住的是百万豪宅!

其实我从来不在blog里写这样的话题,不过这个比较讽刺,所以说两句。我现在和另外3个在同样是在百度的广东人合租一个房子,房龄和我差不多大,不过竟然买卖时的交易金额能够飙升之百万,真是神奇。我们现在¥3400/月把它租下来了,淡季,离奥运还有半年,所以租金算是便宜,却最近才发现原来我们住的是如此值钱的房子,真是神奇!

出名有两种途径

首先,这是Benny在若干年前说的,不是我说的。想要出名,有两种途径,要么互相吹捧,要么互相攻击。没错,他这说法就把所有可能性都囊括再内了,事实上无论你是主动想成名,还是凭借实力成名后想保持身份与地位,这两样都是你的选择,也是你近有的选择。

我们可以看得到,有些业内“知名人士”,时不时发表一些其实没什么深度的文章,里面其实都是对业内其他名人的……这么说吧,就是他表现得在其他名人面前尤为谦虚的样子,这其实就是第一种途径了。你想想,如果你捧一下别人,那个人可能不感恩也来捧一下你吗?这当然可能,因为对方真的可能就是实事求是的人。然而你捧一百个呢?里面总有几个和你一样处于某种尴尬地位的,或者说是瓶颈,论实力想再提升上去有难度,于是干脆就顺你意和你一起玩这个互相吹捧的游戏,反正他也有好处。

另外一种途径,就是找个名人下手,开始攻击他,例如找Keso啦。先不说Keso到底是否有实力,这不是重点,重点在于他出名,那就够了,你就可以用他来做攻击目标,从而推动你的名气上涨。如果你只是一群暴徒中相对“默默无闻”的一个,那没什么作用,但如果你是领头人,你攻击别人的言论足够“一针见血”,那就成功了。正所谓“敌人的敌人也就是朋友”,那位名人的反对者就会站到你这一边来。也就是说,你只要不至于蠢到找一个人缘超好的名人来做攻击对象,找个性格分明的,他肯定有自己的反对派,你一攻击,就相当于把他的反对派拉到你这边来了,多好。

因此,国内的IT圈子有时候也挺像是娱乐圈,谁玩谁还不知道呢。我作为一个MVP,有时候也不得不随大流结识一下圈子里的其他人,例如去认识一下Keso。不过说到底,最值得仰慕的,还是那些真正靠实力而成为geek的人。

2008年1月10日星期四

Windows 就是一个带 UI 的命令行

这是用过Mac之后对Windows的感觉。

用一个对程序员来说比较友善的比喻来说,以面向过程的方式来写一大堆函数,然后再分别塞到几个类里面,这就是Windows了。而Mac是真正的面向对象思想下设计的。

在Windows当中,我们貌似在操作一个“文档”、一段“文本”、一张“图片”,但实际上我们都不是在操作对象本身,而是类似于在操作handle——你不知道对象在哪里,你不能直接传递或操作对象,你只能借助仅有的API对handle进行操作,所有能对handle进行的操作都由API限制了。例如即使你在操作的是一张“图片”,你也很清楚那是一个存放为文件的图片,或者暂存在剪贴板的图片,总之你必须清楚handle在哪,否则你就算看到了那张图片也无法操作——图片在网站上,你先另存或者复制到剪贴板吧。

这种体验不就完全是面向过程的映射?每一个操作相当于调用一个或几个API。Windows发展了那么久,在人机交互方面还是脱离不了对DOS的简单封装。在这方面,Windows从前落后于Mac,现在还是这样。Mac虽然不能达到最理想的面向对象操作方式,但至少系统本身提供的体验要比Windows好,同时主流软件也比Windows的主流软件在体验上要好一个等次。

例如Skitch这个轻量级的图片处理软件,你可以抓起正在编辑的图片扔到桌面上,这就自动另存为一个图片文件了。文件与内存中的图片数据对用户来说已经无缝连接起来了。

再举一个例子,在Windows我们都知道回收站是个很好的比喻,不用的文件当然扔那里面。不过说真的,你多少次把文件扔里面了?你用得更多的是delete按钮,对吧?这是显然的,因为Windows用户习惯最大化窗口,这当然就把回收站遮住了,傻瓜才会选择在窗口里拖动文件的同时回到桌面接着再把文件扔到回收站里。Mac的回收站叫做废纸瘘,它出现在Dock上,Dock类似于Windows的任务栏,永远不会消失,就算自动隐藏也可以在鼠标靠近后自动跳出来,因此你永远可以把你看到的不想要的东西拖到废纸瘘上面去。

这也说明了一个问题,Microsoft这样去仿造Apple发明的交互方式是没用的,因为一点点的差异就可能导致可用性完全不同。Windows Mobile 7泄露的文档中,透露了Windows Mobile 7将可能有一些类似iPhone + Wiimote的功能,例如用手指拨动CD封面从而跳到下一张或上一张CD,甚至晃动手机从而跳到随机抽选的一张CD,这样的交互到底是否好用,真的很难说。

最后,无论你在开发Windows应用还是Web应用,我都建议你去弄个Mac来用一段时间吧,不要给一直以来Windows及Windows主流应用程序的交互设计方式禁锢了你的思路,你应该看一点新鲜点的东西。在以前,我认为Scriptaculous的拖放库完全是多余的,真该好像Atlas转变为ASP.NET AJAX时那样把拖放库丢一边,但在使用Mac之后,我才真正觉得在Web应用中推广拖放操作是非常有意义的。

假如我们都做一样的事情

之前写过关于Facebook News Feed的文章,现在开始反过头来思考trend的坏处了,那就是我们都变成克隆人了。

其实所有寻找同好的网站都有这样的问题,一开始你能够很好地寻找自己的同好,以及他们的爱好,在相邻的领域内拓展自己的爱好。然而实际上我们都明白这在数学上的意义,就是所谓的“类聚”,欧式距离相近的若干个点就聚唯一个类,并且一个点与这个类中各点距离的总和比与另外任何一个类中各点距离总和要小。

之后呢?因为你在变得越来越像你的同类,同时他们也变得越来越像你,这样一个类内的多样性就开始缩减,这绝对不是一件好事。有两种途径可以打破类聚,要么是创造类聚本身的网站致力于重新打破类聚,这听起来很好笑对吗?你的服务目的是创造类聚,但你又要打破它。然而另外一种途径就是,由外力来打破这种类聚,之后你的服务也就真正失去存在意义了,哪一种才是你所期待的?

我们都希望同类的人不停地聚集到自己的平台上来,但这是不可能的,在完全朝着目标的发展路线上一种可控的“叛离”是必须的。你希望聚拢一种用户,但无论是你喜欢还是不喜欢,中间总会带来一些变化,例如新的用户群体超过了原来的用户群体,最终超过临界成为了所谓的“变味”。需要一再强调的是,这种改变是不可避免的,你不能说控制你的平台不发展从而不改变用户群体,他们继续类聚下去也会爆发,因此我们需要在“可控”的前提下进行一些操作。

无论是之前的论坛“火了-水了-完了”,还是麦田现在所说的“有趣-无聊-暴力”,这都表明群体的进化是必然的,我们需要研究的不是如何保持一个群体以避免其发展。虽然上面两个例子看起来都是“衰亡”——总之就是越变越坏,但实际上这是一种发展。我们需要的是控制这种发展,而不是任其自然。

2008年1月9日星期三

跑去见Keso了

北京给我的印象很一般,不过没办法,中国的IT人都聚在这里了,甚至IT以外的人脉枢纽也在这里。与之对比,硅谷不仅仅有人,气候貌似是我喜欢的,生活条件也不错,而北京在“天时地利人和”这3个条件中就只有最后一个,却吸引那么多人跑来这里了,说明其人脉的优势是如此之强大以克服前两者的弱势。

今天晚上在布丁的带领下跑去见Keso等人,第一个印象是这些人特别能吹水,第二个印象是Keso对香烟的消耗率实在高。这样一群人,能够从互联网隐私问题扯到视频管理再到色戒,中间还间插着Google Camp与燕窝这样的东西,实在强。而且那种思维的跳跃性,让听众的大脑很快就会觉得超负载。

在奥校我已经习惯了和一群思维超级跳跃的人聊天,这没什么问题,不过那时候我们都是搞理科竞赛的,我们习惯以geek的思维来扩展,我们对用词与用意是否低俗并不介意。Keso这些人,art背景够强,不像我们只有science背景,于是说话总是喜欢挑些一针见血的,同时又保持言语的高雅性,这样非tech类话题我就很难插嘴了。

总体而言,去和Keso聊天还是很爽的一件事。下星期看看布丁又能带我去见些什么人。周围去找人聊天是一件非常有趣的事情,能认识到不同的人,了解他们的观点,因为这些人的背景都非常不同,所以视点可以是非常独特的。

2008年1月7日星期一

编写 iPhone Friendly 的 Web 应用程序 (Part 6 - iUI)

iUI是一个针对iPhone Safari的Web开发框架,由Joe Hewitt开发。这位Joe Hewitt曾经参与过Firefox的开发,包括其中的DOM Inspector以及Firebug,后来到了Facebook,为Facebook开发了iPhone专用版本,对iPhone Web开发社区算是作出了巨大贡献。

样式

我们继续说iUI这个框架。这个框架所做的事情,就是提供iPhone Friendly的交互方式与样式。为了简单起见,我们先来说说样式方面,iUI提供的不仅仅是一个CSS文件,基于这个CSS文件你所创建的页面能够符合iPhone的人机界面指引,并且看起来的效果贴近iPhone原生的应用程序,从而降低用户学习门槛,避免你自己设计的Web应用对iPhone操作不友善(例如按钮不够大,手指难以点击)。

交互

至于交互方面,iUI提供一个基于page的换页导航机制。这里所说的page不是一个Web页面,而是一个<body />内的顶级DOM元素,每一个这样的DOM元素都可以作为一个page,同一时间上仅显示一个page。页面上的所有链接,要么导致page转跳,要么导致整个页面转跳。这种转跳有如下几种情况。

转跳

如果链接的href指向的是一个锚点,例如#somePage,那么iUI就会在页面中寻找id="somePage"的page对象,然后进行转跳。

如果链接的href指向的是站内地址,例如/somePage.html,那么iUI就会使用AJAX的方法加载/somePage.html的内容并追加到<body />内,注意,/somePage.html必然是一个文档片段而不可能是完整的XHTML文档,否则把<html />追加到<body />下就是错误的了。追加的内容内可以有多个page,如果其中一个有selected="true"的属性,那么接下来将显示该page,否则显示追加内容中的第一个page。

最后一种情况是指向站内地址,但是有target="_replace"属性。iUI在看到target="_replace"属性后,就会知道该<a />所在的page内直属元素要被删除,并且替换为目标页面的内容。在这里用CSS来解释一下所谓的直属元素,body > ul#somePage > li > a[target="_replace"],这里<li />就是<ul id="somePage />的直属元素了。这种转跳通常用于曾亮加载,例如iPhone内置的Mail打开邮箱后自动加载50封邮件,点击more之后再加载50封,Web界面上就可以通过这种方式实现——一个<ul />内包含51个<li />,前面50个对应50封邮件,最后一个<li />包含<a target="_replace" />的more链接,目标页面就是下50封邮件的<li />

在转跳的时候,iUI提供了一种很好看的效果,你能够看到当前page从屏幕左边移出去,新的page从屏幕右边移进来,好像PowerPoint的某种幻灯片切换动画那样。如果添加了axis="y"属性,page还能够子底向下滚动。

历史记录

AJAX式的页内内容更新不是不好,问题就在于浏览器无法自动保存历史记录,导致前进后退按钮实效。iUI已经解决了这个问题,上述3种转跳中的前两种iUI都会自动创建新的hash以便创建历史记录,hash默认就是#_pageId的形式,如果当前显示的page没有id,那么hash就按照增量自动分配id。

在拥有历史记录之后,用户就可以通过浏览器的后退按钮向前翻页了,此时相当于加载前面的page,iUI知道这是一个后退操作,就会提供反向的滚动效果(自左向右或自上向下)。

如果我访问页面的顺序是A > B > C > D > B,那么历史记录会如何呢?历史记录会变成A > C > D > B,也就是说第一次访问B时B从历史记录中删除并重新添加到最前的位置了。

演示

说了那么多,我们来看看iUI的实战效果吧!又是Facebook或者Digg的iPhone版?不是,我们来看看自己利用iUI开发一个小应用的效果以及成本如何。就在上个周末,我花了不到20小时做了个名为iBaidu的小东西,自动抓取Baidu的搜索结果与排行榜并以iPhone friendly的方式显示出来。以下是发布到YouTube的演示视频:

服务器端使用的技术是Ruby on Rails以及ASP.NET。为什么需要ASP.NET?这是一个很郁闷的问题,因为Baidu是基于GBK的,而RoR的编码转换能力其若无比,我懒得花时间去寻找适合的转码库,因此直接拿了ASP.NET来做抓去代理,抓取的时候顺便做一下编码转换。如果不是编码问题,那么只需要RoR就能轻松完成任务。

小结

在这篇文章中,我们已经看到了如果使用RoR搭配Prototype,不好意思,iUI才对,要设计一个iPhone friendly的Web应用程序是多么地容易,开发过程也相当敏捷。如果你喜欢iPhone开发系列的文章,欢迎订阅:

2008年1月6日星期日

什么时候抛弃Live Messenger

最近全面通知QQ上的所有好友,包括群,说明我决定于2008年开始停用QQ或TM,需要继续保持联系的话就加我的Live Messenger或GTalk,无论什么事情,至少可以通过GMail联系我。我期望的是,如果你觉得我们之间的connection不那么重要,就不要来烦我了,我不关心你上线下线这样的琐碎事情,记录下我的GMail吧,没事不要在IM上找我,然而结果却是另一种情况。

在我在QQ上广播暂停使用QQ且给出Live Messenger与GTalk帐号后,一堆人来加我的Live Messenger。因为我在群里面广播了,有些人本来不是好友的,还变成了Live Messenger好友。可能我们在群上根本就没有直接对话过,这样就加进来真不知道说什么好了……我在Live Messenger上也不知道如何给他分类。可能有些人认为,只要有价值的人,也就先加了,避免日后要联系又找不到,然而其实他过去没有任何联系我的理由,将来可能也一直没有。

总之,我现在Live Messenger上面的好友数量暴涨,并且我也从Live Messenger换到Adium上来了,看不到以前的聊天记录了,因此如果我不记得你是谁了,那么请见谅。可能经过一段时间后,我又会选择停用Live Messenger,以过滤掉一批不用联系的人。

2008年1月3日星期四

想买个数位板

最近几天就在fancy这个东西,不知道什么时候才有米去买一个。感觉用笔来画画很爽,况且平时也能用笔操作,鼠标就省掉了,不会因为长期抓鼠标导致健康问题。

2008年1月1日星期二

新年新服务: MVP 播客上线

其实我很早就想做podcast(播客),10月份从三亚回来一直在筹备一个MVP博客,最终在前天完成了第0集(pilot episode)的录制,并将于今天稍晚时候上线。在整个过程中,我需要感谢dudu以及博客园对podcast提供的支持与服务,感谢BeanJeffrey对podcast准备工作与录制的投入。

首先,我介绍一下podcast为什么叫做podcast。过往,我们能够订阅feed,从而好像收取email那样收取网上的信息。例如,我订阅了ABC World New,设置了我的电脑每天早上7:00自动开机并打开feed reader下载feed,那么当我准备好早餐后,我就可以一边享受早餐,一边阅读新闻了,这和传统的喝早茶看早报没什么区别。

然而,ABC World New的新文章,附带了一个新闻视频片段,以龟速的下载速度,我可不能等下载完看完再去上班,因此我希望我的feed reader能够识别视频音频片段并且自动下载。RSS 2.0的<enclosure />标签是第一个出来把问题解决掉的,只要把这一个feed entry相关的文件放到<enclosure />链接内,feed reader就应该懂得自动去下载。之后,我把电脑自动开机时间改为早上5:00,预留两个小时,什么龟速也能把几分钟的视频片段拉下来吧。然后,我还是边喝着早茶(或者咖啡),边看新闻,不过这次不用读文字了,视频里面有人说给我听。

随后,iPod和iTunes又把这个应用提升到了一个全新的层次。如果你使用iTunes订阅新闻,起床后我只需要按一下同步按钮,视频音频都传到iPod上面去了,然后专心吃我的早餐,出门口时记得把iPod从同步底座上拔下来带走就是了。我在地铁或公交上有足够多的时间,把iPod拿出来看看或者听听头条新闻的时间是绝对是有的,甚至还能听听有声电子书。

由于这个功能在iTunes与iPod上就被命名为podcast,而且iPod在美国相当普及,所以大家就都叫podcast了。不过,Microsoft貌似避忌所有pod字开头的东西,以保持和Apple之间的距离,所以就坚持把同样的东西叫做netcast,这样显得中立一些。不过Zune2里面的功能菜单就写着podcast,看来负责整理Zune2菜单字符串资源的人有被炒鱿鱼的危险了……另外,国内有一些名为播客的东西其实不是播客,土豆一开始就给人如此批评了——不支持RSS订阅,也不允许下载,更别说放到iPod上了,这也想带上播客的头衔?

好吧,对podcast的介绍到此结束,稍后MVP博客的第0集将会发布到netcast.cnblogs.com,并且我还会另外发贴详细说明如何订阅podcast。敬请期待!