酷壳 – CoolShell.cn

SteveY对Amazon和Google平台的吐槽

2011年11月03日陈皓评论 170 条评论 173,403 人阅读

Steve Yegge， Amazon的前员工，现任Google员工，其本来想在Google+上和Google的员工讨论一些关于平台的东西，结果不小心把圈子设成了Public，结果这篇文章就公开给了全世界，引起了剧烈的反应。发布后很快他就马上把这篇文章删了，不过，互联网上早备份了下来——SteveY’s Google Platforms Rant。后来，Steve在其Google+上作了一些解释，大体是说他喝多了，而且又是在凌晨，所以大脑不清，文章中的观点很主观，极端且不完整，还有Google的PR对他很好，等等，等等。

几个星期前看到时就一直都想翻译一下这篇文章，不过因为最近事情太多，文章又很长，所以现在才翻译完成，翻译的不好，还请大家指正。

导读

在你阅读正文以前，我想说明几点，希望你注意一下：

Steve这个人非常喜欢写长篇大论的东西。而且比较喜欢辛辣调侃和恶搞的文风，这点大家要注意！

文中先“骂”Amazon公司，再通过“骂”Amazon的创始人贝索斯Bezos并烘托出他的的悟性和雄心，最后教育了一下Google。

我把文章分成了三个部分，这样方便大家阅读和讨论。第一部分只是个人情绪化的抱怨，第二部分是说Amazon的成长，第三部分是教育Google，我觉得第二部和第三部分是重点。

对于我们来说，我们应该获取Steve那些关于平台（Platform）相关的那些有价值的观点。尤其是他说的Amazon如何进化成一个平台性的公司，以及阐述Google应该怎么做的那些观点。

关于对Amazon的那些指责，我想说，6年，对于一个世界级的互联网公司，已经很不一样了。

正文

第一部分

我曾在Amazon工作了六年半，现在，我在Google的日子也差没不多这么长了。对于这两家公司，有一件事总是萦绕着我——这种感觉一天比一天强烈──那就是，Amazon每件事都做错了，而Google每件事都做对了。当然啦，这是很笼统的话，但却是惊人的准确，相当的疯狂吧。大概有一百甚至两百种不同的地方可以让我们去比较这两个公司，而Google可能在每一项都能胜出，如果我记的没错，除了其中3项以外。因为，我曾用电子表格把这些项都列出来了，只是法务部门不会让我给任何人看，即使人事招募部门很喜欢这个报表。

…

阅读全文 Read More

(59 人打了分，平均分： 4.46 )

深入理解C语言

2011年11月01日陈皓评论 190 条评论 169,494 人阅读

Dennis Ritchie 过世了，他发明了C语言，一个影响深远并彻底改变世界的计算机语言。一门经历40多年的到今天还长盛不衰的语言，今天很多语言都受到C的影响，C++，Java，C#，Perl， PHP， Javascript，等等。但是，你对C了解吗？相信你看过本站的《C语言的谜题》还有《谁说C语言很简单？》，这里，我再写一篇关于深入理解C语言的文章，一方面是缅怀Dennis，另一方面是告诉大家应该如何学好一门语言。（顺便注明一下，下面的一些例子来源于这个slides）

首先，我们先来看下面这个经典的代码：

int main()
{
    int a = 42;
    printf(“%d\n”, a);
}

从这段代码里你看到了什么问题？我们都知道，这段程序里少了一个#include <stdio.h> 还少了一个return 0;的返回语句。

不过，让我们来深入的学习一下，

这段代码在C++下无法编译，因为C++需要明确声明函数
这段代码在C的编译器下会编译通过，因为在编译期，编译器会生成一个printf的函数定义，并生成.o文件，链接时，会找到标准的链接库，所以能编译通过。
但是，你知道这段程序的退出码吗？在ANSI-C下，退出码是一些未定义的垃圾数。但在C89下，退出码是3，因为其取了printf的返回值。为什么printf函数返回3呢？因为其输出了’4′, ‘2’,’\n’ 三个字符。而在C99下，其会返回0，也就是成功地运行了这段程序。你可以使用gcc的 -std=c89或是-std=c99来编译上面的程序看结果。
另外，我们还要注意main()，在C标准下，如果一个函数不要参数，应该声明成main(void)，而main()其实相当于main(…)，也就是说其可以有任意多的参数。

我们再来看一段代码：

…

阅读全文 Read More

(58 人打了分，平均分： 4.09 )

API设计：用流畅接口构造内部DSL

2011年10月31日 Todd 评论 32 条评论 34,003 人阅读

感谢@weidagang （Todd）向酷壳投递本文。

程序设计语言的抽象机制包含了两个最基本的方面：一是语言关注的基本元素/语义；另一个是从基本元素/语义到复合元素/语义的构造规则。在C、C++、Java、C#、Python等通用语言中，语言的基本元素/语义往往离问题域较远，通过API库的形式进行层层抽象是降低问题难度最常用的方法。比如，在C语言中最常见的方式是提供函数库来封装复杂逻辑，方便外部调用。

不过普通的API设计方法存在一种天然的陷阱，那就是不管怎样封装，大过程虽然比小过程抽象层次更高，但本质上还是过程，受到过程语义的制约。也就是说，通过基本元素/语义构造更高级抽象元素/语义的时候，语言的构造规则很大程度上限制了抽象的维度，我们很难跳出这个维度去，甚至可能根本意识不到这个限制。而SQL、HTML、CSS、make等DSL（领域特定语言）的抽象维度是为特定领域量身定做的，从这些抽象角度看问题往往最为简单，所以DSL在解决其特定领域的问题时比通用程序设计语言更加方便。通常，SQL等非通用语言被称为外部DSL（External DSL）；在通用语言中，我们其实也可以在一定程度上突破语言构造规则的抽象维度限制，定义内部DSL（Internal DSL）。

本文将介绍一种被称为流畅接口（Fluent Interface）的内部DSL设计方法。Wikipedia上Fluent Interface的定义是：

A fluent interface (as first coined by Eric Evans and Martin Fowler) is an implementation of an object oriented API that aims to provide for more readable code. A fluent interface is normally implemented by using method chaining to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining).

下面将分4个部分来逐步说明流畅接口在构造内部DSL中的典型应用。

1. 基本语义抽象

如果要输出0..4这5个数，我们一般会首先想到类似这样的代码：

//Java
for (int i = 0; i < 5; ++i) {
    system.out.println(i);
}

…

阅读全文 Read More

(19 人打了分，平均分： 2.74 )

多些时间能少写些代码

2011年10月25日陈皓评论 118 条评论 90,865 人阅读

我在我的微博上说过这样一段话，我想在这里把我的这个观点阐述地更完整一些。

@左耳朵耗子：聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。而傻逼的老板，苦逼的程序员会拿出来100%-150%的时间来忙着赶进度，返工，重构，fix 大量的bug… 所以，越差的团队一般会越忙，而且还忙不完。

在现在这个浮躁的时期，再加上敏捷咨询师们念的歪经，他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的，这令那些管理者们很兴奋，就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。

软件开发真是这样的吗？难道不需要花时间去思考吗？对此，有些观点在Todd的《“品质在于构建过程”吗？》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点：

软件的精髓在于设计，设计是一件很费大脑的事件。对于软件来说，设计没有完美的，它总是一件需要取舍需要权衡的事，比如：时间换空间，空间换时间，TCP或UDP，同步还是异步，数据冗余还不冗余等等。那怕是一个小小的observers模式是pull方式还是push方式都需要仔细讨论。这些的东西需要时间和做前期尝试。

TDD、快速原型和迭代可能会对软件和团队产生负面影响。在一开始，你需要花很大的精力来让你的软件从无到有（做过软件的人都知道，从零开始写代码是很痛苦的事），但是因为你没有想好，先做再说，所以，后期你会面临更多的质量问题而让你需要花更多的时间精力。当然，那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你，这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求，其不会关注非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。而这些问题往往都可以让你的软件设计重新来过。

重构是恶梦，重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情（参看《重构代码的7个阶段》）。如果一开始没有想好，你要面临的不单单是re-design, re-architect，还要面对时间和人力成本的增加，最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。

…

阅读全文 Read More

(28 人打了分，平均分： 3.82 )

Stay Hungry, Stay Foolish ！！

2011年10月20日陈皓评论 177 条评论 99,737 人阅读

在整个社会都在关注乔帮主的时候，我想在这里和大家分享一个真实的就在我们程序员身边的故事。和我在《如果你看不见你还能编吗？》一文里介绍的那些盲人程序员一样，同样是Stay Hungry， Stay Foolish。但我个人更认为我今天想要给大家讲述的这个故事对于我们这些普通人更有意义一些。我真心的希望大家认真看完这个“从刷厕所到程序员”故事后，我们能从中感悟到点什么。

因为朋友的原因，我和一个创业团队经常有些往来，通过这个团队，我认识了这个故事的主人翁——王平（@wpingsuper）。其实，很早前他在Google Reader和Buzz里follow了我，但我从没和他交流过。而他的经历我却是在上周末去看望这个创业团队的时候才听说。我问他们要了王平的电话，联系了王平，详细地了解了王平的经历，并征得他的同意，在这里给大家分享他的故事。

王平是一个贵州人，03年大学毕业，体育专业，没有任何家庭背景，只能在贵州的山区里的一个中学里当体育老师，月薪150元。可能和大多数心怀梦想的年轻人一样，他并不甘心，从03年到05年间，他有好多次到北京，他觉得在大城市里有他的梦想。于是，他在04年底，05年初，他正式来到了北京，因为大学专业的问题，他无法找像大学生一样找到不错的工作，那时的他只能在北京一家很小的餐馆当清洁工，他在餐馆里洗盘子，扫地，刷厕所，一个月400元钱。

因为他的学历是这个小餐馆里学历最高的，所以，餐馆里出了什么事都会让他对去搞，所以，财务使用的电脑有了故障也让他去修，当时的他根本对电脑完全不知道是怎么一回事，但是自从接触了电脑以后他就迷上了电脑。他和我说，他这个人就是好奇心强，好动，什么都想弄一弄，所以，时间长了，弄得多了，也能为餐饮解决一些没有懂的问题，维护财务电脑就是其中之一。日子一长，虽然还是刷厕所，但是薪水也涨到了800元一个月，就连餐馆的大厨也对他说，他不属于这里，他将来一定会有前途的。当时的他还觉得不可能，笑了笑就过了。

…

阅读全文 Read More

(80 人打了分，平均分： 4.73 )

Test-Driven Development？别逗了

2011年10月17日陈皓评论 52 条评论 28,238 人阅读

这篇文章来源于Peter Sergeant在Write More Test 博客上的《Test-Driven Development? Give me a break…》，在原文和Reddit 上有很大反响。这篇文章里的很多观点在《TDD并不是看上去的那么美》和《再谈敏捷和TW咨询师》里都出现过（我个人觉得我的观点比其更全面一些）。就像我转的《Scrum为什么不行》和《Bob大叔和Jim Coplien对TDD的论战》一样，从这些贴子我们可以看到——这是一个全世界的问题，并不是只有在中国才有的问题。

很多敏粉都在说我在是喷敏捷，黑敏捷，向敏捷泼脏水，我只想对这些人说——你们这样的见解很肤浅也很敏感，你们根本就没有认识到——争论，反思和不同观点的意义，你也就无法了解你们所信仰的敏捷！你们只是在肤浅和盲目地信仰和教条敏捷中的许多名词、方法和标准答案罢了。

——————————————正文开始——————————————

对于程序员来说有些事有非常危险的信号（red flag）。当我听到有人开始信仰Test-Driven Development 是 One True Programming Methodology（唯一正确的编程方法论），这就是危险信号（red flag），我开始假设你是一个劣等、没有经验的程序员，或是某些敏捷咨询师。

测试只是一个工具来帮助你，而不是用来证明谁比谁更虔诚，或是我的屌比你的要大，等这种愚蠢的行为。测试是用来让程序员得到有帮助的、更快的反馈，从而找到正确的路径，如果你搞坏一些事，其还可以用来给后人一些警告。这根本就不是一个神秘的有魔力的方法其可以让你的代码变得更好……

整个Test-Driven Development的概念是麻痹和信奉，从而让其成为你的人生观。相反的：Developer-Driven Testing，它给你和你的同事一些有用的工具来解决问题，来支持你自己，而不是那种以工具或方法为中心的让你假设其应该是那样的测试。

…

阅读全文 Read More

(16 人打了分，平均分： 3.25 )

“品质在于构建过程”吗？

2011年10月16日 Todd 评论 66 条评论 23,992 人阅读

感谢@weidagang （Todd）向酷壳投递的这篇精彩的文章。原文

今天在微博上看到几位敏捷爱好者探讨敏捷测试和质量保证问题，我忍不住也加入了讨论：

Z先生原帖：我刚才看到一个大会演讲稿，谈到敏捷测试六大指导原则：1.仅靠测试人员不可能获得高质量的软件，质量是整个研发团队的责任；2. 场景是不可穷举的，测试活动必须是风险驱动的，关注于高风险的场景；3.分层自动化测试是唯一出路;4.在正确的位置进行恰当的测试是自动化的关键；【待续】

S先生回复：品质在于构建过程。检验贯穿构建过程，提供及时反馈。

我回复：什么样的构建过程才能出Unix这样的品质呢？迭代？快速反馈？TDD?

S先生回复：据说stroustrup听到重构时的反应是，我们从七十年代就这样做了。推荐《UNIX编程环境》，了解大师的编程方式。

我回复：您偷换了概念。不能说大师用了重构，C++和UNIX的品质就是靠重构或某种构建过程得来的。厨师做菜用到了勺子，不等于菜好吃是因为勺子。

S先生回复：我没有概念。我们看到一个果，就问因是什么。其实是泛因果，无因果，一切是机缘凑巧。

我回复：“品质在于构建过程”难道不是一个明白的因果描述吗？

S先生回复：品质在于构建的人。我说话时没因果，你看到了因果。

我回复：欢迎敏捷爱好者围观！

很高兴几个回合讨论下来S先生修正了先前“品质在于构建过程”的观点。什么重构、TDD、迭代、快速反馈等等构建过程都不是Unix品质的核心要素。我不但不认同“品质在于构建过程”、“测试是最好的设计方法”这类机械式的观点，而且也不满意把软件优劣归结于“人是根本”的简单回答。我们需要探索一个既非机械式，也非简单地归结为某种理念的答案。

…

阅读全文 Read More

(29 人打了分，平均分： 4.00 )

那些曾伴我走过编程之路的软件

2011年10月14日陈皓评论 157 条评论 79,137 人阅读

收家的时候发现了一张VC++6.0的光盘，实然引发了我的怀旧情结。于是在微博上感叹了一下，看到一些朋友的回应，还有朋友提到了Turbo C 2.0，于是更回放大了我的怀旧情绪，让我回想了很多N年前伴我走过编程之路的软件。现在看下来，有些感叹，又有些可笑。感叹的是技术发展的变迁，可笑的是当时的一些想法。（Unix/Linux是在大四和毕业的时候接触的，虽然这是我的强项，但是这下面的编程这么多年来没什么变化，所以就不提了）注：图片较多，请稍等。

还记得第一次接触编程是在高中的时候，用中华学习机学Basic程序，后来到了大学，虽然学校的课程没有教Basic语言，但是DOS下有一个叫Quick Baisc的东西让我把高中时的知识又捡了回了。

大学里学的第一门语言是Pascal，所以，用的编程软件也就是Turbo Pascal，还记编译起来巨快无比，尤其是那个只有软盘和640K的基本内存的时代。

…

阅读全文 Read More

(34 人打了分，平均分： 4.53 )

如果你看不见你还能编程吗？

2011年09月21日陈皓评论 115 条评论 50,771 人阅读

这是个StackOverflow上的问题 How can you program if you’re blind? 。在看到这个问题的时候，我感到应该不可能，但是我错了，这个问题的前两个答案让我深深地震憾了。

第一个答案的回复人是Jared（其在StackOverflow上的积分有将近14K），但是你能想得到他是一个盲人吗？他回复到——

我是一个完全失明的大学学生，我做过一些程序员的实习工作，所以我的回复基于我的这些经历。我使用Windows XP 和 Jaws 来为了读出屏幕上的内容。

对于Java 编程，我使用eclipse这个强大的IDE。我使用SWT开发GUI。对于.NET编程，其使用Visual Studio 2005，使用Jaws可以非常容易地操作VS2005，而且其还有一些很不错的脚本来可容易地用来做表单设计。

对于C/C++，我使用cygwin + gcc 也使用emacs 和 vim 做出编辑器（使用Emacspeak虽然有时候有点迟钝）。在实习过程中，我做了很多和Z/OS相关的编程工作。我使用rlogin通过cygwin登录大型机的USS系统，并使用C3270作为其3270仿真器来访问大型机的ISPF部分。

我依赖于合成语音系统，也需要 Braille display，我发现使用合成语音系统很快，但是使用 Braille display有时候有些问题。比如程序有太多的嵌套括号。

关于Braille display，又叫盲文显示机，是能以盲文进行输出的电子机械式设备。一般来说，该设备通过在平坦表面上打孔来实现点阵的表现。有了该设备的帮助，无法使用一般的显示设备的失明用户也能够阅读文字。如下所示。

…

阅读全文 Read More

(62 人打了分，平均分： 4.71 )

一些文章和各种资源

2011年09月20日陈皓评论 43 条评论 52,534 人阅读

下面是近期收录的一些文章和资源，希望对你有用。

系统方面

印度的电子商务网站flipkart的性能扩展（PPT） http://www.slideshare.net/sids/how-flipkart-scales-php，都是一些最基本的东西，对于初学者来说很不错。PPT做的也不错。

Tagged.com的扩展之路 – 1亿用户，1000台服务器，50亿的PV http://highscalability.com/blog/2011/8/8/tagged-architecture-scaling-to-100-million-users-1000-server.html 还是PHP的WEB站点。另外，highscalability.com这个网站上有很多和高性能有关的文章，很不错。比如最新的：Stuff The Internet Says On Scalability For September 16, 2011

浏览器是怎么工作的？ http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ 相当不错的一个教程，告诉你浏览器里面是怎么搞的，很不错。如果图片看不到，可以看这里。如果你英文不是太好，你可以看看中译版，译得并不是太好。

Mozilla's Gecko rendering engine main flow

怎么使用epoll的示例 https://banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c/

Intel C/C++ 64位程序开发教程 http://software.intel.com/en-us/articles/lessons-on-development-of-64-bit-cc-applications/ 本站以前也介绍过一个关于64位C/C++的编程注意事项。

…

阅读全文 Read More

(22 人打了分，平均分： 4.27 )