*转一下邹欣老师最近写的这个系列，虽标题是读后感，但其实内容都是自己长期经验的积累，有感而发。*

*推荐邹欣老师的博客：*http://yishan.cc/blogs/xin/default.aspx
梦断代码 读后感 (I) 驱动和责任

几个星期前，我给《现代软件工程》课的每一个团队<http://greatsoftware.spaces.live.com/lists/cns%2142F139862BB64716%21307/>都发了一本
《Dreaming In Code<http://www.amazon.com/Dreaming-Code-Programmers-Transcendent-Software...>》
的中文版
《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一
到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了
中文版，也有一些感想如下。

[image: Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs,
and One Quest for Transcendent
Software]<http://www.amazon.com/gp/product/images/1400082471/sr=8-1/qid=1226816...>

*1）驱动*

到底是什么驱动程序员和管理人员，测试人员长年累月投入到一个软件项目中去？

有理论认为，传统的软件公司用工资，职位，绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作（大教堂/Cathedral模式）。其实，用开源， 社区，共享的模式会更好（集市/Bazaar模式）也许更好。正如在第26页所说的
[所有页码都是指英文版]

... it maps an alternate universe for programming in which time is simply
less important because the work is cooperative rather than corporate, the
workers are all volunteers, and the motivation is fun and ego, not financial
reward.  *[p26]*

这理论听起来很好，但是我想起了两个故事：

1) 美国的一个肥皂剧Seinfield里有一集，讲了一个混混Kramer<http://en.wikiquote.org/wiki/Seinfeld>热心地加入了一家公司，义务打工，起初他的口头幽默和热情感动了团队，领导委以重任，不料Kramer
根本没法儿把事情做好。最后领导只好找他谈话，Kramer 承认自己不行，他说- 但是俺是义务给你们打工的！ 领导说，对，这就是让我们为难的地方。。。
项目中来了一位"义务打工的"，照理说，对项目只有帮助，而且别人是"义务"，你怎么好意思把别人赶走？

2) 我以前在西雅图的时候参加过一个非营利组织
<http://www.nwchp.org/>，成员们都是有热情为社区服务，而且义务付出。但是后来有些成员就逐渐找不到了，一些事情也不了了之。
由于大家都是义务贡献，你没法如何要求别人。

在Chandler 项目中，Andy Hertzfeld 就是这样一个义务作贡献的大牛。但是他也遇到了同样的"志愿者问题" -

They don't know whether to count on you or not. And because you're not
getting paid, there's lack of control. *[p167]*

后来这位Hertzfeld 也拍拍屁股走人了，大家可以为 fun 和 Ego 一起工作，但是如果fun  和 ego
都得不到满足，那motivation 也会急剧下降。

*2）责任
*和驱动紧密相关的，是责任 - Accountability.

在 Hard Drive<http://www.amazon.com/Hard-Drive-Making-Microsoft-Empire/dp/088730629...>这本书中，讲了这样的故事
- 由于Windows 一再拖延，BillG 最后跟 SteveB 说 - 如果今年下雪之前Windows
还没出来，你就别在这儿干了。 书中没有详细讲 SteveB 回头来又和他的团队讲了什么，但是第二天一个员工背着睡袋进驻了办公室。

很多年以后，Windows Vista 也经历了很长的拖延，在又一次宣布拖延之后，人们发现 Windows 团队中一个赫赫有名的 VP
已经卷起铺盖走了。

我们回过头来看，在Chandler 项目长达7年的拖延中，有没有发生过各位项目管理者引咎辞职的事？ 好像没有。
[有不少人离开，但是没有人直接为项目延期负责]  既然我上一次拖延没有什么惩罚，那我为什么一定要拼了老命要避免下一次拖延呢？

在传统意义上的软件公司，如果项目延期，那项目原计划的收入就拿不到，拖延的时间再长一些，员工就得走人，否则整个公司都被拖垮了。在"集市"，社区，共享的模 式下，大家都是义务，大家都在玩票，大家都做贡献，但是对最终项目不直接负责任，那到底谁负直接责任呢？

在《移山之道 <http://www.china-pub.com/42261>》 中，我讲了下面的例子：

阿超：我今天在"顶球"网吧看到大牛他爹在下棋，围观者支招的不少，有的说上马，有的说拱卒，有的说出车。大牛他爹一会儿招法就乱了，眼看局势不灵了，围观者一 哄而散，老崔后来也没法，只好认输了。

一个围棋国手在一次重要的对局后，听到旁观者对棋局的进程有很多不同的看法，他也没有过多争辩，只是说："无责任的旁观者和有重大责任的当局者的看法自然是不一 样的"。

无责任的旁观者在支招后，如果不灵，他可以面不改色地继续支招，甚至可以给另一位对局者支招，不管最后谁输谁赢，旁观者随时都能安心地离开，回家吃饭。有重大责 任的当局者在走了损招或败招之后，他很可能就要认输下台，丢掉比赛的奖金和头衔。

我 在清华大学的这一次《现代软件工程》课，我发现有些学生好像不是特别投入，后来了解到，由于申请学校用的GPA只计算前三年的成绩，第四学年课程的分数就
和申请学校没有什么关系了，所以比较"鸡肋"。有一个同学说，如果这门课是在第三学年，那许多同学们会非常计较分数，排名。现在，只要能过就可以了。怪不
得一两个项目中出现了 "花最少的努力，能过就行" 的心态。

一个软件团队可以制定出动人的远景/Vision<http://dtslob.spaces.live.com/blog/cns%218C36B08B06925203%21114.entry>，
但是如果大家没有搞清楚驱动项目的各种因素和每个角色应付的责任，那Vision只是一句话而已。

梦断代码 读后感（II） 交流和时间

[part 2]

几个星期前，我给《现代软件工程》课的每一个团队<http://greatsoftware.spaces.live.com/lists/cns%2142F139862BB64716%21307/>都发了一本
《Dreaming In Code<http://www.amazon.com/Dreaming-Code-Programmers-Transcendent-Software...>》
的中文版
《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一
到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了
中文版，也有一些感想如下。

[image: Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs,
and One Quest for Transcendent
Software]<http://www.amazon.com/gp/product/images/1400082471/sr=8-1/qid=1226816...>

*时间和交流：*时间对每一个人都是公平的，对每一个软件项目也是这样。

nearly all software projects require only 1/6 of their time for the writing
of code and fully 1/2 of their schedule for testing and fixing bugs.  But it
was rare project manager who actually planned to allocate developers' time
according to such a breakdown. *[p17]*

书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。
随着人数的增加，依赖关系的复杂，新手，老手员工之间的不同步，交流的成本会随着几何级数增加。在这里插播一个有奖竟猜：

当Windows 研发团队在开发Windows 2000的时候，团队内部每天有多少封e-mail 交流？
a) 90
b) 900
c) 9,000
d) 90,000

对每一个团队成员来说，他/她不仅要完成手头工作，还有报告自己的进展（通过email
或其他形式），回答别人的问题，了解其他人的进展。每个人的时间都是有限的，那怎么能保证我们在应付所有的交流/沟通之后，能有时间完成"手头工作"？

一 个微软的同事前两天跟我说，他们最近没写什么代码，集中精力做"planning"
去了，大家写了很多PowerPoint，改了很多PowerPoint。然后给VP, General Manger
做了两轮汇报，然后根据VP们的意见再修改，再汇报。。。 PowerPoint
的风格变得非常专业和花哨，但是他们仍然没有完成Planning，进入实质开发阶段。华丽的 PowerPoint 中的每一个条目，也需要花PM
很多时间才能写明白，让VP 了解，同时也要花一线dev/test 很多时间才能实现，但是VP，PM 和 Dev/Test
面对同一个条目，他们心里想的是同一回事么？

*外部交流*

在Chandler 项目中，幸运的是，他们没有这么多VP 要汇报 （真正的VP  -  Al Gore
只露了一个小脸），但是我注意到他们用于交流的时间也非常多。例如

*Every day* the developers shared a chat room via Internet Relay Chat (IRC)
[p139]

1 internal and  4 external email list set up.

blogs, wiki's...

这 些都是花时间的！我看到团队成员还要回复素未谋面的爱好者的各种问题（例如质问他们为何不用某某框架，等等），当然这种透明度也满足了很多人的好奇心，开
源，社区的优点么。。。 ...

read more »

2008/12/28 pongba <pon...@gmail.com>

read more »

2008/12/28 Zoom. Quiet <zoom.qu...@gmail.com>

I find it deeply *ironic that the news piece TSS cited at the top of the

Ted的这篇文章全文如下（不知为何暂时访问不了他的博客，以下是从google cache里面贴来的，所以有一些html格式，见谅）：

The recent "failure" of the Chandler PIM
project<http://blogs.tedneward.com/ct.ashx?id=813ea27d-1f63-4e95-8a7f-053d738...>generated
the question,
"*Can* *Dynamic* Languages
*Scale*?"<http://blogs.tedneward.com/ct.ashx?id=813ea27d-1f63-4e95-8a7f-053d738...>on
TheServerSide, and, as is all too typical these days, it turned into a
"You suck"/"No you suck" flamefest between a couple of posters to the site.

I now make the perhaps vain attempt to address the question meaningfully.
What do you mean by "*scale*"?

There's an implicit problem with using the word "*scale*" here, in that we *
can* think of a *language* scaling in one of two very orthogonal directions:

   1. Size of project, as in lines-of-code (LOC)
   2. Capacity handling, as in "it needs to *scale* to 100,000 requests per
   second"

Part of the problem I think that appears on the TSS thread is that the
posters never really clearly delineate the differences between these two.
Assembly *language* *can* *scale*(2), but it *can*'t really *scale*(1) very
well. Most people believe that C scales(2) well, but doesn't *scale*(1)
well. C++ scores better on *scale*(1), and usually does well on *scale*(2),
but you get into all that icky memory-management stuff. (Unless, of course,
you're using the Boehm GC implementation, but that's another topic
entirely.)

*Scale*(1) is a measurement of a language's ability to extend or enhance the
*complexity budget* of a project. For those who've not heard the term
"complexity budget", I heard it first from Mike Clark (though I *can*'t find
a citation for it via Google--if anybody's got one, holler and I'll slip it
in here), he of Pragmatic Project Automation fame, and it's essentially a
statement that says "Humans *can* only deal with a fixed amount of
complexity in their heads. Therefore, every project has a fixed complexity
budget, and the more you spend on infrastructure and tools, the less you
have to spend on the actual business logic." In many ways, this is a
reflection of the ability of a *language* or tool to raise the level of
abstraction--when projects began to exceed the abstraction level of
assembly, for example, we moved to higher-level languages like C to help
hide some of the complexity and let us spend more of the project's
complexity budget on the program, and not with figuring out which register
needed to have the value of the interrupt to be invoked. This same argument
*can* be seen in the argument against EJB in favor of Spring: too much of
the complexity budget was spent in getting the details of the EJB beans
correct, and Spring reduced that amount and gave us more room to work with.
Now, this argument is at the core of the Ruby/Rails-vs-Java/JEE debate, and
implicitly it's obviously there in the middle of the room in the whole
discussion over Chandler.

*Scale*(2) is an equally important measurement, since a project that cannot
handle the expected user load during peak usage times will have effectively
failed just as surely as if the project had never shipped in the first
place. Part of this will be reflected in not just the *language* used but
also the tools and libraries that are part of the overall software
footprint, but choice of *language* *can* obviously have a major impact
here: Erlang is being tossed about as a good choice for high-*scale* systems
because of its intrinsic Actors-based model for concurrent processing, for
example.

Both of these get tossed back and forth rather carelessly during this
debate, usually along the following lines:

   1. Pro-Java (and pro-.NET, though they haven't gotten into this
   particular debate so much as the Java guys have) adherents argue that a *
   dynamic* *language* cannot *scale*(1) because of the lack of type-safety
   commonly found in *dynamic* languages. Since the compiler is not there to
   methodically ensure that parameters obey a certain type contract, that
   objects are not asked to execute methods they couldn't possibly satisfy, and
   so on. In essence, strongly-typed languages are theorem provers, in that
   they take the assertion (by the programmer) that this program is
   type-correct, and validate that. This means less work for the programmer, as
   an automated tool now runs through a series of tests that the programmer
   doesn't have to write by hand; as one contributor to the TSS thread put
   it<http://blogs.tedneward.com/ct.ashx?id=813ea27d-1f63-4e95-8a7f-053d738...>:

   "With static languages like Java, we get a select subset of code tests,
   with 100% code coverage, every time we compile. We get those tests for
   "free". The price we pay for those "free" tests is static typing, which
   certainly has hidden costs."

   Note that this argument frequently derails into the world of IDE support
   and refactoring (as its witnessed on the TSS thread), pointing out that
   Eclipse and IntelliJ provide powerful automated refactoring support that is
   widely believed to be impossible on *dynamic* *language* platforms.
   2. Pro-Java adherents also argue that *dynamic* languages cannot *scale*(2)
   as well as Java *can*, because those languages are built on top of their
   own runtimes, which are arguably vastly inferior to the engineering effort
   that goes into the garbage collection facilities found in the JVM Hotspot or
   CLR implementations.
   3. Pro-Ruby (and pro-Python, though again they're not in the frame of
   this argument quite so much) adherents argue that the *dynamic* nature of
   these languages means less work during the creation and maintenance of
   the codebase, resulting in a far fewer lines-of-code count than one would
   have with a more verbose *language* like Java, thus implicitly improving
   the *scale*(1) of a *dynamic* *language*.

   On the subject of IDE refactoring, scripting *language* proponents point
   out that the original refactoring browser was an implementation built for
   (and into) Smalltalk, one of the world's first *dynamic* languages.
   4. Pro-Ruby adherents also point out that there are plenty of web
   applications and web sites that *scale*(2) "well enough" on top of the
   MRV (Matz's Ruby VM?) interpreter that comes "out of the box" with Ruby,
   despite the widely-described fact that MRV Ruby Threads are what Java used
   to call "green threads", where the interpreter manages thread scheduling and
   management entirely on its own, effectively using one native thread
   underneath.
   5. Both sides tend to get caught up in "you don't know as much as me
   about this" kinds of arguments as well, essentially relying on the idea that
   the less you've coded in a *language*, the less you could possibly know
   about that *language*, and the more you've coded in a *language*, the
   more knowledgeable you must be. Both positions are fallacies: I know a great
   deal about D, even though I've barely written a thousand lines of code in
   it, because D inherits much of its feature set and linguistic expression
   from both Java and C++. Am I a certified expert in it? Hardly--there are
   likely dozens of D idioms that I don't yet know, and certainly haven't
   elevated to the state of intuitive use, and those will come as I write more
   lines of D code. But that doesn't mean I don't already have a deep
   understanding of how to design D programs, since it fundamentally remains,
   as its genealogical roots imply, an object-oriented *language*. Similar
   rationale holds for Ruby and Python and ECMAScript, as well as for
   languages like Haskell, ML, Prolog, Scala, F#, and so on: the more you
   know about "neighboring" languages on the linguistic geography, the more
   you know about that *language* in particular. If two of you are learning
   Ruby, and you're a Python programmer, you already have a leg up on the guy
   who's never left C++. Along the other end of this continuum, the programmer
   who's written half a million lines of C++ code and still never uses the
   "private" keyword is *not* an expert C++ programmer, no matter what his
   checkin metrics claim. (And believe me, I've met way too many of these guys,
   in more than just the C++ domain.)

A couple of thoughts come to mind on this whole mess.
Just how refactorable are you?

First of all, it's a widely debatable point as to the actual refactorability
of *dynamic* languages. On NFJS speaker panels, Dave Thomas (he of the
PickAxe book) would routinely admit that not all of the refactorings
currently supported in Eclipse were possible on a *dynamic*
*language*platform given that type information (such as it is in a
*language* like Ruby) isn't present until runtime. He ...

read more »

文章中的"反正话儿"太多了，作为感想来说，是很好的感想，但是有一些地方不足以服人。
同一个事情，常常是"仁者风仁，智才见智"，但有时候更夸张，是"黑者见黑，白者见白"——完全相反的观点从同一个例子中得出
像outlook的那个例子，就可以正反两方面说（业界有一句名言："一个愤怒的用户背后是1000个离开的用户"），真*相究竟如何，恐怕不是听人讲故事和想 像猜测能够得出结论的。或者，如果有人认为自己的判断准确，请在几年前的背景下考虑这个问题：outlook中是否应该加入RSS功能？

Chandler毕竟只是个案。不宜过多推广。比如《读后感1》中对"驱动力"和"责任"的怀疑是有些道理的，但这样会给人造成一种错误印象，认为在这么基本的 问题上都有重大漏洞，这种模式怎么可能会走得通呢？其实这种方式在某些情况下是走得通的，人们需要的是这样一个问题的答案（而不是对它进行Yea/Nay的回答 ）：目前这种模式走得通的概率多大？
当然，作为感想，不应该为这种错误印象负责任。但作为一个教师，如果考虑更多，并且少作结论（或罗列向着同一个结论的事例），那么对他的学生会更有益处。
（说到责任问题，我也想到一个例子：10年前有些为什么企业不使用Linux？一个原因是：没有花钱购买，出问题时也就无法找到为之负责的厂商。那么，为什么现 在这几乎不再是一个问题了？你认为原因有多少个？分别是什么？有没有数据能支持你的这种判断？）

《读后感3》中关于设计应该"完美与否"的倾向性很明显。读过文章后应该很容易赞同作者。但是什么是完美呢？每个人，每个team，每个公司的判断标准不同，得 出的结论（特别是事前的结论，而不是事后的）也就不尽相同。如果作者关于完美与否的结论是正确的，我们打算去应用它指导当前项目，可是出现这样的情况该怎么办： 1、有人用"不完美更佳"作为借口拒绝良好的设计；2、有人认为当前的设计离完美还很远，我们现在就还可以在合理范围内改进它。如果出现了这样的种种情况，这种 "完美与否"的标签应该如何去使用呢？
还有一个问题，我想我需要帮助作者补充："完美与否"与项目成功与否没有严格的因果律？它是否需要和许多其它的因素共同起作用？

下面说一下我的读后感（对"读后感"的"读后感"）：如果有一个人的文章，能让读者看过后，认为自己已经了解了事情的本质，许多人就会捧着它大声叫好。因为它让 人有一种"终于明白事情运行机理"的成就感(
http://www.howstuffworks.com/)，这样就能够让自己显得很niubility；特别是对于有些人，对事情有些感性认识但没有完全搞懂，或没有亲自体验过（参见那个网站中的种种条目，不可能每个人 对每种都亲身经历过吧？），在读过这类文章后觉得自己"终于明白了！"，这种情况就觉得more
niubility，就更为叹服这篇文章。人们喜欢并乐于传播这样的讲演/文章/畅销书：将成功/失败的原因总结趋于简单化，如："我之所以成功（或失败），是 因为重视（或忽视）了人才。"
但是，Dreaming In
Code的作者没有这样做，他只是在叙述他了解的事情的整个过程，因为他知道这样复杂的一件事情不是能够那样简单地归结出原因的，甚至事情的成败还未最终定论。 但是他的这种苦心被一些人直接无视了，他们仍旧在这本书的基础上得出结论并乐于推广。我曾经推荐这本书给许多人，有些人读过后跟我说：哦，不就是Chandle r么，其实我很早就知道这个项目，它之所以失败，是因为……布拉布拉

这个书评，我之前也共享过，但是不至于推崇。因为我觉得这里面确实有一些闪光的想法，但是有些想法又比较，或者类似"Kenny Yuan"说的反正话太多。

这本书是我的好友韩磊翻译的，所以问世之前，我就听过了书中的很多故事。但是因为赠书一直没有给的原因，我还没有看过全文。也许我有点武断，虽然我看过样章后就 很推崇这本书，我总是觉得幸福的家庭是丰富多彩的，不幸的家庭却总是一样的。历史上有无数的错误的案例，为什么还有那么多项目继续前仆后继的去失败呢？我参加过 一些项目，有些看似成功，但是实际上早已失败，有些一开始就错的很离谱。

我不想谈我得到了什么教益，因为我觉得对某些失败，我的认识不停的还在改变。但是我想说，很可悲的是，一旦成功就没有人知道你本来就做错了，即使失败了，也没有 人能完全准确的找到负责人，所以我们身边充斥着各种各样的成功经验，有些来自于还没失败的项目，有些干脆就来自失败的项目。错误的种子，往往流传的更广。

这就是我另外一个由来已久的看法，很多巨大成功的事情，也很难说到底有多大的创新，而只是犯的错误少些，或者改正了前人的错误。例如Gmail的成功，很多人认 为是UI好，我只看重容量这一点。不是说任何时候都是越大越好，而是说，在Gmail推出的时候，有1G的容量，你才能让用户真得喜欢用WebMail。现在仍 旧写在Gmail首页的有这么一句话"
you'll never need to delete another
message"，这是核心的真理，如果用户在webmail上面需要删除邮件才能保证有足够的空间的话，那么他就不那么需要Webmail。但是这真得是伟大 的创新么？我不觉得，我觉得是之前的邮件运营商们忘记了什么是用户真正的需求。97-98年的4M邮箱，就等于现在的1G，那时候，他们是酷的，是创新的，只是 他们忘了时代变了。97-98年4M可以放下用户一年的信件，现在1G才可以。当年邮箱不用提供牛屄的垃圾邮件过滤系统，现在不行，我多次想尝试用用hotma il，但是人工从面摘取不是spam的信件太吃力了，所以，hotmail只能被我遗忘。所以，Gmail提供好的垃圾过滤，你可以说酷，但是那只是有人开始满 足用户真正的需求而已。

2008/12/29 Kenny Yuan <yuankain...@gmail.com>

银杏技术咨询公司
http://www.yinxingtech.com/

Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm

TV的Google观察
http://www.tinydust.net/tinygoogle/

我很想把Tinyfool的这一段话加粗加亮加到最大字号 :)

2008/12/29 Tiny fool <tinyf...@gmail.com>

2008/12/29 Tiny fool <tinyf...@gmail.com>

事情的成败
1)往往是很多因素综合作用的结果，而我们的大脑又总是禁不住"单一因果<http://en.wikipedia.org/wiki/Fallacy_of_the_single_cause>
"的诱惑。
2)连当事人往往也未必能够分析出来到底是什么原因导致的。因为当事人在对其成功归因的时候，往往是从两个方面入手的
    - "我跟别人有什么地方不一样？"
（实际上这倒是个很有用的启发法，只不过并不总是work就是了，因为毕竟自己能够觉察到的区别受到对"别人"的各方面因素的了解，和对自己的了解。有可能自己 总结出来的差异性其实是一个minor的因素，而真正的significant的差别却不容易感受到，比如性格方面的差异往往是很隐蔽的，因为性格对于我们就好 比水对于鱼一样）
    - "我原先猜测这个会让我成功，后来我成功了，因此，原因肯定就是我当时猜测的那个"（confirmation
bias<http://en.wikipedia.org/wiki/Confirmation_bias>
）李笑来老师在《把时间当做朋友》里面讲了一个故事(via <http://www.xiaolai.net/?p=423>)：

--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

2008/12/29 Tiny fool <tinyf...@gmail.com>

再到后来，维持成功的因素也许又会发生变化，因为积累了大量的用户之后，即便产品没有新兴产品做得那么好，也仍然能够持续成功，因为市场的惯性（用户习惯；用户 因迁移成本而产生的惰性；因多数人使用该产品而带来的从众效应、品牌效应等等），所以占领市场的公司，到后来其产品未必是最优的（当然前提是跟同类产品相比也没 有致命弱点），但至少肯定是人最多的:P

--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

2008/12/29 pongba <pon...@gmail.com>

其实还有一种方法能更快地增加上臂围：除了每天练到胳膊举不动之外，多吃蛋白粉，多吃维生素，多吃肌酸，所有食物都要搅成糊吃以利于吸收，此外还要多吃激素（严 重警告：睾丸酮类长期服用可能会使性能力丧失），如果能够坚持下来，上臂围超50也是很常见的事情……

伊索寓言式的结尾：以上的故事告诉我们什么呢？——每个人都想走捷径，而且往往也是有捷径可以走；只不过，捷径是有代价的。

--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/

中庸～管理者需要搞懂

2008/12/29 Kenny Yuan <yuankain...@gmail.com>

关于容量这一点我谈得简单了一点，我只说他出现的时候为什么成功了，不讨论后面怎么维系这个成功，所以，我稍微补充一下。

我的意思是，不要小看容量这一变化，在这里容量带来了质变。Webmail中Hotmail算是个鼻祖，后面跟风者如云，然而，到了Gmail出现的时候。全球 的Webmail都已经到了穷途末路之境，国内的尤其是，多加百兆的容量然后收点服务费，貌似是最好的选择。但是后面据我认识的朋友告诉我，VIP邮箱没什么真 正的油水。整个世界都认为Webmail就这么没什么意思了，要被超越的时候Gmail冒出来了。

容量大，才能做到文件都不删除，才能实现你不管到哪里，只要打开一个浏览器，就可以看到你全部的邮件。这不是简单的容量增加，这是重新定义Webmail，或者 说让Webmail回归本意。所以，我的意思是，不是Gmail有多牛。而是做老的Webmail的大家都迷失了，那时候的Webmail强调pop3特性，希 望用户都把信收到本地，然后删除服务器存档。web端的操作方便等等也不被重视。这样就把Webmail这本来可以作为每个人的随时在线的信息中心的作用抹杀了 。Gmail做的就是拨乱反正，回到正途。

就像我的Macbook因为硬件问题，崩溃过几次，我从来不备份apple mail，因为Gmail有全部的备份，下次安装好机器以后，再从新让Apple
mail去同步就可以了。这样我永远保持了信息的随时在线，也完全不损失本地操作的灵活和迅速，以及离线时的处理信息的能力。

2008/12/29 pongba <pon...@gmail.com>

银杏技术咨询公司
http://www.yinxingtech.com/

Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm

TV的Google观察
http://www.tinydust.net/tinygoogle/

2008/12/29 Tiny fool <tinyf...@gmail.com>

1) 当时为什么没有人想到通过广告收费？而不是通过收取容量费。
2)
本地客户端有很多不便（设置麻烦&需要安装从而对新手不利，本地存储从而对同步不利），webmail没这个问题，即便容量较小，但毕竟那个时候用邮件的人也没 有今天那么多邮件吧？（猜测）为什么webmail却到了穷途末路呢？是不是带宽原因？webmail在那个时候不增加容量是不是又是因为硬件价格原因呢？

--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

2008/12/29 pongba <pon...@gmail.com>

--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

跟AJAX，其实关系不大。

电子邮件最早像是某种标准件，不管什么网站都要做。最早的时候中国的大ICP几乎都有自己的电子邮件，好像你没有一个电子邮件系统就不是一个合格的网站一样。那 时候没人考虑邮件怎么赚钱，唯一通过邮件赚钱的就是类似网易这种给别人提供电子邮件的公司。

到了后来，网站的其他部分开始赚钱，但是邮件还是没又开始赚钱。而用户需要的空间越来越大（比如开始流行带附件，尤其是某些多媒体的。或者就是本身邮件数目狂增 。再者也有垃圾邮件的功劳），邮件服务提供者没有赚到钱，当然不会继续再给用户增大空间。

最早的时候，很多人是不懂如何使用本地客户端的，但是如果你的空间总是占满，你要不然就需要随时删邮件，要不然就需要学会本地客户端。我01年在某公司做网管的 时候，一个常见的任务就是帮助公司的员工配置他们的邮件客户端，或者修复邮件客户段出现的问题。所以诚如你所说，那东西很不方便，但是因为webmail空间不 足，实际就强迫用户转向了用本地客户端收信。其他的一些原因，还包括过去网速比较慢，信件较多的时候，客户端明显效率高些（对于时间收费的网民也经济一些，那时 候的好习惯是，上线收信，下线回信）。

另一方面，随着ICP网站的发展，邮件客户越来越多，占用了大量的资源，却毫无收益。所以在，02-03年左右（具体时间待查吧），263等开始停止或者部分停 止免费服务，开始VIP收费服务。虽然后来据说某些VIP还是收到了大量的金钱。但是很多服务商直接关闭免费，我说他们穷途末路估计不过分，不到穷途末路，谁会 把花了大量真金白银的才积累来的客户都赶走了。

这里的矛盾在于，ICP网站希望用户使用他们的Webmail，有流量可以做广告，但是空间给的少，用户自然很少上Webmail，而直接用客户端收信。ICP 网站都不希望用户用pop3，因为消耗一样的流量，一点钱都赚不到。但是谁也不敢率先不支持pop3，把用户推给对手。

Webmail最大的好处在于随时在线，信息不需要同步，用户会有非常高的粘度。但是容量不足，速度不快，用起来不方便，用户就会转向客户端。所以,Gmail 出现的时机很好，全球带宽水平都已经上来了，网速很快了，我们可以上网的地点和场景也多了，所以然后解决容量问题和便捷问题以后就自然会受到用户的追捧。

2008/12/29 pongba <pon...@gmail.com>

银杏技术咨询公司
http://www.yinxingtech.com/

Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm

TV的Google观察
http://www.tinydust.net/tinygoogle/

我来插一句，看看别人和我的印象是不是相同的：

1）当时投放广告的模式还没改过来，还没有这样在邮箱里准确投放广告的。可以说google在邮件方面又发明了一根电线杆
2）容量费是在泡沫吹破的时候向用户趁伙打劫的，形成了习惯思维吧？中国还有尝试手机（通知）收费的
本地客户的使用模式有惯性，而且大家都觉得邮件在本地才保险（还是思维惯性吧）
那个时候，发达国家的带宽正好在增长，对于webmail应该算是已经可用了，这个时机也不错（现在他们的ADSL2+更牛——相比我们的ADSL来说）
3）如你所说，AJAX。那时候的Webmail都是点一下要刷半天的传统HTML，UE太差

最重要的一点：gmail让后来的用户觉得"webmail的世界本来就应该是这个样子"（用户通常不知道要什么，直到你给了他真正想要的东西）

2008/12/29 pongba <pon...@gmail.com>

再加一条：如果一个人在同一台计算机上收邮件，那么对client的惯性就很难改变，直到他开始在2台或2台以上的电脑上试图同步邮件……可能当时人们使用邮件 的习惯开始向这个方向发展了？（这一条是我估计的，没谱儿）

2008/12/29 Kenny Yuan <yuankain...@gmail.com>

On Dec 29, 4:04 pm, "Kenny Yuan" <yuankain...@gmail.com> wrote:

这个，得按美国算吧？当时国内的用户习惯应该还不是google考虑的重点。

2008/12/29 Bennie <ZhaoYin...@gmail.com>

又有谁能说软件开发不是一场灾难呢。。。

其实我很久以来一直觉得，pop3是一个太落后的协议，因为只支持收取，而没有邮件的状态一说。其实我不在意邮件是否可以永久保留，为了整洁和信息归档等原因， 我情愿删除我不需要的那些邮件。但是我很难忍受收取后就没有了这种“单向同步”方式。也因此其实我很不喜欢客户端，不能在多个地方收取（就算有“保留在”服务器 端的功能还是很不方便，例如多次同步等等），所以我一直喜欢用Webmail。我最喜欢就是Outlook + Exchange这种组合方式，现在Windows Live也有这种方式了，我很兴奋。

Jeffrey Zhao

From: Kenny Yuan
Sent: Monday, December 29, 2008 4:04 PM
To: pongba@googlegroups.com
Subject: [TopLanguage] Re: {转载}《梦段代码》读后感(I, II, III) by 邹欣

再加一条：如果一个人在同一台计算机上收邮件，那么对client的惯性就很难改变，直到他开始在2台或2台以上的电脑上试图同步邮件……可能当时人们使用邮件 的习惯开始向这个方向发展了？（这一条是我估计的，没谱儿）

2008/12/29 Kenny Yuan <yuankain...@gmail.com>

  我来插一句，看看别人和我的印象是不是相同的：

  1）当时投放广告的模式还没改过来，还没有这样在邮箱里准确投放广告的。可以说google在邮件方面又发明了一根电线杆
  2）容量费是在泡沫吹破的时候向用户趁伙打劫的，形成了习惯思维吧？中国还有尝试手机（通知）收费的
  本地客户的使用模式有惯性，而且大家都觉得邮件在本地才保险（还是思维惯性吧）
  那个时候，发达国家的带宽正好在增长，对于webmail应该算是已经可用了，这个时机也不错（现在他们的ADSL2+更牛——相比我们的ADSL来说）
  3）如你所说，AJAX。那时候的Webmail都是点一下要刷半天的传统HTML，UE太差

  最重要的一点：gmail让后来的用户觉得"webmail的世界本来就应该是这个样子"（用户通常不知道要什么，直到你给了他真正想要的东西）

  2008/12/29 pongba <pon...@gmail.com>

    2008/12/29 Tiny fool <tinyf...@gmail.com>

      全球的Webmail都已经到了穷途末路之境，国内的尤其是，多加百兆的容量然后收点服务费，貌似是最好的选择。但是后面据我认识的朋友告诉我，VIP邮箱没什 么真正的油水。整个世界都认为Webmail就这么没什么意思了

    这个有意思，我对这段历史没有任何感觉，因为接触网络比tiny晚多了。所以我想在这个问题上多向tiny请教两句：

    1) 当时为什么没有人想到通过广告收费？而不是通过收取容量费。
    2) 本地客户端有很多不便（设置麻烦&需要安装从而对新手不利，本地存储从而对同步不利），webmail没这个问题，即便容量较小，但毕竟那个时候用邮件的人也没 有今天那么多邮件吧？（猜测）为什么webmail却到了穷途末路呢？是不是带宽原因？webmail在那个时候不增加容量是不是又是因为硬件价格原因呢？

    --
    刘未鹏(pongba)
    Blog|C++的罗浮宫
    http://blog.csdn.net/pongba
    TopLanguage
    http://groups.google.com/group/pongba

  --
  Kenny Yuan
  C++, UI, LISP, MMA, Psychology and Automobile.
  BLOG: CS巴别塔(Computer Science Babel)
  URL: http://blog.csdn.net/yuankaining/

--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/

Kenny Yuan 于 12/29/2008 04:04 PM http://embed.mibbit.com/?channel=zhusupe 写道:

2008/12/29 Jeffrey Zhao <je...@live.com>:

然

不过也只是略有不便，对我来说只是重复占用了我一些本地存储，我倒是不在乎

2008/12/29 graham <miao.gra...@gmail.com>

银杏技术咨询公司
http://www.yinxingtech.com/

Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm

TV的Google观察
http://www.tinydust.net/tinygoogle/