微软用新浪来当反面教材
微软的 IE的Blog 发布了这样 一篇文章 ,以此来展示IE9是如何过滤广告和ActiveX控件的功能。其使用了“新浪”来做为反面案例,新浪并不是第一次成为反面案例了,之前就有人用新浪等网站来表明 中国的网站的设计是怎么个烂法 。呵呵。伟大的新浪。
下面是新浪的在IE9下没有开启过滤的样子,我们要吧看到满天飞的flash,广告,还有视频……
下面是开启了过滤功能后的新浪网页(个人感觉还是那么乱,没办法底子太差了)
微软的 IE的Blog 发布了这样 一篇文章 ,以此来展示IE9是如何过滤广告和ActiveX控件的功能。其使用了“新浪”来做为反面案例,新浪并不是第一次成为反面案例了,之前就有人用新浪等网站来表明 中国的网站的设计是怎么个烂法 。呵呵。伟大的新浪。
下面是新浪的在IE9下没有开启过滤的样子,我们要吧看到满天飞的flash,广告,还有视频……
下面是开启了过滤功能后的新浪网页(个人感觉还是那么乱,没办法底子太差了)
C2C不是电了商务里的C2C,而是Copy to China的缩写,以前,我们以Made in China著称,现在我们会以C2C著称。toxicat制作了下面这个图片( 源图 ),大家慢慢欣赏,我相信,如果要把所有的C2C都列上去的话,那么,可能会上很长的一个图片。还记得那篇 为什么中国的网页设计那么烂? 吗?呵呵。何止是互联网,其它东西不也是C2C吗?
在网上看到一张口令破解的表格,如下所示(第一列是口令长度,第二列是全小写的口令,第三列是有大写字母的口令,第四列是又加上了数字和其它字符的口令)
如果你想知道自己的口令花多少时间可以被破确,你可以访问下面这个网站:( 更新2011/3/2晚10点15 )
http://howsecureismypassword.net/
这里先说一个这里说的口令破解。一般来说用户的口令都是以MD5编码加密放在数据库里的,MD5是不可逆的,所以,当你拿到你一串被MD5后的字串,你可以使用暴力破解——穷举所有的可能口令的MD5字串,然后和数据库里的对比,比对了你就知道口令了。当然,你一定要清楚,在某些审查很严重的地方,互联网内容提供商不一定会把你的口令以MD5加密,甚至就是明文(Plain Text)保存,所以你还需要小心,关于如何设计你的口令, 请参看这篇文章 。
从上面这表格我们可以看到,你的口令最好是在8个长度以上,而且一定要有在小写和数字,最好再加上其它字符,这样你的口令被破解的时候最需要463年,这样就比较安全了。当然,如果你的口令使用了一些常用的单词,那就另说了,现在破解口令一般都不会使用暴力破解,都是用一个尝用口令字典表来尝试——比如 这篇文章所说的字典表 。
但我提醒一下,这张表里中的时间忽略了一个问题,那就是并行, 可以使用多台电脑多个进程并行破解口令 ,这样一来,上表中的时间就可大打折扣了。你只需要愿意花2000美刀,你就能够找到一个地方,1秒种计算7亿个口令,因为MD5,SHA这类的算法性能太好了。所以,你可能需要使用新的算法来加密你的口令,这种算法最好加上时间,也就是在算法的计算时间加长。呵呵,慢也有慢的好处。可能你需要考虑一下bcrypt算法,你 可以查看本站的这篇文章 。
六、七年前写过一篇《 跟我一起写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-”为前缀的目标可以用来打印关于这个变量更为详细的东西
(后面有详细说明)
…
打印质数的算法应该是学习计算机编程的一个经典的问题,在这里想给大家展示一些方法,相信这些方法会对你的编程有一定的启发作用。请你注意几点,
首先,先给一个教科书的示例。下面这个示例应该是教科书(至少是我上大学时的教科学)中算法复杂度最好的例子了。其想法很简单,先写一个判断是否是质数的函数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; } } }
以前本站推荐过 麻省理工的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 |
本文来自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 :你这有让我脱衣服的地儿吗?
事主 :什么?
之所以用了“再”,是因为之前的两篇文章——
当然,这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰者们的很多回复,我也有开始沉不住气回复了很多,当然,有一半以上的不是学术上的讨论,而是对我个人的攻击。甚至,在这两篇文章发布后,酷壳(CoolShell.cn)受到 持续性的黑客攻击 。
本来已经过去的事,今天却又发现这两篇文章的访问量和评论又上来了,才发现原来是InfoQ的这篇文章——《 虚拟座谈会:TDD有多美? 》,加上很多我在评论中的观点,以及ThoughtWorks和InfoQ之前给我的来信中谈到的一些观点。我很不自然地想把我的一些观点总结并罗列在这里。主要分成四块—— 1) 我对整个事情的基本观点 ,2) 对于方法论的观点,3)对于TW中国咨询师的观点 ,4) 还有和TW和InfoQ住来信件中的观点 。
————————————————
首先,我想说明一下我的基本观点。
下面的文章转自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理念本身则有很大的问题
,尤其“在没有测试用例失败之前,不要写任何一行代码”的极端方式则更是极端的错误。
…
近日,Stack Exchange系统管理员blog上发布了一篇关于 Stack Exchange的架构一瞥 ,其包括了Stack Overflow, Server Fault 和 Super User的 Stack Exchange 网络。注意最后一个关于人员的配置。希望能给大家一些相关的参考。