suiterchik

要是我选的话我选携程，活下来才有 DPS 。OTA 这块未来很长一段时间内都很难有竞争对手，别的不说，单说各大连锁酒店，携程是他们的大股东，另外携程办公楼的地皮都是携程的，财报上有一项租金收入，意味着携程某种程度上是地主。当然了携程的钱也比较少，但现在这个环境我觉得稳定苟几年，把自己的技术水平提上去才是第一优先级，另外两家的稳定性我感觉不是很好。

当然了以上都是我个人的看法，因为对你的情况也不是非常了解，所以最终决定还是得看你的想法

按照我多年的招人经验以及身边的同事分布，排除 C9 的话，则华科、北航这两所分数差不多的大概率也上不了；那么剩下的学校就是北邮、南开、天大、成电这几所了，再往后就是西电、大连理工、华南理工这几所，同济我好像还没遇到过，不过这也是身边统计学，不一定靠谱。

这几所里面，如果以后不考虑走体制路线的话，北邮可能会好一些，尽管不是 985 但北邮在互联网公司里的分量也足够，而且有个好处是实习方便，现在招人其实更倾向于招有实习经验的学生；

如果想稳妥一点留一个进体制的后路，那么尽量选 985 的，这几所学校我可能更推荐天大和南开多一点

@haimianbihdata 哈哈哈哈啊哈大数据第一步，如何 shade 掉 guava

各有各的优劣吧
* 你的写法对未来业务逻辑的变更会方便一些，比如现在只是对最后一个元素处理，那未来可能会对命中某些逻辑的元素处理，那么这种情况下你的代码改起来会容易一些
* mentor 的写法少一些 if 判断，能带来一些性能上的优化，不过编译器和 JIT 估计会优化掉，所以可能性能上差异不会特别大

对于这种影响不大，属于代码风格方面的差异，那就遵循公司整体的代码风格吧，同一种风格利于长期的维护和迭代。对于有性能风险（跑得快不快）、维护性风险（后期逻辑好不好变更）、稳定性风险（挂了会不会影响其它逻辑）等，那么就对等沟通，对事不对人呗

根据你同事的 feat_1 是否需要跟着你的 feat_2 一起上线，有以下两种情况：

1. 本次发布只紧急发布 feat_2, feat_1 不跟车发布，则对 master 发起 feat_2 的 merge request ，只发布 feat_2 ，后续 feat_1 需要发布的时候，对 develop 分支 rebase master 分支，相当于 commit 顺序是 develop -> feat_2 -> feat_1

2. 本次发布同时带上 feat_1, feat_2 ，则对 feat_2 分支进行 rebase develop 操作，然后向 master 发起 feat_2 的 merge request 操作；或者先向 develop 发起 feat_2 的 merge request 操作，然后向 master 发起 develop 发起 merge request 。相当于 commit 顺序是 develop -> feat_1-> feat_2

@loading @qping 如果日常用鼠标的话，可以考虑通过 ahk 进行右键划屏，也就是按着鼠标右键，然后向左或向右切换虚拟桌面，具体参考 github 的 right-button-ninja 项目

https://github.com/hansenwangvip/right-button-ninja

倒也不是没有稳赚的策略，鞅论走起，就怕你熬不到赚钱的那一轮 [狗头]

@ianshow15 另外，关于你提到的痔疮问题，可以通过在家安装一个智能马桶盖显著缓解；关于腰突问题，可以通过日常多做麦肯基疗法的康复动作略微缓解；至于剩余的问题我目前还没有患上，所以也没啥建议啦 ：）