考虑到22寸LCD近一年来已经便宜得成为主流尺寸了，对于由于价格房子等种种因素不太想买大电视的玩家来说，还是一个不错的选择。

早晨起来发现脚下躺着一头，另一头在悠悠的走去喝水

大概是因为看过功夫之王，所以对这种中西噱头大锅炒的片子已经免疫力增强了，看到兵马俑大战骷髅兵、李连杰变身三头飞龙，破卡车追逐地狱马车外加RPG单兵火箭筒版大烟花轰炸什么的也觉得挺乐呵的。这片子2个小时还是塞得挺满的，看的应接不暇。不过感觉里面中国人的戏份是非常的多，不知道老外是不是买账。

刚开始把火罐吸到身上的时候还没什么痛的感觉，移了一会儿之后反倒变痛了。我就问这压力不是应该越来越小么，怎么会反倒疼起来了，回答是我背上在出痧，所以会疼，555。

再就是好像南方人对火罐刮痧这些东西都比较了解，一般家里都能简单做做。我就一直都不知道这些是干什么用的。

Google also say they’re using a “multi-process design” which they say means “a bit more memory up front” but over time also “less memory bloat.” When web pages or plug-ins do use a lot of memory, you can spot them in Chrome’s task manager, “placing blame where blame belongs.”

If this is true and there's a process manager which allows you to see how many resources are being consumed by a particular browser tab (including plugins!) this will be a 100% killer browser feature.

It simply isn't possible to implement with current browser architectures which brings up two points: 1) Browsers haven't tackled it due to the extreme amount of code rewrite that it would cause and 2) that there's a general consensus that this architecture will actually consume more resources than the current architectures.

This is important. Since there's no sharing going on between the tabs of the browser it's not possible to easily reduce the amount of duplicate resources. For example, within the Mozilla Gecko engine there's a lot of code reuse occurring, which allows for significantly reduced memory consumption (and optimized memory collection and defragmentation).

But here's the rub.

The blame of bad performance or memory consumption no longer lies with the browser but with the site.

By implementing this feature a browser is completely deflecting all memory or performance criticism off to individual site owners ("Yikes, my browser is using 300MB of memory! Actually it's just youtube.com consuming 290MB of it, they should fix their web site!"). This is going to be a monumental shift in the responsibilities of web developers - and one that will serve the web better, as a whole.

Of course there will still be overhead associated with the core browser - but, presumably, this will be marginalized.

This is an incredibly devious (in the best sense of the word) tactic and it's one that browser vendors will be forced to respond to. How the response will occur is another matter entirely.

Once the response occurs, though, two things will happen: Browsers will begin to compete on reducing specific memory/performance numbers for specific sites (it happens now - but with the numbers made obvious users will beg for it) and browsers will be enticed to lie.

Since the browser is the new harbinger of the de-facto "accurate performance metrics" (it's no longer the Window Process Manager, for example) they'll have to take every opportunity to exaggerate those number to their benefit.

On so many levels this new feature will change the way browsers are constructed and how they communicate to the user. Even if Google Chrome launch does nothing but fall off the end of the runway in a fiery explosion, users will be intrigued, and the seed will be planted: Browsers must find a way to respond.

Update: A screenshot has been posted showing the task manager:

It's quite small (and, seemingly, quite spartan) but it appears to detail three properties of every tab: CPU usage, memory usage, and network usage.

It's going to be fascinating to see what type of user-centric UIs come around this. Tabs that use a lot of CPU turn red? if they consume a lot of memory they grow larger? It seems like there's a bunch of ways in which the quality of the tabs could be appropriately communicated.

北京南站

View Album

这两天的天是格外的蓝，白天出去的时候太阳晃得人都睁不开眼。可惜诸事缠身，没能如愿出游一趟，下周，下周一定，嗯。。。

问了问iphone水货的价钱，港版7k+，美版5k+，都是令我OTL的价格，还是算了……nnd，怎么这么贵了。

周末吃了一次牛排，在西单君太地下的Sizzler，我觉得还挺好吃的，就是有些贵……一个疑问是牛排到底应该是多厚啊？这次吃的这个挺厚的感觉差不多有两厘米，但是我以前吃的似乎都是一厘米多点。

早晨一早送小侯去北京南站坐车。九年前我考理科班的时候来这儿坐过一次车，那时候还是在一个破院子里面检票，候车厅检票厅都没有。现在已经翻修一新成了北京最新的火车站了。一路走过去的感觉就是真像飞机场……看这候车厅

还有这个有中国特色的内网IP。。

  skip_before_filter :authenticate, :only => [:login]

But if somehow we did calls in this format twice

  skip_before_filter :authenticate, :only => [:login]
  skip_before_filter :authenticate, :only => [:index]

Then only the latest one will work, the action “login” will be filtered by “authenticate” again, in the example above.
This is a little bit reasonable, because you might mean the latest set when you specify “only” repeatedly. But it WAS a pitfall I fell into. Maybe an option like “:overwrite” on the “before_filter” will be more friendly to user.