小孩地铁站丢失指南

这个十一,我妈带着我的最小的表妹(比我小11岁,与此同时,我最大的表姐今年已经60岁了)来杭州,几天前我们一起去拜访位于城东的我表哥家,回来的时候我们乘一号线,在彭埠转四号线回到我家所在的联庄。

在转车的过程中,由于我的失误,一看地铁要出发了,就赶紧叫我妈上车,结果我和我妈成功上车,同时地铁大门关上。我只能在关门前对我表妹喊留在原地不要动我回来接你。

到了下一站火车东站,我把我家的钥匙给了我妈,跟我妈说叫她先回去,我回去找人。

(更多…)

git操作经验谈

一、代码从远程仓库拉取到本地(更新本地代码为最新)

涉及命令:git fetch / git pull

Q:区别?

A:git pull = git fetch + merge to local

使用场景:

1、本地分支aaa无修改,远程仓库分支aaa有修改,需要更新本地代码:

git pull

2、本地分支aaa有一些改动(通过git status查看是否有改动),远程仓库分支aaa有修改,需要更新本地代码:

方案1(推荐):git fetch更新远程分支→git merge(→ 解决冲突后,git merge –continue)

方案2:git stash暂存本地改动→git pull拉取远程分支合并到本地→git stash pop恢复本地改动

(以上操作可能需要合并冲突(命令行提示CONFLICT (content): xxxxxx),请参考下边的冲突处理)

其他场景待补充

二、冲突处理

展现内容:

gaudi:scenario-test (paycashier)$ git merge master
Auto-merging src/main/java/com/caocao/testgroup/scenariotest/component/AbstractTcpClient.java
Auto-merging pom.xml
CONFLICT (content): Merge conflict in pom.xml
Auto-merging conf/33.properties
Automatic merge failed; fix conflicts and then commit the result.
gaudi:scenario-test (paycashier *+|MERGING)$

Q:冲突发生的原因?

A:某文件的第n行内容在本地有改动或提交:local_commit(修改或删除),且合并的分支的提交:origin_commit中也对此行做了改动,并且local_commit和origin_commit不在一条提交链上(没有祖先/子孙关系)。

当合并两个提交时,则这一行被视为有冲突,不能被auto merging。

1、处理方法1–手动编辑:

编辑器打开冲突的文件,通过查找“=====”内容查找到冲突所在行,如下:

<<<<<<<<HEAD

other code

========

your code

>>>>>>>>your branch name

上方是远程分支上的更改内容,下方是本地分支的更改内容,需要你进行内容抉择,决定保存的内容(将<<<<<至>>>>>的内容替换为合并内容)修改完内容后,命令行git merge –continue。

2、处理方法2–IDE编辑:

推荐使用IDEA自带的Resolve Conflict进行可视化的冲突编辑。点击项目根目录,点击右键 → Git → Resolve Conflict,对每一个文件依次双击处理:

处理完毕后,点击Apply→ OK,即可保存此次文件内容。处理好所有文件内容后,命令行git merge –continue

三、推送本地分支到远程仓库分支中(提交本地代码到仓库)

一般来说master分支是禁止直接push的,正确的处理方式是将改动push到自己的分支中,然后在gitlab中提交PR,由他人(例如leader、有经验的团队成员)做code review后同意合并。

当你需要修改代码时可以通过:

git checkout -b dev_xxx_version (即git branch dev_xxx_version; git checkout dev_xxx_version)

进行开发分支的创建(当你已经在master分支上进行改动且未提交时,也可以执行以上操作,切换到新分支)。

进行一系列的commit后,通过

git push origin dev_xxx_version

的方式将自己的开发分支push到远程仓库中

四、自己的开发分支在日常操作时需要注意以下几点:

1、自己的开发分支在代码实现完成,且功能稳定后,要及时提PR,合并到master分支中,避免后续合并出现难以处理的冲突

2、不稳定的开发分支(实现未完成、测试期、BUG较多等)不要合并到master中,要时刻保证master分支的稳定

3、如果master分支有变更,需要定期地将master分支的内容merge到自己的开发分支中,避免①和主干分支的关键配置或者组件脱节严重,造成代码编译或运行出错;②后续合并出现难以处理的冲突

4、推荐的周期操作:git pull origin master, git pull origin 你的开发分支→ master合并到开发分支→ 开发分支上做代码实现、提交、测试→ master合并到开发分支(可选操作,当你开发周期较长时)→ 主流程测试→ push→ 提交PR

博赌者说

最近世界杯如火如荼,很自然的冒出了很多凑热闹的人,这些凑热闹的人参与世界杯的一种方式之一就是买球。有的人秉持着小赌怡情,让看球有点盼头。有些人则指望一夜暴富,赢了会所嫩模。

其实赌博赌博,这个字要分开看,赌只是他的活动行为方式,博才是他的本质。往大了说,一切充满未知风险的活动都可以定义为赌博。无非这些赌博所带来的回报会有所不同而已。

看透了这些本质,再去下手赌博。

很多人都会觉得自己能控制住自己的欲望。其实不然,人最难控制的就是 “瘾”这个东西,所谓由俭入奢易,由奢入俭难。一旦尝到了赌博所带来的不劳而获的快感,再想戒掉就没那么容易了。物理上的戒烟尚且如此之难,那么心理上的戒赌的难道更是难上加难。

(更多…)

伴我同行

最近上映的一部哆啦A梦大电影之金银岛,勾起了我很多的会议。这个蓝胖子是很多人的童年回忆。在我们这一代人中,每个人都希望有个叫哆啦A梦的小伙伴,都希望有个能拿出各种道具的口袋,能让我们想去哪里就去哪里的任意门,以及一些其他奇奇怪怪的道具,这些道具站在成年人的角度来看可能存在逻辑上的问题,然而每个道具其实对应的都是小孩子面对一个问题,所想到的解决方法。而且看上去,这些解决方法都还不赖。

(更多…)

And then there were none

晚上看了个非常非常牛逼的小说改编的话剧,在推理小说这么多年的发展史上,有两座代表着这个行业这个领域不可跨越的高峰的人物,一个是写出了福尔摩斯的柯南道尔。另外一个是著作满身的推理小说的黄金时代的三巨头之一,也可能是名气最大的阿加莎克里斯蒂。可能写作手法或者其他方面这两位不是最大的,但是名气上来说。这两位可谓是前无古人后无来者。福尔摩斯自不必多说,已经成为了侦探的代名词,而阿加莎的话,我就问下,如果不去搜索的话,谁会知道推理小说黄金三巨头中的另外两个是谁呢?你可能没听过阿加莎,但是你可能听过东方快车谋杀案?尼罗河上的惨案?或者其他类似abc谋杀案,阳光下的罪恶等。

以下有剧透,请慎重点击

(更多…)

性能测试分析

一、场景设计

场景设计需具备以下共同要素:

以下是针对不同测试场景的名词术语说明

1.  单接口基准测试

使用1个用户或者一个线程,不限制tps值,对单一接口进行压测,执行时间为10分钟左右,获取无压力情况下的响应时间与资源使用情况,作为性能基线以及其他场景下的参考依据。基准测试 错误率为 零 , 能说明脚本与数据无任何错误。

(更多…)

昼颜电视剧观后感

昼颜是一代神剧,大约三年前我还住在锦绣江南,我还在华为上班的时候就在看这部连续剧,这部电视剧的剧照虽然看上去很黄很暴力,如下图所示,而且由于是日本电视剧,很多人生启蒙是靠日本小电影启蒙的同学会误会成这部正常的电视剧为东京热之类的日本动作片。

(更多…)

研发团队一般架构

众所周知,在一个IT企业中,研发部门是不可或缺的重要部门,而一个研发部门是由很多相关业务部门组成的。对于很多非IT从业者而言,做一个app是很简单的,所以有个经典的段子就叫做,万事俱备,只差一个程序员和一个投资人我们就可以在星辰大海中遨游了。

其实举个例子来说,对于一个app,他涉及到的人员,最少也是需要有以下几个方面(以下排名不分先后):

(更多…)