Category Archives: 酷壳 – CoolShell.cn

© 2013 . All rights reserved.

PFIF网上寻人协议

本文的主要内容来自Wikipedia(http://en.wikipedia.org/wiki/People_Finder_Interchange_Format) PFIF全称People Finder Interchange Format,是一个应用广泛的数据开源的标准协议,这个协议主要是设计用来在不同的政府、信仰组织、或是其它的一些灾难中生存者和其亲人联系的网站间进行数据交换的一种协议。 这个协议基于XML,信息中包括人的身份标识,还有人目前的位置和状态等一些信息。PFIF可以通过Atom和RSS feed出去。PFIF可以允许不同的寻人站点进行数据交换和合并。每一条记录都有一个唯一的标识,这个标识说明了这是由哪个域名创建的。这样,当A站点获得B点的某个人的数据时,在A站点可以对这个人的增加的信息可以转到其它站点上再被增加相关的信息,因为有一个唯一的ID,所以信息可以在不同的站点上被附加。 从wikipedia上看,说起PFIF这个事,得回到2001年的911事件,那时人们一共使用了超过25个不同的在线论坛和网上寻人站来查找相关的亲人和朋友(注:寻人网站英文叫:Survivor Registry,生还者登记网站)。其中一个最大的网站是由伯克利大学的学生Ka-Ping Yee 和 Miriam Walker 开发运行在Millennium计算集群上的safe.millennium.berkeley.edu网站。那时,为了减少各种网站间的混乱,伯克利的寻人网站开始从其它几个比较大的寻人站点收集相关的数据,并人肉整合到一起。 2005年,在卡特里娜飓风 灾难的时候,有数据百万人迁移。于是相关的寻人网站又出现了,而且比911的还要多。于是有很多的志愿者开发了一个叫 Katrina PeopleFinder Project(卡特里娜寻人项目) 他们人肉地收集不同站点的数据,并统一格式放到一个由Salesfore.com提供一个数据库中。这个项目的组织者David Geilhufe 呼吁一个技术标准以便这些寻人网站间的数据可以自动地整合共享在一起。于是之前伯克利的那个 Ka-Ping Yee 开始和志愿者 Kieran Lal,Jonathan Plax 和 CiviCRM 团队一同工作,于是开始了草拟了第一版的PFIF协议,其于2005年9月4日发布,1.1版于第二天发布,其中修改了一些错误。随后,Salesfore.com的数据库开始支持这一标准,然后,Yahoo!和Google的寻人网站也加入这一协议。 接下来, 2010年的海地地震 时,Google发布了自己的 Google Person Finder,其基于PFIF协议和CNN,纽约时报,以及美国国家医学图书馆和其它的一些寻人网站进行数据交换。然而,PFIF1.1是基于美国的社会标准搞的,并不适用于海地。于是2010年1月26日,PFIF1.2发布,其增加了几个字段用于标记生还者的国家和国际区号,还有性别,年纪,生日,状态,还有相同人的关联。 PFIF 1.3 于2011年3月发布,其主要解决了个人隐私问题,其加入了一个字段指明该信息的一个有效时间,过期的数据会被删除。PFIF1.3同时移除了英式的first-name和last-name,取而代之的是full-name。 … Continue reading

© 2013 . All rights reserved.

Linus:利用二级指针删除单向链表

感谢网友full_of_bull投递此文(注:此文最初发表在这个这里,我对原文后半段修改了许多,并加入了插图) Linus大婶在slashdot上回答一些编程爱好者的提问,其中一个人问他什么样的代码是他所喜好的,大婶表述了自己一些观点之后,举了一个指针的例子,解释了什么才是core low-level coding。 下面是Linus的教学原文及翻译—— “At the opposite end of the spectrum, I actually wish more people understood the really core low-level kind of coding. Not big, complex stuff like the lockless name lookup, but simply good use of pointers-to-pointers … Continue reading

© 2012 . All rights reserved.

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

之前,@风枫峰 在“这是谁的错?”中说过开发团队对需求来者不拒,而@weidagang 也在“需求变更和IoC” 中说过用IoC来最大程度地解决需求变更。今天我也想从Unix设计思想的角度来说说什么是好的软件设计,什么样的设计可以把需求变更对开发的影响降低。(注意:这并不能解决用户或是PM的无理需求,面对无理需求,需要仔细分析需求,而用技术的手段无法搞定这个事,但是可以减轻需求变更带来的痛苦) 我曾经在《Unix传奇》的下篇中写过一些Unix的设计哲学和思想(这里重点推荐大家看一下《The Art of Unix Programming》,我推荐过多次了),以前也发过一篇“一些软件设计的原则”,不过,这些东西都太多了,记不住。其实,这么多年来,我的经验告诉我,无论是Unix设计,还是面向对象设计,还是别的什么如SOA,ECB,消息,事件,MVC,网络七层模型,数据库设计,等等,他们都在干三件事——解耦,解耦,还是解耦!所谓解耦,就是让程序员的模块和模块间尽量少地依赖起来。 现实当中的例子 让我先举几个现实生活中的例子: 1、现实社会中,制造灯具的工厂完全不关心制造灯饰的工厂,制造灯饰的工厂完全不关心制造灯具的工厂,但是,灯具和灯饰可以很完美地组合成用记所喜欢的样子(这和@weidagang 在“需求变更和IoC”说到的那个PC的例子相仿)。他们是怎么做到的? 2、互联网上,做网站的人完全不用关心用户在用什么样的操作系统,什么样的浏览器,反过来,上网的人也不关心做网站的人在用什么的技术开发网站。但是大家在完全不关心对方的情况下,可以很正常地协同工作在一起。为什么? 这样的例子太多了。为什么可以做成这样呢?因为大家依赖的是一个接口,灯具和灯饰并不互相依赖,他们依赖的是一个接口,做网站的人和浏览网站的人依赖的还是接口——HTTP协议。这就是面向对象的核心思想——依赖于接口而不是实现,这就是触耦。当你看过这两个例子以后,我希望你以后设计的软件至少不能比我们现实社会中的这些方法要差。不然,你就是在让社会倒退了,呵呵。 你会说,这和Unix,和应对需求变化有什么关系?好让我们再来看一下Unix的设计。 Unix设计的例子 下面是几个Unix下的例子: 1、Unix下,所有的硬件都可以通过文件的方式存取。其统统在/dev下。于是,软件和硬件的耦合被解开了,操作系统只需要把硬件统统变成文件,而程序只需要使用三个东西,一个是fd,一个是read(),一个是write(),就可以来操作任意的硬件了,这就是抽象,简单到不行。 2、Unix下,所有的命令都可以用管道串起来(管道绝对是个伟大的发明),这样,所有的命令间的交互全部解耦到只依赖于STD_IN, STD_OUT设备上。最酷的是,用户可以使用管道任意地拼装那些命令,以完成各式各样的功能。管道这个设计思想可以映射为今天的Web Service,你可以任意地拼装各种Web Service。 看到这里,你会发现,这还是解耦,本质上来说,也是一种依赖倒置——OOD的精髓。但是,Unix还不仅仅是这些。我们再来看几个例子: 1、Unix下,软件都是绿色地安装。在iOS上更明显——各个程序间基本上互不干扰,这个程序产生的垃圾文件不会影响到另一个程序。你删到一个程序不会让另一个程序不举,各是各的空间。你可以删除这些程序,只要把内核心留着,系统照样可以启动。 2、Unix下,你可以通过设置一些环境变量,让多种环境同时存在,比如:某个LAMP用的是Apache 2.0, Mysql 4.0, PHP 4.0,某个LAMP用的是Apache 2.2, Mysql 5.0,PHP5.3,你不但可以方便地在系统中切换这两个环境,你甚至还可以同时启动他们。 3、Unix下,你可以随意地替换你想要的程序。比如,你不喜欢bash,你可以替换成ksh/csh等,你不喜欢 awk,你可以替换成gawk,所有的东西都像零件一样,你不喜欢什么,你就可以替换什么。 这三个例子告诉了我们——当你把你的软件设计地耦合度非常地低时,你可以随意地组合,随意地安排你的系统。想当的灵活,灵活到Windows到今天都学不会。 应对需求变化 看到这里,你可能明白我想说的是什么了,你可能开始觉得怎么样的系统设计会更有效了。如果你还记得《Steve Y 对平台的长篇大论》,你就会知道我想说什么了。是的,我想说的就是,当你真正了解了Unix的设计思想后,你会觉得今天的这些东西都是对Unix设计思想的一种传承或是变种。这种东西就是: 1)解耦,解耦,解耦。尽量地让你的模块不要在实现上耦合,而是耦合某个规范,某个标准。 2)KISS,KISS,KISS。要做到高度解耦,你的模块就一定要很简单,当然不是说简单到只有几行代码,而是简单到只干一件事,并把这件事干到极致。然后通过某个标准拼装起来。 … Continue reading