Refresh

This website coolshell.cn/articles/date/2009/06/page/2 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.

Browsed by
月度归档: 2009年6月

Unix 40年:Unix年鉴

Unix 40年:Unix年鉴

今年是Unix 40年的生日,这篇文章,主要是一个Unix的年鉴,其记录了40年来所有和Unix有关的里程碑事件。

如果你想知道Unix的一些故事,你可以查看下面这些文章:

1956

美国司法部颁布法令责成AT&T公司不得从事除了公共承运人提供的通信服务以外的一切商业活动。

1969

三月 — AT&T旗下的 Bell 实验室从操作系统项目Multics (Multiplexed Information and Computing Service)研发中撤出,这是一个前沿但很复杂的分时操作系统。一些重要的Multics理念以后来被用于Unix操作操作系统中。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (11 人打了分,平均分: 3.82 )
Loading...
Unix 40年:昨天,今天和明天

Unix 40年:昨天,今天和明天

经历了四个十年,操作系统的未来充满了变数,但传奇将会是永久的

 原文链接Computerworld

 

译者前言

 今年是Unix40岁的生日。很早就看到这篇文章了,一直想转到中文社区。但一直没有时间,今天看到了CSDN首页的一篇《昨天,今天,明天! Unix系统的40年》号称是转载于cnBeta。这篇文章翻译的要有多烂有多烂,简直就是对Unix 40的历史和原文作者的一种不敬。所以,在这里给出全部译文。

 

关于更为详细的历史,可以参考我的《Unix传奇》上篇下篇

以及一篇CSDN对我的采访《Unix的现状与未来

 

正文

40年前的一个夏天,一个程序员只用了一个月的时间就创造出了这个世界上迄今为止最重要一个软件的原型。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (11 人打了分,平均分: 3.82 )
Loading...
优质代码的十诫

优质代码的十诫

1.- DRY: Don’t repeat yourself.

10commandementsDRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

DRY 这一法则可能是编程届中最通用的法则了,目前为止,应该没有哪个程序员对这一法则存有异议。但是,我们却能发现,一些程序在编写单元测试(unit testing)时忘记了这一法则:让我们相像一下,当你改变一个类的若干接口,如果你没有使用DRY,那么,那些通过调用一系例类的接口的unit test的程序,都需要被手动的更改。比如:如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法,而是每个test case自己去构造类的实例,那么,当类的构造函数被改变时,你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 4.30 )
Loading...
编程中的命名设计那点事

编程中的命名设计那点事

在我开始设计系统的时候,我会花去很多时间去设计命名,因为好的命名和好的设计是分不开的。

In the beginning was the Word, and the Word was with God, and the Word was God
太初有道。道与神同在,道就是神。 (约翰福音第一章,第一节)

在设计过程中给类,方法和函数好的命名会带来好的设计,虽然这不是一定成立,但是如果坏的命名那一定不会给你带来好的设计。在设计过程,如果你发现你很难命名某一个模块,某个方法时,可能你真正遇到的问题不是难命名的问题,而是这个设计是否真的合理,你或许应该花更多的时间来重新设计一下你的模块。

好的命名不仅会带来好的设计,好的命名还提高了程序的可读性,降低代码维护的成本。另一方面,如果糟糕的命名会给代码带来一堵无形的墙,让你必须深入代码去研究代码具有的行为,增加你理解代码的时间。

为此我总结了几条关于命名的指导原则,希望这几条原则能为你的命名设计带来帮助,我使用的是C++的语法,当然这些原则也很容易扩展到其他语言中去。

类型命名(类,接口,和结构)


名字应该尽量采用名词
Bad:           Happy
Good:          Happiness

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (28 人打了分,平均分: 4.11 )
Loading...
编程语言的评测

编程语言的评测

摘要:这篇文章的原文出处在这里 我意译了整篇文章。结合计算机语言评测基准这个网站来读此文还是比较有意思。当然也不能以这个评测结果就贸然断定什么语言最好,什么语言不好。没有好不好的语言,只有适不适用于你解决问题域的语言。就文章而言请大家还是不必太过认真,就当从另一个方面来了解一下这33种编程语言吧。

计算机语言评测基准是一个由429个程序组成的集合,它评测了33个程序语言的13的重复实现的基准程序。如果你想量化的比较不同语言,那么这个是一个非常不错的资源。

在计算机评测基准中,评测者为了尽量让评测准确,非常谨慎的选择了13个基准程序,这13个基准程序并不针对某以特定语言有特殊的优化。对于评测选择33中语言都实现了13个基准程序。当然,除了速度这个指标外,程序基准评测同时也为每一个基准测试程序发布一个编码大小指标。非常感谢基准评测让我们看到程序设计中非常重要的一个方面:程序语言的性能和程序语言灵活性之间的矛盾。正是这个矛盾给所谓“高级编程语言”带上一个含蓄的轻蔑的意思。即,当你在使用这些高级语言编码时,你也许可以编写出漂亮的代码,但是你是如此的远离了硬件,你不可能获得更好的性能,是这样的吗?

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (8 人打了分,平均分: 3.13 )
Loading...
质量管理经中的八个法则

质量管理经中的八个法则

质量管理在软件工程中是非常非常重要的一个环节,无论你有多么精妙的算法,或是使用了多么先进的技术,还是拥有了多少强的设计,在质量控制或质量管理面前,这些都可能什么都不是。这里,有一些质量管理的法则,可以让软件的用户从中受益。如果对质量管理一言以蔽之:面对一个长期不断需要改善的软件,当其用户或是管理者们来说,他们对某个组织所提供的标准有一种完全和最基本的信任。

下面,我们给出8个质量管理的法则:

1. 始终从用户角度出发: “无论何时何地,我们都需要明白用户当前的或未来的需求,并能够达到用户的需求,甚至超出用户的期望。”

这是整个软件工程的重中之重。质量管理从某种意义上来说,就是实现用户需求的质量的管理。这需要我们的质量管理管理和用户的关系,以及把用户的需求和整个团队(开发组,测试组,产品组,项目组等等)进行有些的沟通管理。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (5 人打了分,平均分: 2.40 )
Loading...
《Vim Recipes》免费的Vim Cookbook

《Vim Recipes》免费的Vim Cookbook

当今最流行的文本编辑器是什么,如果我的回答是vim应该不算过份吧。

http://vim.runpaint.org/ 你可以获得一本关于vim的cookbook 《Vim Recipes》

如果你非常喜欢vim编辑器,千万不要错过这本书,使用这本书,你将会发现你在vim遇到问题都可以迎刃而解。

此书还在更新过程中,更多内容请关注http://vim.runpaint.org/

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