2006年1月30日星期一

The Redesign of Cat's Personal Indentity

"Cat"这个名称的使用率太高啦,别人不容易搜索到,这样比较麻烦。同时有时候要提供Unique Name的时候,也就只能用"cat_hsfz"或者"cathsfz"取代,很麻烦,要提供Logo/Photo时也没有。

现在决定重新设计整个Personal Indentity,包括Name和Logo,这要一段时间。Name的话,我准备改为"Cat*****",也就是在后面扩展,这样好像比较容易做过渡。然后要搜索一下,看看有什么结果,搜索是没有结果就最好了,表明这个名称是Clean的。然后再设计一个适合的Logo,就可以用于需要Logo或者需要Photo而不一定要真实Photo的地方。

大家有什么idea可以说哦!

2006年1月28日星期六

Time Fragment Management

在Social Convenience里面提到时间过于灵活时,就很容易产生随便,难于管理。这让我想起在C语言里申请内存空间时的一种策略。

这种策略就是,申请和注销内存空间时,大小总是2的n次方,如果你有点学数学的天赋,马上就能feel出这样做的好处??这样你就避免了空闲内存的大小是奇怪的数字,而让他们尽量也是2的n次方(或者至少,他们的大小的因数主要是由2组成),然后你再次申请空间时就很容易把空闲段用上了,从而减少碎片的产生。

在时间管理方面,我觉得也是类似的,虽然没有人给我们任何规则要求我们如何划分空间,你可以逃课,可以迟到5分钟叫做正常到课室上课,但实际上你最好有一种严格的分配策略来划分时间,而没必要为了节省几分钟而打破时间划分策略最后因为时间碎片而造成更大的浪费。

better plan往往就是打破时间划分策略的凶手,例如洗完衣服再去晚自习反正没人规定我多少点到。然而你想想在你中学的时候,是严格规定你几点出宿舍去自习的,你不能够说洗完衣服再去,没洗完你就只能晚自习回来再洗。看起来这样把你的戏衣服时间切割了造成了碎片,但实际上却保障了你晚自习第一节课的时间的完整性。这个完整性有什么用?例如你晚自习第一节课45min,这相当于一个contract,承诺任何小于45min的task你都可以放在里面完成,例如做一份需时40min的题目。如果你选择洗完衣服再去晚自习,那就打破了这个contract,你不能再确保40min的题目能否在剩下的时间做完。例如你洗衣服占区第一节课的8min,你就还剩下37min,为此你可能会选择课件再做3min把题目做完,但同时你也打破了课间10min的那份contract,你做完后剩下7min的课间可能难以填充什么进去。反过来,如果你保障了45min的第一节课,就算做完剩下5min浪费了,然后课间那10min你就可以另作安排,总好过浪费7min。

可能有人会说,better plan浪费7min和严格的时间划分策略浪费5min只是一种碰巧,有些情况回倒过来。没错,确实会,就好像划分内存无论如何都会有碎片,但如果你的碎片大小不是奇怪的数字,而是存在一定的数学规律(例如某个数的倍数或者次方),那么若干个相邻的碎片连在一起的的时候它的大小还是呈现出这种规律,同时你又是按照这种规律去划分,那么出现碎片的机会将减少,同时碎片浪费的比例也是一个可计算的值。但如果你没有任何contract的去用,产生的碎片及造成的浪费将难以计算。

HTML、CSS、Javascript有时间还是应该系统学习一下的

最近看了一下O'Reilly的《Javascript权威指南》,发现HTML、CSS、Javascript这些那么有“历史内涵”的东西,有时候自己靠模仿别人的代码来学只能学到一些表面的东西,呵呵……

所谓“历史内涵”就是指发展过程中因为各种因素而改来改去,要兼容这个兼容那个,还有企业为了竞争而把东西弄得不标准,等等。有复杂“历史内涵”的东西,你不系统学习,很多小东西你根本不知道,用起来就总是走弯路,例如有功能你不会用,或者用起来总是碰上浏览器不允许你这样用的地方。

以前我都是靠看Sample和MSDN学习的,不过MSDN其实也“太不中立”了,很多东西都是以MS的标准为主,虽然现在也把W3C标准的东西写到里面去了,但其时不全的,如果你以为MSDN里面的东西已经把W3C标准包含进去了,那就死定了。而且MSDN里面W3C标准的东西更新总要慢一些。

O'Reilly另外还有《HTML权威指南》和《CSS权威指南》,如果我有时间看书,一定买回来看看。不过现在自己看书的时间实在不多,常常开了电脑就不愿意看书了。嗯……一定要找个方法把自己的时间管理好。

Blogger的Template实在不爽

主要是帮助解释不清楚,搞到有时候你以为这样写Template没问题,而Parser却按照另外一种方式帮你生成HTML(可能Parser根本没想过你会这样写),哎……

做项目做得累了,上来发发Blog,嘻嘻……

2006年1月27日星期五

Social Convenience

为什么学生会那群人整天去贝岗村吃饭和劈酒,而且还挺有“等级意识”的,一开始我也不懂,不过现在逐渐发觉确实social的成分很大,而且有时候必须为了social而social。

在中学的时候,你根本不需要所谓的Social Convenience(社交便利),因为你和你的同学天天见面,所有课都一齐上,一起吃饭,一起回宿舍,一起熄灯后讲话(因为宿舍没有电脑没有QQ)。这就好像在玩Sims时一样,如果你一直在social,该项需求一直都是在高度满足状态。当时有位美院的师兄面对我很不屑于CS的态度说,你知不知道为什么大学里那么多人玩CS,这其中有一个因素就是平时同学之间交往的机会非常少,而CS正是少有的能够进行社交的一项活动。我当时对此持怀疑态度,因为打CS好像娱乐成分远比社交成分要低。

但现在,我才发觉大学生之间真的是如此缺乏日常社交。这里面有很多原因,不过我认为最直接的原因就是时间差,因为时间松动了,不再是中学那种所有人都一致的作息时间安排。可能你觉得这个时间段忙这个好,我觉得那个时间段忙那个好,而只有当两个人都是空闲的时间段才可能用于两个人之间的social,这就造成了:1.用于social的总时间减少,往往你得闲时别人不得闲,你想拉人和你一起去吃饭时别人忙于打机;social的对象难以固定,随机性大,今天可能只有A有时间和你一起去吃饭,明天可能只有B有时间和你一起去吃饭,你难以做到一群熟人总是有若干固定的时间在一起。

这个问题的出现,导致必须找时间一起social,就好像学生会那群人一样。一个人在宿舍很无聊的时候,你就会想找人陪你聊天什么的,至少陪你下楼走一趟吃点东西,不过A在打机、B在洗衣服、C在赶作业、D在洗澡……等你郁闷够了开始看电影了,可能E就来问你有没有兴趣陪他下楼买烧烤,然后你告诉他看完电影再去,于是轮到他郁闷。面对这样的问题,最直接的做法就是“合作”,也就是我们商量定一齐social,可能今晚你牺牲打机时间,明晚我牺牲做作业时间,但总算找到了一个解决方案。但是,显而易见这样的social效率显然比较低,因为总有人有所牺牲,至少“觉得是牺牲了”。

其实“牺牲”这个问题说起来就很奇怪,在你受到严紧的作息时间限制时,大家有共同的Social时间,而且你不能选择把别的事情填充到这里(例如中午一起吃饭,因为你不能选择中午上课提前吃饭),所以你不会觉得是牺牲。但是在时间很灵活掌握的情况下,和严紧作息时间对比你会有better plan(例如你确实觉得中午上课更有学习效率),这时候你就会认为放弃better plan而去social是一种牺牲了。暂时来说,我找不到在时间过度灵活的情况下如何安排social,因为这不是个人时间安排,而是要看多个人的时间安排的。

2006年1月21日星期六

花了一些时间,重新让Template符合XHTML

现在使用的是XHTML 1.0 Transtition,以为符合XHTML了就能够XMLHttpRequest获取到XML了,结果发现Parser好像还是不承认,那没办法啦,只好考虑真的输出XML了,然后我另外做一个Blogger页面。

寒假有n多的Web项目要做,看来没时间做别的事情咯,呵呵……连思考和写Blog的时间都不多了。CooWona开工了,有空要关注一下,好像是挺有价值的一个项目。

2006年1月19日星期四

Live Messenger 的共享目录其实很好用

对比传统的传输方式,利用空闲时间空闲带宽自动上传以达到同步实在很好,不用你专门去手动上传或者传给对方,不过好像没有办法看到是否已经传完。

最近买了台TX,又要找各种适合的最新的Palm软件啦,于是就和Piggest狂交换软件,用的就是Live Messenger的共享目录功能。有什么好用的软件,就扔到上面去真的很方便。

看来IM集成文件共享甚至P2P应该能够做大,反而传统P2P要加上聊天功能则用的人不多,因为不是基于真实中的好友。应用SNS的理论吧,朋友之间需求的东西重叠面往往更加广,对于P2P来说这本来就是一种优化,唯一的问题就在于两个人的上线时间可能不同,而P2P必须同时在线,如果这个问题能够得到解决,例如如何寻找好友共同在线时间,基于SNS的P2P可能比Shareaza那种Hub-Leaf模式更加有效。

2006年1月16日星期一

准备彻底改造我的Blogger Template

首先,我准备为友情链接都加上ajax方式的ping,自动按照ping排序。然而,如果每次点击进入一篇blog的comment又要切换页面,造成友情链接列表又要重新通过ping来排序,所以现在就要连打开comment也换成ajax实现。

另外昨天看到Coo的del.icio.us收集了一个如何实现同一个页面多个XMLHttpRequest请求的文章,其实用数组实现还不如封装成XmlHttpRequest Pool,就像调用数据库时的Connection Pool那样,让Pool自动管理哪一个XMLHttpRequest空闲,当没有空闲时自动创建新的,当达到Pool最大容量时就抛出错误。

2006年1月10日星期二

HTML + AJAX + WebService = C/S or B/S?

关于事物发展总是呈螺旋曲线形上升的,我总是很同意,事情发展到一定的阶段其属性又和发展之前相似了,不过本质上已经提升了一个层次。

最近我和一个做Java开发的朋友聊天,他说他在为点心做一套BOSS的系统,准备全部用WebService,然后前端WebUI通过AJAX方式调用。详细的我不说了,如果去掉JSP部分,我们考虑发展为HTML + AJAX + WebService,是不是又回到了C/S时代?我们不再需要为一个跨越两端的东西(Page,也就是View)而编程,清晰的MVC再次出现,而大量ServerScript变成清晰的WebService同时处理重点再次转移到ClientScript,这是不是ThickClient的再现?呵呵……

C/S就C/S吧,又没什么不好,或许Avalon + XAML + .NET也是这样的模型。经过B/S的进化,这样的C/S也就规定了Client只能生存在某一个普遍使用的客户端框架下,例如Web框架,或者稍微不那么普遍的Java/.NET/Flash框架下。只要基于这个框架,那么Client的移植性是不会有问题的,老C/S架构关于Client移植性的问题也就解决了。Java搞跨平台那么多年,最终最成功的跨平台客户端框架是Web;MS现在自称其SmartClient思路集C/S + B/S + RIA的优势,而去掉这三者的劣势,不过最终能够达到这一目标的可能又不是SmartClient而是别的东西。

Windows Live Messenger Beta的赚钱业务不少哦!

在MSN7里面,就已经有个叫做“动漫传情”的东西,虽然只有几个可能,但从一个“更多”的按钮就能够看出应该是能够有下载的,而下载不提供在内证明肯定是付费服务。到了MSN8,终于开始把这些收费服务推上线了。

在图释里面,有了几个大大的图释集合图标,点下去就会打开新窗口出现如下网页。一个图释集合大概有6~7个系列图释,价格为$1.5(对于美国用户来说不贵),可以通过手机或者信用卡支付。
LiveMessenger.Emoticons.Selling

然后我就顺便看看这个网站还有什么好买的东西,以下是图释集合的列表,看起来有些确实很有趣哦,不知道MSN8正式发布时会不会有中国区的价格,有的话相信不少人会愿意买的。
LiveMessenger.Emoticons.Selling.List

这个是所谓的Muggins,应该就是用与MSN头像的啦,这样看起来好像放在玻璃窗里的展示品,模模糊糊的,不比QQ Show的好看。
LiveMessenger.Muggins

但是你进入Muggins购买页之后,就会发现这个东西比QQ Show要强大得多。首先,它是全Flash的,人物身上的东西先选要哪件,再选主色调要什么,搭配好整个Look了再付钱。一个Look就$3,比起QQ Show要一件一件衣服和首饰付费还有半年就过期好得多。另外这个Flash头像还会动的呢,平时会眨眼啦,如果你输入例如":-)"的表情符号,它就会笑一笑啦。在下图这个页列出了各种表情符号,你可以去尝试预览它们对应的动态效果如何,这个可比gif贴图而成的QQ Show强多了!
LiveMessenger.Muggins.Moods

作为Live Messenger Beta的用户,我觉得MS应该送我们每人一个Muggins嘛,反正才$3,然后等MSN8正式发布之后我们这些Beta用户肯定会为了展示自己的Muggins大力推广MSN,拉其他人都过来看自己的Muggins的。

2006年1月9日星期一

世界上最大的SEO

世界上最大的SEO,不就是Google自己咯。面对GFans.org首页那句“不讨论 SEO 及相关”,有时候真的不知道该怎样想好,作为Search Engine,自己当然是自己最大的Optimizer啦。

留意在Google Account上面列举的Google Service,你能够看到Google Urchin,这个实际上就是Google Analytics。当然,我不是很明白Urchin是什么,然后就进去看看到底是什么回事,然后找到这里:
http://www.google.com/analytics/urchin_software.html

Urchin Software就是Google提供给例如Intranet的离线Analytics服务软件,而这个软件只能通过Partner Service购买。虽然这个软件还没有中文版,但我们看看在中国能否找到Partnet Service:
http://www.google.com/analytics/support_partner_provided.html

然后在中国区找到唯一一个:LexAd Advertising(http://www.lexad.cn)。进去后title大大个SEO(不知道为什么现在打开这个网站已经打不开了),原来Google的“合作伙伴”本来就是专门为客户做搜索引擎相关服务的,呵呵……

其实,SEO是个中性词。虽然Google官方网站也叫大家不要信SEO和使用SEO,否则可能受到PageRank Zero惩罚,但是Google也有合作伙伴是SEO。这个词就如“财产”,关键是是否“合法”,合法财产就受到保护,不合法的就……

通过合理分析站点数据(例如用Urchin)优化站点获得的流量提升,那就算是正当的SEO。没有那么多流量充大流量的,那就是非法的SEO。当然,事实不会是那么绝对的,现实中有很多“灰色收入”,SEO也一样,这个就算是Google也没办法准判啦,呵呵……

2006年1月8日星期日

很久没有上过“Internet”了……

90年代末上网的时候,都还可以说是Internet。虽然是拨号上网,但是接上去之后你就会发现哪里都能去,哪里都能访问,慢也是全世界一起慢。

现在情况不同咯,小区宽待或者类似的LAN接入形式不用说,先要LAN内相处好。就算是所谓的直接接入,甚至是光纤接入手头上有几个Internet IP,感觉也不过是接入了一个WAN。想要和其他WAN沟通?WAN与WAN之间速度慢是一方面,还可能有各种因素让你无法访问另外一个WAN的一些内容。

反正,不再有接入Internet那种想去哪里就去哪里的感觉,就像以前白云山鸣春谷那些小鸟一样,不是放在LAN这样的小笼子里,而是放在WAN那样的占据整个山头的大笼子里,但还是出不去哦(生殖隔离,人工选中,问你死未)。希望WAN的界限能够打破,因为鸣春谷那个大笼子都已经拆了。

2006年1月7日星期六

不太敢在Blog发表太多Idea

在中国真可谓“天下服务一大抄”,再好的Web 2.0服务或者创意,都会有人抄。本来就只是说中国人喜欢抄一些硅谷新兴网站的创意,现在中国人抄中国人的网站也有了,www.douban.com就给人抄了,实在是让人觉得抄袭者太可怕了。

本来借别人网站的服务特色融入到自己的服务中,自己的服务突出另外一种特色,这也算很正常嘛。但就是完完全全抄别人的一切,甚至连页面布局都是抄的,这实在是太没有水平了。以后还是不要发那么多东西在Blog好,内部的东西还是发到内部的Mail List,免得那么多人知道。

终于弄好了Cat's Project子站点

其实这是和Piggest商量了很久要做的事情,就是专门弄一个地方用于作品展示,把自己的作品都收集起来整理好放到这上面。

现在先把这个作品展示站点放出来:
http://cathsfz.sitesled.com/project

然后慢慢添加东西上去,把以前做过的作品能够整理出来的东西慢慢放上去,不过重点还是把以后的作品链接上去。

2006年1月4日星期三

XFN - XHTML Friends Network

刚刚发现了这个挺有趣的东西:
http://gmpg.org/xfn

它的大概作用就是,在XHTML的标准上还是用语义网的思路定义一种用于表示朋友关系语义的attribute。一般用于Blog特别是Blog中常见的链接到朋友的Blog的友情链接区域。这是一个trick,仅仅是为了将来能够理解这种语义的parser来解释,它就是在a这个tag上面加一个rel的attribute(根据XHTML 1.1,a能够有rel吗?这个要查查),然后这个rel用空格分隔的形式可以写入以下关键字:

关系:friend acquaintance contact
现实:met
专业:co-worker colleague
地理:co-resident neighbor
家庭:child parent sibling spouse kin
爱情:muse crush date sweetheart
标识:me

简单来所,你可以用一下这个页面为你生成一个你需要的有rel的a:
http://gmpg.org/xfn/creator

我主要是觉得这个思路不错,在原有的XHTML标准上,利用一些没有最小化attribute应用范围的空缺,用于自己的语义标记。只要这些语义标记不经过某些“自作聪明”的parser然后被过滤掉,那么这份XHTML就能在传递途中永久保留这些语义。在XFN的background中作者谈到,基本的设计出发点就是as simple as possible,这是一个很好的思路,别人的架构如果足够优美而又有空间放你的东西,何必自己重建?

现在所有在线Calendar和Todo做不好的地方

那就是不能够和其他服务、软件同步。特别是对于平时用Outlook/Exchange Server和PDA/手机同步的人来说,自己已经有大量的数据,不能够同步到网上的服务,为什么要去用网上的服务?

其实要做同步不难,很多大型的这类服务都采用类似IMAP的方式来存储(因为都是由做Email座过来的),都支持类似IMAP接口的查询,至少Outlook/Exchange都是。但到现在为止,除了当初MSN Premium用户能够享受Outlook Connector同步以外,我还真的没见过哪个网站能够同步(Sharepoint的不是同步,Sharepoint是在Outlook里面添加一个新的、使用在线数据的Outlook Folder)。

现在要做这个应该已经不难,特别是对于ASP.NET来说。Windows Mobile 5.0的Outlook和Outlook2003都有很好的.NET编程支持,一个Session.*List就能够把整个联系人列表或者约会列表的枚举弄到手,接下来同步的事情还不容易?假如我要做这样的服务,肯定会考虑对Windows Mobile 5.0和Outlook2003提供同步支持,甚至高级同步支持。所谓的高级同步支持,就是要像Web 2.0的操作那样,没有明显的操作延迟(同步那个时间很长啊),尽量不打扰用户、不需要用户显示操作或者回应某些问题,能够自动根据网络环境优化操作。

2006年1月2日星期一

SNS的两个业务重点

1.Personalization,也就是个性化。这是很多SNS发展起来必须要做的东西,例如提供Blog、Podcast服务啦,提供个性化主页(也就是不允许你设计HTML但是允许用它提供的组建简单设计,例如MSN Space)。为什么要允许个性化?这是个很严重的问题,因为SNS甚至Web 2.0的重点就是人人参与,人人有股份,所有人人都要推销自己那一部分顺带就推销了整个整体(上次任敏跟我说这东西现在有个名字,叫做“??公关”,“??”是什么她也忘记了)。

有一句话,叫做Every one would be famous for 15 seconds(人一生中总有15秒钟的辉煌),或者叫做15 seconds of fame。而做Blog/Podcast的,有人说甚至包括参加超女的,都是为了这15 seconds of fame??赢了就是一辈子的fame,输了也算体现了15秒的。

所以允许个性化,允许张扬个性很重要,这是任何一个Web 2.0项目成功的关键。不要强迫用户行为符合某些“业务逻辑标准”,最好他们什么都能做,无论做什么都能体现个性:Blog发表是一种自由的方式,自定义门户页是一种自由的方式,tag则是我认为至今为止最自由最突破业务逻辑限制的方式,至少在Web上是。我们期待Web上能够看到好像Lionhead Studio的Black & White甚至是The Movie那样高自由度游戏的使用方式(详细可以看我那篇《关于模拟游戏和Spore》中关于Game plays men的部分)。

2.Social Network,这就是SNS本身的业务,而其重点我认为是Karma和Testimonial/Review。Karma直接翻译就是佛教的“因果报应”,也就是你现在所做的事情将影响到你将来的命运。例如你曾经如何对别人,那么在Social Network上就会反应过来别人对你的Rating和Review如何,而且这些Rating和Review是“不可拒绝”和“相对匿名”的。(“不可拒绝”指的是在现实中有人要在你背后说你坏话,你是绝对阻止不了的。“相对匿名”指的是发表对你看法的人在他的人际圈中可以是实名发表,但对你来说这个影响源头是匿名的、不可知的。)

例如Orkut,我认为最好的一个SNS,当初能够赢Friendster我觉得仅仅就是因为它加上了Karma和Testimonial这样好玩的小功能。至于iKarma,这样一个为了Karma和Review而存在的SNS,属于纯商业性关系型的SNS所以不做个性化部分,能否单纯靠Karma服务而存活,暂时还很难说。

Karma一个有趣的地方就是,我允许你个性化,你做什么都可以,我不从系统层面或者管理员层面给你设置任何游戏规则,真正的游戏规则是好像社会道德那样来自每一个人对你的看法而造成的约束。如果一个论坛,不是通过论坛过滤禁用词,也不是通过管理员惩罚使用禁用词的用户,而是通过Karma这样的方式来提高使用禁用词的代价,那么每一个人都会明白发表禁用字不仅仅是系统会拦截或者管理员会不爽,每个用户都会对我不爽,那我还是不要发好了。

R3Y设计里面基于发送者的贝叶斯统计和垃圾过滤也是基于类似的思想,我不会说因为机器根据统计觉得你的是Spam就是Spam。而仅仅当你的朋友觉得你的消息是Spam时我才帮助他阻止你的信息;但是如果有另外一位朋友觉得你的不是Spam还非常乐意为你转发,那么你的消息还是能够畅通的发送给那位朋友。然而总的来说,决定你发送的消息是否为Spam的不是系统,而是其它人,这比起Google所谓的“系统结果决定一起,不参入任何手工结果”更加进一步。