看AWS的SDK，感觉云计算的趋势，还是倾向于制作一个Full Stack的开发环境，一方面简化开发者的操作和配置，一方面也绑定开发者在这个平台上，让其更忠心。现在Amazon是底层的instance操作和sdk都提供，Google只提供了sdk，微软的环境似乎也是只有.net开发环境。这几个之间，不能互相迁移，就像我们现在在GAE上写的代码，基本上很难迁移到AWS上去，也不可能，当然也没意向迁移到微软的环境下去。

跟一些朋友聊这个App Engine，有的还不了解，有的上来就说云计算还有不少问题，比如安全之类，一旦细聊起来，其实也是网上看了一些标题，没有深入了解到底怎么安全有问题。看来我们的尝试还是很大胆的:-) 就安全问题来说，自己在国内买机器放服务就安全吗？听说过的IDC被搬了机器的事儿也不少了，老老实实作服务，架不住被连坐。在国外租服务器，数据也是依赖他们的安全措施，和google似乎没太大差别。可能问题会在于，一旦我们的服务做到很大了，需要重写数据接口和数据模型，以适应最广泛应用的分布式环境。但是现在还不太担心这个。做大的可能性，老实来说可能性不大，一旦做大了，也不缺钱干这个。

就现在来说，我希望的云计算是这样子：1.不考虑底层如何做到并发和分布式环境，只需要按照提供的编程模型来写逻辑，系统自动做到分布式查询和更新。2. 按需付费。3. 好用的开发和测试环境。4. 能够提供对底层和异步的一些操作， 能够从上层达到操作底层一样的能力。

现在，2是云计算标榜的特色了，1，3这两点GAE做的都不错，4还差一些。现在GAE无法做到统计功能（比如找出所有职工的个数这样的COUNT(*)操作，不过刚提供的试验性质的mapper似乎可以做到这一点了），也不能使用Socket进行网络连接，甚至一次性select出2000条以上的数据都是问题。这些都是GAE云计算模型的不足，如果以后可以改进，会让这个系统更加好用。而AWS却是4做的最好。他就是给你几个linux或者windows的实例，你爱配置什么就配置什么。不过开发环境和屏蔽底层细节这几点做的不如Google。

从我们的实践来说，Google的这个环境对于小型开发者还是很好用的。就我自己，从来没写过分布式的服务器代码，现在感觉用起来也是挺顺手。无论结果如何，我们总算是走上云计算辅助开发的路了，就这么走下去吧。跟着Google混，就图有免费的肉吃，我们就这么没出息。:-)

首先去gwt的主页跟着tutorial了解了一下流程，感觉很cool。基本上是在写桌面应用，各种组件组装，还能断点跟踪。然后发布的时候会把java编译成javascript下载到浏览器，实现Gmail那样的ajax体验。

就我断断续续加起来不到几个月的可怜的写web代码的经历，从来牛逼架构能实现这样的体验。于是我立即就打算开始用gwt重写这几个页面。周一和周二抽空看了一下tutorial，以及一些基本概念，周三开始写代码。

遇到了几个问题。首先是我希望从它的show case里面扒拉一些code来用，没想到他的整个show case的代码耦合性太强了，想生撕下来一块来用基本上不可能，一折腾就要把整个结构拿来了。折腾了几个小时算是放弃了。然后希望从一个dock的组件入手，自己搭一下。

搭了个七七八八，客户端码好了，一连服务器端发现失败。无论怎么改都是失败。原样的代码用到另一个测试工程上就可以，我觉得可能是当前的工程用了一个现成的framework，把routing给改了，导致客户端通过gwt-rpc这种方式连不到服务器端去。当认识到这个问题的时候，我试图重新修改当前这个framework的源码，让他放过我一条路由，后来发现还是不行。去问google groups里面的开发者，他也没说出来个啥。

后来只好退而求其次，采用gwt提供的另一种交互方式，通过json来交换数据。这样其实也挺好。因为这个工程本来就有很多json的结构，只需要包装一下就能提供给客户端。写了个1+1测试了一下，发现可以通讯了。

由于采用JSON的话，客户端只能看到基于JSNI（一种Json嵌入java的方法）的数据，于是封装了两个模型数据给客户端用，修改客户端请求方式，修改服务器端提供数据的方式，周四下午终于弄出来一个可以操作的版本。

于是心情大好。去田老师红烧肉吃了一顿回来，感觉这两天总算没白费。接下来的事情就简单了，增加css修饰，增加类似Gmail那样的ajax标签提醒，有点模样出来了。

这几天的体会，gwt很好，很强大，很符合我对web开发的期待，那就是组件+断点调试。这是把web作为application的最佳开发模型。当时作浏览器的时候，感觉gmail和gmap的javascript代码都很奇怪，肯定是混淆过，让作解析javascript的哥们痛苦不堪，但是没想到背后有这么一个强大的开发模型在支持。Google就是牛阿。

希望从明天开始能够生活回到正轨。

就国内来说，中国移动只把定位接口开放给了屈指可数的几家合作伙伴，用来做导航或者地图服务。所以普通的个人或者公司想要借助手机的定位信息来开展一些服务，基本上是不可能地。但是Google却有自己的办法绕开了运营商，自己推出了定位服务，用在了Google地图上。去谷歌下载一个手机版的地图，就会发现，没有GPS芯片的手机，也能给你定位个差不离。倒不是因为谷歌偷了移动的数据（这可比搜狗事件严重多了，呵呵），或者和移动合作了，而是Google使了个花招：凭借庞大的用户群，借助有GPS的用户来帮助没有GPS的用户。具体来说就是，当具有GPS芯片的用户使用Google Map客户端的时候，Google会把当前的位置信息和基站编号一起上传，存储到服务器上。随着用户位置信息的变化，以及用户量的增多，服务器上会存储了大量的基站和地理位置的匹配信息。这样，没有GPS芯片的用户发起请求的时候，只提供基站编号，服务器端也能够提供位置信息。

长此以往，中国移动当个宝贝似的捂着的基站地理位置数据，被别人用光明正大的方法拿到，于是含金量也会越来越低了。就像是电影《方世玉 II》里面的“师兄”李国邦的乾坤点穴大法，最后落得“收藏武功，是会贬值的”的感叹。

iPhone和iTouch上的定位方法，据说是采用了Google和一家叫做skyhook的服务，除了GPS和基站定位之外，还可以使用wifi定位（iTouch上可是没有GPS也没办法拿到基站信息的）。精确度在美国也是相当的高，可以在50英尺之内。纽约时报对此事的报道介绍了事情的来龙去脉。

除了这些办法，还可以整合什么信息，来更精确的定位呢？

被成为“物联网”基石的RFID标签，是一种能够主动或者被动接受射频信号的轻巧小卡片，如果这种标签能够大批量的被贴在任何地方，是不是会更精确的传输定位信息呢？据说下一代的iPhone就会带有RFID标签，看来RFID定位也要加入手机定位的”联盟”了。

步入40岁的女性患乳腺癌的几率是1%，现在有一种仪器，当被测者已经患了乳腺癌的时候，它测出来为阳性的概率为80%，当被测者没有患乳腺癌的时候，它误测为阳性的概率是9.6%，那么，当这个仪器测试一位40岁以上的女性为阳性时，她患有乳腺癌的几率为多少？

据说只有15%的医生给出了正确答案。所以被我问住并且回答几率在40%以上的也不必汗颜。直觉会倾向于在9.6%和80%之间取一个中间值，胆大 点的会猜的偏小一点。但是简单用bayes公式计算一下，会发现答案只有7.8%. 就是说，即使这个仪器测出来阳性，患病的几率也只有十三分之一。

对我们普通的群众来说（相对于数学牛人），有悖于直觉，不是吗？大部分人忽略了真实患病的几率只有1%. 可以去这么理解它：仪器的作用就是，把1%的几率，提高到了7.8%. 当然这不是说仪器让患乳腺癌的几率增大了，而是说给真正有可能患病的人一个比1%更确切一点的数字，尽管这个数字似乎仍然没什么作用。

这里给出了一种贝叶斯方法的直觉解释，对于我们这种没有数字敏感性的人群来说，图是最好的解释方式。这篇文章给出了图示来解释贝叶斯公式是怎样把预测的可能性增强的，很符合人的思维模式。

随着搜索引擎、机器学习等热潮的兴起，贝叶斯方法和马尔科夫模型越来越受人推崇，谷歌黑板报也科普过。具八卦传闻，在微软，if..else是软件开发的原子操作，在google，原子操作变成了贝叶斯方法和Markov模型。看来，google具有更高的视野，那里的某个大拿也曾在某次坐飞机的时候写了一段20多行的python代码，利用贝叶斯方法来实现拼写检查，有效率达到了70%-80%.