Welcome to Triffic Site

Eclipse|Maven: 查看3rd jar源码

写这篇文章的背景是:最近在开发一个虚拟账户的金融产品,部署到生产环境之后,如果应用在一段时间之内不活跃(即在这段时间内没有访问虚拟账户的请求),再次访问该应用时,发现一直在等待中,不响应。

查看后台db的日志发现程序卡死了,最后一行日志显示Opening JDBC Connection……,恩,看来在检查跟Oracle数据库服务器的连接上出现了什么幺蛾子。

接下来的思路是去查看druid(额,就是哪个著名的数据库连接池开源项目)的源码,关于最终怎么解决这个问题的故事到此结束,也不是本文的重点。重点在于提到了开源项目的源码,所以还是有必要去熟悉下Maven工具,现在项目构建工具很多,孰优孰劣,各有千秋吧。

如果对Maven真的是小白,似乎可以参考以下顺序来熟悉(其实是我自己的一个熟悉和了解过程),把这当中可能遇到的几个问题罗列在此,也算是一种总结。

[1]熟悉概念阶段
这个就自行Google和百度吧,或者直接读官网上的介绍,或者读下面这两个链接中的内容也是一个不错的选择:
Apache Maven 入门篇(上)
Apache Maven 入门篇(下)
好了,读完这两篇应该对Maven的POM,插件,生命周期,依赖管理,包和项目坐标有了一个基本 (更多…)

「重构-简化条件表达式」之解

重构之旅行程已经快超过一半,本章主要讲解如何简化我们的条件表达式,业务逻辑中大量的if...else if…else的句式肯定还让我们记忆犹新,如何善待if判断中的条件语句是本章我们关注的重点。「重构-改善既有代码设计」前三章的链接如下:

第一篇:「重构-重新组织函数」之解
第二篇:「重构-在对象之间搬移特性」之解
第三篇:「重构-重新组织数据」之解

[1]Decompose Conditional(分解条件式)
解: 针对if语句过于复杂的条件判断,我们应该怎么做,才能达到这样的效果:既能保持原先的判定性不变,同时又能清晰明了的知道组合条件中每个分条件的表达含义,也许我们可以试着提炼这些判断逻辑构成一个新的独立函数。

[2]Consolidate Conditional Expression(合并条件表达式)
解: 说的是虽然我们写了两三个if条件判断,但是当满足这些if条件时,都返回相同值,这个时候我们是否可以考虑合并这些if条件,从而简化条件判断流程,厘清代码逻辑。

[3]Consolidate Duplicate Conditional Fragments(合并重复的条件判断)
解: 对于这一点似乎感触颇深,因为这对简化代码逻辑有着切实的意义,假设现在存在if...else的结构如下所示:

由上可知sendNotice()不管if条件是否成立,都会被调用,这个时候可以 (更多…)

「重构-重新组织数据」之解

继续「重构-改善既有代码设计」之旅,重构前两章的链接如下,本章内容有点多,有兴趣的请耐心观看。
第一篇:「重构-重新组织函数」之解
第二篇:「重构-在对象之间搬移特性」之解

[1]Self Encapsulate Field(自封装值域)
解: 相信该手法已经被我们烂熟于心了,我们都会为类中的值域提供getter和setter函数,但现在讨论的问题是这样的,假设在类A中存在这么一个值域length(表示长度),如果这个值域只是单纯被类A中的函数所调用,这个时候我们还有为length提供getter和setter的必要吗;如果值域length会被除类A之外的其他类函数引用到,这个时候为length提供getter和setter函数都没有意见。就自己的实际开发工作而言,如果只是本类中的函数去调用length,就不会提供getter和setter函数了,其他情况下会提供取值和设置函数。

[2]Replace Data Value With Object(以对象取代数据值)
解: 该手法有点为了以后扩展方便,代码组织清晰的意味。假设我们现在有这么一个订单类,类里面用CustomerName这个简单的String变量来表示这笔订单归属的客户名称,然而我们需要进一步的保存客户的送货地址,联系方式等信息,我们当然依旧可以 (更多…)

「重构-在对象之间搬移特性」之解

在继上一章重构-重新组织函数之后,继续下一章的学习,来总结一下在对象之间搬移特性的几种常用重构手法。在对象之间搬移特性的最初动力来源于我们想把类以及对象这两类角色所应承担的责任和功能厘清,下面我们分别进行一一说明。

[1]Move Method(搬移函数)
解: 现在假设存在一个类A,A里面的某个方法aMethod常常使用类B中的某些特性(可能是值域,也可能是函数),这时我们就要思考了:也许把类A的这个方法移到类B中更合适。也许是当时规划做的不够,不过都没有关系,重构给了我们去重新审视和设计的机会,UML表示如下图所示:
move-method

[2]Move Field(搬移值域)
解: 搬移函数讨论的是在类之间转移函数的行为,而搬移值域相对来说讨论和关注的范围更细,类A里面的某个属性值aTemp在其所属的类之外更被经常使用,这样说起来很官方,说白了就是在 (更多…)

「重构-重新组织函数」之解

近一段时间断断续续的在阅读「重构-改善既有代码的设计」,书中提及的重构手法实用且易于理解,可见作者实践水平和总结能力俱佳。很多问题在实际的开发过程中我们都有遇到过,但没有很好的指导准则引导我们如何去改善我们的代码设计实现,我们常常凭借的是已有的开发经验。

好了,废话不多说,我准备每阅读一章内容,就试着按照自己的风格去理解作者提及的重构手法。关于「重新组织你的函数」这一章,作者提及了以下九种重构手法,如下:
[1]Inline Method(内联函数)
解:函数本体太简单了,就一行语句的事,直接在调用该函数的地方用函数本体进行替换吧。但是请注意,如果在子类中需要重写这个函数,那还是算了吧,怎么样也重写不了一个压根不存在的函数,是不!

[2]Inline Temp(内联临时变量)
解:函数中存在着就这么个仅用了一次的小变量,作为某个查询函数返回的接受者,有点浪费,干脆在用到这个变量的地方用查询函数进行替换吧。做法:有这么一种屡试不爽的手法,在这个变量前加上final修饰符,看看是否存在好几处该变量值被修改而引起报错的地方 The final local variable xxx cannot be assigned, 如果真的有不止一处,那暂时还是算了吧,惹不起,这小变量作用大着呢,不然用查询函数 (更多…)

常用设计模式「Design Pattern」示例

设计模式「Design Pattern」可谓软件设计思想精髓的集中体现,是前人在大量实践中的总结和提炼,网络上相关的资料多如牛毛,好像没有炒冷饭的必要,但这不代表自己能够吸收并且在工程项目中灵活运用,还是自己总结来的比较实在。


在总结常用的设计模式之前,有必要对设计模式的几条基本原则进行充分的理解:
1. 开闭原则(Open Close Principle)
简单说就是「对修改关闭,对扩展开放」,怎么理解:在设计项目的一个模块(比如根据账户类别查询账户信息)时,假设我们已经实现根据「往来户」和「内部户」这两种账户类别查询账户信息,后续当我们新增账户类别时,我们并不希望去修改原有的业务逻辑,而是针对新增的账户类别查询子模块实现热插拔的效果。我们往往需要借助接口和抽象类来实现这样的效果。
2. 里氏代换原则(Liskov Substitution Principle)
里式代换原则是面向对象语言设计的基本原则之一,是软件功能单元复用的基础。简单的说,该原则表明了:「所有基类可以出现的地方,子类一定可以出现」。是对抽象的「开闭原则」的具体实现,在之后模式的总结中,会大量看到里式替换原则的运用。
3. 依赖倒转原则(Dependence Inversion Principle)
该原则更像是一种方法论,核心内容是:针对接口编程,依赖于抽象的接口而不是具体的实现。
4. 接口隔离原则(Interface Segregation Principle)
该原则提倡我们使用多个接口,而不是单个,以便于接口与接口之间的隔离,降低接口之间的耦合度。
5. 迪米特法则(最少知道原则)(Demeter Principle)
一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。
6. 合成复用原则(Composite Reuse Principle)
尽量使用合成/聚合的方式,而不是继承。


在介绍完设计模式的六条基本原则之后,下面来具体说说常用 (更多…)

我们就这么希望着

一般无事可干之时,都会写点文字聊以自慰,用来唤醒沉睡的思想,人不思考,便觉得生死其实是一回事,总是会联想到一些不好的结果。

又及人活的舒服了便也出现各种怪毛病,要不得,那是在虚度本就少的可怜的那点时光,年轻人的狂妄等到年岁渐长之后便觉得是一种笑话,咋能跟自然规律对抗,而可笑的是我们从来没有意识到这一点。

生在中国当下这个巨变的时代是好是坏呢,看的稍微明白的人都活的自由自在,看不明白的人一直都在瞎凑个热闹,我们每天都在消化着一个个新鲜的笑话,因而据我观察我们用来深刻思考的时间是非常少的,时间都用来制造和传播笑话了。

所以感觉可伶,如何在这样的大环境下提升和充实自己就成了一件不得不去思考的问题,我们缺乏开放创新的氛围,在错误价值观的指导下,人活出人样会强人所难,只能靠唤醒自我意识达到曲线就己。

但活着总是要有点希望和盼头,我们也是这么希望着。

在new对象中如何使用spring容器中的bean

实际项目开发过程中可能会遇到在new出来的实例对象中使用spring容器中的bean,这个时候我们可以通过以下方法取得(方法不止这一种)。

我们通过实现ApplicationContextAware接口中的setApplicationContext方法来设置Spring容器的上下文环境,同时在VacctSpringContext实现类中增加一个get方法,使得我们有能力得到spring的上下文环境,就像下面这样:

同时在ApplicationContext.xml文件中增加一条配置:

为了在后面使用过程中更方便一点,再提供一个工厂方法,像下面这样:

在需要用到spring容器中的bean时,通过下面这条语句就能获得:

 

2015个人总结

每年都有这么一次掏心掏肺的时候,抬头开着外面始终灰蒙蒙的天空,感受到了一直以来的沉重,曾几何时,我们习惯了蓝天白云的日子,而今与TA却相逢无多时。

这是开场白,开的不怎么漂亮。先总结工作,今年是毕业以来参加工作的第二年,没有了寒暑假,没有了宽松的时间自由,一切都以工作该有的样子进行着,每天争分夺秒出门,走过熟悉的路,碰上熟悉的陌生人,刻板的和保安师傅说着「早上好」,一天就这样开始了,这样的日子虽然有点刻板讨厌,但都还算能忍,又其实自己还算是一个喜欢工作的人,并没有多大的工作障碍,一个男人不工作还能干啥,我还真没有想出来;然就工作成就的感受来说,并没有取得让自己感觉倍儿兴奋的成绩,感觉很平淡;能感到欣慰的就两三事:负责的产品给团队业务带来80+%的业务结算量,团队专注核心企业供应链上下游业务,自己负责的产品给传统企业带来一定的便利,也给我们团队带来了结算量,这是欣慰之一;其二,年初制定的工作目标似乎完成的还不错,一方面参与团队项目的开发;另一方面,积极跟进开源项目,把三两个开源项目应用在了团队内部,比如piwikDokuwiki等;其三,作为一名软件工程师,学习技术和保持对技术的热情还是有的,不说技术能力有多大多大的提高,起码金融行业的业务背景知识了解的越来越多,包括「个人金融业务」,「银行卡业务」,「融资业务」和「电子银行业务」等,当然对这些知识不敢班门弄斧,我了解的可能只是冰山一角,但欣慰的是一直在积累中。说完了工作下面说说生活吧。

今年完成了人生中的一件大事就是定了婚,把日子安定了下来,心里感觉倍儿踏实,不会太急躁,心里有了每天记挂的人,开始更加认真的生活,突然多出了好多责任感的想法。就这样一笔带过吧?。

关于读书,我觉得读书这事吧,再怎么对TA说好都不为过,虽然我还算不上沉迷于看书,但也读了一些书,不管是在「纸质书」,「iBook」,「多看」还是「Kindle」上,有时会专门抽出时间来读一段,但规律性的还是在睡前,躺在床上看,我们好像都有过这种美妙的体会吧,我一般挑一些跟专业相关的行业书,小说的话偏爱推理小说,读过的书单独再写吧,不想把这篇文章的主旨走偏了。

以上三段零零散散说了一大堆,更多的像是回忆,而不是总结,所以最后给自己来几条建设性的一键:

  1. 培养自己的技术框架,了解自己的短板,补之;16年新学一门语言:「Python」,其实研究生做论文实验的时候用过,后面就荒废了,想系统学习之,并利用它做点小项目;
  2. 多读书,现阶段还是应该多读跟自己专业相关的书籍为宜,能力提高了就不焦虑了;
  3. 了解行业动向,话说起来很高大上,说白了就是学会思考,这个社会这么浮躁,看准眼,不要被人忽悠,一个人的职业生涯只有一次,虽然人的一生其实有很多运气和天意在里面,但起码不要让自己犯愚蠢的错误,不然实在可惜;所谓「谋事在人,成事在天」,起码也是在对的事情和自己喜欢的事情上下苦功夫

最后矫情的来一句:「越努力,越幸运」

自建Piwik-All Websites Dashboard页面

Piwik是一款开源流量监测工具,好用好看好配置,好处自然不用多说。但也有一些小问题,私以为Piwik的可配置参数项还不够多。

前端时间一直在纠结如何在「所有网站」这个页面上加上「访客数」这个指标,一通翻找Piwik源码,发现水有点深,另外考虑到以后的升级,所以在想如果我把它的源码给改了,那以后方便的一键升级是不是玩不转了,或者说升级之后又需要重新再修改一遍,经过重重考虑,决定还是绕道,既然Piwik这么强大,提供的API如此丰富,何不如再写一个自己的「所有网站」页面,展示自己认为比较重要的检测指标,这种灵活性是不是爆棚,所有就自己写了一个「所有网站」的Dashboard页面。

Installation

项目源码下载到本地之后,如果需要跑起来,还需要修改这么几个地方:

  1. ~/js/piwik-tongji.js中的http://www.yourpiwikserver.com替换成你自己Piwik的服务器地址,token_auth请替换成你自己Piwik的授权码;
  2. 如果想要在本地进行测试,并且你的Piwik并没有安装在本地,那么还涉及到一个跨域的问题,可以在Chrome的浏览器里面装一个插件Allow-Control-Allow-Origin: *

Need to be done

1、还是有很多值得优化的地方,比如页面布局

At Last

最后上一张效果图(好像有点以假乱真):
QQ20151119-1@2x