@ByteCat @baobao1270

完 全 一 致

@jingcoco 没有自动化测试，全靠手工测的话，系统做大了以后改动、修复成本会高得惊人。
我司之前就是纯手工测试，整个系统让一个 QA 团队测，一个版本完整测要测 3 周，而一个 sprint 才 2 周，也就是修复完一个问题以后要隔开一个 sprint 才能知道有没有问题，有的话要等下一个 sprint 才来修补。然后还有大量的 bug 没被 QA 团队测出来然后漏给客户的，就不多说了。

刚发布的系统里的版本应该是冻结时候的，没特殊问题的话必须要等发布后（也就是今天以后）才可以更新软件版本。Ubuntu 大约是 2 月 19 号冻结的，所以是 7.4.3 。等过几个星期应该就会导入 7.4.5 了。

用 ORM 的我已经很多年没有考虑过注入问题了。你随便构造数据，我什么都不过滤，能注入算我输。

显示器和电视的调教是不一样的。以前试过拿夏普的液晶电视当显示器用，说实话，感觉眼睛要瞎了。

@dilu 外接精准计时设备，例如铯原子钟，或者北斗或 GPS 时钟同步信号。

既然能写入 /usr/bin，那说明别人已经拿到了 root 权限，那从内核到系统文件，所有的程序都可能会被换掉，你不重装难道留着过劳动节么。

@laminux29 我并没有否认不平等关系。但是不平等关系和羞辱和否决和否定都没有决定性的联系。
考察的目的是找出那些人符合面试官认为的适合公司的候选人，筛掉你当然是因为你不符合面试官心目中的候选人形象。

新手入门我总是建议请老老实实从一个优秀的 GUI 开始。等你知道了 working directory / stash / stage / commit / merge / merge back / rebase 了以后，再要想比如说装个 B，再考虑纯 CLI 的情况。
比如 git pull 这样的命令只能处理最简单的拉取情况。如果你要拉取有冲突的 commit，情况会复杂得多，光一个 add 一个 commit 是远远不够的，需要首先根据场景看要做 rebase 还是 merge，然后根据具体操作去做 3-way conflict resolve 。

你现在的情况是 working directory 有更改，没进 stage 也没上 commit，更没 stash，于是产生了 local change conflict 。然后你做了 add 和 commit，这时候如果你有图形界面的话你可以看到状态是这样的。

origin/feature-init20200401 -> 7bb0b5eb --- 60 多个提交 ---> ae21cc9d
feature-init20200401 -> 7bb0b5eb -> c3c59ecc

然后你又做了 pull --merge，和一个 commit，变成了

feature-init20200401 -> 7bb0b5eb -> c3c59ecc -(merge ae21cc9d) -> 9e87e2c6

先不论结果怎么样，中途这条分支叉出来叉进来再叉回去，会让人无法看清每一个提交的用处和每一处修改的位置，万一提交后出了问题，也很难去单独隔离出某一段提交然后回滚。比如你这里，一处修改分了两次提交，一次在 merge point 之前，一次在之后，就很难去隔离测试。

比较好的做法是，先 stash，然后签出 ae21cc9d，然后 stash pop 并 resolve conflict，然后再做一个单独的「去 log 」提交。
另一种做法是，先 commit，然后做 pull rebase，在 rebase 过程中 resolve conflict，然后把 rebase 过的 commit 给 push 上去。
两种做法的结果是完全相同的。

如果你司没有针对 git 的学习过程的话，建议大家聚在一起好好学一下。瞎基尔用 git 是对 git 强大能力的一种浪费。正确使用 git 会大幅提高源代码管理效率的。

至于你说把同事代码删了是怎么回事，这个也只需要开个 GUI 工具，往上回溯一下看看每个提交的 diff 就知道怎么回事了。无非是 merge 的时候出了问题吧。

@mogami95 https://i.imgur.com/4zPGV9L.png

总的行长有限制。
另外字符串长度还要考虑字符集，UTF8 存 64 字节字符串并不一定能存下 64 个字。

@laminux29 这个问题的本质难道不是考察你问诊的能力？
面试官问了一个模糊场景的问题，作为程序员难道不是去尝试缩小问题点，找到具体问题在哪，然后再针对优化？
让你猜场景和算法？难道不是让你问他场景和算法然后去缩小问题？

就说经典的面试问题，如果用户输入了你的网站地址，按下回车，但是网站迟迟不加载，问题在哪。你不去一步一步分析场景缩小范围找到问题点，坐在那里傻瞪着面试官，那人家不拒你留着过年么。

@whileFalse 当然是通过免费政策搞死良心对手，然后等垄断了再狠狠割一把啦～

git 可以干但是这种场景似乎不是 git 该干的活。最好还是单独做备份工作。

> 我们发送一个请求不是最后都被解析成 ip：端口

当然不是。你的请求就是你的请求，发出去是什么样，别人收到就是什么样。ip 只是从域名做解析，和你报文里写的内容是无关的。

这些文件有没有被 git 曾经 stash 过？

手动更新一下看日志啊。另外可以让 acme 自己升级一下看看。

应届生新人入职还能有什么要求？两只眼睛一个鼻子一张嘴，带着去上班就成了。

我的印象是公司一般默认应届生什么都不会。所以如果你会刷题，你已经超过 95%的同龄人了。如果你还做过有点内容的开源软件，你可能已经超过 99%的同龄人了。如果你和人一起合作开发过开源软件，参与过 peer review，参加过论坛讨论和项目维护，那你进了公司都可以收同事做小弟了。