web analytics

存档

2011年2月 的存档

打印质数的各种算法

2011年2月28日 29 条评论 9,857 人阅读    

打印质数的算法应该是学习计算机编程的一个经典的问题,在这里想给大家展示一些方法,相信这些方法会对你的编程有一定的启发作用。请你注意几点,

  • 实际应用和教学应用有很大的差别。
  • 最后的那个使用编译时而不是运行时的方法大家可以重点看看。

教科书的示例

首先,先给一个教科书的示例。下面这个示例应该是教科书(至少是我上大学时的教科学)中算法复杂度最好的例子了。其想法很简单,先写一个判断是否是质数的函数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;
        }
    }
}

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (7 人打了分,平均分: 4.71 )
Loading ... Loading ...

(麻省理工免费课程)计算机科学和编程导论

2011年2月28日 21 条评论 30,133 人阅读    

以前本站推荐过麻省理工的C/C++的课程,今天在他们的网站看到上有一组关于计算机科学和编程导论的免费公开课(视频是Youtube的),我看了几个课程,我觉得讲得很系统啊,而且有一点一通百通的感觉。虽然是理论课,但是可以感到我国的教育还是有很大差距的。这个组课程推荐给大家(需要翻墙),视频都有字幕,计算机科学系毕业的同学应该会很容易听懂。强烈推荐。(网友Aslan指出已经有人搬运到优酷上了,链接在这里,遗憾的是没有字幕,另外,不知道为什么会说是Python学习)

 

1: Introduction and Goals; Data Types, Operators, and Variables

Youtube(英文字幕)

优酷(无字幕)

 

2: Branching, Conditionals, and Iteration

Youtube(英文字幕)

优酷(无字幕)

 

3: Common Code Patterns: Iterative Programs

Youtube(英文字幕)

优酷(无字幕)

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 5.00 )
Loading ... Loading ...

敏捷水管工

2011年2月25日 27 条评论 4,609 人阅读    

本文来自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:你这有让我脱衣服的地儿吗?

事主:什么?

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (13 人打了分,平均分: 4.69 )
Loading ... Loading ...

再谈敏捷和ThoughtWorks中国咨询师

2011年2月24日 117 条评论 24,038 人阅读    

前言说明

之所以用了“再”,是因为之前的两篇文章——

  • 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议。
  • 我在《TDD并不是看上去的那么美》一文中列举了一些在实际中使用TDD可能会出现的问题和难题,以此来告诉大家在使用TDD时需要注意的东西。就像是在《结对编程的利与弊》说的一样,只有真正知道一件事情的利弊,你才能用好它。

当然,这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰者们的很多回复,我也有开始沉不住气回复了很多,当然,有一半以上的不是学术上的讨论,而是对我个人的攻击。甚至,在这两篇文章发布后,酷壳(CoolShell.cn)受到持续性的黑客攻击

本来已经过去的事,今天却又发现这两篇文章的访问量和评论又上来了,才发现原来是InfoQ的这篇文章——《虚拟座谈会:TDD有多美?》,加上很多我在评论中的观点,以及ThoughtWorks和InfoQ之前给我的来信中谈到的一些观点。我很不自然地想把我的一些观点总结并罗列在这里。主要分成四块—— 1)我对整个事情的基本观点,2)对于方法论的观点,3)对于TW中国咨询师的观点,4)还有和TW和InfoQ住来信件中的观点

————————————————

基本观点

首先,我想说明一下我的基本观点。

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (34 人打了分,平均分: 4.82 )
Loading ... Loading ...

[转]TDD到底美还是不美?

2011年2月24日 29 条评论 4,371 人阅读    

下面的文章转自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理念本身则有很大的问题,尤其“在没有测试用例失败之前,不要写任何一行代码”的极端方式则更是极端的错误。
阅读全文…

分类: 流程方法 标签: ,
好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 4.44 )
Loading ... Loading ...

Stack Exchange 的架构

2011年2月23日 6 条评论 6,144 人阅读    

近日,Stack Exchange系统管理员blog上发布了一篇关于Stack Exchange的架构一瞥,其包括了Stack Overflow, Server Fault 和 Super User的 Stack Exchange 网络。注意最后一个关于人员的配置。希望能给大家一些相关的参考。

网络流量

  • 每月9千5百万个PV
  • 每秒800 HTTP 请求
  • 每秒180 DNS 请求
  • 每秒55Mb 的带宽

数据中心

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (2 人打了分,平均分: 5.00 )
Loading ... Loading ...

WordPress是怎么赢的?

2011年2月23日 17 条评论 4,531 人阅读    

一个以前在Six Apart工作4年的产品经理Byrne Reese发布了一篇文章阐述为什么WordPress成为了赢家。其在文章中比较了WordPress和其主要竞争对手产品Movable Type。我觉得其中有可取之处,本想全文翻译的,后来觉得文章太长,翻译太花时间,所以,我把文章中的观点总结如下。

作者例举了如下为什么WordPress会赢的理由:

一、Movable Type许可证,而WordPress是开源的

2004年,Movable Type修改了其许可证,这一举动激怒了所有Movable Type的用户,于是大家纷纷转投Wordpress,这是WordPress最终成为赢家最大的原因。就算是Movable Type有着优越的设计,优越的功能,还有优越的技术支持,但是面对的是一个完全免费的产品也没有办法。因为WordPress是开源的,开源就意味着完全免费,而Movable Type一开始也是免费的,但是其许可证策略有着很不确定的因素。(注:2007年Movable Type发布了开源版本)

二、WordPress很容易安装

WordPress的安装过程很简单,只需要不到5分钟,比起Movable Type来说,这太受用户和推广商欢迎,你几乎不需要去碰后台的那些Web设置。(注:不仅如此,WordPress的升级和安装插件和风格的用户体验也是非常的不错)这就是为什么大家都喜欢WordPress的原因,就算是其功能比Movable Type少了又少。

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (6 人打了分,平均分: 4.00 )
Loading ... Loading ...

你会问问题吗?

2011年2月22日 12 条评论 9,576 人阅读    

在工作和生活中,总是会有很多人问题我很多技术方面的问题。有一些时候,问问题的和答问题的总是会有一些不爽的事情发生。如下面的几种情况:

  • 比如:“我的电脑老是蓝屏,怎么办?”,通常这样的问题90%以上的回答是:“重装吧”。这让问问题的人感到很沮丧,但你不能不承认那不是答案。而且有时候让人无法解答,比如:“我的makefiel出错了,你帮我看看我的makfile”,我通常会非反问,报了什么错吗?
  • 另一种情况是,回答问题的人首先先对问问题的人的抱怨,你问的问题就不对,或是,你问的这个问题是什么意思,而导致问问题的人却在不停地解释,结果花了好长时间来讨论问题本身是什么。
  • 还有一种情况是,问的问题太简单了甚至太白痴了,比如你自己试一试或是读读文档就知道了的问题,或是问这个问题直接表明了你的无知或是懒惰。这种问题会相当影响别人对你的印象。
  • 第四种情况是,提问者滔滔不绝,扯这扯那,讲了一大堆,听得听累了。最后都不知道你要干什么。

所以,怎么去问问题,怎么问一个好的问题,是一个很重要的事。你提问的技术直接关系到了你是否能够很快得到你满意的答案。

这里有一篇文章推荐给大家《How To Ask Questions The Smart Way》,中文版在这里《提问的智慧》,我把其中的几个亮点总结如下:

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 5.00 )
Loading ... Loading ...

提高编程技能最有效的方法

2011年2月21日 12 条评论 9,546 人阅读    

StackExchange.com上有两个贴子(贴子一贴子二),贴子名叫“What is the single most effective thing you did to improve your programming skills?” – 对你的编程技术提高最有效的一件事是什么?回复的人中给了很多很不错的建议,我把他们总结了一下,十条,相信一定会对你有用。(注意:顺序是我自己按我的个人经验排的)

  • 和比自己聪明的能力比自己强的人工作。学习他们的代码,他们的做事方法,看一看那些人是怎么处理错误的。
  • 总是倾听别人怎么说,无论那个的资历和职位是什么样的。
  • 实践,实践,实践,总是不满意于一开始出来的事。
  • 多问问自己,现在在写什么代码?为什么要这样写成这样?还有没有更好的方法?
  • 学习多样的技术,多多比较他们,并一定要了解各种技术的优缺点。
  • 总是问别人问好的问题。
  • 多回头看看走过的路,做过的事,写过的程序,感觉一下他们有多烂。
  • 多读读那些大师写的书。
  • 不要总坐在电脑前编程序,多做做运动,多到户外走走,和非技术人多接触,向他们学习。
  • 把你的想法说出去,看看别人怎么回应的。从别人的回应中学习。

除了这些,下面是我个人想给你的建议——

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 4.59 )
Loading ... Loading ...

预发布环境,Tag发布机制和可重复的部署过程

2011年2月20日 7 条评论 1,232 人阅读    

下面文章由网友吕毅投递,源文是:http://blog.lvscar.info/?p=427

—————————————————————————————————————————————

周末聚会,无意间聊起建筑行业。自己是搞软件开发的,我们的行业从建筑设计/施工过程中借鉴了大量的概念,隐喻,名词。可以说软件就是现实中伴随整个人类历史发展的“建筑”在虚拟空间中的投影。有个两年前问过其他朋友的问题,这次友人又再次提起,“为什么建筑设计过程中没有普遍性的采用版本控制呢?” 瞎扯了一干各种原因后,我们几乎同时想到一个名字”Joel”,建筑设计行业或许缺乏像Joel Spolsky一样十数年如一日,把自己丰富的经验和深入的思考转化成一篇篇文章以向新人传授软件开发过程中那些容易被忽略的概念。高傲的黑客们会对CMMI之类的认证抱以鄙夷之情,但对Joel整理出的12条写出更好软件的”最佳实践”,大家甚至把此称为审视其他团队开发过程的“Joel TEST”以推崇

这12条测试如下:

1. 是否启用版本控制?

2. 是否可以一步构建?

3. 是否进行每日构建?

4. 是否有bug跟踪列表?

5. 是否在修改bug后,才开始写新代码?

6. 是否及时更新工作计划?

7. 是否在开发前编写了大家一致认可的功能文档?

8. 是否有安静的工作环境?

9. 是否在使用最好的软件开发工具?

10.是否有专职测试人员?

11.是否在面试时以实际编写代码来检查求职者?

12.是否利用陌生人进行可用性测试?

你所在的团队符合其中的几条呢? 觉得这些条目太一般,软件开发原本就该如此? Joel Test写于十年前,一个Windows XP,Mac OS X,Ubuntu都还没有面世的年代。 如果你觉得这些条目有些过时了,Google中搜索“Joel Test”,你可以看到这十年内很多对此进行更新的尝试, 比如这两个页面“The Joel Test Update for 2010″,“Joel Test for web dev”.

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (5 人打了分,平均分: 4.00 )
Loading ... Loading ...