XML | 酷壳 - CoolShell

PFIF网上寻人协议

陈皓 — Sun, 21 Apr 2013 16:20:16 +0000

本文的主要内容来自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。

PFIF 1.4 于2012年5月发布，其加入了一个字段用于链接这个人在互联网上的个人资源链接，这样可以用于合并相同的人（比如：指向同一个微博网址），还支持了多个照片。

PFIF1.4的Spec链接：http://zesty.ca/pfif/1.4/

如下的网站有软件实现了PFIF：

本次四川地震，谷歌率先发布了他人寻人网站：https://google.org/personfinder/2013-sichuan-earthquake。接下来，国内的百度，360，搜索，一淘，CSDN，高德……都发布了自己的寻人网站，微博上，大家都在说这些企业不应该搞这么多这样的网站，这样只会造成混乱。而且大家都在呼吁大家一起运作一个网站，共享数据，共享信息。晚上，我在微博上看到了这个PFIF协议，于是写下这篇文章。

关于Google 的寻人的数据可以通过Google PersonFinder API 下载和上传，这里是其API页面：

http://code.google.com/p/googlepersonfinder/wiki/DataAPI

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post PFIF网上寻人协议 first appeared on 酷壳 - CoolShell.

语言的数据亲和力

Todd — Wed, 29 Jun 2011 00:10:44 +0000

[ 感谢 Todd 同学投递本文 ]

目前，程序设计语言似乎进入了一个蓬勃发展的时期，Javascript、Perl、Python、Ruby、Groovy等一批较新的语言正越来越多地被熟悉和使用，而C++、C#、Java等主流语言也在不断地融入函数式和动态性特征。程序员的百宝箱中可供选择的宝贝是越来多了，而社区中关于语言间的比较和争论也更为热烈，我们常常见到关于“面向过程和面向对象的比较”、“动态语言和静态语言的比较”、“命令式和函数式范式的比较”等比较。我注意到这类讨论的关注点多集中于设计相关话题，如“动态语言的Duck typing多态和静态语言的继承多态的比较”，“Prototype based和Class based的比较”等。但我认为还有一个十分重要的方面值得关注，这就是数据处理。

数据处理之所以重要是因为不论是本地信息存储还是系统间信息交换都需要建立在一定的数据格式基础上。另外，不管语言属于那种范式，设计上采用什么模式，在微观层次上程序很大一部分工作都是在做数据处理。所以，从数据处理角度比较和理解语言间的差异有重要的现实意义。虽然数据通常是平台和语言无关的，但不同的语言在处理某种格式的数据时会表现出不同的难度，甚至某些数据格式只能采用特定的语言才能实现，这就是数据亲和力的不同。

语言的数据亲和力(Data Affinity)指的是语言的数据模型与某种数据格式之间的匹配程度。语言对某种数据格式亲和力越强，则操作某类数据越容易。

二进制字节块格式

在偏底层的操作系统、嵌入式和通信系统中，二进制的字节块是最常见的一种数据格式。二进制数据布局紧凑和接近机器的特点使得它常常作为系统间通信或系统文件的数据格式，但一般高级语言都不方便直接和0101打交道，而是基于记录、结构体和类等结构化表示操作数据，这就存在着在底层的二进制字节块和高层的结构化数据直接的转换问题。

C语言作为最主要的系统语言具有很高的字节块数据亲和力。这不仅因为C语言具有指针可以直接访问内存以外，还因为C的结构体(struct)可以和字节块建立起直接的映射关系。例如，在基于Socket连接的分布式系统中服务器端和客户端通过二进制的字节数据进行通信，通信双方只要事先定义共用的结构体，发送方先创建相应的结构体变量并填充字段，然后把变量对应的内存块copy到Socket，接收方从Socket读取字节块，然后把字节块强制类型转换为相应的结构体指针即可读取个字段信息。整个过程中通信的双方都没有复杂的信息编码和解码的过程。示例代码如下：

struct t_data {
    int version;
    char type[10];
    float value;
};

//发送方
struct t_data data;
data.version = 1;
strcpy(data.type,  “degree”);
data.value = 189.0;
send(socket,  &data,  sizeof(data));

//接收方
struct t_data data;
read(socket,  &data,  sizeof(data));
printf(“%d, %s, %f”, data.version,  data.type, data.value);

上面的方法在实际应用中还需要注意内存对齐问题和大小端问题。内存对齐问题可以通过编译器预处理命令来进行控制，保证内存中struct结构与传输的字节块具有相同的对齐方式；大小端问题需要通信的双方采用同样的大小端方式，否则就需要进行转换。

C++可以完全兼容C的结构体，但C++的类(包括class和struct)中如果定义了虚函数，则会丧失结构的字节块数据亲和力，这是C++编程时需要权衡的一个因素。而除了C/C++，其他语言中则难以见到字节块数据亲和力，其原因在于C/C++允许控制结构体/对象的内存布局，并允许对指针进行非类型安全的强制类型转换，这都是在Java，C#等语言中不允许的。所以，在Java、C#中进行字节块的编码解码就只能按照协议一个字段一个字段地按偏移量和长度进行解析。C/C++的指针以及结构体和内存的直接映射带来了对字节块数据的亲和力，但同时也留下了内存访问和类型安全的隐患；而Java、C#在拥有引用安全和类型安全的同时也失去了对字节块数据的亲和力。

文本格式

文本格式是另一种十分常见的数据格式。《Unix编程艺术》中是这样描述文本格式的：”Text streams are a valuable universal format because they’re easy for human beings to read, write, and edit without specialized tools ”。基于文本流的管道处理是一种备受赞誉的Unix风格。Shell可以通过管道把各种功能单一的命令串联起来，让文本流在管道上流动，因而Shell语言具有很好的文本数据亲和力。许多文本数据处理任务Bash都可以一行搞定，这就是Hacker们酷爱的One Liner风格。

下面我们来看两个用Bash进行文本处理的例子：

1. 统计当前目录下的gz文件数目：

ls –l *.gz | wc –l

2. 在Web服务器日子service.log中统计2011年6月26和27两天中每天中各页面的PV

cat service.log | grep ^2011-06-2[6-7] | cut –d ‘ ‘ –f 1, 3 | sort | uniq –c

service.log:

2011-06-25 13:00:55 /music/c.htm Safari
…
2011-06-26 08:01:23 /main.htm IE
2011-06-26 08:03:01 /sports/b.htm Chrome
…
2011-06-27 11:41:06 /main.htm IE
2011-06-27 11:52:41 /news/a.htm Firefox

输出:

210 2011-06-26 /main.htm
231 2011-06-26 /news/a.htm
155 2011-06-26 /sports/b.htm
288 2011-06-27 /main.htm
292 2011-06-27 /news/a.htm
161 2011-06-27 /sports/b.htm

上面的两个简单文本数据处理任务如果是在C或C++下实现则要麻烦得多，代码量至少是十几行或者数十行，加上编译调试，整个开发效率可能比Shell低一个数量级。除了Shell外，Perl也是以强大的文本数据处理而闻名的。我们来看一个Perl正则表达式的例子：

while () {
    if (/hello\s(\w+)/i)  {
        print “say hello to $1“
     }
     elsif (/goodbye\s(\w+)/i)  {
         print “say goodbye to  $1”
    }
}

输入：

HeLLo world

Goodbye bug

输出：

say hello to world

say goodbye to bug

上面的例子中我们看到Perl直接进行字符串匹配并进行数据提取的强大威力。Perl基于正则表达式的字符串处理不仅比C/C++等系统语言更强大，甚至比Python这样的动态语言也更强大和更方便，这是因为正则表达式是Perl语言的“一等公民”，这就使得Perl比其他以库的方式支持正则表达式功能的语言具有更好的文本数据亲和力。后来的Ruby也学习Perl把直接在语言上支持正则表达式。

结构化文本格式

XML是最近十几年来流行起来的一种通用（半）结构化的文本数据交换格式。XML除具有一般文本格式的优点外，还具有表达复杂的层次信息的优势，所以它至诞生以来就被大量用于配置文件和各种Web Service中。现代程序设计基本都少不了了XML打交道，不过在C++、Java和C#集中静态类型语言中处理XML却并不是一件十分轻松的事情。我们先来看一个Java解析和构建下面这个XML的例子：


  Java
  Groovy
  JavaScript

//Java解析XML
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
try {
    DocumentBuilder db = dbf.newDocumentBuilder();
    Document doc = db.parse("src/languages.xml");
    Element langs = doc.getDocumentElement();
    System.out.println("type = " + langs.getAttribute("type"));
    NodeList list = langs.getElementsByTagName("language");
    for(int i = 0 ; i < list.getLength();i++) {
        Element language = (Element) list.item(i);
        System.out.println(language.getTextContent());
    }
}catch(Exception e) {
    e.printStackTrace();
}

//Java创建XML
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
try {
    DocumentBuilder db = dbf.newDocumentBuilder();
    Document doc = db.newDocument();
    Element langs = doc.createElement("langs");
    langs.setAttribute("type", "current");
    doc.appendChild(langs);

    Element language1 = doc.createElement("language");
    Text text1 = doc.createTextNode("Java");
    language1.appendChild(text1);
    langs.appendChild(language1);

    Element language2 = doc.createElement("language");
    Text text2 = doc.createTextNode("Groovy");
    language2.appendChild(text2);
    langs.appendChild(language2);
    Element language3 = doc.createElement("language");
    Text text3 = doc.createTextNode("JavaScript");
    language3.appendChild(text3);
    langs.appendChild(language3);
} catch (Exception e) {
    e.printStackTrace();
}

为了解析和创建小小的一段XML代码需要编写如此冗长的Java代码，而实现同样的功能动态语言Groovy则十分简洁：

//Groovy解析XML
def langs = new XmlParser().parse("languages.xml")
println "type = ${langs.attribute("type")}"
langs.language.each{
    println it.text()
}
//Groovy创建XML
def xml = new groovy.xml.MarkupBuilder()
xml.langs(type:"current"){
   language("Java")
   language("Groovy")
   language("JavaScript")
}

上面Groovy操作XML的代码简洁而富有表达力，代码与XML几乎是一一对应的，如同直接在XML上进行操作的DSL一样，而相应的Java代码则看不到XML的影子。这说明Groovy具有很高的XML数据的亲和力。为什么Java和Groovy在XML亲和力方面有这样的差异呢？原因在于Java要求所有的方法和属性都必须先定义再调用，严格的静态类型检查使得Java只能把XML元素作为“二等公民”来表达；而Groovy则没有静态类型检查的限制，可以自由地使用方法和属性来表达XML结构。上面用Groovy创建XML的例子中，groovy.xml.MarkupBuilder类中实际上并没有langs, language这些方法，但会在调用的时候自动创建相应的XML结构。

除了XML外，JSON是另一种通用的半结构化的纯文本数据交换格式，它常被视为轻量级的XML。JSON的本意是Javascript的对象表示(Javascript Object Notation)，它属于Javascript的语法子集，所以Javascript对JSON有原生的支持。下面就是一个在Javascript中创建JSON对象的例子：

[javascript]var json = { “langs” :
{
"type” : "current”,
"language” : ["Java”, "Groovy”, "Javascript”]
}
}[/javascript]

许多Javascript程序都会通过AJAX都从服务器获取JSON字符串，然后把字符串解析为JSON对象。由于Javascript对JSON的原生支持，所以，在Javascript中解析JSON字符串可以采用通用的eval方式，如：

[javascript]var json = eval(“(" + jsonStr + “)");

alert(json.langs.type);[/javascript]

甚至可以：

[javascript]eval(“var json = ” + jsonStr);

alert(json.langs.type);[/javascript]

不过eval的通用性带来了一定的安全隐患，所以一般只建议对受信任的数据源采用eval方式解析JSON，对于不受信任的数据源可以采用专门的JSON解析库。无论如何Javascript对JSON的原生支持都使得Javascript创建和解析JSON数据十分的简单，也就是说Javascript具有很高的JSON数据亲和力。另外，Groovy 1.8也加入了对JSON的原生支持，操作JSON与Javascript一样方便。

总结

到这里为止本文篇幅已经很长了，只能列举二进制字节块格式、文本格式和结构化文本格式3种典型的数据格式。实际上，数据亲和力的话题还有很多值得探讨的，比如C#的Linq。本文的探讨算是抛砖引玉，目的在于引起大家注意在比较语言的时候不要忽略了数据亲和力这样一个重要方面。本文的错误或不足，敬请指正，谢谢！

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post 语言的数据亲和力 first appeared on 酷壳 - CoolShell.

Web开发人员速查卡

陈皓 — Wed, 16 Feb 2011 10:59:06 +0000

无论你是多牛的程序员，你都无法记住所有的东西。而很多时候，查找某些知识又比较费事。所以，网上有很多Cheat Sheets，翻译成小抄也好，速查卡也好，总之就是帮你节省时间的。之前给大家介绍过Web设计的速查卡、25个jQuery的编程小抄，还有程序员小抄大全，今天转一篇开发人员的速查卡，源文在这里。下面的文章我就不翻译了。

HTML Cheat Sheet

CSS Cheat Sheets

Adobe Flash Cheat Sheets

ASP Cheat Sheets

PHP Cheat Sheets

MySQL Cheat Sheets

JavaScript Cheat Sheets

jQuery Cheat Sheets

Unicode Cheat Sheets

XML Cheat Sheets

mod_rewrite and .htaccess Cheat Sheets

（全文完）

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post Web开发人员速查卡 first appeared on 酷壳 - CoolShell.

那些炒作过度的技术和概念

陈皓 — Fri, 28 Jan 2011 02:00:52 +0000

StackExchange.com上有一个贴子在评论着最近20年来被炒作过度的技术，对于出现的结果，大多数赞同，也有一些不赞同。下面我从前15名挑了10个（Java的WORE我去掉了，TDD我也去掉了，因为我觉得他们应该没有炒作过度，而且都不错），按原贴的顺序罗列如下：（后面的一些评论是我加的，欢迎大家讨论）

Top 10 过度炒作的技术和概念

Unified Modeling Language (UML) – UML是一个程序员交流想法的不错的工具，但是他离程序员真正需要的设计工具还差得很远，比如：设计是否符合需求、架构设计、数据流等等。只有为数不多的程序员使用这个工具交流想法，而没有用在具体工作中。

Sharepoint – 现在N多的公司都在用微软的这个东西做公司内部的Intranet。不过安装和维护起来，代价相当的大。但是其市场做的很成功，不对技术上来说对技术人员来说，相当的蹩脚。Sharepoint的设计没有认真地分析过业务流程，仅仅是一个文档存储地。看上去我们似乎可以做任何的事，但是如果你要用其来管理你的项目和track你的项目问题，你会发现其是无比的难用。

eXtensible Mark-up Language (XML) – XML嘛，以前说过很多了（XML1， XML2）我们用他来做和程序数据封装，用来做配置文件，用来做网络传输格式。我们的程序处理起XML来，又慢，又不经济，没有工具，几乎无法维护XML文件。XML用来做数据封包真是很不经济，Yaml和JSON那个不比它简单？用XML来做程序配置文件不知道是谁想出来的主意，相当的愚蠢，看看Unix/Linux下的配置文件，简单易读，相当容易维护。真是高科技啊。

SOAP, XML-RPC, WSDL 的 Web Services – 这个东西前几年炒的很凶。所有人都相信，这是程序员的未来。可惜的，其中的复杂和不一致，相当的令人恶心。SOAP的那个S居然还是Simple！看来，扯上XML的都不会是什么好的东东。不过，个人认为，CORBA比他更恶。

CORBA – 作为一个比其更恶的更过度炒作的COM技术的Linux/Unix下的补充技术，这个技术也好不到哪里去。相当的复杂，从理论上开始就是这样了。这是一个没有经过实践就搞出来的一个东西。然后开始炒作。

Cloud Computing – 这是一个靠炒作出现的东西。这个东西也就是说，我们可以使用不同的调备，比如电脑，平板电脑，手机，移动设备随时随地做想做的事。Google的Chrome笔记本的广告展示了这项技术，但是，把工作结果放在云端的人会有多少呢。更多的人更喜欢的是去使用那些自己可以控制的电脑或平台。Google在这点上做的明显不如Amazon，像Amazon EC2平台，你可以在世界上任何一个角落随时随地的去启动你那台远程的系统。（更新（2011/1/29）：解释一下，关于云计算，在写下这篇文章的时候我本来有点拿不定主意的，后来回顾了一下历史，如COM啊，ActiveX啊，EJB啊，当时感觉都是很强的东西，但是最终也只是被炒作的。云计算，我不知道未来怎么样，从今天来看，这项技术在今天存在炒作的情况——中移动云，阿里云，到处都是云，在云面前，神马都是浮云了。）

SOA – Service Oriented Architecture – 这是一个没有人真正知道是什么玩意的概念。炒作了很多年，很多人都试图去了解它，但最后的结果是打个哈欠，看别的东西去了。现在没有人提了。中国一些银行在IBM的鼓动下搞了很多所谓的SOA应用，结果是系统很复杂，当然，也再离不开IBM了。

Software Industrial Process – 软件开发中有很多所谓的工业界的流程，用这些流程好像可以控制质量。外包公司和中国的本土公司很喜欢这些东西，比如ISO和CMMi，这些流程不能说不好，也有好的地方，尤其是对那些不会思考只要跟从的Worker来说。这些工业界流程中炒作过度的是，那些所谓的使用这些流程可以预测项目周期，质量控制，以前需求开发和管理等东西。其让流程上升到了一种神学的可预言的地步，同样也上升到了政治的地步。因为，这些流程中都必然会有SQA 的Audit的流程，还有统计和报告的流程，这些统统不是软件开发的流程，但是的确是相当的政治。使用这些工业届标准流程的公司，通常都是一些创造性有问题的公司。

Agile Software Development – 敏捷开发。首先，我承认其中的很多实践相当有效，在理论上也不错，还有很多不错方法的。不过，还是有炒作的成分（下面的言论，我等着被骂）对我来说，在中国，“敏捷开发”的炒作简直就像是一个电视购物，ThoughtWorks中国各种咨询师们软件开发经验其实并不丰富，准确来说，他们有的是咨询经验，而没有具体项目实施经验（有的咨询师甚至都没有写过一行代码就去学教人怎么编程和开发软件了），和他们沟通起来能够感到他们对敏捷很亢奋，而且是唯敏捷主义，就差打出Once Process，One Agile的口号了，他们信仰敏捷流程的已经接近宗教信仰，他们的精神世界很朝鲜。因为，无论你和他们的咨询师谈什么，他们只说敏捷，从来不会分析一下，项目的特性是什么？开发这个项目的人的风格是什么？客户的特性是什么？有没有关心软件的stakeholder们（如：程序员，测试人员，客户，管理人员）是怎么想的？而XP和SCRUM也就成了Push工程师最强大的工具。流程这个东西，应该是项目组自发出来的东西，而不是被灌输，被教条使用的东西。不同的团队、不同的项目、不同的人，不同的风格就是不同的流程，只有去使用适合自己的流程才是最好的流程。打个比方，足球队中，巴西队玩的是个人艺术足球，德国队玩的是整体和纪律性足球，意大利玩的是防守型足球，但是他们都有夺世界杯冠军的实力，如果你硬要让巴西队去整德国队或是意大利队的风格，那就悲剧了。很显然，ThoughtWorks很像把全中国的软件公司都整成Agile的，这注定了其在中国是杯具的，也只能争取到那些不知所措的公司和项目，没有合适的项目，也只有靠各种炒作（比如整一些大会，搞一些宣传）。他们总是觉得中国的用户和程序员需要去用时间不停地教育，但是，他们从来没有想想自己的原因 — 靠教育和灌输是永远赢不了的。我给他们的个人建议是，不要以为世界就像你所想像的那样，学会尊重程序员和项目还有很多非技术的东西，多听听程序员和客户怎么说，多分析一下项目的特质，从实际情况出发，而不是自己涛涛不绝地向大家灌输自己的理论。

Object-Oriented Programming (OOP) – 不多说了，以前本站说过了，所有的一切都在面向对象是个骗局一文中。不过有一点我想告诉大家，面向对象的Design Pattern真是被滥用了，Design Pattern教你的是两件事，1）怎么去化繁为简，2）怎么能让对象的耦合性降低。而不是一个公式让你的套，但，更多的程序员则学会了“流行的设计模式编程”。

附：下构面是我拿不定是否是过度炒作的技术

Write Once Run Anywhere – 这个有点让我不解，不知道为什么会那么靠前。这是Java的口号，我觉得Java在跨平台方面还是成功的，没有过度炒作啊。用虚拟机的确是做到了这一点，对于那些需要有不同的硬件和操作系统平台并不断升级和更换它们的公司来说，这的确是个很不错的解决平台依赖性的方案。我个感觉这个技术并没有炒作过头，至少在Java这边是这样的。与其说这个，还不如说EJB，这才是炒作过度的技术。

[更新 2011/02/13]下面的回复，在我形成这篇文章的时候我没有想过，经ming同学一说，我觉得似乎有些道理。

ming :

我从一开始就觉得java的“Write Once Run Anywhere”是彻头彻尾的炒作。

想想，所谓的跨平台无非就是依靠虚拟机、解释器之类的东西实现的，那么，哪个脚本语言不是依靠解释器呢？古老的perl已经跨平台了。当然，跨平台的语言还有很多。但是，只有java炒作这个概念。

Test Driven Design (TDD) – 从测试案例开始写程序这可能是很多程序员都不习惯的方法。其实这是一种比较好的编程方法，保证了代码怎么改动都不会break其它没有改动的代码，代码可以在一种持续集成中保证质量。但是，我们需要知道TDD的一些副作用（在十条不错的编程观点里也提到过TDD的弊端）：1）TDD可能会让程序员敷衍了事，以为test case 没有错就正确了。2）TDD可能会让你忽略了软件设计和架构以及程序的扩展性和重用性。TDD只是一种方法，并不是程序的核心。当然，TDD近几年的炒作也有点过头，已经出现了“TDD是一种Design方法”等“神乎其技”的论调，我对此表示质疑中。

[更新 2011/02/13] 关于TDD，请参看我另一篇文章《TDD并不是看上去的那么美》

（全文完）

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post 那些炒作过度的技术和概念 first appeared on 酷壳 - CoolShell.

SOAP的S是Simple

陈皓 — Thu, 27 Jan 2011 00:47:56 +0000

曾经有一个争论，一边是站在SOAP这边的人，另一边则是其它人。站在SOAP这边人，当他们在争论SOAP和Web Service框架的复杂度时，SOAP这边的人说，在引入那些WS-*东东之前，SOAP的确是简单的，这就是为什么SOAP的第一个字母S就是Simple。

在2000年的时候，有一个苦恼的程序员，

程序员: 不好意思，我的老板这周末去打高尔夫了，现在我不得不要搞一个SOAP的应用，但是我根本不知道什么是SOAP。SOAP专家，你能帮我吗？

SOAP专家: 当然可以。首先，我要告诉你，SOAP 就是 Simple Object Access Protocol.

程序员: 哦，那么说来，他是简单的罗？

SOAP专家: 简单的就像星期天一样，我的朋友。

程序员: OK，快跟我说说。

SOAP专家: 好，就像他的名字一样，SOAP用为远程对象访问。

程序员: 像CORBA一样？

SOAP专家: 正是如此，就是像 CORBA，只是更简单。不需要复杂的传输协议，还要设置防火墙，SOAP用的是HTTP。而且我们用的是XML作为传输数据格式而不是二进制。

程序员: 听起来很不错哦，告诉我它是怎么工作的？

SOAP专家: 没问题。首先，有一个SOAP信封，其相当的简单。就是一个XML文件由head和body组成。在body中进行你的RPC调用。

程序员: 哦，这就是所有的RPC的东西？

SOAP专家: 确对是的。就像我所说的，你的RPC调用的方法名和其参数都需要写的这个XML文档的body中。方法名是在最外层的tag，每一个嵌套的子tag就是其参数。并且所有参数的类型都可以被指定，请看能规格说明书的第五节。

程序员: (阅读第五节) 还好，不算太坏。

SOAP专家: 现在，当你的服务开发完后，你需要指定endpoint.

程序员: Endpoint?

SOAP专家: Endpoint, 就是服务的地址。你需要使用HTTP的 POST 方法把SOAP 信封放到 endpoint的 URL.

程序员: 如果我使用HTTP的GET方法什么怎么样？

SOAP专家: 不知道，使用GET的行为 undefined.

程序员: 哼哼。那么，要是我把我的服务移到别的 endpoint上？我是否可以得到一个301错误？

SOAP专家: 不会的，SOAP不会返回HTTP的错误码。

程序员: 那么，当你说SOAP使用HTTP，你的意思是说SOAP在HTTP打了个洞？

SOAP专家: 哦，别说得那么难听，应该说， SOAP 是一个传输协议。

程序员: HTTP 就不是吗？那是应用层的协议啊。总之，SOAP支持了别的什么传输协议？

SOAP专家: 官方地来说没有。但是你可以潜在地支持任何的协议。而且有许多的平台支持JMS，FTP还有SMTP。

程序员: 有人用那那些协议吗？

SOAP专家: 嗯，没有。不过，我想表达的是，你能够。

程序员: 好吧。关于 SOAPAction HTTP header，这是用来做什么的？

SOAP专家: 老实说，没人真正的知道。

程序员: 那么，那些 ‘actor’ 和 ‘mustUnderstand’ 属性，是否有人用呢？

SOAP专家: 没有，真的没人用。你就忽略这些东西吧。

程序员: 好吧，让我现读一读SOAP的规格说明书。

(程序员阅读中……)

程序员: 好了，我现在几乎可以做个简单的东西了，但是我不能说我喜欢这个远程过程调用RPC的方法以及其序列化对象的方式。

SOAP专家: RPC！对象序列化！你从哪得到的SOAP就是一堆RPC的这种印象？! SOAP是关于基于文档的消息传递啊，我的朋友。

程序员: 但是，这是你说的……

SOAP专家: 忘了我所说的吧。现在，让我们谈谈消息传递吧。其消息格式遵守XML Schema，我们把之称为新型的文件格式。

程序员: XML Schema?

SOAP专家: 哦，这是很不错的东西，未来的头等技术，你应该看一下。

程序员: (阅读 Schema 规格说明书). 上帝保佑我们！就算是亚历山大帝也搞不定它啊。

SOAP专家: 不必太担心。会有专门的工作为你来创建XML Schema。真的，这只不过就是工具上的事。

程序员: 工具是怎么做的？

SOAP专家: 好吧，他们反映了你的代码，并自动生成Schema。

程序员: 反映了我的代码？我以为这只是文档，而不是对象序列化。

SOAP专家: 你没听我说吗？这只不是工具上的事。总之，我们不能期望你来手写 XML Schema 和 WSDL。另外，这其实就是一种校正测量。你不需要读的。

程序员: 喔喔，等一下，你刚才说的那个单词是什么？ Wizzdle?

SOAP专家: 哦，我没有说过吗？WSDL. Web Services Description Language. 它让你指定你的数据类型，参数，操作名，传输绑定，以及endpoint URI，这样，所有的客户程序员就可以访问你的服务了。你应该看看。

程序员: (阅读WSDL 规格说明书)。我相信那个写下这个文章的人已经被枪杀了。其内部说明都不一致。而且，其用的是HTTP GET绑定，你不是和我说过， GET 是 undefined吗.

SOAP专家: 不必担心那个，没人会用那玩意。总之，工具会帮你生成WSDL，而且在WDSL里会有Schema的。

程序员: 但是，不应该用别的方法吗？不应该是先设计好接口然后再是生成代码吗？

SOAP专家: 是的，我猜那在原则上听起来是对的。但做起来并不容易，只有很少的SOAP栈支持先开发WSDL。让工具为这个事操心去吧。

程序员: 还有一个问题。如果我们传递 XML Schema 的消息，我们在哪里指写操作名？

SOAP专家: 好吧，你还记得 SOAPAction HTTP header吗? 绝大多数的人把操作名放在那里。

程序员: 大多数人？

SOAP专家: 嗯，这种新型并不会被写在所有的地方。

程序员: 我注意到你们整个SOAP界有很多的模糊和歧意，有些地方还是错的，并没有标准的规格说明书。实际上， SOAP 和 WSDL 规格说明书只是 W3C 的笔记罢了，连草稿都不是。

SOAP专家: 我们还在继续中。

程序员: 这个真的能行吗？能承诺吗？

SOAP专家: 绝对没有问题。

程序员: 好吧，那我去试试。

(不久以后……)

程序员: 事情变得很恶心。我这边的工具生成的WDSL居然不能被我同事的工具使用。还不仅仅是这个，其生成的XML Schemas 无法重用。而且，好像没有工具可以最好的处理SOAPAction header.

SOAP专家: 很报歉，兄弟。在光明的那一面，没人用这些文件。为了让传输独立，我们所有人都用包装好的文件。听着是不是很酷：包装好的文件？

程序员: 那是什么？

SOAP专家: 就像是原来那样，只不过，你整个消息被包装起来成一个元素，其和操作有一样的名字。现在操作名和消息成了一体了。

程序员: 好吧，请问说明书在哪里？

SOAP专家: 哦，没有规格说明书。这只是Microsoft自己搞的。不过应该是个很不错的主意，挺不错的。然后，这是一个新玩意。我想你一定会喜欢它的—— Web Services Interoperability Group，简称 WS-I，它就是为了移除 SOAP 和 WSDL 规格说明书中的那些歧义。我知道你有多么喜欢规格说明书。

程序员: 所以，换句话说，原来的那些规格说明书太糟糕了，以致于你需要一个标准化的东西来标准化这些标准。上帝啊。好吧，那么，是否这些协调问题被解决了？

SOAP专家: 当然，只要你使用 WS-I 的 SOAP 栈，就可以减少使用80%的 XML Schema，别用任何不同寻常的数据类型，也别期望可以和WebSphere和 Apache Axis一起运行。

程序员: 那么，是否包装的文件被在那里被解释了？

SOAP专家: 没有，但是你的工具会明白的。绝大多数，总之。

程序员: 让我总结一下，SOAP的定义是不变的，SOAP可以是任何东西，但就是简单，它不再意味着对象访问，就算是所有的工具都那样做。

SOAP专家: 基本上是对的，但是我们走得比你要远一些。我们不赞成SOAP缩写的含义。

程序员: 真的！那么SOAP是什么的缩写？

SOAP专家: 什么也不是，就是SOAP.

程序员: (无语中……)

SOAP专家: 下面让我来告诉你什么是 UDDI。

（注：我以前还认真地学过SOAP，不过真是学不懂。）

原文：来源

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post SOAP的S是Simple first appeared on 酷壳 - CoolShell.

信XML，得自信

陈皓 — Wed, 19 Jan 2011 00:49:48 +0000

XML可能是计算有史以来最NB的发明了，以至于我们以没有XML的程序是难登大堂的程序，不用XML，你都不好意思当程序员。于是，我们看到了很多很雷人的用法（《信XML，得永生》），当然一些朋友当时并没有看懂，不过我不怪大家，因为我们依然深信使用XML可以让你有强大的Zhuangbility，于是我们有下面这两种相当Geiliable的用法。

一、XML中的XML

这个例子是某公司的一个SOAP实现——我们的Webservice需要返回一个XML字符串，这怎么办呢？其实很容易，因为——XML是无所不能的，那怕是封装自己。



  <CompanyGetConnector>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:element name="InitechGetConnector">
        <xs:complexType>
          <xs:choice maxOccurs="unbounded">
            <xs:element name="employees">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="EmployerName" type="xs:string" minOccurs="0"/>
                  <xs:element name="Employee" type="xs:string" minOccurs="0"/>
                  <xs:element name="Firstname" type="xs:string" minOccurs="0"/>
                  <xs:element name="Prefix" type="xs:string" minOccurs="0"/>
                  <xs:element name="Lastname" type="xs:string" minOccurs="0"/>
                  <xs:element name="Org._unit" type="xs:string" minOccurs="0"/>
                  <xs:element name="Function" type="xs:string" minOccurs="0"/>
                  <xs:element name="E-mail_work" type="xs:string" minOccurs="0"/>
                  <xs:element name="Telephone_work" type="xs:string" minOccurs="0"/>
                  <xs:element name="Mobile_work" type="xs:string" minOccurs="0"/>
                  <xs:element name="Birthdate" type="xs:date" minOccurs="0"/>
                  <xs:element name="Hired_since__irt._yearsemployed_" type="xs:date" minOccurs="0"/>
                  <xs:element name="Image" type="xs:base64Binary" minOccurs="0"/>
                </xs:sequence>
              </xs:complexType>
            </xs:element>
          </xs:choice>
        </xs:complexType>
      </xs:element>
    </xs:schema>

    <employees>
      <EmployerName>
        My Client
      </EmployerName>
      <Employee>
        100001
      </Employee>
    </employees>
  </CompanyGetConnector>

二、一切皆为配置

没有hard code这是一个优秀程序员在入门时就要学习的，对于Hard Coder的东西最好写在配置文件中，这样修改这些参数就不需要修改代码而需要重新编译了。自从有了XML之后，我们的配置文件就不在使用像ini文件或是Unix下在conf文件那样的易读，我们认为，使用XML作为配置文件的格式是大势所趋，而且，我们要让我们的代码尽量的可以高度的配置，于是我们出现了下面的代码——这是一个强大的尝试，其标志着，我们完全可以以不久的未来用XML来编写一切语言的代码。

注：下面的代码最强大的应该是XML中的那个SQL。

来源：文章一，文章二

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post 信XML，得自信 first appeared on 酷壳 - CoolShell.

信XML，得永生！

陈皓 — Wed, 09 Jun 2010 00:27:42 +0000

在计算机的世界里，什么最牛？Javascript？C语言？C++？iPad？还是brainfuck？我个人觉得都不是，这个世界里，XML最NB，这世界到处都充斥着XML，正如在“十条不错的编程观点”文中所说，我们不用XML我们都不知道怎么编程了。下面，让我们来看一看XML的几个真实的示例，相信你会同意我的观点的。

一、如何用XML返回数据库SQL查询结果



  
    NAME
    LAST NAME
    MOTHER MAIDEN NAME
    BIRTHDATE
    ...
  
  
    
      MARLENE
      RUTH
      DE MARCO
      1973-02-24 00:00:00
      ...

二、如何用XML序列化一个图片

三、如何让XML与CSV格式兼容




    
        
            example@example.com

四、如何把XML当成数组来用


   110
   442 Fake St.
   61 Main St.
   ...
   ...
   ...
   3881 N 4th Ave. #5D

相信你一定有比这更牛X的例子，欢迎与我们分享！

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post 信XML，得永生！ first appeared on 酷壳 - CoolShell.

早期XML Schema中的open content模型

Neo — Wed, 22 Apr 2009 05:04:41 +0000

摘要：在看SDO的一些规范文档，可能会出现open content这样的词组，上网查了相关资料，发现这是一种XML Schema的模型，本文就描述了XML Schema的Open Content模型的含义，在最新的XML Schema规范中，好像已经没有Open模型，它的等价物是any模型。

早期发布的XML Schema规范中支持一种新的element定义，在这个定义中，你可以将XML的Element的内容定义为开放的。下面我们将会介绍一下XML的Open Content 模型。

在Open Content模型中，如果一个XML的元素在XML Schema中被声明为开放的，那么这个Schema对应的XML文档的实例就可以包含一个没有在Schema中罗列的子元素。例如，一个包含着如下的XML Schema的Schema文件

这个book element的声明意味着这个Schema的实例XML文件必须包含5个元素 – Title,Author，Date，ISBN，Pbulish。例如：

     
         Illusions The Adventures of a Reluctant Messiah
         Richard Bach
         1977
         0-440-34319-4
         Dell Publishing Co.

假设，在实例XML文件，你希望增加book的另外一个子元素，比如，你希望增加一个到某一个网页的连接：

     
         Illusions The Adventures of a Reluctant Messiah
         Richard Bach
         1977
         0-440-34319-4
         Dell Publishing Co.
         http://www.rbach.com"/>

对于上面这个XML文件，XML Schema分析器将会认为这个XML文件是无效的XML，因为上面的文件的包含了Scheme中没有定义的元素。但是在我们的应用场景中，我们可能会希望XML Schema分析器不要报错，因为，应用程序自己知道如何处理这个元素。为了达到这个目的，我们就可以将Book声明为开放的。

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post 早期XML Schema中的open content模型 first appeared on 酷壳 - CoolShell.

XML | 酷壳 - CoolShell

PFIF网上寻人协议

相关文章

语言的数据亲和力

二进制字节块格式

文本格式

结构化文本格式

总结

相关文章

Web开发人员速查卡

HTML Cheat Sheet

CSS Cheat Sheets

Adobe Flash Cheat Sheets

ASP Cheat Sheets

PHP Cheat Sheets

MySQL Cheat Sheets

JavaScript Cheat Sheets

jQuery Cheat Sheets

Unicode Cheat Sheets

XML Cheat Sheets

mod_rewrite and .htaccess Cheat Sheets

相关文章

那些炒作过度的技术和概念

Top 10 过度炒作的技术和概念

附：下构面是我拿不定是否是过度炒作的技术

相关文章

SOAP的S是Simple

相关文章

信XML，得自信

一、XML中的XML

二、一切皆为配置

相关文章

信XML，得永生！

一、如何用XML返回数据库SQL查询结果

二、如何用XML序列化一个图片

三、如何让XML与CSV格式兼容

四、如何把XML当成数组来用

相关文章

早期XML Schema中的open content模型

相关文章

XML | 酷 壳 - CoolShell

PFIF网上寻人协议

相关文章

语言的数据亲和力

二进制字节块格式

文本格式

结构化文本格式

总结

相关文章

Web开发人员速查卡

HTML Cheat Sheet

CSS Cheat Sheets

Adobe Flash Cheat Sheets

ASP Cheat Sheets

PHP Cheat Sheets

MySQL Cheat Sheets

JavaScript Cheat Sheets

jQuery Cheat Sheets

Unicode Cheat Sheets

XML Cheat Sheets

mod_rewrite and .htaccess Cheat Sheets

相关文章

那些炒作过度的技术和概念

Top 10 过度炒作的技术和概念

附：下构面是我拿不定是否是过度炒作的技术

相关文章

SOAP的S是Simple

相关文章

信XML，得自信

一、XML中的XML

二、一切皆为配置

相关文章

信XML，得永生！

一、如何用XML返回数据库SQL查询结果

二、如何用XML序列化一个图片

三、如何让XML与CSV格式兼容

四、如何把XML当成数组来用

相关文章

早期XML Schema中的open content模型

相关文章

XML | 酷壳 - CoolShell