• 2003-12-19

    保重身体吧!

    我们项目之前的负责人月初的时候对我们说,这个月会过得比较充实。借他吉言,这个月真的很充实,甚至累得快直不起腰来了。最近几天身体明显有些不适,这让想起头两天体检的结果,我已经不是100%的健康了。所以,这里要对所有和我一样的程序员兄弟姐妹们说一声,保重身体。身体是革命的本钱,没有本钱,拿什么做买卖啊!

    我所做出的决定就是9:10之后,不再写工作代码。为什么有零头?因为我们这里最后一班出软件园的班车是9:10,虽然我不必坐车出园,但我仍选择了这个时间作为工作代码编写时间。

    这两天听说JFox要做AOP,于是到JFox的AOP论坛上发了个帖子,侃谈一下我的观点,如下:

    1. 看到JFoxAOP的项目设想,突然冒出这样一个疑问,为什么要用AspectJ?

      首先要说的是,我并不想否认AspectJ的优越,AOP之父领导出来的东西并非浪得虚名。直接采用全新的语法,使得AspectJ相对于许多使用Dynamic Proxy完成的AOP有着相对的效率优势。

      Java世界一个重要的游戏规则就是标准,这也是Java社区与MS抗衡所倚赖的一件利器。AspectJ最为缺少的恰恰就是标准。AOP之父在其访谈录中谈到,AOP思想经历了这么多年,也到了该有标准的时候了。当然,基于现在AspectJ的成熟程度,很可能这个新的标准会取其精华,但指望AspectJ完全成为标准,显然不那么现实。

      如果Java真把AOP纳入语言之中,那么AspectJ其地位如何呢?可能就是一种Java方言了吧!不要认为好的东西进入语言/JDK中就那么理所当然,Log4J已经是一个不良的例子了。

      如果AspectJ真的那么好,为什么JBoss会选择另起炉灶呢?有个朋友对我说过,他并不看好AspectJ的静态weaving,我想最主要的原因在于AspectJ对语言的修改吧!这么做不是不好,只是现在还不是很好。

      作为学习AOP思想之用,AspectJ可能会省去了不少麻烦,但以它作为一个项目的开发语言现在来看是否有些冒进呢?

      看到的,想到的,一家之言,大家一起讨论一下吧!

    2. 现在对于AOP的实现方式通常分成静态和动态两种。

      静态的实现方式正如AspectJ所做,实际上是相当于在普通Java的编译器之前加上了一个预处理器,对aspect进行预处理,使得AspectJ的代码变成普通的Java代码,于是AspectJ产生出来的代码就可以在普通的JVM上运行。

      动态的实现方式可以以nanning和spring为代表,它们采用的手法是运行时根据配置信息进行加载,并在其中插入动态代理,这种实现方式最大的问题就是效率。

      JBoss的AOP实际上介于二者之间,修改class loader,于是优缺点也在二者之间。

      我对Jython的了解(这里提到Jython是因为论坛中有人认为扩展语法的手法不错,并以它作为证据)仅限于听说个这个名词,我不清楚Jython现在的流行程度如何,也不清楚向其它语言扩展,其目的何在。所以也无法得出“采用全新的语法就是好的”这样的结论。

      我在论坛中提出这个问题的原因并非批驳AspectJ,而是希望与大家讨论,得出一个让大家都比较满意的结果。
  • 经过了一段的实践,忽然发现自己最应该掌握的是一些基本的东西,比如数据结构,比如编译原理,比如操作系统,这种感觉随着自己实践经验的增多而愈加强烈。

    学习编译原理和操作系统的意义并不在一定要实现出一个编译器或是操作系统,关键在于学习其中的许多思想,开阔自己的思路。很可惜,念书的时候,我没能找到一种很好的学习方式,以致于虽然不断的告诫自己这两门课的重要性,最终仍未能让其刻骨铭心。

    以我现在的眼界来看,学习这两门课最好的方式是结合源码,操作系统当之无愧就是Linux了,编译器我觉得Gcc不错。oldlinux.org上的赵博士为0.11版的Linux做了份注释,写了本书,我只看了开头不多的一点,感觉还是很不错的。有了问题还可以到网站上去问问题,赵博士挺热心。

    相对来说,Gcc的资料趋近于0。最近我认识的一个高手在研究Gcc,我有幸分享了他的一些成果,受益匪浅。等我小有心得的时候,也把自己的学习成果贡献出来,和别人一起分享。

    说了半天,都快忘了我今天blog的题目了,我买了《算法导论》,这可是本经典的作品。

    Pascal之父Wirth博士的经典论断就是“程序=数据结构+算法”。

    我不知道别的大学是怎样的,我的大学课程中,数据结构进行了专门的讲解,但对算法几乎没有涉及,加上大学中误把二者等同起来,结果造成了现在基础不是很扎实的结果。

    书买回来了,最大的疑问是我能从中获得多少东西。我并不怀疑这本书的经典程度,我怀疑的是自己的学习态度。
    1 书的厚度近1200页
    2 书是英文的
    买书的时候,同去的兄弟就对此提出了置疑,我大言不惭的说,我一定会好好看看,认真的去实践,心里却在打着鼓。

    写下这篇Blog的目的,一是纪念一下为《算法导论》而阵亡的诸多Money们,二是告诫自己,开始学习吧!

  • 早早就申请了这个Blog,却迟迟没有写过一篇,对于多少还算比较喜欢码字的我来说,有点说不过去。于是决定多多少少写点东西,也算对得起自己了。

    既然是个程序员的Blog,话题当然离不了程序。近来比较忙,一个已经做了一年的项目又有了新需求,加上我们项目组的人那么积极上进,于是乎,大家决定为系统设计一个新的架构,版本号也顺理成章的由1.X变成了2.0。

    部门里人事变动,负责人升级了,我们项目中本来负责系统架构的兄弟成了负责的,于是他的活转到我的手里,我成了这个新架构的“架子工”。

    近两个月在看Uncle Bob的《敏捷软件开发》,终于对OO有点开窍了。最近一期的《程序员》gigix那篇关于IoC的文章看得我心潮澎湃。IoC实际上和Uncle Bob所讲的DIP基本上是一回事,有了DIP的一点底子,看IoC就有感觉多了。手头上有gigix的Groller,文章加代码看得我越发有感觉,于是想在新架构中对这些“感觉”进行尝试。

    Groller中的IoC基本上是借鉴了Spring中Bean操作来完成的,所以我也投了一些精力在Spring上,随着对Spring的了解,我的思维开始发散。既然能够把一些组件(bean)配在xml文件中,由Spring来替我们完成组合,那我把整个系统都看作一个组件集如何呢?

    gigix在Groller里进行了一些尝试,他把一些service按照组件进行配置,只不过他的service组合还是比较简单的。我想可以再进一步,把整个系统都以这种方式组合起来,即大的service由小的service组成,这样一点一点把整个系统拼接出来,所有的配置都由配置文件完成。

    和gigix就这个问题讨论了一下,他觉得小service应该是大的service的一个aspect,可惜我不懂AOP的概念,所以,我只能以“小service是大service的一个组成部分”来理解。

    渐渐的,我开始觉得AOP是个好东西了。有人说面向过程如果是一条线,那么面向对象就是一个面,到了AOP就是一个体了。既然可以由一维逐渐演化为多维,看来还可以再进一步,让它变成一个多维的。

    类比一下,我觉得操作系统的文件系统也可以设计成一个多维的。比如我们组织自己手头的资料,可能C中有电子书、有网页,Java中也有电子书、有网页。如果我们换个角度来看:电子书里有C的、也有Java的,网页中同样有C有Java。由此看来,现在的文件系统也可以再进步一下,不必维持现在这种单一的树形结构了。

    呵呵,已经偏离起始的内容好远了。这就是思维混乱的结果,随性而行,差之毫厘,谬以千里。