灵感点滴

Google 的服务器是大规模的分布式机群系统，现在估计达到了百万台的规模，是其最无敌的地方。以前了解了它的GFS、MapReduce、Bigtable 和 Sawzall 等，都相当帅，最近又看了 Upstart 的文章：Modular Software Upgrades for Distributed Systems， 分布式系统的软件升级方案，在保证服务不间断的情况下实现不兼容版本的平滑升级。它所采用的方法并不算高深，Erlang出于电信领域不间断服 务的需求早已经实现了这样的功能和平台，如果采用 Erlang 来实现这种平台的话，应该会更简单。虽然文中所使用的方法并不高深，但是对问题的建模以及严谨的分析还是非常值得学习的。

现在 Google 的服务都是逐步实现升级的，不同用户看到新功能的时间会不一样，但都不会影响到正常的使用。

前阵子去百度面试的时候，就问了面试官这方面的一个问题：百度有没有花大力气去做这类平台的打算？当时的回答是如果需要就会去做，说 Google 在这方面是投入了很多人力的，而百度目前的平台也能满足需求。但从这一方面看，百度就是比较短视和小气，它要真想跟 Google 竞争，就得早点开始在这方面加大投入力度，而不是天天想着如何在搜索结果里搞竞价排名。

过了一阵子，百度成了系统部，并开始急聘人才。我也投了简历，如果 它真打算好好做这方面的话还是一个很好的机会。不过听说百度创业前期的核心技术人才已经走了不少，更加对百度没有兴趣了。这周五被通知去面试，可当天一直 联系不上当初通知我的HR，电话一直占线，估计是电话没放好，不确定面试时间，索性就不去面试了。他们似乎并不看重员工的潜力，碰上一个小气的面试官，多 半是会 REJECT 的。

GMail 终于支持 POP3 收信了，通过 POP3 协议从其他信箱读取邮件，而不是早就支持的邮件客户端从 GMail 收信。有了这个功能，再加上早就支持的代发邮件功能(send mail as)，就可以完全用 GMail 的平台来使用其他邮箱了，既可以享受 GMail 的强大和便利，又省去了换邮件地址的烦恼，相当帅。

其实这项功能推出有一段时间了，只是我的帐号才发现这项功能。在英文界面下，打开设置(setting)界面，有一个帐号(Account)标签，现在多了一项从其他帐号获取邮件(Get mail from other accounts)，可以按照向导添加 email 帐号，跟设置邮件客户端差不多。GMail 系统会每隔一个小时去该信箱检查邮件，也可以手动让它查收。不知道查收邮件的时间间隔能不能调整，否则一个小时有点长，要是能够根据邮件的多少自动学习一个合适的时间就好了。

最近台湾那的光缆断了，访问国外的资源相当慢，Google 的服务也同样受到了影响。可能是在国内已经有部分服务器的缘故，Google 核心服务网页搜索一直相当顺畅，而像 GMail 等外围服务就常常抽风，响应很慢，相当不爽。以前出于安全性和GFW的考虑，都是使用HTTPS方式访问 GMail，在目前这种网络严重堵塞的情况下基本访问不了。这个时候最好改用 HTTP 方式，并同时打开多个 GMail 窗口，它可以很好地利用浏览器的缓存和多线程，可用性大大提高，各位不妨一试。

10月17日参加了 Google 的笔试，表现一般，虽然不及大牛们算法强劲，但面试机会总能捞到一个吧，满怀希望地等待。几天过去了，音信全无，Revv同学在周五收到面试通知，接着周六又进行了第二轮面试。虽然有些沮丧，但总感觉还有些希望，虽然非常渺茫。

刚刚收到了Google的来信，标题为“resume-thanks”，显然被拒了，彻底踏实了。全文如下：

We received your resume and would like to thank you for your interest in
Google.  After carefully reviewing your experience and qualifications, we
have determined that we do not have a position available which is a strong
match at this time.

Thanks again for considering Google.  We wish you well in your endeavors
and hope you might consider us again in the future.

Sincerely,
Google Staffing

问了一下David，他目前还没收到任何回复，估计也是离据信不远了。笔试后，我跟Revv和David都交流过，前面的题目做得都差不多，差别也只是在最后一题，而且我跟Revv对题目的理解和解法都差不多，跟网上大家的讨论有偏差，不至于会有这么大的差别，或许是RP的关系吧，呵呵。

彻底被Google据了，死了心。重新规划一下职业，当红的大型软件公司都没什么希望，虽然IBM和MSRA都投了，可能性很小。其他的公司也都懒得投了，去了也只能是做一些边沿的技术，打杂。前几天，投百度的高级系统管理，也是直接被拒了，网上笔试都没有机会，呵呵。之所以会投这个职位，就是做好了被拒的心理准备的。目前看来，去计算机系的那个实验室还是不错的选择，努力争取一下吧。

GTalk刚出来时，为其单文件的大小和清爽的界面所打动。它打破了一贯的Windows软件界面模式，没有系统菜单，也不见标准的Windows按钮 (设置对话框除外)，甚至猜测它是使用Win32 API来实现的，Google 的传奇足以让我们敢对它做非常大胆的猜测。这种做法是与众不同的，正符合 Google 的作风，呵呵——纯属YY:-)

前几天阅读 chm 格式的文档时，很以外的发现 GTalk 的界面居然是用 IE 控件+JavaScript 来实现的。事情经过是这样的:看ANSYS的chm格式帮助文档时，嫌字太小，就设置IE的Internet选项/辅助功能/不使用网页中指定的字体大 小，然后通过 按住Ctrl并滚动鼠标滚轮来实现放大和缩小CHM中的字体大小。后来打开GTalk，发现聊天窗口的字体变大了，并且通过上面的方法能够控制字体大小。 后来又做了几次验证，跟猜测的完全一样。至少有一点可以肯定，GTalk的聊天窗口使用了IE的配置参数。不难推断，GTalk的整个界面都是通过IE控 件来实现的，这也是近来UI的一种趋势，微软的不少软件也逐渐采用了这种做法。

用HTML+JavaScript是Google的强项，把它应用到做桌面应用也是很自然的事情，比如Google Desktop Search就是通过在本地开一个httpd的方式来做界面，将Web应用延伸到了单机。新版本的GDS估计也是跟GTalk类似的UI实现。这种方案有 很多的好处，集中了BS结构和CS结构的所有优点。做一个CS的外壳程序，可以开机自启动，不受浏览器限制，而且比较容易的访问本地资源。而将核心业务采 用BS结构，在CS外壳中使用HTML+CSS来定制界面，用JavaScript来实现业务逻辑，而这部分全部或者部分是从服务器获取，维护起来非常方 便。现在用CSS来定制UI的技术已经非常成熟，原来单机程序比较复杂的换肤功能已经可以轻松实现，效果甚至更好，比如GTalk的聊天窗口。

Google一下，有人发现了更多的内容：GTalk聊天界面应该是基于IE内核的? 找到了本地的CSS文件，还有用SPY++看到了GTalk用的WebBrowser控件和RichEdit控件等。

这两天把GMail和Orkut注册服务做了重要更新，主要在以下几方面：

• 将后台程序改进为多进程和多线程安全的，提高了并发请求下的稳定性。之前的程序未考虑并发情况，会导致文件读些冲突而文件损坏和丢失数据。
• 改进了验证GMail邀请有效性的算法，使得更新邀请和获取邀请更快捷。快速检验模式下，使用多线程进行并发测试，速度是原来的几十倍，但准确性降低，在批量检查的时候使用。
• 添加了反机器人测试(CAPTCHA)，防止GMail邀请被爬虫误取走。用PyCAPTCHA实现，很好用。
• 对页面和后台程序做了改进，使得页面响应速度更快，为用户提供更好的体验。
• 改变了服务的地址，现在统一用域名 http://www.daviesliu.net/ 进行访问，原来的地址仍然有效，但会重定向到 http://www.daviesliu.net/share/，做了友情链接的朋友麻烦更新。
• 更改了提交GMail邀请的信箱为：gmail@daviesliu.net，这个更短更友好一些。它是使用Google Domain Mail 服务，本质上跟Share.Invitation@gmail.com是一样的。

现在系统的资源比较充足，感谢过去这一段时间内一直给本站发送邀请的朋友们，见页面的致谢。很可惜的是，早期的原始数据丢失，在此向那些朋友表示歉意，但邀请大部分已找回。

现在新注册的用户可能可以有50个邀请名额，对个人已经是足够了，希望在这里注册的用户能够将富余部分回馈本站，谢谢。如果以后GMail邀请资源紧张，可能会采取凭GMail邀请注册Orkut的方式，希望广大GMail用户多多支持。

上一页 | 第 2 / 3 页 | 下一页