作者归档:Young

git根据仓库url修改用户信息

起因

日常Coding使用git的一个问题是,公司工作和个人项目有时候会使用不同的用户信息,例如公司项目要求个人信息必须为your_name@your_company.com的形式,而你自己在使用Gmail,这里自然有些冲突,如果忘记在clone的项目中配置一下,极有可能会把自己的日常使用邮箱提交到公司的repo中,反之亦然。

虽然git本身可以通过--global进行配置,日常使用上使用都用自己的常用个人信息,但是公司项目每次都要单独配置也是做了太多无用功,那么如果能让这个任务更加自动化想必是可以提高工作效率的。

方案

解决的思路决定采用githooks进行处理,在每一次的commit操作前触发,判断当前项目的远端仓库url是否为公司url,若为公司url则修改当前项目目录下的git用户信息,即:

具体匹配操作运用了shellAWK的结合,个人感觉AWK在匹配以及字符串处理上更胜一筹,主要逻辑利用AWK完成。

主要逻辑如下:

其中通过awk的exit值向shell传递信息,通知当前状态,若修改完成,提示用户重新进行commit操作。

使用

GitHub上获取代码后,根据实际情况配置好匹配规则以及用户信息,将hook文件置入git安装目录下的/share/git-core/templates/hooks/之下,并chmod +x赋予执行权限,如在mac上通过homebrew安装的git,则会在类似:

目录下。

最后还需要指定项目的默认init模板目录,例如:

后续clone的项目都能起到效果了。

参考文档

参考了 @liaohuqiu 大大的博客文章git: 提交前强制检查各个项目用户名邮箱设置,同时修改了相关项目的代码,感谢!

TODO

在脚本中尝试帮助用户完成提交操作。

使用Nagios监控Redis

近期新上项目之后出现了后台服务的一些诡异的问题,追查之后发现居然有个Redis的实例把分配的几十G内存给用满了……

终于意识到之前“土法炼钢”的不科学的地方,惭愧之余迅速的想要给Redis加上基本的监控。

最初的想法是直接自己写脚本轮询各个实例的info信息,然后自行parse,当前运行Redis的实例不多,感觉工作量并不大,然而这时候想起组内之前的监控是在用Nagios,觉得为什么不让更专业的软件来完成这项工作呢?于是决定通过Nagios来完成监控。

以下会使用/nip指代Nagios的安装路径,以实际安装路径为准。

Nagios配置

Nagios分为Server和Client,通过各个插件完成对Client的监控,并且在Server中收集展现。

既然运用了Nagios,自然就要按照它的设计思路来进行使用,其实也就是使用合适的插件,同时也不想再造轮子,Google之后确定使用这一项目中的check_redis.pl插件(然而这一文件自2013年7月之后没有过更新了……),这一插件从功能上基本上满足了我对使用内存连接数key个数特定队列长度的监控需求。

这一插件基本上是帮助完成了从redis-cli -h host -p port infoNagios的收集展现过程,所以本身只要在Server上安装即可。

安装插件

安装插件本身并不复杂,只需要download & copy即可,即copy到/nip/libexec目录,并chmod +x赋予可执行权限即可。

然而,真正头疼的是这个插件的依赖安装,由于在服务器上初始化cpan的工作始终无法完成,无奈之下只好通过手工安装依赖。

这一插件的依赖分别是:

  • ExtUtils-MakeMaker
  • IO-Socket-Timeout
  • Try-Tiny
  • Redis

可以在cpan的网站上搜索下载tar.gz文件,解压后基本都通过:

这一过程完成依赖的安装过程。

配置Nagios

想要让监控正常的run起来,配置也是很关键的一个因素,个人认为,配置主要针对监控对象以及监控动作。

监控对象

对于监控对象来说,其实就是标明哪台Server上有着对应的服务,同时还可以对他们进行分组。

监控对象的声明,可以在/nip/etc/conf/hosts.cfg中的对应Server配置中增加一个别名,如:

声明的别名会在报警邮件中得以展现。

同时,需要在/nip/etc/conf/hostgroups.cfg中,为这一批机器分组,以便对一组实例完成监控。

监控动作

对Redis监控,首先要保证Redis实例可访问,不过这一点不用特别配置Nagios,我们需要做的只是针对我们关心数值,进行声明以及配置报警阈值即可。

首先需要在/nip/objects/commands.cfg中配置一个检查指令:

以上参数的含义可以通过/nip/libexec/check_redis.pl --help查看详情:

上述command的含义为针对主机$HOSTADDRESS$的指定端口$ARG1$,检查参数为$ARG2$(可以对照redis-cli info),在$ARG3$设定WARNING级别告警的数值,在$ARG4$设定CRITICAL级别告警的数值,同时生成数据(-f)。

在配置完监控指令之后,还需要针对之前的已经声明的主机组配置使用监控指令进行监控,在/nip/etc/conf/services.cfg增加一项配置:

此处根据个人的实际业务情况,当使用的内存超过28G(30064771072 = 40 * 0.7 * 1024 * 1024 * 1024,以下类比)或者key个数超过30w个时会发出WARNING信息,而在当使用36G内存或者key个数超过40w个时,发出CRITICAL警报。

Nagioscheck_command在参数前使用!,之后的数值针对每一个监控属性,~表示不关注,而对应位置的数值则标称各自的报警阈值。

最后

修改了配置之后,Nagios需要重启才能开始执行监控,那么为了防止因为修改配置而出错,需要通过Nagios先行检测配置文件的正确性:

Nagios的报错信息非常详细,基本可以直接定位到出错的行数。

检查正确之后自然就是重启,等待数据的到来。

emoji,json_encode与MySQL

前言

之前有看到过对于emoji表情这类字符,想要存入MySQL之中,需要建立或者修改表的字符集为utf8mb4,而且对MySQL版本还有一定的要求(>=5.5.3),否则MySQL会提示类似:

的错误。

然而在PHP中其实有一种情况是可以“存储”emoji表情字符的,那就是将包含emoji的字符串通过PHP的json_encode方法处理后再进行存储操作。

emoji不能直接存入UTF-8字符集的表中的原因

根据维基百科上对于字符编码的定义,我们可以将字符集字符编码看做同义词,后面二者将会不加区分的使用。

emoji不能直接存入UTF-8字符集的表中的原因,就得从emoji是什么说起。

emoji简而言之就是若干组Unicode字符,随着iPhone、微博、微信等硬件、软件的支持、普及,emoji也算是越来越常见。

这类字符因为其码位值的原因(U+1F300..1F545U+1F600..1F641U+1F300-1F5FFU+1F600-1F64FU+1F300-1F5FFU+1F600-1F64F),是无法通过3字节长度的UTF-8编码表示的。

以啤酒(BEER MUG)符号举例,这个符号的Unicode的码位值为U+1F37A,那么转换成UTF-8编码则是:

0xF0 0x9F 0x8D 0xBA

明显可以看出需要通过4个字符进行表示,而在MySQL中,一般DBA给定的默认字符集都是UTF-8,而MySQL的文档中写道:

The utf8 character set is the same in MySQL 5.6 as before 5.6 and has exactly the same characteristics:

No support for supplementary characters (BMP characters only).

A maximum of three bytes per multibyte character.

也就是说直到5.6及以前的MySQL的UTF-8字符集最大只支持3个字符,那么emoji字符无法直接存入也是可以理解的了。

emoji转化后进行存储

从上一主题可以看到,不能直接存储emoji字符的话,那么是不是可以通过其他间接手段对emoji字符进行存储呢?

答案是肯定的,如果能够对emoji字符转化成为其编码的字符串之后进行存储,在展示时从字符串转化为原始字符即可,或者是将其转化成为一些特别的字符串进行处理,总而言之就是

的过程。

json_encode与emoji

在实际项目中,JSON是常见一种数据格式,很多结构化的数据可以通过JSON进行存储,而PHP的JSON处理极其简便,配合array简直不能更轻松,很多情况下,数组数据可以通过json_encode之后当做字符串存入MySQL中。

然而这与emoji有什么关系呢?

答案是json_encode会对作为数组中值的emoji字符进行转化,之后转化结果字符串可以方便的存入数据库中。

翻阅在使用的PHP 5.4.24的源码,阅读json扩展的源码ext\json\json.c,可以看到php_json_encode函数中的位于文件的629~631行:

跟进到json_escape_string函数,可以看到文件的422行:

即会将UTF-8编码的字符转化为UTF-16的编码。

之后423538行将转化结果添加到返回的字符串buf中(详情参见PHP源代码文件)。

实际操作一下:

emoji_json_encode_test

这样就解释了为什么经过json_encode处理之后的字符可以存入MySQL中,当然,这样处理之后的成本之一就是存储的字节数的增加了。

[Android学习笔记]改变输入法软键盘上回车键的显示

平日中使用Android应用,例如微信发送消息,输入法的enter键会显示发送二字;在微博中使用搜索功能时,输入法的enter键会显示搜索二字。

编写自己的Android应用时,如果能针对当前的任务,提示输入法显示接近的动作的问题,对用户体验是有所帮助的。

好在在Android上让enter键显示搜索等固定的几种文字并不困难,可以在layout的xml中通过设定EditTextimeOptions属性来实现:

这里需要注意的是,inputType参数也需要设置,否则输入法一样是无法触发enter文字的改变的。

测试的xml文件如下:

搜狗输入法的效果示意图如下:

imeOptions-sample-sogou

至于响应enter输入事件,则需要通过完成对应Listener才能继续了。

Build Facebook fresco

Facebook最近开源了他们的Android图片加载库 fresco ,3月26号到现在两天多时间在github上收获了1000+ star,足见大家对这一个库的肯定。

自己自然也想尝试这一个库,首要工作就是build。

在OS X中进行build

这个库build过程中查看了build.gradle发现需要 ndk 支持,那么首要工作自然是安装ndk。

在OS X 10.9上的build过程比较简单,需要注意的是要把sdk以及ndk的位置加入PATH环境变量中,之后按照github上的README.md中的命令build即可,即:

build过程中可能出现的问题是中间有一步可能还需要挂代理(用到了chromium/webm/libwebp ,gradle会执行一个clone操作),国内网络环境中可能会有连接不上的情况。

Docker中进行build

搭建环境的繁琐之处程序员们自然体会了无数次,还好出现Docker,拯救了程序员。

这里为了方便大家,我简单的构建了一个 Docker image 用于方便大家build,基于dockerbase/android 添加了support library。

使用过程很简单,自然是要先clone fresco

为了在此镜像中build fresco ,需要编辑根目录下的 build.gradle ,从:

变成:

之后继续使用命令 ./gradlew build完成build工作, enjoy~