DBA notes

杭州五年

Sat, 13 Mar 2010 02:07:35 GMT

今天到医院拔掉了一颗让我困扰已久的智齿，现在还有点迷迷糊糊的发烧。整个过程比我想象的顺利得多，一下子如释重负的感觉。有朋友说，拔牙会影响记忆力，如果真是这样，那现在应该多写一些东西，以便在遗忘后还能让我回忆起往事。

时间真的是快，2005 年的今天，我来杭工作。那时候牙齿应该都还好好的，最起码第一年体检的时候没什么毛病，经过五年的爬摸滚打，没想到事业不立，这追随我的牙齿兄弟就已经开始掉队了。我要把我的牙扔到楼下去（这是我们老家的风俗，上牙往下扔)，老婆对我说，你以为还能象小孩子那样再长出来一颗啊? 是啊，我再不可能长"智慧"了啊。

我以前从没想过会在这个城市生活这么久，杭州"离天堂太近"，仍旧无法让我喜欢。这城市不停的有人来，不停的有人走。最近就有一个朋友要离开杭州去创业了，,不知道什么时候开始，"创业"这个词对年轻人有挥之不去的吸引力，我认识的一些朋友，不在创业，就是在准备去创业的路上。可看看这整个商业环境，还是挺令人寒心的。不过，千军万马，总有人杀出血路。

再过几天，我在阿里巴巴集团旗下支付宝的工作就满五周年了。在阿里巴巴，五年陈员工，会有一枚定制的戒指。五年，就这样告一段落。或许，我该记录一下过去的那些痛并快乐的日子作为纪念.....

--EOF--

暂缓迷恋 Cassandra

Fri, 12 Mar 2010 02:07:16 GMT

最近 Twitter 和 Digg 的技术团队都放出话来说要从 Mysql + Memcached 的组合迁移到 Cassandra 环境（Refer 1、2)，这些消息又会让不少人跃跃欲试，恨不得也把自家网站迁移到 Cassandra 下面过把瘾，我相信有些公司的团队又要言必称 Cassandra 了。

Twitter 和 Digg 对数据存储引擎的需求相当独特：写操作密集，基本无修改需求，读操作则多数是分散多次读取汇总展示(想象一下你 Twitter页面上同时显示好友们的 Tweet 内容)。对 MySQL 来说，Sharding 后几乎是被当作简单的存储引擎来用的，即使是加上 Memcached ，对数据读取开销相当大(Refer)，因为这时候即使是最合理用索引，I/O开销也不是最优的--走的是索引范围扫描嘛。Cassandra 则相当于预存了计算结果，这要得益于其 Flexible schema 特性，按照既定规则写入，读取直接取预排序的范围键值结果(这其实是偏 OLAP 的应用，而非 OLTP)。

Twitter 和 Digg 这两家网站的数据结构其实并不复杂，尤其是 Twitter ，相当的简约（当然并不简单）。或许有人说，把 Cassandra 开源的 Facebook 不也在用呢吗 ? Facebook 数据结构不复杂么？没错，Facebook 数据结构很复杂，不过使用 Cassandra 的场景其实和 Twitter / Digg 几乎一致的---只是用在 inbox 这个地方的数据处理而已。

不要迷恋 Cassandra ，如果应用场景不合适，那么对你来说永远都只是个传说。。

--EOF--

苹果为何不在 iPhone、iPad 平台支持 Flash

Wed, 24 Feb 2010 09:44:34 GMT

最近 Apple 和 Adobe 之间因为 Flash 的支持与否，口水仗打的比较热闹。个人愚见，苹果公司做出当前的选择应该不是因为乔布斯要逞一时口舌之快，相信是内部自有 iPhone 以来的长期评估后做出的选择，苹果公司从战略层面甚至会把 Adobe 看作竞争对手而不再是重要的合作伙伴，而谢绝 Flash 入内，是一个非常精明的借口。

之所以说二者是竞争关系，关键字还是在于"平台"。Adobe Flash 是当前业界占有率最广泛的一个技术平台，甚至超过大家想当然的 Java 。根据 Adobe 的统计，Flash Player 占领了 99% 可上网电脑设备，有超过 200 万专业用户在使用，这里的专业用户应该指具备一定开发能力的用户，依托于 Flash 的应用程序数量已经相当的惊人。所以，是否在 iPhone 、iPad 上引入 Flash 的支持，从苹果的角度看，这是平台之战，谁也不想引狼入室。我们设想一下假定 Flash 已经得到了苹果公司的支持，那么 Adobe 可以一转身也建立一个 "Flash App Store" 或者类似的东西，开发者可以用上传的小应用，任何平台的用户都可以下载使用。想想对苹果的冲击会有多大? Adobe 或许还没想好如何也建立一个 App Store ，但不排除将来会染指这一块业务。

苹果公司长久以来不太有"开放"的态度，或者说是"封闭的开放"，最希望通过自己封闭的环境，让用户通过圈下来的地建立一个生态圈子，不想和其它公司一起合作。乔布斯回归后，通过激发用户对 iPod 喜爱与信赖，进而购买使用 iPhone ；通过 iPhone ，进而使用 iPad ；通过 iPad ，再回去使用 Mac 。这是个非常好的封闭循环过程。开放，会丢掉利润，而封闭，才会让苹果公司有更大收益。当然，我也想说的是，对 Flash 的支持友好也的确有可能让 iPad 在某些方面导致平庸，比如性能。与之类比的是 Firefox ，现在速度问题广为用户诟病，而这问题基本由插件导致的，现在 Chrome 尽管足够快，但随着扩展日益增多，必然重蹈覆辙。

现在乔布斯游说内容提供商加入他的 iPad 阵营，而他之所以敢批评 Flash 的不足，也是因为还有另外的技术路线可选，那就是 HTML5 。但是有多少内容提供商会舍弃 Flash 而加入 HTML 5 的阵营，这个还需假以时日才能看清楚。换做另外一家公司，来自用户的呼声可能都会受不了，对于苹果来说，我行我素是一贯的风格，乔布斯一直是个精明的商人。

是否会在 iPad 上看到 Flash ? 将来或许会，但是这要在乔布斯开给 Adobe 的条件都得到满足的情况下才会出现(没错，这两家现在或许已经在谈判桌上了)，这些条件当中，除了解决当前的性能和稳定性问题(这个问题并非原则上的问题)，最重要的是 Adobe 不要与苹果有商业利益上的冲突，苹果一定要得到某种承诺，而这，对于 Adobe 来说，也会是艰难的选择。

--EOF--

注：春节期间构思此文，一直没发出来，后来发现有不少人也持类似观点，澄清一下，并非拾人牙慧。

说起平台，国内 360 安全卫士尽管已经取得了惊人的装机量，进而推的浏览器和网址导航也都立竿见影，但是还难脱"工具" 的影子，还是不能形成技术生态环境，我相信不会有类似 "360 平台" 的产品出来的，不是不想，而是做不到。

Sun(Oracle)公布的 Java 在桌面机有 8 亿。

苹果往事

Fri, 19 Feb 2010 03:20:22 GMT

春节前已经看了一遍这本《苹果往事》，假期又看了一遍。对于这段苹果公司并不鲜为人知的历史来说，这本书从一个亲历者的视角给 Mac 的诞生加了一大段注解。这也是苹果拥趸者最喜欢看的内容。

彼时的乔布斯，恰似刚受封齐天大圣，自信无所不能，被排挤到 Lisa 项目之外意味着他将来没有权利说这是他设计的产品，所以最想做的事情就是找个项目来证明自己。他对于 "自己参与设计" 的项目无疑是寄予厚望的，也给予了足够的支持，否则这个从概念项目起步的团队也不可能发展起来。对于这个团队的多数人，他们要研发的这个产品，不为名不为利(实际上也只有少数几个人得到了名利)，更多的是创造性工作给自己带来的成就感，什么是激情，或许这就是。

对于 1984 年苹果推出的 Macintosh ，现在来看，或许是那个寓意深刻的广告更为令人津津乐道。当时的 Macintosh 只能算是杰出的电子艺术品，是否是成功的产品很难定论。毕竟从市场表现来看，没有给苹果带来像 Apple II 那样的辉煌。这个产品的推出从某种程度上也间接促成了乔布斯被赶出苹果。是苹果公司发展历史上的一道分水岭。如果没有当初，或许也不会成就现在的乔布斯。现在的 Mac，其实无法让人等同于 1984 年的 Macintosh...我相信只是有些精神会延续下来...或许这样就已经足够了。

在这本书的最后，作者 Andy Hertzfeld 感伤 "我所渴望的理想麦金托什团队模式已经消失了，融入了那种我们以前常常取笑的大型组织当中，内部充满官僚障碍及人际摩擦"。曲终人散，这个团队的大多数人都将不再服务于苹果公司。这也是那些非凡团队成员的普遍命运。

阅读这样一本书，对我们更有价值的事情从中学习那些经验和教训，关于人，关于事。让人欣喜，让人心酸。

--EOF--

虎年快乐！

Fri, 12 Feb 2010 03:17:44 GMT

给我的朋友们，还有这个网站的读者以及Twitter 上的推友：感谢过去一年对我的支持、帮助亦或是鼓励、信任。祝愿大家在虎年（来个更加环保一点的拜年）：

新年快乐！健康平安！

新的一年就要来临，在这新的一年会有哪些奇迹发生？一起来期待并见证吧...

一切高墙都会倒塌，只要我们坚持并坚信。

--EOF--

推荐一首歌，崔健《春节》

民生银行的系统事故

Tue, 09 Feb 2010 03:15:18 GMT

虽说年底是 IT 事故多发的期间，不过这次民生银行系统瘫痪事故还是让人觉得有点严重。事发 2 月 3 号，从上午11:00到下午15:30，故障持续四个多小时，全行系统瘫痪。对外称是"核心系统维护"。

个人之所以比较关注这个事故，是因为新闻标题中的"数据库维护失误"。据说是"由于数据系统进行维护时出现了失误，造成宕机"。开始的时候，大家把关注的焦点放到灾备切换与否的问题上，据说是"没敢切换"。初看上去倒是有点像 DBA 误操作。有人说是和时间服务器有关，我错过了讨论现场。

也有朋友在 Twitter 上说：民生银行上周的系统宕机事故，源于IT部门某应用系统数据库（应该是 DB2 Informix，数据库版本老旧，且无正常维护服务），一个应该在夜间处理的长任务，运行到银行开门也未结束，该系统正常时的CPU使用率就已经到达70-80%，长任务从夜里一直跑到上午无法停止，把本来就不堪重负的业务系统拖慢到不能忍受，由于数据库版本 EOS (End of Service) ，无厂商实验室的工具支持无奈之下，要求重启相关系统，结果造成业务停止。事件的(后续)处理还在进行中。(via)

上述说法看起来比较可信，也足以解释为什么不切换到灾备上。如果因为计算能力的不足 (或是系统性能问题) 的话即使是切换也无济于事的。民生的旧系统是 SAP 核心，实施方是埃森哲(refer)。不过，"民生银行打造的新核心系统已经开发完毕，目前处于内部运用的阶段，今年上半年将会在全公司上线"，估计到时候能稳定点?

另外看到有网友说，2008 年初，民生银行的的小额支付系统也出过严重问题，由于操作失误或是程序内部控制原因，造成了几百万的重帐。

涉及到钱的问题总是让人如履薄冰。根据我个人亲身经历过的一些事情来看，事故发生后，更多的时间都会花在决策上，而一旦选择错误或者不是做出最优的决定，灾难才刚刚开始。

--EOF--

有朋友后续补充到：2010 年 2 月 12 日上午 10:25，民生银行的信用卡网银不可用，返回 HTTP 500 服务器内部错误，网站上并没有相关的维护计划，咨询客服，说是系统维护升级。整个民生的 eBank.cmbc.com.cn 都是无法登陆的状态，看来"维护升级"的不只是信用卡网银，自2月3日以来，不到10天又发生状况。

2009年数据库技术领域回顾

Mon, 08 Feb 2010 09:43:18 GMT

简要回顾一下 2009 年数据库技术领域。过去的一年，差不多也可以说是过度的一年，数据库技术以及数据存储产品等都都或多或少发生一些方向上的转变。

Oracle 收购 Sun，MySQL 前途未卜

Oracle 收购 Sun 可谓一波三折。在获得美国司法部门的批准后，欧盟委员会又开始调查，Oracle 随后抛出一个"十条保证"，眼看着欧盟就要点头，没想到 MySQL 创始人 Michael Widenius(Monty) 则在这个当口不失时机的搞出来一个"拯救 MySQL"的抵制活动，让 Oracle 头疼不已。Monty 这人多少也有点上纲上线，现在已经将 MySQL 的命运和 "Internet Free"这个大话题绑在一起了。

没有人会相信 Oracle 会善待 MySQL，谁会干放虎归山的事情呢? 换了你也会把 MySQL 雪藏起来，毕竟商业公司就要逐利。但是，也很难说一旦收购完成后，MySQL 会在短期内消失，基于 MySQL 众多开源分支以及解决方案也都发展的不错，我相信最终决定权还是在用户的手里。就算没有 MySQL，也没准儿会有 YourSQL 出来的...

尽管口水战还在进行，MySQL 的开发者倒是没闲着，在年底发布了 5.5 第二个里程碑版本，原来站点上的 6.0 系列的信息全部撤掉。5.5 更像一个集成版本，将不少第三方贡献的功能改进(比如 Google 的 Patch)融合了进来。

而 Oracle 这一年在产品上的一个标志性事件是推出了 Exadata 存储第二版，与第一个版本不同的是，这一个版本在 OLTP 方面增强了许多。从这个版本开始，Oracle 正式拥有自己的存储硬件(第一版是和 HP 合作的产物)。RDBMS 上，除了发布 11g 第二版之外，也在做功能上的调整，这一次，面向的是数据中心。

NoSQL 的兴起

这是今年数据库领域最有趣的话题。NoSQL 的由来大约是这样的：当时还效力于 Last.FM 的 Johan Oskarsson （现在已经投靠 Twitter 了)组织了一个技术会议，话题是关于"open source, distributed, non relational databases"，为了方便一点，想出来一个 "NoSQL" 的术语。然后由 Rackspace 的 Eric Evans 引用，进而流传开来(refer)。NoSQL 在基于 Key-value 的存储解决方案上提倡去 SQL 化，尤其避免表连接，并且通过一些变通的办法提供 RDBMS 的 ACID 功能（如果需要的话）。

NoSQL 的理念能够短时间内被技术圈所接受，离不开基本的理论支撑：最终一致性、BASE 、CAP 这三大基石；一方面是基于 Key-Value 的数据存储解决方案更加成熟，

所谓 NoSQL ，是针对当前对关系型数据库的过度依赖与运用而言，不要将其当成万能药，也没必要过于激进的推行 NoSQL 的模式。在我看来，NoSQL 是针对争夺应用模式上的一种理念上的运用。对多数企业来说，仍属屠龙之技，没必要照搬解决方案。至于传统的 RDBMS 是不是已经走向末路，我认为不尽然。RDBMS 依然尤其广泛的应用场景，而NoSQL如果要有更大的作为也要有来自商业上的更大支持才会有所突破。

SSD 被更多企业接受

Jim Gray 在 2006 年的那句名言：Tape is Dead，Disk is Tape，Flash is Disk，RAM Locality is King ，现在正在被现实所验证。2009 这一年，用户已经开始进一步试水 SSD 产品，包括 MySpace、Last.FM 等网站已经开始在关键应用上部属 SSD(refer: 1, 2)。而国内也有很多企业对 SSD 进行尝试性的使用，这其中包括阿里巴巴、优酷。

更多的存储厂商已经在高端存储中兼容 SSD ，除了去年的 EMC 尝鲜之外，现在 IBM、HDS 、NetApp 都加入了这一阵营。

。

随着 SSD 的价格迅速下降，很多存储厂商已经开始调整硬件架构，现在有个看似可行的趋势是在 Cache 层与磁盘层之间多构建一个 SSD 存储层，在成本与性能之间做一个折衷。

在去年年底的回顾中，我曾大言不惭的说"相信2009 年会是 SSD 爆发的一年"，总体来看，2009 年对 SSD 的部属还谈不上"爆发"。中规中矩而已。

Amazon EC2 对 MySQL 企业版的支持

尽管我不愿意谈云计算，不过 Amazon 这一年在云计算方面还是做了很大的突破，Amazon EC2 上面现在已经可以跑 MySQL 企业版了，采取按照增长付费 ('Pay-as-we-Grow') 的模式让初创公司有更多的选择，这比 SimpleDB 可以说是前进了一大步。这种模式在国内是否可行，考虑到当前内容审查的问题，还有待商榷。

国内 Key-Value 产品

这一年来国内对 Key-Value 产品的研究与运用和国外基本没太大的距离，豆瓣网先作出了不错的表率，发布了 BeansDB 存储系统，这是一个豆瓣风格的 Dynamo 实现，采用类似 Memcached 的去中心化结构。而最近得到的消息说人人网也要将其内部使用的存储系统 Nuclear 开源。相信在新的一年可供参考的 Key-Value 会层出不穷。

其它方面

Hadoop 过去一年中没有太大的变化，上了一点规模的网站都在用，快成了 Web 数据分布式计划的标准组件了。Doug Cutting 出走 Yahoo! 还是带来了一定的影响，不知道今后 Yahoo! 在 Hadoop 方面的支持力度会如何。至于面向列的 DB 发展情况，在过去的一年中进展不大。SQL Server 和 DB2 等方面似乎没什么可圈可点的大事，倒是 PostgreSQL 因为 MySQL 的不确定性而取得了不小的增长。

有一点要补充的是，假以时日，Open Data 或许也将成为一个趋势。

当然，这份回顾有浓郁的个人色彩，有不同意见请留言探讨吧。

--EOF--

本文发表在《程序员》杂志，不过这里的有些许更新。本文写作时，Oracle 收购 Sun 还没有尘埃落定，现在看起来，一切都变化太快。

借助 Complemento 测试 DoS 攻击风险

Fri, 05 Feb 2010 09:38:13 GMT

前几天从 Sourceforge 上的一篇文章了解到 Complemento 这个工具包，其中的 LetDown 用来做网站网络的压力测试，预防 DoS (拒绝服务)攻击还是不错的，起码可以熟悉一些常见的场景。另外，这个工具可以比较方便的嵌入到 Python 脚本中，用来做更大规模的压力测试(注意随意测试是有风险的)。

Complemento 的 HowTo 文档比较完备，可以用作参考。这个工具包现在也已经内置到 BackTrack 这个用作安全渗透的 Linux 发行版中了。

最近一两年，DDoS 攻击在国内现在更加"流行"而且商业目的明显，经常用做打击竞争对手的武器。当然现在也不只是打Web服务器，也可能会打打 DNS 什么的...

其实我非常好奇各个公司的技术人如何应对 DDoS 的，除了拼硬件，拼带宽，或许饭桌和钱是最好的防御手段。

--EOF--

BTW，Nessus 仍然是扫描系统漏洞的最佳工具，居家旅行...必备...

编程语言的选择并非无关紧要

Sun, 31 Jan 2010 09:23:18 GMT

且说前一段时间听淘宝的黄裳讲解淘宝网站架构发展的时候，说起 2004 年底淘宝为何从 PHP 向 Java 转移的事情。为何转换，他阐述了几个理由，其中一个是非常有趣的：当时的 PHP 缺少一个 IDE。而合适的 IDE 能够有效提升规模化软件开发的效率。

我们知道 eBay 在 2002 年的时候也在 Sun 技术团队的帮助下，将整个应用架构从 C++ 迁移到 J2EE 。也就是 eBay 内部所说的 V3 版本(refer)。

最近一件有趣的事情是，据说腾讯的财付通在招聘 Java 方面的高手，"参与系统架构选型"，要把底层架构从 C/C++ 迁移到 Java 架构上来。另外，百付宝的后台技术据说也是基于 C++ 的(最开始的时候只是一两个人写核心代码）。我相信，现在百付宝或许规模还比较小，总有一天，也要面临向 Java 的迁移。这和阿姆达尔定律有点类似，要得到更大的计算能力，就要尽量减少整个系统中的非并行的环节。只是一两个人能搞定的地方，再加入更多的开发人员也是无济于事的，除非，改变协作的模式。

去年接触到的一些国内的电子商务公司，有些已经在进行技术架构上的变迁，当然，多数是从 Windows 平台迁移到 LAMP 平台，究其原因，也无非是成本与效率，而后者，更为大家所看重。当然，也有一些顽固派，比如京东，仍然固守原来的手工作坊技术模式。

如果单兵作战的话，很多程序高手会说，"用什么语言都是无所谓的"。但是如果是团队协作开发的话，用什么语言，影响则是不一样的。对于电子商务网站来说，语言的选择意味着不同的架构路线、不同的开发框架、不同的测试框架、不同的部署流程，最后更为主要的是不同的开发效率，意味着可以把更多的开发资源并入到当前的环节中。

事实上，对于一个高速发展中的网站，每隔18 或 36 个月，几乎总要有一次架构上变革的阵痛。没有这种变革的勇气，意味着以后也不会有人敢做这个尝试。没有这种阵痛，就不会有成长。

变化的节奏最后影响一切。编程语言的选择并非无关紧要，短期看来似乎影响不大，从长期来看，决定最终的竞争结果。这就是我要说的。

--EOF--

大象跳舞

Sun, 31 Jan 2010 09:22:49 GMT

最近看了不少以前不愿意看的书，《谁说大象不能跳舞?》是其中之一。这是一本教科书，讲述的是如何挽救一家走向衰败的大公司。

所处的位置不同，不同的人阅读这本书会有不一样的体会。给我印象最深的是郭士纳初入 IBM 所采取的策略，"我们只有很少的时间用来找出问题，大部分时间、精力和关注点都将用于解决问题和采取行动上。"

问题本质

新的 CEO 上任之前从众多人的建议中就已经抓住了问题的本质(收到众多建议的时候如何过滤重点?)：IBM 不缺乏能人和天才，公司也不缺致胜战略，新领导人要从"战略"和"文化"等方面推行改革入手。这个改革，体现在具体行动上，是后面的"热烈拥抱"计划，说白了，也就是"拥抱用户"，倾听用户的声音，解决用户的问题，赢取客户信任。然后才是财务方面的止血，最后才涉及到远景规划。能从千万重关系中抓住这些关键点，这是核心能力的提现。

对待人才的策略，也就是如何对待现有管理层，郭士纳也是自有一套。在第一次会晤管理人员的时候就主动传递了这样的信号： "IBM 历来是个人才济济的地方...只有如果有必要的时候，才会从外部引入人才"。但是我相信，这样的策略恐怕只有针对 IBM 等少数公司才会有效。多数公司不能照搬--如果问题的本质抓不住的话。(实际上，郭士纳后来还是招聘了不少曾经和他合作过的管理人员进来。)

对于这只管理团队，也不是真的没有问题，当时的 IBM 比较严重的官僚气是存在更多关心公司内部部门之间利益争夺而不是关注竞争对手的情况。任何一家大公司都会有既得利益者，这一点大家都会有共鸣吧。

"大象跳舞"

这本书的书名有多重隐喻。其命名或许和 TIME 杂志的这篇 Can This Elephant Dance? 有关。"大象跳舞"是什么意思? 对于 IBM 这样的庞然大物来说，跳舞意味着优雅、协调，意味着摆脱笨拙。而一旦大象能够做到以这一点，那么竞争对手自然不足为惧，因为问题来自自身而不是外界。

"Elephant Dance" 应该是个证券行业常用语，大致是"大盘股活跃，反复上涨"之意，从这个角度上来说，郭士纳也做到了，IBM 股价在他的任内也是一路上涨。

--EOF--

乱翻书，不求速进，但求有所得。

从 7-Zip 的预设格式说起

Sat, 30 Jan 2010 09:22:13 GMT

在 Twitter 上看到笑来和几个推友说起关于提供下载为何不用更通用的 ZIP 文件格式而用 7z 的格式(refer)。这个倒是挺有趣的话题，刚好我也是 7-Zip 的用户，对这个不习惯也由来已久了，也一直不喜欢这个方式。

7-Zip 的默认压缩文件格式为"7z" (扩展名是 .7z) ，就是这个微小的差异给用户添加了很大的麻烦。设想一下，你用 7-Zip 压缩了一个文件，扩展名为 foo.7z ，传给了你的朋友(非IT人士)，而你的朋友用的是 WinRAR，这是压缩软件市场上的主流，他看到这个格式之后，他会如何反应? 换个应用场景，如果一个普通用户，从网络上下载一个软件，下载完毕之后发现默认没有软件能打开这个 .7z 为扩展名的文件，他会如何做?

必须要承认，7z 压缩格式有很多优点，而 7-Zip 是个很好的压缩工具软件，但在预设格式上的这个事儿，不折不扣的是在挑战用户习惯。或许有人支持这样的做法，一个支持观点是 7z 格式压缩比更高。这是个很好的理由，不过，那么一点点的压缩比收益，考虑到当前个人用户所用设备的存储能力以及网络支撑能力等，对于单个用户来说，无法抵消使用习惯带来的麻烦。除非全世界都是 7-Zip 的用户，很可惜，现在的 WinRAR 仍然是市场绝对的主流，而 Zip 与 RAR 格式也是事实上的标准。另一种支持观点是现在所有主流压缩软件都支持 7z 格式了，所以使用是合理的。的确，主流压缩软件可能支持了，但是，绝大多数计算机用户不知道这个事实，和他们不知道没什么本质区别。或许，会有人认为这是 7-Zip 发展用户的一种独特的手段，如果是的话，那恐怕这是最拙劣的营销方式，形同绑架用户一样。

如果不是市场的绝对主导者，任何挑战用户习惯的的行为无疑是危险的。相比 WinRAR 和 WinZip 来说，作为开源软件的 7-Zip ，只需要使用习惯和前两者一样，而功能甚至都未必那么强，就会赢取大量用户。但是给用户习惯設置障碍的做法无疑是不可取的。如果有人不同意，那么还记得"兼容机"这个词汇吧 ?

开源软件应该多考虑使用习惯上的"兼容性"，做网站也是一样，有多少人在设计网站的过程中真的尊重用户的遗留习惯? 而你是如何做的呢?

--EOF--

信息过载

Fri, 29 Jan 2010 01:15:53 GMT

先说一下我的结论：信息过载(Information Overload)是个伪命题。只要经过足够的训练，人应该可以接受更多的信息，多到无法想像。尽管这样，我还是相信，对信息的处理还是会让很多人困扰。

如果要减少信息对自己带来的困扰，有哪些可取的途径呢?

克服信息贪婪

你想得到更多，实际上恰恰相反，越想得到更多，真正得到的有质量的内容就会更少。尝试克服对信息的贪婪，有些信息不去主动获取对你影响也会很大。

适度使用工具

工具有的时候时候只是为了减轻个人的负担而存在。不能因为有了工具而变本加利的陷入更多的信息当中。比如，Google Reader 是个不错的 RSS 阅读工具，合理使用会减轻阅读过程中的交互。可如果订阅了过多的 RSS ，反而会使信息泛滥。

现在从 Google Reader 的数据趋势看起来，"推荐"要远比"过滤"有效。通过用户的人工推荐形成的信息流要好过人工设置的过滤方法。说起"社会化推荐"，国内玩聚的团队也在做着不错的尝试。

远离信息噪音

离开门户新闻频道，对比一下：一天看 1000 条新闻与一天不看任何新闻，都不会影响你的生活。所以，远离新浪这样的新闻门户对自己是最大的解脱。当然终极手段是远离网络。我相信看我 Blog 的人都是网虫，而网虫的信息过载都是网络带来的。

另外，我以前很少点击 IM/eMail 里面传来的连接(最近一年倒是对这方面有所放松)。很多话题帖其实没什么看头。不过是满足以下好奇心而已。

远离社会网络

现在可以说满大街都是 SNS 。登录任何一个类似站点，都是满屏幕的状态信息，实际有价值的信息比例非常少。我也尝试了不少网络服务，唯一一个坚持在用的就是 LinkedIn 了。

到现在为止，还没有说到 Twitter ，对于 Twitter，现在说什么都为时尚早，或许不应该说，因为国内不能正常访问这个也许不存在的网站...

其实对于有价值的信息，多少算是过载? 是信息过载还是获取信息的途径超载? 恐怕很难界定，在互联网时代，你一个月接触的信息量要比没有网络时候一年的还要多。但是这所谓的负载是否真的带来了严重问题?

这是 2 年前没写完的一个帖子，今天捡起来发现还有参考价值，做了一点补充，发布出来吧。

--EOF--

太阳升起太阳落下

Wed, 27 Jan 2010 09:15:24 GMT

2010 年 1 月 21 日消息，欧盟已经无条件批准 Oracle 收购 Sun 的计划。接下来，尽管在有的国家或地区还会有所纠葛，但 Oracle 已经扫清了收购 Sun 的主要障碍。一代 IT 巨人 Sun 从此落幕。

(via)

人们谈论起 Sun，总要说起这家伟大公司曾经的辉煌。Solaris、Java、SPARC、NFS......

很多人知道 Sun 是 Stanford University Network 的缩写，不过 Sun 的创始人并不全来自斯坦福大学，虽说 Vinod Khosla 、Andy Bechtolsheim 与 Scott McNealy 三个斯坦福的毕业生是 Sun 的发起人，稍后加入的 Bill Joy 大神则来自伯克利，他尽管不是发起人，但也是公司创始人。对于创始人中的 Andy Bechtolsheim ，必须要多说一嘴，多年之后，是他给了 Google 两位年轻的创始人第一笔 10 万美元的天使投资。

二月创建的公司，当年七月份就已经盈利，这是因为 Andy Bechtolsheim 在成立公司之前就已经设计处了 Sun 的第一代工作站。Sun 工作站在当时可以说无敌于业界，十余年间就卖掉了 1 百万套。而到了 1995 年 Java 推出的时候，简直让业界疯狂，我还记得当初的报纸写到"几乎一夜之间互联网动了起来"，这是 Sun 对业界最大的贡献。尽管 Sun 的品牌在将来或许消失，但是 Java 仍将继续改变这个世界。

公司创建四年之后成功 IPO，股票代码 SUNW ，最早代表 Sun Workstations ，这是 SUN 早期现金牛产品，后来解释为 Sun Worldwide，而到了 2007 年，则更改为 JAVA。这个更迭多少意味着 Sun 的无奈。Solaris 工作站已是明日黄花。在第一波互联网泡沫破灭前，Sun 市值一度超过 2000 亿美金，这是个惊人的数字。互联网上运行的服务器有 35% 跑在 Sun 的服务器上。彼时，Sun 自诩 "We are the dot in the .com"，可惜 Sun 后来的志向 "We're the Dot in Web 2.0" 未能实现，壮志未酬。

除却 Java 之外，Sun 在其它方面的产品创新几乎都有 Bill Joy 的功劳(其实 Java 项目也有他的推动)，这位号称在一个周末重写 BSD 内核的大神，在 Unix 操作系统领域带来惊人的成就，对业界产生无与伦比的影响，甚至他一个周末写就的编辑器 vi 都是很多 Unix 用户离不开的工具。Bill Joy 在 2003 年从 Sun 出走(据说与麦克尼利不和)，他的离去给 Sun 蒙上了一层阴影，从此后，Sun 在 Unix 方面鲜有有创新(这几年数来数去也只有 ZFS 算有点影响力了)。Bill Joy 在离开 Sun 之后转投纳米技术、机器人学等领域，在软件技术方面未有大的动作，但说不定这天才什么时候杀个回马枪呢。

Sun 创造了 Java ，却无法从这个金矿上赚钱。以往的分析往往认为 Sun 卖硬件卖得太舒服了，没能够及时转型。这倒的确是很重要的一方面。而另一方面是开源社区(甚至 IBM )都比 Sun 更能赢得用户的心。而 IBM ，更是抛出了 Eclipse(日蚀)项目以及后来联合其它公司成立了 Eclipse 基金，这实际上是用免费策略断了任何公司想在 Java IDE 上盈利的念头(当然主要针对 Sun)。Sun 在硬件服务器领域和 IBM 争夺市场，而 IBM 则在 Java 上断了 Sun 的后路，除此之外，IBM 亦大力扶植 Linux，甚至鼓励用户将大型机迁移到 Linux 环境下，一方面节约遗留系统维护成本，一方面硬件照卖，这是很高明的一招。

反观 Sun ，在 Linux 渐成燎原之势的时候，应对战略相当的失误，与 IBM 拥抱开源截然不同的是，Sun 采取冷眼旁观。等到 Jonathan Schwartz 主政时期，力主推出 OpenSolaris 策略虽说是一步好棋，但是时过境迁，为时晚矣。试想如果在 Linux 崭露头脚的时候，Solaris 就能够开源或者是 Sun 能援助一臂之力，那说不定就是另一番天地了。

Sun 在收购策略上一直是走弥补硬件产品线的策略，大多数收购并不成功，收购 StorageTek 花费的 41亿美元似乎是绝对的赔本买卖。收购 MySQL 虽说被业界看好，甚至 Jonathan Schwartz 称收购 Sun 是"现代软件史上最重要的并购案"，可没想到仅仅一年的时间，Sun 自己也被卖掉。到现在，MySQL 仍前途未卜。

说起 Sun ，当然绕不开执掌 Sun 帅印长达 22 年之久的斯科特·麦克尼利(Scott Mcnealy)。Sun 成也麦克尼利，败也麦克尼利，说到底，他毕竟是一个商人，一个刚愎自用的商人，对于 IT 大势的判断仍然比盖茨差几个段位。Sun 的四位创始人当中，他其实是没有任何技术背景的。"网络就是计算机" 据说并不是他提出的想法，而是 Sun 的第五位员工的灵光乍现。麦克尼利给中国用户的更多印象是对微软的抵制和对盖茨的敌意，这一点倒是和拉里埃利森是一路人。一个人成功的时候，大家看到的都是他的光环；一旦失败，大家都会去指责他的缺点。

现在有一个公司颇像辉煌时期的 Sun ，那就是 Google。

"一代人来，一代人走，大地永存，太阳升起，太阳落下，太阳照常升起。"

--EOF--

说起 Bill Joy ，在 2000 年曾经发表过 2 篇影响深远的文章：

Why the future doesn't need us
Design For The Digital Revolution As computers change the world, we need to make sure the new world works for humans.

第一篇广为流传，而第二篇似乎少为人知。这两篇文章现在看来，仍然像一位先知对未来作出的预言。这一年，Bill Joy 46 岁。

Oracle 代码中的 Radiohead 歌词

Tue, 26 Jan 2010 01:17:02 GMT

这是我接触 Oracle 这么多年来最有趣的一件事儿。

刚才在邮件列表中看到一位叫做 Dennis Yurichev 的安全研究人员提及在 ORACLE.EXE 这个文件代码中包含有 Radiohead 乐队 Creep 这首歌的歌词，立刻验证了一下，果然：

$ strings oracle.exe | grep radiohead
I'm a creep, I'm a winner, what the hell am I doing here.
I don't belong here - radiohead

没错，真的是 Creep 这首歌的歌词。Radiohead 颇受 Geek 程序员的喜爱。看得出加入这段代码的程序员对这份工作并不是很满意..."what the hell am I doing here"...

另外，原歌词是 I'm a weirdo(古怪的人)，而不是 winner ，估计是随手写错了。

这位 Dennis Yurichev 还给出了伪代码：

#define STRING "I'm a creep, I'm a winner, what the hell am I doing
here.I don't belong here - radiohead" 

kfasSelfTest_update()
{
       kfasOpen (...);
       somestruct.somevalue=STRING;
       kfasUpdate (somestruct);
       kfasClose (...);
       newstruct=kfasOpen (...);
       if (strncmp (newstruct.somevalue, STRING, ...)!=0)
       {
               // raise error 99999?
               kserec1(99999, 1, ...);
               kserec2(99999, 1, ..., STRING, 1, ...);
               return 0;
       };
       kfasClose (...);
       return 1;
};

据说是 10.2.0.1 之后才有，可能和 Oracle ASM 特性有关，不知道这是 Oracle 哪一位程序员的杰作...

--EOF--

我最喜欢的 Radiohead 作品还是 Paranoid Android ...

Firefox 频繁 Crash 的避免

Fri, 22 Jan 2010 09:17:21 GMT

前几天 Firefox 升级到 3.5.7 之后频繁崩溃，导致我也很崩溃。说也奇怪，Firefox 这个版本据说主要是解决以前版本的稳定性问题，还说要修复 Top crash 呢，可没想到在我的机器上反而更加的不稳定。开始猜测是一些扩展(Extension)升级带来的问题，把所有的扩展禁止掉，仍然 Crash。另外怪的是，即使使用的时候没问题，一旦退出 Firefox 的时候还是会提示软件有问题而崩溃。那个提交 Crash 报告的界面都快让我条件反射了。

因为 Firefox 是日常工作首选的浏览器，加上翻墙越脊的也很顺手，还不能弃之不用。昨天痛定思痛，决定仔细分析一下到底怎么回事。说也惭愧，尽管是 Firefox 的老用户，倒是没注意到 Firefox 对于 Crash 的反馈处理还是有一套比较不错的机制的。通过 Firefox Crash Reporter ，用户能够比较快速的定位到自己的问题。

提交了崩溃报告之后，在浏览器地址栏输入：

about:crashes

然后点击所提交的 Report ID，经过联机分析之后，会给出很有价值的提示。可以对比多组结果，便于最后确认。查看Crash Report，我的浏览器的两个主要问题是：

501429 NEW Gmail tab crash while closing it's tab (caused by Google Talk Plugin)
531551 NEW Firefox 3.6 topcrash due to old Acrobat Plugin (nppdf32.dll)

问题和插件(Plugin)有关系，和扩展倒是关系不大。罪魁祸首一个是 Google Talk Plugin ，一个是 Acrobat Plugin，通过 Tools-->Add-ons-->Plugins 将这两个插件关闭。重启动 Firefox ，观察，问题不再复现，泪奔。

尽管不是扩展问题，但还是仔细看了一遍可能会带来问题的 Problematic extensions 列表，看完之后，把 IE Tab 换成了 IE Tab lite。

几点感慨：

对于客户端工具，如果追求扩展能力与第三方开发友好性，那么必然损失稳定性。而这个稳定性的损失如果不被用户理解，对产品的推广是比较危险的。
国内火狐团队在做什么? 至少作为用户，不知道，也打算用"针对国内用户定制"的产品。
其实很多时候解决办法就在那里，只是我们视而不见。

--EOF--

今天已经将 Firefox 升级到 3.6 了，目前稳定性尚可。

有来自火狐中国的朋友留言到"在将来版本的火狐中，整个插件体系被重新设计，所有的插件会在单独的进程中执行，不会影响到Firefox的执行"。这是一个好消息。

Google带来的科普事件

Mon, 18 Jan 2010 01:39:43 GMT

在看到 Google 的公开信后，我在 Twitter 上说"宁与玉碎不为瓦全。也好"。之后一直想写点什么，不过在这个时候，阐述对这件事情的看法，很难不被淹没到口水战里。

揣测 Google 这样做的动机与商业目的对我们大多数人来说没有什么实际意义，不如让我们把讨论的焦点放在这次事件背后的问题上：这次实际上是客观承认了"内容审查"（refer: Censorship）变本加厉的既定事实，也让更多人知道了这一现状对社会带来的负面作用。对互联网的不当隔离与审查是不符合普世价值的，尤其不符合人民群众对于"先进生产力的发展要求"，是民众无法认同与接受的做法。Google 对于互联网来说是先进生产力的绝对代表者，如果将其拒之门外，那么可以肯定这无助于社会的进步。

如果说出于政治目的的审查有其可解释性，但是为了"倒洗澡水而把孩子也倒掉"则是极其错误的做法(当然，表面上都是以一些类似"保护未来的花朵"为借口，这和过去那些重大对立冲突的导火索何其相似也)。这种错误的做法还包括前一段时间的 IDC 整顿、域名整顿等一系列事件乃至要推行网站白名单的传说，这些都是操作层面上的极度不当。"疏"与"堵"，历史给我们带来无数次的经验教训，后者无疑是饮鸩止渴。我不知道在皇帝的新装的那个故事中，小孩喊出来那家伙其实什么也没穿之后，小孩受到了什么待遇，也不知道皇帝是否再次上演新装的闹剧。是在我们这里，似乎这样的闹剧无时无刻都在上演。

上网十年，从一个乐观者变成了悲观者。历史有的时候是进一退二，有的时候是以退为进，还是让我再乐观一次吧，期待 Google 这次准备撤离会唤醒我们更多的思考，给我们带来哪怕是一点点的进步。

--EOF--

更新：

在审查过程中造成的直接和间接的经济损失似乎少有人关注，不知道是否有经济学人关注这一领域。如果有人算一笔经济账，恐怕会是个惊人的数字。而有关部门相信也是投入了大量人力物力的，这也是不小的资金开销。

公司 BLOG 运作经验谈

Fri, 15 Jan 2010 01:40:20 GMT

在过去的 18 个月里，我一直用 20% 的时间在运营支付宝的官方网志 - 支付志，不要误会，我说的 20% 是 100% 之外的时间。

因为在兄弟公司中第一家推出官方 Blog，可参考的同行案例并不多，借鉴了一些 Google 运作产品 Blog 的大致思路和策略(尽管没有明确的策略)。所以，更多只能是摸石头过河，一点点的进行尝试。这里总结一点运作的经验，以供后来人参考。

避免陷入争论

对于用户的疑惑或者质疑，做解释说明(To make plain or comprehensible)，不要辩解，也不要争辩。其实总有一些话题一些客观因素导致的现状是很难迅速解决的，比如"网银对非 IE 浏览器的支持"，一旦就某些观点讨论起来，很容易陷入论战。身处漩涡是一件危险的事情，更好的办法是说明，中立性的的说明。在这里我也建议如果遇到恶意攻击，最好的办法当然是保持沉默。

传递必要信息

说是"官方"，但不意味着事无巨细报道公司的一切，也没有必要专写一些小道消息，有关公司文化或者公益活动等事宜是有必要进行宣传的。而有关产品更新，有关用户问题的跟进解决是有必要进行说明的。而我个人比较关注的是一些被忽视但是对用户会价值的地方。

关心有用指标

我知道有很多公司的官方网志是有专人维护的，而且，主管会定下来很多莫名其妙的指标给维护人，比如访问人次、PV 等等。其实这些指标可能会背离做这件事情的初衷。产生价值有多种渠道和方法，通过 RSS 、转载等多种渠道更能够有效的传递信息，未必一定要用户总在本地阅读，而用户阅读的多寡也不意味着信息传递价值的大小。所以，对于支付志来说，重要的是对用户传递产品信息与公司理念，前面一两个月我还是关心访问人次，到了后期，我更关心的是内容引用率的跟踪，以及引用本站内容的网站所产生的影响。

制定内容策略

在准备运行的时候，针对内容制定了如下几条原则，现在看起来依然适用：

我们可能会犯错误，但一旦发现会尽快纠正；
所有评论在通过管理人员审核后发布，并且将在适当时候尽可能快地回复评论；
我们将尽可能对引用的文章和内容给出初始连接；
对所有不同的意见我们都将给予尊重。

这里面要说明的是对待留言的态度，我对留言的处理先行定下策略，实际操作中有章可循。

积极对待反馈

官方 Blog 的维护过程中，会看到非常多的用户反馈，而有些典型但是没有引起重视的问题要第一时间转发给内部团队，积少成多，长期下来看，这个收益是非常可观的。也有用户会提供针对某些长期问题的自行解决办法，也是非常值得参考的。有的时候，可能从有些角度看，只是小问题，但是对单个用户来说，都是大问题。不要忘了蝴蝶效应，小问题，可能也会带来大影响。这也是我在开始游说开辟 Blog 的一个出发点。

善用媒体工具

适当利用 Twitter (@Alipay)或是新浪微博( @支付宝，已经有超过 5000 人关注了) 等工具，面向不同的关注群体做一下信息广播也会有不错的效果。

结束语

必须要说的是，尽管获得了一点经验，但实际上现状距离目标还相去甚远，还有太多不尽人意的地方，只能尽力为之。

--EOF--

Second Life 升级 MySQL 的案例参考

Thu, 14 Jan 2010 04:00:26 GMT

尽管前一段时间有媒体报道 Second Life 已经悄无声息的衰败，不过林登实验室的人也还是很忙，这不，刚把一堆 MySQL 服务器进行了升级，还进行了详尽的经验总结(Refer)。

原有的 MySQL 都是跑在 4.1 版本上（4.1.11），在 2007 年的时候计划升级到 5.0 版本，不过遭遇到了...嗯，失败。当时的 5.0 版本不够快。被迫回滚。之后中心 DB 一直运行 4.1 的版本，而 Slave 和其它 DB 都逐渐升级到了 5.0.51 的版本。

用 Python 和 RabbitMQ 写了一个支持 MySQL 协议的分布式压力测试框架，该工具用于捕捉产品环境中的流量并在测试环境下回放模拟，以便更加接近系统的真实运行情况。此外，使用了 Maatkit 工具包用于验证 SQL 语法以及数据。

4.1.11 与 5.0.51 的对比测试表明，5.0.51 比 4.1.11 要慢不少，经过与 Percona 的沟通后，决定升级到 5.0.84 。从我几天前这份 MySQL 版本的调查看， 5.0.84 也是目前用户采用比较多的版本。初步测试 5.0.84 的性能和 4.1.11 的性能相差无几，随后测试打了 Percona 与 Google 的补丁的版本，未作调整下收益不大。一些关键的参数需要作调整以便得到更好的 I/O 能力（要注意如果是 SSD 环境下 innodb_read_ahead 参数要做一点调整，16K 还是 32K ? 要测试才知道）。此外，将 Binlog 放到单独的块设备上，得到 10% 的提升。值得注意的是，默认的系统 I/O 调度器不是很适合，切换到 Deadline 后得到了 15% 的提升(参考 I/O 调度器与 DB的关系)。

经过一番折腾，峰值并发达到了14-16k QPS，只用了 80% I/O 能力，而 4.1.11 最高是 8200 QPS，5.0.51 最高 11,500 QPS，看到这里，猜测他们费这么大劲升级也就是要得到更好的并发能力?

然后是对代码的验证上，包括 SQL 在不同 DB 版本上的正确性以及 SQL 运行的效率，后者也就是执行计划稳定性。这两个测试主要是用 Maatkit 来做的。对于后者，我个人觉得他们的验证过程还有点黑盒子，或许应该关注到具体的 TOP SQL 才会更稳妥一些。此外，复制数据的一致性检查也有必要加以重视。

这台中心服务器数据量大约 250GB。当前所用的服务器是 8 核 Xeon E5450 CPU，64GB 内存，400GB 的直连磁盘(RAID 10)，接下来有计划表明要迁移到 16 核的机器上，并且将启用 SSD 。

总体来看，对 MySQL 升级的过程其实也不是那么简单的，也要有个方法论与好的方案才会保证最后升级的成功。

--EOF--

延伸参考：Percona 针对 MySQL 5.0.84 的 Patch 说明。

Movable Type 与 WordPress

旧金山第一天续

Sun, 11 Oct 2009 10:04:43 GMT

要说在美国最大的便利是什么? 要我回答就是：无障碍访问互联网。访问一些人民群众喜闻乐见的站点不需要翻墙了。就为了这个，也值折腾一回的了。所以对我来说，游玩的意义可能还不如上网价值大。

美国人民生活的富足是显而易见的。即使金融危机重创了美国，人家也还活得比我们滋润。我们就别替人家担忧了。

好多人都在给我推荐渔人码头的Crab House，说是大螃蟹非常不错。可是，我是不吃海鲜的人，这倒是一大痛苦。要不我买单看别人吃过瘾一把好了..

旧金山无线网络信号的确随处都有，不过一般都要跳转一次确认才可以。这倒是给我带来了一定的麻烦。讨厌的是，尽管有，都很慢...

住的这个小宾馆号称环保，结果我根本没带牙具，还是要污染环境一回了。隔音不好，鸡犬相闻。

手机漫游没弄明白，到这边除了网络，基本和外界失去联系了。

我的 Twitter 账户: Fenng

--EOF--

旧金山第一天

Sun, 11 Oct 2009 10:00:09 GMT

今天(我也不知道这算是一天还是两天)比我想象的要顺利许多，一个人摸着杀到了旧金山。

起飞前在上海机场书店转悠，挑选了半天，买了一本《追风筝的人》，没想到这本书还真让我打发了三个小时的时光。这是一本关于自我救赎、亲情、阿富汗苦难的作品，远远超出我的期望。从上海起飞的时候感觉不太舒服，一直到降落到东京机场才好。降落前远远望去，日本的房屋都比较低平，机场很干净，最大的缺点是找不到免费无线，所有的接入都是要收费的。本来倒是想购买一下做个体验，但是那个流程实在是繁琐，还是作罢。

(东京机场的休息区)

停留了两个多小时，从日本起飞的时候上来很多日本人，叽里呱啦的。尤其是我前面一派的三个青年男女一路上非常麻烦(男的后现代、女的化妆很抓狂的那种)，不是弄点噪音出来就是按服务铃找空姐来，反正每次都是那个日系空姐过来，折腾了几十次不止。迷迷糊糊睡了醒醒了睡，把提供的视频节目翻看了遍。

机场入关检查还挺慢，足足等了几十分钟才轮到我。用我三句半的英文对付了过去。得到的一个经验是下次最好把电子客票行程带着，免得麻烦。出来的时候看到过道上都是 Oracle 的广告，广告的语气很拉里埃利森。出了机场，感觉眼睛有点不够用，什么都很好奇，都想仔细看看。

下午顶着倒时差的头昏脑胀出去转了一下，Google 街景是个好东西，给我带来很大的便利性。步行出去，走访了本地的电脑硬件零售点 -- 也就是苹果专卖店，主要是来踩点，真是人多、钱傻、速来啊，在美国，苹果也差不多白菜价了。

走在旧金山街道，给我的第一印象是鸽子多，而且都不怕人。第二，路口没有斑马线，就是随便划两条线，但几乎没有闯红灯的。不管开着好车赖车(很少看到公务车)还是那些车里放着摇滚乐的黑人兄弟开的车，在路口都是优先避让行人。

隔着挺远就听见男高音在飘荡... 这家伙肺活量还挺足。右边的店是普拉达专卖店，依稀可见橱窗里的模特照片，胖子旁若无人，很投入，不时还有鸽子飞来飞去助兴。左边靠近镜头是他的CD和捐赠箱，还有一个重要的道具是他的压阵的胖老婆。老实说，唱的很一般。

快到苹果专卖店的时候，听到前面敲锣打鼓震耳欲聋，心想，苹果平时也和国内商场一样搞什么促销活动? 走近一看发现不是，原来是一群黑人兄弟在表演。要说这噪音这么大，也没个城管出来管管...

阳光真好啊。接续溜达，凭着对Google街景的记忆走到了联合广场，这个广场不大，但是名气不小。有在这里无所事事的流浪汉，有走累了的歇脚的游客，有晒太阳的本地人，有即兴的艺术家...当然还有抗议者。

右边拿着喇叭的那位大婶乍一看还以为是华人。抗议者也都是打持久战的，累了就歇一会儿，彼此闲聊几句。广场上你方唱罢我登场，管保有节目可看。人家演说时英语还真是字正腔圆，抑扬顿挫，十分好听。此外，演讲内容不打悲情牌。算得上有组织，有纪律。

这位抗议者嫌举着牌子太累，人家是背着的，做了一点技术革新。在国内看到这些较少(都直接被抓走了)，还是挺新鲜的。

到处都是鸽子。阳光打在身上，有那么一瞬间，觉得自己非常羡慕这些鸽子。

广场旁边是一家书店，走进去细致参观了一下，计算机类图书并不是很全，或许遭受网络冲击太大了。书店硬件设施很一般，供用户查询的电脑显示器还是纯平的，抖动不停，至于网络速度，那叫一个慢。

为了被直接认出来是游客且是土鳖一枚，一路上采取了尽量少拍照的策略。而且，走着走着发现护照没了，心情跌到谷底(回来后才发现是虚惊一场)，顿时没有了闲逛的心情，打道回府去也。

--EOF--

DBA notes

杭州五年

暂缓迷恋 Cassandra

苹果为何不在 iPhone、iPad 平台支持 Flash

苹果往事

虎年快乐！

民生银行的系统事故

2009年数据库技术领域回顾

借助 Complemento 测试 DoS 攻击风险

编程语言的选择并非无关紧要

大象跳舞

从 7-Zip 的预设格式说起

信息过载

太阳升起 太阳落下

Oracle 代码中的 Radiohead 歌词

Firefox 频繁 Crash 的避免

Google带来的科普事件

公司 BLOG 运作经验谈

Second Life 升级 MySQL 的案例参考

Movable Type 与 WordPress

旧金山第一天续

旧金山第一天

太阳升起太阳落下