一台电脑使用多个github账号时如何免密登录

1. 生成各自的ssh key ssh-keygen -t rsa -C “foo@test.com” #选择key文件为~/.ssh/id_rsa_foo ssh-keygen -t rsa -C “bar@test.com” #选择key文件为~/.ssh/id_rsa_bar 2. 将这两个ssh key加入到系统中 ssh-add ~/.ssh/id_rsa_foo ssh-add ~/.ssh/id_rsa_bar ssh-add -l 3. 配置两个虚拟ssh host,分别对应每个ssh key.  这样在进行ssh登录github时,系统知道应该选择哪一个ssh key 引用 #~/.ssh/config Host github-foo HostName github.com User git IdentityFile ~/.ssh/id_rsa_foo Host github-bar HostName github.com User git IdentityFile ~/.ssh/id_rsa_bar 4. 将这两个ssh key的公钥部分分别粘贴到github的账号设定中,这样才能免密登录 请参考: https://help.github.com/articles/generating-ssh-keys 中的Step3 . …

一台电脑使用多个github账号时如何免密登录 Read More »

改变当前git repo的author name和author email

如果你原有一个git账号,它是 UserA/UserA@test.com, 并且你用它工作过 现在你又搞了一个git账号,用这个新账号提交代码后,github(或其他git中心)页面上的日志会说刚刚的代码是由“UserA/UserA@test.com" 提交的。这就很搞笑了。 为什么会这样? 因为你可能已经把UserA设置为global username了 可以这样检查一下 git config –global –get user.name git config –global –get user.email 解决方案是在当前repo中,修改git客户端的username/email: cd your-working-dir git config user.name "UserB" git config user.email UserB@test.com 注: 这里的username/email只用于git commit中的author记录,跟用于登录github的用户名/密码没有关系

二叉查找树与平衡二叉树

内容编译自网络 Binary Search Tree 什么情况下会出现O(n) ? 如果树的根结点没选好,一棵树变成一个列表: 平衡二叉查找树 –  可以自动旋转 参考: http://en.wikipedia.org/wiki/Binary_search_tree http://www.cnblogs.com/huangxincheng/archive/2012/07/21/2602375.html http://www.cnblogs.com/huangxincheng/archive/2012/07/22/2603956.html

代码片断:远程接口返回数据中的属性过滤

从网络流量考虑,我们的远程接口有时并不需要返回所有数据。为此,可以通过反射去掉不要的属性。 /** * 过滤属性,省流量 * * * @param bean * @param filter */ public static void filterProps(Object bean, ResultPropsFilter filter) { if (filter == null) { return; } PropertyDescriptor[] pdArray = PropertyUtils .getPropertyDescriptors(bean); if (pdArray == null) { return; } for (PropertyDescriptor pd : pdArray) { String propName = pd.getName(); if(propName.equals("class")){ continue; } Class<?> type …

代码片断:远程接口返回数据中的属性过滤 Read More »

基于比较的分页机制的注意事项

分页机制有两种: 一种是根据偏移量(或页码)+页大小获取数据,另一种是根据上一次看过的最后一条记录+页大小获取本页记录。 后一种机制常见于weibo/twitter这种feed流页面:记住当前页最后一条feed的发表时间,然后找出比这个时间更早的feed.   这种情况下一般不需要知道feed总数。 姑且把这种机制称为“基于比较的分页”。 使用这种机制时,需要注意的地方有: 1. 用作比较的维度应该是唯一的,在做大小比较时才不会遗漏数据。如果按ID来比较,则比id=1更大的记录是(2,3,…),不会遗漏;  如果按发表时间来比较,则比100毫秒更大的记录是(101, 102…), 而同在第100毫秒发表的其他记录就会被遗漏掉。 2. 除了往下翻页,还可能要往上翻页; 系统应该同时支持。 3. “首页”应该传什么值作为比较基准? 如果id为Long型,应该传-1还是传一个Long.maxValue()? 这种地方最容易埋坑,引发程序错误和沟通困难。 最好的办法是再另传一个参数:firstPage = true, 简单明了。 4. 服务端回传记录时,应该同时回传本页记录第一条和最后一条的比较值,比如第一个feed的id和最后一个 feed的id; 客户端/浏览器 再根据这两个记录决定上一页和下一页的URL。你会说不传也可以,客户端自己从feed列表中找出这两个id; 然而用于比较分页的维度未必是feed的属性,从feed列表中是找不出来的,比如分页查询“我评论过的feed”时,要通过评论ID来做比较,评论ID显然并不是feed的属性。 5. 第4点帮助你得出一个结论:分页参数可以跟业务无关,客户端不必知道分页维度的业务意义; 同理,也不必知道下一页的记录是比某个属性更“大”,还是更“小”,客户端只需要传“下一页”,或是“上一页”,让服务端自己决定取更大或是更小的记录。 6. 有了这个结论,我们可以做一个通用的、适用于任何业务分页参数类。示范代码: 分页参数类: public class PageByCompareParam { * 服务端将跟这个值比较。日期时间类型请传毫秒数时间戳,数字类型将转成字符串后再传过来 */ private String value; /** * 页大小 */ private int pageSize; /** * true = …

基于比较的分页机制的注意事项 Read More »

Jdbc代码片断:使sql in子句中的记录数恒定

private List<Long> toNormalizedList(List<Long> idList) { List<Long> newList = new ArrayList<Long>(); newList.addAll(idList); for (int i = idList.size() + 1; i <= 100; i++) { // 填满100个,使得每个prepared // statement都有100参数,以充分利用sql缓存 newList.add(idList.get(0)); } return newList; } 相应的ibatis sql map: <select id="batchGet" parameterClass="list" resultClass="java.lang.Long"> select distinct * from some_table where id in <iterate open="(" close=")" conjunction=","> #[]# </iterate> </select>

代码片断:在m位数之前加0,凑足n位

代码片断:在m位数之间加0,凑足n位. 这主要用于使数字按字符串排序的顺序跟直接按数字排序的顺序相同 比如把 8,9,10,11 变成 08, 09, 10, 11后,按字符串序排序仍与数字大小序相同 /** * 1 => 0001 * * @param positiveNumber * @param maxValue * @return */ private static String prependZeroForNumber(int positiveNumber, int maxValue) { int digitLength = String.valueOf(maxValue).length(); String numStr = String.valueOf(positiveNumber); StringBuffer pre = new StringBuffer(); for (int i = 0; i < digitLength – numStr.length(); …

代码片断:在m位数之前加0,凑足n位 Read More »

要不要做冗余字段?

冗余是为了避免join, 但避免join未必要一定冗余。你可以先把A关联的b_id查出来,然后再去B表里查一次。 那么什么情况下应该选择冗余,什么情况下选择查询两次呢?除了要看数据会不会更新,还有一些考虑因素:(大前提是不作join) 1. 如果只需要看A的单行记录,及这行记录对应的B记录,使用两次查询就够了 2. 如果需要查看A的列表,及对应的B记录,那就可以考虑把B记录冗余到A表,也可以不冗余。不冗余的话,就要收集A列表中所有的b_id,然后批量地去B表中执行in查询,稍微有点麻烦 3. 如果需要根据B表中的字段查询A记录,并带出相关的B记录,那就只能用冗余了。为了帮助理解,举个例子:在一个论坛系统的数据库中,找出这样一些“回复”记录,这些回复对应的主贴的作者以"k"开头且回复发表于三天之内,结果中除了要显示“回复”记录,还要显示主贴的作者。 如果“回复”表里没有冗余“主贴作者”字段,这个问题就无解。