于是做了一些深入研究。

痘痘和血睾酮的关系就是，血睾酮大量分泌，然后导致皮脂腺分泌，然后就长痘了。看到一篇文章。说的是运动与血睾酮的关系。

———-持续更新——————

众多研究表明，长时间运动训练或力竭性运动会使血睾酮水平降低，但是引起这种变化的机制还不十分清楚。其可能的原因是多方面的：

(1) 长期激烈运动使骨骼肌增加了睾酮的肝外消耗。

(2) 训练使得机体在应急情况下睾丸大量分泌睾酮，应激后睾丸暂时处于 “耗竭状态”，也可能是睾丸本身的功能障碍导致睾酮分泌、合成减少。

(3) 血睾酮浓度与其降解率有关。

(4) 睾酮分泌水平变化在很大程度上受垂体分泌的黄体生成紊(LH)影响。

(5) 长期运动训练后游离睾酮下降幅度超过了总血皋酮下降的幅度，而血液中只有游离睾酮才具有直接生物活性作用，提示游离睾酮大幅度降低对运动性低血睾酮更具有直接意义

(6) 血睾酮下降由排泄引起。

(7) 缺硒引起血清睾酮和睾丸睾酮下降。

(8) 缺锌引起血清睾酮和睾丸睾酮含量降低。

偶尔当心很烦 我总是爱穿过捷运站

看着世界变换 时光像小偷拿走眼泪

从不同的地方

也许吧 泪滴在琴上 所以我有了歌能唱

回忆很美 未来很慢

我的故事因此写到一半

风吹着 我跑向远方 我知道爱也甜也酸

人要学会 停止流浪 我也一样

过去像一滴汗 静静地蒸发在马路上

偶尔当心很烦 我总是爱穿过捷运站

看着世界变幻 时光像小偷拿走眼泪

从不同的地方

也许吧 泪滴在琴上 所以我有了歌能唱

回忆很美 未来很慢

我的故事因此写到一半

风吹着 我跑向远方 我知道爱也甜也酸

人要学会 停止流浪 我也一样

天空从黑到白 继续地转换

热闹后的孤单 让人更加了解珍惜平凡

泪滴在琴上 有了歌能唱

回忆很美 未来很慢

我的故事因此写到一半

风吹着 我跑向远方 我知道爱也甜也酸

人要学会 停止流浪 我也一样

1.
—————————————————————–
return str.replace(/^\s\s*/, ”).replace(/\s\s*$/, ”);
——————————————————————-
All things considered, this is probably the best all-around approach. Its speed advantage is most notable with long strings — when efficiency matters. The speed is largely due to a number of optimizations internal to JavaScript regex interpreters which the two discrete regexes here trigger. Specifically, the pre-check of required character and start of string anchor optimizations, possibly among others.

2.
——————————————————————-
return str.replace(/^\s+/, ”).replace(/\s+$/, ”);
——————————————————————-
Very similar to trim1 (above), but a little slower since it doesn’t trigger all of the same optimizations.

3.
——————————————————————-
return str.substring(Math.max(str.search(/\S/), 0), str.search(/\S\s*$/) + 1);
——————————————————————-
This is often faster than the following methods, but slower than the above two. Its speed comes from its use of simple, character-index lookups.

4.
——————————————————————-
return str.replace(/^\s+|\s+$/g, ”);
——————————————————————-
This commonly thought up approach is easily the most frequently used in JavaScript libraries today. It is generally the fastest implementation of the bunch only when working with short strings which don’t include leading or trailing whitespace. This minor advantage is due in part to the initial-character discrimination optimization it triggers. While this is a relatively decent performer, it’s slower than the three methods above when working with longer strings, because the top-level alternation prevents a number of optimizations which could otherwise kick in.

5.
——————————————————————-
str = str.match(/\S+(?:\s+\S+)*/);
return str ? str[0] : ”;
——————————————————————-
This is generally the fastest method when working with empty or whitespace-only strings, due to the pre-check of required character optimization it triggers. Note: In IE6, this can be quite slow when working with longer strings.

6.
——————————————————————-
return str.replace(/^\s*(\S*(\s+\S+)*)\s*$/, ‘$1′);
——————————————————————-
This is a relatively common approach, popularized in part by some leading JavaScripters. It’s similar in approach (but inferior) to trim8. There’s no good reason to use this in JavaScript, especially since it can be very slow in IE6.

7.
——————————————————————-
return str.replace(/^\s*(\S*(?:\s+\S+)*)\s*$/, ‘$1′);
——————————————————————-
The same as trim6, but a bit faster due to the use of a non-capturing group (which doesn’t work in IE 5.0 and lower). Again, this can be slow in IE6.

8.
——————————————————————-
return str.replace(/^\s*((?:[\S\s]*\S)?)\s*$/, ‘$1′);
——————————————————————-
This uses a simple, single-pass, greedy approach. In IE6, this is crazy fast! The performance difference indicates that IE has superior optimization for quantification of “any character” tokens.

9.
——————————————————————-
return str.replace(/^\s*([\S\s]*?)\s*$/, ‘$1′);
——————————————————————-
This is generally the fastest with very short strings which contain both non-space characters and edge whitespace. This minor advantage is due to the simple, single-pass, lazy approach it uses. Like trim8, this is significantly faster in IE6 than Firefox 2.
Since I’ve seen the following additional implementation in one library, I’ll include it here as a warning:
——————————————————————-
return str.replace(/^\s*([\S\s]*)\b\s*$/, ‘$1′);
——————————————————————-
Although the above is sometimes the fastest method when working with short strings which contain both non-space characters and edge whitespace, it performs very poorly with long strings which contain numerous word boundaries, and it’s terrible (!) with long strings comprised of nothing but whitespace, since that triggers an exponentially increasing amount of backtracking. Do not use.

A different endgame
There are two methods in the table at the top of this post which haven’t been covered yet. For those, I’ve used a non-regex and hybrid approach.

After comparing and analyzing all of the above, I wondered how an implementation which used no regular expressions would perform. Here’s what I tried:

——————————————————————-
function trim10 (str) {
var whitespace = ‘ \n\r\t\f\x0b\xa0\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u200b\u2028\u2029\u3000′;
for (var i = 0; i < str.length; i++) {
if (whitespace.indexOf(str.charAt(i)) === -1) {
str = str.substring(i);
break;
}
}
for (i = str.length - 1; i >= 0; i–) {
if (whitespace.indexOf(str.charAt(i)) === -1) {
str = str.substring(0, i + 1);
break;
}
}
return whitespace.indexOf(str.charAt(0)) === -1 ? str : ”;
}
——————————————————————-
How does that perform? Well, with long strings which do not contain excessive leading or trailing whitespace, it blows away the competition (except against trim1/2/8 in IE, which are already insanely fast there).

Does that mean regular expressions are slow in Firefox? No, not at all. The issue here is that although regexes are very well suited for trimming leading whitespace, apart from the .NET library (which offers a somewhat-mysterious “backwards matching” mode), they don’t really provide a method to jump to the end of a string without even considering previous characters. However, the non-regex-reliant trim10 function does just that, with the second loop working backwards from the end of the string until it finds a non-whitespace character.

Knowing that, what if we created a hybrid implementation which combined a regex’s universal efficiency at trimming leading whitespace with the alternative method’s speed at removing trailing characters?

——————————————————————-
function trim11 (str) {
str = str.replace(/^\s+/, ”);
for (var i = str.length – 1; i >= 0; i–) {
if (/\S/.test(str.charAt(i))) {
str = str.substring(0, i + 1);
break;
}
}
return str;
}
——————————————————————-
Although the above is a bit slower than trim10 with some strings, it uses significantly less code and is still lightning fast. Plus, with strings which contain a lot of leading whitespace (which includes strings comprised of nothing but whitespace), it’s much faster than trim10.

In conclusion…
Since the differences between the implementations cross-browser and when used with different data are both complex and nuanced (none of them are faster than all the others with any data you can throw at it), here are my general recommendations for a trim method:

Use trim1 if you want a general-purpose implementation which is fast cross-browser.
Use trim11 if you want to handle long strings exceptionally fast in all browsers.
To test all of the above implementations for yourself, try my very rudimentary benchmarking page. Background processing can cause the results to be severely skewed, so run the test a number of times (regardless of how many iterations you specify) and only consider the fastest results (since averaging the cost of background interference is not very enlightening).

As a final note, although some people like to cache regular expressions (e.g. using global variables) so they can be used repeatedly without recompilation, IMO this does not make much sense for a trim method. All of the above regexes are so simple that they typically take no more than a nanosecond to compile. Additionally, some browsers automatically cache the most recently used regexes, so a typical loop which uses trim and doesn’t contain a bunch of other regexes might not encounter recompilation anyway.

——————————————————————————–

Edit (2008-02-04): Shortly after posting this I realized trim10/11 could be better written. Several people have also posted improved versions in the comments. Here’s what I use now, which takes the trim11-style hybrid approach:
——————————————————————-
function trim12 (str) {
var str = str.replace(/^\s\s*/, ”),
ws = /\s/,
i = str.length;
while (ws.test(str.charAt(–i)));
return str.slice(0, i + 1);
}
——————————————————————-

我要飞得更高
飞得更高
狂风一样舞蹈
挣脱怀抱
我要飞得更高
飞得更高
翅膀卷起风暴
心生呼啸
飞得更高

一直在飞 一直在找
可我发现 无法找到
若真想要 是一次解放
要先剪碎 这有过的往
我要的一种生命更灿烂
我要的一片天空更蔚蓝
我知道我要的那种幸福
就在那片更高的天空

我时不时的就会收到这样的Email。写这些邮件的人几乎都是跟技术不沾边的人，或正在研究他们的第一个产品。起初，当听到人们这样的话，我总是十分的恼怒。他们在跟谁辩论软件开发所需要的时间？但后来我意识到，即使我自己对自己的项目预测要花去多少开发时间,我也是一筹莫展。如果连我自己都做不好，我何必对那些人恼怒呢？

真正让我郁闷的不是他们预估的错误。问题在于他们竟然认为自己可以做出正确的估计。作为开发人员，我们经常会发现，在软件开发的问题上，一个外行人会很自然的把复杂的事情估计的很简单。

这并不是为我们的愤怒找借口。但这引起了另外一个有趣的问题：为什么我们天生的预测复杂性的能力在遇到编程问题时会失灵？

为了回答这个问题，让我们来认识一下我们的大脑如何估计事情的。有些事情对于一些没有经验的人也很容易预估正确，但有些事情则不然。

我们来想想观看一个人弹吉他。即使你从来没有弹过吉他，在观看了一场弹奏《玛丽有只小羊羔(Mary had a Little Lamb)》的吉他表演后，你也能大概推测出这很简单，一个人不需要太高的技术就能演奏出来。同样，当观看了有人演奏D大调的《卡农(Pachabel’s Canon)》后，你也很容易推测出，这很复杂，需要很长时间的练习才能演奏的出来。

为什么我们能够很迅速准确的预估这两首曲子的复杂性呢？这是跟我们用来判断一个事情简单和还是复杂的方法有关的。我们的大脑有一些现成的模式来完成这些事情，首先一个就是根据速度。这种情况下，大脑会辨别每秒钟演奏的东西。根据每秒钟演奏了多少东西，我们很容易有一个直观的判断曲子的复杂度。因为用吉他演奏一首歌是一种物理过程，一种感官上的活动，我们的大脑很容易依此来推测速度，继而转换成复杂度。

我们还有另外一个天生的推测依据：体积。想想把一个帐篷和一栋公寓放在一起对比。即使一个人从来没有学过建筑学，他也能告诉你通常设计和建造一个帐篷会比设计和建造一栋公寓要简单。为什么？因为我们天生的会使用物理体积作为事物复杂性的一个指标。

当然。上面说的这两种逻辑分析并不是总是100%的有效。但大多数情况下，人们就是这样干，而且很成功。大多数情况中，我们在对物理过程评估时，我们的大脑会对物理事物进行有效的关联，不需要依赖之前的经验。

现在让我们来谈谈软件。当一个不懂技术的人试图对软件开发时间进行评估时，有两个很基本的直观指标在辅助他们：以体积为指标的复杂度和以速度为指标的复杂度。但他们没有意识到，软件跟他们想象的不一样。软件本质上不是有形物质。没有体积和速度。它的极小的组成部分可能会时不时的在电脑屏幕上闪现。正因为如此，当面对开发一个web应用时(或任何类型的软件)，我们的基本直观感觉失效了。

这第一点，速度，很显然根本不可能被外行人拿来对软件进行评估。于是很自然的，他们倾向于使用体积指标进行评估。要么是根据描述文档的页数，要么是根据软件的功能用例数或特征数。

有时候，这种评估手段确实有效！当面对一个静态网站，没有特别的设计要求，外行人很容易用这种方法估计出开发时间。但是，通常情况下，对于软件开发，体积并不能真实有效的反映复杂度。

不幸的是，对于软件的复杂度，唯一有效的推测方法是依据经验。而且还不是时时都好用。作为一个程序员，我知道，根据我之前开发过的相似的功能特征，我可以估计出现在的这些功能特征各自要多少开发时间。然后，我把总时间加起来，这就得到了完成整个项目需要的大致时间。然而，事实情况中，每个项目在开发过程中都遇到二、三个瓶颈。这些瓶颈会肆意的消耗程序员的大量时间，你在遇到它们之前根本不会有所预见。它们会拖住整个项目，致使工期延后数周甚至数月。

这些是没有经验的人在评估复杂度时不会理解的。他们不明白在其他事情上都很灵的方法，为什么放到软件开发上就不灵了。所以，下一次当你听到有人说“我想你几天时间就能把它开发出来”时，不管是谁说的，都不要懊恼。深呼吸一下，告诉他这篇文章的地址，自己该干什么还干什么。

[本文英文原文链接：I'm Sure It Will Only Take You A Few Days To Code ]

[ZZ:http://www.aqee.net/im-sure-it-will-only-take-you-a-few-days-to-code/]