热烈庆贺QQ升级到两个太阳那么多

腾讯名声不算特别好，我以前对他也有一些偏见，但是国内他仍是必须的选择，我们我们一时还无法抛开这里的朋友，让他们也一起来用自己偏爱的产品。

本人大概有洁癖，对花里胡哨的QQ深恶痛绝，但是对TM这款软件还是比较中意的，因为不会过多的干扰我的行为，界面也算大气和简洁，尤其是新版的TM（限于社会和历史原因，现在的软件都做成流线型，3D效果，运行慢，软件越做越大也是一大弊病）。

无意看了一下自己的Profile，发现前几天升到32级了，两个太阳，很牛叉，天天上线2小时以上不是盖的。

对比看起来笨拙，启动却要更快的MSN，TM还是有许多好的功能的，比如发图片直接预览，发生文件速度快等。

由于不是商务人士，对MSN没什么依赖，谢谢各位微软fans不炮轰我。

Google之恶

1. Google中国的首页在多数浏览器（FF例外）里有一个有趣的动画（模仿自Google 韩国），但是可恶的是翻译部分的图片是使用日文，明显又是从Google日本 抄来的。

关于 Google Chrome

作为心得也好，作为八卦也罢，无所谓了，只是随便写写。

I. 值得称道的细节：

1. 整个页面对于Javascript第二次（及其两次以上）调用alert时，用户可以选择不弹出提示（可以避免恶作剧），但现在这个功能是停止当前页面的所有alert，用户下次操作的alert仍然不会被弹出（类似于“记住我的这个选择”或“下次不再提示”）。合理的情况应该是一次用户操作时连续的alert才被阻断（javascript引擎可以识别：一次执行javascript脚本开始，到脚本交回控制权，视为一次连续的过程），当然为了避免恶意程序，也应该提供中止整个页面alert的选项。

2.textarea会检查拼写，但是text input却不会（与同样使用Webkit核心的Safari一样，textarea可以拖放大小）。

3. 没有状态栏，只有在需要显示状态信息时，左下角才隐现出一个浮动条（这个浮动条宽度是固定的，自适应可能更好）。

4. 另外这里看到关于Chrome的中文选词，很强大。
5. 简洁，动态效果，灵活的界面。如页签和单窗口的随意切换（怯怯地：其实我很早之前也想过用Javascript开发一个类似web控件，但一直懒于动手，现在倒是桌面应用程序先实现了 -_-!）。
6. 搜索文本时自动高亮全文匹配（类似于FF3的“全部高亮显示”选项），不过Safari似乎做得更漂亮（文档本身变暗，高亮全部，并且第一个匹配项会有一个警戒色的泡泡提示，感觉这个泡泡影响速度，所以未必需要这样的美丽）。

II. 不足之处：

1. 功能不够完善，比如没有编码选择，导致Google Picasa Web在nametags功能里出现乱码（添加名字标签(Add name tags)操作的页面）时无法手动调整（后来发现都有这些功能）。

2. 一开始就没有做成支持插件的框架，不知道以后会不会改变，现在这样是很简洁，但是在需要定制时，就显得很无助。

3. 下载的视觉效果相当好，但是安全控制似乎不够，尝试用Chrome打开这个页面，浏览器会自动启动下载，并将文件自动保存在默认目录下（一般是系统盘当前用户的Download目录），而其他浏览器至少还有一个保存提示框让用户选择确认。另外已经下载过的文件，仍然会不动声色的再次下载。
4. 不支持全屏(Safari3也不支持)，而这一点FF3和IE7做得比较好，Opera9反应最快，只是鼠标移到显示器顶部附近时，地址栏和页签都不会显示出来（Ctrl + T 创建新页签时出现地址栏，并且地址栏不再消失，除非再次全屏）。

III. 技巧：
Ctrl + B : 调出（默认在地址栏下的）书签栏。
Ctrl + F : 调出搜索框（所有浏览器通用）。
Ctrl + T : 创建新页签（所有浏览器通用）。

Google 的更新

Google基本上每天都有更新（包括创新和失误），然而这次的更新非同一般。

I. Google Chrome
经过两天各大新闻媒体和个人博客的大量相关报道的洗礼，使用Webkit内核（同Safari）的Google浏览器Google Chrome于昨晚（美国时间周二）发布诞生了，Google作为一家以网络为主的公司，Web浏览器对他的影响可想而知，这里是相关链接：谷歌浏览器（中国），Google Chrome漫画书（Google Books，中文版），更多内容可以搜索Google Chrome。

II. Google Picasa Web
很早就知道Google有图片的人脸（包括动物脸）识别技术，主要用于Google街道的隐私方面，但是最近Picasa Web提供了一项新特性：nametags(名字标签)，Google将你的相册中所有人脸识别出来，并进行归类，把相同的同一个人的脸（或相同脸型）的“ 1寸免冠照片”放在一起，你可以给它们加上名字，以后就可以点击这个人的照片找到所有有他在的照片，Picasa Web本身还有其他一些更新，包括界面改版，另外Picase这个客户端图片管理软件也升级到了3(beta)(晚上补充：早上尝试下载3.0，发现链接404错误，晚上可以下了，但是已经退回到了2.7)。

III. RSS AD (is not update)
今天在Google Reader里看订阅的文章，有一篇是GSeeker关于Google Chrome下载的快讯，在Google Reader里出现了一个图片连接广告（甚至在同一窗口中打开），上面的标志是“Ads by Pheedo”（有时是Google的广告）。

我看了一下，是GSeeker做的恶，之前只是类似于“相关文章”或者“看了这个的人也喜欢那个”之类的文本链接（其实内容本身也是外部广告链接），但是这个更招摇而令人厌恶而已。

同步Web客户端的时间

富客户端应用的普遍流行，许多操作直接在客户端完成，而一些跟时间相关的操作，客户端时间的正确性就显得尤为重要，一个和标准时间相差得离谱的时间，可能会带来滑稽甚至严重的错误。

在C/S构架下，对时间有要求的应用程序一般解决方法是同步客户端和服务器端的时间，一些要求较高的应用甚至需要专门的时间戳技术。

普通的B/S应用程序一般没有权限同步客户端的时间（也不一定有这个必要），这个问题也有一些解决办法。

1. 响应用户请求时返回服务器时间，并使用计时器（如：window.setInterval）做一个虚拟时钟。但是考虑到浏览器消耗和脚本计时器本身并不精准，长时间运行后时钟会出现较大的误差，予以忽略。

2. 响应用户请求时返回服务器时间，并计算服务器与客户端之间的时间差，每次时间操作均以该差值进行修正（可以专门做一个接口）。或者考虑只有在差值较大的情况下才进行修正（并提醒用户修正客户机时间）。

另外还要考虑用户所在不同时区的情况（Date.getTimezoneOffset）。

但是对于较精准的时间需求，这样仍然有一个问题，即从服务器端响应到客户端返回过程中的网络传输时间。这是一个随机数，根据网络情况和其他偶然因素有关，从几十毫秒到几十秒不等，有时达数分钟之久，最惨的是整个页面超时，当然同步也就没有必要了：）

如上图，客户端从客户机的t0时刻发送请求到服务端，然后服务端在T0时刻得到请求，经过连接数据、计算等操作，最终在T1时刻响应完成，客户端最后在t1时刻加载完成。

此时我们最关心的是服务器返回到客户端加载完成这段时间的网络传输耗时，但是暂时无法精确求得，只有一个相当不凑和方法：客户端发生请求时，带上当时的客户机时间（t0，浏览器请求头信息里一般带有，也可以通过客户端脚本new Date()，此时则需要通过异步请求），服务器计算所耗时间也可以得到，响应时返回服务器计算耗时（T1-T0）以及浏览器请求的时刻（t0）以及服务器时间，客户端加载完成时刻（t1）计算网络传输总共耗时为：(t1-t1)-(T1-T0)，之后以一定比例（如1:1）计算响应的网络传输耗时。

结果相当不凑和，而过程又相当麻烦，所以只作为抛砖引玉之篇。

图片来自Baidu图片搜索。