略懂 HTML 的朋友都知道,如果想让一个链接在新窗口中打开,通常的做法是利用 target=”_blank” 来设定 a 标签。例如:

  1. <a href=http://jennal.cn target=_blank>Jennal.cn</a>

这种做法确实比较方便,但在 XHTML 1.0 Strict 中去掉了 target 属性,也就是说我们不能再利用 target 属性来控制链接的行为。虽然当今流行的浏览器在 XHTML 1.0 Strict 甚至 XHTML 1.1 下扔能正确执行 target=”_blank”,但这样的代码毕竟是不规范的,不推荐使用。

很自然,我们会想到用 Javascript 来解决这个问题,我通常是使用下面的方法:

  1. <a href=http://jennal.cn onclick=window.open(this.href);return false;>Jennal.cn</a>

这样虽然可以满足要求,但是当链接很多的时候,代码就显得有些臃肿了。为了简化代码,我们应该用 DOM Event / DHTML 的方法来解决这个问题。今天我恰好在做一个网页,需要使用 XHTML 1.0 Strict,准备自己写一个这样的 Javascript。不过幸好我养成了万事先 Google 的坏习惯,还真让我找到了一个很完善的 Javascript 弹窗代码,这段代码不仅写的漂亮,通用性强,而且还考虑到了当今流行的浏览器按下组合键点击链接的情况,已经非常完善了。代码源头在这里,作者提供了源码下载和一个演示

这段代码的通用性非常强,作者原文中举例写的也很详细,其实最简单的用法就是为需要开新窗的链接添加 rel=”external” 属性,当然,你也可以自己定制根据 class 或其它什么属性来判断。

  1. <a href=http://jennal.cn rel=external>Jennal.cn</a>

当然,在网页设计中,弹出新窗口在多数情况下应该尽量避免,只在可以提高用户体验的情况下才需要使用。此外,由于有些 Pop Window Blocker 会拦截 Javascript 弹出窗口,我们可以修改这段代码,通过判断窗口是否成功建立来给出关闭弹窗过滤的提示,相信可以使用户体验提升不少。

转自:http://blog.istef.info/2007/05/17/open-a-new-window-when-click-a-link-under-xhtml-10-strict/

php下载文件的函数

转自:http://www.ruofeel.cn/329.html

使用truss、strace或ltrace诊断软件的”疑难杂症”

进程无法启动,软件运行速度突然变慢,程序的”Segment Fault”等等都是让每个Unix系统用户头痛的问题,本文通过三个实际案例演示如何使用truss、strace和ltrace这三个常用的调试工具来快速诊断软件的”疑难杂症”。

truss 和strace用来跟踪一个进程的系统调用或信号产生的情况,而 ltrace用来跟踪进程调用库函数的情况。truss是早期为System V R4开发的调试程序,包括Aix、FreeBSD在内的大部分Unix系统都自带了这个工具;而strace最初是为SunOS系统编写的,ltrace 最早出现在GNU/Debian Linux中。这两个工具现在也已被移植到了大部分Unix系统中,大多数Linux发行版都自带了strace和ltrace,而FreeBSD也可通 过Ports安装它们。

你不仅可以从命令行调试一个新开始的程序,也可以把truss、strace或ltrace绑定到一个已有的PID上来调试一个正在运行的程序。三个调试工具的基本使用方法大体相同,下面仅介绍三者共有,而且是最常用的三个命令行参数:

使用上述三个参数基本上就可以完成大多数调试任务了,下面举几个命令行例子:

三个调试工具的输出结果格式也很相似,以strace为例:


每一行都是一条系统调用,等号左边是系统调用的函数名及其参数,右边是该调用的返回值。 truss、strace和ltrace的工作原理大同小异,都是使用ptrace系统调用跟踪调试运行中的进程,详细原理不在本文讨论范围内,有兴趣可以参考它们的源代码。

举两个实例演示如何利用这三个调试工具诊断软件的”疑难杂症”:

案例一:运行clint出现Segment Fault错误

操作系统:FreeBSD-5.2.1-release

clint是一个C++静态源代码分析工具,通过Ports安装好之后,运行:


在Unix系统中遇见”Segmentation Fault”就像在MS Windows中弹出”非法操作”对话框一样令人讨厌。OK,我们用truss给clint”把把脉”:


我们用truss跟踪clint的系 统调用执行情况,并把结果输出到文件clint.truss,然后用tail查看最后几行。注意看clint执行的最后一条系统调用(倒数第五 行):stat(“/root/.clint/plugins”,0xbfbfe680) ERR#2 ‘No such file or directory’,问题就出在这里:clint找不到目录”/root/.clint/plugins”,从而引发了段错误。怎样解决?很简单: mkdir -p /root/.clint/plugins,不过这次运行clint还是会”Segmentation Fault”9。继续用truss跟踪,发现clint还需要这个目录”/root/.clint/plugins/python”,建好这个目录后 clint终于能够正常运行了。

案例二:vim启动速度明显变慢

操作系统:FreeBSD-5.2.1-release

vim 版本为6.2.154,从命令行运行vim后,要等待近半分钟才能进入编辑界面,而且没有任何错误输出。仔细检查了. vimrc和所有的vim脚本都没有错误配置,在网上也找不到类似问题的解决办法,难不成要hacking source code?没有必要,用truss就能找到问题所在:


这里-D参数的作用是:在每行输出前加上相对时间戳,即每执行一条系统调用所耗费的时间。我们只要关注哪些系统调用耗费的时间比较长就可以了,用less仔细查看输出文件vim.truss,很快就找到了疑点:

vim 试图连接10.57.18.27这台主机的6000端口(第四行的 connect()),连接失败后,睡眠一秒钟继续重试(第6行的nanosleep())。以上片断循环出现了十几次,每次都要耗费一秒多钟的时间,这 就是vim明显变慢的原因。可是,你肯定会纳闷:”vim怎么会无缘无故连接其它计算机的6000端口呢?”。问得好,那么请你回想一下6000是什么服 务的端口?没错,就是X Server。看来vim是要把输出定向到一个远程X Server,那么Shell中肯定定义了DISPLAY变量,查看.cshrc,果然有这么一行:setenv DISPLAY ${REMOTEHOST}:0,把它注释掉,再重新登录,问题就解决了。

案例三:用调试工具掌握软件的工作原理

操作系统:Red Hat Linux 9.0

用 调试工具实时跟踪软件的运行情况不仅是诊断软件”疑难杂症”的有效的手段,也可帮助我们理清软件的”脉络”,即快速掌握软件的运行流程和工作原理,不失为 一种学习源代码的辅助方法。下面这个案例展现了如何使用strace通过跟踪别的软件来”触发灵感”,从而解决软件开发中的难题的。

大 家都知道,在进程内打开一个文件,都有唯一一个文件描述符(fd:file descriptor)与这个文件对应。而本人在开发一个软件过程中遇到这样一个问题:已知一个fd ,如何获取这个fd所对应文件的完整路径?不管是Linux、FreeBSD或是其它Unix系统都没有提供这样的API,怎么办呢?我们换个角度思考: Unix下有没有什么软件可以获取进程打开了哪些文件?如果你经验足够丰富,很容易想到lsof,使用它既可以知道进程打开了哪些文件,也可以了解一个文 件被哪个进程打开。好,我们用一个小程序来试验一下lsof,看它是如何获取进程打开了哪些文件。

将testlsof放入后台运行,其pid为3125。命令lsof -p 3125查看进程3125打开了哪些文件,我们用strace跟踪lsof的运行,输出结果保存在lsof.strace中:

我们以”/tmp/foo”为关键字搜索输出文件lsof.strace,结果只有一条:

原 来lsof巧妙的利用了/proc/nnnn/fd/目录(nnnn为 pid):Linux内核会为每一个进程在/proc/建立一个以其pid为名的目录用来保存进程的相关信息,而其子目录fd保存的是该进程打开的所有文 件的fd。目标离我们很近了。好,我们到/proc/3125/fd/看个究竟:

答案已经很明显了:/proc/nnnn/fd/目录下的每一个fd文件都是符号链接,而此链接就指向被该进程打开的一个文件。我们只要用readlink()系统调用就可以获取某个fd对应的文件了,代码如下:

出 于安全方面的考虑,在FreeBSD 5 之后系统默认已经不再自动装载proc文件系统,因此,要想使用truss或strace跟踪程序,你必须手工装载proc文件系统:mount -t procfs proc /proc;或者在/etc/fstab中加上一行:

How to choose and use source code analysis tools

January 20, 2009 (CSO) The high cost of finding and patching application flaws is well known. Wouldn’t it be cheaper to write secure code in the first place?

One of the fastest growing areas in the software security industry is source code analysis tools, also known as static analysis tools. These tools review source code (or in Veracode Inc.’s case, binary code) line by line to detect security vulnerabilities and provide advice on how to remediate problems they find — ideally before the code goes into production. (See “How to Evaluate and Use Web Application Scanners” for tools and services that search for vulnerabilities as an outside attacker might.)

The entire software security market was worth about $300 million in 2007, according to Gary McGraw, chief technology officer at Cigital Inc., a software security and quality consulting firm in Dulles, Va. McGraw estimates that the tools portion of that market doubled from 2006 to 2007 to about $180 million. About half of that is attributable to static analysis tools, which amounted to about $91.9 million, he says.

And no wonder; according to Gartner Inc., close to 90% of software attacks are aimed at the application layer. If security were integrated earlier in the software development life cycle, flaws would be uncovered earlier, reducing costs and increasing efficiency compared with removing defects later through patches or never finding them at all, says Diane Kelley, founder of SecurityCurve, a security consultancy in Amherst, N.H. “Although there is no replacement for security-aware design and a methodical approach to creating more-secure applications, code-scanning tools are a very useful addition to the process,” she says.

Despite the high degree of awareness, many companies are behind the curve in their use of static analysis tools, Kelley says, possibly because of the big process changes that these tools entail.

Key decisions in source code analysis

1. Should you start with static tools or dynamic tools, or use both?

In addition to static analysis, which reviews code before it goes live, there are also dynamic analysis tools, which conduct automated scans of production Web applications to unearth vulnerabilities. In other words, dynamic tools test from the outside in, while static tools test from the inside out, says Neil McDonald, an analyst at Gartner.

Many organizations start with dynamic testing, just to get a quick assessment of where their applications stand, McDonald says. In some cases, the groups that start this initiative are in security or audit compliance departments and don’t have access to source code. The natural second step is to follow up with static analyzers, enabling developers to fix the problems found by dynamic analysis tools. Some companies continue using both because each type yields different findings.

An important differentiator between the two types is that static analyzers provide the exact line of code causing the problem, while dynamic analyzers just identify the Web page causing the issue. That’s why some vendors offer integration between the two types of tools.

Dynamic assessment tools “tend to be brute force,” according to the chief scientist at a large software vendor who asked not to be identified. “You have to hit every parameter to find the vulnerabilities, whereas static tools investigate the whole landscape of the application.” He recently chose a code scanner from Ounce Labs Inc. after outsourcing the work to Cigital since 2006. He became interested in application security when customers began requiring PCI DSS certification. He plans to add in dynamic testing in the future, but the static analysis tool is the cornerstone of his application security program.

2. Do you have the source code?

Most static analyzers scan source code, but what happens if you want to analyze third-party software or code written so long ago that you only have the executable? In that case, Veracode offers binary code scanning through a software-as-a-service system. “A vendor may not be willing to give you source code, but they will give you executables or binary,” Kelley says.

At the Federal Aviation Administration, Michael Brown, director of the Office of Information Systems Security, says he chose to use Veracode’s services this year because of the amount of vendor-written code the FAA anticipated to use as a result of its modernization of the national airspace system. Brown says he wanted to ensure that the code was not only functionally correct and of high quality but also secure. He wanted a service rather than a tool to reduce the need for training. So far, the results have been eye-opening, he says. “A lot of the code didn’t really take security into account,” he says. “There were cases of memory leaks, cross-site scripting and buffer overflows that could have been a cause for concern.”

3. What do you currently use for software quality?

Some tool vendors, such as Coverity, Klocwork, Parasoft and Compuware, originated in the quality-testing arena and have added security capabilities, as opposed to vendors like Ounce and Fortify Software Inc., whose tools were solely designed for security. It’s worthwhile to check into the quality tools you already use to see if you can leverage the existing relationship and tool familiarity. You should also consider whether it’s important to your organization to have the two functions merged into one tool in the long term, McDonald says. (See “Penetration Testing: Dead in 2009?” for more on the interplay of quality assurance and vulnerability detection.)

Source code analysis tools: Evaluation criteria

  • Support for the programming languages you use. Some companies support mobile devices, while others concentrate on enterprise languages such as Java, .Net, C, C++ and even Cobol.
  • Good bug-finding performance, using a proof-of-concept assessment. Hint: Use an older build of code you had issues with and see how well the product catches bugs you had to find manually. Look for both thoroughness and accuracy. Fewer false positives means less manual work.
  • Internal knowledge bases that provide descriptions of vulnerabilities and remediation information. Test for easy access and cross-referencing to discovered findings.
  • Tight integration with your development platforms. Long-term, you’ll likely want developers to incorporate security analysis into their daily routines.
  • A robust finding/suppression mechanism to prevent false positives from reoccurring once you’ve verified them as a non-issue.
  • The ability to easily define additional rules so the tool can enforce internal coding policies.
  • A centralized reporting component if you have a large team of developers and managers who want access to findings, trending and overview reporting.

Do’s and don’ts of source code analysis

Don’t underestimate the adoption time required. Most static analysis projects are initiated by security or compliance staffers, not developers, who may not immediately embrace these tools. Before developers get involved, McDonald suggests doing the legwork on new processes, planning integration with other workflows like bug-tracking systems and development environments, and tuning the tool to your unique coding needs. “Don’t deploy to every developer at once,” he adds. “Ideally, you’ll get someone who wants to take on a competency role for security testing.”

The chief scientist at the large software vendor has developed an application security-awareness program that includes training on common vulnerabilities through podcasts and videocasts. Once he builds up awareness, he plans to educate developers on secure coding standards. To complete the circle, he’ll introduce Ounce’s static code analysis tool to enforce the standards and catch vulnerabilities “so it’s a feedback loop,” he says. (See “Rob Cheyne Pushes for Developer Security Awareness” for a look at a similar agenda.

Do consider using more than one tool. Collin Park, a senior engineer at NetApp Inc., says the company uses two code-analysis tools: Developers run Lint on their desktops, and the company uses Coverity each night to scan all completed code. “They catch different things,” he explains. NetApp began using these tools when its customer base shifted to enterprise customers that had more stringent requirements. While Coverity is better at spotting vulnerabilities such as memory leaks, Lint catches careless coding errors that developers make and seems to run faster on developer desktops, Park says.

According to Kelley, organizations typically implement static analyzers at two stages of the development process: within the development environment, so developers can check their own code as they’re writing, and within the code repository, so it can be analyzed at check-in time. The chief scientist uses this method. “In the first scan, if the engineer takes every finding and suppresses them, a milestone scan will catch those and generate a report,” he says.

Do analyze pricing. Vendors have different pricing strategies, McDonald says. For instance, while all continuously add information to their libraries about the latest vulnerabilities, some charge extra for this, while others include it in the maintenance fee, he says. In addition, some vendors charge per seat, which can get expensive for large shops and may even seem wasteful for companies that don’t intend to run the scanner every day. Other vendors charge per enterprise license. In addition, some vendors charge for additional languages, while others charge one price for any language they support, McDonald says.

Do plan to amend your processes. Tools are no replacement for strong processes that ensure application security from the beginning, starting with defining requirements, which should focus on security as much as functionality, according to Kelley. For instance, a tool won’t tell you whether a piece of data should be encrypted to comply with the Payment Card Industry Data Security Standard. “If a company just goes out and buys one of these tools and continues to do everything else the same, they won’t get to the next level,” she says.

The chief scientist says it’s also important to determine what will happen when vulnerabilities are found, especially because the tools can generate thousands of findings. “Does the workflow allow them to effectively analyze, triage, prioritize or dispose of the findings?” he notes. He is working with Ounce to integrate the system better with his current bug-tracking system, which is Quality Center. “It would be great to right-click on the finding to automatically inject it into the bug-tracking system,” he says.

At NetApp, Park has reworked processes to ensure developers fix flagged vulnerabilities. As part of submitting code, developers do a test build, which must succeed, or it can’t be checked in. Then, when they check in code, an automated process starts an incremental build. If that build fails, a bug report is filed, complete with the names of developers who checked in code before the last build. “Developers are trained to treat a build failure as something they have to look at now,'” Park says.

NetApp also created a Web-based chart that’s automatically updated each night to track which managers have teams that were issued Lint or Coverity warnings and whether they were cleared.

Do retain the human element. While the tools will provide long lists of vulnerabilities, it takes a skilled professional to interpret and prioritize the results. “Companies don’t have time to fix every problem, and they may not need to,” Kelley says. “You have to have someone who understands what is and is not acceptable, especially in terms of a time-vs.-perfection trade-off.'”

The chief scientist calls this “truly an art form” that requires a competent security engineer. “When the tool gives you 10,000 findings, you don’t want someone trying to fix all those,” he says. “In fact, 10,000 may turn out to just be 500 or 100 vulnerabilities,”

Park points out an instance when the Coverity tool once found what it called “a likely infinite loop.” On first glance, the developer could see there was no loop, but after a few more minutes of review, he detected something else wrong with the code. “The fact that you get the tool to stop complaining is not an indication you’ve fixed anything,” he says.

Don’t anticipate a short scan. NetApp runs scans each night, and because it needs to cover thousands of files and millions of lines of code, it takes roughly 10 hours to complete a code review. The rule of thumb, according to Coverity, is for each hour of build time, allow for two hours for the analysis to be complete. Coverity also enables companies to do incremental runs so that users don’t have to scan the entire code base but just what they’ve changed in the nightly build.

Do consider reporting flexibility. At the FAA, Brown gets two reports: an executive summary that provides a high-level view of vulnerabilities detected and even provides a security “score,” and a more detailed report that pinpoints which lines of code look troublesome and the vulnerability that was detected. In the future, Brown would like to build into vendor contracts the requirement that they meet a certain security score for all code they develop for the FAA.

Don’t forget the business case. When Brown first wanted to start reviewing code, he met with some resistance from managers who wanted a defined business need. “You’ve got program managers with schedules to meet, and they can view this as just another bump in the road that’s going to keep them from making their milestones,” he says.

Brown created the business case by looking to independent sources such as Gartner and Burton Group for facts and figures about code vulnerability, and he also ran some reports on how much time the FAA was dedicating to patch management.

The chief scientist justified the cost of the Ounce tool by taking the total cost of the product and comparing that with the effort involved in a manual review. “With millions of lines of code, imagine how many engineers it would take to do that — and, by the way, we want to do it every week,” he says. “The engineers would fall down dead of boredom.”

Mary Brandel is a freelance writer based outside of Boston.

Javascript 刷新页面的几种方法

1    history.go(0)
2    location.reload()
3    location=location
4    location.assign(location)
5    document.execCommand(‘Refresh’)
6    window.navigate(location)
7    location.replace(location)
8    document.URL=location.href

[转]国际:写出漂亮代码的七种方法

首先我想说明我本文阐述的是纯粹从美学的角度来写出代码,而非技术、逻辑等。以下为写出漂亮代码的七种方法:

1, 尽快结束 if语句

例如下面这个JavaScript语句,看起来就很恐怖:

但如果这么写就好看得多:

你可能会很不喜欢第二种的表述方式,但反映出了迅速返回if值的思想,也可以理解为:避免不必要的else陈述。

2, 如果只是简单的布尔运算(逻辑运算),不要使用if语句

例如:

可以写为:

3, 使用空白,这是免费的
例如:

很多开发者不愿意使用空白,就好像这要收费一样。我在此并非刻意地添加空白,粗鲁地打断代码的连贯性。在实际编写代码的过程中,会很容易地发现在什么地方加入空白,这不但美观而且让读者易懂,如下:

4, 不要使用无谓的注释
无谓的注释让人费神,这实在很讨厌。不要标出很明显的注释。在以下的例子中,每个人都知道代码表达的是“students id”,因而没必要标出。

5, 不要在源文件中留下已经删除的代码,哪怕你标注了
如果你使用了版本控制,那么你就可以轻松地找回前一个版本的代码。如果别人大费周折地读了你的代码,却发现是要删除的代码,这实在太恨人了。

6,不要有太长的代码

看太长的代码实在太费劲,尤其是代码本身的功能又很小。如下:

#

我并不是说非要坚持70个字符以内,但是一个比较理想的长度是控制在120个字符内。如果你把代码发布在互联网上,用户读起来就很困难。
7,不要在一个功能(或者函数内)有太多代码行
我的一个老同事曾经说Visual C++很臭,因为它不允许你在一个函数内拥有超过10,000行代码。我记不清代码行数的上限,不知道他说的是否正确,但我很不赞成他的观点。如果一个函数超过了50行,看起来有多费劲你知道么,还有没完没了的if循环,而且你还的滚动鼠标前后对照这段代码。对我而言,超过35行的代码理解起来就很困难了。我的建议是超过这个数字就把一个函数代码分割成两个。

转自:http://news.csdn.net/n/20081217/121810.html

搞定一个很纠结的json问题,记录一下

今天被json编码中文搞死了。。。
json_encode中文的时候,会把每个中文字符encode成“\uxxxx”
而存进数据库的时候,“\”被屏蔽了,直接变成”uxxxx”
郁闷,我还以为是json_decode的问题。。。在网上查了一个下午资料都没解决
直到发现网上的文章都说json_encode是把中文encode成“\uxxxx”,我才顿悟。。。
经过一番实验,才发现问题出在存储到数据库的环节。。。
特此纪念一下

至于解决办法,当然是让”\”保留啦,把”\” replace成”\\”就可以啦~

还有一个问题,差点忘了,就是json_decode以后返回的不是array,而是stdclass,有一个很郁闷的问题,如果hash带下划线,如json[‘xx_yy’]会出现很奇怪的问题,页面什么都不显示,也不报错,差点晕死。有一个办法解决,就是先foreach一下,把带下划线的存到一个array里面,或者直接整个转存成array。

//感谢软工的回复
由于已经是2年前写的博客,也没有写实际场景,我已经忘记json_decode是在什么场景下出现的问题。
如果我没有记错的话,当时json_decode还没有第二个参数。

PHP get remote ip address

Taste for Makers

February 2002

“…Copernicus’ aesthetic objections to [equants] provided one essential motive for his rejection of the Ptolemaic system….”

– Thomas Kuhn, The Copernican Revolution

“All of us had been trained by Kelly Johnson and believed fanatically in his insistence that an airplane that looked beautiful would fly the same way.”

– Ben Rich, Skunk Works

“Beauty is the first test: there is no permanent place in this world for ugly mathematics.”

– G. H. Hardy, A Mathematician’s Apology

I was talking recently to a friend who teaches at MIT. His field is hot now and every year he is inundated by applications from would-be graduate students. “A lot of them seem smart,” he said. “What I can’t tell is whether they have any kind of taste.”

Taste. You don’t hear that word much now. And yet we still need the underlying concept, whatever we call it. What my friend meant was that he wanted students who were not just good technicians, but who could use their technical knowledge to design beautiful things.

Mathematicians call good work “beautiful,” and so, either now or in the past, have scientists, engineers, musicians, architects, designers, writers, and painters. Is it just a coincidence that they used the same word, or is there some overlap in what they meant? If there is an overlap, can we use one field’s discoveries about beauty to help us in another?

For those of us who design things, these are not just theoretical questions. If there is such a thing as beauty, we need to be able to recognize it. We need good taste to make good things. Instead of treating beauty as an airy abstraction, to be either blathered about or avoided depending on how one feels about airy abstractions, let’s try considering it as a practical question: how do you make good stuff?

If you mention taste nowadays, a lot of people will tell you that “taste is subjective.” They believe this because it really feels that way to them. When they like something, they have no idea why. It could be because it’s beautiful, or because their mother had one, or because they saw a movie star with one in a magazine, or because they know it’s expensive. Their thoughts are a tangle of unexamined impulses.

Most of us are encouraged, as children, to leave this tangle unexamined. If you make fun of your little brother for coloring people green in his coloring book, your mother is likely to tell you something like “you like to do it your way and he likes to do it his way.”

Your mother at this point is not trying to teach you important truths about aesthetics. She’s trying to get the two of you to stop bickering.

Like many of the half-truths adults tell us, this one contradicts other things they tell us. After dinning into you that taste is merely a matter of personal preference, they take you to the museum and tell you that you should pay attention because Leonardo is a great artist.

What goes through the kid’s head at this point? What does he think “great artist” means? After having been told for years that everyone just likes to do things their own way, he is unlikely to head straight for the conclusion that a great artist is someone whose work is better than the others’. A far more likely theory, in his Ptolemaic model of the universe, is that a great artist is something that’s good for you, like broccoli, because someone said so in a book.

Saying that taste is just personal preference is a good way to prevent disputes. The trouble is, it’s not true. You feel this when you start to design things.

Whatever job people do, they naturally want to do better. Football players like to win games. CEOs like to increase earnings. It’s a matter of pride, and a real pleasure, to get better at your job. But if your job is to design things, and there is no such thing as beauty, then there is no way to get better at your job. If taste is just personal preference, then everyone’s is already perfect: you like whatever you like, and that’s it.

As in any job, as you continue to design things, you’ll get better at it. Your tastes will change. And, like anyone who gets better at their job, you’ll know you’re getting better. If so, your old tastes were not merely different, but worse. Poof goes the axiom that taste can’t be wrong.

Relativism is fashionable at the moment, and that may hamper you from thinking about taste, even as yours grows. But if you come out of the closet and admit, at least to yourself, that there is such a thing as good and bad design, then you can start to study good design in detail. How has your taste changed? When you made mistakes, what caused you to make them? What have other people learned about design?

Once you start to examine the question, it’s surprising how much different fields’ ideas of beauty have in common. The same principles of good design crop up again and again.

Good design is simple. You hear this from math to painting. In math it means that a shorter proof tends to be a better one. Where axioms are concerned, especially, less is more. It means much the same thing in programming. For architects and designers it means that beauty should depend on a few carefully chosen structural elements rather than a profusion of superficial ornament. (Ornament is not in itself bad, only when it’s camouflage on insipid form.) Similarly, in painting, a still life of a few carefully observed and solidly modelled objects will tend to be more interesting than a stretch of flashy but mindlessly repetitive painting of, say, a lace collar. In writing it means: say what you mean and say it briefly.

It seems strange to have to emphasize simplicity. You’d think simple would be the default. Ornate is more work. But something seems to come over people when they try to be creative. Beginning writers adopt a pompous tone that doesn’t sound anything like the way they speak. Designers trying to be artistic resort to swooshes and curlicues. Painters discover that they’re expressionists. It’s all evasion. Underneath the long words or the “expressive” brush strokes, there is not much going on, and that’s frightening.

When you’re forced to be simple, you’re forced to face the real problem. When you can’t deliver ornament, you have to deliver substance.

Good design is timeless. In math, every proof is timeless unless it contains a mistake. So what does Hardy mean when he says there is no permanent place for ugly mathematics? He means the same thing Kelly Johnson did: if something is ugly, it can’t be the best solution. There must be a better one, and eventually someone will discover it.

Aiming at timelessness is a way to make yourself find the best answer: if you can imagine someone surpassing you, you should do it yourself. Some of the greatest masters did this so well that they left little room for those who came after. Every engraver since Durer has had to live in his shadow.

Aiming at timelessness is also a way to evade the grip of fashion. Fashions almost by definition change with time, so if you can make something that will still look good far into the future, then its appeal must derive more from merit and less from fashion.

Strangely enough, if you want to make something that will appeal to future generations, one way to do it is to try to appeal to past generations. It’s hard to guess what the future will be like, but we can be sure it will be like the past in caring nothing for present fashions. So if you can make something that appeals to people today and would also have appealed to people in 1500, there is a good chance it will appeal to people in 2500.

Good design solves the right problem. The typical stove has four burners arranged in a square, and a dial to control each. How do you arrange the dials? The simplest answer is to put them in a row. But this is a simple answer to the wrong question. The dials are for humans to use, and if you put them in a row, the unlucky human will have to stop and think each time about which dial matches which burner. Better to arrange the dials in a square like the burners.

A lot of bad design is industrious, but misguided. In the mid twentieth century there was a vogue for setting text in sans-serif fonts. These fonts are closer to the pure, underlying letterforms. But in text that’s not the problem you’re trying to solve. For legibility it’s more important that letters be easy to tell apart. It may look Victorian, but a Times Roman lowercase g is easy to tell from a lowercase y.

Problems can be improved as well as solutions. In software, an intractable problem can usually be replaced by an equivalent one that’s easy to solve. Physics progressed faster as the problem became predicting observable behavior, instead of reconciling it with scripture.

Good design is suggestive. Jane Austen’s novels contain almost no description; instead of telling you how everything looks, she tells her story so well that you envision the scene for yourself. Likewise, a painting that suggests is usually more engaging than one that tells. Everyone makes up their own story about the Mona Lisa.

In architecture and design, this principle means that a building or object should let you use it how you want: a good building, for example, will serve as a backdrop for whatever life people want to lead in it, instead of making them live as if they were executing a program written by the architect.

In software, it means you should give users a few basic elements that they can combine as they wish, like Lego. In math it means a proof that becomes the basis for a lot of new work is preferable to a proof that was difficult, but doesn’t lead to future discoveries; in the sciences generally, citation is considered a rough indicator of merit.

Good design is often slightly funny. This one may not always be true. But Durer’s engravings and Saarinen’s womb chair and the Pantheon and the original Porsche 911 all seem to me slightly funny. Godel’s incompleteness theorem seems like a practical joke.

I think it’s because humor is related to strength. To have a sense of humor is to be strong: to keep one’s sense of humor is to shrug off misfortunes, and to lose one’s sense of humor is to be wounded by them. And so the mark– or at least the prerogative– of strength is not to take oneself too seriously. The confident will often, like swallows, seem to be making fun of the whole process slightly, as Hitchcock does in his films or Bruegel in his paintings– or Shakespeare, for that matter.

Good design may not have to be funny, but it’s hard to imagine something that could be called humorless also being good design.

Good design is hard. If you look at the people who’ve done great work, one thing they all seem to have in common is that they worked very hard. If you’re not working hard, you’re probably wasting your time.

Hard problems call for great efforts. In math, difficult proofs require ingenious solutions, and those tend to be interesting. Ditto in engineering.

When you have to climb a mountain you toss everything unnecessary out of your pack. And so an architect who has to build on a difficult site, or a small budget, will find that he is forced to produce an elegant design. Fashions and flourishes get knocked aside by the difficult business of solving the problem at all.

Not every kind of hard is good. There is good pain and bad pain. You want the kind of pain you get from going running, not the kind you get from stepping on a nail. A difficult problem could be good for a designer, but a fickle client or unreliable materials would not be.

In art, the highest place has traditionally been given to paintings of people. There is something to this tradition, and not just because pictures of faces get to press buttons in our brains that other pictures don’t. We are so good at looking at faces that we force anyone who draws them to work hard to satisfy us. If you draw a tree and you change the angle of a branch five degrees, no one will know. When you change the angle of someone’s eye five degrees, people notice.

When Bauhaus designers adopted Sullivan’s “form follows function,” what they meant was, form should follow function. And if function is hard enough, form is forced to follow it, because there is no effort to spare for error. Wild animals are beautiful because they have hard lives.

Good design looks easy. Like great athletes, great designers make it look easy. Mostly this is an illusion. The easy, conversational tone of good writing comes only on the eighth rewrite.

In science and engineering, some of the greatest discoveries seem so simple that you say to yourself, I could have thought of that. The discoverer is entitled to reply, why didn’t you?

Some Leonardo heads are just a few lines. You look at them and you think, all you have to do is get eight or ten lines in the right place and you’ve made this beautiful portrait. Well, yes, but you have to get them in exactly the right place. The slightest error will make the whole thing collapse.

Line drawings are in fact the most difficult visual medium, because they demand near perfection. In math terms, they are a closed-form solution; lesser artists literally solve the same problems by successive approximation. One of the reasons kids give up drawing at ten or so is that they decide to start drawing like grownups, and one of the first things they try is a line drawing of a face. Smack!

In most fields the appearance of ease seems to come with practice. Perhaps what practice does is train your unconscious mind to handle tasks that used to require conscious thought. In some cases you literally train your body. An expert pianist can play notes faster than the brain can send signals to his hand. Likewise an artist, after a while, can make visual perception flow in through his eye and out through his hand as automatically as someone tapping his foot to a beat.

When people talk about being in “the zone,” I think what they mean is that the spinal cord has the situation under control. Your spinal cord is less hesitant, and it frees conscious thought for the hard problems.

Good design uses symmetry. I think symmetry may just be one way to achieve simplicity, but it’s important enough to be mentioned on its own. Nature uses it a lot, which is a good sign.

There are two kinds of symmetry, repetition and recursion. Recursion means repetition in subelements, like the pattern of veins in a leaf.

Symmetry is unfashionable in some fields now, in reaction to excesses in the past. Architects started consciously making buildings asymmetric in Victorian times and by the 1920s asymmetry was an explicit premise of modernist architecture. Even these buildings only tended to be asymmetric about major axes, though; there were hundreds of minor symmetries.

In writing you find symmetry at every level, from the phrases in a sentence to the plot of a novel. You find the same in music and art. Mosaics (and some Cezannes) get extra visual punch by making the whole picture out of the same atoms. Compositional symmetry yields some of the most memorable paintings, especially when two halves react to one another, as in the Creation of Adam or American Gothic.

In math and engineering, recursion, especially, is a big win. Inductive proofs are wonderfully short. In software, a problem that can be solved by recursion is nearly always best solved that way. The Eiffel Tower looks striking partly because it is a recursive solution, a tower on a tower.

The danger of symmetry, and repetition especially, is that it can be used as a substitute for thought.

Good design resembles nature. It’s not so much that resembling nature is intrinsically good as that nature has had a long time to work on the problem. It’s a good sign when your answer resembles nature’s.

It’s not cheating to copy. Few would deny that a story should be like life. Working from life is a valuable tool in painting too, though its role has often been misunderstood. The aim is not simply to make a record. The point of painting from life is that it gives your mind something to chew on: when your eyes are looking at something, your hand will do more interesting work.

Imitating nature also works in engineering. Boats have long had spines and ribs like an animal’s ribcage. In some cases we may have to wait for better technology: early aircraft designers were mistaken to design aircraft that looked like birds, because they didn’t have materials or power sources light enough (the Wrights’ engine weighed 152 lbs. and generated only 12 hp.) or control systems sophisticated enough for machines that flew like birds, but I could imagine little unmanned reconnaissance planes flying like birds in fifty years.

Now that we have enough computer power, we can imitate nature’s method as well as its results. Genetic algorithms may let us create things too complex to design in the ordinary sense.

Good design is redesign. It’s rare to get things right the first time. Experts expect to throw away some early work. They plan for plans to change.

It takes confidence to throw work away. You have to be able to think, there’s more where that came from. When people first start drawing, for example, they’re often reluctant to redo parts that aren’t right; they feel they’ve been lucky to get that far, and if they try to redo something, it will turn out worse. Instead they convince themselves that the drawing is not that bad, really– in fact, maybe they meant it to look that way.

Dangerous territory, that; if anything you should cultivate dissatisfaction. In Leonardo’s drawings there are often five or six attempts to get a line right. The distinctive back of the Porsche 911 only appeared in the redesign of an awkward prototype. In Wright’s early plans for the Guggenheim, the right half was a ziggurat; he inverted it to get the present shape.

Mistakes are natural. Instead of treating them as disasters, make them easy to acknowledge and easy to fix. Leonardo more or less invented the sketch, as a way to make drawing bear a greater weight of exploration. Open-source software has fewer bugs because it admits the possibility of bugs.

It helps to have a medium that makes change easy. When oil paint replaced tempera in the fifteenth century, it helped painters to deal with difficult subjects like the human figure because, unlike tempera, oil can be blended and overpainted.

Good design can copy. Attitudes to copying often make a round trip. A novice imitates without knowing it; next he tries consciously to be original; finally, he decides it’s more important to be right than original.

Unknowing imitation is almost a recipe for bad design. If you don’t know where your ideas are coming from, you’re probably imitating an imitator. Raphael so pervaded mid-nineteenth century taste that almost anyone who tried to draw was imitating him, often at several removes. It was this, more than Raphael’s own work, that bothered the Pre-Raphaelites.

The ambitious are not content to imitate. The second phase in the growth of taste is a conscious attempt at originality.

I think the greatest masters go on to achieve a kind of selflessness. They just want to get the right answer, and if part of the right answer has already been discovered by someone else, that’s no reason not to use it. They’re confident enough to take from anyone without feeling that their own vision will be lost in the process.

Good design is often strange. Some of the very best work has an uncanny quality: Euler’s Formula, Bruegel’s Hunters in the Snow, the SR-71, Lisp. They’re not just beautiful, but strangely beautiful.

I’m not sure why. It may just be my own stupidity. A can-opener must seem miraculous to a dog. Maybe if I were smart enough it would seem the most natural thing in the world that ei*pi = -1. It is after all necessarily true.

Most of the qualities I’ve mentioned are things that can be cultivated, but I don’t think it works to cultivate strangeness. The best you can do is not squash it if it starts to appear. Einstein didn’t try to make relativity strange. He tried to make it true, and the truth turned out to be strange.

At an art school where I once studied, the students wanted most of all to develop a personal style. But if you just try to make good things, you’ll inevitably do it in a distinctive way, just as each person walks in a distinctive way. Michelangelo was not trying to paint like Michelangelo. He was just trying to paint well; he couldn’t help painting like Michelangelo.

The only style worth having is the one you can’t help. And this is especially true for strangeness. There is no shortcut to it. The Northwest Passage that the Mannerists, the Romantics, and two generations of American high school students have searched for does not seem to exist. The only way to get there is to go through good and come out the other side.

Good design happens in chunks. The inhabitants of fifteenth century Florence included Brunelleschi, Ghiberti, Donatello, Masaccio, Filippo Lippi, Fra Angelico, Verrocchio, Botticelli, Leonardo, and Michelangelo. Milan at the time was as big as Florence. How many fifteenth century Milanese artists can you name?

Something was happening in Florence in the fifteenth century. And it can’t have been heredity, because it isn’t happening now. You have to assume that whatever inborn ability Leonardo and Michelangelo had, there were people born in Milan with just as much. What happened to the Milanese Leonardo?

There are roughly a thousand times as many people alive in the US right now as lived in Florence during the fifteenth century. A thousand Leonardos and a thousand Michelangelos walk among us. If DNA ruled, we should be greeted daily by artistic marvels. We aren’t, and the reason is that to make Leonardo you need more than his innate ability. You also need Florence in 1450.

Nothing is more powerful than a community of talented people working on related problems. Genes count for little by comparison: being a genetic Leonardo was not enough to compensate for having been born near Milan instead of Florence. Today we move around more, but great work still comes disproportionately from a few hotspots: the Bauhaus, the Manhattan Project, the New Yorker, Lockheed’s Skunk Works, Xerox Parc.

At any given time there are a few hot topics and a few groups doing great work on them, and it’s nearly impossible to do good work yourself if you’re too far removed from one of these centers. You can push or pull these trends to some extent, but you can’t break away from them. (Maybe you can, but the Milanese Leonardo couldn’t.)

Good design is often daring. At every period of history, people have believed things that were just ridiculous, and believed them so strongly that you risked ostracism or even violence by saying otherwise.

If our own time were any different, that would be remarkable. As far as I can tell it isn’t.

This problem afflicts not just every era, but in some degree every field. Much Renaissance art was in its time considered shockingly secular: according to Vasari, Botticelli repented and gave up painting, and Fra Bartolommeo and Lorenzo di Credi actually burned some of their work. Einstein’s theory of relativity offended many contemporary physicists, and was not fully accepted for decades– in France, not until the 1950s.

Today’s experimental error is tomorrow’s new theory. If you want to discover great new things, then instead of turning a blind eye to the places where conventional wisdom and truth don’t quite meet, you should pay particular attention to them.

As a practical matter, I think it’s easier to see ugliness than to imagine beauty. Most of the people who’ve made beautiful things seem to have done it by fixing something that they thought ugly. Great work usually seems to happen because someone sees something and thinks, I could do better than that. Giotto saw traditional Byzantine madonnas painted according to a formula that had satisfied everyone for centuries, and to him they looked wooden and unnatural. Copernicus was so troubled by a hack that all his contemporaries could tolerate that he felt there must be a better solution.

Intolerance for ugliness is not in itself enough. You have to understand a field well before you develop a good nose for what needs fixing. You have to do your homework. But as you become expert in a field, you’ll start to hear little voices saying, What a hack! There must be a better way. Don’t ignore those voices. Cultivate them. The recipe for great work is: very exacting taste, plus the ability to gratify it.

Notes

Sullivan actually said “form ever follows function,” but I think the usual misquotation is closer to what modernist architects meant.

Stephen G. Brush, “Why was Relativity Accepted?” Phys. Perspect. 1 (1999) 184-214.

[转]创造者的鉴赏力


“哥白尼对天动说美学上的反对是他拒绝托勒密体系的重要原因…”
– Thomas Kuhn, The Copernican Revolution

“在Kelly Johnson的训练之下,我们狂热地坚信他的主张: 一架看上去很美的飞机飞得也会同样的美.”
– Ben Rich, Skunk Works

“美是第一道检验: 世上没有永久的地方容纳丑陋的数学.”
– G. H. Hardy, A Mathematician’s Apology

我最近与一位在MIT任教的朋友聊天. 他的领域现在很热门,来自即将成为研究生的申请表每年都潮水般地涌向他. “他们中的大多数看上去都很聪明,”他说. “我不能确定的是他们是否有鉴赏力.”

鉴赏力. 你现在不常听到这个词了. 不过我们仍然需要其中的概念,不管人们叫它什么. 我朋友的意思是,他希望学生不仅是好的技术人员, 而且会用他们的技术知识设计出美好的事物.

数学家称出色的工作是”美的”, 就象不论是过去还是现在,科学家,工程师,音乐家,建筑师,设计师,作家和画家用”美”来形容作品一样. 他们使用同一个形容词,是一种巧合,还是他们所说的有某种含义上的重合? 如果有重合, 我们能否利用一个领域里关于美的发现,去找到另一个领域(的美)?

对于我们设计者来说,这些不仅是理论问题. 如果的确有叫做美的东西,我们必须能够认识它. 我们需要好的鉴赏力来做出好的事物. 与其视美为空洞的抽象物, 我们不如把它看成一个实际的问题: 你如何做出好的物品?

如果你现在提起鉴赏力, 许多人会告诉你”鉴赏力是主观的”. 他们实际上是这样感觉的,所以他们这样认为. 当他们喜欢某样东西的时候,也不知道是为什么. 可能是因为它美,也可能是他们的妈妈有同样的东西,或者是在杂志上看到某个电影明星有同样的东西,或者他们知道这东西很昂贵. 他们的思维处于未经权衡的随心所欲的混乱状态.

大多数人从小就被鼓励让这种随心所欲处在未经权衡的状态下. 如果你取笑你的弟弟在图画书上把人的皮肤涂成绿色, 你妈妈可能会说”你喜欢你的方式,他喜欢他的方式”之类的话.

你妈妈这时并不是想教你重要的美学理论,她只不过想让你俩停止斗嘴.

就象成人告诉我们的许多半真半假的事一样, 这件事与他们说的其它的事矛盾. 再三地跟你说了”鉴赏力只不过是个人的喜好”之后, 他们带你去了博物馆, 并告诉你,你得用点心, 因为达芬奇是一个伟大的艺术家.

这时闪过孩子脑海里的是什么? 他会认为”伟大的艺术家”是什么意思呢? 经过多年的”每个人喜欢用他自己的方式做事”的灌输之后,他不太可能直接得出结论:所谓伟大的艺术家,就是他的作品要比别人的好. 在他托勒密式的宇宙观里,更可能的结论是:伟大的艺术家是对你有好处的,就象书上说椰菜对人的身体有好处一样.

说鉴赏力是个人喜好是避免争论的好办法. 问题是,它不是真的. 当你开始设计事物时,你会感觉到这点.

无论人们做什么工作,他们自然地想做得好些. 足球队员想赢得比赛, CEO想增加收入. 在工作中做得更好, 使人感到愉快和骄傲. 不过如果你的工作是设计,而且其中没有美这码事, 那么就没有办法把工作做得更好. 如果鉴赏力仅是个人喜好, 那每个人都是完美的: 你无论喜欢什么都行,不必多说了.

就象任何一项工作, 当你持续地设计物体,你会得到更好的效果. 你的鉴赏力会改变. 而且就象任何在工作中越做越好的人一样,你知道你也在进步. 如果是这样的话,你原来的鉴赏力不仅和现在不同,而且比现在的坏. 让鉴赏力不会有错的公理见鬼去吧.

现在盛行的相对主义可能会妨碍你对鉴赏力的思考,即使你自己的鉴赏力正在发展. 但是如果你面对现实并承认,至少对你而言,存在着好的设计和坏的设计, 然后你可以开始仔细研究好的设计. 你的鉴赏力是如何改变的? 当你犯错误的时候,想想什么使你犯这个错误? 其他人从设计中学到了什么?

你一旦开始思索这些问题, 就会惊讶地发现美的观念在多少不同的领域是相通的. 同样的完美设计的原则一遍又一遍地出现在人们的面前.

好的设计是简单的. 从数学到绘画,你都能听到它. 在数学里它意味着一个较短的证明往往较好. 特别是公理,越少越好. 在程序设计领域,也是同样的道理. 对建筑师和设计者来说,这意味着美应该依赖于一些精心选择的结构性的元素,而不是过多的表面装饰. (装饰本身并不坏,坏在被用来掩饰平淡的实体.) 类似地, 在绘画领域, 经过仔细观察和扎实临摹的静物画往往比一幅浮华但没头脑的画(比如带花边的衣领)更令人感兴趣. 在写作领域,它意味着简洁地说出你想说的.

当你被迫做得简单,说明你正在面对实际的问题. 如果你不能放弃装饰,你就得放弃本质.

好的设计是永恒的. 数学里的每个证明都是永久的,除非它有错误. 那哈代说 “世上没有永久的地方容纳丑陋的数学”是什么意思呢? 他的意思和Kelly Johnson的一样: 丑陋的东西不可能是最好的解决办法. 一定有更好的办法,最终有人会发现它.

以永恒为目标是发现最佳答案的一个方法: 如果你能想象到别人能超过你,你还是自己来吧. 一些最伟大的大师在这方面做得如此之好,几乎没给后来者留下多少空间. 丢勒之后的雕刻师不得不生活在他的阴影下.

奇怪的是, 如果你想做出吸引将来的人类的事物,一种方法是设法吸引过去的人类. 很难猜测将来会怎样, 但我们可以肯定, 将来会象过去一样,不会关心现在的时尚. 因此如果你能做出吸引当代的人和1500年的人的东西,极有可能它会吸引2500年的人类.

好的设计解决正确的问题. 典型的(烹饪用的)炉子有四个出火口,形成一个正方形,各有一个开关控制它们. 你如何安排这些开关? 最简单的答案是把它们排成一行. 但这是答非所问. 开关是给人用的,如果你把它们排成一行,不幸的厨师不得不每次都停下来思考一下哪个开关是控制哪个出火口的. 更好的办法是象出火口那样安排成一个正方形.

许多坏的设计是勤勉的,但是被误导了. 二十世纪中叶有一股使用无衬线(sans-serif)字体的风气. 这些字体的确更接近纯粹的基本的字形. 但这不是你在文本里要解决的问题. 字母能被容易地认出是更重要的事情. 虽然象是维多利亚时代的风格, 但Times Roman的小写字母g很容易与小写字母y区分.

问题可以解决也可以改进. 在软件领域, 一个难以对付的问题通常可以被一个等价的较易解决的问题代替. 物理学因为要解决的问题变为预测可观察事物的行为,而不是把它与经典著作调和起来,而发展得更快了.

好的设计是有启发性的. 简奥斯汀的小说几乎没有描写,不是告诉你每样事物是什么样子的, 她讲故事如此之好以至于你可以自己想象出场景. 类似地, 有启发的画通常比合盘托出的画更有吸引力. 每个看过蒙娜丽莎的人都有他自己的关于她的故事.

此原则在建筑或设计界的体现是,建筑物或物体应该让你自如地使用: 比如说一幢好的建筑物,能充当这样一个背景,让住在此处的人过任何他们想过的生活, 而不是生活起居就象在执行建筑师的程序.

在软件领域,它意味着你应该给用户一些基本的元素,它们可以象拼装玩具一样自由地组合. 在数学里,它意味着一个能成为许多新工作的基础的证明比一个因难但不能引出什么新发现的证明更可取. 在科学领域,一般来说,(被别人)引用的多少是自身价值的粗略指标.

好的设计常常有点滑稽. 这点并不总是正确. 但丢勒(Durer)的雕刻, 沙里宁(Saarinen)的womb char, pantheon, 以及最初的Porsche 911在我看来都有点儿滑稽. 哥德尔的不完全定理就象一个恶作剧.

我想这是因为幽默与力量有关吧. 有幽默感就有力量: 保持幽默感就是对不幸一笑了之, 而失去幽默感就会被它伤害. 因此力量的标志,或至少是特长,是不要把事情看得太严重. 自信会你显得对全过程采取一种轻松的态度. 就象希区柯克(Hitchcock)在他的电影中, 勃鲁盖尔(Brueghel)在他的绘画中,莎士比亚(Shakespeare)在他的戏剧中所表现的一样.

好的设计不必表现得滑稽,但很难想象没有幽默感的东西会是好的设计.

好的设计是困难的. 看一下有过伟大成就的人物,有一点是共同的:他们曾经努力地工作. 如果你不努力,可能你在浪费时间.

困难的问题需要巨大的努力. 困难的数学证明需要天才的解答,而且它往往是令人着迷的. 工程界也是这样.

你爬山的时候会把所有不必要的东西从背包里拿出来. 同样一个要在困难的地点,或只有很小的预算的条件下造房的建筑师,会发现他必须做出优雅的设计. 流行和浮华的东西只能被撇在一边了.

并不是所有的努力都是好的. 苦痛也有优劣之分. 你希望那种飞奔起来的痛,而不是站在钉子上的痛, 困难的问题可能对设计师有好处, 而刁难的顾客和不可靠的原料可没什么好处.

传统上美术领域的最高位置留给了人物画. 传统是有原因的,不是因为人物画在我们头脑里留下印象,而其它画种没有. 我们是如此善于观察人脸,迫使画脸的人不懈努力使我们感到满意. 如果你画树的时候把树枝画偏了五度,没人会发现. 如果你把人眼画偏了五度, 人人都会注意到.

当Bauhaus学派采纳Sullivan的”形式跟随功能”的时候,他们指的是,形式应该跟随功能. 而且如果功能足够困难, 形式也必须跟随,因为没有出错的余地. 野生动物是美丽的,因为它们有艰苦的生活.

好的设计看上去很容易. 就象优秀的运动员,伟大的设计者使人觉得设计很容易. 通常这是一种表象. 经过好几遍的修改, 才会有读起来朗朗上口的文章.

在科技界,一些最伟大的发现看上去是如此简单,你会对自己说,我也想得到. 发现者有资格回答这个问题: 哪你为什么没有(想到)呢?

达芬奇的一些头像画仅寥寥数笔. 你注视着这些画,心里暗想,你所要做的只是把这八九条线画到正确的位置,然后一幅杰作就产生了. 是的, 但你必须把它们画到恰好正确的位置. 一点儿偏差就会让整幅画失败.

线条画要求近乎完美,因此事实上它是最难的视觉媒体. 用数学的术语说,它是封闭的解. 不那么优秀的艺术家用逐渐逼近的方法解决同样的问题. 十岁左右的孩子放弃绘画的一个原因是,他们决心象大人一样画画,而且第一次就尝试画一张人脸. 当头一棒!

在许多领域,容易是和练习联系在一起的. 也许练习训练你用潜意识来完成得用意识来完成的任务. 在一些情况下, 你精确地训练你的身体. 专业钢琴家按键快于大脑传给手的信号. 经过一段时间训练的画家,可以把视觉感知从眼传到手, 尤如条件反射.

当说一个人”进入化境”时, 我认为他们是指脊髓控制了身体,脊髓少些犹豫, 而且解放了意识,让它思考更难的问题.

好的设计使用对称. 我认为对称可能只是取得简单性的途径之一,但它很重要,值得单独提出来. 自然界大量地应用它, 这是一个好迹象.

有两类对称: 重复和递归. 递归是指在亚层次上重复,就象树叶的脉络.

对称在一些领域里不流行了,作为对以前过多使用的反弹. 建筑师在维多利亚时代开始有意识地使用不对称, 到了1920年代,不对称成为现代主义建筑的明确前提. 但即使是这类建筑也只是在中轴线上不对称,还有许多小的地方是对称的.

在写作中各个层次上都有对称,从句子中的词组到小说的结构. 音乐和绘画也是如此. 由相同颗粒组成的马赛克画(和某些塞尚的画)有特别的视觉冲击力. 组合而成的对称产生了一些最难忘的作品: 亚当的诞生美洲哥特式教堂.

在数学和工程里递归特别有用. 归纳法惊人地简洁. 能够用递归解决的软件问题几乎肯定是最好的解决办法. 埃菲尔铁塔引人注意的部分原因是它是递归的: 一个塔叠着一个塔.

对称,尤其是重复的危险在于,它可能会代替思考.

好的设计模仿自然. 与其说模仿自然有本质上的好处,还不如说大自然已经花了亿万年的时间探索问题的解决方案. 如果你的答案模仿了自然,那是个好迹象.

复制并不是作弊. 没人会否认故事应该象生活. 从生活中找到灵感也是绘画的法宝, 虽然它的任务经常被误解. 目标是不要简单地作个记录, 要点是它给你某些值得玩味的东西: 当你的目光注视着一个物体,你的手会做出更有趣的工作.

效法自然在工程领域也是起作用的. 船很久以来就有脊骨和加强筋,好象动物的胸腔. 在某些情况下我们不得不等待更好的技术出现: 早期的飞机设计者错误地把飞机设计成鸟的样子, 但是他们没有足够轻的材料或动力(莱特兄弟的引擎重152磅,却只有12马力的输出.),也没有精巧的导航系统使得机器象鸟一样飞翔. 不过我预测小型的能象鸟一样飞行的无人驾驶飞机会在五十年内出现.

既然有了强大的计算能力,我们不但可以模仿大自然的结果,也可以模拟大自然的方法. 基因算法能让我们创造出因为太复杂而在通常条件下设计不出的东西.

好的设计是再设计. 第一次就把事情做对的可能性是很小的. 专家料到会扔掉一些初期的作品,他们为计划的改变作了计划.

把作品扔掉需要自信. 你必须这样想,会有更多的成果出现. 举个例子,人们刚开始学画的时候,不情愿重画那些不好的地方. 他们觉得做到这步已经很幸运了,如果重做的话,可能会更糟. 于是他们说服自己这画还没有那么糟, 真的 — 事实上,也许就该这么画.

(这样说服自己)真是危险; 为了培养一种不满足的精神而犯错会更好. 达芬奇的素描里,经常是五六次尝试才能画出一条线的准确位置. 与众不同的Porsche 911的背后,是笨拙的原型. Wright原先的Guggenheim的设计里, 右半部是个金字塔形的建筑(ziggurat),他把它倒转成现在的模样.

犯错是正常的. 不要把错误视为灾难, 而要把它们弄得容易证实和修复. 达芬奇或多或少发明了素描, 使得画画能够承受更多的负荷和探索. 开发源代码的软件错误少些,因为它承认犯错误的可能性.

如果介质能使改变变得容易, 是有帮助的. 油画颜料在十五世纪取代蛋彩的时候, 画家开始能够处理一些诸如人像画等困难的题材, 因为不象蛋彩,油画颜料可以混合和覆盖.

好的设计可以复制. 对复制的态度通常会走一条弯路. 新手还没有了解就开始模仿; 然后他有意识地试图原创; 最后,他认识到正确比原创更重要.

无知的模仿几乎就是坏设计的秘方. 如果你不知道你的想法从哪里来,你可能在模仿一个模仿者. 拉斐尔风格在十九世纪中期是如此流行,以至于每个学画的人都要模仿他, 甚至是模仿的模仿. 正是这种风气,而不是拉斐尔本人的作品,惹恼了拉斐尔前派艺术家.

有雄心的人不满足于模仿. 鉴赏力成长的第二阶段是有意识地以原创为目标.

我认为最伟大的大师们有一种忘我的精神. 他们一心想得到正确的答案,因此如果正确答案的某些部分已经被人发现了,那么没有理由不用它. 他们有足够的自信从别人那儿汲取养料,而不担心在此过程中失去自己的观念.

好的设计通常是奇特的.一些最杰出的作品有不可思议的品质: 欧拉公式, 勃鲁盖尔(Brueghel)的雪中猎人 ,SR-71, Lisp. 它们不仅是美的, 而且是奇异地美.

我不知道原因. 可能是我自己愚昧无知. 开罐器对狗来说一定也是不可思议的. 如果我足够聪明的话, 会觉得ei*pi = -1 是世界上最自然的事情. 不论如何,此公式肯定是真理.

我在本文里提到的大多数品质是可以培养的, 但我不认为奇异性可以培养. 你能做的最好的事情是有这个苗头的时候,不要去压制它. 爱因斯坦没有试图把相对论弄得奇特. 他试图找出真理, 而这真理显得很奇特.

唯一值得拥有的风格是你不能刻意追求的那种. 对奇异性来说, 尤其是这样. 没有捷径可走. 风格主义派(Mannerists), 浪漫派(Romantics)和两代美国高中生苦苦寻找的西北航路是不存在的. 到达它(奇异性)的唯一办法是经受好的(设计),然后从另一头出来.

好的设计成批出现.十五世纪佛罗伦萨的居民包括:布鲁内勒斯基 (Brunelleschi), 吉尔伯提(Ghiberti), 多纳泰罗 (Donatello), 马萨其奥(Masaccio), 菲利波·利比(Filippo Lippi), 弗拉·安吉利科(Fra Angelico), 维洛及欧(Verrocchio), 波提切利(Botticelli), 达芬奇(Leonardo da Vinci), 和米开朗基罗 (Michelangelo). 米兰当时和佛罗伦萨一样大, 你能说出多少米兰艺术家?

十五世纪的佛罗伦萨发生了一些事情,而且它是不可遗传的, 因为现在不发生了. 你必须假定无论达芬奇和米开朗基罗有什么先天的因素,米兰人也应该有. 可以米兰的达芬奇呢?

美国现在的人口大约是十五世纪佛罗伦萨的一千倍. 一千个达芬奇和一千个米开朗基罗生活在我们中间. 如果仅由DNA支配一切, 我们天天会碰到艺术杰作. 我们没有, 原因是你要创造达芬奇, 不仅需要他天生的能力, 还要1450年的佛罗伦萨.

没有什么比一群有才能的人在相关问题上进行探索更强大的了. 比较起来, 基因无足轻重: 具有达芬奇的基因不足以补偿住得离米兰近而离佛罗伦萨远. 现代人迁移得更多了, 但伟大的作品仍然不成比例地来自几个热点地区: 鲍豪斯 (Bauhaus), 曼哈顿计划, 纽约客, 洛克希德的Skunk Works, 施乐的帕洛阿尔托研究中心(Xerox Parc).

在任何时候,只有有限的课题和有限的做出伟大工作的小组. 如果你离这些中心太远, 就几乎不可能有出色的工作. 你可以在某种程度上顺应或反对这种趋势, 但你不能脱离它.(也许你能, 但米兰的达芬奇没有成功.)

好的设计通常是大胆的.历史上的每个时期,人们都会相信一些荒谬的东西, 而且是如此坚定, 你得冒着被排斥甚至暴力的风险说出不同的意见.

如果我们的时代有不同的话,真是太好了. 就我目前的观察,还没有.

这个问题不仅折磨着每个时代,而且某种程度上折磨着每个领域. 许多文艺复兴时期的作品在那个时代长期被认为是可怕的:根据Vasari的说法,Botticelli忏悔并放弃了绘画,Fra Bartolommeo和Lorenzo di Credi actually居然烧掉了部分作品. 爱因斯坦的相对论令许多同时代的物理学家感到不快, 几十年来没有被完全接受, 在法国,直到1950年代.

今天的实验性的错误是明天的理论. 如果你想发现伟大的新事物, 不该对传统智慧和理论不太涉及到的地方视而不见, 而要特别地注意它们.

作为特例,我认为看见丑陋要比想象出美丽容易. 大多数创造出美丽事物的人是通过修改他们觉得丑陋的地方来达到目标的. 伟大的作品往往是这样产生的: 某人看到某物并想, 我可以做得比这好. 乔托(Giotto)看到传统的按公式刻画出来的圣母像让几个世纪的人们感到满意,但他却觉得看上去笨拙和不自然. 哥白尼为一个同时代人普遍接受的理论深深苦恼, 觉得一定有更好的解决办法.

不能忍受丑陋还不够. 在发展出知道哪儿需要修改的嗅觉之前, 你得对该领域非常理解. 你得埋头苦干. 你成为专家之后, 你会听到内心的声音: What a hack! 一定会有更好的办法. 不要忽略这种声音,培养它们. 伟大作品的秘决是: 非常准确的鉴赏力加上能使它满足的能力.


原注
Sullivan 实际上说的是: 形式永远跟随功能. (form ever follows function.) 不过我认为这个不准确的引用更接近现代主义建筑师的意思.

Stephen G. Brush, “Why was Relativity Accepted?” Phys. Perspect. 1 (1999) 184-214.