| Refresh | This website coolshell.cn/page/30 is currently offline. Cloudflare's Always Online™ shows a snapshot of this web page from the Internet Archive's Wayback Machine. To check for the live version, click Refresh. |
微软的IE的Blog发布了这样一篇文章，以此来展示IE9是如何过滤广告和ActiveX控件的功能。其使用了“新浪”来做为反面案例，新浪并不是第一次成为反面案例了，之前就有人用新浪等网站来表明中国的网站的设计是怎么个烂法。呵呵。伟大的新浪。
下面是新浪的在IE9下没有开启过滤的样子，我们要吧看到满天飞的flash，广告，还有视频……
下面是开启了过滤功能后的新浪网页（个人感觉还是那么乱，没办法底子太差了）
(13 人打了分，平均分： 3.77 )
Loading...C2C不是电了商务里的C2C，而是Copy to China的缩写，以前，我们以Made in China著称，现在我们会以C2C著称。toxicat制作了下面这个图片(源图)，大家慢慢欣赏，我相信，如果要把所有的C2C都列上去的话，那么，可能会上很长的一个图片。还记得那篇为什么中国的网页设计那么烂？吗？呵呵。何止是互联网，其它东西不也是C2C吗？
(19 人打了分，平均分： 4.11 )Loading...在网上看到一张口令破解的表格，如下所示（第一列是口令长度，第二列是全小写的口令，第三列是有大写字母的口令，第四列是又加上了数字和其它字符的口令）
如果你想知道自己的口令花多少时间可以被破确，你可以访问下面这个网站：（更新2011/3/2晚10点15）
http://howsecureismypassword.net/
这里先说一个这里说的口令破解。一般来说用户的口令都是以MD5编码加密放在数据库里的，MD5是不可逆的，所以，当你拿到你一串被MD5后的字串，你可以使用暴力破解——穷举所有的可能口令的MD5字串，然后和数据库里的对比，比对了你就知道口令了。当然，你一定要清楚，在某些审查很严重的地方，互联网内容提供商不一定会把你的口令以MD5加密，甚至就是明文（Plain Text）保存，所以你还需要小心，关于如何设计你的口令，请参看这篇文章。
从上面这表格我们可以看到，你的口令最好是在8个长度以上，而且一定要有在小写和数字，最好再加上其它字符，这样你的口令被破解的时候最需要463年，这样就比较安全了。当然，如果你的口令使用了一些常用的单词，那就另说了，现在破解口令一般都不会使用暴力破解，都是用一个尝用口令字典表来尝试——比如这篇文章所说的字典表。
但我提醒一下，这张表里中的时间忽略了一个问题，那就是并行，可以使用多台电脑多个进程并行破解口令，这样一来，上表中的时间就可大打折扣了。你只需要愿意花2000美刀，你就能够找到一个地方，1秒种计算7亿个口令，因为MD5，SHA这类的算法性能太好了。所以，你可能需要使用新的算法来加密你的口令，这种算法最好加上时间，也就是在算法的计算时间加长。呵呵，慢也有慢的好处。可能你需要考虑一下bcrypt算法，你可以查看本站的这篇文章。
(13 人打了分，平均分： 3.23 )Loading...六、七年前写过一篇《跟我一起写Makefile》，直到今天，还有一些朋友问我一些Makefile的问题，老实说，我有一段时间没有用Makefile了，生疏了。回顾，这几年来大家问题我的问题，其实很多时候是makefile的调试问题。所以，就像我在之前的那篇关于GDB的技巧的文章中做的一样，在这里向大家介绍一个小小的调试变量的技巧。相信一定对你有用。
对于Makefile中的各种变量，可能是我们比较头痛的事了。我们要查看他们并不是很方便，需要修改makefile加入echo命令。这有时候很不方便。其实我们可以制作下面一个专门用来输出变量的makefile（假设名字叫：vars.mk）
%:
@echo '$*=$($*)'
d-%:
@echo '$*=$($*)'
@echo ' origin = $(origin $*)'
@echo ' value = $(value $*)'
@echo ' flavor = $(flavor $*)'
这样一来，我们可以使用make命令的-f参数来查看makefile中的相关变量（包括make的内建变量，比如：COMPILE.c或MAKE_VERSION之类的）。注意：第二个以“d-”为前缀的目标可以用来打印关于这个变量更为详细的东西（后面有详细说明）
…
(20 人打了分，平均分： 3.90 )Loading...打印质数的算法应该是学习计算机编程的一个经典的问题，在这里想给大家展示一些方法，相信这些方法会对你的编程有一定的启发作用。请你注意几点，
首先，先给一个教科书的示例。下面这个示例应该是教科书（至少是我上大学时的教科学）中算法复杂度最好的例子了。其想法很简单，先写一个判断是否是质数的函数isPrime()，然后从1到n分别调用isPrime()函数来检查。检查是否是质数的算法是核心，其简单的使用从2到n的开根的数作为除数。这样的算法复杂度几乎是O(n*log(n))，看上去不错，但其实很不经济。
#include <iostream>
using namespace std;
bool isPrime(int nr)
{
for (int d = 2; (d * d) < (nr + 1); ++d){
if (!(nr % d)){
return false;
}
}
return true;
}
int main (int argc, char * const argv[])
{
for (int i = 0; i < 50; ++i){
if (isPrime(i)){
cout << i << endl;
}
}
}
(14 人打了分，平均分： 3.14 )Loading...以前本站推荐过麻省理工的C/C++的课程，今天在他们的网站看到上有一组关于计算机科学和编程导论的免费公开课（视频是Youtube的），我看了几个课程，我觉得讲得很系统啊，而且有一点一通百通的感觉。虽然是理论课，但是可以感到我国的教育还是有很大差距的。这个组课程推荐给大家（需要翻墙），视频都有字幕，计算机科学系毕业的同学应该会很容易听懂。强烈推荐。（网友Aslan指出已经有人搬运到优酷上了，链接在这里，遗憾的是没有字幕，另外，不知道为什么会说是Python学习）
 |
1: Introduction and Goals; Data Types, Operators, and Variables |
 |
2: Branching, Conditionals, and Iteration |
 |
3: Common Code Patterns: Iterative Programs |
(16 人打了分，平均分： 3.50 )Loading...本文来自Terazen Technology Inc的创始人+CTO的 David Ing的《Agile Plumbers》（这也墙？），我的其文中的这个帮事翻译过来（和前些天发的SOAP的S是Simple异曲同工）。
也许你会觉得这个比喻不恰当。但我想告诉你的是，这个故事告诉我们，教条主义和以方法论为中心的危险。十条不错的编程观点中第一条—— The only “best practice” you should be using all the time is “Use Your Brain”.
————————————————————
(门铃响……)
事主：啊, Agile 水管工吗？ 请进，感谢谢你们这么快就来了——这的确很紧急，我这真是很乱。
水管工1: 先生，没问题，我们就是敏捷的。在我给你做Presentation前，我先给你介绍一下我的两个同事。
事主：Presentation？啊，我们有时间吗？这的水已经流得到处都是了……
水管工1：……先生，我们必需坚持这个。我们只是想保证你能成为动态搜寻解决方法的一份子。你是我们的 champion sponsor，也就是我们团队内的 consultant！你可以提供一个白板给我们使用吗？
事主：我没听懂，你们不觉得这变复杂了吗？我觉得我应该告诉你们这水是从房子哪儿流出来的，就是那……
水管工2：你这有让我脱衣服的地儿吗？
事主：什么？
(19 人打了分，平均分： 3.53 )Loading...之所以用了“再”，是因为之前的两篇文章——
当然，这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰者们的很多回复，我也有开始沉不住气回复了很多，当然，有一半以上的不是学术上的讨论，而是对我个人的攻击。甚至，在这两篇文章发布后，酷壳（CoolShell.cn）受到持续性的黑客攻击。
本来已经过去的事，今天却又发现这两篇文章的访问量和评论又上来了，才发现原来是InfoQ的这篇文章——《虚拟座谈会：TDD有多美？》，加上很多我在评论中的观点，以及ThoughtWorks和InfoQ之前给我的来信中谈到的一些观点。我很不自然地想把我的一些观点总结并罗列在这里。主要分成四块—— 1）我对整个事情的基本观点，2）对于方法论的观点，3）对于TW中国咨询师的观点，4）还有和TW和InfoQ住来信件中的观点。
————————————————
首先，我想说明一下我的基本观点。
(51 人打了分，平均分： 4.47 )Loading...
下面的文章转自Todd Wei 的《TDD到底美还是不美？》，对于这篇文章，我个人能过透过作者的观点感受到他的项目中使用TDD的难点，同样可以感受到作者内心的纠结。不管怎么样，我能够感到作者Todd Wei在独立思考，独立思考总是好的，因为那是走向成熟的必要条件。(另，大家可以移步过去看看相关的评论，挺有意思的)
————————————————————————————————————
最近CoolShell上的一篇《TDD并不是看上去的那么美》引起了敏捷社区的高度关注和激励辩论。今天，InfoQ甚至专门举行了一个“虚拟座谈会”《TDD有多美？》，几位国内敏捷社区的名人专门就此问题展开了深入地讨论。不论结果如何，这个纯技术的探讨精神还是非常值得赞赏的。事件实际上可以简单地归纳为“一个有一定影响力的开发人员质疑TDD，一群敏捷社区名人对TDD进行解释和辩护”。现在，就让我坚定地站在CoolShell一边，为对TDD的质疑和批判添砖加瓦吧！
TDD的核心理念是什么呢？第一是Specification by Example，即把测试用例作为表达需求的一种方式。传统的需求表达方式包括文档，Use Case等，而TDD强调通过测试用例来表达需求。另外，TDD的测试用例是黑盒的基于外部接口的，所以，它实际上又是对外部接口的设计。如何看待测试用例是TDD与传统测试的一个重要区别。“不把测试用例单纯地视为测试，而从需求和设计的角度来看测试用例”的理念本身是好的。另外，TDD的第二个理念是Test First，强调测试对于实现的驱动作用，先写测试用例，再实现和重构。在Specification by Example的理念下，Test First的实质是“先理解清楚需求，并做好外部接口设计，把它转化为测试用例，然后再来实现和重构”。
我认为，Specification by Example是不错的，因为测试用例作具有精确性，容易自动化的优点，这是传统的文档和Use Case在表达需求时所欠缺的地方。但Test First理念本身则有很大的问题，尤其“在没有测试用例失败之前，不要写任何一行代码”的极端方式则更是极端的错误。
…
(16 人打了分，平均分： 3.44 )Loading...近日，Stack Exchange系统管理员blog上发布了一篇关于Stack Exchange的架构一瞥，其包括了Stack Overflow, Server Fault 和 Super User的 Stack Exchange 网络。注意最后一个关于人员的配置。希望能给大家一些相关的参考。
(7 人打了分，平均分： 2.71 )Loading...