January 11, 2005
2004年给人印象深刻的二十个博客网站
1. 狗日报 http://www.18mo.com 因为它获得了年度博客奖，让人们认识到专注在博客上的价值
2. CNblog群组博客 http://www.cnblog.org 一个优秀的群组博客，关注面颇有延续性，但传播价值还有待提升
3. 博客中国专栏作家群组 http://www.blogchina.com/new/member/ 这是国内最具影响力的博客群组，几千专栏作家，每人发出一声独立声音，足以让互联网获知震撼力。
4. 对牛乱弹琴 http://www.donews.net/keso/ 洪波的个人博客，在IT评论方面有自己的见解，另外，这个blog告诉人，做blog，贵在坚持
5. 思维的乐趣 http://blog.mindmeters.com/ 这是一个比较有思想深度的网站，站长方军的个人博客也很有特色。
6. Chinese Tea 博客组 http://christina.tecinese.com/ 这个博客组从2003年就获得了很多人的推崇，在2004年，它继续成为少数几个优秀博客的代表
7. 北京印象 http://vincent.com.cn/ 个性化，简洁，低于特征
8. Wangjianshuo’ blog http://home.wangjianshuo.com/ 中国最好的英文blog，作者开放的心态很好，也因自己的认真记录，获得广大博客的认同
9. Owen’s blog http://blog.timetide.net/ 中文博客先行者之一，其个性化和点到为止的特质，使其博客在优秀博客中更凸现其特殊的价值
10. 六翼的天使: http://blog.wespoke.com/ 一年300万访问数，算中国博客访问量记录最高的网站之一，作者卢亮是中文博客先驱之一，创建的博客动力是中文三大博客托管网站之一
11. 巴黎洋相：http://tillnowly.blogone.net/ 这是典型的女人博客，并获得中国博客网年度最佳博客。她的叙事手法非常耐看，思想深度不一般，博客让人认识到她是才女一个。
12. TOPKU：http://www.topku.com/ 关注博客领域发生的一切事情，或许其理想是做一个批评感很强的Blogger。在博客圈中有自己独特的个性。
13. 车东的blog http://www.chedong.com/blog/ 中国最知名的技术博客之一，他竟然发动了他自己的父亲来写博客，将博客推动进行到父辈。
14. Chin’s blog http://chin.blogchina.com/ 博客中国PHP组经理覃健祥的个人博客，一些技术心得汇集。他个人发动的救助罹癌的张琳同学，让人看到了博客的力量，使人深为感动。
15. Ziboy的图片blog http://www.ziboy.com/ 一个漂亮的图片博客，作为一个社会记录者，他的持久记录，是一个优秀博客必须具备的品质。
16. 22cather http://www.22catcher.com/ 优秀的社会记录站点，用镜头说话，或许手法不成熟，但内容绝对是图片博客的领先者。17. MkGenie Polaris http://mkgenie.blogchina.com/ 关于迈克尔?杰克逊的最佳博客，也是博客公社优秀博客。作者为著名乐评者，博客信息量大，深得音乐爱好者和MJ爱好者的喜欢。深度和专业是该博客给人的第一感受。
18. 胖子的博客 http://pangzi.blogchina.com/ 一个学英语背单词的好blog。这样的blog代表着博客公社的博客特色：他们刚刚开始Blog，但他们做得非常认真，做得非常优秀。
19. 诗哲魂：纯粹生态人生与思想 http://shizhehun.blogchina.com/ 思想深度和博客形态的完美结合，博客公社优秀博客的代表
20. 新语丝 http://xys.3322.org 方舟子主持的网站，以每日更新的形式提供了大量独立分析的信息，虽非博客网站，但采用博客形式，在学术打假方面，它始终是中文网站的先驱。2004年更因甘德怀考博事件成为引用最多的原创信息网站。
优秀的博客太多了，这里不可能把所有存在的优秀博客都给列出。上面是我会去看并且深感受益匪浅的优秀博客。或许您的博客也很优秀，暂时还不够知名，或者乐于默默无闻，但只要记得一句话：“博客反映的是您存在的一种状态，或好或坏，无须在意。”您的博客就一定能够找到知音，并最终受到更多人的关注。 2005年您要做的仅仅是和更多的朋友通过博客进行沟通，那样，他们也就会知道您的博客极其优秀的存在状态。
Posted by ch1v4n at 01:15 PM | Comments (2) | TrackBack
November 18, 2004
微软社会性网络-Wallop
微软推出了社会性网络（SNS）服务Wallop，Wallop能够让我们和朋友们交互，分享照片、音乐及Blog等。Wallop界面由Flash做成，界面清新，风格独特（要求浏览器安装插件Flash 7）。 
Continue reading "微软社会性网络-Wallop"
Posted by ch1v4n at 08:33 AM | Comments (1) | TrackBack
November 15, 2004
从RSS新闻聚合谈起
可否提供一种工具，提供对非RSS的源进行聚合。比如订阅某一个传统HTML页面，通过对页面元素的分析选择，形成RSS文件，或者仅仅显示自己感兴趣的内容（比如去掉广告、图片、无谓的装饰等）。我曾经用lynx dump一个页面的信息，然后截取自己喜欢的内容。页面源是http://www.wz121.com，我截取的内容是里边的文字天气预报信息，用来放在一个论坛上。
代码如下：
#!/bin/bash
cd /usr/local/weather/
lynx -dump http://www.wz121.com/welcome.asp |grep -A 30 专业气象台 |grep -B 30
" □" > weather.info
cat weather.info |grep -B 30 ℃ > weather.info_
cat first > /var/www/html/leobbs/weather.html
cat weather.info_ >> /var/www/html/leobbs/weather.html
cat last >> /var/www/html/leobbs/weather.html
最终的页面内容如下：
http://www.hikz.com/leobbs/weather.html
Posted by ch1v4n at 04:15 PM | Comments (0) | TrackBack
November 10, 2004
离散标签和连续标签
我的观点是，应该用自由标签、传统树状分类相结合进行分类。
自由标签是离散的，可以进行个别内容的迅速定位。
树状分类能对内容进行有层次的有效组织。层次性的分类，应当是不能被遗弃的。
为了统一起见，可以这样定义：标签分为两类，连续和离散。 当两个标签之间没有从属关系，那么它是离散的，当一个标签明显的可以从属于某一个标签之下，那么它是连续的（这个名称也许有一个更好的代替）。
要么来一种另外的表达方式：所有的标签都是离散的，但是一个标签可以包含另外一个标签。比如我赋予某一个实体属于标签“music”，那么，它可以同时被赋予标签“entertainment”，或者“hobby”。事实上，很多实体（Entry）很适合这么做。
再来一种表达方式：所有实体可以赋予n个标签以便分类。标签也是一种特殊的实体。
Posted by ch1v4n at 11:10 AM | Comments (0) | TrackBack
What is Furl?
Furl is a free service that saves a personal copy of any page you find on the Web, and lets you find it again instantly by searching your archive of pages. It's your Personal Web.
Furl offers the best ways to share the content you find on the Web, and recommends new Web pages that may interest you. You can also search Furl to find the best sites that other people are saving.
Furl is used for many purposes by many types of people. For travel planning. Recipe sharing. House-hunting. Medical research. Thousands of people use Furl every day to save, share and discover information that is important to them.
Instantly. Simply. Guaranteed.
Continue reading "What is Furl?"
Posted by ch1v4n at 10:55 AM | Comments (0) | TrackBack
October 19, 2004
推荐一个极好的网络书签：“美味书签”
先说明一下，书签，就是收藏夹，在IE里大家保证都用过。只不过IE的书签，仅仅是在本地使用。
现在流行的网络书签很多，为什么单单说它极好呢？
首先它的网址很有意思，Del.icio.us，去掉点号，就是美味的意思（Delicious），老外的想象力确实丰富。
第二，任何人的Del.icio.us书签都很可以让他人共享，你可以非常容易地找到大量自己感兴趣的书签。你可以订阅某人的所有书签，或者仅仅订阅他的一个分类，比如“音乐下载”这个分类，哈哈，他辛辛苦苦收藏起来的书签，你可以毫不费劲地得到。 这种做法，现在已经有一个专门的名称，叫“社会网络”。 MSN, QQ属于“社会软件”。
第三，那是他的分类方法非常有特色，跟IE的按目录分类不同，他使用TAG分类，TAG就是“标签”的意思。比如你收藏了一个音乐下载的网站，也许你会觉得把它归类于“音乐”、“下载”、“个人爱好”、“娱乐”都可以，那么就同时用这么多TAG来识别它吧。如果用目录分类，你要给它复制好几个副本才能做到这样的事情。
这有点类似于GMAIL用LABLE对邮件进行分类。
第四， 添加收藏非常方便，用一个插件，可以直接在IE浏览器的右击菜单里看到“添加到我的美味书签”这个按钮。
大家为何不试试？
我的书签地址是：
http://del.icio.us/1v4n
Posted by ch1v4n at 09:50 PM | Comments (0) | TrackBack
October 13, 2004
Del.icio.us & Linkedin
刚刚申请了Del.icio.us和LinkedIn帐户。
Del.icio.us是一个网络书签，中文称“美味书签”，属于“社会网络”，所有成员之间可以互相共享书签。使用Tag进行分类。
我的美味书签：del.icio.us/1v4n/, 将添加书签的快捷方式添加到右键菜单。
LinkedIn是一个按照六度理论建立的社会网络，人们可以在其中建立自己的关系网络，认识趣味相投的朋友并与之交流。
Posted by ch1v4n at 07:44 PM | Comments (0) | TrackBack
October 11, 2004
将pMachine的博客文章转移到MT上
刚刚将pMachines的所有博客文章转移到这里来。这是真正在MT上发表的第一篇文章，之前发布的文章全部是从pMachine转移过来的。
转移过程：
1、通过phpmyadmin将pm_weblog数据库复制一个副本，删除了出标题、正文和More字段的其它所有字段（由于先前大多comment都是自己写的，没有什么太大价值，所以也不要了），然后导出为SQL文件，再写字板里将SQL文件的一些内容替换，使之能insert到MT的数据库中。然后再通过phpmyadmin执行这个SQL文件。
之前试过很多方法，直接将pm_weblog数据库导出为SQL文件、Excel文件、XML文件等，均不成功。
2、然后再把一些通用的字段，如作者、所属博客、建立时间通过一条SQL语句进行统一修改。
3、将这些文章进行分类
4、修改文章发表的日期（时间就不改了）。逐个手工修改，好累啊。有简单好的方法，可惜pm和MT的时间记录格式不一样，需要进行转换，再加上已经将导入的文章分类好了。如果重新导入的话，会丢失分类信息。反正才125个文章，手工修改也是可行的。
Posted by ch1v4n at 11:34 PM | Comments (0) | TrackBack
MT快速发贴的书签
javascript:
bm=document.selection?document.selection.createRange().text:document.getSelection();
void(
pmentry=window.open(
'http://www.hikz.com/cgi-bin/mt/mt.cgi?is_bm=1&bm_show=trackback,category,
allow_comments,allow_pings,convert_breaks,text_more&_mode=view&_type=entry&
link_title='+escape(document.title)+'&link_href='+escape(window.location.href)+'&text='+escape(bm),'pmentry',
'scrollbars=1,width=450,height=650,toolbar=0,status=1,status=1,location=0,resizable=1'))
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
October 08, 2004
flickr, Photo sharing...
The best way to store, search, sort and share your photos
[url=http://www.flickr.com/]http://www.flickr.com/[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
G盘：Gmail作为系统文件夹
G盘：Gmail作为系统文件夹
早先，Richard Jones提出了GmailFS的概念。利用Gmail的高存储量作为文件系统来使用。bjarke受此启发，开发了一个GMail Drive shell extension的软件。
它在本地机器上为Gmail创建了一个虚拟的文件夹，让人们可以像使用资源管理器那样来使用Gmail存取文件。本地的文件是被转换成电子邮件的附件被发送到Gmail帐号中的。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
June 28, 2004
TikiWiki : Tikiwiki and Sea Surfing
[url=http://tikiwiki.org/tiki-read_article.php?articleId=51]http://tikiwiki.org/tiki-read_article.php?articleId=51[/url]
Tikiwiki and Sea Surfing
By: mose on: Mon 29 Dec, 2003 [11:43 UTC] (1699 reads)
Web applications are more and more popular, more and more used, and, in consequence, more open to abuse than in past years. Tricks like XSS and CSRF are begining to spread rapidly, at least in rumor, in specialized networks. All live web applications need to verify they have basic protections against such abuses if they intend to provide a trustworthy work environment.
Jun0 brought attention to the vulnerability of tikiwiki to the CSRF trick. After some examination and work, a commando patch operation added basic protection in tikiwiki. 1.7.5, under test right now, was created to meet the security needs of the community, and will be released in next hours/days. If security is vital to your activities, upgrade now to cvs version; branches 1.7, 1.8, and HEAD are patched. We need your help to track possible side effect of the patch, then we can release without fear of regression.
Here is the mail I recently sent to a small number of tikiwiki developers explaining the whole story...
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
June 02, 2004
Horda and Chora
The Horde Project is a group of developers who write Web applications
using the Horde Application Framework, itself a product of the
Project.
The Horde Application Framework is written in PHP, and provides the
common tools a Web application requires: classes for dealing with
preferences, compression, browser detection, connection tracking,
MIME, and more.
The Horde Framework, by itself, does not provide any significant end
user functionality; it provides a base for other applications and
tools for developers. You will probably want to install some of the
available Horde applications, such as IMP (a webmail client), or
Kronolith (a calendar). There is a list of Horde applications and
projects at [url=http://www.horde.org/projects.php]http://www.horde.org/projects.php[/url]
This software is OSI Certified Open Source Software.
OSI Certified is a certification mark of the Open Source Initiative.
==============================================
Chora is a web interface to viewing files, revisions, diffs, etc. from
a CVS repository, written in PHP and utilizing the Horde Application
Framework.
This software is OSI Certified Open Source Software.
OSI Certified is a certification mark of the Open Source Initiative.
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 25, 2004
分析：RSS带来“个性化搜索”
[url=http://www.blogchina.com/new/display/26494.html]http://www.blogchina.com/new/display/26494.html[/url]
分析：RSS带来“个性化搜索”
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 22, 2004
IM协议的开放
在Internet上协议的开放才真正的让它发展到现在这步田地。但是不知为什么，在现在的Internet上，封闭的协议却更多的放在大家嘴边，看看国人著名的腾讯，看看新时代的3721。而许久以前的MS的MSN与AOL的AIM/ICQ协议之争也让大家感觉封闭带来的不爽的感觉。我这两天仔细的看了看，把用户较多的几个IM的协议和第三方Lib找了找，发现，国外的技术也不想我们想的哪么封闭，大家最终还是要走向开放，不知国人什么时候也能走到这一步。
MORE...
先来看看MSN，令我想不到的是MSN有一个专门的网站用以说明了MSN的各种协议。而且有不少人以其文档做为参考开发了相关的Lib
Java：TjMSN、jmsn
Python：msnp.py、pebrot
近些年我用ICQ的次数越来越少了，虽然我使用ICQ最早，但是现在越来越难登录到ICQ上了。但是我想使用ICQ的用户不会在少数的。这里有ICQ各个版本协议的说明。而相关的Lib相比msn少了不少。
Java： Instant Messenger Lib (ICQ/AIM)、jcq2k ICQ v7 protocol Java library
Python：py-icq
找Yahoo message的协议真是不好找，但是还是FreeBSD提供了一个好的路径，在它的ports中有一个叫做libyahoo2的，让我们找到了一个新的天地。在它的站点中提供了Yahoo Message的Protocol Docs。
Java：YMSG Java API
当然，也有不少人要大而全，他们在同一个包中打入了多种IM的支持，一般包括MSN、AIM、ICQ、Yahoo、Jabber。
Java：PlanetaMessenger.org、Echomine Muse Communications API 、
Hamsam
更有人使用IM的协议做了一些有意思的事，这是一个使用MSN协议进行远程控制的软件叫做MS Shell。
不知在IM的世界中还会发生什么事。 :)
不过，这些所谓的开放其实也是很封闭的，唯一开放的原因是真的有不少人让这些协议开放了出来，我想国人的一系列的IM也会有这么一天的。我们等等罢
原文：
[url=http://blog.huangdong.com/comments.php?id=33_0_1_0_C]http://blog.huangdong.com/comments.php?id=33_0_1_0_C[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
MSN Messenger 编程
[url=http://www.msner.com/bbs/list.asp?boardid=13&page=1]http://www.msner.com/bbs/list.asp?boardid=13&page=1[/url]
ivanchen
axmanchen
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 21, 2004
PKM工具推荐
Internet资源 MyIE2 [url=http://www.myie2.com/]http://www.myie2.com/[/url]
MyIE2 的特色功能介绍
多页面浏览界面
鼠标手势
超级拖放
隐私保护
广告猎手
快速网络服务
Google 工具栏支持
外部工具栏
收藏工具栏
皮肤支持
人际资源 IncrediMail [url=http://www.incredimail.com]http://www.incredimail.com[/url]
IncrediMail 是一个与众不同的E-mail软件。它具有非常酷的视窗介面、寄信动画效果、可爱的收件信差。还有很多的信签、动画、音效、卡片等，可以组合成出非常炫的电子邮件。让写E-mail和看E-mail都变成新鲜的体验。
这个软件不仅界面超炫，而且功能强大又人性化。
用它可以管理YAHOO、HOTMAIL等各种非POP的邮件帐户，通过Message Rule功能可以轻松实现中国人比较习惯的多帐户方式。还可以根据不同的帐户显示不同的通知图标，比手机的来显示还要方便。对于普通EMAIL管理软件的阻止发件人，在服务器端预览邮件等功能更是不在话呀。实在值得体验一下！
文档资源 Mybase [url=http://www.wjjsoft.com/]http://www.wjjsoft.com/[/url]
Mybase 是一个功能强大且可随心所欲自定义格式及层次关系的通用资料管理软件， 可用于管理各种各样的信息，如：各类文档、文件、资料、名片、事件、日记、项目、笔记、下载的精华、收集的各种资料等等，即使毫无规律的资料，经过精心组织后，也一样可以管理得有条不紊。
Mybase 用途比较广泛，通常可以被用作：日记本、记事本、通讯录、相片簿、文档索引、电子书籍、学生笔记、教师备课、工作计划、学习研究备注、项目管理、知识库管理、客户资料管理等等。总之，其数据组织能力足够灵活，允许您自定义更多的适合具体情况的各种用途。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
TrackBack技术规范
TrackBack技术规范
出自：http://hedong.3322.org/archives/000351.html
原文是[url=http://www.movabletype.org/docs/mttrackback.html]TrackBack Technical Specification[/url],此处是译文。
TrackBack 技术规范
名称
作者
版本
描述
发送一个TrackBack Ping
取回TrackBack Pings
TrackBack Ping URLs的自动发现
例子
TrackBack实现例程
自动发现的例程
变动
1.1 (2002年10月10日)
1.0 (2002年8月28日)
致谢
--------------------------------------------------------------------------------
名称
mttrackback - TrackBack 技术规范
--------------------------------------------------------------------------------
作者
Benjamin and Mena Trott, movabletype.org
--------------------------------------------------------------------------------
版本
1.1
--------------------------------------------------------------------------------
描述
本文描述了TrackBack, 一个点对点通信和网站间互相通告的框架. TrackBack的中心思想是TrackBack ping的概念, 从本质上讲，TrackBack ping是一个请求，通告“资源A与资源B相关，或有链接到资源B.” 一个TrackBack “资源” 用一个TrackBack Ping URL表示, 这是一个标准的URI.
利用TrackBack,站点间可以互相通告相关的资源. 例如，如果博客(weblogger)甲希望通知博客乙他写了一些有趣的/相关的/骇人听闻的文字，甲发送一个TrackBack ping给乙。这完成了两件事：
乙能自动列出那些引用他的某篇文章的网站，到他网站的访问者能读到网络上所有与此文相关的文章，包括甲的文章。
ping在他的文章和你的文章间提供了一种稳固的、直接的链接，而不是那种依赖于外部行为（某人点击那个连接）的非直接连接(如反向连接referrer)。
--------------------------------------------------------------------------------
发送一个TrackBack Ping
TrackBack使用REST(Representational State Transfer,http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)模式工作, 请求通过标准的HTTP调用传送。要发送一个TrackBack ping, 客户端向服务器端发送一个标准的HTTP请求，然后接收一个简单XML格式的应答(详见下述).
在TrackBack系统中，接收TrackBack pings的URL叫TrackBack Ping URL.一个典型的TrackBack Ping URL如http://www.foo.com/mt-tb.cgi/5, 其中5是TrackBack ID. 服务器端可以用任何有意义的格式来定义TrackBack Ping URL;客户端不应该只限于特定的格式.
为了发送一个ping, 客户端发送一个POST格式的HTTP请求到TrackBack Ping URL. 请求的内容的content type应是application/x-www-form-urlencoded. 例如, 到http://www.foo.com/mt-tb.cgi/5 的ping请求可能看起来象:
POST [url=http://www.foo.com/mt-tb.cgi/5]http://www.foo.com/mt-tb.cgi/5[/url]
Content-Type: application/x-www-form-urlencoded
title=Foo+Bar&url=http://www.bar.com/&excerpt=My+Excerpt&blog_name=Foo
注意: 在旧版本的TrackBack规范中，ping是用GET格式的HTTP请求发送的. 这种方式将不再支持; 2003年1月发布的Movable Type系统将会去掉对GET方式的支持。.
可能的参数包括:
title
文章的标题
excerpt
文章的摘要. 在Movable Type系统中, 如果摘录信息超过255个字符将会被截断为252个字符, 并在后面增加 ...三个字符.
url
文章的永久连接. 象其它永久连接一样，这个连接应可能准确地在页面中定位文章的入口，因有疑问时这个链接会用到。
blog_name
发表文章的blog的名称。
在Movable Type系统中, 在上述的参数中只有 url 是必须的. 如果 title 没有提供，, url 的值将被用作标题.
对上述请求的应答信息，以XML格式编排，从而能实现应用层的错误检查。(HTTP层的错误将会这样返回--例如，如果TrackBack URL 所指的资源在服务器上已经不存在，状态码404 将会返回).
一个成功的ping将会返如下应答:
一个失败的ping将会返如下应答:
当然，应用程序应该允许将来根据需要增加字段，但应答的 XML 结构保持不变.
--------------------------------------------------------------------------------
取回TrackBack Pings
要取回某个特定TrackBack Ping URL收到的ping,向它发一个GET格式的HTTP请求，请求字符串(query string)是 ?_mode=rss. 在规范的将来修订中，--一旦从POST转换到GET的过渡期结束--这将非常简单，向TrackBack Ping URL发送一个GET请求，将返回一列ping.
一个GET请求样例如下：:
GET [url=http://192.168.1.103/mt/mt-tb.cgi/3?_mode=rss]http://192.168.1.103/mt/mt-tb.cgi/3?_mode=rss[/url]
对此请求的应答，要么返回如上所述的错误信息，要么返回一列用RSS规范格式标志的TrackBack pings, 整个应答内容的覆巢无根元素是
例如:
http://this.is/the/trackback/item/link/
http://this.is/the/permalink/
在标签
--------------------------------------------------------------------------------
TrackBack Ping URLs的自动发现
TrackBack客户端需要一种方法，来确实一个特定的URL或blog文章的TrackBack Ping URL. 服务器在生成页面时应内嵌RDF; RDF 描述关于该文章的元数据，允许客户端自动发现TrackBack Ping URL.
RDF样例如下：:
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
dc:identifer="http://www.foo.com/archive.html#foo"
dc:title="Foo Bar"
trackback:ping="http://www.foo.com/tb.cgi/5" />
注意: 由目前的检查器将嵌入XHTML页面的RDF信息视为不合规范，要通过检查需要将上述的RDF信息用注释符括起来:
这不是一个完美的解决方案，但是作为一个临时的应对措施它可正常工作.
其中的dc: 元素是标准的Dublin Core 元素; trackback:ping元素来自RSS 1.0/2.0的TrackBack模块，参见http://madskills.com/public/xml/rss/module/trackback/.
给定一个URL my_url, 客户按下列步聚来寻找TrackBack Ping URL:
发送GET格式的HTTP请求，取回 my_url对应的页面的内容.
扫描页面内容，查找内嵌的RDF. 页面中可能嵌有多处RDF--客户端要找到 dc:identifier等于my_url的那块RDF信息.
从RDF块中抽取trackback:ping值，这就是TrackBack Ping URL.
客户端一旦确实了TrackBack Ping URL, 它就可以发送TrackBack ping了 (参见 发送 TrackBack Ping).
自动发现的代码样例参见 例子.
--------------------------------------------------------------------------------
例子
TrackBack实现样例
为帮助那些有远见的开发人员在他们的系统中实现 TrackBack , 我们发布了一个TrackBack的独立的实现，它不依赖于Movable Type系统. 它可接收通过HTTP请求发送来的ping, 将ping存放在本地的文件系统中, 且可以返回某个特定TrackBack项(文章)的一列RDF格式的ping. 如果你要求，它还可以静态地产生 RSS文件. 例如，要将最近的15个ping列在工具条，这项功能就会泒上用场。
这个独立的TrackBack实现可从http://www.movabletype.org/downloads/tb-standalone.tar.gz下载.
它的发行遵循 Artistic License. Artistic License条款的描述在 [url=http://www.perl.com/language/misc/Artistic.html]http://www.perl.com/language/misc/Artistic.html[/url]
它的安装和使用指令说明在http://www.movabletype.org/docs/tb-standalone.html.
自动发现的代码样例
use LWP::UserAgent;
sub discover_tb {
my $url = shift;
my $ua = LWP::UserAgent->new;
$ua->agent('TrackBack/1.0');
$ua->parse_head(0); ## So we don't need HTML::HeadParser
$ua->timeout(15);
## 1. Send a GET request to retrieve the page contents.
my $req = HTTP::Request->new(GET => $url);
my $res = $ua->request($req);
return unless $res->is_success;
## 2. Scan te page contents for embedded RDF.
my $c = $res->content;
(my $url_no_anchor = $url) =~ s/#.*$//;
my $item;
while ($c =~ m!(
my $rdf = $1;
my($perm_url) = $rdf =~ m!dc:identifier="([^"]+)"!;
next unless $perm_url eq $url || $perm_url eq $url_no_anchor;
## 3. Extract the trackback:ping value from the RDF.
## We look for 'trackback:ping', but fall back to 'about'
if ($rdf =~ m!trackback:ping="([^"]+)"!) {
return $1;
} elsif ($rdf =~ m!about="([^"]+)"!) {
return $1;
}
}
}
这段Perl定义了一个过程 discover_tb. 给定一个 URL, 它会试图找到与此URL相对应的TrackBack Ping URL. 如果找到了，它会返回 TrackBack Ping URL; 否则返回 undef.
--------------------------------------------------------------------------------
变动
1.1 (2002年10月10日)
在此版本中，TrackBack pings 的发送用 POST 格式的HTTP请求代替 GET格式的请求.旧版本的GET方式将不在支持，MT中从2003年1月起也不再提供对GET方式的支持。
在RDF中，现在TrackBack Ping URL应在trackback:ping 元素中保存, 而不是原先的 rdf:about元素.
修改了 TrackBack Ping URL的样例的格式，用 PATH_INFO 代替了请求串(query string).
内嵌的供自动发现使用的RDF不再导致页面检查时出错。
增加了自动发现的样例代码.
1.0 (2002年8月28日)
规范首次发布.
--------------------------------------------------------------------------------
致谢
感谢Paul Prescod和其他朋友，他们的指导让TrackBack更符合REST.
--------------------------------------------------------------------------------
Copyright © 2001, 2002 Ben Trott and Mena Trott. All Rights Reserved. Posted by Hilton at November 7, 2003 11:28 AM | TrackBack
Comments
Hi Chergen,
我用的blog引用你说这个blog的“实验室成员个人blog大爆发”，成功了（也麻烦你将它删除吧），也就是说它是可以接收trackback的。
是不是系统不稳定，你再试一下？
Hilton
Posted by: Hilton at March 4, 2004 07:24 PM
在Blog服务器http://www.etc.edu.cn/blog/（Moveable Type） 中的Blog中，发送引用通告时会显示出错了（实际上已经发送出去，目的地能够接收到），但是它本身不能收到其他服务器发送过来的引用通告！请问这是什么原因，以及怎么解决。
希望能得到你的解答！谢谢！
Posted by: Chergen at March 4, 2004 07:06 PM
看的非常犀利糊涂，不知道在程序里如何实现
Posted by: kimjooy at November 14, 2003 09:55 AM
看了你的这两篇教材，开始多少对trackback有些了解了！
谢谢你的共享！
Posted by: tsingove at November 13, 2003 01:14 PM
从这个规范的定义来看，trackback系统是在两个支持tb的两个web服务器之间互相传递信息的一套机制。传递的信息有两类：
一是引用信息，以ping发送，数据包中可以含有 title、excerpt、url、blog_name等内容，其中只有url信息是必须的。这类信息，主要是想告诉对方，我这儿有一篇什么样的文章（如标题为何，摘要是何，URL是何等）引用了你的哪一篇文章（POST信息到的目标URL，已经指定了是哪篇文章了）。
另一类，是从某个站点取回这个站点的某篇文章收到的所有的引用。有了这个功能，你就可以找到所有与你兴趣相投的文章了（只少它们都引用了这篇文章）。
至于当你收到某人发来的ping时，如何处理，要不要显示，显示哪些内容，要不要分类，要不要计数，则是个人的自由，规则没有作规定。
不过有一点，就是没有必要分析referer，一是因为这个ping包中本身就有url信息，二是这个请求是web服务器发出的，请求头里可能没有referer信息。
还有一点，就是从规范中可知，trackback系统中，每篇文章有两个URI，一个正常的可以访问页面的URL，另一个用来接收ping的URL（即所谓trackback ping url)，至于后一种URL如何设计，规范也没作规定，只要这个URL中的信息能区别出是那篇文章，即可。
以上是我的理解，供参考。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
TrackBack新手指南(编译)
[url=http://hedong.3322.org/archives/000350.html]http://hedong.3322.org/archives/000350.html[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 18, 2004
Blog、IM、MSN机器人
Blog、IM、MSN机器人
(2004.03.16) 来自：Chinabyte 张翼轸
近期的IM业界实在是热闹，先是做IM的腾讯和做校友录的搜狐互相捞过界，接着又出了一个IMU，以开放式体系吸引合作者一起成长，而如今又有了一家叫www.golb.cn的网站在推出自家的blog服务同时，一并推出了支持RSS阅读和blog发布的IM软件。毫无疑问，越来越多的网络应用正在努力的和IM融合，寻求新的成长空间。
还是让我们先来看看golb.cn推出的IM软件GOLB BLOG TOOL。相信对于不少blog的研究者而言，这个软件的推出应该是一件令人愉快的事情——他们很早就在猜测的blog和IM合作如今终究有人开始尝试了。不过如果我们对于这款工具的功能仔细审视，恐怕就不会有太多的喜悦。说到底，GOLB BLOG TOOL不过是由三个功能RSS聚合阅读，BLOG更新，MSN即时消息简单的雷加在一起，而缺乏足够的整合，其远远无法发挥出1+1+1〉3的效果。
是的，在blog和IM融合问题上，GOLB BLOG TOOL离我设想的相差太远了。虽然在不久前的一篇文章（《谁应该和IM合作？》）中笔者指出过IM的终端软件特性决定了它在执行很多应用方面比Web有更好的表现，但是如果IM软件只是满足于把其他的软件功能简单的累加在自身身上的话，那么这种累加除了把软件变得越发臃肿以外，能够收到的效果是极其有限的。正如笔者在另一篇文章（《当IM和同学录走到一起》）中所提及的，对于IM软件和其他应用的融合，社会网络的融合是最关键的。
在笔者的脑海中，blog除了是一个自由的发表平台以外，其通过彼此之间的链接构建起来的那个blogger关系网络同样也是其非常独特而引人关注的一个新特性。如果IM和blog要融合的话，那么基于IM的关系网络和基于blog相互连接的关系网络的融合也就应当是首先应当考虑的一个问题。
想象一下吧，当你在你的IM中添加了一位新的好友，这位好友事先登记的blog也会立刻出现在你的RSS阅读软件中，甚至每次对方更新了blog之后，无须RSS阅读软件的反复检查，blog服务商就会自动通过IM把更新的消息发给你；或者与此相反，当你在自己的blog中添加了另一个blog的链接，对方登记的IM帐号也会自动添加入你的IM软件，你在对方blog中留下的评论都会自动通过IM发送给对方，你们彼此之间除了blog以外还可以依托IM进行更加方便的沟通——如果你们愿意，沟通的所有内容也可以反向的补充在blog上，供其他人参阅。
这样的一套应用，是不是比起现在简单的功能累加要来得有趣得多？是的，一切的关键就在于不同软件融合的不仅是他们的功能，更重要的是他们彼此的网络，从而发挥最大的效用——而这正是GOLB BLOG TOOL目前所匮乏的。
事实上，GOLB BLOG TOOL引发我思考的，不仅仅在于其IM和blog融合的思路，更在于其融合的第三条道路的选择。从已有的案例来看，Web应用和IM融合融合，搜狐的校友录走的是完全开发自己的IM软件从零开始的道路；IMU的思路非常具有创新性，它力图将自己的IM平台半公开化，让其他的合作者能够利用定制版或者插件的方法简单的完成融合——就个人观点，在技术上这是最理想的方法；而GOLB BLOG TOOL无疑是第三道路，通过纯粹与现有IM软件兼容的方法来实现融合——与其他一些一方面兼容其它IM软件一方面发展自己的IM软件，把兼容作为抢夺份额的敌意行为不同，这种融合只不过是在原有的基础上增加了一些与IM无关的功能，可以看作是一个新的Shell，一种善意的兼容。
对于这种第三道路，有的用户表示颇为不解，GOLB BLOG TOOL为什么不以一个MSN插件的方式发布，而是要制作成一个全新的MSN Shell。的确从用户的角度来说，在功能一致的前提下，我宁可选择装了插件的MSN也不要另外一个MSN Shell——插件可以装几个，Shell却只能用一个，有局限性。在这一点上，笔者也持同样的看法。但是笔者认为更值得我们思考的事，为什么在IM与WEB融合的问题上，我们一定要纯粹的从客户终端角度去思考，老是想着要在用户的终端软件上做点手脚呢？其实有另一种方法可能成本更低，而且更加有创造性。
你有玩过MSN机器人吗？没错，我说的就是从它身上发展出来的思路。所谓MSN机器人，其实也是一个与MSN兼容的Shell，但是与其他的Shell必须由最终用户安装不同，MSN机器人是采取类似服务器的安装方法，你在自己的服务器上安装这个Shell，并且利用对应注册的MSN帐号上线。其他的用户只需要把对应的MSN帐号加入自己的MSN好友，就可以通过类似以前DOS命令行的方式进行互动，从而获得MSN机器人需要的消息。如果把这个思路发展一下的话，就会发现很多好玩的应用。
还是以电子邮件为例吧。假如我是XXX.net这个电子邮件服务商的用户，XXX.ne基于MSN推出了一个IM邮件提醒的功能，只需要对方的MSN机器人把我的MSN帐号加为好友，并且把这个帐号和我的XXX.net邮件账号绑定，那么一旦我的邮箱有了新的邮件，XXX.net架设的机器人就会通过MSN 短消息告诉我有了新的邮件，大致的内容是什么。这是不是一个非常简单而且使用的IM和WEB应用融合的范例？要知道，这种融合的方式既不需要改变用户的客户端，也不需要在用户的客户端上增加什么插件，只需要用户被作为一个好友添加，一切融合就由此开始了，这是不是一种非常简单而且有效的方法？当然，这种融合方法的一个重要缺陷就在于MSN 消息只能是文字或者图片的，这个就局限了融合的应用，不过即使如此，对于许多的WEB特别是新闻、资讯网站，即使是这种程度的融合，也足够能够开发出许多实际的新应用来的。
事实上，目前阻碍这种思路实用化商用化的一个巨大阻碍就在于MSN的先天限制。在这里，我并不认为对于MSN通信协议的逆向工程利用会是一个问题（微软仅仅公开过MSN最初的通信协议，但是此后一直到如今V10的通信协议都是保密的），因为前面已经说过了，这是一种良性的兼容，微软恐怕应该鼓励才对。真正令人讨厌的在于MSN武断的最多150个好友的限制。要知道，我们目前看到的诸多MSN机器人都是被动式的，只需要用户添加他们，所以每个机器人的服务限制只是受到程序的负荷影响（比如机器人小布是每个3000人），但是笔者刚刚提及的那种与WEB应用融合的MSN机器人是主动式的，必须主动添加用户的MSN才行，这样就会直接面对每个机器人只能为最多150个用户服务的问题，对于那些有上万甚至几十万用户的服务上岂不是要同时启动成百上千个机器人才行。虽然150人的限制其实只是技术上的一个强硬规定，但是考虑到微软的实际情况，恐怕其不太可能为了一些MSN机器人的新应用而有所改变。
如此一来，就只能期望国产的IM软件能够有所行动了。目前关产的IM软件UC已经有了类似MSN上机器人小布的被动式机器人，但是主动式的似乎还没有看到。至于QQ，似乎还没有什么太大的动静。其实笔者最寄予希望的还是IMU，既然其上场就是以开放的合作平台作为重要的卖点，那么类似主动式IM机器人这样的新应用，其应该是乐于见到而且加入到现有的发展战略中去的——毕竟比起用户定制版、插件这两种开放形式来，主动式IM机器人更加简单，更加方便。
摇旗呐喊晚了，笔者在这里也就只能拭目以待，看看第一个与WEB应用融合的主动式IM机器人服务究竟花出谁家了。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 10, 2004
谁应该和IM合作？
[url=http://www.blogchina.com/new/display/25249.html]http://www.blogchina.com/new/display/25249.html[/url]
作者：张翼轸 2004-3-10 9:21:57
出处：博客中国(Blogchina.com) b25249c
前几日写了一篇关于IMU道路思考的文章，虽然大致把个人的思考表达了清楚，但是因为篇幅的限制，并没有能够展开讨论一个对于IMU未来发展的重要问题——为什么应该和类似IMU的IM合作，应该怎样合作？今日再撰一文，作为补充。
IMU还没有正式推出，目前只是一个友情测试版，可是我们在它的首页上便已经可以看到合作伙伴听说过的，没有听说过的已经达到了数十家。当然，现在所说的合作，还只是一个意象，就像你家店铺开张，有朋友送个花篮过来祝贺那样，表表心意多过实质的行动。要观察这些合作伙伴究竟能够和IMU一起闯出什么名堂来，至少还要等到第一个合作伙伴定制版IMU（功能上有突破的）推出以后才能说。
所以，目前笔者只能从理论上的角度来分析一下合作的原因和可能形式。
为什么那么多以网站起家的合作伙伴都会看重IMU的潜质？笔者认为一个重要的原因其实就在于如火如荼的WEB方式有着先天缺陷，而这个先天缺陷恰恰是以IMU这样的IM终端软件所能够弥补的。
第一个缺陷：非本地化。WEB方式当年最吸引人们的就在于它只需要一个浏览器，所有用户获得的都来自服务器，HTML及相关技术的出现大大简化了对于用户使用网络的技术要求，为网络应用的普及带来了不可忽略的影响。但是这种架构的实现以及对于安全性的保证，限制了其在用户端的信息存储（cookies是一个很有限的例外），这也就意味着即使是完全一样的信息，用户每次需要使用也都需要每次从服务器下载，其效率与允许本地存储的终端软件“一次下载，反复读取”的方法相比，其效率无疑地下了许多。虽然宽带的出现一定程度上缓解了多次需要多次读取的时间浪费，但是宽带无论如何发展，短期内要超越本地硬盘的速度似乎都是一件不可能的事情。而HTML技术的先天限制也决定了即使是同样的表达效果，其执行效率也无法与使用高级语言编写的本地终端程序相比拟，这样使诸如Java这样的小程序出现的一个重要因素。但无论如何修修补补，为了实现其通用性，WEB应用在表现的丰富性以及实现效率上是无法与基于本地的终端程序所比拟的——一个很好的例子就是WEB Mail无论多么普及功能多么强大，但是大多数高级用户仍旧喜欢使用EMAIL终端软件来收发MAIL。
但是，如果我们为了WEB的这个缺陷，把所有可以基于WEB的应用都终端化，又会遇到一个当年WEB出现之前我们不得不遇到的问题，用户必须为了一个很小的应用安装一个终端程序，越来越多的终端程序最终将使得用户不胜其烦，同时也会使得用户的系统效率越发低下，所以我们会发现不少网络服务商都为自己的服务推出了终端板，可是如何说服用户再新安装一个终端而犯愁。而IMU的一个重要思路就在于把这两个问题很好的解决了起来——IM作为目前最重要的网络应用之一，用户已经接受而且多半会把其作为一个不可或缺的网络终端，那么其他的网络应用就无需再设计新的网络终端程序，而是可以作为IM程序的一个定制版本或者一个插件的形式来实现，这样终端程序永远只是IM软件一个，可是可以实现的功能却可以不断的扩展，充分发挥终端程序的优势。
第二个缺陷：非即时性。严格来说，几乎不存在真正的即时通讯应用，IM只不过把终端软件与服务器互动的间隔缩小到很小的几乎可以忽略不计的时间单位而已。但是正像我们平常在实现中所感受到的那样，IM软件的即时性实现得很好，而绝大多数力图使用WEB来实现即时性的应用就效果来说始终不如IM软件。而这正是IM软件一个独家的优势所在。相信大家对于MSN已经非常熟悉了，这款IM软件一个让许多用户心动的功能无疑就是其EMAIL到达提醒功能，一旦你的HOTMAIL信箱收到了邮件，你的MSN Messager立刻会提醒你。以往类似的功能，一些MAIL Checker软件也可以实现，但是方法却是按照用户设定的时间间隔通过POP3协议去收取邮件，一方面做不到真正的即时性，另一方面执行的效率也十分低下。而MSN把MAIL Checker的功能通过IM来实现，不但达到了即时提醒的效果，而且执行效率非常高，仅仅在邮件到达的时候接受服务器的信息，并且发出提醒，平常根本不需要像普通的程序那样反复检查邮箱的情况。
如果读者对于前几年的IT发展使还有些印象的话，就应该明白其实上面谈到的问题其实就是当年关于信息获取究竟是用户主动的Pull（拉）为主好呢，还是以服务器主动的Push(推)为好呢？虽然当年的争论支持Push(推)并没有过得太多的市场认同，但是如今有了IM这样的一个终端平台，Push(推)再次大展宏图并非没有机会。
正是基于WEB上述的两个缺陷，使得笔者相信IMU这样以终端化，以IM终端化的形式为合作伙伴提供除了WEB以外的表现形式是可能获得众多服务商的认同的——终端软件的便利性以及IM终端的即时性是可以帮助他们提供更加友好的人机界面及功能，从而取悦用户的。
那么，具体的这种合作究竟可以哪几种形式出现呢？以下是笔者个人思考觉得可能的形式：
一、 与EMAIL服务商合作。其实我们之前已经提及过了这方面的优良先例——MSN Messager和Hotmail的无缝连接。但是MSN Messager的问题就在于其只支持自家的Hotmail和MSN信箱，而无法同时支持其他服务商的邮件服务。但是IMU目前的平台却为此提供了可能性，假设笔者目前使用的是XXX的邮件服务，那么XXX只需要和IMU合作，利用其提供的开放借口制作一个插件，笔者只要在自己的IMU上安装好这个插件，并且设置好信箱的基本信息，那么以后笔者的这个信箱只要一有了新的邮件到达，这个插件便会立刻获得服务器的消息，然后通过IMU告知笔者。甚至笔者还可以通过这个插件直接浏览邮件，决定是否需要删除，甚至直接简单的回复，而不需要劳驾庞大的邮件客户端软件。
二、 与论坛服务商合作。对泡论坛的人而言，最关注的莫过于有谁回复了自己的帖子。以往要想知道这个，无疑就需要频繁的更新自己的帖子，查看是否有人更新，如果需要查看的帖子一多，反复切换刷新就十分麻烦了。即使有的论坛程序比较智能，可以在一个特定页面监控所有帖子的回复情况，但是你也仍旧需要不断的刷新这个页面。而这个论坛服务商如果能够推出IMU的插件，一旦有回复的帖子，那么就立刻可以通过IMU的终端告知，甚至可以把回帖的程序作为插件的一个功能，方便用户在无需开启浏览器的前提下，不离开IMU就能完成回帖的功能。
三、 与校友录合作。这个问题其实笔者在之前的文章中已经谈到过了，目前腾讯在IM的基础上推出校友录产品；Dudu.com一开始就推出IM和校友录紧密结合的产品，但是用户有限；搜狐校友录最有优势，可是其推出的IM产品实在糟糕，融合性也差。其实完全不需要推出自己的IM产品，通过和IMU产品合作制作插件的方式来推出也许是更好的选择，对搜狐而言可以降低开发IM产品的费用，对用户而言可以少安装一个终端软件——为了方便的是用校友录而选择特定的IM产品我未必愿意，但是把其作为已有IM产品的一个插件，我是绝对欢迎的。
其实IM终端和现有WEB服务的合作方式很多样化，上面只是举了几个常见的应用来说明，其实笔者还想到了很多其他的合作方式，比如和网上连载书站、和网上银行、和易趣拍卖网等等，不过实现原理和形式都差不多，这里就不详细说了。
我相信IMU目前想做的是一件非常重要的事情——那就是让IM软件取代浏览器成为我们上网的起点以及最常用的主要工具。当然，这是一个任重道远的过程，也许仅仅依靠IMU一家是不够的，希望能够看到更多的IM服务商能够加入进来，一起推动这个方向的发展——至少在国内，网易泡泡和腾讯QQ这些IM的先行者都是可以及早加入的。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 01, 2004
推荐Jabber，可以与blog配合使用
Jabber是什么?
是另外一个开放式网络信息通讯工具,她可以跳出各种商业即时聊天各自为阵的限制.使用她可以搭建自己的服务器,与其它现有的服务器一起构成全球分布式服务网络!并且可以用她与现有的常用即时聊天工具直接聊天,这样你不必为使用这个新工具而失去在MSN\YahooMsg\ICQ上的朋友,也不必同时或分别打开Oicq\MSN\YahooMsg\AOL等多个工具软件去查找你的朋友是否在线.虽然由于这些公司的抵制,一些相关的服务被封掉了,但相信开放协议的威力一定会战胜这些商用的封闭机制,开放意味着越来越多的机构和组织的主动加入，而每个服务器的加入都在增加了jabber的用户群的整体数量，具备系统发展自组织正反馈形成的特征．
另外,更重要的是,她还可以作为Blog的客户端:即时获得你订阅的rss更新通知、并可以通过她远程发布到你的blog网站。本站所用的两个系统(nucleus和drupal)就有这个潜在的功能接口,但现在尚未测试安装.现有的各种blog网站系统都已经或正在开发支持jabber协议的插件．
可以预见一下将来，一种支持jabber协议和在这个协议基础上同时支持blog-api和rss协议的新的网络工具将代替现有的即时通讯软件和浏览器软件，成为每个上网人通向网络世界的入口，既可以自由上网浏览，还可以保存记录自己浏览轨迹(甚至搜索记录)到你自己的私人网络区(而不是现在依赖于客户端)，可对任何感兴趣的网页发表评论保存到自己的blog中，还可以与他人即时沟通分享信息．
下面一篇文章转自
27floor blog
2003-10-23 眼下即时通讯的功能越来越被企业界看好，以资本无穷的力量，被它看上的东西很快就会收归旗下，这趋势一直以来就是很明显的：前面有QQ收费，有腾迅不允许别人开发Linux下的QQ插件，近来还有微软的Office 2003，在这款Office系统中，IM占据了一个非常重要的位置，几乎所有的应用都同IM绑在一起。而且微软也有自己的企业版IM服务器，可以让企业搭建自己专用的IM系统。有这样的例子，MSN以后会走什么的路线就很难说了。而且微软已经发过消息说不允许别的客户端连接MSN，虽然这话到现在也没有成为现实，可危险永远存在。
Jabber正是这么一种对抗的力量，它是个开源项目，架构、协议全面公开，并且基于XML。而且它还是个分布式的系统，也就是说你可以架自己的Jabber服务器，注册到这台服务器的用户一样可以同其他地方的Jabber服务器上的注册用户联系。比如主站Jabber.org上的用户A，他的联系名是这样的：A@jabber.org，就像电子邮件地址，它可以同B@amessage.info联系，后一台服务器似乎是在德国。这样就构成一个分布全球的Jabber网络。同时，每个企业也可以建立自己的Jabber服务器，并且封闭外部接口，只供自己内部使用。-->>>>>>>>>>>>
Jabber设计的理念是服务器端尽量复杂，功能多样，而对客户端要求较少，这样许多功能都可以在服务器端实现，而客户端可以不管，甚至可以从客户端直接发送XML代码过去实现一些功能。
正因为如此，Jabber也可以通过服务器插件的形式实现同其他IM系统，如ICQ、Yahoo、MSN的联系，但这要求你注册的服务器安装了这些插件。但这些公司似乎都不愿意这样做，如Jabber.org就被他们封掉了，而不能提供，而amessage.info就还没有，有所有这些服务。
信息技术的发展已经到了协同工作的时代，正如MS office所表明的那样，可现在国内的企业似乎都处在个人单机工作的时代，距离还很大。但Jabber的特点表明它可以构建你想要的任何应用，比如同Office集成一下什么的。它开放，又基于XML，前景是很好的。目前Jabber基金会已经向IETF提出了一个标准，不知道同W3C或OASIS有无冲突。
在校园里有人在推UU校园通，它实际上也是个基于Jabber的系统，不过中文版居然不声明这一点，但它的客户端可以连接Jabber服务器的。
我的Jabber账号：qi at jabber.org/amessage.info
2003-10-23 09:51:21，由cathayan发表。目录：General
得分： 31 [ － | ＋ ] 浏览 301 次
Comments
Zoom.Quiet 说：
收到!
感谢您的指引!
FLOSS 事业实在发展的太快,都有些难以选择了!
再谢!
是从Windix’s Weblog 得知此处的!
于 2003-12-06 17:56:35 发表
Zoom.Quiet 说：
嗯嗯留个油箱!
于 2003-12-06 17:57:18 发表
小文 说：
太多好的选择了，有点眼花的感觉。嘻嘻……不过非常感谢能得知。
于 2003-12-09 18:45:30 发表
adpu 说：
这个可以说是超级好。协议开放，跨各种平台，分布式，支持XML，不论是个人用户，还是想整个IM平台的中小企业来说都是不二之选。
于 2003-12-09 20:04:56 发表
good! 说：
我也强烈推荐它!这是属于我们用户的即时通讯！
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
February 17, 2004
什么是trackback ping(引用通告)？
以下文字来自cnblog.org
TrackBack最早是Movable Type上的一个小功能。可以说就是这个小功能在blog界却掀起了一场革命。
TrackBack为将全世界无数个blog连接起来的功能。例如，当你读了某个网站的文章，想对此写下自己的感想。这个时候利用网站准备的讨论功能进行投稿是很最常见的做法。但这样只是把自己的评论意见写下来向别人的网站投稿，而你自己手里却什么也没留下。
TrackBack则与之有很大的区别。可以把评论写到自己网站上。然后向刊载原始文章的服务器发送该网页的URL及标题、部分正文、网站名称等信息（注）。尽管这一过程只是称之为“发送TrackBack Ping”，但通过这种办法，在原始文章的地方就留下了你的评论的URL、标题等部分信息。当然别人也可以向原始文章发送TrackBack Ping，所以在原始文章中就将包括你的TrackBack Ping在内的所有评论都记录了下来。
此外，如果你在自己网站上也设置了TrackBack Ping功能的话，那么谁都可以通过TrackBack Ping来发表针对你的意见了。这样，多家网站就通过相关话题而联接起来。各种评论在因特网上就像网眼一样联接起来。这样就创造出了与日记网站完全不同的文化。
注：发送地址采用原始文章指定的URL，这一URL就称为“TrackBack Ping URL”。最后的“128”为原始文章的专用数字，称为“TrackBack ID”。另外，TrackBack的技术标准刊登在“LowLife.jp”的blog网站上。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
February 13, 2004
知识共享者维客：听维客之父细述Wiki前世今生
作者：尚进 2004-2-12 17:00:34
出处：博客中国(Blogchina.com) b23142c
维客：知识共享者与第二个博客
尚进/三联生活周刊
导语：当新创刊的《商业》在第一期封面上醒目的写道，“大前研一：Google是最好的图书馆”，大多数人似乎会认同这位因为在1975年撰写《战略家的思想》而知名的学者，但是当维客的技术概念悄悄露头之时，大前研一的话很有可能显得过时了。
就如同没有3D游戏，太平洋土著词汇Voodoo也不会被人熟知一样，原自夏威夷语wee kee wee kee的缩减化英语wiki，如果没有沃德·坎宁安(Ward Cunningham)1995年的突发奇想，也不会被人为的创造出来。wee kee wee kee的原意是“快点，快点”，在1995年沃德·坎宁安(Ward Cunningham)为了方便社区群落方式的内部交流，开发了一套名为波特兰模式知识库(Portland Pattern Repository)的工具，在建立这个系统的过程中，沃德·坎宁安突发奇想的创造了wiki技术。当wiki在2003年8月传入国内时，wiki被习惯性的译成了维客。
“木子美让博客概念在国内一夜走红，而维客很有可能是第二个博客”，独立网络开发者李安科喃喃道。实际上维客并不是一套复杂的系统，它与博客在思路上大有殊途同归的意味。博客完全是个人式的文字收集，博客的阅读者仍旧是被动的接收信息，如果对博客主人的某个观点不满，最多也只能在文后附上几句话抵触的评论，而在维客中，每个人既是阅读者，同时又是书写者。从技术角度上看维客不过是一套可以任意编辑的网络白纸，任何人都可以在一段别人写过的内容上编辑加工，也能够按照一定技术规则和文化脉络组合模仿。《商业2.0》将维客形容为社群协作式写作，在他们看来维客必将是群体性知识总结归纳的最优化模式。台湾地区维客组织管理员凌信路接受采访时介绍说：“在维客上任何人都可以自由编辑别人的东西，自由开放的气氛保持的很好，所有那些喜好搞恶作剧在维客上都很规矩，他们生怕任何言辞冒犯了维客群体的开放共享氛围”。所以在维客上你见不到刺刀见红的争论，也见不到任何网络世界常见的尔虞我诈。
“维客简直是天然的百科全书模式”，日本维客龄木久色在接受NHK采访时说。实际上仿照国外Wikipedia的中文维客百科刚刚开张，整个维客百科系统完全就是一套百科全书的架构，任何人都可以对自己了解和感兴趣的领域开新百科分支，并且把自己收集的资料书写上去。维客李安科说道：“我作为骨灰级玩家在中文维客百科上添加了电子游戏的部分，并且书写了不少的内容，但却阴错阳差把名称对应错了，两天后后悔不迭去修正时，却发现已经被别人修改过了。”而在维客百科上，对于“导演”一词的解释就前前后后被改了多次，最初的维客还按照《中国大百科全书》的说法：“把文学剧本搬上银幕使其成为影片的主要艺术家”，但是没过几天，导演的解释就被改成了“导演都是大流氓”。这就是维客的本色，是一个共同创作各抒己见的社区，在维客的技术架构里面并没有等级分明的权限设置，不会让你注册然后输用户名和密码，也不会记录你的IP。因为维客们都信奉没有锁的门是最不怕被撬的门，这句英国古代谚语。
正是因为维客能够坚持自由、共享、信任和免费的原始精神信条，从2001年开始，英文维客百科已经有了超过18万个词条，维客借助普通民众的力量，还在不断的扩增，信息词条越来越接近6张CD容量的微软电子百科全书了。而且维客对于新兴词语的反应速度也很快，正如杨百翰大学语言学教授赛弗·恰克在接受《商业2.0》采访时说的，“维客对于语言词汇的积累是空前的，被维客们归纳的知识在彼此间不停的共享”。除了在百科全书的成功之外，维客技术也被引入到商业领域，即将纳斯达克上市，且预估市值高达400亿美元Google内部就是用维客系统沟通，甚至摩托罗拉公司也把维客引入到公司内部的知识管理中来，《商业2.0》引述Google创始人拉里·佩奇的说法：“维客上涂涂改改的便捷非常适合现代管理制度下的职员交流，维客可以打破企业内部各层隔阂，让那些靠压制手段来管理的主管们被群体智慧淹没”。
对话专访：听Ward Cunningham细述Wiki之前世今生
记者/Bill Venners
在软件社区中，Ward Cunningham享有思想源泉的美誉。他发明了CRC Cards，这是改进对象发现的一种技术。为了促进软件模式的发现和编档，他发明了世界上第一个wiki，一种基于web的协同编写工具。最近，许多极限编程（Extreme Programming）技术背后的主要灵感也被归功于Cunningham。
在2003年9月23日于丹麦Aarhus召开的JDOO大会上，Bill Venners遇到了Ward Cunningham。在这次访谈中，Cunningham深刻剖析了使用wiki协同探索和极限编程的几个方面。
在第I部分“使用Wiki探索”中，Cunningham讨论了使用wiki协同探索以及wiki作者和读者之间的权衡。
在第II部分，Cunningham讨论了他如何把wiki设计成这样一种模型：集体代码所有权、以所有权而自豪的集体激励以及通过消除犯错的代价来解决纷争。
在第III部分中，Cunningham讨论了变更成本曲线的扁平化、预测未来的问题以及像艺术家手中的泥巴那样塑造程序。
第I部分 使用Wiki进行探索
为什么需要Wiki？
Bill Venners：您发明wiki的最初目的是什么？
Ward Cunningham：我创建wiki要完成几件事。第一个wiki的初衷是要建立一种环境，我们能够交流彼此的经验，从而发现编程的模式语言。我以前曾经使用过HyperCard组，它基本上也是为了类似的目标。我知道人们喜欢使用那种HyperCard组来阅读和创作，但它是单用户的。当开始PLoP（编程模式语言）系列讨论会的时候，我们认识到我们真正想要做的是开始编写一部新的作品，我认为我需要使用HyperCard组，并希望能找到一种应用于web的等价物。
对于wiki，我还有更多通用的目标。首先，人们常说“人人喜欢讲话”，我认为这里面有一种令人信服的人类本性。在创建wiki时，我希望激发每个人喜欢讲故事的天性。其次，也许是最重要的一点，我希望不经常创作的人们会发现创作非常轻松，这样就有机会发现创作的结构和方法。
Bill Venners：wiki如何使创作变得轻松？
Ward Cunningham：不熟悉写作的某个人可能有一个想法，这个想法值得写成一段。他们本来可以为杂志写一篇评论，但是一段文字太短了。为了给杂志撰写文章，他们不得不介绍一下背景，讲述某些重要的东西，而且要以多数人都能理解的方式讲述，然后结束文章。太复杂了，多数人都不愿意花费那么多的精力。
但是如果您正在阅读别人的作品，并想到“是的，但是还有一点”可以放在一段中这样说，“啊，不错，但实际上还有……”在wiki上有很多这种类似于“对，但是……”的对比想法。讨论组也作了同样的事情，但是在讨论组中这些对比都丢失了。
Bill Venners：为何在讨论组中丢失了？
Ward Cunningham：因为没有上下文，无法持续下去。讨论组往往反复围绕着同一个话题，但是人们忘记了以前说过什么。我认为，常见问题解答（FAQ）的发明就是针对这个问题的。很多时候，读一读FAQ要比参加讨论组更有意义。在一开始做wiki的时候，有一个系统叫FAQ-O-Matic，它和wiki的想法一样，只不过其真正的目的是制作FAQ。我看到它的时候就想“哦，英雄所见略同”。不过我接下来又想，“不，我更喜欢面向文档的形式而不是问答形式。”在我们的作品中想要创建的模式是某种类似FAQ的东西，但应该不止如此。现在，wiki上可能有10,000到15,000种模式，25,000页文档。
Bill Venners：您认为wiki适合做什么？wiki的高明之处在哪里？
Ward Cunningham：如果您试图回答一个不容易阐述的问题，事先不了解某种应该知道的自然结构，wiki会非常有用。对于像“项目进展如何”之类的问题，我们可以设计一个数据库。但是数据库中要放哪些字段还要归结到对项目进展问题什么是重要的。关于项目的哪方面重要这些资料是不可预见的。
Wiki页面的格式非常自由。在整个wiki中有一个超文本结构，但是在一个给定的页面上，在自然语言灵活性的许可范围之内，您可以讲任何想要述说的东西。因此，wiki是跟踪项目进展状态的一种良好方式。比方说，您可以把我的模式作品看成是一个长期进行的项目。我们不知道终点在那里，但是我们希望在进展中发现它。
此外，wiki也非常适合于想要把控制权交给系统用户的环境。在wiki中并没有多少何人何时可以做何事的逻辑，因为wiki并不真正理解您在做什么。它只是为您保留页面。关于什么是适当的用法什么是不好的用法，已经建立了大量的惯例，但这些都存在于用户的头脑中，而不是在应用程序的业务逻辑中。如果您有一个可靠的团体，不谋求通过计算机强制某种行为，wiki就可以很好地工作。比如，有人曾经问我wiki是否适用于协同环境。我认为某些公司对它们的雇员完全具备这种信赖，某些公司则没有。不信赖雇员的公司可以根据某些需要维护一个web站点而不是wiki。
把握大局
Bill Venners：读者如何把握wiki上的总体内容？
Ward Cunningham：首先要理解，因为我们使wiki更方便作者，实际上就增加了读者使用的难度。里边有某种组织方式，这种组织方式还可以改进，但它不是组织严密的。因此读者就会感到仿佛是在茫茫的一片信息片段中搜寻。偶然发现一段很好的信息，于是就想，“好极了，为什么没有人哪怕只是把那些好的片段作一个清单，我就不用再搜索其他的部分了。”换句话说，“为何没有人组织一下，让我迅速找到问题的答案？”早晚他们的想法会得到实现，“哎呀，行了！”他们花了一个月或者两个月查找所关心的东西，然后做一个页面，wiki组织成什么样子由他们自己承担。
我不是一个分类的痴迷者。如果感兴趣的事物不符合需求或者不是预期的，定义一个有用的分类方案非常困难。不过有些人认为每个页面都应该带有分类。他们带着一个分类方案，根据页面的名称，为wiki建立分类结构。这些注重分类的人负责维护它。如果某人创作了一个不能归类的页面，其他的人就会说，“哦，这应该归为wiki保留页面或者设计模式。”
Bill Venners：如何把一个页面归类为wiki保留页？
Ward Cunningham：只需对一个叫做WikiMaintenanceCategory的页面进行引用。单击该链接时，就会转到那一页，对这种分类进行解释以及为何有这一类。因此把页面归到某一类，习惯上是增加到该类别描述页的链接。这样标记了该页。如果要了解这一类是什么，可以沿着链接到类别描述页。如果要看看这一类中有什么页面，可以搜索引用该类别页的所有页面。
Bill Venners：我猜想搜索也许是研究新wiki的一种方式。从一定意义上讲，wiki类似于一种小型的internet。 一切都分散在各处。如何发现正在寻找的内容呢？我可以从搜索关键字开始。
Ward Cunningham：是的。任何名称以“Category”结尾的wiki页都是一个值得搜索的条目。可以通过Google搜索小说，但是如果有人不把作品标记为小说，就找不到它。分类系统是一组页面，解释分类的基本原理，可以读读这些页面。它们使用了名称空间的一小部分——所有这些词都以“Category”结束——并建立了这些页面涉及其他页面分类的实例。非常棒。还在发展中。如果我要做一个解决方案，可能会非常简单，甚至同样好。我最喜欢的一点是，有一个非常积极的社区在管理这些分类。有时他们把分类搞错了，但很快就会纠正过来。
Wiki中的时间要素
Bill Venners：您所说的有点让我想起“自由讨论”。您把一些人集合起来充实那些您还不完全清楚的事物。
Ward Cunningham：Wiki有点像“自由讨论”，尽管不是交互式的。您可以做10分钟的自由讨论，用30分钟分析自由讨论的成果，然后在45分钟之内完成某件事。Wiki的脚步要慢一些。您可以就某个观点写一个页面，或者就很多想法写一个页面。然后在一周之内回来看看页面上有什么进展。但是如果在15分钟之内回来，不会发生太多的变化。Wiki上的事情是以天或者周为周期的，因为人们往往每天或每周浏览一次。
Wiki中有一个有趣的时间特性。读新闻组或者邮件列表时，会有一种感觉，当前就是您在列表中的位置。我不希望wiki中有一个时间表。当在读wiki上的某些内容时，我不希望时间会影响您，不论它是一年前写的还是一天或者一分钟前写的。这意味着我们需要通过某种方式得到上下文。
如果您正在编写一个页面，那个页面必然和其他某个页面有关。因此所要做的就是，在一个段落中说明其他页面中哪一些是关于这个上下文的。人们逐渐熟悉这些页面的名称。他们遇到一个新的页面，阅读包含对上下文页面链接的段落。如果已经度过这些页，就继续读下去。如果不知道这些页，他们就会说，“哦，这一页没有什么意思。我还得读一读其他的页。”这样如果您了解上下文的话，就不必再去看了。但是如果不了解上下文，您可以去看一看。上下文不会变。
Bill Venners：听起来似乎您必须了解wiki站点。过一段时间后您就会熟悉它了。一开始可能会令人感到困惑，也没有多少提示，您进来发现到处都是这样的内容，但不一定是根据读者的需要组织的。
Ward Cunningham：对，wiki总是在不断地组织中。每花费一个小时组织，都要花费另外两个小时来增加新的材料。因此wiki的总是处于半组织化状态。
Wiki 和可读性
Bill Venners：我确实非常喜欢wiki的思想，但是我发现阅读许多wiki页非常困难。可读性的问题是我一直没有在Artima.com上增加wiki的主要原因。Artima.com也是一种基于web的协作文档，但是更加结构化。在wiki中没有专职编辑为读者组织材料。所有的页面都是协作性的。结构是协作性的。编辑是协作性的。从wiki的协作性中有什么足以抵消可读性的损失？
Ward Cunningham：作为wiki读者，您能够获得以前没有发言的那些人的观点。听我们发言的人对于怎样编写和发布计算机程序有直觉的想法。我们这一行在发表过程中对传统保留了某些尊重。比如，如果您想为一本科学杂志投稿，应该经过同行评审。同行评审的一部分是你应该熟悉所有其他作品。而其他作品可能纠缠进某些细枝末节。关于编程的作品有时并不符合程序员的实际感触。有了wiki，没有时间学习写作并在杂志上开辟专栏的实践程序员，就有机会讲出那些对于他们来说是重要的事情。Wiki提供了一个不同的视角。事实上，您可以分辨出一个人是在wiki上根据自己的经验创作，还是转述刚刚读到的东西。
Bill Venners：那么您怎么分辨呢？
Ward Cunningham：您可以根据他们谈论事情的方式来区分，比如“Mary Ann就是做不好这一部分。”这不符合科学传统。如果有人引述某位作者的话，“某某怎么说，你这家伙怎么听不明白”，有人在赞美他所读的书。另一方面，如果有人说，“您知道，在以前的三个项目中我们都尝试过，但一次也没成功，我们只能用别的办法摆平它。”有个家伙解决了这个问题，他正在跟我谈一些深刻的问题。如何解释要靠我自己。这只是他的经验。然后您可能还会看到其他几段文字，“是的，我也遇到过，我用这种方法搞定了。”那么现在就有两种方法了。突然之间，您开始与解决了软件问题的人交流了，而不是和谈论解决软件问题的人交流，这有很大的不同。
第II部分 代码和文本集体所有权
集体的代码和文本
Bill Venners：极限编程（XP）的集体代码所有权特点让我想到了wiki，在wiki中，每个人对所有一切负责。
Ward Cunningham：这样做完全是有意的。在设计wiki前的几个月中，我们有过一次争论。我认为Kent Beck和我站在一边。坚信主流软件工程教条的那些人站在另一边。我们说“集体代码所有权很好。”他们则说“太荒谬了。没有职责划分，而没有责任就决不会有质量。让他们避免制造缺陷，就必须把缺陷和某个人挂钩。”我说，“完全不对。”
我设计wiki的决定，很大程度上受到建立一种协同过程模型的渴望所启发，我认为在大型代码库中应该有这种协作。我希望wiki能够模拟这种情况。比方说在一堆代码中有一个问题。您知道怎么解决问题，但是解决需要涉及到大量模块。重构需要大量艰苦的工作，如果要同每个最初的作者协商就更加困难。你只是希望改正问题。
困难在于代码可能是按层次结构组织的，但是解决方案可以从多方面来考虑，而不止是某种层次结构。因此当您在某一方面发现一种贯穿整个层次结构的解决办法时，您只能随着解决方案的要求，在适当的地方加入解决方案。我们经常发现自己处于这样一种境地，人们了解这个程序，但是他们不能将这些知识应用于程序。为什么？因为知识的发展和在拥有这些知识之前做出的某些组织决策相冲突。换句话说，程序抗拒知识的积累。
Bill Venners：抗拒？
Ward Cunningham：程序对某种类型的知识有抵抗力——没有预计到的知识——因为很难在一开始就设立的结构内表达这些知识。很难把不符合这种结构的任何东西加进去。
Wiki中也有一点对预料之外思想的抗拒，但这种抗拒主要在人们的实践中。Wiki中写进去的东西越多，对自身权利的要求越严格，但是如果有人要修改而且到第25页去修改，他们就可以去25页。
比如，在wiki中，发生的某个过程是页面从讨论发展成短文。许多人愿意阅读讨论。那些每天访问wiki的人希望看看昨天又说了什么，因此需要按时间组织的页面。但是对学习而言，投稿先后顺序并不是一种很好的组织原则。因此页面总是保持某种讨论之中的感觉，直到这个讨论结束。后来，有人又回来阅读了这些讨论，把您可能称之为线性模式的页面重新组织成文档模式的页面。
如果在注解之间转来转去，而且有许多类似的彼此相邻的注解，您经常会发现可以去掉一大半篇幅。因为只要位置适当，一句话可能就说明白了。在Ward的wiki上，这个过程被称为“重构（refactoring）”，就像我们在软件中那样称呼这个过程。Ward的wiki是关于软件的，其中有许多从事软件的人，因此称为重构。在其他地方可能就会称为“编辑”了。在Ward的wiki上，重构是一个持续的过程。设想如果某些地方被证明不很合适，就要再次进行重构。一切都是重构的目标。这也是我们愿意在软件中所看到的。
软件的优势是它有明确的解释。因为软件是为机器编写的，我们可以依靠精确的解释编写测试。在重构程序时，我们可以测试没有破坏或者丢失的任何东西。但wiki是为人类编写的，没有精确的解释。我可以说，“哎呀，我可以把这个句子放在这儿，并砍掉一半，因为在这个上下文中很容易理解。”但是我可能错了。对于我容易理解，但可能对其他人很难，我也没法做测试。因此在重构过程中，我们可能会丢失wiki上的某些信息。Wiki像一个信息漏桶。它每天都在丢失信息。但是有更多的信息加进来，因此净结果是正的。即使丢失了某些东西，wiki总是比昨天有更多的内容。
高质量代码的集体激励
Bill Venners：从您的描述中我了解了集体代码所有权的好处。但代价是什么？集体代码所有权的缺陷是什么？
Ward Cunningham：我相信有一些缺陷，但是现在还没有想到。
Bill Venners：所有权的自豪感又如何？人类适应集体自豪感吗？在您自己创建什么时，总是希望把它做好。
Ward Cunningham：我认为集体所有权实际上更好一些。是的，我对自己所做的事情感到自豪。对于我而言，自豪感是一种激励。通过集体所有权，我们基本上建立了一种小型的社区，训练他们自我肯定所做的工作。但如果归我所有，人们就会说，“那是Ward的模块，我不想看Ward的模块。”如果必须调用Ward的模块，他们可能会喜欢该模块的API。我的模块缺陷率很低也许会给他们留下印象。不过他们可能会说，“他的模块很简单。他有一个容易编写的模块，这就是为何他的缺陷率这么低。”他们不会知道真正的原因。
当人们使用我提供的材料时，他们会感觉到是否容易使用。所谓使用材料，我是指拿来代码调整，以便做更多一点工作或者稍微改变其功能——这些代码应该做的任何事情。当人们使用代码时，他们会看到我努力完成的一些事情，否则的话他们永远也不会注意到。不需要迫使他们说“Ward你很了不起”，但有时候他们会说，“Ward你很了不起。”这就满足了我的自负感。所有权的自豪感？的确如此。
现在，不需要在每一行上写上我的名字。事实上，这证明如果它确实很好，可能是因为他们做得好，而不是我。我可能只是做了一个计划，然后他们完成了而且完成得很好。我可能会受到不应得到的荣誉，不过他们也可能把赞誉送给别人。一个想法来自谁，荣誉应归谁，这种观点是弹性的。但我认为人们在知道谁参与其中的时候，可以很好地解决这种弹性，承认每个人的贡献。通过集体所有权，我们建立了一种社会环境，通过源代码语句中迸发的智慧可以了解一个人。
Bill Venners：集体所有代码的这种特点为何不能出现在wiki页面上，wiki页面上的内容有时候显得有点乱？
Ward Cunningham：我肯定也会这样。
Bill Venners：您刚才谈到某一行代码是谁编写的并不总是很明显。对于wiki页面也是如此。谁写了某一行文本也并不总是很明显的。有时候一个人在wiki页面上写了一些东西，“我有这样的经验”，而作为读者我并不知道这个“我”到底是谁。集体代码所有权和集体文本所有权相比有什么不同，您刚才只谈到了代码而没有涉及文本？
Ward Cunningham：我认为不可预料的代码是很常见的。代码可能能够工作，但如何工作本质上是秘密的，不可能阅读。事实上，这也可能是一种常见情况。因此混乱可能不够确切，应该是不可读。我有与他人长期结对编程的经验，在读到他们的代码时，甚至认为是自己的代码。但在wiki上还没有出现这种情况，我读到某人的文字而认为是自己写的。这可能是因为代码具有更高的组织性，但我认为更可能是因为代码交流的范围更狭窄。代码交流的范围仅限于某种过程的计算机化，而谈话的最佳方式是相当广泛的。这样就会导致和英语相比，代码会更快地具有稳定的组织性。
解决纷争
Bill Venners：在“Extreme Programming Explained”一书中， Kent Beck写道，“集体所有权增强了在项目中对个人能力的认知。您不会永远钉住别人的蠢事不放。您在途中发现了某些东西，然后把它排除掉。”对于什么是蠢事如果不同人的看法互相矛盾时该怎么办？所谓蠢事不是一种主观的评价吗？
Ward Cunningham：啊，我决不会这样说。当我认识到不需要赢得每一次争论的时候，这是我编程生涯中的一个转折点。我正在和别人讨论代码，我说“我认为最好的做法是A”，他们则说“我认为最好用B”。我说“不，应该是A”，他们则坚持说“我们想用B”。当我能够这样回答的时候，对我而言这是一个转折点：“好吧，用B办法。如果我错了这样就不会损害我们。如果我对了，而您用B办法也不会造成多少损害，因为我们可以改正错误。让我们看看这样做是否错了。”
我们不要把自己看成非常幸运的预言者，要求自己预测未来。最好是建立一种环境，这样您就能够试一试B并看看发生什么。现在证明争吵通常是无益的。无论谁编程，都可以自由选择编程的方式，这样就足够了。当然有时候也可能会证明争论是有用的。我们正在做别的事情，看了看说，“您知道，用在那里并不合适，因为B确实不符合。”而这个问题可能是我在宣传A方法时正好考虑到的，也可能不是。它可能是开发人员在方法B的上下文中硬塞进去的。但有时候您了解这些缺陷或者难以改进的地方。于是开发人员说，“你知道，这些代码令我感觉不舒服。”我说“好吧，我可以解决这个问题”。他们问道“您行吗？”我说，“当然，我可以解决这个问题。您做了B，我就使用B。”然后我就可以开始处理它，只要可能就尽量使用B。但是因为承担了职责，我就有机会使它实现需要的功能。
Bill Venners：您是说再回到A。
Ward Cunningham：如果需要的话。
Bill Venners：也可能是到C。
Ward Cunningham：通常会变成C。对于我们双方这都是一种学习的经历。如果没有这种经历，我们就都没有学到什么。Ward赢了，其他人输了。或者相反。这和一场战争差不多。为什么不说，“好吧，让我们编码看看怎么样。如果不行的话我们再改变。”
我无法告诉你我花费了多少时间担心无关紧要的决策。如果能够做一项决策，然后看看结果如何，当然会大大减少这种担忧，但是这意味着您必须建立一种环境，当确实出问题时可以修正。如果某些事情确实出了问题，不会浪费您和您的客户过多的成本。这不是一种可笑的花费。如果您处于不能承受错误的情况下，就很难做正确的事情。因此如果尝试做正确的事情，正确的事情可以抵消犯错误所造成的代价，要远比猜测什么是正确的好。
比如，在一个项目中我们通过经常升级抵消了错误成本。我们是通过建立一个相当精细的数据库模式演化机制实现的。。我们曾经每周发布一次，每周都修改模式。我们可以为不同的客户根据不同的要求对模式作不同的修改，把这一切结合起来最终得到正确的结果。因为我们每周都在做，大约六周或八周以后，我们就确信我们可以完成它了。我们从没有担心过。多数人都说，“无论做什么，千万不要做模式演化除非你已经做了。”但在项目结束的时候，他们说，“天哪，我们真的做到了。”因此在从来没有做过之前，他们说，“只要我们去做，就让我们做完它吧。”他们做了一个巨型项目，以前从未有这样的经验。你猜怎么样？他们错了。相反，我们每周都在做。每周做一点。我们确实从中受益了。我们永远不会害怕它。它也从来没有出现问题。
因此我们不是通过说“我们要做的工作性质就是这样”，从而通过抹去问题来解决问题。要是这么简单的话才是真的奇怪了。实际上更多的是提问的方法，“您希望擅长什么？”，如果您希望擅长它，就找出一种方法来每天应用它。如果每天都要应用，那么就只能熟练掌握了。因此，选择您希望擅长什么。您应该擅长您所害怕的东西，这样您就不会再害怕它了。
第III部分 塑造程序
变更的成本
Bill Venners：在“Extreme Programming Explained”一书中，Kent Beck写道，“软件工程中一个普遍的假设是程序修改的成本随着时间呈指数级增长。”并建议说，“通过技术和编程实践的结合，有可能得到一条方向相反的曲线。”怎么能够实现变更成本曲线的扁平化呢？
Ward Cunningham：传统上来说，变更成本曲线告诉我们，早发现变更的需要与晚发现这种需要相比，进行变更所花费的代价越小。我批判了这种曲线，因为根据这种理论，我们差不多可以故意犯错，然后在实践中改正错误，这样有助于减少以后变更的成本。
我们认为，任何变更的决定因素不是何时进行变更，而是需要做多少思考。如果我们每周做一次变更，而理解我们的真正需要花费了两天，那么做这种变更就需要两天。如果我们每21周变更一次，理解我们的真正需要也花费两天时间，那么这个变更也用了两天。
在每周一次的变更中，我们可能要写20条语句。在21周变更一次时，我们可能需要写20条语句并修改4条语句。但是如果您习惯于变更，修改4条语句也花不了多少时间。只需要找到那些语句并修改它，可能只需要1分钟。
因此理解变更的需要是决定性因素。编程实现变更并不重要。只要我们理解了变更，我们就可以编程实现，或早或迟。修改代码的实际成本并不在编程中占有主导地位。主要的成本是理解所花费的时间，这就给出了一条趋向平缓的变更成本曲线。
许多人害怕变更，是因为尽管在编写的时候还理解代码，但这种理解很快就消失了。他们对你说，“我们为这些语句费尽了心血，无论如何不要改变这些语句！”他们并不想回到原来的代码，因为重新理解太费劲了。因此使变更成本曲线扁平的另一种方法，即以后变更的成本不会比现在更大，就是确定人们必须能够看到他们将要改变什么并理解它。因此，当你在编写代码时，你就会更多地为将要阅读代码的人编写，而不是为运行它的机器编写。
同样，你也不愿意编写大量的注释，告诉别人如何进行他们所需要的修改，因为您并不知道他们要进行何种修改。最好抱有这样一种观点，您不能帮助将来的程序员进行修改。您所能做到的就是使他们容易理解您努力去做的事。如果您非常小心，避免做太多的事情，这样最有助于他们理解您的努力。您试图完成的功能越多，将来的程序员要理解您的代码就越困难。
比方说，如果您明显地忽略了一种情形，以后的程序员需要解决它，他们打开代码发现您显然是忽略了这种情形。这意味着他们可以自由实现需要的任何功能。但是如果您试图应付这种情形，他们来了首先要确定哪里不工作。他们将看到您试图解决这种情况，因此他们首先要尝试理解您在做什么。一旦理解了您要做什么，他们就可以指出如何修改以实现需要的功能。他们更愿意接手的时候发现您甚至没有考虑到这一点。也许您想到了，但完全没有对此编程。
对未来的预测
Bill Venners：每个人都同意预测未来是很困难的，但预测总是这么糟吗？
Ward Cunningham：在科学中预言未来很简单。科学建立在对物理系统行为研究的基础上，被证明具有惊人的可预言性——可能天气除外。我们已经能够向太空发射火箭并使它沿轨道运行，这是预测的一个范例。但是当开始谈及对未来的期望时，我们可能有某些直觉，这些直觉也许是对的，但不会总是对的。我们必须考虑到不正确的情况。
当一个新的需求出现时，我们看了看说，“好的，这不难。这个程序就是为它而作的。”我们在程序中加入一些代码，然后就成了——我喜欢这样。我讨厌这种情况，新需求的出现不能很好地满足，仿佛程序的设计就是为了和需求作对。这种情况下，我们有大量的工作要做。但是这项工作的性质要求首先修改程序使它更容易适应新的需求，然后把新的需求包含进来就很容易了。换句话说，不是为新的需求在并不适合这种需求的结构上打补丁，而是全力以赴做艰难的任务修改结构，使它能够很容易实现这种需求。打补丁的办法意味着，后来者不但要理解并非为这种需求设计的系统，还要理解试图弥补但不改变系统的那些补丁。最好是修改系统以便很容易适应新的特性。
有人也许会说，“为什么不向前看一看，了解我们必须做到的所有工作呢？为什么不从一开始就把系统设计成使所有工作更方便呢？”如果您能够实现这样一个系统，那真是太好了。正是这样，人们一次又一次地试图设计系统使明天的工作更容易。但是当明天到来时，却发现他们并没有很好地理解明天的工作，实际上他们使明天的工作更难了。
意外的体系结构
Bill Venners：为了批驳变更成本曲线，您发现了一种方法可以在项目的整个生命期中进行变更。这就使得对将来的计划不那么重要了，因为可以在以后真正需要展开的时候进行变更。整个体系结构仅仅是在每次只关注一小步的过程中逐渐浮现出来的吗？
Ward Cunningham：我喜欢塑造程序这种说法，就象艺术家塑造一团泥巴一样。艺术家想做一个雕塑，但是在开始雕塑之前，她只是把泥巴揉来揉去。她开始逐渐塑造成形，并看到泥巴要成为什么样子。揉捏得越多，泥巴就越像她希望的样子，最终变得完全符合她的想法。
一个开发小组用了数月编写一段代码。最初，他们做了一段代码，有点僵硬。代码很短，但仍然有点僵硬。他们搅动这些代码，代码稍微变软了点。在上面提到的一个项目[第II部分]中，我们向数据库增加了模式演化功能。它软化了程序，变更容易多了。每次变更模式时，我们都作一点改进。程序员和代码——作为一个整体——都软化了。我们塑造程序并保持它的柔软性。
在项目结束时您已经完成了需要做的所有事情——有人为之付钱的所有功能——您看了看代码问道，“这一堆东西中的核心是什么呢？这是怎么完成的？我们日复一日地编写程序，它是怎么结束的呢？”通常程序的结束都是令人惊诧的。您会说，“这是一种优美的结构。”那么体系结构又从何而来呢？
在这里，体系结构意味着我们处理不同需求的系统化方式。当我们根据需要塑造程序时，体系结构使我们能够发现进展到哪里了。融入程序的是一个系统，包括我们所做的每一个小决策——正确的小决策，错误但改正了的小决策。从某种意义上讲我们得到的这个体系结构并没有经过尝试。在其他决策上下文中的所有决策凝结成了一种体系结构。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack