北京联通。
光猫桥接，自购华硕路由拨号。
用的华硕路由自家的 DDNS 。
未开通 Web 服务，DDNS 仅用于接入 VPN，手机通过 VPN 接入家庭网络，然后再访问家庭局域网内部资源。
域名是国内平台购买的.cn 结尾的域名，进行了实名验证，但未备案，在 DNSPod 上解析。

联通没有因为这事找过我。

仔细看一下合同，没有直接规定这个事情的话，可以以“使用 DDNS 发现家庭网络 IP 用于查看自家视频监控系统”为由，投诉到工信部试试。

在北京好像是 4G 套餐直接改 5G，价格和流量不变，其他地区可能降费提速的政策还没完全落实？

我是绝大多数时候都能收到 5G 信号，个别信号差的地方会跳到 4G，速度没有直观的对比过，所以也不清楚有没有提升，总之现在挺快的。

Linux 上有一个和 iterm2 功能上差不多的 Terminator，也可以实现 Guake 的那种效果。

我 2016 年的老 MBP，到现在一直用 iterm2，没有遇到这种问题，看是不是其他什么原因。

如果做 Web+App 跨平台支持的话，这个不能在前端做，因为 App 没法实时更新，所以很多企业的方案是前端+BFF+后端的方式，API 映射工作在 BFF 层做，确保后端不管怎么变，BFF 都能做相应处理来兼容前端各版本。

全包你也干预不了多少细节了，所以，只要合同和需求没问题了，等完工就行了。

冬天冷的话，房屋密封是最重要的，其次才是供暖，能地暖最好地暖，装修完了日后想改就很难了；窗户建议选断桥铝双层玻璃，如果在路边噪音多可以选三层玻璃的。

我之前是找的专门的设计工作室做图纸设计，然后找半包装修公司，他们只负责施工和辅材（水泥、胶、线盒、钉子啥的），主材都得自己买，一个法定长假基本全都泡在建材市场。搭配第三方监理，这种模式虽然很累，但几乎是完全受自己把控的，任何一方都受制约难以耍手腕。

装修从提需求做设计开始到最终施工完成验收，每一个环节的工作都是建立在上一个环节的结果的基础上的，所以每个环节之间让监理做质检很有必要，有问题的要整改；同时自己也得尽可能长远考虑，在前期就把需求、要求沟通清楚，避免后悔。

建议装修前研究一下收纳空间怎么规划，有一些书可以翻一翻，比如《小家，越住越大》。

好像一些主板大牌有准系统产品线，基本就是笔记本规格硬件，压缩到一个电视盒子大小，很多也可以装高端独显。

只不过移动平台的硬件的设计目标除了体积小以外还有低功耗，本身都不如 PC 电源尺寸大，供电和散热都有局限性，拿来做准系统的话性能方面恐难以达到标准 PC 的水准，体积、性能二选一。

有装机手艺的话，ITX 小钢炮也能做到挺小了，就是还是达不到可携带的程度。

我大学有个硬核老师，平时在机房要用自己的电脑做开发，而且是虚拟机开好多的那种，对性能要求很高，所以他找了个顶部带把手的中塔机箱，上下班拎着走……

#2 楼两地三中心+同城异地，短短几个字，基本能覆盖大多容灾能力了。

上云的话，云厂商就能提供大多数容灾能力了。

存储容灾上冗余阵列+异地备份；系统容灾至少有双节点，确保一个挂掉另一个可以马上工作。
找家一本正经的等保测评机构花钱做个二级或三级的测评（现在公安都要求每年至少做一次吧），他们会引导你们考虑解决天灾人祸导致主机房直接消失的情况。

@acmore #55 很多宗教都有这种观点，不论是本土的佛教、道教还是外来的基督教，甚至是欧洲神话，应该算是人类共识了吧。
我身边宗教“爱好者”并不少见，甚至有些是高学历的，会绕开宗教的迷信的部分去研究哲学部分，美其名曰“唯物主义信教”，算是把宗教当成一种精神上的工具，各取所需。

一些宗教的哲学观点中，很多苦难来源于欲望，割舍欲望之后，便跳出了苦难，成了局外人。

所以要不要尝试一下修行？（权当脑洞，不是真建议）

20 分钟就好，睡多了会不容易醒，不是因为没睡够。

抛开场景谈对错都是耍流氓。

一个 Vue 项目是由各种类别的模块组成的（如组件、服务、路由……），对于不同项目来说；不同类别的模块规模不同，比如可能营销项目路由路由巨多、组件和服务很少，后台项目路由很少、组件和服务巨多；模块之间的对应关系也不一样，比如有的项目服务可以被所有组件复用，也有的项目服务是从属于各个组件的，不可跨组件使用。
Vue 提供了项目文件结构的灵活性，那么自然在不同场景下可以设计成不同的文件结构，最终都是服务于开发效率。

我接触到的体制内的员工，他们的工作有以下几个好处：

1. 遵守劳动法，工资该给几倍给几倍，真有必要才加班。
2. 社保很高，有的社保金额都超过大半工资了。
3. 标准工资低但福利多，有些富裕的领域会有各种奖金，会发各种东西，发的生活用品和食品（兑换券）一年少说就得几千，如果单位比较人性化的话能省下自己买很多东西的钱。
4. 工资以职级评定为准，只要人际关系不差、擅长考试，升职到中线以上不会很难，就只是会枯燥一些，而且突破天花板要看天时地利人和。

体制内的坏处也是有的，这里就不多说了。

当然，不同体质、不同单位的情况会有些许差异，不管应聘体制内还是体制外，都还是得具体了解才行，有时候可能没有绝对的好坏，更多是适合不适合自己的问题。

我搞了 7 年 JS 技术栈，Deno 就是个过度宣传的东西，本身的定位是个 sandbox，支持 ts 也还是逃不掉转成 JS 在 V8 里跑

免打水晶头，6 类不带屏蔽的 10 块一个，带屏蔽的 20 块钱一个；手打水晶头，6 类带屏蔽 50 块钱一包 50 个，网线钳 20 块钱一个……如果只接一根线，那么就只买 2 个，确实免打的成本低。

我就觉得压水晶头特解压，水晶头也花不了几个钱，之前学的时候就是一个个压，压完测，测完剪掉拿新头重新压，老师在一旁看着都不心疼的。

通不通大概率不是压的问题，是排线的问题，有没有排对顺序，是否剪齐，有没有插到底，手残的话也没法保证免打的就一定通，这个毕竟是手艺活，对工艺要求高的话还是老老实实买成品线或请师傅吧。

网线钳除了压水晶头以外，去皮、剪齐也挺好用。

@balabalaguguji 网站上加个连接，把每个项目的项目地址和许可证内容塞进去就行了，可以参考各 APP 里的“开放源代码许可”页面。
不知道有没有 GPL 的轮子，和其他代码一起打包的话可能会有问题。

@121819756 #2
灰度发布和 ABTest 有时候需求会有些区别。

你们应该是分布式方案吧，如果是分布式无状态方案的话（如 REST API ），ABTest 通常需要确保一个用户不会被重复分配 AB 组，需要用户户第一次访问的时候分配 A 组或 B 组，然后用户每一次访问都走被分定的组，这个有两种方案：
1. 在所有服务节点都部署 AB 两种逻辑，然后用户第一次访问给用户分组并记录到数据库（或 Redis ）中，用户再次访问的时候从数据库中读取用户的分组，然后走对应逻辑。
2. 服务前面加一个 API 网关层，API 网关用户给用户分组、记录分组信息、转发用户请求到特定分组的服务器集群。

然后单纯的灰度发布的话可能不需要固定用户的分组信息，所以通常的做法是从负载均衡上，给一台实例的权重设为 0 （停止分配流量），等没流量了就给这台实例升级为新版本，然后负载均衡慢慢提权重，一点一点放流量进来，同时监控服务状态，出现异常就掐断流量回滚，正常就逐渐把流量放到平均水准，然后再更新第二个实例，重复上述操作，知道把所有实例更新完毕。这个有些持续部署工具可以做到自动化的。

你会发现，这些基本都是通过运维方案来解决的，服务程序本身通常不需要考虑，顶多做好老版本的兼容，确保无缝升级的时候不会有兼容问题。

不知道灰度发布具体指的是什么意思。

如果指的是整体服务的版本发布，可以让新版做好旧版的兼容，然后多实例一个一个的升级。
如果指的是热加载一些 js 文件可以动态 require，但对打包工具不友好。

很多年了一直是 windows defender，但其实还是得有好的使用习惯。

现在用软件基本都是正版或者开源，用 chocolatey 或者去官网下载，所以还好。

唯一需要注意的就是勒索病毒，所以现在用 NAS 基本都用 cyberduck 之类的连接，不直接挂载到系统上，避免中毒的时候被一并加密。