微软仿Chrome自动升级背后 意在让用户放弃IE6

微软仿Chrome自动升级背后 意在让用户放弃IE6:

历史的车轮滚滚向前，无情的将各种旧物抛在身后，在日新月异的IT行业中体现更加明显。12月16日，微软IE业务和营销总经理Ryan Gavin在博客中表示，微软将在明年初推出IE自动升级功能，希望用户不再使用IE6。在网页标准化不断升级以及浏览器竞争日益激烈的今天，微软推出IE自动升级功能，是浏览器市场竞争日益激烈的使然，也是发展的必然。

IE6在中国仍然有较大的份额（图片来自网络）

IE6辉煌的过去 今时开发者的伤

IE6天生对CSS支持不佳（纯CSS测试网站：http://knb.im/css3/）

2001年8月24日注定是一个不同寻常的日子，微软公司在那天发布了一款视窗操作系统Windows XP，这一系统是迄今为止微软最成功的操作系统，伴随着XP的成功也还有内置的IE6浏览器，在当时，IE6的提升是巨大的，不仅提升了DHTML，还支持CSS1、DOM1，以及SMIL2.0，同时也还可以对图片大小自动调整，这么多的优势让IE6成为了使用最广泛的浏览器，甚至市场占有率一度达到95％。IE6固然是很好的浏览器，不过那只是十年前的事了。对于开发者来说，现在的IE6不仅不支持最新的Web技术和标准，也让开发者在设计的时候不得不考虑IE6这个变态，比如PNG多位透明、不支持相对窗口位置等等，更让人不可容忍的是存在着浮动填充Bug，这使得你只有在了解所有Bug的基础上才能设计出能够正确展示的网页，这不仅让开发者痛苦，同时也阻碍了Web技术的发展和标准的推广。另外令用户体验不佳的还有不支持多标签打开、不支持HTML5、对CSS支持不好、还有那永无止尽的漏洞……，存在着这么多的问题，就连微软都希望IE6尽早消失。

Chrome首超火狐 微软压力倍增

Chrome再度超越，成为全球最流行浏览器（图片来自StatCounter）

Chrom在11月份超越火狐成为全球第二大浏览器，仅次于IE，另外根据互联网流量检测机构StatCounter在过去三周的数据显示：

2010年初，IE8登上这个宝座后就一直持续到现在，而谷歌Chrome 15全球市场份额达到24％，IE8为22.9％，火狐8.0为14％，IE9则只有10.4%，位于第四。

Via：StatCounter

至此，Chrome已经成为取代IE8成为全球最流行浏览器。

微软扼杀掉网景浏览器之后便自满自足（图片来自网络）

我们可以分析一下IE浏览器战败的原因。起初，微软在扼杀网景浏览器之后，便自满自足，在获得浏览器市场绝对市场份额之后便失去了更新浏览器的动力，这从IE6与下代浏览器IE7推出相隔五年之久便可端倪出，而这五年，反观其他公司：苹果开始研发iPhone，谷歌也从一家新兴企业成为搜索行业的巨头，微软呢？浏览器市场份额一直下滑，在这么一个互联网发展飞速，移动互联纵横的时代，用户良好的体验便是王道，相比于Chrome的简洁（当然功能也丰富）、快速，火狐众多个性化插件、自定义的细节，IE又有什么呢？IE9 图形硬件加速的噱头？

再反观更新速度上，2011年发布号称体验更佳的IE9与IE8相隔了三年之久，在这三年，Chrome从2008年犀弱、功能单一的浏览器成长为今天全能浏览器，在12月14日谷歌推出Chrome 16版本后，Chrome 17也随即进行内部测试，新功能不断的加入和完善，同时谷歌也积极收购新创公司，加强Chrome团队。再看开源的火狐，11月份发布8.0版本，12月20日便推出了9.0正式版。微软除了在系统补丁里反反复复更新IE的安全性以及图形显示外，它还为用户做了什么？话说回来，如果不是IE内置于Windows系统，如果不是各大网银、政府网站支持IE的话，它的市场份额估计更不堪忍睹。

自动升级的背后 微软发力浏览器市场

各大浏览器之间竞争十分激烈（图片来自网络）

微软效仿Chrome推自动更新却为哪般？一方面是Chrome仅用三年时间便成为第二大浏览器，对IE形成了直接的威胁，同时也是微软与谷歌两个巨头之间博弈的结果，倘若谷歌浏览器获得绝对市场份额，说不定哪天就进入微软桌面操作系统领域。另一方面也是微软闻到了浏览器市场弥漫的硝烟味：各种双核浏览器的推出，谷歌新插件可将IE变Chrome，使得微软不得不反思浏览器市场份额不断下滑的原因。为了保住浏览器市场份额，更重要的是保住在浏览器标准和网页标准方面的话语权，微软将会越来越重视浏览器市场，这从微软急匆匆推出IE10预览版可见一斑。

不管怎么说我们欢迎浏览器市场不断的竞争，也乐于见到微软推出IE自动升级功能，因为这样不仅可以给我们用户带来更佳的浏览器体验，也可以给国内那些不懂如何升级浏览器的用户带来安全和便捷。

本文由Tech2IPO作者燕子转载自CSDN，点此查看原文。如果您对该话题感兴趣，可以留言评论。

Tech2IPO新服务：
HT实验室 | 创业者服务 | 投资人服务

Business of Google APIs 2011

Business of Google APIs 2011:

ProgrammableWeb says Google has 94 APIs. I roughly count about 75 going through Google Code. I’m more concerned with public web APIs, and Google has Android, Chrome and other non-web APIs, so its hard to tell.

In any case I would consider Google to the largest public web API owner around. I don’t think any other single provider, owns the number of, as well as size of public APIs, that Google does. As with any leading API providers I think there is a lot to learn in studying their approach to API deployment and management.

With this in mind I wanted to take a look at the Business of Google APIs in 2011 as one of my year-end, API reflection posts. I think there are some important lessons to be learned from the work Google did over 2011, to get their API business in order.

Google was already setting the theme for 2011, with the launch of Google Console in November 2010. The Google API Console helps developers manage their Google API usage across all of thier sites and apps. It was clear, Google was not just looking for a way to get a handle on how they deploy and manage large numbers of APIs, they were acknowledging developers needed a way as well.

Google API Console centralized how developers managed the Google APIs they used, traffic generated via these APIs, introduced billing management for some APIs, and provided developers with project and team building tools. Google supports 30 APIs inside of the API Console now.

In 2011 Google also worked to make their APIs more discoverable for developers with the launch Google API Discovery Service. The Google API Discovery Service provides a set of web APIs for discovering metadata across Google APIs by delivering a JSON-based API that provides a directory of supported Google APIs, and a machine-readable discovery document for each API.

Now developers can integrate Google API discovery into client libraries, IDE plugins and other tools, making it easier to discover the API they need. After providing an API discovery service, Google followed another 2011 trend around deploying the Google API Explorer.

Like other API explorers, Google API Explorer allows users to make calls and explore REST APIs using a web interface, allowing anyone to start using an API without writing any code, even when authentication using Basic Auth or OAuth is required.

API explorers have done a lot to improve the time it takes for developers to get up and running using an API, but nothing beats good quality code samples, and Google put some serious effort into standardized code samples that can be used across Google APIs, in multiple programming languages:

• Google APIs Client Library for PHP (Beta)


• Client Library for .NET (Beta)


• Objective-C library for a new generation of APIs


• Google APIs Python Library goes to Beta

Beyond making it easier to discover, explore and manage APIs with Google Discovery, Google Explorer and Google Console in 2011, Google also spent a lot of time addressing API security.

The first step to improving the security of Google APIs was by supporting SSL across all Google APIs. Next Google went all in by not just working to support OAuth 2.0 across Google APIs, they want to help developers understand OAuth 2.0, making it easier to secure applications with the standard. To help facilitate this understanding, Google opened up the OAuth 2.0 Playground, which is meant to simplify experimentation with the OAuth 2.0 protocol and APIs that use the protocol by developers.

With these moves by Google in 2011, I think we can say that SSL support and OAuth 2.0 are two API security essentials that are here to stay. After working on security, Google moved into the legal department with the introduction of a single Google APIs Terms of Service.

Google has rewritten their terms from the ground up with the goal of making them easier to understand for application developers, and one by one, redirecting each API to use the centralized, easier to understand terms of service. At the moment it seems as though most of the APIs that use the central terms of service are content and data related APIs, like Google Moderator and Blogger, while more complex APIs like Youtube and Google Adwords still use their own terms of service.

Overall Google made some pretty significant improvements to get their API house in order. Of course in order to do this they also had to make some hard decision, like deciding to shut down 18 Google APIs in May, which included the Google Translate API. A decision they reversed two months later, when they decided it was better to offer Google Translate as a billable API under Google Console.

As the API Evangelist I don’t really invent any of the API approaches I write about, I try to shed light on what others are doing. Thats what this post is all about, shedding light on how Google is conducting the business of their APIs, so we can learn from them-- the good and the bad.

I think its important to remember that we are all making this shit up as we go along, of course it should be based on some experience, but ultimately we are in some seriously new territory, and even some of the biggest players in this space fumble the ball. This fact became painfully clear in an accidental post by Googler Steve Yegge, shedding light into the API strategy of not just Google, but also Amazon.

So what do I take from Google’s approach to APIs in 2011?

• API discovery is important


• API exploration is important


• Centralized billing and reporting are essentials


• Good quality code samples are essential


• Security with SSL and OAuth 2.0 for APIs is standard


• The legal around APIs needs to be easier and standardized


• Sometimes, APIs go away


• We are all making this shit up as we go along

A lot of this is what we already are seeing from API service providers in the space like 3Scale, Apigee, Atmosphere and Mashery. But, what I don’t see, is anyone addressing discoverability, easy legal and centralized billing, management and reporting from a developers perspective.

Google is addressing all of this because its in their best interest for ALL developers to be successful, where API service providers tend to focus on the success of developers who use their client APIs, not ALL developers.

Well, maybe in 2012 a service provider can step up with a solution that help developers discover and manage their business and legal across “ANY” API, or maybe Google can open the doors to any API provider to use the Google API platform as part of any Google Apps account?

HTML5未来发展的六大趋势

HTML5未来发展的六大趋势:

　　HTML 5从根本上改变了开发商开发Web应用的方式，从桌面浏览器到移动应用，这种语言和标准都正在影响并将继续影响着各种操作平台。

　　在移动领域，大家争论不休的一个问题就是开发Web应用还是原生应用？而随着HTML 5标准的发展，两者之间的差异已经逐渐变得模糊，今天各大媒体都争相报道与HTML 5有关的东西，那么，HTML 5未来的发展趋势到底是什么？

　　1） 移动优先

　　前天，appMobi获选ReadWriterWeb2012最具前途的的公司，作为一家初创公司，这个奖公司首先专注于在移动平台上如何实现HTML 5的简单易用和无处不在。

　　从如今层出不穷的移动应用就知道，在这个智能手机和将平板电脑大爆炸的时代，移动优先已成趋势，不管是开发什么，都以移动为主。

　　如上文所说，此前一直困扰移动领域的问题就是开发Web应用还是原生应用。而如今，我们看见一些大型企业如《金融时报》在冲着HTM L5进军移动市场过程中，从App Store撤掉iPad原生应用而开发Web应用，同样表现出色。

　　许多游戏开发商也将在移动Web应用中扮演中重要角色，移动Web应用优先的趋势将会持续到移动设备统治信息处理领域。其实用户根本不在乎你用什么工具开发了什么应用，不管是Web应用还是原生应用，只要好用就可以了。

　　2) 游戏开发者领衔“主演”

　　其实移动游戏开发商是从HTML5获益最多的一方，他们可利用这个平台逃脱付费游戏须向苹果支付的30%提成。在某种程度上，游戏就是移动平台销量最好的应用，也是吸引人们购买移动设备的一个重要因素。

　　许多游戏开发商都被Facebook或者Zynga推动着发展，而未来的Facebook应用生态系统是基于HTML5的，尽管在HTML 5平台开发出游戏非常困难，但游戏开发商却都愿意那么做。通过PhoneGap及appmobi的XDK将Web应用游戏打包整合到原生应用中也是一种方式，Facebook差不多就这么干的——基于Web应用及浏览器，但却将之打包整合进原生应用。

　　3) 响应式设计&自动变化的屏幕尺寸

　　在HTML 5真的改变移动开发平台之前，必须要迈出重要一步，那就是“响应式设计”，也就是屏幕可以根据内容而自动调整大小。

　　响应式设计最好的一个例子就是今年上线的BostonGlobe.com（观看视频），其屏幕能够根据任何内容而调整尺寸大小，在访问过其开发商Filament Group后才了解到，响应式设计也并非易事，一些基本概念设计必须从头开始，比如处理媒体库的RespondJS，而且处理来自第三方的图片和广告也是恼人的问题。

　　要想做好响应式设计，就必须洞悉内容与屏幕之间的反馈关系，一家来自硅谷的响应式设计公司ZURB称，其实在过去的16年中，开发商就意识到响应式设计就要完全离开“流”，转而注重内容是如何在网页和移动设备中被处理的，这一过程还在继续，HTML 5会让它最终成为可能。

　　4 )设备访问

　　消除Web应用与原生应用界限的最大障碍就是浏览器访问移动设备基本特性的能力，比如照相机，通讯录，日历，加速器等，利用HTML5实现此能力方面，上文中提到的appMobi算是行业翘楚，在感恩节后开源了所有API。Mozilla也一直在努力通过移动浏览器Fennec来将强设备访问能力。

　　对许多移动开发商来说，提高设备访问能力是HTML5最令人激动的革新，这意味着Web应用能够登陆移动设备而无需做任何PhoneGap式打包，游戏开发商当然最开心，因为某些特性对他们来说是封锁的，比如能整合到游戏中的加速器。

　　这就开启了另一个可能的世界，比如能与云更好地整合（这有利于应用内购买，消息推送等）并提高游戏可玩性，有了HTML5这个平台，开发商可以不再依赖于Java语言，CSS3，HTML及其它程序语言。

　　5) 离线缓存

　　这个概念相当新潮，离线情况下，app也能照常运作，算是HTML 5充满魔力的一面，今年最好的离线缓存例子就是亚马逊Kindle的云阅读器，可以通过Firefox6以上版本，Chrome11以上版本，Safari5以上版本及iOS4以上版本浏览器将内容同步到所有Kindle系列设备，并能记忆用户在kindle图书馆的一切。

　　亚马逊就这么实现了离线使用Web应用，许多专家人声称原生应用的末日即将到来，因为Web应用的使用变得简单，无摩擦，适用于任何一个平台或者无需平台。当然Mozilla的触角也伸到了这里，实际上，Mozilla想涉足任何一个HTML 5能渗透的领域，从Mozilla的移动蓝图，可以了解更多。

　　6) 开发工具的成熟

• 　　在今年八月份，Brian Fling曾写过一篇博文叫HTML5 Web应用开发剖析，提出了几点建议供从事HTML 5应用的开发者参考：
• 　　要耐心，HTML5项目可能比开发其他任何项目好是都要长
• 　　做好预算，这不像建网站那么简单，可能会耗费你大量资金
• 　　找对开发者，你要记住，这对许多经验丰富的专家来说都非常难的事，那么你的团队也会觉得困难，所以一定要找对人，找到正确的方向
• 　　要自食其力，你要知道，开发HTML 5项目，许多工具都要自制，不是现成的
• 　　在技术界，按部就班的教条风格在这里行不通，会花掉许多不必要的资金，在移动领域，没有对与错，只有是否适合，一切以用户体验为重。

　　在工具方面，除了appMobi提供的工具以外，还有Sencha及Appcelerator提供的框架及IDE供应用开发商们使用，虽然这些工具现在算不上成熟，也不如Android和iOS上的开发商框架及工具那般简单强大，但至少它们在演进，将会变得越来越好用。

　　总结

　　HTML 5的其它功能，如表单和新标准还在快速演进，而随着标准化工作的进行，HTML 5有可能变回HTML。HTML 5开发领域的领军人物包括Sencha，Adobe，Appcelerator，appMobi及Facebook，亚马逊，Google三大巨头。

　　不管你是想开发出新型视频应用的开发商如Brightcover还是想开发新型音频应用的开发商如Soundcloud，不论是桌面应用还是移动应用，HTML 5都是创新的主旋律。

　　英文原文：RWW：Top 6 Trends In HTML5 In 2011

　　中文翻译：雷锋网供稿。

上司嫌我不懂管理

上司嫌我不懂管理:

作者：英国《金融时报》中文网专栏作家 谁谁谁 2011-12-14 (www.ftchinese.com)

者Gogoliu在来信中说：我几年前由于工作出色，由高级工程师被提拔为小主管，带领一个5，6人的小团队。目前团队已经扩大了一倍多，里面也有几个小组，相处和谐。遇到突发事件大家也能抱团应对，从没有退缩过。团队里很多都是年资比较高的老员工，工作也算兢兢业业，我觉得没必要整天绷着个脸横眉冷对的。想不到上司看不到我们一系列漂亮的工作业绩，也看不到别的平行的团队里由于上下级关系紧张，人员流失太快等问题，总时不时challenge我太体贴下属了，说让我improve leadership skill。好莱坞电影《细红线》里有个深得下属人心的连长由于担心一个突击行动的伤亡太大，公然拒绝执行上司在电话里的进攻命令，保住了下属的性命，但最后也被撤职了。我知道和平年代里，也会有这种事情发生。难道“如果让下属太舒服了，上司就不会让你太舒服”是恒古不变的真理么？

我很想对Gogoliu说的是，根据我的观察，对担当部门领导的中层管理人员来说，业务做得好最多只占管理水平的30%，另外30%是让公司里其他同事以及公司外的行业内人觉得你做得好，剩下的40%则是读懂领导的意思，按领导意思办事，从而让领导觉得你做得好。一个好的中层领导，需要将精力中的70%用于让别人肯定自己，而不是自己关起门来苦干。当然有些比较牛的部门领导，即使只用精力的30%，也已经能够把下属折腾得团团转。

让公司内外的人觉得你好，需要的是沟通技巧和公关社交技能；读懂领导意思，则需要掌握情报搜集工作以及一些心理分析技能并兼具相当的政治素质。

有些领导在派活儿的时候喜欢表明立场，给这样的领导当下属相对轻松，只需要做个执行人员即可。有些领导则喜欢把自己的意思藏在后头，全靠你是否有悟性。举个例子。有位领导让下属做一个项目分析报告。这个自以为聪明能干的下属在彻查了能找到的所有资料后，得出一个公司应该尽快停止境外采购，而尽早采取自主生产的模式的建议。这个建议被领导点头称允后，即被锁进箱底不见天日。不久之后，这个下属也被调离做了冷板凳。离开多年后，他才意识到，原来领导的意思是让他分析出一个相反的方向：应继续坚持境外采购，因为领导压根不想让这个项目在本土生产。

我不觉得领导会因为你“太体贴下属”而challenge你，你把领导想得太狭隘了。领导真正想challenge的很可能是你“不够体贴领导”。让你“improve leadership skill”，大概主要的意思也是嗔怪你不懂他的意思吧，只知一味蛮干。

当然如果你真的像《细红线》里那个自以为是的连长，就更是活该遭冷遇了。哪个领导愿意下属部门领导关起门来当皇帝的？你以为你是谁？吴三桂吗？所以，Gogoliu的问题不是“让下属太舒服了”，而很可能是让领导不舒服了。这才是关键。

作者电子邮箱：from9to5@live.cn）

本文的网址：http://www.ftchinese.com/story/001042205