@d3js 员工名额之类的，可以理解为裁员指标。

北京地铁，13 号线西边沿线(龙泽站附近有个隧道大家都没信号除外)、10 线某些站点，我都遇到过别人还在刷抖音视频（当然他们可能也会卡一下，但很短暂），而我连网页都打不开，信号显示只差一格，电话通话不受影响。

现在是移动的流量卡，之前也用过电信和联通的效果差距不大。

觉得别人夸大其词的，欢迎你带俩手机去试试， 西二旗至知春路一段，立帖为证你要是俩手机网络效果几乎没差别，录下视频，我给你 V100 。

@8863824 所以说没办法，大家都只能凑合，我只能是说吃一堑长一智，尽量不卖楼薄的房子，住顶楼对我来说太热也太高了，不值得为了这个付出太多代价。

@cat 还非要嘴硬给自己挽尊，那我只能说要么瞎要么蠢的同时还很犟。

楼里有人 分不清 VS 和 VS code ，和哪个是 ide 哪个是 editor 有关系吗？ 这是分不清 ide 和 editor 的问题吗？ 那些分不清这俩的是 “不知道 ide 和 editor 区别” 导致的吗？

你要是说个"有人分不清 正主 和 过继的侄子" 别人会觉得你也个分不清的蠢货吗？

@zyt5876 哎，无解，我也不是为了指责楼主，我只是以前同时经历过类似楼主和楼主楼上的双重情况。
而我对于噪声敏感度低睡着了吵不醒，并且我还不是因为走路被楼下找上了，所以我可能更同情楼上吧。

这事不论楼上楼下其实大家都能想明白，其实事情的本质是开发商在满足最低建筑要求下的偷工减料引起的问题，但不论谁家都不可能随随便便搬家，那只能找找哪个方向好改善，那个柿子捏起来软了。
好的情况就是互相体谅，不好情况自然就是像楼主这样，并且不好的情况才是多数，互相体谅的那些其实很多也都是双方都觉得自己退让已经是受了委屈了。


你说他们家孩子练乐器噪音我是理解的，但走路有问题这个事我只能说这是你挑刺了，人和人的步态本就不一样，让人改习惯完全不可能，这就像有人出来说你坐姿不正确握笔不正确一样，必须纠正一样，属于管的太宽了。

一想到我要是在家走路都得踮着脚，要不楼下就要投诉我我就会感到压抑，住自己家还得像贼一样。

@cat 楼主说 VS （ IDE ） 不好用，不如 Idea （ IDE ）。

然后你说 “一个开发者为主的社区，这么多人分不清 ide 和 editor 么”， 请问楼主提到的两个东西哪个是 editor ？

究竟是有些人分不清 ide 和 editor ，还是说有些水货只知道 VS Code 连 VS 是什么都不不知道。

简单，搜索燃气壁挂炉，这东西一大堆厂家卖，估计淘宝都搜得到。

然后雇人装修给地面铺地暖管道加 30cm 垫层，如果你们南方找不到会铺地暖的装修队，那你多花俩钱从离你最近的北方城市找人过去，河南陕西绝对不难找。

无非是钱的问题，你住广州海南想弄都可以弄暖气系统，烧燃气或者电加热，方法多得是。


而且不要以为北方人人都集中供暖，我在北京租房这些年自供暖比集中供暖的房子租的更多，差距无非是一个月 500 还是一个月 300 罢了。

并且，小指弯曲回来按也不觉得难受，这是我最常用的两种姿势。

https://s2.loli.net/2024/12/13/dXMCPpeAEfwh6Bo.webp

我低头看了一下自己，我是用小指的指关节按的。


https://s2.loli.net/2024/12/13/JQj2NAfBahqyUML.webp

楼主收入和资产比我强多了，我都 32 了还不慌，别人也没人能把我怎么样，我也没觉得因为个婚姻就失败了，反倒觉得年收入还有离家漂泊才是我失败的地方。

我还是习惯用数值类型的，不过 varchar 也可以接接受，但数值类型我不会强制数值的大小与含义有关系，单纯是思考时候想到的顺序，同时用 char 或者 vchar 我也不接受写 "0001"、"0002"这种玩意，你这么写还不如用数值类型。


另外，不要给数值类型设置长度，因为 mysql 对数值类型设置长度没什么意义，底层存储该是多长还是多长只跟着数值类型 bit 、int 、long 的定义走不会看你设置的长度，只有显示的时候会给你截取一下。

我只有 tinyint(1) 的时候会设置长度，这是因为我们用的 orm 生成 bean 的时候默认可以将这个特殊类型识别为 boolean 的，8 之后我用的工具这里会 warning 让我用改 bool 类型，目前还没改，因为我还需要和别人统一，包括 json 类型，虽然数据库支持了但我们开发手册没改，所以我实际还是用的 text 。

第一个示意图勘误， 排版没搞好折行了。

dev-> dev+a -> dev+a+c -> dev +a+c+b 或 （ dev merge(a + b)+c ）
dev -> dev + b ->↑

我的观点
1 、善用 rebase ，但不要滥用。

我不喜欢用 rebase 来合并分支，尤其是合并到 dev 和 master 这种关键节点，对于是否--no-fast-forward 我都可以接受，但拉取时还有从 dev 合并最新更新到我的分支时我还是会优先考虑 rebase 的。

因为很多时候你从什么位置 fork 以及你从远程分支拉取最新前有提交都是无关紧要信息。
比如你和别人各自开发功能然后他先合并至主线了，那你合并的时候，保留你和他是并行开发还是你在他的基础上开发其实对于多数产品没那么重要。

比如：
dev-> dev+a -> dev+a+c -> dev +a+c+b 或 （ dev merge(a + b)+c ）两种差异重要吗？ 你 b 分支需要别人关注吗？
dev -> dev + b ->↑


2 、善用 rebase -i （ squash / fixup ），尤其是 push 和合并到主要分支前，将零碎杂乱的无用提交都整合。

开发时 commit 提交无所谓毕竟 statsh 确实用着让人不安心，把 commit 但保存无所谓，但合并前最好将提交整理一下，尽量按功能模块让每个 commit 包含一小部分完整功能，没人关心你写一半的代码代码和之前有什么差异。

而你这 200 多个提交确实有点太多了.... 当然如果每个提交都有前后对比的价值那确实不应该合并。

比如:
feature-newxxx -> funA.setp1-> funA. step2-> funB.step1 -> merge(dev) ->funB.step2 -> funA.bugfix
feature-newxxx (rebase(dev)) -> feat: funA -> feat: funB

在这两种提交线路图里我更倾向于用最后 push 那个 rebase 修改过的第二种，你开发 A 功能中间自己思考草稿时的增删改对最终成品意义不大。


---------
最后，你们领导的意思是不是指我说的第二种啊， 希望你用 rebase 来将那些无用的中间过程的 commit 用 squash 或者 fixup 合成一个 Commit 。

楼里觉得夸张窒息的那说明阶级还可以，楼主的情况其实在三线以下小地方是个普遍的状态，不过楼主确实负债压的太狠了，基本不给自己闪转腾挪的空间了，所以要小孩的计划最好往后推一推。

我是不太能接受这种走钢丝的生活的，但我身边确实很多人如你一样，最后许多人也就这么过来了，没什么好解决办法，把自己当灰色牲口呗，兼职摆摊卖吃喝或者送外卖，一天下了班就干兼职。

@geelaw 我的观点就是一句话 他的用法不违规，但不道德， 因此被人口诛笔伐是应该的，活该。