Browsed by
作者:陈皓

芝兰生于深谷,不以无人而不芳 君子修身养德,不以穷困而改志
rsync 的核心算法

rsync 的核心算法

rsync是unix/linux下同步文件的一个高效算法,它能同步更新两处计算机的文件与目录,并适当利用查找文件中的不同块以减少数据传输。rsync中一项与其他大部分类似程序或协定中所未见的重要特性是镜像是只对有变更的部分进行传送。rsync可拷贝/显示目录属性,以及拷贝文件,并可选择性的压缩以及递归拷贝。rsync利用由Andrew Tridgell发明的算法。这里不介绍其使用方法,只介绍其核心算法。我们可以看到,Unix下的东西,一个命令,一个工具都有很多很精妙的东西,怎么学也学不完,这就是Unix的文化啊。

本来不想写这篇文章的,因为原先发现有很多中文blog都说了这个算法,但是看了一下,发现这些中文blog要么翻译国外文章翻译地非常烂,要么就是介绍这个算法介绍得很乱让人看不懂,还有错误,误人不浅,所以让我觉得有必要写篇rsync算法介绍的文章。(当然,我成文比较仓促,可能会有一些错误,请指正)

问题

首先, 我们先来想一下rsync要解决的问题,如果我们要同步的文件只想传不同的部分,我们就需要对两边的文件做diff,但是这两个问题在两台不同的机器上,无法做diff。如果我们做diff,就要把一个文件传到另一台机器上做diff,但这样一来,我们就传了整个文件,这与我们只想传输不同部的初衷相背。

于是我们就要想一个办法,让这两边的文件见不到面,但还能知道它们间有什么不同。这就出现了rsync的算法。

算法

rsync的算法如下:(假设我们同步源文件名为fileSrc,同步目的文件叫fileDst

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 4.90 )
Loading...
NoSQL 数据建模技术

NoSQL 数据建模技术

全文译自墙外文章“NoSQL Data Modeling Techniques”,译得不好,还请见谅。这篇文章看完之后,你可能会对NoSQL的数据结构会有些感觉。我的感觉是,关系型数据库想把一致性,完整性,索引,CRUD都干好,NoSQL只干某一种事,但是牺牲了很多别的东西。总体来说,我觉得NoSQL更适合做Cache。下面是正文——

NoSQL 数据库经常被用作很多非功能性的地方,如,扩展性,性能和一致性的地方。这些NoSQL的特性在理论和实践中都正在被大众广泛地研究着,研究的热点正是那些和性能分布式相关的非功能性的东西,我们都知道 CAP 理论被很好地应用于了 NoSQL 系统中(陈皓注:CAP即,一致性(Consistency), 可用性(Availability), 分区容忍性(Partition tolerance),在分布式系统中,这三个要素最多只能同时实现两个,而NoSQL一般放弃的是一致性)。但在另一方面,NoSQL的数据建模技术却因为缺乏像关系型数据库那样的基础理论没有被世人很好地研究。这篇文章从数据建模方面对NoSQL家族进行了比较,并讨论几个常见的数据建模技术。

要开始讨论数据建模技术,我们不得不或多或少地先系统地看一下NoSQL数据模型的成长的趋势,以此我们可以了解一些他们内在的联系。下图是NoSQL家族的进化图,我们可以看到这样的进化:Key-Value时代,BigTable时代,Document时代,全文搜索时代,和Graph数据库时代:(陈皓注:注意图中SQL说的那句话,NoSQL再这样发展下去就是SQL了,哈哈。)


NoSQL Data Models

首先,我们需要注意的是SQL和关系型数据模型已存在了很长的时间,这种面向用户的自然性意味着:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 4.90 )
Loading...
用Unix的设计思想来应对多变的需求

用Unix的设计思想来应对多变的需求

之前,@风枫峰 在“这是谁的错?”中说过开发团队对需求来者不拒,而@weidagang 也在“需求变更和IoC”中说过用IoC来最大程度地解决需求变更。今天我也想从Unix设计思想的角度来说说什么是好的软件设计,什么样的设计可以把需求变更对开发的影响降低。(注意:这并不能解决用户或是PM的无理需求,面对无理需求,需要仔细分析需求,而用技术的手段无法搞定这个事,但是可以减轻需求变更带来的痛苦) 我曾经在《Unix传奇》的下篇中写过一些Unix的设计哲学和思想(这里重点推荐大家看一下《The Art of Unix Programming》,我推荐过多次了),以前也发过一篇《一些软件设计的原则》,不过,这些东西都太多了,记不住。其实,这么多年来,我的经验告诉我,无论是Unix设计,还是面向对象设计,还是别的什么如SOA,ECB,消息,事件,MVC,网络七层模型,数据库设计,等等,他们都在干三件事——解耦,解耦,还是解耦所谓解耦,就是让软件的模块和模块间尽量少地依赖起来。

现实当中的例子

让我先举几个现实生活中的例子:

1、现实社会中,制造灯具的工厂完全不关心制造灯泡的工厂,制造灯泡的工厂完全不关心制造灯具的工厂,但是,灯泡和灯饰可以很完美地组合成用户所喜欢的样子(这和@weidagang 在“需求变更和IoC”说到的那个PC的例子相仿)。他们是怎么做到的?

2、互联网上,做网站的人完全不用关心用户在用什么样的操作系统,什么样的客户端浏览器(当然事实上,浏览器的不标准让网站那边很头痛,这里只是举个例),反过来,上网的人也不关心做网站的人在用什么的技术开发网站。但是大家在完全不关心对方的情况下,可以很正常地协同工作在一起。为什么?

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (31 人打了分,平均分: 4.87 )
Loading...
做个环保主义的程序员

做个环保主义的程序员

十多年前刚走入社会工作的时候,那时的中国软件开发根本没有什么版本管理,也没有什么编程规范,软件开发相比起今天来说非常地混乱,那时仅凭自己的一些学习总结了一些C语言编程中的好的小笔记,后来,这些笔记写成了一篇叫《编程修养》的文章。今天,又有些感触,想把这个话题扩大一下,从“个人修养”扩大到“环境保护”,所谓,穷则独善其身,富则达济天下,今天的技术人员比十多年前在技术和环境上都富有了许多,所以,也应该或多或少地担负起“达济天下”的责任了。

环境保护说白了就是保护一个良好的环境,为好的环境添砖加瓦,与破坏环境的人和事做斗争。其实,从技术人员来说,我们可以做一些力所能及的事。因为我们身边的技术环境还有很大的改善的空间,而一些来之不易的东西还需要我们去小心维护。另外,对于我们自己来说,少吃一些垃圾食品,健康生活,对自己也有益。

环保主义软件开发

先说说软件开发中的环保。比如:

  • 环保需求。当我们分析需求的时候,如果我们能做到不要像“这是到底是谁的错”一文中那样的来者不拒,如果我们在面对需求能多问这样几个问题:为什么 要有这样的需求?这个功能主要能解决什么 样的问题?为什么不是另外那一种?可不可以简化一下?其实,我们并不需要创新,只需要真正地问好这几个问题,我们就可以少看着一些弯路,少一些苦逼的加班,少一些内耗,少一些埋怨,也就可以为这个社会节省下一些资源,从而环保。
  • 环保开发。当我们做设计写代码的时候,如果我们多花一些时间去思考一下,我们就可以少一些代码(参看“多一些时间少一些代码”)。如果我们在一开始多思考一下,不要急着马上去用迭代的方式认识世界,多思考一下怎么把复杂的东西解藕,把复杂的东西简化,怎么做出一个优雅的设计,怎么让我们的程序少一些tricky的东西,怎么让我们的程序变得更简洁,更清楚,更直,在一开始思考一下未来需求可能的变化,未来软件需要怎么测试,未来的系统需要怎么的运维,那么,我们可以少一些返工,少一些重构,少欠一些债,少一些低级错误,少承担一些系统上线后的压力,那么,我们同样可以为这个社会节约一些资源。说得再直白一点,你用更少的代码产生出更高的效益,少耗一些CPU,就能省一些电,间接地保护了环境。(参看 Why C++?
好烂啊有点差凑合看看还不错很精彩 (122 人打了分,平均分: 4.63 )
Loading...
游戏:VIM大冒险

游戏:VIM大冒险

不知道大家是否还记得“Vim简明攻略”呢?你是不是对Vim的那一大堆热键很头痛呢?现在好好,下面这个游戏是一个使用VIM热键玩的游戏。你可以在玩游戏的过程中熟悉Vim的热键。

你可以点击图片,或是图片下的网址打开这个游戏

http://vim-adventures.com/

VIM大冒险

我试玩了一下这个游戏,真的很不错,下面是一些我给的游戏攻略。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (29 人打了分,平均分: 4.83 )
Loading...
挑战无处不在

挑战无处不在

面试过一些应聘者,当我问到为什么换工作的时候,他们都会告诉我,现在的工作没有挑战,无聊,所以想换一个有挑战的工作。于是我问了一下他的工作情况,发现那些有挑战的东西他还没有搞懂。我总是为有这样的认识的朋友感到惋惜,因为我总是认为有挑战的东西无处不在啊,不能因为工作上没有,自己就放纵了自己。比如,面试过一个做地图的工程师,他的工作是做计算地图上任意两点的最短或最优路径的一部分功能。我觉得这个事很有挑战,也有难度,应聘者说,没什么挑战,因为他做的东西只是调用相关的算法库。他在这个项目干了2年了,当我问他有没有看过算法库,知不知道地图是怎么存储的?他却告诉我,因为没有去做,所以就没有去了解,等做的时候再了解(我希望有这样想法的人都去看看程序员的谎谬之言还是至理名言?)。这样的例子很多,很多应聘者在面试中不能和我一起解决某个问题的时候,比如:OOD,数据库设计,系统设计,等,他们都会告诉我,不好意思,因为没有做过相关的事情,所以就不懂了,所以,他需要一个像我们这样的项目来学习和锻炼。我并不要求你能解决你所不擅长的问题,但毕竟数据库,OO,系统设计都是软件开发的基础知识,多少要懂一些吧。

但另外一方面,他们都会告诉我他们对技术充满和热情和兴趣,有着很强的学习能力,也有很能吃苦的态度。这也许是某面试宝典上看来的,面经上可能都会说,如果面对不能作答问题,可以说一下自己的态度和决心。可惜的是,我并不这么想的,我在我的两篇关于招聘的文章里(我是怎么招聘程序员的再谈我是怎么招聘程序员的)都说过一些我对如何择人的想法。这里重点说明一下其中两个观点:

  • 关于热情和态度,说白了就是不要给自己找借口。比如:“工作忙事多没时间学所以可以不懂”,“工作中没用到所以可以不懂”,“工作没有挑战,一直没有遇到合适的项目”等等。时间可以挤,工作之余可以学,随时随地去思考,挑战是无处不在的…… 想想那些你有热情的事,你会发现,几乎没有什么可以阻止你去做那些事。
  • 对于某些事情,如果以前没有在你身上发生过,那么这个事情在未来也不会发生。如果你以前没有对你接触过的东西去学习,去深挖,去思考,去改善,那么我不会相信你会在未来面对新的东西的时候也会有这样的态度;如果你以前没有用业余时间学习一些项目之外的东西,那么我也不会相信你会在未来会这样做;如果你以前没有把你的热情和态度转换成你的知识,经验和成果,那么我也不会相信你会在未来能做到。

这两个观点可能太刻薄了,但是,当我回想我自己的经历的时候,观察程序员的成长过程的时候,我发现,优秀的程序员都是相似的,当他们还在是一个菜鸟的时候,就已经有各种成为高手的苗头了,这些苗头就是——他们热爱思考,喜欢解决难题,对新鲜事物非常好奇,总是找人讨论,可以用自己的业余时间狠命研究很多和工作无关的技术,会在业余的时间里写些有趣的小程序,或是会把自己的思路书写下来,等等,等等

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (52 人打了分,平均分: 4.87 )
Loading...
我们需要专职的QA吗?

我们需要专职的QA吗?

这个文章必然是有争议的,我在我的微博上讨论过很多次了,每次都是很有争议的。有不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴,如果你会去认真地深入思考,我也会高兴,如果你反对,没关系,可以讨论。

在此之前,我想说明一下我观点里的这个“专职QA”是怎么定义的。

  1. 其是很多公司成立的专门做测试的技术人员,仅测试不开发。
  2. 这些QA对于软件开发技术并不熟悉,甚至不懂。

我经历过一些公司都有专职的QA团队(专职的测试人员),自从上个公司我的开发团队在一个项目上被QA部门搞得一团糟,我越来越怀疑专职QA存在在意义。我的观点不一定对,但请让我鲜明地表达一下——我觉得是不需要全职的QA的,甚至不需要QA这一专职角色或部门,因为,不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得Dev应该应该是做测试最合适的人选,这必然是未来的趋势 (因为我已经看到了中国程序员的进步,相比起10年前,今天的程序员已经是非常全面了,再来十年,必然证明我的观点是对的)。

在我正在展开说明之前,我想引用两篇文章:

两篇文章

一篇是  “On testers and testing”(中文翻译),本文的作者Sriram Krishnan是一名程序员,曾在Yahoo和微软工作过,开发过很多软件,曾被纽约时报报道,写过一本书,本文是他的一篇博客。他在文章中表达了这几个观点——

大多数的开发团队并不需要一个独立的测试角色。即使要有,那么所有的开发时间比上所有的测试时间应该 >20:1的。。证据吗?光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook,还是30年前最初的NT团队,很多伟大的产品都是出自没有或很少测试人员的团队。

开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试,全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”,那你需要更好的程序员。

另一篇文章是邹欣的“现代软件工程讲义 9 测试 QA 的角色和分工”,这是一篇很不错的文章。他在文章里提到了分工的必要性,比如第三方的鉴定机构,并且也指出了分工的一些问题,比如,画地为牢的分工,无明确责任的分工,等,这些问题直接命中了分工的要害。我隐约觉得,我和邹欣的很多观点是相同的,我们内容上是相同的,只是形式上还有分歧。另外,我的观点太鲜明了,从而容易导向极端的理解。

你看,我们都同意,Dev要懂测试,QA要懂开发,只不过分工不同,既然你中有我,我中有你,那就不要分彼此了,一起携手开发测试吧。(另外,我个人觉得不懂开发的测试人员不可能测试得好)

—- update—- {

     //本篇文章出来后,网上出现了一些对此讨论的文章,我一并更新在这里
【 《对《我们需要专职QA吗?》的回应》作者:@段念-段文韬 】
【 《关于“我们需要专职的QA吗”》作者:@Jacky郭
【 《我们需要专职的QA吗?(评)》作者:@Monkey陳曄曄
【《 《我们需要专职的QA吗?》读后感》作者:@ 花生色魔叔

}

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (49 人打了分,平均分: 4.53 )
Loading...
谈谈数据安全和云存储

谈谈数据安全和云存储

前些天,创新工场李开复同学在2012博鳌亚洲论坛表示

“你们有多少人丢过手机?大概有15%。你们有多少人数据放在微软掉过的?我想不见得很多吧。所以相对来说是安全的。放在大公司里比自己拿着掉的概率更大,你不相信的话,可以问陈冠希先生。

两种安全

看到这个消息的时候,我觉得李开复同学混淆了云存储和安全这两个概念,在英文里,有两个单词,一个是Safety,一个是Security,很不幸的是,这两个英文单词翻译成中文都叫“安全”,因此总是被混淆,熟知英文又熟悉IT业的李开复同学在这个句子中混淆了这“两种安全”,我在我的微博上指出来后,居然还有很多网友继续混淆这两点,所以,这让我产生了写篇博文的说明一下,并顺着说说云存储和数据安全的个人理解。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (16 人打了分,平均分: 4.94 )
Loading...
Bret Victor – Inventing on Principle

Bret Victor – Inventing on Principle

Bret Victor简历) – 苹果公司的UI交互设计师(大神级的人),在 CUSECCanadian University Software Engineering Conference) 上做了一个题为 “Inventing on Principle” 的演讲(vimeo视频链接),这个演讲中展示了五个示例:

  • 用程序画树。如何把程序绘图变成实时的,如何把程序和图映射起来。
  • 游戏调试。在实时编程的基础上,可以更容易的让你看到程序参数对游戏的调整,甚至对游戏过程的可视化调试。
  • 算法调试。在写二分查找算法时可以实时看到程序的执行过程。边写边看到。
  • 电路图。可以实时地看到电路图中各个部件的对1/0信号的处理。
  • 动画。一种比flash制作动画更NB 的方法。

下面是优酷上的视频——你一定会被示例中的那些编程工具所震撼!

不过,Bret并不是在说什么编程,也不是在说什么技术,他是在说 How to live your life。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (52 人打了分,平均分: 4.92 )
Loading...
千万别惹程序员

千万别惹程序员

酷壳好久没有发娱乐性质的技术文章了,搞得气氛有点严肃了,考虑到程序员们都是比较严肃和容易较真的类书呆子的群体,所以,需要更新一个有娱乐性质的文章了。正好最近看到了两个比较有趣的图,在新浪微博上都得到了比较不错的反响,因此,更新到酷壳上来。

如果编程语言是一种刀

下面这个图是把编程语言看做是一种刀,那么会是什么样的。这个图我个人感觉很有意思。

对于这个图,最好不要解释,意会就好。不过,我却有点想不解风情,忍不住想解释一下。

阅读全文 Read More

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