我的程序员经历让我明白了一些关于软件开发的事情。下面是一些在编程中可能会让人感到诧异的事情：

• 一个程序员用了大约只用了10%-20%的时间来编码，而且大多数程序员，无论他的水平如何，其平均每天只有10-12行的代码最终会进入最终的软件产品中。这是因为，优秀的程序员会花费90%的时间来思考、调查、研究最佳的设计。而糟糕的程序员则会花费90%的时间来调试代码，并随意地改动代码并尝试让代码工作起来。

“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

“一个优秀的车工其工资是一个普通车工的好几倍，但是一个优秀程序员写出来的代码比一个普通程序员要值钱一万倍。——比尔盖茨”

• 一个好的程序员比一个普通的程序员多十倍的生产率。而一个优秀的程序员的生产率则比普通程序员多20-100倍。这并不是夸张（自从上世纪60年代的研究一直表明这是一个事实）。一个糟糕的程序员并不只是没有产出的——他们并不仅是完成不不工作，而且还会制造出大量的让别人头痛并要去解决的麻烦。

• 优秀的程序员花少量的时间写代码——那些代码都会出现在最终的产品中。那些花大量的时间写代码的程序员其实是很懒惰、很无知，或是很自大的，以至于不能使用已经存在了的解决方案来解决已有的问题。优秀的程序员精通于对通用的模式的识别和重用。好的程序员并不害怕持续地重构/重写自己的代码，直到达到最理想的方案。糟糕的程序员的代码基本上都缺少概念一致性，代码冗长，缺少层次和模式，所以，也就很难被重构。所以，重写他们的代码要比重构他们的代码要容易得多。

• 软件和其它一切事物一样，都遵循着一致性规则。持续得更改只会让软件变成一潭烂泥，其破坏了原始设计的概念一致性。软件产品变成泥沼是不可避免的事情，但是因为程序员不考虑软件概念一致性而导致软件产品更为快速地成为泥沼，这种速度快得可能 会在软件产品还没有完成时，软件产品已经变得没有价值。设计概念一致性的失败通常都会导致软件项目的失败（而第二大导致软件项目失败的原因则是发布的软件并不是用户想要的）。软件变成烂泥的速度正在呈指数级下降，太多的项目在被完结前都面临着激增的时间和成本。

• 一个 2004 研究报告 指出，大多数的软件项目 (51%) 都会在关键环节出问题。而15%的项目则是完全失败，当然，这比1994年有了很大的进步，当时完全失败的项目是是31%。

• 虽然，几乎所有的软件产品都有些开发团队，但其并不是民主的。通常，只有一个人负责设计，而剩下的人去实现细节。

• 编程是一个辛苦的工作。其是一个巨烈的脑力劳动。好的程序员24×7地在思考他们的工作，他们一般都在在洗澡和梦中编写软件中最重要的代码。因为最重要的工作只能在键盘之外完成，软件项目不可能因为加班或是加人来加快进度。

文章来源：http://dotmac.rationalmind.net/2010/08/some-lesser-known-truths-about-programming/

今日，将我编写的S2SH DWR项目移植到weblogic11上，遇到一大堆的问题，但都被我一一解决。现将碰到的问题，汇总如下。

首先在oracle网站上下载weblogic11R1,然后安装上。注意，安装时带上eclipse插件。这个插件可以单独运行，是个集成了weblogic server配置的eclipse.运行eclipse，新建server 并配好。

建好Weblogic域后，就可以运行了，注意建域的时候，要选择开发模式。如果选择生产模式，在最后封装成自启动系统服务时，会失败。为了兼顾稳定，JDK可以选择生产模式的JDK。然后就可以用eclipse打包发布了。

1、首先碰到的是打包后不能运行的问题，解决方法如下，将打包后的文件解压，成为一个目录。然后以目录的形式在Admin Server Console中安装。就能解决这个问题。另外，如果发布后想以更改上下文根，可以在部署后，更改，如改为 / ，之后，会出现上下文 （未指定值），这样就是以网站根发布了。

2、字符集问题。在Jsp中pageEncoding选择GBK,但是content中的charset一定是utf-8。然后原有的工程的WEB-INF下建立weblogic.xml文件。文件头可以到安装目录的例子里去找。然后加上

<wls:charset-params>
        <wls:input-charset>
            <wls:resource-path>/*</wls:resource-path>
            <wls:java-charset-name>utf-8</wls:java-charset-name>
        </wls:input-charset>
    </wls:charset-params>

并且将web.xml中spring的转码设为GBK

<filter-name>encodingFilter</filter-name>
    <filter-class>
    org.springframework.web.filter.CharacterEncodingFilter
   </filter-class>
    <init-param>
      <param-name>encoding</param-name>
      <param-value>utf-8</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

如果这样，可能出现一些js文件失效的情况，可以将js文件用记事本打开，然后另存为utf-8编码，就能解决了。

3、加载HIbernate文件时，出现错误。HqlToken的错误。原因是antlr-2.7.6.jar与weblogic的自带的冲突引起的。解决办法在weblogic.xml里加入

<wls:container-descriptor>
        <wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
    </wls:container-descriptor>

让weblogic优先使用工程自带的包,这个方法要加在字符集之前。

注意此处网上还有一种解决办法，即在用户自定义域环境变量里添加pre classpath.这种方法虽然以控制台启动不报错。但是制作成自启动系统服务后，仍然会出现Hibernate的错误。

4、系统集成了DWR，会在使用时报CSRF错误。需要在web.xml文件里关于dwr的配置修改为如下

<servlet> 
      <servlet-name>dwr-invoker</servlet-name> 
      <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class> 
      <init-param> 
             <param-name>debug</param-name> 
             <param-value>true</param-value> 
      </init-param>
      <init-param>
             <param-name>crossDomainSessionSecurity</param-name>
             <param-value>false</param-value>
      </init-param>
      <init-param>
            <param-name>allowScriptTagRemoting</param-name>
            <param-value>true</param-value>
      </init-param>
</servlet>

变红的部分是新加上去的。这样就不会出现跨域访问安全的问题了。

5、在Tomcat下，引用另外一个jsp的时候正反斜杠是不区分的。但是到了weblogic下，会报文件找不到的情况。将 \ 改为 / 即可。

6、我单位上使用的是ISA2006，在ISA里要将以前的专门的发布网站协议去掉，然后自己新建一个普通的访问协议即可。否则会出现端口占用的情况。

7、最后是制作成自启动系统服务。在weblogic安装目录下，找到wlserver_10.3\server\bin下的installSvc.cmd文件。在"%WL_HOME%\server\bin\beasvc" -install -svcname:"beasvc %DOMAIN_NAME%_%SERVER_NAME%" -javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%" -maxconnectretries:"%MAX_CONNECT_RETRIES%" -host:"%HOST%" -port:"%PORT%" -extrapath:"%EXTRAPATH%" -password:"%WLS_PW%" -cmdline:%CMDLINE%

之前加上

set PRODUCTION_MODE=true
set DOMAIN_NAME=base_domain
set SERVER_NAME=AdminServer
set USERDOMAIN_HOME=C:\Ora\user_projects\domains\base_domain
set WLS_PW=xxxxxx

在命令行执行后就可以了。

删除服务用uninstallSvc.cmd,在执行之前先设好

set DOMAIN_NAME=base_domain
set SERVER_NAME=AdminServer

以上就是我在移植时碰到的问题。如有其它问题，请大家一起探讨。

作者: Uwe Hesse, 译者: Jametong
Oracle高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖"普通的"单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为"伸展集群").Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构(Maximum Availability Architecture,MAA).除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring).我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷.
首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库.一个Oracle数据库总是由一个数据库(由数据文件,在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区;以及后台进程,例如数据库写进程)组成.如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC.如果只有一个实例访问这个数据库,就是单实例数据库.下图是一个所有组件都存储在一个服务器上的简单安装版本:

将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:

从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障.从而这些服务器所在的站点也是单点故障.这样,只要其中一个单点发生故障,整个数据库将不可用.一个"普通的"RAC就是为了解决其中的服务器单点故障的,如下图所示:

如果两个服务器的其中一个发生故障,数据库C将仍然可用.当然,使用RAC并不仅仅是为了实现HA.在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决.另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance).简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了.从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点.如果站点C发生故障(比如火灾),数据库C将不可用.因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC.

现在,这两个站点就不再是单点了.数据库D是在两个站点之间做镜像的.这个架构的缺陷是两个站点之间的网络连接的成本,如果两个站点之间的距离比较远的话.这很关键,因为需要镜像的数据量会非常大.实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突.这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志.在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:

备用数据库由来自主数据库的重做日志. 当主库发生故障时,我们可以失败切换(Failover)到备库上并继续有效工作.这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换,Fast-Start Failover)自动实现.两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别(protection level)).如果我们将RAC与Dataguard集合起来,我们就实现了MAA.显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处.
远程镜像是一个广受欢迎的第三方HA解决方案.总体上,它的架构与下图类似:

这时,也没有哪个站点是单点的,类似于使用扩展RAC架构.这个解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似.同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同.使用RAC时,所有的服务器与相应的站点都可以提供服务.哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障.除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载.

上图展示了Oracle 11g的新特性"物理备用数据库上的实时查询".在恢复过程中时,备用数据库也在同时提供只读访问.另外,还可以在物理备库(Physical Standby)上做离线备份(OffLoad Backup).

附注:
其实还有另外一种可选择的架构. 基于Data Guard与单实例的一个结合.
类似于上面介绍的远程Data Guard方案, 做了一点修正: 将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时).