两个jar库之间不应该互相依赖
两个jar库之间不应该互相依赖,否则两个jar包都不能独立编译
Month: November 2011
Ubuntu下用sudo运行java程序时要注意此时用户目录为/root
Ubuntu下用sudo运行java程序时,要注意此时用户目录为/root,而不是/home/ yourname之类的 如果没注意到这一点,就可能会遇到这样一种情况: 某个java相关的组件把某些配置默认放在/home/ yourname,而你用sudo启动的java程序却又去/root下找这个文件,结果没找到; 而如果相关的模块又不报错或者不够高调的报错,你就很难发现错在哪里. 我今天就遇到了这种情况: eclipse默认把embedded jrebel的license文件配在/home/kent下, 而我启动jboss时又用了sudo. 搞得我折腾了很久才发现错误.
远程Service组件不应该互相调用
因为互相调用可能会造成执行时的无限循环,比如 1.Component A下面的 service A1 调用了 Component B下的service B1 2.Component B下面的 service B2 调用了 Component A下的service A2 这样看没什么问题; 但某一天某个不知情者让B1调用了B2,另一个不知情者则让A2调用了A1, 就有可能在执行时造成 A1 -> B1 -> B2 -A2 -> A1 这种无限循环
Ubuntu下设置terminal的标题
1.gnome terminal会把标题强行置为user@host, 所以第一步是去掉这个强制: vi ~/.bashrc,然后注掉下面这段代码 If this is an xterm set the title to user@host:dir case "$TERM" in xterm*|rxvt*) PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1" ;; *) ;; esac 2.安装xttitle (注意x后面有两个t) 3. xttitle "The title"
明确的技术债务
1.研究下: MySql开发的36条军规 2.淘宝技术大学放出的 java中间件 pdf 3.connanscence 研究
《软件架构设计》读书笔记 – 5. 关键需求决定架构
《软件架构设计》 温昱 ============================================ 等分析完所有需求才进行架构设计，一般是来不及的；应该针对关键性需求在有限的时间内做出可用的架构设计。至于非关键性需求，可以把它们用来验证架构：从每项非关键需求的角度对架构方案进行走查。 那么哪些需求是关键性需求？ 1.约束，因为它们必须被满足 2.关键Use Case 3.需求方眼里的高优先级需求 4.对系统受认可程度有较大影响的质量属性
《软件架构设计》读书笔记 – 4. 关于非功能需求
《软件架构设计》温昱著 ================================================= 非功能需求可分为： 1.约束 2.质量属性 a.运行期质量属性 b.开发期质量属性 先说下约束。约束会从三种途径影响设计： a.设计可以直接遵守约束，比如“必须运行在Linux上” b.约束转换为功能性需求，比如“系统必须严格按人行利率执行” => “必须提供利率调整的功能” c.约束转换为非功能性需求，比如“操作者的计算机水平不高” => “必须有良好的易用性” 关于质量属性，作者创新地把它们分为运行期属性和开发期属性： a.运行期: Performance, security, usability, availability, scalability, interopreability,reliability, robustness b.开发期: Understandability, extensibility, reusability,testability, maintainability(可被修改的难易程度), portability