读源码,从找到入口开始。Openfire源码的入口类在org.jivesoftware.openfire.starter包中,目录结构如下:
org.jivesoftware.openfire.starter
|–JiveClassLoader.java
|–ServerStarter.java
在ServerStarter中,找到了经典的main:
public static void main(String [] args) {
new ServerStarter().start();
}
文章信口雌黄易 思想锥心坦白难
读源码,从找到入口开始。Openfire源码的入口类在org.jivesoftware.openfire.starter包中,目录结构如下:
org.jivesoftware.openfire.starter
|–JiveClassLoader.java
|–ServerStarter.java
在ServerStarter中,找到了经典的main:
public static void main(String [] args) {
new ServerStarter().start();
}
ps:这是一篇无耻的资料整合笔记。
Openfire源码目录结构
1.build目录:build目录下收录的是生成安装文件(例如:rpm)所要的一些文件,例如JRE等;
2.resources目录:resources目录下收录的是一些为实现国际化(i18n)和本地化的一些编码文件(例如:英文,中文,法文,德文等);
3.documentation目录:documentation目录下收录的是一些关于Openfire安装和配置的信息,但最终要的是这里有Openfire开发的Javado;
4.src目录:顾名思义这个src文件夹就是我们想要的Openfire源代码了,这下面又有许多文件夹,我们只要Java文件夹就好,这里面实现的Openfire的核心功能,通过它就可以调试Openfire了。
《暗访》系列目前似乎出了五部,已经读完了三部。印象中还是第一次接触这个类型的书,反映当代社会的、带有浓重纪实气息的小说。小说以一个暗访记者励志般的成长为主线,描述了各种存在于你我身边却不为人知的社会群体,职业乞丐、出租屋妓女、代孕妈妈、酒托、假烟团伙、传销团伙、黑中介、医托、盗墓者、盗窃团伙、盗猎者等等,可以说是一针一线。
android 系统
java
采集android平板在发生内核级崩溃时记录的异常日志文件。经过了解在发生内核级崩溃时系统会把异常信息记录在”/proc/last_log”文件中,该文件是恒大小(512K)的。那么我们要做的就是在每次开机启动并且联网时查询该日志是否记录了异常,如果否则不处理;如果是则通过网络将这个文件上传到服务器。本文主要关注分析日志文件这一块。
需求:有一个异常日志文件,需要分析出该文件中是否记录了某种异常,该异常有一个标志字符串“EXCEPTION _ABC”。即分析出一个文件中是否包含一个字符串“EXCEPTION _ABC”。
代码质量这个事儿一直是组内关注的重点,指标包括findbugs、checkstyle和单元测试覆盖。一直以来前两个静态检查都是采用eclipse安装相应插件的方法,单元测试采用命令行emma生成。刚开始时工程数量比较少,还能撑得住,后来工程越来越多,弄一次报告统计要浪费不少时间,手动效率着实低的可以。正琢磨着换换工具,忽然在某次课程分享中听到了sonar,发现确实省事,而且统计的指标和形式也很多,初试很爽,到最后卡在了单元测试覆盖率这个指标上,专门抽了一个上午弄了一下,终于搞通,这里做个笔记。
最近一段时间工作重点在单元测试上,在这里总结一些两个月来对android单元测试的收获。
单元测试,在android应用这一层主要还是针对类的方法成员或者一个基本功能单元。大体上可以分三步:模拟测试环境;运行测试目标;检查运行结果。
模拟测试环境,实际上就是做好针对测试目标代码的运行准备。在junit框架中,setUp 和 tearDown 回调,就是干这个的。前者运行于每个测试用例之前,在这里实现用例中需要的环境;后者运行于每个用例之后,做一些关闭、释放的操作,算是扫尾。我认为在这个环节中实际上是一个解依赖的过程,需要把影响到测试目标运行的依赖解除掉或者模拟一个假的依赖来供给它运行,目的只有一个——在测试工程中让目标代码可控。
最近有些忙碌,零零散散花了一个礼拜的时间才看完了这本互联网大佬的新书《我的互联网方法论》,又隔了一个礼拜才想起还欠一篇笔记,终于抽得出时间回忆和总结一下对于这本书的收获了。
最近因为业务需要,在研究android源码的下载部分。因为要考虑代码质量的问题,所以就针对源码的测试用例做了一些分析,并在源码用例的基础上添加了我们自己增加接口部分的用例。测试代码的分析比较偏门,网上也很少见,这里权作探讨,欢迎纠错。
最近静极思动,哦不,是嬉极思勤,想抓几本书看看,于是这本《参与感——小米口碑营销内部手册》就来到了我的案头。从目录导图上看这是一本讲产品营销的书,时至今日软件开发人员如果只是单纯的关注写代码那就有点跟不上时代的脚步了,代码实现只是产品的一部分,所以了解产品的方方面面都是有好处的,至少可以提高你针对策划人员的防忽悠能力(总之我不想承认下单之前根本没看清楚的事儿)。书看起来皮尔薄馅儿大,实际上只有两百多页,我花了两个晚上的时间走了一遍——很久没有碰到想一口气读完的书了,里面主要讲互联网背景下产品设计、营销的方法,我觉得整体上是一种方法论的总结,与我这几年浅薄的开发经验和当下各路带有互联网属性产品的走势结合在一起思考,裨益良多。
这回咱们讲讲《水浒》里面的一个框架和一段公案。明清小说,大都带一些玄学色彩,放一些神怪、宿命在里面,现在呢我们称之为“封建糟粕”,这一点《红楼梦》、《三国演义》都有相关的内容。至于水浒,在楔子里就介绍了众好汉的来历——张天师祈禳瘟疫,洪太尉误走妖魔。说仁宗时候东京闹瘟疫,皇上派一个姓洪的太尉到江西龙虎山请天师祈福,正事儿办完了之后,洪太尉就在那儿游山忽然看见了个伏魔殿上边贴着各种封条,道士们说是唐朝时候的天师封了魔王在里面,有道是“好奇害死猫”。洪大官偏要看看魔王长啥样,硬是刨开了封镇,放走了一百单八个妖魔。这就清楚了,梁山好汉本来就是妖魔转世,所以呢一些杀戮啊、不讲道理啊貌似也是合乎情理的。那这妖魔鬼怪的转世,到最后怎么还挂起了“替天行道”的大旗呢,这里边有个关键人物——宋江。