| 28 | |
| 2010.2 |
一直以来，Symbian都是基于OS + UI体系分离的设计，这种分离又不同于Android，后者的不同UI只是视觉呈现的差异，对应用而言，是完全兼容的。但Symbian的不同UI体系，如S60、S80、UIQ、QT等，彼此间连UI的API都不兼容，对应用开发者来说，这真是一个噩梦。虽然也可以通过将UI API的使用限定于Uikon UI（S60、S80、UIQ等当代UI体系共同的继承源），从而实现最大程度的兼容，但这样做是以牺牲广泛的可用UI元素为代价的，对稍复杂的应用而言都不太现实。况且即将取代现有各种UI体系的QT，又是一次颠覆性的变革，不用指望任何的兼容可能了。
那么，在这样一个变革到来之前的暗夜，如何开发一款可跨UI体系的Symbian应用呢？这并非没有可能，但有着诸多的限制。如果你的应用能满足这些限制的话，那么完全可以成为真正意义上的跨UI体系的Symbian应用。
| 11 | |
| 2010.2 |
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生态圈所产生的深远影响，和它在推动开放和标准化上的显著贡献。
| 1 | |
| 2010.2 |
自从习惯了Twitter后，Blog写的是越来越少了。Twitter虽好，但相对于Blog，它其实很不利于内容的沉淀，再加上因国情问题而导致很多朋友无法访问，有价值的信息就此流失。为此，我准备尝试每周做一个Tweets的合辑，让这周中那些不是废话的内容能有机会沉淀下来，并且让更多人有机会从中获取有用的信息。当然，也随时欢迎在Twitter上Follow我。
| 30 | |
| 2010.1 |
Google App Engine（以下简称GAE）除了支持自有的appspot.com域名外，借助Google Apps，它还允许用户配置自己的独立域名提供服务。但之前使用过独立域名的朋友可能都遇到过一个相同的困扰：你可以用指定一个特定的二级域名访问你的应用，但却无法使用泛域二级域名（wildcard sub-domain）。对泛域支持的社区呼声一直都很强烈，Google也声称将要支持这一特性，但却未给出具体的时间表。
前两天为了解决tb.ly的泛域二级域名，折腾了很久。因为虚拟主机服务商Dreamhost不对非Private Server用户支持DNS泛域解析，所以我不得不另谋它策。在GAE上的一次没头没脑的尝试，居然意外的让我发现GAE已悄然支持了泛域二级域名。配置过程稍微有些复杂，所以在这里完整整理出来，以tb.ly的真实案例，分享给各位研究GAE的朋友。
| 26 | |
| 2009.12 |
相信大部分用过Everything的朋友们都再也离不开它了，我也一样。作为一个现今已不多见的“键盘流”，日常的大部分程序我基本都直接从Everything中启动，少了纷乱的快捷方式，桌面也清爽了不少。
Everything由于核心原理建立在NTFS的底层机制上，所以在Vista/Win7中不可避免的必须以提升的权限运行（UAC），不过这对与大多数PC玩家来说早已不算什么障碍。但你是否留意过，通过Everything启动的任何程序或打开的任何文件，也都继承了其拥有的提升权限，这对于重度依赖它的玩家来说，却是一个非常致命的隐患。当你从Everything中启动了Total Commander，又从Total Commander中启动其它应用，这整个程序链全都跑在不受约束的管理员权限下，对系统安全构成了严重的威胁。
那么，如何才能避免这种权限提升的传递呢？
| 12 | |
| 2009.10 |
先来看一下Google的愿景及其诞生至今的战略布局。Google的终极愿景很明确，也几乎没有改变过，那就是：“整合全球信息，使人人皆可访问并从中受益。” 这句话讲的挺有技巧，整合全球信息，并非简单的供你们搜索和访问，“从中受益”，那前提是Google需要充分从这些信息中挖掘出价值，而后才能造福大众。“掌握和控制信息”是Google所有从属战略的核心。
第一代搜索引擎所代表的是“整合互联网静态信息”的愿景，Google借助其强大的搜索引擎和海量存储成功的树立了搜索领域的霸主地位。在这个年代，整合互联网信息的方式相对比较直接了当，那就是“蜘蛛+索引+搜索”。大部分静态内容都是可以方便的直接访问到的，因此Google只需要构建一个巨型索引就可以达到整合信息的战略目的了。
| 3 | |
| 2009.9 |
前段时间，有一个朋友借我的相机去用。回头来还给我时，抱怨说他不小心把拍的很出彩的一张照片给误删除了。我琢磨了一下，富士这款F31fd上，删除相片也是有个二次确认的过程呀，而且二次确认的默认选项还是“停止”。难不成我这个朋友能短路到义无反顾的程度？不过当听完他道出苦水后，才意识到，原来这都是用户交互体验设计失误惹的祸。看似万无一失的“二次确认”，一样拯救不了你的照片。
事情的经过是这样的：当我的朋友在拍完那张照片后细细欣赏时，不小心按到了“上方向键”，这是删除当前照片的快捷键。而后，看到屏幕上显示出的删除确认提示，我这个朋友一阵紧张，先是连按返回键，发现取消不了又忙不迭的切换选择框到“停止”上，并匆匆按下“确认”。哪知道，却依旧眼睁睁的看着喜爱的照片香消玉殒……
| 16 | |
| 2009.8 |
转载自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.
| 4 | |
| 2009.8 |
Google的软件架构向来是最吸引广大开发者的眼球并被人们乐此不彼的津津乐道，尤其是那些运作在Google最杰出服务背后的软件架构。
Google在2004年“愚人节”推出的Gmail服务可以说是Google众多服务中，除搜索外最杰出的典范之一。Gmail在过去五年多的时间里，也经历了一个持续发展和演进的过程。新功能的推出和用户体验的改善或许是大家谈的最多的，但其底层架构的变迁却并不常常能被用户切实感受到。其实，正是因为Gmail底层架构的不断升级，才支撑其众多新特性和功能的更快开发并上线。
早在2007年10月，Gmail的官方Blog上就曾经发表过一篇关于其架构变迁的文章“Code changes to prepare Gmail for the future”，其中提到：
» Read more…
| 25 | |
| 2009.5 |
Twitter的成功，证明了挖掘已有产品间覆盖交叠的薄弱地带，面向用户需求作精确的定向设计，并不需要提供强大的功能，也能脱颖而出，创造一片蓝海。
蓝海是怎样发掘的
在Twitter这种微博客形式出现之前，博客（Blog）和即时消息群（IM.Group）是两种泾渭分明的在线交流形式。博客以博文为中心，辅以评论作为异步交流的空间；而即时消息群则强调实时性和直接交流。前者由于其过于中心化的倾向，弱化了交流的过程，而且过于依赖博文作者的写作意向；后者因其受众的相对固定性，难以充分满足个体的自我表达欲，同时也阻碍了更为广泛的交流，使得讨论主题不易凝聚。
如何才能兼顾博客“自我中心的表达”和即时消息群“及时广泛的交流氛围”，Twitter给出了答案。通过限制字数来有效降低博客的写作门槛并拓展其题材空间，鼓励更多的普通人群加入自我表达中来；另一方面，引入follow机制，吸收SNS的理念，增强了交互的广泛性和及时性。虽然最终的融合使得Twitter上的消息既没有博客看起来那么正式，也没有即时消息群那么及时和活跃，但却有效的弥补了两者的不足。满足用户最切实的需要是Twitter成功的关键。
简单和开放铸就成功
