对于命令行用户来说，频繁的cd和tab应该是日常工作中最多使用的命令了。特别对于重度用户来说，如果可以省去这么多cd和tab，将更多的时间做有意义的事该多好。其实Linux的学习过程本身就行这样。你会不断的不满足于现状，就像我一样，一年之前还在研究如何用cd可以更加快速，cd还有什么好点的用户可以更快的到达目录。（cd -回到之前的目录，cd或cd ~回到用户目录等）学习本身也是成长的过程，不满足于现状是我前进的动力，所以今天，突破cd和tab,让我们接受一个新的神级插件----autojump。
首先简单的介绍下这个插件，简单用法就比如你的文件夹路径是
你不需要cd work,cd build,cd ninja,你只需要在进入第一次之后，（注意是必须在进入之后才会有记录），直接输入autojump b n,就自动进入了这个目录。当然autojump默认将j给alias了，所以你只需要输入j b n就到了这个目录，当然如果你这个目录权重高的话，可能你只需要输入 j nin就到了这个目录。之前介绍了权重，那就简单介绍下，它会根据用户的权重来进行目录名和计数器的哈希文件存储。路径一般在
里面的权重一般是这样
30.3: /home/rickyk/bash_completion/etc/profile.d
30.6: /home/rickyk/.autojump
31.0: /home/rickyk/.oh-my-zsh/custom
31.6: /usr/local/share/cmake-2.8/completions
33.2: /usr/local/share
这个权重代表了当你输入比如针对第一条的/etc/bash_completion.d的时候，你输入了.d，因为这条权重是28.3,所以会进入第二条的/etc/profile.d因为他的权重是30.3
相关安装很简单，apt-get install autojump或者直接
然后进入目录后./install.py就可以了。注意在首次install之后需要在.bashrc加入下句
这样你就可以正常使用这个神级插件了，希望这个插件能够给你带来飞一般的爽快感觉 ： ）
参考链接： http://linux.cn/article-3401-1.html
本文链接：Linux导航神器-----autojump，转载请注明。
最近的开发工作涉及到两个模块“任务”和“日周报”。关系是日周报消费任务，因为用户在写日周报的时候，需要按一定的规则筛选当前用户的任务，作为日周报的一部分提交。整个项目采用类似于Orchard那种平台加插件的架构，“任务”和“日周报”是两个独立的插件。
“任务”已经由一位同事事先写好，周报中筛选任务的规则简单描述如下：
- 截止日期在周一之前，且未完成的任务（超期或待审核）；
- 截止日期在周一至周日之间的所有任务；
- 开始日期在周一至周日之间的所有任务；
- 截止日期在周日之后，且未设置开始日期的所有任务（进行中或待审核）。
看起来貌似挺简单，敲代码的时候却发现下不了手，“任务”的仓储层对“日周报”是不可见的，想要按照规则查询任务列表，我只能调用TaskService，但TaskService中并没有根据上述规则来筛选任务的方法。
怎么办呢？为TaskService添加个实现上述规则的方法，比如GetTasksForWeeklyReport？想了想，貌似不是一个好的思路，因为是“日周报”在消费“任务”模块，任务模块应该是不知道日周报的存在的，直接写一个只针对周报的方法总觉得心里有点不对劲。而且，也不希望以后日周报的需求更改而影响到任务。
再想想，日报中也有自己筛选任务的规则，按照上面那么搞，还需要为日报添加个方法GetTasksForDailyReport。如果其他的业务模块也需要按一定的规则筛选任务列表的话，方法还得继续追加下去。这样势必会造成TaskService的无比臃肿，而且其他的模块的规则已修改，就要同步修改任务模块。如果任务模块单独部署到一台机器上，这种麻烦程度就会更大。
这时候夜壶般的脑袋中闪过一个词：规约。
规约模式可以简单理解为条件判断。就不在此照搬那些费解的概念了，按照现在遇到的问题举例来说，我希望TaskService中有个这样的方法：
GetTasksBySpecification(ISpecification specification);
specification是一个描述任务筛选规则的对象，TaskService可以根据这个对象所描述的规则来找出Task集合。对于周报来说，只需要实现ISpecification接口的具体实例，然后调用TaskService的GetTasksBySpecification方法并传递规约实例，就可以拿到想要的任务列表。对于日报来说，也一样，实现自己的规约类就好。以后再有其他业务模块需要根据自己的规则筛选任务的时候，也只需要实现一个规约类。
这样就可以保证“任务”模块的完整性，而且避免了TaskService无限臃肿的顾虑。
有了思想，就剩下具体实现了。主要参考了大神陈晴阳开发的DDD开发框架Apworks，其中提供了规约模式的.Net实现。
最终类图如下：
ISpecification中定义了规约类需要实现的方法，其中IsSatisfiedBy用来判断一个对象是否满足改规约，GetExpression用来获取表示该规约的表达式树。DailyReportTaskSpecification和WeeklyReportTaskSpecification用来描述筛选规则。有时候查询需要根据两个规约以“and”条件进行查询，所以又有了AndSpecification，用来把两个规约以and条件组合到一起。
周报中任务筛选规则的规约类代码大概是：
public override Expression<Func<TaskEntity, bool>> GetExpression(){
return task =>.....;
}
}
根据用户Id筛选任务的规约类代码：
#region 私有字段
private readonly long _inchargeUserId;
没有评论:
发表评论