2005年05月20日

今天上站,随意一点donews.net的分类栏目:

滚动| IT业界| 软件| 开发| 服务器| 网吧之家| 下载| DIY| 数码| 贴图| 电信| 互联网| 游戏| 传媒| 音乐| 电影| 读书| 精神生活| 体育| 日记

发现居然可以用了,惊喜中!

这本来不应该是惊喜,这本来就是donews.net“理所当然不可不戒”应该提供的功能,想不到原来的donews.net就是没有提供这个功能。

今天的惊喜就好比久病初愈,突然发现对自己很重要的,默认可以走路的,但是一直不能走路的那一条腿,居然可以走路了一样。

以前看过一篇好文章,没有及时保存,等过了那个时间再来找,根本就找不到了,淹没在没有任何索引的茫茫的donews.net blogs中。

一个blogger发布一篇文章,如果没有及时或者没有机会在首页亮相,那么陪伴他的就将永远是无人问津。这个寂寞呀,难怪有人感慨:我写到500篇的时候,该有人出来说句话了吧?!

donews.net的分类栏目就好比图书的目录索引,非常重要。今天终于可以使用,我是不是要不得不高兴一把呢?



栏目有了,那么请问:Tag功能什么时候有呢?不会是又将是漫长的等待吧?

全文到此结束

刚写完“见过不稳定的,没见过像Donews这么不稳定的!”,正想下网,最后一把更新donews.net,却看见刘老大刘韧正在抛出诱惑呢:赶快去激活自己的@donews.com邮箱

不错不错,donews.com开始有自己的邮箱了,当然要支持一把,立即响应号召,点进去:

可是等看完全文,立即决定放弃注册:

2、本邮箱是donews和雅虎合作。后台使用雅虎的系统,稳定可靠。
3、安全无毒 – 全部邮箱提供免费防病毒(Norton)功能
 防垃圾信 – 专利反垃圾邮件技术,有效防御95%以上的垃圾邮件
 超大空间 – 1000M空间,10M附件
 空间增值 – 30兆网络相册和30兆网络公文包

原因很简单:donews跟yahoo的合作。

donews.com跟yahoo的合作能够长久吗?

一朝天子一朝政,如果不久的将来的某天,yahoo不跟donews合作了,那么这个邮箱的前途恐怕就渺茫了吧。

  • 邮箱,一个稳定、长期、可靠的邮箱,是我对邮箱的最基本的要求;
  • 邮箱,防垃圾、防病毒,是邮箱对我最大的增值诱惑;
  • 邮箱,大容量、pop3、smtp,是时下最风行邮箱(yahoo,gmail,hotmail)最不在乎的功能,对我也一样。

但是,我还是要去注册的,我去注册是为了保住我注册的Donews ID。近期没有换邮箱的打算。

只是希望在漫长的岁月中,我不要忘了这个donews.com邮箱的密码。



全文到此结束

2005年05月19日

好不容易下午有时间写了一篇Blog,立即兴冲冲的写完,急迫的发出去了,发布成功。

可是,回到首页,却总也没有在donews.net首页显示出来。以前发布blog的时候,更新到首页需要一定的刷新时间,所以我也没有怎么放在心上,就做别的工作去了。

但是,等过了半个小时,我去看,居然整个donews.net一直没有得到更新,这就奇怪了。连续刷新了好几次,都不成功,奇怪了。一直到下班都没有得到更新,奇怪死了。

等到晚上回到家一看,居然更新了,而且是批量更新,我的blog还没有来得急在donews.net首页上得到更新就被沉下去了。晕的很。

晚上我又写了一篇,居然还是无法得到即时更新。donews.net的博客系统真是让我有点失望了。

见过不稳定的,没见过像donews.net这么不稳定的,这么不完善的,一堆bugs:

1)评论显示数目跟实际评论数目不对,有一个刷新更新的时间

2)评论数量居然还包括了trackback,没有把评论和trackback分开。例如评论显示数目是5条,其中3条评论加上2条trackback,但是trackback又不在评论中显示出来,显示出来只有3条评论,数目根本就对不上评论加trackback的总数。

3)trackback太难用了,没有手工trackback。而且donews.net站内blog引用只是给出一个ping,太简单了。

4)文章中图片的上传功能太简单了,而且全部放在一个上传图片目录中,太难用了,特别不方便,而且显示特别慢。

5)blog分类和链接管理居然没有排序功能,只能按时间倒序排列。

6)文章浏览没有显示出阅读数量

7)系统不稳定,时不时的访问不了,虽然最近稳定了不少

8)系统没有帮助,找个参考都没有。如果上面的问题是我不会用donews.net系统的话,那么就要归咎于这一条了

9)还有其他问题,我一时想不起来,就此打住吧



BTW:想想王翌在“与错过说说我为什么写Blog,兼答王建硕”也说得很有道理:

如果你的Blog写了之后一直都没有人来看,肯定失落感也不小!


全文到此结束

我喜欢阅读Blog的原因至少有几项是这样的:

  • 它表达的是个性化的观点和看法,而不是统一的口径,更多的是显示多样化,而不是大集中;
  • 它也是社会化,它可以从一个Blogger的关注的话题或者Blogger链接到另外一个话题或者认识更多的Blogger,得到更多的信息和更多的观点
  • 我喜欢Blog上思想火花的碰撞以及新鲜事物和话题

就好像今天,就不知道怎么串门走到了“嘟嘟的老窝”去了,看到嘟嘟的观点:

今天为我的Rss订阅用户进行呵护调整

从今天起你通过rss reader看我的日志,如果你在摘要的最后有全文完或者以上是全文等诸如此类的提醒语句,那就表示正文内容和摘要完全一样,你就不用打开链接了。和那一点点访问量相比,为订阅我的rss的用户提供更呵护细致的服务要实惠明智的多。希望更多的人能响应这种游戏规则。

深受感动,向嘟嘟高度关注RSS读众的阅读效果的实际行动表示感谢。同时我也决定响应嘟嘟的游戏规则!

如果您在摘要的最后有“全文到此结束”的提醒语句,那就表示正文内容和摘要完全一样,可以不用打开链接去查看全文了。

只是:估计我的RSS读众就没有几个,除了我自己,莫非是在自娱自乐???

全文到此结束

2005年05月18日

        从天使之城市<-Ts先生上转载的某程序员眼中的Unicode编码,很好的文章,转载一下。

这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念,增进知识,类似于打RPG游戏的升级。整理这篇文章的动机是两个问题:

问题一:

使用Windows记事本的“另存为”,可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件,Windows是怎样识别编码方式的呢?

我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节,分别是FF、FE(Unicode),FE、FF(Unicode big endian),EF、BB、BF(UTF-8)。但这些标记是基于什么标准呢?

问题二:

最近在网上看到一个ConvertUTF.c,实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式,我原来就了解。但这个程序让我有些糊涂,想不起来UTF-16和UCS2有什么关系。

查了查相关资料,总算将这些问题弄清楚了,顺带也了解了一些Unicode的细节。写成一篇文章,送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂,但要求读者知道什么是字节,什么是十六进制。

0、big endian和little endian

big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时,究竟是将6C写在前面,还是将49写在前面?如果将6C写在前面,就是big endian。还是将49写在前面,就是little endian。

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开,由此曾发生过六次叛乱,其中一个皇帝送了命,另一个丢了王位。

我们一般将endian翻译成“字节序”,将big endian和little endian称作“大尾”和“小尾”。

1、字符编码、内码,顺带介绍汉字编码

字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码,为了处理汉字,程序员设计了用于简体中文的GB2312和用于繁体中文的big5。

GB2312(1980年)一共收录了7445个字符,包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7,低字节从A1-FE,占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号,它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030,对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。

从ASCII、GB2312、GBK到GB18030,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支持更多的字符。在这些编码中,英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼,GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。

有的中文Windows的缺省内码还是GBK,可以通过GB18030升级包升级到GB18030。不过GB18030相对GBK增加的字符,普通人是很难用到的,通常我们还是用GBK指代中文Windows内码。

这里还有一些细节:

GB2312的原文还是区位码,从区位码到内码,需要在高字节和低字节上分别加上A0。

在DBCS中,GB内码的存储格式始终是big endian,即高位在前。

GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析:在读取DBCS字符流时,只要遇到高位为1的字节,就可以将下两个字节作为一个双字节编码,而不用管低字节的高位是什么。

2、Unicode、UCS和UTF

前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容(更准确地说,是与ISO-8859-1兼容),与GB码不兼容。例如“汉”字的Unicode编码是6C49,而GB码是BABA。

Unicode也是一种字符编码方法,不过它是由国际组织设计,可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set",简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。

根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载:历史上存在两个试图独立设计Unicode的组织,即国际标准化组织(ISO)和一个软件制造商的协会(unicode.org)。ISO开发了ISO 10646项目,Unicode协会开发了Unicode项目。

在1991年前后,双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果,并为创立一个单一编码表而协同工作。从Unicode2.0开始,Unicode项目采用了与ISO 10646-1相同的字库和字码。

目前两个项目仍都存在,并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是10646-3:2003。

UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码,是由UTF(UCS Transformation Format)规范规定的,常见的UTF规范包括UTF-8、UTF-7、UTF-16。

IETF的RFC2781和RFC3629以RFC的一贯风格,清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。

3、UCS-2、UCS-4、BMP

  UCS有两种格式:UCS-2和UCS-4。顾名思义,UCS-2就是用两个字节编码,UCS-4就是用4个字节(实际上只用了31位,最高位必须为0)编码。下面让我们做一些简单的数学游戏:

  UCS-2有2^16=65536个码位,UCS-4有2^31=2147483648个码位。

  UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个plane。每个plane根据第3个字节分为256行 (rows),每行包含256个cells。当然同一行的cells只是最后一个字节不同,其余都相同。

  group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中,高两个字节为0的码位被称作BMP。

  将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。在UCS-2的两个字节前加上两个零字节,就得到了UCS-4的BMP。而目前的UCS-4规范中还没有任何字符被分配在BMP之外。

4、UTF编码

  UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下:

UCS-2编码(16进制) UTF-8 字节流(二进制)
0000 – 007F 0xxxxxxx
0080 – 07FF 110xxxxx 10xxxxxx
0800 – FFFF 1110xxxx 10xxxxxx 10xxxxxx

  例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间,所以肯定要用3字节模板了:1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是:0110 110001 001001, 用这个比特流依次代替模板中的x,得到:11100110 10110001 10001001,即E6 B1 89。

  读者可以用记事本测试一下我们的编码是否正确。

  UTF-16以16位为单元对UCS进行编码。对于小于0×10000的UCS码,UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0×10000的UCS码,定义了一个算法。不过由于实际使用的UCS2,或者UCS4的BMP必然小于0×10000,所以就目前而言,可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案,UTF-16却要用于实际的传输,所以就不得不考虑字节序的问题。

5、UTF的字节序和BOM

  UTF-8以字节为编码单元,没有字节序的问题。UTF-16以两个字节为编码单元,在解释一个UTF-16文本前,首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E,“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么这是“奎”还是“乙”?

  Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表,而是Byte Order Mark。BOM是一个有点小聪明的想法:

  在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前,先传输字符"ZERO WIDTH NO-BREAK SPACE"。

  这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

  UTF-8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF(读者可以用我们前面介绍的编码方法验证一下)。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。

  Windows就是使用BOM来标记文本文件的编码方式的。

6、进一步的参考资料

  本文主要参考的资料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

  我还找了两篇看上去不错的资料,不过因为我开始的疑问都找到了答案,所以就没有看:

"Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
"Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)

  我写过UTF-8、UCS-2、GBK相互转换的软件包,包括使用Windows API和不使用Windows API的版本。以后有时间的话,我会整理一下放到我的个人主页上(http://fmddlmyy.home4u.china.com)。

  我是想清楚所有问题后才开始写这篇文章的,原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间,竟然从下午1:30写到9:00。希望有读者能从中受益。

2005年05月17日

Brad Yu(余刚)最近给hao123.com提了几条建议,其中有一条这么说的:

2、个人化的hao123。现在的网络服务越来越“个人化”,是否考虑过个人能够编辑hao123页面,只有这样才有长久的生命力,技术组可以考虑一下,我的想法是个人申请帐号来达到拥有编辑功能,保存密码,日后登陆则显示自己编辑的主页。

我想Brad Yu的想法是不错的,发动所有参与者甚至网站的忠诚用户的热忱,把hao123.com改版成一个个性版的hao123.com。他的想法类似与把hao123.com建设成为一个wiki社区,可以让所有的参与者(尽管有授权控制)都来共同建设这个网站。

但是,这个想法是有些问题的。

首先,hao123.com的定位或者说现有的用户群完全是互联网最基础的那群用户,这群用户基本就不是很懂电脑,需要的就是一个干干净净、清清爽爽的网站导航页面来冲浪互联网(关于这种用户的数量和特点可以参考参考王翌再与所谓的IT业人士谈谈hao123)。让庞大的甚至不懂IE菜单“后退”什么含义的用户去编辑hao123.com,这个好像是免为其难吧。

其次,一旦真的实施这个方案,如果充分开放权限,如何避免过多的spam,避免垃圾信息和有害信息,这是个非常重大的问题;如果不开放权限,如何避免hao123.com的内容信息集中到少部分有话语权的编辑和用户手上,如何提供给用户更宽广的视野,这个问题也是需要考虑的。

而且,一旦真的实施成为wiki,按照现在hao123.com巨大的流量和点击率,其站长说纯html的页面都已经快承受不住了(靠更多的带宽和服务器来解决),如果换成wiki,使用动态的脚本更将是服务器的巨大负荷。虽然动态脚本可以静态话,但是这个负荷不能不考虑。

所以说hao123.com实施wiki目前火候不到,还难以实施。但是,联想到最近日益火爆的365key网摘,我们不能实现的个性化hao123,但是完全可以通过网摘服务来实现。

也就是说hao123.com继续保留现有的服务不变,同时另外建立一个网摘系统,适当引导hao123.com的高端用户,开放权限让用户使用来满足他们的个性化要求。

可以想象,如果这样,国内最火爆的网摘服务,很可能就是另外一番景象了,不再是365key的独步天下了。


所以,目前我的建议是:365key.com主动跟hao123.com进行战略合作,提前抢先培育市场!


PS : 今天看了老冒"Long tail"的思考以及苦咖啡豆所谓的长尾,我想,365key.com跟hao123.com合作占领庞大的低端市场获取丰厚的利润,正是长尾理论的最佳实践。

2005年05月16日

下一代WEB开发模式Tapestry简介

http://www.yesky.com/SoftChannel/72342371961929728/20031124/1747436.shtml

http://www.yesky.com/SoftChannel/72342371961929728/20031124/1747436_1.shtml

http://www.yesky.com/SoftChannel/72342371961929728/20031124/1747436_2.shtml

http://www.yesky.com/SoftChannel/72342371961929728/20031124/1747436_3.shtml

新从网上看到的技术AJAX,先做一个转摘,有时间好好研究一下。

http://www.adaptivepath.com/publications/essays/archives/000385.php



Ajax: A New Approach to Web Applications



by Jesse James Garrett

February 18, 2005

If anything about current interaction design can be called “glamorous,” it’s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn’t on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online.

Despite this, Web interaction designers can’t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application.

That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.

Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.

Defining Ajax

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.

Ajax Overview 1

Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).

This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.

Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?

How Ajax is Different

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

Ajax Overview 2

Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).

Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

Who’s Using Ajax

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year — Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.

At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

Moving Forward

The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. Instead, the challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities.

It’s going to be fun.



Ajax Q&A

March 13, 2005: Since we first published Jesse’s essay, we’ve received an enormous amount of correspondence from readers with questions about Ajax. In this Q&A, Jesse responds to some of the most common queries.

Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?

A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.

Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?

A. Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.

Q. Is Ajax just another name for XMLHttpRequest?

A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.

Q. Why did you feel the need to give this a name?

A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.

Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?

A. What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.

Q. Is Ajax a technology platform or is it an architectural style?

A. It’s both. Ajax is a set of technologies being used together in a particular way.

Q. What kinds of applications is Ajax best suited for?

A. We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.

Q. Does this mean Adaptive Path is anti-Flash?

A. Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).

Q. Does Ajax have significant accessibility or browser compatibility limitations? Do Ajax applications break the back button? Is Ajax compatible with REST? Are there security considerations with Ajax development? Can Ajax applications be made to work for users who have JavaScript turned off?

A. The answer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.

Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?

A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.

Q. Are Ajax applications easier to develop than traditional web applications?

A. Not necessarily. Ajax applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly, and better development tools and frameworks will be needed to help us meet that challenge.

Q. Do Ajax applications always deliver a better experience than traditional web applications?

A. Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.

To get essays like this one delivered directly to your inbox, subscribe to our email newsletter.

Jesse James Garrett is the Director of User Experience Strategy and a founder of Adaptive Path. In 2005, he’ll be bringing his full-day seminar The Elements of User Experience to Boulder, Sydney, Seattle and other cities around the globe.

Other essays by Jesse James Garrett include The Nine Pillars of Successful Web Teams and Six Design Lessons From the Apple Store.

2005年05月15日

问一个问题,有谁知道,希望告诉我一下:

国外最大的、人气最旺的BSP是哪家?

而且希望他能够不限制我的空间,可以上传很多图片和资料的,同时又没有被国内封掉的。

今天我去blogger.com申请了一个,得到的好像是blogspot.com的一个BLOG。

后台写文章和发布文章都是用blogger.com,但是浏览发布好的blogspot.com,却无法访问,后来才知道被国内给封掉了。真是faint。

那么,现在国外最大的、人气最旺、不限制空间、没有被国内封掉的的BSP是哪家呢?

希望知道的朋友能够赐教!

今天去从未谋面的鼎鼎大名的http://www.bloglines.com去看他们的网站,无意间进入bloglines.com的CEO -- Mark Fletcher 的 BLOG。有趣的是,Mark Fletcher的blog名字叫做:http://www.wingedpig.com/,翻译过来就是http://www.会飞的猪.com/,而且他自己Blog的图片居然是国内常见的那张喷着火长着翅膀的飞猪。实在可爱的很。

看着名字和图片我恍惚回到了中国,在国内叫这个响亮的名字简直就是多如牛毛,太俗了,想不到bloglines的CEO也会用这个名字。我差点以为他就是中国人了,但是看Mark Fletcher这个名字好像不是中国人,我在google里也没有搜索出证据出来证明他就是中国人,按照我们对google近似上帝般的信任,我是不是要下结论:他不是中国人?呵呵。


扯远了,回到正题。


关键是我从Mark Fletcher的网站上看到一堆风险投资的BLOG,这些Blog对我而言,没有什么用处,但是对于很多想得到风险投资的国内的创业者们,我想可能会有兴趣。呵呵。我给大家共享一下:




我随意进入一个beyongVC.com,居然正好看到一段跟中国的风险投资有关的blog,其中有一段对中国风险投资环境的看法,大家可以参考一下。

我的英文端不上台面,勉强看懂,不能给大家翻译了,大家自己看。

Venture capital in China

I recently caught up with my friend Derek Sulger, founder of Linktone (Nasdaq: LTON) and current founder and CFO of Smartpay, a Paypal-like play in China (I really like what Derek is doing with this one-no credit in China, use the mobile phones for debiting from bank accounts).  Derek and I are college friends and we certainly have come a long way from college when he finds my email on Google under a heading "Geeking out with Ed Sim" (thanks to Jeff Clavier for this one!) because his mobile device with all of his data on it is cracked on his flight from China.  That being said, we had a great chat on VC in China and opportunities he sees there.

First, from his perspective, he would rather pick one or two ventures at a time then spread out investments VC style.  If you think about it, there have only been around 7 or 8 internet-type companies that have gone public in China since the last bubble in the US (Linktone is one of those) when the Sina.coms were out in the market.  Given that, he would rather pick a couple sure bets and really work with them cradle to grave.  It is also tough to have any real governance and control of an investment by just sitting on a board in China, especially if you are monitoring a deal from thousands of miles away.  Secondly, he said it is tough to find good, experienced talent.  That is one of his gaiting factors in ramping up his ventures.  Finally, from an investment perspective, he would rather go consumer than enterprise.  His first business was a systems integration play which spawned Linktone and Smartpay.  He said it was difficult because the private companies you are selling to are really quasi-government agencies.  It is tough to get paid and very tough to protect your intellectual property.  At least on the consumer side, if you price your product or service appropriately, you can build a real PAYING user base and protect yourself from competitive threats with your base of subscribers.  Look at the history of China going from Boeing to the automakers like GM which did joint ventures with companies in China only to have their IP recreated and used against them.  I am sure GM could have protected themselves by charging less for their Buicks!

So there you have it from an experienced entrepreneur in China.  His thoughts make a ton of sense.