Google Wave终于支持非Wave用户匿名浏览

下面这个嵌入式的Wave就是Google Wave团队的官方公告Wave,现在你不用登录Wave就能看到它了。不过匿名用户还只能浏览,参与互动仍然需要登录。但这样已经让Google Wave的可用性大大增强了,可以在更多Web领域发挥它应有的价值。

结合Google Wave API的Proxying-for,我们也可以自己实现匿名式交互,或者与其它身份系统集成(比如OpenID)。有时间的话,我会尝试做一个OpenID Proxy的Sample。

Google Buzz的解读误区

Google发布Buzz后,网络上迅速出现了大量对Buzz的评论,有正面的,有负面的,有炒作概念的,有跟着起哄的,甚至引发了大家对Gmail安全的担忧。这其中不乏一些对Buzz的误读,所以,在这里以我个人的理解来解释一下。

“Google Buzz是Twitter杀手!”

这是大多数媒体最喜欢的炒作方式,又一个Killer App出现了,于是编辑们都兴奋了,又可以赚足眼球了。事实上,Google Buzz和Twitter总体来看并不是一个层面上的应用,还构不成真正意义上的Killer。一些冷静的分析还是看的比较清楚,Google Buzz其实主要针对的是FriendFeed,因为它们都是聚合平台,让不同源头的信息聚合在一起。Buzz相对于FriendFeed的最大进步在于,它除了聚合信息之外,还创造性的利用Social Graph来聚合人际关系。

当然,Google Buzz除了聚合功能外,自身也充当了一个简单的信息源,可以在Buzz上发表富媒体信息。但事实上,你有自己充分的选择权,完全可以保持原有的习惯,在WordPress上写Blog,在Twitter上唠叨几句,这些信息最终都会自动被汇总到Buzz中来。

“我们不需要又一个社交网络”

当你迫不及待的跑来Buzz上兴奋的吼了几句后,才意识到它和Twitter也没多少差,反而在这里找不到Twitter上那种“振臂一呼,Follower百应”的成就感了。没过多久,你就会逐渐淡忘掉Buzz。这是因为,你把Buzz当成了一个和Twitter、Facebook、MySpace一样的社交网络。“又一个新的SNS,我不得不又一次花费时间从头建立我的关系网络。”其实这不奇怪,不光是你,连Microsoft也这么认为

本质上,Buzz并不想打造一个新的社交网络,恰恰相反,它的目的是推进一系列开放标准,使用户不必在各个SNS维护一个又一个彼此独立的关系网络,使人际关系得以重用和汇聚,进而构造起一个去中心化的Social Graph,不依附于某一个特定的SNS。

Buzz倡导运用XHTML Friends Network (XFN) 和 Friend of a Friend (FOAF) 挖掘和汇聚用户既有的关系网,实现SNS间的互操作性。如果各个开放SNS都能响应这一号召的话,那么将来我们就再也不用担心自己的人际关系被锁死在某个SNS中,甚至还可以借助新的SNS发现原有SNS中漏掉的好友。

“Buzz让信息的回复和评论更加破碎了”

这一点确实是目前不争的事实,因为无论你从Twitter往Buzz同步也好,还是打算反过来从Buzz发布到Twitter,你都得面对一个问题,回复和评论的不同步。你很可能因为只在Twitter上读消息而遗漏了Buzz里别人的评论,或许在习惯了Buzz后,又冷落了Twitter上的Followers。在Web应用越来越多的引入“聚合(Aggregation)”功能后,这个问题逐渐凸显出来。Google Buzz现在没有解决这个问题,但这只是因为目前的Buzz还尚不完整。Buzz的API文档中有一节“Coming Soon”,其中提到了Buzz未来对这一问题的解决之道——Salmon

之所以现在没有推出Salmon支持,我猜想,一方面是由于这个规范尚处在Draft阶段,另一方面它无法从Google单方面实现,因为信息源和聚合者都必须遵从Salmon协议,才能完整的实现评论同步。这个事情倘若让任何一家其它互联网公司来推,可能都收效甚微,但由Google Buzz倡导,其影响力就不可同日而语了。因此,Google在完成Salmon的支持前,先放出Roadmap来,让大家都意识到Google开放的心态和坚定的决心,这样Salmon才有机会得到广泛的认可和支持。

所以,就如同Wave对大多数人来说也不过尔尔,只有当你透过API去洞察其背后所希望表达的真正意图后,才能深刻理解Google每一款产品的前瞻和愿景。在大多数人被Buzz的优雅与便捷所打动时,我更看重的是它将对整个SNS生态圈所产生的深远影响,和它在推动开放和标准化上的显著贡献。

【闲言碎语】淘宝电器城、网瘾战争、轩网、GAE、tb.ly、第一推动丛书……

自从习惯了Twitter后,Blog写的是越来越少了。Twitter虽好,但相对于Blog,它其实很不利于内容的沉淀,再加上因国情问题而导致很多朋友无法访问,有价值的信息就此流失。为此,我准备尝试每周做一个Tweets的合辑,让这周中那些不是废话的内容能有机会沉淀下来,并且让更多人有机会从中获取有用的信息。当然,也随时欢迎在Twitter上Follow我

继续阅读【闲言碎语】淘宝电器城、网瘾战争、轩网、GAE、tb.ly、第一推动丛书……

从胶水到运河——Google Wave的战略使命

  先来看一下Google的愿景及其诞生至今的战略布局。Google的终极愿景很明确,也几乎没有改变过,那就是:“整合全球信息,使人人皆可访问并从中受益。” 这句话讲的挺有技巧,整合全球信息,并非简单的供你们搜索和访问,“从中受益”,那前提是Google需要充分从这些信息中挖掘出价值,而后才能造福大众。“掌握和控制信息”是Google所有从属战略的核心。

  第一代搜索引擎所代表的是“整合互联网静态信息”的愿景,Google借助其强大的搜索引擎和海量存储成功的树立了搜索领域的霸主地位。在这个年代,整合互联网信息的方式相对比较直接了当,那就是“蜘蛛+索引+搜索”。大部分静态内容都是可以方便的直接访问到的,因此Google只需要构建一个巨型索引就可以达到整合信息的战略目的了。

继续阅读从胶水到运河——Google Wave的战略使命

GFS: Evolution on Fast-forward

转载自ACM Queue – GFS: Evolution on Fast-forward

A discussion between Kirk McKusick (known for his work on BSD Unix, including the original design of the Berkeley Fast File System) and Sean Quinlan (served as the GFS tech leader for a couple of years and continues now as a principal engineer at Google) about the origin and evolution of the Google File System.

The discussion starts, appropriately enough, at the beginning—with the unorthodox decision to base the initial GFS implementation on a single-master design. At first blush, the risk of a single centralized master becoming a bandwidth bottleneck—or, worse, a single point of failure—seems fairly obvious, but it turns out Google’s engineers had their reasons for making this choice.

可能和我们想象中Google的分布式系统设计原则完全对立的一个决定,是如何产生的呢?这段对话就是从这个有趣的话题开始的。

整个对话在两个对文件系统有着深刻理解的业界专家之间展开,从分布式体系的设计思路及其演进、吞吐和延迟的取舍、性能瓶颈的解决策略,以及GFS和 BigTable之间相辅相成的内在联系。印象中这还是Google第一次在公开场合提及大量GFS的运作方式和实现策略的细节,强烈推荐给做分布式系统的技术人员!


GFS: EVOLUTION ON FAST-FORWARD
A DISCUSSION BETWEEN KIRK MCKUSICK AND SEAN QUINLAN ABOUT THE ORIGIN AND EVOLUTION OF THE GOOGLE FILE SYSTEM.

During the early stages of development at Google, the initial thinking did not include plans for building a new file system. While work was still being done on one of the earliest versions of the company’s crawl and indexing system, however, it became quite clear to the core engineers that they really had no other choice, and GFS (Google File System) was born.

继续阅读GFS: Evolution on Fast-forward

探究Google的Iterative Web App软件架构

Google的软件架构向来是最吸引广大开发者的眼球并被人们乐此不彼的津津乐道,尤其是那些运作在Google最杰出服务背后的软件架构。

Google在2004年“愚人节”推出的Gmail服务可以说是Google众多服务中,除搜索外最杰出的典范之一。Gmail在过去五年多的时间里,也经历了一个持续发展和演进的过程。新功能的推出和用户体验的改善或许是大家谈的最多的,但其底层架构的变迁却并不常常能被用户切实感受到。其实,正是因为Gmail底层架构的不断升级,才支撑其众多新特性和功能的更快开发并上线。

早在2007年10月,Gmail的官方Blog上就曾经发表过一篇关于其架构变迁的文章“Code changes to prepare Gmail for the future”,其中提到:
继续阅读探究Google的Iterative Web App软件架构

Google Adsense开始针对用户特征投放广告

今天收到Google Adsense的邮件,得知Adsense网络的一个重大升级——“用户兴趣定位广告”。过去,Google是通过抓取网页内容以确定广告投放的定向性,也就是“以内容定广告”。如今Adsense将要推出的这个新特征将广告投放的定向性进一步深化,达到了“以访客定广告”的效果。这也间接印证了我一直以来的一个忧虑,Google长期以来在通过其服务网络收集用户特征,包括注册和非注册用户。借助cookie和javascript跨站交互,Google可以将其所有的服务网络串联起来,深度跟踪用户在其各类服务中的使用习惯和兴趣。尤其是前段时间推出的Google FriendConnect服务,更是将其触角延伸到Google自己的服务之外,渗入个人Blog和SNS之中。(所以在这一点上,我对 FriendConnect还是有点抵触的……

看起来,目前Google已经掌握了足够的用户特征,可以正式在其Adsense网络中推出上述针对用户特征的定向广告投放了。对我们这些互联网用户而言,也不知是福是祸…… 还是那句话,别把鸡蛋放在一个篮子里,用户隐私也是一样。

FriendConnect——Google的宏伟愿景

Google是一家技术型公司,和微软一样,并不擅长于“大众行为”的研究,因此,它在IM和SNS两个领域内都不太成功。其实,并不是Google不懂用户体验,但典型的技术型公司都有一个通病,它们不屑于做“一些事情”,而这些事情又恰恰为网络“大众”所好。没办法,所以腾讯能把IM做到盆钵满金,而SNS领域也被一帮后起的小毛孩所瓜分。

Google在过去经常以技术领航者的身份自居,动不动就推一些过于超前的概念,不仅不管它人能否理解,而且还无视商业潜规则。可惜互联网时代没人懂得尊重教父,太多的后辈想要一展拳脚。因此,Open Social遭遇了滑铁卢,几乎没有一家规模的SNS网站买账。想想也能理解,在这个SNS烽火战国的年代,各大诸侯都在忙着把对方的用户挖到自己的墙里来,你却跳出来讲什么“兼爱非攻”……

如今,Google总算学会了游戏规则,技术当然是永远不可抛弃的根本,也是打天下的利器,但铮亮的枪头得用布给包一下,既要攻其不意,还要锋芒内敛。于是,FriendConnect就在这样的背景下低调登场了。

从技术的角度讲,FriendConnect代表了“网络人际”发展不可阻挡的未来趋势。在过去的几年间,Web 2.0革命性的将个体的“人”从封闭的网站和论坛中解放出来,造就了雨后春笋般涌现的一大批具有独立言论的“博客”。只可惜革命得有点过了火,使得越来越多的个人博客逐渐迷失在自我的孤岛中。这时,那些论坛旧势力背后的贵族趁机见风使舵,披上Web 2.0的外衣,改头换面以“SNS”的全新身份又杀了回来,并且打着“互动”和“开放”的幌子,妄图把刚刚获得自由的个体又重新圈入它们筑起的高墙之中。可怜Google在一旁望着这些被花言巧语骗的跟风盲从的大众,只能兴叹革命的心酸与不易,而到头来胜利果实却被它人收入囊中。

当然,Google也并不全是表面上看起来那么高尚,真正点燃这场SNS大战导火索的其实是那些SNS网站自己。我们别忘了,Google的核心使命(或者说核心利益)是整合全球的信息。就在Google从“人肉搜索”中顿悟后,开始构思它“从整合已发布的静态信息上升到整合人们所要表达的思想”这一战略步伐时,那些不懂事的SNS网站跳出来挡道了。不光挡道,而且还狠狠的扇了Google一记耳光,因为它们开始拒绝向搜索引擎爬虫提供用户发布的信息。你说这还能不惹恼Google么?

在潜心思索后,Google又重新站了出来,这一次它借FriendConnect的旗帜再度鲜明的指出了“个体”的重要性,强调互联网应当以“人”为中心,而非眼下这些院墙渐深的SNS社区。当然,如果你一定要将它也视作SNS的话,这张网就是整个Internet。FriendConnect试图改变现今SNS的游戏规则,它要在当前零散的星型SNS网络外面编织一个更大的、无所不包的无形的网状SNS。因为用户不必从一个固定中心的SNS网站登入,然后才开始在其中交互;以后,你在访问互联网的任何一个角落时,可能都在这个SNS网络的辐射中,你可以以一种合乎行为习惯的方式随时和朋友交流你正在浏览的内容,而不必像现在这样非得粘贴链接到社区里去,让后续讨论完全与内容的来源脱钩。FriendConnect同时很好的解决Web 2.0的“个体解放”革命中遗留下来的孤岛效应,既肯定了个人的自由和中心地位,又让整个互联网和SNS融为一体,再无森森院墙。

从战术的角度来看,这一着Google也走的相当高明。它不再傻乎乎的与现有的SNS网站正面争抢用户,而是领会了毛泽东军事思想中“农村包围城市”的精髓,采取笼络尚处于游离状态的个人博客(以引入流量为诱饵)的策略,在主流SNS之外的空白地带织网。可以猜想的到,待FriendConnect羽翼渐丰后,下一步Google很可能会以定制Gadget的方式将FriendConnect直接安插进现有的SNS网络(比如推出一个Facebook服务,整合两边的好友),再从中抽丝剥茧,内外夹击的蚕食掉这些自我中心主义的SNS社区。

作为一个开放技术的拥护者,我非常支持Google的FriendConnect。但当忧及隐私问题时,FriendConnect又一次布下了一片遮天蔽日的乌云,这一次甚至让你找不到躲开它的角落。从技术的角度讲,利用Cookie和跨站脚本,任何加入FriendConnect的网站实际上都在不知不觉中被Google利用来作为眼线,从而大大拓展了用户被跟踪的范围。想想Eagle Eye里面所描绘的图景吧,说不定那就是明天的Google。

最后,从引导互联网正确趋势以及力量制衡的角度出发,我还是希望FriendConnect一路走好。但我更希望看到未来一个对等和完全开放的FriendConnect出现,而非由Google来垄断……

谁家语言将成为Google App Engine的下一个宠儿?

Google App Engine Roadmap

10/08 – 3/09

* Service for storing and serving large files
* Datastore import and export utility for large datasets
* Billing: developers can pay for more resource usage
* Support for a new runtime language
* Uptime monitoring site

顺便看看社区的民意,Java、PHP和Ruby名列三甲!

从技术角度来讲,PHP和Ruby应该较Java在现阶段更易于实现;但从业界支持的角度来看,Java占据了企业级应用的主流,而PHP代表着Web开源社区的倾向,似乎是两难的选择呀;纯粹从语言本身来看,Java应该更适合Google的战略布局。

这个语言想必Google内部早已有了定论,并且已在紧锣密鼓的赶工中,留给大家YY也不会改变任何东西了。虽然从感情上更倾向于Java,但我还是认为PHP的可能性最大。

Symbian S60下的Google日历同步工具——CalSync

http://s60addons.com/calsync/

虽然仍在beta阶段,但也比以前用的GooSync.com要强多了,至少Todo List可以被正常同步。而且比用SyncML协议的速度要快那么一点。

但据我测试,仍然有bug:在手机上删除的Todo条目似乎不能正常同步删除Google日历中的条目,等再次同步时,CalSync又会将它同步下来,并且变成一个全天的备忘事项。