半年总结

     进入新公司半年了，一直忙于工作跟适应环境，没有好好的总结一下，今天把公司的笔记总结到博客里面，算是这半年来的工作上的一个小结吧：

2010-09-20

Action中获取用户IP

如何获取浏览器访问端用户的真实IP： ServletActionContext.getRequest().getHeader("X-Real-IP")

2010-09-02

一个数据源原则

web操作跟HSF操作同一个数据源时，设计的时候，应该考虑在一个地方配置数据源，例如在短信平台的设计当中，现在的设计是HSF读mongodb中的模版数据发短信，HSF要配置一个数据源，WEB有模版管理后台要读写mongodb中的模板数据，实现对短信模版的管理，web又配置了一个数据源，这导致每次有修改，需要维护两个同样的数据源，而且都是短信平台的，今天小新给我指出来了，想想也觉得这样不合适，于是小结一下，针对这样的情况，的确应该在HSF提供操作mongodb的api，web端通过使用api对短信模版进行操作，便于以后维护。

 

2010-09-02

mongodb使用小结

1、sql使用教程 http://www.mongodb.org/pages/viewpage.action?pageId=5079170#%E6%95%99%E7%A8%8B-%E5%90%91%E9%9B%86%E4%B8%AD%E6%8F%92%E5%85%A5%E6%95%B0%E6%8D%AE

 

2、条件导出数据，脚本范例

mongoexport --db sms_log --collection sms_collection --query '{"date":{$gt:"20100827"}}' --out /tmp/log.bson

此脚本表示：导出日期大于"20100827"的数据。
date > 20100827

mongoexport --db sms_log --collection sms_collection --query '{"date":{$gte:"20100826", $lt:"20100901"}}' –out /tmp/log.bson

此脚本表示：导出日期大于等于"20100826"并且小于"20100901"的数据。
20100826 <= date < 20100901

2010-07-23

通过http方式，请求数据乱码问题

        通过支付宝接口获取数据，返回了一段XML字符串，原本工程、文件、字符串编码都是UTF-8，结果放在服务器上，发现获得的数据由于乱码问题，解析XML失败。一通检查下来，发现服务器环境是GBK编码的，所以造成了乱码的问题，但是这也说明了，这段解析程序本身是脆弱的，会依赖环境的编码而出现问题，这可不符合代码严谨的要求，于是研究怎么优化。
        开始以为是解析XML时，依赖了环境编码，结果发现，原来通过HttpURLConnection去获得http访问返回数据，并使用InputStreamReader来读取数据之后的返回结果就已经是乱码了，问题就出在这里，于是在InputStreamReader读取数据的时候，就设置一下读取的编码方式，new InputStreamReader(l_urlStream, "UTF-8") ，以此来保证不管环境是什么编码，获得的数据都是UTF-8的编码方式，最后测试通过，问题解决！！

2010-06-17

struts属性校验中字段获取问题

        今天用户登录绑定优化上线，原本以为测试已经通过的业务代码部分已经没有问题，简单的页面测试很快就能搞定，谁知道，测试到快下班的时候才发现支付宝登录绑定优化有部分处理被遗漏了，杯具啊，赶紧ctrl+c，ctrl+v，改到最后发现了一个很诡异的问题：form表单中提交的属性，在struts的属性校验文件中，无法获得对应的属性值，导致校验一直无法通过。开始我以为是命名的问题（无法获得的值的属性名是“password”），就把名称改掉了，甚至将form表单的提交方式从post改成了get，但是一直没找到原因所在，后来请教了师傅跟木瓜，还是他们心思细腻，跟我一步步检查配置文件、action文件的文件名称，属性名称是否一致，拦截器等配置是否都齐全，最后发现，原来是因为action文件中对应的“password”属性只有set方法没有get方法，而struts的校验配置文件是通过action对应属性的get方法获得其值，然后进行各种校验操作的，嗯，学习了。        

        这里，建议以后action类中的所有private属性，都加上public的get跟set方法，这并不会对执行效率有多少影响的，但是确可以保证，以后对action增加校验时不会出错，我这次的错误就是因为老的代码只是进行了客户端验证，没有进行服务端的验证，我自己加了服务端验证后，又没有仔细测试各种异常情况，导致这次的发布拖延了一个多小时，吸取教训，下次改正！！

2010-06-03

        昨天晚上搞了coding review，很多同事都出现了review工具使用不顺手的情况，通过在小刚的机器上捣鼓半天，我终于摸索出了一个使用方法，这里记录下来，方便以后查阅：

        给别人的代码做review的方法相信大家都没有问题了，就是选中可以优化的代码，右键鼠标，在出来的菜单中点击“Add Review...”，根据提示就可以操作了。

        当查看别人review自己代码的一个反馈文档时，首先点击Review工具条的“Individual Phase”菜单，这时会提示让你新建一个Review Id，问题的关键就在这个地方，

最好统一一下，review人跟被Review人在建立Review文档时都使用这个工程的名字作为Review Id，因为相同的Review Id，工具才会默认打开同一个Review文档，

你才能看见别人Review你代码的反馈信息，如果以前有创建过跟工程名字不一样的Review Id导致不能打开Review时，可以在工程名字上点击鼠标右键，

在菜单中点击“Properties”，在“Properties”窗口中找到“Review”菜单，就可以看到Review Id的管理页面了，删除错误的Review Id，再进行操作既可以。

        建好Review Id后，再点击Review菜单中的“Team Phase”菜单，就可以进入Review反馈信息
4000
查看页面了，就这么简单！

 

2010-06-02

        今天搞短信业务平台遇到maven工程lib包无法下载的问题，一头雾水，后来请教师傅帮我搞了半天依然失败，在install maven的时候，提示junit测试有错误，当时也没觉得是这个问题造成的，因为前几天用起来还好好的，后来请来了鲨鱼帮忙，终于知道原来是因为install的时候，maven去跑了junit的测试，但是因为我写的测试用例有问题运行报错了，导致jar导入lib目录的时候失败，通过给pom.xml加上一段配置，让maven在install的时候只下载jar包，不去跑测试用例，终于解决了这个疑难杂症，下面是设置maven不跑测试用例的配置代码：

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<skip>true</skip>
<!--
<testFailureIgnore>true</testFailureIgnore>
-->
</configuration>
</plugin>

“testFailureIgnore”可以设置测试信息是否忽略。

 

 

2010-05-25

        最近修改口碑卡项目中的短信应用，接触到了咱们的缓存方面的技术，本来以为把主线工程中的配置拷贝过来修修改改应该就没问题了，结果搞了两天都还是在抛空指针异常，无奈之下只有请教青菜，终于知道了问题所在，原来我们的cache配置文件还是很有讲究的，拿下面的配置做例子：

<bean id="smsCacheManager" class="com.taobao.common.cache.CacheManagerImpl">
    <property name="cacheProviders">
        <map>
        <entry key="SMS_WEB_MEMCACHED">
        <ref bean="PublicMemcachedProvider" />
        </entry>
        </map>
    </property>
</bean>
<bean id="smsCache" class="com.taobao.common.cache.DefaultCache" init-method="init">
    <property name="cacheManager" ref="smsCacheManager"/>
    <property name="cachePolicy">
    <props>
        <prop key="refresh.period">604800</prop>
        <prop key="capacity">10000000</prop>
        </props>
    </property>
    <property name="cacheName">
        <value>SMS_WEB_MEMCACHED</value>
    </property>
    <property name="cacheType">
        <value>READ_ONLY</value>
    </property>
    <property name="cacheRegion">
        <value>SmsWebCache</value>
    </property>
</bean>

配置文件中的

<property name="cacheName">
    <value>SMS_WEB_MEMCACHED</value>
</property>

可不是可以随便命名的，这个名字是在<property name="cacheProviders">标签中的entry中设置的，如下：

<entry key="SMS_WEB_MEMCACHED">
    <ref bean="PublicMemcachedProvider" />
</entry>

如果两边不一致，就会出现空指针的错误了，下次得注意了。

        不过这次的错误倒是加深了我对cache配置的理解，PublicMemcachedProvider作为一个cache源被定义出来，作为smsCacheManager缓存资源的供应者，并且以SMS_WEB_MEMCACHED作为他的key，在实例化自己的cache类时，通过SMS_WEB_MEMCACHED找到当前cache类的cache资源供应者，我想应该可以这样来理解吧，作为自己的一次教训记录下来，以备翻阅。

经验教训

2010-08-09

会员0156上线总结

1、对于需要使用sql修改老数据的操作，除了需要考虑执行sql的业务是否正确外，还需要考虑清楚，修改后的数据会不会有冲突的情况（比如主键冲突sql执行失败），需要的话要统计一下线上的数据，是否有错误数据，考虑清楚，错误数据如何处理。

2、在使用外调接口、HSF服务的时候，需要调研清楚，上线后是否有需要修改的配置，如果有，就要写在发布计划里面，不要以为这个是别人已经实现的功能，就默认配管知道上线改如何修改，比如这次使用铛铛的获取支付宝数据的服务，因为自己的疏忽，忘记在上线计划里面写上要修改以及如何修改支付宝线上环境的配置参数，导致获取支付宝数据时出错，并查找这个错误花了很多时间，下次要注意。

3、由于修改的是主线工程，多人会操作这里面的文件，所以这次发布是挑选文件上线，这就要求开发的发布计划里面不能遗漏要上线的文件列表，这点下次要注意，不能因为开发时间间隔长，涉及的工程比较杂，而遗漏某一个文件，每次修改完任何bug都必须反复检查是否把已修改的文件都放在了文件列表中，这次遗漏了登录页面的jsp，还好木瓜细心发现了，真要谢谢他，下次要注意了，最好避免这种挑选文件上线的情况。

4、这次上线的文件，有几个涉及到了从测试环境到线上环境路径的修改，以后再有这样的需求，一定要列个文件，把这种修改环境所涉及到的文件一一列出，以提醒自己在上线前把这些文件都改到线上环境，当然，以后这种涉及到环境修改的文件一定都要放在配置文件中，之后我会把老的代码中的配置都抽出来放在配置文件中，以避免下次发布时因为环境问题出现各种bug。

5、如果修改的程序会影响数据，在上线后半个月内需要密切观察是否有错误数据产生。