按照惯例，年底的 淘宝 的确是到了「需要改版的时候」。这次新版的淘宝首页上线，乍看并没有多少夺人眼球的地方，但仔细揣摩其中的细节，还是发现了不少的改变。

其中有一点就是感觉页面留白过多，仔细看了下发现是页宽从 原来的 960px 拉伸至 1000px。

不要小看这个增加了的 40px 页宽，这对于设计师们而言可能是做了个「异常艰难的决定」。

混沌时期

还记得用 Win98 拨号上网的时代吗？那时候分辨率也小得可怜，800x600 的标配分辨率甚至都不及当前的某个高端智能手机。

不知道什么时候开始，网页的页宽有了个经典宽度 600px -- 当然，那时候谁都不会在意它。

960 时代

后来，这个故事变得简单而且老套：随着硬件的发展，分辨率也不断的提升。从 1024x768 到 1280x800 再到 1440x900 甚至更高（ 这里有个统计 ）。

网页的页宽数字也在不断的增加，比较经典的几个数字为从 600px、740px 直到 960px 。然而这时候标准线出现了，那就是 960 页宽。

以淘宝为例，我印象中 960px 页宽从 2006 年沿用至今（2011）已经整整五年。这相比二十一世纪的前五年的页宽改变趋势而言，这实在是让人感到有些变化不大过于拘泥。

当然，设计师们采用 960 这个数字当作页宽的布局方案也有其道理：

1. 其能兼容大部分的屏幕分辨率。800x600 已死，剩下分辨率最小的也有 1024x768。那么，为了更可能多的展现内容，页面的宽度自然会在 800-1024 像素之间，960 设置数值差不多是个中间值，不多不少刚刚好。
2. 960px 方便栅格化布局 -- 其实从数学的角度上说，这个观点有点站不住脚。不过 960 页宽的栅格是最早出现的， 同时也是最广泛使用的 （附， 淘宝的栅格系统 ）。

打破僵局

既然 960 页宽已经足够好，沿用传统的页宽也并不会犯错，那么回过头来我们再看这次淘宝首页为何要改变成规。

根据我的个人观点，可以总结部分：

1. 960 页宽已经显得「过时」，1024x768 像素会像当年的 800x600 一样，迟早会被更大数字的分辨率所淹没。
2. 需求的驱动，需要在页面中加入更多的内容。想想页宽增加 40px 乘以页长，整个页面将会多出多少设计和内容填充空间。
3. 1000px 这个整数更容易计算和安排栅格 -- 不过从数学上这个说法也很难站住脚。不过整数 1000 的整除数比 960 多多了，也更容易安排。

单单 40 像素的改变，对于「粗心大意」的用户而言似乎无关痛痒（当然，也可以理解为淘宝其实不想让用户过多得在意他们的改变）。

个人觉得 1140 页宽 也是可以考虑的数字。那么，还有会不会有更大的页宽数字出现？我想应该会控制在 1200px 以内， 否则将会给用户阅读带来困扰 。

未来

我们来预测下未来的经典页宽将会是什么数字？说实话我也不知道，这一答案完全在设计师脑子里。有点可以预料到的是，移动上网设备的兴起会有促进两个大的趋势：

1. 向下兼容针对小屏幕的弹性页宽（ 详见 ）。
2. 页面布局将会针对不同的设备而定制，因此 800px 以下的页宽将会「复活」。

-- Split --

这次广泛采用 HTML5 标签、加大页宽等等的改变，看得出淘宝一直在做着细节方面的尝试和调整。然而从不谐调的留白、布局的不协调看得出来，淘宝对于新的页宽经验稍显不足。

但愿 1000px 这个页宽将又会是个经典的数字。毕竟，不客气的说，「山寨」淘宝首页的站点实在是太多太多了。

PS，淘宝还给我们留了个小彩蛋，新版在首页搜索框中输入「about:staff」会有惊喜（相应代码在 1970 行开始） :^D

-- EOF --

此篇为译文，原文在： http://37signals.com/svn/posts/2710-designed-by-apple-in-california 或许可以从设计师角度部分诠释 Apple 此做法的用意。

-- Split --

我曾经在 很多场合中提起 ：「‘Designed by Apple in California’ 这段字，我是见过的所有包装上最为夺目的字符」。我的其中位读者 迈克尔 问我：

我同意您的看法，我第一眼看见这段字就让我难忘。
…
不过我很好奇，为什么您会相信「这些夺目的字符注
定会出现在不起眼的包装上」。

这句简单的标签出现在 Apple 的产品及其包装上至少已有十年的历史。（其实，我无法明确准确的时间说明 Apple 是从什么时候开始，但我记得在 2000 年的时候，苹果就在其 iPod 的包装上打上这行字了。）

这说明这句短语的历史是多么的悠久，同时对于 Apple 而言是多么的重要。

背景

「Designed by Apple in California」 这段字是多么的显眼。

当你拿到 Apple 产品的时候，打开包装的皮瓣或者内页那一刻，这段字通常会独立一行印在简洁的包装上 -- 它太显眼了，你几乎不可能错过它。

然后，你缓缓的翻开包装，继续拿出你梦寐以求的设备 -- 这个过程是多么的自然，同时这个体验让你近乎难忘。

情感

Apple 的使命之一是唤起了人们对艺术的感受。Apple 的每件产品，就好比匠人精心制作的作品，被精心包装后安全地送到家门一样。这件产品似乎顷刻间就被赋予了情感，就犹如它是被你所爱的人制造出来一样。

匠人们都会在自己得意的作品上签名。克莱默大师会将他 自己的名字篆刻在每把他经手的刀上 ；佛蒙特设计的家具，在其 每个产品不起眼的位置都留下自己的印记 。 爱德华建议 每个设计师将他们设计的产品署名 -- 这表明你是精心的造就了该产品，并赋予它最好的品质。

或许，我们能了解 Apple 这行字的用意即为如此。

此外，它标注的不是「Made by Apple in California」，而是被设计（Designed）的。我很难想到还有其公司会将设计（Design）放在如此高的地位。它的每件产品似乎注定是被设计出来而非制造。同时，这也是该公司使命的最好表述。

此时无声胜有声

平面设计领域中有句这样的话：

如果你想让它显眼，那么就把它放大吧！如果你想将其变
得更突出，那么加边框！仍然不够？那么就把他标红。

放大、加边框、标红，这些技巧明显是那些懒惰的设计师常用的伎俩。我们之所以认为这很愚蠢，原因之一就是它过于明显的表达了自己的意图。

话到此，我们或许能 Apple 熟谙这种微妙。Apple 通过突出传达这句话（绝对不会存在任何无视它的机会），来突出产品。这段文字小而优雅，就想是与产品本身浑然天成。我们感觉不到任何的意外和惊讶。

在我们阅读它以后，Apple 不需要任何过多的言语，去复述传达自身产品的品味和价值。因为，此刻用户已经了解。

-- Split --

后记，文章发表后， 发现已经有哥们翻译了这篇文章了 ，两个版本的译文对比着理解吧。

下面说说我的看法。不容否认，苹果的成功让人们更多的关注这个公司的任何地方，有些甚至有些很不经意的细节都会被无形的放大以及被咀嚼，其中就包括上文「Designed by Apple in California」这段小字。

我们应该能理解，苹果的成功从另方面讲是许多个数不清的这样的细节组就而成。任何物品经过精雕细琢那么它的价值往往会多于它的本身，包括产品、设计、还是编码，其实都是这样的道理。

还是有个问题和期待就是，什么时候我们的「Made in China」变成「Designed in China」？

-- EOF --

简介

nginx_concat_module 是 淘宝研发的针对 nginx 的文件合并模块 ，主要用于 合并前端代码减少 http 请求数 。如果你的应用环境中部署了 nginx，那么可以考虑尝试此模块减少请求数。

安装

安装 nginx_concat_module 需要重新编译 nginx。 可以从这里 checkout 最新的代码 ，

svn checkout http://code.taobao.org/svn/nginx_concat_module/trunk/ $NGINX_CONCAT_MODULE

然后下载适合你自己版本的 nginx 源码包 ，在 ./configure 中增加参数

--add-module=$NGINX_CONCAT_MODULE

就可以继续 nginx 的编译安装过程。

Tips

顺便废话下，默认编译 nginx 的 gcc 参数带了 「-g」 开关。处于洁癖和性能考虑，可以考虑将其关闭。编辑文件

$NGINX_SOURCE_DIR/auto/cc/gcc

注释掉下面的行

CFLAGS="$CFLAGS -g"

如果觉得有必要，可以修改下面的编译参数（感觉性能提高不大）

NGX_GCC_OPT="-O2"

配置

新的 nginx 编译安装好以后，配置 nginx_concat_module 主要有如下的选项

# nginx_concat_module 主开关
concat on;

# 最大合并文件数
# concat_max_files 10;

# 只允许同类型文件合并
# concat_unique on;

# 允许合并的文件类型，多个以逗号分隔。如：application/x-javascript, text/css
# concat_types text/html;

（详细察看安装包下 INSTALL 和 README 文件）。其实不用那么复杂，简单的配置

location / {
     concat    on;
}

就可以合并 javascript、css 等文件了（顺便注意是否和 rewrite 规则冲突）。

使用

上面的图可以说明如何使用 nginx_concat_module 。随着以后的深度使用， 如果感觉 url 过长， 那么就要考虑另一种优化了 。

ps，再罗嗦句，有关 nginx_concat_module 性能方面的忧虑，我想应该可以让人放心，尤其是看了淘宝首页的源代码以后 :^)

有关 nginx_concat_module 的任何意见和建议，可以联系其作者 Joshua Zhu <shudu[at]taobao.com>。

-- EOF --