夕角的足迹

今天刚收到的，折腾系统中…

关于这三个配置项的差别，apache的文档里都有，但讲得不是那么明确，特别对英文水平不好的人来说，容易搞混（好吧，我承认我搞混了 囧rz）。

是对apache在访问本地文件时在目录级上上进行限制，除了本身的服务目录（比如/var/www/localhost/htdocs）外，都要另外设置。要不，apaceh会说，配置不允许。当然，你也可以设定成允许对 / 访问，那么只要apache进程的所属用户ID能访问的，apache都会乖乖地取出来给你，但从安全上来说，这个不推荐。
比如你把 www.example.com/downloads 映射到 htdocs 外的 /var/downloads，那么，除了设置映射的语句外，还要加上


<Directory /var/downloads>
Options None
Order deny,allow
Allow from all
</Directory>

也是对本地的文件访问进行限制，不过是从文件名上进行匹配。这个主要用于防止特定文件被用户下载，比如类似.htpasswd的密码文件。来个例子，不允许访问index.html配置项：

<Files index.html>
Options None
Order deny,allow
Deny from all
</Files>
则是从url的路径部分进行匹配。啥叫路径部分？比如 http://example.com/abc/def 这个url的路径部分就是 /abc/def 。要允许对 /abc/def 的访问，则配置项如下：

<Location /abc/def>
Options None
Order deny,allow
Allow from all
</Location>

当然，httpd.conf的访问控制不只有这么简单，这些访问控制会组成类似于防火墙的规则链，以更进行更深层次的控制，要了解更多就去看apache的文档吧。

October 2nd, 2009 by vgod

之前在[HCI] 谈人机介面设计与Usability一文中提到了usability的概念，并用了Windows的开始钮说明了在设计UI上容易忽略的陷阱。这篇文章我会继续探讨介面设计与usability，并以效率(Efficiency)与UI设计时最重要的定律之一费兹定律(Fitts’ Law)为重点。

设计软体的操作介面并不难，但很多时候直觉的设计并不一定能达成想像中的目的。这就是usability的研究想要了解的，到底什么样的设计才是「更好」的设计？什么样的设计其实只会让usability变得更糟？

以menu bar为例，menu是图形介面(GUI)的最基本元素之一，现代软体功能越来越强大，包山包海的结果就是menu变得越来越多、越来越深，每一个menu展开后几乎都有sub-menu，甚至还有sub-sub-menu等等复杂的选单。我每次教我爸妈用电脑时，都觉得Windows的menu根本是设计来折磨使用者的，奇妙的是竟然很少听人在抱怨这介面很难用，而是纷纷强迫自己「学会」这种操作模式。

我想会看到这篇文章的读者，早就很习惯于操作GUI了，也没想过选单能有什么好用或难用之别。所以先让我们来想想要开启一个埋藏在sub-menu里的功能是多困难的工作（就假设是档案/最近开启/某档案.txt好了）。第一，把游标移到menu bar的「档案」上，并停住不动；第二，按下滑鼠左键打开档案选单，把游标「垂直往下」移到「最近开启」上停住；第三，等sub-menu打开，把游标「水平往右」移进sub-menu里；第四，再度「垂直往下」找到某档案.txt，在上面停住并按下左键。好，想像完毕后你可以试着用你的非惯用手操作滑鼠做一次看看。

如果是已经很熟悉GUI的使用者，想必都不觉得操作选单有什么困难的，但当你被迫用非惯用手操作时，一定会感觉到操作速度大大的降低，甚至没办法精准控制游标进入sub-menu，这时我们才有机会体认到操作滑鼠其实并不容易。除此之外，如果仔细观察，还可以发现进入sub-menu又比平常把游标移到任意地方还困难，因为必须把游标保持在一条狭长的「隧道」里水平移动，如果在移动时不小心移出了这条隧道，sub-menu就会关闭。

有个有趣的案例发生在一个着名的open source影像处理软体GIMP上（可以说是免费版的photoshop）。当初开发GIMP的团队曾做过一个有趣的决定，他们决定拿掉固定在视窗顶端的menu bar，并用可以在任何地方按右键打开的context menu取代。因为context menu可以在任何地方打开，GIMP的开发团队认为这样可以加快存取menu的速度。这个想法很直觉，但真的对efficiency有帮助吗？

既然我都说了这么多，答案当然不会是yes。

context menu对efficiency并没有帮助，反而使之变得更差。为什么呢？

如上图，从第一层的选单要进入第二层时，必须先经过第一层狭窄的隧道(红色区域)，才能进入第二层选单。如果直接走直线路径到想要按的目标，就会先经过第一层的其他项目，导致不同的sub-menu被打开。传统的menu bar也是有sub-menu，所以直觉上可能不会觉得多一层的sub-menu会有多大影响，但事实上是这种把游标限制在一条隧道里的设计大大的降低了操作游标的速度，和一般可以经由任意路径指到目标的操作有指数级的速度差异。

Fitt在1954年提出了Fitt’s Law，可以说是人机互动领域的第一条「定律」，对人类指向任一目标的动作建立了一个数学模型。基本的概念是，移到目标上的时间(T)可以表示为目标距离(D)与目标大小(W)的函数。具体来说，T = a +b log₂(D/W+1)，a和b都是一个常数。

Fitt’s Law告诉我们，移到任意目标上的时间大约跟目标距离除以目标大小的对数成正比。也就是说，目标越远移动时间就越长，目标越小时间也会越长；反之，目标越近或目标越大的话，所需时间就越短。有趣的是，距离和目标大小的影响并不算大，经过log让这两个变数的影响降低了一个指数等级。例如距离变长1000倍，并不会让时间也变成1000倍，而是变成log₂(1000)，大约是10倍而已。

在软体介面上，Fitt’s Law有个特例值得讨论一番。在电脑里的滑鼠游标，有个基本特性是其活动范围被限制在萤幕里，只要游标到了萤幕边缘，无论再怎么继续往同一个方向移动滑鼠，游标还是只能停留在边缘上。这个特性让UI设计有了戏剧性的变化，一个最有趣的例子是Windows和Mac OS X的menu bar设计。

Microsoft的Windows自古以来的UI设计都是把menu bar放在视窗的title bar下面，而Mac OS採取完全不同的设计：把menu bar固定在萤幕最顶端。一般人大多觉得这两种设计只是习惯问题，没有什么客观差别，但如果你已经学会了Fitt’s Law，你觉得哪一种设计比较好呢？

如果直接套用Fitt’s Law，第一个得到的答案很可能会是Windows的设计比较好，因为当滑鼠从视窗内移往menu bar时，距离会比移到萤幕顶端还近。可是，别忘了考虑萤幕边缘所造成的影响。Mac把menu bar放在萤幕顶端，虽然距离变长了，但目标的大小也跟着变成了「无限大」。因为萤幕的边缘会阻挡住游标的行动，于是使用者可以尽情的把用力滑鼠往上一甩，不用停下来「对准」目标，也就等同于目标的大小变成了无穷大。在Fitt’s Law中，当W是无限大时，整个log函数得到的结果会变成0，也就是说T就会变成一个简单的常数值a，跟距离或大小都没有关系了。

如此比较之下，我们就可以发现Mac把menu bar放到萤幕顶端是有其用意在的，因为它大大减少了把滑鼠放进menu bar并对准目标的时间，使用者只要把滑鼠用力往前一移，自然就会进入menu bar里面了。我在[HCI] 谈人机介面设计与Usability一文中也提过Windows开始钮的例子，跟menu bar的例子也是相同的道理。

到目前为止，我们已经看过了三种形式的menu。对于efficiency而言，我们知道Mac的设计比Windows的设计还好，那如果和GIMP的context menu比起来呢? 从Fitt’s Law可以得知，Mac的设计已经达到极限了，无论如何也没办法捨去那个常数a，所以我们可以直接来比Windows的设计和GIMP的设计哪个比较差XD。

前面提过，sub-menu是一种很难的指向操作，除了要把游标移到目标上，还限制了中间经过的路径在一个隧道里。在Fitt’s Law之后，Accot and Zhai提出了 Steering law。其结论非常简单，让游标经过一个宽度W的隧道移动距离D的时间 T = a + b * D / W。换句话说，把移动路径限制住的话，其移动到目标的时间和一般性移动(Fitt’s Law)所需的时间是指数级的差距，这也就是为什么电流急急棒可以变成一个有百万奖金的挑战，而随意动动滑鼠则简单的多。

了解了Steering law之后，再回来看sub-menu的设计，你就会发现sub-menu是一个多不人道的设计。每一层的menu其实都是一个steering操作：垂直的menu移动比较简单，因为menu宽度通常都蛮宽的；但每当要水平移动进入下一层sub-menu时，就是一个困难的挑战，因为这时的宽度变成了menu item的高度，通常也就是一个字母高而已。和Fitt’s Law不同的是，宽度(W)变小n倍，对时间的影响不再是对数，而真的就是让时间变长n倍。所以说呢，如果可以迅速又准确进入多层sub-menu的滑鼠高手，其实也有参加电流急急棒比赛的能力呢！

回过头来看Windows和GIMP的menu设计，这时就可以明显比较出来。GIMP把所有的选单操作全都变成了steering操作，Windows虽然也有sub-menu的问题，但至少第一层还是任意的指向操作，所以就efficiency来说，GIMP的设计其实是一大失策..。

最后，再顺便提两个Windows和Mac OS X对于sub-menu造成的问题所提供的解决方法。微软和Apple都知道sub-menu很难操作，所以他们其实都有偷偷的在介面上做了一点贴心的设计。微软的方法是，在游标要进入sub-menu时，如果不小心移出隧道外，只要在一定的时间内移回来，sub-menu就不会消失。这个方法其实有些风险，主要是因为这个「时间」很难掌控。如果这个设定的时间太短，那就没多大效果；但如果设定太长，使用者如果是真的想要移到别的menu item打开另一个sub-menu，就会觉得系统反应太慢（就是那种顿顿的感觉）。所以，微软的这个方法其实并不是很有效的解决这问题。

而Apple虽然也是用同样的方法来sub-menu不要马上消失，但他们又加上了一个聪明的设计：sub-menu的延迟消失只有在游标到sub-menu的顶端和底端形成的三角形内有效。换句话说，如果使用者是想进入sub-menu中，他甚至可以直线移动滑鼠进入其中而不会意外打开另一个不同的sub-menu（只要在设定的延迟时间内移动完成）。而假如使用者是想打开另一个sub menu，那直觉的把滑鼠往下移动就会自然的避开这个三角形区域而避免了「顿顿的」感觉。

在UI设计上，Apple一向是比其他公司用心许多。这种聪明的设计虽然很小（甚至没什么人会注意到），但在每天反覆的使用中就能自然减少使用者的挫折感和提昇操作的流畅度，这也是为什么我常说Mac有许多贴心的设计，用起来会自然让人感觉很愉快，而其他系统在UI设计上所下的功夫就明显不足了。

原文链接

如题，好大一个悲剧…

注意看EVE的学习曲线，很有喜感

这是一个平凡的故事，里面的男主角很平凡，甚至有不少缺点。奇怪的是，这么一个平凡的故事，却能让浮躁的我坐下来，静下心看完。也许是因为对剧情的共鸣。说到共鸣，想到一点，能遇上那么一个可人儿主动对你示好，最后对你死心塌地，相信几乎所有性格内向的男生都有过这样的幻想（笑）。而我想说是共鸣是指个人的成长，从一开始就对这么一个性格极度内向，有交际障碍，还很孩子气的男主角如何泡到MM很有兴趣。当然情节总结起来也就那几句话，偶遇，相互吸引，走到一起，冲突，最终成为圆满的一对.……从男主角的主角说，是他突破自己的过程：害羞地出手（拉着女主角，讲宇宙大爆炸），呆呆地追击（穿宇航服爬窗户），笨拙的浪漫（到公园看狸猫），到最后能分辨出好心的谎话，找到适合自己的工作，破除了交际障碍等等，几乎都是顺理成章的收获。米国的电影几乎都有个特点，就是关注个人的成长，强调一分耕耘一分收获道理，也许这就是我们现在最欠缺的吧。

英语原文
中文翻译

在过去的N年中，我遇到了很多使用囧然不同风格的开发者，下面是我所知道的一些，你还知道其它的吗？

散弹枪编程

这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯，这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”，当然依然出错，于是我们的程序员会这样：“好吧，那我就注释掉整个方法吧”，或是其它更为随意的处理方式，直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。

如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地，那么，那个正规的程序可以马上变得发疯起来，并且，可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程，这是因为他们破坏性的才能会造成的伤害会比只有一个还差。

撞大运编程

这是一种比散弹枪编程要温和一些的编程方式，我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道他们在干什么，也不知道所写的程序的本质和实际，但是可以让程序工作起来。他们以一种撞大运的方式在写程序，某些时候，他们根本就不知道某个错误的原因，就开始稀里糊涂地修改代码。一旦出现问题，他们会用两条路：1）停下来，理解一下程序，找到出错的原因。2）使用散弹枪编程方式开始解决问题。

测试驱动开发（Test Driven Development）是一种可以用来拯救上百万的撞大运编程的程序员。于是，他们有了一个更为NB的借口：只要我的程序通过测试了，你还有什么话好说？别骂我，测试驱动开发是一个不错的事物，其主要是用来控制撞大运开发所带来的问题。

Cargo-Cult 编程

关于Cargo Cults 这个词儿来自二战期间的某些太平洋上小岛里的土著人。在战争期间，美国利用这些小岛作为太平洋战场上的补给站。他们在这些小岛上修建自己的飞机跑道以用来运输战争物资。而那些小岛上的土著人从来没有见过飞机，当他们看到飞机的时候，觉得相当的牛，可以为那些白人带来各种各样的物品和食物。当二战结束后，那些土著人仿照着修建了飞机跑道，并用竹子修建了塔台。然后就在那期望着有飞机为他们送来物品和食物。

Cargo Cult 编程是一种非常流行的编程方法，使用这种方法的程序员会学习其它编程高手的编程方法，虽然他们并不知道为什么高手们要那样做，但是他们觉得那样做可以让程序工作起来。举个例子，当时有大量的程序员在J2EE出现的第一年中过度地使用了EJBs和Entity Beans。

刻舟求剑编程

刻舟求剑是一个很流行的寓言了。这种风格的编程在程序员的圈子里是非常常见的。比如，有一天，你发现了一个空指会的异常，于是你到了产生空指针异常的地方，简单地放上一个判断： if (p != NULL)。

是的，这样的fix可以让你的程序工作起来，但你并没有真正地解决问题。你只不过是在你的船边记下了剑掉下去的位置，这样做只不过把问题隐藏起来，最终只会让你的程序的行为变得神出鬼没。你应该找到为什么指针会为空的原因，然后再解决这个问题。

设计模式驱动型编程

正如这种编程的名字所说的，这种编程风格使用大量的设计模式，在你的程序中，四处都是设计模式，你的代码到处都是Facade，Observer ，Strategy，Adapter，等等等等。于是，你的程序要处理的业务逻辑被这些设计模式打乱得无法阅读，最后，也不知道是业务需求重来，还是设计模式重要，总之，实际业务需求的程序逻辑被各种设计模式混乱得不堪入目。

侦探型编程

在解决一个Bug的时候，侦探型程序员会调查这个Bug的原因。然后，则调查引发这个BUG的原因的原因。再然后，其会分析修正代码后是否会导致其它代码失败的因果关系。再然后然后，他会使用文本搜索查找所有使用这个改动的代码，并继续查找更上一级的调用代码。最后，这个程序员会写下30个不同的情形的测试案例，就算这些测试案例和那个Bug没有什么关系，最最后，这个程序员有了足够多的信心，并且精确地修正了一个拼写错误。

与此同时，其它一个正常的程序修正了其它5个Bug。

屠宰式编程

使用这种风格的程序员，对重构代码有着一种难以控制的极端冲动。他们几乎会重构所有经手的代码。就算是在产品在Release的前夜，当他在修正几个拼写错误的bug同时，其会修改10个类，以及重构与这10个类有联系的另20个类，并且修改了代码的build脚本，以及5个部署描述符。

switchy现在可以制定规则，规定哪些网站需要用代理了，hoho.