» Publishers, Monetize your RSS feeds with FeedShow: More infos (Show/Hide Ads)
前几天，Google Reader推出了个人RSS阅读的Trends统计。可以统计出你订阅的Channel的更新、数量等指标，也可以知道你阅读上的很多指标，你可以根据这些指标来维护订阅列表，比如已经基本不更新的完全可以踢出列表了。
一直都在关注这些RSS阅读器，自己曾经在Eclipse的RCP平台基础上做过一个,不过没有开放，也没有release，开始只有CCoffee一个用户，后来连他都舍弃了，呵呵。现在平时一直在做一个升级版本的，想加入一些辅助阅读的东西。
其实，这种类似于Trends的是我想加入的第一个feature。平时使用bloglines订阅rss，但是经过很长时间的积累之后，每天300+的阅读量，已经没有勇气去维护这个阅读列表，但是其中有很多的feeds已经不更新，或者是很少阅读，没有这个trends分析，很难去维护。说道维护，还希望有的就是批量维护，一些rss阅读器提供了批量维护，但是只不过是列成了一大列，要选对于每个feed的操作，很麻烦啊。当初想的是做一个DnD Box，可以把想一起操作的feed一个一个拖拽到一个box里面，然后一个操作就全生效了。
Read/Write的blog上说， 2006年是内容过滤的一年，当然这个趋势还没有发展到国内，所以，可能07年才是国内互联网内容过滤的一年，为什么要过滤，无非就是要解决信息过载同个人阅读能力之间的矛盾。而现在的RSS阅读器大部分还仅仅使用OPML的个人列表来解决这个问题，可是多了之后才出现了维护困难的问题，不过仅仅是阶段问题，即便可以很好的维护，但是真的把自己阅读的feeds限制在200个以内也不是什么好的解决办法。于是，就看到了国外的meme engine，一种阅读上内容过滤和聚类的方式。每天的热点会根据Topic和backlink聚类到一起，比如techmeme和tailrank。可以很大的减小阅读上的压力，但是，国内的blog内容往往缺乏互相引用和讨论的氛围，究竟是不是合适，这个也不可能知道。
不过我想会有越来越多的人关注Meme engine的发展，不过具体要多长时间，不得而知。06年Wikipedia上搜索第一名的是web2.0，但是我注意到meme也列到了 Wikipedia搜索的top10。其实，Meme engine这种方式解决的是将优秀话题和短期内热点话题从大量的信息中过滤出来，成为阅读的首要话题。在本质上，跟Digg达到的效果一样，不过 Meme engine需要技术上的手段，把这些信息过滤出来，并且依赖于blog世界中每个写blog的人的参与。但是，Digg不同，Digg仅仅需要阅读者的参与，而非写作者的参与，这更现实一些。
Digg基于一种协同的方式把内容过滤出来，wisdom of crowd是他的理论基础，然而这种digg的方式缺少个性化的内容。Read/Write说07年是个性化的一年，我也写过一点个性化内容阅读的粗浅东西。个性化阅读在国内更是为时过早，不过不妨漫无边际的想象一下。在一些RSS阅读器中其实已经有一些share阅读的东西，比如Google的东西，可以直接Tag某人，然后通过这个Tag链接，某人可以订阅好友推荐给自己的东西，类似于del.icio.us的network，你可以tag某篇文章为 for:xxx。抓虾在国内这方面走的比较向前，内容已经有了，于是开始了内容的digg，不过貌似效果不是很好，朋友之间也可以分享feed。不过我很看好抓虾，因为老板是搞挖掘的，应该会有些东西出来，呵呵。
豆瓣开始做我上，也是一种好友之间对于博客内容阅读的分享。前几天，我在豆瓣的豆瓣小组上提问，为什么豆瓣要做我上，不过没有引发什么讨论。阿北说不会把“我上”做成RSS阅读器，那么为什么要做我上呢。不要忘了，豆瓣是一个基于内容过滤的推荐系统，我不知道backbone的算法是什么，不过应该是类似于协同过滤的内容过滤算法。现在豆瓣把blog也当作一种资源，在网友之间进行共享和推荐，推荐适合你个人阅读的blog。但是在blog这个层面做推荐，个人觉得是比较困难的，这个范畴太大了，而且每个人写的文章不一定就始终保持那一个主题。文章应该是更准确的推荐资源。所以，个人觉得内容阅读的推荐系统或者说协同过滤应该建立在文章的基础上，而不是blog的基础上。可是真的很难。
协同过滤需要大家一起来阅读并且推荐或者进行某些行为的分析。也就是，协同过滤的backbone需要明确的输入输出。对于 blog文章来说，大家类似的OPML可以作为相似范围的划定，文章的Tag也可以作为相似范围的划定，明确的输入可能包括digg、comment、阅读、甚至点击流模型，可是这些就已经很难很难了。就类似于Amazon，仅仅有书的资源不能形成协同过滤，仅仅有买书的行为也不能形成协同过滤，只有横向连接的买书的行为分析才能形成协同过滤。豆瓣同理。可是在内容阅读上想搞这个，行为更加复杂，自身资源也更加复杂，而且需要大量的语言和语义方面的分析。
内容阅读是一个很有意思的东西，发展到目前这个阶段其实也不是很容易，毕竟到了现在人们对于内容阅读的要求还不是非常强烈。强烈之后才需要非常好的过滤器帮助个人阅读，现阶段，这更像是一种奢侈品，普通大众还不需要的奢侈品。内容的个性化阅读和推荐阅读更是金字塔顶了。
呵呵，都是我一些粗浅的想法，大侠不要笑话，呵呵。
© Jia Mi for Xerdoc Together, 2007. | Permalink | 67 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Tech, Xerdoc.
微软著名的C++大师Herb Sutter在2005年初的时候曾经写过一篇重量级的文章：”The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software“，预言OO之后软件开发将要面临的又一次重大变革-并行计算。
摩尔定律统制下的软件开发时代有一个非常有意思的现象：”Andy giveth, and Bill taketh away.”。不管CPU的主频有多快，我们始终有办法来利用它，而我们也陶醉在机器升级带来的程序性能提高中。
我记着我大二的时候曾经做过一个五子棋的程序，当时的算法就是预先设计一些棋型（有优先级），然后扫描棋盘，对形势进行分析，看看当前走哪部对自己最重要。当然下棋还要堵别人，这就需要互换双方的棋型再计算。如果只算一步，很可能被狡猾的对手欺骗，所以为了多想几步，还需要递归和回朔。在当时的机器上，算3步就基本上需要3秒左右的时间了。后来大学毕业收拾东西的时候找到这个程序，试了一下，发现算10步需要的时间也基本上感觉不出来了。
不知道你是否有同样的经历，我们不知不觉的一直在享受着这样的免费午餐。可是，随着摩尔定律的提前终结，免费的午餐终究要还回去。虽然硬件设计师还在努力：Hyper Threading CPU（多出一套寄存器，相当于一个逻辑CPU）使得Pipeline尽可能满负荷，使多个Thread的操作有可能并行，使得多线程程序的性能有5%-15%的提升；增加Cache容量也使得包括Single-Thread和Multi-Thread程序都能受益。也许这些还能帮助你一段时间，但问题是，我们必须做出改变，面对这个即将到来的变革，你准备好了么？
Concurrency Programming != Multi-Thread Programming。很多人都会说MultiThreading谁不会，问题是，你是为什么使用/如何使用多线程的？我从前做过一个类似AcdSee一样的图像查看/处理程序，我通常用它来处理我的数码照片。我在里面用了大量的多线程，不过主要目的是在图像处理的时候不要Block住UI，所以将CPU Intensive的计算部分用后台线程进行处理。而并没有把对图像矩阵的运算并行分开。
我觉得Concurrency Programming真正的挑战在于Programming Model的改变，在程序员的脑子里面要对自己的程序怎样并行化有很清楚的认识，更重要的是，如何去实现（包括架构、容错、实时监控等等）这种并行化，如何去调试，如何去测试。
在Google，每天有海量的数据需要在有限的时间内进行处理（其实每个互联网公司都会碰到这样的问题），每个程序员都需要进行分布式的程序开发，这其中包括如何分布、调度、监控以及容错等等。Google的MapReduce正是把分布式的业务逻辑从这些复杂的细节中抽象出来，使得没有或者很少并行开发经验的程序员也能进行并行应用程序的开发。
MapReduce中最重要的两个词就是Map（映射）和Reduce（规约）。初看Map/Reduce这两个词，熟悉Function Language的人一定感觉很熟悉。FP把这样的函数称为”higher order function”（”High order function”被成为Function Programming的利器之一哦），也就是说，这些函数是编写来被与其它函数相结合（或者说被其它函数调用的）。如果说硬要比的化，可以把它想象成C里面的CallBack函数，或者STL里面的Functor。比如你要对一个STL的容器进行查找，需要制定每两个元素相比较的Functor（Comparator），这个Comparator在遍历容器的时候就会被调用。
拿前面说过图像处理程序来举例，其实大多数的图像处理操作都是对图像矩阵进行某种运算。这里的运算通常有两种，一种是映射，一种是规约。拿两种效果来说，”老照片”效果通常是强化照片的G/B值，然后对每个象素加一些随机的偏移，这些操作在二维矩阵上的每一个元素都是独立的，是Map操作。而”雕刻”效果需要提取图像边缘，就需要元素之间的运算了，是一种Reduce操作。再举个简单的例子，一个一维矩阵（数组）[0,1,2,3,4]可以映射为[0,2,3,6,8]（乘2），也可以映射为[1,2,3,4,5]（加1）。它可以规约为0（元素求积）也可以规约为10（元素求和）。
面对复杂问题，古人教导我们要“分而治之”，英文中对应的词是”Divide and Conquer“。Map/Reduce其实就是Divide/Conquer的过程，通过把问题Divide，使这些Divide后的Map运算高度并行，再将Map后的结果Reduce（根据某一个Key），得到最终的结果。
Googler发现这是问题的核心，其它都是共性问题。因此，他们把MapReduce抽象分离出来。这样，Google的程序员可以只关心应用逻辑，关心根据哪些Key把问题进行分解，哪些操作是Map操作，哪些操作是Reduce操作。其它并行计算中的复杂问题诸如分布、工作调度、容错、机器间通信都交给Map/Reduce Framework去做，很大程度上简化了整个编程模型。
MapReduce的另一个特点是，Map和Reduce的输入和输出都是中间临时文件（MapReduce利用Google文件系统来管理和访问这些文件），而不是不同进程间或者不同机器间的其它通信方式。我觉得，这是Google一贯的风格，化繁为简，返璞归真。
接下来就放下其它，研究一下Map/Reduce操作。（其它比如容错、备份任务也有很经典的经验和实现，论文里面都有详述）
Map的定义：
Map, written by the user, takes an input pair and produces a set of intermediate key/value pairs. The MapReduce library groups together all intermediate values associated with the same intermediate key I and passes them to the Reduce function.
Reduce的定义：
The Reduce function, also written by the user, accepts an intermediate key I and a set of values for that key. It merges together these values to form a possibly smaller set of values. Typically just zero or one output value is produced per Reduce invocation. The intermediate values are supplied to the user’s reduce function via an iterator. This allows us to handle lists of values that are too large to fit in memory.
MapReduce论文中给出了这样一个例子：在一个文档集合中统计每个单词出现的次数。
Map操作的输入是每一篇文档，将输入文档中每一个单词的出现输出到中间文件中去。
map(String key, String value):
// key: document name
// value: document contents
for each word w in value:
EmitIntermediate(w, “1″);
比如我们有两篇文档，内容分别是
A － “I love programming”
B － “I am a blogger, you are also a blogger”。
B文档经过Map运算后输出的中间文件将会是：
I,1 am,1 a,1 blogger,1 you,1 are,1 a,1 blogger,1
Reduce操作的输入是单词和出现次数的序列。用上面的例子来说，就是 (”I”, [1, 1]), (”love”, [1]), (”programming”, [1]), (”am”, [1]), (”a”, [1,1]) 等。然后根据每个单词，算出总的出现次数。
reduce(String key, Iterator values):
// key: a word
// values: a list of counts
int result = 0;
for each v in values:
result += ParseInt(v);
Emit(AsString(result));
最后输出的最终结果就会是：(”I”, 2″), (”a”, 2″)……
实际的执行顺序是：
- MapReduce Library将Input分成M份。这里的Input Splitter也可以是多台机器并行Split。
- Master将M份Job分给Idle状态的M个worker来处理；
- 对于输入中的每一个<key, value> pair 进行Map操作，将中间结果Buffer在Memory里；
- 定期的（或者根据内存状态），将Buffer中的中间信息Dump到本地磁盘上，并且把文件信息传回给Master（Master需要把这些信息发送给Reduce worker）。这里最重要的一点是，在写磁盘的时候，需要将中间文件做Partition（比如R个）。拿上面的例子来举例，如果把所有的信息存到一个文件，Reduce worker又会变成瓶颈。我们只需要保证相同Key能出现在同一个Partition里面就可以把这个问题分解。
- R个Reduce worker开始工作，从不同的Map worker的Partition那里拿到数据（read the buffered data from the local disks of the map workers），用key进行排序（如果内存中放不下需要用到外部排序 - external sort）。很显然，排序（或者说Group）是Reduce函数之前必须做的一步。 这里面很关键的是，每个Reduce worker会去从很多Map worker那里拿到X(0<X<R) Partition的中间结果，这样，所有属于这个Key的信息已经都在这个worker上了。
- Reduce worker遍历中间数据，对每一个唯一Key，执行Reduce函数（参数是这个key以及相对应的一系列Value）。
- 执行完毕后，唤醒用户程序，返回结果（最后应该有R份Output，每个Reduce Worker一个）。
可见，这里的分（Divide）体现在两步，分别是将输入分成M份，以及将Map的中间结果分成R份。将输入分开通常很简单，Map的中间结果通常用”hash(key) mod R”这个结果作为标准，保证相同的Key出现在同一个Partition里面。当然，使用者也可以指定自己的Partition Function，比如，对于Url Key，如果希望同一个Host的URL出现在同一个Partition，可以用”hash(Hostname(urlkey)) mod R”作为Partition Function。
对于上面的例子来说，每个文档中都可能会出现成千上万的 (”the”, 1)这样的中间结果，琐碎的中间文件必然导致传输上的损失。因此，MapReduce还支持用户提供Combiner Function。这个函数通常与Reduce Function有相同的实现，不同点在于Reduce函数的输出是最终结果，而Combiner函数的输出是Reduce函数的某一个输入的中间文件。
Tom White给出了Nutch[2]中另一个很直观的例子，分布式Grep。我一直觉得，Pipe中的很多操作，比如More、Grep、Cat都类似于一种Map操作，而Sort、Uniq、wc等都相当于某种Reduce操作。
加上前两天Google刚刚发布的BigTable论文，现在Google有了自己的集群 - Googel Cluster，分布式文件系统 - GFS，分布式计算环境 - MapReduce，分布式结构化存储 - BigTable，再加上Lock Service。我真的能感觉的到Google著名的免费晚餐之外的对于程序员的另一种免费的晚餐，那个由大量的commodity PC组成的large clusters。我觉得这些才真正是Google的核心价值所在。
呵呵，就像微软老兵Joel Spolsky（你应该看过他的”Joel on Software”吧？）曾经说过，对于微软来说最可怕的是[1]，微软还在苦苦追赶Google来完善Search功能的时候，Google已经在部署下一代的超级计算机了。
The very fact that Google invented MapReduce, and Microsoft didn’t, says something about why Microsoft is still playing catch up trying to get basic search features to work, while Google has moved on to the next problem: building Skynet^H^H^H^H^H^H the world’s largest massively parallel supercomputer. I don’t think Microsoft completely understands just how far behind they are on that wave.
注1：其实，微软也有自己的方案 - DryAd。问题是，大公司里，要想重新部署这样一个底层的InfraStructure，无论是技术的原因，还是政治的原因，将是如何的难。
注2：Lucene之父Doug Cutting的又一力作，Project Hadoop - 由Hadoop分布式文件系统和一个Map/Reduce的实现组成，Lucene/Nutch的成产线也够齐全的了。
© Meng Yan for Xerdoc Together, 2006. | Permalink | 40 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Tech.
最近很喜欢上vox，其实也才开始几天而已，呵呵，他类似于LIVE space或者现在越来越多的BSP，试图把所有的资源添加到一个封闭系统中，个人很容易控制，而且又有很强的好友关系，记得04年的时候曾经看过一个叫做multiply的网站，也是试图作这样的事情，但是后来也没有太大发展，不知道现在如何了。
很喜欢vox里面的VoxWatch的应用，实际是一个vox reader，对于每个人内容是不同的，而展现出来的是很多信息的聚合，包括你好友的信息、好友最近添加的资源、全局很favorite的post、你的comments，还有你热衷的tag，我觉得很方便，而且很好看，即便没有更新我也愿意打开VoxWatch来看看那个页面，呵呵。
觉得很大的问题就是对于新产生的内容不够highlight，或者说旧的东西还占着页面上主要的位置，其他的都感觉很好，呵呵。
其实个性化内容的订阅是一个很重要的趋势，而个性化内容的阅读器可能就是一个很重要的入口，就像以前一篇Personalize content里面总结过的，但是我没有更多的去使用Google的ig，或者live.com，因为很多信息我觉得没有意思，大致上都是些订阅rss的东西，我现在一上网打开的肯定是rss阅读器，那里的信息更多，基本上看完了就能知道这一段时间自己关心的方面究竟发生了什么事情。所以，我现在更看好类似于Spotback这样的个性化内容阅读应用。
我跟踪我关注的内容，自定义展现的方式，自定义应该出现的内容。但是，老实说我从来没有在spotback上找到过我特别关注的东西，因为他的内容是一个全局的内容，太多了，有太多跟我的个性化要求不靠普的，而且很让我没有阅读的欲望，可能是英文太多了，好像是当初逼着自己看21st Century英文报纸一样，呵呵。其实就算是RSS阅读器也不合适，我现在每天出现200篇文章，我能仔细阅读的也就20篇，然后匆匆扫过内容的100篇，其他基本就是匆匆扫过标题。如Keso所言，我们需要一个能够收缩内容又能够帮助你扩展内容的阅读器，可是developer说，真的很难，呵呵。
对于Vox来说，这样个性化内容的阅读可能就好多了，因为他是一个封闭系统。封闭系统一个好处就是你的个性化其实是用很多强的耦合连接在一起来体现的，比如你的好友、比如你tag关注的内容，如果这个内容封闭的系统很大，里面呈现出若干cluster，你又可以通过关注cluster来达到个性化内容的目的……等等。其实，每天上博客来满足自己阅读需要的也就是这些了，看看有没有人回复，看看你好友更新了没有，看看最近有谁踩过你，看看你关注的tag内容有没有新的变化……内容聚合是很久就开始作的东西了，但是聚合已经无法满足人们的阅读需求，新的发展就是如何过滤了，呵呵。
© Jia Mi for Xerdoc Together, 2006. | Permalink | 19 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Other.
在Google的2006第三季度的Earning Call（不知道这种conference应该叫做什么，是效益报告吗，不懂）中，CEO Eric提到了在Google未来的任务和使命中个性化内容将占据的重要性。
to receive … needs to be accessible when and where they want it for
them in a very personalized way.
我们相信人们的信息和他们愿意获取的信息……需要在任何他们需要的时间和地点能够被获得，而且是通过一个非常个性化的方式获得。
The interesting thing is that
this approach to having your information personalized is a benefit not
only for the user who can continue to refine and target information …
but also for businesses who want to know they are spending their money
in an effective and targeted way.
有趣的事情是，个性化组织信息不仅仅为那些想要精炼和寻找信息的用户带来好处，而且同样为那些企业带来好处，他们更能了解是否有效的、有的放矢的花钱（这句有点胖译了，呵呵）
As we continue to innovate and
bring out … new products, we’ll also continue to … improve the
experiences, bringing the most personalized and targeted information to
people, which is ultimately our mission.
正当我们持续创新并带来新的产品，我们也会继续提升用户的体验，给人们带来最重要的个性化和更有针对性的信息，这是我们最终的使命。
[We] provide access to
the world’s information … [and] organize it in a very personalized
and targeted way. That benefit drives the entire cycle of Google, and
it’s fundamental.
（我们）提供了全世界信息的访问途径，并且使用一个非常个性化和针对性的方法来组织这些信息。这种利益驱动着Google的运作和成长，是基础性的工作。
正好前几天，Read/Write Web也是谈到了个性化内容的一个市场overview。
sites - the other is Power of Masses, which we will cover in a future post. The leading
examples of these approaches are reddit for Personalized
Content and digg for Power of Masses.
个性化内容是下一代新闻网站最流行的趋势之一，另外一个就是Power of Masses。目前处于领先地位的个性化内容例子就是reddit，而Power of Masses的代表作就是digg。
the Personalized Content approach uses a very
similar technique to spam detection software. The idea is that everyone has their own
pattern of reading. To recognize your pattern, Personalized Content services omit
stopwords and extract keywords from the news you read - then use Bayesian Statistical
analysis to predict what kind of news you will like or dislike in future.
个性化内容的方法使用的技术同spam检测的技术是非常相似的。想法就是每个人都具有他独特的阅读模式。为了识别这种阅读模式，个性化内容服务将从你阅读的新闻中忽略stopwords、提取关键词，然后使用贝业斯统计分析来预测哪些新闻是你喜欢的还是不喜欢的。（也很象用户推荐系统，呵呵）
Our guess is that personalized content will become a more popular paradigm in about 1
to 2 years, provided of course that the technical challenges can be overcome. Which is by
no means certain, since a lot of smart developers
think that personalized content is a huge challenge.
我们（Read/Write Web的两个作者）的猜测是个性化内容将在未来1到2年中成为很流行的范例，当然各种技术挑战将被征服。但是千万别肯定，因为很多聪明的developer认为个性化内容将是一个巨大的挑战。
个性化内容在未来的一两年里面将成为个人上网的重要入口，个人博客是不是会朝着这个方向发展呢？不知道，呵呵。
从RSS的角度来说，下一个重要的进展将会是Personalization ＋ Clustering。用Read/Write Web上曾经说过的话是，如果2005年是RSS聚合（aggregate）的一年，2006年应该是关于如何过滤的一年，但是developer说这真的很难。真是能逗阿，眼瞅着就两月就过完2006了……
不过确实很难，尤其是我这种数学基础薄弱的，上周我基本上是在内积空间里面迷失了，虽然将将理解了QR分解，可是实在搞不定eigenvalues和eigenvectors了，就更别提eigen分解了。放弃，交给paladin去做，自己偷摸重新看书去，不丢人了，呵呵。
© Jia Mi for Xerdoc Together, 2006. | Permalink | 2 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Other.
Steve Jobs是谁？应该很多人知道吧，呵呵，Apple的创始人，Pixar创始人，Apple现任CEO，不对，要叫iCEO。
看了一晚上youtube上关于Steve Jobs的视频，当然其中很多是几年来Macworld上的keynote speech，很棒。有一个youtuber可能是Jobs的big fan，做得节目基本都是同一个主标题，—— all about Steve，不仅仅包括每次非常有意思的演讲，甚至包括Steve语言特点的专辑，好像Steve在演讲和demo的时候特别喜欢说cool、Boom、Oops等等，那个哥们基本上把这些都剪辑出来形成了专辑，呵呵。还有一个比较有意思的，Steve创办Apple之后，因为同董事局之间的分歧，居然被fire掉，于是Steve创办了Pixar获得成功，所以，在几乎所有的Keynote中，Steve每次展示产品，基本上都要扯上Pixar公司的作品，比如Toy Story、Finding Nemo、Incrediable等等，呵呵，那个哥们也细心的总结了一个专题节目，很逗，呵呵。
有的朋友应该知道Steve的一生不是很顺利，而很有名的就是Steve在Stanford毕业典礼上的一次演讲，讲述他自己这一生的三个故事，很有意义的一个演讲，Youtube上也有，很容易search到。呵呵。有心的可以去找找看。更有意思的是Apple和Microsoft之间的关系，呵呵。Apple在97年差点破产的时候，MS投资15亿美元进入Apple，至今仍然是Apple的大股东，而代价是授权MS发售Apple Mac上office，以及从97年开始，IE作为Mac的默认浏览器，直到03年Safari成功开发出来。推荐大家去找找97年的macworld，youtube上有完整的版本。那年Apple应该是处于一个转折点，而Steve也从被fire之后由重新回到了Apple，而也是那次macworld会议上，宣布了同微软之间的合作。
最后一个很有意思的事情，我在一个视频里面，——当然是关于Steve的视频里面，发现了一个人，很面熟。
大家看那个穿深色西装的是谁，我觉得是Google的Serge，呵呵。
这里是视频的地址，有兴趣找一下，呵呵
http://www.youtube.com/watch?v=KHUH9QOCzDU
© Jia Mi for Xerdoc Together, 2006. | Permalink | One comment
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Other.
前阵子，参加了MS中国研究院一个朋友对于RSS用户习惯的调查活动，我们差不多做了将近两个小时的Interview和闲聊，呵呵。
现在帮他做个广告，更多的人可以通过匿名的方式参与到这次调查活动中，只需要您花费10分钟不到的时间来填写一份在线的问卷就可以了，呵呵。
先代他感谢大家了，呵呵，让我们一起推动RSS的发展！！
链接：http://research.microsoft.com/acid/rss/chinese.aspx
Herock那里偷来的图片，呵呵，Herock参与调查的一篇日志在这里。
© Jia Mi for Xerdoc Together, 2006. | Permalink | 3 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Other.
前一段，Blogsphere里面关于WebOS的大讨论甚是激烈，如果说Web2.0的时代，整个Web将会是一个大大的WebOS的话，将各个应用和服务联系在一起的就是两个东西：
- RSS
- Web Service
以前RSS说的太多了，今天就来说说Web Service。Mac OS最新的Tiger里面的Dashboard，里面的每个小Widget都是由简单的HTML、CSS以及Web Service组成的，你可以用这些Widget来查询股票，天气，以及其它很多事情。这些Widget的核心组件，就是调用外部的Web Service。我以前曾经说过的Google IG、Live.com中的Gadget，也都是这个道理。
说到Web Service，就不能不说到RPC（远程系统调用）。所谓的远程，包括进程外，甚至本机外，经典的RPC协议包括DCOM、CORBA以及ICE等等。我觉得，对于RPC来说，最重要的就是两点：
- 将过程调用的参数和返回值序列化（Serizialize）成一系列的数据 - marshalling，中文翻译成“列集”这个怪怪的名字；
- 用某种方式来传递这种数据。对于进程外RPC来说，可以采用共享内存、管道等等。而不同机器之间，则多是用专署协议了，比如DCOM和CORBA，现在有更轻量级的ICE。
Web Service解决以上两个问题的办法是：
- 采用XML来进行数据的Marshalling；
- 采用HTTP来进行数据的传递（SOAP的新标准中也支持了其它协议，比如SMTP）；
记着2000年我刚刚接触Web Service的时候，对采用HTTP来进行数据传输这点很是不以为然，觉得穿透防火墙这些Feature绝对是宣传上的噱头。那时的自己还醉心于对桌面平台的COM、DCOM以及CORBA的研究。现在我慢慢认识到，采用XML（明文、可读）、HTTP（最常用的网络协议），绝对是Web Service得以成功的两个重要的因素。
现在比较流行流行的Web Service主要有三种，分别来说说：
1）SOAP
SOAP，全名是Simple Object Access Protocol，是Microsoft提交给W3C的Web Service协议。我觉得SOAP的两个最大的好处是：
- 协议的可扩展性（Extension Mechanism）
- 良好的工具支持
SOAP的消息称为一个SOAP Envelope，包括SOAP Header和SOAP BODY。其中，SOAP Header可以方便的插入各种其它消息来扩充Web Service的功能，比如Security（采用证书访问Web Service），SOAP BODY则是具体的消息正文，也就是Marshall后的信息。
SOAP调用的时候，也就是向一个URL（比如http://ws.invesbot.com/stockquotes.asmx?WSDL）发送HTTP Post报文，调用方法的名字在HTTP Request Header SOAP-Action中给出，接下来就是SOAP Envelope了。
服务端接到请求，执行计算，将返回结果Marshall成XML，用HTTP返回给客户端。
SOAP的工具支持非常好，比如在.NET里，可以用WSDL.exe非常方便的为一个Web Service生成本地Proxy（Proxy模式），这样，你的程序就像调用本地API一样了，而由Framework为你完成Marshall和传送的工作。
2）XMLRPC
XMLRPC ，我记着看过一段Don Box的采访，他说当时Microsoft费了7年的时间（大概，记不清楚了）才成功的把SOAP提交给W3C，而Dave Winer（眼熟吧，RSS’s Father）借鉴SOAP实现了一个更轻量级的协议，那就是XMLRPC。以前曾经大概看过XMLRPC，XMLRPC就是SOAP的简化和改进，比如说：
- Marshall类型的支持有限
- 取消HTTP Header中的SOAP Action，而将Method Name也放到XMLRPC的Body中
- 传送的XML信息中没有Header，只有Body。
XMLRPC相比于SOAP最大的优势就是它的简单，弱点就是扩展性弱，另外，工具支持也不如SOAP那般正规，感觉起来，一个像正规军，一个像游击队。不过，游击队才有作战灵活的特点 
。
XMLRPC在社区中非常流行，我这篇Blog是在Writely写的，通过WordPress的XMLRPC接口发布到我的Blog上。
3）REST
REST - Representational State Transfer, 是Roy Fielding的博士论文中提出的概念，其实，与其说REST是一种Web Service协议，不如说REST是一种Web based软件架构，一种基于Resource State的服务访问架构。
通俗的将，可以用你访问我的Blog的过程来描述REST的工作流程。当你访问我的Blog首页，其实就是对我的Blog的一个资源访问，那么Web Server会将这个资源的Representation返回给你，也就是我的Blog的首页的HTML。当你点击了这个HTML中的一个link，比如某篇Blog，你实际上就又对另一个资源发生了请求，Web Server会将新的资源Representation以HTML的形式发送给你。
我曾经看过一个人对REST和SOAP的解释，我觉得很对，SOAP是面向活动，而REST是面向资源的。
Build一个Web Service，in SOAP way还是in REST way还是有很大的不同的。
比如说，要实现一个世界杯赛程、赛果、球员评分查询的这样一个简单的Web Service，如果用SOAP的话，我们可以生成一个WSDL：
它包含很多方法，比如GetMatchResult, GetPlayerScore, GetFixture，客户端通过调用这些Web Method来获得相应的数据。
如果用REST的方法来构架，就得先分析系统中都有那些资源，每一个资源有一个URL，比如：
http://www.mengyan.org/worldcup2006/fixture/?team=Brazil
每种资源都是一个URL，然后利用URL Path或者Query来实现参数的传递，Response则是这个资源的一个表示形式。
当然，这些只是逻辑上的URL，具体的实现是采用URL Rewrite还是其它就可以你的具体设计了。
万事没有绝对，你也可以用其它方法设计REST Web Service。比如Flickr，它的Rest Service都是如下样子：
http://www.flickr.com/services/rest/?method=flickr.test.echo&name=value
也就是说，整个Service是一个资源，method变成了参数，用Method来标明不同的方法调用。我觉得，Flickr的REST Service其实还是采用传统的SOAP思想考虑的，只不过用了REST来实现。不能称作Thinking in REST way 
。
Ok，就说到这里吧。最后别忘了，和本机的Function Call相比，Web Service还是有很多需要注意的地方，最重要的两点就是Performance和Security。有很多需要注意的地方，这些说起来就太多了，而我也还有很多需要学习的地方，就简单举两个例子
：
- 减少方法调用的次数
- Message-Based Programming
- 利用Cache
我一直在想，如果有一天，我在Debug的时候，Stack Trace是一层层、一个个的Web Service，是不是很有意思？
© Meng Yan for Xerdoc Together, 2006. | Permalink | 6 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Tech.
© Jia Mi for Xerdoc Together, 2006. | Permalink | 13 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Tech.
还是在上周末的时候，看到了Microsoft RSS Team的SLE(Simple List Extensions)扩展。三个单词中，最重要的是List，SLE主要是用来解决Feed订阅阅读模式的某种特定需求而产生的：
- Treat Feed as List
- Define customized sorting functions
- Define customized filting functions
从订阅者的角度来说，订阅了这种Feed，本地的Feed列表将完全和Feed服务器提供的保持同步。这种同步包括几个方面：
- Feed Item的次序与服务器上完全相同，如果有更新，则Feed Reader也会更新顺序
- Feed Reader不会缓存过期的Feed Item，如果某一个Item从Feed中删除，本地Feed Reader也会将它从本地（或者在线Feed Reader Storage）删除。
简单的说，你通过Feed Reader看到的Feed应该与Feed Publisher发布的完全一致。
这种特定应用的需求会有很多，比如典型的几种应用：
- Top 10 Best Seller - 比如Top 10 畅销书籍，Top 10 Music等等，对这种Feed的关注通常是更加关注于当前那10个；
- Wish List - 如果我已经得到了某个东西，就会把它从SLE中拿去，这样，订阅了我的Wish List的人也就不会再看到这个，不会送重复的东西了:)；
- Open Positions - 当前职位列表，过期的职位通常意义不大。
可以看到，这些应用都有一些共同的特点，就是Feed本身更倾向于一种通知（Notification），过期的Item意义不大，而且，通常，这个List本身的次序是很重要的。
Specification很简单，通过以下这个声明来确定某个Feed是否是SLE（支持RSS2.0 & Atom），下面是一个RSS 2.0中的例子：
<rss version="2.0" xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005"> <channel> <cf:treatAs>list</cf:treatAs> <title> Top 10 Popular Post </title> .......... .......... </channel> </rss>
Sorting和Grouping(Filtering)的规则举例：
<cf:listinfo> <cf:sort ns="http://www.xerdoc.com/rss/pl/" element="date" label="Publish Date" data-type="date"/> <cf:sort ns="http://www.xerdoc.com/rss/pl/" element="rank" label="Popular Rank" data-type="number"/> <cf:sort ns="http://www.xerdoc.com/rss/pl/" element="comments" label="Comments" data-type="number"/> <cf:sort ns="http://www.xerdoc.com/rss/pl/" element="pingbacks" label="Pingbacks" data-type="number"/> <cf:sort ns="http://www.xerdoc.com/rss/pl/" element="trackbacks" label="Trackbacks" data-type="number"/> <cf:sort ns="http://www.xerdoc.com/rss/pl/" element="pageviews" label="Page Views" data-type="number"/> <cf:group ns="http://www.xerdoc.com/rss/pl/" element="author" label="Author"/> </cf:listinfo>
当然，SLE不止是一个针对于Feed Publisher的标准，还需要Feed Reader的支持。与一般的Feed不同，Feed Reader在处理SLE的时候会有一些特殊处理，现有的Feed Reader还基本上不支持SLE，除了IE7 Beta2。
为了试验，我做了一个简单的WordPress Most Popular Post的插件。基本的打分是采用Popular Context插件，根据留言数量，Pingback、Trackback数量，浏览数量等因素来确定一篇文章的受欢迎程度，最后，提供一个WordPress的Top 10 Popular Post的SLE，可以用IE7 Beta2订阅来看看效果。
右面可以根据Comments，Pingback，Pageview来排序，也可以Filter来选择某个作者的Post。
订阅：
Most Popular Post @ Xerdoc’s Weblog
Most Popular Post @ Meng Yan’s Weblog
相关阅读：
Simple List Extensions Specification
Simple List Extensions in action
© Meng Yan for Xerdoc Together, 2006. | Permalink | 5 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Tech.
其实，晚上是想跟CCoffee和Elan Meng讨论一下如何使用CSS来指定Theme的机制，而正巧前几天发现GTalk可以使用CSS来设定Theme，所以就谈起来这样的Theme系统如何实现，结果发现GTalk聊天界面是基于IE内核完成的。
可以看看个人的目录，比如，C:\Documents and Settings\xxxx\Local Settings\Application Data\Google\Google Talk\themes\system\chat\BubblePicture\Contents\Resources\Outgoing，你可以把那里的content.html中添加一条script：
<a href='javascript:alert( navigator.appName);>Test</a>
然后，打开聊天界面，在输出的方式中，就会看到一个Test的超链接。
点击那个超链接，会有一个IE窗口弹出，会执行上面的JavaScript，应该可以证明GTalk聊天界面是基于IE内核的。我们试验了很多，当然也有很多屏蔽的东西，呵呵。
希望广大Geek继续发现！
Update：又跟CCoffee讨论了一番，发现这个问题不能这么轻易的下结论。有很多从Gtalk里面打开链接的都是从IE打开，即使设置了firefox为缺省浏览器。这是为什么呢。老外也谈到了这个问题，究竟GTalk跟IE的关系是什么样子的，我们现在也搞不明白了。
附上链接：
www.revolutionwebdesign.com/blog/index.cfm/2005/11/1/gTalk-and-IE
在Gtalk里面对于链接的处理不会是Hardcode吧，就是写成IE的？
© Jia Mi for Xerdoc Together, 2006. | Permalink | 16 comments
Add to del.icio.us
Search blogs linking this post with Technorati
Want more on these topics ? Browse the archive of posts filed under Other, Tech.