尝试用ReactNative写的iOS客户端
API是通过kimono抓取的(开发期间正好碰上RubyChina关闭了API)
kimino请求速度很慢,等rubychina哪天再开放API了再切换过来~
基本功能
- 精选主题
- 分类节点
- 节点主题
部分截图
首页
分类节点
主题详细页
关于
TODO
- 缓存
- 用户页
- 下拉刷新
- 用户登录(等开放API)
- …
BSD
尝试用ReactNative写的iOS客户端
API是通过kimono抓取的(开发期间正好碰上RubyChina关闭了API)
kimino请求速度很慢,等rubychina哪天再开放API了再切换过来~
BSD
Slack是一款企业内部协作平台,能将各种分散的沟通、协作工具整合到一起,基本上市面上所有的知名第三方服务都能很好的集成到Slack,其它没被官方集成的服务也可以通过Slack提供的API集成,比如整合内部任务系统、ERP系统等等。
Hubot是Github推出的开源聊天机器人,能整合各类IM工具。可以通过写hubot coffee脚本来实现各种好玩的小工具~
下面开始介绍如何利用Slack和Hubot处理Android自动打包。
##Ubuntu环境处理Android打包
###安装工具 下载ADT
$ wget https://dl.google.com/android/adt/adt-bundle-linux-x86_64-20140702.zip
$ unzip adt-bundle-linux-x86_64-20140702.zip
$ sudo cp -r adt-bundle-linux-x86_64-20140702/sdk /opt/adt-sdk
安装ant
$ sudo apt-get install ant
安装jdk
$ sudo apt-get install openjdk-7-jre openjdk-7-jdk openjdk-7-jre-lib
设置环境变量,在你的profile文件内加入下面代码:
export ANT_HOME=/usr/share/ant
export ANDROID_SDK_HOME=/opt/adt-sdk/
export PATH=$PATH:$ANDROID_SDK_HOME/tools:$ANDROID_SDK_HOME/build-tools/android-4.4W:$ANDORID_SDK_HOME/platforms/android-20/
export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
注:根据平台不同,上面的java-7-openjdk-amd64
有可能为java-7-openjdk-i386
###检查环境
$ ant -version
Apache Ant(TM) version 1.8.2 compiled on December 3 2011
如果正常输出版本号则表示ok,如果提示报错,(如tools.jar
找不到等),跟环境有关,请按上面步骤检查。
###处理包签名
生成keystore
(需设置密码),这里以kudong
为例
$ keytool -genkey -v -keystore kudong.keystore -alias kudong -keyalg RSA --validity 10000
进入项目目录,新建文件ant.properties
,输入以下内容:
key.store=上面保存的keystore文件路径
key.alias=kudong
key.store.password=上面设置的密码
key.alias.password=上面设置的密码
###更新项目
$ android update project --name kudong -t 1 -p /path/to/android/project
这里的-t
参数可能会报错,需要用下面的命令查看当前存在的targets
$ android list targets
###开始打包
先跑一次测试
$ ant debug
如果报错,可能需要安装下面的库(android工具依赖库需要兼容32位)
$ sudo apt-get install libc6-i386 lib32stdc++6 lib32gcc1 lib32ncurses5 lib32z1
再次ant debug
提示成功后,就可以打包了
$ ant release
...
...
-post-build:
release:
BUILD SUCCESSFUL
Total time: 6 seconds
打好的包在项目的./bin
目录下
##安装Hubot
Hubot基于NodeJs 和 Coffeescript,这里我们将用Hubot调用前面的ant
打包工具。
###安装并创建hubot项目
1. 安装npm
$ wget http://nodejs.org/dist/v0.10.32/node-v0.10.32.tar.gz
$ tar zxvf node-v0.10.32.tar.gz
$ cd node-v0.10.32
$ ./configure
$ make
$ sudo make install
2. 安装hubot和coffee
$ sudo npm install -g hubot coffee-script
3. 创建Hubot项目
$ hubot --create myhubot
$ cd myhubot
$ hubot
Hubot>
###用Hubot调用ant打包android项目
Hubot脚本需要用coffeescript编写,简化版如下:
module.exports = (robot) ->
robot.respond /build/i, (msg) ->
msg.send 'building, please wait...'
command = 'cd /path/to/android/project; ant release'
ret = require('child_process').exec(command)
error_chunks = []
ret.stdout.on 'data', (chunk) ->
#msg.send chunk.toString()
ret.stderr.on 'data', (chunk) ->
error_chunks.push chunk.toString()
ret.on 'exit', (code, signal) ->
if code == 0
msg.send 'build success'
else
msg.send error_chunks.pop()
###Slack与Hubot通信
修改package.json
文件,在dependencies
中加入slack:
"hubot-slack": "~2.0.4"
然后运行
$ npm install
设置Slack相关环境变量(token,团队名,机器人名)
这里我们的机器人名字叫:kucat
export HUBOT_SLACK_TOKEN=你的Token
export HUBOT_SLACK_TEAM=kudong
export HUBOT_SLACK_BOTNAME=kucat
启动
nohup ./bin/hubot --adapter slack --name kucat &
然后在Slack增加Hubot集成
填入Hubot URL:
http://你的服务器IP:8080/
这个时候在Slack任一频道内输入:
kucat build
就可以看到返回数据了。
##最后
自动打包这个需求,其实完全可以通过Github的hook机制处理,还更方便快捷,不过这不是本文重点。
本文只是很简单的应用案例,Slack+Hubot还有更多更酷的玩法,后面慢慢讲~
今天收到服务器报警邮件,是服务器硬盘快满了(超过90%),检查后发现redis
的aof
文件居然达到9G,这才想起来没有定期rewrite aof文件,于是干脆一不做二不休,升级到新版,免得手动处理aof(redis 2.4以上的版本会自动rewrite aof)
大致过程比较简单
卸载旧版
apt-get remove redis-server
下载官方稳定版编译安装
wget http://download.redis.io/redis-stable.tar.gz
tar xvzf redis-stable.tar.gz
cd redis-stable
make
sudo make install
拷贝文件到原来的位置(懒得改init脚本)
sudo cp /usr/local/bin/redis-* /usr/bin/
然后修改配置文件(aof bind daemon等等)。
另外,旧版的配置文件跟新版不兼容,比如vm-enabled
等参数,新版中木有。
启动后,查看版本
$ redis-cli --version
redis-cli 2.8.15
然后回到开头的问题,aof文件过大的问题
只需执行BGREWRITEAOF
命令即可:
redis> BGREWRITEAOF
Background append only file rewriting started
以上命令在旧版中也可以执行,但是新版中这个操作由Redis自行触发,就不用人为定期处理了。
可以通过以下参数来控制自动触发行为:
auto-aof-rewrite-percentage
auto-aof-rewrite-min-size
默认触发机制是当aof文件大小为基准大小(64mb)的两倍时,自动执行BGREWRITEAOF
完。
昨天在开发一新接口时,遇到一问题,nginx时不时出现502错。
打开nginx错误日志,发现如下报错:
2014/09/15 14:34:28 [error] 5103#0: *114 upstream sent too big header while reading response header from upstream, client: 127.0.0.1, ...
这个属于比较常规的问题了,header长度超出,之前遇到过
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
于是按照之前的方法适当调整nginx配置,发现问题依旧。
程序逻辑比较简单,大致流程是:
调试发现,每次写入redis缓存都会导致nginx报502
开始觉得不可能,因为系统其它很多地方也用到redis但一直没遇到过这个问题.
于是怀疑是不是snc redis
的bug?
经过一番调试发现,如果执行redis命令的时候不记录日志,则能正常工作,否则就报502错,代码为下面的$this->logger->logCommand
这一行。
public function __call($name, array $arguments)
{
$log = true;
...
$startTime = microtime(true);
$result = call_user_func_array(array($this->redis, $name), $arguments);
$duration = (microtime(true) - $startTime) * 1000;
if ($log && null !== $this->logger) {
$this->logger->logCommand($this->getCommandString($name, $arguments), $duration, $this->alias, false);
}
return $result;
}
进一步debug,发现这里调用到了Symfony
内的Monolog
的方法用于记录日志。
public function addRecord($level, $message, array $context = array())
{
...
// check if any handler will handle this message
$handlerKey = null;
foreach ($this->handlers as $key => $handler) {
if ($handler->isHandling($record)) {
$handlerKey = $key;
break;
}
}
// none found
if (null === $handlerKey) {
return false;
}
// found at least one, process message and dispatch it
foreach ($this->processors as $processor) {
$record = call_user_func($processor, $record);
}
while (isset($this->handlers[$handlerKey]) &&
false === $this->handlers[$handlerKey]->handle($record)) {
$handlerKey++;
}
return true;
}
问题就出在上面的 handlers
里,打印出来发现这里面包含了4个handler,经过排查发现是ChromePhpHandler
的问题,进一步抠代码:
public function onKernelResponse(FilterResponseEvent $event)
{
...
$this->response = $event->getResponse();
foreach ($this->headers as $header => $content) {
$this->response->headers->set($header, $content);
}
$this->headers = array();
}
打印出这里的header后发现问题了,header内的X-ChromeLogger-Data
值长度达到165952
字节,大约162K
,超出了我本地nginx配置里设定的128K,于是出现502. 如图:
为弄清具体是什么数据,经过base64_decode
和json_decode
后,如图:
原来是snc_redis
完整记录了redis
操作数据,所以如果写入到redis的数据过大,可能超出web服务器设置的header最大长度,导致报错。
这尼玛。。这种方式简直反人类啊,绝逼不靠谱,于是准备跟symfony
官方反馈这个问题,不过发现官方已经解决过了。。
解决办法是,去掉Symfony配置文件config_dev.yml
内的chromephp
相关配置。
到这里问题解决了,简直太坑。。
不过,调试过程中发现snc redis
的另外一个坑,下次有空再写出来。