酷壳(coolshell.cn)镜像站

2011年12月21日晚，某计算机专业的大学生寝室，某同学大叫到：“兄弟们，最新的日本XX女星的AV片已经下好，大家快过来看啊，相当精彩啊~~~”，然而，这个寝室里的其它同学似乎没有听到这哥们的呼喊，于是，这哥们又叫了三次，没有人理他，因为大家都在眉飞色舞地谈论着CSDN的明文密码和用户帐号泄露的事情，并在网上查找着下载CSDN那600万的用户数据……上面这个故事是我编的，只是想描述一下昨晚的情形。 其实，CSDN明文密码并不是什么稀奇的事情，我是2000年注册CSDN的吧，当时找回口令的机制就是把口令直接传回来了，这一定是明文了。去年去CSDN参加移动互联网沙龙的时候，范凯和蒋涛说过明文密码的事，不过他们说的是很早以前的事了，而且一笔带过了。1年后的今天，事情又暴了，可见，“出来混的，迟早是要还的”这句话是几近真理的。 我在以前的BLOG里就提到过CSDN的明文密码（在“如何设计用户登录功能”一文）和 帐号泄露（“如何设计自己的口令”） 的事（由此可见，酷壳里的很多文章里的事都应验了，因为我知道“出来混的，迟早是要还的”） （可悲吧？还是程序员的网站呢，明文口令和用户信息泄露有悖于 ...

在StackExchange上有人问了这样一个问题：What should every programmer know about web development?（关于Web开发，什么是所有程序员需要知道的？）里面给出的答案非常不错，所以，我翻译转载过来。 顺便说一下，StackExchange真是非常好，大家可以对同一个答案做贡献和修订，看看这个问题的修订过程你就知道了——专业的问答网站应该怎么去做。这就是我在这篇文章中也说过真正的用户体验是什么样的。 好了，下面是正文（我对原文做了一些批注，也许不对或有误导，请大家指正） 下面的这些东西可能对于大多数人并不陌生，但是可能会有些东西你以前并没有看过，或是没有完全搞懂，甚至都没有听说过。（陈皓注：我相信当你看完这个列表后，你会觉得对于我国的Web开发有点弱了，还是那句话，表面上的东西永远是肤浅的） 目录 接口和用户体验 安全 性能 SEO (搜索引擎优化) 技术 Bug fixing 接口和用户体验 小心浏览器的实现标准上的不一致，确信让你的网站能 ...

Keith Schwarz是一个斯坦福大学计算机科学系的讲师。他对编程充满了热情。他的主页上他自己正在实现各种各样的有意思的算法和数据结构，http://www.keithschwarz.com/interesting/， 目前这个网页上有88个（见下面的列表），但这位大哥要干135个，你可以看看他的To-Do List。 从这个列表上，我们可以看到，他从去年7月份就在自己实现这些东西了，我把他实现的这些算法转过来， 一方面我们可以学习一下这些算法和代码，因为很多东西对我来说都比较新，我以前列举过一些经典的算法，算法和数据结构词典，还有可视化的数据结构和算法， 不过感觉都没有这个全。 另一方面我希望这个事可以影响到一些正在学习编程的人。看看别人是怎么学习编程的，希望对你有借鉴作用。 Name Link Date Added Language Description Binomial Heap (link) 7‑24‑2010 C++ An implem ...

因为《腾讯帐号申诉的用户体验》一文中好多人觉得腾讯申诉是世界级先进的，并让我拿出一个找回用户的帐号的功能来。本来不想写的，因为大家看看其它系统的就行的，但是，很明显有些人就是很懒，也不会思考，而且不会观察，所以，我就只好写下这篇科普性常识性的文章。 在行文之前，我得先感谢腾讯公司的至少30名员工在《腾讯帐号申诉的用户体验》一文后的回帖（我STFG（Search The Fucking Google）看到了你们使用的那个固定IP在各个大学论坛上的腾讯的招聘广告），我感谢你们主要有两点： 你们有半数以上的人留下的是gmail而不是QQMail/Foxmail的电子邮件，这点让我感到很欣慰。 你们在加班到晚上11点的时候都能在本站回复，的确如你们的Andy Pan所说，你们的核心竞争力很强，包括水军方面。 好了，让我正式谈谈这个设计。找回用户帐号通常就用三个事就可以了：邮箱，安全问答，手机。 邮箱，安全问答，手机 大多数的系统都会使用邮箱和安全问答，这足够了，很多系统直接用邮箱做帐号名（Apple ID，Facebook，新浪微博 ….），这样一来，就算你的系统口令被盗，帐号的是改 ...

前面写过一篇“腾讯，竞争力 和 用户体验”批评了腾讯，于是在我的微博上和博客上收到了一些反对意见，基本上是说腾讯产品的用户体验做得很好，很方便，等等，还列举了N多的例子，以及说过什么用户数量为王的言论，让我感到我应该写一篇博客。当然，如果我们只看某个技术层面的东西的话，我同意，QQ的一些产品还是很易用的。但是我们还是要看得更深一些。Effective C++的作者Scott Meyers 在《More Effective C++》中说过——“美丽的是肤浅的表现”。   我借用一下这句话，认为QQ是好的产品的观点是肤浅的认识。 网上有大量的文章说QQ扫描硬盘啊，说QQ收集用户信息啊，你可能忘了这些。前段时间的3Q大战的那个“艰难的决定”，你好像也忘了。还有狗日的腾讯，你也忘了。包括QQ可以预防犯罪的新闻，你可能也忘（这本就是一个容易忘事的民族）。你已经被QQ的用户体验迷住你的双眼，觉得QQ无敌于天下，就像这个微博 以及微博里的回复一样在赞叹QQ注重细节一样，那些人在看到QQ的Mac版上向Steve Jobs感谢的字样激动不已。我感到你被 ...

自从那篇rant了一堆公司都的文章发布来，得到了大家的关注，有些朋友让我写一下腾讯，在我的微博上（@左耳朵耗子）还有位腾讯的朋友让我也评价一下腾讯。本来不想写的，觉得腾讯没啥好说的，但是因为下面的几个原因，让我有点坐不住了： 这两天知乎上的一个“腾讯的核心竞争力”的贴子在微博上被很多人所推崇。 还有一个网友发邮件给我说让我别rant了，宁可C2C也比rant有意义。 我周末的时候去豆瓣和他们交流了一些关于产品和用户体验方面的话题。 还看到了Jeff Bezos的访谈文章《贝佐斯：亚马逊是科技界唯一一家低利润公司》 于是就有了这篇文章，但不想再rant了，我希望这篇文章更有价值一些，但是我喜欢的调侃的风格依然，因为这是我觉得能让文章有趣味的方式。 目录 腾讯的“价值” “腾讯的核心竞争力”一文 腾讯的软肋 真正的用户体验 腾讯的“价值” 首先我想说说腾讯的价值。根据我那篇 rant 的文章来说，我觉得人要活得有价值，事业也要做得有价值。我不太待见那些没有价值的东西。所以，我在那篇文章里让大家都思考了一个问题，我们做 ...

上一篇博文翻译了Steve Yegge的rant，这两天有一些事让我也想rant一下（所谓rant就是一篇巨长无比的抱怨和说教），不过无论是从见解还是恶搞来说肯定没有SteveY的水平高，所以，这篇博文只是单纯的rant，看标题就知道了，就像“篱笆，女人和狗”一样，乡土味实足。所以，下述的一些观点未必正确，也未必靠谱，也就是我的个人唠叨罢了，我想到哪里说到哪里。（篇幅较长，见谅） 目录 引子 邮件回复 创业 和 事业 移动互联网 结尾 引子 我前两天，收到一封邮件，一位快要毕业的的大学生问我，是去百度，还是去创新工场？他在来信中说，从个人道德价值观来说，他想去创新工场，要远离流氓企业，不然会有狼狈为奸、助纣为虐的感觉，对不起自己。但是创新工场那边情况不熟悉， 不知道怎么选择，并问我现在比较热的移动互联网靠不靠谱。 正好这两天我在微博里看到大家转贴李开复的几个让毕业生创业的微博，比如，这个微博，还有 这个微博。呵呵。 李开复：有关毕业生高科技创业,我的建议：1）创业需要理解趋势、汇集精英、实践经验,因此大学 ...

某人发了一篇Don’t use MongoDB的血泪控诉，我把原文翻译如下，你可以看看。不过，我想我们还要去看看10gen CTO的对此事的回复，我们还要去在Reddit上看看大家的说法，10gen CTO的对此事的回复后面也有一堆人在讨论这个事，还有一些程序员开始去读MongoDB的源码了，呵呵。看样子，说MongoDB的这些事并不是真的。 10gen CTO 对此事的并不完全知道，其在回复，对些文中的每一条都做了回复。我把其回复的大体意思也放在原文中。不过，很有意思的是那些程序员的讨论。建议大家看看。 正文 因为各种政治原因，我这段时间没有说什么，但是现在我觉得因为要对社会负责，所以我要阻止大家不要把你们的业务放在MongoDB上。 我的团队在一个有巨大用户量（一个有千万用户级的大型的公司）系统上使用的MongoDB，这个系统上让MongoDB有非常大的负载。早期，我们以为使用MongoDB会像10gen公司（MongoDB背后的公司）宣扬其在长期性能扩展有很多好处。但是，我们错了，而这个rant(长篇抱怨)就是为了让你不要相信那些所谓的成功经验而和我们一样犯了大错。如 ...

Steve Yegge， Amazon的前员工，现任Google员工，其本来想在Google+上和Google的员工讨论一些关于平台的东西，结果不小心把圈子设成了Public，结果这篇文章就公开给了全世界，引起了剧烈的反应。发布后很快他就马上把这篇文章删了，不过，互联网上早备份了下来——SteveY’s Google Platforms Rant。后来，Steve在其Google+上作了一些解释，大体是说他喝多了，而且又是在凌晨，所以大脑不清，文章中的观点很主观，极端且不完整，还有Google的PR对他很好，等等，等等 。 几个星期前看到时就一直都想翻译一下这篇文章，不过因为最近事情太多，文章又很长，所以现在才翻译完成，翻译的不好，还请大家指正。 导读 在你阅读正文以前，我想说明几点，希望你注意一下： Steve这个人非常喜欢写长篇大论的东西。而且比较喜欢辛辣调侃和恶搞的文风，这点大家要注意！ 文中先“骂”Amazon公司，再通过“骂”Amazon的创始人贝索斯Bezos并烘托出他的的悟性和雄心，最后教育了一下Google。 我把文章分成了三个部分，这样方便大家阅读和 ...

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文件，链接时 ...

感谢@weidagang （Todd）向酷壳投递本文。 程序设计语言的抽象机制包含了两个最基本的方面：一是语言关注的基本元素/语义；另一个是从基本元素/语义到复合元素/语义的构造规则。在C、C++、Java、C#、Python等通用语言中，语言的基本元素/语义往往离问题域较远，通过API库的形式进行层层抽象是降低问题难度最常用的方法。比如，在C语言中最常见的方式是提供函数库来封装复杂逻辑，方便外部调用。 不过普通的API设计方法存在一种天然的陷阱，那就是不管怎样封装，大过程虽然比小过程抽象层次更高，但本质上还是过程，受到过程语义的制约。也就是说，通过基本元素/语义构造更高级抽象元素/语义的时候，语言的构造规则很大程度上限制了抽象的维度，我们很难跳出这个维度去，甚至可能根本意识不到这个限制。而SQL、HTML、CSS、make等DSL（领域特定语言）的抽象维度是为特定领域量身定做的，从这些抽象角度看问题往往最为简单，所以DSL在解决其特定领域的问题时比通用程序设计语言更加方便。通常，SQL等非通用语言被称为外部DSL（External DSL）；在通用语言中，我们其实也可以在 ...

我在我的微博上说过这样一段话，我想在这里把我的这个观点阐述地更完整一些。 @左耳朵耗子：聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。而傻逼的老板，苦逼的程序员会拿出来100%-150%的时间来忙着赶进度，返工，重构，fix 大量的bug… 所以， 越差的团队一般会越忙，而且还忙不完。 在现在这个浮躁的时期，再加上敏捷咨询师们念的歪经，他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的，这令那些管理者们很兴奋，就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。 软件开发真是这样的吗？难道不需要花时间去思考吗？对此，有些观点在Todd的《“品质在于构建过程”吗？》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点： 软件的精髓在于设计，设计是一件很费大脑的事件。对于软件来说，设计没有完美的，它总是一件需要取舍需要权衡的事，比如：时 ...

这篇文章来源于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 ...

感谢@weidagang （Todd）向酷壳投递的这篇精彩的文章。原文 今天在微博上看到几位敏捷爱好者探讨敏捷测试和质量保证问题，我忍不住也加入了讨论： Z先生原帖：我刚才看到一个大会演讲稿，谈到敏捷测试六大指导原则：1.仅靠测试人员不可能获得高质量的软件，质量是整个研发团队的责任；2. 场景是不可穷举的，测试活动必须是风险驱动的，关注于高风险的场景；3.分层自动化测试是唯一出路;4.在正确的位置进行恰当的测试是自动化的关键；【待续】 S先生回复：品质在于构建过程。检验贯穿构建过程，提供及时反馈。 我回复：什么样的构建过程才能出Unix这样的品质呢？迭代？快速反馈？TDD? S先生回复：据说stroustrup听到重构时的反应是，我们从七十年代就这样做了。推荐《UNIX编程环境》，了解大师的编程方式。 我回复：您偷换了概念。不能说大师用了重构，C++和UNIX的品质就是靠重构或某种构建过程得来的。厨师做菜用到了勺子，不等于菜好吃是因为勺子。 S先生回复：我没有概念。我们看到一个果，就问因是什么。其实是泛因果，无因果，一切是机缘凑巧。 我回复：“品质在于构建过程”难道不 ...