IT笑话若干

这些笑话，可能并不算真正的笑料，毕竟是我生活中实际遇到的故事，并不夸张。不过，还是有很多可反思的：

笑话1：

某小伙子，湖南某计算机大专毕业，技能尚可，很能说，所以薪水也巨高。优点是特别自信，不过，缺点也是，看不到自己的缺点和不足，就是看到了，也要掩饰。经典名言：跟IBM的人在一起，你首先在气势上要压倒他。（佩服阿，这原本是我的作风）

不过，最经典的名言是：我们那个学校，在计算机上面的水平，那个高啊，可真没得说了，就是清华大学，也比不过的。

我当时很想喷他，但还是忍住了，想我这么狂妄之人，也只曾说过：我比某个清华的人要厉害多了。还不至于说，我的大学要比清华厉害很多阿。事实上，若论知名 度，俺的大学跟清华多少也算大哥小弟吧，N年前还可以华山论剑呢（吹吹水），而估计10亿中国人，就那么几万人知道他的那个大专：当然都是跟这个学校相关 联的人拉。

笑话2：

某领导，算是华南某大型软件公司的技术领头人拉，某次会议，他又强调他的测试观点了：本季度还是要做UI测试自动化的，要不，这么多测试的兄弟，整天重复体力劳动，怎么可以提高呢？

兄弟向来只来直往，凭着对现有系统的了解（代码质量那个差阿，一定跟全中国的软件水平匹配得起来），什么单元测试都没有，整个系统就像一个3年没清洗的厨 房，大小蟑螂成千上万，随手可以拍死一堆。（不过，技术人员倒是可以持续忙碌了），就这么个水平，要做UI的自动化测试，就跟我现在想编个程序，控制一下 我的那部遥控车，整天到我的厨房瞎撞差不多，说不定也能碾死几只蟑螂啊。于是，就说了：这样做不会有任何效果，只是浪费时间。

下面的兄弟可能觉得我这样说太不给面子，于是，圆圆场：也不能说一点效果都没有，还是会有一点效果的。

于是，我只有认个错：那是当然，只要努力找，还是应该能找到一点价值的。

最后，领导总结：我知道，技术人员都很牛，是很难管理的。

晕倒。

Learn JAX-WS Spec

• WSDL 1.1 to Java mapping

• wsdl:definitions JavaPackage
  
• wsdl:portType JavaInterface @WebService @SoapBinding
  
• wsdl:operation JavaMethod @WebMethod @WebResult @WebRequestWrapper @WebResponseWrapper @WebParam @WebFault
  
• wsdl:Message JavaParameter/Return and JavaClass
  
• wsdl:part follows JAXB2 spec
• wrapped style/non-wrapper style
  

• Annotations

@Target({TYPE})
public @interface WebService {
  String name() default "";
  String targetNamespace() default "";
  String serviceName() default "";
  String wsdlLocation() default "";
  String endpointInterface() default "";
};

@Target({METHOD})
public @interface WebMethod {
  String operationName() default "";
  String action() default "" ;
};

@Target({METHOD})
public @interface Oneway {
};

@Target({PARAMETER})
public @interface WebParam {
  public enum Mode { IN, OUT, INOUT };
  String name() default "";
  String targetNamespace() default "";
  Mode mode() default Mode.IN;
  boolean header() default false;
};

@Target({METHOD})
public @interface WebResult {
  String name() default "return";
  String targetNamespace() default "";
};

@Target({TYPE})
public @interface SOAPBinding {
  public enum Style { DOCUMENT, RPC }
  public enum Use { LITERAL, ENCODED }
  public enum ParameterStyle { BARE, WRAPPED }

  Style style() default Style.DOCUMENT;
  Use use() default Use.LITERAL;
  ParameterStyle parameterStyle() default ParameterStyle.WRAPPED;
}

Learn Java2D

如果能够在无聊的时候,静下心来学习学习，总是会有收获的。可惜，年纪大了，心却还是没法静下来。最近，看了看 2D 方面的一些文档、代码，对2D有了一些基础的认识。

比较好的Java2D的教材：http://java.sun.com/docs/books/tutorial/2d/index.html

在2D中，主要的概念包括：

• Stroke：用于绘制Shape的外形，包括线宽、样式等。
• Paint：用于填充 Shape，Color，GradientColor、Texture等几种Paint形式。
• Composite：用于定义多种形状覆盖时的行为
• Transform：对基本形式进行变形的技术
• Clip：定义对图形的剪裁
• Font：也可以理解Font是一种图形形状的定义。

Java2D基本上是一种PureJava的2D图形实现，采用了Pipe技术，最终产生一个 raster 的图像，这个图像可以在普通的图形环境中显示。本质上，Java2D就是把逻辑世界上的一些图形对象映射到一个raster的光栅世界中，前者是人理解和 使用的语言，后者则是显示器的方式。从这个角度上来看，Java3D（OpenGL)等本质也是如此的。

后来，又察看了已下 SVG 的相关规范，SVG与Java2D在概念上基本一致，而且完全可以在Java2D的基础上进行（不知道batik实现是不是基于Java2D的）。但 SVG把Java2D的概念从Low level的API提升到了一个更高的层次，使用DOM（对象）来表示了一个2D的世界，因此，也可以通过脚本对对象的操作来实现交互、变化的2D世界， 而Java2D则紧紧是在API层次，这些图形的对象也是一个非常暂态的，是使用代码而不是数据来表示2D。

那么，SVG技术可以如何反过来应用到GUI程序中呢？这里仅仅是我的一些很初步的想法：

1. 在Swing的L&F中，可以直接使用外部的XML来配置L&F，这个就是现在的Synth的基本概念。
2. 可以使用SVG来定义render。这里包括样式和render两部分，后者的动态性更强，更为复杂，也提供更灵活的功能。完全可能将原来在Java中通过代码来完成的功能，通过SVG来进行render。
3. 可以采用一些优化的技术，例如，优化的编译技术，可以自动的把SVG编译成为Java2D的调用，从而提高render的速度，并降低对象所 占用的开销，或者对一些render采用cache处理，可以预期在性能上可以满足用户需求。但是，可以通过外部的工具，来对这些SVG进行配置（尤其是 提供WYSIWYG的可视化效果，从而让美学专家来定义显示效果）

在样式方面，所有的GUI组件都可以借鉴Java2D的概念，例如，background，不仅仅可以是颜色，而且可以是Texture、 GridentColor等，同样显示也可以是透明的。单单如果能够让所有的按钮都能配上一个好的背景图案，我觉得UI的效果就会完全不同。

google的 ajax-xslt 源代码

http://goog-ajaxslt.sourceforge.net/

google 最近将其部分ajax源代码Open出来，或许我们在后续的一些开发商，可以使用这些技术。

通过使用 XSLT 技术，我们可以进一步的实现以数据（基于XML）为中心的用户界面。

以数据库的 CRUD 模式为例，我们可以在后端定义一个 SOAP 服务，在ajax中，可以直接进行基于一个数据模型的查询（类似于ADO.MD的API），返回一个DataSet后，可以利用 XSLT 将其翻译成用户界面。

浅谈Hibernate获得成功的十大理由

转载：CSDN，确实，这些都是我们做产品应该借鉴的。这里没有太多的技术和方法，但却跟技术的结合远远的大于所谓的软件过程。

下面是对Hibernate开发工作的个人想法，正是这些工作使得Hibernate如此迅速的得到广泛的欢迎。

1、飞快的版本发布

保持活跃的开发速度，经常进行版本发布，甚至几天 之内就从前一个版本开发到下一个版本。这样是保证软件远离Bug的最好的办法，也可以让用户感到很放心，确信Hibernate的开发十分活跃，另外这样做也有一大好处，就是可以发现哪些功能是用户真正需要的。

2、回归测试

我想现在整个Java社区一定都很重视自动回归测试。如果软件的功能和设计有比较大的修改，那么一个综合性的test suite对于软件可维护性和稳定性来说实在是太重要了。我们应该有这样的意识：如果对软件的一个新功能没有进行回归测试，我们根本就不该去做它。

3、把一个功能做到最好

要么不做，要做，就一定做到最好。那些我们做不到最好的功能，我们根本不去做，扔给其他软件去做吧。

4、避免过度设计

浪 费大量的时间和精力进行软件功能的抽象和扩充软件的灵活性，还不如多花点时间来解决你的用户面临的实际问题呢！简单一点，软件最重要是运行起来，不要尝试 去解决你的用户根本不关心的问题。就算你的软件设计的不够优雅也没有关系，反正还是initial阶段。以后还可以再refactor，你应该关注的问题 是及时的把有用的功能给做出来。

5、集权

在你需要由民主投票来下决定之前，至少你已经把软件轮廓做好了。软件开发需要由 一两个开明的人来领导，这样可以保证软件开发的连贯性而不至于产生太大的分歧，可以保证开发团队集中火力把要实现的功能做到最好。我觉得，OSS软件最大 的风险就是意见不统一，摊子铺的太大，结果最后搞的什么都没有做好。

（译者按：非常赞同，凡是成功的OSS软件，都是在某个人已经把软件做好了之后，发布出来，然后由大家往里面添加功能的，并且在这个人的领导下不断进步。缺乏此人的OSS软件都不算很成功，比如Mozilla）

6、文档

没有什么比文档更重要的了。如果你的用户不知道你的软件有这么一个功能，就等于没有这个功能，干脆把它去掉得了，省得给源代码增加复杂度。

7、避免标准化

好的标准可以带来软件的互用性和可移植性，坏的标准能够窒息软件创新。最好的软件是在不断的尝试，不断的出错，不断的经验积累的过程中产生的。事实上的标准往往更加贴近用户需求。

8、10分钟之内把Hibernate跑起来

潜在的Hibernate的用户在他们下载了Hibernate，第一次使用的时候根本就不可能花半个小时那么多时间来安装、配置和 troubleshooting，他们早就丧失了对Hibernate的兴趣了。

我们的口号就是新用户（假设有足够的JDBC知识）5分钟之内把 Hibernate的Demo跑起来，而他们能够在1个小时之内写出"Hello World"式的最简单的Hibernate程序并且正常运行。

9、开发人员的责任感

用户总是不可避免的碰到问题，开发团队有责任有义务提供帮助。用户让我们知道了文档的漏洞，用户让我们知道了测试用例的小bug。此外，没有用户来用我们的Hibernate，我们还开发它做什么，不是浪费时间吗！

有 个关于bug的笑话：用户根本不介意发现新功能的bug（译者按：Windows的用户好像都是如此），只要你能迅速的改掉bug。"责任感"意味着 bug修复应该在1周之内。从收到bug报告到bug修复代码提交到CVS上要做到平均在24小时左右，这才是一个理想的目标。

10、易用的、可更新的wiki网页

关于数据库技术的一些想法

1、条件索引。

create index gz_people on peoples(name) where city = 'gz'

这种索引的最大特点是并不对数据库中的所有记录都进行索引，而只对符合条件的记录进行索引，当符合条件的记录仅仅是全部记录的一个较小的子集时，这个索引可以使用更小的存储空间，而且在其他记录（不符合这个索引的过滤条件）进行更新的时候，也无需更新索引。

典型的应用场景：对于OLTP类型的数据库，最近修改的记录总是最为频繁的。假设我们想把所有的记录同步到另外的一个数据库中，这样就需要跟踪最近的修改 记录。我们可以在数据库上添加一个Synchronized标志，新增加（修改）的记录为false，而已经同步的记录为true。在大部分的情况下，记 录时同步的。如果对这个字段进行索引，索引非常巨大。通过条件索引（在这种情况下，甚至可以结合位图索引），索引规模大为减小。

进行查询时，当且仅当当前查询具有与这个条件索引相同的过滤条件时，才使用此索引，此时，可以从查询条件中剔除这些过滤条件，而在此索引上进行进一步的定位（甚至是基于索引的遍历），当查询需要对索引字段进行排序时，使用效率是最高的。

2、编译技术。
SQL的查询简单情况下，最适合使用解释的方式进行执行，包括：select表达式的求值，决定选择哪个索引等。但是否可以使用编译技术呢？通过将SQL 编译成为一个可以直接运行的代码，在编译的过程中，交织各种优化技术，把原有的解释型执行过程转变成为一个直接执行过程。

采用编译型技术肯定会复杂一些，但这个过程理论上可以让计算机自己来做，而且只要能够获得性能的提升，又不增加人的工作量（自动化），这种复杂性肯定是值得的。
在这里，编译与解释的本质区别是什么呢？解释执行，存在着一个取码、解码、执行的过程，而编译执行时，所有的取码、解码工作已经由编译器展开了，只需要直 接执行就可以了。（JVM中原有的对字节码解释执行，采用 switch(code){...} 的方式，可以理解为解释的过程，取码、译码，而采用thread技术，预先将所有的字节码对应的执行地址存放在一个数组中，然后直接顺序执行。在 SabeVM中，采用这种优化技术，号称可以把执行速度提高几倍呢）。

最重要的，编译技术并没有加大应用代码的复杂性，即使只获得10%的性能提升，在数据库这样的场合下，也是完全值得的。

CCW：CMM改善不了软件的质量

CCW 6-20的应用与方案版中刊登了对Ivar Jacobson的采访，Ivar算是妙语连珠。其中，提到：

如何检测一个软件过程是好是坏呢：第一：坏的过程关注文档，而好的过程关注在可执行程序或者系统上。第二：坏的过程延误了揭露风险的时机，而好的过程则已 开始就把自己暴露在风险之下，及时解决。第三，坏的过程在项目的最后才能验证质量，而好的过程每时每刻堵在进行质量的验证工作。第四，坏的过程有一个非常 复杂的跟踪关系矩阵，从需求到代码需要一个非常复杂的过程，而好的过程，则是一个无缝连接。第五，坏的过程面对变更非常脆弱，而好的过程则建壮的多。

其实，个人认为，这些比较确实是一个很好的可以量化的手段，但还是要回归到本质上来，那就是"过程"是质量的一个辅助，而技术和人则是质量的根本保证，偏 离了这个原则，期望通过规范化的流程、文档和管理来保证软件的质量，只能是本末倒置。什么样的情况会导致这种倒置呢？那就是这个公司、项目对于技术、质量 的热忱文化，让一个整天乐乎于开会、做思想工作、思考人际关系的人来负责项目、产品甚至公司的研发，而这样的人甚至自己都写不好代码，做不好需求、测试等 基层工作，那么他还能干什么？只好去整天拿"过程改造"来说事了。

Ideas on Swing & UI

我对Swing没有过深入的研究和学习，也很少编写Swing的应用程序。对于SWT来说，也是如此。但我从感觉上，总觉得SWT很别扭，姑且不说SWT 的那一套 style bit mask，明显的是早期 C 程序的痕迹，从核心实现的角度来看，SWT就缺乏Swing的那种气度，什么东西都依赖于所谓的native世界，在不同的平台上，移植的工作量，以及由 此带来的复杂度并不会见到就比全部重新使用Java来渲染一套组件要简单。

或许，在刚开始的时候，SWT可以快速速成，毕竟只需要对native进行封装就可以了，而Swing则不然，要把Windows等这么多年发展而来的 UI从零开始，除了工作量大，而且一开始效果也比较差，尤其是对于UI这样一个用户非常敏感的区域，所以，在Java的世界中，总是由那么多的对 Swing用户界面不满的呼声：Swing速度慢、用户界面别扭，等等不一而足。

然而，就像 Windows 也是从 Windows 3.1发展起来的一样，Swing 的用户界面总是可以向 native 无限靠拢，甚至超越的，尤其是在即将来临的3D世界，一个Pure Java的UI将快速的将native的UI抛在后面。

其实，Swing中抱怨最大的，应该是它的Look&Feel部分，客观来说，Swing自带的Meta L&F的效果确实比较糟糕，只能算是一个 L&F 的参考实现。做一个漂亮的L&F，其实不是什么技术难度的问题，而是美学设计的问题，估计Swing小组的专家们，技术专家比美学专家要多。（在 几乎所有的UI世界里，程序员都很难做出漂亮的UI来的，这也正是为什么WEB界面是那么的成功，因为WEB界面大部分是一般不需要软件技术的WEB工程 师的杰作，程序员仅仅是隐藏在UI的后面的）。

在Java5中，新增加了一种 L&F ，名之为：Synth。 这种L&F就是一种可以配置的，这种配置可以在一个工具的支持下，让具有美感的人来进行。其实，这种方法是技术与美学的最佳结合，让有美感的人来 写L&F，要求太高，让会写技术的人来做L&F，可行性也太低。而设计一个可以配置的L&F，所有的美术上的东西，以配置的形 式，交给美学工程师来进行，这里面，主要也就是类似于HTML世界中的css的工作：色彩、字体、背景、边框，等等。已经有一个 XUI 的框架，可以让UI工程师，使用SVG来进行一些渲染的配置。这应该是一个很有刺激性的发展方向，因为，借助于SVG的强大渲染能力，组件可以提供更复 杂、灵活的L&F，而且，这是以一种美学专家所擅长的方式来进行的。

或许，Java5还应改从CSS中借鉴一些有价值的地方，包括：

• 更为一致的样式配置。基本上，所有的组件都可以使用一致的方式来进行样式的配置。而且这种配置可以与UI高度的独立。设想，软件工程师提交一个UI，你可以通过对其进行重新的Layout、设置style来对其进行美化，那么，要做一个漂亮的UI应用应该也不是一件难事。
• CSS的cascade功能，使得你可以灵活的定义任何对象的显示样式，这一点，与 Motif 编程中的外部资源配置文件有非常相似的地方，只是更为规范化、开放一些。

同时，Swing作为一个低层的UI框架，从应用的角度来看，我们还是需要一个类似于 XUL + XHTML + SVG 之类的基于XML的，支持Javascript等脚本语言的应用模式（我以前写过这些主题的Blog)，从而将UI的工作可以更为充分的交给UI工程师来 完成，这就要求有类似于Firefox这样的技术支持，包括 WYSIWYG 的编辑器、Javascript调试器、DOM察看器等。让一个UI的程序总是可inspect的，可control的。

我也准备在后续的工作中，多花点时间来学习学习Swing、UI方面的知识，了解Swing的结构，了解UI的技术，包括Java2D等技术。

处理 JDK 源代码，进行格式化和提供调试支持

<?xml version="1.0"?>
<project name="project" default="build-debug-jre">
<description>
compile the JDK's source with debug option.

the JDK's rt.jar is compiled without debug information, which makes
debug ineffictive.
</description>

<property name="jdk.dir" value="d:/java/jdk1.5.0" />
<property name="jdk.src.dir" value="${jdk.dir}/src_fommated" />
<property name="jdk.class.dir" value="${jdk.dir}/classes" />

<target name="compile">

<mkdir dir="${jdk.class.dir}" />
<javac srcdir="${jdk.src.dir}"
destdir="${jdk.class.dir}"
debug="on"
source="1.5"
target="1.5"
memoryinitialsize="128m"
memorymaximumsize="512m"
fork="true"
>
<exclude name="com/sun/corba/se/spi/costransactions/TransactionService.java" />
<exclude name="com/sun/org/apache/xalan/internal/xsltc/trax/SmartTransformerFactoryImpl.java" />
<exclude name="com/sun/org/apache/xerces/internal/impl/xs/psvi/PSVIProvider.java" />
</javac>

</target>

<!-- we dont compile it in ant, instead, we build using eclipse -->
<target name="build-debug-jre">

<echo message="prepare directory ..." />
<delete dir="${jdk.dir}/debug-jre">
</delete>
<mkdir dir="${jdk.dir}/debug-jre" />

<echo message="copy standard jre" />
<copy todir="${jdk.dir}/debug-jre">
<fileset dir="${jdk.dir}/jre">
</fileset>
</copy>

<echo message="unzip old rt.jar" />
<mkdir dir="${jdk.dir}/debug-jre/rt_jar" />
<unzip dest="${jdk.dir}/debug-jre/rt_jar" src="${jdk.dir}/jre/lib/rt.jar">
</unzip>

<echo message="replace with new classes" />
<copy todir="${jdk.dir}/debug-jre/rt_jar" overwrite="true">
<fileset dir="${jdk.class.dir}" />
</copy>

<echo message="zip the rt.jar" />
<zip destfile="${jdk.dir}/debug-jre/lib/rt.jar" compress="false">
<fileset dir="${jdk.dir}/debug-jre/rt_jar" />
</zip>

<echo message="zip the src.jar to the jre directory" />
<zip destfile="${jdk.dir}/debug-jre/src.zip" compress="true">
<fileset dir="${jdk.src.dir}">
</fileset>
</zip>

<delete dir="${jdk.dir}/debug-jre/rt_jar">
</delete>

<echo message="Debug JRE build on ${jdk.dir}debug-jre" />

</target>

</project>

JDK 中的源代码是没有进行代码格式化的，在阅读时，有点费劲。此外，rt.jar 中不包含符号信息，在进行源代码调试时，一旦调试进入JDK的源代码，就无法进行察看变量等调试信息，很不方便进行调试工作。

为此，我对JDK的源代码进行如下处理，以方便进行阅读和调试：

1. 使用eclipse IDE
   
2. 新建 一个 java 项目
3. 将 $JDK/src.zip 展开
4. 在 eclipse IDE 中加入该源代码目录
5. 编译可能会存在一些错误，在我的环境中，有接近10个编译错误，和上万个警告。（但还算非常顺利，证明了eclipse的JDT编译效率和质量都相当不错），这些报告的错误是本来就存在的，暂时忽略。
6. 在eclipse中选择对包进行 Format。我把 Format Comments 选项去掉了，只格式化源代码。（由于eclipse中格式化智能对选定的包进行，要对整个项目进行格式化，可以选择整个源代码目录）
7. 然后再打包一个 DEBUG-JRE 目录，与标准的 jre 目录/文件完全相同，但rt.jar、src.zip 已被替换，在eclipse中加入进来。

使用 eclipse 进行编译的class在实际运行中好像还是有些问题，会产生一些 IllegalAccessError的运行时错误，这个错误在我使用 javac 来进行编译时，总算是成功解决。 build.xml 为以后进行类似的工作提供了基础。

这样制作出来的JDK自然可以大大的加快学习JDK类库的速度和调试速度，起到事半功倍的作用。

AJAX 中的数据库组件

1、定义数据库的元信息。

2、数据库的元信息可以使用 XML 来表示，并映射成为 JavaScript的对象模型，这样，就可以在 AJAX 中方便的使用。

3、提供 Data Set 的XML表示，可以用来封装数据，用于在AJAX中进行传递。并且有对应的 JavaScript 映射，便于在AJAX中处理。

4、Data Set 提供类似于 ADO.NET 或者 SDO 的功能，在浏览器端，可以对 Data Set进行修改，修改后，提交到服务器上进行保存。

5、UI 组件模型

a)      大部分的UI组件都设计成为MVC模式，且不依赖于DataSet，而是通过UI适配的Model来定义。

6、DataObjectService ：

a)      根据定义的元信息提供Service。

b)      开发成为Web Service，提供 Java/Soap 的映射。

c)      可以在 AJAX 中直接调用。

7、开发模式：

a)      基于 POJO 模型，采用 Java 5 Annotation来进行元信息定义。

b)      可以直接利用 Hibernate 等的annotation基础，来定义DataObject。或者采用XML来进行。

有这样的部门领导,够你受的

前几天,偶然听到一位部门经理跟他的上司(或许也不算他的上司)，抱怨他手下的人，除了工作态度不成，就是能力也很低，还总想着蒙他一把．然后又总结一 下，这怎么可能蒙得住我呢，我随便找一个人来，就证实了他们的错误．呵呵，他那个语气，显然是对他的下属们很大的不满，所以，我也有点怀疑他们那个团队可 能是一个很不协调的团队．

其实，这个小组也就4个人，除了这个经理之外，另外3人都是程序员，资历可能都差不多，都是好些年的程序员了。最近，在忙乎一个数据仓库的研发任务，领导 于是让这3位霸住公司的一个会议室，好搞封闭式的开发了。而自己呢，则独立办公，偶尔过问一下，基本上就是检查工作，下达指令了。（其实，这3个人的办公 环境相当宽裕，反之，呆在那个小的会议室里，反倒又挤又小）。

又过了几天，这个团队又碰到了一些技术问题，我上去凑凑热闹，又听到了这位经理在点评：这个问题怎么就解决不了呢？你们就不知道想象办法？不行的话，加班 也要搞定阿。那般兄弟也不怎么当他是一回事，办法照样想，班也照样加。只是，对这个经理好像也不怎么理财。称呼之必为“领导”。还好，由我出马，基本上解 决了他们的问题，但在跟这几位干活的人交谈时，也顺便加深了对这位经理的一些了解。无聊之时，记录一下。

1、经理到底是干什么的？监工吗？
这位经理位并不高，也应该是从技术人员升上去的，可是现在呢，团队的技术工作就交给队员来干，出了问题，只负责指责、加班监督，却不去实际分析，了解原因，想想办法。这样的技术经理是我们需要的吗？
2、不能要求经理就一定要有很强的解决问题的能力，也无法保证经理的技术会比队员好，那么，在出现问题的时候，需要以一个监工的角色来进行吗？解决不了是你们的问题，我只负责监督。而不能试图理解这种困难（毕竟你自己也解决不了啊），营造一种和谐的团队气氛。
3、这位经理显然具有一种凌驾于队员之上的感觉，团队本来具备较好的办公条件，却要他们占用会议室，目的仅仅是达到一种所谓的封闭效果，并给到领导一个 “封闭式开发”的感觉（却没有想到他们实际占用了不该占用的公司资源，别的团队进行开会就不方便了）。而且，动则指手画脚，根本缺乏一种对队友的团结和尊 重意识。

唉，这样的领导，如果你碰上了，就够你受的了。我要是管事的话，不可能让这样的一些只会纸上谈兵、不会尊重部属的人来做领导啊，那简直就是浪费公司资源阿。

BI 平台还可以做什么？

在 BI 这个行当混了快一年了，本来以为是对我来说的一个很好的职业生涯，可惜的是，却变成一个闲人，无所事事。

BI这个领域，在多年的数据应用日趋成熟，企业数据愈来愈丰富的情况下，对于报表、数据分析、智能决策支持等需求确实是越来越强烈了，也感谢IBM、 Oracle、MS等IT老大的概念推广，BO、Brio、Cogous等BI厂商的努力，已经到了众人拾财火焰高的境界了。

最近，Eclipse发布了 BIRT 这个opensource的商业智能工具，包括了报表引擎、设计器等，以eclipse的行事风格，BIRT肯定会成为一个成熟的工具平台。那么，作为BI平台供应商，我们还有什么可以做得吗？

1、数据模型。为关系数据库建立数据模型，可以提供用户在一个抽象模型上的简单化操作，把复杂的数据库、表关系简单的表述出来。BO的Universe是一个我们可以参考的模型。
2、BIRT关注在报表上，而在即席查询、分析方面并不足够。Brio在这方面可以借鉴。
3、在OLAP即席分析上，还有很大的空间。
4、在OLAP报表上，可以在报表级集成复杂的MDX计算能力，包括计算成员、计算指标、计算单元等。以及基于上下文的脚本控制，实现个性化的用户分析流程。
5、在数据分析上，可以集成更为丰富的分析模型。跟SAS学习。
6、深度挖掘 DM 的功能，目前的BI工具在DM上还相当的弱。

我觉得，在BIRT的基础上发展一个BI平台，还是相当的有前途的，即继承了足够的技术基础，发展的空间也非常的大，只要能够为BI应用提供最好的、最快速的开发平台、工具，这样的工具厂商应该来说是很有前途的。（可惜，我们现在开始放弃了这个方向）

Language Oriented Progamming/ Meta Program System

在Java世界中，JetBrains公司还算是颇具知名度的，在IDE这样一个费力不讨好的世界里（旧有列强，如Borland、IBM等，新有 OpenSource先锋如Eclipse、NetBeans等），强力推出 IntelliJ IDEA 这样的一个IDE，而且在Java世界中广受好评，风光丝毫不减于JBuilder、Eclipse等巨头。单这一点，足以让人佩服然了。（可惜的是，鄙 人对IDEA这个工具所知甚少）

在今天的 TSS 上，有一篇 LOP 的介绍文章，仔细一看，对这个公司又有了一些新的认识。

是 MPS 的作者 Sergey Dmitriev Sergey Dmitriev is the cofounder and CEO of JetBrains Inc., makers of the IntelliJ IDEA Java IDE. 单这一点就可国内的软件公司极大不同，在中国国内，指点江山的CEO们，或许有曾经是程序员的，但今天还进行技术研发的，基本是绝迹，就连关注技术的，很 怕也是难见到。这般兄弟虽然日渐远离核心技术，但对技术的自信却随着玩弄资本、关系的熟练，而愈发膨胀，反倒极大的瞧不起技术对于他所在公司的价值了。像Sergey这 位老兄，在搞完 IDEA 这样的冬冬后，再来搞一个 MPS 这样的前沿研究的，怎么能做CEO呢？，如果在中国，我让他做个CTO已经很不错了，实际上，若不是考虑到他现在已有这么大的口碑（算个名人），CTO都 不能给他做，给他个高级技术顾问就可以了。CTO的事情可多了，整天捉摸这些LOP/MPS冬冬，有点不务正业了。

闲话少说：LOP/MPS这个概念，其实也不算全新的技术，但现在来炒一炒，还是有很多新的亮点的。作者的语言，LOP将成为新的提高软件质量、价值的新 手段，鄙人是十分赞同的。http: //www.onboard.jetbrains.com/is1/articles/04/10/lop/index.html 在这个地址上可以查看作者对 LOP的一些介绍，其中很重要的一点就是：所谓软件，无非是把需求映射成为计算机可执行的一个过程，通用的语言包括C++/Java等实际上是"计算机语 言"，而不是"人"的语言，或者说是"业务"语言，实际上，有很多的"业务"或者"领域"语言，是给人看得，比如说 SQL，数学家使用 FL，这些要用C/Java来完成，肯定可以，但已经是猫虎不象了。而LOP则希望回归到这些的支持上，在一个General的平台上，集合GP和LOP 的所长。

作者在文中还提到 程序的存储形式，认为源代码存储的方式已经是一个过时的技术了，而以AST形式进行存储的方式，可以带来更多的优点。的确，AST不再是文档，而是一个 DOM，从此，代码就如同数据一样，可以便于处理，从而在IDE、编译、自动生成等居多环节都带来了巨大的优点，Java的Byecode或多或少的从这 种模式中获利。

我个人的理解方面，我觉得可以基于 LALR 的表达式文法的基础，建立一个专门针对LALR文法的IDE，来支持LOP的开发工作，具体而言，包括如下的功能：
1、 LALR 文法编辑器。提供可视化的方式来编辑LALR。在此过程中，可以快读的对诸如冲突等进行提示。
2、提供基于LALR文法的目标语言的编辑器，虽然说文本形式不一定是最佳的存储形式，但做为一个程序员，却感觉还是一个很好的表现形式。编辑器可以是 LALR文法驱动，提供自动的编辑支持，包括对关键字的code complete、AST语法检查等等。这可以给到新的使用这种语言的人一个莫大的帮助，而不再需要复杂的学习、排错等过程才能使用这种新的语言。
3、在此基础上，提供一些基于AST的额外支持框架，比如说Code Complete，Refractor等，在AST的基础上，难度就比较低了一些。

在目标语言上，我觉得象 Haskell、SQL、XPath 这样的语言均应考虑支持。

Ideas on OS/Database/Filesystem

操作系统、数据库、文件系统这三样东西应该来说是今天软件的中枢了，就存储而言，商业系统大都选择关系数据库来存储数据，而更多的则是选择使用文件系统来 存储其它各类的数据，甚至包括软件本身。操作系统则是所有系统软件、应用软件的基础件，是其它所有软件的平台。这样的形势已经运转了２０多年了，成为了经 典的软件配置模式。

那么，在这个方面，还有没有什么新意可以挖掘挖掘呢？首先要看看有些什么样的苗头：

• Winodws Rigistry：Windows的注册表可谓是Windows下最为流行的技术之一了，熟悉注册表的技巧往往是衡量一个人计算机水平够不够高的一个关键指标。也难怪，Windows的众多秘密都隐藏在这个杂乱无章的存储体系之下。从这个角度上来说，Windows中是最早的Dependency Injection模式的成功应用者。
  
• Microsoft 计划在 LongHorn中推出新的文件系统 WinFS，这是一个建立在关系型数据库的基础之上的文件系统。
• Oracle 9i/10g 如果说Oracle 9i/10g仅仅是一个关系数据库管理系统，可能有点费解，我至今还怀念的Informix Online不过10M的规模，运行的一点也不错。Oracle 9i/10g从莫种角度上来看，就像是一个操作系统，包括他内置的支持J2EE、新的OLAP选项，就有如一个在操作系统上的应用软件。
• Oracle IFS：一个建立在Oracle数据库基础上的文件系统。看来文件系统和关系数据库相结合，也是一种趋势中技术。

如果再回忆起使用普通的文件系统来管理数据，有些什么样的弊端呢：

• UNIX、Linux下的配置文件是满天飞，hosts, passwd, groupd, services，不一而足，在Linux下的高手比试就看谁熟悉的配置文件更多了，这一点就像Windows下使用注册表是一样的。只是，客观的说，注 册表的方式好像要更高明一些，容易管理一些。
• 文件的查找非常痛苦。1个月前下载的文件，或者查找一封历史的邮件，呵呵，都不是一件容易的事情。Mac OS/X Tiger中的一个闪光点Lightspot，就是集成的文件搜索功能。（不过，Tiger中文件系统也根DBMS没什么关系）
• 文件系统还是缺乏关系数据库的一些特性，比如说，增量备份、事务支持等，另外，在快速恢复等方面，文件系统也不如数据库技术成熟。

关系型数据库，目前来说，应该是非常成熟的技术了，简单的开发模型，强大的查询语言，使得关系数据库目前已构成了当今软件的最大市场（这也应了：简单的技术才能普及应用，J2EE的那般专家需要反省反省阿），但是关系模型在很多的时候，还是不具备强的数据表述能力，而且在灵活性方面，也存在一定的不足：

• XML数据表示。XML能够表述的数据要更为复杂得多，现在也有一些XML数据库，包括XML Enable的关系数据库、native的XML数据库。
• OODB。
• 我以前也作过在关系数据库的基础上建立一个模拟文件系统的开发工作，就是需要文件系统的目录层次结构（这与用户的体验、习惯非常相符合），同时又提供更为丰富的元信息，并且利用建立在数据库基础上的特点，可以进行统一的数据管理。
• 在Domino或者Exchange这样的系统中，也会有一个另类的数据库，或者称为非结构化数据库，其特点是存储非结构化的数据，尤其是文档数据、邮件数据等。
• 包括Microsoft Office、Star Office在内的软件，对于其存储的文件格式，又定义其私有的存储模型，这些存储模型，即借鉴了文件系统的概念，也组合了关系数据库、非结构化数据库的特点。
  

其实，存储确实是整个软件系统的核心之所在，从某种角度上来看，是存储的数据决定了开发的软件，存储不单是一个软件的产出，而且也是一个软件开发的一部 分，像今天最为热门的IOC模式，就要求整个软件的高度可配置性。而今天的存储体系，包括了文件系统、关系数据库、XML、非结构化数据等，是一个分离 的、复杂的集合，从长远的角度上来看，有必要整合在一起，互相结合，统一管理。

会有一些什么样的整合机会呢?我想未来会出现这样的一个存储系统：

• 支持关系型数据的存储。这样的数据被组织到 Schema.Table的存储空间中，其查询可以依赖于关系的查询语言，使用索引的机制来提供查询的优化。
• 建立在关系数据库基础上的文件系统， 提供FileSystem的API。文件内容以BLOB/CLOB的方式进行存储。事实上，在关系型数据库的基础上建立文件系统，是一个完全可行的构想，文件系统将存储管理完全的交付给数据库系统，而重点在于提供一个逻辑的结构模型。
• 在关系数据库的基础上，提供XML-Enable，具体而言，可以使用一个 XML 字段，这个字段上可以进行各种 XML 的操作，例如XQuery等。
• 支持对象数据的存储，这样的对象被组织到 Class 的存储空间中，对对象的查询也可以通过索引技术来进行优化。
• 或者说，以对象数据库为底层技术，在其上建立关系型数据库、文件系统、非结构化数据库等。

如果将这样的一个存储系统整合到操作系统中，必然可以大大的简化应用软件的开发，并进而提供更为一致的软件功能。

Learning Oracle 10g OLAP API

Oracle 10g OLAP API中的Source处理，应该是Oracle的核心之所在，可文档也使够难以读懂的，现在，总算是有点理解了。

联想起前一段时间学习 Haskell 等函数式语言，在这个时候，觉得 Source 与函数式语言具有很多的相似之处，一个Source的定义，在某种角度上来看，就是一个函数调用（Closure)。而一个有 input 的Source则向一个 Curing 函数。

Source dimSrc = dimensionMetaObject.getSource()
==> dimSrc = function return all members in the dimensions as a list

dimSrc.position(2)
==> position dimSrc 2

dimSrc.value()
==> 1 阶Curing 函数 value dim

关于Java的 内存数据 处理能力

假设我们现在想开发一个基于内存的数据库系统，这个系统将把整个数据库直接映射到内存中。如果使用Java来编写这样的数据库系统，应该如何来着手呢？

首先，我们有这样的假设：

• 数据库的存储结构必须是Open的，也就是说，多个的工具都需要共享该结构。这个结构不能依赖于语言。

在Java中，由于没有内存的概念，是很难以直接将对象和内存进行映射的，以往的做法是通过 java.io.Serializable 机制来进行序列化和反序列化的，但这个在内存数据库中肯定是行不通的。在C语言中，可以定义一个结构，并且让这个结构与存储结构保持一致（保持相同的字段 顺序、注意编译选项中的填充项），可以实现这种映射。

那么，是否可以在Java中，也进行类似的处理呢？要进行这样的支持，需要对JVM规范做一些什么样的修改呢？

64位时代的软件构想

如果以Microsoft作为标尺的话，回想起来，16位的时代从1984年到1994年，其代表作以DOS和Windows 3.1，大约统治了PC的10年时间。自从Windows95推出后，PC开始进入了32位的时代，Windows2000的推出则基本上淘汰了16位的 时代，到今天也算时10年时间了。

相对而言，64位时代显得要风雨声小了很多，这少到现在，PC上还见不着64位的CPU和OS（AMD的64位CPU推出也不算长，还不够普及，64位的 OS，如Linux和Windows，市面上还很难看到，更谈不上普及了。）所以，要全部进入64位时代，估计还有个3年5年的时间。

64位时代到底会给软件业带来一些什么样的影响呢？本文纯粹是个人的一些猜测：

• 更大的内存将会普及。目前PC的标配基本上是256M，开发人员则开始朝512M/1G上靠拢。在64位时代，PC内存的普及指标估计会达到1G，软件开发人员的标配估计是4G。软件的规模将越来越大。
• 内存数据库将普及。与现有的关系型数据库不同，内存数据库利用巨大的内存空间，将外部存储直接映射到内存中，从而使得数据的处理速度更为快 捷。传统的数据库受限于内存地址空间及可用内存的数目，仅使用内存作为数据的Cache，而需要频繁的读写数据，对数据的处理则需要简洁的进行。采用将整 个数据库映射到内存中，数据库处理程序可以更为简洁，同时提高处理效率。更多的内存，同时也使得IO将更为高效率化，无需频繁的将数据导入导出。这个对于发展中国家，来建立新的数据库系统，从某种角度上来说，是站在了一个新的起点上，可以跟Oracle/DB2等进行竞争。
• 新的操作系统。32位的操作系统为了提供更大的虚拟空间，广泛的使用了虚拟内存的技术，所有的进程均具有自己的独立的内存空间，通过虚拟内存 来映射到物理内存上。在64位时代，64位的地址空间应该说是提供了极为巨大的地址空间，而使得利用虚拟内存来提高地址空间的做法变得多余，同时，64位 时代的巨大可用内存，也使得在相当多的领域，使用外部存储设备来作为内存的后背成为不必要的选项。从这个角度上来看，64位的操作系统将首先不再需要为不同的进程使用不同的地址空间，包括操作系统、驱动程序、应用程序在内的所有代码可以运行在一个统一的内存空间内。这样的优点是进程之间的通信将更为简化和高效率，并促使原来的micro-kenerl的操作系统结构走向普及。 同时，由于物理内存将大大提升，操作系统将支持这样的选项，即不再使用外部存储来作为内存的后背，在这种模式下，可以完全不起用虚拟内存机制。由于内存模型的进一步简化，将导致新的软件结构也进一步的简化，进而提供更为强大的、复杂的功能。
• 虚 拟机语言的进一步普及。以JVM/.NET为代表的基于虚拟机的语言环境在64位时代将更为普及，由于64位时代的物理CPU将提供更为巨大的地址空间、 更为快速的CPU计算能力，更为简单的底层模型，因此，很多的管理功能将逐渐的从原始的CPU级提升到上层的虚拟机上。依赖于虚拟机的隔离，应用软件可以 以更为简单、透明的方式进行开发、移植。而虚拟机则充分的提供更高的计算语义支持，例如，提供内存管理、动态编译等。

Oracle 10g OLAP Server 安装

最近要学习一下 Oracle 10g OLAP，并且熟悉其相关的底层开发，首先要把它给安装起来。

上个月试验了一两天，也没有成功的把它给跑起来，觉得很沮丧，好歹也是10多年的软件从业人员了，却连一个安装都搞不定，说从不来都丢人啊。不过，想想，这也是Oralce/IBM/Sun等大公司的气派所在，如果我的软件让你们轻易就安装成功了，那我多没面子啊。

没办法，只好请Oracle的高手出马，果然是药到病除，为了确保以后我还能顺利安装，只好记下相关的安装步骤了。

1、首先安装 10g_win32_db.zip 文件，解压，安装。不要建立示例数据库了。
2、打10.1.0.4的补丁 p4163362_10104_WINNT.zip 。 （唉，我就不知道打这个补丁，软件一定要打补丁才能用阿？）
3、创建示例数据库，一定要在选项中加入OLAP这一个组件。
4、加载 Samples 数据库，这里包含了一个OLAP数据库实例，可以用来做开发 （解压 samples.zip, 运行common_schema/install.bat) 。
5、使用 oracle d4o.jar 来进行测试，看看能否连得上OLAP，并且打开报表。
6、按照 oracle OLAP API 的文档，马上在eclipse中编写一个很小的测试程序，试一试。将olap_api.jar， classes12.jar等文件全部从oracle的安装目录上拉过来的。

呵呵，一定是跑不通的，而且提供的错误信息基本上不能提供真正的帮助。你只需要把这些 jar 全部去掉，直接把 d4o.jar 用来做 classpath，然后再跑，总算是成功了。个中原因，自然是oracle安装时带的这些包不正确了。

推箱子游戏

最近比较闲，比较闲，没事干的时候真是很郁闷阿。于是，就想起我手机上的一款"推箱子"的游戏，还有很多的关是很难过的，何不编写一个程序，让计算机去帮我过这些关呢？也算是联系一下自己的算法思维吧。这篇Blog就是我对这个过程的一个纪录。

编写这个程序并让他跑起来，倒也不算花太多的时间，大约4-5个小时，终于可以成功的跑完这个程序了，真不错，很快的，就帮我过了1关。在此过程中，虽然 碰到了一些问题，但总算是能够快速的解决掉。而且，由于一开始，我并没有进行任何的设计，虽然总体的代码数不多，就2个文件，4-5个类，总数大约400 -500行Java源代码，这个时候也适当的进行了一下重构，整个系统的结构也变得稍许合理一些。

然而，在过下一关时，就碰到麻烦了，让这个程序跑了2个小时，计算步子也超过了2千万次以上，还没有跑出来。说实在的，对这个计算的复杂性到底有多大，我实在是没有一个计算的方法，但感觉是2个小时也跑不出来的话，这个算法应该是存在着较大的问题的。

然后尝试着对其进行分析，但很难找到出发点，没办法，又给这个程序添加上一个GUI，可以动态的显示出推箱子的状态显示，这个时候，终于发现，在一种特定 的情况下，让人眼来判断，基本上是一目了然，可以判定无法继续下去的情况，但这个算法不能对其检测出来，还在尝试对剩下的箱子进行各种可能的移动，天啊， 这可真是一个很大的计算量，而且，会即位高度的进行重复。

未完 - 待续。 有时间的话，我会把这个算法详细的描述出来，在Blog上发布。