月度归档: 2015 年 9 月

  • 使用git@osc的WebHook自动部署

    有一个小项目代码托管在git@osc上,因为oschina支持免费的私有库,代码就放在上面了。

    因为毕竟是实验性的东西,部署比较频繁,就写了一小段shell去做部署,也就是每次需要部署的时候登陆到主机执行这段shell即可。

    后面看到了deploybot,感觉挺有意思的,但是最后的部署需要登录到主机上,总感觉不安全。

    看了一下,利用WebHook也可以自己做到相关功能。

    git@osc的WebHook是可以配置密码的,所以安全性还可以。

    因为很简单的功能,监听一个端口,获取到post到的数据,然后判断密码,在判断commit信息,如果包含[deploy]就调用部署脚本。

    图方便直接使用nodejs来写,虽然对nodejs很不熟,但是毕竟快。用到的库是express,日志用的log4js

    var express=require('express');
    var app= express();
    var bodyParser=require('body-parser');
    var spawn=require('child_process').spawn;
    var log4js=require('log4js');
    log4js.configure({
    appenders:[
    {type:'console' },
    {type:'file', filename:'logs.log' }
    ]
    });
    var logger = log4js.getLogger();
    app.use(bodyParser.urlencoded({ extended:false }));
    
  • 用jitpack直接引入github项目

    用jitpack直接引入github项目

    Github是一个汇聚了很多有趣东西的地方。如果你使用java作为主要开发语言,并配合gradle,maven等构建工具,那么项目的依赖大部分应该取自maven仓库。

    但有些时候总有有些意外,有些项目的作者并没有将项目发布到maven中央仓库,有些分布在自己的一些第三方的仓库中。

    没有发布的还好,自己寻找方案,如果发布到第三方仓库的,很有可能出现一些问题。

    一直正常运行的项目突然CI挂了,去看看结果发现对方的第三方库挂了,而且这个依赖还是一个snapshot的依赖。

    虽然在github上有源码,但是使用时我并不需要修改源码,所以并不希望直接使用源码级的依赖,采用jar的依赖是最好的。

    无意之间发现了jitpack,解决了这个问题。

    以这个项目为例modular ,项目基于maven,有pom.xml配置。

    直接jitpack中填入这个地址,可以看到几个选项。

    jitpack

     

    我需要最新版本,选择第一个,然后在gradle配置中添加

    repositories {
      maven {url"https://jitpack.io" }
    }
    dependencies {
      compile'com.github.mountainblade:modular:4bf87e0a75'
    }

    一切就搞定了。

    jitpack会自动打包并生成jar包,第一次请求会慢一些,后面就正常了。还可以查看打包的日志和项目文档。

    比如https://jitpack.io/com/github/mountainblade/modular/4bf87e0a75/build.log.…

  • 构建可测试的libGDX应用

    构建可测试的libGDX应用

    Libgdx应用由于其特殊性,测试本身还是有一定难度的。好在Libgdx自身可以跨平台,在桌面平台调试/测试自然比在设备上方便不少。

    但是一个庞大的项目光看调试/测试是很难保证高可靠性的,特别是很多情况并不好测试,比如触发特定事件后的抽奖模块。

    如果可以使用一定数量的单元测试来保证应用的可靠性那自然是最好的了。

    分离绘制

    Libgdx应用测试的一个困难在于UI层面,基于opengl绘制出的界面并没有特定的自动化工具来完成测试,最简单的办法就是分离绘制和其他模块。

    你现有的Libgdx应用可能是这样的

    现有架构

    在render中放置了大量的代码,并在其中直接处理输入和其他逻辑,那么这种代码确实很难测试。

    如果你的应用是这个样子的

    实体系统

    那么大部分代码都可以直接被单元测试覆盖。

    Libgdx提供了ashley作为实体系统。

    利用Backend测试

    即使剥离了绘制,还是有大部分代码需要Libgdx环境。Libgdx环境是指除绘制以外其他模块,比如Gdx.files。

    这种情况下最简单的就是使用headless backend测试。

    这个backend有关gl部分是mock出来的,但是其他部分都是真实的,基本可以视为单元测试环境。

    在Web开发中我们喜欢提functional测试,即控制浏览器在页面上操作,并作出断言检测。

    其实利用Jglfw,我们依然可以做出类似的测试。

    我自己定义了一个Junit的Runner作为测试的辅助。这样的测试会打开一个界面,然后在测试完成后关闭。

    publicclass LibgdxRunner extends BlockJUnit4ClassRunner {
    private Random random =new Random();
    publicLibgdxRunner(Class<?> klass)throws InitializationError {
    super(klass);
    initApplication();
    }
    privatevoidinitApplication() {
    try