0

目前主流开发技术的分析和总结

转至: www.csdn.net

主流的程序设计语言：C++、Delphi(ObjectPascal)、Java、C#

　　桌面应用程序框架：MFC、VCL、QT、JavaAWT\SWING、.Net

　　企业应用程序框架：WindowsDNA（ASP、COM、COM+）、J2EE、.NetFramework

　　开发工具：VisualBasic、Delphi、VisualC++、C++Builder、VisualC#
*程序设计语言：C++\Delphi（本来应该是ObjectPascal，但为了简单，我就语言和工具混为一谈吧）\Java\C#(虽然他刚刚推出，但因为微软为之倾注了大量心血，一定会成为一种重要的开发语言)

　　　*桌面应用程序框架:MFC\VCL

　　　*企业应用程序框架:WindowsDNA\J2EE\.Net

　　　*COM技术：我单独提出这项技术，是因为它无法简单的被视为语言、桌面应用程序框架或企业应用程序框架，它与这些都有关系。

　　2.1 程序设计语言

　　2.1.1 C++语言的演进

　 　最初要从二进制代码和汇编说起，但那太遥远了。我们就从面向过程的语言说起吧（包括Basic\C\Fortran\Pascal）。这种面向过程的高 级语言终于把计算机带入了寻常的应用领域。其中的C语言因为它的简单和灵活造就了Unix和Windows这样的伟大的软件。

　　面向对象 的语言是计算机语言的一个合乎逻辑的进化，因为在没有过多的影响效率、简单性的前提下提供了一种更好的组织数据的方法，可使程序更容易理解，更容易管理 ——这一点可能会引出不同意见，但事实胜于雄辩，C++终于让C语言的领地越来越小，当今还活着的计算机语言或多或少的都具备面向对象的特征，所以这一点 并不会引起太多困惑。C++的成功很大程度要归因于C，C++成为它今天的样子是合乎逻辑的产物。因为在面向过程的时代，C几乎已经统一天下了。今天著名 的语言象Java\C#都从C借鉴了很多东西，C#本来的意思就是C++++。其实C++曾经很有理由统一面向对象程序设计语言的天下来着，但可惜的是， C++太复杂了。即使是一个熟练的程序员，要你很清楚的解释一些问题你也会很头痛。举几个还不是那么复杂的例子来说：

　　对=的重载\成员转换函数\拷贝构造函数\转化构造函数之间有什么区别和联系呢？

　　定义一个类成员函数private:virtualvoidMemFun()=0;是什么意义呢？

　　int(*(*x(int))[4])(double);是什么意思？

　 　还有其他的特征，比如说可以用来制造一种新语言的typedef和宏（虽然宏不是C++的一部分，但它与C++的关系实在太密切了），让你一不小心就摔 跤的内存问题（只要new和delete就可以了吗？有没有考虑一个对象存放在容器中的情况？）……诸如此类，C++是如此的复杂以至于要学会它就需要很 长的时间，而且你会发现即使你用C++已经好几年了，你还会发现经常有新东西可学。你想解决一个应用领域的问题——比如说从数据库里面查询数据、更改数据 那样的问题，可是你却需要首先为C++头痛一阵子才可以，是的，你精通C++，你可以很容易的回答我的问题，可是你有没有想过你付出了多大的代价呢？我不 是想过分的谴责C++，我本人喜欢C++，我甚至建议一个认真的开发普通的应用系统的程序员也去学习一下C++，C++中的一些特性，比如说指针运算\模 板\STL几乎让人爱不释手，宏可以用几个字符代替很多代码，对系统级的程序员来说，C++的地位是不可替代的，Java的虚拟机就是C++写的。C++ 还将继续存在而且有旺盛的生命力。
2.1.2 Java和C#

　　Java和C#相对于C++的不同最大的有两点：第一点是他们运 行在一个虚拟环境之中，第二点是语法简单。对于开发人员而言，在语法和语言机制的角度可以把Java和C#视为同一种语言。C#更多的是个政治的产物而不 是技术产物。如果不是Sun为难微软的话，我想微软不会费尽心力推出一个和Java差不多的C++++，记得Visual J++吗，记得WFC吗？看看那些东西就会知道微软为Java曾经倾注了多少心血。而且从更广泛的角度来说，两者也是非常相似的——C#和Java面对的 是同样的问题，面向应用领域的问题：事务处理、远程访问、Webservice、Web页面发布、图形界面。那么在这一段中，我暂且用Java这个名字指 代Java和C#两种语言——尽管两者在细节上确实有区别。Java是适合解决应用领域的问题的语言。最大的原因Java对于使用者来说非常简单。想想你 学会并且能够使用Java需要多长时间，学会并且能够使用C++要多长时间。由于Java很大程度上屏蔽了内存管理问题，而且没有那么多为了微小的性能提 升定义的特殊的内容（比如说，在Java里面没有virtual这个关键字,Java也不允许你直接在栈上创建对象，Java明确的区分bool和整型变 量），他让你尽量一致的方式操作所有的东西，除了基本数据类型，所有的东西都是对象，你必须通过引用来操作他们；除了这些之外，Java还提供了丰富的类 库帮助你解决应用问题——因为它是面向应用的语言，它为你提供了多线程标准、JDBC标准、GUI标准，而这些标准在C++中是不存在的，因为C++并不 是直接面向解决应用问题的用户，有人试图在C++中加入这些内容，但并不成功，因为C++本身太复杂了，用这种复杂的语言来实现这种复杂的应用程序框架本 身就是一件艰难的事情，稍后我们会提到这种尝试——COM技术。渐渐的，人们不会再用C++开发应用领域的软件，象MFC\QT\COM这一类的东西最终 也将退出历史舞台。

　　2.1.3 Delphi

　　Delphi是从用C++开发应用系统转向用Java开发应用系统的一 个中间产物。它比C++简单，简单的几乎象Java一样，因为它的简单，定义和使用丰富的类库成为可能，而且Delphi也这么做了，结果就是VCL和其 他的组件库。而另一方面，它又比运行于虚拟环境的Java效率要高一些，这样在简单性和效率的平衡之中，Delphi找到了自己的生存空间。而且预计在未 来的一段时间之内，这个生存空间将仍然是存在的。可以明显的看出，微软放弃了这个领域，他专注于两方面：系统语言C++和未来的Java(其实是. Net)。也许这对于Borland来说，是一件很幸运的事情。如果我能够给Borland提一些建议的话，那就是不要把Delphi弄得越来越复杂，如 果那样，就是把自己的用户赶到了C++或Java的领地。在虚拟机没有最终占领所有的应用程序开发领域之前，Delphi和Delphi的用户仍然会生存 得很好。

　　2.2桌面应用程序框架

　　目前真正成功的桌面应用程序框架只有两个，一个是MFC，一个是VCL，还有一些其他的，但事实上并未进入应用领域。遗憾的是我对两个桌面应用程序框架都不精通。但这不妨碍我对他做出正确的评价。

　　2.2.1MFC

　 　MFC（还有曾经的OWL）是SDK编程的正常演化的结果，就象是C++是C的演化结果一样。MFC本身是一件了不起但不那么成功的作品，而且它过时 了。这就是我的结论。MFC凝聚了很多天才的智慧——当然，OWL和VCL也一样，侯捷的《深入浅出MFC》把这些智慧摆在了我们的面前。但是这件东西用 起来估计不会有人觉得很舒服，如果你一直在用Java、VB或者Delphi，再回过头来用MFC，不舒服的感觉会更加强烈。我不能够解释MFC为什么没 有能够最终发展成和VCL一样简单好用的桌面程序框架，也许是微软没精力或者没动力，总之MFC就是那个样子了，而且也不会再有发展，它已经被抛弃了。我 有时候想，也许基于C++这种复杂的语言开发MFC这样的东西本身就是错误的——可以开发这样的一个框架，但不应当要求使用它的人熟悉了整个框架之后才能 够使用这个系统，但很显然，如果你不了解MFC的内部机制，是不太可能把它用好的，我不能解释清楚为什么会出现这种现象。

　　2.2.2VCL

　 　相比之下VCL要成功的得多。我相信很多使用VCL的人可能没有像MFC的用户研究MFC那样费劲的研究过VCL的内部机制。但这不妨碍他们开发出好用 好看的应用程序，这就足够了，还有什么好说的呢？VCL给你提供了一种简单一致的机制，让你可以写出复杂的应用程序。在李维的Borland故事那篇文章 中曾经说过，在Borland C++ 3.1推出之后Borland就有人提出开发类似C++ Builder一类的软件，后来竟未成行。是啊，如果C++ Builder是在那个时候出现的，今天的软件开发领域将会是怎么样的世界呢？真的不能想象。也许再过一段时间，这些都将不再重要。因为新生的语言如 Java和C#都提供了类似于VCL的桌面应用程序框架。那个时候，加上Java和C#本身的简单性，如果他们的速度有足够块，连Delphi这种语言也 要消失了，还有什么好争论的呢？只是对于今天的桌面程序开发人员来说，VCL确实是最好的选择。
2.3 企业应用程序框架

　　2.3.1 Windows DNA

　 　Windows DNA的起源无从探究了。随着.Net的推出，事实上Windows DNA将成为历史的陈迹。Windows DNA虽然是几乎所有的企业应用程序开发人员都知道的一个名词，但我相信Windows DNA事实上应用的最广泛的是ASP而不是COM+。真正的COM开发有多少人真正的掌握了呢，更不要提COM+(我有必要解释一下：COM+是COM的 执行环境，它提供了一系列如事务处理、安全等基础服务，让应用程序开发人员尽量少在基础架构设计上花精力)——当然我这里指的COM开发不是指VB下的 COM开发，所以要这么说，是因为我觉得如果不能理解用C++进行COM开发，也就不能真正的理解COM技术。如果以一种技术没有被广泛理解和应用作为失 败的标志，那么Windows DNA实际上是失败了，但这不是它本身的错，而是基于C++的COM技术的失败造成的。多层应用、系统开发角色分离的概念依然没有过时。
 2.3.2 J2EE

　 　J2EE是第一套成功的企业应用程序开发框架。因为它把事务处理、远程访问、安全这些概念带入了寻常百姓家。这种成功我认为要归因于Java的简单性。 Java的简单，对于J2EE容器供应商来说一样重要。开发一个基于Java的应用服务器要比基于C++的更容易。而且由于Java的简单性，应用系统开 发者出错的机会也会少一些，不会像C++的开发者那样受到那么多挫折。开发基于Java的企业应用系统的周期会更短，这恐怕是不容争辩的事实。不论如何， 是J2EE让事务处理、远程访问、安全这些原来几乎都是用在金融系统中的概念也被一般的企业用户使用并从中获得利益。

　　2.3.3 .NET

　 　.Net有什么好说的呢？其实，它不过是微软的J2EE。事务处理、安全、远程访问，这些概念在.Net中都找得到。更有力的说明是，微软也利用了. Net实现了一个PetStore。所以，.Net与J2EE几乎是可以完全对等的。但微软确实是一家值得尊敬的公司——我指从技术上，象Web form这种东西，我相信很多Web应用开发者都梦想过甚至自己实现过，但Sun却一直无动于衷，而且似乎Borland也没有为此作过太多努力，好像有 过类似的东西，但肯定是不怎么成功——Borland已经很让人敬佩了，我们也许无法要求太多。
2.4 COM技术

　　COM应当 是个更广泛的词汇，其实我觉得Axtive X、OLE、Auto mation、COM+都应当提及，因为如果你不理解COM，上面的东西你是无法理解的。而且，我只是想说明COM是一种即将消亡的技术，仅仅说说COM 的复杂性和他的问题就够了，所以不会提及那些东西。为什么会出现COM技术？COM的根本目标是实现代码的对象化的二进制重用，进而实现软件的组件化、软 件开发工作的分工。这要求他做到两点：第一，能够跨越不同的语言，第二，要跨越同一种语言的不同编译器。COM技术为这个目标付出了沉重的代价，尤其是为 了跨越不同的编译器，以至于无论对于使用者而言还是开发者而言，他都是一个痛苦的技术。但幸运的事，这一切终归要结束了。

　　让我们从这个 目的出发看看COM为什么会成为它现在的样子。其实COM不是什么新玩意，最初的DLL就是重用二进制代码的技术。DLL在C的年代可能还不错，但到了C ++的年代就不行了。原因在于如果你在.h文件中改变了类定义（增加或者减少了成员变量），代码库用户的代码必须重新编译才可以，否则用户的代码会按你的 旧类的结构为你的新类分配内存，这将产生什么后果可想而知。这就是为什么通过接口继承和通过接口操作对象成为COM的强制规范的原因，能够通过对象的方式 组织代码是COM的重要努力。那么著名的IUnknown接口又是怎么回事呢？这是为了让使用不同编译器的C++开发人员能够共享劳动成果。

　 　首先看QueryInterface，因为COM是基于接口的，那么一个类可能实现了几个接口，而对于用户来说，你又只能通过操作接口来操作类，这样你 必须把类造型成某个特定的接口，使用Dynamic_cast吗？不行，因为这是编译器相关的，那么，就只好把它放在类的实现代码中了，这就是 QueryInterface的由来。至于AddRef和Release，他们产生的第一个原因是delete这个操作要求一个类具有虚析构函数（否则的 话，他的父类的析构函数将不会被调用），但不幸的是不同的编译器中析构函数在vtbl中的位置并不相同，这就是说你不能让用户直接调用delete，那么 你的COM对象必须提供自己删除自己的方法；另外的原因在于一个COM对象可能作为几个接口在被用户同时使用，如果用户粗暴的删掉了某个接口，那么其他的 接口也就不能用了，这样，只好要求用户在想用一个接口的时候通过AddRef通知COM对象“我要使用你了，你多了一个用户”，而在不用之后要调用 Release告诉COM对象“我不用你了，你少了一个用户”，如果COM对象发现自己没有用户了，它就把自己删掉。

　　再看看诡异的 HRESULT，这是跨语言和跨编译器的代价。其实，异常处理是物竞天择的结果——连一直用效率作标榜的C++都肯牺牲效率来实现这个try- catch，可见它的意义，但COM为了照顾那些低级的语言居然抛弃了这个特征——产生的结果就是HRESULT。我们可以看看他是多么愚蠢的东西。首 先，我们要通过一个整数来传递错误信息，通过IErrorInfo来查找真正的错误描述，本来在现代语言中一个try-catch可以解决的问题，现在我 们却需要让用户和开发者都走很多路才能解决，你怎么评价这个结果？其次，由于这个返回计算结果的位置被占用了，我们不得不用怪异的out参数来返回结果。 想想一个简单的int add(intop1,intop2)在COM中竟然要变成HRESULT add(intop1,intop2,int* result)，我不知道你对此作何感想。而且由于COM的方法无法返回一个对象而只能返回一个指针，为了完成一个简单的std::string GetName()这一类的操作，你要费多少周折——你需要先分配一块内存空间，然后在COM实现中把一个字符串拷贝到这个空间，用完了你要删掉这个空 间，不知道你是否觉得这种工作很幸福，反正我觉得很痛苦。还有COM为了照顾那些解释性的语言，又加入了Automation技术，你有没有为此觉得痛 苦？本来一个简单的方法调用，现在却需要传给你一个标志变量，然后让你根据这个标志变量去执行相应的操作。（这一点我现在仍然不明白，为什么解释性的语言 需要通过这个方式来执行一个方法）。“我受够了，我觉得头痛”，你会说，是啊，我想所有的人都受够了，所有这些因素实际上是把COM技术变成了一头让人无 法驾驭的怪兽。

　　人对复杂事物的掌控能力终究是有限的，C++本身已经够复杂了，COM的复杂性已经超出了我们大部分人的控制能力，你需 要忍受种种痛苦得到的东西与你付出的代价相比是不是太不值得了？我们学习是为了解决问题，而现在我们却需要为了学习这件事情本身耗费太多的精力。这些痛苦 的东西太多了，我在这里说到的，其实只是一小部分而已。计算机技术是为人类服务的，而不是少数人的游戏（我想COM技术可能是他的设计者和一部分技术作者 的游戏），难道我们愿意成为计算机的奴隶吗？通过一种过于复杂的技术抛弃所有的人其实等于被所有的人抛弃，这么多年中选择J2EE的人我相信不乏高手，你 是不是因为COM的过于复杂才选择J2EE的？因为它可以用简单的途径实现差不多的目标——软件的“二进制”重用、组件化、专业分工（容器开发商和应用开 发商的分工）。事实上，你是被微软所抛弃的，同时，你也抛弃了微软。

　　现在让我们回来吧，我把你带进了COM的迷宫，现在让我把你领回 来。再让我们看看COM到底想实现什么目标，其实很简单，不过是代码的二进制重用，也就是说你不必给别人源代码，而且你的组件可以象计算机硬件那样“即插 即用”。我们回过头来看看Java，其实，这种二进制重用的困难是C++所带来的（这不是C++本身的错，而是静态编译的错），当Java出现的时候，很 多问题已经不存在了。你不需要一个头文件，因为Java的字节码是自解释的，它说明了自己是什么样子的，可以做什么事情。不像C++那样需要一个头文件来 解释这些事情；也不需要事先了解对象的内存结构，因为内存是在运行的时候才分配的。如果我们现在再回过头来解决COM要解决的问题，你会怎么做呢？首先你 会不再选择C++这种语言来实现代码的“二进制”重用，其次，你会把所有的语言编译成同样的“二进制”代码（实际上，应当说是字节码），这显然是更聪明的 做法，从前COM试图在源代码的级别抹平二进制层次的差异，这实际上是让人在做本来应当由机器做的事情，很愚蠢是吗？但他们一直做了那么多年，而且把这个 痛苦带给了整个计算机世界——因为他们掌握着事实的标准，为了用户，为了利润，为了能够在Windows上运行，尽管你知道你在做着一个很不聪明的事情， 但你还是做了。

　　COM技术为了照顾VB这个小兄弟和实现统一二进制世界的野心，实在浪费了太多的精力。首先，落后的东西的消亡是必然 的，就象C、Pascal在应用领域的消亡一样，Basic一点一点的改良运动是不符合历史潮流的做法，先进的东西和落后的东西在一起，要么先进的东西被 落后的东西拖住后腿，要么是同化落后的东西，显然我们更愿意看见后者，现在Basic终于被现代的计算机语言同化了。其次，统一二进制世界好像不是那么简 单的事情，而且也没什么必要，微软的COM技术奋战了10年，现在也只有他自己和Borland支持，.Net终于放弃了这个野心。这一切终于要结束了。

过去J2EE高歌猛进地占领着应用开发的领地，COM在这种进攻面前多少显得苍白无力。现在微软终于也有了可以和J2EE一较长短的.NET，对于开发 人员来讲，基于字节码的组件的二进制重用现在是天经地义的事情；你不用再为了能够以类方式发布组件做那么多乱七八糟的事情，因为现在所有的东西本来就是类 了；实现软件开发的分工也很自然，你是专业人员，就用C#吧，你是应用开发人员，你喜欢用VB.Net，你就用吧，反正你们写的东西最终都被翻译成了一样 的语言（其实我觉得这一点意义不大，因为一些不那么好用的语言被淘汰是正常的事情，C风格成为程序设计语言的主流风格，肯定是有它的原因的，语言的统一其 实是大势所趋，就象中国人民都要说普通话一样，我觉得Java不支持多语言算不上缺点——本来就是一种很好看很好用的语言了，为什么要把简单问题复杂化 呢？）。COM不会在短期内死去，因为我估计微软还不会马上用C#开发Office和Windows的图形界面部分，但我相信COM技术退出历史舞台的日 子已经不远了，作为一般的开发人员，忘了这段不愉快的历史吧——你将不会在你的世界里直接和COM打交道。若干年以后，我想COM也许会成为一场笑话，用 来讽刺那种野心过大、钻牛角尖的愚蠢的聪明人。

0

Java替代C语言的可能性

前不久CSDN刊登了一篇《C语言已经死了》的文章，引起了一些争论。其实那篇文章是从Ed Burnette的博客上转载来的，原文题目是“Die, C, die!”，直译过来应该是《去死吧，C！》，表达的是一种诅咒，而不是判断。翻译称《C语言已经死了》，显然是一种煽风点火的误读。CSDN网友对于其观点已经进行了批判，不过坦率地说，由于这些批判基于一个扭曲的翻译文本，所以不但没有什么新鲜的地方，而且也没有抓住原作者的重点。

    实际情况是这样的，最近一段时间，在国外的技术社群里刮起了一股风，不少人在讨论Java做为C语言替代者而成为最主流的基础软件编程语言的可能性。从大部分人发表的观点来看，对于Java替代C的趋势还是支持的。

     基础软件是指这样一类软件，其主要任务是把计算机的潜能充分发挥出来，面向上层应用软件提供一个高效、可靠的功能集。这些软件会被密集地调用，性能上的一点点滞后都会在实践中被成百上千倍的放大。所以对于基础软件来说，性能至少与可靠性一样重要。我们在一些基础软件的源代码里，常常看到一些丑陋的设计，看到一些变态的黑客技巧，在其他的领域里，这是不被鼓励的，但是在基础软件中，这就是合理的，可以接受的。

     C语言目前仍在一些领域里坚挺，在操作系统、虚拟机和设备驱动程序开发方面，它可能是永远的王者。但是在其他的基础软件领域，比如数据库、网络服务器、图形图像处理等，C语言继续占据霸主地位的原因其实只有两个，一是快，二是熟悉的人多，而且经验丰富。

    但是这两点现在都遭到了挑战。

    首先是速度。Java的执行速度在JDK1.4的时候达到了这样一个水平，就是对于一个一般水平的开发者来说，他写的C++程序已经不再比对等的Java程序跑得更快了。随后的JDK 5.0和6.0进一步提高了执行性能，由不同的组织举行的多项评测结果表明，Java与C语言的整体执行效率差距在一倍以内，也就是说，素以速度著称、并且为了速度放弃了很多东西的C语言，现在比装备齐全的Java只快不到一倍了。这还不算，如果考虑到新的计算环境，C语言的速度优势有可能仅仅是一个错觉。因为，世界上只有很少的人有能力在多CPU计算平台上用C语言写出又快又正确的大程序，在这些人中间，又只有很少很少的人有能力用C语言写出一个在大型的、异构的网络环境下能够充分发挥各节点计算能力的大规模并行程序。也就是说，你也许有能力把程序效能提高一倍，从而充分发挥一台价值6000元人民币的PC的计算潜力，为客户节省1000元钱。但如果是在一个由1000台机器组成的大型异构网络并行计算的环境下，你写的C程序恐怕性能还会远远低于对应的Java程序，更不要说巨大的后期维护成本，而由此带来的损失可能是1000万或者更多。

    其次是经验。很多人都宣称自己的C功力如何如何了得，但是实际上，即使是真正的C高手也不得不花相当可观的时间来寻找并且调试错误，尤其是内存方面的错误。大部分用C写的上规模的软件都存在一些内存方面的错误，需要花费大量的精力和时间把产品稳定下来。这还没有把安全方面的缺陷考虑在内，现在大部分的开发者在代码安全方面的知识都很薄弱，安全漏洞在代码中相当普遍，而在C语言中，这一不足暴露得格外明显。最大的挑战或许得说是并发问题了，并发是一个很复杂的问题，需要在相当高的抽象层面上解决，而C语言的抽象机制过于简单，提供不了高层的抽象，因此在开发者只能从一些“并发原语”出发去构造并发程序，这跟用铅笔刀锯大树没什么分别，直截了当地说，大部分C程序员根本没有能力编写高效无缺陷的并发程序。

    所以残酷的事实是，当一个人说自己的C语言如何了得，经验如何丰富时，非常可能他说的是，自己在用C语言写单机、单线程的，不会遭到外界攻击的，在时间预算上没有什么压力，而且用户能够忍受一个很长的产品稳定期的应用程序方面非常有经验。遗憾的是，市场环境和计算环境已经完全变化。面对更复杂的计算环境，用C语言来编写高质量的大规模软件，是只有真正的专家团队才能完成的工作。如果你曾经有过连续数日苦苦追踪和调试一个内存泄露、或者线程错误的经历，你就会明白，你可能不是这样的专家。

    相比之下，Java在抽象机制、基础设施、安全和并发方面，与C语言比起来，就好像是马克沁重机枪对弓箭。比如并发，Java 5.0加入的java.util.concurrent包，可能是目前主流语言中对于并发问题最强有力的支持库。Java的内存管理和安全机制，也已经被实践证明确实能够有效地减少程序的缺陷。这也就是那篇诅咒文章的原文的意图。

    所以，我的态度明确的，我认为Java替代C是一个进步的想法，不过世界上进步的想法很多，能够美梦成真的却寥寥无几。Java是否真的能够在基础软件领域强有力地替代C语言呢？我看至少短期内还做不到，原因如下：

1. 人的问题。能够用C语言写出优秀基础软件的人固然不多，能用Java写出来的人恐怕更少。Java有好几百万开发者，但是他们在干什么？大部分是去搞企业级开发、Web开发了，有多少人真的理解Java的内存模型？有多少人能够熟练使用concurrent包中提供的那些工具？很多使用Java多年的人没有写过socket程序，不了解Java多线程的开销，不清楚如何进行性能诊断和调优，而这些在写基础软件的时候是必备的技能。大部分Java程序员在刚刚学会Java之后就转向Web开发，把主要精力花费在掌握一个又一个大型的、复杂的、具有厚厚的抽象层和华丽结构的frameworks上，不但对真实计算机体系结构不清楚，对于Java虚拟出来的那个计算环境也不清楚。因此，要把Java社群编程转变成能够担负起下一代基础软件开发工作的尖兵，不但难度很大，而且必须花费足够的时间。

2. Java的内存消耗太大。对于系统级程序来说，内存消耗大，就意味着cache命中率降低，与磁盘交换数据的可能性增大，对性能的影响还是比较严重的。现在很多人还是觉得Java慢，主要的原因已经不是Java跑得慢，而是由于内存消耗过大导致的综合性能下降。这个问题不解决，Java就只能用来做一些比较上层的基础软件。也许随着计算机硬件的发展，这个问题会逐步得到解决？

3. 风格的问题。这个问题我认为是最严重的。基础软件开发崇尚的是自由、直接、透明、简单、高效，要像匕首一样锋利，像战士一样勇猛，像农夫一样朴实，反对繁琐华丽的设计，反对架床迭屋的层层抽象，反对复杂的结构和不必要的灵活性。而Java社群多年来形成的设计风格与此格格不入，甚至可以说是对立的。Java在意识形态上是要面向企业应用软件的开发，所以特别强调架构，强调设计模式，强调标准，强调规规矩矩，强调高姿态，强调一种华贵的宫廷气质。在C中，你吃饭就是吃饭，捧起碗来喝酒，放下筷子骂娘，甩开膀子抓肉，撸起袖子抹油。而在Java中，你经常为了要干某件事，先new一个对象，然后以这个对象为参数new另一个对象，如此这般重复n遍，得到真正需要的对象，最后就是为了调用那个对象的一个方法，就好比吃饭时焚香洗面，漱口净手，战战兢兢，毕恭毕敬。在C中，遇到问题要像亡命徒，像流氓版程咬金，管你三七二十一，冲上去就是三板斧，还怕劈不死你丫的。在Java里，遇到问题要像宋襄公，要张榜檄文，要名正言顺，要礼仪之邦，要把架子拉开了，把谱儿摆足了。Java的口号是，不管劈不劈的死，先把你小子感动了再说。 这套繁琐的东西，对于基础软件开发来说，既不必要，也很难习惯。需要说明的是，这不是Java语言的问题，其实Java本身不必如此复杂、如此巴洛克。从语言本身来看，Java也可以是轻快直接的，也可是酣畅淋漓的。只不过十多年来几乎没有人这样用过，所以大家已经不知道：如果不来个一步三叩首，那么该怎么用Java写程序？

    正是因为上面的这种种原因（可能还不全面），直到最近，第一流的基础软件几乎都还是C语言编写的，或者至少其核心部分还是以C为主。而且我认为，在短期内，这种局面不会有大的改变。当然，如果Java社群能够克服上面的这些问题，充分发挥出Java本身的优势，在基础领域开发出一大批一流的支撑软件，那么局面是可以改变的，而且这种改变也是进步的，值得欢迎的。

转自：http://blog.csdn.net/myan/archive/2007/01/14/1482614.aspx

0

免费软件套装

0

程序员真实写真:35岁前成功的12条黄金法则

转http://www.javaresearch.org/article/60374.htm

第一章：一个目标

　　一艘没有航行目标的船，任何方向的风都是逆风

　　1、你为什么是穷人，第一点就是你没有立下成为富人的目标

　　2、你的人生核心目标是什么？

　　杰出人士与平庸之辈的根本差别并不是天赋、机遇，而在于有无目标。

　　3、起跑领先一步，人生领先一大步：成功从选定目标开始

　　4、贾金斯式的人永远不会成功

　　为什么大多数人没有成功？真正能完成自己计划的人只有5%，大多数人不是将自己的目标舍弃，就是沦为缺乏行动的空想

　　5、如果你想在35岁以前成功，你一定在25至30岁之间确立好你的人生目标

　　6、每日、每月、每年都要问自己：我是否达到了自己定下的目标

　　第二章：两个成功基点

　　站好位置，调正心态，努力冲刺，35岁以前成功

　　（一）人生定位

　　1、人怕入错行：你的核心竞争力是什么？

　　2、成功者找方法，失败者找借口

　　3、从三百六十行中选择你的最爱

　　人人都可以创业，但却不是人人都能创业成功

　　4、寻找自己的黄金宝地

　　（二）永恒的真理：心态决定命运，35岁以前的心态决定你一生的命运

　　1、不满现状的人才能成为富翁

　　2、敢于梦想，勇于梦想，这个世界永远属于追梦的人

　　3、35岁以前不要怕，35岁以后不要悔

　　4、出身贫民，并非一辈子是贫民，只要你永远保持那颗进取的心。中国成功人士大多来自小地方

　　5、做一个积极的思维者

　　6、不要败给悲观的自己

　　有的人比你富有一千倍，他们也会比你聪明一千倍么？不会，他们只是年轻时心气比你高一千倍。

　　人生的好多次失败，最后并不是败给别人，而是败给了悲观的自己。

　　7、成功者不过是爬起来比倒下去多一次

　　8、宁可去碰壁，也不要在家里面壁

　　克服你的失败、消极的心态

　　（1）找个地方喝点酒

　　（2）找个迪厅跳跳舞

　　（3）找帮朋友侃侃山

　　（4）积极行动起来

　　第三章：三大技巧

　　1、管理时间：你的时间在哪里，你的成就就在哪里。

　　把一小时看成60分钟的人，比看作一小时的人多60倍

　　2、你不理财，财不理你

　　3、自我管理，游刃有余

　　（1）创业不怕本小，脑子一定要好

　　（2）可以开家特色店

　　（3）做别人不愿做的生意

　　第四章：四项安身立命的理念

　　35岁以前一定要形成个人风格

　　1、做人优于做事

　　做事失败可以重来，做人失败却不能重来

　　（1）做人要讲义气

　　（2）永不气馁

　　2、豁达的男人有财运，豁达的女人有帮夫运

　　35岁以前搞定婚姻生活

　　3、忠诚的原则：35岁以前你还没有建立起忠诚美誉，这一缺点将要困扰你的一生

　　4、把小事做细，但不要耍小聪明

　　中国人想做大事的人太多，而愿把小事做完美的人太少

　　第五章：五分运气

　　比尔?盖茨说：人生是不公平的，习惯去接受它吧

　　1、人生的确有很多运气的成人：谋事在人，成事在天：中国的古训说明各占一半

2、机会时常意外地降临，但属于那些不应决不放弃的人

　　3、抓住人生的每一次机会

　　机会就像一只小鸟，如果你不抓住，它就会飞得无影无踪

　　4、者早一步，愚者晚一步

　　第六章：六项要求

　　1、智慧

　　（1）别人可你以拿走你的一切，但拿不走你的智慧

　　（2）巧妙运用自己的智慧

　　（3）智者与愚者的区别

2、勇气

　　（1）勇气的力量有时会让你成为超人

　　（2）敢于放弃，敢于舍得

　　3、培养自己的领导才能、领袖气质

　　（1）激情感染别人

　　（2）三o七法则实现领袖气质

　　（3）拍板决断能力

　　（4）人格魅力

　　4、创造性：不要做循规蹈矩的人

　　25-35岁是人生最有创造性的阶段，很多成功人士也都产生在这一阶段

　　5、明智

　　（1）知道自己的长处、短处，定向聚焦

　　（2）尽量在自己的熟悉的领域努力

　　6、持之以恒的行动力：在你选定行业坚持十年

0

.NET程序设计之四书五经

(以下排名不分先后)

(一)  C#程序设计  
 　　由获奖作家Charles Petzold撰写的这本书对C#语言做了深入浅出、循序渐进的论述。不论是第一次接触程序设计还是第一次接触C#语言，你都会迅速掌握使用C#语言开发应用程序的技巧。
　　C#语言是一种面向对象的程序设计语言，特别适合为Microsoft Windows和因特网开发各种解决方案。由获奖作家Charles Petzold撰写的这本书对C#语言做了深入浅出、循序渐进的讲述。读者不论是第一次接触程序设计还是第一次接触C#语言，都会通过本书迅速掌握使用C#语言开发应用程序的技巧。
内容简介：
　　●最简单的变量 整数和文本字符串
　　●最基本的用户输入和输出
　　●十进制数和浮点数
　　●帮助程序做出判断与决定的布尔类型
　　●选择与重复 条件语句，循环语句、枚举集合
　　●防止程序崩溃 结构化异常处理机制
　　●用字段、方法和属性构建一个类
　　●充实和扩展类的功能 继承、操作符和虚方法
　　●把信息保存到数据文件里
　　●CH程序设计实战 用C#程序演奏C#“交响乐”

(二) Microsoft.NET程序设计技术内幕   
        本书是《微软.NET程序员系列》丛书之一，主要讲述Microsoft.NET编程技术，可帮助你快速而深入地理解.NET框架的主要编程模型。全书分为三大部分，第I部分“基本概念”，主要介绍学习本书需要了解的一些基础知识，包括Microsoft.NET框架方面的知识。第II部分的所有内容都是关于ASP.NET的，包括如何用ASP.NET构建Web应用程序和Web服务。第III部分“前沿技术”，分别介绍ADO.NET、XML、多线程和远程处理技术。本书用简明的语言解释了复杂的概念，书中还包括75个精心设计的完整的示例程序，对于理解.NET的编程模型和解决实际的开发问题很有帮助。
        本书是开发.NET Web应用程序的开发人员必读的经典著作。

(三) C# Windows Forms程序设计
        本书是打开WindowsForms编程之门的金钥匙，它所采用的编程语言是当前最为流行、最具潜力的C#。本书内容详尽充实，共分为3个部分：初识WindowsForms、WindowsForms基础和高级WindowsForms。通过本书的学习，读者能够迅速掌握通过.NETFramework开发WindowsForms程序的所有相关技术。
无论对开发桌面应用程序的Windows程序员，还是正在学习WindowsForms知识的开发人员，或者是毫无Windows开发经验的初学者，相信本书都是最佳的选择。

(四) Microsoft .NET框架程序设计（修订版）
        这是一本任何一个想了解.NET、学习.NET的读者都不可不读的开山之作。它全面剖析了.NET框架机理，深度阐述了.NET平台思想。它在亚马逊网站雄踞编程类图书销量排行榜榜首达14个月之久。让我们听听下面的声音：
        ‘Jeffrey在.NET框架上所做的大量的工作，在这部内容详实的优秀著作中得到了充分的体现。’ 
                                                                –Eric Rudder 微软公司，开发者与平台推广部 ，高级副总裁
        ‘Jeffrey和通用语言运行时项目组的日夜协作使得这本书成为解释CLR内部机理方面最好的教本。’ 
                                                                –Dennis Angeline，微软公司，通用语言运行时组，程序经理主管
        本书是《微软.NET程序员系列》丛书之一，主要介绍如何开发面向Microsoft .NET框架的各种应用程序。Microsoft .NET框架是微软公司推出的新平台，包含通用语言运行时(CLR)和.NET框架类库(FCL)。本书将深入解释CLR的工作机制及其提供的各种构造，同时还将讨论FCL中一些重要的类型。全书共分为五个部分，包括：.NET框架基本原理、类型和通用语言运行时、类型设计、基本类型，以及类型管理。
        本书适用于要了解、掌握.NET平台的读者，尤其适合广大编程爱好者、软件工程师、系统架构师阅读。

(五) .NET大局观
        “David Chappell 是当今最优秀的技术作家之一。他身负数十年业界经验，以流畅的写作风格，为读者提供了这一份对．NET平台清晰而忠实的观察。面对本书，每一位称职的架构师、开发人员和管理人员都应该人手一本。我向你强烈推荐。”——Richard Monson-Haefel，《Enterprise Java Beans》3e (O’Reilly，2001)作者
微软的．NET是一个对Windows-based软件开发起到革命性影响的新技术集。.NET主题之一是Web services的思想，允许软件运用Internet技术，和其他软件直接通讯。这个首创技术中的核心组成：．NET Framework和Visual Studio.NET，提供了一个多语言环境，让开发人员在其中开发Web services及其他类型的应用。.NET的另一方面：.NET My Services，提供我们一个用以创建新型应用的新型平台。总而言之，.NET技术将改变几乎所有Windows应用程序的构建方式。
        《.NET大局观》是为开发人员和技术管理人员撰写的一本书，是对Windows崭新开发景观的一份简明指南。页边注释、详细图表以及明晰的写作风格，使这本书易于阅读和浏览；分析文块则探索带争议的话题，并提出常见的关注点。这本书的独立观点和直白描述，清楚地阐示了．NET技术的运作机理和使用方式。
        本书关键主题包括：
                ．NET本身及其目标总览
                 Web services技术， 包括SOAP(简单对象 存取协议)及其他…
                ．NET Framework通用语言运行层(CLR)
                 C#和Visual Basic．NET
                ．NET Framework类库(Class Library)
                 ADO．NET
                 ASP．NET
                ．NET My Services
        理解是运用之钥。《．NET大局观》将使阁下得以作出正确的决策，并最大限度地挖掘这一革命性框架(framework)的潜能。

(六) PROGRAMMING MICROSOFT WINDOWS WITH C#（英文版）
        Charles Petzold先生的《Programming Microsoft Windows With C#》没有理由不引起Microsoft.NET平台开发人员的注意，它在2001年12月甫一出版就和Jeffrey Richter先生的《Applied Microsoft.NET Framework Programming》一起被各方视为Microsoft.NET领域的“书坛双璧”，两者也被微软官方出版社钦定为Microsoft.NET领域的“红宝书”。显然，人们对Windows技术写作领域的两位大师抱以这样的期待有足够的理由。Jeffrey Richter先生不负众望，利剑出鞘，《Applied Microsoft.NET Framework Programming》已经成为Microsoft.NET底层框架技术方面公认的、事实上的Bible（圣经）。那么《Programming Microsoft Windows With C#》怎么样呢？是否能再现当年《Windows 程序设计》的辉煌？是否能成为读者所期待的Microsoft.NET平台下Windows程序设计方面的圣经呢？从笔者的阅读经验来看，《Programming Microsoft Windows With C#》一书虽然仍旧保持了Charles Petzold先生一贯的简约雅致、平实通俗的写作风格，但整本书不管在组织的广度上、还是在内容的深度上不免要使许多“慕名而来”的读者失望，还有不少地方有待补足与提高。当然，这本书在名目繁多的技术书籍中不能不算优良之品，只是与Charles Petzold先生的盛名不符，与期望的大师之作有差距。
        在进入本文主题之前有必要对本篇书评所论的对象、以及该书的几个衍生版本向读者做一说明。该书首先出版的是2001年12月的英文版《Programming Microsoft Windows With C#》，后来由于考虑到C#和Visual Basic.NET语言相近的特点、以及广大Visual Basic.NET程序员的需要，Charles Petzold先生在所有主题内容没有丝毫变动的情况下将此书的代码和术语由C#全部换成Visual Basic.NET，随即又在2002年7月推出其姊妹书《Programming Microsoft Windows With Microsoft Visual Basic.NET》。《Programming Microsoft Windows With C#》目前在国内有两个版本，其一为世界图书出版公司于2002年6月出版的英文影印版，其二为北京大学出版社于2002年9月出版的中文版《Microsoft C# Windows程序设计》（天宏工作室翻译）。《Programming Microsoft Windows With Microsoft Visual Basic.NET》目前在国内还没有见到影印版，其中文版由华中科技大学出版社组织翻译。由于本文并不涉及具体编程语言，而且原作本身的主旨也不在具体实现语言，所以本文对这两本书的所有版本都将适用。特别要提醒读者注意的是，本文仅限于原书英文版的内容，而不会涉及中文版的翻译，读者不应该将本文看作是对中文版的评介——因为中文版不仅要看原来英文版的内容，很大程度上还要取决于中文版的翻译质量。
        本书的“宽度”
        我们知道微软为在Microsoft.NET平台上构建Windows桌面应用程序提出了一套全新的框架模型，这就是Windows Forms。本书的定位即在Microsoft.NET平台上如何构建Windows应用程序，自然它的所有内容都将围绕着全新的Windows Forms框架模型而展开。但是，不管Windows Forms框架模型怎样创新，一个典型的运行于Windows操作系统上的应用程序仍旧离不开Windows消息、图形界面、鼠标、键盘、菜单、控件、对话框、多线程等等这些基本课题。实际上Windows Forms框架模型就是利用Microsoft.NET平台中的互操作技术对传统Windows API的一个组件化的封装。了解了本书的主旨内容，我们就可以合理的提出我们的期望，并客观审慎地来评价本书的内容。
        我们首先从内容组织的“宽度”上来审视本书。从功能逻辑上我们可将本书的整个内容划分为4个部分：Windows Forms应用程序基本构造、新一代图形设备接口GDI+、基本控件使用介绍、语言与常用类型参考。四个部分中除了“语言与常用类型参考”外，其他三个部分都是Windows Forms框架模型的基本课题，都是不可缺席的内容。但是，仅有这些是否就够了呢？我们没有看到一些重要的、期望中的构建企业级桌面应用程序的课题，比如数据绑定、定制控件、文档/视图模型、单文档/多文档用户界面、Windows Forms多线程模型等等，令人倍感遗憾。当然，也许作者的目的并非要读者读完本书就能彻底通透地运用Windows Forms模型，并能轻松地创建具有专业水平的Windows Forms应用程序。也许作者的视角在于向读者展示一个完整的Windows Forms应用程序的结构。实际上，作者在本书开始的话似乎已经暗示了本书的重点在于帮助读者建立Windows Forms模型下编写程序的基本观念，而非构建复杂应用。
        本书的“深度”
        首先来看本书的第1个部分——Windows Forms应用程序基本构造，这部分包括了Windows Forms应用程序模型基本介绍、键盘、鼠标、时钟、菜单、对话框、打印、剪贴板共8个主题，这些都是构建一个典型的Windows Forms应用程序所要涉及到的基本要素。
        读者学习Windows Forms框架模型时一个最基本、同时也是最重要的问题便是“一个Windows Forms应用程序的基本结构是什么”。它是我们理解Windows Forms框架模型的基础，也是扩展Windows Forms框架模型的起点，要求这个本源性的问题在这本旨在讲述“Windows Forms应用程序设计基本观念”的书中得到解释不算为过。作者对这个问题当然有所触及，但是令人遗憾的是点到深处却戛然而止。作者并没有解答绝大多数读者运用Windows Forms框架模型时提出的一个基本而关键的问题：Windows Forms程序到底是怎样运行起来的——毕竟这种透过模型框架提供的表面服务来挖掘底层的API调用机制正是作者的专长，作为对Charles Petzold先生的期待并不过分，可是很多读者都要在此失望。类似这样的问题本章还有好几处。
        下面来看本书的第2部分——新一代图形设备接口GDI+。这部分的确是本书的一个亮点，对于那些希望用Windows Forms框架模型来制作丰富、专业的图形界面的读者来说，这部分是一个很好的起点。在笔者的印象中，Charles Petzold先生一直有着精湛的Windows图形、几何知识，将这些知识应用到GDI+的讲解中自然如鱼得水。GDI+当然不仅仅是一些图形、几何元素的堆砌，它本身也有一个非常良好的结构体系——有过传统GDI编程经验的程序员一定会对此感同身受，相对于“句柄”、“设备上下文”的应用体验，相信很多读者在领略了GDI+中的各种“对象”后一定会欢呼雀跃——本书这部分在讲解GDI+的对象结构方面也有上好的表现。另外，在娓娓道来技术知识的同时，这部分还穿插了大量生动翔实、深具教益的示例。
        再来谈一谈本书的第3个部分——基本控件使用介绍。这部分总体来讲比较平淡，偶尔有一些亮点，但也是点到为止，没有做深入的解析。如果读者先前看过Microsoft.NET框架SDK自带的“快速入门、教程和示例”中的“Windows 窗体快速入门”，那么应该对这部分内容比较熟悉，再来阅读本书的这部分内容收获不会太多。实际上读者在学会使用Windows Forms控件后，更希望得到关于控件的更深入的认识，可惜的是这些高级话题都没有如读者期望的那样在这部分得到详尽的解释，对于“定制控件”这个非常重要的课题，本书也只是在讲解其他课题时顺带地有所涉及，没有给予系统和深入的讲解，不能不视为遗憾。这部分唯一可圈可点的是作者选取的一些完整的示例，它们应该会为那些对于控件使用还不熟练的读者提供一个良好的模板范例。
        最后谈一谈本书的第4个部分——语言与常用类型参考，这部分包括第1章的编程语言介绍、以及附录A、B、C中的文件I/O、数学运算、字符串操作。笔者认为这些主题都不应属于本书的着力范畴，作为参考列出的必要性也不是太大。
        结语
        这本书可以满足不少没有面向对象观念的传统Visual Basic、C程序员的需要，比如怎样使用面向对象技术来创建Windows Forms应用程序、正确的处理事件、运用新一代GDI+模型、使用常用的控件、操作鼠标和键盘等等，本书对这方面的程序员有实质性的帮助——实际上可以说是相当好了。但这本书显然不能满足大多数从C++、Java领域转向C#的程序员的胃口。
        最后，笔者在此对于那些期望学习Windows Forms框架模型的读者给出关于本书（英文原版或者英文影印版）一个大胆的建议——中低级程序员需要仔细阅读本书、尤其是那些从Visual Basic转型到.NET（无论是C#还是Visual Basic.NET）上、面向对象观念还不成熟的程序员。但是对于高级程序员，尤其是已经有了比较成熟的面向对象观念的程序员，Windows Forms应用程序基本构造、GDI+模型、基本控件使用、.NET语言以及常用类型参考这些课题中除了有限的几个课题外，其他很多课题在本书中涉及的深度基本上都可以从Microsoft.NET SDK框架文档中轻松获得，购买此书的价值不是太大——当然，作为对Charles Petzold先生的尊敬，或者处于收藏目的则另当别论。对于已经学习过Windows Forms框架模型、又购买了此书的读者，精读、通读的必要性不大，最好把它作为某些课题（比如鼠标、键盘、时钟等）的针对性阅读来对待。当然，本书也才刚刚开始第一版，Windows Forms框架模型本身也还有很长的路要走，随着Windows Forms框架模型的成熟，我们有理由相信传奇作者Charles Petzold先生能够在本书未来的版本中再现昨日辉煌！

0

Firefox 3.0 Alpha 1 已经出炉!

点击此处开始下载 (官方连接)

0

网页 Meta 标记全面介绍

META标签是HTML语言HEAD区的一个辅助性标签，它位于HTML文档头部的<HEAD>标记和<TITLE>标记之间，它提供用户不可见的信息。meta标签通常用来为搜索引擎robots定义页面主题，或者是定义用户浏览器上的cookie；它可以用于鉴别作者，设定页面格式，标注内容提要和关键字；还可以设置页面使其可以根据你定义的时间间隔刷新自己,以及设置RASC内容等级，等等。
下面介绍一些有关 标记的例子及解释。
　　META标签分两大部分：HTTP标题信息(HTTP-EQUIV)和页面描述信息(NAME)。
※ HTTP-EQUIV
　　HTTP-EQUIV类似于HTTP的头部协议，它回应给浏览器一些有用的信息，以帮助正确和精确地显示网页内容。常用的HTTP-EQUIV类型有：
　　1、Content-Type和Content-Language (显示字符集的设定)
　　说明：设定页面使用的字符集，用以说明主页制作所使用的文字已经语言，浏览器会根据此来调用相应的字符集显示page内容。
　　用法：<Meta http-equiv="Content-Type" Content="text/html; Charset=gb2312">
　　　　　　<Meta http-equiv="Content-Language" Content="zh-CN">
　　注意：　该META标签定义了HTML页面所使用的字符集为GB2132，就是国标汉字码。如果将其中的“charset=GB2312”替换成“BIG5”，则该页面所用的字符集就是繁体中文Big5码。当你浏览一些国外的站点时，IE浏览器会提示你要正确显示该页面需要下载xx语支持。这个功能就是通过读取HTML页面META标签的Content-Type属性而得知需要使用哪种字符集显示该页面的。如果系统里没有装相应的字符集，则IE就提示下载。其他的语言也对应不同的charset，比如日文的字符集是“iso-2022-jp ”，韩文的是“ks_c_5601”。
　　Content-Type的Content还可以是：text/xml等文档类型；
　　Charset选项：ISO-8859-1(英文)、BIG5、UTF-8、SHIFT-Jis、Euc、Koi8-2、us-ascii, x-mac-roman, iso-8859-2, x-mac-ce, iso-2022-jp, x-sjis, x-euc-jp,euc-kr, iso-2022-kr, gb2312, gb_2312-80, x-euc-tw, x-cns11643-1,x-cns11643-2等字符集；Content-Language的Content还可以是：EN、FR等语言代码。
　　2、Refresh (刷新)
　　　说明：让网页多长时间（秒）刷新自己，或在多长时间后让网页自动链接到其它网页。
　　　用法：<Meta http-equiv="Refresh" Content="30">
　　　　　　<Meta http-equiv="Refresh" Content="5; Url=http://www.xia8.net">
　　　注意：其中的5是指停留5秒钟后自动刷新到URL网址。
　　3、Expires (期限)
　　　说明：指定网页在缓存中的过期时间，一旦网页过期，必须到服务器上重新调阅。
　　　用法：<Meta http-equiv="Expires" Content="0">
　　　　　　<Meta http-equiv="Expires" Content="Wed, 26 Feb 1997 08:21:57 GMT">
　　　注意：必须使用GMT的时间格式，或直接设为0(数字表示多少时间后过期)。
　　4、Pragma (cach模式)
　　　说明：禁止浏览器从本地机的缓存中调阅页面内容。
　　　用法：<Meta http-equiv="Pragma" Content="No-cach">
　　　注意：网页不保存在缓存中，每次访问都刷新页面。这样设定，访问者将无法脱机浏览。
　　5、Set-Cookie (cookie设定)
　　说明：浏览器访问某个页面时会将它存在缓存中，下次再次访问时就可从缓存中读取，以提高速度。

当你希望访问者每次都刷新你广告的图标，或每次都刷新你的计数器，就要禁用缓存了。通常HTML文件没有必要禁用缓存，对于ASP等页面，就可以使用禁用缓存，因为每次看到的页面都是在服务器动态生成的，缓存就失去意义。如果网页过期，那么存盘的cookie将被删除。
　　　用法：<Meta http-equiv="Set-Cookie" Content="cookievalue=xxx; expires=Wednesday, 21-Oct-98 16:14:21 GMT; path=/">
　　　注意：必须使用GMT的时间格式。
　　6、Window-target (显示窗口的设定)
　　　说明：强制页面在当前窗口以独立页面显示。
　　　用法：<Meta http-equiv="Widow-target" Content="_top">
　　　注意：这个属性是用来防止别人在框架里调用你的页面。Content选项：_blank、_top、_self、_parent。
　　7、Pics-label (网页RSAC等级评定)
　　　说明：在IE的Internet选项中有一项内容设置，可以防止浏览一些受限制的网站，而网站的限制级别就是通过该参数来设置的。
　　　用法：<META http-equiv="Pics-label" Contect="(PICS－1.1′http://www.rsac.org/ratingsv01.html’ I gen comment ‘RSACi North America Sever’ by ‘inet@microsoft.com’　for ‘http://www.microsoft.com’ on ’1997.06.30T14:21－0500′ r(n0 s0 v0 l0))">
　　　注意：不要将级别设置的太高。RSAC的评估系统提供了一种用来评价Web站点内容的标准。用户可以设置Microsoft Internet Explorer（IE3.0以上）来排除包含有色情和暴力内容的站点。上面这个例子中的HTML取自Microsoft的主页。代码中的（n 0 s 0 v 0 l 0）表示该站点不包含不健康内容。级别的评定是由RSAC，即美国娱乐委员会的评级机构评定的，如果你想进一步了解RSAC评估系统的等级内容，或者你需要评价自己的网站，可以访问RSAC的站点：http://www.rsac.org/。
　　8、Page-Enter、Page-Exit (进入与退出)
　　　说明：这个是页面被载入和调出时的一些特效。
　　　用法：<Meta http-equiv="Page-Enter" Content="blendTrans(Duration=0.5)">
　　　　　　<Meta http-equiv="Page-Exit" Content="blendTrans(Duration=0.5)">
　　　注意：blendTrans是动态滤镜的一种，产生渐隐效果。另一种动态滤镜RevealTrans也可以用于页面进入与退出效果:
　　　　　　<Meta http-equiv="Page-Enter" Content="revealTrans(duration=x,transition=y)">
　　　　　　<Meta http-equiv="Page-Exit" Content="revealTrans(duration=x,ransition=y)">
　　　　　　　Duration　　表示滤镜特效的持续时间(单位：秒)
　　　　　　　Transition　滤镜类型。表示使用哪种特效，取值为0-23。
　　　　　　　0 矩形缩小　　　　　　　1 矩形扩大
　　　　　　　2 圆形缩小　　　　　　　3 圆形扩大
　　　　　　　4 下到上刷新　　　　　　　5 上到下刷新
　　　　　　　6 左到右刷新　　　　　　　7 右到左刷新
　　　　　　　8 竖百叶窗　　　　　　　9 横百叶窗
　　　　　　 10 错位横百叶窗　　　　　　 11 错位竖百叶窗
　　　　　　 12 点扩散　　　　　　 13 左右到中间刷新
　　　　　　 14 中间到左右刷新　　　　　　 15 中间到上下
　　　　　　 16 上下到中间　　　　　　 17 右下到左上
　　　　　　 18 右上到左下　　　　　　 19 左上到右下
　　　　　　 20 左下到右上　　　　　　 21 横条
　　　　　　 22 竖条　　　　　　 23 以上22种随机选择一种
　　9、MSThemeCompatible (XP主题)
　　　说明：是否在IE中关闭 xp 的主题
　　　用法：<Meta http-equiv="MSThemeCompatible" Content="Yes">
　　　注意：关闭 xp 的蓝色立体按钮系统显示样式，从而和win2k 很象。
　　10、IE6 (页面生成器)
　　　说明：页面生成器generator，是ie6
　　　用法：<Meta http-equiv="IE6" Content="Generator">
　　　注意：用什么东西做的，类似商品出厂厂商。
　　11、Content-Script-Type (脚本相关)
　　　说明：这是近来W3C的规范，指明页面中脚本的类型。
　　　用法：<Meta http-equiv="Content-Script-Type" Content="text/javascript">
　　　注意：
※NAME变量
　　name是描述网页的，对应于Content（网页内容），以便于搜索引擎机器人查找、分类（目前几乎所有的搜索引擎都使用网上机器人自动查找meta值来给网页分类）。
　　name的value值（name=""）指定所提供信息的类型。有些值是已经定义好的。例如description(说明)、keyword(关键字)、refresh(刷新)等。还可以指定其他任意值，如：creationdate(创建日期) 、document ID(文档编号)和level(等级)等。
　　name的content指定实际内容。如：如果指定level(等级)为value(值)，则Content可能是beginner(初级)、intermediate(中级)、advanced(高级)。
　　1、Keywords (关键字)
　　　说明：为搜索引擎提供的关键字列表
　　　用法：<Meta name="Keywords" Content="关键词1,关键词2，关键词3,关键词4,……">
　　　注意：各关键词间用英文逗号“,”隔开。META的通常用处是指定搜索引擎用来提高搜索质量的关键词。当数个META元素提供文档语言从属信息时，搜索引擎会使用lang特性来过滤并通过用户的语言优先参照来显示搜索结果。例如：
　　　　　　<Meta name="Kyewords" Lang="EN" Content="vacation,greece,sunshine">
　　　　　　<Meta name="Kyewords" Lang="FR" Content="vacances,grè:ce,soleil">
　　2、Description (简介)
　　　说明：Description用来告诉搜索引擎你的网站主要内容。
　　　用法：<Meta name="Description" Content="你网页的简述">
　　　注意：
　　3、Robots (机器人向导)
　　　说明：Robots用来告诉搜索机器人哪些页面需要索引，哪些页面不需要索引。Content的参数有all、none、index、noindex、follow、nofollow。默认是all。
　　　用法：<Meta name="Robots" Content="All|None|Index|Noindex|Follow|Nofollow">
　　　注意：许多搜索引擎都通过放出robot/spider搜索来登录网站，这些robot/spider就要用到meta元素的一些特性来决定怎样登录。
　　　 all：文件将被检索，且页面上的链接可以被查询；
　　　 none：文件将不被检索，且页面上的链接不可以被查询；(和 "noindex, no follow" 起相同作用)
　　　 index：文件将被检索；（让robot/spider登录）
　　　 follow：页面上的链接可以被查询；
　　　 noindex：文件将不被检索，但页面上的链接可以被查询；(不让robot/spider登录)
　　　nofollow：文件将不被检索，页面上的链接可以被查询。(不让robot/spider顺着此页的连接往下探找)
　　4、Author (作者)
　　　说明：标注网页的作者或制作组
　　　用法：<Meta name="Author" Content="张三，abc@sohu.com">
　　　注意：Content可以是：你或你的制作组的名字,或Email
　　5、Copyright (版权)
　　　说明：标注版权
　　　用法：<Meta name="Copyright" Content="本页版权归Zerospace所有。All Rights Reserved">
　　　注意：
　　6、Generator (编辑器)
　　　说明：编辑器的说明
　　　用法：<Meta name="Generator" Content="PCDATA|FrontPage|">
　　　注意：Content="你所用编辑器"
　　7、revisit-after (重访)
　　　说明：
　　　用法：<META name="revisit-after" CONTENT="7 days" >
　　　注意：
※Head中的其它一些用法
　　1、scheme (方案)
　　　说明：scheme can be used when name is used to specify how the value of content should
　　　　　　be interpreted.
　　　用法：<meta scheme="ISBN" name="identifier" content="0-14-043205-1" />
　　　注意：
　　2、Link (链接)
　　　说明：链接到文件
　　　用法：<Link href="soim.ico" rel="Shortcut Icon">
　　　注意：很多网站如果你把她保存在收件夹中后，会发现它连带着一个小图标，如果再次点击进入之后还会发现地址栏中也有个小图标。现在只要在你的页头加上这段话，就能轻松实现这一功能。<LINK> 用来将目前文件与其它 URL 作连结，但不会有连结按钮，用於 <HEAD> 标记间， 格式如下：
　　　　　　　<link href="URL" rel="relationship">
　　　　　　　<link href="URL" rev="relationship">
　　3、Base (基链接)
　　　说明：插入网页基链接属性
　　　用法：<Base href="http://www.csdn.net/" target="_blank">
　　　注意：你网页上的所有相对路径在链接时都将在前面加上“http://www.cn8cn.com/”。其中

target="_blank"是链接文件在新的窗口中打开，你可以做其他设置。将“_blank”改为“_parent”是链接文件将在当前窗口的父级窗口中打开；改为“_self”链接文件在当前窗口（帧）中打开；改为“_top”链接文件全屏显示。

<head>　　
<title>文件头，显示在浏览器标题区</title>
<meta http-equiv="Content-Language" content="zh-cn">
　<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
　<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
　<meta name="ProgId" content="FrontPage.Editor.Document">
　<meta name="制作人" content="Simonzy">
　<meta name="主题词" content="HTML 网页制作 C# .NET JavaScript JS">
</head>

以上是META标签的一些基本用法，其中最重要的就是：Keywords和Description的设定。为什么呢？道理很简单，这两个语句可以让搜索引擎能准确的发现你，吸引更多的人访问你的站点!根据现在流行搜索引擎(Google，Lycos，AltaVista等)的工作原理，搜索引擎先派机器人自动在WWW上搜索，当发现新的网站时，便于检索页面中的Keywords和Description，并将其加入到自己的数据库，然后再根据关键词的密度将网站排序。

0

各系Rails大点兵

不知道明年今日，会不会出现一队只会用Ruby On Rails的毕业生，像当年的asp、jsp、php迅速剿了C++/perl的CGI那样，把我们给剿了。同好们劝我，根据大公司经济学，这基本不会发生。

在茫茫的框架之海认出一个Rails框架，基本上靠四个特征
1.一门动态语言
2.一个extreme simple to use的ORM框架
3.一个extreme simple to use的MVC框架
4.一些自动生成代码的命令、模版
其余ajax、web service、i18n等特性自由扩展

1.Ruby: Ruby on Rails
Rails系的旗手，一己之力搞得J2EE阵营鸡飞蛋打。
旗手的作用表现在：
*最接近1.0的版本，目前已出到最后一个RC版 1.0 rc4(0.14.3)
*拥有一本amazon超级畅销的《Agile Web Development with Rails》，而且这本书的组织也好，part I是一个渐进的sample application 让你快速入门，partII是几个重要领域的深入介绍。
*拥有自己的IDE: RadRails ，基于Eclipse但独立成军，目前出到0.5。(是不是怕惨了Eclipse的多变，现在这些IDE的发行版本开始反包含了Eclipse在内。)

2.Python: DJango、turbogears
认识不深，所以DJango请看limodou的blog，turbogears看xlp123的。

3.Groovy: grails
如果能顺产，绝对是J2EE阵营里感情分最高涨的项目。因为它语言用Groovy，ORM用annotation版Hibernate，MVC用Spring。不用担心它换汤不换药，因为经过extreme的封装，再结合Groovy，绝对不再是原来的Spring+Hibernate，而是和RoR差不多的一样东西了。不信可以看看他的Sample。
不过这个项目的源码目录树非一般的乱，也还没有0.1版释出。还有一样奇怪的事情，这个Groovy项目，大多数的class代码都是Java写的。

4.Php: symfony ,cake
据说cake比symfony弱非常多，所以没看。
symfonys是基于php5的项目，成功整合了Propel(ORM)、Mojavi3(MVC)，再配合自动生成的脚本打造而成。看他的sample，最后整合出来的东西也很Rails了，除了ORM层的xml文件。
还有一个发现是Php项目现在可以用pear来安装，很像Ruby的gem，Java的Maven要努力了。
C: />pear channel-discover pear.symfony-project.com
C: />pear install symfony/symfony
这样就装完了symfonys和propel&croel, mojavi3,还有用来运行脚本命令的pake(php make)，PHing(php ant?)，一大堆东西。

from :http://www.blogjava.net/calvin/archive/2005/11/22/20938.html
author:江南白衣

0

Rails RESTful (1) 什麼是REST?

Ruby on Rails 1.2 的一個重要進展是 RESTful，在了解怎麼用之前，我們要先了解什麼是 REST(Representational State Transfer)?

什麼是REST?

REST 是一種分散式超媒體系統(如WWW)的軟體架構風格，你可以想像它是一個良好設計的Web應用程式規則: 一組網路Web頁面(虛擬的狀態機器)，其中 Client 透過點選超連結(狀態變換)，結果是下個Web頁面(表示應用程式的下一個狀態)。

REST 所描述的網路系統包括三個部份:
data elements (resource, resource identifier, representation)
connectors (client, server, cache, resolver, tunnel)
components (origin server, gateway, proxy, user agent)

幾個重點:
Data elements 由標準化介面存取
Components 透過介面傳輸 資源表徵 (representations of resources) 來溝通，而不是直接操作資源本身。
Connectors 提供 component 的抽象介面來溝通，隱藏溝通機制的實作細節。
Components 使用 connectors 來存取，connectors 提供資源的存取或居中。
所有來自 connector 的 requests 必須包含所有必要的資訊來了解該 request，不需要依靠之前的request (即 stateless)

嚴格來說REST符合以下幾個條件:
應用程式的狀態跟功能拆成 resources
每個 resource 使用獨一無二用來當作超連結的通用定位語法(在WWW中即URI)
所有 resources 共用一致的介面在 client 跟 resource 之間轉換狀態，包括:
一組有限的良好定義操作 well-defined operations
一組有限的內容格式 content types,也許包括 可執行的程式碼 code-on-demand (在WWW中即Javascript)
這種通訊協定 protocol (在WWW中即用HTTP) 包含以下特色:
使用者端/伺服器端 Client/Server
狀態無關 Stateless
可以快取 Cacheable
分層的 Layered

符合 REST principles 的系統稱做 RESTful。

一般來說REST這個詞彙常被用來描述任何使用XML (or YAML, JSON, plain text) 的簡單介面，而不須靠其他機制(如SOAP)。另外 REST 雖然是個來自 WWW 的架構概念(比WWW晚)，但是這兩者並不是綁在一起，有可能設計一個大型軟體系統符合REST但是不用HTTP協定也不需跟WWW互動，也有可能設計一個簡單的 XML+HTTP 界面使用 RPC model 而不符合 REST principles。

Resources

REST的一個最重要的觀念就是 resources (特定資訊的資源)，每一個 resource 由一個 global identifier (即URI)所表示。為了操作這些 resources，網路的 components (即 clients 跟servers) 透過標準化的介面 (即HTTP) 來溝通並交換這些 resources 的 representations (即實際上傳達資訊的文件).

任意數量的 connectors (如clients, servers, caches, tunnels等) 可以居中 request，但是都不可以 “seeing past” (不需要其他 layer層)。這樣的應用程式跟一個 resource 互動根據兩件事情: resource的URI 跟 要做的動作 – 它不需要知道是否有 caches, proxies, gateways, firewalls, tunnels, 或其他任何藏在sever之間的東西。這個應用程式只需要知道資訊的格式 (representation)，通常是 HTML或 XML 或圖片什麼的。

REST 有什麼優點?
支援快取 caching 將改善反應時間跟server的負載能力。
因為不必維持連結狀態，大大改善 server 的 scalability 能力。這表示不同server可以處理同一串 requests。
一個瀏覽器就可以存取任一應用程式跟資源，client 端不需使用別的軟體。
在HTTP之上不依存其他機制跟軟體。
跟其他連結方式相比(如RPC)，可以提供相等的功能。
不需要其他的 discovery 機制，因為使用超連結了。
提供比RPC更好的長期相容性，因為 :
如同HTML這種文件具有後前及向後的相容能力
支援新的內容格式不需要丟掉舊的

另外比起RPC-style，URL command line 有極佳的 human-friendly 優點，容易 discovered/ transmitted /scripted/bookmarked 一個 URL。請參考 The Beauty of REST 跟 Tangled in the Threads 的優點介紹。

跟 RPC 的比較

跟 REST Web 應用程式對比的就是 RPC (Remote procedure call，實作上有XML-RPC或SOAP等) 了。RPC 應用程式曝露一或多個網路物件，每個有特定的 functions 可以呼叫。在 client 與物件溝通之前，它必須知道這個物件的知識來操作。

REST 的設計限制了 resource 的面向，它定義了介面 (動詞 verbs 跟內容型別 content types)，導致比RPC更少的型別，但是更多的resource identifiers (名詞nouns)。REST 的設計尋求定義一組 resources 讓 Clients 可以一致性的互動，而且提供超連結在資源之間可以瀏覽，而不需要了解整個 resources 的知識 。Server 提供的表單 forms 也可以被用在 RESTful 的環境來描述 clients 如何建構 URL 來跟特定的resource做溝通。

這張圖指出了REST的三位一體 : Nouns, 有限的 Verbs 跟 Content Types。

需注意的是，根據不同的用法要求跟效率，在不同的應用程式環境中，該使用哪種架構仍有很大討論的空間跟爭議(SOAP的支持者認為REST仍有其侷限，只適合簡單的應用)。REST的重要性在於它有個目前最成功的大型軟體架構應用: Wide World Web。RESTful 是 Web 的天性，也是讓 Web 成功的原因，因此 RESTful 的支持者認為使用 RESTful 架構就是 Web上最好的方法來做到有擴充性(scalable),彈性跟有威力的應用程式。在有這麼多複雜的RPC技術之後，REST因其簡單又有威力的架構近來越來越受到矚目跟重視。

舉例

一個 RPC 應用程式可能會定義以下的操作:

getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
listUsers()
listLocations()
findLocation()
findUser()

Client 的程式碼可能會這樣存取:

exampleAppObject = new ExampleApp(”example.com:1234″)
exampleAppObject.getUser()

在 REST中，重點在 resources(或稱作 nouns)的多樣性，比如說可能有以下的用法:

http://example.com/users/
http://example.com/users/{user} (one for each user)
http://example.com/findUserForm
http://example.com/locations/
http://example.com/locations/{location} (one for each location)
http://example.com/findLocationForm

Client 的程式碼可能這樣存取:

userResource = new Resource(http://example.com/users/001)
userResource.get()

每個 resource 擁有自己的識別名詞，而 Clients 從單一 resource 開始瀏覽，透過標準操作走訪 resource ，如 GET 下載，PUT更新，DELETE刪除，POST新增，注意到每個物件有自己的URL，而且可以容易被快取，複製跟書籤化(bookmarked)。

參考資源
Representational State Transfer
RestWiki
How to Create a REST Protocol

From :http://ihower.idv.tw/blog/archives/1542

0

Reactor模式和NIO

转至 www.jdon.com

注: 理解ACE中的Reactor模式,  高效的响应IO等事件.

当前分布式计算　Web Services盛行天下，这些网络服务的底层都离不开对socket的操作。他们都有一个共同的结构：
1. Read request
2. Decode request
3. Process service
4. Encode reply
5. Send reply

经典的网络服务的设计如下图，在每个线程中完成对数据的处理：

但这种模式在用户负载增加时，性能将下降非常的快。我们需要重新寻找一个新的方案，保持数据处理的流畅，很显然，事件触发机制是最好的解决办法，当有事件发生时，会触动handler,然后开始数据的处理。

Reactor模式类似于AWT中的Event处理：

Reactor模式参与者

1.Reactor 负责响应IO事件，一旦发生，广播发送给相应的Handler去处理,这类似于AWT的thread
2.Handler 是负责非堵塞行为，类似于AWT ActionListeners；同时负责将handlers与event事件绑定，类似于AWT addActionListener

如图：

Java的NIO为reactor模式提供了实现的基础机制，它的Selector当发现某个channel有数据时，会通过SlectorKey来告知我们，在此我们实现事件和handler的绑定。

我们来看看Reactor模式代码:

以上代码中巧妙使用了SocketChannel的attach功能，将Hanlder和可能会发生事件的channel链接在一起，当发生事件时，可以立即触发相应链接的Handler。

再看看Handler代码:

注意在Handler里面又执行了一次attach，这样，覆盖前面的Acceptor，下次该Handler又有READ事件发生时，将直接触发Handler.从而开始了数据的读　处理　写　发出等流程处理。

将数据读出后，可以将这些数据处理线程做成一个线程池，这样，数据读出后，立即扔到线程池中，这样加速处理速度：

更进一步，我们可以使用多个Selector分别处理连接和读事件。

一个高性能的Java网络服务机制就要形成，激动人心的集群并行计算即将实现。