ftofficer|张聪的blog

http://www.cnbeta.com/articles/69450.htm
美国洛斯阿拉莫斯实验室科学家说,能为2万户家庭提供用电的微型核电站5年内有望上市。

这个来自CNBeta的新闻，可信度先不说，会不会带来恐怖袭击也不说，2500万美元每台的定价是不是靠谱也不说，只是说这个点子就让人觉得有趣。

想想以前，大家自己要顾及自己的能源，需要自己砍柴烧饭，自己买油点灯照明；后来有了电网和电站，于是能源的生产、传输和使用就分开了，大家在使用电力完成照明和烧饭的任务之外也出现了逐渐多样化的能源使用者，出现了大量的电器可以满足大家的需要。但是这样的模式也有自己的问题。一个就是巨大的传输损耗，另一个就是电站的设计和运营仍然没有分开，所以电站的运营成本仍然需要将设计成本计算在内，而且一个设计很难复用在其他电站用来降低成本。

现在有了这种可以量产的核电站，也就解决了这样一个电站的设计和运营的问题。如果电站的设计成本可以因为复用而降低，那么部署更多的电站，实现更分布的电网也就成为可能。而购买了电站的人或者组织只要负责运营电站，所以他们也可以把更多的精力放在优化运营上面。关键是要有一个电站的标准，所有符合标准的电站都可以加入电网。于是电力这个系统也就将原来的电站细分成了电站设计公司和电站运营公司。说不定可以极大降低电力的成本，这样没准更多有趣的，但是需要大量电力的应用就可以得到商用，比如说，粒子级别的物体分解和重组？

和电力系统向对应的一个行业就是计算机行业。人们常用的隐喻就是，早年大家需要提供自己的在线应用，需要自己买机器，自己拉网线接入互联网，自己维护机器，这相当于大家自己砍柴烧火做饭的年代；后来有了主机托管，于是一部分维护成本就转移到托管商那里，并得到一定的优化从而降低成本，这相当于管道煤气烧火做饭，虽然能源的生产和分发得到了一定程度的分工，但是能源的提供方式不够通用，所以管道煤气也只能用来做做饭、顶多能用来烧洗澡水，托管也一样，这种主机通常用来托管网站，很少见到有人拿它作其他应用，比如做一些科学计算等等；再后来有了Amazon的云服务，还有Google的GAE，直接将存储和计算能力出售，而不在乎这种计算能力来自哪里，这相当于大家开始逐渐用电力通过电热炉来做饭烧水的年代，因为计算能力和存储相对更抽象，也就有人开始拿它做别的，比如做科学计算。

那接下来，如果像我想象的电力系统的未来一样，将云平台的设计和运营分开，有专门的云平台软件提供商，专门做云计算软件，运营交给其他的公司去做，如果到时候提供GAE服务的提供商和现在的托管商一样多，竞争起来，价钱说不定就会大大降低了。做软件让别人运营，这个听起来很像是某$公司的做法。

—
以上纯属扯淡，如有不满，敬请提出。

— 先写一些废话 —
LiveSpace的评论系统做得不是一般的烂……
所以，如果要评论，去我的xiaonei的主页上面评论吧。这个方面社交网络还是要更擅长一点。
— 废话 完 —

旧金山印象

今天按照计划去旧金山游玩一下。可惜天公不作美，从早上就阴雨连绵，而后来也证明，阴雨确实影响了这次的游玩。在此再次谢谢带我去旧金山的Jason帅哥。:)

实际上这次进入旧金山的交通工具是BART，BART全称是Bay Area Rapid Transport，即湾区快速交通，其实就是轻轨+地铁。Jason开车到了旧金山机场附近的BART站，然后$4直达旧金山。因为天气不好，所以没有去金门大桥等景点，只是步行在旧金山市内转了一下。这个城市基本上是1906年大地震之后重建的，距今也有100多年了，所以城市给人的印象就是古旧，没有太多的高层建筑，没有太多光鲜的大楼，但是相当的干净，而且看起来所有的房子都很坚固，也许再过100年也不会有问题。论城市的历史和对古老建筑的保护，国内最接近的也许就是上海了，但是上海的干净程度显然不如旧金山。

这个城市对于古老东西的保护也是非常好的，传统的Cable Car，即有轨电车，现在也是一个游览景点了。这种车又被称为叮当车，就是因为开车的时候会叮当响一声。

旧金山的叮当车

旧金山的市中心，联合广场。这也是旧金山高层建筑集中的地方，但也基本上仅在这一片了。

顺便拍到的在联合广场附近巡逻的警察帅哥。帅哥也很配合地摆出这样一个姿势，有够酷。

联合广场中央正在装扮得圣诞树。虽然还有六个星期才到圣诞节，但是这个国家的人们已经开始动手准备他们一年当中最盛大的节日了。

旧金山的小街，古老、狭窄但是并不显得拥挤。从这张图上也能感觉到旧金山著名的>40度的上坡路。

是的，到处都是这种上坡路，陡峭得很。

旧金山的第一高度。但是我不知道这栋楼叫什么名字。据说是个博物馆吧。

旧金山的教堂

旧金山China Town入口，牌坊，上书国父的“天下为公”四字

China Town当中的吊角楼

还有钟楼

从这张图可以看出来，旧金山其实就是一个建在V字形山坡上的城市。远方因为天气原因，云雾缭绕，反而看起来很有感觉。

为了纪念1906年旧金山大火当中牺牲的消防队员而修建的Coit Tower

通向这座塔的台阶上，每块石头上都刻着一个消防队员的名字

之后去的地方还有著名的渔人码头。
To be continue…

停了两天，是因为倒时差的缘故。之前周末的时候，因为每天都在到处晃，所以没有感觉出来困，前两天开始感觉受不了了，每天到了晚上8点左右就开始困的要死，毕竟相当于正常作息情况下的通宵到第二天中午。还好今天已经开始习惯了，所以晚上回来继续写。

时间还是上周日，从Google园区出来，便去了Stanford。加州湾区有不少大学，大多都很有特色，但是例如Berkley之类的距离太远，所以就挑了最近的Stanford了。拍的照片不多，所以就选几张贴了。主题不是Stanford的景色，而是加州的天空。

Stanford“大门”外面的一片草坪。说是大门外面，实际上Stanford根本没有围墙……

著名的Memorial Church外面的小广场，绿草红瓦蓝天白云，怎么说呢，我从来没亲眼见过这么清澈的景色。

Stanford里面随处可见的棕榈树，很多都长到了几个人合抱的粗细，估计要几百年吧

在胡佛塔顶上的观景台拍摄到的旧金山湾区

这是另一侧的湾区。

照片就贴这么多。

这个周末去旧金山，去看看传说中的金门大桥。这个地方如果不去拍一张到此一游照的话，我都不好意思说我来过了。:P

继续昨天的写。

既然来了山景城，肯定要去Google看一下的，毕竟很大程度上山景城这个地方是因为Google才逐渐变得出名的。天公也很作美，周六还是阴雨连绵的，周日却是一个大晴天。于是搭Jason的车去Google的园区转了一下。废话少说，上PP：

Google园区的小路，公园一样的布局

Google的某栋楼

Google员工种的花圃，里面有很多相互缠绕的藤本植物，取名“The Growing Connection”。Connection对于Google的意义，自然不用多说了吧。

园区里面的恐龙骨骼化石——没错，就是恐龙骨骼化石

流动理发车。-_-b

园区里面随处可见的松鼠，一点都不怕人。这只还很识相地抬头盯着镜头，摆出一副很上镜的pose。

这只松鼠嚣张的多，大摇大摆地坐在路中间，即使镜头在不足一米之处对准了它，也只是往这边瞄一眼然后继续享用它的美食。

Google Android，一个三人高的机器人模型，脚下还有一条狗……

其实你可以把这条狗搬来搬去，拿来当马骑

和Android的合影

园区的风景，绿色的草地、红色的枫叶、加上蓝天白云，要不是我摄影技术太差，基本上可以拿来做桌面了。

既然来了加州，这边著名的几个大学也是非去不可的。Stanford因为距离这边最近，所以接下来便去了Stanford。

To be continue…

因为公司项目安排，我被送到美国1个月支持某项目，从11月1日到12月1日。北京时间11月1日晚上从上海出发，乘坐印度Jet Airway的飞机从上海飞到旧金山，落地按照当地时间计算，比起飞还早——所以我的11月1日有41个小时，:)。当然了，回去的时候估计就要丢失一段时间了。飞机从西向东飞，跨过国际日期变更线，所以可以追上地球的昼夜界限，也就是说我上飞机的时候天是黑的，飞了一段之后变成白天，落地之后再次变成黑夜——也就是说我的11月1日有两个白天和两个黑夜，:)。

在天上的时候拍到不少漂亮的云，更多的在Picasa相册里面。

Jet Airway的飞机是波音777，看起来像是新飞机，座位间距也足够大，机上娱乐设施也很齐全，空姐也很nice。唯一不爽的是，飞机是途经上海的，起飞地点是孟买，所以飞机上大部分都是印度人，所以咖喱的味道充满了整个机舱——而且食物提供除了西餐就是印度餐，也更加剧了咖喱的味道。下了飞机，直到现在，我衣服上还有一股咖喱味道。

然后落地之后，旧金山正下着大雨，公司派的车就在这大雨之中把我送到了住的地方，加州山景城（Mountain View）的Oakwood公寓。这个公寓正如其名，完全木制结构，一大片三层小楼，按区域划分成ABCDEFGHIJK。公寓Checkin处是一位叫George的老爷子，大概60多岁。经过一系列复杂的文件工作，签了大概接近20个名，然后住进了公寓。因为不久还要有另外一个同事过来，所以公寓是两室一厅的，客厅和厨房是连在一起的，有阳台，两个独立卫生间。房间有免费的WiFi访问，夸张的是，经过速度测试，下载接近4Mbps，上传2Mbps，而且直接拿到公网独立IP，这就是规则制定者的好处啊。

继续贴公寓里面的照片：

客厅

厨房

卧室

因为第一天下雨，所以也没有怎么活动，而且下飞机之后发现自己已经24个小时没有好好睡过觉了，为了倒时差又不能立即睡觉，所以硬撑着到了当地时间10点多就睡着了，睡之间看到桌子上有个闹钟，就定在了9点起床。

因为相当于北京时间的下午，正是我一天当中精神最好的时候，所以这个晚上虽然很困但也没睡很好。等到今天早上，闹钟很敬业的把我叫醒，发现自己反正也睡不着，就爬起来在屋里翻箱倒柜地收拾——发现屋里没有洗衣机，看来只能花钱去洗衣房了。

大概闹钟显示10点的时候，因为看到Oakwood的手册上写周日10点-11点有免费早餐供应，所以冲去餐厅，发现空无一人。找到管理员疑问，管理员说，啊，现在才9点啊。当时才想起来拿出手机看看时间。因为手机已经在昨天落地的时候调好了，所以手机应该不会有问题，同样显示9点。然后管理员说，你是外国人？我说是。然后管理员说，你知不知道夏令时？我说知道。我做项目最头疼的就是夏令时的处理问题了，然后恍然大悟：当地时间11月1日正好是夏令时到冬令时转换的时间，也就是说，11月1日1:59分之后，会是另外一个1:00，相当于把表拨慢了1个小时。但是闹钟是机械的，需要手动调整，所以闹钟很敬业的把我晃点了一把。

回去上网一个小时之后，吃早饭，然后朋友Jason到这边来看我，于是蹭他的车出去转了转。既然到了Mountain View，不能不去Google看看。正好天公作美，雨过天晴，从我住的地方到Google园区也只要几分钟车程，不去白不去。

太晚了，睡觉先。看起来时差已经倒过来了……

to be continue…

http://ftofficer.blogspot.com

这个新blog将完全集中在技术问题的探讨上，并且将以英文发布。

访问这个blog需要翻墙，方法可以参考我之前的帖子。或者可以直接在Google Reader当中添加“http://ftofficer.blogspot.com”到订阅即可直接翻墙。

今天照常上网的时候，突然发现自己的Google主页上面的所有按钮上面的文字都消失了，所有的单选按钮也都消失了。
变成了这样：

这个问题最后得以解决，解决方案如下：
首先，在地址栏输入about:config，然后找到nglayout.debug.enable_xbl_forms这个配置项，如果它是true的话，把它改成false。重新启动Firefox即可。

======我是无聊的分割线======

如果你的兴趣仅限于解决这个问题，下面的查错过程请无视。

这当然是非常不爽的一件事情，于是我开始回忆在上次显示尚且完好之后我做了什么操作，但是实在想不起来上次完好是什么时候的事情了——我上网一般都是在Google Reader上面徘徊，而Google Reader上面确实没有什么显眼的HTML标准控件可以让我发现这个问题。

于是没有办法，只好开始手动排错。在重新启动Firefox，重新启动Windows，用IE访问Google主页三步之后，基本可以排除系统原因或者Google的网页本身的原因。接下来看看是不是插件的问题，那么就先从“安全模式”开始看看问题是否能够解决。于是打开Firefox在开始菜单当中的安全模式，然后把“禁用所有扩展”打勾，重新访问Google，问题依旧，因此也不是插件的问题。那么是Firefox本身程序的问题么？为了考察这个，我新建一个Profile：在命令行中输入<path_to_firefox>\firefox.exe -P，注意P需要大写，然后再弹出对话框当中选择新建配置文件之类，完成之后用这个新的配置文件启动，然后访问Google，没有问题。因此看起来问题仍然在Profile本身。

Profile当中既然不是插件的问题，那么很可能就是首选项的问题了。我们知道在每个Profile目录下面有一个prefs.js的文件，是Firefox在当前情况下的所有的首选项的值，也就是在about:config里面看到的东西。最简单的就是比较两个Profile当中的prefs.js文件。在经过了大约半个小时，尝试过数十个不同的首选项之后，发现了nglayout.debug.enable_xbl_forms这个罪魁祸首。

然后用这个key的名字来搜索，发现其实这个是从Mozilla 1.3就开始有的问题，最早可以追溯到2002年12月：

这个至今未关的Bug (185612)就是在讨论我遇到的这个问题。

事情还没有结束。

在我没有修改这个键值的情况下，是谁动了我的Firefox键值？

在仔细回顾了这个问题之前一天我所做的事情之后，发现嫌疑最大的是插件 XPCOMViewer 版本0.9a。在新建的Profile上面尝试，发现一旦打开XPCOMViewer的主窗口，这个键立即就被改变成了true。也许是作者为了绕过某个难解的bug吧。之后查阅XPCOMViewer网站，发现作者公布的最新开发版1.0a当中已经修复了这个问题，也许我应该给作者发一封信告诉他应该更新一下Mozilla网站上面的版本了。

最后要澄清一下，虽然0.9a有这样的问题，但是作为一个仍然在sandbox当中的项目，这个扩展已经做得相当的好用。根据作者最近的一篇文章当中所说，1.0a版本支持一个非常cool的特性：直接将一个XPCOM组件导出成为Javascript/C++/Python的代码。对于有意在Firefox平台上面做点事情的朋友，这个扩展值得推荐。

昨天收到了Mozilla Addons发来的邮件，经过漫长的等待，TabIMSwitch已经成为了Mozilla Addons大家庭的正式一员。
现在你可以登录Mozilla Addons上的页面来下载最新版本了。

https://addons.mozilla.org/addon/5413

—
5413将是你的终生代号 :b

最近玩Google App Engine，发现随着闹运会的结束，这个东西也重新不可访问了。今天偶然在SMTH的Python版上看到的。非常实用的一个方法，原始作者不可考，于是整理一下写在这里。

简单的说，Google的所有服务都是可以通过一个相同的服务器访问到，Google根据请求的URL当中的域名来决定应该定向到哪个服务。www.google.cn一样可以访问到所有的服务，例如App Engine。但是因为DNS服务器的原因，appengine.google.com会被定向到Google美国的服务器，不会去连接www.google.cn。但是事实上，如果我们能够向www.google.cn发送一个HTTP请求，其中的URL是指向appengine.google.com的，服务器一样能够帮我们中转请求，并把结果会传给我们。

要达到这个目的有两个方法，一个是修改hosts，让appengine.google.com和*.appspot.com指向到www.google.cn的IP地址。这个有两个劣势，一个是www.google.cn其实有很多个地址做负载均衡，一旦加上了hosts条目，就失去了负载均衡的好处；另一个劣势是hosts文件不支持*.appspot.com这种语法，所以只能把自己知道的appspot上的应用统统添加。

另一个方法则相对好一点，就是把www.google.cn:80设置成访问appengine.google.com的代理服务器。这种方法很好用，但是需要写PAC文件（Proxy Auto-Config，代理服务器自动配置文件）。所幸这个文件语法相当简单，因此可以直接写下面一段：

function FindProxyForURL(url, host) {
    if (shExpMatch(host,"*.appspot.com")) {
        return "PROXY www.google.cn:80";
    }
    if (shExpMatch(host,"appengine.google.com")) {
        return "PROXY www.google.cn:80";
    }
    return "DIRECT";
}

然后保存成一个proxy.pac文件。在浏览器的配置当中，把“自动浏览器配置脚本”的配置项指到这里即可。

Google今天在官方blog上面透露，他们“无意中”把Google自己的浏览器Google Chrome的漫画泄漏到了网上（看不懂E文的看这里）。这个漫画相当有趣，晚上发现cnbeta上面已经有人放出来了漫画的中文版，没看过的可以先看看。

说说几个吸引我的地方。因为我的经验主要是Firefox，对IE缺少研究，所以讨论也是基于对于Firefox的了解。

“现在的浏览器本质上是单线程的”

一针见血的论断，之前在研究Firefox插件的时候，发现了Firefox的这个设计缺陷（或者叫特性？）。Firefox虽然使用了多线程进行网络IO，但是界面的渲染仍然是单线程的，而这个单线程的本质原因是因为Javascript引擎是单线程的。单线程有一个好处就是编程简单，尤其对于插件来说，不需要头疼同步问题。但是单线程也有严重的问题，就如同在漫画中描述的那样，任何一个页面上的Javascript问题都会导致整个浏览器等待，表现就是界面停滞甚至死掉。现有的解决方案之一是异步模型，或者叫Event Driven的模型，例如Ajax就是对于网络IO的异步化，也有一些模拟的实现来实现Javascript的线程，比如使用SetInterval。但是因为Javascript规范缺少线程模型，引擎也很难做成多线程的，这个限制也极大地制约了浏览器和网络应用的性能和响应。

对于此问题，Google的解决方案是一个折衷：多进程。这样既不需要修改Javascript引擎，同时可以获取到并发的优点。其实我对于漫画当中对于多进程对于节省系统资源的论断持保留态度，对其他宣称的好处也是有保留的赞成，但是我承认这是一个正确的设计决定。用多进程的模式实现的浏览器，对于将来潜在的插件的实现者来说，是一个极大的模型简化。使用多线程的Javascript引擎（如果有的话），我相信带来的问题会比解决的问题更多。

多进程模型

接下来就是说另一个有趣的地方：多进程。从漫画当中透露出来的消息来看，这个多进程模型是1拖N的模式。每一个页面都将是一个单独的进程。因此我开始怀疑，Google Chrome如何实现标签页浏览。也许根本就没有实现，或者实现了一个假的。如果将标签页浏览实现在Chrome任务管理器当中，就必须有一种IPC机制来让管理器来将窗口共享给子进程来渲染，这个我还没有想到一种可以跨平台的实现方式。

Chrome任务管理器

非常cool，非常值得期待的组件，如果其功能真的如同其在漫画当中宣称的那样棒的话。

这个也是我对于Firefox最期待的功能之一。目前虽然有FireBug作为替代方案，但是FireBug仍然是内建在浏览器内部的。我希望的是一个非侵入式的任务管理器，一个独立于浏览器之外的组件来实现对于浏览器执行流程的监控。这样的好处之一就是可以在浏览器失去响应或者崩溃的时候仍然保留对于Javascript执行状况的监测。理想状况下我期望如同Windows的调试器一样，attach到一个失去响应的进程然后查看其调用栈或者执行时间，进而可以了解到浏览器各个组件的执行状况，发现引起问题的组件。

实现这种功能，需要Javascript引擎的协助。引擎必须提供一种机制来中断当前的执行流程，并能够使用某种机制将其内部状态导出。这是一个不小的工程。但是由于Google的介入，也许这个并非不可能之事。

名字和核心

Google Chrome。当我看到这个名字的时候，我就以为这个是基于Gecko的另一个版本——因为Gecko（Firefox所使用的核心）的核心组件之一就是Chrome。或者说，Firefox本身就是一个Chrome。

但是根据一些透漏的信息，Google Chrome使用的是WebKit内核——一个宣称比Gecko更快、更高效的内核。这个也比较靠谱，毕竟Google的Android上面使用的也是WebKit内核。

野心

随着浏览器的发布，Google用户联网占领桌面，并且试图逐渐替代桌面的野心昭然若揭（当然很早之前就已经是司马昭之心了）。一个中央管理组件协调各个网络应用；每个网络应用占用一个进程；可以查看任何一个应用的资源占用和响应时间；再加上从Google Doc到Google Mail的一条线的网络应用……

很好很强大的新桌面和新系统。

—
到了那个时候，你的所有安全，就全部寄托在了几个在网络上明文传送的Cookie。