关于PageRank的一些见解

根据googlepagerankupdate.com的调查,最新的一次PR值更新发生在2010年的4月2日,更早一次则发生在去年圣诞期间也就是2009年的12月31日。相信不少站长都在期盼着PR值更新,Google PageRank预示着一个页面的重要性和相关性,我们需要大量高质量的链接来喂饱它。

很多人大概会很反感看到这一连串PR的计算公式:PR = 0.15 + 0.85 ( PR(Backlink 1)/TotalLinks(Backlink 1) + PR(Backlink 2)/TotalLinks(Backlink 2) + … + PR(Backlink X)/TotalLinks(Backlink X) )。在我眼中PR计算公式并不能说明什么,重点在于你的页面上有什么,其内容是否是独一无二的,是否能给大众带来帮助;实际上越是那些实际内容空洞接近NULL的站点越热衷于提高自身的PR。

在最近SEO业界有着关于PageRank将变得不再可见(invisible)的流言,这源于部分网站坚信PageRank是它们的命根子,是它们生命价值的唯一体现,这一迷信。就我看来这棒极了,很多人大概不再会为了一个数字在别人的网站或博客上制造垃圾评论了。不少SEO方面的公司和专家以PageRank值作为它们成功的标志,显然PR不因该被拿来做炫耀的奢侈品,我们因我们的creation而自豪,绝非因为一个数字。

你大概见到过不少PageRank很低而SERP(search engine results page,如果你不知道这个术语那么不要在乎它,我们要避免陷入一个怪圈)很不错的站点,由此可以证明PageRank并不意味着较高的排名。

SEO没有错,这是一份正当的工作,但SEO真正应该完成的是让我们的页面受到与其内容相符的搜索引擎重视程度,而缔造非某些数字。

试用IE9 Preview

IE 9 Preview版现在可以从http://ie.microsoft.com/testdrive/下载到了:
[Read more…]

Gmail priority inbox帮助你减少工作量

全世界平均每天发送2940亿封电子邮件,而脑力劳动者每周花在邮件上的时间大约为13个小时。在过去的几个月里,出现过不少用以帮助用户有效使用Gmail的工具。今天,Google推出了自家的priority inbox。如果priority inbox的选项被激活,它会将您的收件箱分成三个部分:重要的邮件,打星号的邮件,其他所有邮件。该系统会自动识别邮件的重要性,并将那些紧急邮件在收件箱中置顶。

Gmail将允许用户进一步客制化Priority Inbox。你可以选择显示那些你关心的版块(好比说那些重要的,未读的,以星星标记的邮件)。当然你也可以很简单地关闭Priority Inbox功能。这一切客制化工作都可以简单地从Gmail的设置菜单中完成。

Google计划将这一令人振奋的特性向每位Gmail用户推广。

JailbreakMe.com-最新浏览器模式破解iPhones,iPads和iPod Touches方法

一位黑客建立了该网站(JailbreakMe.com),可以通过浏览器登录的形式破解几乎所有的iOS,这包括了iPhone,iPad,和iPod Touch,将解除Apple对这些设备的软件限制。

用户如果想尝试未经授权的app或者想在多个不同国家使用这些设备,都可以登录http://jailbreakme.com来实现破解。

很显然这是自上周关于破解iPhone等设备并不属于非法行为的判决后,对于Apple反对破解行为并声称破解对设备安全与稳定会造成影响的公然挑衅;我们不得不赞叹于黑客的卓越技术和开发速度。

破解设备将影响到设备正常的保修,Apple这样解释。但是实际上,破解操作可以很容易地被例如重置到出厂设置等操作撤销,如果安装了新版本的Apple mobile Operating System-iOS, 也可以达到撤销破解效果的目的。

“JailbreakMe”迅速成为Twitter上的热门话题,这极有可能是第一个以浏览器为基础的破解程序。在过去,用户一般都采用下载破解程序到个人电脑上,然后连通电脑与需要破解的设备的模式。

已经尝试的用户反映除了针对运行3.2.1版本的iPad存在问题外破解程序近乎完美。从打开Safari浏览器到登陆JailbreakMe.com下载程序完成大约耗时1分钟,程序会告知已将自身加入home screen,并祝你”have fun”!

装修记

2010年7月4日的样子,敲了很多墙:

7月31日,开始吊顶,大多数瓷砖都进场了,今天还去把马赛克买了。
买的马赛克:

厅里用的瓷砖到了:

开始铺客厅瓷砖:

Apple:破解iPhone或许合法,但仍会影响保修

天知道这在法庭上会是什么说法!Apple采取了一种积极防御的态度,他们指出破解(jailbreaking)iPhone,在今天可能是合法的,但仍将影响到保修。此外他们还表示真正会去破解IPhone的人只是那么一小撮,实在没必要因此而太过兴奋。

昨天的法律仲裁可能会是近几年最大的科技趣闻,同时也给了Apple一个机会。Apple公司的法律支持大概要花一阵子时间搞清楚破解(jailbreaking)这档子事了。事实是经过仲裁认定这是百分之百合法的。苹果公司当然没有义务为你提供一个专门用来破解的应用(jailbreaking application)-jailbreaking.app;但他们也不能够直接回绝你:“抱歉,我们禁绝任何破解!”。

一位苹果公司发言人这样对Mac狂热爱好者说:

苹果公司的目标是保证在使用iPhone时能获得美妙的用户体验,而且我们了解到破解其实是有损于这种体验的。正如我们之前所说的,绝大多数用户并没有破解的打算,因为那样做会影响到保修并且导致iPhone极不稳定也不可靠。

大体上我们不用质疑这份声明的诚意,但在末尾关于破解会导致iPhone极不稳定的纯属无中生有。如果破解存在诸多问题,怎么可能使整个社区致力于此?

【转】网络制图法(Internet Cartography)

fackbook的技术专家之一Carlos Bueno在这周一发表了这篇关于有趣的网络制图(Internet Cartography)的文章,如果你恰好”无法正常浏览“facebook的页面,那么也可以读读我所引用的:

Every generation likes to think it reinvents the world from scratch. But some things are shaped by history and geography as much as anything. Mountains, rivers, archipelagos, and long terrestrial crossings play a big role in deciding where, how, and how well different parts of the Earth get connected.

This is a map of the global telegraph network from 110 years ago side-by-side with the internet of today:

One way to see the internet is as a physical manifestation of trade volume between cities, on a 40-year moving average. That is about how long it takes for economic ties to develop, demand to rise, and high-volume communications routes to be financed and built. Once built, these links tend to stick around.

Governments and empires have come and gone, bandwidth has increased a billion-fold, but the network has the same general shape it had back when Mark Twain was sending witty telegrams. The only big change since then is greater ties between the US and Asia.

Just from looking at where the cables go you can guess how long it would take to send a message. A telegram from San Francisco to Hong Kong in 1901 must have taken many hops through British Empire cables to Europe, through the Middle East, and so on. London to New York was fast and direct. The vestiges of the Spanish and Portuguese Empires show up in the many links between South America, the Caribbean archipelago, and the Iberian peninsula.

A cool thing is that you can measure these relative latencies yourself, using the present-day internet. If you run a website with a decent amount of worldwide traffic, you can use that traffic to map out how the internet responds with regards to you, and see how that matches with the gross structure of the ‘net.

I wrote about a cheap and cheerful way to generate this data last year, and the code has since been open-sourced as part of Yahoo’s Boomerang measurement framework. The basic idea is to have your users perform two tiny network requests: one to a throwaway hostname generated in the moment, like 8j48sas.dns.example.net/A.gif, then another to a different single-pixel image on the same host, 8j48sas.dns.example.net/B.gif. The first request will require a DNS lookup, TCP handshake, and HTTP transaction. The second only needs to do the TCP and HTTP steps. Now you have fuzzy measurements of how long it took to do a full HTTP round-trip (B) and to do a full end-to-end DNS lookup (A – B).

Real-world data on DNS performance is generally considered hard to come by. The domain name system is designed with caching and intermediaries at all levels, so you as a site owner only see part of the story during normal operation. You can buy data like this from commercial services like Gomez or Keynote, or get it yourself if you happen to have, say, a browser plugin installed on millions of computers. Otherwise, this Javascript method is less accurate but works well enough.
xkcd.com/192

Here is a chart of median (50th percentile) DNS latencies experienced by a random sample of Facebook users, broken down by country. As you can see, there are several lines crowding together at the bottom. That is the US and parts of Europe like the UK and Belgium. Facebook’s DNS servers tend to be physically close to users in those countries. Spain and France are a bit higher up, and the rest of the graph is a mix of Asian and South American countries. [1]

The median value only tells part of the story. Here is the worldwide DNS latency data as a density plot, to show the distribution. Notice that a substantial number of users took more than 500 milliseconds just to look up a hostname. This is the uncached worst-case, of course, but it’s something to keep in mind.


HTTP Latencies
Here is the chart for measurement B, the TCP + HTTP latency. This better reflects the real “geography” of the internet, because the HTTP requests travel all of the way back to our web tiers in the United States. There is much less volatility in these measurements day-to-day; it’s controlled more by basic network conditions and speed-of-light and less by the health of various DNS recursors around the world.

How low can you go?
So how fast are these links between countries, compared to what is possible? Below is a chart of the same median HTTP latency data, averaged over a week. The short light-grey bars represent the theoretical minimum. If you could carve a direct line between any two spots along the surface of the planet, this grey bar would be the internet round trip time between the US and the given country. [2]

We can learn a lot of things from this chart. The most obvious is that HTTP latency between Asia and the US is worse than US-Europe. The Pacific Ocean is wider than the Atlantic, of course, but raw distance is not the only factor. Economics and local geography play their part.

Look at the ratios between the black bars (real) and the grey bars (theoretical). Both the fastest European and Asian countries have real-world latencies at or below 2X the theoretical minimum, which is pretty impressive. Few technologies get within spitting distance of the physical limits of the universe.

These low-multiple countries tend to have fortunate geography, or a strong history of economic relations with the United States, or both. Other countries with less-strong trade ties, such as Spain, or lots of little islands like the Philippines, have multiples nearer to 2.5X and above. While Australia is a bit farther than Thailand it’s 15% closer as far as the internet is concerned. More investment has been put in by the cable operators to make that route fast and wide. In fact, Australia (population 22M) a comparable amount of bandwidth to the US as all of South America (population 385M).

The multiples of South American countries start at 3.5X and go up from there. North-South routes are hurt by an unlucky trifecta of mountains, long land crossings, and archipelagos. There is only one cable that serves the Pacific side from Los Angeles to Panama. It’s hard to justify building lots of capacity on the Pacific side, because the Andes mountains cut off that part of the continent from the rest. Most traffic follows a long and painful path across the entire length of the US to the Atlantic, then takes a right turn and down another 800 miles of the Florida peninsula. It exits Miami and immediately hits a congested maze of cables, hopping in and out of the water as it navigates the islands of the Caribbean. Someday South America will get better connected, but natural barriers drive the costs way up.

There are other interesting cases such as Belgium, which has the lowest latency and lowest multiple (1.6X) of any European country. The reason is that Belgium is well-placed as an internet nexus, being a) close to Britain but away from the Channel and b) geographically convenient for branching off into the rest of Europe.

Try this at home
These measurements are very skewed towards the United States. It would be awesome to see measurements from other spots and different traffic patterns from around the world. The code to collect this data (and a lot more) is open-source and simple to implement. So try the experiment for yourself and let us know what you find.

Carlos Bueno, an Engineer at Facebook, loves pinging the tubes.

Notes
[1] This chart generally agrees with data gathered by Yahoo and Microsoft. The data is very US-centric; the picture will be quite different if you were to run the experiment from a site based on another continent. Facebook’s servers are largely in the US, so naturally we care most about how to get bits from here to there and less about, say, between India and Saudi Arabia.

[2] The theoretical minimum latency is calculated using the average speed of light through optical fiber, over a hypothetical cable laid in a great circle line between the town of Independence, Kansas and the centroid of the given country. This time is multiplied by 4 to approximate the two round-trips necessary to complete a TCP handshake and HTTP transaction. You can read all about Great Circle routes and the speed of light through fiber in Wikipedia, or just use Wolfram Alpha to do it for you.

facebook发布了Tornado V1.0

想要在您的站点上实时体验海量活跃用户的负载?我们来介绍一种最新的方式,这种新的实时网络框架被命名为Tornado(中文为龙卷风);Facebook从去年秋天开始研发该软件,最近以开源协议发布了该软件的1.0版本。

Tornado是基于Python开发的实时网页服务器,理论上可以支持上万的连续连接,使用长轮询方式进行实时数据传递。它是构成FriendFeed的核心技术,FriendFeed最初由2名前Google员工及多名网络社区领导人协作开发,在2009年FriendFeed被facebook所收购。Facebook公司现在的CTO:Bret Taylor进一步扩展了该软件。

Bret Taylor在过去几年中曾是Google Reader的主要开发者之一,之后他加入了real-time网络社区,并同Taylor一起启动了FriendFeed项目。之后FriendFeed被facebook收购,Darnell重返thing实验室,并领导将Tornado开发到现在的V1.0版本。

可以从这里进入Tornado的官网并下载下载到源代码tar包。

Twitter将启动其在犹他州的客户数据中心

常用twitter的用户可能感觉到了,该网站在过去几个月中出过一些过载导致无法访问的故障。世界杯期间每天300000新建用户的增长是造成过载的一个重要因素。这也推动了twitter建设自己的数据仓库存储中心。他们正在建设的一个数据中心,位于盐湖城。

虽然毫无疑问该中心将不及苹果在北卡罗来纳州耗资10亿美元建设的数据中心庞大。 Twitter发言人称他们正加紧建设一个为自身定制的数据中心,并将在今年启动。

“拥有独立的数据中心,将给予网站更大的容量,以适应用户的增长”Twitter的jean-Paul Cozzatti在其技术博客中写到。

“在该数据中心,Twitter将有能力完全控制其网络及系统配置,将占用大块商用面积,并使用特殊设计的电源和冷却设备。该数据中心将采用多个供应商提供的服务器,并且运行开源操作系统和应用程序”。

直到最近,Twitter仍使用由日本电信电话株式会社NTT美国公司在海湾地区建设的数据中心。”我们仍将和NTT美国合作管理现有的中心,这尚是我们首次定制数据中心”,一位Twitter发言人这样告诉我们。

这是自facebook在1月份公开其独立数据中心以来大型社交网站的又一重大举措。facebook的数据中心位于俄勒冈州,那里聚集了众多其他公司的Datacenter,包括亚马逊和谷歌。巨型网络公司扎堆于是有原因的,这里可以提供廉价的电能和适宜的气候(够凉爽),以及公司税收优惠。

近期Twitter出现了因大量无法正常访问的用户投诉(最主要的恐怕是有时无法注册新用户)而引发的公关危机。Twitter公司的博客大致叙述了他们的问题,Cozzatti-Twitter公司的主要技术负责人之一的博客也详细地描述了该问题。最主要的问题在于每周一,Twitter的主用户数据库会因为一个查询而卡住,此时整个系统都被锁定了。他们不得不重启该数据库,这个过程历时超过12小时!现在你或许理解他们需要对系统拥有更多控制权的苦衷了:)

”我们时常对比在各种在收缩,维护,调整Twitter这一飞翔中的火箭的工作”Cozzatti写到。

原SUN网站:java.sun.com,developers.sun.com,bigadmin将合并到OTN

就OTN上发布的合并声明来看到8月1日,Oracle将完成java.sun.com,developers.sun.com,bigadmin这几个网站合并到OTN的工作,这次迁移将是完整的并且在内容上是无损的。整合后的网站将提供给java开发者,数据库开发者及管理员,系统开发者及管理员一个多样的技术社区。

同时Oracle保证通过重定向技术确保用户原先的网页书签不会失效;java开发者仍可以像以往一样轻松获取java api信息;Oracle暂时不会修改java技术页面内容的构成,开发者目前不用担心不适应(我从metalink到MOS倒是很不适应,所幸现在好了);

docs.sun.com以及原sun旗下的论坛,博客,维基将暂时不做迁移。如果用户有问题可以向社区反馈讨论版反映。另外作为这些网站的原用户可能需要在OTN新注册一个成员账号。

PS:

7月30日,合并似乎提早了,OTN的界面有了极大的变化,就我个人而言似乎还是老的界面比较对眼!

沪ICP备14014813号-2

沪公网安备 31010802001379号