Programmer Life

       XP中重要的一点就是交流和勇气。

       关于交流，相信大部分国内的软件团队都是做的不太好的。其实交流有什么不好的，它带来的是很多的好处呀，我觉得之所以会导致团队内不怎么交流最大的原因就是programmer的一个通性，都比较的高傲吧，发现programmer都觉得自己比别人厉害，当发现自己比别人弱的时候还是不愿和别人交流，因为每个programmer都不希望让别人觉得自己比他差，所以都会尽量自己去学，这种上进心无可厚非，但有些时候别人的指点会比你看N本书都强，如俗语所言：“与君一谈，胜读十年书”，怎么感觉写的好像有点不太对，呵呵..........另外一个我比较坚持的就是一个人看问题会总是一种角度的，但当你和同事交流时你就会得到另外一个角度的思想，还有就是你为了说服同事或让自己接受同事的思想，都得让自己完全有一个理由，一个让自己和同事觉得应该这么做而不是那么做的理由，这点我深有体会，因为要说服别人或说服自己都不是一件容易的事呀。交流好了就使得在其后的designing、codeing时会更容易，更顺利的进行下去。发挥XP的原则吧，既然交流这么好，那咱们就多一点交流.......

       关于合作，觉得在这点上国内的大部分软件团队做的也不是很好，虽然任何一个团队都是需要合作的。其实合作在很大的程度上能够增强团队的凝聚力，以及各成员对于系统的整体理解能力，当然各成员负责的还是有个主要方向的，毕竟只有这样系统才好进行，不过建议推行PP，在使用PP的情况下能够使得团队内的成员对于系统的整体理解加强，另外一个就是可以学习别人的编程风格，统一团队中的思想。其实合作的加强对于公司以及个人都是有很大的好处的，对于公司而言，使得人员的流动不会带来太大的影响，而对于个人而言能够更快的提升自己的理论知识以及实际编程能力。

       关于培训，相信大部分团队还是会经常做的吧，我指的是公司内部的那种对于公司产品某一部分的主要技术负责所做的培训。其实觉得在做这种培训的时候最大的受益者是讲课的人，而听课的提升速度真的不会有讲课的快，因为既然要讲课首先就要求把自己对于系统的理解思路理清，而且还要能够系统的讲出来，这点并不容易做到，很多时候你觉得自己对于某东西已经很清楚了，但真的要你进行系统的讲解的时候你会发现很难，呵呵......这个大家可以试试，我深有体会，就象以前给同事做Jetspeed培训时，简直就是混乱呀，在那种情况下你就会要求自己更加深入的去理解那个系统，然后适当的划分，进行相应的分块讲解，这就使得你自己迅速的得到提升。还是那句话，发挥XP的原则吧，既然培训这么好，那我们就多把自己认为自己更熟的一些技术讲给别人听吧..............

       要成为一个精英团队（相信很多programmer都希望自己处身于这样的团队之中），交流、合作、培训都是非常重要的，这也是成为一个精英团队的基础，让我们努力吧，^_^

       工作两年了，除了把深圳自身的景点玩的差不多了，都没出去玩过，今年5、1好不容易有个长假，终于订了去丽江的团，爽呀，呵呵.........唯一的遗憾就是还是没订成去九寨沟的团，等10、1看看有没有时间再圆九寨沟之梦，^_^

       调了好久，也查了网上的文章，发现没有什么关于如何详细使用BeanNameAutoProxyCreator的文章，为什么我的会不行呢？怪了，我的配置如下：

 <bean id="trueblogService" class="com.jerry.portal.application.service.blog.BlogManagerService">
  <property name="blogDao"><ref local="blogDao"/></property>
 </bean>
 
 <bean id="autoProxy"
    class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
  <property name="proxyTargetClass">
        <value>true</value>
     </property>
  <property name="beanNames">
   <value>*Service</value>
  </property>
  <property name="interceptorNames">
   <list>
    <value>blogServiceAdvisor</value>
    <value>performanceInterceptor</value>
   </list>
  </property>
 </bean>

 

然后调用时我getBean("trueblogService")，其后执行方法时怎么我的interceptor毫无反应呢？郁闷呀，大侠们帮忙

       本来是不能放这的，因为涉及到商业问题(所以稍微了改动了一些东西)，暂时放这几天，大家有兴趣的可以下载过去(为了节省空间我压缩了一下)看看，呵呵.........看完后给点建议，自己感觉有些迷糊

       下载地址：http://BlueDavy.blogdriver.com/diary/BlueDavy/inc/rbacdesign.rar

       越想越觉得很麻烦，一直就没认证的去考虑权限系统，现在真的开始做这一块就发现真的很麻烦，ACL能让你简单的实现权限系统，但RBAC可就没那么简单了，一旦增强了系统的灵活性，必然也就增加了系统的复杂程度。

       发现在写上篇blog的时候觉得从理论上来讲的RBAC实现好像不难，但当我进行情景测试的时候发现真的好难，呵呵...........得好好看看一些权限系统的设计了，借鉴借鉴

       由于要做公司的一个权限系统相关的任务，又开始重拾RBAC了，不过一直以来对权限系统就比较的感兴趣，因为这确实是无论什么系统中的重中之重，一个灵活的权限系统将使得系统变得简单易用，并且控制性极强。

       RBAC：Role Based Access Control，翻译过来基本上就是基于角色的访问控制系统，ACL：Access Control List，访问控制列表，是前几年盛行的一种权限设计，它的核心在于用户直接和权限挂钩。RBAC的核心是用户只和角色关联，而角色代表对了权限，这样设计的优势在于使得对用户而言，只需角色即可以，而某角色可以拥有各种各样的权限并可继承。ACL和RBAC相比缺点在于由于用户和权限直接挂钩，导致在授予时的复杂性，虽然可以利用组来简化这个复杂性，但仍然会导致系统不好理解，而且在取出判断用户是否有该权限时比较的困难，一定程度上影响了效率。

       RBAC的使用，个人认为RBAC在使用时在管理程序的表现为首先创建一个角色，对该角色授权，给用户授予此角色使得用户拥有该权限。权限系统的基本概念就是谁对谁进行某操作的权限，其中第一个谁指的是操作者，通常即为用户id，而第二个谁通常是指资源id，如部门id呀等等，操作则通常指的是删除、修改、查看等权限，角色的概念在我的理解就是资源id和操作的组合，两者组合构成了权限，然后用户只需属于此角色即可进行操作。鉴于此种理解，系统的权限系统设计为：

       1、管理程序。在管理程序中首先通过名称空间的方式配置系统中可用的资源，如部门等等；在角色管理部分配置增加角色，并给角色进行资源和操作的授予；在用户管理中给用户授予角色。

       2、应用程序中的权限认证。在应用程序中判断用户是否拥有某权限可使用如下步骤进行检验，首先取出执行此操作所需要的最小的资源＋操作权限所对应的角色，然后判断用户是否拥有此角色权限，这好像有点是RBAC中所说的最小权限，我对RBAC中的这个一直不太理解。

       以上简单的描述了一个权限系统的设计，当然在真正开发时就更为复杂了，需要考虑比较多的东西了。在应用程序中的权限认证目前基本采用的都是proxy模式去实现，因为现在觉得采用AOP还有太大的风险，而且自己也没想清该怎么用AOP实现，还是继续用成熟的proxy模式实现好了。

       Advice：之前我有解释过，其实就是对你关注的pointcut采取的措施或者说执行的干预吧。

        配置中改成了：

<bean id="performanceInterceptor"
       class="com.jerry.portal.application.aop.advice.PerformanceInterceptor"/>

 

刚顺便看了一下Spring源码，发现它提供了一个PerformanceMonitorInterceptor

已经有了

 

就说AOP拿来做性能分析呀、日志记录这些是很容易应用上的，只是被切者和横切者一旦发生某些关联信息就比较麻烦了

       呵呵......反正现在也不急着做新的门户框架了，多参考参考一些优秀的东西是不错的，粗略的看了XWork的文档，是potian blog上的那个，有了个大概的印象，感觉确实非常的good，至少我看到了对响应页面的action类的可测试性，太优秀了，大家可以去看看，网站是：